日々の破片

_ 良い工夫と悪い工夫

御伽噺のような話だ。

個人的には嫌いなのだがやんごとなき理由からCheckStyleというツールを使っている。

困ったことに、初心を忘れて好きになりかけている自分がいたりもするのだが、それはおいておいて。

一応、良くあるルールは入っていて、たとえばstaticメソッドしか定義されていないつまるところユーティリティにはprivateコンストラクタが無ければ怒るとかなっている。

このコーディング規約ってのは、個人的にはあまり意味がないと思うのだが、おそらく

public class Utility {
    /**
     * 与えられた文字列をnullに変換する。
     * @param s nullにする文字列
     * @return null
     * @throws NullPointerException 与えられたsがnull
     */
    public static String convertToNull(String s) {
        if (s == null) {
            throw new NullPointerException("null was given");
        }
        return null;
    }
}

というようないかしたユーティリティに対して

public bar(String arg) {
    String s = new Utility().convertToNull(arg);
    ...
}

みたいなすっとぼけた利用方法を防止することが目的なんだと思う。

実際にはとっくの昔に役割を終えていて、こういうのって警告が出るような気がするのだが（わざわざこんな書き方しないからわかんないけど）、バージョン管理を考えるとあまりよろしくないルールのような気がするのだが、それはまた別の話である。

で、そういうルールがあってこれをCheckStyleがチェックするというわけだ。

で、そんなある日のこと、愉快なソースを眺めていたら

public class CoolUtility {
    /**
     * 新しいCoolUtiltityを作る （といった文）
     */
    public CoolUtility() {
    }
    public String bornClash(int x) {
        return String.valueOf(x);
    }
    public String bornClash(long x) {
        return String.valueOf(x);
    }
    ... 山ほどたくさん。
}

というような、すばらしくぼんくらなクラスが出てきたので腰を抜かした。

どうあってもString.valueOfを使いたくないらしいというのには目を瞑るとしても、なんでこれがインスタンスメソッドなんだ？

すると隣の席の人いわく

このコンストラクタのJavadocにはEclipseの匂いがする。

出たー。Eclipseか(追記：誤爆の可能性あり。更に追記：誤爆確定（って、ことは小僧以下だな。確信のもとにコンストラクタを書いているということになる。――無引数publicコンストラクタ書けルールのほうかな？ でもあのルールは殺しているはずだが）)。何しろ小僧の神様だからなぁ。神様がなされたことはすべからず善であるから消すなんておそれおおくてできないだろうし。ってことは、いくらなんでも最初はstaticメソッドとして実装してみたが、CheckStyleが怒った（privateコンストラクタじゃないわけだから）もんで、ごめんなさい、ごめんなさい、って謝りながらメソッドからstaticを消して行ったんだろうなぁ。(注：「すべからく」じゃないのは意図した誤動作)

かくしてCheckStyleは文句を垂れなくなりました。めでたし。

実に工夫の後が見える実装である。

教訓：小僧にEclipseを与えてはならない（実にたくさんメソッドが入っていたわけで、だめなコードの生産性を高めては本末転倒であろう。より生産性が低いツールを与えた方がプロジェクト全体としては効率が向上する可能性がある）。または重箱の隅をつつくようなコーディング規約の厳密なチェックは、より質の低下を招く。

注：骨を砕くんじゃなくて、生まれてきてごめんなさいの意がこもったメソッド名だという点を味わって欲しい

_ 時が暴走する

単に寝ちゃっただけだけど。

_ いかがなものとはなにものか

今を去ること25年近く昔、っていうか4半世紀かよ、夕刊紙の穴埋め記事のバイトを友人がやっていて、ちょっと手伝ったことがある。

ここに魔法の言葉あり。それが

いかがなものか

これは便利だ。字数が7字というのが1行不足したりするときにもぴったり。

で、どうでもよいことだらだらてなことがあったりしたりもするもんかもしれないかもしれない。(まったく)?、?最近の*は、いかがなものか。

*には、大学生、サラリーマン、OL、銀行マン、風俗、男、女、大学、キャンパス、会社、恋愛事情、あたりを前の文章と字数に応じて適当に当てはめる。とにかくいかがなものかさえ最後に置けば、どんなでたらめを書いても許される。まったく、最近の言葉の受け止め方はいかがなものか。

追記：リンクもなくいかがなものかとはいかがなものか。

いかがなものか、という言葉はかようにいかがわしいものであるから、この言葉が出てきたらまじめに取らないほうがかえって良いようにさえ思える。すると本気でいかがなものかしているいかがな人というのは立場がいかがなものになってしまうのだがいかがなものか。

_ 忍びの道はきびしいでござる

いかがなものか？

いかにも伊賀ものでござる。

いやいがものかとは言ってはいないのだが聞き間違えるとは忍びのものとしていかがなものか？

いかにも伊賀ものにてござる

にて？

にてにてござる

これはしたりそうでござったか

ござるござればござらばござれ

_ 追って来ないでお願いだから

追っ手から逃れるシステム（きしだのはてな）は、具体的な逃げ手のノウハウが満載でとても役に立つのだが、1点ダウトがある。

上から下へ流してもうまくやることで追っ手の戦意を著しく削ぐことが可能だからだ。

たとえば、以下のようにやって見せることだ（実は目撃談だったり）。

public class ValueObject {
    String key1;
    public String getKey1() { return key1; }
    ...// keyが5個くらいあるとする
}
...
// 幹のロジック（追記：後で書いていることとメソッド名が合わなくなっているので修正した。っていうか難しいよこの書き方は）
public void trunk(ValueObject v1, ValueObject v2) {
    ...
    if (v1.getKey1().equals(v2.getKey1())) {
        if (v1.getKey2().equals(v2.getKey2())) {
          ...
            if (v1.getKey5().equals(v2.getKey5())) {
              ... // 処理タイプ1が20行
            } else if (v1.getKey5().compareTo(v2.getKey5()) > 0) {
               ... // 処理タイプ1'が20行
            } else if (v1.getKey5().compareTo(v2.getKey5()) < 0) {
               ... // 処理タイプ1''が20行
            } else { 
               ...（追記：もちろんここにも処理タイプ1が20行入っているのが不安感を煽るのなんのって）
            }
          ...
       } else if (v1.getKey2().compareTo(v2.getKey2()) > 0) {
            // 処理タイプ1'が20行
       } else if (v1.getKey2().compareTo(v2.getKey2()) < 0) {
           // 処理タイプ1''が20行
       } else {
           // 処理タイプ1が20行
       }
   } else if (v1.getKey1().compareTo(v2.getKey1()) > 0) {
        // 処理タイプ1'が20行
   } else if (v1.getKey1().compareTo(v2.getKey1()) < 0) {
        // 処理タイプ1''が20行
   } else {
        // 処理タイプ1が20行
   }
   ...
   // すごくたくさんの処理
    if (v1.getKey1().equals(v2.getKey1())) {
        if (v1.getKey2().equals(v2.getKey2())) {
          ...
            if (v1.getKey5().equals(v2.getKey5())) {
              ... // 処理タイプ2が20行
            } else if (v1.getKey5().compareTo(v2.getKey5()) > 0) {
               ... // 処理タイプ2'が20行
            }
      ...
   }
   // すごくたくさんの処理
    if (v1.getKey1().equals(v2.getKey1())) {
        if (v1.getKey2().equals(v2.getKey2())) {
          ...
            if (v1.getKey5().equals(v2.getKey5())) {
              ... // 処理タイプ3が20行
            } else if (v1.getKey5().compareTo(v2.getKey5()) > 0) {
               ... // 処理タイプ3'が20行
            }
      ...
   }
   // すごくたくさんの処理
   if (v1.getKey1().equals(v2.getKey1())) {
     ...
   // この調子でずーっと永遠とも思える行数が使われて行く
}

追記：最初、すさまじく複雑な条件なのかと思ったらなんのことはない、単に2つの引数が小さいか、等しいか、大きいかで処理が分岐しているだけの話なのに1つのif文につき1条件として(複合キーだからこれはわからんでもない)、かつ律儀にすべてのブロックに処理を埋め込んでいるだけの話だ。それを何度でも倦むことなく繰り返しているのは条件と条件の間に共通の処理が時間軸に沿って挿入されているからのようだ。

これを究極のコピー&ペースト技と呼ぼう。確かにパターンを掴めば上から下へ流れるだけだが、実は処理タイプn〜n'''のいずれかに、しかしkey3が等しかった場合「だけ」は処理タイプn.5が必要とかが紛れてみたらいかがなものか（ry。

逆側から考えると、次のようになっていれば追跡しやすいと考える。

まず、処理1〜処理嘘800までは、ばらかしているということから、仕様上の1つの処理の固まりと考えられる。したがって、ここは必ずしも幹上で上から下へ入れる必要はない。次にn.5が必要となるのは極一部だから、そこだけを特別扱いすれば良い。最後に、比較を幹で行うことは良いとしても、比較の実装はValueObjectが持つべきだ。別のクラスであってもこの場合は文字通り関連があり、いずれにしろ追う場合、エディターにはこのソースも開いているはずだ（マルチファイル／ウィンドウエディターであれば）。

public class ValueObject implements Comparable {
   ...
   public int compareTo(Object o) {
     ... // 追加（もちろん特化メソッドでも良いが僕は標準が好き
   }
}
...
public void trunk(ValueObject v1, ValueObject v2) {
    ...
    int v1CompareToV2 = v1.compareTo(v2); // 注：基本的にローカル変数は1〜2字ルールなのだが、こういう分岐フラグとかは別格
    if (v1CompareToV2 > 0) {
        処理パターン1'();
        すごくたくさんの処理1();
        処理パターン2'();
        すごくたくさんの処理2();
         ...
        if (v1.getKey3().equals(v2.getKey3()) {
            処理パターン4'改(do4.5);
        } else {
            処理パターン4'改(dont4.5);
        }
        処理パターン5'();
        ...
    } else if (v1CompareToV2 < 0) {
        処理パターン1''();
        すごくたくさんの処理1();
        処理パターン2''();
        すごくたくさんの処理2();
         ...
    } else {
        処理パターン1();
        すごくたくさんの処理1();
        処理パターン2();
        すごくたくさんの処理2();
         ...
    }
}

もちろん、処理パターン1〜1''が引数レベルで調整可能な良く似た処理であれば、それもありかも(分離性から言えばなくても良いと思う)。

だから、とてつもなく逃げるのがうまい人は上から下までルールでさえ、とんでもないことをするということでした。

追記：なお、上の形を最終型とせずにテンプレートメソッドパターンにしてクラスを分離すると突然読みにくくなったりするのがおもしろいところ。でも僕はケースバイケースでやるけどね。ただ、この場合であれば内部クラスとして閉じるけど。

追記：修正した。いや、実に読むのも辛いが書くのも大変だ。作ったやつはおそろしく頭が良いに違いない。使い方が間違っているだけなんだろう。

追記：本当にこれは反省しているのだが、CheckStyle嫌いというのもあって、また、明らかにそうすべきケースがあるからなのだが、明示的な行数制限を取っ払ったのが裏目だ。しかし、明らかにそうすべきケースであってもそれを判断できる開発者ならその制限を回避することはできるわけだから、メソッドの行数のようなものは制限をきつめにかけるべきだったのだ。以前、80点から100点ルールに合わせるべきと書いたが、まさにケースバイケースで、50点ルールにすべきものもあるということだ。と書いてから気付いたが最初のきしださんのネタは20行ルールを逆手に取るうまい逃げ手の話だった。あちら立てればこちら立たずになってたのかも知れないってことか。だめなやつはどうやらせてもやっぱり……という結論にするのは気に食わないから、ここはやはりだめなものとだめじゃないものを教えてくしかないという結論を出さざるを得ないんだろうか。

_ Emacsがささると

とても悲しい。

しかも外は雨だし。

_ お名前

ちゃんちゃんちゃんちゃか、あなたのお名前なんてーの？

お前は何様だと

すげー名前だ。コメン欄でゴメン。

「オレ様」のほうがでも、名前としては王者の風格があると思うが。それにしても何様っていうのは面白い言い回しだ。でも如何様にちょっと似ているのは如何なものか（しつけーよ）。

_ S2.NET

えーと、はぶさんのとこに出てますが（と他人事のように書き始めてみる）、暑い夏が過ぎて秋の風が吹くあたりからS2.NETに本格参入予定です。

よろしくお願いします。

これでMSMVPはいただきだね（と、わけわからんことも書いてみたり）。

_ 成長

子供が、スターウォーズスターウォーズと叫ぶので、うーん、ポケモンかどっちかだなぁ、と言ったら、スターウォーズときっぱり言った。ニヤリ。そうしたらあまりにこっちが嬉しそうに見えたのかあわてて「でもゲームは別」と付け加えていた。

_ リング

_ さらに逃げる

カムイ外伝やサスケとかのもじりでも書こうかと思ったが、さすがにそんなものを書いても誰もわからんだろうな、と気付く。

そこで思い出したのだが、煙幕を張るというのは伝統的な逃げ手の良い作戦だ。巻きビシ作戦はまた別の機会にでも。

効果的な煙幕は相手を咳き込ませるような煙よりも、相手が桃の畑だと勘違いするようなやつだ。追っ手の経験が浅いうちは、日本語による記述というのは実に甘い香りがする。実は香ばしいだけなんだが元の意味は同じだからだ。そのため優れた煙幕として作用する。

public void updateFoo(Foo democracy, Foo burocracy) {
  // 民主主義の手がかり
  int tegakari1 = democracy.getTegakari();
  // 民主主義の足がかり
  int ashigakari1 = democracy.getAshigakari();
  ...
  // 官僚主義の手がかり
  int tegakari2 = democracy.getTegakari();
  // 官僚主義の足がかり
  int ashigakari2 = democracy.getAshigakari();
  ...
  // 民主政権の打倒
  bang(tegakari1, ashigakari1, ..1, ...1, ...1);
  // 今度は官僚主義を打倒する
  bang(tegakari1, ashigakari1, ..1, ...1, ...1);
  ...
}
...
void bang(int ashigakari, int tegakari, ...) {
    ...
}

各主義（Fooクラス）は属性がたくさんある。その属性をすべてローカル変数に格納する。この時ローカル変数の名前は元の主義がわからなくなるように抽象化すると効果的である。抽象化しすぎると怪しまれて逆効果であるから属性名についてはそのまま利用すると非常に良い。並の追っ手であれば最初の10数行を見てうんざりしているため、第2引数からの属性抽出などコメントをちょっと眺めて、バカと呟いて通り過ぎる（煙幕1）。

そしてこれらの主義を必要とするところに、主義そのものを与えれば済むはずのメソッドをあえて属性を引数としたメソッドとして実装したものに与えさせる（煙幕2）。この時、属性の並び順を煙幕1の並び順と変えておくと更に良い（煙幕3）。

これらの煙幕が破られたときのために、有りえない取り違いも混ぜておく（煙幕4）。

もちろん、テストプログラムも付けて置く。この時、両方の主義の属性が等しくなるように注意深くテストケースを選択しておく。煙幕3の補強のために、肝となる属性値を同値にしておくことも重要だ（煙幕5）。

追記：ask型プログラミングってこういうことになりやすいよな。

_ あ、たなばただ

一発で変換しなかったんでひらがなだが、なんか強烈だな。たなばただ、なばたなばたな、たなばただ。

さて、マリンスキーリングだが抽選に当たると地獄だが（懐が）、当たらなければ天国というわけでもないのが辛いところだ。

追記：たなばただたけやぶやけたたなばただ

_ マリンスキーリング

S席は外れた。ちょっとほっとした。でも口惜しいような気もする。

とは言ってもA席になったわけで、やはりまじめに仕事をするしかあるまい。

_ 365日ずっと付けっ放しさ

やっぱ、Hi-Posiはええのう。ポップなメロディと適量のノイズ、妙に可愛い声。

こういうのって最初に聞いたのはケイトブッシュってことになるのかな。全然違うんだけど、コニーフランシスとかカーペンターズ、オリビアニュートンジョンみたいなのでもなければ、パティスミスとかスージースー（時代が妙に違うからだめだな）とかみたいのじゃなくて、なんか全然違う文脈で出て来たようなすっとんきょうなのって。

で、矢野顕子にたまげて、なんちゃら泉（忘れちゃった。たしかうる星やつらの主題歌の人。急に思い出したけど六本木のピットインで高中バンドのギグ見に行ったときのキーボードで、唄ったのを聴いたな。っていうか番組のほうは見てないからそこでしか聴いたことはないのだが）、ジューシーフルーツ、戸川純と来てHi-Posi。フューとかコクシネルとかはちょっとまた違う傾向だが。

基本はピコピコした音と可愛い声。

恋はAmi Ami(アミ・アミ)~リオ・ベスト~(LIO)

そう言えばLIOってのもそんな感じだった。テレックスがバックでピコピコしているところにアミアミアミアミカルモンヴォートルとか。

倉田まり（子？）とかいうアイドルがカヴァーしてたのがまた妙だったり。

そう言えば、子供が幼稚園に通ってた頃、あたしのselectを妙に気に入っていっしょに唄ってたな、とか思い出したり。

_ 素晴らしい部品共通化とか再利用とか

目が覚めるような工夫を見た。

 ...
List list = TableMaster.read(connection, "foo", form.getBar(), form.getBaz());
boolean boolFlag = false;
Iterator ite = list.iterator();
while (ite.hasNext()) {
    Map map = (Map)ite.next();
    if (map.get("KEY3")).equals(form.getBoz())) {
        boolFlag = true;
        break;
    }
}
if (boolFlag == false) {
   ...
} else {
   ...
}

まあ、for (Iterator i = list.iterator(); i.hasNext();) と書かずに、わざわざループのスコープ外にイテレータを宣言するようなコード書くのにろくなのがいないということはわかってしまったから、どうせろくでもないことをしてるんだろうな、と見ていると、っていうかboolFlagかよ、どっからflagなんて言葉が出てくんだろうね？ 一体としは幾つなんだか、とかむかむかしてきながら我慢して読んでいた。っていうか、fooってテーブルは何十万件だかあるテーブルなんだが、2つしかキーを与えないとへたすると数万とか返ってくるんじゃないか？ 違うのかな？ とか、まだ多少は希望はあったりしながら見ているわけだが。

 ...
List list = (ArrayList)TableMaster.read(connection, "bogus", form.getBar(), form.getBaz());
boolean flag = false;
Iterator iterator = list.iterator();
while (iterator.hasNext()) {
    Map map = (HashMap)iterator.next();
    if (map.get("KEY3").equals(form.getFunky()) &&
        map.get("KEY4").equals(form.getKinky()) &&
        ....
        map.get("KEY8").equals(form.getDonky())) {
        flag = true;
        break;
    }
}
...

今度のはもっとすげーな。flagかよ、っていうか、キャストがひど過ぎるが一体なんなんだ？ っていうか、条件演算子を右端に書くやつにろくなのはいないっていうことはすでにお見通しなんだが、っていうかbogusってのは数100万件とかいう大物じゃなかったか？ っていうか、KEY8って、おい……

てな調子で数本見ればさすがに馬も土曜に蒼ざめる。このおそるべきマスターはどこだ？

/**
 * 部品共通化
 */
public class TableMaster {
    /**
     * 共通テーブル処理
     */
    public static List read(Connection c, String name, String key1, String key2) throws SQLException {
        StringBuilder sb = new StringBuilder();
        sb.append("SELECT * FROM " + name + " WHERE id='" + key1);
        sb.append("' and subid='" + key2 + "'");
        List list = new ArrayList();
        PreparedStatement ps = null;
        ...
        try {
            ...
            while (rs.next()) {
                Map map = new HashMap();
                ResultSetMetaData rsm = rs.getMetaData();
                for (int i = 0; i < rsm.getColumnCount(); i++) {
                    map.put(rsm.getColumnName(i + 1), rs.getObject(i + 1));
                }
                list.add(map);
            }
            return list;
        } finally {
            ...
        }
    }
}

うが。想像どおりなんですが。StringBuilder#appendの中で文字列連結してどうするよ、ってなことはその後のに比べりゃどうでもいいが（追加：良くねぇよ。キーを文字列連結しちゃいかんだろう。安全性の面からも実行効率の面からもPreparedStatement使うのが筋だ……って言うか使ってるよorz。使い方がぱっぱぱらひゃら）、これ最大同時予測アクセス数とか何も考えてないんだろうな、っていうかループの外に出せというかそんなことより、なぜ、こんな妙なユーティリティを作るのか？ というか。1人も動かせばメモリーいっぱいいっぱいだというか、ああ、それでテストはしましたとか胸を張ったりするのかなというか、なんていうか、なんにも言う気も起きないんだが、*を使ってカラム全部とってもさっきまで見てた連中は残りのキーを除けば1つか2つのカラムしか見てないぞっていうか、そんなことは全体から見れば小さいことだが、それにしても各テーブルでできるだけカラム名を同じにするっていうことにこういう罠が待ってたわけですな。っていうか、Javadocコメントがすごく虚しいのだが。

汚染された廃物は再利用不可能だから書き直し決定。

_ 愚者の船

なんだか遙か昔のこと、世田谷のほうに劇を見に行った時に入った喫茶店がすごかった。5回くらい注文を取りに来て8回くらい注文を間違えて運んできて、おまけにそこら中でお盆を引っ繰り返すは、そのくせニコニコしながら店員たちは働いていて、お盆を引っ繰り返したってめげもしょげもせずに、とにかく一生懸命働いているんだが、することなすことすべて正しく動かない。別にねらい打ちで間違えているわけではなく、隣のテーブルに何か持って行けば「それ頼んでないですよ」、あっちへ行ったと思ったら「ご注文は……」「え、もう頼みましたが」、こっちへ来たと思ったら「えーと、なんちゃらコーヒーをご注文ですよね？」「いえ、頼んでいませんが」「ではなんちゃららコーヒーでございましたか」「いやなんちゃらららコーヒーです」「失礼いたしました（と何か注文票を直しているって、何回目だ？）」っていう感じ。

まるで愚者の船だ。と、一緒に居たやつが呟いたのが妙に印象的で、今でも時々思い出す。

っていうか、突然思い出したがあの店員、眼鏡っ娘だったが、狙ってたのかな？ なんてこたないだろうが、フラグといえば船だな、とそんな方向へ記憶が飛んだんだが、そんなに使うもんかな。

jnzとかbeqとかじゃないんだから。

追記：やたらクラスがたくさんあってDTOを次々クローンして呼び出しが連鎖するプログラムみたいだ。ソースを見てもさっぱり責任の所在（責務の範囲が曖昧）もオリジナルなインスタンスの管理もわからないシステムは、実はシステム自体も正しく機能しないという見本のような。

_ 百科事典を買う

_ 今日は初台

魔法の笛。

子供がオペラ好きのバレエ好きなのは嬉しい。値段が半端じゃないからさすがに独りで行くのは気が引けてたわけだが。

_ 魔笛のメモ

中劇場。入りは2/3程度。

オケは20人くらいかな？ 合唱は10人いないかどうか。

最初に僧侶に伴われてフルートの独奏

前奏曲の時点で登場人物が遊戯を繰り広げる。したがって、すべては遊戯の世界。

弁士はザラストロが肩代わり（だと思う）。

夜の女王は良かった。

舞台から降りて最前列を行き来するため、オーケストラピットを輪の中心として円環状の舞台として構成。

やっぱり一幕目が好きだ。侍女の3重唱、ムムムの五重唱。実にくだらない歌を素晴らしい技法で軽やかに。

モノタナトスが良い味を出している。なぜか僧侶が印象的。

楽しかった。

_ カマラード

『コモドールの華麗なる興亡』翻訳きぼんぬ。

via Classic 8-bit/16-bit Topics。

_ ファミレス

大人の女が美しい(長沢 節)

長沢節がそういえば、おふらんすでは自分の家ってのはプライベートな領域だから当然全裸ですよ。と言って四谷の上のほうでは確かに全裸でうろうろしていたとか聞いたことがある。ちょっと先生のこと呼んで来るわとか言って呼びに行くと全裸でうろうろ。っていうか、『大人の女が美しい』にもそんなくだりがあるな。服を着ていたら大小たすのに一々服を脱ぐことになって非合理的ですね。そもそも便器を便所なんて部屋へ隠したら不便ですな。したくなったときにわざわざ移動するってのは、匂いから敵がやってくるのを防ぐ獣の習性で、なんでこの文化的たる人間様がそんな非合理的な行動を取らなきゃならんのですか？ え、先生のお家にはトイレはないんですか？ トイレというのが何をさすのかはわかりませんが、便器を隔離した小部屋はありません。無意味です。便器は、当然、そのへんに作っておきます。それでは臭いのでは？ ――おお、なんて発想がオリエンタル。使ったらきれいにするのは当たり前。きれいにしているのに臭いとはこれいかに？

という全裸老人だったらしいが、大人の女は美しいには全編そんな感じでいかに合理的に生活すべきかが書かれている。全裸万歳。

では客が来たら脱いでもらうのですか？ と言えば、家に上げる人はプライベートな関係なんだからそりゃ全裸です。そうではない人と会うのは、そのためのパブリックなスペースが発達してるから当然カフェとかです。そうじゃなくても、寝ると大小をたす以外はパブリックな場所に任せれば家は広々と使えるのに小さく仕切って狭い狭いと文句を垂れてる君らの非合理的な生活態度にはびっくりぎょうてんだ。というような感じである。

それはそれとして長沢節の顰に倣って仮に全裸生活するにしても、その状態でPowerBookをいじったら、当然、すごーくおそろしいことになるのがわかっているので、ファミレスへ持って行ってみることにする。

_ ドメインモデル高脂血症

うーん、貧血小僧に比べると門前の小僧と高僧以上にソースの美しさに差があるし、腰蓑と宇宙服以上に構成力に差があるんだが、脳血栓とかになりそうな気が（不吉な香りが）するぞ。急に心臓が止まるとか。立ちくらみでふらつくほうがシステムとしてはむしろ良いかも。

（追記：タイトルを修正）

_ ドメインモデル糖尿病

蟻が群がるうちは良いとしても、片足切断とかの大手術が必要になりそうな気もしないでもない。

_ カーネル関数

90年代のごく最初か80年代の終わり頃か、気持ち良くtime(2)とか（今ならgettimeofdayになるのかな）呼びまくってたら、「遅くなるからやめろゴラ」と怒られたものだが。

というわけで多分、何も考えてないのだと思うがやたらめたらとSystem.currentTimeMillisだのCalendar.getInstanceだのを呼んでいるプログラムを見ると気になる。

トレースとかだってstartとstopをトレース側に用意しておけば有効無効に連動して時刻呼び出しの有無を切り替えられるはずなのに、地のほうで差を求めてトレースに与えたりしてるのを見かけるし。

import java.util.Calendar;
import java.util.GregorianCalendar;
public class Day {
    static Calendar createByCalendar(int y, int m, int d) {
        Calendar c = Calendar.getInstance();
        c.clear();
        c.set(Calendar.YEAR, y);
        c.set(Calendar.MONTH, m - 1);
        c.set(Calendar.DAY_OF_MONTH, d);
        return c;  // getInstanceで常にクロック読み取りするってのが変だと思う。new Dateもそうだが。
    }
    static Calendar createByGregorianCalendar(int y, int m, int d) {
        return new GregorianCalendar(y, m - 1, d);
    }
    public static void main(String[] args) {
        for (int i = 0; i < 3; i++) {
            long l = System.currentTimeMillis();
            for (int j = 0; j < 10000; j++) {
                Calendar cal = createByCalendar(2005, 1, 1);
            }
            System.out.println("経過：" + (System.currentTimeMillis() - l));
            l = System.currentTimeMillis();
            for (int j = 0; j < 10000; j++) {
                Calendar cal = createByGregorianCalendar(2005, 1, 1);
            }
            System.out.println("経過：" + (System.currentTimeMillis() - l));
        }
    }
}

C:\test>java Day
経過：296
経過：47
経過：78
経過：31
経過：78
経過：47

1GHz P-III、Windows2000だと3〜4マイクロ秒もかかるのか。ちなみにSparc Solarisのやっちいやつで試したら想像どおり200ナノ秒ちょっとというところだった。

でも、この数の裏側にいろいろなやり取りがあるわけだし。OSとハードの実装に依存するのだが、システムクロックの読み取りというのは余り気軽にやって欲しいものではない。というか、ユーザーがやらなくても、JVMをtrussするとすさまじくクロック読み取りしているように見えるのだが。

_ イイ

P
  __|
P

_ 世界中どこでも技術者は愛されている（多分）

ネットの上で読んだんだと思うんだけどグーグルさんに問い合わせてもわからないらしい。するってーと本で読んだのか？ それとも重要なキーワードを間違えてるかどっちかだ。

というわけで、思い出しながら採録。

政治家と牧師と技術者が木曜の午後にゴルフをしに行った。この時間は確実に空いているため、邪魔が入らずにのびのびとプレイできるからだ。

3人は仲良くプレイを始めたが、困ったことに今日に限って先客が居た。しかも前の集団は異様にのろい。しかも猛烈にヘタクソだ。それでも最初のうちは待ちながら談笑もしていたが、そのうちだんだんイラついてきた。前の集団がこちらのほうを見ているときに手を振って追い抜いていいか、とやってみせたりもした。しかし彼等は知らん振りしてやっぱりのろのろやっているではないか。

政治家が言った。きっと連中はアカに違いない。だからサボタージュが身に染み込んでるんだ。ああいう連中はさっさとキューバに送り返すべきだな。

神父が言った。神よ、彼等に業病と永遠の地獄の業火の責め苦を与えたまえ。

技術者が言った。キャディさん、彼等に僕らを先に行かせるように交渉してきてくれないか？

キャディは前のグループのところへ駈けて行き、何か話し込み、そして戻ってきた。

キャディは言った。ジェントルメン、ついてないね。彼等は地元のライオンズクラブ主宰の『盲人にゴルフを』の会の盲人たちでさぁ。

技術者が口を挟んだ。だからヘタなのか。

政治家と牧師は彼を睨みつけて、キャディに先を続けさせた。

キャディは続けた。彼等は後ろに他の客が居るとは気付かなかった、誠に申し訳ないと言っていた。

その途端に技術者が手を打った。なるほど、そりゃそうだろう。

政治家と牧師は彼を睨みつけて、キャディに先を続けさせた。

キャディは続けた。どうぞ、先へ行ってくださいとのことでさ。

牧師は顔をまっかにして言った。神よ、お許しください。私はこれから毎木曜日に彼等のために祈ることにいたします。

政治家は半泣きしながら、しかしきっぱりと言った。いや、誠に無礼なことをした。確かに木曜日の午後に我々がプレイしようというのが間違いだ。これから木曜の午後は彼らのために解放するよう、市議会に働きかけよう。先ほどひどいことを言ったせめてのおわびだ。

技術者が言った。木曜の午後を彼等に明渡しても無駄だ。それより僕は夜中のゴルフ場を彼らのために解放開放することを提案する。そうすれば我々は木曜の午後を楽しく過ごせるし、彼等も心置きなくプレイに専念できるというものだ。

_ この世は旅だ

久々にセリーヌを読みたくなったが、見当たらない。

夜の果ての旅を読んだのは高校生の頃だから、もう随分経つ。でも、繰り返し繰り返し読んだから結構覚えているかも知れない。

志願兵になってアフリカへ行く当たりまではおっちょこちょいだ。

で、間違えてアメリカへ奴隷として売られてしまう。ガレー船に鎖で繋がれて鞭で叩かれながら漕がなきゃならない。アメリカではexitという単語を最初に覚えた。no exitより前の話だ。

で、フランスに戻り、クリシーで医者を始める。どんどん人は死んでいく。サクレケールの丘で夜空を見上げると子供の顔が浮かんでくるようだ。

っていうか、全然、覚えてないな。

#あれ、夜の果てへの旅なのか。ずっと夜の果ての旅だと信じていたのでびっくりだ。

#追記：それはそうだ。夜の果ての旅なら、そこは夜の果てでそれ以上どこへも行きようがない。それでも旅を続ければ夜明けを迎える可能性もあるかも知れない。でも、夜の果てへの旅なら、それはただただ夜の果てへ向かうわけだな。確かにそういう旅の物語であった。

_ へ

ああ、アマゾンのブッックレビュー読んでびっくり。おれが持ってるのは「夜の果ての旅」で、これは「夜の果てへの旅」なのか！

これは、買わなきゃならんだろう。

下巻はある（上巻が見あたらないのだ）。

_ 影響

もし、僕の文章が誰かに影響されたものだとしたら、それは明らかにわかっているのだが、

高橋悠治、セリーヌ（生田耕作）、ADG（訳者は知らない）あたりのはずだ。というくらい、リアルに高校2年生のころに読んで読んだな。>夜の果ての旅（へなしバージョン）

_ ADG

_ 今日は映画の日

星になった少年象に乗る。

象がいっぱい出てくる予告編はすごくおもしろそうだったが、お涙映画だといやだな。

_ 星になった少年

想像と違ってタイの象使い学校の条りはそんなに長いわけじゃなかった。

インディジョーンズでも感じたが、他所の国の食い物を気持ち悪いものとして（主人公の目で）描いたシーンというのは、なんかすごく不快感を感じる。一応、食ってから合うか合わないかは決めたいものだ。なんか、象の糞を食べる甲虫とかヤモリかイモリの串焼き（こっちは最後にうまそうに食うけど。確かにうまそうだ）。

滝のくだりはなんかあまりにバカっぽく見えた。

説教はやだね。まるでジャッキーチェンの映画みたいだ。でも、まあしょうがないのかも。

母親がエキセントリック過ぎてなんかあまりに妙だったかも。

音楽は、どうしようもないな。シェルタリングスカイの使いまわしとかリトルブッダの使いまわしとか言われても信じてしまうようないつもの調子。もっともいつもの調子が欲しくて依頼するんだろうから、当たり前の話か。

映画として楽しめたのは、学校があるところに着いて行進とすれ違うところと、別れのところの横一列、学校での階段の上り下りのところあたり。葬式の象と弟のところ。

象がいっぱい出てきたからまあいいや。それにつけても不思議な動物だ。ああいうのが裏山をうろうろして人間と共存しているってのは、おもしろいな（本当にそうなんだろうか）。

_ 悲しい

メインマシンは突然落ちる。

MacはEmacsがハングする。

日本の夏は蒸すけれど涼しい

−−隣の印度人

_ とーきーはながれーる

いつの間にか出てる。

>ruby -e 'p 0008'
-e:1: syntax error
>ruby -e 'p 0010'
8
>ruby -e 'p 8'
8

_ tDiary

ちょっとしくった。

日記は書くだけじゃなくてフィードをちゃんとさせないとダメと。

_ 怖い話

文字列がイミュータブルなことは良いことに思える。

しかし、 むとぽんさんが出会った『怖い話』とか、富士通は『Java講座の第1回目』で何を教えようとしたか（追記：答えは、だから富士通が売っている開発規約違反検出ツール買えということだったりするわけだが、FindBugsとかCheckStyleとかもあるでよ）とか、『Sunの毒消し』（やり過ぎてもだめだし、それ強調しないでおくれよ、っていう感じ――追記。思い出しけど、こないだ確かに見たよ。文字列定数をappendしまくるおばかなコード。どうして因果律を考えも知ろうともせずにバカの一つ覚えで済まそうとするのか？）とか、なぜあるのか、と言えばあるんですな、これが。

String encode(String s) {
    String ret = "";
    for (int i = 0; i < s.length(); i++) {
        if (s.charAt(i) == '&') {
            ret += "&amp;";
        } else ... {
            ret += s.charAt(i);
        }
    }
    return ret;
}

とか、書く人が。さすがに見たことはないけどこんな処理をjavax.servlet.Filterでやられたらガクブル。

人のせいにするのは簡単だが、VBでは（イディオムじゃないな）

Dim s As String
...
s = s & "....."

だったりするし、ミュータブルなC++のbasic_stringも+=はそういう動作じゃなかったっけ（こっちは、メモリー再アロケーションのオーバーヘッドで僕が自分で死んだことがあったり）？ というわけで文字列＝イミュータブルという考えが無いとこうなるし、企業教育とかだと元ネタのソースがこれらの言語だったりすることもあるから、ありそうな話だ。というか、多分に直観的な記述なのではないかという疑いもある。で、こういう処理が多いのだな、実務アプリケーションだと。したがって、そこら中でStringオブジェクトが作られてはGCが動く。

上のはミュータブルな文字列バッファを使うのが正しい（これは上記の富士通やSunのページ参照。だからここには1.5で書いておく）。

String encode(String s) {
    StringBuilder ret = new StringBuilder(s.length() * 1.5); // 追記：1.5って何これ？
    for (int i = 0; i < s.length(); i++) {
        if (s.charAt(i) == '&') {
            ret.append("&amp;");
        } else ... {
            ret.append(s.charAt(i));
        }
    }
    return ret.toString(); // 1.5からはこうしたほうがプラグマティックには効率的だし、
                           // CharSequence#toStringと考えると筋は通っていると思う。
}

_ 黙々と実装

ソフトウエアはまずいところが有れば直せばいいんだから、開発者は殺伐と思いついたものを黙々と実装すればいいんじゃないかな、と開き直りつつある今日この頃

――てくのーと

その通りだと思う。

だから水だけ差すことにするけど（これはかんさん個人に対してじゃない、開発者というかんさんや僕やここ読んでる人全員のことだ）、だからこそ開発者は、最低限、既存の脆弱性のパターンとそれに対する回避方法についての実装知識（もちろん知ってるだけじゃだめでそれを使って実装すること）は抑えておく必要がある。それは32ビット整数に収まる演算――たとえばループカウンターとか――で済めばintを使うというのと同じレベルの当たり前なことで、利用者の善意とか悪意とかと無関係に、そうするのが当然、というレベルのことだ。

早い話が、『セキュリティエンジニアリング』はデフォルト。っていうか、情報処理技術者試験の1番ちょろいやつってここからガンガン出題してるんだろうか？ すべきだろうな。

_ バカの煮物

Bloglinesで見てたら字が小さいのでなんとなく獲物がそう見えて吹いた。

それが羹に懲りて獲物に吹くということかな。

_ VBacs

VBA Emacs（Visual Basic Emacsっていう表記はちょっと違う気がする）。

C-uがちょっと愉快な実装みたいだが。

ついに、MacではWordを本格的に利用するつもりになったので発見。

_ アフィリエイトプログラムのイマ

現在と書いてイマと読むのイマ。

SEshop.com Link Program (SLP)サービス提供終了についてというのを見たけど、勝負がついてしまったということなのか、それともたまたまSEshopの独自の判断なのか、どうなんだろう。

_ ふつう

ふつうのLinuxプログラミング Linuxの仕組みから学べるgccプログラミングの王道(青木 峰郎)

と言っても書いてる人がふつうじゃないからね。

だって、技術書にプレミアが付いちゃったりするわけだし。

何がふつうなんだ？

そうか、書いてる人がふつうじゃないからふつうじゃないプログラミングの本だと想像されると困るからふつうと言う必要があるのだな。

そうじゃないと、プラットフォーム別Linuxのインラインアセンブラの書き方とかがアルファを中心に出てるんじゃないかとか、シグナルの処理について延々と書いてたりするんじゃなかろうかとか、コンパイルしてテストが通ったらCVSへコミットしてメールで通知してっていうようなrubyのスクリプトの書き方が載ってたりするんじゃなかろうかとか、いきなりopen("/dev/mem", O_RDWR)とか始めるんじゃなかろうかとか、いろいろ想像されてしまうかも知れないからだ。

追記：ふむ。意識的にこのページを読んでる人ならともかく、たまたま「ふつうのLinuxプログラミング」で検索して来た人間がもし読んだら、誤解することはなはだしいかも知れないから、まともなことも書いておくか。

この入門書の「ふつう」は僕が読んだ限りじゃ、「common sense」のcommonのことだ。青木さんの本は、「独習する前」もそうだが、リテラシーを踏まえた上でのすっ飛び方だかったりするわけで、この本においても、Linuxプログラミングについての「ふつう」なあり方ということを主眼にしていると見た。だからおそらく青木さんから見て、「ふつう、それくらいは知ってるよね」の「ふつう」についての解説が主となる。で、それが吹っ飛んでると問題なわけだが（ふつうプログラミングといったらmodula-2だよね、というC入門とかなかったっけ？）、青木さんはその意味では信用できるふつうの感覚の持ち主だ。微妙かな。ちょっとold typeかも知れないかな。でも、考えてみればnew typeって以心伝心が強力な人なわけであまりソフトウェア開発には向かなさそうな気がするんだけど。

というわけで、この本は、ふつうLinuxはこうなっていて、Cでプログラミングするってのはふつうはこういうことで、これこれする場合にふつうはこうするというような1冊でプログラミング入門とUnixリテラシとその他の開発上の常識みたいなものが学べる本ということだ……というか、ふつうじゃないのが多いっていう反語でもあるんだろうな。

追記：本人が語る「ふつう」とは。

_ サーバー様

はてなキーワード。

物や概念に「様」を付けるとネ申が誕生するということを、おれは確かにこの眼で確認した。ありがたや。

物に様というと、軍服様に敬礼とか、貴様の体を軍服様に合わせるのだとかというような用例が先入見としてあるから、すごく気持ちが悪い。

それはともかく、これは構造も確かに同じだ。だからすごく不快な言い回しなのだ。

軍服様と言う（まあ、上等兵とかが言うわけだけど）やつは、二等兵の目の前にあるすさまじく窮屈でクビが絞まる3周りくらい小さい服のことを言ってるから始末に困るわけだが、その裏の妄念としては、文字通りこの軍服様というのが神からのタマモノだというものがある。実際には税金のなれの果てなのだが。（実際に物資が不足して何がなんでもそれを使わざるを得ないという場合とかもあるだろうけど、エクスキューズになってなさ過ぎる）

物に精神を注入してしまうということは、その物の実体を見失うことだ。楽だしな。考えなくて良いし（だからDIですよ）。様を付けた途端に絶対不可侵な神になるから、反論の余地もなくなる。

そこで、サーバー様に相談ですよ。

「なんか、同じ商品が3個分、明細に記録されているんですよ。でも実際には1個しか買ってないのですが」とクレジット会社に電話する。

「今、お調べしますね。ああ、確かに3個お買い上げになってますね」

「買ってませんよ。実際に1個しか届いてないし、それは通販会社の出荷記録を調べていただければわかるんじゃないですか」

「でも、3個お買い上げになられてますよ」

「買ってません」

「わかりました。サーバー様に相談いたします。ヒソヒソ。ちゃんと払え、ごるぁ」

とか

「永遠に再起動を繰り返すんですが……」

「わかりました。サーバー様に相談いたします。ヒソヒソ。天罰だそうです。功徳をお積み下さいませ。ガチャリ」

とか

「なんで、こんなわけのわからないクラスが出てくるんだ？」

「オブジェクト様のお告げです」

あ、これは見かけるな、実際に。

「なんで、ループの中で文字結合するんだ？」

「String様のお告げです」

とか

「なぜそこでrunを呼ぶ？ startを呼ばなきゃだめだろうごるぁ」

「Eclipse様のお告げです」（アルファベット順ということか？）

_ 別のJavaブリッジ

yajb。

javassistを使ってるところが特徴。

_ 大魔神

そういえば、「山神さまがお怒りじゃ〜、なんまんだぶなんまんだぶ」とたくさんの村人が地べたに這いつくばって拝みまくるって光景を思い浮かべやすい言葉だな。サーバー様って。

「サーバー様がお怒りじゃ〜、あなおそろしやなんまんだぶなんまんだぶ」と頭に注連縄と巻きつけた老婆が村の真ん中で大声を上げる。

飛び出す村人たち。

「ばばさま、何事じゃ」

「何事じゃ、何事じゃ」

あっというまに十重二十重に取り巻き不安におののきババサマの次の言葉を待つ村人たち。

「大変なんじゃ。村の周りに見知らぬ者ドモの足跡がたくさん見つかったのじゃ」

「なんとな」

「どこぞの不届き者じゃい」

口々に地団駄を踏みまくり踊りまくる無駄人たち。

ばばさま、得意満面に、

「わしゃな、さっそく、サーバー様を拝み倒してリファラログを見させていただいたのじゃ」

そこで一度黙って村人たちの顔を覗き込む。

固唾を飲む村人たち。

最初に口を切ったのはおっちょこちょいの吾作だ。いつものことだ。

「おお、見たのか、ばばさま」

やっと問い掛けてもらえてよほど嬉しかったのかばばさま、歯の無い口を大きく開けてそりゃあ嬉しそうに言ったもんだでな。

「おお、見たとも見たとも見やいでか」

ついに他の村人たちもわれ先にと放し始めた。

「で、どうだった？」

「どだったどだった」

ばあさま、大きく息を吸い込むと

「出てた、出てた、お告げが出てた」

と言ったもんだ。

「出てたか、出てたか」

「おお、出てた。やっぱり、そうじゃ、無断リンクじゃ」

それを聞くと、得心した村人たちはすぐさま

「おおそうか、やっぱり出たか、そりゃ一大事じゃ」

と自分んちの納屋めがけて駆け出した。そしてすぐに手に手に鎌やら鍬やらを持つと村の真ん中へ引返してきただ。おそろしかことたい。

「ばばさま、みんな用意はできた。さっそくリンクのお礼のお参りじゃ」

「お礼参りじゃ」

「お礼参りじゃ、ええじゃないかえじゃないか」

「それは違うがえじゃないか」

が、ばあさまは冷静だ。

「ま、待て、ゴンの姿が見えないようじゃが」

「お、そうじゃ、ゴンがおらんようじゃ」

「ゴンはどこじゃ」

と、よく見ると村1番の怪力の権の姿がない。

その時、裏山から巨大なサーバー様の御神体を手にゴンが走ってくるのが見えた。

「さすが、ゴンじゃ。大人衆8人がかりでも持てない御神体を独りで担いで駆けて来るわい」

「ほんに、立派なオノコだわい。わしがあと60若けりゃ逆夜這いをかけるというもんじゃに」

飽きてきた。

_ dRubyによる分散・Webプログラミング

dRubyによる分散・Webプログラミング(関 将俊)

献本いただきました。ありがとうございます。

マルチスレッドとかタプルスペースとかそこら中にオブジェクトがいっぱいとかで幸せを感じる人はぜひとも買いたい本です。

打ち込んでは試してないけど（すぐに試せるようにirbでの実行例がたくさん出てるけど、これは良い工夫だな――と試してない僕が書くのはだめか、今はWindowsマシンのほうを使ってるからだけど）例がいっぱい、図がいっぱい、とりあえず一通り眺めた感じでは、Webサーバーをフロントに置いて裏側をdRubyで繋ぐという使い方を主にしてるのだけど、なんかいろいろ考えつくことがあるな。それはそれとしてRindaっておもしろい。

_ FindBugs

開発のプロが教える標準FindBugs完全解説 ―Javaバグパターンの詳細と対策。

長い題だな。でも嘘は無いよ。

_ fair license

フェアライセンス

というか、http://rhid.com/fairが404なのだが。

少し違うのはあるがまだexperimentalみたいだ。

いずれにしろ、このライセンスは非常にシンプルで気持ちが良い。

debian-legalにexperimental版の投稿があるな。

The purpose of the license is to create a concise gift license. It

contrasts from BSD and MIT and most other gift licenses by being

"open-ended", rather than closed. That difference being that BSD and MIT

specifically state the exercisable rights, whereas this license

authorizes all the rights granted by authorship(all inclusive).

結構、良い感じに見える。gift licenseという言葉があるのか。

_ CodeZine

初心者シリーズ第2段。

スタックトレース。

_ 宇宙、それは最後の開拓地

スタックトレースってスタートレックのアナグラムだね。

_ やっとわかってきたこと

以前、.NETの属性がAOPどうしたみたいに書いてあるのに非常に違和感を覚えた。アトリビュートはクラスやメソッドの属性だから静的な情報に過ぎないわけで、頭の中の像はそれまで2次元のオブジェクトグラフをせいぜい3次元にするだけなのではないか（X軸がクラスの名前、Y軸がメソッドやフィールド、に対してZ軸として属性）、と感じたと言うことだ。つまり、それはインスタンスの情報ではない。

最近（ここ1年くらいか）やっとわかったのは、その見方はクラスの定義者側からの視点だから疑問に感じたのだなということだ。

実行時に与えられたオブジェクトが何者かを識別するのに現在のたとえばメソッドシグネチャでは表現不可能な情報を属性として得ることができるということは、定義自体は静的（クラスやメソッドなどの静的情報と不可分）だが、利用時には動的（あるインスタンスについての情報として利用）だということだ。すなわち、その情報は誰のものかという点について正しく認識できていなかったということである。

と、反省。

_ ケーススタディ）

あるIT企業の憂鬱。この記事を書いている人はうまい釣り師なのだが相変わらず大漁だ。

52件（注：いい加減にやっていったため、下の抽出は失敗してダブルカウントがあるようで数が合わない。面倒なので直さない）のコメントを分類してみる。定性分析なのでそのつもりで。

パターン１：子供 10件で全体の20%を占める

・記者の愚痴を聞かされている読者・・・(40代，システム・インテグレーター，研究・開発部門 )

・で、結局どのような意見を言ったのでしょうか?(30代，システム・インテグレーター，システムエンジニア )

・愚痴は嫌い？十分愚痴のコラムじゃないですか。◆なぜ匿名報道なのでしょうか。この会社に発注するリスクを、あなたは回避し、読者は負い続ける。不公平です。そして、あなたは卑怯です。(40代，その他，情報システム部門 )

・結論無き記事は駄文である(30代，ハード・ソフトベンダー，研究・開発部門 )

・興味深いので続きをお願いします。（提案したご意見の内容とこの会社のその後）(30代，システム・インテグレーター，研究・開発部門 )

・他の方もコメントされていますが、結論がないので単なる愚痴になってますよね？（略）(20代，システム・インテグレーター，システムエンジニア )

・（略）なんだかなぁ、中身のない「日記」だよなぁ。 (30代，システム・インテグレーター，システムエンジニア )

・だから谷島はいったい何を言いたいんだかさっぱりワカラナイ。

・谷島さんが考えてること？ そりゃあもう「IT Proサイト昨日のBest10」で１位になって、こっそりほくそ笑むこと。(30代，ユーザー企業，情報システム部門 )

・（略）他の方が書かれた記事同様尻切れな内容にはあまり満足しません。（略）

パターン２：知ったか　8件

・「経営者がやるべきは“組織”を作ることである」これに尽きると思います。（略）(30代，ユーザー企業，一般ユーザー部門 )

・ここにはＩＴ企業となっていますが有る程度成熟してきた企業ではよく有ることに思えます。（略）(40代，ユーザー企業，情報システム部門 )

・（略）小規模な会社では幾らでもある、普通の話題だと思うからです。（略）(40代，ユーザー企業，情報システム部門 )

・この記事は谷島編集委員の日経BP社に対する想いとして解釈すると執筆の動機が判りやすいと思う。(30代，その他，企画・マーケティング部門 )

・この会社（社長？）問題分析とその後のアクションに関する社内合意のプロセスを全体で共有出来ていない。あるいは、そのスキルが無いだけなのでは？（記事だけでは正確な事はわかりませんが）(40代，その他，コンサルタント )

・最近、ビジネス文書の書き方がわからない人が増えていますね。みんな忙しいので、はじめの数行で意図がわからなければ、読まれません。雑誌の記者もそのようでは、日本のビジネス文章力は落ちているのだろうか？(30代，ハード・ソフトベンダー，研究・開発部門 )

・読み物としては面白かったです。内容はありきたりですがね・・・。（略）(30代)　（注：インチキ3点リーダーが知ったかぶりを際立たせていて興味深い）

・上位の管理職になる程、バランス感覚の欠如が致命的になる。（略）(40代，システム・インテグレーター)

パターン３：ケーススタディとして読む（知ったかとは異なり何らかの分析/推測/知見を伴う）　10件

・この問題はIT業界にもならず、わが国の多くの企業にいえるのではないでしょうか。（略）2007年問題が片付いたら、過去の成功体験を生んできた人々が去り、新たな方向性が見えてくるのではないでしょうか。(50代，システム・インテグレーター，企画・マーケティング部門 )

・この話って、今国会で審議されている郵政民営化法案の政府と与党のやり取りと似ていますね。（略）(50代，その他，コンサルタント )

・（略）私見ですが、これは経営者や管理職が、経営者や管理職としての仕事をせずに、いつまでも担当者の感覚で仕事をしているからという事につきるのではないでしょうか？（略）(30代，ハード・ソフトベンダー，研究・開発部門 )

・（略）もし、この社風を変えたいのなら、会長自ら、社長自ら、「まず他人の話を聴く」ようにする必要があるのではないかな、と感じました。(40代，ハード・ソフトベンダー，コンサルタント )

・（略）改革というより再起業ですね。(30代，その他，一般ユーザー部門 )

・（略）私にも過去に、社長のように空回りの経験がありました。やりかたも変えてみたのですが結果として成功しませんでした。(70代，その他，経営者 )　（注：子供ではない）

・blog に意見を書きました。（略）(40代，ハード・ソフトベンダー，システムエンジニア )

・提案内容の予想：（略）(30代，ユーザー企業，情報システム部門 )

・（略）このお話を愚痴として読むだけで済ませてしまうことこそ危険な気がする。(30代，システム・インテグレーター，システムエンジニア )

・記事を読む限り、諸悪の根源は、会長と社長ではないかと。（略）(40代，システム・インテグレーター，研究・開発部門 )　（注：しかし「前科」って……こいつは何様だ？）

パターン４：提案型　8件

・これは、同族企業の典型的な例ですね。（略）(50代，ユーザー企業，企画・マーケティング部門 )　（注：一見、知ったかパターンだが、実は興味深い……かな？ 知ったか分類でも良さそうな気もする）

・今回の社長が自分が見つけた問題点をすべて指摘しているようですが、（略）(20代，ユーザー企業，情報システム部門 )

・こういう問題が起きるのは、社員・役員のベクトルが合っていないからでしょう。（略）(50代，ハード・ソフトベンダー，経営者 )

・評論は総論各論いろいろあるだろう。（略）(40代，システム・インテグレーター，システムエンジニア )

・（略）◆実践的なツールとしては、コーチングなんかいいんじゃないでしょうか？以前日経ビジネスアソシエの誌上でやっていた研修を見る限り、こういう問題に効き目がありそうに思います。(20代，ハード・ソフトベンダー，研究・開発部門 )

・コミュニケーションの問題ですね。（略）(40代，ユーザー企業，コンサルタント )

・社長のトップダウンだけではなく、若手中心の事例発表会などを開けば、もっとよくなるとおもいますが、中堅以下でそれがうまくいっている会社は少ないようです。(30代，システム・インテグレーター，システムエンジニア )

・ゴールが共有できてないのでは？（略）(40代，システム・インテグレーター，システムエンジニア )

・☆私の提案は以下のとおりです。（略）(40代，その他，コンサルタント )

パターン５：振り返り型　（パターン３に合わせても良かったな）　6件

・（略）社内カンパニー制を導入することが一考。10年後を考えれば、現経営陣の総退陣も善しとせねば。。(40代，その他，システム企画部門 )

・読んでいて自分の働いている会社のことかと思ってしまいました。（略）(40代，その他)

・リアリティある実例として興味深いと思いました。結論が無いとの批判がありますが、その通りにすればうまくいく「正解」を与えられるのを期待しているところに、日本の教育体制等含めて問題があるのではないか、とむしろ思いました。自分で考え抜いた解決策ではない、既存の定型的解決策など与えても、そもそも現実の仕事では意味がありません。(30代，ハード・ソフトベンダー，研究・開発部門 )

・（略）中小企業は創業者と企業の寿命に従って死ぬのが自然の摂理。無理な延命は迷惑です。(30代，システム・インテグレーター，システムエンジニア )　（注：一見、単なる知ったかパターンに見えるが社長に立場を寄せている点が特殊なのでここへ分類）

・うちの会社が、今まさにそのとおりです。（略）(40代，システム・インテグレーター，研究・開発部門 )

・中途入社として、似たような状態を改善する立場にあるので、笑えない話である。（略）(40代，ハード・ソフトベンダー，企画・マーケティング部門 )

パターン６：ちゃちゃまたは説教または無力感の表明（子供とは明らかに違い、他人に読ませることを意識はしているように感じる）　10件

・大変参考になったが、谷島さんの思いとはおそらく異なり、ITユーザーの立場である読者としては、このIT企業の実名を知り、ここには発注したくない、と言う気持ちになってしまった。(50代，ユーザー企業，システム企画部門 )

・"筆者なりの考えを伝えた"とありますが、ここを含んだ続きが、ぜひ読みたいですね。(30代，システム・インテグレーター，システムエンジニア )

・（略）「やってみせ、言ってきかせて、させてみて、 誉めてやらねば人は動かじ」言って聞かせただけで人を動かせれば苦労は無いですよ。(50代，その他，システム企画部門 )

・いやぁ、どの業界でも脳みそ筋肉系の人はどこにでもいるものです。 IT業界はそれではいけないのですが・・。(30代，システム・インテグレーター，システムエンジニア )

・（略）この冒頭の会話に、この会社の問題が全て含められている気がしています。（略）―（注：匿名。提案型に見えて知ったかにも見えるが実は単なるヤジウマのようだ）

・●社長は多分、欝ですね。（略）(40代，通信事業者，研究・開発部門 )

・（略）ブログではないのですから、読者との対話でこの話題を発展させるのは難しいと思います。(40代，ハード・ソフトベンダー，情報システム部門 )

・（略）読者全員が記者のファンであり経歴を知っているわけではないことを意識してほしいです。

・（略）やっぱり記事は読まれないと意味がないという例だと思います。(30代，ユーザー企業，経営者 )

・応援している政党によっても社内で分裂しちゃうんですよね。（略）(30代，その他，研究・開発部門 )

失敗した。時間軸に沿ったパターンの推移も考慮に入れるべきだった。

意外なほど、ちゃちゃじゃないように読めるなんらかの提案をしているコメントがあるのが予想外だった。また年齢、職業とコメントの内容には傾向はなく散らばっているように見える。

_ 727

シメトリカル。

昨日みたいに、午後に猛烈な雨が降るとその日は結構ご機嫌なものになるのかな？

（ちょっとだけ違う）

_ publishedとpublic

wildcatsさんの「私が思うリファクタリングとリストラクチャリングの違い」を読んでいて（というか、そのコメント欄でのやり取りを読んでいて）考えた。

概念的にフレンドアクセスとそれ以外の2つに分けて、フレンドにはclassを触らせることを許可して、それ以外にはinterfaceしか触らせないようにする。ではどうだろうか？

classにpublicなメソッドがあっても、それがinterfaceに定義されていない場合、それはフレンド用であって外部には触らせないということだ。すなわちpublicではあるが非published。

この場合、javadocはinterfaceのものしかpublishしない（javapして解析して呼ぶような相手の場合は、そもそも考慮しても無駄だから置いておくことにする）。

パッケージ0　→　パッケージ1　←　パッケージ2

として、パッケージ1はinterfaceが定義されていてJavadocのpublish対象。

パッケージ0は実装そのもの。パッケージ2はパッケージ0の利用者（しかしパッケージ1経由でしか利用できない）。

以前だとパッケージ1にはパッケージ0に対するファクトリを入れておく必要があったと思うし、その呼び出しの手間とか考えるとパッケージ2の開発者から拒否反応が出そうな気もするが、今であればパッケージ1とパッケージ0のマッピングはDIによって実現できるからそのほうが（ファクトリの実装を不要化できるから）お互いに楽だと思う。

ただ、複数の責務を持つpublishedなメソッドって別に構わないと思うので（サービスだ）そこは違和感を覚えた。レイヤー分けの問題に過ぎないと思うからだ。具体的にはpublishedなメソッドの中で複数の単責務なメソッドを呼び出すという考え方を取れば良いし、その単責務なメソッドを同一パッケージ内の複数のクラスやあるいは同一クラスの複数のメソッドとして分ければよいのではなかろうか？ というか、外部へ公開するということはそういうことだと思う。複数のメソッドの呼び出しには呼び出し順序の依存やステートの遷移が伴う。したがって、1回の呼び出しで済ませられるのであればそのほうが単に呼び出し側の利便性が向上するだけではなく、状態遷移の制御も単純化できると思う。（追記：ファサードのことだな）

追記：だから、そういう風に再構成すれば、外部インターフェイスは変わらないよね？ そこがなぜ、他のクラスに影響を与えることになるのか不思議なのだが。

public void createHTML(String fileName) {
　　Bean bean = new Bean();
　　// Beanに対する設定
　　// HTMLの作成
　　VelocityContext context = new VelocityContext();
　　context.put("bean-name", bean);
　　BufferedWriter writer = new BufferedWriter(new FileWriter(fileName));
　　Template template = Velocity.getTemplate(vmName);
　　template.merge(ctx, writer);
　　writer.flush();
}

public void createHTML(String fileName) throws IOException {
　　Bean bean = buildBean();
    writeToHtml(fileName, bean); // 追記：メソッド名を変えた
}
public Bean buildBean() {
    Bean bean = new Bean();
　　// Beanに対する設定
    return bean;
}
public void writeToHtml(String fileName, Bean bean) throws IOException {
　　// HTMLの作成
　　VelocityContext context = new VelocityContext();
　　context.put("bean-name", bean);
　　BufferedWriter writer = new BufferedWriter(new FileWriter(fileName));
　　Template template = Velocity.getTemplate(vmName);
　　template.merge(ctx, writer);
　　writer.flush();
}

と変えても外部インターフェイスは変わらないと思うんだけど。

_ インターフェイス

インターフェイス変更恐怖症はCOMコンポーネントをバカスカ作ってた頃に身に染みたという経験から来てる。

あの世界だとC++とVBの間には溝があるからそれは恐ろしいことが起きる。

でも、考えてみたらa.jarを参照しているb.jarをそのままにしてa.jarが勝手にインターフェイスを変えたら、同じように恐ろしいことが起きるね。ActionErrorsがActionMessagesになるとか。関係ないか。

_ 掌が赤い

PowerBookのせいだ。厄介なコンピュータだな。

dRuby本のUMLがきれいだけど、これはOmniGraffleだからだろうな。とOmniGraffleでUMLを書きながら思った。

でも、シーケンス図のジョイントがうまく行かないんだが。なんか生存線が全然生存線として使えないような。

_ 笑った

クラムボンは笑ったよ

的外れで笑ったよ

なぜ

題に書いてある

水の上から見ればぷかぷか

水の下から見ればかぷかぷ

シュアロジカリー

でもそれはでたらめかも

だってボンはボムだから

クラムボンは爆発したよ

ほんと？

知らない

_ メモ

Weblogic 6.1 (service pack 5 is required for Weblogic 6.1 due to bugs in the ServletFilter implementation 6.1)

-taglibs-user

SP3

解決済みに見えるが、っていうかどのバージョンを使ってるんだ？

_ デバッグ能力

何かそうじゃない別のものもあるような気がします。

おくじさんのところ。思い当たる点がある考察。確かに不思議だ。

_ 狩猟と農耕

子供と話していて、

「槍の先端が重くて尖ったのはいつごろか知ってる？」と子供。

「鉄を利用できるようになったことが原因だろうから、弥生時代だろうな」

「当たり」

というところから、狩猟民族より農耕民族のほうが戦争をしまくり、虐殺をしまくり、血に飢えた恐ろしい民族であるという結論にたどりつく。集団で土地を囲って手間隙かけて水を引いたり開墾したりすると、兵糧もできるし人数も多いから戦争もしやすい道理だ。奴隷の使い道もある。鉄の利用は農耕具のためではなく武器のためだというところも興味深い。

確かに世界の農業生産とか見ると、血に飢えたゴール人、血に飢えたアングロサクソン人の国が農業生産国（農産物輸出大国）だ。

あの連中が狩猟民族や（19世紀以降に生まれた）工業民族（これはまだ奴隷の使い道があるからだめかも）や情報民族（こうなると奴隷なんて不要だから相当良さそうだが何を食って生きるのか良くわからない）に変わってくれると世界が平和になるのかも、と思ってみたりしてみたり。

_ ソウヤー

ヒューマン -人類- (ハヤカワ文庫 SF (1520))(ロバート・J・ソウヤー)

ふーん、読んでみるかな、と思ってamazonで見ると、どうも続き物らしい。

で、第1作らしいのを見てみると、たださんが星5個つけてるな。ってことは本当におもしろいんだろうから、秋の読書週間用に買うことにしてみよう。

_ 結局

注文した。

_ すげぇ

例の中の例。

まさに例だ。こういう内容を書ける人間は少ないが、それを例として書ける人間はもっと少なそうだ。っていうか人物像がちゃんとあるのがミソなのか。っていうことは、読者像もきちんと想定できるってことなんだろう。うーん、いろいろ教えられる。

_ 練習してみる

男/女/年齢/学歴/職業/思想/嗜好/

まずは、こんなのが来たらいやだなからかな。それは簡単そうだ。

■あなたのお名前

紋切まさし

■メールアドレス

monkey@example.com

■あなたはどんな方？（お仕事や年齢、趣味など）

IT業界勤務。PC自作

■最近あったうれしいこと、かなしいこと

うれしい：特になし

かなしい：特になし

■結城の本を読んだことがあれば、その感想など

ない

■結城に「こんな本を書いてほしい」というご希望があれば

ない

■そのほか、結城の活動に関して、感想をご自由に

ない

……orz 変なのを想定してしまった。もっと軽いのを考えてみる。

■あなたのお名前

子供くんた

■メールアドレス

kuntakinte@example.com

■あなたはどんな方？（お仕事や年齢、趣味など）

登山が好きで、高い山の上から下界を見下ろしながらプログラミングをするのが趣味です。でも、山の上だとgoogleできないのが難点です（PHS使用）。

■最近あったうれしいこと、かなしいこと

うれしいことと言えば、仕事が一段落したのでやっとEP3を見に行けました。これで話がつながってすっきり。

でも、アナキンがかわいそうで気分が落ち込んでます。

■結城の本を読んだことがあれば、その感想など

すみません、ありません。

■結城に「こんな本を書いてほしい」というご希望があれば

モヒカン族のためのパターンランゲージ入門をぜひお願いします。

僕も仲間に入ってトマホークを投げてみたいのですがessaさんのは難しいしotsuneさんのは個別事例が多くて入門には向いていないと感じています。ここはぜひ結城さんにお願いしたいと思います。

■そのほか、結城の活動に関して、感想をご自由に

すみません。実は良く知らないんです。

---

■あなたのお名前

魚

■メールアドレス

tanuma@example.com

■あなたはどんな方？（お仕事や年齢、趣味など）

魚です。世界が丸く見える事を活かした職業につきたいと思っているのですが、今のところ水槽の中で泳ぐことくらいしかできていません。

■最近あったうれしいこと、かなしいこと

最近、河川がきれいになったようで仲間が増えて幸せを感じています。でも、水が清くなり過ぎると棲めなくなるので、行き過ぎないか不安に感じ始めています。

■結城の本を読んだことがあれば、その感想など

デザインパターンの最初のやつを読みました。GOFには挫折したのですが、ちゃんと通読できて良かったと思います。特にNullオブジェクトパターンは好きで良く煮込みにして食べています。

■結城に「こんな本を書いてほしい」というご希望があれば

UMLの書き方の本が欲しいです。これまで何冊も読みましたが全部、挫折しました。原因を考えるとコードと図をマッチさせていないからだと思います。つまりデザインパターンと同じことだと思います。したがって結城さんが書かれたUMLの書き方の本ならちゃんと読めると思います。

■そのほか、結城の活動に関して、感想をご自由に

----

難しい理由がわかった。現実の結城さんが設問に出て来るからだ。したがって後半の記述の自由度が乏しい。前半を、女子高校生とか小学生とかITプロコメンテーターとか具体的に設定すると、後半に結びつけられない。たとえば前半をITプロコメンテーター（40代，システム・インテグレーター，研究・開発部門）にすると後半がどうなるかは原因と結果だが、いくらネタでもそんなもの書けるはずが無いからだ。

そのため、後半と前半を切り離す必要が出て来る。すると後半の想定がどうしてもIT業界人（特にプログラマ側）に寄ってしまう（このあたりが限界なんだろう）、すると前半が紋切り型しか想像できないので、でたらめになってしまうようだ。