WOMeeting欠席
欠席しちゃいました。 すんません。
欠席しちゃいました。 すんません。
参加させていただいてきた。
時間ぎりぎりだったので、自転車を必死にこいで新宿南口から会場へ向かう。 汗びっしょり。結果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?
いろいろと面白い話を聞かせていただいた。書いていいのかよくわからないので、とりあえず。
飲み会
ちょっとした用事があったのと、途中合流が難ししそうだったので、欠席させていただいた。
Practical WebObjects 読書会のみ参加。今月はChapter10. WebObjects In A J2EE World。
シンプルなアーキテクチャでServlet対応できてしまうところに、WebObjectsのスジのよさを感じるわけである。
ただ、あいかわらずマルチスレッド関係の処理に不安が残るわけである・・・。 WWDCに行かれる方は、Chales HillさんにEOEditingContextのLock問題について質問してきてください!(どうやらWWDC@SFにて、Pratical WebObjectsの著者がセミナーをやるらしい)
久しぶりに顔を出した。 しばらく休んでいたのに快く迎えてくれた皆さんに感謝!
As-Is
As-IsとTo-Beを区別することは必要だけど、あまりAs-Isにこだわりすぎるのはどうかと、ふと思った。
PoEAA読書会 第3回に参加した。まとまりなく書いてみる。
発表資料はこちら
駆け込みで前夜に資料作成
前夜1:00am-6:00amぐらいで3章のサマリをPPTで作成し、持参&発表。 直前に駆け込みで作ったこともあり、内容はイマイチだったけど、議論のベースとして機能したので結果オーライ。ということにする。んで、質は量に転化する。ということにする。(これまでも、これからも)
あ、資料作成の際には昔WOMeetingで使った資料を流用したりした。継承の実装方式の図や、RDBMSのイメージとかEnterpriseObject(笑)とか。ちょっと手を抜けた。
進め方など
当初、15~25分程度でさくっと進めるつもりだったのだけど、実際始めてみると、 発表しつつ、議論しつつな感じで進めたほうがよさそうな印象を受けたので、そうすることにした。 自分が2部以降をキチンと読み込んでいなかったため、議論についていけなかったり、議論の整理がうまくなかったりした部分があったのは反省点。でも、読み込む時間がないのよねー。あと、情報を体系化して、脳みそへ定着するための時間が。
議論に参加してくれた方、感謝。いろいろ話して、楽しくやりましょう。 特に、ひがさんには感謝!感謝!有益なネタ振りをたくさんしてくれた。しかも、カナリ読み込んでるし! つーか、発表者のくせしてあまり読み込んでなくてごめんなさい。たたき台として存在する意味があると自分に言い聞かせる。
UnitOfWork
EOEditingContext! EOF最強! 楽○○○○○○御が実質的に機能しない点を除いては!(苦笑)
外部キー制約、参照整合性
外部キー制約付けない派が大多数。なるほど。確かに実務上は付けないほうがよさそうではあるのだけど。 ちょっと意外ではあった。
依存
依存概念をCASCADE ON XXX制約でカバーできるかどうか?については良くわからない。 EOFの場合、(確か) 親Objectと子Objectのリレーションシップを切断すると、子Objectが削除されたはず。 というわけで、Objectの世界で依存概念の意味をどこまで規定するかに依存すると思われる。 ただ、たいていの場合、CASCADE ON XXX制約で十分な気がしている。
一瞬、ER図にも依存概念を導入したほうが良いかなと妄想した。うーん、IDEF1xとかだと入ってそうだな。でも、あれを理解する気にはなれない・・・。ま、いいや。
EOF/WebObjects
発表が終わって、ogijunさんとボソボソ。 やっぱ、EOFはいけてるねーとか。
O/Rマッパーに必要な概念のほとんどを実装しているからねぇ。 Apple買収後も、XML対応とかいろいろ適切な方向に進化してくれたら面白かったのに!とか思う。
あと、Webフレームワークがステートフルな方向に行くのなら、WebObjectsフレームワークも・・・って、完全に脱線だなコリャ。
ちょっとWebobjectsに興味をもたれたかたは、ここらへんとか、suzukiさんの有益な資料(spice-of-life.net - WebObjects)などをごらんくださいまし。
概念をビジュアル化することの効能
余談だけど、概念を脳みそへ定着させるために発表スライドをつくるというのは結構有益。 ソフトウェアをビジュアル化する作業は、モデリング技術の延長上にある。複雑なもの・見えないものをある側面に着目して、表現することに相当する。短期的・長期的に有益。 というわけで、誰か、次回のサマリ担当に立候補してくれないかなーと。
ポジションペーパ
リンク集発見!
ありがとうございます。koicさん。
Day by day(2005-05-23)
| M | T | W | T | F | S | S |
|---|---|---|---|---|---|---|
| « Sep | ||||||
| 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 | |||