Привет!

Сегодня heartbeat-ный линко пост:)

A co-Relational Model of Data for Large Shared Data Banks - статья Эрика Мейера о том, что Sql и NoSql (на самом деле реляционная и "ключ-значение" модели данных) являются дуальностями:
> What this all means is that coSQL and SQL are not in conflict, like good and evil. Instead they are two opposites that coexist in harmony and can transmute into each other like yin and yang. Because of the common query language based on monads, both can be implemented using the same principles.

Эрик Мейер - мужик который запил LINQ в C# и Rx*, я думаю его можно назвать отцом реактивной движухи в прошлом десятилетии

#posts@ergonomic_code #relational_model@ergonomic_code #sql@ergonomic_code

Привет!

Внезапно (для меня) вышла Scala 3
Я с одной стороны смотрю и понимаю, что будет ещё больший ад для коммерческого программирования, а с другой стороны руки зачесались почитать/потыкать:)

Я порадовался/заинтересовался следующим фичам:
1) сделали скобки опциональными
2) выкинули new
3) вроде прибрались в имплиситах и заменили их на гору нового синтаксиса
4) прикрутили экстеншн функции своим особым способом
5) запилили колтин-подобные DSLи своим особым образом
6) запилили opaque типы
7) запилили union types - наконец-то! Хоть кто-то кроме мёртвого Цейлона
8) классы теперь final по дефолту
9) запилил поддержку делегации своим особым способом
10) запилил null-safety своим особым способом
11) запиили инлайн функции

Короче, имхо, изучение третьей скалы поможет хорошенько потянуть мозг и расширить кругозор в области дизайна языков
А сама Скала 3 - прекрасный инструмент для креативного программирования фо фан.

А вот в продакшн я бы не рискнул её тащить

Привет!

Я готовлю серию постов о SOLID, и чёт это не так просто оказалось, поэтому залип:)

А пока немного агитации за Котлин:)

Q: I want know what is benefit use of kotlin instanced of java for android app development
A: besides the subjective things like "fun to write" etc, there are also objective metrics - we found that among top apps for the ones that are written in Kotlin users see on average a 10% reduction in crashes.

https://www.reddit.com/r/Kotlin/comments/nm2eaf/kotlin_team_ama_3_ask_us_anything/gzm654b?utm_source=share&utm_medium=web2x&context=3

#kotlin@ergonomic_code

Я тут в комментах к предыдущему посту я ещё один микропост написал, о том почему на мой взгляд Котлин это не временное явление:)
https://t.me/ergonomic_code/76?comment=260

Привет!

Я начал писать третий вариант сериии/поста о солид:)

Поэтому снова ссылка:) Когда использовать моки, по версии анкл Боба
Суть:
1) Только на границах системы - внешние системы, СУБД. веб-сервер. И я даже тут не согласен -
1.1) интеграцию приложения с веб-сервером, я проверяю интеграционными тестами (которые работают по HTTP) и тут мокам сервера я не верю,
1.2) лоигку работы приложения я проверяю через "сервисы" - и тут сервер уже вообще не нужен.
2) СУБД я запускаю в контейнере на каждый запуск тестов. Это даёт константную прибавку ко времени тестов в 5-10 секунд. А потом я уже не вижу разницы во времени работы. Я даже как-то баловался с тем, чтобы контейнер завести на RAM-диске - у меня разницы не было, но с HDD, наверное на этот стоит заморочиться
3) Вобщем я только мокаю внешние системы (https://azhidkov.pro/posts/21/03/210321-project-l-testing/)

#posts@ergonomic_code #whynomocks@ergonomic_code

Привет!

Экспозиция примеров нарушения LSP и их мотивации: https://github.com/spring-projects/spring-framework/issues/17787

> it would be easier to only maintain the additional feature of the "overridden" method.

> The easiest solution for us, if it were possible, would be to mark the PUT/POST/DELETE methods of the subclass as not accessible.

Наследование вообще плохая идея, а такое его использование - просто ужас

#posts@ergonomic_code #solid@ergonomic_code #spring@ergonomic_code

Привет!

Я два месяца возился с SOLID вообще и SRP в частности и наконец-то осилил первый пост про SRP.

И этот факт многое говорит о простоте и понятности этих штуковин:)

Чтобы следующие два месяца ждать было повеслее, раскажу о чём я хочу ещё написать:)

Про SRP можно написать ещё как минимум два поста:
- часто забываемая половина про объединение "штук" которые меняются вместе
- подробнее расписать, чем я предлагаю руководствоваться при разработке ПО.

И про остальные принципы мне тоже есть что сказать:)

Плюс на ближайшее время у меня есть идея двух небольших заметок:
- читайте свой код. О технике поиска проблем в дизайне через чтение кода как текста на естественном языке
- ещё чутка попинать JPA, за нарушение структуры поддерживаемых приложений, открытого ещё в 70ых

Далее у меня есть хвосты о которых я помню:
1) Дописать итог к серии постов о видах функций
2) Пост с критикой пакетирования по слоям

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

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

#posts@ergonomic_code #solid@ergonomic_code

Случилось чудо

В поисках Structured design: fundamentals of a discipline of computer program and systems design я перекапал весь инет и даже по оффлайн библиоткам пошукал - нашёл только на архив.орге.

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

В общем рекомендую эту книгу. Она хоть и 77ого года, ну уже тогда изобрели как правильно делать информационные системы и с тех пор по сути ничего особо не поменялось.

Ну и заодно - https://archive.org/ тоже оказалась крутая штука:)
Там читать не особо удобно (картинки в браузере с арендой на час), но там много того, что нагуглить не получается. Плюс читать там - легально:)

#books@ergonomic_code #structured_design@ergonomic_code

Фух, опубликовал наконец статью об СРП, вздохнул полной грудью и Остапа понесло:)

Сам ещё не читал, но судя по картинкам накапал прям огненную статью о дизайне информационных систем: https://herbertograca.com/2017/11/16/explicit-architecture-01-ddd-hexagonal-onion-clean-cqrs-how-i-put-it-all-together/

у неё в конце даже ссылка на русскую версию есть:)

#posts@ergonomic_code

Привет!

Крутой доклад о единственно верном функциональном подходе к управлению состоянием.
И львиная доля кода на JSе:)

Настоятельно рекомендую всем, у кого состояние ещё раскидано по всему приложению

#talks@ergonomic_code #functional_architecture@ergonomic_code #js@ergonomic_code

Привет!

Канал уходит на каникулы.

На фоне Новосибирской жары я понял что дико устал, так что ухожу на каникулы до сентября.

Всем хорошего (и комфорнтного!), лета:)

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

Привет!

Начинаю потихоньку возвращаться с каникул и решил написать линко-мысли-в-слухо-пост.

Подвернулся недавно вот этот пост.

Если вкратце, Лукас Эдер (автор jooq-а), предлагает тянуть json сразу из базы, не заморачиваясь на маппинг в энтити, а потом в ДТО.

И этот пост прям хорошо лёг на то, что я в последние пару месяцев качнулся в сторону "облегчения" разработки. Я тут недавно в одном из своих "хорошо" спроектированных проектов добавлял одно поле и мне для этого потребовалось потрогать штук 5-6 классов, в паре-тройке пакетов. И мне это не понравилось. А с таким подходом мне надо было бы поправить ровно два места - в схеме БД и в запросе. Это та самая вторая часть SRP - одна "вещь" должна делаться в одном месте.

До этого подхода тоже, конечно, можно докопаться с разной степенью успешности:

1. Он подходит только если json сливается напрямую в ответ, без какой либо обработки в приложении.
2. Он не подходит если итоговый ответ надо собрать из нескольких источников.
3. Слой работы с БД по факту сцепляется с веб-слоем. Если в ответе надо будет поменять имя поля, то это надо будет делать в репозе.
4. Логика помещается в БД. Тут я уже не согласен. Во-первых, это вообще сейчас модно (Datomic, VoltDB, например, реализуют транзакции только через хранимки). Во-вторых, логика всё равно остаётся в "приложении" - в том же репозитории, по соседству с вызывающим кодом. Написана просто на встроенном DSL-е.
5. Зависит от технологии работы с БД и самой БД, но скорее всего прямо json из базы вернётся каким-то специфичным для базы типом. И это уже будет нарушением принципа сокрытия информации, что совсем плохо. Это можно обойти, вернув из базы или репоза строку и получив stringly typed код.

Тем не менее, мне кажется что для простого веб АПИ к БД, такой подход должен хорошо работать. Я собираюсь попробовать:)

Так же этот подход хорошо согласуется с ещё одной идеей по облегчению разработки - замена "тупых" сервисов на функциональные типы. Мне всегда резал глаз код вроде этого:

class UsersConf {
    @Bean fun usersRepo() = UsersRepo()
    @Bean fun usersService() = UsersService(usersRepo())
    @Bean fun usersController() = UsersController(usersService())
}
class UsersController(val usersService: UsersService) {
    fun findById(id: Long) = userService.findById(id)
}
class UsersService(val usersRepo: UsersRepo) {
    fun findById(id: Long) = userRepo.findById(id)
}

Сейчас я хочу попробовать вместо этого писать так:

class UsersConf {
    @Bean fun usersRepo() = UsersRepo()
    @Bean fun usersController() = UsersController(usersRepo()::findById)
}
class UsersController(val findUserById: (Long) -> User) {
    fun findById(id: Long) = findUserById(id)
}

Кода меньше, а в плане связности так даже лучше - контроллер вообще зависит только от платформы.

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

P.S.

Как вытянуть json в Postgres

#posts@ergonomic_code #ergo_persistance@ergonomic_code #ergo_approach@ergonomic_code #databases@ergonomic_code

Привет!

На новый пост я ещё не созрел, но созрел длить яду в пост о жэпэа:)

Привет!

Протип: в идее (ультимейте) есть встроенный тул для визуализации планов SQL-запросов

Попасть туда можно через Ctrl+Shift+A -> Explain*, стоя курсором на запросе

https://www.jetbrains.com/datagrip/features/executing.html

#tools@ergonomic_code

И ещё линка
Я постоянно между делом попинываю тестирование с моками, но свой развёрнутый пост на эту тему ещё не написал. А тут мужик всё правильно написал, да ещё и на русском.

Я уже находил блог этого мужика - хороший мужик, рекомендую подписаться. Блог правда на английском

#posts@ergonomic_code #ergo_testing@ergonomic_code #terminology@ergonomic_code

Привет!

Ещё чуть-чуть хейта хибера :)
Скажите, когда хватит:)

#posts@ergonomic_code #whynojpa@ergonomic_code

Привет!

Ночные мысли.

Хибер и спринговый компонент скан вроде как дожны увеличить продуктивность программиста. С одной стороны.

С другой стороны, по моему опыту, проект на хибере и компонент скане в среднем стартует 30-60 секунд. На моём топовом 12-ядерном i7 19ого года с 32 гигами быстрой оперативы и быстром ссд.

И я никогда не жду эти 30-60 глядя в консоль. В лучшем случае иду чатики проверить. А то и покурить. И хорошо если не в курилку, где легко можно на полчаса залипнуть (когда в офисе работал).

В итоге один рестарт приложения стоит в среднем минут 5.

А спринг и хибер не особо дружат с хот релоадом. Да и я не уверен, что многие девелоперы вообще знают о нём. Но даже с хот релоадом у меня выходит

В общем такой наброс: компонент скан и хибер увеличивают время разработки на 10% только за счёт времени старта (не говоря уж о войне с автомагией и адовыми багами вызванными её не правильным использованием).

Увеличивают ли они продуктивность на столько же? Не уверен.

#ergo_approach@ergonomic_code #whynojpa@ergonomic_code #spring@ergonomic_code

Прикольный тред (не сильно длинный, минут 5-10) о происхождении термина boilerplate. И, внезапно, это однокоренное слово с "Бойлер"

#posts@ergonomic_code

Привет!

Утренние мысли.

В рамках концепции
> В общем буду теперь двигать эргономичный подход в сторону баланса между удобством навигации/рефакторинга/типобезопасностью и количеством кода, который надо навигировать/рефакторить/использовать.

решил попробовать чутка сдать позиции, и пустить spring data jdbc в слой домена, и спринг в целом в слой приложения/юз кейсов/интеракторов. На этом фоне, внезапно подумал, что надо поглядедь на код анкл Боба - может всё-таки без этого можно обойтись и всё придумано до нас.

А там - ни одной информационной системы. Есть Fitnesse, которая судя по всему с БД вообще не работает. Есть пачка всяких игр и симуляторов, всякая мелочёвка и всё.

Тогда я решил залезть в репоз 8th light (которы вроде бы связанной с анкл Бобом). Там тоже всякая мелочёвка.

Дальше я пошёл просто шукать по гитхабу Clean Architecture. Тут уже появились демо проектики с одной сущностью. Но всё ещё ни одного реального репоза с проектом хотя бы на 5-10 сущностей.

Писать посты и рисовать красивые картинки легко - сам так делаю:) Но “Talk is cheap. Show me the code.” (c) Torvalds.
Знаете хоть один живой пример проекта с чистой архитектурой?

При том, что мне концептуально нравиться идея чистой архитектуры, мне надо учить людей писать реальный код за конкурентноспособную цену, а не демо проектики или шедевры дизайна.

Пойду дальше искать своего Грааля:)

#ergo_approach@ergonomic_code #ergo_persistance@ergonomic_code #clean_architecture@ergonomic_code #posts@ergonomic_code