Сейчас я буду рассказывать и показывать на примерах, почему физики тоже должны использовать инструменты статического анализа кода. Мне бы хотелось, чтобы этим инструментом был PVS-Studio. Но, конечно, любой другой инструмент тоже будет полезен. Анализатор кода сократит время на отладку приложений и уменьшит головные боли от тупых ошибок. Лучше побольше думать о физике и поменьше об ошибках в программах на языке Си++.
Только что, я сел и проверил проект VirtualDub с помощью PVS-Studio. Выбор был случаен. Я считаю, самое главное регулярно проверять/перепроверять различные проекты, чтобы показать, как развивается анализатор кода PVS-Studio. А какой проект будет проверен, не так важно. Ошибки есть везде. Проект VirtualDub мы уже проверяли в 2011 году, но тогда почти ничего интересного не нашлось. Вот я и решил посмотреть, как обстоят дела, спустя 2 года.
2 с лишним года я старался радовать Хабр статьями (преимущественно, личными) в области информационной безопасности, по большей части в сфере веб. Делился знаниями, получал опыт и отзывы, знакомился с интересными людьми.
Не заметно для себя, сделал самый большой вклад в хаб «Информационная безопасность» за всё время. За это время я сам научился многому, совершенно не сравнить уровень моих знаний тогда и сейчас.
И, работая в этой сфере, я прочувствовал несколько проблем, решения для которых я не мог найти нигде. Я встречал и других людей, которые столкнулись с этим же. Но решения так и не было! И тогда я принял решение — решить, в первую очередь, свою проблему, и знать, что я точно помогу многим. Так и родился ресурс с говорящим за себя адресом — bugscollector.com.
Эта статья рассказывает о том, как я, внезапно для себя, перешел с уровня простого пользователя GNU/Linux на уровень контрибьютора в мир open source. Надеюсь что она сможет послужить еще кому-примером для собственного роста.
Все началось с того, что я, как всегда, перешел на новый релиз Ubuntu, на этот раз на 13.04. У меня оказалась не самая удачная материнка для линуксоида, так как в дистрибутивах из коробки редко есть дрова для ее сетевой карты (RLT8168E). Но ведь это не большая беда, верно? Раздобыв сопутствующие для компилирования пакеты, скачал с офф сайта последние дрова на Linux. Я уже делал так с Ubuntu 12.10 и ничто не предвещало подвоха.
Внезапно эти «дрова» не компилируются. Немного повтыкая в текст ошибок, я пошел просить совета на linux@conference.jabber.ru. Там мне рассказали, что брать дрова с сайта — не всегда хорошая идея и что для моей сетевой карты в репозитории есть пакет. Приятный сюрприз. И действительно, стоило начать с поиска пакета с дровами в репозитории. Но, как оказалось, в нем код того же модуля и при компиляции он точно так же падает.
Читать полностью »
В последнее время часто стал натыкаться на различные рассуждения людей, по поводу того, что MySQL — это плохо, это очень плохо — потому что… а вот дальше идут описания различных фич MySQL, которые четко документированы, но пользователь их просто не знает. Кто-то добавляет в БД данные без валидации и удивляется почему они сохранились в неверном формате, а кто-то описывает кучу особенностей myIsam движка, и на этих основаниях делает вывод, что MySQL это отстой — который невозможно использовать в реальных проектах. Всю документацию прочитать невозможно, и да — я с этим абсолютно согласен, но поверьте у нас есть куча других недокументированных и не менее интересных особенностей. Давайте начнем с малого, к примеру докажем, что NULL равно нулю.
Читать полностью »
На Хабре достаточно много написано про хороший стиль программирования, naming convention. А про хороший стиль написания баг-репортов?
Конечно, дефекты хранятся в баг-трекинговой системе, которая накладывает свои ограничения и требования, конечно, есть какие-то внутрикорпоративные правила создания отчетов об ошибках, но все же есть и человеческий фактор, в результате чего появляются баги, отвечающие всем правилам оформления, но абсолютно непонятные даже коллегам-тестировщикам. Плохо описанный баг может получить резолюцию Cannot reproduce и оказаться забытым, пока случайно не выплывет у заказчика.
В этой статье я попробую описать основные проблемы отчетов об ошибках, которые я встречала за год работы на большом проекте, а также способы их улучшения.
Читать полностью »
Было бы неплохо сделать серию статей, в которых описывались различные не очевидные «особенности» языков программирования. Во-первых, «предупреждён — значит, вооружён», во-вторых, знание их позволяет глубже понимать язык и объяснить, в случае чего, чем они опасны. Даже если в своём собственном коде такие конструкции не используются, с этими ловушками можно встретиться при разборе чужого кода или работая в команде.Читать полностью »
Каждый, кому приходилось заниматься разработкой сайтов, знает об ошибках браузеров.
Однако до сегодняшнего дня я думал, что нужно хотя бы использовать хитрые конструкции CSS, вложенные иерархии DIV-ов и таблиц, всякие float-ы и коллапсирующиеся margin-ы, чтобы налететь на реальную ошибку.
Я был уверен, что существует хотя бы одна ситуация, когда можно не опасаться никаких засад и приколов: мы всегда можем обернуть фрагмент обычного текста обыкновенным DIV-ом (display:block; и float:none;) и быть уверенными, что наш текст останется внутри него:
<DIV>
Этот текст никогда не выйдет за пределы обычного DIV-а!
</DIV>
Но на самом деле нет пределов в этом жестоком мире браузерного маразма…
Читать полностью »
Столько воды утекло с тех пор как ПХП провозглосил себя ООП языком. Мне не удалось уточнить когда именно, но «On July 13, 2004, PHP 5 was released, powered by the new Zend Engine II. PHP 5 included new features such as improved support for object-oriented programming».
Т.е теоретически уже тогда появились конструкторы и деструкторы. Сам пользуюсь версией 5.3.2, но диву даюсь что он вытворяет.
Читать полностью »
