Joel on Software
業務都合によりあまり時間が取れませんでしたが、私もレビュワーとして協力させていただきました。
この本、本当にいい本です。
第一線でプロとしてソフトウェア開発を行う全員に読んでほしい。 強くそう思います。
超オススメです。 文句なく、自身が読んだ中での今年のNo.1書籍といえますね。
|
|||||
|
そろそろポジションペーパ書きに飽きて来たので手抜きをしてしまいました。 いかんですね。 ### Unit Of Work : まさゆきさん * Hibernate との比較で語られていたので、わかりやすかったように思う。 * ちなみに、EOF/WebObjects関連の資料は、WebObjects基礎研究室 とか、WebObjects関連プレゼン資料 にあります。 #### ちょいとHibernateに対する疑問 * 1 Request = 1 Sessionなる考え方にどうもなじめないなぁと。EOF/WebObjectsの1 HTTP Session = 1 Unit of Workの方がシンプルな気がするのです。なぜなら、複数画面に渡る編集機能を実現することを考えた場合を考えると、いちいちdetachしてattachするのが面倒に思えるので。（と某mixi日記に書いたのですが、獄長から「Hibernateでも1 HTTP Session = 1 Unit of Workでつかえるよん」とツッコミが。1 Request = 1 Sessionと1 HTTP Session = 1 Unit of Workを使い分けるというのがよい？） * なんであんなにListenerが必要なのだろうか？実行の順序性に意味がありそうな一連のオペレーションを、Event, Listenerモデルで構築する意味がわからない・・・ ### Identify […] 参加してきました。今回は発表はなしでした。 ### TableDataGateway (わたなべさん) 読書会の議論でも発言させていただきましたが、TableDataGatewayは（非常に荒いレベルの）オブジェクトの設計方針について、わかりやすい指針を示しているものに過ぎないと考えます。 * 具体的な対象と照らし合わせた上での、責務の範囲 : 具体的には・・・RDBの構成要素（テーブル、カラム、複数テーブルなど）を相手にするGateway一般の中で、TableDataGatewayは、テーブル（もしくはテーブル類似のビューなど）を相手にする。責務の範囲をテーブルとする * クライアントから見た場合のインスタンス関係。もっと言えば、アイデンティティ。：具体的には・・・TableDataGatewayは1テーブルにつき1個。（テーブルの数は簡単に数えられる（苦笑）ので、インスタンスのアイデンティティも容易に理解できる） ### RowDataGateway (和田さん) あとで書きます。 ### ActiveRecord(inoueさん) Railsのデモが中心。やっぱRailsすげー！ ちょっと気になったのは、Railsの実行モデル。あれだけ評価・処理実行・自動生成が走るとなると、CGIでは・・・きついよね。多分。 ### 議論を聞いて。 ビジネスロジックの割り当て、データアクセスの議論が混在している印象。 ここは分けて話さないとまずいっす。 せっかくファウラーたんが、整理してくれているのだから。（わかりにくいけど） ### 角谷さんの意見に同意 わからない部分を曖昧に、抽象的に触れて流すよりも、わからない部分を明確に提示し、自分が理解できている（と思っている）部分を具体的に示すほうが良いと思う。ここはそれが許される「場」であると思います。 言い方を変えれば、せっかくなんだから燃料を投下しましょうよ。 どんなに炎上しても誰かが整理してくれるし。となるかも。 ### 資料（半）公開希望。 再度資料を見て、記憶を呼び戻したいので。 懇親会で酔っ払ったので、良く思い出せないというは秘密。 ### 戦果 ogijun氏が蔵書の一部を販売していたので、以下の2冊を購入。 * ユースケース実践ガイド 1500yen : 最近、プロセス屋さんの世界で next ユースケースが熱いらしいので、あらためて基礎を抑えておこうかと。 * ソフトウェアエンジニアリング基礎知識体系 600yen : なんか、書き物書くときに便利そうじゃない？たとえば・・・「IEEE xxx では、?における特性として、a) ・・・性、b) ・・・性、c) ・・・性、が求められている。本ドキュメントでは、a) ・・・性の・・・について記述する。」とか。 […] PofEAA 読書会で話題になったので。 シンタックス的に利用する機構（＝多態性）が同じこの2つのパターン。 思うところをつれづれと書いてみたりする。 ### コマンドパターン * マクロでみた意味的には、そのインスタンスにコマンド実行（処理実行）に必要なデータと、ロジックを詰め込むようなイメージ。 * 必要なデータとロジックがインスタンスにパッキングされているがゆえに、1番目の処理Aと2番目の処理Bと3番目の処理Aを実行したい場合は、処理Aに対応したインスタンス＋処理Bに対応したインスタンス+処理Aに対応したインスタンスをキューなどに並べておき、順次実行すればよいこととなる。 * コマンド実行のトリガを与えるクライアントが、コマンドのインスタンス以外に気を使わなくて良い点がポイント。コマンドクラスが、そのコマンド実行に必要なデータ、ロジックをカプセル化して保持しているから。 * さらに、コマンド実行を取り消す（アンドゥ）ために必要なデータと、ロジックも詰め込むようにすることで、アンドゥ処理が可能となる。 * OOPの意味的な観点でいうと、コマンドパターンは「インスタンス」に意味がある。 * 具体的には、同じMoveCommand(dx, dy)でも、new MoveCommand(5,10)と new MoveCommand(-10,20)は、処理内容が異なる。 * 多態性は、クライアントが異なるコマンド種別を統一的に実行できるために活用される。 * Command cmd = queue.getCommand(); cmd.execute() ### ストラテジパターン * マクロで見た意味的には、ロジックをプラガブルにしたようなイメージ。インスタンスレベルで保持するデータにはあまり重きを置かれていない。 * クラスとか、インスタンスとかが本質的な意味でポイントにはならず、プラガブルな構成要素的な観点を持つものであればよい。 * OOPの意味的な観点でいうと、ストラテジパターンは「インスタンス」にあまり意味がない。 * プラガブルな機構を実現できれば、ストラテジが提供するメソッドはクラスメソッドでもかまわない。（暴論気味・・・） * 多態性は、クライアントの統一的な利用というよりは、プラグ差し替えを実現するための機構として利用される。本質は利用形態の一元化ではなく、差し替え可能性にある。 ### 最近のコマンドパターン StrutsのActionFormをコマンドパターンとか言う人もいて、 ちょっと違和感を感じていたりもするけど、まぁいいかも。という気もする。 HTTPリクエストの内容を、1つのインスタンスにパックしており、かつ、ビジネスレイヤの呼び出しというロジックも（一応）実装しているから。上記に話とも一応対応している。 が、キューに格納されるでもなく、アンドゥ機構を提供するでもない点がちょっと引っかかるかな。コマンドパターンのご利益を活用しているわけではないということ。 executeメソッドを実装しているクラス群が何でもコマンドパターンというのは違うと思いますがね。 インスタンスにデータとロジックがパッキングされていることがポイント。 と思いますよー。と、気弱にまとめてみた。 いやー、内容の濃い5時間半だった。 ### EJB 3.0 いやー、ついていけませんでした。正直。ぜんぜんEJB3を追っかけてないからなぁ。 ### Next Generation J2EE Deployment 気になったとこだけ。 * データアクセスレイヤ?ビジネスロジックレイヤをつなぐデータ構造（モデル）としてドメインモデルを、ビジネスロジックレイヤ?ビジネスロジックレイヤをつなぐデータ構造（モデル）としてプレゼンテーションモデルを利用する。 * 誤解を恐れずにいうと、 * ドメインモデルはデータベースのテーブル構造に比較的近い構造のJavaクラスモデルとなる。 * プレゼンテーションモデルは、データベースのビューに近い構造のJavaクラスモデルとなる。 * かなり乱暴なものいいです。 * ドメインモデルとプレゼンテーションモデルの変換は、ビジネスロジックレイヤの背後にいるDxo（ダックスオー）が実行する。 * ドメインモデルの構造として、テーブル構造に比較的近い構造を使用する理由は、Persistence APIの存在があるため * ドメインモデルはJavaクラスのデータ構造に関する。PofEAAのドメインロジックパターンと混同せぬよう。後者は、ロジックの割り当てに関する。 * EJB3 or Seasar2の選択は、開発元の文化によると思われる。 * 標準化を重視するかどうか。とか。 ### テスティング話 結構盛りだくさんでした。早期の資料公開希望します（笑）。 PofEAA第五回読書会に参加してきた。 発表に関連した議論の内容を中心に、箇条書きでメモ。 ### セッションステート * レコードデータとサーバセッション * セッションステートをRDBに書き出したレコードはレコードデータではない。 * publicかつpersistentなデータがレコードデータであると理解した。 * 文中の「データベースとサーバセッションの中間の位置」とは何か？ * 中間の位置ではなく、中間の特性（？）ということみたい。 * 「位置」なる訳は、かなりグレー。 * セッションの特性に応じて、セッションアフィニティ(=スティッキー)にすべきか？セッションマイグレーション（セッションレプリケーション）すべきか？が変わってくると思われる。 * 具体的には・・・ セッションに格納するデータ量の大小、セッションの維持時間 * セッションに格納するデータ量が多い場合→ アフィニティ? * セッションの維持時間短い場合→ アフィニティ? * （セッションアフィニティに関連して）ロードバランシングについて・・・ * 書籍では「クライアントIPアドレスによってロードバランシングする」なる記載があるが、SSLのキーでロードバランシングできるものもある。暗号化の影響を受けず、かつ、決め細やかなロード バランシングが実現できる。 * 書籍では、「クライアントIPアドレスによるロードバラシンシングが機能しにくい」例として、Proxyサーバを介したアクセスとなるAOLが上げられている。が、日本の場合、Docomoが問題となりやすい。 * DOCOMO携帯からのアクセスの場合、リクエストのたびにIPアドレスが変化するので、IPアドレスでロードバランシングすることは問題。サブネット単位で行う必要が有るようだ。 * Session Stateとパフォーマンス * ステートの格納先をServerとするか？DBとするか？の選択基準としては、パフォーマンスよりリソースの観点が重要なのでは？ * ちなみに、「パフォーマンス」のファウラー流定義は、邦訳 P6あたりにある。 * PHPにはセッション情報をインメモリに持つ手段が無い。 * スクリプト起動のモデルがCGI的である故 * デフォルトで、セッション情報はファイルに格納する * RDBMSのテーブル(永続化ストレージ or インメモリ）に格納することもできる。 * […] 参加させていただいた。 場所は秋葉原近くの某研究所さん（名前カードや、注意書きの配布など、キッチリした事前準備に驚きました。ありがとうございました！）でした。 内容は、髪をばっさりと夏仕様にしたひがさんによるJSF(myfaces, s2jsf)のソースコードの追い方講座と、t-wadaさんによるTDDをめぐる混乱について。 * t-wadaの日記 ### JSF(myfaces, s2jsf) のソースコードの追い方講座 箇条書きで。 * myfacesの実装はところどころアイタタタな面がみられる。 * 処理の起点はfacesservletである。 * jsfのアーキテクチャはWebObjects Frameworkに酷似している。 * 画面の構成要素に対して、動的にidが付与され、idがマッチする画面の構成要素に対して処理が実行される * リクエスト-レスポンス・ループに関連する状態を管理するクラスはfacescontextである。(WebObjectsの場合、WOContext) * リクエスト-レスポンス・ループ処理は、いくつかのフェーズに分割して行なわれる。 * WOとの相違点は、validationフェーズが独立して存在すること * WOの場合、処理を実装する場所は フェーズx{Application, Session, WOComponent}の掛け算分だけあるのに対し、JSFの場合はもうちょっとシンプルな構成になっているみたい。 * JSFは適用領域をWeb/HTML/HTTPに限定していないため、内部のコンポーネントに対して直接???Request, ???Responseを見せない。見せるのはfacesContextのみ。この中にRequest類が入っているようだ。 ### “Test” という言葉 (TDD話 導入編) by t-wada 後で書きます。 伝説のプログラマ、カトラー氏はなお健在だった – So what is IT? [ITmedia オルタナティブ・ブログ] > 私：「私はその昔、デビット・カトラーさんにインタビューしたことがあるんです」 > K氏：「へぇ、そうでしたか」 > 私：「13年も前の話です。カトラーさんはもうMicrosoftにはいらっしゃいませんよね？」 > K氏：「とんでもない。今でも現役のプログラマとして、64bit Windowsのコアをゴリゴリと開発していますよ」 すごすぎる。まぁ、私の隣の席の人も、負けずに一生コードを書いてそうな勢いだが・・・。 参加させていただいてきた。 時間ぎりぎりだったので、自転車を必死にこいで新宿南口から会場へ向かう。 汗びっしょり。結果5分ぐらいの遅刻。スンマセンでした。 ### JSF vs Struts 実際にベンダー系JSF実装(+IDE)を使用/試用されている現場の方々や、JSF実装であるmyfacesの実装と問題点について熟知されているひがさんのお話を聞けたのがとっても収穫。 ありがとうございました。 ### JUnit4の胎動 なんだかかわいらしいフォントだなぁ。と余計なことは置いておき。 t-wadaさんの発表。面白かったです。 アノテーションを駆使したJunit4の特徴と、プレゼンテーションの中でちらちらと披露されたt-wadaさんのテストに対する考え方や、テストをうまくやるためのノウハウ開示がとても有益でした。 中でも、テストのカテゴリ分けの必要性、TestSuite(Junit4ではなくなる可能性もあるらしい！）の必要性と、現在Greee/Redしかないテスト結果状態を細分化する必要性について興味を持った。 テストのカテゴリわけは、テスト数が膨大となると絶対的に必要でしょうね。 TestSuiteの必要性に関して、t-wadaさんはテスト時間を短縮するために必要とのこと。 テスト時間の短縮というと味気ないな・・・・現場感覚が伝わりにくい。違う。 よりAgileに、プログラミング→テスト→プログラミング→・・・なるサイクルをより円滑に進めるために、絶対的に必要なものだというニュアンスと思っている。 そういえば、t-wadaさんは、テスト対象クラス（ファイル）のタイムスタンプを元にテスト順序を決める、（何らかの手段でテストクラスに与えた）優先度を元にテスト順序を決めるアイディアなども披露してくれた。うーん、欲しいねぇ。 テスト結果状態を細分化とは、具体的には・・・・ * @Ignoreアノテーションを付けたテストはYellowで表示される（これはJUnit4に実装されるようだ) * (なんらかの手段で、)まだテストに通らないことが明らかであることが示されたテストがfailした場合、別の色(Orange? Blue, Red, Yellow以外の何か。第4の色)で表示される とか。個人的には「第4の色(named by t-wada?)」が欲しい。とっても欲しい。 テストは書いたけれども、failすることが明らかであるテストがRedとなると、真のfail(failしないと思っていたのに、failしてしまった!)を見つけるのが難しくなる。 あ、あと、S2TestUnitを見ておかないとなぁ。と個人的なメモ。 #### 2005/06/19:追記＞ t-wadaさん 「呼びかけ」にうまく反応できなくてごめんなさい。 K.Beck(?)の、「not union but intersection」の真意がよく掴めなくて・・・・。 つーか、わざわざ小難しい言い回しせんでも、「必要最小限の機能」といえばいい気がするぞ。> K.Beck ### DIの本質 (ひがさんの考える)OCPとは端的に言えば、「修正をAdd-onlyで実現するもの」と理解した。 (全ての修正をadd-onlyで実現するのが望ましいという意味ではないです。) ### S2 5.0? いろいろと面白い話を聞かせていただいた。書いていいのかよくわからないので、とりあえず。 ### 飲み会 ちょっとした用事があったのと、途中合流が難ししそうだったので、欠席させていただいた。 […] reBeLog ≫ WebObjects Licensing via http://d.hatena.ne.jp/ogijun/20050608/p2 > Development is no longer supported on any other platform. > > Deployment on any platform other than Mac OS X is no longer supported. なるほどね。Windowsでの開発もサポートされないと。 Appleも思い切ったことするなぁ。まぁ、いつかこのときがくるとは思ってたけど。正直。 |
|||||
|
Copyright © 2024 WR blog - All Rights Reserved Powered by WordPress & Atahualpa |
|||||