Потребовалось проверить некий IP адрес на наличие в блеклистах. Обычно для проверки занесен ли адрес в блеклист используют класс pear Net_DNSBL но у меня локально он наотрез отказался работать корректно, к тому же он требует чтобы PHP был не ниже 5.3.x.x. Такое его поведение мне не понравилось, поэтому решил разобраться как на самом деле происходит проверка. Оказалось все банально до пошлости: сам блеклист есть не что иное как набор DNS файлов на некоем сервере. Допустим, нужно проверить есть ли IP 1.2.3.4 на блеклисте 'db.wpbl.info' для этого просто достаточно проверить существует ли субдомен: 4.3.2.1.db.wpbl.info (обратите внимание - IP указывается в обратном порядке). Если существует - адрес в блеклисте, если нет - на нет и суда нет. Функция checkdnsrr нам в помощь.

По аналогии с  http://www.dnsbl.info/dnsbl-database-check.php сделал аналогичный сервис у себя на сайте - на всякий случай.

Кстати, оказалось что ренетовский IP через который я выхожу в Internet находится сразу в нескольких блеклистах из этого списка.

Имеется InnoDB табличка, небольшая - меньше миллиона записей, делаем такой запрос (нужно получить top10 доменов):
> select dlvDestinationDomain, count(*) from email_accounting where jobid="11837" group by dlvDestinationDomain order by count(*) desc limit 10

созданы следующие индексы:

Обнаружилась забавная вещь: некоторые индексы не только не ускоряют но и замедляют агрегатные запросы:

вообще без использования индексов:

mysql> select dlvDestinationDomain, count(*) from email_accounting IGNORE INDEX(dlvDestinationDomain_2, jobId_3, jobId, dlvDestinationDomain) where jobid="11837" group by dlvDestinationDomain order by count(*) desc limit 10;

3.09 секунды

используя индекс по jobId дает небольшой прирост производительности:

mysql> select dlvDestinationDomain, count(*) from email_accounting FORCE INDEX (jobId) where jobid="11837" group by dlvDestinationDomain order by count(*) desc limit 10;

2.13 секунд;

использование составного индекса по jobID и dlvDestinationDomain сделало все гораздо веселее:

mysql> select dlvDestinationDomain, count(*) from email_accounting FORCE INDEX (jobId_3) where jobid="11837" group by dlvDestinationDomain order by count(*) desc limit 10;

0.39 секунд;

ипользование ключа с полям в обратном порядке  (dlvDestinationDomain и jobID) работает гораздо хуже:

mysql> select dlvDestinationDomain, count(*) from email_accounting FORCE INDEX (dlvDestinationDomain_2) where jobid="11837" group by dlvDestinationDomain order by count(*) desc limit 10;

1.36 секунд;

А вот использование ключа только по dlvDestinationDomain заставляет MySQL думать почти две минуты:

mysql> select dlvDestinationDomain, count(*) from email_accounting FORCE INDEX (dlvDestinationDomain) where jobid="11837" group by dlvDestinationDomain order by count(*) desc limit 10;

1 минута 48 секунд;

Кстати, заметил, что использование jobid="11837" (jobid у меня текстовое) заметно прибавляет скорости против jobid=11837. Не зря в strict моде MySQL грязно ругается на такие преобразования, ох не зря...

Upd. Во всем оказались замешаны настройки InnoDB, если увеличить в my.cnf значение переменной innodb_buffer_pool_size то скорость выполнения агрегативного запроса с индексом по группируемому полю заметно возрастает и картина меняется на прямо противоположную.

Вчера рассказали изумительный стишок:

Товарищ верь, пройдет она,
И демократия и гласность,
Но Комитет Госбезопасность,
Запомнит ваши имена!

Сегодня сходил покатался с горки на Первой Дачной, всего за этот год это получился уже четвертый раз когда я выбрался покататься. Катался на горнолыжной базе "Роща".

В прошлые разы немного поснимал телефоном, и наконец, смонтировал то что получилось:

Потребовалось обработать логи в которых дата хранилась примерно в таком формате 2010-12-03T18:34:33-0500. К сожалению в PHP нет толковой функции для преобразования строкового представления даты в timestamp. Как показала практика strtodate совершенно не учитывает последние четыре знака в строке которые она просто отбрасывет.

Пришлось парсерить строчку ручками и вот что получилось:

function covertdate($date){
	preg_match('/(\d{4})-(\d{2})-(\d{2})T(\d{2}):(\d{2}):(\d{2})([-+])(\d{2})(\d{2})/', $date,$res);
	list($d,$year,$month,$day,$hour,$minute,$second,$digit,$zonehours,$zoneminutes) = $res;
	
	$offset = ((int)($digit."1"))*($zonehours*3600+$zoneminutes*60);
	
	$timestamp = gmmktime($hour,$minute,$second,$month,$day,$year)-$offset;
	return $timestamp;
}

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

Сейчас, чтобы узнать что либо неофициальное не обязательно слушать Голос Америки по ночам - достаточно найти нужный сайт в Интернет. Чтобы создать шедевр живописи - не нужно годами смешивать краски работая подмастерьем у придворного художника. Чтобы изучать боевые искусства не нужно сорок лет готовить еду, убираться и работать на своего Мастера.

Что, информация, блин, вся на английском? Но выучить иностранные языки - легко. Они кругом эти иностранные языки. Половина спама приходящего в мой почтовый ящик предложение выучить какой-нибудь язык. Хочешь Английский, хочешь Японский, хочешь Немецкий -  пожалуйста. Они кругом. Чтобы получить доступ к литературе на иностранных языках совсем не обязательно идти в магазин Интеркнига на Советской, который еще двадцать лет назад был единственный Саратове. Сериалы, мультфильмы, кино - пожалуйста все это для вас на языке оригинала. Не нравится учить тексты - можно учить песни - это даже интереснее.

Чтобы отправиться на другой материк не нужно несколько месяцев жить в корабле, болеть цингой и есть вяленую рыбу. Но ведь это так сложно сделать визу и купить билет на самолёт.

Мы живём в время безграничных возможностей. Сейчас любой ботан может стать Марком Цукербергом, Линусом Торвальдсом, Сергеем Брином или Билом Гейтсом. Любой. Может.

Но...

Реально Цекербергами становится один на Миллиард.

Миллионы слушают новости про Викиликс - реально скачивают и читают эти документы - единицы.

Хорош читать чужие блоги. За работу. Когда настанет время уходить из этого мира - а оно обязательно настанет, оглянувшись назад, сможешь ли ты сказать что использовал на сто процентов все те возможности которые были тебе дарованы? Был ли ты безупречен?

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

Зато теперь мы закупаем муку всевозможных видов — пшеничную, ржаную, рисовую, разрыхлители, дрожжи, мак и т.д. и т.п.

Достаточно загрузить в хлебопечку все необходимые ингредиенты в правильном порядке и в правильных пропорциях и на выходе получается вкусная горячая бухaнка.

Выпекание занимает чуть больше трёх часов. Оказывается, для хлеба важным является порядок загрузки ингредиентов — важно, сначала залить воду, затем положить соль и другие ингредиенты, затем засыпать муку и в уже самом конце на муку положить дрожжи. Если дрожжи положить в воду — это их убъёт и ничего не получится. Именно так я загубил свою первую буханку. Кстати, сухие дрожжи лучше  покупать в маленьких пакетиках - в больших пакетиках они почемуто работают хуже.

Ещё важно соблюдать правильные пропорции продуктов - стоит немного положить больше воды или дрожжей и хлеб осядет но если положить больше муки то хлеб получится недостаточно мягким и клёклым. Для лучшего результата желательно на кухне иметь электронные весы.

Но зато, если все условия соблюдены идеально, на выходе получается вот такая изумительная буханка:

Приятного аппетита!

Несколько вещей которые мне нравятся у Git в сравнении с Subversion:

1. в Git нет дурацких папочек .svn в каждой директории проекта. Одна папка .git лежит в корне и все!
2. папки можно безбоязненно переименовывать - ведь в них больше нет папочек .svn (см. п. 1);
3. ignore лежит в корне проекта - это удобно;
4. каждый локальный репозиторий одновременно содержит и локальную версию проекта;
5. если квакнется удаленный репозиторий - локальный все равно содержит историю всех изменений;
6. можно использовать несколько удаленных репозиториев;
7. просматривать историю изменений при помощи .git реально быстро - она вся хранится локально;
8. Я так и не научился при доступе через SSH в Subversion обходиться без пароля - в Git правилом хорошего тона является использование ключей шифрования;
9. Git создал Линус Торвальдс — а это дорогого стоит;

Я не люблю Web 2.0.

Хоть по работе я и связан с созданием всяких там Web 2.0 штучек, мое искреннее убеждение, что Web 2.0 хуже по определению чем классический Web. И под Web 2.0 я подразумеваю переход к облачным вычислениям, когда вы запускаете приложение из облака и надеетесь, что оно будет работать как надо. Тоже относится к разным системам шаринга файлов или документов, различные централизованные онлайн чаты.

Я не люблю livejournal - это глупость хостить свои блоги на стороннем сервисе, по мне так безопасней иметь собственный блог на собственном хостинге. Желательно на домашнем сервере.

К сожалению, история показывает что плохое всегда заменяется очень плохим - серебрянные монеты вытеснили золотые, медные вытеснили серебрянные, появились бумажные деньги обеспеченные золотом, потом они стали необеспеченные золотом, сейчас бумажные деньги вытесняются пластиковыми картами, которые, идее вообще сводят идею денег до виртуальных фантиков. Аналогичная судьба ждет и Web - он все больше виртуализируется.

Ребята, что вы будете делать когда интернет сломается? Сегодняшнее падение Skype по всему миру лишний раз подтверждает идею, что Web 2.0 - sux.

Допустим, у вас есть какой нибудь сервер с доступом по SSH. На сервере стоит git. Мы хотим создать некую папку на удаленном сервере, содержимое которой должно синхронизироваться с локальной папкой на домашнем копьютере а также с локальной папкой на другом компьютере, например на работе.

Начнем с сервера (на нем Ubuntu).

1. если git не стоит установим его:

> sudo apt-get install git-core
> git config --global user.name "Uzumaki Naruto" #расскажем немного о себе
> git config --global user.email naruto@uzumaki.co.jp #свой емайл


2. создадим репозиторий

> cd /path/to/the/folder #переходи в папку которую будем шарить
> git init #создаем репозиторий
> git config receive.denyCurrentBranch ignore #это чтобы можно было заливать изменения

3. создаем файл README и добавим его в наш новый репозиторий:

> touch README #создаем пустой файл
> git add README #добавляем его в репозиторий
> git commit -a -m"first commit" #фиксируем изменения

Репозиторий создан. Теперь переходим на наш домашний компьютер. Прежде чем соединяться с удаленным сервером нам нужно залить на удаленный сервер публичный ключ домашнего компьютера чтобы мы могли соединяться с ним без пароля.

> ssh-keygen -t rsa -C"naruto@homeaddress.ru" #создадим ключ если не создан
> cat ~/.ssh/id_rsa.pub | ssh user@remoteserver.com 'cat >> .ssh/authorized_keys' #закинем ключ на удаленный сервер

скачиваем наш репозиторий с удаленного сервера:

> git clone user@remoteserver:/path/to/the/folder

Поздравляю, репозиторий скачан, мы можем отредактировать файл README локально и закачать изменения в репозиторий:

> git status #смотрим что изменилось
> git commit -a -m "local chages" #фиксируем изменения
> git push origin master

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

> git pull #все изменения сделанные дома зальются на рабочий компьютер.

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

> git reset --hard

Проверям, содержимое файла README теперь такое же как и на нашей домашней машине, как и на рабочей машине.

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

Несколько замечаний.

1. для доступа к удаленному репозиторию по идее git не обязателено устанавливать на удаленной машине достаточно иметь к ней доступ по SSH - просто скопировать локально созданный репозиторий на удаленную машину, но в этом случае мы не сможем видеть изменения на удаленном сервере в виде живых файлов.

2. в примере используется SSH авторизация, если нужно чтобы к репозиторию обращалось несколько человек имеет смысл использовать gitosis см: https://help.ubuntu.com/community/Git