Привет!
Периодически гипотезы, лежащие в основе ЭП, рушатся о жестокую реальность промышленной разработки, что приводит к кризисам ЭП, которых уже было три штуки: раз по мотивам проекта Barcoder (решение), два (решение) и три (решение - нафик ООД, ДДД и private внутри одного репоза😀) - по мотивам #project_e.
И вот по мотивам #project_r за последние 5 дней у меня случился и благополучно разрешился очередной кризис ЭП:)
В связи с чем у меня пачка новостей.
Книга
Это уже новость второй свежести, но для контекста надо проговорить - я договорился с менеджером проектов издательства Питер начать с апреля плотную работу над книгой про ЭП. Так что надеюсь, на горизонте пары лет книга увидит свет.
Отказ от ФА
Номинально самая большая новость - я решил отказаться от ФА (которая когда-то была одним из трёх столпов ЭП).
Но по сути ничего не меняется - ЭП всё так же предполагает использование неизменяемых структур данных и максимально возможное разделение логики и ио.
Это просто признание реальности, что в ЭП, который начинался как сильно функциональный, я методично отказываюсь от отличительных черт ФА/ФП:
1. уже очень давно я отказался от монад и ROP-а в пользу защитных условий
2. затем я затащил операции в императивную оболочку
3. во многом по мотивам Проекта Р я вернул в милость выброс исключений вместо возвращения Result
4. по мотивам Проекта Р, я утащил сбалансированную форму системы с архитектурного уровня системы, на локальный уровень отдельных методов
Отказ от SDJ как дефолтной технологии работы с БД
А вот по сути самое больше изменение - я решил отказаться от SDJ в качестве дефолта для работы с БД.
Это всё ёще допустимый в рамках ЭП т.к. его всё ещё легче "продать" заказчикам и коллегам, но по умолчанию я теперь предлагаю использовать какой-то легковесный DSL - jooq или Exposed, ещё не решил что именно.
Это опять же обусловлено опытом Проекта Р - там у меня львиная доля запросов чтения рукописные, потому что SDJ не в состоянии эффективно доставать данные этого проекта, а после того, как мне пришлось ещё и два кастомных метода сохранения написать - стало понятно, что я борюсь с технологией. Этому решению так же поспособствовали пост из канала одного из участников нашей группы.
И решение перейти на UUID-ы, которое так же было обусловлено опытом разработки Проекта Р, где надо сетапать огромные графы объектов в тестах и с генераций ИДов на уровне БД это очень сложно.
Новая версия описания Эргономичной архитектуры
На мой взгляд самая крутая новость - я выложил новый подход к описанию ЭА.
По сути там ничего не изменилось, изменилась только подача.
Но эта новая подача мне настолько нравится, что я решил показать самый первый черновик.
Основная фишка - я отказался от попытки быть как все и уместить архитектуру на одну картинку и ввёл идею проекций. Их три:
1. проекция структуры данных (модель данных) - тут про агрегаты и связи между ними
2. проекция состояния (объектная модель) - тут про объекты в рантайме (порты, операции, ресурсы) и связи между ними
3. проекция структуры поведения (процедурная модель) - тут про методы и связи между ними
Плюс я туда сразу накидал кучу примеров (пока на словах😕), а так же процессы построения всех этих структур и итоговой архитектуры.
Над единой картинкой я тоже ещё подумаю: кажется, судя по проектам физических изделий, где есть проекции по плоскостям плюс изометрия или проекты зданий, где есть тоже должны быть разные проекции и разные слои (с электропроводкой, например) - для ЭА тоже можно что-то такое сделать.
И возвращаясь к книге - эта статья по сути - четверть книги. Заполнить там пробелы, добавить примеры и теоретическая часть по ЭА готова. Вспоминая про бейзкамповский Hill Chart, у меня сейчас такое ощущение, что я достиг холма реализации ЭА и дальше только дело техники. Лишь бы очередной проект не зафейлил очередную гипотезу😄
#the_book@ergonomic_code #functional_architecture@ergonomic_code #ergo_arch@ergonomic_code #ergo_persistance@ergonomic_code #spring_data_jdbc@ergonomic_code
Периодически гипотезы, лежащие в основе ЭП, рушатся о жестокую реальность промышленной разработки, что приводит к кризисам ЭП, которых уже было три штуки: раз по мотивам проекта Barcoder (решение), два (решение) и три (решение - нафик ООД, ДДД и private внутри одного репоза😀) - по мотивам #project_e.
И вот по мотивам #project_r за последние 5 дней у меня случился и благополучно разрешился очередной кризис ЭП:)
В связи с чем у меня пачка новостей.
Книга
Это уже новость второй свежести, но для контекста надо проговорить - я договорился с менеджером проектов издательства Питер начать с апреля плотную работу над книгой про ЭП. Так что надеюсь, на горизонте пары лет книга увидит свет.
Отказ от ФА
Номинально самая большая новость - я решил отказаться от ФА (которая когда-то была одним из трёх столпов ЭП).
Но по сути ничего не меняется - ЭП всё так же предполагает использование неизменяемых структур данных и максимально возможное разделение логики и ио.
Это просто признание реальности, что в ЭП, который начинался как сильно функциональный, я методично отказываюсь от отличительных черт ФА/ФП:
1. уже очень давно я отказался от монад и ROP-а в пользу защитных условий
2. затем я затащил операции в императивную оболочку
3. во многом по мотивам Проекта Р я вернул в милость выброс исключений вместо возвращения Result
4. по мотивам Проекта Р, я утащил сбалансированную форму системы с архитектурного уровня системы, на локальный уровень отдельных методов
Отказ от SDJ как дефолтной технологии работы с БД
А вот по сути самое больше изменение - я решил отказаться от SDJ в качестве дефолта для работы с БД.
Это всё ёще допустимый в рамках ЭП т.к. его всё ещё легче "продать" заказчикам и коллегам, но по умолчанию я теперь предлагаю использовать какой-то легковесный DSL - jooq или Exposed, ещё не решил что именно.
Это опять же обусловлено опытом Проекта Р - там у меня львиная доля запросов чтения рукописные, потому что SDJ не в состоянии эффективно доставать данные этого проекта, а после того, как мне пришлось ещё и два кастомных метода сохранения написать - стало понятно, что я борюсь с технологией. Этому решению так же поспособствовали пост из канала одного из участников нашей группы.
И решение перейти на UUID-ы, которое так же было обусловлено опытом разработки Проекта Р, где надо сетапать огромные графы объектов в тестах и с генераций ИДов на уровне БД это очень сложно.
Новая версия описания Эргономичной архитектуры
На мой взгляд самая крутая новость - я выложил новый подход к описанию ЭА.
По сути там ничего не изменилось, изменилась только подача.
Но эта новая подача мне настолько нравится, что я решил показать самый первый черновик.
Основная фишка - я отказался от попытки быть как все и уместить архитектуру на одну картинку и ввёл идею проекций. Их три:
1. проекция структуры данных (модель данных) - тут про агрегаты и связи между ними
2. проекция состояния (объектная модель) - тут про объекты в рантайме (порты, операции, ресурсы) и связи между ними
3. проекция структуры поведения (процедурная модель) - тут про методы и связи между ними
Плюс я туда сразу накидал кучу примеров (пока на словах😕), а так же процессы построения всех этих структур и итоговой архитектуры.
Над единой картинкой я тоже ещё подумаю: кажется, судя по проектам физических изделий, где есть проекции по плоскостям плюс изометрия или проекты зданий, где есть тоже должны быть разные проекции и разные слои (с электропроводкой, например) - для ЭА тоже можно что-то такое сделать.
И возвращаясь к книге - эта статья по сути - четверть книги. Заполнить там пробелы, добавить примеры и теоретическая часть по ЭА готова. Вспоминая про бейзкамповский Hill Chart, у меня сейчас такое ощущение, что я достиг холма реализации ЭА и дальше только дело техники. Лишь бы очередной проект не зафейлил очередную гипотезу
#the_book@ergonomic_code #functional_architecture@ergonomic_code #ergo_arch@ergonomic_code #ergo_persistance@ergonomic_code #spring_data_jdbc@ergonomic_code
Please open Telegram to view this post
VIEW IN TELEGRAM
1🔥6👍4❤2
Остальные три четверти:
1. Всякая обвязка типа введения/заключения
2. аналогичная штука для архитектуры кодовой базы тестов (тут в целом тоже львиная доля готова, плюс туда надо вписать ещё одну находку из Проекта Р - пресеты фикстур тестов, для сетапа сложных графов)
3. Вымышленная история реализации Trainer Advisor с иллюстрацией теоретических идей и процесса.
Вот такие дела:)
1. Всякая обвязка типа введения/заключения
2. аналогичная штука для архитектуры кодовой базы тестов (тут в целом тоже львиная доля готова, плюс туда надо вписать ещё одну находку из Проекта Р - пресеты фикстур тестов, для сетапа сложных графов)
3. Вымышленная история реализации Trainer Advisor с иллюстрацией теоретических идей и процесса.
Вот такие дела:)
Эргономичный подход
Эргономичная архитектура (v3.0.0)
Текущая версия статьи написана в режиме потока сознания и пока что я не проводил даже проверки правописания, не говоря уж о том, чтобы сопроводить идеи иллюстрациями и кодом.
Предыдущие черновики и диаграммы здесь.
Введение В своей книге The Problem with…
Предыдущие черновики и диаграммы здесь.
Введение В своей книге The Problem with…
🔥8👍2
Привет!
Ток что впервые за 4 года пришлось запилить руками dirty checking в SDJ...
Хотел написать я.
Но уже буквально коммитаясь я в последний момент одуплил, что я поломал основную идею ДДД, SDJ и эргономичного персистанса - у меня одна сущность оказалось частью двух агрегатов.
По бизнес процессу, она сначала появляется в одном агрегате, а потом перемещается во второй агрегат того же типа, но в другую связь (условно - из черновика в основные данные). Добавил удаление ссылки из первого агрегата при перемещении - и обошлось:)
Это же действие, заодно сделало модель более надёжной - черновики меняются на месте и без доп логики, а основные данные с версионированием и приплясками. И в оригинальной модели как раз таки была возможно похачить сущность через черновик без версионирования, а сейчас такой фокус не проканает.
5-ый кризис ЭП пролетел буквально за часик:)
Хотел написать я.
А потом упёрся в то, что есть ещё одна сущность, которую я сделал частью нескольких агрегатов одного типа...
А если учесть, что эта сущность в перспективе будет контрибьютить в инварианты этого типа агрегатов - Проект Р, кажись, не у ЭП, а у ДДД трубу зашатал...
#project_r@ergonomic_code #ddd@ergonomic_code #ergo_persistance@ergonomic_code #spring_data_jdbc@ergonomic_code
Ток что впервые за 4 года пришлось запилить руками dirty checking в SDJ...
Хотел написать я.
Но уже буквально коммитаясь я в последний момент одуплил, что я поломал основную идею ДДД, SDJ и эргономичного персистанса - у меня одна сущность оказалось частью двух агрегатов.
По бизнес процессу, она сначала появляется в одном агрегате, а потом перемещается во второй агрегат того же типа, но в другую связь (условно - из черновика в основные данные). Добавил удаление ссылки из первого агрегата при перемещении - и обошлось:)
Это же действие, заодно сделало модель более надёжной - черновики меняются на месте и без доп логики, а основные данные с версионированием и приплясками. И в оригинальной модели как раз таки была возможно похачить сущность через черновик без версионирования, а сейчас такой фокус не проканает.
5-ый кризис ЭП пролетел буквально за часик:)
Хотел написать я.
А потом упёрся в то, что есть ещё одна сущность, которую я сделал частью нескольких агрегатов одного типа...
А если учесть, что эта сущность в перспективе будет контрибьютить в инварианты этого типа агрегатов - Проект Р, кажись, не у ЭП, а у ДДД трубу зашатал...
#project_r@ergonomic_code #ddd@ergonomic_code #ergo_persistance@ergonomic_code #spring_data_jdbc@ergonomic_code
😱4👍1
Привет!
У нас сегодня праздник: ровно - я подгадал - 5 лет назад, в 11:03 22 февраля 2020 года я нарисовал эту картинку и начал работу над Эргономичным подходом.
За эти годы Эргономичный подход многое потерял (в основном функциональный вайб и юношеский максимализм) и многое нашёл (в основном конкретные инструменты и боевые шрамы) и я хочу отметить этот день небольшой ретроспективой Эргономичного подхода.
У нас сегодня праздник: ровно - я подгадал - 5 лет назад, в 11:03 22 февраля 2020 года я нарисовал эту картинку и начал работу над Эргономичным подходом.
За эти годы Эргономичный подход многое потерял (в основном функциональный вайб и юношеский максимализм) и многое нашёл (в основном конкретные инструменты и боевые шрамы) и я хочу отметить этот день небольшой ретроспективой Эргономичного подхода.
🍾21🔥13👍2
Привет!
Я тут в рамках выбора новой либы для работы с БД решил посмотреть на график контрибьюторов за предыдущий квартал на GitHub-е для основных проектов и там есть несколько любопытных находок:)
1. С диким отрывом лидирует Hibernate - 743 коммита от 4 активных контрибьюторов за октябрь-декабрь 2024 года. Любопытно, что в 21-ом году начал активно коммитать Гэвин Кинг
2. Далее идёт Jimmer - 229 коммита от 3ёх активных контрибьюторов. И там даже есть пара коммитов по строке с фиксом опечаток от Владимира Ситникова:)
3. Почётное 3-е место достаётся jooq-у, где невероятно плодовитый Лукас Эдер в одно лицо нагенерял 196 коммитов
4. MyBatis - 169 коммитов от двух контрибьюторов
5. На пятом месте с большим отрывом от лидеров идёт Exposed c 73 коммитами от 3ёх контрибьюторов
6. Формально, со 135 коммитами пятым должен идти komapper, однако из них 73 - от renovate[bot], поэтому считаем что в этом проекте 57 коммитов от одного контрибьютора
7. По большому счёту делят 7ое место Ebean (42/1), Spring Data Relational (39/2) и JDBI (39/2)
8. На восьмом месте оказались то ли достигшие совершенства, то ли мёртвые QueryDSL и ktorm с 0 коммитов
Я не предлагаю делать каких-то далеко идущих выводов (я даже допускаю, что QueryDSL на самом деле достиг совершенства) - просто немного статпорно вам в утреннюю ленту:)
Ну и за одно может узнаете про какую-нить новую для себя либу или что-то новое про известную. Я, например, про Jimmer давно уже знаю, но не знал, что его настолько активно пилят
Я тут в рамках выбора новой либы для работы с БД решил посмотреть на график контрибьюторов за предыдущий квартал на GitHub-е для основных проектов и там есть несколько любопытных находок:)
1. С диким отрывом лидирует Hibernate - 743 коммита от 4 активных контрибьюторов за октябрь-декабрь 2024 года. Любопытно, что в 21-ом году начал активно коммитать Гэвин Кинг
2. Далее идёт Jimmer - 229 коммита от 3ёх активных контрибьюторов. И там даже есть пара коммитов по строке с фиксом опечаток от Владимира Ситникова:)
3. Почётное 3-е место достаётся jooq-у, где невероятно плодовитый Лукас Эдер в одно лицо нагенерял 196 коммитов
4. MyBatis - 169 коммитов от двух контрибьюторов
5. На пятом месте с большим отрывом от лидеров идёт Exposed c 73 коммитами от 3ёх контрибьюторов
6. Формально, со 135 коммитами пятым должен идти komapper, однако из них 73 - от renovate[bot], поэтому считаем что в этом проекте 57 коммитов от одного контрибьютора
7. По большому счёту делят 7ое место Ebean (42/1), Spring Data Relational (39/2) и JDBI (39/2)
8. На восьмом месте оказались то ли достигшие совершенства, то ли мёртвые QueryDSL и ktorm с 0 коммитов
Я не предлагаю делать каких-то далеко идущих выводов (я даже допускаю, что QueryDSL на самом деле достиг совершенства) - просто немного статпорно вам в утреннюю ленту:)
Ну и за одно может узнаете про какую-нить новую для себя либу или что-то новое про известную. Я, например, про Jimmer давно уже знаю, но не знал, что его настолько активно пилят
GitHub
Contributors to hibernate/hibernate-orm
Hibernate's core Object/Relational Mapping functionality - Contributors to hibernate/hibernate-orm
👍7
Привет!
Зацените какую либульку для тестов накопал - кажется может быть заменой моих ObjectMother-ов.
Сам ещё не пробовал
Зацените какую либульку для тестов накопал - кажется может быть заменой моих ObjectMother-ов.
Сам ещё не пробовал
www.instancio.org
Instancio: Test Data Generator for Java - Instancio
Instancio is a test data generation library for Java. Its goals are to automate data setup, make tests more concise, and reduce test maintenance effort.
👍8🙏2
Привет!
Мне тут на Хабре заминусили коммент про отказ от моков в пользу интеграционного тестирования.
В ответ на это я собрался мокистам ответить подборкой цитат классиков и экспертов по ТДД о моках и оказалось, что у меня её нет.
Теперь есть:)
Берите себе на вооружение, в своей борьбе за простое девелоперское счастье и здоровый ночной сон:)
#posts@ergonomic_code #whynomocks@ergonomic_code #ergo_testing@ergonomic_code
Мне тут на Хабре заминусили коммент про отказ от моков в пользу интеграционного тестирования.
В ответ на это я собрался мокистам ответить подборкой цитат классиков и экспертов по ТДД о моках и оказалось, что у меня её нет.
Теперь есть:)
Берите себе на вооружение, в своей борьбе за простое девелоперское счастье и здоровый ночной сон:)
#posts@ergonomic_code #whynomocks@ergonomic_code #ergo_testing@ergonomic_code
Алексей Жидков
Эксперты об интеграционном тестировании и моках - Алексей Жидков
https://azhidkov.pro/
1👍11🔥6❤4
Привет!
Докинул на вики рыбу статьи с ещё одним костылём для SDJ - как быть, если хочется сослаться на некорневую сущность агрегата.
#ergo_persistance@ergonomic_code #spring_data_jdbc@ergonomic_code #ergowiki@ergonomic_code
Докинул на вики рыбу статьи с ещё одним костылём для SDJ - как быть, если хочется сослаться на некорневую сущность агрегата.
#ergo_persistance@ergonomic_code #spring_data_jdbc@ergonomic_code #ergowiki@ergonomic_code
Эргономичный подход
Ссылки на некорневые сущности (v0.0.0)
По философии DDD идентичностью (глобальным идентификатором) обладают только корни агрегатов, соответственно извне агрегата ссылаться можно только на его корень.
Однако время от времени возникает необходимость сослаться на некорневую сущность агрегата.
Примером…
Однако время от времени возникает необходимость сослаться на некорневую сущность агрегата.
Примером…
👍3
Привет!
Прочитал субстак про Radical Object-Orientation (автор его ещё дописывает)
Имхо - Эргономичная архитектура, только в профиль.
- PoMO - очень напоминает то, что у меня ресурс может быть включен только в один другой ресурс
- IOSP - очень напоминает сбалансированную форму системы
- У него тоже дизайн рекурсивен - атомарная операция ио с точки зрения оркестрации сама может оказаться оркестрацией на своём уровне абстракции
- Так же придерживатеся мнения, что абстракция != public interface - "Integrations are abstractions as well."
- Но у автора всё, включая интеграции - есть объект. У меня, по крайней мере синтаксически, объектами (штуками эксклюзивно владеющими собственными состоянием) являются только ресурсы, а операции - это скрипты которые заимствуют состояние ресурсов и тем самым разделяют его между собой. Но. Всё приложение в целом - можно считать объектом.
Из минусов:
- (Относительно) многа букаф и картинок и очень мало кода, а тот что есть - тривиальный и про консольные приложения
- Аналогия с клетками привлекательная, но не очень... Клетки действительно организуют очень крутые, сложные и адаптивные системы. Которые человечество за миллион человеко-часов понять не может - хотим ли мы поддерживать такие системы?
- А ещё я в #project_r@ergonomic_code опять (но теперь под другим углом) начал сталкиваться с тем, что инкапсуляция состояния плохо масштабируется, так как влечёт неограниченный рост поверхности АПИ ключевых/центральных/фундаментальных объектов-ресусров.
Вердикт: по принципу "повторение - мать учения" и "количество переходит в качество" - советую почитать. Но мне кажется у меня сейчас те же по сути идеи поданы лучше - как минимум у меня довольно много примеров реального кода, а не консольных утилиток.
#posts@ergonomic_code #ergo_approach@ergonomic_code #oop@ergonomic_code
Прочитал субстак про Radical Object-Orientation (автор его ещё дописывает)
Имхо - Эргономичная архитектура, только в профиль.
- PoMO - очень напоминает то, что у меня ресурс может быть включен только в один другой ресурс
- IOSP - очень напоминает сбалансированную форму системы
- У него тоже дизайн рекурсивен - атомарная операция ио с точки зрения оркестрации сама может оказаться оркестрацией на своём уровне абстракции
- Так же придерживатеся мнения, что абстракция != public interface - "Integrations are abstractions as well."
- Но у автора всё, включая интеграции - есть объект. У меня, по крайней мере синтаксически, объектами (штуками эксклюзивно владеющими собственными состоянием) являются только ресурсы, а операции - это скрипты которые заимствуют состояние ресурсов и тем самым разделяют его между собой. Но. Всё приложение в целом - можно считать объектом.
Из минусов:
- (Относительно) многа букаф и картинок и очень мало кода, а тот что есть - тривиальный и про консольные приложения
- Аналогия с клетками привлекательная, но не очень... Клетки действительно организуют очень крутые, сложные и адаптивные системы. Которые человечество за миллион человеко-часов понять не может - хотим ли мы поддерживать такие системы?
- А ещё я в #project_r@ergonomic_code опять (но теперь под другим углом) начал сталкиваться с тем, что инкапсуляция состояния плохо масштабируется, так как влечёт неограниченный рост поверхности АПИ ключевых/центральных/фундаментальных объектов-ресусров.
Вердикт: по принципу "повторение - мать учения" и "количество переходит в качество" - советую почитать. Но мне кажется у меня сейчас те же по сути идеи поданы лучше - как минимум у меня довольно много примеров реального кода, а не консольных утилиток.
#posts@ergonomic_code #ergo_approach@ergonomic_code #oop@ergonomic_code
Substack
Radical Object-Orientation | Ralf Westphal | Substack
Object-orientation grown from its roots. Click to read Radical Object-Orientation, by Ralf Westphal, a Substack publication with hundreds of subscribers.
👍8
Привет!
#project_r подходит к концу и я ищу для себя новый проект по разработке веб-приложения, веб-сервиса или бакэнда мобильного приложения на JVM-стеке (Kotlin, Java).
Могу собрать команду и сделать проект "под ключ", могу выстроить эффективный процесс разработки в существующей команде, могу писать код.
Рассматриваю варианты работы по договору с ИП, договору ГПХ и трудовому договору.
Если вам или кому из ваших знакомых нужен хорошо сделанный бакэнд - приходите в личку, пожалуйста:)
Буду благодарен за репост.
#project_r подходит к концу и я ищу для себя новый проект по разработке веб-приложения, веб-сервиса или бакэнда мобильного приложения на JVM-стеке (Kotlin, Java).
Могу собрать команду и сделать проект "под ключ", могу выстроить эффективный процесс разработки в существующей команде, могу писать код.
Рассматриваю варианты работы по договору с ИП, договору ГПХ и трудовому договору.
Если вам или кому из ваших знакомых нужен хорошо сделанный бакэнд - приходите в личку, пожалуйста:)
Буду благодарен за репост.
🔥9👍5
Привет!
Реклама
Как сервисам взаимодействовать между собой надёжно, быстро и понятно?
REST, gRPC, события, контракты, версии — деталей много, а универсальных решений нет.
На онлайн-конференции Podlodka Techlead Crew (7–11 апреля) разберёмся, как выстраивать межсервисное взаимодействие: от проектирования API до публикации событий и сравнения протоколов.
В программе:
🎯 Event Storming + DDD: проектируем EDA правильно — Кирилл Ветчинкин расскажет, как выделять правильные события, избавляться от синхронных вызовов и строить событийно-ориентированные системы без боли
🔄 Обратная совместимость в парадигме specification-first — Сергей Константинов покажет, как поддерживать REST API и работать со спецификациями типа OpenAPI
🎙Интервью: Проектируем API — contract first — Илья Зонов поделится, когда этот подход спасает, а когда мешает. И как версионировать API без боли
⚔️ gRPC vs RESTful: битва протоколов — Алексей Романов сравнит два подхода по 10 критериям
Готовы прокачаться?
Билеты здесь🎟
Реклама
Как сервисам взаимодействовать между собой надёжно, быстро и понятно?
REST, gRPC, события, контракты, версии — деталей много, а универсальных решений нет.
На онлайн-конференции Podlodka Techlead Crew (7–11 апреля) разберёмся, как выстраивать межсервисное взаимодействие: от проектирования API до публикации событий и сравнения протоколов.
В программе:
🎯 Event Storming + DDD: проектируем EDA правильно — Кирилл Ветчинкин расскажет, как выделять правильные события, избавляться от синхронных вызовов и строить событийно-ориентированные системы без боли
🔄 Обратная совместимость в парадигме specification-first — Сергей Константинов покажет, как поддерживать REST API и работать со спецификациями типа OpenAPI
🎙Интервью: Проектируем API — contract first — Илья Зонов поделится, когда этот подход спасает, а когда мешает. И как версионировать API без боли
⚔️ gRPC vs RESTful: битва протоколов — Алексей Романов сравнит два подхода по 10 критериям
Готовы прокачаться?
Билеты здесь🎟
podlodka.io
Онлайн-конференция Podlodka Teсhlead Crew #10
Недельное мероприятие от команды Podlodka: ежедневные интерактивные сессии в Zoom по актуальным проблемам techlead-разработки, нон-стоп общение с экспертами и звёздами индустрии, закрытое профессиональное сообщество в Telegram.
Привет!
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
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
❤3👍2
Привет!
Баги, найденные командой QA это:
Баги, найденные командой QA это:
Anonymous Poll
89%
Да норм, не в проде же
11%
Это катастрофа, стыд и позор - девелоперы шипают лажу и куча времени тратится на связанные оверхеды
Эргономичный код
Привет!
Баги, найденные командой QA это:
Баги, найденные командой QA это:
Понимаю, что на самом деле сильно зависит от, но хочу понять общее отношение к багам в сообществе - выберите вариант который вам по духу ближе, пожалуйста.
#ergo_testing@ergonomic_code
#ergo_testing@ergonomic_code
Привет!
Начинаю потихоньку собирать отзывы по #project_r.
Начал с простого - спросил у второго разработчика, которая раньше на Котлин не писала: "Какие у тебя впечатления от Котлина? Не появилось непреодолимого желания переехать на него?:)"
Ответ:
Выделение моё.
В общем если пишите на Java и сомневаетесь нужен ли вам Kotlin - попробуйте:)
#retro@ergonomic_code #project_r@ergonomic_code #kotlin@ergonomic_code
Начинаю потихоньку собирать отзывы по #project_r.
Начал с простого - спросил у второго разработчика, которая раньше на Котлин не писала: "Какие у тебя впечатления от Котлина? Не появилось непреодолимого желания переехать на него?:)"
Ответ:
только положительные 😀
очень много рутиных вещей из джавы уже есть в готовых функциях, читаемость намного лучше, легче конструкции логические всякие городить)
А про переехать 🤔
Если бы меня отправили работать в микросервис на котлине, я бы точно фу не сказала, спокойно бы писала, как и на джаве)
Выделение моё.
В общем если пишите на Java и сомневаетесь нужен ли вам Kotlin - попробуйте:)
#retro@ergonomic_code #project_r@ergonomic_code #kotlin@ergonomic_code
👍7💯6
Привет!
Продолжаю ретроспективить #project_r@ergonomic_code.
Подбил Джиру, собрал немного статистики:
1. всего задач по проекту: 223 - сюда входят и задачи на разработку, и баги, и мусорные задачи и метазадачи
2. задач на разработку по бэку проекта Р: 65
3. багов в бэке проекта Р: 12
4. регрессий в бэке проекта Р: 4
5. всего задач на разработку по бэку основного сервиса: 23
6. всего багов в беке основного сервиса: 28
7. всего регрессий в беке основного сервиса: 3
8. моих задач на разработку по бэку основного проекта: 6
9. моих багов в бэке основного проекта: 5
10. моих регрессий в бэке основного проекта: 2
Это упражнение я проделал для того чтобы проверить тезис "Применение ЭП снижает количество ошибок" и я получил очередное свидетельство этому:
1. отношение задач к ошибкам в сервисе по ЭП: 16/65 = 0.25
2. отношение задач к ошибкам в сервисе не по ЭП: 31/23 = 1.35
3. отношение моих задач к ошибкам в сервисе не по ЭП: 7/6 = 1.17
Тут по цифрам вообще выходит, что багов в 4-5 раз меньше, но, имхо, стоит сделать скидку на мою предвзятость в анализе и не учтённые факторы и сделать более консервативный вывод, что ЭП снижает количество ошибок в 2-3 раза.
Вопрос в том, стоит ли оно того - как показал опрос, большинство разработчиков не видит проблем в ошибках.
По хорошему, чтобы ответить на него, надо как-то привязаться к срокам и деньгам, но в этом проекте сделать этого не получится:
1. наверное, стоит начать с того, что по срокам мы тотально зафейлились🥲 Но по моему мнению, любой другой подход дал бы тот же результат
2. у меня есть данные только по своим трудозатратам, а в проекте участвовали ещё два разработчика
3. нет референса, к которому можно было бы привязаться.
#retro@ergonomic_code #project_r@ergonomic_code #case@ergonomic_code
Продолжаю ретроспективить #project_r@ergonomic_code.
Подбил Джиру, собрал немного статистики:
1. всего задач по проекту: 223 - сюда входят и задачи на разработку, и баги, и мусорные задачи и метазадачи
2. задач на разработку по бэку проекта Р: 65
3. багов в бэке проекта Р: 12
4. регрессий в бэке проекта Р: 4
5. всего задач на разработку по бэку основного сервиса: 23
6. всего багов в беке основного сервиса: 28
7. всего регрессий в беке основного сервиса: 3
8. моих задач на разработку по бэку основного проекта: 6
9. моих багов в бэке основного проекта: 5
10. моих регрессий в бэке основного проекта: 2
Это упражнение я проделал для того чтобы проверить тезис "Применение ЭП снижает количество ошибок" и я получил очередное свидетельство этому:
1. отношение задач к ошибкам в сервисе по ЭП: 16/65 = 0.25
2. отношение задач к ошибкам в сервисе не по ЭП: 31/23 = 1.35
3. отношение моих задач к ошибкам в сервисе не по ЭП: 7/6 = 1.17
Тут по цифрам вообще выходит, что багов в 4-5 раз меньше, но, имхо, стоит сделать скидку на мою предвзятость в анализе и не учтённые факторы и сделать более консервативный вывод, что ЭП снижает количество ошибок в 2-3 раза.
Вопрос в том, стоит ли оно того - как показал опрос, большинство разработчиков не видит проблем в ошибках.
По хорошему, чтобы ответить на него, надо как-то привязаться к срокам и деньгам, но в этом проекте сделать этого не получится:
1. наверное, стоит начать с того, что по срокам мы тотально зафейлились🥲 Но по моему мнению, любой другой подход дал бы тот же результат
2. у меня есть данные только по своим трудозатратам, а в проекте участвовали ещё два разработчика
3. нет референса, к которому можно было бы привязаться.
#retro@ergonomic_code #project_r@ergonomic_code #case@ergonomic_code
🔥5👍4
Привет!
Соскучились? Это затишье перед бурей - у меня зреет сразу три большие новости:)
Но новости будут в мае, а пока пара ссылок.
Я в последнее время много думаю о том, как мне железобетонно обосновать пользу применения ЭП и пока не придумал.
А сегодня наткнулся на то, что у Фаулера были примерно те же проблемы 20 лет назад.
В статье 2007 Design Stamina Hypothesis, он рисует "псевдографик", на котором задизайненная система довольно быстро (в течении недель) начинает обгонять по объёму фич, незадезайненную. Тем самым обосновывая дизайн системы (например по ЭП).
Я про себя уже начал мондеть, что наткнулся на очередную картинку из головы, но парой абзацев ниже Фаулер сам начал оправдываться, что это гипотеза, и с научной точки зрения паршивая гипотеза. Потому что её невозможно проверить.
А проверить её невозможно, потому что по его (и моему) мнению из 2003 года эффективность разработки надо оценивать как <увеличение выручки бизнеса> - <стоимость разработки>. Но как привязать увеличение выручки к реализованной фичи - хз.
#posts@ergonomic_code
Соскучились? Это затишье перед бурей - у меня зреет сразу три большие новости:)
Но новости будут в мае, а пока пара ссылок.
Я в последнее время много думаю о том, как мне железобетонно обосновать пользу применения ЭП и пока не придумал.
А сегодня наткнулся на то, что у Фаулера были примерно те же проблемы 20 лет назад.
В статье 2007 Design Stamina Hypothesis, он рисует "псевдографик", на котором задизайненная система довольно быстро (в течении недель) начинает обгонять по объёму фич, незадезайненную. Тем самым обосновывая дизайн системы (например по ЭП).
Я про себя уже начал мондеть, что наткнулся на очередную картинку из головы, но парой абзацев ниже Фаулер сам начал оправдываться, что это гипотеза, и с научной точки зрения паршивая гипотеза. Потому что её невозможно проверить.
А проверить её невозможно, потому что по его (и моему) мнению из 2003 года эффективность разработки надо оценивать как <увеличение выручки бизнеса> - <стоимость разработки>. Но как привязать увеличение выручки к реализованной фичи - хз.
#posts@ergonomic_code
martinfowler.com
bliki: Design Stamina Hypothesis
The value of good software design is economic: you can continue to add new functionality quickly even as the code-base grows in size.
👍4🔥3
Ну и за одно полезняшка - рыба статьи на вики о том как поддержать мультитенантность на базе схем в Spring Data JDBC. Основана на опыте её реализации в #project_r
#spring_data_jdbc@ergonomic_code #ergowiki@ergonomic_code #project_r@ergonomic_code
#spring_data_jdbc@ergonomic_code #ergowiki@ergonomic_code #project_r@ergonomic_code
Эргономичный подход
Мультитенантность на основе схем (v0.0.0)
Для того чтобы поддержать мультитенантность на основе схем, глобально надо сделать три вещи:
Опционально: завести кастомную аннотацию для бинов обеспечиваюищих мультитенантный режим
Завести ресурс/инфраструктурный компонент, который будет хранить тенанта…
Опционально: завести кастомную аннотацию для бинов обеспечиваюищих мультитенантный режим
Завести ресурс/инфраструктурный компонент, который будет хранить тенанта…
👍3🔥3
Привет!
Полезняшка. А для кого-то может и целых три за раз:)
Если вы не знали - с одним гит-репозом можно использовать несколько рабочих деревьев. Которые будут разделять между собой директорию .git.
Это экономит место на диске (и время синхронизации в облако, если пользуетесь) и позволяет фетчить origin только один раз.
Я этим активно пользуюсь - у меня всегда есть ворктри для основной текущей задачи, для быстрых фиксов, и для ревью каждого члена команды. Соответственно между всеми этим активностями можно переключаться по щелку. И не чертыхаться каждый раз, что надо зафетчиться.
А ещё если не знали - для Gradle есть плагин, который позволяет закинуть в проект git.properties-файл с инфой о сборке (дата, ветка, тэг, автор и т.д.), который можно добыть в рантайме через Actuator.
Ноесть была проблема - плагин не умеет в worktrees и по дефолту взрывает всю сборку при запуске из директории со вторичной копией.
Я года 4 хачил это комментированием плагина во вторчных директориях. И раза три это случайно коммитал и откатывал.
И вот наконец написал 8 строк, которые костыляют эту проблему аккуратнее
Важное уточнение - это именно костыль и в git.properties при этом попадут данные из основной рабочей директории, а не той, где была запущена сборка
#tools@ergonomic_code #tips@ergonomic_code #git@ergonomic_code
Полезняшка. А для кого-то может и целых три за раз:)
Если вы не знали - с одним гит-репозом можно использовать несколько рабочих деревьев. Которые будут разделять между собой директорию .git.
Это экономит место на диске (и время синхронизации в облако, если пользуетесь) и позволяет фетчить origin только один раз.
Я этим активно пользуюсь - у меня всегда есть ворктри для основной текущей задачи, для быстрых фиксов, и для ревью каждого члена команды. Соответственно между всеми этим активностями можно переключаться по щелку. И не чертыхаться каждый раз, что надо зафетчиться.
А ещё если не знали - для Gradle есть плагин, который позволяет закинуть в проект git.properties-файл с инфой о сборке (дата, ветка, тэг, автор и т.д.), который можно добыть в рантайме через Actuator.
Но
Я года 4 хачил это комментированием плагина во вторчных директориях. И раза три это случайно коммитал и откатывал.
И вот наконец написал 8 строк, которые костыляют эту проблему аккуратнее
// build.gradle.kts
gitProperties {
val dotGit = File(".git")
if (dotGit.isFile) {
val actualGitDir = dotGit.readText().substringAfter("gitdir: ").substringBefore("/worktrees")
this.dotGitDirectory.set(File(actualGitDir))
}
}
Важное уточнение - это именно костыль и в git.properties при этом попадут данные из основной рабочей директории, а не той, где была запущена сборка
#tools@ergonomic_code #tips@ergonomic_code #git@ergonomic_code
👍6🔥4
Привет!
Что-то последняя большая новость никак не дозреет, поэтому пока расскажу о двух созревших.
Новость №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
Что-то последняя большая новость никак не дозреет, поэтому пока расскажу о двух созревших.
Новость №1
В Trainer Advisor появился второй живой пользователь.
Из хорошего для ЭП это значит, что публичный демо проект стал решать больше реальных проблем реальных людей и, как следствие, стал чуть более приближенным к реальной жизни и чуть более показательным.
А из плохого - фича-реквестов и найденных багов стало в два раза больше, поэтому он стал в два раза активнее требовать моего времени, которое я могу добыть только за счёт сокращения работы над каналом в частности и ЭП в целом.
Тут хочу напомнить, что ко мне можно попасть на менторинг за
Там по началу надо будет починить пару мелких багов/фич (например этот и эту) чтобы познакомиться с проектом и процессами, а потом в бэклоге у меня пачка на мой взгляд интересных и познавательных задач: интеграция с 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
Алексей Жидков
Книга: первая версия плана - Алексей Жидков
https://azhidkov.pro/
👍17🔥3❤2
Привет!
#why_kotlin@ergonomic_code #talks@ergonomic_code
Тогда я решил посмотреть на Котлин. И больше не оглядывался [на Java]
— Род Джонсонс, создатель Spring Framework, Kotlin Conf 2025
#why_kotlin@ergonomic_code #talks@ergonomic_code
😱5👍1