Под угрозой сервисы, которые открывают недоверенные файлы через Excelize: импорт таблиц, конвертеры и обработчики отчётов. Ограничение размера загрузки само по себе не устраняет проблему, поскольку приведённый исследователем файл занимает всего 3 072 байта. До исправления отчёт предлагает отсеивать неподдерживаемые зашифрованные контейнеры или изолировать обработку по времени.

• Причина: если первые восемь байт файла совпадают с сигнатурой OLE, Excelize идёт по ветке расшифровки независимо от того, задан ли пароль.
• Функция convertPasswdToKey выполняет spinCount итераций хеширования до проверки верификатора, а spinCount берётся из XML-потока EncryptionInfo без ограничений.
• Стоимость линейная, около 0,6 микросекунды на итерацию: 1e8 даёт около минуты, 1e9 около десяти минут; память при этом держится на 24 МБ.
• На пути нет context.Context, поэтому вызывающий код не может отменить операцию; после ответа HTTP-обработчика по таймауту горутина продолжит вычисление.
• Excel и LibreOffice обычно записывают spinCount 100 000; в отчёте такой вызов занимает 61 миллисекунду. Автор предлагает ограничить счётчик при разборе файла. Сообщил исследователь arpitjain099; уведомление опубликовано 6 сентября, идентификатора CVE и патча пока нет.

Как файл на три килобайта занимает библиотеку на минуту

Зашифрованные паролем книги Excel хранятся в OLE-контейнере, внутри которого лежит поток EncryptionInfo с параметрами шифрования и сам зашифрованный пакет. Excelize определяет такой файл по первым восьми байтам: функция openReaderAt ветвится только по заголовку и не смотрит, передал ли вызывающий код пароль в опциях. Дальше agileDecrypt вызывает convertPasswdToKey, где ключ выводится из пароля повторным хешированием; число повторов задаёт поле spinCount, и проверка хеша-верификатора идёт уже после этого цикла.

Само поле spinCount в коде объявлено как обычный int и заполняется голым xml.Unmarshal из потока файла. Никакой верхней границы нет, поэтому атакующий сам выбирает, сколько времени займёт вызов. Автор отчёта проверил это на выпущенных версиях с proxy.golang.org без директив replace:

Цикл появился вместе с файлом crypt.go в версии 2.3.1 и с тех пор не менялся. Память во время атаки остаётся плоской, около 24 МБ, поэтому её нельзя отловить ни лимитом памяти, ни OOM-киллером: процесс просто занимает ядро на выбранное атакующим время. Автор отмечает, что уязвимость касается только доступности и не угрожает программам, которые открывают файлы, созданные их же оператором.

Чем защититься, пока нет патча

Самый простой фильтр стоит на границе: если сервис не поддерживает зашифрованные книги, отбрасывайте файлы, которые начинаются с OLE-сигнатуры D0 CF 11 E0 A1 B1 1A E1, до вызова Excelize. Обычный XLSX это ZIP-архив и начинается с 50 4B 03 04. Такая проверка занимает одну строку и полностью закрывает вектор для сервисов без паролей.

Проверьте используемую версию Excelize в зависимостях проекта. В сохранённом advisory уязвимыми названы версии с 2.3.1 по 2.11.0 включительно, поле исправленных версий пусто. Следить за появлением патча следует по тому же advisory и релизам проекта; отсутствие предупреждения отдельного сканера само по себе не подтверждает безопасность зависимости.

Если зашифрованные файлы нужны, разбор стоит вынести в отдельный процесс или воркер с жёстким лимитом времени: context.Context на этом пути Excelize не поддерживается; остановить горутину снаружи невозможно. Полезно также разобрать EncryptionInfo самостоятельно и отклонить файлы, где spinCount больше, скажем, миллиона: Excel и LibreOffice обычно используют 100 000. Автор отчёта предлагает мейнтейнерам такой потолок на этапе парсинга.

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

Почему это типовой класс ошибок для парсеров

Схема одна и та же: формат позволяет файлу самому объявить, сколько работы предстоит парсеру, а парсер верит. Вышло исправление libheif 1.23.4, где файл с неограниченным числом элементов давал квадратичное время разбора и полтора гигабайта памяти. У Excelize ситуация проще: нет ни рекурсии, ни аллокаций, только счётчик из недоверенного XML. Следить за исправлением стоит в репозитории проекта: в advisory должна появиться исправленная версия, после чего можно будет обновить зависимость и проверить импорт. О диагностике горутин в работающем сервисе рассказывает новый профиль в Go 1.27, а о девяти уязвимостях в curl того же класса мы писали на прошлой неделе.

Источники: GHSA-jrfj-fhj2-jjvm: Unbounded spinCount in agile decryption burns CPU during OpenFile, Репозиторий qax-os/excelize

Изображение на обложке: Excelize, логотип проекта

Для тех, кто гоняет Polars в пайплайнах, это значит два дела на сегодня. Во-первых, после обновления часть запросов может вернуть строки в другом порядке: потоковый движок не гарантирует порядок для join, group_by и unpivot, если явно не попросить. Во-вторых, код, который годами «работал» на неявных приведениях типов и молчаливом заполнении пропусков, начнёт падать с ошибкой. Разработчики называют это осознанной политикой: ошибка сразу лучше неверного результата через двадцать минут работы пайплайна.

• RC ставится командой pip install polars==2.0rc1; финальный 2.0 выйдет в ближайшие недели, точной даты нет.
• LazyFrame.collect() по умолчанию идёт через streaming-движок; по ожиданиям авторов, в совокупности он «легко в 5 раз быстрее» старого in-memory и заметно экономит память; независимых замеров RC нет.
• Порядок строк после join, group_by и unpivot больше не гарантирован; для join и group_by порядок возвращает параметр maintain_order, для unpivot нужен явный sort; старый движок включается через pl.Config.set_engine_affinity("in-memory") или collect(engine="in-memory").
• is_in с разными типами, горизонтальный concat с разной высотой, касты строк в даты и целых в Enum теперь бросают исключение вместо тихого приведения.
• Большинство удалённых методов и параметров отвечают типизированными ошибками AttributeRemovedError и ArgumentRemovedError с подсказкой, чем заменить.

Почему потоковый движок потребовал мажорной версии

Polars давно развивает два движка. Классический in-memory собирает результат каждой операции целиком в памяти. Потоковый разбивает данные на куски и прогоняет их через план запроса конвейером, поэтому промежуточные результаты не раздуваются. До 2.0 потоковый движок нужно было включать явно; теперь режим engine="auto" выбирает именно его.

Цена такого дефолта в порядке строк: потоковый движок для ряда операций его не гарантирует. Старый движок порядок сохранял, и на это молча полагалось много кода: например, брали первую строку после группировки и считали её «самой ранней». В 2.0 такие места нужно найти и явно попросить порядок (у join и group_by есть параметр maintain_order, после unpivot остаётся явный sort):

Заявление о скорости стоит читать как оценку вендора: «в сумме мы ожидаем, что потоковый движок будет легко в 5 раз быстрее», со ссылкой на собственные бенчмарки Polars. Независимых замеров на RC пока нет, и выигрыш зависит от запроса: на маленьких таблицах, которые целиком помещаются в кеш, разница будет меньше, чем на группировках по десяткам гигабайт.

Где код перестанет молчать об ошибках

Вторая тема релиза сформулирована в посте так: ошибки должны подниматься заранее, а не через 20 минут работы пайплайна, и неявное поведение при несовпадении данных должно включаться явно, а не быть дефолтом. Авторы отдельно отмечают, что строгость стала ценнее с приходом ИИ-агентов: агент может вызвать collect_schema(), проверить типы без чтения данных и быстро получить обратную связь. Примеры из поста и руководства по миграции:

• is_in с разными типами. Раньше Int64 и Float64 приводились к общему супертипу, даже если это теряло точность. В примере из поста идентификатор 9007199254740993 при касте в float64 округлялся до 9007199254740992 (граница, до которой float64 представляет все целые точно), и проверка по списку «помеченных» аккаунтов давала ложное совпадение. В 2.0 это InvalidOperationError: кастовать нужно самому и осознанно.
• Горизонтальный concat. Таблицы высотой 5 и 4 раньше склеивались, а недостающая ячейка молча становилась null; типичный сценарий из поста: тихо упавшая задача за один из дней. Теперь ShapeError, а старое поведение включается через how="horizontal_extend".
• Касты заменены специализированными методами. Целые в Enum или Categorical и обратно: вместо cast() нужны .cat.to() и .cat.physical(). Строка в дату: вместо cast(pl.Date) методы .str.to_date() и .str.to_datetime(), которым можно явно задать формат. Кастовать плоскую колонку в List через cast(pl.List(...)) тоже нельзя, для этого есть pl.list().
• Булевы операторы между Boolean и целыми числами теперь ошибка; std() и var() для Duration удалены, сначала переводите в микросекунды через .dt.total_microseconds().
• Каст между Struct с разным числом полей при strict=True (дефолт) падает, а не обрезает лишние поля; руководство помечает это отдельным предупреждением, потому что раньше данные терялись молча.

Отдельный набор изменений касается чтения CSV. При сканировании набора файлов схема теперь выводится по первым 10 файлам, а не по всем (параметр infer_schema_files). Автоматические имена колонок для файлов без заголовка начинаются с column_0, а не column_1; это же касается read_excel и read_ods. Пользовательская схема в scan_csv сопоставляется с файлом по именам колонок, а не по позиции: раньше первая запись схемы молча получала данные первой колонки файла, даже если имена не совпадали. Для лишних и недостающих колонок появились параметры extra_columns и missing_columns, по умолчанию оба бросают ошибку.

Что будет со старым кодом

Для большинства удалений библиотека получила два типизированных исключения (документация предупреждает, что часть удалённого по-прежнему даёт обычные AttributeError и TypeError): polars.exceptions.AttributeRemovedError для удалённых методов и атрибутов и polars.exceptions.ArgumentRemovedError для удалённых параметров. Оба сообщения указывают на замену:

По словам Винка, большая часть удалённого давно помечена как deprecated, и у тех, кто обновлялся регулярно, пайплайны пострадать не должны. Команда просит сообщать, если из библиотеки убрали что-то, на что реально полагались. Смена движка не затрагивает eager-API DataFrame: выигрыша в скорости там не будет, потому что дефолт меняется только у LazyFrame. Остальные несовместимости на eager распространяются полностью: строгий concat, новые правила read_csv, убранные касты и удалённые методы.

Как проверить свой проект до финального релиза

1. Поставьте RC в отдельное окружение: pip install polars==2.0rc1. В прод его тащить рано, это кандидат в релиз.
2. Прогоните тесты и посмотрите на исключения AttributeRemovedError, ArgumentRemovedError, InvalidOperationError и ShapeError: каждое сообщение содержит подсказку с заменой.
3. Найдите места, где код полагается на порядок строк после join, group_by или unpivot: сортировки «по умолчанию», head(1) после группировки, сравнение с эталоном по позициям. Добавьте maintain_order (join, group_by) или явный sort (unpivot).
4. Если результат обязан совпадать со старым до байта, зафиксируйте старый движок на время миграции: pl.Config.set_engine_affinity("in-memory").
5. Проверьте чтение CSV без заголовка (сдвиг нумерации колонок на единицу) и scan_csv с явной схемой (сопоставление по именам).

В планах ветки 2.x, о которых команда, по её словам, «недостаточно говорила публично»: полноценная out-of-core обработка для потокового движка, новая архитектура IO-плагинов, собственный читатель S3, расширенное покрытие SQL, планировщик на основе оценки стоимости с переупорядочиванием join и отказ от mmap, после которого конвейер станет асинхронным от начала до конца. Сроков по этим пунктам нет. Замечания по RC команда принимает в issues на GitHub.

Источники: Pre-release of Polars 2.0 (блог Polars, Ritchie Vink), Руководство по переходу на Polars 2.0, Бенчмарки Polars

Изображение на обложке: Логотип: Polars

Все началось с рабочей задачи по реализации весьма специфичной web-панели мониторинга и управления различным оборудованием, в которой нужно было получать данные и отправлять команды по разнообразным сценариям (периодический опрос, подписка на websocket-события, https-запросы и т.д.), а также выводить состояние и графики в реальном времени, динамически комбинируя различные источники данных в разных виджетах.

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

В первой итерации с использованием RxJS получилось много неструктурированного и сложно поддерживаемого кода, так как архитектура на RxJS вынуждала императивно описывать перестроение топологии при изменении правил маршрутизации «на лету». В нашем специфичном кейсе с динамическими виджетами это приводило к сайд-эффектам и сложностям в отладке. Кроме того, местами размывалась строгая типизация и мы лишались compile-time гарантий. Так появилась идея разработать собственное решение на основе альтернативной концепции — модели графа потоков данных.

В результате получившаяся модель продемонстрировала предсказуемое поведение и низкую связность компонентов, а кодовая база сократилась на ~30% и приобрела более декларативный вид. Убедившись в эффективности решения, мы решили оформить его в виде отдельной библиотеки с открытым исходным кодом — Transferum.

И что, получилась просто еще одна реактивная библиотека?

Не совсем. Классические FRP-библиотеки (RxJS, Bacon, Most) построены вокруг единственного примитива (Observable). Transferum же основан на композиции различных типов узлов с явно определенным поведением.

Каждый узел в графе потоков распространения данных явно декларирует свои способности: может ли он принимать данные через push, отдавать через pull, распространять полученный сигнал подписчикам, опрашивать источник, фильтровать, блокировать поток и т.д.

Объявленные узлом возможности являются одновременно флагами для использования в runtime и compile-time гарантиями наличия соответствующих методов, определяющих его поведение.

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

Transferum предоставляет четыре слоя абстракции:

1. Трансферы — узлы графа (каналы, поллеры, мапперы, буферы, разветвители и концентраторы, реализации debounce, throttle, switchMap и т.д.).
2. Мосты — ребра графа — управляемые вентили между узлами с динамической маршрутизацией и гейтингом.
3. Операторы — stateless-трансформаторы и фильтры данных (используются трансферами, отвечающими за конвертацию данных).
4. Билдеры — fluent-конструкторы композитных трансферов из цепочек трансферов-примитивов.

Концептуальная и архитектурная основа — capability flags system. Каждый трансфер реализует CommunicationContractInterface — набор булевых флагов, определяющих его возможности.

Флаги isPushable, isPullable, isSubscribable, isGate и другие — это не просто свойства объекта. Это метаданные, которые:

• Определяют TypeScript-интерфейс трансфера на этапе компиляции.
• Управляют стратегией связывания с другими трансферами в рантайме (с помощью функции linkTransfers()).
• Обеспечивают совместимость в билдерах без приведений типов.

Один набор флагов — три потребителя. Это единый источник истины для всей системы.

Когда флаг равен true, соответствующий метод входит в TypeScript-интерфейс трансфера. Это позволяет предоставлять трансфер пользователю вот так:

Или вот так:

Именно в таком формате типов фабрики в библиотеке возвращают трансферы. Например:

Эта «магия» работает в compile-time благодаря несколько замысловатой системе вычислимых типов:

Архитектурные инварианты

1. Трансферы не знают своих соседей

Трансфер определяет своё поведение (push, pull, subscribe и др.), но никогда не ссылается и не проверяет класс другого трансфера. Он не знает, что является upstream или downstream — лишь выполняет свой контракт. Пользователь может создать свой трансфер, объявить и реализовать его возможности — и он органично и бесшовно впишется в экосистему.

2. Мосты не знают конкретных реализаций

Мост инспектирует capability flags, а не имена классов. Нет цепочки instanceof, нет переключения по имени класса. Любой output-трансфер может быть соединен с любым input-трансфером — при условии совместимости их флагов, о чем мы поговорим чуть ниже. Это применимо и к тем узлам, которые еще не существуют и будут созданы пользователем.

3. Значение undefined никогда не распространяется

В Transferum undefined означает «нет данных», а не «пустое значение». Оно подавляется на уровне внутренней реализации менеджера подписок — подписчики никогда не уведомляются с undefined. При этом для явных маркеров пустых значений можно использовать null. Мы сознательно пошли на этот компромисс, чтобы избежать runtime-оверхеда и сохранить нативную скорость работы на плотных потоках данных.

Связывание трансферов

Функция linkTransfers(lhs, rhs) соединяет output-трансфер (lhs) с input-трансфером (rhs) с автоматическим выбором стратегии связывания на основе возможностей этих трансферов:

• isSubscribable → isPushable (реактивная подписка);
• isPullable → isPollingProxy (активный опрос);
• isSubscribable → isAsyncPushable (реактивная подписка + асинхронный push);
• isAsyncPullable → isAsyncPollingProxy (активный асинхронный опрос асинхронного pull-источника);
• isPullable → isAsyncPollingProxy (активный асинхронный опрос синхронного pull-источника).

Protocol-oriented design: механизм не спрашивает «какой это класс?» — он выясняет, какие у него есть возможности. Любая пара трансферов с совместимыми возможностями является linkable. Добавление нового класса трансфера требует только объявления его флагов и реализации соответствующих методов — как связать его с другим трансфером, связующий алгоритм разберется сам.

Sync и async в одной экосистеме

Синхронные и асинхронные трансферы сосуществуют и могут быть связаны между собой. linkTransfers() предпочитает sync-связывание, когда это возможно, а async-стратегии применяет только когда sync неприменим. Нет отдельного «асинхронного мира».

Поддержка backpressure

Ряд асинхронных трансферов (AsyncSinkTransfer, AsyncWriteTransfer, AsyncConvertTransfer, AsyncConditionTransfer) поддерживают необязательные поля в конфигурации: maxConcurrency, bufferSize и onBufferOverflow — для ограничения параллельных async-операций, очереди избыточных данных и graceful-обработки переполнения. По умолчанию — неограниченная обработка, без буферизации.

Локальная обработка ошибок

Transferum использует единую модель обработки ошибок для всех трансферов. Каждый трансфер, который может столкнуться с runtime-ошибкой, принимает опциональный onError-хэндлер в своей конфигурации.

А теперь — к примерам использования

Вот так можно просто и декларативно описать опрос и агрегирование данных из нескольких источников:

А вот как можно организовать динамический роутинг:

Пример организации игровой механики:

Когда имеет смысл попробовать Transferum

Библиотека подойдет для:

• TypeScript-first проектов — благодаря максимально строгой типизации и compile-time вычислению доступных методов любого трансфера на основе объявленных у него флагов возможностей.
• Работы с pull-based источниками данных — polling API, датчиков, хранилищ с PollingProxy.
• Смешанных sync/async пайплайнов — в единой модели без ручного преобразования.
• Явного flow control — gates, bridges, selectors для runtime-маршрутизации.
• Game development / IoT — frame-aligned tickers, idle polling, sensor aggregation.
• Устойчивой обработки ошибок — локальная, non-fatal обработка: одна стадия не убивает пайплайн при условии переданного в конфиге обработчика ошибок, ничего не подавляется молча.

Результаты и планы

• Библиотека уже используется в двух наших внутренних проектах и показывает свою эффективность. Код доступен на GitHub под лицензией MIT, библиотека не имеет внешних зависимостей и поставляется с подробной документацией (README + API Reference).
• В одном из проектов граф состоит из ~80 узлов и стабильно обрабатывает несколько сотен событий в секунду без деградации. На основе этих данных в том числе рендерится 3D-сцена в Babylon.js со стабильным фреймрейтом ~60 FPS без микрофризов.
• Тесты библиотеки покрывают не только отдельные трансферы, но и поведение системы в динамике: переподключение мостов, обработку ошибок в длинных асинхронных цепочках, а также разнообразные граничные случаи. Покрытие — 100%.
• В дальнейшем планируем реализовать хуки и утилиты для более удобного и нативного использования Transferum с Vue и React. Если они окажутся в достаточной мере переиспользуемыми, оформим в отдельные пакеты-адаптеры.

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

P. S. Если вы сталкивались с похожими задачами и решили их как-то иначе — буду рад прочитать о вашем опыте в комментариях.

Потом проект вырос, в команду пришли ещё люди, и стало понятно: этот красивый монолит пора разделять.

Это было взвешенное решение. В какой-то момент общий фреймворк превратился в поле мерж-конфликтов, где ты уже не тесты пишешь, а разбираешься, кто чей page object сломал и почему Android отвалился после правки для iOS.

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

Как говорил один мой коллега, перефразируя классическое “вам шашечки или ехать”:

Ты сюда страдать пришёл или тесты писать?

После этого решение разделить Android и iOS на два проекта стало очевидным.

Сейчас у меня два отдельных проекта: mb-android-tests и mb-ios-tests. И знаете что? Это лучшее архитектурное решение за всё время на этом проекте. Серьёзно.

Контекст: что за проект и почему это важно

Финтех. Нативное приложение. Отдельные кодовые базы, Kotlin на Android, Swift на iOS. И UI там не «три кнопки и список», формы с десятками полей, кастомные контролы, WebView-вставки, платежи, валютные операции, бюджетные переводы. Ну вы поняли.

Стек: Java 21, TestNG, Appium 2.x, Selenide, Allure, Maven. CI на GitLab, крутится на Mac Mini. 5 Android-эмуляторов, 4 iOS-симулятора, 9 Appium-серверов — по одному на устройство.

Но это сейчас. А начиналось всё с одного жирного монолита.

Старый проект: 8 модулей и конструктор-монстр

Идея была «как в книжке»: один репозиторий, модульная структура, переиспользование. DRY во все поля. Ну а чё, красиво же.

8 модулей. Один mvn clean install. Все зависят от mobile-automation-framework, в котором живут DriverFactory, BaseTest, общие Page Objects и слой Steps.

А DriverFactory принимал 11 параметров. Одиннадцать, Карл.

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

Когда я работал один, было норм. Ты сам знаешь, от куда что идет.

А потом пришли люди.

Почему с людьми всё навернулось

Мерж-конфликты каждый божий день

Вот конкретная ситуация. Один человек правит LoginPage в общем фреймворке, добавляет метод для iOS, меняет локатор. Второй в тот же момент рефакторит этот же LoginPage под новую версию Android-приложения.

Мерж. Конфликт.

И тут начинается самое весёлое: какой локатор правильный? Для Android? Для iOS? Для обоих? Кто будет разбираться? Тот, кто мёрджит? А он вообще контекст понимает?

Это не единичный случай. Это было каждый день. Потому что mobile-automation-framework получился общим модулем, от которого зависят все. И все туда лезут. Постоянно.

Обновление одной библиотеки = блокировка всех

Решил обновить java-client с 7.x на 8.x. Нормальное желание — API поменялся, MobileElement удалили, capabilities переехали на типизированные Options.

Вот что произошло в реальности:

1. Меняю версию в parent pom.xml
2. MobileElement удалён → compilation error в DriverFactory, во всех DriverManager’ах
3. DesiredCapabilities → UiAutomator2Options / XCUITestOptions → переписываю все менеджеры
4. selenide-appium 1.x несовместим с java-client 8.x → обновляю до 2.x
5. selenide-appium 2.x требует Selenide 6.x → обновляю Selenide
6. Selenide 6.x ломает API page objects → переписываю page objects во всех модулях
7. А Selenide 6.x ещё и Java 8 не поддерживает → обновляю Java

Одна библиотека.

Задача «обновить одну библиотеку» превратилась в 50+ файлов, 4-5 каскадных обновлений, 2-3 недели работы. И всё это время develop нестабилен. Все заблокированы. Тесты не запускаются.

Две недели.

Из-за одной строчки в pom.xml.

Page Objects с if/else — это два page object в одном файле

Общие Page Objects звучат красиво на бумаге: пишем один раз, используем для обеих платформ. А на практике…

Это не page object. Это два page objects, запиханных в один файл через if/else. И так в каждом методе.

А сверху ещё слой Steps. Обёртки над page objects «для читаемости». И в steps тоже if (platform), потому что логика взаимодействия разная. На Android ты скроллишь через UiScrollable семантически, «прокрути до элемента с текстом X». На iOS координатами, «двигай палец из точки A в точку B». Один метод в steps, а внутри два разных мира.

В какой-то момент ловишь себя на мысли: я же не тесты пишу. Я подгоняю pages и steps под две платформы, чтобы фреймворк не развалился. Это уже не автоматизация тестирования, это поддержка фреймворка ради поддержки фреймворка.

Каждый работает в своём темпе и все друг другу мешают

У одного задача покрыть тестами новый экран на Android. У второго пофиксить падающие тесты на iOS. У третьего добавить тестовые данные.

Все трое лезут в mobile-automation-framework. Все трое меняют pom.xml, BaseTest, page objects. Каждый в своей ветке.

А потом мёрдж.

Технические причины, которые добили окончательно

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

Локаторы: работай с тем, что дают

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

В теории есть AccessibilityID единый локатор для обеих платформ. Звучит хорошо. А на практике? Попробуй попросить мобильных разработчиков расставить одинаковые accessibility-идентификаторы на сотнях экранов. На Kotlin и Swift. Одновременно. Они тебя вежливо пошлют, но скорее всего не вежливо. И будут правы, у них свои спринты, свои дедлайны, и твои автотесты в их приоритетах где-то между «поправить тень у кнопки» и «никогда».

Так что реальный выбор:

XPath - работает, но на iOS может быть тормозным. На Android через UiSelector быстро, нативно, надёжно. На iOS через NSPredicate тоже ок. А «универсальные» XPath типа //*[@text='Войти' or @label='Войти'] это путь к боли, потому что Page Source на двух платформах два совершенно разных XML-дерева.

Координаты - костыль? Да. Но иногда единственный вариант. Когда у тебя кастомный контрол без accessibility-свойств, а разработчик говорит «это декоративный элемент», ты либо тыкаешь по координатам, либо не тестируешь.

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

Суть в том, что «напиши один локатор и работай на двух платформах» это миф. Page Source на Android это android.widget.Button с resource-id. На iOS XCUIElementTypeButton с name и label. Разные типы элементов, разные атрибуты, разная глубина вложенности. Разные миры.

StaleElementReferenceException — «подарок» от iOS

Android рендерит UI через Choreographer синхронно с VSYNC. Элемент появился → стабилен → кликаем.

iOS рендерит через CoreAnimation с неявными анимациями. Элемент есть в дереве, но ещё анимируется. Формально кликабелен, фактически хрен.

Стандартный WebDriverWait с elementToBeClickable это не ловит. Элемент «кликабелен» по мнению Appium wait завершается. А потом click() падает, потому что DOM изменился между вызовами.

На Android этой проблемы нет вообще. Тот же тест, тот же wait, тот же код зелёный на Android, красный на iOS. Один и тот же метод, два разных результата. И это не баг это фундаментальное различие платформ.

Кастомные wait-стратегии для iOS отличаются от Android принципиально. Пихать их в один фреймворк строить leaky abstraction, которая протекает на каждом шаге.

Жесты — два разных мира

Свайп вниз на Android:

Свайп вниз на iOS:

Чувствуете разницу? И даже длительность свайпа важна: на Android 200мс это нормальный скролл. На iOS 200мс это fling, и элемент улетает за экран.

«Кроссплатформенная» обёртка для скролла функция на 40 строк с двумя ветками if (platform), внутри каждой и ещё if для performSwipeDown() vs performSwipeUp(). На 50+ экранах таких обёрток, которых десятки.

И каждая место для бага.

Решение: разделяй и властвуй

Решение было болезненным. Я реально откладывал, потому что казалось, что это шаг назад. Дублирование кода, нарушение DRY, всё такое. Мозг сопротивлялся.

А потом я просто сел и разделил.

Никаких общих page objects. Никаких общих steps. Никакого общего DriverFactory с 11 параметрами. Каждый проект со своим pom.xml, свои зависимости, свой BaseTest, свои локаторы.

Что осталось общего: подход к структуре (Maven + TestNG + Allure), CI-шаблоны, принципы организации. Но не код. Код полностью раздельный.

Что поменялось на практике

В Android-проекте DriverManager типизирован под AndroidDriver. В iOS под IOSDriver. Не AppiumDriver<MobileElement> с кастами и проверками, а конкретный тип для конкретной платформы. IDE подсказывает только релевантные методы. Компилятор ловит ошибки на этапе сборки, а не в рантайме.

BaseTest принимает ровно те параметры, которые нужны. Android: deviceName, platformVersion, udid, appPackage, appActivity, systemPort, serverUrl, appPath — 8 штук, все релевантные. iOS: deviceName, platformVersion, udid, appPath, serverUrl, wdaLocalPort — 6. Никаких @Optional("systemPort") со строкой “systemPort” в качестве дефолта.

А мерж-конфликты?

Когда один человек работает в mb-android-tests, а второй в mb-ios-tests то они вообще не пересекаются. Разные репозитории. Конфликт невозможен физически.

Обновление java-client в Android-проекте не затрагивает iOS. Хочешь обновить, обновляй. iOS продолжает работать на старой версии.

Добавить новый параметр для iOS? Меняешь BaseTest и testng.xml в iOS-проекте. Android даже не узнает.

Это прям кайф.

А как же дублирование кода?!

Конечно, конечно. Первый вопрос, который задают: «Но ведь ты пишешь тесты дважды!»

Нет.

Я пишу каждый тест один раз и без костылей. Без if (platform) в каждом методе. Да, для одного и того же экрана есть два теста, один для Android, один для iOS. Но каждый из них чистый, понятный, заточенный под свою платформу.

В старом варианте я тоже «писал один раз», а потом тратил столько же времени на поддержку if/else, мерж-конфликты и каскадные обновления. «Экономия» на создании оборачивалась переплатой на поддержке. С процентами.

Когда кроссплатформа всё-таки ок

Я не топлю за то, что кроссплатформенный фреймворк абсолютное зло. Есть ситуации, где он работает:

Приложение простое, пара экранов, стандартные контролы, минимум кастомного UI.

UI реально идентичен на обеих платформах. Бывает, наверное.

Команда из одиного человека. Сам пишешь, сам мёрджишь, сам разруливаешь. Голова справляется.

Минимум жестов. Нет сложных свайпов, drag-and-drop, pinch-to-zoom.

Если у тебя финтех, банк, enterprise-приложение с сотнями экранов, кастомными контролами и тремя+ QA, то два проекта дешевле. Не в строках кода, а во времени. В нервах. В часах, потраченных на мерж-конфликты вместо написания тестов.

Итого

Два проекта это не шаг назад и не двойная работа. Со стороны может выглядеть именно так, но на практике ты пишешь каждый тест один раз, под конкретную платформу, без лишних компромиссов. Потом поддерживаешь его без постоянных мерж конфликтов, каскадных обновлений и if/else в каждом втором методе.

Кроссплатформенный фреймворк на Appium для сложного нативного приложения часто оказывается иллюзией экономии.

В следующей статье покажу, как у нас устроена инфраструктура для 9 параллельных устройств на одном Mac Mini: порты, bash скрипты, Appium серверы и workaround’ы, которых нет в документации. Спойлер: там тоже всё не совсем как в гайдах.

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

itertools — модуль стандартной библиотеки Python, который предоставляет ленивые итераторы для композиции цепочек обработки данных.

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

Функции разделены на три группы: бесконечные итераторы (count, cycle, repeat), конечные итераторы (chain, islice, groupby и др.) и комбинаторные (product, permutations, combinations).

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

Подводные камни: groupby требует предварительной сортировки по тому же ключу; итераторы одноразовые; tee() может неэкономно расходовать память.

Зачем вообще ленивые итераторы?

Обычный подход в Python — сгенерировать список и пройтись по нему циклом. Это просто и читаемо, пока данных немного. Когда файл весит несколько гигабайт, а строки приходят из сети, список становится дорогим: он требует памяти и времени, хотя в каждый момент вам нужен лишь один текущий элемент.

Ленивый итератор не строит коллекцию целиком. Он помнит текущее состояние и умеет «добыть» следующий элемент. Поэтому itertools работает с любыми итерируемыми источниками — файлами, генераторами, сетевыми потоками — и не требует, чтобы весь объём данных поместился в оперативную память.

Память vs скорость:
Ленивость экономит память, но не всегда ускоряет код. Если данные всё равно нужны целиком — например, для сортировки — список может оказаться быстрее. Используйте итераторы там, где важна потоковая обработка.

Три семейства инструментов

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

Бесконечные итераторы: count, cycle, repeat

count — это range без конца. Ему можно задать начальное значение и шаг, и он будет выдавать числа до тех пор, пока его не остановят снаружи. cycle бесконечно повторяет переданную последовательность, а repeat — бесконечно или заданное число раз возвращает один объект.

Классический трюк — сочетание map и count: map(f, count()) работает как математическое табулирование tabulate(f), знакомое из SML и Haskell.

Конечные итераторы: chain, islice, groupby и другие

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

batched появился в Python 3.12 и сразу стал незаменимым инструментом: партии запросов к API, пакеты строк для вставки в базу, страницы данных. Последняя партия может быть короче — это поведение по умолчанию.

groupby часто путают с SQL-аналогом, но это не тот же инструмент. Python-версия группирует только подряд идущие одинаковые ключи, поэтому перед ней обычно нужна сортировка по тому же ключу. Если забыть про это, результат покажется случайным.

Комбинаторные итераторы: product, permutations, combinations

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

product с аргументом repeat удобен для перебора многомерных конфигураций: product([0, 1], repeat=3) даст все двоичные triples, как в таблице истинности.

Подводные камни, за которые хватаются новички

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

• groupby работает только с подряд идущими одинаковыми ключами. Перед вызовом сортируйте данные по тому же ключу, иначе группы разобьются.
• Итераторы одноразовые. После list(iterator) исходный итератор опустошён, и второй проход по нему даст пустой результат.
• tee копирует данные во внутренний буфер, пока все производные итераторы не прочитают их. Если один итератор сильно отстаёт, память может расти не хуже списка.
• zip_longest с бесконечным итератором никогда не остановится. Ограничивайте такие комбинации islice или takewhile.
• product полностью потребляет входные итераторы, чтобы построить пулы значений. С бесконечными последовательностями его использовать нельзя.

Рецепты: от простого к составному

Документация Python включает раздел рецептов — готовые комбинации функций, которые решают частые задачи. Некоторые из них настолько удобны, что со временем превращаются в полноценные функции модуля: так появились accumulate, compress и pairwise.

Для sliding_window сейчас часто используют рецепт из документации или аналог из more-itertools, где функция уже реализована и хорошо протестирована.

Выводы

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

Together, they form an iterator algebra making it possible to construct specialized tools succinctly and efficiently in pure Python.

Источник: itertools — Functions creating iterators for efficient looping. Если в вашем коде до сих пор царят вложенные циклы и огромные списки — попробуйте заменить их на поток. Скорее всего, получится короче, быстрее и понятнее.

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

Так появляется классическая ловушка legacy: систему надо модернизировать, но остановить развитие нельзя. Переписать всё с нуля страшно, поддерживать как есть — всё дороже. В результате продукт обрастает временными решениями, скорость разработки падает, а стоимость каждого следующего изменения растет.

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

Почему Big Bang-переписывание чаще всего заканчивается плохо

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

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

Проблема не в самой идее переписывания, а в условиях, при которых оно проваливается. Большой риск возникает, когда совпадают четыре фактора: переписывание занимает много месяцев, в это время бизнес продолжает развивать старую систему, новая версия покрывает сразу большую часть функциональности, а откат связан с миграцией данных. Если все четыре пункта присутствуют, Big Bang почти гарантированно превратится в долгий и дорогой проект.

Допустим, команда решила переписать модуль заказов в e-commerce-продукте. В старой версии есть корзина, промокоды, доставка и оплата. Команда планирует за полгода сделать новый сервис заказов. Но за эти полгода бизнес добавляет подписки, подарочные сертификаты, частичную оплату бонусами и новую логику возвратов. В итоге новая система, которую проектировали под старые требования, к моменту релиза уже нуждается в доработке.

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

Big Bang всё-таки бывает оправдан — но в узких условиях. Если кодовая база молодая (год-два), пользователей мало, у системы нет критичного состояния в БД и продукт можно временно заморозить или вести в обоих контурах параллельно, полное переписывание может оказаться дешевле постепенной миграции. Это редкая ситуация, и она быстро исчезает по мере роста продукта. В зрелых системах безопаснее работает другой подход — постепенная архитектурная эволюция.

Пример: как команда переписала сервис документов и потеряла полгода

Команда сопровождала сервис — старый модуль на aiohttp с Pydantic v1, через который проходила вся обработка путевых листов и актов осмотра транспорта. Сервис существовал шесть лет, был покрыт тестами фрагментарно, а его API использовали мобильное приложение водителей, диспетчерская веб-панель и пакетный импорт.

Команда решила переписать сервис целиком: перейти на FastAPI, обновить Pydantic до v2, заодно почистить контракты и заменить внутреннее хранилище документов с MongoDB на PostgreSQL. План был рассчитан на четыре месяца.

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

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

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

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

В-четвёртых, переключение было сделано «в лоб»: маршрут в API Gateway просто перенаправили на новый сервис. Фича-флага не было, теневого запуска не было, плана отката не было. Когда выяснилось, что новый сервис строже валидирует исторические форматы документов и отклоняет часть старых записей, быстро вернуться на старую реализацию не получилось — её к тому моменту уже отключили на стенде, а в БД успели уйти записи в новом формате.

В итоге миграцию свернули, потратив около десяти человеко-месяцев и потеряв доверие бизнеса. Сервис до сих пор работает в исходной реализации, а команда переходит к плану, описанному ниже.

Strangler Fig Pattern: как заменить систему по частям

Один из самых практичных подходов к модернизации legacy-кода — Strangler Fig Pattern. В софтверном виде паттерн был сформулирован Мартином Фаулером в 2004 году под названием StranglerFigApplication. Идея проста: не переписывать систему целиком, а постепенно выносить отдельные части в новую реализацию.

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

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

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

Strangler Fig хорошо работает там, где между старым и новым кодом есть сетевая граница: HTTP, message bus, RPC. Если такой границы нет — например, нужно постепенно заменить функцию или класс внутри одного процесса — используется родственный паттерн Branch by Abstraction: над старой реализацией создается абстракция, рядом пишется новая реализация, переключение происходит через конфигурацию или фича-флаг, после стабилизации старая ветка удаляется. Снаружи это выглядит как Strangler Fig, но без сетевого прокси.

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

Главное правило: сначала повторить поведение, потом улучшать

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

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

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

Прежде чем менять поведение, его нужно зафиксировать. Для этого пишут характеристические тесты (characterization tests, иногда называемые golden master или approval tests). Идея простая: на реальных данных или их обезличенных копиях прогоняется старая реализация, её ответы сохраняются как эталон, и любые будущие изменения, отклоняющиеся от эталона, отлавливаются автоматически. Тесты пишутся не для красоты, а для того, чтобы зафиксировать существующее поведение — даже странное — перед тем, как его трогать. Подробно эта техника описана у Майкла Физерса в книге Working Effectively with Legacy Code; на практике её удобно реализовать через библиотеки семейства approval-tests (approvaltests-python, approvaltests-java и аналоги).

Поэтому первый этап модернизации — не улучшение, а воспроизведение текущего поведения. Новая реализация должна вести себя так же, как старая. Даже если старое поведение кажется странным. Только после стабилизации можно отдельно обсуждать, что именно стоит менять.

Feature toggles: как включать новую логику без риска

Feature toggles, или фича-флаги, — один из главных инструментов безопасной миграции. Они позволяют включать и выключать новую логику без деплоя.

В обычной разработке релиз часто выглядит бинарно: код либо выкатили, либо нет. При миграции legacy это неудобно. Гораздо безопаснее иметь возможность включить новую реализацию для 1% пользователей, затем для 10%, потом для половины аудитории и только после этого для всех.

Например, команда переносит расчет стоимости доставки из монолита в новый сервис. С помощью фича-флага это выглядит так:

user_id передается явно, чтобы решение «попал ли пользователь в новый сегмент» было стабильным от запроса к запросу. Иначе один и тот же клиент будет получать разные ответы при обновлении страницы, и поведение системы станет непредсказуемым.

На первом этапе флаг включают только для внутренней команды. Потом для тестового сегмента пользователей. Затем для небольшой доли реального трафика. Если метрики стабильны, долю увеличивают. Если появляются ошибки, флаг выключают, и пользователи снова идут в старую реализацию.

Важно различать два разных типа флагов. Флаг постепенной выкатки (rollout flag) меняется редко и контролирует, какой процент пользователей видит новую логику. Kill switch — отдельный флаг, единственная задача которого — мгновенно выключить новую реализацию при инциденте. Kill switch должен опрашиваться на каждом запросе, его кэширование должно жить секунды, а не минуты, и он принципиально не должен зависеть от той системы, которую он выключает. Иначе в момент аварии может оказаться, что выключатель сам недоступен.

В качестве инфраструктуры для флагов команды обычно берут одну из платформ: LaunchDarkly, Unleash, Flagsmith, GrowthBook, либо собирают собственную поверх Redis или конфигурационного сервиса. Для миграции важны три свойства: быстрое распространение изменений (секунды, а не минуты), поддержка таргетинга по пользователю/сегменту и аудит — кто и когда менял флаг.

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

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

Shadow testing: как проверить новую систему на реальном трафике

Feature toggles помогают безопасно переключать пользователей. Но перед этим хорошо бы понять, совпадает ли новая логика со старой. Для этого используют shadow testing.

Shadow testing — это запуск новой реализации параллельно старой, но без влияния на пользователя. Пользовательский запрос по-прежнему обрабатывает старая система, а новая получает копию запроса и считает результат «в тени». Пользователю этот результат не показывается. Команда только сравнивает ответы.

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

Два момента, на которые стоит обратить внимание в этом коде. Теневой вызов запускается через asyncio.create_task — корутина сразу планируется в event loop и начнёт выполняться, как только функция вернёт управление. И весь блок завернут в try/except: исключение в новой логике не должно ронять основной запрос. Без этих двух свойств shadow testing рискует ухудшить продакшен вместо того, чтобы безопасно его проверить.

Небольшая оговорка для продакшена: event loop держит на task только слабую ссылку, и без сохранённой ссылки задача может быть собрана сборщиком мусора прямо во время выполнения. В реальном коде Task имеет смысл класть в set фоновых задач и удалять оттуда через add_done_callback. В примере выше эта обвязка опущена для читаемости.

Для критичной доменной логики — платежей, биллинга, расчета тарифов — допустимый уровень расхождения должен быть около нуля: цель в shadow-режиме не «как можно меньше различий», а «понимаем каждое расхождение». Для менее чувствительных доменов (рекомендации, ранжирование результатов поиска) можно жить с расхождением в долях процента, но и там расхождения нужно классифицировать, а не игнорировать. Возможно, это баги новой реализации. А возможно, старая система содержит устаревшую логику, которую нужно отдельно обсудить с бизнесом.

Shadow testing особенно полезен для критичных доменных частей: платежей, биллинга, расчета тарифов, персональных предложений, транзакций. Там нельзя просто «попробовать на пользователях» и посмотреть, что будет.

При этом важно отличать теневую проверку чтения от теневой проверки записи. Чтение проверить относительно дёшево: запрос идёт в обе системы, ответы сравниваются, никаких внешних эффектов нет. С записью всё сложнее. Если новая реализация в shadow-режиме действительно создаст заказ, спишет деньги или отправит письмо, у пользователя возникнут двойные эффекты. Поэтому для writes либо вводят идемпотентные ключи и shadow-режим без реальных побочных действий (внешние вызовы заменены no-op-стабами, БД — отдельной shadow-копией), либо вообще отказываются от теневой проверки записи в пользу постепенной выкатки за фича-флагом.

Сравнение ответов в реальной системе тоже не сводится к одной функции compare. Нужно отдельно решать, как игнорировать «нормальный» шум (метки времени, идентификаторы, порядок коллекций), как сэмплировать трафик, чтобы не утопить хранилище расхождений, и как организовать триаж — кто и в каком ритме разбирает накопившиеся диффы. Готовые решения этого класса — GitHub Scientist (Ruby и его порты в другие языки), Twitter Diffy, либо собственный лёгкий регистратор поверх Kafka и таблицы расхождений.

С чего начинать модернизацию

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

Удобный способ выбрать первый кусок — оценить кандидатов по двум осям: насколько модуль критичен для бизнеса (low / high) и насколько сильно он связан с остальной системой (low / high). Начинать стоит с квадранта low-criticality + low-coupling: ошибки в нем не уронят бизнес-показатели, а малое количество зависимостей позволит провести миграцию полностью, не утянув за собой смежные модули. Высоко-критичные и сильно связанные части (платежи, ядро авторизации) трогают в последнюю очередь — на этот момент команда уже наберёт опыт безопасной миграции.

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

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

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

Миграция данных: самая сложная часть

Большая часть статьи говорит о маршрутизации запросов и переключении трафика. Но в реальных проектах основная сложность лежит ниже — в данных. Старая и новая реализации почти всегда работают с общим состоянием: одной БД, одним хранилищем документов, одним набором очередей. Переехать туда «одним коммитом» нельзя.

Базовый рабочий приём — Expand-Contract (он же Parallel Change). Изменение схемы делается в три такта. На этапе expand в БД добавляются новые поля, таблицы или индексы, при этом старое поведение полностью сохраняется. Затем — migrate: обе реализации начинают писать и в старое, и в новое место (dual writes), а отдельный фоновый процесс делает backfill — заполняет новые поля историческими данными. После этого читатели по одному переключаются на новую схему. Только когда никто из читателей не использует старую структуру, наступает contract — удаление лишних колонок и таблиц.

Несколько практических деталей, которые часто упускают:

· Dual writes — это не бесплатная операция. Две записи означают две точки отказа. Если одна из них упала, нужно решать, что делать: продолжать ли работу, ставить ли событие в очередь на повтор, помечать ли запись как несогласованную. Простое «сначала пишем туда, потом сюда» в продакшене на нагрузке приводит к расхождениям.

· Backfill часто длиннее, чем кажется. На большой таблице миграция в одном UPDATE блокирует продакшен. Поэтому backfill делают батчами по N тысяч строк с паузами, отслеживают прогресс и предусматривают возможность остановить и продолжить.

· Онлайн-изменения схемы на крупных таблицах делаются не штатным ALTER TABLE, а специализированными инструментами: gh-ost или pt-online-schema-change для MySQL, встроенные онлайн-механизмы PostgreSQL для индексов и колонок, Liquibase/Flyway — для управления версионированием изменений в репозитории.

· Shadow testing данные не покрывает. Можно сравнить, что новая реализация возвращает то же, что и старая, но если за этим стоит другая схема в БД, проверка корректности самой миграции данных — это отдельная работа: сверки, контрольные суммы, выборочный аудит исторических записей.

Без этих шагов любая красивая фасадная архитектура наталкивается на разъезжающиеся данные — и тогда даже идеальный Strangler Fig снаружи не спасает.

Прокси-слой как точка контроля

Чтобы постепенно заменять legacy-код, нужно управлять маршрутизацией запросов. Для этого часто создают прокси-слой, API Gateway или фасад, через который проходит обращение к старой и новой логике. В терминах Domain-Driven Design такой слой часто называют Anti-Corruption Layer: он защищает новую реализацию от старых контрактов и наоборот, позволяя двум моделям сосуществовать без взаимного «загрязнения».

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

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

В качестве технической основы команды обычно берут один из трех вариантов: классический API gateway (Kong, AWS API Gateway), service mesh (Envoy, Istio) или более простой reverse proxy (NGINX, HAProxy). Service mesh особенно удобен, когда трафик уже идёт внутри Kubernetes-кластера: маршрутизацию можно менять конфигурацией, без правок кода клиентов и сервисов.

Например, мобильное приложение обращается к endpoint /orders/history. Раньше этот endpoint напрямую обслуживал монолит. После введения API Gateway приложение продолжает ходить по тому же контракту, но внутри gateway может решать, куда направить запрос: в legacy-модуль или новый сервис истории заказов.

Управление маршрутизацией обычно делается не «всё или ничего», а на основании атрибутов запроса: значения заголовка (X-Migration-Cohort: new), куки, хэша от user-id (стабильное разбиение пользователей на сегменты) или географического региона. Это позволяет выкатывать новую реализацию сначала на одну страну, на сотрудников самой компании или на тестовый сегмент — и только потом расширять охват.

Для клиента ничего не меняется. Для команды появляется управляемость.

Наблюдаемость: без метрик миграция превращается в гадание

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

Минимальный набор — это логи, метрики и распределенная трассировка (distributed tracing). Нужно понимать, сколько запросов идет в старую и новую реализацию, сколько ошибок возникает, как меняется latency, где появляются таймауты, какие статусы возвращаются, какие бизнес-метрики проседают.

Технические метрики стоит формулировать не как «средний ответ» и «процент ошибок», а в терминах SLI и SLO: целевые показатели вида «99.9% запросов на /orders/history отвечают быстрее 300 ms за 30 дней» с явным error budget. Latency измеряется по перцентилям (p50, p95, p99) — среднее значение почти всегда обманчиво, а хвосты распределения говорят о реальном опыте пользователя. На время миграции имеет смысл выставить отдельные SLO для нового и старого пути и сравнивать их.

В качестве инструментов де-факто стандартом стал OpenTelemetry для трассировок, метрик и логов — единый протокол, который пишет в практически любое хранилище. Дальше — Prometheus и Grafana для метрик, Jaeger или Tempo для traces, Sentry или аналог для ошибок. Для миграции важна возможность фильтровать метрики по «варианту» — отдельно по старому и новому пути — иначе все цифры смешаются и реальную динамику будет не видно.

Технических метрик недостаточно. Если команда переносит оформление заказа, важно смотреть не только на 500 ошибки и время ответа, но и на конверсию в оплату, количество брошенных корзин, повторы запросов, обращения в поддержку.

Пример: новая система формально отвечает быстрее старой и не дает ошибок. Но после включения на 10% пользователей падает конверсия в оплату. Причина может быть не в серверной ошибке, а в изменении порядка полей, другом тексте сообщения или потере какого-то edge-case. Без бизнес-метрик команда может решить, что миграция успешна, хотя для продукта она уже создает проблему.

Практическая последовательность миграции

Рабочая последовательность обычно выглядит так.

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

Затем поверх legacy-логики создается стабильный контракт. Это может быть API, фасад, gateway или отдельный слой внутри приложения. Главная задача — сделать так, чтобы клиенты зависели не от внутренней реализации, а от понятного интерфейса. На этом этапе полезно вспомнить про contract testing (Pact, Spring Cloud Contract): автотесты со стороны потребителей фиксируют, что именно они ожидают от API, и предупреждают о ломающих изменениях до того, как они доедут до продакшена.

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

Следующий этап — shadow testing. Новая система получает копии реальных запросов, считает результат, но пользователю по-прежнему возвращается ответ legacy. Команда сравнивает результаты и устраняет расхождения.

Когда новая реализация достаточно стабильна, начинается постепенное переключение через feature toggles. Сначала внутренние пользователи, потом 1% реального трафика, затем 5–10%, затем 50% и только после этого 100%.

На каждом этапе команда смотрит на метрики. Если всё стабильно, движение продолжается. Если появляются проблемы, флаг выключается, трафик возвращается в legacy, а команда разбирает причины.

Последний этап — удаление старого кода. Это не формальность, а обязательная часть миграции. И «удалить старый код» — это не один коммит, а явный Definition of Done: вырезана старая ветка кода, удалён фича-флаг, обновлена документация и схемы архитектуры, переименованы или удалены устаревшие дашборды и алерты, обновлены runbook’и для on-call и проведено короткое внутреннее обучение. Если этого не сделать, через полгода никто уже не вспомнит, какой путь актуален, и легаси-ветвление останется в коде навсегда.

Откат миграций: дешёвый только пока не пошли записи

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

Поэтому ещё на этапе проектирования каждое изменение должно сопровождаться явным планом отката. Удобно различать три типа шагов.

Полностью обратимые шаги. Чтение через новый сервис, расчёт «в тени», новые метрики. Откат — выключить флаг. Это самый комфортный режим, и в нём стоит держать миграцию как можно дольше.

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

Forward-only. После некоторой точки откат становится невозможен — например, после того, как старая схема удалена или внешние интеграции перенастроены на новый сервис. Такие шаги допустимы, но к ним нужно приходить отдельно, осознанно, с особенно строгими SLO в предыдущем этапе. До forward-only-перехода имеет смысл подержать систему в режиме параллельной работы дольше, чем по графику.

Базовое правило: ни один шаг миграции не должен уходить в продакшен, если у команды нет письменного ответа на вопрос «как мы откатываемся в случае проблемы». Иначе при инциденте откатываться будут на ходу — и не факт, что успешно.

Пример: как тот же сервис мигрировали со второй попытки

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

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

Параллельно команда провела инвентаризацию побочных эффектов. Из исходного кода и логов выяснилось, что сервис не только хранит документы, но и: публикует событие в Kafka при смене статуса, инкрементирует счётчик в Redis для рейтинга водителей, отправляет webhook во внешнюю систему партнёра, пишет в таблицу аудита. Каждый из этих эффектов попал в отдельный пункт чек-листа «что должно остаться» в новой реализации.

Затем команда выбрала первый кусок для выноса — не весь сервис, а только чтение документов (GET /documents/{id} и GET /documents/by-driver/{driver_id}). Это была наименее рискованная часть: ошибки в чтении неприятны, но не ломают финансовые потоки.

Новый сервис написали на FastAPI рядом со старым. На уровне API Gateway появилось правило маршрутизации: запросы на чтение шли в старый сервис, но в фоне дублировались в новый. Ответ пользователю всегда возвращал legacy, а ответ нового сервиса сравнивался с эталоном и записывался в отдельную таблицу для разбора. Использовали обёртку поверх asyncio.create_task — на ответ пользователя теневой вызов не влиял.

За три недели shadow-режима команда нашла четыре расхождения. Два оказались багами новой реализации (округление времени, неправильная сортировка вложений). Два — давно забытыми особенностями старого сервиса (одно поле возвращалось в UTC, другое — в локальной зоне; так было исторически, бизнес не возражал, но в новой реализации захотели единый формат). Все четыре зафиксировали явно: баги — починили, особенности — согласовали с продуктовой командой как осознанное изменение.

Когда расхождений не осталось, включили фича-флаг на сотрудников самой компании. Через неделю — на 1% реальных водителей. Дальше шаг по 5%, 25%, 50%, 100% с паузой в несколько дней между этапами. На каждом шаге следили не только за HTTP-ошибками и latency, но и за продуктовыми метриками: количество подписанных актов, время от открытия документа до подписи, доля повторных запросов. Один раз пришлось откатиться с 25% на 5% — в одном из регионов выросло время отклика из-за неэффективного запроса. Исправили, выкатили снова.

Через два месяца чтение полностью перешло в новый сервис. Старый код чтения и фича-флаг удалили в том же релизе. После этого по той же схеме мигрировали запись документов, потом публикацию событий, потом импорт из внешних систем. Полная миграция заняла девять месяцев — почти столько же, сколько провалившийся Big Bang, — но продукт всё это время продолжал развиваться, инцидентов не было, и в конце команда осталась с системой, которую понимает.

Типичные ошибки при работе с legacy

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

Вторая ошибка — недооценивать скрытые зависимости и побочные эффекты. Legacy-код часто делает больше, чем кажется. На один и тот же вызов могут быть навешаны: запись в таблицу аудита, инкремент счётчика в кэше, публикация события в очередь, обновление статуса связанной сущности, инвалидация кэша, дёрганье webhook’а во внешнюю систему. Если в новой реализации воспроизвести только явный путь, скрытые потребители молча перестанут получать данные — и узнают об этом через жалобу бизнеса, а не через ошибку в логах. Поэтому перед выносом любого модуля имеет смысл составить инвентаризацию побочных эффектов: пройтись по коду и логам и выписать каждое нелогичное действие отдельным пунктом чек-листа.

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

Четвертая ошибка — не договариваться с бизнесом. Модернизация не должна быть невидимой «инженерной активностью в стол». Её нужно встраивать в roadmap, объяснять эффект и договариваться о приоритетах. Если бизнес не понимает, зачем команда тратит время на миграцию, работа будет постоянно проигрывать новым фичам.

Пятая ошибка — не удалять старый код. Временное сосуществование старой и новой логики нормально. Вечное сосуществование — нет. Если legacy не удаляется, технический долг не уменьшается, а просто меняет форму.

Шестая ошибка — не удалять фича-флаги после миграции. Флаг, который сыграл свою роль и больше никогда не выключается, превращается в постоянное ветвление в коде. Через год команда не помнит, можно ли удалить такую ветку или там сидит важный edge-case. Через два — кода с такими «мёртвыми» флагами становится больше, чем основной логики. Поэтому каждый флаг должен заводиться с условием удаления («после полной выкатки и двух недель стабильной работы») и иметь ответственного, кто этим удалением займётся.

Отдельно стоит упомянуть организационную сторону. Закон Конвея работает и в обратную сторону: если новый и старый код владеются разными командами с разными приоритетами, миграция будет тормозиться независимо от выбранного паттерна. На время миграции имеет смысл явно проговорить, кто отвечает за переход, и не разделять старую и новую реализации между несовместимыми roadmap’ами.

Компромиссы, к которым нужно быть готовыми

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

Shadow testing увеличит нагрузку на инфраструктуру, потому что часть запросов будет обрабатываться дважды. Команде придется поддерживать дисциплину: документировать контракты, отслеживать флаги, удалять старую реализацию после миграции, поддерживать contract-тесты в актуальном состоянии.

Но это контролируемая сложность. Она распределена во времени и управляется инженерными практиками. В отличие от Big Bang-риска, где команда долго работает с минимальной обратной связью, а потом выкатывает один большой релиз с максимальной неопределенностью.

Когда Strangler Fig особенно оправдан

Постепенная миграция особенно хорошо подходит для систем, где downtime невозможен или слишком дорог. Это финтех, e-commerce, биллинг, мобильные бэкенды с большой аудиторией, высоконагруженные продукты, старые монолиты и системы с большим количеством интеграций.

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

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

Когда модернизацию лучше не делать

Постепенная миграция — мощный инструмент, но у неё тоже есть стоимость, и иногда правильный ответ — оставить систему как есть. Несколько сценариев, в которых модернизация плохо окупается.

Продукт, который уходит из эксплуатации. Если через год сервис будет выключен или заменён на покупное решение, тратить квартал на его рефакторинг бессмысленно. Достаточно стабилизировать то, что есть.

Модуль, который никто не трогает. Если код десятилетней давности продолжает работать, не падает, не требует изменений и не вызывает инцидентов, его «уродливость» — не повод его переписывать. Цель модернизации — упростить будущие изменения; если будущих изменений нет, цели тоже нет.

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

Простой тест: если на вопрос «какой бизнес-сценарий мы откроем после миграции» нет внятного ответа — модернизацию имеет смысл отложить и заняться чем-то другим.

Что получает команда

Главный результат постепенной модернизации — управляемость. Команда начинает лучше понимать систему, контролировать изменения и снижать риск инцидентов.

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

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

Модернизация — это процесс, а не проект

Legacy нельзя «починить за квартал». Если система развивалась годами, она не станет простой после одного рефакторинга. Но её можно системно улучшать.

Strangler Fig Pattern, Branch by Abstraction, feature toggles, shadow testing и аккуратная миграция данных дают рабочую модель: выбрать ограниченный участок, описать контракт, реализовать новую версию, проверить её на реальном трафике, постепенно переключить пользователей и удалить старый код.

Это не самый быстрый путь. Зато он управляемый. А в зрелых продуктах управляемость важнее скорости.

Потому что цель модернизации — не написать красивую новую систему. Цель — сделать так, чтобы продукт продолжал развиваться, команда могла безопасно вносить изменения, а пользователи не становились участниками инженерного эксперимента.

GameNetworkingSockets (GNS) — это open-source транспортный слой для игр от Valve. UDP-сокеты с надёжной доставкой, шифрованием end-to-end, congestion control, NAT traversal через ICE, retry-логикой поверх ненадёжной сети. По устройству ближе всего к QUIC — UDP в основе, поверх свой надёжный канал, шифрование, фрагментация. Но это не QUIC: формат пакетов и хэндшейк свои, совместимости с RFC 9000 нет. Когда Valve открыла исходники в 2018 году, у инди-разработчиков и небольших студий появился рабочий движок сетевой части без необходимости заказывать его за миллионы долларов или писать самим с нуля.

С тех пор библиотеку взяли в самые разные продукты — от шутеров до симуляторов и до RPG. Major-тег 1.4.0 вышел в январе 2022 года, патч-релиз 1.4.1 — в июне 2022. С тех пор в репозитории шла обычная разработка — около 350 коммитов в master с фиксами и улучшениями, — но нового тега не было. 28 апреля 2026 года Valve собрала весь этот хвост в релиз 1.5 и подытожила, что именно изменилось.

v1.5.0 — первый тег за почти 4 года. Major-тег 1.4.0 вышел в январе 2022, патч 1.4.1 — в июне 2022. Накопленный хвост — около 350 коммитов в master с прошлого тега.

Поменялась семантика SendMessages. Раньше функция возвращала единый код, по которому невозможно было понять, какие из сообщений ушли. Теперь каждое сообщение получает свой результат, и интерфейс облегчает retry. Старый код, который игнорировал результат и работал как «отправь и забудь», нужно пересмотреть.

Новые конфиги: Explicit Congestion Notification (ECN), статистика jitter, IPLocalHost_AllowWithoutAuth и ещё несколько. Помогают тюнинговать поведение в стрессовых сетях и тестовых окружениях.

Native ICE-клиент по-прежнему в beta. Race-баги, ведущие к hang, починили; для production-P2P пока всё равно WebRTC ICE.

Появились первые Rust bindings — community-вклад, не официально поддерживаемый Valve, но рабочая отправная точка для Rust-проектов.

Что такое GameNetworkingSockets и кто на нём работает

GameNetworkingSockets — это библиотека сетевого транспорта, открытая Valve в 2018 году. По смыслу она ближе всего к QUIC: UDP в основе, поверх — собственный надёжный канал, шифрование, контроль перегрузки, фрагментация. Главное отличие — ориентация на игровой трафик: маленькие частые сообщения, тонкая конфигурация ретраев, поддержка ненадёжной доставки рядом с надёжной (можно выбрать на каждое сообщение).

Использует библиотеку прежде всего сама Valve: на ней работают Counter-Strike, Dota 2 и любой другой мультиплеер из Steam, который ходит через Steam Datagram Relay (SDR) — собственную сеть Valve, агрегирующую трафик через быстрые узлы поближе к игроку. Кроме Valve, библиотеку взяли разные инди- и middleware-проекты, плюс она встроена как дополнительный backend в несколько игровых движков.

У GNS есть два режима. Первый — клиент-сервер по обычному IP, без участия Steam-сети. Второй — P2P, через ICE для NAT traversal. P2P-режим требует внешнего signaling-сервера для обмена ICE-кандидатами между пирами; пример Valve поставляет в репозитории.

Что нового в 1.5

API: новая семантика SendMessages, плоский C API для Messages

Главное изменение в API — поведение ISteamNetworkingSockets::SendMessages при ошибках. Раньше функция возвращала единый код, который не давал понять, какие из сообщений ушли, а какие нет. Теперь каждое сообщение получает свой результат, а интерфейс облегчает retry — можно прозрачно переотправить только упавшие, не дублируя успешные. Если у вас в коде есть обёртка «отправил пачку — получил ОК или нет», её надо переписать под новый паттерн, иначе при сбоях часть сообщений просто потеряется.

Добавлен flat C API для ISteamNetworkingMessages — это режим, где сокеты привязываются не к connection-у, а к идентичности игрока, и отправка идёт по принципу «отправь пользователю X». Раньше этот режим был доступен только из C++. Теперь можно дёргать его и из C, и из любого языка с C FFI без C++-обёртки — что особенно актуально для Rust-, Go- и Python-биндингов.

Появилась хук-функция SteamNetworkingSockets_SetServiceThreadInitCallback — для тех, кто хочет подкрутить поведение сервисного потока (приоритет, имя, привязка к ядру) до того, как библиотека начнёт обрабатывать пакеты.

Надёжность и наблюдаемость

На уровне пакетов и очереди сообщений библиотека теперь автоматически корректирует часть out-of-order ситуаций — раньше эти случаи выливались в reorder-events для прикладного кода, и каждый разработчик разбирался с ними сам. Не идеальное решение для всех сценариев, но для игрового трафика — обычно то, что нужно по умолчанию.

Из новых конфигов и метрик:

• ECN (Explicit Congestion Notification) — поддержка пометок в IP-заголовке, чтобы роутеры могли сигнализировать о перегрузке без потери пакетов.
• Jitter stats — статистика разброса времени доставки, видимая через стандартные accessor-ы. Полезно для тонкой настройки буферов и плавности геймплея.
• IPLocalHost_AllowWithoutAuth — режим без аутентификации для localhost-соединений, удобен в тестовых сборках, dedicated-серверах локальной отладки и CI.
• ETW (Event Tracing for Windows) — диагностические события, видимые в Windows Performance Analyzer и аналогах.

P2P: ICE-клиенты, race-баги

P2P-стек получил серию точечных фиксов. В WebRTC ICE-клиенте, который Valve использует как основной для P2P, починили race-баги, которые приводили к hang при определённых таймингах рукопожатия. В нативном ICE-клиенте — собственной имплементации ICE-стека Valve, которая развивается параллельно ICE из WebRTC, исправили несколько багов, но он по-прежнему помечен как beta — для production пока рекомендуют WebRTC ICE.

Пример сигнального сервера в репозитории переписан с нуля на Python — раньше он жил на C++ и имел набор багов, которые мешали запустить локальный P2P-тест из коробки. Сейчас пример работает «как описано» и заодно проверяется в CI: P2P-сценарии добавили в авто-тесты, что для самоподдерживающейся кодовой базы серьёзный шаг.

Rust bindings, CMake/vcpkg, протобафы

В релиз попали первые официальные Rust bindings — но с дисклеймером community contribution: их пишет и поддерживает не Valve, а сторонние мейнтейнеры. Если планируете сетевой стек на Rust поверх GNS — подключите биндинг как зависимость, но будьте готовы к тому, что приоритет фиксов и обновлений отличается от основной библиотеки.

Интеграция с CMake и vcpkg существенно упрощена — собрать GNS без сторонних рецептов теперь реально на обычной машине. Параллельно починили совместимость с новыми версиями protobuf и abseil — последняя регулярная боль для тех, кто строил на vcpkg или conan.

Почему 4 года тишины

Valve в release notes причину не комментирует. Видимая динамика — около 600 коммитов в master за этот период, регулярные мерж-реквесты от внешних контрибьюторов, активное реагирование на issue. Пакетный релиз делается, по всей видимости, по другому критерию — когда внутреннее использование в продуктах требует фиксированной версии для интеграции.

Для пользователей библиотеки это означало одно из двух: либо собирать сборку из master и брать на себя риск сломанных интерфейсов, либо сидеть на 1.4, не получая четырёх лет улучшений. Релиз 1.5 закрывает обе дороги: можно зафиксироваться на стабильном теге и получить весь хвост.

Стоит ли переходить на 1.5

Если у вас 1.4 в продакшене:

• Тщательно проверьте код вокруг SendMessages — теперь по каждому сообщению есть свой результат, и старый «отправь и забудь» нужно дополнить логикой ретраев.
• Прогоните регрессионный тест P2P, если используете — race-баги в WebRTC ICE и нативном ICE затрагивали реальные сценарии и могли проявляться раз в N подключений.
• Подключите ECN и jitter stats к телеметрии — за 4 года накопилось чем мерить качество соединения, грех не воспользоваться.
• Если в ваших сборках болела совместимость с протобафом или abseil — берите 1.5: эти места починили.

Если выбираете между GNS и альтернативами для нового проекта — релиз 1.5 не меняет принципиально позиционирование. GNS остаётся хорошим выбором, когда нужен стабильный, проверенный в Counter-Strike транспорт с готовым P2P для NAT traversal. Для проектов, где важно глубже интегрироваться с QUIC, WebTransport или WebRTC напрямую, существуют более специализированные стеки. Между GNS и более минималистичными ENet, kcp, RakNet выбор зависит от потребностей: GNS даёт из коробки больше фич (ICE, шифрование, контроль перегрузки), ценой большего C++-кода и зависимостей; ENet и kcp компактнее и быстрее интегрируются.

Выводы

GameNetworkingSockets 1.5 — это спокойный пакетный релиз: четыре года накопленных улучшений, без масштабных переписываний интерфейсов. Главное API-изменение — семантика SendMessages, и это та правка, которую разработчики на 1.4 пропустить не смогут. Всё остальное — про observability, P2P-стабильность и удобство сборки.

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

Источники: релиз v1.5.0 на GitHub, репозиторий и документация, обзор у Phoronix.

14 апреля 2026 года OpenSSL Project выпустил OpenSSL 4.0 — первый мажорный релиз со времён 3.0 (сентябрь 2021). За четыре с половиной года накопилось много удалений и чуть поменьше новых возможностей. Разбираем, что именно сломается при апгрейде и ради чего всё это затевалось.

• OpenSSL 4.0 — первый мажор с 2021 года. Релиз 14 апреля 2026.
• Engine-интерфейс удалён полностью. Ломает gost-engine, старые PKCS#11- и TPM-адаптеры — мигрируйте на providers.
• Поддержка SSLv3 вырезана из кода (выключена по умолчанию была с 2016 года).
• ASN1_STRING стал непрозрачным — прямой доступ к полям через -> больше не компилируется.
• Появилась поддержка ECH (RFC 9849) — TLS прячет SNI от провайдера.
• Добавлен гибридный постквантовый обмен SM2+ML-KEM-768 и подпись ML-DSA-MU.

Что выпилили: список для миграции

OpenSSL 3.0 в 2021 году ввёл архитектуру providers и одновременно объявил engine-интерфейс устаревшим. Четыре года переходного периода закончились: engines больше нет в коде, опция сборки no-engine всегда включена, макрос OPENSSL_NO_ENGINE — всегда определён. Это самое болезненное для тех, кто держал кастомный крипто-плагин: GOST, аппаратные HSM, PKCS#11-токены со старым драйвером.

Из публичных API в 4.0 пропали или стали непрозрачными:

• Engine-интерфейс целиком — providers теперь единственный способ подключить внешнюю криптографию.
• Поддержка SSLv2 Client Hello и SSLv3. SSLv3 деприкейтнули ещё в 2015 году (RFC 7568), в 1.1.0 выключили по умолчанию в 2016-м, теперь удалили из кода.
• Структура ASN1_STRING стала непрозрачной. Прямой доступ к полям — через функции-аксессоры.
• ERR_get_state(), ERR_remove_state(), ERR_remove_thread_state() — объект ERR_STATE теперь непрозрачный.
• Кастомные методы EVP_CIPHER, EVP_MD, EVP_PKEY, EVP_PKEY_ASN1 — устаревшие API удалены.
• X509_cmp_time() и семейство деприкейтнуты в пользу X509_check_certificate_times().
• Скрипт c_rehash — использовать openssl rehash.
• BIO_f_reliable() — был сломан с 3.0 и без жалоб прожил все эти годы.
• Опция msie-hack в команде openssl ca.
• Таргеты сборки darwin-i386 и darwin-ppc.
• Устаревшие эллиптические кривые в TLS (RFC 8422) выключены в сборке по умолчанию — включаются флагом enable-tls-deprecated-ec.
• Explicit EC curves — аналогично, флаг enable-ec_explicit_curves.

Отдельно изменилось поведение глобальной очистки. libcrypto больше не ставит обработчик на atexit(); OPENSSL_cleanup() теперь вызывается как глобальный деструктор при выходе процесса — значит, освобождение памяти по умолчанию происходит позже и в непредсказуемом порядке относительно других деструкторов. Если вам нужна детерминированная очистка до завершения процесса (например, чтобы выявлять утечки под valgrind), вызывайте OPENSSL_cleanup() явно.

Что это значит для ГОСТ-криптографии

gost-engine — основной проект, который даёт OpenSSL понимание российских алгоритмов (ГОСТ Р 34.10-2012, ГОСТ Р 34.11-2012, «Кузнечик» и «Магма» по ГОСТ Р 34.12-2015). Как понятно из названия, он реализован именно как engine и без engine-слоя собраться и загрузиться в OpenSSL 4.0 не сможет.

Альтернатива — gostprov, провайдер от того же сообщества на новом API. На 15 апреля 2026 года gostprov покрывает базовые примитивы — ГОСТ Р 34.10-2012 (подпись), ГОСТ Р 34.11-2012 (хеш «Стрибог») и блочный шифр «Магма»/«Кузнечик» (ГОСТ Р 34.12-2015). Что ещё не закрыто по сравнению с gost-engine: часть схем шифрования CMS (ГОСТ-обёртки ключей), VKO KEK-2012 и ряд нишевых TLS-свитов. Если ваш продукт сертифицирован по требованиям ФСБ или продаётся в госсектор — апгрейд на 4.0 нужно планировать заранее, с пересертификацией.

Ветки 3.x продолжают поддерживаться: 3.5 — LTS до апреля 2030 года, 3.4/3.3 — обычные релизы с обновлениями безопасности. Если с 4.0 спешить некуда — остановитесь на 3.5 и дождитесь, пока gostprov покроет нужные вам примитивы.

Что добавили

Encrypted Client Hello (ECH)

ECH — это RFC 9849, принятый в марте 2026 года. В обычном TLS-рукопожатии первый Client Hello содержит SNI — имя сайта, к которому вы подключаетесь — в открытом виде. Провайдер видит его и по нему можно фильтровать трафик или собирать метаданные. ECH делит Client Hello на две части: ClientHelloOuter с именем фронтового домена идёт в открытую, а ClientHelloInner с настоящим SNI шифруется публичным ключом, опубликованным через DNS (HTTPS-запись).

OpenSSL 4.0 — первая мажорная версия с ECH в основной ветке. Серверная и клиентская стороны поддерживают draft-final в полном объёме. Документация проекта — doc/designs/ech-api.md.

Гибридный постквант: SM2+ML-KEM-768

OpenSSL поддерживает ML-KEM (Module-Lattice Key Encapsulation Mechanism, FIPS 203 — постквантовый обмен ключами) и гибриды с ним с версии 3.5. В 4.0 добавили ещё один гибридный обмен — curveSM2MLKEM768: китайский SM2 (RFC 8998) плюс ML-KEM-768 в качестве постквантовой части. Комбинация адресная — она нужна прежде всего для рынка КНР, где SM2 обязателен по национальному стандарту. Плюс новый алгоритм цифровой подписи ML-DSA-MU — вариант ML-DSA с внешним префиксом (prehash) для больших сообщений.

Для остального мира в релизе также появился cSHAKE (SP 800-185 — customizable SHAKE, версия SHAKE с доменным разделением). cSHAKE используется как строительный блок в новых стандартах NIST — именно на нём построен KMAC, а также часть постквантовых подписей. Плюс KDF для SNMP и SRTP — узкие штуки, но их в OpenSSL долго не было.

FFDHE в TLS 1.2 и прочие мелочи

FFDHE (finite-field Diffie-Hellman) по RFC 7919 — способ согласовывать группы для классического DH из фиксированного списка, а не из того, что сервер пришлёт. В TLS 1.3 это сделали сразу, в TLS 1.2 OpenSSL годами поддерживал только «пришли мне параметры». 4.0 закрыл этот пробел.

• FIPS self tests теперь можно откладывать до реального использования — флаг -defer_tests в openssl fipsinstall.
• На Windows можно выбирать статическую или динамическую линковку VC Runtime.
• Нижние границы параметров PKCS5_PBKDF2_HMAC теперь проверяются при работе в FIPS-провайдере.
• Проверка AKID добавлена при установленном X509_V_FLAG_X509_STRICT.
• CRL-верификация получила несколько дополнительных проверок корректности.

Как мигрировать на OpenSSL 4.0

1. Не обновляйтесь в лоб. Сначала прогоните вашу сборку с 3.5 и флагами -Wdeprecated-declarations и OPENSSL_NO_DEPRECATED_3_0, чтобы увидеть, где висит engine-API или структурный доступ к ASN1_STRING.
2. Составьте карту зависимостей: какие ваши библиотеки линкуются с OpenSSL и какие из них делают что-то нестандартное. Особое внимание — ко всему, где в коде встречается ENGINE_*.
3. Если используете ГОСТ — ставьте параллельно gostprov на 3.x, проверьте, что покрываются все ваши примитивы, и только после этого двигайтесь к 4.0.
4. Проверьте, как ваше приложение освобождает ресурсы OpenSSL. Если вы полагались на atexit()-финализацию или ранний OPENSSL_cleanup() в середине работы — добавьте явный вызов в точку, где очистка действительно нужна.
5. Пересоберите статические пакеты. OpenSSL 4.0 несовместим по ABI с 3.x — пакетные менеджеры дистрибутивов ближайшие месяцы будут подтягивать зависимости.

Выводы

OpenSSL 4.0 — релиз не столько про новые фичи, сколько про дочистку хвостов. За четыре с половиной года команда вывела из эксплуатации несколько слоёв устаревшего API и зафиксировала архитектуру providers как единственный способ подключать внешнюю криптографию. Цена — несовместимость по исходникам и ABI. На 15 апреля 2026 года крупные пакеты Debian, Ubuntu, RHEL и Fedora ещё линкуются с 3.x; пересборка экосистемы займёт месяцы, а для продуктов на engines (HSM-адаптеры, gost-engine, старые PKCS#11-драйверы) — ещё дольше.

Практический совет: если у вас нет конкретной нужды в ECH или SM2+ML-KEM-768, ближайший год можно спокойно сидеть на 3.5 LTS и следить за тем, как пересобираются ваши зависимости. Когда пакетные менеджеры дистрибутивов начнут подтягивать 4.0 автоматически — это и будет момент серьёзной миграции.

Полный changelog, downloadable tarballs и ключи для проверки подписи — на странице релиза на GitHub. Сам файл CHANGES.md — хорошее чтение на вечер для всех, кто хоть раз линковал с OpenSSL.

Интересный факт: все это происходит на фоне иска на астрономические $13 трлн, поданного платформой и крупными лейблами к библиотеке.

Что именно выложили

Пользователи Reddit заметили десятки новых раздач — всего 47 торрент-файлов объемом около 6,4 ТБ.

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

Сейчас раздачи идут медленно: у части торрентов всего по одному сидеру.

Важно: опубликованная часть — лишь фрагмент более масштабного архива. Ранее Anna’s Archive заявляла о «скрейпе» порядка 300 ТБ музыки — около 86 млн треков, что якобы покрывает 99,6 % всех композиций на Spotify.

Пока на торренты выложены только наименее популярные композиции с меткой pop_0 — это внутренняя шкала популярности Spotify от 0 до 100.

Отдельно библиотека уже публиковала 200-гигабайтный архив с метаданными — 256 млн треков и 186 млн уникальных ISRC-кодов.

Реакция Spotify и иск на триллионы

Spotify заявила, что выявила и заблокировала аккаунты, использовавшиеся для «незаконного скрейпинга». После этого компания вместе с крупными правообладателями подала иск против неизвестных операторов Anna’s Archive.

Сумма требований — $13 трлн — выглядит как какая-то нереалистичная цифра. Она получена исходя из максимальных компенсаций в США: до $150 000 за каждое предполагаемое нарушение авторских прав. Если умножить эту ставку на миллионы треков, итог и правда уходит в космос.

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

Это конец или только начало

После подачи иска Anna’s Archive временно скрыла раздел, посвященный загрузке музыки со Spotify. Публичных комментариев от проекта с тех пор не было. Однако появление торрентов показывает: процесс публикации, по крайней мере частично, продолжается.

Отдельная проблема для тех, кто теоретически захочет хранить весь архив — банальная физика. 300 ТБ — это десятки жестких дисков. Пользователи уже шутят, что стоимость хранилищ на фоне ИИ-бума делает «пиратство на таком масштабе» дорогим удовольствием.

Новый GC по умолчанию: минус до 40% накладных расходов

Так, в релизе включён сборщик мусора greenteagc. Он оптимизирован для частого создания и сканирования мелких объектов.

В приложениях с активной аллокацией это даёт снижение накладных расходов GC на 10–40%. Если у вас сервис с короткоживущими структурами, это обновление может стать бесплатным ускорением, без изменения кода.

cgo стал дешевле

Вызовы функций на C через cgo также подешевели примерно на 30%. Это важно для проектов, которые тянут нативные библиотеки (криптография, обработка изображений, старый C-код).

Дополнительно в runtime для 64-битных платформ включили рандомизацию адресного пространства (heap base). Это усложняет эксплуатацию уязвимостей в C-коде, подключённом через cgo. При необходимости можно отключить через:

new() теперь умеет принимать выражения

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

Было:

Теперь можно:

Мелочь, но код становится компактнее и чище.

Обобщённые типы: разрешили «ссылаться на себя»

Generics стали чуть гибче. Теперь тип может передавать сам себя в список параметров типа:

Раньше такая самоссылка вызывала ошибку. Теперь — нет. Для сложных generic-алгоритмов это снимает лишние ограничения.

Больше аллокаций в стеке, меньше в куче

Компилятор расширил список случаев, когда слайсы размещаются в стеке, а не в куче. А так как меньше давления на GC, то и выше производительность.

go fix переписали полностью

Команду go fix переписали на базе пакета analysis. Теперь она использует анализаторы из пакета modernize, которые предлагают правки с учётом новых возможностей языка и стандартной библиотеки.

Также появился анализатор inline — он разворачивает вызовы функций, помеченных директивой:

Новые пакеты

В стандартную библиотеку добавили:

• crypto/hpke — реализация Hybrid Public Key Encryption
• crypto/mlkem/mlkemtest
• testing/cryptotest

Появился экспериментальный simd/archsimd — низкоуровневый доступ к SIMD-инструкциям на AMD64. Это первый осторожный шаг Go в сторону управляемых векторных вычислений без ассемблера.

Также добавили экспериментальный runtime/secret для безопасного обнуления временной памяти и новый профиль goroutineleak в runtime/pprof — для поиска утечек горутин.

Скачать Go 1.26 можно по ссылке.

*WhatsApp заменил более 160 000 строк C++-кода на Rust в критически важной части приложения — обработке медиафайлов. Новый код уже развернут на миллиардах устройств: от Android и iOS до веба, десктопа и носимых гаджетов.

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

Откуда вообще взялась проблема

История тянется с 2015 года и уязвимости Stagefright в Android. Тогда выяснилось неприятное: достаточно отправить специально собранный видеофайл и он выполнит код на устройстве жертвы еще до того, как пользователь что-то нажмет.

Проблема была в системных медиабиблиотеках операционной системы. Именно поэтому приложения вроде *WhatsApp не могли решить ее самостоятельно.

После этого в *WhatsApp появился собственный C++-модуль wamedia, который проверял медиафайлы на соответствие стандартам, чтобы не скормить ОС заведомо опасный контент.

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

Почему именно Rust

В *WhatsApp довольно рано сделали неприятный, но честный вывод: значительная часть критических багов связаны с банальными ошибками работы с памятью в C и C++. Rust эту категорию проблем убирает на уровне языка.

Вместо аккуратного «подкручивания гаек», разработчики пошли чуть более радикальным путем: переписали медиабиблиотеку целиком, параллельно поддерживая две реализации — на C++ и на Rust.

Их прогоняли через дифференциальный фаззинг, тесты и сравнение поведения, пока результаты не совпали.

Что получилось на выходе

Итог оказался даже лучше ожидаемого. 160 000 строк на C++ превратились примерно в 90 000 строк на Rust. И это уже с тестами.

Производительность не просела, а потребление памяти в ряде сценариев даже снизилось. Основные сложности были не в коде, а вокруг него: размер бинарников из-за стандартной библиотеки Rust и сборка под десятки платформ.

Тем не менее, библиотеку полностью выкатили в прод. Сейчас этот Rust-код ежемесячно доставляется на миллиарды устройств, включая *WhatsApp, *Messenger и *Instagram.

В *Meta прямо называют это крупнейшим клиентским деплоем Rust, о котором им известно.

Зачем это пользователю, который «просто шлет мемы»

Новая система, внутри компании получившая имя Kaleidoscope, проверяет файлы еще до того, как ими займутся системные библиотеки.

Она отсекает битые и нестандартные структуры, ловит подмену типов (когда «картинка» на деле исполняемый файл), отдельно помечает рискованные форматы вроде PDF со скриптами и вложениями.

По сути, это еще один слой защиты. Пользователь его не видит, но это и не нужно.

Важно что речь идет только об async python.

Краткая сводка по sqlalchemy

sqlalchemy предоставляет Engine, который отвечает за пул подключений к базе данных. Так же sqlalchemy предоставляет Session через которую мы и делаем sql запросы. Сессия обладает одним единственным коннектом, который она получает от engine.

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

(На схеме 2 engine подключено к одной бд, что конечно странно. Тут хотелось просто подсветить что каждый engine имеет свой пул. В приложении вы будете иметь один engine для одной бд. Например 1 для мастера и 1 для реплики)

Внедрение и использование в приложении

Прямое использование

Для начала посмотрим на самое простое внедрение и ручное использование в котором используется только sqlalchemy и это можно внедрить куда угодно.

Создаем engine и создаем session_maker чтобы создавать сессии:

И вот представим у нас есть функция создания юзера, которая является ручкой:

На 2 строке мы открыли сессию, на 3 строке открыли транзакцию и наконец на 4 строке мы выполнили какой-то sql запрос относящийся к созданию юзера.

А теперь представим, что мы делаем два sql запроса в рамках создания юзера

Тут появляется 2 проблемы:

1. Используется 2 транзакции, хотя вероятно мы бы хотели получить одну транзакцию
2. Дублирование кода

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

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

Dependency

Можно использовать dependency и вынести управление сессией и транзакцией туда. Например в FastAPI это можно сделать так:

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

Так же теперь session нужно прокидывать по всему стеку вниз, до момента где эта сессия реально потребуется:

Как видите do_first сам не использует сессию, но вынужден принимать аргумент чтобы прокинуть его ниже. Лично мне это очень не нравится. Мне нравится инкапсулировать такое внутрь insert_to_database, тут скорее вкусовщина и борьба философий.

Обертки над sqlalchemy

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

Новая библиотека

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

Что хотелось получить от библиотеки при работе с ней:

• Мало кода без дублирования
• Автоматический commit или rollback, когда нет нужды вручную этим управлять
• Есть возможность ручного управления сессией и транзакцией
• Удобно для CRUD и удобно для сложных сценариев
• Не привносит новый синтаксис как обертки
• Не зависит от веб фреймворка

И вот что получилось:

Простейший сценарий

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

Функция db_session создает новую сессию с которой можно работать. Сессия будет закрыта в конце обработки запроса. Все. Вот так просто. 1 строка для получения сессии и выполняем нужные sql запросы.

А вот так выглядит несколько запросов в рамках одной сессии и транзакции:

Функция db_session не будет создавать новую сессию если она уже есть. Таким образом insert_user_profile использует ту же самую сессию и ту же транзакцию.

Досрочное закрытие транзакции

А что если хочется закоммитить заранее? Можно!

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

А еще лучше сделать вот так, как бы обернуть функцию в отдельную транзакцию:

Можно так же досрочно сделать rollback через rollback_db_session .

Досрочное закрытие сессии

Бывают ситуации, что нам нужно закрыть сессию, чтобы отпустить коннект, пока мы например делаем другую долгую работу. Можно сделать так:

close_db_session закрывает сессию. Когда update_something вызовет db_session он уже получит новую сессию и другой коннект.

Конкурентное исполнение запросов

В sqlalchemy нельзя делать 2 конкурентных запроса в одной сессии. Для этого нужно создавать отдельную сессию.

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

run_in_new_ctx запускает функцию в новом контексте, таким образом функция получит новую сессию. Так можно например использовать функции в gather или asyncio.create_task

Либо можно вообще использовать сессию не используя контекст вообще. Как в ручном режиме про который я рассказывал в начале

Эти способы можно комбинировать:

Другие сценарии

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

Интеграция библиотеки с приложением

Теперь посмотрим как интегрировать эту библиотеку в свое приложение. Я хотел сделать так, чтобы это было очень просто.

Начнем как раз с создания engine и session_maker, а так же ответим на вопрос что такое connect который все время передается в функции библиотеки. За параметры соединения с базой данных отвечает DBConnect

Предполагаемое использование - глобальный инстанс, который отвечает за жизненный цикл engine и session_maker.

Он принимает на вход 2 фабрики:

• engine_creator - фабрика по созданию engine
• session_maker_creator - фабрика по созданию session_maker

Вот примеры:

host - опциональный параметр хоста базы данных к которой нужно подключиться.

Почему хост опционален и почему фабрики? Потому что либа позволяет переподключаться к бд в рантайме. Это важно, например, при работе с мастером и репликой.

У DBConnect есть еще один опциональный параметр - обработчик, который будет вызван перед созданием новой сессии. Там вы можете поместить какую угодно логику:

В конце жизни вашего приложения нужно корректно закрыть соединение. Для этого у DBConnect есть метод close

А вот всю самую важную магию по управлению сессиями и транзакциями берет на себя middleware. Ее очень просто подключить.

Вот пример для FastAPI:

Так же есть чистая ASGI middleware

Тестирование

Тестирование - очень важная часть разработки. Я предпочитаю тестировать с реальным живым postgresql. И в таком случае есть важная проблема, которую нужно решить - изоляция данных между тестами. И базово есть 2 подхода:

• удалять данные из бд между тестами. Тогда у приложения своя транзакция, у теста своя
• делать общую транзакцию между тестом и приложением, чтобы делать rollback

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

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

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

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

Библиотека предоставляет пару удобств для тестирования:

Первая из них это rollback_session - сессия, которая всегда будет откатываться в конце. Ее на самом деле в обоих видах тестов стоит использовать

А вот специально для тестов с общими транзакциями есть set_test_context и put_savepoint_session_in_ctx

Эта фикстура создаст контекст заранее. Таким образом приложение будет работать в этом контексте, а не будет создавать свое. А так же там будет лежать подготовленная сессия, которая вместо commit будет делать release save point.

Как все работает

Вот схема как все работает:

middleware инициализирует контекст. Ваше приложение приложение обращается к этому контексту через функции библиотеки. В конце middleware закрывает все незакрытое и закрывает контекст.

Как работает middleware:

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

Итог

Подведем итог. Получилась классная либа, которая помогает работать с sqlalchemy:

• Мало кода без дублирования
• Автоматический commit или rollback, когда нет нужды вручную этим управлять
• Есть возможность ручного управления сессией и транзакцией
• Удобно для CRUD и удобно для сложных сценариев
• Не привносит новый синтаксис как обертки
• Не зависит от веб фреймворка
• удобно тестировать

Используйте!

• Библиотека доступна под MIT лицензией
• Открытый исходный код на github
• Есть документация
• Доступен в pypi

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

Не забудьте поставить звезду на github, если понравился проект! Спасибо!

Почему релиз Node.js 22 важен

30 апреля 2025 года завершился жизненный цикл версии Node.js 18. Сообщество заранее предупреждало об этом через официальный аккаунт в X. Там напомнили разработчикам о необходимости перейти на более свежие версии — Node.js 20 или 22. Восемнадцатая версия перестала получать патчи безопасности, поэтому обновление стало критичным для поддержания стабильной работы приложений.

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

Хотя релиз этой версии не выглядел революционным, он существенно изменил основу платформы. Многие возможности, которые раньше требовали внешних библиотек, теперь встроены прямо в платформу: WebSocket-клиент, стабильный fetch(), работа с файлами, Blob и URL, улучшенная совместимость ESM и CommonJS. Это уменьшает количество зависимостей, снижает вероятность уязвимостей и значительно упрощает поддержку проектов.

Помимо удобства разработки, в новой версии усилились производительность и безопасность. Обновлённый движок V8 ускоряет выполнение кода, а оптимизация старта и снижение потребления памяти делают Node.js более стабильным в высоконагруженных и serverless-сценариях. Улучшенная модель разрешений, строгие настройки TLS и расширенная поддержка AbortController повышают защиту на уровне рантайма, ограничивая последствия уязвимостей в сторонних пакетах. Это даёт компаниям возможность строить более надёжные сервисы с меньшими затратами на контроль рисков и эксплуатацию.

Node.js 22 также стал удобнее для работы гибридных команд. Стабильная интеграция ESM и CommonJS облегчает миграцию старых проектов, а унификация Web-API делает код универсальным и понятным даже для сотрудников без глубокого опыта в бэкенде. Улучшенные инструменты тестирования и диагностики повышают прозрачность разработки и снижают время на нахождение ошибок.

Node.js 22 — эволюционный релиз. Он развивает ранее введённые возможности (fetch, ESM, WebSocket и др.), но не переворачивает парадигму разработки. Это укрепление уже заданного курса.

Возможности Node.js 22

Расширение JavaScript и обновление V8. Получив движок V8 12.x, Node.js подтянул все улучшения ECMAScript 2024. Код стал исполняться быстрее как за счёт оптимизаций в компиляторе, так и благодаря улучшенной работе с асинхронностью. Например, async/await теперь обрабатываются эффективнее, а создание структур данных, активно используемых в серверах, стало менее затратным.

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

Corepack включён по умолчанию. До выхода Node.js 22 разработчики сами решали, подключать ли Corepack. Теперь он активен без дополнительной настройки, и это серьёзное изменение в экосистеме. Все менеджеры пакетов контролируются единой прослойкой, что устраняет зависимость от версии, установленной глобально у разработчика или в CI.

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

Corepack, как мне кажется, сильно упростит жизнь большим командам. Исчезает вечная история “а у меня Yarn другой версии” или “Pnpm не подтянулся”. Corepack берёт на себя управление версионированием менеджеров пакетов, а значит, сборки становятся более воспроизводимыми. Для корпоративных проектов это плюс, особенно если речь идёт о распределённых командах или CI/CD-конвейерах.

WebSocket API и улучшенные Web Streams. Node.js 22 внедрил нативную поддержку WebSocket API. Теперь можно создавать WebSocket-клиенты и серверы без сторонних библиотек вроде ws. Это делает код чище и ближе к браузерному API.

Параллельно были улучшены Web Streams. Работа с потоками стала предсказуемой, а инструменты вроде CompressionStream и DecompressionStream функционируют так же, как и в современных браузерах. Поддержка универсального кода — сервер + клиент — стала проще, а объём внешних зависимостей уменьшился.

Улучшения в работе CommonJS и ESM. Node.js постепенно движется в сторону ESM, но у огромного количества проектов всё ещё используется CommonJS. В новой версии улучшена производительность смешанных проектов и сокращены ошибки при импорте модулей между двумя системами. Между ними появилось меньше «подводных камней», а значит миграция на ESM может идти постепенно, без ломки архитектуры.

Стабильный встроенный fetch(). Его реализация теперь полностью совпадает с браузерной, так что в простых кейсах можно отказаться от axios или node-fetch. Меньше зависимостей — быстрее запуск и меньше технического долга.

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

Я бы отметил более зрелую работу с Permission Model. Она уже не экспериментальная и реально помогает ограничивать доступ к файловой системе и сети. Параллельно улучшилась производительность V8, а вместе с ней и общая отзывчивость серверных приложений. Подтянули и Web-стек: стабильнее стали Web Streams, Request/Response и другие API, которые сближают Node с браузерами. Всё это не революция, но тренд на унификацию растёт.

Расширенные возможности тестирования. Node.js продолжает развивать встроенный тестовый фреймворк node:test. Теперь доступны кастомные репортеры, покрытие кода без внешних инструментов и mock timers (замена реальной работы таймеров). Это позволяет использовать встроенный тест-раннер для большинства задач, отказавшись от Jest или Vitest в простых проектах.

Обновления в безопасности. Обновление OpenSSL — одно из самых чувствительных изменений в релизе. Поддержка старых криптоалгоритмов исключена, проверка сертификатов стала строже, а взаимодействие по TLS 1.3 стабильнее.

С точки зрения безопасности рывка не произошло, но заметное движение есть: Permission Model, улучшенная работа с OpenSSL, более аккуратная валидация входящих данных. Всё это снижает риски, но полностью опасность не снимает, потому что реальная безопасность всё равно лежит в архитектуре, процессов CI/CD и культуре разработки.

Повышенная производительность. Заметные улучшения коснулись старта приложения, работы с памятью и производительности под нагрузкой. Приложения запускаются быстрее, а распределение нагрузки между worker threads стало более эффективным. Это позволит обслуживать больше запросов при тех же ресурсах и уменьшить расходы на инфраструктуру.

Международные стандарты и локализация. Были обновлены Intl API на базе новой версии ICU. Преимущества: точные часовые пояса, поддержка новых календарей и систем чисел. Это критично для глобальных SaaS-платформ, аналитических сервисов и финтех-продуктов.

По словам Даниила Гоника, для разработчиков наиболее значимы такие изменения, как WebSocket-клиент, модульная система., обновление V8, улучшение JIT-компиляторов, добавление новых возможностей JS и улучшение встроенного test-раннера.

Как безопасно мигрировать на Node.js 22

Переход лучше начинать с аудита и подготовки окружения. Сначала стоит убедиться, что все зависимости поддерживают Node.js 22. Особенно это касается библиотек, которые используют нативные модули, криптографию и WebSockets. Проверка совместимости позволит избежать неожиданностей вроде ошибок компиляции или падений при запуске.

После этого нужно прогнать тесты. Даже минимальный набор позволит выявить проблемы, связанные с изменениями в ESM/CJS, WebSocket API или OpenSSL.

Само обновление среды зависит от выбранного инструмента. Через nvm или n процесс занимает секунды, а для Docker достаточно указать новый базовый образ. Если проект использует CI/CD, стоит уделить внимание Corepack: теперь он активен всегда, что может изменить поведение сборки.

После обновления полезно проверить логи и внимательно изучить предупреждения. Большинство проблем решается установкой последних версий библиотек, иногда — правкой конфигурации TLS или обновлением менеджера пакетов.

Обновление стоит внедрять поэтапно, начиная со staging или частичного продакшена, и держать готовность к откату.

Я обычно советую подход двухконтурного обновления. Сначала поднять проект на 22-ю версию в отдельной среде, включить максимальный объём логов, запустить тесты и прогнать реальные сценарии. Потом обновить линтеры, сборщики и самые старые пакеты, чтобы убрать накопленные за годы предупреждения. И только когда всё стабильно, имеет смысл переключать продакшен. По сути, обновление Node нужно делать так же аккуратно, как обновление облачных сервисов: через изоляцию, наблюдаемость и бэкап-стратегию.

В Node.js 22 удалены некоторые устаревшие, малоиспользуемые функции, поэтому при переходе может потребоваться рефакторинг мест, где они использовались. Следует проверить депрекейты: Node.js 22 помечает ряд старых возможностей как устаревшие и предлагает альтернативы. Необходимо убедиться, что все библиотеки и пакеты, используемые проектом, поддерживают новую версию Node.js.
При скачке сразу с 18/20 на 22 некоторые зависимости могут оказаться несовместимыми с обновлённым движком V8 или новыми APIs — может понадобиться их обновление до последних версий.

Кому стоит подождать с переходом

Переход на Node.js 22 подходит не всем проектам. В некоторых ситуациях разумнее подождать, чтобы избежать регрессий и поломок в продакшене. Вот кому стоит повременить с переходом:

• Тем, кто использует инструменты сборки или менеджеры пакетов, которые ещё не совместимы с Node.js 22 и могут выдавать ошибки или не работать вовсе.​
• Командам, которые работают на старых версиях ОС. Известны проблемы совместимости с macOS 10.14 и ниже, а также возможны ошибки на Windows при миграции старых приложений.​
• Тем, чьи CI/CD, контейнеры или Docker-образцы завязаны на конкретные версии Node.js и npm. Переход на 22-ю версию требует много регрессионного тестирования.​
• Проектам с критически важными C++-добавками. Смена major-версии влечёт за собой обновление бинарных интерфейсов, что может вызывать ошибки при компиляции нативных модулей.
• Пользователям определённых интеграций. Для некоторых версий MongoDB‑драйверов зафиксированы фатальные баги после перехода на конкретные промежуточные версии Node.js 22.x.​
• Если вы используете проекты, которые сами рекомендуют Node.js 18 или 20, а обновление их зависимостей под 22 только планируется.

В продакшене чаще всего проблемы возникают не из-за самих изменений в платформе, а из-за того, как эти изменения проявляются в реальных проектах. Где-то обновился V8 и стал вести себя строже, где-то повылезали deprecated-модули, а где-то просто сломались сборщики или старые зависимости. Многие команды до сих пор живут на Webpack 4, Express 4 или TypeORM старых версий: вот они первыми столкнутся со сложностями.

Что дальше

Среди будущих трендов в экосистеме Node.js Максим Захаренко выделяет следующие: «Первое — постепенное сближение Node с Web-стеком, чтобы код становился максимально универсальным. Второе — рост влияния Bun и Deno, которые будут подталкивать Node к более агрессивной оптимизации. И третье — всё более активная интеграция с AI-инструментами, особенно в DevTools и в цепочках генерации кода».

Всё больше веб-API внедряются в Node.js (fetch, WebSocket, EventTarget). Этот тренд будет продолжаться. ESM становится стандартом, поддержка будет расширяться, CommonJS постепенно уйдёт в прошлое. Расширяется WASI и поддержка WASM-модулей. Node.js движется в сторону мульти-языковой среды. Модель прав доступа и другие sandbox-механизмы также продолжат развиваться. Кроме того, в версии Node.js 22.5.0 экспериментально добавлен встроенный модуль SQLite (через –experimental-sqlite). Это важное уточнение: в релизе 22.0.0 SQLite отсутствовал.

Даниил Гоник хотел бы увидеть в будущих релизах стабильную и удобную модель разрешений, возможность require() для ESM без флагов, улучшения в DevX: поддержка TS «из коробки», больше инструментов в ядре, расширение SEA (Single Executable Apps) и встроенные механизмы верификации зависимостей (подписи, integrity).

Выводы

Node.js 22 делает приложения быстрее, безопаснее и совместимее с Web API, улучшает работу с памятью и снижает зависимость от глобальных инструментов. Хотя переход требует подготовки, он не представляет серьёзных рисков, если следовать базовой процедуре: проверить зависимости, прогнать тесты и обновить среду постепенно. Если инфраструктура современная, а стек устойчивый, переход на Node.js 22 принесёт ощутимые преимущества как в скорости работы, так и в удобстве разработки.

Недавно я понял, что вместо того, чтобы использовать “правильный инструмент для задач” я просто использую инструменты, которые сказали на работе — и это определило языки программирования, которые я знаю. Последние пару месяцев я потратил много времени на эксперименты с языками, которые не использую в рабочих проектах. Цель не была в том, чтобы стать экспертом — я хотел сформировать мнение о том, для чего каждый язык действительно хорош.

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

Этот вопрос важен для меня, потому что я не хочу выбирать язык по чек-листу, будто покупаю увлажнитель воздуха. Меня волнует создание софта и мои инструменты. Делая свои компромиссы, языки выражают набор ценностей. Я хочу понять, какие ценности резонируют со мной.

Этот вопрос также помогает прояснить разницу между языками, которые на первый взгляд сильно пересекаются по возможностям. Судя по количеству вопросов статей вроде “Go или Rust” и “Rust или Zig”, люди тоже не понимают, что происходит. Сложно запомнить, что язык X лучше для веб-сервисов, потому что у него есть фичи a, b и c, а у языка Y только a и b. Гораздо проще запомнить, что язык X лучше для веб-сервисов, потому что язык Y создан человеком, который ненавидит интернет (условно) и считает, что нужно вырубить всю сеть.

Я собрал здесь мнение о трёх языках, с которыми недавно экспериментировал: Go, Rust и Zig. Я попытался превратить свой опыт с каждым языком в общий вывод о том, что этот язык представляет из себя и насколько хорошо реализует свои ценности. Да, это упрощение, но кристаллизация упрощённых предубеждений — именно то, что я здесь и делаю.

Go: минимализм для корпораций

Go выделяется своим минимализмом. Его называют “современным C”. Go не похож на C, потому что у него есть сборщик мусора и полноценная среда выполнения, но он похож на C тем, что весь язык помещается в голове.

Весь язык помещается в голове, потому что в Go очень мало возможностей. Долгое время Go был известен отсутствием дженериков. Их наконец добавили в Go 1.18, но только после 12 лет, в течение которых люди умоляли это сделать. Другие возможности, обычные для современных языков — например, размеченные объединения (tagged unions) или синтаксический сахар для обработки ошибок — в Go так и не появились.

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

Ещё один пример минимализма Go — тип slice. И в Rust, и в Zig есть slice, но это толстые указатели (fat pointers) и только они. В Go slice — это толстый указатель на непрерывную последовательность в памяти, но slice также может расти. То есть он объединяет функциональность типа Vec<T> из Rust и ArrayList из Zig. Кроме того, поскольку Go управляет памятью за вас, он сам решает, где будет жить память вашего slice — в стеке или куче. В Rust или Zig вам придётся сильно задуматься, где живёт ваша память.

История происхождения Go, насколько я понимаю, примерно такая: Роб Пайк устал ждать компиляции проектов на C++ и устал от ошибок, которые другие программисты Google делали в тех же проектах на C++. Поэтому Go прост там, где C++ перегружен. Это язык для рядовых программистов, спроектированный быть достаточным для 90% задач и при этом простым для понимания, даже (или особенно) при написании конкурентного кода.

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

Rust: максимализм ради безопасности

Если Go минималистичен, то Rust максималистичен. Популярный слоган Rust — “абстракции с нулевой стоимостью” (zero-cost abstractions). Я бы дополнил: “абстракции с нулевой стоимостью, и их очень много!”

У Rust репутация сложного для изучения языка. Я согласен с Джейми Брэндоном, который пишет, что Rust делает сложным не система времён жизни (lifetimes), а количество концепций, запиханных в язык. Я не первый, кто приводит в пример этот конкретный комментарий на GitHub, но он идеально показывает концептуальную плотность Rust:

Тип Pin<&LocalType> реализует Deref, но не реализует DerefMut. Типы Pin и & помечены #[fundamental], так что возможна реализация DerefMut для Pin<&LocalType>>. Вы можете использовать LocalType == SomeLocalStruct или LocalType == dyn LocalTrait, и можете привести Pin> к Pin>. (Действительно, два слоя Pin!!) Это позволяет создать пару “умных указателей, реализующих CoerceUnsized, но имеющих странное поведение” на стабильной версии (Pin<&SomeLocalStruct> и Pin<&dyn LocalTrait> становятся умными указателями со «странным поведением», и они уже реализуют CoerceUnsized).

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

Цель производительности понятна сама по себе. Что означает “безопасность” — менее очевидно, по крайней мере для меня (хотя, может быть, я просто слишком долго писал на Python). “Безопасность” означает “безопасность памяти” — идею, что вы не должны иметь возможность разыменовать невалидный указатель или сделать двойное освобождение памяти. Но это также означает больше. “Безопасная” программа избегает всего неопределённого поведения (undefined behavior, или UB).

Что такое ужасное UB? Лучший способ понять это — вспомнить, что для любой работающей программы ЕСТЬ СУДЬБЫ ХУЖЕ СМЕРТИ. Если в программе что-то идёт не так, немедленное завершение — это прекрасно! Потому что альтернатива, если ошибка не поймана — ваша программа переходит в сумеречную зону непредсказуемости, где её поведение может определяться тем, какой поток выиграет следующую гонку данных, или тем, какой мусор оказался по конкретному адресу памяти. Теперь у вас хайзенбаги и дыры в безопасности. Очень плохо.

Rust пытается предотвратить UB без потери производительности во время выполнения, проверяя всё во время компиляции. Компилятор Rust умный, но не всеведущий. Чтобы проверить ваш код, ему нужно понимать, что код будет делать во время выполнения. Поэтому в Rust есть выразительная система типов и множество трейтов, которые позволяют объяснить компилятору то, что в другом языке было бы просто видимым поведением кода во время работы.

Это делает Rust сложным, потому что вы не можете просто взять и сделать что-то! Вы должны узнать, как Rust это называет — найти нужный трейт или что-то ещё — и реализовать это так, как Rust ожидает. Но если вы это делаете, Rust может дать гарантии о поведении вашего кода, которые другие языки не дают, а это в зависимости от приложения может быть критично. Он также может давать гарантии о чужом коде, что делает использование библиотек в Rust простым и объясняет, почему проекты на Rust имеют почти столько же зависимостей, сколько проекты в экосистеме JavaScript.

Zig: свобода и контроль

Из трёх языков Zig самый новый и наименее зрелый. На момент написания статьи Zig на версии 0.14. У его стандартной библиотеки почти нет документации, и лучший способ научиться её использовать — читать исходный код напрямую.

Не знаю, правда ли это, но мне нравится думать о Zig как о реакции одновременно на Go и Rust. Go прост, потому что скрывает детали того, как работает компьютер. Rust безопасен, потому что заставляет прыгать через свои обручи. Zig освободит вас! В Zig вы контролируете вселенную, и никто не может указывать, что делать.

И в Go, и в Rust выделить объект в куче просто — достаточно вернуть указатель на структуру из функции. Выделение памяти неявное. В Zig вы выделяете каждый байт сами, явно. (В Zig ручное управление памятью.) У вас больше контроля, чем даже в C: чтобы выделить байты, нужно вызвать alloc() на конкретном виде аллокатора, то есть вы должны выбрать лучшую реализацию аллокатора для вашего случая.

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

Неопределённое поведение всё ещё важно в Zig

Zig называет его “нелегальным поведением” (illegal behavior). Он пытается обнаружить его во время выполнения и обрушить программу, когда это происходит. Для тех, кого беспокоит стоимость таких проверок по производительности, Zig предлагает четыре разных “режима релиза” на выбор при сборке программы. В некоторых проверки отключены. Идея в том, что вы можете запустить программу достаточно раз в проверяемых режимах, чтобы иметь разумную уверенность: в непроверяемой сборке нелегального поведения не будет. Это кажется мне очень прагматичным дизайном.

Ещё одно различие между Zig и двумя другими языками — отношение Zig к объектно-ориентированному программированию. ООП давно не в моде, и Go, и Rust избегают наследования классов. Но в Go и Rust достаточно поддержки других идиом ООП, чтобы вы могли построить программу как граф взаимодействующих объектов, если захотите. В Zig есть методы, но нет приватных полей структур и нет языковой возможности для полиморфизма во время выполнения (динамической диспетчеризации), хотя std.mem.Allocator просто умирает стать интерфейсом. Насколько я могу судить, эти исключения намеренны; Zig — язык для дата-ориентированного дизайна (data-oriented design).

Ещё одна вещь, которую я хочу сказать, потому что она открыла мне глаза: может показаться безумием создавать язык программирования с ручным управлением памятью в 2025 году, особенно когда Rust показал, что сборка мусора не нужна и компилятор может всё сделать за вас. Но это дизайнерский выбор, тесно связанный с выбором исключить возможности ООП. В Go, Rust и множестве других языков вы обычно выделяете маленькие кусочки памяти за раз для каждого объекта в графе объектов. У вашей программы тысячи маленьких скрытых malloc() и free(), и, следовательно, тысячи разных времён жизни. Это RAII. В Zig может показаться, что ручное управление памятью потребует много утомительной, подверженной ошибкам работы, но это так только если вы настаиваете на привязке выделений памяти к каждому маленькому объекту. Вместо этого вы можете просто выделять и освобождать большие куски памяти в определённых разумных точках программы (например, в начале каждой итерации цикла событий) и использовать эту память для данных, с которыми работаете. Именно этот подход и поощряет Zig.

Многие люди не понимают, зачем нужен Zig, если уже есть Rust. Дело не только в том, что Zig пытается быть проще. Думаю, разница более важная. Zig хочет, чтобы вы вырезали ещё больше объектно-ориентированного мышления из своего кода.

У Zig весёлая, подрывная атмосфера. Это язык для разрушения корпоративной классовой иерархии (объектов). Это язык для мегаломанов и анархистов. Мне он нравится. Надеюсь, он скоро выйдет в стабильный релиз, хотя текущий приоритет команды Zig — переписать все свои зависимости. Не исключено, что они попытаются переписать ядро Linux, прежде чем мы увидим Zig 1.0.

Go — для командной работы и быстрой разработки, Rust — для критически важных систем, где нужны максимальные гарантии, Zig — для тех, кто хочет полного контроля и готов от ООП отказаться в пользу дата-ориентированного подхода. Выбор зависит не от списка фич, а от того, какая философия вам ближе.

В версии urllib3 2.6.0 разработчики удалили несколько API, которые считались проблемными еще с 2019 года и были официально помечены как устаревшие с 2022-го.

Все было сделано «по правилам»: предупреждения в документации, changelog, отдельные сообщения через DeprecationWarning при каждом использовании устаревших методов.

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

После релиза выяснилось, что удаление API стало сюрпризом даже для активно поддерживаемых проектов — зависимых библиотек и крупных клиентов.

Почему предупреждения никто не заметил

Ключевая проблема в том, что DeprecationWarning в Python по умолчанию отключен. Он находится в списке предупреждений, которые интерпретатор просто игнорирует, если разработчик явно не включил их показ.

В итоге ситуация выглядела так: API годами «кричал» о своей устарелости, но его никто не слышал.

Когда методы удалили, пользователи и сопровождающие популярных библиотек — Kubernetes-клиента, Fastly, Airflow — столкнулись с поломками и неожиданными ошибками.

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

Предупреждение есть, эффекта нет

Вывод автора жесткий: DeprecationWarning в текущем виде не работает для Python-библиотек. Он формально существует, но экосистема его просто не воспринимает как сигнал к действию.

Парадокс в том, что сам механизм warnings в Python удобный и встроенный прямо в язык. Но именно DeprecationWarning оказался слишком «вежливым» — он не мешает, не ломает код и потому остается незамеченным.

Какие есть варианты выхода

Ларсон рассматривает несколько возможных путей:

• создавать собственные предупреждения на базе UserWarning, которые не игнорируются по умолчанию;
• отказаться от длительных периодов устаревания и делать более частые мажорные релизы по SemVer, как это принято в криптографических библиотеках;
• менять культуру работы с предупреждениями в Python — но это долгий и малореалистичный путь.

Что это значит для экосистемы

История с urllib3 показала: даже в зрелой и массовой экосистеме стандартные механизмы могут перестать выполнять свою функцию. DeprecationWarning задумывался как мягкий способ предупредить пользователей, но на практике он стал «мертвым письмом».

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

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

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

GUI для скачивания видео: yt-channel-downloader

yt-channel-downloader — графическое приложение для скачивания видео с YouTube и любых других сайтов, где есть видеоконтент. Это не только видеохостинги: если на странице есть видео, приложение попытается его скачать.

Под капотом работает связка из трёх Python-библиотек: yt-dlp для универсального парсинга, scrapetube для работы с каналами и плейлистами, pytube как вспомогательный инструмент. Поверх этого — кроссплатформенный графический интерфейс для Windows, macOS и Linux.

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

Полезные особенности:

• Вход в аккаунт YouTube прямо из приложения. Это позволяет скачивать приватные ролики, доступные только по ссылке или для авторизованных пользователей. Куки хранятся в локальном конфиге и автоматически очищаются при выходе из аккаунта.
• Пометка уже скачанных файлов. Не нужно вручную проверять, что уже есть на диске.
• Ограничение параллельных потоков. Если качаете большой плейлист, можно задать лимит одновременных загрузок, чтобы очередь не подвисала и не перегружала канал.

Для работы нужен установленный ffmpeg — он используется для конвертации и склейки потоков. Для пользователей Windows доступен готовый инсталлятор в разделе Releases (размещён на SourceForge).

Код и инструкции по установке — на GitHub. В планах у автора: поддержка скачивания YouTube Shorts, поиск по полученному списку видео, более наглядный прогресс-бар, история загрузок и расширенная поддержка других видеоплощадок.

gopass — менеджер паролей для разработчиков

gopass — консольный менеджер паролей, заточенный под командную работу и версионирование. Все секреты хранятся в виде файлов, шифруются через GPG и версионируются в Git. Вы можете держать их локально, синхронизировать через любой git-ремоут (GitHub, GitLab, собственный сервер) и при этом всегда иметь историю изменений.

Рабочий цикл выглядит консольно и привычно для разработчиков. Из терминала вы листаете хранилище командой gopass ls, смотрите конкретный пароль через gopass show, генерируете новый — gopass generate. Копирование в буфер обмена тоже работает из командной строки, что удобно для скриптов и автоматизации.

Поверх базовой функциональности есть плагины:

• gopass-bridge — интеграция с браузером. Позволяет автоматически заполнять формы входа без копирования паролей вручную.
• Помощь с Git-кредами. gopass может выступать credential helper для Git, так что пароли от репозиториев тоже хранятся зашифрованными и версионируются.
• Проверка через Have I Been Pwned. Можно проверить, не утекли ли ваши пароли в публичные базы.

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

gopass написан на Go, поэтому работает на macOS, Linux и Windows без дополнительных зависимостей. Настройка сводится к созданию git-репозитория с зашифрованными файлами и клонированию его на рабочие машины. Один репозиторий — доступ с любого устройства.

Код в репозитории, документация подробная, есть примеры для всех основных сценариев использования.

Self-hosted SSH-клиент: Termix

Termix — полностью опенсорсная и self-hosted альтернатива Termius для управления серверами по SSH через единый веб-интерфейс. Разворачивается в Docker как бэкенд, синхронизируется с клиентами под веб, Windows, Linux, macOS, iOS и Android.

Ключевые возможности:

• SSH-терминал с вкладками и сплитами. Можно открыть до 4 панелей одновременно, переключаться между сессиями, кастомизировать тему оформления и шрифты. Всё работает через браузер или нативное приложение.
• SSH-туннели с автопереподключением. Настраиваете туннель один раз, система сама восстанавливает соединение при обрывах и отслеживает состояние туннелей в реальном времени.
• Файловый менеджер поверх SSH. Можно просматривать и редактировать код прямо в интерфейсе, смотреть картинки, слушать аудио, проигрывать видео, загружать и выгружать файлы, выполнять операции копирования, перемещения, удаления — всё без отдельного SFTP-клиента.
• Менеджер хостов. Организация серверов по тегам и папкам, автоматическая заливка SSH-ключей на хосты, безопасное хранение логинов и паролей в зашифрованной базе.
• Мониторинг. Для любого подключённого сервера можно посмотреть загрузку CPU, память, диск, сеть, аптайм и системную информацию. Есть дашборд с общим обзором по всем хостам.

Под капотом: веб-клиент собран на React + Tailwind + Shadcn, бэкенд работает с зашифрованной базой SQLite, автоматическая настройка SSL-сертификатов, вход через OIDC и двухфакторная аутентификация (TOTP). Интерфейс поддерживает несколько языков.

Проект распространяется под Apache 2.0. Основной способ установки — docker-compose с томом для данных, всё настраивается за пару минут. Для десктопа и мобильных устройств доступны нативные сборки и приложения в официальных сторах под все основные платформы.

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

TUI-клиент для торрентов: Torrra v2

Torrra — TUI-клиент для поиска и скачивания торрентов прямо из консоли, без браузера и без отдельного GUI-приложения. Написан на Python, интерфейс собран на библиотеке Textual, так что всё выглядит аккуратно и отзывчиво даже в терминале.

Можно подключаться к своим индексаторам Jackett или Prowlarr, смотреть результаты поиска и выбирать, чем качать. Есть два режима: через встроенный движок на базе libtorrent или передать magnet-ссылку во внешний торрент-клиент (Transmission, qBittorrent и так далее).

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

Установить можно несколькими способами:

• Через pipx: pipx install torrra
• Из AUR для пользователей Arch Linux
• Через Homebrew на macOS
• Docker-образ для изолированного запуска
• Готовые бинарники под Linux, macOS и Windows

После установки минимальный сценарий работы такой: поднимаете Jackett или Prowlarr (это отдельные сервисы для агрегации торрент-индексаторов), запускаете

Дальше стрелками ходите по списку результатов, Enter — начать скачивание, p — пауза, r — продолжить, q — выйти из программы.

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

Проект кроссплатформенный (Linux/macOS/Windows) и активно развивается: есть подробная документация, регулярные релизы, автор отвечает на issues. Код в репозитории, на видео можно посмотреть демонстрацию работы.

Защита от подглядывания: EyesOff для macOS

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

Написано на Python + PyQt, модель распознавания лиц крутится локально на вашем Mac — ничего не уходит в облако, никакие кадры не сохраняются. Есть три режима оповещения на выбор:

• Попап на экране — появляется окно с предупреждением, что кто-то смотрит.
• Системная нотификация — более деликатный вариант, уведомление в углу экрана.
• Автозапуск приложения — можно настроить, чтобы автоматически запускалась блокировка экрана или любое другое приложение.

Автор написал подробный разбор того, как тренировал модель детекции. Интересный момент: он оптимизировал accuracy не в среднем по всем дистанциям, а конкретно для mid-range (~1-2 метра) — именно там обычно стоят любопытные коллеги. На близких дистанциях (менее метра) и дальних (более трёх метров) точность может быть ниже, но это компромисс ради производительности и практичности.

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

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

Все пять инструментов объединяет один принцип: контроль над своими данными. Вы не зависите от подписок, облачных сервисов или закрытых платформ. Каждый из них решает конкретную задачу, делает это хорошо и не требует доверять кому-то свои пароли, SSH-ключи или видео с камеры. Код открыт, можно проверить, как всё устроено, и при желании — доработать под свои нужды.

Именно этот релиз завершил важный этап стабилизации асинхронных возможностей фреймворка. Он поддерживает Python версий с 3.10 по 3.13, что покрывает потребности большинства разработчиков.

Асинхронность в Django прошла долгий путь: начало было положено в версии 3.0 с базовой поддержкой ASGI, в Django 4.0 появились асинхронные ORM-запросы. В версии 5.1 этот инструмент окончательно сформировался для высокопроизводительных приложений, и его успели проверить «в боевых условиях» много разработчиков.

Зачем вообще нужна асинхронность?

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

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

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

Основное преимущество асинхронности — эффективная работа с операциями ввода-вывода. Это запросы к внешним API, взаимодействие с файлами и базами данных. В таких сценариях асинхронный код может обрабатывать больше запросов на том же оборудовании — в некоторых случаях до 3-5 раз, в зависимости от нагрузки и конфигурации..

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

Импортируем необходимые библиотеки:

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

Асинхронный ORM: текущее состояние

Django 5.1 продолжает улучшать асинхронную поддержку ORM (Object-Relational Mapping — система, которая позволяет работать с базой данных как с набором Python-объектов). Большинство операций с БД теперь имеют асинхронные версии. Но важно понимать ограничения.

Полностью асинхронные запросы работают только с драйверами, поддерживающими асинхронность. Для PostgreSQL это psycopg3, для MySQL — aiomysql. SQLite имеет ограниченную асинхронную поддержку.

Пример асинхронного ORM-запроса:

Методы, начинающиеся с «a» (aget, alist, afirst), предоставляют асинхронный интерфейс к стандартным ORM-операциям.

Производительность: реальные показатели

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

Архитектурные преимущества асинхронности реализуются, если соблюден ряд условий:

• используется ASGI-сервера вместо WSGI;
• правильно настроены асинхронные драйверов базы данных;
• нет блокирующих операций в основном потоке выполнения.

При грамотной реализации это позволяет обрабатывать тысячи одновременных соединений без пропорционального увеличения потребления памяти.

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

Типичные ошибки и как их избежать

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

Ошибка: вызов синхронной функции из асинхронного контекста без обертки.

Неправильный подход:

Правильное решение:

Другая распространенная проблема — блокирующие вызовы в асинхронном коде. Даже в асинхронной функции такие операции как сложные вычисления или синхронные HTTP-запросы будут блокировать цикл событий.

Решение — выносить ресурсоемкие задачи в отдельные потоки через asyncio.to_thread или использовать специализированные воркеры.

Типичная ошибка: неправильная работа с транзакциями в асинхронном контексте. Синхронные транзакции Django не работают с асинхронным кодом.

Неправильно:

Правильное решение — использовать sync_to_async для обертки всей транзакции:

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

Проблемный код:

Решение — использовать семафоры для ограничения параллелизма:

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

Неправильно:

Правильный подход — учитывать специфику асинхронных исключений:

Ошибка блокировки цикла событий долгими CPU-bound операциями. Асинхронность не ускоряет вычисления, а только улучшает работу с вводом-выводом.

Проблемный код:

Решение — вынос вычислений в отдельный поток:

Ошибка неправильного использования глобальных переменных в асинхронном коде. Состояние может изменяться неожиданно из-за параллельного выполнения.

Опасный код:

Решение — использование контекстных переменных или передача состояния явно:

Ошибка создания взаимной блокировки при неправильном использовании примитивов синхронизации. Асинхронные блокировки имеют свои особенности.

Проблемный код:

Решение — проектировать код так, чтобы избегать вложенных блокировок и использовать timeout:

Исключив эти ошибки, сможете создавать более надежный и производительный асинхронный код в Django 5.1.

Когда асинхронность не нужна

Асинхронность — мощный инструмент, но не универсальное решение. Есть сценарии, где ее применение не дает преимуществ, а только усложняет код.

Ситуации, когда асинхронность избыточна:

• Простые CRUD-приложения без внешних вызовов — если приложение в основном выполняет базовые операции с базой данных и не взаимодействует с внешними API, синхронный код проще для понимания и отладки.
• Проекты с небольшой нагрузкой — когда количество одновременных пользователей измеряется десятками, а не тысячами, дополнительные затраты на управление асинхронными задачами перевешивают преимущества.
• Команды без опыта работы с асинхронным кодом — асинхронное программирование требует понимания цикла событий и корутин (легковесных программ, которые позволяют писать асинхронный код так, как будто он синхронный). Ошибки сложнее обнаружить и исправить.
• Приложения с интенсивными вычислениями — Python GIL ограничивает параллельное выполнение CPU-bound задач, поэтому для вычислений лучше подходит многопроцессорность.
• Интеграция со сторонними библиотеками — многие популярные Python-библиотеки не поддерживают асинхронность, приходится использовать обертки sync_to_async.
• Быстрая разработка и тестирование — написание и отладка асинхронных тестов занимает больше времени, что критично для стартапов.
• Высокие требования к надежности — синхронная архитектура предсказуемее и надежнее для проектов, где стабильность важнее производительности.
• Ограниченные ресурсы разработки — стоимость разработки и поддержки асинхронных приложений обычно выше из-за требований к квалификации команды.
• Миграция legacy-проектов — переписывание существующих синхронных систем на асинхронность рискованно и часто неоправданно.
• Микросервисная архитектура — выделение отдельных сервисов для асинхронных задач часто практичнее, чем преобразование всего приложения.

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

Миграции в Django 5.1: эволюция продолжается

Система миграций — один из самых мощных инструментов Django. В версии 5.1 она получила значительные улучшения в производительности и надежности.

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

Рассмотрим пример улучшенного обнаружения изменений. Было в models.py (основном файле для описания структуры базы данных):

В Django 4.2 это могло создать две отдельные миграции. В 5.1 система понимает, что created и created_at — одно поле, и генерирует одну миграцию с операцией RenameField и изменением max_length.

Безопасные миграции больших таблиц

Работа с таблицами в миллионы записей всегда была болезненной точкой. Блокировки таблиц при применении миграций могли приводить к простоям приложения.

В Django 5.1 представлен атрибут Operation.category. Он позволяет классифицировать операции миграций. Команда showmigrations теперь отображает специальные символы для каждой операции. Это упрощает чтение плана миграций. Разработчики быстрее понимают структуру изменений в базе данных.

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

Новые опции в миграциях:

Миграции с данными: лучшие практики

Миграции данных остаются мощным, но опасным инструментом. Ошибки в этом процессе может привести к катастрофическим последствиям.

Как делать правильно:

• всегда тестировать миграции на полной копии production-данных;
• использовать пакетную обработку для больших объемов данных;
• предусматривать откат для каждой операции с данными;
• добавлять индикатор прогресса для долгих миграций

Пример безопасной миграции данных:

Интеграция с облачными базами данных

В 2025 году большинство проектов развернуты в облачных средах. Django 5.1 улучшил поддержку облачных баз данных типа Amazon RDS, Google Cloud SQL и Azure Database.

Основные улучшения:

• лучшая обработка временных разрывов соединения;
• поддержка реплик для чтения для распределения нагрузки;
• улучшенная работа с пулами соединений;
• автоматическое переподключение при обрывах.

Конфигурация для облачной PostgreSQL:

Django 5.1 сделал встроенную поддержку пулов соединений PostgreSQL через psycopg3, чтобы сократить расходы на установку соединений.

Мониторинг и отладка асинхронного кода

Отладка асинхронного кода требует специальных подходов. Трассировка стека в асинхронных приложениях сложнее из-за работы цикла событий (event loop).

Новые инструменты для мониторинга:

• ASGI middleware (промежуточный слой) для мониторинга производительности;
• интеграция с системами мониторинга производительности приложений;
• специализированные логи для асинхронных операций;
• метрики для event loop.

Пример middleware для мониторинга:

Тестирование асинхронных приложений

Тестирование асинхронного кода в Django требует использования специальных тестовых классов и подходов.

Пример тестирования асинхронной вьюхи:

Безопасность асинхронного кода

Асинхронность приносит новые векторы атак. Состояния гонки, взаимные блокировки и проблемы с разделением состояния становятся более вероятными.

Как минимизировать риски:

• использовать потокобезопасные структуры данных;
• избегать разделяемого изменяемого состояния;
• тщательно тестировать на состояния гонки;
• использовать асинхронные версии блокировок при необходимости.

Пример безопасной работы с разделяемыми ресурсами:

Миграционная стратегия для legacy-проектов

Перевод существующего проекта на асинхронность требует продуманного подхода.

Рекомендуется постепенная миграция:

1. Начать с новых эндпоинтов, реализуя их асинхронно.
2. Выделить наиболее нагруженные части API для перевода на async.
3. Использовать гибридный подход, где это необходимо.
4. Тщательно тестировать производительность на каждом этапе.

Пример гибридного подхода. Старые синхронные вьюхи остаются:

Новые эндпоинты делаем асинхронными:

Гибридный эндпоинт:

Производительность в продакшене: метрики и мониторинг

При развертывании асинхронных приложений важно отслеживать правильные метрики.

Традиционные метрики веб-приложений дополняются специфическими для async:

• Event loop latency — задержки в обработке событий;
• Active tasks — количество активных асинхронных задач;
• Queue size — размер очереди задач;
• Database connection pool usage — использование пула соединений.

Настройка мониторинга:

Итоги: асинхронность как стандарт

Django 5.1 знаменует переход асинхронности из категории экспериментальных возможностей в стандартный инструмент разработки. Стабильность и производительность async-компонентов достигли уровня, позволяющего использовать их в production-проектах.

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

Ключевые выводы для разработчиков в 2025 году:

• асинхронные вьюхи готовы к использованию в продакшене;
• наибольший выигрыш от асинхронности — в сценариях с интенсивным вводом-выводом;
• миграции стали надежнее и безопаснее для больших баз данных;
• постепенная миграция legacy-кода — оптимальная стратегия;
• мониторинг и тестирование требуют адаптации под асинхронную парадигму.

Django продолжает эволюционировать, поддерживая равновесие между современными требованиями и обратной совместимостью. Асинхронность в Django 5.1 — это закономерный этап развития фреймворка, который уже более 15 лет входит в топ наиболее популярных инструментов для веб-разработки на Python.

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

Но теперь эта «шутка» стала наглядной — проект Stacktower превращает рисунок в настоящую визуализацию зависимостей.

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

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

Как работает Stacktower

Сайт предлагает две модели: «стабильную башню» и «неустойчивую башню», где уровни подстраиваются под выбранные библиотеки.

Пользователь может загрузить зависимости своих приложений — например, на Python или JavaScript — и увидеть, что будет, если убрать даже один элемент.

На странице приводится пример для Node.js:

приложение зависит от Express → Express зависит от body-parser → body-parser зависит от qs → и так далее

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

Есть и Python-вариант:

импорт Flask тянет Werkzeug, Jinja2, MarkupSafe, Click и еще несколько пакетов. А те, в свою очередь, имеют собственные зависимости.

Зачем это нужно

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

Стек современных приложений неизбежно сложен и даже крошечный модуль может стать критически важным. Именно так в 2022 году случайное удаление библиотеки left-pad временно «сломало» огромный кусок JavaScript-мира.

Stacktower превращает эту абстрактную проблему в понятный визуальный эффект: убираешь одну зависимость — рушится вся конструкция.

Комьюнити уже подхватило идею

Проект быстро разошелся по Reddit, Hacker News и X: разработчики делятся скриншотами своих «башен», спорят о хрупкости экосистем и обсуждают, стоит ли пересматривать подход к зависимости.

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

Изучить проект подробнее можно на его странице на GitHub.

В сети появился материал, автор которого — программист с 20+ летним стажем — вспоминает, как еще в 90-е взрослые уверяли его, что программирование обречено.

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

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

Мультимедиа, IDE и другие «концы света», которые не случились

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

Но через несколько лет это стало обыденностью — просто очередным <video /> в HTML. Никто массово не разорился из-за отсутствия мультимедиа в продуктах.

В 2000-х на горизонте появился новый «убийца профессии» — умные IDE вроде IntelliJ. Автодополнение, рефакторинг, перенос классов, исправление ошибок до сборки — все это казалось магией, которая вот-вот заменит людей.

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

Автоматизация в реальности: она освобождает время, а не людей

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

Вывод простой: работы становится не меньше, а больше. Автоматизация убирает рутину, но не отменяет необходимости решать новые проблемы.

Новые ввения приходят и уходят, но разработка остается

Интернет, Web 2.0, машинное обучение — каждая волна начиналась как революция и заканчивалась чем-то будничным. Мы привыкли к тому, что технологии, которые вчера казались чудом, сегодня воспринимаются как мелочь.

Текущая волна ИИ — не исключение. Да, большие языковые модели меняют рабочие процессы. Да, они автоматизируют часть задач.

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

Вместо финала: ИИ не убьет разработчиков, но сделает их работу другой

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

Как и последние 30 лет, разработка остается живой потому, что мир постоянно усложняется. А значит — всегда будет кому этот мир программировать.

Эта статья написана с помощью сервис . Исходник — видео и гайд про новые t-строки в Python 3.14.

Эволюция форматирования строк в Python

Процентный стиль (%) — с самого начала

Python умел форматировать строки через процент с первых версий:

Класс Template — Python 2.4

В модуле string появился альтернативный способ:

Метод format() — Python 2.6

Форматирование стало компактнее:

F-строки — Python 3.6

Этот синтаксис быстро стал стандартом де-факто:

T-строки — Python 3.14

Новый инструмент для отложенной интерполяции:

Когда использовать t-строки

Для разработчиков приложений

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

Для авторов библиотек

T-строки полезны при разработке библиотек, где пользователям нужна отложенная интерполяция. Типичные сценарии:

• Экранирование SQL-запросов перед выполнением
• Обработка HTML перед рендерингом
• Работа с регулярными выражениями
• Предварительная обработка данных перед объединением в строку
• Отложенная интерполяция (как в модуле logging)

Отличия f-строк от t-строк

Ключевое различие: f-строки выполняют интерполяцию немедленно и возвращают готовую строку, t-строки возвращают объект Template с отложенной интерполяцией.

Проблема, которую не решают f-строки

Рассмотрим функцию dedent из модуля textwrap, которая удаляет общие отступы из текста:

Результат:

Функция корректно убирает общие отступы, но сохраняет относительные:

Результат:

Где f-строки создают проблему

Возьмём многострочный код:

Попробуем вставить его в f-строку и передать в dedent:

Получаем некорректный результат:

Первая строка кода имеет отступ, остальные — нет. Вся выходная строка обработана неправильно.

Причина проблемы

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

F-строка взяла строку без общих отступов (code) и поместила её внутрь строки с отступами. Когда итоговая строка попала в dedent, функция не смогла корректно определить, что нужно было сначала добавить отступы к подставляемому значению, а потом убрать общие отступы.

Функция dedent не может посмотреть историю и понять структуру исходной f-строки.

Как работают t-строки

T-строки возвращают объекты Template

F-строка возвращает готовую строку:

T-строка возвращает объект Template:

Итерация по объекту Template даёт смесь строковых фрагментов и объектов интерполяции:

Применение t-строк

Объект Template позволяет библиотекам предварительно обрабатывать интерполируемые части перед финальной сборкой строки.

Решение проблемы dedent с t-строками

Используем t-строку вместо f-строки:

Корректный результат:

Версия dedent, работающая с t-строками, видит, что подставляемое значение имело относительные отступы внутри более крупной строки, но само содержимое не было с отступами. Функция корректно применяет отступы к подставляемому значению перед удалением общих отступов у всей строки.

Реализация dedent для t-строк

Кастомная версия dedent для работы с t-строками:

Функция выполняет следующие операции:

1. Использует стандартный dedent из модуля textwrap
2. Обрабатывает каждое интерполируемое значение в зависимости от его содержимого
3. Учитывает позицию значения внутри более крупной строки
4. Корректно применяет отступы перед финальной обработкой

Эта реализация доступна в виде библиотеки better-dedent в индексе пакетов Python:

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

Вывод по t-строкам: нужны или нет

Писать t-строки просто

Синтаксис t-строки идентичен f-строке, меняется только префикс:

Работать с Template сложнее

Работа с объектом Template, который возвращает t-строка, требует понимания его структуры: нужно уметь итерироваться по частям и обрабатывать интерполяции.

В большинстве случаев вы не будете напрямую работать с t-строками и объектами Template в повседневном коде. Вы будете передавать их в библиотеки, которые специально разработаны для приёма t-строк.

Если библиотека поддерживает t-строки — передайте ей t-строку. Всё остальное библиотека обработает сама.

Перспективы t-строк

Python 3.14 вышел недавно, поэтому примеров использования t-строк в реальных проектах пока немного. Создатели t-строк ведут список awesome t-string для тех, кто хочет следить за развитием экосистемы.

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

Первичка и не только

Когда мы говорим «бухгалтерские документы», мы имеем в виду не пару стандартных бланков, а множество первичных, учредительных, учетных и распорядительных документов, полуструктурированных и гибких форм. Среди них счета-фактуры, УПД, формы ТОРГ-12, транспортные накладные, акты, УКД, КСФ, ИСФ, уставы, приказы, бухгалтерский баланс, отчеты о финансовых результатах и многие другие.

Визуальный контроль и ручная перепечатка этих документов в системы бухучета – одна из наиболее времязатратных задач бухгалтерии. Даже при выборочной проверке и среднем уровне автоматизации сотрудник успевает обработать около 200-300 документов в день, в то время как объем документооборота у крупных компаний исчисляется десятками и сотнями тысяч страниц.

Снять практически 100% нагрузки в части ввода и проверки данных из бумажных документов и поступающих по ЭДО сканов можно при помощи OCR-систем. Автоматическое распознавание документов исключает человеческий фактор и связанные с ним ошибки. Если сотрудник может банально устать или некорректно перенести информацию из документа, то ИИ, напротив, обеспечивает высочайшую точность извлечения данных.

Возможности ИИ для работы с бухгалтерскими документами

Для автоматизации работы с бухгалтерскими документами недостаточно простого полнотекстового распознавания. Чтобы действительно принести видимый экономический эффект, система OCR должна классифицировать документ, обнаруживать и считывать таблицы, чекбоксы и штрихкоды, извлекать даты, суммы, данные контрагентов, контролировать наличие подписей в документах, а также поддерживать распознавание многостраничных форм. Только такой комплекс возможностей ИИ способен внести реальный вклад в упрощение бухучета, учета НДС и налогов по УСН, ускорить делопроизводство и сэкономить часы времени сотрудников.

Мы в Smart Engines занимаемся разработкой таких решений. Наш флагманский продукт для распознавания документов Smart Document Engine способен выполнить месячный объем работы отдела из 10 бухгалтеров всего за 1 час. Система обрабатывает изображения документов без передачи данных в облака, на внешние серверы или краудсорсинговые платформы. Это означает, что содержание документов не покидает устройство сотрудника – бизнес при этом получает гарантию сохранения коммерческой тайны.

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

Интеграция в Android

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

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

На этом этапе мы должны подготовить изображение для передачи в сессию. Мы создаем изображение класса se.common.Image с помощью соответствующих методов API.

Например, вы выбираете из галереи что-то в формате HEIC и система возвращает вам bitmap

Объект result содержит в себе не только распознанные поля документа, но и изображение документа: исправленное по перспективе и обрезанное по шаблону, уровень уверенности распознавания каждого поля и т.п.

Интеграция в iOS

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

Первый вариант интеграции – ручной.

Вы перетаскиваете себе в проект две папки, одна из них содержит xcframework, обертку на objc и бандл. Вторая - готовый UI-контроллер, который можно вызывать из своего проекта.

Также необходимо в проекте прописать пути к заголовкам обертки и указать путь к файлу *-Bridging-Header.h, для раскрытия делегатов в swift из нашего контроллера.

Более удобные для интеграции SPM и Cocoapods мы тоже поддерживаем.

Сценарий взаимодействие с библиотекой на iOS точно такой же как и на Android, но в iOS мы имеем больше инкапсулированной логики. Для начала следует добавить в ваш класс два протокола SmartDocumentEngineDelegate, SmartDocumentEngineInitializationDelegate

Приведем сразу коллбек imagePicker, где реализована основная логика распознавания после выбора изображения из галереи.

Ожидать результата следует в делегате.

Объект результата по структуре идентичен объекту, который вы получаете в Android.

Подведем итоги

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

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

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

Если PEP примут, Python впервые за историю станет «двуязычным» проектом — частично на C, частично на Rust.

Зачем Python нужен Rust

Разработчики приводят несколько причин:

• Безопасность памяти. Rust устраняет категории ошибок, привычные для C: use-after-free, гонки, переполнения.
• Подготовка к free-threaded Python. Переход к работе без GIL требует безопасных примитивов — Rust подходит идеально.
• Производительность. Rust позволяет создавать быстрые структуры данных без ручного менеджмента памяти.
• Современный стек. Linux, Android и Firefox уже используют Rust в системных компонентах — Python догоняет тренд.
• Поддержка долгосрочного развития CPython. Сложность кода растет, а Rust упрощает сопровождение.

Что именно планируют делать

Стоит отметить, что Rust не планируют использовать в качестве полной замены C — появится возможность использовать оба языка. В идеале, должен получиться симбиоз:

• Crate cpython-sys. Это набор автоматически сгенерированных привязок (FFI-слоя), которые позволяют Rust-коду безопасно «общаться» с внутренним API CPython.
• Поддержка модулей на Rust. Некоторые части стандартной библиотеки можно будет писать и подключать так же, как C-модули — только на Rust.
• Прозрачное разделение зон безопасности. «Безопасный» Rust будет использоваться по максимуму, а unsafe — только там, где нужно напрямую взаимодействовать с C-частями интерпретатора.

Уже есть рабочий пример — модуль _base64 на Rust, который оказался быстрее варианта на C.

Переходный план

Если PEP утвердят, переход займет три релиза:

• Python 3.15 — предупреждение при сборке без Rust.
• Python 3.16 — Rust остается опциональным, но его отключение потребует отдельного флага.
• Python 3.17 — Rust становится обязательной частью сборки CPython.

То есть через два релиза Python не соберется там, где нет Rust.

Какие есть проблемы

В обсуждении упоминают несколько рисков. Например, циклическая зависимость при сборке — Rust требует Python, Python требует Rust.

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

Появятся и сложности со сборкой в ограниченных средах, например embedded-системах. При этом остается неясной судьба Rust-API для сторонних расширений — скорее всего, его не откроют.

Что это значит для сообщества

Для пользователей Python почти ничего не изменится. А вот для разработчиков интерпретатора это станет одним из самых крупных сдвигов в истории проекта.

Так, Python наконец-то станет сильно безопаснее. При этом CPython получит более надежный фундамент для будущих фич вроде полного отказа от GIL.

О том, как компании используют open-source для развития продуктов и какие возможности это открывает для бизнеса, расскажет Сергей Востриков, руководитель направления «Маркетплейс и интеграции» Битрикс24.

Почему вокруг библиотек формируется комьюнити

Сообщества не возникают вокруг библиотек случайно. Они формируются там, где инструмент становится стандартом, а его создатели — открыты к диалогу и улучшениям. Так случилось с React от Meta, который определил язык фронтенд-разработки на годы вперёд. Или с Kubernetes, начавшимся как внутренняя инфраструктура Google, а со временем превратившимся в экосистему с тысячами плагинов и сервисов. FastAPI, созданный Себастьяном Рамиресом, получил поддержку благодаря простоте и продуманной архитектуре — контрибьюторы пришли сами, потому что инструмент был ясен и полезен.

В экосистеме Битрикс24 открытая модель работает по тем же законам. Компания публикует документацию по REST API, SDK для популярных языков, инструменты для интеграций и тестирования. Это позволяет внешним разработчикам создавать собственные решения — от платёжных модулей до отраслевых сервисов, которые точно отвечают запросам локального бизнеса. В результате формируется живая сеть партнёров и интеграторов — люди вкладываются в продукт, потому что видят в этом устойчивую ценность и пространство для роста. Даже если компания делится не самим ядром продукта, а вспомогательными инструментами, эффект оказывается значительным — появляется среда, где развитие идей становится совместным усилием.

В чем выгода бизнеса

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

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

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

Экономическая логика open-source

Open-source давно перестал быть жестом альтруизма. За ним стоит чёткая экономическая логика. Когда ядро продукта доступно бесплатно, компания переносит монетизацию на уровень сервисов, инфраструктуры и качества опыта. Пользователь получает гибкость и надёжность, бизнес — масштаб без роста издержек. Такая модель делает код открытым, но ценность — платной.

Сила open-source — в сетевом эффекте. Каждый новый плагин, библиотека или интеграция увеличивают полезность продукта и усложняют его замену. Экосистема начинает жить собственной жизнью — контрибьюторы расширяют функциональность, компании создают коммерческие надстройки, а ценность бренда растёт за счёт активности сообщества. Поддержка распределяется между тысячами участников, снижая нагрузку на core-команду и ускоряя внедрение новшеств.

Есть и долгосрочный дивиденд — репутация. Популярный open-source-проект становится витриной инженерной культуры компании. Он облегчает найм, укрепляет доверие к бренду и даёт компании влияние на технологические стандарты рынка. Так формируется экономика вокруг продукта, где вклад в общее развитие напрямую повышает устойчивость бизнеса.

Типичные ошибки

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

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

По сути, успешный open-source управляется так же, как зрелая продуктовая команда — через цели, процессы, ответственность, прозрачность. Разница лишь в том, что всё это работает не в рамках одного офиса, а в распределённой среде, где людей объединяет общий интерес.

Open-source стал одной из редких моделей технологического сотрудничества, где интересы бизнеса и профессионального сообщества совпадают естественным образом. Компании получают инструмент ускорения развития, а разработчики — среду, в которой можно расти, делиться опытом и влиять на технологическую повестку. Такой обмен создаёт эффект синергии. Чем активнее сообщество, тем устойчивее продукт и тем выше ценность всей экосистемы.

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

Все началось с дружеского спора: автор и его знакомый решили за месяц решить 100 задач, чтобы проверить, насколько это реально. Цель была достигнута быстро — и стала привычкой.

Спустя полтора года у него за плечами 700+ решенных задач и впечатляющий стрик длиной в 600 дней.

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

«LeetCode — это спорт»

По словам разработчика, примерно после сотни задач он заметил, как мозг начинает видеть паттерны: «алгоритмы перестают быть абстракцией и становятся шаблонами действий».

После 300 задач появилась уверенность, а к 600 — автоматизм: больше не страшно видеть длинные цепочки функций, не путаешься в деревьях и графах, а выбор структуры данных становится интуитивным.

Он выделяет три типа решений на платформе:

• Производительные и сложные, где «изобретают велосипед» ради скорости;
• Элегантные, но непроизводительные, зато читаемые и похожие на реальный продакшн-код;
• «Чтобы просто работало» — типичные решения новичков без оптимизаций.

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

Стоило ли того?

По мнению автора поста, LeetCode помогает тем, кто хочет попасть в биг-тех, разобраться в алгоритмах, или просто тренировать мозг. Но для повседневной работы в типичном проекте навыки из LeetCode пригодятся разве что косвенно — как понимание сложности операций или знание стандартной библиотеки.

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

Среди советов начинающим — не гнаться за hard-задачами, смотреть чужие решения и помнить, что прогресс измеряется не количеством, а осознанностью.

В итоге разработчик делает вывод, знакомый каждому, кто сталкивался с LeetCode:

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

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

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

Некоторые люди начинают с относительно низкоуровневого программирования на C и C++. Другие выбирают более традиционный путь, изучая Java или C#. Есть и те, кто начинает с высокоуровневых или скриптовых языков вроде Python, Ruby или JavaScript.

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

Низкоуровневые языки: близко к «железу»

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

Примеры: C (для ОС вроде Linux), C++ (для игр на движке вроде Unreal Engine), Assembler (для оптимизации критических частей кода).

Плюсы:

• Полный контроль: вы решаете, как использовать ресурсы. Так, в C++ можно вручную выделять память для массивов, избегая ненужных копий данных.
• Высокая скорость: прямой доступ к памяти позволяет писать код, который работает быстрее (это важно для работы с играми или серверами).
• Основы основ: такие языки учат, как компьютер работает изнутри, чтобы в будущем ценить удобства других языков. Например, вы узнаёте, почему «утечка памяти» — это проблема.
• Эффективность: низкоуровневые языки мотивируют думать об оптимизации заранее, снижая расход батареи или CPU.
• Компактность: минимальная библиотека, приложения получаются лёгкими (идеально для embedded-систем, как в IoT-устройствах).

Минусы:

• Всё-таки это сложно: рутинные задачи (например, чтение файла) требуют больше кода и внимания к деталям, рискуя ошибками вроде переполненного буфера.
• Ручное управление памятью: можно легко «забыть» освободить память, вызвав утечки или краши. Например, в C нужно использовать malloc/free, иначе программа съест всю RAM.
• Много копипасты: придётся писать шаблонный код, и делать это часто.
• Платформо-зависимость: код для Windows может не работать на Linux без правок.

Среднеуровневые языки: баланс контроля и удобства

Эти языки предлагают готовые инструменты, упрощающие работу, но требуют строгой проверки типов данных. Для их запуска нужна специальная программа (среда выполнения). Они идеальны для приложений, серверов и игр.

Примеры: Java (для Android-приложений), C# (для Unity-игр или .NET-серверов).

Плюсы:

• Автоматическая память: память очищается автоматически благодаря сборщику мусора, что избавляет от ручной работы и снижает вероятность ошибок, вроде утечек памяти в больших проектах. При этом можно получить доступ к низкоуровневым функциям для особых задач, например, через специальные инструменты в Java.
• Богатые библиотеки: готовые инструменты для сетей, GUI или баз данных. Пример: Java’s Spring для веб-серверов.
• Кроссплатформенность: компиляция в байт-код (JVM для Java) позволяет запускать код везде. Например, пишешь на Windows, запускаешь на Linux.
• Безопасность: язык проверяет типы данных перед запуском программы, помогая заранее найти ошибки. Среда выполнения защищает от опасных сбоев, например, от переполненной памяти.
• Масштабируемость: встроенные инструменты для параллельных вычислений позволяют легко создавать программы, которые одновременно выполняют много задач (серверы для тысяч пользователей и т.п.).

Минусы:

• Дополнительная нагрузка от рантайма: Среда выполнения и автоматическая очистка памяти создают дополнительную нагрузку. Сборщик мусора может ненадолго останавливать программу, что заметно в играх или при обработке видео.
• Меньше контроля: абстракции скрывают детали памяти, усложняя оптимизацию (например, в Java сложно избежать боксинга примитивов).
• Повторяющийся код, которого много: приходится писать повторяющийся код и тренировать свою усидчивость, например, для доступа к данным объекта. Кстати, инструменты вроде Lombok могут упростить эту задачу.
• Зависимость от среды: для запуска программ нужна специальная среда (например, JVM для Java), что влияет на размер программ и замедляет их старт.
• Сложность интеграции: подключение кода на других языках, например, на C, требует писать специальные обёртки, что усложняет работу и снижает скорость.

Высокоуровневые языки: удобство и скорость разработки

Эти языки скрывают технические детали, позволяя сосредоточиться на создании логики программы. Подходят для веба, data science или скриптов.

Примеры: Python (для ML), Ruby (для веб-разработки), JavaScript (для фронтенда).

Плюсы:

• Простота: сложные задачи решаются в пару строк. Так, в JS async/await упрощает API-запросы.
• Быстрая разработка: динамическая типизация позволяет быстро писать и тестировать код без необходимости его компиляции.
• Богатые экосистемы: есть библиотеки для всего (к примеру, NumPy для данных в Python).
• Гибкость: легко менять код, идеально для прототипов или стартапов.

Минусы:

• Низкая производительность: абстракции добавляют нагрузки. Например, циклы в Python медленнее, чем в C.
• Ошибки на рантайме: из-за слабой типизации ошибки выявляются только при запуске программы, что усложняет отладку.
• Риск «спагетти-кода»: лёгкость изменений может привести к хаосу без дисциплины.
• Скрытые проблемы: абстракции маскируют баги.
• Зависимость от интерпретатора: программы требуют установленного интерпретатора, что замедляет их запуск и добавляет зависимость от дополнительного ПО.

Чек-лист: как выбрать язык программирования для новичка

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

1. Определите, что вас вдохновляет, и выберите сферу. Подумайте, что вы хотите создавать: сайты, игры, мобильные приложения или серверы. Разные сферы требуют разных языков. Например, для веб-разработки подойдут JavaScript или Python, для мобильных приложений — Java, Kotlin, Swift или Dart, а для игр — C# или C++. Составьте список идей (например, сайт-визитка, игра, аналитика данных) и найдите, какие языки для них используют.
   — Аня Жаркова, руководитель мобильной разработки в USETECH
2. Ищите язык с широким применением. Выбирайте языки, которые используются в разных областях, чтобы легче переключаться между задачами. Например, Kotlin подходит для мобильной разработки, веба и серверов, а C# — для десктоп-приложений, игр (Unity) и бэкенда. Это даёт гибкость и упрощает изучение новых языков в будущем.
   — Аня Жаркова, руководитель мобильной разработки в USETECH
3. Проверьте спрос на рынке труда. Если цель — смена профессии, изучите вакансии на HH.ru или LinkedIn. Введите «junior Python», «junior Java» и сравните, где больше предложений и какие требования. Избегайте языков с низким спросом, если хотите быстро найти работу. Например, Java, Kotlin, Python и JavaScript популярны для найма.
   — Владислав Масунов, Head of Development
4. Опробуйте языки на практике. Напишите простые программы (например, "Hello World" или калькулятор) на нескольких языках, чтобы понять, какой синтаксис вам ближе. Используйте онлайн-редакторы вроде Replit или CodePen. Например, попробуйте TypeScript для веба (он поддерживает типизацию и разные подходы к программированию) или C++ для понимания работы с памятью. Это поможет почувствовать, к чему лежит душа.
   — Рома Троицкий, фронтенд-инженер в Сбер B2C, член ПК HolyJS & MoscowCSS; Евгений Антонов, ИТ-консультант, автор тг-канала @general_it_talks
5. Выберите язык с хорошей документацией и сообществом. Убедитесь, что у языка много обучающих материалов и активное сообщество. Например, TypeScript имеет богатую документацию и поддержку, что упрощает старт. Проверьте ресурсы вроде LearnPython.org, freeCodeCamp для JavaScript или Telegram-чаты для C++. Это поможет быстрее решать вопросы.
   — Рома Троицкий, фронтенд-инженер в Сбер B2C, член ПК HolyJS & MoscowCSS
6. Учитывайте сложность и карьерные цели. Для небольших проектов или быстрого старта берите Python или PHP — они проще и подходят для веб-разработки или скриптов. Для сложных задач с высокой нагрузкой (например, серверы или оптимизация) попробуйте C++ или Go. Если цель — работа в крупных компаниях, Java и Kotlin востребованы и часто используются с ИИ-инструментами. Выбирайте, исходя из сложности и ваших амбиций.
   — Евгений Антонов, ИТ-консультант, автор тг-канала @general_it_talks
7. Смотрите на универсальность и переход к другим языкам. Выбирайте язык, который учит основам программирования и упрощает переход к другим. Например, изучение C# может помочь освоить Java, а затем — Android-разработку. TypeScript учит объектно-ориентированному и функциональному программированию, что полезно для разных задач. Это создаёт базу для дальнейшего роста.
   — Аня Жаркова, руководитель мобильной разработки в USETECH; Рома Троицкий, фронтенд-инженер в Сбер B2C, член ПК HolyJS & MoscowCSS
8. Не гонитесь за гилти плежа. Избегайте языков, которые изучают «для удовольствия» без практического применения. Выбирайте те, которые можно применить в реальных проектах или которые востребованы в индустрии. Например, вместо нишевых языков берите Python, Java или Kotlin: они имеют чёткие сценарии использования.
   — Аня Жаркова, руководитель мобильной разработки в USETECH
9. Практикуйтесь с ИИ-инструментами. Если хотите работать в крупных компаниях, освойте язык, который хорошо сочетается с ИИ-инструментами (например, Go или Java). Практикуйтесь с ИИ-агентами по типу GitHub Copilot для автоматизации задач — это ценится работодателями.
   — Евгений Антонов, ИТ-консультант, автор тг-канала @general_it_talks
10. Составьте план развития. Создайте roadmap: определите, какие проекты хотите делать через 3-6 месяцев (например, мобильное приложение или веб-сервис), и подберите язык под эти цели. Если выбрали C#, начните с десктоп-приложений, затем попробуйте Xamarin для кроссплатформенной разработки. Постепенно добавляйте новые языки, опираясь на первый.
    — Аня Жаркова, руководитель мобильной разработки в USETECH

Если не определились, предлагаем пройти квиз и расставить всё по полочкам:

Об этом рассказал Логан Килпатрик, продакт-лид Google AI Studio, в посте на X.

Что такое вайб-кодинг

Термин vibe coding (от англ. vibe — «ощущение», «настроение») появился в 2024 году и описывает подход к программированию, где разработчик не пишет код вручную, а общается с ИИ в свободной форме, задавая лишь общие направления: «сделай RPG про кота-самурая», «добавь погодные эффекты», «пусть враги становятся умнее».

Пока этот подход работал только с простыми проектами вроде сайтов и мобильных приложений, но Google обещает вывести его на новый уровень.

Что умеет новый AI Studio

По словам компании, обновленный Google AI Studio «понимает задачу и автоматически подбирает нужные модели, API и инструменты».

Например, если пользователь захочет сделать приложение, генерирующее изображения по промтам, AI Studio сам подключит соответствующий API (в данном случае — Nano Banana API) и настроит всю инфраструктуру.

«Мы сделали процесс создания мощных, функциональных и ИИ-дополненных приложений максимально простым», — говорится в блоге Google.

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

Теперь и для игр

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

«Это откроет путь для новых 100 млн разработчиков. Многие мечтают сделать игру, но спотыкаются о C++, C# и Unreal Engine. Теперь они смогут создавать истории, персонажей и геймплей — без единой строчки кода», — написал он.

Разумеется, до уровня Civilization или Baldur’s Gate дело не дойдет. По словам Килпатрика, речь идет о «небольших проектах для друзей», где игроки сами управляют сюжетом и механикой.

Скепсис и ожидания

Пока даже самые продвинутые ИИ-инструменты едва справляются с генерацией простых 2D-игр вроде Wordle или Flappy Bird.

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

Тем не менее, Google, по слухам, готовит к релизу Gemini 3.0, который может радикально улучшить креативные и кодогенерационные возможности.

Если планы компании сбудутся, то к концу года видеоигра мечты может начаться не с кода, а с фразы:

«Сделай мне космический шутер, где коты сражаются против пылесосов».

Целью Маниша было разработать инструмент для создания визуально привлекательных интерфейсов, который был бы прост в использовании. Он считал, что популярные библиотеки по типу Tkinter, требуют большого объема кода и часто дают неудовлетворительные результаты. Его решение позволяет применять любые графические элементы в качестве объектов интерфейса, открывая широкие возможности для дизайна. Особое внимание уделено поддержке нестандартных элементов управления — кнопки и слайдеры необычной формы, что недоступно во многих других инструментах.

Библиотека работает с многослойными изображениями, позволяя создавать интерактивные интерфейсы с минимальным количеством кода для настройки их параметров и поведения. При этом нет привязки к конкретному редактору — например, в некоторых демонстрациях используется MS Paint вместо GIMP. Видео доступны на GitHub для всех желающих протестировать библиотеку. Публикуем одно из них:

Также можно узнать и о других инструментах для разработки GUI, например, о библиотеке для встраиваемых систем. Подробности и демонстрацию работы можно посмотреть здесь.

Автор написал клон классической аркады Space Invaders на C++, опираясь всего на пару зависимостей. В этой части мы подготовим окно и контекст OpenGL 3.3, используя GLFW и GLEW — это единственные внешние библиотеки, которые понадобятся на старте.

Что такое Space Invaders

Space Invaders — аркадная игра 1978 года. Это 2D-шутер с горизонтальным управлением: игрок двигает пушку вдоль нижней границы экрана и стреляет по строю инопланетян. За каждого сбитого врага начисляются очки. Периодически по верхней части экрана пролетает НЛО — если сбить, получите бонусные очки. По мере уничтожения инопланетян игра ускоряется. Враги тоже стреляют случайно, приближаясь к низу экрана; попадание по игроку отнимает жизнь. Пушку частично прикрывают бункеры, но они постепенно разрушаются как под выстрелами врагов, так и самим игроком. После зачистки волны появляется новая, а бункеры восстанавливаются. Игра заканчивается, если бункеры полностью разрушены, инопланетяне достигли низа экрана или у игрока закончились жизни.

Постановка целей

Важно определить цели до начала проекта. Мы не собираемся дотошно воссоздавать оригинал — сделаем «space-invaders-like» прототип с базовыми элементами. В геймдеве обычно сначала собирают «грубый» прототип, чтобы проверить ядро механик, а «полировать» будем позже.

В прототипе нужны:

• управляемая игроком пушка;
• волны инопланетян, которые постепенно движутся к пушке;
• стрельба у обеих сторон.

НЛО и бункеры на первом этапе опустим (их несложно добавить потом).

Почти любую игру можно разложить на базовые элементы (очень советую доклад Raph Koster). В Space Invaders это движение и стрельба (а значит — детекция столкновений). Даже простой клон поможет прокачать понимание геймлупа, коллизий и правил игры.

Поехали!

Hello Window

Окно можно создать по-разному: нативные API (Cocoa/X11/WinAPI) или кроссплатформенные библиотеки (Qt, GLFW). Нативный путь даёт полный контроль, но ради простоты и кроссплатформенности возьмём GLFW: лёгкая, простая C-API.

Подключим заголовки (стандартный ввод/вывод и GLFW):

Это откроет окно 640×480 с заголовком Space Invaders и контекстом OpenGL. Два последних параметра glfwCreateWindow — монитор для фуллскрина и «шаринг» контекста между окнами. При неудаче вызываем glfwTerminate(). Важно: нужно «привязать» контекст текущему потоку (glfwMakeContextCurrent), чтобы последующие вызовы OpenGL применялись к нему.

По умолчанию версия контекста не гарантируется — попросим минимум 3.3 Core (задать до создания окна):

Почему нужен загрузчик функций OpenGL. OpenGL — это спецификация; реализация зависит от GPU/драйвера/ОС. Множество функций нужно загружать в рантайме. Делать это вручную неудобно, поэтому используют лоадеры. Здесь — GLEW (можно и GLAD, но в статье выбран GLEW).

Важно: подключаем GLEW до glfw3.h:

Игровой цикл (Game loop)

Если запустить код сейчас, окно мигнёт и программа завершится. Нужен бесконечный game loop, где мы обрабатываем ввод, обновляем состояние и рисуем кадр:

• Буферы. Современный OpenGL рисует в «задний» буфер, а «передний» отображается на экране. glfwSwapBuffers() меняет их местами.
• События. glfwPollEvents() вынимает накопившиеся события (клавиатура, мышь, закрытие окна).
• Выход. glfwWindowShouldClose() станет true, если пользователь нажал «крестик».

В конце корректно освобождаем ресурсы:

Компиляция

Ниже — команды из оригинала (C++11), плюс современные примечания.

Обратите внимание, что позже мы будем использовать некоторые функции C++11, поэтому компилируем с помощью -std=c++11. В обоих случаях убедитесь, что у вас установлен GLFW 3. В Linux, в зависимости от вашего дистрибутива, вы можете использовать менеджер пакетов. Например, в Ubuntu GLFW можно установить с помощью следующей команды:

На Mac OS X автор предпочитает использовать Homebrew:

Возможно, эта статья поможет вам настроить проект GLFW в Visual Studio.

Если всё собрано успешно, вы увидите красное окно с заголовком Space Invaders.

Итоги

Даже просто «поднять окно» с контекстом OpenGL на C++ — задача не из быстрых, несмотря на помощь GLFW. Мы пока ничего не рисуем; настройка простейшего рендера в современном OpenGL тоже требует подготовки. Хорошая новость — делать это придётся один раз, а дальше вы переиспользуете базу в следующих частях (шейдеры, VBO/VAO, спрайты, коллизии и т. д.).

Вторая часть статьи — здесь

• Тестовая среда: используйте последний стабильный релиз (например, 3.5.6; см. страницу Tags на GitHub).
• Staging (предпроизводственная) и Production (производственная) среды: используйте последний минорный релиз предыдущей стабильной ветки.
• Если требуется новый функционал или критическая фиксация, можно собрать из актуального кода ветки main, используя официальный Docker-образ сборочного окружения.
• Компонент BE (Backend) требует CPU с поддержкой AVX2. Возможна сборка без AVX2 (работоспособно, но не рекомендуется — нет полноценного покрытия тестами).
• Начиная с 1.19 StarRocks поддерживает ARM, но потребует самостоятельной сборки на ARM-хосте (официальные готовые бинарники под ARM пока не публикуются).

Справочные ссылки:

• Страница Tags (например, 3.5.6, 4.0.0-rc01): https://github.com/StarRocks/starrocks/tags
• Release Notes 1.19 (сообщество): https://forum.mirrorship.cn/t/topic/552

Ниже — пример сборки из актуального кода ветки main с использованием официального Docker-образа.

1. Установка Docker и загрузка сборочного образа

Для примера используется CentOS 7.6 в виртуальной машине (рекомендуется ≥2 vCPU и ≥4 ГБ RAM). Во время сборки требуется стабильное сетевое подключение.

1.1 Установка Docker

1.2 Запуск Docker и автозапуск

1.3 Проверка установки

При успешном выполнении отобразится сообщение “Hello from Docker!”.

1.4 Ускорение загрузки образов (для нестабильных каналов)

Если загрузка официальных образов Docker медленная/нестабильная, можно использовать сервисы Alibaba Cloud Container Registry (ACR). Важно: официальный ACR image accelerator больше не синхронизирует последние образы. Если образ не скачивается или тег latest не содержит актуальную версию, воспользуйтесь альтернативами:

• Подписка в ACR на зарубежные исходные образы (subscription of overseas source images).
• Использование GA (Global Accelerator) для ускорения прямого доступа к зарубежным реестрам.

Рекомендация для Production: минимизируйте зависимость от Docker Hub из‑за сетевых рисков.

Если вы используете containerd:

• Убедитесь, что в /etc/containerd/config.toml задан config_path, например: [plugins."io.containerd.grpc.v1.cri".registry] config_path = "/etc/containerd/certs.d"
• Уберите конфликтующие mirrors (если есть), перезапустите containerd: sudo systemctl restart containerd
• При ошибке старта изучите вывод: journalctl -u containerd
• Создайте файл /etc/containerd/certs.d/docker.io/hosts.toml: server = "https://registry-1.docker.io" [host."https://<your-ACR-accelerator-address>"] capabilities = ["pull", "resolve", "push"]

1.5 Загрузка сборочного образа StarRocks

Выбирайте тег образа в соответствии с веткой/версией исходников (для ветки main — тег main; для ветки 3.5 — тег 3.5 и т. п.):

1.6 Просмотр локальных образов

2. Получение исходников StarRocks

2.1 Клонирование из GitHub или скачивание архива

Стандартно:

Если из‑за сетевых ограничений возникают ошибки (например, EOF), можно:

• использовать зеркало GitHub (пример): git clone https://github.com.cnpmjs.org/StarRocks/starrocks.git
• либо скачать архив кода из браузера: https://github.com/StarRocks/starrocks
• архив конкретного релиза: https://github.com/StarRocks/starrocks/tags

Чтобы ускорить клонирование, добавьте --depth 1 (если не требуется полная история).

2.2 Загрузка архива на сервер и распаковка (вариант с ZIP)

2.3 Запуск контейнера со сборочным окружением и монтированием кэшей

Рекомендуется смонтировать локальный Maven-кэш (~/.m2) для ускорения повторных сборок.

(Опционально — подключите ccache, смонтировав ~/.ccache, если это поддерживается образом.)

2.4 Проверка запущенных контейнеров

2.5 Вход в контейнер

2.6 Переход в каталог исходников

2.7 Сборка FE и BE

Скрипт скачает зависимости и выполнит сборку (может занять значительное время). Благодаря монтированию ~/.m2 зависимости будут переиспользованы в следующих сборках.

Результаты сборки — в каталоге output/:

Сборка без AVX2 (только при необходимости; не рекомендуется)

Измените build.sh, чтобы принудительно отключить AVX2:

Измените сборку сторонней библиотеки в thirdparty/build-thirdparty.sh (блок croaring):

Повторно выполните ./build.sh. Учтите: такой вариант не имеет полноценного покрытия тестами.

Полезные опции build.sh

2.8 Сборка Broker

Broker не собирается шагом выше — его нужно собирать отдельно:

Готовые файлы появятся в

.

2.9 Выход и повторный запуск контейнера при необходимости

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

Примечания и рекомендации

• FE (Frontend) и BE (Backend) — основные компоненты StarRocks, сборка которых выполняется скриптом build.sh.
• Для воспроизводимости привязывайте тег сборочного Docker-образа к ветке/версии исходников (например, starrocks/dev-env:3.5 для ветки 3.5.x).
• Для ускорения повторных сборок используйте кэш Maven (~/.m2) и, при возможности, ccache для C++.
• ARM: официальный сборочный Docker-образ пока не рассчитан на ARM. Для ARM-сборки потребуется нативный ARM-хост и корректные версии зависимостей (JDK, CMake и др.).
• Список актуальных релизов и тегов: https://github.com/StarRocks/starrocks/tags
• Release Notes 1.19 (сообщество): https://forum.mirrorship.cn/t/topic/552

После этих шагов у вас будут собранные бинарные артефакты FE/BE и Broker, готовые к дальнейшему развертыванию кластера StarRocks.

Эти пакеты используются в миллионах проектов по всему миру — общее количество загрузок только за неделю превышает 2 млрд.

Как работал вредоносный код

Внедренный JavaScript-код маскировался внутри библиотек и выполнялся исключительно в браузерной среде. Основная цель — перехват криптовалютных транзакций через подмену данных:

• внедрение в методы fetch, XMLHttpRequest, а также Web3-объекты (window.ethereum и др.);
• отслеживание и подмена адресов кошельков при вызовах вроде sendTransaction, approve, transfer;
• использование «похожих» адресов для подмены без визуального отличия;
• манипуляции с параметрами транзакций на этапе подписи;
• сохранение внешней «нормальности» интерфейса, чтобы пользователь ничего не заметил.

Таким образом, атака была нацелена на незаметное хищение криптоактивов прямо из интерфейсов Web3-приложений.

Как злоумышленники получили доступ

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

Он получил письмо с поддельного адреса support@npmjs.help, зарегистрированного 5 сентября 2025 года. После компрометации аккаунта были опубликованы вредоносные версии пакетов.

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

Список затронутых пакетов

Наиболее популярные зараженные библиотеки:

• chalk
• debug
• supports-color
• strip-ansi
• ansi-regex
• wrap-ansi
• color-name
• color-convert
• color-string
• chalk-template
• has-flag
• has-ansi
• slice-ansi
• error-ex
• simple-swizzle
• backslash
• и другие

Большинство из них используются транзитивно — через другие зависимости.

Что делать разработчикам

1. Проверить package-lock.json или yarn.lock на наличие зараженных версий.
2. Использовать npm audit, snyk, Safe Chain или аналогичные инструменты для анализа зависимостей.
3. Обновить или зафиксировать безопасные версии пакетов.
4. Если проект работает с криптовалютой, проверить, не было ли компрометации в процессе использования.

Почему это важно

Эта атака стала одной из крупнейших в истории JavaScript-экосистемы и подчеркивает уязвимость цепочек поставки (supply chain) в open-source.

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

Последний рубеж React и Vue

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

SSR ускоряет загрузку страницы: сервер рендерит HTML, пользователь видит контент и пытается с ним взаимодействовать. Но пока JavaScript не загрузится, ничего не заработает.

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

Системные проблемы не исправить очередным хуком или новой версией фреймворка, поэтому появление SolidJS и Qwik — было вопросом времени.

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

Обзор SolidJS

SolidJS во многом похож на React. Самое интересное — его подход к обновлению интерфейса:

• Отсутствие виртуального DOM — Solid напрямую обновляет только те DOM-узлы, которые действительно изменились.
• Компоненты как функции инициализации — каждый компонент вызывается только один раз для настройки реактивности.
• Сигналы вместо хуков — состояние управляется через createSignal(), который возвращает геттер/сеттер пару.

Например, когда срабатывает счётчик, Solid не перерисовывает весь компонент. Он точечно обновляет только текст внутри <p>, где используется count():

Преимущества SolidJS

👍 Производительность и размер бандла

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

👍 Простота освоения

Синтаксис SolidJS похож на React. Функциональные компоненты, JSX, концепции вроде Suspense и Error Boundaries — всё это есть в Solid. Изучение основ займёт 1-2 дня, если есть опыт с MobX/effector/RxJS.

👍 Стабильность

Фреймворк находится на стабильной версии 1.x. Это означает отсутствие кардинальных изменений API, в отличие, например, от ситуации со Svelte, где сосуществуют версии 4 и 5 с разными подходами.

👍 Совместимость с React

SolidJS совместим с экосистемой React. Можно переиспользовать дизайн-системы и компоненты в legacy-приложениях.

👍 Удобное управление состоянием

Функционал сигналов и сторов покрывают 90% потребностей в управлении состоянием без необходимости подключать внешние библиотеки.

Минусы SolidJS

👎 Ограниченная экосистема

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

👎 Кривая обучения

Несмотря на знакомый синтаксис, модель реактивности SolidJS отличается от React. Разработчики должны усвоить следующие принципы:

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

👎 Проблемы с инструментарием

Возникают сложности с настройкой компилятора в нестандартных окружениях — монорепозиториях, при запуске тестов или интеграции с другими инструментами. DevTools не дотягивает до аналога у React.

👎 SolidStart всё ещё развивается

SSR-решение SolidStart пока не достигло зрелости Next.js или Nuxt. Разработчики сообщают о проблемах с гидратацией и других сложностях при работе с серверным рендерингом.

Обзор Qwik

Qwik — это проект Мишко Хевери (создателя Angular). Идея фреймворка заключается в возможности возобновить работу приложения на клиенте без повторного выполнения кода, который уже был выполнен на сервере.

В Qwik радикально решили проблему гидратации — полностью отказались от неё. Время до интерактивности (TTI) падает в разы. Пользователь может кликать на кнопки сразу после загрузки HTML, без ожидания разогрева всего приложения.

Qwik автоматически разбивает код на мелкие чанки и загружает их только при необходимости. Символ $ в коде указывает на границы ленивой загрузки.

Плюсы Qwik

👍 Мгновенная загрузка

Практически нулевой JavaScript при первоначальной загрузке, следовательно отличные показатели Core Web Vitals.

👍 Автоматическая оптимизация

Оптимизация на уровне компилятора, умная предзагрузка критических ресурсов. Не нужно думать о разделении кода — Qwik делает это автоматически.

👍 Знакомый синтаксис

👍 Спасибо за SEO

Быстрая загрузка улучшает ранжирование за счёт полноценного SSR из коробки.

Минусы Qwik

👎 Молодая экосистема

Ограниченное количество библиотек, мало готовых решений и компонентов. Небольшое сообщество разработчиков (если сравнивать с React/Vue).

👎 Кривая обучения

Придётся изучать новые концепции. Из-за ленивой загрузки усложняется отладка.

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

👎 Сложность интеграции

Трудно интегрировать существующие React/Vue компоненты и ограниченная поддержка сторонних библиотек. Скорее всего, придётся с нуля переписывать код существующего проекта.

Экосистема и готовность к продакшену

Если сравнивать с React, то экосистема — самое слабое место обоих фреймворков.

SolidJS имеет SolidStart — метафреймворк с роутингом, SSR и серверными функциями. Документация качественная, сообщество активное. Большинство React-библиотек можно адаптировать без особых проблем, для популярных UI-китов есть готовые порты.

Qwik развивается в связке с Qwik City, который покрывает типовые задачи веб-разработки. Builder.io активно инвестирует в экосистему, регулярно выходят обновления и новые интеграции.

Риски есть, но они управляемые. Меньший размер сообщества означает меньше готовых решений и ответов на Stack Overflow. Если не боитесь изучать новое, то выигрыш в производительности перевесит неудобства.

Сравнение SolidJS и Qwik

SolidJS повышает производительность обновлений. Если данные меняются часто и непредсказуемо — графики, мониторинги, редакторы — Solid даст максимальную отзывчивость.

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

Медиа, блоги с жёсткими требованиями к TTFB/TTI/INP будут лучше работать на Qwik. Пользователи смогут читать и скроллить без задержки. Интерактив добавляется дозированно — это лучшая стартовая стоимость.

E-commerce, каталоги с SEO и карточками рекомендуется разрабатывать на Qwik. Особенно если на главной тяжёлые модули, а клиенты приходят с поисковиков. Вы выигрываете у конкурентов буквально на первом взаимодействии.

Сложный SPA или дашборд с живыми виджетами и апдейтами будет лучше работать на SolidJS. Точечная реактивность упростит жизнь и снизит цену апдейтов. Solid сияет в проектах, где происходят сотни мелких изменений в секунду.

Solid хорош для аналогов десктопных приложений в браузере — Figma, Miro. Здесь приложение загружается один раз, а потом работает долго и должно быть максимально отзывчивым. Также Solid будет хорош там, где важна плавность анимаций.

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

Оба фреймворка умеют SSR/SSG и стриминг. Solid снижает стоимость обновлений, Qwik — стоимость старта. Для LCP/TTI/INP в контентных сценариях выигрывает Qwik. Для интенсивных интерактивных сценариев Solid удерживает FPS и снижает CPU.

Оба дружат с серверными платформами. SolidStart имеет адаптеры для Vercel/Netlify, Qwik City — тоже.

Выбирайте Solid.js, если вы создаете сервис, куда пользователь заходит надолго, и ему важна отзывчивость после загрузки. Выбирайте Qwik, если вы создаете сайт, куда пользователь приходит за контентом, и важно показать ему этот контент мгновенно.

Немного выводов:

• Solidjs быстрее Qwik при рендеринге. Qwik быстрее Solidjs при загрузке страниц.
• У Solidjs документация лучше, чем у Qwik.
• С нуля код на Qwik писать проще и быстрее, чем на SolidJS.
• Typescript в SolidJS может быть головной болью, в Qwik об этом можно не беспокоиться.

Практические рекомендации по переходу на SolidJS и Qwik

1. Начните с аудита текущих проблем. Посмотрите метрики сайта: сколько времени занимает гидратация? Тормозят ли обновления интерфейса? Где именно проблема — на старте или в процессе работы?
2. Выберите изолированную часть проекта. Возьмите один виджет, одну страницу, один компонент и реализуйте его на новом фреймворке. Измерьте разницу в производительности и удобстве разработки.
3. Если проблема в медленной загрузке — попробуйте Qwik. Соберите прототип лендинга или каталога, включите SSG с resumability и протестируйте на медленном соединении.
4. Если проблема в тормозах интерфейса — попробуйте Solid. Перепишите самый страдальный компонент с частыми обновлениями, уберите мемоизации и посмотрите на результат.

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

Тенденция отказа от React/Vue

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

А вы что думаете? Готовы попробовать модные фреймворки SolidJS и Qwik в следующем проекте?

Так, проведя диагностику, Фройнд обнаружил скрытый вредоносный код в библиотеке xz — она используется практически во всех дистрибутивах Linux и задействуется при работе с SSH.

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

Под ударом оказались Fedora, Debian, openSUSE, Arch и готовящийся релиз Ubuntu 24.04. Его внедрение произошло в xz версий 5.6.0 и 5.6.1 в феврале и марте 2024 года. Если бы Фройнд не заметил задержку — миллионы серверов оказались бы взломаны.

Атака на человека, не на код

Самое страшное, что атака эта длилась три года и была направлена не на уязвимость в коде. Она целилась на уязвимость в человеке — Лассе Коллине. Это доброволец, который в одиночку поддерживал xz с 2005 года.

Под именем Jia Tan злоумышленники создали фейкового разработчика, который годами отправлял мелкие патчи, завоёвывал доверие и постепенно получал доступы.

Параллельно фальшивые аккаунты вроде Jigar Kumar и Dennis Ens психологически давили на Коллина — критиковали его за медленные релизы, упрекали за проблемы с ментальным здоровьем и требовали передать проект «более активным» участникам.

В итоге выгоревший Коллин отдал проект в руки атакующих. К 2024 году у Jia Tan был полный контроль: доступ к репозиторию, релизам и даже сайту проекта. Остальное — дело техники.

«Синдром Небраски»: когда критическую инфраструктуру тащит один человек

История с xz — не исключение, а симптом. Open-source в целом как явление держится на людях, которые годами бесплатно поддерживают критически важные библиотеки. Например:

• OpenSSL (Heartbleed) — один разработчик и $2000 бюджета в год;
• Express.js — десятки миллионов скачиваний, один мейнтейнер;
• curl — десятилетия работы Даниэля Стенберга;
• Log4j — критическая уязвимость в библиотеке, которую поддерживал один человек.

Вот и атака на xz не совсем история про лобовой эксплойт. Это скорее история про системную усталость. Уязвимость была в доверии и выгорании.

Мы живем на доброй воле и это проблема

Вообще, произошедшее сложно назвать «сбоем open-source». Это сбой модели поддержки подобного софта. Проекты, от которых зависят миллиарды людей, поддерживаются на энтузиазме одного или двух человек. И мы никак это не компенсируем.

Виноваты не разработчики, а система, где:

• корпорации получают триллионы на бесплатном ПО;
• мало кто инвестирует в его поддержку;
• кризис выгорания решается атаками на выгоревших.

Что с этим делать?

Некоторые страны и компании уже делают шаги:

• Германия выделила €23 млн на поддержку OSS;
• ЕС обсуждает фонд в €350 млн;
• GitHub и Tidelift пытаются создать модели устойчивого финансирования.

Но пока это капля в море. Тысячи проектов критичны, а финансируются десятки. И сколько еще таких историй, как атака на xz, нас ждет — покажет лишь время...

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

Почему владение Django — не предел для разработчика

Особенности Django

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

Основные плюсы:

• Полноценный стек: ORM для работы с базой, мощная система маршрутизации URL, шаблоны для рендеринга, встроенная админка, формы, система аутентификации и авторизации.
• Архитектура MTV (Model-Template-View): похожа на классический MVC, но с особенностями, которые упрощают разделение логики, представления и данных.
• Безопасность: Django автоматически защищает от CSRF, XSS, SQL-инъекций и других распространенных атак. Не нужно писать много дополнительного кода.
• Активное сообщество и экосистема: тысячи сторонних пакетов, расширений и готовых решений.
• Поддержка нескольких баз данных: PostgreSQL, MySQL, SQLite, Oracle и др.

Ограничения:

• Синхронная природа Django.
• Монолитность: архитектура фреймворка ориентирована на создание крупных приложений, но в микросервисах может быть избыточна.
• Ограниченная гибкость ORM: нестандартные SQL-запросы иногда сложно выразить средствами ORM, приходится использовать raw SQL или сторонние библиотеки для запросов.
• Строгие правила организации кода: требуют дисциплины и могут ограничивать свободу в архитектурных решениях.
• Недостаточная производительность: уступает лёгким асинхронным фреймворкам (например, FastAPI), особенно под высокими нагрузками. Но для большинства проектов пока это не критично.

В каком направлении двигаться после изучения Django

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

Первое направление для развития — расширить инструментарий для решения разных задач в веб-разработке

Возможные пути:

• Изучить другие веб-фреймворки (Flask, FastAPI)
• Углубиться в асинхронное программирование (asyncio, aiohttp)
• Работать с API и микросервисами

Flask и FastAPI

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

FastAPI — современный асинхронный фреймворк, ориентирован на создание высокопроизводительных API. Поддерживает стандарт OpenAPI и автоматическую генерацию документации. Он быстрее Flask и Django благодаря asyncio и Pydantic.

Асинхронное программирование

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

Поэтому изучение asyncio — стандартной библиотеки Python для асинхронного программирования — откроет перед вами новые возможности. Вместе с aiohttp или тем же FastAPI вы сможете создавать приложения, которые обрабатывают тысячи одновременных соединений. Это особенно важно для real-time сервисов, чат-приложений и систем с интенсивным обменом данными.

Второе направление — расширить навыки в смежных областях

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

Изучение DevOps и контейнеризации

Контейнеры позволяют запускать приложения в изолированной среде, это упрощает настройку и развертывание. Например, Docker помогает упаковать приложение с зависимостями в один контейнер, а Kubernetes — управлять такими контейнерами в продакшене. Знание этих технологий улучшит взаимодействие с операционной командой и ускорит выпуск новых версий приложений.

CI/CD и автоматизация процессов

Непрерывная интеграция (Continuous Integration) и непрерывное развертывание (Continuous Deployment) — ключевые практики современной разработки ПО. Они позволяют автоматизировать сборку, тестирование и доставку приложений, масштабировать процессы.

Инструменты CI/CD (например, Jenkins, GitLab CI/CD, GitHub Actions) помогают настроить автоматические пайплайны, которые обеспечивают быструю обратную связь и минимизируют человеческий фактор в релизах. Автоматизация процессов снижает количество ошибок и позволяет сосредоточиться на разработке новых функций.

Настройка непрерывной интеграции и доставки (Continuous Integration / Continuous Delivery) снижает поток ошибок при релизах и экономит время. Пример: GitHub Actions для автоматического запуска тестов и сборки проекта при каждом коммите.

Больше знаний в области баз данных

Помимо классических реляционных баз данных (PostgreSQL, MySQL), современные приложения часто используют NoSQL для специфичных задач. MongoDB, Redis, Cassandra обеспечивают гибкость в хранении данных, горизонтальное масштабирование и высокую производительность при работе с большими объемами информации.

Графовые базы данных (Neo4j, ArangoDB) предназначены для эффективного хранения и анализа связей между объектами, что важно для социальных сетей, рекомендательных систем и других приложений с богатой структурой.

Так, Redis хорошо подходит для кэширования данных, а Neo4j — для сложных связей между объектами.

Третье направление — переход к другим аспектам Python-разработки

Рассмотрим четыре варианта карьерного развития для Python-программиста: Data Science и машинное обучение, автоматизация бизнес-процессов, разработка десктопных приложений и встраиваемые системы (IoT).

Почему стоит попробовать?

• Высокий спрос на специалистов. Они востребованы в банках и инвестиционных компаниях, в сфере медицины и биотехнологии, в консалтинге, автомобильной промышленности и т.д..
• Широкий набор библиотек: pandas, NumPy, scikit-learn, TensorFlow, PyTorch.
• Возможность работать с реальными задачами: от бизнеса до науки.

Автоматизация и скрипты для бизнеса

Python часто используется для автоматизации рутинных задач: парсинга данных, обработки файлов, интеграции систем, генерации отчетов. Создание скриптов для автоматизации бизнес-процессов помогает повысить эффективность работы и снизить количество ошибок.

Знание таких библиотек, как openpyxl (работа с Excel), requests (HTTP-запросы), BeautifulSoup и Scrapy (парсинг веб-страниц), а также умение писать скрипты под конкретные задачи, делают разработчика ценным специалистом в корпоративной среде.

Примеры задач:

• Автоматическая загрузка данных из Excel и их преобразование
• Скрипты для отправки email-рассылок
• Интеграция с CRM и другими сервисами через API

Разработка десктопных приложений (PyQt, Kivy)

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

Инструменты для создания:

• PyQt — мощный фреймворк для создания кроссплатформенных GUI.
• Kivy — библиотека для разработки приложений с поддержкой сенсорных экранов.

Этот путь подходит тем, кто хочет создавать удобные инструменты с графическим интерфейсом для пользователей на Windows, macOS или Linux.

Встраиваемые системы и IoT

В области IoT и встроенных систем Python набирает популярность благодаря легкости освоения и поддержке на маломощных устройствах. Помогают в этом платформы по типу Raspberry Pi и MicroPython.

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

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

Если рассматривать профессию “Python-разработчик на Django”, то сразу получится сужение до конкретной библиотеки на конкретном языке. Если же в резюме у специалиста стоит, что он “разработчик Python”, возможностей сильно больше. Если написать про себя “разработчик”, будет не понятно, разработчик чего. Но изменив резюме на “DevOps инженера”, становится понятен карьерный трек.

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

По словам автора, он почти наверняка знает, что такие фрагменты были сгенерированы с помощью больших языковых моделей (LLM), вроде ChatGPT или GitHub Copilot.

И проблема не в том, что код плохой. Проблема в том, что он — чужой. Его будто писали не члены команды, а кто-то извне, не знающий, как у них принято.

LLM игнорируют контекст проекта

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

Везде используется функциональный подход — а LLM сгенерировал класс. Уже есть модуль с нужными утилитами — но модель пишет их заново. Такие случаи множатся.

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

ИИ — мощный инструмент, но он не заменяет инженера

Автор подчеркивает: ему все равно, как код попал в IDE — был он написан вручную, скопирован с форума или сгенерирован ИИ. Важно то, что попадает в кодовую базу.

И если ты пользуешься LLM, то будь инженером, а не оператором. Ставь четкие задачи, указывай нужные библиотеки, приводи примеры, ограничивай объем кода.

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

Разработка — это про долгосрочность

По словам автора, софт должен быть не просто рабочим, а поддерживаемым годами.

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

Цифровой контент — актив, который требует защиты не меньше, чем банковские данные. Многие привыкли, что свежий сериал или долгожданный фильм оказывается в сети за неделю до премьеры или в день релиза, а дорогостоящий курс можно скачать бесплатно на «складчинах». В 2024 году пиратство нанесло российским правообладателям ущерб в 3,36 млрд рублей, а глобальные потери медиаиндустрии превысили $71 миллиард. Утечки контента происходят через уязвимости в системах доставки, запись экрана или взлом серверов.

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

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

Важно понимать, что защита должна учитывать не только копирование контента, но и целостность всей экосистемы — от API до клиентского плеера.

Многоуровневая защита: из чего она состоит

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

1. Защита от несанкционированного доступа и копирования

Первый барьер — ограниченный доступ к контенту:

• Шифрование: AES-128 или AES-256 для защиты видеопотоков.
• Авторизация: токены JWT или OAuth для проверки прав пользователей.
• Системы управления цифровыми правами (DRM) устанавливают ограничения на воспроизведение контента — по устройствам, географическому положению и времени. Если отсутствует соответствующий ключ шифрования, выдаваемый лицензионным сервером, воспроизведение может быть заблокировано.

2. Пиратские копии

Даже если контент уже украден, важно оперативно выявить его нелегальное распространение. Технологии AI-мониторинга и цифровой форензики сканируют даркнет, соцсети и пиратские сайты. ИИ распознает видео по фрагментам, даже если оно перекодировано.

Технический нюанс: ИИ-системы используют сверточные нейросети (CNN) для анализа визуальных и аудиохарактеристик. Разработчикам стоит интегрировать такие решения через API, например, от Google Cloud Vision или специализированных вендоров.

3. Отслеживание источника утечки

Ключевой вопрос при утечке: кто и как получил доступ к контенту? Водяные знаки и «цифровые отпечатки» (fingerprinting) позволяют встраивать уникальные идентификаторы в видеофайлы. Fingerprinting, например, создает хэши аудио- и видеофрагментов для поиска копий.

Технический нюанс: сессионные водяные знаки добавляют задержку в стриминг. Проблема решается предварительной обработкой сегментов для HLS/DASH-протоколов.

4. Противодействие пиратским ресурсам

Удалить копии после обнаружения можно через:

• Обращение в РКН и к платформе, где появилось видео. Если реакции от платформы нет, РКН или провайдер хостинга заблокируют сайт по запросу.
• Автоматическую блокировку ссылок через API хостингов.
• Юридическое давление на пиратские платформы.

Технологии против пиратов: DRM, ИИ, водяные знаки и «цифровые отпечатки»

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

DRM (управление цифровыми правами)

DRM-системы шифруют контент и управляют лицензиями на доступ к видеопотоку. DRM защищает контент на уровне клиента и сервера, предотвращая неавторизованный доступ и перехват. Такие системы интегрируются в плееры и платформы и показывают контент только авторизованным пользователям.

DRM-системы опираются на три ключевых компонента:

1. Лицензионный сервер отвечает за выдачу и проверку ключей расшифровки контента.
2. Клиентская часть DRM (Content Decryption Module, CDM) интегрирована в браузер/плеер.
3. Упаковщик контента (Packager) подготавливает видеопотоки для защищенной доставки.

Но есть техническая проблема совместимости — DRM-системы неоднородны по платформам:

• Widevine (Android, Chrome, Firefox, Opera);
• PlayReady (Windows, Xbox, некоторые Smart TV);
• FairPlay (экосистема Apple);
• WisePlay DRM (экосистема Huawei).

Решение — мульти-DRM упаковщики, поддерживающие все стандарты через единую интеграцию. Используйте библиотеки, например, Shaka Player, для упрощенной интеграции мульти-DRM.

Водяные знаки (Digital Watermarking)

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

Отслеживание «цифровых следов» (Fingerprinting)

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

Например, YouTube Content ID верифицирует права на материалы и затем в автоматическом режиме отслеживает загрузки на платформе. Когда пользователь загружает видео, Content ID сравнивает его с базой отпечатков, и, если обнаруживает совпадение с материалами, может заблокировать ролик за нарушение авторских прав, перенаправить доход от рекламы правообладателю или уведомить владельца контента.

Цифровая форензика

Цифровая форензика — это сбор и исследование данных для раскрытия цифровых преступлений. Проще говоря, цифровая криминалистика. Специалисты-форензики анализируют источники пиратских копий через анализ метаданных, характеристик кодирования, артефактов сжатия и других цифровых «улик», чтобы выявить, как и когда произошла утечка. Например, уникальные артефакты в H.264-кодеке могут указать на устройство, с которого записали экран.

AI-мониторинг

Искусственный интеллект ускоряет поиск пиратских копий через анализ огромных массивов данных в интернете с помощью компьютерного зрения и машинного обучения. ИИ-системы мониторинга используют сверточные нейросети (CNN), которые способны распознавать визуальные образы и алгоритмы, такие как Mel-Frequency Cepstral Coefficients (MFCC) (используется для распознавания речи). С их помощью можно находить копии даже при перекодировании или обрезке.

Уже существует множество готовых решений на основе ИИ. Например, Red Points постоянно мониторит соцсети, видеоплатформы и пиратские сайты с применением машинного обучения, компьютерного зрения и распознавания изображений, а при обнаружении совпадений автоматически отправляет запросы на удаление через API. Piracymeter и Bytescare анализируют списки доменов, поисковые результаты Google и торрент-трекеров. Bytescare также может находить пиратские копии ПО.

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

Пример комплексного подхода к защите видео

Для защиты видеоконтента компании всё чаще используют решения, которые сочетают несколько технологий. Например, разработчик систем безопасности GS Labs совместно с видеохостингом Kinescope создал систему, интегрирующую DRM, водяные знаки и цифровую форензику. Она позволяет шифровать контент, встраивать уникальные идентификаторы для отслеживания утечек и анализировать источники пиратских копий. Такое решение работает как в облаке, что даёт стриминговым платформам масштабируемость, так и локально, что важно для компаний с собственной инфраструктурой.

Модели внедрения технологий защиты видеоконтента

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

Локальные решения (on-premises)

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

Облачные/SaaS-решения

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

Совет: используйте облачные решения с SOC 2 или ISO 27001 сертификацией для защиты данных.

Гибридные модели

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

Совет: используйте Kubernetes для оркестрации гибридных систем и минимизации downtime.

Что стоит сделать прямо сейчас, чтобы защитить видеоконтент

1. Подобрать постоянное комплексное решение: исследуйте вендоров и технологии на рынке.
2. Провести аудит инфраструктуры: проверьте уязвимости в CDN, API и плеере, например, с помощью OWASP ZAP.
3. Интегрировать DRM: выберите мульти-DRM решение, совместимое с Widevine, PlayReady и FairPlay.
4. Внедрить мониторинг: подключите ИИ через API для поиска копий.
5. Провести пентесты в BurpSuite, симулируя пиратские атаки и взлом.
6. Отработать реакцию на инциденты.

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

Мы в Smart Engines занимаемся разработкой интеллектуальных систем для распознавания документов. Мы уже рассказывали вам, как просто и быстро интегрировать наши решения для распознавания паспорта, а также распознавания жестких и гибких форм в Android.

Сегодня речь пойдет про браузерное распознавание. Оно в последние несколько лет пользуется колоссальным спросом со стороны рынка – прежде всего у финтеха. Кроме того, развертывание PWA-приложений понадобится компаниям при интеграции функциональности в новый отечественный мессенджер MAX.

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

Исторический экскурс

Технология WebAssembly (WASM) появилась в 2015 году и два года спустя была реализована во всех основных браузерах. Тогда же ученые Smart Engines начали проводить с WASM первые эксперименты.

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

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

Ответ нашелся быстро – WASM и Smart Engines.

В чем плюсы?

Браузерное распознавание имеет очень много преимуществ. Во-первых, это все преимущества веб приложения:

• Кроссплатформенность;
• Возможность доступа к приложению из любой точки с интернет-соединением
• Мгновенное развертывание и обновление приложения, что позволяет пользователям всегда работать с актуальной версией.

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

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

Все преимущества браузерного распознавания уже оценили наши партнёры, нацеленные на развитие своих интернет-сервисов. Среди них – Альфа-Банк, Газпромбанк и другие.

Распознавание кодифицированных объектов

Одним из самых востребованных направлений в OCR сейчас является распознавание кодифицированных объектов, таких как баркоды, номера телефонов, банковских карт и прочие машиночитаемые зоны.

В своё время мы выделили распознавание таких объектов в отдельный продукт Smart Code Engine для того, чтобы иметь возможность гибче работать с различными сценариями распознавания, а также иметь возможность пойти дальше в деле оптимизации скорости и размера библиотеки. В результате появился Smart Code Engine 2.0 – продукт получил новый интерфейс и возможность максимально гибко настраивать поведение для получения лучшего качества распознавания.

Библиотека Smart Code Engine написана на С++ и портировалась в веб с помощью инструмента Emscripten. Поскольку вся кодовая база, от низкоуровневых вычисления над изображениями до архитектуры поисковой сети, поддерживается нашим научным отделом, качественное портирование не составляло особых проблем.

Js-интерфейс библиотеки представляет собой практически зеркальный С++ интерфейс и с его помощью распознавание банковской карты реализуется вот так:

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

Передача изображений в библиотеку осуществляется прямо с чтения пикселей элемента canvas, где вы выводите изображения с камеры устройства или прикрепленного файла PDF.

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

Вот как это выглядит на выходе:

Как вы можете заметить, интеграция Smart Code Engine SDK не вызывает сложностей – внедрение происходит практически мгновенно, а скорость распознавания сопоставима с нативными библиотеками.

1. Pandas

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

Библиотека строится вокруг двух ключевых структур: Series (одномерный массив с индексами); DataFrame (таблица с индексами и колонками).

Какие задачи решает библиотека

Pandas полезна для следующих задач:

• Сам анализ данных: можно быстро фильтровать, группировать, агрегировать и строить сводные таблицы.
• Очистка данных: удаляем пустые строки, заменяем значения, приводим типы.
• Загрузка данных из CSV, Excel, SQL.
• Визуальная разведка данных (EDA) перед построением моделей.
• Подготовка данных для ML и отчётов.
• Автоматизация отчётов и ETL-пайплайнов.

Благодаря Pandas аналитик превращается в инженера данных, а ML-специалист может сосредоточиться на моделях, а не на ручной подготовке датасетов.

Как пользоваться

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

Почему это меняет карьеру

Работа с Pandas становится границей между знанием Python и умением решать задачи бизнеса. Для джуна это шанс сразу показать практическую пользу: выгрузки, отчёты и базовый анализ можно делать в десятки раз быстрее и аккуратнее, чем вручную в эксельке.

Для аналитика Pandas превращается в главный рабочий инструмент, позволяя не просто проверять гипотезы и делать сводные таблицы, а строить полноценные отчётные пайплайны, автоматизировать рутинные выгрузки и концентрироваться на сути данных, а не на правках ручками.

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

Наконец, даже для разработчиков Pandas может стать неожиданным бустом в карьере. Например, когда нужно автоматизировать отчёты для бизнеса или быстро анализировать логи и данные из БД без поднятия дашбордов — Pandas даёт гибкость и скорость, которые редко даёт что-то ещё в экосистеме Python.

2. Django

Django — фреймворк для веб-разработки на Python, который позволяет быстро создавать надежные и масштабируемые веб-приложения. Он следует принципам DRY (Don’t Repeat Yourself — не повторяй себя), предоставляя разработчику ORM, роутинг, систему авторизации, админку, работу с формами, шаблонами и инструментами безопасности из коробки.

Django подходит как стартапам, которым нужно быстро выйти на рынок, так и крупным проектам с миллионами пользователей. Это не просто библиотека, а полноценный каркас для построения и сопровождения веб-сервисов.

Какие задачи решает библиотека

Каркас, действительно, каркасный. Задачи следующие:

• Создание веб-приложений и API любой сложности.
• Быстрая разработка MVP, прототипов и коммерческих проектов.
• Упрощение работы с базами данных через ORM, без написания сырого SQL.
• Построение административных панелей для управления данными без ручной разработки.
• Гибкая маршрутизация и работа с формами, валидацией и шаблонами.
• Реализация аутентификации, авторизации и защиты приложений.

Django позволяет сосредоточиться на бизнес-логике и продукте, не тратить недели на настройку инфраструктуры.

Как пользоваться

Устанавливаем:

Создаем проект и приложение:

Пример модели:

Миграция базы данных:

Создание админки:

После этого можно запустить сервер:

И перейти по адресу http://127.0.0.1:8000/admin для управления записями через готовую админ-панель.

3. PyTorch

PyTorch — мощная библиотека Python. Она позволяет строить и обучать нейронные сети, проводить вычисления с автоматическим дифференцированием и работать с GPU для ускорения самих вычислений.

Главное отличие PyTorch от других ML-фреймворков — динамическая вычислительная графика (define-by-run): модель строится и изменяется во время выполнения кода, что даёт гибкость при создании и отладке сложных моделей.

Сегодня PyTorch используется в продакшен системах, научных исследованиях, компьютерном зрении, NLP и генеративных моделях, занимая ведущее место в индустрии.

Какие задачи решает библиотека

В функционал PyTorch входят:

• Построение нейронных сетей любой сложности (CNN, RNN, трансформеры);
• Обучение и тестирование моделей на CPU и GPU;
• Реализация кастомных слоёв и loss-функций;
• Разработка и деплой ML/AI моделей в продакшен;
• Быстрая итерация гипотез с удобной отладкой.

С PyTorch можно начать с простых нейронных сетей, а затем перейти к реализации современных архитектур.

Как пользоваться

Установим PyTorch (на CPU, для GPU потребуется версия с CUDA):

Рассмотрим кейс обучения простой нейронной сети для классификации рукописных цифр MNIST.

После обучения можно использовать torch.save() для сохранения модели и torch.load() для загрузки в продакшн.

Почему это меняет карьеру

PyTorch — билет в мир современной разработки AI и машинного обучения. Владение инструментом даёт разработчику возможность уверенно войти в области, которые продолжают оставаться топовыми на рынке: искусственный интеллект, компьютерное зрение, NLP, генерация изображений и видео и т.д.

Для начинающего ML/AI-специалиста PyTorch помогает лучше понять, как устроены нейронные сети, и под капотом увидеть, как происходят вычисления. Это ускоряет рост навыков и делает разработчика востребованным в исследованиях и R&D-проектах.

Для дата-сайентистов PyTorch позволяет превратить исследовательские ноутбуки в готовые к деплою модели, благодаря PyTorch Lightning, TorchScript и ONNX.

Для разработчиков, которые хотят выйти на рынок AI, PyTorch — это мастхев: проекты в стартапах и крупных компаниях всё чаще строятся вокруг него. Умение писать кастомные loss-функции, проектировать сложные пайплайны обучения, настраивать обучение на кластерах и GPU — компетенции, которые существенно бустят зарплату.

PyTorch в целом помогает расширять портфолио: с ним можно создавать генеративные модели, строить LLM, участвовать в соревнованиях и работать с самыми современными подходами в машинном обучении.

4. Polars

Polars — современная библиотека для обработки данных в Python, созданная как альтернатива Pandas. Она использует колоночную архитектуру и многопоточность, что позволяет работать с большими объёмами данных значительно быстрее и с меньшим потреблением памяти.

Polars вдохновлена Pandas, но её API оптимизировано для производительности и удобства, а также даёт разработчику возможность писать цепочки ленивых вычислений, которые оптимизируются перед выполнением. Это делает её отличным инструментом для аналитиков, дата-инженеров и дата-сайентистов, которым нужно обрабатывать данные быстро.

Какие задачи решает библиотека

Polars явно есть, чем гордиться:

• Загрузка, очистка и преобразование больших датасетов;
• Анализ данных с использованием цепочек преобразований;
• Быстрая агрегация и группировка данных;
• Ленивые вычисления: построение пайплайнов преобразования данных, которые выполняются только при вызове collect().
• Обработка данных, которые не помещаются в память, за счёт эффективности и колоночной архитектуры.

Если Pandas начинает притормаживаться на данных в несколько гигабайт, Polars обычно продолжает работать быстро, позволяя без боли обрабатывать большие CSV.

Как пользоваться

Установка:

Давайте загрузим данные и проведем базовые трансформации:

А вот и пример ленивых вычислений:

В чем особенность:

• pl.read_csv загружает данные сразу.
• pl.scan_csv создаёт план вычислений для последующей оптимизации.
• Используются выражения (pl.col, .with_columns, .agg), которые композируются без создания промежуточных копий, это ускоряет процесс.

Почему это меняет карьеру

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

Для дата-инженеров Polars полезен при построении ETL и пайплайнов обработки данных, где важна скорость и предсказуемое потребление ресурсов. Его можно использовать в продакшен-скриптах, для подготовки данных к ML и для автоматизации отчётности.

Для дата-сайентистов Polars даёт возможность анализировать больше данных за меньшее время, быстро итерировать гипотезы и ускорять исследования. Его API достаточно близок к Pandas, поэтому переход не требует месяцев переучивания.

Освоение Polars показывает работодателям, что ты не просто знаешь стандартные инструменты, но умеешь выбирать оптимальные решения для реальных задач, повышая эффективность работы команды. В эпоху роста данных это критично для любого Python-разработчика, работающего с аналитикой и машинным обучением.

5. FastAPI

FastAPI — современный фреймворк для создания API на Python, заточенный под скорость, асинхронность и валидацию данных из коробки. Он построен на Starlette и Pydantic, автоматически создаёт OpenAPI-документацию, поддерживает асинхронное программирование и позволяет писать производительные REST и WebSocket API с минимальным количеством кода.

Вместо долгой настройки, как у Flask или Django, в FastAPI многое готово изначально: удобная работа с запросами и ответами, декларативная валидация, документация Swagger, асинхронность и высокая производительность без лишних усилий.

Какие задачи решает

Задач, действительно, много:

• Быстрая разработка REST API для мобильных и веб-приложений;
• Создание бэкенда для ML/DS моделей (деплой моделей в виде API);
• Построение микросервисов с хорошей производительностью;
• Реализация websocket-серверов и асинхронных API;
• Подготовка внутренних инструментов или бэкендов для MVP.

FastAPI помогает быстро запускать API и уверенно масштабировать его в полевых условиях. Это один из немногих фреймворков Python, который по скорости работы сопоставим с Node.js и Go.

Как пользоваться

Во-первых, нужно установить FastAPI и Uvicorn (используем ASGI-сервер для запуска):

Простейший API-пример с эндпоинтом GET /:

Запускаем сам сервер:

После запуска API будет доступен по адресу http://127.0.0.1:8000/. Автоматически доступна интерактивная документация Swagger по адресу http://127.0.0.1:8000/docs.

FastAPI поддерживает валидацию параметров запроса, тел запросов и путей прямо через типы Python. Например, простой эндпоинт с параметром:

При вызове http://127.0.0.1:8000/items/10?q=test FastAPI автоматически проверит, что item_id — это число, и распарсит q как строку.

Почему это меняет карьеру

FastAPI — билет в мир бэкенда, где скорость и чистота кода имеют довольно высокое значение. Для Python-разработчика это возможность быстро освоить создание API и микросервисов, не увязнув в громоздкой настройке, как в Django, и при этом получить систему, готовую к продакшену.

Для ML-специалиста FastAPI становится инструментом для деплоя моделей: можно обернуть пайплайн предсказаний в API, подключить авторизацию или логирование и получить работающий сервис за считанные дни.

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

6. Typer

Typer — современная библиотека для создания CLI-приложений на Python с минимальным количеством кода и автоматической генерацией документации. Автор библиотеки — Себастьян Рамирес, создатель FastAPI.

Главная особенность Typer — использование type hints для автоматического парсинга аргументов командной строки. Вы получаете удобную и читаемую CLI с поддержкой автодополнения и цветного вывода за считанные минуты.

Какие задачи решает библиотека

Список задач такой:

• Создание CLI-утилит любого уровня сложности.
• Быстрое прототипирование и упаковка Python-скриптов в удобные инструменты для продакшена.
• Генерация подробной справки (--help) и автодополнения команд.
• Облегченная поддержка и масштабирование CLI за счёт структуры и читаемого кода.
• Организация CLI с подкомандами, вложенными аргументами и обработкой ошибок.

Typer использует аннотацию типов и минимум шаблонного кода.

Как пользоваться

Установка:

Пример минимальной CLI:

Теперь можно запустить из консоли:

Результат будет такой: Привет, Алиса! Тебе 25 лет.

Почему это меняет карьеру

Typer меняет карьеру тем, что открывает путь к созданию удобных CLI-инструментов, которые автоматизируют рутину и повышают продуктивность.

С Typer можно быстро превращать свои Python-скрипты в надежные утилиты, которыми удобно пользоваться и другим разработчикам, и сотрудникам из других отделов. CLI-приложения часто становятся клеем инфраструктуры: они позволяют автоматизировать деплой, миграции БД, сбор данных, интеграцию с внешними API и локальную разработку.

Если вы Data Scientist или ML-инженер, Typer позволяет оборачивать пайплайны в CLI, которые легко запускать из Jenkins, Airflow или вручную. Если вы DevOps или Backend-инженер, можете создавать CLI для работы с инфраструктурой и сервисами без сложных зависимостей.

Кроме того, работа с Typer улучшает навык структурирования кода, понимание CLI, использования type hints и разработки инструментов, которые делают работу проще для других. А это, очевидно, ценится в любой команде и повышает востребованность специалиста.

7. Rich

Rich — библиотека Python для красивого форматирования и интерактивного отображения информации в терминале. С её помощью можно выводить цветные таблицы, маркдаун, прогресс-бары, подсвеченный синтаксис кода, деревья каталогов и логирование в понятной и привлекательной форме.

Rich создана для того, чтобы «оживить» консоль Python, сделать логи удобными для восприятия, а CLI-инструменты — профессионально выглядящими без лишних усилий. Это библиотека, которая улучшает и UX, и DX.

Какие задачи решает

Про красоту не забываем! Задачи следующие:

• Цветное и структурированное логирование, понятное при чтении логов в реальном времени.
• Отображение прогресс-баров для долгих операций.
• Вывод таблиц, деревьев каталогов, JSON прямо в терминале.
• Подсветка синтаксиса кода для CLI-инструментов.
• Создание CLI-интерфейсов, которые выглядят профессионально и современно.
• Улучшение читаемости при отладке скриптов.

С помощью Rich можно быстро сделать понятными даже сложные данные при отладке или демонстрации.

Как пользоваться

Установка Rich:

Для примера выведем таблицу с подсветкой в консоли:

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

Почему это меняет карьеру

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

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

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

Для дата-инженеров и разработчиков DevOps Rich полезна при создании админ-утилит и при мониторинге пайплайнов, для Python-разработчиков — при создании библиотек и фреймворков с CLI.

8. LangChain

LangChain — фреймворк для создания приложений на базе LLM, например, GPT, Claude, Mistral, Gemini. Он позволяет строить цепочки обработки запросов, интегрировать LLM с данными и инструментами, добавлять память и управление состояниями, а также связывать работу модели с внешними API и базами знаний.

LangChain предоставляет удобный слой абстракции над вызовами LLM и ускоряет разработку чат-ботов, RAG-приложений, агентов с инструментами, систем анализа документов и других AI-сервисов.

Какие задачи решает

Список внушительный:

• Интеграция LLM в Python-приложения без необходимости писать тот самый клеевой код вручную.
• Построение цепочек с последовательной обработкой сообщений, включая преобразования и вызовы внешних функций.
• Добавление памяти в чат-боты для сохранения истории общения и контекста.
• Использование агентов для динамического вызова инструментов (веб-поиск, базы данных, API).
• Создание RAG-систем с интеграцией LLM и векторных БД.
• Быстрая сборка прототипов LLM-приложений, которые можно развернуть в продакшен.

Как пользоваться

Установка:

Создадим простую цепочку с чатом GPT:

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

Почему это меняет карьеру

LangChain меняет карьеру, потому что открывает новый пласт Python-разработки в AI и LLM-инженерии, быстро превращая пользователя GPT в создателя полноценных AI-приложений. Вместо того чтобы писать хаотичный клеевой код, вы начинаете системно проектировать цепочки запросов, учитесь строить продуманные промпты и объединять их с инструментами, памятью и внешними API.

Работа с LangChain погружает в практическую LLM-инженерию: вы начинаете создавать RAG-приложения, которые умеют искать и анализировать данные перед генерацией ответа и строить агентов. Это востребовано в продуктах, где нужно подключать ИИ к базам знаний, автоматизировать задачи и разрабатывать интерактивные системы, которые реально используют модели в продакшене.

LangChain позволяет быстро собирать и запускать MVP AI-продуктов, что дает конкурентное преимущество при создании стартапов или внутренних сервисов. А ещё учит мыслить структурами и проектировать масштабируемую архитектуру LLM-приложений и видеть, как генеративный ИИ можно превратить в рабочий инструмент.

9. SQLAlchemy

SQLAlchemy — это мощная ORM и toolkit для работы с базами данных в Python, позволяющая писать SQL-запросы декларативно, создавать модели таблиц и управлять транзакциями в Python-коде без ручного написания SQL.

Библиотека даёт разработчику два уровня контроля:

• Core: низкоуровневая работа с SQL выражениями и соединениями;
• ORM: высокоуровневая декларативная работа с моделями, классами и связями между таблицами.

SQLAlchemy поддерживает PostgreSQL, MySQL, SQLite, Oracle и другие СУБД, давая единую абстракцию, без привязки к конкретному движку.

Какие задачи решает

Пул задач следующий:

• Описание таблиц в виде Python-классов и управление ими через сессии;
• Создание, чтение, обновление и удаление данных;
• Миграция SQL на декларативный стиль без потери гибкости;
• Полный контроль над транзакциями и выполнением запросов;
• Работа с асинхронными приложениями при создании FastAPI/Django-приложений;
• Экранирование параметров, которое снижает вероятность SQL-инъекций и ошибок.

Как пользоваться

Создадим минимальный пример для SQLite с таблицей пользователей:

Этот код создаёт базу example.db, таблицу users, добавляет туда одного пользователя и выводит всех пользователей в базе. При необходимости можно использовать SQLAlchemy Core для написания гибких запросов вручную, если нужно работать ближе к SQL.

Почему это меняет карьеру

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

Знание SQLAlchemy открывает дорогу в мир API, микросервисов и продуктов, где требуется качественное управление данными и гибкая логика работы с БД. Работа с SQL теперь совсем не страшная.

10. Seaborn

Seaborn — библиотека для визуализации данных на Python, построенная поверх Matplotlib и упрощающая создание информативных и стильных графиков с минимальным количеством кода.

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

Библиотека тесно интегрируется с Pandas DataFrame, позволяя использовать колонки данных напрямую для построения графиков, что делает её идеальной для EDA (разведочного анализа данных) и подготовки визуализаций для отчётов и презентаций.

Какие задачи решает

Визуализация безумно важна, особенно в контексте дата-аналитики. Seaborn отвечает за:

• Быстрое построение информативных графиков для анализа данных и поиска инсайтов;
• Автоматическую обработку ошибок отображения и масштабирования, что экономит время;
• Поддержку сложных визуализаций по типу ящиков с усами или тепловых карт без десятков строк кода;
• Стилизацию графиков без ручных настроек Matplotlib;
• Возможность добавлять статистические элементы (линию регрессии, KDE, распределение);
• Интеграцию с Jupyter Notebook для интерактивного анализа данных.

Как пользоваться

Допустим, у нас есть датасет с данными о чаевых:

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

Для построения более сложных графиков можно использовать диаграмму рассеяния:

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

Почему это меняет карьеру

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

Использование Seaborn в Python-стеке помогает выделиться среди разработчиков, которые ограничиваются Pandas и текстовыми логами, ведь визуализация часто позволяет быстрее заметить закономерности и убедить команду или заказчика в правильности гипотезы.

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

А какими библиотеками пользуетесь вы? Делитесь в комментариях!

Представьте: пятница, 18:30. Релиз через час. Вы меняете один роут в конфиге — и внезапно половина приложения отлетает. Поздравляем, вы только что познакомились с классической болью фронтендеров.

Проблема кроется в самой природе JavaScript. Строковые пути вроде /users/profile/${id} существуют в коде как обычные строки — без проверок, автокомплита и гарантий корректности. Опечатался в /usres вместо /users — и твоя навигация сломалась, а TypeScript молчит как рыба.

Двадцать лет назад мы кликали по window.location.href, десять лет назад — радовались React Router, а сегодня пора переходить на типизированные решения.

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

Суть проблемы

Проблема очевидна: путь /admin/products размазан по всему коду. TypeScript не знает, что эти строки связаны с определенной директорией, поэтому не проверяет их корректность. Опечатка в product вместо products — и вылетает ошибка 404.

В больших проектах эта проблема критична. Приложение с 200+ путями, где навигация разбросана по сотне компонентов, превращается в минное поле. Один программист меняет структуру URL, а остальные даже не подозревают об этом. Команды используют TypeScript для типобезопасности, но навигация остается уязвимой.

Что такое типизированная навигация?

Типизированная навигация превращает строковые пути в типизированные объекты. Вместо /admin/products/123/edit программист работает с функциями, которые знают структуру приложения и проверяют корректность написания путей на этапе компиляции.

Представьте GPS-навигатор, который знает все адреса в городе. Вы не можете ввести несуществующую улицу — система сразу выдаст ошибку. Так работает типизированная навигация: TypeScript проверяет, что путь существует, параметры переданы правильно, а структура URL соответствует пути.

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

Польза зависит от уровня разработчика:

• Джуны получают защиту от опечаток и автокомплит — меньше глупых ошибок и быструю разработку.
• Миддлы ускоряют разработку благодаря надежному рефакторингу — можно смело менять структуру URL без страха что-то сломать.
• Сеньоры используют типизацию для построения архитектуры приложения — создают переиспользуемые компоненты навигации, проверяют параметры и строят масштабируемые системы путей и директорий.

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

Как использовать React Router вместе с TypeScript

Для базовой типизации в React Router v6 сначала определите структуру путей. Создайте интерфейс, который описывает все пути в приложении:

Типизация параметров URL решает проблему с useParams. Вместо any получаете конкретные типы:

Query-параметры типизируются аналогично через useSearchParams. Создайте интерфейс для каждой страницы с query-параметрами и оберните хук.

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

Как внедрить типизированную навигацию в проекты

Централизованная система маршрутов облегчает управление навигацией в больших приложениях. Создайте отдельный файл с конфигурацией всех путей:

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

Современные библиотеки решают проблему из коробки. Например, Tanstack Router предоставляет полностью типизированную систему путей с автогенерацией типов, а Type-route создает типобезопасные пути через API.

Библиотека typesafe-routes внедряется даже в крупные проекты без необходимости менять сотни строк кода.

Выбор инструмента зависит от размера программы. Если у вас небольшое приложение — быстрее написать хук в пару строк. Но если разрабатываете сложный сервис — используйте библиотеки.

Как не сломать код при использовании типизированной навигации

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

Чеклист для код-ревью поможет не уронить прод:

• Все новые navigate() и используют типизированные версии;
• Параметры путей явно типизированы;
• Нет магических строк в навигации;
• Query-параметры описаны интерфейсами.

Важно: не используйте одновременно строки и типизированные пути — выберите один подход для проекта и не допускайте высокого уровня вложенности в объектах.

Автоматизация упрощает процесс. ESLint правило no-hardcoded-routes запретит использование строк в навигации. Код-генераторы создают типы из OpenAPI схем или конфигурации роутера.

Производительность не страдает — типы исчезают после компиляции. Теряется немного времени на компиляцию TypeScript, но экономия на отладке перекрывает затраты.

Где применять типизированную навигацию

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

E-commerce проекты выигрывают от типизации каталогов и фильтров. Пути вроде /catalog/:category/:subcategory?filters=price,brand содержат много параметров, которые легко сломать при рефакторинге.

Интеграция с Redux и Zustand упрощает синхронизацию состояния с URL. Типизированные селекторы автоматически обновляются при изменении роутов:

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

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

Больше новостей — в нашем тг-канале Представляешь

Что такое n8n

Рост использования ИИ в рутине разработки, маркетинга и бизнеса приводит к потребности в простых и гибких инструментах, которые позволяют быстро соединять модели, API и данные в работающие пайплайны. Каталог n8n даёт инженерам и продуктовым командам фору: можно за день собрать MVP своего ассистента или системы автоматизации, сократив месяцы разработки.

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

На данный момент на сайте доступно:

• 457 простых пайплайнов для новичков;
• 1349 пайплайнов среднего уровня сложности;
• 1440 продвинутых решений для профессионалов и команд автоматизации.

Каждый агент сопровождается документацией, описанием кейсов использования и рекомендациями по настройке. Также обновляется для совместимости с последними версиями n8n.

Запуск агента в n8n обычно занимает несколько минут:

1. Вы выбираете нужный шаблон из каталога (например, автоматический парсинг HackerNews с публикацией в Telegram, автоматическую вёрстку в Notion, управление AWS-ключами через Slack или генерацию отчётов с помощью Claude).
2. Импортируете шаблон в свою среду n8n (SaaS или локально). Настраиваете ключи API или доступ к нужным сервисам (Telegram, Notion, Discord, AWS, HubSpot и др.).
3. Запускаете и получаете работающий агент, готовый к эксплуатации без написания кода.
4. Все процессы визуализированы, поэтому можно легко редактировать логику работы, добавлять свои шаги (например, постобработку с помощью GPT, уведомления в Slack или отправку в CRM) и адаптировать агента под свои задачи.

Какие задачи можно автоматизировать

В каталоге есть ИИ-агенты и пайплайны для:

• SMM и маркетинга (сбор лидов, управление постингом, аналитика трендов);
• Кибербезопасности (мониторинг SSL, автоматические алерты, управление ключами AWS);
• Разработки (поддержка TypeScript Intellisense, автоматизация CI/CD);
• Продуктивности (сбор и структурирование заметок в Notion, автоматизация писем, напоминания);
• Исследований (поиск и структурирование данных с помощью ИИ, генерация дайджестов);
• Дизайна (подготовка медиафайлов и управление рабочими процессами);
• Продаж и клиентского сервиса (онбординг клиентов, автоматические уведомления и CRM-интеграции).

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

Что есть для разработчиков

n8n остаётся платформой с открытым исходным кодом, поэтому разработчики могут:

• Клонировать и адаптировать любые из 3200+ рабочих процессов под свои нужды.
• Интегрировать LLM (GPT-4o, Claude, Gemini) для создания сложных агентов с мультимодальными возможностями.
• Выстраивать корпоративные пайплайны и автоматизированные рабочие места для команд.
• Подключать плагины и собственные ноды для кастомных сценариев.
• Запускать пайплайны локально или в облаке, сохраняя контроль над данными.

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

Давайте представим ситуацию, что нужно запустить код, минуя все эти стадии. Прям в production-среде. На первый взгляд — бред! Но если подумать, то на самом деле, не такая уж редкость. Например, некоторые системы предоставляют своим пользователям возможность расширять функциональность за счет прикладных скриптов. Наш любимый CI/CD-конвейер зачастую построен на пользовательских скриптах.

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

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

Ненадёжный код

Для начала определимся, что же считать ненадёжным кодом? На самом деле ответ зависит от решаемой задачи, правил и процессов, принятых в компании:

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

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

Уровни изоляции кода

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

Уровень 1: тот же процесс

Запуск внешнего кода в адресном пространстве процесса приложения.

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

Примером может служить использование интерпретаторов скриптов (Rhino, IronPython, Jython и т.п.), визуальных языков программирования (workflow-движков) или подключение модулей расширения (плагинов).

Способов защиты на этом уровне не так много. Пожалуй, самым эффективным выступает (self-sandboxing), при котором приложение делает самозапрет на доступ к некоторым ресурсам системы. Например, сразу после инициализации — самозапрет на доступ к файловой системе.

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

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

Уровень 2: отдельный процесс

Запуск внешнего кода на той же машине, но в отдельном процессе ОС.

Поскольку и приложение, и внешний код взаимодействуют в рамках одного узла, используя локальные ресурсы ОС (оперативная память, файловая система и т.п.), скорость межпроцессного взаимодействия очень высокая.

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

Уровень 3: отдельная машина

Запуск внешнего кода на отдельной машине — песочнице.

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

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

Использование песочницы

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

Пересоздание или переиспользование песочницы

Песочницу требуется пересоздавать перед исполнением каждой задачи, если требуется особенное окружение (например, определенная версия ОС, пакетов или ресурсов) или идентичность этого окружения (для стабильности получаемых результатов). Схожие вопросы возникают, например, при интеграционном тестировании: каждому тесту нужны свои предустановки.

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

Основным преимуществом пересоздания песочницы выступает стабильность получаемых результатов. К недостаткам относится медленный запуск и перерасход ресурсов. На пересоздание песочницы уходят десятки секунд или даже минут, следовательно, большая часть ресурсов будет тратиться именно на это. Существует множество техник ускорения пересоздания, благодаря которым можно сократить время запуска. Прежде всего, сюда можно отнести backup/restore (snapshot песочницы, базы данных и т.п.). Также если поток задач небольшой и ресурсы позволяют, можно попробовать организовать пул песочниц и создавать их заранее.

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

Последовательное или параллельное исполнение

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

• важен порядок следования и исполнения задач;
• задачам нужен эксклюзивный доступ к определенному ресурсу;
• задачи ёмкие и их совместное исполнение вызовет нехватку ресурсов;
• задачи могут мешать исполнению друг друга из-за борьбы за ресурсы.

Например, шаги установки и настройки ПО; шаги CI/CD-конвейера; рендеринг изображения на GPU; интенсивные вычисления. Все эти задачи, скорее всего, придётся исполнять последовательно.

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

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

На практике было замечено, что при параллельном исполнении, несмотря на увеличенную общую пропускную способность, время исполнения каждой отдельной задачи увеличивается. Если уровень параллелизма становится больше числа CPU-ядер, время исполнения начинает деградировать намного сильней.

Управление песочницами

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

Оркестрация

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

Основное преимущество оркестрации в контексте решаемой проблемы — её простота и ясность. Код легко читается и сосредоточен в одном месте. Однако у этого решения есть и недостатки. Рассмотрим их в порядке от простого к сложному.

• Синхронное взаимодействие. Так или иначе, для результата приложение вынуждено ожидать окончания исполнения задачи. Для продуктивного использования ресурсов приходится прибегать к техникам асинхронного программирования: пока задача исполняется, приложение будет занято полезной работой. Это малозаметный недостаток в языках со встроенной поддержкой концепции асинхронного программирования. Для упрощения работы с асинхронным кодом в Java я создал небольшую вспомогательную библиотеку asynchronizer, снабдив её подробной документацией.

• Отслеживание доступности песочниц. Поскольку хотелось бы, чтобы количество песочниц менялось в зависимости от нагрузки на систему, придётся отслеживать их доступность. Это прямая обязанность оператора песочниц, которую можно выделить в отдельный discovery-сервис (например, на базе Netflix Eureka), либо реализовать как часть приложения с использованием инфраструктурных механизмов (например, Kubernetes API). Важно отметить, что оператор песочниц не имеет отношения к бизнес-логике приложения.

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

• Неопределённость результата, если нет ответа от песочницы. Песочница может быть недоступна по различным причинам, включая не только проблемы с сетью, но и падения песочницы из-за ненадёжного кода. К сожалению, в общем случае эта проблема не имеет решения, так как делать повторные запуски (retries) может быть опасно. Всё, что остаётся, это использовать таймауты и откладывать неуспешную задачу на потом.

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

Для отслеживания нагрузки на песочницы экземпляр приложения ориентируется на количество задач в каждой из доступных песочниц. Предположим, что было принято решение увеличить количество экземпляров приложения. Этот экземпляр исполняет 5 задач в двух песочницах (3 процесса в одной и 2 в другой). Известно, что каждая песочница может вынести максимум 4 параллельных задачи.

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

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

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

• Для контроля количества исполняемых задач в песочнице использовать распределённый счётчик (например, на базе Redis). Проблема в том, что распределённый счётчик имеет латентность и на момент запуска задач может выдать устаревшее значение. Кроме того, в системе появляется еще один инфраструктурный компонент, который не несёт бизнес-пользы.

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

Кстати, после доклада на TechLeadConf 2025 мне задали интересный вопрос: Можно ли при балансировке нагрузки на песочницы учитывать не только количество исполняемых задач, но и процент загрузки CPU, памяти и прочих ресурсов? Если у кого-то возник такой же вопрос, то отвечу, что это не имеет смысла, поскольку ситуация в песочнице может поменяться мгновенно. Полученный практический опыт и нагрузочное тестирование показали, что простой подсчёт задач работает эффективно.

Самоорганизация

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

Ключевой момент в архитектуре — это появление двух очередей: очередь задач на исполнение (Task Queue) и очередь результата их исполнения (Result Queue). Все поступающие задачи приложение направляет в первую очередь, а результаты — во вторую. Дополнительно появляется роль агента — микросервиса, который исполняется в рамках узла песочницы и координирует исполнение поступающих задач.

Основной недостаток самоорганизации — распределённый процесс обработки задач. Учитывая простоту алгоритма обработки, это не так существенно. Стоит отметить преимущества этой архитектуры.

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

• Скорость и стабильность взаимодействия. Никаких проблем с сетью из-за локальности взаимодействия между агентом и песочницей.

• Контролируемая нагрузка на песочницы. Агент, выступая в роли консюмера очереди задач, может точно контролировать степень параллелизма и выбирать новые задачи только тогда, когда он закончил обрабатывать предыдущие.

• Минимум инфраструктурного кода. Очереди избавляют от необходимости иметь оператор песочниц, отслеживать их состояние и осуществлять балансировку нагрузки.

• Простота масштабирования. Приложение и песочницы масштабируются независимо друг от друга без негативных побочных эффектов.

Запуск процесса ОС

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

• Как ограничить права доступа к ресурсам. Самое простое решение — запуск процесса от имени пользователя с ограниченными правами (на доступ к ресурсам ОС).

• Как ограничить объем используемых ресурсов. Для запускаемого процесса нужно определить доступные ресурсы и возможные действия.

• Как осуществлять анализ поведения и результатов исполнения. Наличие и решение этой проблемы целиком и полностью зависит от специфики проекта. Здесь невозможно предложить универсального решения.

Рассмотрим варианты ограничения ресурсов процесса ОС.

Ограничение ресурсов процесса

Ресурсы процесса могут быть ограничены на трех уровнях:

• Лимиты узла. Физические ограничения машины, на которой исполняется процесс. В частном случае можно говорить об инфраструктурных лимитах, определённых для Docker/Kubernetes контейнера.

• Лимиты контейнера. Программные лимиты, задаваемые выбранным инструментом контейнеризации (cgroup, Docker, Bubblewrap, ProcessSandbox и т.п.).

• Лимиты процесса. Программные лимиты, задаваемые средствами ОС. На этом уровне можно осуществлять гибкую настройку вариантов запуска и исполнения.

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

Между тем, важно отметить некоторые трудности, которые могут возникнуть при использовании инструментов контейнеризации.

Например, для использования cgroup или Docker внутри Kubernetes-контейнера нужно эскалировать привилегии контейнера, что в общем случае небезопасно в контексте исполнения ненадёжного кода. Более того, практика показала, что легковесных rootless-средств, предоставляемых ОС, вполне достаточно, чтобы снять большую часть рисков. В частности, Linux API позволяет не только лимитировать CPU и память, но и блокировать доступ к некоторым возможностям самой ОС. Например, можно наложить фильтр, который запретит вызов определённых системных функций.

Проблемы жёсткого лимитирования

Рассмотренные выше способы лимитирования задают жёсткие границы (hard limit), нарушение которых замедляет исполнение процесса, либо приводит к его принудительному завершению. При этом поведение наблюдаемого процесса и системы сильно варьируется в зависимости от того, какой лимит был превышен. Например, превышение по использованию CPU может привести к троттлингу (throttling), приостановке работы или принудительному завершению; превышение по использованию памяти заканчивается принудительным завершением со стороны ОС (OOM Killer) либо самостоятельным падением процесса (с ошибкой Out Of Memory).

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

Такой подход имеет несколько преимуществ.

• Точное определение причин принудительного завершения. Жёсткие лимиты чуть выше мягких, благодаря чему для исполняемого кода создаётся иллюзия отсутствия каких-либо лимитов. Между тем, если лимиты всё-таки нарушаются, процесс всё равно будет завершен (либо со стороны приложения, либо гарантированно со стороны ОС). Но подобный дополнительный контроль со стороны приложения оставляет для него гораздо больше шансов понять причину принудительного завершения наблюдаемого процесса.

• Возможность гибкого лимитирования ресурсов. Приложение (или агент), ответственное за запуск наблюдаемого процесса, может обратиться к средствам ОС (в частности, к Linux API) и гибко настроить параметры запуска и исполнения. Как минимум, жёстко определить лимиты по CPU и памяти; наложить ограничения на объем I/O; создать запрет на вызов некоторых системных функций (например, запрет использования сетевых операций или файловой системы) и т.п.

Такой подход я назвал watchdog и в целях иллюстрации реализовал его в виде .NET-библиотеки ProcessSandbox. Помимо прочего, на странице проекта подробно рассмотрена проблематика контроля и анализа поведения процесса ОС со стороны прикладного кода.

Итоговая схема лимитирования может выглядеть так, как показано на рисунке ниже. Вместо тяжеловесных инструментов контейнеризации используется легковесный rootless-инструмент (watchdog) на базе средств ОС и только.

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

Многоконтейнерные поды

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

Несмотря на всю заманчивость данной идеи, она несёт ряд недостатков.

• Плохая масштабируемость. Соотношение приложение-песочница всегда один к одному. Однако не исключено, что в некоторых случаях это вполне приемлемо.

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

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

• Риск нарушить работоспособность приложения. Выход песочницы из строя скорее всего приведет к перезапуску всего пода. Более того, если приложение и песочница обмениваются файлами через общий раздел (shared volume), это может стать уязвимым местом.

Образ для песочницы

Основные моменты, которые следует учесть при создании (Docker) образов песочниц:

• Заменить init-процесс на tini, чтобы не превысить лимит по PIDs.

• Создать непривилегированного пользователя, ограничив ему права на доступ к ресурсам.

• Регулярно сканировать версии образов и пакетов на наличие уязвимостей.

Инфраструктура исполнения

Основные моменты, которые следует учесть при настройке инфраструктуры исполнения:

• Обеспечить быстрый (пере)запуск песочниц. Нужно быть готовым к тому, что песочницы будут падать. Если речь идет о Kubernetes, то улучшить время запуска может подходящая настройка Image Pull Policy. При этом лучше не использовать тег `latest`, а указывать конкретную версию или хэш-код образа, чтобы не тратить время на попытки определения последней версии при каждом запуске.

• Установить приемлемый лимит на PIDs. Необходимо контролировать число активных процессов в системе. Особо вредоносный код может попытаться создать очень много дочерних процессов, поэтому при отсутствии лимита на PIDs узел быстро будет выведен из строя. Важно отметить, что лимит задаётся для пользователя, а не для запускаемого процесса. По этой причине он должен быть разумно большим.

• Установить лимиты на ресурсы узла. В Kubernetes для каждого контейнера нужно указать, как минимум, лимиты по CPU и памяти. Значения лимитов лучше всего определить в ходе нагрузочного тестирования или путём сбора метрик приложения.

Заключение

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

Я постарался показать последовательность шагов по направлению к целевой архитектуре, которая будет отвечать требованиям бизнеса и справляться с ненадёжным кодом. Если вам интересна данная тематика, подписывайтесь на мой Telegram-канал Архитектоника в ИТ (@arch_and_dev). Буду рад поделиться опытом.

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

Шутки шутками, но тема действительно важная. Я прошел путь от классических монолитных приложений до сложных микросервисных, проектировал системы, которые работают под большой нагрузкой, и пришел к выводу, что однозначного ответа здесь не существует. И вообще, «монолит или микросервисы» — это неправильная постановка вопроса.

Недавно сходил с Витей на запись подкаста на эту тему и настолько преисполнился, что решил в текстовом виде формализировать свое отношение к теме (я гнался за вами три дня, чтобы сказать, как вы мне безразличны, ага), обобщить то, о чем говорили, и попытаться дать ответ на вопрос «когда микросервисы действительно помогают и как не сойти с ума, если вы с ними работаете». Порассуждаю о проектировании, поддержке, DevOps-культуре и попробую немного заглянуть в микросервисную архитектуру.

Микросервисы: зачем они нужны и в чем их плюсы

Архитектура приложений: немного базы

Под капотом современных приложений обычно скрываются три основные части:

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

Собрать это все можно по-разному. Можно сложить в монолит, а можно попробовать модульный подход.

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

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

Масштабировать можно и монолиты, но у них всегда остается какая-то единая точка отказа — например, база данных. Особенно если это реляционная СУБД, завязанная на Oracle или PostgreSQL. Когда база достигает сотен гигабайт или даже терабайт, масштабировать такую штуку становится дорого, больно и ненадежно.

Микросервисы — панацея? Не совсем

Тренд на микросервисный подход появился в начале 2010-х годов, вместе с проникновением интернета в широкие слои населения. Первый iPhone вышел в 2007 году, люди стали гораздо ближе к интернету, к данным, к информации. Бизнес захотел дотянуться до этой аудитории, и тогда началась диджитализация, сложность систем стала повышаться. Особенно остро это почувствовали крупные организации вроде банков: функциональность увеличивалась, и монолит начал «трещать» не только технически по инфраструктуре, но и по возможностям команд разработки, которые с ним работали.

Плюсы микросервисов очевидны: масштабируемость, независимая разработка, изоляция компонентов. Но вместе с этим пришли новые проблемы — усложнились мониторинг и поддержка, стали требоваться все новые инструменты, чтобы обеспечивать работу огромной инфраструктуры. Так появился DevOps.

Распространение DevOps-культуры и инструменты оркестрации

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

В новой реальности количество артефактов, которые нужно перекидывать через забор, кратно выросло. Вместе с этим появилась и стала распространяться DevOps-культура: понимание, что за качественную раскатку в проде отвечает не только команда поддержки, но и разработчики.

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

Проектируем микросервисы без боли: от стандартов до DDD

Стандартизация — наше все

Если каждый микросервис пишет логи в своем формате и использует свои библиотеки, получается зоопарк. Нужно, чтобы были выровнены стек и CI/CD pipeline, существовали одинаковые библиотеки логирования и формат.Микросервисы дают свободу писать на разных языках, но с ней приходит и ответственность: под каждый язык придется придумывать и поддерживать разные инструменты. А это приведет к еще большему увеличению сложности. Так что с языком тоже лучше соблюдать стандартизацию: если пишете на Java, то и решать все проблемы стоит с помощью этого языка.

При этом иногда другой язык вполне оправдан. Например, просто потому, что Java не может работать с такой высокой скоростью, какая нужна. В некоторых случаях даже на Java приходится писать особым образом, либо можно использовать C++, Go или Rust. Но это скорее исключение из правила.

Инженеры — натуры увлекающиеся и любят паттерн CV driven development, когда хочется новую технологию потрогать и внедрить у себя. А потом похвастаться этим на каком-нибудь ивенте по принципу «just because I can» («просто потому что могу»). При этом может оказаться, что бизнесу технология особо и не была нужна. Чтобы избегать таких ситуаций, необходим технологический радар — список того, что можно использовать в компании, а что нет. И исключения из такого радара должны приниматься и допускаться очень взвешенно.

DDD: как правильно нарезать сервисы

Одна из опасностей при проектировании микросервисов — скатиться в очень мелкую гранулярность, когда логика нарезается чуть ли не по отдельной функции на микросервис (на отдельный deployment unit). Это может привести к такой сложности, которой потом будет очень трудно управлять. Такая проблема была, например, у Uber в начале их пути, и им пришлось пересматривать свою архитектуру. Избежать этого помогает Domain-driven design (DDD) — предметно-ориентированное проектирование.

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

Существует и еще одна проблема, с которой DDD помогает справиться, — неправильная нарезка сервисов с точки зрения бизнесовой функциональности. Если не понимать бизнес-контекста, можно получить «распределенный монолит»: будет много отдельно стоящих сервисов, но профита никакого, только все сложности микросервисов плюс проблемы монолита с масштабируемой базой данных. Особенно остро это проявляется, когда изменения в одной части бизнес-процесса (в одном сервисе) влекут за собой изменения еще в трех-четырех-пяти других сервисах.

DDD помогает выделить bounded context — согласованные по бизнесу участки. Они позволяют более или менее правильно нарезать большой бизнес-функционал на отдельные части.

Еще один важный принцип правильной архитектуры микросервисов — у каждого микросервиса должна быть своя независимая маленькая база данных (если она вообще нужна).

Два эмпирических правила, которые касаются размера сервисов и помогают понять, правильно ли они спроектированы:

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

Внедрение микросервисов: с чего начать?

С микросервисным подходом есть проблема — нет четкого ответа, куда идти и что делать, чтобы научиться его создавать. Это одна из главных сложностей микросервисной архитектуры, особенно когда только начинаешь с ней работать. Если хочется изучить Spring или Oracle, можно почитать официальную документацию. А к такой большой и необъятной теме, как микросервисы, даже и непонятно, с какой стороны подступиться. Туториала к ней нет, есть только куча статей, подходов и практик. Причем одни практики подойдут конкретной команде, а другие — нет.

И вот тут возникает реальная сложность, особенно когда вы только начинаете, — глаза разбегаются. Здесь Kubernetes, здесь ELK, здесь Grafana, здесь observability, здесь всякие паттерны отказоустойчивости, CAP-теорема и прочее. Непонятно, куда бежать. И каждый день появляются новые инструменты, которые так или иначе упрощают жизнь.

Совет: задавайте себе вопрос о каждом инструменте, который вы хотите внедрить (будь то Kubernetes, OpenTelemetry с Jaeger или любой другой) — какую проблему мы решаем, втаскивая его в свою инфраструктуру? Ответ на этот простой вопрос может дать много инсайтов и просветлений.

Чтобы в первом приближении ознакомиться с темой, можно почитать материалы SRE от Google, также будут полезны статьи и книги в блоге Мартина Фаулера, в том числе Microservices Guide. Если вам нужна практика, можно попробовать пойти на тот же Udemy, где есть множество курсов по микросервисной архитектуре с хорошими рейтингами и отзывами.

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

Поддержка микросервисной архитектуры

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

В крупных организациях микросервисов могут быть сотни: например, в некоторых системах насчитывается почти 700 микросервисов на продакшене. Каждый инстанс еще масштабирован — это тысячи подов, которые постоянно обрабатывают клиентский трафик. И при этом в современных условиях нужно стремиться к доступности системы на уровне четырех девяток (99,99%), то есть к простою всего в несколько минут в год.

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

Паттерны отказоустойчивости

Микросервисы — это не про «разбили монолит», это про то, что сбой одного сервиса не должен валить весь продукт. Поэтому если какой-то важный сервис упал, то максимум, который нужно сделать, — чтобы клиент не увидел упавший кусочек функционала приложения.

Еще один хороший вопрос: как мониторить аварии? Необходимо очень быстро находить точку отказа. Для этого, собственно, и нужен observability-подход, трейсинг. Нужно смотреть, где какой RPS (число запросов в секунду), не произошло ли резкого скачка трафика, важно следить за latency (задержками).

Бывали случаи, когда из-за бага в мобильном приложении трафик внезапно удваивался, и системы не выдерживали такой нагрузки. Любая малейшая задержка в самом незначительном компоненте может привести к тому, что по цепочке пойдет отказ, — будут копиться потоки, соединения, и рано или поздно упадет вообще все. Чтобы подготовиться к таким ситуациям, важно изучить хотя бы четыре «золотых сигнала» мониторинга из SRE от Google.

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

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

• Circuit Breaker — если сервис спамит ошибками, лучше временно прекратить попытки до него достучаться. Для клиента ничего не изменится, он как получал ошибки, так и будет получать. Но, по крайней мере, можно дать системе возможность восстановиться. А еще лучше — позволить ей переключиться на какой-то резервный канал, например сходить в кэш с неактуальными данными.
• Rate Limiter — абсолютно банальная, но необходимая вещь. Нужно ограничивать входящий поток на примерно максимальном уровне от того, который ожидается. Чтобы все не развалилось, если произойдет резкий скачок трафика.
• Blue-Green Deployment — значительно снижают на продакшене количество аварий и проблем, связанных с кривыми релизами. Можно не раскатывать новую фичу сразу на все 100 подов, а выкатить ее только на 1% трафика и проверить.

И это только малая часть паттернов.

Все это must have для абсолютно любой системы. Даже если у вас низкая нагрузка, она когда-нибудь увеличится. Лучше вовремя предусмотреть это, заранее потратив чуть больше времени и реализовав эти паттерны.

Как эффективно работать с инцидентами

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

Первый уровень — это application-слой, сами сервисы, которые в подах крутятся в Kubernetes. Нужно проверить, все ли у них хорошо по точкам интеграции — нет ли тайм-аутов. Все ли в порядке у них по железу — по CPU, по памяти, по дискам.

Если на первом уровне все нормально, нужно опуститься на уровень ниже — либо на виртуалки, на которых Kubernetes развернут, либо на железки, если он развернут на Bare-metal. Недавно мы столкнулись с интересным случаем: виртуалка показывала нормальную загрузку CPU, но физический гипервизор, на котором она крутилась, был загружен на 99%. Естественно, виртуалка страдала, но уровнем выше этого не было видно.

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

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

Вообще, человеческий фактор — это отдельная боль. Все привыкли менять что-нибудь руками: заходить в виртуалки, поправлять конфиг. Чтобы такого было как можно меньше, важно вкладываться в infrastructure as a code и даже everything as a code. В идеале следует стремиться к zero access production — нулевому доступу к продакшену — и все раскатывать через Git, через конфигурации, включая политики безопасности.

Культура ответственности и изменение ролей в команде

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

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

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

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

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

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

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

Проще говоря, есть два варианта взаимодействия с поддержкой: классический, когда она административно отделена, и SRE-подобный, когда сотрудники «второй линии» прямо интегрированы в команду разработки. Могу сказать, что второй эффективнее.

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

Это то самое SRE, о котором пишет Google. Но людей нужно долго обучать такой культуре — это не дело одного месяца. Благодаря такому подходу инженеры, которые раньше были просто разработчиками или аналитиками, глубже осознают свою ответственность за стабильность продакшена. И это действительно правильное направление развития. Потому что и DevOps, и SRE — это в первую очередь культура, а уже во вторую — набор инструментов.

Будущее микросервисов: тренд на AI Ops

Разработчики уже используют AI как copilot — и это очень мощный инструмент в умелых руках. Он не заменяет инженера, но сильно экономит ему время. Эту помощь от нейросетей очень хочется растянуть и на инфраструктуру, и на эксплуатацию, чтобы получить крутой AI Ops.

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

Есть прототипы — например, Big Panda или Moocsoft (который был недавно куплен Dell), но пока это точечные решения. Возможно, на горизонте 5–7 лет (скорее 5, чем 10) они станут серьезной частью индустрии и очень мощным прорывом, который упростит разработчикам жизнь.Кроме того, важно, чтобы развивались и более «приземленные» технологии: инструменты контейнеризации, оркестрации, observability, а также APM — Application Performance Monitoring.

Инженер остается в центре всего

Никакие микросервисы, Kubernetes и AI Ops не спасут, если за системой не стоит инженер, который думает головой, правильно работает руками и отвечает за результат. Важны его навыки, кругозор и культура работы. Именно такие люди превращают набор сервисов в работающий продукт. Все остальное — только инструменты.

P. S. Если интересно, как мы решаем эти задачи на практике, слушайте (и смотрите) наш подкаст «Техно.Логично» — там регулярно обсуждаем самое актуальное в IT-сфере.

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

2005-2009: Эпоха авторских решений и первых веб-фреймворков

В середине 2000-х типичный рабочий инструмент программиста — это громоздкий системный блок с процессором Intel Pentium 4 или новеньким Core 2 Duo. Мониторы с ЭЛТ-трубкой постепенно уступали место LCD-экранам с разрешением 1024×768 — именно на таких дисплеях создавались первые версии Wikipedia и набирающих популярность соцсетей. Оперативная память в 1-2 ГБ считалась нормой, а жесткие диски на 80-160 ГБ часто заполнялись до отказа — проекты редко весили меньше нескольких гигабайт.

Серьезная разработка велась преимущественно на стационарных компьютерах. Ноутбуки только начинали входить в обиход — их брали в офис, но для реальной работы предпочитали мощные десктопы. Операционная система Windows XP доминировала на рабочих станциях, в то время как серверы чаще всего крутили на Linux — Red Hat Enterprise или Debian.

Среды разработки того времени сегодня кажутся архаичными. Eclipse и NetBeans потребляли гигабайты памяти, Visual Studio 2005 требовала серьезных ресурсов. Многие разработчики предпочитали простые текстовые редакторы вроде Notepad++, а для отладки использовали примитивные методы вроде вывода значений переменных через print. Контроль версий только начинал входить в практику — Git появился в 2005 году, но большинство команд продолжали использовать SVN или вообще заливали файлы по FTP напрямую на продакшен.

Языковая экосистема этого периода вращалась вокруг трех основных технологий. PHP версий 4 и 4.3 доминировал в веб-разработке — на нем работало около 80% всех сайтов в интернете. Однако его объектно-ориентированные возможности были крайне ограничены до выхода PHP 5 в 2004 году.

Java в лице J2EE оставалась стандартом для корпоративных решений — банковских систем, крупных порталов и ERP-комплексов. Spring Framework только начинал набирать популярность, а Hibernate упрощал работу с реляционными базами данных. C++ сохранял свои позиции в разработке игр (особенно с использованием Unreal Engine), драйверов и высоконагруженных сервисов.

Фронтенд-разработка в те годы была невероятно простой по современным меркам. Верстали преимущественно таблицами, а всю динамику реализовывали через jQuery, который появился в 2006 году и быстро вытеснил нативный JavaScript из повседневной практики. AJAX-запросы казались революционной технологией, позволяющей обновлять части страницы без ее полной перезагрузки.

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

• «Философия Java» Брюса Эккеля;
• «Совершенный код» Стива Макконнелла;
• «PHP и MySQL. Разработка веб-приложений» Люка Веллинга.

Русскоязычное сообщество активно обсуждало вопросы разработки на форумах RSDN.ru и CyberForum.ru. В 2008 году появился Stack Overflow, который постепенно стал главной площадкой для профессиональных обсуждений.

Университетское образование давало хорошую теоретическую базу — алгоритмы, структуры данных, принципы ООП. Однако практическим навыкам приходилось учиться самостоятельно, методом проб и ошибок. Документацию часто скачивали в формате CHM-файлов или читали непосредственно на сайтах вроде php.net и MSDN.

Типичный стек начинающего разработчика в 2009 году:

• HTML/CSS с jQuery для фронтенда;
• PHP или Ruby on Rails для бэкенда;
• MySQL в качестве базы данных.

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

Показательный кейс:

В 2007 году разработчик PHP-приложений из МЭСИ (Москва) столкнулся с типичной для того времени проблемой — SQL-инъекциями. Вместо стандартных решений он создал DLAC (Data Logic Access Component) — обертку для работы с базой данных, которая автоматически экранировала параметры запросов. Это выглядело революционно на фоне типичного кода того периода, где строки запросов часто собирали через конкатенацию с пользовательским вводом.

Компонент использовал новую для 2005 года технологию Generics в C#. Он генерировал параметризованные запросы, что резко снижало риски взлома.

Разработчики в университетской среде тогда редко задумывались о безопасности — многие проекты содержали уязвимости вроде SELECT * FROM users WHERE name = ‘.$_POST[‘name’].

DLAC стал локальным спасением для внутренних систем МЭСИ, пока в 2009 году не появился NHibernate — порт популярного Java-фреймворка Hibernate.

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

2010-2014: Мобильная революция и рассвет JavaScript

Начало нового десятилетия ознаменовалось стремительным ростом мобильных технологий. Выход iPhone 4 в 2010 году и Android 2.3 Gingerbread задал новые стандарты мобильной разработки.

Программисты массово переходили на MacBook Pro — не столько из-за преимуществ macOS, сколько благодаря появлению Retina-дисплеев в 2012 году, которые кардинально улучшили качество отображения кода.

Железо продолжало стремительно эволюционировать. Твердотельные накопители (SSD) начали вытеснять традиционные жесткие диски в рабочих станциях. Облачные платформы вроде AWS и Heroku стали реальной альтернативой локальным серверам, которые раньше часто стояли прямо под рабочими столами в офисах. Оперативная память в 8 ГБ стала стандартом для комфортной разработки, а четырехъядерные процессоры ускорили сборку крупных проектов.

Языковая палитра этого периода значительно расширилась. Objective-C стал основным языком для iOS-разработки и оставался таковым до появления Swift в 2014 году. Python 3 начал набирать популярность благодаря веб-фреймворку Django и научным библиотекам NumPy и Pandas, которые открыли дорогу для анализа данных в массовом сегменте.

JavaScript пережил настоящий ренессанс — после выхода AngularJS в 2010 и Node.js в 2009 году он перестал быть просто «языком для анимаций на сайте», превратившись в полноценную платформу для fullstack-разработки.

Важный факт. В 2011 году разработчик из Сан-Франциско Райан Даль представил Node.js — среду выполнения JavaScript на стороне сервера. За первые 24 часа после релиза проект собрал 10 000 звезд на GitHub, что для того времени стало рекордом. Многие скептически относились к идее использовать JavaScript вне браузера, но уже через год такие компании как LinkedIn и Walmart перевели части своего бэкенда на Node.js, получив прирост производительности в 2-3 раза по сравнению с традиционными решениями на Java и Ruby.

Образовательная сфера претерпела значительные изменения. В 2011 году запустилась Coursera с первым массовым курсом по программированию — Machine Learning от Эндрю Ына. В 2012 году в Кремниевой долине открылся Hack Reactor, ставший прототипом современных coding bootcamps (интенсивов по программированию). Эти форматы предложили альтернативу традиционному университетскому образованию, сделав акцент на практических навыках.

Параллельно в России:

• В 2012 году появился Hexlet — одна из первых русскоязычных платформ с практико-ориентированными курсами по программированию. Особенность: выполнение заданий в реальной среде разработки через браузер. Платформа до сих пор работает: на текущий момент 80% выпускников трудоустраиваются в IT, согласно исследованию ВШЭ. В 2012 этот показатель был еще выше.
• «Нетология» (основана в 2011) к 2013 году запустила курсы по веб-разработке с акцентом на JavaScript и Python, сотрудничая с российскими tech-компаниями. Их модель включала менторство и проектные работы.
• В 2013 году стартовал Stepik — платформа с открытыми курсами от ведущих вузов (ИТМО, МФТИ). Особенность: интерактивные задачи с автоматической проверкой кода, что было прорывом для местного рынка.

Курс «Введение в Linux» от Stepik (2014) за полгода собрал 50 тыс. студентов — рекорд для Рунета. Задания включали настройку виртуальных серверов, что сразу применялось в работе.

Эти проекты заложили основу для бума EdTech в России после 2015 года, доказав, что онлайн-формат может давать актуальные навыки быстрее вузов.

Типичный разработчик среднего уровня в 2014 году:

• понимал принципы REST API;
• начинал осваивать основы DevOps с появлением Docker в 2013;
• экспериментировал с микроконтроллерами вроде Arduino или Raspberry Pi, создавая собственные IoT-устройства.

В профессиональной среде начал формироваться консенсус о том, что PHP устаревает для сложных коммерческих проектов.

2015-2019: Эра больших данных и облачных технологий

Аппаратные возможности сделали очередной рывок вперед. Многоядерные процессоры Intel i7 и AMD Ryzen стали стандартом для рабочих станций. 16 ГБ оперативной памяти перестали быть роскошью, а мониторы с разрешением 4К стали доступны широкому кругу разработчиков. В 2015 году появился Visual Studio Code, который быстро обогнал по популярности Sublime Text и Atom благодаря удачному сочетанию функциональности и производительности.

Языковая экосистема продолжила развитие. TypeScript, представленный в 2014 году, предложил решение проблемы масштабируемости JavaScript-кода в крупных проектах. Go от Google, созданный еще в 2009, нашел свою нишу в разработке микросервисов и инструментов оркестрации вроде Kubernetes (2015). Rust от Mozilla начал завоевывать доверие системных программистов благодаря уникальной системе владения памятью.

JavaScript-сообщество столкнулось с первыми серьезными проблемами. В 2016 году инцидент с пакетом left-pad показал уязвимость экосистемы npm — удаление одного небольшого модуля привело к сбоям в работе тысяч проектов по всему миру. Это заставило разработчиков задуматься о зависимости от сторонних библиотек.

Типичный senior-разработчик в 2019:

• разбирался в микросервисной архитектуре и понимал, как избежать vendor lock-in (привязки к поставщику) при работе с облачными провайдерами;
• имел опыт работы с React или Vue.js;
• знал, что понимание принципов работы алгоритмов становится менее важным, чем развитие soft skills для работы в команде.

Ключевые технологии этого периода включали Kubernetes, который стал стандартом де-факто для оркестрации контейнеров, а также TensorFlow (2015) и PyTorch (2016), открывшие эру машинного обучения для широкого круга разработчиков. Появились первые серьезные инструменты для работы с большими данными — Apache Spark, Hadoop.

Ключевой момент. В 2016 году Netflix раскрыл детали своего перехода на облачную инфраструктуру AWS. Компания полностью перенесла все сервисы — от рекомендательной системы до биллинга — в облако за семь лет. Главным триггером стала катастрофа 2008 года, когда три дня простоя дата-центра оставили 8,4 млн подписчиков без доступа к сервису. Миграция потребовала перепроектирования архитектуры: инженеры разбили монолит на 500 микросервисов и внедрили Chaos Monkey — инструмент для тестирования отказоустойчивости, который случайно отключал серверы в продакшене.

Этот кейс стал хрестоматийным примером cloud-native подхода. Облачные технологии стали активно использоваться в разработке, а обращение с ними — обязательным навыком для прогеров.

2020-2024: AI-assisted разработка и новые парадигмы

Пандемия COVID-19 ускорила переход на удаленную работу. Программисты по достоинству оценили макбуки на чипах M1 (2020) за их энергоэффективность и производительность. Домашние офисы оснащались 32-дюймовыми 4К-мониторами и механическими клавиатурами, ставшими своеобразным профессиональным стандартом.

Языковая палитра продолжала обогащаться. Rust официально вошел в ядро Linux в 2022 году, подтвердив свой статус системного языка нового поколения. Zig появился как современная альтернатива «C» с акцентом на безопасность. WebAssembly (Wasm) позволил запускать ресурсоемкие приложения прямо в браузере, открыв новые возможности для веб-разработки.

Искусственный интеллект начал проникать в повседневную работу программистов. GitHub Copilot на базе GPT-3, представленный в 2021, изменил сам процесс написания кода, предлагая контекстные подсказки. Low-code платформы вроде Retool упростили создание внутренних инструментов для бизнеса.

Типичный lead-разработчик в 2024 году:

• умел эффективно работать в гибридных командах (офис + удаленка);
• автоматизировал рутинные задачи через ChatGPT API;
• следил за развитием квантовых вычислений, хотя практическое применение пока оставалось ограниченным.

Ключевой момент. В 2023 году GitHub Copilot, разработанный совместно с OpenAI, стал катализатором перемен в индустрии. За первый год после релиза инструмент использовали более 1,3 млн разработчиков — каждый десятый подписчик GitHub. Система анализировала контекст кода и предлагала целые функции: например, при написании SQL-запроса она автоматически генерировала соответствующую модель данных на Python. Amazon внедрил аналогичный инструмент Amazon Q Developer для внутренних команд — по заявлению CEO Энди Джесси, это сэкономило компании 4,500 человеко-лет работы и $260 млн ежегодно.

Но были и курьезы. В 2024 году разработчик из Берлина случайно отправил в продакшен код, полностью сгенерированный Copilot. Система использовала фрагмент из GPL-лицензированной библиотеки, что нарушило политику компании по открытому ПО. Инцидент заставил пересмотреть процессы ревью: теперь 78% команд требуют ручной проверки AI-кода перед мержем (слиянием).

Параллельно выяснилось, что Copilot в 40% случаев предлагает уязвимый код при работе с СУБД — это привело к взлому API стартапа через SQL-инъекцию. Такие кейсы показали, что ИИ пока не заменяет программистов, а требует от них новых навыков — критического анализа машинных предложений и понимания юридических аспектов кода.

2025: Современное состояние профессии

Современные рабочие станции программистов оснащены ноутбуками с процессорами Apple M4 (3 нм) или Windows-машинами на Snapdragon X Elite. Мониторы с разрешением 8К используются для разработки AR-приложений, а OLED-экраны с HDR стали стандартом для работы с графикой. Появляются первые экспериментальные IDE с нейроинтерфейсами, способные предсказывать код на основе анализа мозговой активности.

Среди языков программирования выделяется Mojo (2023) — «Python для GPU», набирающий популярность в сфере машинного обучения. Carbon как потенциальный наследник C++ пока остается в тени Rust. Квантовые языки вроде Q# и Cirq интересуют в основном энтузиастов и исследователей.

Профессия претерпела значительные изменения. ИИ стал не конкурентом, а помощником — по некоторым оценкам, около 60% рутинного кода в 2025 году (тесты, документация) генерируется автоматически. Знание английского языка стало важнее знания сложных алгоритмов — без него невозможно эффективно работать с современными AI-инструментами. Понятие «fullstack-разработчик» трансформировалось — теперь оно подразумевает владение фронтендом, одним бэкенд-языком и основами машинного обучения.

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

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

Ты уже программист, если читаешь это! Больше о кодинге тут.

Исследование охватило 80 млн коммитов на GitHub, проанализированных с помощью обученного классификатора на основе GraphCodeBERT. Он распознает, сгенерирована ли функция ИИ. В выборку попали 200 000 разработчиков из шести стран.

Для сравнения, в других странах картина выглядит так:

• США — 30,1%
• Германия — 24,3%
• Франция — 23,2%
• Индия — 21,6%
• Китай — 11,7%

Разработчики с меньшим стажем используют ИИ чаще: новички в среднем генерируют с помощью ИИ 41% кода, тогда как ветераны — около 28%.

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

Что это дает

Авторы также выяснили, что интенсивное использование ИИ увеличивает продуктивность: переход на 30% сгенерированного ИИ кода увеличивает число коммитов на 2,4%.

Кроме того, возрастает и исследовательская активность: разработчики начинают чаще использовать новые библиотеки и их комбинации — как ранее не использовавшиеся лично, так и вообще новые для экосистемы.

Что дальше

По оценкам авторов, уже сейчас ИИ приносит до $14,4 млрд ежегодной добавленной стоимости только в американской индустрии разработки софта.

А если экстраполировать более оптимистичные результаты из контролируемых экспериментов, цифра может достигать и $96 млрд в год.

Полный отчет доступен на arXiv.

Что такое pet-проект и зачем его защищать

Pet-проект (от английского pet — «домашний питомец») — тренировочный проект, который разработчик создаёт в свободное время по собственному желанию. Обычно их делают, чтобы освоить новую технологию, пополнить портфолио или поучаствовать в хакатонах.

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

Кроме того, защита pet-проекта — важный навык, который высоко ценится работодателями.

Рассмотрим основные правила кибербезопасности, которые нужно учитывать при работе над pet-проектом.

Безопасное управление секретами

Секреты — это чувствительные данные, такие как пароли, токены доступа, ключи API, SSH-ключи, сертификаты и другие данные, которые обеспечивают аутентификацию и шифрование. Если добавить секреты в код, злоумышленники могут получить полный контроль над вашей инфраструктурой.

Какие правила нужно соблюдать

• Не храните секреты в коде. Храните секреты в отдельных файлах env. и добавьте эти файлы в .gitignore, чтобы они не попадали в репозиторий.
• Придерживайтесь принципа минимальных привилегий. Каждый сервис должен иметь только те права, которые необходимы для выполнения своих задач.
• Регулярно обновляйте секреты. Меняйте токены и пароли периодически, особенно после обнаружения утечек или изменений в проекте.
• Используйте менеджеры секретов. Популярные сервисы: Doppler, HashiCorp Vault, AWS Secrets Manager, 1Password Developer Tools.
• Мониторьте утечки. Можно использовать такие инструменты, как GitGuardian, TruffleHog, Gitleaks.
• Шифруйте секреты. Используйте библиотеки типа cryptography в Python и подключайте шифрование на уровне операционной системы.

Безопасность CI/CD

Пайплайн CI/CD (Continuous Integration / Continuous Delivery) — автоматизированный процесс сборки, тестирования и развёртывания приложений. Он помогает автоматически интегрировать код и деплоить его на различные среды.

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

Способы защиты пайплайна

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

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

Сервисы мониторинга и логирования

Логирование — запись событий, ошибок и других данных о работе приложения в специальные файлы или базы данных. По сути, это дневник.

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

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

Примеры популярных сервисов

Logtail — простой инструмент для сбора и анализа логов, есть бесплатный тариф.

Papertrail — удобный сервис для быстрого поиска по логам, бесплатный план для небольших проектов (10 Мб в день).

Sentry — хорош для отслеживания ошибок в приложениях на клиентской стороне и сервере.

BetterStack — мониторинг доступности сайтов и серверов с бесплатными уведомлениями об инцидентах по почте, через SMS и Slack.

Grafana Cloud Free — мониторинг с красивыми дашбордами, бесплатный лимит ресурсов до 10 тыс. серий данных, 50 ГБ трафика.

Prometheus и Grafana — Prometheus собирает метрики, Grafana их визуализирует.

UptimeRobot — проверка доступности вашего проекта каждые 5 минут, бесплатный тариф на 50 мониторингов.

Бэкап и восстановление данных

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

Как сделать бэкап пошагово

1. Определите данные, которые необходимо бэкапить: какие данные критически важны, какие можно восстановить вручную.
2. Выберите место хранения: облачные сервисы, собственные серверы, внешние носители, Git-репозиторий.
3. Выберите тип бэкапа: при полном копируются все данные целиком, при инкрементном — изменения с момента последнего копирования, при дифференциальном — изменения с момента последнего полного бэкапа.
4. Настройте автоматизацию, чтобы не забывать делать бэкапы вручную. Можно использовать скрипты, планировщики задач или бэкап-сервисы.
5. Проверьте бэкап. Проведите тестовое восстановление.
6. Определите частоту бэкапа. Например, можно проводить полный бэкап раз в неделю и инкрементные бэкапы каждый день.
7. Защитите чувствительные данные.

Локальные туннели

При разработке pet-проекта может возникнуть необходимость показать результат внешнему миру. Кроме того, многие внешние сервисы, такие как платёжные системы и мессенджеры, тоже требуют «боевые» URL для отправки запросов. Однако открывать порты на своём устройстве напрямую небезопасно. Локальные туннели создают временный внешний URL-адрес без развертывания на реальном сервере.

Когда вы запускаете туннель через специальный инструмент, он:

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

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

Примеры инструментов

Ngrok — самый известный инструмент для быстрого создания туннелей. Есть бесплатный тариф.

Порты от VSCode — отличное решение для пользователей Visual Studio Code, удобно для быстрой демонстрации.

VK Tunnel — российская альтернатива, подходит для работы через VK Cloud.

Tuna и xTunnel — простые в использовании решения, есть бесплатные тарифы.

Чек-лист по инфобезу для тех, кто делает pet-проект

1. Регулярно обновляйте зависимости. Используйте автоматические инструменты, например, Dependabot или npm audit.
2. Настройте базовые HTTP-заголовки безопасности. Добавьте заголовки Content-Security-Policy, X-Frame-Options, Strict-Transport-Security, чтобы минимизировать риск XSS, Clickjacking и других атак.
3. Используйте бесплатные SSL-сертификаты. Подключите HTTPS через бесплатные сервисы, например, Let's Encrypt.
4. Очищайте и валидируйте ввод данных. Фильтрация и валидация данных защитит от SQL-инъекций и XSS.
5. Создайте отдельные учётные записи для разных сервисов. Не используйте одну и ту же учётную запись везде.
6. Минимизируйте доступы к базе данных. Если сервису нужно только читать, не давайте права на запись или удаление.
7. Используйте бесплатные инструменты для сканирования уязвимостей. Проверьте код через такие сканеры, как SonarQube Community Edition, Snyk, OWASP ZAP.
8. Делайте резервные копии. Настройте автоматические бэкапы базы данных и важных файлов.
9. Не храните секреты в коде. Используйте .env файлы и убедитесь, что они добавлены в .gitignore.
10. Включите двухфакторную аутентификацию (2FA). На всех сервисах, где это возможно, включите 2FA для дополнительной защиты.
    

А больше про разработку и все, что с ней связано, в нашем тг-канале!

Мы в Smart Engines занимаемся разработкой софта для распознавания самых разных документов — начиная от паспорта РФ, свидетельства о рождении и заканчивая первичкой вроде УПД или ТОРГ-12, а также банковских карт, номеров телефона и баркодов. Наши библиотеки написаны полностью с нуля (на плюсах), мы уделяем огромное внимание скорости алгоритмов, нейросетям (новым архитектурам, размеру и правильному применению) и оптимизации, за счет чего наш софт портируется на любые архитектуры и может быть использован на любой платформе.

Сегодня продолжим знакомиться через рассказ о нашем софте, на очереди вторая библиотека — Smart Document Engine и ее возможности работы с жесткими и гибкими формами.

Гибкие и жесткие формы

Вначале про сами формы: они могут быть «жесткими» и «гибкими». Жёсткие формы подразумевают, что положение всех объектов на форме может быть задано прямо в виде координат на шаблоне. Самое простое определение для жестких форм — они совпадают «на просвет». Возьмите пару листов А4 с распечатанной жёсткой формой, наложите друг на друга, и места расположения полей точно совпадут. Гибкие формы устроены гораздо сложнее, но все равно имеют свою характерную структуру и топологию.

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

Кстати, иногда вместо распознавания текста целиком достаточно просто ответить на вопрос «есть ли текст в выбранной области, и, если есть, то где»

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

Также существуют общие для подобных форм проблемы. Правильно интерпретировать галочки в чекбоксах, найти штрихкоды, правильно разметить табличные данные — есть куча проблем, каждая из которых имеет своё state-of-the-art решение и набор алгоритмов, над которыми нужно ломать голову.

Почему не LLM, хотя казалось бы

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

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

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

Вернёмся к библиотеке Smart Document Engine. Как уже говорилось выше, гибкие формы на то и гибкие, что исключительно геометрией на них не обойдёшься — вопрос местонахождения полей решается «на лету». На процесс взаимодействия с библиотекой это влияет в самом конце, на моменте работы с результатом. Перейдем к знакомству с интерфейсом на примере всё того же встраивания в андроид.

Встраивание

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

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

Как правило, результат распознавания представляют в виде json-объекта, но для наглядности лучше всего пользоваться html — особенно в случае, когда логические и физические поля имеют больше одного соответствия. Вот простенький генератор html на основе документа:

В результате получается удобная для взаимодействия html-страничка. Если добавить немного фантазии, то можно сразу сделать форму, в которой можно будет проверять и дополнять неуверенно распознанные поля — очень удобно в случае, если качество изображения плохое или документ плохо пропечатан.

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

На этом мы не заканчиваем, ждите новых статей!

Мы в Smart Engines занимаемся разработкой софта для распознавания самых разных документов – начиная от паспорта РФ, свидетельства о рождении и заканчивая первичкой вроде УПД или ТОРГ-12, а также банковских карт, номеров телефона и баркодов.

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

Объяснять (и хвастаться) проще всего на примере – покажем, как развернуть распознавание паспорта РФ прямо на устройстве на Android.

Зачем это всё?

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

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

Немного вводных

SDK Smart ID Engine – это библиотека, собранная под нативную платформу, конфигурационный бандл и обёртка для вызова функций библиотеки с помощью других языков программирования (в этой статье нам понадобится java).

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

• Движок распознавания. Он создаётся с указанием конфигурационного бандла и представляет собой что-то вроде “склада инструментов” для распознавания различных документов. Движок создаётся в самом начале, существует на всём протяжении жизни (приложения или хотя бы сценария, в котором используется распознавание). От него создаются следующие элементы интерфейса:

• Сессия распознавания. Это сам процесс распознавания конкретного физического объекта – паспорта, ВУ, СТС, загранпаспорта и других. Всего по состоянию на сегодняшний день мы поддерживаем более 3 тысяч типов документов. В сессию можно передать всего одно изображение, а можно - серию изображений последовательно (видеопоток), при этом после каждого нового распознавания результат будет уточняться, а так же на основе уверенности в результате будет приниматься решение, нужно ли распознавать дальше или лучше уже не будет.

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

• Настройки сессии. Они хранят список доступных для распознавания типов документов (сам по себе этот список определяется конфигурационным бандлом), дополнительную информацию о каждом документе, а также позволяют настроить процесс распознавания: задать список ожидаемых типов документов для сессии распознавания (кстати, если поставить *, то система сама определит тип документа из всех преднастроенных шаблонов), включить\выключить проверки признаков подлинности, задать таймаут для сессии распознавания и так далее. Настройки создаются перед созданием самой сессии и не могут редактироваться в процессе распознавания.

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

Беглого взгляда на этот интерфейс достаточно, чтобы понять, как его правильно встроить в приложение. При старте приложения (или сценария) создаем экземпляр движка, перед непосредственно распознаванием создаем настройки сессии и заполняем их, после чего при переходе на экран с превью камеры создаем саму сессию распознавания и “кормим” её кадрами до тех пор, пока сессия не затерминалится (= не решит, что “ей хватит”). После чего можно переходить к разбору результата распознавания.

Как это встраивается и работает

А теперь немного кода - покажем, как делается распознавание документа с помощью камеры устройства на Android. Полный код можно найти, перейдя по ссылке на GitHub, а ниже – наиболее интересные моменты.

Начнём с создания движка:

Объявим класс:

И приведём его имплементацию:

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

С имплементацией:

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

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

Теперь вы знаете, что встроить распознавание паспорта РФ в приложение для Android — намного проще, чем может показаться на первый взгляд.

Это далеко не единственный вариант использования нашего софта. Как минимум, помимо распознавания документов также можно сверять лица, проверять лицо на “живость”, организовывать распознавание двусторонних документов и еще много чего.

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

Если заинтересовались – добро пожаловать на наш сайт. И не расходимся, скоро расскажем еще много чего интересного!

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

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

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

Основные причины утечек

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

Разберем основные причины утечек.

Хардкодинг ключей в исходном коде

Пожалуй, самая распространенная и опасная практика — прямое внедрение API-ключей в исходный код приложения. Разработчики часто делают это для удобства тестирования, забывая удалить секретные данные перед релизом.

Особенно критично, когда ключи остаются:

• в конфигурационных файлах (config.php, .env);
• в закомментированных блоках кода;
• в тестовых сборках, которые по ошибке попадают в продакшен;
• в шаблонах и примерах кода.

Яркий пример — инцидент с Microsoft в 2023 году, когда утечка ключа MSA (Microsoft Account) через устаревший код позволила хакерам получить доступ к почтовым ящикам правительственных организаций США, включая Министерство торговли. Как показало расследование Microsoft Security Response Center, проблема возникла из-за ключа подписи, который продолжал использоваться в legacy-системах и попал в руки злоумышленников.

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

Случайные коммиты в публичные репозитории

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

Типичные сценарии:

• временное добавление ключа для отладки с последующим «удалением»;
• позднее добавление .env-файла в .gitignore;
• слияние веток с чувствительными данными;
• автоматические коммиты IDE и инструментов разработки.

В публичные репозитории GitHub ежедневно попадают сотни активных ключей — некоторые из них даже предоставляют доступ к платежным системам и базам данных.

Ошибки в настройке CI/CD

Автоматизированные системы сборки и деплоя могут невольно способствовать утечкам:

• передача ключей через аргументы командной строки;
• попадание секретов в логи сборки;
• неправильная настройка переменных окружения;
• хранение ключей в незащищенных артефактах;
• избыточные права доступа для CI-сервисов

Особенно опасны ситуации, когда CI-пайплайн настроен на публикацию артефактов сборки, включающих конфигурационные файлы с ключами.

Логирование чувствительных данных

Разработчики часто добавляют отладочный вывод, который затем забывают удалить:

• console.log (“API Key: “, secretKey);
• погирование полных HTTP-запросов с заголовками авторизации;
• дампы ошибок с конфиденциальными данными;
• журналирование параметров запросов.

Такие записи могут попасть в системные логи, инструменты мониторинга (Kibana, Grafana), браузерную консоль (для фронтенд-приложений) и облачные сервисы хранения логов.

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

Неправильное управление доступами

Часто проблема кроется не в технических решениях, а в процессах управления:

• отсутствие ротации ключей — некоторые из них используются годами;
• использование одних ключей для разных сред (dev/stage/prod);
• избыточные права доступа — принцип минимальных привилегий не соблюдается;
• хранение ключей в общих хранилищах и чатах;
• отсутствие аудита использования ключей.

Часто утечки происходят из-за совокупности нескольких перечисленных факторов. Например, типичный сценарий: ключ сначала попадает в код, затем в репозиторий, обнаруживается в логах CI-системы, а потом оказывается в общем доступе из-за неправильных настроек прав.

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

Безопасное хранение и использование API-ключей

API-ключи — это критически важные элементы инфраструктуры, и их утечка недопустима. Чтобы минимизировать риски, важно соблюдать несколько принципов.

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

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

Для более сложных сценариев стоит рассмотреть специализированные хранилища секретов, такие как HashiCorp Vault, AWS Secrets Manager или Doppler. Они не только обеспечивают безопасное хранение, но и добавляют функции ротации ключей, аудита доступа и интеграции с системами мониторинга.

• Vault динамически генерирует временные ключи для отдельных сервисов, сводя к нулю риск их повторного использования. Однако такие решения требуют настройки и контроля — при некомпетентном подходе компании сталкиваются с ошибками конфигурации при внедрении.
• AWS Secrets Manager — инструмент, который позволяет централизованно хранить конфиденциальную информацию, извлекать ее, управлять доступом, ротировать и мониторить.
• Doppler — кроссплатформенное решение с удобным интерфейсом и историей изменений. Особенно популярно среди стартапов.

Главное преимущество таких систем — централизованное управление. При увольнении сотрудника или компрометации ключа его можно отозвать мгновенно для всех сервисов.

Шифрование обязательно как при передаче, так и при хранении. Даже если злоумышленник получит доступ к базе данных или логам, зашифрованные ключи останутся бесполезными без расшифровки. Современные стандарты, такие как AES-256 или алгоритмы на основе PQC (постквантовой криптографии), уже встроены в большинство облачных провайдеров. Но важно не забывать про управление ключами шифрования (KMS): их утечка сведет на нет всю защиту.

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

Наконец, мониторинг помогает обнаружить утечку до того, как ею воспользуются. Инструменты вроде AWS GuardDuty или открытый вариант Falco отслеживают подозрительные операции: неожиданные запросы из новых регионов, аномальную частоту вызовов API или попытки доступа к заблокированным эндпоинтам.

Важно: ни один метод не дает 100% защиты API. Нужно комбинировать подходы и регулярно аудировать систему. Безопасность API-ключей — это не разовая настройка, а процесс, требующий регулярного пересмотра политики адаптации к новым угрозам.

Лучшая практика работы с ключами

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

Вот самые эффективные практики:

• Первое правило — никогда не оставлять ключи в коде. Даже если репозиторий приватный, всегда существует риск случайной публикации или утечки через резервные копии. Инструменты вроде pre-commit хуков помогают предотвратить подобные инциденты, автоматически проверяя изменения перед отправкой. Например, скрипт может сканировать коммиты на наличие строк, похожих на ключи, и блокировать их сохранение.
• Регулярная ротация снижает потенциальный ущерб от возможной компрометации. Ключи, которые не обновлялись годами, представляют особую опасность. Современные системы, такие как HashiCorp Vault или AWS Secrets Manager, позволяют автоматизировать этот процесс.
• Принцип минимальных привилегий должен применяться ко всем ключам. Если токен нужен только для чтения данных, он не должен иметь прав на запись или удаление. Ограничение области действия каждого токена — простой, но эффективный способ снизить риски.
• Мониторинг использования помогает выявлять аномалии в реальном времени. Неожиданные всплески активности, запросы из новых регионов или попытки доступа к неиспользуемым методам API — все это сигналы потенциальной компрометации. Инструменты типа AWS CloudTrail или Elastic SIEM позволяют отслеживать подобные события и оперативно реагировать на угрозы.
• Обучение команды не менее важно, чем технические меры. Регулярные тренинги и чек-листы помогают поддерживать уровень осведомленности.

Централизованное управление упрощает контроль за ключами. Когда все токены хранятся в одном защищенном месте, проще отслеживать их использование, вовремя обновлять и отзывать при необходимости. Это также облегчает аудит, который часто требуется для соответствия стандартам вроде PCI DSS или ГОСТ Р 56939-2024.

Процесс отзыва должен быть максимально оперативным. В случае компрометации ключа важно не только сгенерировать новый, но и убедиться, что старый уже недействителен. Некоторые сервисы, например Google Cloud, позволяют автоматически блокировать ключи при обнаружении подозрительной активности.

Автоматическое выявление утечек

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

Эффективный мониторинг начинается с проверки исходного кода. Такие инструменты, как GitGuardian и TruffleHog, сканируют git-репозитории, включая историю коммитов, на наличие случайно оставленных ключей. Они используют комбинацию шаблонов и энтропийного анализа, что помогает находить даже замаскированные секреты. Интеграция этих проверок в CI/CD-пайплайны позволяет перехватывать потенциальные утечки до их попадания в основную ветку.

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

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

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

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

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

Как реализовать безопасный доступ на фронтенде

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

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

Вместо этого рекомендуется использовать архитектурный паттерн Backend-for-Frontend (BFF), когда фронтенд общается с промежуточным сервером, а тот уже взаимодействует с основными API. Так ключи остаются на защищенной стороне, а клиент получает только временные токены с ограниченным сроком действия.

Для аутентификации пользователей оптимально подходит OAuth 2.0 с расширением PKCE (Proof Key for Code Exchange). Этот механизм обеспечивает безопасный обмен токенами даже в публичных клиентах. В отличие от обычного потока авторизации, PKCE добавляет дополнительный уровень защиты через одноразовые ключи верификации, что предотвращает перехват кодов злоумышленниками.

В случаях, когда фронтенду необходим доступ к публичным API без аутентификации пользователя, стоит использовать ограниченные токены. Например, для картографического сервиса можно выпускать ключи, разрешающие только чтение данных с жестким лимитом запросов. Такой подход применяют многие крупные платформы, включая Яндекс.Карты. Даже если токен будет скомпрометирован, его полезность для злоумышленников окажется минимальной.

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

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

Последний рубеж безопасности — верификация среды выполнения. Современные библиотеки анализируют параметры браузера, выявляя признаки эмуляции или автоматизации. Это позволяет блокировать запросы от ботов и скриптов, пытающихся массово собирать данные через API. Такой подход особенно важен для финансовых сервисов и платформ с ценной информацией.

Главный вывод: фронтенд действительно представляет угрозу для безопасности API-ключей, но грамотная архитектура и продуманные механизмы авторизации позволяют снизить риски до приемлемого уровня. Ключевой принцип защиты API — минимализм в правах доступа и максимальное делегирование ответственности серверной части.

Хочешь писать код, который не стыдно показывать? Всё для фронтендеров и бэкендеров в одном месте.

Что такое DevSecOps

DevSecOps образовано от слов development (разработка), security (безопасность) и operations (эксплуатация или операции). Это подход к разработке приложений, при котором безопасность учитывается на каждом этапе CI/CD, чтобы минимизировать стоимость и повысить скорость исправления ошибок. К нему относятся не только инструменты, по типу различных сканеров библиотек и кода, но и определённые договоренности между разработчиками, DevOpsами и безопасниками.

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

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

Лицо врага

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

Процент небезопасных приложений в исследованиях российских компаний, занимающихся защитой приложений, в разные годы отличается и зависит от отрасли. Так, про финансовую отрасль Positive Technologies в 2015 говорили о 90%, в 2016 г. — о 71%, а в 2017 – о 56%. Если замеченный Positive Technologies тренд защищенности приложений финансового сектора сохранился бы в тех же пропорциях, то сегодня процент был бы ещё меньше. Однако исследование «Стингрей Технолоджис» 2024 г. говорит о 56% опасных приложений в финтехе.

Ассоциация ФинТех проводила исследование, и в 2025 году 82% компаний назвали разработку на базе открытого исходного кода оптимальной с точки зрения сроков и удобства внедрения. При этом использование таких библиотек несёт в себе риски на протяжении всего жизненного цикла продукта, и риски для данных, которые используются в приложениях.

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

Какие есть риски для данных

Основные риски для данных обычно связаны с нарушением их конфиденциальности. В процессе разработки важно проводить тесты, а для этого нужны данные, причём не сильно отличающиеся от настоящих. Также важен их объём, иначе не получится провести нормальные нагрузочные тесты. Выгрузка реальных данных — самый заманчивый вариант. Но если для стендов Dev и Test используются облачные среды или в процессах разработки задействованы подрядчики, то некоторые организации могут на такое не решиться из-за требований к ИБ. И это логично, поскольку в Prod есть комплексный подход к защите, а на стендах Dev и Test меры защиты могут быть минимизированы.

Один из способов снизить риски — использовать системы маскирования: они помогают обезличить персональные и финансовые данные (например, номера карт и счетов). Сейчас действует приказ Роскомнадзора №996 от 2013 г., но, необходимо отметить, уже опубликован проект приказа Роскомнадзора «Об утверждении требований к обезличиванию персональных данных и методов обезличивания персональных данных», который его заменит.

Контейнеры стали стандартом для запуска приложений, но вместе с удобством они приносят и риски — особенно в защите данных. Да, контейнеризация улучшает доступность и масштабируемость, но не решает проблем с конфиденциальностью и целостностью «из коробки». На российском рынке уже существуют отечественные платформы контейнеризации, например, Штурвал, DeckHouse, в которых сразу учтены механизмы безопасности либо есть накладные средства для kubernetes от Luntry, PT, Kaspersky и т.д.

Как внедрять DevSecOps

DevSecOps — подход, при котором безопасность вшита в код на всех этапах. Уязвимости ищут не в самом конце, а прямо по ходу разработки: в pull request'ах, CI/CD и при работе с зависимостями. Такой подход требует, чтобы разработчики, DevOps и специалисты по безопасности работали как одна команда, а не передавали задачи «по цепочке» в последний момент.

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

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

Cloud Native — это подход к разработке приложений, изначально ориентированных на работу в облачной среде и интеграцию с облачными сервисами. Сегодня большинство новых решений проектируются именно так. Для безопасной работы таких приложений важно не только адаптировать архитектуру под облако, но и выстраивать взаимодействие с провайдером: от заключения договора до работы с API. Облачные провайдеры часто предлагают инструменты, которые помогают встроить безопасность в процесс разработки. У многих есть готовые сервисы Kubernetes, в том числе с учётом требований информационной безопасности. Также доступны решения уровня WAF и инструменты анализа безопасности кода (например, SAST, DAST, SCA) — иногда по подписке, как в случае с некоторыми российскими платформами.

Начать можно с внедрения бесплатных решений — например, SAST, SCA и DAST, которые уже можно интегрировать в текущий DevOps-стек. Когда команда понимает ценность и пользу этих проверок, можно переходить к платным продуктам с расширенными возможностями.

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

Однако не стоит думать, что это финальная точка. DevSecOps — постоянный процесс: мониторинги, улучшения, обновления стандартов ИБ и поиски идеальных практик.

Цена вопроса

Вернемся к примеру с салатом. Все любят разное: кто-то — «цезарь», другой – «селёдку под шубой». Разные языки программирования, риск-аппетиты в командах в отношении принятия требований безопасности, цели внедрения DevSecOps (кому-то нужно в итоге получить сертификат, а кому-то страшно за конечный продукт и важно обеспечить реальную максимальную безопасность) — всё это не позволяет создать коробочный продукт с фиксированной ценой, хотя на рынке есть те, кто предлагает поставить 2-3 сканера и удовлетвориться этим, назвав DevSecOps.

При внедрении DevSecOps стоит учитывать затраты на разделение сред Dev, Test и Prod — это не входит в концепцию по западным лекалам. Однако от руководства компаний-клиентов нам часто поступают запросы на усиление безопасности разработки, поскольку разработчик перепутал стенд, после чего важнейшие системы компании пострадали. Вынести в облако Dev и Test и оставить у себя Prod кажется хорошей идеей (или наоборот). Для некоторых она способна полностью решить вышеупомянутую проблему.

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

Сканеры библиотек могут быть бесплатными и платными

Статический анализ кода (SAST) — может быть реализован через бесплатные инструментов, таких как SonarQube, semgrep, gitleaks/trufflehog, но есть и платные – PVS-Studio, Svace, Solar appScreener и т.д.

Динамический анализ кода (DAST) — можно осуществить с помощью бесплатных инструментов OWASP ZAP, Nuclei, NMAP, Burp Suite или платных, например, PT BlackBox.

И другие элементы DevSecOps (анализ мобильных приложений, API и т.д.) можно реализовать с использованием платных или бесплатных инструментов.

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

В процессы Ops можно также включить элемент безопасности WAF (Web Application Firewall). Доступны как бесплатные варианты (например, ModSecurity), так и платные (PTAF, Гарда WAF, Вебмониторэкс и т.д.).

Начинать стоит с бесплатных инструментов, поэтапно внедряя их в CI/СD, взаимодействуя с командой DevOps. По сути, DevSecOps – это консалтинг с возможностью применения платных инструментов, если к ним готова команда DevOps. И мы абсолютно уверены, что ради его внедрения точно не стоит жертвовать командой разработки. Кстати, для трактовки отчётов сканеров зачастую используются те же консалтеры, что внедряли DevSecOps.

Нельзя забывать и об обучении команды практикам безопасной разработки. Тут следует упомянуть, что сканеры типа CheckMarx наглядно демонстрируют эксплуатацию уязвимостей. Часто вендоры сводят DevSecOps к сканерам, консалтеры — к процессам, а про людей и их обучение — забывают.

Просто прочитать пару статей про DevSecOps — недостаточно. Команда должна понимать реальные уязвимости: как они появляются, чем опасны и как их избежать. Сейчас в России появляются обучающие платформы, которые показывают это на практике — с примерами уязвимого кода, проблемных библиотек и типовых ошибок. Но останавливать разработку ради курсов на две недели — нереально. Поэтому лучше встроить обучение в рабочий ритм: хотя бы один час в неделю на всю команду. Это немного, но в долгосрочной перспективе даёт устойчивую культуру безопасности. Стоимость зависит от числа участников и выбранных курсов — но в любом случае это обойдется дешевле, чем инцидент в проде.

Требования к безопасной разработке ПО

Уже сейчас требования по безопасной разработке (а если есть DevOps, то по сути это требования к внедрению DevSecOps) появились в:

• ГОСТ Р 57580.1-2017: СМЭ.6, СМЭ.7, ЖЦ.4, ЖЦ.5, ЖЦ.6, ЖЦ.7. ЖЦ.24;
• PCI DSS 4.0.1: 6.2, 6.3, 6.5;
• ГОСТ Р ИСО/МЭК 15408-3-2013: ALC_CMC, ALC_CMS, ALC_DEL, ALC_DVS, ALC_FLR, ALC_LCD, ALC_TAT.

Если речь идет о средствах защиты информации (СЗИ), которые нужно будет сертифицировать по требованиям ФСТЭК или ФСБ, важно помнить: инструменты, которые вы используете для сканирования кода, тоже должны быть сертифицированы. Иначе при испытаниях возникнут сложности — лаборатории не примут результаты без официальной документации.

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

Куда будет развиваться DevSecOps

Очевидно, что DevSecOps ждет намного более массовое внедрение и развитие — устранить проблемы на этапе разработки дешевле, чем позже латать пробоины в ИБ.

Скорость появления эксплоитов растёт — и это прямая угроза. Если раньше у команд была пара месяцев, чтобы закрыть уязвимость до начала атак, то теперь — всего несколько дней. Исследование Google показало: в 2018–2019 годах эксплойты появлялись в среднем через 63 дня после патча, в 2020 — через 44, в 2021 и 2022 — уже через 32, а в 2023 году — всего через 5 дней. А с развитием ИИ этот срок может сократиться ещё сильнее.

В России сильные программисты, но собственные новации в сфере ИБ традиционно появляются позже, чем на Западе — чаще в виде адаптаций или копий существующих решений. Однако импортозамещение меняет ландшафт: появляются десятки отечественных продуктов, которых просто нет в зарубежных базах уязвимостей. А значит — и в популярных сканерах кода они тоже не учтены. Это открывает окно возможностей: российские команды смогут развивать собственные инструменты безопасности — от сканеров и доверенных репозиториев до платформ для DevSecOps. Плюс эти принципы начнут постепенно проникать в программы обучения в вузах.

Уже существуют реестр отечественного ПО (ведется под патронажем Минцифры), реестр сертифицированных средств защиты ФСТЭК России, реестр ФСБ России, реестр отечественных ПАК (ведётся Минпромторгом). Чтобы попасть туда в ближайшие годы, разработчики должны будут не просто заявлять о безопасности, а доказывать на практике — в процессах, документации и архитектуре. Это станет драйвером роста: инструменты для безопасной разработки будут развиваться, а вместе с ними — и культура DevSecOps.

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

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

Носители информации: эволюция

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

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

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

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

Первые носители информации были аналоговыми и требовали физического контакта. Бумага, перфокарты, магнитная лента — все это работало по принципу «записал один раз и следи, чтобы не испортилось». Но с появлением продвинутой техники понадобилось что-то более гибкое, что позволило бы не только хранить, но и быстро перезаписывать данные. Так началась эра магнитных носителей.

Магнитные кассеты использовались не только для записи и воспроизведения музыки, но и стали первым массовым способом хранения цифровой информации для домашних компьютеров. Пользователи писали на пленку игры типа Pacman или Dizzy, а также прикладные программы для компьютеров АТМ Турбо и Spectrum.

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

Затем пришли дискеты, и мир узнал, что такое «портативность» в цифровом смысле. Если кассеты были еще слегка похожи на предыдущее поколение (массивные бобины), то флоппи-диски уже вполне выглядели как технология из будущего. Первые модели хранили жалкие 80 КБ, но к 1980-м емкость выросла до 1.44 МБ — достаточно для текстовых документов и простейших программ. Правда, надежность оставляла желать лучшего: магнитные диски боялись пыли, влаги и просто времени.

Оптические носители, такие как CD и DVD, стали следующим шагом. Они предлагали куда больший объем (от 700 МБ до 4.7 ГБ) и теоретически — вечное хранение данных. Правда, на практике царапины, солнечный свет и некачественные болванки приводили к быстрому обнулению файлов. Но главный минус — эти диски нельзя было просто так перезаписать. CD-RW и DVD-RW решили проблему, но их распространение было медленным: люди уже начали привыкать к тому, что данные можно копировать бесконечно.

Конец XX века принес еще несколько любопытных форматов вроде ZIP-дисков, которые пытались заменить флоппи, но проиграли войну, поскольку оказались слишком дорогими и неудобными.

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

Как хранили и передавали информацию до флешек и облаков

Ненадежные, но безальтернативные дискеты, вмещавшие меньше, чем сегодняшний снимок экрана; кассеты с уязвимой магнитной пленкой; CD с их обманчивым обещанием «вечного хранения». Все эти носители в свое время считались если не революционными, то прогрессивными и передовыми. Нынешнему поколению будет полезно узнать, где хранили музыку, видео, софт и другие данные их родители и почему эти волшебные изобретения больше не используются массово.

Аудио и видеокассеты: не забудьте перемотать на начало

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

Магнитная лента появилась задолго до кассет — первые бобинные магнитофоны использовались еще в 1940-х, но они были громоздкими и дорогими. Все изменилось в 1963 году, когда компания Philips представила компакт-кассету — небольшой, удобный и, что важно, дешевый формат. В отличие от винила, кассеты можно было записывать повторно, носить с собой и даже ронять без катастрофических последствий.

К 80-м годам кассеты стали основным способом слушать музыку. Их продажи в США достигли пика в 442 миллиона штук в 1990 году, но затем началось стремительное падение — CD-диски предлагали лучшее качество звука и отсутствие изматывающей перемотки. Однако кассеты не исчезли полностью: даже в 2012 году в Штатах продали 13 миллионов штук, в основном благодаря автолюбителям, чьи старые машины были оборудованы кассетными магнитолами. В России формат держался примерно до середины 2000-х, после чего кассеты почти исчезли из обихода.

Пока аудиокассеты правили балом в музыке, VHS делал то же самое с видео. Этот формат, появившийся в 1970-х, быстро вытеснил конкурентов (например, Betamax от Sony) благодаря простоте и доступности. Видеомагнитофон стал почти обязательным устройством в каждом доме, а прокат кассет — целой индустрией.

Но у VHS были свои причуды:

• Длинный фильм на двухчасовой кассете мог закончиться в самый напряженный момент, заставляя зрителя в недоумении хлопать глазами.
• Качество изображения ухудшалось с каждой перезаписью, превращая картинку, над которой так трудилась съемочная группа, в движения размытых или крупнозернистых силуэтов.
• Размагничивание, скручивание ленты и вечная борьба со «снегом» и полосами на экране — все было неотъемлемой частью пользовательского опыта.

Несмотря на это, VHS формат продержался до начала 2000-х, пока его не вытеснили DVD, а затем и стриминговые сервисы.

Магнитная лента использовалась не только для музыки и фильмов — в 1980-х она стала первым массовым носителем данных для домашних компьютеров. Владельцы ZX Spectrum и Commodore 64 загружали программы с аудиокассет, подключив магнитофон к компьютеру. Процесс напоминал шаманский ритуал: нужно было выставить правильный уровень громкости, надеяться, что маг не зажует ленту, и ждать несколько минут, пока игра загрузится (если, конечно, в середине не возникала ошибка, заставляющая начинать все сначала).

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

Казалось бы, эпоха магнитной ленты бесповоротно миновала, но это не совсем так. В дата-центрах до сих пор используют ленточные библиотеки (например, LTO), потому что они дешевы, энергоэффективны и отлично подходят для долгосрочного хранения больших объемов данных. Современные картриджи LTO-9 вмещают до 45 ТБ информации — это в тысячи раз больше, чем могла предложить кассета 1980-х.

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

Флоппи-диски (дискеты): 1,4 Мб славы

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

Флоппи-диски, или просто дискеты, стали символом компьютерной революции 1980-1990-х: они были везде, их боялись потерять, ими обменивались, как сейчас ссылками, и их регулярно проклинали, когда на экране возникало сообщение «Диск не отформатирован».

Первая дискета, представленная IBM в 1971 году, была 8-дюймовой и вмещала смехотворные по современным меркам 80 КБ данных. Она создавалась как альтернатива перфокартам — более надежная и удобная, но по-прежнему громоздкая. К середине 1980-х индустрия перешла на 5,25-дюймовые гибкие диски, а затем и на 3,5-дюймовые, которые стали стандартом. Последние, кстати, были не такими уж «гибкими» — прочный пластиковый корпус защищал магнитный диск внутри, хотя слово «флоппи» (от английского floppy — «гибкий») так и осталось в названии.

Объем памяти рос медленно: если в 1984 году дискета на 3,5 дюйма хранила 720 КБ, то к 1987-му — уже 1,44 МБ. Этого хватало для текстовых документов, простых программ и даже некоторых игр. Microsoft Word 2.0, выпущенный в 1991 году, умещался на одной дискете, а его современный аналог требует около 4 ГБ — в 3000 раз больше.

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

Еще одна проблема — ограниченный срок жизни. Даже идеально хранимая дискета могла потерять данные через 5-10 лет из-за размагничивания. Архивы на флоппи требовали регулярного перезаписывания, что превращало хранение информации в постоянную головную боль.

В 1980-х развернулась настоящая битва форматов. Компания Apple сделала ставку на 3,5-дюймовые дискеты, в то время как IBM и другие производители первое время держались за 5,25 дюймов. Победил, как известно, меньший размер — отчасти благодаря тому, что новые носители были прочнее и компактнее.

Любопытно, что следы дискетной эпохи до сих пор встречаются в цифровом мире. Буква «A:\» в Windows, которая изначально обозначала дисковод, осталась в системе как дань традиции. Иконка «Сохранить» во многих программах до сих пор изображает флоппи-диск, хотя большинство современных пользователей и в руках-то его никогда не держали.

К началу 2000-х дискеты начали стремительно исчезать. В 2011 году компания Sony, последний крупный производитель, прекратила их выпуск. Но, как это часто бывает, технология не умерла полностью.

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

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

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

Сиди и Дивиди: эпоха лазерного ренессанса

В конце 1990-х дискеты уже выглядели архаично, а облачных хранилищ еще не существовало. На сцену вышли оптические диски — сначала скромные CD на 700 МБ, после — DVD на 4,7 ГБ, а затем и Blu-ray с их 50 ГБ. В определенный период записать фильм на болванку считалось технологическим подвигом. Нужно было также красиво написать название на внешней стороне специальным маркером.

Изначально компакт-диски создавались для музыки — первый коммерческий CD выпустили в 1982 году с записью альбома ABBA «The Visitors». Объем в 650 МБ (74 минуты аудио) выбрали не случайно: разработчики из Sony и Philips хотели, чтобы на один диск целиком поместилась Девятая симфония Бетховена. К концу восьмидесятых большинство звукозаписывающих компаний перешли на CD-формат.

Когда технологию адаптировали для компьютеров (CD-ROM), эти же 700 МБ стали стандартом для софта, игр и даже операционных систем, например, Windows 95.

Запись CD представляла собой сложную процедуру . Программа Nero Burning ROM с ее интерфейсом, напоминающим кабину пилота, требовала идеально настроенного буфера записи. Ошибка «Buffer underrun» означала, что диск испорчен, а 30-50 рублей за болванку (по меркам 2000-х — немалая сумма) летели в мусорку.

Когда в 1996 году появились DVD, их емкость в 4,7 ГБ казалась фантастической. Почему не 5? Все просто: инженеры Sony и Philips изначально планировали 5 ГБ, но пришлось пожертвовать частью объема ради совместимости с форматом CD. Впрочем, даже 4,7 ГБ хватало для фильмов в приличном качестве — пиратские копии расходились быстрее, чем студии успевали считать убытки.

Киноиндустрия быстро поняла угрозу и начала войну с пиратством. На диски добавляли защиту вроде SecuROM и StarForce, которая не только мешала копированию, но и могла вывести из строя дисковод. Пользователи в ответ придумывали хитрости: от скотча на краю диска до специальных программ, которые «прожигали» защитные сектора.

В середине 2000-х разгорелась война форматов высокой четкости: Blu-ray от Sony и HD DVD от Toshiba. Технически Blu-ray был лучше — большая емкость (50 ГБ против 30 ГБ у HD DVD), но исход противостояния решил не этот фактор. Sony, которая владела киностудией Columbia Pictures, обеспечила Blu-ray эксклюзивными релизами. А когда за синий формат неожиданно выступила индустрия фильмов для взрослых (на тот момент — один из главных драйверов продаж любых носителей), судьба HD DVD была предрешена.

К 2010-м оптические диски начали сдавать позиции. Скорость интернета росла, стриминговые сервисы набирали популярность, а производители ноутбуков массово отказывались от дисководов. Последний гвоздь в крышку гроба забила Apple, выпустив в 2012 году MacBook Pro без CD-привода — тогда это казалось смелым шагом, а сегодня воспринимается как норма.

Но диски не исчезли полностью. Blu-ray до сих пор используют для фильмов в 4К, а некоторые госструктуры предпочитают архивные DVD — они дешевы и, в отличие от флешек, не подвержены спонтанному размагничиванию. Да и любители ретро-техники продолжают охотиться за редкими релизами игр на CD — например, оригинальная Half-Life на диске сегодня стоит дороже, чем в Steam.

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

Почему все это исчезло

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

Три причины краха:

• Первая и главная — объем. В 1990-х 1,44 МБ дискеты хватало для текстовых документов, но уже к началу 2000-х этого было недостаточно даже для одной MP3-песни. CD на 700 МБ казались спасением, но и они быстро устарели, когда размеры софта перевалили за гигабайты. Современные игры и видеофайлы просто не поместились бы на десятках дисков, которые пришлось бы таскать с собой.
• Вторая причина — скорость. Загрузка программы с кассеты занимала минуты, запись DVD — десятки минут, а копирование файлов с дискеты напоминало медитацию. Когда на смену пришли USB-накопители с их мгновенным доступом к данным, терпеть эти задержки стало невозможно.
• Наконец, надежность. Магнитные ленты размагничивались, дискеты боялись кофе и магнитов, а царапины на CD превращали их в елочные украшения. Потерять данные было проще, чем сохранить — особенно если учесть, что резервные копии требовали такого же ненадежного носителя.

Некоторые архаичные носители до сих пор используются там, где важнее стабильность, а не прогресс. В авиации, например, часть бортовых систем Boeing 747 до недавнего времени обновлялась через 3,5-дюймовые дискеты — потому что проверенная временем технология надежнее экспериментальных решений.

Промышленные станки, медицинское оборудование и даже банковские системы иногда работают на технологиях 1980-х просто потому, что их модернизация стоит дороже, чем покупка партии старых дискет на eBay. А энтузиасты ретро-компьютеров сознательно используют кассеты и флоппи-диски — для них это не просто носители, а часть культурного кода.

Что мы потеряли и что приобрели

Физические носители учили нас ценить данные. Когда файл нельзя было скопировать в два клика, а каждый мегабайт занимал место, люди тщательнее подходили к хранению информации. Переписка кассет требовала времени, коллекцию CD бережно держали на книжных полках, стирая пыль с футляров, а игры на 10 дискетах устанавливали с замиранием сердца — вдруг последняя окажется битой.

Сегодня данные стали абстрактными. Мы не держим их в руках, не боимся потерять из-за царапины и даже зачастую не знаем, на каком именно сервере они лежат. Это удобно, но лишает нас того самого «тактильного» отношения к информации.

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

Флешки, SD-карты и облака: вы находитесь здесь — что дальше

Флешки, которые еще недавно казались чудом технологий, уже выглядят архаично на фоне облачных хранилищ. SD-карты, вмещающие терабайты информации, размером не больше ногтя на мизинце. Но что дальше?

Твердотельные накопители, основанные на кремниевых чипах, приближаются к физическим пределам. Производители научились упаковывать данные невероятно плотно — современные 3D NAND-чипы содержат до 200 слоев памяти. Однако закон Мура (формулирующий неизбежность технологического прогресса) хотя и универсален, имеет определенные физические ограничения: стоимость новых фабрик по производству микросхем измеряется десятками миллиардов долларов.

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

Будущее, которое уже тестируют в лабораториях:

• ДНК-хранилища. В 2017 году гарвардские ученые записали на ДНК кишечной палочки GIF-анимацию и изображение. Технология CRISPR позволяет редактировать геном, превращая его в биологический жесткий диск. Пока процесс дорогой и медленный, но потенциал огромен: один грамм ДНК может хранить 215 петабайт данных — эквивалент 14 тысяч современных SSD.
• Молекулярные диски. Исследователи из Университета Брауна (Провиденс, США) создали прототип накопителя, где информация кодируется органическими молекулами. Метод напоминает древние глиняные таблички, только вместо клинописи — бинарный код из присутствия или отсутствия конкретных молекул.
• Кварцевые кристаллы. Технология «5D-памяти» использует фемтосекундные лазеры для записи данных в кварцевое стекло. Такие носители выдерживают температуру до 1000°C и могут хранить информацию миллиарды лет. В 2018 году Илон Маск отправил в космос Tesla с кварцевым диском, содержащим трилогию А. Азимова «Основание».
• Арктические архивы. На Шпицбергене уже работает «Арктический мировой архив», где данные хранятся на специальной пленке в стальных контейнерах. Туда поместили исходники GitHub, цифровое искусство и даже конституции некоторых стран — на случай глобальной катастрофы.

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

Ты точно программист, если читаешь это! Больше мемов, инсайтов и боли кодеров тут.

Больше новостей — в нашем тг-канале «Представляешь»

Новый API станет частью стандартной библиотеки Java и будет следовать принципу «батарейки в комплекте», который предполагает, что базовые функции должны быть доступны без внешних зависимостей.

Основные особенности

Простой интерфейс

Новый API будет включать минимальный набор классов для работы с JSON, включая:

• JsonValue — базовый интерфейс для всех JSON-значений;
• JsonObject — коллекция ключ-значение;
• JsonArray — упорядоченный список значений;
• JsonString — строковое значение;
• JsonNumber — числовое значение;
• JsonBoolean — логическое значение;
• JsonNull — пустое значение.

Вот как это будет выглядеть:

Пример использования

API будет поддерживать базовые операции, такие как разбор строк JSON и преобразование значений:

Со временем, по мере добавления новых возможностей для сопоставления паттернов (pattern matching) в Java, этот код станет еще более лаконичным.

Работа с числами

Поскольку JSON не различает целые и десятичные числа, новый API будет предлагать несколько способов работы с числами:

1. Получение строкового представления числа.
2. Преобразование строки в BigDecimal для точной работы с десятичными числами.
3. Преобразование в стандартные числовые типы Java (Long, Double, BigInteger) с автоматическим выбором подходящего типа.

Совместимость и производительность

Первая версия прототипа уже доступна в sandbox-репозитории OpenJDK.

Несмотря на раннюю стадию разработки, она успешно прошла большинство тестов из JSONTestSuite, за исключением случаев с дублирующимися ключами, которые намеренно запрещены для упрощения обработки JSON-объектов.

Дальнейшие шаги

Разработчики планируют оформить предложение по улучшению языка (JEP) для включения нового API в будущие версии JDK.

Это может быть обновление существующего JEP 198 (Light-Weight JSON API) или полностью новый документ.