満足せる豚。眠たげなポチ。

はぶさんの WEB+DB PRESS Vol.21 のセルフ焼直しが素晴らしい。

以下、個人的ポイント。本文の要点ではないのであしからず。

ポイントその１。

ですが、それとは別にインスタンスライフサイクルを示すためのIdentifierの導入が必要だといってるのです。

中々すべてを得心できず、「我ながらあったま悪いなぁ〜」と思いながら、WEB+DB PRESS 読みまくったことを思い出します。けっきょく CRUD と One Fact in One Place の話だというのを理解するのに何十回と読むことになりました。

ポイントその２。

また実際の運用に入ったら、コード体系変更のリスクが予想以上に高いことに気付きます。疎結合を考えたときに、ID導入は実利として有効です。

ほんとに。考えて調整して運用で回避して、あるいは回避するためのアドホックなコードを練り込んで。

ってコストを考えると、考えずにとりあえず ID にしときゃいいじゃん。それでほとんど考えずに流れ作業的に解決できるじゃんと思います。

考えるコストと調整するコストってのは馬鹿にならないです。

判断の DRY 重要。

ポイントその３。

なので業務フローの定義ってのが本当に重要になる。それはデータフローじゃないんです。データが流れるんじゃなくてデータの状態が業務フローに沿って遷移していくということです。

あー、これはすごいわかるなー。

ってことで、最後は DHH の Why bother? で締め。(スライドの「これでよくね?」は名訳。)

そして、あえてこっちをおすすめする。

と、思ったらもう在庫切れなんですね。総集編もないようだし。おとなしく ERDレッスン をおすすめしておきます。

  

個人的には VB がどうなろうと別に構わないが、仕事の上では無視できないので記事を読んでみた。

@IT の「VB 6業務アプリはいつまで使えるの？ Vistaでは？」
http://www.atmarkit.co.jp/fdotnet/vblab/opensemi_01/opensemi_01_01.html

例えば、マルチコアのCPUが登場するなど、現在でもなお、PCのパフォーマンスは急ピッチで上がり続けています。マルチコアCPUの性能を十分に引き出すには、アプリケーションの実行コードがそれに対応にする必要があります。しかしもはや一昔前の開発言語であるVB 6ではそのような実行環境を生かすことはできません。向上するハードウェア性能の恩恵に浴せないようなアプリケーションで、本当に顧客を満足させ続けることができるのでしょうか。

どこの世界にマルチコアの CPU のフルスペックを引き出さないといけないような VB アプリがあるんだよ。適材適所でやってれば、昨今のハードで VB が性能のボトルネックにはならないだろうに。(現実になってるところもあるだろうけど、それは VB 自体のパフォーマンスではなく設計上、実装上の問題だろう)

理由のための理由を聞かされてもなぁ。

  

フレームワーク（Rails とかのじゃなくて、思考の方の）は、物事をパターンにはめるために使うんじゃなくて、自分の中で MECE に整理するために使うんだな。

世に出回るフレームワークは 3C とかの既製品ばかりだから、根本的に誤解していた。

そう考えると、つまらない問題をお手製フレームワークで思考するってのもありなわけだ。

何事も目的を理解して使うのは大事だなぁ。

つまり、「企業の戦略を考えるときは、 3C のフレームワークを使おう」というデザインパターンとして使うんじゃなくて、「今日の昼食は何を食べようか」という問題があったら漠然と考えるよりも、「予算・体調・天気」の３要素をフレームワークとして使ってみようかな、というように柔軟に有効に使うべきだということ。

  

ダメだ、おもしろすぎる。

http://www.shudo.net/article/OSM-200606-hacker/

普通のやつらの上を行け (*5)

この言葉は「私はLispが大好きだ」という意味であり、 Lisp系言語を愛用していない人に対する煽り (*6) です。

  

ちなみに、前のエントリで触れた「経営者の条件」はドラッカーが個人に対して投げかけた最高の一冊。

「経営者の」という言葉に抵抗を感じて未読の方はぜひ読むことをお薦めします。「プロフェッショナルの条件」であり、「Pragmatic Programmer のための条件」であり、「Agile であるための条件」でもありえると思います。

  

基本は、ドラッカーの「経営者の条件」の第二章に集約される。

• 時間の使われ方を実際に記録し、
• やるべき仕事以外のもの(やらなくてよい仕事ではない)に手を付けるのを止め、
• 残った時間をまとめ、大切なことに集中する時間を作る

これは話としてはわかっていた。優先順位ではなく、劣後順位を付ける。

でも、この話がわかっても、実践できていたかというとできていなかった。

それが、次のことを意識するようにしたことで劇的に改善した。

それは、仕事には、

• 定量的な仕事(一定の時間やれば確実に終わり、かかる時間も読みやすい仕事)
• 定量的でない仕事(一定のところまでやれば終り、というのがはっきりしない仕事)

と、

• やりたい仕事・好きな仕事
• やりたくない・気の進まない仕事

があるということ。

そして、その中で、

• やるべき仕事
• それ以外の仕事

があるということ。

これらの優先順位はこのようになる。

1. やるべきで、定量的な仕事
2. やるべきで、定量的でない仕事
3. それ以外

当然、「それ以外」はやらない。

ちなみに、これを意識しないと自然と陥りがちな作業順序はこうなる。

1. やりたい仕事で、定量的でない仕事(甘い蜜)
2. やりたい仕事で、定量的な仕事(いつでもできそうだから後回し)
3. やりたくない仕事で、定量的でない仕事(だらだら仕事)
4. やりたくない仕事で、定量的な仕事(面倒なので先延ばし)

「やりたい仕事で、定量的でない仕事」は無駄な作業時間を永遠に長引かせることができる魔法のツールだ。仕事をやってるふりをしながら、成果を出さずに忙しさを演出できる。

正直、ぼく自身もこれが大好きだ。(なんせ「やりたい仕事」なんだし。) Ruby でツールを無駄に凝りながらプログラミングしたり、そこに関心のあるライブラリを使ってみたり、しかも自分用のツールでエンドがない仕事だから時間は使い放題。その上で仕事上のツールだから、あくまで仕事の内。後ろめたい気分になるようなこともない。

しかし、これは冷静に時間に対するアウトプットを考えてみると、成果が少ない。(自己満足は高いので客観視する指標を作らないと、言い訳し放題。)

まとめとして、この一言を。

「最初に申したではないか。まず時間を決めよと」
「はあ」
「なにを何時間、何分間やるのか、決めること。そして時間が来たらやめる。そうしなければ、ほかのことができなくなるではないか」
「はあ」
明るい国の王様は、とまどうクラゾーに「まず、それを決めなければならぬのじゃ」と釘を指しました。
「王様の速読術」より

「まず時間を決めよ」「そうしなければ、ほかのことができなくなるではないか」

この言葉は RSS フィードに埋もれて身動き取れなくなったり、mixi にはまって廃人になったりする時代に、主体的に時間を使うとはどういうことかを端的に語ってくれている。

ちなみに、この「まず時間を決める」こそが、「やるべきで定量的でない仕事」に全体のバランスを見つつ集中するための秘訣だと思う。

  

くまくまーの中の人が書いた Ruby on Rails 入門が気になっていたので、仕事帰りに本屋で購入。(既発の Rails 本が全部置いてあった職場近くの本屋は正直どうなんだとちょっと疑問に思った。それだけ Rails が浸透したのか?)

肝心の本を2時間くらいで読了したわけですが、かなり良い出来でした。2冊目の Rails 本に一押し。1冊目なら、大人しく AWDwR の前田修吾さん監訳版なんかを購入しておいた方が安全と思われます。

それにしても、舞波はさておき、ActiveSupport から始まる Rails の解説というのもこだわりが感じられ、とにかく今この瞬間の Rails を切り取った本としては最高に面白い仕上がりでした。「 Pragmatic Programmers の Ruby 本 + レシピブック」みたいなかんじで、「 AWDwR + 舞波本」というかんじのポジション取りに最適。

  

なに、このエグイの。

How to create a Ruby extension in C in 43 seconds
http://www.rubyinside.com/how-to-create-a-ruby-extension-in-c-in-43-seconds-167.html

RubyInline さえインストールしておけば、Ruby コード中に C のコードを書いて、インラインで実行可能らしい。

拡張モジュールが 43 秒で!って、実行速度とかごりごりと .so を作るのとどのくらい違ってくるんだろう。

局所的にパフォーマンスがどうこうっていうようなときにこれでさっくり解決したらかっこいいなぁ。

  

知らないうちに del.icio.us の edit 機能がシンプルになってた。一覧の状態からさくさくと編集できて、とても快適。

機能追加や機能変更のたびに思うけど、 del.icio.us の UI はほんとセンスがいいよなぁ。