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

Привет, Хабр! На связи Данила Трусов, директор продукта «Инферит ИТМен».

Конец лета для многих ИТ-команд — сигнал к началу горячего сезона. Впереди осенние закупки, аудиты и закрытие года, а значит, пора разбираться, что происходит в инфраструктуре.

Сведения об ИТ-активах редко находятся в одном месте: чаще они распределены между несколькими источниками данных, учетными системами, локальными таблицами в Excel. К моменту аудита или закупки их приходится собирать и проверять, и чем крупнее ИТ-инфраструктура, тем это труднее.

Поэтому мы запустили акцию «Яблочный Спас»: получите сертификат на скидку 30% на лицензии «Инферит ИТМен» на сайте и успейте применить его до 31 декабря 2026 года.

Когда я начал работать с CH32V203G6U6 и обнаружил, что там есть 64-битный аппаратный таймер, то подумал: ух, это же отлично, раз таймер аппаратный, то и о чтении/записи заботится сам микроконтроллер. И какое-то время это не вызывало вопросов. А потом…

Некоторые банки и государственные сервисы используют TLS-цепочки, которые заканчиваются корнем Russian Trusted Root CA. Яндекс Браузер и Атом умеют работать с такими цепочками. Chrome для Android показывает NET::ERR_CERT_AUTHORITY_INVALID, потому что этого корня нет в хранилище Chromium.

Я пользуюсь Chrome и не хотел заводить второй браузер для нескольких сайтов. Поэтому добавил корень в Chromium, ограничил его зонами .ru и .рф и собрал отдельный APK. Проект получил название Ruthenium.

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

Но у такого замера есть неприятное слепое пятно. Можно аккуратно сохранить 99% выдачи исходного эмбеддера и все равно плохо находить нужные документы на своем домене. Внешний бенчмарк, даже сильный, этого не гарантирует. BEIR как раз был создан, чтобы показать, насколько результаты retrieval меняются между разными задачами и доменами; один усредненный скор там не заменяет проверку на собственных данных.

Нужен свой eval set. И тут обычно возникает ложная развилка:

Вы уже брали когнитивный долг

Представьте, что вы руководите проектом. Аналитик Вася присылает двадцать слайдов, которые сегодня (а на самом деле вчера) надо показать клиенту. Общая логика вроде ОК, ключевые цифры разумные. На 17-м слайде есть результаты расчета, на проверку которого, по-хорошему, уйдет день. Вася говорит, что все проверил.
Можно попытаться перенести встречу. А можно решить: достаточно, Вася выглядит адекватным, риск небольшой, идем к клиенту.
Если вы были в похожей ситуации – вы уже брали когнитивный долг.
И никакого искусственного интеллекта для этого не требовалось.

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

Начальник не повторяет все вычисления сотрудника. Архитектор не читает каждую строчку каждого сервиса. Главный редактор не перепроверяет каждый факт так, как это делал автор. Партнер консалтинговой фирмы не строит своими руками каждую модель, которую показывает клиенту.
Более того, если заставить его все это делать, организация перестанет иметь экономический смысл.
Поэтому вопрос — не «есть ли у нас когнитивный долг?»
А два других: сколько его у нас и достаточно ли мы контролируем риск? 

Инструмент: C4 QuietGridLabs. Можно открыть демо без авторизации: проект будет храниться локально в браузере.

Иногда архитектура «есть» — но пользоваться ею невозможно.

На доске лежит схема сервисов. В Confluence живёт описание. Где-то рядом — sequence-диаграмма, которую никто не открывал с прошлого года. ER-модель хранится в другом инструменте. А когда на ревью возникает простой вопрос «какой endpoint обслуживает этот путь?», команда начинает собирать ответ из памяти, догадок, выдумок, ссылок и исходников.

Я больше 15 лет работаю в ИТ, из них около десяти занимаюсь проектированием и системным дизайном. За это время перепробовал немало: Sparx, ArchiMate, Structurizr, Confluence, whiteboard-сервисы. Я не считаю их плохими — у каждого есть свой сценарий и своя аудитория. Но лично у меня постоянно оставалось ощущение разрыва: диаграмма была отдельно, документация отдельно, а живой контекст системы — в голове у людей.

В какой-то момент моими рабочими спасателями стали whiteboard и VS Code, а позже Cursor. В них можно быстро собрать мысль, оставить немного полезного творческого беспорядка и двигаться дальше. Но они не решали главную проблему: хотелось, чтобы система, её связи, сценарии и документация были одной навигационной моделью.

Так появился C4 QuietGridLabs. Это мой экспериментальный редактор, где C4-модель — это каркас проекта. К элементам можно прикреплять документацию, sequence-диаграммы, ER-диаграммы и описание API, а по связям — переходить от общего ландшафта к конкретным участникам взаимодействия.

Рассказываем, как одна система из камер, датчиков и нейросетей закрыла сразу три задачи стройки: охрану труда, учет транспорта и контроль сроков.

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

Хочу рассказать про случай, где в одном стартапе мы искали причину две недели, но при этом мониторинг всё это время показывал, что всё в порядке, и формально он был прав.

Добрый день, я хотел бы поднять крайне недооценённую среди PHP-разработчиков тему e2e-тестов, затронуть бизнес-важность таких тестов, техническую часть и почему их никто не пишет.

Сделай сам — покажи другим, как надо. На старте сезона DIY Лемана Тех и Хабр пришли с таким запросом к сообществу авторов, и они не подвели. В рамках сезона вышло множество статей о самых разнообразных проектах, сочетающих работу с железом и софтом. Участники соревновались в том, кто лучше всех владеет отвёрткой, 3D‑принтером, различными языками программирования, у кого самая необычная идея и кто способен максимально хардкорно её воплотить.

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

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

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

Теперь Meta открыла Astryx — дизайн-систему, построенную на React и StyleX. На первый взгляд это выглядит как релиз большой библиотеки: больше 170 компонентов, темы, тёмный режим, шаблоны, CLI, всё как мы любим. Но количество компонентов здесь не самое интересное. Astryx стоит рассматривать как следующий шаг после StyleX: если StyleX делает предсказуемыми стили, то Astryx пытается сделать предсказуемой работу с интерфейсом целиком — и для человека, и для AI-агента.

Привет, Хабр! Представьте ситуацию в интернет-магазине. Клиент звонит и пишет в поддержку, так как получил поврежденный заказ. При этом он уже откладывал повторную покупку из-за долгой доставки в прошлый раз и не дописал отзыв, который хотел оставить неделю назад. Человек на грани ухода к конкурентам. Что увидит типичный оператор поддержки? Да просто текущее обращение. Он оформит возврат, закроет тикет — и на этом как бы все. Остальные сигналы останутся незамеченными им. В противовес ему, агентная система видит всю картину, ловит паттерны и закрывает боли клиента: оформляет возврат, предлагает промокод на следующую покупку, устраняет причину недовольства. Это рабочая модель, которую уже описывают аналитики McKinsey в свежем отчете о перестройке клиентского опыта в эпоху агентского ИИ.

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

Битва уже идёт, даже если ты этого не замечаешь. Более того, AI уже побеждает!

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

Как вам название? Звучит интригующе? Нет, это не кликбейт. Это моя реальная история.

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

Начну я свою историю с начала. Т. е. со школы. Детский сад, так уж и быть, упущу ;-)

Приветствуем, Хабр.

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

Когда начинаешь выбирать оперативную память, сразу бросаются в глаза две главные цифры. Производители даже в маркировку обычно выносят тип-частоту и тайминги. Обычно это цифры вроде DDR5-6000 и CL30. Споры о том, что из них важнее для игр, идут уже не меньше 15 лет, и как правило, обе стороны в них не правы примерно одинаково. Частота и тайминги — это не два независимых параметра, они связаны между собой через длительность такта, но часто важнее оказывается другой фактор. Об этом сейчас и поговорим.

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

Все условия были созданы: компания — на взлете, босс — поклонник ИИ, сфера деятельности — клиентская поддержка онлайн. Идеальные условия для внедрения ИИ. 

Что могло пойти не так?

Привет, Хабр! Меня зовут Сергей Маркизов и я бэкенд-разработчик в Далее. 

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

Node.js отлично чувствует себя в I/O-bound задачах (API, микросервисы, работа с базами данных и очередями), но как только в приложение попадает тяжелая CPU-bound логика (хеширование больших файлов, обработка изображений, видео, криптография) event loop может стать узким местом.

Один из способов решить эту проблему — вынести тяжелую часть в нативный аддон. В статье разберемся, как делать такие аддоны на Rust с помощью NAPI-RS: посмотрим на базовые типы, классы, асинхронные задачи, работу с JavaScript-объектами и управление ресурсами через Reference и External. 

Материал будет полезен Node.js-разработчикам, backend-инженерам и всем, кто хочет понять, когда Rust можно встроить в JavaScript-проект без боли для пользователей библиотеки.

В старой резервной копии базы данных 0.mk хранится 657 958 ссылок, созданных с 2009 по 2014 год, а также количество нажатий на них. В августе 2026 года мы восстановили 657 607 из этих записей в виде ссылок до 2015 года и прошли по каждой из них. Из 655 178 безопасных записей ссылок с возможностью перехода 76,7% больше не возвращало загружающуюся страницу.

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

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

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