Привет!

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

Поэтому вот вам мемасик на злобу дня:)

Prompt
by Christoph Niemann

Хорошей тебе недели!

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

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

Блин. Я дочитал. И тотально разочаровался. Автор просто придумал JPA/Hibernate/NHibernate на ручной тяге поверх EntityFramework и передачу списка вообще всех репозов в методы сущностей/агрегатов/бизнес-логики. По сути, книга о том, как сделать производительность большого императивного кома грязи сносной, если ты хочешь остаться в ОО, но не знаешь про хибер. Не рекомендую к прочтению.

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

Собственно отрывок из черновика статьи Модель неизменяемых реляционных данных с чуть более подробным описанием идеи:

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

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

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

PS>

Вот и пиши после этого книги, чтобы аноны в интернетах их обсирали 🤦‍♂️🤣

Не, ну кстати, справедливости ради, есть у автора одна любопытная идея.

Чтобы защитить инварианты сущности, автор предлагает делать конструктор приватным, я для создания экземпляров делать внутренний интерфейс, у которого есть протектед метод, который делегирует вызов в конструктор:

public class Client
{
    public interface IRepository : IBaseRepository<Client>
    {
        protected static Client Restore(
            Guid id, string name, string address, Conditions condition)
            => new(id, name, address, condition);
    }

    private Client(
        Guid id, string name, string address, Conditions condition)
    {
        // ...
    }
}

В оригинальном виде, правда, это половинчатое решение - этот интерфейс может реализовать кто угодно и создать сущность без проверки инвариантов. И в шарпе (по словам гопатыча), нет возможности это как-то залечить. Зато в Котлине есть.

interface можно сделать sealed и тогда его реализовать можно будет только в той же директории.
Правда в котлине нельзя сделать протектед метод в интерфейсе, но можно сделать sealed класс.

В итоге получается такая конструкция:

// в файле my_app.clients.Client.kt

class Client private constructor(
    val id: UUID,
    val name: String,
) {
    sealed class Repository {
        protected fun restore(id: UUID, name: String) =
            Client(id, name)
    }
}

// в файле my_app.clients.ClientRepository.kt

class ClientRepository : Client.Repository() {
    fun restoreFromDb(id: UUID, name: String) =
        restore(id, name)
}

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

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

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

#kotlin@ergonomic_code

Привет!

Прочитал пост How to be more ambitious: A tutorial for humans with models антропиковского лида разработки Claude.ai, Cowork, и Code Desktop

И там есть совет:

Pick unreasonable goals and tell the model that they’re very reasonable: You need your website to load in 5s instead of 10s? Ask for 200ms.

А между тем, если делать нормально, то 200мс - это вполне себе решаемая задача. Для старомодных кожанных мешков, а не мясных прокси, во всяком случае.

Теперь в целом понятно, какой ценой Антропик получают свой кратный рост кол-ва мёржа ПР-ов - ценой моего времени. Клодом не пользуюсь, но за гопатыча могу с уверенностью сказать: он и тормозит, и багов в нём больше, чем звёзд на небе.

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

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

#ai@ergonomic_code

Подписывайтесь: VK | MAX

Привет!

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

Сейчас я пытаюсь описать для ИИ модель организации инфраструктурного кода для сетапа фикстуры тестов, но выходит не очень хорошо. И размышляя о том как это всё-таки сделать, меня чёрт дёрнул погопатить модель/методику для текстов описывающих модели/методики.

К моему удивлению, оказалось что на самом-то деле есть дофига матчасти, которую можно изучить:
1. Бесплатный курс от гугла по техписательству
2. Книга The Minto Pyramid Principle: Logic in Writing, Thinking and Problem Solving. Есть русский перевод, но ругают за "машинность" и то, что переводчики не разобрались в теме.
3. Книга Ясно, понятно: Как доносить мысли и убеждать людей с помощью слов
4. Diátaxis - фреймворк/архитектура документации.
5. The Science of Scientific Writing - научная статья о том как люди понимают научные статьи
6. Ну и тут ещё стоит упомянуть классическую (в моей картине мира) Пиши, сокращай

И так как на мой взгляд скоро нам всем придётся стать своего рода писателями - берите на вооружение:)

Сам пока только начал читать Diátaxis, поэтому отзывов пока не дам. Надеюсь в этот раз не выйдет как с архитектурой свободных сущностей.

#books@ergonomic_code

Подписывайтесь: VK | MAX

Привет!

У меня давно, ещё во доИИшную эру на ревью были замечания в духе "Тут написана дичь".
В буквальном смысле.

Например, берёшь код

externalSystem.getAuthRequests().shouldAuthorizeDevice(deviceSerialNumber)

И мысленно пытаешься превратить его в текст на естественном языке.
Для этого, первым делом разбиваешь все цепочки вызовов:

val authRequests = externalSystem.getAuthRequests()
authRequests.shouldAuthorizeDevice(deviceSerialNumber)

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

External system, get me [list of received] authorization requests
Let authorization requests be the retrieved list of requests.
Authorization requests should authorize the device with serial number X.

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

Затем пытаешься написать тоже самое, но "по-русски":

External system, get me [list of received] authorization requests
Let authorization requests be the retrieved list of requests.
[List of received] authorization requests should contain authorization request for the device with serial number X.

Дальше, если хочется, можно ООПизировать этот текст или инкапсулировать проверку:

External system, verify that an authorization request was received for the device with serial number X.

И потом обратно перевести эти тексты в код:

val authRequests = externalSystem.getAuthRequests()
authRequests.shouldContainAuthRequestForDevice(deviceSerialNumber)

// или

externalSystem.verifyAuthRequestWasReceived(deviceSerialNumber)

В данном случае разница невелика — это просто один из свежих примеров.
Но подобные упражнения меня много раз выводили на серьёзные баги (вот, например) или серьёзные архитектурные улучшения.

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

А сейчас пресловутые фронтьирные ИИ-модели пишут подобной дичи ещё больше чем джуны, которые в школе учили немецкий. Поэтому я пошёл добавлять в ErgocodeAi соответствующий рычаг и первым делом пошёл искать, что люди пишут и думают на эту тему. И оказалось, что я не одинок — в гайдлайнах дизайна АПИ Swift-а прямым текстом написано "Prefer method and function names that make use sites form grammatical English phrases" и "Clarity at the point of use is your most important goal".

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

#ergo_approach@ergonomic_code

Подписывайтесь: VK | MAX

Привет!

В ЭП, да и в ErogocdeAi, грядут серьёзные изменения. Не буду пока раскрывать все карты, но одно из ключевых изменений: я решил всё-таки развести правила работы с продовым кодом, с тестами и ТДД в более-менее независимые части и перетряс под это разделение вики.

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

PS>

Плюс решил завести отдельный канал для ИИ-луддизма — подписывайтесь, если вам близка эта тема:) Там как раз и ссылка на жутковатую историю про кодекс подоспела:)

#ergo_approach@ergonomic_code

Подписывайтесь: VK | MAX