Дайджест Новостей

Статья объясняет, почему в инвестиционных проектах конфликтуют два контура управления — проектный (работы, сроки, риски, результат) и финансовый (движение денег, учёт, доходность). Из-за этого бывает, что отчёты «зелёные», а на площадке монтаж ещё идёт, а деньги не перечислены, и запуск сдвигается. Разбираются ключевые показатели: CAPEX, OPEX, NPV, IRR и потребность в финансировании, с примерами про 100 млн вложений, ставку дисконтирования и приведённую стоимость 120 млн, полученных раньше или позже. Также приводится таблица распределения данных между системами (финмодель, ERP, ИСУП, документооборот). Далее на примере продукта Directum Projects идёт 8 шагов: обоснование инициативы с рисками, паспорт проекта с NPV/IRR, связка фаз по Stage-Gate с контрольными точками, привязка платежей к работам и вехам, оценка изменений и сравнение версий плана при удорожании CAPEX с 5,2 до 5,4 млрд, проверка влияния на портфель через сводный отчёт, проверка результата после запуска и автоматизация через интеграции. В P.S. автор прямо приглашает обсудить, насколько пример близок к реальности. По сути это лонгрид-демонстрация возможностей вендорской ИСУП с полезной общей методической частью в начале, но с явной маркетинговой целью продвинуть конкретный продукт; новостной и прорывной ценности нет, злободневных политэкономических или остросоциальных тем тоже нет.

По сути это не статья и не новость, а куцый форумный выкрик: заголовок-намёк про «технарей» с мультиметром (цешкой), а сам текст — одна фраза-вопрос «Что думаете? По линии помощи ЕС, гуманитарка на весь подъезд». Ни тезисов, ни фактов, ни источника, ни контекста — что за помощь ЕС, кому, в связи с чем и почему «на весь подъезд», из текста не следует. Похоже на ироничный комментарий о раздаче евросоюзной «гуманитарки» на дом/подъезд, но никакой конкретики, которую можно было бы пересказать или оценить, здесь нет. Информационная ценность нулевая, аналитики и аргументов нет, читателю сообщать нечего.

Студент (или сотрудник) ИТМО сделал неофициальный сервис rasp.ifmagic.ru, который превращает расписание из приложения/кабинета my.itmo.ru в подписку для календаря: ICS-ссылка или read-only CalDAV. Мотивация — расписание живёт отдельно от личного календаря, переносы пар в приложении легко пропустить (автор так пропустил занятие из-за переноса аудитории). Подключение через номер ИСУ и пароль (пароль не хранится, дальше токены в шифре) либо через свои токены сессии, чтобы сервис не видел учётку. Сервис только читает расписание, ничего не пишет в ИСУ, аккаунта и оплаты нет, это хобби-проект без SLA. Технически подробно и честно: неофициальный вход в ITMO.ID через PKCE, рендер в ICS и CalDAV по RFC 5545/4791/6578 (SEQUENCE, DTSTAMP, STATUS:CANCELLED с надгробиями, sync-collection, PROPFIND, calendar-query), кэш и sendfile(2) в ядре с ETag/304/Range (заявлено ~10 300 rps на попадании), дедупликация задач через FOR UPDATE SKIP LOCKED (один поход в ИТМО вместо N), устойчивость при падении my.itmo (отдаёт последнюю версию, freeze при усечённом ответе), метрики в формате Prometheus, стек Go 1.27 + PostgreSQL, distroless. Настраиваемые интервалы обновления (30 мин — 6 ч) и напоминания. Открытые аудиты по безопасности и производительности в репозитории. Ограничения перечислены прямо: неофициальность, отсутствие поддержки 24/7, глобальные напоминания в Google Календаре. Социально-полезный нюанс: ещё в 2022 году в ИТМО был внутренний конкурс ITMO.FUTURE 3.0, где инициатива «Синхронизация расписания с внешним календарём» заняла второе место, получила исполнителя решением экспертного совета от 14 апреля 2022 года, а команда my.itmo обещала сделать функцию сама — но официальной подписки нет до сих пор, спустя больше четырёх лет. По сути — не реклама (сервис бесплатный, некоммерческий, с самокритикой и честным дисклеймером), а технический разбор личного хобби-проекта с элементами институциональной критики. Полезно и актуально для студентов ИТМО и интересно технически, но узкая ниша и нет широкой новостной значимости.

Глава «Росатома» Алексей Лихачев заявил, что Россия планирует разместить атомную энергоустановку на Луне к середине 2030-х годов для создания полноценной внеземной станции. Проект разрабатывают «Росатом» и «Роскосмос», о плане впервые сообщалось в июне 2026 года. Ранее речь шла об установке мощностью до 10 кВт, массой не более 1200 кг и сроком безаварийной работы не менее десяти лет; она должна выдержать запуск, вакуум, радиацию и лунную ночь с температурой до −150 °C. Далее автор переходит к спекулятивной части: по мере роста постоянной лунной инфраструктуры там появятся энергетика, транспорт, связь, навигация, передача данных и автоматика, а значит, и сеть, которую теоретически можно атаковать. Лунный DDoS описан не как мгновенное отключение базы, а как постепенная деградация связи: запаздывание телеметрии, рост очередей данных, отвал второстепенных сервисов и потеря оператором на Земле понимания происходящего. Упоминаются распределенная архитектура, резервные маршруты и DTN, а также сценарий, где атака уже закончилась, но Земля продолжает получать данные из накопившейся очереди. Фактически материал — новость о лунной АЭС плюс анонс отдельной статьи о сетевой безопасности на Луне. Практической конкретики по DDoS нет, тема скорее футурологическая и кликбейтная, хотя сама новость о лунном энергоблоке значима.

Автор — инженер по безопасности архитектуры RISC-V в Syntacore — даёт обзор аппаратных механизмов защиты, уже реализованных или обсуждаемых в RISC-V, с акцентом на микроконтроллеры и встраиваемые системы. Напомнив историю архитектуры (зародилась в 2010-м в Беркли у Дэвида Паттерсона и Крсте Асановича, первая спецификация 2014 года, то есть архитектуре всего 12 лет), он объясняет её главное преимущество — принцип «ядро плюс модули»: базовые наборы команд RV32I/RV64I/RV128I дополняются расширениями (M — умножение, A — атомарные операции, F/D/Q — плавающая точка, C — сжатые инструкции, B — битовые операции, V — векторные), что позволяет собрать процессор строго под задачу без лишнего. RISC-V применяется в IoT, АСУ ТП, промышленной и медицинской электронике, системах безопасности, перспективны автомобильная электроника и ИИ. Главный барьер — молодость архитектуры: жизненный цикл микроконтроллера около 10 лет, и заказчики сомневаются в зрелости решений, хотя по набору угроз (софтверные уязвимости, атаки по побочным каналам, glitch-атаки, декорпусирование, дыры в протоколах) RISC-V не хуже других. Далее разбираются конкретные механизмы. PMP (Physical Memory Protection) задаёт до 16–64 регионов доступа хартов к физической памяти, не обходится никаким обращением и после конфигурации не переписывается; расширения smepmp и smap/smep закрывают доступ из привилегированных режимов. IOPMP защищает физическую память от злонамеренных устройств через DMA, поддерживая до 65 535 устройств и до 63 доменов (полная модель сильно бьёт по производительности). Landing pads (инструкция LPAD, отслеживание ELP) и shadow stack убивают целые классы атак — ROP/JOP/COP-гаджеты и перезапись адреса возврата, — но требуют пересборки библиотек компилятором с поддержкой. MMU даёт виртуальную память (SV39/SV48/SV57), IOMMU защищает виртуальное адресное пространство от недоверенных устройств двухэтапной трансляцией. Тегирование памяти пока не принято в спецификации (описана лишь база на pointer masking и zimop для 64-бит: 7 свободных бит адреса используются как «ключ-замок», что закрывает use-after-free и выход за границы). Спекулятивные барьеры Zisb позволяют вручную ограничивать спекуляции и не допускать утечек секретов по побочным каналам. RISC-V Worlds (развитие WorldGuard от SiFive, наследующего ARM TrustZone) делит систему на миры с World ID и чекерами на каждом пути к памяти, обычно не более восьми миров. CHERI требует дополнительные 32/64 бита на capability и очень ресурсоёмок. Автор честно перечисляет цену: рост площади кристалла (бывают случаи удвоения), требования к поддержке в компиляторах, библиотеках и загрузчиках, падение производительности (особенно IOPMP). В финале — вывод, что RISC-V хорош именно для микроконтроллеров, аппаратная защита уже есть, а рынок активно растёт, в том числе за счёт китайских процессоров, и что нейросеть уже сгенерировала работающий процессор за 12 часов. Статья завершается вакансиями Syntacore, то есть по сути является ещё и материалом для найма. Материал содержательный и технически корректный, хорошо систематизирует защитные расширения RISC-V и их стоимость, но это довольно обзорный, не новостной текст с элементами продвижения работодателя и без прорывной или остроактуальной повестки, поэтому оценка умеренная.

Статья разбирает направление Solocraft — адаптацию группового контента классических MMORPG (на примере клиента WoW 3.3.5a и проекта WoW Prime на эмуляторах TrinityCore/AzerothCore) под одиночное прохождение. Исходная математика подземелий и рейдов рассчитывалась на «святую троицу» из 5/10/25 игроков, но демография изменилась: у взрослых игроков дефицит времени, а интерес к старому контенту остался. Автор выделяет три ключевые проблемы. Первая — математика эффективного здоровья (EHP) и входящего урона: боссы заточены под латного танка с внешним отхилом 4000–8000 HPS, поэтому маг или разбойник умирает за пару тиков автоатаки; простое занижение статов мобов ломает челлендж. Решение — динамическое масштабирование характеристик, аккумулирование статов экипировки в общий пул эффективного здоровья, гибридизация талантов (микро-вампиризм, процентная регенерация ресурса от урона для чистых DPS-классов). Вторая — механики гарантированного вайпа: ментальный контроль, смертельные комбо, станы, ледяные склепы, фазирование, которые в норме снимаются союзниками, а в соло ведут к мгновенному эвейду босса. Решается переписыванием триггеров в C++ скриптах боссов: проверка ThreatList.size()==1, замена изоляции на AoE-урон с возможностью диспела или позиционного уклонения, растягивание таймеров энрейджа пропорционально отсутствию остальных участников. Третья — эндгейм-прогрессия: без организационного лага контент проходится быстро, что грозит выгоранием базы; вводятся кастомные инстанс-модификаторы по типу Mythic+ с аффиксами, влияющими на качество дропа, и система экстра-уровней (Prestige/Overcap) за пределами 80-го уровня. Вывод: перевод старой MMORPG в формат соло Action-RPG — это не накрутка статов в конфигах, а комплексная работа со скриптами эмулятора, пересчёт формул защиты и полная деконструкция энкаунтеров, что даёт вторую жизнь устаревшим клиентам и закрывает дефицит свободного времени у игроков. Материал технически содержательный, без рекламы, но узкоспециализированный: полезен преимущественно разработчикам приватных серверов и интересующимся game design, прорывных или общественно значимых тем здесь нет, актуальность ограничена нишей ретро-MMORPG.

GigaIDE Pro как отдельная сборка прекращает существование: на GitVerse вышел единый дистрибутив GigaIDE 2026.1, где набор функций определяется лицензией — при активной подписке доступны Pro-возможности, без неё среда работает в режиме Community. Это упрощает командную разработку: вместо индивидуальных сборок у каждого разработчика ставится один продукт, а возможности зависят от лицензии, роли и сценария. Значительно расширен Community-режим — туда перенесена базовая поддержка фреймворков, ранее доступная только в Pro: Java/Kotlin (Spring, Spring Boot, Spring Wizard, Spring Boot Run, JPA), Python (Django с мастером проектов, run/debug, инспекциями, ORM в Explorer, шаблонами), JS/TS (Node.js, React, Next.js, React Native, CSS с автодополнением, навигацией, форматированием, run/debug через DAP, тесты Jest/NodeJs Test Runner), а также клиент БД (SQL-поддержка, подключение к источникам PostgreSQL, H2, MySQL, SQL-консоль, интроспекция, Explain plan, интеграция с JPA/Spring Data/Django/SQLAlchemy). Часть функций остаётся только в Pro: расширенные источники (GreenPlum, Hive, Spark, ClickHouse, Trino, MongoDB, Ignite), редактирование грида, импорт/экспорт CSV, работа с MongoDB, все прочие функции Pro-режима. Ранее Pro был доступен только юрлицам по заявке — в ближайшее время подписку откроют для всех прямо на GitVerse. Это по сути корпоративный продуктовый анонс от GitVerse (Сбер) в лице PO продукта: полезной технической информации о смене модели поставки и расширении Community-версии достаточно, но статья носит явно промо-характер с призывами скачать, смотреть видео и писать в поддержку; прорывных или остросоциальных тем нет, новость актуальна лишь для узкого круга пользователей этой IDE.

16 октября 2026 г. исполнилось 70 лет со дня открытия АЭС «Колдер-Холл» (графство Камбрия) — событие подано как начало гражданской атомной энергетики, хотя первой в мире АЭС была Обнинская (1954), а Колдер-Холл был первой станцией промышленного масштаба. Факты: станция вырабатывала электроэнергию с 1956 по 2003 год, затем выведена из эксплуатации. Реакторы остановлены, основные источники опасности устранены, лишние здания и сооружения снесены (градирни — в 2007-м, один из машинных залов — в 2026-м). Работы теперь мало отличаются от обычного промышленного сноса: применяются отработанные методы. Цель — освободить дефицитную территорию Селлафилда под следующие этапы очистки площадки. Приводятся парадные цитаты: министр энергетики Майкл Шэнкс обещает «атом нового поколения» на Sizewell C и Hinkley Point C с тысячами рабочих мест; глава Sellafield Ltd Юэн Хаттон говорит о смене ответственности на безопасный демонтаж; глава NDA Дэвид Питти — о сохранении ядерных технологий и рабочих мест. Отдельно рекламируется проект Pioneer Park — «чистый энергетический комплекс» на землях NDA рядом с Селлафилдом, который должен привлечь инвестиции и рабочие места. Существенного анализа в материале нет: это ведомственный пресс-релиз о юбилее, где под праздничной риторикой не упомянуты ни реальная стоимость и сроки ликвидации наследия (Селлафилд — крупнейшая и самая загрязнённая ядерная площадка Европы, ежегодно поглощающая миллиарды фунтов госсредств), ни проблемы хранения отходов, ни причины, по которым британская атомная программа буксовала десятилетиями. Полезной информации для российского читателя почти нет, кроме самого факта продолжения работ по сносу и планов новой площадки.

Автор разрабатывает сервис для Тайного Санты (My Santa) и на примере жеребьёвки разбирает комбинаторику и подводные камни. Главная находка: при обычном способе «перемешать список и перетасовать, если кто-то выпал сам себе» с вероятностью около 39,3% возникают взаимные пары — двое дарят друг другу. Это свойство случайных перестановок, а не баг: в перестановке в среднем 1/2 двойного цикла, вероятность хотя бы одного ≈ 1 − e^(−1/2), и от числа игроков (начиная с шести) она не зависит. Формально правила не нарушены, но в момент вручения оба сразу всё понимают, а в анонимном чате сервиса анонимность рушится мгновенно; то же с тройками. Описаны три распространённых подхода: тянуть бумажки из шляпы (последний в отделе из 8 человек остаётся со своим именем примерно в 9% случаев), перемешать-проверить (нужно ~2,7 попытки, поскольку бесподвижных перестановок ~1/e) и одноцикловая раздача — когда Аня дарит Боре, Боря Вере и так по кругу до замыкания на Аню; замкнутых групп меньше всей компании там нет по построению, реализуется парой строк кода. Дальше про ограничения вроде «муж не дарит жене» или «начальник не дарит подчинённому». Простые пары почти не мешают (6 человек, две пары — подходит 40% кругов), но семьи и отделы ломают всё: 8 человек (семья из четырёх плюс пара) — лишь 2,9% подходящих кругов, 12 человек (шесть из одного отдела) — 0,2%. Тогда включался запасной путь: паросочетание в двудольном графе алгоритмом Куна плюс склейка циклов обменом подопечных (умножение на транспозицию из разных циклов сливает их). Отдельно разобран случай, когда раздать нельзя вовсе — теорема Холла: 12 человек, семеро из одного отдела, а снаружи лишь пятеро, распределения не существует, и сервис честно отказывает с подсказкой либо оставляет игру открытой. Самое ценное — проверка честности. Автор измерил равномерность и обнаружил, что запасной путь (Кун плюс жадная склейка) даёт заметный перекос: некоторые разрешённые круги выпадали до 1,26 раза чаще ровной доли, некоторые до 0,84 реже, тогда как у перемешивания это был лишь шум. Запасной путь включался часто: в семейной игре на 20 человек в 57% случаев, при шестерых из одного отдела — в 87%. Починка — одна строка: бюджет задан не в 64 попытках, а в ~400 000/n шагов, что даёт вероятность провала порядка e^(−70), после чего перекос ушёл в шум. Приведены замеры времени (микросекунды на обычную жеребьёвку, 2–3 мс в худшем случае). В конце честно перечислено, чего нет: равномерности в запасном пути (равномерный выбор случайного паросочетания — задача #P-полная), криптостойкого генератора (используется PCG из math/rand/v2, не ChaCha8 с crypto/rand) и защиты от админа сервера с доступом к базе. Главный вывод — число 64 прожило в коде незамеченным, потому что тесты проверяли допустимость результата, а не равномерность; вопрос к читателям — есть ли дешёвый способ равномерно выбирать случайный гамильтонов цикл при малой доле подходящих. Статья не рекламная (сервис упомянут лишь как контекст), технически честная, оригинальная, с конкретными цифрами, измерениями и признанием собственных ошибок. Не новостная и не социально-политическая, но по качеству и пользе для разработчиков очень хороша и тематику не устаревает.

Статья — практическая заметка UX-исследователя из Контур.Фокус о том, почему качественно проведённое исследование само по себе не приносит пользы продукту, и как встроить его в рабочий процесс команды. Основные тезисы. Исследовательская и продуктовая задача — разные вещи: команда часто приносит готовые гипотезы и вопросы, а на деле ей нужно принять конкретное решение, поэтому брифинг стоит начинать с вопросов о задаче команды, принимающем решение, нужных знаниях и дальнейшем использовании результатов. Исследование не заканчивается презентацией отчёта — после него нужно совместно ответить, что узнали, что это значит для задачи и что делать дальше, причём следующим шагом может быть и отказ от гипотезы. Первый исследователь в команде вынужденно делает две работы: проводит исследования и учит команду с ними работать, поэтому важно вслух подсвечивать проблемы и договариваться о процессах, а не молча их компенсировать. Полезно смотреть шире своей функции и подключаться к другим этапам, например к дизайн-ревью. В финале — советы обеим сторонам: тем, кто нанимает первого исследователя, и тем, кто приходит в новую команду, а также рекомендация искать наставника и не изобретать процессы в одиночку. По сути это мягкая экспертная колонка с общими управленческими и коммуникационными рекомендациями, без данных, кейсов, цифр и методологической конкретики. Никакой новостной, политэкономической или технологической ценности она не несёт; в конце присутствует прямая реклама телеграм-канала, что дополнительно снижает оценку. Для узкого круга UX-исследователей и продактов содержание разумно и адекватно, но новизны почти нет — большинство тезисов давно известны в индустрии.

Автор (в рамках своего открытого проекта humanizer-ru) прогнал 84 рабочих текста через 12 моделей — Gemini 4 Argon, Claude Sonnet 5.5 и Haiku 5.5, GPT-6 Luna и 6.1 Sol, Qwen 3.8 Max и Flash, Kimi K3, GLM-5.3, MiniMax M3, Mistral Large 4, Muse Spark 1.3 — и посчитал типовые «манеры» чат-ботов. Главное: в 32 текстах из 84 модели оставили служебные реплики, адресованные заказчику, а не получателю («Вот готовый вариант…», «Если нужно, могу добавить…»), — такие фразы не нужны в готовом письме или посте. Gemini 4 Argon начинала с «Вот…» в 9 текстах из 10, чаще других давала несколько вариантов сразу (3 из 10) и восклицательных знаков (2,7 на 1000 знаков против 1,1 в среднем). Kimi K3 в 5 текстах из 7 и Claude Sonnet 5.5 в 6 из 10 завершали текст предложением что-то доработать; у Kimi вдобавок самые длинные предложения (13 слов). Mistral Large 4 лидирует по жирному (8,5) и заголовкам (2,2), Qwen 3.8 Max близко по жирному (7,7), MiniMax M3 — по эмодзи (3,6), а у Claude Haiku 5.5 заголовков не было вовсе. Qwen 3.8 Flash писала самые длинные тексты (в среднем 5735 знаков). Горизонтальные линии «---» встретились в 51 тексте из 84. Отдельный вывод: длинное тире — миф как «примета нейросети». У моделей в среднем 2,5 тире на 1000 знаков, у Гиляровского 2,25, у Герцена 1,59; чаще всех у GLM-5.3 (4,3) и Muse Spark 1.3 (3,9), реже всех у Claude Sonnet 5.5 (0,7). Механическое вычищение тире (как в английском навыке stop-slop) портит русский текст, оставляя рубленые фразы, — тире часто требуется грамматикой. Практические советы: срезать первую фразу-анонс, последний абзац с предложением доработки, линии «---», лишние варианты и избыточное оформление; тире оставлять по грамматике. Автор честно оговаривает грубость метода, разные жанры и малую выборку (4–10 текстов на модель, по одной попытке через API без системного промпта), а сами тексты и навык выложены в открытом репозитории на GitHub. Полезная, конкретная прикладная заметка с открытыми данными и внятными рекомендациями; не реклама услуг, хотя и продвигает собственный проект. Методология местами приблизительна, тема не прорывная и без полит-экономического или остросоциального угла, зато актуальна для всех, кто работает с LLM и «очеловечивает» текст.

Депутат АдГ Максимилиан Крах заявил, что США, закупая российское дизельное топливо, фактически перестали быть нейтральными и перешли на сторону России, запрещая Украине атаковать российскую нефтяную промышленность и финансируя РФ. По его мнению, это приближает завершение конфликта. Он также потребовал, чтобы Германия взыскала с Украины компенсацию за оказанную помощь, назвав это партийной позицией АдГ. Это лишь мнение одного депутата, поданное как сенсация. Конкретных данных о том, что Вашингтон действительно «встал на сторону России», нет — тезис строится на упрощённой трактовке закупок нефтепродуктов. Требование компенсации с Украины звучит популистски, без реалистичного механизма. Новость полезна только как штрих к позиции АдГ, но не даёт анализа или проверяемых фактов.

Статья Иннокентия Бодрова (Product Leader) на учебном, воспроизводимом примере сервиса объявлений показывает, как общая метрика скрывает провал на редком сегменте. На наборе из 1000 карточек (900 из основного потока, 100 из партнёрского API) новая модель B подняла общую accuracy с 93% до 95,5% и сократила очередь ручной проверки с 136 до 113 отправок, но именно на партнёрском фиде recall упал с 80% до 40%: модель нашла 8 нарушений из 20 вместо 16, пропустив 12 вместо 4. Главный тезис: агрегированные accuracy, precision, recall и F1 одинаково способны замаскировать деградацию отдельной группы, поэтому решение о релизе по одной общей метрике недопустимо. При редком положительном классе автор советует PR-кривые вместо ROC. Приведён публичный кейс Jigsaw по классификатору токсичных комментариев Perspective API (1,8 млн комментариев): на коротких комментариях с упоминанием геев и лесбиянок BPSN AUC вырос с 0,57 до 0,82 после коррекции обучающих данных, но проблема не снялась полностью. Также упомянуто исследование hidden stratification на медицинских изображениях. Разбирается проблема selective labels: если модератор видит только карточки, отобранные текущей моделью, у остальных нет метки, и приравнивать «не проверяли» к «нарушения нет» нельзя — среди непроверенных и прячутся FN; нужна независимая полная разметка либо веса. Отмечены риски малых срезов (20 нарушений — один пропуск меняет recall на 5 п.п.), необходимость фиксировать версию правил модерации и согласованность разметчиков, проверять парные карточки парным bootstrap с группировкой по продавцу. Рекомендуются заранее определённые срезы по маршрутам продукта, условия приёмки (например, минимум 75% recall на партнёрском API, непревышение мощности модерации), автоматизация порогов через TensorFlow Model Analysis, а при провале критичного среза — оставить старую модель, усилить ручную проверку или отложить фид. Причина просадки ищется по расхождениям версий на конкретных карточках, исправление проверяется на новых данных. Завершается статья рекламой бесплатного демо-урока OTUS про Data Drift и дайджеста вебинаров.

Автор представляет свой open-source проект genoas — генератор спецификаций OpenAPI 3.1 для Go из комментариев к коду. Предыстория: работая в банке, он столкнулся с тем, что swaggo/swag слабо поддерживал 3.0, а go-swagger3 давно не обновлялся, терял куски спецификации при росте числа ручек и не умел часть вещей (например, ответ строкой). Вместо доработки чужого кода он написал свой. Ключевые особенности: • Вместо хрупких регулярных выражений для разбора свойств тегов используется адаптированный reflect.StructTag со сканером в духе stdlib — устойчивее к пробелам и кавычкам внутри значений. • Комментарии упрощены, позиционные аргументы заменены именованными (description(...), example(20)), реальные Go-типы указываются как есть ([]models.Pet, map[string]int, дженерики). • Два стиля записи свойств на выбор: parensStyle и goStyle (флаг --comment-style). • Целевая версия — OpenAPI 3.1+; поддержка дженериков (включая кросс-пакетные), полиморфизма oneOf/anyOf/allOf, nullable, подмены типов, multipart/form-data по правилам 3.1 с contentMediaType/contentEncoding. • Собственная нотация Content-Type прямо в теге (@Success 200 json ...) вместо отдельных @Accept/@Produce. • Блок @Info можно разместить в любом файле, а не только в main.go. • Внутри — конвейер независимых парсеров, что упрощает расширение и замену частей. • Табличные unit-тесты всех парсеров и детерминированный e2e-гейт (make golden-check) со сверкой с эталонным oas_golden.yml. • Сравнение со swag: genoas экономнее по памяти (~300 МБ против известных OOM у swag на больших проектах), но уступает в зрелости, экосистеме, интеграциях и полноте спецификации. Чего пока нет: discriminator, именованных примеров на уровне media type, @Security на операцию, encoding для multipart, x-расширений, cookie-параметров, webhooks, drop-in совместимости с тегами swag и многого другого. Список открыто признан неполным. Проект писался с февраля практически в одиночку на фоне основной работы, изначальная мотивация (нужды банка) отпала, но автор довёл его до рабочей стадии и просит обратную связь. Это не реклама платных услуг, а честная презентация личного open-source инструмента с прозрачным перечнем ограничений.

Автор размышляет о страдании (мучении) как о состоянии, которое выбивает человека из колеи, лишает продуктивности и толкает на нехорошие поступки. Отсюда его тезис: работа «через мучение» никогда не даёт результата, а тот, кто терпит муку, не отгораживая от неё других, — герой; тот же, кто вешает свою муку на окружающих, — эгоист высшей степени. Далее автор переходит к конкретному поводу: кто-то из страдальцев просит, чтобы его пристрелили. Автор возмущён такой позицией — «здоровые силы» должны держать мир, солдат должен быть накормлен, а остальным, даже голодающим, следует «заткнуться», поскольку их мучения — следствие их же поведения в благополучные времена, а значит, «Божья кара справедлива». При этом он предостерегает от того, чтобы брать на себя грех и убивать страдающего, призывая не тянуть других за собой в пучину. Мысль рыхлая и противоречивая: с одной стороны, вроде бы призыв к состраданию и отказ от «пристрелить», с другой — прямая проповедь чёрствости и презрения к слабым, отказ в помощи тем, кто просит её, подмена милосердия рассуждением «у всех своих дел по горло». Полезной информации, анализа, фактов — ноль, только эмоциональные декларации с обилием грамматических ошибок.

Автор полез в сервис прогнозов загруженности парковок по другому поводу и заметил, что эндпоинт отвечает за две секунды вместо выдачи готового ответа из Redis. Оказалось, что Redis у сервиса отсутствовал восемь недель: контейнер упал с кодом 255, имя перестало резолвиться в докеровской сети, подключение при старте падало, и каждый запрос все это время считался с нуля. Код внешне был к этому готов, но только внешне. В инициализации ловится исключение и присваивается redis_client = None, хотя комментарий обещает заглушку. Дальше каждый метод обёрнут в try, вызывает self.redis_client.get, получает AttributeError у None, ловит его тем же except и возвращает None, то есть неотличимо от пустого кэша. Итог — две строки уровня ERROR на каждый запрос восемь недель подряд, то есть авария не была тихой, но её никто не видел, потому что симптомы отсутствовали: сайт работал, данные были верные, просто пересчитывались каждый раз. Регулярный ERROR превращается в фон, и чем чаще он пишется, тем надёжнее пролистывается. Отдельно разобраны ложные «ок». У класса есть метод get_status с проверкой ping, который вернул бы False, но он не подключён ни к одному эндпоинту. Другой health-эндпоинт отдаёт status: «ok» и timestamp строковыми константами (timestamp вообще из мая 2025 — не менялся 17 месяцев), а nginx-локейшн /health перехватывает путь и возвращает константный 200 OK раньше, чем запрос дойдёт до сервиса. Uptime Kuma следит только за публичным сайтом с таймаутом 48 секунд и проверкой по ключевому слову, так что 11 мс и 2 секунды для него неразличимы. Ни одно из «ок» не лгало про то, что проверяло, — просто ни одно не проверяло ничего другого, а вместе они читались как «всё в порядке». Замеры: промах кэша — полный пересчёт по базе, ~1,9 с; попадание — выдача готовых 150 КБ за ~11 мс, разница около 170 раз. При этом авария была терпимой: TTL ключа пять минут, поэтому даже с живым кэшем раз в пять минут кто-то платит эти две секунды; восемь недель сервис просто работал в режиме «платят все», дав лишнюю нагрузку на базу и медленную карту первым зашедшим. Именно поэтому автор и не заметил — если бы кэш был на критическом пути, он узнал бы в тот же день. Починка: второй Redis не поднимали (на машине узкое место — память), переключились на Redis другого сервиса, поменяв номер базы, чтобы сервисы не затирали кэш друг другу; свой контейнер, том и depends_on убрали. Попутно выяснилось, что docker-compose.yml сервиса вообще не лежал в репозитории, а веса модели доставлялись через docker cp — то есть авария с кэшем была единственной причиной туда заглянуть. Главный вывод: обработка ошибки, возвращающая безопасное значение, осознанно превращает отказ в деградацию, но у деградации нет момента, когда о ней узнают извне, поэтому лог становится единственным каналом, а в лог смотрят по симптомам, которых у деградации по определению нет. Значит, аккуратно обработанный отказ надо мерить, а не логировать: счётчик промахов, доля попаданий — то, что можно спросить снаружи и сравнить с ожиданием. logger.error — не уведомление, а запись для того, кто уже пришёл разбираться. Плюс комментарий описывал намерение сделать работу без кэша штатным режимом, но теста на это поведение не было, и вместо задуманного приложение падало в ту же ветку через AttributeError дважды на запрос. Данные сервиса открыты: 4,6 млн получасовых замеров загруженности парковок под CC BY 4.0. Это добротный инженерный постмортем без рекламы, с конкретикой, кодом, замерами и внятными выводами про наблюдаемость, деградацию против отказа и бесполезность константных health-чеков. Полезно бэкенд- и DevOps-инженерам, тема вечнозелёная, но узкопрофильная и без остросоциальной или политэкономической составляющей, поэтому верхнюю планку не ставлю.

Станислав из «РТК-ЦОД» описывает, как в службе техподдержки из хаоса чатов и личных заметок построили рабочую базу знаний. Сигналы, что БЗ нужна: постоянные повторяющиеся вопросы в рабочих чатах, личные мини-базы у инженеров, бесконечное обучение новичков. Требования к БЗ: быстрый поиск, логичная структура и единообразие оформления, короткие прикладные инструкции вместо тяжёлых мануалов, простой доступ (лучше бот в корпоративном мессенджере, чем VPN плюс куча действий). Структуру автор советует строить не по энциклопедическому принципу, а по убыванию актуальности тематик, хотя на практике почти все ищут через поиск, поэтому много сил ушло на ключевые слова, теги и единообразие терминов. Самые востребованные разделы — полезные ссылки и чек-листы. Первичный сбор информации оказался не главной трудностью: самое сложное — постоянная актуализация. Устаревшее надо архивировать, а не удалять (старая прошивка однажды пригодилась). Куратор не должен работать в одиночку, нужна мотивация коллег: новые статьи приравнивались к группе решённых инцидентов в KPI, проводились конкурсы с призами, вёлся канал с анонсами новых инструкций. За 2–3 месяца написали около сотни инструкций, позже — около тысячи. Аргумент в пользу БЗ: полчаса на статью экономят многократные объяснения целым поколениям новичков. Метафора автора — БЗ это инвестиционный портфель, который работает сам и приносит дивиденды команде. По сути это корпоративный контент-маркетинг от провайдера ЦОД с полезными, но давно известными в индустрии практиками knowledge management — без прорывов, политики и остросоциальной повестки.

NetFix Mobile — открытое Android-приложение для телефонов и Smart TV, запускающее обход блокировок для YouTube, Discord, Instagram, X и локальный прокси для Telegram одной кнопкой. Автор прямо подчёркивает: методы обхода он не изобретает, а оборачивает готовые open-source инструменты — ByeDPI (обход DPI через локальный SOCKS-прокси, приёмы --split, --disorder, --fake, --tlsrec), hev-socks5-tunnel и tg-ws-proxy. Приложение не является VPN: трафик не шифруется и IP не меняется. На Android трафик заворачивается в DPI-прокси через системный VpnService, причём это не удалённый сервер, а локальная обработка. Работают два независимых сервиса: обход DPI (VpnService + hev-socks5-tunnel + ByeDPI на C через NDK) и Telegram-прокси (ядро на Rust, вызывается из Kotlin через JNA, поднимает локальный MTProto-сервер, наружу ходит по WebSocket через Cloudflare). Режимы запускаются кнопкой: только Telegram, только обход, либо оба сразу; приложения для туннеля выбираются по отдельности, сам NetFix из туннеля исключён. Главная фишка — автоподбор рабочей конфигурации «воронкой»: для каждой стратегии делаются настоящие HTTPS-запросы и ответ читается до конца (проверка по объёму полученных данных, а не по пингу, так как DPI часто пропускает рукопожатие TLS, но режет поток), затем быстрый проход по небольшому набору адресов YouTube и Discord для всех стратегий (до 30 запросов параллельно), пять финалистов проходят полный набор адресов, десять лучших перепроверяются на конкретной сети и ранжируются; можно вставить свою строку аргументов, результаты экспортируются и импортируются. Стратегии хранятся и подбираются отдельно для Wi-Fi и мобильной сети (сеть запрашивается через NetworkRequest с TRANSPORT_CELLULAR и флагом NOT_VPN, ожидание до 90 секунд), при смене подключения стратегия переключается сама. В Telegram-прокси на Rust реализованы пул заранее открытых соединений (чтобы не «висели» первые фото), сброс пула при смене сети и переключение на прямой режим при чужом VPN; подключение — по ссылке tg://proxy в один тап, но настройки внутри Telegram из другого приложения менять нельзя. Есть версия для Android TV с переработанным под пульт интерфейсом на Compose и предложением поставить SmartTube, фоновая работа через foreground-сервисы, watchdog на WorkManager, плитка быстрых настроек. Отдельно описана оптимизация анимированного глобуса на Canvas: ограничение 30 fps с адаптацией под нагрузку снизило нагрузку на CPU эмулятора примерно с 70% до 33%, а медианное время кадра — с 32 до 17 мс. Из ограничений: рабочей стратегии для конкретного сервиса у конкретного провайдера может не найтись, это не VPN, чужой VPN влияет на работу. Статья сочетает личную разработку с реально полезным техническим разбором обхода DPI — тема злободневная и остросоциальная (блокировки YouTube, Discord, Telegram в 2026-м), материал честный, инструменты и код открыты, при этом это по сути продвижение собственного продукта и канала, а ряд вещей (обёртка над чужими решениями, тонкости настройки) уже знаком читателям Хабра.

Мошенники применяют автоматизацию и генеративный ИИ (массовые рассылки, синтез речи, гибкая смена легенды), но защитники используют тот же принцип — scambaiting: подозрительный звонок перенаправляется в контролируемую среду, где отвечает бот с заданным профилем. Его задача — не спорить, а удерживать мошенника в диалоге, вытягивая ссылки, номера, банковские реквизиты, адреса криптокошельков, сценарии социнженерии и названия организаций. Эти данные после верификации становятся сигналами для блокировок, расследований и предупреждений. Австралийская Apate (по данным WIRED, гендиректор Дали Кафар) заявляет о ~350 тыс. ботов и свыше 250 тыс. единиц информации о мошеннической инфраструктуре — но это цифры самой компании, а не независимая оценка. В демонстрации для журналистов бот вёл осмысленный разговор, делал естественные паузы и не соглашался на перевод; некоторые диалоги длятся дольше двух часов. Отдельная блокировка номера слабо помогает: преступники меняют SIM, аккаунты и домены, и только диалоговый бот связывает канал, легенду, реквизиты и временные паттерны в единую картину кампании. Тот же подход в кибербезопасности — LLM-ханипоты. Исследователи ETH Zurich (Марк Веро) с методикой Honeyval показали, что LLM-ханипоты удерживали автономных ИИ-агентов-атакующих примерно втрое дольше правило-ориентированного базового варианта, хотя более долгий диалог повышает риск распознавания ловушки. Реалистичность не равна безопасности, и разговорный слой нельзя подключать к реальной инфраструктуре без изоляции. Данные делят на три уровня: срочные индикаторы (ссылки, реквизиты, номера), контекст кампании (роли, угрозы, шаблоны) и долгосрочные признаки (повторяющиеся инфраструктурные элементы). Бот должен только собирать сигнал, а решения об ограничениях — оставаться за верифицируемым процессом. Ограничения: мошенник может подсунуть ложные реквизиты, менять сценарий, проверять защиту; всё должно работать в правовом поле и изолированной среде. Метрика успеха — не длительность разговора, а доля подтверждённых индикаторов, скорость обработки, число предотвращённых контактов и отсутствие вреда обычным пользователям. Приведены пять практических правил для команд безопасности. Вывод: ИИ удешевляет и усиливает мошеннические схемы, но в защите превращает контакт с жертвой в ловушку и источник разведданных — при условии связки с антифродом, проверкой данных и понятным процессом реагирования.

Автор потерял рабочую переписку и пришёл к мысли, что ИИ-модель переживает похожее на каждом длинном сеансе: контекст сжимается, модель сама решает, что забыть, и потом «тупеет». Он сделал MemShelf — внешнюю память для ИИ-агента в виде MCP-сервера. Это git-репозиторий с Markdown-файлами, где единица хранения — эпизод: что делали, какое решение приняли, какие альтернативы отклонили, где ошиблись, что осталось доделать. Похоже на work log, но эпизод описывает сессию целиком, включая то, что не попало в коммиты. Эпизоды берутся из ночных и дневных смен Claude Code по 28 репозиториям, из решений по диспетчеру и шине между сессиями, из хоумлаба, из экспериментов с пререгистрацией и из студенческого фидбэка. К середине сентября набралось 230 эпизодов, около 150 — итоги рабочих сессий; основные замеры сделаны на 38-й день, когда было 157 эпизодов. Проблема сжатия контекста описана так: пока беседа влезает в окно, всё нормально; когда перестаёт, агент автоматически сжимает историю и может выбросить нужное. Уменьшать окно вредно — сжатие срабатывает чаще. Практический «пол» — 200–300 тысяч токенов, потому что заметная часть окна занята до первого слова пользователя: системный промпт, инструменты, MCP-серверы. У автора в медиане 38,6 тысячи токенов, из них 32 тысячи — сам клиент. MemShelf не отменяет сжатие, но забирает у него главное решение: вместо автоматического «что важно» человек сам закрывает сессию эпизодом и кладёт его на полку. Механика: агент замечает, что тема закрыта, и предлагает зашелвить. Он пишет дайджест и секции, инструмент проверяет контракт дайджеста, вычищает известные секреты по POLICY.patterns, коммитит только файл эпизода. Человек смотрит diff и коммитит или открывает PR. Бот рендерит INDEX.md, ledger.tsv, .meta.json, stats.svg на main. Doctor проверяет схему, контракт дайджеста, секреты, учёт, раздутый индекс и блокирует push при ошибках. В контекст агента едет не вся полка, а только INDEX — по строке на эпизод. За телами эпизодов агент идёт через recall, если решит, что нужно. Дайджест — контракт не больше 120 слов, с маркером решения вроде «выбран», «отклонён», «решено»; для сессий обязательна секция Timeline. Плюсы читаемой памяти: её можно поправить до того, как она станет памятью, через PR/CI; её можно читать из другой модели — автор проверил на Claude Code и Gemini CLI, оба видели одно и то же рабочее дерево git; она работает как протокол и материал для расследований. Но при росте начинаются проблемы. Индекс и дайджесты сами занимают контекст: на 38-й день INDEX весил 8 045 токенов, вместе с дайджестами — 36,6 тысячи, почти пятая часть окна в 200 тысяч. Прирост — 4,8 эпизода в день и 1,1 тысячи токенов в день. Параллельные записи из разных сессий давали конфликты в четырёх производных файлах. Лечение оказалось архитектурным: эпизод — единственный источник, всё остальное рендерит бот; две сессии больше не конфликтуют. Полку разделили на общую и проектные, и типичная сессия стала стоить около 6 тысяч токенов вместо 36. Отдельно автор разобрал экономику токенов. Медианная сессия — около 60 тысяч токенов, её дайджест — 184. За 38 дней было 27 обращений к полке, в среднем по 1 212 токенов; одна секция может стоить десятки токенов, например Decisions — около 60 вместо 60 тысяч. За 30 дней база составила 1,63 млрд токенов, или $1 487 в API-эквиваленте при подписке Max 20x за $200. 97,4% — чтение кэша; внутри него 76,5% — накопленный диалог, 18,8% — статический префикс, 4,7% — выдача инструментов. Главный вывод: платишь не за содержимое, а за время, которое токен провёл в контексте; накопление растёт квадратично. Эксперименты с autoCompactWindow: при 100 тысячах сжатие приходило каждые 3,7 минуты, при 200 тысячах — раз в 15,7 минуты. Автор оставил 200 тысяч и отказался от ultracode в пользу xhigh. Расход на ход упал с $0,2379 до $0,0895, средний контекст — с 283K до 97K, максимальный — с 996K до 166K. Но вклад самой полки в экономию оказался нулевым: тяжёлые контексты обрываются на 159–166 тысячах, то есть экономию дали порог сжатия и отказ от ultracode. Полка же стоит 36,6 тысячи токенов постоянно, и 84% этой стоимости приходилось на 132 эпизода, к которым автор ни разу не вернулся. Кэш и полка решают разное: кэш дешевле, но не меньше, и живёт минуты; полка живёт между сессиями и вендорами. Главный вывод статьи: записать — не значит вспомнить. Запись — событие, чтение — нет. 14 августа ассистент не воспользовался эпизодом, который лежал на полке с 4 августа, потому что инструменты MemShelf были отложенно загружены, а правило «сначала прочитай полку» лежало внутри INDEX, который виден только тому, кто уже открыл полку. За шесть дней — 4 обращения против 23 записей. Поэтому автор добавил правило в инструкции проектов и пользовательские настройки, сделал скилл /shelve и хуки SessionStart, SessionEnd, PreCompact. Хук убирает само решение «идти ли в память». Код открыт: memshelf-mcp, MIT, пакет на PyPI, формат полки описан в shelf-spec; есть подключение к Claude Code, Claude Desktop и CLI-цикл. Инструменты: init, shelve, lint_digest, import, index, recall, search, stats, advise, rebuild, rollup, purge, resolve, doctor. Статья не рекламная в обычном смысле: это подробный отчёт автора open-source-проекта с замерами, провалами и честным признанием, что полка не дала заявленной экономии и почти не использовалась. Полезна тем, кто работает с ИИ-агентами, контекстом, MCP, Claude Code и хочет понять реальную цену «внешней памяти». Актуальность высокая для 2026 года, адекватность и прозрачность тоже высокие, но тема всё же нишевая и местами перегружена деталями конкретного проекта.