Привет, Хабр! Меня зовут Кирилл Курдюков, и мы с командой делаем YDB (СУБД Яндекса). Как и с языками программирования, популярность СУБД определяется не только их возможностями, но и экосистемой.

В предыдущей статье я рассказал о том, как разработать Java-клиент для распределённой СУБД и интегрировать его с популярными ORM. А из этой статьи вы узнаете, как под капотом работает ADO.NET, почему управление пулом сессий может сильно влиять на ваш код работы с базой данных и какой стратегии обработки ошибок можно придерживаться для разработки отказоустойчивых сервисов. Статья будет полезна тем, кто изучает особенности взаимодействия в распределённых системах или просто хочет научиться лучше писать клиентский код, работающий с современными распределёнными системами.

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

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

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

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

Привет! Меня зовут Алексей Архипенко, я руковожу группой разработки ML‑инфраструктуры в команде YTsaurus. Мы часть Yandex Infrastructure и предоставляем пользователям внутри Яндекса инфраструктурный фундамент для самых разных задач машинного обучения.

YTsaurus — основная платформа для хранения и обработки данных Яндекса, которая доступна на GitHub под лицензией Apache 2.0. Это позволяет всем желающим загрузить систему на свои серверы, а также дорабатывать её под свои нужды. Мы уже писали в прошлых постах про её выход в опенсорс и дальнейшее развитие, а также кейсы использования в рекламе. Сегодня расскажу, как Яндекс запускает в ней почти все ML‑обучения и batch‑инференс.

Привет, Хабр! Меня зовут Иван Кузнецов, я Android‑разработчик в Кинопоиске. В прошлой статье я научил Jetpack Compose показывать рекомпозиции в реальном времени, но это был скорее учебный стенд: куча модификаторов, обёрток и примеры, которые нужно готовить вручную.

Я хотел чего‑то более полезного: чтобы IDE сама показывала, какие composable‑функции перерисовываются прямо сейчас, а какие скипаются и какие параметры реально меняются. Нажал Run — и редактор превратился в живую тепловую карту UI.

Ради этого пришлось сделать то, чего нормальные люди обычно избегают: залезть под капот Kotlin Compiler Plugin и научиться внедрять код в промежуточное представление на этапе компиляции, разобраться в битовых масках Compose и поднять TCP‑сервер внутри IntelliJ, чтобы запущенное приложение могло стучаться прямо в IDE.

Так появился Riflesso — плагин, который переносит идею Layout Inspector прямо в редактор кода и делает Compose прозрачным. В этой статье я разберу его архитектуру и покажу, как компилятор, клиентская библиотека и плагин IDE собираются в один инструмент.

Сколько будет корень из нуля? Даже школьник ответит не задумываясь: ноль. Но если задать этот вопрос JIT‑компилятору Maglev внутри движка V8, то при определённых обстоятельствах он сначала скажет: «ноль», а потом решит сэкономить на проверке безопасности и отдаст злоумышленнику доступ к памяти браузера.

Меня зовут Паша Кузьмин, я занимаюсь практической безопасностью Яндекс Браузера и проекта Chromium. В нашей команде мы регулярно разбираем уязвимости и исследуем методы атак — чтобы защищать пользователей до того, как их атакуют злоумышленники. Сегодня расскажу про CVE-2025-9864 — уязвимость, которую я нашёл в движке V8.

Это история о том, как безобидный Math.sqrt(0) превращается в use‑after‑free, а затем в произвольное чтение и запись памяти. Разберём проблему по шагам: от теории до работающего эксплойта.

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

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

Чтобы перестать каждый раз изобретать велосипед, мы собрали накопленные практики в единый подход и сделали инструмент для чат‑ботов с ИИ — @gravity‑ui/aikit. Он позволяет создать полноценный интерфейс ассистента за несколько дней и при этом легко адаптировать его под разные сценарии.

Меня зовут Илья Ломтев, я старший разработчик в команде Foundation Services Yandex Cloud, и в статье я расскажу, почему мы решили собрать AIKit, как он устроен, немного о планах на будущее — и о том, что можно попробовать у себя.

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

Проблема известна. Scala использует implicit parameters на уровне языка, Kotlin экспериментирует с context receivers, Android полагается на Dagger. А Swift не предлагает встроенного решения. Поэтому мы в команде Яндекс Браузера создали библиотеку Implicits — механизм неявной передачи зависимостей с compile‑time‑проверками. Она успешно работает в продакшне Браузера на полутора миллионах строк Swift‑кода, а ещё доступна в опенсорсе.

В этой статье я расскажу о поиске собственного подхода для передачи зависимостей в коде на Swift, о том, как внедрение Implicits позволяет существенно сократить boilerplate, ускорить рефакторинг и улучшить читаемость кода благодаря локальному объявлению только реально используемых зависимостей, а также покажу реальные примеры из продакшн‑кода мобильной версии Яндекс Браузера.

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

Раньше для этого можно было использовать только строку User‑Agent, которую браузер отправляет автоматически, но её избыточность и сложность парсинга стали сдерживать развитие веба. Client Hints предлагает другой подход: вместо того чтобы сразу раскрывать всю информацию, браузер передаёт только те данные, которые действительно нужны сайту.

На связи Степан из команды Яндекс Браузера. Сегодня поговорим о том, как мы переходим от устаревшего User‑Agent к современной технологии Client Hints. В статье разберём, почему User‑Agent стал проблемой, как работают хинты под капотом и какие перспективы у перехода на новую технологию.

Сегодня мы делимся техрепортом, в котором разобран полный цикл создания нового семейства моделей Alice AI: базовая текстовая Alice AI LLM и специализированная LLM Search, мультимодальная Alice AI VLM и картиночная Alice AI ART. 

В части про Alice AI LLM расскажем, как сделали упор в Alignment на RL и Reward Modeling: мы минимизируем число разрозненных RL-стадий, собирая «общий RL». Вместо хрупкого «суперсигнала» используем аспектную формулировку качества и агрегируем её в целевую функцию, чтобы изменения критериев не требовали пересборки всей разметки. В главе про Alice AI LLM Search расскажем про многократные последовательные походы в Поиск с последующей фильтрацией/ранжированием источников. А также о том, как готовим ответы с использованием документов разной модальности (веб-документы, картинки, видео, гео).

Чтобы «вывезти» MoE-модель на сотни миллиардов параметров, мы целенаправленно сняли инфраструктурные ограничения обучения и инференса: в обучении используется YaFSDP (которую мы выложили в опенсорс) и собственная библиотека коллективных коммуникаций YCCL. В прод-инференсе мы работаем под SLA (avg TPOT ≤ 70 ms, p95 TTFT ≤ 2 s) и достигаем их комбинацией TP Attention/EP FFN, KV cache reuse, FP8 w8a8kv8 (в т. ч. сжатие KV cache ~3,05→~1,52 GB) и спекулятивного декодинга EAGLE‑3, что в сумме даёт 5.8× ускорение относительно BF16 (и 1,32× относительно лучшего open-source). Параллельно для Alice AI VLM нарастили в 1,5 раза объем претрейна, контекст до 32k и обновили OCR-датасет; VLM-генератор работает «из коробки», а для математики/геометрии выделен специализированный VLM‑решатель. В пайплайне Alice AI ART повышение релевантности к промпту начинается с диагностики смещений в датасете с помощью VLM и последующей адресной коррекции обнаруженных проблем.

Недавно все эти модели и решения легли в основу нашего нового ИИ-ассистента, и уже к ноябрю, согласно исследованию Mediascope, Алиса AI вышла на первое место по используемости среди россиян (14,3%), обойдя ранее доминировавший DeepSeek (9,4%). Кроме того, модель Alice AI LLM теперь доступна и для разработки собственных AI-решений на платформе Yandex AI Studio.

Всем привет! Меня зовут Сергей Бунатян, я руководитель службы в Техплатформе Городских сервисов Яндекса. 

На сегодняшний день существует довольно много брокеров сообщений. Наиболее часто используемыми в индустрии, пожалуй, будут те, которые, реализуют парадигму очереди сообщений. Самых известных представителей вы наверняка знаете, — Apache Kafka и RabbitMQ, а внутри Яндекса широко используется Logbroker. И, тем не менее, как нетрудно догадаться из этого вступления, мы зачем‑то решили написать свой брокер сообщений.

Сегодня я расскажу про нашу систему, которая называется STQ — Sharded Tasks Queue. По названию системы можно было бы подумать, что это ещё один сервер очередей, однако это будет не совсем верно. STQ — это скорее message broker. 

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

Привет! Меня зовут Дима Кривопальцев, я тимлид бэкенд‑команды Яндекс Диска (Яндекс 360). Уже больше семи лет я занимаюсь разработкой высоконагруженных распределённых систем — и в статье расскажу об одной из них.

В Яндекс 360 есть сервисы с очень большими нагрузками — и по RPS, и по объёму хранимых данных, и по числу обрабатываемых асинхронных задач. Именно последняя часть — асинхронная обработка — будет в центре этого рассказа.

Тема может показаться немного провокационной: речь пойдёт об очередях поверх SQL‑баз, а в сообществе такое решение принято считать антипаттерном — и на это есть основания. На конференциях и в статьях обычно можно услышать скепсис: «Очередь на PostgreSQL? Не стоит даже пытаться». Действительно, подобных попыток было много, и почти все сталкивались с типовыми проблемами — от блокировок до деградации производительности.

Тем не менее, в реальности у многих крупных компаний всё равно есть свои очереди, построенные поверх SQL‑баз — как PostgreSQL, так и MySQL. Это решение встречается и в российских, и в зарубежных командах. Яндекс Диск здесь не исключение — у нас тоже есть своя реализация, о которой сегодня и пойдёт речь.

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

Раньше для такого требовались: стейт‑машина с полудюжиной состояний, очереди и воркеры, обработчики на каждое событие и блокировки от race conditions. Теперь всё это описано в одной функции, которая вообще выглядит как псевдокод. 

Магия? Нет, Temporal. 

С тех пор как мы перенесли процессинг на Temporal, разработка существенно упростилась. Пользователь оплачивает заказ, ресторан его подтверждает и готовит, курьер забирает и привозит — ровно это и отражено в коде. Ну разве не прелесть?

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

Меня зовут Дмитрий, и я руковожу ML‑разработкой в команде автонавигации Яндекс Карт. Вместе с моим коллегой Альбертом Юсуповым (@al‑iusupov) в этой статье мы поделимся историей полного переосмысления системы генерации дорожных аннотаций. Расскажем, почему решили отказаться от десятков хитрых условий в коде, а также почему заманчивая идея отдать всё на откуп большим нейросетям (VLM, LLM) провалилась. И, наконец, как пришли к элегантному решению: создали уникальный датасет с помощью сотен водителей‑экспертов и обучили быструю и точную ML‑модель, которая работает по принципу «меньше, но лучше».

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

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

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

Привет! На связи Антон Полухин из Техплатформы Городских сервисов Яндекса. Сегодня я расскажу о ноябрьской встрече Международного комитета по стандартизации языка программирования C++, в которой принимал активное участие. Это была первая из встреч, связанных с «полировкой» C++26. Другими словами, новые фичи C++ пока не появятся — комитет должен только проработать замечания всех стран-участников, включая наши замечания от России.

Однако от плана немного отступили и втащили некоторые новинки как ответы на пожелания участников комитета: std::integer_sequence оброс новой функциональностью, а std::format научился в constexpr.

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

Всем привет, меня зовут Алексей Чубуков. Я аналитик из команды поиска и назначений водителей в Яндекс Такси. В нашей команде мы оптимизируем алгоритмы, которые помогают находить водителей на заказы оптимальным способом, чтобы пользователи быстрее получали машины, а водители бóльшую долю времени проводили с пассажирами. 

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

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

Сегодня мы, команда платформы данных в Yandex Cloud, хотим рассказать о SPQR — нашем опенсорс‑инструменте, который который создавался как ответ на боль шардирования и эксплуатации крупных OLTP‑систем. Под катом — история о том, что стало отправной точкой для его создания, какие задачи он помогает решать, на чём основано наше решение и что помогает ему быть довольно простым в эксплуатации.

Что такое код-гольф? Это соревнование, в котором надо решить задачу по программированию (как правило, несложную), используя наименьшее количество символов. Соревнование довольно известное. Можно поиграть, например, на одноимённом сайте, есть целая секция на CodinGame, иногда такие соревнования публикует kaggle, была такая секция на HackerRank (сейчас её я не нашёл).

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

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

Эта статья — смесь разбора задач и истории появления соревнования по код-гольфу на конференциях Яндекса.

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

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

В этой статье мы разберём, как устроен один из ключевых инструментов — map‑editor, обеспечивающий создание и развитие HD‑карт для роботов, какие технические вызовы встречаются по пути и как мы с ними справляемся. Среди наших технологий — FastAPI и C++ для серверной логики, PostgreSQL с PostGIS для работы с геометрией, интеграция с облачными хранилищами и распределёнными вычислениями, а также элементы автоматизации на базе ML.

Всем привет! Я Андрей, в Яндексе работаю над IoT‑железками в Городских сервисах. Но сегодня речь пойдёт не о них. Эта история началась с неожиданной находки в новой квартире — с обычной, на первый взгляд, трубки домофона. Кажется: ну трубка и трубка. Но вот что бросилось в глаза: она была подключена по Ethernet. А если есть Ethernet, значит, внутри что‑то с TCP/IP, то есть уже маленький компьютер.

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

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

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