TL;DR: Нет, не нужны.

Текст ниже — иллюстрация к тексту «Этот мир — асинхронный, и что вы ему сделаете», раскрывающая реализацию конечного автомата на полностью асинхронной акторной модели.

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

Все современные средства разработки — практически без исключения — наделены двумя родовыми травмами. Они не дают доступа к чуть более низкому софтверному уровню (синтаксическому дереву) без помощи сторонних хаков и ориентированы на синхронное исполнение.

Прежде, чем продолжить, я сразу оговорюсь: я не имею в виду узкоспециализированные задачи, типа написания драйверов, программирования контроллеров и прочей околожелезной разработки; там другие правила. Я говорю про мир приложений: от инди-игр до энтерпрайза. Языки высокого уровня, на которых сегодня ведется более (оценка навскидку) 98% всей разработки продуктов для конечного пользователя, лишены примитивов представления AST и параллельного (не путать с асинхронным) исполнения.

Если на Силикатной улице (это в Мытищах) остановить тысячу случайных прохожих и спросить их, на каких трёх слонах покоится ООП, каждый второй назовёт инкапсуляцию. В коридорах МИФИ, или на собеседовании в Яндексе — процент будет даже выше. Даже LLM способна на шести пальцах объяснить, почему.

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

Книги делятся на две категории: fiction и non-fiction. Технические книги — внезапно — не исключение, и поддаются точно такой же классификации. Между учебником по научной дисциплине, начинающегося с аксиоматики и продолжающегося доказательствами теорем, — и практически любой современной литературой по «Computer Science» — лежит пропасть. Что происходит, когда люди долгое время оказываются рабами одной-единственной книги (с продолжениями), нам хорошо известно из истории. Возникает религия.

99% процентов литературы по ООП — это талмуд. Вероятность того, что вам подойдет «паттерн» — примерно 50%. Как встретить динозавра на Невском. Знание паттернов полезно в той же степени, что и теология, — и примерно тем же по специальности людям. Всегда полезно уметь отличать по запаху Пана от простого фавна, но практических применений такой эрудиции — не существует.

Когда Грубер со Шварцем выкатили маркдаун, он был как глоток свежего воздуха. Минимум разметки, читаемый текст даже до обработки, достаточный для рядового средней руки блогера набор красивостей.

Спустя пару лет мне стало мучительно недоставать возможности тонкой настройки. Я никогда не использовал маркдаун для разметки научных статей и документов с вложенными в нумерованные списки таблицами, а CommonMark двигался, почему-то, именно в этом направлении. Не, серьёзно, цитата с вложенной таблицей, в одной из ячеек которой — список? Кому вообще может прийти в голову реализовывать это на маркдауне?

Один из самых вредоносных принципов в разработке, когда-либо получивших широкую известность — YAGNI. Его озвучил Рон Джеффрис в 1998, а спустя более двадцати лет — еще и Кармак подлил керосин в огонь со своим: «Неопытным разработчикам трудно оценить, как редко разработка архитектуры с учетом будущих требований приводит к успеху».

Вообще говоря, в нашем разнообразном мире ни одна максима не может быть без оговорок применима всегда. Насколько могу судить, будучи сформулированным столь безжалостно афористично, принцип YAGNI привел к тому, что у лентяев появилась отговорка на все случаи жизни.

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

Зайду с козырей: КДПВ этой заметки имеет прямое отношение к тексту.

Если вы сфокусируете взгляд на синей рамке, вы увидите растопырившего лапы Амбидиректуса с вытянутой шеей и маленькой головой, развернутой влево. Перефокусируясь на красную рамку, вы познакомитесь с его приготовившимся нырнуть в стену справа Alter Ego, с плотно ввинченной в шею головой и замершими во взмахе назад передними конечностями.

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

Есть несколько стандартных вопросов для собеседований на позицию разработчик эрланг/эликсир. Речь не идёт про веб, там от людей обычно требуется умение писать код на Phoenix, который настолько хорошо абстрагирует OTP от ранимого разработчика, что можно годами клепать на нем сайты и не иметь представления о том, что такое акторная модель.

Но если речь идёт о понимании парадигмы, людей обычно спрашивают примерно о таких вещах:
  ▸ [junior] чем отличается GenServer.call/2 от GenServer.cast/2 и от Process.send/3
  ▸ [middle] как реализована модель синхронных вызовов (GenServer.call/2) и зачем в колбэке нужен второй параметр
  ▸ [middle] зачем нужен колбэк init/1 и в каких случаях из него имеет смысл вернуть кортеж {:ok, state, {:continue, arg}}
  ▸ [senior] как перенести процесс на другую ноду

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

Как часто вам доводилось оказываться в ситуации, когда инкапсуляция в чужой библиотеке или фреймворке скрывает от вас то, что вам необходимо, а авторам — показалось деталями реализации? Мне — постоянно.

Иногда проблему можно решить пулл реквестом, иногда — хаком (спасибо Матцу за доверие к разработчикам, в руби скрыть вообще ничего нельзя, но и в менее дружественных к подкостыливанию языках — есть всякие рефлекшены, аспекты, указатели на сырую память, наконец). Наконец, можно форкнуть библиотеку, экспортировать всё, что нужно — и окунуться в ад поддержки форка. Особенно это досадно в иммутабельных языках: ну зачем что-то там от меня скрывать, если я все равно ничего испортить в вашем коде не смогу?

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

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

Спустя минуты три жаркой дискуссии, я сказал: «C’mon guys. It’s irrelevant now. Just let me know when you have it settled». Лид команды монолита сдержанно хихикнул и спросил: «В смысле „всё равно“?». Я пожал плечами и ответил: «Я прикручу выбранный вами способ за два часа, всё в порядке, пошли работать».

В последнее время я поучаствовал в нескольких дискуссиях, которые выявили то, о чем я и так давно догадывался: очень многие программисты не понимают, зачем в тестировании нужны моки. Если ваш ответ — «чтобы не ходить из тестов в сторонние сервисы», или «чтобы не разворачивать весь мир для одного хиленького юнит-теста» — текст ниже может оказаться вам полезен.

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

Когда заходит разговор про эрланг/эликсир, людям обычно приходит на ум три основные ассоциации: легковесные процессы, акторная модель, отказоустойчивость. Эрланг позволял запускать сотни тысяч (при тонкой настройке виртуальной машины — миллионы) «процессов» (того, что потом назвали гринтредами, а еще позже — горутинами) — почти сорок лет назад. Джо Армстронг в своей диссертации полушутя охарактеризовал язык через катахрезой everything is a process. С акторной моделью — понятно, это прямое влияние Алана Кая и его идей насчет everything is an object (sending messages to each other).

В тексте ниже я покажу, как сохранять состояние между падениями и перезапусками процесса — без сторонних хранилищ и СМС.

Уже более двадцати лет в индустрии принято тестировать написанный код до выкатывания его в продакшн. Люди придумали unit-тесты, acceptance-тесты, интеграционные тесты, property-based тесты. Люди даже придумали TDD, чтобы удостовериться в том, что тесты на самом деле работают. Люди придумали моки и контракты, наконец (настоятельно рекомендую прочитать эту заметку Валима, она буквально открыла мне глаза на то, что не так с моками в большинстве случаев).

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

TL;DR: решение задачки Эйнштейна на прологе и объяснение, зачем мне вообще пролог в 2025 году.

В библиотеке finitomata конечный автомат задаётся набором переходов в текстовой форме в формате plantuml и/или mermaid (с поддержкой пользовательских форматов, но это не суть). На этапе компиляции описание проверяется со всех возможных сторон на корректность (нет обособленных состояний, одно и только одно начальное, для всех неоднозначных переходов определены резолверы, ну и так далее). Долгое время добавление нового правила приводило к написанию очередного велосипеда по его проверке. Все-таки, эликсир — не самый удобный инструмент для валидации правил.

Наконец, мне все это надоело. Заколачивать утюгом шурупы — весело, но малоэффективно. Я даже попробовал прикрутить Coq, но микроскоп тоже плохо подходит для довольно грубой работы с шурупами. И тут меня осенило: пролог же. Оффтопик: почему-то вика в этом месте не переведена на русский язык, если эту заметку читает кто-то, кому не противно редактирование вики — сделайте доброе дело, пожалуйста.

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

Один из моих знакомых недавно сходил на собеседование, на котором его попросили спроектировать укорачиватель ссылок. Он растерялся и задачу — как хотел интервьюер — не осилил, а потом нашел в интернете популярное решение и попросил меня прокомментировать. Полная формулировка поставленной проблемы: «Как бы вы разработали службу сокращения URL-адресов, подобную TinyURL?»

К моему сожалению, я — человек любознательный, поэтому я не закрыл окно чата, а пошел почитать, как принято в высшем свете такую задачу нынче решать. То, что я увидел, заставило меня набросать свою собственную архитектурку, потому что даже в страшном сне согласиться с предложенным по ссылке дизайном — не вариант. В тексте ниже я заочно дискутирую с автором решения по ссылке выше.

По долгу службы, мы много работаем с деньгами. Складываем, вычитаем, считаем проценты. Любому школьнику известно, что для этих расчетов не подходят обычные встроенные в язык типы: флоаты не сойдутся у финансовых аудиторов, большие целые принесут кучу проблем при конвертации (например, йены обходятся без дробных единиц, а в одном оманском риале — 1000 баиз, а не сто, как у всяких плебейских долларов и евро), и так далее. Существуют целые комитеты, определяющие стандарты (ISO 4217 — коды валют и ISO 24165 — идентификаторы цифровых токенов). Во всех более-менее современных языках есть библиотеки для работы с денежными суммами, реализующие стандарты и скрывающие от нас адовую арифметику без потерь точности.

В мире эликсира, почти всем, что связано с имплементацией комитетских стандартов, занимается Кип Коул. Удобной работе с деньгами мы обязаны тоже его библиотекам: ex_money — для собственно арифметики и money_sql для персистенса.

В последнее время мне пришлось прочитать довольно много кода претендентов на позицию Senior Ruby Developer, и теперь, вытащив из глаз затычки, предотвращающие вытекание, я решил поделиться теми типовыми ошибками, которые соискатель делать не имеет права в принципе. Все они напрямую скопированы из разных решений тестового задания. Задание простое, требует немного денежной арифметики, немного простой логики, немного умения спроектировать и организовать малюсенький проектик.

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

Оговорюсь, что я никогда не зверствую в кодревью и требую исправить только ошибки. Советую подправить — совсем уж корявый код, и только после апрува. Захочет коллега — исправит перед мерджем, нет — нет.

Тестирование — один из самых больных, если не самый больной вопрос в современной разработке программного обеспечения. Поговаривают, что разработчики не любят писать тесты, что написать правильные тесты зачастую сложнее, чем сам код, что «зеленое — не значит работает», а типовые экстремисты даже утверждают, что АДТ с лихвой эти самые тесты заменяют.

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

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