В Go‑сервисе recover() может выглядеть надёжной страховкой, пока конкурентная запись в map не завершает процесс через fatal error: concurrent map writes. При этом часть гонок проходит незаметно и приводит к потере данных без единой ошибки в логах. В статье разбираемся, почему recover() не спасает в таких ситуациях, как обнаружить проблему с помощью -race и какой способ синхронизации выбрать для общей map.

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

Расскажу, как мы решали такую задачу с помощью Propensity Score Matching.

Идея не новая. Генерировать строки по регулярке умеют randexp в JavaScript, Xeger в Java, exrex и Hypothesis в Python. В TDCV2 я добавил это тоже, и первая половина статьи будет знакома тем, кто ими пользовался. Своё начинается дальше: уникальность, которая заранее знает, хватит ли места; точные доли прямо внутри выражения; условие, при котором одна часть строки следует из другой. Последние две вещи живут в расширенном генераторе advanced_regex, и в таком виде я их больше нигде не встречал.

И про слова. RegExp здесь - это синтаксис регулярных выражений, который TDCV2 использует как язык описания строки: конечное подмножество привычного синтаксиса плюс несколько своих конструкций. В конфиге генераторы называются regex и advanced_regex.

Всем привет! Я Лев Алимов, техлид платформы хаос-тестирования Storm. Моя работа считается хорошо выполненной, если где-то с моей помощью чей-то production прилег. Эта статья о том, как мы в T-Банке развивали Chaos Engineering, когда в него особо никто не верил.

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

Снова статья о том, как надо/не надо делать.

Long story short.

У меня все еще работает CHUWI CoreBox, который уже появлялся в предыдущих статьях: Core i7-13620H, 16 ГБ LPDDR5 (а жаль!), SSD на 512 ГБ. Он успел побыть прокси, NAS, VPN, сервером Lineage 2 и складом 3D-моделей для печати. Склад потом переехал на отдельный накопитель, а сбор моделей я остановил. Даже качественные модели скачивались гораздо быстрее, чем я успевал их печатать. На освободившемся мини-ПК шла разработка своего продукта, ибо я привык к linux, и там же крутились тесты. С обычными проверками еще можно было жить, но мутационное тестирование занимало часы. Хотелось продолжать работу, пока оно выполняется, а свободных ресурсов на той же машине было немного.

Зато рядом стоял мой любимый игровой компьютер: Ryzen 9 9950X3D и золотые 64 ГБ Kingston FURY Beast DDR5-6000 CL30. Память до 64 ГБ я докупал в 2026 году. Кто в этом году собирал комплуктер, тот понимает, почему я сейчас это упоминаю и ставлю на этом акцент.
К этому моменту я уже смотрел по квартире, у чего еще есть оперативка. Поглядывал дергающимся глазом на робот-пылесос и духовку. Если они подключаются к Wi-Fi, значит, они чем-то думают и чем-то помнят.

Но начал все-таки с ПК. Windows оставил на месте, потому что игры нужно на чем-то играть, поставил WSL с Ubuntu и отдельным Docker. Разработку оставил на мини-ПК, а тяжелые проверки решил вынести на игровую машину. Первый измеренный запуск PIT на ней занял больше девяти часов и закончился с ошибкой памяти. Это же разочарование я ловил много раз на мини-пк, разбирал по этому разочарованию логи, в течение десятков часов, в надежде исключить дефицит памяти. Смотрим.

Автор: Дмитрий Квашнин, ведущий инженер-эксперт Innostage

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

В первой части статьи мы проверили производительность PT NGFW версии 1.10.3. Измерили скорость установления TCP-соединений, количество одновременных сессий и пропускную способность на профиле EMIX при разных наборах включённых функций.

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

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

Про N+1 в Laravel обычно пишут три строки про with() и расходятся. Я собрал небольшой стенд на Laravel 13 и SQLite, воспроизвёл проблему, посчитал запросы для каждого способа лечения и проверил, что «не ловится» режимом запрета ленивой загрузки. Отдельно разобрал места, где eager loading не помогает или сам создаёт нагрузку. Все числа в статье получены на этом стенде на искусственных данных.

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

Как поддерживать PostgreSQL и MSSQL в одном приложении, сохраняя единую кодовую базу?

На примере iLocks Online разбираем выбор провайдера в EF Core, отдельные наборы миграций, различия в последовательностях, типах данных и именовании объектов. Рассказываем, что необходимо проверять на обеих СУБД и почему подключения двух провайдеров недостаточно для полноценной совместимости.

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

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

Любой A/B-тест состоит из маршрутизации пользователей, логики входа в эксперимент, деления на группы, метрик и правил принятия решений. Ошибка на любом этапе превращает тест в генератор красивых, но бесполезных графиков.

В феврале 1988 года мне, десятилетнему, купили «Детскую логическую машину». Хотя на коробке указан возраст: от 13 до 15 лет. В ней нет ни транзисторов, ни реле, ни микросхем, а только пластмассовые планки, штеккеры, пружинные контакты и четыре лампочки. И конечно батарейки.

При этом её можно программировать. Времена были такие, и мы кодили на чём могли.

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

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

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

Ну а что? Эмуляторы японских консолей в ассортименте, а вот чтобы наше советское, из пластика и лампочек - нету. Непорадок!

Одна задача, три API: разобрать дистрибутив Pomotroid, восстановить настольный таймер и добавить импорт и экспорт состояния. Сравниваю готовые приложения, автоматические проверки, время выполнения и фактические списания через OpenAI, OpenRouter и TeamoRouter.

Каждый таксист знает, как управлять страной а заодно и «Роснефтью»: кого снять в правлении и что делать с ценой на нефть, он объяснит за одну поездку от аэропорта до центра. Проверить эти знания на деле ему было негде. Теперь и государство, и крупную корпорацию можно собрать из ИИ‑агентов, и мы это сделали! Нет, не перешли работать в такси, а собрали Корпорацию Всевластия. А я таки сел за руль:-)

Я пришёл в нативное iOS-тестирование из Appium, и простой логин на XCUITest раз за разом обрастал waitForExistence, ретраями и самописными хелперами. Так появился KassiOS — слой в стиле Kaspresso поверх XCUITest: тап с общим бюджетом ожидания, который не повторяется после отправки, перечитывание поля после ввода, понятные сообщения о падениях, параметризованные тесты.

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

Наша группа продуктовых исследований регулярно тестирует классические средства сетевой защиты информации — NGFW, IPS. Для этого существуют давно отработанные практики. Например, практически все методики проверки NGFW в зарубежных и отечественных компаниях опираются на стандарты RFC 9411 и RFC 2544 от Internet Engineering Task Force.

К сожалению, с NDR всё иначе: открытых стандартов нагрузочного тестирования для этого класса СЗИ, кажется, просто не существует, а готовые сценарии от NGFW для них не совсем подходят. Поэтому мы разработали собственную методику и делимся ею с ИБ-сообществом.

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

Разберем, чем такое тестирование отличается от классических испытаний NGFW и IPS, как собрать стенд, какие метрики снимать на стороне самого NDR и почему недостаточно статистики генератора трафика. Покажем, как формулировать критерии прохождения теста и как отделять ограничения продукта от ограничений стенда. В конце покажем практический пример того, как методика помогает найти узкое место в производительности NDR. 

Перед переездом автотестов с Java на .NET мы решили разобраться, что действительно стоит переносить. Я ручной QA и для этой задачи подключил ИИ-агента: дал ему доступ к репозиториям и TestIT, задал критерии и проверял его рекомендации. За две недели мы провели аудит примерно 2600 тестов и собрали статистику по базе из 6500. Расскажу, как устроили процесс, находили дубли и выбирали приоритеты с помощью P85.

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

Я уже более 10 лет работаю с тестовыми средами, и раньше делал ошибку: выгружал из прода 200 000 строк, менял фамилии на обезличенные шаблоны, и считал, что все окей. А затем как-то заметил, что в выгрузке остались номера договоров. Мне повезло, что именно я нашел их первым, особенно учитывая всё более суровую регуляторку. С тех пор я отношусь к тестовым данным также серьезно, как к проду.

Как версионируемый QA-репозиторий помогает маршрутизировать контекст, повторно использовать процессы и сохранять обоснование выбора тестов.