Книжный куб

Zero to One (От нуля к единице. Как создать стартап, который изменит будущее) (Рубрика #Startups) Прочитал интересную книгу Питера Тиля, со-основателя PayPal и Palantir, еще 2014 года, которая является конспектом его курса в Stanford, который он читал за пару лет до этого. В этом курсе Питер обсуждал не рецепты успеха, а говорил про сдвиг мышления: как из технологии сделать новую категорию, а не ещё один продукт, что будет чуть лучше, чем у конкурентов. В 2010 году эта книга пришлась ко двору во время бума венчура и стартап‑культуры - всем хотелось поймать "следующего единорога", а книга требовала делать наоборот: искать уникальность и строить защитный ров вокруг своей идеи. В книге было много ярких формулировок, например, вокруг того, что "конкуренция - это для лузеров", а это привело к тому, что они стали вирусными и разошлись на цитаты. В общем, с точки зрения маркетинга идей книга была хороша. С тех пор многое поменялось, но ее до сих пор полезно прочесть и подумать над идеями вроде 1️⃣ Идея "0→1 vs 1→n" Вообще, название книги противопоставляет идею создания чего-то нового с нуля (0→1) и идею дальнейшего масштабирования и улучшения (1→n). По мнению Питера ценность часто в 10x скачке за счет архитектуры, алгоритмов, UX, стоимости или надёжности и т.д., а не в бесконечной полировке продукта 2️⃣ Идея секретов Эта идея крутится вокруг важной истины в вашей области, что неочевидна большинству. Собственно, это очень напоминает мышление from the first principles, когда можно взглянуть на ситуацию не через стереотипы, а шире и найти нестандартное решение 3️⃣ Про пользу монополий по сравнению с идеальной конкуренцией У Тиля очень нестандартный взгляд на монополии и кокуренцию. Я думаю, что это особенность позиции большого капиталиста, но он говорит про творческое преимущество, а не про возможность задушить рынок. Для него монополия - это идея вокруг того, а почему вас сложно повторить (данные, интеграции, сеть, стандарты, бренд, скорость поставки). 4️⃣ Про важность дистрибуции У Тиля это часть системы - можно собрать идеальный движок, но без канала доставки ценности он не станет продуктом. Но про остальные процессы для рабочего продукта он почти не говорит. Если посмотреть, а как менялись подходы к венчуру после выхода книги, то получим примерно такой таймлайн - 2014–2019: Lean/MVP + рост → затем мода на blitz scaling (захватим рынок, потом оптимизируем) - 2020–2021: дешёвые деньги → мегараунды, гонка оценок, “growth at all costs” - 2022→ now: разворот к эффективности и юнит‑экономике: burn, выручка, маржа, путь к прибыльности снова стали "first-class metrics" - 2023→ now: AI‑волна усилила запрос на реальные рвы (данные, модели, доступ к compute) и честный GTM (go-to-markt), а не просто красивую историю Какие вопросы можно задать себе как руководителю - Какой секрет мы видим в нашем продукте? - Где наш потенциальный 10x? - Почему нас сложно скопировать - и как мы доставим ценность пользователю? #Startup #Management #Leadership #Economics #Engineering

Студия, где снимали Гарри Поттера Вчера с Настей были в студии Warner Brosers под Лондоном, где снимались все книги про Мальчика, что выжил. Посмотрели на павильоны, интерьры, костюмы, спецэффекты и нам все очень понравилось. Видно, что была проделана огромная работа, но в результате получилась легендарная экранизация. В мае приедем сюда же, но уже с детишками.

The Rise and Rise of FastAPI (Рубрика #API) Интересная мини‑документалка о FastAPI, которая длится меньше 10 минут. В ней говорится о том, как FastAPI прошел путь сверхбыстрого роста open source проекта по траектории вида: side‑project → "индустриальный дефолт" для API на Python. После документалки мне стало интересна судьба этого проекта и кажется, что FastAPI "выстрелил" не потому что "он fast", а потому что собрал в одном месте: - Стандарты** (ASGI, OpenAPI/JSON Schema) - Типизацию как интерфейс** (type hints → Pydantic модели) - DevEx как продукт (авто‑документация, предсказуемые ошибки, быстрый старт) - Композиционную архитектуру (Starlette‑стек, middleware, зависимости) В итоге, для команд, что его используют результаты выглядят так, что у них меньше боли на границах ответственности (APE endpoints) + быстрее интеграции + быстрее онбординг Если говорить про вехи развития проекта, то получится следующее 1️⃣ Side‑project → фреймворк Фокус был на создании "API без боли": валидируй вход, сериализуй выход, документируй автоматически 2️⃣ Технический стержень - ASGI‑модель (современная I/O‑архитектура) - Starlette как "тонкий" веб‑слой - Pydantic как слой данных: строгая валидация/сериализация поверх type hints 3️⃣ Контракт становится "живым артефактом" - OpenAPI генерится из кода. - Интерактивная документация /docs и /redoc делает API‑контракт частью ежедневной разработки, ревью и интеграций 4️⃣ Снежный ком крутого DevEx (developer experience) - Шаблоны, практики, интеграции, “как правильно” из коробки. - Порог входа падает → adoption растёт. 5️⃣ Взросление и коммерциализация вокруг поддержки - Когда популярность становится инфраструктурой для бизнеса, неизбежно появляются: поддержка, консалтинг, managed‑подходы, облака и т.п. - Это меняет ожидания: "фреймворк" → "платформа вокруг фреймворка". Если раскрывать ключевые инсайты подробнее, то получаем примерно так 1) FastAPI - это "композиция стандартов + DX", а не "магия" FastAPI не "заменяет архитектуру". Он фиксирует удачный дефолт: типы → модели → валидация/сериализация → схема → документация. По итогу у нас становится меньше неявных договорённостей и "случайных JSON" 2) Контракт‑ориентированная разработка - становится нормой OpenAPI в FastAPI - не "дока на потом", а контракт в процессе: - Проще подключать фронт - Проще делать партнёрские интеграции - Проще ревьюить изменения В итоге, скорость и надежность на другом уровне 3) Производительность - следствие правильной I/O‑модели, а не цель ASGI + async дают выигрыш только если вы: - Не блокируете event loop - Используете правильные драйверы/клиенты - Умеете проводить границы sync/async Правда, "async ради async" = быстрый путь к деградации и непредсказуемым p95/p99 4) OSS‑рост почти всегда приводит к вопросу устойчивости Если фреймворк становится критическим для тысяч компаний, возникает давление: - На поддержку - На эксплуатационные "best practices" - На продуктовую упаковку вокруг деплоя/наблюдаемости В итоге, с точки зрения технического руководителя это уже не просто "выбор библиотеки", а уже управление зависимостью На сайте system-design.space есть чуть более подробный разбор. #Engineering #Architecture #DistributedSystems #Software #SoftwareArchitecture

A Brief History of Bjarne Stroustrup, the Creator of C++ (Рубрика #Engineering) Интересная история Бьярне Страуструпа, датского учёного в области информатики, автор языка программирования C++. Вся история снята в городке Орхус (Дания), где он родился в 1950 году и учился в университете Орхуса, там же получил магистерскую степень. Дальше он защитил PhD в Кембридже, а затем работал в Bell Labs рядом с Керниганом, Ритчи, Моррисом и др. Ниже интересные моменты про его биографию, не все из которых я знал - В программирование Бьярне попал "случайно": выбрал направление "математика с датологией", не понимая, что "datologi" - это компьютерные науки - На него сильно повлиял Кристен Нюгорд (Kristen Nygaard), создатель Simula и концепции объектно‑ориентированного программирования; идеи структурирования кода в Simula до сих пор для него опорные. - В Bell Labs Бьярне интересовался операционными системами и архитектурой машин и, не найдя подходящего языка, решил "сделать свой". - Первый вариант языка назывался "C with Classes" - фактически C с классами в стиле Simula; затем название сменили на C++ (оператор инкремента в C), потому что это было "милое и необычное" имя. Не забыли они обсудить и сам C++, его предназначение и историю развития - В какой‑то момент Бьярне знал около 24 языков программирования (Snowball, Algol 68, PL/I, PL/360 и др.) - правда, он говорит, что раньше языки было проще изучать, т.к. у них не было огромного "багажа" и экосистемы. - Бьярне описывает философию C++ метафорой: "я должен был вырастить сорняк, а не розу", т.е. язык, который выживает и растёт без постоянного "полива" автором. - Особенно гордится тем, что у C++ не было маркетинговой кампании и "спонсора" - язык распространялся органично, через пользу и сообщество. - Через 10 лет после появления у C++ было уже около миллиона пользователей, а сейчас оценивается порядка 7 миллионов инженеров, использующих язык. В итоге, я себе отметил моменты 1. Роль случая - это про вход в профессию и что серьёзные карьерные траектории в ИТ часто начинаются не с продуманного плана, а с любопытства и случайного выбора. 2. Сила хороших идей и наставников - это про встречу с Нюгордом и знакомство с Simula и что один сильный ментор и одна сильная идея (ООП в Simula) могут задать направление целому поколению технологий. 3. Создание инструмента "для себя", а не для рынка - это про то, что фокус на реальной инженерной боли, а не на маркетинге, может дать шанс, что инструмент станет стандартом де‑факто. 4. Устойчивость важнее "идеальности" - тут метаформа сорняка говорит о том, что проектирование для реального мира, а не идеальной академической конструкции приводит к тому, что выживает тот, кто успешно работает в проде, а не на бумаге 5. Рост без маркетинга - это про то, что для инфраструктурных технологий органическое принятие и решённые задачи ценнее пиара. 6. Отношение к работе и мотивация - Бьярне продолжает учить, выступать и писать код, потому что ему "просто интересно видеть, как это используется, и приятно общаться с людьми". В итоге, долгосрочная мотивация строится на удовольствии от процесса и ответственности за последствия своей работы. #Engineering #Software #Management #Leadership #Architecture

Путешествие в Лондон Вчера мы сначала 10+ часов летели в Лондон с пересадкой в Баку, а потом целый день бродили по нему. Была отличная погода: солнышко, +10 градусов и запах весны. В итоге, мы находили порядка 20 тысяч шагов и успели прогуляться по центру города и вернуться в номер. Часов в 20 по местному времени мы отключились, а сегодня утром идем на персональную экскурсию по Лейстер square. В обшем, эту неделю я побуду в роли туриста, а не технического директора (но материалов для tg-канала я приготовил заранее достаточно, так что вам все еще будет, что посты будут продолжаться и во время моего отпуска) #Travel

How to be a CEO when AI breaks all the old playbooks | Sequoia CEO Coach Brian Halligan (Рубрика #Management) Интересная серия подкаста Лённи, в котором к нему пришел Брайан Холлиган, со‑основатель и экс‑CEO HubSpot. Они обсудили каким становится лидерство и бизнес в эпоху ИИ: как нанимать, расти и продавать, когда старые плейбуки трещат по швам. Брайан был CEO 15 лет, а теперь выступает как внутренний CEO‑коуч в Sequoia и ведёт подкаст про лидеров Long Strange Trip. Основные инсайты примерно такие 1️⃣ Стартовая компанию проще, чем когда‑либо; масштабировать - сложнее, чем когда‑либо ИИ и облака кратно удешевили запуск, поэтому число компаний взлетит в небеса в ближайшие 10 лет, но шум и конкуренция делают масштабирование и дифференциацию всё труднее 2️⃣ Работа CEO → бесконечный найм и орг‑дизайн "Взрослые CEO" тратят до половины времени на рекрутинг, интервью и конструкцию exec‑команды, а не на продукт или операционку. 3️⃣ Все ужасно переоценивают своё умение интервьюировать Инстинкт "мне кажется, он классный" почти ничего не стоит; куда важнее жёсткие blind‑references, рабочие сессии с кандидатом и правильные вопросы про повторный найм 4️⃣ Нужно нанимать "острых" (spiky), а не консенсусных людей HubSpot перестал использовать консенсус в виде "3/4 от всех голосов" и начал брать людей с сильными плюсами и заметными минусами; это улучшило хит‑рейт 5️⃣ Люди из bigtech почти всегда не заходят компаниям на ранней стадии Найм из Microsoft/Salesforce/Google на компанию в 50–500 человек часто даёт "импеданс‑мисмэтч": ожидания процесса и ресурсов не совпадают с реальностью стартапа 6️⃣ Базовый плейбук - команда как Red Sox‑2004: микс homegrown и пары "звёзд" Большая часть менеджмента вырастает изнутри, плюс несколько дорогих ветеранов, а не "ковёр‑самолёт" из McKinsey/FAANG. 7️⃣ Фреймворк LOCK(S) для оценки фаундеров - L (lovable): хочется за этим человеком идти, он вдохновляет последователей - O (obsession): глубоко одержим проблемой, сильный founder–market fit - C (chip on the shoulder): серьёзный "чип на плече", внутренняя мотивация "доказать". Тут интересно, что я раньше не знал эту идиому и она мне нравится (кажется, что я лучше всего работаю, когда у меня есть такое чувство) - K (knowledge): глубокое знание домена - S (student): фанатичный студент игры, копает и историю, и современность 8️⃣ CEO может стать не любой, но одновременно и ими не только рождаются Есть редкие "5‑tool CEOs", которые умеют кодить, продавать, вдохновлять, иметь вкус и видение (пример - Брет Тейлор), но большинству приходится добирать умения: обратная связь, детектор BS, вдохновение людей. 9️⃣ Боль №1 у фаундеров - давать фидбек и менять ранних сотрудников Самое тяжёлое - сказать кофаундеру/раннему head of X: "ты больше не управляешь, ты - визионер/CTO, а мы нанимаем операционного лидера над тобой" и сделать это экологично, но жёстко 🔟 ИИ уже сильно бьёт по разработке и саппорту, но не по enterprise продажам Кодинг, support, legal уже трансформируются, а enterprise‑продажи, где нужно доверие между двумя людьми, будут последними в белых воротничках, кого заменит ИИ. Но вообще у всех будут свои персональные агенты, подключённые к почте, календарю и заметкам, которых можно звать в митинги как активного участника, а не просто как запись Ну и финально про воронку go-to-market, которая становится ориентирована на агентов - Воронка "Google → сайт → demo" сменится на "Gemini/Claude/ChatGPT → глубокое исследование → уже образованный клиент". Сайт станет менее важен - На сайте будет "всезнающий аватар", который понимает продукт, цены и контекст клиента, ведёт беседу и пишет в CRM - У сейлза на созвоне будет свой "аватар", который знает всё о продукте и клиенте и помогает отвечать в реальном времени В продолжении я расскажу про то, а что можно почерпнуть из этого выступления инженерам и техническим руководителям. #Leadership #Management #Software #AI #ML

Laravel Origins: A PHP Documentary (Рубрика #Engineering) Интересный документальный фильм про фреймворк Laravel, который по моему ощущению занял нишу Ruby on Rails, но вместо Ruby тут языком выступает PHP. В фильме присуствуюте ключевые люди и именно они рассказывают историю развития проекта. Например, одна из главных ролей за Taylor Otwell, что создал Laravel и сейчас выступает как BDFL фреймворка ("benevolent dictator for life"), также там есть Jeffrey Way (автор образовательного ресурса Laracasts), Dayle Rees (автор первых книг по Laravel) и другие. Мы видим последовательное развитие истории: - Сначала жизнь и работу Тейлора в Арканзасе, а дальше старт проекта Laravel от caravel, где была изменена одна буква в названии коробля - Ранний рост проекта: первые GitHub‑звезды, переход UserScape на Laravel, полугодовой период, когда Тейлор фактически фуллтайм развивал фреймворк в рамках работы - Формирование экосистемы: очереди, миграции, пакеты, затем вокруг ядра вырастают Laravel Forge, Envoyer, Spark, Nova, Vapor, которые закрывают полный цикл от разработки до деплоя. - Комьюнити и медиа: книги Dayle Rees, Laracasts, Laravel News, агенства вроде Tighten, появление Tailwind CSS - как побочный эффект культуры "делать инструменты для других девелоперов" - Конференции и культура: Laracon в США, Европе, Австралии, "Laracation" как неформальные поездки, ощущение "как любимая группа в городе", а не корпоративное мероприятие. - Социальный эффект: карьеры тысяч людей, компании уровня Apple, госструктуры США и крупные бренды (например, Winter Olympics API, Boston Celtics) на Laravel. Ключевые инсайты из фильма такие - Видно, как Laravel вырос как решение собственных болей Тейлора - поэтому факторы скорости, продуктивности и "fun to use" стали ядром продуктового видения, а не были выстроены от маркетинга - Сильное, единое видение ("benevolent dictator for life") позволяет фреймворку быть цельным, последовательно эволюционировать и избегать scope creep и дрифта базовых концепций - DevEx как продукт: документация, выразительный синтаксис, консистентная эстетика кода (вплоть до формата комментариев) - сознательно воспринимаются как конкурентное преимущество - Коммерческая экосистема не подменяет open‑source, а дополняет его: SaaS‑продукты ведёт команда, а Тейлор фокусируется на ядре и R&D, что сохраняет качество фреймворка Отдельно видно, что коммьюнити вокруг Laravel сложилось крепкое и отсюда тоже можно извлечь инсайты - Осознанный дизайн культуры: с первого дня цель - "дружелюбное, chill, welcoming" сообщество, где люди чувствуют принадлежность и не боятся задавать вопросы - Конкуренция за вклад "в плюс миру": участники соревнуются в количестве бесплатных материалов, тулов и библиотек, а не в токсичности или статусе - Инклюзивность как практическая работа: создание Larabelles и других инициатив для вовлечения всех в профессию и коммьюнити - Сообщество как социальный капитал: люди обсуждают, как Laravel поменял их жизнь Для технического руководителя это напоминание о том, что - Хороший фреймворк - это не только API, но и эстетика, документация, DX и осознанное лидерство; это так же важно, как техническая "чистота" - Сильное ядро + продуманная коммерческая надстройка позволяют маленькой команде (порядка пяти человек) поддерживать огромную экосистему и влиять на индустрию - Сообщество и образовательная инфраструктура (типа Laracasts) критичны для adoption не меньше, чем сам код, особенно в мире, где каждые пару лет приходит новая волна девелоперов - Инклюзивная, по‑настоящему дружелюбная культура вокруг технологии может стать решающим фактором её популярности и longevity, а не только технические фичи #Documentary #Software #Architecture #Leadership #Culture #Management

Дискуссия с Гришей Скобелевым про подготовку к System Design Interview (Рубрика #Architecture) На этих выходных мы с Гришей из клуба { между скобок} поговорили про подготовку к System Design Interview и про то, как я дошел до жизни такой, что собрал сайт system-design.space. Основные моменты, что мы успели обсудить следующие ​ - Книга по System Design быстро устаревает: паттерны и требования меняются, а живой сайт можно непрерывно допиливать под практику, а не под "вечную теорию" ​- Ожидания на интервью сдвигаются от "знаешь ли ты стандартный набор сервисов и buzzwords" к умению думать как архитектор: трезво выбирать компромиссы, задавать вопросы, формализовывать требования - Разобрали типовые ошибки кандидатов​ - - Сразу рисовать «кубики и стрелочки» без уточнения ограничений, - - Оптимизировать за пределами реальных bottleneck’ов - - Заучивать шаблоны задач вместо понимания инвариантов (consistency, durability, latency budgets и т.д.) ​- System Design интервью на самом деле проверяет не "знаешь ли ты Kafka", а: как ты принимаешь решения, как разговариваешь с продакт менеджером, как эволюционируешь систему от MVP до сложной архитектуры ​- Разница между "рисованием кубиков" и архитектурным мышлением: во втором случае ты всегда привязываешь решения к пользовательским сценариям, нагрузке, отказоустойчивости и стоимости владения, а не просто перечисляешь модные технологии ​- Для senior/staff обязательны темы: масштабирование хранения и вычислений, очереди и асинхрованная работа, кэширование, консистентность, observability, эволюция схемы данных и rollouts, а также работа с неопределённостью и неполными требованиями ​- Готовиться нужно не "по чек-листу задач", а системно: строить свой набор инвариантов и шаблонов мышления, прогонять реальные кейсы, а не просто зубрить решения. ​ Если говорить про инсайты для руководителей, которыми можно поделиться, то - Интервью по SD стоит перестраивать с "угадай сервис" на разбор реального кейса: дать неполные требования, посмотреть, как кандидат уточняет, режет scope и развивает архитектуру итеративно ​Хорошее SD-интервью - это мини-совместное проектирование: вы вместе выходите хотя бы к первому адекватному приближению системы, а не к идеальной картинке из учебника. ​- Стоит явно формализовать, какие уровни архитектурного мышления вы ждёте от middle/senior/staff, и дать людям прозрачную лестницу роста (в идеале - с примерами на внутренних кейсах). ​- Вместо того чтобы ждать от команды "чтения книг по SD", проще дать живую базу практик, чек-листы и разборы постмортемов - то есть institutional knowledge, а не набор ссылок на классические книги. ​ #SystemDesign #Architecture #DistributedSystems #Career #Interview #Engineering

[2/2] OpenClaw Creator: Why 80% Of Apps Will Disappear (Рубрика #AI) Интервью было очень интересным и прорывным, но всегда интересно, а как перевести эти идеи в практическое русло. Для разработчиков отсюда можно извлечь следующее Если ваш продукт можно выразить как операции - агент сможет "съесть" ваш UI. Поэтому фокус смещается на “agent-ready интерфейсы”: - Tool-first мышление: превратите ключевые фичи в чёткие операции (CRUD/поиск/экспорт/триггеры), которые можно дергать напрямую. Минимум - хорошая CLI или SDK + примеры. - Документация "как для агента": понятные help‑тексты, примеры входов/выходов, ошибки, ограничения, idempotency там, где возможно. - Нормализуйте “опасные входы”: prompt injection и неожиданные действия - это базовый режим, если агент читает DMs/почту/веб. Тестируйте это как часть фичи, а не как edge case. - Локальная память = новый тип "секрета": думайте, что именно агент сохраняет, где лежит workspace, как чистится и бэкапится. Если хочется посмотреть а как это работает, то можно поднять OpenClaw локально/на тестовом сервере, подключить один канал, включить pairing/allowlist, запретить опасные tool‑группы и прогнать 3 сценария: "поиск/сводка", "операция с файлами", "задача через браузер". А дальше уже оценить насколько это удобно/безопасно/перспективно. Что это значит для техлидов и технических руководителей - Пересоберите threat model: "агент с инструментами" - это RPA + LLM + доступ к секретам. Нужны политики: где хранятся ключи, какие каналы доверенные, какие действия требуют подтверждения, как устроена изоляция сессий/пользователей. - Вводите governance по памяти: ретеншн, классификация данных, экспорт/удаление, audit trail - это станет не менее важным, чем логирование микросервисов. - Контроль экономики агентности: агентные циклы могут неожиданно "жечь" стоимость из-за контекста/памяти/инструментов. Нужны лимиты, бюджеты, режимы, мониторинг. Стратегия продукта: если тезис про "80% apps" хотя бы частично верен, дифференциаторы смещаются в (а) данные/память (б) безопасные интеграции (в) доверие/комплаенс (г) hardware/sensors/сообщества #AI #Engineering #Software #Management #Leadership #Startup #LLM #ML #Architecture

[1/2] OpenClaw Creator: Why 80% Of Apps Will Disappear (Рубрика #AI) Интересное и короткое интервью Peter Steinberger, создателя OpenClaw (недавно перешедшего в OpenAI) проlocal-first персональных агентов и то, как они могут "съесть" большую часть привычного софта. Интервью у него брал Raphael Schaad, Visiting Partner в Y Combinator; основатель/CEO Cron (проект купил Notion). Ниже представлены основные инсайты 1️⃣ Local-first агент ≠ «ещё один чат-бот» Агент живёт на вашей машине/вашем сервере, поэтому может быть шлюзом между чатами и вашими инструментами: файлы, shell, браузер, интеграции - "всё, что может пользователь на компьютере". Это принципиально другой класс возможностей по сравнению с облачным ассистентом. Забавно, что создатель Manus AI рассказывал о том, как они ушли от локального агента в браузере в облако, чтобы отвязаться от локальной машинки:) 2️⃣ Магия - это tool-use + выбор кратчайшего пути Самый показательный кейс из интервью: голосовое сообщение внезапно само транскрибировалось, хотя функциональность "явно не кодили заранее". Агент сам сделал следующие шаиг - Определил формат аудио по заголовку (даже без расширения) - Перегнал через ffmpeg - Не стал ставить локально Whisper, а выбрал быстрый путь - отправить аудио в speech-to-text API через curl, потому что так быстрее получить результат В итоге, по мнению Питера конкурентное преимущество смещается от "самой умной модели" к инструментам, оркестрации и данным/памяти пользователя 3️⃣ "80% приложений исчезнет" - речь про приложения‑контейнеры данных Смысл тезиса не в том, что UI умрёт. А в том, что приложения, чья основная функция - ввод/хранение/менеджмент данных, становятся избыточными, если агент: - Сам собирает контекст (файлы/логи/фото) - Пишет/читает из хранилищ - Планирует/напоминает - И делает результат без отдельного “перехода в приложение”. Отдельно проговаривается идея, что выживут продукты, сильно завязанные на специфическое железо/сенсоры. 4️⃣ Главная ценность и риск - "память" агента Если агент становится персональным, то его “memory” - привычки, контекст, история действий, локальные файлы - это новый приватный периметр. В отчёте подчёркнуто, что такие memory‑файлы могут быть "более приватными", чем условная поисковая история. Также упоминаются файлы вроде SOUL.md / AGENTS.md / TOOLS.md как часть "инжектируемого" контекста в workspace. 5️⃣ CLI как универсальный "адаптер" для агента Одна из инженерных мыслей, что противоречит текущему вектору: вместо специальных протоколов интеграций агентам часто достаточно обычных человеческих инструментов - CLI. Если есть --help, примеры и предсказуемые команды - агент часто "разберётся". В отчёте это подано как практичный вектор (в т.ч. обсуждение CLI vs MCP). 6️⃣ Security - не "потом", а сразу Агент, который читает чаты/веб и имеет доступ к shell/файлам/браузеру, резко расширяет поверхность атаки. В отчёте много акцентов на базовых контролях: threat model, изоляция, allowlist, аудит, sandboxing, политики для DMs, защита от prompt injection. В продолжении обсудим, а что из этого интервью могут почерпнуть инженеры и технические руководители #AI #Engineering #Software #Management #Leadership #Startup #LLM #ML #Architecture

Мюзикл на чердаке (Рубрика #Culture) Были вчера с женой на этом мюзикле в Детском музыкальном театре "Поколение" и нам очень понравилось. У нас случилась накладка по расписанию и мы оба ехали туда отдельно и опоздали - я на 10 минут, а жена на полчаса, но как мы добрались нас сразу впустили в зал и мы смогли насладиться концертом, в основе которого знакомые с детства шлягеры в жанре мюзикла. По легенде спектакля брат и сестра спрятались от своей мамы на чердаке и нашли кассету с хитами мировых мюзиклов - а дальше музыка начинает оживать вокруг них. Мне понравились все хиты, но особо части про призрака оперы (когда ехали обратно, то слушали Nightwish), а Насте понравилась песня из диснеевского мультика "Русалка". В общем, я непрочь и повторно сходить на этот же спектакль еще раз, но мы решили съездить с детишками в этот театр на спектакль попроще и покороче (этот был 12+ лет и длился 2.5 часа). #ForParents #ForKids

Modular Monoliths and Other Facepalms - Kevlin Henney - NDC London 2026 (Рубрика #Architecture) Интересное видео Kevlin Henney, где он выступает евангелистом монолитов, модульных монолитов:) Если сокращать, то он говорит, что проблема была не в монолитах, а в запутанных зависимостях и размытых границах. Союственно, микросервисы не лечат плохую декомпозицию. Но они просто делают ошибки дороже (сеть, консистентность, наблюдаемость, эксплуатация). Забавно, что свой первый монолит в Т-Банке я начал пилить как раз для того, чтобы довести эту стоимость до предела и перейти Рубикон (первая бекенд система, что мне досталась была сделана фронтедерами для фронтендеров и напоминала лапшу - по-другому выставить границы было нельзя).Но если возвращаться к рассказу Кевлина, то его совет в том, чтобы начинать с хорошо структурированного модульного монолита → и только потом (если есть устойчивые драйверы) выделяйте сервисы. Отдельно мне понравилась история вокруг эволюции подходов, так как я сам люблю так выстраивать сторителлинг для своих докладов - 1972 - Дэвид Пэрнас: критерии декомпозиции + information hiding (прячем то, что часто меняется) - 1974 - Лисков и Зиллс: abstract data types (ADT), работа с абстракциями данных - 1997 - Foote & Yoder: антипаттерн Big Ball of Mud (система "уползает" в комок без дисциплины) - 2014 - Fowler/Lewis: микросервисы как набор independently deployable сервисов (а не "мелкие модули по сети") - 2014+ - Simon Brown: предупреждение про distributed big ball of mud Если говорить про инсайты, то они примерно такие 🧩 Модульность - свойство кода и зависимостей, а не инфраструктуры Если внутри одного процесса вы не удерживаете границы, микросервисы не спасут - они просто добавят частичные отказы и сложность диагностики. 🕸 Архитектура проявляется в зависимостях сильнее, чем в диаграммах Значит архитектуру можно (и нужно) делать проверяемой: правила → CI → "ломаем билд" на нарушениях. 🧩 “Монолит” становится проблемой, когда он превращается в tangled monolith То есть не "один деплой" плохо, а переплетённость (циклы, обход границ, случайные импорты, нарушение слоёв). 🤑 Микросервисы - это инвестиция (техническая + организационная). Они оправданы, когда реально нужно независимо деплоить, изолировать изменения, масштабировать по частям, разводить ответственность команд. Если драйверов нет - вы покупаете overhead без выигрыша. Для разработчиков следуют такие практические выводы - Цель: сделать “границы” реальными, а не декоративными Модуль = единица эволюции, а не папка. Есть публичный API, есть скрытая внутрянка, есть запреты на “обход”. - Направление зависимостей важнее названий слоёв Следите за циклами, “обратными” ссылками, протеканием инфраструктуры в домен. Для технических руководителей следуют такие практические выводы Архитектурные ярлыки не заменяют управления границами. Если мотивация “давайте микросервисы, чтобы код разделился сам” - это красный флаг. Сначала: границы, ownership, правила, ревью‑политики, архитектурные тесты. Микросервисы по определению увеличивают: - Число deploy‑единиц - Количество коммуникаций - Требования к CI/CD, observability, security, data contracts Стратегия, которая обычно работает лучше: - Modular monolith - дефолт - Microservices - осознанная инвестиция при устойчивых драйверах P.S. Как обычно, расширенная версия есть на system-design.space. #Architecture #Software #DistributedSystems #Engineering #Management

Как взять идеи Google и построить себе похожий контроль качества архитектуры (Рубрика #Architecture) В прошлом посте мы разбирали whitepaper от ребят из Google "Understanding Architectural Complexity, Maintenance Burden, and Developer Sentiment - a Large-Scale Study". А сейчас я хотел бы поговорить про практические шаги, что можно сделать у себя в компании, если вы не Google, но тоже хотите контролировать качество архитектуры и размер техдолга. 1️⃣ Сформулируйте "maintenance burden" так, чтобы его можно было считать Самый практичный вариант - доля багфиксов vs фич за период: - % задач типа Bug в трекере - % PR/коммитов, привязанных к Bug - % LOC (или хотя бы файлов), изменённых ради Bug 2️⃣ Соберите минимум данных (обычно уже есть) - Git/PR-логи: кто/когда/что менял (changed files, размер). - Issue tracker (Jira и т.п.): тип задачи (bug/feature), компонент/сервис, команда. - Dependency graph: зависимости между пакетами/модулями/сервисами (из build graph, import graph, API calls). - Active coding time по задачам или DAT (Diff Authoring TIme), которым так хвалилась запрещенная в России Meta и про который я уже рассказывал - Если нет Active Coding Time, то начните с прокси: lead time PR, время ревью, размер batch’ей (а потом все-таки соберите ACT) 3️⃣ Архитектурные метрики: начните "дёшево", потом усложняйте Метрики из приведенного выше whitepaper конечно крутые, но сложные. Я говорю про - Propagation Cost (PC): насколько широко расползаются изменения по зависимостям - Decoupling Level (DL): насколько хорошо система декомпозирована на независимые модули В академии есть DV8 от авторов оригинального исследования (Yuanfang Cai, Rick Kazman) или условный Sonar в качестве коммерческого инструмента. Но для старта хватит - Отслеживать циклы на уровне модулей/сервисов (SCC) - Считать fan-in/fan-out, транзитивный fan-out - Отслеживать co-change кластеры: файлы часто меняются вместе, хотя "по архитектуре" не должны По правилу Парето мы так найдем 20% проблем, что приносят 80% боли 4️⃣ Склейте всё в регулярный отчёт (по кварталам/месяцам) На уровне repo/сервиса/команды: - Тренд coupling/циклов/co-change - Тренд bugfix ratio - Микро-опрос 1 вопрос раз в квартал: "насколько техдолг/сложность мешали вам работать?" Важно искать не виноватых, а проблему в системе: high coupling + растущий bugfix ratio = кандидат #1 на тех-инвестиции Если воспользоваться этим алгоритмом, то у вас будет набор карт на руках, с которыми никакой техдолг не страшен - У вас будут аргументы для рефакторинга в цифрах (и разговор с бизнесом пройдет на понятном им языке) - У вас будет внятная приоритизация: какие 2–3 hotspot’а чинить в первую очередь - Вы увидите ранние сигналы деградации: поймаете тренды до того, как команда уйдёт в вечный багфикс - Вы улучшите DevEx и скорость доставки фич как следствие Но важно не облажаться и не наступить в анти-паттерны - Не превращайте метрики в KPI людей/команд - будет гейминг - Не ставьте одинаковые абсолютные пороги по метрикам - нужны базовые нормы "что ок" для вашего домена; - Не пытайтесь получить одну метрику техдолга - он многомерен и метрики - это сигнал, а не приговор. Дальше нужны дизайн‑ревью и инженерная оценка найденных проблем Если бы я делал это в компании, то попробовал бы - Катануть пилот на 10–20 репозиториях/сервисах - Собрал бы базовую панель метрик, перечисленных выше - Подождал сбора результатов, напрмер, квартал - Дальше сделал бы точечные рефакторинги (благо сейчас рефакторинг становится сильно дешевле, если его делать с помощью AI-инструментов) - Сравнил бы "до/после" по bugfix ratio и скорости доставки - Если бы метрики улучшили, то планировал бы дальше раскатку В общем, с точки зрения алгоритма примерения тут нет никакого rocket science, но дьявол кроется в деталях:) #Engineering #Software #Bigtech #Productivity #Management #Leadership #Processes

A Brief History of Bjarne Stroustrup, the Creator of C++ (Рубрика #Engineering) Интересная история Бьярне Страуструпа, датского учёного в области информатики, автор языка программирования C++. Вся история снята в городке Орхус (Дания), где он родился в 1950 году и учился в университете Орхуса, там же получил магистерскую степень. Дальше он защитил PhD в Кембридже, а затем работал в Bell Labs рядом с Керниганом, Ритчи, Моррисом и др. Ниже интересные моменты про его биографию, не все из которых я знал - В программирование Бьярне попал "случайно": выбрал направление "математика с датологией", не понимая, что "datologi" - это компьютерные науки - На него сильно повлиял Кристен Нюгорд (Kristen Nygaard), создатель Simula и концепции объектно‑ориентированного программирования; идеи структурирования кода в Simula до сих пор для него опорные. - В Bell Labs Бьярне интересовался операционными системами и архитектурой машин и, не найдя подходящего языка, решил "сделать свой". - Первый вариант языка назывался "C with Classes" - фактически C с классами в стиле Simula; затем название сменили на C++ (оператор инкремента в C), потому что это было "милое и необычное" имя. Не забыли они обсудить и сам C++, его предназначение и историю развития - В какой‑то момент Бьярне знал около 24 языков программирования (Snowball, Algol 68, PL/I, PL/360 и др.) - правда, он говорит, что раньше языки было проще изучать, т.к. у них не было огромного "багажа" и экосистемы. - Бьярне описывает философию C++ метафорой: "я должен был вырастить сорняк, а не розу", т.е. язык, который выживает и растёт без постоянного "полива" автором. - Особенно гордится тем, что у C++ не было маркетинговой кампании и "спонсора" - язык распространялся органично, через пользу и сообщество. - Через 10 лет после появления у C++ было уже около миллиона пользователей, а сейчас оценивается порядка 7 миллионов инженеров, использующих язык. В итоге, я себе отметил моменты 1. Роль случая - это про вход в профессию и что серьёзные карьерные траектории в ИТ часто начинаются не с продуманного плана, а с любопытства и случайного выбора. 2. Сила хороших идей и наставников - это про встречу с Нюгордом и знакомство с Simula и что один сильный ментор и одна сильная идея (ООП в Simula) могут задать направление целому поколению технологий. 3. Создание инструмента "для себя", а не для рынка - это про то, что фокус на реальной инженерной боли, а не на маркетинге, может дать шанс, что инструмент станет стандартом де‑факто. 4. Устойчивость важнее "идеальности" - тут метаформа сорняка говорит о том, что проектирование для реального мира, а не идеальной академической конструкции приводит к тому, что выживает тот, кто успешно работает в проде, а не на бумаге 5. Рост без маркетинга - это про то, что для инфраструктурных технологий органическое принятие и решённые задачи ценнее пиара. 6. Отношение к работе и мотивация - Бьярне продолжает учить, выступать и писать код, потому что ему "просто интересно видеть, как это используется, и приятно общаться с людьми". В итоге, долгосрочная мотивация строится на удовольствии от процесса и ответственности за последствия своей работы. #Engineering #Software #Management #Leadership #Architecture

Understanding Architectural Complexity, Maintenance Burden, and Developer Sentiment - a Large-Scale Study (ICSE’25) (Рубрика #Architecture) Наконец-то у меня дошли руки написать про этот интересный whitepaper про связь качества архитектуры с нагрузкой на поддержку решения и восприятия инженерами самого проекта. Лид автором этой статьи была Yuanfang Cai, профессор в Drexel University и автор метрик применяемых метрик, а также команда Google Developer Infrastructure / Engineering Productivity Research (Ciera Jaspan и др.) Авторы взяли данные - 1200+ проектов внутри Google (C++/Java). - Логи разработки: commits, LOC (lines of code) и Active Coding Time; отдельно мерили их в разрезе "фичи" vs "багфиксы" - 7200 ответов инженеров из регулярного опроса: насколько техдолг/избыточная сложность мешали работе (подробнее про этот опрос было в статье ребят из Google "Measuring Developer Experience With a Longitudinal Survey", что я уже разбирал) Цель всего приседания была в том, чтобы заменить "ощущения техдолга" на измеримые связи: архитектура → бремя сопровождения → настроение разработчиков. Кстати, про техдолг ребята из Google уже публиковали крутую статью "Defining, measuring and managing technical debt", которую я уже разбирал Измеряли они следующие три категории 1️⃣ Архитектурная сложность - Propagation Cost (PC): насколько широко расползаются изменения по зависимостям - Decoupling Level (DL): насколько хорошо система декомпозирована на независимые модули - Архитектурные запахи: циклические зависимости, co-change без явных зависимостей, нестабильные интерфейсы, проблемы наследования и т.п. 2️⃣ Maintenance burden - Доля усилий на багфиксы: по commits, LOC (lines of code), ACT (active coding time) 3️⃣ Developer sentiment - Ответы на вопросы из опросы вида "тормозит ли меня техдолг" Методология выглядела так - Для каждого проекта считают PC/DL/запахи по dependency graph + считают "bugfix ratio" по истории изменений - Дальше делают статистический анализ (корреляции/значимость) между тремя слоями В итоге у них на выходе получились результаты, что - Более сложная архитектура (PC↑, smells↑) связана с тем, что команда тратит больше доли усилий на багфиксы и меньше - на развитие - Чем больше "feature work" у команды, тем реже инженеры говорят, что техдолг их тормозит - "Архитектура <-> недовольство" во многом проявляется через рост багфиксов: когда вы живёте в поддержке, техдолг становится осязаемым Отдельно стоит отметить, что исследование нашло корелляцию, но это не причинно-следственная связь. Но это частая картина для сложных методологий исследований, что через a/b тест не катанешь. В следующем посте я расскажу свои мысли, а что можно из этого забрать себе, чтобы контролировать качество архитектуры и не стать техническим банкротом. P.S. Я рассказывал про многие статьи ребят из Google, у них отлично выстроена методология и есть очень интересные результаты - подробнее можно посмотреть в подборке из двух постов: 1 и 2 #Engineering #Software #Bigtech #Productivity #Management #Leadership #Processes

It takes two (Рубрика #Games) Почти 20 лет я не играл в компьютерные игры, но на этот новый год мы купили детишкам PS 5 с кучей игрушек. Но Настя (моя жена) не обделила и нас и купила эту кооперативную игру. Мы в нее играли иногда по вечерам и за полтора месяца прошли. Игра оказалась очень интересной, веселой, местами психологической и наводящей на мысли о семейном быте. Вся история крутится вокруг родителей маленькой девочки, что решили развестись. Чаяниями их дочки мама и папа оказываются в своем доме в виде игрушек и им нужно пройти большой путь, чтобы стать опять людьми. В общем, игра была превосходная - мы даже купили игру Split Fiction, которую сделала та же студи и в которой история другая, но кооперативные механики те же. #ForParents

Inside Claude Code With Its Creator Boris Cherny (Рубрика #AI) Интересно интервью Бориса из Anthropic в подкасте Lightcone от Y Combinator. Обсуждение строилось вокруг Claude Code и того, как Борис создал этот один из самых успешных AI инструментов в виде простого терминального продукта, а также про то, а что будет дальше. ​ Если говорить про ключевые инсайты, то они такие 🚀 Строить под модель через 6 месяцев В Anthropic принцип: не оптимизировать продукт под текущую модель, а думать о том, какой она будет через ~полгода. Любой сложный «скэффолдинг» вокруг модели часто даёт +10–20% и полностью обнуляется следующим релизом, поэтому лучше минимальный слой обвязки и ждать апгрейда модели. 🎉 Рождение Claude Code как побочного эффекта Борис просто хотел научиться пользоваться API Anthropic и написал терминальный чат‑клиент, без UI. Добавил bash‑tool, попросил модель "узнать, какую музыку я слушаю", та сгенерировала AppleScript и залезла в плеер - для него это был первый "AGI‑момент»: модель "очень хочет использовать инструменты". 🖥 Почему терминал и почему он "прилип" Терминал выбран не из идеологии, а как самый дешёвый способ сделать прототип. Внутри Anthropic люди начали использовать его "до того, как он был готов", потому что: - Удобно автоматизировать git, bash, Kubernetes, рутинные DevOps‑таски - Продукт ощущается как "игра", а не как тяжёлый IDE‑плагин Из этого вырос принцип: следовать латентному спросу (latent demand) - смотреть, что люди уже пытаются делать, и облегчать ровно это, а не навязывать новый поток работы. Это прямо топовый продуктовый подход для создания внутренних инструментов разработки. ✍️ CLAUDE.md / CLAUDE.md как «операционный контекст» У Бориса личный CLAUDE.md - всего две строки: включать automerge на PR и постить PR в командный канал для быстрого ревью. Вся остальная "политика" живёт в repo‑локальном CLAUDE.md, который вся команда правит по несколько раз в неделю. Он советует: если файл раздулся до тысяч токенов, просто удалить и собрать заново - с каждой моделью нужно всё меньше инструкций. 🔈 Вербозность и UX терминала Команда постоянно тюнингует детализацию: пытались скрывать bash‑вывод, сотрудники взбунтовались - он нужен для дебага (Kubernetes, сложные команды). Скрыли подробные логи чтения файлов/поиска, но по жалобам GitHub‑юзеров добавили режим verbose в конфиге. 💪 Как он сам работает с Claude Code - 80% сессий начинает в plan mode: сначала план, потом выполнение. - Распараллеливает работу: несколько вкладок в терминале и десктоп‑приложении, каждая начинает с плана. - При сложных задачах явно просит несколько подагентов (3, 5, 10) исследовать проблему в параллели и потом объединить вывод. 🔮 Будущее plan‑mode и агентов - Plan mode - просто одна дополнительная фраза в промпте "пожалуйста, пока не пиши код". - Он считает, что срок жизни явного plan mode ограничен: при росте способностей модели она сама будет входить в "режим планирования", а потом и вовсе можно будет "одним шотом" давать задачу. - Уже сейчас Claude Code иногда сам включает план‑режим, когда это было бы естественно для человека. ⛓️ Автоматизация всей инженерной цепочки - Внутри Anthropic Claude‑агенты (через Claude Agents SDK) автоматизируют: code review, security review, triage и лейблинг задач, путь фичи до продакшена. - Фича plugins для Claude Code полностью была написана «роем» агентов за выходные: один агент получил спеку, создал задачи в Asana, породил подагентов, те подняли PR‑ы. 🤖 Профиль идеального инженера / фаундера в эпоху LLM - Главное - научный подход, мышление от first‑principles и готовность признавать ошибки; многие опытные инженеры застряли в старых паттернах. - Борис ценит либо гипер‑специалистов (как команда bun / люди, одержимые devtools, рантаймами), либо гипер‑генералистов, которые пересекают продукт, инженерку, ресёрч, бизнес. - Отбор кандидатов - в том числе по поведению с агентами: можно ли по транскрипту сессии понять, что человек умеет мыслить системно, использовать план, логи, корректировать модель. #AI #Engineering #Software #Management #Leadership #Startup #LLM #ML #Architecture

Дискуссия с Гришей Скобелевым про подготовку к System Design Interview (Рубрика #Architecture) Завтра, 21 февраля, в 11 часов утра по Москве мы с Гришей из клуба { между скобок } решили собраться и поговорить про подготовку к System Design Interview и про то, как я дошел до жизни такой, что собрал сайт system-design.space Мы точно обсудим вопросы, что есть в программе встречи • Почему книга не лучший формат для System Design • Как меняются ожидания на интервью • Какие ошибки чаще всего допускают кандидаты • Что на самом деле проверяют на System Design интервью • Как отличить «рисование кубиков» от настоящего архитектурного мышления • Какие темы обязательно нужно понимать senior / staff инженеру Но также думаю, что затронем вопросы системного мышления и фундаментальной подготовки, а не просто запоминания задач. Встречаемся завтра c кофе ☕️ в 11:00 на YouTube #SystemDesign #Architecture #DistributedSystems #Career #Interview #Engineering

История Linux и UNIX! Кто породил ВСЕ современные системы! (Рубрика #Engineering) Интересное видео про историю операционных систем от канала PRO Hi‑Tech, из которого хорошо видно, что в истории unix или gnu linux победила не "одна фича", а сочетание идей + институтов (люди, лицензии, стандарты, сообщества). Из таймлана развития событий видно, что многие технологии приняли участие в ходе этой истории - 1969: Unix в Bell Labs - простые абстракции под жёсткие ограничения (знаменитые пайпы и простые инструменты, что ждут на вход текст и ) - 1973: переписывание на C → переносимость как стратегия (переносимость между разным железом) - 1984: BSD + TCP/IP → Unix становится “родным” для сетей - 1988: POSIX → общий контракт совместимости среди зоопарка Unix - 1991: Linux (ядро) → недостающий пазл для свободной системы (ядро экосистемы GNU) - 1993+: Debian/*BSD → управление качеством, релизами, пакетами - 2000–2008: Darwin/macOS и Android → Unix‑подход уходит в массовые платформы (на Android и в основу Mac) Из всей этой истории можно сделать определенные выводы, что полезны и в продуктовой разработке - Переносимость = драйвер экосистемы. Инвестируйте в стабильные API/ABI и “тонкий слой” платформенной специфики - "Файл/процесс/pipe" → сила простых контрактов. Малые утилиты и композиция = предок современных микросервисов и пайплайнов - Фрагментация лечится стандартами. POSIX появился не из любви к бюрократии, а чтобы снизить стоимость переносимости - Open‑source ≠ анархия. Сообщества выживают за счёт governance, CI, правил релизов и ответственности за интеграцию - Лицензия - архитектурное решение. Она определяет, кто и как может вкладываться, монетизировать и форкать - "Ядро" ≠ "продукт". Дистрибуция/SDK/пакеты/политики поставки часто важнее самого kernel Для технических лидеров это можно приземлить на набор полезных по моему мнению советов - Зафиксируйте "поверхность контрактов": публичные API/CLI/форматы, SLA, обратная совместимость - Постройте конвейер принятия вкладов: code review → CI → релизные ветки → rollback - Разделяйте владельцев: ядро/платформа vs userland vs дистрибуция/поставка - Не верьте красивым нарративам на слово: проверяйте даты/причины решений - история любит упрощения (посмотрите оригинальный фильм и почитайте доки - составьте свое мнение) Более подробный разбор есть на моем сайте system-design.space. #Engineering #Documentary #Architecture #Software #DistributedSystems #Leadership

The Man Who Revolutionized Computer Science With Math (Рубрика #DistributedSystems) В этом видео Лэсли Лэмпорт за 8 минут рассказывает про специальную теорию относительности, причинность и распределённые системы, а также как это все свзяано между собой. Это видео - короткое интервью Quanta Magazine где он объясняет смысл своей классической фразы

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

Но лучше сначала расскзать, а чем известен Лэсли Лампорт, который получил премию Алана Тьюринга (аналог Нобелевской, но в информатике). За ним числятся - Lamport clocks + happens‑before: как упорядочивать события без «общих часов» - Paxos и replicated state machine: фундамент отказоустойчивых кластеров/хранилищ - LaTeX: де‑факто стандарт научной вёрстки - TLA+: спецификации + model checking, чтобы ловить дизайн‑баги до кода Самое вкусное в этом интервью - это рассказ про связь специальной теории относительности из физики и теории распределенных систем из информатики. Мне как учившемуся на Физтехе очень понравилась эта часть про мультидисциплинарность и пользу физики (хотя я учился на факультете прикладной математики, но физика у нас выдавалась всем так, чтобы никто не ушел обиженным от того, что ее недополучил). Так вот, в СТО (специальной теории относительности) нет универсального "сейчас": наблюдатели могут спорить, что было раньше. Но они не спорят о причинности - событие A может повлиять на B только если сигнал (не быстрее света) мог дойти от A до B. И Лэсли Лэмпорт перенес это 1‑в‑1 в распределённые системы: - Нет глобального времени (латентности, дрейф, партиции) - Зато есть причинный частичный порядок: "могла ли информация из A повлиять на B" В итоге, в распределёнке важнее порядок, совместимый с причинностью, чем "точные таймстемпы". Отсюда появились логические часы, тотальный порядок поверх частичного и согласованная эмуляция одной последовательной state machine несколькими узлами. В общем, я раньше не знал как Лэсли к этому всему пришел, а тут узнал и понял, что действительно это блестящая игра разума. Но если возвращаться на грешную землю, то можно почерпнуть такие инсайты для инженеров и технических руководителей - Programming ≠ coding. Код - последняя миля. До него должны появиться модель поведения и явные допущения (сеть, сбои, порядок сообщений, часы). - "Алгоритм без доказательства - гипотеза". Даже если вы не пишете формальные доказательства, TLA+/модель‑чекер часто ловят те баги, которые тестами почти не поймать. - Ищите причинность. Когда спорите о порядке операций в БД/кэше/очереди - спрашивайте не "который час был раньше", а "какая информация могла попасть куда". Ну и отдельный момент про любимый алгоритм Лэслю "Bakery (mutual exclusion)". Здесь метафора пекарни работает так: каждый процесс берёт «номерок», и в критическую секцию входит минимальный (при равенстве - по id). В оригинальной работе он даже отмечает, что такие "номерки" можно реализовать распределённо: хранить у владельца процесса и читать по сети. Красота в том, что алгоритм корректен даже при очень слабых предположениях о памяти: чтение, пересекающееся с записью, может вернуть произвольный "мусор", а докатазательство всё равно работает. Лэмпорт понял это, когда дописывал доказательство - это отличный аргумент, зачем вообще писать спецификации/доказательства: они находят свойства, которых вы "не закладывали". #DistributedSystems #Software #Engineering #Architecture #Leadership #SystemDesign