Книжный куб

[1/3] A Prompt Pattern Sequence Approach to Apply Generative AI in Assisting Software Architecture Decision-making (Рубрика #Architecture) В декабре 2024 года вышел whitepaper на тему использования Gen AI в архитектуре. Я заинтересовался этой темой и решил прочитать что же придумали ребята. Оказалось, что это некоторый co-pilot для архитекторов, который помогает правильные решения. Для этого авторы предлагают использовать паттерны промптинга, что объединяются в цепочку подготовки, анализа и принятия архитектурных решений. Основные паттерны здесь следующие - Software architect persona pattern - Architectural project context pattern - Quality attribute question pattern - Technical premises pattern - Uncertain requirement statement pattern - Prompt pattern sequence Эти паттерны авторы исследования опробовали на 3 компаниях - двух настоящих (leading automobile financing bank's technological portal и leading retail pharmacy network) и одной вымышленной компании, что по легенде делает cloud-based CRM. В самом начале авторы рассказывают как выглядит их подход к описанию указанных выше паттернов, куда входят как стандартные аттрибуты вида: Name, Context, Problem, Forces, Solution, Rationale и Consequences, а также расширенный список - Specializes: описывает, как текущий стандарт специализируется или расширяет существующие стандарты, уточняя их связь и адаптацию для решения конкретных задач или контекстов. - Statement template: предоставляет краткое описание или структурированное резюме стандарта, позволяя быстро понять его суть. - Concrete statement example: приводит реальный пример использования шаблона описания, демонстрируя его применение на практике. - Related patterns: содержит информацию о других паттернах, связанных с текущим, включая зависимости, предпосылки и рекомендации по совместному использованию (связанные паттерны вынесены в приложение к статье) - Usage example: приводит практический пример из реальной жизни, показывающий применение паттерна и его полезность в конкретной ситуации. - Known uses: представляет исторические или текущие примеры успешной реализации паттернов, подтверждая их эффективность и предоставляя ссылку на выполненный запрос для получения дополнительных деталей. Сам flow работы с паттернами и Gen AI инструментами по мнению авторов статьи выглядит так 1) Архитектор ищет подходящие паттерны из списка выше 2) Дальше он применяет их для своего конкретного проекта и получает подсказки и предложения 3) Дальше он принимает решения после анализа сгенерированных подсказок и своего знания проекта Все звучит достаточно понятно, но давайте перейдем к самим паттернам, а потом рассмотрим как авторы предлагают объединять их в цепочку промптов для ассистирования в анализе архитектуры проекта и принятии арх решений. Сами паттерны будут рассмотрены в следующем посте. #Architecture #GenAI #AI #ML #Software #Engineering #SystemDesign #DistributedSystems #Project

Что читают CTO? (Рубрика #Management) Недавно я поделился своим списком рекомендованных tg-каналов с ребятами из Holyweb (аутсорс/аутстафф компания) и South HUB (сообщество C-Level). Они совместно проводили опрос технических директоров о том, а какие книги и telegram каналы они читают. Про книжки у меня спрашивать не стали, а вот про каналы спросили. Я поделился списком, но все они на мою карточку не влезли:) Еще в этом опросе участвовали ребята из Делимобиля, Звука, МТС Travel и других компаний и все рассказывал о том, что помогает им управлять ресурсами, доносить идеи до команд и инвесторов, а также создавать эффективные и конкурентные IT-решения. Ниже представлены карточки с рекомендациями уважаемых людей, а мой полный список рекомендаций доступен здесь. #AI #Software #Engineering #Management

Vibe Coding Is The Future (Рубрика #AI) Интересное видео от Y Combinator с обсуждением vibe coding, подхода к программированию, который описал Андрей Карпаты, сооснователь OpenAI и бывший директор по ИИ в Tesla. В феврале 2025 года он опубликовал твит, описав личный опыт использования Cursor Composer с интеграцией Whisper для голосового управления. В итоге, ребята из Y Combinator решили разобрать насколько этот подход к разработке меняет правила игры. Основные моменты обсуждения следующие 1) Роль инженера в эпоху ИИ Согласно опросу YC, 25% основателей утверждают, что 95% их кодовой базы генерируется ИИ. Это не означает исчезновения технических навыков, но переопределяет приоритеты и ключевая компетенция смещается в сторону продуктового мышления - умения определять, что строить, а не как это кодировать. Интересно, что мы недавно именно это обсуждали с S0ER в подкасте Code of Leadership 2) Инструменты и рабочие процессы Cursor и Windsurf стали фаворитами благодаря интеграции с кодовой базой и автономному анализу файлов. Gemini выделяется длинным контекстным окном, позволяя загружать всю кодовую базу для исправления ошибок. Sonnet и Deepseek конкурируют в качестве движков для генерации, тогда как Devin пока ограничен простыми задачами. При этом отладка остаётся слабым звеном: ИИ часто неспособен исправить ошибки, требуя полной перегенерации кода. Основатели сравнивают это с перегенерацией изображений в Midjourney с тем же промптом - вместо точечных правок код переписывается с нуля. 3) Трансформация найма и образования Классические алгоритмические собеседования устаревают. Компании вроде Stripe и Gusto переходят к оценке практической продуктивности, например, созданию прототипа за 3 часа. Однако для масштабирования проектов критически важны системные архитекторы — специалисты, способные оптимизировать инфраструктуру под высокие нагрузки. Поколение Z, начинающее карьеру с ИИ-инструментами, демонстрирует уникальные преимущества. Обученные в «цифровой среде», они избегают классического синтаксического бремени, фокусируясь на логике и продуктивности. Однако без фундаментального понимания архитектуры (как в случае с Twitter и его проблемами масштабирования) даже генерируемый код рискует стать "техническим долгом". 4) Будущее разработки: Рекомендации и риски - Интеграция ИИ в образование: Учебные программы должны совмещать генерацию кода с глубоким пониманием системного дизайна. - Пересмотр метрик найма: Акцент на навыках отладки, код-ревью и продуктовом видении вместо алгоритмических головоломок. - Инвестиции в инструменты отладки: Текущие LLM слабы в анализе ошибок — это направление станет ключевым для следующих версий моделей. Все эти тезисы авторы подкаста подтверждают цитатами из общения с основателями стартапов, что входят в Y Combinator. #AI #Software #Engineering #Management #SystemDesign #ProductManagement #Productivity #Architecture

Clean Architecture (Чистая архитектура) (Рубрика #Architecture) Я прочитал эту книгу Дяди Боба (Роберта С. Мартина) шесть-семь лет назад и нашел концепции достаточно интересными, а по самым интересным частям я даже сделал подробные разборы: "Дизайн и архитектура, парадигмы программирования" и "Принципы дизайна модулей и разделения по компонентам", но все это было до старта этого канала. Поэтому сегодня я решил исправить это недоразумение и рассказать об этой книге, в которой Дядя Боб подчеркивает важность разделения ответственности и независимость от фреймворков, баз данных и пользовательских интерфейсов. Дядя Боб это делает очень ультимативно, что сильно подрывает веру в его подход. Ключевыми идеями являются следующие Правило зависимостей: зависимости исходного кода должны указывать только внутрь, в направлении высокоуровневых политик. Это создает систему, в которой бизнес-правила не зависят от технических деталей. Слоеность архитектуры: при реализации этого правила у нас появляются отдельные слои - Entities (cущности) - основные бизнес-объекты и корпоративные бизнес-правила - Use cases (варианты использования) - бизнес-правила конкретного приложения. Тут забавно, что этот термин взят из UML, где так называется один из видов диаграмм, про которые я рассказывал раньше - Interface adapters (адаптеры интерфейса) - контроллеры, презентеры и шлюзы - Framework & drivers (фреймворки и драйверы) - внешние инструменты, базы данных, UI-фреймворки Этот архитектурный подход близок к гексагональной архитектуре (hexagonal architecture) или порты и адаптеры и луковая архитектура (onion architecture). Она также активно включает принципы SOLID, особенно принцип инверсии зависимостей, на котором строится вся слоистость и правило зависимостей. Боб говорит о том, что архитектура должна "кричать" о своем назначении — при взгляде на структуру кодовой базы она должна отражать бизнес-домен, а не технические детали. С точки зрения применимости clean architecture наиболее полезна в следующих сценариях: - Сложные или долгоживущие приложения, где поддерживаемость является критически важной - Системы, где доменную модель решили выделить отдельно и использовать стиль DDD (domain driven design) - Проекты, требующие четкого разделения между бизнес-логикой и инфраструктурой Она помогает создавать системы, которые могут развиваться со временем в соответствии с изменяющимися бизнес-потребностями, и обеспечивает гибкость для замены фреймворков, баз данных или UI-технологий с минимальным влиянием на основную бизнес-логику. Но этот подход заслуженно критикуют за - Избыточную сложность для малых или простых проектов с прямолинейными требованиями - Чрезмерную слоистость и натыкивание интерфейсов без явных преимуществ, что приводит к "злоупотреблению интерфейсами" - Избыточный шаблонный код и абстракции, которые затрудняют понимание системы - Чрезмерно крутую кривую обучения для инженеров и строгую дисциплину для правильной реализации - Замедление начального развития проекта из-за предварительных усилий по проектированию - Низкую производительность итогового решения из-за чрезмерного количества абстракций Итого, я видел подходы к применению Clean Architecture для повышения качества кода в существующих проектах, но я уже активно не писал код сам, когда Uncle Bob явил свою концепцию миру. Именно поэтому я не могу оценить из первых рук насколько с ней получаются хорошие приложения:) Но мне кажется, что это как с любым подходом - можно сделать хорошо, а можно тяп-ляп ... Чистая архитектура тут не исключение. #Architecture #Software #Engineering #DistributedSystems #SystemDesign

Code of Leadership #31 - Hooked: how to build habit-forming products (Рубрика #Management) Новый эпизод подкаста посвящён обсуждению книги Нира Эяля «На крючке» и её модели создания продуктов, формирующих привычки. Для обсуждения книги пришел Евгений Сергеев (S0ER), который поделился опытом применения модели в разработке ПО, обсуждения её этических аспектов и влияния на пользователей. В общении мы затронули темы поведенческих триггеров, адаптации продуктов к привычкам пользователей, а также эволюции технологий, программирования и роли разработчиков. Особое внимание уделили важности обратной связи, доверия пользователей и интеграции продуктов в экосистемы. Евгений уже много лет публикует хорошие видео на Youtube на канале S0ER, а также у него есть каналы в tg (@softwareengineervlog и @soer_live). Он много рассказывает про хард скиллы в обще, а также про проектирование и архитектуру в частности. Выпуск подкаста доступен в Youtube, VK Video, Podster.fm, Ya Music. #Architecture #Software #Engineering #ProductManagement #Management #Economics

CTO Conf X и Teamlead Conf (Рубрика #Management) Я уже рассказывал раньше про конференцию CTO Conf X, которая пройдет этим летом, в программном комитете которой я состою. А программный комитет так устроен, что его участники ревьювят все заявки на конференцию и выбирают лучшие доклады. Сейчас у нас уже есть порядка 120 заявок на примерно 20 мест, то есть конкурс 6 к 1, что достаточно солидно. В итоге, нам приходится повышать требования по качеству и стараться искать доклады, которые принесут что-то новое и интересное нашей аудитории. И одним из критериев для меня является сравнение с тем, а как заявленную тему раньше раскрывали на другой конференции Онтико, которая идет уже давно и где обычно обсуждались темы менеджмента и эта конференция "Teamlead Conf". Я сам выступал на ней несколько раз, а также знаю многих спикеров и членов программного комитета, то есть конференция достойная. Теперь представьте, что ко мне попадает заявка про создание самой перформящей команды, которая мотивирована на достижение результата, причем именно такого что нужен бизнесу. Вроде звучит хорошо, но можно чекнуть, а что рассказывали на конференции Teamlead Conf про это, а дальше спросить у потенциального спикера, а что он хочет добавить к тому, что уже было рассказано. Такой вопрос сразу переводит общение в плоскость конкретики и можно начинать говорить не просто за все хорошее против всего плохого, а по сути:) Кстати, вот список докладов, что я нашел на Teamlead Conf, которые неплохо укладываются в заданную в качестве примера тему - Культура как основа для масштабирования команды х2 каждый год - Мотивация, делегирование и автоматизация: рецепт создания суперкоманды - Пошаговый алгоритм создания самоорганизующейся команды - Как вовлечь команды разработки в бизнес компании - Развиваем доверие в командах - Как внедрять инженерные практики в сопротивляющихся командах - Методы мотивации сотрудников. Способы выращивания сотрудников с нуля - Научный руководитель vs бизнес-менеджер: как управлять R&D В общем, рекомендую канал конференции Teamlead Conf - там есть много интересных выступлений. Ну а на конференции для CTO и тем, кто им сочувствует, мы как программный комитет соберем бомбическую программу в этом году - нам хватает потенциальных спикеров и хороших заявок, но кажется уже не хватает для них мест, так как половина программы уже собрана. В итоге, дело осталось за вами - приходите на конференцию 6 июня. #Management #Leadership #Strategy #PlatformEngineering #Engineering #Software #Architecture

AchDays 2024 "Архитектура в Т-Банке: вчера, сегодня, завтра" - Александр Поломодов (Рубрика #Architecture) Наконец-то появилась запись моего выступления про наши подходы к проектированию и построению архитектуры систем. Я в компании уже 8 лет и видел как эти процессы эволюционировали во времени, а также знаю к чему мы пришли. Я выделил следующие четыре стадии и объяснил как и почему они сменяли друг друга во времени 1. COTS (commercial of the shelf) 2. Свой собственный софт 3. Platform Engineering 4. Большие мегапроекты и governance Напоследок я рассказал про подходы корпораций и технологических компаний к должностям/ролям архитекторов, а также поделился своим видением того, как нам дальше стоит развиваться. У меня есть расшифровка этого выступления в отдельной статье #Architecture #Software #Evolution #Management #SystemDesign #Engineering

Large-Scale Automated Refactoring Using ClangMR (Рубрика #Architecture) В последнее время я много изучаю, как Gen AI помогает в SDLC. Но иногда надо вернуться на шаг назад и понять, а как мы жили до генеративного интеллекта и что делали для повышения эффективности рефакторинга. И если копнуть туда, то видно, что эти старые и проверенные подходы активно используются в современности для обеспечения предсказуемых результатов комбинации стохастических и детерминированных подходов. Собственно, именно так я дошел до чтения короткого whitepaper 2013 года ребят из Google. Здесь они рассказывали про крупномасштабный рефакторинг своей кодовой базы на C++, например, со старой версии стандарта на более новую. Интересно, что их масштаб кодовой базы потребовал сразу учитывать возможность распараллеливания работы, для чего они использовали Map Reduce (именно это означает MR в конце названия ClangMR). Но теперь пора перейти к основным идеям из этой статьи Собственно, суть в том, что фреймворк ClangMR решает проблему технического долга в крупных C++ кодовых базах через семантически безопасный рефакторинг, который хорошо параллелится. Ключевыми моментами подхода является - Использование AST (abstract syntax tree), абстрактных синтаксических деревьев. В отличие от regex-инструментов, это позволяет гораздо точнее описывать изменения ,например, легко можно различить методы с одинаковыми именами в разных классах - Масштабируемость. Распределенная обработка через MapReduce сокращает время рефакторинга с месяцев до часов. - Повторяемость. Поддержка инкрементных изменений, когда авторы использовали инструмент итеративно для рефакторинга десятков тысяч файлов частями Сама реализация ClangMR основана на трех китах - Indexing (индексация): компиляция кодовой базы в AST с хранением в распределенной БД (e.g., Google's Bigtable). - Node matching (сопоставление узлов): Разработчики определяют AST-шаблоны (например, memberExpr(hasName("OldMethod")) и коллбэки для генерации правок. Интересно, что эта часть состоит из описания паттерна для матчинга частей дерева, а также callback для применения изменений (причем callback может решить, что изменений не требуется) - Sorce code refactorer (применение изменений): Локальное применение правок с разрешением конфликтов и автоформатированием через ClangFormat. Эта статья и подход, описанный в ней, привели к нескольким последствиям - Развитие Clang/LLVM: Компоненты вроде AST matcher API стали основой для Clang-Tidy и Clang refactoring engine - Смена практик рефакторинга: Популяризация AST-подходов, повлиявшая на инструменты вроде Coccinelle для ядра Linux. - Эволюция стандартной библиотеки: Ускоренное внедрение современных возможностей создало давление на вендоров компиляторов. В общем, статья была очень интересной для 2013 года. Но если говорить про микс этого подхода с Gen AI, то можно посмотреть доклад ребят из Uber 2024 года "This Year in Uber’s AI-Driven Developer Productivity Revolution", в котором они рассказывали среди прочего про миграцию с Java на Kotlin, где активно использовался микс AST matcher, а также Gen AI, который помогал генерировать правила трансформации:) Подробнее можно почитать в моем обзоре этого доклада (1 и 2) #Architecture #Leadership #Software #SoftwareDevelopment #AI #Engineering

ArchInsight в Лемана Тех - Панельная дискуссия про архитектуру Пару недель назад я ездил в Лемана Тех на их первый офлайн-митап архитекторов под названием ArchInsight, где поучаствовал в дискуссию про будущее архитекторов и архитектуры. Буквально сегодня появилась запись дискусии, а также пост ребят о самом мероприятии в их tg канале. Напомню, что мы за час успели обсудить следующие темы 1. Управление архитектурными изменениями в быстро меняющемся мире 2. Сложные кейсы архитектуры: что делать, когда все не так, как должно быть? 3. Архитектурный репозиторий: как сделать его инструментом для всех? 4. Архитектор как посредник между бизнесом и ИТ: как говорить на одном языке? 5. Эффективное управление архитектурными изменениями: от идеи до внедрения В дискуссии мы вспоминали много разных тем и конкретно книгу "The Software Architect Elevator" Gregor Hohpe, про которую я писал раньше. Суть была в том, что архитектору не стоит отрываться от земли и уходить в фантазии на N-том этаже своей башни, а стоит быть поблжие к земле и спускаться в машинный зал, где работают инженеры. Забавно, что после окончания конфы спикерам раздали подарки в сумке "Do it yourself", где были шуруповерты. В общем, я понял намек на то, что слова не должны расходиться с делами и обязательно воспользуюсь этим инструментом:) P.S. Спасибо организаторам за мероприятие - мне понравилось общение с другими участниками панельной дискуссии и всего митапа в целом, а также понравился подарок:) #Architecture #Software #Management #Leadership

Обложки для книг "Getting to Neutral" и "Главное правило мышления"

Getting to Neutral. How to conquer negativity and thrive in a chaotic world (Главное правило мышления) (Рубрика #Thinking) Эта интересная книга Тревора Моавада, ментора спортсменов мирового уровня, предлагает интересный подход к управлению своим ментальным состоянием и принятию качественных решений. В английском названии книги основная мысль вынесена в название "Getting to neutral" - автор предлагает концепцию нейтрального мышления, что расположено между позитивным мышлением и негативным. Позитивное мышление - это зобирование себя мыслями, что все так или иначе будет хорошо, а негативное мышление предполагает рассмотрение всего происходящего со стороны негативных факторов и рисков. Автор же предлагает сбалансированно и рационально смотреть на ситууацию и вызовы, которые нам требуется преодолеть. Забавно, что для этого понадобилось отдельное название - я практикую такой взгляд на мир уже больше 30 лет. Странно, что МИФ дал книге альтернативное название при переводе "Главное правило мышления" - это вводит читателей в заблуждение, так как автор ни разу не называет никакого правила мышления в книге, но приводит несколько концепций, которым рекомендует следовать - Neutral thinking (нейтральное мышление): этот майндсет помогает людям оставаться спокойными и объективными в условиях высокого давления. Вместо того, чтобы быть слишком оптимистичными или пессиместичными такое мышление позволяет оценить обстоятельства и доступные варианты и принять качественне решения - Power of words (сила слов): Тревор отмечает, что произнесенные слова оказывают на порядок больше влияния, чем мысли. Причем негативные слова оказывают больше влияния, чем нейтральные или позитивные. Например, Тревор называет заболевание, с которым он боролся во время написания книги, "словом на букву р" (и только один раз он говорит о том, что это рак, описывая первый раз, когда ему огласили диагноз) - Behavior over words (поведение важнее слов): действия значат больше, чем мысли или слова. Тревор отмечает важность фокусировки на желаемом поведении, которое приближает нас к желаемым целям. - Behavior over emotion (поведение важнее эмоций): успех связан с консистентным поведением больше, чем с флуктуациями эмоций. Нейтральное мышление фокусируется на действиях, что приближают к успеху, а не к следованию за эмоциональными пиками и спадами - Eliminating negativity (устранение негатива): автор рекомендует читателям идентифицировать и устранять влияние негатива на их жизни, включая чтение новостей и социальных медиа - Adversity tolerance (устойчивость к невзгодам): нейтральность помогает людям развивать устойчивость, отстраняясь от прошлых неудач или успехов и сосредотачиваясь на том, что можно контролировать в настоящий момент. - Value-based decision making (принятие решений на основе ценностей): Тревор поощряет выравнивать действия с ключевыми ценностями для поддержания ментального баланса даже в стрессовой ситуации. Тревор Моавад так и не смог победить рак, но он успел дописать эту книгу, в которой поделился своими секретами психологической подготовки, которые он практиковал с элитными спортсменами, военными и корпоративными лидерами. Он получал награды за его инновационные методы оптимизации производительности в условиях давления, но главное - это признание его вклада в успех его клиентов. Например, послесловие написал квотербек НФЛ Рассел Уилсон, с которым он сначала работал над мотивацией, а потом Рассел помогал Тревору в период его лечения. В общем, Тревор в своей книге предлагает прагматичную альтернативу традиционным парадигмам позитивного мышления. Приняв нейтральное мышление, люди могут лучше ориентироваться в сложностях жизни с ясностью и устойчивостью.. P.S. Интересно, что эти принципы отлично работают в больших компаниях - например, важно смотреть не на слова, а на действия топ-менеджмента, чтобы понимать какие ценности у компании на самом деле. #Management #Leadership #Psycho #SelfDevelopment #Brain #Thinking

Примеры того, как выглядят диаграммы из списка 1) Use case diagram (диаграмма вариантов использования) 2) Class diagram (диаграмма классов) 3) Sequence diagram (диаграмма последовательности) и Activity diagram (диаграмма деятельности) 4) Component diagram (диаграмма компонентов) 5) Deployment diagram (диаграмма развертывания) 6) State chart diagram (диаграмма конечного автомата) #Software #Architect #SystemDesign #SoftwareArchitecture #Processes

Полезные диаграммы из UML (Рубрика #Architecture) Сегодня утром я вспоминал книгу "Самоучитель UML", а также применимость языка для коммуникации и размышления об архитектурных решениях (1 и 2). Там я пообщел отдельно рассказать о диаграммах, которые я считаю полезными и вот время пришло. Ниже представлен список, который мне кажется полезным и в нынешних условиях, когда UML проиграл другим средствам моделирования, навроде C4 Model, про который хорошо рассказывает Саймон Браун, создатель концепта (смотрите мой разбор его доклада "The C4 Model - Misconceptions, Misuses & Mistakes" из 2024 года) 1) Use case diagram (диаграмма вариантов использования) - это стандартная диаграмма со сценариями, из которой обычно все помнят человечков и эллипсы, но забывают, что это только иллюстрации, а основа в тексте с happy path и exceptional flow. Также тут есть магия про декомпозицию и композицию сценариев. Сам тип диаграммы иногда используется до сих пор, но когда-то стало модно это описывать через user stories, потом customer journey map, потом jobs to be done сценарии и так далее 2) Class diagram (диаграмма классов) - по-факту, это наследие ER диаграммы (entity-relationship), но в объектно-ориентированном исполнении. Почти любая IDE может генерировать такие диаграммы по коду. Они понятные для инженеров и тоже иногда используются 3) Sequence diagram (диаграмма последовательности) - это популярная диаграмма для описания взаимодействия между разными частями системы. Она достаточно интуитивно читается, а также позволяет описать и проанализировать сложное взаимодействие. Хороший пример такого описания и анализа есть в недавные статье от Google "A Model-based, Quality Attribute-guided Architecture Re-Design Process at Google", про которую я рассказывал раньше. Кстати, есть похожая диаграмма, которая тоже про взаимодействия, но отображение чуток другое - это Activity diagram (диаграмма деятельности). Эти диаграммы отображают динамическое поведение системы 4) Component diagram (диаграмма компонентов) - это диаграмма позволяет отобразить компоненты с их интерфейсами, а также как они зависят друг от друга. Эта диаграмма отображает статическое состояние системы. 5) Deployment diagram (диаграмма развертывания) - этот вид диаграмм позволял связать логическое описание системы с его физическим воплощением. То есть мы понимали тут как наши компоненты будут физически воплощены в процессах, внутри серверов, связаны сетью и так далее. 6) State chart diagram (диаграмма конечного автомата) - этот тип диаграмм позволяет описывать конечные автоматы. У него есть состояния и переходы между ними, доступные действия и так далее. В этой диаграмме мы можем описать, например, логику работы чайника. Его состояния могут быть такими: «выключен», «нагревается» и «кипит». Когда мы нажимаем кнопку, он выполняет действие — переходит из состояния «выключен» в состояние «нагревается». А когда вода в чайнике закипает, он автоматически меняется на состояние «кипит». Каждое из этих действий, например, нажатие кнопки или закипание воды, заставляет чайник переходить из одного состояния в другое, по заранее заданным нами правилам. В общем, эти виды диаграмм отлично помогли мне структурировать понимание того, как можно декомпозировать систему на части и размышлять о них отдельно - это аналитическая часть проектирования. И только потомя научился не просто разбирать системы на произвольные части, но и собирать что-то осмысленное обратно. А постепенно мне стало ясно, как размышлять про эмерджентные свойства системы, которые удовлетворяют как функциональным, так и нефункциональным требованиям к системе. Но это уже история для другого поста. #Software #Architect #SystemDesign #SoftwareArchitecture #Processes

Опыт "горячий лед" (Рубрика #Kids) Сегодня утром с детишками делали простой опыт с горячим льдом, что замерзает при комнатной температуре. У нас есть целая коробка с разными опытами, но конкретно этот опыт выбрал Кирилл, наш младший сын четырех лет, которому нравится синий цвет, а коробка с опытом как раз была синей. Сам опыт оказался крайне простым: - Надо было сделать раствор ацетата натрия в горячей воде - Дальше надо было поставить его остужаться в холодильник - Через некоторое время раствор надо достать из холодильника и начать опыт - Первый эксперимент связан с добавлением кристаллов ацетата натрия в перенасыщенный раствор, что приводит к ускоренному превращению раствора в стакане в лед - Дальше этот раствор опять можно нагреть, а потом охладить и попробовать налить раствор в чашу Петри, где размещена деревянная снежинка. В этом случае процесс замерзания выглядит чуток по-дргоому - Также в опыте есть шприц, с помощью которого можно сделать что-то типа замерзающей горки (у нас эта часть получилась так себе) В общем, четырехлетнему Кириллу опыты понравились, а вот девятилетнему Максиму быстро стало скучно - он только поинтересовался тем, что получилось, но после половины эксперимента перестал в нем участвовать. P.S. Интересно, что подобный состав ацетата натрия используется в солевых грелках, которые раньше использовали для обогрева ног зимой:) #PopularScience #Kids #Parents #Physics

Обложка книги "Самоучитель UML, 2 издание". Отмечу, что автор очень тонко уловил будущее языка UML, который при переходе от версии 1* к 2* сместил фокус с людей на машины, так как у мейнтейнеров языка была идея фикс писать описание на UML, а дальше из этого генерировать код. Это привело к падению популярности языка UML, так как люди почти перестали его использовать для общения между собой, а вот использовать его для указания машинам как генерировать код на языках программирования так и не начали:)

Самоучитель UML, 2 издание (Рубрика #Architecture) Иногда я все-таки очищаю свои книжные полки от старых книг, обычно этот момент наступает, когда у меня не остается места для новых книг. Именно с такой целью я снял книгу Александра Леоненкова 2006 года издания, в которой он рассказывал про UML 1.5. Эта книга была пересказом стандарта на русский язык в вольной форме. С тех пор стандарт убежал до версии 2.5.1, которая вышла в декабре 2017 года, но проблема с языком гораздо глубже ... В этом посте я немного расскажу и про книгу и про свое отношение к языку UML. Около 20 лет назад я только начинал свою профессиональную карьеру как программист. Я учился на третьем курсе Физтеха и уже начал получать какие-то деньги за написание кода. Я писал код и до этого, он был так себе, а еще я делал это бесплатно. Но когда я понял, что это теперь моя профессия, то я решил подойти к делу серьезно и подучить теорию (это мой стандартный подход к изучению чего-то нового). Забавно, что на свой первый личный компьютер я заработал на стройке Nix, где работал на летних каникулах первого курса. Личный компьютер позволил мне проще погружаться в мир разработки, а опыт работы на стройке помог понять, что лучше работать головой, а не руками. Но вернемся к изучению теории. В университете мы учили C++ и ассемблер (признаюсь, ассемблер прошел мимо меня). На работе надо было писать на html, js, css, php, а еще знать немного linux:) Ну а для себя я решил разобраться с архитектурой и проектированием систем. Так я стал счастливым обладателем нескольких книг по UML, а также книги "Совершенный код" Макконнела, про которую я уже писал. Одной из книжек по UML был именно этот самоучитель Леоненкова, который был хоть и нудноват, но зато неплохо и на русском рассказывал про унифицированный язык моделирования UML. Книга состояла из трех частей: - Основы UML - Диаграммы концептуального, логического и физического моделирования - Анализ и проектирование с использованием UML и IBM Rational Rose 2002 В основах UML автор рассказывал про процедурное программирование, потом объектно-ориентированное программирование, а потом переходил к объектно-ориентированному анализу и проектированию. Причем все это сопровождалось историческим анализом и объяснением как разные методологии разных людей потом оказались сшиты в унифицированный язык моделирования. Про это рекомендую посмотрть подкаст с Гради Бучем, создателем языка, про который я рассказывал раньше. Потом автор погружался в рассказ о моделях реального мира, метамоделях из UML, а после переходил к основным типам диаграмм, про которые я расскажу отдельно в следующем посте. После диаграмм автор рассказывает про использование IBM Rational Rose 2002, которая как раз является делом рук Гради Буча и его компании Rational, которую когда-то выкупил IBM. Гради про это интересно рассказывает в упомянутом выше подкасте. В общем, эта книга когда-то помогла мне структурировать понимание того, как можно декомпозировать систему на части и размышлять о них отдельно - это аналитическая часть проектирования. И только потомя научился не просто разбирать системы на произвольные части, но и собирать что-то осмысленное обратно. А постепенно мне стало ясно, как размышлять про эмерджентные свойства системы, которые удовлетворяют как функциональным, так и нефункциональным требованиям к системе. Но это уже история для другого поста. P.S. В текущий момент эта книга просто раритет. Читать ее никакого смысла уже нет:) Но вот изучить виды моделей из UML может быть полезно, поэтому дальше я расскажу про них #DistributedSystems #Architecture #Software #Engineering #SystemDesign

Баскетбол: ЦСКА - Уникс (Рубрика #LifeStorie) Сегодня ходили со средним сыном на очередной (уже второй) матч баскетбольного ЦСКА. В этот раз в опонентах был Уникс, который шел на втором месте, когда мы покупали билеты, но к старту матча он опустился на третье место. Но в прошлый раз мы видели как ЦСКА проиграл идущему на четвертом месте Локомотиву, поэтому уверенности в победе не было. Но в этот раз ЦСКА не стал играть в кошки-мышки, а сходу захватил преимущество очков в 10 и так его стабильно и держал до финальной сирены. Иногда, казалось, что Уникс догоняет, но потом игроки ЦСКА переставали мазать броски и разрыв по очкам возвращался к комфортным значениям. Сыну игра и победа понравились, поэтому мы решили продолжить традицию и купить сразу билеты на следующий матч. Для нас это будет 12 марта, когда к ЦСКА приедет в гости Енисей. #Sport #ForKids

Какие каналы я читаю для получения релевантной информации (Рубрика #Stories) Я уже рассказывал откуда я беру интересные научные статьи, но это специфический вид контента:) А сегодня я хотел поделиться тем, как я получаю более приземленные знания по интересующим себя темам. Для этого я собрал список таких каналов #Economics - @hoolinomics - экономические обзоры с юмором и глубиной, нравится подача автора и школа мысли относительно разбора экономических ситуаций #AI - @ai_newz - новости из мира AI, которые подаются с пылу с жару, автор канала сам прикладывает руку к SOTA моделям Meta, а также хорошо знает происходящее в индустрии - @gonzo_ML - канал с разбором ML whitepapers. Я люблю сам читать whitepapers, но они в основном про software engineering. А вот про ML я знакомлюсь с научными новостями через этот канал. - @seeallochnaya - хороший канал с AI/ML тематикой, где выходят глубокие и интересные посты с разборами технологий и новинок - @theworldisnoteasy - крутой канал с обсуждением будущего и футуристичными статьями, очень хорошо расширяет кругозор #Engineering - @rockyourdata - много информации про data engineering за рубежом, про Snowflake, Databricks и другие cloud native решения, включая open source, что позволяют увидеть как происходит шифт от канонического DWH в сторону Lake House и Data Mesh - @it_arch - хороший канал по архитектуре Максима Смирнова, которого я знаю как компетентного архитектора. Максим постит индустриальные новости вокруг enterprise, solution и software architecture - @databaseinternalschat - чат про базы данных - в этом канале есть разработчики популярных баз данных и с ними можно обсудить сложные вопросы работы планировщика, транзакций, оптимизаций и т.д. - @backend_megdu_skobkah - в чате много ребят, что исполняют роль техлидов/архитекторов в своих компаниях, поэтому можно обсудить сложные вопросы #T-Tech - @kod_zheltyi - технические новинки от Т-Технологий - хороший источник новостей из мира российского бигтеха (а конкретнее Т-Технологий) - @tbank_education - канал про образование от Т Технологий Изначально список был подлиннее, но потом я понял, что часть каналов у меня висит и я их не читаю, а значит и рекомендовать их не стоит. В общем, остались только те каналы, что я действительно считаю полезными для себя. #AI #Software #Engineering #Economics

Research Insights Made Simple #9 "What Do Developers Want From AI?" (Рубрика #AI) В этой серии подкаста речь идет про whitepaper "What Do Developers Want From AI?", про который я уже писал раньше. Для его обсуждения я позвал в гости Николая Бушкова из RnD центра Т-Банка. Николай занимается исследованиями инженерной продуктивности и глубоко погружен в темы того, как AI может улучшать инженерные процессы. Кстати, здесь можно подробнее почитать про RnD центр Т-Банка и о направлении инженерной продуктивности. Мы обсудили следующие темы 1. Введение в тему: AI и разработчики 2. Метафоры технологических изменений (параллели с электрификацией) 3. Три уровня AI-улучшений (параллели с автомобильной промышленностью) 4. Подходы к измерению продуктивности (комбинация опросов и логов) 5. Code review и роль AI (примеры из практики) 6. Проблемы документации и технического долга 7. Платформенный подход к инструментам 8. Агентные системы и метауровень 9. Исследования продуктивности и сотрудничество (примеры из Google и Т-Банка) Также мы упоминали и другие научные статьи, которые хорошо ложились в тему дискуссии 1) "Measuring developer goals" от Google - мы его обсуждали в предыдущей серии Research Insights вместе с Сашей Кусургашевым, а также у меня было краткое саммари по нему 2) "Resolving code review comments with ML" от Google - пока я про нее не писал, но скоро будет обзор 3) "BitsAI-CR: automated code review via LLM in practice" от ByteDance, по ней тоже будет обзор 4) "Defining, Measuring, and Technical Debt" от Google - мы его обсуждали в одной из серий Research Insights вместе с Димой Гаевским, а также у меня было краткое саммари этой статьи 5) "Build Latency, Predictability, and Developer Productivity" от Google - у меня было краткое саммари этой статьи Эпизоды доступны на Youtube, VK Video, Podster.fm, Ya Music. #Management #Leadership #Software #SoftwareDevelopment #Metrics #Devops #Processes #AI #ML #DevEx

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