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

Затем кэширование нарушило авторизацию.

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

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

При нагрузочном тестировании токен истекал, и несколько запросов одновременно проходили через один и тот же поток. Каждый из них видел пустой кэш и запрашивал у внешнего API новый JWT. Внешний API аннулировал предыдущий токен каждый раз, когда выдавал новый.

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

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

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

Привет, Хабр. На связи Илья Новиков, технический директор команды разработчиков «Исходный код».

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

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

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

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

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

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

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

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

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

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

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

Спойлер: оба находятся в опасности, но по-разному. Эта разница имеет значение.

Я не собирался сравнивать веб и мобилку как две враждующие платформы.

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

На вебе можно спрятать админку за условием в JavaScript и решить, что доступ закрыт. В мобилке можно положить токен в SharedPreferences и надеяться, что до него никто не доберется. Можно оставить открытый бакет, отключить нормальные правила Firebase, забыть про rate limit на логине или принять userId из тела запроса.

Все это выглядит как мелочи, пока приложение работает.

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

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

DatePicker казался нам небольшой задачей в разработке UI, пока мы не попробовали создать компонент, который будет корректно работать с keyboard navigation, screen reader’ом, управляемым состоянием и реальными проверками доступности.

Нам потребовался DatePicker производственного уровня на React и TypeScript, и сначала очевидный путь казался очень заманчивым: дать AI четкий запрос, получить 80% готового кода, а остальное доработать руками. Подробный разбор этого кейса есть в моей предыдущей статье «Попросили Claude создать WCAG-доступный DatePicker на React и потратили 3 дня на доработки».

Так вот.

Модель может сгенерировать структуру календаря, атрибуты ARIA, базовую keyboard navigation и логику работы с датами.

Затем начинается интеграция: поведение фокуса становится нестабильным; возникают конфликты между обработчиками событий; озвучивание screen reader’ами требует тщательного тестирования; небольшое изменение в логике работы с датами может неожиданно нарушить работу календаря; код выглядит нормально, но компонент пока не является надежным.

В этой статье я сравниваю два способа создания доступного DatePicker'а с помощью AI:

Первый — 80% кода с помощью AI, остальные 20% руками. Второй — системное проектирование с AI-агентом: PRD, декомпозиция задач, правила агента, внешняя верификация, Vitest, Playwright, сборка Vite, проверки типов и строгий цикл, в котором агент не может двигаться дальше, пока не будет пройден текущий шаг.

Дальше все по делу: в чем AI действительно нам помог; где он начал сбиваться с курса; почему одного большого promt'а оказалось недостаточно; как The Verifier изменил процесс и почему основная задача инженера в разработке с использованием AI больше не сводится только к написанию кода, а заключается в контроле над замыслом, архитектурой, контрактами и стоимостью изменений.

Выбор даты кажется небольшой задачей в UI, пока не попробуешь сделать его по-настоящему WCAG-доступным.

Нам понадобился настраиваемый DatePicker на React для процесса записи на прием к врачу, где пользователи, работающие с keyboard navigation, и люди, использующие screen reader’ы, должны были выбрать дату без лишних затруднений.

Claude сделал нам хорошую первую версию: структуру компонента, ARIA-атрибуты, базовую keyboard navigation и логику календаря. На первый взгляд результат выглядел почти готовым.

Затем мы запустили NVDA, VoiceOver и протестировали сценарий keyboard navigation.

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

Код выглядел нормально, но UX оставлял желать лучшего.

В этой статье мы рассмотрим реальную работу, стоящую за WCAG-доступным DatePicker'ом: где AI сэкономил нам время; где он не справился; как нам помог WAI-ARIA APG; какие детали нам пришлось исправлять вручную и почему доступность нельзя проверить, просто прочитав сгенерированный код.

Приготовьтесь к инсайтам, багам и победам!