Windows新発見！
「ほげ.(・ω・)」というファイルを作って、フォルダを詳細表示にするとファイルの種類の所に「(・Ω・)」と表示されてます！！！微妙に違うよ(爆)
設計はUMLだけで済む
ほ、本当にそれで今までうまく行ってたんですか！？と思ってしまった話がありました。「UMLは分析・設計ツールです」とりあえずこの一言で”ああ、ちょっと間違ってる”と思いましたが引き続き話を聞くと、UMLでユースケース図書いて、クラス図を書いて、シーケンス図を書けばプログラマは実装できるでしょと。ええっ…業務ロジックの仕様はどこへ行ったんですか？この問いの答えはユースケースシナリオに書いてあります。と。画面設計とかDB設計どこ行ったの…といろいろと不明な点が多かったんですけど、言っている事は立派でした。まさに理想。あまりに現実離れしていたのでポカーンとしてしまいましたが感想をば。
とりあえず上に書いたもののアウトプットを見せてもらいました。すごいです…とんでもなくすごいです。ソースコードからリバースした並のクラス図とシーケンス図です。各クラスにはきっちりメソッドが定義されていて、型まできっちりついてます…。ある主のフレームワークのがっちり型にはまったクラス図じゃありません。業務に沿ったメソッド名やらクラスが定義されています。私は思いました。実装していったら全く役に立たないクラス図なんでは無いかと…。それでテストファースト開発で品質ばっちりでやってきたというからすごい。タイムマシンを持っているとか、予知能力があるとかSE(サイキックエンジニア(ローマ字で書くとSE・・・本当はPE(T_T))がいるとしか思えません…。SIerが本気で動くとこんなにも常人離れした結果を出してくるのかとびっくりしました。
さて、この話が上っ面だけで中身を伴ってないまったくの空論だったのか、現実だったのか。結果は来月判明します…。あの結果できあがるプログラムって一体どんなものなんでしょう。設計・開発指針を提示する部隊と、実際に設計作業する部隊と、プログラムの実装部隊は違うので、指針が空論だと後工程が全部崩れてしまいます。ここで本当にデキる人は違うのか、言うだけの人だったのか興味があります。私は是非ともやり遂げて欲しいと思います。究極を見せられてしまったら、現状の私がミジンコに思えます。空論が実は現実だったということは、私は空論と決め付けてその高台へ上り詰めるのをサボっていた事になりますから。いや…でも正直理想論すぎると思う…誰もができるわけじゃないのに、一部のスペシャルな人ベースで物事考えられちゃうと、プロジェクトとして成り立ちません。誰にもマネできないから区別化できているという考えをプロジェクト内で行っても、そりゃ誰もついていけません。どういう結果になるかわくわくします(^^)あ、そういえばアーキテクトのＸＸです。というのをリアルで初めて聞きました。逆にSEのＸＸと聞かないのは私の周辺だけですかね。
DispatchActionに定義するメソッドはひとつか
DispacheActionと言えど基本概念はActionと一緒。1イベント、1メソッド、1クラスと。しかし、それじゃーDispatchActionの意味が無い。機能ごとに1クラスに複数メソッド書いても良いじゃないですか。例えばマスタメンテナンスなら、select, insert, update, deleteメソッドを定義するみたいな。ただし、これはメソッドが短い時のみ。1アクションで1000ステップも行ったらそりゃ間違いです。せっせせっせとイベントを小分けしたほうが良いでしょう。
DispacheActionの利点はメソッド名がexecute固定でなく、複数のメソッドを定義できる事。複数のアクションを一つのクラスで処理できる事だと思うので、例えばウィザードみたいな一連のイベントを処理する場合は、1ファイルに収まっていて分かりやすいと思うわけです。パッケージにまとめてクラスを小分けするんでも良いですけど、タブ開きすぎ(苦笑)
っとここまでは前文です。今やってるStrutsのコードは1イベントあたり20行程度のとーっても小さい実装に収まっています。多くても50行くらいかな。だから、機能ごとにひとつのDispacheActionクラスでもとても見渡しが良い。メンテナンス性が良くて、関連ある機能が見渡せるなら、小分けにしなくても良いなぁと実感した瞬間でした。
DispacheAction使うとstruts-configの肥大化も防げますしね。いや、肥大化とかの前にユースケースごとに分けてしまうという方法がありますが、それはそこそこの規模があってこそ。あまり大きな規模じゃない時は管理するファイルが増える分だけ面倒です。でも分業する時は便利なんですよね…CVSからアップデート＞コミットを連日やるのは面倒なので、あっちのチームとこっちのチームでstruts-config分けてしまおう！リリース前に統合ってことで。これでもOKなわけです。少なからずサブシステムごとには分けますが、機能ごとに分けなきゃいけないのは、ひとつの機能にさまざまな機能が凝縮している場合で、設計そのものを直す選択肢もあるかもしれません。今の所機能ごとにstruts-configを分けているのは遭遇したことがありません。臨機応変結果良ければ全て良し。いつでもこれでOKじゃないですけど、臨機応変な対応は重要です。型に捕らわれすぎて自分を変えないは良くない。っと正論化してみる(苦笑)
強化書
教科書とかけているのか、うまい事言うなと思った言葉でした。なお、Amazonで検索するとどの本だかすぐに分かります。1冊しか”ちゃんと”ひっかからないんです。検索結果は3冊ですが、”強化書”と入っているのは1冊です。普通にぐぐると約 427,000 件ということで、別に珍しい言葉じゃないんですかね。ちなみにまだ先月の本の出費のせいで本が買えません。カートに入っている9冊は一体いつになったら購入してもらえることやら(苦笑)3ヶ月経つとカートから消えてしまうようなので読みたい順に買う予定…。買ってばっかで読んでないと思われるでしょうが、実は最近読んでます。読むの好きですし、おもしろいから！
大人買い、子供読み。しょぼーん
Eclipseプラグイン開発者OFF
＃略してEPD OFF。(教祖様さすがっ！)
プラグイン開発って山ほどできる事あるじゃないですか。開発してる人はいるとしても、人それぞれ触ってる所が違ったりするんで、その差分を知識共有したいなぁと思いました。パースペクティブは分かるがプリファレンスは分からんとか。プロパティービューは分かってもコード補完は分からんとか。全部分かってる人はまだまだ多くないはず。まだ妄想です。ネタにも昇格してません。もちろん現実にも。まだ私がなんにもできないから企画(があっても)して参加しても知識として吸収できないからorz真夏には熱く語り合ってみたいですね。興味ある方も今から是非作ってみたいものを見つけて、コツコツ始めてみてください。習得には結構時間かかると思うので日々コツコツです。私はプラグイン開発に加えてGEFも知らないといけない…さらに課題としてプラットフォームに注目するというのがあります。本格始動はEclipse3からと思っていますけど、3のリリース前に加速装置くらいは作っておきたい。でもとっても忙しい時期なのよね(T_T)
過去の日記へのコメントに気づかない…
すみません、コメントいただいててもそれに返事が無いのは気づいてない証拠です。これどうやって発見すれば良いんだろうか？
＃新しいコメントがあるとメールで通知してくれる機能がありました。Thx！id:makotan
Tバックが来ない
id:skimuraさんの所でもあった現象です。教祖様からのTバックが記録されません。一体どういう仕組みになっているんだ(・・?)
もしかして明示的にTバック送信しないと駄目になったのかな。id:hoso-kawaと自分にテストしてみる。
居酒屋で小耳に挟んだ話
バカな技術者はシステムを殺し、そして人を殺す。
なんでこんな時間に小耳にはさむのか・・・お察しください(苦笑)
