Экономия на числе запросов
До недавнего времени я предполагал, что 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 и this
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-е мир клином не сошёлся и нужно что-то более универсальное.
InoReader как замена усопшему Google Reader-у
В прошлом, кажется, году Google приняла решение убить свой успешный продукт — Google Reader, который к этому моменту, успели полюбить миллионы, если не десятки миллионов. Причины указаны не были, но народ решил, что всё дело в не очень большой популярности их социальной сети Google+. В любом случае проект закрыли, а необходимость удобно читать и не только RSS никуда не исчезла.
Какое то время хабрахабр был атакован десятками статей про различные RSS-агрегаторы, число которых росло как на дрожжах. Многие из них были написаны только из-за закрытия Google Reader-а. Самым популярным, как мне показалось, на тот момент был Feedly. Причём уже тогда у него была мобильная версия. Я попробовал 4-5 различных сервисов, в том числе и Feedly. Больше всего мне не понравился как раз он. Разработчики решли отойти от изначальной концепции и родить что-то своё, оригинальное и не на что не похожее. У них это получилось. Как этим пользоваться, я, право, так и не разобрался. В особенности в мобильнике. В итоге про Feedly я забыл и стал искать более googlereader-like аналоги. Названия их я не запомнил, почти все не умели чего то очень важного для меня, какой-то из них внезапно стал "чисто для своих", а некоторые закрылись.
В итоге мой выбор пал на InoReader. Пользуюсь им уже где-то полгода-год и проблем не знаю. На какое то время, как мне показалось, на проект подзабили. Но пару месяцев назад все update-ы стали отображаться с просьбами обновить страницу, ну или посмотреть на список изменений. Был редизайн (в лучшую сторону). В конечном итоге получился довольно вкусный продукт. На мой взгляд лучший, чем был Google Reader. Посему рекомендую :)
PHP-FPM и short_open_tag
Перенеся сервер, на котором расположен 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 4
CKEditor - это WYSIWYG редактор HTML-кода для браузеров. Всякий раз, сталкиваясь с его документацией или же с его исходным кодом, с исходным кодом его плагинов я терялся. И это не мудрено, ведь CKEditor это очень большой продукт, имеющий довольно сложную инфраструктуру. Но, зачастую, стандартных возможностей не хватает и требуется добавить свою. В этой статье я хотел бы остановиться на плагине, который позволяет встраивать и оперировать в редакторе Yandex-картами. Вот так это будет выглядеть по окончанию редактирования: