Personal tools
You are here: Home ブログ 井上 Categories カテゴリなし
« December 2010 »
Su Mo Tu We Th Fr Sa
      1 2 3 4
5 6 7 8 9 10 11
12 13 14 15 16 17 18
19 20 21 22 23 24 25
26 27 28 29 30 31  
Recent entries
Apache2.4のリリース予定は来年(2011年)初め(あくまで予定) inoue 2010-12-23
Herokuの発音 inoue 2010-12-20
雑誌記事「ソフトウェア・テストPRESS Vol.9」の原稿公開 inoue 2010-12-18
IPA未踏のニュース inoue 2010-12-15
労基法とチキンゲーム inoue 2010-12-06
フロントエンドエンジニア inoue 2010-12-03
ASCII.technologies誌にMapReduceの記事を書きました inoue 2010-11-25
技術評論社パーフェクトシリーズ絶賛発売中 inoue 2010-11-24
雑誌連載「Emacsのトラノマキ」の原稿(part8)公開 inoue 2010-11-22
RESTの当惑 inoue 2010-11-22
「プログラマのためのUXチートシート」を作りました inoue 2010-11-19
「ビューティフルコード」を読みました inoue 2010-11-16
Categories
カテゴリなし
 
Document Actions

カテゴリなし

Up one level

Document Actions

移行の一歩

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

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

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

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

The URL to Trackback this entry is:
http://dev.ariel-networks.com/Members/inoue/transition/tbping

Plone/Zope印象批評1

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

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

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

/Members/inoue/images/plone-impression/plone-nav1

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

/Members/inoue/images/plone-impression/plone-nav2

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

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

/Members/inoue/images/plone-impression/plone-nav3

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

/Members/inoue/images/plone-impression/plone-nav4

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

/Members/inoue/images/plone-impression/plone-nav5

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

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

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

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

The URL to Trackback this entry is:
http://dev.ariel-networks.com/Members/inoue/plone-impression1/tbping

Re:Plone/Zope印象批評1

Posted by ohtani at 2005-12-26 13:51
「->ありえるえりあ」は、単に僕の設定ミスです。
それから、表示するときにはコンテンツとそれに対するビューで。。。めんどくさいので,そのうち説明します。

Plone/Zope印象批評2

Plone/Zope印象批評の続きです。 触って初日の感想なので、知識不足からでた感想もあるかもしれません。知識が無い状態で印象を書ける時期は貴重なので、会社の凄い人に怒られるリスクを犯して書いています。

ACL(アクセス制御)が良く分かりません。

/Members/inoue/images/plone-impression2/plone-acl-nav1

やりたいことは上の画面で「AirOneの国際化プログラミングの方」になっているので、「AirOneの国際化プログラミングの方針」に修正したいのです。

ボタンメニューに「編集」がありますが、これは文書ではなく、/ホーム/コラム/を編集する意味です(前回のエントリの学習)。

文書自体を開くために、「AirOneの国際化プログラミングの方」のリンクをクリックすると次の画面に遷移します。

/Members/inoue/images/plone-impression2/plone-acl-nav2

編集メニューが現れません。ここでURLに注目すると、最後が/viewになっています。表示アクションを意味しているため、編集行為が行えないのでしょう。1枚目の画面に戻り、「コンテンツ」ボタンメニューをクリックして、目的の文書をクリックします。次の画面に遷移します。

/Members/inoue/images/plone-impression2/plone-acl-nav3

URLから/viewが取れましたが、編集メニューは現れません。仕方無いので、URLの最後に/editを付けてreloadしてみました。

「権限が不十分です」というエラーが出ました...

自分の文書なのに。

気を取り直して、「共有」メニューをクリックすると次の情報が見えます。

/Members/inoue/images/plone-impression2/plone-acl-nav4

見る限り、自分が所有者の文書です。

画面の下の方に「上位フォルダからロールを継承」という項目があり、チェックもついています。 1枚目の画像によれば、/ホーム/コラム/には編集権限がありそうです(編集メニューが現れる)。

「方」を「方針」に修正したいだけなのですが。

The URL to Trackback this entry is:
http://dev.ariel-networks.com/Members/inoue/plone-impression2/tbping

Re:Plone/Zope印象批評2

Posted by liris at 2005-12-26 11:28
まだ、ワークフローの設定途中なので,そうなっています。
それから、なるべく権限を取り上げるようにしています。

JDEE(Java Development Environment for Emacs)の紹介

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の凄い所を説明します。

1.準備

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

<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>

StrConcat.javaの中身(意図は名前で推測してください。実装がすぐに目に浮かぶほどくだらないinterfaceですが、説明のための例なので許してください)

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

コード補完のために、CLASSPATH内にStrConcat.classが無いといけないので、StrConcat.javaをコンパイルしておきます。

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。

/Members/inoue/images/jdee/jdee1

3. デバッグ

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

Compile command: ant -emacs 

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

/Members/inoue/images/jdee/jdee2

慌てず、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

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

/Members/inoue/images/jdee/jdee3

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

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

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

/Members/inoue/images/jdee/jdee4

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

The URL to Trackback this entry is:
http://dev.ariel-networks.com/Members/inoue/jdee/tbping

AirOne新機能紹介、新着受信時の音

/Members/inoue/images/misc/sound

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

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

The URL to Trackback this entry is:
http://dev.ariel-networks.com/Members/inoue/airone-sound/tbping

codeblogに記事を書きました

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

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

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

The URL to Trackback this entry is:
http://dev.ariel-networks.com/Members/inoue/codeblog/tbping

Re:codeblogに記事を書きました

Posted by Anonymous User at 2006-01-05 10:31
大谷さんはかつて、tDiaryユーザだったそうです。

CSSパフォーマンスと昔話

メールを整理していたら、約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がサポート外なので、子セレクタにして少しパフォーマンスを稼げるかもしれません。

昔話

CSS1の最初の公式スペックは1996年12月(http://www.w3.org/TR/REC-CSS1-961217)です。

それと前後して、インターネットの世界にw3c原理主義者がいました。簡単かつ偏った説明ですが、w3c原理主義者はHTMLでレイアウトを記述する書き手を粛正しました。w3c原理主義者にも過激派と穏健派がいました。過激派は、無知な大衆を攻撃しました。DTDも読めずにHTMLを書く素人はWebサイトで文書を公開する資格がないので、HTMLやCSSを勉強してから出直すか、書くのをやめろ、と主張しました。穏健派は、罪はツールおよびツール作成者にあると主張しました。ツールが正しいHTMLを吐き出すべきだと主張しました。それを使う一般ユーザ(当時の言葉で言えば、ホームページを作る人たち)が難しい仕様を理解する必要は無いと主張しました。

すみけん氏も語っているように(http://www.asahi-net.or.jp/~jy3k-sm/)、時代は穏健派が勝利しました。

The URL to Trackback this entry is:
http://dev.ariel-networks.com/Members/inoue/css-perf/tbping

Re:CSSパフォーマンスと昔話

Posted by anaka at 2006-01-08 15:33
クラス名を付けるのは(気持ちとしては)見栄えの指定に限った行為ではないので、そんなに違和感はないかなぁ。
別のスキーマが入り込むからイヤというのは同意。

2006年、鬼のプロジェクト管理

去年(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万円の借金です。「まだ慣れていないから」や「始めたばかりだから」という言葉に耳を貸してはいけません。借金は自動的に無くなることはありません。その週に作った借金は、確実に返済させるべきです。土曜、日曜に返済させない限り、間違いなく借金地獄になります。

The URL to Trackback this entry is:
http://dev.ariel-networks.com/Members/inoue/pm2006/tbping

Copyright(C) 2001 - 2006 Ariel Networks, Inc. All rights reserved.