[2/2] Communication Patterns: A Guide for Developers and Architects (Паттерны коммуникации: руководство для ИТ-разработчиков и архитекторов) (Рубрика #Management)

Продолжая рассказ о паттернах коммуникации, расскажу про вторую половину книги, в которой речь идет про передачу знаний и эффективную удаленную работу.

3️⃣ Передача знаний (Communicating Knowledge) - как управлять знаниями в команде и организации.
- Глава 10. Принципы управления знаниями (Knowledge Management Principles). Разница между данными, информацией и знаниями. Почему wiki-системы превращаются в свалку и как этого избежать.
- Глава 11. Знания и люди (Knowledge and People). Как люди усваивают информацию и почему "шаринг знаний" часто не работает. Психология обучения взрослых применительно к инженерным командам.
- Глава 12. Эффективные практики (Effective Practices). Конкретные инструменты: от ведения ADR (Architectural Decision Records) до проведения воркшопов и сессий совместного моделирования.

4️⃣ Удаленная работа (Remote Communication) - специфика общения в распределенных командах.
- Глава 13. Фактор времени при удаленной работе (Remote Time). Паттерны для асинхронной коммуникации и работы в разных часовых поясах. Как сохранить контекст и темп работы, когда команда разбросана по миру.
- Глава 14. Принципы дистанционного общения (Remote Principles). Здесь речь про создание четких коммуникационных каналов, протоколов, а также про адаптацию стиля общения в зависимости от нужд команды. На эту тему есть хорошая книга "Remote Team Interactions Workbook" (о которой я уже рассказывал) от авторов книги "Team Topologoies".
- Глава 15. Методы дистанционного общения (Remote Channels). Здесь автор рассказывает про установление культуры открытой и честной обратной связи, а также использование технологий для улучшения коммуникации и поддержания связи между членами команды. Кстати, про открытую и честную обратную связь можно почитать в книге "Radical Candor: Be a Kick-Ass Boss Without Losing Your Humanity", о которой я уже рассказывал.

#Thinking #Writing #Leadership #Management #DistributedSystems #Architecture #SoftwareArchitecture #SystemDesign #Software #Writing #Speaking

AI-инженерия. Построение приложений с использованием базовых моделей (AI Engineering) (Рубрика #AI)

Книгу "AI Engineering" уже перевели и скоро выпустят в издательстве Питер. А я эту книгу прочитал на английском еще в начале года и она мне супер зашла (мы ее вместе с Женей Сергеевым из Flo почти целиком разобрали за три серии подкаста: 1, 2 и 3). Собственно, книга отлична подходит инженерам, что строят GenAI‑продукт прямо сейчас, например, чат‑бот, copilot, RAG, ...

Книгу написала Chip Huyen, которая
- Преподавала Machine Learning Systems Design в Stanford (CS329S), а значит умеет объяснять системно и доступно
- Написала книгу "Designing Machine Learning Systems" (O’Reilly), которую многие считают must‑read для инженеров из ML/Platform команд
- Работала на стыке AI + инфраструктуры (NVIDIA, Snorkel AI), сейчас - Voltron Data (GPU‑ускорение аналитики)

Есть несколько факторов почему "AI Engineering" стала бестселлером
1. Попала в боль 2024–2025: команды массово интегрируют базовые модели, и нужен инженерный фреймворк, а не очередной набор промптов
2. Большой фокус был на evaluation: не “vibe check”, а измеримые метрики, регрессионные наборы, LLM‑as‑a‑judge, тестирование на деградации
3. Закрывает прод‑реальность: стоимость и латентность инференса, мониторинг, качество данных/фидбек‑лупы, безопасность и риск‑менеджмент
4. Даёт карту паттернов (prompting, RAG, fine‑tuning, tools/function calling, agents) и отвечает на главный вопрос: когда что выбирать
5. У книги есть публичные материалы/ресурсы (репо на 12.5к звездочек), поэтому вокруг неё быстро выросла “экосистема” практик

Вот чем может быть полезна эта книга инженерам, которые уже пилят GenAI
- Превращает "демку на фреймворке" в проект: требования → архитектура → eval harness → релиз → наблюдаемость
- Помогает говорить на одном языке с Product/Platform: какие SLO/SLI у LLM‑фичи, что логируем, где делаем гейтинг качества, как считаем cost‑per‑request
- Хороша для техлидов: много про компромиссы (качество vs цена, контекст vs retrieval, детерминизм vs креативность) и про то, где чаще всего “ломается” система

Мини‑чеклист из книги, который можно использовать хоть завтра:
- Golden кейсы + негативные кейсы (и регулярные регрессионные eval’ы)
- Версионирование промптов/моделей/ретривера + логирование контекста
- Метрика "стоимость ответа" + бюджет на фичу
- Eval гейты в CI перед деплоем (как unit/integration, только для LLM)

В общем, книга определенно заслуживает прочтения. Кстати: пока книга еще в предзаказе на нее действует скидка в 35% при использовании промокода "Предзаказ"

#Architecture #Software #AI #Engineering #ML #Data #SystemDesign #DistributedSystems

Топ-3 книги издательства Питер, что я могу порекомендовать в этом году (Рубрика #Software)

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

1️⃣ AI-инженерия. Построение приложений с использованием базовых моделей
Последние годы проходят во многом под знаком AI. Уровень хайпа просто бомбический, но это не значит, что за хайпом ничего не стоит, а сами технологии ничего не дают. Напротив, результаты есть и они масштабные, но только у тех, кто умеет пользоваться инструментом правильно. А эта книга как раз про то, как строить приложения с использованием фундаментальных моделей. Я уже рассказывал про эту книгу раньше и считаю, что она будет полезна инженерам

2️⃣ Паттерны проектирования API
Про эту книгу я тоже рассказывал раньше, но в рамках хайпа про AI она мне кажется становится важнее. Суть в том, что 2025 год прошел под знаком AI агентов и эта движуха дальше будет только разгоняться - осенью 2024 года был представлен протокол MCP (model context protocol), который описал формат API вызова инструментов моделями, весной 2025 года Google представил A2A протокол (agent to agent), но все эти штуки живут поверх хороших подходов к управлению API. А эта книга как раз про это, причем автор, Джей Джей Гивакс, работал в Google и был соавтором статьи "API Governance at Scale" про подходы в Google (см. мой разбор). Он же был сооснователем ресурса aip.dev и одним из главных идеологов процесса AIP (API Improvement Proposals), про который я рассказывал раньше. Интересно, что с момента издательства книги Джей Джей уже успел перейти в Meta (видимо там тоже нужно поработать над API Governance).

3️⃣ Распределенные данные. Алгоритмы работы современных систем хранения информации
Про эту книгу "Database Internals" я уже рассказывал и мы даже ее разбирали в подкасте "Code of Architecture". Если подвязывать эту книгу к теме AI, то можно много сказать про хранение данных, про важность их для контекста ... Но я не буду этого делать - я выбрал эту книгу, потому что она хорошо рассказывает про движки для хранения данных, а также про архитектуру распределенных систем. Автор книги, Алекс Петров, контрибьютил в Cassandra, поэтому у него релевантный опыт для рассказа об этих темах.

В общем, книги достойные - я получил большое удовольствие, когда их изучал:)

#Databases #Software #Engineering #Architecture #AI #ML #DistributedSystems #Architecture #API

[1/2] Databases in 2025: A Year in Review by Andy Pavlo (Рубрика #Databases)

Изучил ежегодный обзор рынка баз данных от Andy Pavlo, крутого преподавателя и исследователя мира БД из Carnegie Melon University. Ниже краткое саммари основных моментов

🐘 PostgreSQL правит бал
Доминирование PostgreSQL продолжается и именно вокруг Postgres сосредоточена большая часть энергии и инноваций в СУБД.
В 2025 это подтвердилось громкими сделками:
- Databricks купил облачный PostgreSQL-сервис Neon (~$1 млрд)
- Snowflake – Crunchy Data ($250 млн)
- Microsoft запустил свой PostgreSQL-DBaaS (HorizonDB)

Появились проекты масштабирования Postgres по горизонтали (шардинг):
- Supabase нанял соавтора Vitess для проекта Multigres
- PlanetScale анонсировал систему Neki – Postgres-на-стероидах для больших нагрузок
Pavlo приветствует эту волну "шардированного Postgres", хотя напоминает, что попытки сделать масштабируемый Postgres предпринимались и раньше.

🤖 MCP для LLM в каждый дом
Если 2023-й был годом "векторных индексов" в каждом движке, то 2025-й – годом поддержки Anthropic MCP (Model Context Protocol) во всех СУБД. После поддержки OpenAI этого протокола практически каждый вендор выпустил MCP-сервер к своей базе – от OLAP-систем (ClickHouse, Snowflake и др.) до NoSQL (MongoDB, Neo4j, Redis); а провайдеры PostgreSQL‑DBaaS написали свои реализации. По мнению Andy Pavlo появление такого стандарта взаимодействия ИИ с БД - это благо, но стоит нужно ограничивать и мониторить эти реализации (например, только read-only запросы, лимиты на результат и таймауты), иначе рано или поздно случится факап

⚖️ MongoDB против FerretDB – судный день?
Впервые за историю индустрии СУБД одна компания подала в суд на другую за имитацию её API. MongoDB, Inc. обвинила стартап FerretDB (прокси, переводящий запросы MongoDB в PostgreSQL) в нарушении авторских прав, патентов и лицензии. Andy Pavlo сравнивает этот иск с процессом Oracle vs Google за Java API – тогда суд встал на сторону свободной реализации. Исход дела неясен, но есть пикантный нюанс: FerretDB изначально назывался "MangoDB". Интересно, что параллельно Microsoft в 2025 открыла исходники собственной Mongo-совместимой базы DocumentDB (передав проект в Linux Foundation) – то есть фактически занялась тем же, в чём Mongo обвиняет FerretDB.

📁 Война форматов данных
Почти 15 лет формат Parquet царил в колонночных хранилищах, но в 2025 сразу пять новых open-source форматов бросили ему вызов (ещё несколько появились в 2024-м). Среди них – проекты от академиков (FastLanes, F3, AnyBlox), стартапов (Vortex от SpiralDB) и гигантов (Microsoft Amudai, правда, его тихо прикрыли к концу года). Сообщество Parquet встрепенулось и взялось за модернизацию стандарта. Andy Pavlo отмечает, что главная проблема Parquet – не в самом формате, а в фрагментации реализации: слишком много парсеров/писателей в разных языках, поддерживающих разный поднабор фич. В результате 94% файлов «в живой природе» до сих пор созданы с фичами v1 образца 2013 года. Никто не будет переписывать петабайты старых паркет-файлов, да и невозможно быть уверенным, что любая система прочитает новейший файл – вдруг ей не хватит поддержки специфичных опций. Новые форматы пытаются решить проблему совместимости по-разному. Например, формат F3 (разрабатываемый в том числе при участии Pavlo) встраивает в каждый файл собственные декодеры: и в виде нативных модулей, и в виде WASM-кода, лежащего прямо в файле. Идея в том, что база данных сможет прочесть колонку даже нового, незнакомого формата – исполнив прикреплённый WASM-декодер. Другие (AnyBlox) генерируют единый WASM для всего файла. Пока неясно, чей подход победит – Parquet повсеместен, и инерция огромна. Следующее сражение развернётся за поддержку GPU в форматах, прогнозирует Pavlo, но одно ясно уже сейчас: битва за эффективное хранение данных вошла в новую фазу.

В продолжении я расскажу про остальные пункты.

#Database #Architecture #Management #DistributedSystems #Software #Engineering #Future

[2/2] Databases in 2025: A Year in Review by Andy Pavlo (Рубрика #Databases)

Продолжая рассказ об обзоре рынка баз данных от Andy Pavlo, расскажу про оставшиеся тезисы.

💸 Деньги, слияния и поглощения
2025-й оказался богат на крупные сделки в мире данных
- Продолжилась охота на PostgreSQL-компании: Neon ушёл к Databricks, Crunchy Data – к Snowflake (за $250 млн)
- IBM не остался в стороне и забрал себе DataStax (Cassandra) примерно за $3 млрд
- Salesforce раскошелился на старейшую ETL-платформу Informatica (~$8 млрд)
- Даже MariaDB Corp. умудрилась в том же году дважды купить «саму себя» – вернув под своё крыло отколовшуюся облачную дочку SkySQL
- Неожиданностью года стало слияние Fivetran и dbt Labs – две взаимодополняющие компании объединились в ETL-колосс, метящий на скорый IPO

📉 Инвесторы охладели к новым СУБД
Хайп вокруг векторных баз спал, венчуры в 2025 меньше инвестировали в молодые DB-стартапы, предпочитая нести деньги в AI. Зато лидеры отрасли продолжают получать огромные раунды:
- Databricks привлёк $5 млрд (два раунда) за год
- ClickHouse – $350 млн
- Supabase – суммарно $300 млн (Series D + E)
- И даже совсем молодые проекты вроде SpiralDB (создатели Vortex) поднимают десятки миллионов.

💀 Не все выжили
Ряд компаний не пережил этот год
- Закрылся FaunaDB – амбициозный распределённый СУБД‑стартап с сильной консистентностью (Pavlo был у них техконсультантом и советовал добавить SQL, но его не послушали)
- Проект PostgresML (машинное обучение внутри PostgreSQL) тоже не взлетел
- Команда Hydra (коннектор DuckDB↔️Postgres) разбрелась кто куда
- Даже классика: Apache Derby (Java-СУБД с 1997 года) объявлен "read only" – разработка остановлена за отсутствием мейнтейнеров.
GPU-базы данных тоже постигла нелёгкая судьба
- Стартап-супергруппа Voltron Data с инвестициями $110M так и не успела выпустить свой GPU-ускоренный движок Theseus
- HeavyDB (ранее OmniSci/MapD, пионер GPU-СУБД) тихо прекратил самостоятельное существование – команду поглотила Nvidia
Andy Pavlo резюмирует: нишевые решения вроде Kinetica и Sqream по-прежнему где-то на периферии, а заметно потеснить классические CPU-ориентированные СУБД GPU-решения пока не смогли. Производительность современных колонночных систем на CPU уже настолько высока, что решающее значение имеют не сырые оптимизации, а удобство для разработчиков и «умность» оптимизатора запросов. Впрочем, Pavlo намекает, что в 2026-м мы услышим о новых попытках задействовать GPU на полную мощность – гонка продолжается.

🏆 Ларри Эллисон – вершина успеха
Для основателя Oracle этот год стал поистине триумфальным. В 81 год Ларри Эллисон возглавил список богатейших людей планеты, впервые «коронованный» как самый богатый человек в мире (состояние оценивалось около $393 млрд). Oracle взлетел в цене благодаря облачным сделкам в сфере ИИ, и в сентябре 2025 акции Oracle выросли на 40% за день, сделав Эллисона не только №1 в мире, но и самым богатым человеком в истории (с поправкой на инфляцию обошёл даже Рокфеллера). Правда, спустя пару месяцев стоимость Oracle откатилась и Ларри потерял порядка $130 млрд – в масштабе миллиардера это как для нас с вами лишиться одной зарплаты, шутит Pavlo. В течение года Oracle/Эллисон засветились в крупных событиях: Oracle выступил ключевым партнёром в сделке по «американизации» TikTok и финансировал попытку поглощения Warner Bros (через принадлежащий семье Эллисона холдинг Paramount). Andy Pavlo признаётся, что был даже рад услышать новость о том, что “благодаря базам данных кто-то стал самым богатым на земле” – наконец в нашей сфере случилось нечто позитивное. Он иронизирует над критиками Эллисона: мол, Ларри уже завоевал мир корпоративных баз данных, выиграл регаты и построил сеть люкс-спа для техно-богачей, так почему бы ему не купить новостной телеканал? Эллисон не обращает внимания на разговоры, делает что хочет – фанаты и новая жена его поддерживают, а остальное неважно.

#Database #Architecture #Management #DistributedSystems #Software #Engineering #Future

Сайт по system design (Рубрика #Architecture)

Многие мои подписчики знают, что я планировал написать книгу ... но я не уточнял какую. Суть была в том, что я параллельно занимался работой над несколькими книгами. Ближе всего к готовности была книга по System Design (с фокусом на подготовке к интервью) - мне просто было проще всего ее собрать из своих материалов. Я работал по стартинке - сделал желаемое оглавление, собрал часть глав из своих материалов и получил большой Google Doc. Но на каникулах меня осенило, что цель-то не в книге, а в удобной компиляции моих мыслей. Поэтому я поменял подход - скормил google doc сервису Lovable для создания интерактивного сайта, а дальше инкрементально начал его дорабатывать. Я этим занимался больше месяца и получился такой вот сайт system-design.space. Конечно, нет предела совершенству и я собираюсь продолжить его наполнение, но думаю, что он уже может принести пользу тем, кто хочет прокачаться в проектировании.

Если найдете какие-то ошибки или опечатки, то пишите - я буду править их по мере своих сил. В ближайшие месяцы я планирую добавить еще рекомендованных книг, поработать над пулом задачек, чтобы тут были не только классические из других книг + сделаю побольше красивых визуализаций. На более далеком горизонте я планирую пойти в стороне не только классическо system design, но и других типов, что описаны в главе про специфику интервью.

#SystemDesign #Interview #Career #Architecture #DistributedSystems #Databases #Engineering #Software

[1/2] Google открыл A2UI - протокол, который позволяет агентам “говорить UI”, а не только текстом (Рубрика #AI)

15 декабря 2025 команда A2UI в Google публично выложила проект A2UI (Agent-to-User Interface) - открытый формат + библиотеки рендеринга, чтобы “удалённые” AI‑агенты могли возвращать сложные интерфейсы (формы, карточки, списки, кнопки) как данные, а не как исполняемый код. Этот протокол призван решить проблему текстовых чатов, когда простые пользовательские действия (забронировать столик, заполнить поля, выбрать время) превращаются в долгую переписку “вопрос‑ответ‑уточнение”. A2UI предлагает вместо этого дать агенту возможность сгенерировать контекстную форму/карточку из каталога компонентов и отрисовать её в вашем приложении. Сам протокол доступен на GitHub.

По сути это работает примерно следующим образом - агент генерирует декларативное описание UI в JSON, клиент рендерит это нативными компонентами своего приложения.
Ключевые принципы (сформулированы в README проекта):
- Security‑first: агент не присылает JS/HTML/код. Он присылает данные, которые проходят валидацию, а UI строится из каталога заранее разрешённых компонентов (Button/Card/TextField/и т.д.). Это снижает риск UI‑инъекций и “случайного RCE через UI”
- LLM‑friendly + инкрементальные апдейты: UI описывается “плоской” структурой (adjacency list) с ID‑ссылками, поэтому агент может стримить интерфейс и патчить отдельные компоненты по ID, не пересылая всё дерево
- Framework‑agnostic: один и тот же A2UI‑пейлоад может быть отрендерен в разных клиентах (web/mobile/desktop) — потому что “как рисовать” решает клиент
- Transport‑agnostic: A2UI - это формат/контракт сообщений, его можно гонять поверх разных “транспортов” (включая A2A и AG‑UI)

На практике (в версии v0.8, stable/public preview) сообщения обычно идут как JSON Lines (JSONL): одна строка = одно сообщение. Есть 4 ключевых типа:
- beginRendering
- surfaceUpdate
- dataModelUpdate
- deleteSurface
Сам стрим может выглядеть примерно так

{"surfaceUpdate": {"surfaceId":"main","components":[ ... ]}}
{"dataModelUpdate": {"surfaceId":"main","contents":[ ... ]}}
{"beginRendering": {"surfaceId":"main","root":"root-component"}}

Но надо отметить, что спека все еще дорабатывается и между v0.8 (stable) и v0.9 (draft) уже есть изменения в деталях и даже названиях envelope‑сообщений

Теперь давайте обсудим, а почему этот протокол нам интересен и чем он лучше альтернатив.
1. Одной из альтернатив является генерация HTML/JS/React‑кода агентом.
Здесь у нас есть проблема с безопасностью и контролем - вам либо нужно исполнять непроверенный код, либо городить тяжёлую песочницу. В A2UI у нас вместо кода данные, а рендеринг идет только из доверенного каталога компонентов.
2. Другой алтернативой являются iframe‑подходы / “UI как ресурс” (например, MCP Apps)
В статье Google прямо сравнивает A2UI с MCP Apps: там UI часто приходит как “opaque payload” (например HTML) и рендерится в sandboxed iframe. Но A2UI выгодно отличается “native‑first” подходом: агент отправляет blueprint нативных компонентов, и UI наследует стиль/дизайн‑систему/доступность хост‑приложения, вместо отдельного “мини‑веба в iframe”.
3. Платформенные end2end экосистемы (например, OpenAI ChatKit)
Плюс таких решений - интеграция в рамках одной платформы. Минус - переносимость и работа в мульти‑агентных сценариях с разными вендорами. A2UI целится в переносимый UI‑контракт для ваших собственных клиентов и enterprise‑mesh сценариев.
4. Просто возьмём AG‑UI и хватит
AG‑UI решает вопросы интеграция агента и UI), а A2UI - описывает сам формат UI‑ответа. Google явно позиционирует A2UI как комплементарный слой: подключили хост через AG‑UI → можете использовать A2UI как формат для UI‑ответов, в том числе от внешних агентов

Продолжение о том, а почему этот проект так интересен в посте-продолжении.

#Engineering #AI #Agents #Software #Architecture #RnD #ML #DistributedSystems

[2/2] Google открыл A2UI - протокол, который позволяет агентам “говорить UI”, а не только текстом (Рубрика #AI)

В продолжении обсуждения протокола A2UI от Google мы рассмотрим, а почему он может быть интересен создателям genAI приложений для пользователей.

Если смотреть на публичные сигналы, проект реально подхватили:
1. GitHub traction. За полтора месяца проект набрал 10.9k звезд, 810 forks, 66 issues, 80 PR, 332 commits, 31 contributor в основном репозитории
2. Официальные туториалы Google. В документации для Google Workspace появился quickstart “Build a Google Chat app with an Agent2UI agent” (обновлён 2026‑01‑27), с развёртыванием агента через ADK и хостингом в Vertex AI Agent Engine. Это хороший индикатор, что A2UI продвигают как практический способ строить UI‑ответы агентов внутри Workspace/Chat‑сценариев.
3. Экосистема вокруг. Появляются сторонние реализации/порты:
- a2ui-rails - порт в Ruby/Rails
- A2UI-for-Google-Apps-Script - демо/адаптация под Apps Script/Workspace
- Отдельные упоминания и интеграционные запросы в других agent‑framework репозиториях тоже всплывают (feature requests/discussions)

И отдельно: сам проект помечен как Early stage public preview (v0.8), при этом параллельно ведётся v0.9 (draft) - то есть активная фаза “формат шлифуется”.

Отдельно надо подсветить почему это должно быть инженерам
- Нормальный контракт между “мозгом” и UI: агент не “рисует DOM”, а отправляет декларативные апдейты, которые ваш клиент валидирует и рендерит. Это лучше ложится на архитектуру “удалённый агент / недоверенная граница”
- Инкрементальность и патчи: можно стримить UI и менять только нужные куски по ID, вместо “перерисовать всё”
- Переиспользование дизайн‑системы: UI остаётся нативным (ваши компоненты/темизация/а11y), а агент лишь “просит” собрать композицию
- Прагматичная интеграция: есть референсные рендереры (Lit/Angular/Flutter), есть понятный quickstart с демо‑агентом

Для техлидов и engineering менеджеров это может быть интересно по другим причинам
- Скорость поставки фич: вместо того чтобы каждый раз вручную проектировать “формочку под новый workflow”, часть UX можно делегировать агенту, но в рамках жёсткого каталога компонентов и правил
- Управляемый риск: “данные вместо кода” = проще проходить security review, проще ограничивать поверхность атаки, проще объяснять границы доверия между командами/вендорами
- Стандартизация для мульти‑агентных сценариев: когда разные агенты/под‑агенты (внутренние и внешние) должны отдавать UI в единый клиент, формат уровня A2UI снижает интеграционный ад
- Сигналы зрелости: быстрорастущий репозиторий + официальный quickstart в Google Workspace доках + параллельная работа над спецификацией (v0.8 stable / v0.9 draft) — это похоже на проект, который реально хотят “довести до v1”

Если вы сейчас строите agentic‑продукт и упираетесь в “чат вместо продукта”, A2UI выглядит как очень практичный способ превратить ответы агента в управляемые, нативные, безопасные UI‑сессии - и при этом не завязаться на один конкретный фронтенд‑стек.

#Engineering #AI #Agents #Software #Architecture #RnD #ML #DistributedSystems

Update по System Design Space (Рубрика #Engineering)

Я запустил этот сайт чуть больше недели назад и продолжил его активно дорабатывать и решил поделиться lessons learned.
- Дорабатывать сайт ипользуя только Lovable дорого - кредиты улетают как не в себя - я прошел такой путь за месячную подписку всего за полтора месяца 0$ -> 25$ -> 50$ -> 100$ -> 200$
- Как второй и основной помощник я сейчас использую OpenAI Codex, где подписки в 200$ хватает как на веб, deep research, так и на написание кода (сразу для целой пачки ресурсов)
- Я добавил очень много новых глав + отдельный раздел, что посвящен документальным фильмам про технологии
- Для сложных тем я сделал визуализации архитектуры и процесса работы - смотрите примеры из части с кейсами
- Я добавил светлую тему, оглавление, поменял верстку под мобилу и еще кучу всего
- Сайт успел за неделю полежать пару раз. Один раз мы с Codex оптимизировали сборку и lazy загрузку React, что локально все работало, а на внешнем хостинге нет - пришлось откатить эту оптимизацию. Второй раз была проблема с DNS - я забыл подтвердить email регистратору доменных имен и дальше делегирование сайта было преостановлено (дальше прожал кнопочку подтверждения из email и буквально всего через 2 часа все вернулось, а могло и через 2 дня)
- Как-то я попросил отрефакторить проект и агент ушел локально колбасить что-то на всю ночь - утром пришел проверил, сделал несколько фиксов и все полетело
- Тесты у меня есть, но из-за того, что я часто меняю внешний вид сайта, то я часто их просто заново гененрирую, а не прогоняю для проверки (главы - это отдельные ts файлы, поэтому изменения обычно хорошо локализованы и дают мало внешних эффектов)
- Я занимаюсь этим по выходным, а также по вечерам после работы и это затягивает - иногда в 2 часа ночи ловлю себя на мысли, что надо выдать задачку помасштабнее и наконец-то пойти спать:)

А если в целом, то мне давно не было так интересно заниматься разработкой софта в качестве хобби после работы - раньше мешало отсутствие времени, а теперь с новыми инструментами мешает только отсутствие идей ... А если идеи у вас есть, то возьмите и попробуйте новые инструменты и может быть вам это понравится.

#SystemDesign #Interview #Career #Architecture #DistributedSystems #Databases #Engineering #Software

Local-First Software: Taking Back Control of Our Data | a mini-doc (Рубрика #DistributedSystems)

Посмотрел интересный мини-документальный фильм, в котором засветились разные люди, но меня заинтересовал Мартин Клеппман, автор книги DDIA и один из апологетов подхода local-first. Собственно, этот подход предлагает альтернативу централизации хранения информации в облаке (и фиксации там источника истины). В local-first приложениях "истина" хранится на устройстве пользователя, работает без интернета и синхронизируется с облаком как с дополнительной копией.

Основные идеи концепции такие
1️⃣ Главная копия - у пользователя. Приложение читает/пишет локально → быстрый UX, офлайн по умолчанию. Облако нужно для синка между устройствами и бэкапа.
2️⃣ Cloud‑first ломается в быту. Например, пропал сигнал - пропал плейлист, хотя музыку «купили». И ещё хуже: сервис закрылся/выключил серверы - люди теряют доступ к своим данным.
3️⃣ Коллаборация возможна, но это сложно. Цель - как в лучших облачных продуктах (реал‑тайм, единые данные), но без постоянной связи с центральным сервером. Техники: CRDT, p2p/распределённая синхронизация, «слияние» изменений. Пока есть трудные кейсы и много инженерной работы.
4️⃣ Это уже движение. Сообщество растёт, появляются митапы/инструменты. Большинство «local‑first» продуктов пока гибридные (компромисс идеала и практики), но направление ясно: больше автономности и контроля пользователя.

Если прекладывать это на идеи для проектирования своих приложений и хочется попробовать двигаться в эту сторону, то можно сделать следующее
- Сделайте offline‑first базовым нефункциональным требованиям. Не «спиннер без сети», а работа с локальными данными + очередь/ретраи/идемпотентность (кстати, сейчас такой подход был бы актуален на случай блокирования мобильного интернета)
- Локальная БД + фоновый sync. SQLite/IndexedDB и слой репликации: журналы изменений, версии, мердж, лимиты/квоты, наблюдаемость синка.
- Конфликты - не баг, а сценарий. Опишите модель консистентности: last‑write‑wins, CRDT, явные конфликты в UI, правила домена.
- Контроль и долговечность данных. Экспорт, локальные бэкапы, миграции схем, E2E‑шифрование для синка/облака.
- Сдвиг сложности на клиент. Сервер может стать проще (координация/хранилище), но растут требования к тестированию офлайн/синка и к компетенциям в распределённых системах.

В общем. если подводить итог, то local-first пытается решить боли уехавших в облака приложений и ставших cloud-only, а список проблем большой: зависимость от сети, доверие и сохранность данных. Но надо отметить, что полный переход не обязателен, но уже сейчас можно внедрять элементы: локальное хранение, офлайн‑UX, безопасный sync и понятную модель конфликтов. Это даст продукту устойчивость и пользователю - ощущение контроля.

P.S.
Минидокументалка всего на 10 минут, поэтому ее вообще изян посмотреть почти как shorts:)

P.P.S.
Эта документалка тоже попала на сайт system-design.space, так как в ней очень интересно обсуждаются компромиссы при проектировании распределенных систем.

#DistributedSystems #Architecture #SystemDesign #Software #Databases

Update: SDS (System-Design.Space)

С прошлого апдейта я не останавливал работу над проектом и добавил на сайт кучу нового:
- Добавил уровень сложности для глав и разметил их
- Добавил фильтрацию по типу материала и сложности
- Добавил возможность отслеживать прогресс прохождения, отмечая пройденные главы, а таже возможность откладывать главы в закладки (это завязано на local storage, поэтому пока не переносится по устройствам)
- Добавил много интерактивных архитектурных диаграмм в часть с задачами/кейсами
- Добавил в базовые практики проектирования главы про балансировку трафика, кеши, асинхронность
- Добавил части про безопасность и фронтовую архитектуру
- Добавил кучу глав в разные части программы.

В общем, мне очень нравится дорабатывать и расширять сайт. Если у вас есть идеи улучшений или репорты о багах, то пишите в комменты и я их учту в планах разработки

#SystemDesign #Interview #Career #Architecture #DistributedSystems #Databases #Engineering #Software

[1/2] Nvidia’s Explosive Rise from Zero to Trillions (Рубрика #Documentary)

С большим интересом я посмотрел этот документальный фильм рассказывает впечатляющую историю превращения Nvidia из стартапа на грани банкротства в компанию стоимостью $3 триллиона . Фильм охватывает путь от основания в 1993 году до текущего доминирования в области AI . Мне было интересно посмотреть, а какие этапы проходила компания и какие выводы можно почерпнуть нам как инженерам и техническим руководителям

Основание и первые годы
Nvidia была основана тремя инженерами - Дженсеном Хуангом, Крисом Малачовски и Кёртисом Примом - которые познакомились работая в Sun Microsystems и LSI Logic . Легендарная встреча состоялась в ресторане Denny's в Сан-Хосе, где за чашками кофе они обсуждали будущую компанию день за днем . Их ставка была на 3D-графику для PC и видеоигр, хотя на тот момент они даже не видели персональный компьютер . Название Nvidia произошло от латинского слова "invidia" (зависть), а также от сокращения NV ("next version"), которое основатели использовали при сохранении файлов . С начальным капиталом всего $40,000 и последующим финансированием $20 млн от Sequoia Capital, они начали свой путь .

Провал и чудесное спасение
Первый продукт NV1 (1995) оказался катастрофой: из 250,000 чипов, отправленных партнёру Diamond Multimedia, вернулось 249,000 . Проблемы были в том, что чип использовал quadratic primitives вместо triangle primitives, которые стали стандартом Microsoft DirectX, плюс был слишком дорогим . После отмены контракта с Sega на NV2, у компании осталось финансирование только на один месяц зарплат . Riva 128 (август 1997) стал продуктом, спасшим Nvidia - за четыре месяца он продался тиражом в миллион единиц, в отличие от NV1, который продал едва тысячу . С тех пор в компании существует неофициальный девиз: "Мы всегда в 30 днях от банкротства". Интересно, что в моем первом компьютере был чип riva tnt2, то есть я познакомился с творчеством ребят еще до начала 21 века:)

Прорыв и IPO
GeForce 256 (1999) стал первым в мире GPU с программируемым ускорителем - это был прорыв в концепции ускоренных вычислений . В январе 1999 года Nvidia провела IPO, что дало компании больше капитала и публичности . Следующим большим шагом стал контракт с Microsoft на $200 млн на разработку чипов для оригинального Xbox .

Поворот к AI
Самое интересное решение было принято в середине 2000-х: релиз CUDA в 2006 году - платформы параллельных вычислений, которая позволила использовать GPU не только для графики . Профессор Стэнфорда Эндрю Нг вспоминает, что уже в 2008 году его студенты экспериментировали с CUDA для deep learning и получали ускорение в 10-100 раз . Это был огромный риск: в конце 2000-х никто не знал, станет ли AI прибыльным . Nvidia приняла решение о масштабной трансформации компании, добавляя затраты, нанимая людей и отвлекая внимание от основного бизнеса в gaming и компьютерной графике . Хуанг описал это как "wholesale pivot" - полную переориентацию всей компании .

Интересно, что у меня был коллега в МФТИ, которого мы взяли пилить всякие веб-сайты, а он парарллельно занимался CUDA по научной траектории и в какой-то момент сказал нам ариведерчи и ушел заниматься CUDA фултайм.

Дальше карта AI пошла хорошо - в 2012 году случился AlexNet и произошел старт “современного AI”. NVIDIA прямо отмечает, что прорыв AlexNet стал спусковым крючком эры modern AI, и GPU оказался в центре этой волны. А про инсайты и выводы из этой документалки мы поговорим в следующий раз.

#Documentary #Infrastructure #AI #ML #Engineering #Software #Leadership #Startup #DistributedSystems

Dyad - local‑first AI app builder: как Lovable/Bolt, только на своем компьютере (Рубрика #AI)

Я как-то уже рассказывал про продукт Lovable, этакий "AI app builder", в котром написал запрос → получил изменения кода → увидел превью → опубликовал на прод. Собственно, то Dyad делает ровно этот цикл, но локально. В самом репозитории Dyad прямо позиционируется как local/open‑source альтернатива Lovable/v0/Bolt (и в целом - альтернативный путь по сравнению с облачными платформами).

Кстати, про подход local-first я тоже уже рассказывал, когда делал саммари на документалку и в dyad есть все признаки этого подхода
- Код и проект у вас на диске: без "платформенной клетки", можно импортировать/экспортировать и свободно переходить между Dyad и обычным dev‑workflow
- Bring your own keys: вы сами подключаете нужных провайдеров и модели (OpenAI/Google/Anthropic и т.д.), без принудительного вендор‑лок‑ина
- Расширяемость: можно добавлять инструменты через MCP‑серверы и жить на шаблонах (templates) под разные JS‑стеки

Функциональность Dyad похожа на Lovable и включает в себя
- Full‑stack приложения через Supabase: быстро подключить базу, auth и server functions
- Security review на базе AI: запускаете проверку, получаете находки с уровнями критичности и можете попросить AI исправить конкретную проблему; правила проверки можно подкрутить через SECURITY_RULES.md
- Автоматическое versioning: каждое AI‑редактирование - это новая версия; по сути это git‑коммит. Можно открыть список версий и “restore” до последнего удачного состояния (механика похожа на git revert, история при этом не теряется)
- Публикация: “publish anywhere” - GitHub/Vercel или ваш стек

Если говорить про архитектуру, то это устроено следующим образом
Dyad - это electron‑приложение:
- UI живёт в renderer process,
- Доступ к файловой системе и "применение изменений" - в main process,
- Общение идёт через IPC

Ключевой трюк AI-редактирования в том, что модель отвечает не "просто текстом", а в XML‑подобном формате команд. UI стримит и красиво показывает ответ, а затем main‑процесс (через response processor) применяет команды к проекту: создать/изменить/удалить файлы, добавить npm‑пакеты и т.п.
Отдельно отмечается, что Dyad не стремится быть максимально "агентным" как Cursor, потому что сложные agentic‑циклы быстро становятся дорогими - поэтому чаще это “один запрос → один аккуратный проход”, с опциональным авто‑фиксом TypeScript ошибок.

Подробнее про архитектуру проекта можно прочитать на сайте system-design.space, куда я выложил подробный разбор с картинками и визуализациями.

#AI #Engineering #Software #Architecture #DistributedSystems #Agents #ML

Inside Argo: Automating the Future (Рубрика #DevOps)

Если у вас Kubernetes в проде, то этот фильм про опенсорс проект может принести пользу - это история того, как Argo вырос из workflow‑движка в набор инструментов для автоматизации деплоев и процессов вокруг них (Workflows / CD / Rollouts / Events). В кадре появляются ключевые люди, что стояли у истоков Argo и которые в 2017 году запустили Argo и как вокруг него постепенно появлялось community и набор связанных инструментов. Также мы видим почему GitOps + Argo стали де‑факто стандартом для "предсказуемых" деплоев в cloud‑native мире.

Для инженеров просмотр может быть интересен, так как
- Это не "маркетинг инструмента, а кейсы взросления опенсорса: комьюнити, мейнтейнерство, стандарты качества/безопасности, и как из внутренней разработки получается индустриальный инструмент
- Это про масштаб: Argo прошёл путь CNCF Incubating (2020) → Graduated (2022), и CNCF отмечает сильную индустриальную динамику принятия инструмента (adoption)

На практике этот инструмент позволяет разработчикам иметь меньше ручных релизов и “магии” в пайплайнах → больше декларативности, повторяемости и отладки через Git как source of truth. А руководителям платформенных команд это дает понимание, что delivery‑контур - это продукт. Инструменты типа Argo ценны ровно настолько, насколько вы вкладываетесь в guardrails, стандарты и поддержку внутренней платформы.

P.S.
Более подробный разбор в моей статье на system-design.space.

#Kubernetes #DevEx #PlatformEngineering #Software #Architecture #DistributedSystems