Книжный куб

От классического PDLC к AI-native разработке (Рубрика #ai4sdlc) Написал статью на Medium про то, как AI меняет не только скорость написания кода, а саму организацию инженерного труда. Мы постепенно движемся от SE 1.0 - процесса с ролями, стадиями и handoff’ами - к SE 2.0, где часть инженерной работы берут на себя AI-инструменты и агенты. Но это не бесплатное ускорение. Если не перестроить review, тесты, CI/CD и guardrails, AI просто переносит bottleneck дальше по цепочке. Для больших компаний рабочая стратегия - не ломать всё сразу, а использовать SE 2.0 как полигон новых практик и затем переносить лучшие из них в основной производственный контур. В этой статье на 10 минут чтения я разобрал, что именно меняется в lifecycle и как на это смотреть инженерам и техническим руководителям. #Engineering #AI #Metrics #Software #DevEx #Productivity #DevOps #Architecture #Culture #Engineering #ML #SystemDesign

What Makes a Great Developer Experience? (Рубрика #Productivity) Интересный доклад Макса Канат-Александра с DPE Summit 2025 (подробнее про саммит здесь). Макс рассказывает про трех китов хорошего опыта разработчиков 1. Cycle time - сколько времени проходит от идеи до работающего результата 2. Focus - сколько у разработчика непрерывного времени на работу без дёрганий 3. Cognitive load - сколько лишнего нужно держать в голове, чтобы сделать полезную задачу Идея в том, что почти любую проблему инженерной продуктивности можно разложить по этим трём осям по мнению Макса. А он знает толк в DevEx, так как он занимался этим всю инженерную карьеру - как главный архитектор Bugzilla - работая над Code Health в Google - отвечая за Developer Experience в LinkedIn - а сейчас он Executive Distinguished Engineer в Capital One (банк чьей моделью бизнеса вдохновлялись при создании Тинькофф) Поэтому мне взгляд Макса на productivity кажется не абстрактной теорией, а опытом полученным на практике. Главная мысль доклада в том, что отличный developer experience - это не про красивый интерфейс внутреннего портала разработки. Это про системное снятие барьеров, которые замедляют инженера, выбивают его из фокуса и заставляют тратить мозг не на продукт, а на инфраструктурный шум. Макс по сути говорит: если улучшение не сокращает цикл, не защищает фокус и не снижает когнитивную нагрузку, то его ценность для DevEx сомнительна. А теперь про инсайты 1️⃣ Скорость - это не мантра "работайте быстрее" От призывов ускориться или поднажать появляется только стресс, а для реального ускорения надо ускорять внутренние циклы разработки (между внутренними этапами цикла), например можно сделать - Быстрее ревью - Меньше и понятнее PR - Короче сборки - Прозрачнее CI/CD - Быстрее локальную обратную связь Настоящая скорость рождается не из героизма, а из хорошо настроенной системы. 2️⃣ Фокус - это недооценённый актив Каждое прерывание стоит дорого. Непонятная ошибка, внезапный статус-митинг, кривой tooling, шумные алерты - всё это рвёт контекст. А восстановление контекста часто занимает заметно больше времени, чем само прерывание. Интересна мысль про то, что developer productivity часто тонет не в больших проблемах, а в постоянной мелкой фрагментации внимания. 3️⃣ Когнитивная нагрузка - главный скрытый налог Если для обычной продуктовой задачи инженеру нужно помнить особенности пяти пайплайнов, трёх систем мониторинга и семи способов доставки, то проблема не в инженере. Плохой DevEx часто выглядит именно так: разработчик пришёл делать бизнес-фичу, а вместо этого изучает внутренний зоопарк платформенных решений. Из доклада можно извлечь очень практичные советы для технических руководителей 1) Оптимизируйте не лозунги, а путь работы Смотрите не на абстрактную "производительность", а на конкретные бутылочные горлышки: сборка, ревью, тесты, деплой, ожидание доступа, диагностика падений. 2) Убирайте фазу угадывания Если CI/CD падает с сообщением уровня "something went wrong", вы создаёте анти-DevEx. Хорошая система не просто сообщает о сбое, а помогает сразу понять причину и следующий шаг. 3) Берегите инженерный фокус как ограниченный ресурс Линейных инженеров не стоит без необходимости тащить на статусные синки. Контекст-свитчинг - один из самых дорогих видов потерь в разработке. 4) Снижайте вариативность базовой платформы Один стандартный CI, один понятный observability stack, единый способ запуска типовых сценариев - это не "ограничение свободы", а способ вернуть командам внимание к продукту. 5) Не путайте внутренний портал платформы с решением проблемы Склеить 20 плохих процессов в один красивый UI - не значит улучшить DevEx. Иногда лучший интерфейс - это вообще отсутствие ручного шага. P.S. У Макса есть много интересных выступлений, например, про "Developer Experience in the Age of AI Coding Agents" я уже рассказывал #Engineering #AI #Metrics #Software #DevEx #Productivity #DevOps #Architecture #Culture #Engineering #ML #SystemDesign

DORA AI Capabilities Model - Разбор отчета (Рубрика #Productivity) Прочитал на выходных отчет про эту модель-компаньон отчета 2025 года, который называется "State of AI-assisted Software Development". Основная мысль "DORA AI Capabilities Model" в том, что AI сам по себе не гарантирует улучшения, но он усиливает уже существующую социотехническую систему - хорошие практики усиливает, плохие тоже. Модель выделяет 7 capabilities, которые повышают шанс, что AI даст заметный положительный эффект. Отдельно отмечу, что я уже рассказывал как собираются отчеты DORA, как анонсировали AI Capabilities и что было в DORA 2025 - State of AI-assisted Software Development Но если возвращаться к новому отчету, то вот эта великолепная семерка capabilities и вратарь AI 1. Clear and communicated AI stance - у организации есть понятная и донесенная позиция по использованию AI: что разрешено, что ожидается, какие инструменты можно применять. 2. Healthy data ecosystems - внутренние данные качественные, доступные и не разрозненные. 3. AI-accessible internal data - AI-инструменты могут безопасно получать контекст из внутренних кодовых баз, wiki, систем и документов. 4. Strong version control practices - зрелые практики version control, включая частые коммиты и возможность rollback. 5. Working in small batches - маленькие изменения, маленькие релизы, короткий цикл обратной связи. 6. User-centric focus - команда держит в центре пользователя и пользовательскую ценность. 7. Quality internal platforms - качественная внутренняя платформа помогает масштабировать эффект AI на уровне организации. Исследователи из DORA нашли следующие связи между этими семью capabilities и интересующими всех outcomes 1. Clear and communicated AI stance ~ individual effectiveness и organizational performance 2. Healthy data ecosystems ~ organizational performance 3. AI-accessible internal data ~ individual effectiveness и code quality 4. Strong version control practices ~ individual effectiveness и team performance 5. Working in small batches ~ product performance и снижении friction 6. User-centric focus ~ team performance, но без этого фокуса AI даже может ухудшать team performace (команда будет быстрее двигаться не туда) 7. Quality internal platforms ~ organizational performance Отдельно надо отметить, что эти новые capabilities напрямую связаны с классической DORA Core Model - новые capabilities дополняют core модель - Core Model - это более консервативное ядро DORA: capabilities, metrics и outcomes, которые многократно подтверждались в исследованиях за многие годы. - AI Capabilities Model - это надстройка поверх Core, которая отвечает на другой вопрос: при каких условиях AI-assisted development реально улучшает результаты DORA отдельно подчеркивает, что многие AI-capabilities - это те же самые базовые инженерные и организационные способности, которые и раньше были связаны с high performance. Интересно отметить, что 7 факторов получилось не совсем из головы - по описанию DORA, процесс был таким: - Сначала исследователи сформировали широкий список гипотез о capability, которые могут влиять на успех AI-assisted development, опираясь на 78 in-depth interviews, мнения domain experts и прошлые исследования DORA - Затем через приоритизацию они отобрали 15 кандидатов в capabilities для включения в опрос - Потом в количественном анализе они оставили те, по которым нашлось существенное evidence of interaction with AI use В общем, в итоговую модель вошли те 7 capabilities, которые статистически усиливали эффект AI adoption на значимые outcomes #DevEx #Metrics #DevOps #Engineering #Software #Management #Leadership

Как незаметно DORA метрик стало не четыре, а пять (Рубрика #Productivity) Долгие году у DevOps Research & Assesment или попросту DORA было 4 метрики, на которых строилась кластеризация команд по разным уровням элитности. Эти метрики были про скорость поставки и стабильность - Скорость поставки: deployment frequency и lead time for changes - Стабильнсоть: MTTR / time to restore service и change fail rate Подробнее эту историю можно прочитать в моем разборе книги "Accelerate") С января 2026 года у DORA стало 5 software delivery performance metrics, которые на их сайте тоже разбиты на две категории 1️⃣ Throughput - пропускная способность системы - Change lead time - время от коммита до успешного деплоя в прод - Deployment frequency - как часто вы выкатываете изменения - Failed deployment recovery time - как быстро вы восстанавливаетесь именно после неудачного деплоя 2️⃣ Instability - Change fail rate - доля деплоев, требующих немедленного вмешательства - Deployment rework rate - доля незапланированных деплоев, которые пришлось делать из-за прод-инцидента / дефекта Возникает вопрос, а что именно изменилось по сравнению со старой моделью и зачем это было сделано? Вообще, измений было два и оба они важные 1) Старый MTTR / time to restore service в 2023 был уточнен и переопределен как failed deployment recovery time. DORA прямо объясняет это тем, что старое определение смешивало проблемы, вызванные изменением в коде, и внешние инциденты вроде outage в датацентре. Новая формулировка лучше статистически "сцепляется" именно с delivery-метриками. 2) В 2024 DORA добавила новую пятую метрику - deployment rework rate. Их логика была такой: change fail rate хорошо ловит немедленные проблемы после релиза, но плохо отражает объем последующей незапланированной переделки. Поэтому DORA решила отдельно измерять rework как самостоятельную часть instability. Если же говорить про использование метрик, то возникает вопрос: а теперь классификация будет идти по 5 метрикам? И тут по сути ответ "да", но есть нюансы ... ребята из DORA отдельно подчеркивают, что число кластеров не фиксировано и не задается вручную. В FAQ они пишут, что кластеры у них emergent from the data: до 2018 обычно было 3, с 2018 по 2021 - 4, в 2022 снова 3, а в 2023 и 2024 - опять 4. То есть фиксированного "всегда 4 класса команд" больше воспринимать не стоит. Если подумать, а что это значит для обычных технических руководителей (кто не упарывается по методолгии и метрикам)? Кажется, что DORA стала лучше различать два разных вида проблем: - Немедленный фейл после релиза → change fail rate - Отложенная незапланированная переделка из-за продовых проблем → deployment rework rate Это полезно, потому что команда может выглядеть "нормально" по rollback/hotfix сразу после релиза, но при этом системно тонуть в незапланированном rework через день-два. В старой 4-метричной модели это было видно хуже; в новой - видно лучше. Это и есть главное содержательное обновление модели. Отдельно стоит сказать, что 5 метрик бывало в DORA и раньше, а именно в 2021/2022 годах, когда была операционная метрика reliability, но она была не про software delivery performance, а вот текущая великолепная пятерка - это уже именно delivery metrics. P.S. В чате @ai4sdlc вчера обсуждали метрики и было предложение просто использовать DORA. В итоге, я решил написать этот пост, чтобы показать, что даже DORA не просто так посчитать, а еще само понимание метрик дрифтит со временем:) #DevEx #Metrics #DevOps #Engineering #Software #Management #Leadership

You can write code faster. Can you deliver it faster? (Рубрика #Productivity) Это открывающий keynote доклад с конференции DPE Summit 2025 (я уже про нее рассказывал). Его рассказывает Hans Dockter, CEO Gradle Inc, который ассоциируется с темой build automation и delivery pipeline: он основал Gradle Build Tool, руководил крупными enterprise-сборками и давно работает на стыке tooling, DevEx и software delivery. Главный тезис доклада вынесен в название - GenAI ускоряет написание кода, но это не означает ускорение доставки работающего софта, Автор отмечает, что если AI увеличивает объём изменений upstream, то downstream-система - build, test, compliance, deploy - начинает захлёбываться и это выглядит как звучит как предупреждение для слушаетелей. Hans объясняет эту проблему так - AI делает код быстрее, чаще и в больших объёмах, но одновременно снижает глубину человеческого понимания - Это провоцирует крупные и более рискованные батчи изменений - Это ухудшает feedback loops и растёт число сбоев - В итоге, между "быстро поэкспериментировать" и "надёжно доставить в production" возникает всё больше трения Если говорить про инсайты выступления, то они такие 1️⃣ Фокусироваться надо не на output, а на outcome Важен не рост объёма сгенерированного кода (LoC, lines of code), а рост количества рабочего софта, которое команда реально доводит до пользователей 2️⃣ Узкое место смещается из coding в delivery system Если раньше многие команды оптимизировали IDE, code review и генерацию кода, то теперь конкурентное преимущество будет у тех, кто умеет ускорять pipeline throughput без потери качества и без взрывного роста стоимости CI (continious integrations). То есть выигрывает уже не тот, кто "быстрее пишет код", а тот, у кого архитектура пайплайна выдерживает AI-нагрузку. 3️⃣ GenAI-ready pipeline - это не просто больше железа Автор рассказывает про конкретные классы решений, что надо улучшать: траблшутинг, интеллектуальная параллелизация запусков, предиктивное выполнение тестов, универсальное кеширование, автоматизация применения политик. В общем, закидать раннерами не получиться - придется перестраивать систему как умный конвейер с хорошей диагностикой и управлением риском 4️⃣ Observability и быстрый анализ ключевых причин становятся частью developer experience Кажется, что мы идем в сторону того, что AI-кодинг может становиться для разработчика все более "чёрным ящиком", а поэтому важно усиливать не только тестирование, но и видимость сигналов: результаты тестов, статический анализ, группировку фейлов, coverage, диагностику причин падений. Мне понравилась еще и метафора, что автор подобрал для выступления - он сравнивал скорость мутаций в организмах и появление рака со скоростью AI кодинга и мутациями GenAI моделей, которые приводят к галлюцинациям. В итоге, автор провел параллели между количеством клеток у слонов по сравнению с людьми и работой их механизмов коррекции и защиты от мутаций - если бы у слонов не было такой защиты и они имели похожие средства само-корректировки ДНК, то они бы жили на порядок меньше и умирали от рака. Параллель тут была с нашими CI/CD инструментами, которые должны быть крутыми, чтобы мы могли защищаться от недетерминистической природы GenAI моделей, которые теперь генерируют нам потоки кода:) Если говорить про выводы, то мне кажется следует вынести следующие четыре вещи 1. Мерить надо не сколько кода написали, а как изменились lead time, failure rate, MTTR и time-to-feedback 2. DevEx теперь включает качество delivery loops, а не только удобство редактора и SDK 3. Платформенная команда становится ещё важнее: именно она делает AI adoption безопасным и экономически оправданным 4. Самая зрелая позиция для руководителя - не спорить "заменит ли AI инженеров", а перестроить систему так, чтобы рост output не разрушал outcome В общем, AI тут скорее сделал все эти вещи еще более важными, так как они и раньше были на повестке многих компаний. #DevEx #Metrics #DevOps #Engineering #Software #Management #Leadership

Чат "Архитектура, менеджмент и влияние AI на разработку" У меня давно был чат для комментариев в этом канале, но я про него особо не рассказывал:) Теперь я решил поменять подход и приглашаю вас в этот чат @ai4sdlc, где мы сможем обсудить вопросы проектирования, технического руководства и не только. Ну и конечно там можно общаться про влияние AI на разработку, так как я теперь full-time занимаюсь этой темой на своей работе. Я буду бывать в этом часте достаточно часто (как минимум, чтобы удалять ботов из него). В общем, you are welcome - https://t.me/ai4sdlc #Architecture #AI #Management

DPE Summit 2025 от Gradle: почему это одна из самых полезных конференций про инженерную продуктивность (Рубрика #Productivity) Мне нравится конференция DPE (Developer Productivity Engineering) от Gradle, которая проходит ежегодно в Сан-Франциско. Я часто рассказывал про доклады с саммита 2024 года (например, здесь: 1, 2, 3 и 4). Это событие целиком посвящено темам инженерной продуктивности и DX (developer experience) и в этом году оно прошло 23–24 сентября и организаторы уже выложили записи сессий (вот плейлист). Почему мне кажется это событие важным и интересным - потому что DPE - это взгляд на продуктивность разработки не в лоб вида "сколько строк кода написал инженер", а скорее как на инженерную задачу: - Как ускорить feedback loops и снизить cognitive loag - Как улучшить CI/CD (ускорить, упростить, сделать дешевле) - Как улучшить observability и упростить troubleshooting Сами Gradle и dpe.org прямо описывают DPE как практику, которая повышает продуктивность и счастье разработчиков за счет инструментов, автоматизации и данных, а не только менеджерских метрик. Самое ценное в этой конференции - это не абстрактный треп про "developer productivity", а кейсы от крупных инженерных организаций (где все равно может быть вода). В программе были спикеры и доклады от Netflix, Google, Meta, Microsoft, Capital One, Uber, JetBrains, Okta, Lloyds Bank, Square, Databricks и других компаний. Они обсуждали среди прочего темы влияния GenAI на delivery, подходы к измерению эффекта AI на продуктивность, ускорение билдов, universal cache, merge queue, flaky tests, dependency updates, observability и DevEx-метрики. Если обобщать, то основной вывод саммита в том, чтоGenAI ускоряет написание кода, но не гарантирует ускорение поставки работающего софта. В keynote Ханс Доктер прямо формулирует вопрос:

You can write code faster. Can you deliver it faster?

Логика вопроса простая: чем больше кода генерирует AI, тем сильнее нагрузка на build, test, compliance и deployment. Если pipeline не готов, то AI не ускоряет delivery, а просто переносит bottleneck вниз по цепочке. Отсюда фокус на smarter pipelines, observability, predictive test orchestration, caching и shift-left практиках. Я посмотрел пока только несколько докладов, но уже видно, что не все доклады как keynote абстрактны. Например, Max Kanat-Alexander из Capital One в доклада "What Makes a Great Developer Experience?" рассказыват о трех вещах, что улучшают DevEx: быстрее итерации, больше focus time и меньше cognitive load. Netflix разбирает productivity в эпоху GenAI и отдельно показывает, как они подходят к build vs buy и внедрению AI coding agents. Google обсуждает, как реально улучшать влияние AI на продуктивность разработчиков. Uber показывает тему merge queue "at scale", а Square - как использовать idle time разработческих машин, чтобы ускорять workflows и улучшать cache hit rate. Для технических руководителей ценность в том, что DPE Summit хорошо показывает, что продуктивность - это уже не HR-дискуссия и не спор про velocity, а полноценная область platform engineering и engineering management. Мерить надо не только output, но и flow, friction, надежность пайплайна, время обратной связи, стоимость изменений и реальный опыт разработчика. Ну и если посмотреть доклады, то можно перейти от поверхностных разговоров в стиле "AI заменит разработчиков" на обсуждение изменений все контур delivery - от локальной среды и тестов до pipeline, observability и управляемых DevEx-инвестиций. В следующие дни я буду много рассказывать про интересные доклады с этого саммита. #DevEx #Metrics #DevOps #Engineering #Software #Management #Leadership

IntelliJ IDEA — The IDE That Changed Java Forever | DOCUMENTARY (Рубрика #Engineering) Посмотрел эту документалку про IntelliJ IDEA, что вышла 5 марта 2026. Это захватывающая история о том, как небольшая команда стартовала создала продукт, который переопределил ожидания от dev tools. В кадре находятся как сотрудники компании JetBrains, так и представители индустрии которые делятся своими воспоминаниями о том, как это было. JetBrains росла органически, без внешних инвестиций, и с самого начала строила не просто редактор, а "интеллектуальный" инструмент для разработчика - забавно, что в конце фильма обсуждается роль искусственного интеллекта в разработке софта и будущего IDE, а сотрудники JetBrains говорят, что редактор даже в названии своем сразу содержал часть про интеллект:) Но если начать сначала, то когда-то IntelliJ шла от рефакторинга и понимания структуры кода, а не от красивой оболочки. Это важно: они сделали ставку не на "еще один IDE", а на то, чтобы машина реально понимала программу глубже. Другая интересная мысль - это то, что ребята показали как developer tools могут быть платформой, а не только продуктом. В 2009 году JetBrains открыла Community Edition и прямо писала, что убирает главный барьер для более широкого использования - цену, сохраняя при этом коммерческий Ultimate. Причем Community Edition и IntelliJ Platform стали базой не только для IDEA, но и для других инструментов JetBrains. А дальше цепочка уже известна: Android Studio официально построена на IntelliJ IDEA, а Kotlin, запущенный JetBrains в 2011 году и рано открытый в open source, со временем стал частью очень большого сдвига в JVM и Android-мире. Следующая мысль крутится вокруг качества продукта и общей любви потребителей к нему. В фильме видно, что dog fooding в JetBrains был с самого начала и это был не маректинг. Ребята честно рассказывают о том, как их продукты часто рождались из внутренних потребностей, а сами команды ежедневно работают в собственных инструментах. Плюс у них есть культура 20%-проектов, хакатонов и Labs для выращивания новых идей. Это очень узнаваемый паттерн: когда разработчики сами страдают от своих UX-решений, качество обратной связи резко растет. Дургой инетерсный момент связан с подходом к ведению бизнеса. Доверие пользователей для JetBrains постулируется важнее "правильной бизнес-модели на бумаге". Это проявилось в 2015 году, когда JetBrains переходили на подписочную модель, что вызвало сильную негативную реакцию. Компания потом публично признала, что не учла важные группы пользователей и плохо объяснила изменения, после чего быстро добавила perpetual fallback license и continuity discounts. Для меня это один из самых сильных эпизодов всей истории: хороший продукт не дает иммунитета от ошибок, но прозрачная коррекция курса помогает доверие вернуть. Не часто видишь похожий подход к тому, чтобы не только декларировать важность доверия пользователей, но и оправдывать его. Ну и последняя мысль связана с современным трендом на AI4SDLC. Cейчас JetBrains продвигает AI как продолжение IDE: Next Edit Suggestions умеют использовать нативные IDE-действия вроде Rename refactoring, а Junie позиционируется как coding agent прямо внутри IDE. То есть ребята хотят стать центром нового процесса, где генерация соединяется с навигацией, рефакторингом, инспекциями и проверкой изменений. Правда, про это в фильме не говорится, но это видно по анонсам новинок в их продуктах:) В итоге, руководителям можно забрать тезисы про - Важность инвестиций в DevEx и крутые инструменты как бустеры эффективности разработки - Dogfooding как бустер качества продуктов - Open core как варианта развития коммерческого продукта в связке с open source - Важность уметь не только декларировать ценности, но и следовать им даже во времена кризисов - Понимание, что нельзя почивать на лаврах и надо уметь ловить волну (в этом случае AI в разработке) P.S. Summary есть и на system-design.space. #Engineering #Software #Management #Leadership #Startup #Architecture #Documentary #AI

Как я пишу посты в канал (Рубрика #SelfDevelopment) Меня периодически спрашивают как я пишу так много постов и есть ли там помощь от LLM. И вот я решил написать про свой подход к потреблению знаний и ведению канала. Если кратко, то пайплан выглядит примерно следующим образом - Discovery: у меня есть набор телеграм каналов, обученная система рекомендаций от Google (в браузере и Youtube), есть подписки, что делают отбивки мне на почту. Мои интересы сфокусированы вокруг разработки, менеджмента, наук (в основном точных), искусств (здесь скорее визуальных, включая фотографию) - Digest: каждый день я смотрю пару видео, читаю несколько статей + несколько глав из книг - Discuss: дальше я обсуждаю изученное с LLM моделями - раньше у меня часто была проблема, что обсудить материал было не с кем, а теперь даже если я читаю зубодробительный whitepaper, то у меня есть собеседник - Describe: дальше мой диалог с LLM я прощу суммаризировать SOTA модель в формат поста - eDit: дальше я делаю ревью того, что получилось, куда входит фактчекинг + проверка того, что в коротком посте подсвечены именно те инсайты, что возникли у меня после просмотра видео / прочтения статьи и дальше дискуссии с LLM - Deliver: дальше остается запланировать публикацию поста на нужный день и нужное время с учетом моего настроения и тем, которые я люблю группировать в блоки В итоге, получается 6D процесс, который позволяет мне глубоко погружаться в интересующие меня темы, а также делиться возникшими мыслями с аудиторией канала. #Engineering #AI #Productivity #Writing

The third golden age of software engineering - thanks to AI, with Grady Booch (Рубрика #AI) Интересное интервью Гради Буча, создателя UML и Chief Scientist for Software Engineering в IBM, в подкасте The Pragmatic Engineer. Гради и Gergely Orosz, автор подкаста, обсуждают как меняется ремесло инженера, когда уровень абстракции снова поднимается (как было во времена появления ассемблера, а потом высокоуровневых языков программирования). Интересно, что в этом интервью Гради Буч заочно дискутирует с Дарио Амодеи, что в прошлом марте публично говорил, что мы можем быть в 6–12 месяцах от ситуации, когда модели будут делать end‑to‑end то, что делают software engineers, а инженеры перейдут в режим "модель пишет - я редактирую. Буч на это реагирует очень жестко и по сути: это взгляд на программирование как на набор строк кода, а не на инженерную дисциплину:) В общем, основные тезисы интервью такие 1️⃣ Мы уже в "третьем золотом веке" - и он про системы, а не про код Буч раскладывает историю на 3 золотых века: 1) 1940-1970 - алгоритмы и автоматизация бизнеса 2) 1970-2000 - объектные абстракции 3) 2000-сейчас - системы, где мы собираем продукты из библиотек, платформ, API, облаков - и теперь поверх всего этого появляется ИИ‑слой. И по мнению Гради AI - это не конец профессии, а очередной скачок абстракции 2️⃣ Экзистенциальная паника - повторяющийся цикл Когда появились компиляторы и языки высокого уровня, тоже казалось, что всё, программисты не нужны. Но индустрия не умерла - она пересобралась и пошла выше по стеку. Одна из центральных мыслей Буча: ваши инструменты меняются, но ваши проблемы - нет 3️⃣ ИИ силён там, где паттерны уже установились Текущие инструменты типа Cursor/Claude хороши там, где задачи повторяются: типовые CRUD, стандартные интеграции, привычные веб‑паттерны. Буч прямо отмечает, что они обучены на проблемах, которые мы видели снова и снова. А вот граница интересного - в системах, контексте, компромиссах, ответственности. 4️⃣ Software engineering - это не набор кода, а баланс сил и решений Инженерия - это баланс технических ограничений, человеческих факторов и этики, а код - лишь один из инструментов. А отсюда у нас простой вывод - ИИ может ускорить производство артефактов, но не заменить принятие решений под ограничениями. 5️⃣ Автоматизация ударит по delivery pipeline (и это нормально) Буч отдельно отмечает, что пайплайн поставки (всё вокруг сборки/доставки/рутины) - это низко висящий фрукт для автоматизации. И людям в этих ролях может понадобиться дообучение 6️⃣ Чем выше абстракция - тем важнее фундамент Парадоксально, но факт: когда код писать стало легче, больше ценится глубокая модель мира. Буч рекомендует усиливать фундамент и мышление системами Кажется, что инженерам теперь качать нужно следующие навыки - System design и distributed systems, а эта тема неплохо описана на сайте system-design.space - Умение работать с ограничениями: стоимость, сроки, риски, легаси, безопасность, регуляторика, команда - эта тема хорошо описана там же + скоро появится новый сайт для технических лидеров в том же стиле, что я сделал system-design.space - Навык “review & governance: проверять, тестировать, ставить ограничения, ловить неочевидные баги, которые ИИ легко генерит наряду с работающим кодом - Доменные знания: бизнес‑контекст, который теперь ценится еще больше:) #Architecture #Software #AI #Engineering #ML #Data #SystemDesign #DistributedSystems #History

An Illustrated Guide to AI Agents (Рубрика #Agents) Пока летел обратно из Лондона в Москву успел прочитать эту книгу и могу ее рекомендовать всем. Ее пишут Jay Alammar и Maarten Grootendorst - авторы крутой книги "Hands-On Large Language Models", о которой я уже рассказывал. Новая книга про агентов настолько же хороша, как предыдущая, а еще она находится в процессе написания и пока написана только половина глав. Уже видно, что новая книга продолжает тему LLM, но уже в мире AI agents - то есть в первой книге читатели могут увидеть как устроены LLM (там почти 300 иллюстраций), а в новой - как из LLM собирать агентские системы. То есть первая книга отвечает на вопрос "что у модели внутри", а новая - как вокруг модели построить память, tools, планирование и координацию. В общем, рекомендую читать именно в таком порядке, чтобы сначала понять движок, а потом - архитектуру приложения. Если говорить про готовность книги, то сейчас уже готовы основные главы 1. Introduction - зачем вообще нужен "agent", чем он отличается от просто LLM-вызова, где кончается чат-бот и начинается система. Это глава для выравнивания терминов и общей архитектурной картинки. 2. Reasoning LLMs - что меняется, когда модель умеет не только отвечать, но и проходить цепочки рассуждений / test-time reasoning. Это важная глава, чтобы не путать "умный ответ" и "умение модели размышлять". 3. Memory - это одна из самых практичных частей: контекст, short-term vs long-term memory, context engineering, как агент "помнит" и почему память быстро становится архитектурной, а не только ML-задачей. 4. Tool Usage, Learning, and Protocols - эта глава про инструменты, function calling, интеграции и протоколы вроде MCP. То есть про момент, когда LLM перестает быть только генератором текста и начинает что-то делать во внешнем мире. 5. Planning and Reflection - здесь речь про декомпозицию задачи, пересборку плана, self-critique и feedback loops. Это уже территория, где агентность начинает влиять на надежность и стоимость решения. 6. Multi-Agent Systems - когда одного агента мало, как делить роли между несколькими, а также как выстроить координацию агентов. Тут появляется и A2A протокол (раньше я уже как-то рассказывал про MCP vs A2A протокол) В общем, мне книга зашла и я буду следать за появлением новых глав. Думаю, что она будет полезна инженерам и техлидам, которым нужно не увидеть "еще одно демо", а построить себе в голове ментальную модель: из каких блоков вообще собираются AI agents и где в этой конструкции живут реальные инженерные риски. И если "Hands-On Large Language Models" был хорошим входом в тему LLM, то "An Illustrated Guide to AI Agents" выглядит как хороший вход в тему агентских архитектур и мульти-агентных систем P.S. Более подробный разбор есть на сайте system-design.space. #Architecture #Software #AI #Engineering #ML #Data #SystemDesign #DistributedSystems

[2/2] How AWS S3 is built (Рубрика #Architecture) В продолжении этого крутого интервью, я хотел бы поделиться выводами из него для инженеров и технических руководителей. Для инженеров можно забрать идеи о том, что - Надёжность - это не try/catch и ретраи, а отдельные системы: аудит, восстановление, непрерывная проверка инвариантов. Если у вас данные с высокими ставками, то думайте не только про happy path, но и про способы самовосстановления - Корреляция отказов важнее единичных сбоев - дизайн по fault domains (rack/AZ/region), хаос‑тесты не для того, чтобы случайно вырубить ноду, а отключить общий домен - Rust в критическом пути - это хороший способ оптимизации, если вы пишете сетевой/IO‑интенсивный runtime или любой hot path - memory‑safe системный язык становится конкурентным преимуществом - Формальные методы могут быть не избыточно тяжелыми, а практичными: не обязательно верифицировать всё. Достаточно выбрать 1–2 инварианта (консистентность, crash safety, права доступа) и поставить автоматическую проверку рядом с CI А для технических руководителей это история про то, что - Сложность можно победить ограничениями - сервисов может быть сотни, но каждый должен быть простым и сфокусированным, а иначе система станет неуправляемой. - Метрики уровня SLO должны быть измеряемыми, а не декларативными: идея мы можем ответить, какая у нас фактическая durability за неделю/месяц - это про культуру инженерии, где операционка встроена в дизайн. - Correctness как продукт - automated reasoning/формальные проверки как инвестиция, которая позволяет двигаться быстро и не ломать. Это особенно важно там, где тестами невозможно покрыть комбинации состояний - Хранилище S3 превращается в data‑платформу: Tables/Vectors - это намёк, что часть базы/поиска/оптимизации всё чаще будет жить рядом с storage. Для архитектуры это означает: регулярно пересматривайте, что выгоднее - строить самим или сдвигать вниз в managed‑примитивы. Если хочется попробовать этот подход у себя, то можно - Нарисовать fault domains (реальные) и проверить, где у вас скрытая корреляция. - Добавить сервис аудита хотя бы для ключевых инвариантов (checksums/версионирование/сверка индексов/реплик). - Выделить 1 критичный модуль и использовать легковесный формальный подход: спецификация + автоматическая проверка (пусть даже минимальная). - Пересмотреть сервисы на предмет перегрузки функциональностью и разложить ответственность так, чтобы каждый компонент был тупым, маленьким и проверяемым. #Culture #Management #Leadership #Processes #Engineering #Software #Architecture #DistributedSystems #SystemDesign

[1/2] How AWS S3 is built (Рубрика #Architecture) Интересный выпуск подкаста "The Pragmatic Engineer", в котором Gergely Orosz общается с Mai‑Lan Tomsen Bukovec, VP of Data & Analytics в AWS, которая руководит развитием/эксплуатацией S3. А Simple Storage Service - это одна из самых масштабных систем в мире, поэтому из этого обсуждения можно извлечь много интересного 1️⃣ Масштаб, который ломает интуицию В S3 сотни миллионов транзакций в секунду, 500+ трлн объектов, сотни эксабайт данных. Интересно, что Gergely и Mai‑Lan говорят о том, что сложенные в стопку десятки миллионов дисков в S3 почти смогут достать до МКС 2️⃣ Переход к strong consistency - как крутая инженерная миграция S3 стартовал с eventual consistency (2006), но затем перешёл к strong consistency без ухудшения доступности и без удорожания для клиентов. Архитектура была примерно такой: replicated journal + протокол когерентности кеша с идеей failure allowance 3️⃣ Тихий переход на Rust в критическом request path Команда переписала почти всё performance‑critical в обработке запросов на Rust, с мотивацией: максимум perf и минимум latency 4️⃣ 11 девяток durability - это "измерение факта", а не обещания Durability уровня 99.999999999% поддерживается не магией, а флотом фоновых сервисов: микросервисы аудита, которые непрерывно проверяют каждый байт, и отдельные repair‑механизмы, которые автоматически чинят. 5️⃣ Формальные методы - это production‑практика, а не академические изыски В S3 активно используют формальные методы верификации: при изменениях в подсистеме индексов/консистентности запускаются автоматические формальные проверки, чтобы не было регресса модели. И это не просто слова: в публикации Amazon Science про "lightweight formal methods" описан опыт, где такие методы помогли не пустить в прод 16 проблем 6️⃣ Главный враг сегодня - correlated failures Одиночные поломки нормальны, но опасны коррелированные отказы: общий rack/AZ/питание/и т.п. Архитектура строится вокруг борьбы с этими корреляциями: репликация по AZ, quorum‑подходы, физическая/логическая декорреляция, хранение копий в разных fault domain 7️⃣ Сотни микросервисов - и многие из них не про трафик В эпизоде фигурирует порядок 200+ сервисов, и заметная часть из них занимается health checks / audit / repair, а не пользовательскими запросами. Сложность удерживается через упрощение - каждый сервис должен быть максимально сфокусирован 8️⃣ S3 перестаёт оперировать только бакетами: новые примитивы Tables и Vectors Появились новые примитивы - S3 Tables: объектное хранилище с встроенной Apache Iceberg‑поддержкой и фоновой оптимизацией таблиц (перепаковка/компакшн и т.п. "в фоне"). AWS заявляет до 10x TPS vs Iceberg‑таблицы в обычных S3‑бакетах - S3 Vectors: нативное хранение/поиск векторов в S3. В эпизоде - инженерная идея vector neighborhoods (предрасчёт кластеров оффлайн), чтобы получить тёплые запросы <100ms, и очень большие масштабы индексов/бакетов 9️⃣ Crash consistency - как мировоззрение Настоящие инженеры мыслят так: система должна возвращаться в корректное состояние после fail‑stop; проектирование идёт через перебор возможных состояний при отказах + набор сервисов, которые удерживают инварианты 🔟 Принцип Scale must be to your advantage Нельзя строить так, чтобы рост сервиса ухудшал характеристики; на масштабе, наоборот, должны появляться эффекты, улучшающие надёжность (например, декорреляция нагрузок) В продолжении расскажу как можно этот опыт переложить на практические рекомендации инженерам и техническим руководителям. #Culture #Management #Leadership #Processes #Engineering #Software #Architecture #DistributedSystems #SystemDesign

Svelte Origins: A JavaScript Documentary (Рубрика #Frontend) Посмотрел очередной интересный документальный фильм на этот раз про фреймворк Svelte и его историю по конец 2021 года. В документалке мы видим ключевых персонажей коммьюнити - Rich Harris (создатель Svelte) и его путь: от задач интерактивной визуализации к идеям Svelte - Guillermo Rauch (CEO Vercel) - про переход Rich Harris в Vercel и последствия для проекта - Orta Therox (инженер TypeScript Compiler) - зачем Svelte нужен TypeScript и как его внедряли - Amelia Wattenberger (GitHub Next) - про DevEx и "удовлетворённость" пользователей - м ногие другие Основные инсайты истории следующие 1. Svelte = компиляторный подход: максимум работы делается на этапе сборки, в браузере - минимум “фреймворк‑рантайма”. Идея - меньше JS в проде и проще держать performance budget. 2. Отказ от Virtual DOM - не хайп, а инженерный выбор: обновления DOM специализируются под конкретные компоненты ещё на build‑time. 3. Истоки в "враждебном продакшене": интерактивная журналистика/визуализации, дедлайны, куча сторонних скриптов (реклама/аналитика), строгие ограничения по весу и скорости - отсюда мотивация "делать меньше в браузере". 4. Svelte вырос из опыта Ractive.js: осознание, что прошлые подходы дают лишнюю сложность/издержки, и это можно переупаковать в компиляцию. 5. V1 → V3 как история про DevEx: подчёркивается, что "приятность разработки" - часть идеологии, а не побочный эффект оптимизаций. 6. TypeScript - не "приятный бонус", а блокер адопшна. Подробнее про TypeScript и его историю развития можно посмотреть в документалке 7. Комьюнити - это усилитель экосистемы: Svelte Summit + Svelte Society как инфраструктура онбординга, контента, пакетов и "социального доказательства" 8. Профессионализация через Vercel: Rich получает возможность заниматься Svelte full‑time, при этом отдельно проговаривается независимость governance Отдельно стоит отметить, что это история на конец 2021 года, когда был снят ролик, а не актуальное состояние фреймворка и планов его развития. Что это значит для разработчиков - Если у вас жёсткие бюджеты по JS/TTI/LCP и много интерактива - Svelte логично тестировать как кандидат: философия проекта про это. - Делайте пилот вертикальным слайсом (одна реальная фича/экран), а не демкой: сравните bundle size, LCP/TTI, скорость доставки и "количество слоёв абстракций". - Если в компании TS - начинайте пилот сразу с TypeScript, потому что TS‑поддержка в видео явно показана как важнейший запрос рынка. - Для data‑heavy UI / визуализаций проговаривается сильный паттерн Svelte + D3. Что это значит для техлидов и руководителей - Здесь классно показана рамка принятия решений: переносим сложность из runtime в build‑time → выигрываем в рантайме, но должны честно оценить trade‑offs (инструменты, дебаг, экспертиза, найм). - Риски OSS по-взрослом: Vercel снижает bus‑factor (full‑time maintainer), но появляется управленческая зависимость от спонсора как стейкхолдера. Это стоит проговорить заранее. - Перед пилотом фиксируйте KPI успеха: RUM‑метрики, регрессии, time‑to‑ship, дефекты UI/реактивности - чтобы обсуждать не "нравится/не нравится", а эффект. - Стратегия внедрения: инкрементально (страница/модуль/"острова"), а не big‑bang rewrite. - Инвестируйте в обучение идей (реактивная модель, стоимость обновлений, дизайн состояния), а не только синтаксиса компонентов. #Software #Documentary #Engineering #Architecture #Management #Frontend

Building AI-Powered Products (Рубрика #AI) Прочитал интересную книгу Marily Nika, AI Product Lead (Google, ex‑Meta) и основателя AI Product Academy. Marily рассказывает в ней про то, как выглядит отдельная дисциплина AI product management и как определить, а что именно строим, как меряем качество продукта, сколько это будет стоить в продакшене и почему пользователи не уйдут через неделю. Эта книга вышла в феврале 2025 года и пыталась выдать плейбук, который связывает идею → продуктовую ценность → архитектуру → эксплуатацию → метрики → риски. В ней рассматривались вопросы вида - Как выбирать AI сценарии, которые приносит value, а не "потому что модно" - Как думать про измерение успеха: оффлайн‑метрики, human eval, мониторинг в проде - Как оценивать trade‑offs: качество vs latency vs стоимость инференса vs риски - Как выстроить работу продакт менеджеров, инжиниринга, data science и research, чтобы ожидания совпали - Как быть с этикой и compliance: данные, приватность, "галлюцинации", ответственность за работу моделей Если говорить про содержание книги, то она состоит из preface, 8 глав и appendix. Chapter 1. The Role of AI Product Managers Здесь автор рассказывает про роль AI продакт менеджеров и как развивалась эволюция AI: традиционный AI → GenAI → грядущий AGI. Какие особенно у AI продуктов, включая вероятностную природу, зависимость от данных, дрифт моделей, требования к интерпретируемости/объяснимости, автоматизированные решения, масштабируемость и влияние этого всего на UX. Тут же описывается какой набор скиллов требуется для AI продакт менеджеров Chapter 2. The AI Product Development Lifecycle Здесь автор рассказывает про каркас AI Product Development Lifecycle (AIPDL) и проводит по стадиям: - Типы AI‑продуктов: 0‑to‑1 (новый продукт) vs 1‑to‑n (AI‑фичи в существующем) (напоминает историю "Zero to One" Питера Тиля) - Этап Ideation (в т.ч. брейншторм и приоритизация через RICE - Этап Opportunity: product‑market fit + бизнес‑viability (ROI/монетизация/риски/регуляторика), реализуемость и desirability, - Concept & Prototype: прототип "хардкодом", проверка интеграции, доменная экспертиза, ценность "с первого дня", - Testing & Analysis и Rollout Chapter 3. Essential AI PM Knowledge В этой главе автор рассказывает про базовые практики продакт менеджмента, классическую оценку build vs buy, лидерство и коммуникации, связь с инженерной командой, базовые технические концепции и так далее. В общем этакий product management 101. Chapter 4. The AI PMs Day‑to‑Day Здесь автор рассказывает про карьерную лестницу AI PM: execution → AI/ML PM → стратегическое лидерство. Дальше она приводит примеры людей, которые работали в этих ролях в разных компаниях. Здесь же идет рассказ про выстраивание кросс‑функциональных взаимодействий в командах. Chapter 5. Strategic Thinking in AI Здесь речь про стратегию и "правильные вопросы" до того, как писать код: - Когда AI может быть не ответом, - Disruptive vs sustaining и как не проиграть “innovator’s dilemma”, - AI‑стратегия build vs buy (матрица решения + гибридные подходы), - Data‑стратегия: synthetic vs real‑world data, - Выбор подхода: fine‑tuning vs RAG vs grounding + фреймворк принятия решения, - Product reviews как инструмент получения buy‑in от руководства. Chapter 6. Setting Goals and Measuring Success Здесь автор рассказывает про метрики и измеримость: product health, system health, ai proxy metrics. Как собирать OKR. Chapter 7. AI Tools for Product Managers Обзор классов инструментов для поддержки AIPDL и инструментов для совместной работы. Chapter 8. Building AI Agents Глава про агентные продукты, что это такое и как "сконструировать" агента под продукт: вертикальный vs general‑purpose, activation, autonomy, feedback/learning. #ProductManagement #Software #SoftwareDevelopment #AI #Engineering #Management #Leadership

Кафедральный собор Святого Павла (Рубрика #Travel) Мы сегодня с Настей посетили этот собор и остались в восторге. Величественное злание возвышается над округой и внутри выглядит замечательно. Кроме первого этажа можно спуститься в крипту, где покоятся исторические деятели, а также можео подняться под свод собора и даже выше, чтобы со смотровой площадки увидеть Лондон вокруг. В общем, это обязательное для посещение место ... как минимум для туристов. #Culture

[2/2] Retired Netflix Engineering Director On Regrets, Video Engineering, Hiring Stories (Рубрика #Engineering) В продолжении этого крутого интервью, я хотел бы поделиться выводами из него для инженеров и технических руководителей. Что это значит для разработчиков (IC) - Если ты single point of failure - это не "круто", это риск. Документация, runbook’и, ротации on-call, передача контекста, “absence drill” (плановая недоступность) — это то, что делает команду взрослой. - Собирай "evidence of impact" до того, как тебя об этом попросят. Простая привычка: раз в месяц фиксировать “что сделал → какой эффект → какие риски снял → какие метрики/сигналы подтверждают”. Это помогает и в оценке, и в повышении, и в переговорах. - Не путай "много работал" с "много решил". В разговоре красной нитью: часы - плохой KPI. Системы и команды должны работать так, чтобы не требовать постоянного героизма. - Про собесы: будь готов к стандартизированным фильтрам, но выигрывает инженерная зрелость. Умение рассуждать про trade‑offs, неопределённость, дизайн систем и реальные решения - то, что отличает сильных на дистанции. Что это значит для техлидов и технических руководителей - Культура должна "исполняться", а не декларироваться. Например, "No brilliant jerks" работает только когда есть реальный enforcement: обратная связь, понятные ожидания и готовность расставаться даже с сильными, если они ломают команду. - Сделайте отпуск диагностическим инструментом. "Vacation/bus‑factor тест": кто уходит на неделю → что ломается → какие знания/доступы/процессы надо распаковать из головы в систему. - Видимость вклада - это инфраструктура роста. Не обязательно сразу “как в Meta”. Но вам нужна лёгкая версия: цели → зафиксированный impact → регулярная синхронизация ожиданий между командами, иначе на масштабе всё начнёт “тонуть в тумане”. - Найм: определитесь, что вы реально измеряете, и структурируйте процесс. Если хотите системное мышление и зрелость - добавляйте этапы, которые это проявляют (work‑sample / разбор реального кейса / обсуждение решений при неполных данных), а не только "задачки". - Компенсируйте перекос в индивидуальной аттрибуции резульататов. Если "светится" только личный вклад - получите локальную оптимизацию. Добавляйте командные сигналы, качество взаимодействия, ownership на длинной дистанции, культуру совместного результата. #Culture #Management #Leadership #Processes #Engineering #Software #Career #Interview

[1/2] Retired Netflix Engineering Director On Regrets, Video Engineering, Hiring Stories (Рубрика #Engineering) Интересное интервью Дэвида Ронка, экс Engineering Director в Netflix (пришёл в 2007), позже Director/Principal в Meta (видеотехнологии), которое он дал Райану Питерману , Staff SWE в Instagram. В этом интервью Дэвид, который уже вышел на пенсию, делится ретроспективой своей карьеры и управленческих решений. Основные инсайты следующие 1️⃣ "No brilliant jerks" - это не HR-лозунг, а инженерная оптимизация throughput Токсичная "звезда" может быть сильной индивидуально, но снижает скорость и качество всей команды (а значит и системы). 2️⃣ Героизм и 24/7 - симптом организационного бага, а не доблесть Если команда не переживает нормальный отпуск ключевого инженера, проблема почти всегда в устройстве системы: ownership, знания, ротации, процессы, приоритеты. 3️⃣ Culture Memo "aspirational": культура без инфраструктуры ломается при росте На небольшом масштабе "контекст вместо контроля" и сильные люди могут вытягивать многое. На большом масштабе без уровней/процессов/прозрачности вклада начинаются перекосы: вклад размывается, аттрибуция успехов уезжает вверх, компенсации сложнее объяснять. 4️⃣ Масштаб реально меняет физику инженерных решений Переход в Meta показал ему, что некоторые задачи (например, видео на уровне платформы) нельзя "дожать CPU’шками и количеством серверов" - нужна другая парадигма. 5️⃣ Найм: конфликт "точность оценки <=> масштабируемость процесса" У него жёсткая позиция про LeetCode (как не очень хороший сигнал качества инженера), но при этом он признаёт: в big tech стандартизация этапов часто неизбежна. Плюс важный тезис: over‑leveling - дорогая ошибка, потому что "мягко опустить ожидания" потом почти невозможно. 6️⃣ Performance/калибрации могут быть отличной школой управленческой объективности Да, это тяжело и неприятно, но заставляет формулировать вклад инженеров так, чтобы он держался на фактах и impact’е, а не на харизме менеджера. 7️⃣ Риск формализованных систем: перекос в "индивидуальную аттрибуцию результатов" Вклад становится видимым, но риск в том, что люди начинают оптимизировать "видимость" и личную победу, а не командный результат. В продолжении расскажу как можно этот опыт переложить на практические рекомендации инженерам и техническим руководителям. #Culture #Management #Leadership #Processes #Engineering #Software #Career #Interview

Граф знаний сайта system-design.space (Рубрика #SystemDesign) Материалов на сайте про system design стало слишком много и мне самому потребовалось средство для визуализации тем, глав и связей между ними. Так у меня получился граф знаний, который показывает 222 глав и 820 связей между ними. Каждый узел - это глава книги, а линия - смысловая связь между материалами. Связи строятся по перекрёстным ссылкам внутри контента глав: MarginNote на полях справа, ссылки из блоков "связанные главы" в конце глав и ссылки, что раскиданы по тексту статьи. Я планирую в будущем добавить в этот граф возможность выбора траекторий изучения, но пока он работает попрощ - Клик по кластеру в сайдбаре приводит к зуму и фокусу на главы из этой темы, а остальные главы затемняются - Клик по ноде в графе открывает панель с деталями главы, списком связанных глав и появляется кнопка перехода к материалу - Скролл / pinch позволяыт зумить. При приближении появляются названия глав - Перетаскивание - можно передвигаться по графу или если потянуть за отдельный узело, то можно его перместить - Цвета узлов соответствуют своим темам (кластерам) - По разному отмечаются связи внутри кластера и между кластерами + сами связи направленные - Для отрисовки графа используется force-directed layout (d3-force): узлы отталкиваются друг от друга, а связи притягивают. В итоге связанные главы оказываются рядом, а изолированные - на периферии. Я использовал этот граф сам для того, чтобы проверить, что у меня я сам не забыл добавить кросс-ссылки между темами (на самом деле забыл и граф мне позволил это исправить). #SystemDesign #Architecture #DistributedSystems #Career #Interview #Engineering

Science Museum (Рубрика #Travel) Были в будний день в Музее Науки в Лондоне и это было очень круто. Музей расположен рядом с Имперским колледжом Лондона, насчитывает пять этажей и каждый этаж посвящен своей теме. Сам вход в музей бесплатный, но можно пожертвовать сколько хочешь. Мы пришли за два часа до закрытия и практически бегом пробежали экспозиции инжиниринга, космоса, полетов, компьютеров, медицины и на выходе успели еще купить подарки детям. В следующее посещение Лондона мы сюда обязательно зайдем, но уже вместе с детьми. #Science #Museum #ForKids #ForParents #Culture