ん～、これはむずかしい問題なんだけど。でも、やっぱり、 誰がミスしたのかっていうのはハッキリさせなきゃいけない と思うんだよね。たとえチームの雰囲気が険悪になると してもね。もし、本当にいいチームなら、それを乗り越え られると思うし。

ハッキリさせないと、やっぱり他人事になっちゃうんだよね。 もちろん、『問題 vs 私たち』っていうのは好きな言葉なん だけどさ。

ハッキリさせるっていっても、そのやり方は状況次第だしね。 チームが体育会系で若いんだったらビシッといってやれば いいし。成熟度が高いんなら、一言いえば当人が反省する だろうし。

これは同意。

けっきょくミスの原因と対策を真剣に考えるとその過程で直接のミスをした人っていうのは明らかになっちゃうよね。

そこから人の問題としてミスした人に焦点を当てるか、それとも仕組みの問題と捉えてミス自体に焦点を当てるかというのが大事になってくるわけで。

だから、そういう意味ではミスした人がはっきりする状況というのは別に『問題 vs 私たち』に反しないとも思う。

そこをみんな大体誰がミスしたのかは知っているけど、あいまいに指摘せずに「まぁ、次からみな気を付けていきましょう。」というような締め方をするようであれば、それはけして『問題 vs 私たち』という意味での「私たち」ではないし、結果にたいして一番不誠実な態度だと思う。

With this context in mind, I claim that the Properties Pattern is yet another kind of domain modeling, with its own unique strengths and tradeoffs, distinct from all the other modeling schools I've mentioned.

At a high level, every implementation of the Properties Pattern has the same core API. It's the core API for any collection that maps names to values:

• get(name)
• put(name, value)
• has(name)
• remove(name)

あー、なんか話が見えてきた。

Let me summarize what I think are the key takeaways.

First: this is a critically important pattern. I call it the "Universal" design pattern because it is (by far) the best known solution to the problem of designing open-ended systems, which in turn translates to long-lived systems.

You might not think you're building that kind of system. But if you want your system to grow, and have lots of users, and spread like wildfire, then you are building exactly that kind of system. You just haven't realized it yet.

Second: even though people rarely talk much about this pattern, it's astoundingly widespread. It appears in strongly-typed systems like Eclipse, in programming and data-declarative languages, in end-user applications, in operating systems, and even in strongly typed network protocols, although I didn't talk about that use case today. (Nutshell: a team I know using CORBA got fed up and added an XML parameter to every CORBA API call, defeating the type system but permitting them to upgrade their interface without horking every existing client. Bravo!)

Third: it can perform well! Or at least, "well enough". The playing field for potential optimizations is nearly unbounded, and with enough effort you can reduce just about everything to constant time.

Finally, it's surprisingly versatile. You can use it on a very small scale to augment one teeny component of an existing system, or you can go the whole hog and use it for everything, or just about anything in between. You can start small and grow into it as you become more comfortable with the pattern.

The Properties Pattern is not "just" name/value pairs, although the name/value pair certainly lives at the heart of the pattern.

これはうつを防止するためのツールではなくて、日常のコミュニケーションの中で必要な質問をしてもらうためのツール。企業の中で使っているものだけど、他にも使える場面があるかと思う。

ということで、「質問があったらいつでもしてください」と言わずに質問を受け付けるための４つのステップ。

1. 今なにをしているの？と聞く
2. したことの説明を受ける
3. 受けた説明について、そう考えた理由や今後についての見解を聞く
4. 最後に、何か困っていることは？と聞く

以上。

詳細の説明は省くけど、それぞれに4つ目の質問が出てきやすいようなトリックが入っているのでバカ正直にこの順で毎日会話をすればいい。

ここに書かれていないことで前提の条件になりそうなこと（心構えとか）もいくつかあるけど、それは以前紹介した「この「聞く技術」で道は開ける」とか「3分間コーチ」とか読むとよいと思う。

ちなみに、「質問があったらいつでもしてください」は「質問がなければ声をかけるな」というメッセージも伝わってしまうので、ぼくは意識的に避けるようにしてます。

追記。5秒でわかるまとめ。

この記事から。

最近、携帯の端末IDとセキュリティの話を考えていた。

そして、今まったく別のことを調べていて偶然見つけた結城浩さんの固有 ID のシンプル・シナリオがおもしろかった。特に Q&A の項はおもしろい。

日付を確認すると、2003 年に書かれたものなんですね。

あわせて読みたい。

• http://takagi-hiromitsu.jp/diary/20080710.html
• http://takagi-hiromitsu.jp/diary/20080722.html

5周年おめでとう！＆クーポンありがとう。

年末までに何買うか決めないと。このチャンスにまとめ買いかなー。

今もよくお世話になっていますが、Ruby を使い始めて以来、るびまに育てられたと言っても過言ではないくらい、いろいろな記事を繰り返し読んできました。

Ruby に関するまとまった文章としては、リファレンスマニュアルに継いで世話になった回数が多いのは間違いありません。

ささださんの

るびまを続けていきたい人、何かやってみませんか？

via Rubyist Magazine 4周年に寄せて

の言葉もありますし、次回以降も何かしら関わることができたらいいなと思います。

そこで、こんなんを追加してみる。

class String
  def -@
    Pathname.new self
  end
end

-'/path/to/somewhere' # => #<Pathname:/path/to/somewhere>

-'/'+'home'+'myacount' # => #<Pathname:/home/myacount>

これは、ちょっと本気でいいかもしれない。

前にもより前衛的な（というか、お遊びの）ものを挙げたことがあって、コードとしてはおもしろかったんだけど、実際に使えるようなもんじゃなかった。でも、今度のは一度実際に使ってみようかなと思える。

ちなみに、アイデアの9割は authorNari さんのこのエントリのおかげです。ほんと、こんなのあったんかいw でした。

まず、絶対設計というのは造語で、「設計というのは完成された姿があり、それは静的に写しとれる。」という信条を指す。設計書作成をプログラミングに先行して行おうとするのなどは絶対設計。

でもプログラミングというのは設計プロセスだし、より良い設計というのはそのときの置かれた状況により動的に変わるし、他の設計と比べてこの条件だとどっちが良い？っていうような相対的なものなので、すべてを見通して静的な完璧な設計を作って設計書を作るというのは不可能。(この辺、当たり前のように XP やリファクタリングや TDD やを正しい方向性としているので、ここが食い違うとこの後の問題意識や考えも食い違う。あしからず。)

でも、不可能だということと、する必要がないというのはまた別の話で、どんなケースでもソフトウェア開発は「いやー、そんなん書いてみなきゃわからんですよ」というのが許されるかというとそうもいかない。

で、「そうもいかない」のはどんなときなのかってのを考えると、「計画」が求められているときなんだよね。たとえば、「ターゲットの日付が先に決まっている」というのは計画をすることが必須になる要件だし、単に「上司がスケジュールを出せと言っている」でもいい。

この辺からかなり話があやしくなってくるわけだけど、この「計画」への対処は二つあって、

• 計画がいらなくなるように環境を変える
• 計画ができるように方法を変える

続く。

Web だけをやってきた人は MFC とか通ってないから、Document-View アーキテクチャとか知らない人もいて、そうすると HTML テンプレートと View って何が違うの？みたいな話になってしまうのか。

まぁ、ひたすら VB で開発してました、みたいな場合も Model を抽象化するというのは想像つかず、画面から DB 呼び出してルールも画面に書いて、という人もいるので、最終的にはその人次第となってしまうのだけど。

結論としては、『観察されるデータの複製』とか載っている「リファクタリング」はよい本だなぁ。ということでした。

http://www.ruby-lang.org/ja/documentation/repository-guide

に従い、

$ svn co http://svn.ruby-lang.org/repos/ruby/trunk ruby

してダウンロード。

configure がない

./configure しようと思ったら、configure がない。仕方ないから autoconf しようと思ったら、autoconf が未導入だった。

yum install autoconf 

してみたところ、準備されているパッケージでは ruby 1.9 で必要な autoconf のバージョンを満たしていない。(CentOS4)

autoconf のダウンロード

http://www.gnu.org/software/autoconf/ へ行き、http://ftp.gnu.org/gnu/autoconf/ から http://ftp.gnu.org/gnu/autoconf/autoconf-2.62.tar.gz をダウンロード。

wget http://ftp.gnu.org/gnu/autoconf/autoconf-2.62.tar.gz
tar zxvf autoconf-2.62.tar.gz
cd autoconf-2.62.tar.gz
./configure

エラー。。

今度は、GNU M4 のバージョンが足りないらしい。

GNU M4 のインストール

http://www.gnu.org/software/m4/m4.html へ行き、http://ftp.gnu.org/gnu/m4/ から http://ftp.gnu.org/gnu/m4/m4-1.4.11.tar.gz をダウンロード。

wget http://ftp.gnu.org/gnu/m4/m4-1.4.11.tar.gz
tar zxvf m4-1.4.11.tar.gz
cd m4-1.4.11
./configure
make
make install

autoconf のインストール

./configure
make
make install

configure の生成

co した ruby ディレクトリへ移動

autoconf

ruby のコンパイル

./configure --prefix=/usr/local/ruby19
make

コマンド bison なんて知らないらしい。。

bison のインストール

yum install bison

今度こそ ruby のインストール

make
make install

無事インストール完了。お疲れさまでした。

初めてのRuby

posted with amazlet at 08.09.10

Yugui
オライリージャパン
売り上げランキング: 2708

おすすめ度の平均:

要点がコンパクトにまとまっています。(中級者以上向け）

Amazon.co.jp で詳細を見る

詳しくはまた別に書きたいが、想像以上に本当にすばらしい内容の本だった。

誤解を恐れずに言ってしまうと、RAILS OF RUBY ON RAILS は Rails2.x 世代の最高のチュートリアルだと思う。これから Rails について知りたい人は、Web で一生懸命に Rails 情報を探すよりも、まずこの本を買って読んでみるほうがいい。

読むだけなら短時間で内容に目を通せるのもチュートリアル的だ。教科書としてではなくチュートリアルとして買うのであれば、（同じくショッピングカートを作っている）「RailsによるアジャイルWebアプリケーション開発」と比べてもぼくはこちらを推す。

チュートリアルと呼んでしまうと内容が薄そうに聞こえるが、この本のすごいところはチュートリアルとしての進め方をしながら、その実要所要所で必要となる Rais の機能についてはきっちり説明がされているところだ。

もちろん、説明されていないことはたくさんある。説明されていることだって、説明の内容が深いかと言うとそんなことはない。でも、ここから後は必要に応じて自分でリファレンス読んだり、別の本を買ったり、Web で検索したりして調べることができる。

他にもいろいろな点で感動したのだが、とりあえずここまで。（あ、純粋に技術書として買うとここまでの評価にはならないかもしれません。でも、そういう需要には達人プログラマー+DHH+前田修吾さんが応えてくれるので問題ないでしょう。）

Rails of Ruby on Rails ~Case of LOCUSANDWONDERS.COM~

posted with amazlet at 08.07.24

Plan de Sens 清水 智雄
毎日コミュニケーションズ
売り上げランキング: 43091

Amazon.co.jp で詳細を見る

だけど、こういうものを捉えるときのアプローチとしては、「もし、後々これが大きなターニングポイントになるとしたら、何をもってターニングポイントになりうるのか？」という視点で検討したほうがいいのではないか。と思ったのだ。

その脅威が実現する可能性についてはまた別途検討すればいい。結果として何でもない単なるおもしろインターネット端末でした、という結論なら安心してスルーするか、祭りを楽しめばいい。

ただ、検討もしないで「あれがない」「これがない」と現在あるものとの比較でないもの探しをしていると、大きな流れを見失う恐れがある。（実際に買った人から「Safari 落ちすぎ！」みたいな声も挙がっているのはひとまず横に置いておく。）

ということで、ざっくりとだが自分でいろいろ読んでみた。

以前に shi3z さんのこのエントリを読んで「ほー」と思った覚えはあったので、 Push Notification Service が iPhone のキーコンセプトだということを取っ掛かりに調べ始めた。（ちなみに「ポジショントーク」というはてブコメの指摘はたしかになー。とも思った。）

ケータイコンテンツの最大の特徴とは、ユーザ側から働きかけるのではなく、サービス側から働きかけることによってユーザの行動そのものを動的に変えて行くということです。

そうだよなぁ。ケータイであるということは、つまりユーザーが常時携帯し、どこにいてもいつでも手元に置いているということだ。つまり、（PC の前でできることだけではなくて）あらゆるユーザーの行動に働きかけをし続けることができるという可能性を秘めているわけだ。今ユーザーが何をしているか、何を欲しているかを生活の隅々まで追って、その瞬間にほしいものを提供するということができるとしたら、それは携帯端末だけだ。 （ケータイは携帯電話であるので、こう文章にすると文字通りの当たり前のことなんだけど。）

続いて、blog.Winding-life.net さんのなぜはてブが３つしか付いていないのかまったく理解できないすばらしいエントリ。これは全員が読むべき。説明も非常にわかりやすく、その洞察も納得がいきやすい。

とにかく重要なのは、サードパーパーティのアプリに対して「着信機能」をシステムレベルで開放してくれるってこと。 ここから広がる可能性は今までの携帯電話とは比較にならないと思うんだけど。

そして、

でもこの仕組みの一番のえげつなさは、音声通話とパケット通信以外のサービスをキャリアに関係なく自分で実装できちゃうっていうこと。今までは「着信機能」を持てないがためにキャリアでしか実装ができなかったものも自分たちで実装できるようになる。要するに「お前らはちゃんとデータを流しさえしてりゃいいんだよ」とキャリア各社に申しておるわけですよ、Appleは。

はい。これだけしか引用しません。ぜひ全文読んでください。

次は、米国の CNET から。

For the better part of a year, users with jailbroken iPhones have been enjoying apps that run the traditional way (in the background), even when the device is in sleep mode. Jailbroken apps like Mobile Chat and Intelliborn's Intelliscreen (hands-on) run quietly, pulling in data every few minutes and popping up with a message the way Apple's own apps behave. The problem is that this model doesn't scale.

iPhone は(jailbreak することで)従来型の（バックグラウンドプロセスによるプル型の）仕組みを実装することもできる。ただし、この仕組みはスケールをしない。という指摘。携帯デバイスという特性上、複数のクライアントアプリケーションがバックグラウンドプロセスで動作し続けるというモデルは非効率であり、その解として Push Notification Service が出てきている。と解説している。

This new tunnel for data is a veritable gold mine that's not just metrics--it's attached to user IDs and billing information too.

さらに、この Push Notification Service という新しいユーザー接点（データをユーザーへ届けるパイプ）は、ユーザー ID でユーザーを個別に識別可能であり、決済機能とも結び付いている。

個別の端末について IP を握っており、それがユーザー ID と過去の様々な通信活動の履歴と結び付いているという状況を思い浮かべると、Apple の優位性がはっきりと見えてくる。そして、意外にもそれは DoCoMo が握っていた優位性とも似ている部分がある。DoCoMo は独裁者としては優しかったのかもしれない。Apple はそれほど甘い顔を続けないだろう。

国内の情報に戻って、WWDC2008 の基調講演を丁寧にまとめた記事へ。上記を踏まえて読み返すと、その構成や文句についていろいろ考えさせられるものがある。（わざわざ検索して読み返さんでも、すべて WWDC2008 で言われてるじゃん！自分どれだけ鈍いんだ！的なものも含めて。）

たとえば、この辺は見える景色が違ってくるのではないだろうか。

3番目は、looptのSam Altman氏は、iPhoneのCore Location APIを使って、自分の周囲にいる友達を表示してくれるアプリケーションを紹介。利用者は自分の居場所についてコメントを残したり、友達にメッセージを残したりできるという。

Altman氏は「これまでは終わってから、実は友達が近くのレストランにいたということが分かったりした」「looptを使えば2度とさびしく一人で食事をすることはなくなる」と語った。このソフトはApp Storeにて無料で配布される。

で、なんだかんだでこうして見てくると、Apple は最近の Web の流れとして明らかに見えていた「テキストベースじゃない Web の世界」で勝とうとしているのだということに気付く。iPhone が提示しているアプリケーションとそのインフラとして働くデータとサービスの集合があり、Web と呼ばれたものはその基盤を担っていくという未来を Apple は描いているし、iTMS から着々と実現に向けて駒を進めている。（別にこれは新しい話でもなく、Adobe も MS もそれに向けた手を打っていた。ただ、その概念がソフトウェアとその開発環境という枠組みを出なかっただけだ。）

最後にこれは Apple によるロックインだ！という当然挙がるであろう声も紹介しておく。

この記事の中では、バックグラウンドプロセスを採用せず、Push Notification Service を採用したことによる問題をいくつか提起している。一番気になる点はやはり必ず Apple を介さないといけない仕組みになっている点だろう。それを利用して Apple の一人勝ちモデルとしていくのか、それともそこを共存共栄の仕組みへと進めていくのか。

この Apple が Push Notification Service の根っこをがっつり握っているよ、という話で思い出すのは、fladdict さんの「バイパス」の話。まさにバイパス以外の何物でもないものを出してきたという印象だ。

この機会に fladdict さんの一連の Apple 関連エントリも読まれることをおすすめする。

• 2005.04.06 アップルの本質は「あちら側」ではないのか？
• 2007.01.14 iPhoneは携帯でも音楽プレイヤーでもないし、Appleは家電屋じゃあない
• 2008.01.29 みんながパソコンから逃げ出してる

それにしても、なんだか、こういう内容でブログを書くのはとてもひさしぶりな気がするな。

#!ruby -Ku
X = []
def method_missing name, *args
  puts "ひだまりスケッチ×365 " + args.to_s if name == :<
end
X / _ / X < :来週も見てくださいね!

method_missing 万能すぎちゃってあまりおもしろくないな。

で、肝心のBDDですが、これは確かに実績を上げてました。RSpecとSeleniumを使うようになって格段にバグも減ったし、「何をやってるか知りたければまずSpecを見ろ」っていう習慣も自然に浸透したし、LLに不慣れなベテランプログラマや新人プログラマを含む混成部隊でもペアプロのお陰で開発速度を維持できたし全体の技術水準も上がりました。

あと余談だけど、「Specのないコードを書くときは上長に申請書を提出させる」とか「ペアプロ時にはナビゲータはピコピコハンマー装備」とか、今回の名言「わかんないやつは黙ってろ」とか、本当にやっちゃう人ですからねyuguiさんは。実際に。そこに痺れる憧れる。

via RubyKaigi 2008に行ってきた

以上、個人的なメモ。

最近、自分でコードを書くときはよほど小さなツールでないかぎり、ほとんど BDD で開発している。BDD の体感的の感覚としては、森博嗣氏のこの話が近いと思う。

「どうしても、思いどおりに小説が書けません。どうしたら、良いでしょうか？」と尋ねられることも少なくないのだが、そういうときは、「思いどおりに書けなかった小説を見せて下さい。何作くらいあるんですか？」ときき返す。１作も書けていない人が多い。１作も書いてないのに、どうして思いどおり書けないなんて言うのだろうか？　書いてから悩めば良いではないか。書けない書けないと悩む人がいるけれど、書けないなんてことはない、なにかは必ず書ける。幼稚園児だって書ける。100時間も1000時間も悩めば、必ず書けるだろう。５作くらい書けば、自分の才能が小説に向いているか向いていないか、多少はわかるのではないか。

(略)

沢山の具体案を考えることは、無駄なようでけっして無駄ではない。採用されなかった案が、その人の将来の持ち駒になるからだ。

via MORI LOG ACADEMY

つくづく、よくできたやり方だと思う。

KaigiFreaks の方々とレポをしてくださった皆様、そして実行委員の皆様に感謝。特に KaigiFreaks は LT 見て、あらためて感謝です。札幌から自費で参加って！おかげさまで、自宅からも楽しめました。どうもありがとうございました。

そして、共通タグらしいので rubykaigi2008 タグ付けてみた。livedoor blog のタグ機能なんて初めて使ったよw