Привет, Хабр. Меня зовут Саша, в прошлый раз я рассказывал сообществу про поиск организаций в Яндексе. В этот раз мы вновь поговорим про поиск, но уже совершенно другого рода. Сегодня расскажем про «Поиск по архивам». Этот проект вырос из моего личного интереса к истокам семьи, но в итоге (хочется верить!) поможет тысячам других таких же пользователей чуть больше узнать о своих корнях.

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

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

Решению этой задачи мы и посвятим историю. А поможет мне с ней Таня @miryable из команды, которая уже много лет развивает в Яндексе технологию оптического распознавания символов (OCR).

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

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

У вас бывало, что открываешь поиск, ищешь что-то по программированию и не находишь ответ? Тогда эта история для вас. 

Меня зовут Алексей Степанов, я руковожу службой исследований машинного обучения поиска Яндекса. Сегодня я расскажу непростую историю. Она про проблему, до решения которой у нас слишком долго не доходили руки. Из поста вы узнаете, почему стандартная метрика качества поиска не учитывала интересы разработчиков и как мы её улучшили. Расскажу про новую нейросеть CS YATI, обученную понимать таких же айтишников, как и мы. Ну и про грабли на нашем пути тоже расскажу, куда без них.

Этот пост основан на моём докладе с Data Fest 2022, но не во всём (мой коллега Максим Хурсанов @Maxim2207 существенно расширил историю).

Высвобождение ресурсов

• Простота. Стажёр или студент, приходя к нам, может уже через неделю написать и отправить в продакшен новый микросервис.
• Надёжность. Многие ошибки, в том числе и связанные с многопоточностью, можно поймать на этапе компиляции. Кроме того, фреймворк даёт подсказки по исправлению проблем.
• Полнота. В userver есть всё необходимое для тестирования, работы с разными базами данных, кеширования, логирования, трейсинга, распределённых блокировок, работы с JSON, BSON, YAML, изменения параметров сервиса на лету и так далее.

Всем привет! Наверняка каждый Android-разработчик хоть раз сталкивался с проблемой скорости сборки своего проекта. После нехороших слов в адрес кодогенерации, покупок более мощного железа, многочисленных попыток распилить проект на небольшие параллельно собираемые модули и прохождений всех стадий торга мы продолжаем искать решение этой проблемы. К счастью, за годы развития и в Gradle, и Android Gradle Plugin (AGP) появилось много полезных штук для ускорения сборки, о которых я расскажу дальше.

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

Я расскажу на примере мобильного Яндекс Браузера. У нас было ~150 Gradle-модулей, ~2 млн LoC на Java/Kotlin, десяток Gradle-плагинов, тысячи строк кода в buildSrc и лёгкая дрожь от вопроса, сколько ещё может переварить билд-система. Не скажу, что это всё было категорически необходимо, но к написанным строчкам кода надо проявлять уважение.