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

Giga4DQM — открытый проект, реализующий концепцию ИИ-агентов для автоматизированного расследования инцидентов с данными и построения целостной картины зависимостей в существующей БД. Система понимает вопросы на естественном языке, самостоятельно анализирует структуру базы, строит граф зависимостей и формирует диагностические запросы. Архитектура не привязана к одной СУБД: в качестве примера взята PostgreSQL, но подход может быть адаптирован к любой системе с развитым каталогом метаданных. В основе — мультиагентная архитектура на основе GigaChat и LangGraph. Код открыт, доступен для тестирования и внедрения.

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

Занимаюсь разработкой своей игры на Flutter. Дошёл до этапа, когда её пора было показать другу-тестировщику, а у него iPhone. Первая мысль — покупать Mac Mini или подписку Apple Developer за $99 в год. Обе цены платить не хотелось, пока проект не подтвердил, что вообще будет.

На Samsung всё это делается за 15 минут: dev mode, USB, установка. На iPhone пришлось искать схему, которую нигде не находил собранной в одном месте — четыре инструмента, час на реализацию и заметно дольше на то, чтобы вообще понять, что она существует.

Внутри: рабочий пайплайн Tenorshare iCareFone → GitHub Actions → Sideloadly → доверие на устройстве. Полный yml для сборки unsigned .ipa на хостовом macOS-раннере (со всеми нюансами Flutter-версии, precache, packaging и --dart-define для API). Разбор тонких моментов, которые не вылезают в туториалах: bundle ID под бесплатным Apple ID, Firebase-конфиги, миграция macos-latest на macOS 26 в июне 2026.

Отдельно — честная экономика iOS-релиза из России в июле 2026: как теперь оплачивать Apple Developer, когда с 1 апреля отключили мобильную оплату; во сколько по факту обходится 99 долларов через Gift Card, посредников и иностранные карты; и сравнение с Google Play ($25 единоразово), RuStore и AppGallery.

Kadr: видеоредактор, в котором Claude Code монтирует рядом с тобой

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

Привет, Хаброжители! При разработке современных систем, таких как веб-приложения, микросервисы и IoT- устройства, программный интерфейс (API) необходим для обмена данными. Авторы Лукаш Дыновски и Марцин Дулак делятся с разработчиками и архитекторами ПО опытом проектирования и реализации ключевых типов API: REST, GraphQL, gRPC, веб-хуков, WebSocket и других.

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

Эта статья не содержит туториалы по вайбкодингу и не разбирает технически неуспешные кейсы внедрений.

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

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

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

Если вы когда‑нибудь общались с популярными чат‑ботами или заглядывали на Character.ai, легко поддаться иллюзии, будто на той стороне экрана сидит живой человек. ИИ искусно шутит, сопереживает, злится и подыгрывает. Ведёт себя почти как человек. Но может ли за всем этим скрываться настоящее сознание и душа?

Если говорить кратко и прямо — за экраном только пустота и холодные математические расчеты.

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

У LLM нет ни характера, ни настроения, ни личности. То есть ничего того, что свойственно человеческой психике.

Красивый фасад «души» быстро рассыпается в долгих диалогах. В текстовых ролевых играх (AI‑roleplay) это заметно сильнее всего: через 20–30 реплик бот теряет нить разговора, забывает детали и начинает безвольно поддакивать игроку.

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

Вступление: или откуда ноги растут

Если вы когда‑нибудь работали с результатами сканирования OpenSCAP или любого другого OVAL‑совместимого сканера, то знаете эту боль: получаете XML‑файл под сотню мегабайт, внутри — тысячи определений уязвимостей. Открыть его в браузере? Бесполезно. В текстовом редакторе? Глаза сломаешь. В Excel? Он просто зависнет, а если и откроет, то структура будет нечитаемой.

Мне, как сотруднику поддержки, пришлось анализировать такие отчёты по запросу нашей РБ службы. Ну как всегда, им нужно, а мы делаем.

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

В общем, я решил написать свой инструмент. Но есть нюанс: я не фронтенд‑разработчик, мой основной стек — Python и Bash. Писать сложный одностраничник на чистом JavaScript с нуля я бы не осилил за разумное время. Да, когда то водил сайты, понимание есть, но скидок уже не осталось. Поэтому я пошёл по пути современного разработчика — вайбкодингу. А тому же меня натолкнула статья учителя физики. Ссылку не могу дать, не найду уже, который написал собственный инструмент.

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

Так родился OVAL Viewer. Сейчас это полноценное веб‑приложение, которое работает прямо в браузере, без сервера, и закрывает 90% моих ежедневных задач. А ИБ тоже довольны.

Сейчас почти все представляют AI-разработку одинаково. Агент пишет код. Разработчик открывает diff, делает code review и разрешает релиз. То есть мы заменили программиста на AI, но сам процесс практически не изменился.

Но меня не покидает одна мысль. Есть известный принцип утки: если что-то плавает как утка, крякает как утка и выглядит как утка — скорее всего, это утка.

Почему бы не применить этот принцип к разработке? Если после изменений система проходит все тесты, выполняет продуктовые сценарии, не ломает существующее поведение, укладывается в требования по производительности и безопасности, то зачем вообще читать код? Мы ведь никогда не проверяли код ради кода. Мы всегда пытались понять только одно — правильно ли работает система. Раньше это было невозможно без code review. Код писал человек, и только другой человек мог оценить его качество.

Но теперь код все чаще пишет AI.

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

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

А потом проработал двадцать лет. Командами от 20 до 500 человек. В Сбербанке, Соцгорбанке, ЛОКО-Банке, Банке Национальный Стандарт. И понял, что люди в банках делают ровно те же ошибки, что и везде. Только цена у них другая - за спиной деньги вкладчиков и нормативы Центробанка.

Три из них я сделал лично. И видел в каждой новой организации.

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

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

Это, пожалуй, самая сложная часть. Мне пришлось удалить со своего iPhone все приложения для социальных сетей и стриминговых сервисов. Я удалила Instagram, YouTube, Facebook и т. д. Когда я только начинала привыкать к этому, я ловила себя на том, что беру телефон в руки и сразу же замечаю, что чего-то не хватает, ведь единственное, что оставалось делать, — это проверять погоду, читать скучные письма или смотреть состояние счёта в банке. Через несколько дней мой мозг начал перестраиваться, и я перестала испытывать острую потребность сразу же хвататься за телефон, как только у меня не оставалось дел. Я также ношу дешёвые аналоговые часы, чтобы смотреть время на запястье и не доставать телефон.

Дрон летит над карьером на Сахалине. Оператор сидит за пять тысяч километров и пьёт кофе. Между ними — только канал связи, и это в лучшем случае оптика, а в худшем — LTE-модем с одной палкой.

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

Внутри разберём тонкости, о которых обычно молчат в презентациях:

— что на самом деле делает дрон, когда связь пропадает посреди миссии (спойлер: не падает);
— почему "разбить большую миссию на части" — это не арифметика, и при чём тут ветер и швы на ортофотоплане;
— зачем оператору видео с задержкой меньше секунды и почему телеметрия важнее картинки;
— как платформа дружит с ОРВД, ГИС и ERP заказчика — и почему в промышленности побеждает не самый красивый софт;
— и где нам приходится подбирать костыли, потому что не все методы SDK производителя открыты.

Привет, Хабр! На связи команда uFactor, я — Глеб Дубодел, аналитик SOC L1 UserGate. Сегодня расскажу о значимости временных параметров в контексте ИБ и об угрозах безопасности, с которыми можно столкнуться, если не сверять часы.

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

По мере развития компьютерных сетей возникла проблема несогласованности времени на хостах: разница во времени искусственно увеличивала время доставки сетевых пакетов, из-за чего они считались уже недействительными при получении. Для решения этой проблемы был создан протокол NTP (Network Time Protocol). Он позволил согласовать время в сети относительно UTC, с формированием иерархии NTP-серверов.

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

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

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

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

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

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

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

Мы много раз сталкивались с этой проблемой, поэтому решили разработать Attack Replay — открытую утилиту для воспроизведения и модификации сетевого трафика при тестировании СЗИ. Она объединяет в одном интерфейсе функции нескольких популярных инструментов и автоматизирует рутинные операции, связанные с подготовкой и запуском тестов.

В статье покажем, какие задачи решает Attack Replay, как устроен инструмент и какие результаты он уже дал в реальных проектах. А в конце поделимся ссылкой на GitHub с исходным кодом проекта и набором готовых pcap-файлов.

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

Привет Хабр, меня зовут Данила Гуляев, я — методист Linux-решений в АСКОН, и сегодня мы поговорим о развёртывании программных продуктов в условиях предприятий с закрытыми внутренними сетями. Не секрет, что наша активно развивающаяся линейка продуктов для Linux востребована там, где на рабочих местах нет доступа к интернету. Эта статья должна в первую очередь ответить на вопросы технических специалистов таких предприятий.

Дано: сеть из нескольких сотен АЗС. Визуальный аудит качества обслуживания и сервиса (проверяется соблюдение скриптов, стимулирование дополнительных продаж и установок приложения) покрывает несколько процентов смен, остальное не просматривается. Наш клиент хотел увидеть, что происходит в те моменты, которые упущены из виду. Важно: система должна работать на действующих камерах и микрофонах без всякой доукомплектации. Задача: брать архивные записи, автоматически выделять сессии обслуживания и проверять их по чек-листу.

Кассир у микрофона говорит громко и развернутыми фразами. Клиент отвечает коротко, тихо, иногда просто кивает. Стандартный ASR-пайплайн сталкивается с суровой реальностью: в транскрипции остаётся монолог кассира с пропусками там, где отвечал клиент.

Начали с видео. 

Я много работаю с кодинг‑агентами в Claude Code. В какой‑то момент поймал себя на том, что не представляю, на что уходят токены. Счёт в конце месяца есть, а из чего он складывается, непонятно.

Написал небольшую утилиту: она читает то, что Claude Code и так пишет на диск, и раскладывает расходы по статьям. То, что она показала, мне не понравилось.

«Дайте агенту доступ к терминалу и файловой системе, и он сам всё сделает» звучит привлекательно ровно до первого случая, когда агент вместо тестового файла отредактировал конфиг продакшена, или переписал файл с ключами API, потому что тот «мешал» задаче. После этого в компании обычно появляется вопрос от безопасника или тимлида: а как мы вообще контролируем, что этот агент делает с кодом?

Проблема в том, что «контроль над агентом» - это не один переключатель в настройках. Это набор независимых механизмов, каждый из которых ограничивает что-то своё: что агент видит, куда может писать, насколько самостоятельно действует и кто проверяет результат. «Разберём эти механизмы по отдельности на примере того, как это устроено в Veai — агенте, который работает и в OpenIDE, и в JetBrains IDE; в статье возьмём плагин для JetBrains IDE, потому что на нём проще показать конкретные экраны и файлы: так проще говорить предметно, а не абстрактно.»