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

Есть такая традиция - "велосипеды изобретать". Очень часто при интеграциях с другими информационными системами обращаю внимание на то, какие подходы там используются в части управления процессами согласования или другими действиями над рассматриваемым объектом: где-то делают только уведомления ("вам пришёл документ на согласование"), где-то для каждого документа отдельный уникальный тип задач, где-то подключают BPMN, а где-то не делают вообще ничего.

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

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

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

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

Самая практическая часть: как на реальном примере автоматизировать ввод активов, сканирование и контроль состояния через связку CMDB и VM-системы, как связать серверы с недопустимыми событиями и выстроить патч-менеджмент так, чтобы кнопка “пропатчить все” не привела к катастрофе.

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

Раньше большая часть инженерной работы происходила внутри задач, коммитов и проверки кода. Теперь между постановкой и итоговым кодом возникает отдельное производство: агент исследует проект, строит план, пишет реализацию, запускает проверки; человек возвращает результат, меняет навыки, переключает модель, правит harness и принимает решения. Но трекер задач продолжает показывать одну строку: «задача у разработчика».

Из-за этого агентная разработка пока масштабируется странно. У каждого человека появляется всё более сильный персональный заводик, но команда не получает общего производства. Она видит продукт, не видит способ его изготовления — и поэтому не может этот способ измерять, сравнивать, передавать и улучшать. Компания не станет AI‑native, пока эта работа остаётся невидимой и развивается на ощущениях.

Всем привет!
Я порядка 15 лет занимаюсь администрированием СУБД, а в данный момент работаю на должности старшего инженера по базам данных.

За свою карьеру мне довелось попробовать в работе разные системы мониторинга СУБД, но больше всего мне нравился Spotlight for SQL Enterprise. Это, наверное, лучшая система мониторинга, с которой мне доводилось работать.

К сожалению, Quest Software ушел из РФ, и компании, которые вынуждены соблюдать санкционные режимы, больше не могут им пользоваться. В попытках найти близкие альтернативы я понял, что ничего похожего на рынке нет, и понял: вот она, ниша, в которой можно проявить себя и применить весь свой опыт! :=)

Так появился Lumen.

Сначала — об архитектуре.
Lumen имеет аналогичную архитектуру со Spotlight, есть Diagnostic Server который устанавливается на Windows host. В нем настраиваются подключения к целевому серверу. На целевой сервер ничего устанавливать не нужно, необходимо лишь наличие прав на стороне сервера.

Распространённых транспортов у MCP два, а Copilot Studio поддерживает один - Streamable. SSE в документации помечен как deprecated, и после августа 2025 года Copilot Studio его для MCP не поддерживает - сервер на SSE переделывают до всякой настройки. По документации Microsoft у готового сервера три пути подключения, три типа аутентификации и три режима внутри OAuth 2.0, а доступ агента к серверу и его инструментам заодно регулирует политика данных на коннекторы Power Platform, если такая политика в тенанте есть. Разбор построен на двух страницах learn.microsoft.com, сверенных 4 сентября 2026 года: в нём три места, о которых документация молчит, и по одному из них ответа у меня нет.

В этой части мы вернёмся к работе, которую предыдущие главы принимали как готовую: упаковке. Сначала найдём скалярную ловушку в упаковке B, затем используем ZA как машину транспонирования, после этого разберём 128-битный случай для комплексных чисел и правило корректности для общего PACKM_KER. В финале соберём весь цикл одной дугой: от FMOPA до работающей субконфигурации BLIS для Apple SME.

Недавно мне пришлось объяснять племяннику простейшее 2x + 4 = 10. Я уже собирался произнести школьное «переносим четвёрку вправо с противоположным знаком», но внезапно поймал себя на вопросе: а почему она вообще должна менять знак?

Если ребёнок воспринимает = как портал, через который числа проходят и магически меняют свойства, возможно, проблема не в математике, а в способе её объяснения.

Из этого вопроса вырос MathRoots — мой эксперимент с математикой как dependency graph: от ответа можно проваливаться вниз до операций, свойств и совсем фундаментальных понятий, искать root cause ошибки, визуализировать формулы и спрашивать у каждого шага: «Почему я вообще могу это сделать?»

В статье покажу, во что превратилось обычное 2x + 4 = 10, зачем математике debugger, причём тут AST и как всё это в итоге доросло до React, AI и Docker.

Если честно, это один большой кликбейт, и я крайне не рекомендую вам сюда жать.

Во-первых, это очередная статья про DLSS 5. Во-вторых, вы и так знаете, как я заставил его работать на Nintendo Switch OLED!

Всем привет! Решил поделиться с вами опытом написания и проведения ревью аудит‑политики Kubernetes.

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

Недавно я сел перечитать собственный конфиг на ~580 строк — собирал его из нескольких источников, в первую очередь опираясь на Kubernetes Threat Matrix. Хочу поделиться не столько конкретными находками (так как они специфичны для конкретного кластера), сколько принципами и типовыми ловушками, которые всплыли в процессе ревью. Если вы пишете или проводите ревью политики аудита для своего кластера — этот чек‑лист вполне сэкономит время.

Что мы увидим, если посмотрим на монитор разработчика в разгар рабочего дня? Там наверняка будет открыта IDE, Git, таск-трекер, документация, корпоративный мессенджер. И еще какая-нибудь мелочевка — в зависимости от того, что принято в команде.

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

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

В Stack Overflow Developer Survey 2025 разработчиков впервые попросили посчитать, сколько отдельных инструментов они используют в работе. Из 27 378 ответивших 54% назвали шесть и более приложений или платформ. Операционная система и браузер в этот подсчет не входили. Для сайд-проектов картина оказалась несколько другой —  65% из 25 391 разработчика используют пять инструментов или меньше.

Согласитесь, шесть инструментов — не так уж много. Особенно если учесть, что речь, вообще-то, идет про современную разработку.

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

В словарь добавляют 101 ключ — поиск занимает 8 763 наносекунды. Добавляют 102-й — 718.

Ключей стало больше, а времени в 12 раз меньше. Разбираемся, что происходит на 102-й вставке.

На рынке ML-автоматизации сложился заметный перекос: одни и те же вопросы всплывают у клиентов и у интеграторов снова и снова, но ответы на них редко формулируют вслух. Эта статья является попыткой сформулировать их системно.

В материале представлены мои наблюдения и выводы, основанные на практическом опыте работы в B2B white-label и в B2C в формате ИП, подкрепленные свежими исследованиями по теме. Будет полезно тем, кто на стороне заказчика принимает решения об ИИ-автоматизации, и тем, кто такие решения строит.

Интеграция 1С с сайтом, мобильным приложением, CRM, WMS или корпоративной платформой редко ломается на первом запросе. Отправить JSON в HTTP-сервис и получить ответ умеет почти любая команда. Настоящие проблемы начинаются позже: внешняя система узнаёт внутреннюю структуру справочников 1С, повторный запрос создаёт второй заказ, зависшая база останавливает всю цепочку, а источник ошибки приходится искать по журналам трёх систем.

 Поэтому вопрос сегодня звучит не так: «Можно ли подключить 1С к современному стеку?» Можно. Платформа поддерживает HTTP- и web-сервисы, обращения к внешним HTTP-ресурсам, JSON, XML, OData и другие способы обмена. Вопрос в другом: как построить интеграцию так, чтобы обновление конфигурации, рост нагрузки или временная недоступность одного сервиса не превращались в аварию.

 Задача не потеряла актуальности с появлением ветки 1С:Предприятие 8.5. Финальная версия 8.5.1 вышла в конце декабря 2025 года. Следующей версией фирма «1С» объявила сразу 8.5.4 — в неё вошли задачи, ранее запланированные на 8.5.2 и 8.5.3, часть задач перенесена в 8.5.5. План 8.5.4 обновлялся в течение 2026 года, но дата выхода на момент подготовки материала не объявлена. Одновременно развивается 1С:Шина: в анонсе версии 9.0 заявлены доступ к телу сообщения как к строке (что удобно для XML и JSON), новый тип узла «Разделитель» и дополнительные способы аутентификации при подключении к Kafka. Новые версии расширяют инструментарий, но не отменяют главного архитектурного требования: между учётной системой и внешним миром должен существовать устойчивый контракт.

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

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

Это вторая статья из цикла про прототип Plyra — мой домашний прототип для которого я еще толком не сформулировал класс, но похоже как будто на Smart Knowledge Mesh или по крайней мере фронтенд для него. В первой я рассказывал про существующие проблемы в работе со сложными и запутанными знаниями и то как я пришел к идее прототипа. Здесь я попробую объяснить идею через сравнение с космосом и тому куда в итоге переедет «клубок» запутанности.

Начну со спорного решения: я храню в базе готовый HTML с Tailwind-классами.

Не Markdown, не JSON-схему блоков, а буквально это:

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

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

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

ML-контур сейчас работает с 13 токенами на бессрочном рынке USDT: LINK, AAVE, FET, FIL, ETH, LTC, PENGU, HYPE, DOT, BNB, DOGE, BCH и SUI. Таймфреймы соответствуют внутридневной торговле: 15, 60 и 240 минут.

Задача этого контура не состоит в замене сканера одним магическим числом. У AltScanner остаётся фиксированная двухосевая оценка. D показывает направление от −100 до +100, а A показывает рыночную активность от 0 до 100. Машинное обучение строится рядом с этой системой. Оно изучает связь признаков с последующим движением цены, но не переписывает веса D и A.

В статье мы познакомимся с Buildozer и научимся собирать APK из python с его помощью. Я собрал готовое решение, как без плясок с бубном и вызова “Богов кодинга” собрать проект.