Hostgen.py: генератор конфигов Apache под Win

Большая часть web-разработки проходит у меня на данный момент в Windows и под Apache. При этом часто приходится создавать локальные домены (и часто удалять их). При этом процесс создания обычно следующий:

  1. Вспомнить, где у меня лежит vhosts.conf и найти его
  2. Скопипастить одну из секций <VirtualHost>
  3. Внести в неё нужные изменения для нового домена
  4. Выдумать домену уникальный локальный IP и указать его тут же
  5. Откопать глубоко в недрах папки Windows файл hosts и добавить IP туда
  6. Перезапустить Apache
  7. PROFIT

Это утомляло мою лентяйскую натуру. Кроме того, я намеревался написать какую-нибудь простенькую утилитку на Python, для лучшего изучения этого, пока ещё тёмного для меня языка. Встречайте — Hostgen.py, может даже кому-нибудь пригодится. (Брать — здесь, zip 11K)
Остальной текст под катом

Mercurial-3: head всему голова

Это продолжение части 1 и части 2.

С момента написания предыдущей части прошло две недели, но за это время произошло немало событий. Зарелизились Mercurial 1.5 и TortoiseHg 1.0, а Джоэл Спольски написал туториал по mercurial. Что характерно, повествование своё, Джоэл разбавил логами виндовой консоли, что позволяет мне в тайне надеяться, что перед этим он читал мой блог :)

Впрочем, даже столь серьёзная конкуренция не отобьёт у меня желания продолжить свой убогий обзор.

Сегодня тема будет небольшая и, на первый взгляд, простая. Однако и здесь можно запутаться. Итак — головы (heads) в Mercurial.
Остальной текст под катом

Redis: перевод официальной документации

Redis logo

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

Для тех, кто не в курсе: Redis, это хранилище типа «ключ-значение» (key-value). Как Memcached (вернее MemcacheDB с его постоянным хранением данных), только круче :).
 
От мемкэша Redis оставил себе скорость и простоту доступа к данным по ключам, а так же легкость в разнесении большого хранилища на множество серверов. Однако, если Memcached в качестве значений поддерживал только строки, то Redis поддерживает также более сложные типы данных (списки и множества). И, вместе с этими типами, также имеется большой набор атомарных операций над ними.

Таким образом, если Memcached это, по большому счёту, всего лишь система для кэширования, то Redis уже полноценная база данных (так называемая NoSQL-БД).

Если хорошо подумать, в большинстве веб-приложений, где используются реляционные БД (типа MySQL), их реляционность по большому счёту и не нужна. И их с большей эффективностью можно заменить на NoSQL-базы типа Redis’а. Особенно это касается высоконагруженных проектов, где требуется высокая скорость и масштабируемость (и нет недостатка в аппаратных ресурсах).

Относительно средних по размеру проектов — Redis может успешно дополнять тот же MySQL, забирая себе некоторые из его функций. Например, основные данных хранить в Redis, а индексы, выборки и сортировки оставить MySQL.

Итак: Перевод официальной документации по Redis на pyha-wiki.

Из наиболее интересного:

Tools: генерилка паролей

Новый полезно/бесполезный сервис — генерилка паролей.

Генерите себе пароли на любой вкус! По одному и целыми пачками :)

Плохая цобако

Писец, сколько людей упёртых не там, где надо. Нахватались поначалу «правильных советов от великих гуру» и теперь остальным мозг выносят. «Никогда не используйте eval», «никогда не используйте @ в PHP»…

Действительно ли никогда нельзя использовать собаку (@) в пыхе? Давайте просто головой подумаем.

Итак, как можно бороться с ошибками в программном коде? Есть два основных способа:

  1. Путём их игнорирования.
  2. Путём их корректной обработки.

Как всем нормальным людям ясно, первый способ (для которого часто и используется собака) ведёт нас прямиком в ад. Человека, который не обрабатывает ошибки в коде, никто не будет уважать, не подаст ему руки и никакая девушка не выйдет за него замуж.

Нам нужна корретная обработка. Однако, ошибки бывают разные и способы их корректной обработки тоже разные.

Первый тип ошибок: ошибки в программе. Синтаксическая ошибка, в запросе опечатались, лень было проверить существование запрашиваемого ключа в массиве и т.п. Аналог проверяемых исключений (RuntimeException). Корректная обработка подобных ошибок может быть только одна — исправление программного кода на этапе разработки. И для этого нам нужно чётко отлавливать их появление и ни в коем случае не подавлять сообщения о них. Здесь собака действительно вредна.

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

$lid = mysql_connect($host, $user, $password);
if (!$lid) {
    throw new Exception('MySQL fail');
}

Мы не спрятали голову в песок. Мы корректно обработали возможную ошибку. Но вот незадача — несмотря на это, mysql_connect() всё равно выкинет совершенно уже ненужный нам Warning.

К чёрту Warning!

$lid = @mysql_connect($host, $user, $password);
if (!$lid) {
    throw new Exception('MySQL fail');
}

Вывод: слушайте умных дядей, но и своей головой думайте.