画面遷移図

以前、画面遷移図にレイアウト情報を貼り付けると、ユーザの興味がレイアウトにいってしまい、画面遷移そのもののレビューができないということを書いたのですが、実際に試すと、画面遷移のレビューは、問題なく終わるのですが、結局、画面遷移そのものは理解していないということが分かりました。
人は、ある程度具体的なものが見えないと理解しづらいということですね。
そこで、モックの縮小版を貼り付けて、画面遷移図のレビューをすることにしました。


モックを作る上で問題になるのが、画面にどのような項目を出すのかがFixしていない、レイアウトもFixしていないというものです。レイアウトはデザイナに任せることが多いので、結局後で変更されます。
要件定義の段階で、モックが出来上がっているなら、ものすごく都合が良いのですが、そんなことはまずありません。デザイナに頼むと高いので、できるだけ発注を遅らせるためです。


画面にどのような項目を出すのかがFixするまで待っていると、いつまで経ってもプロジェクトが進みません。良くある話です。
そこで、モックを作る段階で分かっている範囲で、入出力項目を決めます。まだ、未定だとかいわれることも多いのですが、最もこうなるだろうという確立が高いものに賭けます。実際にモックを見るとユーザの考えが整理されて、仕様がFixしていくものだからです。最初のモックはたたき台という考えで良いんじゃないかと思います。
レイアウトは後からどうせ変わるので、こらずに最もオーソドックスなものにします。


最初のモックで、画面遷移図を作ってレビューをおこないます。同時にモックで実際の画面遷移は確認してもらいましょう。より具体的なものが理解しやすいのです。
私が、物事を抽象化して本質的なものを抽出しようとするモデラーを胡散臭く思うのはそのせいです。

あんたの作ったモデル、誰も理解してないですから。残念！！！

レビューでOKがでたら、次はバウンダリとエンティティの設計です。レビューしたときに、入出力項目や、リンクやボタンなどの機能についてフィードバックがありますから、モックに反映させます。モックがバウンダリ設計のインプットですから。

キーワード

はてなを利用のみなさまに、できれば、ということでのお願いなのですが、Seasar関係の話題の場合は、SeasarもしくはSeasar2、くーす関係の話題の場合は、くーすと記述してもらえると、はてなのキーワードから私が追っかけることができるので、何かあればフォローアップします。
早めに気づいて欲しいときには、id:higayasuoと記述してください。
よろしくお願いします。

ThreadLocalを使いたい場合

コンポーネントから、HttpServletRequestなどにアクセスしたい場合もあるでしょう。そのような場合は、ThreadLocalを使って管理するのが一般的です。
しかし、このような管理クラスを作る場合に、シングルトンやstatic変数を使ってはいけません。グローバル変数はできるだけ避けなければなりません。それではどうすれば良いのでしょうか。
まず、くーすらしくRequestContextというインターフェースを定義します。

interface RequestContext {

  HttpServletRequest getRequest();

  void setRequest(HttpServletRequest request);

}

次は実装クラスです。

class RequestContextImpl extends RequestContext {

  private ThreadLocal requests_ = new ThreadLocal();
  HttpServletRequest getRequest() {

    return (HttpServletRequest) requests_.get();

  }

  void setRequest(HttpServletRequest request) {

    requests_.set(request);

  }

}

このようにして、HttpServletRequestにアクセスしたいコンポーネントは、RequestContextをDIしてもらえばいいのです。テストのときには、ThreadLocalを使わないRequestContextの実装を使い、ThreadLocalの副作用を避けます。
staticなThreadLocalやシングルトンが良くないのは、あるテストで行ったことが別のテストに影響(副作用)を与えてしまうことです。
RequestContext、ResponseContextは次のSeasar2のリリースに含まれるかも。コンポーネントのインスタンス管理をrequest,sessionごとに行うことに対する布石。


JSFもこうなってほしかったなぁ。> FacesContext
まさにシングルトンとThreadLocal。そのせいでテストがしにくいんですけど。

いまそこにある下半身危機

今年は三十路突入な節目だったのですが、一昨年辺りから一足早く、そいつはやってきました。中年の危機、そうビール腹というやつです。

あの手のサプリメントは、結局気のせいです。残念！！！
サプリメント大好きだった私が言うのでたぶん間違いない。効果があっても極わずかでしょう。
そうそう、女性はあの手のサプリメントを試している男性は、あまり好ましく思わないみたいです。


結局脂肪を燃やすのは、赤い筋肉です。瞬発力につながる白い(?)筋肉ではありません。地道に筋力をつけて燃やすしかないのです。そうすれば、基礎代謝もあがり、太りにくい体になります。食べると直ぐ太る、便秘がちという場合は、筋力不足である可能性が大です。
おなかの脂肪を落とすには、腹筋とわき腹の筋肉を鍛えるのが一番です。私は、毎日、通常の腹筋運動を20回、体を左右にひねっての腹筋運動を20×2やってます。
腹筋だけを鍛えると体のバランスが悪くなるので、背筋も鍛えましょう。
毎日10分くらいの筋トレで、腹が出るのを防げます。


後、できるだけ大またで歩き、股間の筋肉を鍛えましょう。ヒップが垂れるのを防ぎ、引き締まった太ももが手に入ります。

Singletonの怖さ

Singletonはテストと相性が悪い。なぜなら、テストメソッド間で状態を維持してしまうからだ。

このようにいってきた私自身が、Singletonにはまってしまいました。
無念だ。心より恥じる。
S2Daoのテストをしているときに、ロールバックが効かない場合がありました。何でだろう。実はこの3日間、ずっと悩んでいました。
原因は、DaoMetaDataFactoryで、DataSourceごとキャッシュしていたためでした。Singletonで管理されていたため、前のテストで使ったDaoMetaDataが古いDataSourceごと次のテストで使われていたのです。
性能を確保するためにキャッシュするにしても、Singletonを使うのは避けた方がいい、ReadOnlyではないstatic変数は避けた方がいいということを身をもって知りました。