capsctrldays(07-22[長年日記])

2003-07-22 (火) Edit

■ Technology at Harvard Law:

アンテナに追加。

Technology at Harvard Law: RSS 2.0

■ Wired News: Blogging for Bucks

ドットコム企業（プッ）をクビになった奴が、自分なりの経済レポートをblogで書くことで、今まで以上の収入を得るようになったというお話。

好感持てるのは「blogだから」というお話ではないから。重要なのは、彼自身なのだ。彼が何をやってきたかなのだ。blogなんかではないのだ（そういう陳腐な話に落とすのはもうマッピラだ！）。blogとは、コンピュータに関係なひとも簡単にPOSTできる仕組みのことのみを指す。文体だのスタイルだのジャーナリズムだのは、この際、別にどうだっていいんだ。そんなもの、ウェブロでも出来てたじゃないか（と山田民も言っている）。そこを混同して論じるから、おかしなことになるんだ。こういうふうに、彼がやったことにフォーカスすれば、blogなんて取るに足らないッ！

モチベーションはどうやって維持してるの？という質問に彼はこう答えている。

I know people are reading my work and expect it. It has become a social obligation of sorts -- in a very good way.

もうすでに「書きたいから書く」を超えているのだなぁ。

■ ロバート・キャプラン博士による企業パフォーマンス管理webセミナー

memo.

■ [Agile] アジャイル開発導入事例セミナー

Sun＠用賀であったボーランドのセミナー。遠いぜ、用賀。

事例からみるXPの実践的導入方法

テクノロジックアートの方。XPの導入事例の紹介。XPとは従来の工学的なものを社会学（ときには政治学）的にしたもの。おー。なるほどね。

導入には、マネージャーがしっかりしろよッというお話（ありがちだな）。若いひとのほうが（特に新人）、XPの定着率および技術吸収率がよいとのこと。これもありがちですな。

FDDの概要と実践におけるTips

TISの方。FDDの概要なんだが、ドメインモデリングの段階でつまづいた……。４つのアーキタイプがうんぬんかんうんって言ってたなァ……言ってることは分かるんだが、まったく理解が出来ない。なんのことやら？って感じ。FDD本どうしようか。読むのダルいなあ。

で、ここで休憩が入ったのでとんずら。

Generics

資料を見ると、J2SE1.5の説明がちょっとばかしあったのでメモ（Javaなんて追いかけないからよく知らないのだ）。

List<String> words = new ArrayList<String>();
String title = words.get(0).toUppercase();

キャストが不要になるんですって。それはいいとして、List<String>って何だろうか。Collectionに型が必要だったら、キャスト不要になってもあんまり意味がないような？

[ツッコミを入れる]

2004-07-22 (木) Edit

■ オリジナルソーシャルネットワークの作り方

SNSを使えばこういうメリットがー！みたいな記事は萎えますなあ。なんで萎えるかは分かりませんが。こういうのも萎えません？ぐだーってなる。ひょっとして俺だけっすかね。

萎えるのはそれくらいにして、ここで触れられている Central と Base という考えは、GreeNight 行った後に先輩と話してた内容と一緒だッ（俺は全面的に否定してたが）。開発、がむばってください。

追記：

ふむWiki:デジタルキャンパスに見る近未来のコミュニケーション

こんなの教えてもらいました。

■ さくらんぼブービーいいよなあ

前から好きだったんだけど、よーやく名前を覚えた。きっと漫☆画太郎先生のファンだと思うんだ。mixiのコミュニティに入ったらムービーがあったのでぺったんこ。

インスタントジョンソン、波田陽区、東京ダイナマイトのコミュニティにも入りました。

■ [本] 業務システムのための上流工程入門―要件定義から分析・設計まで(渡辺幸三)

読了。薄い本なので細かいところには立ち入っていないが、上流工程の「ある種の形」を提示してくれている貴重な本。これが妥当かどうかはぼくには判断つかない（そもそも上流という言葉が気に入らない）。

デザインパターンと称した章もあるが、これもぼくにはなんのこっちゃいな、という感じ。分かるひとには分かるのでしょうが。ぼくの感想は以下のようなもの。

▼

上流工程がボトルネックになっていると氏は述べる。優秀なプログラマが自分のために開発したソフトウェアと優秀なプログラマがお客様のために開発したソフトウェアとでは、後者のほうが圧倒的に時間がかかることからもそれは明らかだと言う。また、上流と下流で分担すれば、単価の高い上流工程に専念することも可能となり、結果として会社全体の利益も上がると言う。

一般的な「上流工程」が何を指すのかぼくはよく知らないが、ここでいう「上流工程」ってのは、以下の１＋３のモデルを作ることにあるという。画像の説明

絵を説明すると、まず業務フロー図をDFD（実際はイベントを付記したDFDもどき）で描き、次にデータモデルを作る（IEもどきで表記）。次に文章形式で業務モデルを記述し（これは後にマニュアルとなる）、最後にその業務モデルに沿った形でシステムの画面イメージを作っていく（外部設計）。

本書の最後にストーリー仕立てでその構築方法が記されてあるので、是非一読されたい。

この工程そのものについてコメントできるほどぼくは知識を持ち合わせていないので、おおッと思ったポイントだけ書いておこう。

その場主義

以上のモデルのラフデザインを、お客さまとのセッションを通じてホワイトボードに殴り書きしていく。ここが非常に感銘を受けた。アジャイルだぜこれ。これを氏は「その場主義」と呼ぶ。そのセンスの無さがまた魅力である。

細かいことにこだわり杉

オブジェクト倶楽部の納涼祭で、一部、話題騒然となった「マジックは新品を」「モデリングは似顔絵である」「曲線は美しい」などの迷言が、コラムとして紹介されている。面白いので是非読んでおこう。DFDやIEをカスタマイズするところに、氏のビジュアルへのこだわりが見える……反面、こんなこと言ってるとキワモノ扱いされてしまうようにも思う（それはそれで楽しいが）。

つーか、データモデルのひとたちって自分で記法を作っちゃうのよね、あれって悪い風習だと思うYO。

業務モデル

この存在が重要。システムを構築しても、それをどうやって使えばいいのかが分からなければどーしよーもない。ユースケース記述がマニュアルになりますよーという話は聞くが、あんなマニュアル読めたもんじゃない。氏は分かりやすく、更新しやすいマニュアルを作れと述べる。おお、これはまさにWikiの出番じゃないか。

機能モデル

機能モデルは、それまでのデータモデル、業務モデル、それからドメインの知識（およびパターン）でもって構築していくべしとのこと。ここでデータモデルがしっかりしてれば、更新すべきじゃないデータを画面を表示させることなどを防止できるとかなんとか。でもね、アーキテクチャを考えない画面イメージなんてどーかと思うんだよ。右クリックしたら「修正」メニューが出てきて……なんてHTMLでどーやるの？逆に、もっと簡単な操作方法があるだろうけど、このウンコ仕様書にはこう書いてあるから、こうやったーみたいなのもあるでしょう。

業務アプリのユーザビリティが総じて醜悪なのは、こういうところからきてるんじゃないかなあ、と思う。