Привет!

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

Подвернулась под руку хорошая статья по дизайну 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

Привет!

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

У них там тоже граф, но однородный - и операции и ресурсы представленны одинаково, плюс ещё есть понятие артефакта (выводимые данные). А вот связи между ними характеризуются 16-ю аспектами.

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

#papers@ergonomic_code #design@ergonomic_code

Привет!

Сегодня рубрика и смех и грех.

Диалог со студентом (примерный):
С - а как вы раньше запросы писали?
Я - о_О
С - ну там иерархическая модель, сетевая, всё такое
Я - О_О

Кажется мне пора начать подкрашивать седину 😂

На всякий случай историческая справка - иерархическая и сетевая модели имели наибольшее распространение в 60-70-ых годах прошлого века.

Привет!

Мне выдали именной промокод на скидку 20% на персональные билеты на JPoint: AZhidkov2023JRGpc:)

Приходите, развиртуализируемся:)

Привет!

Мне тут пришла рассылка от CodeFest (конференция в Новосибирске). Говорят места на квартирники остались, зазывают провести квартирник, бесплатные билетики (всем) обещают. Но нужна экспертная группа:) Айда похоливарим?

Мои предложения по темам:
1) Из очевидного - как декомпозировать системы?
2) Ту жэпэа ор нот ту жэпэа?
3) Сеттеры - инкапсуляция или фикция? Или что имел ввиду Алан Кей, когда придумывал ООП?
4) Интеграционные/юнит тесты это скам (нужное подчеркнуть)

Но если мне будет что сказать - готов и к вашей теме подключиться:) Да и к вашей заявке:)

Ну и заодно вести с полей Проекта Э.

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

Обязательно напишу пост с ретро проекта, и может даже удастся это до JPoint-а осилить

#project_e@ergonomic_code

Привет!

У меня есть уникальное предложение для жителей и гостей города Новосибирск!

Совместно с Сибериан.Про организовали оффлайн митап с тестовым (уже третьим) прогоном моего доклада на JPoint. Если не едете в Москву, то можете посмотреть кусочек JPoint-а практически не сходя с места:)

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

Количество участников ограничено (размером офиса), поэтому регистрация обязательна:)
Приходите, будет интересно:)