Так получилось, что моя домашняя рабочая станция практически всегда находится во включенном состоянии и всегда в подключена к 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;
}

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

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

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

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

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

Но...

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

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

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

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

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

Достаточно загрузить в хлебопечку все необходимые ингредиенты в правильном порядке и в правильных пропорциях и на выходе получается вкусная горячая бух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.