komagataのブログ

% node -v  
v0.4.8
% rails -v
Rails 3.1.0
% rails new foo
% cd foo
% vi app/assets/stylesheets/foo.css.scss
body {
  background: image-url("rails.png");
}
% rake assets:precompile
rake aborted!
rails.png isn't precompiled
  (in /Users/komagata/tmp/foo/app/assets/stylesheets/foo.css.scss)

Tasks: TOP => assets:precompile
(See full trace by running task with --trace)

何故だろう？

とりあえずはconfig/environments/production.rbをconfig.assets.compile = true

にしてLive compileして凌いでいる。

追記：

rails3.1のバグでした。3.1.1を待て。

@kakutaniさんからpull requestが来てたので改めて、holiday_jpについて。

2009年に仕事で必要になって作ったgemです。祝日が必要なソフトウェアは結構あると思いますが、こんな調査に時間を割くのは一人でいいんで共有できればと。

祝日は法律によって増えたり減ったりするので未来に渡って計算で算出することができません。

休日・祝日の定義について

休日は単に休みの日です。祝日は”国民の祝日を定める法律”で規定されるお祝いのための休日です （土日は祝日ではありません）。皇室の祭典を行った大祭日などが元になっています。

立春の日・秋分の日について

また厄介なのが立春の日と秋分の日です。基本的には国立天文台の算出する定気法による日（天体の動き）から決定されるため「ほぼこの日だろう」という日は分かりますが、実際には前年度の2月1日に閣議決定され、官報で告知されるまで確かなことはわかりません。（天文学に基づいて年毎に国家の祝日が決定されるのは世界的に見ても珍しいそうです。）

つまり、「現行法に置いては」という但し書きをつけても、日本の祝日は１年先までしかわからないということです。

「１年毎に誰かがメンテナンスする必要があるのであればgithubとかあるし100年分ぐらいgemの中に持っちゃえばいいじゃん。」

ということでholiday_jpができました。

関連：holiday_jp - 国民の祝日が分かるライブラリ - komagata

ヒャッハー！ruby1.9.3preview1で動かねえところもたまらねえぜ。

Write below If you want to hide address bar on iPhone or Android.

window.scrollTo(0, 1)

Lokkathon #5 : ATND

LokkathonはLokka + Hack + Marathonです。 Lokkaに関する作業をモクモクとするイベントです。会場は用意されますが、Lingrのチャットのみでの参加も可能です。（むしろ推奨）

毎週やってるLokkathon #5、明日もやります。リモート参加も歓迎です。（リモート参加の場合はATND登録しなくて大丈夫です。）腹減るので食べてくるのがオススメです。

成果は毎回下記のようにlokka.orgのエントリーになるのでリモートでも何かやった方はURLとかスクリーンショットをLingrにいただければ載せていきたいと思います。（活動してるプロジェクト感を維持するために・・・）

Lokkathon #3 - Lokka

module Foo
  module Helpers
    def bar
      'unk'
    end
  end
end

こういうHelpersを

helpers do
  include Foo::Helpers
end

こういう風に使ってた場合。

RSpec.configure do |config|
  config.include Foo::Helpers
end

describe Foo::Helpers do
  context 'bar' do
    it 'should return unk' do
      bar.should eql('unk')
    end
  end
end

Spec::Runner.configでincludeするとテスト出来る。

LokkaはSinatraベースなので同じようにHelpersのテスト書ける。でもRspecややこしいな。config.includeのとことか。とTest::Unit, Shoulda信者が申しております。

先週、怖話.jpのランキングを重いサブクエリを書いて実装しましたが、Rails3レシピブック（Recipe 093 カウンタキャッシュを利用する）を見ていたらcounter_cacheというので簡単に速くなりそうだったのでやってみた。

ASCIIcasts - “Episode 23 - Counter Cache Column”

要はfoo has many barsという関係の時にbarのbelongs_toに:counter_cache => trueと書いて、fooのDBにbars_countというカラムを追加すればいいらしい。

怖い話（story）に付いている怖い（scare）とコメント（comment）の集計にcounter_cacheを使ってみた。

class Scare < ActiveRecord::Base
  belongs_to :story, :counter_cache => true
end

class Comment < ActiveRecord::Base
  belongs_to :story, :counter_cache => true
end

class AddCounterCacheToStories < ActiveRecord::Migration
  def self.up
    add_column :stories, :comments_count, :integer, :null => false, :default => 0
    add_column :stories, :scares_count, :integer, :null => false, :default => 0

    Story.all.each do |story|
      Story.update_counters(story.id, :comments_count => story.comments.count)
      Story.update_counters(story.id, :scares_count => story.scares.count)
    end
  end

  def self.down
    remove_column :stories, :comments_count
    remove_column :stories, :scares_count
  end
end

counter_cacheはfooのcreateとdestroyのコールバックとして数を増減するというだけの動作なので、後付けする場合はupdate_countersメソッドで集計し直してやる必要がある。

class Story < ActiveRecord::Base
  scope :order_by_ranking, joins(:user).order("view + (select count(*) from scares where scares.story_id = stories.id) * #{Scare::RANKING_WEIGHT} + (select count(*) from comments where comments.story_id = stories.id) * #{Comment::RANKING_WEIGHT} desc, stories.id desc").includes(:user)
end

お陰でこんな醜悪なクエリが、

class Story < ActiveRecord::Base
  # scares_count and comments count is using counter_cache.
  scope :order_by_ranking, joins(:user).order("view + scares_count * #{Scare::RANKING_WEIGHT} + comments_count * #{Comment::RANKING_WEIGHT} desc, stories.id desc").includes(:user)
end

ホッとするシンプルなクエリに。

しかし、キャッシュ系によくあることですが、カウンタキャッシュを使っているということをちゃんと意識してないと端からみたらわかり辛いことになるので、現在は一人開発ですが、将来の自分を含めた他人に向けて注意を喚起するコメントを残しておくことにしました。

rails + jenkinsでgithubにpushしたらテストというところまでは下記を参照してください。

• Testing Rails apps with Jenkins - komagata
• GithubにpushしたらJenkinsでビルドする - komagata

ウェブオペレーションで継続的デプロイというキャッチーな単語を知ったので試してみた。

継続的デプロイなんつっても、上記の様にいつものテストにcapのタスクを追加するだけ。簡単。

githubにpushされると勝手にjenkinsが動き出して…

ステージング環境にデプロイ。

これでデザイナーの@machidaさんがgit pushした時も勝手にステージング環境が最新になる。デザインが変わっただけでも頻繁にデプロイされるので問題点などが議論し易い。（特にスマホサイトは実機からアクセス出来る環境があると便利。）

最近はデザイナーも簡単にGithubが使える環境が揃ってきたので、テスト・開発・チェックイン・デプロイというサイクルにデザイナーが入る良いタイミングかも。

デザイナーのためのGithub for Mac の使い方「リポジトリ作成編」 - KUROIGAMEN(黒い画面)

% rake
`include Capybara` is deprecated please use `include Capybara::DSL` instead.

include Capybaraがdeprecatedになってたので指示通り書き換えました。

# test/test_helper.rb:
class ActiveSupport::TestCase  
  (...)
  class ActionDispatch::IntegrationTest 
    include Capybara::DSL      
    Capybara.app = KowabanaJp::Application
  end
end

Unit::TestとCapybaraでのIntegrationTestは簡単なのにちゃんと動く（バグを見つけたりデグレを防ぐ役割をちゃんと果たすという意味で）のでお気に入りです。

unicornのデフォルトとportが被ってるので変更した。Debianパッケージ版jenkinsは下記に設定がある。

# /etc/defaults/jenkins:
# port for HTTP connector (default 8080; disable with -1)
#HTTP_PORT=8080
HTTP_PORT=8000