Technotext

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

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

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

Меня зовут Александр Батин, я инженер‑схемотехник. Уже больше трёх лет я работаю в Яндексе в команде, которая занимается разработкой умных экранов и новых продуктов. Отвечаю за проектирование материнских плат (разрабатывал материнскую плату для Станции Дуо Макс), а в последних проектах участвую уже в качестве техлида.

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

— рассмотрим интересные моменты на этапе проектирования,

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

— обратим внимание на сложности, с которыми столкнулась команда разработчиков.

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

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

У Горыныча есть ряд нетривиальных решений, которые сильно отличают его от стандартных USB‑хабов. В нём реализована трансляция USB 3.1 в USB 2.0 для ускорения времени прошивки устройств, установлены контроллеры USB Power Delivery source на каждый порт для питания устройств с различными требованиями к напряжению и мощности, а также 12 независимых COM‑портов для отладки. В итоге к Горынычу можно подключить одновременно 10 мощных устройств — и он спокойно выдержит такую нагрузку.

Всем привет! За полтора года наша команда разработки в YADRO написала с нуля четыре полноценных приложения для операционной системы kvadraOS. Проекты разные по объему, требованиям и связям с системой, но всех их объединяет современный стек (Kotlin + Compose) и чистая архитектура.

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

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

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

Хабр, всем привет! С вами Лиза Акманова, ведущий аналитик ГК «Юзтех».

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

Привет, Хабр! Меня зовут Алексей, я развиваю направление искусственного интеллекта и машинного обучения в ГК Юзтех. В этой статье я расскажу о полезном инструменте для рекрутеров, который реализовала наша ML-команда. Теперь наши HR-специалисты не тратят кучу времени на поиск по фильтрам, а доверяют сервису, который за секунды выполняет поиск по базе из 300 000 кандидатов.

Про исследования и проблемы найма

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

По данным Хантфлоу скрининг резюме опытным рекрутером составляет около 5–10 секунд. Рекрутеру с меньшей осведомленностью понадобится около минуты. Несложно подсчитать, что, если на вакансию получено около 100 резюме, время на первичный отбор занимает от 15 минут до 100 минут. Однако, если рассматривать нестандартные вакансии по разработке узкоспециализированных систем, HR тратит около 10 минут на изучение, а это почти 17 часов на 100 резюме.

Немного о задаче

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

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

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

Сегодня мы расскажем, как исследовали алгоритмы community detection для группировки товаров, с какими проблемами столкнулись и при чём тут матчинг. Статья будет полезна всем, кто работает с большими объемами данных и ищет способы оптимизировать операции с этими данными. Поехали!

Привет, Хабр! На связи команда продуктового матчинга ecom.tech. Наша команда решает задачи поиска, группировки и сопоставления товаров с помощью алгоритмов машинного обучения. Все это необходимо для развития и улучшения бизнес-процессов в компании, а именно быстрого заведения карточек товаров, мониторинга цен на товары и развития ML. В этой статье мы расскажем про доматчинг – сравнение сложных пар товаров, которые отобрали на предыдущем этапе пайплайна, с помощью LLM. Поехали!

Всем привет! 

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

Всем привет, меня зовут Сергей Сибара, я фронтенд-разработчик в ИТ-холдинге Т1. Так как при использовании Feature-Sliced Design (FSD) возникает много вопросов и разные люди понимают её по-разному, я решил написать статью-справочник, раскрывающий некоторые подробности методологии.

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

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

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

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

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

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

Спойлер: это не связано с европейским регламентом по защите данных (GDPR) и правом клиента быть забытым (потребовать от компании удаления всей информации о себе).

Как фулстек разработчику, мне доводилось работать с проектами на совершенно разных технологиях. Как правило, нужно было поправить небольшой баг или сделать небольшую фичу. Для задач такого разряда стек технологий обычно не имеет значения: отладка примерно одинаковая что на JavaScript, что на Haskell, Go или Python.

Написать немного кода мне, в общем-то, никогда не было сложно на любом языке, с которым я работал.

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

Я устал от этого, и придумал, как больше никогда в жизни не устанавливать тулинг вручную.

В этой статье пойдет речь об одной из самых сложных и интересных архитектур — трансформере, лежащей в основе современных моделей от OpenAI и Google DeepMind. И это не научпоп для обывателя с наивным уровнем объяснения, а полноценный учебный материал, который поможет вам понять работу трансформера на фундаментальном уровне без черных ящиков типа TensorFlow и Pytorch.

А для того чтобы лучше вникнуть, давайте напишем настоящий мини-трансформер на процедурном Python и обучим его!

Данный материал можно изучать в разных режимах:

* Как объяснение архитектуры для общего представления;

* Как полноценный гайд с чтением кода и самостоятельной практикой;

* Как основу для собственных экспериментов.

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

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

Для закрепления материала, выполните Домашнее задание, которое ждет вас в конце статьи.

Фильтра Калмана много не бывает! По этой теме издано несколько книг, опубликовано большое количество статей, в том числе на Хабре. Разработанный в 1960-х годах алгоритм оценки состояния динамических систем по сегодняшний день считается одним из лучших, получает все более широкое применение в различных технических системах: от радиолокации до электрокардиографии.

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

Все модели, которые я буду использовать и описывать, выполнены на языке Matlab – среде, изначально созданной для работы с матрицами. Гарантированно они будут работать на версии R2016b и выше.

При создании интерфейса важно проверить, как он реально выглядит. Часто это проверяют все участники процесса — от разработчиков до менеджеров. И для автоматизации и упрощения процесса визуального тестирования приложения есть специальный инструмент — golden‑тесты. Это методология тестирования, в которой текущий UI сравнивается с предварительно сгенерированным «золотым» эталоном. Если вы уже слышали про скриншот‑тесты — это примерно то же самое, но есть нюансы.

Меня зовут Даниил Липаткин, я тимлид в команде разработки курьерского приложения Яндекс Доставки. В этой статье:

— Мы познакомимся с методологией, рассмотрим её преимущества и недостатки, а также когда её стоит и не стоит применять.

— Напишем базовый Golden‑тест на примере стандартных инструментов библиотеки flutter_test.

— Рассмотрим пакет alchemist, который решает проблему платформозависимости flutter_test.

— Получим прикладные рекомендации по применению тестов и настройке IDE и CI.

Привет! Меня зовут Валерий Ильин, я руководитель сектора разработки мобильных роботов в Яндекс Роботикс. До недавнего времени в нашей линейке роботов отдельно жили мобильные роботы (робот‑инвентаризатор и робот‑тотоносец) и проекты на основе роборук (депалетизатор, пикер). Решения закрывали две основные операции на складе: перемещение товара и его отбор, но по отдельности. Идея объединить их и собрать робота, который закрывает обе операции, зрела в мыслях уже давно. Но прежде чем задумка воплотится в жизнь, ей нужно было созреть, набраться сил, а нам — опыта.

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

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

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

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

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

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