Ну и раз уж я вас сегодня заспамил, то вот ещё немного:)
Запилил оператор terminateOn для Kotlin sequence&flow
Предполагаемый юзкейс - функциональное описание эффективной операции до получения терминального значения - считай ретрай

юзается примерно так:

    val res = sequnceOf(1, 2, 3)
                        .map { delay(it) ; getEntityStatusOnServer() }
                        .take(15)
                        .terminateOn { it.isSuccess() || it.isFailed }
                        .last()
    when (res.status) {
        success -> println("success")
        pending -> println("timeout")
        failure-> println("process failed on server")
        network_failure-> println("status fetch failed")
    }

#tools@ergonomic_code #kotlin@ergonomic_code

Привет!

Наткунлся на прикольную статью об объектах и абстрактных типах данных. Не особо практичная, именно прикольная - автор приходит к выводу, что функции высших порядков чаще используются в ОО, чем ФП программах, и что лямбда исчесления были "untyped λ-calculus was the first object-oriented language.":)

Более практично же обеъекты и АДТ рассмотрены в этой статье.

Если в кратце - объекты не должны быть единственным инструментом разработчка. Объекты надо применять, когда вероятность появления новых типов (наследников, реализаций интерфейсов), выше вероятности появления новых данных - в этом случае "данные" (Алгебраические типы данных), позволят добавить их не трогая старый код.

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

#papers@ergonomic_code #oop@ergonomic_code #fp@ergonomic_code

Привет!

Пыль от поста на Хабре улеглась и пришло время подводить итоги:)

1) +4 к карме (+5 -1)
2) +13 рейтинг поста (+19 -6)
3) +1 предложение писать за деньги в один из топовых блогов на Хабре
4) 67 закладок
5) 0 конструктивной критики в комментах (по данным разведки)
6) +26 (+80%) подписчиков канала

Я считаю, что авантюра стала успешной.

Самым важным результатом для меня стали новые читатели - рад вас приветствовать в своём канале и спасибо за доверие.

Такой рост аудитории - хороший повод ещё раз написать, что я за движуху вообще здесь затеял.

Если коротко - то в последние несколько лет у меня стало получаться писать код, который поддерживать и развивать чуть менее больно, чем код, написанный в "стандартном" (для бэков на Java) стиле.
В книге, блоге и канале я пишу что я делаю по другому, почему я это делаю по другому и как я это делаю.

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

Привет!

Дочитал Just Enough Software Architecture: A Risk-Driven Approach

Она прекрасна - пожалуй лучшая книга по архитектуре и роли архитектора, что я прочитал, рекомендую:)

#books@ergonomic_code #design@ergonomic_code

Привет!

Хотел написать небольшую заметку о SRP, OCP и дизайне типов и залип на 3 часа:)

Представляю вам пост ... <барабанная дробь>... Анкл Боб не всегда прав - критичное настроение всё ещё со мной:) В отпуск мне надо:)

#posts@ergonomic_code #solid@ergonomic_code

хехей, нас 1000000b:)
а ещё 2 недели назад было на порядок меньше:)
экспоненциальный рост есть, можно идти к инвесторам:)

Привет!
Пролистал по диагонали Principles of Package Design - не со всем согласен, но в целом хорошая книга, несёт намного больше пользы, чем вреда
Только не надо брать на вооружиение суффикс Interface, уш лучше префикс I:)

Советую к прочтению молодым программистам, а так же опытным, у которых в проектах:
1) нет модуля core, не зависящего ни от чего
2) есть пакеты service, entities etc с 10+ классов
3) есть пакеты enums, exceptions, dtos
4) есть классы с 7+ полей
Там объясняется почему это плохо и как этого избежать
Если не знали, что Анкл Боба 11, принципов, а не 5 - тоже можно почитать. В этой книге принципы расписаны подробнее, чем у самого Мартина:)

#books@ergonomic_code

Привет!

Небольшой параноидальный оффтоп: https://twitter.com/sdw/status/1389661120500174856?s=20

сигнал запустил рекламную компанию, в которой выдавал юзерам инфу, которую о них знает и перепродаёт фейсбук. Фейсбук их забанил.

А я между делом намылился заказать PinePhone:)

Привет!

Сегодня 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