2003-09-10 (水) [長年日記]
■ 広告批評・佐藤雅彦研究室
今更ながらに読んでみた。すんごい。大学はこうあるべきだという理想像の完成形を見たような気がする(言い過ぎ?)。
佐藤さんはご自身がなさってきたCMプランナーという仕事を、鈍化してる仕事だと言い切ってる。ぐはぁ。世の中で「クリエイティヴ」だと言われている仕事が鈍いですと? そんじゃあ、クリエイティヴな仕事って一体、何があるんだぁーー。というか、この佐藤研以上にクリエイティヴな場所って、他にあるのかーー。 あったとして、それはビジネス的にやっていけてるのかーー。この研究室を出たひとが、世の中はクソだって思ったりしないかと、他人事ながらに不安になりました。
あ、そうそう。いんげんソート、ぼくもやってみようと思う。いつもソートの種類が分からなくなるので。
■ インテリジェントパーキングアシスト via TECHSIDE
縦列駐車のムービー。これ欲しい。よだれダラー。
■ 【インタビュー】ユビキタスをファッショナブルに開発する研究員(1)
萌え萌え。インタビュー内容も萌え萌え。
■ [Java][UML] Uml for Java Programmers (Robert C. Martin)
というわけで、ぼちぼち読んでます。3章まで読みました。ので、ちょっとだけまとめてみます。
ここまでの主張は一貫してて、
- 他の業種ではモデルのほうが実物よりもコストが低い
- んじゃあ、ソフトウェアでは?モデルのほうがコードよりもコストが低いの?
- ……んなこと知るかよッ!(いやなら作るな。そして地獄へ行け)
- UML描くのはホワイトボードで十分だ!(学習曲線が直線!)
- つーか、欲しいのはコード!(UMLなんかじゃねーよ!)
- UML描くのが終わったら、早くコード書きにいけコラ!
というもの(256パーセントの脚色)。
おお、まるでXP。
そもそも、UMLの使いすぎはUMLを使わないのよりずーーーっと太刀が悪い、などと書かれてあるくらいで、この本はUMLマンセーの本なんかじゃぜんぜんない。UMLをちゃんと完璧に学ぶための本じゃあなくて、いかに効果的にUMLを利用するか?(しかもJavaで)という本なのだ。
その意図は、2章の「Envisioning the code」という節に、端的に表われているように思う。
Never let the diagrams become an end unto themselves.
JavaとUMLのマッピングという意味でいうと、浅海様の『やさしいUML入門―Javaオブジェクト・モデリング』と系統が似ているのかもしれない。
When to draw diagrams and when to stop.
2章にあるこの節(p.22)。テキトーに訳してみます。眠いので間違ってるかもしれない。気づいたらあとから直します。
いつUMLを描くか:
- 何人かのひとが同時並行的に作業を行うために、設計のある部分の構造を理解する必要がある場合にUMLを描くとよい。皆が理解したならば、描くのを止める。
- 2人以上のひとがある要素の設計方法に賛同しない場合、あなたが賛同を得ようとするためにUMLを描くとよい。その話し合いは time box に入れて、投票などの公平な決定方法を選ぼう。time box の最後、もしくは議論に決着がつきそうだったら、描くのを止める。そして、UMLを消す。
- 設計のアイデアをこねくりまわしたいときに描くとよい。閃きがあるかもしれない。コードで考えるのを終えるポイントにきたら止め(?)。UMLはステ。
- 誰かに(もしくは自分自身に)コードの構造を説明する必要がある場合にUMLを描くとよい。コードみながらうまく説明できるようになったら止め。
- プロジェクトが終わりに近づいて、顧客が誰かのためにドキュメントが欲しいといった場合。
UMLを描かないのはいつか:
- 開発プロセスで描くようになってる場合。
- 描かないのが悪だと思っている場合。もしくは、優秀な設計者がやるべきことだと思っている場合。優秀な設計者というのはコードを書くのもUMLを描くのも、必要なときにしかやらない。
- 設計フェイズの終わりにコードへの引継ぎとして理解可能なドキュメントを作成する場合。こういうドキュメントはまっっったく価値がない上に、莫大な時間がかかる。
- 他のひとがコーディングするために描く場合。真のソフトウェアアーキテクトは自分たちの設計のコーディングにも参加する。だから、彼らがつくったベッドで横たわっているのを見ることができる(???)。
あーねむ。もう寝ます。いま午前3時。
■ [Hiki] cvs up
HikiFarmが動かなくなったので、
cvs up -p -r 1.1.2.13 index.cgi > index.cgi
とやってみた。バージョンを落とすとき、いままでは SF から直接 DL していたので、なんかちょっと賢くなったような気がする。それにしても何が悪いのかな。とりあえず保留。
HikiFarm で作った Hiki からも更新メールが届くようになって(単なる設定ミスだった罠)、かなり満足な感じ。
■ [UML] oosquare-ml:03706
医者から検索するのではなく、病院Listから適合しない医者を消していけば可能です。
おおうッ。目から鱗。
ぼくは
┌──┐ ┌───┐ │病院│ * │医 者 │ ├──┤ <>---- ├───┤ │ │ │診療料│ └──┘ └───┘
こうじゃね?って思ってたんだが。
診療料オブジェクトって何だ?
追記:
ああそうか。「会社」と「給与体系」と「社員」と考えればいいのか。そうなると、オブジェクト図を作らないことには、何とも言えないような気がする。とりあえず、先のUML本では、triangle aggregation は Illegal cycles of aggregation between instances としてダメ扱いされていた。
■ [UML] 世の中XPやってるとこなんかねーんだよゴルァ!
と、Thomas Paul from Plainview, NY USA さんがレビューされている。設計やるやつが設計やって、コードかく奴がコードかいてんの。そういうもんなの。現場は。ったく。つーか、そもそもUML嫌ってんじゃんこいつ。フェアじゃねーよ。と。
そしてJ2EEだったらコレ。最強。つって、『Enterprise Java and Uml (Omg)』を推薦なさっている。うむ。ウィッシュリストに入れておこう。
■ Campus Petit CRITZ 2 big (ケス-5090LS)

こんなん買ってみました。カバンのなかが、幾分整理された感じがする。これで会社、かばん、家とに分けて文房具を置く必要がなくなった……かな。

はじめまして。Uml for Java Programmers 面白そうですね。
UMLの基本がお分かりでしたら、必要ないかもしれませんが、良書だと思います。英語が平易なので読みやすいですし(ぼくでも読める)。
どのように動かなくなったかお知らせくださいますか?>HikiFarm
げ。さっきやったらちゃんと動きました……ごめんなさい(T-T;;
個人的には<http://www.amazon.co.jp/exec/obidos/ASIN/4798102113/>がJ2EE最強とは思えませんが……。アーキテクタス・リローダス志願にはイイのかも。
アーキテクタス・リローダス???
ウルシステムズの翻訳本は 1stEdit を元にしていますが、Thomas Paul さんが指しているのは 2ndEdit のようです。今年の6月に出版されています。ちゃんとJSP使っているようですよ :)
Greetings all...<br><br>So after practically 5 years of focusing on the assets sector and really enjoying every small of it...the time has come to lengthen my horizons and opt for the next trace in delivering tremendous products in support of Microsoft. So as of completely in the near future (girlfriend TBD) I will be moving to a Program Operation task in a further goods being developed in the Corporation division.