суббота, 31 декабря 2011 г.

[life.sport.darts] Лытдыбр

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

[life.cinema] Очередной кинообзор (2011/12)

Подошло время очередного кинообзора.

Упражнения в прекрасном. Посмотрел с огромным удовольствием.

Воспоминания об убийстве. Еще один хороший южнокорейский криминальный фильм. Очень понравился.

Дом. Очень даже нечего. Если бы не один момент в конце фильма, который все испортил.

Ночь страха. Отличная смесь вампирского фильма с около-молодежной-комедией.

Ронал-варвар. Смешной мультик для тинейджеров, с классной русской озвучкой.

Нечто (2011 года) и Нечто (1982). До просмотра я читал несколько сравнений нового фильма со старым. Не в пользу нового, конечно. Но я никакого разочарования не испытал. Хоть и закручены фильмы вокруг одной и той же идеи, они разные. Тем более, что новый фильм снят как приквел к старому. Хотя мое личное мнение, что старый фильм сильнее. Хоть в нем и спецэффекты совсем примитивные (по сравнении с новым фильмом), но воспринимается он как-то достовернее.

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

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

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

Бой с тенью 3D: Последний раунд. Сказочка.

Коломбиана. На один просмотр. Местами много соплей. И все очень невероятно.

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

Кожа, в которой я живу. Потрясающе классно снятая потрясающая галиматья.

Красный штат. Потенциально неплохая задумка была полностью испорчена халтурным исполнением (как на уровне сценария, так и на уровне съемок).

среда, 28 декабря 2011 г.

[prog.testing] Ознакомился с описанием тестирования SQLite

Вот здесь наткнулся на интересную статью How SQLite is Tested. Внушаить. Снимаю шляпу, есть чему поучиться и есть к чему стремиться.

Для тех, кто не в курсе: SQLite – это, пожалуй, самая распространенная встраиваемая в приложение легковесная реляционная СУБД, поддерживающая подмножество SQL.

Если коротко, то в тестировании SQLite используется три набора тестов (все цифры относятся к версии 3.7.8):

  1. TCL tests. Находящиеся в открытом доступе тесты, написанные с использованием языка TCL. В них реализовано 28278 тестов (test cases), но некоторые запускаются с разными параметрами, так что суммарно проверяется порядка 1.7 миллиона тестов.
  2. TH3. Это закрытый набор тестов, который нужно лицензировать отдельно. В нем реализовано 33595 различных теста. Этим тестовым набором обеспечивается 100% покрытие кода SQLite (для чего требуется прогон порядка 800 тысяч тестов). Всего же полный тестовый прогон перед релизом SQLite содержит порядка нескольких сотен миллионов тестов.
  3. SQL Logic Test. Прогоняет туеву хучу различных SQL-ных запросов как через SQLite, так и через другие БД для того, чтобы убедиться, что получаются одинаковые результаты обработки запросов. Всего при тестировании выполняется порядка 7.2 миллионов запросов.

Все это дело используется для проверки:

1. Аномальных режимов работы:

  • нехватка памяти. Для симуляции чего SQLite подсовывается специальный менеджер памяти, который специально возвращает 0 при обращении к функции malloc (однократно или последовательно, в зависимости от сценария теста);
  • наличие ошибок ввода-вывода. Для симуляции чего SQLite использует специальную реализацию интерфейса Virtual File System. Эта реализация поддерживает возможность имитации различных ошибок ввода-вывода по различным сценариям;
  • крах приложения. Здесь посредством еще одной реализации Virtual File System проверяется корректность содержимого файлов БД при имитации краха приложений на разных стадиях работы с данными;
  • сочетания различных видов сбоев – например, нехватка памяти при попытке восстановления после ошибки ввода-вывода.

2. Некорректных данные:

  • синтаксически корректные, но семантически неправильные SQL-выражения (во время этого тестирования прогоняется порядка 102.1 тысяч разнообразных SQL выражений);
  • запорченные файлы БД. Берутся нормальные файлы БД, в которых меняется часть байт и испорченные таким образом БД скармливаются SQLite;
  • граничные условия. Проверяется поведение SQLite когда ей пытаются задавать значения, превышающие максимально допустимые. Например, создаются таблицы со слишком большим количеством столбцов и т.д.

3. Отсутствия регрессии при разработке SQLite. На каждый выявленный баг заводится тест, который включается затем в набор регрессионных тестов для проверки того, что он не всплывет в будущих версиях.

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

Так же активно используются средства динамического анализа:

  • assert-ы, которые можно включить посредством символа препроцессора SQLITE_DEBUG;
  • valgrind, который ловит кучу проблем, связанных с памятью, но за счет серьезного снижения скорости работы. Поэтому под valgrind-ом прогоняется только ограниченный набор тестов;
  • memsys2, который контролирует работу с памятью (хуже, чем valgrind, зато намного быстрее);
  • специальные средства для контроля за тем, что мутексы при работе в многопоточной среде захватываются и освобождаются должным образом;
  • journal test VFS, специальная реализация интерфейса Virtual File System, которая контролирует, что все данные, которые SQLite пишет в БД, сначала проходят через rollback journal (т.е. сначала попадают в журнал транзакции);
  • отсутствия переполнения signed int-ов, для чего делаются прогоны кода, скомпилированного посредством GCC с опцией –ftrapv.

Так же SQLite проверяется на получение одинаковых результатов работы с данными в БД при включенной и выключенной оптимизацией запросов.

Еще раз повторюсь – внушаить. Такое впечатление, что в тестирование SQLite вложено в разы больше труда, чем в собственно ядро SQLite. Что подтверждается цифрами: объем кода SQLite – 77.6 KSLOC, объем тестов – 91392.4 KSLOC (в 1177 раз больше).

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

[prog] Вышла версия 6.0.7 библиотеки ACE

Обновилась библиотека ACE – появилась версия 6.0.7. В этой версии в шаблонный класс ACE_Atomic_Op добавлен метод exchange. В группу шаблонных классов для поддержки таймерных очередей добавлен новый параметр – TIME_POLICY. Класс ACE_Countdown_Time преобразован в шаблон, в котором так же есть параметр TIME_POLICY. Заявлена начальная поддержка MS Visual Studio 11.

Скачать новую версию ACE (а так же обновленные версии TAO, CIAO и DAnCE) можно отсюда: http://download.dre.vanderbilt.edu/previous_versions/

понедельник, 26 декабря 2011 г.

[prog.suddenly] Интересное качество языков программирования

Выдернуто отсюда:

Кстати языки высокого уровня тем и интересны, что более подходят для развития человеческого мышления.

Даже не знаю, как прокомментировать. Но фраза замечательная.

[prog.memories] Несколько хороших историй на тему инженерной археологии

…нашлось в разделе юмора на RSDN, хотя место им вовсе не в юморе. Вот они:

Память фирмы (не про программирование, но очень поучительно)

Археология исходников в блоге ув.тов.ShaggyOwl

Археология исходников в Компьютерре за авторством ув.тов.Виктора Шепелева.

На тему первой истории (про установку производства полимеров и “левые” копии технической документации у инженеров) мне вспомнился случай, который произошел со мной.

Когда-то давным-давно сделали систему для большого заказчика. Причем сделали так – есть софт на нашей стороне, есть софт на их стороне. То, что на нашей стороне, мы полностью делали сами. То, что на их стороне – в основном их собственная разработка, в которой использованы наши библиотеки. Понятное дело, что как только возникало что-то странное в работе софта на их стороне, то всех собак вешали на нас (“Ваша библиотека работает не правильно!”) и мы с шилом в заднице пытались найти у себя проблемы, которые чаще всего были не у нас.

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

Минуло еще года три и случился большой Бах-ТРАХ-Тара-Рах (причем ТРАХ именно с большой буквы во всех смыслах этого слова). В конце-концов проблема была найдена – зацикливание при разборе принимаемых данных. Но этого было мало, нужно было еще как-то указать, откуда она взялась. И тут очень пригодился валявшийся все это время без дела архив – зная что именно искать я, в итоге, нашел место, где происходила ошибка. Хотя, по хорошему, этих исходников у меня быть не должно было ;)

воскресенье, 25 декабря 2011 г.

[life.sport.darts] Впечатления от дротиков Unicorn Phase 6 Purist – 25g 97%

В начале 2011 года Фил Тейлор на несколько месяцев сменил дротики. Затем вернулся на свою, уже старую, пятую фазу (Unicorn Phase 5). Но Unicorn через полгода выпустил в продажу ту самую модель, которую назвали Phase 6. После длительного облизывания и глотания слюней я таки решился прикупить себе комплект на пробу. Несколько фотографий и впечатления под катом.