Привет!

Параноидальный линко-пост.
Гугл, по чистой случайности главный большой брат и владелец самого популярного браузера, собирается выкинуть АПИ критичные для АдБлокеров.

Го Firefox - тут вполне ок последние 4 года

Привет!

Прочитал оригинальюную статью по Parnas Partitioning (ещё раз спасибо @celebithil за неё).

Не сказать чтобы статья показалась мне особо полезной, но напоминание одной хорошей мысли утянул:
In fact, imposing a design goal of modularity or flexibility WITHOUT providing the associated Hiding Assumption List would appear to be inherently ineffective. General purpose flexibility is likely to prove to be an ill-defined goal.

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

Привет!

Вышли корутины 1.6.0 с парой долгожданных (мной) фич:
1) наконец-то можно писать мультиплатформенные тесты на suspend код без костылей
2) наконец-то можно создавать диспетчеры с ограниченным параллелизмом

#tools@ergonomic_code #kotlin@ergonomic_code

Привет!

Новый год - время перемен.

Весь 21-ый год я пытался сделать рациональную методику разработки ПО с детерминированным результатом. И что-то у меня не выходил каменный цветок - наверное не просто так, никто ещё этого не смог:)

И вот, под конец года я сначала прочитал "Думай медленно, решай быстро", где Канниман среди прочего ставит под сомнение предсказательную способность некоторых экспертов (я это прочитал как сомнение в способности программистов предсказать изменения).
Затем я прочитал "A RATIONAL DESIGN PROCESS: HOW AND WHY TO FAKE IT", где Парнас пишет, что рациональный дизайн невозможен.
Потом прочитал "Чёрного Лебедя", где Талеб среди прочего через слово пинает платонические модели
И сейчас читаю "Data and Reality", где Кент показывает, что информация сама по себе - аморфное месиво, и нет рационального способа выбора её представления в компьютере.

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

С наступающим Новым годом!:)
Пусть вам программирование приносит больше положительных эмоций, чем отрицательных:)

#ergo_approach@ergonomic_code #books@ergonomic_code

Привет!

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

И одним из аспектов кризиса является разочарование в агрегатах и Spring Data JDBC. Я пока не понимаю где проблема - в самих идее и технологии или ДНК (моём) и у меня нет другой идеи как делать эргономичный персистанс, поэтому пока придерживаюсь старой схемы.

Так вот, накопал интересный доклад о Spring Data JDBC от его разработчика. Он там из первых рук объясняет мотивацию создания модуля (мало кто в мире понимает и может эффективно использовать JPA, за пределами туториалов и хелло воролдов) и даёт пачку рецептов решения не совсем тривиальных проблем.

И этот доклад натолкнул меня на интересную мысль: Агрегаты и неизменяемая модель данных - идеальная комбинация.
По задумке, все изменения в агрегате должны проходить через его корень.
И если у вас модель изменяемая, то для соблюдения этого правила есть только два пути:
1) Полностью инкапсулировать все сущности внутри агрегата. Но в этом случае в агрегате придётся нагенерять гору методов для чтения данных некорневых сущностей.
2) Отрубать руки за прямую мутацию некорневой сущности. В прямом смысле, потому что более мягкое наказание будет приводить к нарушению этого правила, из-за невнимательности или спешки.

Потенциально есть ещё вариант с package private методами для мутации некорневых сущностей, но:
1) В Котлин package private всё ещё не завезли:(
2) Это требует пакетирования по агрегатам
Однако главный аргумент против того, чтобы не искать способ соблюдать это правило в изменяемой модели - императивный код сложен в понимании и подвержен ошибкам

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

#ergo_approach@ergonomic_code #spring_data_jdbc@ergonomic_code #talks@ergonomic_code #whynojpa@ergonomic_code

Привет!

Postgres Professionals - российская контора по разработке и коммерческой поддержке постгреса, выпустила книгу (на русском!) об устройстве постгреса. Сам, естественно, ещё не читал, но добавил себе в список прочтения.

#books@ergonomic_code #databases@ergonomic_code

Привет!

Продолжаю проверять гипотезу, что это у меня проблема в ДНК, а с агрегатами и Spring Data JDBC всё ок, смотрю очередной видос

Всё тот же автор Spring Data JDBC одновременно:
1) пинает JPA
2) восторгается агрегатами
3) предлагает декомпозировать систему на основе агрегатов
4) запрещает циклы в зависимостях
Смотрю как в своё зеркало 21ого года:)

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

Ну и наконец:
"it will feel painfull ... but people have to think where stuff belongs and this alone is I think a great benefit"
Со второй частью согласен полностью. Но хочется найти способ обойтись без боли

#talks@ergonomic_code #spring_data_jdbc@ergonomic_code #whynojpa@ergonomic_code #ergo_approach@ergonomic_code

Привет!

Сегодня линкопост: Functional Programming for Pragmatists
Мужик говорит быстро, поэтому слушать довольно тяжело, но мне нравится его определение и объяснение ФП.

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

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

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

#talks@ergonomic_code #fp@ergonomic_code

Между тем в фоновом режиме думаю как делать эргономичный персистанс и накопал статью с критикой SQL-я за неэргономичность:) И альтернативным предложением:)
Может быть у нас всё-таки есть свет в конце туннеля:)

#posts@ergonomic_code #sql@ergonomic_code

Привет!

Вы наверняка слышали, что Хоар назвал null-ы своей ошибкой на миллиард долларов.

Вчера случайно наткнулся на относительно свежую (2009 год) презентацию самого Хоара на эту тему.
И она натолкнула меня на мысль, что мы живём на закате (первой?) золотой эры ИТ - всё самое крутое придумали в 60-70-ые годы и многие из тех, кто это ещё живы и при на них можно посмотреть в живую:)

Сама же презентация не то чтобы прям полезная была, но довольно интересная и за ней можно скоротать длинный зимний вечерок:)

#talks@ergonomic_code

Привет!

Снова линко-пост.

Тут дядька хорошо показывает в чём проблема с наллами и предлагает заменить их на Maybe-монаду (ака Java Optional, ака sum типы).

Но не спешите всё переписывать на Optional, пока не посмотрите как Рич Хикки пинает Maybe в первых 14 минутах этой презентации и предлагает заменить их на union типы (ака Kotlin nullable, ака Java Multiple catch block).

А этой статье автор подробно рассматривает sum & union типы и приходит к выводу, что "Therefore union types are strictly more flexible than sum types, but the ergonomics of each approach depends on the use-case."

#talks@ergonomic_code

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

Привет!

Пока новый пост варится - радую вас линками:)

Я нашёл базу данных мечты - EdgeDb.

Что в ней крутого:
1) Она на базе Постгреса. Т.е. ядро надёжное и если с верхним слоем будут проблемы - можно будет цепануться к Постгресу напрямую
2) У неё графово-реляионна модель данных
2.1) Она поддерживает вложенные инсёрты
2.2) Она поддерживает наследование и полиморфные связи
2.3) Она поддерживает выборку иерархичных данных
2.4) Запросы на EdgeQL композируемые (Composable)
3) Судя по гиту, пилят её уже 13 лет и сейчас пилят активно как никогда - на момент написания предыдущий мёрж в мастер был 43 минуты назад, а за последние 2 дня вмёржили 20 ПРов
4) Free как и свобода и как пиво
5) Поддерживает GraphQL из коробки
6) У неё релиз версии 1.0 в феврале

Одна проблема - нет клиентов под JVM 😂

#posts@ergonomic_code #ergo_persistance@ergonomic_code #tools@ergonomic_code #databases@ergonomic_code

И бонусом, в первую очередь для моих студентов, но может и опытным специалистам покажется интересным: ещё раз про джоины

#posts@ergonomic_code #sql@ergonomic_code

Привет!

Внезапный "а знаете ли вы пост?".

Наверняка вы слышали, что при проектировании REST API необходимо отдавать предпочтение стандартизированный штукам, например для авторизации использовать заголовок Authentication.

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

#http_api@ergonomic_code #rest_api@ergonomic_code #posts@ergonomic_code

Привет!

Объявляю идейный кризис эргономичного подхода успешно преодолённым:) В частности с агрегатами и Spring Data JDBC всё так, это у меня была ошибка в ДНК.

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

Эргономичный подход - это подход к разработке ПО с минимальной связанностью (coupling) и как следствие с максимальной связностью (cohesion).
Программы с минимальной связностью дёшевы и легки в поддержке благодаря простоте понимания и лёгкости модификации.

Эргономичный подход стоит на трёх столпах:
1) Декларативный стиль программирования
* Это позволяет минимизировать связанность по общей области и управлению (common & control coupling)
2) Декомпозиция системы на модули с высокой связностью и низкой связанностью
* Это и делает систему простой для понимания и лёгкой в поддержке
3) Детройтская школа тестирования
* Это минимизирует связанность между тестами и деталями реализации

От мейнстримового подхода Эргономичный подход отличается следующим:
1) Использование модели неизменяемых связанных данных (Immutable Relation Data) на базе агрегатов DDD и эпохальной модели времени для моделирования информации системы (а не модели графа изменяемых объектов)
2) Стремление максимум кода вынести в функции без побочных эффектов (а не бессистемное разбрасывание побочных эффектов по всему коду)
3) Применение архитектурного стиля функциональное ядро/императивная оболочка (а не классической слоёной архитектуры)
4) Разделение слоя бизнес-логики на подслой приложения (оркестрация выполнения операции системы) и подслой предметной области (сложные бизнес-правила, задействующие несколько агрегатов) (а не единый слой сервисов)
5) Верхнеуровневое разбиение на модули системы (а не слои)
6) Минимизация зависимостей между модулями системы (а не произвольное добавление новых зависимостей в систему)
7) Тестирование системы на соответствие требованиям (а не покрытие тестами классов и методов)
8) Мокирование только дорогих или нестабильных внешних систем (а не всех классов, помимо тестируемого)
9) Для достижения пп 1-3 и 6 - использование Spring Data JDBC (а не Spring Data JPA)
10) Для достижения п. 6 - ручное управление зависимостями (а не Spring Component Scan)

P. S>
это ещё и линко пост был:)
Immutable Relational Data - коротенько (30 минут) о там как жить с неизменяемой моделью данных (в данном конкретном случае на примере веб-фронта на Elm-е)
эпохальная модель времени - как моделировать изменения в неизменяемой модели данных

P.P.S>
Промахунлся:(

#immutable_domain_model@ergonomic_code #ergo_approach@ergonomic_code

Привет!

Отвлёкся от поста про агрегаты, чтобы быстро написать свою версию ответа на вопрос "Что почитать по проектированию приложений?"

#books@ergonomic_code

Привет!

По результатам голосования по предпочитаемой частоте постов перешёл к батчингу постов:)

Итем 1
(Уже вчера) вышел Котлин 1.6.20 с превью фичи множества ресиверов (дизайн фичи)
Фича довольно жёсткая - даже не буду пытаться тут на пальцах её объяснять.
Поэтому, не уверен, что несёт больше пользы, чем вреда (см сколько "не делайте так" в дизайне).
Но если аккуратно применять, то позволит писать ещё более выразительные ДСЛи

Итем 2
Делал тут странное - сессию живого кодирования, для непрограммистов.
Вкратце упрощённо рассказал что современный код состоит из классов. Классы упрощённо бывают двух типов - сущности с описанием данных и сервисы с алгоритмами.

Потом пошёл кодидить и вот мне потребовалось заинжектить зависимость. Тут я ни сходу, ни после не придумал простого способа объяснить что и зачем я делаю.

Зато, подумал, что если бы у меня были только функции, в том числе высшего порядка, то мне было бы намного проще объяснить.
Попробовал объяснить это жене (она 15 лет назад прошла курс по ООП, а сейчас продвинутый пользователь экселя) - и про функции мы смогли нормально поговорить, а с объектами очень быстро дошли до "ой всё":)
И у меня нет ощущения, что сложность ООП как-то окупается.

В общем ФП - наше всё:)

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

А тут я добрался наконец до дисера по REST и там чуть ли не на первой странице Филдинг пишет:
> The hyperbole of The Architects Sketch may seem ridiculous, but consider how often we see software projects begin with adoption of the latest fad in architectural design, and only later discover whether or not the system requirements call for such an architecture. Design-by-buzzword is a common occurrence

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

Привет!

Линко пост. "Что почитать архитектору?" по версии какого-то мужика в интернете:)

#posts@ergonomic_code #books@ergonomic_code

Привет!

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

ТЛДР- мальчик становится мужчиной 5-летний "техлид" начинает понимать суть своего карго культа, нахапанного в интернете, и встаёт на путь к эргономичному подходу:)

А теперь подробнее:)

Во-первых, заголовок явно кликбейтный (или как оно называется?). Я работал с кодом стартапа из долины и постоянно читаю про "зарубежный опыт" - у них там буквально всё тоже самое, один в один.
Во-вторых, это личное мнение одного автора, а не всего "зарубежа".
В-третьих, автор закончил в универ в 17ом году - а я не верю в техлидов с 5 годами опыта (добавка после прочтения поста - и правильно делаю, что неверю)
Но, справедливости ради, у него есть пост про отказ от юнит тестов - плюсик.


> For us, this has reduced the size of a regular feature, such as a new microservice endpoint for updating or reading data, from a total of approximately 25 files down to just 5, that’s an 80% reduction with the majority of code simply having been deleted, all while simultaneously improving code readability
Ох, ну у меня по дефолту на эндпоинт надо вообще 4-5 классов - контроллер, сервис приложения, репоз, агрегат и опциональный сервис домена
А на фоне оверхеда который приносят микросервисы всё что описано позже - экономия на спичках. Из поста не ясно, есть ли к системе требования, обосновывающие применение МС.

> meaning that we want to keep abstractions to a minimum and only introduce complexity when it provides a significant and real benefit
С этим тезисом в целом согласен - поэтому, например, отказался от чисто архитектуры по дефолту и практически никогда не завожу интерфейсы с одной реализацией.
С другой стороны, не опробовав на практике идею отказаться от сервисов-обёрток вокруг репозов, типа: fun findById(id: Long) = repo.findbyId(id), я снова начинаю склоняться к тому, что они всё-таки нужны для определения публичного интерфейса модуля. Но тут ещё буду думать.

> each class should only have one reason to change, or, they should only have one job
Чувак не понимает SRP
Но при том понимает, что SRP в его интерпретации - вреден - плюсик

Судя по второй картинке - он юзал заголовочные интерфейсы. Понял что это лишнее - плюсик
Судя по ней же - он поклонник карго культа - использует концепцию repository для read model. Насколько я знаю, не существует альтернативной ДДДшной и распространённой концепции репозитория. А в ДДД репозитории используются только для write-модели.

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

> Introducing various programming design patterns before their benefit is really needed is another common pitfall
вот поэтому техлиды должны иметь хотя бы лет 10 опыта - чтобы успеть наигарться во всякие прикольные штуки.
Я паттернами сейчас практически не пользуюсь.
Плюсик, что понял

> Another pattern used extensively is the Command and Publish-Subscribe Pattern
В целом согласен. Я видел как эвент басы используют для вызова методов в одном процессе - это характеризуется "событиями", названы как указания - SendHttpRequest(dest), ровно одним обработчиком "события", катастрофичными последствиями, если событие не будет обработано мгновенно.
Но если вам над расцепить слабосвязанные компоненты (т.е. вам ок, если обработчик сработает завтра) - то эвент бас один из основных инструментов для этого.

#posts@ergonomic_code #ergo_approach@ergonomic_code