Design Recipe 別館 Blog - Home

マスターの導きを受けつつ、TDD で Ruby を学びながら悟りを開く - Koans

2011-08-14T14:55:00Z

Koans とは

クイズ形式で Ruby を学ぶ Koans。その手法がなかなか凝っている。

Learn Ruby with the EdgeCase Ruby Koans
ここでは上記からダウンロードできる 2010/12/23 日版を利用した。
- edgecase/ruby_koans - GitHub
  GitHub でソースは管理されている。

The goal is to learn the Ruby language, syntax, structure, and some common functions and libraries. We also teach you culture. Testing is not just something we pay lip service to, but something we live. It is essential in your quest to learn and do great things in the language.

Koans は Ruby 言語の文法、構造、そして、幾つかの共通関数やライブラリを学ぶことをゴールとしたもので、TDD の手法を用いてそれを実現している。

path_to_enlightenment.rb というファイルを起動することで、あるテストケースがカルマにダメージを与えたとのメッセージが表示され、マスターから助言を授かることになる。
表示されるメッセージを頼りにテストケースをパスするように修正していくことで、次の新たな設問(新たなカルマへのダメージ)へと進み、30ちょっとのカテゴリの計272問(2010/12/23版)の設問をクリアすることで悟りをひらけることになる。

設問をクリアしていく過程は以下のようになる。
例えば2番目の設問は以下の通りとなっている。

マスターが「君はまだ悟りをひらいていない」と言っている。”The answers you seek…” ということで “This shoud be true – Please fix this” とある。
「please meditate on the following code:」ということで、about_asserts.rb:16:in test_assert_with_message’` が指定されているので、該当ファイルの該当行を確認すると、

  # Enlightenment may be more easily achieved with appropriate
  # messages.
  def test_assert_with_message
    assert false, "This should be true -- Please fix this"  # line: 16
  end

assert が false となっている。当然これではテストは通らないので、true に書き変えて保存する。

再度 path_to_enlightenment.rb を起動してあげると、

$ ruby path_to_enlightenment.rb 
AboutAsserts#test_assert_truth has expanded your awareness.
AboutAsserts#test_assert_with_message has expanded your awareness.
AboutAsserts#test_assert_equality has damaged your karma.

The Master says:
  You have not yet reached enlightenment.
  You are progressing. Excellent. 2 completed.

The answers you seek...
  Failed assertion, no message given.

Please meditate on the following code:
  /home/hoge/Dropbox/work/koans/about_asserts.rb:25:in `test_assert_equality'

learn the rules so you know how to break them properly
your path thus far [.X________________________________________________] 2/274

次の設問へと続く。

基本は、テストケースのアサーションの期待値を埋めていくことで設問に答えていくことになる。

メッセージ(“The ansers you seek…“)に既に答えが出てしまってはいるが、そこはじっくり読まずに、テストケースとテストメソッド名の方に集中して何を学ばせようとしているのか頭の片隅に置きながら期待値を考えていると、よく考えられた設問になっているなぁと感心してしまう。

最初の方こそ上記のようなホントに初歩的な設問だが、徐々に内容が濃くなってくるので、なかなか良い復習、勉強になる。

また、一気に 274 問実施するのは流石にキツイので、できる時間に少しづつ実施することが可能な作りになっているのもうれしい。何問目まで回答できているかは .path_progress というファイルが覚えておいてくれているので、特に意識することなく、path_to_enlightenment.rb を起動すれば前回の設問から続きを行うことができる。

watchr を使って回答に集中

設問に答えては path_to_enlightenment.rb を起動するというのはメンドイ。
自動化しておく。

watchr gem を使うとファイルを監視下におき、編集された際に実行させたいことを定義することができる。回答を記述するファイルを編集するたびに自動的に path_to_enlightenment.rb が実行されるようにしておく。

watchr をインストールしていない場合はインストールしておく。

$ sudo gem install watchr

path_to_enlightenment.rb と同じディレクトリに以下のファイルを用意しておく。

koans.watchr:

def run
  system("clear; ruby path_to_enlightenment.rb")
end

watch('.*\.rb$') { run }
run

watchr を起動しておく。

$ watchr koans.watchr

これで回答を行うファイルを編集する度にコンソールがリフレッシュされ path_to_enlightenment.rb の結果を確認することができる。

`triangle.rb`

大半は assertion の期待値を埋めていくのだが、テストケースを通す為の関数を書く設問もある。

以下の2問。

設問その1：about_triangle_project.rb

class AboutTriangleProject < EdgeCase::Koan
  def test_equilateral_triangles_have_equal_sides
    assert_equal :equilateral, triangle(2, 2, 2)
    assert_equal :equilateral, triangle(10, 10, 10)
  end

  def test_isosceles_triangles_have_exactly_two_sides_equal
    assert_equal :isosceles, triangle(3, 4, 4)
    assert_equal :isosceles, triangle(4, 3, 4)
    assert_equal :isosceles, triangle(4, 4, 3)
    assert_equal :isosceles, triangle(10, 10, 2)
  end

  def test_scalene_triangles_have_no_equal_sides
    assert_equal :scalene, triangle(3, 4, 5)
    assert_equal :scalene, triangle(10, 11, 12)
    assert_equal :scalene, triangle(5, 4, 2)
  end
end

設問その2：about_triangle_project_2.rb

class AboutTriangleProject2 < EdgeCase::Koan
  # The first assignment did not talk about how to handle errors.
  # Let's handle that part now.
  def test_illegal_triangles_throw_exceptions
    assert_raise(TriangleError) do triangle(0, 0, 0) end
    assert_raise(TriangleError) do triangle(3, 4, -5) end
    assert_raise(TriangleError) do triangle(1, 1, 3) end
    assert_raise(TriangleError) do triangle(2, 4, 2) end
 end
end

設問その1のテストの要件を満たす関数を用意し、かつ、設問その2の制約もパスする必要がある。

答えは提供されていない(見つけられなかった。。)ので、ベストアンサーかどうかはわからないが、以下の関数を書くことでテストをパスしている。
ツッコミありましたらご指摘願いたい。

triangle.rb:

def triangle(a, b, c)
  raise TriangleError.new if [a, b, c].any? { |e| e <= 0 }
  raise TriangleError.new if ((a + b) <= c) || ((a + c) <= b) || ((b + c ) <= a)

  case [a, b, c].uniq.size
    when 1 then :equilateral
    when 2 then :isosceles
    else :scalene
  end
end

Rack アプリケーション向けの HTTP サーバ Unicorn の基本操作

2011-07-30T14:55:00Z

Unicorn とは？

Rails、Rack アプリケーションを動作させるコンテナとしては、Passenger、Thin、Mongrel などの選択肢がある。それ以外にも Unicorn という Rack アプリケーション向けの HTTP サーバがあり、今回試しに使ってみたのでそのメモ。

Unicorn: Rack HTTP server for fast clients and Unix

設計方針に特徴的な部分があり、以下の記事に詳しい。

Unicorn! - GitHub
Unicorn を使用している github の記事
UnicornでSinatraアプリをデプロイしてみた - 射撃しつつ前転

github の記事の結論で書かれているが、

Passenger is awesome. Mongrel is awesome. Thin is awesome.

Use what works best for you. Decide what you need and evaluate the available options based on those needs. Don’t pick a tool because GitHub uses it, pick a tool because it solves the problems you have.

それぞれの HTTP サーバが良い点を持っており、自身のサービスの用途、目的に応じて適切なものを使用するのがよいでしょうと。

サーバの良し悪しを測る項目の1項目として ab を使ったベンチなどがよくとられている。確かにスループットにある程度のレベルのものは要求したいが、それよりも運用に入った際の安定性、信頼性、何か問題が起きた際のリカバリ含めた可用性の部分を気にしていた。

今回 Unicorn を試してみようと思ったのは、そこにあり、先の記事にも、以下の記載があり、Unicorn を試してみることにした。

Honestly, I don’t care. I want a production environment that can gracefully handle chaos more than I want something that’s screaming fast. I want stability and reliability over raw speed.

ここで記載するのは Unicorn を動作させるまでの基本的な設定と Unicorn を操作する基本的なオペレーションのメモになる。

Unicorn のインストールと事前準備
Unicorn の設定ファイルを用意する
Unicorn サーバを起動する
nginx と Unicorn を連携する
Unicorn を停止する
Unicorn の設定の再読込
サービスの提供を止めずにプログラムの再読込

Unicorn のインストールと事前準備

今回のお試し環境は以下の通りとなる。

アプリには簡単な Sinatra Hello World アプリを使用
Unicorn サーバのフロントは nginx をリバースプロキシとしてたてる

Unicorn 以外に nginx と Sinatra gem がインストールされている必要がある。

Unicorn は RubyGems で提供されているので gem コマンドを使用してインストールする。

# gem install unicorn

動作環境のサンプルとして Sinatra アプリケーションを用意する。
(Sinatra がインストールされていない場合には、# gem install sinatra が必要。)

適当なディレクトリ($APP_DIR)に Rack アプリケーションのエントリポイントとなるファイル config.ru を用意し、簡単な HelloWorld アプリケーションを記述しておく。

$APP_DIR/config.ru:

require 'rubygems'
require 'sinatra/base'

class HelloApp < Sinatra::Base
  get '/hello' do
    'Hello World'
  end
end

run HelloApp

Rack の rackup コマンドを使用して、上記のアプリがきちんと動作することを確認しておく。

$ cd $APP_DIR
$ rackup
[2011-07-30 21:15:38] INFO  WEBrick 1.3.1
[2011-07-30 21:15:38] INFO  ruby 1.9.2 (2011-02-18) [i686-linux]
[2011-07-30 21:15:38] INFO  WEBrick::HTTPServer#start: pid=6260 port=9292

ブラウザから、http://localhost:9292/hello の URI で “Hello World” が表示されることを確認しておく。

Unicorn の設定ファイルを用意する

Unicorn は unicorn コマンドを使って起動するが、起動時に設定ファイルを指定して起動することができる。
設定例は、Class: Unicorn::Configurator からリンクのある以下のページで確認できる。

上記の最低限の設定を設定を流用し、以下の設定ファイルを用意する。
Unicorn は TCP/IP ソケットでも待機できるが、以下の設定では Unix ドメインソケットを使った設定のみとしている。

$APP_DIR/unicorn.conf:

worker_processes 2

listen '/tmp/unicorn.sock'

stderr_path File.expand_path('unicorn.log', File.dirname(__FILE__))
stdout_path File.expand_path('unicorn.log', File.dirname(__FILE__))

preload_app true

ログファイルの記載部分を見てもらえるとわかるが、Unicorn の設定ファイルには Ruby の構文が利用可能となっている。

Unicorn サーバを起動する

Unicorn サーバを起動する。
unicorn コマンドを利用して起動することになる。$APP_DIR に移動して、以下のコマンドで起動する。

$ unicorn -c unicorn.conf -D

先ほど作成した Unicorn の設定ファイルを -c オプションで指定し、-D オプションでデーモン起動を行っている。

unicorn はデフォルトで config.ru をアプリケーションのエントリポイントとして認識するので、起動時のディレクトリに存在する Sinatra で書かれた Rack アプリケーションである $APP_DIR/config.ru が上記のコマンドで読み込まれている。

ログファイルを確認してみる。

$ cat unicorn.log
I, [2011-07-30T21:50:47.966116 #6632]  INFO -- : unlinking existing socket=/tmp/unicorn.sock
I, [2011-07-30T21:50:47.966669 #6632]  INFO -- : listening on addr=/tmp/unicorn.sock fd=3
I, [2011-07-30T21:50:47.967666 #6632]  INFO -- : Refreshing Gem list
I, [2011-07-30T21:50:48.343228 #6632]  INFO -- : worker=0 spawning...
I, [2011-07-30T21:50:48.343795 #6632]  INFO -- : worker=1 spawning...
I, [2011-07-30T21:50:48.344260 #6632]  INFO -- : master process ready
I, [2011-07-30T21:50:48.344266 #6635]  INFO -- : worker=0 spawned pid=6635
I, [2011-07-30T21:50:48.344450 #6635]  INFO -- : worker=0 ready
I, [2011-07-30T21:50:48.344672 #6638]  INFO -- : worker=1 spawned pid=6638
I, [2011-07-30T21:50:48.344863 #6638]  INFO -- : worker=1 ready

エラーが表示されておらず、上記のようなログが出力されていれば問題なく起動が行えている。 master プロセスが1つ上がり、worker プロセス2つを起動している。

nginx と Unicorn を連携する

フロントでリクエストを処理する nginx の設定。

最低限の設定というところで、以下の設定を記述する。

upstream ディレクティブ(ロードバランシングの指定)で unicornapp というバックエンドサーバを定義し、Unicorn サーバの Unix ドメインソケットを指定しておく。
location ディレクティブで upstream に指定した unicornapp バックエンドサーバを指定する

upstream unicornapp {
  server unix:/tmp/unicorn.sock;
}

server {
        listen   80;
        server_name localhost;

        location / {
               proxy_pass http://unicornapp;
        }
}

nginx 設定ファイルの再読込を行い、ブラウザで http://localhost/hello の URI を参照すると先ほどの rackup コマンドを使用して確認した “Hello World” と同じメッセージの画面が表示されていることが確認できる。
(ここで確認している画面は Unicorn で提供されているサービス)

unicorn のログにもリクエストを処理したメッセージが確認できる。

$ tail -f unicorn.log
...
I, [2011-07-30T22:13:27.755913 #7306]  INFO -- : worker=1 ready
I, [2011-07-30T22:13:27.756925 #7303]  INFO -- : worker=0 spawned pid=7303
I, [2011-07-30T22:13:27.757150 #7303]  INFO -- : worker=0 ready
127.0.0.1 - - [30/Jul/2011 22:13:39] "GET /hello HTTP/1.0" 200 11 0.0155

以上で基本的な設定はおしまい。

Unicorn を停止する

Unicorn に対する操作は基本 Unicorn の master プロセスに対してのシグナルでの操作となる。

まずは停止方法。2つの停止方法がある。

プロセスを即座に終了する: INT/TERM シグナルを使用
処理を行っているリクエストが完了するのを待ってプロセスを終了する: QUIT シグナルを使用

$ ps -ef | grep unicorn | grep -v grep
hoge      7299     1  0 22:13 ?        00:00:04 unicorn master -c unicorn.conf -D
hoge      7303  7299  0 22:13 ?        00:00:03 unicorn worker[0] -c unicorn.conf -D
hoge      7306  7299  0 22:13 ?        00:00:03 unicorn worker[1] -c unicorn.conf -D

上記でわかるように、master プロセスは 7299 のプロセスIDで動作している。master プロセスに対してシグナルを送る。

Unicorn を gracefully に終了させる場合、

$ kill -QUIT 7299

unicorn.log を確認。

I, [2011-07-30T23:32:13.866125 #7299]  INFO -- : reaped #<Process::Status: pid 7303 exit 0> worker=0
I, [2011-07-30T23:32:13.866403 #7299]  INFO -- : reaped #<Process::Status: pid 7306 exit 0> worker=1
I, [2011-07-30T23:32:13.866683 #7299]  INFO -- : master complete

2つの worker プロセスと master プロセスが終了したことがわかる。

Unicorn の設定の再読込

Unicorn の設定を再読込させる場合は、master プロセスに HUP シグナルを送る。

$ kill -HUP <master のプロセスID>

ログを確認してみると、再読みされていることが確認できる。

I, [2011-07-30T23:35:42.261177 #7768]  INFO -- : reloading config_file=unicorn.conf
I, [2011-07-30T23:35:42.272338 #7768]  INFO -- : Refreshing Gem list
I, [2011-07-30T23:35:42.557187 #7768]  INFO -- : done reloading config_file=unicorn.conf
I, [2011-07-30T23:35:42.557362 #7768]  INFO -- : reaped #<Process::Status: pid 7773 exit 0> worker=0
I, [2011-07-30T23:35:42.557432 #7768]  INFO -- : reaped #<Process::Status: pid 7776 exit 0> worker=1
I, [2011-07-30T23:35:42.557545 #7768]  INFO -- : worker=0 spawning...
I, [2011-07-30T23:35:42.558136 #7768]  INFO -- : worker=1 spawning...
I, [2011-07-30T23:35:42.558726 #7782]  INFO -- : worker=0 spawned pid=7782
I, [2011-07-30T23:35:42.558966 #7782]  INFO -- : worker=0 ready
I, [2011-07-30T23:35:42.559173 #7785]  INFO -- : worker=1 spawned pid=7785
I, [2011-07-30T23:35:42.559430 #7785]  INFO -- : worker=1 ready

サービスの提供を止めずにプログラムの再読込

プログラム(ここで言う Sinatra Hello World アプリ)を再配置するときなど、再度プログラムをロードし直す必要がある。
Unicorn サーバを停止して、再起動でもよいが、サービスの提供を止めずに実施する場合の実施方法は以下の方法となる。

現在のプロセスの状況は以下の通り。

$ ps -ef | grep unicorn | grep -v grep
hoge      7768     1  0 23:35 ?        00:00:00 unicorn master -c unicorn.conf -D
hoge      7782  7768  0 23:35 ?        00:00:00 unicorn worker[0] -c unicorn.conf -D
hoge      7785  7768  0 23:35 ?        00:00:00 unicorn worker[1] -c unicorn.conf -D

ここで何らかのアプリの改修があり、プログラムを再配置したとする。

Unicorn では、既存のプロセスをそのまま残し、新たな Unicorn サーバのセットをもう一セット作成し、リクエストの処理もそちらに引き継いであげることができる。

まず現在の master プロセスに USR2 シグナルを送る。

$ kill -USR2 7768

Unicorn のプロセスを確認してみる。

$ ps -ef | grep unicorn | grep -v grep
hoge      7768     1  0 23:35 ?        00:00:01 unicorn master (old) -c unicorn.conf -D
hoge      7782  7768  0 23:35 ?        00:00:00 unicorn worker[0] -c unicorn.conf -D
hoge      7785  7768  0 23:35 ?        00:00:00 unicorn worker[1] -c unicorn.conf -D
hoge      7822  7768  1 23:43 ?        00:00:00 unicorn master -c unicorn.conf -D
hoge      7826  7822  0 23:43 ?        00:00:00 unicorn worker[0] -c unicorn.conf -D
hoge      7829  7822  0 23:43 ?        00:00:00 unicorn worker[1] -c unicorn.conf -D

元々あったプロセス(master pid: 7768)に old という表示が入っており、Unicorn サーバのセットがもうワンセット追加されていることがわかる。

新たに生成されたプロセスには、プログラムの更新が反映されている。

この時の Unicorn の動作をログで確認してみると以下の動作になっている。

I, [2011-07-30T23:43:20.117449 #7822]  INFO -- : executing ["/home/hoge/.rvm/gems/ruby-1.9.2-p180/bin/unicorn", "-c", "unicorn.conf", "-D"] (in /home/hoge/Dropbox/work/unicorn-app-sample)
I, [2011-07-30T23:43:20.117641 #7822]  INFO -- : forked child re-executing...
I, [2011-07-30T23:43:20.798555 #7822]  INFO -- : inherited addr=/tmp/unicorn.sock fd=3
I, [2011-07-30T23:43:20.798829 #7822]  INFO -- : Refreshing Gem list
I, [2011-07-30T23:43:21.165052 #7822]  INFO -- : worker=0 spawning...
I, [2011-07-30T23:43:21.165798 #7822]  INFO -- : worker=1 spawning...
I, [2011-07-30T23:43:21.166209 #7826]  INFO -- : worker=0 spawned pid=7826
I, [2011-07-30T23:43:21.166311 #7822]  INFO -- : master process ready
I, [2011-07-30T23:43:21.166401 #7826]  INFO -- : worker=0 ready
I, [2011-07-30T23:43:21.166635 #7829]  INFO -- : worker=1 spawned pid=7829
I, [2011-07-30T23:43:21.166768 #7829]  INFO -- : worker=1 ready

新しいプロセスにリクエストの受付処理は引き継がれているので、古い方のプロセスを落としていく。

まずは、古い方の master プロセスに WINCH シグナルを送り、その worker プロセスを落としてあげる。 WINCH シグナルはその master プロセスの worker プロセスを gracefully に止めてあげる。

$ kill -WINCH 7768

プロセスとログを確認してみる。

$ ps -ef | grep unicorn | grep -v grep
hoge      7768     1  0 23:35 ?        00:00:01 unicorn master (old) -c unicorn.conf -D
hoge      7822  7768  0 23:43 ?        00:00:01 unicorn master -c unicorn.conf -D
hoge      7826  7822  0 23:43 ?        00:00:00 unicorn worker[0] -c unicorn.conf -D
hoge      7829  7822  0 23:43 ?        00:00:00 unicorn worker[1] -c unicorn.conf -D

I, [2011-07-30T23:48:45.648299 #7768]  INFO -- : gracefully stopping all workers
I, [2011-07-30T23:48:45.678491 #7768]  INFO -- : reaped #<Process::Status: pid 7782 exit 0> worker=0
I, [2011-07-30T23:48:45.678664 #7768]  INFO -- : reaped #<Process::Status: pid 7785 exit 0> worker=1

確かに、古い方の Unicorn のプロセスは、master プロセスだけが残り、worker は全て終了している。

一旦ここで念のため、アプリがキチンと動作しているか確認しておく。
問題無いようであれば、古い master プロセスも止めてあげる。

$ kill -QUIT 7768

プロセスとログを確認してみる。

$ ps -ef | grep unicorn | grep -v grep
hoge      7822     1  0 23:43 ?        00:00:01 unicorn master -c unicorn.conf -D
hoge      7826  7822  0 23:43 ?        00:00:00 unicorn worker[0] -c unicorn.conf -D
hoge      7829  7822  0 23:43 ?        00:00:00 unicorn worker[1] -c unicorn.conf -D

I, [2011-07-30T23:51:35.694051 #7768]  INFO -- : master complete

これで、新しいプログラムで Unicorn サーバが動作している状態となる。

情報の集約とコミュニケーションの円滑化 - チームの情報のハブになる便利なツール Flowdock

2011-07-08T15:35:00Z

チーム内で扱われる情報を一箇所に集約し、リアルタイムにそれらの情報についてコミニュケーションをとれるようなツールはないだろうか？たまたまフォローしている方のつぶやきで知った Flowdock。1ヶ月程使ってみたが、まさに求めていた(以上の)ツール。

Flowdock Teamwork Revolution

実際に使用している画面は以下のような感じ。
使い方は至ってシンプル。まさにヒットしているコミニュケーションツール(twitter だったり、2ch だったり)の特徴だ。このシンプルさのため、自分たちの目的に合わせて自由に使える柔軟性も合わせ持つ。

左側が influx(直訳すると「流入」) と呼ばれているもので、チーム内に必要な情報を流しこむところ。
上記画面では、twitter のリアルタイム検索の結果、チェックしておきたい twitter アカウントの情報、Wiki ツールである Confluence の更新履歴などがリアルタイムに流れ込んできている。

この流れこんできている1つ1つの情報にはコメントを入れることもできる。
例えば wiki で書かれた更新履歴についてコメントして議論したり、後でチェックしておきたい情報にはコメントを入れておくようなこともできるので、情報が埋もれてしまうことがない。

右側がグループチャットのペイン。
独り言を呟くのもよいが、twitter のように “@” を使って宛先を指定できたり、”#” を使ってタグを付けることもできる。
自分宛のつぶやきには上記のように背景色が黄色になるのでわかり易い。また、設定で変えられるが自分宛のつぶやきが届いた場合には「ポローン」と音で通知してれる。

使い方がシンプルな割に多くの特徴をもつアプリケーションで、なかなかその良さの全ては書ききれない。
先に記述した内容と多少重複すること部分もあるが、公式サイトで書かれている3つの特徴について書いてみる。

Discuss (議論する)
Aggregate (集約する)
Organize (整理する)

具体的にどういうことか？

Discuss (議論する)

リアルタイムグループチャット && ファイルの共有と保管場所として

チーム内のコミニュケーションにメールを使うのは非効率でストレスが溜まる。
開発者間であれば、IRC などを使うのも手なのだが、デザイナーさんであったり、IT を専門としない方などとのやり取りには使い難い。
また、画像などが扱えると会話がスムーズになったりもする。

誰にでも簡単に使えて、画像の扱いも容易なリアルタイムグループチャット、まず1つ目の Flowdock の特徴。

更に、Twitter のように、”@” で宛先を指定でき、指定された方では音声での通知(設定は変えられる)、背景色の変化などで容易に認識できるようになっている。また、”#” でタグ付けが行える。

タグでの絞り込み検索、”@” の宛先による絞り込み検索なども行えるので、チャットアプリケーションにありがちな 過去情報が埋もれてしまう心配もない。

タグ、”@” による宛先指定は取り外し可能なので、自分などはちょっとしたタスク管理にも Flowdock を使っており、タグを活用している。すぐできないタスクには “#todo” タグを振っておき、後で”#todo”タグでタスクを検索、完了したらタグを剥がす、というような使い方。
また、”@” を併用することで、誰のタスクなのか？まで管理できたりもする。

Aggregate (集約する)

他システムとの容易な連携

Redmine や JIRA といった課題管理システム、Confluence などの Wiki システム、github など、プロジェクトには欠かせない他システムとの連携が容易に、かつ、リアルタイムに行える。

リアルなアップデート情報は Flowdock だけを気にしていれば事足りるようになる。

このチームに必要な情報を全て1箇所に集約できるというのが、2つ目の Flowdock の特徴。

Atlassian 製品の代理店でもあるらしく、Atlassian 製品との連携は特によくでている。
それ以外のものでも、基本 RSS フィードをはいているものであれば、Flow に流し込むことができる。

また、Twitter との連携も可能で、リアルタイム検索の結果の流しこみ、Twitter アカウントの follow も可能。

開発チームであれば、リポジトリへのコミットログや、deploy 情報も流し込めるので Flowdock の influx を追っているだけで、ティーム内の活動状況を把握することができる。

Flowdock for Software Developers

Organize (整理する)

タグ付けで会話をナレッジに

グループチャットでは一過性の情報をやり取りすることが大半だが、Flowdock ではそのやり取りがそのままナレッジとしても蓄積される仕組みを用意してくれている。
これが3つ目の Flowdock の特徴。

まず、やり取りされる情報は全て永久に Flowdock に保存される。
Twitter のようなタグ付け、メンションの機能、そして、全文検索も可能なので、過去やり取りした情報を容易に後からピックアップすることができる。
(タグは日本語でも全然問題ないが、全文検索に関しては現状日本語での検索は行えない。)

「ドッグフードを食べる」

ダラダラと書いてしまったが、使ってみてもらえるとすぐにその良さを体感してもらえるのではないかと思う。

Flowdock Teamwork Revolution

ソフトウェア開発の概念で、「ドッグフードを食べる」という言葉がある。

Eating your own dog food - Wikipedia, the free encyclopedia

Eating your own dog food, also called dogfooding, is when a company (usually, a software company) uses the products that it makes.

自社製品を自分たちでも実際に業務で使って評価して開発していることを言うのだが、使ってみて、まさにそうして開発されてきたサービスではないのかなと感じた。

自分たちが必要、便利だと思うものをサービスにして、それをその利用者にも喜んでもらえる、という状況は理想的な状況だ。

フィンランドの会社のようで、メンバの方とちょっとやり取りさせてもらったのだが、とても丁寧で親切。
そして、自分たちのサービスを好きで、誇りを持っており、更によいサービスにしていきたいと思っている意志と情熱がひしひしと伝わってきた。

今後の更なる進化も期待できるサービス。

作業データを複数の VM で共有する - VirtualBox「共有フォルダ」の使い方

2011-07-03T08:01:00Z

複数の VM 環境を扱っているとき、VM 上でカスタマイズする設定ファイル、スクリプトなどの大半は各 VM で共有できることが多い。
VM 環境毎に新たにファイルを作成したり、ファイルを scp 等でコピーしたり、など、まともにやっていると管理含めてメンドイことになる。
ローカルで開発を行っており、複数の VM を使って作業を行う場合、VM 環境からローカル(ホストOS)のファイルを扱えるようにしておいて、各 VM で共有できると何かと便利だ。

VM 環境からローカル(ホストOS)のファイルを「共有フォルダ」として扱えるようにする。

また、このホスト OS の対象ファイルをオンラインストレージサービス Dropbox などで管理していものを利用すると、どのマシンでも同じ作業データを使用して VM 環境を利用できるようになる。

環境と手順の概要

環境は以下の通りとなる。

Oracle VM VirtualBox v4.0.8
ローカル(ホスト)OSは、Ubuntu 10.04 Desktop or Windows XP
VirtualBox が動作すれば特に選ばないはず。
仮想 OS は Turnkey Linux (Ubuntu 10.04) を使用

手順は以下の流れとなる。

VM Manager での作業
1. VM Manager でネットワーク設定に “Host only adapter” を追加しておく
2. 共有フォルダを作成しておく
VM ゲスト OS での作業
1. 必要なパッケージのインストール
2. Guest Additions のインストール
  a. イメージのマウント
  b. Guest Addictions のインストール実行
3. 共有フォルダを利用する

1. VM Manager での作業

まずは、VM Manager での作業。まだ VM のマシンは起動していない。

1.1. VM Manager でネットワーク設定に “Host only adapter” を追加しておく

VM Manager を使用して仮想マシンのネットワーク設定に “Host only adapter” を設定していない場合には設定しておく。

1.2. 共有フォルダを作成しておく

VM から使用するローカル(ゲストOS)のディレクトリを指定し、共有フォルダとして VM Manager に登録しておく。

上記の例では、実体としてのフォルダを”ファルダのパス” (/home/xxx/Dropbox) に指定し、”フォルダ名” に “Dropbox” と指定している。後者の “フォルダ名” というのが、VM 環境のゲスト OS から参照する際のフォルダの名称となる。

ここで、VM のマシンを起動しておく。

2. VM ゲスト OS での作業

VM のゲスト OS での作業になる。

2.1. 必要なパッケージのインストール

bzip2、dkms、build-essential、linux-headers-<kernel-version> が必要となる。

# apt-get install bzip2
# apt-get install dkms
# apt-get install build-essential
# apt-get install linux-headers-`uname -r`

2.2. Guest Additions のインストール

VirtualBox が提供している Guest Addictions のインストールを行う。まずは、このインストールに使用するファイルをゲストOSから見えるようにする。

2.2.a) イメージのマウント

VirtualBox の “デバイス” メニューにある “Guest Addictions のインストール” をクリックする。

クリックした後、画面上何の変化もなく、何が起きたの？的な状況になるが、これで、ゲスト OS から “Guest Addictions” のインストール用ファイルがあるイメージを参照できるようになっている。

ゲスト OS からマウントする。

# mkdir /media/cdrom
# mount /dev/cdrom /media/cdrom
# cd /media/cdrom/
# ls -l
total 37393
dr-xr-xr-x 3 root root     2048 2011-05-17 01:59 32Bit
dr-xr-xr-x 2 root root     2048 2011-05-17 01:59 64Bit
-r-xr-xr-x 1 root root      647 2011-01-19 21:42 AUTORUN.INF
-r-xr-xr-x 1 root root  7853516 2011-05-17 01:53 VBoxLinuxAdditions.run
-r-xr-xr-x 1 root root 14664192 2011-05-17 01:55 VBoxSolarisAdditions.pkg
-r-xr-xr-x 1 root root  9284432 2011-05-17 01:45 VBoxWindowsAdditions-amd64.exe
-r-xr-xr-x 1 root root  6190464 2011-05-17 01:39 VBoxWindowsAdditions-x86.exe
-r-xr-xr-x 1 root root   278832 2011-05-17 01:39 VBoxWindowsAdditions.exe
-r-xr-xr-x 1 root root     6966 2011-05-17 01:51 autorun.sh
-r-xr-xr-x 1 root root     5523 2011-05-17 01:51 runasroot.sh

インストールプログラムである VBoxLinuxAdditions.run が見えている。

2.2.b) Guest Addictions のインストール実行

インストールを実行する。

# ./VBoxLinuxAdditions.run 
Verifying archive integrity... All good.
Uncompressing VirtualBox 4.0.8 Guest Additions for Linux..........
VirtualBox Guest Additions installer
tar: Record size = 8 blocks
Removing existing VirtualBox DKMS kernel modules ...done.
Removing existing VirtualBox non-DKMS kernel modules ...done.
Building the VirtualBox Guest Additions kernel modules ...done.
Doing non-kernel setup of the Guest Additions ...done.
Starting the VirtualBox Guest Additions ...done.
Installing the Window System drivers ...fail!
(Could not find the X.Org or XFree86 Window System.)

“Window System drivers” が fail しているが、サーバ用途で使っていてファイルの共有だけの用途であれば無視して構わない。

2.3. 共有フォルダを利用する

先に VM Manager 側の作業で共有フォルダ “Dropbox” を作成していた。この共有フォルダをゲスト OS でマウントする。

# mkdir Dropbox
# mount -t vboxsf Dropbox ~/Dropbox
# cd Dropbox/
# ls -l

以上でゲスト OS のファイルを VM ゲスト OS から利用可能となる。

参考サイト

LAMP and VirtualBox 4 Shared Folders TurnKey Linux Forum

Refinery CMS - カスタム Engine でのマイグレーションの追加

2011-06-26T14:05:00Z

作成したカスタム Engine でマイグレーションを追加する場合、Refinery CMS のお作法としてどうするのがよいか？如何様にもできそうだが、カスタム Engine のメンテナンス性が保てるやり方がよい。そのメモ。

まず最初に product という簡単なサンプルカスタム Engine を作成する。その後にマイグレーションを追加する方法を記載していく。作業の流れは以下の通り。

Rails 標準の rails generate migration でマイグレーションファイルを作成する
作成されたマイグレーションファイルをカスタム Engine 配下(vendor/engines/my_engine/db/migrate)に配置する
generator を使用して Rails プロジェクト本体に配置し直して、rake db:migrate

0. 新規のカスタム Engine を作成しておく

これから作業するための新規のカスタム Engine を作成しておく。product という簡易な engine になる。

$ rails g refinery_engine product title:string description:text image:image
      create  vendor/engines/products/app/controllers/admin/products_controller.rb
      create  vendor/engines/products/app/controllers/products_controller.rb
      create  vendor/engines/products/app/models/product.rb
...(snip)...
      create  vendor/engines/products/refinerycms-products.gemspec
      create  vendor/engines/products/spec/models/product_spec.rb
------------------------
Now run:
bundle install
rails generate refinerycms_products
rake db:migrate
------------------------

最後のメッセージの指示通り引き続きコマンドを叩き、カスタム Engine を動作可能な状態としておく。

$ bundle install
...(snip)...
$ rails g refinerycms_products
      create  db/migrate/20110615142942_create_products.rb
      create  db/seeds/products.rb
------------------------
Now run:
rake db:migrate
------------------------
$ rake db:migrate
==  CreateProducts: migrating =================================================
-- create_table(:products)
   -> 0.0014s
-- add_index(:products, :id)
   -> 0.0005s
==  CreateProducts: migrated (0.4472s) ========================================

以上で OK。サーバを起動して管理画面を確認してみると確かに product の管理画面が追加されている。

1. Rails 標準の rails generate migration でマイグレーションファイルを作成する

Product のモデルはすでに作成済みであるが、販売促進用のブローシャアをそれぞれの製品につけたくなったとする。製品に添付ファイルをつけられるようにする。

まずは、Rails 標準の rails generate migration を使用して普通に(Rails way で)マイグレーションファイルを作成する。

$ rails g migration AddBrochureToProducts
      invoke  active_record
      create    db/migrate/20110616161904_add_brochure_to_products.rb

マイグレーションファイルに必要な記載を行っておく。

db/migrate/20110615145336_add_brochure_to_product.rb:

class AddBrochureToProducts < ActiveRecord::Migration
  def self.up
    add_column :products, :brochure_id, :integer
  end

  def self.down
    remove_column :products, :brochure
  end
end

マイグレーションファイルへの追加は以上で終了となる。

上記のマイグレーションの記載に関して、products テーブルに brochure_id という外部キーのフィールドを追加し、関連付けまでさせてたのはわかるが、brochure 本体はどこ？となるだろう。

ここでは、Refinery CMS が標準で用意している Resources Engine を利用している。

resource(ファイル)を扱う為の仕組みは既に Refinery CMS には用意されており、Resource モデルも既に存在する。上記はその外部キーを products テーブルに作成しようとしている。

当然上記のスキーマの更新だけでは動作しないので、既に作成済みの Product モデルにも Resouce への関連を追加しておく。

vendor/engines/products/app/models/product.rb:

class Product < ActiveRecord::Base

  acts_as_indexed :fields => [:title, :description]

  validates :title, :presence => true, :uniqueness => true

  belongs_to :image

  belongs_to :brochure, :class_name => 'Resource' # add
end

2. 作成されたマイグレーションファイルをカスタム Engine 配下(vendor/engines/my_engine/db/migrate)に配置する

先ほどの作成されたマイグレーションファイルは Rails プロジェクト本体の db/migrate 配下に作成されている。これを Engine の db/migrate 配下に移動する。

$ mv db/migrate/20110616161904_add_brochure_to_products.rb vendor/engines/products/db/migrate/

3. generator を使用して Rails プロジェクト本体に配置し直し rake db:migrate

Refinery CMS が用意している generator を使用して、Rails プロジェクト本体に配置し直す。

$ rails g refinerycms_products
      create  db/migrate/20110616163831_add_brochure_to_products.rb
You already have a migration called create_products
      create  db/seeds/products.rb
------------------------
Now run:
rake db:migrate
------------------------

products Engine 配下の db/migrate に移動したマイグレーションファイルが、Rails プロジェクト本体の db/migrate 配下にコピーされる。これで migrate する。

$ rake db:migrate
==  AddBrochureToProducts: migrating ==========================================
-- add_column(:products, :brochure, :integer)
   -> 0.0014s
==  AddBrochureToProducts: migrated (0.0015s) =================================

仮に同じ名前のマイグレーションファイルがあった場合には、rails g refinerycms_products を実行しても Rails プロジェクト本体にはファイルはコピーされない。

$ rails g refinerycms_products
You already have a migration called add_brochure_to_products
You already have a migration called create_products
   identical  db/seeds/products.rb
------------------------
Now run:
rake db:migrate
------------------------

以上となる。

スキーマに変更を加える場合には 1 〜 3 の同様の作業を繰り返す。

まどろっこしいことをやっているようだが、この方法により、カスタム Engine ディレクトリ内に全て完結した構成がとれる。
独立性が保たれるので、他プロジェクトへの移植性も高くなる。

(蛇足) 管理画面にブローシャアの登録機能を追加

「カスタム Engine でのマイグレーションの追加」の作業は以上で終了だが、モデルには手を加えたものの、管理画面にブローシャアを登録する為の機能が存在しないので追加する。

既に管理画面用の共通部品として refinerycms-core で resource 用のPicker(/shared/admin/_resource_picker.html.erb)が用意されているので、これを利用する。

管理画面のフォームの view に以下の追加を行っておく。

vendor/engines/products/app/views/admin/products/_form.html.erb:

イメージのフィールドの下あたりで brochure 用のフィールドを追加しておく。

...(snip)
  <div class='field'>
    <%= f.label :image -%>
    <%= render :partial => "/shared/admin/image_picker", :locals => {
          :f => f,
          :field => :image_id,
          :image => @product.image,
          :toggle_image_display => false
        } %>
  </div>
  # add
  <div class='field'>
    <%= f.label :brochure -%>
    <%= render :partial => "/shared/admin/resource_picker", :locals => {
          :f => f,
          :field => :brochure_id,
          :resource => @product.brochure,
        } %>
  </div>

管理画面で確認すると確かにブローシャア用のフィールドが追加されておりちゃんと機能する。

同様にユーザに表示する画面にもブローシャアをダウンロードするための機能を追加しておく必要があるが、ここでは割愛する。

Atlassian の Confluence 3.5 インストールメモ

2011-06-05T14:05:00Z

Wiki のツールを調べており、Atlassian の Confluence を試してみることにした。そのインストールメモ。

エンタープライズコラボレーションおよび Wiki ソフトウェア - Confluence

まずは評価目的で試してみる。以下の構成でインストールする。

ベースとなる OS は仮想環境上にのせる。TurnKey Linux の提供する Virtual Applicace Standalone Tomcat Appliance を使う。
- この環境は、Java 環境、Tomcat サーバ、MySQL 5.1 がすでに利用可能な環境となる
Confluence は Standalone ではなく WAR バージョンを既存の Tomcat 環境にインストールする

インストールの手順は、以下のドキュメントを参考に行う。

Installing the Confluence EAR-WAR Edition - Confluence 3.5 - Atlassian Documentation - Confluence

事前に用意するものと事前準備

用意するもの

まず、Confluence のインストールに必要なものは以下の2点。

Confluence のインストール用ファイル
ライセンス

ライセンスファイルはインストール途中で取得するので、まずはインストールに必要なファイルをダウンロードしておく。

Download Wiki Software - Confluence Enterprise Wiki

上記サイトの右側にある “Show all” をクリックし、全てのダウンロード可能なファイルを表示させ、Confluence 3.5.5 - EAR/WAR (TAR.GZ Archive) をダウンロードする。

事前準備

今回 Virtual Applicace Standalone Tomcat Appliance のアプライアンスをベースとするので、サイトからアプライアンスライブラリをダウンロードし、仮想環境上に作成しておく。

ここでは仮想環境上にアプライアンスをインストールする手順は割愛する。今回使用するアプライアンスライブラリではないが、過去 Redmine の環境を構築した際のメモがあるので参照のこと。
(大枠の手順は変わらない)

手間要らずでプロジェクト管理ツール Redmine を導入する - VirtualBox 編 (その1)

ここから先は既に上記の仮想アプライアンスのインストールは完了しているものとして記述する。

今回の構築時には、追加で以下の2点を実施しておく。
作業内容はそれぞれのページを参照のこと。

ロケールとタイムゾーンの変更
- Ubuntuサーバ日本向け環境の初期設定 - ロケールとタイムゾーン
Java 環境を OpenJDK から Sun Java へ変更 (Confluence は OpenJDK を正式にサポートしていない模様)
- Ubuntu(TurnKey Linux) で Java 環境を OpenJDK ではなく Sun Java をデフォルトに + Tomcat も

で、さらに Java 環境絡みで実施しておく必要がある。仮想OSが使用できるメモリと Java が利用するメモリに関してになる。

デフォルトの設定のままではメモリが足りず、インストールがハングってしまうことになる。

仮想 OS には 1G over のメモリは割り当てておく
Java 環境では、ヒープの Max は 1G、Permanent 領域も 256M くらいは必要

にはしておいた方がよい。

Java 環境の変更に関しては /etc/init.d/tomcat6 で変更を行っておく。JAVA_OPTS に設定を追加。以下のように変更を加えた。

# git diff b4119c5 9f7a1a5 tomcat6
diff --git a/init.d/tomcat6 b/init.d/tomcat6
index 7b31300..575967b 100755
--- a/init.d/tomcat6
+++ b/init.d/tomcat6
@@ -79,7 +79,7 @@ TOMCAT6_SECURITY=no
 # It also looks like the default heap size of 64M is not enough for most cases
 # so the maximum heap size is set to 128M
 if [ -z "$JAVA_OPTS" ]; then
-       JAVA_OPTS="-Djava.awt.headless=true -Xmx128M"
+       JAVA_OPTS="-Djava.awt.headless=true -Xms128M -Xmx1024M -XX:MaxPermSize=256M"
 fi
 
 # End of variables that can be overwritten in $DEFAULT

ちなみに、Standalone 版を確認してみたところ、

JAVA_OPTS="-Xms256m -Xmx512m -XX:MaxPermSize=256m $JAVA_OPTS -Djava.awt.headless=true "
export JAVA_OPTS

となっていた。

Confluence のインストール

Confluence の設定ファイルに Confluence ホームディレクトリの設定

Confluence のインストール時には、以下2つのディレクトリを意識しておく必要がある。

インストールディレクトリ
ホームディレクトリ

先にダウンロードしていた confluence-3.5.5.tar.gz を /opt/atlassian 配下に展開し、インストールディレクトリは、/opt/atlassian/confluence とすることにして、シンボリックリンクをはっておく。

# ln -s /opt/atlassian/confluence-3.5.5 /opt/atlassian/confluence
# cd /opt/atlassian/
# ls -l
total 4
lrwxrwxrwx  1 root root   35 2011-06-05 13:27 confluence -> /opt/atlassian/confluence-3.5.5
drwxr-xr-x 11 root root 4096 2011-06-05 13:19 confluence-3.5.5

ホームディレクトリは、/opt/atlassian/confluence-data としておく。

Tomcat サーバは tomcat6 ユーザで動作するので、ホームディレクトリと念の為インストールディレクトリもパーミッションの変更を行っておく。

# chown -R tomcat6:tomcat6 /opt/atlassian/confluence-data
# chown -R tomcat6:tomcat6 /opt/atlassian/confluence-3.5.5

ホームディレクトリの位置を Confluence の設定に反映しておく。

/opt/atlassian/confluence/confluence/WEB-INF/classes/confluence-init.propertiesの confluence.home の値を上記で決めたディレクトリに指定しておく。

confluence.home=/opt/atlassian/confluence-data

DB の設定

評価目的であれば内蔵の DB を使えばよいのだが、DB 環境含めての評価を行っておきたいので MySQL への接続設定を行う。以下のページが参考になる。

Database Setup For MySQL - Confluence 3.5 - Atlassian Documentation - Confluence

上記に記載のある MySQL の設定ファイル /etc/mysql/my.cnf の設定を追記+変更しておく。以下は変更点。
全て[mysqld] セクション内になる。

# git diff b4119c53 9f7a1a5 my.cnf
diff --git a/mysql/my.cnf b/mysql/my.cnf
index 92b55c2..9e0be08 100644
--- a/mysql/my.cnf
+++ b/mysql/my.cnf
@@ -46,6 +46,16 @@ basedir              = /usr
 datadir                = /var/lib/mysql
 tmpdir         = /tmp
 skip-external-locking
+
+# add
+default-collation=utf8_bin
+character-set-server=utf8
+collation-server=utf8_bin
+default-character-set=utf8
+
+default-storage-engine=INNODB
+
+transaction-isolation=READ-COMMITTED
 #
 # Instead of skip-networking the default is now to listen only on
 # localhost which is more compatible and is not less secure.
@@ -54,7 +64,7 @@ bind-address          = 127.0.0.1
 # * Fine Tuning
 #
 key_buffer             = 16M
-max_allowed_packet     = 16M
+max_allowed_packet     = 32M
 thread_stack           = 192K
 thread_cache_size       = 8
 # This replaces the startup script and checks MyISAM tables if needed

設定変更後、MySQL の再起動をかけておく。

# service mysql restart
mysql start/running, process 8088

Confluence で使用するデータベースの作成、接続ユーザの作成を行っておく。

# mysql -uroot -p
Enter password: 
Welcome to the MySQL monitor.  Commands end with ; or \g.
Your MySQL connection id is 35
Server version: 5.1.41-3ubuntu12.8 (Ubuntu)

Type 'help;' or '\h' for help. Type '\c' to clear the current input statement.

mysql> CREATE DATABASE confluence;
Query OK, 1 row affected (0.00 sec)

mysql> GRANT ALL PRIVILEGES ON confluence.* TO 'confluenceuser'@'localhost' IDENTIFIED BY 'confluencepass';
Query OK, 0 rows affected (0.03 sec)

上記のデータベースのユーザ名(confluenceuser)パスワード(confluencepass)は一例。適切なものに変更して入力を行うこと。

DB は以上。

Tomcat の設定

Tomcat の設定ファイルに先ほど配置した Confluence を Web アプリケーションとして認識させるための設定を追加しておく。

Tomcat の設定ファイルは、通常 Tomcat のインストールディレクトリの conf/Catalina/localhost に配置するが、今回使用している TurnKey Linux での該当ディレクトリは /etc/tomcat6/Catalina/localhost になる。

/etc/tomcat6/Catalina/localhost/confluence.xml ファイルを作成し、以下の記述を行う。

confluence.xml:

<Context path="/confluence"
         docBase="/opt/atlassian/confluence/confluence"
         debug="0"
         reloadable="true" />

docBase には先にインストールディレクトリとして決めたパス配下の confluence ディレクトリを設定している。

Tomcat の再起動を行う。

# service tomcat6 restart
 * Stopping Tomcat servlet engine tomcat6
   ...done.
 * Starting Tomcat servlet engine tomcat6
   ...done.

以上で Tomcat の設定は完了。上記の起動時に妙なエラーが出ていなければまずは OK。

Web 画面からの設定

ここから先はブラウザで http://<server host>/confluence にアクセスし、残りの設定を Web の画面から行う。

まずはライセンスファイルの情報が必要になる。

上記ページの “generate an evaluation license online” をクリックすることで、My Atlassian のログイン画面に遷移するので、ログインを行う。
(アカウントをまだ作成していない場合はアカウントを先に作成する)

ログイン後のページに必要な項目が引き継がれた状態で表示されるので、”ライセンスの生成”をクリックする。

うまいことページが Redidirect される仕組みになっていて、先に表示されていたライセンス入力画面にライセンスキーが入力された状態で戻ってくる。

外部のデータベースを使用するので、”Production Installation” をクリックし、次のページに進む。

今回 MySQL を使うので、”External Database” で “MySQL” を選択し、”External Database” をクリックし次のページに進む。

Web アプリケーションサーバのデータソースは使わずに直接つなぐので、”Direct JDBC” をクリックする。

“Driver Class Name” はそのままとし、Database URL には、表示されている文字列の最後に &useUnicode=true&characterEncoding=utf8 を追加してあげる。全文字列は以下の文字列になる。

jdbc:mysql://localhost/confluence?autoReconnect=true&sessionVariables=storage_engine%3DInnoDB&useUnicode=true&characterEncoding=utf8

もし、データベース名を confluence とは異なる名前にしていた場合には、適宜変更しておく。

また、DB の設定時に作成した confluence データベースに接続を行うユーザ名とそのパスワードを入力して “Next” をクリックする。

この後データベースへのスキーマ作成などいろいろな作業が走るのでしばし時間をおいた後に次の画面に遷移する。

Example サイトがあった方がとっつきやすくなるので、”Example Site” をクリックする。

この後、”Create administrator” 画面へと遷移し、Administrator アカウントを作成した後にセットアップが完了となる。
(画面のスクリーンショットを撮り忘れ。。)

以上でインストール作業は完了となる。

http://<server host>/confluence にアクセスすると Confluence が利用可能となっている。

この状態ではコンテツの日本化はされていない。一部の日本語入力においても問題がある。この後日本語化を行う。次回に続く。

待ちきれない場合は、

Confluenceの日本語化 - インストール手順 - Confluence

を参照のこと。

Ubuntu(TurnKey Linux) で Java 環境を OpenJDK ではなく Sun Java をデフォルトに + Tomcat も

2011-06-05T09:50:00Z

何かと便利な仮想アプライアンスライブラリ。

TurnKey Linux のものをよく使わせてもらっているが、Tomcat のオールインワン環境を提供している Tomcat Applicance では、JDK は OpenJDK を使っている。これを Sun Java 環境に変更し、併せて Tomcat も Sun Java で起動するように変更する。

Standalone Tomcat Appliance - Java Servlet and JSP Platform TurnKey Linux Virtual Appliance Library

このアプライアンスライブラリにはデフォルトで Tomcat 6.0.24 と MySQL 5.1 が含まれており、最低限の必要な設定も既に終えている。

使用している TurnKey Linux のバージョンは以下の通り。

# cat /etc/turnkey_version
turnkey-tomcat-11.1-lucid-x86
# cat /etc/lsb-release 
DISTRIB_ID=Ubuntu
DISTRIB_RELEASE=10.04
DISTRIB_CODENAME=lucid
DISTRIB_DESCRIPTION="Ubuntu 10.04.1 LTS"

OpenJDK から Sun Java へ変更

デフォルトでは以下の Java 環境となっている。

# java -version
java version "1.6.0_20"
OpenJDK Runtime Environment (IcedTea6 1.9.2) (6b20-1.9.2-0ubuntu1~10.04.1)
OpenJDK Client VM (build 19.0-b09, mixed mode, sharing)

Sun Java に切り替える。

まずは Sun Java のインストールから。

必要なレポジトリソースを追加し、アップデートしておく。

# echo "deb http://archive.canonical.com/ lucid partner" >> /etc/apt/sources.list.d/sources.list
# apt-get update

Sun Java のインストール。

# apt-get install sun-java6-jdk

デフォルトで使用される Java を Sun Java に変更しておく。

# update-alternatives --config java
There are 2 choices for the alternative java (providing /usr/bin/java).

  Selection    Path                                      Priority   Status
------------------------------------------------------------
  0            /usr/lib/jvm/java-6-openjdk/jre/bin/java   1061      auto mode
* 1            /usr/lib/jvm/java-6-openjdk/jre/bin/java   1061      manual mode
  2            /usr/lib/jvm/java-6-sun/jre/bin/java       63        manual mode

Press enter to keep the current choice[*], or type selection number: 2
update-alternatives: using /usr/lib/jvm/java-6-sun/jre/bin/java to provide /usr/bin/java (java) in manual mode.

“Press enter to keep the current choice[*], or type selection number:” の問い合わせに Sun Java の 2 を入力している。

確認してみる。

# java -version
java version "1.6.0_24"
Java(TM) SE Runtime Environment (build 1.6.0_24-b07)
Java HotSpot(TM) Client VM (build 19.1-b02, mixed mode, sharing)

とりあえず OK だが、JAVA_HOME の設定も変更しておく。

# echo $JAVA_HOME
/usr/lib/jvm/java-6-openjdk

まだ OpenJDK の方を参照している。この環境変数を設定しているのは、/etc/environment になる。JAVA_HOME の値を /usr/lib/jvm/java-6-sun に変更しておく。変更箇所は以下の通り。

# git diff environment
diff --git a/environment b/environment
index 225ca6c..8c7937c 100644
--- a/environment
+++ b/environment
@@ -4,4 +4,4 @@ LC_ALL=C
 CATALINA_HOME="/usr/share/tomcat6"
 CATALINA_BASE="/var/lib/tomcat6"
 CATALINA_OPTS="-server -Xms384M -Xmx512M -XX:MaxPermSize=256M"
-JAVA_HOME="/usr/lib/jvm/java-6-openjdk"
+JAVA_HOME="/usr/lib/jvm/java-6-sun"

ちなみに、上記でもわかるように、TurnKey Linux では /etc 配下を git で管理している。変更履歴をキチンと管理できるので安心して設定変更が行える。

また、この /etc/environment にてロケールの設定も入っている。ロケールの設定に関して、OS 起動時に /etc/default/locale の設定で上書きされるのでこのままでもいいのだが、どこで悪さするかわからないので、LANG と LC_ALL の設定も変更しておく。

ロケールの変更に関しては、

Ubuntuサーバ日本向け環境の初期設定 - ロケールとタイムゾーン

にも記載している。

最終的に /etc/environment は以下の内容になっている。

# cat /etc/environment
PATH="/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games"
LANG=ja_JP.UTF-8
LC_ALL=ja_JP.UTF-8
CATALINA_HOME="/usr/share/tomcat6"
CATALINA_BASE="/var/lib/tomcat6"
CATALINA_OPTS="-server -Xms384M -Xmx512M -XX:MaxPermSize=256M"
JAVA_HOME="/usr/lib/jvm/java-6-sun"

変更の反映は、一旦システムを再起動しておいた方が安心。

以上で OK。

Tomcat 側の設定

これまでの作業を行っておけば、特に必要はない。

念の為に確認してみる。

# /usr/share/tomcat6/bin/version.sh
Using CATALINA_BASE:   /var/lib/tomcat6
Using CATALINA_HOME:   /usr/share/tomcat6
Using CATALINA_TMPDIR: /var/lib/tomcat6/temp
Using JRE_HOME:        /usr/lib/jvm/java-6-sun
Using CLASSPATH:       /usr/share/tomcat6/bin/bootstrap.jar
Server version: Apache Tomcat/6.0.24
Server built:   December 10 2010 1755
Server number:  ...0
OS Name:        Linux
OS Version:     2.6.32-26-generic
Architecture:   i386
JVM Version:    1.6.0_24-b07
JVM Vendor:     Sun Microsystems Inc.

全て Sun Java に切り替わっている。

Ubuntuサーバ日本向け環境の初期設定 - ロケールとタイムゾーン

2011-06-04T14:40:00Z

Ubuntu だけに限った話ではないが、海外の IaaS サービス(EC2など)や仮想専用サーバ(VPS)を使う際に、ロケールやタイムゾーンを日本向けの環境に変更しておく必要がある場合がある。

ここではその簡単な手順をメモしておく。

環境は、Ubuntu 10.04 LTS Server (厳密には、TurnKey Linux)。

ロケールの変更

まずはロケール。以下の状況となっている。

# locale
LANG=en_GB
LC_CTYPE="C"
LC_NUMERIC="C"
LC_TIME="C"
LC_COLLATE="C"
LC_MONETARY="C"
LC_MESSAGES="C"
LC_PAPER="C"
LC_NAME="C"
LC_ADDRESS="C"
LC_TELEPHONE="C"
LC_MEASUREMENT="C"
LC_IDENTIFICATION="C"
LC_ALL=C
# cat /etc/default/locale
LANG=en_GB

日本語の Language support package をインストールし、ロケールをアップデートする。

# apt-get install language-support-ja
...(インストールログは省略)...
# dpkg-reconfigure locales
Generating locales...
  en_GB.ISO-8859-1... done
  ja_JP.UTF-8... up-to-date
Generation complete.
# update-locale LANG=ja_JP.UTF-8

上記の作業で基本 OK。

# cat /etc/default/locale
LANG=ja_JP.UTF-8

/etc/default/locale も変更されている。ただ、これだけでは、LC_xxx 系の環境変数までは変わらない。

/etc/default/locale に LC_ALL=ja_JP.UTF-8 も追加しておく。

# echo "LC_ALL=ja_JP.UTF-8" >> /etc/default/locale
# cat /etc/default/locale
LANG=ja_JP.UTF-8
LC_ALL=ja_JP.UTF-8

ここで一旦 reboot をかけておく。

# shutdown -r now

確認する。

# locale
LANG=ja_JP.UTF-8
LC_CTYPE="ja_JP.UTF-8"
LC_NUMERIC="ja_JP.UTF-8"
LC_TIME="ja_JP.UTF-8"
LC_COLLATE="ja_JP.UTF-8"
LC_MONETARY="ja_JP.UTF-8"
LC_MESSAGES="ja_JP.UTF-8"
LC_PAPER="ja_JP.UTF-8"
LC_NAME="ja_JP.UTF-8"
LC_ADDRESS="ja_JP.UTF-8"
LC_TELEPHONE="ja_JP.UTF-8"
LC_MEASUREMENT="ja_JP.UTF-8"
LC_IDENTIFICATION="ja_JP.UTF-8"
LC_ALL=ja_JP.UTF-8

OK だ。

タイムゾーンの変更

次にタイムゾーン。以下の状況となっている。

# date
2011年  6月  4日 土曜日 14:20:49 UTC

GUI で変える方法もあるが、以下でやってしまう。

# mv /etc/localtime{,.org}
# ln -s /usr/share/zoneinfo/Asia/Tokyo /etc/localtime

確認する。

# date
2011年  6月  4日 土曜日 23:22:10 JST

OK だ。

Refinery CMS (Rails) でのテスト環境

2011-05-15T10:01:00Z

Refinery CMS というのは、Rails をベースにした CMS。
公式サイトにもテストに関するガイドはあるのだが、テストを開始する前の準備の記載がないのでメモしておく。

How to test Refinery - Guides - Refinery CMS

そもそも、Refinery CMS は CMS なので、Refinery CMS 自体のテストを実施する必要があるの？という話もあるかもしれないが、 Refinery CMS は既存の動作を override できたり、通常の Rails アプリの感覚で拡張できたり、はたまた engine の仕組みを使って必要な機能を拡張していける。

いろいろ手をいれていくと新たに追加した部分だけでなく、既存の環境を壊していないよね？と確認したくなるもの。既存環境のテストをできる状態にはしておきたい。

テスト環境の構築には、Refinery CMS 独自の部分と Rails プロジェクト共通の部分とがあり、先に Refinery CMS 独自のセットアップを行い、更に環境のカイゼンのためのセットアップを幾つか行う。

なお、ここで記載している内容は Refinery CMS は 0.9.9.21 を、Rails は v3.0.7 を使用している。

Refinery CMS テスト環境の準備

まずは、Refinery CMS 独自の部分。

Refinery CMS 自体は gem でインストールされ、実行時には gem のライブラリが使用される。作成されたプロジェクト内にその存在を見ることはないが、必要に応じて自身のプロジェクトに必要なものをとってくることになる。

テストの場合も同様で、必要な gem をインストールしておき、自身のプロジェクトでテストを実行するために必要なファイルをセットアップする必要がある。

まずは、Gemfile で必要な gem を読み込むようにする。 Refinery CMS のプロジェクトを作成した際に Gemfile にはデフォルトで既に以下の内容が記述されている。

Gemfile:

group :development, :test do
  # To use refinerycms-testing, uncomment it (if it's commented out) and run 'bundle install'
  # Then, run 'rails generate refinerycms_testing' which will copy its support files.
  # gem 'refinerycms-testing',    '~> 0.9.9.21'
end

refinerycms_testing gem がコメントアウトされているので、有効にしておく。

Gemfile:

group :development, :test do
  gem 'refinerycms-testing',    '~> 0.9.9.21'
end

bundler を実行しておく。

$ bundle install

Gemfile にも書かれていたように、Refinery CMS でテストを実施するために必要なファイルを refinerycms-testing が用意している generator を使って作成しておく。

$ rails g refinerycms_testing
      create  config/cucumber.yml
      create  spec/spec_helper.rb
      create  spec/rcov.opts
      create  .rspec
      create  features/support/paths.rb

rspec を実行する。

$ rake spec
(in /home/taka/Work/refinerycms-test-sample)
...(略)...
No DRb server is running. Running in local process instead ...
...........................................................................................................

Finished in 6.82 seconds
107 examples, 0 failures

107 example が実行され、0 failure という結果。テストも実行でき、結果もオールグリーンなので Refinery CMS 本体のテストはこれで OK。

更にカイゼンする - spork、watchr

ここからは、Refinery CMS 独自というわけでもなく、通常の Rails アプリにも当てはまる部分。

spork を利用してテスト環境の下準備時間を短縮

先ほどのテスト結果を見ると、”Finished in 6.82 seconds” と出ており、107件の example の全てのテストの実行に約7秒かかったことになっているが、実際はもっと時間がかかっている。

確認してみる。

$ time rake spec
(in /home/taka/Work/refinerycms-test-sample)
...(略)...
No DRb server is running. Running in local process instead ...
...........................................................................................................

Finished in 6.88 seconds
107 examples, 0 failures

real    0m32.983s
user    0m25.254s
sys     0m1.788s

30秒ちょっと。短くできるものは短くしておく。

実行時のメッセージで DRb server を探しているが、spork server を上げておけば、rspec の下準備にかかる時間を短縮できる。

timcharper/spork - GitHub

refinerycms-testing の generator を使って作成した spec_helper.rb には spork の利用を想定した以下の記載が既に存在する。

spec/spec_helper.rb:

# If spork is available in the Gemfile it'll be used but we don't force it.
unless (begin; require 'spork'; rescue LoadError; nil end).nil?

  Spork.prefork do
    # Loading more in this block will cause your tests to run faster. However,
    # if you change any configuration or code from libraries loaded here, you'll
    # need to restart spork for it take effect.
    setup_environment
  end
  ...

spork を利用するには Gemfile に spork の読み込みを追加してあげる。

group :development, :test do
  gem 'spork'
end

再度 bundle install で bundler を実行しておき、spork を起動しておく。

$ spork
Using RSpec
Loading Spork.prefork block...
Spork is ready and listening on 8989!

再度テストを実行する。

$ time rake spec
(in /home/taka/Work/refinerycms-test-sample)
...(略)...
...........................................................................................................

Finished in 6.86 seconds
107 examples, 0 failures

real    0m22.155s
user    0m9.497s
sys     0m0.764s

テスト自体にかかっている時間は先ほどと変わりないが、テストを起動してから終了するまでの実際に掛かっている時間が10秒ほど短縮された。

それでも22秒かかってはいるが、全てのテストを継続的に都度実施しながらコーディングというのはあまりやらないだろう。着手している機能部分に関連するテストを継続的に行う方がストレスも少なく効率的だ。それを行うためにもう一手加える。

watchr を使った継続的なテスト

全てのテストを都度実施するのではなく、編集を行ったソースに対して関連するテストを都度、しかも自動的に実施できるとうれしい。

ファイルを監視していて、何か変更があった時にやりたいことを実施させることができる watchr という便利な gem がある。

mynyml/watchr - GitHub

使い方は、上記の sample や、watchr - ファイルに変更があったら何かする / もしくはオサーンについて - 川o・-・）＜2nd life などが参考になる。ここでは詳細は割愛する。

書き方はいろいろあるだろうが、プロジェクトルート直下に rails.watchr というファイルを用意し、今回は以下のような記述を行った。

rails.watchr:

watch('^spec/(.*)_spec\.rb') { |m| run_test_matching(m[1]) } # (1)
watch('^app/(.*)\.rb') { |m| run_test_matching(m[1]) }       # (2)
watch('^spec/spec_helper\.rb') { run_all_tests }             # (3)
Dir['vendor/engines/*'].each do |d|                          # (4)
  watch("^#{d}/spec/(.*)_spec\.rb") { |m| run_test_matching(m[1]) }
  watch("^#{d}/app/(.*)\.rb") { |m| run_test_matching(m[1]) }
end

def all_specs
  Dir['spec/**/*_spec.rb'] + Dir['vendor/engines/**/spec/**/*_spec.rb']
end

def run_all_tests
  @all_tests_passing = run(all_specs.join(' '))
  puts 'All tests pass' if @all_tests_passing
end

def run_test_matching(thing_to_match)
  matches = all_specs.grep(/#{thing_to_match}/i)
  if matches.any?
    @all_tests_passing &= run(matches.join(' '))
    run_all_tests unless @all_tests_passing
  end
end

def run(files_to_run)
  system("clear; rspec --drb #{files_to_run}")               # (5)
end

若干補足する。

(1) では、spec ディレクトリ配下のテストを記述する spec ファイルに変更があった場合には、その spec を実行する。

(2) では、app ディレクトリ配下の全てのファイルを監視し、変更があった場合には、そのファイルに対応する spec を実行する。

(3) では、spec ファイル全てから参照されている helper である spec_helper.rb が変更された場合には全ての spec を実行し直す。

(4) では、追加した全ての engine の spec、及び、app 配下のディレクトリを監視しておき、変更があった場合には該当する spec を実行する。各 engine に対して (1) と (2) でやっているのと同じことを実行していることになる。
ちなみに、watch メソッドへの引数のパターンでうまくパターンを組めれば Dir を使って engine のディレクトリを探索させてやることもないのだが、今回うまくマッチさせられなかったのでこのような書き方になっている。良い書き方を見つけたら変更しておこう。

(5) は rspec の実行部分だが、--drb オプションを使うことで裏で起動している spork を利用するので、待ち時間なく即座にテストが実行される。

用意した rails.watchr を watchr コマンドを使って起動しておく。

$ watchr rails.watchr

これで、spec、もしくは、app 配下に変更を加える度に関連するテストが再実行されるので、よからぬことをやってしまった場合にはすぐに気づくことができる。

後半の watchr の部分は、

The Pragmatic Bookshelf - Continuous Testing

を参考にした。

Rails3 における Rack

2011-02-27T16:06:00Z

Rails3 は完全な Rack アプリケーションになったと、ものの本では目を通していたが、実際に試していなかったので確認してみた。

$ rails new rails_in_rack
$ cd rails_in_rack

Rack 準拠のサーバは、Rack の決まりに従って、RAILS_ROOT/config.ru から読み込む。このファイルの中身を見てみると、

require ::File.expand_path('../config/environment',  __FILE__)
run RailsInRack::Application

RAILS_ROOT/config/environment.rb を読み込んだ後に、RailsInRack::Application を run している。

Rack のエントリポイントと同様になっている。

また、ルーティング先に指定するオブジェクトはただの Rack アプリとなっているとのこと。
(ルーティング処理も Rack のレイヤとなっているようだ。)

であれば、試してみる。

Rack アプリケーションは、call メソッドを実装していればよく、call メソッドは、リクエスト発生時に、環境変数(env)を引数に呼び出されるので、最後にレスポンスとなるインスタンスを結果として返す処理を書くだけとなる。

Proc オブジェクトで書けるので、直接ルーティング先に Rack アプリケーションを指定してみる。

RAILS_ROOT/config/routes.rb:

RailsInRack::Application.routes.draw do
  root :to => proc { |env| [200, {}, ['Hello! from proc app']] }
end

RAILS_ROOT/public/index.html を削除しておいて、サーバを起動して http://localhost:3000/ にアクセスしてみる。

$ rm public/index.html
$ rails s

確かに動作している。

ということは、Sinatra でも動作する。

RAILS_ROOT/Gemfile に以下を追加し、Bunder を実行する。

RAILS_ROOT/Gemfile:

gem 'sinatra'

$ bundle install

Sinatra アプリケーションを用意する。

RAILS_ROOT/lib/home_app.rb:

class HomeApp < Sinatra::Base
  get '/' do
    'Hello! from Sinatra'
  end
end

Rails3 からデフォルトでは RAILS_ROOT/lib 配下はロードパスに加えられなくなっている。 RAILS_ROOT/config/application.rb に以下を追加しておく。

RAILS_ROOT/config/application.rb:

module RailsInRack
  class Application < Rails::Application
  ...
    config.autoload_paths += Dir["#{config.root}/lib/**/"]
  ...
  en
end

ルーティングの呼び先を先ほど用意した Sinatra アプリに変更しておく。

RAILS_ROOT/config/routes.rb:

RailsInRack::Application.routes.draw do
  root :to => HomeApp
end

再度 http://localhost:3000/ にアクセスしてみる。

確かに Sinatra アプリも動作した。

完全な Rack アプリケーションになったということは、Rack Middleware の資産もそのまま使える。

目的に応じて、組み込む場所が選べる。

RAILS_ROOT/config.fu
Rails 本体よりも先にロードし、適用
Application.config(RAILS_ROOT/config/application.rb)
Rails の通常のリクエスト処理に対して適用
コントローラ
各コントローラで、filter 同様に適用

大きく進化した Rails3 だが、完全な Rack アプリケーションになったのはうれしい。