Привет!

Я несколько лет назад придумал тезис: у бизнеса и разработчиков одна цель - быстро выпускать фичи без багов.

И, как и львиная других моих придумок, эта тоже оказалась бояном:)
Наткнулся на целый пост на эту тему, который навёл меня на цепочку мыслей:

- Я (пока что скорее голословно) утверждаю, что ЭП позволяет быстро выпускать фичи с минимумом багов

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

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

Осталось сделать самую "малость" - провести двойные слепые рандомизированные исследования об эффективности работы по ЭП и... неЭП

#posts@ergonomic_code

И заодно -- как вы относитесь к явной рекламе?

В духе "этот пост подготовлен при поддержке тех-то" или "такие-то ребята заплатили мне за то, чтобы я ознакомился с их продуктом и написал пост о впечатлениях"

Сейчас сделаю опрос

Привет!

Если долгими томными вечерами вы как и я любите позаниматься странным - например, почитать древние научные статьи на английском - то рекомендую почитать статью VALUES AND OBJECTS IN PROGRAMMING LANGUAGES, которая рассматривает с математически-философской точки зрению разницу между объектами и данными (ака сущностями и объектами-значениями).

ТЛДР - объекты изменяемые, а данные - нет; и в реальной жизни надо и то и то.

Ещё пара хлёстких цитат оттуда:
1) "Computer science - это объектно-ориентированная математика"
2) Программирование - это объектно-ориентированная математика, математика - это "value-oriented" программирование.

Эта статья подтолкнула меня поискать объекты в Trainer Advisor. И хотя конструкция object встречается 17 раз, изменяемый объект я нашёл только один - билдер динамических запросов. И то он изменяемый только потому, что Котлин (пока?) не достаточно data-oriented и не поддерживает литералы списков и мап.

В общем жить в прикладном коде без объектов - вполне реально.
Если не знаете, как сделать сущности неизменяемыми - с помощью эпохальной модели времени (видео, текст)

#papers@@ergonomic_code #oop@ergonomic_code #dop@ergonomic_code

И про рекламу

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

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

В итоге я сформировал следующую позицию (с учётом того, что большинство читателей не против рекламы):
1) У меня нет и не будет цели монетизировать этот канал с помощью рекламы
2) Но я допускаю размещение рекламы для развития канала, при условии что:
2.1) Рекламируемый продукт не противоречит УК РФ и моим морально-этическим убеждениям
2.2) Реклама будет сопровождаться соответствующим дисклеймером
2.3) Я сам верю в то, что пишу

Исходя из этой позиции, я вижу два возможных вида рекламы на канале:
1) Поддержка поста - я посвящаю написанию текущего поста дополнительное время, пропорционально "рекламному бюджету" и в замен добавляю в пост ссылку на рекламодателя со словами, что пост написан при его поддержке

2) Совместный проект - сейчас в голову приходит только мой приход в гости в чей-то подкаст и соответственно ссылки друг на друга, но в целом возможны и другие варианты.

Привет!

Финализирую первый пост с описанием тестирования TA и походу дела накапал небольшую неопубликованную заметку с его архитектурой и стеком. И вот опубликовал:)

А пост с тестированием, думаю, на этой недели опубликую.

#trainer_advisor@ergonomic_code

Привет!

Опубликовал первый пост про тестирование TA с общими идеями и принципами (но уже здесь с иллюстрациями реальным кодом из TA).

#trainer_advisor@ergonomic_code #ergo_testing@ergonomic_code

И тизер следующей части, где кода и картинок больше, чем текста:)

Привет!

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

Лично меня больше всего порадовала мысль Андроид разработчика, что бэк - это не деталь реализации, а домен:)

Правда следуя этой логике, можно прийти и к тому, что БД - это не деталь реализации, а домен:)
Что, на самом-то деле, похоже на правду - я уже не раз выкидывал "ядро" системы в виде кода, оставляя "деталь реализации" в виде данных в текущей схеме и строил новое ядро поверх этой детали.

#posts@ergonomic_code #clean_architecture@ergonomic_code

Привет!

Если вы как и я в последние лет 6 несколько раз пытались дедуплцировать версии зависимостей в мультипроектном Gradle-билде на Kotlin DSL и всякий раз терпели крах: кажется, наконец-то появился вменяемый способ это сделать - в 7-ом Грэдле оказывается появилась фича каталога версий

#tools@@ergonomic_code #gradle@ergonomic_code

Привет!

Меня тут после 3ёх лет работы исключительно на Kotlin (+ Spring Data JDBC) занесло писать на Java 8 (+ JPA).

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

В общем, если вы сейчас на Java (даже свежей - там всё равно нет null-safety и нормальных утилит манипуляции данными) - рекомендую попробовать Kotlin - DevX у Котлина на порядок выше.

P.S>
В комментариях пишут про другой опыт - видимо, тут как и везде на вкус и цвет:)
Но, тем не менее, если ещё не пробовали Kotlin - попробуйте - возможно наши вкусы совпадают и тогда вас ждёт чудный новый мир:)

А чтобы интереснее было пробовать - можно мне в Trainer Advisor поконтрибьютить:)

#whykotlin@ergonomic_code

Привет!

"Золотые слова, Юрий Венедиктович!"

Доклад: https://www.youtube.com/watch?v=9Q7GANXn02k

#talks@ergonomic_code #why_no_microservices@ergonomic_code

Привет!

Опубликовал второй кусочек описания тестирования Trainer Advisor - сетап system under test.

#trainer_advisor@ergonomic_code #ergo_testing@ergonomic_code

Привет!

Начал читать Code That Fits in Your Head, пока прочитал только 50 страниц, но книга уже нравится.

В частности там есть очень крутой заход на важность локальности рассуждений/исключения скрытых эффектов через Систему 1 Канемана из Думай медленно… Решай быстро, который получил нобелевскую премию за исследования описанные в этой книге.

Так вот, Канеман говорит, что у нас есть два режима мышления - Система 1 и Система 2.
Система 1 - это то как мы размышляем обычно - на автомате, без затрат усилий
Система 2 - это когда мы целенаправленно прикладываем усилия для размышлений.

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

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

fun main() {
    val els: ArrayList<Int> = arrayListOf(2, 2)
    val sum = sum(els)
    println("Сумма ${els[0]} + ${els[1]} = $sum")
}

То глядя на него Система 1 быстро придумает историю, что sum вернёт значение, не поменяв els и выводом программы будет "Сумма 2 + 2 = 4". А это не так.

В общем минимизируйте количество изменяемого состояния в ваших программах, чтобы истории ваших Систем 1 чаще были правдоподобными:)

#whyfp@ergonomic_code #books@ergonomic_code

Привет!

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

#posts@ergonomic_code

Привет!

Я тут проснулся с мыслю - а вам не кажется, что Микросервисная, Гексагональня и Кричащая архитектуры - это всё про разное? И один проект может соответствовать всем трём сразу?

Привет!

Решил попробовать завести группу, посвящённую применению основных идей ЭП (модульные монолиты, неизменяемую модель данных, функциональную архитектуру, интеграционные тесты, outside in TDD, data-oriented programming) на практике.

Задумка такая, что столкнувшись с проблемой в собственной практике вы приносите её в группу и остальные члены группы (как минимум я), накидывают идеи и соображения по решению.

Присоединяйтесь, будет полезно:)

P.S. Буду благодарен за репост:)

И опубликовал очередной кусочек описания тестирования Trainer Advisor - формирование фикстурных объектов и их вставка в БД.

Там из 34К знаков 14К - код, почти половина:).

P.s. сбросьте кэш браузера, чтобы подтянуть css с выделеним строк в некоторых из сниппетов

#trainer_advisor@ergonomic_code #ergo_testing@ergonomic_code

Привет!

Забрёл сегодня в блог анкл Боба, там наткнулся на древний пост, а там:

OO is not about state.
Objects are not data structures. Objects may use data structures; but the manner in which those data structures are used or contained is hidden. This is why data fields are private. From the outside looking in you cannot see any state. All you can see are functions. Therefore Objects are about functions not about state.
When objects are used as data structures it is a design smell; and it always has been. When tools like Hibernate call themselves object-relational mappers, they are incorrect. ORMs don’t map relational data to objects; they map relational data to data structures. Those data structures are not objects.
Objects are bags of functions, not bags of data.

#posts@ergonomic_code #oop@ergonomic_code