В последнее время работа и тренировки не оставляли времени на блог, поэтому не удавалось описывать события по горячим следам. Под катом небольшой рассказ о последних событиях и краткое подведение итогов.
Размышления и впечатления, которые не хочется держать в себе. О программировании в частности. Ну и о творчестве, и о жизни вообще.
суббота, 31 декабря 2011 г.
[life.cinema] Очередной кинообзор (2011/12)
Подошло время очередного кинообзора.
Упражнения в прекрасном. Посмотрел с огромным удовольствием.
Воспоминания об убийстве. Еще один хороший южнокорейский криминальный фильм. Очень понравился.
Дом. Очень даже нечего. Если бы не один момент в конце фильма, который все испортил.
Ночь страха. Отличная смесь вампирского фильма с около-молодежной-комедией.
Ронал-варвар. Смешной мультик для тинейджеров, с классной русской озвучкой.
Нечто (2011 года) и Нечто (1982). До просмотра я читал несколько сравнений нового фильма со старым. Не в пользу нового, конечно. Но я никакого разочарования не испытал. Хоть и закручены фильмы вокруг одной и той же идеи, они разные. Тем более, что новый фильм снят как приквел к старому. Хотя мое личное мнение, что старый фильм сильнее. Хоть в нем и спецэффекты совсем примитивные (по сравнении с новым фильмом), но воспринимается он как-то достовернее.
Дом грёз. Неожиданный разворот сюжета. Но что-то в этом фильме было такое, что не позволило ему сильно понравиться. Получился просто неплохой фильм.
Воин. Очень качественно и реалистично сняты сцены боев без правил. Между которыми слишком много соплей и высокопарных диалогов.
Заражение. Попытка снять страшилку на тему глобальной пандемии. Боюсь, что если таковая произойдет на самом деле, то все будет намного страшнее. И фильму не удалось отразить и доли того ужаса, который будет твориться.
Бой с тенью 3D: Последний раунд. Сказочка.
Коломбиана. На один просмотр. Местами много соплей. И все очень невероятно.
Время. Снято добротно. Но воспринимать серьезно происходящее не получалось. Есть во всей тамошней идее какая-то нелогичность. Какая не понял, но есть впечатление, что концы с концами в этой системе ограничения и продления времени не сходятся.
Кожа, в которой я живу. Потрясающе классно снятая потрясающая галиматья.
Красный штат. Потенциально неплохая задумка была полностью испорчена халтурным исполнением (как на уровне сценария, так и на уровне съемок).
среда, 28 декабря 2011 г.
[prog.testing] Ознакомился с описанием тестирования SQLite
Вот здесь наткнулся на интересную статью How SQLite is Tested. Внушаить. Снимаю шляпу, есть чему поучиться и есть к чему стремиться.
Для тех, кто не в курсе: SQLite – это, пожалуй, самая распространенная встраиваемая в приложение легковесная реляционная СУБД, поддерживающая подмножество SQL.
Если коротко, то в тестировании SQLite используется три набора тестов (все цифры относятся к версии 3.7.8):
- TCL tests. Находящиеся в открытом доступе тесты, написанные с использованием языка TCL. В них реализовано 28278 тестов (test cases), но некоторые запускаются с разными параметрами, так что суммарно проверяется порядка 1.7 миллиона тестов.
- TH3. Это закрытый набор тестов, который нужно лицензировать отдельно. В нем реализовано 33595 различных теста. Этим тестовым набором обеспечивается 100% покрытие кода SQLite (для чего требуется прогон порядка 800 тысяч тестов). Всего же полный тестовый прогон перед релизом SQLite содержит порядка нескольких сотен миллионов тестов.
- 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. После длительного облизывания и глотания слюней я таки решился прикупить себе комплект на пробу. Несколько фотографий и впечатления под катом.