:-)
  • PHP 05.02.2010 2 Comments

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

    Tags: , ,

  • *nix, PHP 05.02.2010 2 Comments

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

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

    Tags: , , , ,

  • *nix, PHP 05.02.2010 No Comments

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

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

    Tags: , , ,

  • JS 04.02.2010 2 Comments

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

    Tags: , , ,

  • SQL 29.01.2010 No Comments

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

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

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

    Tags: ,

  • *nix, PHP, SQL 21.01.2010 No Comments

    Такая ошибка возникла у меня после перехода на 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

    Tags: , , ,

  • Мне нужно было получать строку из файла по порядковому номеру. То есть первую, десятую, 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, она уже была привязана к никсам, так что хуже мне не стало.

    Tags: ,

  • SQL 01.12.2009 10 Comments

    Если вы хотите делать массовый апдейт в 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);

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

    Tags:

  • Apache 26.11.2009 4 Comments

    Закончилась моя суточная эпопея с 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.

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

    Tags: , ,