Привет!

Линко-пост

Прикольный "научпопный" доклад для задро... нердов с версией о том, почему ООП стало мейнстримом, а ФП - (пока) нет. Спойлер - случайно и не на всегда:)

Только мужик говорит быстро и слушать сложно:(

Поэтому вот ещё ссылка из доклада на тему ОО/П.

Ну а для совсем ленивых, мой главный инсайт из этой статьи:
> Alan Kay was interested in personal computing. His work on FLEX, the Dynabook, and Smalltalk all revolve around that. In his vision, the PC would be a something totally under the user’s control, everything from core system logic to the graphic rendering tweakable and explorable at runtime. Message passing and late binding solve a lot of problems here. If a kid installs a new game, should they have to recompile the entire OS to use the new program? No: make it so that you can send any arbitrary message to any object and rely on runtime protocol-handling to fix it.1 If a person clobbers the sound logic, should the whole OS crash? Of course not, so allow objects to decide how to handle messages themselves. This is a place where objects shine.

Ole-Johan Dahl and Kristen Nygaard were trying to solve a completely different problem. They were interested in simulation. One of the case studies in the Simula manual is modeling the spread of infection across a fixed population. The system is completely closed: you have a fixed set of code, you run your simulation, you get your output. For them, message passing isn’t useful. But things like being able to define simulations in terms of other simulations, specialize entities, and model time as a first-class object are incredibly useful. This is also a place where objects shine!

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

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

#talks@ergonomic_code #oop@ergonomic_code #fp@ergonomic_code

Привет!

Продолжаю в фоне размышлять о том является ли RPC over RabbitMQ антипаттерном, нагенерял ещё пару мыслей, делюсь.

Нетиповое решение
Я сейчас читаю Building Microservices (кстати, очень крутая книга - в первой же главе пишет что МС это боль и надо начинать с монолита) и там типовым решением для синхронного стиля пишут HTTP/RPC (картинка)

Стримминг
В рамках работы над этим чудо проектом в один момент показалось, что мне нужен стриминг большого объёма данных из одного МС в другой. В итоге обошлось но если бы не обошлось, то на HTTP я бы это без вопросов сделал, а с очередью бы ой вышел

Разделение АПИ
Ещё подумал, что плюсом такого решения является явное разделение АПИ на публичное и приватное. Но на HTTP это тоже можно провернуть (сам не пробовал)

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

#case@ergonomic_code

Привет!

Выкинул "первый черновик" (который был на самом деле первой доведённой до конца попыткой) поста с обоснованием декомпозиции на базе диаграммы эффектов.

Написал очередную версию и, кажется (хоть бы, хоть бы) в этот раз наконец успех.

Заодно находка-любопытка. Вы читали Чистый код анкл Боба? В частности раздел "Антисимметрия данных/объектов"?

Там любопытное написано:
> Процедурный код (код, использующий структуры данных) позволяет легко добавлять новые функции без изменения существующих структур данных. Объектно-ориентированный код, напротив, упрощает добавление новых классов без изменения существующих функций.

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

Вам не кажется, что в информационных системах чаще требуется добавлять новые функции, чем (варианты) типов данных?

Но в этом случае, естественно, ещё лучше функциональный код и неизменяемые структуры данных

#oop@ergonomic_code #dop@ergonomic_code

Привет!

А вот и Фаулер советует стартовать с монолита

Из статьи достаточно прочитать две фразы:
1) Almost all the successful microservice stories have started with a monolith that got too big and was broken up
2) Almost all the cases where I've heard of a system that was built as a microservice system from scratch, it has ended up in serious trouble.

1) Практически все микросервисные истории начинались с монолита, который вырос слишком большим и был разбит (на микросервисы)
2) Практически все случаи, о которых я слышал, где начинали с микросервисов, закончились серьёзными проблемами

#posts@ergonomic_code #why_no_microservices@ergonomic_code

Привет!

Прочитал Building Microservices: Designing Fine-Grained Systems - редкая книга, с содержанием которой я согласен без всяких но, рекомендую:)

#books@ergonomic_code

Привет!

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

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

#posts@ergonomic_code #ergo_approach@ergonomic_code #ergo_arch@ergonomic_code

Привет!

Свинья везде найдёт грязь, а я - в любой книжке по ООП агитацию за ФП.

В рамках подготовки поста об ОО декомпозиции полез кое-чего глянуть в Object-Oriented Software Construction. И пока искал, наткнулся на раздел "23.1 SIDE EFFECTS IN FUNCTIONS". Там достаточно хорошо описано что такое побочный эффект, чем он опасен и как отделять чистые функции от функций с эффектом (это тот самый CQS, если вы понимаете о чём я).

И вообще в этой книге много мудрости, например OCP анкл Боб взял оттуда (хотя и подменил суть, по большому счёту).

Единственное что, Мейер там сильно заблуждается на счёт значимости и практики применения механизма наследования, но это всеобщее помутнение сознания тех лет (конца 80-ых) и вполне простительно.

В общем рекомендую почитать на досуге.

#books@ergonomic_code #whyfp@ergonomic_code #oop@ergonomic_code

Привет!

Опубликовал пост о подходах к декомпозиции

#posts@ergonomic_code #ergo_approach@ergonomic_code #ergo_arch@ergonomic_code

Привет!

Наткунлся на обновлённую версию доклада Simple Made Ease с русскими субтитрами.
Доклад очень крутой, советую посмотреть, тем кто ещё не смотрел

#talks@ergonomic_code #fp@ergonomic_code #clojure@ergonomic_code

Привет!

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

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

#docs@ergonomic_code #spring@ergonomic_code #http_api@ergonomic_code #rest_api@ergonomic_code

Привет!

Довольно часто встречаю у студентов и молодых разработчиков ошибку добавления ИД в таблицу связку: user_roles(id, user_id, role_id).
Раньше я в таких случаях из чисто на основе интуиции говорил "лучше убрать и заменить на составной ключ, потому что ИД нафик не нужен и чуть лишней памяти жрёт".

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

#posts@ergonomic_code #relational_model@ergonomic_code

Привет!

Решил взять небольшую паузу в постах и немного позаниматься технической работой.

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

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

Привет!

Я тут вынашиваю страшный план - отказаться от REST-стиля в "бэке одного фронта".

Как я собираюсь это делать:
1) Ядро продолжать так же делать из подсистем-объектов
2) Вокруг ядра сделать слой app, где по конторллеру на каждую страницу/экран/вью
3) урлы будут вида /api/app/login-page/login, api/app/dashboard-page/get-init-data
В общем в некотором смысле вернуться к структуре из этого поста, но сервисы приложения смёржить с контроллерами. Ну либо к пакетированию по компонентам Брауна

Что надеюсь получить:
1) Упростить процесс проектирования. Я давно этим занимаюсь и прочитал пачку книг по РЕСТу, но всё равно буквально в каждом проекте вылазит какая-нибудь штука, над которой я долго грею голову
2) снизить сцепленность ядра. в моём текущем подходе зачастую в подсистему надо тащить зависимость на другую подсистему, только для того чтобы вытащить вложенную сущность для какой-нить админки
3) Повысить удобство для фронтендеров - у них постоянно возникают вопросы что откуда брать для данной конкретной страницы. Тут, надеюсь, не будет. Плюс в доках появится понятное место куда можно будет сиквенс диаграммы работы страницы воткнуть
4) Повысить производительность. Как засунуть в рест один запрос для формы ввода, который вернёт пачку справочников для выпадающего списка - я не очень понимаю. А в эту схему - очень понимаю

Что потеряю и как планирую нивелировать потери
1) идиоматичность. С РЕСТом в целом народ как-то уже разобрался, а тут опять какая-то непонятная хрень. Это я попробую нивелировать за счёт простоты, возможности перенести общие принципы проектирования и постами с описанием идеи и кейсов
2) универсальность. Новому клиенту может не подойти существующее АПИ. Для второго клиента можно будет завести свой набор методов, а для третьего уже спроектировать и прикрутить сверху REST апи

Пока не очень понимаю что делать с методами, которые нужны на разных страницах. Но есть несколько идей:
1) по факту дублировать эндпоинты для них с минимизацией дублирования кода через делегирование в Котлине (и кстати о Котлине - я последнее время работаю с .net и чёт прям устал от NullPointerException - хочу назад в налло-безопстность 😥)
2) оставить такие методы в ядре
3) завести понятие ui-компонента на бэке - урлы вида /api/app/image-component/load

Я пока ещё думаю на эту тему и не уверен, что пойду туда, но возможно в ближайшем времени опробую её на личном проекте. И если опробую - расскажу как впечатления:)

#http_api@ergonomic_code #rest_api@ergonomic_code #ergo_approach@ergonomic_code

Привет!

Соскучились? Я тоже:)

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

#posts@ergonomic_code

Привет!

Я почти доделал лендинг для Диаграммы Эффектов, но его надо ещё пополировать.

Зато под руку подвернулась хорошая линка про то, как писать доки:)

#posts@ergonomic_code

Привет!

Java 19 зарелизали О_О
ещё недавно ток 17ая была
сколько между 7ой и 8ой лет прошло? 4?
Щяс даже Котлин, кажись, раз в год релизается

Туда ещё и структурную канкаренси в инкубаторе впихнули О_О
так глядишь, году к 30, на юбилейной 30ой джаве можно будет жить почти как на Котлине

#tools@ergonomic_code #java@ergonomic_code

Привет!

По ряду причин сейчас нет ресурса на Эргономичный подход, но внезапно PR-повод подъехал с другой стороны:)

Если и вам надо сделать работу быстро и всё равно достаточно хорошо - приходите, свободные специалисты у меня есть

#ergo_approach@ergonomic_code #why_ergo_approach@ergonomic_code

Привет!

Раскрою одну из причин, почему я приостановил проработку Эргономичного подхода.

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

Я уже несколько раз упоминал в этом канале, что мне достался на саппорт и вывод в прод легась на дотнете. Так вот я умудрился сделать финт ушами и сначала продать РП идею переписывания его по ЭП на Котлине, потом вместе с РП и клиенту. На этом я и буду сфокусирован в ближайшие 4-5 месяцев.

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

Объём проекта:
1) примерно человеко-год разработки
2) 42 таблицы
3) 100+ рест эндпоинтов
4) 14 микросервисов

Ключевые проблемы проекта:
1) 0 (ноль) тестов
2) микросервисы. В данном случае они не решают никаких проблем
3) плохая нарезка на микросервисы.
3.1) Больше всего меня поразил метод генерации отчётов, который задействует 5 (пять) микросервисов. А если считать предварительную генерацию токена доступа, то 6
3.2) В целом практически каждый рест эндпоинт в своей работе идёт в 1-2 микросервиса
4) Библиотека shared, задействованная во всех МСах и ещё больше сцепляющая их
5) Взаимодействие между микросервисами на базе RabbitMQ и с протоколом в shared. В результате его сложно дебажить, а изменение нового требует кучу церемоний (поправить shared, собрать-опбликовать, обновить зависимость сервера, обновить сервер, обновить зависимость клиента, обновить клиент, выкатывать их строго вместе)
6) Вертикальная архитектура на базе MediatR. Даже самый простой эндопоинт требует пачку лишних приседаний - класс команды, класс обработчика, класс ответа, класс содержания ответа.
7) По определённым причинам проект заморозили в 19ом году, и он остался на устаревшей и более не поддерживаемой версии дотнета
8) У меня в команде нет экспертизы дотнета

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

Как я собираюсь это делать.
В подробностях я пока не спланировал работы, но в общих чертах план примерно следующий:
1) Мы в ближайшее время выводим в прод текущую версию
2) Сейчас у нас основные работы ведутся по созданию админ-панели к системе и часть АПИ мы уже сделали на дотнете, но на прошлой недели я начал заводить бэк на Котлине и в следующем релизе админку мы уже будем делать на Котлине
3) Все новые методы будем делать на Котлине
4) Все большие баги переписывать на Котлин и фиксать там (?)
5) Параллельно в обратном направлении графа зависимостей МСов методично всё переписывать и покрывать тестами. Выкатывать обновлённые методы будем каждый спринт

Сколько это стоит
Точную цифру я не назову, по понятным, причинам, но я планирую осилить эту работу за 3-4 месяца силами себя и двух джунов

Как я буду оценивать результаты
Для меня успех выглядит так: РП и заказчик отвечают утвердительно на вопрос "Видите ли вы на глаз как минимум удвоение скорости разработки?". Понятно, что это субъективно, но это именно то, что я продаю.
Кроме того, я посмотрю кол-во багов и регрессий, а так же среднее время задачи от "In Progress" до "Done" за месяц работы "до" и "после".
Если РП и клиент заметят удвоение на глаз и оно подтвердиться цифра - это будет оглушительный успех
Если РП и клиент не заметят удвоения, а на цифрах оно будет - пойду учиться доносить результаты
Если наоборот - можно так и оставить 😂
Если РП и клиент не заметят удвоения и это не подтвердиться цифрами - ну всё, расходимся

Касательно проработки ЭП - как только я выведу в прод этот проект и у меня устаканится ещё пара моментов, я надеюсь вернуться к практике "30 минут ЭП в день" и потихоньку продолжить двигать и эту тему.

Вот такие дела, пожелайте мне удачи:)

#project_e@ergonomic_code

Привет!

Я тут тихой сапой перечитал рекламирую мной структуру и интерпретацию компьютерных программ.
И я несколько поменял своё мнение о ней. В целом книга действительно крутая и рассматривает все ключевые вопросы программирования.
Однако, на мой взгляд, относительно просто перенести на реальную практику только первые 3 главы, посвящённые общим понятиям программирования.
А вот главы про интерпретацию и компиляцию перенести на реальную практику довольно сложно, если вы ещё не понимаете как это работает.

Наверное поэтому недавно выпустили редакцию с примерами на JavaScript (только на английском). Я её сам не читал, но может быть её будет проще перенести на реальную практику.

Ну и подтверждаю, что русскую версию можно смело читать.

Итого, вердикт:
1) Книга крутая, рекомендую к прочтению как минимум первые 3 главы
2) Главы 4-5 оригинальной версии не факт, что зайдут и будут полезны
3) Можно попробовать прочитать версию на JS-е, скорее всего так будет проще, если вы не умеете в лисп, или не собираетесь глубоко проштудировать эту книгу, с набором всех примеров и выполнением упражнений

#books@ergonomic_code

Утащил текст про xUnit Patterns в телеграф: https://telegra.ph/Strategiya-testirovaniya-kotoraya-srabotaet-dlya-bolshnistva-proektov-10-13