Привет!
Прочитал The Problem with Software: Why Smart Engineers Write Bad Code - не однозначная книга.
С одной стороны - я не понимаю для кого она и зачем.
Автор явно разжевывает работу программистов для не программистов.
И рассматривает всё подряд - go to, слоёную архитектуру, объекты, аджайл, обработку ошибок и исключения.
При том разжевывает до такой степени, что объясняет как устроен стек, чтобы объяснить как переполнение локальных массивов в Си позволяет писать вредоносы.
И в целом вроде даёт ответ на вопрос из названия: потому что все - научное сообщество, коммерческие компании и сами разработчики забили на научный подход. Но толком не предлагает решения этой проблемы.
С другой стороны книга написана хорошо и я с интересом её читал.
Советую её прочитать, если вы:
1. не закончили профильный вуз и не писали на Си и/или трансляторы - там как раз такие кишочки есть, что, на мой взгляд полезно разработчику. Хотя автор как раз считает иначе 😂
2. не программист, но вам очень любопытно как работа программиста устроена внутри - похоже вы один из двух людей в мире, являющихся целевой аудиторией этой книги 😂
3. любите историю - в книге многое говориться о становлении индустрии
4. любите древние книги и научные статьи - в тексте прям миллион ссылок на всё подряд
Мой текущий пост (который уже на стадии финальной полировки) очень хорошо иллюстрирует посыл этой книги - в нём есть такие строки:
То бишь сначала анкл Боб бездоказательно заявляет, что в системах будут появляться новые устройства, а потом я так же бездоказательно заявляю, что не будут. Твоё слово против моего, встретимся в суде. Так и живут "инженеры" от современного ИТ...:)
#books@ergonomic_code
Прочитал The Problem with Software: Why Smart Engineers Write Bad Code - не однозначная книга.
С одной стороны - я не понимаю для кого она и зачем.
Автор явно разжевывает работу программистов для не программистов.
И рассматривает всё подряд - go to, слоёную архитектуру, объекты, аджайл, обработку ошибок и исключения.
При том разжевывает до такой степени, что объясняет как устроен стек, чтобы объяснить как переполнение локальных массивов в Си позволяет писать вредоносы.
И в целом вроде даёт ответ на вопрос из названия: потому что все - научное сообщество, коммерческие компании и сами разработчики забили на научный подход. Но толком не предлагает решения этой проблемы.
С другой стороны книга написана хорошо и я с интересом её читал.
Советую её прочитать, если вы:
1. не закончили профильный вуз и не писали на Си и/или трансляторы - там как раз такие кишочки есть, что, на мой взгляд полезно разработчику. Хотя автор как раз считает иначе 😂
2. не программист, но вам очень любопытно как работа программиста устроена внутри - похоже вы один из двух людей в мире, являющихся целевой аудиторией этой книги 😂
3. любите историю - в книге многое говориться о становлении индустрии
4. любите древние книги и научные статьи - в тексте прям миллион ссылок на всё подряд
Мой текущий пост (который уже на стадии финальной полировки) очень хорошо иллюстрирует посыл этой книги - в нём есть такие строки:
И [анкл Боб] тут же говорит - это плохой код, который вносит новые зависимости в систему, и по мере развития системы и появления новых устройств в ней будет появляться всё больше зависимостей. И в итоге система станет жёсткой и хрупкой.
[...]
Однако моя практика показывает, что в современной разработке прикладных приложений бизнес-логика не переиспользуется и новых "устройств" появляться не будет. А, значит, новых зависимостей появляться не будет, система не станет жёсткой и хрупкой и DIP не нужен, ч.т.д.
То бишь сначала анкл Боб бездоказательно заявляет, что в системах будут появляться новые устройства, а потом я так же бездоказательно заявляю, что не будут. Твоё слово против моего, встретимся в суде. Так и живут "инженеры" от современного ИТ...:)
#books@ergonomic_code
👍5😁4❤3
Привет!
Мысли в слух по теме прошлого поста.
Кажется, строительство сооружений и классическое "инженерное дело" — это не верный ориентир для разработки софта.
Как не крути, но в этих областях ТЗ фиксированное — мост и через 10 лет будет выполнять туже функцию и глобально не изменится. А условный айфон - вообще не изменится, если останется жив. А айфон 10 — это уже будет десятый проект с фиксированным ТЗ.
Наиболее близкая, как мне кажется, деятельность к разработке софта - построение бизнеса. Тут одна и та же организация через 10 лет может начать выполнять много новых функций или старые делать по другому.
Ещё более-менее похожая штука - "строительство" городов - города тоже живут долго и сильно меняются.
Других видов деятельности, по "выращиванию" одной сущности в течении длительного срока в меняющихся условиях я пока не придумал.
Надо будет как-нить покопаться что там с научным подходом к бизнесу и строительству городов:)
Мысли в слух по теме прошлого поста.
Кажется, строительство сооружений и классическое "инженерное дело" — это не верный ориентир для разработки софта.
Как не крути, но в этих областях ТЗ фиксированное — мост и через 10 лет будет выполнять туже функцию и глобально не изменится. А условный айфон - вообще не изменится, если останется жив. А айфон 10 — это уже будет десятый проект с фиксированным ТЗ.
Наиболее близкая, как мне кажется, деятельность к разработке софта - построение бизнеса. Тут одна и та же организация через 10 лет может начать выполнять много новых функций или старые делать по другому.
Ещё более-менее похожая штука - "строительство" городов - города тоже живут долго и сильно меняются.
Других видов деятельности, по "выращиванию" одной сущности в течении длительного срока в меняющихся условиях я пока не придумал.
Надо будет как-нить покопаться что там с научным подходом к бизнесу и строительству городов:)
👍5🤔1
Привет!
Прочитал Shape Up.
Книга о том, как устроен процесс разработки в Basecamp - контора, которая наиболее известна созданием Ruby on Rails.
Книга в первую очередь для владельца конторы/продукта, но всё равно советую прочитать.
Во-первых, как и все книги от Бейзкампа читается легко за несколько дней.
Во-вторых, там есть несколько прикольных идей, про которые просто прикольно знать:)
Общий процесс у них такой:
1. есть два трэка - шейпинг и билдинг
2. на треке шейпинга они прорабатывают концепт проекта, на среднем уровне детализации - без детального проектирования, но так чтобы снять основные неизвестные и ограничить скоуп, чтобы создать ощущение, что проект впишется в цикл билдинга
3. шейпинг не ограничен по времени, потому что он как раз таки исследует "кроличьи норы" проекта
4. Цикл билдинга строго 6 недель. Если за 6 недель проект не выпустили в прод - по дефолту он отменяется совсем.
5. Между циклами билдинга есть 2 недели охлаждения, когда все выдыхают, подчищают хвосты, делают что сами считают важным и живут без дедлайна
Прикольные идеи:
Breadboarding - способ описания концепта проекта. Состоит из элементов - мест (places - страницы, модалки и т.д.), возможностей (affordance - кнопки, ссылки, динамические тексты) и связей (connection lines - в какое место ведёт возможность).
Я раньше на вход к проектированию бэка требовал макеты UI. Мне в ответ говорили "Ты дебил? Нафига тебе макеты для проектирования бэка?". На что я отвечал "А у вас требования такие, что по ним хрен разберёшь что конкретно надо сделать". В следующий раз надо будет попробовать такую штуку
Hill chart - холмообразный график, представляющий прогресс выполнения работы. На старте в задаче скрыто много неизвестных неизвестных и работа может потенциально пойти тяжело (по восходящей), в какой-то момент работа достигает пика - всё тёмные пятна прокопаны и осталось "дело техники" - работа начинает катиться сама собой (идти по нисходящей). Положение задачи на графике определяется интуитивно исполнителем.
Они себе в бейзкампе (я так понимаю что-то аля джиры) запили эти самые хил чарты и отслеживают статус проекта по ним.
Любопытный факт - у них на компанию с "миллионами пользователей и дюженой человек в производственной команде" только 1 QA-инженер, который занимается граничными случаями. Базовый уровень качества обеспечивает производственная команда, в том числе тестами.
#books@ergonomic_code
Прочитал Shape Up.
Книга о том, как устроен процесс разработки в Basecamp - контора, которая наиболее известна созданием Ruby on Rails.
Книга в первую очередь для владельца конторы/продукта, но всё равно советую прочитать.
Во-первых, как и все книги от Бейзкампа читается легко за несколько дней.
Во-вторых, там есть несколько прикольных идей, про которые просто прикольно знать:)
Общий процесс у них такой:
1. есть два трэка - шейпинг и билдинг
2. на треке шейпинга они прорабатывают концепт проекта, на среднем уровне детализации - без детального проектирования, но так чтобы снять основные неизвестные и ограничить скоуп, чтобы создать ощущение, что проект впишется в цикл билдинга
3. шейпинг не ограничен по времени, потому что он как раз таки исследует "кроличьи норы" проекта
4. Цикл билдинга строго 6 недель. Если за 6 недель проект не выпустили в прод - по дефолту он отменяется совсем.
5. Между циклами билдинга есть 2 недели охлаждения, когда все выдыхают, подчищают хвосты, делают что сами считают важным и живут без дедлайна
Прикольные идеи:
Breadboarding - способ описания концепта проекта. Состоит из элементов - мест (places - страницы, модалки и т.д.), возможностей (affordance - кнопки, ссылки, динамические тексты) и связей (connection lines - в какое место ведёт возможность).
Я раньше на вход к проектированию бэка требовал макеты UI. Мне в ответ говорили "Ты дебил? Нафига тебе макеты для проектирования бэка?". На что я отвечал "А у вас требования такие, что по ним хрен разберёшь что конкретно надо сделать". В следующий раз надо будет попробовать такую штуку
Hill chart - холмообразный график, представляющий прогресс выполнения работы. На старте в задаче скрыто много неизвестных неизвестных и работа может потенциально пойти тяжело (по восходящей), в какой-то момент работа достигает пика - всё тёмные пятна прокопаны и осталось "дело техники" - работа начинает катиться сама собой (идти по нисходящей). Положение задачи на графике определяется интуитивно исполнителем.
Они себе в бейзкампе (я так понимаю что-то аля джиры) запили эти самые хил чарты и отслеживают статус проекта по ним.
Любопытный факт - у них на компанию с "миллионами пользователей и дюженой человек в производственной команде" только 1 QA-инженер, который занимается граничными случаями. Базовый уровень качества обеспечивает производственная команда, в том числе тестами.
#books@ergonomic_code
👍12🔥5😱1
Привет!
С подачи в комментариях к посту про DIP прочитал Stratified Design over Layered Design - на мой вкус прикольный, любопытный и полезный пост об абстракции.
Который оказался кроличьей норой.
Там дальше есть ссылка на IODA Architecture от того же мужика- штуку, которая сильно перекликается с моей Эргономичной архитектурой.
А если это погуглить её, то можно найти ещё один более свежий пост, где в конце всё тот же чувак предлагает ещё и Sleepy Hollow Architecture
А если ещё посмотреть на его блог - там ещё куча любопытный заголовков постов, в том числе что-то про Radical Object-Orientation, о чём у него есть отдельный сабстак.
А если погуглить самого чувака, то можно накопать и Clean Code Developer.
В общем советую почитать как минимум посты из этого поста и в целом покапаться в творчестве Ralf Westphals - у него явно есть чему поучиться.
#posts@ergonomic_code
С подачи в комментариях к посту про DIP прочитал Stratified Design over Layered Design - на мой вкус прикольный, любопытный и полезный пост об абстракции.
Который оказался кроличьей норой.
Там дальше есть ссылка на IODA Architecture от того же мужика- штуку, которая сильно перекликается с моей Эргономичной архитектурой.
А если это погуглить её, то можно найти ещё один более свежий пост, где в конце всё тот же чувак предлагает ещё и Sleepy Hollow Architecture
А если ещё посмотреть на его блог - там ещё куча любопытный заголовков постов, в том числе что-то про Radical Object-Orientation, о чём у него есть отдельный сабстак.
А если погуглить самого чувака, то можно накопать и Clean Code Developer.
В общем советую почитать как минимум посты из этого поста и в целом покапаться в творчестве Ralf Westphals - у него явно есть чему поучиться.
#posts@ergonomic_code
Medium
Stratified Design over Layered Design
Designing software with layers is common — and broken. It’s broken for two reasons:
🔥6👍4
Привет!
Добавил на вики пару заглушек паттернов тестирования:
1. Тестирование генерации xlsx-документов с помощью Apache POI
2. Используйте фейковый кодировщик паролей
#ergo_testing@ergonomic_code #ergowiki@ergonomic_code
Добавил на вики пару заглушек паттернов тестирования:
1. Тестирование генерации xlsx-документов с помощью Apache POI
2. Используйте фейковый кодировщик паролей
#ergo_testing@ergonomic_code #ergowiki@ergonomic_code
Эргономичный подход
Тестирование генерации xlsx-документов с помощью Apache POI (v0.0.0)
Тестирование кода генерации xlsx-документов является достаточно сложной задачей.
Верификация состояния XSSFWorkbook вручную будет очень громоздкой и сложной для чтения.
О существовании какого-то DSL-я, который бы позволял лаконичного и читаемо описывать корректные…
Верификация состояния XSSFWorkbook вручную будет очень громоздкой и сложной для чтения.
О существовании какого-то DSL-я, который бы позволял лаконичного и читаемо описывать корректные…
🔥5
Привет!
Периодически гипотезы, лежащие в основе ЭП, рушатся о жестокую реальность промышленной разработки, что приводит к кризисам ЭП, которых уже было три штуки: раз по мотивам проекта 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👍1
Привет!
Я тут в рамках выбора новой либы для работы с БД решил посмотреть на график контрибьюторов за предыдущий квартал на 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 #9
Недельное мероприятие от команды 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
GitHub
Commits · ergonomic-code/Trainer-Advisor
Информационная система йогатерапевта и демонстрационный проект Эргономичного подхода - Commits · ergonomic-code/Trainer-Advisor
❤3👍2
Привет!
Баги, найденные командой QA это:
Баги, найденные командой QA это:
Anonymous Poll
89%
Да норм, не в проде же
11%
Это катастрофа, стыд и позор - девелоперы шипают лажу и куча времени тратится на связанные оверхеды
Эргономичный код
Привет!
Баги, найденные командой QA это:
Баги, найденные командой QA это:
Понимаю, что на самом деле сильно зависит от, но хочу понять общее отношение к багам в сообществе - выберите вариант который вам по духу ближе, пожалуйста.
#ergo_testing@ergonomic_code
#ergo_testing@ergonomic_code