Seasar関連の便利クラス - 出羽ブログ
フレームワーク開発者ではなく、フレームワーク利用者の視点でSeasar関連のjarファイルに�内包されている便利クラスをピックアップしました。 便利クラスの存在を知って活用することは大切ですが、もっと大切なのは、便利クラスを自作する前に、フレームワークやプラットフォームで似たようなモジュールが存在していないかチェックする習慣だと思います。 他にも便利なクラスやメソッドがあれば、ぜひ、コメント等で教えて下さいませ m(_ _)m 。 ArrayUtil.isEmptyメソッド 用途 配列が空（null）かどうかをチェック jar s2-framework-2.4.xx.jar パッケージ org.seasar.framework.util メソッド static boolean isEmpty(Object[] arrays) ArrayUtil サンプル if (arrays == nul
2008-06-26
趣旨とあんまり関係ないですが、Service・Logicをとりまぜた3階層にするならば、エンティティによったものをService、アクションによったものはLogicと呼んだ方が、フレームワーク側の呼び方との親和性は高いように思います。 ちなみに、今はこんな感じの設計はどうかと思っています。 Serviceクラス：エンティティと対につくる。ドメインモデル的な考え方がプロジェクト内でついていけないならばいっそのこと導入しない。 Logicクラス ・ユースケースを跨がる画面まわりの制御処理や、ユースケースをまたがるビジネスロジック特有の処理を書く。いわゆる、サブシステム間共通関数のイメージ。たとえば複数ユースケースであるケースでは沢山の表にインサートするが、あるケースではアップデートのみするようなものを使う。 ・ただし、Serviceクラス的設計が難しい場合には、画面制御的なクラス Servic
2008-06-19
昨日、Firefox3が正式リリースされたのでインストールしてみました。 激速ですね。素晴らしい！キビキビしまくりです。 次世代ブラウザ Firefox http://mozilla.jp/firefox/ 今まで、WebブラウザはSafariを使っていたので、速さでは満足していました。でも「Googleツールバー」と「はてなバー」、「マウスゼスチャのプラグイン」が使えないことがやや不満でした。「Googleツールバー」で英単語にマウスフォーカスするとポップアップで日本語の意味を教えてくれる機能がないと、何気に英語の文章を読むのが辛かったんですよね〜。 SafariからFirefox3への移行において心残りなのは、Safariの美しいフォントから離れてしまうことです。 「Googleツールバー」以外のプラグインは、まだ確かめていませんが、これを機にメインで使うWebブラウザはFirefox
SAStruts + S2JDBCのアーキテクチャを図示してみる - 出羽ブログ
SAStruts と S2JDBC を使って少し複雑なケースのWebアプリを開発する際において、現時点で自分が一番良いと考えているアーキテクチャを図示してみました。 なかなか良い感じです。あえて、課題をあげるならば、次の２点です。 アクションフォームの内部クラスに @Component(instance = InstanceType.SESSION) を付けて、スコープをセッションにしたいができないこと（やり方が分からないだけだと思う。）←できないことが判明しました ユースケースをまたいでアクションフォームを使用しない方針とした場合、検証メソッドをアクションフォームに書きたくなるが現状ではアクションにしか書けないこと。 追記： 1.0.3-rc1 より検証メソッドはアクションフォームに書くことができるようになります。 よって、検証メソッドはアクションからアクションフォームへ移すことをオスス
2008-05-31 - 出羽ブログ -「８割の簡単な処理」と「２割の複雑な処理」への対処方針
例えば、アプリケーション全体の構成要素として、簡単な処理が占める割合が８割で、複雑な処理が占める割合を２割あったとします。この場合、次の１〜３のどの方針を採用するだろうか？ [方針１] ８割の簡単な処理にあわせる 生産性重視。ただし、複雑な処理で品質を落としやすい。 [方針２] ２割の複雑な処理にあわせる 品質重視。ただし、簡単な処理の生産性は落ちる。 [方針３] 両方の対処方法を用意して、使い分ける 最適化重視。ただし、厳密な使い分けは難しい。 例えば、Strutsにおいて、見た目まわりの処理を実施する場合はこんな感じになります。 [方針１の実装例] EL式（もしくは、スクリプトレット）を使う。 [方針２の実装例] ロジックはコントローラ側で実施して、結果フラグ等をViewへ渡す。 View上では、結果フラグを使った分岐処理のみに留める。 [方針３の実装例] 例えば、変数が２〜３個で処理
2008-04-20
追記： 以前に以下のようなエントリを書いてしまいましたが、 transient を付けたプロパティは、HOT deployとCOOL deploy で 挙動が違うことが判明したため、使わないこと強くを推奨します。 混乱させてしまって、スミマセン。 挙動から判断するに、HOT deployの時は、HogeDtoをシリアライズ して何処かに退避しておき、クラスローダが差し替わった後には シリアライズしたものを使ってHogeDtoを復元しているように思えます。 transient を付けたプロパティは、シリアライズの対象から外れるため、 結果的にセッションスコープではなくなります。 しかし、そもそもCOOL deploy ではシリアライズやクラスローダの差し替えは 行われないので、transient を付けたプロパティもセッションスコープと なってしまう訳です。 次のエントリのコメント欄でこの記
2008-02-22
SAStrutsとStrutsはアクションのコンポーネントの スコープが異なっているので注意しなければならない。 アクションのスコープの違い Struts singleton SAStruts request 生Strutsのアクションが持つフィールド 複数のスレッド間で共有される一方、 冗長化構成のマシン間では共有されない。 このようなクセがあるために、使用を避ける、 もしくは、慎重に使う必要がありました。 （使用禁止にしていたプロジェクトも多いと思われる） SAStrutsのアクションのフィールド 他のスレッドに影響を及ぼさないrequestスコープなので、 気軽にどんどん使用することができる。 ちなみに、アクションのフィールドをpublicフィールドとして 宣言しておくと、次のようにJSP側のEL式で簡単に呼び出すことができる。 HogeAction.java package tut
2008-02-08
1つユースケースに閉じていることは、すべてActionに記述し、複数のユースケースで使われるものをLogicに分割するのがシンプルでわかりやすいのではないかと、そう思ったわけです。 ＜＜中略＞＞ 追記2:コメントへの回答ですが、ユーティリティは、staticメソッドで構成されるやつは、utilのパッケージ。ActionにDIするやつは、logicパッケージでいいと思います。どっちでもないユーティリティもutilパッケージですね。 Entityについては、SAStrutsのドキュメントにもこのblogでも書いていますが、1つのEntityに閉じたロジックならEntityに記述するということでいいと思います。複数のユースケースで使うからこそ、Entityに書く意味がありますね。個別のユースケースでしか使わないなら、Actionに書いたほうがいいと思います。 上記のひがさんのエントリーを元に「ど
JavaScriptの技法：高度な関数の活用 - 出羽ブログ
・JavaScriptの技法：高度な関数の活用 http://builder.japan.zdnet.com/news/story/0,3800079086,20364532,00.htm 「今風のJavaScriptは、何だか良く分からないなぁ」なんて思っていたら、 いい記事を見つけることができた。軽くまとめながら理解を深めてみる。 JavaScriptで関数を定義する方法 3種類の方法で関数を定義できる。 function文を用いた定義 function add(x,y) { return x + y;} Function()コンストラクタを用いた定義 var add = new Function('x','y','return x + y;'); functionリテラルによる定義 var add = function(x,y) {return x + y;}; JavaScript
2007-11-19 - 出羽ブログ 〜はてな版〜 - [ソフト開発]コーディングの際に「やっていること・やるべきこと」のまとめ（β版）
コーディングの際に、知っておくべき情報や注意してる点など、 やっていること・やるべきことを自分なりにまとめてみました。 ただし、（おそらく永遠の）ベータ版です！ クラス名、メソッド名、変数名などの名前付けにこだわる。 変数名へのこだわりの無さが「バグの温床」になることを理解する。 名前と内容は一致しなければならない。 名前から内容が容易に推測できるものでなければならない。 １つの対象に別々の変数名を付けない。（変数名の一貫性）特に、チームメンバー間でズレやすいので気をつける。 チーム内で変数の命名相談を繰り返すことで、命名センスの均一化に繋がる。 コーディングスタイルは無数にある。重要なのは、自分のスタイルを貫くことではなく、１つの決めたスタイルに合わせることである。 NullPointerExceptionがでないかどうかに神経を使う パラメータ引数がnull だったら、戻り値がnull
2007-09-18 - 出羽ブログ ～はてな版～
今日、六本木のコンビニで「デューク更家」を見かけました。 一応、普通の歩き方をしていましたw 執筆した原稿で添削された箇所。 うーん、もっと精進せねば、、、。 ×：まずは、 ○：先ずは、 ×：活かせて頂ければと思います。 ○：活かして下さい。 ×：〜するといった ○：〜するという ×：各ページごとの詳細な… ○：各ページの詳細な… ×：〜のようになっております。 ○：〜のようになっています。 ×：仕様において ○：仕様に基づき ×：さっそく ○：早速 ×：〜がミソです。 ○：〜がポイントです。 ×：URLを打ち込まずに ○：URLを入力せずに ×：修正したら、 ○：修正すれば、 ×：実感して頂きたいです。 ○：実感して頂きたいのです。 ×：プロジェクトごとでアーキテクチャをデザインしてください。 ○：プロジェクト毎にアーキテクチャをデザインしてください。 ×：更新対象となる。 ○：更新対象
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
2007-10-25 - 出羽ブログ 〜はてな版〜