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

Внедрили таск-трекер для ускорения — а команда стала тратить 40 минут в день на костыли. Рассказываю, как за полтора года у нас накопилось 11 обходных путей, почему онбординг новичков растянулся до трёх недель и что мы с этим сделали. Внутри — чек-лист «тормозит ли вас ваш инструмент» и пошаговый план действий.

Всем привет!

Недавно мне нужно было нанять людей в команду по созданию системы на Python, Java, Go. Для меня крайне важны соблюдения принципов SOLID, Чистой архитектуры, Чистого кода.

Я придумал задачу, которую спрашиваю на собеседованиях в свою команду. И мне хочется поделится ею с вами.

Надеюсь, она будет вам полезна!

Большинство знают базу: создал схему компоновки, написал запрос, перетащил поля в настройки — получил отчёт. Но СКД умеет гораздо больше! И многие задачи, которые решают кодом в модуле отчёта, на самом деле решаются средствами самой компоновки — проще, надёжнее и с бонусом в виде пользовательской настройки.

Разберём механизм и приёмы, которые экономят время и код.

Это вторая часть нашей реализации MCP на Open WebUI, которая строится для целей портфельной аналитики. В прошлой части мы разобрали интеграционную часть нашего решения: как мы пришли к Open WebUI, как использовали статусы в запросах пользователя, как отображаем результаты (чтобы не словить ошибки о слишком больших чанках), как строим графики в интерфейсе и как работаем с запросами пользователей.

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

У вас в GitLab несколько проектов с одинаковым CI? Или просто надоела копипаста в пайплайнах? Каждое изменение нужно отразить в 10 местах? Рассказываем, как сократить код на 56 %, убрать дублирование и сделать один CI для всей группы проектов. Шаблоны, матрицы и практика.

Telegram-группа с топиками как мини-CRM: бот для квалификации лидов на Python, деплой на Yandex Cloud Functions за 0 ₽/мес. Код, подводные камни, Lockbox.

Недавно в Амстердаме прошла конференция Vue.js Amsterdam 2026 — ежегодное мероприятие, посвящённое экосистеме Vite и современным инструментам фронтенд-разработки.

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

В этой статье разберём основные анонсы конференции: Vite 8, Vite+, Void Cloud, а также обновления Vue и Nuxt.

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

Храбрым разработчикам «ВС: Бухгалтерия», «Plazma ERP+CRM», «Ананас» и других «адинэсок» посвящается.

НАСТОЯЩИЙ МАТЕРИАЛ (ИНФОРМАЦИЯ) ПРОИЗВЕДЕН И (ИЛИ) РАСПРОСТРАНЕН НЕИСПРАВИМЫМ ФАНТАЗЁРОМ, ГЕНЕРАЛЬНЫМ РАЗНОРАБОЧИМ ВЛАДИМИРОМ ЛЕВАДНЫМ, ЛИБО КАСАЕТСЯ ДЕЯТЕЛЬНОСТИ СУМАСШЕДШЕГО МЕЧТАТЕЛЯ, ГЕНЕРАЛЬНОГО РАЗНОРАБОЧЕГО ВЛАДИМИРА ЛЕВАДНОГО.

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

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

Что можно сделать, чтобы не терять обращения, продажи и клиентов?
Ответ: Автоматизировать ответы на часто задаваемые вопросы (FAQ).

Автоматизация ответов на часто задаваемые вопросы (FAQ) - один из распространенных способов применения Искусственного Интеллекта в бизнесе.

Раньше клиент был вынужден искать информацию самостоятельно на сайте, в том числе в FAQ‑разделе сайта. Если же вопрос отправлялся оператору, то оператору приходилось самому готовить ответ, опираясь на свой опыт и имеющую документацию.

Теперь у клиентов появилась возможность составлять свой вопрос на естественном языке, и система автоматически выдает ответ, основываясь на соответствующей Базе Знаний.

В итоге клиенты получают быстрые и точные ответы на типичные вопросы и переходят к оформлению и оплате.

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

В этой статье я разберу подход, основанный на JWT (JSON Web Tokens), и покажу, как реализовать полноценную авторизацию в FastAPI — одном из самых быстрых и современных фреймворков для Python. Мы пройдём путь от архитектуры приложения до готового кода, который можно использовать в реальных проектах.

Привет,

Время от времени мою светлую голову озаряют "элегантные решения сложнейших задач", которые почему-то никем не были решены до меня (*сарказм*), и сейчас я поделюсь с вами очередной такой киллер идеей на триллион копеек. Я назвал её "NamedBeacon and Proxy".

Собственно, речь о прокси (proxy) и беконах (beacon— «маяк») для обновляемых смартов на Solidity. Все началось с неудовлетворенности реализацией BeaconProxy от OpenZeppelin:

Современные браузеры тихо съедают экосистему JavaScript живьем.

За последние несколько лет основные браузеры выпустили нативные веб-API, которые заменяют удивительно большое количество утилит, которые мы до сих пор устанавливаем по привычке. Тем не менее, многие разработчики продолжают использовать уже ненужные, но привычные библиотеки. Если зависимость всегда работала, она остается в стеке, даже если браузер уже умеет выполнять ту же работу.

Такой подход обходится дороже, чем кажется. Каждый дополнительный пакет увеличивает вес сборки, затраты на обслуживание, частоту обновления версий и риск отказа от проекта в долгосрочной перспективе. Нативные API-интерфейсы стоят пользователям 0 КБ данных, работают глубоко в движке (часто вне основного потока (main thread)) и используют оптимизации, недоступные библиотекам.

[Текст не для публикации: не нашел как Редакции прикрепить сообщение, эта статья написана в рамках Блога "Институт системного программирования им. В.П. Иванникова РАН"]

Если вы только начинаете работать с требованиями, эта статья для вас.

Бизнес говорит на языке стратегических направлений. «Комплексная трансформация», «синергетический эффект», «актуализация векторов развития» — эти формулировки звучат весомо, но за ними не всегда видна конкретная задача. Как из таких фраз сформулировать понятные требования для разработки? В статье разбираем 6 типичных ловушек и даём конкретные вопросы, которые помогут услышать реальную задачу.

Я работаю разработчиком. Каждый день пишу код, ревьюю PR, хожу на стендапы. Обычная жизнь в 2026 году — только за последние полтора года она изменилась сильнее, чем за предыдущие пять.

Cursor, Claude Code, Copilot. Коллеги из западных команд говорят, что скорость разработки выросла в два раза. Не в полтора — в два. Это не хайп, это реальные цифры от реальных людей.

А потом закрываешь ноутбук и понимаешь: большинство этих инструментов в России либо не работают нормально, либо требуют VPN который отвалится в самый неподходящий момент, либо стоят $20 в месяц которые ещё надо как-то оплатить иностранной картой.

Это меня достало. Поэтому я сделал своё.

Эта статья — не туториал и не обзор. Это история о том, как я искал инструмент для своих задач, не нашёл, расстроился, а потом успокоился и написал свой. Речь пойдёт о Ботинке — консольном AI-агенте для работы по SSH. Но сначала немного контекста.

Я работаю с Linux-серверами уже лет пятнадцать. За это время видел разные эпохи: когда всё настраивали руками, когда появился Ansible, когда все бросились в Kubernetes, когда устали от Kubernetes и вернулись к простым docker-compose. Скрипты-костыли множились, документация устаревала, а сервера как требовали внимания, так и требуют.

И вот теперь добавился ещё один слой — LLM. Можно спросить у модели, как настроить nginx, и получить рабочий конфиг. Можно попросить проанализировать логи. Но каждый раз копировать-вставлять между терминалом и чатом — это отдельный вид боли. Хочется, чтобы модель жила прямо в консоли, понимала контекст сервера и могла сама выполнить рутину.

Статья будет полезна тем, кто:

Работает с серверами по SSH и устал от рутины

Интересуется AI-агентами, но хочет что-то лёгкое и локальное

Имеет ограниченные ресурсы (не у всех есть 24GB VRAM)

Хочет понять, как строится архитектура агента с инструментами

Зачем ещё один AI-агент?

Ситуация знакомая: есть задачи, которые хочется поручить AI — проанализировать логи, написать код, найти информацию в интернете. Но мне нужен был именно консольный агент — работаю в терминале, хожу по серверам по SSH, не хочу отвлекаться на GUI.

На волне хайпа попробовал OpenClaw — хайповый проект 2025-2026 года, self-hosted AI-агент для автоматизации жизненных задач. Идея в целом норм: агент работает 24/7, отвечает в Telegram/WhatsApp, умеет чистить почту, управлять календарём, чекиниться на рейсы. Четырёхслойная архитектура, куча интеграций, активное сообщество.

Но на практике для моих задач оказалось слишком тяжело:

Оверсложнённая архитектура — Gateway, Integration, Execution, Intelligence — это отлично для энтерпрайза, но перебор для «зайти на сервер и поправить конфиг»

Ориентация на lifestyle-автоматизацию — почта, календарь, бронирования. А мне нужно: логи, systemd, docker, nginx

Постоянно висящий сервис — 24/7 демон, который кушает ресурсы. А я хочу: запустил — поработал — закрыл

Мессенджер как интерфейс — удобно для личного ассистента, но для админской работы нужен терминал и SSH

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

Так родился Ботинок.

Ключевая идея: не сервис, а инструмент

Здесь важно остановиться на главном. Ботинок — это не фоновый сервис и не постоянно висящая служба. Это обычное приложение: запустил, поработал, закрыл. Никаких веб-серверов, демонов, системных служб.

Идея пришла из наблюдения за тем, как работают разработчики с Cursor, Windsurf и подобными IDE. Там ты открыв

Domain-Driven Design (DDD) звучит как серебряная пуля. Когда мы начинаем проект на ASP.NET, идея четкого разделения на слои, изоляция бизнес-логики в домене и использование паттернов вроде Repository и Unit of Work кажется идеальной архитектурой.

Но есть один нюанс: магия DDD начинает испаряться ровно в тот момент, когда количество агрегатов (реестров) в проекте переваливает за 30. То, что было элегантным решением для CRM с 10 сущностями, превращается в бюрократический ад для ERP-системы или крупного маркетплейса.

В этой статье я разберу, почему классический DDD в ASP.NET (особенно в связке с Entity Framework Core) становится узким местом на масштабных проектах.

Я просто хотел выложить мобильное приложение и начать зарабатывать. В итоге – блокировка Google-аккаунта, несколько кругов ада с тестированием и квест с выводом денег. Рассказываю, как это было и почему это оказалось сложнее, чем написать само приложение

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

Обычно документацию делают по одному из двух путей – либо используют стандарты, описывающие требования к составу, структуре и содержанию документов (например, ГОСТ 19-й и 34-й серий – ЕСПД и КСАС), либо самостоятельно разрабатывают документ, создавая его на основе собственного опыта или по существующим образцам, в т.ч. взятых из интернета.

Но как же её правильно сделать?

Мой ответ - начинать надо с синопсиса документов.

Когда смотришь на существующие self-hosted мессенджеры, часто видишь одно из двух: либо сложную инфраструктуру, которую непросто развернуть (Matrix/Synapse), либо минимализм без шифрования. ONYX — это попытка найти середину: простой в развёртывании сервер, полноценное E2E-шифрование и режим работы в локальной сети без интернета вообще.