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

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

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

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

via http://www.jitu.org/~tko/cgi-bin/bakagaiku.rb?bakaid=200811171

これは同意。

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

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

だから、そういう意味ではミスした人がはっきりする状況というのは別に『問題 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分間コーチ」とか読むとよいと思う。

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

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

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

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

あわせて読みたい。

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

pragprog.com から 20%OFF のクーポン届いてた！

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

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

るびまにレポートを寄稿。感無量です。

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

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

ささださんの

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

via Rubyist Magazine 4周年に寄せて

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

一度使うと手放せない便利クラス Pathname なんですが、Pathname.new するのが面倒だったりする。字面が長いから。

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

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 やを正しい方向性としているので、ここが食い違うとこの後の問題意識や考えも食い違う。あしからず。)

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

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

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

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

続く。

「MVC の V って何するの？」「いらないんじゃない？」という話を聞いて、なぜ View の価値が理解できないのか不思議だったんだけど、なんとなくわかった気がする。

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

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

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

東京 Ruby 会議の yugui さんのセッションを聞いて、svn head の 1.9 系を使ってみたくなったので、

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 で詳細を見る