Привет!
Что-то последняя большая новость никак не дозреет, поэтому пока расскажу о двух созревших.
Новость №1
В Trainer Advisor появился второй живой пользователь.
Из хорошего для ЭП это значит, что публичный демо проект стал решать больше реальных проблем реальных людей и, как следствие, стал чуть более приближенным к реальной жизни и чуть более показательным.
А из плохого - фича-реквестов и найденных багов стало в два раза больше, поэтому он стал в два раза активнее требовать моего времени, которое я могу добыть только за счёт сокращения работы над каналом в частности и ЭП в целом.
Тут хочу напомнить, что ко мне можно попасть на менторинг заеду работу над TA (или так: в TA можно устроиться на работу за еду опыт). С вас реализация фич в ТА - с меня аккуратное ревью и обучение разработке в целом. И этим вы можете помочь не только себе и мне, но и всему сообществу, дав мне больше времени для работы над ЭП.
Там по началу надо будет починить пару мелких багов/фич (например этот и эту) чтобы познакомиться с проектом и процессами, а потом в бэклоге у меня пачка на мой взгляд интересных и познавательных задач: интеграция с Goggle Calendar (где надо будет ещё и с OAuth поупражняться), реализация веб-пушей (тут сначала надо будет фронт допилить, но это может я сам успею сделать), реализация отправки сообщений клиентам в телегу (через бизнес-акки или бота).
Но сразу хочу предупредить, что ревью будет дотошное и каждый МР скорее всего будет проходить 2-3+ итерации ревью.
И что делать надо будет не только бэк, но и фронт. Как минимум вёрстку на Twitter Bootstrap (с чем неплохо чат-боты справляются) и, иногда UI-логику на AlpineJS типа такой: 1, 2, 3, 4.
В целом сейчас разбивка строк кода по типам следующая: Kotlin - 81%, html - 14%, css - 3%, js - 2%
Но фронт я ревьювлю уже не так дотошно. Думаю, если вы нагенеряете код гопатычем и он будет работать - я не замечу:)
Новость №2
Я официально стартую второй подход к написанию книги. На этот раз с неофициальной пока что поддержкой проектного менеджера ИД Питер.
Пока что осилил накидать только обновлённый план. Относитесь к нему как к архитектуре проекта на 2-3 человеко-года, сделанной джуном - результат в общих чертах будет напоминать исходную архитектуру, но детали, скорее всего, будут существенно отличаться.
И быстрого прогресса по книге не ожидайте - она будет бороться за мой ограниченный временной бюджет ещё и с ТА, блогом (где у меня план таки дописать пост про SQL в ближайшие пару недель, а потом таки написать ретро #project_r) и двумя детьми.
Кроме того, я под книгу планирую написать отдельную версию ТА, чтобы:
1. коммиты были привязаны к главам
2. API сделать в виде более распространённого JSON over HTTP, а не Тру REST API
3. в целом убрать исторические наслоения и быстрые хаки в коде, чтобы код был образцово-показательным, а не реальным в части компромиссов.
В общем, интуитивно, с учётом всех вводных мне кажется, что писать книгу я буду ещё года 2-3.
Так что стей тюнед, будет интересно:)
А ну и с третьей новостью - там тоже будет интересно (я мастер интриги 😂) - надеюсь в начале июня она таки дозреет:)
#trainer_advisor@ergonomic_code #ergo_book@ergonomic_code
Что-то последняя большая новость никак не дозреет, поэтому пока расскажу о двух созревших.
Новость №1
В Trainer Advisor появился второй живой пользователь.
Из хорошего для ЭП это значит, что публичный демо проект стал решать больше реальных проблем реальных людей и, как следствие, стал чуть более приближенным к реальной жизни и чуть более показательным.
А из плохого - фича-реквестов и найденных багов стало в два раза больше, поэтому он стал в два раза активнее требовать моего времени, которое я могу добыть только за счёт сокращения работы над каналом в частности и ЭП в целом.
Тут хочу напомнить, что ко мне можно попасть на менторинг за
Там по началу надо будет починить пару мелких багов/фич (например этот и эту) чтобы познакомиться с проектом и процессами, а потом в бэклоге у меня пачка на мой взгляд интересных и познавательных задач: интеграция с Goggle Calendar (где надо будет ещё и с OAuth поупражняться), реализация веб-пушей (тут сначала надо будет фронт допилить, но это может я сам успею сделать), реализация отправки сообщений клиентам в телегу (через бизнес-акки или бота).
Но сразу хочу предупредить, что ревью будет дотошное и каждый МР скорее всего будет проходить 2-3+ итерации ревью.
И что делать надо будет не только бэк, но и фронт. Как минимум вёрстку на Twitter Bootstrap (с чем неплохо чат-боты справляются) и, иногда UI-логику на AlpineJS типа такой: 1, 2, 3, 4.
В целом сейчас разбивка строк кода по типам следующая: Kotlin - 81%, html - 14%, css - 3%, js - 2%
Но фронт я ревьювлю уже не так дотошно. Думаю, если вы нагенеряете код гопатычем и он будет работать - я не замечу:)
Новость №2
Я официально стартую второй подход к написанию книги. На этот раз с неофициальной пока что поддержкой проектного менеджера ИД Питер.
Пока что осилил накидать только обновлённый план. Относитесь к нему как к архитектуре проекта на 2-3 человеко-года, сделанной джуном - результат в общих чертах будет напоминать исходную архитектуру, но детали, скорее всего, будут существенно отличаться.
И быстрого прогресса по книге не ожидайте - она будет бороться за мой ограниченный временной бюджет ещё и с ТА, блогом (где у меня план таки дописать пост про SQL в ближайшие пару недель, а потом таки написать ретро #project_r) и двумя детьми.
Кроме того, я под книгу планирую написать отдельную версию ТА, чтобы:
1. коммиты были привязаны к главам
2. API сделать в виде более распространённого JSON over HTTP, а не Тру REST API
3. в целом убрать исторические наслоения и быстрые хаки в коде, чтобы код был образцово-показательным, а не реальным в части компромиссов.
В общем, интуитивно, с учётом всех вводных мне кажется, что писать книгу я буду ещё года 2-3.
Так что стей тюнед, будет интересно:)
А ну и с третьей новостью - там тоже будет интересно (я мастер интриги 😂) - надеюсь в начале июня она таки дозреет:)
#trainer_advisor@ergonomic_code #ergo_book@ergonomic_code
Алексей Жидков
Книга: первая версия плана - Алексей Жидков
https://azhidkov.pro/
👍17🔥3❤2
Кое-как с третьей попытки вымучил раздел "Зачем?" главы "Эргономичный подход".
Купили бы книгу с такой постановкой проблемы?:)
———
2.1. Зачем?
Так вышло, что все 20 лет своей карьеры я занимался разработкой "простых" CRUD-приложений.
Они всю свою жизнь (в некоторых случаях - десятилетнюю) хранили данные в реляционной СУБД одного вендора (один раз требовалась поддержка двух вендоров - PostgreSQL и Oracle). Они всю свою жизнь принимали запросы по HTTP и возвращали ответы в формате JSON.
Церемонии Чистой Архитектуры в таких приложениях только мешали.
И в них не было настолько сложной бизнес-логики, чтобы бизнес видел ценность в проведении сессий эвентштроминга с участием экспертов предметной области и трате времени на создание вездесущего языка (Ubiquitous language) и карты контекстов. И они не обслуживали разные отделы бизнеса, с собственными процессами, правилами и языком.
Идея применения DDD в таких приложения умирала на этапе "продажи" бизнесу и команде.
Но назвать эти приложения простыми у меня язык не поворачивается.
Потому что они хранили информацию о десятках и сотнях типов сущностей. У которых были десятки, а иногда и сотни полей.
А "простые" CREATE/UPDATE/DELETE операции затрагивали десятки таблиц, делали пару-тройку походов во внешние сервисы по HTTP, публиковали по сообщению в пару разных брокеров очередей и отправляли емейл "на сладкое".
Сложность этих систем заключалась не в бизнес-правилах и инвариантах, на которых фокусируются Чистая Архитектура и DDD, а в модели данных и взаимодействиях с внешними системами.
И разработчики таких систем оставались без руководства, как проектировать модель данных и эффекты (поведение). И в отсутствии каких-либо ограничений, разработчики шли по пути наименьшего сопротивления и порождали такие модели данных:
Картинка №2
и такие графы вызовов методов:
Картинка №1
Диаграммы выше - это диаграммы построенные по коду реального проекта, с которым мне довелось работать. И я вам скажу, что работать с этим кодом было удовольствием для редкостных гурманов.
На самом деле именно этот проект послужил для меня толчком к поиску способа писать код по другому, который в итоге привёл к созданию Эргономичного подхода и написанию этой книги.
Я создал Эргономичный подход для того, чтобы я сам и другие разработчики "простых" CRUD-приложений могли проектировать сложные модели данных без экспертов предметной области и организовывать код поведения так, чтобы эффекты его работы были очевидными, а задачи по его оптимизации, исправлению и рефакторингу не превращались в детективные триллеры.
#ergo_book@ergonomic_code
Купили бы книгу с такой постановкой проблемы?:)
———
2.1. Зачем?
Так вышло, что все 20 лет своей карьеры я занимался разработкой "простых" CRUD-приложений.
Они всю свою жизнь (в некоторых случаях - десятилетнюю) хранили данные в реляционной СУБД одного вендора (один раз требовалась поддержка двух вендоров - PostgreSQL и Oracle). Они всю свою жизнь принимали запросы по HTTP и возвращали ответы в формате JSON.
Церемонии Чистой Архитектуры в таких приложениях только мешали.
И в них не было настолько сложной бизнес-логики, чтобы бизнес видел ценность в проведении сессий эвентштроминга с участием экспертов предметной области и трате времени на создание вездесущего языка (Ubiquitous language) и карты контекстов. И они не обслуживали разные отделы бизнеса, с собственными процессами, правилами и языком.
Идея применения DDD в таких приложения умирала на этапе "продажи" бизнесу и команде.
Но назвать эти приложения простыми у меня язык не поворачивается.
Потому что они хранили информацию о десятках и сотнях типов сущностей. У которых были десятки, а иногда и сотни полей.
А "простые" CREATE/UPDATE/DELETE операции затрагивали десятки таблиц, делали пару-тройку походов во внешние сервисы по HTTP, публиковали по сообщению в пару разных брокеров очередей и отправляли емейл "на сладкое".
Сложность этих систем заключалась не в бизнес-правилах и инвариантах, на которых фокусируются Чистая Архитектура и DDD, а в модели данных и взаимодействиях с внешними системами.
И разработчики таких систем оставались без руководства, как проектировать модель данных и эффекты (поведение). И в отсутствии каких-либо ограничений, разработчики шли по пути наименьшего сопротивления и порождали такие модели данных:
Картинка №2
и такие графы вызовов методов:
Картинка №1
Диаграммы выше - это диаграммы построенные по коду реального проекта, с которым мне довелось работать. И я вам скажу, что работать с этим кодом было удовольствием для редкостных гурманов.
На самом деле именно этот проект послужил для меня толчком к поиску способа писать код по другому, который в итоге привёл к созданию Эргономичного подхода и написанию этой книги.
Я создал Эргономичный подход для того, чтобы я сам и другие разработчики "простых" CRUD-приложений могли проектировать сложные модели данных без экспертов предметной области и организовывать код поведения так, чтобы эффекты его работы были очевидными, а задачи по его оптимизации, исправлению и рефакторингу не превращались в детективные триллеры.
#ergo_book@ergonomic_code
👍16❤10❤🔥2
Привет!
Итоги 2025 года - лучше поздно, чем никогда, правда же?:)
Итог №1 - Больше реального кода
Больше всего сил в 2025 году (192 коммита, против 43 и 36 в вики и блог) я вложил в Trainer Advisor - публичный пример проекта, написанного по ЭП.
За 2025 год я в нём сделал 34 различных фичи и фикса, самые крупные и трудозатратные из которых были:
1. Интеграция с Гугл Календарями (PR, пост)
2. Пуш-уведомления (PR, пост)
В результате, TA дорос до 20К строк исходников и 20 таблиц.
Помимо этого в #project_e мы за прошлый год сделали пару новых сервисов и допилили новых фич в ядро на 2.2, 4.1 и 6К строк соответственно.
В итоге суммарное количество промышленного кода, написанного по ЭП, перевалило уже за 121 тысячу строк Kotlin и Java-кода.
Итог №2 - Эргономичная архитектура
Также значительным на мой взгляд итогом 2025 года стало появление Эргономичной архитектуры и её представление с помощью трёх проекций. Описание Эргономичной архитектуры всё ещё в статусе черновика и публичных обновлений не было давно, но за кулисами я весь четвёртый квартал 25-ого года работал над проекцией модели данных. С четвёртой попытки у меня вышел текст, который мне нравится, но ещё надо убрать исторические наслоения из ТА, чтобы он стал хорошей иллюстрацией и собственно добавить эту иллюстрацию.
Итог №3 - Исследование характеристик поддерживаемых кодовых баз
Затем, довольно много времени и сил я потратил на проведение исследования характеристик поддерживаемых кодовых баз backend-приложений. К сожалению, собрать достаточное количество анкет не вышло (хотя анкета всё ещё открыта и вы всё ещё можете её заполнить:) ), поэтому все эти усилия по большому счёту пошли прахом. Тем не менее, у меня появилось слабое, но подтверждение, что ЭП как минимум не вредит поддерживаемости:)
Итог №4 - Большие посты
На поприще блоггинга я смог написать два больших поста:
1. Вам не нужна Чистая архитектура. Скорее всего
2. Учимся читать SQL SELECT
А всего в блог и вики я добавил (немного пугающие) 6660 строк. Это не считая незакоммитанных черновиков:)
Итог №5 - Новые паттерны
Ещё в 2025 году у меня оформилось несколько паттернов, немного сокращающих трудозатраты на разработку (за счёт того, что не надо велосипед придумывать):
1. Переход на UUID v7 в качестве идов сущностей
2. Пресеты сложных фикстур
3. [Wire]MockServers
4. и ещё пачка более мелких см. историю коммитов
Итог №6 - +1см в направлении книги
Прошлый год начался с того, что мне написал проектный менеджер ИД Питер с предложением издать книгу. На этой волне я немного полежал в направлении книги, но переключился на исследование. Знаете как расшифровывается СДВГ? "Синдром дефицита Вау! Голубь!".
И вот в конце прошлого года ко мне пришёл представитель уже второго крупного издательства с тем же предложением. Мы с ним довольно серьёзно продвинулись в планировании книги и ред. коллегия была готова заключить договор на издание книги, но с условием, что авторский текст я сдам до конца 26 года. А я по ряду причин не готов на это подписываться, поэтому и в этот раз не срослось.
Но, держим пальчики, процесс потихоньку сходится, когда-нибудь книга обязательно будет:)
#ergo_approach@ergonomic_code #traineradvisor@ergonomic_code #ergo_book@ergonomic_code
Итоги 2025 года - лучше поздно, чем никогда, правда же?:)
Итог №1 - Больше реального кода
Больше всего сил в 2025 году (192 коммита, против 43 и 36 в вики и блог) я вложил в Trainer Advisor - публичный пример проекта, написанного по ЭП.
За 2025 год я в нём сделал 34 различных фичи и фикса, самые крупные и трудозатратные из которых были:
1. Интеграция с Гугл Календарями (PR, пост)
2. Пуш-уведомления (PR, пост)
В результате, TA дорос до 20К строк исходников и 20 таблиц.
Помимо этого в #project_e мы за прошлый год сделали пару новых сервисов и допилили новых фич в ядро на 2.2, 4.1 и 6К строк соответственно.
В итоге суммарное количество промышленного кода, написанного по ЭП, перевалило уже за 121 тысячу строк Kotlin и Java-кода.
Итог №2 - Эргономичная архитектура
Также значительным на мой взгляд итогом 2025 года стало появление Эргономичной архитектуры и её представление с помощью трёх проекций. Описание Эргономичной архитектуры всё ещё в статусе черновика и публичных обновлений не было давно, но за кулисами я весь четвёртый квартал 25-ого года работал над проекцией модели данных. С четвёртой попытки у меня вышел текст, который мне нравится, но ещё надо убрать исторические наслоения из ТА, чтобы он стал хорошей иллюстрацией и собственно добавить эту иллюстрацию.
Итог №3 - Исследование характеристик поддерживаемых кодовых баз
Затем, довольно много времени и сил я потратил на проведение исследования характеристик поддерживаемых кодовых баз backend-приложений. К сожалению, собрать достаточное количество анкет не вышло (хотя анкета всё ещё открыта и вы всё ещё можете её заполнить:) ), поэтому все эти усилия по большому счёту пошли прахом. Тем не менее, у меня появилось слабое, но подтверждение, что ЭП как минимум не вредит поддерживаемости:)
Итог №4 - Большие посты
На поприще блоггинга я смог написать два больших поста:
1. Вам не нужна Чистая архитектура. Скорее всего
2. Учимся читать SQL SELECT
А всего в блог и вики я добавил (немного пугающие) 6660 строк. Это не считая незакоммитанных черновиков:)
Итог №5 - Новые паттерны
Ещё в 2025 году у меня оформилось несколько паттернов, немного сокращающих трудозатраты на разработку (за счёт того, что не надо велосипед придумывать):
1. Переход на UUID v7 в качестве идов сущностей
2. Пресеты сложных фикстур
3. [Wire]MockServers
4. и ещё пачка более мелких см. историю коммитов
Итог №6 - +1см в направлении книги
Прошлый год начался с того, что мне написал проектный менеджер ИД Питер с предложением издать книгу. На этой волне я немного полежал в направлении книги, но переключился на исследование. Знаете как расшифровывается СДВГ? "Синдром дефицита Вау! Голубь!".
И вот в конце прошлого года ко мне пришёл представитель уже второго крупного издательства с тем же предложением. Мы с ним довольно серьёзно продвинулись в планировании книги и ред. коллегия была готова заключить договор на издание книги, но с условием, что авторский текст я сдам до конца 26 года. А я по ряду причин не готов на это подписываться, поэтому и в этот раз не срослось.
Но, держим пальчики, процесс потихоньку сходится, когда-нибудь книга обязательно будет:)
#ergo_approach@ergonomic_code #traineradvisor@ergonomic_code #ergo_book@ergonomic_code
GitHub
GitHub - ergonomic-code/Trainer-Advisor: Информационная система йогатерапевта и демонстрационный проект Эргономичного подхода
Информационная система йогатерапевта и демонстрационный проект Эргономичного подхода - ergonomic-code/Trainer-Advisor
❤8👍7🔥3
Чего ждать в 2026 году
Я даже не из тех людей, которые в начале года составляют планы на год, не говоря уж о том, чтобы придерживаться этих планов:)
Поэтому список далее - это то, что у меня сейчас есть в голове и чего хотя бы теоретически можно от меня ожидать. А что будет на самом деле - только время покажет. Вы же уже знаете, как расшифровывается СДВГ:)
Итак, чего от меня можно ожидать в 2026 году:
1. Актуализация Project Mariotte - это то, чем я занимался до итогов. Обновляю платформу и зависимости и перевожу реализацию на актуальные паттерны ЭП.
2. Пост с опытом миграции на Spring Boot 4. Я уже смигрировал Project Mariotte и два небольших сервиса в Project E. И уже словил и решил гору проблем (с Jackson 3 в основном). На горизонте пары месяцев, я надеюсь мигрировать TA и основной сервис Project E и по результатам написать большой пост с граблями (и решениями), которые я словил в процессе.
3. Рефакторинг TA на актульный гайдлайн ЭП. ТА у меня будет иллюстрацией и для ЭА и для книги, поэтому надо убрать оттуда исторические наслоения и компромиссные решения
4. Описание проекции модели данных ЭА с примером из ТА.
5. Проекция поведения ЭА - там, похоже, тоже придётся ещё повозиться
6. Описание процесса транзакционного анализа и процессов проектирования модели данных и компонентов на его основе.
7. В целом пп 3-6 - это всё работа в направлении книги. Но помимо этого, возможно удастся начать описывать кейсы.
8. Наверняка я придумаю что-то ещё, столь же неожиданное, как и исследование:)
На что я готов подписаться, так это на то, что в 2026 году я продолжу работу над ЭП и продолжу писать о своих приключениях на этом пути в канале:)
В общем как всегда: стей тюнед, будет интересно:)
#ergo_approach@ergonomic_code #traineradvisor@ergonomic_code #ergo_book@ergonomic_code
Я даже не из тех людей, которые в начале года составляют планы на год, не говоря уж о том, чтобы придерживаться этих планов:)
Поэтому список далее - это то, что у меня сейчас есть в голове и чего хотя бы теоретически можно от меня ожидать. А что будет на самом деле - только время покажет. Вы же уже знаете, как расшифровывается СДВГ:)
Итак, чего от меня можно ожидать в 2026 году:
1. Актуализация Project Mariotte - это то, чем я занимался до итогов. Обновляю платформу и зависимости и перевожу реализацию на актуальные паттерны ЭП.
2. Пост с опытом миграции на Spring Boot 4. Я уже смигрировал Project Mariotte и два небольших сервиса в Project E. И уже словил и решил гору проблем (с Jackson 3 в основном). На горизонте пары месяцев, я надеюсь мигрировать TA и основной сервис Project E и по результатам написать большой пост с граблями (и решениями), которые я словил в процессе.
3. Рефакторинг TA на актульный гайдлайн ЭП. ТА у меня будет иллюстрацией и для ЭА и для книги, поэтому надо убрать оттуда исторические наслоения и компромиссные решения
4. Описание проекции модели данных ЭА с примером из ТА.
5. Проекция поведения ЭА - там, похоже, тоже придётся ещё повозиться
6. Описание процесса транзакционного анализа и процессов проектирования модели данных и компонентов на его основе.
7. В целом пп 3-6 - это всё работа в направлении книги. Но помимо этого, возможно удастся начать описывать кейсы.
8. Наверняка я придумаю что-то ещё, столь же неожиданное, как и исследование:)
На что я готов подписаться, так это на то, что в 2026 году я продолжу работу над ЭП и продолжу писать о своих приключениях на этом пути в канале:)
В общем как всегда: стей тюнед, будет интересно:)
#ergo_approach@ergonomic_code #traineradvisor@ergonomic_code #ergo_book@ergonomic_code
👍10❤6🔥4