Caller & Pry

2011-12-12T14:09:00+06:00

Когда у меня отказывают мозги, я берусь за отладчик. Если бы не необходимость писать код, я бы из него не вылезал вообще. И отсутствие толкового отладчика в Ruby меня до сих пор очень расстраивает.

Представим себе ситуацию: в трёх практически одинаковых контроллерах по совершенно идентичному набору параметров производятся абсолютно одинаковые действия. Результат этих действий - заполненная этими действиями форма добавления объекта в таблицу. Десять отличий между тремя вариантами найдены, вынесены в параметры, всё отлично заполняется, но: в двух случаях заполненные данные попадают куда надо, в третьем - хрррррр!

Начинаем копать всякие before_filter, фильтры в самой модели - ничего.

Отладчика, которым мне не больно и не противно было бы пользоваться, в наличии нет. (Любители IDE идут в обнимку с их IDE куда-нибудь, где java не тормозит под убунтой).

Итак, отладчика нет, а брэйкпоинт поставить надо. Аккуратно добавляем в исследуемую модель конструктор:

weird_model.rb

  def initialize(*args)
    binding.pry
    super
  end

и, как только pry выбрасывает нас в консоль, смотрим значение, возвращаемое caller.

В результате выяснилось, что второй экземпляр модели создавался во вьюхе. Баг пофикшен, блогпост написан, кому уходит луч поноса - тоже ясно.

Осталось вычистить все binding.pry и всю байду, которую добавил в процессе отладки.

Список используемой литературы

Папа, настрой nginx

2011-09-08T10:36:00+06:00

Есть задача, даже две. Первая - разобраться с настройкой nginx для отдачи rails-статики и балансировки двух (трёх, сколько нужно), mongrel-ов. Вторая - всё то же самое, но без mongrel, а с использованием passenger и, главное, через capistrano.

Nginx + mongrels

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

Убрал из дефолтной конфигурации все директивы server и upstream, оставил только директивы include - так гибче, если что.

##
# Virtual Host Configs
##

include /etc/nginx/conf.d/*.conf;
include /etc/nginx/sites-enabled/*;

Добавил в отдельный файл конфигурацию апстрима на двух монгрелах (важен был сам принцип, а не количество) и сервер:

upstream mongrel { # <-- имя upstream-а для ссылок на него
  server localhost:3000; # Первый mongrel
  server localhost:3001; # Второй mongrel
  # <-- добавить mongrel-ы по вкусу
}

server {
  listen           8084; # <-- номер порта
  server_name      ~^(?<subdomain>[-\w]+)\.lvh\.me$; # <-- Запоминаем subdomain
  access_log       off;

  location / {
    proxy_pass       http://mongrel;
    proxy_set_header Host $subdomain.lvh.me:8084; # <-- Передаём subdomain и port
  }

  location ~ ^/(image|stylesheet|javascript)s {
    root             /home/user_name/devel/rails/project_name/public;
  }
}

Отдельный пункт в первой задаче был - сохранить для использования в рельсовских контроллерах субдомен, пришедший в запросе. Что и было реализовано при помощи server_name с регулярным выражением и proxy_set_header с использованием пришедшего из регэкспа поля $subdomain. Без передачи параметра Host в запросе к приложению приходил параметр "mongrel" с никаким субдоменом, а без передачи порта возникали проблемы с открытием следующих страниц (редиректы, ссылки и т.п.)

Теперь заходим на organization_name.lvh.me:8084 и в приложение приходят запросы с указанным субдоменом и разбрасываются между монгрелами. Как-то так.

Capistrano, а потом passenger

На самом деле, мне просто хотелось лёгкого деплоя. И поэтому я решил что на другую машину я буду деплоить при помощи capistrano. А passenger всплыл уже потом.

Начинаем, как водится, с нуля:

$ cd /home/user_name/devel/rails/project_name
$ capify .
$ emacs -nw config/deploy.rb # <-- Вместо emacs используйте Ваш любимый редактор ;)

Полученный Capfile оставляем в покое, а вот с config/deploy.rb пришлось потанцевать, по целому ряду причин. Во-первых, мне категорически не хотелось использовать sudo при деплое, во-вторых, мне не хотелось вводить пароли при каждом деплое, в третьих, на удалённой машинке rvm был установлен из-под root-а.

Итак, берём deploy.rb и внимательно на него смотрим.

config/deploy.rb

### Где всё будет происходить
#
role :web, "195.151.207.37"                   # Машинка, куда всё будет деплоиться
role :app, "195.151.207.37"                   # Как правило, то же самое, что :web
role :db,  "195.151.207.37", :primary => true # А здесь будет лежать база данных


### Что ставим, куда ставим
#     1. Имя приложения
set :application,     "your_application_name"
#     2. Куда ставим
set :deploy_to,       "/home/user_name/deploy_path"
#     3. Откуда берём исходники
#        В нашем случае исходники лежали на bitbucket, но никто не запрещает держать
#        их на github или другом хостинге для исходников.
#
set :repository,      "ssh://hg@bitbucket.org/account_name/repository_name"
set :scm,             :mercurial
#     4. Кем ставим
#        Собой, любимым
set :user,        "user_name"
set :use_sudo,    false
#     5. Форвардим ssh-agent, чтобы удалённая машина знала, что это мы.
#        Разумеется, на удалённой машине должен лежать Ваш public key,
#        и на bitbucket - тоже
set :ssh_options, {:forward_agent => true}


### Bundler
#     1. bundle install автоматически
require 'bundler/capistrano'
#     2. bundle install в домашний каталог (чтобы не запускать рутом)
set :bundle_flags, "--deployment --quiet --path=/home/user_name/bundle"
#     3. bundle install, но с локальными настройками из $shared_path
before "bundle:install",     "bundler:config_symlink"
after  "deploy:setup",       "bundler:config_setup"

namespace :bundler do
  # Создаём каталог, куда будут сохраняться локальные настройки bundler-а
  #
  task :config_setup do
    run "mkdir -p #{shared_path}/bundler_config"
  end

  # Создаём линк на каталог, чтобы bundler не создавал ./.bundler по-новой
  #
  task :config_symlink do
    run "cd #{release_path} && ln -s #{shared_path}/bundler_config .bundle"
  end
end


### Копируем данные, лежащие в shared/config в свой config
#    config/database.yml, например
#
#    Не забудьте предварительно создать сам каталог и всё, что в нём должно лежать!
#
after  "deploy:update_code", "deploy:copy_config"

namespace :deploy do
  ### А этот код достаточно просто раскомментировать
  task :start do ; end
  task :stop do ; end
  task :restart, :roles => :app, :except => { :no_release => true } do
    run "touch #{File.join(current_path,'tmp','restart.txt')}"
  end

  task :copy_config do
    run "cp #{shared_path}/config/* #{release_path}/config/"
  end
end

Примерно так стал выглядеть deploy.rb на моей машинке (если комментарии не считать). В процессе мне пришлось разбираться, как настроить ssh-forwarding, как запускать на удалённой машине ssh-agent и как запускать passenger в standalone режиме и что man-ы и официальная документация are the developer's best friends.

И всё было почти хорошо. И деплой проходил, не заканчиваясь сообщением, что какая-то команда не прошла, но вот рестарт passenger-а не происходил. Вот если бы passenger-а можно было бы запускать с командной строки, указывая, в каком каталоге будет производиться запуск, тогда бы, возможно, следующую часть можно было бы и опустить. А так мне пришлось устанавливать passenger в конкретном gemset-е, в нём же запускать установку nginx-модуля для passenger и настраивать nginx уже на работу с /home/user_name/deploy_path/public.

$ sudo rvm 1.9.2@project gem install passenger
$ sudo rvm 1.9.2@project passenger-install-nginx-module
$ sudo rvm 1.9.2@project passenger-config --root # <-- Отсюда возьмём путь к passenger-у
$ sudo vi /opt/nginx/conf/nginx.conf             # <-- Да, иногда я пользуюсь vi. Особенно на удалённых машинах ;)

Дальше - правки, внесенные в /opt/nginx/conf/nginx.conf

http {
    # Сюда пишем то, что выдала команда passenger-config --root
    passenger_root /usr/local/rvm/gems/ruby-1.9.2-p290@crm/gems/passenger-3.0.9;
    # Эту строчку выставляет passenger-install-nginx-module (а откуда ещё я мог её взять?)
    passenger_ruby /usr/local/rvm/wrappers/ruby-1.9.2-p290@crm/ruby;
...
    # А вот этот кусочек я написал, глядя в руководство
    server {
      listen 80;
      server_name _;
      root /home/user_name/deploy_path/current/public;
      passenger_enabled on;
    }
...
}

Перезапускаем nginx и идём пить кефир.

Список используемой литературы

Пилим linkify tweet

2011-08-09T10:02:00+06:00

Допилил октопрессовский twitter.js, теперь в импортированных твитах выделяются тэги с кириллицей.

Вкратце, в регекспах, выбирающих тэги в твитах заменил (\w+) на ([\wа-яА-ЯёЁ]+). Для тех, кто не любит ковыряться в коде, полный вариант исходной и заменённой функции:

До допиливания - twitter.js

function linkifyTweet(text){
  return text.replace(/(https?:\/\/)([\w\-:;?&=+.%#\/]+)/gi, '<a href="$1$2">$2</a>')
    .replace(/(^|\W)@(\w+)/g, '$1<a href="http://twitter.com/$2">@$2</a>')
    .replace(/(^|\W)#(\w+)/g, '$1<a href="http://search.twitter.com/search?q=%23$2">#$2</a>');
}

После допиливания - twitter.js

function linkifyTweet(text){
  return text.replace(/(https?:\/\/)([\w\-:;?&=+.%#\/]+)/gi, '<a href="$1$2">$2</a>')
    .replace(/(^|\W)@([\wа-яА-ЯёЁ]+)/g, '$1<a href="http://twitter.com/$2">@$2</a>')
    .replace(/(^|\W)#([\wа-яА-ЯёЁ]+)/g, '$1<a href="http://search.twitter.com/search?q=%23$2">#$2</a>');
}

Оно работает! Но, блин, как..

2011-08-08T16:52:00+06:00

На днях исправлял чудесный, феерический баг в коде, уже успевшем стать древним (просто потому, что мой склероз прогрессирует заметно быстрее, чем я пишу код). Вкратце, берётся инпут, обвешивается несколькими способами обработчиками, после чего в инпут вводится значение и.. и обработчики не работают!

Через минут двадцать я обнаруживаю, что $(искомый инпут).data() - девственно пуст. Ещё получаса мне хватило на то, чтобы додуматься почесать скрипт grep-ом. И опаньки! В тот момент, когда инпут получает фокус я делаю (барабанная дробь) .unbind без параметров. (Старательно выношу матершинные слюни за скобки).

Никогда так не делайте - focus.js

$("input.dummy_data").focus(function() {
  $(this).
    val("").
    removeClass("dummy_data").
    unbind(); // Вот в этом месте все обработчики дружно собираются и уходят курить
});

Мораль сей басни - учите, господа, матчасть. В своё время я использовал .unbind чтобы второй раз не вызывать обработчик по событию .focus. И хотя самостоятельно отрубать себе же руки (хэндлы) я в виду не имел, но очень даже это сделал.

P.S.

Правильный вариант обработчика - focus.js

$("input.dummy_data").bind("focus.placeholder", {
  var $this = $(this);

  // Очищаем значение, как и планировалось
  $this.val("");

  // Убираем стиль, чтобы снять оформление
  $this.removeClass("dummy_data");

  // Аккуратно убираем обработчик события, не трогая остальные
  $this.unbind("focus.placeholder");
});