По мотивам всё той же хроники архитектуры, перелистывал книгу по DDD Эванса и наткнулся на чистые функции прямо в оглавлении: SIDE-EFFECT-FREE FUNCTIONS.
С рекомендацией:
Place as much of the logic of the program as possible into functions, operations that return results with no observable side effects
Всё, расходимся - вдумчиво читайте ДДД и будет вам счастье.
На самом деле нет😊 Мне всё ещё кажется, что мне есть что добавить к классикам - у меня есть свой взгляд на методику проектирования и я предлагаю более легковесный процесс и архитектуру.
#ddd@ergonomic_code #why_no_side_effects@ergonomic_code #whyfp@ergonomic_code
С рекомендацией:
Place as much of the logic of the program as possible into functions, operations that return results with no observable side effects
Всё, расходимся - вдумчиво читайте ДДД и будет вам счастье.
На самом деле нет😊 Мне всё ещё кажется, что мне есть что добавить к классикам - у меня есть свой взгляд на методику проектирования и я предлагаю более легковесный процесс и архитектуру.
#ddd@ergonomic_code #why_no_side_effects@ergonomic_code #whyfp@ergonomic_code
Ну и наконец, линко-пост о кэшировании в Spring Data JDBC.
Про кеширование там полезно тем, что подсвечивают ряд граблей, свойственных JDBC, но самое полезное - раздел Why Spring Data does no caching, в котром автор пинает JPA.
Подписываюсь под каждым словом этого раздела всеми ~8 годами своих мучений с JPA/Hibernate в проде.
#posts@ergonomic_code #spring_data_jdbc@ergonomic_code
Про кеширование там полезно тем, что подсвечивают ряд граблей, свойственных JDBC, но самое полезное - раздел Why Spring Data does no caching, в котром автор пинает JPA.
Подписываюсь под каждым словом этого раздела всеми ~8 годами своих мучений с JPA/Hibernate в проде.
#posts@ergonomic_code #spring_data_jdbc@ergonomic_code
Spring Data JDBC - How do I implement caching?
Level up your Java code and explore what Spring can do for you.
Привет!
Мне тут довелось пообщаться с адептами микросервисов и ох. Я понял, что многие люди видят их в качестве решения проблемы плохоспроектированного кода. В итоге получают плохоспроектированный распрделённый код и все следующие за этим беды.
С другой стороны, я понял, что у меня самого нет внятного понимания, когда модулярный монолит пора начинать резать на отдельные сервисы.
Начал изучать тему и наткнулся на огненный видос, с ответом на этот вопрос. Настоятельно рекомендую его посмотреть перед выбором МС в качестве архитектуры - в противном случае, с большой долей вероятности, сначала будет немножечко приятно, а потом очень больно и всю оставшуюся жизнь ни за что.
Ещё, чувак в слух проговорил, но на графике стоимости не нарисовал четвёртый вариант - начать с хорошо сделанного модулярного монолита, а потом по необходимости и без сложностей вырезать из него микросервисы. Это даст бенефиты обоих подходов. Это эргономичный подход к разработке очень больших систем.
#talks@ergonomic_code #why_no_microservices@ergonomic_code
Мне тут довелось пообщаться с адептами микросервисов и ох. Я понял, что многие люди видят их в качестве решения проблемы плохоспроектированного кода. В итоге получают плохоспроектированный распрделённый код и все следующие за этим беды.
С другой стороны, я понял, что у меня самого нет внятного понимания, когда модулярный монолит пора начинать резать на отдельные сервисы.
Начал изучать тему и наткнулся на огненный видос, с ответом на этот вопрос. Настоятельно рекомендую его посмотреть перед выбором МС в качестве архитектуры - в противном случае, с большой долей вероятности, сначала будет немножечко приятно, а потом очень больно и всю оставшуюся жизнь ни за что.
Ещё, чувак в слух проговорил, но на графике стоимости не нарисовал четвёртый вариант - начать с хорошо сделанного модулярного монолита, а потом по необходимости и без сложностей вырезать из него микросервисы. Это даст бенефиты обоих подходов. Это эргономичный подход к разработке очень больших систем.
#talks@ergonomic_code #why_no_microservices@ergonomic_code
YouTube
Modules or Microservices? - Sander Mak
Microservices promise a scalable architecture, increased flexibility, and better performance. But then you find out what’s actually involved in designing and running a microservices-based architecture. Turns out it’s not that straightforward after all.
Often…
Often…
Привет!
Немного офтопа, но на злободневную тему
Заболели с женой одновременно ковидом.
Жена уже на 4ый день огурец практически, я на исходе 5ого только начинаю чуствовать себя человеком.
Жена полностью привита, я на половину.
Вызвали ковидную пригаду из районной поликлиники, приехали в тот же день две приятные тётенки, осмотр сделали и мне и жене, хотя в бумагах у них был только я, выдали на халяву гору лекарств, записали на халявный пцр.
Я это к тому, что:
1. сомневающимся, рекомендую привиться - даже первой дозой можно сэкономить себе пару дней коматозного состояния
2. боящимся бесплатной медицины - рекомендую попробовать, если всё-таки угораздит заболеть. Возможно не только в моей деревне, а в целом по стране всё не настолько плохо, как пишут в одних сми, а настолько хорошо, как пишут в других. Как минимум в части ковида.
Немного офтопа, но на злободневную тему
Заболели с женой одновременно ковидом.
Жена уже на 4ый день огурец практически, я на исходе 5ого только начинаю чуствовать себя человеком.
Жена полностью привита, я на половину.
Вызвали ковидную пригаду из районной поликлиники, приехали в тот же день две приятные тётенки, осмотр сделали и мне и жене, хотя в бумагах у них был только я, выдали на халяву гору лекарств, записали на халявный пцр.
Я это к тому, что:
1. сомневающимся, рекомендую привиться - даже первой дозой можно сэкономить себе пару дней коматозного состояния
2. боящимся бесплатной медицины - рекомендую попробовать, если всё-таки угораздит заболеть. Возможно не только в моей деревне, а в целом по стране всё не настолько плохо, как пишут в одних сми, а настолько хорошо, как пишут в других. Как минимум в части ковида.
Привет!
Ковидно-депрессивные мысли вслух.
Что-то меня в последнее время жизнь посталкивала с энтерпрайзными Java-архитекторами в корпорациях, и эти события мне напомнили цитату:
> First of all, and sad to say, I think there has been a general abandonment of good design and development practices in the Java community.
И далее:
> Due to Jimmy’s good work and that of others promoting the Alt.NET mindset, there is a high tide of good design and development practices going on in the .NET community. Java developers need to take notice.
Из Implementing Domain-Driven Design - вторая по почетаемости после оригинала книга в ДДД тусовке от очень крутого чувака.
Плюс я могу накидать пачку хороших блоггеров от дотнета (раз, два, три) и даже пару неплохих от пхп (раз, два), а вот джависты мне что-то как-то не припоминаются (именно по дизайну, хардкорщиков хватает)
И самое страшное, что я все те же привычки вижу у многих студентов и у меня не особо получается их переучить - больно уж сладок и лёгок путь паршивого кода.
Хоть иди джуном в Дотнетчики, чтобы от Джававских адских традиций спастись.
#books@ergonomic_code #posts@ergonomic_code #design@ergonomic_code #java@ergonomic_code
Ковидно-депрессивные мысли вслух.
Что-то меня в последнее время жизнь посталкивала с энтерпрайзными Java-архитекторами в корпорациях, и эти события мне напомнили цитату:
> First of all, and sad to say, I think there has been a general abandonment of good design and development practices in the Java community.
И далее:
> Due to Jimmy’s good work and that of others promoting the Alt.NET mindset, there is a high tide of good design and development practices going on in the .NET community. Java developers need to take notice.
Из Implementing Domain-Driven Design - вторая по почетаемости после оригинала книга в ДДД тусовке от очень крутого чувака.
Плюс я могу накидать пачку хороших блоггеров от дотнета (раз, два, три) и даже пару неплохих от пхп (раз, два), а вот джависты мне что-то как-то не припоминаются (именно по дизайну, хардкорщиков хватает)
И самое страшное, что я все те же привычки вижу у многих студентов и у меня не особо получается их переучить - больно уж сладок и лёгок путь паршивого кода.
Хоть иди джуном в Дотнетчики, чтобы от Джававских адских традиций спастись.
#books@ergonomic_code #posts@ergonomic_code #design@ergonomic_code #java@ergonomic_code
Привет!
Сегодня у меня новый формат поста - "вопрос к экспертам по REST":)
Представьте, что вы делаете систему, где сущностям надо аттачить картинки.
Вы решаете сделать сразу абстрактную файло-хранилку с эндпоинтом files/
И оказываетесь правы, т.к. заказчик тут же приходит и говорит, что хочет хранить ещё и видео.
А вы говорите - да туда же и лейте их, там просто файлы.
Дальше заказчик хочет пережимать картинки на бэке.
И вот тут я поплыл.
Первый порыв: files/<id>?maxSideSize=128 - явно дурно пахнет.
Второй порыв: files/<id>/resized?maxSideSize=128 - мне по началу показался ок, но пришёл коллега и спросил: "а если там не картинка? а когда превью видео захотят?"
Тут до меня дошло, что files - полиморфный ресурс.
Что с ним делать?
files/images? images?
и 404, когда файл с таким идом есть, но не картинка?
Что посоветуете?
Сегодня у меня новый формат поста - "вопрос к экспертам по REST":)
Представьте, что вы делаете систему, где сущностям надо аттачить картинки.
Вы решаете сделать сразу абстрактную файло-хранилку с эндпоинтом files/
И оказываетесь правы, т.к. заказчик тут же приходит и говорит, что хочет хранить ещё и видео.
А вы говорите - да туда же и лейте их, там просто файлы.
Дальше заказчик хочет пережимать картинки на бэке.
И вот тут я поплыл.
Первый порыв: files/<id>?maxSideSize=128 - явно дурно пахнет.
Второй порыв: files/<id>/resized?maxSideSize=128 - мне по началу показался ок, но пришёл коллега и спросил: "а если там не картинка? а когда превью видео захотят?"
Тут до меня дошло, что files - полиморфный ресурс.
Что с ним делать?
files/images? images?
и 404, когда файл с таким идом есть, но не картинка?
Что посоветуете?
Привет!
Наконец-то прочитал пару классических научных статей по ФП:
1) Why functional programming matters
2) The Curse of the Excluded Middle
Начитал много любопытного, много думал.
Во-первых, на мой взгляд, их можно считать достаточно авторитетным источником для следующих тезисов:
1) Чистые функции исключают важный источник ошибок [связанных с временной связанностью] [1]
2) Модульный дизайн - ключ к успешному программированию [1]
3) Компиляторам проще оптимизировать чистые функции [2]
4) Императивные программы сложнее понимать, чем декларативные [2]
Эти утверждения не подтверждаются данными, но статьи из рецензируемых журналов - лучше, чем ничего.
При том Why FP Matters, утверждает, что FP собственно имеет значение, т.к. даёт два новых инструмента модуляризации:
1) Функции высшего порядка
2) Ленивый режим вычисления
И то и другое в более менее-аналогичном виде появилось ещё в ООП (статья 80ого года и ООП ещё не хайпануло), а в том же Kotlin сейчас есть прямые аналоги даже ленивому режиму вычисления (в виде корутин).
С функциями высшего порядка совсем всё хорошо - благодаря Stream API (и аналогам), они сейчас распространены повсеместно.
А вот с ленивым вычислением - всё хуже.
В мейнстриме его практически нет.
Видимо потому что смешение ленивых вычислений и эффектов - не даёт модуляризации. И вообще дорога в ад.
Вторая статья при этом утверждает, что нет ленивых вычислений - нет ФП
Это меня натолкнуло на другую мысль - я вот вроде везде топлю за ФП. А топлю ли я за ФП?
Я топлю за максимизацию процента кода без эффектов и максимизацию видимости эффектов, не более того.
Но я не топлю за то, чтобы описывать программы как композицию функций, которая когда-то как-то кем-то вычислится в 42
И ленивые вычисления - на мой взгляд, прикольный и иногда полезный инструмент, но он действительно плохо совместим с эффектами, а мы программы пишем ради эффектов.
Я с этим ещё буду разбираться, но пока у меня план начать топить за декларативное программирование.
А дальше я задумался (снова), что у нас в индустрии полный бардак в терминологии.
Что значат все эти штуки:
1) функциональное программирование
2) декларативное программирование
3) процедурный подход
4) императивный подход
5) структурное программирование
6) структурный дизайн
7) объектно-ориентированное программирование
8) объектное программирование
9) объектно-ориентированный дизайн
10) модульное программирование
11) компонентное программирование
Что у них общего? Чем они отличаются?
Видимо придётся мне хотя бы для школы разработки имени себя навести тут какой-то порядок.
#papers@ergonomic_code #fp@ergonomic_code #terminology@ergonomic_code
Наконец-то прочитал пару классических научных статей по ФП:
1) Why functional programming matters
2) The Curse of the Excluded Middle
Начитал много любопытного, много думал.
Во-первых, на мой взгляд, их можно считать достаточно авторитетным источником для следующих тезисов:
1) Чистые функции исключают важный источник ошибок [связанных с временной связанностью] [1]
2) Модульный дизайн - ключ к успешному программированию [1]
3) Компиляторам проще оптимизировать чистые функции [2]
4) Императивные программы сложнее понимать, чем декларативные [2]
Эти утверждения не подтверждаются данными, но статьи из рецензируемых журналов - лучше, чем ничего.
При том Why FP Matters, утверждает, что FP собственно имеет значение, т.к. даёт два новых инструмента модуляризации:
1) Функции высшего порядка
2) Ленивый режим вычисления
И то и другое в более менее-аналогичном виде появилось ещё в ООП (статья 80ого года и ООП ещё не хайпануло), а в том же Kotlin сейчас есть прямые аналоги даже ленивому режиму вычисления (в виде корутин).
С функциями высшего порядка совсем всё хорошо - благодаря Stream API (и аналогам), они сейчас распространены повсеместно.
А вот с ленивым вычислением - всё хуже.
В мейнстриме его практически нет.
Видимо потому что смешение ленивых вычислений и эффектов - не даёт модуляризации. И вообще дорога в ад.
Вторая статья при этом утверждает, что нет ленивых вычислений - нет ФП
Это меня натолкнуло на другую мысль - я вот вроде везде топлю за ФП. А топлю ли я за ФП?
Я топлю за максимизацию процента кода без эффектов и максимизацию видимости эффектов, не более того.
Но я не топлю за то, чтобы описывать программы как композицию функций, которая когда-то как-то кем-то вычислится в 42
И ленивые вычисления - на мой взгляд, прикольный и иногда полезный инструмент, но он действительно плохо совместим с эффектами, а мы программы пишем ради эффектов.
Я с этим ещё буду разбираться, но пока у меня план начать топить за декларативное программирование.
А дальше я задумался (снова), что у нас в индустрии полный бардак в терминологии.
Что значат все эти штуки:
1) функциональное программирование
2) декларативное программирование
3) процедурный подход
4) императивный подход
5) структурное программирование
6) структурный дизайн
7) объектно-ориентированное программирование
8) объектное программирование
9) объектно-ориентированный дизайн
10) модульное программирование
11) компонентное программирование
Что у них общего? Чем они отличаются?
Видимо придётся мне хотя бы для школы разработки имени себя навести тут какой-то порядок.
#papers@ergonomic_code #fp@ergonomic_code #terminology@ergonomic_code
Привет!
Вышел Kotlin 1.6.
На мой взгляд релиз минорный, но двум фичам я прям рад:
1) Теперь можно в качестве значений параметров suspend функций передавать обычные функции (Suspend conversions)
2) Наконец-то сделали инструмент для оценки покрытия тестами в мультиплатформенных проектах
#tools@ergonomic_code #kotlin@ergonomic_code
Вышел Kotlin 1.6.
На мой взгляд релиз минорный, но двум фичам я прям рад:
1) Теперь можно в качестве значений параметров suspend функций передавать обычные функции (Suspend conversions)
2) Наконец-то сделали инструмент для оценки покрытия тестами в мультиплатформенных проектах
#tools@ergonomic_code #kotlin@ergonomic_code
The JetBrains Blog
Kotlin 1.6.0 Released | The Kotlin Blog
Kotlin 1.6.0 is now officially released with Stable exhaustive whens, Kover, and new memory manager for Kotlin/Native!
Привет!
Накатал лонгрид на 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…