Привет!

Ковидно-депрессивные мысли вслух.

Что-то меня в последнее время жизнь посталкивала с энтерпрайзными 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, когда файл с таким идом есть, но не картинка?

Что посоветуете?

Привет!

Наконец-то прочитал пару классических научных статей по ФП:
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

Привет!

Накатал лонгрид на 40 минут чтения с описанием того, чем и почему эргономичный подход отличается от обычного.

Но при этом у меня закрались сомнения.
Я пинаю "обычный" подход.
Но что такое "обычный" подход - это подход который я видел в своей практике.
А моя практика - 10-20 проектов/команд. И то, что я вижу в интернете.

Так вот - может весь мир уже пишет в эргономичном подходе и выкинул JPA, а у меня просто выборка опыта кривая?

Как по вашему, практики эргономичного подхода отличаются от наиболее распространённых?

#posts@ergonomic_code #ergo_approach@ergonomic_code

Привет!

Про тип: если в идеи в build.gradle вставить зависимость в maven-формате, идея сама сконвертит 🤯

#tools@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

Привет!

Я замотался и забыл выпустить пресс-релиз, что 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

Привет!

А вот и обещанный пост о структурах программ, к которым я стремлюсь в работе.

Но этот раз всего 20 минут и с картинками:)

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

А все же уже в курсе про горячий (уже тёплый) пирожок от JetBrains?

#tools@ergonomic_code

Привет!

Немного пиара Котлина вам в ленту:)

Вышел Compose Multiplatform 1.0 Release :)

Анонсировали AWS SDK для Котлина (и Swift с Rust)

#tools@ergonomic_code #kotlin@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

Привет!

Мне тут попался проект с пакетированием по слоям представляющий из себя сферический 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

Привет!

Это снова я:)

Анкл Боб недавно написал новый пост с восхвалением ФП.
Да-да, это тот самый Анкл Боб, который придумал SOLID - "5 основных принципов объектно-ориентированного программирования", согласно русской Википедии.

#posts@ergonomic_code #fp@ergonomic_code

Привет!

Сегодня я надел свою шляпу параноика.

Ещё одна реальная история бана большим братом аккаунта простого юзера со всеми данным.