Книжный куб

AI as Software Architect assistant by Avraham Poupko (Рубрика #Architecture) Интересное выступление Авраама Пупко про то, как AI может помогать архитектору. Авраам Пупко — ведущий архитектор программных систем, руководитель стратегического планирования и продуктовой архитектуры в Toga Networks, преподаватель системного мышления и проектирования. Более 25 лет он занимается анализом, моделированием и проектированием ПО, работал как с небольшими стартапами, так и с крупными корпорациями. В этом докладе он поднимает следующие ключевые темы и формулирует следующие тезисы 1) Роль AI как помощника, а не заменителя архитектора. AI не заменяет архитектора, а становится инструментом для повышения продуктивности и эффективности. Ключевой вызов — научиться использовать ИИ правильно, сохраняя ответственность за решения. 2) Границы возможностей AI. AI работает с языковыми моделями, а человек — с моделью мира. Архитектор должен понимать, что AI не обладает настоящим пониманием, а лишь манипулирует словами и связями между ними. Правда, сейчас есть разные гипотезы о том, а есть ли у LLM (и LMM) есть понимание модели мира или нет:) 3) Ответственность и этика. Архитектор всегда несёт ответственность за принятые решения, даже если использовал ИИ как советчика. Этические вопросы и осознанность остаются прерогативой человека. 4) Работа с неоднозначностью требований. AI помогает выявлять и анализировать неоднозначные требования, но не может полностью заменить архитектурное мышление и опыт в разрешении таких ситуаций. Тут можно почитать примеры идей в whitepaper типа "From Requirements to Architecture: An AI-Based Journey to Semi-Automatically Generate Software Architectures", про которую я писал раньше 5) Компромиссы и принятие решений. Архитектору важно уметь взвешивать плюсы и минусы разных подходов, а ИИ может помочь структурировать аргументы и рассмотреть альтернативы, но не принимает решения за человека. А пример такого подхода можно глянуть в whitepaper "A Prompt Pattern Sequence Approach to Apply Generative AI in Assisting Software Architecture Decision-makingture Decision-making", про который я писал раньше 6) Коллаборация и командная работа. Архитектор работает на стыке технологий, людей и организаций. ИИ может способствовать обсуждению и анализу, но не способен заменить человеческое взаимодействие и эмпатию. 7) Метафоры и модели. AI генерирует метафоры и помогает объяснять архитектурные решения, но глубина понимания и адаптация к контексту остаётся за архитектором. Я вот тоже люблю метафоры еще со времен начала карьеры, когда я прочитал книгу Стива Макконелла "Совершенный код", про которую я уже писал раньше 8 ) Жизненный цикл принятия решений. Архитектор проходит полный цикл: сбор информации, рассмотрение вариантов, принятие решения, действие, обратная связь. AI может быть полезен на отдельных этапах, но не охватывает весь цикл. Тут мне тоже видится перспективы в том, чтобы собирать мултиагентную систему, что сможет закрыть весь цикл принятия решения и дальше архитектору надо будет только отревьювить то, что эта система наделела:) 9) Ошибки, обучение и рост. Человеческий опыт, способность учиться на ошибках и развивать интуицию — уникальные качества архитектора, недоступные AI. Спорное утверждение, особенно, если немного изучить область reinforcement learning. 10) Будущее профессии и развитие навыков. Архитектору важно быть инициативным, критически относиться к советам ИИ, развивать экспертизу и не бояться экспериментировать. Только те, кто умеет эффективно использовать ИИ, останутся востребованными. Если подводить итоги выступления Авраама, то его мысль в том, что AI — это мощный инструмент для архитектора, но не его замена. Поэтому осваивайте ИИ, используйте его для повышения эффективности, но сохраняйте критическое мышление, ответственность и профессиональную инициативу. #Architecture #Software #Engineering #AI #SystemDesign #SelfDevelopment #Architect

Обложки книг "The 48 Laws of Power" и "48 Законов Власти", а также список всех законов.

The 48 Laws of Power (48 Законов Власти) (Рубрика #Management) В отпуск я взял с собой несколько бумажных книг, среди которых была и эта книга Роберта Грина "48 законов власти". В первый раз я прочитал ее порядка 20 лет назад и она показалась мне циничной и манипулятивной до невозможности:) Но я подумал, что стоит ее перечитать, ведь с тех пор я прочел "Государя" Макиавелли и Сунь-Цзы "Искусство войны". А эта книга написана в их стиле и содержит 48 "законов власти", каждый из которых сопровождается теоретическими обоснованиями и историческими примерами. Грин использует анекдоты из жизни исторических фигур, таких как Людовик XIV, Талейран, Отто фон Бисмарк, Екатерина Великая и Мао Цзэдун, чтобы проиллюстрировать практическое применение своих правил. Если бы книгу писали IT специалисты, то они бы ее назвали "48 Patterns of Laws", так как структура похожа на типичную книгу о паттернах, например, "Design Patterns", "Technology Strategy Patterns" или "Enterprise Integration Patterns". По словам самого автора, книга помогает "заглянуть в фундаментальные характеристики власти и способы ее завоевания, понимания и противостояния ей" Все 48 законов перечислять тут мы не будем, но несколько основных вспомним 1) Никогда не затмевай господина. Мысль в том, чтобы всегда делать так, чтобы твой начальник чувствовал себя умнее и значительнее тебя. 2) Скрывай свои намерения. Мысль в том, чтобы держать людей в неведении о своих планах. Пример из мира IT - rогда Microsoft объявил, что покупает GitHub "ради поддержки open-source сообщества", никто не сказал: "Мы хотим получить данные о миллионах разработчиков и их проектах для обучения нашего ИИ-помощника Copilot". Правда, тогда и копайлота еще не было 3) Пусть другие работают за тебя, но всегда бери заслуги на себя. Пример из мира IT - В Apple дизайн продуктов шел от Джони Айва, хотя над каждым продуктом трудятся сотни дизайнеров - В Amazon крупные проекты были "инициативами Джеффа Безоса" и не важно кто ее придумал 4) Учись делать людей зависимыми от тебя - чтобы сохранить независимость, необходимо, чтобы в тебе нуждались и тебя желали. Примеры из мира IT - Когда руководитель обеспечивает job-security за счет непрозрачности процессов и паутины связей. - Когда Apple создала целую экосистему устройств. Купил iPhone? Теперь тебе нужны AirPods. Потом MacBook, потому что "они так хорошо работают вместе". А теперь Apple Watch. И iCloud+. И AppleTV+ ... 5) Добивайся того, чтобы твои достижения казались легкими. В IT-компаниях часто говорят про "запуск новой функции", не акцентируя внимания на том, что на нее могут быть потрачены сотни человеко-лет. Надеюсь, что вы уже поняли, что "48 законов власти" - это не столько практическое руководство, сколько зеркало, отражающее тёмную сторону человеческой природы и социальных взаимодействий. Книга во многом напоминает "Вредные советы" Григория Остера - если воспринимать её буквально и следовать каждому совету, можно не только не добиться успеха, но и нажить много проблем. Многие законы Грина откровенно циничны и иногда аморальны, что признает и сам автор. Книгу часто критикуют за пропаганду манипуляций и макиавеллизма. Однако её ценность заключается не в прямом следовании советам, а в понимании механизмов власти, которые существуют в любой организации. Задуматься над этими "законами" стоит хотя бы для того, чтобы распознать, когда ими пользуются против вас. Книга может служить своеобразной вакциной от наивности в корпоративном мире, где за внешним лоском "плоских структур" и "открытых культур" нередко скрываются те же самые властные механизмы, что существовали при дворах королей столетия назад. Так что в следующий раз, когда вы увидите необъяснимые корпоративные решения или странные перестановки, то не удивляйтесь. #Management #Leadership #Politics #Strategy

Весенняя распродажа в издательстве «Питер» (Рубрика #Sales) В издательстве Питер очередная распродажа со скидками в 35% на бумажные книги и 50% на электронные. Для получения этой скидки надо использовать промокод "Бумажная" (или "Электронная", если покупаете элетронную версию) при оформлении заказа. На прошлых распродажах я уже купил себе пачку книг, половину из которых я уже прочитал, а половину нет (подробнее про эти книги можно прочитать здесь). Но с тех пор я получил еще пару книг по архитектуре - Head First Software Architecture (Head First. Архитектура ПО) - я ее уже прочитал и рассказал про нее (книга хорошая) - Acing the System Design Interview (System Design: пережить интервью) - я ее читаю сейчас и планирую рассказать про нее (книга хорошая) В общем, я обычно покупаю книги издательства Питер на таких распродажах - это удобно, так как я собираю батч и покупаю его раз в квартал:) #Sales

Интервью Windsurf CEO с Y Combinator: Betting On AI Agents, Pivoting in 48 hours, and the future of coding (Рубрика #AI) На выходных посмотрел интересное видео от Y Combinator, в котором представлено интервью с Варуном Моханом, основателем Windsurf (ранее Codeium). В интервью много интересных мыслей, но основные примерно такие 1) Ключевая трансформация компании (как Windsurf стал Windsurf) Компания Варуна начиналась как Exofunction, компания по виртуализации графических процессоров, но совершила pivot в за одни выходные в середине 2022 года. Причиной стало понимание того, что модели-трансформеры превратят их бизнес в commodity. Имея всего восемь сотрудников и несмотря на то, что они получили «пару миллионов revenue», они поставили всё на создание AI инструментов для разработки 2) Быстрое развитие и рост компании Всего через два месяца после pivot они выпустили свой первый продукт — изначально он был хуже по качеству, чем GitHub Copilot, но он был бесплатным 🆓. Они быстро улучшили свои показатели, обучив свои собственные специализированные модели для разработки, добавив возможности, которых не хватало их конкурентам. Вскоре после этого такие крупные предприятия, как Dell и JP Morgan Chase стали их клиентами и внедрили их продукт для десятков тысяч разработчиков. 3) Эволюция в Windsurf от расширения к собственной IDE Позже команда преобразовала свое расширение VS Code в Windsurf, полноценную IDE с возможностями агента, завершенную менее чем за три месяца менее чем с 25 инженерами. В отличие от конкурентов, сосредоточенных на интерфейсах чата, они создали «первый агентный редактор», предназначенный для более глубокого понимания кодовой базы и быстрых изменений. 4) Философия развития и видение будущего разработки Варун подчеркивает, что «каждый insight обесценивается», и компании должны постоянно внедрять инновации, чтобы выжить.

Technology moves fast. If we’re not continuing to have insights—and executing on them—we’re just slowly dying

Их разработка направляется строгими системами оценки, вдохновленными работой автономных транспортных средств. Он считает, что ИИ вскоре обеспечит «в 10 раз больше рычагов» во всех аспектах разработки программного обеспечения, превратив инжиниринг в более ориентированную на исследования область, где разработчики проверяют гипотезы, а не пишут повторяющийся код. Варун приходит к выводу, что демократизация разработки программного обеспечения означает, что «каждый станет строителем», поскольку технологии продолжают развиваться. В общем, мне понравился этот рассказ, из которого видно, что если ты хочешь делать продукт на переднем краю технологий, то важен 1) Не размер команды, а ее качество 2) Готовность команды к интенсивной работе 3) Готовность к ошибкам при проверке бесчисленного количества гипотез 4) Умение менять направление при изменении окружающих условий #AI #ML #Software #DevEx #Engineering #Development

Обложки книг "Head First Software Architecture" и "Head First. Архитектура ПО", а также пара внутренних страниц

[2/2] Head First Software Architecture (Head First. Архитектура ПО) (Рубрика #Architecture) Продолжая рассказ об этой книге о проектировании софта, стоит начать с алгоритма создания архитектуры на основе четырех измерений, который по мнению авторов выглядит примерно так 1) Определить architectural characteristics на основе требований. Важно выяснить, какие quality attributes критичны для вашей системы (performance, scalability и др.) 2) Принять architectural decisions - на основе выявленных характеристик принять решения о технологиях, паттернах и подходах 3) Определить logical components - разбить систему на функциональные блоки с учетом как раз функциональных требований, которые должны быть реализованы системой, а также архитектурных характеристик 4) Выбрать architectural style - подобрать стиль (например, microservices, layered), который поддерживает ваши характеристики, решения и компоненты Все четыре измерения взаимосвязаны - каждое должно соответствовать остальным. Architectural style должен соответствовать выбранным характеристикам и решениям, а logical components - поддерживать характеристики и вписываться в стиль. Структура книги выглядит следующим образом: в первых пяти главах дается введение в архитектуру и разбираются четыре измерения, описанные выше 1. Software Architecture Demystified: Let’s Get Started! 2. Architectural Characteristics: Know Your Capabilities 3. The Two Laws of Software Architecture: Everything’s a Trade-Off 4. Logical Components: The Building Blocks 5. Architectural Styles: Categorization and Philosophies В следуюзих частях разбираются архитектурные стили, причем авторы используют схему со звездочками для каждого стиля по избранным архитектурным характеристикам, куда входят maintainability, testability, deployability, simplicity, evolvability, performance, scalability, elasticity, fault tolerance, overall cost. Эти стили примерно соответствуют тому, что было в книге "Fundamentals of Software Architecture", где я в первый раз увидел эти таблички с этими рейтингами 6. Layered Architecture: Separating Concerns 7. Modular Monoliths: Driven by the Domain 8. Microkernel Architecture: Crafting Customizations 9. Do It Yourself: The TripEZ Travel App 10. Microservices Architecture: Bit by Bit 11. Event-Driven Architecture: Asynchronous Adventures В последней главе авторы предлагают спроектировать систему на основе выданных требований, используя алгоритм, предложенный в предыдущих главах 12. Do It Yourself: Testing Your Knowledge Заканчивается все приложением "A. Leftovers: The Top Six Topics We Didn’t Cover", в котором авторы обсуждают интересные темы, что не влезли в основную часть книги - Должен ли архитектор писать код - В чем состоят обязанности архитектора - Какие навыки, кроме технических, полезны архитектору - Немного про построение архитектурных схем - О глубине и широте знаний архитекторов - О пользе архитектурных кат В итоге, если суммировать, то эта книга хороша в качестве старта для погружения в software architecture, а дальше уже можно читать и более продвинутые книги по архитектуре. #Architecture #Software #Engineering #SystemDesign #DistributedSystems #Metrics #Architect

[1/2] Head First Software Architecture (Head First. Архитектура ПО) (Рубрика #Architecture) В отпуске я прочел книгу из серии Head First по архитектуре, которая вышла в марте прошлого года на английском, а в апреле этого уже появилась на русском в издательстве Питер. Вообще, я люблю серию "Head First" за доступное объяснение сложных тем, а архитектура софта - это определенно сложная тема:) Авторами книги были Раджу Ганди, Марк Ричардс и Нил Форд, причем двух последних я знаю хорошо - я читал их книги по архитектуре и мне показалось, что они уже исписались и я зарекся их читать. А вот Raju Gandhi был для меня новичком, но оказалось, что он уже написал несколько книг в серии "Head First" и его опыт благотворно повлиял на книгу - она мне показалась интереснее и полезнее "Fundamentals of Software Architecture" и "Software Architecture: The Hard Parts", которые писали Форд и Ричардс без Ганди:) Кстати, про обе книги я уже рассказывал: "Fundamentals ..." и "... Hard Parts". Если же возвращаться к книге "Head First Software Architecture", то это доступное введение в основы software architecture, оформленное в визуально насыщенном стиле (аля комикс), основанном на исследованиях в области когнитивных наук, что делает ее отличной отправной точкой для разработчиков, желающих освоить архитектурное мышление. Основная мысль книги базируется на четырех измерениях архитектуры, которые выделяют авторы 1) Architectural Characteristics Это то, какие свойства (нефункциональные требования, атрибуты качества, архитектурные характеристики) система должна поддерживать - такие как scalability, testability, availability и др. Интересно, что я недавно разбирал whitepaper "Quality Metrics in Software Architecture" (1 и 2), где очень подробно разбирались - QualityElements - элементы качества, которые по мнению авторов этой статьи юывают трех видов - Metric — конкретная метрика для измерения качества архитектуры - QualityCharacteristic — глобальная характеристика качества (например, reliability, maintainability) - QualityAttribute — атрибут качества, связанный с одной из характеристик Авторы книги настолько не упарываются по этим -ilities, но отмечают, что архитектурные характеристики — это основа архитектуры, без которой невозможно принимать архитектурные решения или анализировать компромиссы. 2) Architectural Decisions Это решения, оказывающие долгосрочное или значимое влияние на систему, например, выбор базы данных, количество сервисов, способы их взаимодействия. Architectural decisions задают структуру для команд разработки, определяя, например, количество сервисов и типы баз данных. Забавно, что лет 5 назад я сам рассказывал про наши архитектурные процессы в Т (Архитектура в масштабе на ArchDays 2020) и там было про RFC (request for comments) и ADR (architecture decision records) 3) Logical Components Это функциональные строительные блоки системы и их взаимодействие. Например, в e-commerce системе это могут быть inventory management и payment processing. Logical components - это как комнаты в доме: базовые структурные элементы с определённой функцией. 4) Architectural Styles Это общее физическое устройство и структура системы, аналогично тому, как план здания определяет структуру дома. Architectural styles можно классифицировать по - Стилю разбиения (technical или domain partitioned) - Модели деплоя (monolithic или distributed) В следующем посте будет рассказан алгоритм применения этих четырех измерений при проектировании, а также про общую структуру книги. #Architecture #Software #Engineering #SystemDesign #DistributedSystems #Metrics #Architect

Balancing Coupling in Software Design - GoTo Book Club 2025 В недавнем интервью для GOTO 2025 Влад Хононов представил свою новую книгу "Balancing Coupling in Software Design" в беседе с Шином Брисалсом. Про книги и выступления Влада я уже как-то рассказывал раньше - Про его книгу "Learning DDD", на которую я написал 4 кратких обзора: общий обзор DDD, DDD и микросервисы, DDD и event-driven architecture, DDD и data mesh - Про его выступление "Сложность и модулярность две стороны одной медали" на ArchDays с частью истории про coupling еще до публикации книги (1 и 2) А вот интервьюера я видел в первый раз, хотя Шин Брисалс тоже автор книги "Serverless Development on AWS: Building Enterprise-Scale Serverless Solutions" (O'Reilly, 2024), который специализируется на помощи командам в проектировании, создании и эксплуатации устойчивых serverless-решений Основными темами интервью были - История исследования coupling в системах - здесь Влад рассказывает, как неудачный проект с микросервисами подтолкнул его к глубокому изучению принципов coupling в архитектуре ПО - Вневременная природа проблем проектирования - несмотря на эволюцию технологий, базовые принципы проектирования и управления связями остаются неизменными на протяжении десятилетий. Влад вдохновлялся книгами 70-х годов - Три измерения связей: интеграционная сила (knowledge sharing), дистанция и волатильность - фундаментальная модель для оценки связей между компонентами. Ниже представлены основные идеи об этих трех измерениях, хотя собеседники их прямо отдельно не проговаривали -- Оценка силы интеграции между компонентами является ключевой, начиная от интрузивной связи (высокий обмен знаниями) до контрактной связи (низкий обмен знаниями). -- Когда физическое расстояние между компонентами увеличивается (например, переход к микросервисам), связь должна быть сбалансирована за счет сокращения общих знаний (например, с четкими контрактами API и отсутствием прямого доступа к данным). -- Прогнозирование и управление изменчивостью, т. е. скоростью изменений, также имеет решающее значение при проектировании для соответствующего уровня связи. Если один компонент, например устаревшая система, не должен меняться, то высокая сила интеграции или большое расстояние не являются проблемой. - Декомпозиция проблем и оценка сложности - подходы к разбиению сложных задач и объективной оценке их сложности с учетом неопределенности - Локальная vs глобальная сложность - как оптимизация локальной сложности отдельных компонентов может привести к увеличению глобальной сложности системы - Модульность как противовес сложности - модульность является ключом к созданию масштабируемых и поддерживаемых систем - Границы знаний и абстракции - как правильные абстракции создают эффективные границы знаний между компонентами - Креативный подход к техническому писательству - использование поэзии в технической книге для лучшего донесения сложных концепций (здесь Влад рассказывает как genAI помогал ему писать стихи для этой книги) Если обобщать, то эта книга получилась не такой легкой как "Learning DDD", но она все равно очень полезна для всех, кто стремится создавать гибкие, масштабируемые и поддерживаемые программные системы через правильное управление связями между компонентами. #Software #Architecture #DistributedSystems #SystemDesign #Patterns #Sofware #Metrics #Management

Конференция T-Observability Day 2025 (Рубрика #SRE) 19 мая в Москве пройдет конференция для обмена опытом и обсуждения современных практик в области наблюдаемости, мониторинга и управления инцидентами в сложных распределённых системах. Доступно как оффлайн, так и онлайн участие. В программе будут три отдельных сессии 1) 10:30—12:00 - Сессия лидеров-визионеров Здесь пройдет дискуссия о том, как повысить операционную устойчивость и эффективность бизнеса. Участники обсудят как в условиях 2025 года эффективно развиваться, какую роль в этом играют платформы наблюдаемости и аналитики операционных данных и что за горизонтом: какие технологические тренды ближайшего будущего важно отслеживать уже сегодня 2) 12:30–14:15 - Сессия практиков Здесь пройдет дискуссия о том, как совмещать два в одном: наблюдаемость и непрерывную аналитику операционных данных. Участники поговорят о сценариях использования платформ наблюдаемости в разных отраслях: как расти, масштабировать бизнес, становиться ближе к клиентам с помощью лучшего опыта и проактивного сервиса. Обеспечивать надежность, безопасность цифровых продуктов и быстрее внедрять инновации 3) 15:00–16:45 - Сессия разработчиков и пользователей Здесь пройдет дискуссия о том, как выглядит технологический вектор развития платформ наблюдаемости и связанных с ними компонентов. Участники разберут какие подходы, платформы и инструменты актуальны для решения задач наблюдаемости, мониторинга и инцидент-менеджмента. А кроме выступлений будут еще зоны для прямого общения с инженерами и разработчиками платформ, где можно узнать о решениях FineDog (управление жизненным циклом инцидентов) и Sage (наблюдаемость инфраструктуры, кросс-кластерный поиск, алертинг и дашборды). Кроме этого будет рассказ про Технологический радар Observability на базе радаров от Thoughtworks, куда входят 80+ практик, платформ, фреймворков и инструментов по наблюдаемости за последние 15 лет — для внедрения и развития современных практик и инструментов SRE, DevOps, ITOps, NetOps Сама конференция ориентирована на разработчиков, SRE-инженеров, специалистов по DevOps и ITOps, заинтересованных в современных подходах к мониторингу, анализу инцидентов и повышению надёжности сервисов. А для участия надо зарегестрироваться на сайте и дождаться подтверждения участия. #SRE #DevOps #Architecture #Software #Processes #Metrics #Engineering

Understanding Distributed Architectures - The Patterns Approach (Рубрика #Architecture) Недавно на конференции YOW! 2024 выступил Unmesh Joshi, известный эксперт в области распределённых систем, который является Principal Consultant в ThoughtWorks с более чем 20-летним опытом работы в индустрии. Это выступление является кратким изложением его книги "Patterns of Distributed Systems", изданной в 2023 году в серии Мартина Фаулера (на сайте Мартина есть краткая версия каталога паттернов из этой книги). Понятно, что в 35 минутном выступлении рассказать все 30 паттернов из книги он не смог, но вот вот какие темы у него раскрыть получилось - Введение в распределённые системы - современные системы включают облачные сервисы (cloud services), Kafka, Kubernetes и многие другие распределённые технологии. - Самоподобие шаблонов - паттерны (patterns) применимы на разных уровнях абстракции и часто демонстрируют свойства самоподобия (self-similarity). Мне это напомнило фракталы:) - Изучение открытого кода - для выявления шаблонов Unmesh использует "правило трёх реализаций", анализируя open source проекты распределенных систем (Kafka, K8s, Cassandra, ...) - Каталог из 30 шаблонов - созданный автором каталог шаблонов помогает понять внутреннее устройство распределённых систем, с примерами из реальных продуктов. - "Симпатия к платформе" - концепция, аналогичная "механической симпатии" (mechanical sympathy) в автогонках, помогающая эффективно использовать системы.

Mechanical sympathy is when you use a tool or system with an understanding of how it operates best. You don't have to be an engineer to be be a racing driver, but you do have to have Mechanical Sympathy. Jackie Stewart, racing driver.

- Важность практического опыта - реальный код устраняет двусмысленность и превращает абстрактные концепции в конкретные решения. У автора на Github есть репозитории с примерами распределенных систем для оркестрации контейнеров (аля K8s), messaging system (аля Kafka), nosql database (аля Cassandra) - Структурирование через шаблоны - паттерны помогают организовать информацию и сделать код более понятным, устраняя неясности в документации. Я бы добавил, что они позволяют использовать инженерам общий язык при проектировании сложных систем - Архитектура как последовательность паттернов - знание шаблонов упрощает понимание сложных архитектур, а также проектирование собственных систем - Согласованное ядро и управление метаданными - пример паттерна, где небольшой кластер с высокой степенью согласованности (high consistency) управляет метаданными (metadata), что позволяет основному кластеру масштабироваться до тысяч узлов (nodes). По-факту, это стандартная концепция с разделением control plane и data plane. - Применение шаблонов в реальных системах - у автора есть демонстрация реализации паттернов на примере мнииатюрных версий Kubernetes и Kafka для обучения (можно поискать на Github аккаунте автора, который я приводил выше) Ну и финальная мысль выступления в том, что эти шаблоны помогают уменьшить случайную сложность (accidental complexity) и прояснить существенную сложность (essential complexity) распределённых систем (distributed systems), что помогает разобраться с таким сложной темой:) #Software #Architecture #DistributedSystems #SystemDesign #Patterns #Sofware

9 мая Поздравляю всех с Днем Победы ... а себя еще и с окончанием поездки в Китай, где я провел две недели со своей семьей, чуток подустал от отдыха и рад вернуться на вторые майские праздники в Россию. В связи с этим мой перерыв с постами в этот канал оканчивается и дальше они пойдут примерно в прежнем темпе.

Диснейленд в Шанхае (Рубрика #Travel) Во второй раз за месяц приехал в Китай, но на этот раз с семьей. Первым делом мы отправились в Диснейленд, чтобы прочувствовать атмосферу диснеевских мультфильмов. В принципе, у нас это получилось - мы пришли к 8.30 в парк, а ушли в районе 17.00, полностью посетив все, что входили в fast tack из 11 аттракционов. Круто, что самого маленького сына пустили почти везде. Особенно нам понравился громадный ландшафтый парк и общая атмосфера с музыкой и парадами игровых персонажей по улицам города. В общем, мы с женой вспоминили свое детство со старыми диснеевскими мультиками, а детишки простт увидели воплощенные сказки, которые они часто видят в телевизоре. Один день на Дичнейленд конечно потратить стоит, но больше одного дня по нему ходить было бы скучно. #Travel #Cinema

The Beauty of Simplicity - Making Your Own Technology • Yan Chernikov • YOW! 2024 (Рубрика #Architecture) Посмотрел недавно интересно выступление Яна Черникова (The Cherno), австралийского разработчика, популярного YouTube-блогера и бывшего инженера Electronic Arts. Его основной вклад — образовательный контент по C++, разработке игровых движков и программированию, а также создание собственного 3D-движка Hazel. Черников прославился благодаря подробным видеоурокам по архитектуре игровых движков и практическим сериям по созданию Hazel с нуля. До Hazel он работал над движками Osiris и Frostbite в EA, но ушёл, чтобы сосредоточиться на собственных проектах и образовательной деятельности. В этом выступлении он рассказал интересный доклад про красоту простоты. В своем докладе он подчёркивает ценность простоты как основы для выживания и эффективности в разработке собственных решений. Вот основные темы, что он затронул в своем рассказе - Как он пришел к Hazel и почему это было вызовом самому себе и стало образовательным проектом для сообщества - Как Hazel вырос из личного проекта в командную разработку благодаря вовлечённости сообщества и добровольцам - Как выглядит образовательная часть - самHazel и сопутствующие видео используются для обучения C++, архитектуре движков и демонстрации реальных кейсов разработки - Как сравнить использование готовых движков с созданием собственного продукта - Unity и Unreal Engine против Hazel - Какие основные неявные критерии выбора: лицензии, поддержка, найм специалистов - все это важные аспекты при выборе между готовыми решениями и самостоятельной разработкой - Как работать с зависимостями и почему важна модульность - лучше минимизировать внешние зависимости и работать модульно - это обеспечит гибкость и возможность менять отдельные модули под свои задачи - Почему open source помогает делает свои решшение - сейчас есть много открытых решений, что позволяют ускорить разработку и делегировать часть задач готовым решениям - Что такое VSDD (vertical slice driven development) - я уже как-то рассказывал про доклад "Designing for change with Vertical Slice Architecture - Chris Sainty - NDC London 2024", где об это рассказывают сильно подробнее Вертикальная разработка и оптимизация Подход VSDD: развитие всех компонентов проекта параллельно, а не углубление только в одну часть; простота как ключ к эффективной оптимизации. - Почему важно поступательное движение и фокус на конечном продукте, а также зачем пробовать создавать свои решения, даже если это кажется сложным В общем, Черников вдохновляет разработчиков не бояться создавать свои технологии, ценить простоту и учиться на реальных задачах, а не только на готовых решениях. #Architecture #SystemDesign #Engineering #Management #Software

What Every Programmer Should Know about How CPUs Work • Matt Godbolt • GOTO 2024 (Рубрика #Engineering) Посмотрел на неделе интересное выступление Мэтта Годболта, британского программиста, разработчика игр и бывшего сотрудника Google, наиболее известного как создатель популярного среди разработчиков инструмента Compiler Explorer. В этом выступлении Мэтт рассказывал о вещах, которые обязательно знать программистам о том, как работают CPUs (да, я знаю, что сейчас более модно рассказывать о том, как работают GPUs, но мы тут про базу, а не про хайп). Доклад проливает свет за 45 минут на следующие вещи - Как выглядит архитектура современных процессоров в плане конвейерной обработки инструкций, что такое фронтэнд и бэкэнд в процессорах - Как базово работает механизм branch prediction (предсказания ветвлений) - Как процессоры разбирают инструкции и избегают конфликтов при работе с регистрами. - Как достигается одновременное выполнение множества инструкций и почему это важно для производительности (тут про буфер переупорядочивания) - Как процессор реагирует на ошибки (например, сегментации) и отменяет неверные вычисления. - Как точность предсказания ветвлений напрямую влияет на скорость работы программ. - Как сортировка данных и особенности кода влияют на эффективность исполнения (примеры на Python и C++) - Почему деление — одна из самых медленных операций, как компиляторы и программисты могут это обойти (роль кэшей и памяти) - Какие инструменты можно использовать для анализа производительности (Perf, Compiler Explorer, Cache Grind и другие) В итоге, этот доклад прямо интересно посмотреть тем, кто хочет писать быстрый и эффективный код, понимая, как реально работают современные процессоры и компиляторы. #Engineering #Software #Architecture #Hardware

[3/3] Quality Metrics in Software Architecture (Рубрика #Architecture) Заканчивая рассказ (1 и 2) про этот whitepaper поделюсь иллюстрациями из самой статьи

[2/3] Quality Metrics in Software Architecture (Рубрика #Architecture) Продолжая рассказ про эту научную статью, поговорим про методологию исследования и подход к реализации. Для реализации своего фреймворка авторы взяли следующие инструменты - Модель реализована с помощью доменно-специфического языка (Domain-Specific Language, DSL) на базе xText, что позволяет текстово описывать элементы качества и их связи. - Для визуализации используется генератор кода (xTend), который строит интерактивные веб-интерфейсы: списки метрик и атрибутов, а также граф взаимосвязей между ними. - Каталог поддерживает расширение и коллективную работу: любой участник может предложить новую метрику или атрибут через pull request, после чего данные автоматически попадают в визуализацию (правда, в репозитории не было pull requests за все время) Если описывать подход авторов к исследованию, то он был достаточно строгим - Они сформулировали исследовательские вопросы (RQ1–RQ4): какие метрики и атрибуты используются, являются ли они универсальными или специфичными, внутренними или внешними, и как их применять на практике. - Они сформулировали поисковую стратегию: запросы по ключевым словам в пяти крупнейших научных базах (IEEExplore, ACM Digital Library, Scopus, Springer Link, ScienceDirect) за период 2011–2022 гг. - Они отфильтровали найденные публикации по релевантности, языку, типу публикации и другим критериям, из 746 публикаций осталось всего 33 - Они проанализировали и классифицировали найденные метрики и атрибуты - для этого использовались характеристики из ISO/IEC 25010:2011, а потом они добавили классификацию по признакам generic/specific (универсальные/специфичные) и internal/external (внутренние/внешние) - На основе этого они собрали модель и дальше использовали DSL для описания и генерации визуализаций Этот подход обеспечивает полноту охвата, прозрачность критериев отбора и воспроизводимость результатов. Важным аспектом является открытость каталога для дальнейшего пополнения и коллективного развития. Авторы подчёркивают, что их каталог и фреймворк — это "живой" инструмент, который должен развиваться совместно с профессиональным сообществом. Основные направления будущих исследований и развития: - Оценка и валидация с участием стейкхолдеров: планируется провести пользовательские исследования с архитекторами и экспертами для проверки удобства и полезности DSL и каталога. - Комьюнити-драйв развитие: каталог открыт для внешних вкладов, его развитие зависит от активности сообщества инженеров и исследователей. - Интеграция в практику: каталог может использоваться для: -- Поиска и выявления новых или отсутствующих связей между метриками и атрибутами; -- Поддержки инструментов автоматической оценки качества архитектуры; -- Анализа влияния одних атрибутов качества на другие (impact traceability); -- Построения переиспользуемых моделей качества и SaaS-решений, не зависящих от конкретного архитектурного языка. - Расширение набора внешних метрик: большинство найденных метрик — внутренние, поэтому требуется разработка и внедрение большего количества внешних метрик, отражающих восприятие качества пользователями и заказчиками. - Валидация связей между атрибутами: каталог помогает выявлять неожиданные или спорные связи между атрибутами качества, что может стать поводом для новых исследований и экспериментальных проверок В итоге, эта статья предлагает систематизированный и практически применимый каталог метрик для оценки архитектуры ПО, реализованный в виде расширяемой модели и фреймворка. #Architecture #Metrics #Software #Engineering #SystemDesign #Management

Platform Engineering Night (Рубрика #Engineering) Только что начиналась наша конференция Platform Engineering Night (трансляция доступна здесь). Конференцию открыл Игорь Маслов, наш VP of Coretech & Data. Сама конференция про то, как платформы дружат с искусственным интеллектом! Эта дружба пройдет под знаком Productivity & AI, мы погрузимся в реальные кейсы, где AI не просто модное слово, а инструмент, который уже сегодня автоматизирует рутину, предсказывает сбои, масштабирует сервисы и повышает продуктивность команд. Только проверенные подходы, которые работают в проде — никаких теорий, только практика. 1) На сцену выйдут заслуженные джентельмены и лидеры индустрии: Игорь Маслов (Т-Банк), Евгений Колесников (Yandex Infrastructure), Денис Артюшин (Nestor, Т-Банк), Иван Юрченко (FineDog, Т-Банк) и другие. Они расскажут, как строить собственных AI-ассистентов, эволюционировать SRE и внедрять AI в инженерные платформы. 2) Помимо докладов будут демонстрационные зоны, где можно пообщаться с инженерами, потрогать платформы руками и узнать, как устроены LLM Platform, FineDog и другие решения для автоматизации и управления инцидентами. 3) Будет экспериментальный контент в виде кодинг-батла: AI против человека! Кто быстрее и качественнее решит задачу — разработчик или AI-ассистент? Сначала — битва, потом разбор полётов от экспертов. Голосуй за фаворита и участвуй в обсуждении: сможет ли искусственный интеллект заменить живой опыт и инженерное мышление? 4) Ну и конечно будет крутой нетворкинг, где можно будет обменяться опытом с практиками, найти единомышленников, обсудить острые вопросы и заводи новые профессиональные связи. P.S. Я присутствую на этой конференции, так что если кто-то уже у нас в гостях, то пишите, сможем поговорить очно:) #PlatformEngineering #Architecture #Processes #Conference

JVM Day от Т-Банка (Рубрика #Software) В конце лета пройдет очередная конференция про JVM технологии от Т-Банка. На конференции будут обсуждаться инженерные практики, сложные кейсы, нестандартные решения. В этом году будут три секции: Java, Scala и Backend. В текущий момент открыт прием заявок (call for papers), причем приветствуются следующие темы для каждой секции - Java: инструментарий и тулинг, грядущие возможности Java и Kotlin, Java Enterprise, качество и организация кода, JVM, технологии в ретроспективе и истории факапов. - Scala: новые фичи языка и их использование, подходы к разработке, инструменты, системы эффектов (Cats Effect, ZIO, Kyo), обзор и сравнение библиотек. - Backend: опыт внедрения архитектурных подходов и практик, микросервисная архитектура, надежность и доступность, инфобез, инфраструктурные оптимизации, AI в разработке, устаревающие технологии и автоматизация тестирования. Если у вас есть желание поделиться интересной историей, то не держите ее в себе и подавайте заявку на сайте конференции до 16 мая (по своему опыту члена программного комитета могу сказать, что если подаешь заявку раньше, то шанс получить одобрение выше) #Software #Engineering #Architecture