Делаем сайты удобнее и приятнее
Привет, Хабр! Меня зовут Виктория Мохирева, я консультант SAP MM. Моя прошлая статья была посвящена тому, как с помощью локального класса и глобального API мы с командой «приручили» большую языковую модель для работы с пересортицей. И, как это часто бывает, с прототипа все только началось.
В этой статье мы проанализируем код одной из самых известных в мире игр: Grand Theft Auto Vice City. Это игра, на которой мы выросли. Хотя с момента её выпуска прошло более двадцати лет, код игры по-прежнему нас восхищает. Он не только хорошо работает на CPU с частотой 300 МГц (поскольку изначально его писали для PlayStation 2), но и обеспечивает игровой процесс без экранов загрузки сегментов карты, несмотря на ограничение в 32 МБ ОЗУ.
Здесь стоит упомянуть, что мы будем рассматривать не оригинальный исходный код, написанный Rockstar, а код на C++, полученный реверс-инжинирингом двоичных файлов игры. Мы поговорим о специфике эпохи PS2, почему игра почти никогда не распределяет память, о том, что весь город состоит из 25 пешеходов и 12 машин, обсудим работу физики и распознавание коллизий. В игре даже есть используемая для трюков система реплеев, которой для записи всех движущихся вокруг игрока объектов хватает одного мегабайта памяти.
Кроме того, Rockstar реализовала точно ту же механику работы с данными, что и в современных ECS-движках: целое число, в котором упакованы индекс слота и счётчик поколений, благодаря чему устаревшая ссылка ни на что не указывает.
В конце мы поговорим о знаменитых читах игры и о том, как она боролась с пиратством, ломая снайперскую винтовку, создавая ураган или даже повреждая данные сохранений.
В традиционном представлении бизнес-аналитик — это «собиратель требований» и переводчик между бизнесом и разработкой. Сегодня этого уже явно недостаточно. Генерацию пользовательских историй можно доверить ИИ, а ценность профессионала смещается в сторону стратегического мышления и исследовательской работы. Аналитик не просто посредник, а тот, кто снижает неопределённость для команды и руководства.
Недавно говорила об этом с коллегой и услышала неожиданный вопрос: «А ты всегда любила работать с неопределённостью?» Вообще-то никто не любит неопределённость, она вызывает стресс и тревожность. В контексте задач аналитика для меня фраза «работать с неопределённостью» означает умение взять её под контроль. И в этом смысле всегда интересно встретить новую задачу, которую можно решить.
В этой статье я расскажу об одном кейсе, где для снижения неопределённости использовался каскад исследований. И, как водится, я сделала ошибку, а потом её исправила. Понять почему неправильно выбрал фреймворк даже интереснее, чем идеальный план с самого начала.
Задача звучала так: «Пользователи испытывают сложности на странице поиска, нужно что-то менять». У такой задачи нет адекватных критериев приемки и сама формулировка содержит допущения. «Пользователи испытывают сложности» — это слишком универсально. Много вы знаете приложений, где ни разу не задумались как выполнить какое-нибудь действие? Почему утверждается, что именно нашим пользователям сложнее других? Какого рода сложности искать и как понять, когда остановиться в поисках? В общем, нужно снизить уровень неопределенности.
Вторая статья из цикла «Аналитик в чужом процессе»
После первой статьи я решил посмотреть существующие дашборды Service Desk. Оказалось, что проблема не в отсутствии отчётов. Иногда красивый дашборд опаснее его отсутствия — он создаёт ощущение контроля там, где его нет.
Привет, Хабр!
Развитие искусственного интеллекта заметно изменило экономику финансового мошенничества – в том числе атак на системы KYC. По оценке INTERPOL за 2026 год, схемы с использованием ИИ могут приносить в 4,5 раза больше средств, чем схемы без него. Генеративные инструменты позволяют охватывать больше потенциальных жертв, ускорять подготовку и снижать затраты на каждую новую атаку.
KYC-системы продолжают совершенствоваться, но теперь сталкиваются не с единичными случаями фальсификации, а с непрерывным потоком машинно созданных подделок. В этой статье разберем, как генеративный ИИ меняет атаки на удаленную идентификацию, почему фотографию паспорта нельзя считать достаточным доказательством его подлинности и какие уровни защиты помогают выявлять цифровое вмешательство до оформления услуги.
Типичная умная колонка с Алисой — это скромное железо и совсем немного оперативной памяти: у младших моделей её всего 256 МБ на всё устройство сразу. И за каждый мегабайт идёт настоящая борьба между множеством команд и компонентов: бизнес‑логикой, обработкой звука, локальными нейросетями.
Ежедневно мы собираем и анализируем memory‑дампы с миллионов колонок — нам важно понимать, куда уходят эти драгоценные мегабайты.
Меня зовут Сергей, я работаю в команде, которая пишет прикладной код на C/C++ для умных устройств с Алисой (например, колонок, телевизоров и автомобилей). Под катом расскажу, как мы построили и используем инструмент для анализа потребления памяти в проде на нашем флоте Linux‑колонок.
Первая статья из цикла «Аналитик в чужом процессе»
145 тысяч тикетов, почти 87 тысяч "аномалий" и уверенность, что Service Desk полностью сломан. Но один разговор с опытным специалистом первой линии заставил меня выбросить половину критериев, переписать анализатор и полностью изменить выводы. Эта статья — о том, почему большие данные сами по себе ничего не объясняют, если сначала не понять сам процесс.
Приветствую, Хабр!
В этой статье хочу описать практический кейс, который выглядит не как единичная ошибка на карте, а как системная проблема в работе навигационного сервиса от Яндекса. Речь идет о маршрутах в городе Дербент, где одна из дорог была перекрыта еще в марте 2026 года в связи с ремонтными работами (строительство сегмента центральной набережной города). Сейчас уже 23 июня 2026 года, прошло почти 4 месяца, но навигатор продолжает строить маршруты так, как будто проблемы не существует.
На первый взгляд это может показаться локальной городской неудобностью: где-то перекрыли дорогу, где-то маршрут стал длиннее, кто-то потратил лишние несколько минут. Но в реальности проблема серьезнее. Если навигатор отправляет водителей по маршруту, которого физически не существует, или ведет по дороге в таком состоянии, что там можно оставить колеса и всячески игнорирует попытки пользователей внести в маршрут корректировки - это уже не просто неточность данных. Это вопрос безопасности, качества сервиса и способности платформы реагировать на обратную связь.
Осенью 2026-го страна встала в очереди за бензином. Пока одни карты честно красили пустые баки красными точками, а официальные приложения сетей деликатно молчали о сухих колонках, мы задали неудобный вопрос: а что, если показывать не только где топлива НЕТ, но и где его ВОТ-ВОТ привезут? За пару дней 1 051 человек нажал кнопку «Тоже жду» — и мы поняли, что попали в нерв.
ГдеЗаправка (gdezapravka.ru) — народная карта наличия топлива на заправках России. Не приложение нефтяной компании и не рекламная витрина сети: обычные водители отмечают, где сейчас реально есть 92-й, 95-й и дизель, а мы собираем это в одну живую карту. Наличие — краудсорсинг от людей на местах, цены — открытый скрейп. Без единой строчки данных от владельцев АЗС. Отметиться можно анонимно, без регистрации и номера телефона — по отпечатку устройства.
Расскажу, как и почему я в какой-то момент решил написать собственный pivot grid — без сторонних библиотек, на чистом JavaScript и DOM. И что из этого получилось: от первой версии с обычным GROUP BY до кэширования больших выборок и цепочки связанных гридов.
Наш сетевой драйвер терял пакеты. Не время от времени, а постоянно. На пропускной способности линии с 64-байтными пакетами мы теряли 31% всего трафика.
В качестве оборудования использовался Ethernet-контроллер на 1 Гбит/с на SoC RISC-V. В спецификациях говорилось, что он может справляться со скоростью проводного трафика. Движок DMA работал корректно. Обработчик прерываний срабатывал вовремя. Тем не менее, пакеты исчезали.
Я начал с очевидного подозреваемого: очереди получения. Реализация выглядела вполне логично — простой связанный список с указателями на голову и хвост. Под нагрузкой (64-байтные пакеты на пропускной способности линии) драйвер терял 31% пакетов! При профилировании обнаружилась причина проблемы: производительность убивали связанный список и спин-блокировки.
Я переписал драйвер, использовав кольцевой буфер без блокировок. Результаты: потеря 31% пакетов превратилась в 0,12% — улучшение в 258 раз!
В этой главе мы поговорим о структуре очередей для драйверов устройств.
Наш загрузчик оказался слишком медленным. Требование было чётким: загружаться менее чем за 500 миллисекунд. Показатели оставались не менее чёткими: 720 миллисекунд. Мы отставали от нужного значения на 44%.
Это требование не было «мягким». Загрузчик должен был работать в промышленном контроллере, обязанном реагировать вскоре после включения питания. Каждая секунда времени загрузки — это потерянная продуктивность. В спецификации к изделию был указан максимум в 500 мс. Мы обязаны были их обеспечить.
Задача загрузчика была простой:
1. Инициализировать оборудование (UART, SPI, DDR-контроллер)
2. Загрузить ядро из флэш-памяти
3. Спарсить дерево устройств
4. Перейти ко точке входа ядра
Реализация казалась логичной: стандартные структуры данных из библиотеки C. Проблема выявилась при профилировании: 45% времени загрузки тратилось на malloc/free! В загрузчике всего с 64 КБ ОЗУ динамическое распределение роняло производительность.
Наш веб-краулер потреблял 128 МБ ОЗУ только на отслеживание посещённых URL. На встраиваемом устройстве с 256 МБ это была половина всей памяти.
Задача краулера была простой: отслеживать посещённые URL, чтобы не краулить одну и ту же страницу дважды. После обработки 1 миллиона URL (средняя длина 80 байт) хэш-таблица, в которой хранились эти URL, разрослась до 96 МБ плюс оверхед.
«Можем ли мы обменять точность на память? Нас вполне устроит несколько дублированных операций, если это позволит сэкономить большой объём памяти», — сказал мне мой менеджер во время ревью кода.
Этот вопрос изменил всё. На самом деле, идеальная точность не требуется. Если мы случайно обработаем одну страницу дважды, то впустую потратим часть пропускной способности, но ничего не поломаем. Главным ограничением была память.
В пайплайне перевода видео в Яндекс Браузере скорость работы в синтезе речи долго оставалась узким местом: одно видео — это сотни фраз, каждая генерируется отдельно, и любая сэкономленная миллисекунда становится заметной в масштабах сервиса.
Внутри TTS работает каскад из трёх компонентов: языковая модель предсказывает аудиотокены по тексту, диффузионный декодер восстанавливает мел‑спектрограмму из латентов, а вокодер превращает её в звуковую волну. Долгое время самой тяжёлой была языковая модель, но после её оптимизации на первый план вышел декодер латентов — его forward pass запускается на каждом шаге семплинга диффузии, а шагов — десятки. Именно его мы и взялись ускорять.
Когда маркетологи хотят всё: сырые данные в GA4, запись сессий в Метрике, хитмапы в Clarity и при этом «Lighthouse 100» в PageSpeed Insights — приходится изобретать. Расскажу, как мы это сделали на небольшом проекте и во что это обошлось по времени и нервам.
Проект — нишевый агрегатор российских хостинг-провайдеров. Более 120 страниц в sitemap, 31 статья, десятки категорий услуг, живые цены, сравнения. Стек: Astro 6 + Strapi 5 + Tailwind 4, плюс Partytown, PostgreSQL, Nginx и обычный VPS на Ubuntu. Сайт собирается в статику во время билда, никакого SSR в рантайме нет.
На desktop — Lighthouse 100 / 100 / 100 / 100. На mobile с жёстким throttling (4x slow CPU) — 99 / 100 / 100 / 100. В реальных условиях и по Chrome UX Report — 100 везде. LCP на desktop — 0,5 секунды, на mobile throttled — 1,7 секунды. CLS — ноль. TBT — 10 ms на мобильном и 0 ms на десктопе.
В ресторанных сетях данные о гостях часто распределены между несколькими системами. Бронирования хранятся в одном сервисе, чеки — в ресторанной учётной системе, переписки — в мессенджерах, отзывы — в агрегаторах, данные приложения — в отдельной базе, платежи — у эквайринга.
Такая архитектура усложняет работу с клиентским профилем. У бизнеса нет единой истории взаимодействия с гостем, менеджеры работают с фрагментами данных, а сервис, маркетинг и аналитика опираются на неполную картину. Для ресторанной сети это напрямую влияет на персонализацию, качество обслуживания, LTV и повторные визиты.
В проекте для сети из 10 ресторанов была реализована единая база данных гостей. Задача системы — собрать в одном профиле все взаимодействия клиента с бизнесом: от первого контакта и переписки до бронирований, чеков, отзывов, оплат, технических инцидентов и повторных визитов.
Сжатие текста уже давно стало стандартом в мире веб‑приложений. Сокращение объёма данных даёт сокращение времени передачи и снижение нагрузки на сетевой канал. Однако, часто настройка компрессии сводится к динамическому сжатию gzip и настройкам по умолчанию. В этой статье разберём вопрос сжатия более глубоко. Для начала вспомним основные технологии сжатия, доступные в вебе.
Подробное руководство по ускорению любимого браузера подручными средствами. В помощь домохозяюшкам, студентам и высшему руководству — всем у кого нет под рукой топового железа с 64Гб памяти для работы в современном интернете.
Пока впечатление о полученной услуге свежее, клиент лучше помнит детали и охотнее делится обратной связью. Бизнесу это помогает быстрее находить слабые места в сервисе и исправлять их.
Когда клиентов мало, администратор может быстро их обзвонить: спросить, всё ли понравилось, и зафиксировать ответы. При масштабировании бизнеса этот вариант уже не подходит: звонки отнимают много времени. В итоге часть визитов остаётся без проверки, а бизнес узнаёт о проблеме, когда недовольный клиент опубликовал негативный отзыв в интернете, ухудшив рейтинг компании, и перестал возвращаться.
В этой статье разберём, как автоматизировать исходящие звонки. Клиенту, получившему услугу, звонит голосовой робот и проводит короткое анкетирование. Результаты опроса сразу попадают в рабочую таблицу, а если клиент остался недоволен, управляющий дополнительно получает СМС и может быстрее разобраться в ситуации.
Стек решения: Python 3.10+, Flask, requests, python-dotenv, SQLite, YCLIENTS API, голосовой робот и SMS API МТС Exolve, MWS Tables.
Если вы думаете, что внедрение CRM — это «купить подписку, выдать доступы менеджерам и ждать роста продаж», спешим вас расстроить — такая схема устарела лет 10 назад.
Привет, Хабр! Меня зовут Наталия Меркулова, я руковожу продвижением CRM-системы и виджетами Envybox. Мы в Envybox создаём CRM-систему, которая не будет отпугивать менеджеров и забирать у них последнюю мотивацию работать. Вот уже 11 лет мы помогаем автоматизировать рутинные процессы — и, несмотря на то, что многие на рынке знают, что такое CRM, по нашему опыту мало кто понимает, когда в компании она действительно нужна. Чаще всего ценность теряется на этапе отрицания изменений командой. Поэтому сегодня хотим поделиться, почему так происходит, и как такие барьеры преодолевать, чтобы команде стало легче в том числе. В статье мы поговорим о том, как отказаться от табличек и листочков в пользу автоматизации и донести эту мысль команде.