До недавнего времени я предполагал, что 1 кривой INSERT SQL-запрос c ON DUPLICATE KEY UPDATE, должен выполняться быстрее, чем 2400 простых UPDATE SQL-запросов. Но на деле оказалось, что пляски с ON DUPLICATE KEY очень сильно гасят производительность. Более того — 2400 простых INSERT-ов с 3 изменямыми полями выполняются всего за 500-1000ms.

Собственно макеты запросов. Вариант с ON DUPLICATE KEY:

INSERT tbl (id, f1, f2, f3)
VALUES (1, 1, '2', 3), (2, 4, '5', 6) ...
ON DUBLICATE KEY UPDATE f1=VALUES(f1), f2=VALUES(f2), f3=VALUES(f3);

Вариант с UPDATE-ом:

UPDATE tbl SET f1=1, f2='2', f3=6 WHERE id = 1

Возможно, есть более элегантный вариант сделать 2400 UPDATE-ов не по всем полям (что отсеивает REPLACE INTO), используя всего 1 запрос, но я его не знаю :(

UPD 0. Шеф подсказал, что можно поступить примерно следующим образом — сформировать временную таблицу, содержащую все изменяемые данные, а следующим запросом простым UPDATE-ом с JOIN-ом считать оттуда данные. Правда следует учесть все тонкости работы с временными таблицами в mySQL.

Knockout, безусловно, весьма мощная библиотека, которая позволяет сэкономить море времени, но некоторые моменты в её работе, мне показались неудобными. Про один из них эта заметка. Binding «click» просит указать метод, но особенности JavaScript-а, не позволяют удобным способом указать метод и объект this, для его вызова. В итоге мы имеем вот такие вот уродливые конструкции

<span data-bind="click: $root.save.bind($root)"></span>
<span data-bind="click: $root.edit.bind($root, 'someParameter')"></span>

У меня возникло желание как это дело упростить. Я решил остановиться на таком варианте:

<span data-bind="click: @save"></span>
<span data-bind="click: [@edit, 'someParameter']"></span>

Возможно, не очень очевидный синтаксис, но никто не мешает придумать свой :) Итак, задача состоит в том, чтобы заставить knockout эти конструкции принимать за нужный метод. Для этого воспользуемся хаком preprocess для binding-а click. У меня получилось примерно так:

    ko.bindingHandlers.click.preprocess = function( val )
    {
        val = $.trim( val );

        if( val[ 0 ] === '@' )
        {
            var method = val.substr( 1 );
            return 'function(){ return $root["' + method + '"].apply( $root, arguments ); }';
        }

        if( val[ 0 ] === '[' && val[ val.length - 1 ] === ']' )
        {
            val = $.trim( val.substr( 1, val.length - 2 ) );
            var params = val.split( /\s*,\s*/ );
            if( params[ 0 ] && params[ 0 ][ 0 ] === '@' )
            {
                var method = params.shift().substr( 1 );
                var args = params.join(', ');
                var js = 'function()\n' +
                    '{\n' +
                        '\tvar args = [ ' + params + ' ].concat( _.toArray( arguments ) );\n' +
                        '\treturn $root["' + method + '"].apply( $root, args );\n' +
                    '}';
                return js;
            }
        }

        return val;
    }

Решение пока черновое и не обкатанное. К тому же на click-е мир клином не сошёлся и нужно что-то более универсальное.

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

Какое то время хабрахабр был атакован десятками статей про различные RSS-агрегаторы, число которых росло как на дрожжах. Многие из них были написаны только из-за закрытия Google Reader-а. Самым популярным, как мне показалось, на тот момент был Feedly. Причём уже тогда у него была мобильная версия. Я попробовал 4-5 различных сервисов, в том числе и Feedly. Больше всего мне не понравился как раз он. Разработчики решли отойти от изначальной концепции и родить что-то своё, оригинальное и не на что не похожее. У них это получилось. Как этим пользоваться, я, право, так и не разобрался. В особенности в мобильнике. В итоге про Feedly я забыл и стал искать более googlereader-like аналоги. Названия их я не запомнил, почти все не умели чего то очень важного для меня, какой-то из них внезапно стал "чисто для своих", а некоторые закрылись. 

В итоге мой выбор пал на InoReader. Пользуюсь им уже где-то полгода-год и проблем не знаю. На какое то время, как мне показалось, на проект подзабили. Но пару месяцев назад все update-ы стали отображаться с просьбами обновить страницу, ну или посмотреть на список изменений. Был редизайн (в лучшую сторону). В конечном итоге получился довольно вкусный продукт. На мой взгляд лучший, чем был Google Reader. Посему рекомендую :)

подробности…

Перенеся сервер, на котором расположен deltaplan.kz, с apache2 на php-fpm, я столкнулся с неожиданной проблемой. Несмотря на правильным образом настроенные nginx конфиг и php-fpm pool GPS-подсайта — сервер упрямо, вместо того, чтобы запускать PHP файлы, возвращал их исходный код. Первым делом я вспомнил про security.limit_extensions = .php. Затем полез мучить различные fastcgi-параметры nginx хоста. Однако враг зашёл с другой стороны. Дело в том что в /etc/php5/fpm/php.ini по непонятным мне причинам был установлен short_open_tag: Off, в то время как XC Leonardo вовсю использует сокращённый вариант <? ?>. Разрешив эту опцию и перегрузив php5-fpm всё взлетело.

CKEditor - это WYSIWYG редактор HTML-кода для браузеров. Всякий раз, сталкиваясь с его документацией или же с его исходным кодом, с исходным кодом его плагинов я терялся. И это не мудрено, ведь CKEditor это очень большой продукт, имеющий довольно сложную инфраструктуру. Но, зачастую, стандартных возможностей не хватает и требуется добавить свою. В этой статье я хотел бы остановиться на плагине, который позволяет встраивать и оперировать в редакторе Yandex-картами. Вот так это будет выглядеть по окончанию редактирования:

подробности…