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

ホーム

2006年06月30日

あははは。やっさんみたいに「メガネ、メガネ」って
やってるとこを想像して笑ってしまった。

--

http://c2.com/cgi/wiki?MockObject

下のほうにある

  Isn't Mock Objects duplication or parallel hierarchy?

とかの質問は自分が書いたんですよね。ずいぶん
答えがもらえなかったんですけど。で、その答えが:

  No. A mock object implements an interface. You typically don't have
  a hierarchy of interface types.

ってなってて。これで疑問がちょっと氷解しましたね。
完全に氷解したわけじゃないんですけど。モデル・コード
(製品コード) のインターフェイスを変えなくっても、実装を
変えただけでも、やっぱりMockのほうも変えなきゃ
いけないっていうのはあるわけですから。そこに並列性は
存在します。ただ、Mockのほうは階層になることは少ない
わけで、その点は安心ですけど。

  Isn't it danger to use Mock Objects in dynamic typing languages?

っていうのは、動的言語だと、インターフェイスの
縛りが弱いわけで、それだけMockの裏付けが希薄になると
いうことを心配してるわけです。つまり、モデルとMockとで
インターフェイスが同じであることを保証できない。
もちろん、この回答にあるように、Mockは動的言語のほうが
適用しやすいのは事実なんですけど。

ああ、こうやって書いてますけど、自分は今はMockを
使ったテストはやります。

本家Permlink


2006年06月29日1

ちょっと誤解されそうですか。

『再利用に投資しない』というのは、もちろん
程度の問題です。XPでは、設計と同じように、
再利用にも先行投資しないということです。

再利用については、進化的設計の中で対応します。
つまり、once and only once、YAGNI、リファクタリング
などのルールや実践で、必要になったときに必要なだけ
再利用に投資します。

そもそもが再利用は設計の一部でしょう。ならば、
設計が日常の活動であるXPならば、再利用も日常の
活動になります。

--

C++なんですけど:

class Base {
private:
    virtual void do_parent(pid_t child_pid);
    ...
};

みたいなBase.hppがあったとして、このprivateな
do_parentで使われるpid_tのために<sys/types.h>を
Base.hppでincludeしなきゃいけないのはイヤなんです
けど、避けられないもの? どうしてもイヤなら、
Base.cppのほうにstaticで非メンバな関数を書くしか
ない?

本家Permlink


2006年06月29日

XPは、昔も今も人間系、社会学系ですよ。それから、
XPは、pragmaticでもあります。つまり、今、あなたが
参加しているプロジェクトをどうやって成功させるか
という問題を扱います。

そういう意味で、XPはすでに再利用について答えは
出してるんですよ。つまり再利用に投資するのは
pragmaticではないという答えを。

本家Permlink


2006年06月28日

あはは。

http://www.google.co.jp/search?q=man+exevp&start=0&hl=ja&lr=lang_ja&ie=utf-8&oe=utf-8&client=firefox&rls=org.mozilla:ja:official

もしGoogleがコンパイラ言語を作ったら、やたら
親切なコンパイル・エラーを出してくれそう。

本家Permlink


2006年06月27日1

昨日の話の続きなんですけど。

自分らプログラマだって手の抜き方はいろいろ
知ってますよね。ユニット・テストを書かない。
コンパイラの警告を無視する。汚いコードに目を
つぶる。他にもいっぱいいっぱい手の抜き方は
あります。

だから、結局モラルの問題というのは、自分ら
プログラマだけでなく、営業も顧客も関係する
わけです。だから、チーム全体としてモラルを
高めていかないといけないわけです。そのため
にも自分らはまず開発プロセスを向上させる。
そうすることで営業や顧客から信頼を得る。
信頼を得れば、営業や顧客のモラルを上げる
こともできる。信頼関係がなければ忠告といった
ものは無視されるだけです。

気の長い話ですけど、それが本筋というもの
じゃないでしょうか。

--

http://dgames.jp/dan/?date=20060626#p03

ニヤリ。

もちろん、製品の価値は、コードで計られるもんじゃ
ありません。製品の価値は、ユーザの満足度で計られる
ものです。

というのを大前提として。なお、以下の中の『品質』と
いう言葉は、ユーザの満足度は含まず、『バグの多寡』と
いった事柄だけを意味するものとします。

で、ゲームをステレオタイプな見方で見ると:

* 短命
* 規模が小さい
* ユーザがバグに寛容

といったことがあげられます。ただ、これらが当て
はまらなくなっている現状もありますよね。

短命には2つ意味があって、1つは製品サイクルが短いこと。
そしてもう1つは稼働時間が短いこと。でも、どっちも
今ではあまり期待できません。開発にかかる資金が大きく
なっている現在、再利用性が重視されているでしょう。
そういう意味で、短命なゲームでは資金回収ができなく
なっている。また、ネトゲなどでは連続稼動していて、
そういう意味でも短命であることが期待できなくなって
いる。いずれにしてもコードの品質が問われることに
なります。

同様に、規模が小さいということに関しても、今では
期待できないことも多いでしょう。開発する人数が
増えれば、やっぱりコードの品質が問われることに
なります。

ユーザに関しては今でも変わらないかもしれません。でも、
ネトゲなどの場合、バグで会社が傾いてしまう可能性は
十分あります。

ここで最初の話に戻りますけど、製品の価値はユーザ、
もっといえば顧客の満足度で計られるわけです。
今風にいえば、ユーザ・エクペリエンスが高ければ、
相対的にバグの多さというものは問われにくいという
ことです。昔のMac関係の製品はバグが多かったわけ
ですが、それを上回る魅力が製品にあったと。あるいは
バグだらけの真・女神転生が結構ウケたりもしました。

まぁ、それは置いとくわけです (笑)。自分らは魔法
使いじゃない、フツーの人なんだから。だから、品質の
問題を人任せにするんじゃなしに、自分のできることを
やろうと。

逆をいえば、自分は非常に欲ばっているわけです。
ユーザ・エクスペリエンスも高く、なおかつ品質も高い。
いってみれば、バグのないAppleを目指そうというわけ
です。

ところで、ゲーム業界には優秀な人が集っているという
ことはいえるんじゃないでしょうか。少なくとも熱意
という点では、他の分野に比べれば高いはずです。多分、
ゲーム業界に秘密なんかなくって、優秀な人がいると
いうだけのことじゃないでしょうか。
いや、ひょっとしたら『任天堂生産方式』みたいなものが
あるのかもしれませんけど。

本家Permlink


2006年06月27日

VC++の最適化をやさしく説明してくれるページは
ありますか?

コンパイラ言語だとこういうのがあるからイヤ!

本家Permlink


2006年06月26日1

なんかキャラ変えようとしてる?
というか、生で会ったときのギャップを狙ってる?
『日記じゃトゲトゲしてるけど、実際に会ってみると
優しい人じゃん!』みたいな。

トゲアマ。トゲトゲ + 甘。

100%流行んないな、これ。

--

結局さ、クズなコードからはクズな製品しかできないじゃん?
そんなの当たり前じゃん。いくらQAががんばったって限界って
もんがあるし。それにバグフィクスってのは後手なわけ。後手
後手に回って、汚ねぇコードが輪をかけてひどくなってくわけ。
だから、最初っからバグを少なくしようとしないとダメじゃん?
品質ってのはQAが保証するんじゃない。オレたちがオレたちの
存在を賭けて保証するんだぜ? わかる? わかってんの? ほんとに。

--

あ、思い出した。

自分にマインドマップは合わないと感じて使ってない
んですけど。

で、マインドマップでやたらデカくて細かい絵を描く人が
いますけど、そんなんじゃ役に立たないでしょ。
それってCでCGI書くようなもんじゃない? ちょと違うか。
でも、適材適所を知らないでしょ。
きっと開発も下手なんだろうなぁと思ってしまう。

--

ちょっとおかしい気がします。

これまで『モデリングが重要』と同じように『DB設計重要』
ということがいわれていましたよね。

で、これに対してXPは『モデリングなんか重要じゃない』
っていったわけです。いや、より正確にいうと、『モデリングに
時間はかけない』といったわけです。モデリングも都度払い
できると。

なら、DB設計も都度払いできるんじゃないですか? というか、
まだそれを試みた人はかなり少ないはず。それをあたかも
不可能のように否定するのはどうでしょうか。規模や複雑さは
今ではXPを否定する材料にはならなくなったんですよ?

まぁ、DB設計を都度払いできるかどうかはM.Fowler氏くらいしか
答えられないかもしれませんけど。

正直、自分はDBは疎いので、この直感が間違ってるかも
しれませんけどね。でも、もし、DB設計を都度払い
できないんだったら、agileなんかクソの役にも立たないと
いってもいいんじゃないですか? でなきゃ、DBが
今だにagileに応えられるレベルに達していないって
ことでしょう。ツールの発達があってこそのXPなわけ
ですから。でも、それを認めるのはDB Loveな人にとって
屈辱でしょう。

DBは*硬い*とか、データが膨大だとか、そういうのは
言い訳にならんとですよ。そこがフロンティアなわけで、
そこの技術を磨くというのが進化的設計を志す者の
勤めというものでしょう。

まぁ、Railsがいいわるいは別にしてね。自分はRailsは
知りませんから。

--

いやはや、みなさん賢いから、何でもゼゼヒヒで
ございますな。『XPがいい』って聞いても、『じゃあ、
そのいいところだけ頂戴しましょう』ってなもんで。
まぁ、それが技術者らしい態度なんでございましょうな。

ケッ

コウなことでございますな。

--

営業さんですかぁ。むつかしいですな、正直。

営業さんに仮想顧客になってもらうというのも手では
あるんですけど。
あるいは営業さんにプロジェクト管理者になって
もらうのも手ではあるんですけど。

ただ、営業にしても開発にしても、モラルが大切だ
というのはおなしなわけで。それをあたかも開発だけは
聖人君子が必ずそろうものだと言い切るのはちょっと
アレですよね。

まぁ、結局はMutual Benefitということに尽きる
んじゃないでしょうか。お客さんも、開発も、そして
営業も、みんなが満足するようなプロジェクトにする。
そのためには互いの信頼関係が大事だということに
なりますよね。で、その信頼関係を築くための努力と
いうのは続けなあかんでしょうね。

本家Permlink


2006年06月26日

あ。

本家Permlink


2006年06月25日1

DebianのEmacsでUTF-8を見るにはmule-ucsって
いうのがいるんだけど、前はそれは入れるだけで
有効になってたんだけど、ちょっと立ち上げが
遅くなるっていう欠点があった。

フと気づいたらUTF-8のファイルが読めなく
なってて、Firefoxからのコピペもできない。
で、/usr/share/doc/mule-ucsのREADME.Debianを
読んだら:

(require 'un-define)

をやってくれみたいなことが書かれてて、
そのとおりの.emacsでやってみた。これで
UTF-8も読めるようになる。

でも、前みたいに立ち上げが遅くなるっていう
のはなくなったような? だったら、デフォルトで
有効にしちゃってもいいんじゃない?

--

ちょっと気違いじみたことを書きます。

日本の業界は、米国で流行ったものだけを取り入れる
という風潮があります。Lispにしても、Smalltalkに
しても、米国ではマイナーながらも確固たる地位を
築いています (多分)。でも、そういうマイナーな
ものは日本ではほとんど受け入れられません。

業界全体が『右へ習え』といった感じなのです。

で、90年代、OOA/OODというものが流行りました。
当時自分はこの業界にいなかったのですが、それが
日本の業界を席巻したのは想像にかたくありません。
そして、おそらく、ここでも『右へ習え』が発動
したんでしょう。

その結果、日本には宇宙飛行士がウジャウジャいる
ことになった。実装を軽視する風潮はこのころ特に
強まったんじゃないでしょうか。

そして、クズなコードが残されました。

自分は、この90年代の宇宙飛行士の時代を深刻な
価値喪失だと考えます。日本がそこから立ち直るのは
かなり大変でしょう。若い人に期待するというのは、
そういう部分にもあります。

そのころの人たちが今は出世して、現場から離れたのは
幸いですが、逆に、彼らが反省しなければagile
というものは現場に浸透しないんじゃないでしょうか。
上の人が最終的にゴー・サインを出すわけですから。
特に大企業では。

--

そう考えると、やっぱりプログラマから管理者に
転身するのは間違いですよね。

優れた管理者になるためにプログラマを経験する
というのはアリかもしれませんけど。

プログラマの仕事っていうのは、非常に長い目で
見ないといけません。10年くらい使われるプログラム
なんてザラにあります。つまり、プログラマが作った
ものが優れているかどうかは、長い時間が経ってからで
ないとわからないことがあるということです。

プログラマが転身するとなると、自分の作品の結末を
知らずにいることになる。あるいは、自分のケツを
拭かずにいることになる。それじゃあ、いいプログラマが
育つわけがない。

本家Permlink


2006年06月25日

Lispが動的言語の源泉だとすれば、
AOPはやっぱり本命ってことになるんじゃ
ないですかね。
もちろん、AOPがOOPの次だといいたいわけじゃ
なくって、OOPとAOPは相互補完的なものです。

自分は、プログラマの意図を明白にすると
いう点で、AOPは有効なんじゃないかと
思うんですけど。ただ、応用範囲が狭いって
いうのはあるんですけど、それはまだ研究が
進んでいないからかもしれませんし。

--

あ、CよりRubyのほうが先に廃れる可能性の
ほうが全然高いですから。

Perlもそう。PerlはUnixの準標準スクリプト
言語といっていいでしょう。だから、最低10年は
大丈夫でしょう。落ち目だっつっても、そうそう
なくなりませんよ。

まぁ、でも、Rubyは、CやPerlというよりも
Unix文化の影響を受けているといったほうが
正しいでしょう。もちろんUnix文化というのは
Cの文化でもあるわけで、それがAPIにも色濃く
現れるわけです。

自分は、RubyのPerlっぽいところは嫌いなんです。
たとえば$_とか。昔、subに文字列を渡したのに
正規表現にコンパイルされるってのもあって、
それも嫌いでしたけど、今はコンパイルされなく
なってます。これは多分まつもとさんも同じで、
Perlの思想はいいけど、その実現は好きじゃない
でしょう。だからRubyを作ったと。

そういう意味だと、Perlが好きな人はやっぱり
Perlのほうが好きなんじゃないですかね。
RubyもPerlも好きだよっていう人はかなり
少ないんじゃないですか。

--

品質というのは、システム全体、製品全体で評価される
ものだ。だから、『この部分の品質は高いけど、この
部分の品質は低い』という評価はない。どこか一カ所でも
低い部分があれば、それが全体の品質ということになる。

だから、自分の担当する部分だけでなく、他の部分の
品質にも目を光らせないといけない。そうしなければ、
システム全体の評価が下がり、結局は自分の評価も
上がらないのだから。

--

``earn''という言葉。これは『稼ぐ』という意味だけど。
自分はこの『稼ぐ』という言葉を能動的なものと
捉えている。つまり、座っているだけでお金がもらえる
ようなことを『稼ぐ』とはいわないわけだ。

能動的に稼いでこそ、働きがいが生まれる。
能動的であるということは、傍観者ではいないことだ。
能動的であれば、その分責任を負うことになる。
それはリスクだ。でも、そのリスクを取って稼ぐ
というのが自分の価値観だし、そういう価値観を
共有したいと願っている。

本家Permlink


2006年06月24日

『若い』ということが条件にあがってたみたいで、
オシムの代表監督はない線だと思ってたんですけど。

つか、なんか情けねぇ。自分はオシム監督は
好きですし、尊敬もしていますけど、もう歳だし、
千葉あたりでのんびりとサッカーを楽しんでて
ほしかった。まだまだ千葉はオシムを必要としてる
んじゃないかとも思うし。

そういうオシムに頼らざるを得ないという日本の現状が
情けないし、もうちょっと人を探す努力をしろと。

--

むぅ。strncpyは使いにくいんですね。infoにも
srrncpyはパフォーマンスに問題があるって書かれてます。

まぁ、富豪としてはパフォーマンスはともかく、
'\0'で終わらないことのほうが問題ですか。
だとすると、strncpyの正しい使い方というのは:

strncpy(dest, src, n);
dest[n-1] = '\0';

ってことになるんでしょうか。標準にこだわるならば
の話ですけど。

--

http://www.toyokeizai.net/online/tk/person/index.php?page=3&kiji_no=28

 この形を勉強するならこの人の棋譜を見ればいい、というのがある。そうい
  うのを見つけ出すことがすごく大事。検索してオーソリティ見つける。たく
  さんの人が見たということよりも、信憑性の問題。この人のだったら間違い
  ない、というのが見極められるか否か。もう最終的にはそこに尽きてしまう。

オレは『この人』になれてるんだろうか。

--

コンパイル時の警告、それはコードの悲鳴なんだ。
治してくれと叫んでいるんだ。
キャストで黙らせても、何の解決にもならない。
それは暴力で黙らせることに似ている。それで問題が
解決されるわけではなく、不満が地下に潜り、燻り続け、
いずれ大爆発を起こすだろう。

本家Permlink


2006年06月23日1

オレはさ、カリスマでもないし、ベシャリも上手くないし、
会議は今でも嫌いだし、せいぜい茶々入れるくらいが
一番なわけ。そいでもって、ここでグチ垂れるくらいがさ。

でもさ、オレはさ、隅に隠れるのは止めたんだ。だったら
いわなきゃダメじゃん? 間違ってると思ったことを口に
出して表明しないとダメじゃん?
シャベリが下手でキツイ表現になってもさ。それで
煙たがられてもしょうがない。隠れるのを止めるってのは
そういうことなんだから。

--

それから、オレは単なるプログラマなわけ。これは
謙遜でも、自戒でもなく、ほんとにそうなわけ。
アーキテクトみたいな知識持ってるわけでもなければ、
いわゆるSEみたいにビジネス・マナーを知ってる
わけでもない。ましてやプロセスのコンサルタントでも
ない。いろいろとプロセスのことについて考えるのは、
それがプログラマの仕事の一部であるからだし、まぁ、
それが嫌いでもないっていうだけなわけ。

だから、やっぱりコード書いてるのが一番楽しいし、
コード書くのがオレの仕事だし、そうでなければこの
業界から足洗って趣味でプログラミングしたほうが
よっぽど楽しい。

--

エモノのほうにリンク張ったんですけど。

『見える化』の話から『モジュール化』の話に
つなげるのはどうでしょうか。

建築のメタファー同様、製造業のメタファーも十分に
失敗する可能性がありますよね。

本文でも触れられているように、モジュールという
ものは不安定なわけで、それがソフトウェアの本質
なのかもしれません。だとしたら、モジュールに
こだわること自体が間違いである可能性も高い
ことになります。

それは、アーキテクチャにこだわることにも
いえます。インフラに先行投資することはXPでは
嫌われます。そして、先行投資でないアーキテクチャ
なら、それは多分、フツーの進化的設計の範囲内
でしょう。

トヨタの、『気付く、広める、比べる』というのは
非常にタメになります。でも、その実際を読むと、
あんまり自分はやりたくありません。何かにつけて
レポートを提出したり確認したり。まぁ、それが
仕事っちゃ仕事なのかもしれませんけど、そういう
ことをやんなきゃいけない仕事は仕事にしたくない (笑)。

本家Permlink


2006年06月23日

人間なら誰でも間違いはある。でも、そこで考えるのを
止めていいわけがない。

間違うのを防ぐことを考える。それがプロセスを考える
ということだ。

逆をいえば、間違いが起きるのは、今のプロセスに問題が
ある可能性が高いということだ。

「5つのなぜ」はそういうために使うんだし、
Root-Cause Analysisとは考えるのを止めない
態度のことだ。

--

http://japan.cnet.com/column/pers/story/0,2000055923,20055389,00.htm

「オープンソースの陰」と称して次のような点をあげています:

* 技術的停滞
* 市場の破壊
* クローズコミュニティ
* 知的所有権

「技術的停滞」というのはオープン・ソースに限った話じゃ
ないですよね。規模が大きくなったり、長く使われてたら、
そりゃオープンだろうがクローズだろうが変えたくない人の
ほうが多いでしょう。

「市場の破壊」という面もありますけど、それと同時に
「市場の創造」という面があることを無視しています。実際、
オープン・ソースのおかげで中小規模の企業の活力は大きく
なったんじゃないでしょうか。

「クローズコミュニティ」というのは、何と比べてなのか?
独占的ソフトウェアの場合、もともとクローズドなわけで、
それと比較したら、クローズドなオープン・ソース・
コミュニティであっても、全然民主的じゃないでしょうか。

「知的所有権」についても同様で、オープン・ソースに
限った話ではありません。今はどんなに大企業でも、どんなに
調査しても知的所有権の地雷を踏む可能性が高くなっています。
これは「作りたいものを作れない」という人間の根本的な
活動に関わってくるもので、オープン・ソースだけの
問題じゃないはずです。

本家Permlink


2006年06月22日

ストーリーが出されたら、それをタスクに分解する。
その分解する段階からすでに設計が始まっている。
これまで、そういうことを設計と呼ぶ習慣は
なかったが、それは明らかに設計という活動の一部だ。
そして、それが設計活動の一部ならば、その分解は
プログラマがやらなければならない。しかも、その
ストーリーの実現の責任を引き受けたプログラマが
やらなければならない。

これまでの習慣でいう設計というものには時間軸が
欠けていた。それでは進化的設計には対応できない。
要求があり、それをどういう手順で実現していくか。
当たり前だが、そういうことを考えることはとても
大切だ。

本家Permlink


2006年06月21日1

g++で*.soを作れば、C++でもリフレクションまがい
のことはできそう。少なくともテスト・メソッドを
抜き出すのは簡単そう。

#include <iostream>

using namespace std;

class MyTest {
public:
    void test_doit();
    void test_dothat();
};

void MyTest::
test_doit()
{
    cout << "hello, world" << endl;
}

void MyTest::
test_dothat()
{
    cout << "hello, universe" << endl;
}

#!/usr/bin/env ruby
bin = File.read(ARGV[0])
test_methods = []
while (match = bin.slice!(/\w+Test::test_\w+/))
  test_methods << match
end
p test_methods

$ g++ -Wall -g -c cpp.cpp
$ g++-4.1 -shared -Wl,-soname,libcpp.so cpp.o -o libcpp.so
$ ruby rb.rb libcpp.so 
["MyTest::test_dothat", "MyTest::test_doit"]

--

自分はC++のPOSIXライブラリはPOSIX側で策定すべき
だと思ってるんです。CにはUNIXの機能が入りすぎた
観がありますから。

で、ググるとこういうのが見つかります:

http://standards.usenix.org/posix++wiki/WorkGroupOrganization

で、これがまた実体がなさげなんだ (笑)。いや、
こういうのは大企業様たちが秘密裏に策定してんのかも
しんないけど。

何度も書いてますけど、自分はC++は嫌いじゃない
です。Cより全然好きです。でも、C++の仕事でペイ
するまでになるのは相当難しいと思うんですけどね。

--

オレはさ、『マッド』は全然オッケーなわけ。

この『マッド』っていうのは、P.Graham氏がいってる
『ハッカーは口に出すのも憚れるようなことを考える』
っていうようなことを指すわけ。

だから、たとえば『著作権法がザルであることを証明
するためにサイコーのP2Pソフトを開発する』とか。
『技術的に面白いからワームを発明しちゃって、実際に
効果を確かめたくなった』とか。

もちろん、何度も書いてるように、技術者は高い
モラルを持たなきゃいけないんだけど、それはオレの
プロ意識がいわせるのであって、『マッド』はまた別な
価値観なわけ。

でも、ヤツらは違うじゃん。技術者の皮をかぶった
ただの小悪党じゃん。モラルも低ければ、マッドでもない。
そんなもん、許すわけにはいかねー。
ベンチャーとしても認めねー。

--

考えてみれば当たり前の話なんですよね。
ひがさんとこはともかく、フツーは受注生産の会社で
ベンチャーするのはかなり難しいんですよね。
どうしたって顧客の獲得に限界が来るわけで。
顧客を獲得するためには、同じソフトで多くの人が
使えるもののほうが有利なわけで。
それでもって、大口の顧客を獲得できるかっつったら、
まずムリなわけで。そういうのはもう大手が取っちゃう
わけで。

--

ああ、『ひがさんとこはともかく』っていうのは
皮肉じゃないですよ。顧客獲得の限界を超えることを
真剣に考えてるわけですから。

自分がひがさんのを読まないのは影響を受けたく
ないからで、多分、読んだほうがタメになる人のほうが
多いでしょう。

要は、自分のヘソが曲がってるっていう話で。ま、
ひがさんもこのページなんか読んでないでしょうし。

本家Permlink


2006年06月21日

MeadowでCygwinのlsが``ls -1''になっちゃうんだけど、
``ls -C''とやるとカラム表示できる。

つまり、~/.bashrcで:

if [ "$TERM" = "emacs" ]
then
    alias lc='ls -CF'
    alias ls='ls -C'
else
    alias lc='ls -F --color'
fi

とやればいいんだけど、lsをそのままaliasするのは
個人的に大嫌いなので (だからRedHatとか嫌い)、

if [ "$TERM" = "emacs" ]
then
    alias lc='ls -CF'
    alias l='ls -C'
else
    alias lc='ls -F --color'
fi

とすることにした。

本家Permlink


2006年06月20日

(自主規制)

あんまり書くとオレがタイーホされちゃうから
書かねぇけど、少なくともbakaiku読者は
就職禁止な。就職したら縁切るから、マジで。

--

http://d.hatena.ne.jp/habuakihiro/20060618#1150557955

自分、habuakihiroさんとこは読まないようにしてる
んですけど (笑)。

上のリンクで書かれてるのは、こないだ自分が書いた
話とちょっと似てますよね。ほら、T.O'Reilly氏の
出版業界分析記事に触れたときの話。

ただ、自分はプログラマを雇うほうが現実的かな
とは思いますけど。いや、こっちも全然現実的じゃ
ないか (笑)。パッケージとかASPがあるから、そういう
ので満足できるんならそれでいいし。それじゃ満足
できないんだったら、すでにそれだけの体力のある
証拠なんだし、プログラマを雇ったほうがいい
んじゃない?

まぁ、例によって自分の意見は少数派だろうけど。
でも、いずれにしてもプログラマができることは
まだまだたくさんあるってことに間違いはないでしょ。

--

ああ、あと、いじめられてるっていうならC/C++に
かなうものはないでしょ。C++だってシステムの
稼働時間からいえばJavaのシステムより全然長いでしょ。

結局、言語なんて使う側の思い込みで使う、使わないが
決まるわけです。生産性なんて計測できないし、
実際にコードを書くプログラマが決定権を握ってる
わけでもない。

本家Permlink


2006年06月19日1

まぁ、あんまり書くとクドイっていわれちゃうけど。

だから、コードを書くときも設計のことを考えてやるわけ。
設計フェーズとかコーディング・フェーズとか、そういう
区切りはないわけ。

コードを書くってことは、コードを読むってことじゃん?
コードを読めば、重複の1つや2つ見つかるじゃん?
見つけた重複はどうすんの?
リファクタリングするじゃん?
リファクタリングは設計じゃん? 
ほら、コーディングと設計の間に区切りなんかないんだよ。

フェーズを区切るっていうのは、臭いものにフタを
してるのとおなじだぜ?

もちろん、今やってることの区切りをつけることは大切だ。
区切りがないと迷子になっちゃうから。でも、区切りを
つけてリファクタリングするまでの時間はごく短いもの
なわけ。1日に何度も行き来することもあるし、ちょっと
厄介なのは新しいストーリーにしてもらう。ストーリーに
してもらうってことは次の週にはやるってことだ。何ヶ月も
ほっとくことはしない。それより大きいもの、
big refactoringは、まぁ、チームの事情にもよるかも
しんない。

--

なんかしんないけど、ユニット・テストは広く認知
されたみたいでさ。でも、ほんとにわかってんのかな?
ユニット・テストを書くってことは、コードの量が
メチャメチャ増えるってことじゃん。っていうか
そのくらいの量がないとユニット・テストの意味はないし。
で、コードの量が増えたら、まともに設計しないと
やってけないじゃん。テスト・コードも
リファクタリングの対象だっていうのはオレも度々
書いてるけどさ。ユニット・テストなんか書いてるんなら、
設計とコーディングのフェーズの区切りなんかあったら
コードがすぐに腐っちゃうよ。

--

いや、なんか全然反響がないから、オレのほうが頭が
おかしいのかと思っちゃうよな。でも、それなら
ユニット・テストが認知されたことと矛盾するし、
リファクタリングが認知されたこととも矛盾する。

ユニット・テストやリファクタリングが認知されているのに
『設計とコーディングのフェーズは分ける』っていうのが
いまだに常識なのはどういうこと?
なんかズレてるんだよな。

結局言葉だけしか受け入れられていないんだろうな。
でも、言葉だけ受け入れたらユニット・テストにしても
リファクタリングにしても最悪だよ。コードの量は増えるし、
コードはいつも不安定だし。

そういう苦労と正面から向き合って、それを苦労と
思わなくなって、ようやくユニット・テストと
リファクタリングの意味がわかるんじゃないのかな。

少なくとも自分は、ユニット・テストを書かない
コーディングは気持ち悪い。腐ったコードを見ると
無性に直したくなる。たとえそれでシステムが不安定に
なっても (笑)。

本家Permlink


2006年06月19日

「リファクタリング」や``Smalltalk Best Practice
Patterns''が教えてくれたのは、設計 (designing) 
というのは日常の活動だということでしょう。

関数に名前をつけるのも設計という活動の一部だし、
フォーマッティングを整えるのも一部だし。

だから、設計というのを前払いとして捉えちゃダメ
でしょう。
もちろん、XPでも前払いみたいなことはやりますよ。
でも、そりゃ当たり前の話で、方針も決めないで
いきなりコーディングするなんて、いくらXPでも
やりませんから。でも、その方針決めるのに時間は
かけませんよね。時間かけちゃ、日常的な活動とは
いえないわけですから。

結局、いわゆる設計と実装の違いっていうのは、
XP的な視点からいえば規模の違いでしかないって
ことでしょう。高い位置から見れば、コードの
代わりに図を描いたりするし、低い位置から見れば、
コードを書く。でも、そこから向けるのは常に
設計という視線なわけですよね。コーディングと
設計とを分けるなとここで繰り返し書いているのは
そういうことです。

本家Permlink


2006年06月18日

http://www.dinkumware.com/manuals

どういうわけかC++の標準ライブラリのオンライン・
リファレンスはDinkumwareのしかなくって、
そのDinkumwareのリファレンスも、ミョーな制限が
ついてたりしてたんですけど、そのミョーな制限が
なくなったみたい。ありがたいことです。

--

いいすぎた。ごめん。

--

余計なヘッダ・ファイルをインクルードすることで、
コンパイル時間が長くなるのは当たり前の話なんですよね。
特にC++の場合は、ヘッダ・ファイルに実行コードが
書かれていることが多いからなおさらです。

まぁ、現実問題、余計なコードがコンパイルされたからって、
そんなに時間が喰われるわけじゃないと思うんですけど。
それよりも、やっぱりコードの質が問題ですよね。

一般的にいって、きれいなコードは質が高いという
コンセンサスがありますよね。じゃあ、きれいなコードって
何? 条件の1つに、ゴミがないことがあげられますよね。
じゃあ、余計な#includeは? そりゃゴミですよね。意味が
ないコードなんですから。ってことは、余計な#includeが
あるコードってのは、やっぱり質が低いわけです。

こないだも書きましたけど、あるコードを見て、きれいだとか
汚いとかいいますけど、それは見た目じゃなくって技術
としてどうかということ。余計な#includeがあったって
見た目がそんなに落ちるわけじゃないですよね。でも、
それは技術的にはゴミなんです。だから、きれいだとか汚い
とかを見た目で判断するなと。

さらにいえば、センスという言葉で簡単に済ますなと。
センスは確かに大事だけど、コードは時間をかけて
磨き上げていくものだということ。センスというのは
瞬間瞬間の判断に優れていることをいうんであって、
それは必ずしもコードのきれいさとは結びつかない。

本家Permlink


2006年06月15日

C/C++のリファクタリングの1つにはマクロの展開
っていうのがあるんだろうけど、メンドイな、これ。

--

http://staff.aist.go.jp/toru-nakata/humanerror.html

長くて読み切れてないけど必読。第3部まで読んだ。

--

やっぱりRakeはいいなぁ。Windows上のCygwinで使えない
のはほんとに痛いな。もうちょっと調べてみるか。

#!/usr/bin/env rake  # -*- mode:ruby -*-

require 'rake/clean'

CLEAN.include('sh2', 't-sh2', '*.o', '*.exe', 'PromptRunner')

CXX = 'g++-4.1'
CXXFLAGS = '-Wall -g -fPIC'

def link(key, array)
  file key => array do |t|
    sh "#{CXX} #{t.prerequisites} -o #{t}"
  end
end

rule '.o' => '.cpp' do |t|
  sh "#{CXX} #{CXXFLAGS} -c #{$cppflags} #{t.source} -o #{t.name}"
end

task :default => 'test'

task :test => ['t-sh2', 'PromptRunner', 't-prompt'] do |t|
  sh "./t-sh2"
  sh "./t-prompt"
end

link('sh2', ['sh2.o', 'main2.o'])
link('t-sh2', ['t-sh2.o', 'sh2.o'])
link('PromptRunner', ['PromptRunner.o', 'sh2.o'])
link('t-prompt', 't-prompt.o')

まぁ、Rake使うと移植性という点じゃ全然落ちる
わけだけど。それもいろんな意味で。Rubyがわからないと
手を出せないしね。Ruby知らなくっても、なんとなくは
わかるだろうけど。Ruby自体はUnixでもWinでもMacでも
動くわけで、多分それはRakeもおなしで、まぁ、そういう
意味での移植性だったら十分すぎるほどあるとはいえる
んだけど。

本家Permlink


2006年06月14日

XPE2, ``Planning: Managing Scope''より

  As a young software engineer, I learned three variables by which to
  manage projects: speed, quality, and price. The sponsor gets to fix two
  of these variables and the team gets to estimate the third. If the plan is
  unacceptable, the negotiating starts.

  This model doesn't work well in practice. Time and costs are gener-
  ally set outside the project. That leaves quality as the only variable you
  can manipulate. Lowering the quality of your work doesn't eliminate
  work, it just shifts it later so delays are not clearly your responsibility.
  You can create the illusion of progress this way, but you pay in reduced
  satisfaction and damanged relationships. Satisfaction comes from doing
  quality work.

XPE1でもいわれているように、高い品質を維持することは
XPの使命 (死命) です。

品質を下げたツケが後になって回ってきたといった
ことは誰にでも経験があることだと思います。
レガシー・コードが開発速度の足を引っぱることも
多いですよね。それは、とりもなおさず、レガシー・
コードの品質が低いからです。

逆をいえば、開発速度を上げるには、品質の高いコードを
書けばいいということになります。もちろん、テストも
含めてですよ。

昨晩もチラッと書いてすぐ消しちゃったんですけど、
品質の高いコードというのは、サラサラ書けるもんじゃ
ないんです。何度も書き直して品質は上がるものなんです。

それと、話は変わりますけど、上の最後のほうで
satisfactionっていう話が出てきましたね。これも
自分が最近書いている『働きがい』の話に通じるものです。

質の高い仕事をして働きがいを高める。そういうごく
当たり前の話をしてるだけなんですけど、どうもウケが
よくないみたいで (笑)。

--

引き続きXPE2の``Planning: Managing Scope''から:

Plan at every timescale with these four steps:

1. List the items of work that may need to be done.

2. Estimate the items.

3. Set a budget for the planning cycle.

4. Agree on the work that needs to be done within the budget. As you
   negotiate, don't change the estimates or the budget.

前に書いたように、計画というのはトップダウンです。

やるべき作業をリストアップして、
それぞれの作業を見積もり、
全体の予算を決め、
実際にやるべき作業について合意を得る。

だから、まず大きな絵を描くことが大切です。
そして、大きな絵を切り分けていく。

よくありがちな間違いが、深さ優先で絵を切り分けて
いってしまうこと。立案というのは規模、あるいは粒度
というものが重要で、不必要にまで細かく切り
分けるのは時間のムダですし、肝心の大きな絵を
見失ってしまう可能性が高くなります。

本家Permlink


2006年06月13日1

というような話はプライベートの日記に書く
ことにした。こうした約束事が守られた例は
ないんだけど (笑)。

いや、ほんとは具体例をあげつつ、ああだ
こうだ書きたいんだけど、さすがにそれは
できない (笑)。だから、どうしてもヘンに
抽象的で偉そうな書き方になる。

そんなに難しいことをいってるつもりはないし、
間違ったことをいってるつもりもないんだけど。

本家Permlink


2006年06月13日

http://www.kt.rim.or.jp/%7ekbk/zakkicho/zakkicho12.html#D20060611

というわけで、_tサフィックスは使っちゃイカンという
方向で。どこまでがライブラリかってのは難しいけど、
多分、<...>でインクルードされる類のものとか。
って、それも乱用されてるみたいなんですが (笑)。

--

WinのOne-Click Installerで入れたRubyに
Rakeを入れてみたんですけど、Cygwin端末からは
使えないんですか?

  $ rake.rb
  c:\ruby\bin\ruby.exe: No such file or directory -- /cygdrive/c/ruby/bin/rake.rb
  (LoadError)

本家Permlink


2006年06月12日

XPE2 ``The Theory of Constraints''より:

Here's a sad but repeated story: a development team begins apply-
ing XP, dramatically improves quality and productivity, but then is dis-
banded, its leaders fired and the rest of the team scattered. Why does
this happen? From the Theory of Constraint perspective, the team's
improved performance shifted the constraint elsewhere in the organiza-
tion. The new constraint (e.g. marketing, who can't decide what they
want fast enough) doesn't like the spotlight. Nobody actually cares
about organizational throughput. The "source" of the turmoil, XP is
blamed and eliminated.

Executive sponsorships and strong relationships with people outside
the team are crucial to applying XP, precisely because applying XP will
shift the structure of work in the rest of the organization as soon as
software development gets its act together. If you don't have executive
sponsorships, be prepared to do a better job yourself without recogni-
tion or protection.

いかにもK.Beck氏が実際に体験した事柄だと感じさせる
内容ですね。

個人レベルでは、これまでもこうした話はよく
あったんだと思います。『できる人』の能力が組織の
容量を超えてしまうんでしょうね。
そうしたとき、ありそうな結末は2つでしょうね。

1つめは、『できる人』の地位を上げて遊軍的な位置に
置く。まぁ、これは平和な話です。

2つめは、『できる人』が組織から出ていく。
この場合、出ていくまでに様々な経過が考えられます。
閑職に追いやられるとか、『できる人』への負担が
増えすぎるとか。

で、XPみたいなのが出てくると、こうした話がチーム・
レベルでも起きるっていうんですね。
『できるチーム』が出てきたとき、組織として、
あるいは上層部としてどう扱うか。

異端児の集団として解散させてしまう、あるいは
そこまでしなくっても、圧力をかけて骨抜きに
してしまうっていうのが、ありがちな結末でしょうね。
もちろん、それじゃ組織全体のスループットが上がる
わけありません。

これからは『できるチーム』の良さをどうやって組織の
他の部分にまで影響させるかってのが焦点になるんだと
思います。

だから、他のとこの人間を『できるチーム』に体験入隊
させたりとか。そういう工夫をしていかないと
いけないんじゃないかと思うわけです。

本家Permlink


2006年06月10日1

sidだとmake-docがnon-freeに入ってるんだけど、
そういうもの?

--

C言語のtypedefって、新しい型名に_tを
サフィックスでつけるのは推奨されない
んじゃなかった?

本家Permlink


2006年06月10日

Emacsの起動でフォントのエラー・メッセージは
出なくなったんだけど、メニュー・バーの
フォントがクソ汚ねぇ。こんなもんか?
M-x infoでも文字化けしなくなった。

--

CxxUnit、よさそうなんだけど、ここ最近、
手入れされてないみたいなんだよなぁ。
Perlじゃ手の出しようもないし。

本家Permlink


2006年06月08日

require 'pp'
require 'stringio'

class Mine
  def initialize
    @array = [1,2,3]
  end

  def inspect
    StringIO.open('', 'w') do |output|
      PP.pp(@array, output)
      return output.string
    end
  end
end

PP.pp(Mine.new)

PP.ppを使うのは、出力先を与えたいから。
具体的にいうとStringIO。昨日やったみたいに。

で、PP.ppは、inspectがオーバーライド
されていればそれを出す。
でも、inspectを潰したくない場合は?

あと、上のと

PP.pp([1,2,3])

とでビミョーに結果が違います (笑)。
インデントも変わっちゃうんですよね。
配列が特別扱いされてるせいですかね。

--

『開発はガーデニングに似ている』と
いったのはPragProgsでした。
特にコードに関してはガーデニングに
似ているのではないかと感じます。

コードは腐りやすいです。
新機能をどんどん追加していくだけでは
すぐに腐ってしまいます。
コードが腐り、システムが腐ると、
待っているのはシステムの刷新です。
刷新というと耳触りはいいですが、
要は、面倒が見切れなくなって
捨てるということです。

システムの刷新はXPではありません。

コードは手入れを必要とします。
雑草を取り除き、
草木を動かして風通しを良く
する必要があります。

手入れは小まめにやる必要があります。
これはPragProgsのいう『割れ窓の理論』
です。

さらにいえば、手入れを小まめにやる
ためにもテストが重要になるのです。

--

いや、ほんと、リファクタリング
っていう言葉は広く知られるように
なりましたけど、
『そろそろリファクタリングすっか』
とか
『あとでリファクタリングすりゃいいじゃん』
とか
バカが多すぎる。
そんなものはリファクタリングじゃない。

ユニット・テストも書かず、
まめにリファクタリングしないんなら、
『動いてるコードを触るな』のほうが
よっぽど理に適ってる。

本家Permlink


2006年06月07日1

我々は間違った種類のドキュメントを
残そうとしているのではないか?

ある程度の規模を持ったシステム、つまり
独自のフレームワークを形成している
程度の大きさのシステムならば、もっとも
必要とされるのは、そのフレームワークの
チュートリアルだ。オープン・ソース流に
いうならハッキング・ガイドということ
になる。

仕様は、最悪、システムに聞いても
わかるし、ソースを読んでもわかる。
けれどもチュートリアルとなると
そうはいかない。
チュートリアルとは、そのフレームワークを
利用するときのエッセンスだからだ。
何も知らない人間が、複雑に入り組んだ
ソース・コードからエッセンスを
取り出すには時間がかかりすぎる。

我々は間違った種類のドキュメントを
残そうとしているのではないか?
あるいは、その反動で、残すべき
ドキュメントすら残そうとしていない
のではないか?

--

アクセス・ログからbakagaiku.rbのリファラを
取り出すことにした。

最初のうちは純粋にTDDでやっていた、つまり、
単純なTODOリストでやっていたんだが、
どうも全体の流れがよくつかめない。そこで
疑似コードで書いてみることにした:

lines = IO.readlines(access_log)
arrays = lines.map{|line| split_line(line)}
filter_bakagaiku!(arrays)
filter_referer!(arrays)
bakaids = collect_bakaids(arrays)
print_referers(bakaids)

口語訳すると:

* アクセス・ログのファイルを読み込む。
* 1行をカラムごとに分解する。
* bakagaiku.rbをGETするものだけを取り出す。
* リファラのないものを消す。
* ハッシュを作る。そのキーはbakaidで値は配列。配列にはリファラが入っている。
* ハッシュを適当に印字する。

前にもここで書いたが、自分は、こうやって
ループを何回も回すやり方が好みだ。
それぞれの関数が単機能で、テストがやりやすい。
もちろん、これは以前、nakadaさんにも
ツッコまれたが、ブロックを受け取ることで
ループを減らすこともできる。が、それは
とりあえず後回し。

まず行を分解するテストを書く:

class BakarefTest < Test::Unit::TestCase
  def setup
    @target = Bakaref.new
  end

  def test_split_line
    input = '999.999.999.999 - - [28/May/2006:06:35:05 -0400] "GET /~tko/cgi-bin/bakagaiku.rb HTTP/1.1" 200 2851 "http://www.rubyist.net/~kazu/samidare/" "Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.0; .NET CLR 1.0.3705; .NET CLR 1.1.4322; Sleipnir 1.66)"'
    expecteds = [
      999.999.999.999',
      '',
      '',
      '28/May/2006:06:35:05 -0400',
      'GET /~tko/cgi-bin/bakagaiku.rb HTTP/1.1',
      '200',
      '2851',
      'http://www.rubyist.net/~kazu/samidare/',
      'Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.0; .NET CLR 1.0.3705; .NET CLR 1.1.4322; Sleipnir 1.66)'
    ]
    actuals = @target.split_line(input)
    assert_equal(expecteds, actuals)
  end

そしてモデル・コード:

class Bakaref
  def split_line(line)
    results = []
    StringIO.open(line) do |input|
      while (c = input.getc)
        next if /\s/ =~ c.chr
        input.ungetc(c)
        results << case c
                   when ?[
                     read_brackets(input)
                   when ?"
                     read_dquotes(input)
                   else
                     read_token(input)
                   end
      end
      return results
    end
  end

  def read_brackets(input)
    return read_pair(input, ?[, ?], "not bracket")
  end
  private :read_brackets

  def read_dquotes(input)
    return read_pair(input, ?", ?", "not double quote")
  end
  private :read_dquotes

  def read_pair(input, start_char, end_char, err_message)
    result = ''
    c = input.getc
    raise err_message if c != start_char
    while (c = input.getc)
      break if c == end_char
      result << c.chr
    end
    return '' if result == '-'
    return result
  end
  private :read_pair

  def read_token(input)
    result = ''
    while (c = input.getc)
      break if /\s/ =~ c.chr
      result << c.chr
    end
    return '' if result == '-'
    return result
  end
  private :read_token

もちろん、いきなりこのコードにたどり
着いたわけではない。read_pairも
リファクタリングして生まれたものだ。

続いて、filter_bakagaiku!のテスト:

  def test_filter_bakagaiku
    lines = IO.readlines('access.log')
    actuals = lines.map{|line| @target.split_line(line)}
    @target.filter_bakagaiku!(actuals)
    actual_str = ''
    StringIO.open(actual_str, 'w'){|output| PP.pp(actuals, output)}
    assert_equal(File.read('filter_bakagaiku.exp'), actual_str)
  end

これも実は『あと出し』で、最初は:

  def test_filter_bakagaiku
    lines = IO.readlines('access.log')
    actuals = lines.map{|line| @target.split_line(line)}
    @target.filter_bakagaiku!(actuals)
    actual_str = ''
    File.open('filter_bakagaiku.exp', 'w'){|output| PP.pp(actuals, output)}
    StringIO.open(actual_str, 'w'){|output| PP.pp(actuals, output)}
    assert_equal(File.read('filter_bakagaiku.exp'), actual_str)
  end

とやってモデル・コードの出力をファイルに
落とし、それを目で確認している。

こういうあと出しをするのは、データを
作るのがメンドイから。

で、filter_bakagaiku!の実装:

  def filter_bakagaiku!(arrays)
    arrays.delete_if{|array| /bakagaiku\.rb/ !~ array[4]}
  end

続けて、filter_referer!のテストと実装:

  def test_collect_bakaids
    lines = IO.readlines('access.log')
    actuals = lines.map{|line| @target.split_line(line)}
    @target.filter_bakagaiku!(actuals)
    @target.filter_referer!(actuals)
    actuals = @target.collect_bakaids(actuals)
    actual_str = ''
    StringIO.open(actual_str, 'w'){|output| PP.pp(actuals, output)}
    assert_equal(File.read('collect_bakaids.exp'), actual_str)
  end

  def filter_referer!(arrays)
    arrays.delete_if{|array| array[7].empty?}
  end

とりあえず、ここまで。

考察。単純なTODOリストだけでは、ほんとに
目前のTODOしか思い浮かばないときが
往々にしてある。それではあまりにも
見通しが悪い。やはり全体を見渡す必要が
ある。その場合には疑似コードなり、
他の分析手法、たとえばCRCカードやUMLを
使うのも有効だろう。もちろん、その
分析はラフで構わないし、むしろ分析に
時間をかけるのではTDDではない。

『あと出し』やPPを使って目で確認する
といったこが、自分のよくいう『テストに
王道なし』ということ。ただし、目で確認
するのは一度で十分だ。

本家Permlink


2006年06月07日

お金の価値が相対的に下がってるんだよな。
もちろん、自分らの目的はお金をたくさん稼ぐ
ことなんだけど。ああ、誤解のないように
いっておくと、お金を稼ぐのは企業人として
当たり前で、それを社会的な価値観から逸脱
しないように注意する必要はあるんだけど。

で、お金の価値が下がってるってことは、他の
価値が上がってるわけだ。そう、たとえば時間だ。
だから、わずかなお金を節約するために時間を
費すことは、今の価値観に合ってない
ってことになる。

帰るときPCの電源を落とす。それは節電と
いわれる行為だ。でも、それで明日の朝、
時間がわずかでも失われる。両者を天秤に
かけたとき、どっちのほうが痛いかっていう
話だ。

本家Permlink


2006年06月06日1

いや、mapもcollectも使わないよ派という
のもあっていいんじゃないか。each派。

--

遅れを取り戻そうとするんじゃない。
リズムを取り戻すんだ。

--

リズムがなければ、どんなに飛ばしても
すぐに失速する。リズム、リズム、リズム!

--

コードとニラメッコするくらいなら
システムに聞け。

デバッガもあるし、ログを吐き出させる
こともできるじゃないか。

本家Permlink


2006年06月06日

ruby 1.8.4のio.cで、インデントにタブが
使われてる箇所があります。オケ?

本家Permlink


2006年06月05日

``war''、これ何て読みます?
『うぉー』ですよね。戦争のウォー。

じゃあ、``warning''は? (笑)

--

『つまんない仕事』っていうのは、言い替えれば、
『働きがいのない仕事』っていうことです。

たとえばの話、もし時給でお金をもらっている
なら、別に『働きがい』がなくっても、
それなりにその場に座っていればお金は
もらえるわけです。
でも、たとえ時給でなくっても、
そういう昼行灯みたいなことは自分は
やりたくないんです。

前にも書きましたけど、大野さんが
『徹底したムダの排除』を訴えているのは、
経営上の視点だけではなく、働きがいを
高めるためでもあるんです。それを単純に
『Slackをなくす』と誤解しないように。

--

ふと、カープの猛練習好きの体質が
日本人の残業好きの体質と似てるんじゃないか
と思った。

--

結局、みんなのふつうのレベルを上げるしか
ないんじゃないかな。それも無理なく、
自然に。

そして、ふつうの人が新しく入ってきても
その『ふつうのレベル』にまで無理なく、
自然に引っぱり上げられるようにする。

まぁ、上に書いたカープの話じゃないけど、
日本の『ふつう』というのは、ある程度
勤勉とかいう意味が含まれたりしますけど (笑)。


たとえば、同僚に『この本面白いよ』と
いって『達人プログラマー』かなんかを
勧めたとしますよね。これって時間外労働を
奨励していることになる? それはちょっと
常識的じゃないですよね。こういう交流は
大事だし、また『勧められたんだから
読んでみようか』って思う向上心も大事
でしょう。だから、そういう交流や向上心が
『ふつう』に存在するくらいのレベルまで、
それができたらまた次の『ふつう』のレベル
までみんなの意識を高めていこうということ。

--

コンパイルという作業は、ユニット・テストに
似ている。

警告はテストの失敗。だから、コンパイルは
終わりまで実行される。コンパイル・
エラーはエラー。だからコンパイルが
途中で止まる。

だから、警告でもエラーでも、信号は
赤。何も出なくなってはじめて青。

これもユニット・テストと同じで、
ただ青にすればいいというのじゃ
十分じゃない。コピペでもテストは
通すことができるんだから。テストの
意図を汲みつつ信号を青にすることが
大切。
だから、単純に警告をなくせばいい
っていう問題じゃなくって、
リファクタリングを心のどこかに
留めておきながら、警告をなくす。

本家Permlink


2006年06月04日

Debian sidで:

  X上のbashでアルファベット1文字しか
  含まれていないファイルをcatすると
  何も印字されない。
  ただし、PS1で色を変えてる場合。

という、やたらビミョーなバグが。
xterm, krxvtで現象を確認。Xを落として
仮想コンソールで試すと正しく印字される。
Xに戻って:

PS1='$ '

とやっても正しく印字される。

krxvt上で、ssh -Xでsargeのマシンに
ログインした場合も正しく印字される。

bashに戻した途端、これかよ! (笑)。

本家Permlink


2006年06月03日

へー、rubyってテケトーな拡張子の
スクリプトはrequireとかloadとか
できなかったのか。

あ、ゴメン。loadはOKだった。

本家Permlink


2006年06月02日

ぐえ。ukaiさんもGoogleかよ。

--

オレがほしいと思ってるのは顧客の視点なわけ。
ストーリーっていうのは、顧客にとって価値の
あるものなわけ。
だから、分析とか設計とかをスケジュールに
入れたくないわけ。そんなもんは顧客にとって
何の価値もないわけ。
顧客にとって価値のあるものってのは、
ぶっちゃけていえば、ゼニになるものなわけ。
売れるものなわけ。それがEconomyってこと
なわけ。

そういう『顧客がほしいもの』を機能って
呼ぶのかもしんないけど、機能っていう言葉
でさえ開発側の言葉なわけ。あなたが顧客役を
やるんなら、そういう言葉で考えるなと
いいたいわけ。

もっと価値指向、価値セントリックに
なんなきゃダメだ。自分らのコードの
一行一行が顧客にとっての価値を生み出す
んだということを強く意識してもらいたい。

--

ああ、いつものように、四角四面に
いってることを取らないように。

バグとか大きなリファクタリングとかを
ストーリーとして入れることはあるだろう。
でも、それは例外。

--

こないだも書いたけど、
「彼はカリスマだから」
で済ますのは思考停止なわけ。
オレはカリスマにはなれないけど、
カリスマのテクニックは学べるわけ。

カリスマっていうのは強みでもあるし
弱みでもあるわけ。カリスマがバスで
轢かれたらどうするよ?
だから、みんながカリスマの手口を
学んでおく必要があるわけ。
だいたい、自分らはordinary people
なんだから、学ぶしかないわけ。

--

いや、しかし、ほんとにオレは
カリスマにはなれないんだよな (笑)。
人望のなさは群を抜いてる (笑)。
こればっかりはいかんともしがたい (笑)。
いや、ほんとに笑うしかない。

本家Permlink


2006年06月01日1

いや、ほんとにいいたいことは『コンパイラの
警告をなくしましょう』っていうことじゃない
んだ。

コンパイラの警告を無視するようなヤツが
コンパイラ言語を使う資格があるのか
っていう根深いとこを問いたいわけ。

だからオレは途方に暮れるわけ。これで
excellentを目指せるのか?と。

だから、C/C++よりもLisp使いましょうって
いってるのは、半ば本気なわけ。Lispが
ダメだっていうんならJavaでもC#でもいい
から、そういうもうちょっと親切な言語を
使ったほうがいい。

だから、コンパイラはオプティマイザじゃ
ないんだと。大体、コンパイラの意義を
わかってないヤツがC/C++で書いたって
JavaやC#で書くよりスピードの出る
プログラムなんか書けるわけがない。

ああ、もちろん、これはただのグチだ。
すぐにどうこうできる問題じゃない。
それはわかってるんだ。

--

ああ、いっとくけど、オレがこっちを
選んだのは、上みたいなことで
悩みたかったからだから (ニヤリ)。

だから、あんまり深刻に受け取らないように (笑)。

--

XPE2でちょくちょく出てくる言葉に
accountabilityというのがあります。
『説明責任』と訳されることが多いん
ですけど。要は、自分のやっている
ことをはっきりと説明できることと
いった意味でしょう。

  Dictating practices to a team destroys trust and creates resentment.
  Executives can encourage team responsibility and accountability. Whether
  the team produces these with XP, a better waterfall, or utter chaos is up
  to them. Using XP, teams can produce dramatic improvements in the
  areas of defects, estimation, and productivity. The price of the improve-
  ment is closer collaboration and engagement with the whole team. Raise
  your expectations for accountability and teamwork, then help the team
  through the inevitable anxiety that comes with change.
  === (Getting Start)

  実践をチームに強要すると、信頼を壊し、恨みを呼ぶ。上層部は、チームに
  責任と説明責任を奨励する。よりよいウォーターフォールが生まれるか、そ
  れともまったくの混沌が生まれるかは、チームがXPとともに責任と説明責任
  を生み出すかにかかっている。XPを使えば、欠陥、見積もり、生産性といっ
  た分野においてチームを劇的に改善できる。改善のために支払われるものは、
  緊密な協調と約束とをチーム全体と交すことだ。そして、あなた (上層部) 
  は、説明責任とチームワークに対する期待度を上げ、変化がもたらす不安か
  らチームを助けだす。

これは上層部がチームに対して
accountabilityを求めるという話です。
でも、プログラマなら顧客に説明
できなきゃいけませんし、管理者
だったら、経営陣に説明できなきゃ
いけません。

何を説明するかといえば、
自分たちがどこに向かおうとしいてて、
今どこにいるのか
ということです。

結局、これは計画ということになります。
XPでは、計画そのものよりも、計画を
立てるという活動を重視します。一回の
計画の精度にこだわない代わりに、
繰り返し計画を見直すことで精度を
上げようとします。

だから、XPは決して無計画じゃありません。
外部と協調する必要がある以上、
accountabilityは必要であり、その拠り所
となるのが計画です。

計画というのは、XPであろうがなかろうが
トップダウンです。大きな絵を描き、それを
小さな絵に切り分けていく。
XPなら、大きな絵は四半期ごとのテーマ
ということになるし、小さな絵はストーリー
ということになります。

そういう計画を立てることで、自分たちが
どこに向かい、今どこにいるかを外部に
説明でき、また自分たちも道を外れて
いないと安心できるのです。

本家Permlink


2006年06月01日

解決するのにカリスマが必要なこともあるが、
技術で解決できることも多い。そして、
あの場面では技術で解決できたはずだ。
つまり、あの会議を有益なものにできなかった
のは、カリスマが不在だったからではなく、
我々が技術的に未熟だったからだ。
その技術というのは単純なことで、
目標を設定すればいいだけのことだった。
会議は決定を下す場であり、であるならば、
『何を決めれば、今日の会議は有益な
ものになるか』という設定をすればいい。

この技術は、カリスマから学んだ (笑)。

その決定は、その会議が設計をする場なのか、
それとも見積もりをする場なのかによって
大きく変わる。そこをはっきりさせなかったのも
敗因の1つではある。

ただし、設計、見積もりのいずれを議題に
するにしても、その結果はストーリーに
砕かれなければならない。なぜなら、
ストーリーこそが我々の燃料だからだ。

ちなみに、オレはブレストといわれるものが
大嫌いだ。そういうのはshared mealや
coffee breakでやったほうが効果的だ。

本家Permlink


Copyright © 1905 tko at jitu.org

バカが征く on Rails