2005 6 7 8 9 10 11 12
2006 1 2 3 4 5 6 7 8 9 10 11 12
2007 1 2 3 4 5 6 7 8 9 10 11 12
2008 1 2 3 4 5 6 7 8 9 10 11 12
2009 1 2 3 4 5 6 7 8 9 10 11 12
2010 1 2 3 4 5 6 7 8 9 10 11 12
2011 1 2 3 4 5 6 7 8 9 10 11 12
2012 1 2 3 4 5 6 7 8 9 10 11 12
2013 1 2 3 4 5 6 7 8 9 10 11 12
2014 1 2 3 4 5 6 7 8 9 10 11 12
2015 1 2 3 4 5 6 7 8 9 10 11 12
2016 1 2 3 4 5 6 7 8 9 10 11 12
2017 1 2 3 4 5 6 7 8 9 10 11 12

ホーム

2006年07月30日

http://radar.oreilly.com/archives/2006/07/state_of_the_computer_book_mar_4.html

みんなちゃんとチェックしてる?

ちなみに前回のがこれ:

http://radar.oreilly.com/archives/2006/04/state_of_the_computer_book_mar_3.html

C/C++はやっぱり落ち目で安定なのかなぁ。
自分的にはC++復活しつつあるような気がしてたんだけど。
やっぱ厳しいのかなぁ。

C#がデカイんだろうねぇ。WinといえばC++だったわけで、
そういう人たちがゴッソリC#に乗り換えてるんじゃないかな。
その気持ちはすごくわかるけど。

Monoの時代が来るかなぁ。正直わかんないよね。Linuxとかも
含めて、オープン・ソース全体でちょっと弱気になってる
気がしないでもないし。ま、サーバ・サイドは全然アレだけど。

結論としては、Windowsプログラマなら、VBとC#とSQL Serverの
3つをおさえて、それにC++あたりがチョロッとできれば
食いっぱぐれることはないガチガチの鉄板。
ってことなんだけど、オレには関係ねぇしなぁ (笑)。

agile全体は上がり目だけど、XPとかリファクタリングとかは
ちょっと落ち目なのか。まぁ、そんなもんだろ。ある意味、
XPの役割は終わったともいえる。重量級から目線を外すっていう。
one of themになったわけだけど、それでも今後開発プロセスを
語るときにXPを避けて通ることができなくなったのは事実だろ。
それに、XPだってまだ終わったわけじゃないしね。

--

ああ、すんません。間違いってわけじゃないんですけど、
やっぱり間違い。

rake.htmlのrake-4.rakeの中で:

#!/usr/bin/env rake

task :default => "hello"

task "hello" => ["hello.o", "main.o"] do |t|
  sh "gcc -o #{t.name} #{t.prerequisites.join(' ')}"
end

task "hello.o" do |t|
  sh "gcc -c -o #{t.name} hello.c"
end

task "main.o" do |t|
  sh "gcc -c -o #{t.name} main.c"
end

なんてやってたんですけど、こんな長ったらしいこと
書かなくっていい。ほんとは:

#!/usr/bin/env rake

task :default => "hello"

task "hello" => ["hello.o", "main.o"] do |t|
  sh "gcc -o #{t} #{t.prerequisites}"
end

task "hello.o" do |t|
  sh "gcc -c -o #{t} hello.c"
end

task "main.o" do |t|
  sh "gcc -c -o #{t} main.c"
end

って書けばオケ。Taskオブジェクトにしろ、その
prerequisitesにしろ、適切に文字列展開されるから。

公開してるのはぜんぶ直しときました。

本家Permlink


2006年07月29日1

http://www.javaworld.jp/event/agile2006/index.html

メールありがとうございます。

``Agiter SOFTWARE''って耳慣れないとこですね。
K.Beck氏が``Agiter Fellow''という形で参加してる
みたいですけど。

う〜ん、悩む。悩むとこではあるんですけど、今回は
見送りということで。わざわざお知らせいただいたのに
申し訳ありません。英語聞いてもわかんないし (笑)。

いや、それでK.Beck原理主義者と名乗るのはどうかと
自分でも思いますけど (笑)。

(ちょと早く次のに行きすぎた気がしたので再掲)

--

いや、なんでそこまでしてその会社にこだわるのかよく
わからん。身体が壊れるほど残業させられるっていう
時点で、そんな会社に希望なんかあるわけない。
フツーはもっと早く気づくもんだけど。

オレたちは何者だ? 会社員である前に技術者だろ?
技術者っていうのは腕一本だろ?
ダメな会社にこだわる理由なんかどこにあんの?

本家Permlink


2006年07月29日

#!/usr/bin/env ruby

class Argv
  def initialize(argv)
    @argv = argv
  end
  attr_reader :argv

  def spawn(inpipe, outpipe)
    pid = Process.fork
    return pid if pid
    join_pipe(inpipe, outpipe)
    exec
  end

  def join_pipe(inpipe, outpipe)
    inpipe.reopen_stdin
    inpipe.close_out
    outpipe.close_in
    outpipe.reopen_stdout
  end

  def exec
    return unless @argv
    Kernel.exec(*@argv)
    exit(1)
  end
end

class Pipe
  def initialize(input=nil, output=nil)
    @in = input
    @out = output
  end
  attr_accessor :in, :out

  def reopen_stdin
    $stdin.reopen(@in) if @in
  end

  def reopen_stdout
    $stdout.reopen(@out) if @out
  end

  def close
    close_in
    close_out
  end

  def close_in
    @in.close if @in
  end

  def close_out
    @out.close if @out
  end
end

def each3(array)  # block
  return if array.size < 3
  (array.size - 2).times do |i|
    yield array[i], array[i + 1], array[i + 2]
  end
end

def exec_commands(commands)
  argvs = commands.map{|argv| Argv.new(argv)}
  argvs.unshift(nil)
  argvs << nil
  return exec_argvs(argvs)
end

def exec_argvs(argvs)
  return 0 if argvs.size < 2
  pids = []
  inpipe = Pipe.new
  outpipe = Pipe.new
  each3(argvs) do |first, second, third|
    outpipe = Pipe.new(*IO.pipe) if third
    pids << second.spawn(inpipe, outpipe)
    inpipe.close
    inpipe = outpipe
    outpipe = Pipe.new
  end
  status = 0
  pids.each{|pid| pid, status = Process.waitpid2(pid)}
  return status
end

commands = [
  %w[echo 1],
  './inc.rb',
  './inc.rb',
  './inc.rb',
  './inc.rb',
]
exec_commands(commands)

やりすぎという気がしないでもない。

ちなみに、inc.rbっていうのは:

#!/usr/bin/env ruby

puts($stdin.gets.to_i + 1)

--

さっきの話の続きだけど。

あれが現実的じゃないっていうのは、もう1つ理由がある。
1テラ歩譲ってITプランニングなるものが大切だとしよう。
で、じゃあ、どうする? どう変える? 組織をどう変える?

そういうことが大事だろ? 理想や目標を設定したとして、
それにどう近づくかっていうことを具体的に考えないと
ダメじゃん。それが現実的ってもんだろ?

人はそうそう変わるもんじゃない。その人が集まってる
組織というものはもっと変わるもんじゃない。そこへ
もっていきなり『念入りなITプランニングやりましょう!』
って・・・バカだろ? できるわけねぇっつの。
そういうことを抜きにして『ITプランニングは大事です!』
ってのはただのプロパガンダだろ?

XPにしたってそうなんだよ。いきなりぜんぶ理解して、
ぜんぶ実践できるなんてことは絶対ない。
だから、簡単に実践できそうなものからやってくんだし、
ちょっとずつ理解を深めていくんだろ。ほんとの理解
っていうのは経験に裏打ちされたものなんだし。

これは裏を返せば、プロセスの向上に終わりはない
っていうこと。1歩階段上がったら、また新しい階段が
目の前に現れる。いつか振り返ったら、ずい分高い
とこまで来たことに気づくかもしんない。でも、また
前を見れば、まだ階段は続いてる。それに、自分が
組織を移ったら、また最初っから階段登るハメになるかも
しんない。

銀の弾丸なんてどこにもないってことになぜまだ気づかないんだ?

本家Permlink


2006年07月28日

http://www.javaworld.jp/event/agile2006/index.html

メールありがとうございます。

``Agiter SOFTWARE''って耳慣れないとこですね。
K.Beck氏が``Agiter Fellow''という形で参加してる
みたいですけど。

う〜ん、悩む。悩むとこではあるんですけど、今回は
見送りということで。わざわざお知らせいただいたのに
申し訳ありません。英語聞いてもわかんないし (笑)。

いや、それでK.Beck原理主義者と名乗るのはどうかと
自分でも思いますけど (笑)。

--

コラーッ!

bakaidの一番古いのは20050620!

それより前のはない!

pre.htmlのときはほんとに書き捨てだったんだから!
オレだってバックアップ取ってなかったんだから!

--

http://opentechpress.jp/article.pl?sid=06/07/28/0246223

なんでこういうのにYendotともあろうものがリンク
張るのかよくわからん。

だって、これ読んでどう思うよ? 現実的か?
お題目はリッパだけどよ。とてもpragmaticとはいえねぇ
じゃん?

ハッカーはすべからくpragmaticであるべきで、その
ハッカーがやってるYendotとして、これはどうなのよ?

何度も書いてる気がするけど、計画することは大事だ。
勘違いするんじゃないよ? 『計画』はそれほど大事
じゃなくって、『計画する』ことが大事なんだよ。つまり、
計画というのは何度も修正されるものなんだということ。

  堅実なプランニングがなぜITアプリケーションプロジェクト開発で成果を上
  げるかといえば、一番の理由は、プロジェクトに関連する問題点、手法、選
  択肢が入念に検討されることだ。最善のソリューションが必ずしもプランニ
  ング工程で生まれるとは限らないが、主要な選択肢を検討し、最も適切なも
  のを選択したという確信は得られる。

これって要は前払いでしょ? そんなことに時間を
かけるんじゃないって何度も書いてるじゃん。
とにかく走りだしてから、計画を修正していくことが
大事なわけじゃん?

だって考えればすぐわかるじゃん。
走りだしたほうがフィードバックが得られるんだから、
計画が現実に合ったものになりやすいじゃん。

時間かけたら最善なものが得られる? そうか? ほんとに
そうか? バカいうなよ。時間かけたらまた新しい
選択肢が増えるだけじゃん。

だったら走りだして、計画を頻繁に修正するほうが
柔軟じゃん? 変化に対応できるじゃん?
ソフトウェアならそれができるじゃん?

昨日のトヨタの話じゃないけど、10年とかそういう
単位で同じものを使い続けるんなら前払いでもいい
だろうけど。
でも、そんなノンビリで勝てるの? 生き残れるの?

なんだ? ハッカーっていうのはビジネスの話になると
頭が硬直するのか? そうじゃねぇだろ? 自分が
ハッカーだっていうことに誇りを持ってんなら、
そのハッカーのやり方をビジネスにも適用しようと
しなきゃダメじゃん? それがP.Graham氏のいってる
ことじゃん? それがGoogleがやろうとしてる
ことじゃん? わかってんの?

ああ、オレはハッカーになることはあきらめたからさ。

本家Permlink


2006年07月27日

http://itpro.nikkeibp.co.jp/article/OPINION/20060724/244158/

いや、これで若手の教育には成功するでしょうけどね。
それが目的なら、こういうやり方もアリでしょうけど。

  ●事前準備に金をかける
    ・・・
  ●データベースを念入りに設計
    ・・・
  ●土台となるコンピュータやソフトウエアは10年以上使う
    ・・・
  ●いかなることがあってもプロジェクトの期限を守る
    ・・・

  これらは,いずれも情報化に関する基本中の基本である。

バカですか? ここで基本中の基本といえるのは
プロジェクトの期限を守ることくらい。でも、それが
どういうことか理解してる? プロジェクトの期限を
守るということは、当初の計画を曲げるということ。
だって、そうでしょ? 実装できてない機能を落とさないと
期限に間に合わないんだから。

上のような事柄が基本といえたのは、10年以上前の話でしょ。
状況が変われば基本も変わるということ。少なくともXPでは、
上の4つのうち3つは否定されてるわけで。

agileはトヨタ生産方式に大きく影響を受けている。
その元祖のトヨタがこれじゃあな。
大野さんが知ったら泣くぜ、トヨタさんよ。

--

http://www.nikkei.co.jp/news/keizai/20060724AT3S2001923072006.html

バカですか?

--

仕事がらみで学ぶ言語は常に嫌いになるという法則。

自分の場合はPHPくらいしかないんだけど。

--

リーチは日本生まれの役だったような。

--

[1,2,3].inject(nil) do |result, item|
  next item unless result
  p [result, item]
  item
end

おお、nextで値を返す(?)なんてはじめて使った。

これで得られる出力は:

[1, 2]
[2, 3]

となる。

--

ああ、これですか。

http://www.scissor.com/resources/teamroom/indexjaJP-utf8.html

これは良くいって誤解を生むだけで、悪くいっても
誤解を生むだけじゃないですかね。

こういうとこで自分は仕事をしたいとは思いません。
大部屋結構。ガヤガヤ結構。それが日本の事情という
ものでしょう。そういう劣悪な環境でどうやって
XPやるかっていうのを、日本のXPerは考えなきゃ
いけないんですよ。マジで。建物事情なんて
どうにもなんないことのほうが多いんだから。

いったよ。『どうにかなりませんか?』って。
いったけど返事は『どうにもなりません』だったから (笑)。
それ以上どうにもできねぇじゃん。

だいたいよー、キャスター付きの引き出し机とか
使うか? 使わねーだろ、フツー。ペア・
プログラミングのジャマにしかなんねーのに。
ほんとバカが多いっつーか。捨てたいんだけどさ。
捨てらんねぇじゃん。客の持ち物なんだし (笑)。

だから、優雅にXPやろうとかバカなこと考えねぇでさ。
もっと泥にまみれてXPやろうや、な。

本家Permlink


2006年07月25日

http://weathernews.jp/

一部でWeb 2.0とFlashの関連とか盛り上がってる
みたいですけど。

上みたいなページ見ると、Flashやっぱダメじゃん?
って思っちゃいますね。戻るボタン利かないとか、
URLを共有できないとか、Web 2.0っぽくないとこが
たくさんある。こういうのは結構大事で、Webの
メタファーに則ってないのはやっぱダメでしょう。
YouTubeにしても、URL張れるところが人気なわけで。
画面遷移をFlashの中だけで済ませるのはやっぱダメ。

もちろん、これはFlashの使い方がまずいだけで、
これで即「FlashはWeb 2.0じゃ使えない」ってことには
なりませんけど、そんなに楽観はできないですよね。

本家Permlink


2006年07月24日

正直いえば、自分も工業製品製造のメタファーっていうのは、
あんまり好きじゃないんです。

まぁ、日産の工場で期間工として働いていたことが
トラウマになってんのかもしれまんけど (笑)。

コンベアでスポット打ったりとかはともかく、セル
生産方式にしても、失礼ながら、あんまりやりたい
とは思いませんしね。これは単なる偏見でしょうけど。

自分がよくいう『ordinary』っていうのは、あくまでも
ソフトウェア開発におけるordinaryであって、それは
工業製品製造のordinaryとは違うんじゃないかって、
そう思ってます。もちろん、願望を込めてね。

だから、プログラマは上流から下流まで面倒を見るべき
ですし、ビジネスにも積極的に関わるべきだと。
ソフトウェア開発ならば、それができるはずだと。

もちろん、ビジネスの大きさによっては、ビジネスの
末端に位置するようなことはあるでしょう。でも、
その末端なら末端であっても、上から下まで面倒を見て、
そしてその末端のビジネスに積極的に貢献すべきだと。

でも、工業製品製造と変わらないordinaryさっていうのは、
あるはずで。それが『お客さんの立場になって作る』って
いう、ほんとにごく平凡なこと。自分が今作っているもの、
それがお客さんにどう喜ばれるか、どう作れば喜ばれるか、
そういうことを考えるのが、常に変わらないordinaryさ
なんじゃないかと思うわけです。

--

それと、近代から現代まで、日本っていうのは、
チープ革命の尖兵だったわけです。ならば、そこで
開き直るのもアリかなと。何もGoogleやMSみたく
大金持ちになるのばかりが革命じゃないでしょう。

本家Permlink


2006年07月23日

http://www.youtube.com/watch?v=1o9dxtFdQ_Y

へー、これ乗ってたのか。史上最短の世界戦。

--

http://www.youtube.com/watch?v=13B_NKF4PbU

誰このヤッさん?

クレイジー・キム検索して引っかかったんだけど、
クレイジーケンバンドの人?

本家Permlink


2006年07月22日

Firefoxが最近クソ重くなってるような気がするのは
気のせい?

軽くするためにMozillaから分岐したのに、また
重くなってるんじゃ、意味ない。

本家Permlink


2006年07月21日

くくくはbashでもいけるみたい。

--

ebanさんとこで教えてもらったelectric-buffer-list
なんですけど、Meadowだとバッファ名切り詰めちゃう。
『バカ?』っていいたくなるくらいの挙動なんですけど、
また何か自分が勘違いしてますか? 20文字くらいで
切り詰められちゃうから、*.hと*.cppの区別がつかない (笑)。

ちなみに、C-,とかC-.で切り替えるのも
試してるんですけど、あんまり便利じゃないかも。

--

ああ、『Rubyスクリプトはすべてが実行文』っていう
言い方でいいのかな? 『実行文』っていうのは、
『インタプリタが解釈実行する文』っていう意味なんだけど。
だから、関数を呼び出すときは、その関数が前に定義されて
いないとダメ。だから、下のはエラーになる:

doit

def doit
  p true
end

一方で、定義も実行文なんだけど、それは『定義すること』を
実行するだけで、その『定義の中身』はすぐに実行されるわけ
じゃないから、まだ定義されてない名前を使うことができる:

def doit
  dothat
end

def dothat
  p true
end

doit

そういう意味で、Rubyっていうのは古風なインタプリタ。
バイトコンパイルとかしないし (まつもとさんはよく
『いや、内部的にはコンパイルしてる』っていうんだけど)。
ああ、これはruby 1.Xの話ね。
宣言の類がないのは、まつもとさんが狙ってやってることだし。

--

オレだって q! 知ってるんだから、C-x C-c くらい覚えてよ (笑)。

--

穴があったら挿れる、それが男というものだ。
つまり:

public void manDo(Woman obj) {
  insertTo(obj);
}

よりも:

def man_do(obj)
  return unless obj.respond_to?('have_hole?')
  insert_to(obj)
end

のほうが男らしいといえる。すなわち、DuckTypingは男道なり。

--

いやいや、それはミスリーディングというものだ。
穴だったら何でも挿れたがるのはただのガキだ。
オトナの男はインタフェースを使うのだ:

public void manDo(Insertable obj) {
  insertTo(obj);
}

すなわち、インタフェースは『オトナの階段』なり、だ。

本家Permlink


2006年07月19日


本家Permlink


2006年07月18日

http://itpro.nikkeibp.co.jp/article/OPINION/20060706/242719/

  Googleが東京オフィスを開設した時,食事やリクリエーション設備,マッサー
  ジルームといった,技術者に対する手厚い福利厚生が話題になった。そういっ
  た面ももちろん大事だが,Googleの「居心地の良さ」とは,何よりも優秀な
  技術者集団から得られる刺激や,社会で話題となるサービスを手がけている
  という「やりがい」から形成されているはずだ。

そう、『やりがい』の大切さはGoogleも自分らも
変わらないはずです。

でも、この文中にあるように、その『やりがい』と
いうのは、福利厚生からもたらされるものじゃない
でしょう。

日本的な技術者の『やりがい』というのは、そう、
たとえれば『作業ジャンパー』です。まぁ、個人的に
作業ジャンパーが好きだっていうのがあるんですけど (笑)。

何度も書いてますけど、自分はordinary powerでGoogleを
超えたいと願っています。そのordinaryの象徴として
作業ジャンパーがあります (笑)。

作業ジャンパーを着て作業することに誇りを感じること。
そういうordinaryさがほしい。ひたむきに製品の品質を
上げる。定時が来たら帰宅する。でも、がんばるときは
がんばる。そんなordinaryな人たちとGoogleを超えたい
と願っています。

何度もいいますけど、自分は本気ですよ? しかし、
どいつもこいつもGoogle礼賛か、敵視しててもGoogleと
おなし方法論でGoogleを超えようとしてるしな。
つまんねー。

--

あれ? JVMってOOPに特化してたんじゃなかった?
クラスとか扱えなかった? そのせいでイマイチ汎用の
仮想機械になり切れてないって思ってたけど?

--

いや、それはイヤっていうほどいわれてましたし、
実際に試されたやり方なんです。でもダメだったんです。
だから、変化を受け入れながら開発するXPが
生まれたんです。

また逆をいえば、ソフトウェアほど柔軟な創造物、
製造物はなかなかないわけで、その長所を活かすためにも、
変化を受け入れながら開発するのがいいんです。

--

class MyObject
  include Enumerable
end

class YourObject
end

YourObject.new.extend(Enumerable)

モジュールは中出し。
オブジェクトは外出し。
外出しのほうがちょっと安心なんだけど、
でもやっぱりどっちも危いんだよ。

だからね、ほんとはね:

class HisObject
  def initialize(her)
    @her = her
  end
end

みたくするといいんだよ。
・・・
もうお母さんがいなくなってずいぶん経つなぁ。
お前も大きくなったんだし、そろそろほんとのことを
いっておこう。
実は、お前はパパの娘じゃ・・・

--

なんだ。アイフルアイフルゆーからアイフルに聞けば
いいじゃん、って思ったら準備中だった。ガッカリ。

--

発想を変えてみようじゃないか。

オレたちは、今の3倍売りたいわけだ。
なぜなら、ライバルの売上がオレたちの3倍だからだ。

では、3倍売り上げるために今の顧客を切らなきゃ
いけないとしたら?

それでも当初からは2倍売れることになる。

1 * 3 - 1 = 2

簡単な算数だ。

何がいいたいか。今の顧客のために新しい顧客を逃すな
ということ。つまり、今の顧客を無視してでも、それで
全体としてユーザ体験が向上できると信じるだけの根拠が
あるなら、それを実現しなきゃダメだ。そして、その
根拠は、それほど明確でなくてもいい。そこで臆病に
なっては3倍など土台無理な話だ。

本家Permlink


2006年07月17日

アア、ゴメンナサイ、ゴメンナサイ。昨晩のうちに
消したつもりだったのに・・・

--

結局、パターンって知恵なのかな?と思わないでも
ない今日このごろです。

もしそうだとすると、パターン集は格言集とかベカラズ
集と大して変わんないのかなとも。

正直いって、自分はパターンに入れ込んでないんですよね。
etoさんの書かれたとおり、XPとパターンが直結してると
しても、どっか煮え切らない感じがあるんです。

なんで煮え切らないかっていうと、やっぱり格言集とか
ベカラズ集はつまんないからなんじゃないですかね。
バラバラな感じで。XPだと、もうちょっとそれぞれの
事柄が結び付いてる感じがあるじゃないですか。

メタっていう言葉は嫌いですし、多分ハズレだと
思うんですけど。パターンを生み出すパターン?
ちょっとバカっぽいでしょ? いや、でも、パターンを
生み出すものを知りたいっていうのはあるんですけど。

--

やっぱりSelf-Similarityが大切な気がしてきました。

Self-Similarityを武道の言葉でいえば、
一を以って万に当たる
っていうことになるんでしょうね。

守破離というのも、スケールのこともいっているのかも
しれません。型の本質を小規模から大規模へと適用して
みるっていう。

だから、パターンというのは、1つの手がかりという
こともできるんじゃないですかね。ある型を見つけたら
おしまいっていうわけじゃなくって、他の型との関連を
調べたり、それがどの規模まで通用するのか試したり。
規模を変えることで、より抽象的な概念が見えてくる。
抽象的な概念は、厄介なんですけど、適用範囲は広い。

たとえばテスト・ファーストなんかも、最初は製品の
品質をいかに高めるかっていう話だったわけです。でも、
そこからTDDに発展すると、プロジェクトやチームの質を
いかに高めるかっていう話が見えてきた。さらに、
そこから生き方というものも見えてくる・・・気がする (笑)。
計画を立てて、目標をはっきりさせて、そうすることで
充実した人生を送るっていう。まぁ、実際にできるかは
ともかく (笑)。

さらにいえば、パターンというのは学習でもあるわけです。
発見、実験、考察、発展・・・みたいな?

本家Permlink


2006年07月16日1

やべー、はぶさんとこからリンク張られてたらしい。
ドット汗出てきた。心当たりがありすぎて恐い (笑)。

--

ああ、irbをUIに使うってのは全然アリなんですね。
特にユーザがプログラマの場合には。

たとえば、アクセスログの解析をするとして。結局、
それってgrepなんだけど、もうちょっと構造的って
いうか、ログ・フォーマットを意識したものになる。
で、引っかけたいとこ、たとえばリファラだったり、
bakaidだったりとかは結構変わったりする。つまり、
何を引っかけたいかはユーザが知ってる。それで
なおかつ、何を出力したいかもユーザが知ってることが
多い。

こうしたとき、コマンド行引数で解決するのは大変だ。

$ aclogrep -url=bakagaiku.rb -output=date,bakaid,referer access.log

みたいな。でも、これだともっと複雑なパターンに対応
するのが大変だ。findみたく-oとか-aとかワケワカラン
事態になる。

なら、irb使って、ユーザが知ってるところはユーザに
書かせるようにすればいいじゃんか。

Aclogrep.grep('access.log') do |record|
  if record.url.index('bakagaiku.rb')
    printf("%s:%s:%s\n", record.date, record.bakaid, record.referer)
  end
end

ユーザにしたら面倒かもしらんけど、やりたいこと
知ってるのがユーザしかいないんだからしょうがない。
型にハメられるんなら、それをコードにしちゃえば
いいんだけど。

--

ああ、そうか。Windowsのシェルがやりたいのは
こういうことなのか? だったら気持ちはわかるなぁ。
irbだとRubyにしか使えないけど、.NETなら、それが
他の言語のオブジェクトにも使えるってことだろう。

本家Permlink


2006年07月16日

停電なんて久しぶりに食らった。

--

あははは、そりゃムチャってもんでしょう。

  プログラマってのはひとつの文を書くのに信じられない
  ほどの時間をついやして考えあぐねる人々のことだと
  思っている。

ですか? 

それとも、プログラムは誰が書いても同じようになる?

--

え? 神戸に引っ越したの?

--

スレッドなら結城さんのデザイン・パターンのがいいですよ。

--

え? 博士号取らないの?

--

ん〜、マーケティングなんですかね? いや、Railsの
ことよく知らないんですけど。

自分は、Railsがウケた理由は、やっぱ新しい開発スタイル
だからだと思うんですよね。もちろん、それを宣伝した
ってことはあるとは思うんですけど。

だから、Railsの流行とAgileの流行ってのは切り離せない
と思うんですよね。実際、DHHはAgileの信奉者らしい
ですし。

だから、Railsのスゴイところは、Agileの思想をコード化
しちゃってるとこなんでしょう。そういう根っこから
他の製品と違うんじゃないですかね。そうすることで
単なるツールを超えたんじゃないでしょうか。

ああ、そういえば、これはEclipseにもいえることで、
だからNetBeansはダメだと思うんですよね。機能云々
じゃないんですよね。思想やスタイルを訴えるほうが
強いですから。

--

そうじゃない。見た目にこそプログラマの技量という
ものが現れるんだ。

なぜか。悪いUIは、それだけユーザのことを考えて
作られていないことを示しているからだ。あるいは、
悪いUIというのは、良いプログラムを知らない
プログラマから生まれるからだ。結局、どちらも
プログラマの技量が足りないということになる。

何もリッチなインタフェースを提供しろといってる
わけじゃない。フツーのUIを提供しろといっている。

フツーとは何か。シンプルであること。使いやすいこと。
そのプラットフォームの慣習に従っていること。
たったそれだけのことだ。たったそれだけのことが
なぜできない? それはプログラマの技量が
足りないからだ。

http://capsctrl.que.jp/kdmsnr/wiki/transl/?UsingPatternLanguagesForOOP

  特に気になるのは、どちらの手法も最も重要な
  設計事項であるユーザ・インタフェースに重きを
  置いていない点である。

あのWardAndKentが『最も重要な設計事項である
ユーザ・インタフェース』とまでいっている。
わかるか? ダメなUIというのは設計がダメと
いうのと等しいんだ。

本家Permlink


2006年07月15日

ほんの15年くらい前なのに、OOPの捉え方が今とは
ずいぶん違ってたんですね。

15年前というと、SmalltalkがOOPLの代名詞でした。
C++は、少なくともPCの世界では全然マイナーだった気が
します。

で、このころのOOPの捉え方というのは、
シミュレーションの影響を強く受けてたんですね。
『OOプログラムは現実世界を再現したものだ』という
ヤツです。多分、今こう考えてる人は少ないでしょうね。

今はOOPを、どちらかというとモジュール化の
テクニックの1つとして捉えることが多いでしょう。
もちろん、モデルという考え方も残ってますけど、当時と
比べれば、それほど『再現』にはこだわっていませんよね。

まぁ、今でも『モデリング命』の人はいるでしょうけど、
そういう人も『現実世界の再現』なんてノンキなことは
考えてないでしょう。現実世界をどうデフォルメ
(抽象化) するか、どうコンピュータの都合に合わせるか
ということで悩んでるんじゃないでしょうか。

--

同じことをまた書くけど

顧客がストーリーを切るなっていったよね。ストーリーを
タスクに砕くのはプログラマの仕事だって。だって、
タスクに砕くってことは設計活動の一部なんだから。

そのかわり、だ。そのかわり顧客はプログラマに説明を
求めることができる。どういう方針でストーリーを実現
するのか。今どこまでできてて、何が残っているのか。
いつ実装が終わりそうか。そういう説明をプログラマに
求めることができる。

逆をいうと、プログラマは、顧客に説明を求められた
ときに、はっきりと答えなきゃいけない。『技術の
ことに口出しすんな』じゃダメ。難しいことでも
顧客がわかるように説明する努力がいる。

だから、顧客とプログラマとをつなぐのが計画って
ことになる。

ここまで書けばわかると思うけど、顧客とプログラマとの
間には信頼関係がないとダメ。いくら権利があるからって
いっても、そんなにしょっちゅう説明を求められたら
開発どころじゃなくなる。もちろん、プログラマの
ほうは、ウソをついちゃダメ。終わりそうもないのに
終わるとかいっちゃダメ。

--

JavaとかC++とかでインスタンス変数にプレフィックスとか
つける慣習ありますよね。

class Foo {
   private int m_value;
   private int value_;
}

みたいなの。まぁ、Rubyなんかは、この慣習を文法に
取り入れちゃったわけですけど。

はっきりいって、これ、ダメですよね。インスタンス
変数だと一目でわからないってことは、そのメソッド
なりが長すぎるってことでしょ。

ローカル変数は宣言するわけでしょ。ってことは、
宣言されてない変数はインスタンス変数ってことでしょ。
それが一目でわからないってことは、メソッドが
長すぎるってことでしょ。

逆をいえば、この慣習は、長いメソッドを助長してる
わけです。『長くなってもインスタンス変数が
わかるようにプレフィックスをつけよう』っていう
意図なんですから。

『全部が全部短いメソッドにはならんだろ!』っていう
人がいるでしょうけど。長いメソッドがあったとしても、
それが全体に占める割合はどうなんですか。2割も
あったら大変でしょう。ってことは、ほんのわずかな
長いメソッドのために、悪い慣習を取り入れてるって
ことになるでしょ。

誰もが長いメソッドはいけないことだって知ってます。
誰もがわかりにくい名前はいけないことだって知ってます。
なのになぜプレフィックスつけるんですか?
結局それって、長いメソッドやわかりにくい名前が
いけないことだってことをほんとにわかってないって
ことになるでしょ。日本人特有の本音と建前ってヤツ?

本家Permlink


2006年07月13日

ツールにこだわらない人がツールを作るっていうのは
どこか矛盾してますよね。

技術者の信条として『神は細部に宿る』っていうのが
ありますけど。それは『細部にまで気を配れ』っていう
ことでもあるでしょう。で、それってやっぱり細部に
こだわるってことでしょう。細部にこだわるってことは
ツールにこだわるってことにもつながるでしょう。

ツールを取っ替えひっ替えするのだってツールに
こだわってるといえると思うんですよね。よりいい
ツールを見つけようとしてるわけで。

でも、1つのツールにこだわるわけでもなく、身近な
もので済ますっていう意味での『こだわらない』は
やっぱり自分は好きじゃないです。

本家Permlink


2006年07月12日

ああ、実際そういうことはありますよね。
下請けがお客さんと直接話がしたいからっていって、
元請けに『そちらの名刺を使ってでも構いませんから
会わせてください』っていって頼んだのに断わられた
って話を聞いたことがあります。

こういうのは、こないだここでも取り上げた
(つっても、例によってリンクは張らなかったような
気がしますけど (笑)):

http://www.mars.dti.ne.jp/~hirok/xp/col/046.html

にも書かれてましたね。

前にも書きましたけど、高速道路時代になっちゃって、
元請けと下請けの技術的な格差ってのはなくなってる
わけです。むしろ逆転してることも多い。元請けは
プロジェクト管理のことで手一杯で、技術力や実装力が
落ちてます。ああ、ダメな下請けもまだたくさん
いますけど。

で、元請けは、そういう現実にどう対応するかが
問われてるわけですね。

自分は今でも下請けの立場ですけど、もうそういう
立場は気にしないことにしました。それは元請けに
恵まれてるからということもあるんですけどね。

前にも書いたように、今は総力戦の時代です。元請けとか
下請けとか、オープン・ソースとかプロプラとか、
オフショアとか内製とか、そういうことにこだわって
られない。結局、どうやったらビジネスとして成功するか
しかない。

--

多分、意図してなんでしょうけど、Interpreterってのは、
本来、ADTをそのまま評価するのが目的で、ADTを作る
ことは目的じゃないんですよね。そうGoFには書いて
あります。そういう点で、InterpreterでADTを作るって
いうのは興味深いですけど、ちょっと誤解を招くんじゃ
ないでしょうか。

本家Permlink


2006年07月11日1

ひさしぶりにJavaのコードをコンパイルしたら警告が
出てビックリ。ArrayListを生で使うと叱られるらしい。
要はパラメタライズド・タイプを使えということ。
ちょっと親切に過ぎない?

あれ? java.awt.Component#getGraphicsで取った
aGraphicsはdispose()したほうがいいんじゃなかった?

--

生産性を上げるっていうと、何かシャカリキになって
仕事するみたいなイメージがあるかもしれませんね。

でも、そういうことをやりたいわけじゃないんです。
人間性やゆとりを犠牲にしてまで生産性を上げたいとは
思ってません。

じゃあ、どんなことができるか。具体的なことをいえば、
たとえばビルドにかかる時間を減らすとか。cvs updateに
かかる時間を減らすとか。そういうムダをなくしたい。
ちょっと生生しすぎますか (笑)。

他にも意識の問題もありますよね。こないだ書いた
ビジネスへの積極的な関与とか。そうすることで作る
ものの価値を上げる。それもまた生産性を上げることに
なるわけです。

生産性と人間性やゆとりを両立するためにできることは
他にもたくさんあるはずです。

本家Permlink


2006年07月11日

XPE2ではRedundancyが1つの原則としてあげられています。
「冗長性」ですね。

わかりやすいのでいえばペア・プログラミング。1つの
コードを書くのに2人がかりです。

それから、「2つ (あるいはそれ以上) の実装案があるなら、
そのすべてを実装して比べてみる」っていうのも、
いわれていることです。

TDDにしても、最初にコードをコピーすることから
始めるやり方もあります。まず重複を目に見えるように
してから、それを取り除くというやり方です。

Redundancyは、XPの価値の1つであるSimplicityと正反対の
事柄で、RedundancyはSimplicityより弱いんですけど、
それでも原則の1つとしてあげられているわけです。

とはいえ、設計にはRedundancyをできるだけ持ち込まない
ほうがいいでしょうね。

--

記事にリンクを張るときは、下のPermlinkをご利用ください (笑)。

いや、ああいうことを書いても滅多に反応がないのは、
それが当たり前すぎるからなんでしょうねぇ。と
思いたい (笑)。

でも、XPにしても、当たり前を当たり前にしたから
生まれたわけで。たとえば、「テストはやったほうがいい」
って誰でも思ってるわけで、それはいわば「当たり前」な
わけで、でもテストを本当に頻繁にやるほどは「当たり前」
じゃなかったわけです、XPが生まれる前までは。
「ちょっとずつ作るほうが確かだよね」っていうのも
「当たり前」でしたけど、それでも前払いが幅を利かせて
いたわけです、XPが生まれる前までは。

# ああ、もちろん、XPが生まれる前からユニットテストや
# 都度払いを実践してる人はいましたよ。そういうのを
# 表に出したのがXPといってるだけで。

だから、「顧客のビジネスの成功がプロジェクトの
成功だ」っていう「当たり前」を、ほんとに真剣に
考えてるの?っていうね。真剣に考えてるんなら、
それはプロセスに組み込まれてないとおかしいでしょ?
っていうね。そこをいいたいわけです。

本家Permlink


2006年07月10日

こういう、まったりとしたリズムに慣れちゃうのが恐いね。
オレが異分子だからそう感じてるだけで、みんなは
そんなこと感じてないだろうけど。

--

前にも書きましたけど、Learn Teachingが大切です。
間違いじゃないですよ、Learn Teachingです。

ペアを組むとき、2人の知識が同じレベルであることは
滅多にありません。で、知識のあるほうが主導権を
取って開発を進めていきます。

で、その具体的な進め方ですけど、確か『先がハッキリ
見えているほうがコードを書く』といったことが
いわれていたはずです。これは間違いじゃないんですけど、
やっぱり間違い。というのも、知識のあるほうがコードを
書いちゃうと、知識のないほうが追いつけないことが
多いんです。今の自分がその立場だから、よくわかります (笑)。

『教える』ということに価値を置いた場合、コードを
書いたり、実際の作業をするのは、知識のないほうが
やるべきです。でないと、知識のないほうはただの
見物人になってしまいます。

模範を示すのは教え方の1つの手段です。でも、教師が
問題をぜんぶ解いちゃったら、そりゃ教えたことには
ならんでしょ。

もちろん、知識のないほうが作業をすれば、ペースは
落ちます。それは教育のコストというものでしょう。
だから、長い目で見ないといけません。知識のないほうが
学習することによって、チーム全体の生産性がいずれ上がる
だろうと期待するわけです。

いいですか。XPの原点というのは、『時間が無限に
あったらどうするか?』です。時間が無限にあったら
テストを書くでしょう。だからテスト・ファーストです。
時間が無限にあったら、教えることに時間を割くでしょう。
だから、Learn Teachinなわけです。

ペアを組むなら教え上手にならないとダメですし、
もっというなら、開発をうまく進めたいなら教え上手に
ならないとダメです。もちろん、自戒を込めて書いてますけどね。

本家Permlink


2006年07月09日

読者第一号であるbowezさんのために、最近知ったRakeの
新しいワザを1つ。あっちに書き足したいんだけど、
いい例題がまだ思い浮かばないんです。

んで、そのものズバリ書くと『タスクをタスクの中から
呼び出す!』です:

task :default => :call_tasks

task :call_tasks do |t|
  Rake::Task[:doit].invoke
  Rake::Task[:dothat].invoke
end

task :doit do
  p true
end

task :dothat do
  p false
end

makeだと、こういう場合、$(MAKE) で再帰的にやったり
しますけど、Rakeはそういうのはいらない。やっても
いいけど。

--

『分析と実装とのギャップ』などという言葉があります。
でも、こう考えること自体、ちょっとしたワナに
はまっているんじゃないでしょうか。

ある問題を解く手段が『分析』で、そこから求められた
ものが『実装』だとすれば、その『分析』が間違っていた
と考えるほうが自然でしょう。

ほんとのギャップは分析と実装との間なんかじゃなくって、
(顧客の) ビジネスとシステムとの間にあるわけです。
それを『分析』とか『実装』とかいう言葉で表現するのは、
問題のすり替え、あるいは矮小化というものでしょう。

ビジネスとシステムのギャップを埋めるにはどうすれば
いいか。ビジネスの価値をできるだけダイレクトに
システムに反映させればいい。そういう考えがXPの
ストーリーの根本にあります。

要件とか機能とかいう言葉ではなく『ストーリー』という
言葉を使うのも、ビジネスが中心であることを強調
するためでしょう。顧客が何をしたいのか。何が
ビジネスの価値なのか。そういうことを要件とか機能とか
仕様といった言葉で表現していいものなんでしょうか。
『ストーリー』には、そういう根本的な問いかけも
あるわけです。

ビジネスの価値をストーリーに砕く。そしてストーリーを
実際の開発作業であるタスクに砕く。こう書くとイニシエの
分析/設計/実装という流れと似ていますけど、もっと
ビジネスを前面に出しているわけです。いってみれば、
イニシエの分析/設計/実装という流れは、システムが
実装できてしまえば、顧客のビジネスが失敗しようが
知ったこっちゃないわけです。ちょといいすぎか (笑)。
でも、そういうコンサルが世の中にはたくさんいる
という話も聞きます (笑)。

で、ギャップを少なくするもう1つのテクが漸増的かつ
繰り返しの開発です。毎週のようにストーリーを注ぎ
込んだり、ちょっとずつシステムを大きくしていくことで、
システムがビジネスから離れないように監視するわけです。

で、こっからグチなんですけど、本物の顧客がいない場合、
あるいは、開発経験のある人物が顧客の役をやる場合、
えてして顧客の視点が失われがちなんですね。
ストーリーがビジネスの価値を反映しなくなる。そう
なると、チームのメンバもビジネスの価値を見失う
ことになります。これには解決策っていうのはなくって、
もう注意するしかない。いや、ほんとに (笑)。

ちょっと話がそれましたけど、結局、プロジェクトが
成功する、生き残るためには、顧客のビジネスが成功
しないとダメなんです。受注だって、そんなに
変わんないはずですよ。次の仕事来なくなっちゃいますから。
大手はしらんけど。だから、システムがビジネスの価値を
生み出すかどうか、生み出しているかどうかを常に
気にしてないとダメなんです。そのためにどうするか、
そこを考えるのが本当のプロセスなんじゃないでしょうか。

本家Permlink


2006年07月07日

ユニット・テストを先に書く。これが一番よく知られた
テスト・ファースト。

次に、受け入れテストを先に書く。これがXPE2で
述べられている中規模のテスト・ファースト。

さて、さらに規模を上げるとどうなる?

そう、計画を立てることがテスト・ファーストになる。
計画というのは、いうまでもなく、事前にやるものだ。
だから、プラン・ファーストと改めていう必要はない。

ユニット・テストはタスク、あるいはもっと小さな粒の
機能を検証する。受け入れテストはストーリーを検証
する。なら計画は? プロジェクトの動きを検証する。

プロジェクトがどこに向かい、今どこにいるかを
確かるために計画を立てる。何をすべきか、何をすべき
でないかを確かめるために計画を立てる。

こうやって考えることがSelf-Similarityということ
なんじゃないだろうか。

本家Permlink


2006年07月06日

昨日の話なんですけど、あのページでいわれているSEっ
ていう人あるいは職業に関していえば、の話ですよ。

あそこで「中流を目指せ」っていわれているSEって
いうのは、エンジニアじゃないですよね。だって、
やることといえば、人とかの資源の管理でしょ?

それと、軍隊のメタファーっていうのはもともと危険
なんです。上意下達の世界で、それは開発の世界とは
ちょっと違いますから。少なくともXPは、そういう世界を
目指していません。

どうも日本人というのは、管理者にスーパーマンを
求めるみたいですね。たとえば野球の監督にしても、
個人の技能指導から、選手育成から、リーグ優勝のための
戦略から、何から何までできることを求められる。
ムリだっつーの。

ああ、「SEはもっと顧客のビジネスに貢献すべきだ」っ
ていう話だったんですかね。それならもっともな話です。
でも、それなら別に軍隊なんか持ち出す必要は
ないですよね。

本家Permlink


2006年07月05日

こんな天気じゃテンション急降下だよ。

--

ああ、そういう意味でいうならSEはエンジニアじゃない
でしょう。管理者と呼んだほうがいいです。

今の業界が求めてるのが、管理者だというなら、そういう
ふうに人を育てないといけませんよね。それは前から
自分がここで訴えてることですけど。

プログラマと管理者は職能が違うわけで、勉強のために
一時的にプログラマを経験するのはアリだと思います
けど、プログラマを10年やったら管理者になれるとか、
そういうことはないでしょう。

本家Permlink


2006年07月04日

まぁ、裏を返せば、自分は設計が苦手ともいえるわけです。

ここでいう設計というのは、いわゆる設計のことです。

でも、厳密にいえば、大規模だからといって必ずしも
前払いでないと設計できないとはいえないでしょう。
縮尺を変えればいいわけですから。

設計というのは、ある高度からシステムを眺めた景色です。
低いとこから見れば、細かいとこまで見れるかわりに
全体が見えなくなる。高いとこから見れば、全体は
見れるけど細かいとこは見えなくなる。

前払いの場合は、最初は高いとこから眺めて、ある程度
時間をかけながら低いとこに降りようとします。まぁ、
スカイダイビングみたいなもんですかね。実装という
ロープもつけずに一気に飛び降りてしまう。そういう
点では、前払いのほうが設計にかける時間は全体としては
短いのでしょう。

ちょっと話がそれました。設計は、システムを見る高さ
によってその手段が変わります。低ければコードそのもの
ですし、高ければ図や文章といったものになります。
でも、どちらが優れた手段かということはないでしょう。
高さが違うわけですから。

言い替えると、ある高さの設計にかかる時間は、別の
ある高さにかかる時間とそれほど変わらないという
ことです。もちろん、これは一般論ですよ。でも、
高いとこから見た設計のほうが時間がかかるという
ことはないはずです。だって、詳細を無視してるはず
だから。高いとこから低いとこに視点を変えようとする
から難しくなるわけです。当たり前の話ですけど。

高いとこから見た設計が妥当かどうかは、低いとこまで
降りてみないとわからない。逆に、低いとこの設計が
全体として正しいかどうかは、高いとこまで登って
みないとわからない。

だから、リファクタリングするときは、システム全体が
良い方向に進むことを心に留めておかないといけません。

いやいや、ここまで書いといていうのもナニですけど、
こういうことを書きたかったんじゃないんです (笑)。
『どうすれば高いとこから見て、それなりに妥当な
設計を得ることができるか、しかも時間をかけずに』
っていうことを知りたいんです、自分は。

まぁ、これにはいろいろやり方があって、一般的には
UMLですね。でも、『時間をかけない』という前提なら、
厳密なUMLに出る幕はありません。厳密でないUMLなら
ホワイトボードに書くことくらいはありますけど。
XPではCRCカードというのもありますけど、実際に
使ってる人を見たことがない (笑)。他にもPragProgsは
ポストイットノートという、これまたよくわからない
ものを使うようです。

結局、『これだ』っていうのはないんでしょうかね。

--

http://c2.com/doc/crc/draw.html

ああ、わかった。CRCカードの障害は悪筆だ (笑)。
読めねー (笑)。

本家Permlink


2006年07月03日1

そう、顧客が将来どういう要望を出すかは予測しない。
そう決めたんだよね。

今ある問題を、確実に (間違いなく)、もっとも単純に
解くにはどうするかを考える。

『もっとも単純に』だけでは不十分だ。単純すぎて
要件を満たさないかもしれない。だから『確実に』と
いうことが大切。

What is the simplest thing that could possibly work?

--

いい物書きというのは、漠とした事象からギュッと
エッセンスを絞り出し、それを針小棒大に伝える
ものなのだなぁ。

--

XPE2のCorollary Practicesの1つにCode and Testsと
いうのがあるんですけど。これはコードとテストだけが
保守の対象、いわばプロジェクトの財産だという意味
なんですけど。

ちょっと意味合いが変わっちゃうんですけど、
プロジェクトの財産という意味では、やっぱり人も
大切だと思うんですよね。

XPではチームは動的に変化するものという前提がある
わけですけど、その一方で、Team Continuity、チームの
継続性というのもCorollary Practicesの1つとしてある
わけです。

コードとテストが保守対象といっても、そこから抜け
落ちてしまうものは必ず出てくるわけで。だから:

  Rely on social mechanisms to keep alive important history of the
  project.

  (XPE2: Corollary Practices, Code and Tests)

と書いてあるように、社会的な仕組みで補うと。
ここでいう社会的な仕組みというのが、人という
ことになるんじゃないかと思うわけです。生き字引と
いうヤツですね。

そういう意味で、組織内で流動的なのは歓迎される
ことなんですけど、組織から人が出てっちゃうのは
やっぱり痛い。歴史が失われちゃうわけです。
だから、やっぱり組織、そして仕事そのものが
魅力的じゃないとダメだと思うんですよね。人を
留められるだけの魅力を持ってないと。

--

へー、VC++2005にもmemccpyがあるんですね。ただ、
警告出ますけど。より安全な_memccpyを使えという
ことのようです。

memccpyはSingle Unix Specに入ってるみたいですね。
表の見方がよくわかんないんですけど。

_memccpyのほうは、VC++の警告を見ると:

The POSIX name for this item is deprecated. Instead, use the ISO C++
conformant name: _memccpy.

とあって、C++の標準なんですかね? ググっても
MSの他にはSunOSくらいしか引っかからないんですけど。

_memccpyは、少なくともglibc, libstdc++には入って
ないみたい。

--

いや、大いに反省しました。バカはバカでも、やっぱり
謙虚なバカにならないといけません。

まぁ、自分から怒りを取ったら何も残らないんですけど (笑)。

--

というわけで、昼の話の続きをもうちょっと。あんまり
自分語りはしたくないんですけど、この場合はちょっと
書いておいたほうがいいでしょう。前に書いたことも
あると思うんですけど。

自分がXPに至ったのは、いわゆるOOA/OODに共感
できなかったからです。図を描くばっかりでちっとも
プログラムが出来上がらない。しかも、自分が行き
詰まるのはやっぱりコーディングなんです。それだけ
基礎知識がなかったということなんですけど、それでも
図を描けば、あとは楽々コーディングできるっていうのは
信じられませんでした。

で、しばらくOOA/OODから離れて。プログラミングに
専念してたんですけど。もちろん、それと並行して
社会学系の本は読んでましたけど。で、Webかどこかで
XPっていうのを知ったんです。で、白本 (XPEの原書) を
買って。日記を見ると、2000-03-22に最初の記述が
あります。

で、しばらくして『リファクタリング』が出ました。
これが2000-06-08。XPEのときは実践の話が全然なくって、
正直、いいとは思ってもどこまで踏み込むべきか迷って
いました。でも、この『リファクタリング』を読んで、
ユニット・テストをやるようになって、『これだ』と
思うようになったわけです。

だから、もともとプロセスに興味があって、社会学系の
本とか読んでいたっていう背景はあるんです。だから、
他の人より動機付けは強いです。だから、強い動機を
持ってない人にXPが受け入れられるかどうかは、ちょっと
わからないんです。

XPを選ぶ人は、多分、今のやり方に疑問を持ってる人
なんじゃないでしょうか。だから、なんとなく『XPって
どうよ?』みたいに思ってる人だと『ふーん』で
終わっちゃう可能性が高いんじゃないでしょうか。

そして、もし今のやり方に疑問を持ってるなら、
持ってるなら、XPE, XPE2, PXPの原書を読んだほうが
いいです。和訳はメタメタですから。

あるいは、自分と同じように、実践から入るという
道もあるかもしれません。XPを選ぶ人なら、そっちの
ほうが向いてるかもしれません。つまり、
『リファクタリング』とSBPP (これの和訳は悪くない
ようです) とTDD (これも和訳はダメっぽい)。
SBPPは``Smalltalk Best Practice Patterns''で、
TDDは``Test-Driven Development''のこと。
読む順は、TDD, 『リファクタリング』、SBPPが
オススメ。

でも、実践の3冊はXPの一部でしかありませんから、
やっぱりXPの3冊も後で必ず読んだようがいいです。
XPE2はアレですけど (笑)、XPEは確実に面白いですから。

本気でやれば6冊を1年で読めるんじゃないでしょうか。
自分にはそんな根性ないですけど。逆をいえば、
それくらい時間をかけて熟読すること。実践の本の
場合は、実際に手を動かすこと。自分は、SBPPのときは
Smalltalkのコードを実際にGNU Smalltalkで
動かしましたし、リファクタリングはもちろん
Javaでしたし、TDDでもPythonのコードを実際に動かして
みました。

本家Permlink


2006年07月03日

ねぇっつの (笑)。

つか、真面目な話、XPE, XPE2, PXPの3冊は抑えとかないと
始まらないんだけど、それがクソだからどうしようもない。

がむばって英語読んだほうがいい。英語の勉強だとでも
思って。で、また、K.Beck氏の英語がわかりにくいんだ (笑)。

ちなみに、自分はK.Beck原理主義者ですから、XP本に関しては
上記の3冊以外読む必要はないと思っとります。
もちろん、XP以外では「リファクタリング」、TDD、SBPPは
必読。全部で6冊? これさえ読んでりゃXPer名乗っても
いいんじゃない? だってオレだってそうだもん。

本家Permlink


2006年07月01日

あんまり大規模開発だってことを認識してないんじゃないの?

C/C++シロートのオレが指摘するこっちゃねーと思うんだけど
なぁ。

まず、ガードされてないヘッダ。自分らはそれをいじれない
わけだ。勝手にガードしたらブーブーいわれちまう。それは
わかる。だったら、自己防衛するしかねーじゃん?

たとえば、noguard.hっていうノーガードなヘッダが
あったとする。だったら、自分らでガードすりゃいいじゃん?

// guard.h
#ifndef guard_h_guard
#define guard_h_guard

#include "noguard.h"

#endif

で、自分らはこのguard.hを使うようにすればいい。

それと、エクスポートされてないプロトタイプ。こういうのも
自分らでヘッダを作ればいい。

// missing_proto.h
#ifndef missing_proto_h_guard
#define missing_proto_h_guard

extern void hidden_func(void);  // defined in somewhere.c

#endif

*.cの中でチマチマプロトタイプ宣言書くより、こうやって
ヘッダに集めるほうがいい。なぜって? それが『見える化』
ってヤツだろ?

コードに問題があるんなら、それを直すのが一番。
でも、それができないんだったら、問題があるという
ことを顕在化させておかないとダメじゃん?

もちろん、自前ガードにしても、自前ヘッダにしても、
それで終わりじゃない。こういうパッチはいずれは
なくさなきゃいけないし、そのために外部に働きかける
必要がある。

いいか? 設計っていうのは、モデルとかクラスとか
そういう高尚な話ばっかじゃねーんだぜ? コードに
かかわる決定すべてが設計だ。だから、ガードしてねぇ
ヘッダも設計としてダメダメだし、それを放置して
インクルードしてるほうも設計としてダメダメなんだぜ?

でだ、そういう泥臭いところを避けないのがXPなわけ。
なぜって? コーディングはXPの主要なactivityだからだよ。
ガードしてないヘッダ、エクスポートされてない関数、
それはみんなコーディングの障害なわけ。だから、それを
取り除かないのは主要な活動であるコーディングを放棄
してるも同然なわけ。そんなものはXPじゃない。

本家Permlink


Copyright © 1905 tko at jitu.org

バカが征く on Rails