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

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

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

Какие исследования легли в основу метаанализа

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

ИИ помогает быстрее писать код и проверять идеи, но ускорение разработки не означает ускорение всей системы. Что происходит с тестированием, ревью, метриками и выращиванием инженеров.

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

Давайте сегодня разберемся, как UX/UI встречается с маркетинговой сферой, почему за комфорт в продуктах отвечают именно дизайнеры и как они избавляют от ощущения контроля и слежки.

Код skillmem прошёл два независимых ревью, и я считал его чистым. Потом две модели с разных сторон — Claude и GPT — сорок раундов подряд читали его враждебно, обязанные воспроизводить каждую находку командой. Шесть P1 и около двадцати пяти P2 в коде, который «уже был отревьюен», и главный урок: каждый второй фикс рождал регрессию, которую ловил только следующий раунд.

И снова привет! Я Владимир, технический лидер по развитию сервисов Evolution Data Platform в Cloud.ru и фанат древних рабочих станций, которые несли на себе всю тяжесть цифрового мира 90-х под операционной системой UNIX. В первой части мы сделали длинный экскурс в историю компании Sun Microsystems и ее продукции, посмотрели, что находится внутри рабочей станции Sun SPARCStation 5 и хирургическим путем вылечили ее детскую болезнь, которая препятствовала загрузке и работе.

В следующей части статьи мы погрузились в историю средних веков (UNIX-войны начала 90-х), поговорили в целом о мире коммерческого UNIX-а, установили на Sun SPARCStation актуальную операционную систему Solaris, настроили ее и вышли во «всемирную паутину».

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

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

Проект решил три задачи одновременно: гарантировал выполнение требований законодательства по импортозамещению без потери функциональности, сохранил независимость от конкретного вендора и обеспечил официальную поддержку с SLA. Работа с Хоулмонт позволила реализовать все это и не останавливать развитие проекта даже тогда, когда Camunda сменила бизнес-модель.

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

Модульная архитектура ускорила отклик интерфейса и упростила дальнейшее развитие системы.

Посчитал месяц работы разработчика с AI-агентом по ценам API и подписок на сентябрь 2026: от $87 на DeepSeek до $7 720 на GPT-6 Astra. Почему 82% токенов — это кэш, что ломает кэширование посреди сессии, почему лимиты подписок в запросах обманчивы и сколько на самом деле дают Claude Code, Codex, OpenCode Go, GLM Coding Plan и Ollama Cloud.

Ошибки в аналитических витринах часто скрываются за корректным числом строк и успешно выполненным SQL‑запросом. Разберём, как неправильные JOIN и разный уровень детализации данных искажают суммы, почему DISTINCT не всегда помогает и какие проверки позволяют находить такие проблемы.

Испанец Энрик Бернат Фонтладоса был кондитером в третьем поколении. На его долгий век (а он прожил 80 лет) пришлась Гражданская война и режим Франко. Но именно он стал знаменитым создателем шарообразных карамельных конфет на палочке, озолотивших и прославивших его на весь мир. Речь идет о Chupa Chups.

NBER в недавнем исследовании оценил накопительный эффект AI-инструментов: до 240% больше коммитов, но лишь 30% больше релизов. LinkedIn тем временем пришлось строить отдельную платформу для AI code review, а исследования разработчиков фиксируют сдвиг от написания кода к проверке результата.

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

Во время выпуска стали из конвертера в сталеразливочный ковш температура — 1600–1650°C. В зоне слива жара такая, что металл светится ярко-белым, и любое незащищённое оборудование обгорает мгновенно. Первые попытки сделать систему визуализации контроля наполнения стальковша в прямом смысле сгорели. А задача внести присадки ферросплавов вовремя, чтобы получить нужную марку стали, — никуда не делась.

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

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

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

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

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

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

Мы проследили путь одного изделия — от конфигуратора на сайте до упаковки готового карниза. Рассказываем, как все устроено.

Мне переслали архив с документами и написали, что пароль пришлёт отдельно. Он задерживался, а я по привычке заглянул внутрь посмотреть, что там.

Он открылся. Не файлы - список файлов. Имена, размеры, даты. Пароль потребовался, только когда я попробовал вытащить один из файлов.

Проверил на своих архивах - то же самое. Так работает формат.

В IT я больше двадцати пяти лет, в Android - почти пятнадцать. Оказалось, что этого мало.

Опыт никуда не делся. Я по-прежнему знаю, чем интерфейс отличается от абстрактного класса и в чём разница между val и var. Но работать по-старому стало тяжело. В требованиях всё чаще стояло не знание Kotlin и Compose, а умение вести разработку с ИИ. Не "пробовал Copilot", а именно вести: ставить задачу, разбирать результат, замечать, где инструмент уверенно врёт.

Вместо привычных TDD, BDD, DDD и FDD вокруг всё чаще звучали AIDD и SDD. Дошло до того, что на работе в карточках JIRA появилось обязательное поле "уровень использования ИИ" со значениями "полностью выполнено агентом" и "частично выполнено агентом". Варианта “выполнено самостоятельно” там нет. Намёк понятен.

Назад пути не было, пришло время меняться.

Учиться по статьям смысла нет - там всё получается. Нужен был настоящий проект, достаточно большой, чтобы в нём было где ошибиться.

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

Получилось приложение. Через полгода оно лежит в Google Play, я пользуюсь им каждый день, и это уже давно не учебная работа. Дальше - как оно из неё выросло: через три смены курса (учебный проект стал продуктом, Gemini CLI сменился на Claude Code, маршрутизатор на два выхода стал графом), одну стену, в которую я въехал на полном ходу, и запуск, который не сработал.

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

В этой статье начну с мобильной платформы и довольно простой задачи: заставим робота самостоятельно пройти заданный маршрут.

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

В далеком 2017 году мне передали SD-карту памяти с диагнозом «сломана пополам, вдруг получится что-то с нее считать». Я честно пробовал: восстановил все оборванные дорожки, досконально проверил все соединения и на целостность линий, и на отсутствие замыканий. Положительного результата не получил – карта определялась, но с нулевым объемом. По этой причине она отправилась в ящик ждать «лучших времен».

Прошло 9 лет. В результате очередной уборки-инвентаризации, в ящике нашел эту старую карточку. Вот и настали «лучшие времена», подумал я.

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

Спойлер - всё получилось.

В предыдущей статье о моей домашней сети я рассказал об использовании локального агента для её настройки и поднятия разных интересных сервисов.

Однако почти сразу я столкнулся с тем, что встроенной оперативки моего роутера (256 МБ) перестало хватать. Запустил AdGuard Home, telemt‑форк под OpenWRT, далее попробовал поднять v2ray со списками разрешенных серверов — и тут же OOM безжалостно начал убивать процессы.

Кажется, что можно было купить новый роутер, с большим количеством оперативки — но роутеры с 1Гб или более RAM сейчас стоят недешево. И тут меня посетила идея: «А что если взять старый смартфон в качестве сервера?».

В этом гайде я расскажу, как пройти путь от выбора и покупки б/у телефона на торговой площадке до рабочего мини-сервера под управлением PostmarketOS с Podman и запущенным на нём AdGuard Home. А также как я облажался в процессе этого пути, прилично ограничив возможности моего сервера.

Классическая ситуация: Go-сервис падает с panic: runtime error: invalid memory address or nil pointer dereference, Nuxt-фронтенд логирует NUXT_UNHANDLED: unhandled rejection. Клиент видит лишь общее «что-то сломалось» — точный текст ошибки остаётся только в логах.

Решение — алертинг по логам. Связка VictoriaLogs + Vector + vmalert + Alertmanager следит за потоком, и как только приложение пишет panic, log.Fatal или NUXT_UNHANDLED, в Telegram уходит алерт. Ниже — как поднять эту связку в Kubernetes без лишней нагрузки на хранилище.

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