Development

Сразу отмечу, что я не имею никакого отношения к миру ruby. Изредка пишу простые скриптики для небольших личных нужд, не углубляясь ни в дебри языка, ни в его окружение. В очередной раз обновив с нуля систему, я снова столкнулся с задачей установки compass-а. И в очередной раз все стандартные способы надо мною надругались. Казалось бы, linuxmint ― это просто разновидность ubuntu, самого популярного репозитория, а значит установка популярной либы не должна быть проблемой. Но нет…

Установить compass можно как-минимум двумя способами. Первый это привычный нам aptitude: sudo aptitude install ruby-compass. Программа устанавливается без ошибок, и даже позволяет узнать её версию. Но вот работать отказывается на отрез, ругаясь на отсутствие какого fssm. Быстрый поиск решения проблемы результатов не дал. Выполнив sudo aptitude purge ruby-compass, я решил воспользоваться стандартным механизмом для ruby ― gem. Итак: gem install compass выбрасывает мне ошибку доступа. Дескать в /usr/… ему недостучаться, и он просит root-а. Такое поведение мне кажется странным, но ладно, ок, установим из под root-а. Установка проходит успешно, но вот сам compass после этого запускаться отказывается. Нужен root. Вот это уже действительно странно. 

В конечном счёте я нагуглил установку с таким вот ключём gem install --user-install compass. Установка прошла успешно. Но вот никаких удобных ссылок для запуска программы не было создано. Пришлось руками лепить ссылку к ~/.gem/ruby/1.9.1/gems/compass-1.0.1/bin/compass. Теперь всё работает. 

Самое удивительное, так это то, что далеко не каждый пакет из gem требует таких вот бубнов. И что на офиц. сайте compass-а предлагают не суетиться, и просто запустить gem install compass. Такие вот дела. 

После обновления на живом сервере с php5.3 до php5.5 столкнулся с неприятной проблемой. Socket-файл, для прослушивания nginx-ом, который создаёт при старте демон php5-fpm, стал недоступен для nginx, который запускается от www-data. Лечится это дело очень просто, необходимо в pool-конфиги добавить следующее:

listen.owner = www-data
listen.group = www-data
listen.mode = 0660

Думаю по названиям настроек всё более чем понятно. Жаль только, что когда я попробовал перенести эти настройки на уровень выше, в сам php-fpm.conf, демон споткнулся при старте. Так было бы удобнее.

Случайно обнаружил, что Chrome DevTools поддерживают нечёткий поиск по именам файлов на вкладке Sources. Поиск доступен также как и в SublimeText2 по комбинации Ctrl + P. Enjoy! :)

В очередной раз увидев как рисует браузер латинские буквы в 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.