Куда должен вести пуш

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

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

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

Как проверить переход при разном состоянии приложения

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

• Приложение закрыто. При холодном старте оно запускается и загружается, после чего должно продолжить переход к экрану из уведомления. Во время проверки проследите, куда пользователь попадает по завершении запуска.
• Приложение работает в фоне. Здесь проверяют возвращение из свёрнутого приложения и открытие целевого экрана. При действующей сессии пользователь должен продолжить работу в приложении; дополнительную перезагрузку при открытии пуша стоит разобрать с командой.
• Телефон заблокирован. Откройте уведомление с экрана блокировки и разблокируйте устройство с помощью Face ID или PIN-кода. После этого маршрут к нужному экрану должен сохраниться.
• Пользователь уже работает в приложении. Полученное уведомление открывают во время активной работы. Проверьте, как переход вписывается в текущую навигацию и вызывает ли он перезагрузку приложения.

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

Что происходит после повторного входа

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

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

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

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

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

Что показать, если нужный экран недоступен

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

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

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

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

Как проверить одну ссылку в разных каналах

Один диплинк может использоваться в пушах, рекламных баннерах, письмах и СМС. Ссылку также размещают в QR-кодах, социальных сетях и мессенджерах. Команда должна проверить переход из каждого канала, где эта ссылка используется.

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

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

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

Как организовать работу с диплинками

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

В запись о каждом диплинке можно включить следующие поля:

• название или ID диплинка;
• цель перехода;
• тип диплинка;
• параметры;
• статус;
• ответственный;
• дата создания;
• дата последней проверки;

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

Подготовленные требования к переходам и реестр ссылок помогут сформулировать задачу для внешней команды QA. Centicore Group проводит функциональное тестирование приложений на соответствие требованиям и разрабатывает тестовые сценарии под задачи проекта.

Итого

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

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

Сначала разделим деплой и релиз

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

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

Держите в фокусе четыре параметра:

1. какой именно артефакт попадает в среду;
2. какая доля запросов или пользователей видит изменение;
3. по каким сигналам выкладка продолжается или останавливается;
4. сколько времени занимает возврат к рабочей версии.

Время восстановления тоже нужно определить заранее. Например, отключение функции через флаг должно занимать не более 1–5 минут, возврат к предыдущей стабильной версии — до 15 минут. Для сбоев, затрагивающих базу данных или требующих ручного вмешательства, устанавливают отдельное целевое время восстановления — например, 30–60 минут. Эти значения служат отправной точкой: уточняйте их с учётом критичности сервиса, архитектуры и требований бизнеса.

Один артефакт для всех сред

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

С подобной проблемой столкнулись и мы в RWB. При непрерывной интеграции и доставке (CI/CD) пайплайны для разных сред запускались независимо. Из-за повторной сборки в прод мог попасть образ, который не проходил проверку на стейджинге.

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

Для прода в RWB добавили отдельное правило. Если пайплайн не находит ранее собранный образ, выкладка завершается ошибкой. Правило находится непосредственно в коде пайплайна.

После внедрения этого подхода RWB еженедельно пропускает около 700 сборок. Это 30% сборок с включённой фичей и 5% общего числа сборок через CI/CD. Главное — между тестированием и продом сохраняется один и тот же исполняемый код.

Поэтапная выкладка ограничивает радиус сбоя

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

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

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

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

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

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

Метрики, которые останавливают релиз

Статус контейнера Running подтверждает только запуск процесса. Для решения о продолжении выкладки нужны сигналы нескольких уровней.

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

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

Feature flags управляют доступностью функции

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

Флаг не заменяет канареечную выкладку контейнера. Эти механизмы контролируют разные уровни:

• канареечная выкладка проверяет новую версию приложения и её взаимодействие с инфраструктурой;
• feature flag управляет отдельным пользовательским сценарием внутри уже развёрнутой версии.

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

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

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

Миграции данных требуют собственного плана отката

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

Для изменений, затрагивающих схему данных, применяют подход expand–migrate–contract:

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

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

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

У RWB похожая задача решена через правила совместимости — рассказали об этом в кейсе о переходе к микрофронтендам. Основное приложение выбирает подходящую версию независимо развёртываемого фронтенд-модуля. Благодаря этому вы можете выпускать изменения постепенно и при необходимости откатывать отдельный микрофронтенд.

Откат нужно репетировать

В рабочий сценарий нужно включить:

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

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

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

Минимальный набор перед первой управляемой выкладкой

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

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

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

Вместо вывода

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

Я никогда так не ошибалась.

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

При этом ТЗ всё ещё не было.

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

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

Хочешь сделать лотерею — думай «как лотерея»

На старте мы знали только одну вещь: клиент должен получить возможность покупать лотерейные билеты внутри мобильного банка. Всё остальное было как в тумане.

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

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

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

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

В лотерее главное — ожидание

Именно тогда в проекте появился эмоциональный CJM. Если обычный клиентский путь отвечает на вопрос «что делает клиент», то эмоциональный пытается ответить на вопрос «что он чувствует». Для лотереи эта разница оказалась принципиальной. Человек покупает не набор цифр и даже не шанс на выигрыш. Он покупает надежду, ожидание и эмоциональный опыт.

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

Но дальше начинался длинный период ожидания.

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

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

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

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

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

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

Закон — это база для требований

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

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

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

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

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

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

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

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

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

• Нужно ли идентифицировать клиента?
• Какая у него налоговая ставка?
• Является ли он налоговым резидентом?
• Какой доход он уже получил с начала года?
• Кто выступает налоговым агентом?
• Какие данные необходимо получить из внутренних систем банка?
• Какие документы нужно сформировать?
• Какие данные передать партнеру?
• В какой момент считать выплату завершенной?

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

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

Еще одной областью, которая неожиданно ворвалась в проект, стала фискализация — требования Федерального закона 54-ФЗ о применении контрольно-кассовой техники. До работы над Альфа-Манией я, как и многие, воспринимала онлайн-кассы как что-то существующее где-то рядом с бухгалтерией и налоговой отчетностью. Однако очень быстро выяснилось, что чек является такой же частью клиентского опыта, как экран оплаты или push-уведомление. Нужно понимать, в какой момент формируется чек, кто отвечает за его выпуск, какие реквизиты должны передаваться, как обрабатываются ошибки и что происходит в нестандартных сценариях.

В результате обсуждение требований 54-ФЗ стало занимать в календаре не меньше места, чем обсуждение мобильных интерфейсов.

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

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

Многие growth-гипотезы появились задолго до первых требований. По сути growth-механики начали появляться еще на этапе Discovery, когда самого продукта в привычном понимании не существовало. Мы еще не написали требования к покупке билета, но уже понимали, в каких клиентских сценариях человек может впервые встретиться с Альфа-Манией.

Это была статья про Discovery

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

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

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

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

И, если получится, про то, как финтех сделал свою лотерею, я расскажу в следующей статье. Не переключайтесь.

Реклама. Рекламодатель: АО "АЛЬФА-БАНК" ИНН 7728168971, erid: 2W5zFGzLAg1

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

Это было взвешенное решение. В какой-то момент общий фреймворк превратился в поле мерж-конфликтов, где ты уже не тесты пишешь, а разбираешься, кто чей 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’ы, которых нет в документации. Спойлер: там тоже всё не совсем как в гайдах.

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

«Личный кабинет» — слово, за которым может скрываться что угодно

Президентской академии было важно понять, насколько их сервис отвечает ожиданиям и как он выглядит на фоне рынка. И чтобы посмотреть на фон, а заодно отраслевые стандарты и решения, мы провели экспертный аудит личных кабинетов (ЛК) шести крупных российских вузов. Иначе говоря — откалибровались.

И выявили кое-что интересное.

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

Немного отойдём в сторону — мы знаем, что ЛК имеются у различных платформ, к примеру, личный кабинет владельца ОСАГО, селлера на маркетплейсе или налогоплательщика. Это некая устоявшаяся отраслевая сущность, которая есть в разных крупных компаниях, цифровых сервисах и выполняет функцию некого внутреннего пространства, где пользователь видит свои данные и выполняет набор определенных действий.

А какой набор действий может быть у студента?

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

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

Чтобы сравнивать вузы корректно, нам была нужна единая шкала. Но подходящего инструмента для сравнения не было — ведь никто до этого не сравнивал ЛК разных вузов. Поэтому мы придумали сравнительную шкалу сами.

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

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

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

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

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

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

Удобный ЛК — не просто веяние времени, он снижает нагрузку на кураторов и административный персонал. Вопросов «А где заказать справку?», «А куда идти?», «А где оплатить?», «А у нас сегодня что, пар по философии дипломатических отношений не будет?» становится меньше, как и затраченного на это всё времени.

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

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

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

С такими вводными мы приступили к задаче. Она казалась простой: взять ЛК и протестировать.

Как тестировали: айтрекинг, эмоциональный отклик и 2 сегмента пользователей

После бенчмарка перешли к детальному тестированию личного кабинета. У нас было 32 участника разделённых на две группы по 16 человек:

• Группа 1 — студенты Президентской академии: пользуются ЛК в учёбе, знают интерфейс, привыкли к нему.
• Группа 2 — студенты других вузов: свежий взгляд, быстро спотыкаются там, где ЛК нарушает привычные паттерны.

Тестирование проходило так: сначала проводилось интервью про опыт использования личного кабинета (Президентской академии или другого вуза). Далее шло юзабилити-тестирование в очках eye-tracking и отслеживание эмоционального отклика респондента (пять заданий подряд). Здесь нам важно было посмотреть, как будет выполняться задание в естественных условиях без обсуждения, и замерить время прохождения. Когда очки снимались, переходили к обсуждению каждого задания, чтобы получить подробную обратную связь.

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

Как только студент завершал задание (успешно или нет), мы задавали три вопроса:

• Насколько легко или сложно было выполнить это задание?
• Сколько времени у вас заняло выполнение задания?
• Насколько вы удовлетворены или неудовлетворены выполнением задания?

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

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

Два дополнительных инструмента фиксации:

• Айтрекинг (Tobii Pro) — отслеживает движения глаз с точностью до миллисекунды. Человек может говорить, что всё понятно, и при этом три раза беспорядочно блуждать взглядом по странице, прежде чем заметит нужный элемент.
• SenseMachine — нейросетевая технология анализа микровыражений лица в реальном времени, обученная на данных более чем 40 000 лиц. Показывает эмоции человека и когнитивную нагрузку в режиме реального времени — полезный инструмент, поскольку не все эмоции осознаются человеком или озвучиваются по разным причинам.

Теперь к самому интересному.

Нашли то, что скрыто

Один из выводов из «эмоциональных» данных — это разрыв между двумя группами: опытными студентами Президентской академии и студентами других вузов (далее — «новичками»).

Например, средний уровень когнитивной нагрузки у студентов Президентской академии — +0.11, а у студентов других вузов — +0.15. Разрыв небольшой, но он показывает, как свои студенты адаптировались к интерфейсу и перестали «замечать» сложности — именно поэтому когнитивная нагрузка у них ниже, чем у новичков. Новички же спотыкаются там, где ЛК нарушает привычные паттерны.

Конкретный пример — сценарий «Заказ справки». Айтрекинг фиксирует паттерн у обеих групп: взгляд сначала концентрируется на нецелевых разделах, которые подсознательно казались респонденту более релевантными, — например, разделе «Документы» — и только потом замечает правильный «Студенческий офис МФЦ». Студенты Президентской академии выучили расположение нужного раздела и находили его за 4,9 сек. А студенты других вузов тратили почти вдвое больше времени, а половина его и вовсе «игнорировала». Нагляднее — на тепловых картах.

Ещё одна неожиданная находка: «Главную страницу» не используют по назначению. Что интересно, у Президентской академии все пять самых важных сценариев есть в быстром доступе на главной, но эту страницу не использовали как точку быстрого входа. Тепловые карты это подтверждают: внимание остаётся в верхней трети, затем взгляд уходит в меню.

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

Обычный UX-тест показал бы, что всё хорошо...

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

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

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

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

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

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

Именно поэтому, когда на встрече с IT-департаментом Президентской академии и проректором мы показывали слайды с результатами, рекомендовали дорабатывать сначала Главную и Меню и только потом — другие сценарии.

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

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

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

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

Итого

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

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

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

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

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

Спасибо за внимание. Исследователи проекта — Залина Цховребова, Ксения Никонова, Таня Рязанова, Лёша Михаленков и Юлия Дзынова.

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

Редакция Tproger недавно была нескольких таких ивентах и на партнёрском дне Диасофт пообщалась с членом правления Диасофт и директором по работе с партнёрами Александром Сахаровым. Мы поговорили о том, почему агентская разработка в её нынешнем виде — тупик, как строить эффективные AI-процессы разработки, почему фреймворк теперь важнее модели и что нового в AI-обновлении платформы Digital Q.

Digital Q — российская low-code экосистема разработки от «Диасофт» с готовым «заводом» инструментов для сборки корпоративных приложений: от проектирования бэкенда, дизайна интерфейсов до DevOps. В мае 2026 года вышла AI-driven версия, где искусственный интеллект встроен в саму платформу — он проектирует архитектуру, генерирует код, фронтенд и бизнес-процессы по человекочитаемой спецификации, оставляя разработчику работу с замыслом, а не с рутиной.

AI добрался до фундамента

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

— Главный сдвиг — это то, что AI добрался до вещей, которые казались незыблемыми. ERP-системы — это же фундамент крупного предприятия. И мы своими глазами видим, как крупные компании переходят на вайб-кодинг ERP. Звучит страшновато, но это факт, это происходит не в стартапах, а в очень больших организациях. Банки, промышленность, энергетика — везде одно и то же.

А шум — это вера, что AI всё решит сам по себе. Что можно купить лицензии Copilot, посадить за них разработчиков и они вам начнут производить продукты в десять раз быстрее. Нет, не начнут. Точнее, начнут, но счета вас очень неприятно удивят.

От агентов к AI-native платформе

Агентская разработка как самостоятельный подход не работает. Не масштабируется. Подход должен быть AI-native

— Вы на сцене показывали, как обновился Digital Q с декабря. Что конкретно поменялось за эти полгода?

— В декабре, на зимнем партнёрском дне, мы представили платформу Digital Q.GPT — на ней можно реализовывать агентский workflow. Интеграция со всеми LLM-моделями, экосистема построения агентов, мультиагентные системы. На тот момент это было супер актуально.

К маю выяснилось, что этого недостаточно. За последние шесть месяцев все — Anthropic, Google, Gartner, Amazon, Сбер на ЦИПР — пришли к одному и тому же выводу: агентская разработка как самостоятельный подход не работает. Не масштабируется. Подход должен быть AI-native, то есть AI вшит в саму экосистему разработки, а не прикручен сбоку отдельными агентами.

— А что плохого в агентах?

— С агентами ничего плохого, они нужны. Плохо, когда вся разработка строится только вокруг них. Если кто-то хочет писать агенты — пожалуйста, в Digital Q.GPT весь функционал остался: workflow, мультиагентные системы, всё это работает. Но это уже не центральная история. Центральная история теперь — единая экосистема, в которую AI встроен на каждом этапе процесса.

Три способа потерять деньги на AI

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

— Давайте про антипаттерны. Вы на сцене перечислили целый список — что точно делать не надо. Какой из них самый болезненный?

— Самый болезненный — вендорлок на конкретную LLM. Если вчера вы платили 20 долларов на разработчика в месяц, завтра это 100, послезавтра 200. Скоро будет дороже, чем один разработчик в месяц. И весь ваш контекст — спецификации, история, наработки — лежит у этой модели. Вы заложник. Они вам говорят: «не парьтесь, весь контекст у нас, всё будет хорошо». Хорошо у них будет, а у вас потом будут проблемы.

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

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

— Как можно решить эти проблемы?

— Главный тезис: фреймворк важнее модели. Они это называют harness, мы называем экосистема разработки. Есть термины IDP — Integrated Development Platform, IDE — Integrated Development Environment. Суть одна. Ваш фреймворк должен быть локально у вас, весь контекст — локально у вас, модели должны быть взаимозаменяемые. Тогда вы можете переключаться между ними и управлять стоимостью.

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

Как теперь устроена разработка

— Вы говорили про два контура разработки. Объясните для тех, кто услышит об этом впервые.

— Раньше был один контур: ТЗ — постановка — кодирование — тестирование — релиз. Долго, последовательно. Цифровая трансформация это ускорила: годы превратились в кварталы и месяцы. Но всё равно один линейный процесс.

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

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

И самое важное между ними — экосистема, которая держит все артефакты и весь контекст. Если этой экосистемы нет — у вас ничего не получится развивать. Сгенерили код, отдали в продакшен, а через полгода вы уже не понимаете, как туда внести изменение.

— Это та же мысль, что и про вендорлок, по сути?

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

— Вернёмся к Digital Q. Как она теперь устроена? Если разобрать на компоненты — что там лежит?

— Если коротко — то, во что крупные компании годами вкладываются, чтобы отстроить правильный процесс разработки. Независимость от модели — это базовое. Полный SDLC: как правильно писать, какие артефакты должны быть. Репозиторий справочников, репозиторий процессов, репозиторий потоков. Работа с данными. Поддержка двухконтурной модели. Единые репозитории инструкций для разного типа агентов. Полностью DevOps. Полностью процесс тестирования.

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

Разработчик всегда идёт на самую дорогую модель — она же лучшая. И запускает её сто раз в день. Ему кажется, что это бесплатно. Извините, не бесплатно.

— Почему вы так настойчиво возвращаетесь к теме денег? Ведь все маркетинговые материалы AI-вендоров обещают именно экономию.

— Потому что это самая опасная иллюзия сейчас. Uber, пытаясь сэкономить на разработчиках, потратил больше трёх миллиардов долларов на AI-генерацию кода. Японская компания за несколько месяцев потратила 500 миллионов долларов вместо тех людей, которых сократили. Долларов, не рублей. И это уже не теория, это свежие кейсы 2025–2026 годов.

Почему так получается? Потому что разработчик, если его не ограничивать, всегда идёт на самую дорогую модель — она же лучшая. И запускает её сто раз в день. Увидел маленькое расхождение в результате — поправил формулировку — перегенерил всё. Ему же кажется, что это бесплатно. Это так красиво, так удобно — нажал кнопку, всё пересоздалось. Извините, не бесплатно. Это огромные деньги. Свобода такая, что разоряет.

— И как вы с этим боретесь технически?

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

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

— Расскажите про демо с CRM. Вы показывали, как из 400-страничного ТЗ получается работающее приложение. Это правда один день двух человек, или там есть нюансы?

— Один день двух человек — это правда. Нюансы есть, конечно. Главный: это не black box, который сгенерил вам что-то непонятное. Это полностью оснащённый артефактами IT-проект. Можно пойти и сдать любому госзаказчику по ГОСТу. Полная документация — техническая, пользовательская, финансовая. Полный набор описанных бизнес-процессов. Полный набор тестов, включая тесты на уязвимости.

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

Дальше прорисовывает архитектуру бэкенда. Здесь критически важный момент: она смотрит на репозиторий и решает, что писать с нуля, а что переиспользовать. У неё в инструкциях жёстко зашито: инфобез не писать, использовать готовый. Логирование не писать. Справочники, типовые штуки — не переписывать. Только то, что реально новое.

— А фронтенд?

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

Потом бизнес-процессы. Та же AI-машина смотрит на ТЗ и генерит BPMN-процесс — уже машиночитаемый, его можно сразу выполнять. Но она же его и критикует: смотрит со стороны и говорит — у вас тут проблема, тут проблема, ТЗ было неполным, давайте решать. И человек уже работает с агентом, который ему подсвечивает дыры.

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

— Вы говорили, что AI-агенты теперь работают не только в коде, но во всех ролях — от аналитика до девопса. Как это устроено?

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

Фишка нашей платформы в том, что мы все роли оснастили всеми агентами из коробки. Не надо ничего собирать самому. Скачали Digital Q, поставили, производите ПО.

Что доступно прямо сейчас

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

— И эта экосистема действительно доступна партнёрам?

— Да, мы её отдаём рынку. С июля начинаем публиковать обновлённую версию для партнёров. Можно скачать, развернуть, запускать. Правда, нужно знать, что такое Kubernetes и Kafka — это не магический инсталлер для гуманитариев. Но если знаете — берёте и работаете.

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

— Возвращаясь к началу разговора. Вы фактически заявляете, что Диасофт — единственный, кто отдаёт такую экосистему рынку. Это правда так, или маркетинг?

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

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

Если такого человека нет — никакая AI-генерация вас не спасёт. Будет только дороже и хуже.

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

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

И ещё одно. Команды теперь строятся вокруг продуктового инженера. Это новая ключевая роль. Раньше ценностью был код. Сейчас ценность — бизнес-компетенция, способность правильно поставить задачу. Если у вас есть человек, который понимает бизнес и умеет это сформулировать — код появится быстро. Если такого человека нет — никакая AI-генерация вас не спасёт. Будет только дороже и хуже.

Бонус: чек-лист «AI-разработка без иллюзий»

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

Чего точно не стоит делать:

— Сажать команду на одну LLM-модель — это вендорлок, и он будет дорожать;

— Разрешать разработчикам неограниченно гонять самую дорогую модель;

— Использовать AI только в кодировании, без интеграции в остальной процесс;

— Накупить разных инструментов и надеяться, что они потом «как-нибудь соберутся»;

— Сокращать разработчиков в расчёте на «бесплатные» токены.

Что стоит сделать:

— Держать экосистему разработки и весь контекст локально;

— Зашить в платформу переиспользование кода — половину нового модуля собирать из готового;

— Настроить лимиты: дешёвые модели для простых задач, перегенерация только изменённых частей;

— Разделить процесс на два контура — замысла (где работает человек) и исполнения (где работают агенты);

— Растить продуктовых инженеров — людей, умеющих формулировать задачу, а не только писать код.

Реклама. Рекламодатель: ООО «Диасофт», ИНН 7715560268, erid: 2W5zFJRM88q

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

Я работаю в ретейле больше двадцати лет, и за это время успела убедиться: самые дорогие проблемы в магазине — не технические, а операционные. Товар лежит на складе, но не на полке. Покупатель уходит, продажа теряется. Мы с командой Lenta tech (ИТ-бренд «Группы Лента») решили, что пора выстроить платформу, которая сама определяет, какой товар донести до полки, из какой палеты и в каком порядке. Проектную группу собрали из сотрудников разных подразделений: Big Data, SAP, мобильная разработка, онлайн и операционный бизнес. Именно то, что за одним столом сидели инженеры, аналитики и люди, которые каждый день работают в торговом зале, позволило учесть все аспекты — от архитектуры до количества кликов на экране ТСД.

Почему классические процессы перестали масштабироваться

Гипермаркет — это не магазин у дома. Это десятки тысяч товарных позиций (SKU), сотни палет ежедневно и непрерывный поток перемещений между складскими зонами, верхними стеллажами и торговым залом. Ручной поиск товара, бумажные описи на палетах, выкладка «на глаз» — все это работало до определенного момента. Но при масштабах крупной сети процесс перестал справляться.

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

Три слоя архитектуры: что оставили, а что написали с нуля

Архитектурно решение выстроили вокруг трех слоев: система планирования ресурсов предприятия (ERP) на базе SAP, слой больших данных (Big Data) и серверная часть мобильного приложения (backend), написанная с нуля.

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

Слой Big Data взял на себя аналитику и генерацию задач. Здесь лежит основной объем логики: обработка прогнозов, анализ расхождений между запасом и фактическими продажами, формирование потребностей к пополнению полки. Данные содержатся и обрабатываются в корпоративном хранилище (Data Lake), откуда потребности уходят дальше — в backend приложения.

Backend мобильного приложения — новый компонент, созданный специально для проекта. Команда мобильной разработки отвечала за этот слой с нуля: он получает от Big Data потребности к пополнению, формирует задания для сотрудников, обрабатывает операции изъятия товара из палет и передает информацию о местах хранения обратно в SAP. Помимо этого, backend взаимодействует с системой онлайн-заказов (PDA PickerApp): когда сборщик не находит товар на полке, событие поступает в backend и тоже превращается в задание.

Для директоров магазинов и руководителей секций предусмотрен веб-интерфейс (Web UI), где визуализируются списки задач, отчетность и статистика. Сотрудники торгового зала работают через мобильное приложение «Адресное хранение» на ТСД или смартфоне, где могут фильтровать задания, выполнять сверку ценников и управлять палетами.

Почему legacy не стало препятствием

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

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

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

Логика задач: прогнозы, приоритеты и пересечения списков

Ключевая логика системы сосредоточена в механизме формирования задач. Эту часть взяла на себя команда Big Data. Нельзя проверить весь ассортимент — ресурс сотрудника ограничен. Поэтому система выдает только наиболее приоритетные задания, и логика их отбора довольно сложная. В продакшне работают несколько видов автоматических задач:

• Событие «нулевого пика» (zero pick). Сборщик онлайн-заказа не нашел товар на полке и ставит отметку в PickerApp. Система проверяет остаток: если он ненулевой, рассчитывает количество к выкладке и создает задание. Это самый «чистый» сигнал — живой человек уже подтвердил, что товара на месте нет.
• Пустая полка. Раз в час Big Data сверяет остатки на основном складе магазина с запасом в палетах. Если эти цифры совпадают, значит, весь товар лежит в палетах — на полке ноль. Генерируется задача.
• Недостаточный запас. Товар на полке есть, но система сопоставляет текущий остаток с прогнозом продаж. Если остатка не хватает для покрытия спроса, формируется задание на пополнение. Здесь важно, что задача возникает не по факту «полка пуста», а на опережение.
• Товары без продаж. Если по позиции в течение недели не было ни одной продажи, система берет товары с наибольшим объемом запаса для каждой секции и собирает из них перечень задач на неделю. Если по позиции уже была отработка — повторно она не добавляется. Логика здесь в том, что большой запас без движения — потенциальный симптом невыложенного товара.

Помимо автоматики, руководящий персонал может создать задачу вручную через Web UI.

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

«Каждый лишний клик стоит денег»

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

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

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

Пять команд и одна зона неопределенности

Как я уже говорила, проектная группа была собрана из пяти подразделений: Big Data, SAP, мобильная разработка, команда онлайна и операционный бизнес. Каждое было опытным, каждое умело работать по своим задачам. Проблема проявилась на стыках.

Когда в продакшн-среде возникала ошибка, далеко не всегда было очевидно, какое именно подразделение ее допустило. Данные проходят через несколько слоев: Big Data сформировала потребность, backend ее получил, мобильное приложение отобразило задачу, SAP отдал информацию о палетах. Если задание некорректно, нужно пройти всю цепочку и определить, где произошел сбой. Разграничение зон ответственности и процедура разбора инцидентов — то, на что было заложено недостаточно времени на старте. Притирка заняла ощутимый ресурс, хотя ни одна из команд не была новичком.

Синхронизация изменений тоже требовала внимания: когда Big Data меняет логику формирования задач, backend должен корректно обработать новую схему, а мобильное приложение — отобразить результат. Каскадные доработки ускоряли одно звено и ломали соседнее. Со временем процесс выстроился, но в ретроспективе — это одна из главных недооцененных статей расхода по срокам.

Лавина ложных задач и контроль качества данных

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

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

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

Волны, feedback loops и продукт, который менялся на ходу

Внедрение разделили на пять волн, и это было осознанным инженерно-процессным решением, а не просто осторожностью.

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

Циклы обратной связи (feedback loops) работали следующим образом: магазин фиксирует проблему, операционная служба передает ее в проектную команду, разработка вносит изменение, следующая волна получает обновленную версию. Между этими этапами проводится анализ метрик дисциплины и качества отработки задач. Если магазины первой волны показывали низкие результаты, разбирались: проблема в инструменте или в процессе?

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

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

Что показал проект

Дополнительная прибыль за 2025 год превысила целевые показатели на 7%. Но, помимо финансовых результатов, проектная группа вынесла несколько важных инженерных и процессных выводов.

Большие ретейл-технологические проекты — это всегда про процессы, а не только про код. Можно написать идеальный backend, но если магазин не размечает палеты, система бесполезна.

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

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

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

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

Главный риск: обмануться быстрой победой

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

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

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

Спроектируйте архитектуру раньше, чем напишете первый экран

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

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

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

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

Сначала бэкенд и контракт, потом клиенты

Соблазн делать клиентское приложение «по фиче» и откладывать бэкенд велик, особенно когда фронт оживает за секунды. Это прямой путь к расхождению версий, когда веб, iOS и Android начинают жить своей жизнью.

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

AI-тесты не заменяют ручное тестирование и фокус-группу

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

Автотесты Claude проверяют то, что поддается формализации. Правильно ли считаются баллы по заданному алгоритму, корректно ли обрабатываются зависимости, верно ли отрабатывают условные конструкции. За пределами их охвата остается всё, что происходит в реальной эксплуатации. Например, когда пользователь с конкретной версией Android и конкретными смарт-часами пытается загрузить тренировку, которую его трекер назвал иначе, чем ожидает система. Или когда два пользователя одновременно обращаются к одной записи. Это принципиальное ограничение автоматического тестирования, и оно не отменяет важности функциональных автотестов.

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

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

Как собрать AI-driven команду под такой проект

За три месяца сложилось понимание оптимального состава для подобного проекта:

• 1 архитектор — человек, который понимает, как обеспечить стабильность многопользовательского сервиса под нагрузкой;
• 2 продакт-инженера — берут на себя и проработку пользовательских сценариев, и собственно вайбкодинг;
• UX/UI-дизайнер;
• QA-инженер.

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

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

Что в итоге

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

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

На первый взгляд кнопка «наверх» — задача на пять минут. Добавил position: fixed, обработчик window.scrollTo() — готово.

Но стоит этой кнопке появиться в живом проекте, как выясняется, что она пересекается с cookie-баннером, мешает чату поддержки, выглядит иначе в мобильной версии, не дружит со строгим CSP или пропадает из Django Admin.

В итоге маленькая UI-деталь начинает обрастать условиями. Я решил собрать их в отдельный Django-пакет — django-scroll-to-top

Когда трёх строк JavaScript достаточно

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

Это нормальное решение. Не всегда стоит тянуть пакет ради одной кнопки.

Но в реальном Django-проекте быстро появляются дополнительные вопросы:

• когда именно показывать кнопку: после 300 пикселей, одного экрана или только при прокрутке вверх;
• что делать на коротких страницах;
• как не перекрыть cookie-баннер, чат, toast-уведомления или нижнюю мобильную навигацию;
• как дать пользователю закрыть кнопку;
• как не сломать клавиатурную навигацию и режим reduced motion;
• как сделать отдельное оформление для сайта и Django Admin;
• как не заставлять проект добавлять unsafe-inline в Content Security Policy;
• как позволить редактору или администратору изменить цвет, положение и иконку без нового деплоя.

Именно в этот момент «три строки JavaScript» превращаются в отдельный компонент.

Что я хотел получить

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

1. Подключение сайта одной template-тегом.
2. Отдельная поддержка обычных страниц и стандартного Django Admin.
3. Настройка внешнего вида через админку, а не через постоянную правку CSS.
4. Без jQuery, CDN, фронтенд-фреймворка и обязательной сборки.
5. Безопасная работа при строгой CSP.
6. Прогрессивное улучшение: без JavaScript остаётся обычная ссылка в начало страницы.
7. Возможность жить рядом с другими фиксированными элементами интерфейса.

Пакет в итоге хранит обычные настройки установки в settings.py, а визуальное поведение — в базе данных. Это позволяет менять кнопку через Django Admin, публиковать новую версию настроек и при необходимости откатываться на предыдущую. В проекте есть отдельные профили для публичного сайта и Django Admin, а ревизии могут быть черновыми, опубликованными или архивными.

Быстрое подключение

Базовый сценарий начинается с установки:

В settings.py добавляем приложение. Если нужна поддержка стандартной админки, пакет должен идти раньше django.contrib.admin:

Включаем области, где должна работать кнопка:

Для публичной части добавляем URLConf пакета:

А в общий шаблон сайта — один тег:

На стандартном Django Admin ничего дополнительно вставлять не нужно: пакет использует обычный механизм разрешения шаблонов Django. Если же в проекте переопределён admin/base_site.html тег можно добавить вручную в блок footer

Настройка без превращения админки в редактор CSS

Мне не хотелось хранить в базе шаблоны, произвольный CSS или JavaScript. Это неудобно для сопровождения и создаёт лишнюю поверхность для ошибок.

Поэтому визуальная часть собрана из контролируемых вариантов:

• круг, квадрат, скруглённый квадрат или pill;
• заливка solid, outline, soft, ghost, glass или gradient;
• положение в любом углу экрана;
• отдельные размеры для desktop и mobile;
• светлая и тёмная тема;
• встроенные иконки, иконки от разработчика или загружаемые SVG;
• настройки тени, границы, opacity и focus ring.

Что происходит, когда рядом есть cookie-баннер или чат

Нижний правый угол страницы редко бывает свободен. Там часто живут:

• cookie-баннер;
• компактная кнопка после закрытия баннера;
• чат поддержки;
• кнопка обратного звонка;
• мобильная навигация;
• toast-уведомления.

Пакет умеет рассматривать такие элементы как препятствия. Для этого можно пометить элемент атрибутом:

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

Для сложных виджетов есть отдельный адаптер: он может отслеживать появление и исчезновение элементов, например компактного launcher после закрытия cookie-баннера. При этом ни cookie-пакет, ни чат не становятся зависимостями django-scroll-to-top

Доступность — не отдельная галочка в конце

У кнопки есть понятное имя для screen reader, поддержка клавиатуры, видимый focus-visible, минимальный размер области нажатия и режим prefers-reduced-motion.

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

Полный независимый аудит WCAG 2.2 AA и тестирование масштабирования 200% и 400% пока находятся в roadmap, поэтому называть компонент полностью сертифицированным по WCAG было бы неправильно. Но структурные требования — клавиатурная доступность, фокус, reduced motion, forced-colors и безопасная работа без JavaScript — уже заложены в компонент и покрываются тестами.

CSP и загружаемые SVG

В корпоративных проектах часто нельзя просто добавить inline-скрипт и включить unsafe-inline ради одной кнопки.

По умолчанию компонент использует same-origin CSS и JavaScript. Для него подходит политика такого вида:

Настраиваемые цвета и размеры отдаются не через inline-стили, а через версионированный stylesheet endpoint. Это позволяет сохранить простой контракт с одним template-тегом и не ослаблять CSP.

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

Ревизии, публикация и откат

Одна из самых полезных вещей в пакете — не сама кнопка, а жизненный цикл её настроек.

Можно создать черновик, посмотреть результат в live preview, опубликовать изменения или вернуться к предыдущей версии. Это особенно удобно, когда кнопку настраивает не разработчик, а контент-менеджер или дизайнер.

У ревизий есть три состояния:

• draft — редактируемый черновик;
• published — текущая активная конфигурация;
• archived — сохранённая версия для отката.

Где пакет уместен, а где нет

django-scroll-to-top имеет смысл, когда кнопка нужна в нескольких проектах, должна работать в Django Admin, настраиваться без деплоя или жить в окружении со строгими требованиями к CSP и интерфейсу.

Для лендинга на одну страницу проще и правильнее написать несколько строк самостоятельно. Это будет быстрее, понятнее и дешевле в сопровождении.

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

Сейчас пакет выпущен как beta-версия 0.2.0, требует Python 3.10+ и поддерживает Django 4.2 LTS, 5.x и 6.0. Лицензия — MIT.

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

Пакет опубликован в PyPI под именем django-scroll-to-top.

Обратная связь, баг-репорты и предложения по интеграции с кастомными Django Admin-темами приветствуются в Issues.

Почему инфраструктура начинает привлекать больше, чем фичи

С фичами всё прозрачно: написал код — увидел результат на экране. Быстрая и понятная обратная связь. Но со временем замечаешь, что проблемы повторяются. Приложение тормозит не из-за плохого кода, а потому что на один экран уходит пять-шесть сетевых вызовов. Логика на клиенте. Хочешь что-то изменить — готовь релиз, проходи App Store Review и жди недели, пока обновление дойдёт до всех.

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

Возвращаться к фичам стало неинтересно. В инфраструктуре задачи сложнее, результат измеряется метриками — latency, error rate, скорость релизов, — а влияние на всю систему, а не на один экран.

Что Android даёт для инфраструктуры — а чему учиться с нуля

Мобильный бэкграунд оказался не балластом, а преимуществом. Я понимал ограничения изнутри. Backend-инженер может прочитать, что мобильные сети ненадёжны, память ограничена, а батарея — критичный ресурс. Но прочитать и прочувствовать — разное. Я годами наблюдал, как приложение “захлёбывается” на устройствах среднего сегмента. Знал, что 60% пользователей сидят именно на таких. Видел, как баг, который мы починили за день, продолжает висеть у людей неделями — просто потому, что они не успели обновиться.

Когда я проектировал gateway, я точно знал, что почувствуют мобильные разработчики, если ошибусь. Добавить ещё один сетевой вызов — это будет не бесплатно. Оставить логику в приложении — значит отдать её на устройство, которое я не контролирую.

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

Чему пришлось учиться с нуля? Операционному мышлению. В Android ты выпускаешь релиз — и он либо работает, либо нет. Если крашится, починишь в следующей версии. В инфраструктуре нет «следующей версии». Если gateway падает, всё приложение ложится для миллионов пользователей прямо сейчас.

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

Что делать, если один из пяти сервисов не ответил? Как понять, что мы катимся к инциденту, до того, как пользователи начнут жаловаться?

Этому в мобильной разработке не учат.

Как я учился: пробелы, сроки и смена мышления

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

Учился итеративно, не пытаясь объять необъятное сразу. Gateway начинался как простой прокси. Затем добавили агрегацию ответов, потом — конфигурационные определения экранов. Каждый такой шаг вынуждал осваивать следующий уровень: circuit breakers, стратегии повторов, observability, планирование мощностей.

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

Что означает «выдающийся уровень» в инфраструктуре

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

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

Затем — миграция живой системы, где права на ошибку практически нет. Приложение нельзя выключить или отрепетировать в реальном масштабе. Остаётся только постепенный перевод трафика: shadow mode → 1% → 5% → 25% → 50% → 100%, с автоматическим откатом при любом росте ошибок. И всё это — пока миллионы пользователей активно работают с продуктом, не подозревая, что под капотом идёт замена двигателя на ходу. Такой уровень дисциплины и инструментации приходит только с практикой.

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

Почему путь в инфраструктуру доступнее, чем кажется?

Карьерные траектории в инфраструктуре редко бывают чётко описаны. Здесь нет готового чек-листа в духе «диплом по Computer Science, пять лет в бэкенде, обязательное знание Kafka и Kubernetes». С одной стороны, такая неопределённость пугает. С другой — именно она и делает этот путь более доступным, чем принято думать.

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

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

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

Мобильный бэкграунд как преимущество архитектора

Считаю ли я, что мобильный опыт сделал меня лучшим архитектором для mobile-first продуктов? Безоговорочно, да.

Я помнил, как ощущается медленный экран на устройстве среднего сегмента. Помнил, что случается, когда API возвращает слегка неправильные данные и приложение падает при парсинге. Помнил то чувство, когда баг уже в проде, а ты ждёшь App Store Review и ничего не можешь исправить.

Поэтому когда я проектировал gateway, я не занимался абстрактной «оптимизацией перформанса». Я опирался на совершенно конкретный опыт. Знал, что убрать один сетевой round trip — это подарок каждому мобильному разработчику. Знал, что перенос логики на сервер означает перенос в место, где я могу починить всё за минуты, а не за недели.

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

Коротко: что делать, если думаете о переходе

• Найдите промежуточный шаг. Не прыгайте сразу в бэкенд. Начните с задач на стыке: оптимизация API, инструменты для мобильных разработчиков, улучшение сетевого слоя.
• Используйте мобильный контекст как рычаг. Вы понимаете то, о чём бэкенд-инженеры только догадываются. Говорите об этом вслух.
• Учитесь измерять невидимое. В инфраструктуре результат — это метрики: latency, error rate, скорость релизов. Учитесь рассказывать историю через цифры.
• Проектируйте под отказ, а не тушите пожары. Senior-уровень — это определить, что сломается и кто за это отвечает, до того, как оно сломается.
• Не ждите разрешения. Путь не размечен, но он открыт. Начните с малого — и двигайтесь туда, где задачи становятся интереснее.

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

Так появляется классическая ловушка 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 и аккуратная миграция данных дают рабочую модель: выбрать ограниченный участок, описать контракт, реализовать новую версию, проверить её на реальном трафике, постепенно переключить пользователей и удалить старый код.

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

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

К 2010 году российское IT составляло всего 1% ВВП страны — индустрия приносила деньги, но до современных масштабов было ещё далеко. В этот период IT развивалось по принципу цепной реакции: каждый новый этап наступал тогда, когда нужно было решить проблему, созданную прошлой или новой технологией.

Эта статья — о том, как российское IT развивалось и продолжает развиваться в 2010-х и 2020-х годах.

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

Интернет выходит из дома: как смартфон заменил компьютер

В 2007 году Apple представила первый iPhone. Россия не вошла в список стран первой волны, поэтому официально оригинальный iPhone 2G на внутреннем рынке сразу после появления не продавался. Частники ввозили телефоны из-за границы и снимали блокировку, чтобы они могли работать с местными операторами. Если в США первый iPhone стоил от 499 долларов, то на «сером» рынке в России дефицитный гаджет продавали от 600 долларов.

Официальные продажи запустили только 3 октября 2008 года — с появлением модели iPhone 3G. Базовая версия на 8 ГБ стоила 23 000 рублей. По данным Росстата, средняя зарплата по стране в 2008 года составляла около 18 000 рублей, поэтому iPhone за 23 000 рублей считался люксовым и недоступным для массовой аудитории.

У культуры смартфонов в России был свой путь: рынок стал массовым не за счёт Apple, а за счёт более доступных Android-устройств от Nokia, Samsung, HTC, LG, Sony, а позже и локальных брендов, таких как Highscreen, Explay, Texet и Digma. В 2012 году в России продали 13 млн смартфонов, а доля Android-устройств за этот же год выросла с 29% до 58%. К 2014 году потребительское поведение изменилось окончательно: продажи смартфонов впервые превысили 57%, а кнопочным телефонам теперь оставалось только грустить на пыльных полках.

Смартфонов стало много, но старый десктопный веб в них просто не помещался, а 3G-сети не тянули тяжелые сайты.

Бизнес оказался не готов: костыли мобильного веба

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

Добавьте к этому инфраструктуру: 3G покрывал не все районы страны, и даже к концу 2014 года через быстрые сети 4G LTE в интернет выходили всего около 3% устройств в стране. Разработчик мог написать идеальное веб-приложение, но пользователь просто не мог его загрузить. Решать это на уровне вышек связи было слишком долго, поэтому индустрия решила вопрос оригинально: раз веб в браузере работает криво, нужно пересаживать людей в нативные мобильные приложения.

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

Удержание любой ценой: зачем бизнес разработал супераппы

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

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

К примеру, Яндекс.Такси запустился в октябре 2011 года очень скромно: всего 11 таксопарков и около тысячи водителей в Москве. Но к 2020 году приложение превратилось в Яндекс Go — монстра, в котором на одном экране вы можете вызвать такси, заказать еду, доставку и оформить каршеринг.

Экосистемы к тому моменту перестали быть модным словом и стали обычной логикой роста: если у компании уже есть аудитория, ей хочется закрывать всё больше задач пользователя внутри своих сервисов. Поэтому Контур постепенно собирал в экосистему свои продукты для бизнеса — ЭДО через Контур.Диадок, проверку контрагентов через Фокус, инструменты для бухгалтерии и кадрового учёта в Экстерне, а позже — сервис для онлайн-общения и видеозвонков Контур.Толк.

Но для решения таких задач нужны были тысячи разработчиков, а их в стране не хватало.

Новая проблема — где взять столько разработчиков

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

Ответом на этот дефицит стало онлайн-образование. В первой половине десятых на рынке появились GeekBrains, Skillbox и другие платформы, которые обещали быстро подготовить новичков к работе в IT. А в 2019 году к этой гонке подключился и Яндекс со своим «Практикумом». Фраза «войти в IT» ушла в массы и быстро превратилась в массовый карьерный сценарий.

Пандемия только ускорила этот процесс. В 2020 году спрос на онлайн-курсы резко вырос: люди сидели по домам, искали новую профессию и всё чаще выбирали IT как понятный способ сменить карьеру. За несколько лет рынок онлайн-образования вырос в 1000 раз, но вместе с ним выросла и новая проблема: курсы научились отлично собирать и готовить новичков, но индустрии не хватало опытных специалистов.

Армия новичков: как IT-школы перегрели рынок

Образовательные площадки быстро продавали очень привлекательную идею: учишься полгода и сразу получаешь высокооплачиваемую работу. Школы показывали в рекламе красивые зарплатные вилки, обещали помощь с трудоустройством, и люди массово понесли им деньги. Весной 2022 года онлайн-школы зафиксировали очередное увеличение спроса на курсы минимум на 30%.

К 2025 году, по данным исследований hh.ru, на одну вакансию junior-разработчика падало в среднем 18,6 резюме. Конкуренция на рынке стала страшной: средняя компания могла получить более 2300 откликов на позицию начинающего фронтендера за несколько недель.

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

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

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

Кризис найма: что случилось после образовательного бума

Избыток новичков удвоил сроки найма. Ранее компании закрывали вакансию за полтора месяца, затем процесс растянулся до трёх месяцев.

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

ИИ стал массовым: как нейросети начали заменять джунов

Для российского IT нейросети начались не в день релиза ChatGPT. Корпорации годами строили языковые модели внутри своих лабораторий. Сбер показал ruGPT-3 на конференции AI Journey в декабре 2020 года. В июне 2022 года Яндекс выложил в открытый доступ YaLM 100B — на тот момент это была крупнейшая GPT-подобная модель в мировом open source. Но тогда это оставалось игрушкой для исследователей и темой для узких конференций.

В 2023 году всё вышло из-под контроля. В апреле Сбер открыл доступ к GigaChat, а уже осенью вывел его в публичный релиз. Яндекс в мае 2023 года встроил YandexGPT прямо в Алису и научил голосового помощника генерировать нормальные тексты.

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

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

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

В Centicore Group разобрали несколько кейсов из практики мобильного тестирования: промокоды, которые нельзя активировать, рейтинг, который считал лишнюю звезду, пуши на iPad, UI, который ломал рабочий сценарий, и WebSocket, который оставался висеть после выхода из чата.

Промокод, который нельзя ввести

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

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

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

Фиксить нужно мобилку, потому что генерация уже работает. А мобилка на тот момент полностью нативная, без динамических обновлений, значит полный цикл хотфикса: собрать сборку, отправить на ревью в App Store и Google Play, дождаться одобрения, выпустить. Многие крупные игроки к тому времени уже работали с динамическими обновлениями, это приложение нет.

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

Samsung, одна звезда и RatingBar

В финтех-приложении стандартная функция обратной связи — Voice of Client: пользователь оценивает консультацию в чате звёздами. Тестировщик нажимает на первую звезду — выбираются две. Нажимает на вторую — выбирается третья.

Первая гипотеза — кривой экран. Проверили на других устройствах: у коллег всё работает нормально. Версия ОС у всех Android 15, тестовый пользователь один и тот же, сборка идентичная. Добавить тестовое устройство в изолированную сеть банковского приложения непросто, но сделали. После нескольких итераций проверок выяснили, что баг воспроизводится только на живом железе Samsung — на эмуляторах и других производителях чисто.

Причина нашлась в устройстве компонента: Android RatingBar глубоко в иерархии наследует ProgressBar, а звёзды в нём скорее декоративный слой. Когда пользователь касается звезды, компонент вычисляет рейтинг через округление на основе параметра stepSize. На Samsung это округление стабильно уходило в большую сторону: касание по краю четвёртой звезды давало рейтинг 5. Фикс простой — stepSize выставляется в 0.01, а итоговое округление до целого числа делается вручную в листенере. После этого поведение стало одинаковым на всём железе.

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

iPadOS, которого не существовало

На iOS тестировать одно удовольствие: Apple настолько плотно контролирует железо, что ситуация, когда баг есть на iPhone 13, но нет на iPhone 15, практически невозможна. Граница, на которой что-то ломается в яблочной экосистеме, проходит между iPhone и iPad.

В финтех-приложении перестали работать пуш-уведомления на iPad. Сборка идентичная с iPhone, версия та же, настройки одинаковые. На iPhone регистрация в пуш-сервисе проходила штатно: приложение отправляло запрос на регистрацию устройства и получало подтверждение. На iPad в ответ прилетал код 400 с ошибкой «Provider UUID not found».

Первое подозрение было на заголовки запроса, но заголовки оказались чистыми. Причина нашлась в теле JSON-запроса: iPad и iPhone используют разные названия операционной системы: на телефоне это iOS, на планшете — iPadOS. Приложение передавало это название через атрибут OSName как есть, без нормализации. Бэкенд знал только «iOS» — при получении «iPadOS» возвращал ошибку, потому что такого значения в его словаре не существовало. Одна строка в JSON оставила целую категорию устройств без уведомлений.

Пофиксили на бэке: при получении значения «iPadOS» оно автоматически заменялось на «iOS» перед любой дальнейшей обработкой. Решение в лоб, зато надёжное. Могло быть значительно сложнее: Huawei без Google-сервисов с пуш-уведомлениями это отдельный класс проблем, где просто заменить одну строку — не получится.

Когда никто не проверял крайние сценарии

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

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

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

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

Где прячутся баги, которых нет в документации

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

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

Всё началось с безобидного, почти рутинного тикета в саппорт:

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

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

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

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

Мы начали разбираться. Стандартный мониторинг показывал норму: дашборды зелёные, в логах тихо, метрики CPU и памяти без отклонений. При этом в базе обнаруживались дубликаты, которых быть не должно. И только тогда, когда мы внимательно посмотрели на коммунальный API Gateway, то поняли что одно изменение от другой команды поменяло идемпотентность работы endpoint-а.

Проблема была структурно невидима для тех, кто находился ближе всего к ней. Отсутствие видимой проблемы не равно отсутствию риска — система просто ждала подходящего момента.

Что произошло: хронология инцидента

Архитектура была классической: Клиент → API Gateway → микросервисы,.

Сценарий развивался почти незаметно для стандартных средств наблюдения:

1. Фронтенд: Пользователь нажимает кнопку «Выпустить карту».

2. Gateway: Запрос начинает обрабатываться в API Gateway.

3. Микросервис по созданию карт: честно выполняет работу: создаёт запись в БД и возвращает `200 OK` в Gateway.

4. Новый микросервис: API Gateway вызывает новый микросервис и получает HTTP 500 в ответ от него. Исключение возникает уже после успешного вызова нашего микросервиса, и это ключевая точка разрыва: Gateway считает весь запрос неудавшимся, а ответ нашего микросервиса теряется.

5. Клиент: получает HTTP 500

6. Реакция: Пользователь видит красную плашку ошибки и логично решает: «Не сработало, пробую снова». Более того, с точки зрения протокола HTTP - запросы, в ответ на которые пришла ошибка HTTP 500, можно пытаться отправлять опять.

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

Круг замкнулся. Эпидемия началась.

В компании такого уровня это не было предусмотрено. И это такая обидная ошибка.

Как так получилось?

Вскрылось ошибочное предположение:

«В API Gateway вызов микросервиса создания карт всегда идет последним».

Таким образом идемпотентность достигалась «формально» - ведь если создание карты завершалось с ошибкой - это точно означало что и вызов API Gateway тоже завершится с ошибкой. Сработало ложное чувство безопасности.

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

Что потребовалось изменить

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

FAQ: Часто задаваемые вопросы

1. Почему нельзя просто заблокировать кнопку на фронте?

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

2. Чем идемпотентность отличается от дедупликации в БД?

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

3. Как долго хранить ключи идемпотентности?

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

4. Что делать со старыми клиентами, которые не шлют request_id?

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

5. Обязательно ли делать идемпотентность для всех методов API?

Идемпотентность требуется только для методов, которые изменяют состояние системы — POST, PUT, PATCH и иногда DELETE. Методы чтения (GET, HEAD, OPTIONS) не изменяют данные, поэтому считаются идемпотентными по умолчанию.

6. Как понять, что в вашей системе уже есть скрытая проблема с дублями?

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

Если метрик ещё нет, вот три косвенных признака, которые помогут заподозрить неладное:

• В базе данных периодически появляются записи с одинаковым содержимым, созданные с разницей в несколько секунд.
• Пользователи жалуются на дубликаты карт, заказов или платежей, но вы не можете воспроизвести проблему локально, списываете на то, что пользователи что-то делают не так
• В логах API Gateway периодически всплывают HTTP 500 ошибки, но downstream-сервисы при этом отрабатывают успешно.

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

Итог

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

Метрик на всплески повторных запросов у нас не было. А зря — это самый дешёвый способ увидеть проблему до того, как она обрушит продакшен. Системы, спроектированные на 10% нагрузки, ломаются на 60% — и обычно это становится неожиданностью для команды.

Практический чек-лист: что проверить в своей системе уже сегодня

• Убедитесь, что все критические мутирующие эндпоинты поддерживают ключ идемпотентности.
• Настройте алерты на аномальное количество запросов на создание сущностей от одного пользователя за короткий промежуток времени.
• Проверьте, как ваш API Gateway обрабатывает ошибки — не теряет ли он ответы downstream-сервисов.
• Убедитесь, что фронтенд корректно обрабатывает не только 200, но и 500, 502, 504, не провоцируя пользователя на повторные клики без необходимости.

Но пока что искусственный интеллект работает не идеально и может допускать ошибки и уязвимости. Чтобы увеличить надёжность результатов работы ИИ, есть несколько правил. Применять их можно даже без опыта разработки, достаточно использовать те же ИИ-инструменты. Что это за правила, рассказывает руководитель больших данных, высоконагруженных систем и машинного обучения Битрикс24 Александр Сербул.

Когда вайбкодинг — это риск

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

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

Создатель AI-агента Open Claw Питер Штайнбергер говорит: «Вайбкодинг — это навык, который прокачивается». Это значит, что использовать публично и в открытом доступе под нагрузками для критически важных процессов написанный ИИ код можно только при полном понимании того, как он работает.

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

Правило 1: выбираем строго типизированный язык

Программа работает с разными типами данных: числами, строками, логическими значениями.

Некоторые языки программирования более гибкие, например PHP, Python или JavaScript. В них можно менять типы данных по ходу работы программы — это может быть удобно разработчику, но для ИИ повышается вероятность допустить ошибку. Другой вариант — типизированные языки, которые заставляют разработчика сразу указывать, какие типы данных где находятся: TypeScript, Java, Kotlin, Rust. Человеку с таким языком работать труднее, но нейросети их понимают хорошо, и количество ошибок нейросети резко снижается.

Для гибких языков программирования решение тоже есть: можно добавить дополнительные аннотации типов и проверки-валидаторы типов данных. Пример такого валидатора — MyPy для Python.

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

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

Правило 2: включаем базовую проверку с помощью линтеров

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

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

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

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

Правило 3: пишем тесты

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

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

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

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

Правило 4: считаем тестовое покрытие

Следующий шаг, который нужен для надёжного вайбкодинга: общее тестовое покрытие.

Покрытие показывает, какая часть приложения проверяется тестами. Иначе может оказаться так, что тесты есть, но значительную часть кода они не проверяют. Покрытие измеряется в процентах. Например, покрытие в 75% может означать, что тесты проверяют 750 строк из 1000.

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

Правило четвёртое: считайте процент тестового покрытия. Минимальный процент — 70-80% программы.

Правило 5: проверяем входные данные, фреймворки и зависимости

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

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

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

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

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

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

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

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

Чтобы упростить процесс такого контроля за продуктом, можно использовать специально подготовленные платформы для ИИ-разработки, вроде Битрикс24 VibeCode или Replit. Такие платформы работают по разному: выстраивают ограничения для агентов, другие сразу направляют ИИ для работы с конкретными технологиями. Ещё в них используются техники минимизации рисков: серверы с запущенными приложениями недоступны для атаки снаружи, а данные из приложений фильтруются через слой защищённого официального REST API.

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

Насколько надёжнее становится результат вайбкодинга

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

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

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

Так вот — ReadGen. Блочный конструктор README-файлов. Месяц, 2-3 часа в день, React и TypeScript и небольшая пачка дополнительных библиотек для разумного облегчения жизни. Важно понимать что это не коммерческий продукт и не претендует на решение чьей-то боли. Просто техническая задача которую я давно хотел разобрать.

Демо: readgen-eight.vercel.app

Репозиторий: github.com/islamxm/readgen

Почему

contenteditable — старый добрый дед среди браузерных API. То что он старый - это да, а вот доброта - под вопросом.

Он искренне хочет помочь, сам расставляет <div> и <br>, сам решает что делать с Enter, сам форматирует как считает нужным. Проблема в том что его никто не спрашивал. Когда тебе нужен предсказуемый блочный редактор с контролируемой структурой данных — такая самодеятельность становится основным источником боли.

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

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

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

Три OM

Между реальным DOM и виртуальным DOM React затесался ещё один — MOM, Markdown Object Model. Пафосное название для того что по сути является flat map структурой документа. Но только по сути — на деле это целое ядро, состоящее из парсера, валидатора, гардов, движка, сериализатора. Это по сути модули без внешних зависимостей (кроме dexie.js в подмодуле storage) которые принимают данные, делают свое дело и отдают, впрочем как и принято в среде порядочных разработчиков.

Архитектурно MOM живёт как отдельный изолированный модуль — ведёт себя как shared слой в FSD, но это не набор утилит а самостоятельное ядро. Всё остальное приложение построено на гибриде FSD и layered подхода, но MOM существует по своим правилам.

Один DOM, два хозяина

Вот где настоящий конфликт. Структурой документа, порядком блоков, состоянием UI управляет React. Но внутри редактируемых блоков он полностью отступает. Там нет react рендеринга, только innerHTML и чистый DOM. Синхронизация происходит в эффекте, источник истины — содержимое contenteditable, и именно оттуда формируется MOM.

Два хозяина поделили территорию. React взял всё снаружи, DOM взял всё внутри. С одной стороны казалось бы все круто, так и должно быть, но на самом деле это порождает новый пласт проблем.

Отдельная история внутри этой истории — курсор. Позицию нужно постоянно сохранять и восстанавливать через selection/range API, и синхронизировать это с React. Это отдельная боль внутри общей боли.

Деструктивная синхронизация DOM — innerHTML = '' перед каждой манипуляцией выглядит грубо, зато работает. Можно было конечно написать свой reconciliation но учитывая исходные рамки по времени я решил отказаться.

Генераторы в сериализаторе

Экспорт документа в .md — финальная точка всей архитектуры. MOM → Serializer → файл. Впервые за все время своего осознанного программирования я решил тут применить генераторы в деле.

Каждый тип узла имеет свою функцию-генератор. Первый yield — контент блока, второй yield "" — пустая строка-разделитель. Тут мы избавляемся от аккумулятора который нужно тащить в глубь и код делаем более плоским и понятным. Array.from(gen).join("\n") в конце собирает всё в строку.

Drag and drop на Pointer Events

Кастомный drag and drop с анимацией как отдельный хук. И тут я познакомился с довольно таки мощными событиями класса pointer

о существовании которого я знал но почему то всегда обходился с touch

и mouse ивентами.

Pointer Events унифицируют всё что раньше требовало отдельных mouse и touch обработчиков. Без pointercancel drag зависает если браузер решает прервать жест сам. setPointerCapture — чтобы события не терялись когда курсор уходит за пределы контейнера.

Компромиссы

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

То же самое с блоком кода - MOMCode. Для этого я подключил библиотеку uiw, думаю в будущем заменю его на более современное и понятное решение.

Виртуализации нет, README на 10 000 блоков не существует в природе, проблема надуманная ну или просто не успел (выбирайте сами).

Мелочи которые просто есть и работают: менеджер глобальных шорткатов, тултипы для вставки блоков, эмодзи и форматирования текста, миниатюры документов через modern-screenshot, хранение в IndexedDB без бэкенда.

Заключение

Месяц закончился. contenteditable я теперь знаю лично — и он знает меня. Selection/Range из страшного незнакомца превратился в рабочий инструмент. Понял где React уместен, а где лучше отойти и дать DOM делать своё дело. Нашёл наконец задачу где генераторы оказались не паттерном ради паттерна а реально лучшим решением.

Демо: readgen-eight.vercel.app

Репозиторий: github.com/islamxm/readgen

Я Java-разработчик и в основном работаю с backend: Spring Boot, базы данных, интеграции, авторизация, WebSocket — всё то, что обычно находится за интерфейсом.

В какой-то момент я поймал себя на мысли: я каждый день пользуюсь мессенджерами, но плохо понимаю, как они устроены внутри. Окей, JWT, WebSocket, PostgreSQL, Redis — это понятно. Но что технически означает фраза "end-to-end encryption"? Как сервер доставляет сообщения, если он не должен их читать? Где живут ключи? Что хранится в базе? Что происходит, если у пользователя два устройства?

Решил разобраться через практику. Написал мессенджер с нуля. Назвал Chaos Messenger.

Сразу честно: криптографическую часть я изучал вместе с Claude и ChatGPT — читал спецификации X3DH и Double Ratchet, разбирал примеры, задавал вопросы, пока не сложилась цельная картина. Frontend тоже делался с активной помощью ChatGPT: я backend-разработчик, React для меня не основная среда. Но архитектура, backend, интеграция WebCrypto, модель конвертов, хранение сообщений и принципиальные решения — мои.

Для меня AI здесь был не заменой понимания, а инструментом — примерно как документация, Stack Overflow и ревью коллег. Без понимания threat model и архитектуры такой проект всё равно не собрать.

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

Стек: Spring Boot 3, React 18, WebCrypto API, PostgreSQL, Redis, WebSocket/STOMP, Prometheus, Grafana.

Важная оговорка про web-E2EE

Когда я говорю, что сервер не может прочитать сообщения, я имею в виду backend, базу данных, WebSocket-слой и уже сохранённые ciphertext-конверты. У них нет ключей и plaintext.

Но у web-E2EE есть отдельная проблема: frontend-код тоже приходит с сервера. Теоретически скомпрометированный сервер может отдать изменённый JavaScript, который украдёт ключи или plaintext до шифрования. Это ограничение не конкретно моего проекта, а браузерной модели в целом.

Поэтому корректная формулировка такая: backend не получает ключи и не может расшифровать уже переданные или сохранённые сообщения. Защита от подмены клиентского кода — отдельный слой безопасности: подпись сборок, независимая верификация клиента, desktop/mobile-приложения, reproducible builds.

Почему обычный подход не работает

Большинство "мессенджеров" на GitHub выглядят примерно так:

Сервер знает всё. Видит каждое сообщение. Если БД утекла — утекла вся переписка. Если сервер взломали — читай что хочешь. Если завтра компания решит продать данные — технически ничего не мешает.

E2EE решает это радикально: backend не получает ключи и не хранит plaintext. Сообщение шифруется на устройстве отправителя до отправки в сеть, а расшифровывается только на устройстве получателя.

Это уже не вопрос политики конфиденциальности в стиле "мы обещаем не читать". Это архитектурное ограничение: если у сервера нет ключа, он не может превратить ciphertext обратно в текст.

Звучит как магия. На самом деле — два протокола и немного WebCrypto.

Главная идея: конверты

Представь что Алиса хочет написать Бобу. Вместо того чтобы положить письмо на стол и надеяться что никто не прочитает — она кладёт его в запечатанный конверт. Конверт может открыть только Боб своим ключом. Сервер просто передаёт конверт не заглядывая внутрь.

Именно так это работает в коде. В базе данных у меня это выглядит так:

Когда я впервые увидел

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

А вот что сервер возвращает при запросе списка чатов через API:

Не

. Не

. Буквально

(DevTools → Network → ответ API с

)

Откуда берутся ключи: X3DH

Главный вопрос: как Алиса и Боб получают общий секрет, если они никогда раньше не общались? И как сделать это так, чтобы сервер только помог передать публичные данные, но сам не смог вычислить итоговый ключ?

Для этого используется X3DH — Extended Triple Diffie-Hellman, протокол из экосистемы Signal. Его задача — установить общий секрет между двумя устройствами, используя долгосрочные и временные ключи.

Что хранится на сервере

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

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

Здесь важно сказать честно: хранение приватных ключей в

Более строгий вариант — использовать Web Crypto API с

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

В браузерных E2EE-приложениях обычно приходится выбирать между несколькими вариантами:

• Сериализуемые ключи в localStorage или IndexedDB — проще реализовать, но нужно очень серьёзно относиться к XSS и целостности frontend-кода.
• extractable: false + IndexedDB — безопаснее, но сложнее в реализации и восстановлении состояния.
• Нативное secure storage вроде Android Keystore или iOS Secure Enclave — лучший вариант для мобильных клиентов, но он недоступен обычному web-приложению.

В текущей версии Chaos Messenger используется первый вариант. Это осознанный компромисс для pet/open-source проекта и удобного запуска в браузере. Переход на non-extractable ключи и более строгую модель хранения стоит в roadmap.

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

Установка сессии

Когда Алиса открывает переписку с Бобом впервые, происходит следующее:

В классическом X3DH четвёртая DH-операция с one-time prekey опциональна: она выполняется, если сервер выдал доступный OPK получателя. В моей реализации устройство публикует набор one-time prekeys при регистрации, поэтому первое сообщение обычно использует DH4. Если OPK закончились, сессию всё равно можно установить через остальные DH-компоненты, но это уже менее сильный вариант.

Боб, получив конверт с эфемерным публичным ключом Алисы, повторяет те же операции со своими приватными ключами и получает тот же самый

. Математика симметрична.

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

Получить

Как шифруется каждое сообщение: Symmetric Ratchet

X3DH даёт нам стартовый

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

Решение — симметричный ratchet. После каждого сообщения цепочка ключей продвигается вперёд:

Визуально это выглядит так:

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

— он прочитает только второе сообщение.

В рамках такой симметричной цепочки это даёт forward secrecy назад по цепочке: зная текущий или отдельный

Само шифрование сообщения:

А вот что уходит на сервер — живой пример из DevTools:

Сервер получает

и

. Расшифровать без

Важная оговорка: это ещё не полный Double Ratchet

В этом проекте реализован Symmetric Ratchet — цепочка, где из

для каждого сообщения выводится отдельный

Это защищает прошлые сообщения: если атакующий узнает текущий ключ или отдельный

, он не сможет откатить HMAC назад и получить старые ключи.

Но это не полный Double Ratchet из Signal Protocol.

В полном Double Ratchet есть ещё DH ratchet step: стороны периодически выполняют новый Diffie-Hellman обмен и обновляют root key. Это даёт break-in recovery — возможность восстановить безопасность будущих сообщений после компрометации части состояния.

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

Мультиустройство: один пользователь, несколько конвертов

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

Если у Боба два устройства — телефон и ноутбук — нужен отдельный encrypted envelope для каждого устройства. Сервер не может взять один конверт, расшифровать его и "переупаковать" для второго устройства: у него нет ключей и он не знает plaintext.

Значит при отправке сообщения нужно зашифровать его отдельно для каждого устройства каждого участника чата.

Для чата где у каждого по 2 устройства — 4 конверта на одно сообщение. Для группы из 10 человек — потенциально 20 конвертов. Это нормально, это цена безопасности.

Сервер: хранение и доставка конвертов

На сервере сообщение создаётся с контентом

, а конверты сохраняются отдельно:

После сохранения — fanout по WebSocket. Каждое устройство получает свой конверт и только его:

Это важное отличие от обычного WebSocket-чата. В обычном чате сервер рассылает одно и то же событие всем участникам. В E2EE-чате сервер рассылает разные события разным устройствам: payload для каждого устройства содержит свой

Топик

— строго персональный. Устройство А не получает конверт устройства Б. Никакого broadcast — только адресная доставка.

Архитектура целиком

Баг который долго не замечал

В панели чатов показывается превью последнего сообщения. Я реализовал это через

Запускаю — в списке чатов у всех написано

.

Конечно. Сервер же не знает что там написано.

Я полчаса думал как решить это на сервере. Потом дошло: нельзя решить это на сервере — у него нет ключей. Решение только на клиенте.

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

Это хороший пример того, как E2EE меняет привычное мышление backend-разработчика. В обычном приложении preview — это поле в SQL-запросе. В E2EE-приложении preview — это локальное клиентское состояние, потому что только клиент видел plaintext.

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

Rate limiting: дыра которую легко не заметить

Эндпоинт

отправляет SMS с кодом. Без защиты любой скрипт может дёргать его тысячи раз — это называется SMS pumping fraud, SMS стоят реальных денег.

Redis у нас уже был для хранения онлайн-статусов. Добавил rate limiting поверх него:

При превышении — HTTP 429 с заголовком

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

Важный нюанс: в текущей реализации, если Redis недоступен, сервис не блокирует авторизацию полностью. Для pet-проекта это приемлемый компромисс: лучше рискнуть одним лишним SMS, чем положить вход в приложение.

В production я бы сделал строже: fallback in-memory лимит на инстанс, отдельные лимиты по IP и телефону, антифрод-логику и алерты на всплески отправки кодов.

Авторизация WebSocket

Отдельная история — авторизация WebSocket соединений. HTTP-эндпоинты защищены Spring Security автоматически, но WebSocket — другое дело. STOMP-соединение устанавливается один раз, и нужно проверять JWT при каждом подключении.

Отдельно важно не только проверить JWT, но и связать WebSocket-соединение с конкретным устройством. Пользователь может быть один, но устройств у него несколько, а encrypted envelope адресован именно

Поэтому при подключении я проверяю не только токен, но и

: устройство должно быть зарегистрировано и принадлежать текущему пользователю. Иначе легко случайно превратить per-device E2EE-доставку обратно в обычный broadcast по пользователю.

Что получилось — живые скрины

Что реализовано:

• E2EE-модель с per-device encrypted envelopes
• X3DH session setup + Symmetric Ratchet + AES-GCM
• Мультиустройство
• Личные и групповые чаты
• Realtime доставка через WebSocket/STOMP
• Статусы SENT → DELIVERED → READ
• Редактирование и soft delete сообщений
• Online presence, typing indicator
• Фото-вложения
• Поиск пользователей
• Rate limiting на SMS через Redis
• Prometheus метрики + Grafana дашборд
• Swagger UI с JWT авторизацией
• 24 backend-теста на Testcontainers, 12 frontend на Vitest, E2E на Playwright
• GitHub Actions CI

Что ещё не сделано:

• Полный Double Ratchet с DH ratchet step и break-in recovery
• Ротация signed prekey и аккуратное пополнение one-time prekeys
• Более строгая модель хранения приватных ключей на клиенте: non-extractable CryptoKey + IndexedDB
• Защита от подмены frontend-кода: подпись сборок, независимая верификация клиента, reproducible builds
• Android-клиент с Android Keystore
• Реальный SMS-провайдер вместо кода в backend-логах
• Push-уведомления без утечки содержимого сообщений
• Более строгая metadata-модель для групповых чатов

Главный инсайт

E2EE — это архитектурное решение, а не библиотека.

Нельзя взять обычный Spring Boot чат и просто "включить шифрование". Нужно с самого начала проектировать систему так, чтобы backend не был участником доверенной зоны: он не должен получать plaintext, не должен иметь ключи и не должен уметь пересобирать сообщение из данных в базе.

Это меняет почти всё:

• структуру БД — вместо текста появляются encrypted envelopes
• API — сервер отдаёт [encrypted], а не preview сообщения
• WebSocket — доставка идёт не по пользователю, а по конкретному устройству
• мультиустройство — одно сообщение превращается в несколько ciphertext-конвертов
• frontend — становится полноценной криптографической частью системы, а не просто UI

Второй инсайт: мессенджер — это не "чат с WebSocket". В E2EE-модели это система доставки зашифрованных конвертов с адресацией по устройствам. Как только это принимаешь, многие странные на первый взгляд решения становятся логичными.

Репозиторий

Код открыт: github.com/vaazhen/chaos-messenger

В репозитории есть README на русском и английском, диаграммы, скриншоты, security audit, Docker Compose и запуск одной командой.

Проект не претендует на уровень production-криптомессенджера вроде Signal. Это учебный и инженерный open-source прототип, цель которого — показать, как E2EE меняет архитектуру backend, frontend и realtime-доставки.

Если вы делали что-то похожее — особенно интересно сравнить подходы к ротации prekey-ов, хранению non-extractable ключей в браузере и реализации DH ratchet step. Вопросы и критика приветствуются.

Мы остановились на открытом симуляторе InferSim от Alibaba. Он умеет считать TTFT, TPOT и пропускную способность без запуска реального инференса. Но из коробки поддерживает только несколько топовых GPU и фиксированный набор моделей — для наших сценариев этого было недостаточно. Пришлось дорабатывать.

Как устроен InferSim

В основе симулятора — двухфазная схема. Сначала на целевом железе запускаются микро-бенчмарки: измеряется реальная производительность на типовых операциях внимания и матричных умножениях. Получается таблица коэффициентов Model FLOPs Utilization (MFU) — сколько процентов от теоретического максимума выдаёт конкретная карта на конкретной операции. Затем, уже без доступа к GPU, симулятор на основе этих MFU и аналитической модели вычисляет задержки. Именно такой подход даёт более точные предсказания, чем оценка по паспортной пропускной способности памяти.

Добавляем своё железо

Первым делом мы внесли в hardware/gpu.py поддержку MetaX C500 64GB. Характеристики добавляются через dataclass-экземпляры:

После этого c500 попадает в словарь gpu_map, и симулятор запускается с ключом --device-type C500 --world-size 2. Значения FLOPS и пропускной способности пришлось оценивать по косвенным источникам — производитель не публикует точных цифр. Позже планируем уточнить их через бенчмаркинг на реальном оборудовании. Таким же способом добавили Nvidia 1xH100 и A100.

Конфигурация моделей и одна болезненная ошибка

Симулятор ожидает стандартный config.json в формате Hugging Face. Для Qwen3-32B подготовили файл qwen3_32b_config.json:

Ключевой момент — правильное значение head_dim. У Qwen3-32B оно равно hidden_size / num_attention_heads = 5120 / 64 = 80. У нас ушло некоторое время, чтобы понять, почему симулятор выдаёт невалидные результаты: изначально в конфиге стояло значение 128. Пока не исправили — KV-кеш переоценивался, и метрики улетали в неадекватные цифры. После исправления всё встало на свои места.

Позже добавили поддержку Qwen3.5‑9B с её гибридной архитектурой, построенной на чередовании Gated DeltaNet и Gated Attention. Главная особенность модели в том, что около трёх четвертей слоёв не создают привычного KV‑кеша, а используют линейное внимание – компактное скрытое состояние, которое лишь обновляется с каждым новым токеном, не увеличиваясь в объёме. Это кардинально снижает расход памяти на длинных контекстах, но привносит и свою цену: на коротких дистанциях такая модель проигрывает в скорости Prefill, потому что Gated DeltaNet работает последовательно и хуже утилизирует матричные вычисления GPU.

Симулятор изначально не умел различать слои двух типов и считал весь KV‑кеш одинаково. Чтобы поддержать Qwen3.5, пришлось доработать расчёт задержек в классе HybridModel: теперь он отдельно обсчитывает full‑attention‑слои с полным кешем и linear‑attention‑слои без кеша, используя параметры num_full_attn_layers и num_linear_attn_layers из конфигурации. В директорию проекта models добавили hybrid_model.py, в котором сделали дополнительные расчёты:

Без такой дифференциации симулятор для Qwen3.5‑9B показывал E2E порядка 2 500 секунд вместо реальных нескольких секунд – та ошибка, которую мы долго отлавливали.

Визуализация и эксплуатация

Чтобы не разбирать каждый раз текстовый вывод InferSim, сделали веб-интерфейс на Streamlit. Симулятор дёргается через subprocess, результаты парсятся из stdout и визуализируются:

• тепловые карты задержек (Prefill, Decode, E2E Total) для разных длин входных и выходных токенов;
• анализ RPS с расчётом требуемой параллельности и сравнением с доступной памятью;
• информация о занятой памяти в формате «X ГБ из Y ГБ».

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

Приложение упаковано в Docker и лежит в репозитории на GitHub. Сервисы — сам Streamlit и Nginx в качестве обратного прокси с SSL-терминацией и базовой HTTP-аутентификацией. Деплой на VDS автоматизирован через GitHub Actions: собрали образ, отправили на сервер, перезапустили контейнеры. SSL-сертификаты Let's Encrypt обновляются по cron.

Что в итоге

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

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

Мне эта модель быстро наскучила.

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

Сразу зафиксируем рамки, чтобы не плодить фантомные ожидания:

- это не убийца Telegram;

- это не презентация для инвестора с KPI и growth loops;

- это не проповедь о том, как всем теперь жить.

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

И вот здесь началось смешное.

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

Что это вообще такое

На текущем этапе это PWA-мессенджер.

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

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

Почему все равно PWA:

- мне нужен был короткий путь от идеи до живого клиента;

- мне нужен был быстрый цикл выката без ритуальных танцев с

магазинами приложений;

- мне нужен был клиент, который можно быстро ломать, чинить,

пересобирать и снова кидать в бой;

- мне нужно было что заработает на разных платформах;

- мне нравится, что PWA живет в браузерной песочнице, а не лезет в телефон как хозяин квартиры.

У PWA есть реальные потолки:

- нет такой свободы по платформенным API, как у нативного клиента;

- фон, пуши и некоторые сценарии мобильной жизни работают хуже, чем

хотелось бы;

- нет нормальных VoIP-пушей (звонки работают только когда приложение

открыто), нет нормальной интеграции со списком вызовов телефона;

- по голой производительности натив его обгоняет.

И, да, Service Workers иногда ведут себя как подростки в пубертате, а iOS местами режет фоновую жизнь PWA так, будто лично обиделась на идею веб-клиента. Я в курсе. Выживаем с тем, что есть.

Но для моей задачи PWA дал главное: скорость эволюции. А в экспериментальном проекте это иногда важнее, чем стерильная идеология.

И да, работает эта штука подозрительно хорошо. Лучше, чем я ожидал, если честно.

Зачем вообще писать еще один мессенджер, когда мир и так ими забит

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

Потому что я люблю контролировать инфраструктуру, а не молиться на чужую.

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

Потому что мне скучно.

Да, это тоже важная часть правды. На обычной работе мозг периодически начинает зевать от предсказуемости. А когда ты в одиночку пытаешься собрать живой real-time-сервис, где есть сессии, доставка сообщений, поиск, синхронизация состояния, очереди и weird cases мобильной сети —

то зевота быстро заканчивается.

То есть да: это учебный проект. Но из тех учебных проектов, которые в какой-то момент говорят: «всё, детский сад закончился, теперь давай как взрослые».

Где начинаются не разговоры про highload, а настоящая инженерная жизнь

Пока не собираешь такое сам, кажется, что мессенджер — это просто чатик.

Ну текстик, ну websocket, ну кнопка «отправить», господи. А потом начинается взрослая часть спектакля.

1. Сообщение должно не просто уйти, а дойти правильно

Самая скучная и самая дорогая ошибка — считать, что «отправил» значит

«доставил».

Нет. В реальной жизни между клиентом, сетью, сервером и хранилищем полно мест, где всё может стать интересно:

- клиент послал пакет, но сеть моргнула;

- сервер принял, но клиент не получил подтверждение;

- клиент решил, что ничего не дошло, и отправил повторно;

- внезапно у тебя уже не просто доставка, а идемпотентность,

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

дублями.

И это только один кусок.

2. Порядок сообщений — штука гораздо более капризная, чем кажется

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

Инженерная реальность куда веселее:

- локальный optimistic update на offline-first клиенте хочет быть

быстрым;

- серверная истина хочет быть правильной;

- база хочет жить в своей временной линии;

- несколько устройств одного пользователя могут в это время смотреть на

мир разными глазами.

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

3. Race condition — это когда баг уже произошел, но ты еще не знаешь, где именно тебя унизили

Race conditions — мой любимый жанр инженерного фольклора. Это когда всё прекрасно, пока ты смотришь. И ломается ровно в тот момент, когда отвлекся налить кофе.

Условно:

- один поток думает, что пользователь в онлайне;

- второй уже считает, что он отвалился;

- третий в это время честно пишет новое состояние;

- четвертый с невинным лицом отдает клиенту вчерашнюю правду.

А потом ты сидишь и объясняешь себе, почему в 99.7% случаев всё идеально, а в оставшихся 0.3% система внезапно начинает разговаривать голосами. А когда еще и пытаешься заставить работать реалтайм систему еще в кластере, то все сложности возводятся в квадрат.

4. Любая «маленькая фича» очень быстро приходит за твоей архитектурой с ножом

Захотел новую механику? Например, необычную резервацию UIN еще до регистрации? На бумаге выглядит забавно. На бэкенде начинается вечеринка:

- появляется состояние для еще не существующего пользователя;

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

- нужно думать о TTL, освобождении, гонках, повторных запросах и кривом клиентском поведении;

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

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

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

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

И тут выясняется, что в реальном мессенджере мало просто «хранить сообщения». Нужно еще:

- быстро искать;

- не ломать горячий путь доставки;

- не превращать сервер в печку под нагрузкой;

- думать наперед, где потом начнется горизонтальное масштабирование, а

где сначала будет боль, потом переписывание, потом снова боль.

Чтобы это не выглядело как очередная литература про «сложности highload», вот живой пример. Это кусок поиска по групповым сообщениям в моем бекенде: с проверкой доступа, выборкой только текстовых сообщений и сортировкой по релевантности.

Под этот запрос у меня лежит не молитва, а вполне конкретная опора: partial GIN index по выражению`(content->>'text') gin_trgm_ops`.Иначе такая красота очень быстро превращает сервер в отопление стойки за счет тупого перебора JSONB.

А вот так тот же самый функционал очень часто пишут новички — вроде работает, пока данных смешно мало:

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

На реальном объеме истории в проде разница здесь может быть уже не в процентах, а на порядок и выше. То есть это очень быстро превращается не в «чуть-чуть быстрее», а в 10x+, а дальше всё зависит от размера истории, доли текстовых сообщений, партиций и того, насколько сильно вы любите мучить PostgreSQL.

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

6. Очереди, ретраи и backpressure — это не украшения, а повод спать чуть спокойнее

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

То есть нужны:

- очереди (Kafka, или что вы там предпочитаете);

- повторные попытки (retry-логика);

- backpressure;

- вменяемая реакция на временную деградацию (graceful degradation);

- circuit breaker чтобы какой-нибудь маленький и вроде бы некритичный сервис не мог каскадно положить бы всю инфраструктуру;

- архитектура, которая умеет признавать, что мир не идеален.

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

Интерфейс я подсматривал у Telegram. И да, специально

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

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

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

Моя любимая инженерная шалость: UIN-рулетка до регистрации

Тут я, конечно, немного похулиганил.

Я сделал резервацию UIN еще до этапа регистрации. То есть можно зайти, поймать красивый номер, а уже потом решить, нужен тебе вообще этот зоопарк или нет.

С человеческой стороны это фан, ностальгия и немного ICQ-вайба.

С серверной стороны это пачка вопросов:

- как хранить состояние для «почти-пользователя»;

- как не раздать красивые номера слишком щедро;

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

- как освобождать резервы и не плодить мусор;

- как не застрелить логическую целостность ради красивой игрушки.

С практической точки зрения миру, возможно, и не нужна эта фича. С инженерной — она просто слишком вкусная, чтобы я прошел мимо.

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

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

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

- транспорт закрыт современным TLS 1.3 (который на текущий момент, март 2026, взломать прямым криптографическим методом практически невозможно);

- клиент живет как PWA в браузерной песочнице, какая уже сама по себе имеет ряд уровней защиты;

- поверх этого я стараюсь не творить откровенной дичи;

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

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

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

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

Почему я вообще тащу это именно на TProger

Потому что TProger — это место, где тексту мало быть наглым. Здесь за дерзость прощают только одно: если под ней есть мясо.

А у меня как раз тот случай, когда мне интереснее не «собрать лайки», а получить нормальную техническую реакцию:

- где архитектура выглядит спорно;

- где логика доставки сообщений может начать чудить;

- где PWA упрется в реальные ограничения платформы;

- где резервация UIN создает лишнюю поверхность атаки;

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

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

Мне не нужен хор в духе «вау, круто».

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

Вот ему я и пишу.

Что я от вас хочу

По сути — честной драки, но умной.

- Хотите проверить, как это переживает плохую сеть — отлично.

- Хотите посмотреть, как выглядит поведение в edge-cases — вообще прекрасно.

- Хотите понять, насколько легко читается логика протокола — давайте.

- Хотите найти баг в порядке сообщений, в кеше, в подтверждениях, в резервации UIN, в клиентском поведении — тем более.

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

Мне это полезнее, чем аплодисменты.

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

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

Что можно делать прямо сейчас

- Если вы параноик или устали от мейнстрима и навязанных решений — держите это как запасной канал связи.

- Если вы соскучились по временам красивых UIN — приходите ловить UIN-номер.

- Если вы любите sniff, разбор трафика и сетевые игры — смотрите что идет по проводу.

- Если у вас профессиональная привычка первым делом искать edge-cases — вот, собственно, ради вас всё это и принесено.

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

Что дальше

Планы без корпоративной шелухи, но вполне понятные:

- дальше допиливаю PWA-версию;

- нативные Android и iOS-клиенты — в планах, но пока не в приоритете;

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

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

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

Итог

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

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

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

Если хотите просто еще один канал связи — пожалуйста.

Если хотите посмотреть и проверить, насколько крепок мой цифровой эксперимент, — тем более пожалуйста.

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

Добро пожаловать.

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

PS:

Меня там можно найти по нику IGRYM или по UIN 10001. Также есть внутренняя группа для первых пользователей (Early Birds, доступна на экране списка чатов через «+» вверху экрана)

Ссылки:

- Приложение: https://beta.plumb-app.ru/

- Телеграм-канал с новостями проекта: https://t.me/plumb_channel

- Телеграм-группа обсуждения: https://t.me/plumb_group

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

Момо нажимает клавиши на Bluetooth-клавиатуре. Сигнал проходит через Raspberry Pi 5 в небольшое Rust-приложение DogKeyboard, которое фильтрует спецклавиши и передает ввод ИИ Claude.

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

• отправляет текст в Claude Code,
• запускает сборку игры (на Godot 4.6, логика — на C#),
• выдает собаке лакомство через автоматическую кормушку,
• звуковым сигналом сообщает, что ИИ готов к следующему «брифингу».

Один цикл — и еще один уровень готов. На создание играбельной сборки уходит 1–2 часа.

Главный трюк — не в собаке

Самое сложное, по словам Лика, было не научить собаку «долбить» клавиши, а убедить Claude воспринимать бессмысленный ввод как осмысленные команды.

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

Это глупость или в этом все же что-то есть?

Формально Момо не «кодит». Но эксперимент показывает, насколько гибко современные агенты могут интерпретировать даже абсурдный ввод.

Да и в целом, как фановый проект, ставший популярным мемом — отличное отражение времени.

Почему профессиональный инструмент может быть бесплатным

Серьезные инструменты для работы, дизайна или программирования не обязательно стоят больших денег. Есть целая экосистема профессиональных программ с открытым исходным кодом (так называемое open-source ПО). И пользоваться ими можно абсолютно бесплатно. Open-source — это когда исходный код программы, ее «цифровая кухня», открыт для всех. Пользователь может не только использовать приложение, но и улучшить его, предложить свой вариант начинки или поделиться модификацией с другими. Такой подход объединяет тысячи разработчиков по всему миру, которые вместе создают, проверяют и совершенствуют ПО. Это похоже на мировую научную лабораторию, где знания и наработки открыты для всех, что ускоряет прогресс.

Конкуренция здесь основана не на цене (обычно она нулевая), а на качестве, надежности и активности сообщества. Уже сейчас целые индустрии опираются на открытое ПО:

• В кино и анимации популярен Blender, открытое приложение для 3D-моделирования и анимации. Его используют для создания спецэффектов и полнометражных фильмов.
• В разработке игр с коммерческими аналогами конкурирует движок Godot, который позволяет создавать полноценные игры для самых разных платформ.
• В веб-дизайне — Figma, в ее основе также лежат открытые компоненты.

А эта статья посвящена одному из главных открытых приложений в мире дизайна — графическому редактору GIMP (GNU Image Manipulation Program). Это профессиональный полностью бесплатный инструмент, который идеально подходит для того, чтобы начать путь в цифровом творчестве.

Далее мы подробно разберем:

• Для каких задач предназначен редактор GIMP.
• Почему он является отличной стартовой площадкой для обучения ребенка графическому дизайну.
• Интерфейс и первые шаги в GIMP.
• А также сравним GIMP и Adobe Photoshop, чтобы вы могли сделать осознанный выбор между ними, исходя из целей обучения.

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

Что такое GIMP

GIMP — это растровый графический редактор с большой историей и собственной философией. Его название расшифровывается как GNU Image Manipulation Program (Программа для обработки изображений GNU). Он был создан в 1995 году как университетский проект и с тех пор развивается силами международного сообщества программистов, дизайнеров и энтузиастов. Это значит, что над его улучшениями и обновлениями работают не наемные сотрудники одной компании, а люди со всего мира, которым важна сама идея свободного и доступного творчества.

Философия GIMP основана на принципах открытого программного обеспечения. Это выражается в нескольких простых, но важных вещах:

• Бесплатно навсегда. Вы можете скачать GIMP, установить его на любое количество компьютеров (домашний, школьный, ноутбук) и использовать сколько угодно без каких-либо платежей или ограничений по времени.
• Свобода использования. Программу можно применять для любых целей: для обучения, личных, творческих проектов или коммерческой работы.
• Открытый код. Исходный код GIMP доступен для изучения. Для большинства пользователей это просто любопытный факт, но он имеет большое значение. Благодаря этому:— программа независима и не принадлежит ни одной корпорации;— ее безопасность и надежность постоянно проверяются независимыми экспертами;— для продвинутых пользователей или старшеклассников, увлекающихся программированием, это возможность заглянуть «под капот» и понять, как устроены сложные алгоритмы обработки изображений на самом деле.

Для каких задач предназначен GIMP

GIMP — это редактор, который покрывает практически все базовые потребности в цифровой графике — от бытовых до прикладных профессиональных.

Обработка фотографий. В GIMP есть все необходимые инструменты для превращения сырых снимков в отличные картинки.

• Ретушь — удаление мелких дефектов кожи, лишних предметов на фоне, пыли с отсканированных старых фотографий. Для этого используются инструменты «Штамп», «Восстанавливающая кисть» и «Лечащая кисть».
• Цветокоррекция — исправление слишком темных или блеклых снимков, изменение цветового баланса, усиление контраста. Работа ведется через «Уровни», «Кривые» и «Цветовой баланс».
• Создание коллажей — вырезание объектов с одних фотографий и аккуратное размещение их на других с подбором освещения и тени. Основные навыки здесь — работа с инструментами выделения («Лассо», «Волшебная палочка») и масками слоев.

Создание графики для соцсетей. Востребованное и понятное для детей и подростков направление.

• Обложки и аватары для YouTube, VK, Telegram каналов.
• Посты и сторис с текстом, эффектами, наложением графики на фотографии.
• Баннеры для школьного проекта или личного блога.

Здесь, помимо обработки фото, нужна работа с текстом, заливкой, фигурами и эффектами слоев (тени, обводки).

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

• Кнопки и иконки для сайтов или приложений. Создаются с помощью векторных контуров (инструмент «Контуры») и стилей слоя.
• Текстуры для 3D-моделей или 2D-игр. Например, можно нарисовать кирпичную стену, деревянную доску или металлическую поверхность, используя фильтры шума и рельефа.
• Спрайты и элементы интерфейса для простых игр, создаваемых, например, в Roblox Studio или других конструкторах.

Рисование цифровых иллюстраций. При подключении графического планшета GIMP превращается в полноценный холст для художника.

• Можно создавать рисунки с нуля, используя различные кисти, которые имитируют акварель, масло, карандаш.
• Редактор поддерживает давление пера, что позволяет контролировать толщину линии и прозрачность мазка в зависимости от нажима.
• Иллюстрацию можно строить поэтапно, на отдельных слоях: сначала набросок, потом цвет, потом тени и блики.

Подготовка макетов для печати. Сложная, но полезная задача, которая учит внимательности к деталям. В нее входит создание визиток, открыток, листовок или небольшого плаката. Для этого необходимо настроить правильный размер холста, выдержать «безопасные» отступы от краев, установить правильное разрешение (обычно 300 dpi) и работать в цветовой модели CMYK для точной цветопередачи при типографской печати. GIMP позволяет решать все эти задачи.

Перспективы изучения GIMP для ребенка

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

Системное и алгоритмическое мышление. Работа в графическом редакторе — это цепочка логических шагов. Ребенок учится:

• Декомпозиции — разбивать сложную задачу (например, «сделать крутую обложку») на простые последовательные этапы: найти фон, вырезать объект, добавить текст, применить эффекты.
• Работе с абстракциями — понимать, что изображение состоит из виртуальных слоев. Умение организовать слои, давать им понятные имена, группировать их — это прямой аналог организации кода или любого сложного проекта.
• Применению логических операций — маски слоя и выделения по принципу работы близки к условным операторам в программировании (if/else). Фильтры — это, по сути, готовые алгоритмы обработки изображения, применение которых меняет результат по строгим правилам.

Понимание принципов цифровой графики. Изучая редактор GIMP, ребенок осваивает не только расположение кнопок и функции в конкретной программе, но и универсальные концепции цифровой графики: что такое растровое изображение, разрешение, цветовые модели (RGB/CMYK), коррекция по кривым, работа с каналами.

Позже, при необходимости освоить Adobe Photoshop, Affinity Photo или профессиональные инструменты для ретуши, он столкнется с уже знакомыми понятиями, реализованными в другом интерфейсе.

Гибкость мышления. На современном рынке ценится способность быстро осваивать новые инструменты и понимать общие принципы, а не знание одного программного продукта. Опыт работы с open-source решением, построенным на логике, а не на маркетинговых упрощениях, воспитывает именно такую гибкость.

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

Знакомство с интерфейсом

Первое, что видит пользователь после запуска GIMP, — это рабочее пространство с логичной структурой, внешний вид настраивается под задачи.

Основные элементы рабочего пространства:

Главное окно (окно с изображением). Это центральная область, где отображается и редактируется фотография или рисунок. Его можно сравнить с основным холстом художника. Сверху находится стандартное меню («Файл», «Правка», «Вид» и т.д.), откуда доступны все функции программы.

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

• Инструменты выделения: прямоугольное и эллиптическое выделение, «Лассо», «Волшебная палочка». Они нужны, чтобы указать программе, с какой конкретной областью изображения вы хотите работать.
• Инструменты рисования и ретуши: «Кисть», «Карандаш», «Ластик», «Штамп», «Восстанавливающая кисть». С их помощью рисуют, закрашивают области или убирают дефекты.
• Рабочие инструменты: «Перемещение», «Масштаб», «Текст», «Заливка», «Градиент».

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

Панель слоев, каналов и контуров. Это, как правило, правая панель с несколькими вкладками. Самой важной является вкладка «Слои».

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

Другие важные панели редактора GIMP:

• «История действий» — полный список всех выполненных шагов. Если вы сделали ошибку, можно как отменить последнее действие (Ctrl+Z), так и вернуться сразу на несколько шагов назад, щелкнув по нужному пункту в истории.
• «Кисти», «Текстуры», «Градиенты» — библиотеки ресурсов для инструментов рисования и заливки.

Важно: все эти панели — плавающие. Их можно откреплять, перемещать, закрывать и снова открывать через меню «Окно». Это позволяет создать рабочее пространство, максимально удобное именно для поьзователя. Если ребенок случайно закрыл нужную панель, ее всегда можно вернуть через пункт меню «Окно» -> «Закрепляемые диалоги».

Основные принципы работы в редакторе GIMP

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

Слои — основа порядка

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

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

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

Сочетание клавиш для создания нового слоя — Ctrl+Shift+N.

Определение рабочей зоны

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

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

Основные инструменты:

• Прямоугольное/Эллиптическое выделение — для работы с четкими геометрическими формами.
• Свободное выделение (Лассо) — позволяет вручную обвести объект по контуру.
• Волшебная палочка — автоматически выделяет области одного цвета. Полезно для отделения объекта от однородного фона.

Сначала нужно научиться создавать точное выделение, а уже потом выполнять над ним любые действия. Снять выделение можно клавишами Ctrl+Shift+A.

Инструменты ретуши: «Штамп» и «Восстанавливающая кисть»

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

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

Для удаления мелких дефектов чаще используют «Восстанавливающую кисть», а для крупных областей с повторяющейся текстурой больше подойдет «Штамп» (например, для клонирования травы).

Работа с текстом

Для добавления надписей выберите инструмент «Текст» (значок «А»), щелкните по холсту и начните печатать. Автоматически создастся новый текстовый слой.

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

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

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

GIMP или Adobe Photoshop

Сравним GIMP и Adobe Photoshop по основным параметрам.

Цена и доступность

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

Adobe Photoshop доступен только по подписке (Adobe Creative Cloud) — а это регулярные платежи. Если подписка прекращается, доступ к программе и вашим файлам в родном формате (.psd) блокируется. Для ребенка, который только пробует свои силы, подписка может быть неоправданной тратой.

Интерфейс и удобство

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

Интерфейсы Photoshop и GIMP похожи, но у второго он более «технический» и модульный. В редакторе GIMP логика работы вынесена на передний план. Пользователь явно видит и управляет слоями, каналами, масками. Это напрямую способствует пониманию основ. В GIMP ребенок учится не нажимать волшебную кнопку «Улучшить», а осознанно работать с кривыми, чтобы сделать картинку светлее или контрастнее. Для образовательных целей это преимущество.

Функционал для обучения

Главный вопрос: есть ли в GIMP все необходимое для освоения графического дизайна? Ответ — да.

• Работа со слоями и масками реализована полностью. Все принципы композиции, неразрушающего редактирования и организации проекта здесь можно изучить в полном объеме.
• Кривые, уровни, цветовой баланс. Все инструменты для профессиональной цветокоррекции и тоновой коррекции присутствуют и работают по общепризнанным алгоритмам.
• Инструменты ретуши: «Штамп» (Клонирование), «Восстанавливающая кисть», «Заплатка» — все основные инструменты для удаления дефектов есть.
• Выделения и работа с контурами — полный набор инструментов для точного выделения объектов.
• Работа с текстом: создание текстовых слоев, базовое форматирование.

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

Производительность

Здесь между Photoshop и GIMP также есть разница. GIMP, как правило, менее требователен к ресурсам компьютера. Он хорошо работает на средних и даже не самых новых домашних ПК и ноутбуках.

Для полноценной работы в Photoshop нужен современный процессор, достаточный объем оперативной памяти (16 ГБ и более) и дискретная видеокарта для ускорения отдельных функций.

Экосистема и поддержка

Photoshop является частью огромной экосистемы Adobe Creative Cloud. Его преимущество — в бесшовной интеграции с Illustrator (векторная графика), After Effects (анимация), InDesign (верстка). Это может быть критически важно для профессионалов в издательском деле или рекламе.

GIMP — независимый инструмент, хотя он отлично сочетается с другими open-source программами: векторным редактором Inkscape, программой для цифровой живописи Krita, редактором RAW-файлов Darktable.

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

Реклама. Рекламодатель ООО «Пиксель.Стади», ИНН 5074078988, erid: 2W5zFK4efwv

Судя по всему, это те самые приложения, которые были собраны на скорую руку с помощью ИИ. В базе уже 167 приложений. Проект опубликован на платформе Firehound и активно обсуждается в сообществе iOS-разработчиков на Reddit.

Что именно нашли

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

В реестре уже есть приложения с:

• десятками миллионов записей в открытых базах;
• доступными коллекциями profiles, posts, comments, likes;
• утекшими email-адресами, никнеймами, метаданными активности.

Один из лидеров антирейтинга — приложение Adult Coloring Book – Pigment. У него более 7,7 млн документов оказались доступны без какой-либо аутентификации.

Причем тут вайб-кодинг

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

Типичный сценарий:

• ИИ предлагает использовать Firebase, Supabase или MongoDB.
• Конфигурация безопасности либо отсутствует, либо остается дефолтной.
• Ключи и переменные окружения попадают в клиентский код.
• База становится публичной — иногда буквально в один клик.

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

Это не взлом — и в этом главная проблема

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

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

Теперь ИИ может работать с данными из Gmail, Google Фото и YouTube, чтобы отвечать не на абстрактные вопросы, а на запросы, связанные с жизнью конкретного пользователя.

Функция уже доступна в бете для подписчиков Google AI Pro и AI Ultra в США. По умолчанию она отключена — пользователь сам решает, давать ли Gemini доступ к личным данным.

Что именно умеет Personal Intelligence

Идея проста: вместо ручного поиска по почте или фотоархиву, пользователь может задать вопрос напрямую. Например, Gemini может распознать деталь автомобиля на снимке из Google Фото и тут же найти письмо с чеком или подтверждением покупки в Gmail.

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

Как включить новую функцию

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

• открыть приложение Gemini;
• перейти в настройки;
• выбрать пункт Personal Intelligence;
• в разделе Connected Apps указать, к каким сервисам Gemini может получить доступ — например, Gmail или Google Фото.

Google подчеркивает, что функция работает только после явного согласия пользователя.

Польза против приватности

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

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

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

После планового МРТ, он получил USB-флешку с медицинскими данными. Но открывались они лишь через коммерческое Windows-приложение от производителя оборудования. Лютке такой вариант не устроил и он решил сделать собственный инструмент.

Вместо поиска альтернатив или подписки на очередной проприетарный софт, он просто запустил Claude и дал ему доступ к данным на флешке. Через минуту у него был HTML Viewer для анализа снимков прямо в браузере.

Что именно он сделал с помощью ИИ

Лютке публично выложил промпт, которым пользовался:

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

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

Почему этот кейс важнее, чем кажется

История быстро разошлась по соцсетям не потому, что код написал CEO крупной компании. Людей удивило то, как он это сделал. По сути, Лютке за минуту заменил нишевый SaaS-продукт, который десятилетиями продавался клиникам и пациентам.

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

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

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

Google называет Disco «исследовательской платформой», а не готовым продуктом. Сейчас он доступен только для ограниченного числа пользователей — доступ можно попросить на специальной странице (но только на macOS).

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

GenTabs построен на базе модели Gemini 3 и использует сразу несколько источников контекста. В том числе текущие вкладки, историю взаимодействия и диалог с пользователем.

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

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

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

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

Вкладки как приложения, а не как список

Ключевая идея Disco — уйти от модели, где вкладки существуют сами по себе.

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

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

Мы собрали пять свободных инструментов, которые решают типичные задачи разработчика: от скачивания видео с любых сайтов до защиты от подглядывающих коллег. Все они работают локально или 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-ключи или видео с камеры. Код открыт, можно проверить, как всё устроено, и при желании — доработать под свои нужды.

Мессенджер MAX снова испытывает масштабный сбой. Утром 30 марта 2026 года пользователи по всей России начали массово жаловаться на недоступность сервиса — приложение не открывается, сообщения не отправляются, а у части пользователей не приходят уведомления.

Проблемы затронули Android, iOS и веб-версию. По данным Detector404, резкий всплеск жалоб начался около 09:25 МСК — число обращений быстро приблизилось к тысяче. Больше всего жалоб поступает из Москвы, Самарской области, Краснодарского края и Санкт-Петербурга.

Это уже не первый крупный сбой MAX в 2026 году: 10 февраля сервис также массово «падал» (тогда пресс-служба утверждала, что «всё работает в штатном режиме»). А накануне, 29 марта, фиксировались проблемы с VK Видео — сервисом из той же экосистемы VK.

Официальных комментариев от команды MAX по сбою 30 марта пока нет.

Предыдущий сбой MAX — 8 декабря 2025 года

8 декабря 2025 года мессенджер MAX столкнулся с крупным техническим сбоем.

По данным Detector404, количество жалоб за последний час превысило 944, а за сутки — более 1200. При этом сервис «упал» практически мгновенно — на графике видно резкое вертикальное поднятие кривой жалоб.

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

Со сбоем столкнулись как владельцы Android-смартфонов, так и iPhone. И даже пользователи веб-версии.

География сбоя 8 декабря

Проблемы фиксировались в десятках регионов. Среди лидеров по числу жалоб — Краснодарский край, Республика Коми, Алтай, Новосибирская область, Республика Саха (Якутия) и Москва.

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

• «не работает приложение»;
• «невозможно отправить сообщение»;
• «не приходит код авторизации»;
• «не открывается MAX, пишет ошибку сети».

Где именно «ломался» MAX

Согласно статистике Detector404, 45,9% жалоб пришло от пользователей Android, 29,7% — от владельцев iPhone и 18,9% пришлось на долю веб-версии.

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

Отдельная часть пользователей жаловалась, что мессенджер «видит интернет», но фактически не соединяется с серверами.

Что говорили пользователи и что было известно официально

Команда MAX тогда не опубликовала официального комментария. Пользователи предполагали, что это либо крупная внутренняя авария, либо сбой в CDN/серверной инфраструктуре.

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

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

Но теперь эта «шутка» стала наглядной — проект 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.

По данным следствия, подросток создал программу с помощью ChatGPT и использовал ее для «несанкционированного доступа к серверам компании».

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

Всего он успел выгрузить около 7,25 млн записей, включая личную информацию членов Kaikatsu Club.

Как школьнику удалось взломать систему

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

Источники TBS сообщают, что программа генерировала последовательность запросов, которые обманывали сервер приложения Kaikatsu Frontier и вынуждали его выдавать данные о пользователях.

Из-за повторяющихся атак приложение неоднократно выходило из строя — фактически школьник парализовал работу части сервисов сети.

Что это за задержанный подросток такой

В ноябре он уже попадал в поле зрения полиции: тогда его арестовали за покупку карт Pokémon по украденным реквизитам.

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

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

Утром 3 декабря в России случился масштабный сбой — тысячи пользователей не смогли зайти в Roblox.

По данным Detector404, сервис зафиксировал более 1400 жалоб всего за сутки. При этом по подсчетам сервиса, с проблемой и вовсе столкнулось до 65 000 человек.

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

На данный момент проблемы отмечаются в 25 городах — от крупных региональных центров (вроде Москвы и Екатеринбурга) до небольших населенных пунктов.

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

Как реагируют пользователи

В комментариях на сервисах мониторинга началась типичная паника.

Одни уверены, что «Roblox заблокировали в России навсегда», другие предполагают проблемы на стороне Amazon. Именно там размещается часть инфраструктуры игры.

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

Что известно о причинах

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

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

Традиционный видеоплеер Totem уступит место приложению Showtime, а встроенный GNOME System Monitor заменят на новое системное приложение Resources.

Что придет на замену

Оба приложения уже используют GTK4 и libadwaita, поэтому выглядят и ощущаются гораздо органичнее в текущем GNOME.

Showtime — это новый официальный видеоплеер GNOME, который уже заменяет Totem в апстриме (GNOME 49). Интерфейс у него проще, чище и лучше вписан в дизайн среды.

Resources — разработка из GNOME Circle, легкий системный мониторинг с возможностью отслеживать загрузку железа и завершать процессы. Canonical выбрала его вместо Mission Center из-за лучшей доступности — важный критерий для LTS-выпуска.

Можно попробовать уже сейчас

Если хочется потестировать новинки до релиза:

• Showtime доступен через apt в Ubuntu 25.10.
• Resources можно установить с Flathub.

Totem и классический System Monitor никуда не исчезнут: их можно будет поставить вручную.

Когда ждать релиз

Ubuntu 26.04 LTS выйдет в апреле 2026 года и будет поддерживаться до 2031 года.

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

Первичка и не только

Когда мы говорим «бухгалтерские документы», мы имеем в виду не пару стандартных бланков, а множество первичных, учредительных, учетных и распорядительных документов, полуструктурированных и гибких форм. Среди них счета-фактуры, УПД, формы ТОРГ-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. А если вам понравился материал, предлагаем к прочтению нашу предыдущую статью про распознавание документов в мессенджерах.

Я проанализировала более 20 предложений по написанию статьей ВАК на заказ и собрала подборку сервисов. В первой части — ТОП-10 сервисов с полным спектром услуг, в следующей — 3 дополнительных сервиса. Так вы получите обзор и сможете выбрать вариант по бюджету и задачам.

ТОП-10 онлайн-сервисов для помощи в написании статей ВАК в 2026 году

1. Homework — персональный формат, где эксперт сопровождает автора статьи ВАК от выбора темы до финальной проверки.
2. Автор24 — крупная база специалистов с учеными степенями и высоким качеством консультаций по публикациям ВАК.
3. Студворк — длительная поддержка и бесплатные доработки по статьям ВАК в течение года.
4. Studently — удобное онлайн-взаимодействие и мгновенная связь с экспертами по структуре и тексту статьи.
5. Zaochnik — более 20 лет стабильной работы и точное соответствие публикаций требованиям ВАК.
6. Напишем — прозрачная схема оплаты и контроль качества консультаций без риска для клиента.
7. Студландия — низкие цены и бесплатная первичная консультация по структуре статьи.
8. Все сдал — лидер по числу экспертов и отзывов, быстрая помощь при подготовке публикаций ВАК.
9. Феникс — быстрый отклик консультантов и оперативная оценка заказа по статье.
10. Student24 — открытая система предложений и прямое взаимодействие со специалистами без посредников.

1. Homework

Онлайн-сервис Homework известен как площадка, где студенты, аспиранты и преподаватели получают профессиональную консультационную помощь при подготовке научных публикаций, в том числе статей для журналов из перечня ВАК. Эксперты сервиса сопровождают автора на всех этапах: от выбора темы и составления структуры до редактирования текста и проверки оригинальности. Здесь помогают выстроить аргументацию, адаптировать материал под формат научного издания и оформить работу по ГОСТу. Публикация ВАК-статьи — трудоемкий процесс, и платформа дает шанс получить квалифицированную поддержку, сохранив при этом авторство и уникальный стиль исследователя.

• Стоимость: от 11 500 руб. за консультацию по статье ВАК
• Направления: гуманитарные, естественные, технические, юридические, экономические, педагогические, IT
• Гарантийный срок: до 6 месяцев (в течение этого времени доступны бесплатные правки)
• Виды услуг: консультации по структуре и содержанию статей, редактирование и повышение уникальности, проверка антиплагиата, подготовка списка литературы и аннотации, оформление по стандартам ВАК и ГОСТ, помощь с речью для защиты, рецензирование и анализ текстов

Преимущества:

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

Недостатки:

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

Перейти на сайт >>>

2. Автор24

Сервис Автор24 работает как крупная онлайн-платформа, где можно заказать консультацию по подготовке статьи для публикации в журнале из перечня ВАК. Здесь студенты, аспиранты и исследователи обращаются к экспертам, чтобы получить профессиональные рекомендации по структуре, формулировке научной идеи и требованиям издания. Каждый заказ сопровождается специалистом, который помогает адаптировать материал под нужный формат, уточнить методологию, повысить оригинальность и подготовить текст к рецензированию. В команде более 400 000 экспертов, среди которых кандидаты и доктора наук, преподаватели ведущих российских вузов. Работа по статье ВАК на заказ выстраивается напрямую между автором и экспертом, что делает процесс прозрачным и контролируемым.

• Стоимость: от 3 200 руб. до 4 400 руб. за консультацию по статье ВАК
• Направления: гуманитарные, естественные, экономические, технические, юридические, педагогические, IT
• Гарантийный срок: 20 дней (в этот период можно бесплатно запросить корректировки)
• Виды услуг: консультации по научным статьям ВАК, выбор журнала для публикации, повышение уникальности, редактирование и корректура текста, подготовка сопроводительных документов, рецензирование, подбор научных источников, анализ содержания

Преимущества:

• большая база экспертов разных направлений;
• персональные консультации с учетом требований ВАК;
• профессиональные специалисты с учеными степенями;
• прямое взаимодействие между автором и экспертом;
• гарантия возврата средств при невыполнении условий;
• безопасная сделка через внутреннюю систему сервиса;
• проверка оригинальности в выбранной системе антиплагиата;
• бесплатные правки в течение гарантийного срока;
• возможность рассрочки и оплаты частями;
• прозрачное формирование цены по результатам общения с экспертом;
• работа только через защищенную платформу без обмена личными контактами;
• поддержка клиентов по телефону, в мессенджерах и по e-mail;
• рейтинговая система, помогающая выбрать лучшего специалиста;
• статистика и история завершенных проектов доступна пользователям;
• интерфейс и мобильное приложение для удобной работы со всеми заказами.

Недостатки:

• нет фиксированной стоимости на публикацию в журнале;
• консультации проводятся только онлайн;
• срок гарантии ограничен 20 днями;
• цена зависит от сезона и загруженности экспертов.

Перейти на сайт >>>

3. Студворк

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

• Стоимость: от 500 руб. за консультацию по статье ВАК
• Направления: гуманитарные, технические, естественные, юридические, экономические, педагогические, IT
• Гарантийный срок: 1 год (в течение этого времени бесплатные доработки при сохранении исходных требований)
• Виды услуг: консультации по написанию статьи ВАК, корректура и редактирование текста, повышение уникальности, рецензирование, помощь с выбором журнала, структурирование материала, подбор источников, проверка на антиплагиат

Преимущества:

• крупная база авторов с научной квалификацией;
• гарантия на заказ до одного года;
• бесплатные правки в рамках условий заявки;
• безопасная сделка через платформу;
• высокая уникальность работ — от 70%;
• открытые рейтинги и отзывы на экспертов;
• прозрачная система ценообразования;
• возможность выбрать исполнителя по профилю дисциплины;
• работа над заказами без посредников;
• минимальный срок консультации — от 2 часов;
• отклики от экспертов появляются в течение 10 минут;
• отсутствие скрытых комиссий;
• техническая поддержка по телефону и e-mail;
• фильтрация авторов по уровню опыта и образованию;
• положительная репутация и высокий средний рейтинг — 4.97.

Недостатки:

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

Перейти на сайт >>>

4. Studently

Онлайн-сервис Studently специализируется на консультационной помощи авторам, готовящим статьи для публикации в журналах из перечня ВАК. Платформа работает с аспирантами, преподавателями и исследователями, которым важно получить экспертную поддержку на всех этапах подготовки научного текста. Здесь помогают выстроить структуру статьи, сформулировать научную идею, проверить уникальность и привести оформление к требованиям ГОСТ и ВАК. Клиент взаимодействует с автором напрямую через чат, что обеспечивает прозрачность и оперативность процесса. Отдел контроля качества следит за соответствием требований, а гарантия на каждую работу действует до 30 дней. Сервис подходит тем, кто хочет сохранить авторство и одновременно получить профессиональную поддержку при подготовке материала к публикации.

• Стоимость: от 2 500 руб. за консультацию по статье ВАК
• Направления: гуманитарные, экономические, технические, педагогические, юридические, естественные, IT
• Гарантийный срок: 30 дней (при необходимости может быть продлен до 60 дней)
• Виды услуг: консультации по написанию статей ВАК, редактирование и корректура, повышение уникальности текста, подбор литературы и оформление ссылок, консультации по структуре и стилю, проверка на антиплагиат, поддержка при подготовке к публикации

Преимущества:

• индивидуальный подход к каждой статье;
• более 2 800 экспертов на платформе;
• прямая связь с автором без посредников;
• быстрый подбор специалиста под заказ;
• круглосуточная работа сервиса без выходных;
• гарантия качества и контроль уникальности;
• консультации по требованиям ВАК и ГОСТ;
• бесплатные доработки в течение гарантийного периода;
• точное соблюдение сроков выполнения;
• безопасная сделка и защита платежей;
• возможность делить оплату на два этапа;
• прозрачный расчет стоимости через онлайн-калькулятор;
• техническая поддержка 7 дней в неделю;
• отзывы и рейтинг авторов доступны перед заказом;
• оформление публикаций с учетом рекомендаций рецензентов.

Недостатки:

• общение с экспертами только в онлайн-формате;
• цена растет при срочных заказах;
• нет фиксированной стоимости за конкретный объем;
• часть отзывов не содержит подробных комментариев по работе.

Перейти на сайт >>>

5. Zaochnik

Образовательный сервис Zaochnik работает с 2001 года и известен как один из старейших онлайн-ресурсов академической поддержки. Платформа помогает авторам, готовящим статьи для публикации в журналах из перечня ВАК. На сайте можно получить консультацию по научному тексту, уточнить структуру, скорректировать стиль изложения, оформить список литературы и проверить материал на оригинальность. Эксперты сервиса — преподаватели вузов и исследователи с учеными степенями, которые разбираются в требованиях Высшей аттестационной комиссии. Работа с клиентом строится через личный кабинет, где можно общаться с консультантом напрямую, отслеживать этапы и получать обратную связь. Сервис обеспечивает официальное сопровождение, заключает договор и гарантирует конфиденциальность данных.

• Стоимость: от 1 500 руб. за консультацию по статье ВАК
• Направления: гуманитарные, экономические, технические, педагогические, юридические, естественные, IT
• Гарантийный срок: 2 месяца (в течение этого времени выполняются бесплатные правки и уточнения)
• Виды услуг: консультации по написанию статей ВАК, повышение уникальности, редактирование и корректура текста, помощь с выбором журнала, оформление по ГОСТ, проверка источников и ссылок, подготовка сопроводительных документов, рецензирование, консультации перед подачей статьи в издание

Преимущества:

• более 2 700 экспертов по 600 направлениям;
• круглосуточная поддержка 24/7;
• официальное заключение договора;
• бесплатные корректировки в течение гарантийного срока;
• консультации преподавателей и кандидатов наук;
• возможность срочного обращения;
• прозрачная схема оплаты с предоплатой 25%;
• безопасная сделка и защита личных данных;
• контроль качества готовых материалов;
• помощь в подготовке к публикации и защите;
• личный менеджер, сопровождающий заказ;
• большой опыт работы на рынке — с 2001 года;
• высокий рейтинг сервиса (4.8 по отзывам студентов);
• поддержка на всех этапах работы;
• проверка уникальности и стиля научного текста.

Недостатки:

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

Перейти на сайт >>>

6. Напишем

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

• Стоимость: от 2 500 руб. за консультацию по статье ВАК
• Направления: гуманитарные, экономические, юридические, технические, педагогические, медицинские, естественные, IT-дисциплины
• Гарантийный срок: 30 дней (в течение этого периода выполняются бесплатные корректировки)
• Виды услуг: консультации по подготовке статей ВАК, корректура и редактирование текста, проверка уникальности, подбор литературы, структурирование разделов, рецензирование, работа с аннотацией и списком источников, консультации по требованиям издания, советы по улучшению научного содержания

Преимущества:

• прозрачная система безопасных сделок;
• более 560 авторов онлайн ежедневно;
• рейтинг исполнителей на основе отзывов;
• выбор эксперта по профилю и опыту;
• прямая связь с консультантом в чате;
• гарантия оригинальности от 80%;
• проверка на antiplagiat.ru перед сдачей;
• бесплатные доработки в течение гарантийного срока;
• официальное заключение договора с клиентом;
• контроль качества через службу проверки;
• поддержка анонимности и конфиденциальности;
• выполнение заказов в срок от 2 дней;
• низкая предоплата от 25%;
• возврат средств при нарушении условий;
• скидка 10% на первый заказ.

Недостатки:

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

Перейти на сайт >>>

7. Студландия

Сервис Studlandia консультирует студентов, преподавателей и исследователей, которые готовят статьи для публикации в журналах из перечня ВАК. Здесь все заинтересованные получают профессиональную помощь по структуре, корректности научных формулировок, аннотации, списку литературы и уникальности текста. Работой занимаются специалисты с академическим опытом, знакомые с требованиями ВАК и ГОСТ. На сайте указано, что компания не продает готовые научные статьи и не занимается изготовлением документов об образовании. Все консультации проходят в правовом поле и направлены на развитие собственных исследовательских навыков клиента. Studlandia гарантирует конфиденциальность данных и безопасную оплату, а также предоставляет бесплатные доработки в течение гарантийного периода.

• Стоимость: от 100 руб. за консультацию по статье ВАК
• Направления: гуманитарные, технические, юридические, педагогические, медицинские, экономические, естественные, IT
• Гарантийный срок: до 21 дня (в течение этого времени выполняются бесплатные доработки)
• Виды услуг: консультации по структуре и содержанию статей ВАК, редактирование текста, повышение уникальности, подбор источников и литературы, проверка аннотации, корректировка разделов, подготовка презентации и речи для защиты, сопровождение при подаче работы в журнал

Преимущества:

• бесплатная первичная консультация;
• общение напрямую с консультантом в Telegram;
• оплата только после получения готовой работы;
• низкие цены по сравнению с аналогами (на 20–30% ниже);
• проверка оригинальности в антиплагиате;
• гарантия конфиденциальности и безопасных платежей;
• бесплатные правки по требованиям преподавателя;
• консультанты с профильным образованием;
• поддержка клиентов 7 дней в неделю;
• обработка заявок в течение 5 минут;
• срочные заказы — от 12 часов;
• возможность рассчитать стоимость онлайн;
• более 4000 экспертов на платформе;
• точное соблюдение ГОСТ и требований ВАК;
• контроль качества и сопровождение до защиты.

Недостатки:

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

Перейти на сайт >>>

8. Все сдал

Онлайн-площадка «Все сдал!» — это маркетплейс образовательных консультаций, где студенты, аспиранты и преподаватели могут купить услуги и получают экспертную помощь при подготовке научных материалов, в том числе статей для публикации в журналах из перечня ВАК. На сайте работают проверенные специалисты, которые разбираются в академических требованиях, структуре научных текстов и критериях Высшей аттестационной комиссии. Они помогают авторам собрать и систематизировать материал, скорректировать формулировки, доработать аннотацию и список литературы, привести текст в соответствие с ГОСТ. Каждый заказ размещается через систему «Безопасная сделка», где средства резервируются на время работы и переводятся исполнителю только после подтверждения результата. Консультации по тому, как написать статью ВАК на заказ, проходят онлайн, а отклик экспертов поступает уже в течение нескольких минут.

• Стоимость: от 400 руб. за консультацию по статье ВАК
• Направления: экономика, юриспруденция, педагогика, психология, менеджмент, гуманитарные, естественные, технические и IT-науки
• Гарантийный срок: от 7 дней (в течение этого времени предоставляются бесплатные доработки)
• Виды услуг: консультации по структуре и содержанию статьи ВАК, корректура текста, рецензирование, подбор литературы, проверка аннотации и выводов, редактирование списка источников, консультации по требованиям изданий, советы по улучшению аргументации, подготовка речи и презентации для защиты

Преимущества:

• быстрый отклик экспертов после публикации заказа;
• выбор специалиста по рейтингу и отзывам;
• прямое общение с консультантом без посредников;
• бесплатные доработки и уточнения по запросу;
• гарантия возврата денег при нарушении условий;
• безопасная сделка и контроль платежей;
• поддержка пользователей 7 дней в неделю;
• проверенные эксперты с высшим образованием;
• низкие цены за счет прямого сотрудничества;
• выполнение срочных заказов от 4 часов;
• рейтинг более 857 тысяч отзывов с оценкой 4.9 из 5;
• удобный интерфейс сайта и мобильное приложение;
• подробная база советов по написанию научных текстов;
• высокая уникальность материалов (до 95%);
• индивидуальный подход к каждой теме и дисциплине.

Недостатки:

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

Перейти на сайт >>>

9. Феникс

Сервис Feniks.Help работает более 10 лет, высоко ценится, специализируется на профессиональной академической поддержке студентов и исследователей. Здесь проводят консультации по научным статьям, включая публикации в журналах из перечня ВАК и РИНЦ. Эксперты сервиса помогают авторам разобраться со структурой материала, уточнить формулировки, доработать аннотацию, подобрать научные источники и привести текст в соответствие с требованиями Высшей аттестационной комиссии. На площадке зарегистрировано свыше 22 000 авторов, среди которых преподаватели, аспиранты и специалисты прикладных направлений. Feniks.Help работает по принципу прямого взаимодействия клиента и эксперта без посредников. Оплата проводится через безопасную систему, а средства резервируются до подтверждения готовой работы. Клиент может самостоятельно выбрать консультанта, оценить его рейтинг и отзывы, а также контролировать процесс консультации онлайн.

• Стоимость: не указано
• Направления: гуманитарные, экономические, юридические, педагогические, технические, естественные, медицинские, IT
• Гарантийный срок: не указан (предусмотрены бесплатные доработки в установленный период)
• Виды услуг: консультации по структуре и содержанию статей ВАК, редактирование научных текстов, проверка аннотаций, подбор литературы, корректировка по ГОСТ, анализ рецензий и диссертаций, повышение уникальности, подготовка речей и презентаций для защиты, помощь в подготовке материалов к подаче в журналы ВАК

Преимущества:

• прямая работа с экспертами без посредников;
• более 22 000 авторов, 2400 активных онлайн;
• выбор специалиста по рейтингу и отзывам;
• безопасная сделка с оплатой после подтверждения результата;
• быстрый отклик — оценка заказа в течение 15 минут;
• консультации преподавателей, кандидатов и докторов наук;
• выполнение срочных заказов от нескольких часов;
• гарантия оригинальности и корректности текста;
• бесплатные доработки и уточнения по требованиям ВАК;
• поддержка клиентов по телефону и электронной почте;
• широкий перечень дисциплин и видов научных работ;
• прозрачная система расчета стоимости;
• конфиденциальность данных клиентов;
• простая онлайн-форма для заказа;
• публикации принимаются в ведущих изданиях ВАК.

Недостатки:

• отсутствует фиксированный прайс, цена уточняется индивидуально;
• сроки и стоимость зависят от выбранного эксперта;
• нет информации о длительности гарантийного срока;
• ограниченное время поддержки (с 9:00 до 21:00).

Перейти на сайт >>>

10. Student24

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

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

Преимущества:

• прямая работа с экспертами без посредников;
• конкурентные цены за счет открытых предложений;
• более 75 тысяч успешно завершенных проектов;
• возможность выбора специалиста по рейтингу и отзывам;
• защищенная сделка с оплатой после подтверждения результата;
• гарантированное качество и соблюдение сроков;
• поддержка клиентов на всех этапах заказа;
• конфиденциальность персональных данных;
• широкий спектр направлений и научных дисциплин;
• помощь от аспирантов и преподавателей вузов;
• бесплатное размещение заявки и оценка работы;
• гибкая система обратной связи с автором;
• профессиональные консультации по требованиям ВАК;
• структурированный процесс с понятными этапами;
• положительные отзывы и высокая оценка пользователей (5 из 5).

Недостатки:

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

Перейти на сайт >>>

Еще 3 сервиса для помощи в написании статей ВАК

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

• СтудСервис. Площадка работает с 2006 года и предоставляет консультации по написанию научных статей, в том числе для публикации в изданиях ВАК. Клиентов консультируют преподаватели вузов, которые помогают выстроить структуру исследования, уточнить тему и привести текст к академическим требованиям. Проверка оригинальности считается обязательной, а доработки выполняются бесплатно при сохранении исходного задания.
• StudLance. Сервис предлагает консультации по подготовке научных статей для публикации в изданиях ВАК. Эксперты помогают авторам собрать и структурировать материал, оформить текст по требованиям журнала и скорректировать научные формулировки. Все работы выполняются с соблюдением академических стандартов и проходят проверку квалифицированными специалистами.
• TopWork24. Сервис предоставляет консультации по подготовке научных статей для журналов из перечня ВАК. Эксперты с высшим образованием и научными званиями помогают авторам выстроить структуру текста, уточнить формулировки и привести материал к требованиям научного издания. Все консультации проходят в формате безопасной сделки, а гарантийный срок на доработку составляет до 60 дней.

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

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

Скачать его уже можно в Google Play, но пока только в США, Канаде, Японии и Южной Корее. Остальные регионы (включая Европу) получат доступ позже.

Что умеет Sora на Android

Функционал полностью совпадает с веб- и iOS-версиями:

• создание коротких видеороликов по текстовым описаниям;
• настройка стиля, атмосферы и эффектов;
• генерация реалистичных сцен и персонажей.

Главное обновление — функция Cameo, теперь умеющая работать не только с людьми, но и с анимированными героями.

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

Как получить доступ

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

Таким образом, Android-пользователи наконец-то дождались релиза. А также того, что Cameo больше не эксклюзив iPhone.

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

Приложения за минуты

Главное новшество — Copilot App Builder. Этот агент способен за несколько минут сгенерировать и развернуть рабочее приложение: с панелями, графиками, калькуляторами, списками и формами.

Все, что для этого нужно — написать промт вроде «Создай дашборд для учета продаж с фильтром по регионам».

После генерации, Copilot позволяет редактировать интерфейс и функциональность через дальнейшие подсказки на естественном языке. Готовое приложение можно расшарить по ссылке внутри компании — так же, как Word-документ или Excel-таблицу.

Данные в таких приложениях хранятся не в сложных базах, а в Microsoft Lists, что делает процесс максимально простым для непрофессиональных разработчиков.

Автоматизация задач

Второй агент, Copilot Workflows, предназначен для автоматизации рабочих процессов: от рассылки писем до организации встреч в Teams.

Пользователю достаточно написать, что он хочет автоматизировать и Copilot создаст готовый сценарий, объединяющий Outlook, SharePoint, Planner и прочие сервисы Microsoft 365.

Например: «Каждое утро отправляй отчет о новых задачах в общий чат» — и ИИ создаст нужный воркфлоу, который можно потом донастроить обычными фразами вроде «Добавь напоминание за час до дедлайна».

Новая экосистема агентов

Microsoft также запустила облегченную версию Copilot Studio — встроенную среду для создания ИИ-агентов и внутренних инструментов прямо внутри Copilot.

Если же нужно что-то масштабнее — с кастомными моделями и сложными потоками данных — можно перейти в полноценную версию Copilot Studio.

Обе новинки (App Builder и Workflows) уже доступны корпоративным клиентам через Agent Store в рамках программы Copilot Frontier.

Ждем их релиза и для обычных пользователей вроде нас с вами.

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

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

Некоторые люди начинают с относительно низкоуровневого программирования на 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, который может радикально улучшить креативные и кодогенерационные возможности.

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

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

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

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

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

Браузеры

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

• Большинство пользователей: Chrome, Edge или Safari
• Защита приватности: Firefox, Brave, Ungoogled Chromium
• Опытные пользователи: Vivaldi
• Максимальная анонимность: Tor Browser

Google Chrome

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

Минус один, но существенный: Chrome прожорлив. Если у вас открыто больше десятка вкладок, он может съесть несколько гигабайт оперативной памяти. На компьютерах с 8 ГБ RAM и меньше это становится проблемой.

Mozilla Firefox

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

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

Microsoft Edge

Edge построен на том же движке Chromium, что и Chrome, но при этом лучше оптимизирован для Windows. Microsoft вложилась в производительность: браузер работает быстро, потребляет меньше ресурсов и отлично интегрируется с системой.

Особенно приятны функции вроде Collections (коллекции вкладок для организации исследований), режим чтения и встроенный скриншотер. Edge поддерживает все расширения Chrome, так что переход безболезненный.

Brave

Brave — это Chrome на стероидах приватности. Браузер блокирует рекламу и трекеры по умолчанию, что делает сёрфинг быстрее и безопаснее. При этом он полностью совместим с расширениями Chrome.

Есть интересная фишка: Brave Rewards позволяет зарабатывать криптовалюту за просмотр приватной рекламы (если захотите её включить). Спорная механика, но как опция — почему нет. Для тех, кто хочет Chrome без Google и с упором на приватность, Brave — отличный выбор.

Safari (только macOS)

Если у вас Mac, Safari заслуживает внимания. Это самый энергоэффективный браузер для macOS: на MacBook он даёт ощутимо больше автономности по сравнению с Chrome или Firefox. Интеграция с экосистемой Apple безупречна: Handoff, синхронизация через iCloud, Reading List, автозаполнение паролей.

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

Ungoogled Chromium

Для ультраосторожных Ungoogled Chromium удаляет всё отслеживание и сервисы Google — но вам придётся настраивать всё самостоятельно, так как в нём нет автообновлений или встроенной синхронизации.

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

Tor Browser

Выводя приватность на следующий уровень, Tor Browser маршрутизирует ваш трафик через сеть Tor, анонимизируя ваш IP и многократно шифруя соединение. Он медленнее по задумке, но идеален, если ваш приоритет — максимальная анонимность, а не скорость или удобство.

Vivaldi

Vivaldi — браузер мечты для тех, кто хочет полного контроля. Стекирование вкладок, тайлинг, кастомные горячие клавиши, встроенная почта и календарь, веб-панели — это полноценный десктопный опыт внутри браузера. Хотите боковую панель браузера, открывающую ваши заметки, RSS-ленты или любой нужный сайт? Vivaldi это умеет.

Arc

Наконец, Arc — когда-то новичок на рынке браузеров, нацеленный на переосмысление UX: замена традиционной панели вкладок на боковую панель, акцент на веб-приложениях, интегрированные разделённые виды и easels для заметок и доски. К сожалению, компания за Arc прекратила разработку, чтобы полностью переключиться на ИИ с новым браузером, который сейчас в закрытой бета-версии.

Управление паролями

• Лучший бесплатный выбор: Bitwarden
• Также отлично: 1Password, Dashlane, KeePass

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

Также не будем забывать о passkeys (ключах доступа). Если говорить практически, можно сказать, что passkeys объединяют концепцию пароля и двухфакторной аутентификации (2FA) в одно плавное действие, но гораздо безопаснее и гораздо менее раздражающе.

Bitwarden

Полностью опенсорсный, зашифрованный и щедрый даже в бесплатной версии. Вы получаете неограниченное количество паролей, синхронизацию между устройствами и приложения для всех платформ. Премиум ($10/год) добавляет безопасный обмен файлами и инструменты 2FA. Также есть доступные семейные и командные планы.

1Password

Премиум-решение с отполированным интерфейсом, сильной кроссплатформенной поддержкой и отличными функциями вроде Travel Mode (режим путешествий) и полной интеграцией passkeys.

Dashlane

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

KeePassXC

Отличная оффлайн-альтернатива, если хотите полного контроля и не против ручной синхронизации (или использования чего-то вроде Syncthing или Dropbox для синхронизации базы данных).

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

Продвинутые утилиты и дополнения к ОС

• Поиск + лаунчеры: Everything или Wox (Windows), Alfred или Raycast (macOS)
• Пакетные менеджеры: WinGet, Homebrew (macOS)
• Для пользователей Windows: PowerToys
• Для пользователей Mac: Rectangle
• История буфера обмена: ClipClip, Flycut (macOS)
• Скриншоты + аннотации: Monosnap

Winget

Официальный менеджер пакетов Microsoft, встроенный в Windows 10 и 11. Работает похоже на Chocolatey, но разработан и поддерживается Microsoft. Homebrew — самый популярный менеджер пакетов для macOS. Позволяет быстро устанавливать, обновлять и управлять приложениями и CLI-инструментами с помощью команд в терминале.

Everything

Что касается поиска, Everything остаётся золотым стандартом сверхбыстрого поиска по именам файлов в Windows. Он индексирует диски за секунды и выдаёт почти мгновенные результаты с минимальной нагрузкой на систему. Если нужен функционал шире базового поиска, Wox использует движок Everything и добавляет мощные возможности лаунчера: поиск файлов, запуск приложений, калькулятор, перевод текста и расширения через плагины. Получается более гибкий опыт в духе Spotlight для Windows.

Command Palette/Alfred/Raycast

В который раз Microsoft не смогла существенно улучшить встроенный поиск Windows, хотя Command Palette в PowerToys даёт неплохой компромисс для тех, кто не хочет ставить сторонние утилиты.

На macOS Alfred по-прежнему главный лаунчер и утилита поиска. Он быстрый, интуитивный и в бесплатной версии включает историю буфера и настраиваемые поиски; расширенная автоматизация и «воркфлоу» доступны в Powerpack.

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

Менеджеры буфера обмена

Они позволяют возвращаться к ранее скопированному — тексту, изображениям, ссылкам — и сильно ускоряют рутинные операции.

В Windows встроенная история буфера (Win + V) кое-как выручает, но продвинутым пользователям обычно хочется большего. В числе бесплатных рекомендаций — ClipClip для Windows и Flycut для macOS.

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

PowerToys — набор полезных утилит от Microsoft для продвинутых пользователей Windows, повышающих продуктивность и упрощающих рабочие процессы. Среди инструментов: FancyZones для продвинутого раскладывания окон, PowerRename для пакетного переименования, Keyboard Manager для ремапинга клавиш, универсальный color picker и другие.

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

Широко используемая альтернатива в Windows — FancyZones (часть PowerToys), предлагающая продвинутое управление окнами: настраиваемые сетки, зоны привязки и поддержку нескольких мониторов — поэтому это фаворит пауэр-пользователей на Windows.

Для рутины и создания проектов

• Бесплатные инструменты: FreeOffice, LibreOffice и WPS Office
• Microsoft Office за единовременную плату $49, Office 2024 — $129
• Заметки: Notion, OneNote, Obsidian
• Бесплатный PDF-редактор: PDFsam
• Почтовые клиенты: Thunderbird, eM Client

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

Microsoft Office остаётся отраслевым стандартом для профессиональной продуктивности. Подписка Microsoft 365 открывает доступ к Word, Excel, PowerPoint, Outlook и включает 1 ТБ облачного хранилища.

Среди бесплатных альтернатив LibreOffice — мощный open-source комплект с сильным сообществом (хотя интерфейс некоторым кажется старомодным). Если нужна внешне более майкрософтовская альтернатива, попробуйте FreeOffice или WPS Office Free — у них хорошая совместимость.

На macOS Pages, Numbers и Keynote предустановлены и более чем достаточны для большинства задач, особенно если вы в экосистеме Apple.

Знания и ведение заметок

Notion стал универсальной платформой организации: заметки, базы данных, to-do, управление проектами, создания совместных рабочих пространств. Если нужны более локальные заметки с синхронизацией между устройствами и поддержкой Markdown, Obsidian — любимец студентов и исследователей.

Для быстрых кроссплатформенных заметок OneNote — крепкий бесплатный вариант от Microsoft. В качестве альтернатив — Simplenote или open-source Joplin.

Если вы занимаетесь академической работой и научными статьями, Zotero — отличный open-source менеджер источников с интеграцией в браузер и совместными коллекциями. Milanote предлагает визуальный подход к заметкам и планированию — идеально для креативных пользователей.

Работа с PDF

Хотя Adobe Acrobat остаётся премиальным редактором PDF, бесплатные альтернативы вроде PDFsam позволяют без усилий объединять, разбивать, редактировать и поворачивать страницы.

Инструменты для дизайна и создания контента

Для дизайна два выделяющихся приложения хорошо дополняют набор продуктивности. Figma Desktop — совместная платформа интерфейс-дизайна, широко используемая UI/UX-дизайнерами и фронтенд-разработчиками. Десктоп-версия работает быстрее, чем браузер, и лучше интегрируется с ОС — это удобно для сложных дизайн-систем и коллаборации в реальном времени.

Canva с интуитивным drag-and-drop превосходно чувствует себя и как десктоп-приложение. Отлично подходит для быстрых графических материалов для соцсетей, маркетинга, постеров и презентаций. Благодаря тысячам шаблонов и совместной работе это фаворит как у профи, так и у новичков.

Почтовые клиенты

Если вы предпочитаете отдельный почтовый клиент, у eM Client много функций, бесплатный — до двух аккаунтов. Mozilla Thunderbird — мощная open-source альтернатива с удобной настраиваемостью, а Mailbird — вариант с упором на продуктивность для тех, кого не пугает подписка.

Инструменты разработчика

• Редакторы кода и текста: VS Code, Cursor, Sublime Text
• Система контроля версий: SourceTree, GitHub Desktop
• Контейнеры: Docker
• Локальные LLM: Ollama
• SFTP, загрузка файлов: WinSCP, Forklift

Для разработчиков Visual Studio Code — безусловный вариант. Бесплатный, лёгкий, но мощный, кроссплатформенный — тысячи расширений покрывают практически любой язык, фреймворк или инструмент. Набирающая популярность альтернатива — Cursor, редактор на базе VS Code с усиленной AI-помощью. Он подходит для связки с LLM: даёт inline-подсказки, генерирует код, рефакторит и позволяет редактировать кодовую базу.

При этом Sublime Text остаётся для скорости и простоты, а Notepad++ — отличный лёгкий редактор для быстрых правок в Windows.

Для Git графические клиенты SourceTree и SmartGit дают понятный интерфейс для управления репозиториями на GitHub, GitLab и не только. GitHub Desktop раньше был простоват и не слишком хорош, но сейчас существенно прибавил — всё ещё простой для работы, но в хорошем смысле.

Для локальных окружений, API-тестирования или терминального воркфлоу инструментов — пруд пруди. Например, Docker Desktop стал стандартом для тех, кто собирает и запускает контейнеризированные приложения на разных платформах. Он упрощает настройку окружений и держит систему чистой.

Ollama позволяет запускать большие языковые модели (LLM) локально с минимальной настройкой. Поддерживает модели вроде LLaMA, Mistral и другие open-weight альтернативы GPT, так что можно работать с ИИ прямо на своём компьютере без отправки данных в облако.

Если вы работаете с облачными хранилищами или SFTP, WinSCP (Windows) и ForkLift (macOS) — отличные клиенты с двухпанельным управлением файлами, синхронизацией и автоматизацией. На Mac также популярны Commander One и Transmit — у них есть встроенные подключения к удалённым и облачным путям.

Безопасность

И Windows, и macOS сегодня предлагают более чем достойную встроенную защиту. С защитой в реальном времени, интеграцией с файерволом и биометрией вроде Windows Hello и Touch ID. Для обычных пользователей, которые соблюдают гигиену безопасности: не скачивают сомнительное ПО, используют менеджеры паролей и включают 2FA — встроенной защиты часто хватает.

Для продвинутых пользователей есть дополнительные варианты.

Отличное первое дополнение — Malwarebytes. Это давний фаворит в обнаружении и удалении malware, adware и руткитов; бесплатная версия по-прежнему хороша для ручных сканов. В платной — защита в реальном времени без ощутимой просадки производительности.

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

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

Мы не поклонники установки антивирусов на каждый компьютер и не полностью в курсе, какие сейчас показывают лучшие результаты. Тем не менее, AV-Test давно и регулярно оценивает популярные решения, поэтому советуем смотреть их свежие отчёты. В текущем списке высокооценённых — Avast, BitDefender, ESET и другие; многие из них предлагают бесплатные версии для пробы.

Удалённый доступ и вспомогательные утилиты

RustDesk стал современным, ориентированным на приватность аналогом TeamViewer. Он с открытым исходным кодом, быстрый и работает кроссплатформенно.

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

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

Remote Mouse — простой и эффективный способ эмулировать мышь и клавиатуру с телефона. Для более продвинутых сценариев можно использовать приложения вроде Unified Remote.

Редактирование изображений и видео

• Профессиональный видеомонтаж: DaVinci Resolve
• Простой видеомонтаж: CapCut
• Редакторы изображений: GIMP, PhotoDemon, Pixelmator Pro
• Бесплатное улучшение изображений: Upscayl
• RAW-редактирование: RawTherapee
• Видеоконвертация: HandBrake

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

Если вы хотите увеличивать разрешение изображений без потери качества, Upscayl — мощный и бесплатный инструмент для апскейла. Он кроссплатформенный, и по нашим тестам показывает результаты на уровне платных решений вроде Topaz.

Для векторной графики — логотипы, иллюстрации — Inkscape является достойным open-source вариантом с полной поддержкой редактирования SVG. Krita — ещё один отличный бесплатный инструмент, особенно подходящий для цифровой живописи и художественного творчества.

Для редактирования RAW-фотографий, Darktable и RawTherapee — два высококлассных open-source аналога Adobe Lightroom. Их широко используют фотографы, которым нужна работа с изображениями без подписки.

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

Среди платных фоторедакторов Adobe Photoshop остаётся лидером, но для macOS есть Pixelmator Pro — мощное приложение с разовой оплатой, а Affinity Photo предлагает профессиональные возможности по более доступной цене.

Видеомонтаж и конвертация

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

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

Для пользователей macOS iMovie предустановлен и остаётся надёжным вариантом для базовых видео. Если вам нужно просто конвертировать или сжимать видео в современные форматы, HandBrake — проверенное бесплатное решение с поддержкой и вариацией входных и выходных форматов.

Тем, кто ищет топовый профессиональный монтаж, подойдут Adobe Premiere Pro и Final Cut Pro, но там есть дорогая подписка и более высокий порог входа.

Коммуникации и совместная работа

• Для повседневной связи: WhatsApp, Messenger и Zoom, если у вас нет FaceTime
• Для приватности: Signal
• Для работы: Slack, Teams
• Для игр и общения: Discord

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

Для личной переписки WhatsApp и Facebook Messenger остаются самыми массовыми платформами по всему миру. У них есть десктопные клиенты и встроенное сквозное шифрование по умолчанию. Telegram также крайне популярен благодаря синхронизации между устройствами и поддержке крупных чатов. Пользователи Apple продолжают активно использовать iMessage для приватного, шифрованного общения в экосистеме Apple.

Из видеоконференций Zoom остаётся одним из лидеров для групповых звонков и онлайн-ивентов, предлагая локальные записи, демонстрацию экрана и комнаты (breakout rooms). Однако бесплатный тариф ограничивает 1:1 звонки 40 минутами, если не перейти на платный план. Zoom поддерживает сквозное шифрование, но при включении E2EE отключаются некоторые функции вроде облачной записи и комнат.

Google Meet — отличный браузерный аналог без необходимости установки, который заметно улучшился по качеству и удобству использования. Многие компании применяют Meet в ежедневной работе и гибридных форматах. Если ваша организация использует Microsoft 365, скорее всего, вы работаете в Microsoft Teams, который уже заменил Skype на корпоративном уровне. Teams поддерживает большие созвоны, обмен файлами и глубоко интегрирован с Office. Сквозное шифрование доступно, но только для 1:1 звонков.

FaceTime по-прежнему отличный для пользователей Apple, и благодаря новым обновлениям к звонку теперь могут присоединяться и пользователи Android/Windows по ссылке через браузер.

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

Для рабочих коммуникаций Slack и Teams продолжают использоваться в бизнес-среде. Бесплатный тариф Slack ограничивает историю 90 днями и звонки, но остаётся любимцем стартапов и малых команд благодаря интеграциям и ботам. Cisco Webex — также крепкий вариант, особенно популярен в корпоративной среде.

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

Для внутриигрового голосового чата TeamSpeak остаётся олдскульным достойным вариантом: можно использовать анонимно и получать полный контроль над сервером. Встроенный чат Steam лучше, чем раньше, и помогает в игровой координации, но большинство всё же выбирает Discord.

Гейминг, моддинг и стриминг

• Игровые платформы: Steam, Epic Games, EA App, Ubisoft, GOG
• Последние драйверы для GPU: Nvidia GeForce, AMD Radeon, Intel Arc
• Стриминг: OBS Studio

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

Не менее важно установить Epic Games Store. Хотя библиотека меньше, он регулярно раздаёт бесплатные игры, доступные любому с аккаунтом Epic. Это также must-have, если вы играете в Fortnite.

Помните: не все издатели размещают игры на Steam или Epic. Для тайтлов EA понадобится EA App (ранее Origin), для Ubisoft — Ubisoft Connect, для Blizzard/Activision — Battle.net, а GOG Galaxy не только предлагает DRM-free классику, но и может агрегировать игры из других лаунчеров.

Некоторые сверхпопулярные игры распространяются отдельно: Minecraft (через Minecraft.net или Microsoft Store), Roblox, League of Legends и Valorant (через лаунчер Riot Games). Если вы новичок и ищете что-то лёгкое, можно начать с free-to-play тайтлов или классики вроде Brutal Chess или GZDoom.

Если вы играете с геймпадом, Windows поддерживает Xbox-контроллеры из коробки. PlayStation-контроллеры теперь тоже отлично работают: Steam через Steam Input поддерживает DualShock 4 и DualSense практически во всех играх. При необходимости глубокой кастомизации можно использовать DS4Windows, но большинству хватает возможностей Steam.

Если вас интересует моддинг, хороший менеджер модов время в этой жизни:

• Mod Organizer 2 — лучший для RPG Bethesda (Skyrim, Fallout).
• Vortex (от Nexus Mods) — дружелюбный к новичкам и поддерживает широкий перечень игр.

Для записи геймплея или стриминга Nvidia ShadowPlay и AMD Radeon ReLive подходят для простых задач. Но для стриминга с вебкой, сценами, оверлеями или многосценовым продакшеном OBS Studio — безальтернативный лидер. Он бесплатный, open-source и подходит как новичкам, так и про-стримерам (Twitch, YouTube, Kick и т.д.). SignalRGB помогает синхронизировать весь RGB-зоопарк и задавать динамические эффекты.

Мониторинг железа и разгон

• Мониторинг: CPU-Z, HWMonitor, HWiNFO64
• Настройка и разгон: Afterburner, FanControl, ThrottleStop, SignalRGB

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

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

Для более широкого мониторинга HWMonitor показывает температуры, напряжения и скорости вентиляторов в реальном времени. Если нужно ещё глубже и с более гибким интерфейсом — HWiNFO64 считается одним из лучших: поддерживает логирование датчиков и интеграцию с оверлеями (например, RTSS или Rainmeter).

Чтобы проверить хранилище, CrystalDiskMark измеряет скорость чтения/записи SSD и HDD — это помогает понять, соответствует ли диск заявленным характеристикам. Глубже оценить здоровье накопителя можно в Hard Disk Sentinel, который анализирует SMART-данные, оценивает срок службы и предлагает ограниченный ремонт.

С точки зрения охлаждения, всё больше геймеров используют утилиты для настройки вентиляторов. FanControl — актуальный бесплатный фаворит: поддерживает сложные кривые оборотов, привязку к датчикам, и совместим с большинством современных материнских плат. На Mac одной из лучших утилит остаётся Macs Fan Control.

Для настройки видеокарт долгое время стандартом был MSI Afterburner — для разгона, настройки вентиляторов и мониторинга с RTSS-оверлеем. Однако из-за замедления обновлений многие сегодня используют встроенные утилиты от Nvidia (GeForce Experience/Control Panel) и AMD (Adrenalin Software).

Если вы меняете видеокарту или подозреваете проблемы с драйверами, обязательно используйте Display Driver Uninstaller (DDU) — он полностью очищает систему от старых драйверов перед переустановкой.

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

Тем, кто серьёзно подошёл к разгону CPU и GPU, пригодятся фирменные инструменты вроде Intel XTU (для Intel) и AMD Ryzen Master — они дают контроль над частотами, напряжениями и лимитами мощности.

Управление файлами

• Поиск больших файлов: SpaceSniffer, WizTree, Disk Drill (macOS)
• Поиск дубликатов: dupeGuru
• Архивы и ZIP: PeaZip, The Unarchiver
• Очистка: BCUninstaller, CCleaner Portable, AppCleaner (macOS)

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

На macOS — GrandPerspective и Disk Drill предлагают аналогичный функционал, а DaisyDisk — один из самых красивых платных вариантов с молниеносным сканированием.

Если дубликаты засоряют диск, dupeGuru (open-source) отлично справляется с поиском повторяющихся изображений и музыки, даже слегка изменённых.

Для пакетного переименования файлов (например, фоточек с камеры) существует гибкий Bulk Rename Utility. Если нужно что-то попроще: PowerRename из PowerToys (Windows) или встроенный инструмент в Finder (macOS) подходят большинству.

Встроенный File Explorer в Windows недавно получил вкладки и стал удобнее, но Files (open-source) — современная альтернатива с улучшенным UX. Кто-то ещё пользуется Total Commander или Directory Opus, благодаря расширяемости и скриптам, хотя новичкам они кажутся устаревшими. Для просмотра изображений по-прежнему незаменим IrfanView.

Для работы с архивами, если не устраивает встроенный ZIP-менеджер Windows, скачайте 7-Zip или PeaZip. На Mac лучшим бесплатным инструментом остаётся The Unarchiver.

Для очистки системы важно выбирать надёжные утилиты. На Windows, BCUninstaller (Bulk Crap Uninstaller) — один из самых проверенных для удаления программ и их хвостов. BleachBit и Wise Disk Cleaner — безопасные альтернативы CCleaner (лучше использовать Portable-версию, так как стационарная испортила репутацию). На Mac AppCleaner всё ещё любим за полное удаление приложений без мусора.

Если вы организуете большую библиотеку медиа, стоит взглянуть на open-source TagSpaces, позволяющий тегировать файлы локально, без облака.

Облачное хранилище и резервное копирование

• Простая синхронизация: Dropbox, Google Drive
• Фото между устройствами: Apple iCloud, Google Photos
• Приватность: pCloud, Proton Drive, Internxt
• Полные бэкапы: Backblaze, IDrive

Базовое облачное хранилище

Dropbox — один из самых простых в использовании, хотя бесплатных 2 ГБ мало.

Google Drive — 15 ГБ бесплатно, используется Gmail, Docs и Photos. Идеален для Android.

OneDrive — идёт в комплекте с Windows и Microsoft 365. 1 ТБ включён в большинство Office-планов. Хотя по скорости и интерфейсу уступает Dropbox/Google.

iCloud Drive — лучший выбор для пользователей Apple, глубокая интеграция с macOS/iOS. Бесплатно 5 ГБ, далее по планам до 2 ТБ.

Proton Drive — шифрованная альтернатива от создателей ProtonMail.

Фото и видео

На macOS приложение Photos автоматически создаёт альбомы по людям и локациям, синхронизирует всё через iCloud.

На Windows мы часто рекомендуем Google Photos, который предлагает аналогичный набор функций и автоматизацию. Для пользователей Android — это стандарт по умолчанию. Да, раньше было безлимитно, теперь фото занимают общее место Google Drive (15 ГБ), которое быстро заканчивается.

Полные бэкапы

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

Backblaze — топ в этой категории: фиксированная цена (~$8/месяц за устройство), безлимитное хранилище, минимум настроек: установил и забыл.

IDrive — более контролируемый вариант, поддерживает несколько устройств, внешние диски и версионность файлов.

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

Профессионалам — Acronis Cyber Protect: клон дисков, анти-вымогатель, гибридное облако.

Для особо чувствительных данных

Если вы храните личные финансовые документы или медицинские сведения, стоит выбрать end-to-end решений.

pCloud предлагает клиентское шифрование (через платный «Crypto»). Даже при взломе аккаунта файлы не расшифруются без ключа.

Proton Drive — аналогичный подход, с прозрачностью open-source.

Прочие полезные инструменты, не вошедшие в другие разделы

Google Earth — для любителей карт и планировки.

qBittorrent — лучший torrent-клиент: чистый, без рекламы, с поиском. Альтернатива — легковесный Transmission или кастомизируемый Deluge.

iMazing — must-have для владельцев iPhone: резервные копии, экспорт медиа, проверка батареи, конвертация HEIC.

AirDroid — аналог для Android: управление файлам, уведомления, SMS с ПК.

Rufus — лидер по созданию загрузочных USB-дисков для Windows/Linux.

Open Shell — возвращает классическое меню «Пуск» в стиле Windows 7.

Stretchly — напоминает делать перерывы — полезно удалёнщикам и фрилансерам.

AutoHotkey — скриптовый движок для Windows: переназначение клавиш, макросы, автоматизация.

VPN: бесплатные — ProtonVPN, Windscribe, TunnelBear (с лимитом). Платные — ProtonVPN, NordVPN.

Calibre — лучшее бесплатное решение для чтения, организации и конвертации e-book (EPUB, MOBI, PDF и др.).

Заключение

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

Несколько советов напоследок:

1. Не захламляйте систему. Устанавливайте только то, что действительно используете. Чем меньше фоновых процессов — тем быстрее работает компьютер.
2. Следите за обновлениями. Большинство программ обновляются автоматически, но некоторые требуют ручного апдейта. Свежие версии — это не только новые функции, но и закрытые уязвимости.
3. Делайте резервные копии. Никакие утилиты не спасут от отказа жёсткого диска. Регулярный бэкап на внешний носитель или в облако — обязательная практика.
4. Экспериментируйте. Попробуйте несколько браузеров, редакторов, плееров. То, что подходит большинству, может не подойти именно вам.
5. Читайте отзывы. Перед установкой незнакомого приложения загляните на форумы или Reddit. Сообщество быстро выявляет проблемы и подводные камни.

Теперь ваш компьютер готов к работе, учёбе, развлечениям — и чему угодно ещё. Главное — не забывайте, что инструменты важны, но ещё важнее то, как вы их используете. Удачи!

По данным компании, за первые пять суток после запуска Sora достигла отметки в 1 млн загрузок, обогнав по темпам роста даже ChatGPT, который стал мировым феноменом в 2022 году.

Глава проекта Билл Пиблз признался, что команда не ожидала такого ажиотажа:

TikTok, но с ИИ

Приложение Sora пока доступно только по приглашениям и исключительно в США и Канаде, однако уже успело стать темой #1 в технологических медиа.

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

В основе платформы лежит новая модель Sora 2, которая умеет создавать реалистичные сцены, персонажей и эффекты.

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

Быстрый успех и первые проблемы

Несмотря на ограниченный запуск, популярность Sora растет стремительно. Приложение взлетело на первое место в разделе «Entertainment» App Store всего за двое суток.

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

Что дальше

Sora стала самым успешным запуском OpenAI после ChatGPT и DALL·E. Компания позиционирует ее как «новую социальную платформу для цифрового творчества», где пользователь и ИИ создают контент вместе.

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

Что известно

ICEBlock позволял пользователям отмечать и передавать данные о перемещении агентов ICE. По данным Business Insider, Apple удалила приложение после запроса правоохранительных органов.

«Мы создали App Store как безопасную и надёжную площадку для поиска приложений, — заявили в Apple. — Получив информацию от правоохранителей о рисках, связанных с ICEBlock, мы удалили его и похожие программы».

Разработчики ICEBlock пока не прокомментировали решение.

Реакция властей

По информации Fox News, с требованием удалить ICEBlock к Apple обратилась генеральный прокурор Флориды Пэм Бонди. Она заявила, что приложение «создано для того, чтобы подвергать агентов ICE опасности».

«Насилие против сотрудников правоохранительных органов — красная линия, которую нельзя пересекать», — отметила Бонди.

Министерство юстиции США пока не дало официального комментария.

Контекст

Администрация Дональда Трампа выступает против приложений, отслеживающих правоохранителей. Ранее Politico сообщало, что министр внутренней безопасности Кристи Ноэм предлагала возбудить дело против CNN за публикацию материала о таких сервисах.

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

Не первый случай давления

Apple уже не раз удаляла приложения по требованию властей. В 2019 году компания убрала HKmap.live, использовавшееся протестующими в Гонконге для отслеживания полиции.

В 2024-м Apple по требованию Китая удалила WhatsApp, Signal и Telegram. Тогда представитель компании заявил, что Apple «обязана соблюдать законы стран, где ведёт деятельность, даже если не согласна с ними».

Давление со стороны администрации

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

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

Она добавила, что разработчику ICEBlock будет сложно оспорить решение Apple в суде: формально приложение удалено добровольно, а не по приказу правительства.

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

В OpenAI заявили, что новинка — это скачок уровня GPT-3.5, но для видео.

Что умеет Sora 2

Новая модель компании впитала в себя целую кучу нововведений. Теперь модель:

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

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

Новый формат общения — Sora.app

Одновременно с моделью запущено iOS-приложение Sora, которое:

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

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

Промт: «мастер боевых искусств отрабатывает ката с бо-стиком, стоя по пояс в воде в пруду с карпами кои»

Важные ограничения

• Sora 2 пока доступна только в США и Канаде через приложение или sora.com.
• ChatGPT Pro-пользователи получат доступ к улучшенной версии модели — Sora 2 Pro.
• Подписка не требуется — генерации пока бесплатны, но с ограничениями по доступным вычислениям.
• Sora 1 Turbo остается доступной и весь ваш контент сохранится.

В ближайшее время планируется запуск API для Sora 2.

Мы попросили сервисы сгенерировать короткую презентацию (до 10 слайдов) в бесплатном режиме на тему: “История IT в России”. Редакция тестировала базовые шаблоны без покупки Pro-версий, что из этого получилось и какой сервис вам подойдет больше — читайте и выбирайте.

1. Кэмп (ex-Кампус) – нейросети для студента

Кэмп (ex-Кампус) — это сервис, который превращает текст в аккуратную академическую презентацию за считанные минуты. Он автоматически собирает и структурирует материал по требованиям преподавателей, распределяет ключевые идеи по слайдам и оформляет их в понятный дизайн. Пользователю остаётся сосредоточиться на содержании и выступлении, а не на технических деталях. Экспорт доступен в формате PPTX, а первая презентация по сгенерированному тексту создаётся бесплатно. Дальше сервис работает по подписке: 399 рублей в месяц за 30 токенов (примерно две презентации), при необходимости можно докупить токены.

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

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

Технически Кэмп работает через веб и Telegram-бота, экспортируя готовые материалы в PPTX. Ограничение по размеру — от 8 до 22 слайдов. API и интеграций с другими платформами нет.

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

2. Сократик — ИИ для презентаций с полным автоматом

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

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

Как это работает на практике

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

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

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

Особенности и подход

Сократик отличается несколькими ключевыми моментами:

• Вы можете проверить и скорректировать план презентации ещё до финальной генерации, изменить отдельные слайды или дать глобальный промпт ко всей презентации сразу.
• Генерируются не только текст и картинки — сервис создаёт таблицы, графики и инфографику, которые вписываются в общий дизайн. Это критично для аналитических или учебных презентаций.
• Онлайн-редактор сочетает привычные мануальные функции (как в PowerPoint или Google Slides) с возможностью использовать ИИ для правок. Можно менять шрифты, добавлять слайды, редактировать картинки — всё в одном месте.
• На основе готовой презентации сервис генерирует текст для выступления, что значительно сокращает время подготовки, особенно для тех, кто волнуется перед презентациями.

Технические детали и ограничения

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

Ограничения и платежи:

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

• Единоразово — 149 рублей. Полный доступ к одной конкретной презентации без водяного знака, безлимитное скачивание в PDF и PPTX, текст для выступления в подарок.
• Подписка «Безлимит» — 469 рублей в месяц или 2490 рублей в год. Неограниченное количество презентаций без водяных знаков, безлимитное скачивание во всех форматах, тексты для выступлений ко всем презентациям.

Управление и поддержка

Сократик работает исключительно как онлайн-ресурс — скачать приложение или использовать десктопную версию нельзя. Всё управление происходит в браузере.

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

3. Slidy AI: Редактор с анимациями прямо в браузере

Slidy AI — Нейросеть, которая собирает презентацию из темы, тезисов или загруженного документа, а затем отдаёт результат в онлайн редактор. От большинства генераторов в подборке он отличается тем, что происходит после генерации: слайды можно не только переписать, но и оживить — добавить переходы между слайдами и анимацию появления текста и картинок, как в PowerPoint.

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

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

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

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

Готовую презентацию выгружают в PPTX или PDF и отправляют ссылкой в мессенджеры и почту.

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

Особенности и подход

• Полная автоматизация цикла: от темы и структуры до готового дизайна, без ручной вёрстки на старте.
• Smart design: алгоритмы сами подбирают стиль, компоновку, цвета, шрифты и макеты; есть библиотека шаблонов под бизнес, образование, маркетинг и науку.
• Русский язык на входе и выходе — язык выбирается на этапе создания.
• Анимации и переходы: из всей подборки движение настраивается в браузере только здесь, у остальных сервисов слайды остаются статичными до выгрузки в PowerPoint.
• Работа с медиа: в слайд можно положить не только изображение, но и видео.

Технические детали и ограничения

Slidy AI — веб-сервис, работает в браузере на Windows, macOS и мобильных устройствах, устанавливать ничего не нужно. Экспорт доступен в PPTX и PDF.

Ограничения, о которых стоит знать до старта:

• Публичного API и SDK у сервиса нет.
• Интеграции с Google Slides, Canva и Notion в FAQ на сайте заявлены как планируемые — пока связка с PowerPoint работает только через выгрузку PPTX.
• На сайте предлагают сделать первую презентацию бесплатно, часть возможностей открывается в платном доступе. Публичного прайса нет: тарифы и лимиты бесплатного режима на сайте не указаны.
• Публичной базы знаний и комьюнити у сервиса нет.

Управление и поддержка

Всё управление происходит в браузере или через мобильное приложение на iOS или Android. Поддержка работает через канал связи на сайте, отдельно есть форма для сообщений об ошибках — bug bounty. Из публичных каналов у сервиса открыты сообщество во «ВКонтакте» и Telegram.

4. Gamma: Вёрстка, которая адаптируется под контент

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

Для PM и аналитиков есть генерация Pitch Deck (презентация продукта) или Team Update (отчет о работе команды) из черновика текста. Можно быстро превратить текстовый план в структурированный документ, готовый к показу. Для разработчиков: Создание Portfolio или Keynote Speech (доклад) с автоматическим подбором иллюстраций, что позволяет сфокусироваться на содержании, а не на дизайне.

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

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

5. SlidePoint: Преобразование текста в слайды в браузере

SlidePoint — это ИИ-генератор, созданный для тех, кому нужно оперативно перевести большой объем информации в формат презентации. Сервис дает два основных пути для старта. Можно ввести тему, например, «Проектирование базы данных», и ИИ самостоятельно сгенерирует структуру и контент. Второй, более точный вариант — создать презентацию по готовому тексту. Сюда можно вставить или прикрепить файл DOCX, PDF, TXT с объемом до 20 000 символов, на основе которого нейросеть извлечет ключевые мысли и построит слайды.

После генерации вы автоматически попадаете в визуальный редактор, который поддерживает все стандартные инструменты работы с презентациями: вставку медиа (аудио, видео, GIF), фигур, таблиц и диаграмм, а также форматирование текста. Это позволяет доработать сгенерированный материал.

Что касается иллюстраций, то здесь есть выбор:

1. Вставка из интернета (бесплатно).
2. Генерация уникальных картинок с помощью ИИ по промптам (платно).
3. Отключение генерации изображений.

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

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

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

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

6. Pitch: Платформа для совместной работы с аналитикой

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

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

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

После рассылки презентации по ссылке менеджер по продажам или PM может увидеть, кто именно открыл документ и сколько времени было потрачено на каждый слайд. Эти объективные данные о вовлеченности помогают оптимизировать контент и повысить конверсию.

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

7. MagicSlides (GPT for Slides): ИИ-генерация прямо в Google Workspace

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

Этот плагин позволяет создать черновик презентации из любого исходника. Вы можете задать тему, добавить свой вводный текст, использовать PDF/DOCX-файл, скормить ему URL-ссылку или даже видео с YouTube. ИИ-движок обрабатывает этот контент и генерирует готовый черновик с иллюстрациями из фотостока Pexels примерно за 100 секунд. Для PM или аналитика это удобный способ быстро превратить техническое описание или статью в презентационный формат, минуя ручное копирование и форматирование.

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

Что касается доступа, то это бесплатное приложение с платными функциями. В бесплатной версии можно создать три презентации в месяц, но есть лимит на обработку текста — не более 2500 знаков на одну презентацию. Платные подписки начинаются от 16 долларов.

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

8. Presentations AI: Когда ИИ мыслит корпоративными стандартами

Presentations AI — это генератор, который использует искусственный интеллект для создания слайдов, фокусируясь на профессиональном и строго корпоративном внешнем виде. Сервис берет на себя всю дизайнерскую работу, превращая идеи в презентации, отчеты, дорожные карты продуктов (Product Roadmaps) и планы проектов.

Чтобы начать, можно просто ввести тему, но для более точных и полезных бизнес-документов лучше предоставить исходные данные: ссылку на сайт компании или документы в форматах DOC, PDF или даже XLS. Это удобно для PM и аналитиков, которым нужно быстро создать формальный отчет, основанный на табличных или текстовых данных.

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

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

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

9. SlidesGo: Коллекция готовых шаблонов с ИИ-стартом

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

Чтобы начать, вы вводите промпт с темой и указываете количество слайдов. ИИ создает черновик текста, который вы можете поправить, а затем остается выбрать подходящий шаблон оформления. Главная ценность SlidesGo — это огромный выбор готовых дизайнов, сгруппированных по индустрии (Технологии, Бизнес) и по стилю (Профессиональный, Минималистский), что позволяет быстро подобрать подходящую обложку для любого доклада.

Для преподавателей и студентов есть специальный раздел Education Hub с узкоспециализированными ИИ-инструментами (например, генератор планов уроков и викторин), а также шаблонами для защиты диссертаций или материалов по истории и науке.

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

Что касается доступа, то в бесплатной версии есть лимит — скачивание не более трех презентаций в день. Платный доступ (от 4,99 евро в месяц) снимает ограничения и открывает доступ к дополнительным шаблонам. Стоит иметь в виду, что сервис не понимает промпты на русском языке.

Как выбрать ИИ-помощника для презентаций

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

1. Если вам нужен академический стиль и структура (например, для доклада или отчета о курсовой работе), стоит обратить внимание на Кэмп (ex-Кампус). Его ключевое отличие — ориентация на требования вузов: он создает логичные, хорошо структурированные презентации без лишней информации, при этом позволяет вмешаться в процесс и скорректировать данные.
2. Если важна командная работа, аналитика и строгий корпоративный бренд, то подойдет Pitch (с фокусом на аналитике просмотров и совместной работе) или Presentations AI (с упором на Brand Sync и создание официальных отчетов).
3. Если вы работаете в экосистеме Google и вам нужна гибкость входных данных, выбирайте MagicSlides (GPT for Slides). Он интегрируется прямо в Google Slides и может генерировать слайды из видео с YouTube или PDF-файлов.
4. Если задача — быстро перевести большой объем текста в PPTX-файл, подойдут SlidePoint (с хорошей поддержкой русского языка и работой без регистрации) или SlidesGo (с упором на огромную библиотеку готовых, профессиональных шаблонов).

В конечном итоге, ИИ-генератор не заменит человека, но он возьмет на себя 80% технической работы с контентом, будь то оформление академического отчета или подготовка питча для инвесторов.

Как будет работать приложение

OpenAI ограничит длительность роликов в Sora 2 десятью секундами внутри приложения. Вне его рамок лимит пока остаётся неизвестным. Для сравнения: TikTok начинал с 15 секунд и сейчас позволяет загружать видео до 10 минут.

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

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

Ограничения и вопросы безопасности

Согласно данным, Sora 2 будет отказываться генерировать некоторые ролики из-за авторских прав. Но остаётся неясным, насколько сильной окажется эта защита: The Wall Street Journal сообщает, что OpenAI предложит правообладателям не проактивную защиту, а опцию «опт-аута» — то есть им придётся самостоятельно заявлять об исключении их контента из генерации.

Почему это важно

Причина выхода OpenAI на рынок соцсетей может крыться в неопределённости вокруг TikTok. Напомним, президент США Дональд Трамп несколько раз продлевал срок, который ByteDance дали для передачи американской части бизнеса TikTok под контроль США. OpenAI, судя по всему, увидела в этой ситуации окно возможностей.

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

Что случилось

Согласно новым правилам, которые Google планирует внедрить с сентября 2026 года, каждый разработчик Android-приложений должен будет:

• подтвердить свою личность с помощью государственных документов;
• передать Google информацию о приложении, включая идентификатор и ключ подписи.

Это касается всех приложений, даже если они не публикуются в Google Play.

Фактически это будет конец F-Droid и других открытых репозиториев приложений в их нынешнем виде.

Почему это важно

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

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

Теперь же Google хочет взять контроль над этими ключами, даже если приложение распространяется вне Google Play. Это создает монопольную модель, при которой все пути ведут через Google, несмотря на официальную поддержку сторонней установки .apk-файлов.

Под угрозой: свобода, приватность и конкуренция

Авторы F-Droid отмечают, что:

• не все разработчики хотят или могут регистрироваться у Google;
• это ударит по открытому ПО, анонимным проектам и альтернативным экосистемам;
• Android уже обладает встроенными механизмами безопасности (Play Protect), а Google Play регулярно пропускает вредоносные приложения.

Что делает F-Droid

Проект F-Droid уже обратился в регуляторные органы США, ЕС и других стран, призывая проверить инициативу Google на предмет злоупотребления доминирующим положением и монополизации рынка Android-приложений.

Что говорит Google

Google объясняет нововведения борьбой с вредоносными программами и мошенниками, а также повышением доверия к Android-приложениям.

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

Когда начнут действовать новые правила

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

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

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

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

Визуализируем проблему

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

При скорости 3 RPS часть запросов отбрасывается. Если новый запрос приходит на сервер в момент, когда тот уже обрабатывает другой, сервер его отклонит. Пользователь получит ошибку — этого нужно избегать. Исправить ситуацию можно, добавив ещё один сервер в пул нашего балансировщика нагрузки. Ура, запрос принят! Балансировщик отправляет по очереди запрос каждому серверу. Это называется балансировкой, циклическим перебором или «round robin». Один из самых простых и действенных способов балансировки нагрузки. Он хорошо работает, когда серверы имеют одинаковую мощность, а запросы примерно одинаково затратны.

Когда round robin не подходит

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

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

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

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

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

Проблема сохраняется на серверах с разной мощностью. Маломощная часть железа быстро перегружается и начинает отбрасывать запросы. При этом более производительное оборудование простаивает. Этот сценарий показывает основную слабость round robin — колебания. Однако round robin всё равно остаётся стандартным методом балансировки HTTP-нагрузки для nginx.

Как улучшить round robin

Улучшить round robin балансировку можно с помощью алгоритма «взвешенного циклического перебора» или «weighted round robin». Так он лучше будет справляться с вариативностью.

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

Хотя такой подход лучше справляется с разбросом мощности серверов, чем обычный round-robin, нам всё ещё приходится иметь дело с вариативностью «стоимости» запросов. Тактика «поручать людям вручную выставлять веса» быстро перестаёт работать. Свести производительность сервера к одному числу сложно и требует аккуратного нагрузочного тестирования на реальных сценариях. Это делают редко, поэтому другой вариант взвешенного round-robin вычисляет веса динамически, используя прокси-метрику задержку (latency).

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

Разметим каждый сервер и покажем среднюю задержку трёх последних обработанных запросов. Отправляем 1, 2 или 3 запроса каждому серверу на основе относительного различия в задержках.

Результат схож с weighted round robin. При этом не нужно заранее указывать вес каждого сервера. Алгоритм адаптируется к изменениям производительности со временем. Это называется «динамический взвешенный round robin».

Осталось понять, как метод справится с мощными колебаниями в мощности серверов и стоимости запросов.

Уходим от round robin

Динамически взвешенный round robin хорошо учитывает колебания мощности сервера и затрат на запросы. Но можно решить задачу элегантнее и проще. Применим балансировку по принципу «наименьшего количества соединений» — least connections.

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

Этот алгоритм просто реализовать, он отлично работает вне зависимости от степени вариативности, избавляет от неопределённости и точно вычисляет нагрузку каждого сервера. Поэтому метод — стандарт балансировки HTTP-нагрузки в балансировщиках AWS и применяется как опция в nginx. Как и в других подходах, не удаётся избавиться от потерь запросов. Но единственный случай, когда он отбрасывает запросы, — это когда буквально не остаётся места в очереди. Он гарантирует использование всех доступных ресурсов, и потому — отличный выбор по умолчанию для большинства рабочих нагрузок.

Оптимизируем latency (задержки)

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

Чаще нас волнует задержка (latency). Она измеряется в миллисекундах — от момента создания запроса до момента его обслуживания. В этом контексте принято говорить о разных перцентилях. Например, 50-й перцентиль (он же медиана) — это такое значение в миллисекундах, ниже которого находится 50% запросов и выше — тоже 50%.

Запускаем три симуляции с одинаковыми параметрами на 60 секунд. Каждую секунду снимаем метрики. Симуляции отличаются только алгоритмом балансировки. Давайте сравним медианы для каждой.

На графике перцентилям внутри одного алгоритма не назначены разные цвета. Более высокие перцентили всегда расположены выше.

Возможно, неожиданно, но у round-robin лучшая медианная задержка. Если смотреть только на этот показатель, мы упустим общую картину. Давайте посмотрим на 95-й и 99-й перцентили.

Мы видим, что round-robin показывает слабые результаты в верхних перцентилях. Как так получается, что у него отличная медиана, но плохие 95-й и 99-й перцентили?

При round-robin состояние серверов не учитывается, поэтому немало запросов попадает на простаивающие серверы — отсюда низкий 50-й перцентиль (медиана). Но с той же лёгкостью запросы отправляются и на перегруженные машины — поэтому 95-й и 99-й перцентили ухудшаются.

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

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

Применяем ещё один алгоритм

Если мы действительно хотим оптимизироваться по задержке, нам нужен алгоритм, который прямо учитывает latency. Было бы здорово объединить динамический взвешенный round-robin с least connections: чувствительность к задержке первого и устойчивость второго.

Возьмём плюсы от обоих подходов и попробуем избавить от минусов.

Такая идея возникла не впервые. Существует алгоритм Peak Exponentially Weighted Moving Average «пикового экспоненциально взвешенного скользящего среднего» или PEWMA. Название длинное и сложное, но принцип понятный.

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

Как он это делает? Комбинирует приёмы из динамического взвешенного round-robin и из least connections, а сверху добавляет щепотку собственной «магии».

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

Сначала посмотрим на 50-й, 95-й и 99-й перцентили в сравнении с данными для least connections из предыдущей части.

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

А что насчёт потерянных запросов?

Сначала он показывает лучшие результаты, но со временем начинает уступать least connections. Это логично: PEWMA стремится к наименьшим задержкам, и из-за этого иногда оставляет сервер недозагруженным.

К тому же, у PEWMA много настраиваемых параметров. Реализация, приведённая в этой статье, использует конфигурацию, хорошо показавшую себя в протестированных сценариях; дополнительная тонкая настройка может дать результаты лучше, чем у least connections. Но это и минус PEWMA по сравнению с least connections: большая сложность.

Заключение

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

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

Подведём итоги:

1. Round robin (циклический перебор) — самый простой алгоритм, который отправляет запросы по очереди каждому серверу. Хорошо работает только при одинаковой мощности серверов и одинаково затратных запросах. Имеет лучшую медианную задержку, но плохие высокие перцентили.
2. Weighted round robin (взвешенный циклический перебор) — учитывает мощность серверов через веса, которые задают разработчики. Требует ручной настройки и тщательного тестирования. Не адаптируется к изменениям производительности.
3. Dynamic weighted round robin (динамический взвешенный циклический перебор) — самостоятельно определяет веса серверов по задержке ответов. Адаптируется к изменениям производительности со временем. Хорошо справляется с колебаниями мощности и стоимости запросов.
4. Least connections (наименьшее количество соединений) — отправляет запросы на сервер с наименьшим количеством активных соединений. Метод простой и эффективный. Он использует все доступные ресурсы. Стандартный метод в AWS, опция в nginx.
5. PEWMA (пиковое экспоненциально взвешенное скользящее среднее) — самый сложный алгоритм, оптимизирует задержку, учитывая историю ответов с экспоненциально убывающим весом и текущую нагрузку. Лучшие показатели задержки во всех перцентилях, но его сложнее настроить. Метод также может сбоить при перегрузках.

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

По условиям соглашения, контроль над TikTok в США перейдет к новому совместному предприятию, в котором Oracle и инвесторы из США получат доминирующий пакет, а доля китайской ByteDance не превысит 20%.

Общая оценка американского бизнеса TikTok составила $14 млрд, сообщил вице-президент Джей Ди Вэнс. Сделка позволит избежать блокировки, предусмотренной законом о нацбезопасности, если китайская сторона не продаст свою долю.

Кто будет владеть TikTok в США

Новую компанию будут контролировать:

• Oracle, которая также возьмет на себя вопросы кибербезопасности TikTok и предоставит облачную инфраструктуру;
• инвестиционные фонды Silver Lake и MGX (ОАЭ);
• американские инвесторы ByteDance, включая Sequoia, General Atlantic и Susquehanna.

Общая доля американских инвесторов составит около 80%, что должно успокоить регуляторов. Китайская сторона при этом пока официально не комментирует сделку.

Президент Трамп заявил, что Си Цзиньпин одобрил сделку, хотя по словам Вэнса, со стороны Китая сначала был «некоторый саботаж».

Что дальше

Oracle получит ключевую роль в управлении безопасностью и хранении данных TikTok в США. Также, по словам Трампа, в сделке могут участвовать Руперт и Лаклан Мердоки, а также Майкл Делл.

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

У TikTok есть время до 16 декабря, чтобы завершить формирование новой структуры — до этой даты Минюст не будет применять санкции.

Также подписывайтесь на мой ТГ, который я почти не веду.

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

Я помню, как сейчас, ту прекрасную зимнюю пору: готовилась к демо. Последняя попытка. Последний шанс выйти в прод до нового года. Коллеги из других команд уже ушли на новогодний корпоратив — пить, курить и веселиться. А мы узким кружком готовились к демонстрации. Часики тикали, всё почти готово. Я открываю финальную вкладку… и у меня схлопывается интерфейс в ошибку 500, приложение встаёт колом — ни туда, ни сюда.

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

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

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

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

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

Нет.

В ней не пророс буйным цветом дефект регресса. Она не тестировалась вообще.

Никогда.

Ошибка 500 не была случайностью. Она была слепым пятном, про которое в спешке я забыла!

Господь. Я была плохой девочкой и тестировала без документации и тест-кейсов. Но обещаю, что это мой последний провал (ха-ха — нет). Обещаю потом всё задокументировать (нет). Обещаю аккуратно ввести рабочие планы (всё ещё нет).

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

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

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

И вдруг кружок загрузки завертелся — вкладка открылась.

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

Мы справились. За час мы пролетели через все эмоциональные качели: провал — успех — осознание приближающегося конца — смерть — и снова успех.

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

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

Да, мы бегали.

Да, у нас были провалы.

Да, у нас были дефекты в проде.

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

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

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

sorry not sorry

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

Если вы дошли до этого места — спасибо вам. И помните: всё обязательно получится (или не получится). Не теряйте веры. Не теряйте надежды. Продолжайте учиться и совершенствоваться.

Будущее не будет радужным и безоблачным — на самом деле, никогда не будет.

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

• CISA официально относит их к уязвимым факторам,
• Microsoft описывает, как их обходят AiTM, SIM‑swap и кража токенов.

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

Что такое двухфакторная аутентификация и чем она отличается от многофакторной

Двухфакторная аутентификация (2FA) встречает на входе в банковские приложения. Сначала вводите пароль, потом указываете код из СМС.

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

• код из СМС или приложения,
• отпечаток пальца,
• USB-ключ,
• пуш-уведомление на телефон.

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

Анна Храмцова, старший руководитель направления разработки продукта Dion, соавтор тг-канала Диагноз:Аналитик:

2FA — это частный, самый распространённый случай MFA. Когда говорят «MFA», часто подразумевают именно 2FA. А когда говорят о «более чем двух факторах» (3FA+), то имеют в виду системы с экстремально высоким уровнем риска. Для большинства сценариев, включая банковские приложения, 2FA выступает «золотым стандартом» и достаточной мерой.

Почему СМС-коды больше не гарантируют безопасность

В 2025 году мошенники чаще обходят 2FA, где используются коды из СМС.

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

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

SMS-коды — ненадежный 2-ой фактор аутентификации. Сегодня операции с копированием номеров и перехватом сообщений не столько редки и невозможны, как, скажем, 5 лет назад.

Третий — социальная инженерия. Мошенники звонят от имени техподдержки с просьбой продиктовать код из СМС для «проверки безопасности» или «отмены подозрительной операции».

Какие методы защиты работают

Приложения-аутентификаторы генерируют временные коды. Google Authenticator, Яндекс.Ключ обновляют комбинации каждые 30 секунд. Перечисленные сервисы работает по TOTP — код синхронизирован между телефоном и сервером через общий секретный ключ. Перехватить код невозможно, потому что он не передаётся по сети.

Физические ключи безопасности — это USB-устройства размером с флешку. YubiKey, Google Titan Key подключаются к компьютеру или телефону и подтверждают личность. Взломать такую защиту практически невозможно. Ключ проверяет подлинность сайта, поэтому не сработает на фишинговой копии.

Пуш-уведомления отправляют запрос на подтверждение входа в мобильное приложение.

Биометрия — отпечатки пальцев, распознавание лица. Смартфоны хранят эти данные в защищённом чипе.

Александр Шибаловский, CTO:

В исключительных случаях используется 4 фактора: например, логин + динамический код + физический носитель ЭП + биометрия. Только ключ в замке провернуть не хватает для верности 🙂

Делать самим или купить готовое решение

Разработка системы 2FA с нуля займёт минимум полгода работы команды из 3-4 человек. Это зарплаты, тестирование, исправление ошибок и постоянные обновления. Ответственность за каждую уязвимость ляжет на вас.

Анна Храмцова комментирует:

Моя рекомендация для большинства организаций: начать с оценки готовых решений на рынке. Фокус следует сместить с вопроса «разрабатывать или подключать?» на вопросы:
1. Какой сторонний сервис лучше всего соответствует нашим техническим требованиям и бюджету?
2. Как правильно интегрировать его в нашу ИТ-инфраструктуру?
3. Как его плавно внедрить для пользователей, чтобы повысить безопасность, а не создать барьеры?

Интеграция 2FA/MFA — это в подавляющем большинстве случаев использование стороннего сервиса, а не разработка с нуля. Создание собственной защиты требует огромных ресурсов, глубокой экспертизы в безопасности и постоянного сопровождения. Также в России есть риски, связанные с возможным отключением облачных сервисов, поэтому преимущество на стороне on-premise решений.
Разрабатывать своё решение имеет смысл только в очень специфических случаях. Например, если работаете в закрытой инфраструктуре, где запрещено подключение к внешним сервисам, или у вас уникальные требования, которые ни один вендор не покрывает. Но даже тогда лучше брать open-source библиотеки вроде privacyIDEA или Keycloak и дорабатывать их, чем писать всё с нуля.

Готовые решения делятся на три типа:

• SaaS (Software as a Service — программа как услуга) работает через интернет на серверах разработчика. Вы платите за подписку, подключаете сервис за пару дней и забываете про технические вопросы.
• On-premise (на вашей территории) устанавливается на серверы компании. Вы полностью контролируете данные, но нужны свои администраторы для поддержки системы.
• Open-source (открытый код) можно скачать бесплатно и доработать под свои нужды.

Большинству компаний подходят SaaS-решения: быстрый старт, предсказуемые расходы и команда профессионалов, которая следит за безопасностью 24/7. On-premise имеет смысл при жёстких требованиях регуляторов или работе с гостайной.

Александр Шибаловский считает:

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

Типичные ошибки при внедрении MFA и как их не допустить

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

Распространённые ошибки:

• Нет запасных вариантов входа. Сотрудник разбил телефон с приложением-аутентификатором, и всё — он не может войти в рабочие системы.
• Один метод для всех. Директору и стажёру предлагают одинаковую защиту. Хотя у директора доступ к финансам, а у стажёра — только к корпоративному чату.
• Сложность вместо удобства. Сотрудники вводят три разных пароля и ждут СМС по пять минут.
• Забыли про гостевые аккаунты. Подрядчики заходят в систему по старинке через логин-пароль, пока постоянный персонал мучается с токенами.

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

Когда два фактора достаточно, а когда нужно больше

Двухфакторной защиты достаточно для личной почты и соцсетей. Уперевшись в 2FA, взломщики пойдут искать жертву попроще. Добавьте к паролю код из приложения — и спите спокойно.

Выбор 2FA или MFA зависит от нескольких факторов:
Первый — стандарты и регуляторные требования (ГОСТы по идентификации и авторизации, финансовому сектору + требования ФСТЭК РФ + стандарты NIST SP 800 и др.). Второй — решение компании-поставщика услуги. Третий — решение пользователя (если компания-поставщик решила предоставить ему возможность выбора).
Для массовых пользователей (Госуслуги, банки, почта, соцсети) стандартом остаётся 2FA. Защита 3+ факторами встречаются преимущественно в сфере критичной инфраструктуры и крупных корпоративных решений.

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

Самая частая ошибка — внедрять 2FA как формальность, не продумывая пользовательский опыт, из-за чего пользователи саботируют систему. Часто забывают про резервные методы аутентификации, и когда пользователь теряет телефон или токен, компания теряет доступ к критичным системам на часы или дни.

Что делать, если пользователи саботируют защиту

Сотрудники обходят двухфакторную защиту через общие аккаунты, записывают резервные коды на стикерах или просят коллег войти под их учёткой. Люди саботируют MFA не из вредности — им просто неудобно.

Анна Храмцова комментирует:

Внедрение второго фактора ради второго фактора — это частая ошибка. Приступая к интеграции 2FA-решения, необходимо озадачиться вопросами потребностей бизнеса, требований ИБ и распространённых векторов атаки.

Как сделать безопасность удобной

1. Начните с малого.

Включите 2FA сначала для критичных систем — почты руководства, доступа к финансам, админки сайта. Когда сотрудники привыкнут, расширяйте охват.

2. Дайте выбор

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

3. Упростите вход для доверенных устройств

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

4. Объясните выгоду

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

5. Решите технические проблемы заранее.

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

Чем меньше человек тратит времени на борьбу с системой, тем охотнее её использует.

При выборе важно смотреть не только на функционал, но и на соответствие требованиям вашей отрасли — например, наличие сертификата SOC2, ISO 27001, поддержка GDPR. Также стоит учитывать удобство для конечных пользователей: если система слишком сложная, её будут обходить или отключать. Не забудьте проверить, как сервис ведёт себя при масштабировании и какие есть варианты восстановления доступа — это критично при сбоях.

Чек-лист для успешного внедрения 2FA и MFA

Подготовка:

• Составьте список всех систем, где нужна защита (почта, CRM, админка сайта).
• Проверьте, какие методы 2FA поддерживает каждая система.
• Определите критичность доступа: где хватит СМС, где нужен аппаратный ключ.

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

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

Запуск:

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

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

1. Study AI

Study AI — это платформа, которая даёт доступ к популярным нейросетям (ChatGPT, Claude, Midjourney, Google и т.д) и собственным моделям, заточенным под конкретные задачи. Через веб-интерфейс можно генерировать изображения, создавать реалистичные фотографии людей, редактировать снимки, увеличивать разрешение, стилизовать или объединять несколько картинок в одну. Сервис подходит дизайнерам, маркетологам, студентам и контент-креаторам, которым нужно быстро получать визуальные решения без сложных настроек.

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

Ключевое отличие сервиса — работа напрямую из РФ: не нужен VPN, оплата возможна российскими картами. Генерация быстрая (всего несколько секунд), качество изображений высокое, интерфейс поддерживает русский язык. Кроме того, у платформы есть собственное комьюнити с промтами и советами, что облегчает работу новичкам.

Study AI работает по подписочной системе: минимальный тариф начинается от 199 рублей — это одна из самых доступных цен на рынке. Дополнительно можно докупить токены для продолжения генерации.

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

2. GPTunnel

GPTunnel — это универсальная платформа, которая собрала более сотни нейросетей для генерации текста, изображений, видео и аудио в одном месте. Здесь доступны ChatGPT, Midjourney, Stable Diffusion, Flux, Suno, Sora, ElevenLabs и десятки других моделей — от инструментов для генерации картинок до сервисов для оживления фото или замены фона. Сервисом пользуются уже свыше миллиона человек и более трёх тысяч компаний, а количество запросов превысило 10 миллионов.

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

Для дизайнеров и иллюстраторов GPTunnel открывает доступ к мощным графическим моделям: Flux создаёт чёткие и детализированные картинки в разных стилях, Recraft идеально подходит для логотипов и иконок, Seedream 3 работает как бюджетное, но эстетичное решение с яркой палитрой, а Midjourney остаётся эталоном художественной генерации. Маркетологи и контент-креаторы могут использовать сервис для создания рекламных визуалов и озвучки роликов, разработчики — подключать API для автоматизации процессов, а команды — получать корпоративный доступ и персональное сопровождение.

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

3. GoGPT

GoGPT — это агрегатор нейросетей, который собрал в одном интерфейсе самые популярные модели — ChatGPT 5, DeepSeek, Claude, Midjourney, Flux и многие другие. Сервис доступен без VPN и номера телефона, работает на русском языке и подходит как для работы с текстами, кодом и файлами, так и для генерации изображений и обучения собственных моделей. Пользователи отмечают универсальность платформы: здесь можно писать статьи, анализировать данные, готовить SEO-контент, создавать презентации, обрабатывать изображения или обучать Flux на своих фотографиях для персонализированных результатов.

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

предлагает бесплатный тариф с базовыми возможностями и платный план с расширенным доступом к GPT-5, Claude Opus, DALL·E 3, Flux Pro, Ideogram и инструментам для замены лиц или анализа видео. Оплата возможна в рублях, интерфейс локализован, а запросы обрабатываются за считанные секунды.

Для дизайнеров GoGPT становится мастерской визуального контента: в чате доступны Midjourney, DALL·E, GPT-Image, Ideogram и Flux, которые помогают создавать логотипы, обложки, художественные сцены или фотореалистичные портреты. Для маркетологов и блогеров сервис полезен готовой базой промтов, которая ускоряет работу над текстами и изображениями. Разработчики используют его для генерации кода и анализа файлов, а продакт-менеджеры — для быстрого ресерча и подготовки материалов. Дополнительное преимущество — возможность работать через веб, Telegram-бот или мобильное приложение.

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

4. Шедеврум

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

Главное преимущество Шедеврума — полностью свободный доступ без подписок и ограничений (с недавнего времени запустили ПРО версию за 100 рублей в месяц). Интерфейс прост и интуитивно понятен, поэтому начать создавать изображения может любой, даже без опыта работы с нейросетями. За генерацию отвечает собственная модель «Кандинский», которая регулярно обновляется и хорошо понимает запросы на русском языке. Это позволяет получать качественные, точные и выразительные иллюстрации по коротким текстовым описаниям — от реалистичных рендеров и портретов до картинок в жанре аниме.

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

Шедеврум выступает как оригинальный проект Яндекса, где нейросеть совмещена с социальной платформой. Он подойдёт тем, кто ищет лёгкий и бесплатный способ попробовать себя в генеративном искусстве и при этом хочет быть частью творческого комьюнити.

5. Kandinsky 3.1

Kandinsky 3.1 — российская разработка от Сбера, которая заслужила популярность благодаря высокому качеству генерации и множеству способов использования. Доступ к нейросети можно получить через сайт fusionbrain.ai, телеграм-бот, навык «Включи художника» в Салюте, сайт rudalle.ru, а также в боте VK. Для разработчиков предусмотрена интеграция через фреймворк diffusers, что делает инструмент универсальным как для массовых пользователей, так и для специалистов.

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

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

Midjourney давно стал эталоном генеративного искусства, но рынок уже предлагает массу достойных альтернатив, каждая из которых закрывает свои ниши. Study AI и GoGPT делают ставку на простоту и универсальность, предлагая быстрый доступ к картинкам без технических барьеров. GPTunnel превращается в полноценный хаб для работы с десятками моделей без подписок. Шедеврум от Яндекса добавляет социальное измерение и делает творчество доступным каждому. А Kandinsky 3.1 от Сбера расширяет горизонты, позволяя работать не только с изображениями, но и с видео и анимацией.

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

Главные отличия Web3 от Web2

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

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

В Web3 логика сильно меняется. Пользователь входит в систему с помощью криптокошелька, например, MetaMask. Каждая задача создаётся транзакцией и записывается в смарт‑контракт, а значит становится частью блокчейна. Удалить её уже нельзя — только отметить статус выполнения. Такой подход даёт прозрачность: любой участник сети может проверить, что задача действительно существует, и её статус изменён честно.

Стек Web3: что понадобится на практике

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

• Блокчейн: Ethereum, Layer‑2 (Arbitrum, Optimism, Base, Polygon), Solana.
• Языки: Solidity (EVM), Rust (Solana), Go (инфраструктура и сервисы).
• Библиотеки: ethers.js, wagmi.
• Фреймворки: Hardhat, Foundry, Truffle.
• Хранилища: IPFS/Arweave для файлов и метаданных.
• Кошельки/подключение: MetaMask, WalletConnect (v2/WalletConnect Network), Web3Auth.

Точка входа для новичка — Alchemy, а также ethers.js.

Пример. Быстрое подключение кошелька (ethers.js).

Архитектура DApp: из чего состоит современное Web3‑приложение

Любое Web3‑приложение строится из нескольких слоёв, каждый со своей ролью. Фронтенд остаётся привычным SPA, но работает не с сервером, а напрямую с кошельком и смарт-контрактами. Контракты содержат бизнес‑логику и хранят ссылки на данные в децентрализованных хранилищах. Оракулы обеспечивают связь с внешним миром, например, передают цены или сообщения между разными блокчейнами. Важную часть играет off‑chain слой — сервисы вне блокчейна (индексаторы, аналитика), которые помогают быстрее искать и обрабатывать данные, при этом не перегружать сеть.

Пример. Возьмём DeFi‑приложение. Пользователь открывает фронтенд и инициирует операцию swap(). В ответ фронтенд обращается к смарт‑контракту, который выполняет обмен токенов. Чтобы определить курс, контракт тянет актуальные данные через оракул. При этом тяжёлые артефакты, изображения или отчёты не хранятся в блокчейне напрямую — они лежат в IPFS. Сам контракт содержит только контент‑идентификаторы CID. Таким образом, получаем баланс: блокчейн отвечает за логику и безопасность, а децентрализованное хранилище — за данные.

Практика: ваш первый DApp за вечер

Давайте попробуем собрать простейшее приложение своими руками.

Шаг 0. Подготовка

Сначала убедитесь, что у вас стоит Node.js LTS и Git. Также нужен браузер с установленным MetaMask, где можно создать тестовый аккаунт. Чтобы оплачивать транзакции в тестовой сети, заранее возьмите немного тестовых монет через faucet — например, для Sepolia или Polygon Amoy.

Шаг 1. Проект

Создадим новый проект и установим Hardhat вместе с тулзами. Эта среда нужна для компиляции и деплоя контрактов.

Шаг 2. Контракт

В папке contracts/ создаём файл TaskTracker.sol и копируем туда код смарт-контракта из первого раздела. Это и будет бизнес-логика нашего приложения.

Шаг 3. Сценарий деплоя

Пишем скрипт, который разворачивает контракт в сети. Это простой скрипт на JavaScript, который вызывает методы Hardhat.

Шаг 4. Конфиг сети

В файле hardhat.config.js добавляем настройки для подключения к тестовой сети. Используем RPC-URL от Alchemy или Infura и приватный ключ от тестового аккаунта — его можно экспортировать из MetaMask, но использовать только для тестовой сети.

Шаг 5. Деплой в тестнет

Теперь запускаем скрипт деплоя. После выполнения увидите адрес контракта — он понадобится для фронтенда.

Шаг 6. Фронтенд (React + ethers.js + wagmi)

Собираем простое SPA: форма, чтобы добавить задачи, и кнопка «complete». Здесь мы используем ethers.js для обращения к контракту. Сделайте вызовы addTask и completeTask.

Подводные камни Web3-разработки и что с ними делать

Комиссии (gas): любая запись в блокчейн стоит денег и иногда комиссия выше ценности операции — например, $10 за простую задачу.

• Что делать: использовать Layer-2 (Arbitrum/Optimism/Base/Polygon), выбирать сети с низкими комиссиями (Solana, Avalanche), оптимизировать контракты и батчи транзакций.

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

• Что делать: показывать «оптимистичный UI», кешировать данные, переносить часть логики off-chain, использовать быстрые сети (Solana, Near, Aptos).

Безопасность: код контракта неизменяем, и одна ошибка может стоить миллионов.

• Что делать: проходить аудит (CertiK, Trail of Bits), использовать проверенные библиотеки (OpenZeppelin), писать тесты в тестовых сетях (Goerli, Sepolia), внедрять баг-баунти и ролевую модель доступа.
• Ресурс: ConsenSys Diligence — Smart Contract Security Best Practices.

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

• Что делать: использовать аккаунт-абстракцию (ERC-4337), социальный логин, gasless транзакции через Paymaster, улучшать UI (подсказки, авто-фокус на MetaMask).

Регуляция: законы о Web3 пока разные в каждой стране. Легальное в одной юрисдикции может быть запрещено в другой (например, токенизация акций без лицензии).

• Что делать: консультироваться с юристами, следить за изменениями. Например, MiCA в ЕС — “Markets in Crypto-Assets Regulation” — это единый регламент по криптоактивам в Евросоюзе.

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

Карьерные возможности и перспективы

Web3‑разработчиков уже активно ищут: зарплаты в среднем предлагают выше, чем у Web2‑коллег. Кроме программистов, востребованы смежные роли: аудиторы смарт‑контрактов, специалисты по безопасности, а также продакт‑менеджеры и аналитики, которые понимают специфику блокчейна.

Чтобы войти в профессию, начните с изучения Solidity и базовых паттернов смарт‑контрактов. Сделайте пару пет‑проектов и выложите код в GitHub. Отличный вариант прокачки — участвовать в хакатонах и грантовых программах от Ethereum Foundation или Solana Grants. Это даёт и опыт, и контакты, и иногда финансирование.

Пара пет‑проектов + понимание блокчейна — хороший старт в Web3‑команду.

Будущее Web3

Web3 не вытеснит Web2 полностью, но поменяет привычный подход к разработке. Разработчику это открывает новые вызовы: комиссии, безопасность и UX, но одновременно и новые возможности — прозрачные данные, токенизация, децентрализованные бизнес‑модели.

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

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