Привет, Хабр! Это Сергей Перевозчиков, основатель агентства контекстной рекламы «КонтекстЛаб». Когда ко мне обратился производитель деревянных игрушек, главной проблемой была не выручка, а экономика продаж. Я часто вижу такую ситуацию на маркетплейсах: продажи вроде есть, а прибыли почти нет, потому что бизнес не считает реальные показатели по товарам и не замечает скрытые возможности для роста.

Мы внимательно разобрали ассортимент, посчитали экономику каждого товара и нашли точки роста, которые раньше оставались незамеченными. В результате клиент смог не просто повысить прибыльность, но и создать продукт с высокой добавленной ценностью — настолько высокой, что покупатели были готовы платить 2 000 рублей за изделие из дерева, которое на первый взгляд кажется очень простым. Итогом этой работы стал рост бизнеса в 14 раз.

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

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

Меня зовут Дмитрий, руководитель отдела рекламы и продвижения в Аспро. Мы запускаем интернет-магазины и развиваем систему управления бизнесом Аспро.Cloud.

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

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

В эволюции человека, с сопутствующими видами, есть достаточно любопытный момент. По какой-то причине, примерно 2 миллиона лет назад размеры нашего тела и мозга резко выросли. Это опровергает концепцию эволюции, как медленного и устойчивого прогресса через небольшие изменения. А может ли что-то устойчивое идти скачками?

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

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

Начну с главного:

Финансовые данные в компании обычно уже есть: в 1С, в хранилище, витринах, аналитических кубах. Но в конце отчётного периода аналитики всё равно часто делают одно и то же: выгружают числа в Excel, собирают сводные таблицы, вручную считают отклонения и готовят презентации для руководства. В этой статье покажем, как перевести такой процесс в промышленный контур: создать OLAP-модель, вынести бизнес-логику в семантический слой и получать живые отчёты в Web, Excel и LibreOffice без ручного копипаста. Выгружать данные будем из 1С, но в виду большого количества способов это сделать мы коснёмся этой темы в следующей статье, а здесь сосредоточимся я на возможностях анализа данных.

Статья будет особенно полезна:

- BI-разработчикам;

- архитекторам данных;

- бизнес-аналитикам;

- финансистам;

- руководителям, которым важно быстро получать корректную управленческую отчётность.

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

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

В прошлый раз я писал о японских технологии и цифровизации.

Загрузка операционной системы — процесс многоступенчатый и разнообразный. Несколько лет назад я писал о процессе загрузки сервера x86 в режимах Legacy и UEFI, но акцент тогда был именно на «железной» части.

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

Несколько месяцев назад в публичном пространстве появилась история, которую в engineering-сообществе стали называть поучительной. Команда AWS использовала внутренний AI-инструмент Kira для ускорения работы. Kira предложила джуниорам сценарий: переразверни продакшн-слой. Инженеры согласились. Следующие шесть часов весь AWS не работал. После разбора полётов компания объявила новое правило: финальный апрув на изменения, предложенные агентом, должен давать сениор-инженер.

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

История AWS точно формулирует главный вызов 2025-2026 годов: AI научился быстро писать код, но индустрия пока не научилась с такой же скоростью его доставлять, проверять и принимать решения о нём. Данные, собранные в рамках масштабного исследования State of AI4SDLC, это подтверждают.

Привет, Хабр! В этот раз разбираемся, как нагнетается тема кризиса карьерных треков и что нам всем с этим делать: кому придется переучиваться, что делать новичкам и стоит ли всем срочно записываться в электрики.

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

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

Ранее в рубрике Skill of the Week мы уже разбирали Skill для Spring Data JPA. И, что предсказуемо, в комментариях нашлись те, кто увидел в нём лишнее доказательство простого тезиса: «вот видите, JPA не нужна, она слишком сложная». Аргумент понятный — у AI Agent-а с JPA действительно регулярно случаются «пожары»: ошибки в настройке связей между сущностями, странности с конфигурацией базовых типов, путаница с контекстом персистентности и разными состояниями сущности. Что характерно, ровно на этих же местах спотыкаются и живые разработчики — так что претензия скорее к технологии, чем к модели.

Раз JPA такая сложная — почему бы не взять что-нибудь попроще? Чистый JDBC многим кажется слишком низкоуровневым, и взгляд естественным образом падает на Spring Data JDBC: те же репозитории и сущности, но без прокси, lazy loading и кэша первого уровня. Технология проще — значит, и никакой Skill тут не нужен, верно?

А вот и нет. Умение AI «пользоваться» той или иной технологией зависит не столько от её когнитивной сложности, сколько от того, сколько кода с её использованием модель видела на этапе обучения. Spring Data JDBC объективно проще JPA, но кода с ней в открытом доступе на порядки меньше. Парадокс, но именно для технологий «с малым количеством кода» Skill даёт наибольший эффект: он закрывает ровно тот пробел, который модели нечем заполнить самостоятельно.

В сегодняшнем эпизоде еженедельной рубрики Skill of the Week разберёмся, как, используя Spring Data JDBC Skill, научить своего агента важным навыкам при работе со Spring Data JDBC.

Два месяца своих сессий с ИИ скормил скрипту и собрал бенчмарк под СВОЮ работу — не под чужой лидерборд.

Результат: тройка «лучших открытых моделей» сжалась в ничью, а в практике победила модель в 37 раз дешевле — потому что отвечает мгновенно, а 744B-гигант думает 22 секунды до первого слова.

Важным оказался не балл, а телеметрия, которую балл прячет.

Всем привет!

Недавно я опубликовал свою первую статью про восстановление легендарного компьютера: «Воскрешение „Пентагона-128“ из пепла и безвейтовый контроллер клавиатуры и джойстиков на ATmega8 своими руками». Честно скажу, то, как её встретили — лайки, добавления в закладки и первые подписки на меня — очень сильно воодушевило. По свежим следам и на этой волне вдохновения я сразу же решился опубликовать ещё одну свою разработку. На этот раз — девайс полностью самостоятельный, а все схемы, платы и файлы прошивок я отдаю в открытый доступ.

Сразу оговорюсь: к Спектруму это устройство отношения не имеет. Это универсальный контроллер климата, разработанный мной довольно давно. Он успешно и активно эксплуатируется в реальных условиях уже более 10 лет (причем не только мной), так что жесткое «альфа- и бета-тестирование» временем прибор прошел на отлично.

Устройство можно одинаково успешно применять в двух разных сценариях:

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

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

Недавняя публикация правительством США сотен ранее засекреченных случаев «неидентифицированных аномальных явлений», охватывающих период с 1940-х годов по настоящее время, а также новый фильм Стивена Спилберга «День раскрытия» (Disclosure Day), посвящённый внеземной жизни, подкрепили идею о том, что инопланетяне посещают Землю.

Действительно, опросы общественного мнения в Австралии, США и других странах показывают, что около трети населения верит в присутствие на Земле инопланетян.

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

Вступление: Почему мы заговорили об MCP?

Наверняка, вы, как читатели Хабра в 2025-2026 годах заметили всплеск интереса к аббревиатуре MCP. Много разных статей уже появилось на эту тему. Но сегодня я хотел рассмотреть MCP в контексте работы в связки с APM мониторингом.

Давайте пока коротко вспомним о чем речь, потом проговорим как это может помочь мониторингу и закончим обзором реализации MCP сервера в нашей системе Ключ-АСТРОМ.

Итак, появившись как open-source инициатива от Anthropic, Model Context Protocol быстро стал главным стандартом подключения LLM к внешним данным. Это можно сравнить с USB-C для ИИ: один универсальный разъем вместо кучи проприетарных коннекторов.

MCP — это протокол прикладного уровня, построенный поверх JSON-RPC 2.0. Его задача — стандартизировать обмен контекстом между ИИ-моделью (Хост) и источниками данных (Сервер).

Архитектура строится вокруг трех ключевых ролей:

В прошлой статье мы завершили сборку конвейера безопасной разработки: настроили GitLab CI/CD, подключили Vault для безопасной работы с секретами, добавили статический и динамический анализ, генерацию SBOM, а также интеграцию с DefectDojo, Dependency-Track и Nexus. Теперь у нас есть пайплайн, который автоматически собирает приложение, проверяет его на уязвимости и сохраняет результаты анализа. 

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

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

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

Большинство ошибок с памятью в C++ не выглядят как ошибки. Код компилируется, тесты проходят, приложение работает неделями. А потом внезапно появляется Segmentation fault, повреждённая куча или утечка памяти, которую приходится искать часами.

Разберём пять типичных ловушек, в которые регулярно попадают начинающие разработчики.

Помните, как года два назад все вокруг говорили про промпт-инженеров? Шестизначные зарплаты, никакого кода, просто «умей разговаривать с нейросетью». Казалось, вот оно - профессия будущего.

Сегодня этих вакансий почти не существует.

Рынок труда в IT меняется быстрее, чем большинство людей успевают переучиться. И это уже не страшилки из LinkedIn - это реальные данные, которые мы собрали, чтобы разобраться: что реально произошло, и куда двигаться дальше.