Я уже давно обещал выложить исходные коды судоку (поиграйте в судоку, если еще не играли). Я думал, что со временем исправлю код, сделаю лучше, но нет ни времени, ни желания. Поэтому лучше я выложу как есть, а вы уж сами улучшайте. Посмотреть код. Далее в посте будут комментарии. Читать дальше...

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

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

Хочу рассказать вам про многопоточные приложения, взаимодействие процессов (IPC) и применение всего этого на PHP. В качестве примера мы возьмем счетчик с эксклюзивным доступом, доступный для всех процессов.

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

Я уже писал про создание модальных окон на jQuery с помощью Simplemodal, на этот раз я решил попробовать другой плагин и нашел для себя blockUI. Он потребует jQuery версии не ниже 1.2.3. Итак приступим. Читать дальше...

Если у вас возникают ошибки при работе с SQLite, то вот у меня пара решений.

Если у вас ошибка "Unable to open database file" и при этом база читается, даже если вы дали права файлу БД 0777, то вам еще надо дать права на запись папке, в которой лежит файл. Дело в том, что при открытии транзакции пишется файл dbfilename-journal. Так же под Windows эта проблема может означать наличие кириллических символов в пути к базе.

Если вы по привычке написали ON DUPLICATE KEY UPDATE ..., и не понимаете в чем ошибка - обратитесь к официальному мануалу и просто измените INSERT на REPLACE, а "ON DUPLICATE..." сотрите.

Такая ошибка возникла у меня после перехода на PHP 5.3. Решение я нашел на http://stackoverflow.com, можете там посмотреть, чтобы узнать про эту ошибку более подробно. Выглядит она вот так:

Warning: PDO::__construct() [pdo.--construct]: [2002] Invalid argument (trying to connect 
via unix://) in /home/blah-blah-blah.php on line 9
 
Fatal error: Uncaught exception 'PDOException' with message 'SQLSTATE[HY000] [2002]
Invalid argument' in /home/blah-blah-blah.php:9 Stack trace: #0
/home/blah-blah-blah.php(9): PDO->__construct('mysql:host=localhost;dbname=db', 'USER', 
'PASSWORD') #1 {main} thrown in /home/blah-blah-blah.php on line 9

Решается она так: вместо localhost, при написании DSN для PDO пишите 127.0.0.1. А так же стоит указать путь к сокету MySQL в php.ini: pdo_mysql.default_socket=/var/run/mysqld/mysql.sock

Как вы, возможно, помните я купил себе зеркалку Nikon D60. Я достаточно долго щелкал на китовый объектив и, естественно, захотел новых игрушек. Китовый объектив я отдал хозяину, а себе купил кит от D90 Nikkor 18-105mm f/3,5-5.6, а чуть позже Гелиос-81Н 50мм f/2. Сейчас я коротенько расскажу про Гелиос.

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

Мне нужно было получать строку из файла по порядковому номеру. То есть первую, десятую, 390815-ую, и т.д. Сначала мне хватало цикла fgets, который прокручивал до нужной строки. На строке 500000 такой способ у меня занимал уже почти минуту, что явно плохо. Stream_get_line был совем не быстрее, а даже медленнее процентов на 30.

Первый из костылей, пришедших мне в голову был fseek до значения в 500000 строк (посчитал байты), а оттуда уже крутил fgets. Но так как у меня идет обработка до 100 тысяч строк в сутки, то через пару дней опять пришлось высчитывать смещение для fseek. Опять же, требовался другой выход. И я его таки нашел.

function getFileLine($file, $line) {
    return trim(exec("head -n $line $file | tail -n 1"));
}

Head берет N первых строк файла, tail N последних. Все гениальное просто. 1 миллионная строка берется из файла за 1.027 сек, 40 миллионная - 30 секунд, что очевидно быстрее прокручивания fgets. (Конечно, если не прыгать fseek до 40 миллионной записи и считывать 40000001-ую)

Конечно, решение ограничено *nix системами, но т.к. моя система и без того использует pcntl_fork, она уже была привязана к никсам, так что хуже мне не стало.

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

CREATE TEMPORARY TABLE ids (value INT, url VARCHAR(255));
INSERT INTO ids VALUES 
    (0, 'http://url1.ru'),
    (0, 'http://url2.ru'),
    (0, 'http://url3.ru');
UPDATE blogs, ids SET my_value = ids.value WHERE blogs.url = ids.url;

Поясню. Допустим, мне понадобилось обновить некое значение в таблице в соответствии с URL. Скажем, статистику интернет-магазинов. Я создал временную таблицу из тех значений, по котороым будет вестись поиск, и значений, которые я буду вставлять в нужную мне таблицу. Дальше, идет INSERT сразу нескольких строк. Его очень просто собирать в цикле из массива. Например вот так:

$elements = array();
foreach ($aray as $url => $value) {
    $elements[] = '('.$db->escape($value).', '.$db->escape($url).')';
}
$insert_string = implode(',', $elements);

После чего, собственно апдейт со вставкой. Временная таблица исчезнет после окончания сессии БД. На то она и временная.

Закончилась моя суточная эпопея с Kohana, когда я пытался всего лишь работать с контроллером по имени Index. Проблема заключалась в том, что когда я заходил по адресу http://somesite.ru/kohana/index/save с надеждой, что выполнится контроллер index, метод save я получал ошибку о том, что мол страницы save-то и не существует. Особенно странно было то, что эта ошибка проявлялась только на рабочем сервере под Debian. Сначала я стал дебажить роутинг Коханы, но докопавшись до самых глубин, выяснилось, что Apache отдает неверный параметр сервера PATH_INFO, вместо 'index/save', в роутинг передавался просто 'save', и это уже трактовалось как контроллер. Я перепроверил на всех доступных мне shared хостингах, везде все было в порядке, кроме рабочего сервера.

Ладно, подумал я, и переустановил Apache. Но проблема не решилась. Ладно, снова подумал я, и включил unstable пакеты и установил распоследний Apache, но проблема по прежнему не решилась. Вот тут я уже стал впадать в панику. А я вам скажу, что было уже утро следующего дня, как я обнаружил проблему. Просмотрев конфиги Апача я не нашел ничего криминального. Я грешил уже и на mod_rewrite, и на Debian, и на все подряд.

Почти отчаявшись, я стал разбирать Апач по кусочкам, выключив все модули, кроме mod_rewite и mod_php. И вот тут все заработало. Выяснилось, что mod_negotitation считал, что раз я напрямую не указал index.php в URI, значит я ошибся. И милостливо переписывал имя контроллера index в index.php.

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