2013-03-28

MacBook Air 11 インチを注文した

会社に入ったら MacBook Air を買うんだ〜、と twitter につぶやいて数か月。遂に可愛いい MacBook と別れる決意をした。

前回は Apple Store で購入したので、キーボード交換くらいしかスペック変更できなかったけど、今回はなるべくスペックを高くした。MacBook は後でメモリー増設したり、ストレージが足りなくなってアップアップになったりしたけれども、もうその愚は犯さない。

目的は二つ。ブロガー・ミーティングのために持ち歩く。多少の開発マシンとしても使用する。MacBook は重くて辛かったので、ディスプレイ・サイズが小さくとも軽量でコンパクトな 11 インチ・モデルを選択。その上で、開発もやりたいのでスペックは高めに。本当に開発するなら、Pro なんだろうけど、Pro は重いのよね。

購入スペックは以下の通り (青字は変更部分):

  • ディスプレイ: 11.6 インチ (1366 x 768)
  • ストレージ: 256 GB SSD
  • CPU: 2.0 GHz (Dual Core) Intel Core i7
  • メモリー: 8 GB 1,600 MHz DDR3L SDRAM
  • 高さ: 0.3〜1.7 cm
  • 幅: 30 cm
  • 奥行き: 19.2 cm
  • 重さ: 1.08 kg
  • グラフィックス: Intel HD Graphics 4000
  • カメラ: 720p FaceTime HD カメラ
  • USB 3.0 ポート x2
  • Thunderbolt ポート x1
  • MagSafe 2 電源ポート
  • 802.11n Wi-Fi ネットワーク, IEEE 802.11a/b/g 対応
  • Bluetooth 4.0
  • キーボード: バックライト・キーボード (US)

しめて 134,857 円也。

あとがき

前の MacBook は 159,800 円してたから、安くなったなぁ。しかも、MacBook Air だってのに。初代 MacBook Air の高嶺の花さときたら、もう。泣きたくなっちゃう。今回、唯一ダウングレードしたのはディスプレイ・サイズだけ。それでも画面サイズは 1280 x 800 から 1366 x 768 になってるので徴妙に広がってる。

昨夜、注文。お届け予定日は 2013-03-31 から 2013-04-04。来週がワクワク。

カスタムしないなら、Amazon で買っちゃうのも手かもね。ちょっと安い。

APPLE MacBook Air 1.7GHz Core i5/11.6/4GB/128GB MD224J/A
APPLE MacBook Air 1.7GHz Core i5/11.6/4GB/128GB MD224J/A

ちなみに、Apple 45W MagSafe 2 電源アダプタ for Macbook Air (6,475 円) も注文した。こちらは出荷に 3-4 週間かかるとのこと。最短で 2013-04-18。こっちは気長に待つ。

Redmine で別サーバーにある git リポジトリーを参照する

Redmine はローカル・マシンにあるリポジトリーしか参照できない。なので、Redmine 用のサーバーとリポジトリー用のサーバーを分けて運用している場合、チケットとコミット・ログを紐付けることができない。

これは不便なので、公開リポジトリーに commit したら Redmine サーバーにデータを転送するようにした。

なお、掲題の通り今回は git リポジトリーを扱う。

設定

Redmine を動かしているサーバーを server_redmine と呼ぶ。

Git の公開リポジトリーを置いているサーバーを server_git と呼ぶ。リポジトリーは /var/git/sample.git にあるとする。

ssh ログインの準備

server_git から server_redmine へ ssh ログインできる様に設定をしておく。

server_git で上 ssh 鍵を作り、server_redmine へ公開鍵をコピーする。

server_git ~$ ssk-keygen -t rsa
server_git ~$ ls .ssh/
id_rsa id_rsa.pub
server_git ~$ scp .ssh/id_rsa.pub server_redmine:~/
server_git ~$ ssh server_redmine
server_redmine ~$ mkdir .ssh
server_redmine ~$ chmod 700 .ssh
server_redmine ~$ touch .ssh/authorized_keys
server_redmine ~$ chmod 600 .ssh/authorized_keys
server_redmine ~$ cat id_rsa.pub >> .ssh/authorized_keys
server_redmine ~$ rm id_rsa.pub
server_redmine ~$ exit

以上で設定は終了。ssh ログインできれば成功。

server_git ~$ ssh server_redmine
server_redmine ~$ hostname
server_redmine

git repository のコピー

まずは、server_redmine に server_git の git リポジトリーを clone する。

server_redmine ~$ cd /var/git/
server_redmine /var/git$ git clone --mirror ssh:server_git:/var/git/example.git

--bare--mirror の違いがいま一つ分かっていないけれども、--mirror の方が今回の用途に合っていそう。

なお、この作業には server_redmine から server_git へ ssh ログインできることが前提になっている。もし出来ない場合は、上の server_git から server_redmine へ ssh ログインする設定をもう一度、逆方向にして欲しい。

ここまでで、server_git にある最新の git リポジトリーを server_redmine に持って来れた。けれど、今のままでは server_git のリポジトリーにコミットされた内容が server_redmine 側に反映されない。

hooks/update の利用

たいていのバージョン・コントロールには hook という機能がある。コミット直前に何かするとか、コミット直後に何かするとか、そういう機能。

git にも hook 機能があるので、それを使う。今回使うのは post-update フック。

post-update は、全てのコミットが公開リポジトリーに push された後に実行されるフック。server_git 内の /var/git/example.git/hooks/post-update を編集する。中身は次の通り:

#!/bin/sh
#
# An example hook script to prepare a packed repository for use over
# dumb transports.
#
# To enable this hook, rename this file to "post-update".

# exec git update-server-info
ssh -t -t server_redmine <<EOF
 cd /var/git/example.git
 git fetch --all
 exit
EOF

server_redmine に ssh ログインして、git fetch している。git の公開リポジトリーから redmine 側のリポジトリーに push できれば話は簡単なのだけど、「公開リポジトリー (--bare 付きで作ったリポジトリー)」からは git push できない制約がある。仕方がないので、server_redmine 側に移って git fetch している。

ファイルを作ったら、実行権限を付けるのを忘れずに。

server_git ~$ chmod +x /var/git/example.git/hooks/post-update

あとがき

他サーバーにある git repository を同期する手段には、cron を使って定期的に git fetch (or git pull) する方法もある。この方法の欠点は、git push 後、Redmine にデータが同期するまでにタイムラグが出来ること。また、git repository が更新されていなくても、git fetch が実行されてしまうこと。

hook を使えば、誰かが git push したら、自動的に Redmine 側の git repository に反映される。タイムラグもないし無駄な git fetch も発生しない。ぼくは、こちらの方法を好む。

2013-03-27

Android のバージョンとその分布 —— 自分用まとめ 2013/02

2013-03-06 の Engadget に Android のバージョン分布に関する記事が載っていた。Android はバージョンがごっちゃになって、既にぼくの頭の中で混乱の渦を描いている。この記事を参考に自分用のまとめを書いておく。

Android の歴史

基本、バージョン番号順に並べた。そのため、リリース日が前後している行がある (Froyo 2.3.3/2011-02-09 と Gingerbread 2.3/2010-12-06)。また、Android は 2 系がモバイル用、3 系がタブレット向けに分かれたので、その点も考慮に入れて作表した。モバイル/タブレットの統合はバージョン 4 の Ice Cream Sandwich 以降で行なわれている。

バージョンリリースモバイルリリースタブレット
1.02008-09-23——x
1.12009-02-09——
1.52009-04-30Cupcake
1.62009-09-15Donut
2.02009-10-26EclairHoneycomb
2.0.12009-12-03
2.12010-01-12
2.22010-05-21Froyo
2.2.12010-09-10
2.2.22011-01-22
2.32010-12-06Gingerbread
2.3.12011-01-26
2.3.22010-12-16
2.3.32011-02-09
3.02011-02-22
2.3.42011-04-28
3.12011-05-10
3.22011-07-15
2.3.52011-07-25
2.3.62011-09-02
2.3.72011-09-20
3.2.12011-09-20
3.2.22011-08-30
4.02011-10-18Ice Cream Sandwich
4.0.12011-11-14
4.0.22011-11-29
4.0.32011-12-16
4.0.42012-03-28
4.12012-06-27Jelly Beans
4.1.12012-07-10
4.1.22011-10-09
4.22012-11-13
4.2.12012-11-28
5.02013-XX-XXKey Lime Pie

API 番号とバージョン番号の対応は次の通り:

APIバージョンコードネーム
11.0——
21.1——
31.5Cupcake
41.6Donut
52.0Eclair
62.0.1
72.1
82.2Froyo
92.3 - 2.3.2Gingerbread
102.3.3 - 2.3.7
113.0Honeycomb
123.1
133.2
144.0 - 4.0.2Ice Cream Sandwich
154.0.3 - 4.0.4
164.1Jelly Beans
174.2

バージョン分布

上のデータが頭に入ってなくて、バージョン分布がよく分かっていなかったんだよね。Engadget のデータを転載する。上位 5 つを赤字で書いた。

バージョンコードネームAPI利用率
1.6Donut40.2%
2.1Eclair71.9%
2.2Froyo87.6%
2.3 - 2.3.2Gingerbread90.2%
2.3.3 - 2.3.71044%
3.1Honeycomb120.3%
3.2130.9%
4.0.3 - 4.0.4Ice Cream Sandwich1528.6%
4.1Jelly Bean1614.9%
4.2171.6%

このデータは Google の発表による。

Google が Android 開発者向けのプラットフォームバージョン分布データを更新しました。2013年3月4日までの14日間に Google Play にアクセスした端末を集計した最新データ

Androidのバージョン分布、4.x系が45%に達し Gingerbread (2.3)を追い越す - Engadget Japanese より引用

Google の発表なので、全世界でのデータかな? 日本でのデータではないよね? 一応、バージョン 4 系が 45.1%。Android 2.3.X の Gingerbread が 44.2%。僅差の勝利。第三勢力に Froyo 7.6% がしぶとく残ってる。タブレット専用の Honeycomb は 1.2%。ほとんど普及しなかったのね。

日本だけだと、まだ Gingerbread が多そうな気もする。Nexus 4 もまだ発売されてないしね (ないよね?)。誰か日本限定のデータを出してくれないかしらん。

2013-03-21

Rails の Exception Notification で例外を Gmail 通知させてみた

Ruby on Rails のアプリで例外が発生したらメールでお知らせを受け取りたい。exception_notification という gem を使うと可能になるというので、設定してみた。

exception_notification の設定

Gem install

Gemfile に次の一行を追記して、bundle install を実行する。

gem 'exception_notification', :require => 'exception_notifier'

作者の Sebastian Martinez 氏から、最新版の exception_notification なら「:require => 'exception_notifier'」の記述はいらないよ、とコメントをもらった [Thank you, Sebastian]。

gem 'exception_notification'

メールを送付するための Action Mailer の gem も自動でインストールされるので助かる。

設定

config/environments/development.rb にメール送付の設定を書く。上手く行ったら、config/environments/production.rb にコピー。

  # Exception Notification
  config.middleware.use ExceptionNotifier,
    :email_prefix => "[プロジェクト名] ",
    :sender_address => %{"notifier" <notifier@example.com>},
    :exception_recipients => %w{exceptions@example.com}

エラーが出たら、メールを送りたい。でも、とりあえずメール設定は後回しにしたいので、ターミナルに出力させてみる。次の一行を config/environments/development.rb に追記。

  config.action_mailer.delivery_method = :test
例外のコード

手元に例外を出すコードがなかったので、ちょっと強引に行く。Ruby on Rails Guides のブログ・アプリで新規作成ページに行ったら例外を出す、本当に強引なコード。

app/controllers/posts_controller.rbdef new に次の様に例外発生コードを挿入。

  def new
    raise "exception sample"
...
例外を出す

さて、ブラウザーを起動して「新規作成」ページへ。例外が発生するはず。xterm にはこんな文章が出てくれば OK。

Sent mail to exceptions@example.com (7ms)
Date: Thu, 21 Mar 2013 11:59:53 +0900
From: notifier <notifier@example.com>
To: exceptions@example.com
Message-ID: <514a77a971208_16764fb37dc647a@localhost.mail>
Subject: [Try-RoR] posts#new (RuntimeError) "exception sample"
Mime-Version: 1.0
Content-Type: text/plain;
 charset=UTF-8
Content-Transfer-Encoding: 7bit

A RuntimeError occurred in posts#new:

  exception sample
  app/controllers/posts_controller.rb:31:in `new'

...

Gmail 設定

Action Mailer の設定を config/environments/development.rb もしくは config/environments/production.rb に書く。先に書いた terminal に例外情報を出力するコードはコメント・アウトする。

  # Action Mailer for Gmail
  #  config.action_mailer.delivery_method = :test
  config.action_mailer.delivery_method = :smtp
  config.action_mailer.smtp_settings = {
    :address => 'smtp.gmail.com',
    :port => 587,
    :domain => 'gmail.com',
    :user_name => 'your_account@gmail.com',
    :password => 'your_password',
    :enable_starttls_auto => true
  }

これで例外を発生させて Gmail からメールが届けば成功。

わざと例外を発生させてる人は、そのコードを削除してお終い。

あとがき

Rails2 時代と比べて、SSL 関連の設定が楽になってて幸せだった。Action Mailer の SMTP を Gmail ではなく Yahoo! Mail (yahoo.com の方) を使いたかったけど、上手くいかなかった。同じ様な設定で行けるはずなんだけど...

そうそう、自分のサーバーからメールを送る時は postfix あたりを使うと良いらしい。暇が出来たら試してみたいね。

$ sudo apt-get install postfix
config.action_mailer.delivery_method = :sendmail

ref

rvm でデフォールトの ruby のバージョンを指定する

rvm で ruby の 1.9.3 と 2.0.0 を入れている。現在、デフォールトが 1.9.3 なのだけど、メインに使っているのは 2.0.0。毎朝、rvm で ruby のバージョン切替を行なうのが面倒になったので、デフォールトの ruby version を 2.0.0 に変更した。

現状

$ rvm list

rvm rubies

=> ruby-1.9.3-p392 [ i686 ]
   ruby-2.0.0-p0 [ i686 ]

# Default ruby not set. Try 'rvm alias create default <ruby>'.

# => - current
# =* - current && default
#  * - default


$ rvm use 2.0.0
Using /home/ataka/.rvm/gems/ruby-2.0.0-p0
$ rvm current
ruby-2.0.0-p0

rvm list で利用可能な ruby の一覧を表示。

rvm current で現在利用中の ruby を表示。

デフォールトの変更

デフォールトの変更は --default オプションを付ける。

$ rvm use 2.0.0-p0 --default

あとがき

これで明日以降、面倒や変なトラブルに悩まされなくなるはず。

会社とこのブログの立ち位置について

アクトインディ株式会社に入社した。一つ、このブログと会社との関係について書いておく。

ぼくのブログ (clmemo@aka 及び life@aka) は、安宅個人の主張・意見・表現の場であって、安宅が所属する会社の意見を代表するものではない。

ブログを書き始めてもう 8 年。ブログを書くということは、ぼくに生活に大きな位置をしめる。極端な書き方をすれば、ぼくのブログは、ぼくのブランドであり、ぼくにとってのもう一つの会社のようなもの。

ぼくは、このブログで偏った情報を流さない様にしてきたつもり。そのスタンスはぼくのブログの在り方であり、ぼくの誇りでもある。だから、会社に所属したからと言って、会社に偏った情報を書くつもりはない。会社の意見を代表するつもりもないし、そんな権利は最初から持っていない。

上に、このブログを「会社」の様なものと書いた。ぼくがブログを書く時は、「安宅のブログ」という会社の社員として文章をつづっている、とも言える。アクトインディはそういう意味では別の会社であり、他社の企業秘密を漏らしたり、一つの会社を持ち上げたり、また一つの会社を誹謗中傷することはない。「安宅のブログ」のポリシーとして、ステルス・マーケティングを行なうこともしない。

その上で一筆。自分が所属する会社は、やはりぼくの生活の一部なので、関連する記事はやはり増える。しかし、ぼくがブログを書くスタンスは上記の通り。そして、ぼくのブログの立ち位置もそのスタンスの上に立っている。

2013-03-19

Rails 3 に paperclip で画像をアップロードした

paperclip という Gem を使うと、Ruby on Rails に手軽に画像をアップロードできる仕組みが作れる。README を読むと一発で動きそうだったけど、世の中、上手くいかないもの。ハマったので、最小限のコードだけ書いておく。

なお、paperclip はデフォールトでファイル・ストレージ、Fog Storage、S3 Storage(aws-sdk 経由) に対応しており、追加の gem のインストールで Azure Storege と Dropbox にも対応する。

利用バージョンは以下の通り:

  • Ruby 2.0.0-p0
  • Rails 3.2.11
  • paperclip 3.4.1

準備

convert への Path 指定

paperclip はバックエンドで ImageMagick を使う。config/environments/development.rb に次の行を追記する。

Paperclip.options[:command_path] = "/usr/bin/"

Path が分からない時は which convert を入力。convert を削った Path が入力すべき文字列になる。

paperclip のインストール

Gemfile に次の一行を追記。

gem "paperclip", "~> 3.0"

bundle install する。

$ bundle install

ソースコードの編集

今、簡単なブログ・システムをサンプルにしている (ref. Ruby on Rails Guides: Getting Started with Rails)。各記事に一つだけ画像を表示する様に変更を加えたい。

Model の変更

app/models/post.rb を変更

class Post < ActiveRecord::Base
  attr_accessible :content, :name, :title, :tags_attributes, :image
...
  has_attached_file :image,
                    :styles => { :medium => "300x300", :thumb => "100x100" },
                    :default_url => "/images/:style/missing.png"
...

各 Post に画像を付ける様にした。

DB migration

画像情報を保存するために DB を変更する。

$ rails generate paperclip post image
$ rake db:migrate

post に image を追加。

Controller の変更

は特になし。@post を作る作業があるけれど、それは Ruby on Rails Guide の中でやっちゃってるからね。

View の変更 — 画像の追加

画像の追加用のコードをビューに追加する。Ruby on Rails Guide の例なら、views/posts/_form.html.erb を開く。<%= form_for のコードを次の様に変更。

<%= form_for @post, :html => { :multipart => true } do |f| %>

適当な位置に次のコードを挿入。

<%= f.file_field :image %>

これで、submit ボタンが押されると、選択した画像がアップされる。

View の変更 — 画像の表示

今回は views/posts/show.html.erb をいじった。次の一行を追加。

<%= image_tag @post.image.url(:medium) %>

見ての通り画像サイズは medium と style で指定したサイズになっている。サムネイル・サイズが欲しければ引数を :thumb に、オリジナル・サイズがよければオプション引数を取らなければいい。

追記

今回はコーディングしなかったけど、ファイルをデタッチするには次のコードを書く。

@post.image = nil
@post.save

記事の破棄用コードの中にでも仕込めばいいかな?

あとがき

一度やってしまえば簡単だけど、初めてだとどうしても勘所が分からないや。そういうわけで、最低限、動くコードだけでもメモとして残しておかないとね。

rbenv で複数バージョンの Ruby をインストール

rbenv でも複数のバージョンの Ruby をインストール・切り替えが出来ると聞いたので試してみた。

rbenv と ruby-build のインストール

予め必要とされるライブラリーのインストール。

$ sudo apt-get install build-essential libreadline-dev libssl-dev zlib1g-dev

次に必要とされる rbenv コマンドと ruby-build コマンドをインストールする。rbenv はローカル環境にインストールするけど、ruby-build コマンドはシステムにインストールする。

rbenv のインストール

rbenv は git リポジトリーからインストールする。

$ git clone git://github.com/sstephenson/rbenv.git ~/.rbenv

.bashrc もしくは .zshrc に次のコードを追記:

export PATH="$HOME/.rbenv/bin:$PATH"
eval "$(rbenv init -)"
ruby-build のインストール

ruby-build も git リポジトリーからインストールする。

$ git clone git://github.com/sstephenson/ruby-build.git
$ cd ruby-build
$ sudo ./install.sh

以上で、rbenv と ruby-build のインストールは終了。

Ruby のインストール

rbenv は rvm と違って ruby のインストールをデフォールトで行なわない。

現在最新の Ruby 2.0.0-p0 と 1.9 系最後の 1.9.3-p392 をインストールする。

まず、rbenv でインストール可能な ruby を確認。

$ rbenv install -l
Available versions:
  1.8.6-p383
  1.8.6-p420
  1.8.7-p249
  1.8.7-p302
  1.8.7-p334
  1.8.7-p352
  1.8.7-p357
  1.8.7-p358
  1.8.7-p370
  1.8.7-p371
  1.9.1-p378
  1.9.2-p180
  1.9.2-p290
  1.9.2-p318
  1.9.2-p320
  1.9.3-dev
  1.9.3-p0
  1.9.3-p125
  1.9.3-p194
  1.9.3-p286
  1.9.3-p327
  1.9.3-p362
  1.9.3-p374
  1.9.3-p385
  1.9.3-p392
  1.9.3-preview1
  1.9.3-rc1
  2.0.0-dev
  2.0.0-p0
  2.0.0-preview1
  2.0.0-preview2
  2.0.0-rc1
  2.0.0-rc2
  2.1.0-dev
  jruby-1.5.6
  jruby-1.6.3
  jruby-1.6.4
  jruby-1.6.5
  jruby-1.6.5.1
  jruby-1.6.6
  jruby-1.6.7
  jruby-1.6.7.2
  jruby-1.6.8
  jruby-1.7.0
  jruby-1.7.0-preview1
  jruby-1.7.0-preview2
  jruby-1.7.0-rc1
  jruby-1.7.0-rc2
  jruby-1.7.1
  jruby-1.7.2
  jruby-1.7.3
  maglev-1.0.0
  maglev-1.1.0-dev
  rbx-1.2.4
  rbx-2.0.0-dev
  rbx-2.0.0-rc1
  ree-1.8.6-2009.06
  ree-1.8.7-2009.09
  ree-1.8.7-2009.10
  ree-1.8.7-2010.01
  ree-1.8.7-2010.02
  ree-1.8.7-2011.03
  ree-1.8.7-2011.12
  ree-1.8.7-2012.01
  ree-1.8.7-2012.02

rvm と同じく数が多いのも嬉しい。今のぼくは、素の ruby しかインストールしないので、それほどありがたみはないけれど...

少し嫌なのは、rvm と違ってパッチ番号まで指定しないといけないことかな。rvm なら 1.9.3 と指定すれば Ruby 1.9.3 の最新パッチがインストールされたけど、rbenv は 1.9.3-p392 と指定しないといけない。面倒。

先に書いた通り 2.0.0 と 1.9.3-p392 をインストールする。インストールには rbenv install を使う。

$ rbenv install 2.0.0-p0
Downloading ruby-2.0.0-p0.tar.gz...
-> http://ftp.ruby-lang.org/pub/ruby/2.0/ruby-2.0.0-p0.tar.gz
Installing ruby-2.0.0-p0...
Installed ruby-2.0.0-p0 to /home/masayuki/.rbenv/versions/2.0.0-p0

$ rbenv install 1.9.3-p392
...

Ruby の変更

今、使っている ruby の確認。

$ rbenv version
system (set by /home/ataka/.rbenv/version)
$ ruby --version
ruby 1.9.3p0 (2011-10-30 revision 33570) [i686-linux]

おやおや。昔、システムにインストールした Ruby が動いてる。

今、rbenv でインストールしている ruby のバージョンを確認。

$ rbenv versions
* system (set by /home/ataka/.rbenv/version)
  1.9.3-p392
  2.0.0-p0

rbenv global でバージョンを指定。

$ rbenv global 2.0.0
rbenv: version `2.0.0' not installed
$ rbenv global 2.0.0-p0
$ rbenv rehash
$ rbenv version
2.0.0-p0 (set by /home/ataka/.rbenv/version)
$ ruby --version
ruby 2.0.0p0 (2013-02-24 revision 39474) [i686-linux]

バージョン番号だけじゃ Ruby の変更は出来ないのか。ちゃんとパッチ番号まで含めて変更。rbenv rehash を忘れずに。また railsなど、コマンドが付いてくるタイプのgemをインストールしたとき、rbenv rehashを実行する必要がある とのこと。

特定のディレクトリーでの Ruby 指定

rbenv --local を使うと、そのディレクトリー以下での Ruby のバージョンを指定できる。

$ cd ~/project/first-project/
$ rbenv local 2.0.0-p0

bundler コマンドの --path オプションを併用することで、特定のディレクトリー下の gem も指定することができる。

$ bundle install --path vendor/bundle
$ bundle list

あとがき

rvm は cd などの shell のコマンドを上書きすると聞き、不安になったので rbenv をインストールしてみた。マシンによっては rvm が残ってるものもあるので、移行しなきゃなあ。

rbenv rehash の存在が面倒だけど、それ以外は rvm よりスマートな気がする。

ref

2013-03-16

Google Reader はフィードリーダー界の IE6 だったのかもしれない

2013-03-14 (木)、Google は Google Reader サービスの終了を告知した。サービスの終了日は 2013-07-01。

Google は、Google Reader に熱烈なファンがいることは承知しつつも、Google Reader のユーザー数が低下している ためサービス終了に踏み切ったと説明している。

周りの様子

突然のニュースに Google Reader ユーザーは恐慌をきたした。様々な要望・意見・疑問も噴出している。ユーザー減少がサービス終了の本当の理由か? 有料化で対応できないのか? フィード文化は死んだのか? もう Twitter や Facebook らソーシャル・サービスの時代ではないのか? ソーシャル・サービスの良さを認めつつも、フィード・リーダーの持つ良さを捨てられない... etc.

Google Reader Data Points は Google Reader の客観的なデータを提供している。

  • Google Reader で最も人気のフィードは CNN.com。2,400 万購読者
  • 二番手は Engadget.com。660 万購読者
  • 三番手は The New York Times。170 万購読者
  • Google Official Blog は 2007 年に購読者数 10 万を突破、現在 35 万
  • 同サイトの FeedBurner 統計によれば、Google Reader 及び iGoogle による購読は全体の 87%
  • Google Trends の傾向はスクリーン・ショットの通り:

ぼくが共感した意見は、F's Garage さんのこの文章。

Googleリーダーみたいに市場を食い荒らしまくって、他のRSSリーダーサービスを終焉に追い込んでおいておきながら、風向きが変わったら、さくっと終わってしまうことのほうが大問題。

F's Garage @fshin2000 :全収集型RSSリーダーの終焉とソーシャル化するWeb より引用

Google Reader の歴史

Google Reader のターニング・ポイントは 3 つ。

  1. 2005-10: Google Labs にて Google Reader リリース
  2. 2006-09: clmemo@aka: Google Reader バージョン・アップ
  3. 2011-10: Google+ とのソーシャル機能を廃し Google+ 連携を開始

最初の Google Reader はレンズ型とも呼ばれ、全てのフィードを読むのを前提としたスタイルだった。記事を次から次へと読む時の視認性には優れていたけれども、多読性はやや低く、拾い読み派には優しくない UI だった。

一年後、Google Reader は大きく UI を変える。小さな変更を含みつつも、2013-03-16 に至るまで全体の骨子は変わっていない。ぼくは最初の Google Reader の UI を好むけれど、機能という面では新バージョンの良さを認めずにはいられない。

2011 年は Google Reader の外側ではなく内側に大きな変化があった。Google Operating System の記事を引用する。

Everything started with a feed parser built by Chris Wetherell that turned into a feed reader, helped by Ben Darnell, Laurence Gonsalves, and Mihai Parparita. The product was launched in 2005 as a Google Labs project (後略)

In 2011, Google removed Reader's social features and replaced them with a Google +1 button. It was the beginning of the end for Reader, who lost all the engineers from the original team. Google Reader is in maintenance mode ever since then.

(訳) 全ては Chris Wetherell がフィード・パーサーを作ったことから始まった。それは Ben Darnell、Laurence Gonsalves そして Mihai Parparita の助けを借りてフィード・リーダーに結実した。そのサービスは 2005 年に Google Labs プロジェクトとして開始された。

2011 年、Google は Google Reader からソーシャル機能を削り Google +1 ボタンに置き換えた。それは Google Reader の終わりの始まりだった。Google Reader はオリジナル・チームのエンジニア全てを失った。その時を境に、Google Reader はメンテナンス・モードに入った。

No More Google Reader より引用

2006 年の新 Google Reader リリース以降、Google Reader は着実に競合サービスを追い落としユーザーを増やしていった。ぼくの印象では、ここ三年以上 Google Reader に心動かされる新機能が追加されたことはない。いわゆるメンテナンス・モードに入った、と呼ばれる時期と重なる。

Internet Explorer 6 の罪

ここで少し Internet Exlorer (以下 IE) の歴史を振り返ってみたい。IE のバージョン・アップを簡単にまとめてみた。

  1. 1995-08-24
  2. 1995-11-27
  3. 1996-08-13
  4. 1997-09-30
  5. 1999-03-18
  6. 2001-08-27
  7. 2006-10-18
  8. 2009-03-20
  9. 2011-03-15
  10. 2012-08-15

IE6 から IE7 の間に 5 年以上の間が開いている。他のバージョンと比べるとリリース間隔が異常に長い。この頃の Microsoft になにがあったのか。

2000 年以前、ウェブ・ブラウザー界は Netscape 社の Netscape Navigator と Microsoft 社の Internet Explorer に人気を二分していた。Microsoft は Windows にウェブ・ブラウザーを統合する戦略で Netscape に勝利する。大勢は 2000 年頃に決した。いわゆる第一次ブラウザ戦争。

2001 年にリリースした IE6 以降、Microsoft はウェブ・ブラウザーの新機能追加を止めた。ブラウザー・シェアは 90% を越え、最大の敵だった Netscape Navigator に力はなく、新興の Firefox や Opera は一部のギークに使われているにすぎなかった。もはや、新機能を投入する意味が「Microsoft」にはなくなっていた。

IE6 と IE7 の間に Microsoft に何があったか? 慢心があった。

Ajax の登場

2005 年、事件が起きる。Ajax 技術の発表。Google は Ajax を使って Google Maps をリリース。ウェブ・ブラウザー内で使えるスクロール地図が世界に衝撃を与えた。Firefox らがこの新技術にとびついた。今までウェブ・ブラウザーで出来ないと思っていたこと (もちろん、今では当たり前に出来ること) への道が大きく開けた。

IE6 もこの動きに追いつくべく IE7 を 2006 年 10 月にリリースする。第二次ブラウザ戦争が始まろうとしていた。

そして、多くの人達が気付いた。IE6 の寡占状態が続いた間、ウェブ・ブラウザー業界にほとんど進化がなかったことを。

重なる Google Reader

寡占状態による進化の停態。Google Reader は悪しくも、IE6 と同じ道を辿ったのではないか?

特徴的な機能で名を馳せた Rojo は 2006 年に Six Apart に買収されたあと消えた。Google Reader 以前に代表的なフィードリーダーだった Bloglines は 2010 年に姿を消した。「はてな」のはてな RSS も 2010 年に終了した。他にも多くのフィードリーダーが生まれては消えていった。

Google Reader のシェアはどんどん広がる。競合が減る。新機能が生まれない。それでも Google Reader のシェアが減ることはない。次第と「フィードリーダー」というもの自体に興味が失われていった。Google は慢心した。

Google Reader のオリジナル・チームを Google Reader プロジェクトから外したのも、慢心の一つではないか?

今、Google Reader 復活の嘆願をしている人達がいるという。気持ちは分かる。でも、Google Reader を「本気」で開発しようとしていない Google に Google Reader を延命させて、何か変わるのかしらん。オリジナル・チームが戻って来て、リリース当初のモチベーションで新機能開発を行なうなら面白いかもしれない。でも、今の Google には難しいように思う。

IE6 への引導は Ajax が渡したけれど、Google Reader は Google 自身が引導を渡した。人はその行為を「evil」と呼ぶかもしれない。でも、ぼくは、Google が Google Reader から興味を失っていたこと自体がユーザーに対する「evil」であり、サービスの中止は「evil」な自分を正す行為と受け取めている。ようやく、Google が「Do not evil」を一つ為したと思う。

既に Google Reader 中止を受けて、もしくは中止を予想して、多くのプロジェクトが動いていると聞く。フィード・リーダー使いにとっては厳しい冬が来るけれども、Google Reader が思いつかなかった世界を開くフィード・リーダーが現れるのではないか? 春は悲観する程に遠くはないのではないかと期待する。

2013-03-15

Ruby on Rails 3 のソースコードを入手して実行

過去に作った Ruby on Rails のプログラム (Ruby on Rails Guides をやっただけ) を他の環境で動かそうとしたら、色々忘れててハマった。

準備

  • MySQL はインストール済
  • Ruby 2.0.0 がインストール済
ソースコードの入手

Github から Ruby on Rails のソースコードを入手:

$ git clone git@github.com:ataka/try-ror.git
Gem のローカル・インストール

テスト用なので、システムの Gem を汚したくない。ローカル・ディレクトリー ./vendor/bundle にインストール

mysql2 gem のインストールに失敗したので、予め mysqlclient-dev をインストール。

$ apt-get install mysqlclient-dev

改めて bundle install

$ bundle --path vendor/bundle install

Gem ファイルが入る。

データベース起動

MySQL のデータベースを作る。

rake コマンドはローカルに入れたので、bundle exec コマンドを用いる:

$ bundle exec rake db:create
$ bundle exec rake db:migrate

ウェブサーバーで確認

Rails についてきている簡易ウェブサーバーを実行。

$ bundle exec rails server

上手く動いているかな? http://0.0.0.0:3000 にウェブ・ブラウザーからアクセス。

ちゃんと動いてた。

あとがき

rake db:migrate はよく使うので覚えていたけれど、rake db:create は見事に忘れてた。おかげで Unknown database とエラーが出て困った。db:migrate の説明を何度読み返しても、解決しないし。慣れてない人間のハマり所?

あと、Ruby on Rails の簡易ウェブ・サーバー。Rails 2 の頃は ruby script/server で起動していたのね。ウェブを検索しても、Rails 2 時代の説明が多かった。Rails 3 になると rails server でサーバーが起動する。これもハマったなぁ。

とまあ、大きく 2 つハマった。同じ誤ちを冒さないためにもメモ。

ref.

bundle exec については過去記事も参照されたし。

2013-03-14

Nginx の location にハマった

Nginx の location ディレクティブでハマったので、メモ。

こんな設定を書いた。

server {
  listen 80;
  server_name myserver.com;
  root /var/redmine/public;

  location / {
    passenger_enabled on;
  }

  location /bookmarklet {
    root /var/redmine/www;
    index index.html index.htm;
  }
}

http://myserver.com/ で Redmine を公開。Redmine 用のブックマークレットを書いたので、 http://myserver.com/bookmarklet/ でブックマークレット用ページにアクセスさせようというもの。

ところが、上記 URL にアクセスしても 404 Not Found のエラーが出るばかり。問題はウェブ・ページの置き場所にあった。

  • (誤) /var/redmine/www/index.html
  • (正) /var/redmine/www/bookmarklet/index.html

ファイルを置く場所は root で指定した場所だと思っていたのだけど、その下に location で指定したディレクトリーを作らないといけないのね。ハマッた、ハマッた。これからも同じ失敗をしそうなのでメモ。

それにしても、何でこうなるのか? 直感的じゃないなぁ。

Redmine の「説明」にテンプレート・テキストを挿入する bookmarklet を作った

Redmine を使うに当たって、「説明」部分のテンプレートを用意したい。これをブックマークレットで実現した。

Redmine のパワーユーザーならご存じの通り、Redmine で「新しいチケット」を登録する時、「題名」と併せて重要なのが「説明」。

「バグ」に絞って話を進めると、どのような操作をしたのか? エラー・メッセージは何と出たのか? ということは最低限書いて欲しい。

けれど、新人のテスターやプログラミングをやったことのない人が Redmine にバグ登録するのは敷居が高い。そこで、「説明」部分にテンプレートを置き、入力の補助を行なう。

ブックマークレット

「説明」部分にテンプレートを挿入するブックマークレットを作った。

JavaScript のソースコードはこんな感じ。

document.getElementById("issue_description").value="
h1. バグについて

h2. バグが出た場所

* 

h2. バグを出す操作

#

h1. エラー・メッセージ

<pre>
</pre>"

これをブックマークレットに直したのがこちら。

簡単に説明を加えると、Redmine の「説明」の textarea の ID は issue_description。textarea の中身を書き換えるには InnerHTML ではなく value を使う。

ちなみに Redmine のバージョンは 2.3.0。

他の方法もあるけれど

Redmine のソースコードをいじるのは、バージョン・アップに対してリスクが大きい。特に細めにバージョン・アップを繰り返す場合はやりたくない。

Redmine Plugin では Issue Template というのが良さそうだった。今回、このプラグインが程提するほどの高性能を求めないことと、プラグインは開発が止まる (もしくは最新版に追従しない) リスクがあるので使用を控えた。

あとがき

皆にブックマークレットを登録してもらうのが手間と言えば手間だけど、基本、Redmine 初心者用と割り切っている。

パワーユーザーになれば、定型にこだわることなくテキストを入力する。ほんの数行で理解させるバグ報告の場合もあるし、とても詳しいバグ報告を書かないといけない場合もある。こういった判断は経験を積まないと出来ない。

今回のブックマークレットは、とりあえずバグ報告をする時に「初心者」の敷居を低くすることに主眼を置いている。複数のテンプレートがあるなら、複数のブックマークレットを作ればいいし、ユーザーの力量によってテンプレート挿入を自己判断に任せられることが気に入っている。

2013-03-12

Apache の mod_rewrite —— Redmine のバージョン間 URL の違いを吸収

Redmine のバージョンを大幅に上げた。

ここで一つ困ったことが発生。Redmine のバージョンが上がって、URL が変わった。変わったのはチケットを番号で指定する URL。

  • (旧) http://myserver.com/issues/show/番号
  • (新) http://myserver.com/issues/番号

ご覧の通り赤字で書いた「show」という文字列が抜けた。URL がスッキリして良くなったと思う。

問題は、過去の文書資産 — 過去メールや他のドキュメント — に旧 URL が使われていること。全ての文書の URL を直すのは大変なので、旧 URL でアクセスしたら 新 URL に自動的に移るようにした。これを URL のリダイレクトという。

Apache の rewrite 設定

まず、Apache に rewrite 用のモジュール mod_rewrte が入っているかどうかを確認。

$ sudo apache2ctl -M | grep rewrite
Syntax OK
 rewrite_module (shared)

うん、rewirte 用のモジュールが入っている (入ってない人は、頑張って入れて下さい)。

Apache の設定ファイルを変更 (追記部分を青字で書いた)。

<VirtualHost *:80>
  ServerName myserver.com
  DocumentRoot /var/redmine/public
  RewriteEngine On
  RewriteRule ^/issues/show/(.+)$ /issues/$1 [R]
</VirtualHost>

RewriteRule の末尾にある [R] はリダイレクトするための設定。このコードがないと、新しい Redmine の URL に旧 URL でアクセスできる様になる。見る分には問題ないけれど、URL をコピーする時に旧 URL をわざわざコピーさせるのはスマートじゃない。リダイレクトすると、旧 URL でアクセスすると URL は新 URL に変わる。

Apache を再起動すれば、リダイレクトが効くようになる。

あとがき

Redmine を久々にアップグレードして、その変化の大きさに驚いている。地味ながら、結構不満になったのが、今回の URL 問題。正規表現が使えると知るまでは、どうしようかと悩んだ。

Apache の Reverse Proxy を SSL 経由で試す

Apache のリバース・プロキシを使って、Apache の 443 ポートに来た通信を Nginx の 4443 ポートに飛ばした。

関連エントリー/前提条件

関連するエントリーは以下の通り:

前提条件は下記の通り:

  1. myserver.com に複数の Rails アプリが動いている
  2. myserver.com:/var/redmine に最新の Redmine をインストールした
  3. 今までは https://myserver.com で Redmine を公開
    • Apache を利用
    • 443 ポートを利用
  4. 新 Redmine は https://myserver.com:4443 で公開
    • Nginx を利用
    • 4443 ポートを利用

新 Redmine を Nginx で動かしたのは、他の Rails アプリが使っている Passenger と競合したため。Nginx で 4443 ポートを使ったのは、443 ポートが Apache に使われているため。

Apache のリバース・プロキシを試す

現在、Redmine は https://myserver.com:4443/ で動いている。けれど、ポート番号をいちいち入力するのは手間だし、過去のメールや Wiki にはポート番号なしの URL が記入されており、そこからリンクを辿る時にポート番号を追加するのはとても面倒。

なので、https://myserver.com/ にアクセスしてたら、自動的に https://myserver.com:4443/ に転送する様にしたい。つまり、Apache が 443 ポートで受けたリクエストを Nginx の 4443 ポートに飛ばしたい (また Nginx の 4443 ポートからの返信を Apache が 443 ポートで受け取れる様にしたい)。これを Apache のリバース・プロキシ機能で実現する。

80 番ポートで練習

まずは SSL (443 ポート) を使わない。80 番ポートで練習。

Nginx は 8080 ポートを開く設定にした:

server {
  listen 8080;
  server_name myserver.com;
  root /var/redmine/public;
  ...
}

Nginx を再起動。http://myserver.com:8080/ でサイトを開ける。Apache に Reverse Proxy の設定を追加して http://myserver.com/ でサイトを開くようにする。設定ファイルは以下の通り (Proxy の設定を青字で書いた)。

<VirtualHost *:80>
  ServerName myserver.com
  DocumentRoot /var/redmine/public
  ProxyPass / http://myserver.com:8080/
  ProxyPassReverse / http://myserver.com:8080/
</VirtualHost>

Apache を再起動すれば http://myserver.com/ でサイトが開く。

443 番ポート対応

まず Nginx 側のポート番号を 4443 にする。

server {
  listen 4443;
  server_name myserver.com;
  root root /var/redmine/public;

  ssl on;
  ssl_certificate /my/path/to/ssl-cert.pem;
  ssl_certificate_key /your/path/to/ssl-cert.key;
  ...
}

Nginx を再起動。https://myserver.com:4443/ で開ければ OK。http を https に変えるのを忘れるポカをしないこと (意外とハマる)。

4443 番ポートを指定するのは面倒。https://myserver.com/ で開きたい。まず、Apache で Reverse Proxy の設定を変更する (新変更点を青字で書いた)。

<VirtualHost *:443>
  ServerName myserver.com
  DocumentRoot /var/redmine/public
  ProxyPass / https://myserver.com:4443/
  ProxyPassReverse / https://myserver.com:4443/

  SSLEngine on
  SSLProxyEngine on
  SSLCertificateFile /my/path/to/ssl-certpem
  SSLCertificateKeyFile /my/path/to/ssl-cert.key
</VirtualHost>

SSLProxyEngineon にしていること、http を https に直していること、ポート番号をちゃんと指定すること、を注意。

Apache を再起動すれば、https://myserver.com/https://myserver.com:4443 にアクセスする。ポート番号不要になって幸せ。

参考エントリー

2013-03-11

アマゾン・アソシエイトにはサイト登録が必須!! 〜 2 つ目のサイトを作る時に注意

Amazon アソシエイト (Amazon のアフィリエイト・サービス) を受けるには審査が必要。審査には、自分がアフィリエイト・リンクを張る「ブログ」を Amazon に伝える。審査に通れば、アソシエイト ID が利用可能になる。

さて、長年ブログやウェブページで Amazon アソシエイトを使っていると、新しいサブ・ブログやウェブ・サイトに対しても既存のアソシエイト ID を使ってしまうことがあるかと思う。しかし、Amazon はそのような行為を禁止している。審査済以外のサイトで Amazon アソシエイトを行なう場合は、再度 Amazon からそのサイトの審査・承認を受ける必要がある。この場合、既存のアソシエイト ID に追加する形で申請を行なうといい。

申請ページが見つかりにくい。次の様な手順になる。

  1. Amazon アソシエイト(アフィリエイト) - ホーム にアクセス
  2. ページ右上の「ヘルプ」をクリック
  3. 「複数のWebサイトを管理する」をクリック
  4. 「一つのアカウントに複数のURLを登録できますか?」をクリック
  5. 説明文の中にある「カスタマーサービス」のリンクをクリック
  6. 説明文の中にある「ここをクリック」をクリック
  7. フォームが現れるので、件名を「アカウント情報の変更、登録URLの追加など」にして、他の必要事項を記入の上「Eメールを送信」をクリック

あとがき

初めて Amazon アソシエイトに申し込む時、このことは頭の中に刻みつけていたと思う。ぼくはサブ・ブログに life@aka を持っているけれど、このブログも Amazon アソシエイトに登録してある。

ところが時は記憶を風化させる。Amazon に、「審査済のサイト」を知る機能がないのも痛い。

事実、ぼくは他のサイトに Amazon アソシエイトのリンクを張ってよいと勘違いしていたし、life@aka の審査を申し込んだかも忘れてしまっていた。審査済かどうかを調べる術はないので、仕方なく上記フォームから「○○のサイトの審査をしたかどうか忘れてしまったので、調べて欲しい」と Amazon に申し込んでしまった (ちゃんと審査済だったので一安心だったけど)。

意外と忘れてしまうことなので、ここにブログの記事とした。

なお、本エントリーは下記記事を大いに参考にしている。この記事を読んで、ぼくは「審査」のことを思い出した。本エントリーには書いていない情報・Tips も詳しいので、Amazon アソシエイトを使っている人は続けて読むことをお勧めする。

2013-03-10

楽天カード (クレジット・カード) を手に入れた

楽天カードの審査が通った。と、いきなり書いても唐突すぎると思うので、過去エントリーをまじえて経緯を書く。

まとめ

無職の期間にクレジット・カードを不正使用された。カード会社の厚意で、自動的にカードは凍結。不正使用された金額も払い戻された。そして、クレジット・カード再発行の手続きが進むところ、手続きが止まった。カード再発行手続きには審査が再び行なわれる。その審査の段階で止まっていた。理由は、ぼくが「無職」のため。この時 (おそらく今も)、クレジット・カードの審査は無職ではまず通らない (楽天カードは定職・定収入が原則)。審査落ちの履歴は個人信用情報に残り、他社のクレジット・カードの作成も厳しくなるという。そういうわけで、審査に入る手前でカード会社が手続きを止めていた。

今年の 2/27。ようやく入社。以前の問い合わせ電話にて、「入社したら電話を下さい。試用期間でも構いません」ということを言われていたので、入社 5 日後の 3/3 (日) にカード会社に電話した。今までの経緯を話し、「会社に入れたのでとりあえず電話した」旨を伝える。担当者はそのまま個人情報を聞き、審査へと回してくれたらしい。

質問された内容は次の項目。

  • 旧カードのカード番号
  • 名前・生年月日・住所・電話番号
  • 入社した会社の名前と住所・電話番号
  • おおまかな年収
  • 銀行の残高

年収はすぐに頭に出なかったので、月収を伝えた上で、それを 12 倍して欲しいと頼んだ。頂度、その時荷物が届いたので、電話をそのままに荷物受け取りへ。戻ってみたら、年収計算を向こうが終えていた。2 月入社 (といっても 2 月は 2 日しか出社していないので実質 3 月入社) の場合、年収は 10 か月分。それにボーナスになると思うんだけど、細かい金額ではなくザックリした収入が分かれば良かったんだと思う。

電話をしたのが 3/3 (日)。そして一週間経たない 3/9 (土)。新しい楽天カードが届いた。

あとがき

過去エントリーにも書いたけれども、定職にない状況でクレジット・カードを作るのは大変。ぼくの場合、不幸な出来事で審査が必要になったわけど、これはまあ事故の様なもの。

それはともかく、これから退職する人 (定年退職含む) やリストラの可能性がある人で、クレジット・カードが必要そうと思うなら、会社に居る内にクレジット・カードを作ることをお勧めする。入社して 3 日しか出社していない人間がクレジット・カードの審査に通り、定職にないとはいえ預金残高が高い人間の審査が通らないというのも、アンバランスな感じを受ける。でも、世の中、そういう風に動いているらしい。

ref

2013-03-08

Nginx + Passenger + Redmine 2+

先のエントリーで旧い Redmine を開発版の Redmine に置き換えようとしたのだけど、実は Apache 回りで上手くいっていなかった。何が悪かったかと言うと、新 Redmine はローカルに入れた gems で動き、旧 Redmine はシステムの gems で動いていたこと。

Apache はシステム側の Passenger で動かしていたので、旧 Redmine は動くけど新 Redmine は動かない。何故なら、新 Redmine はシステムの Passenger を使わないから。エイヤッとシステム全体の gems を統一しちゃえば問題ないんだけど、安全策が事態をややこしくした。

というわけで、clmemo@aka: Redmine 2 系へのアップグレード方法 の続きから。

Nginx for Passenger のインストール

Apache で共存させるのは大変なので、Nginx を使うことにした (see also clmemo@aka: Nginx をソースからコンパイルしてインストールしてみた)。これからの作業で Nginx のインストールを行なうので、過去記事の Nginx のインストール部分は飛ばして良し!!

/var/redmine-dev に移動して、nginx 用の module を組む。Apache はモジュールを後から追加できるけど、nginx はコンパイル時に module を組み込む。なので、module 用コマンドがそのまま nginx のコンパイル・コマンドになっている。

$ cd /var/redmine-dev
$ echo 'gem "passenger"' >> Gemfile.local
$ bundle install
$ sudo bundle exec passenger-install-nginx-module
(中略)
Nginx doesn't support loadable modules such as some other web servers do,
so in order to install Nginx with Passenger support, it must be recompiled.

Do you want this installer to download, compile and install Nginx for you?

 1. Yes: download, compile and install Nginx for me. (recommended)
    The easiest way to get started. A stock Nginx 1.2.6 with Passenger
    support, but with no other additional third party modules, will be
    installed for you to a directory of your choice.

 2. No: I want to customize my Nginx installation. (for advanced users)
    Choose this if you want to compile Nginx with more third party modules
    besides Passenger, or if you need to pass additional options to Nginx's
    'configure' script. This installer will  1) ask you for the location of
    the Nginx source code,  2) run the 'configure' script according to your
    instructions, and  3) run 'make install'.

Whichever you choose, if you already have an existing Nginx configuration file,
then it will be preserved.

Enter your choice (1 or 2) or press Ctrl-C to abort:

(1) 自動インストールか、(2) カスタム・インストールか聞かれる。ここはあえてカスタムの 2 を選ぶ。

  • Where is your Nginx source code located?
    Please specify the directory:
    ~/src/nginx-1.3.14/
  • Where do you want to install Nginx to?
    Please specify a prefix directory [/opt/nginx]:
    /etc/nginx
  • Extra Nginx configure options
    (中略)
    Extra arguments to pass to configure script:
    --sbin-path=/usr/sbin/nginx --conf-path=/etc/nginx/nginx.conf --error-log-path=/var/log/nginx/error.log --http-log-path=/var/log/nginx/access.log --pid-path=/var/run/nginx.pid --with-mail --with-mail_ssl_module --with-sha1=/usr/include/openssl --with-md5=/usr/include/openssl

最後に ENTER を押してコンパイル & インストール開始。

設定ファイルへの追記

2 つのファイルを編集。まず、/etc/nginx/nginx.confhttp セクションに次の 2 行を追記:

  passenger_root /var/redmine-dev/vendor/bundle/ruby/1.8/gems/passenger-3.0.19;
  passenger_ruby /usr/bin/ruby1.8;

Ruby や Passenger のバージョンは環境によって違う。詳しくは、passenger-install-nginx-module のヘルプ・テキストを参照のこと。

次に Redmine を動かす site-availables/yourserver.com を編集。

server { ...
  listen 8080
  root /var/redmine-dev/public;
  passenger_enabled on;
  ...
}

これで nginx を再起動 (/etc/init.d/nginx については過去記事参照)。

上手く http://yourserver.com/ で Redmine が見えたかな?

あとがき

Redmine をアップグレードしようとしたら、二日がかりになってしまった。アップグレードは細めに行ないたいもの。ちょっと泣きそうになったよ。

最後に参考にしたサイトを一つ紹介して終わる。このページはまとまってるとは言いがたいけど、エラーに遭遇して対処して、またエラーに遭遇する様が物語の様で (特に同じ道を歩く者には) 笑いを誘う。もちろん、役にも立つよ。

Nginx をソースからコンパイルしてインストールしてみた

Apache の対抗馬としてメキメキ名を上げている nginx。パッケージ・インストールすれば簡単だけど、あえてソースからコンパイルして、インストールしてみた。

インストール

最新 1.3.14 版をダウンロードして configure && make && make install。nginx の難しい所は、モジュールのインストールや設定を configure でやってしまう点。必要なモジュールがあれば再インストールが必要になる。まあ、代わりに nginx 自体はシンプルに保てるわけだけど...

デフォールトの設定ファイルが /etc/nginx/ 以下に入らないとか、独特な仕様なので Ubuntu Linux のパッケージから nginx の configure オプション (nginx -V で見られる) を調べて、適当に削って configure を実行した。

$ wget http://nginx.org/download/nginx-1.3.14.tar.gz
$ tar xzvf nginx-1.3.14.tar.gz
$ cd nginx-1.3.14
$ ./configure --prefix=/etc/nginx \
  --sbin-path=/usr/sbin/nginx \
  --conf-path=/etc/nginx/nginx.conf \
  --error-log-path=/var/log/nginx/error.log \
  --http-client-body-temp-path=/var/lib/nginx/body \
  --http-fastcgi-temp-path=/var/lib/nginx/fastcgi \
  --http-log-path=/var/log/nginx/access.log \
  --http-proxy-temp-path=/var/lib/nginx/proxy \
  --http-scgi-temp-path=/var/lib/nginx/scgi \
  --http-uwsgi-temp-path=/var/lib/nginx/uwsgi \
  --lock-path=/var/lock/nginx.lock \
  --pid-path=/var/run/nginx.pid \
  --with-pcre-jit \
  --with-debug \
  --with-http_addition_module \
  --with-http_dav_module \
  --with-http_geoip_module \
  --with-http_gzip_static_module \
  --with-http_image_filter_module \
  --with-http_realip_module \
  --with-http_stub_status_module \
  --with-http_ssl_module \
  --with-http_sub_module \
  --with-http_xslt_module \
  --with-ipv6 \
  --with-sha1=/usr/include/openssl \
  --with-md5=/usr/include/openssl \
  --with-mail \
  --with-mail_ssl_module
$ make
$ make install

途中、足りないライブラリー (libgd2-xpm-dev や libgeoip-dev など) を apt-get でインストール。

設定

/etc/nginx/nginx.conf を編集。サンプル:

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

events {
    worker_connections  1024;
}

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

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

    sendfile        on;
    #keepalive_timeout  0;                                                      
    keepalive_timeout  65;

    gzip  on;
    gzip_disable "msie6";

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

一応、ログをインストールしたり後で使う設定ファイルのためにディレクトリーを作成。

$ sudo mkdir -p /var/lib/nginx/body
$ sudo mkdir -p /etc/nginx/conf.d/
$ sudo mkdir -p /etc/nginx/sites-enabled
$ sudo mkdir -p /etc/nginx/sites-available

myserver.com で開くようにしてみる。/etc/nginx/sites-available 以下に myserver.com というファイルを作る:

server {
  listen 8080;
  server_name myserver.com;

  location / {
    root /home/you/www/myserver.com/;
    index index.html index.htm;
  }
}

Apache が 80 番ポートを使っているので、8080 番ポートでアクセスする様にしてみた。location の中身は ~/www/myserver.com/ 以下に置いた HTML ファイルが myserver.com からアクセスする設定。

続いて sites-enabled にリンクを張る。

$ cd /etc/nginx/sites-enabled
$ ln -s ../sites-available/myserver.com ./

myserver.com にアクセスできる様 /etc/hosts もいじっておく (テストの時は意外とハマり所)。下記一行を追記。

127.0.0.1 myserver.com

/etc/init.d/nginx の実行

さあ、nginx を実行してみたい。apache と同じ様に /etc/init.d/nginx を start... と思ったらファイルがない。nginx。このファイルから作らなきゃなのか...

大変なので Ubuntu Linux のパッケージ・インストールしたスクリプトをコピー。ファイルは下記の通り:

/etc/init.d/nginx
#!/bin/sh

### BEGIN INIT INFO
# Provides:          nginx
# Required-Start:    $local_fs $remote_fs $network $syslog
# Required-Stop:     $local_fs $remote_fs $network $syslog
# Default-Start:     2 3 4 5
# Default-Stop:      0 1 6
# Short-Description: starts the nginx web server
# Description:       starts nginx using start-stop-daemon
### END INIT INFO

PATH=/usr/local/sbin:/usr/local/bin:/sbin:/bin:/usr/sbin:/usr/bin
DAEMON=/usr/sbin/nginx
NAME=nginx
DESC=nginx

# Include nginx defaults if available
if [ -f /etc/default/nginx ]; then
 . /etc/default/nginx
fi

test -x $DAEMON || exit 0

set -e

. /lib/lsb/init-functions

test_nginx_config() {
 if $DAEMON -t $DAEMON_OPTS >/dev/null 2>&1; then
  return 0
 else
  $DAEMON -t $DAEMON_OPTS
  return $?
 fi
}

case "$1" in
 start)
  echo -n "Starting $DESC: "
  test_nginx_config
  # Check if the ULIMIT is set in /etc/default/nginx
  if [ -n "$ULIMIT" ]; then
   # Set the ulimits
   ulimit $ULIMIT
  fi
  start-stop-daemon --start --quiet --pidfile /var/run/$NAME.pid \
      --exec $DAEMON -- $DAEMON_OPTS || true
  echo "$NAME."
  ;;

 stop)
  echo -n "Stopping $DESC: "
  start-stop-daemon --stop --quiet --pidfile /var/run/$NAME.pid \
      --exec $DAEMON || true
  echo "$NAME."
  ;;

 restart|force-reload)
  echo -n "Restarting $DESC: "
  start-stop-daemon --stop --quiet --pidfile \
      /var/run/$NAME.pid --exec $DAEMON || true
  sleep 1
  test_nginx_config
  # Check if the ULIMIT is set in /etc/default/nginx
  if [ -n "$ULIMIT" ]; then
   # Set the ulimits
   ulimit $ULIMIT
  fi
  start-stop-daemon --start --quiet --pidfile \
      /var/run/$NAME.pid --exec $DAEMON -- $DAEMON_OPTS || true
  echo "$NAME."
  ;;

 reload)
  echo -n "Reloading $DESC configuration: "
  test_nginx_config
  start-stop-daemon --stop --signal HUP --quiet --pidfile /var/run/$NAME.pid \
      --exec $DAEMON || true
  echo "$NAME."
  ;;

 configtest|testconfig)
  echo -n "Testing $DESC configuration: "
  if test_nginx_config; then
   echo "$NAME."
  else
   exit $?
  fi
  ;;

 status)
  status_of_proc -p /var/run/$NAME.pid "$DAEMON" nginx && exit 0 || exit $?
  ;;
 *)
  echo "Usage: $NAME {start|stop|restart|reload|force-reload|status|configtest}" >&2
  exit 1
  ;;
esac

exit 0

実行

これで準備は整った。

$ sudo /etc/init.d/nginx start

ブラウザーで http://myserver.com にアクセスして Nginx のページが出たら成功。

あとがき

Nginx。最初はパッケージ・インストールしたので楽なツールと侮っていたけど、自分で make するとかなり大変。でも、モジュールをインストールする時は再コンパイルが必要というので挑戦してみた。あー、疲れた。

2013-03-07

Redmine 2 系へのアップグレード方法

古い Redmine (< 2.0) を最新の Redmine にアップグレードするので、メモ。今回、ぼくは開発版をインストールした。2013-03-07 現在、Redmine の最新版は 2.2.3 (2013-02-12 リリース)。開発版をインストールする場合でも、問題はないはず。

参考ドキュメント

開発版は公式の git mirror から頂く。

アップグレード手順は以下のページを参照した。

必須条件

アップグレード必須条件を書いておく (PostgreSQL や SQLite3 を使ってる人は、「Redmineのインストール | Redmine.JP」を参照のこと)。

  • Ruby 1.8.7, 1.9.2, 1.9.3
  • RubyGems <= 1.8
  • Rails 3.2.12
  • MySQL 5.0 以上

Ruby 2.0 には対応していない。各アプリケーションのバージョン・チェック方法は以下の通り:

$ ruby --version
$ gem --version
$ gem list | grep rails
$ mysql --version

必要に応じてアップデートを行なわれたし。

データのバックアップ

以降、旧 Redmine は /var/redmine/ 以下にインストールしたとして話を進める。バックアップ先は ~/redmine-bakups。

$ mkdir ~/redmine-backups
files ディレクトリーのバックアップ

Redmine にアップロードしたファイルは、全て files ディレクトリー以下に保存されている。

$ rsync -a /var/redmine/files/ ~/redmine-backups/files
MySQL DB のバックアップ

mysqldump コマンドを使う。

$ mkdir -p ~/redmine-backups/db
$ /usr/bin/mysqldump -u USER -pPASSWORD REDMINE_DB | gzip > ~/redmine-backups/db/redmine_`date +%y_%m_%d`.gz

REDMINE_DB の名前は /var/redmine/config/database.yml の中を見れば確認できる。

アップグレード作業

Redmine の入手

安定版を使う人はDownloadページから最新版を入手して解凍されたし。ぼくは開発版を git から取って来る。

$ cd /var
$ git clone git://github.com/redmine/redmine.git redmine-dev

redmine-dev というディレクトリーに clone。既存の redmine ディレクトリー (今、動いているバージョン) を上書きしちゃわないように。

Redmine の設定
  1. 旧い config/dababase.yml をコピー
  2. 旧い config/configuration.yml をコピー (ver. 1.2.0 より前からアップグレードする時は config/configuration.yml.example を config/configuration.yml にコピーした上で旧 config/email.yml の内容をコピーする)
  3. files ディレクトリー以下をバックアップから復帰
  4. プラグインのコピー (これは後回しの方が安全かな?)
  5. rake generate_secret_token で config/initializers/secret_token.rb を作る
  6. テーマのコピー (これも後回しで良いかな?)

実作業は次の通り:

$ cd /var/redmine-dev/config
$ cp -p ../../redmine/config/database.yml ./
$ cp -p configuration.yml.example configuration.yml
$ cat ../../redmine/config/email.yml >> configuration.yml
$ cd ..
$ rsync -a ~/redmine-backups/files/* files
$ rake generate_secrete_token
$ ls config/initializers/secret_token.rb
config/initializers/secret_token.rb

トラブル・トラブル・トラブル

実は rake generate_secrete_toke する所でエラーになった。

 rake aborted!
no such file to load -- bundler/setup

bundler が必要らしいけれど、インストールされていない。インストールしようとしたら、gem のバージョンが古い (bundler は gem 1.3.6 以上) という。そんなわけで gem をアップデートして bundler をインストール。

$ sudo gem1.8 install rubygems-update -v 1.3.6
$ sudo update-rubygems
$ sudo gem1.8 install bundler

旧い Redmine が稼動中なので、gem をシステム・インストールするのは怖い。もしかすると、動かなくなるかも。bundler は --path オプションでローカルにファイルをインストールできる。推奨とされる ./vendor/bundle 以下にインストールすることにした:

$ cd /var/redmine-dev
$ bundle install --path vendor/bundle

しかし、ImageMagick 系でエラー。

checking for Magick-config... no
Can't install RMagick 2.13.2. Can't find Magick-config in (後略)

Magick-config がないという。ImageMagick 系のパッケージをインストール:

$ sudo apt-get install graphicsmagick-libmagick-dev-compat 

再度、bundle コマンド実行。

checking for wand/MagickWand.h... no

お次は wand/MagickWand.h がないという。libmagickwand-dev をインストール。

$ sudo apt-get install libmagickwand-dev

さあ、どうだ!!

$ bundle install --path vendor/bundle
Fetching gem metadata from https://rubygems.org/.........
Fetching gem metadata from https://rubygems.org/..
Resolving dependencies...
Using rake (10.0.3)
Using i18n (0.6.4)
Using multi_json (1.6.1)
Using activesupport (3.2.12)
Using builder (3.0.0)
Using activemodel (3.2.12)
Using erubis (2.7.0)
Using journey (1.0.4)
Using rack (1.4.5)
Using rack-cache (1.2)
Using rack-test (0.6.2)
Using hike (1.2.1)
Using tilt (1.3.4)
Using sprockets (2.2.2)
Using actionpack (3.2.12)
Using mime-types (1.21)
Using polyglot (0.3.3)
Using treetop (1.4.12)
Using mail (2.4.4)
Using actionmailer (3.2.12)
Using arel (3.0.2)
Using tzinfo (0.3.36)
Using activerecord (3.2.12)
Using activeresource (3.2.12)
Using metaclass (0.0.1)
Using mocha (0.10.5)
Using bourne (1.1.2)
Using bundler (1.3.1)
Using nokogiri (1.5.6)
Using ffi (1.4.0)
Using childprocess (0.3.9)
Using rubyzip (0.9.9)
Using websocket (1.0.7)
Using selenium-webdriver (2.31.0)
Using xpath (1.0.0)
Using capybara (2.0.2)
Using coderay (1.0.9)
Using fastercsv (1.5.5)
Using rack-ssl (1.3.3)
Using json (1.7.7)
Using rdoc (3.12.2)
Using thor (0.17.0)
Using railties (3.2.12)
Using jquery-rails (2.0.3)
Using mysql (2.8.1)
Using net-ldap (0.3.1)
Using ruby-openid (2.1.8)
Using rack-openid (1.3.1)
Using rails (3.2.12)
Installing rmagick (2.13.2)
Installing shoulda-context (1.0.2)
Installing shoulda-matchers (1.4.2)
Installing shoulda (3.3.2)
Installing yard (0.8.5.2)
Your bundle is complete! It was installed into ./vendor/bundle

成功!!

rake をこのまま実行すると、システムの gems を使ってしまう。bundle exec を使うと、--path で指定・インストールした gems を使ってくれる。なのでこれからの作業は bundle exec 付きで実行。

$ bundle exec rake generate_secret_token
$ ls config/initializers/secret_token.rb
config/initializers/secret_token.rb

secret_token.rb が出来ていることを確認して一安心。

MySQL の設定

MySQL の初期設定を行なう。

ここからは、ローカルの gems を使うので bundle exec を付ける。システム・インストールした gems を使う人は、適宜 bundle exec を消して作業されたい。

$ bundle exec rake db:migrate RAILS_ENV=production
クリーンアップ

キャッシュとセッション・ファイルをクリアする。

$ bundle exec rake tmp:cache:clear
$ bundle exec rake tmp:sessions:clear
パーミッションの変更

Apache などのウェブ・サーバーがディレクトリーにアクセスできるようにパーミッションを変更。

$ sudo chown -R redmine:redmine files log tmp
$ sudo chmod -R 755 files log tmp
確認

以上で Redmine 側の設定はおしまい。心配症な方は WEBrick サーバーを起動してチェック。

$ ruby script/rails server webrick -e production

ぼくはやらなかったけどね。

おしまい

最後にアプリケーション・サーバー (Apache とか) を再起動して実行。

DB を壊しちゃった人は、バックアップから復帰して再挑戦?

$ mysql -u USER -pPASSWORD REDMINE_DB < ~/redmine-backups/db/redmine_YYYY_MM_DD.gz

古い Redmine からアップグレードしようとすると、rake db:migrate RAILS_ENV=production でエラーが出るかもしれない。その場合は Redmine 2.2.2 をダウンロードして上の記事を参考に rake db:migrate ... を実行。データベースを新しくしてから、もう一度最新の Redmine で rake db:migrate ... をかける。

Redmine の公式ミラー・リポジトリー in git/hg

2010 年 3 月、Redmine の git による公式ミラー・リポジトリーについて書いた (Redmine の開発は Subversion で行なわれている)。

今日、サイトを見てみたら公式 git リポジトリーと hg (Mercurial) リポジトリーが載っていた。昔、紹介した git のミラー・リポジトリーも生きている様だけど、今後はこちらの方を使っておくのが良いかな。

ミラー・リポジトリーのプロジェクト・ページは以下の場所にある:

git における開発版の入手方法:

$ git clone git://github.com/redmine/redmine.git

Mercurial (hg) における開発版の入手方法:

$ hg clone https://bitbucket.org/redmine/redmine-trunk redmine

開発版に手を出したい方はどうぞ。

2013-03-06

irb —— Ruby のお手軽実行

Ruby のコードを書くのに、小さなコードのテストがしたい。でも、ファイルを開けて、一行程度のコードを書いて、shell から ruby を実行する... なんてしたくない。手軽に実行できる環境はないものかしらん、と聞いてみたら irb の存在を教えてもらった。

Ruby と一緒にインストールされるらしい。実行は irb コマンドを打つだけ。すると、ワンラナー形式で Ruby のコードが試せる。irb の中なら、設定した項目 (例えば def) も生きている。

$ irb
1.9.3p392 :001 > 'bye ' * 4
 => "bye bye bye bye "
1.9.3p392 :002 > str='bye '; str * 4
 => "bye bye bye bye "
1.9.3p392 :003 > 'foo'.center 20
 => "        foo         "
1.9.3p392 :004 > 'Sec 1'.ljust(10) + 'p.8'.rjust(10)
 => "Sec 1            p.8"
1.9.3p392 :005 > foo=['foo','bar','hoge']; foo.each {|f| print "This is #{f}\n"} 
This is foo
This is bar
This is hoge
 => ["foo", "bar", "hoge"]
1.9.3p392 :006 > def a(x) x * 5; end
 => nil
1.9.3p392 :007 > a(3)
 => 15
1.9.3p392 :008 > exit

exit で終了。こりゃいいや。

RVM で複数バージョンの Ruby をインストール

RVM (Ruby enViroment Manager) を使うと、Ruby のバージョン切り替え及び gem の環境切り替えができると聞いたので、インストール・メモと利用方法のメモ。

以下のサイトを参考にした。

インストールでハマる

apt-get でインストールできるかと思って試したら、どうもパッケージが見つからない。

$ rvm
プログラム 'rvm' はまだインストールされていません。 次のように入力することでインストールできます:
sudo apt-get install ruby-rvm
$ sudo apt-get install ruby-rvm
パッケージリストを読み込んでいます... 完了
依存関係ツリーを作成しています
状態情報を読み取っています... 完了
E: ruby-rvm のパッケージが見つかりません

ふふふ、ステキ (泣)。

インストール

» Installing Ruby RVM on Ubuntu 12.10 Obfuscated Reality を参考にインストール。まずは必要とされるパッケージを念のためインストール。

$  sudo apt-get install libxslt1.1 libxslt1-dev xvfb build-essential git-core curl libreadline-dev libyaml-dev libsqlite3-dev libgdbm-dev libffi-de libssl-dev

その後、rvm のインストール・コマンドを実行。

$ \curl -L https://get.rvm.io | bash -s stable --ruby

最新版 Ruby と各種必須ツール (らしきもの) のインストールが行なわれる。システム・インストールではなく、ユーザー・インストールになるらしい。インストール先は ~/.rvm/ 以下。インストールが終わると、次の様な文言が現れる

* To start using RVM you need to run `source ~/.rvm/scripts/rvm` in all your open shell windows, in rare cases you need to reopen all shell windows.

毎回コマンドを実行するのは面倒なので .bashrc に上記コマンドを書き込んでおく。

source $HOME/.rvm/scripts/rvm

Ruby の確認

インストールされた Ruby を確認する。

$ rvm list

rvm rubies

=* ruby-2.0.0-p0 [ i686 ]

# => - current
# =* - current && default
#  * - default

ruby-2.0.0-p0 がインストールされてた。

一応確認。

$ ls -F ~/.rvm/rubies/
default@  ruby-2.0.0-p0/

Ruby 1.9.* のインストール

最新の Ruby では困ることもあるので、枯れた Ruby も入れておく。

まずは rvm でインストール可能な ruby のバージョン確認。

$ rvm list known
# MRI Rubies
[ruby-]1.8.6[-p420]
[ruby-]1.8.7[-p371]
[ruby-]1.9.1[-p431]
[ruby-]1.9.2[-p320]
[ruby-]1.9.3-p125
[ruby-]1.9.3-p194
[ruby-]1.9.3-p286
[ruby-]1.9.3-p327
[ruby-]1.9.3-p362
[ruby-]1.9.3-p374
[ruby-]1.9.3-p385
[ruby-]1.9.3-[p392]
[ruby-]1.9.3-head
[ruby-]2.0.0-rc1
[ruby-]2.0.0-rc2
[ruby-]2.0.0[-p0]
ruby-head

# GoRuby
goruby

# TheCodeShop - MRI experimental patches
tcs

# jamesgolick - All around gangster
jamesgolick

# Minimalistic ruby implementation - ISO 30170:2012
mruby[-head]

# JRuby
jruby-1.2.0
jruby-1.3.1
jruby-1.4.0
jruby-1.6.5.1
jruby-1.6.6
jruby-1.6.7.2
jruby-1.6.8
jruby[-1.7.3]
jruby-head

# Rubinius
rbx-1.0.1
rbx-1.1.1
rbx-1.2.3
rbx-1.2.4
rbx[-head]
rbx-2.0.testing
rbx-2.0.0-rc1

# Ruby Enterprise Edition
ree-1.8.6
ree[-1.8.7][-2012.02]

# Kiji
kiji

# MagLev
maglev[-head]
maglev-1.0.0

# Mac OS X Snow Leopard Or Newer
macruby-0.10
macruby-0.11
macruby[-0.12]
macruby-nightly
macruby-head

# Opal
opal

# IronRuby
ironruby[-1.1.3]
ironruby-head

山の様に出てきた。ここでは、Ruby 1.9.3 系の最新版をインストールしてみる。

インストールには rvm install を使う。

$ rvm install 1.9.3
Searching for binary rubies, this might take some time.
No binary rubies available for: ubuntu/12.10/i386/ruby-1.9.3-p392.
Continuing with compilation. Please read 'rvm mount' to get more information on binary rubies.
Installing Ruby from source to: /home/ataka/.rvm/rubies/ruby-1.9.3-p392, this may take a while depending on your cpu(s)...
ruby-1.9.3-p392 - #downloading ruby-1.9.3-p392, this may take a while depending on your connection...
######################################################################## 100.0%
ruby-1.9.3-p392 - #extracting ruby-1.9.3-p392 to /home/ataka/.rvm/src/ruby-1.9.3-p392
ruby-1.9.3-p392 - #extracted to /home/ataka/.rvm/src/ruby-1.9.3-p392
ruby-1.9.3-p392 - #configuring
ruby-1.9.3-p392 - #compiling
ruby-1.9.3-p392 - #installing
Retrieving rubygems-1.8.25
######################################################################## 100.0%
Extracting rubygems-1.8.25 ...
Removing old Rubygems files...
Installing rubygems-1.8.25 for ruby-1.9.3-p392 ...
Installation of rubygems completed successfully.
Saving wrappers to '/home/ataka/.rvm/bin'.
ruby-1.9.3-p392 - #adjusting #shebangs for (gem irb erb ri rdoc testrb rake).
ruby-1.9.3-p392 - #importing default gemsets, this may take time ...
Install of ruby-1.9.3-p392 - #complete

バージョンを切り替える

まず、今、インストールされてる ruby のバージョンを確認。rvm list で詳細情報が表示される。

$ ruby --version
ruby 2.0.0p0 (2013-02-24 revision 39474) [i686-linux]
$ which ruby
/home/ataka/.rvm/rubies/ruby-2.0.0-p0/bin/ruby
$ rvm list

rvm rubies

   ruby-1.9.3-p392 [ i686 ]
=* ruby-2.0.0-p0 [ i686 ]

# => - current
# =* - current && default
#  * - default

最新 2.0.0-p0 と 1.9.3-p392 がインストールされ、現在のデフォールトが ruby-2.0.0. なことが分かる。

rvm use でバージョンを変更。

$ rvm use 1.9.3
Using /home/ataka/.rvm/gems/ruby-1.9.3-p392
$ ruby --version
ruby 1.9.3p392 (2013-02-22 revision 39386) [i686-linux]

うん。OK。

あとがき

長くなったので、gem のインストールについてはまた次回。しかし、もう最新の Ruby 2.0 が入るようになっているとはね。便利。便利。

2013-03-05

Amazon EC2 ファースト・トライ (4) Elastic IP Address — 固定 IP アドレスの落とし穴

上記の続き。Amazon EC2 ファースト・トライ記事はこれで一区切りの予定。

Apache の起動時にハマったことだけど、EC2 インスタンスは起動毎に Public DNS が変わる。つまり、再起動するたびにログイン・サーバーが変わるし、Apache で表示させるウェブ・ページも別の URL に変わる。

Elastic IP Address の設定を行なうと、固定 IP アドレスを取得できる。インスタンスと IP アドレスが紐付けされている限り、課金はされない。

設定

EC2 のダッシュボードから、Elastic IPs を選択。

You do not have any Elastic IP addresses allocated.
Click the Allocate New Address button to reserve an Elastic IP address.

固定 IP アドレスが振られてないよ、下のボタンを押しな。とメッセージが出る。

「Allocate New Address」ボタンを押下。

設定そのままで「Yes, Allocate」をクリック。

IP アドレスが決まった。今回は 54.249.248.51。でも、まだ固定アドレスを取得したにすぎない。複数のインスタンスを持っていたら、どのインスタンスに固定アドレスを振るか設定しなくちゃいけない。この設定はインスタンスの数が一個でも同じ。

画面右上の「Associate Address」ボタンをクリック。IP アドレスを振るインスタンスを選んで「Yes, Associate」を押す。

これで設定終了。

テスト

インスタンスを停止させる、その後、開始する。今までなら、これで Public DNS が変わってた。今は IP アドレスからアクセスできるはず。

$ ssh -i ~/.ssh/name.pem ec2-user@54.249.248.51

ログインできた!!

$ sudo /etc/init.d/httpd start

ウェブ・サーバーを起動して、http://54.249.248.51 にアクセス。ウェブページが見れた!!

気をつけたいこと

こんな記事をつけた。

アタッチしていないElasticIPには1時間あたり$0.01課金される模様。 使っていないから無料と思いきや、遊ばせておくと課金ってことね。

take some notes 【システム開発メモ Flex AWS DB WEB Android etc】 AWS ElasticIP 料金 ご注意 より引用

確かに「IP アドレスを紐付け」していると無料と書いてあった。それは逆を返せば、Elastic IP Address の設定をしてインスタンスを停止させていると、料金が発生するということ。

サービスが安定してほぼ 24 時間動くならまだしも、日曜プログラミングしている人やもう使わなくなったけどただ残してあるサービスなんかに Elastic IP Address 設定をしておくのはもったいないかもしれない。少額だけどね。

Elassonic IP Address を解放する

Elassonic IPs の設定画面で、解放したいアドレスを右クリック。「Disassociate」を選択。その後、「Release Address」ボタンを押す。以上。

これでもう、54.249.248.51 でアクセスしても何も起きない。

あとがき

今回、簡単に EC2 で遊んでみた。遊びなので、固定 IP アドレスは解放した。

一度やり方が分かれば 10 分ちょっとで設定が終わる。その代わり、初めての人は知らない概念に悩まされたり、値段体系を調べたりと時間を喰うと思う。時間のあるうちに一度試しておけると、後々のためになるかもしれない。

本を一冊くらい読んどく方が良いのかな〜?

Amazon Web Services クラウドデザインパターン実装ガイド
大澤 文孝 玉川 憲

4822211983
日経BP社 2013-02-07
Amazonで詳しく見る
by G-Tools

Amazon EC2 ファースト・トライ (3) Amazon EBS にファイルを保存

上記の続き。Amazon EC2 ではインスタンスを停止すると、ファイルが消えるという。これに対して Amazon は EBS と S3 という二種類の外部ストレージ・サービスを持つ。上記スライドでは EBS が使われていたので、これを使ってみる。

EBS とは...

EBS は Elastic Block Store の略。Amazon S3 が単体で使えるストレージなのに対して、EBS は EC2 と一緒に使うことが前提なストレージか。EBS の特徴は Amazon の公式ページに詳しい。

ボリューム・タイプは 2 つ。「スタンダード・ボリューム」と「プロビジョンド IOPS ボリューム」。前者はコスト重視、後者はパフォーマンス重視。

費用はスタンダード・モデルで 1 GB ごとに月 0.1 ドル。ただし、値段は「リージョン」によって徴妙に変わる。米国バージニアでは $0.1 だけども、アジアパシフィック (東京) では $0.12 になる。微々たる違いだけど、あんまり言及してるサイトがなかった。

ぼくが使ってる無料利用枠では EBS が 30 GB 提供される。無料期間が終わると、30 * 0.12 = $3.6/月 となるので注意が必要かな。まだ Amazon Web Service を使い初めたばかりで右も左も分からない。一年後には何が最良なのか分かる様になってる... といいな。

ログインして確認

前のエントリーでインストールした Apache がまだあるかどうか確認。

$ ls /etc/init.d/httpd
/etc/init.d/httpd

あれ、あるね。

試しにホーム・ディレクトリーに foo.txt を作成して、インスタンスを停止・開始してみる。

$ touch foo.txt

EC2 のダッシュボードから、インスタンスを停止。その後、開始。再ログイン。

$ ls
foo.txt

う〜ん、これは、どういうことかな? スライドの説明を読むと

今回立ち上げたEC2インスタンスのAMIは、仮想外部ディスク(EBS)を伴うAMI(EBS-bootと呼ばれる)なので...

というあたりが肝かな? 最初から EBS を使ってる?!

そうじゃないモデルを選んだ場合は、ファイルが消えるのかな。後でまた調べよう。

EBS のアタッチ

EC2 のダッシュボードから「Volumes」タブを選択。すると、一つ何か Volume が動いてる。スライドの説明だと、ここから State が Available な Volume をアタッチするんだけど、ぼくの手元では State が既に in-use になっていて「Attach Volume」なる選択肢が出ない。

テストなんで、新しくボリュームを作ってみる。

左上の「Create Volume」をクリック。最小 1 GB のボリュームを作る。

新しく作ったボリュームは State が available なまま。右クリックから「Attach Volume」を選択。古い Volume のチェックを外すのがコツ。そうしないと、右クリックしても「Attach Volume」が現れない。

インスタンスを指定。Device が /dev/sdf なことを確認。「Yes, Attach」をクリック。

State がすぐに in-use になった。

インスタンスから作成したボリュームにアクセスできるようにする。手順は次の通り:

  1. ファイル・システムの作成
  2. マウント用ディレクトリーの作成
  3. マウント
$ sudo mkfs -t ext4 /dev/sdf
mke2fs 1.42.3 (14-May-2012)
Filesystem label=
OS type: Linux
Block size=4096 (log=2)
Fragment size=4096 (log=2)
Stride=0 blocks, Stripe width=0 blocks
65536 inodes, 262144 blocks
13107 blocks (5.00%) reserved for the super user
First data block=0
Maximum filesystem blocks=268435456
8 block groups
32768 blocks per group, 32768 fragments per group
8192 inodes per group
Superblock backups stored on blocks:
        32768, 98304, 163840, 229376

Allocating group tables: done
Writing inode tables: done
Creating journal (8192 blocks): done
Writing superblocks and filesystem accounting information: done

$ sudo mkdir /ebs
$ sudo mount /dev/sdf /ebs

/dev/sdf を ext4 でフォーマット。/ebs にアクセス・ポイントを作って、mount コマンドでマウント。

これで EBS で作った新しいボリュームに /ebs からアクセスできる。EBS が壊れない限り、/ebs 以下に置いたファイルは削除されない。

あとがき

EBS の正体が分からずに困った。今も、実は良く分かっていない。とりあえず、無料期間は最大 30 GB のファイル・ストレージを持てたということで納得しよう。

Amazon EC2 ファースト・トライ (2) Apache の起動

Amazon EC2 ファースト・トライ 〜サインアップから EC2 開始・終了まで〜 の続き。

先のエントリーで参考にしたスライドに Web サーバーを公開する方法が書いてあったので、試してみる。

ログイン

まずは停止した Amazon EC2 インスタンスを起動。

前エントリーを参考に Amazon EC2 にログイン。

おっと、ログインに失敗。EC2 のダッシュボードから Instances を選び Public DNS をチェックしてみると、前回と違う。コレか。新しい Public DNS をコピーして、ログイン。成功! インスタンスを停止するたびに Public DNS は変わるのかな?

httpd のインストール

yum コマンドを使ってウェブ・サーバー Apache をインストール。Apache を起動する。

$ sudo yum -y install httpd
$ sudo /etc/rc.d/init.d/httpd start

yum の -y オプションは、インストール中に yum が聞いてくることにデフォールトで yes を返すオプションらしい。rpm と apt-get は使ったことあるけど、yum はほとんど初めてなので勝手が分からない〜。

ウェブ

http://Public DNS にウェブ・ブラウザーからアクセスしてみる。

ほい。ウェブ・ページが表示された。

あとがき

ログインには見事にハマッた。意外な盲点。初めてのユーザーはよく躓きそう。あと、ssh -i key ec2-user@PUBLIC_DOMAIN とすべき所を、勢いあまってユーザー名を消してしまうミスもやりそう ssh -i key PUBLIC_DOMAIN。

Amazon EC2 ファースト・トライ 〜サインアップから EC2 開始・終了まで〜

Amazon EC2 の名前ばかり知っていて、どんなことができるのか分かっていない人間がここに一人。重い腰を上げて Amazon EC2 の設定をしてみた。公式料金表によると、「新規ユーザー」は「マイクロ・インスタンス」の 750 時間使用が一年間タダとのこと。

サービス開始に必要なものは以下の通り (無料ユーザーであっても):

  • クレジット・カード
  • 電話 (Amazon から電話がかかってくる)

設定は、下記スライドを参考にした。

EC2 の起動からログインまでを書く。

詳細な解説及びスクリーン・ショットはスライドにあるので極力省略。作業手順を書いてゆく。

アカウント作成

  1. Amazon のページからアカウントの作成を行なう (例えば料金表ページに「今すぐサインアップ」ボタンがある)
  2. 既存の Amazon アカウントを使うか、新規作成するか問われる。
  3. 「問い合わせ情報」に「氏名・国・住所・市区町村・都道府村・郵便番号・電話番号」を半角英数字で入力 (日本語は使えない!!)
  4. クレジットカード情報を入力
  5. 番話番号を入力。「確認用に自分に電話をする」ボタンを押す
    • 画面に PIN 番号が表示される
    • 電話が Amazon からかかってくるので、PIN 番号を入力
    • 電話は日本語なので安心されたし
  6. Amazon から確認メールが届く。アカウントにアクセスして、アカウント作成終了。

自分のアカウント・ページに到達。ぼくの環境をスクリーン・ショットに撮った。

AWS のアカウントを作ったはずなのに、画面に AWS アカウントをお持ちではありませんか? 今すぐ申し込む という文言が不安を誘うが、AWS のアカウントはちゃんと作成できているので心配ない。

以降のログインは、下記 URL を使う。

EC2 の起動

EC2 の起動作業に入る。

  1. アカウント画面から「AWS Management Console」をクリック
  2. ログイン画面が現れるので、登録したメール・アドレスとパスワードを入力する
  3. 利用可能な Amazon のウェブ・サービスが並ぶ (ウホッ)
  4. 「EC2」を選択
  5. EC2 のダッシュボードに入る (ここから先は英語の画面)
  6. EC2 を起動する地域を日本国内にする
    • 右上のメニュー、「Help」の隣に EC2 を動かすサーバーのある地域が表示される
    • 無論、日本でサービスを行なうなら、日本でサーバーを動かす方が良い
    • ぼくの場合、「N. Virginia」(アメリカじゃん!!) になっていた
    • 地域を Asia Pacific (Tokyo) に変更
  7. 「Launch Instance」をクリック
  8. 「Classic Wizard」をクリック (Quick Launch Wizard という選択肢もある)
  9. AMI (Amazon Machine Image) の選択画面で「Amazon Linux AMI 2012.09.1 64bit」を選択 (星印は無料使用枠適用を表す)
  10. 「Number of Instances」が 1 に、「Instance Type」が「T1 Micro (t1.micro, 613 MB)」になっていることを確認して次へ
  11. 「Advanced Instance Options」には手を触れず次へ
  12. 「Storage Device Configuration」も手を触れず次へ
  13. 名前付け画面。とりあえず「Value」に「ataka.demo」と入力
  14. ssh の鍵作成。「Create a new Key Pair」を選びキーの名前を入力する
    1. 「Create & Download your Key Pair」をクリック
    2. 秘密キーが「name.pem」という名前でダウンロードされる (name 部分は各自好きな名前を)
    3. 秘密キーを ~/.ssh 以下に保存
      $ mv ~/Downloads/name.pem ~/.ssh
      $ chmod 400 ~/.ssh/name.pem
  15. 「Custom TCP rules」で「HTTP」を選択して、「Add Rule」をクリック
  16. 確認画面が現れるので、「Launch」ボタンを押す
  17. 引き続き設定を... と促されるが、「Close」をクリック

EC2 のダッシュボードに戻る。「Instances」タブが表示されて、今、作った AIM の State が running になっているのを確認。

これで EC2 の設定・起動は終了。

この後のログイン作業のために、Public DNS 情報をコピペしておく。「インスタンス」の行をクリックすると詳細情報が下に現れるので、スクロールして「Public DNS」の中身をコピー。

ssh でログイン

ssh コマンドでログインしてみる。

$ ssh -i ~/.ssh/name.pem ec2-user@YOUR_PUBLIC_DNS
       __|  __|_  )
       _|  (     /   Amazon Linux AMI
      ___|\___|___|

https://aws.amazon.com/amazon-linux-ami/2012.09-release-notes/
There are 10 security update(s) out of 15 total update(s) available
Run "sudo yum update" to apply all updates.
[ec2-user@ip-NN-NNN-NNN-NNN ~]$

ログイン・プロンプトが現れた!!

なんか、セキュリティ・アップデートが必要だと言っているので sudo yum update を実行しておく。

一応、チェック。

$ echo $SHELL
/bin/bash
$ which emacs
/usr/bin/which: no emacs in (/usr/local/bin:/bin:/usr/bin:/usr/local/sbin:/usr/sbin:/sbin:/opt/aws/bin:/home/ec2-user/bin)
$ which ed
/bin/ed

なるほど、shell は bash。デフォールトで Emacs エディターは入っていない。ed エディターは最低限入ってるから問題なし! と。

EC2 インスタンスの停止

スライドから引用。

EC2インスタンスを立ち上げたままにしておくと課金が続くので、不要になったらEC2インスタンスを止めておきましょう

EC2インスタンスには、終了(Terminate)と停止(Stop)の2種類があります

停止すると、EC2 の稼動料金はかかからないがEBS(ディスク料金)はかかります。しかしデータを保存しておいて、またサーバを立ち上げられます

終了するとサーバー、データともに完全に無くなります

EC2インスタンスの停止方法は次の通り:

  1. ダッシュボードから EC2 インスタンス一覧を表示する
  2. 停止したい EC2 インスタンスを選択し右クリック
  3. 「Instance Lifecycle」から「Stop」を選択
  4. 確認画面に対して「Yes, Stop」を選ぶ

少し時間がかかるけど State が「stopped」になって EC2 インスタンスが終了した。

あとがき

スライドには、HTTP サーバーの起動とか ERB の設定とかあったけど、まずはログインと停止までやっておけば最低限のことは出来るでしょ。続きはまた書く。

2013-03-04

「LINE なぜ若者たちは無料通話&メールに飛びついたのか?」の Kindle 版を思わず購入

秋元さんが「LINE なぜ若者たちは無料通話&メールに飛びついたのか?」という記事を書いている。同名の書籍のレビューなんだけど、興味をひかれたので思わず Kindle 版をポチッとしてしまった。

LINE なぜ若者たちは無料通話&メールに飛びついたのか? (マイナビ新書)
コグレマサト まつもとあつし
B00B99BLVI

書籍版は 872 円、中古 649 円。Kindle 価格 571 円。ページ数 232。そんなに厚くない。

感想記事の感想

ぼくを衝動買いに導いた文章を引用する。

僕自身、LINEの飛躍を冷ややかに見つつ使ってない非ユーザーなので、コグレさんが本をくれると言った時に断ったのですが、「LINE使ってない人にこそ読んでほしい」と言われ、受け取ったものです。

LINE なぜ若者たちは無料通話&メールに飛びついたのか? | 秋元@サイボウズラボ・プログラマー・ブログ より引用

ぼく自身の LINE に対するスタンスは秋元さんと同じ。LINE 非ユーザーでありつつも、その存在は意識している。でも使う気にはなっていない。

でも、コグレさんは、そんな人に読んで欲しいと言う。フムフム。

LINEでの将来的なビジネスに乗っかりたい人や、LINEと自社サービス・製品の関わり方を考えなければいけなくなるかもしれない業界人にとっては面白い本だなと感じました。

LINE なぜ若者たちは無料通話&メールに飛びついたのか? | 秋元@サイボウズラボ・プログラマー・ブログ より引用

この感想にガツンとやられた。ある程度サービスが大きくなってくると、やはり SNS としての規模の大きい LINE を無視できなくなる。自分のポリシーとして LINE を使わないというのはアリだけど、IT 業界で開発するなら LINE の雰囲気は知っとかなゃ、ね。

あとがき

本の感想は読書メーターに書いている。読み終えたら感想を書く。読書メーターの短い感想欄に納まらなければ、ブログの記事にするかも。

Ruby で文字列置換 〜 正規表現を使わずに その 2

clmemo@aka: Ruby で文字列置換 〜 正規表現を使わずに の続き。Just another Ruby porter, さんの記事を参考に。

ここでは&&=を使うのがぴったり。

str["perl"] &&= "ruby"

Re: Ruby で文字列置換 〜 正規表現を使わずに - jarp, より引用

おお、とても良いことを教えてもらった。ありがとう!!

試してみる

元のコードは次の通り。

str = "This is perl test"
pl = "perl"

if str.include?(pl)
  str[pl] = "ruby"
end

これを、&&= を使って書き直すと、こうなる。

str = "This is perl test"
pl = "perl"
str[pl] &&= "ruby"

わっ。コードの量が減って可読性も上がった。バグも減らせそう。

すると、前のエントリーの最終コードは次の様にシンプルになる。

IMAGE = [
  "http://www.foo.org/bar.png",
  "http://www.hogehoge.net/o/NNN_NNNN.jpg",
  "http://sample.net/more.png"
]

IMAGE.each { |img|
  line[img] &&= "external/" + File.basename(img)
}

とてもスッキリ、これは良いね。

Syntax Sugar

Just another Ruby porte, さんによると、&&= は次のコードのシンタックス・シュガーとのこと。

str["perl"] &&= "ruby" (シンタックス・シュガー)
str["perl"] && str["perl"] = "ruby" (本来のコード)

フムフム、勉強になる。str["perl"] 自身が bool 値を返すのか?

ワンライナーで確認。

$ ruby -e 'p "This is perl"'
"This is perl"
$ ruby -e 'p "This is perl".include?("perl")'
true
$ ruby -e 'p "This is perl"["perl"]'
"perl"
$ ruby -e 'p "This is perl"["ruby"]'
nil

上から見ていく。一つ目は文字列の確認。OK。

二つ目は include? のテスト。true が返ってる。

三つ目は str["words"] のテスト。なるほど、マッチした文字列が返るのか。Ruby は nil もしくは false 以外は true と等価なので、"perl" が返っているからこのテストは true と。

四つ目は、わざと間違えてみるテスト。見事に nil が返ってる。フムフム、すると str["perl"] = ruby で文字列 str に perl が含まれていないと、nil = ruby という風になっちゃうからエラーになるのね。

Ruby 面白いなぁ。

2013-03-02

Ruby で文字列置換 〜 正規表現を使わずに

Ruby で文字列置換をしたいと思って頭を悩ませた。なんとか出来たのでメモ。

文字列[置換される文字列] = 置換する文字列 という構文を使う。サンプル。

str = "This is perl test"
p str
str["perl"] = "ruby"
p str

これを実行する。出力は以下の通り。

"This is perl test"
"This is ruby test"

上手く行った。

一手間かける

このままだと、文字列 str が文字列「perl」を含んでいるかどうかが分からない。include? を使う。

str = "This is perl test"
pl = "perl"

if str.include?(pl)
  str[pl] = "ruby"
end
p str

出力を見てみる。

 "This is ruby test"

う〜ん、この判定は必要なのかな? 分からないや。一応、念のため。

配列を使って

本当は、絶対 URL を相対 URL に変えたかった。ただし、ほとんどの絶対 URL は外へのリンクとして残しておいて、一部の URL だけ相対 URL に変えたかった。本来のコードは、こうなってる。予め相対リンクにする URL をリスト・アップしておいて each で回す。

IMAGE = [
  "http://www.foo.org/bar.png",
  "http://www.hogehoge.net/o/NNN_NNNN.jpg",
  "http://sample.net/more.png"
]

IMAGE.each { |img|
  if line.include?(img)
    line[img] = "external/" + File.basename(img)
  end
}

出力例はもう出さないよ。これで、絶対 URL の画像を external ディレクトリー以下から参照するように変更できた。

あとがき

置換と言えば正規表現なのだけど、URL を正規表現に変えるのが面倒で... なんかコストもかかりそうだったし。文字列で置換が出来ないものかと調べて、この方法に辿りついた。

もっと良い方法があったり、間違いを犯しているようならご指摘たまわりたい。

ref

  • class String (Ruby 1.9.2 リファレンスマニュアル)