Привет!

Всегда запускал БД в тестконтейнере один раз на запуск тестов и чувствовал себя при этом плохишом.

А тут выяснилось, что это идиоматичный способ работы с тестконтейнерами. Стабильность тестов при этом не увеличилась, конечно, зато чувствую себя теперь пионером:) Тем который всем пример:)

#posts@ergonomic_code #ergo_testing@ergonomic_code #integration_tests@ergonomic_code

Привет!

Большая и довольно хардкорная статья о структурном конкурентном программировании (как вариант - корутины Котлина) и что оно даёт.

ТЛ ДР: примерно то же, что и структурное последовательное программирование:)

#posts@ergonomic_code

Привет!

Скреативил пост в формате "ночные мысли вслух". Вообще ему место здесь, в канале, но там куча картинок, поэтому опубликовал на сайте.

И как-то так вышло, что я случайно изложил в нём всю суть Эргономичного подхода:)

#posts@ergonomic_code #ergo_arch@ergonomic_code #ergo_approach

Привет!

В Applying UML and Patterns вычитал третью интерператцию OCP:
> In the context of OCP, the phrase "closed with respect to X" means that clients are not affected if X changes. For example, "the class is closed with respect to instance field definitions" through the mechanism of data encapsulation with private fields and public accessing methods. At the same time, they are open to modifying the definitions of the private data, because outside clients are not directly coupled to the private data.

Тут под OCP понимается инкапсуляция чего-либо за интерфейсом - т.е. возможность изменить это без изменения клиентов.

Первая интерпретация, у Мейера - язык программирования должен обеспечивать возможность инкапсуляции.

Вторая интерпретация у Мартина - части поведения модуля должны инжектиться, чтобы можно было изменять поведение модуля, без изменения самого модуля.

Кому верить - вопрос на миллион. Наврное всё-таки Мартину, т.к. в этом случае больше вероятность того, что вас правильно поймут.

#books@ergonomic_code #solid@ergonomic_code

Хм, я тут понял, нас (разработчиков) сложно найти (рынок перегрет), легко потерять (рынок перегрет) и невозможно забыть (как минимум - в гите записи останутся, а то и набор костылей, подпорок и багов:) )

В Кольцовской поликлинике тетенька, которая принимает документы на прививку, сидит на Gnome 2:) хз какой дистрибутив, поди астра какая-нибудь

πfs - файловая система, которая "хранит данные в числе пи":)

Привет!

Выжимка из выжимки о тестировании:)

1) избегайте моков любой ценой. в оригинале - "используйте их только на границах модулей". Моя версия - используйте их только для систем вне вашего контроля (внешине сервисы)
2) Избегайте деталей реализации, тестируйте поведение - изменение состояние заметное внешнему наблюдателю
3) Триггером нового теста является не новый метод или класс, а новое требование. Или старый баг - прим. пер.
4) Пишите тесты, которые проверяют юз кейсы или юзер стори
5) изолировать надо не тестирумый класс, от остального кода, а сами тесты друг от друга

Там есть ещё пара пунктов о том, что надо мокать БД и дёргать код напрямую, а не через HTTP. Но тут я не согласен - такие тесты лично мне не дают уверености, что всё работает

#posts@ergonomic_code #whynomocks@ergonomic_code #ergo_testing@ergonomic_code

Говорят ФБ прилёг
Ещё говорят, что сотрудники ФБ не могут войти в здание чтобы починить ФБ, потому что у них электронные ключи, которые не работают без ФБ

Вот почему нам нужны децентрализованные сервисы

Т - технологии
Д - дилемма

https://twitter.com/leahmcelrath/status/1445100877933694976?s=20

Привет!

Соскучились?:) Я - да:)

Сейчас будет три микро поста:)

Дочитал хроники архитектуры и мне есть много чего сказать по ней.

Во-первых, посты 1-16 содержат сеньерский минимум на мой взгляд. Если человек называет себя сеньером, техлидом или архитектором, но не знает чего-то из этого - у меня появятся большие вопросы к его любознательности, и как следствие квалификации.

Во-вторых, посты 17-19 содержат неплохой вариант предельно гибкой (а значит дорогой) архитектуры. Я с этими постами согласен процентов на 60-80 и уж точно лучше так, чем ни как - будет всё равно удобнее и дешевеле, чем Big Ball of Mud. Но, я бы их сильно сдобрил ФП и на мой взгляд сейчас для индустрии намного актуальнее вопрос того, как делать хорошие приложения, чем как делать гибкие во все стороны приложения.

Наконец, заключение серии навело меня на умную мысль.

Там мужик, в след за Эвансом и Мартином пишет, что именно ядро (бизнес-логика, юз кейсы, бизнес-правила) отличает систему от конкурентов. В целом, по большому счету, я согласен. Но как обычно есть но.

Допустим, все конкуренты используют условный Spring Data JPA. А мы, допустим, используем условный Spring Data JDBC и благодаря этому, допустим, наш продукт:
1) В целом быстрее для пользователей
2) Требует меньше ресурсов железа
3) Содержит меньше багов
4) Быстрее получает новые фичи
5) Благодаря пп 2-4, дешевле

Это всё разве не будет отличительным фактором (и конкурентным преимуществом)? Мне кажется будет.

В общем серию рекомендую к прочтению - она несёт больше пользы, чем вреда.

Я же, тем временем, тоже не катал вату. Я наконец определил содержание книги и написал черновик тизера первой части книги. Уже совсем скоро, я наконец опубликую кусок авторского контента.

#posts@ergonomic_code

По мотивам всё той же хроники архитектуры, перелистывал книгу по 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

Ну и наконец, линко-пост о кэшировании в Spring Data JDBC.

Про кеширование там полезно тем, что подсвечивают ряд граблей, свойственных JDBC, но самое полезное - раздел Why Spring Data does no caching, в котром автор пинает JPA.

Подписываюсь под каждым словом этого раздела всеми ~8 годами своих мучений с JPA/Hibernate в проде.

#posts@ergonomic_code #spring_data_jdbc@ergonomic_code

Привет!

Мне тут довелось пообщаться с адептами микросервисов и ох. Я понял, что многие люди видят их в качестве решения проблемы плохоспроектированного кода. В итоге получают плохоспроектированный распрделённый код и все следующие за этим беды.

С другой стороны, я понял, что у меня самого нет внятного понимания, когда модулярный монолит пора начинать резать на отдельные сервисы.

Начал изучать тему и наткнулся на огненный видос, с ответом на этот вопрос. Настоятельно рекомендую его посмотреть перед выбором МС в качестве архитектуры - в противном случае, с большой долей вероятности, сначала будет немножечко приятно, а потом очень больно и всю оставшуюся жизнь ни за что.

Ещё, чувак в слух проговорил, но на графике стоимости не нарисовал четвёртый вариант - начать с хорошо сделанного модулярного монолита, а потом по необходимости и без сложностей вырезать из него микросервисы. Это даст бенефиты обоих подходов. Это эргономичный подход к разработке очень больших систем.

#talks@ergonomic_code #why_no_microservices@ergonomic_code

Привет!

Немного офтопа, но на злободневную тему

Заболели с женой одновременно ковидом.

Жена уже на 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

Привет!

Сегодня у меня новый формат поста - "вопрос к экспертам по 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