Сегодня решил сравнить размерчики OS X 10.8 и macOS 15.
Вот что увидел:
OS X 10.8: du -sh ~/Library -> 33M
macOS Sequoia: du -sh ~/Library -> 8.2G
OS X 10.8: du -sh /Library -> 842M
macOS Sequoia: du -sh /Library -> 3.8G
OS X 10.8: du -sh /System/Library -> 3.2G
macOS Sequoia: du -sh /System/Library -> (куча permission denied даже для read, спасибо SIP) -> но то что удалось считать 139G
Конечно последнее значение выглядит как фальшивое, но на остальные сквозь пальцы посмотреть нельзя. А тем временем предлагаю оценить сколько новых фишек добавилось в новой macOS за 13 лет и оценить здравость такого роста:
Рост никак не оправдан, новых и полезных фишек почти 0
Новых функций прибавилось много, но увеличение веса системы не соразмерно
Вес вполне оправдан, так и должно быть при такой массе нововведений!
Лично я склоняюсь к варианту 2. Свои ответы можете написать в комментариях!
Пошаговые инструкции сборки — больше не ад для техписов
Изначально система автоматической генерации документов требует значительных затрат. Если конфигураций оборудования всего несколько, то раздельные инструкции проще и быстрее написать вручную, чем создавать под них систему.
В нашем случае разработка самой системы динамической документации и подготовка контента для первых четырех продуктов в ней заняли в сумме около 1300 человеко-часов. Этот самый тяжелый и затратный этап включал изменение логики, наполнение и отладку системы и согласование изменений с технологами.
На данный момент мы собрали из исходников документы для 647 конфигураций серверов. Даже при таком сравнительно небольшом количестве инструкций мы простым делением получаем затраты на один документ в размере 2 человеко-часов. Это в 12,5 раз дешевле, чем писать отдельные инструкции вручную — выше мы оценивали затраты такого подхода. В итоге с документацией справляются шесть человек — а если бы мы делали инструкции вручную, потребовалось бы не меньше 13 сотрудников. После внедрения конструктора мы оценили дальнейшие трудозатраты, продолжили работу с динамической документацией, и уже через несколько месяцев система начала окупаться.
Глеб Свистунов, руководитель отдела производственной документации YADRO, в своей статье рассказал о подходе динамической документации. С ним составлять пошаговые инструкции сборки оборудования для огромного количества конфигураций гораздо эффективней, чем вручную.
Откровения евангелистов БЯМ (LLM) для целей софтостроения генерируются публикуются с высокой скоростью. Не только на хабре, LinkedIn заполнен ими "под завязку". Прочитывать всё невозможно, да и не нужно, но некоторый тренд в изложении присутствует.
К сожалению, авторы много пишут о процессе, забывая собственно цели. Упоминание о функциональной сложности программы, как правило, отсутствует. Длина описаний процесса может создать ложное впечатление о развесистой функциональности, хотя большинство примеров находятся на уровне "записная книжка". В этом нет ничего плохого, просто не забываем, что 30 лет назад RAD типа Delphi умели создавать такие же "книжки" без написания кода вообще: достаточно было "накидать" компонентов на форму, настроить, связать их, и нажать "Run".
Накидали, и что дальше?
За словами "писать на близком к естественному языку", скрывается постепенное создание быстро растущего "промпта" - детальной спецификации, местами - псевдокода. Как следствие, необходимо иметь версии таких "исходников", как и раньше для кода (об этом практически не пишут). Для сторонних пакетов, API служб и прочих зависимостей не забываем указывать версии. По сравнению с таким "псевдокодом" техзадание может показаться увлекательной беллетристикой. Речь идет по сути о конечных спецификациях, ведь программирование - не столько кодирование (от силы 20% времени), сколько детальное проектирование и стабилизация.
Размер спецификаций псевдокода вкупе с описаниями контекста среды могут превзойти собственно размеры генерируемого кода, написанного программистом на формальном ЯВУ. Спецификации придется так же хранить в Git, и нервно просматривать, что же изменилось в сценариях, почему, ***, вместо слова "опять" кто-то написал "снова".
Для детерминированности процесса желательно, чтобы моделька была в том же состоянии, что и на предыдущем этапе генерации, но для внешних БЯМ-сервисов это недостижимо. Напомню, что компиляторы и классические генераторы кода (CASE, MDD) - детерминированные.
На первый план выходят тесты, их нужно писать "больше и лучше", потому что под капотом теперь только "черный ящик", "белого" больше нет. Тесты нужно постоянно обновлять в зависимости от объема изменений. Если ваши новые спецификации меняют 20% существующей кодовой базы, то тестов придется менять вдвое больше, принимая 2:1 за стандартное соотношение тестов к коду. Для языков без статической типизации тестирование еще более усложняется.
В реальных проектах написание сотен строк в день - это режим стартапа, причем на "нулевом цикле". Достаточно быстро программист приходит к естественной норме десятков строк в день, остальное время занимает понимание текущего потока проблем, поиск ошибок, интеграция и стабилизация. Хороший программист минимизирует объем порождаемого кода. Нужно ли включать БЯМ для написания 50 строк в день - вопрос.
В процессе не предусмотрена роль юниоров. Перспектива - "уйти со сцены", не воспитав смены, достаточно сомнительная для бизнеса и весьма печальная в личном плане.
Напоследок накину немного философского. Евангелисты любят упоминать, что человеческий мозг и БЯМы работают на одних и тех же принципах. Часто выясняется, что курса "Аналоговые ЭВМ" на их потоке уже не было, что несколько удручает. Еще более простой вопрос на примере несуществующей (пока?) телепортации: "Человек на входе телепортера и на выходе - это одна и та же личность?"
Пройдите наш тест и узнайте правду: вы — гуру бизнес-анализа или просто мастер красивых диаграмм?
Что вас ждёт:
✔️ 10 вопросов о работе с требованиями, декомпозиции задач, анализе данных и коммуникации с заказчиками и командой.
✔️ Честный вердикт на каком уровне находитесь: Junior, Middle или Senior.
✔️ Полезный бонус — бесплатный чек-лист лист «Как разбить работу бизнес-аналитика на задачи», который поможет структурировать проекты и избежать ошибок в планировании.
Готовы проверить себя?Переходите по ссылке и узнайте, какие области стоит прокачать для профессионального роста.
P.S. Чек-лист работает, даже если тест выявил, что ваша суперсила — это крепкий кофе и удалёнка.
Клиент: Сколько страниц будет входить в аудит? Я: Неизвестно. Почему неизвестно? Потому что у меня нет цели написать определённый объём правок и замечаний. Сколько их увижу — столько и зафиксирую. Если бы я проаудировал систему и не нашёл в ней ни одной проблемы — размер документа не превышал бы одной страницы.
Тут сразу пара моментов, которые хотел бы подсветить.
Я раньше, когда работал над документацией, считал, что «чем объёмнее — тем лучше». Это ещё со школы и универа. Реферат должен быть на пять листов. Эссе на семь. Доклад на три.
Акцент был на форме, а не на содержании. И это ужасно. В начале двухтысячных, когда работал в компании Webmaster.Spb проектировщиком, клиентам нравились толстые ТЗ. Точнее, представителям клиентов. Менеджерам. Сами-то клиенты эти ТЗ не читали, насколько мне известно.
Из строительной тематики тоже была клёвая байка, которую мне рассказал один из клиентов: «Я однажды сдаю своему шефу пачку документации высотой в два сантиметра. А он смотрит на неё и пальцами показывает три сантиметра. Вот столько, говорит, надо. Возвращайся, когда будет пачка высотой в три сантиметра».
Это первый момент. А второй — если во главе стоит форма, а не содержание, то это сродни проектированию главной страницы сайта, когда всё остальное ещё не готово. Спроектировал главную за час, а потом пятьдесят часов подгоняешь остальные сто страниц под неё. Вместо того, чтобы сделать всё без ограничений, а главную рисовать уже в самом конце, когда весь проект будет понятен. В виде вишенки на торте.
Иногда ещё, знаете, решишь написать статью. И придумываешь ей заголовок «пять ошибок начинающих проектировщиков». И вот четыре ошибки легко расписал, а пятую никак придумать не можешь. И сидишь, мучаешься, тратишь время. А мог сначала статью написать, ограничившись четырьмя ошибками, а затем уже заголовок придумывать.
Прикиньте, кто-то сначала бы придумал тематику: пять начал (законов) термодинамики. И после четвёртого сидел бы и страдал.
Возвращаясь к моим аудитам: у меня нет задачи найти конкретное количество косяков. Задача — проверить, достигают ли пользователи интерфейса своих целей. Если достигают — и отлично! Радоваться надо, что в моём документе будет одна строчка текста («Всё идеально, красавчики»). Это как на чек-ап пойти ко врачу и переживать, что ничего не нашли.
К сожалению, на практике такого ещё ни разу не было. Всегда что-то нахожу.
П.С. Представляете, я бы сказал, например: «Четыре страницы». Сделал бы аудит и нашёл бы ошибок на две страницы. И что бы делал? То же, что в школе и универе? (здесь должна быть какая-нибудь эмодзи с льющейся бессмысленной водой)
Хочу поделиться с вами видением хорошей архитектуры Go проекта, к которой я пришёл на данный момент и также интересно послушать ваши варианты и мнения по данному поводу.
Моё видение:
У нас ядро приложения это сервисный слой (юзкейсы), именно ядро самая основная часть приложения, которая взаимодействует с какой‑то логикой.
Если логика основана на внешних компонентах, то для связи ядра с компонентом(адаптер) и обратно используются абстракции в виде интерфейса(порт). При этом неважно какая связь (от ядра к компоненту или наоборот), внешние компоненты реализуют интерфейсы ядра и не содержат бизнес‑логики, они лишь преобразуют данные к форматам, понятным ядру (интерфейсы также основаны на моделях ядра).
Так как мы не хотим, чтобы логика из ядра уходила во внешние компоненты (по моему мнению, это повлечет переплетение зависимостей и нарушение принципов разделения ответственности), то вся логика должна выполняться на уровне ядра (например, вместо default значений полей в базе, мы создаём модель на уровне ядра, а база служит лишь в качестве хранилища, не выполняя какой‑либо бизнес логики). То есть бизнес‑валидация (инварианты агрегатов) остаётся в ядре, а адаптеры проводят schema‑валидацию (обязательные поля и форматы) до передачи в юзкейсы, тем самым мы избегаем лишних вызовов ядра (при некорректных данных), и не засоряя само ядро валидацией (отличным примером служит то, когда HTTP адаптер валидирует модель до передачи её в юзкейсы).
При этом всё, самое лучше место для интерфейсов (портов) будет отдельный пакет в ядре, к которому могут иметь доступ адаптеры, чтобы проверить реализации контракта (при это адаптеры будут "знать" лишь интерфейсы, а не весь сервисный слой, если бы порты хранились бы в месте использования), а также сами сервисы могут спокойно ссылаться на данные интерфейсы, не подтягивая их с адаптеров (в том случае, если бы мы хранили интерфейсы по месту имплементации).
То есть я считаю идеальной архитектурой для большинства Go проектов, работающих на основании адаптеров (к примеру, REST или gRPC сервис) гексагональную архитектуру с включением подхода DDD.
У меня остались также холиварные вопросы к вам. Как считаете:
Передавать в юзкейсы структуру или поля по отдельности?
Должно ли хранилище, в виде БД например, иметь валидацию данных? Операции по крону? Дефолтные значения полей?
Транзакции: где их начинать/заканчивать?
Когда и где вводить versioning: в HTTP‑уровне, в домене (разные агрегаты) или в репозиториях (Multi‑tenant)?
Должны ли доменные ошибки возвращать rich‑error (с кодом/контекстом) или достаточно обычных error с текстом?
Если у вас в приоритете — опыт работы над масштабным продуктом и строчка в резюме, с ходу впечатляющая HR-ов… Другими словами, если в ваши карьерные планы входит работа в крупной технологической компании — значит, мы придумали этот тест для вас.
Он поможет сориентироваться: проверить хард- и софтскилы и понять, какие навыки уже на высоком уровне — а что стоит прокачать, чтобы повысить шансы оказаться в бигтехе.
Тест вам подходит, если:
Ваша специальность — разработчик, DevOps-инженер, аналитик данных или ручной тестировщик.
Ваш грейд — джун+ и выше. Нужна теоретическая база, коммерческий опыт или опыт решения учебных проектов на реальных кейсах.
Чтобы давать релевантные задачи, мы консультировались с нанимающими менеджерами Яндекса — они знают, чего ждут от соискателей в больших технологических компаниях.
Кэширование: как работает, обновляется и очищается кэш⁉️
Кэш – быстрый временный буфер для хранения данных. Его цель – ускорить доступ к информации и снизить нагрузку на основное хранилище или систему
Варианты кэширования:
1️⃣Cache Aside. Читаем из кэша. Если нет, то читаем из БД и кладём в кэш 2️⃣Read Through. Запрос идёт в кэш, при необходимости обновляет данные из БД 3️⃣Write Through. При записи сразу обновляем кэш и БД 4️⃣Write Behind. Сначала пишем в кэш, позже – в БД 5️⃣Refresh Ahead. Кэш обновляется заранее, до истечения срока жизни
Алгоритмы обновления кэша:
1️⃣TTL (Time To Live). Данные удаляются по таймеру 2️⃣По записи. Кэш обновляется автоматически при изменении данных 3️⃣По запросу (manual invalidation). Кэш сбрасывается вручную 4️⃣Прогрев (pre-warming). Кэш заполняется заранее 5️⃣По расписанию (scheduled refresh). Кеш обновляется по расписанию
Алгоритмы вытеснения (eviction):
1️⃣LRU (Least Recently Used). Удаляем самый давно неиспользуемый элемент 2️⃣FIFO (First In, First Out). Удаляем самый старый элемент 3️⃣LFU (Least Frequently Used). Удаляем наименее используемый элемент 4️⃣Random. Удаляем случайный элемент
А ещё у меня в боте можно скачать бесплатный методический материал, где ты найдешь шаблоны пяти основных диаграмм на PlantUML в практических кейсах с описанием.
Как правильно организовать бизнес-архитектуру компании? На бесплатном вебинаре «Что такое бизнес-архитектура. От определения к управлению» разберемся, что именно входит в понятие бизнес-архитектуры икак эффективно с ней работать. Рассмотрим объекты управления и их взаимосвязи, а также ключевые правила и принципы.
📅 Дата: 26.06.2025
⏰ Время: 18:00-19:00 (Мск)
На вебинаре:
✔️ Понятие объекта управления
✔️ Примеры объектов управления
✔️ Целевое состояние объектов управления
✔️ Пример мета-модели финансовой организации
✔️ Архитектура, как взаимосвязь объектов
✔️ Управление изменениями, как основная задача управления архитектурой
👨🎓 Спикер: Коптелов Андрей — эксперт в области бизнес-анализа, управления проектами и процессами.
Присоединяйтесь к нам, чтобы узнать, как эффективно управлять бизнес-архитектурой, связывая бизнес-цели с ИТ!
Ловите возможность узнать лучшие практики по подготовке и получению сертификации по TOGAF Enterprise Architecture Foundation в 2025 году.
Вебинар предназначен для всех, кто хочет познакомиться с актуальной версией самого популярного фреймворка по управлению корпоративной архитектурой TOGAF.
Ведущий вебинара, бизнес-тренер Олег Бурко, сдал экзамен на сертификат TOGAF Enterprise Architecture Foundation в 2025 году и поделится лучшими практиками как по подготовке к сертификации, так и по изучению TOGAF 10.
📅 Дата: 24.06.2025
⏰ Время: 16:00-17:00 (Мск)
На вебинаре:
✔️ Фреймворк по управлению корпоративной архитектурой TOGAF
✔️ Что нового в TOGAF 10
✔️ Какую сертификацию по TOGAF выбрать
✔️ Как подготовиться и успешно получить сертификат TOGAF Enterprise Architecture Foundation
В моем канале IT Talks можно скачать бесплатный методический материал, где ты найдешь шаблоны пяти основных диаграмм на PlantUML в практических кейсах с описанием.
Для каждого шаблона подробно описан процесс, для которого построена диаграмма, а также есть сама диаграмма и исходный код на PlantUML. В гайде можно найти диаграмму активности, последовательности, прецедентов, состояний и компонентов.
Как интеграция SRM-системы и портала поставщика сокращает цикл закупки на 23%
Эксперты расскажут, как интеграция ELMA365 «Закупки для работы с поставщиками» и «Портала поставщика» на базе «Бустрейд» позволит сократить цикл сделки и повысить эффективность закупочных процессов.
Российский бизнес тратит на закупки до 65% от выручки и до нескольких недель времени из-за ручных согласований участников процесса. Коммуникация с поставщиками в закупках часто не систематизирована: заказы в почте и чатах теряются, дублируются, требуют ручной обработки. Ручной сбор КП и подбор позиций отнимает время, приводит к ошибкам и недопониманию. А не унифицированные процессы провоцируют потерю ресурсов компании.
На партнерском вебинаре эксперты «КОРУС Консалтинг» и ELMA365 Закупки расскажут, как интеграция «Портала поставщика» на базе «Бустрейд» и SRM-системы помогает ускорить закупочный цикл на 23% и сделать его одновременно выгодным для бизнеса и удобным для контрагентов.
На встрече обсудим: ✔️ Тренды рынка. Что происходит с закупками в России и почему автоматизация — стратегическая необходимость; ✔️ Кейсы из практики. Как компании сокращают закупочные циклы и добиваются прозрачности в работе с поставщиками; ✔️ Демо-интеграции. Сквозной процесс: как «Портал поставщика» на базе платформы «Бустрейд» и ELMA365 Закупки автоматизируют весь цикл — от сбора потребностей до взаиморасчетов. ✔️ Сессия Q&A + бонус. Отвечаем на ваши вопросы и дарим участникам полезный материал
Кому будет полезно: Директорам и руководителям отделов по закупкам Специалистам по закупкам Коммерческим директорам Директорам по цифровой трансформации и CIO Бизнес-аналитикам и руководителям по автоматизации
Что получите на вебинаре: ✔️ Понимание рыночных трендов в сфере закупок ✔️ Реальные кейсы компаний ✔️ Понимание, как автоматизация может оптимизировать ваши закупки с помощью демо-презентации ✔️ Ответы на вопросы, разбор типичных ошибок и первый шаг к действию
Pull/Merge Request для согласования требований и документации
Аналитики и технические писатели, признайтесь: сколько раз вы теряли время, сравнивая версии документов в MS Word? Компьютер тормозит, красные и синие правки сливаются в кашу, а поиск согласования в бесконечной переписке или Confluence превращается в квест.
Есть решение — берем механизм Pull/Merge Request и применяем его к текстам! Что получаем:
Все правки в одном месте. Редактируйте несколько документов сразу и смотрите изменения в едином окне. Забудьте про переключение между файлами и версиями!
Подробная подсветка. Все правки видны построчно или в удобном визуальном редакторе — сразу ясно, что добавили, убрали или исправили.
Простое согласование. Назначайте проверяющих и получайте их апрувы прямо в интерфейсе. Никаких "ок" в письмах или мессенджерах!
Полная история. Все комментарии, согласования и версии сохраняются. В любой момент можно вернуться и проверить, кто, что и когда утвердил.
Экономия времени. Gramax объединяет редактирование, ревью и согласование в одном месте — больше не нужно жонглировать Word, Confluence и почтой.
И все это в Gramax! Как всегда: бесплатно и с открытым исходным кодом. Все как в коде, только проще.
Тест на собеседовании на должность проектировщика интерфейсов
Ставим перед соискателем большую коробку с конструктором типа Лего. Задача: собрать его за час. А дальше наблюдать.
В коробке должно быть шесть пакетов и инструкция по сборке. В инструкции должно быть указано, что для успешной сборки понадобится семь пакетов. Если соискатель заметит это перед тем, как распечатает первый пакет, и укажет на невыполнимость задачи — он молодец.
Конструктор должно быть физически невозможно собрать за час. Первый пакет должен занимать в среднем пятнадцать минут, а остальные пакеты должны быть примерно такого же объёма и сложности и это должно быть заметно. Если соискатель, собрав первый пакет за пятнадцать минут, укажет на невыполнимость задачи — он молодец.
Это бы отсеяло тех кандидатов, которые готовы браться за работу, не разобравшись с задачей и её выполнимостью. В нашей профессии такой подход чреват лавинообразными правками после бесполезной работы, а также быстрым выгоранием.
К сожалению, этот тест — плод моей фантазии развлекательного характера. Представляете, сколько это мороки — подготавливать и упаковывать в пакеты подобные наборы для каждого нового соискателя? Не, проще пообщаться. Но идея не даёт мне покоя :)
А вот ещё один теоретический способ, с помощью которого я бы проверял квалификацию соискателей. Там про цепляние к мелочам.
Что нового мы добавили в open source-платформу для управления технической документацией Gramax.
ИИ-поиск для портала документации. Раньше поиск по документации был ограничен точным совпадением слов, теперь можно подключить ИИ-поиск от любого провайдера (например, OpenAI, Anthropic и др.) и искать по смыслу. Даже при неточном запросе пользователь получит релевантные результаты. Поддерживается как облачное подключение, так и запуск собственного сервера — для тех, кому важна приватность.
ИИ для создания и редактирования текста. В пространстве редактора можно также подключить ИИ. Он позволит написать текст с нуля: например, если не удается придумать структуру статьи. А также отформатировать существующий текст. В случаях, если его нужно сократить, сделать более формальным или структурированным.
Шаблоны. Добавили возможность создавать шаблоны со свойствами и использовать их в статьях.
Заметки. Теперь можно прямо в каталоге сохранять идеи и предложения для изменения документации. Заметки сохраняются в репозитории, но не отображаются на портале для чтения.
Расширенный редактор сниппетов. Теперь сниппеты можно оформлять как и обычную статью без ограничений.
Выбор формата для исходных файлов. Добавили 2 дополнительных формата хранения статей — XML и GitHub Flavored Markdown. Изменить формат можно в настройках каталога.
Вход для внешних пользователей в Gramax Enterprise Server. Добавили возможность настроить вход на портал для чтения по почте: таким читателям не нужно иметь учетную запись в SSO. Достаточно указать свою почту при входе и ввести одноразовый код.
Разберём, что собой представляет архитектура приложений, а также какие задачи она решает и какие ограничения накладывает на разработку. Также детально обсудим три ключевых принципа для фронтенда, включая методологии Solid и Grasp, которые помогут вам создать более эффективные и масштабируемые проекты.
📅 Дата: 05.06.2025
⏰ Время: 17:00-19:00 (Мск)
Содержание:
✔️ Архитектура
✔️ Solid
✔️ Grasp
👨🎓 Спикер: Щербаков Александр — эксперт в области фронтенд-разработки.
19 июня наше SA-сообщество проведёт четвёртый Alfa Analyze IT Meetup — поговорим о том, как оценивать навыки по матрицам компетенций, принимать решения о повышении и адаптироваться к изменениям от ИИ.
Вы поймёте, как тимлиды ищут таланты внутри команд и выстраивают карьерные треки, а также получите готовые инструменты для оценки и развития аналитиков.
В программе:
процесс ассессмента для аналитиков в Альфа-Банке,
выстраивание и развитие матрицы компетенций системного аналитика Газпромбанк.Тех в эпоху цифровой трансформации,
развитие системных аналитиков в X5 Tech: от внутреннего поиска до повышения с опорой на матрицу компетенций,
архитектура DWH в Яндекс Go: технологии, подходы, матрица компетенций.
Присоединяйтесь онлайн и офлайн — зарегистрироваться можно по ссылке.
Где: Офис Альфа-Банка по адресу Москва, Андропова пр-т., 18 к.3, в трёх минутах пешком от метро «Технопарк».
Делюсь с Вами разработанным мною шаблоном, для описания таблицы БД в PlantUML, c элементами автоматизации, описание которых указанно в комментариях.
Всем привет! Делюсь с Вами разработанным мною шаблоном, для описания таблицы БД в PlantUML, c элементами автоматизации, описание которых указанно в комментариях.
