古いブログ http://dev.ariel-networks.com/blog/ からの移行です。

古いブログはログインできなくなって、エントリの追加も編集もできなくなりました。 こちらへリンクを張る最後のエントリぐらい書きたいです。まあドメインが同じなのでこれは些細な話です。

問題は、昔の文書を手直しする手段が無いことです。電子化している意味が無いので最悪です。 来週、ここの管理者に裏技でも何でもいいので、手段を聞きます。 SQLのupdateしか手段が無かったら、嫌だなあ。

ぼくが嫌いなWebサイトはリンク切れの多いサイトです。今回のアリエルエリアの移行はプロが行ったので、リンク切れはたぶんありません。これは素晴らしい点です(古い技術文書のCSSが失われていますが、些細です)。 移行によるURLの変更で最も理想的な姿は、301 Moved Permanentlyのステータスで文書単位で新しいURLにリダイレクトする形です。 時々、404 Not Foundの代わりに、リンク切れになった文書は全てトップページにリダイレクトするサイトがあります。一見親切なようで全くダメです。トップページに戻されても、読みたかった文書の新しいURLなんて探せません。

Plone/Zope初体験です。 ソフトウェアは慣れてしまうと見えない部分がでてきます。

余計な知識が無い今、素直な印象を書いてみます。

ナビゲーションに慣れません。一貫した操作感を感じません。 図を使って説明してみます。

トップページです。「ホーム」と呼ばれています。これには違和感はありません。「ホーム」の下の「ブログ」に入るために、上に並んだメニューの「ブログ」を選択すると、次の画面に遷移します。

画面の上の方の「現在の場所:(ぱんくずリストらしき部分)」が「ホーム->ブログ」になりました。その後ろの「->ありえるえりあ」が謎ですが、とりあえず、ホームの下のブログ(と言う場所)に至ったことは分かります。 ファイルパス風に書くと/ホーム/ブログ/です。ここまでは直感的なナビゲーションです。

しかし、この下に移動するには、画面右の「井上Blog」のリンクをクリックする必要があります。クリックすると次の画面に遷移します。

ぱんくずリストもどきの現在の場所を見ると、/ホーム/ブログ/井上Blog/に移動できたことが分かります。ぼくがUIから受けた理解では、この下には「コンテンツ」もしくは「エントリ」が置かれます。ここにあるエントリ一覧を見るには、ボタンメニュー(画面右上)の「エントリ一覧」をクリックします。すると次の画面に遷移します。

ぱんくずリストもどきを見ると現在の場所は変わっていません。最初の3つの画面はcd相当の操作ですが、エントリ一覧のクリックはls相当の操作なので、場所は変化しません。一覧の「移行の一歩」の文書エントリをクリックすると、次の画面に遷移します。

ようやく目当ての文書にたどり着きました。

一応言っておくと、自分の文書に関しては、「マイフォルダ」というショートカットがあります。ショートカットはともかく、階層構造をたどるナビゲーション操作に一貫性が無い気がします。

ぱんくずリストもどきの「現在の場所:」を示す行の最後の「->ありえるえりあ」の部分は謎です。最後の5枚目の画像で、この行の「移行の一歩」のリンクをクリックすると、URLが http://dev.ariel-networks.com/Members/inoue/transition/ から http://dev.ariel-networks.com/Members/inoue/transition に変化しました。

挙動が謎すぎて理解できませんが、たぶん深遠な意味があるのでしょう。

http://www.bookshelf.jp/soft/meadow.html (必読) から http://jdee.sunsite.dk/ のJDEE(Java Development Environment for Emacs)をインストールしました。

日本語の説明:

http://www.alles.or.jp/~torutk/oojava/meadow/index.html

Debianなら次のようにインストールできます。

# aptitude install jde

JDEEの凄い所を説明します。

<project name="MyTest" default="compile" basedir=".">
  <property name="src" location="."/>
  <property name="build" location="."/>
  <target name="compile">
    <javac srcdir="${src}" destdir="${build}" debug="on" />
  </target>
  <target name="junit" depends="compile" description="Run JUnit Tests">
        <junit printsummary="on" fork="false" haltonfailure="false" failureproperty="tests.failed" showoutput="true">
            <formatter type="brief" usefile="false"/>
            <batchtest>
                <fileset dir="${build}">
                    <include name="**/Test*.*"/>
                </fileset>
            </batchtest>
        </junit>
         <fail if="tests.failed">
        tests.failed=${tests.failed}
        ***********************************************************
        ****  One or more tests failed!  Check the output ...  ****
        ***********************************************************
        </fail>
    </target>
</project>

public interface StrConcat {
    void pushString(String str);
    String getResult();
}

2. 実装

上のinterfaceの実装クラスを作ります。StrConcatImpl.javaファイルを新規作成して、次のコマンドを実行します(jde-gen-なんとかが、コード自動生成のコマンドです)。

M-x jde-gen-class

次のように質問があるので適切に答えます。

Packge: (テストのため無視。そのままエンターキー)
extends: (テストのため無視。そのままエンターキー)
implements: StrConcat (を入力)

次のソースコードが自動生成されます。本当は先頭にファイル説明コメントがありますが、削っています。 (引用の都合で空行は削っています)

public class StrConcatImpl implements StrConcat {
    public StrConcatImpl() {
    }
    // Implementation of StrConcat
    /**
     * Describe <code>getResult</code> method here.
     *
     * @return a <code>String</code> value
     */
    public String getResult() {
        return null;
    }
    /**
     * Describe <code>pushString</code> method here.
     *
     * @param string a <code>String</code> value
     */
    public void pushString(String string) {
    }
}

予想を裏切ってStringBufferではなく、StringBuilderで実装したソースが次です。 (引用の都合で空行を削っています)

public class StrConcatImpl implements StrConcat {
    private StringBuilder sb;
    public StrConcatImpl() {
        sb = new StringBuilder();
    }
    // Implementation of StrConcat
    /**
     * Describe <code>getResult</code> method here.
     *
     * @return a <code>String</code> value
     */
    public String getResult() {
        return sb.toString();
    }
    /**
     * Describe <code>pushString</code> method here.
     *
     * @param string a <code>String</code> value
     */
    public void pushString(String string) {
        sb.append(str);
    }
}

getResult()メソッドで、sb.の後ろにカーソルがある状態でC-c C-v C-.と打つと、次のようにメソッド名の候補が表示されます。先頭の文字を入力してC-c C-v .と打つと補完入力してくれます。さようならEclipse。

3. デバッグ

コードができたらビルドします。 M-x compileと入力します。Compiler command:を聞かれるので、次のように入力します。

Compile command: ant -emacs 

すると、次のようにコンパイルエラーが見つかりました。

慌てず、antのエラー表示行でC-mキーを押します。すると、エラーのある行に自動で飛びます。

public void pushString(String string) {
    sb.append(str);
}

interfaceの定義では、メソッドの引数の名前をstrにしていたのですが、自動生成したコードの引数名はstringになっています。この辺は自動生成の弊害でしょうか。とりあえず修正してビルドが通ることを確認します。

4. テスト

次にJUnitを利用したテストコードを書きます。 テスト原理主義者からは、テストコードを書く順番と実装クラスを書く順番が逆だと怒られそうですが、気にしません。今日はJDEEの説明が目的です。

TestStrConcat.javaの中身(引用の都合で空行は削っています)

import junit.framework.TestCase;
public class TestStrConcat extends TestCase {
    private StrConcat sc;
    public void setUp() {
        sc = new StrConcatImpl();
    }
    public void testSimple() {
        sc.pushString("foo");
        assertEquals(sc.getResult(), "foo");
    }
    public void testNull() {
        sc.pushString(null);
        assertEquals(sc.getResult(), "");
    }
}

build.xmlはファイル名の先頭がTestで始まるファイルを勝手にJUnitのテストコードと認識するようになっているので、M-x compileの後、次のように入力します。

Compile command: ant -emacs junit

次のようにテストが見事にこけました。

またまた慌てず、antのエラー表示行でC-mキーを押します。テスト失敗の該当行に自動で飛びます。nullを渡したケースを考慮していなかったので、次のように修正します。

public void pushString(String str) {
    if (str != null) {
        sb.append(str);
    }
}

再びM-x compileします。 無事にテストが通りました。こんな短いコードのコンパイルと実行に8秒もかかっているのが泣けますが。

悲しいこと。 JDEEをいれてからEmacsの起動が重くなりました。 一ヵ月後にはアンインストールしているかもしれません。

この設定画面で音ファイル(wavファイルのみサポート)を設定すると、AirOne(ProjectAおよびマルスケ)に新着メッセージが届いた時に音がなります。

寂しがりやな人は設定してください。

codeblog<https://www.codeblog.org/blog/inoue/>にmod_authn_dbdの記事を書きました。

今後、apache関係の話はcodeblogに書きます。apache以外の話は、今まで通り「ありえるえりあ」に書きます。

少し前にreStructured Textに慣れたと思えば、今度はtDiaryです。表記の微妙な違いを覚える気が失せてきます。tDiaryは自分でいじらないと画面に何も無いので、調べるか誰かに聞きます。

メールを整理していたら、約2年半前に自分が書いたメールを見つけました。

Subject: [airone-dev:07728] CSSパフォーマンス(v2後の研究課題?)
Date: Fri, 08 Aug 2003 23:26:25 +0900 (JST)
From: INOUE Seiichiro <inoue@ariel-networks.com>

参考
http://jt.mozilla.gr.jp/xpfe/goodcss.html

理屈では分かっていましたが、パフォーマンス的には、IDやクラスをつけまくるのが良いと読めます。

しかし、理論上は良いとは思えません。
結局、IDをつけることは新タグを作るようなもので、IDをつけまくると、HTMLと違う別のスキーマ
を持つようになってしまいます。
クラスをつけまくると、見栄えのために構造が影響を受けてしまいます。
美しさと効率が相反する、悩ましい部分です。

子孫セレクタ指定が(劇的に)遅いのは昔から分かっていたことですが、
IE5がCSS1サポートで、子セレクタが使えないので、やむなくAirOneでは使っています。

引用
> ダメ - treehead treerow treecell { }
> マシだが、まだダメ (次を参照) - treehead > treerow > treecell { }
> 完璧 - .treecell-header { }

パフォーマンス的には完璧かもしれませんが、プログラマ的感覚からすると、
「変数のスコープを大きくして直接参照すれば速い」、と言っているようにも見えて、
全面的に賛成とは言いにくいです。
とは言え、パフォーマンスは目前の問題ではあります...

「IDやクラス指定をした場合タグ名を付けるな」、というのは想定外でした。
ぼくの脳内HTMLレンダリングエンジンは、タグから先にマッチすると思っていたので、
table.movebtn tr .button
より
table.movebtn tr td.button
の方が、ムダなマッチングが少ないと思っていました。

IEがどうかは不明です。MozillaがIDやクラスから先にマッチさせるなら、同じかもしれません。

昔のAirOneはIE5をサポートしていたため、子セレクタの指定を使っていません(すべて子孫セレクタ)。今はIE5がサポート外なので、子セレクタにして少しパフォーマンスを稼げるかもしれません。

去年(2005年)の反省です。

ありえるえりあで偉そうにプロジェクト管理について語っていながら(http://dev.ariel-networks.com/column/pm/working_on_project/view)、ことごとく同じ過ちを繰り返しています。やってはいけないと頭では分かっているのに失敗します。分かっていることと実践できることは違うということを思い知らされています。

去年PM的な立場の仕事をしました。今までの経験の中で最悪でした。勝てば選手の力、負ければ監督のせい、です。失敗の責任はぼくにあります。その時の記録が詳細に残っています。(ぼくは監督を解任されましたが)後学のために、記録を読み直してみました。一体、どこでどう間違ったのでしょう。

分析の結果分かったことは、前から分かりきっていたアンチパターンにことごとくはまっていたことです。

代表的なアンチパターンを3つ挙げると次のようになります。

• 常に70%から90%の達成率が報告されている
• 最初(初日)から遅れが発生している
• 次から次へ想定外の問題が起きている

説明します。 記録を読み直すと、ほぼ毎日、70%から90%の達成率が報告されていました。試験なら70点でも及第点、90点なら良くやった、と言うところですが、プロジェクトの進捗報告の場合、100点以外は全部落第と肝に命じるべきです。70%から90%の日があっても、他の日に120%があれば平滑化されるのでは、と思うかもしれません。残念ながら、100%を越える達成率はほとんど起こりえないと考えるべきです。毎日平均的に80%の達成率だと、1週間で1日分の遅れがでます。1ヵ月あると約1週分の遅れになります。去年のプロジェクトの期間は約4ヵ月でした。後に述べるような要因も含め、約1ヵ月分の遅れがでました。最悪です。

「完了」以外の報告なんて信用するな、は頭では分かっていたはずです。分かっていてもこのざまです。たぶん監督として無能なのでしょう。

100%に満たない達成率は初日から発生していました。立ち上がりが悪いだけで、慣れてくれば良いパフォーマンスを見せるだろうと思っていました。これが甘かったです。このような甘い予測は断ち切るべきです。

次から次へ想定外の問題が発生して遅れが更に加速しました。しかし、想定外の問題が発生するのは不思議なことなのでしょうか。ぼくはそう思っていません。ソフトウェアの開発において、分かりきったことは最初から問題になりません。ルーティンワークは自動化されます。つまり、ソフトウェア開発で人間が手を出す部分は、そもそも何が起きるか不透明な部分なのです。少なくとも、アリエルネットワークがやる仕事は、手順に従ってルーティンをこなしていけば時間とともに何かができる、と言った仕事にはなりません。

ソフトウェア開発のプロジェクトでは、新しいこと、想定外のことが起きるのを常態と考えるべきです。「いずれ慣れてくれば効率が上がる」という幻想を打ち破る時がきました。常に新しいことが起こり続ける以上、慣れることはありません。つまり、「慣れていないので進捗があまり良くありません」という言い訳をした人間は、その後もずっと進捗が遅れ続けます。「慣れていないから遅い」という言い訳は、「新しいことへの適応が遅い」と読み替えるべきなのです。

選手としてのぼくは、決して新しいことへの適応は早くありません。アリエルには大谷さんのように軽々と適応吸収する凄い人もいますが、ぼくは違います。そんなぼくがなんとか(選手としては)生き延びているのは、休みの間に予習をして溝を埋めているからです(予習をしておかないと不安、という小心者でもあります)。

2006年、鬼監督が就任予定です。2005年の反省を活かすことを考えてみます。ぼくは監督を解任されたので、次期監督の助けになることを願っています。

最初の週から100%以外の達成率は認めないことです。90%の達成率は借金をしているようなものと考えるべきです。達成率が90%なら10万円の借金です。「まだ慣れていないから」や「始めたばかりだから」という言葉に耳を貸してはいけません。借金は自動的に無くなることはありません。その週に作った借金は、確実に返済させるべきです。土曜、日曜に返済させない限り、間違いなく借金地獄になります。