Angular: The Documentary | An origin story (Рубрика #Engineering)

Посмотрел интересный документальный фильм про создание и развитие фронтового фреймворка Angular. Этот фильм интересно посмотреть даже если вам не интересна история фронтовых фреймворков (кстати, про react тоже есть документалка и я уже про нее рассказывал). Фильм рассказывает как Angular родился как внутренний эксперимент в Google, который поначалу отмахнули большие команды (Gmail и Maps), а затем стал массовым фреймворком и прошёл через болезненную «вторую жизнь» (Angular 2+). А теперь чуть

1. Как Angular появился внутри Google (локальная инициатива)
Старт проекту дала команда, работавшая над Google Feedback. Она утонула в 17 000 строк фронтенда и низкой тестопригодности. Тогда Ми́шко Хевери предложил дерзкий ход: переписать всё за две недели своим хобби‑проектом (GetAngular/AngularJS). Вышло за три, но код сжался до ~1 500 строк, и это стало моментом истины — менеджмент увидел в подходе ценность и дал зелёный свет на развитие. В общем, видно, что Angular родился не как глобальная инциатива "сверху-вниз", а скорее как локальная инженерная идея, доказавшаяся прототипом лечение реальной боли команды.
2. Борьба за ресурсы и «нет» по дороге
На старте AngularJS не получал аппрув от флагманов внутри Google - многие говорили что-то в стиле "хорошая игрушка, удачи". Поддержка пришла после демонстрации драматической экономии сложности/кода и скорости разработки. Сначала - маленькая команда, много скепсиса, мало ресурсов; дальше - органический рост вокруг первых успешных внедрений. Итого, в большой компании лучше один раз радикально показать ценность на рабочем кейсе, чем долго убеждать словами.
3. Как в Angular появился Dart и почему далее произошёл «раскол» AngularJS и Angular
Следующей развилкой стала производительность, статанализ и tree‑shaking. Внутри Google к этому моменту крепки были позиции Dart (с его dart2js и агрессивным tree‑shaking), а команда Angular экспериментировала между JS, AtScript и Dart. В итоге Google и Microsoft сошлись на TypeScript: ключевые идеи AtScript попали в TS 1.5, а Angular 2 строили уже на TypeScript, параллельно поддерживая AngularDart для крупных внутренних продуктов (Ads/AdSense). Это и закрепило исторический «раскол»: AngularJS (1.x) и Angular (2+) — два разных мира. В итоге, видно, что Dart повлиял на выделение дополнительных ресурсов, архитектуру фреймворка и компиляцию (статичность, AOT, tree‑shaking), но "языковая ставка" в открытой экосистеме ушла в сторону TypeScript.
4. Большие миграции
У Angular было две ключевые миграции:
- Архитектурный разрыв AngularJS → Angular (2+) - без обратной совместимости. Перепроектирование ради мобильности, модульности, типизации и будущей компиляции. Это самая болезненная точка истории.
- Смена движка рендера на Ivy (Angular 9) - уже внутренняя замена View Engine на новый компилятор/рендерер, специально спроектированный под мелкогранулярный tree‑shaking и меньшие бандлы. Переход стал дефолтом в v9 и принёс ощутимую экономию размера без переписывания приложений с нуля.
Обе миграции были болезненны, но кажется, что необходимы.
5. Как Angular чувствует себя сейчас и планы
Angular снова на подъёме: зрелая реактивность (Signals), сильный SSR/гидрация, фокус на DX и производительности, аккуратные мажоры без «лома мира». А Google планирует переносить фичи Wiz (внутреннего фреймворка внутри Google) в публичный Angular. Акутальная дорожная карта есть на angular.dev/roadmap.

В общем, документалка показалась мне интересной как техническому руководителю и инженеру - из этой истории можно извлечь много полезных уроков о том, как создавать и развивать крупные проекты.

#Software #SoftwareDevelopment #Architecture #Engineering #Management #OpenSource

Эволюция метрик и практика применения SPACE (Рубрика #DevEx)

Мои коллеги Саша Кусургашев и Дима Гаевский на IT Пикнике летом рассказывали про то, как мы используем фреймворк SPACE для оценки продуктивности инженеров. Недавно появилась запись выступления Саши (который отдувался за двоих) и я решил поделится кратким саммари этого рассказа.

Если уложить это саммари в одну мысль, то она примерно такая "инженеров нельзя адекватно оценить одной цифрой или простым количественным показателем" - хотя часто это пытались сделать (например, число коммитов, строк кода, выполненных задач), но каждая такая метрика отражает лишь одну сторону дела и сильно зависит от контекста. Например, большое число изменений в коде может свидетельствовать как о высоком темпе команды, так и о переработках или неэффективном процессе – без контекста такие цифры вводят в заблуждение. Ребята привели в докладе кучу примеров того, как приходится учитывать множество граней эффективности: скорость работы, качество результата, командное взаимодействие, удовлетворённость сотрудников и другие факторы.

Собственно, первая половина доклада была про сам фреймворк "SPACE", где рассказ строился на статье "The SPACE of Developer Productivity", о которой я уже рассказывал раньше. Сам акроним SPACE расшифровывается как
- Satisfaction & Well being (удовлетворённость)
- Performance (результативность)
- Activity (активность)
- Communication & Collaboration (коммуникация)
- Efficiency (эффективность)
Каждое из этих измерений дополняет остальные, создавая целостную картину. В выступлении отмечалось, что такой многомерный подход родился как реакция на злоупотребления однобокими метриками и нацелена на то, чтобы сделать оценку работы инженеров более справедливой и осмысленной.

Вторая часть доклада была посвящена опыту внедрения SPACE и мне она кажется самой полезной частью выступления. Саша рассказал с чего начать сбор метрик и как интерпретировать.Внедрение многомерной системы измерений оказалось непростой задачей – потребовалось агрегировать данные из разных источников (систем контроля версий, трекеров задач, CI/CD, опросов сотрудников и пр.) и привести их к единой основе для сравнения. Авторы подчеркнули важность нормализации данных и правильных «разрезов» – нужно решать, по каким сечениям анализировать метрики (по командам, по проектам, по временным периодам), чтобы выявлять закономерности и проблемные зоны. Это оказалось нетривиально: разные сегменты показывали разную картину, и неправильный выбор среза мог скрыть проблему или создать иллюзию успеха. Например, сравнение по командам требует учёта специфики проектов; сравнение по времени – учёта сезонности и изменений обстоятельств.

Круто, что ребята честно поделились ошибками первого подхода к SPACE. Поначалу они старались измерить «всё и сразу» и получить мгновенный интегральный показатель. Это привело к избытку данных и трудностям в их понимании. Как итог - не стоит пытаться охватить сразу все метрики без приоритизации. Вместо этого лучше выбрать несколько метрик по ключевым измерениям, которые наиболее актуальны для текущих проблем команды, и начать с них. Важно «не перегнуть палку и не утонуть в данных», а подбирать метрики под свой контекст. Постепенно, когда культура работы с метриками начала формироваться, они расширяли охват SPACE-факторов, но уже осознанно и с учётом полученных инсайтов.

Из выступления можно забрать такие мысли
1) Комбинируйте объективные метрики с обратной связью от людей
2) Используйте метрики как инструмент для улучшения, а не для наказания. Стоит выявлять узкие места и точки роста, а не устраивать «соревнование разработчиков» или повышать бюрократию
3) Вводите метрики постепенно и осмысленно. Начать с пилотной команды или направления, выбрать небольшое подмножество SPACE-метрик, относящихся к наиболее болезненной проблеме, и опробовать их в деле
4) Важна роль культуры и поддержки руководства. Внедрение SPACE – это не разовая акция, а изменение подхода к управлению

#Processes #Management #ExternalReview #ProductManagement #Leadership #SoftwareDevelopment #Software #SRE

Vite: The Documentary (Рубрика #Frontend)

На прошлой неделе вышел документальный фильм про Vite или как один побочный проект Эвана Ю (автора Vue.js) за несколько лет изменил весь фронтенд. Начать стоит с того, а почему Vite так важен. Он появился в ответ на то, что Webpack стал слишком медленным и громоздким. В этот момент Эван Ю, автор Vue.js пытался улушить DevEx инженеров, что писали на Vue и он попробовал радикально другой подход: запускать dev-сервер без бандлинга, отдавая модули прямо в браузер через ESModules. Так появился Vite - инструмент, который:
- Стартует почти мгновенно;
- Обновляет код без перезагрузки страницы (hot module replacement, HMR);
- Компилирует зависимости через esbuild и Rollup, обеспечивая скорость на уровне Rust-решений.

В начале фильма звучит фраза «если вы пишете на современном JS-фреймворке, вы, скорее всего, используете Vite» и это уже не преувеличение. На нем работают Vue, SvelteKit, Nuxt, Astro, Remix, Qwik, Laravel, Shopify Hydrogen и десятки других фреймворков. Авторы фильма рассказывают про таймлайн развития технологии, который выглядит примерно так
- 2020 - Первая версия как dev-сервер для Vue.
- 2021 - Vite 2.0 — мультифреймворк, переход SvelteKit и Laravel.
- 2022 - Экосистема взрывается: ViteConf, Vitest, интеграции с Nuxt 3 и Astro.
- 2023 - Remix и RedwoodJS переходят на Vite; анонс Rust-бандлера Rolldown.
- 2024 - Основана компания VoidZero; Vite 6.0, 17 млн скачиваний в неделю.
- 2025 - Премьера фильма и планы на Rust-реализацию всего стека.

Ключевые факторы DevEx, за которые инженеры полюбили Vite
- Скорость: дев-сервер стартует за секунды, HMR - почти мгновенный.
- Простота: минимальная конфигурация и плагинная архитектура.
- Расширяемость: единая база для React, Vue, Svelte, Qwik и др.
- Интеграции: тестирование (Vitest), Storybook, E2E (Cypress, Playwright), Laravel, Rails.
- Сообщество: 850+ контрибьюторов, десятки компаний (Google, Shopify, Cloudflare, NASA, OpenAI).

Но Vite не стоит на месте и окмпания VoidZero уже пишет на Rust собственные инструменты:
- Rolldown - замена Rollup внутри Vite;
- Oxc - быстрый парсер и линтер;
- Есть планы на «Vite +» - единый стек для сборки, тестирования и форматирования.
- Есть движение в сторону AI - на ViteConf 2025 уже обсуждали агентов, помогающих создавать приложения на Vite.

Фильм получился не только про технологию, но и про сообщество: как инженерный «побочный проект» стал точкой объединения фронтенда.

Раньше я уже рассказывал про другие документальные фильмы из этой же серии и могу рекомендовать их любителям технологий и историй про их создание и развитие.
- Kubernetes Documentary
- eBPF Documentary
- Inside Envoy
- GraphQL: The Documentary
- Node.js Documentary
- Python: The Documentary
- Ruby on Rails: The Documentary
- React.js: The Documentary
- Angular: The Documentary

#Software #Documentary #Engineering #Architecture #Management #SoftwareDevelopment

State of Devops Russia 2025 (Рубрика #Devops)

Несколько дней назад были опубликованы результаты большого опроса про состояние DevOps в России. Наступили выходные, я его дочитал и решил написать тезисный разбор. Кстати, если этот разбор понравится, то можно его сравнить с глобальным DORA отчетом за 2025 год, о котром я уже писал. Но вернемся к этому опросу

- Производительность команд выросла: суммарная доля высокоэффективных команд (профили Elite и High) увеличилась на 6% по сравнению с прошлым годом, и ключевые показатели эффективности (частота релизов, скорость доставки, время восстановления, процент неудачных изменений) улучшились. Напомню, что в стандартном подходе все компании бьются на 4 кластера: low, medium, high, elite на основе 4 метрик DORA (deployment frequency, lead time for changes, change failure rate, mean time to restore).
- DevEx дает эффект: у высокоэффективных команд налажены быстрые и качественные циклы обратной связи, ниже когнитивная нагрузка и выше автономность инженеров (подробнее про модель DevEx я уже писал)
- Гибридная модель потребления: оркестраторы рабочих нагрузок не используют только ~15% опрошенных, остальные предпочитают c отрывом K8s (~51% разворачивают его on-prem, ~25% гибридно, еще 25% в облаке или нескольких). Данные треть хранит on-prem, треть гибридно, а треть в облаке.
- Повышение использования IDP: внутренние платформы разработки превращаются в обязательный атрибут крупных компаний с активной разработкой. Более 45% респондентов уже используют IDP для управления доступами и поиска необходимой информации. Главная цель развития внутренних платформ на 2025 год – максимальная автоматизация рутинных задач. Крупный бизнес рассматривает IDP как способ унификации процессов разработки и усиления контроля безопасности
- Информационная безопасность стала приоритетом: большинство команд теперь интегрируют её в процессы разработки (77% используют инструменты ИБ)
- Инструменты AI получили массовое распространение: ~71% опрошенных говорят, что применяют AI/ML в работе (чаще всего для генерации кода), при этом более половины уже отмечают рост продуктивности благодаря AI
- Продолжается импортозамещение: растёт использование российских OS и K8s-дистрибутивов вместо зарубежных аналогов
- Ситуация на рынке труда для devops инженеров изменилось: hh-индекс конкуренции (отношение резюме к вакансиям) вырос с 7,7 до 14,9 за год, то есть на одну позицию претендует больше инженеров

Исследование State of DevOps Russia 2025 проведено командой «Экспресс 42» (консалтинговое подразделение компании Flant) и стало пятым ежегодным отчётом о развитии DevOps в России. В опросе участвовало более 3300 специалистов из России и стран СНГ. Респонденты представляли широкий спектр отраслей и ролей в ИТ - среди них были как инженеры и DevOps-специалисты, так и руководители разных уровней из крупных, средних и небольших компаний. В общем, результаты можно с достаточной уверенностью считать репрезентативными для оценки текущего состояния DevOps практик.

#Processes #Management #Performance #Engineering #Software #SoftwareDevelopment

Postcriptum State of Devops Russia 2025 (Рубрика #Devops)

Отдельно поделюсь заключительной частью этого отчета, в которой приведена цитата Димы Гаевского, моего друга и коллеги, который у нас отвечает за развитие нашей внутренней платформы разработки.

Российский рынок ПО продолжает идти своим, местами парадоксальным путём: с одной стороны — жёсткое внешнее давление, с другой — необратимое взросление ИТ-ландшафта. В XL-сегменте тренд на интеграцию AI в производственные конвейеры только усилился. «Бигтехи» уже отстроили безопасные внутренние платформы, а теперь метят в AIOps и GenAI-копилотов, выжимая из DevOps максимум продуктивности. Но важно помнить, что даже крупнейшие игроки по-прежнему остаются «догоняющими» по
сравнению с США и Китаем — разрыв бюджетов и доступ к современным GPU остаются вопросом как минимум ближайших двух лет.

Средние и мелкие компании, пережившие кадровую турбулентность 2022 года, решали задачи автономно и почти поголовно выбрали проверенный OSS-стек — GitLab, Ansible, ELK, Kubernetes. Это был единственный рациональный путь на фоне дефицита зрелых российских предложений и высокой технологической неопределённости. Теперь же, когда регуляторика импортозамещения ужесточилась (реестр ПО, квоты в госзакупках, совместимость с «Альт»/Astra), к этому стеку постепенно добавляются отечественные надстройки — от SCA-плагинов с ГОСТ-крипто до репозиториев кода типа GitFlic.

Безопасность стала отдельным фронтом: массовый self-hosting GitLab без выстроенных процессов патч-менеджмента законсервировал множество уязвимостей. Компании начинают вкладываться в SBOM и DevSecOps, чтобы закрыть регуляторный и репутационный риск. Одновременно растёт популярность FinOps: стоимость GPU-кластеров растёт быстрее, чем ROI по экспериментальным AI-проектам, и советы директоров всё чаще спрашивают не «сколько мы натренируем моделей», а «сколько рублей мы сэкономим».

Аппаратные ограничения ощутимы: top-tier NVIDIA/AMD по-прежнему под экспортным контролем, китайские ASIC — решение рабочее, но ставит потолок производительности. Это подталкивает XL-компании к «федеративным» альянсам: банки и ритейл делятся дообученными LLM, промпредприятия — моделями предиктивного обслуживания; государство выступает ранним якорным заказчиком и субсидирует разработки, но объёмы субсидий пока несравнимы с глобальными CAPEX.

Прогноз на ближайшие годы — без паники, но и без иллюзий. Крупные продолжат апстримить AI-инновации и строить FinOps-офисы, страхуя TCO. SMB останутся на OSS-ядре, однако вынужденно потратятся на DevSecOps и аутсорс-SOC. Консолидация усилий пойдёт в двух плоскостях: горизонтальные коалиции гигантов для обмена моделями и вертикальная «надстройка» отечественных решений над универсальным OSS. В результате рынок получит не «западный стек против российского», а гибрид «OSS-база + локальные специализированные модули», что, пожалуй, и есть самый реалистичный сценарий 2025 – 2027 годов.

#Processes #Management #Performance #Engineering #Software #SoftwareDevelopment

AI changes *Nothing* — Dax Raad, OpenCode (Рубрика #AI)

Посмотрел интересный доклад Dax Raad из OpenCode на конференции AI Engineer, где создатель популярного coding agent выступил с провокационным тезисом: несмотря на весь ажиотаж вокруг AI, фундаментальные вызовы построения успешного продукта остаются прежними. В общем, AI не решает волшебным способом те проблемы, что раньше требовалось решать для развития продуктов. Основных тезисов в выступлении всего три

1️⃣ Маркетинг - это про "крутость", а AI слишком корявый
Dax утверждает, что настоящий top-of-funnel маркетинг - это способность создать что-то, чем люди захотят поделиться. Это не стандартные блог-посты о релизах или оплаченные упоминания у инфлюенсеров. Вам нужно вызвать у пользователя такую реакцию, чтобы он захотел показать это коллегам или друзьям со словами "можете в это поверить?".​
Проблема в том, что AI инструменты генерации контента выдают слишком банальные и/или корявые результаты. Они не способны создать крутые штуки, которые цепляют эмоционально. Даже используя AI как brainstorming-партнёра, Dax не получил ни одной действительно хорошей идеи. Маркетинг требует креативности, а AI пока не может её обеспечить.​​ В итоге, лучше не поручать маркетинг AI, а придумывать идеи самим, чтобы иметь ненулевой нулевой шанс стать вирусными.​

2️⃣ Aha-момент: безжалостное устранение фрикций
Второй критический этап - это aha-момент: момент в journey пользователя, когда он наконец "понимает" ценность продукта. Вы должны определить единственный самый важный момент озарения и безжалостно устранить все препятствия на пути к нему.​​ Кстати, про это рассказывал Петр Савостин, мой коллега, что занимается у нас развитием мобильных продуктов для физических лиц. Суть в том, что на каждом лишнем шаге customer journey вы теряете 10-20% пользователей и до aha-момента часто большинство пользователей не добираются. В итоге, это не про то, чтобы сделать много фич, а про то, чтобы сделать вылизанные фичи, где пользователь сразу чувствует ценность. Например
- ChatGPT: пустое поле ввода, куда можно написать что угодно и получить человекоподобный ответ - мгновенное понимание ценности​
- Facebook (retention): добавление 7 друзей в первые 10 дней коррелировало с долгосрочным удержанием​
- Spotify: прослушивание 10 песен в первые 2 часа​

AI не помогает с решением этой проблемы - создание правильного aha-момента требует глубокого понимания problem space, позиционирования, ясности в том, что вы делаете уникально. Это требует куса, который не может быть делегирован алгоритму.

3️⃣ Retention: примитивы важнее фич
Здесь Dax развенчивает миф о том, что продукт может быть либо простым, либо мощным. На самом деле никакого trade-off нет - можно и нужно строить оба качества одновременно.​ Суть в том, чтобы не строить сложные фичи сходу, а в том, чтобы создавать deep primitives (глубокие примитивы), которые можно собрать в нужную функциональность. Сначала проектируете мощный, широкий слой примитивов, а затем собираете из них простой опыт для 99% пользователей. Когда пользователи становятся более продвинутыми, они получают прямой доступ к этим примитивам и могут настраивать продукт под себя, никогда его не перерастая.​

Но с этим не справляются AI инсутрменты, так как проектирование правильных примитивов - это процесс exploration. Чтобы даже объяснить AI, что вы хотите, нужно самому очень хорошо это понимать. Задача - понять проблему настолько глубоко, чтобы спроектировать правильный набор примитивов. AI здесь бесполезен.​​

В итоге, автор отмечает, что AI - это мощный инструмент для технической работы, но он не решает фундаментальных задач создания успешного продукта: маркетинга (креативность), onboarding (taste и фокус) и retention (архитектурное мышление). Технические лидеры должны продолжать инвестировать в человеческие навыки и не попадаться на иллюзию, что AI сделает крутые продукты автоматически. Hard work, хороший вкус, и человеческая изобретательность остаются необходимыми - и это хорошая новость.​​

#ProductManagement #Software #SoftwareDevelopment #AI #Engineering #Management #Leadership

[1/2] AI, DevOps, and Kubernetes: Kelsey Hightower on What's Next (Рубрика #PlatformEngineering)

Посмотрел интервью Келси Хайтауэра с командой JetBrains про состояние индустрии в 2025 году. Помню как лет 7 назад изучал Kubernetes по его репозиторию Kubernetes The Hard Way, который был не прост, но помог мне сдать лабы для получения шилдика CKA (Certified Kubernetes Administrator) первым в компании. Это было в те времена, когда мы с моим коллегой Стасом (гостем из первого выпуска подкаста Code of Leadership), Андреем (гостем 43 выпуска Code ...) и Антоном (гостем 17 выпуска Code ..) продумывали как будем переезжать в Kubernetes с виртуалок:)

Но если возвращаться к Келси, то он уже завершил активную карьеру в Google и теперь может философски размышлять про devops и не только. Я выделил 5 тем, что были интересны мне в этом обсуждении

1️⃣ DevOps: Эволюция или провал?
Келси критически оценивает то, во что превратился DevOps во многих компаниях.
- "Футболка вместо навыков": Многие компании просто переименовали системных администраторов в DevOps-инженеров, не изменив суть работы. "О, теперь я DevOps-инженер, дадут ли мне за это футболку?" — иронизирует Келси.
- Правильная имплементация: DevOps был задуман как "чертеж" (blueprint), предполагающий расширение компетенций. Сисадмины должны были научиться программировать, а разработчики - понимать, как работает операционная система (например, тюнить JVM под ядро Linux).
- Проблема опыта: Келси упоминает людей, у которых "20 лет опыта, состоящих из одного и того же года, повторенного 20 раз" (20 years of one-year experience). Это те, кто просто чинит серверы, не пытаясь автоматизировать или изменить подход.
- Platform Engineering: Это не что-то принципиально новое, а эволюция DevOps. Это переход от "я починю сервер, когда он сломается" к созданию продукта (платформы) для внутренних клиентов.

2️⃣ Kubernetes и «скучные» технологии
- Kubernetes - это скучно (и это хорошо): Для stateless (веб) приложений Kubernetes стал скучным еще 6-7 лет назад. Келси сравнивает инфраструктуру с полетом на самолете: "Самолеты интересны только тогда, когда они делают не то, что мы ожидаем. Если при посадке люди хлопают - значит, что-то пошло не так. Мы хотим просто выйти из самолета и не думать о полете".
- Инфраструктура не должна вызывать восторг: Если ваша инфраструктура вызывает у вас сильные эмоции, значит, вы боретесь с поломками или трением. Восторг должен вызывать продукт, который вы строите поверх неё.
- Будущее Kubernetes: Если через 20–30 лет мы всё еще будем обсуждать Kubernetes, это будет провалом индустрии. Мы должны придумать что-то лучшее. Kubernetes должен стать просто деталью реализации (как BIOS или машинный код), скрытой под более удобными абстракциями.

3️⃣ API, Silos (Колодцы) и взаимодействие команд
Келси делает контринтуитивное заявление: "Мне нравятся silos (изолированные команды)", но при наличии четкого API.
- Аналогия с авиабилетом: Когда вы летите в другую страну, вы не идете в кабину пилота обсуждать маршрут. Вы покупаете билет. Билет - это API (контракт). Вы садитесь в кресло, засыпаете и просыпаетесь в другом месте.
- API как контракт: Платформенная команда и разработчики не должны сидеть рядом и постоянно разговаривать. Они должны взаимодействовать через четкий контракт (API): "Мне нужно столько-то памяти, такой-то регион, такая-то версия".
- Когда нужно общение: Разговаривать нужно только тогда, когда вы хотите изменить API или добавить новую фичу в платформу. Для рутинного деплоя общение - это лишние накладные расходы.
Забавно, что примерно эти же моменты про взаимодествие команд мы разбирали со Стасом Халупом в первом выпуске Code of Leadership.

Оставшиеся темы про AI и важность soft skills обсудим в продолжении разбора этого крутого интервью.

#Management #Leadership #PlatformEngineering #Software #SoftwareDevelopment #Architecture #Processes

[2/2] AI, DevOps, and Kubernetes: Kelsey Hightower on What's Next (Рубрика #PlatformEngineering)

В продолжении разбора интервью Келси нужно упомянуть темы AI и важности soft skills

4️⃣ Искусственный интеллект (AI)
Хайтауэр скептичен к хайпу, но видит фундаментальную пользу.
- AI как новый DSL: Келси смеется над "Prompt Engineering", когда люди чекинят в git 500 markdown-файлов с промптами и версионируют их. По сути, мы изобрели еще один, очень нестабильный язык программирования.
- Недетерминированность: Всю карьеру инженеры боролись за предсказуемость (тесты, идемпотентность), а теперь мы внедряем AI, который по своей природе вероятностный ("Зачем гадать, если можно знать наверняка?").
- Главная польза AI: Он заставил вендоров и разработчиков наконец-то написать нормальные API и документацию, чтобы LLM могли с ними работать. То, что мы должны были сделать для людей (хорошие доки и интерфейсы), мы теперь делаем для роботов.
- Guardrails (Ограничения): В итоге все равно все сводится к созданию жестких рамок (guardrails), чтобы заставить AI выдавать предсказуемый, "скучный" результат.

5️⃣Развитие: Человек vs Инженер
В конце интервью фокус смещается на soft skills и личностный рост.
- Командный спорт: Келси сравнивает работу в IT с баскетболом или футболом, а не с легкой атлетикой. В беге ты побеждаешь или проигрываешь один. В IT, каким бы крутым инженером ты ни был, ты зависишь от команды.
- Эмпатия: Это не просто "быть милым". Это понимание того, что если разработчик боится деплоить в пятницу, проблема может быть не в его трусости, а в ненадежности платформы, которую вы построили.
- Профессионализм и «Ящик с инструментами»: Не будьте просто «коллекционером» инструментов. Профессионал регулярно перебирает свой ящик с инструментами (toolbox), чистит их и выбрасывает ненужные.
- Дисциплина важнее любопытства: В профессиональной среде нельзя тащить в продакшн Rust или новую технологию только потому, что вам "любопытно". Выбирайте инструменты, которые решают задачу бизнеса, а не тешают эго инженера.

#Management #Leadership #PlatformEngineering #Software #SoftwareDevelopment #Architecture #Processes

Two decades of Git: A conversation with creator Linus Torvalds (Рубрика #Software)

Интересный рассказ Линуса Торвальдаса о том, как 20 лет назад, в апреле 2005-го, Линус за 10 дней накатал первую версию Git. Он сделал это потому, что у разработчиков ядра Linux отобрали любимый инструмент (BitKeeper). Git родился из боли: CVS Линус терпеть не мог, SVN считал «тем же CVS». Он признаётся, что изначально писал Git "под себя", не парясь об удобстве для других.

Линус всего несколько месяцев сам поддерживал Git, а уже к осени 2005 передал бразды другому разработчику – Junio Hamano (он и по сей день мейнтейнер). Торвальдс вернулся к любимому детищу (ядру Linux), а Git зажил своей жизнью. Постепенно что-то переключилось в сообществе: через пару лет народ распробовал инструмент. Особенно помог приток молодых разработчиков, для которых Git стал первой системой контроля версий. Вместо возни с устаревшим CVS они с удовольствием юзали Git и удивлялись, почему раньше было иначе. В итоге Git взлетел и практически монополизировал рынок VCS – сейчас, по словам Линуса, порядка 98% проектов на нём. Даже дочь Торвальдса однажды сказала ему, что в университетской лабе его знают больше как автора Git, а не Linux 😅.

Ключевые идеи и фишки Git следующие

1️⃣ Распределённость
В Git нет главного репозитория, каждый клонированный репо - полноценный. Это не просто философия, а огромное практическое удобство: разработчик может работать локально без центрального сервера, а при надобности выложить код куда угодно (GitHub и появился благодаря этой идее). Как мне кажется, это local-first приложение by design.
2️⃣ Скорость и масштабируемость
Git проектировался под гигантский Linux-репозиторий, поэтому все операции (патчи, слияния) должны быть быстры. Линус шутит, что применить 100 патчей должно быть делом секунд – «не надо успевать пить кофе, пока ждёшь».
3️⃣ Надёжность данных
Каждый коммит и объект помечаются крипто-хешем (SHA-1): это больше про защиту от случайной порчи или ошибок, чем про безопасность. Такая проверка целостности на каждом шаге отличала Git от предыдущих систем (в BitKeeper, например, были слабее CRC/MD5 и не всё покрывали).
4️⃣ Простота ядра
В основе Git всего несколько концепций (объекты, индексы, ветки), за счёт этого первую версию удалось написать быстро и она до сих пор совместима (почти полностью) с нынешней. Всё сложное вынесено либо “наверх” (в командный интерфейс, скрипты), либо появилось позже.

Интересно, что Линус, вдохновляясь философией Unix, нарочно не копировал привычные команды CVS – делал по-своему, даже названия дал другие (commit-tree, index и т.д.), чем вызывал баталии на почтовых списках. Но он сознательно ломал устои: слишком уж его раздражали старые подходы, хотелось кардинально другой инструмент.

Вообще, история Git - это отличный пример, как разработчик решает свою проблему, а в результате меняет индустрию. Линус просто хотел продолжать разрабатывать ядро, не мучаясь с отвратительным инструментом, - и из этого родился Git, без которого сейчас не мыслят работу ни разработчики, ни тимлиды. Порой действительно стоит взять и сделать «как надо», даже если изначально продукт сырой и неудобный: если в основе заложены верные принципы, сообщество подтянется и доведёт до ума. Мы видим, как открытые инструменты побеждают закрытые (BitKeeper канул в лету, Git царит).

Торвальдс отмечает, что теперь вокруг Git выросла экосистема, которая решает проблемы, о которых он и не думал. Например, появились расширения для больших файлов и монорепозиториев (привет корпорациям) – изначально Git не планировался для этого, но жизнь заставила. Интересна его мысль о трекере задач/багов: сейчас у каждого хостинга своя система issues, и Линусу хочется единого открытого стандарта (чтобы не было привязки к конкретному сервису). Возможно, это намёк сообществу, где ещё есть простор для инноваций 😉.

#Management #Leadership #PlatformEngineering #Software #SoftwareDevelopment #Architecture #Processes