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

В своём блоге я часто пишу о японских RPG. Какие-то элементы этих порой странных, громоздких игр заставляют возвращаться к жанру снова и снова, несмотря на их частую репетативность и времязатратность. Разработчики из Страны восходящего солнца (а также все те, кто пытается подражать игровым или эстетическим элементам их игр) за десятилетия существования этой индустрии сформировали определённый канон жанра. Мы слышим «JRPG» и думаем об аниме стилистике и сопутствующем юморе, запутанной истории, цветастой экшен-боёвке или нагруженной пошаговой системе и, главное, чувстве огромного приключения. В той или иной мере этой есть в любом проекте, который относит себя к этому жанру.

Огромное разнообразие этих игр и фокус разработчиков на каком-то определённом аспекте означают, что фанату жанра никогда не придётся сидеть без дела. Особенно если ему приглянулась какая-то конкретная игра — с огромной долей вероятности это часть какой-то уже устоявшейся долгоиграющей франшизы. Японцы, в отличие от западных коллег, как-то редко хотят экспериментировать вне рамок существующих IP, особенно гиганты вроде Nintendo или Square Enix. Но эти эксперименты или, наоборот, их отсутствие, нередко становятся причиной «гибели» серии. Продажи падают, новичкам не хочется приобщаться к незнакомой серии с большим количеством игр, а «олдам» уже надоело.

Говорить о мёртвых франшизах интересно, но тяжело, хотя бы, потому что и зарубежом, и тем более у нас, о них мало кто помнит, а поиграть самому в них проблематично — игры редко покидали свой родной регион и не были локализированы. Что интереснее, дак это обсудить тех, кто всё смог вырваться из забытия и вернуть себе хотя бы часть былой славы. Тем более что через месяц выходит новая полноценная «Fire Emblem» — яркий пример подобного феномена.

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

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

Привет, Хабр! Меня зовут Сергей Чистяков, в ИТ я с 2006 года. Веду канал в телеграм. Сейчас работаю техлидом в Райффайзен Банке и строю систему автоматизации бизнес-процессов, в которой вместе работают люди и агенты. Расскажу про воркшоп, на котором никто не научился писать автотесты, двухдневный дофаминовый шок и пять маленьких команд, которые начали проводить задачи через весь цикл разработки и построили для этого собственный workflow поверх нескольких репозиториев.

Решение запретить сотрудникам искать рабочую информацию в открытом интернете обычно кажется радикальным — пока не начинаешь считать потери. Один неточный ответ из Google, один лишний запрос в публичный AI-сервис, одна утечка кусочка внутренней информации — и у компании уже есть и риск, и простой, и лишняя головная боль.

Мы рады объявить о выходе Dart 3.13!

В этом релизе мы отмечаем тему, которую любят все разработчики: чистый и легковесный код. Dart 3.13 фокусируется на этом аспекте на каждом уровне работы разработчика. Что касается языка, то первичные конструкторы устраняют повторяющийся шаблонный код, позволяя определять классы в одной строке кода. В инструментах разработчика внесены улучшения, позволяющие dart formatподдерживать аккуратность кода в соответствии с правилами стиля Effective Dart , а также dart pubвведены новые команды рабочей области для поддержания порядка в монорепозиториях. На pub.dev расширенные функции документации, такие как <callout-box>теги и {@example}директивы, делают документацию пакетов более понятной. Внутри системы, оптимизация кода нативных библиотек (tree-shaking @RecordUse) и отложенная загрузка WebAssembly помогают сделать скомпилированные бинарные файлы приложений максимально компактными.

Так что обновите Dart или запустите программу flutter upgrade и следите за обновлениями, пока мы будем изучать новинки Dart 3.13!

Так получилось, что пару десятилетий занимался в тои числе и базами данных. Ставил. Тюнил. Выносил логику В базу. Вынос иллогику ИЗ базы. Поднимал когда падали... Когда перешёл в большой SRE-спорт, почти октаду лет поддерживал экзабайтные аналитические query engine. В общем, развлекался, как мог.

Главное открытие заключалось в том, что почти всё, что считается невозможным, случается. Люди креативны. Ты им дашь регексп -- и они начнут майнить биткойны. Ты им дашь data lake -- и они начнут хранить данные в именах таблиц. Ты им дашь GEO... Сам виноват.

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

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

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

О том, как меняется подход к автоматизации разработки, рассказали инженеры MTC Web Services на митапе для Go-разработчиков. А еще в эфире разобрали несколько практических сценариев, где в одном случае ИИ-агент получает собственную среду выполнения, в другом типовые инфраструктурные задачи выносятся на общую платформу, а в третьем — код создается на основе описания API.

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

Броский заголовок есть, а теперь к сути. Сие ошибка, стандартный привет от дефолтного модуля pion/webrtc в Go. Воспроизводится просто – читаем обычные мануалы по использованию pion, выкатываешь красивый WHEP-хендлер, открываешь пару (ладно, ладно, не пару, просто красивый оборот) вкладок с плеером в браузере, и сервер начинает захлебываться. Хендшейки виснут по секундам, ICE отваливается по таймауту, а в pprof половина флеймграфа забита crypto/elliptic.p256OrdSqr и аллокациям мап внутри движка. Сюрприз? Да никакого сюрприза, если более вдумчиво почитать большинство «туториалов» по WebRTC на Go. Мне кажется, что они впринципе написаны теми, кто никогда не тестировал свою реализацию под нагрузкой даже полсотни одновременных зрителей – максимум пару-тройку потоков и успокоились на этом. Так вот, там на каждый POST-запрос с SDP-оффером создают новый webrtc.NewAPI(), регистрируют дефолтные кодеки, дергают api.NewPeerConnection() и со спокойной душой отдают ответ. На локалхосте, с парой клиентов это летает и работает без проблем. А вот на проде – превращается в катастрофу. Проблема здесь не в самом WebRTC (и уж тем более библиотеке pion`a, она очень крутая) и не в Go. Проблема в том, что глобальную и дорогую «инфраструктуру» создают на каждый(!) запросом, вместо того чтобы просто ее переиспользовать.

Безопасность — неотъемлемая часть конвейера разработки, который работает под высокой нагрузкой и круглые сутки должен быть в состоянии обслуживать много пользователей. 

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

Космическая обсерватория NASA Swift больше 20 лет работает на околоземной орбите, изучая гамма-всплески и другие феномены Вселенной. Несмотря на солидный возраст, научные приборы обсерватории остаются исправными. Однако в последние годы Swift стал терять высоту. Без посторонней помощи аппарат может войти в плотные слои атмосферы и сгореть уже до конца года.

NASA решило спасти работающую обсерваторию необычным способом. К ней отправили аппарат LINK, который должен догнать Swift, захватить его роботизированными манипуляторами и поднять на более высокую орбиту. Но вскоре после запуска проблемы возникли уже у самого спасателя: LINK потерял нормальную ориентацию и начал быстро вращаться. Теперь инженерам приходится сначала спасать этот аппарат, а уж потом думать, что делать с обсерваторией. Давайте разбираться.

В первой статье цикла мы гоняли по 11 тестам Opus 4.8, GPT 5.5 и Gemini 3.1 Pro, во второй устроили дуэль тяжеловесов Claude Fable 5 и GPT 5.5 Pro, в третьей спустились в средний класс и столкнули три поколения Sonnet с GigaChat 2 MAX и YandexGPT Pro 5.1. Закончили мы прошлый материал прямым вопросом: хотите ли увидеть в следующей части DeepSeek и Qwen? Запрос в комментариях мы услышали, так что сегодня на ринге Китай.

Привет, Хабр! На связи Светлана Газизова, APO по ИИ в UserGate. Сегодня разберем один из наиболее актуальных способов распознать дипфейк — по движению волос. Обсудим надежность этого способа, а также поговорим о том, как генеративные модели в целом обращаются с биомеханикой.

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

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

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

Когда нужно прокачать конкретный навык, проще всего начать с практической задачи. В этом дайджесте собрали 39 открытых уроков августа для IT-специалистов: от asyncio, Kafka и PostgreSQL до системного дизайна, DevSecOps и локальных AI-моделей — с разбором инструментов и подходов, которые применяются в реальных проектах.

Привет, Хабр! На связи патентный поверенный UserGate Александр Киселев.

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

Типичные ошибки в патентных формулах хорошо известны сегодняшнему рынку: предельная абстрактность («информационная система», «модуль обработки данных»), отсутствие четко сформулированного технического эффекта, искусственное дробление алгоритмов на псевдотехнические блоки, подмена новизны терминологией. Такой подход к описанию сущности изобретения не развивает технологии и не создает новые, а лишь имитирует изобретательскую деятельность. Абстрактные патенты ничего не привносят ни в науку, ни в практику.

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

Всем привет! Я Ольга Матушевич, преподаватель курса «Нейросети для бизнеса», а в прошлом наставница на курсе «Аналитик данных». Про то, что нейросети «отберут работу», написаны тысячи текстов и сняты сотни роликов. Про обратную сторону — какие вакансии ИИ создал и где рынок труда вырос — говорят реже и обычно без цифр. Чтобы это исправить, я собрала и обобщила данные отечественных и зарубежных источников за 2025–2026 годы и написала эту статью. К сожалению, найти зарубежные источники оказалось проще. Поэтому в статье мало конкретики «как оно сейчас в России», но много информации о мировой динамике рабочих мест или динамике конкретно в США.

Эта история началась банально. Я взял в прокат повербанк сети Energo рядом с кофейней - телефон садился, а зарядки под рукой не было. Дотянул до дома, про устройство забыл напрочь. Через пару дней приложение вежливо сообщило, что аренда автоматически превратилась в покупку, и списало с карты сумму, сопоставимую со стоимостью неплохого обеда. Штраф за утерю как он есть. 

Я расстроился, закинул желтый корпус в ящик с проводами и забыл о нем еще на полгода. На днях, разгребая этот ящик, наткнулся на знакомую коробочку и только сейчас я обратил внимание на деталь, о которой в самом сервисе почему-то активно умалчивают: на боковой грани корпуса красуется стандартный входной разъем Type-C. То есть девайс после выкупа не превращается в бесполезный пластиковый «кирпич», его можно спокойно заряжать дома обычным кабелем от розетки или ноутбука, используя как обычный многоразовый аккум.

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

Из новостей: продажи Against the Storm достигли 2 миллионов копий, Meccha Chameleon разошлась тиражом в 20 миллионов копий, Epic Games продала ArtStation и Sketchfab, Supermassive Games объявила о сокращениях.

Из интересностей: Quasimorph — когда сложность это творческий замысел, как перестать бояться и полюбить ассемблер, простая 2D-трава на WebGPU, на пути к Unity 7.

Пайплайн у вас есть. Он есть у всех: CI перестал быть предметом споров примерно тогда же, когда Docker перестал быть новостью. Именно поэтому разговор пора вести другой - не “зачем вам CI”, а можно ли верить вашему зелёному пайплайну, сколько он стоит и кто им владеет. Разбор в формате “зачем - как - чем - цена отказа” - пилот рубрики: дальше в ней будут другие практики, формат останется.

На Хабре немало статей о том, почему Agile не работает. И в большинстве из них авторы справедливо отмечают, что ритуалы превратились в формальности, Scrum выродился в бюрократию, команды имитируют активность. Всё так.

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

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

Эта статья — не про то, что Agile плох. Она про то, как сделать его работающим.

Привет, Хабр!

У меня есть для вас очень простой способ испортить себе вечер. Поставьте cargo-llvm-lines, запустите на своём проекте и посмотрите не на первую колонку, а на вторую, которая называется Copies. Сверху почти наверняка будет core::ptr::drop_in_place, дальше что-нибудь из Vec, потом хвост от serde. И напротив каждой строчки будет стоять не единица.

Обычная реакция в этот момент: ну да, дженерики, зато быстро, а одинаковые копии потом схлопнет LLVM. Часть действительно схлопнет. Только не тем механизмом, о котором вы подумали, и точно не тем, который вы включили в Cargo.toml.

В статье узнаем откуда берутся копии, почему Vec<u32> и Vec<i32> в бинарнике сливаются в одну функцию, а Vec<u32> и Vec<u64> не сольются ни при каких настройках, что от этого видно в именах символов, как с той же проблемой воюет сам std и куда делась полиморфизация, которую пять лет ждали как лекарство.

Иногда TypeScript думает мучительно долго. У меня это вылезло не самым приятным способом: @_chenglou — он работал над React, ReasonML и ReScript, а сейчас над Midjourney — завёл в моей библиотеке схем issue «Large TS types cause type inference slowdown».

Ну… неприятно. Но я знал, что в системе типов TS люди собирали и не такое, вплоть до Doom, — значит, тормоза лечатся, а не заложены в фундамент.

Дальше всё оказалось довольно механически. Сначала тесты на типы, чтобы ничего не сломать молча: оптимизация типов легко превращает { a: string } в { a?: string }, и никто вам об этом не сообщит. Потом замеры через @ark/attest от создателей ArkType — он считает, во сколько инстанцирований типов обходится выражение, и фиксирует это как бейзлайн, который дальше можно занести в CI. И только после этого — сама оптимизация.

Фикс в итоге оказался на одну строчку. S.Output матчился по всему типу Schema<…> — большому объекту с перегрузками, пересечённому с юнионом всех вариантов схемы, — хотя готовый тип всё это время лежал в соседнем поле ~standard. Достаточно было заглянуть сразу туда.

Извлечение типа стало дешевле в 15.7 раза и перестало зависеть от размера схемы. В статье — таблица со всеми замерами до и после, код тестов и бенчмарков и рецепт, который можно применить к своему проекту.