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年08月30日

教えていただいた:

 $ :> a.file

でファイルを空にするってヤツですけど、なんすか、これ?

bashのinfoには:

`:    (a colon)'
          : [ARGUMENTS]
     Do nothing beyond expanding ARGUMENTS and performing redirections.
     The return status is zero.

って書いてあるんですけど、何をするためのものなのか
サッパリわかりません。

本家Permlink


2006年08月29日1

昨日の話の続きだけどさ。一言語の一機能を取り上げて、
それが大規模に向いてるかどうかなんて、話が幼稚
すぎるよな。そもそも大規模の問題を技術でどうこう
しようっていうのが危い発想だってことにイーカゲン
気づけっていうの。

いや、大規模開発に有用な技術の発展を自分も望まない
わけじゃないけどさ。でも、規模が大きくなる、人が
増える、コード行が増える、そういうのって技術の
問題より人間の問題を解決するほうが先じゃん。

だからオレはさ、言語を選ぶとき、pragmaticな理由の
ほうが好きなわけ。好きっていうか、納得できる。型が
どうとかなんかより、『Javaのほうが人集められる
でしょ』とか、そういうミモフタもない理由のほうが。

逆をいえば、『頭のいい人を集めたいならLisperを
雇え』っていう、P.Graham氏の意見もpragmaticなわけ。
だって、現実にそうだから。Javaプログラマの中から
頭いい人を探すのは大変だけど、Lisperの中から頭いい
人を探すのはそんなに難しくない。そのLisperでビジネス
できるかっていうのは置いといて、『頭のいい人を雇う』
っていう目的には近いわけ。

だから、もっと現実的に考えろっつの。

本家Permlink


2006年08月29日

http://research.sun.com/self/release_4.3/release.html

IntelMacで動くってさ。オレにはカンケーネーけど。

本家Permlink


2006年08月28日

~$ echo hello, world >hello
~$ ls -l hello
-rw-r--r-- 1 mcd mcd 13 Aug 28 19:24 hello
~$ cp /dev/null hello
~$ ls -l hello
-rw-r--r-- 1 mcd mcd 0 Aug 28 19:25 hello

勉強になりました。

$ cat /dev/null >hello

でもいいみたい。

--

ライブラリアンを置くっていうのは前からいわれてる
案の1つなんですけど。

自分は、これにはかなり否定的です。多分、『変わった』と
いえるほど変わることはないんじゃないでしょうか。

自分の根拠は『インフラには投資しない』というXPの
方針です。

ライブラリやフレームワークというのは、予言者が
作るのではなく、当事者が何度も同じドメインの仕事を
していく中で、自然とできあがるのが理想的です。

インフラに先行投資してしまうと、宇宙飛行士症候群に
陥る可能性が高くなります。それとほぼ同じ意味ですが、
不必要な機能が盛り込まれる可能性も高くなります。

もちろん、フレームワークにしろ、言語にしろ、
『物知り博士』のような存在がいれば心強いことでしょう。
でも、そういう人物の登場を待てるほどノンビリ仕事は
できないでしょう。

これは規模とは関係のない話です。規模が大きくなれば、
複数のチームに分けることになりますが、そのときも
機能を中心に考えて分けます:

http://capsctrl.que.jp/kdmsnr/wiki/bliki/?cmd=view&p=FunctionalStaffOrganization&key=%A5%C1%A1%BC%A5%E0

階層という横割りではなく、機能という縦割りでチームを
分けるということです。

ここでいう機能というのがちょっとわかりにくいかも
しれません。これは、ストーリー・カードのような
ユーザに近い要件を最初から最後まですべて実現した
ものという意味と自分は捉えています。そうなると、
階層で分けることはできません。階層で分けても、
ストーリーは実現できませんから。

--

http://www.artima.com/forums/flat.jsp?forum=270&thread=173574

一理あるようで、でもちょっと考えたらウソ臭い話やな。

この程度の落とし穴、C++だったらいくらでもあるし。
それでもC++で大規模開発やってるとこはたくさんあるし。

まぁ、『既存のクラスに新しいメソッドを追加しないこと』
とかいうローカル・ルールを設けることは意味がある
かもしんないけど。でも、それって規模とは関係ない話に
思える。どっちかっつーとチームの習熟度の度合いの
話で。大規模開発だと習熟度が落ちるっていうのが
前提なのかいな。大規模になれば習熟度にバラつきが
出るのは予想できることだけど、だからって上のヤツが
下のヤツに合わせるってのもおかしな話じゃん、ねぇ。

だったら、『危険だから』っていう理由でJavaに導入
される予定のクロージャも禁止にするの? 『複雑すぎる』
っていう理由でC++のテンプレートも禁止にするの?
それとも、演算子多重定義は禁止する?

この手の話って、大規模大規模ゆーてるわりには大規模
っちゅーもんが見えてこないんだよな。まるで『大規模』
っていう名前の人間であるかのような話し方をする。
ほんとに大規模開発やって、それでもって苦労したとか
いう話なら、こっちも真剣に耳を傾けるけど、想像上の
話だけじゃ説得力がちっともない。そういうのは動的
言語蔑視とおんなじ類のヨタだよな。

本家Permlink


2006年08月27日

そう、ファイルを切り詰めるコマンドがないのが不思議
なんですよね。切り詰めるっていうか、ファイルを空に
するコマンドなんですけど。

#include <cstdio>
#include <cstdlib>
#include <sys/types.h>
#include <unistd.h>

static const char* progname;

static void
print_usage()
{
    fprintf(stderr, "usage: %s FILENAME\n", progname);
    exit(1);
}

int
main(int argc, char* argv[])
{
    progname = argv[0];
    if (argc <= 1) print_usage();
    if (truncate(argv[1], 0) == -1) {
        perror(argv[1]);
        exit(1);
    }
    return 0;
}

なぜかC++。前はシェル・スクリプト書いてて、それは:

rm -f $1
touch $1

でした。

--

そういえば、$HOME/binでバイナリなのはこれが初めてだなぁ。
他は.shか.rbばっかり。まぁ、ほとんど使わないんですけど。

一番使うのは、ここの記事をアップするヤツ。

自前のスクリプトだと、他はcronで動くバックアップ・
スクリプトかな。

あと、たまにrubyのヘッドをビルドするヤツとか。

--

あれ? 後藤大地って人、結構前からいる人で、ヘンな
ことは書かない人っていう印象だったんだけどな。

Javaのせいでクロージャが騒がれてるわけだけど、
そんなにむつかしい話? クロージャでむつかしいとこが
あるとしたら、環境をキャプチャしちゃうとこでしょ?
それって、そんなにむつかしい話には思えないけど。

オレは、Javaにクロージャ入れるのは気に入らないな。
だって、内部クラスとかあるじゃん? あれって、
クロージャに対するJava側の回答だと思ってたからさ。
実際、制約があるとはいえ、環境をキャプチャするしさ。
それなのにわざわざクロージャ入れるってことは、
無名クラスはダメでしたってバラしてるようなもんでしょ。

オレ、また何か勘違いしてる? まぁ、細かいとこ
全然見てないから勘違いしてるかもしんないけど。

--

GnuスタイルのCコードのスライドを見るのははじめてかも。

本家Permlink


2006年08月26日

あれ? それってPythonに限った話じゃないような。

"a"と"a+"はO_APPENDで、これが立つと書き込みは必ず末尾になる。だから、
書き込むときにlseekとかしてもムダ。

"w+"は読み込めるけど最初にファイルを空にしちゃう (なければ作
る)。

そういう意味じゃ、まともに読み書きできるは"r+"くらいなのか。

--

今、たまたまAPUE読んでまして (笑)。さとるさんのブログ読んで、もう一度
チャレンジしてみようと。そう、何回か途中で挫折してます (笑)。

本家Permlink


2006年08月25日


本家Permlink


2006年08月24日

Pull Up Method、つまり、メソッドをスーパークラスに
引き上げるリファクタリングっていうのは、OOPでは
よくあること。よくあることなんだけど、実はあんまり
うれしくない。

なぜなら責任が集中しちゃうから。責任の分配、分散
っていうのは、OOPではもっとも大切な設計活動の1つ。
だから、Pull Up Methodをやるハメになったら、悪い
設計になりつつある兆候ではないかと疑ってみる。

Pull Up Methodで集中しちゃった責任を分配するには、
オブジェクトを切り出す。たとえばStrategyとかが
使えないか考えてみる。

--

自分はデザイン・パターンを積極的に肯定はしないんだけど、
その例外がスレッド・プログラミング。

スレッド・プログラミングっていうのは型にハメないと
危いっていうのがある。それと、他の一般的なデザイン・
パターンと比べると、アプリケーション・ドメインに
影響されにくく、純粋な形のまま適用できることが多い。

--

オシム特集ということで、大嫌いな『Number』を買う。

で、オレはみんなに問いたい。日本というordinaryな
選手の多いチームが、ワールドカップでベスト4あたりに
まで行くことがそんなにバカげた話なのかと。

予選リーグを2勝1敗くらいでで通過して、決勝
トーナメントで2勝するのが、不可能だといえるほど
困難なことなのかと。

オレがいってるのは、そういうことだ。ordinaryな
開発メンバでGoogleに勝つ。リーグ戦では負けるかも
しれないが、一発勝負のトーナメントなら可能性は
十分あるし、その一発だけで十分だ。

Googleは確かに強い。でも、日本がGoogleのマネなんか
したって勝てるわけがない。米国という人材に恵まれた
場所で、さらに優秀な人間を集めるというその戦術を、
この日本で展開できるわけがない。

ordinaryで何が悪い。ordinaryは強みだ。いや、強みに
しなきゃいけないんだ。ordinaryな能力と、不屈の闘争心が
あれば、Googleを越えられるはずだ。

もしオレのいってることが間違いだっていうんなら、
日本代表なんか応援する意味がないし、通を気取って
セリエAとかリーガ・エスパニョーラでも見てろってんだ。
クソッタレガ。

本家Permlink


2006年08月23日

ああ、またまたゴメンナサイ。

昨日のスマート・ポインタの話で:

obj;

っていう式の値の型はT*なんじゃないの?って書きました
けど、これは間違い。これはやっぱりSmartPointer<Object>。

で、なんで:

if (obj) ...

がゼロになり得るかというと、条件式はゼロとの比較
だから。

ゼロと比較したとき、objの予想できる型としては
SmartPointer<Object>と、多重定義したObject*の2つが
あるんだけど、Object*のほうが妥当で、だから型変換が
起こると。

以上、識者の意見の受け売りでございました。

--

一応追試。

まず、演算子多重定義でデフォルト引数は取れないらしい。

で、次のようなコードを書いてみた:

#include <iostream>

using namespace std;

class Mine {
public:
    bool operator==(bool b) const {
        return true;
    }
};

int
main()
{
    Mine mine;

    if (mine) cout << "true" << endl;
    return 0;
}

これでoperator==が発動する目論見だったんだけど、
結果はコンパイル・エラー:

$ g++-4.1 -Wall cc.cc
cc.cc: In function 'int main()':
cc.cc:17: error: could not convert 'mine' to 'bool'

つまり、条件式の中でオブジェクトが単独であっても、
そのoperator==は呼び出されることはない。

もちろん:

    if (mine == true) cout << "true" << endl;

と書き換えればコンパイルできる。

さらに:

#include <iostream>

using namespace std;

class Mine {
public:
    operator bool() {
        return true;
    }
};

int
main()
{
    Mine mine;

    if (mine) cout << "true" << endl;
    return 0;
}

のように型変換演算子を定義すれば、問題なくコンパイル
できる。

ちなみに:

#include <iostream>

using namespace std;

class Mine {
public:
    operator bool() {
        cout << "bool";
        return true;
    }

    operator int() {
        cout << "int";
        return 1;
    }

    operator int*() {
        cout << "int*";
        return (int*)1;
    }
};

int
main()
{
    Mine mine;

    if (mine) cout << endl;
    return 0;
}

上のエラー・メッセージから予想できたことだけど、
このときはbool()が走る。

あ、つまり、正しくはゼロとの比較ではなく、
falseとの比較ということか?

本家Permlink


2006年08月22日

あははは。我田引水すぎました。ごめんなさい。

『法律からいったら教えちゃいけないんだけど
教えちゃったのよ、それは下請けのスキルが低いから
なのよ』っていうのが会長の言い分なわけですね。

ガキの言い訳じゃないんだから。

まぁ、2次請負が常駐してて、それに指導しちゃいけないっ
ていう法律のほうがおかしい気がするけど。でも、
『だったら雇え、雇って2次請負をなくせ』っていうのが
法律の言い分なわけですか。

http://itpro.nikkeibp.co.jp/article/Watcher/20060307/231853/

  それを防ぐためには少なくとも、開発するシステムだけでなく、仕事自体の
  コンポーネント化、モジュール化が出来ていなければならない。

こっちも自分同様にズレてますね。そんなものができる
くれーなら苦労しない。オフショアにしたってオンサイトや
なんだで密なコミュニケーションが必要で、それは要は
『指導する』ってことだし、それをやっちゃいけねーって
いってるのが法律なわけなんだから。

--

やっぱりC++は奥が深い、いや、深すぎます。

演算子多重定義による暗黙の型変換なんて、全然
知りませんでした。

スマート・ポインタを使ったコードで:

SmartPointer<Object> obj;

...

if (obj) ...

みたいなコードがあって、何が起こってるのか全然
わかりませんでした。『pがゼロになることなんて
あるの?』っていう疑問。

『==演算子の多重定義が暗黙裏に呼び出されてんの?』
とも思ったんですけど、だとしたら引数がなきゃおかしい。
じゃあ、デフォルト引数でも指定しているのかと思ったら、
たまたまデバッガで:

operator T*() { return p; }

が呼び出されてるのがわかったんですけど、今度は
『何これ? 何の演算子?』。

家に帰って『プログラミング言語C++』読んでも、
それらしい記述がなくって、『More Effective C++』
読んで、ようやく理解しました。いや、理解したと
いうより、『そういうものか』という、なんだか
釈然としない気持ちにしかなれませんでしたけど。

結局のところ、暗黙の型変換演算子が多重定義されてる
場合、上のコードでいえば:

  obj;

という式があったとして、その式の値の型はObject*
であるということなんですかね。だから、if文の中の
条件式でも、その型はObject*であり、値は型変換された
ものであると。

まぁ、暗黙の型変換演算子の多重定義なんて、パンピー
には全然関係ない話なんですけど。でも、上みたく
字面だけ見て『なにこれ?』って思っちゃうんですよね。
そう思っちゃったら調べるしかないわけで。だから、
やっぱりC++は奥が深すぎるっつーか。

--

まぁ、Rubyでもそういうことはありますけどね。コード
見ても何やってるかさっぱりわからんときが。

--

『More Effective C++』をチラチラ見てたら『未来形で
プログラムする』っていうのがありました。

まぁ、完全に否定するわけじゃないんですけど。いくら
YAGNIだっていっても、ある程度の常識はありますから。
標準を遵守するというのもその1つでしょうし。

だから、結局大切なのは、未来形でやるとかYAGNIで
やるとかじゃなくって、諦観することなんですね。
K.Beck氏が『リファクタリング』の中でいってるヤツ。

どんなコードだって良くすることができるんだっていう
自信を持つこと。それを持ってなければYAGNIなんて
いってもムリなわけで。未来形でやるにしたって、
予言者じゃないんだから目論見が外れることだって
あるだろうし、そうしたらやっぱりコードをいじらなきゃ
いけない。

他の人の作業を横で見てて思うんですけど、ほんっとに
みんなコードを触りたがらない。ダッセーコメントとか、
#if 0とか、自分は『そんなもん消しちめーよ』とか
思って見てるんですけど、作業してる人は、ほんとに
それがタブーかのごとく避けるんですよね。まぁ、
実際にやりだしたらキリがないっていう現実もあるん
ですけど。

ああ、黙ってるのは、まだ自分が下っ端だからです。

で、コードを触らないっていうのは、結局は割れ窓を
放っておいてるわけです。で、どんどんコードが荒れて
いく。で、最終的には手の出しようがなくなって、
自分の嫌う『刷新』ってことになっちゃうんです。

だから、諦観を持って、コードをいっつも手入れするのが
大切なんです。まぁ、それってやっぱり未来形なんて
ものを否定してることになっちゃうんですけど。

本家Permlink


2006年08月21日

http://d.hatena.ne.jp/essa/20060818/p2

これ、結局のところ、『ウチは下請けを教育する指導力が
ありません、ゴメンナサイ』っていってるんですよね?

下請けとプロパーを比べたとき、プロパーのほうが
有利なのは、それだけドメインに特化して仕事して
るんだから当たり前ですよね。下請けは、なんでもかん
でもこなさなきゃいけないから、特化なんてできない。

だから、プロパーが下請けを教育する、専門知識を伝える
っていうのは当たり前というか、省くことができない
手間なわけで、それができないっていうんなら
『プロパーやめたら?』っていいたくなります。

こういうところにも、下請けとプロパーとの間に技術力の
差がなくなっていることを感じますね。プロパーが
専門知識を持ってるのは当たり前なんですけど、でも
技術的な知識に関してはそう違いはないし、むしろ
逆転してることも多い。プロパーに技術力がないから、
技術的なことを下請けに教えられない。

もし仮に、プロパーにも専門知識がないというのであれば、
さらに悲惨で、専門知識もないし、技術力もないし、
『あんたのスキルは何なのさ?』『はい、プロジェクト
管理でございます』っていう、ほんとにありがちなオチに
しかなりません。

そういう意味で、essaさんのいうスキル問題はちょっと
違うかなと思います。スキル云々っていうのは、下請けの
スキルが低いってことでしょう。それって高速道路時代には
必ずしも常識じゃないでしょう。

本家Permlink


2006年08月20日

ああそう、_POSIX_SOURCEはデフォで立ってるの。
前は立ってなかったように思うんだけど、勘違いかな。

本家Permlink


2006年08月16日

http://www.nextindex.net/java/index.html

素晴らしいですね。趣味のサイトでこれだけ書かれてるのは
珍しい。話題が幅広いのが目を引きます。

--

http://www.youtube.com/watch?v=pDvdBgJdEzU

アーティストは早死にするべきだ。

もし、死後70年もの間、彼/彼女の作品が公のものにならないのであれば。

ちなみに、B.Marleyが亡くなったのは1981年だそうな。

本家Permlink


2006年08月15日

『ワールド・ボクシング』読んだ。

当然亀田の試合は見てないんだけど。ワーボクの表紙も、
亀田の写真より名城の写真のほうを大きくしている。

ワーボクも観戦記は否定的。でも、そんなに大差がついてた
わけじゃなかったみたいね。ワーボクの他の人の中にも
亀田に軍配を上げてる人もいるし。

ボクシングの判定基準で納得できないのが、最高でも
1ラウンドで3点しか差がつかないこと。しかも、ダウン
させても10-8がフツーで、10-7なんか滅多にない。
ダウンさせて判定になったら無条件で勝ちにすりゃ
いいじゃんと自分なんかは思っちゃうんだけど。

前も書いたけど、跳ねっ返りならクレイジー・キムの
ほうを応援したいし、人間的にはイーグル京和のほうが
数倍上だし、在日とかタイ人とかあるけど、強けりゃ
それでいいのがボクシングだし、リングで金のかかった
小芝居見せられてもうれしくもなんともない。


そういえば、ボクマガも本屋で見かけたけど、確か
亀田がデカデカと表紙で、論調としては否定的だったはず。
日和見のBBMが出す雑誌にしちゃ珍しいことがあるもんだ
と思った。こないだオシムネタに釣られてサカマガを
買っちゃったんだけど、BBMだと知ってスッゲー後悔した。

本家Permlink


2006年08月14日1

そうか、さとるさんとこはコメント入力がないんですね。

ブ厚い本読むコツってあるんですかね? 途中で挫折した
ことが数知れずあるもんで。いや、ブ厚くなくても (笑)。

毎日でもチビチビ読んだほうがいいのか、それとも週末
まとめて読んだほうがいいのか。読むだけでいいのか、
ノートを取ったほうがいいのか。サンプルはゼロから
書き起こすか、それともネットで配られてたりするのを
いじるだけにするか。演習はやったほうがいいのか、
それとも飛ばしてもいいか。

こうやって考えると、時間と理解度のトレードオフな
気がしますね。しっかり理解したければ、時間のかかる
やり方を選ぶしかない感じ。

自分の場合、挫折する原因は、まぁ、飽きちゃうん
ですね (笑)。理解できなくって途中で投げ出すことは
滅多にありません。そういう本は選びませんし。
『アナリシスパターン』と``The Art of Meta-Object
Protocol''は理解できなくって投げ出しましたけど。
でも、MOP本はいつか読み通したいです。

そういえば、XPE2の読みも止まってるなぁ。

写経スタイルだと『心的負担が大きい』っていうのも
あるんですよね (笑)。ほら、PCの前に座らないと
できないから。睡眠薬代わりに読むってわけには
いきませんからね。

本家Permlink


2006年08月14日

『野球小僧』ってTV CMやってたの? TVねーから
全然知らなかったよ。

http://kozo.boxerblog.com/kozo/2006/08/14_1567.html

ナニワのゴジラ、一軍で試合に出たんだね。
早すぎる気がしないでもないけど、まぁ、バファローズだから
しゃーないか。

それにしてもパ・リーグも落ちたもんだな。ルーキー
相手に1球もストレート投げないなんてな。
あ、投げたほうも新人なのか。まぁ、しゃーないか。

本家Permlink


2006年08月13日

などとエラそうなことを書いておきながら、
夏休みはしっかり遊んでしまうワタシなのであった。

いや、ついこないだ『天外魔境2』やっちゃって、
『もう長いゲームはゼッテーやんねー!』って約束した
はずなのに、また『カルチョビット』だもんな。
まぁ、長いゲームだなんて知らずに買っちゃったんだけど。
でも、フレッシュ・リーグでお腹いっぱいって感じ。

このゲーム、GBA、っていうか携帯ゲーム機で出す
意味があんまりないんだよなぁ。結局、PCでパラメータと
ニラメッコしてる時間が長いし。いや、そういう遊び方は
邪道なのかもしんないけど。もっと気軽に『チョビット』な
感じで楽しむべきなのかもしんないけど。でも、
パラメータがあるとわかってて、ノンビリ楽しむ気には
なれねーじゃん?

まぁ、そもそも、サッカーをあんまし知らない自分の
ような人間が手を出していいゲームじゃなかったのかも
なぁ。ダメダメな試合っぷりのチームがトレーニングを
重ねていくにつれて、それなりにサッカーの形になって
いく、その姿を見てカンドーするのがこのゲームの
ネライなんだろうけど。サッカーのことよくしんないから、
『サイドバックが駆け上がってセンタリングして
シュート!』みたいな王道っていうか、パターンを
ほとんど知らないし。そういうのを知らないと試合が
単なるカードを集めるだけの、どうでもいい時間に
なっちゃう (笑)。

でも、いっとくけど、すっごく上質なゲームであるのは
間違いない。シンプルでいて奥が深いし、サッカーを
知っている人ほどハマるんじゃないかと思う。

それと、このゲームのために久々にGBA SPを触ったけど、
やっぱGBA SPはケッサクだね。DSなんてヤボい。GBA SPは
いつまでもなくならないでほしいなぁ。

あ、そういえば、DSでも遊べたんだな、これ。で、
DSに何が差さってるか見てみたら、トルネコ2だった。

本家Permlink


2006年08月11日1

そろそろメジャーになった観のある『中学野球小僧』の
新しいのが出てました。いつもパラパラとめくっていって
目についた記事から読んでいくのですが、今回は
清宮監督へのインタビューで手が止まりました。

清宮克幸氏、サントリー・サンゴリアスの監督と
いうより、早稲田大学ラグビー部の監督だった人と
いったほうが早いかもしれません。

大学監督時代の5年間で大学日本一3度、しかもそれが
低迷していた早稲田というので非常に注目を集めた
監督です。確か本も執筆されてるはずですけど、自分は
読んでません。

わずか数ページですけど、非常に得るものが多かったです。
『中学野球小僧』によるインタビューのいいところは、
非常にストレートなところです。このインタビューは、
『強いチームになるためのスーパー強化策』と題されて
いるんですけど、実際には、指導者による指導方法の
ノウハウです。早稲田のことといった前振りはほとんど
なく、どうやって清宮監督が強いチームを作ったか
というノウハウについてストレートに書かれています。

触りだけ書いとくと、まず一番最初にやるべきは、
チームとしてのミッションを掲げることだといいます。
勝つだけなく、勝ったその先を見据えるということ。
サンゴリアスであれば、『サントリーのラグビーを見て、
「こういうラグビーがしたい!」と子どもたちが思える
ようなスタイルで勝つ』というのがミッションなんだ
そうです。

Googleは『世界の情報を整理し尽す』というのを
ミッションに掲げてたと思うんですけど。そういう
ミッション、使命感、使命意識というのを、もっと
チームといった小さい単位の組織でも持たないと
ダメな気がしました。

このインタビューには、他にも『数値化が大切だ』とか、
興味深いノウハウがあります。立ち読みでもして、気に
なったら買ってみてください。他にも新垣とか今江への
インタビューもありますんで。

--

ソフトウェアはチームの状態を映す鏡という。

つまりだ、あのクソッタレなUIはオレたちがユーザの
ことをちっとも考えてねぇってことを映し出してるんだよ。

それでもって、あのクソッタレなコードは、オレたちが
混乱してるってことを映し出してるんだよ。

あと10倍 (ほんとは3倍じゃなくって10倍らしい (笑))
売らなきゃいけねぇってのにな。まったく危機感がない。

--

だから、オレのミッションの1つは、ordinaryでも
best and birghtestを超えられるってことを証明する
ことだ。それが証明できれば、日本だってまだまだ
やれるってことにもなる。いや、日本だけじゃなくって、
他の国だってできるってことになるじゃないか。

このミッションは自分の個人的なものに過ぎないけど。
でも、そういうバカがチーム内にいるってことを知って
おいてほしいな。

--

くどいようだけど、ordinaryっていうのは、衆愚政策とは
かけ離れたものだからな。みんなで賢くなろうよっていう、
そういうことだから。オレだって全然愚かだけど、バカが
バカのままでいるのは救いがない。バカがバカを抜け出そうと
もがくところに日本的な美しさというものがあるんじゃ
ないか。たとえバカのまま終わったとしても。

本家Permlink


2006年08月11日

なんか、東スポっていうとウソが書いてあると
思われてるみたいなんですけど。

イヤ、確かにUMAの類とか、なくはないですよ?
でも、それって、すぐわかるように書かれてるんですよ、
一応は。

で、そういう『いかにも東スポ』っていうとこ以外は、
ネタが独特なだけで、ウソは書いてませんよ (多分)。

昨日の記事でいえば、『上村愛子ブログ炎上』。
なんでも、モーグルの上村選手がブログで『亀田選手の
試合、感動しました』って書いたら、講義のカキコミが
すごかったとか。

もう1つ昨日の記事でいえば、『「JALが危ない」本が
成田空港で売られていた』。なんでも、『JALが危ない』
っていう本が成田空港の航空博物館で売られていると
という話。

で、東スポは、JALにコメントもらってるんです (笑)。
担当者曰く、『不快感を感じています』。

もちろん、その航空博物館からももらってますけどね。
『JALさんから直接講義が切てるワケではないので・・・』

こういう独特なネタを独自取材するのが東スポらしさ
というかね。だから、ウソが書いてるあるわけじゃ
ないんです。

本家Permlink


2006年08月10日

母子ともに健康でありますように。

なんか最近メチャメチャ忙しいみたいですけど、
できるだけ早く帰ってあげてください (笑)。

(もちろん、オレの話じゃないよ)

--

そうなんだよな。Pythonのプログラムって結構
あるんだよな、地味に。

--

自分がWikiを書くのは、どっちかっつーと、今いる
メンツのためじゃないんですね。今いるメンツは
知ってますから。だから、誰と情報共有したいかと
いえば、『将来新しく入ってくるであろう誰か』
なんです。

これはYAGNI違反というわけじゃなくって、自分が
書くことで自分の理解も深まりますから。

『書くクセ』をつけることが難しいんですよね。
書くことに抵抗を感じる人が少なからずいると。
そういうのは強制的に書かせるようにして、抵抗感を
なくすしかない。

強制的にっていうのは、仕事の中で否応なく使わせると
いうこと。XPだったらストーリーを書くのに使ったりとか。
作業報告書を書かせるとか。毎日のようにWikiを
いじらせると。

もう1つ、『編集するクセ』をつけるのも難しい。
Wikiで『何でも書いていいよ』っていわれて、最初に
書くのは自分だけのためのメモだったりするんですよね。
そういうページだと、なんか編集するのがためらわれちゃう。

そういう場合、まずlots of little piecesにするのから
始めればいい。メモの中のトピックをページとして
どんどん切り出していく。そうして十分細かいピースが
できてきたら、『まとめページ』みたいなものからリンクを
張りまくる。こうすると、いじるほうもいじられるほうも、
そんなにイヤな思いはしません。

結局、編集グセは、自分が小人さんになるしかない。
そういう小人さんの存在が、また新しい小人さんを
生むと信じて。

本家Permlink


2006年08月08日

今日のバカその1。

そこそこCVS使ってたつもりですけど:

$ cvs -n update

ってのは知りませんでした。

だから、cvs statusして``Locally Modified''な
エントリを探すスクリプトを自前で書いてました。

--

今日のバカその2。

Cの構造体にある配列は代入のときにコピーされるって
いうのを知りませんでした。いや、どっかで読んだ
ことはあったかもしれませんけど、全然思い出せません。

#include <assert.h>
#include <string.h>

struct MyStruct {
    char buf[16];
};

int
main(int argc, char *argv[])
{
    struct MyStruct s1 = {"abc"};
    struct MyStruct s2;

    memset(&s2, 0, sizeof(s2));
    s2 = s1;
    assert(s1.buf != s2.buf);
    assert(!strcmp(s1.buf, s2.buf));
    return 0;
}

これは有名な話らしくて:

http://www.st.rim.or.jp/~phinloda/cqa/cqa14.html

にも出てくる話です (【配列1つだけを含む構造体】)。

--

TDDっていうのは、トップダウン・アプローチとかボトム
アップ・アプローチなんかと同列に語られるべきものです。
つまり、プログラムの作り方についての話なんです。

だから、TDDを品質という枠でくくるのは、ちょっと
誤解を生みます。

だから、TDDの効果で自分がまっ先にあげるのは『自信を
持てる』っていうことなんですね。あとは『リズムが
良くなる』とか。品質とかは二の次、三の次。

『自信が持てる』っていうのは、それまでやってきたことが
形として残っているということ。しかも動くコードとして。
その安心感が自信を生みます。『リズムが良くなる』って
いうのは、テスト・コード、モデル・コード、リファクタリング
っていうサイクルを素早く回すことで得られる疾走感
みたいなもの。こういう疾走感がないと、なかなか大量に
コードを書くことはできません。

TDDを導入するきっかけとして『品質が上がる』って
いうのは、それはそれでいいと思うんですけど。でも、
いつまでの品質を上げるためだけにTDDをやってるんじゃ、
それは多分TDDじゃないでしょう。

ああ、ちなみに、ここでいってる品質というのは、
例によって『バグが少ない』とかそういう単純な意味での
品質です。ユーザ体験とかは含みません。

--

ああ、オシムみたいなシステムはもう存在してたのね。
ガッカリ。

http://s1.muryo-de.etowns.net/~ponce/

本家Permlink


2006年08月07日

あははは。あれ公開したらサーバがパンクするかと
心配したんですけど、全然杞憂でした。ま、そんな
もんですか。

あのゲーム、メタファーとしてはポーカーみたいな
感じなんですよね。手札から合計値の高い役を選び
出す感じ。

--

http://d.hatena.ne.jp/squeaker/20060805#p2

W.Cunningham氏とペア・プログラミングできるなんて、
なんともうらやましい話です。

ペア・プログラミングっていうのは、まさに相棒との
対話なんですね。話すことでお互いに理解が深まる。

慣れてない人は、言葉にするのがまどろっしく感じる
かもしれませんけど、言葉にすることで考えがより
はっきりします。これは『電話デバッグ』とか『ゴムの
アヒルちゃん』とかにも通じる話です。

一方、話を聞くほうも、対話がよりスムースに流れる
ように注意しないといけません。ボンヤリと聞き流す
なんてもってのほか。って、これ、よくやっちゃうん
ですけど (笑)。

だから、ペア・プログラミングっていうのは、教える/
教わるっていう関係とはやっぱりちょっと違うんですね。
もちろん、知識レベルに差があるときはそういう師弟
関係みたいになっちゃいますけど、別に知識レベルに
差がなくったってペア・プログラミングは有効なんです
から。

http://d.hatena.ne.jp/squeaker/20060804#p1

こっちのほうは、ちょっと難しめ?

  ただ、単純にフェンスを建てておくだけではなくて、システムのほかの部分
  にも影響するようなコード変更が起こったときに、関係するオブジェクトた
  ちにもちゃんと通知されて、人間が問題を解決するようにして、「変化に強
  いシステム」を目指すべきだとも。

『見える化』みたいな話なんですかね? 変化を目に
見えるようにして、人間が解決しやすくする?
CVSのようにコンフリクトを人間任せにするとか、
そういう感じ? 違うかな。

本家Permlink


2006年08月06日

Osim

本家Permlink


2006年08月04日1

この高速道路の時代に便利屋やるのか?
便利屋なんて、それこそ吐いて捨てるゲロくらい
いるんだぜ?

将棋の羽生さんが教えてくれたヒントをもう一回
思い出してみろよ。

  『この型だったら、あの人の意見を聞けば大丈夫』って
  いう人を見つけること。

っていってたろ?

間違うなよ。オレがいってるのは、

  「あの人」を見つけろ

っていってんじゃなくって、

  「あの人」になれ

っていってんだよ。だって、そっちのほうがまだ勝目が
あるだろうよ。

Googleみたいなとことオールラウンダーで勝負するほうが
バカだろ? 違うか? 一発カマすためには、相手の裏を
かかなきゃダメだろ。

--

自信はいいリズムを生む鍵となります。残りを片づけ
られるっていう自信があれば、早く帰ることができます。
早く帰れば、また次の日元気に仕事できます。自分の
設計に自信があれば、それをはっきりと説明することが
できます。はっきりとした説明があれば、顧客も安心して
ビジネスに集中できます。そういった具合に、自信と
いうのはいい循環を生むために大切なものです。

でも、誰だって自信のなくなるときはあります。そんな
ときどうすればいいんでしょうか。そんなときは、
なけなしの勇気を振り絞るしかありません。

そう勇気。勇気はXPの4つの価値の1つです。ほんの
ちょっとの勇気を出して、やってみて、結果を出す。
結果が出れば自信が湧きます。つまり、勇気が自信に
変わったことになります。そして、その自信をもとに、
またほんのちょっと勇気を出してみる。その繰り返しで
自信を確かなものにしていきます。

スポーツ選手なんかはよく『豊富な練習量が自信の裏づけに
なっている』なんていいます。スポーツ選手は練習するのが
仕事みたいなところがありますけど、自分らは違います。
自分らは毎日が試合のようなものです。ならば、毎日の
仕事の中から学ぶことが大切でしょう。就業時間外の
勉強もいいですけど、まず仕事の中から学ぶのが基本です。
だから、仕事の中で学ぶ機会に目を光らせとかないと
いけません。機会 (Opportunity) は、XPE2の原則の
1つです。

勇気と学習、この2つで自信を得る。これは言い替えれば、
未知なものに挑戦するっていうことです。未知なものに
挑むときは勇気が必要です。未知を既知に変えるのが
学ぶということです。そして、勇気と学習が混ざり合った
ものが好奇心と呼ばれます。

--

前にも書きましたけど、重量級からの反動でか、どうも
ドキュメントを軽視しすぎる傾向があるんじゃないかと
感じています。

ただ、自分がほしいドキュメントっていうのは、仕様書
なんかじゃなくって、チュートリアルだったり、高い
視点から見た俯瞰図だったりします。これは、新しい
人が入ったときに、システムを学ぶのに役立つものです。

だから、いわゆるUMLなんかとは違います。あれは
コードみたいなもんで、学習にはそれほど効果は
ありません。

仕様書、あるいはストーリーにしても、それを読んで
具体的なイメージが湧くものでないと意味がありません。
これはJoel氏が書いていたことに影響されました。
無味乾燥なドキュメントほど読んでて苦痛なものは
ありません。読まれないドキュメントなら、書かない
ほうがマシ、っていうか書いちゃダメでしょう。

そういう『読まれない大量のドキュメント』を書かせる
プロジェクトにいたことはありますけど、自分は全然
役立たずでした (笑)。
まぁ、自分には向いてないです。

本家Permlink


2006年08月04日

オレたちがなんで『ドキュメントはなるべく書かない』で
済んでるか考えたことあるか?

コードとテスト、それにWikiがあるからか?

違うだろ。本質はそんなとこにあるんじゃない。

オレたちは、4つの価値の1つであるCommunicationを
重んじているからであり、なおかつそのCommunicationは、
何よりも生の、人と人との直接的な触れ合いを意味
してるからだろ。

だったら、教えることの手間をイヤがるんじゃない。

仮に、教えることで自分の作業が遅れるとしてだ。誰が
それを責めるっていうんだ? 誰も責めやしない。

もし教える手間をイヤがるんなら、ドキュメントを
イヤだろうが何だろうがドッサリ書くべきだ。だって
そうだろ? どんな形であれ、プロジェクトにとって
Communication、つまり情報がそこに存在し、流れている
っていうことはもっとも大事なことだからだ。しかも、
オレたちのプロジェクトは大規模開発といわれる部類の
ものだしな。

何度もここで書いてるけど、Learn Teachingはとっても
大切なことなんだ。プログラマはすべからく教えるのが
上手くなければならない。だから、教えることで教える
ことを学ぶんだ。それがXPが期待しているプログラマ像の
一面ということだ。

本家Permlink


2006年08月02日

やっぱグチって書いても空しいよな (笑)。

というわけでネタを。といっても、これも獲物の
ほうで紹介済みなんだけど:

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

今見たら、さらにこれ関係のが増えてた:

http://radar.oreilly.com/archives/2006/08/programming_language_trends.html

RubyのほうはRailsブームみたいなもんだから、いつまで
続くかちょっとわかりませんよね。日本でも一時期
Ruby本のラッシュがあったんですけど、そのラッシュの
反動で、Railsブームが来るまでは、少なくとも本に
関しては、低迷してたっていう例もあります。

Javaのほうはちょっと悲惨ですね。Tigerがそれほど
起爆剤になってないのが痛い。とはいえ、シェアで
いえば今でも一番なんですけど。

こないだも獲物のほうで『最近のJavaには元気が
ないぞ!』って叱ってた人の日記を紹介しましたけど。
JavaWorldが隔月刊化ですか。まぁ、MSのJava追撃が
成功しつつあるってことなんでしょうかね、ぶっちゃけ。

こないだも書きましたけど、C/C++が長期的に凋落傾向に
あるのは、まぁ、しょうがないでしょうね。

Perlはちょっと辛いですね。ネガティブな印象が
パンピーにも植えつけられちゃった感じ。Javaが出た
ときにC++へのネガティブ・キャンペーンみたいな
フインキがありましたけど、それと似た感じが世間に
漂ってるような。って、こう書いてる自分がそういう
雰囲気を作ってるのかもしれませんけど (笑)。

いや、でもさ、Pythonなんですよね、一番の問題は。
よく『RubyかPythonか?』みたいなこともいわれますし、
『海外だとPython多いよ』とかもいわれるんですけど、
このグラフだけ見たら、『どこが?』って感じですよね。
Perlの後継だ後継だっていわれて何年経ったの?っていうね。
Ruby云々別にしてね。RubyだってRails出なきゃ世間的には
余裕でスルーの言語でしたけど。Pythonの教義から
いったら、Rubyよりポピュラーであることを善しと
してるはずで、それが実現できてないのはイーカゲン
マズかろうと。

Rubyは、まつもとさんもいってるように、そんなに
ポピュラーじゃなくてもいいやっていう、開き直った
とこがあるんですけど。プログラマ向けの言語だっていう。
それが原因となって優秀な人が集まって、Railsみたいな
もんが出てきちゃってRuby自体もポピュラーに
なっちゃうっていうのは、ちょっとした皮肉なんですかね。

日本のオライリーも自分とこでRaderやりゃいいのに。
もったいない。Timさんのネタを引っぱってきて、
『実は日本では・・・』みたいな話だって十分
面白いでしょ。

本家Permlink


2006年08月01日

http://d.hatena.ne.jp/squeaker/20060729#p4

  大きなゴールを胸に、小さなステップを繰り返してゴールに近づくやり方が
  良い。

これ。読んで涙が出てきた。だって、自分が度々書いてる
ことじゃないですか。リファクタリングの姿勢。

リファクタリングっていうのは、多くは非常に細かい
作業です。名前を変えたりとか、メソッドを切り
出したりとか。でも、そういう細かいことばっかり
やってると、道を逸れちゃいやすい。価値のない
コードばっかり書いちゃうことになる。

もちろん、これはリファクタリングだけの話でも
ないんです。開発全体にしてもそう。顧客の利益となる
大きなゴールを胸に抱いてないと、役に立たないシステムが
出来上がっちゃう。そうなってから騒いでも手遅れ
なんです。

そういう意味で、プログラマはみんなアーキテクトで
なければならないし、ビジネスを見る目を持って
なきゃいけない。

--

http://www.oversea-pub.com/

獲物で済ましちゃいけない気がしました (笑)。

事のイキサツは:

http://www.wnishida.com/~wmemo/?date=20060731#p01

を。

とりあえず見ずに買いたい。まぁ、ちょとビンボーなので
あんまり高いとちょっと尻込みしちゃいそう。

あっちの連載のほうも、GBAの部分については書籍化
されたんですけど、それ以外のところはまだなわけで。
いろんな事情があると思うんです。で、そういう事情が
自費出版に走らせたのかなぁと邪推しちゃうんです。
GBAのヤツも絶版でしたよね、確か。

紙にこだわりたいっていう気持ちもわからなくも
ないんですけど。でも、PDFでもいいんじゃないの?
っていう気もしないでもないんです。サンプル・コード
とかコピペできますし。

まぁ、繰り返しますけど、出たら買います。

--

Unixアプリケーション・プログラミングの源流が
K.Thompson氏によるB言語というならば、スクリプト
言語でUnixアプリケーションを書くのはまったく正統
であると私は主張する。

--

マジメな話、オメメパッチリな感じならオケじゃないでしょうか。

--

下でグチってるわりには、いざリンクされるとビビって
目を通さない小心者だったりします (笑)。

http://d.hatena.ne.jp/habuakihiro/20060620#1150770612

はぶさんの日記、アンテナに登録させていただきました。

『餅は餅屋』とか『酒を混ぜれば赤くなる (もしくは
赤くなりたい)』とか、気持ちはわからなくはありません。
自分も、ソフト開発ではないとこで仕事してたことが
ありますから。

ただ、今はフリーの人も多いし、もちろん派遣だって
ありますし、そういう人がいるんだから雇っても
いいんじゃないかと。

まぁ、雇われた人にとって長いこと続けられるほど
ヤリガイを感じられるかどうかは別にして (笑)。
自分も、そのときは『オレはここにいる人間じゃ
ないよなぁ』と感じてましたから。それはお金云々じゃ
なくって。

それと話は変わりますけど、自分はK.Beck原理主義者を
名乗ってるくらいで。XPの教条というものを、多少は
吟味することはあっても、基本的には盲信してます (笑)。

だから、『Small Initial Investmentが良い』って
いわれたら、『そりゃそうだ、そうだよ、そうなんだ』
ってな具合です。

それに、XPで実際に仕事を請け負ったことはないですしね。
今XPっぽく仕事やってますけど、請負の仕事じゃないですし。
だから、XPのやり方で請負の仕事を取れるかどうかって
のは自分はわかりません、正直いって。

結局のところ、agileとかを実際にやるなら、上層部の
協力が絶対に必要なわけで。だから『ジジイ早くドケ』
とか思わないでもないんですけど、自分ももう
いい年だし、あんまりそういうことはいえません。

逆をいえば、開発プロセスをしっかり視野に入れた経営を
する上層部がいるとこは強いと。そうでないとこは
いずれダメになるでしょう。『いずれ』ってのは5年も
かかりませんよ。予言しちゃいますよ、ええ。
だって、あと5年すれば、XPが世に出て10年ですよ。

--

グチは書かないっていう約束なんですけど、たまには
許してください。いや、これ、こないだも書いたんですけど、
すぐ消しちゃったんですけど、やっぱり書いとこうかと。

たまたま、ここで取り出せる一番古い記事を調べる機会が
あって、それ読んだら:

  ソフトウェア開発は、工場の生産にたとえられるべきではなく、工場を作るこ
  とにたとえられるべきでしょう。

  工場というのは一旦ラインが出来上がれば、あとはほぼ正確に計画どおりに生
  産することができるでしょう。けれども、そのラインを作り上げる過程はどう
  なのか? おそらく最初の計画どおりに進むなんてことはないはずです。

  ベイパーウェアは何もソフトウェアに限ったことではありません。たとえば
  ぷなんかにしても、しょっちゅう遅れますし、ロードマップも頻繁に変更さ
  れます。

  だまされちゃダメですよ。

なんてことを書いてるわけですよ。まぁ、工場の
メタファーを攻撃したのはこれが最初でもないですし、
自分がはじめてでもないですし、PragProgsは『達人
プログラマー』の中で、工場よりもガーデニングのほうが
適切だって主張してますし、``Code as Design''も
pre.htmlのときも含めて、何度か取り上げたことがあるんですよ。

ほんと、『なんじゃそりゃ?』って感じですよ。
オレはそんなに人に読まれないことを書いてるのか?っていうね。
ヒジョーにムナシイ。もう、読まれてないことについては
開き直ろうって何度も思ってるんですけどね。ときどき
脱力しますよね。さすがに。

まーえーか。としかいえない。

本家Permlink


Copyright © 1905 tko at jitu.org

バカが征く on Rails