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

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

Сначала я запускал тесты руками: save, switch, $ nosetests. Потом к тестам добавились проверялки качества кода и пришлось всё засунуть в скрипт:
pyflakes *.py
pep8 *.py
pylint *.py
nosetests

Скрипт запускать каждый раз ужасно лениво, поэтому небольшая оболочка на inotifywait стала запускать тесты и проверки после каждого сохранения:
while true; do
inotifywait -e modify project/*.py -qq; clear
./do_tests
done

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

Кроме того довольно тяжело следить за коллегами, которые тоже могут что-то сделать и забыть прогнать тесты, в результате в репозитории лежит битый код, не прошедший code review и при очередном pull может внезапно начаться clusterfuck.

И тут очень вовремя kmmbvnr@lj выпустил скринкаст, в котором он демонстрировал интеграцию тестирования для django-проектов с сабжем Jenkins (бывш. Hudson). Посмотрел я на все эти красоты, графики и отчёты и тоже захотел чтобы всё само пело и играло. Но у него django-jenkins, как и следует из названия, встраивается в джангу и генерит отчёты используя хитрую систему. Мой проект до джанги не дорос и скорее всего не дорастёт — это достаточно тривиальное WSGI-приложение, которое правда стремительно разрастается. Пришлось поднимать всё с нуля.

Воскресенье я на это убил, но в целом всё довольно прямолинейно и теперь у меня есть симпатичные отчёты:



Что внутри?

Расскажу немного о том, как быстро превратить emacs в полноценную python IDE. Начнем с интересного способа автозавершения кода + по ходу дела добавим еще пару интересных и полезных возможностей. Наверняка многие используют что-то типа rope (или может свои какие-то решения) и это довольно разумно, но не слишком наглядно. Расскажу об одном дополнительном способе.

Теперь по нажатию TAB мы будем получать вот это:

Пользователь yruslan опубликовал хорошую статью про арифметику с плавающей запятой: «Что нужно знать про арифметику с плавающей запятой».

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

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

Обзор практически всех *top утилит под linux (atop, iotop, htop, foobartop и т.д.).

top

Все мы знаем top — самую простую и самую распространённую утилиту из этого списка. Показывает примерно то же, что утилита vmstat, плюс рейтинг процессов по потреблению памяти или процессора. Совсем ничего не знает про загрузку сети или дисков. Позволяет минимальный набор операций с процессом: renice, kill (в смысле отправки сигнала, убийство — частный случай). По имени top суффикс "-top" получили и все остальные подобные утилиты в этом обзоре.

atop

Atop имеет два режима работы — сбор статистики и наблюдение за системой в реальном времени. В режиме сбора статистики atop запускается как демон и раз в N времени (обычно 10 мин) скидывает состояние в двоичный журнал. Потом по этому журналу atop'ом же (ключ -r и имя лог-файла) можно бегать вперёд-назад кнопками T и t, наблюдая показания atop'а с усреднением за 10 минут в любой интересный момент времени.

В отличие от top отлично знает про существование блочных устройств и сетевых интерфейса, способен показывать их загрузку в процентах (на 10G, правда, процентов не получается, но хотя бы показывается количество мегабит).

Незаменимое средство для поиска источников лагов на сервере, так как сохраняет не только статистику загрузки системы, но и показатели каждого процесса — то есть «долистав» до нужного момента времени можно увидеть, кто этот счастливый момент с LA > 30 создал. И что именно было причиной — IO программ, своп (нехватка памяти), процесор или что-то ещё. Помимо большего количества информации ещё способен двумя цветами подсказывать, какие параметры выходят за разумные пределы.

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

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

Устанавливал я Ubuntu 10.10 на ноутбук Acer Aspire Timeline 5810TG. Эта машина обладает экраном в почти 16 дюймов и относительно производительным железом, зато батарея достаточно емкая, чтобы ставить с ней личные рекорды.

Неприятности начались с того момента, когда мой любимый американский хостер вдруг перенес мой многолетний аккаунт на новый сервер и установил хитрый лимит на память php для всего аккаунта. И вроде бы memory_limit 90M на первый взгляд достаточно для любого сайта, но этот лимит действует на весь аккаунт в целом. Т.е. сайты, расположенные на одном аккаунте, начинают «душить» друг друга. Начались проблемы с форумом phpbb посещаемостью всего 2000 уников в сутки. При превышении лимита памяти сервер отдавал 500 ошибку.

Опытные люди, не читая далее, сразу скажут, что предложила мне техподдержка: конечно же переход на их VPS. Для отечественного хостинга это обычное дело, но от буржуев я такое услышал впервые. Выход в таком случае один — переход на другой хостинг, ибо с «террористами переговоров не ведут» да и 15$ за их 300Mb VPS мне показалось несколько дороговато.

Выбрал Open VZ VPS в России 768Mb за ~500 рублей. Все поставил, вроде работает. Но тут черт меня дернул перед сменой DNS проверить нагрузку с помощью loadimpact.com и меня накрыл тихий ужас: при одновременном доступе к сайту 50 посетителей страницы грузились по 60 секунд.

Фонетические алгоритмы сопоставляют двум словам со схожим произношением одинаковые коды, что позволяет осуществлять сравнение и индексацию множества таких слов на основе их фонетического сходства.

Часто довольно трудно найти в базе нетипичную фамилию, например:

— Леха, поищи в нашей базе Адольфа Швардсенеггера,
— Шворцинегира? Нет такого!

В этом случае использование фонетических алгоритмов (особенно в сочетании с алгоритмами нечеткого сопоставления) может значительно упростить задачу.

Такие алгоритмы очень удобно использовать при поиске в базах по спискам людей, в программах проверки орфографии. Зачастую они используются совместно с алгоритмами нечеткого поиска (которые, несомненно, заслуживают отдельной статьи), предоставляя пользователям удобный поиск по именам и фамилиям в различных базах данных, списках сотрудников и так далее.

В этой статье я рассмотрю наиболее известные алгоритмы, такие как Soundex, Daitch-Mokotoff Soundex, NYSIIS, Metaphone, Double Metaphone, русский Metaphone, Caverphone.