Веб-разработка *

В JDK 27 появится JEP 527: гибридный post-quantum key exchange для TLS 1.3. Разбираем, что меняется в JSSE, зачем нужен X25519MLKEM768 и какие проблемы могут всплыть при миграции.

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

Мой опыт говорит мне о том, что агентов можно выстроить в цепочку, подать на вход задачу (issue) и на выходе иметь готовый результат - код. Или отказ в обработке и причину отказа - тоже себе результат. Ведь именно такую цепочку я и сделал. Цепочку, которая автоматически, без моего участия, превращает запрос любого github-пользователя в страницу моего сайта. Или не превращает, если не посчитает нужным. Теперь любой github-пользователь может не просто критиковать мой февральский коммент, а критиковать предметно - на деле показать, что агенты действительно не могут справляться с возложенной на них задачей. Или убедиться на практике, что могут.

Практика Project Loom: как включить preview Structured Concurrency в javac, Maven и Gradle, как использовать ScopedValue для request context и StructuredTaskScope для параллельных вызовов, joiner’ы, timeout и связка обеих фич в одном примере. Примеры под JDK 25+

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

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

Разбираю проблемы cross-platform onboarding между Telegram Mini Apps и native apps. Почему Android, iOS, Windows и Linux по-разному ведут себя при deeplink handoff внутри Telegram WebView.

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

Привет! Меня зовут Костя, я разработчик интерфейсов в ЮMoney. В этой статье разбираю, почему вкладка после возврата из фона начинает вести себя странно: интерфейс подвисает, таймеры съезжают, события приходят пачкой.

Материал особенно пригодится тем, кто делает сложные SPA с realtime‑обновлениями, WebSocket и насыщенным UI — CRM, дашборды, платёжные сценарии.

В статье разберём:

— как устроены Page Visibility API и Page Lifecycle API,
— зачем браузеры ограничивают фоновые процессы,
— что происходит при заморозке вкладок, системном сне и возврате страницы из BFCache,
— чем отличаются Chrome, Safari и Firefox,
— какие API уже устарели,
— а какие подходы помогают делать интерфейсы стабильнее в реальных пользовательских сценариях.

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

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

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

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

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

При проектировании REST-интеграций часто возникает конфликт заголовков, когда и целевая система, и шина данных требуют дефолтный Authorization. В этой статье мы пошагово разберем, как перенастроить FESB на анализ кастомного заголовка для отдельной группы методов. Вы узнаете, как отключить стандартную проверку, распарсить Base64 с помощью Groovy и вернуть корректный HTTP-ответ.

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

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

Рассказываю о том, что делать со всем этим безобразием...

Сначала всё выглядело как типичная AI-история успеха.

За пару вечеров LLM помогла превратить Google Sheets для учёта финансов в настоящее приложение. Потом появился backend, sync между устройствами, mobile-first UX, AI-рекомендации, rollback, conflict resolution, миграции, Docker images, golden tests и React-компонент на 10 537 строк.

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

Привет, Хабр! Это снова Алиса из KISLOROD. В прошлых частях мы вынесли из Битрикса каталог, корзину, цены и чекаут. Но в любом ecommerce-проекте есть еще одна зона турбулентности — интеграции.

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

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

В конце мая Яндекс открыл Yandex Commerce Protocol для всех — теперь онлайн-магазины могут подключать продажи через Алису AI, Поиск и Яндекс Ритм. Из коробки готовые решения есть для Яндекс KIT, Яндекс Маркета и 1С-Битрикс. Для WooCommerce — нет. У меня магазин на WP, и я написал плагин сам. Open-source, GPL-2.0, все 10 эндпоинтов протокола закрыты. Разбираю архитектуру: как боролся с письмами “новый заказ на 0 ₽”, зачем идемпотентность по session_id, как сделать совместимость с HPOS-хранилищем заказов, и пара других граблей, в которые наступил.

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

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

А PSS — Passenger Service Systems — это как раз те самые динозавры. Древние, массивные, неприкасаемые. В них живут бронирования, билеты, тарифные правила и вся логика, объясняющая, почему перелёт с пересадкой в Чикаго стоит как подержанная «Тесла». PSS — это священные реликвии, написанные в эпоху телетайпов и перфолент, и с тех пор тронутые примерно столько же раз, сколько египетские пирамиды. Работает? Работает. Значит, не трогаем. Любая попытка модернизации выглядит как попытка провести МРТ на мамонте: интересно, но зачем?

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

Стек выбирал не по хайпу, а по принципу «доеду и не утону в обслуживании»: FastAPI (быстро, асинхронно, автодоки), Next.js на React (SSR из коробки — критично для SEO), PostgreSQL (SQLite кончился на первых же конкурентных записях), Redis для кэша и рейт‑лимитов. Nginx + systemd на обычном VPS. Никакого Kubernetes — для одного это способ обслуживать инфраструктуру вместо разработки.

llms.txt - это файл в корне сайта, который говорит языковым моделям, что у вас за сайт, какие источники канонические и что цитировать. ChatGPT, Perplexity и Claude уже его читают. Большинство сайтов в Рунете его не имеют, поэтому AI-краулеры цитируют их или плохо, или никак. Файл пишется за 30 минут, эффект на цитируемость в AI-выдаче появляется в течение 1–4 недель.

В статье разбираю: что такое llms.txt, чем отличается от robots.txt, какие 5 блоков должны быть внутри, как написать свой за час, и показываю живой пример с production-сайта.

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

Привет, Хабр! Это снова Алиса из сериала про Laravel рядом с Битриксом.  В первой части мы аккуратно подселили Laravel к Битриксу. Во второй — растащили события, авторизацию и тяжелую логику по нормальным сервисам, а в третьей — перестали мучить каталог SQL-запросами и отдали поиск OpenSearch.

Теперь добрались до места, где любой e-commerce начинает показывать характер: корзина и расчет заказа. Это каталог может тормозить незаметно. А вот если корзина начинает чудить — это уже чувствует бюджет.

Недавно я увидел видео, где маленький мальчик собирает кубик Рубика за 2,76 секунды (вот оно), и мне тоже захотелось научиться его собирать. Конечно, не за такое время, но главное — суметь сложить хотя бы за 10 минут. Главная проблема в том, что кубика у меня нет; можно купить, но это как-то скучно, на троечку. Поэтому я подумал: а почему бы не написать за выходные простой код, чтобы побыстрее посмотреть и покрутить кубик, а потом уже можно и купить. Заодно и разберусь, где что находится у кубика.