Development

В очередной раз увидев как рисует браузер латинские буквы в microsoft-овском шрифте Calibri, решил это дело как-нибудь починить. Эксперементальным путём выяснил, что шрифт в системе есть, и что браузеры его правильно подхватывают, что уродливыми края у букв становятся только у латинских символов, и что только при размере <=16px. В итоге Google дал мне такой ответ:

Calibri fonts and other cleartype fonts have bitmap versions embedded in them which activate at small sizes, which makes it look bad. To disable this and get correct smoothing at all sizes do this:

Create a .fonts.conf file in your home directory, paste this in it:

<match target="font">
  <edit name="embeddedbitmap" mode="assign">
      <bool>false</bool>
  </edit>
</match>

Перезагрузив браузер (похоже, что для Chromium-а теперь это тривиально сделать невозможно, т.к. он работает аки daemon, но никаких иконок в tray-е не рисует) — убедился что уродливые границы исчезли. 

До недавнего времени я предполагал, что 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 всё взлетело.