Привет!

У меня за топиками декомпозиции ретро Проекта Э не получается раскрыть тему тестирования. И вот какой-то добрый человек сделал это за меня. С реализацией я не во всём согласен (в частности на Gherkin я со скепсисом смотрю), но концептуально - фокус на компонентных тестах и тестирование сценариев - полностью согласен.

#posts@ergonomic_code #ergo_testing@ergonomic_code

Привет!

Играюсь со сборкой сервиса в нативное приложение, чёт мемасик вспомнился.

Как закончу - напишу микропост о своих приключениях

Привет!

Сегодня у меня день релизов!:)

Во-первых, я накатал обещанный микропрост про упражнения со Spring Boot Native.

А во-вторых и в главных - опубликовал первый том ретро реинжиниринга Проекта Э!

Ну и заодно немного обновил лендинг ЭП и добавил туда кейс Проекта Э

#case@ergonomic_code #project_e@ergonomic_code #posts@ergonomic_code

Привет!

Джуг наконец-то опубликовал запись моего доклада о декомпозиции на базе эффектов с JPoint!:)

А ещё они мне подарили бесплатный оффлайн билет на Джокер:) Не знаю, сколько ещё продлится этот аукцион невиданной щедрости, но приятно.

В общем ещё раз рекомендую Джуг в качестве организатора конференций - теперь я ещё в чуть большем восторге:)

#talks@ergonomic_code #ergo_approach@ergonomic_code #effects_diagram@ergonomic_code #project_camp@ergonomic_code #case@ergonomic_code

Привет!

Если вы как и я сильно ждали, но всё равно пропустили, вот вам "новость" - вышла Ява 21. Так как я пишу на Котлине меня в ней интересует только Project Loom - я уже знаю место в Проекте Э, которое с его помощью можно будет чуть упростить. Но ещё больше я жду Spring Boot 3.2, с поддержкой лума, который уже в стадии RC-1.

По традиции, на 21 Яву я перееду в ближайшее время и расскажу как всё прошло.

#tools@ergonomic_code #java@ergonomic_code

Привет!

Прочитал любопытную статью «Чистый» код, ужасная производительность.
Там мужик (автор оригинала) меряет урон от применения принципов чистого кода в деградации айфонов.
И в комментах его справедливо обвиняют в профдеформации.

Однако в случае полиморфизма вместо свича дело не только в производительности. Полиморфизм и лучшую поддерживаемость как минимум не гарантирует. А по моему мнению при разработке бэков информационных систем он чаще снижает поддерживаемость и за пропаганду полиморфизма я тоже анкл Боба пинал.

Но самое любопытное, что в Чистом коде анкл Боб был более осторожен. Хотя в разделе "Switch Statements" он призывает "хоронить switch в низкоуровневых фабриках", далее в разделе "Data/Object Anti-Symmetry" он уже не так категоричен:

> Procedural code (code using data structures) makes it easy to add new functions without changing the existing data structures. OO code, on the other hand, makes it easy to add new classes without changing existing functions.

Вопрос на миллион: как понять, что нам важнее - добавлять новые функции или добавлять новые подтипы? Наверняка я не знаю. Но моё субъективное ощущение, что в разработке бэков информационных систем чаще нужны новые функции, чем подтипы.

Поэтому я сейчас придерживаюсь эвристики, что для объектов, которые скорее представляют сервисы, я использую полиморфизм, а для объектов, которые скорее представляют данные - алгебраические типы данных (sealed классы и интерфейсы в Котлине и свежей Джаве).

Например, в проектах я часто на ранних этапах в качестве шины сообщений использую Spring ApplicationEventPublisher, однако скрываю его за своим интерфейсом, чтобы при необходимости можно было легко переехать на какую-нибудь очередь (и при этом слежу за тем, чтобы этот интерфейс не тёк).
С другой стороны, например, сущности событий дневника в Проекте Э у меня реализована как sealed иерархия классов, с пачкой функций-свичей для их обработки.

Кроме того, АДТ выигрывают у классического свича в том, что благодаря закрытости иерархии, компилятор может следить за "исчерпываемостью" свичей. Если вдруг вы добавите новый тип - компилятор скажет вам, где его надо прописать.

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

Вообще, это всё хорошо известная и изученная Expression problem, для которой не существует (пока что) хорошего решения.

А и спасибо мужику за доп аргумент в пользу АДТ - скорее всего они ещё и работают быстрее. Хотя в случае JVM я бы за это не поручился без бенчей.

#posts@ergonomic_code #clean_architecture@ergonomic_code

Привет!

Для меня работа с БД - это самая большая боль Эргономичного подхода.
Возможно, после публикации второго тома ретро (ориентировачно в четверг) - я напишу пост о том, почему мне не подходит хибер и почему подходит Spring Data JDBC.

Но SDJ хоть и подходит концептуально, в повседневной жизни бывает довольно болючь (о чём я тоже когда-нибудь напишу).

Поэтому я, стараясь не привлекать внимание санитаров, подумываю о собственном ОРМе (у меня уже даже есть небольшой прототип АПИ, работающий поверх Мап).

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

В качестве потенциально решения этой проблемы на "продвинутом SQL" мне виделся SQL MULTISET или его эмуляция на json-е.

А сегодня наткнулся на статью с амбициозным названием "This is the Beginning of the End of the N+1 Problem" от основного разработчика SDJ, где он описывает решение на оконных функциях. И самое чудесное, что это решение в минимальном виде уже работает в мейлстоуне SDJ 3.2.0.

Возможно, мне всё-таки не придётся писать ОРМ и SDJ станет тем инструментом работы с БД, который не только подходит мне идеологически, но и зубную боль не вызывает.

P.S.
Но не спешите переезжать на SDJ ради решения проблемы Н+1. Если вы сейчас на хибере, то у вас совершенно точно изменяемая модель данных и, скорее всего, не функциональная архитектура. И если вы не смените подход к проектированию на неизменяемую модель данных и функциональную архитектуру, то получите все те ужасы, баги и боли, которых говорит Андрей в Меняем Spring Data JPA на Spring Data JDBC!. И очень мало получите взамен.

#posts@ergonomic_code #spring_data_jdbc@ergonomic_code #ergo_approach@ergonomic_code

Привет!

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

#posts@ergonomic_code #project_e@ergonomic_code

Привет!

Посмотрел свежий доклад Рича Хикки о том как "делать дизайн". Как всегда очень крутой.

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

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

Потому что в 3-4 последних заметках были косяки, которые привели к к переделкам реализации в процессе первичной разработки или спустя время от нескольких часов до месяца 🤦‍♂️🤯.

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

#talks@ergonomic_code #design@ergonomic_code

Привет!

Та-да-да-да...

Анкл Боб (тот чувак, который придумал SOLID и чистую архитектуру и чистый код) написал Functional Design: Principles, Patterns, and Practices.
Кто бы мог подумать?
Тот, кто знал, что он больше 10 лет пишет на Clojure :)

Выяснил я это, потому что видел анонс книги, сейчас, перед томом с анатомией Проекта Э, решил сделать спинофф и написать большой пост "Почему ФП?" и в рамках этого поста пошёл её искать.
А спинофф решил написать потому что Проект Э сделан в функциональном стиле и этот вопрос наверняка у кого-то возникнет.

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

#books@ergonomic_code

Привет!

Прочитал Software Architecture: The Hard Parts, более подходящим названием которой было бы "Yet another монолит в микросервисы - практическое пособие для мазохистов по выбору инструментов самоистязания".

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

В остальном - очень качественный, полноценный и "comprehensive" материал, с обзором вариантов архитектур и адекватным обзором плюсов и минусов.
Так что рекомендую.

Особенно понравилось/зацепило глаз:
1. идея разделения на статическую и динамическую сцепленность. Думаю я себе это утащу в будущий пост про неё.
2. Идея пакетирования домен.поддомен.компонент и требование, чтобы компоненты были только в листах. У меня сейчас всё компоненты, при том допускаются вложенные компоненты и это не всегда работает. Не уверен, что утащу эту идею к себе, но точно подумаю в эту сторону
3. Они там так же как и я предлагаю технику выбора имени компонента, для определения его "разумности". И в целом в части декомпозиции, возможных вариантов решения сложных случаев и советов по выбору среди них - у нас совпадение процентов 80, но в книге материал больше проработан. Думаю, чем-то из книги смогу дополнить свой подход.
4. Понравилась идея семантической сцепленности - сцепленности в самой предметной области. Правда, эта штука ещё более расплывчатая, чем сцепленность в техническом решении.
4.1. Туда же хорошая идея, что техническое решение может только ухудшить (и часто так делает), семантическую сцепленность
4.2. Туда же идея, что при дизайне архитектор может "push back"-ать требования, если они содержать избыточную семантическую сцепленность, в лёгкой форме это у меня было в дизайне интеграции с ЕМИАС, где по изначальным требованиям казалось, что заказчик хочет семантической сцепленности регистрации пользователя в системе и привязке его к ЕМИАС

#books@ergonomic_code #project_e@ergonomic_code

Привет!

Подглядел в https://t.me/byndyufeed

https://ralphammer.com/make-me-think/

Пока сам не прочитал, но гифки завораживают.
Узнаёте себя при работе с современными фреймворками на левой гифке? Я да.

Привет!

Прочитал Functional Design: Principles, Patterns, and Practices.
Впечатления не однозначные

С одной стороны, там и правда, слово монада встречается ровно один раз в месте, где Мартин пишет, что не будет писать о них:
> As such, I will not spend any appreciable time on the more theoretical aspects of functional programming such as Monads, Monoids, Functors, Categories, and so on

И там и правда хорошо иллюстрируются плюсы ФП, его совместимость с ООД/П и то, что код в ФП-стиле может выглядеть достаточно знакомым большинству разработчиков.

С другой стороны, там нет ни строчки кода работы с БД - аспектом, который вносит больше всего "интересностей" в применение ФП при разработке бэков информационных систем. Более того, в книге вообще никаких интересных эффектов с вводом-выводом нет.

И отсюда же, видимо, вообще не раскрыта важная и одна из самых сложных частей ФП стиля - проектирование модели данных. Неизменяемой. И эффективно хранимой в БД.

Ну и Clojure. Мне язык нравится, и я согласен с тем, что на скобки глаз набивается быстро, но использовать книгу с примерами на Clojure в качестве инструмента популяризации ФП я не стану.

Поэтому рекомендовать книгу как единый источник для изучения прагматичного ФП нельзя, на мой взгляд. Но в рамках погружения в этот дивный мир книгу стоит прочитать.

#books@ergonomic_code

Привет!

Собираю я вчера второй хот фикс на последний кровавый релиз Проекта Э с одной регрессией бэка и двумя костылями для багов в МП, пока шёл пайплайн заглянул на хабр, а там - Релиз без ошибок. Невозможное возможно?.
У мужика процесс намного более стандартизован (бюрократизирован?) и такого я себе пока позволить не могу, но в фокусе на функциональных тестах мы уже сходимся:)

С учётом того, что я заявляю, что ЭП позволяет существенно сократить кол-во багов, а в этом релизе на бэке нашли штук 5-6 багов (справедливости ради - только при тестировании МП и в течении 2-3 недель), то я этот релиз и все баги разберу по косточкам. И постараюсь опубликовать разбор, если удастся сохранить смысл, не нарушая NDA.

#posts@ergonomic_code #project_e@ergonomic_code

Но пост выше - это я просто актуальным поделился.

А вообще - сегодня день релиза поста "ФП виновно в снижении стоимости программ. Вот мои доказательства, господа присяжные заседатели" :)

#posts@ergonomic_code #whyfp@ergonomic_code

Привет!

Я завершаю работу над Проектом Э с 1 января 2024 года и ищу новый проект.

Со мной возможен широкий спектр вариантов сотрудничества - от реализации проекта под ключ по фикс прайсу силами моей команды до краткосрочного аутстаффа меня лично.
Работаю я по договору с ИП (ЭДО есть) и оплатой на расчётный счёт.

По сравнению с большими компаниями, цены у меня очень демократичные.
Полная стоимость для заказчика часа моей работы составляет 2500 р/час.
Стоимость часа других специалистов зависит от грейда и профиля, но так же ниже, чем у больших игроков с большими накладными расходами.

Если вы или ваша компания сейчас ищете подрядчика/субподрядчика на выполнение работ по разработке ПО - напишите, пожалуйста, мне в личку - @d_r_q, или на почту - me@azhidkov.pro.

Привет!

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

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

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

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

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

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

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

#trainer_advisor@ergonomic_code

Привет!

Я определился с форматом и планами канала на ближайшие полгода-год.

Основным форматом остаётся текстовый.

Потому что:
1. Почти половина против видео (Я занёс в против тех, кому ок видео нормального качества, см. п. 3)
2. В комментариях 100% против
3. Я провёл небольшой тест-драйв такого формата и понял, что без подготовки получается лажа.

Но, я хочу всё-таки попробовать продемонстрировать разработку по эргономичному ТДД, поэтому как минимум один видеопост всё-таки будет.

Контент станет преимущественно практическим (на базе QYoga).

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

Сейчас у меня план постов следующий:
1. 22 ноября - микропост с нотацией описания неизменяемой модели данных (пригодится для следующего поста)
2. 23 ноября - микропост с общим описанием QYoga
3. 24 ноября - микропост о том, как мы моделируем самую сложную часть QYoga
4. 2 декабря- микропост с описанием устройства кодовой базы QYoga
5. 3 декабря- видеопост с демо эргономичного ТДД
6. 10 декабря - пост с третьим томом ретро Проекта Э (устройство кодовой базы)
7. 24 декабря - пост с четвёртым томом ретро Проекта Э (проблемы унаследованные от .net-бэка)

И спасибо всем, поучаствовавшим в опросе:)

Эдит: обновил планируемые даты постов