У Вильянова нашёл чудесное:

Давно хотел написать, да все было лень. Обычно я покупаю домены в зоне ru примерно за 500 рублей. В интернете полно предложений на этот счет, но недавно узнал, что, оказывается цена доменов практически ничем не регулируется - поэтому регистраторы продают домены по той цене по которой их покупают.

На сайте www.2domains.ru сейчас можно купить домены в зоне ru на год за 99  рублей. При этом через год, продление домена также будет стоить 99 рублей.

Я сначала подумал — развод, но когда я таким образом зарегистрировал aiki-center.ru и seikikan.ru — все прошло на ура. Ребята предоставляют доступ к площадке reg.ru а reg.ru вполне себе солидный регистратор. Оплачивать можно через мобильный кошелёк QIWI - это вообще сказка. На сайте сказано, также, что можно переносить домены от других регистраторов и тогда их продление также будет стоить сто рублей. Это я еще не проверял, но переплачивать за домены как то не хочется, поэтому когда придет время что-нибуть продлять обязательно попробую.

Собираюсь в небольшую заграничную поездку, задался вопросом сколько будет стоить звонок через Skype на мобильник в Саратов. На сайте Skype написано что это будет стоить примерно щесть центов.

Положил денег на счет, сделал звонок длительностью одна минута. Со счета сняли около 15 центов.

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

Замечали ли вы, что мужчины смотрят женщинам на три части тела: на грудь, попу и на лицо. Причем этот процесс протекает совершенно неосознано, мужчины практически не могут это контролировать. Просто взгляд сам собой скользит в нужном направлении. Почему так происходит?

Все просто - это позволяет сразу оценить насколько женщина интересна для продолжения рода. Возможно, это звучит слишком упрощённо и цинично, но мне кажется люди уже достаточно созрели что бы перестать прикрываться идеями Эпохи Возрождения, вроде того, потому что это красиво, или потому что женское тело само по себе прекрасно и привлекательно. Женское тело так же привлекательно для самцов вида homo sapiens как тело самки гориллы привлекатильно для горилл-самцов.

Да да, человек это примат, учили, кажется, в школе теорию Дарвина. Конечно, всегда найдется тот, кто с теорией Дарвина не согласен и кивает на Библию, мол, человек создан по образу и подобию Бога, но разве там сказано, что все остальные животные созданы по образу и подобию кого то друго? Не сказано. Современная генетика вам это легко докажет и покажет — все живые существа на земле созданы из одних и тех же кирпичиков. Так что давайте смиримся с тем, что мы недалеко ушли от мира животных, (а скорее, даже, совсем, от мира животных не ушли) и посмотрим, какие в этом есть приятные стороны.

Читать далее...

Так получилось, что моя домашняя рабочая станция практически всегда находится во включенном состоянии и всегда в подключена к Internet. Иногда бывают ситуации, когда нужно получить доступ к домашней машине из другого места, например с работы, или с Нетбука по WiFi, или с телефона через GPRS или 3G.

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

Давно вынашивал идею настроить VPN и сегодня её, наконец, реализовал. Для этого на линодовский VDS я поставил openvpn (да здравствует линодовский VPN!) OpenVPN настраивается очень просто на официальном сайте OpenVPN есть подробнейшая инструкция как это сделать далее, настраиваем клиентскую часть openvpn на всех машинах, которые хотим объединить в сеть, запускаем, готово - у нас есть собственная виртуальная защищенная сеть где все компьютеры имеют собственный внутренний IP адрес вида 10.8.0.x.

Заработало все практически без проблем, единственное смутило, что пример server.conf в юбунтовском пакете почему то оказался зазипованным (зачем они так сделали?) и не совсем очевидно было как настроить статические IP для всех клиентов.

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

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

Потребовалось проверить некий 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;
}