著作一覧 |
EJB3.0。すっきり。
追記:この上下で全然異なる話ですよ。DとBはdataやbaseじゃないですよ。と念のため。
DとBの7の間に水平に移動できる通路が必要だと思う。すごくバカな建物だ。でも話によるとこのあたりの利用方法も含めてデザインされているらしい。異なる利用方法をすると罰金刑もあるらしい。いいねぇ、バカなデザインを強制できるってのは。
でもバカなデザインと規定が合理性を持つ可能性についても一応は考えてみると、何が理由となるだろうか? 大量の人間の水平移動によって何か問題が発生するので、少量ずつボトルネックとしてのエレベータを利用して一度に移動可能な量を制限しているのかも。横移動ではなく縦移動が必要な構造なのかも知れない。だとすると、バランスが非常に悪い建築物なのだろう(もし、本当に、それが必要なのならば)。とすると、やはりバカな建物だということになると思う。
あるいは、毒ガスが充満した場合に、各棟で被害を押さえ込めるように分けているのかも。火事になったら毒ガスがもくもく出て来る仕組みなので被害を最小に留めるためには分離しておく必要があるということだ。やはりまともなデザインではないな。火事になったら消せるように考えれば良いと思うし、有毒ガスが発生しないような考慮はできないんだろうか?
他にはどんな理由があるのかな?
萩原さんのセッションのテーマ。
ユースケースは拡張の記述が追記できる。
しかし、静的なモデル図ではどうすれば良いのだろうか。
フィーチャモデルでは必須なものとオプションを書き分けられるし追記もできる。
大雑把には、@itの連載のサワリの部分。
以下はそれについて考えたこと。
カスタマイズ可能なソフトウェアについて当てはめて考えてみる。
あるべきありようというのは
・コアコンポーネントはそのまま他のカスタマーのところへ持ち込める。削除できる
・可変部(カスタマイズが必須な部分)は、当たり前だがカスタマイズできる。追加できる(基本はゼロなので削除は考える必要がない)。
・可変部からコアコンポーネントへの影響をどう吸収するか。
継承(実装継承、デリゲート含めて)をパッケージで分離するとDolphinのモジュラー化機能が利用できるのだろうかと考えたり
修正というのはソースを作成する(カスタマイズする)時のオマケとして、追加と削除だけで考えられるようにするというのが、間違いは少ないのではないか。
マスタングのことだと思い込んでいたorz。
紙は平面だが巻物にすると収納しやすい(しかしランダムアクセスはしにくい)、製本するとランダムアクセスしやすい(直方体になるので積み重ねしやすい)というように、人間はおつむを使うことができた。
いやでもCPU作ってる会社とGPU作ってる会社がそれをしたいわけだし、MSも(多分Appleも)それを使おうとしている。
ということは、いやでも2Dのものを3Dに配置するデスクトップはやって来る。
やって来ることがわかっていて、おつむを使う余地が開けきっているわけだ。
UIに少しでも興味を持っているのなら、今すぐ使える3Dの世界、つまりLG3Dに飛び込まなきゃ嘘だろう。
Project Looking Glass Developer's Guide。
と煽ってみたり。
ジェズイットを見習え |
DとBの話は http://www.t-i-forum.co.jp/cmn/swf/serviceguide.swf ですね。;-)
ピンポン。しかし変な造りだなぁ。