Отправляет email-рассылки с помощью сервиса Sendsay
  Все выпуски  

Клуб профессиональных программистов :: Выпуск #54


Клуб профессиональных программистов "Весельчак У"
Информационная рассылка сайта и форума.  Выпуск No54 (2008-08-05).

Здравствуйте, уважаемые читатели!


Сегодня в выпуске:



Публикуемый здесь фрагмент статьи Андрея Карпова дан "для затравки". Статья опубликована на нашем сайте, где вы ее и можете прочесть целиком. Статья очень интересная - рекомендуем.

У автора и его коллег не мало других статей, которые они нам любезно предоставили. По мере обработки, мы будем публиковать их на нашем сайте и анонсировать в рассылках. на очереди статья "Viva64: что это и для кого?" о переносе существующего ПО на 64-битные платформы и инструментарии, помогающем в этом непростом деле.


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

Специально для обраной связи и обсуждения рассылок создана тема Наши почтовые рассылки в разделе "Самоуправление". Напоминаем, что раздел доступен только активным участникам форума, написавшим не меньше 25 сообщений. Можно просто написать нам на почту: club AT shelek DOT ru.

Форум. Поиск. Мысли вслух.

Нас ищут!

Ищут давно и упорно. И как бы мы не скрывались, нас иногда, все таки, находят...

Речь пойдет о поисковых системах.


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

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


  • Тема: Солнечное затмение 1.08.2008. Статья на astronet.
    Эта тема без какой-либо раскрутки вышла на вторую страницу поисковой выдачи Яндекса по запросу "солнечное затмение 1.08.2008", но сейчас скатилась на 21 место, так как сейчас об этом только ленивый не написал. Это о том, как полезно вовремя создать тему и написать правильное название темы. К сожалению тема, по характеру информации, недолговечная и на сегодняшний день уже устарела.
  • Тема: Методы приготовления креветок.
    Мы уже почти год в топе Яндекса (сейчас четвертое место) по запросу "приготовление креветок". Достаточно было задать правильное название темы и не сильно от нее откланяться в обсуждении. Кстати, если бы в теме "методы" заменить на "рецепт", то находили бы нас вдвое чаще, так как более логичным выглядит запрос "рецепт приготовления креветок".
  • Раздел форума: Программирование 1С
    Запросы "программирование 1с" (32 место, 150 переходов), "1с программирование" (173 (!) место, 60 переходов). Очень популярная тема. Еще есть много "скачать 1с", но это нам не нужно. Спасибо Kivals, Harry и tulke, что раздел 1С не покрывается льдом.
  • Тема: Вывод текста в RichEdit.
    Всего лишь 22-е место по запросу "memo scrollby", но зато 943 перехода в тему с Яндекса! Затрудняюсь оценить полезность темы, но все равно спасибо zubr-у за ответы!
  • Тема: Почта и ошибка 0x800CCC0F
    Второе место в Яндексе по запросу "0x800CCC0F". Замечу - очень часто по нему переходят. Это говорит о том, что тема для людей по прежнему актуальна. Только находят они у нас не решение проблемы, а совет сменить Outlook на что-нибудь более устойчивое и менее дырявое. Совет логичный, но совсем не тот, что искали люди. Взялся бы кто завершить тему...
  • Тема: Как лечить winlogon.exe?
    Третье место в Яндексе по запросу "winlogon.exe". Опять: тема популярная (604 перехода из июльской тиши), а толку в ней мало - нет в ней такого, чтобы заставило человека задержаться на форуме немного дольше.

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

Переходов с поисковиков, на самом деле, существенно больше, чем указано выше - в 2-3 раза. Просто анализатор логов Webalizer не умеет работать с разными кодировками и банальное изменение строчной буквы на прописную или перестановка слов дает у него новый запрос со своей собственной статистикой.


Интересно бывает покапаться в поиске. Только поиск скажет, сколько лет Шелеку и примерную дату его появления...

Скоро нам исполняется шесть лет!

А кто найдет самое раннее упоминание в сети?

Содержание.



Аннотация.


Иногда единственным методом отладки является использование протоколирования событий приложения. К недостаткам протоколирования (логирования) можно отнести большой объем кода, который приходится писать вручную для сохранения всей необходимой информации. В статье рассматривается методика, позволяющая построить систему автоматического протоколирования кода на языке Си/Си++.


Введение.


Несмотря на время, языки Си и Си++ продолжают занимать лидирующие позиции во многих областях программирования. И в ближайшее 10 лет вряд ли что-то существенно изменится.  Появилось много красивых и интересных языков, однако на практике часто предпочтение все-таки отдается Си и Си++. Это одни из лучших существующих языков, универсальные, высокоэффективные и с широкой поддержкой. Если вы хотите лучше понять, чем же привлекательны эти языки, то я предлагаю вам познакомиться со статьей "Инструменты и производительность" [1] и интересной подборкой сообщений из форума comp.lang.c++.moderated "Why do you program in c++?" [2]. Все это значит, что разработка инструментария для языков Си/Си++ по прежнему актуальна.

Во всех языках разработчики допускают ошибки и языки Си/Си++ здесь не исключение. Более того, как и многие профессиональные инструменты, они требуют большего внимания и аккуратности при их использовании. В результате одной из важнейших задач при разработке приложений является отладка кода, то есть поиск и устранение ошибок.

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

  • Интерактивные средства отладки;
  • Runtime-диагностика;
  • Визуальные (графические) средства отладки;
  • Модульные тесты (Unit Testing);
  • Функциональные тесты;
  • Протоколирование;
  • Отладка по крэш-дампам;
  • Визуальный просмотр кода (Code Review);
  • Статический анализ кода.

У каждого из перечисленных методов есть свои достоинства и недостатки, с которыми можно познакомиться в статье "Способы отладки приложений" [3]. Но в рамках нашей статьи мы поговорим о протоколировании (логировании) и методах его автоматизации.


1. Почему протоколирование?


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

Рассмотрим области, где протоколирование является незаменимым по удобству и эффективности решением:

  • Отладка оптимизированных (Release) сборок приложения. Иногда Release версия ведет себя не так как Debug, что может быть связано с ошибками неинициализированной памяти и т.д. Но работать с Release версией в отладчике бывает часто неудобно. А еще, хотя это бывает крайне редко, встречаются ошибки компилятора, которые тоже проявляются только в Release версиях. В таких ситуациях протоколирование представляет собой хорошую замену отладчику.
  • Отладка механизмов защиты. Часто разработка приложений с аппаратной защитой (например, на основе ключей Hasp) крайне затруднена, так как отладка невозможна. Протоколирование в этом случае, является, чуть ли не единственным способом поиска ошибок.
  • Протоколирование - это единственно возможный вариант отладки для приложения, которое запускается на компьютере у конечного пользователя. Грамотное использование файла протокола позволит разработчикам получить полную информацию, необходимую для диагностики возникающих у пользователя проблем.
  • Протоколирование позволяет отлаживать драйверы устройств и программы для встроенных систем.
  • Протоколирование позволяет быстрее обнаруживать ошибки после пакетного запуска функциональных или нагрузочных тестов.
  • Еще одним интересным способом использования логов является просмотр отличий (diff) двух различных версий. Читателю предлагается самому подумать, где такая возможность была бы ему полезна в его проектах.
  • Протоколирование дает возможность удаленной отладки, когда интерактивные средства невозможны или труднодоступны. Это удобно для высокопроизводительных многопользовательских систем, где пользователь ставит свои задачи в очередь, а затем дожидается их выполнения. Такой подход используется и в наши дни в институтах и других организациях, работающих с вычислительными кластерами.
  • Возможность отладки параллельных приложений. В таких приложениях ошибки часто происходят при создании большого количества потоков или при наличии проблем с синхронизацией. Ошибки в параллельных программах бывает достаточно сложно отладить. Надежным методом отлова таких ошибок является периодическое протоколирование состояния систем, которые имеют отношение к ошибке, и исследование данных лога после некорректного завершения работы [1].

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


2. Создание системы протоколирования.


Начнем с требований, которым должна обладать современная система протоколирования:

  • Код, обеспечивающий протоколирование данных в отладочной версии, должен отсутствовать в конечной версии программного продукта. Во-первых, это связано с увеличением быстродействия и уменьшением размера программного продукта. Во-вторых, не позволяет использовать отладочную информацию для взлома приложения или иных несанкционированных действий. Заметим, что имеется в виду именно конечная версия программы, так как лог могут создавать и Debug и Release версии.
  • Интерфейсы системы протоколирования должны быть лаконичны, чтобы не загромождать основной код программы.
  • Сохранение данных должно осуществляться как можно быстрее, чтобы вносить минимальное изменение во временные характеристики параллельных алгоритмов.
  • Полученный лог должен быть наглядным и легко поддаваться анализу. Должна существовать возможность разделить информацию, полученную от различных потоков, а также варьировать ее уровень подробности.
  • Кроме протоколирования непосредственных событий приложения полезно выполнить сбор сведений о компьютере.
  • Желательно, чтобы система сохраняла имя модуля, имя файла и номер строки, в которой произошла запись данных. В ряде случаев полезно хранить время наступления события.

Система протоколирования, отвечающая таким качествам, позволяет универсально решать задачи, начиная от разработки механизмов защиты до поиска ошибок в параллельных алгоритмах C++. [4].

Данная статья, хотя и посвящена системе протоколирования данных, в ней не будет рассматриваться какой-то завершенный вариант такой системы. Универсальный вариант невозможен, так как он сильно зависит от среды разработки, особенностей проекта, предпочтений разработчика и многого другого. Кстати отметим, что существует ряд статей, в которых рассматриваются эти вопросы. Например, "Logging In C++" [5] и "Способы отладки приложений: Протоколирование" [6].

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

Самым простым способом осуществить протоколирование является использование функции, аналогичной printf, как показано в примере:


...


Целиком статью можно прочесть на нашем сайте.

А теперь прощаемся с Вами до следующего выпуска.


С уважением, команда Клуба.


В избранное