Телеграм канал «emacsway-log: Software Design, Clean Architecture, DDD, Microservice Architecture, Distributed Systems, XP, Agile, etc.»

Запись ArchDays Meet Up доступна для просмотра 5 июня Сергей Баранов рассказывал о том, как принимать архитектурные решения быстрее, без потери качества и бесконечных обсуждений. В записи: ▪️ разбор реального решения ▪️ ADR, Trade-off Analysis и шаблоны для оценки вариантов ▪️ фасилитация как инструмент согласования решений 📌Кстати, если вам близка эта тема — загляните в Школу Архитектора ПО от Сергея. Это тренинг с глубокой проработкой архитектурных подходов, включая AI и автоматизацию. Смотрите видео, делитесь мнением и следите за анонсами в канале, чтобы не пропустить следующие встречи. 📱 ВКонтакте 📱 YouTube

#дайджест постов в канале @aidea4work за 2 месяца ↗️ Внедрение ИИ в компаниях 🔵Прирост качества работы при добавлении ИИ в команду и другие инсайты из исследования P&G 🔵Выбор и внедрение транскрибатора 🔵Локальные LLM для размещения внутри контура 🔵Как внедрять ИИ так, чтобы люди им пользовались 👑AI-агенты 🔵MCP для быстрой интеграции инструментов в агентах 🔵Deep Research: зачем нужен + сравнение спец. агентов 🔵Кому нужны универсальные агенты ✏️ Картинки для презентаций 🔵Обзор генераторов с точки зрения текста на картинках 🔵Ideogram 3.0 и GPT-4o с точки зрения следования промпту ✔️Инструменты личной эффективности 🔵Бесплатные безлимитные альтернативы ChatGPT 🔵Ассистент для генерации личного ИИ-ментора 🔵Промпты для ИИ-ассистентов: как не писать их самим Пишите в комментариях темы, которых вам здесь не хватает ➡️

Физические Agile-доски до сих пор активно используются в крупных IT-компаниях, даже в таких, как Thoughtworks. Это никакой не исторический рудимент. Они используются даже для распределенных команд - в удаленном офисе на самом видном месте устанавливается большой монитор, на который проецируется изображение доски с главного офиса. У меня в офисе такая доска была. Она состоит из поролоновых кубиков, количество которых пропорционально трудомощности команды разработки. Каждая сторя занимает площадь на столько кубиков, сколько составляет её трудоемкость. В Jira даже есть опция распечатать стори. Если в спринт нужно вставить другую сторю, то на доске сперва удаляется сторя эквивалентной площади. Основное принцип - доска всегда должна быть перед глазами, на самом видном месте. Её функции больше психологические - она создает контекст погружения в обстановку. И помогает в борьбе с Первым Законом Паркинсона, но это уже отдельная тема для обсуждения, - для эффективного её решения нужны две доски на два спринта. Так вот, к чему это я. Некоторые мои в т.ч. широко известные коллеги используют бумажный ежедневник, чем неоднократно вводили меня в замешательство. Я считал это рудиментарными привычками. Но недавно у меня появилась хорошая перьевая ручка и мне захотелось купить себе бумажный ежедневник. После непродолжительных поисков мой выбор пал на блокнот fineplan формата A6 на кольцах из натуральной кожи коньячного цвета с тиснением под крокодила. Он у меня всегда раскрыт возле монитора и выполняет те же функции, что и физическая Agile-доска, - постоянно визуализирует образное представление моего личного распорядка перед глазами. Эстетичность блокнота и ручки вызывает желание ими пользоваться. За несколько дней заметил существенное улучшение моей личной сконцентрированности и организованности. И понял, что это никакой не исторический рудимент. Теперь я понимаю своих коллег с бумажными ежедневниками. Хотя от электронных ежедневников я не отказался, и продолжаю пользоваться Open Source приложениями: https://github.com/orgzly-revived/orgzly-android-revived (как заядлый емаксоид в прошлом) и https://github.com/tasks/tasks Оба приложения доступны на F-Droid.

Только что обнаружил, что Greg Young тоже опубликовал 16 ноября пост на шахматную тематику. [UPDATE]: И, кажется, он это делает систематически. Видимо, не я один заинтересовался шахматами на почве ИТ-архитектуры.

Может кому-нибудь пригодится для реализации критериев выборки (фильтрации) Public-API по Style Guide AIP-160 by Google: - https://github.com/einride/aip-go - https://github.com/aip-dev/google.aip.dev/issues/684 - https://github.com/aip-dev/google.aip.dev/issues/738 - https://google.aip.dev/160 - https://github.com/google/cel-spec Другие варианты смотрите здесь: - https://dckms.github.io/system-architecture/emacsway/it/self-education/self-education-for-software-engineer.html#api-design

О дихотомии функции и конструкции на примере шахмат. В шахматах существует такой тактический прием, как связывание: https://chessrussian.ru/materialy/beginners/svyazka-primenenie-svyazki/ Он означает, что некая фигура (т.е. конструкция, кстати, в шахматах так и говорят - материал), называемая связываемой, принимает на себя функцию по защите иной, прикрываемой, фигуры. И до тех пор, пока свявающая (атакующая) фигура (потребитель) не изменит свой способ взаимодействия с конструкцией (провайдером), связанная фигура не может освободиться от своей функции (изменить своей дислокации) без ущерба для конструкции. Обратите внимание, что в качестве функции защиты может быть использована и иная конструкция, т.е. фигура. А сама конструкция, т.е. фигура, может быть использована и в качестве иной функции, например, атаки. Это и есть дихотомия функции и конструкции. Связанную фигуру можно так же рассматривать в качестве слоя трансляции - чтобы защитить свою доменную модель (самую дорогую часть ПО), мы создаем слой трансляции под названием Open Host Service: this approach of inserting a translation layer for each external system avoids corruption of the models with a minimum of cost http://ddd.fed.wiki.org/view/open-host-service Т.е. чтобы предотвратить разрушение модели/конструкции. Все как и в шахматном связывании. Этот тактический прием открывает также понимание еще и такого явления, как Coupling. Мы не можем изменить дислокацию фигуры (интерфейса), потому что она связана. См. также.

FINDING SOFTWARE BOUNDARIES FOR FAST FLOW Team Topologies and Domain-Driven Design