改めて思った 2 + 1 のこと
最近、人に話すことで改めて自分の思いに気づいたことが二つある。
- いい仕事をしたい
- 中小企業には時間も人手も余裕はない
軽く掘り下げて書き残しておきたい。そして書いている途中で出てきたのが
- 老害になりたくない
である。これも残しておこう。いつか振り返ったときにいろいろ思えるかもしれない。
いい仕事したいじゃん
「いい仕事」という言葉はいろいろな意味を含む。人によって定義が変わってしまう曖昧な言葉とも言えるけど、ここではとりあえず曖昧なまま行ってしまっていいんじゃないかと感じている。エンジニアにはエンジニアの、営業には営業の、会計には会計のいい仕事があるはずだ。それでいいと思う。
正直なところ自分は何もしなくていいなら何もしたくない人間だ。好きなことだけダラダラできるならこんな素晴らしいことはないと思うし、それでも恐らくヒマで困っちゃうようなタイプではないと思っている。
ところが残念ながら現実はそう甘くない。仕事しないと生きていけない。社会が抱えるあまりに大きな負債について「なんでこんなアホな話ばっかなんだ」と思うことは多いけれど、ひとまずそれを置いて目の前の問題に対処しなければいけない。つまり仕事するのだ。
どうせやり続けなくちゃいけないのならば「いい仕事」をしたいと自分は思うタイプである。アジャイル的には「お客様の満足」と言うのがここはかっこいいところなんだけど、あまり一つの言葉で置き換えてしまいたくはない。将来の自分が開発しているとも限らない。
中小企業には時間も人手も余裕はない
これは大きな会社でも特に真面目に国内トップレベル、あるいは世界レベルで「競争」しているところも同じかもしれない。要するに
余っているものなんか何もない
のだ。だから「本当に必要なの？」と疑問に感じるような仕事はどんどん見直さなくちゃいけない。
例えば IT の世界でよく聞くのは
- のちにちゃんと振り返りもしないのに大量に書かされる言い訳文書
- メンテナンス性、検索性の悪い Excel 仕様書
- 重すぎてまともに作業できない Excel のバグ票
- 仕様書と合ってないコード
- 酷似しているのに微妙に違う大量のコピペコード
- 意図を伝えず動作だけを説明する「意味のない大量のコメント」
- 作業効率を著しく落とす「コメントアウトされた前バージョン」
これらはすべて現実によくある話1。ここで挙げたのは大まかに
- 無駄な文書、無駄なコード
- 作業効率の悪い文書フォーマット、作業効率の悪いコード（読みにくいコード）
に集約される。
つまり日々の生産性を確実に落とすものたちだ。ということは全部見直しの対象である。見直さないと、本来達成すべき「価値」ではなく「作業」に自分の「手」と「意識」を奪われてしまう。
しかしここで問題になるのが多層下請け構造。元請けなら文書、コードのルールは自由に設定できるが、下請けの場合はそうもいかないこともよくある。幸い自分はそういう環境にはないので、直せるところは直していかないと
競争力を失って退場させられてしまう。
それが我々の生きる世界なのだ。
老害にはなりたくない
あれ、三つ目がでてきてしまった。
書いてるうちに再確認できたことがもう一つあった。自分は
老害にはなりたくない
んだなと強く思った。
上に挙げた問題は基本的に
過去を踏襲しているだけの作業が新たな価値の創造を阻害している
と言えると思う。つまりかつてはそれが最善と思われたのでそうなったのだ。多少好意的解釈を多めに加える必要はあるが。しかし今はより適切な道具を適切に使いさえすればもっと良い作業に変えることができる。少なくとも
- 現代的なバージョン管理システム
- 現代的な Issue Tracking System
を正しく運用すれば、上の問題の多くは解消できる。もちろん導入しただけですべて解決するわけではない2が、少なくともルーチンワークのコストを下げる準備はできる。
だからこの二つは最低限達成しなければいけない。
しかしそこで浮上してくるのが
教育／学習コスト
の問題である。
ここは残念ながら失うものの多いベテランの抵抗が強い。年を取れば取るほど新しいものの習得は億劫になるし、ヨーイドンで同時に学習を始めたら若いやつにかなう訳がない。気持ちは分からなくはないが、もうその状態は老害になっていると思った方がいい。
自分を振り返って、自分の周りの人間を観察して思い当たることはないだろうか。はっきり言って自分で触ってもいないのにしたり顔で○○の批評をするやつは老害だ。年齢は関係ない。気をつけて掛からなきゃいけない。○○には何を入れてもいい。ちょっと前ならスマートフォンが入るし、とりあえず新しめのものを入れればだいたい成り立つ。
自分は今ちょうど境目にいると思っている。今はまだ老害ではないが、ちょっと学ぶ意欲が足りなくなったらあっという間に老害になる危険を感じている。学ぶ意欲というのは個性かもしれないが環境の問題もやはり大きい。老害になった方がいいかもしれないと感じてしまうようなら、「見捨てる」結果になるとしても、環境を変えた方がいいのかもしれないとも思う。
あるいは例えば新しい技術についての判断はしない、ただの老として生きるか。今の自分はまだ老害に腹を立てる側の人間である。つもりだ。しかしいつか労害になり得る。いつかストップを掛けてしまう側の人間になる。そのときにはもうその判断をしない立場にならなければいけないのではないかとも思っている。
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 にしましょうか
といった柔軟な運用が可能になった。
よしよし。
参考
- 満足せる豚。眠たげなポチ。:CGI から Mongrel まで、Rack で Web アプリを Web サーバから抽象化する
- ウノウラボ Unoh Labs: RackでWebアプリのWebサーバー依存を無くす
というか加齢とともに落ちる一方だぜ！ オレは10代の若者じゃねぇ！ ↩
FreeBSD Security Advisory FreeBSD-SA-06:25.kmem
以前のサーバは手でリセットスイッチを押さないと再起動できなかったが、今度のは躊躇せずリモートで再起動を掛けられる。
スバラシイ。
根っから役者なのかと思ったら美大でデザインを専攻していたのか。どおりで妙に自己完結する世界を作ると思った。映画を撮るのも「映画製作という世界」を自分で作り上げたいというところなのかな。
才能と機会を両方持つ人。役者から絵描きみたいなことをする人は多いけど、この人は今後何を作っていくのだろう。
今のパソコンは金か手間を掛けるしかない。手間を掛ける時間のない人、手間の掛け方の分からない人はお金を使ってください。
こんなものができていたのね。街中の研修施設（最大一部屋26人まで）や会議室（最大一部屋12人まで）としても使えるってことで、なかなか便利なんじゃなかろうか。まぁ自分にはあんまり関係なさそうだけど。
ネットワークリソースはネスク。こういうとこに食い込んでいるのか。
【結果発表】IT Pro読者はFirefoxをどう評価したか : IT Pro 記者の眼
Web のプロじゃない人の方が圧倒的多数だろうとは思うんだけど、レイアウトが崩れるとかそんな初歩的なことをぬかす ASP.NET 開発者ってどうなんだ。今まで IE でしか確認してないってことでしょ。そんなんでプロ名乗るな。
あと、IE でしか見られないサイトに対応できるようにしてほしいという意見が多いんだけど、そんなことしたら Gecko が複雑になって遅くなるし、ユーザーがサイトに対して意見していかないと状況は少しもよくならないってことが分からないのかなぁ。
これが IT の Pro たる読者の意見なのか。違うのか？ 読者は Pro の卵か？ なんだか謎だ。
以前からどうしてこれが実現していないのか不思議でならなかったことが、IME の情報をステータスバーに表示する機能。OS 標準でこの機能を提供してくれていればいいのに、と何度も思っていた。IME のツールバーを独立して表示させるのは邪魔だけど、タスクバーまで視線を移動させるのもかったるい。
というわけで Clock Pod というソフトを見つけた。これはもともとは時計を表示するものだったのだが、今ではかなりいろんな情報を表示できるようになっている。多くの情報を表示するためにテロップ機能（ゆっくりスクロールさせることで文章などの比較的多くの情報を狭い範囲に表示する機能）がついているのは最近のこの手のツールの常識のようであるが、これは全然必要ないので設定でバッサリカット。
ちなみに、設定方法はいきなり設定用のテキストファイルが関連付けられたアプリで開かれるという大胆なものだ。初心者は引くだろうがレジストリにもノータッチだし、編集を終了すればすぐに設定が反映されるので個人的にはこの方法はかなりありがたい。けっこう気に入ってしまった。