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

После недели работы с кодинг-агентом возникает вопрос: почему счёт растёт быстрее, чем объём написанного кода.

Разбираю по полям usage, куда именно уходят токены. Оказывается, типов не два, а пять: обычный ввод, запись в кэш, чтение из кэша, вывод и reasoning. Последний виден не всегда, а платите вы за него по цене вывода: в одном из примеров из 234 токенов ответа 230 оказались рассуждениями, а полезного текста — одно слово.

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

Обычно под термином транслитерация подразумевают написание русскоязычного текста latinskimi bukvami. Однако это лишь одна сторона транслитерации — романизация.

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

Более того, существующие библиотеки часто не учитывают контекст и преобразовывают побуквенно. Результаты могут быть трудночитаемыми и нарушать всевозможные языковые правила. Например, 北海道 (Хоккайдо) становится Bei Hai Dao, بغداد (Багдад) становится bGdd, и так далее

Что, если нужна бесплатная библиотека, которая живёт на нашем сервере, и которая каждый раз выдаёт предсказуемые результаты? Что, если нужна правильная, удобочитаемая транслитерация? Что, если нужна не только романизация, но и транслитерация между самыми разнообразными письменностями и языками?

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

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

Но разработчики нет‑нет да и задаются вопросом: а что, если сделать email лучше? Так рождаются RFC — от крошечных правок до попыток заново изобрести почту на JSON. По этим документам можно заглянуть на десятилетие вперёд и понять, какие идеи получат массовое распространение, а какие останутся красивой мечтой.

Привет, Хабр! Меня зовут Лёша Савлев, я скрам-мастер продуктовых команд м2. За последние полгода мы изменили наш подход к дискавери — и я хочу поделиться тем, как мы этого достигли. 

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

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

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

Разрабатывать собственный SSH-клиент за такой срок было бы интересным способом познакомиться с бессонницей, но плохим способом выполнить проект. Поэтому в 2024 году мы пошли по максимально прагматичному пути: взяли open source, сделали форк, адаптировали его под требования заказчика и примерно за 35 дней превратили задачу по импортозамещению в продукт, который можно было закупать.

Мы тогда совершенно не планировали следующие два года переписывать интерфейс, спорить с архитектурой Electron/NodeJS, самостоятельно переделывать RDP и VNC, добавлять клиент баз данных, десяток администраторских инструментов, а в итоге выбрасывать почти весь старый backend и переносить приложение на Rust. Но именно это и произошло.

Эта статья — не о том, как мы с первого раза все сделали правильно. Скорее наоборот. Здесь будет несколько решений, которыми мы довольны, и минимум четыре случая, когда сначала пришлось сделать неправильно, чтобы понять, что вообще требуется делать.

В этой статье:

● Откуда вообще взялась задача

Долго выбирал что взять в первый практический разбор/демонстрацию возможностей своего инструмента. Решил остановиться на разборе изменений Правил продажи.

С 1 сентября действуют новые Правила продажи товаров - ПП № 657. Прежние, ПП № 2463, утратили силу. Это не поправки, а новый документ: в начало добавили три пункта, и дальше вся нумерация сдвинулась на три.

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

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

Сервис принимал запрос, писал строку в базу, отвечал 201. Никто не пишет статей про такой код, потому что в нём нечего обсуждать.

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

Значит нужно асинхронно, через брокер. И почти всегда этим брокером оказывается Kafka.

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

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

Все мы живем в мире, полном противоречий. С одной стороны, постоянно появляются и очень быстро развиваются новые технологии. В то же время многое остается неизменным просто потому, что оно работает. Магнитная лента — ровесница послевоенных ЭВМ, технология настолько древняя, что впору держать ее в музее рядом с перфокартами. Но удивительный факт: в первом квартале 2026 года суммарная емкость поставок LTO выросла на 57% по сравнению с прошлым годом. Динозавр вдруг ожил, и виноват в этом, как ни странно, искусственный интеллект.

Обучение языковых моделей требует гигантских объемов хранения для исходных датасетов, с чем HDD или SSD не всегда справляются. В отличие от магнитных лент. Современный стандарт LTO-10 упаковывает до 40 ТБ чистых данных (или до 100 ТБ сжатых) на один компактный картридж.

Если открыть статистику по запросу modx, первое впечатление довольно приятное: частотность — 8 011. Для довольно нишевой CMS выглядит солидно.

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

Проблема обнаруживается после раскрытия списка.

Задача звучала просто: создать ВКС с jitsi и чатом нарисовать красивый интерфейс в корп стиле.

Решение — написать собственный тонкий веб‑клиент поверх matrix-js-sdk, который разговаривает с уже существующим Synapse‑сервером и Jitsi‑сервером, но выглядит и ведёт себя как часть внутреннего портала компании.

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

С Вами Артур Валиев V.

Когда-то давно я начинал писать музыку на пятнадцатидюймовом ЭЛТ-мониторе. Кажется, это был какой-то старенький 550S — огромная тяжёлая коробка с выпуклым стеклом, занимавшая приличную часть стола.

А ещё у меня был диск.

Один из тех дисков из далёкого и уже почти забытого компьютерного прошлого: сборник программ, который мой брат когда-то купил на Горбушке. Я не знаю, зачем он его купил. Диск несколько лет лежал среди игр, драйверов и прочего компьютерного хлама, пока однажды после игр, учёбы и обычной подростковой суеты мне просто не стало скучно.

Я достал его и начал устанавливать всё подряд. Среди программ оказалась FL Studio, кажется, третья версия. Поставил совершенно случайно, открыл, ничего особенно не понял и начал стучать по барабанам.

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

Зачем я вообще начинаю статью про системное приложение для Windows с какого-то старого диска и ЭЛТ-монитора?

Потому что эта статья на самом деле не столько про мониторы.

Она про пространство.

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

Ниже я разберу типичные UX‑ошибки на уровне сценария, примеры «как не надо» и «как лучше», а также простые метрики, по которым можно заметить проблему в своём боте. 

Давным‑давно, аж одиннадцать лет назад, в соответствии с Федеральным законом «О промышленной политике в Российской Федерации» Правительство Российской Федерации выпустило знаменитое Постановление от 17 июля 2015 г. № 719 «О подтверждении производства промышленной продукции на территории Российской Федерации», сокращенно везде именуемое ПП 719. Основной целью данного постановления была стимуляция развития отечественной промышленности. После начала СВО и введения санкций ПП 719 становится ключевым в продвижении любой продукции.

С завидной периодичностью выходят дополнения к данному постановлению, что добавляет азарта в попытках угнаться за фантазиями законотворцев. Меня, как разработчика электроники (на данный момент времени — автоэлектроники) сильно заботят изменения, касающиеся группы II (Продукция автомобилестроения) и группы IX (Продукция радиоэлектроники). Последние редакции ПП 719 в этих группах определены Постановлением Правительства Российской Федерации от 16 марта 2024 г. № 317 «О внесении изменений в Постановление Правительства Российской Федерации от 17 июля 2015 г. № 719».

Дисклеймер от автора: Я пишу эту статью, опираясь на 15 лет работы в тренингах, сотни часов индивидуальных сессий с IT-руководителями и собственный опыт трансформации в управленца. То, что вы чувствуете — нормально.

Вы написали сервис, который обрабатывает миллион запросов в секунду. Вы спроектировали архитектуру, которую не стыдно показать на HighLoad++. Вас повысили до тимлида или архитектора-наставника.

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

Поздравляю. У вас синдром самозванца. И если верить моей практике (а также статистике Harvard Business Review), прямо сейчас его испытывают около 70% специалистов при переходе на новую ступень ответственности.

Почему ваш внутренний критик орет громче обычного

В разработке всё логично. Тесты зеленые или красные. Сложность алгоритма оценивается. Это мир бинарной определенности.

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

Когда инженер становится лидом, происходит слом парадигмы:

OpenAI выпустила подробный гайд по промптам для GPT Image 2.5. Я прочитал его, а потом полез на Reddit смотреть, что происходит с этими рекомендациями в реальной жизни. Оказалось, пользователи уже успели не только проверить многие советы, но и найти несколько довольно полезных обходных путей.

Добавление физического сервера в кластер Kubernetes требует ручных действий: подключиться по SSH, установить пакеты, добавить параметры подключения и секреты, сконфигурировать kubelet, проверить, что узел появился в кластере, повторить для следующего сервера.

Привет, Хабр! Меня зовут Андрей Волков, я руководитель SRE в команде Managed Service for Kubernetes в Yandex Cloud и мы добавили возможность подключать BareMetal-серверы в кластер Kubernetes одной кнопкой.

Привет, Хабр! Меня зовут Илья Никифоров, я отвечаю за Security Awareness — обучение сотрудников информационной безопасности в команде GRC в Авито. 

CTF (Capture the Flag, или «захват флага») — соревнование по кибербезопасности, в котором участники решают задания и получают за них очки. В каждом задании нужно найти «флаг» — короткий текстовый ответ. Например, разгадать шифр и получить секретное слово. Участник вводит найденный ответ на сайте соревнования: если он верный, система начисляет очки.

Один из форматов CTF называется jeopardy. Это набор отдельных заданий: участник сам выбирает, с какого начать и к какому перейти дальше. Решённые задания приносят очки, а место в таблице результатов зависит от того, сколько очков удалось набрать.

Совместно с BI.ZONE мы взяли эту механику за основу и собрали «Кибердетектив» — соревнование по информационной безопасности для нетехнических сотрудников. Для основной части заданий не требовалось писать код. В некоторых из них флаг выдавался за отказ от опасного действия. Но автоматически отклонять всё подряд было недостаточно: нужно было разобраться в ситуации и найти безопасное решение.

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

Андреа Бранкалеони (Andrea Brancaleoni) прекратил сопровождение 113 пакетов в дистрибутиве Void Linux в ответ на нетерпимость применения AI-инструментов для анализа изменений и выполнения рутинных задач. Без сопровождения остались такие пакеты, как alacritty, arpwatch, asus-kbd-backlight, clementine, docker-cli, etcd, flint, forego, fscrypt, kubernetes, libguestfs, libnfc, moby, openresolv, packer, racket, rancher-compose, terraform, thermald, trollock, ttf-ubuntu-font-family, vagrant и virt-manager.

Два дня назад в процессе оценки совместимости пакетов с новой версией языка программирования Go, Андреа опубликовал статистику со списком пакетов, в которых возникли проблемы со сборкой после обновления инструментария, а также разбором изменений в Go, из-за которых возникли проблемы. Один из членов Void Core Team спросил, каким образом было подготовлено сравнение, на что Андреа признался, что использовал типовой инструментарий с AI-агентом OpenСode и AI-моделью GLM-5.3-flash.

Участник из Void Core Team ответил, что он не намерен пробираться через дебри сгенерированного при помощи AI текста, и привёл выдержку из правил проекта, предписывающих принимать только изменения, подготовленные людьми, и допускающие использование AI-инструментов лишь для проведения исследований и обучения. В правилах указано, что код, документация, отчёты о проблемах, комментарии и описания pull-запросов должны создаваться людьми, разбирающимися в сути содержимого.

Андреа пояснил, что присланный им текст прост для понимания, и он ручается за информацию в нём. На что участник из Void Core Team заявил, что правила предельно ясно указывают на то, что текст не может быть сгенерирован AI, независимо от того, ручается или нет за него разработчик. Андреа ответил значком

Мажор всей экосистемы: что появилось в redb.Core, redb.Route, redb.Tsak и redb.Identity, что закрыто по безопасности и что ломает обновление.

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

Это мажор всей экосистемы разом. Хранилище redb.Core, интеграционный движок redb.Route, рантайм redb.Tsak и OpenID-сервер redb.Identity выходят одним номером: 76 пакетов на NuGet (у 3.7 было 66), семь образов в GHCR, архивы под Windows и Linux. Pro-издание по-прежнему бесплатно и не требует лицензионного ключа на всей линии 4.x.

Изменений столько, что подробный разбор любого из продуктов тянет на отдельную статью, и такие статьи будут. Здесь коротко, почти списком: что появилось, что закрыто по безопасности и что нужно знать перед обновлением. Полные списки изменений лежат на redb.ru/releases.