2003-12-06
_ タイトルバーに IME の情報を
以前からどうしてこれが実現していないのか不思議でならなかったことが、IME の情報をステータスバーに表示する機能。OS 標準でこの機能を提供してくれていればいいのに、と何度も思っていた。IME のツールバーを独立して表示させるのは邪魔だけど、タスクバーまで視線を移動させるのもかったるい。
というわけで Clock Pod というソフトを見つけた。これはもともとは時計を表示するものだったのだが、今ではかなりいろんな情報を表示できるようになっている。多くの情報を表示するためにテロップ機能（ゆっくりスクロールさせることで文章などの比較的多くの情報を狭い範囲に表示する機能）がついているのは最近のこの手のツールの常識のようであるが、これは全然必要ないので設定でバッサリカット。
ちなみに、設定方法はいきなり設定用のテキストファイルが関連付けられたアプリで開かれるという大胆なものだ。初心者は引くだろうがレジストリにもノータッチだし、編集を終了すればすぐに設定が反映されるので個人的にはこの方法はかなりありがたい。けっこう気に入ってしまった。
2004-12-06
_ ITPro の読者層ってどうなんだ。
【結果発表】IT Pro読者はFirefoxをどう評価したか : IT Pro 記者の眼
Web のプロじゃない人の方が圧倒的多数だろうとは思うんだけど、レイアウトが崩れるとかそんな初歩的なことをぬかす ASP.NET 開発者ってどうなんだ。今まで IE でしか確認してないってことでしょ。そんなんでプロ名乗るな。
あと、IE でしか見られないサイトに対応できるようにしてほしいという意見が多いんだけど、そんなことしたら Gecko が複雑になって遅くなるし、ユーザーがサイトに対して意見していかないと状況は少しもよくならないってことが分からないのかなぁ。
これが IT の Pro たる読者の意見なのか。違うのか？ 読者は Pro の卵か？ なんだか謎だ。
_ ITビジネスプラザ武蔵
こんなものができていたのね。街中の研修施設（最大一部屋26人まで）や会議室（最大一部屋12人まで）としても使えるってことで、なかなか便利なんじゃなかろうか。まぁ自分にはあんまり関係なさそうだけど。
ネットワークリソースはネスク。こういうとこに食い込んでいるのか。
_ 竹中直人
根っから役者なのかと思ったら美大でデザインを専攻していたのか。どおりで妙に自己完結する世界を作ると思った。映画を撮るのも「映画製作という世界」を自分で作り上げたいというところなのかな。
才能と機会を両方持つ人。役者から絵描きみたいなことをする人は多いけど、この人は今後何を作っていくのだろう。
2005-12-06
2006-12-06
_ kernel の更新もどんとこい
FreeBSD Security Advisory FreeBSD-SA-06:25.kmem
以前のサーバは手でリセットスイッチを押さないと再起動できなかったが、今度のは躊躇せずリモートで再起動を掛けられる。
スバラシイ。
2008-12-06
_ CGI を rackup してみた
Ruby は自分の大好きな言語だが、実は長く運用する Web アプリを Ruby で書いたことはない。cgi.rb の評判はずいぶん前から芳しくないし、決定打となるフレームワークの不在が長く続いたこと、すでに PHP を使っていたことが大きな理由だった。
Rails が登場した。勉強した。「うーん、なんか DBMS とか要らないんだけど、どうしたらいいのよ？」と思っているうちに世間ではすっかり定着、代わりに自分の中では興味は薄れていった。そうこうしているうちに Rails の問題点もちょこちょこ指摘されるようになり、prototype.js とともに先駆者ゆえの苦難を味わっているなぁと感じている今日この頃。
Merb だなんだと言われていた中、Rack が登場した。これだ！と思った。こういうシンプルなやつが欲しかったんだよ！ しかしそれから特に何の理由もないまま一年半の月日が流れた。なんかこんなんばっかだな。RSS の登場により情報の収集は速くなったけど、知識にするための時間、手を動かして「つかむ」までの時間は、自分という人間の性能が変わらない*1のでちっとも短くならない。
そんなオレ語りはどうでもよく、今回はようやく自分で Rack を使ってみましたよというお話。しかも、あんまり見ない、WEBrick と CGI の二本立て。試したのは gem で入れた rack 0.4.0
Rack の使い方は二段階ある
超簡単なチュートリアルを読んでもリファレンスを見てもこの違いを明確に意識することができなくて苦労した。Rack の機能には以下の二段階がある。
- Handler によってアプリケーションサーバの違いを抽象化する
- rackup によって便利なミドルウェアを使う
この違いは
- ruby から直接 Rack::Handler::FOO.run( App.new )
- rackup から run( App.new )
の違いからくる。要するに
ミドルウェアを use したければ rackup しろ
ってこと。
逆に言うと rackup しなくても Request, Response の抽象化は行えるので基本的なことはできる。
ではそれぞれの方法をもう少し詳しく見てみる。
※ ブコメいただきました。ミドルウェアの中にアプリケーションを突っ込んで、ミドルウェアを Handler に渡すという方法もあるようです。なんかちょっと不思議な感じもしますが、そもそも内部ではミドルウェアでアプリケーションを再帰的に wrap する構造のようです。
lib/rack/lobster.rb at master from chneukirchen's rack ― GitHub
ruby から直接 Handler を呼ぶ方法
WEBrick の例
komagata さんの記事から拝借。
ウノウラボ Unoh Labs: RackでWebアプリのWebサーバー依存を無くす
#!/usr/bin/env ruby
require 'rubygems'
require 'rack'
class HelloRack
def call(env)
[200, {"Content-Type" => "text/plain"}, ["Hello, Rack"]]
end
end
Rack::Handler::WEBrick.run HelloRack.new, :Port => 3000
この hello-rack.rb を
ruby hello-rack.rb
で起こし、これにブラウザからアクセスすると
Hello, Rack
と表示される。うむ。
CGI の例
同じことは CGI でも当然できる。
#!/usr/bin/env ruby
require 'rubygems'
require 'rack'
class HelloRack
def call(env)
[200, {"Content-Type" => "text/plain"}, ["Hello, Rack"]]
end
end
Rack::Handler::CGI.run HelloRack.new
こんな感じで Handler を CGI にしてやれば ok. これを
- Web サーバ配下の CGI の実行可能なディレクトリに置いて
- 実行権限を付けて
ブラウザからアクセスしてやるとさっきと同じように
Hello, Rack
と表示される。めでたしめでたし。
これで cgi.rb を使わなくても Ruby で CGI を書けるようになったよ！
（CGIAlt があるとか言わないでね。）
気をつけなきゃいけないこと
以下は自分のためのメモ
- CGI の場合は Web サーバがアプリケーションを勝手に起こしてくれるけど、実行権限の付与が必要
- WEBrick（など）の場合は自分でアプリを起こしてやらないといけない
自分の場合は生 CGI を触る機会が減っているので実行権限の付与をしょっちゅう忘れる。
でも Rack の本当の威力を味わうなら rackup
rackup は
rackup -s webrick [config file]
などとして server(handler) を指定してアプリケーションサーバを起動する。rackup が行われると、中で
Rack::Builder
がアプリケーションサーバの環境を作ってくれ、自分の書いたアプリケーションはこの中で実行される。
ここで初めて use が使えるようになる。
もうちょっと細かく見てみよう。
use は Rack::Builder の instance_method
Rack でミドルウェアを追加する use は Rack::Builder の instance_method となっている。
irb(main):001:0> require 'rack' => true irb(main):002:0> Rack::Builder.methods.grep( /use/ ) => [] irb(main):003:0> Rack::Builder.instance_methods.grep( /use/ ) => ["use"]
つまり
require 'rack'
しただけでは use は使えない。
rackup の流れ
rackup を読んでみると、アプリケーションは rackup の中で以下のように実行されている。（詳細は端折ってある）
Rack::Builder.new {
run inner_app
}
つまりそういうこと。Rack の便利機能を使いたければ rackup すべし。
では実際に rackup してみる。
WEBrick の例
直接起動で use の使えない様子
さきほどの hello-rack.rb に use を加える。
#!/usr/bin/env ruby
require 'rubygems'
require 'rack'
use Rack::ShowExceptions
class HelloRack
def call(env)
[200, {"Content-Type" => "text/plain"}, ["Hello, Rack"]]
end
end
Rack::Handler.WEBrick.run HelloRack.new, :Port => 3000
すると、当然ながら
$ ruby hello-rack.rb hello-rack.rb:6: undefined method `use' for main:Object (NoMethodError)
怒られる。use なんて使えない。
rackup してみる
#! /usr/bin/env ruby
require 'rubygems'
require 'rack'
use Rack::ShowExceptions
class HelloRack
def call(env)
[200, {"Content-Type" => "text/plain"}, ["Hello, Rack"]]
cho_www
end
end
run HelloRack.new
ここで注目してほしいのは、
- cho_www という syntax error をアプリケーションの中に仕込んであるところ
- run の呼び方を変えたところ
どうも
rackup するときは Handler は外から（rackup の -s オプションで）指定してあげた方がなんかうまくいく感じ。
これを hello-rack.ru の名前で保存し、
rackup -s webrick -p 3000 hello-rack.ru
で実行。
ご覧のようにブラウザ上に Exception を表示できる。画像では端折ってあるが TraceBack も表示できる。当然のことながら cho_www を削除すれば普通に動く。
CGI の例
直接起こして use してダメなのはさっき WEBrick で見たので省略。
rackup する
ru ファイルはさっき用意した hello-rack.ru をそのまま利用。CGI の方は以下のようにする。
#! /bin/sh /opt/local/bin/rackup hello-rack.ru
パスが /opt/local/bin なのは MacPorts で入れた Ruby で gem を使ってインストールしているから。rackup のパスは適宜調整すること。
これを hello-rack.cgi の名前で保存、ごにょごにょしてブラウザからアクセスしてみる。画像の中の URL の違いに注目。確かに CGI で動いている。
ただし、当然のことながら CGI で rackup するのは負荷的には不利。
従来の流れ
- shebang から Ruby を起動
- 自分自身を読み込ませる
rackup 時の流れ
- shebang で sh や他のインタプリタから
- rackup コマンドを呼び出し
- そこから ruby が呼ばれ
- アプリケーションがロードされる
という長い道のりを要するようになってしまう。でもメリットでかいし。
わざわざ別プロセスの rackup から起動しなくてもいんじゃね？と思いたいのは分かる。自分も思った。でも結局 rackup と同じとまではいかないまでも似たような流れで Rack::Builder を呼んであげなきゃいけないので、Rack に頼るうまみが薄れちゃうよね？と思うのでそういうことはしないことにした。
まとめ
何はともあれ、Rack の基本的な使い方は分かった。map とかは分かってないけど、これで
- WEBrick で開発
- とりあえず CGI で deploy
- 負荷的にまずいので FastCGI にしましょうか
といった柔軟な運用が可能になった。
よしよし。
参考
*1 というか加齢とともに落ちる一方だぜ！ オレは10代の若者じゃねぇ！
