Technotext

Год назад на конференции VideoTech ваш покорный слуга сделал большой доклад, в том числе про прогресс современных метрик качества видео (которыми мы довольно плотно занимаемся: тык, тык, тык, тык, тык, тык, тык, тык). А на открытой дискуссии тем же вечером представитель крупного российского видеосервиса поднялся и высказал всем мнение (своего менеджера):

«Измерение качества видео — это лишняя операция. Бизнес — это вообще-то про деньги. Поэтому в бизнесе главное — это бизнес-метрики: user retention, DAU, MAU и вообще ARPU. А все эти ваши PSNR, SSIM, VMAF — от лукавого. Если пользователи платят деньги и не отписываются, значит всех всё устраивает и это главная метрика качества».

«И вообще в свое время в Toyota был внедрен подход Lean Manufacturing, где одна из «семи потерь» — это потери из-за лишних этапов обработки (waste on over-processing), к которому, очевидно, относится измерение качества. Эти материи проходят на курсах MBA, которые довольно дороги. Поэтому далеко не все российские технари в теме этих важнейших понятий и не в состоянии осознать их критическую важность для бизнеса компаний».

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

«Слушай, а почему у меня на даче YouTube через Роскомнадзор работает лучше Rutube без Роскомнадзор?»

(видеоверсия — доклад на VideoTech доступен тут)

Ну-с, господа, «которых всё устраивает!» Поехали! 

Однажды к нам обратился клиент с проблемой: имеется 2 HDD с производительностью записи 250 MБ/с. Из них делается хранилище RAID 0. Начинаем записывать трафик, скорость — 350 MБ/с. Он успешно пишется, но через некоторое время утилизация дисков подходит к 100% и начинаются потери при записи. Вывод клиента: проблема в PT NAD, так как диски должны все успевать. Думаю, многие уже догадываются, в чем соль. У нас тоже имелись догадки, но тем не менее мы решили их проверить. Из этой проблемы и родилось небольшое исследование по записи трафика в хранилище. Под катом — наше расследование «заговора» разработчиков HDD.

Некоторое время назад администрация платформы, номинально, ведомая проникновением ИИ во все сферы нашей жизни, предложила пользователям помочь Хабру идеями. Это предложение было оформлено в виде поста со ссылкой на опрос, который выяснял: нравится ли пользователю ИИ‑контент и что делать с ИИ‑контентом на Хабре?

Данное официальное сообщение администрации, однако, находится в некотором концептуальном противоречии с заметкой «Инфляция обратной связи» продукт‑менеджера Хабра в его публичном тг‑канале:
«Когда проект становится значимым, обратная связь теряет в цене: мнение одного человека плохо масштабируется на миллионы; отклики часто противоречат друг другу. Поэтому статьи в духе «5 идей как сделать Хабр лучше» всегда хорошо обсуждают, но пользу из них извлечь сложно»

Обдумывая это противоречие, мне стало интересно, когда именно Хабр превратился из маленькой деревушки, где староста знал каждого в лицо, в Олимп, с вершины которого ропот внизу не особо различим? Так как батарейки в моём Б3‑18М сели, я взял арифмометр «Феликс», бумагу, перьевую ручку и решил выписать некоторые числа, а затем кое‑что посчитать.

Но как это часто бывает, исследование привело туда, где сам вопрос уже не вполне имеет значение :)

В Дринкит был анимированный компонент на MotionLayout — слайдер быстрой оплаты в меню. Его и сейчас можно увидеть, когда вы добавляете продукты в корзину. Проведя по нему, вы оплатите заказ, а тапнув — перейдёте к покупкам.

Так почему «был»? У компонента накопилось немало багов, а самому слайдеру понадобился новый функционал. Реализовать его на MotionLayout было сложно, так что мы решили переписать компонент на Compose.

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

Весной 2025 года Google представила Live Updates, аналог Live Activity в iOS. Мы быстро запушили продактов — «нам такое надо!» — и потащили фичу в Android-приложение Додо Пиццы.

Но всё оказалось не так просто — мы столкнулись с неполной документацией, расхождениями представлений дизайнеров Google и разработчиков этого SDK, и не только. В общем, запасайтесь попкорном. Сегодня расскажем обо всех нюансах в реализации и тестировании Live Updates.

Недавно, перебирая хлам скопившийся на пыльных антресолях, я обнаружил старенький MacBook 2,1 (A1181) образца 2008 года выпуска. Этот MacBook мне на день рождения, который состоялся более 15-ти лет назад, подарила супруга. Большим ценителем яблочной продукции я так и не стал, но некоторое время использовал эту машинку в качестве второй — для чтения почты или просмотра ютуба, брал с собой в туристические поездки. Мне нравился дизайн корпуса и клавиатуры этой машинки, местами даже где-то меня привлекала операционная система MacOS X являющаяся родственником FreeBSD. Но сейчас не об этом. В те времена вычислительная техника персонального применения стремительно устаревала — появлялись процессоры с всё большим числом ядер и большей тактовой частотой, состоялся полный переход от 32-битных архитектур к 64-х битным и т. д. Всё это сильно расслабило разработчиков и, как следствие, требования софта к железу выросли просто непомерно. Таким образом, данная машинка очень быстро «морально устарела». Я пару раз проводил апгрейд — сначала добавил немного SDRAM, потом заменил HDD на SSD, несколько раз апгрейдил MacOS X. Но к 2012 году машинка всё равно стала мало пригодной для работы и отправилась на антресоли.

Две недели назад этот MacBook попался мне на глаза. Я включил его и обнаружил, что MacOS X прекрасно загружается и даже подключается к WiFi, только вот в Safari все сертификаты давно протухли и ни один Web сайт не открывается. Но тут меня посетила совершенно здравая мысль - почему бы не оживить эту машинку установкой на неё современной ОС, такой как например FreeBSD ? К тому же появился повод — одна из моих дочерей доросла до своего компьютера, а покупать ей сейчас новый ноут для посещение «учи.ру» меня, откровенно говоря, «жаба душит». Короче, я быстренько заказал новую АКБ на известном китайском маркетплейсе и принялся изучать вопрос «как пропатчить KDE MacBook для FreeBSD».

В данной статье я расскажу о некоторых особенностях яблочных ноутбуков мало знакомых даже опытным маководам, о тонкостях установки FreeBSD, о проблеме под названием UEFI, о баге в ядре ОС FreeBSD с которым я столкнулся и помог зафиксить, о прекращении поддержки DRM-KMOD драйверов в 32-х битной ветке ОС FreeBSD и о том, как мне все же удалось портировать их для FreeBSD 14.3-RELEASE/i386. И еще о некоторых мелочах, знание о которых необходимы для того, чтобы сделать ОС FreeBSD пригодной для эксплуатации на этом стареньком MacBook-е, и чтобы Ваш кислотно-щелочной баланс всегда оставался в полном порядке^TM.

Отладка больших CMake-проектов часто превращается в боль. Уходит не один час на то, чтобы с помощью message() и бубна найти проблему. Но существуют более удобные и эффективные способы. Например, отладчик, который позволяет пошагово пройтись по CMake-скриптам и посмотреть значение переменных. Или профилировщик, показывающий последовательность вызовов и время их выполнения. Как их использовать? Читайте в статье.

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

Разговор о собственном PostgreSQL-кластере обычно начинается с фразы: «Да там поставить — день работы». Технически это правда. Установка PostgreSQL на два сервера в разных ЦОДах действительно занимает несколько часов. Проблема в том, что установка — это меньше 10% работы до Production-ready-состояния.

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

Параллельно покажем те же временные и трудозатраты при выборе Managed-решения, DBaaS (базы данных как сервис), чтобы вы могли сравнить и выбрать — делать дальше самим или передать это на аутсорс.

Кажется, что оборачивать BigDecimal и String в отдельные классы — это overengineering и преждевременный DDD. Но именно из-за этих «лишних» типов в прод не пролезают посылки в ПВЗ, проценты внезапно превращаются из 0.8 в 80, а деньги теряют валюту и смысл. В статье на реальном примере логистики разбираем, как один небольшой record Weight и несколько аккуратных Value Object’ов наводят порядок в бизнес-логике: инварианты перестают жить в комментариях, проверки перестают дублироваться, а код начинает читаться как текст предметной области. Без внедрения полного DDD, без религиозного фанатизма — только практические шаги.

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

С точки зрения ИТ доменная печь — это огромный «чёрный ящик». Вы кладёте сырьё и топливо, получая на выходе чугун и шлак. Измерить внутри все можно почти ничего нельзя: датчики просто «умирают» от температуры, воздействия шихты и прочих условий. Измерить снаружи тоже сложно (да и нужно ли?): большие печи имеют диаметр порядка 15 метров и высоту 35 метров, — что нам дадут граничные условия для таких размеров?! По опыту на малых печах можно измерять уровень расплава (без разделения на шлак и чугун) по ЭДС внешними датчиками, но у нас так не выйдет, и нам пришлось провести целое исследование, чтобы понять, почему.

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

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

Но цифровые возможности развиваются, и мы пробуем применить самые современные цифровые решения, даже если они на грани возможного.

Некоторые уязвимости, связанные с повреждением памяти, невероятно сложны для эксплуатации. Они могут вызывать состояния гонки, приводить к сбоям системы и накладывать разные ограничения, которые усложняют жизнь исследователя. Работа с такими «хрупкими» багами требует значительно больше времени и усилий. CVE-2024-50264 в ядре Linux — как раз одна из таких сложных уязвимостей, которая получила премию Pwnie Award 2025 в категории «Лучшее повышение привилегий» (Best Privilege Escalation). В этой статье я представлю свой проект kernel-hack-drill и покажу, как он помог мне разработать прототип эксплойта для уязвимости CVE-2024-50264.

Привет! Я Рома, бэкендер-питонист в KTS.

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

Привет! Я Тимур, разработчик мобильных приложений в KTS.

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

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

Да, тема довольно холиварная, и в статье я не заявляю, что KMP лучше Flutter’а во всем. Каждая технология хороша под свои задачи. Вместо этого я расскажу о конкретном проекте, на котором KMP оказался более удачным выбором. Также коснусь вопросов архитектуры и миграции Android-приложения на iOS с помощью CMP, а заодно подсвечу подводные камни, с которыми пришлось разбираться в процессе.

Бизнес Додо активно масштабируется. Уже сейчас Dodo IS круглосуточно работает в двух облаках, более чем в 25 странах и практически во всех часовых поясах. В таких условиях важно знать, что вся система действительно работает хорошо, а не просто «не горит» прямо сейчас.

Чтобы это знание обрести, мы привезли в нашу инженерную савану SLO'на — неповоротливое, но умное существо. Он наводит порядок в хаосе метрик и алёртов, и отличает реальную проблему от мнимой. А ещё он требует внимания, точных чисел и ясных целей. Поначалу мы его боялись, но позже поняли: если его приручить, он защитит нас от ночных звонков и научит бизнес говорить на языке надёжности.

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

Это очередная статья на тему «как прокачаться продакту». Однако рекомендовать в ней книги, подкасты или «100% работающие» фреймворки я не буду.

Привет, меня зовут Юля! В этой статье я поделюсь навыками, которые стоит развивать всем желающим качаться в продукте.

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

До этого «скоро» ещё далеко, но это не повод не использовать ИИ-агентов в автоматизации различной рутины. Например, в написании платёжных интеграций для POS-терминалов в разных странах. Передать ИИ-агентам такую задачку — не очень просто, но у нас получилось! Сегодня расскажем, как мы это сделали.

Почему даже самая мощная LLM иногда выдаёт бессмысленные фразы и противоречия? Всё дело в экспоненциальном росте вариантов (N^M) и свободном копировании человеческих ошибок. Читайте статью, чтобы узнать, как мы с помощью формальных грамматик превращаем хаотичную генерацию в управляемый синтез, усиливая роль семантики и соблюдая структурные правила.

Представьте: ваш Python-код работает на 30% быстрее благодаря JIT-компиляции, обработка запросов масштабируется на все ядра процессора без ограничений GIL, а отладка высоконагруженных систем происходит в реальном времени, без остановки продакшена. Это не футуристический сценарий “what-if” — это реальность Python 3.14, релиза, который переосмысливает саму природу разработки с высокой производительностью на Python.

К середине 80х рынок 8-битных ПК типа Commodore 64 и ZX Spectrum достиг насыщения. Новые задачи (современная графика, плавная анимация в играх, софт для бизнеса, «взрослая» компьютерная музыка) уже не укладывались в их возможности.

Ответом на вызов стали две «машинки», ставшие символами новой эпохи — Commodore Amiga и Atari ST. Это прямо quantum leap (но не от Синклера), который похоронил собственных 8-битных предков. 

В этой истории главный парадокс в том, что технологическую революцию сделали именно Commodore и Atari, но оба бренда упустили массовый сегмент, и уступили место «серому ящику» от IBM.

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