Kurgan-Telecom Ru | Информационные технологии

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

Крошечный аккумулятор, мало памяти, чип с жёсткими ограничениями по тактовой частоте, да ещё и с кое‑какими неожиданным сюрпризами на уровне SDK. Всё это потребовало переосмыслить с нуля архитектуру споттера (компонента, который распознаёт обращение «Алиса» прямо на устройстве). 

Меня зовут Григорий Афанасенко, я работаю в команде голосовых технологий Яндекса. Сегодня мы запустили Яндекс Дропс — первое носимое ИИ‑устройство с Алисой AI. В этой статье я расскажу, как мы адаптировали споттер под железо наушников, какие решения пришлось принять, где мы наступили на грабли и что планируем делать дальше. 

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

В этом кейсе расскажем о роботизации распределительного центра (РЦ) «Новая Рига» X5 –  крупнейшем логистическом объекте торговой сети «Пятёрочка». Проект стал одним из самых масштабных внедрений мобильной робототехники в российском ритейле: на объекте был развернут комплекс из более чем 80 роботизированных устройств под управлением единой системы WCS Automacon.

ИИ не всегда ошибается в коде. Часто проблема появляется раньше, в выборе уровня решения.

На трех примерах из веб-разработки показываю, почему рабочий ответ ИИ еще не значит, что его стоит брать в проект: импорт товаров из Excel, мобильное меню на MODX и компонент для Schema.org-разметки.

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

Убеждение в том, что компьютеры произведут революцию в образовании, укоренилось задолго до эры микрокомпьютеров; в 1960-е годы оно быстро распространилось по американским университетам. Для этого созрели как политические, так и технические условия: запуск Советским Союзом «Спутника» в 1957 году и программы Линдона Джонсона «Великое общество» послужили катализаторами для притока огромных объёмов федеральных средств в сферу образования и, в частности, в научные исследования в этой области. Между тем, технология разделения времени, позволявшая нескольким пользователям одновременно получать доступ к одному большому и дорогому компьютеру, сделала возможным одновременное обучение целых классов студентов с помощью компьютера (хотя это всё ещё было очень дорого, учитывая стоимость компьютеров в то время).

Открываешь чужой код на Python, а там — Java. Абстрактные базовые классы в местах, где хватило бы простой функции, фабрики фабрик и нагромождение паттернов, усложняющих чтение бизнес-логики. Знакомая картина?

Многие разработчики механически переносят архитектурные привычки из строго типизированных языков в Python, создавая переусложненный неидиоматичный код. В этой статье мы возьмем классические правила SOLID и переведем их на язык динамической типизации (Pythonic way). Разберем на реальных примерах, где принципы спасают проект, а где слепое следование им скатывается в карго-культ.

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

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

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

К маю 2026 года средний сбор аудитории в нашей системе занимал 2 часа 50 минут. Проблема состояла из двух частей. Первая: 96.5% этого времени процесс стоял в очереди. Вторая: даже добравшись до исполнения, расчёт занимал 6 минут — десятки задач внутри DAG выполнялись над множествами в миллионы строк, и основным инструментом были JOIN.

Мы последовательно устранили обе проблемы — 20 изменений, разбитых на шесть этапов. Ниже описан каждый шаг и итоговый результат.

Все числа «до» и «после» получены одним и тем же SQL‑запросом по Postgres — это воспроизводимый замер.

Домен обобщён: конкретная компания не имеет значения. Это платформа, которая по булевым условиям («траты > 5000 ₽ за последние 3 месяца» И «покупки в категории Рестораны») собирает множество клиентских идентификаторов из 10-миллионной базы и доставляет его во внешние системы.

На связи Сергей Скирдин, технический директор ИТ-интегратора «Белый код». Два года я изучаю российский рынок шин данных. За это время удалось связаться с более 40 вендорами, с половиной из них мы встретились, чтобы написать обзор. Каждый такой материал — это вопросы разработчикам, демонстрация решения, изучение документации. Недавно я объединил все обзоры в один большой, чтобы было удобнее знакомиться с разными продуктами. Рассказываю, в чем идея и что у меня получилось сделать за 2 года.

iDig3Dprinting

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

Первым побуждением в этом процессе является «залить наглухо, на 100% — и гори оно всё…» (грешен, сам практикую :-B). 

Однако, есть и гораздо более интересные варианты, которые позволяют добиться достаточно впечатляющих результатов…

Протокол CalDAV существует с 2007 года (RFC 4791), и за это время он стал стандартом де-факто для синхронизации календарей. Казалось бы, стандарт — значит, всё одинаково. На практике же каждый крупный провайдер реализовал его по-своему, зачастую отходя от стандарта.

Для меня всё началось с простой задачи: автоматизировать управление своими календарями. Один pet-проект, один провайдер — ничего сложного. Но когда я решил попробовать поддержать второй, третий, четвёртый — оказалось, что CalDAV у каждого свой. В этой статье я расскажу, с чем вы столкнётесь, если решите написать клиент, работающий одновременно с Google, Apple, Яндексом и Mail.ru.

Интернет полон историй безупречного успеха: «Мы взяли модный фреймворк, переписали систему с нуля, и всё стало летать». Но реальный мир корпоративной разработки – это legacy. Это системы вроде Redmine, которые живут десятилетиями, хранят в себе терабайты критических данных, и чья миграция обойдется бизнесу слишком дорого.

Мы в команде ArcFront решили, что хватит терпеть интерфейсы из 2006 года. Вместо того чтобы убегать на платные облачные трекеры, мы совершили хирургическую инъекцию. Мы внедрили молниеносный React SPA прямо в ядро старого Ruby-монолита. Без микросервисов. Без CORS.

Рассказываем, как мы заставили старого пса выучить новые трюки: от архитектуры инъекции и парсинга Textile до психологии интерфейсов и нашего официального перехода на бизнес-модель Open Core.

Что делать, если автоматизация дома уже началась, деньги потрачены, кабели проложены, а подрядчик перестал отвечать на звонки?

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

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

Я руковожу отделом дизайна в ЛАНИТ. В этой статье расскажу, как давать обратную связь дизайнеру, чтобы макеты становились лучше, а командное взаимодействие – комфортнее. 

В последние годы недорогие ноутбуки часто уступали более дорогим моделям по качеству корпуса, автономности и экранам. Intel считает, что часть этих проблем связана не только с процессорами, но и с самим подходом к разработке устройств. Поэтому вместе с процессорами Wildcat Lake компания представила Project Firefly — набор стандартизированных решений для производителей ноутбуков. 

Проект анонсировали вместе с запуском процессоров Core Series 3 (кодовое имя Wildcat Lake) в мае 2026 года в Китае. Что за инициатива? Если кратко, то вместо того чтобы просто выпустить новые чипы и оставить производителям самим решать, как собрать из них недорогой ноутбук, компания предложила готовый набор стандартизированных решений. Цель — использовать опыт массового производства смартфонов, чтобы снизить себестоимость и ускорить вывод устройств на рынок. Давайте разберем подробности. 

Я наткнулся на подход к функциональным тестам, который меня по-настоящему удивил. Тесты в нём вообще не знают, что внутри Spring: стучатся в реально поднятый сервис по HTTP, как обычный клиент, гоняются параллельно и проходят за секунды. Я разбирал это на код-ревью и сначала прифигел, а потом не стал переходить на него сам, но кое-что забрал себе. В статье сравниваю оба подхода, разбираюсь где какой уместен, и показываю три вещи, которые подсмотрел и притащил в свой Spring

Опубликован Flatpak 1.18.0 — новый стабильный выпуск системы для сборки, распространения и запуска изолированных Linux-приложений. Flatpak позволяет разработчикам выпускать одно приложение для разных дистрибутивов, поставлять собственные зависимости и запускать программы в предсказуемой среде. Общее описание проекта приведено на сайте flatpak.org, а список изменений опубликован в официальном релизе Flatpak 1.18.0 на GitHub. Дополнительный краткий разбор выпуска опубликован Linuxiac в заметке Flatpak 1.18 Released with AMD Compute Interface Support.

Основные изменения Flatpak 1.18.0:

( читать дальше... )

 flatpak

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

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

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

Когда я отвечал за бизнес-юнит МСБ в Кайтене, мне нужно было посчитать юнит-экономику B2B SaaS с длинным циклом сделки. Задача казалась простой — поделить LTV на CAC и сравнить с порогом. Я неоднократно так делал для B2C для сделок короче месяца.

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