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

Автор «Чистого Кода» и «Чистой Архитектуры» рассказывает про свой нелёгкий путь в AI coding: какие инструменты попробовал, какие шишки набил, к чему пришёл в итоге.

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

Меня зовут Никита Бугуев — я бэкенд‑разработчик на Python в команде, которая разрабатывает открытое банковское API и пытается захватить контроль над всеми интеграциями наружу. В статье расскажу, как мы написали свои велосипеды для вебхуков и какие грабли собрали по пути.

Многие предприятия до сих пор эксплуатируют системы автоматизации зданий (BMS) на базе оборудования Johnson Controls предыдущих поколений. Часто возникает задача модернизации или расширения системы.

Цель данной работы — исследовать механизм обмена данными протокола N2Bus по интерфейсу RS-485 и проверить возможность подключения современных устройств Modbus RTU непосредственно в ту же физическую шину, где "живут" контроллеры Johnson Controls.

Важно: Все приведённые данные использованы исключительно для целей локальной интеграции. Материал предназначен для образовательных и исследовательских целей в контексте интеграции в системы автоматизации зданий.

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

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

****

В 1947 году появилась статья (H. Mann, D. Whitney) (1), где авторы предложили критерий, способный различать два непрерывных распределения. Таким образом, его нулевую гипотезу можно формулировать так: «Обе выборки порождены одним и тем же распределением», т.е. H0: F(t) = G(t), где F() и G() - функции распределения непрерывных случайных величин X и Y, соответственно. Обратите внимание, мы сейчас формулируем равенство именно в терминах функций распределения (cumulative distribution functions, CDF), а не плотностей (probability density functions, PDF).

Что с альтернативной гипотезой? Здесь и начинается путаница. В оригинальной статье альтернатива представлена следующим образом: HA: F(t) > G(t) (или F(t) < G(t), но далее мы, без потери общности, будем рассматривать только первый вариант). Итак, в авторской версии альтернатива состоит в том, что одна из функций распределения мажорирует другую. В более привычном для практики виде это означает, что плотность случайной величины X "смещена" влево относительно плотности Y (рис. 1).

Когда зимой холодает, мы достаём из шкафа зимнюю куртку. Этот дополнительный слой одежды не только спасает от мороза, но и наглядно демонстрирует, как физика, известная уже несколько столетий, сочетается с передовыми достижениями материаловедения.

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

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

Между целями и ресурсами 

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

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

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

Поэтому, когда сотрудник тратит 80% энергии на борьбу с системой, на саму продуктивную работу остается лишь 20%. Формально план выполняется, но цена этому — истощение личных ресурсов. В долгосрочной перспективе это ведет к выгоранию, в краткосрочной — к отказу от любой деятельности сверх минимума. 

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

А если не проверяешь? Replit удаляет базу данных, Claude Code становится инструментом киберпреступников, а твой стартап оказывается взломан за 16 минут.

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

Мне бы хотелось поделиться некоторыми впечатлениями по итогам Всемирного экономического форума-2026 в Давосе. Думаю, что они могут быть полезными для ИТ-специалистов.

Известно, что ВЭФ — это ежегодная встреча руководителей крупнейших финансовых компаний. Тот же Ларри Финк, глава крупнейшего инвестиционного фонда в мире BlackRock, является сопредседателем форума.

Но, что примечательно. В этот раз очень много обсуждений (а самое интересное — это часто в кулуарах между официальными презентациями) строилось не столько просто про искусственный интеллект (ИИ), а какие перспективы у классического ИТ-сектора в связи с этим.

По ходьбе свежие исследования есть. Подтвердились в том числе мои личные догадки и наблюдения. Главное не скорость ходьбы, а то что ты просто ходишь, причём ходишь по 20-30 минут подряд.

На этот раз сфокусировались на пользе для спины и в целом спина-ноги. Набрали людей у которых спина ещё не болела. Тут важно - по статистике, в мире болями в спине 60 - 80%, хотя бы иногда у них болела спина. Поэтому эти 11 194 добровольца, хоть пока спиной не мучались, но многие обязательно могли начать мучаться.

Наблюдали 3 месяца. Те кто ходил в сутки 78 - 100 минут, снизили риск начала болей в спине на 13%.

101 - 124 минуты - на 23%.

125 минут и дольше - минус 24% к вероятности болей в спине.

Исследователи добавили - согласно статистике, лучше просто ходить побольше, чем быстрее, пользы от обычной ходьбы вагон, а рисков нет.

https://www.sciencedaily.com/releases/2025/09/250911073206.htm и https://pmc.ncbi.nlm.nih.gov/articles/PMC12166487/

От ланцета исследование - Daily steps and health outcomes in adults: a systematic review and dose-response meta-analysis

Суммировали 57 научных работ разных лет на тему пользы ходьбы. Вывод - если ходить 7000 шагов в сутки - риск смертности снижается. В частности меньше риск болезней сердца, сосудов, деменции, рака, диабета 2 типа и депрессии.

7000 шагов в сутки, это:

Минус 47% риска смертности от всех причин.

Минус 25% риска болезней сердца и сосудов.

Минус 38% риска деменции.

Начну с ситуации, которая произошла некоторая время назад - встретился я за чашкой кофе со своим бывшим коллегой, десять лет назад он пришел в разработку игр студентом, но объективно не тянул программирование и в итоге пришлось расстаться. Разошлись достаточно мирно, (пусть будет) Кеша ушел сначала в мобилки, а потом в маркетинг игр в смежную компанию, где за прошедшее время поднялся до начальника отряда трудоголиков на галере, но по какой-то своей внутренней мотивации решил в вернуться в большой игрострой, на фоне чего, собственно, мы и пересеклись в кафе. За последние время индустрия не то, чтобы особо прыгнула вперед, но существенно так просеменила некоторый путь в направлении светлого будущего в объятиях аишки, чутка поменялись стандарты, добавились разные помощники и жить в целом стало веселее, а местами даже без кранчей. Но Кеша пришел фактически со знаниями студента последних курсов, зато с большим опытом в игрострое в плане того, как продать уже сделанную игру на последней миле, но статья будет не об этом, а скорее про то, как молодой или уже не очень спец попадает в разработку.

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

С одной стороны у нас движковый, анимационный и gameplay программист это буквально одна из самых дефицитных профессий в индустрии прямо сейчас, чтобы вы понимали в среднем нехватка по студиям больше 20% мидловых и помидорских позиций, т.е. не хватает как минимум одного спеца в каждой команде, куда ни ткни. А ребята из Epic Games, Unity, CD проджектов и прочих крупных студий постоянно жалуются, что не могут найти нормальных специалистов, которые реально умеют работать с современными движками, и они готовы платить безумные деньги (безумные по меркам штатов конечно, в старом свете все более приземленное, но тенденция та же) тем кто шарит в графике или может написать мультипоточный код, который не развалится на проде, или знает, как выжать лишние пару кадров из железа, но людей всё равно не хватает и это при том, что желающих работать в геймдеве очень и очень много.

В прошлый раз мы остановились на том, что в творческом порыве на всём скаку отсекли целый пласт потенциальных возможностей нашкодить при помощи функций стандартных библиотек Lua — доступ к файловой системе и функциям ОС, системным командам и переменным окружения, возможность подгрузки сторонних Lua-модулей и C-библиотек на стороне скриптов и чего только ещё не. Напрочь отсекли.

Настолько напрочь, что существенно осложнив жизнь пытливым умам юных любителей экспериментов, мы сами себе связали руки. Скрипты теперь можно вызывать только со стороны C++, а значит, о гибкости и модульности скриптовой части проекта можно было бы смело забыть.

Горячая работа со стеклом, декоративным или техническим, в наше время обычно выполняется при помощи ручных или стационарных горелок — в их пламени стеклянные заготовки размягчаются и формуются, а края деталей спаиваются. Тип, количество и форма горелок, конечно, сильно зависит от марки обрабатываемого стекла, другого оснащения мастерской, потребных операций и манеры работы мастера, однако, более или менее универсальным вариантом, как и десятилетия назад, остаются горелки настольные, по возможности с большим (для формовки) и тонким (для спаивания) факелом или же горелка большая настольная и малая ручная. Горелка стеклодува — предмет его гордости, основной инструмент, от удобства и безопасности работы с ней зависит многое. Жалеть времени на совершенствование и настройку своих горелок ни в коем случае не стоит, оно сторицей окупится комфортной работой. Ниже представлен отчёт о радикальной модернизации настольной ретро горелки-«пушки» в любительской мастерской, своими руками, без применения станочных работ.

Или почему в споре, где все правы, в итоге не прав никто

Пролог. Вавилонская башня, которая размножилась

Представьте дорогу, где у каждого водителя — собственные правила движения. Один считает красный свет условностью, другой уверен, что его статус или машина дают приоритет, третий просто «не чувствует» знаков. Что произойдёт? Не хаос — хаос ещё предполагает движение. Произойдёт замороженный коллапс: столкновения на полной скорости, после которых участники спокойно объясняют, что аварии не было, потому что «по их правилам» они были правы.

Теперь представьте конфликт, где у каждой стороны — своя священная правда. Одна действует «во имя освобождения», другая — «во имя защиты». Но при столкновении выясняется странное: у них нет врага. Противник не признаётся равноправным участником конфликта, он обозначается как «нацист», «террорист», «марионетка», «недосубъект». Его можно уничтожить, но с ним нельзя говорить. Не из-за ненависти, а потому что общий язык исчез.

Это не метафора. Это повседневная реальность.

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

Проблема не в том, что мы перестали верить фактам.
Проблема в том, что мы отменили саму возможность быть неправыми.

Что мы сделали

Мы разработали диагностический инструмент для анализа этого явления. Он называется «Эпистемология безответственности»/«Epistemology of Irresponsibility» и состоит из трёх частей:

Сегодня расскажем про библиотеку Arrow в Kotlin. Arrow привносит в Kotlin крутые штуки из функционального программирования: типы вроде Either и Validated для работы с ошибками, эффекты для безопасной работы с внешним миром, ну и много всего. Звучит мощно, но когда за это действительно стоит браться?

Мы часто воспринимаем дашборды как красивые визуализации – набор графиков, цифр и диаграмм. Но за этой «картинкой» скрывается огромный объём работы: настройка сбора данных, очистка, согласование метрик, построение архитектуры хранения и только затем — визуальная подача. Аналитик AkademiaDev Сергей Тищенко подробно объясняет, из чего на самом деле состоит путь от сырых данных до управленческих инсайтов.

В 2026 году обновят JavaScript. Окончательный список изменений сформируется из проектов ECMAScript, достигших 4 этапа к марту. Но многие из них уже на заключительной стадии, а другие готовы и доступны в некоторых браузерах и средах. Под катом — что ждёт разработчиков и какие проблемы будут решены в этом апдейте.  

Продолжаю рубрику «Мысли вслух». Цель данной публикации – описать алгоритмы и новизну моих исследований по созданию кластера СУБД с горизонтальным масштабированием производительности – распределенного вычислительного кластера (РВК). Набралась очередная порция материалов в следствие новых изысканий и натурных экспериментов, которыми и делюсь. Сегодня речь пойдет о возможных протоколах работы РВК. Создание распределённого кластера СУБД обычно приносит серьёзные потери в производительности одиночных операций, плюс сложности в разработке, эксплуатации и сопровождении. Цель моей работы – создать РВК без этих недостатков.

Привет, Хабр! На связи снова разработчик из компании АльфаСтрахование. Наша скрам-команда занимается автоматизацией бизнес-процессов Операционного блока, и для решения многих задач нам часто требуются фоновые операции. В этой статье я расскажу о шаблоне фонового сервиса на .NET, который мы используем в своей работе

Наши недавние публикации в блоге Цифрового СИБУРа вызвали оживленные дискуссии. Выяснилось, что ещё для очень многих людей слово «завод» ассоциируется с чем угодно, только не с цифровизацией. Большинство людей видят промышленность как картинку из старого советского фильма: трубы, цеха, большие агрегаты, мужики в форме бегают и что-то делают. Многие уверены, что там используют отсталый стек и вряд ли понимают потенциал ИИ.

Это давно не так, и современные заводы могут сильно удивить цифровизацией процессов, автономностью и минимизацией ручного труда. Для нас этот тезис сам собой разумеется, однако главное правило Хабра: тезис нуждается в доказательствах. И вот с этим есть сложность. Как-то так сложилось, что статей по теме Heavy Digital пока очень мало. Но мы попробуем изменить ситуацию.

С 30 января по 15 марта 2026-го мы открываем на Хабре сезон Heavy Digital — конкурс статей о цифровизации промышленности. Если у вас есть кейс, история из мира современных заводов, разбор решений или интересный научпоп о технологиях на производстве — самое время поделиться этим с читателями.

Мы с командой могли бы запустить продажи бесплатно и всего за два дня. Но вместо этого выбрали всем известную CRM, потеряли 200 000 ₽ и уйму времени на внедрение. 

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