タグ

関連タグで絞り込む (1)

タグの絞り込みを解除

seasarと開発に関するgakkiyのブックマーク (4)

  • Seasar2でサクサクか炎上か - ひがやすを技術ブログ

    可燃プロジェクトに飛び込むことになりました。下記のような炎上する要素満載。 関係者各社に告知済みのためカットオーバーは伸ばせない 外部仕様を策定した会社は行方不明 外部仕様はあるが、OS も AP サーバも環境もアーキテクチャーも未定 外部仕様を分かる人がいないw 開発は 3 社合同なのにソース管理方式も決まってない DB アーキテクト不在っぽい フレームワークに詳しい人がいない AJAX っぽいのたくさん お金がない、規模はわりとでかい、納期短い、残業禁止、増員不可 最初このエントリを見たとき、4/1だったこともあり、一瞬ネタかなと思ったんですが、その後に、SAStrutsとS2JDBCに対する具体的な質問がいくつもあり、私のほうもできる限り質問に答えました。 その後、どうなったのか気がかりだったんですが、今見たらこんな書き込みが 開発メンバからは、簡単で楽でいい! 1 機能が 1 時間

    Seasar2でサクサクか炎上か - ひがやすを技術ブログ
  • 普段私がコードを書く時に気を付けていること - 出羽ブログ

    普段私がSAStrutsでアクションのコードを書く際に 気を付けていることをまとめてみました。 原則: 既存コードを修正することなく、機能追加を実現する 画面が追加されても、既存のメソッドに修正が入らず、メソッド追加で対応できること ボタン追加などイベント処理が追加されても、既存のメソッドに修正が入らず、メソッド追加で対応できること 初期化ロジックの無い箇所に後から初期化ロジックを追加する場合でも、クラスのインターフェースは変更しないこと できるだけタイプセーフなコードにすること メソッド・シグネチャにおける属人性を排除する この原則を成し遂げるために、以下のコーディング規約を守る必要があります。 (オリジナルであって公式ではない。) コーディング規約 全てのアクションにindexメソッドを用意する Teedaスタイルで入力系メソッドと出力系メソッドを分離する(※) JSPを単独で使用しな

    普段私がコードを書く時に気を付けていること - 出羽ブログ
  • 2007-12-03 - ひがやすを blog - Super Agile Struts開発記その6 - JSTL連動

    以前のエントリで、BeanUtilsとHOT deployをあわせて使うと、PropertyDescriptorが無駄にどんどんキャッシュされていってメモリリークする話を書きました。 http://d.hatena.ne.jp/higayasuo/20070725#1185340917 実は、問題はそれだけではなく、BeanUtilsは、publicフィールドをプロパティとして認識しないという問題もあります。メモリリークだけなら、どこかでクリアすれば良いだけなのですが、publicフィールドの場合は、どうしようもありません。 結局、BeanUtilsにJavaBeansのプロパティをアクセスされたら負けなのです。 最初に考えたのが、JavaBeansをDynaBeanでラップする方法。Struts単独なら、これでうまく行きますが、JSTLと組み合わせるとうまく行かない。なぜなら、JSTLは

    2007-12-03 - ひがやすを blog - Super Agile Struts開発記その6 - JSTL連動
  • ひがやすを blog - [etc]トランザクションスクリプトとドメインモデル

    このネタについては、ループしやすく結論が出ないので、あまり書きたくはないのですが、私の考えを誤解している人が多いようなので、書いておきます。 トランザクションスクリプト、ドメインモデルなんてのは、所詮実装の話で、どっちもどっち。トランザクションスクリプトが良いわけでもないし、ドメインモデルが良いわけでもない。私はどっちも好きではない。 重要なのは、ユースケース(ユーザ要件)と実装の対応関係が明確になっていることです。それさえ満たされていれば、実装はどうなっていてもかまわない。 ユースケースと実装の対応関係を明確にする方法の一つとして、ユーザ機能レベルのユースケースは、Teedaでいうサブアプリケーション(関連する複数の画面を束ねたもの)にマッピングする。サブアプリケーションは、関連する各画面の親クラスに相当する。各画面は、サブ機能レベルのユースケースに相当し、サブ機能レベルのユースケースは

    ひがやすを blog - [etc]トランザクションスクリプトとドメインモデル
  • 1