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

Привет, Хабр! На связи команда Рунити под руководством Антона Ивахненко: Дмитрий Виноградов, руководитель направления разработки, менеджер продукта Карина Калеева, ML-инженер Александр Михеев и тех.лид Владимир Устьянцев. 

В этой статье мы рассказываем про RAG-ассистента, который скоро у нас появится. Этот ассистент ищет по Confluence и GitLab одновременно, уважает права доступа и не отправляет корпоративные данные наружу. Но обо всём по порядку. 

Здравствуйте, меня зовут Дмитрий Карловский, и я пилил веб-компоненты, когда их ещё не придумали, делал полноценные компоненты на AngularJS, когда там ещё были только директивы, и разработал компоненто-ориентированный фреймворк $mol с инверсией контроля и статической типизацией, когда это ещё не было мейнстримом. Короче, я немного в теме. И сейчас я расскажу вам, почему мы сразу отказались от Web Components и почему у них нет никаких перспектив.

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

Можно ли делать RAG на MacStudio M3 Ultra? CAG - убийца RAG? Самый лучший RAG от OpenAI и Grok?

Ответы на эти вопросы мы узнали во время участия в соревновании Agentic RAG Legal Challenge. Стоит отметить хорошую организацию соревнования и продуманные метрики. Более 300 команд со всего мира.

Недавно я посмотрел большое интервью с основателем и руководителем Revolut - компании, которую можно описать как «Т-банк в мировом масштабе». Revolut работает в 40 странах, у неё нет физических офисов для клиентов, но по своей сути это мощная ИТ-компания с банковской лицензией.

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

Как бесконтрольное использование ИИ для генерации кода превращает сеньоров в уборщиков чужого кода: разбираем метрики, которые выявляют проблему, и три практики, позволяющие встроить управление ИИ-долгом в процесс разработки.

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

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

Несколько лет назад я делал внутренние доклады по PostgreSQL для команды — разбирали транзакции, блокировки и уровни изоляции на живых примерах. Потом ушёл на другой стек, а недавно вернулся к PostgreSQL и пересмотрел свои записи. Материал до сих пор актуален — базовые концепции не изменились. В статье: почему UPDATE из двух сессий «висит», чем Read Committed отличается от Repeatable Read на практике, почему Serializable падает даже без логического конфликта, и как VACUUM на самом деле работает с мёртвыми строками. Всё с SQL-примерами, которые можно повторить.

Системные программисты годами живут в вынужденном компромиссе. Когда вы пишете ОС, гипервизор или драйвер ядра, у вас два пути. Первый — чистый ассемблер (NASM/GAS), где вы имеете 100% контроль над железом, но теряете систему типов и тонете в ручном управлении памятью. Второй — использование inline asm вставок в C/C++, которые превращают ваш код в строковый «черный ящик», ломают пайплайн оптимизатора и могут взорваться в рантайме из-за ошибки в одной букве (Fragile Constraints).

Мы решили исправить эту историческую несправедливость.

Спустя месяцы безумной разработки мы представляем AsmX Raptor Engine — первый в мире конвейер компиляции, где высокоуровневая типизация и машинные инструкции живут в едином, неразрывном абстрактном синтаксическом дереве (AST).

В этой статье мы заглянем под капот нового движка и разберем:

Frontend-Backend Split: Как Pratt Parser (алгоритм сортировочной станции) и логика lookahead навсегда избавили нас от костылей C++.

Reference Collapsing и CV-квалификаторы: Почему наш тайпчекер ударит вас по рукам, если вы попытаетесь перезаписать const или неправильно примените reinterpret_cast<T>.

Kernel-Mode Orchestration: Как мы научили компилятор быть Version-Agnostic и собирать модули ядра (.ko) под любую версию Linux на лету через вытягивание метаданных из dmesg.

Operand Bridge: Трансляция абстракций в интеллектуальные инструкции железа.

Мы не пытаемся заменить C++. Мы возвращаем инженерам абсолютный контроль над каждым байтом, не лишая их мощи статического анализа. Добро пожаловать в манифест эффективности AsmX Raptor.

По данным Financial Times, AI-агент Amazon получил operator-level доступ к продакшену - и выбрал «удалить окружение» как оптимальный способ починить баг. 13 часов аутейджа. Собрал хронологию трёх инцидентов марта 2026 и разбираюсь, что именно пошло не так на уровне permissions, review gates и CI/CD.

У Figma давно был MCP-сервер. Работал он в режиме read-only, и сценарий выглядел так: дизайнер (или вы сами) рисовали макеты руками, потом разработчик скармливал агенту ссылку на файл в Figma, агент разбирал его по слоям, вытаскивал структуру, цвета, отступы, шрифты, и на выходе генерил код, который более-менее соответствовал тому, что было нарисовано.

Вчера Figma обновила свой MCP-сервер, и теперь она умеет не только читать, но и рисовать дизайн. Причём речь не про "нарисуй мне кнопку" или "сделай один экран". Агент может собрать полноценный лендинг целиком или выстроить UX-флоу на несколько экранов. И самое ценное: он делает это в рамках вашей дизайн-системы. Берёт ваши компоненты, ваши токены, ваши стили и собирает из них макет, который выглядит как часть вашего продукта, а не как что-то из генератора 2015 года.

До этого обновления все попытки генерировать дизайн через AI выглядели так себе. Результат глючил, визуал был устаревший, компоненты не из вашего UI Kit, а откуда-то из дефолтных библиотек. Пользоваться этим в проде было нельзя, максимум для наброска. Сейчас ситуация другая. Вы подключаете свою дизайн-систему (UI Kit), и агент собирает макеты, которые реально пригодны для использования.
Я считаю для быстрых экспериментов и проверки гипотез это гигантский шаг вперёд.

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

Язык проектировался простым, лёгким в освоении, готовым для написания сервисов с первого дня. Он мог бы таким и остаться, если бы не одна проблема. Проблема отбора.

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

Явно ставилась задача — сделать язык достаточно простым, но не настолько, чтобы собеседование мог пройти любой новичок.

Представьте: команда взялась за инициативу, расписала задачи по спринтам, завела тикеты в Jira — и ушла пилить. Через квартал выясняется, что не успели. Или успели, но никому не нужно. Или руководство неожиданно "не поддержало".

Большинство провалов проектов и инициатив — предсказуемы. Их можно увидеть заранее, если знать, куда смотреть.

Для этого существует DICE-фреймворк от Boston Consulting Group. Это методика оценки вероятности успеха (или провала) проекта до старта.

В данной статье будем реализовывать оптимальный фильтр Калмана с помощью среды моделирования Engee.

Структура навигационной системы будет представлять собой комбинацию бесплатформенной навигационной системы + спутниковой навигационной системы (СНС).

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

Если вы хоть раз гуглили «как настроить Obsidian для задач» - вы знаете, чем это заканчивается. Три часа в YouTube, пять вкладок с гайдами, десяток установленных плагинов и... система не работает. Потому что это чужая система.

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

Если тема управления знаниями и задачами в Obsidian вам близка - заглядывайте в мой тг-канал, там я разбираю подобные вещи регулярно.

Механизмы переваривания и усвоения пищи для ума удивительным образом похожи на переваривание и усвоение пищи для тела.

Неглупые вроде бы люди понимают, почему спортсмены едят часто, но по‑немногу, и тем не менее почему‑то многие пытаются сидеть за учебником английского по два часа подряд. Годовалый ребёнок не может переваривать еду, которую ест взрослый. К тому же объём еды, которую может усвоить ребёнок, несопоставим с объёмом еды, которую переварит молодой стокилограммовый боксёр. Как же увеличить мощность «интеллектуального желудка»? В некоторых программах обучения рассматриваются, например, такие темы как «физический и психический тонус, степень бодрствования и изучение новой информации». Конечно, есть врождённые индивидуальные ограничения. Но мощность ума в значительной степени развить можно различными регулярно выполняемыми сильнодействующими (а значит, к сожалению, и опасными без присмотра инструктора) и довольно сложными упражнениями на протяжении нескольких лет: наработкой сосредоточения внимания, его распределения, деконцентрации, специальными дыхательными упражнениями и пр.

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

На собеседованиях мы слышим или говорим сами, что поиск в массиве медленнее, чем в хеш-таблице. Кто-то даже вспоминает, что поиск в массиве имеет линейную сложность или O(n), а в хеш-таблице — константную O(1). Но работает ли это на практике? Что, если есть ситуации, когда поиск в массиве оказывается быстрее? Давайте не будем торопиться с выводами.

Научный и технологический прогресс были бы невозможны без двух основополагающий качеств человека — лени и любопытства. Второе особенно проявляется в исследованиях неизведанных доселе территорий, будь то поиски прохода через Арктику или далеких планет. Независимо от пункта назначения, подготовка к экспедиции имеет решающее значение для успеха миссии и выживания ее участников. Говоря о длительном пребывании за пределами нашей планеты, например на Луне, одним из важнейших ресурсов будет пища. Конечно, можно собрать необходимый провиант заранее, но его транспортировка и хранение сопряжены с рядом сложностей в и без того сложном путешествии. Для более длительных экспедиций может потребоваться выращивать еду на месте, но почва Луны не пригодна для выращивания растений, по крайней мере была раньше. Ученые из Техасского университета в Остине (США) смогли модифицировать почву Луны, используя специальные удобрения и грибок, что позволило им вырастить урожай нута. Что именно потребовалось для изменения лунной почвы, как протекал процесс роста нута, и насколько урожайным был результат? Ответы на эти вопросы мы найдем в докладе ученых.