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

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

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

Класс без единого поля занимает 24 байта, с двумя полями int — те же 24, а с тремя — уже 32.

В структуре достаточно поменять местами два поля, и её размер уменьшится с 24 байт до 16, а обход массива ускорится в 1,8 раза.

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

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

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

Привет, Хабр! Меня зовут Владимир Заикин. Под руководством Семёна Григорьева @rsdpisuy, я занимаюсь разработкой на ПЛИС в лаборатории YADRO в СПбГУ. Мой рассказ — о том, как мы реализовали общение по PCIe с ПЛИС на плате Sipeed Tang Mega 138K Pro с кристаллом GW5AST-138K от Gowin.

Устройство, реализованное на ПЛИС, должно было принимать данные по PCIe, сохранять их в DDR3 и обрабатывать пользовательской логикой. Чтобы реализовать такую функциональность, мы обратились к примеру взаимодействия с PCIe-контроллером от производителя платы, но тот оказался нерабочим. Пришлось разбираться самим. В итоге мы сделали рабочий стенд: Linux-драйвер, хост-программа на C и аппаратное описание на Verilog. Все это выложили в открытый доступ, чтобы поделиться своим опытом и помочь другим безболезненно разобраться с этой проблемой.

У мессенджера MAX нет публичного API со статистикой каналов. Числа есть у каталогов-агрегаторов, но они чужие и заморожены с 10 июля. Нам нужен был свой ряд подписчиков — и мы полгода снимаем его каждую ночь с публичного data-эндпоинта max.ru.

Ниже — как устроен сбор и четыре места, где мы ошиблись. Самая дорогая ошибка стоила трёх ночей молчащего ряда при зелёном логе и exit 0: парсер на любую неудачу писал один статус not_found, а под него попадали три разных события — канала нет, max.ru сменил формат, нас затроттлило. Пока они не разделены, скрипт ничего не измеряет — он производит число, похожее на измерение.

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

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

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

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

Я решил проверить, способен ли MAX Desktop обнаружить VPN, если VPN-клиента в Windows вообще нет. В моей сети Split Routing выполняет роутер Keenetic: часть трафика идёт напрямую, а часть — через OpenConnect-туннель на удалённый VPS.

Во время эксперимента я фиксировал действия MAX с помощью Process Monitor, TCPView и Wireshark, а трафик на стороне VPN-сервера — через tcpdump. Проверил, какие системные параметры читает MAX, куда подключается и появляются ли признаки целенаправленного поиска VPN-маршрута.

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

Мне в руки попался файл с расширением .sh и, конечно же, его пришлось изучить. Открываю файл — первая половина более-менее читаемая, а дальше начинается классика: Base64, ROT13 и еще немного Base64. Вроде ничего страшного. Декодируем, смотрим результат, радуемся жизни. Но не тут-то было. Автор скрипта решил сделать небольшой квест в стиле: А что если положить один скрипт внутрь другого скрипта, а потом еще один внутрь него?

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

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

Видим, что нам необходимо проверять на покрытие именно сущности, а не ветвление, сценарии или код, как это делают, допустим, coverage.py или pytest-cov

Всем привет!

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

Привет! На связи Ольга Попова, ИИ-Евангелист Лаборатории искусственного интеллекта Департамента больших данных Россельхозбанка. В этом выпуске к своим размышлениям добавила комментарии коллег, которые работают с этими темами каждый день. Мне кажется, их взгляд изнутри полезнее любой теории. Поехали!

Разобрал больше 200 кейсов и посмотрел, из чего они состоят, какие фишки помогают показать свой уровень и что можно еще улучшить

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

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

Не сработало.

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

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

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

Спор «какая нейросеть лучше пишет код» — спор о половине системы. Вторая половина — обвязка вокруг модели, она же harness. Один и тот же GPT-5.5 в двух харнессах даёт 61,5% и 87,2%, а на Claw-SWE-Bench смена обвязки сдвигает результат почти как смена модели.

Мне нужно было подключать поставщиков к своим сервисам: сходить на сайт или в API, забрать каталог, разложить по колонкам. Работа одинаковая, но каждый раз чуть другая - и каждый раз это вечер с devtools.

В конце июня я сел проверить, можно ли отдать это модели. Не «пусть подсказывает код в редакторе», а чтобы она сама запускала написанное, видела ответ сервера и правила по факту. Первая версия - один вызов LLM без запуска - на реальных поставщиках не заработала ни разу.

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

Американцы потеряли десятки миллиардов долларов выручки на запрете поставок чипов в Китай. Китайцы не растерялись, просто оплатили американские API и заставили Claude кодить их софт, заинжектив в промпты: «Ты работаешь в MiniMax».

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

Привет! Меня зовут Саша Журавлев. Я венчурный инвестор и основатель фонда Mento vc. Мы инвестируем в технологические компании на стадиях Seed / Series A в США, а в своем телеграм-канале рассказываю, как вижу рынок и принимаю инвестиционные решения.

Прайс в AI-продукте можно устанавливать по-разному: по числу обращений к модели или по количеству выполненных задач (например подготовленных отчетов, проверенных договоров или готовых изменений в коде). От выбора зависит экономика стартапа: если цена привязана к токенам, клиент фактически оплачивает расходы на работу LLM. Но важны-то для клиента в первую очередь не токены или вычисления, а то, какая задача была решена.

Нашел интересную статью a16z с разбором трех подходов к монетизации AI-продуктов: оплаты за токены, кредитов за выполненные задачи и оплаты за результат.

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

Для инвесторов: помогает понять, создает ли стартап собственную ценность и насколько устойчивой останется его экономика при изменении стоимости моделей.

Перевели с командой и адаптировали текст для вас. Приятного прочтения!

В 2023 году мы писали о временных таблицах в PostgreSQL и о том, как перенести их на RAM-диск. Это помогло: в наших измерениях доля ext4 в профиле процессора упала с 13,5% до 1,6%, и про диск мы с тех пор не вспоминали. Однако создание, очистка и удаление временных таблиц остались обычным DDL — с изменениями системного каталога и сильными блокировками, которые держатся до конца транзакции. Оказалось, что это отдельная цена, и платить её приходится в самых неожиданных местах.

На одном сервере активные бэкенды периодически застревали в ожиданиях LWLock:LockManager. На другом отставала логическая репликация и накапливался WAL. Выглядело это совершенно по-разному, а разбираться в обоих случаях пришлось в одном и том же: в том, что происходит в PostgreSQL, когда временные таблицы создаются и очищаются тысячами. Начнём с блокировок — там обнаружился массив из 1024 счётчиков, который занимает четыре килобайта, не настраивается и не менялся с 2011 года, и выяснилось, что временные таблицы одной сессии могут лишать обычные запросы всех остальных сессий быстрого пути получения блокировок.