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

Привет, Хабр!

Меня зовут Илья Петров, я руковожу продуктом Digital Q.Sensor BI в «Диасофт». За последний год я неоднократно слышал одну и ту же фразу от разных команд — и своих, и клиентских: «нам бы сюда буквально пару графиков». И каждый раз внутри у меня загорается тревожная лампочка, потому что я примерно знаю, чем это заканчивается.

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

Вы наверняка сталкивались с этим эффектом: монтируете sshfs, rclone mount или gocryptfs — и после этого файловый менеджер, редактор, архиватор и бэкапилка работают с появившимся каталогом так, будто перед ними самая обычная файловая система. Хотя байты могут жить на сервере, в S3, внутри шифрованного каталога или вообще рождаться на лету.

Как программа из userspace умудряется встать между open() и данными так, чтобы остальная система ничего особенного не заметила? Сегодня разберёмся. Заваривайте чай покрепче (ядро любит крепкий), устраивайтесь поудобнее — поговорим про FUSE.

Сразу одна оговорка, чтобы не заложить мину в фундамент статьи: не всякая «сетевая папка» или подключённый телефон в файловом менеджере — это FUSE. GNOME GVfs, KDE KIO и MTP умеют показывать похожую картину на уровне приложений. FUSE идёт глубже: он подключается к файловому стеку ядра, поэтому смонтированное дерево видят обычные программы через привычные open(2), read(2), stat(2) и компанию.

Две недели назад я ехал к отцу и не успел примерно на сорок минут.

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

Когда приехал, его уже не было.

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

Но эти сорок минут почему-то заставили меня думать не столько о смерти, сколько о времени.

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

На этот раз мне захотелось попробовать описать не любовь.

Мне захотелось описать конец жизненного цикла.

Документация устаревает быстрее, чем код успевает писаться? Рассказываем, как мы построили конвейер из Python-скриптов и нейросетей, который сам находит изменения в PHP-контроллерах и обновляет документацию API Invapi.

Средний fps – вещь, которая к реальной плавности геймплея может не иметь никакого отношения. Вообще. Даже если вы собрали топовый ПК и имеете стабильные 180 кадров в счетчике картинка все равно может дергаться. А все потому, что глаз реагирует не на количество кадров, а на равномерность их появления. И вот эту равномерность средний показатель – тот самый AVG – как раз и прячет. Значит, надо смотреть на другие цифры. Но на какие?

Ключ-структура из числа и строки. Поиск по словарю на 10 000 таких ключей занимает 74 975 микросекунд. Тот же ключ, объявленный record struct, — 3,354 микросекунды.

Разница в 22 354 раза, и берётся она не из сравнения ключей.

Мы сделали свой UI Kit: 6 компонентов превратились в 30+, а одна ошибка сломала разметку во всех проектах

С чего всё начиналось

Когда в проекте начинает появляться всё больше одинаковых элементов интерфейса, рано или поздно возникает вопрос: зачем каждый раз создавать один и тот же Button, Input или Select?

Мы рассматривали готовые решения, в том числе Ant Design и Material UI, но они не закрывали наши требования. Нам требовался больший контроль над внешним видом и поведением компонентов, возможность детально адаптировать их под наши задачи и учитывать требования проекта к безопасности.

Привет, Хабр!

На связи Дмитрий Ларин, я руковожу продуктовым направлением по защите баз данных, в Гарде.

Маскирование данных — важное направление нашей работы (в продуктовой линейке Гарды даже представлен отдельный продукт для выполнения таких задач). Поэтому нам не привыкать к разнообразным вопросам об этом методе защиты — от банального «зачем вообще нужно маскирование?» до провокационного «почему бы не скормить поиск ПДн нейронке?».

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

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

Итак, поехали.

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

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

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

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

Переход строительной отрасли на отечественные ТИМ/BIM-решения поставил перед застройщиками, техническими заказчиками и проектными организациями практический вопрос: способны ли российские программные продукты обеспечить полноценное информационное моделирование без использования зарубежного программного обеспечения и сохранить привычные процессы взаимодействия участников проекта?

В статье представлен практический опыт реализации одного из первых в России проектов по комплексной разработке всех основных разделов проектной документации многоквартирного жилого комплекса с использованием отечественной ТИМ/BIM-платформы nanoCAD BIM Строительство и nanoCAD Инженерный BIM1 (далее – nanoCAD BIM). На момент подготовки статьи проект успешно прошел экспертизу и получил разрешение на строительство.

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

На практике до дашборда было ещё далеко.

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

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

Я наблюдал ситуации, когда компания формально соответствует требованиям регулятора, регулярно проходит аудиты, имеет утвержденные Политики, настроенные СЗИ, выделенный SOC и несколько сотен страниц Регламентов на случай любой проверки.

Но однажды, после первого инцидента, выяснялось, что:

— Учетная запись имела многофакторную аутентификацию (что после компрометации сессии значения не имеет).
— SIEM собирал события, но расследование затруднялось тем, что в разных источниках один и тот же пользователь имел разные идентификаторы.
— Доступ сотрудника был вовремя отозван в Active Directory, но остался в одном из SaaS-сервисов.
— Резервное копирование выполнялось ежедневно, но восстановить критичный сервис в установленный RTO невозможно.

Значит ли это, что мы должны отказываться от формальностей? Нет, конечно. Соответствие требованиям необходимо. Без него невозможно выстроить управление ИБ, тем более в регулируемых отраслях.

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

Предлагаю посмотреть на области, которые уже соответствуют требованиям, немного другим взглядом. Рассмотрим MFA, SIEM, управление доступом, DLP и прочие моменты с точки зрения слабых мест бумажной безопасности.

В Lаmoda Tech мы внедряем машинное обучение и работаем с большими данными, чтобы сделать онлайн-шоппинг для миллионов пользователей комфортным, увлекательным и вдохновляющим. И делимся на митапах самыми интересными кейсами.

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

Когда работаешь с такими масштабными продуктами, как мы делаем в VK, быстро начинаешь ценить код, который можно не писать. Особенно если речь о небольших сценариях: открыть поповер, анимировать появление блока или подстроить поле под контент. Ещё недавно для таких задач мы почти автоматически тянулись к JavaScript. Но за последние два года CSS сильно расширил свои возможности для задач, связанных с интерфейсом.

Я Максим Кузнецов, занимаюсь оптимизацией производительности и улучшением стабильности веб-версий ВКонтакте. В этой статье расскажу, что уже можно использовать как альтернативу JS, что стоит попробовать аккуратно, а за чем пока лучше просто следить.

Мне надоело тянуться к клавиатуре и мыши, чтобы пролистнуть ролик, — и я собрал кликер для ПК на базе ESP32. Три кнопки, наподобие пульта для презентаций: две листают ленту стрелками вверх и вниз, третья отправляет F13. Её нажатие ловит собственное расширение браузера и ставит лайк.

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

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

Дальше — весь путь: от печати корпуса и схемы на ёмкостных сенсорах до кода прошивки и расширения под Firefox и Chrome. Со сметой на 450 ₽ и граблями, на которые я наступил.

Всем привет. На связи Сергей Игнатенко, основатель ИИ-платформы VibePilot. Мы сделали свой бенчмарк моделей ИИ на реальных задачах: сметы, договоры, многостраничный Excel. 1 198 задач, 22 сбоя, 1,8%. Считается, что суверенные модели слишком слабы для агентов. Внутри жёсткого конвейера Алиса делает смету с разделами за 19 секунд и обгоняет Qwen3-235B в четыре раза.

Я программист с приличным стажем, ещё в школе писал игрушки для БК‑шек, а сейчас у меня коммерческий стаж на Python, и я считаю себя, в общем‑то, уверенным сеньором.

До недавнего времени из ИИ я пользовался только браузерным Gemini. Он быстрый, живой, отзывчивый — с ним можно приятно поболтать, однако кодит он неважно. Добиться нужного результата частенько получалось только через крепкое словцо, на которое, впрочем, Gemini охотно откликается. Но понятно, что это всё жутко неудобно и надо было переходить на кодинг‑агентов.

Так бы я и канителился, однако получилось так, что вайб‑кодинг, вместе с вайб‑планированием и вайб‑постановками задач в Jira, в нашей команде внедрили волевым решением. Никого не спрашивая, не выясняя, кто что умеет, кто как к этому относится и как это вообще повлияет на разработку.

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

Всё началось со странной потери скорости решения задач.

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

Насчёт лимитов я особо не переживал. Подход моей AI-команды позволяет параллельно работать над несколькими крупными проектами на подписке Claude Code стоимостью 100 долларов. Команда разделена на роли, у каждой роли собственная рабочая область, задачи декомпозируются, а большие исследования можно выносить в отдельные сессии. Система была рассчитана именно на то, чтобы не складывать весь проект в голову одному агенту.

Но затем мой AI-архитектор продукта дважды ушёл в сжатие контекста.

Он работал на Opus с контекстным окном в один миллион токенов.

Первый раз можно списать на случайность. Второй — уже закономерность.

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

Началось расследование.

Тогда я ещё не знал, что системная проблема всей AI-команды началась, скорее всего, с одной моей ошибки в терминале.

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

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

Трудно представить начало сессии с ИИ, в которой модель легко и быстро понимает весь проект и необходимый контекст, чтобы принять от разработчика требования и качественно спроектировать внедрение, не сломав текущее стабильное состояние. Экспертиза инженера‑разработчика или системного аналитика несравненно качественнее — хотя бы потому, что он живёт с ней 24/7.