FOLLOWING ECLIPSE GMF
気になっていた Eclipse GMF をちょっと追いかけてみようかな？という思いつき。(いつまで続くことやら… ^^;)
とりあえず、本家サイトを見てお勉強をはじめてみる。説明は跳訳です。mOm;
- GMFチュートリアル
- GMFの概要
- EMFとGEFを使ったプラグインの開発は一般的になっています。以下ではこれらのフレームワークを一緒に利用する方法について述べます。GMFの話に入る前に、EMFとGEFを使ったより先進的な方法について、GMFのアプローチを少し見てみましょう。GMFの実行環境についてはこの記事を参照して下さい。
- GMFプロジェクトでは、GMFを利用したプラグインの開発者を示すために『ツール職人』('toolsmith')ということばを使っています。これに対し、プラグインの利用者(開発者かも知れませんが)を一般に『ユーザ』('user')と呼びます。GMFを利用する立場からすると、GMFで内部的に利用される『モデル』('models')の数や型はできるだで隠すべきなのですが、ほとんどのツール職人は、裏でどう動いているかということに興味があると思うので、このチュートリアルではそれぞれのモデルについて説明しています。
…つづく予定
THE 21TH JAVA EE STUDY MEETING
JavaEE勉強会に行ってきました。
今回は名札(朝まで生テレビみないな感じ)があったので 名前⇔顔 mapping が強化されて良い感じでした。
- ポジション・ペーパーより … お題「【こんな】method【あります】」(ちなみに自分の提案だったりして…^^;;;)
- Javaだけではなく、JavaScript、Groovyなど他の言語だったり、広い意味での“メソッド”(でもこれGOODです!!)があったり、いろいろバラエティに富んでいて(?)、個人的には面白かったです。
- 自分は最近Seasar2のコードを読んでいて知った、プライベートメンバーへのアクセスを可能にするリフレクション系のメソッドを紹介。ソースコードの字が小さかったなぁ〜と反省…orz
- 以下、メモの転写
- Java
- Groovy
- Method#invocation
- Groovyオブジェクト (root object in Groovy)
- JavaScript
- function.toString("JavaScript Code")
- .NET / C#
- "メソッド"
- DEWA-METHOD (いいかも…)
- How to start up open source project by ひがさん
- Pro EJB 3 / Java Persistance API 読書会
- Introduction
- Getting Started
- JPQL … 式書けない。(集計関数だけ)
- PersistanceContext
- @Entity(name="AliasNameOfTableInJPQL")
- EntityManaged
- new
- managed
- removed
- detached
- Persistance(in JPA) ≒ DataSource(in JDBC)
- TopLink
- Essencial (Glass Fish)
- 商用 (JDeveloperにライセンスが付いてくる)
- ？
- auto
- never
- commit
- PK = Object (Single column PK is better. [must?])
う〜まとまっていない。「個人メモです」という言い訳落ち ^^;;;
SCOPE A LA CARTE
conversation scopeというのがコンテキストの生存期間としてあると便利かな? と思った昨日ですが、これを、より長い期間の方へ延長するとどうなるだろうと考えた場合、workflow scopeみたいなのもありかなと…*1
つまり長期間→短期間の順でいくと…
- Environment Scope (依存する外部システムなどの存続期間*2 )
- Enterprise Scope (会社が存続する期間/データベースが存在する期間)
- Workflow Scope (数時間〜数ヶ月程度以上のGOALを持つ業務タスクの遂行期間)
- Application Scope (サービス提供期間/アプリケーションが稼動している期間)
- Session Scope (利用者の作業期間/ログイン〜ログアウトの期間)
- Conversation Scope (数分〜数十分程度のGOALを持つ短い業務タスクの遂行期間)
- Request Scope (利用者の指示を遂行する期間*3 )
- Action Scope (指示を細分化した粒度の細かい処理/ActionChain*4の1Action?)
ApplicatoinとSessionは、微妙に毛色が違うような気のせいもしますが…
…それで? と言われるとそれまでです…^^;;;
最近*5、自分の中でContextという言葉が1つのキーワードになっています。Context-Drivenあるいは、Context-Centricな開発やフレームワークってできないかなぁと*6…
Contextという言葉は、まさに文脈によっていろいろなイメージがあると思いますが*7、自分としては Chain of Responsibility パターンにおける主体となるもの*8という捉え方が1つ。これをActive-Contextと呼ぶとします。一方、
先ほど出た7つのScopeに対応するContextがもう1つの捉え方です。これをPassive-Contextと呼ぶとします。
そうすると、Active-Contextがシステム利用者とシステムの間、あるいはシステム間をぐるぐる回りながら、Active-ContextとPassive−Contextの間でデータをやり取りするというイメージが湧いてきたわけです。
これを踏まえ(?) … もう少し具体的に、現在のWebシステムに当てはめて考えると、
- Active-Contextが、ユーザの入力データを受け取ります。(これもResponsibility Chainで)
- Responsibility Chain のトンネルの中に放り込みます。
- 各Chainは以下のような処理を行います
- Passive-Contextに特定スコープのPassive-Contextのデータをコピーしたり
- Active-Contextのデータを処理してActive-Contextに書き戻したり
- Active-Contextから、特定スコープのPassive Contextにデータを書き戻したり
- …などなど
- Active-Contextからユーザ用のビューを作ります。
- 繰り返し
配管作業の要領でビジュアル・コンポーネント指向でアプリケーションが作れたらいいなぁ〜なんて…
DOAのフレーバーが若干…? 現在のWEBシステムをContextで言い換えただけ…? でも、名前重要! イメージ重要! (個人的な)しっくり感重要! なので… なんとなく書いてしまいました…
こんなの100年前からあるよ! とか、このパターンはこんな問題を含みます、みたいな情報があれば、"優しく"コメントしてください ^^;;;
っていうか、文章まとまってなさ杉… 頭の中も整理されていなさ杉…orz
CONVERSATION SCOPE
S2のソースコードを読んでいます。S2には外部コンテキスト(ExternalContext)という、サーブレットコンテナ上のコンテキスト(Application、Session、Request、Responseを含む)を抽象化したものがあります。いまのところほぼ100%サーブレットコンテナが対象だと思いますが、いろいろ応用も考えられるし、Mockを使ったテストとかには便利そう。
ところで“Spring WebFlow”というWEB画面の遷移を制御/管理するフレームワーク(今度こそ1.0が出そう…^^;;)があります。これを解説した“Expret Spring MVC and Web Flow”*1という書籍のなかで『Conversation Scope』*2という言葉が出てきました。なるほど、言い得て妙だなぁと思ったのですが、どういうものかというと「生存期間がRequestより長く、Sessionより短いスコープ」という意味です。具体的に言えば、ウィザード的な閉じた画面遷移系とか、ドリルダウンした状態で使える閉じた画面遷移系のスコープのようです。
S2のExternalContextに、Conversation Scope があったらどうなるだろう? と漠然と考えてみました。
- Conversation Scope Context
Application > Session > Conversation > Request/Response
-
- Sessionに固有のキー名で、ConversationMapみたいなのを持つのかなぁ
- 親の遷移系から子の遷移系に移った場合、戻った時の為に、親の遷移系の情報は保持する必要があるなぁ…スタックか?…Continuationか?
- そうするとSessionスコープもルートConversationスコープみたいに考えれば、汎用的にConversatoinスコープで扱えるかなぁ…Spring WebFlowはどうやってるのだろう…をコードを覗いてみようかなぁ…
- でも、ポートレットみたいに、画面上に複数の独立したパネルがあって、各パネルがそれぞれ独立したコンテキストを持っている場合や、さらに同時並行にAjaxしちゃうような場合にも使いたいなぁ…これでは、スタックだけじゃだめだなぁ…
- Session
- ∋ ConversationStackMap(concurrent conversation)
- ∋ ConversationStack(drill down conversation)
- ∋ ConversaionMap(conversation scope context)
- ∋ ConversationStack(drill down conversation)
- ∋ ConversationStackMap(concurrent conversation)
- こんな感じ?…ややこしいそうだなぁ…
- うぅん…
と、いうわけです(?)。漠然としたまま思索終了です…orz
OBJECT CLUB SUMMER EVENT 2006
オブジェクト倶楽部の夏イベントに参加してきました。
が、体調不良の為、遅刻…基調講演聴けず…
…聴いた人の話を聞くと、とても面白かったらしい…非常に残念…
というわけで、前半セッションから…
なお、聞き漏らしたところは抜けてたり、ところどころ自分の心像の言葉になっていたりしてますので、講演者の皆さん本人の言葉である保障はありません…
個人用メモということで…
- セッション前半
- 和田卓人さん(t-wadaさん)
- デベロッパー・テスト
- テストの分類の複雑化
- xUnitの登場
- デベロッパー・テスティングの作用
- 開発者の心の健康
- リアルタイムなフィードバック
- ソフトウェアに対する自信
- 次のソフトウェアに対する自信
- テスト済みのソフトウェア部品を使用して開発する場合など
- ソフトウェアの健康
- …いわずもがな…
- さまざまな信頼の獲得
- ソフトウェアの信頼
- 開発メンバーへの信頼
- お客様からの信頼
- 開発者の心の健康
- Developer Testing
- Stub/Mock
- Network、File System、Database
- Debugging Test
- BUG検出
- 再現テスト … ガマンして書く …時にはできない時もあるけど…
- RED
- GREEN
- Learning Test
- 未知の(使ったことのない)ライブラリのテストなど
- ライブラリの理解
- (未知の)ライブラリを使用してコードを書く
- テストが学習結果として残る → 他の学習者の参考になる
- Assumption Test
- 外部ライブラリのテスト
- Test as Documentation
- ソース → HOW
- テスト → WHAT
- …忘却…
- Good Practices
- TDDの流れ … テスト・ファースト
- 道はひとつではない
- 美しいくてまだ動かないコード → 美しく動くコード
- 汚いけど動くコード → 美しく動くコード
- ※ 「汚い→美しい 軸」と「まだ動かない→動く 軸」の2次元グラフは分かりやすかったです
- 道はひとつではない
- リファクタリング
- GOAL指向
- What do you want to do ?
- What makes you fun ?
- …
- Fear
- Next action
- GTD〜similar〜TDD
- "HEART"
- × Open loop (開ループが生産性に与えるダメージは大きい)
- EOT (Ease Of Testing)
- 責務 → …
- コラボレーターを減らす
- etc...
- 他の人が分かるテストコードを書くことが重要 → 多少冗長でも…DRYにはこだわらない
- 稼動時の Debugging Test は、外から攻めることが多い → そしてBINGO !
- Developer Testing is SKILL !
- So, Everyone can do it! Sure! You can do it!
- Stub/Mock
- セッション後半
- 全体講演
- 懇親会
講演者の皆様、後援者の皆様、運営の皆様、ボランティア皆様、参加者の皆様、お疲れ様でした。個人的にとても楽しめました! ぜひ冬のイベントにも参加したいと思います。
ではでは…以上、オブジェクト倶楽部 2006年 夏 イベント レポートでした。
※ 読み返すと書き方 酷杉 → 自分 orz
