Молния!

Я, возможно, тормоз, но я тут открыл github codespaces

И они реально работают - мне тут надо было подправить пулл реквест в спеку диаграммы эффектов, я открыл ветку в спейсе, мне открылся ВС Код, я там поставил плагин аскиидока, и открыл превью! О_О
Поставил вим и он заработал
А вот синк сеттинги на веб не поставились.
Но в любом случае, это вполне рабочий вариант что-то подхачить в приличной среде, не выходя из облака

#tools@ergonomic_code

Привет!

Вчера задеплоили в прод результаты первых трёх спринтов -первый кусочек (~20%) нового бэка Проекта Э, в проде нашли один баг нового бэка, и старый баг в старом бэке:) Я считаю неплохо.

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

Касательно Эргономичного подхода у меня на подходе (pun intended) лендинг для него - планирую зарелизать на следующей недели

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

После этого я наконец вернусь к большим постам. Сейчас у меня есть идеи четырёх потенциальный поста:
1) Наконец написать пост по декомпозиции проекта TSP на базе диаграммы эффектов
2) Пост о шаблоне раскладки кода по пакетам в Эргономичном подходе
3) Пост о том, почему я считаю, что ФП стиль даёт лучшие результаты, с точки зрения суммарной стоимости разработки
4) Собственный пост о функциональной архитектуре с заходом через трансформационно-центричную морфологию из структурного дизайна.

Так же практика прошлых лет показывает, что у меня первая половина года намного богаче на посты, чем вторая, так что стей тюнед, будет интересно:)

#project_e@ergonomic_code #ergo_approach@ergonomic_code

Привет!

Зарелизил анонсированный на прошлой недели лендинг Эргономичного подхода:)

Теперь вам есть куда отправить уставших от багов и вечных спринтов разработчиков и владельцев продуктов:)

Пользуясь случаем, хочу ещё раз выразить благодарность руководителям проектов, на которых я обкатывал ранние версии ЭП: Николаю Макарову, Денису Исаеву, Евгению Тимофееву и Дмитрию Семёнову - парни, без вас бы ЭП не было.

#ergo_approach@ergonomic_code

Привет!

Написал очередной микропост на тему того, "Почему ФП?".

#posts@ergonomic_code #whyfp@ergonomic_code

Привет!

А вот и подошла очередь анонсированного ранее релиза спеки диаграммы эффектов в0.1.0.

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

К этим изменениям в модели меня подтолкнули грамотные вопросы специалиста из documentat.io, у которых я заказал техническую редактуру спеки.
Это - полировка текста профессиональным техническим писателем - второе больше изменение в спеке.

#posts@ergonomic_code #effects_diagram@ergonomic_code #ergo_approach@ergonomic_code

Привет!

Нашёл железобетонный аргумент в пользу классической школы тестирования:)

> You may have heard of famous Classicist TDD practitioners including Uncle Bob and Kent Beck. If you want an example of a Mockist look no further than Sandi Metz, J.B Rainsberger or Steve Freeman
Test Driven Development Wars: Detroit vs London, Classicist vs Mockist

Так, ну анкл Боба и Бека каждая собака знает. Если что, Фаулер - тоже классицист.

А вот за эти ваши моки - что за господа (и дамы) с горы топят? Они даже в выдаче стартпейджа ниже футболистов. Единственное известное (мне) творение этих авторов - Growing Object-Oriented Software, Guided by Tests - Хориков (тоже классицист) в части дизайна и качества тестов разнёс в пух и прах.

А если серьёзно, я начинаю потихоньку отходить от абсолюта "не используйте моки никогда!" - так что не сильно удивляйтесь, увидев пост "Когда и как стоит использовать моки?":) Тизер: тогда, когда надо симулировать ошибку, отгородится от дорогой/медленной/нестабильной внешней системы и стараться мокать только стабильные интерфейсы.

#posts@ergonomic_code #ergo_testing@ergonomic_code #tdd@ergonomic_code #whynomock@ergonomic_code

Привет!

У меня появилась странная идея. Написать пост "Зачем декомпозировать систему?". Кажется, идея провалится, потому что ответ пока что сводится к "затем", но эта деятельность натолкнула меня на хорошую мысль.

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

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

Зато есть несколько вещей, в которых я уверен:
0. кодовая база должна иметь регулярную структуру, для того чтобы в ней было проще ориентироваться
1. декомпозиция второго уровня неизбежно будет дублироваться - внутри каждого модуля первого уровня надо будет поддерживать декомпозицию второго уровня, такую же, как и в соседних. Из-за этого декомпозицию второго уровня поддерживать сложнее, чем первого
2. техническая декомпозиция уже устоялась и практически не меняется. В разных командах могут быть небольшие отличия, но множества ключевых слоёв и типов классов имеют конечный размер. Благодаря этому техническую декомпозицию поддерживать просто.
3. декомпозиция предметной области (для всех проектов) не может быть устоявшейся, т.к. количество предметных областей условно бесконечно. Из-за этого:
3.1. каждой команде надо заново придумывать свою декомпозицию предметной области
3.2. декомпозиция может эволюционировать вместе с пониманием командой предметной области или даже самой предметной областью
3.3. поддерживать декомпозицию предметной области сложно - её нельзя заучить один раз на всю карьеру, она меняется даже в течении жизни одного проекта и в целом она может быть намного сложнее, чем 3 слоя и десяток типов классов

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

Ну а декомпозировать систему в принципе надо потому что потому. Я серьёзно. В литературе так и пишут
Например, в статье о структурном дизайне пишут, что мистер Константин "наблёл", что проще реализовывать и изменять те программы, что состоят из простых независимых модулей.
> Mr. Constantine has observed that programs that were the easiest to implement and change were those composed of simple, independent modules

Никакими фактическими данными по объективным метрикам наблюдения мистера Константина не подкрепляются.

Наконец, пришёл я ко всей этой цепочке в процессе [мысленной] дискуссии с Фаулером по мотивам его статьи о сцепленности, где он на первый (и единственный) уровень вытащил техническую декомпозицию и на которую я натолкнулся как раз в процессе поиска ответа на вопрос "зачем декомпозировать системы"

#ergo_approach@ergonomic_code #ergo_arch@ergonomic_code #papers@ergonomic_code

Привет!

Проснулись? Похмелились?:) Вот вам линко пост потупить в кровати, пока раскачиваетесь:) С прошедшим:)

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

#posts@ergonomic_code #http_api@ergonomic_code

Привет!

Чем задро люди, нашедшие работу по душе занимаются на праздничных днях? Правильно - переводят проекты на Spring Boot 3.

И я, будучи таким человеком, перевёл Проект Э на Spring Boot 3.
За пару месяцев работы в 3.5 лица мы нагенеряли довольно дофига кода - 300 *.kt-файлов и тем не менее переезд мне дался довольно легко. Сделал я его часа за 2, изменения внёс следующие:

1) очевидным образом, обновил версии
2) заменой по проекту поправил javax.* -> jakarta.*
3) Поменял com.github.tomakehurst:wiremock-jre8:2.35.0 -> com.github.tomakehurst:wiremock-jre8-standalone:2.35.0. Без этого были проблемы со спекой сервлетов, что ли
4) В конфиге Spring Security заменой по файлу поправил antMatchers -> requestMatchers
5) Руками поудалял ConstructorBinding
6) Больше всего времени ушло на то, чтобы реанимировать вытягивание доков к эндпоинтам в сваггере из котлин доков. Для этого пришлось руками добавить зависимость runtimeOnly("com.github.therapi:therapi-runtime-javadoc:0.15.0"), а допетрить до того, что этот джарник пропал из зависимостей (без ошибок) пришлось самостоятельно
7) всё. Все 100+ тестов (преимущественно пользовательских/внешних/функциональных/е2е) прошли, приложение благополучно задеплоилось на тестовый стенд. Но его ещё не тестили (почему-то), так что может что-то ещё вылезет. Если вылезет - напишу

Наверное, мне сильно помогло то, что проект я заводил за месяц до релиза Бута 3 и проект у меня был на Буте 2.7.4. Я на самом деле даже попытался сразу стартануть на бете Бута 3, но тогда не получилось завести то ли сваггер целиком, то ли вытягивание котлин доков - круто что уже через месяц после релиза это всё допилили.

При всём моём противоречивом (но всё более положительном в последнее время) отношении к Spring - они реально делают штуку, которая just works (tm).

#spring@ergonomic_code #project_e@ergonomic_code #case@ergonomic_code

Привет!

Посмотрел доклад "Меняем Spring Data JPA на Spring Data JDBC!". Хотя докладчик в начале сказал, что не призывает использовать JPA, мне что-то захотелось написать микропост в защиту Spring Data JDBC.

#talks@ergonomic_code #spring_data_jdbc@ergonomic_code

Привет!

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

Сейчас делаю второй подход к посту декомпозиции, откопал его, перечитал, снова впечатлился и на это раз решил поделиться с вами:)

#posts@ergonomic_code #coupling@ergonomic_code #cohesion@ergonomic_code

Привет!

Пост про ОО-декомпозицию начинает обретать вменяемый вид - надеюсь в течении пары недель закончить:)

А тем временем, буду радовать вас линкопостами:)
Вот очень крутой конспект/лекция (?) из MIT-а про изменяемость/неизменяемость, с хорошими примерами рисков, которые несёт изменяемость. Если вы по дефолту используете изменяемое состояние - рекомендую прочитать, может быть передумаете:)

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

#posts@ergonomic_code #whyfp@ergonomic_code #immutable_domain_model@ergonomic_code

Привет!

В продолжение темы неизменяемых данных: Почему Java делает так много штук неизменяемым?
ТЛ/ДР - потому что неизменяемые штуки потоко-безопасны и благодаря постоянным улучшениям JVM создание нового объекта зачастую может быть быстрее мутации старого

#posts@ergonomic_code #immutable_domain_model@ergonomic_code #java@ergonomic_code

Привет!

Что-то я прокрастинирую пост о декомпозиции. Самое мясо с декомпозицией написал, а вот полировка буксует - то пойду писать спинофф про эффекты, то доделывать спинофф "почему всё-таки объектно-ориентированная?", то пинать Spring Data Jdbc, то болеть.

Но я его точно допишу.

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

#posts@ergonomic_code

Привет!

Я молния! опечатка по фрейду

Молния! Я разочаровался в Spring Data JDBC. Вкратце, по трём причинам: отсутствие наследования, отсутствие спецификаций и отсутствие возможности автоматически подтянуть ридонли агрегат по ссылке. Потом, может, подробнее распишу.

Поэтому я снова полез гуглить идеальный орм и откопал любопытную штуку. Он пока у меня особо доверия не вызывает и на мой у него довольно многословное АПИ, но идея прикольная.

#tools@ergonomic_code @spring_data_jdbc@ergonomic_code #ergo_persistance@ergonomic_code

Привет!

У меня продолжается маниакальная стадия "мне нужен идеальный ОРМ" и я накопал ещё пару любопытных линок.

Либа персистентных (в смысле переживающих процесс) коллекций для Kotlin/Java. Она, кажется начинает подгнивать, но может пригодиться в некритичных задачах

Вы говорите в ОРМах много магии? А как насчёт МетаОРМа?

Наконец, на обе штуки я уже давал ссылки, но и себе и вам напомню, что существуют примеры того, что я считаю идеальной технологией персистанса: MicroStream и Erlang Mnesia

#posts@ergonomic_code #tools@ergonomic_code #ergo_persistance@ergonomic_code

Привет!

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

Не совсем согласен, но ознакомиться рекомендую.

#posts@ergonomic_code #coupling@ergonomic_code #structured_design@ergonomic_code

Привет!

Чуствую себя тем мальчиком из притчи, который кричал волки.

Сегодня у меня настоящая молния, но я, кажется, обесценил это слово в этом канале.

Меня с докладом про декомпозицию на базе эффектов взяли на JPoint!

Привет!

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

Однако, попадание в программу JPoint, некоторое упрощение задачи (отказ от полной детерменированности) и ещё одна бессонная ночь и у меня кое-что получилось.

Тематический тизер алгоритма декомпозиции:

fun clusterize(diagram: Diagram) {
    var proceed = true
    while (diagram.hasFreeElements() && proceed) {
        proceed = false
        for (r in diagram.freeResources) {
            val tightlyCoupledOperations = r.operations
                .filter { o -> o.resources.size == 1 ||
                               (o.writtenResources.size == 1 && o.writtenResources[0] == r) ||
                               (o.isReadOnly && God.isPrimaryResource(o, r)) }
            diagram.makeCluster(r, tightlyCoupledOperations)
            proceed = tightlyCoupledOperations.isNotEmpty()
        }

        for (e in diagram.freeElements) {
            val adjaсentClusters = e.elements.map { it.cluster }.toSet()
            if (adjecentClusters.size == 1) {
                diagram.extendCluster( adjacentClusters.first(), e)
                proceed = true
            }
        }

        for (r in diagram.freeResources) {
            val possiblePairs = r.operations.flatMap { it.resources }
            val bestMatch = God.findBestMatch(r, possiblePairs)
            if (bestMatch != null) {
                diagram.aggregate(r, bestMatch)
                proceed = true
            }
        }
    }
    if (diagram.hasFreeElements) {
        diagram.finalyzeClusterization()
    }
    diagram.nameClusters()
    diagram.hideSubmodules()
    diagram.groupModules()
}

Кажется, общий ход алгоритма получилось описать достаточно чётко:) А если учесть то, что сейчас могут нейронные сети, то, кажется, они вполне могут справиться с реализацией функций isPrimaryResource и findBestMatch не как боженька, конечно, но не хуже джуна уж точно.

Т.е. гипотетически, алгоритм объектно-ориентированной декомпозиции действительно можно сделать полностью автоматическим. Подаёшь на вход .drawio файл с диаграммой эффектов и на выход получаешь .drawio файл, с декомпозицией, которую надо просто перепроверить. Ну а генератор скелета проекта по drawio файлу с декомпозицией я прямо сейчас без всяких нейронных сетей за вечерок напишу.

А с учётом того, что нейронные сети уже умеют писать код и моих склонностей к мании величия и нарциссизму, у меня в мечтах диаграмма эффектов уже стала самым распространённым языком программирования 5-ого поколения:) М? Мощно задвинул?:)

Осталась только самая мелочь - забутстрапить систему и нарисовать диаграмму эффектов, по которой GitHub copilot сможет сгенерировать код генерации кода по диаграмме эффектов:)

Привет!

Студент прислал еженедельный отчёт:)

Я считаю это успех

Привет!

По посту с декомпозицией пока особых новостей нет и не будет до JPoint-а, поэтому пока накатал микропост с описанием опыта внедерния тулов статического анализа кода (Detekt, Kover, ArchUnit) в Проект Э.

#posts@ergonomic_code #tools@ergonomic_code #case@ergonomic_code