Программирование *

Testcontainers - Java-библиотека, которая управляет Docker-контейнерами прямо из тестового кода. Во время выполнения тестов она запускает нужный контейнер - базу данных, брокер сообщений, поисковый движок и т.д. - а по завершении останавливает и удаляет контейнер.

Зачем это нужно? Для интеграционных тестов на реальном ПО, а не на in-memory эмуляторах. Тест работает с тем же движком, что и в продакшене.

В этой статье я разберу, как можно оптимизировать работу с Testcontainers:

tmpfs - перенос файлов в оперативную память.

Прединициализация - перенос тяжёлой инициализацию в отдельный Docker-образ.

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

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

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

В экосистеме современного C++ прочно укоренилось мнение: классический динамический полиморфизм через виртуальные функции (vtable) и наследование — это устаревший, медленный и недружелюбный к кэшу процессора механизм. В качестве «серебряной пули» модно предлагать связку std::variant и std::visit. Если вы спросите любого виртуального умника (ИИ) он до последнего будет убеждать вас что std::variant и std::visit всегда(!) лучше чем виртуальные функции, даже не сомневайтесь. Проблема в том что с таким отношением вы во многих случаях просто лишаете себя выбора адекватного технического решения. Решения адекватного условиям конкретной задачи с необходимостью диспетчеризации вызовов. По интернету кочуют статьи, утверждающие, что std::visit выполняет диспетчеризацию за фиксированное время O(1) и полностью уничтожает старый добрый ООП-подход, но вы должны понимать что не существует универсальных решений на все случаи жизни.

А что если мы попробуем уравнять начальные условия использования обеих техник диспетчеризации и будем использовать вариант с указателями, а не с эмплейс-объектами: std::vector<std::unique_ptr <BaseClass>> и std::vector<std::variantstd::unique_ptr<TypeA>, std::unique_ptr<TypeB>,std::unique_ptr<TypeC>>> в условиях раздельной компиляции классов и кода который делает вызовы (зачем это надо?).

ROC‑AUC вырос с 0,871 до 0,874 — модель стала лучше или вам просто повезло с разбиением?

Разберём, почему прирост на третьем знаке часто оказывается шумом, как измерить разброс метрики и сравнивать модели так, чтобы «улучшение» не исчезло на свежих данных.

В каждом бэкенде рано или поздно рядом появляются id, UUID, slug, token и request_id. Все они выглядят как строки, но отвечают за разные вещи.

Когда это забывают, UUID становится защитой, slug — вечной айдишкой, а token — просто ещё одним идентификатором.

Hibernate 7.4 исправляет старую проблему с пагинацией и fetch join.

Раньше запрос на первые 10 Order вместе с OrderItem не мог безопасно ограничиться на уровне SQL. Из-за join один заказ превращался в несколько строк, и limit мог обрезать коллекцию. Поэтому Hibernate загружал все подходящие строки, а страницу выбирал уже в памяти. На больших данных это било по памяти и могло закончиться OutOfMemoryException.

Теперь Hibernate сначала выбирает нужные id родительских сущностей во вложенном запросе, а затем загружает для них полные дочерние коллекции. Пагинация остается в БД, данные не режутся.

Еще в 7.4 появились history и audit tables. @Temporal хранит версии строк и позволяет читать сущность на конкретный момент времени. @Audited пишет изменения ADD/MOD/DEL в audit-таблицу без Envers.

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

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

Digital Q.AppServer как раз закрывает эту задачу: платформа дает единый интерфейс для работы с серверами приложений Digital Q.TomEE и Digital Q.WildFly и собирает в одном месте основные операции сопровождения. В центре внимания здесь – уже не сам по себе выбор между серверами, а то, что ими можно управлять как частью одного эксплуатационного процесса, а не как набором разрозненных систем.

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

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

«Контейнер для DI — это лишний оверхед, передай зависимость руками и не выдумывай». Я тоже так считал, пока не замерил: наивный контейнер резолвил типичный сервис-граф примерно в 200 раз медленнее ручной сборки.

Рассказываю, как тремя шагами — кэш плана, удаление проверки, которая всё равно не срабатывает, и компиляция графа в одну плоскую функцию — довёл резолв с 52.9 до 0.40 мкс/оп, почти как руками. И как при этом не дал exec-кодогенерации тихо собирать не те объекты в проде.

Приёмы переносимые: профилирование микрооверхеда, выкидывание мёртвой защиты, фаззинг на эквивалентность.

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

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

Привет, Хабр.

Сегодня я постараюсь максимально понятным языком объяснить Hazard pointers, с схемой и примерами.

В Tauri фронтенд дёргает Rust-команды через invoke("get_user", { userId: 42 }) — строка, объект, никакой проверки типов. После очередного вечера, убитого на расхождение snake_case и camelCase, я написал генератор, который превращает Rust-команды и serde-типы в готовые TypeScript-файлы — без аннотаций и правок в коде приложения.

Под катом — почему генерировать надо не то, что написано в коде, а то, что serde реально шлёт по проводу; как я выпустил три релиза за один день, воюя с макросами; и при чём тут юникод-эскейпы в TOML на Windows.

Долгое время вижу одно и то же в новостях и обзорах: ИИ уберет рутину, снимет трение, даст крылья и вообще панацея от всех болячек. Я поставил Claude Code — и да, трение исчезло. Рутина схлопнулась. Идею теперь можно проверить за вечер, а не за месяц.

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

Сегодня за утренним кофе прочитал статью “70% разработчиков считают ИИ-код дырявым, при этом 30% всех опрошенных деплоят его в прод”. Внезапного для меня в этом нет. Я уже писал, что ожидания завышены, а к сгенерированному коду есть избыточное доверие (как и к текстам в целом). Неожиданно другое: проблематику некачественного и ненадёжного ИИ-кода начинают обсуждать как нечто новое. Уже встречал размышления, мол, как теперь строить процессы разработки, чтобы достичь необходимое качество.

Что произойдёт, если дать языковой модели доступ к терминалу, файловой системе и интернету? Она перестанет быть болтливым ассистентом и превратится в агента, который сам читает код, правит файлы и запускает команды — примерно так под капотом и работают Claude Code и Codex. В этой части добавляем нашему агенту семь базовых инструментов и разбираемся, как модель сама решает, какой из них вызвать.

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

Для этого мы сравнили два способа «подружить» ИИ‑агента с внутренними API — MCP и CLI + Skill. Взяли гипотезу из внешних исследований, собрали бенчмарк на 14 сценариях и двух моделях, прогнали больше 400 запросов на реальных внутренних инструментах. И в какой‑то момент всё, что работало, сломалось — и это оказалось самым интересным. Пришлось разбираться почему.

Привет, меня зовут Даниил Михайлов, я из команды разработки партнёрских продуктов Городских сервисов Яндекса. В статье расскажу, что именно мы измеряли, как ломали свои же результаты и к каким выводам в итоге пришли. В конце статьи — дерево решений: когда какой подход использовать.

Сколько раз вы реально меняли базу под приложением? Generic Repository – первое, что тащат в проект, и последнее, в чём сомневаются, – держат ровно ради этого. У меня за карьеру смена базы случилась дважды, и оба раза репозиторий полетел в корзину вместе со всем слоем. Это лишь первое из трёх обещаний, которое он не сдержал, а по дороге тихо забрал доменную модель. Как именно – на реальном кейсе с Mongo, и чем мы его заменили.

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

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

В общем, решил поделиться опытом найма программистов нового поколения. Это просто жесть. Иногда у меня ощущение, что я ищу не разработчиков, а операторов кнопки "сделай красиво через ИИ". Причём кнопку они нажимать уже научились, а вот читать то, что написано вокруг неё, пока нет.

Начнём с самого простого. Кандидаты часто вообще не читают вакансию. Просто шлют сопроводительное письмо в стиле "Я готов работать", "." или "Я соответствую вакансии". Точка. Просто точка, Карл. Даже не три точки, чтобы была хоть какая-то интрига.

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

Например: "Классный у вас ИИ-агент. Я работал с LLM, посмотрел ваш продукт, идея огонь. Хочу поучаствовать, получить опыт и принести пользу - готов работать бесплатно за строчку в резюме". Всё. Такого кандидата уже хочется пригласить на интервью. Про "работать бесплатно за строчку в резюме" я, конечно, шучу. Но если человек хотя бы посмотрел продукт, это уже событие уровня "нашли воду на Марсе".

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

Реактивность лучше MobX, виртуализация рендеринга «из коробки», типизированные стили на TypeScript, локально-первая модель данных через CRDT — эти идеи Дмитрий Карловский (nin-jin) разрабатывает на своём фреймворке $mol и в проекте $hyoo.

За десять лет накопилось около сотни статей на Хабре и большая документация на mol.hyoo.ru, разбросанная по годам и площадкам — карта потерялась даже у тех, кто читал.

Этот каталог — навигатор по корпусу. 80+ материалов разложены по 12 темам:

с чего начать и для кого это вообще

история фреймворка от тизера 2016-го до обзора 2025-го

реактивность от первого «атома» 2014-го до свежего цикла 2026-го

архитектура: MAM, view.tree, виртуализация, CSS-in-TS

руководство по практике

утилиты: $mol_fetch, $mol_time, $mol_regexp, VaryPack, MarkedText

TypeScript-приёмы и принципы кода

$hyoo и Гипер База — распределённые данные на CRDT

сообщество, бенчмарки, аналитика проекта в цифрах

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

Полезно даже тем, кто не будет писать на $mol.