Привет!
Накатал лонгрид на 40 минут чтения с описанием того, чем и почему эргономичный подход отличается от обычного.
Но при этом у меня закрались сомнения.
Я пинаю "обычный" подход.
Но что такое "обычный" подход - это подход который я видел в своей практике.
А моя практика - 10-20 проектов/команд. И то, что я вижу в интернете.
Так вот - может весь мир уже пишет в эргономичном подходе и выкинул JPA, а у меня просто выборка опыта кривая?
Как по вашему, практики эргономичного подхода отличаются от наиболее распространённых?
#posts@ergonomic_code #ergo_approach@ergonomic_code
Накатал лонгрид на 40 минут чтения с описанием того, чем и почему эргономичный подход отличается от обычного.
Но при этом у меня закрались сомнения.
Я пинаю "обычный" подход.
Но что такое "обычный" подход - это подход который я видел в своей практике.
А моя практика - 10-20 проектов/команд. И то, что я вижу в интернете.
Так вот - может весь мир уже пишет в эргономичном подходе и выкинул JPA, а у меня просто выборка опыта кривая?
Как по вашему, практики эргономичного подхода отличаются от наиболее распространённых?
#posts@ergonomic_code #ergo_approach@ergonomic_code
Алексей Жидков
Что я делаю не так - Алексей Жидков
Рассмотрим в чём разница для бизнеса между типовым и эргономичным подходами
Привет!
Про тип: если в идеи в build.gradle вставить зависимость в maven-формате, идея сама сконвертит 🤯
#tools@ergonomic_code
Про тип: если в идеи в build.gradle вставить зависимость в maven-формате, идея сама сконвертит 🤯
#tools@ergonomic_code
image_2021-11-22_06-55-10.png
186.4 KB
Привет!
В Implementing DDD нашёл ещё одно пересечение с идеями эргономичного подхода - декомпозировать систему на модули необходимо исходя из агрегатов.
Там же мужик заодно и попинал пакетирование по типам классов.
В общем хорошая книга, рекомендую:)
#books@ergonomic_code #ddd@ergonomic_code #ergo_approach@ergonomic_code
В Implementing DDD нашёл ещё одно пересечение с идеями эргономичного подхода - декомпозировать систему на модули необходимо исходя из агрегатов.
Там же мужик заодно и попинал пакетирование по типам классов.
В общем хорошая книга, рекомендую:)
#books@ergonomic_code #ddd@ergonomic_code #ergo_approach@ergonomic_code
Привет!
Конкурирущая фирма пиарит JPA
Но автор почему-то среди альтернатив потерял Spring Data JDBC, который обладает практически всеми перечисленными достоинствами, кроме кэша (который не особо нужен нормальным приложениям), мультитенантности (вот тут да, будет боль) и генерации схемы.
И при этом забыл пару фатальных недостатков - противоречие классическим принципам дизайна и программирования и кое-что новенькое для этого чатика
Существует принцип проектирования API под названием "Pit of Success (Яма успеха)" - суть в том, чтобы разработчики "плывущие по течению" делали правильные вещи. В случае же JPA "разработчики плывущие по течению" будут создавать приложения с плохим дизайном (все сущности связаны двунаправленными связями) и производительностью (кучи N+1 запросов).
#posts@ergonomic_code #jpa@ergonomic_code
Конкурирущая фирма пиарит JPA
Но автор почему-то среди альтернатив потерял Spring Data JDBC, который обладает практически всеми перечисленными достоинствами, кроме кэша (который не особо нужен нормальным приложениям), мультитенантности (вот тут да, будет боль) и генерации схемы.
И при этом забыл пару фатальных недостатков - противоречие классическим принципам дизайна и программирования и кое-что новенькое для этого чатика
Существует принцип проектирования API под названием "Pit of Success (Яма успеха)" - суть в том, чтобы разработчики "плывущие по течению" делали правильные вещи. В случае же JPA "разработчики плывущие по течению" будут создавать приложения с плохим дизайном (все сущности связаны двунаправленными связями) и производительностью (кучи N+1 запросов).
#posts@ergonomic_code #jpa@ergonomic_code
Vlad Mihalcea
Why and when you should use JPA - Vlad Mihalcea
If you are wondering why and when you should use JPA or Hibernate, then this article is going to provide you the answer.
image_2021-11-27_06-04-06.png
4 KB
Привет!
Я замотался и забыл выпустить пресс-релиз, что 23 ноября нас стало 100 человек!:)
Спасибо что вы со мной, для меня это значит что я делаю не полную чушь и у меня даже получается неплохо подать свои мысли и идеи. Так же это является для меня дополнительной мотивацией продолжать доводить эргономичный подход до ума.
И заодно небольшой анонс - я уже дописал текст следующего (на этот раз всего 20-минутного 😂) поста о структурах эргономичных программ - к чему я стремлюсь, когда делаю не так.
К нему ещё надо иллюстрации нарисовать, но надеюсь в течении недели опубликую.
Я замотался и забыл выпустить пресс-релиз, что 23 ноября нас стало 100 человек!:)
Спасибо что вы со мной, для меня это значит что я делаю не полную чушь и у меня даже получается неплохо подать свои мысли и идеи. Так же это является для меня дополнительной мотивацией продолжать доводить эргономичный подход до ума.
И заодно небольшой анонс - я уже дописал текст следующего (на этот раз всего 20-минутного 😂) поста о структурах эргономичных программ - к чему я стремлюсь, когда делаю не так.
К нему ещё надо иллюстрации нарисовать, но надеюсь в течении недели опубликую.
Привет!
Давным давно - практически до нашей эры по меркам ИТ - в 2014 году, David Heinemeier Hansson (автор Ruby on Rails) устроил бучу под названием "TDD is dead". Эта буча дошла до одного из отцов-основателей TDD - Кента Бека и они на троих с Мартином Фаулером устроили публичные дебаты на эту тему - рекомендую послушать, там много полезного о тестировании.
Но я не об этом, я там откопал подкрепление тезису "Основатели движения юнит-тестирования под юнит тестами имели ввиду совсем не то, что люди делают с моками".
И вот вырезка о том, что сам Кент практически не использует моки:
My personal practices... I'm mock almost nothing. If I can't figure out how to test effciently with the real stuff I find another way of creating a feedbacj loop for myself... I just don't go very far down the mock path. I look at a code where you have mocks returning mocks returning mocks and... my experience is if I have... If I use TDD I can refactor stuff and then I heard these stories people say well I use TDD and now I can't refactor anything and I feel like I couldn't understand that and then I started looking at their tests... Well if you have mocks returning mocks returning mocks your test is completely coupled to the implementation... not on the interface but the exact implementation of some object ... three streets away ... of course you can't change anything without breaking a test. So that for me is too high a price to pay that's not not a trade-off I'm willing to make.
TW Hangouts | Is TDD dead?
#talks@ergonomic_code #tdd@ergonomic_code #ergo_testing@ergonomic_code #whynomocks@ergonomic_code
Давным давно - практически до нашей эры по меркам ИТ - в 2014 году, David Heinemeier Hansson (автор Ruby on Rails) устроил бучу под названием "TDD is dead". Эта буча дошла до одного из отцов-основателей TDD - Кента Бека и они на троих с Мартином Фаулером устроили публичные дебаты на эту тему - рекомендую послушать, там много полезного о тестировании.
Но я не об этом, я там откопал подкрепление тезису "Основатели движения юнит-тестирования под юнит тестами имели ввиду совсем не то, что люди делают с моками".
И вот вырезка о том, что сам Кент практически не использует моки:
My personal practices... I'm mock almost nothing. If I can't figure out how to test effciently with the real stuff I find another way of creating a feedbacj loop for myself... I just don't go very far down the mock path. I look at a code where you have mocks returning mocks returning mocks and... my experience is if I have... If I use TDD I can refactor stuff and then I heard these stories people say well I use TDD and now I can't refactor anything and I feel like I couldn't understand that and then I started looking at their tests... Well if you have mocks returning mocks returning mocks your test is completely coupled to the implementation... not on the interface but the exact implementation of some object ... three streets away ... of course you can't change anything without breaking a test. So that for me is too high a price to pay that's not not a trade-off I'm willing to make.
TW Hangouts | Is TDD dead?
#talks@ergonomic_code #tdd@ergonomic_code #ergo_testing@ergonomic_code #whynomocks@ergonomic_code
martinfowler.com
Is TDD Dead
A series of conversations between Kent Beck,
David Heinemeier Hansson, and Martin Fowler. We discuss
Test-Driven Development (TDD) and its impact upon software
design.
David Heinemeier Hansson, and Martin Fowler. We discuss
Test-Driven Development (TDD) and its impact upon software
design.
Привет!
А вот и обещанный пост о структурах программ, к которым я стремлюсь в работе.
Но этот раз всего 20 минут и с картинками:)
#posts@ergonomic_code #ergo_arch@ergonomic_code #ergo_approach@ergonomic_code
А вот и обещанный пост о структурах программ, к которым я стремлюсь в работе.
Но этот раз всего 20 минут и с картинками:)
#posts@ergonomic_code #ergo_arch@ergonomic_code #ergo_approach@ergonomic_code
Привет!
Немного пиара Котлина вам в ленту:)
Вышел Compose Multiplatform 1.0 Release :)
Анонсировали AWS SDK для Котлина (и Swift с Rust)
#tools@ergonomic_code #kotlin@ergonomic_code
Немного пиара Котлина вам в ленту:)
Вышел Compose Multiplatform 1.0 Release :)
Анонсировали AWS SDK для Котлина (и Swift с Rust)
#tools@ergonomic_code #kotlin@ergonomic_code
The JetBrains Blog
Compose Multiplatform 1.0 Is Going Live! | The Kotlin Blog
Compose Multiplatform by JetBrains, the declarative UI framework for Kotlin, has reached version 1.0, which makes it ready for production use! Here are a few highlights that we hope will make you as e
Продолжаю убеждаться в том, что львиная доля эргономичного подхода - это переизобретённый ДДД,
"The effects of its code must be transparently obvious, so the consequences of a change will be easy to anticipate."
Eric Evans, DDD Reference
"А пренебрежение эффектами ведёт к тому, что они разбросаны по коду в произвольных местах. Это усложняет понимание того, к каким эффектам приведёт та или иная операция и наоборот, какие операции могут привести к тому или иному эффекту ... Из-за этого разработчикам сложно понять все последствия вносимых изменений"
"Применение этих техник даёт ... Повышения видимости последствий изменений"
Я, Что я делаю не так
#books@ergonomic_code #ddd@ergonomic_code #ergo_approach@ergonomic_code
"The effects of its code must be transparently obvious, so the consequences of a change will be easy to anticipate."
Eric Evans, DDD Reference
"А пренебрежение эффектами ведёт к тому, что они разбросаны по коду в произвольных местах. Это усложняет понимание того, к каким эффектам приведёт та или иная операция и наоборот, какие операции могут привести к тому или иному эффекту ... Из-за этого разработчикам сложно понять все последствия вносимых изменений"
"Применение этих техник даёт ... Повышения видимости последствий изменений"
Я, Что я делаю не так
#books@ergonomic_code #ddd@ergonomic_code #ergo_approach@ergonomic_code
Domain Language
DDD Reference - Domain Language
A summary of the patterns and definitions of DDD. This document is meant as a convenient reference for those who know the principles of Domain-Driven Design (DDD). It does not contain full explanations of DDD or even of the terms and patterns covered. It…
ss-bbom.png
15.6 KB
Привет!
Мне тут попался проект с пакетированием по слоям представляющий из себя сферический Big Bull of Mud в вакууме.
Проект хорош тем, что в пакетах верхнего уровня нет ничего лишнего, но я утверждаю, что подобный подход к пакетированию неминуемо ведёт к такой архитектуре
P.S.
На диаграмме - матрица зависимостей, красным обозначены циклы в зависимостях между модулями, в здоровом проекте их быть не должно и матрица должна быть нижнетреугольной.
#case@ergonomic_code
Мне тут попался проект с пакетированием по слоям представляющий из себя сферический Big Bull of Mud в вакууме.
Проект хорош тем, что в пакетах верхнего уровня нет ничего лишнего, но я утверждаю, что подобный подход к пакетированию неминуемо ведёт к такой архитектуре
P.S.
На диаграмме - матрица зависимостей, красным обозначены циклы в зависимостях между модулями, в здоровом проекте их быть не должно и матрица должна быть нижнетреугольной.
#case@ergonomic_code
И немного классиков вам в ленту
"The translation of a feeling (for example, disgust at side effects)..."
Beck, TDD by example, с. 30
P.S.
Перевод: "Перевод чувства (например, отвращения к побочным эффектам".
#books@ergonomic_code #why_no_side_effects@ergonomic_code
"The translation of a feeling (for example, disgust at side effects)..."
Beck, TDD by example, с. 30
P.S.
Перевод: "Перевод чувства (например, отвращения к побочным эффектам".
#books@ergonomic_code #why_no_side_effects@ergonomic_code
Привет!
Это снова я:)
Анкл Боб недавно написал новый пост с восхвалением ФП.
Да-да, это тот самый Анкл Боб, который придумал SOLID - "5 основных принципов объектно-ориентированного программирования", согласно русской Википедии.
#posts@ergonomic_code #fp@ergonomic_code
Это снова я:)
Анкл Боб недавно написал новый пост с восхвалением ФП.
Да-да, это тот самый Анкл Боб, который придумал SOLID - "5 основных принципов объектно-ориентированного программирования", согласно русской Википедии.
#posts@ergonomic_code #fp@ergonomic_code
Привет!
Сегодня я надел свою шляпу параноика.
Ещё одна реальная история бана большим братом аккаунта простого юзера со всеми данным.
Сегодня я надел свою шляпу параноика.
Ещё одна реальная история бана большим братом аккаунта простого юзера со всеми данным.
Mere Civilian
Apple broke up with me 😢
Do not get too attached to your Apple account; it belongs to Apple, NOT YOU!
Привет!
Случайно наткнулся на прямой ответ на мой сакральный вопрос - как декомпозировать систему на модули?
Ответ - Parnas Partitioning.
Правда оригинальную статью даже за деньги нагуглить не могу.
Ну и сам ответ любопытный, но, кажется, не практичный.
Что предлагают:
1) собрать всех стейкхолдеров. В моих реалиях - уже анриал
2) стрясти с них все идеи того что может поменяться. С учётом того, того, что сейчас требований на старте особо нет, то фик знает как трясти
3) отсортировать это всё по относительной вероятности. Вот тут уже хорошо и понятно, осталось придумать как пройти первые два шага:)
4) Оценить стоимость инкапсуляции каждого пункта
5) То что инкапсулировать дешево - инкапсулировать в отдельный модуль
6) Из оставшегося инкапсулировать наиболее вероятные штуки, пока бюджет не кончится.
Кажется, декомпозиция системы на модули (в современных условиях, по крайней мере) - это всё-таки вотчина гадалок и экстрасенсов.
#papers@ergonomic_code #design@ergonomic_code
Случайно наткнулся на прямой ответ на мой сакральный вопрос - как декомпозировать систему на модули?
Ответ - Parnas Partitioning.
Правда оригинальную статью даже за деньги нагуглить не могу.
Ну и сам ответ любопытный, но, кажется, не практичный.
Что предлагают:
1) собрать всех стейкхолдеров. В моих реалиях - уже анриал
2) стрясти с них все идеи того что может поменяться. С учётом того, того, что сейчас требований на старте особо нет, то фик знает как трясти
3) отсортировать это всё по относительной вероятности. Вот тут уже хорошо и понятно, осталось придумать как пройти первые два шага:)
4) Оценить стоимость инкапсуляции каждого пункта
5) То что инкапсулировать дешево - инкапсулировать в отдельный модуль
6) Из оставшегося инкапсулировать наиболее вероятные штуки, пока бюджет не кончится.
Кажется, декомпозиция системы на модули (в современных условиях, по крайней мере) - это всё-таки вотчина гадалок и экстрасенсов.
#papers@ergonomic_code #design@ergonomic_code
Привет!
Пересмотрел старый доклад моего любимого Рича Хикки.
Он там прямым текстом говорит, что доклад не про то, чтобы попинать ООП, но получается у него очень хорошо. При том на фундаментальном уровне.
Но самая крутая на мой взгляд штука - это Эпохальная Модель Времени, кратко описная здесь.
Очень рекомендую к вдумчивому просмотру
#talks@ergonomic_code #fp@ergonomic_code #clojure@ergonomic_code #immutable_domain_model@ergonomic_code
Пересмотрел старый доклад моего любимого Рича Хикки.
Он там прямым текстом говорит, что доклад не про то, чтобы попинать ООП, но получается у него очень хорошо. При том на фундаментальном уровне.
Но самая крутая на мой взгляд штука - это Эпохальная Модель Времени, кратко описная здесь.
Очень рекомендую к вдумчивому просмотру
#talks@ergonomic_code #fp@ergonomic_code #clojure@ergonomic_code #immutable_domain_model@ergonomic_code
InfoQ
Are We There Yet?
In his keynote at JVM Languages Summit 2009, Rich Hickey advocated for the reexamination of basic principles like state, identity, value, time, types, genericity, complexity, as they are used by OOP today, to be able to create the new constructs and languages…
У меня накопилось ещё ссылок, но мне показалось, что на той недели я вас заспамил, такчто пока их придержал.
Как часто я могу что-то постить, чтобы вам было комфортно?
Как часто я могу что-то постить, чтобы вам было комфортно?
Anonymous Poll
3%
Раз в месяц
19%
Раз в неделю
50%
Два-три раза в неделю
16%
Каждый день
3%
Каждые восемь часов
9%
Раз в два-три часа
Привет!
Параноидальный линко-пост.
Гугл, по чистой случайности главный большой брат и владелец самого популярного браузера, собирается выкинуть АПИ критичные для АдБлокеров.
Го Firefox - тут вполне ок последние 4 года
Параноидальный линко-пост.
Гугл, по чистой случайности главный большой брат и владелец самого популярного браузера, собирается выкинуть АПИ критичные для АдБлокеров.
Го Firefox - тут вполне ок последние 4 года
Electronic Frontier Foundation
Chrome Users Beware: Manifest V3 is Deceitful and Threatening
Like FLoC and Privacy Sandbox before it, Google Chrome’s Manifest V3 is another example of the inherent conflict of interest that comes from Google controlling both the dominant web browser and one
Привет!
Прочитал оригинальюную статью по Parnas Partitioning (ещё раз спасибо @celebithil за неё).
Не сказать чтобы статья показалась мне особо полезной, но напоминание одной хорошей мысли утянул:
In fact, imposing a design goal of modularity or flexibility WITHOUT providing the associated Hiding Assumption List would appear to be inherently ineffective. General purpose flexibility is likely to prove to be an ill-defined goal.
Абстрактная задача создания гибкой системы - плохая задача. Невозможно (с практической точки зрения, по крайней мере) создать систему гибкую в любом месте по любому направлению. И если делать систему гибкой просто на всякий случай, то с большой долей вероятности вы не угадаете и заложенные "точки перегиба" не пригодятся, но они увеличат стоимость разработки и усложнят "сгибание" системы в непредусмотренных местах, когда это действительно потребуется.
Прочитал оригинальюную статью по Parnas Partitioning (ещё раз спасибо @celebithil за неё).
Не сказать чтобы статья показалась мне особо полезной, но напоминание одной хорошей мысли утянул:
In fact, imposing a design goal of modularity or flexibility WITHOUT providing the associated Hiding Assumption List would appear to be inherently ineffective. General purpose flexibility is likely to prove to be an ill-defined goal.
Абстрактная задача создания гибкой системы - плохая задача. Невозможно (с практической точки зрения, по крайней мере) создать систему гибкую в любом месте по любому направлению. И если делать систему гибкой просто на всякий случай, то с большой долей вероятности вы не угадаете и заложенные "точки перегиба" не пригодятся, но они увеличат стоимость разработки и усложнят "сгибание" системы в непредусмотренных местах, когда это действительно потребуется.
Привет!
Вышли корутины 1.6.0 с парой долгожданных (мной) фич:
1) наконец-то можно писать мультиплатформенные тесты на suspend код без костылей
2) наконец-то можно создавать диспетчеры с ограниченным параллелизмом
#tools@ergonomic_code #kotlin@ergonomic_code
Вышли корутины 1.6.0 с парой долгожданных (мной) фич:
1) наконец-то можно писать мультиплатформенные тесты на suspend код без костылей
2) наконец-то можно создавать диспетчеры с ограниченным параллелизмом
#tools@ergonomic_code #kotlin@ergonomic_code
The JetBrains Blog
Introducing kotlinx.coroutines 1.6.0 | The Kotlin Blog
Following the release of Kotlin 1.6.0, the 1.6.0 version of the kotlinx.coroutines library is out. Here are the main features it brings: A new API and multiplatform support for kotlinx-coroutines-t
Привет!
Новый год - время перемен.
Весь 21-ый год я пытался сделать рациональную методику разработки ПО с детерминированным результатом. И что-то у меня не выходил каменный цветок - наверное не просто так, никто ещё этого не смог:)
И вот, под конец года я сначала прочитал "Думай медленно, решай быстро", где Канниман среди прочего ставит под сомнение предсказательную способность некоторых экспертов (я это прочитал как сомнение в способности программистов предсказать изменения).
Затем я прочитал "A RATIONAL DESIGN PROCESS: HOW AND WHY TO FAKE IT", где Парнас пишет, что рациональный дизайн невозможен.
Потом прочитал "Чёрного Лебедя", где Талеб среди прочего через слово пинает платонические модели
И сейчас читаю "Data and Reality", где Кент показывает, что информация сама по себе - аморфное месиво, и нет рационального способа выбора её представления в компьютере.
В общем, я решил сделать пивот и в следующем году перейти от попытки создать теорию всего к описанию своей практики.
Генеральный план - составить каталог "соображений", исходя из которых я принимаю решения и разбирать конкретные кейсы применения этих соображений и принятия решений. Потом может удастся всё это как-то объединить.
С наступающим Новым годом!:)
Пусть вам программирование приносит больше положительных эмоций, чем отрицательных:)
#ergo_approach@ergonomic_code #books@ergonomic_code
Новый год - время перемен.
Весь 21-ый год я пытался сделать рациональную методику разработки ПО с детерминированным результатом. И что-то у меня не выходил каменный цветок - наверное не просто так, никто ещё этого не смог:)
И вот, под конец года я сначала прочитал "Думай медленно, решай быстро", где Канниман среди прочего ставит под сомнение предсказательную способность некоторых экспертов (я это прочитал как сомнение в способности программистов предсказать изменения).
Затем я прочитал "A RATIONAL DESIGN PROCESS: HOW AND WHY TO FAKE IT", где Парнас пишет, что рациональный дизайн невозможен.
Потом прочитал "Чёрного Лебедя", где Талеб среди прочего через слово пинает платонические модели
И сейчас читаю "Data and Reality", где Кент показывает, что информация сама по себе - аморфное месиво, и нет рационального способа выбора её представления в компьютере.
В общем, я решил сделать пивот и в следующем году перейти от попытки создать теорию всего к описанию своей практики.
Генеральный план - составить каталог "соображений", исходя из которых я принимаю решения и разбирать конкретные кейсы применения этих соображений и принятия решений. Потом может удастся всё это как-то объединить.
С наступающим Новым годом!:)
Пусть вам программирование приносит больше положительных эмоций, чем отрицательных:)
#ergo_approach@ergonomic_code #books@ergonomic_code