Для многих разработчиков программного обеспечения, выбор и изменение модели trial-режима является одной из самых трепетных и обсуждаемых задач. Для одних программ придумать модель проще, для других сложно. А некоторых людей не покидает вопрос: «Мы всё правильно сделали?». Актуальна задача выбора trial-модели и для нас, разработчиков PVS-Studio. Мы решили поделиться некоторыми сопутствующими мыслями и рассказать о том, какой новый вариант мы придумали. Надеемся, что наши рассуждения и некоторые мысли окажутся полезными и другим разработчикам.

Из всех видов рекламы довольно небольшое ее количество приходится на инструменты для программистов. Медийная реклама (телевидение, радио, популярные печатные издания) – очень дорого (так как оплата идет за потенциально большую аудиторию) и сильно мимо (так как программистов из них очень мало). Реклама на специализированных сайтах часто тоже не столь эффективна, так как, во-первых, глаз у программистов «отметает» рекламу автоматически, а, во-вторых, программисты знают про AdBlock. Делать видео по работе с программой – не все программы выглядят красочно и ярко, чтобы можно было их интересно снять. Таким образом, чуть ли не единственный способ сообщить о своем продукте миру – это честно и объективно показывать, чем он хорош на реальных примерах.

Вопрос о том, как добавить собственное диагностическое правило в наш статический анализатор PVS-Studio задают нам довольно часто. И мы всегда отвечаем, что сделать это очень просто: «Нужно всего лишь написать нам письмо, и мы добавим это правило в анализатор». Такой интерфейс для добавления новых правил удобен для пользователя. Это самый лучший и удобный интерфейс. Сделать самому подобную работу, не так просто, как кажется. В заметке я покажу подводную часть айсберга, которая скрывается за понятием «добавили вот это простое правило».

Сначала я хотел назвать эту заметку «Как PVS-Studio позволяет ДЕШЕВО внедрить статический анализ кода в процесс разработки», но не решился из-за двусмысленного толкования слова «дешево». Поэтому я расскажу об одной инженерной проблеме, которую мы постоянно должны были решать для того, чтобы люди пользовались нашим продуктом. Забегая вперед, скажу, что, как мне кажется, мы ее решили.

Очень много вокруг разговоров о том, что новые версии сайтов помогают поднять продажи, а после заказа продвижения сайта они (продажи) и вовсе взлетят до небес. Но, положа руку на сердце, господа сеошники и разработчики сайтов, всегда ли ваша работа нужна людям? Может быть, просто кто-то на этом «отмывает» ворованные деньги? Под катом один из многих примеров, когда новый сайт делается НЕ с целью улучшения продаж…

В статье «Трудности сравнения анализаторов кода или не забывайте об удобстве использования» [1] говорится о том, что сравнить между собой два инструмента не так просто как кажется, потому что помимо собственно технических характеристик анализаторов очень большое значение имеет такой параметр как удобство использования.

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

В статье показаны ошибки, выявленные с помощью статического анализатора кода, встроенного в Visual Studio 2010. Исследование проводилось на пяти open source проектах. Эти же проекты были проверены с помощью PVS-Studio. Приведены результаты сравнения этих двух инструментов.

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

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

Вы сомневаетесь, что сравнивать указанные параметры бессмысленно? Приведем несколько примеров.

Все компании, у которых есть сайт, указывают на нем контактный e-mail. «Зачем вы это делаете?!», — спрашиваю я у таких компаний недоуменно. Ведь вы же все-равно ничего там не читаете. А ваши спам-фильтры – самые мощные в мире!

Совет тем компаниям, у которых указан на сайте e-mail. Пожалуйста, подумайте о том, что кто-то туда вам может написать. Дальше – маленькая поучительная история про попытку связаться по e-mail.

Итак, мне понадобилась простенькая услуга настройки 1С. Я зашел на сайт компании, которая такую услугу предоставляет. И увидел у них контактный e-mail помимо номера телефона. Звонить я не стал. Можете считать меня занудой, но в некоторых случаях мне удобнее написать e-mail, чем позвонить. Почему? Ну потому что пять раз рассказывать разным людям что мне нужно собственно сделать первому секретарю, второму секретарю и т.п. – это лишнее. Написав e-mail, я стал ждать ответа.

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

Я опишу два свежих примера, относящиеся к общению с такими людьми из компаний «Parasoft» и «Лаборатория Касперского». Цель поста не пожаловаться на мир, как кому-то может показаться, а привлечь внимание к проблемам, когда из-за того, что на определенной должности находится человек-робот, какие-то вопросы не решаются. Причем я думаю из-за этого нередко теряет не только клиент/покупатель/пользователь, но и та сторона, которую представляет человек-робот в качестве интерфейса.

(В кабинете у психолога молодой мужчина...)

Понимаете, моя жизнь связана с компьютерами. Я использую компьютеры на работе, дома. Иногда ко мне обращаются друзья и знакомые. Так вот (тяжело вздыхает)… В последний год мне кажется, что меня преследуют. Время от времени я получаю странные красные окошки на всех моих компьютерах. Зачем они попадаются мне на глаза – я не знаю, но я их вижу все чаще и чаще!

В конце октября 2010 года немецкий Fraunhofer Institute for Industrial Engineering (IAO) выпустил свое исследование «Market overview of tools for multicore software development». IAO — это организация, расположенная в Штутгарте (Германия), которая изучает вопросы сферы управления технологиями.

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

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

Программирование это сложно. С этим никто, надеюсь, не спорит. Но вот тема новых языков программирования, а точнее поиск «серебряной пули» всегда находит бурных отклик в умах разработчиков программного обеспечения. Особенно «модной» является тема превосходства одного языка программирования над другим. Ну, к примеру, что C# «круче», чем C++. И хотя holy wars — это не та причина, по которой я пишу этот пост, тем не менее, что называется «наболело». Ну не поможет C#/lisp/F#/Haskell/… написать изящное приложение, взаимодействующее с внешним миром, и все тут. Вся изящность теряется, стоит захотеть написать что-то реальное, а не пример «сам в себе».

Этот пост продолжает мысли моего коллеги, описанные в посте "Ммм… Супер язык… Дайте мне Си++ пожалуйста!". Та статья не нашла понимания у общественности. Теперь я попробую.

Под катом несколько фрагментов на C#, взятые из модуля интеграции статического анализатора кода PVS-Studio в популярную среду Microsoft Visual Studio. Этими фрагментами я хочу показать, что писать, к примеру, на C# совсем не проще, чем на, C++. Желающие поспорить — «велкам в камменты». Кто хочет сказать, что автор кода просто не умеет писать программ — тоже пишите, обсудим.

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

Рассказывая про 64-битные ошибки, поджидающие программистов при миграции их программ, я часто слышу упреки: «Ну да, этот ваш Windows, он такой… Хорошо, что в Linux с 64-битным кодом проблем да-а-а-авно уже нет».

«А вот и нет, мой любознательный читатель».

Сегодняшний пост про 64-битную ошибку в ядре Linux.

В преддверии выхода примерно в сентябре статического анализатора от Intel под названием Advisor, который войдет в Intel Parallel Studio 2011, нелишне будет в целом рассказать о технологии статического анализа кода и об ее применении. Дело в том, что по опыту в России статический анализ применяется не часто, видимо из-за того, что у нас не так много сложных программных проектов. Поэтому краткий текст на тему что это и кому может быть полезно, надеюсь, окажется кстати. Ну и кому же как не авторам анализатора PVS-Studio этот текст делать? :-)

В последние полгода на меня активно валятся предложения «пощупать» Intel Concurrency Checker, как напрямую из партнерской программы Intel, так и косвенно, например, в блоге Сергея Вильянова (здесь). Я довольно долго отказывался от этого заманчивого предложения. И вот недавно я сдался. Под катом — мой опыт использования этого инструмента. Сразу скажу, что меня инструмент оставил в полном недоумении. Почему? Сейчас расскажу. Заранее отвечу на вопрос, что этот пост делает в блоге Интел. Я думаю высказывать замечания к продукции компании лучше здесь, а не в личном блоге.

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

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

В последнее время в сети возникает довольно много тем вокруг стартапов вообще и конкретно проектов, которые создаются или созданы за пару дней, за выходные, за неделю. На мой взгляд, это довольно странная активность, так как все CD-Ejector давно созданы, а их авторы уже заработали свои миллионы. Или нет?