Design Recipe 別館 Blog - Home

node.js のインストール - Ubuntu 10.04 編

2012-03-24T09:45:00Z

Ubuntu 10.04 への node.js のインストールメモ。

apt repository を新規に追加してインストール。

$ sudo add-apt-repository ppa:chris-lea/node.js
$ sudo apt-get -y update
$ sudo apt-get -y install nodejs

これだけ。。

irb でのオブジェクトの表示を更に見易く - awesome print

2012-03-20T14:50:00Z

環境を整理していていたついでにメモを残しておく。

irb でシンタックスハイライトなどを行うには Wirble など便利な gem があるが、awesome_print はオブジェクトのデータ構造もわかりやすくインデントして表示してくれる。

michaeldv/awesome_print · GitHub

Awesome Print is a Ruby library that pretty prints Ruby objects in full color exposing their internal structure with proper indentation. Rails ActiveRecord objects and usage within Rails templates are supported via included mixins.

インストールと irb でのお試し

インストール。

$ gem install awesome_print
Fetching: awesome_print-1.0.2.gem (100%)
Successfully installed awesome_print-1.0.2
1 gem installed
Installing ri documentation for awesome_print-1.0.2...
Installing RDoc documentation for awesome_print-1.0.2...

irb で試してみる。

$ irb
1.9.3-p125 :001 > require 'awesome_print'
 => true 
1.9.3-p125 :002 > data = [ false, 42, %w(forty two), { :now => Time.now, :class => Time.now.class, :distance => 42e42 } ]
 => [false, 42, ["forty", "two"], {:now=>2012-03-20 14:11:20 +0900, :class=>Time, :distance=>4.2e+43}] 
1.9.3-p125 :003 > ap data
[
    [0] false,
    [1] 42,
    [2] [
        [0] "forty",
        [1] "two"
    ],
    [3] {
             :now => 2012-03-20 14:11:20 +0900,
           :class => Time < Object,
        :distance => 4.2e+43
    }
]
 => [false, 42, ["forty", "two"], {:now=>2012-03-20 14:11:20 +0900, :class=>Time, :distance=>4.2e+43}]

awesome_print を require 後に、ap メソッドに awesome_print で表示させてたいオブジェクトを預ける。

実際のコンソールの画面も貼りつけておく。

irb での出力を常に awesome_print で

先ほどの確認では、awesome_print を使って表示するためには ap にオブジェクトを預ける必要があったが、ap の入力なしに常に awesome_print で表示が行えるようにする。

$HOME/.irbrc に以下を追記。
($HOME はユーザアカウントの HOME 直下。)

$HOME/.irbrc:

# load libraries
require 'rubygems'
require "awesome_print"

unless IRB.version.include?('DietRB')
  IRB::Irb.class_eval do
    def output_value
      ap @context.last_value
    end
  end
else # MacRuby
  IRB.formatter = Class.new(IRB::Formatter) do
    def inspect_object(object)
      object.ai
    end
  end.new
end

試してみる。

$ irb
1.9.3-p125 :001 > data = [ false, 42, %w(forty two), { :now => Time.now, :class => Time.now.class, :distance => 42e42 } ]
[
    [0] false,
    [1] 42,
    [2] [
        [0] "forty",
        [1] "two"
    ],
    [3] {
             :now => 2012-03-20 14:17:37 +0900,
           :class => Time < Object,
        :distance => 4.2e+43
    }
]

実際のコンソールの画面。

rails console でも `awesome_print`

Rails の console でも awesome_print を使いたくなる。

Rails アプリケーションの Gemfile に awesome_print を追加してロードできるようにしておく。開発環境とテスト環境のみで利用可能に。

$RAILS_HOME/Gemfile:

group :development, :test do
  gem 'awesome_print', '~> 1.0.2'
end

Bundler でインストールしておく。

$ bundle install

以下は Refinery CMS で使用した例。

モデルオブジェクトを見てみる。

$ rails c
Loading development environment (Rails 3.2.2)
1.9.3p125 :001 > Refinery::Page
class Refinery::Page < Refinery::Core::BaseModel {
                     :id => :integer,
              :parent_id => :integer,
                   :path => :string,
                   :slug => :string,
           :show_in_menu => :boolean,
               :link_url => :string,
             :menu_match => :string,
              :deletable => :boolean,
                  :draft => :boolean,
    :skip_to_first_child => :boolean,
                    :lft => :integer,
                    :rgt => :integer,
                  :depth => :integer,
          :view_template => :string,
        :layout_template => :string,
             :created_at => :datetime,
             :updated_at => :datetime
}

実際のコンソールの画面。

検索結果は以下のような感じ。

1.9.3p125 :002 > Refinery::Page.find(:first)
  Refinery::Page Load (0.5ms)  SELECT "refinery_pages".* FROM "refinery_pages" LIMIT 1
  Refinery::Page::Translation Load (0.3ms)  SELECT "refinery_page_translations".* FROM "refinery_page_translations" WHERE "refinery_page_translations"."refinery_page_id" = 1
#<Refinery::Page:0xa3f780c> {
                     :id => 1,
              :parent_id => nil,
                   :path => "Home",
                   :slug => "home",
           :show_in_menu => true,
               :link_url => "/",
             :menu_match => "^/$",
              :deletable => false,
                  :draft => false,
    :skip_to_first_child => false,
                    :lft => 1,
                    :rgt => 4,
                  :depth => 0,
          :view_template => nil,
        :layout_template => nil,
             :created_at => Sun, 18 Mar 2012 04:20:54 UTC +00:00,
             :updated_at => Sun, 18 Mar 2012 12:27:27 UTC +00:00
}

実際のコンソールの画面。

Refinery CMS v2 変更点

2012-03-18T14:30:00Z

2月後半に Refinery CMS のメジャーバージョンアップがされている。

Refinery CMS 2.0.0 released - Refinery CMS (2012/02/29)

Refinery 2.0 makes a number of very important updates to the project. Chief amongst these, Refinery now supports Rails 3.2 and the asset pipeline, and is now mountable as a Rails engine.

Rails 3.2 への対応が行われており、Ruby は 1.9.3 が推奨となっている。

Refinery CMS 自体の仕組みでは、軽く触ってみたところ、名前空間の扱い、設定情報の扱いが大きく変わっていた。 Changelog - resolve/refinerycms Wiki - GitHub から変更点をまとめておく。

ワークフローの変更
- extension のインストールには、rake db:seed の実行が必要
- 設定情報 (Settings) は、config/initializers/refinery ディレクトリでカスマイズする(admin 機能でない)
- Settings extension は Refiney Core には含まれなくなった
Extensions の変更
- extension の生成書式の変更
- Settings (設定情報) は RefinerySetting で扱われなくなった
- 公式(デフォルトで組み込まれている)の extension のネームスペースの変更

ワークフローの変更

extension のインストールには、`rake db:seed` の実行が必要

extension のインストールには、rake db:seed の実行が必要となっている。 extension を作成する際の適切なワークフロー以下の通りとなる。

# Add extension to your Gemfile
rails g refinery:<your_extension>
rake db:migrate
rake db:seed

設定情報 (Settings) は、`config/initializers/refinery` ディレクトリでカスマイズする(admin 機能でない)

Refinery アプリケーションの全ての設定は、config/initializers/refinery 内で行われる。 extension を作成した際には、上記ディレクトリ内にテンプレートから作成された設定がコピーされる。

Settings extension は Refiney Core には含まれなくなった

これまで Settings extension は Refinery Core に含まれてきていたが、Core から外れた。別途 extension として導入は可能。

parndt/refinerycms-settings GitHub

Extensions の変更

extension の生成書式の変更

v2.0 からは以下の書式で生成。

rails generate refinery:engine <model_name> field:type field:type field:type

より詳細なオプションは、

rails generate refinery:engine

で確認できる。

Settings (設定情報) は `RefinerySetting` で扱われなくなった

Settings (設定情報)は RefinerySetting からアクセスしていたが、使用されなくなり、代わりに Refinery::<ExtensionNamespace>.value でアクセスする。

例えば、Prtfolio extension では、Refinery::Portfolio.approximate_ascii_for_i18n でアクセスを行う。

I18n などでも、

> Refinery::I18n.default_locale
 => :ja

という感じ。

設定情報は、内部的には 2つの別のファイルの extension 内で扱われている。
1つは、lib/refinery/<extension_name>/configuration.rb の中でデフォルトの値が宣言されており、もう1つは、extension 生成時に generator から読み取られる lib/generators/refinery/<extension_name>/templates/config/initializers/<extension_name>.rb.erb 内にテンプレートが記載されている。

例えば、I18n の場合は、

lib/refinery/i18n/configuration.rb(デフォルト値の設定):

module Refinery
  module I18n
    include ActiveSupport::Configurable

    config_accessor :current_locale, :default_locale, :default_frontend_locale,
                    :enabled, :frontend_locales, :locales

    self.enabled = true
    self.default_locale = :en
    self.default_frontend_locale = self.default_locale
    self.current_locale = self.default_locale
    self.frontend_locales = [self.default_frontend_locale]
    self.locales = self.built_in_locales
  end
end

lib/generators/refinery/templates/config/initializers/refinery/i18n.rb.erb(テンプレートの設定):

# encoding: utf-8

Refinery::I18n.configure do |config|
  # config.enabled = <%= Refinery::I18n.config.enabled.inspect %>

  # config.default_locale = <%= Refinery::I18n.config.default_locale.inspect %>

  # config.current_locale = <%= Refinery::I18n.config.current_locale.inspect %>

  # config.default_frontend_locale = <%= Refinery::I18n.config.default_frontend_locale.inspect %>

  # config.frontend_locales = <%= Refinery::I18n.config.frontend_locales.inspect %>

  # config.locales = <%= Refinery::I18n.config.locales.inspect %>
end

となっている。

Nginx の設定概要

2012-03-11T04:30:00Z

Nginx に関して、とりあえず最初の一歩としてこれだけ知っておけば何とかなる、という内容をまとめておきたくメモを残すことにした。

Basic Nginx Configuration – Linode Library のページがとてもよくまとめられていたので、このページの内容をベースに書かせてもらった。

全体的な構成
グローバルな設定
サーバの設定 - server ディレクティブ
- listen ポートの設定 - listen ディレクティブ
- バーチャルホストの設定 - server_name ディレクティブ
- リソース(ロケーション)の設定 - location ディレクティブ
設定ファイルの管理

全体的な構成

Nginx の設定に関しては、まずは、ディレクティブ、ブロック、コンテキストという言葉をおさえておく。

Nginx はインストール直後ですぐに使える状態になっており、設定は $NGINX_ROOT/conf/nginx.conf に記載されている。($NGINX_ROOTは Nginx がインストールされているルートディレクトリに読み替えること。)

その設定ファイル内のざっくりとした構成は以下のような感じになっている。

#user  nobody;
worker_processes  1;
...
events {
  ...
}

http {
  ...
  server {
    ...
    location / {
      ...
    }
    ...
  }
  ...
}

worker_processes、events、http、server、ocation というのがディレクティブであり、events、http、server、location などは{ } (中括弧)で囲まれたブロックを引数に持っている。このブロックを含めたディレクティブの引数に Nginx で記載可能なシンタックスを使用して条件文などを混じえてディレクティブを記載していく。

Nginx はネストされたブロックの構文を使用でき、上記のように http ディレクティブに server ディレクティブがネストされている構文をとれる。この時、server ディレクティブは http ディレクティブのコンテキストにあると言う。

ディレクティブは、コンテキストによって使えるもの、使えないものとがあるので、ドキュメント Modules で確認する。
ドキュメントの記載は以下のように、ディレクティブ名、シンタックス、デフォルト動作、コンテキストの記載があり、その後にそのディレクティブの詳細説明が続く構成となっている。

 location
 
 syntax: location [=|~|~*|^~|@] /uri/ { ... }
 
 default: no
 
 context: server

インストール時のオプション、パッケージマネージャー等で多少の違いはあるが、インストール直後の $NGINX_ROOT ディレクトリ配下は以下の構成となっている。(include ディレクティブでは起点が nginx.conf の存在するディレクトリになる。後述。)

$ ll
total 42
drwx------  2 nginx root 4096 2012-03-04 15:21 client_body_temp
drwxr-xr-x  4 root  root 4096 2012-03-10 14:46 conf
drwx------  2 nginx root 4096 2012-03-04 15:21 fastcgi_temp
drwxr-xr-x  2 root  root 4096 2012-03-04 15:14 html
drwxr-xr-x  2 nginx root 4096 2012-03-10 17:22 logs
drwx------  5 nginx root 4096 2012-03-05 22:30 proxy_temp
drwxr-xr-x  2 root  root 4096 2012-03-04 15:14 sbin
drwx------  2 nginx root 4096 2012-03-04 15:21 scgi_temp
drwx------  2 nginx root 4096 2012-03-04 15:21 uwsgi_temp

設定内でのパスの指定には、絶対パスと相対パスが使えるが、相対パスを使った場合の起点は、$NGINX_ROOT となる。

デフォルトの設定ファイルは、 $NGINX_ROOT/conf/nginx.conf.default として残されており、このファイルを読みながら、Nginx の設定の概要を掴むことにする。

グローバルな設定

#user  nobody;
worker_processes  1;

#error_log  logs/error.log;
#error_log  logs/error.log  notice;
#error_log  logs/error.log  info;

#pid        logs/nginx.pid;


events {
    worker_connections  1024;
}

上記の記載で nginx.conf.default は始まっている。

# で始まる行はコメントなので解釈されない。
ディレクティブは変数(例: worker_processes, pid)で始まり、その引数(1, logs/nginx.pid)、または、連続した引数(logs/error.log notice)を含む。
全てのディレクティブは ; (セミコロン)で終える。
ディレクティブにはサブディレクティブを含む(ネストする)ことができる。(上記の events のように。)
これらのサブディレクティブは { } を使って、コンテキストとスコープを定義する。
スペースは無視されるので、インデントをうまく使って可読性を上げることができる。
Nginx は、1つのマスタープロセスと実際にリクエストを処理する複数のワーカープロセスで動作する。ワーカープロセスは非特権ユーザで動作するが、user ディレクティブにはそのユーザを指定できる。worker_processes には、動作させるワーカープロセスのプロセス数を指定する。

さらに読み進める。

http {
    include       mime.types;
    default_type  application/octet-stream;

    #log_format  main  '$remote_addr - $remote_user [$time_local] "$request" '
    #                  '$status $body_bytes_sent "$http_referer" '
    #                  '"$http_user_agent" "$http_x_forwarded_for"';

    #access_log  logs/access.log  main;

    sendfile        on;
    #tcp_nopush     on;

    #keepalive_timeout  0;
    keepalive_timeout  65;

    #gzip  on;

http ディレクティブのブロック({ })が書かれている。

include ディレクティブは mime.types ファイルをインクルードしている。相対パスでの記述になっており、この設定ファイルと同じディレクトリに mime.types ファイルが存在する。通常、設定ファイルに記載される相対パスは、$NGINX_ROOT が起点となるが、include ディレクティブの場合は、nginx.conf ファイルの存在するディレクトリが起点となる。(Since version 0.6.7 CoreModule::include)
このように設定ファイルを外出して include ステートメントで読み込むことができるので、設定ファイルの可動性はあがり、管理し易くなっている。
log_format をコメントアウトし、要件に合わせたログフォーマットに変更することができる。
gzip ディレクティブはラストマイル環境がよくない場合など効果を発揮するコンテンツの圧縮をオンザフライで実行する。Apache でいうところの mod_deflate の機能。細かな設定が行えるので、詳細は HttpGzipModule を参照のこと。

access_log ディレクティブの設定サンプルを見てみる。

access_log logs/example.access.log;
access_log /srv/http/example.org/logs/access.log;
access_log /var/log/nginx/access/example.org;
access_log off;

最初の例では、相対パスになっているので、この場合は、ログは$NGINX_ROOT/logs/example.access.logに記録される。
続く2つ目、3つ目の例では、access.log へのフルパスでの指定を行っている。
ログを残したく無い場合、4つ目の例のようにオフにすることも可能。(あまりやらないだろうが・・・)

サーバの設定 - server ディレクティブ

    server {
        listen       80;
        server_name  localhost;

        location / {
            root   html;
            index  index.html index.htm;
        }

        # redirect server error pages to the static page /50x.html
        #
        error_page   500 502 503 504  /50x.html;
        location = /50x.html {
            root   html;
        }
    }

上記の server ディレクティブは、http ディレクティブに内包されている(http ディレクティブのコンテキストにある)。

server ディレクティブのブロックはそれぞれのサーバ自体の設定を行うところとなる。

listen ポートの設定 - `listen` ディレクティブ

まず listen ディレクティブだが、上記は 80 番ポートで待機していることを意味する。更に柔軟な記載が行えるようになっているので、詳細は、HttpCoreModule::listen を参照のこと。

バーチャルホストの設定 - `server_name` ディレクティブ

server_name ディレクティブは、名前ベースのバーチャルホストを実現する。
1つの IP アドレスで待機しているサーバは、リクエストヘッダーの HOST 名に基づいて、複数のドメインのホスティングを行える。

# サンプル1
server_name   example.com;
# サンプル2
server_name   example.com www.example.com;
# サンプル3
server_name   *.example.com;
# サンプル4
server_name   .example.com;
# サンプル5
server_name   example.*;
# サンプル6
server_name   example.com exmaple.net example.org;
# サンプル7
server_name   localhost example1 example2;
# サンプル8
server_name   "";

上記サンプルは、Basic Nginx Configuration – Linode Library の例から使わせてもらっている。

個々の名前は、スペース区切りで記述できる。Nginx はサーバに対して１つ以上の名前を持たせることができ、特定の server_name ディレクティブは1つ以上の名前のリクエストに応答する。また、ワイルドカードの定義や、正規表現での定義も行える。

最初のサンプルは、server_name に example.com を定義している。これにより、http://example.com にはこのサーバが応答する。
2つ目の例の example.com www.example.com の場合、http://example.com と http://www.example.com に応答する。
*.example.com と .example.com の記述の意味は等しい。また、この記述の場合、サブドメインも全てハンドリングする。例えば、www.example.com、img.example.com、search.example.com など。
5つ目の例の example.* の記述は、example で始まる全てのドメインへのリクエストをハンドルする。例えば、example.com、example.net、example.org など。example.wao.com、example.hello.com も同様。
6つ目の example.com exmaple.net example.org は3つのドメイン全てへのリクエストをハンドルする。
Nginx は無効なドメイン名でもバーチャルホストとして定義できる。7つ目の例の localhost example1 example2 の場合、ホスト名となっているが、Nginx はリクエストの HTTP のヘッダのみを見てリクエストを処理するので、有効なドメイン名である必要はない。ただし、この場合は、hosts ファイルにホスト名が定義されている必要がある。
最後の "" の定義では、Nginx は全てのリクエストを処理することを意味する。

リソース(ロケーション)の設定 - `location` ディレクティブ

次に location ディレクティブ。location ディレクティブは、クライアントによってリクエストされたロケーションに対する振舞いを定義する。

location ディレクティブは、そのブロックの前に適用するパターンを記載する。シンタックスは以下の通りとなっており、まずはこの動作概要を掴んでおくことが必要。

location [=|~|~*|^~|@] pattern { ... }

Basic Nginx Configuration – Linode Library の例を利用させていただき、その動作を理解する。

# パターングループ1
location / { }
location /images/ { }
location /blog/ { }
location /planet/ { }
location /planet/blog/ { }

# パターングループ2
location ~ IndexPage\.php$ { }
location ~ ^/BlogPlanet(/|/index\.php)$ { }

# パターングループ3
location ~* \.(pl|cgi|perl|prl)$ { }
location ~* \.(md|mdwn|txt|mkdn)$ { }

# パターングループ4
location ^~ /images/IndexPage/ { }
location ^~ /blog/BlogPlanet/ { }

# パターングループ5
location = / { }

最初の5つのサンプルはリテラル文字列マッチと言われるもの。ホスト名に続くリクエストの最初のパートにマッチする。
server_name に example.com が設定されており、http://example.com/ へのリクエストがあったとする。この時、”location /” ディレクティブはこのリクエストにマッチする。Nginx は “most specific match” でリクエストの条件を満たす。http://example.com/planet/blog/ と http://example.com/planet/blog/about へのリクエストは、”location /planet/blog/” で満たされる。当然、”location /planet/” でも満たされることになる。
2つ目のグループの ~ (チルダ)に続くサンプルでは、Nginx は正規表現での適用を行う。これらの ~ だけのマッチ表現は case-sensive (大文字小文字を区別する) になる。最初の例では、IndexPage.php はマッチするが、indexpage.php はマッチしない。また、/BlogPlanet、/blogplanet/、/blogplanet/index.php もマッチしない。Nginx は Perl Compatible Regular Expressions (PCRE) を使用している。
3つ目のグループの ~* の表現は、~ の場合と同じく正規表現でのマッチで、case-insentive (大文字小文字を区別しない)になる。ここでの表現では、特定の拡張子で終わるファイル名に対してどう処理するのかを定義している。最初の例では、.pl、.PL、.cgi、.CGI、.perl、.Perl、.prl、.PrL、何れの拡張子のファイルにも適用される。
4つ目のグループの ^~ の表現は、最初のグループのリテラル文字列マッチのように動作する。注意点として、このマッチ文が適用されると Nginx はパターンの検索を中止する。”^~ /images/IndexPage/“、”^~ /blog/BlogPlanet/” パターンでの location ディレクティブは、仮に他にマッチする location ディレクティブが他にあったとしても、このパターンがマッチした時点で使用される。
最後の = の表現は、リクエストされたパスに完全一致した場合に適用され、マッチした時点で他のパターンの検索を中止する。例えば、最後のサンプルは、http://example.com/ にはマッチするが、http://example.com/index.html にはマッチしない。

ここまでの記述だけでは、location ディレクティブの全体の適用順がイマイチ掴みきれない。location ディレクティブのパターン適用ルールは以下の通りとなる。

完全一致(=)が最初に処理される。マッチするものが見つかった場合、Nginx はそこでパターンの検索を中止し、リクエストを実行する。
次に残りのリテラル文字列ディレクティブが処理される。もし、^~ が使用されていれば、Nginx はそこでパターンの検索を中止し、リクエストを実行する。それ以外の場合は、Nginx は location ディレクティブを処理し続ける。
正規表現で定義された(~、~*)全ての location ディレクティブが処理される。正規表現がマッチしたら、Nginx はそこでパターンの検索を中止し、リクエストを実行する。
正規表現がない、または、正規表現がマッチしなかったときは、最も適切なリテラル文字列のパターンが使用される。

一旦 Nginx が特定のリクエストに対してリソースを提供する “location” を選択したら、このリクエストに対するレスポンスは、”location” ディレクティブのブロックによって定義される。

location / {
    root   html;
    index  index.html index.htm;
}

ドキュメントルートは、root ディレクティブによって、html ディレクトリに定義されている。上記は相対パスでの指定なので、実際のディレクトリは、$NGINX_ROOT/html となる。/blog/includes/style.css へのリクエストは、他の location ディレクティブがマッチしていないと想定した場合、$NGINX_ROOT/html/blog/includes/style.css にあるファイルがリソースの対象となる。root ディレクティブには絶対パスを指定することもできる。

index ディレクティブはリクエストがファイル名を含んでいない場合に、ファイルシステムのどのファイルが使用されるべきかを指定する。http://example.com/ へのリクエストは、$NGINX_ROOT/http/index.html のファイルがリソースの対象となる。複数のファイル名指定されている場合、Nginx は順にそのリストを処理し、存在するファイルにリクエストを適用する。上記の例の場合、index.html が存在しなければ、index.htm が使用される。仮にどちらも存在しない場合には、404 メッセーが送出される。

設定ファイルの管理

include ディレクティブを活用し、ベースとなる $NGINX_ROOT/conf/nginx.conf には必要最低限の記述のみを行い、各サーバ毎の固有の設定は別ファイルに切り出しておくとメンテナンス性があがる。

例えば、以下のような書き方。$NGINX_ROOT/conf/nginx.conf の内容は至ってシンプルになる。

user nginx;
worker_processes 4;
pid /var/run/nginx.pid;

events {
        worker_connections 768;
        # multi_accept on;
}

http {

        ##
        # Basic Settings
        ##

        sendfile on;
        tcp_nopush on;
        tcp_nodelay on;
        keepalive_timeout 65;
        types_hash_max_size 2048;

        include /etc/nginx/mime.types;
        default_type application/octet-stream;

        ##
        # Logging Settings
        ##

        access_log /var/log/nginx/access.log;
        error_log /var/log/nginx/error.log;

        ##
        # Gzip Settings
        ##

        gzip on;
        gzip_disable "msie6";

        ##
        # Virtual Host Configs
        ##

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

最後の include ディレクティブによって、個々のバーチャルホスト毎の設定は別ファイルに定義を行っている。

参考情報

マスターの導きを受けつつ、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 


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

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

を参照のこと。

Design Recipe 別館 Blog - Home

node.js のインストール - Ubuntu 10.04 編

irb でのオブジェクトの表示を更に見易く - awesome print

インストールと irb でのお試し

irb での出力を常に awesome_print で

rails console でも awesome_print

Refinery CMS v2 変更点

ワークフローの変更

extension のインストールには、rake db:seed の実行が必要

設定情報 (Settings) は、config/initializers/refinery ディレクトリでカスマイズする(admin 機能でない)

Settings extension は Refiney Core には含まれなくなった

Extensions の変更

extension の生成書式の変更

Settings (設定情報) は RefinerySetting で扱われなくなった

Nginx の設定概要

全体的な構成

グローバルな設定

サーバの設定 - server ディレクティブ

listen ポートの設定 - listen ディレクティブ

バーチャルホストの設定 - server_name ディレクティブ

リソース(ロケーション)の設定 - location ディレクティブ

設定ファイルの管理

参考情報

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

Koans とは

watchr を使って回答に集中

triangle.rb

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

Unicorn とは？

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

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

Unicorn サーバを起動する

nginx と Unicorn を連携する

Unicorn を停止する

Unicorn の設定の再読込

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

Discuss (議論する)

Aggregate (集約する)

Organize (整理する)

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

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

環境と手順の概要

1. VM Manager での作業

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

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

2. VM ゲスト OS での作業

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

2.2. Guest Additions のインストール

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

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

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

参考サイト

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

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

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

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

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

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

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

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

用意するもの

事前準備

Confluence のインストール

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

DB の設定

Tomcat の設定

Web 画面からの設定

rails console でも `awesome_print`

extension のインストールには、`rake db:seed` の実行が必要

設定情報 (Settings) は、`config/initializers/refinery` ディレクトリでカスマイズする(admin 機能でない)

Settings (設定情報) は `RefinerySetting` で扱われなくなった

listen ポートの設定 - `listen` ディレクティブ

バーチャルホストの設定 - `server_name` ディレクティブ

リソース(ロケーション)の設定 - `location` ディレクティブ

`triangle.rb`