Из лицензионного соглашения
В opensource продуктах попадаются замечательные вещи, например очень понравилось у Spam Karma - плагин для вордпресса фильтрующий спам.
It goes without saying that this software is provided “as is”, without any guarantee of warranty of any kind, nor could I ever be held liable for any damages it could do to your system (see header of source code for details): if SK2 was to go berserk, screw up your database, delete your entire blog, kill your cat and rape your hamster (or the other way round), you’re pretty much on your own legally. It shouldn’t though.
ПО предоставляется "как есть" без каких либо гарантий любого вида, в частности я не отвечаю на какие либо повреждения вашей системы (см. заголовок в исходном коде для более подробной информации): если SK2 сойдет с ума, сломает вашу базу данных, удалит весь блог, убьет вашего кота и изнасилует вашего хомяка (ну или что-то в этом роде), то это будет целиком на вашей совести. Хотя этого и не должно случиться...
Говнокод
Представьте ситуацию, пришли вы к зубному, открыли рот, доктор посмотрел, и как заржет:
- ха ха ха, вы только посмотрите как тут эти эскулапы нахуевертили, кто вам лечил зубы? Настенька, вы только гляньте какая кривая пломба! А как залечены пятерки! Нет говнодоктор явно не знал что такое кафердан... А ты погляди, как эти козлы сделали депульпацию! Да они даже каналы не запломбировали! Пойди позови главврача, он должен это видеть... еще позови Михалыча, вместе поржем... Да еще дай мне фотик сейчас пошлю ЭТО на govnodent.ru!
Что неверится? Зато программисты так всегда делают, обосрать код другого это дело чести...Это я к чему? Просто мой код наконец удостоился чести быть опубликованным на http://govnokod.ru.
Опера на первом месте
- Что делаешь Петька?
- Да вот оперу пишу...
- Это хорошо... А про меня напишешь?
- Напишу Василь-Иваныч, напишу — опер про всех просил написать...
Обнаружил, что на моем сайте больше всего заходов из под оперы. Вот уж никак не ожидал, что Опера обгонит по популярности все остальные браузеры, или это у меня на сайте аудитория такая специфическая?
| 1. |
Opera
|
453 | 37.47% |
![]() |
| 2. |
Firefox
|
406 | 33.58% | |
| 3. |
Internet Explorer
|
209 | 17.29% | |
| 4. |
Chrome
|
85 | 7.03% | |
| 5. |
Konqueror
|
16 | 1.32% | |
| 6. |
Mozilla
|
12 | 0.99% | |
| 7. |
Opera Mini
|
12 | 0.99% | |
| 8. |
Safari
|
12 | 0.99% | |
| 9. |
SeaMonkey
|
3 | 0.25% | |
| 10. |
HTC_Touch_Diamond2_T5353 Opera
|
1 | 0.08% |
Локальное время в MySQL отличается от времени в PHP
Начинаю понимать почему многие разработчики забивают на тип DATETIME в MySQL и используют вместо него целочисленные поля:
$date = gmmktime(0,0,0,1,1,2010); //2010-01-01 00:00:00;
DB::execute("insert into messages SET date_created=from_unixtime(?)",$date);
$id = DB::getLastID();
$r = DB::execute("select date_created from messages where message_id=?",$id);
print $r->fields[0]; //2010-01-01 03:00:00
все функции для работы с датой используют локальное время MySQL сервера, но так как они могут не совпадать с локальным временем в PHP то можно получить довольно интересные баги...
Оказывается для MySQL нужно выставлять зону отдельно.
DB::execute("SET time_zone='".Config::$mysql_timezone."'");
причем, строковые значения вида 'America/New_York' для зоны дают странные результаты - почемуто у меня получилось расхождение в 34 секунды c PHP, возможно связано с тем, что MySQL высчитывает даты с использованием leap seconds c в PHP просто прибавляет или вычитает часовую разницу, поэтому решил, что лучше использоватать числовые зоны, типа SET time_zone='-5:00'.
