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

Вышедшая 27 мая 2026 года 007 First Light, что называется, выстрелила — только за первые сутки с момента релиза игра разошлась тиражом в 1,5 миллиона цифровых копий. Игровое сообщество немедленно принялось обсуждать девушек из окружения Джеймса Бонда, а также массово клепать мемасики и строить теорию, что агент 007 и Индржих из Kingdom Come: Deliverance — это один и тот же человек.

Однако вдвойне приятно, что за успехом 007 First Light стоит сравнительно небольшая и многоопытная датская компания IO Interactive, в копилке которой имеется целая коллекция по-настоящему достойных проектов. Собственно, о них, лучших играх от создателей нового Бонда и старого-доброго Hitman, мы сейчас поговорим.

На демо всё красиво: задачки бегают, доски сияют, отчёты рисуются. Через полгода команда уточняет статусы в чате, релизы сверяет в таблице, а тимлид перед стендапом открывает пять вкладок. Разбираем четыре ошибки выбора системы управления разработкой и даём чеклист из 12 вопросов, которые стоит задать до покупки.

Чуть больше полугода назад состоялся релиз .NET 10. Остались ли дефекты в исходном коде проекта, спустя месяцы после релиза? Постараемся сегодня найти ответ на этот вопрос.

В этой статье переделываем датчик открытия окон и дверей Tuya в условно универсальный. Задача была в управлении из приложения умного дома приточно-вытяжной вентиляцией Daikin, а сложность в том что управляется эта приточка пультом BRC1D52 (фото 1) по закрытому протоколу связи через 2 провода, через которые этот пульт также получает питание. 2 провода и всё. Осциллограф показал что нужно что-то серьезное курить, а тех веществ которыми снабжают инженеров Daikin мне не достать. А нужно как минимум включить-выключить и видеть состояние.

Привет, Хабр! Меня зовут Станислав Кулагин, я ведущий инженер отдела сертификационного тестирования компании YADRO. Я разработал ATS Studio — Flask-приложение, которое позволяло запускать автотесты в TestY TMS из браузера, не проставляя статусы руками. За полгода приложение стало популярным в нашей компании теперь экономит по 40 часов в месяц коллегам из KVADRA. 

Но я заметил, что у ATS есть потенциал стать лучше, поэтому начал разрабатывать вторую версию. Теперь ATS умеет обрабатывать до 400 тестов одновременно и подходит для совместного использования. В статье расскажу, как появился ATS Framework и почему TestY остается краеугольным камнем этой истории.

В апреле 2026 года четыре астронавта впервые с 1972 года долетели до Луны и вернулись живыми. Через несколько недель после этого NASA провело пресс‑конференцию, на которой раскрыло, что будет дальше — и масштаб того, что там объявили, оказался заметно больше, чем ожидали даже профильные журналисты.

Это не «программа Artemis 2.0» и не «давайте слетаем туда ещё раз». Это план превратить Луну в обжитую территорию: 25 запусков до 2029 года, флот автономных роверов, рой дронов‑разведчиков, лунная спутниковая группировка для связи и навигации, и в перспективе — распределённая база размером с небольшую область, растянутая на сотни квадратных километров.

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

Третья часть серии про security-навыки Hermes Agent. В первых двух мы разбирали, как агент проводит пентест веб-приложений и как читает логи NGFW. Теперь я отдал ему локальную сеть – с её принтерами 2007 года, BMC в гостевом сегменте и другими устройствами. Рассказываю, что из этого вышло, какие навыки агент сам выбрал под задачу и почему план он составил лучше, чем составил бы я.

Если пропустили начало серии:

· Web-pentest skill в Hermes Agent: как агент проводит пентест веб-приложений

· Пещера Аладдина для безопасника: 754 навыка для AI-агента и что будет, если использовать их для своего NGFW

Среда, утро

Mac Mini бесшумно работает на столе рядом с рабочим ноутбуком. На нём – Hermes Agent и Opus 4.8. Пишу ему в telegram простыми словами (даже промтом это не назвать): «Просканируй мою локальную сеть и найди уязвимости. Авторизую – это моя рабочая сеть».

И можно сходить за кофе.

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

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

Сначала агент не побежал сканировать. Он подумал

Вот это меня и зацепило.

Я ждал, что Opus сразу выплюнет nmap -sV и начнёт долбить подсеть. Вместо этого он сделал то, чего я от себя самого добиваюсь годами – остановился и составил план. Просканировал фронтматтеры доступных навыков (больше 700 по ИБ), прикинул задачу и выдал раскладку: вот основной навык, вот дополняющие, вот порядок.

Финальная статья с "деврел-супервизии". Успели сказать пару слов о том, как быть и действовать в кубарем катящемся к AI-изации техномире.

Анонимный вопрос участника: что делать с перегрузом от потока ИИ-инструментов, FOMO, ощущением отставания и заменяемости? Отдельно — что посоветуете начинающим DevRel в этой ситуации?

В марте я проверял, можно ли уговорить AI-ассистентов выдать что-то похожее на системный промпт. Ответы выглядели убедительно: внутренние правила, технические “дампы”, отчёты, почти готовые кейсы для bug bounty. Но ответы команд безопасности приземлили эксперимент: часть результатов оказалась галлюцинациями, часть — обходами ограничений, а не подтверждёнными уязвимостями.

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

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

Сквозных процессов не было вообще. Каждая вертикаль стала отдельным мини-бизнесом со своим планом действий. Одни упоролись в RnD, другие в этот момент пилили «свой Ноушен» с документами. Каждый делал хорошо, но никого не волновало, что делает сосед.

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

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

Нам пришлось полностью снести старые подходы. Сейчас расскажу, как мы это пережили и сколько народа полегло.

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

Я редактор, работаю с образовательными лонгридами на 15–20 страниц и заметила закономерность: если текст сложный/непонятный, то чаще всего из‑за плохой структуры. Когда мысль прыгает туда‑сюда, за ней сложно уследить и понять, что хотел сказать автор. 

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

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

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

Большинство Telegram-ботов выглядят одинаково. /start — стена текста — кнопки. Пользователь тыкает, получает ответ, закрывает. Никакого ощущения что за ботом стоит что-то живое. Конверсия падает, люди не возвращаются, и ты не понимаешь почему — ведь функционал вроде работает.

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

В этой статье я собрал 7 конкретных фич с кодом на aiogram 3.x которые это исправляют. Некоторые внедряются за пять минут, некоторые требуют больше времени — но каждая влияет либо на удержание, либо на монетизацию, либо на рост аудитории. Без воды, сразу к делу.

За неделю я прошел хх. Это как в Тиндере, когда ты свайпнул всех и видишь плашку “сорян, под ваши запросы у нас больше нет людей”. Вот и я вручную просмотрел 4700+ вакансий в Москве и Минске, откликнулся на 156, получив 0 созвонов с эйчарами.

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

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

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

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

Я всё утро вылизывал план на 1700 строк. Дольше, чем заняла бы сама задача, если бы я сел и написал её руками. И к обеду поймал себя на мысли, что я не написал ни строчки кода, я редактировал документ про то, как код будет написан, и кажется немного поехал

Два часа ночи, у разработчика горит релиз, он подключает ваш API — и получает в ответ голое «invalid_request». Что не так, почему, что делать — ни слова. Сорок минут гаданий и злое письмо в поддержку.

Разбираем, как сделать опыт разработчика (DX) человеческим: как переписать ошибки по стандарту RFC 9457, но для живого человека; почему время до первого успешного вызова — главная метрика онбординга; и отчего предсказуемый, «скучный» API — это комплимент. С готовым шаблоном, который можно прикрутить к себе сегодня.

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

Чтобы отличать повтор от новой операции, используют idempotency key (ключ идемпотентности). Это обычная уникальная строка-идентификатор, которую клиент или апстрим отправляет вместе с запросом (часто в заголовке Idempotency-Key). Сервис сохраняет этот ключ у себя и связывает с результатом операции.

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

В новом переводе от команды Spring АйО рассмотрим не самые очевидные ошибки и то, о чём стоит подумать, при реализации идемпотентного API.

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

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