Привет!

Я рассматриваю вариант существенного изменения концепции канала, и прежде чем принять окончательное решение, хочу узнать ваше мнение.

Изменения будет два:
1) Переключение фокуса на практику
2) Переход на формат быстрых (без особой режиссуры и монтажа) видео

Посты будут о разработке (интересных, не обычных и сложных частях) моего пет-проекта - QYoga (название рабочее, сегодня проведу брейншторм нового названия:) )

План первого видео:
1) Для случайных прохожих - кто я и что такое Эргономичный подход
2) Общее описание QYoga
3) Подробный разбор текущей кодовой базы
4) Демо реализации простой фичи (регистрация юзера) по эргономичному ТДД

Мотивация переключения на практику - так как я заканчиваю работу с Проектом Э и не уверен, что следующий проект смогу сделать по ЭП (а если смогу сделать - что смогу писать об этом) - я боюсь что либо потеряю вообще обратную связь ЭП с миром, либо потеряю источник контента для блога. И чтобы отвязаться от внешних ограничений - хочу сделать свой собственный максимально приближенный к реальности проект по ЭП. А совмещать коммерческую работу, работу над QYoga и проработку теории я точно не осилю.

Мотивация переключения на видео - у меня есть гипотиза, что это будет быстрее, чем писать микропосты.

Сейчас заведу пару опросов.

#trainer_advisor@ergonomic_code

Привет!

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

Но у меня есть уважительная откоряка - я активно пилю первую фичу QYoga (карточку клиента), чтобы завести первого живого пользователя, чтобы приблизить проект к "реальному".

Тем не менее, я осилил микропост с общим описанием проекта.

Всё остальное медленно, но верно тоже распишу.

#trainer_advisor@ergonomic_code

Привет!

А теперь наконец-то осилил встравить скриншот в другой прошлогодний микропост - Проектирование модели данных клинического мышления в Trainer Advisor.

И заодно анонс следующего (микро)поста - анализ эффективности работы команды Проекта Э во втором и третьем квартале от рождества христова от даты завершения реинжиниринга.

Это будет продолжение сравнения эффективности работы команд Проекта Э до и после реинжинирига - так же подобью задачи в джире и посмотрю медианные трудозатраты и количество багов на задачу. А потом сделаю экстраполяцию по трём точкам 🤣

#trainer_advisor@ergonomic_code

Привет!

Я не умер. И канал не умер. И я не забил ни на канал, ни на ЭП:)

Последнее время я активно допиливал Trainer Advisor. И теперь TA содержит всю базовую функциональность.

В цифрах это:
1) 14 таблиц
2) 12 страниц UI
3) 57 эндпоинтов
4) 4378 строк продового Kotlin-кода
5) 136 интеграционных + 2 мок-теста + 2 юнит теста + 1 архитектурный тест = 141 тестов, проходящих за 17 секунд
6) 1e2e Селениум тест

Это всё написано более-менее по текущим канонам ЭП и публично доступно для изучения и ознакомления.

И это самый большой известный мне проект, демонстрирующий какой-либо подход к разработке.
А если к этому добавить ещё и тот факт, что этот проект задеплоен и один живой пользователь внёс в него 40 единиц реальных доменных данных - то уже можно начать бросаться словами в духе "Демонстрация, не имеющая аналогов в мире".:)

—

Прямо сейчас в коде ТА хорошо проиллюстрированы две части ЭП:
1) Неизменяемая модель данных
2) Подход к тестированию

Так же с помощью 370 строк кода мне удалось решить две самые большие боли Spring Data JDBC:
1) Динамические критерии выборки
2) Подгрузку ссылочных данных для вывода на фронт (без дублирования структуры доменных объектов)

И сейчас решение этих задач у меня выглядит так:

// Выборка по динамическим параметрам:
findAll(pageRequest) {
        Client::therapistId isEqual therapistId
        Client::firstName isILikeIfNotNull clientSearchDto.firstName
        Client::lastName isILikeIfNotNull clientSearchDto.lastName
        Client::phoneNumber isILikeIfNotNull clientSearchDto.phoneNumber
}
// Выборка с подгрузкой ссылок
object Appointment.Fetch {
    val summaryRefs = listOf(Appointment::clientRef, Appointment::typeRef)
    val editableRefs = summaryRefs + Appointment::therapeuticTaskRef
}
val appointment = appointmentsRepo.findById(appointmentId, Appointment.Fetch.editableRefs)

Естественно, их можно комбинировать, но пока в проекте такой потребности нет.

Но эта работа так же помогла мне проявить пару противоречий и нерешённых проблем в ЭП:
1) С ФА есть проблема в том, что в большинстве моих проектов бизнес-логики (чистого ядра) набирается от силы процентов 10, а всё остальное - линейный круд. И кажется что это противоречит тому что ФА является одним из столпов ЭП
2) Реальный мир не всегда хорошо ложится на плоскую картину use case/workflow даже 3ей версии эргономичной структуры программ.

Что с этим делать - пока не знаю

—

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

#trainer_advisor@ergonomic_code #ergo_approach@ergonomic_code #ergo_persistance@ergonomic_code

Привет!

Финализирую первый пост с описанием тестирования TA и походу дела накапал небольшую неопубликованную заметку с его архитектурой и стеком. И вот опубликовал:)

А пост с тестированием, думаю, на этой недели опубликую.

#trainer_advisor@ergonomic_code

Привет!

Опубликовал первый пост про тестирование TA с общими идеями и принципами (но уже здесь с иллюстрациями реальным кодом из TA).

#trainer_advisor@ergonomic_code #ergo_testing@ergonomic_code

Привет!

Опубликовал второй кусочек описания тестирования Trainer Advisor - сетап system under test.

#trainer_advisor@ergonomic_code #ergo_testing@ergonomic_code

И опубликовал очередной кусочек описания тестирования Trainer Advisor - формирование фикстурных объектов и их вставка в БД.

Там из 34К знаков 14К - код, почти половина:).

P.s. сбросьте кэш браузера, чтобы подтянуть css с выделеним строк в некоторых из сниппетов

#trainer_advisor@ergonomic_code #ergo_testing@ergonomic_code

Привет!

Опубликовал пост с последним кусочком описания сетапа фикстуры Trainer Advisor - сетап тестовых дублей.

В этом посте для полноты картины я добавил бонус-трек с описанием сетапа тестовых дублей для тестирования работы с внешними веб-сервисами, кроликом, кафкой и MQTT-брокером.

И под это дело добавил соответствующий бонус-трек в пост с описанием запуска инфраструктуры.

#trainer_advisor@ergonomic_code #ergo_testing@ergonomic_code #whynomocks@ergonomic_code

Привет!

Я ещё почти два года назад назад начал думать в сторону того, что пути эндпоинтов REST/JSON-over-HTTP API надо нарезать исходя из UX-клиентов, а не сущностей/ресурсов.

То есть, допустим, у нас есть пользователи и три эндпоинта:
1. Залогиниться
2. Посмотреть собвтенные данные
3. Посмотреть данные любого юзера для админов

И раньше я делал сам и наблюдал буквально во всех проектах, которые видел, эти эндпоинты замапили бы на:
1. POST /users/login
2. GET /users/profile
3. GET /users/profiles/{id}

А сейчас я бы это зампаил так:
1. POST /public/login
2. GET /user/profile
3. GET /admin/profiles/{id}

И после того, как я отказался от объектно-ориентированной декомпозиции и актуализировался вопрос декомпозции слоя приложения - эта идея заиграла новыми красками - первичную декомпозицию слоя приложения можно делать по UX-ам - считай приложениям

И, например, в TA я это так и сделал - если не считать вспомогательных пакетов infra и platform, в пакте app два подпакета:

1. public - "приложение"-точка входа, для регистрации и логина (по историческим причинам мапится на "/"...)
2. therapist - "приложение"-АРМ терапевта (мапится на "/therapist/")

Ещё есть "приложение"-сисадмина - Spring Boot Actuator (мапится на "/ops/**")

Такая схема, среди прочего ещё и существенно упрощает конфигурацию авторизации

Но это всё была прелюдия.

Я тут наткнулся на оригинальный пост про гексагональную архитектуру (ака порты и адаптеры), а там:

What exactly a port is and isn’t is largely a matter of taste. At the one extreme, every use case could be given its own port, producing hundreds of ports for many applications. Alternatively, one could imagine merging all primary ports and all secondary ports so there are only two ports, a left side and a right side.

Neither extreme appears optimal.

The weather system described in the Known Uses has four natural ports: the weather feed, the administrator, the notified subscribers, the subscriber database. A coffee machine controller has four natural ports: the user, the database containing the recipes and prices, the dispensers, and the coin box. A hospital medication system might have three: one for the nurse, one for the prescription database, and one for the computer-controller medication dispensers.

It doesn’t appear that there is any particular damage in choosing the “wrong” number of ports, so that remains a matter of intuition. My selection tends to favor a small number, two, three or four ports, as described above and in the Known Uses.

Что именно является портом, а что нет, во многом является делом вкуса. С одной стороны, каждому юз-кейсу можно было бы присвоить свой собственный порт, создав сотни портов для множества приложений. В качестве альтернативы, можно было бы объединить все основные и все дополнительные порты, чтобы было только два порта, левый и правый.

Ни один из крайних вариантов не кажется оптимальным.

Система прогнозирования погоды, описанная в "Известных вариантах использования", имеет четыре естественных порта: канал прогноза погоды, администратор, уведомленные подписчики, база данных подписчиков. Контроллер кофемашины имеет четыре естественных порта: пользователь, база данных, содержащая рецепты и цены, дозаторы и ящик для монет. Больничная система выдачи лекарств может состоять из трех компонентов: один для медсестры, один для базы данных рецептов и один для диспенсеров лекарств с компьютерным управлением.

Похоже, что выбор “неправильного” количества портов не может нанести какой-то особый ущерб, так что это остается вопросом интуиции. Мой выбор, как правило, делается в пользу небольшого количества - двух, трех или четырех портов, как описано выше, и в известных случаях использования.

И я в этом тексте вижу те же самые приложения (в "левых"/основных портах у Кокбёрна), что и у себя.

В общем советую подумать в сторону того, сколько UX-ов есть у ваших (монолитных) бакендов и отражено ли это в вашей архитектуре

#design@ergonomic_code #rest_api@ergonomic_code #hexagonal_architecture@ergonomic_code #trainer_advisor@ergonomic_code

Привет!

Обещанные демо-проекты.

Project Moby - демо того, как я выкручиваюсь на Spring Data JDCB с энергичной загрузкой, когда она нужна.

Project Sherlok - демо того, как я выкручиваюсь с динамиеческими запросами.

Обе техники используются в Trainer Advisor.

#spring_data_jdbc@ergonomic_code #trainer_advisor@ergonomic_code #demo_projects@ergonomic_code

Привет!

На выходных спинным мозгом чутка подвигал Trainer Advisor

Переезд на Kotlin 2.0.20

Начал с того, что с третьей попытки наконец осилил переехать с Kotlin 1.9.20 на 2.0.20.
Летом при переезде на 2.0.0 (и, возможно, 2.0.10 - не помню уже точно) было какое-то совершенно невнятное сообщение об ошибке компиляции, которое ставило меня в тупик.

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

Я начал пытаться локализовать строчку, на которой компилятор взрывается (он писал файл). И долокализовался до того, что файл вообще удалил, а компилятор продолжил взрываться 🤯

Потом каким-то чудом я обнаружил, что у меня есть одноимённый файл в Gradle Test Fixtures source set. И вот когда я туда залез - там у меня уже IDEA GigaIDE начала взрываться, что не найдены Spring-овые классы. Пошёл гуглить WTF и по первой же ссылке выяснил, что во 2-ой версии, impl-зависимости продового кода не перекидываются в testFixture - прокинул, завелось.

Мораль - чёрт его знает. Проект на 13К нетривиального кода (люблю я знаете ли проверять компиляторы на прочность) перевести мне удалось. Но чудом. Если ждали знака, чтобы попробовать перевести свой проект - вот он. Но будьте готовы к приключениям.

Переезд на HTMX 2.0.3

Следующим шагом переехал на новую мажорную версию HTMX. Просто обновил и всё заработало. Вряд ли это кому-то ещё интересно, но если вдруг - на HTMX 2 можно достаточно смело ехать.

Greenmail для локальной работы в докере

Но кое-какой нюанс с переездом всё таки был - если покрытие серверного кода, включая рендеринг HTML у меня близок к 100%, то динамика UI (у меня там ещё и alpine.js немного есть) у меня очень слабо покрыта e2e тестами - есть только тесты на критичные сценарии - регистрация и логин и создание карточки клиента и приёма.

Поэтому я на всякий случай после переезда на HTMX 2 решил руками прогнать полный регресс.

И упёрся в небольшую шероховатость DevX-а проекта.
Наполовину по историческим причинам и наполовину во имя простоты бэка, сейчас при регистрации пароль отправляется письмом на почту юзера.
Примерно по тем же причинам, в проде для отправки почты у меня используется бесплатный ящик на Яндексе. И креды от него, по понятным причинам, куда-то заныканы.
Соответственно, при локальной разработке, после чекаута проекта зарегаться нельзя - надо сначала как-то настроить отправку писем.
Об это я и споткнулся, когда начал делать регресс в новом проекте - обычно я 99% работы делаю через тесты и ещё для 0.99% работы мне достаточно юзера, который добавляется в демо-данных при локальной разработке.
А вот регистрация из коробки не работала.

Вот это я и залечил, добавив Greenmail в проект компоуза локальной инфры.

И написав shell-однострочник для выковыривания пароля оттуда:

curl -X GET "http://localhost:58080/api/user/test%40ya.ru/messages/" \
-H 'accept: application/json' | jq -r '.[] | .mimeMessage ' | grep -A7 0JfQ | python3 -m base64 -d | grep 'Пароль'

PS>

Напоминаю, что мне в ТА можно поконтрибьютить.

Если вы опытный разработчик и вам не комфортно работать в том стиле, в котором пишете сейчас - это хороший способ пощупать ЭП руками и понять нравится ли вам такой DevX.

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

Код двух подписчиков уже есть в TA - так что это вполне реально:)
Отзыв одного из них:

В целом, мне понравилось делать изменения у тебя. Не могу сказать, что согласен со всем. Мне пока кажется почти идеальным вот этот layout https://github.com/gushakov/cargo-clean

Если интересно - пишите в личку, договоримся о звонке для онбоардинга

#trainer_advisor@ergonomic_code #tools@ergonomic_code #kotlin@ergonomic_code #devx@ergonomic_code

Привет!

На днях перевёл Проект Р и Trainer Advisor на Kotlin 2.1.0 и Spring Boot 3.4.0
В целом всё прошло без проблем, делюсь впечатлениями

Проект Р/Котлин 2.0.0 -> 2.1.0
1. Т.к. переходил с версии 2.0.0 так же возникла проблема с пропажей продовых зависимостей в testFixtures source sets. И со второй попытки я её определил и починил быстро
2. В паре data классов с приватными конструкторами пришлось развесить @ConsistentCopyVisibility, чтобы варнинг убрать

Проект Р/Спринг 3.3.1 -> 3.4.0
1. Тест на корс, который ломился без авторизации на закрытый урл начал валиться по 401/3 (забыл уже) - перевёл его на запрос к публичному пути - заработало

Trainer Adviser/Котлин 2.0.21 -> 2.1.0
1. Заглючила идея 2024.2 и опять на testsFixtures - гредлом всё ок собирается, в редакторе ошибок нет, но при попытке сборки проектов идеевским билд тулом (я юзаю его для разработки, так как он быстрее гредлового) - ругается что не может в коде тестов найти символ из кода фикстур. Это поличилось обновлением самой идеи до 2024.3

Trainer Advisor/Спринг 3.3.5 -> 3.4.0
1. Начало взрываться responseEntity.contentLength = storedFileInputStream.metaData.size при size = 0. Добавил if (size > 0) - завелось
2. В одном из эндпоинтов на параметр принципала не был навешан @AuthenticationPrincipal. Раньше это как-то работало, после преезда перестало, после добавления аннотации снова заработало.

—

На обновление Проекта Р у меня ушло часа три.
Львиная доля ушла на:
1. переход на обратнонесовместимый Kover 0.8.3
2. datafaker в котором задепрекейтили один из методов
3. не связанные с обновлением разборки с гредлом

Trainer Advisor вообще за час максимум обновил.

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

#kotlin@ergonomic_code #spring@ergonomic_code #projectr@ergonomic_code #trainer_advisor@ergonomic_code

Привет!

Heartbeat-пост.

Я жив. И канал жив. И Эргономичный подход жив.

Затишье в последнее время связано в основном с тем, что я в Trainer Adviser пилю интеграцию с ical-календарями.
Там не то чтобы прям рокетсайнс, но уже и не совсем тривиальный круд - будет больше примеров нетривиального кода по ЭП.

Но это я днём руками работают. А ночью думаю. Что взять на замену функциональной архитектуре. И у меня тут появилась идея CQTS Principle - Command-Query-Transformation Principle.
Берём старый добрый CQS скрещиваем его со сбалансированной формой системы и получаем профит. Это пока мысль в слух - не знаю стоит ли дальше этот термин педалировать или ну его.

#trainer_advisor@ergonomic_code #ergo_approach@ergonomic_code #functional_architecture@ergonomic_code #structured_design@ergonomic_code

Привет!

Что-то последняя большая новость никак не дозреет, поэтому пока расскажу о двух созревших.

Новость №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