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

Не называйте это пузырём и не вините нас

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

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

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

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

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

Наверняка многие мечтают о том, чтобы никогда больше не удалять старые игры, не разбираться в архивах фотографий и не выбирать, какие фильмы оставить. По крайней мере, я мечтаю. Компания Seagate словно услышала эти желания и выпустила три линейки жестких дисков объемом 32 ТБ для всех задач — Exos, SkyHawk AI и IronWolf Pro. Звучит как мечта любого хомяка данных, но давайте разберемся, стоит ли отдавать за HDD сумму, сопоставимую с ценой топового процессора или 32 ГБ DDR5.

Меня зовут — Антон Карцев, генеральный директор и основатель Флайск. Сегодня хочу поделиться своим опытом внедрения amoCRM и автоматизации найма.

Разберу наш кейс аутсорсинговой HR-компании и расскажу, за счёт каких решений нам удалось сократить операционные HR-расходы и сократить скорость обработки отклика до 4 минут.

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

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

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

Прежде всего обратимся к теоретической базе, в инфраструктуре всегда существуют вертикальный и горизонтальный трафики:

Разработчики восьми дистрибутивов Linux, специализирующихся на предоставлении окружений для запуска компьютерных игр, сформировали рабочую группу Open Gaming Collective (OGC) для совместной разработки унифицированного набора компонентов и продвижения подготовленных изменений в основной состав проектов, образующих открытый игровой стек. К инициативе присоединились дистрибутивы Universal Blue (Bazzite), Nobara, ChimeraOS, Playtron, Fyra Labs, PikaOS, ShadowBlip и ASUS Linux.

Предполагается, что совместная работа над дублирующимися в разных дистрибутивах задачами позволит высвободить время и сфокусировать внимание на развитии специфичной для каждого дистрибутива функциональности. При создании патчей к существующим пакетам участники по возможности будут добиваться принятия подготовленных изменений в основные проекты (upstream), вместо поддержания отдельных наборов патчей, привязанных к поставляемым в дистрибутивах пакетам.

В настоящее время в OGC запущено два проекта - пакет с Linux-ядром OGC Kernel, сфокусированным на оптимальную производительность и эффективность при выполнении игровых приложений, и форк развиваемого компанией Valve композитного сервера Gamescope, включающий поддержку дополнительного оборудования. В составе OGC также планируют совместно развивать фоновый процесс InputPlumber для обработки событий с разных устройств ввода и патчи к различным пакетам компании Valve, используемым в SteamOS.

Дистрибутив Bazzite, основанный на технологиях Fedora Silverblue и оптимизированный для запуска игр, принял решение перейти на использование ядра OGC Kernel, заменить HHD (HandHeld Daemon) на InputPlumber, интегрировать в Steam UI поддержку управления RGB-подсветкой и кулерами, и начать тестирование применения Faugus Launcher в качестве потенциальной замены платформы Lutris.

 linux, игры, сообщество

Автор «Чистого Кода» и «Чистой Архитектуры» рассказывает про свой нелёгкий путь в 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 для работы с ошибками, эффекты для безопасной работы с внешним миром, ну и много всего. Звучит мощно, но когда за это действительно стоит браться?