Разработка

Google выпустила свой бесплатный генератор сайтов и приложений Stitch:

• генерит простые, но стильные дизайны; 

• под капотом мощнейшая модель Gemini; 

• экспорт в Figma буквально парой кликой 

• есть специальная фича Copy to Figma; 

• любой элемент можно отредактировать.

Isar и еще 8 систем сборки для создания дистрибутива на Linux

Isar — система сборки, представляющая собой набор скриптов для создания пакетов и дистрибутивов на базе Debian с возможностью настройки. Организация проекта Isar похожа на Yocto Project, для сборки используется Bitbake.

Перед сборкой можно настроить параметры файловой системы, ядра, модификации списка пакетов (добавление и удаление пакетов, в том числе и собственных, изменение существующих пакетов). Систему сборки разрабатывает компания ilbers GmbH.

Архитектура системы

Так как Isar основан на Bitbake, архитектура решения состоит лишь в нескольких слоях для Bitbake, реализующих сборку и установку пакетов в соответствии с конфигурацией сборки. В основе всех этих слоев и рецептов лежат утилиты Debian Build Toolchain, которые ответственны за непосредственную сборку пакетов, разрешение зависимостей и т.д.

Особенности решения

• Аналогично Yocto требует усилий на начальных этапах для освоения инструмента.

• Поддерживает загрузку готовых пакетов из репозиториев Debian.

• Подходит для embedded-дистрибутивов, где необходимо сочетание Debian-экосистемы и глубокой конфигурации.

О других embedded- и desktop-решениях решениях рассказали студенты и преподаватели СПБГЭТУ «ЛЭТИ» в обзоре систем для создания Linux-дистрибутивов.  

InfoWatch примет участие в сессии «Киберстрахование: когда ждать прорыва?» на PHDays Fest 2025

Президент ГК InfoWatch Наталья Касперская поделится своим видением развития рынка киберстрахования в России.

Также на сцене — эксперты из «Кибериспытания», Mains, «СОГАЗ», Innostage, Red Security.

Участники обсудят:

• почему рынок киберстрахования растет медленно

• что мешает бизнесу и страховщикам создать прозрачные, понятные продукты

• как найти баланс между технологической экспертизой и требованиями регуляторов

23 мая, спорткомплекс «Лужники», Арена «Ломоносов», 15:40–16:40.

Встречайте новый сервис — реестр контейнеров Kubernetes 🔥

Реестр контейнеров (Container Registry) — это хранилище для Docker-образов, которое позволяет их загружать, скачивать и использовать в Kubernetes и других окружениях.

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

Для подключения переходим в раздел «Kubernetes» → «Реестры контейнеров» → нажимаем кнопку «Создать» и выбираем нужный объем. Подробнее о подключении читайте в доке.

Цены и конфиги:

• 🐟 На выбор шесть готовых тарифов: от 5 ГБ за 40 ₽/мес до 100 ГБ за 200 ₽/мес.

• 🦈 Плюс конфигуратор, в котором можно настроить объем до 2 ТБ.

Добавить образы в свой контейнер в Kubernetes →

High‑Agency People

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

Дальше университеты начали обещать «научим думать». Логика, критическое мышление, работа с данными — всё ещё звучало солидно. И тут внезапно подали второй протез: искусственный интеллект, умеющий не просто хранить, а обрабатывать, синтезировать, предлагать решения. Чат‑модели пишут код, рисуют презентации и спорят о Хайдеггере. Наши когнитивные мускулы тоже оказались отчасти заменяемыми.

Получается странная картина: знание обслуживает Google, мышление делегируется ChatGPT, а что остаётся человеку? Зачем нанимать сотрудника, если его хард‑скиллы обесцениваются быстрее, чем заканчивается бесплатный пробный период очередного SaaS? А главное - какой скилл будет преимуществом в недалеком будущем?

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

Что я называю «агентностью»

Это привычка не ждать. Заметил дырку в процессе — залатал. Увидел новую гипотезу — проверил на реальных цифрах. Не спрашиваешь: «Можно ли?», а говоришь: «Я уже запустил, держу в курсе». Агентность живёт не в чек‑листах OKR, а в личном эмоциональном пружинном механизме, который толкает вперёд без внешнего толкателя.

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

Как прокачивать эту мышцу

Ниже не инструкция, а скорее набор подсказок‑маячков, куда смотреть и что пробовать.

— Ставь себя в ситуации неопределённости. Проекты, где нет подробного ТЗ, заставляют мозг переключаться с режима «исполнить» на «придумать и исполнить».

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

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

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

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

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

Уже невозможно молчать!

Где игровые мышь для левшей?

Что за дискриминации со стороны производителей по использованию руки?

С джойстиками такая же фигня, но на них ни так заметно!

Почему мы разлюбили Isar

Isar — это NoSQL база данных, которую когда-то разработали создатели Hive. Про все плюсы этой БД мы уже писали. Однако однажды нашей Flutter-команде достался проект, который заставил их в корне изменить отношение к Isar и отказаться от этой технологии раз и навсегда.

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

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

Как же мы ошибались! Так как у приложения был офлайн-режим, на старте оно загружало большие объемы данных, среди которых, например, было гигантского видео. И это создавало проблемы. В приложении добавлялись новые справочники, но документации на миграцию в Isar не было. К тому же на Android 32-ой архитектуры в базе вылезли баги.

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

Кстати, этот проект в целом оказался судьбоносным для нашей команды Flutter. Какие еще уроки они вынесли после работы над приложением — в отдельной статье.

RxJS: Почему shareReplay(1) может вызывать утечки памяти

Если вы используете shareReplay(1) в RxJS, будьте осторожны — в некоторых случаях это может привести к утечкам памяти! Давайте разберёмся, почему так происходит и как это исправить.

❌ Проблема с shareReplay(1). По умолчанию:

• Сохраняет последнее значение в бесконечном буфере, даже если подписчиков больше нет

• Не отписывается от источника, когда никто не слушает (например, interval, Subject, HTTP-запросы)
  Это означает, что данные могут накапливаться, а ненужные Observable продолжают работать в фоне

✅ Решение: shareReplay({ bufferSize: 1, refCount: true })

• Добавление refCount: true решает проблему:

• Автоматически отписывается, когда не остаётся подписчиков

• Очищает буфер, предотвращая утечки памяти

💡 Ключевые выводы:

1. shareReplay(1) - Может оставлять "висящие" подписки

2. shareReplay({ bufferSize: 1, refCount: true }) - Безопасная альтернатива

Я обнаружил эту проблему во время code review вчера, а впервые узнал о ней из видео Dmytro Mezhenskyi.

🔗 P.S. Самое время быстро исправить это в наших проектах!)

Больше об 🅰️ngular в моём Telegram-канале

Скрипт очистки логов всех баз MSSQL

Изначально статья была выложена на своём сервере https://ast-1c.kz/almasoft/?p=1443

Ничего сверхъестественного, но может кому пригодится:)

В процессе работы с сервером 1С, который в качестве сервера баз данных использует MSSQL сервер, очень часто приходится решать задачу по очистке логов базы. Сама по себе задача достаточно тривиальная и решается исполнением скрипта (при полной модели восстановления):

USE база_данных;  
GO  
-- Изменяем модель восстановления базы данных на SIMPLE.  
ALTER DATABASE база_данных
SET RECOVERY SIMPLE;  
GO  
-- Обрезаем LOG файл до 1 мегабайта.  
DBCC SHRINKFILE (база_данных_log, 1);  
GO  
-- Возвращаем модель восстановления базы данных на FULL.  
ALTER DATABASE база_данных
SET RECOVERY FULL;  
GO

либо же для базы использующей простой тип модели восстановления:

USE база_данных;  
GO  
-- Обрезаем LOG файл до 1 мегабайта.  
DBCC SHRINKFILE (база_данных_log, 1);  
GO  

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

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

Declare @name varchar(100)
declare @qu as varchar(1200)
declare icur cursor fast_forward for

SELECT name
FROM sys.databases
WHERE name NOT IN ('master', 'model', 'msdb', 'tempdb')
--and recovery_model_desc = 'FULL'

open icur
 fetch next from icur into @name
 While @@Fetch_Status = 0 

Begin
  Set @qu='use [' + @name + '] Declare @logname varchar(64), @size int'
  Set @qu=@qu + ' Set @logname = (SELECT [name] FROM [sys].[database_files]  where type_desc=''LOG'')'
  Set @qu=@qu + ' Set @size = (SELECT max_size FROM [sys].[database_files]  where type_desc=''LOG'') * 0.7/128'
  Set @qu=@qu +  ' ALTER DATABASE [' + @name + ']  SET RECOVERY SIMPLE DBCC SHRINKFILE (@logname, 7)'
  Set @qu=@qu + ' ALTER DATABASE [' + @name + ']  SET RECOVERY FULL'
  Exec (@qu) 
  Set @qu = '' 
  fetch next from icur into @name
END
close icur

SELECT name
FROM sys.databases
WHERE name NOT IN ('master', 'model', 'msdb', 'tempdb')
--and recovery_model_desc = 'SIMPLE'

open icur
 fetch next from icur into @name
 While @@Fetch_Status = 0 

Begin
  Set @qu='use [' + @name + '] Declare @logname varchar(64), @size int'
  Set @qu=@qu + ' Set @logname = (SELECT [name] FROM [sys].[database_files]  where type_desc=''LOG'')'
  Set @qu=@qu + ' Set @size = (SELECT max_size FROM [sys].[database_files]  where type_desc=''LOG'') * 0.7/128'
  Set @qu=@qu +  ' ALTER DATABASE [' + @name + ']  SET RECOVERY SIMPLE DBCC SHRINKFILE (@logname, 7)'
  Exec (@qu) 
  Set @qu = '' 
  fetch next from icur into @name
END
close icur
deallocate icur

DBCC SHRINKDATABASE (TEMPDB);

Скачать готовый на GitHub Gist

Еще немного про надежное программирование в Solidity

Исследуем хранилище EVM

Я уже писал что для хранения маппингов и динамических массивов (в том числе строк и байтовых массивов длиннее 32 байт) в Solidity, в качестве адреса объекта в постоянном хранилище, используется хеш-ключ . Это делает возможным (хоть и весьма маловероятным) возникновение коллизий при обращении к разным сохраненным объектам, что приведет к порче данных при записи объектов по совпавшим или близким адресам.

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

Однако, меня заинтересовало внутреннее устройство хранилища. 256 бит ширины адреса и константная стоимость записи слота требует нетривиальных решений с точки зрения реализации. И они нашлись у разработчиков EVM. Для хранения слотов хранилища, они используют modified Merkle-Patricia Trie который, как вы уже наверно догадываетесь ... да, именно, использует все тот же для вычисления адреса слота в хранилище. Адрес вычисляется, как где - это адрес контракта, а - это адрес в адресном пространстве хранилища.

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

Если вы прочитали статью, вы уже наверно заметили, что вычисление адреса данных маппинга в хранилище и адреса слота хранилища для хранения в modified Merkle-Patricia Trie подозрительно похожи. Эксперимент это подтвердил. Коллизии при полном переборе номеров слотов начинают возникать, как только битовая ширина номера слота превышает половину ширины адресного пространства. Таким образом, почти бесконечный размер хранилища съеживается до значительно более скромных . Иначе говоря, из всех слотов хранилища, вам надежно доступны только из них (эксперимент, как вы понимаете, перебирал те слоты, которые сосредоточены в начале хранилища с точки зрения их номеров).

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

Приглашаем на QA Meetup 28 мая! Спикеры от Garage Eight, МТС, Островок.

Если ты тестировщик, QA-инженер или просто неравнодушен к качеству продуктов — приходи в гости в петербургский офис международной продуктовой IT-компании Garage Eight 28 мая в 19:00.

В программе три выступления от крутых спикеров:
> Алина Матлахова, QA Guild Lead, Островок – Zero Bug Policy: работа с багами и их превентированием.
> Лена Федорова, QA, Garage Eight – Мир, дружба, тестирование: как QA и Dev могут работать вместе на высшем уровне.
> Андрей Ганин, Chief Quality Officer, МТС – Что убивает качество?

А ещё будет:
— QA-викторина с призами;
— Пицца, напитки и живое общение;
— Экскурсия по нашему красивому офису (если ты у нас ещё не был — самое время заглянуть!);
— Немного развлечений — плойка, кикер, кайфовая атмосфера.

Где: Санкт-Петербург, офис Garage Eight (Новгородская улица, 17)

Участие бесплатное, но количество мест ограничено. Обязательно зарегистрируйся по этой ссылке.

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

И подписывайся на нас в telegram, чтобы не пропускать будущие митапы!

К чему готовиться на хакатоне по проектированию SoC и созданию процессоров?

Трек UVM-верификации — результат эволюции и переосмысления задач SoC Design Challenge предыдущих лет. В этом году участники работали с конфигурируемым AXI Stream маршрутизатором, который по заданным правилам распределяет транзакции с входных каналов на выходные, избегая коллизий. Для конфигурации блока предусмотрены регистры, доступные по шине APB.

Несмотря на упоминание UVM в названии трека, окружение было несколько упрощено относительно «честного» варианта методологии. Это позволило опытным участникам проявить себя, а начинающим инженерам познакомиться с основными аспектами UVM — объектно-ориентированным подходом в SystemVerilog, модульностью и абстрагированием через моделирование на уровне транзакций.

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

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

Это описание лишь одного из четырех треков SoC Design Challenge — совместного хакатона YADRO и МИЭТ, который в этом году прошел в четвертый раз. Подробное описание остальных треков и знакомство с командами — в нашем репортаже.

ITFB Group совместно с BPMSoft приглашает на вебинар, посвященный теме организации правильной подготовки к выбору сложных ИТ-решений на примере CRM-платформы.

Вебинар будет полезен компаниям крупного бизнеса (включая Enterprise), планирующим внедрение с нуля или замену legacy-систем как в рамках импортозамещения, так и при смене самописных решений для широкого класса ИТ-систем, автоматизирующих различные бизнес-процессы (BPM, HRM, ATS, КЭДО, SRM, СЭД и др.)

Обсудим:

⏩ Как важно подготовиться к выбору сложных ИТ-решений для крупного бизнеса на примере выбора CRM-системы

⏩ Почему запросы предложений не содержат необходимой информации для проведения точной оценки стоимости внедрения

⏩ Как методология предпроектного обследования (ППО) от ITFB Group помогает создать качественный RFP (запросы предложения)

⏩ Кейсы: ППО незначительно увеличивает сроки и бюджет, но сильно снижает риски

⏩ Как при помощи ППО и гибкого лицензирования вендора можно снизить ТСО в проекте CRM

⏩ Применение ППО для выбора других сложных ИТ-систем (BPM, СЭД, SRM, HRM, ATS, КЭДО)

Спикеры:
Николай Чекин — директор по развитию отношений с партнерами, ITFB Group
Максим Илюхин — директор по продажам, BPMSoft

Дата и время: 29 мая в 11:00

ЗАРЕГИСТРИРОВАТЬСЯ

Интересно применение ML и AI в борьбе за безопасность и доверие пользователей? Тогда Trust&Safety AI Meetup точно для тебя 👀

Когда? 22 мая, 18:00
Где? офлайн в Москве + онлайн-трансляция 

В программе будут 2 технических доклада, интересная дискуссия, спикеры из Wildberries&Russ, Avito, AI Masters. А еще розыгрыш классного мерча среди активных участников и нетворкинг с полезными знакомствами.

Регистрация закроется 21 мая — выбирай формат участия и успей отправить заявку. До встречи на Trust&Safety AI Meetup!

Не пропустите подробности о митапе: @wb_space 🌟

"mergeMap: Секрет управления параллелизмом в RxJS"

Вы знаете mergeMap, concatMap, exhaustMap и switchMap — но знали ли вы, что только один из них принимает второй аргумент?

👉 mergeMap уникален благодаря параметру concurrent, который ограничивает параллельные подписки. Это как "регулятор скорости" для ваших Observable.

_____

Пример использования (контролируемая загрузка файлов):

Представьте, что вам нужно:
1️⃣ Обработать несколько файлов
2️⃣ Избежать перегрузки браузера/API
3️⃣ Сохранить порядок загрузки

В этом случае второй аргумент mergeMap становится незаменимым:

from(fileList).pipe(
  mergeMap(
    file => uploadFile(file), // функция загрузки
    3                        // одновременно только 3 файла
  )
).subscribe();

_____

Преимущества mergeMap с concurrent:
✅ Предотвращает перегрузку API
✅ Оптимизирует нагрузку на сеть
✅ Сохраняет отзывчивость интерфейса
_____

Знали ли об этой возможности? 😉

Больше об Angular в телеграмм-канале

22 мая Андрей Квапил (a.k.a. kvaps) проведет вебинар на YouTube-канале CNCF и расскажет о том, как быстро и просто деплоить виртуальные машины и Kubernetes-кластеры и пробрасывать в них GPU с помощью Open Source-платформы Cozystack.

Зарегистрироваться можно по ссылке: https://tinyurl.com/yf9jcfst. Просто кликните по кнопке «Login to RSVP», чтобы получить приглашение в календаре.

Привет, приспичило создать тестовый стручек (pod), проверить кое-что. Создал и добавил это в kui, в секцию "быстрых" команд:

Тестовый стручек создается вот такой командой:

kube run $quick_pod_name $ns --image=$quick_pod_image --command -- $quick_pod_command 2>&1

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

quick_pod_name=busytest          # Pod name for simple test pod
quick_pod_image=busybox:1.32     # Pod image for simple test pod
quick_pod_command="sleep 3600"   # Pod command for simple test pod

Творите, выдумывайте, пробуйте!)

В репозитории Tencent Cloud SDK for Go на GitHub содержится более 200 000 тегов Git. Это так много, что попытка взаимодействия с тегами в этом репозитории может фактически привести к сбоям в работе GitHub (504 Gateway Time-out. The server didn't respond in time).

Вышло обновление DLP-системы InfoWatch Traffic Monitor 7.12

Выпустили обновление DLP-системы InfoWatch Traffic Monitor. Агент новой версии получил поддержку работы с новыми версиями ОС.

Для соответствия требованиям госструктур агент InfoWatch Traffic Monitor версии 7.12 протестирован и поддерживает новые версии распространенных российских ОС — РЕД ОС 8 и Astra Linux 1.8.

Также в бета-версии агента добавлена поддержка macOS c возможностью контролировать HTTPS-трафик и события печати.

Бета-тестирование: обновлённый парсер для анализа кода на языках C и C++

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

Уже больше года команда разработки PVS-Studio кропотливо работает над обновлением собственного парсера для анализа кода на языках C и C++. Это большое обновление, хоть и не видно для большинства пользователей. Оно служит фундаментом для дальнейших усовершенствований анализатора.

Отличная новость для пользователей Linux: по вашим многочисленным просьбам мы добавили возможность тестирования на Linux! Теперь пользователи обеих операционных систем (Windows и Linux) могут помочь нам в улучшении продукта. Если вы ещё не участвовали в тестировании, сейчас самое время присоединиться!

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

Как присоединиться к тестированию?

Просто заполните специальную форму на нашем сайте. В ответном письме вы получите подробную информацию о тестировании, инструкцию по установке тестовой версии и, при необходимости, временную лицензию на PVS-Studio.

Расскажите о своём опыте!

Если во время использования анализатора вы заметите баги, падения, странные срабатывания или замедление, пожалуйста, сообщите нам об этом! Для этого вы можете ответить на письмо, которое мы присылали ранее, или написать через форму обратной связи. Любые отзывы, баг-репорты и предложения будут очень полезны для нас.

Если хотите поделиться этой статьей с англоязычной аудиторией, то прошу использовать ссылку на перевод: Mikhail Gelvikh. Beta testing: updated parser for C and C++ code analysis.