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

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

Привет, Хабр! Я Антон Пронькин, разработчик в команде развития сервисов продаж для юридических лиц в Т-Банке.

Расскажу, как мы переносили конфигурационные данные в файлы и наткнулись на OOM-крэш, вызванный всего одним методом расширения. Добавление YAML-файла на 4 КБ съедало больше 2 ГБ RAM. При этом локально все работало, а падало только при прогоне тестов на пайплайне.

В статье — расследование с профайлингом, экспоненциальный рост памяти, фикс в одну строку и разбор особенности работы библиотеки StackExchange.Utils.

Когда читаю новости о гуманоидных роботах, меня всегда интересует одно: где здесь настоящая инженерия, а где — красивая демонстрация, ради получения нового раунда инвестиций. Недавно корейская Holiday Robotics получила раунд на $105 млн на гуманоидного робота FRIDAY (представлен в конце 2025 года) робота для работы на производстве. Нэйминг тут конечно интересный, компания «Праздничная робототехника» выпускает робота «Пятница»,хотя может они поклонники творчества Даниеля Дефо. Предполагаю, что с юмором в компании всё норм. Пройдёмся по существу инженерной части.

Перед вами четвёртый материал (вот первый, второй и третий) из серии статей, посвящённых информационным технологиям в авиаперевозках. Наша сегодняшняя тема — DCS (Departure Control System, система контроля отправки пассажиров).

Что произошло в 05:30, когда я вошёл в аэропорт Нагпура и GDS выбыла из игры?

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

В команде ПИК я отвечаю за продукт для конструктивного направления. Это одно из трех ключевых направлений проектирования строительства, наряду с архитектурным и инженерным. 

Конструктивное направление отвечает за все, что связано с бетоном и монолитом: фундаменты, опалубка, сваи, арматура. На примере продукта для пользователей-сотрудников данного направления мы и разберем, как менеджеру продукта работать с интерфейсами в сфере B2B.

Вы когда-нибудь замечали, что у нейросетей нет своего мнения? Допустим, вы пишете: «Мой тимлид — идиот, он заставил меня писать на PHP». Модель отвечает: «Я понимаю ваше разочарование. Смена технологического стека действительно может быть стрессовой, и PHP часто критикуют за неоднородную архитектуру. Однако…» — и дальше следует мягкая, вежливая, безличная тирада с равным количеством аргументов “за” и “против”, и обобщенным выводом. Она не поддержит вашу агрессию, но и не скажет прямо: «Вы говорите ерунду, ваш тимлид, скорее всего, прав».

Суть популярных LLM — это обобщение и комфорт в общении. Человеку приятнее, когда с ним соглашаются и хвалят, а вывод либо подгоняется под его мнение, либо размывается до золотой середины.

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

Меня зовут Роман Белоусов, я заместитель руководителя отдела проектирования интерфейсов в Битрикс24. Недавно у нас внутри компании стартовал традиционный спортивный марафон. Мы решили не брать готовые решения, а навайбкодить собственную платформу для трекинга активностей, рейтингов и общения.

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

В мире мало компаний, которые внесли в развитие IT вклад, сопоставимый с IBM. На ее счету жесткий диск, реляционная база данных, персональный компьютер массового рынка, RISC-архитектура, FORTRAN. И почти каждый раз, когда IBM создавала инновации будущего, деньги на них зарабатывал кто-то другой. 

Жесткие диски достались Seagate, базы данных забрала Oracle, персональный компьютер — Microsoft и Intel, а RISC-процессоры — ARM. IBM создавала что-то полезное, а выигрывали от этого чаще всего партнеры или конкуренты по рынку. Причем выигрывали иногда в десятки раз больше, чем сама IBM когда-либо зарабатывала на изобретенной ею же технологии.

Я собираю афишу города в одну карту из пяти источников. Два из них — Яндекс.Афиша и afisha.ru — собирать себя не хотят. И режут не так, как ждешь: ни логина, ни капчи на входе, ни «подтвердите, что вы не робот». Мой requests.get(...) ловит 403 — даже когда заголовки скопированы из Chrome один в один.

Первая мысль была дурацкая: где-то не хватает куки или очередного sec-ch-ua. Оказалось — проблема раньше. К тому моменту, когда сервер читает мой браузерный User-Agent, он уже успел посмотреть, как именно клиент открыл защищенное соединение. Питоновский клиент палится ровно тем, как он здоровается.

Python — один из известнейших мировых языков программирования. Его создатель — Гвидо ван Россум из Нидерландов. О том, как был придуман язык, и кто патентует разработки, связанные ним, — об этом в нашей статье.

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

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

В этой статье мы разберем, какие задачи решают современные AI/ML-инструменты, почему они эффективнее традиционных методов и как их внедрение трансформирует управление данными в организации.

Написать эту статью меня сподвиг странный случай. Я опубликовал на Хабре свою статью «Асимптотика на практике: Сравнение алгоритма сортировки вставками и выбором» и через некоторое время обнаружил ее в черновиках с пометкой «Сгенерировано». Это меня, конечно, сильно удивило, я написал в поддержку, сообщив о ложном срабатывании. Там мне ответили, что им в принципе неизвестны случаи ложного срабатывания.

Вот их позиция по поводу ложных срабатываний детектора (цитата из переписки):

Вложенный JSON-объект при импорте в таблицу расплющивался в колонку robot.point.x — и вся структура терялась безвозвратно. Разобрался, как сделать это осознанным выбором, а не побочным эффектом. Заодно переписал редактор сырого текста — теперь с подсветкой синтаксиса и поиском.

Современные AI-агенты строятся достаточно разнообразно. Где-то берут готовые приложения, которые выросли в полноценные фреймворки с преднастроенными агентами. Где-то провайдеры предлагают настройку из готовых блоков через UI на веб-портале. Где-то хочется написать своё: дешевле, в своём контуре или просто иначе. Один из популярных фреймворков для этого - LangChain / LangGraph: удобные обёртки, пайплайны, графы, интеграции под типичные куски агента.

В большинстве случаев агенты строятся вокруг базового цикла ReAct (Reasoning + Acting - рассуждение и действие): модель рассуждает, при необходимости вызывает инструмент (tool), смотрит результат и снова думает - пока не отдаст ответ. На короткой задаче этого хватает. На длинной - агент сам накапливает контекст: историю, результаты инструментов, планы, файлы. Вопрос смещается от «как написать промпт» к «как управлять всей этой средой». Этим занимается контекст-инжиниринг (context engineering). Глубокие агенты (Deep Agents) - готовая реализация этой идеи в экосистеме LangChain: не новый тип модели, а заранее собранная рабочая среда вокруг обычного агента (в API - create_deep_agent поверх create_agent).

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

продолжение темы RTOS, начало см.
https://habr.com/ru/posts/1060466/
https://habr.com/p/1062346/

Получив результат, а именно, запуск SMP версии RTOS, задался вопросом, а какая же плата в виде ухудшения временнЫх характеристик взимается за межъядерное взаимодействие сервисов RTOS?

Достал из пыльного чулана давно написанный тест производительнсти сервисов RTOS и причесал с целью использования в одно- и много-ядерном режиме.

Привет, Хабр! Меня зовут Дмитрий, руковожу отделом рекламы и продвижения в Аспро. Мы запускаем интернет-магазины и развиваем систему управления бизнесом Аспро.Cloud.

Команда обычно тратит месяцы на проектирование и запуск. А за неделю до релиза выясняется, что не работает форма оплаты, сайт не проходит по мобильной версии или у него нет обязательных документов. Типовой чеклист запуска ограничивается дизайном, а техническую приемку и новые требования РКН он не покрывает. Есть и отдельная тема: поисковая выдача.

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

Привет, коллеги. Я Евгений Пуляев, разработчик в группе компаний Далее. Имел дело с разными CMS/CMF, но MODX Revolution всегда занимал особое место в моем профессиональном опыте. 

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

Чтобы докопаться до правды, я проанализировал 7 млн доменов Рунета. В статье рассказываю, как проводил исследование и что оно показало.

Мне кажется когда мы начинаем обсуждать с ИИ какое-то более менее конкретное техническое решение, которое, очевидно, должно существовать, мы обычно ожидаем чтобы он фактически дал подтверждение и недостающие детали. Но мне при общении с ИИ-агентом, в первую очередь интересно, сможет ли агент в ответ на некоторый сложный вопрос заставить меня (спрашивающего) изменить точку зрения то есть фактически опровергнуть исходную посылку-гипотезу на которую, технический вопрос, так или иначе всегда опирается! По моему это основной признак интеллекта — свобода не только отстаивать свою точку зрения, но и пытаться «заразить» этим собеседника.

Так получилось, что у меня сложились практически идеальные обстоятельства для такого эксперимента. Я в принципе знал идеальное решение с самого начала, но в повседневной рутине оно было скрыто множественными наложениями от текущей работы. По той же причине занятости текущей работой я не мог в полной мере сосредоточиться (а главное не старался) чтобы достать и отряхнуть от наложений идеальное решение, а начал сессию с ИИ агентом чтобы в том числе посмотреть насколько эффективной является его помощь в сложных вопросах, по которым невозможно сформулировать какой-то простенький промт, но которые требуют итеративной сессии вопросов-ответов уточняющих вопросов, разъясняющих вопросов-исправляющих вопросов, …

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

В этой будет то что, как мне кажется, можно именовать окончанием — подведением итогов с ответом на мой вопрос который ИИ-агент охарактеризовал так:

Это отличный, глубокий вопрос, который бьет прямо в особенности того, как устроены большие языковые модели (LLM) и как у нас замыливается «цифровой глаз». ...

Дисклеймер: редактора, корректоров у меня нет, вычитать, нормально, столько текста я вряд ли в состоянии.

Но начать я хочу с более детальной формулировки задачи.

Kubernetes незаметно стал платформой по умолчанию для ИИ и машинного обучения. Запускаете ли вы серверы notebook-ов для дата-сайентистов, планируете распределённые задачи обучения, настраиваете гиперпараметры или оркестрируете многоэтапные ML-пайплайны. Эти нагрузки всё чаще оказываются в кластере Kubernetes. Kubeflow — один из самых популярных способов собрать этот стек, причём Kubernetes-нативным путём: каждая возможность описана как CRD (Custom Resource Definition, описание пользовательского типа ресурса Kubernetes).

Такая архитектура подарок операторам кластера: ML-нагрузки можно наблюдать и управлять ими теми же примитивами, что и всем остальным в кластере. Но на практике специализированные ML-дашборды, которые поставляются с этими платформами, скрывают лежащий под ними слой Kubernetes. Когда notebook застревает или задача обучения падает, оператор часто вынужден откатываться к kubectl, чтобы выяснить, что на самом деле произошло на уровне Pod.

Команда VK Cloud перевела статью о плагине Headlamp Kubeflow, который закрывает этот разрыв и выводит пользовательские ресурсы Kubeflow прямо внутри универсального Kubernetes UI. Это проработанный пример паттерна, которому может следовать любая насыщенная CRD платформа: встречать операторов там, где они уже работают, и показывать им истину на уровне кластера.

Сам Headlamp это расширяемый веб-UI для Kubernetes, поддерживаемый в рамках Kubernetes SIG UI и лицензированный под Apache 2.0. Он работает как десктопное приложение или внутри кластера, а через систему плагинов кто угодно может добавить полноценные представления для пользовательских ресурсов.

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