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

В начале 80-х мир захлестнула — по крайней мере его гиковскую часть — ПК-мания, и у «буржуев» набирали высоту BBC Micro, ZX Spectrum, MicroBee, Apple II и другие машинки, на которых миллионы западных школьников с упоением писали свои первые программы и игры.

Этот пост для разработчиков, которые еще скептически относятся к кодингу с ИИ агентами и не используют его. Мир стремительно меняется и пора «проснуться» и поменять методику работы.

Ниже я расскажу личный опыт, чтобы было нагляднее.

На примере маркетплейса разберём, как разделить приложение на feature-модули, связать сервисы через DI, организовать состояние и изолировать работу с браузерными API.

Про HTTP/2 и HTTP/3 обычно пишут, что они ускоряют всё подряд. Я собрал стенд и померил сам: Caddy отдаёт одни и те же данные по всем трём протоколам, tc netem изображает шесть сетей — от дата-центра до края соты.

Результаты вышли неудобными. На десяти файлах HTTP/2 проигрывает старому HTTP/1.1. На одном крупном файле все три протокола показывают одинаковое время. В дата-центре новые протоколы отстают вчетверо. Выигрыш есть, но узкий и адресный.

В этой статье рассмотрим получение Номенклатуры из базы данных SQL и последующую запись в систему 1С. После обработки сообщения системой 1С будет сформирован асинхронный ответ о статусе обработки и отправлен в систему источник.

Кейс по мотивам исследования SKILL.state: немного инженерии контекста, бенчмарков и графиков. Эксперименты с памятью coding-агентов в OpenCode и Codex и размышления о перспективах идеи.

Совет оптимизировать сайт под Claude смешивает два инструмента Anthropic: Claude и агента Claude Code. Profound снял 24 135 ответов на одних запросах, и у двух инструментов разошёлся почти каждый показатель. Я прошёл по документации путь запроса в обоих инструментах. Для владельца сайта из разбора следуют три вещи: какие боты Anthropic заходят на сайт, что закрыть в robots.txt и как проверить заходы по access-логу.

Представим обычную задачу: хочется куда-нибудь уехать на выходные. Есть бюджет, свободная суббота и воскресенье, желание оказаться у воды и условие вернуться домой до полуночи.

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

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

Путешествие редко состоит из одной операции: нужно совместить транспорт, даты, жилье, бюджет и иногда несколько пассажиров. Поэтому в начале лета мы открыли сервисы Туту для ИИ-агентов через Model Context Protocol (MCP), а в августе дали эту инфраструктуру участникам всероссийского хакатона.

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

Прототип к исследовательскому проекту «Планировщик инструкций для VLIW‑архитектур». Главный тезис:

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

Проще говоря, NEX CLI x Elbrus берет граф и модель e2k‑v6 и показывает: сколько насчитал жадный, сколько мог бы идеальный, и на какой операции и каком канале разница.

В прошлой статье показал скатерть Улама

( https://ru.wikipedia.org/wiki/Скатерть_Улама https://en.wikipedia.org/wiki/Ulam_spiral )

немного её усовершенствовал в косынку и померял с разных сторон.

Но вот если рисовать точки не по квадрату? Скатерть Улама рисуется обходом точки в форме квадрата, а если обходить по треуголнику или пятиугольнику?

Сохранится тонкая структура линий?

Думаю, что скатерть изменится, но по сути как тонкая структура сохранится, т.е. линии будут, но в другом месте, но точно будут.

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

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, утратили силу. Это не поправки, а новый документ: в начало добавили три пункта, и дальше вся нумерация сдвинулась на три.

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