Hypermedia Systems.

HATEOAS и Hypermedia получают, на мой взгляд, недостаточно внимания. Подходы, которые описывал в докторской Рой Филдинг, всё реже трактуются в связке с HATEOAS.

Это удивительно, потому как слово REST в обсуждениях я слышу часто. Но только в формате “используйте HTTP глаголы для описания действий”. Или, еще хуже, как синоним HTTP JSON API.

Как же так? Как обсуждать REST без учёта концепции зрелости Ричардсона? Это тема, которая требует дополнительного обсуждения, ведь HATEOAS — высший уровень зрелости REST.

К чему я? Прочитал за два дня книгу Hypermedia Systems. Авторы до этой книги работали над HTMX.

Хоть и сталкивался с HTMX, книга помогла дополнительно прояснить, как HTMX соотносится с HATEOAS. Авторы представляют уверенную аргументацию, что простой HTML можно рассматривать как ключевой элемент реализации HATEOAS. И что SPA с раздутыми JavaScript-фреймворками для маппинга JSON API в HTML — тупиковая ветвь эволюции.

Книгу можно и последовательно читать, и использовать как справочник по HTMX. Она есть в публичном доступе.

Если Вы ещё не встречались с HTMX, HATEOAS, Hypermedia, и не знаете, что это такое, рекомендую всеми руками, объём достаточно небольшой.

Книга Pro Git.

Несмотря на кажущуюся сложность, на повседневной основе для работы с Git не требуется большой набор знаний. Checkout, fetch, branch, commit, amend, rebase, revert, reset, pull и, наконец, log. Это — большинство нужных команд. Изредка пользуюсь еще config, бывает нужно.

В общем-то, Git достаточно прост с точки зрения пользователя. Проблема: понимание простоты Git приходит именно с опытом работы с тем самым Git. А по началу хочется иметь под рукой какую-нибудь книжку.

Скотт Чакон и Бен Страуб составили замечательное справочное пособие для тех, кто хочет окунуться с головой в детали работы с Git. Издание есть в виде сайта, PDF, EPUB и MOBI. Распространяется Pro Git бесплатно.

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

Pro Git не раз мне пригодился в прошлом, рекомендую.

Страница Pro Git: https://git-scm.com/book/ru/v2

Lazygit.

При работе с Git я почти не пользуюсь отдельными программами. В корпоративной разработке у меня под рукой есть IntelliJ с достаточно удобной панелькой Git. А для своих проектов я привык пользоваться Git CLI.

И всё же, время от времени, нужно посмотреть изменения в разрезе нескольких коммитов. Делать тучу git diff не очень удобно, особенно когда нужно дать хэш конкретного коммита.

И тут на помощь приходит Lazygit. Этот TUI позволяет удобно шастать по дереву Git стрелками. Окна в программе настраиваются, мышка поддерживается, темы оформления есть.

Можно делать stage для кусков кода, а не целых файлов. Можно делать commit, fixup, revert, amend… В общем, все (или почти все) функции Git в наличии.

Благодаря тому, что это TUI инструмент, им можно пользоваться на удалённых машинах по SSH. Очень удобно и практично.

UTF-8 Everywhere.

На неделе вспомнил про wchar_t в Си, пока в очередной раз работал с Unicode, но в Windows. Штука… Неоднозначная.

Часть WinAPI жёстко завязана на WCHAR (wchar_t). Но в Windows он до сих пор определён размером в 16 бит. Тот же GCC на Debian мне говорит, что у него wchar_t — все 32 бита.

Т.е. перевод строки из char в wchar_t генерирует валидный UTF-16 в Windows, но UTF-32 в Linux…

Кажется, char32_t должен решить эту чехарду в будущем… Хотя бы с точки зрения размерности… Пусть это и не исправит проблемы WinAPI…

Но действительно ли так часто нужно работать с полноценным code point в Unicode? Зачем? Только чтобы посчитать общее количество символов? Это же просто сделать и на основе char!

Авторы UTF-8 Everywhere дают развёрнутый ответ на этот и многие другие вопросы. Идея хорошо проработана, есть даже прекрасный FAQ для любопытных.

На этой веб-странице собрали самые веские доводы для использования исключительно UTF-8. Везде. Всегда.

Веб-сайт UTF-8 Everywhere: https://utf8everywhere.org/

Go To Statement Considered Harmful.

Легендарное письмо Эдсгера Дейкстры обсуждалось учёными и программистами довольно долго. Даже сейчас встречаются разные взгляды на присутствие GOTO в программе.

Краткое содержание (парафразирую): GOTO нарушает простую навигацию по коду и, самое главное, возможность сопоставить код с тем, что мы имеем как состояние процесса в определённый момент времени.

Сам Дейкстра пишет, что ничего нового не говорит, о том же уже выступали Тони Хоар, Никлаус Вирт и ряд других учёных.

Дейкста и его коллеги в 1970-х дадут старт “структурному программированию”. В основу ляжет теорема Бёма-Якопини.

Оригинал статьи есть в свободном доступе библиотеки ACM.

Что интересно, этот вариант вырезки содержит и другие письма от 1968 года в редакцию журнала ACM.

К примеру, одно из них про то, что ЯП и их среды не должны быть защищены торговыми марками. Другое про дихотомию килобайты-кибибайты. Ещё одно про необходимость включения пост-мортем дампов (stacktrace или coredump) как обязательную часть высокоуровневых ЯП…

Иногда кажется, что мы застряли в каком-то странном лимбо, где всё уже было придумано или обдумано за нас. Нам же надо только иногда почитывать работы прошлого…

Letters to Editor на сайте ACM: https://dl.acm.org/doi/pdf/10.1145/362929.362947

Книга Modern C.

В течении нескольких последних дней активно почитывал книгу Дженса Густеда “Modern C”.

Книга будет хороша как общий справочник, набор best practices кодинга на C, да и просто посмотреть, какие трюки в C23 можно делать.

Удивительно, что столь детальную и кропотливую работу можно найти в свободном доступе. Распространяется книга по лицензии CC 4.0 в вариации BY-NC-ND. Это очень радует.

Книга структурирована по уровню вовлечённости в C. От самых базовых элементов до многопоточных программ.

Для опытных разработчиков больше всего будут интересны Takeaways. Они резюмируют текст и позволяют фокусироваться на самом интересном. В конце книги есть листинг всех Takeaways, разбитый по разделам книги.

Рекомендую для любителей C.

Книга на сайте HAL Open Science: https://inria.hal.science/hal-02383654v2/file/modernC.pdf

Что нужно знать про Unicode.

Большая часть сложностей с кодировками ушла в прошлое. Сейчас у нас есть Unicode. Он признаётся как универсальный стандарт всеми современными ОС.

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

Проблема только в том, что Unicode имеет несколько актуальных видов, которыми он может быть закодирован. И всё же, жизнь стала значительно проще.

Тематику Unicode затронул Джоэл Спольски ещё в далёком 2003 году, но она актуальна и на сегодняшний день.

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

Статья не просто имеет место быть, но обязательна для ознакомления, если Вы работаете с текстом на уровне байт.

Статья на сайте Джоэла Спольски: https://www.joelonsoftware.com/2003/10/08/the-absolute-minimum-every-software-developer-absolutely-positively-must-know-about-unicode-and-character-sets-no-excuses/

Тестовый фреймворк для Си.

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

На практике это не всегда так.

Да, мир Си — дикий запад. Но, тем лучше, всегда есть выбор.

Джон Брюер приводит превосходный пример того, каким может быть минималистичный фреймворк для тестирования. Всего пара макро и одна переменная, восхитительно!

Статья на сайте Джона Брюера: https://jera.com/techinfo/jtns/jtn002

Про The Clean Architecture.

Конечно, говоря про Clean Architecture, нельзя обойти стороной книгу Роберта Мартина “Чистая Архитектура”.

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

Но не менее полезной можно считать дистиллированную версию в блоге Clean Coder. Автор заметки — тот же Роберт Мартин. Если Вы не знакомы с Clean Architecture, то статья станет хорошей отправной точкой.

Статья в блоге Clean Coder: https://blog.cleancoder.com/uncle-bob/2012/08/13/the-clean-architecture.html

Статьи по DDD.

Уди Дахан — один из первопроходцев DDD в C#.

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

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

Статьи на сайте Дахана:

• How to create fully encapsulated Domain Models

• Domain Events – Take 2

• Domain Events – Salvation

Про Null References.

Популярные современные ЯП позволяют переменным-ссылкам иметь значение NULL. И это уже привело к огромным проблемам, рассказывает Тони Хоар на выступлении.

Борьба с NULL принимает разные виды.

Дизайн каких-то ЯП оставляет это на откуп линтерам, не обременяя себя вопросами времени компиляции и исполнения.

Другие ЯП разрешают хранить NULL только в переменных, которые имеют знак вопроса после типа. Пример: Object? a = null. Нет знака вопроса — переменная не может быть NULL.

Отдельные ЯП имеют монаду Maybe или Optional в стандартной системе типов. Так они кардинально избавляются от самого концепта NULL.

Так или иначе, определённо ясно, что NULL — исключительно техническая необходимость прошлого. А в моделировании предметной области использовать NULL просто не получится.

Презентация на сайте InfoQ: https://www.infoq.com/presentations/Null-References-The-Billion-Dollar-Mistake-Tony-Hoare/

A Micro-Manual for LISP.

LISP имеет удивительный по простоте синтаксис. Это делает его одним из самых популярных кандидатов для программирования своего интерпретатора.

Такой интерпретатор — замечательный пример пет-проекта, который расширит кругозор и познакомит с элегантностью LISP. Быть может, разожжёт интерес к Clojure и Scheme.

Отличной подмогой для проекта будет работа Джона Маккарти. В своём микро-руководстве он описал базовые блоки для построения минимального интерпретатора.

Маккарти формулирует основу LISP всего в десятке правил и пяти основных аббревиатурах, сопровождая этот набор дополнительными примерами.

И это описание занимает всего две страницы! Фантастика!

Статья на сайте ACM: https://dl.acm.org/doi/pdf/10.1145/960118.808386

Btop.

Интерактивный монитор ресурсов — полезный инструмент.

В мире текстовых терминалов для этих задач часто выбирают Htop. Он предельно прост, работает в режиме Text-based User Interface (TUI) и есть в репозиториях всех популярных ОС из семейства Unix-like.

Htop позволяет наблюдать только за CPU, памятью, процессами и операциями ввода-вывода. И это его минус — больше ничего просто нет…

Более широким профилем обладает Btop. Он имеет всё тот же форм-фактор интерактивного TUI и уже есть в большом количестве стандартных репозиториев.

Btop позволяет, окромя возможностей Htop, следить за температурой CPU, получать детализированную информацию с графиками по процессу, точкам монтирования и сетевым интерфейсам. Кроме этого, он поддерживает темы и настройку расположения панелей по вкусу прямо на лету.

В стандартных репозиториях Debian он есть начиная с Bookworm (12). Присутствует и backport для Bullseye (11).

Установка простая:

sudo apt install btop

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

When to Make a Type.

Мартин Фаулер размышляет о ярких преимуществах выделения новых типов и мастерски формулирует лаконичный ответ на этот вопрос.

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

В деталях об этой идее, но немного с другого ракурса, пишет Эрик Эванс в книге "Предметно-ориентированное проектирование" (Domain-Driven Design).

Книга Эванса требует глубокого погружения в концепты DDD. Что такое доменный объект? Как он связан с реальными бизнес-сущностями? Что такое объект-значение? И т.д.

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

Рекомендую к ознакомлению!

Статья на сайте Мартина Фаулера: https://martinfowler.com/ieeeSoftware/whenType.pdf

Интерактивность в разработке.

Брэт Виктор отлично презентует своё видение мира. Попутно он затрагивает вопрос о необходимости моментального визуального отклика на изменения в исходном коде. Рассказывает о том, как интерактивность позволяет получить совсем иной опыт разработки. Более динамичный.

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

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

Впрочем, всегда есть, куда стремиться.

Презентация на Vimeo: https://vimeo.com/906418692

Демо Smalltalk-76.

Иногда просто поражает масштаб того, что разрабатывали в Xerox PARC.

На этом видео Дэн Инголлс презентует Smalltalk-76, объединённую интерактивную среду исполнения и сам язык программирования. Два в одном! И это в 1976 году!

Smalltalk исторически повлияет на большое количество современных ЯП с ООП. Отдельно стоит отметить яркое влияние на ЯП, где в основе лежит модель акторов.

В то время ООП было не столь про термины "инкапсуляция", "полиморфизм" и "наследование". Скорее про то, что всё есть "объект", а объекты общаются между собой исключительно путём обмена сообщениями.

Это — основа современной акторной модели.

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

Презентация на YouTube: https://youtu.be/NqKyHEJe9_w

Впечатления от RoadCraft.

Добрался на выходных до демо-версии RoadCraft. Прохождение заняло (по цифрам Steam) около 4 часов.

Впечатления смешанные. Как и в случае с Expeditions, разработчики захотели сделать SnowRunner, но не совсем SnowRunner. Получилось так себе, как и с тем же Expeditions.

Самая большая проблема — они берут всего один аспект SnowRunner и выкручивают его на максимум. В Expeditions — это исследования местности, в RoadCraft — ремонт инфраструктуры. Но формула SnowRunner в таком случае рассыпается и играть становится не так интересно.

Чести ради, в RoadCraft было проще втянуться, чем в Expeditions, там я не продержался и пары часов. А тут демку до конца прошёл.

К слову, в отличие от SnowRunner, RoadCraft можно купить в ру-регионе Steam. Но смотрю на цены... Уф. Сейчас игра стоит 1749 рублей (30% скидка от 2499 руб.) Нет уж, я лучше пойду в классику какую-нибудь поиграю...

Dotfiles для NVIM v0.10.

За прошедший год меня несколько раз спрашивали: каким конфигом NVIM я пользуюсь?

Люблю брать дефолтный NVIM и накидывать минимум плагинов, которые чуть-чуть упрощают жизнь. Для локальной машины добавляю LSP, линтинг, авто-форматтеры и тему.

Единственная особенность конфига — прибиваю гвоздями версии плагинов, чтобы они были совместимы с NVIM v0.10. Некоторые плагины уже требуют v0.11+, но я на Debian Trixie и в стабильных репах живёт только v0.10. Бэкпортов пока не завезли...

В общем как-то так, вот репа на GitHub.

Podman, OCI и HEALTHCHECK.

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

Compose файлы, которые там есть — предельно простые. Есть цепочка сервисов, которые запускаются друг за другом. Первым стартует БД, никаких проблем. Вторым — сервис с API для загрузки данных в БД. Опять никаких проблем. Третьим — контейнер с wrk для нагрузочного тестирования. И вот тут загвоздка. Контейнер зависал в бесконечном состоянии "Created".

Подебажил. Оказалось, что при сборке образа API никак не фиксировался HEALTHCHECK! Podman по-умолчанию использует именно OCI спеку контейнеров, а не Docker, и там нет поддержки HEALTHCHECK. Из-за этого не срабатывал condition: service_healthy в Compose-файле, подвешивая контейнер с wrk.

Чтобы решить эту проблему, нужно явно указать формат спеки как Docker при сборке Dockerfile/Containerfile. У Podman это выглядит так:

podman build --format docker .

А вот так для Podman Compose:

podman-compose --podman-build-args='--format docker' build

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

export BUILDAH_FORMAT=docker

Вот такие пироги :)

Rustfs vs Minio.

Раньше много пользовался Minio, бывало удобно, когда нужно быстро поднять сервис для перекидывания файлов.

Самая большая проблема у Minio, которая меня преследует в последнее время — жёсткие требования минимального объёма свободного места на диске. Разработчики говорят: нужно минимум 10% свободного места. Неважно абсолютное значение, хоть даже 400T, как в одном из issues на GitHub.

На днях нашёл RustFS, прямой аналог Minio. RustFS даёт спокойно записать файлы и при 1% свободного места.

Для домашнего пользования или мини-лабы — самое то!