mikuriya.bizThis domain may be for sale!
はてなブログ | 無料ブログを作成しよう
思いは言葉に。 はてなブログは、あなたの思いや考えを残したり、 さまざまな人が綴った多様な価値観に触れたりできる場所です。
1分でWebアプリを作れるEclipseプラグイン「Dolteng」
1分でWebアプリを作れるEclipseプラグイン「Dolteng」：Java初心者が超俊敏にWebアプリを作る方法（1）（1/3 ページ） Javaの業務用Webアプリ開発に必要なもの 読者の皆さんは、Javaで業務用のWebアプリケーションを開発するのに必要なものとして何を思い浮かべるでしょうか。統合開発環境？ サーブレット/JSP？ アプリケーションサーバ？ Struts？ DB接続のO/Rマッピング？ DIコンテナ？ 技術的には、これらも確かに必要です。また、アプリケーションが“安全”に“確実”に動くことが業務で使うときには求められます。 上記は当然のものとして、“仕事”として売り上げを上げるためにアプリケーション開発を行う場合に一番求められるのは、アプリケーションを一から開発する際や、デバッグ／修正する際の“速さ”や“俊敏さ”ではないでしょうか。 たとえJava言語の初心者、また
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
Seaserのホットデプロイとリフレクション
Seaserのホットデプロイは 実行時に特定箇所でクラスローダを毎回新しくするというシンプルなものです。 結構、割り切った作りになっているなぁというのが感想ですが、そのシンプルさと原理からいろいろと制限事項も生まれてしまう。 今回、私がハマったところはフレームワーク内でリフレクションをする際に、クラスローダの違いからClassCastExceptionを出したり、NoSuchMethodExceptionを出したりしたことでした。 クラスローダの基礎知識 まず、基礎知識としてクラスローダが違う場合、同じClassでも代入互換性がありません。Classの同一性は、Class自身とそのクラスローダによって定められます。 次に、クラスローダは階層構造をなしていて、まず親クラスローダにロード処理が移譲されます。 ClassLoader ClassLoader クラスは、委譲モデルを使ってクラスとリ
TopHatenarはRails並の軽さで作られている - kaisehのブログ
TopHatenarにみる「Javaの復活」 - yvsu pron. yas Java好きな僕としては、TopHatenarが、Javaでも（Seasar2ファミリーを使えば特に）スピーディーなWeb開発ができることの実証例になれば良いなあと思っています。 ただし、HOT deployが使えない場合はさすがに「Javaでもスピーディー」とは言えないかも*1。S2ファミリーのフレームワーク（SAStruts, Cubby, Teeda, etc）なら基本的にHOT deploy対応なので大丈夫です。 ここで、TopHatenarのコードの一部を引っ張り出して、仮に同じことをRailsでやったらどうなるか考えてみようと思います。 結論を先に言うと、すごく似た感じになります。TopHatenarはCubbyを使ったけど、SAStrutsでも大枠は同じになるはず。 以下は、http://toph
2008-04-20
追記： 以前に以下のようなエントリを書いてしまいましたが、 transient を付けたプロパティは、HOT deployとCOOL deploy で 挙動が違うことが判明したため、使わないこと強くを推奨します。 混乱させてしまって、スミマセン。 挙動から判断するに、HOT deployの時は、HogeDtoをシリアライズ して何処かに退避しておき、クラスローダが差し替わった後には シリアライズしたものを使ってHogeDtoを復元しているように思えます。 transient を付けたプロパティは、シリアライズの対象から外れるため、 結果的にセッションスコープではなくなります。 しかし、そもそもCOOL deploy ではシリアライズやクラスローダの差し替えは 行われないので、transient を付けたプロパティもセッションスコープと なってしまう訳です。 次のエントリのコメント欄でこの記
普段私がコードを書く時に気を付けていること - 出羽ブログ
普段私がSAStrutsでアクションのコードを書く際に 気を付けていることをまとめてみました。 原則： 既存コードを修正することなく、機能追加を実現する 画面が追加されても、既存のメソッドに修正が入らず、メソッド追加で対応できること ボタン追加などイベント処理が追加されても、既存のメソッドに修正が入らず、メソッド追加で対応できること 初期化ロジックの無い箇所に後から初期化ロジックを追加する場合でも、クラスのインターフェースは変更しないこと できるだけタイプセーフなコードにすること メソッド・シグネチャにおける属人性を排除する この原則を成し遂げるために、以下のコーディング規約を守る必要があります。 （オリジナルであって公式ではない。） コーディング規約 全てのアクションにindexメソッドを用意する Teedaスタイルで入力系メソッドと出力系メソッドを分離する（※） JSPを単独で使用しな
そろろろRailsについて本音を書いてみるか - ひがやすを blog
最近の大田さん@mixiのところで、Rubyについて考察する機会があったのと、よういちろうの考えと同じことを思っていたので、たまには本音で書いてみる。 Railsで、最も良いところは、テストの雛形も自動的に作ってくれて、テストの敷居を下げてくれてるところだと思う。なのに、それについて触れる人があまりにも少ないような気がする。一応、私は、1年半以上、はてなのキーワード検索で毎日Railsについては調べているので、はてなでRailsについて書いている人の記事はたいてい見ています。 理由は、いくつか考えられますが、私の読みだと、テストが当たり前の人にとっては、当たり前すぎてわざわざ書く意味がないし、そうではない多くの人にとっては、ほとんどテストは書いていないんじゃないかな。 実は、テストを書くのは結構工数かかるんですよ。スクリプト言語は、コンパイラがミスを教えてくれることはないので、Javaと比
Teeda + DBFluteプロジェクトのセットアップのFlash動画 - 出羽ブログ
近日中にライブコーディングの内容を Flash動画で公開することにしました。 先日のSeasar Conference 2007 Autumn の 「実践的なサンプルアプリをその場でコーディングします！」の デモでトラブル多発で ヘタこいてしまったので、 めげずに当初予定していたデモを随時Flash動画にて アップしていきたいと思います。 まだ途中ですが、フライング気味に 「Teeda + DBFluteプロジェクトのセットアップ」の Flash動画をアップしました。 ■準備編 ○Teeda + DBFluteプロジェクトのセットアップ ・Churaプロジェクトの作成 ・DBFlueのセットアップ http://dbflute.sandbox.seasar.org/view/demo/webdbvol41/1_setup.html ↑ ※ 画像をクリックしたらページに飛ばしたいが、 はてな
2007-10-25 - ひがやすを blog
っていうか、Hibernateにも昔からcriteriaあるよね？ http://www.hibernate.org/hib_docs/v3/reference/en/html_single/#querycriteria List cats = sess.createCriteria(Cat.class) .add( Restrictions.like("name", "Fritz%") ) .add( Restrictions.between("weight", minWeight, maxWeight) ) .list(); 流れるようなインターフェースとメソッドチェーンは違うものだよヨシオリ。ぱっとみは似ているかもしれないけど。 流れるようなインターフェースでは、ソースコードを書いている人が、中断することなく流れるようにコーディングできなければいけない。 HibernateのCrit
ひがやすを blog - 2007-09-24 - 「なぜお前らは「好きだからコードを書く」はできるのに「好きだからメンテナンスする」ができないのか?
本当の問題は「スーツ + 頭のカタイおやじ VS. 無垢な技術者」という話だろうか。なんで、スーツの人や、頭のカタイおやじや、無垢な技術者がいるのか、その前提条件を問わなくちゃいけないんじゃないのか。その前提条件に、自分がどんな一手を打てるのかを考えて、世界を変えていこうよ。ていうか、世界を変えていたじゃない。 なんか、高井さんが勘違いしているみたいだから、書いておくけど、俺は、「だから世の中が悪い」とかいうつもりはありません。この構図は、過去何度も繰り返されている事実だから、まず私たち技術者は、その事実をきちんと認識しなければならない。 昨日は書かなかったけど、実は、「弱い技術者」というのは、「頭の固いおやじ予備軍」でもだったりする。 実際良く見かけるんだけど「最新の技術についていくのは疲れた」「なにかスーパーなデファクトが現れてそれで統一されて欲しい」「考えるのめんどくさいから標準で統
回り道日記 - 規約早見表が欲しい
@ 規約早見表が欲しい規約ベースなので、id とプロパティの対応の一覧が欲しいなあ。たとえばこんな感じ。機能名とか適当。(※この表は不足や間違いがある可能性があります。また、リンク先が正しくない場合があります) 機能タグおよび属性HTML上のidプロパティ名
ErrorPageManager経由で例外のPageに遷移したときに、発生したExceptionをインジェクトできるようにする。（sugaさんのご要望に応える） - おおたに6号機blog
まずこの件は明らかにバグなので 瞬殺で修正しました。 で、次の件（エラー画面にスタックトレースを出したい）なんですが、 これはPageクラスに普通にExceptionがインジェクションできたほうが良いだろうと いうことで、そのように修正しておきました。 こんな感じになります。 /** * スタックトレースを表示するためのページクラス。 * * @author suga */ public class ErrorResultPage { private static final String SERVLET_NAME = "javax.faces.webapp.FacesServlet"; private FacesContext context; private String stackTrace; private Exception exception; public String pr
列挙について更に考える - 六の日記はこっちになったぞ
もっと考えてみると、Entityに列挙をプロパティとして持つ事で受けるメリットとデメリットのバランスが悪すぎる。 Entityクラスを自動生成する方法がいくつかあるのに、それが素直に使えない。EntityクラスってくらいなのでDB上の型と合わせた方が筋ではないかいのう、などなど。 で、条件分岐などで区分を見るとかだったら、 if(HogeFlag.NOT_HOGE.getValue.equals(fuga)){ //ああだこうだ }とかやればいい訳だし、大した事ではない。 列挙のメリットは、メソッド呼び出し時の引数の型チェックが大きいと思う。だからEntityのプロパティまで律儀に列挙にするメリットはあまりないよなあ。 やっぱWebアプリの場合、需要なさそうだなあ・・・。
列挙についてもちょっと考える - 六の日記はこっちになったぞ
よく考えてみたらば、S2Daoで上手い事文字列の区分から列挙に変換してEntityクラスにマッピングしてくれるとベストではないかと。 Dtoは基本的にプレゼンテーション層依存と考えてるので、そこから独立した業務ロジックたるLogicクラスではEntityを見て色々とやるのが筋かと思うわけです。 その時の条件分岐なんかに列挙が使えれば、これは固い。 で、HTMLベースのWebアプリだとUIでは文字列で持つしかないので、Dxoでは逆に列挙から文字列へ変換して、プレゼンテーション層へ渡す。 さて出来るかな・・・。 もっと贅沢云うと、Dxoでは変換しないで、プレゼンテーション層のフレームワークで列挙→文字列変換。うーんこれは要らんかな。 なんで俺はこんなに列挙が好きなんだ？
2007-03-09
id:koichikさんにコメント戴きまして。有難う御座居ます。 教わったとおり、こんな感じで。 public Object convert(Object source, Class destClass, ConversionContext context) { if(source ==null){ return null; } String srcStr = source.toString(); for(Object e: destClass.getEnumConstants()){ if(e.toString().equals(srcStr)){ return e; } } return null; }わーできました！getEnumConstantsなんてメソッドがあったとは・・・これでEnum側でgetEnumFromなんてクラスメソッドを実装しないでいけますよ。 標準ではEnum#
2007-03-08
DB上の区分をそのままシステム上で文字列定数で扱うのはいやだなあと思って、せっかくのSE5.0なので列挙を使ってみる事にした。 最初、Service層で変換かけてやれと思ったんだけど、これまたせっかくなのでDxoでやってしまおうと思いました。 列挙から文字列へはこんな感じでやってみた。 まず列挙。送信フラグ、とかそんなの。 public enum SendFlag { NOT_SEND("N"), SENDING("S"), SENT("E"); private String value; SendFlag(String value){ this.value = value; } public String getValue(){ return value; } }変換対象となるBeanたち。Hogeでは区分を文字列で持つ。HogeDtoで区分を列挙で持つ。 public class Ho
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
c-sq.com
c-sq.com