2 сервера на Python
Интересные открытия ждут новичков при исследовании функциональности Python интерпретатора и состава библиотек.
SMTP сервер для разработчика
Команда:
python -m smtpd -c DebuggingServer -n
Что делает:
Выводит всё, что приходит по стандартному smtp протоколу на стандартный вывод. Можете перенаправить в файл, можете смотреть так, в терминале. По умолчанию ожидает соединения на порт 8025 (стандартный 25 порт использовать без повышения привилегий нельзя). Для дополнительных опций и возможностей смотрите документацию.
Веб сервер для статики или передачи файлов
Бывает так, что надо посмотреть что-то по http протоколу, т.к. политики браузера не разрешают это через file://. А бывает, что надо что-то большое передать по сети коллеге, что выкладывать на друпбоксы долго, а расшаривать папки муторно (или запрещено файерволами).
Команда:
python -m SimpleHTTPServer
Что делает:
Даёт доступ по http ко всем файлам в текущем каталоге. index.html работает, список файлов при его отсутствии выдаёт. По умолчанию использует 8000 порт (стандартный 80 порт использовать без повышения привилегий нельзя). На стандартный вывод пишутся логи запросов, что также удобно. Для дополнительных опций и возможностей смотрите документацию.
Забыть md5
Интересно, но я до сих пор считал, что md5 хеш в текстовом представлении (32 символа) для идентификации объектов — весьма не плохо. И коллизии маловероятны. Тем не менее, если не нужно привязываться к контенту объектов (как в git, к примеру, который, к слову, использует более длинный sha1), то можно поискать что-то более интересное и короткое.
Например, почитав статью Размещение, можно заключить, что у md5 при длине 32 символа возможно 16^32 вариантов. Это отлично! Однако не всегда нужно, поэтому могу предложить более простую реализацию: используя все символы английского алфавита и цифры можно получить достаточное количество вариантов ключей, надо лишь подобрать нужную длину для вашей задачи. При 5 (пяти, всего пяти!) знаках — это уже почти миллиард вариантов.
Это не моя идея, сервисы сокращения интернет ссылок используют этот механизм уже давно, но задуматься об эффективности перехода с md5 меня заставили собственные текущие задачи.
Регистрационный код по электронной почте, верификационный код какой-либо купонной системы, ссылка на информационный UGC элемент… Тут есть выигрыш при использовании более короткого кода. Хотя бы от того, что сам код становится менее страшным для человека (психологический момент использования сервиса) или ссылки в коде страницы станут короче (в случае UGC) — страница меньше и быстрее.
Это всё копейки. Но по копейкам набегают миллионы 
/*
* Пример генерации кода на PHP
*/
function makeCode() {
$a = '1234567890abcdefghijklmnopqrstuvwxyzABCDEFGHIJKLMNOPQRSTUVWXYZ'; // 62 символа
$l = strlen($a) - 1;
$c = $a[rand(0, $l)] . $a[rand(0, $l)] . $a[rand(0, $l)] . $a[rand(0, $l)] . $a[rand(0, $l)] .
$a[rand(0, $l)] . $a[rand(0, $l)] . $a[rand(0, $l)] . $a[rand(0, $l)] . $a[rand(0, $l)]; // 10 знаков
return $c; // число возможных размещений: 62^10 = 8,392993659*10^17
}
PS: На коллизии не забывайте проверять!
Грабельки deployment при наличии opcode кэша
Привет, PHP разработчик, администратор или релиз-менеджер! Наткнулся на интересное, спешу поделиться.
Дано:
Проект на PHP, одновременно работающий в режиме разработки («DEV», из SVN), а также боевом режиме («LIVE»), в который переводится ветка DEV после отлова багов. Сервер примечателен только тем, что PHP запускается через php-fpm и там включено opcode кэширование. У меня нижеследующее проявилось и при XCache и при APC.
Надо:
Перевести отлаженный проект из режима разработки в режим работы.
Решаем:
Итак, имеем примерно такую структуру проекта (ненужное вырезано):
.../dev/
/app/
/index.php : <?php require dirname(__FILE__).'/../conf.php'; print $me;
conf.php : <?php $me = 'dev';
.../live/
/app/
/index.php : <?php require dirname(__FILE__).'/../conf.php'; print $me;
conf.php : <?php $me = 'live';
Два виртуальных хоста в web сервере берут данные из …/dev/ и …/live/, где лежит соответствующий код. Всё работает, opcode кэш ускорят работу, все счастливы. Запрос на …/dev/app/index.php возвращает «dev», на …/live/app/index.php — «live».
Но вот пришла пора выложить код из DEV в LIVE как можно более быстро и без глюков. Понятно, что вариантов море, один из пришедших в голову был таков: для deployment использовать 2 команды переименования каталогов. Это на самом деле весьма «дешево»: операционная система сделает очень мало работы в очень короткое время, сбои крайне маловероятны:
mv .../live/app .../bak && mv .../dev/app .../live
И вот в очень короткое время мы переместили код. Всё хорошо? Нет! Запрос на …/live/app/index.php возвращает «dev», сайт работает с тестовыми данными разработчика! 
Расследование:
Собственно, поиск причины был не сильно долгим. Мы переместили ветку файловой системы, идентификаторы файлов («inode») внутри ветки не поменялись и op-кэш наивно думает, что ничего не поменялось, т.к. он идентифицирует код по идентификатору файла. Ну и в итоге в окружении LIVE лежит файл, который запускается интерпретатором PHP со включенным файлом конфигурации на момент попадания в кэш — это был файл из DEV ветки. Вот так.
Итого мораль — при переносе дерева файлов PHP в рамках обработчика PHP с включенным opcode кэшированием вы продолжаете использовать старый закэшированный код, даже если включенные из перенесенных файлы поменялись.
Что делать?
Один из вариантов, и как мне кажется правильный — это запустить два экземпляра php-fpm обработчика. Отдельно для DEV и LIVE окружений. Или полностью исключить некоторые файлы из кэширования.
Python beginners class from Google
Just watched Google python class done by Nick Parlante. It is rather introductory but very useful and cool.
Lecture videos:
1.1 Introduction, strings
1.2 Lists and sorting
1.3 Dicts and files
2.1 Regular expr
2.2 Utilities
2.3 Utilities urllib
2.4 Conclusions
Python
Сколько не сопротивляйся, прогресс настигает…
Давно ли я изучал perl? Как казалось, самый крутой и развитый язык для всего-на-свете (и самый мозгодробильный, ага). Хотя, должен признать, язык и среда выполнения очень стабильные, библиотеками покрыты все предметные области, простые проекты делать легко, сложные — интересно, а работает оно годами и без сбоев.
Давно ли я изучал php? Самый продвинутый и простой язык для web-разработок. Как классно создавать на нём что-то: раз, два и готово! Сколько вокруг приложений на нём — бери, изменяй под себя и используй.
Но, вот уже довольно продолжительное время рядом со мной ширилось использование другого, нового и любопытного языка — python-а. Со времён моего знакомства с RedHat 8 я видел интересный процесс перехода в системных задачах от perl-а к python-у. Сам язык практически стабилизировался, появилось невообразимое количество библиотек. Использование сервисами Google, развитие приложений для web и другие применения — всё это не оставило выбора.
Начал изучать python. Не могу больше сопротивляться 
Зачем изучать? Для меня есть минимум 3 причины: саморазвитие, быстрая разработка кросс-платформенных приложений, причём, как серверных, так и с графическим интерфейсом, а также разработка для web. А вообще — что-то очень много всего на python вокруг стало в моей любимой Ubuntu, да и вообще.
В голове есть идеи, реализация которых начата в процессе обучения, вероятно напишу про результаты позже. Как показал опыт, самая эффективная форма обучения — использование изучаемого. Тем не менее читать документацию, статьи и книги очень полезно. Поэтому посылаю:
- http://python.org/
- http://www.python.ru/
- http://www.djangoproject.com/
- http://www.djbook.ru/
- http://softwaremaniacs.org/blog/category/django/
- http://habrahabr.ru/blogs/django/
- https://launchpad.net/quickly
Принимаю ссылки от освоивших. Особенно интересны обзоры хороших практик применения особенностей языка и вообще описание этих особенностей и отличий от.
PS: Python — это не про рептилию (хотя в логотипе намекают), а про Monthy Python-ов, так что «улыбаемся и кодим, улыбаемся и кодим»!
Что-то заинтересовало?