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

Zed — новый редактор, написанный почти полностью на Rust. Своим слоганом он сразу заяляет то, для чего предназначен: Zed — Your last next editor.

Для меня Zed оказался нужен по следующим причинам: не устраивало наличие 5+ редакторов под разные языки программирования; требовалось иметь интеграцию с ИИ, чтобы тот мог вносить точечные изменения в код с автозапуском тестов и генерировать коммиты; хотелось найти что-то полегковеснее условных PyCharm, Intellij IDEA и им подобных; искал редактор, который без проблем сможет работать с WSL (в принципе, подходит большинство, но возвращаемся к вопросу о числе редакторов для разных проектов, так что нужно было “1 раз и чтобы навсегда”)

Я прошел через стадию отрицания при настройке (нет обычных кнопок Run и Debug, повсюду! Максимально непривычный интерфейс), но когда всё заработало, остался лишь один вопрос: почему я не слышал о Zed раньше?

Kubernetes без магии и заучивания команд. Разберёмся, зачем он вообще нужен, как устроен кластер, чем Control Plane отличается от Worker Nodes и какую роль играют Pod, Scheduler, kubelet, etcd и другие основные компоненты.

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

Разбираю по полям 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-программы, проводит внутренние соревнования по кибербезопасности или отвечает за обучение сотрудников и предпочитает наступать на чужие грабли заочно, а не на свои лично.