Pull to refresh

Comments 38

Молодцы что не скрываете ибо не ошибается только тот кто ничего не делает.
Ошибки в программном продукте для поиска ошибок. Очень интересно :)
Я все больше и больше убеждаюсь в том, что непосредственные контакты производителей с потребителями (разработчиков с пользователями) приносят огромную пользу. Жаль, что не все это понимают.
Меня на предыдущем месте работы не раз тыкали носом: «Пиши код, $%#$ь, для работы с пользователями есть специальная служба поддержки и SMM-манагеры»
Я за последние полтора года (которые в команде, где весь саппорт лежит непосредственно на разработчиках) в этом убедился окончательно. Скорость реакции на багрепорты отличная, плюс, когда в комментарии приходит непосредственно разработчик фичи и внятно объясняет, что сломано и где он будет это чинить — а заодно, походя, дает воркараунд — это очень способствует лояльному коммьюнити. Ну и разработчики при этом знакомятся со сценариями реального использования продукта.

Правда, для нас это работает потому, что пользователи — тоже разработчики, так что там общаться можно на вполне продвинутом техническом уровне, не насилуя свою психику.
Не поделитесь, как возрастает ваш доход от статей на Хабре о PVS-Studio? Думаю многим было бы интересно.
Два ответа:
1. Как только наш блог на Хабре перестанет существовать, значит стало «не выгодно» :-).
2. С другой стороны, на самом деле Хабр все-таки российский ресурс, а у нас продажи 85% в США и Европе, 10% в России.

Так что Хабр — это для души, в комментах сразиться. И потренироваться в написании статей.
>2. С другой стороны, на самом деле Хабр все-таки российский ресурс, а у нас продажи 85% в США и Европе, 10% в России.

Есть такое. Клиентов потенциальных много но все какие то жадные :)
Не надо провоцировать. Все, что люди делают — они делают ради своей прямой или косвенной прибыли.
Прибыль либо прямая материальная, либо отложенная косвенная.
Есть очень мало контр-примеров, когда человек что-то осознанное сделал и непонятно зачем это ему.
Один из контр-примеров — доказательство гипотезы Пуанкаре Перельманом. Второй пример: император Диоклетиан, известный нам от Гоши из «Москва слезам не верит»
UFO just landed and posted this here
Или просто в нагрузку отдать CppCat лично ему, для личного пользования.
Замечательный хэппиэнд, но я думал, что будет немного «хэппиэнднее». Что Михаил (точнее, его компания) получит скидку на ваши продукты за обнаружение ошибки и, главное, за значительную помощь в ее отлове.
Странно, что вы так долго не могли поверить в то, что в вашем продукте может быть ошибка :)
«Ошибка у нас? Не, не может быть, давайте проверим еще раз» :))
Извините, но я Вас немного не понимаю…
Посмотрите на ситуацию с другой стороны: пользователь говорит, что в продукте ошибка. Она у Вас не воспроизводится. Более того, она не воспроизводится ни у одного из Ваших коллег.
По-моему, наоборот, всё отлично: создатели вместо того, чтобы повесить тег «Can not reproduce», начали очень основательно в этом разбираться.
А дальше всё было очень долго, потому что никак не получалось воспроизвести баг, а значит — не было ясно, как же его решать.
> Так исправление одной ошибки в продукте за $250 дало нам продажу другого нашего продукта за совсем другие деньги.
Не уверен, что одно следовало из другого. На его начальника вы и другим путем могли выйти.

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

PS Скидку нам всё же сделали :)
Михаил, спасибо что отметились в комментариях!
Наверно здорово, когда большинство твоих клиентов — тоже программисты, и с пониманием относятся к багам. Завидую!
Это нереально круто!

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

В общем идеал!
Через тридцать секунд Павел сказал:

— Евгений… Ну что же ты забыл...

так скомкать самый интересный момент повествования просто не честно по отношению к нам!!!
Жаль, что зачастую компании быстро исправляют ошибки ДО продажи и ОЧЕНЬ долго после получения денег на счет…
А вот у меня вопрос «по существу», так сказать… насколько я понимаю, анализ кода возможен только когда проанализированы зависимости. Тогда расскажите, как системы паралелльной компиляции могут на разных машинах компилировать разные файлы из одного и того же решения? Я думал что если у файлов зависимости нужно их компилировать в определенном порядке. Или я не прав?

Вопрос актуален т.к. с параллельным анализом идет, в принципе, то же самое. Ведь если можно параллельно анализировать файлы, то можно воткнуть Xeon Phi и параллельно анализировать их на таком мегапараллельном железе. Ну или на кластере анализировать.

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

Специализированное железо… Если это 32-ядерный компьютер, то отлично. У нас еще несколько лет назад некоторые клиенты радовались, как их 16-32 ядер загружаются с помощью анализатора нашего.
Я имею ввиду не-x86 железо. Понятно что если все паралеллится то и 60 процессоров будут прекрасно работать. Имеются ввиду более смелые подходы, например разбор текста на GPU или FPGA. (Кстати, ссылка в тему.)
Че-то сложно все. Нам же надо запускаться на том, что есть у типичных разработчиков, а не программно-аппаратные комплексы продавать :-).
CUDA есть практически у всех, а аппаратные решения — это то, что движет нас вперед! К тому же, при цене в 9к за набор лицензий, anything goes!
У нас нет проблемы с временем анализа.
Сколько занимает проанализировать весь Boost на commodity железе (не 32-core)?
Не тот вопрос. Если человек работает с инкрементальным анализом, то у него проверяются только те файлы, которые были перекомпилированы только что. А это быстро проходит. А если речь о ночной проверке на билд-сервере, то главное чтобы за ночь отрабатывало и слава богу.
Но ведь это неправильно. Нужно переанализировать не только те файлы которые были только что изменены, но и те, которые зависили от тех что изменились. Или нет?
так этим как я понимаю система сборки занимается, пересобирает все зависимости, потом все пере-собранные файлы прогоняются через анализатор.

Хоть я не согласен что время проверки не важно, при СІ прогоне результат хотелось бы получить пораньше (можно запускать параллельно с тестами, желательно чтобы статический анализ работал не намного дольше чем запуск тестов).
То есть, поменяв что-то в «корне» системы, нам нужно пересобрать и переанализировать всю систему. Я про это и говорю. За быструю сборку отвечает IncrediBuild, а за быстрый анализ — вы. Вот и интересно, насколько это будет быстро.
>> Михаил хотел, чтобы сообщения об ошибках CppCat выдавались не в отдельное окно, как сейчас, а в стандартное окно ошибок Visual Studio. С моей точки зрения «хранителя продукта» CppCat это пожелание выглядело нецелесообразным, и я попытался объяснить в почте, что у нас специально сделано отдельное окно, чтобы не путать наши сообщения и сообщения Visual Studio.

Выдачу в окно Error List стоит делать хотя бы потому, что так делает все остальное в VS, включая другие сторонние расширения. И пользователи знают об этом, и поэтому прежде всего будут искать ошибки именно в этом окне. Плюс, там есть стандартные удобные фичи вроде поиска и фильтрации («только текущий проект» etc).

>> выдается уведомление в трее и меняется заголовок окна анализатора.

Ваше расширение для VS выдает сообщения в трее? Это действительно… очень нестандартный UI design для расширения, мягко говоря.
> Error List стоит делать хотя бы потому, что так делает все остальное в VS…

Ну-ну. Даже статический анализатор, встроенный в Visual Studio, выдает сообщения в своё собственное окно, что позволяет реализовывать специфические функции.

Error List совершенно неюзабелен в плане функциональности. Вывести мало. Нужно ещё дать интерфейс для работы с этим списком.
Я не призываю вас ограничиваться Error List. Но сделать опциональный вывод в него — это абсолютно разумное требование.
Я думал, хэппи-энд будет заключаться в том, что ошибка уже полгода находилась самим анализатором в ночных билдах, но на нее никто не смотрел. А так — ошибка как ошибка ;)
Sign up to leave a comment.