Привет!

Для меня работа с БД - это самая большая боль Эргономичного подхода.
Возможно, после публикации второго тома ретро (ориентировачно в четверг) - я напишу пост о том, почему мне не подходит хибер и почему подходит 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-бэка)

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

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

Привет!

"Хочешь насмешить бога - расскажи ему о своих планах" (с) Народ.

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

А ещё то, что на этой же недели у меня заболеет ребёнок 🤯

Поэтому план уже точно поедет как минимум на неделю.

Тем не менее, вопреки обстоятельствам, я осилил написать микропост с моей нотацией описания модели предметной области и алгоритмом её допила под хранение в виде неизменямых деревьев структур данных.

#immutable_domain_model@ergonomic_code #ergo_approach@ergonomic_code #ergo_persistance@ergonomic_code

Привет!

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

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

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

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

#trainer_advisor@ergonomic_code

Привет!

В IDEA 2023.3 стал доступен всем AI Assistant с бесплатным триалом.

#tools@ergonomic_code

Привет!

Проживаю очередной кризис нигилизма:
1) ООП - нахер, эта фигня никогда не работала для информационных систем
2) ООД - нахер, эта фигня не масштабируется ([1], [2])
3) DDD - нахер, таш самая дичь, что и микросервисы - нужно и возможно только в 1% проектов, а в остальных - только удоржает разработку и тешит самолюбие разработчиков
4) Сокрытие информации - нахер, в рамках одного проекта над которым работает одна команда (а то и один человек) - это попахивает шизофринией
5) Open-Closed Principle и Dependency Inversion Principle и Чистая архитектура - нахер (пока реализация одна), эта хрень только усложняет кодовую базу и удорожает разработку
6) Low Coupling/High Cohesion - нахер, это какая-то непонятная дичь. На самом деле - тут тоже "пока что-то" или ещё какое-то условие, но вот что за условие - я ещё не понял.
7) Information Expert - нахер, эта фигня не масштабируется

А что не нахер?
1) DRY - это то, что позволяет снизить стоимость (гемморой для разработчика) внесения изменений
2) KISS - это то, что позволяет снизить стоимость (гемморой для разработчика) внесения изменений
3) Отсутствие циклов в зависимостях - это первое средство борьбы с Big Ball of Mud (упращения кодовой базы)
4) Неизменяемя модель данных - второе средство борьбы с Big Ball of Mud (упращения кодовой базы)
5) Структурный дизайн/функциональная архитектура - третье средство борьбы с Big Ball of Mud (упращения кодовой базы)
6) Единство уровня абстракции/SRP - четвёртое средство борьбы с Big Ball of Mud (упращения кодовой базы)
7) Очевидность связей (сцепленности?)/локальность рассуждений о коде - пятое средство борьбы с Big Ball of Mud (упращения кодовой базы)
8) Классическая школа ТДД - единственное (известное мне) надёжное средство борьбы с регрессиями -> возможность свободно улучашть качество кодовой базы
9) Базовая модель информационных систем в виде операций, ресурсов и эффектов - это то, чем информационные системы являются по своей сути

Вобщем "гамак-дривен" девелопмен эргономичной структуры программ в3 продолжается (второе полугодие), но вроде процесс начал сходиться.

P.s.

1) добротный и двольно свежий пост с обзором и сравнением основных архитектур
2) И в дополнение - более подробный разбор вертикальной архитектуры

#ergo_approach@ergonomic_code #oop@ergonomic_code #ddd@ergonomic_code #design@ergonomic_code

Я тут подумал, что сцепленность, возможно зря в первый список поместил.

Я поленился написать обзор на Fundamentals of Software Architecture: An Engineering Approach, которую недавно прочитал и которая, на самом деле, мне понравилась намного больше, чем Software Architecture: The Hard Parts, а меж тем там авторы пишут про Connascence - аналог Coupling для ОО-систем.

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

В общем рекомендую вам и Fundamentals of Software Architecture: An Engineering Approach прочитать и Connascence погуглить.

Ну и сам я рано или поздно её разберу подробно и напишу о ней пост.

#books@ergonomic_code #oop@ergonomic_code #couplingergonomic_code