タグ

ブックマーク / ryoasai.hatenadiary.org (13)

  • Spring MVCでコントローラーのリクエストハンドラメソッドのメタ情報を記録する方法 - 達人プログラマーを目指して

    正攻法でアクションハンドラメソッドのメタ情報を取得することは困難 開発で利用するフレームワークを作成する際には、実行対象となるオブジェクトの型やメソッドに付けられたアノテーションなどのメタ情報を利用したい場合が多くあります。特に、Spring MVCを拡張してさまざまなことを裏でやらせたい場合には、現在実行中のクラスやメソッドのメタ情報(ClassクラスやMethodクラスのインスタンス)をスレッドごとにグローバルにアクセス可能なコンテキストオブジェクト内に記録しておくと便利です。なぜなら、Springの場合ViewResolverやViewなど独自に拡張可能なインターフェースが多数提供されているものの、通常の手段では実行中のクラスやメソッドの情報をパラメーターなどから簡単に取得できないことが多いからです。 たとえば、Spring MVCでセッション属性のキーをコントローラーごとに別々にす

    Spring MVCでコントローラーのリクエストハンドラメソッドのメタ情報を記録する方法 - 達人プログラマーを目指して
  • 大混乱に陥っているJavaEE 6のアノテーションに関する使い分けについて - 達人プログラマーを目指して

    JavaEE 6標準は、従来のJavaEE 5に対してさらなるEoDと軽量化を目指しているということだったのですが、いざ使おうと思うと、名前が同じアノテーションが複数のパッケージに定義されていたり、意味的にほとんど違いがないようなアノテーションが存在していたりで、初心者はもちろんのこと、ある程度ベテラン開発者であってもどう使い分けてよいものか途方にくれてしまいます。仕様は多数の人間の決めることですから、ある程度機能的な重複や矛盾があることは避けられないことですが、それでも、特にDIやEJB、管理Bean関係のAPIに対する機能重複についてはかつて経験したことがない程ひどく、これで当にfinalの状態なのかと信じられないくらいです。さまざまなアイデアを取り込むのは大歓迎ですが、かつて仕様に統一感があった(仕様自体はまったく使い物になりませんでしたが)EJB2.1のころの時代が逆に懐かしく感

    大混乱に陥っているJavaEE 6のアノテーションに関する使い分けについて - 達人プログラマーを目指して
    Nagise
    Nagise 2012/06/11
  • Javaの型パラメーターに対してstaticメソッドを呼び出した場合の挙動 - 達人プログラマーを目指して

    以前にJavaの配列関連で調べたことがあったのですが、Javaの総称型は型消去によって直感的でない挙動をする場合があります。 Java言語のClassクラスが持つちょっと不思議な性質について - 達人プログラマーを目指して Java5の型システムを理解するにはリフレクションAPIを使ってみるのが最短の近道になる - 達人プログラマーを目指して 特に、総称型の型パラメーターTについては以下はコンパイルできないという制約があります。 new T() new T[配列サイズ] catch (T ... extends T T.class instanceof T また、staticメソッドやstatic初期化ブロック内でクラスの型パラメータを使えないという制約もあります。 AngelikaLanger.com - Java Generics FAQs - Type Parameters - An

    Javaの型パラメーターに対してstaticメソッドを呼び出した場合の挙動 - 達人プログラマーを目指して
    Nagise
    Nagise 2011/11/30
    staticメソッドの場合は「オーバーライド」じゃなくて「ハイディング」(あるいは日本語で「隠蔽」)だからなあ。型変数にドットつけてstaticメソッド呼び出しできる機能は要らないとは思う
  • Java総称型のワイルドカードを上手に使いこなすための勘所 - 達人プログラマーを目指して

    Java5以降では総称型(generics)がJava言語に導入されています。総称型自体は、最近の静的な型付けのプログラミング言語で珍しいことではなく、現在の最新版では.NETのC#やVisual Basicにも導入されています。一般的には総称型をサポートするクラスライブラリを自分で正しく定義することは非常にスキルがいるが、事前に定義されたクラスを使うだけであれば、それほど難しくないとされています。しかし、Java言語の総称型はエントリで説明するように特殊なところがあり、単に利用するだけでも他の言語に比べて遥かに難しいところがあるというのも事実です。特に総称型をパラメータ化する際に指定するワイルドカード型(List<? extends Serializable>など)の意味を正しく理解して使いこなすことは簡単なことではありません。その結果、昔のJDK1.4までのように型パラメーターのない

    Java総称型のワイルドカードを上手に使いこなすための勘所 - 達人プログラマーを目指して
    Nagise
    Nagise 2011/03/26
    「C#でも最新の4.0からは参照型の型変数に対して変位指定が可能になっています」へえ
  • SI業界の改革には責任者に対するショック療法が有効かもしれない - 達人プログラマーを目指して

    私の直属の上司ではないのですが、会社の大先輩がインドに1ヶ月程滞在し、現地のSIerの開発現場を視察してきました。現地での研修を提供している会社は、あのデータさんの子会社になっているみたいです。 http://www.vertexsoft.co.jp/services/learning-in-india.html そこで、実際にインドのプログラマーアジャイルプロセスを使って開発をしている現場を目の当たりにし、いい意味ですっかり洗脳されて帰っておいでになりました。 1週間ごとに追加機能をリリース スタンドアップミーティングによるタスクの割り当て 徹底的に自動化された進捗管理*1 徹底的に自動化されたテスト きわめて計画的で少ない残業時間 プログラマーの地位の高さと優秀さ やはり、百聞は一見に如かずといいますが、日のSI業界の開発手法が20年も遅れていると言われても、何十年も開発の現場から

    SI業界の改革には責任者に対するショック療法が有効かもしれない - 達人プログラマーを目指して
    Nagise
    Nagise 2011/03/07
    大手SIerはここ10年ぐらいまるで進化していない。むしろ、昔やれていたことがやれなくなっていて退化しているのではないかとすら思える。下克上にはうってつけの時代だと常々思っている
  • 業務系のJavaプログラマーが知っておくべき10個のBad Partsとその対策 - 達人プログラマーを目指して

    Java: The Good Partsののタイトルに触発されて、逆にJava言語の使いにくい部分をいくつかピックアップしてみました。Java EEなどの業務系のアプリケーションプログラマーの視点で書いていますので、別の立場ではここで指摘している事項が必ずしもBad Partではないという指摘もあるかもしれませんし、他にもいろいろなポイントがあると思いますが、とりあえず、私の独断で思いついたものを10個説明したいと思います。 1.標準APIのチェック例外が扱いにくい Java言語のチェック例外は当にGood Partなのか? - 達人プログラマーを目指してでも取り上げましたが、Bad Partの第一番目として標準APIのチェック例外が扱いにくいという点を指摘させていただきたいと思います。チェック例外については、理屈上コンパイラーによって例外の処理をプログラマーに強制させることができるす

    業務系のJavaプログラマーが知っておくべき10個のBad Partsとその対策 - 達人プログラマーを目指して
    Nagise
    Nagise 2011/02/27
    歴史側というより後続言語ではどのように改善されたかの話。今、初期のJavaを見つめてみるのも面白いと思う
  • システム系の例外は実行時例外+AOPでハンドリングするのがベスト - 達人プログラマーを目指して

    インフラ層のチェック例外はやはりJavaのBad Partだと思う 先日のJava言語のチェック例外は当にGood Partなのか? - 達人プログラマーを目指してで、 インフラ層のフレームワークなどでは実行時例外が適切 ということを書いたのですが、この点についてもう少し詳しく考えてみたいと思います。 Java: The Good PartsのではRMIの章があるのですが、RMIではRemoteというマーカーインターフェースを継承しつつ、すべてのメソッドがRemoteExceptionというチェック例外を送出する規則となっています。 Java Good Parts(9.1節より引用) pubic interface StatRecorder extends Remote { void recordGame(BoxScore stats) throws RemoteException;

    システム系の例外は実行時例外+AOPでハンドリングするのがベスト - 達人プログラマーを目指して
    Nagise
    Nagise 2011/02/22
  • Java言語のチェック例外は本当にGood Partなのか? - 達人プログラマーを目指して

    デブサミ2011会場のオライリーのブースで目に入ったため、以下のを購入しました。 Java: The Good Parts 作者: Jim Waldo,矢野勉,笹井崇司出版社/メーカー: オライリージャパン発売日: 2011/02/24メディア: 大型購入: 3人 クリック: 148回この商品を含むブログ (37件) を見る180ページほどの薄いですし、各章は独立して気軽に読むことができます。早速、気になるいくつかの章から読んでみました。ただし、監訳者のid:t_yano氏も前書きで 書が、みなさんにとってJava以外の言語についても考えるようになり、みなさんのプログラミングの世界がさらに豊かになることを望みます。 と書かれているように、このから直接Javaのプログラミングのテクニックや知識を得るというよりも、ベテランの上級者がJavaについて考え直すきっかけ作りとして読むのが良

    Java言語のチェック例外は本当にGood Partなのか? - 達人プログラマーを目指して
    Nagise
    Nagise 2011/02/21
  • AJDTを使って規約違反のコードを検出する方法 - 達人プログラマーを目指して

    AspectJというと、メソッドなどに処理を織り込むAOPのイメージが強いと思いますが、AJDTというeclipseのプラグインを使うと強力なコード検証ツールとして利用できることは意外と知られていないようです。(AJDTはSpring Tool Suiteには最初から内蔵されています。) 実際、 コントローラークラスのメソッド内でフィールドの設定を行う サービス層を経由せずに直接DAOを呼び出している 日付オブジェクトを直接newしている*1 などの箇所をコンパイル時に検証して、警告やエラーとして検出できます。 たとえば、Spring MVCのコントローラークラスのメソッド内でフィールドの設定を行っている箇所を警告として検出するには以下のようなアスペクトを書くだけです。 package sample.mvc; import org.springframework.stereotype.Co

    AJDTを使って規約違反のコードを検出する方法 - 達人プログラマーを目指して
  • 日本では職業上専門家たるプログラマーという地位が確立されていない?

    ずっと前に読んだことがあるのですが、 金持ち父さんのキャッシュフロー・クワドラント 作者: ロバートキヨサキ,白根美保子出版社/メーカー: 筑摩書房発売日: 2001/06/27メディア: 単行購入: 23人 クリック: 601回この商品を含むブログ (142件) を見るというでキャッシュフロークワドラントという考え方が説明されています。 金持ち父さんのキャッシュフローゲームの目的とは? ~ロバート・キヨサキのゲームの価値を解き明かす~ | 金持ち父さん研究室 http://hibridge.info/2007/27.html その考え方では、4つのクワドラントは E(Employee):従業員 S(Small business, Specialist):自営業者、専門家 B(Business owner):ビジネスオーナー I(Investor):投資家 のように定義されています。世

    日本では職業上専門家たるプログラマーという地位が確立されていない?
    Nagise
    Nagise 2011/02/05
  • やはり、私は今後もSI業界で達人プログラマーを目指したい - 達人プログラマーを目指して

    SI業界(日)のJavaプログラマーにはオブジェクト指向より忍耐力が求められている?に対して、実に多くの方々からコメントやトラックバックをいただきました。中でも、id:higayasuoさんのSI業界からはさっさと抜けだしたほうがいいの記事は、私としては非常にセンセーショナルかつショッキングな内容でした。私の頭の中の時計が2年前の状態で止まっていたというところあるかと思いますが、id:higayasuoさんは大手SIerにいながらSeasar2などのすばらしいフレームワークを開発され、業界でも珍しい私の憧れのプログラマー、理想像に近い仕事をされている方のように考えていたため、余計に衝撃が大きかったのだと思います。 もっといえば、プログラマも良いコードを書いていればいいという時代は終わった。これからは、プログラムをいかに金に変えるかどうかをプログラマが真剣に考える時代です。 新しいビジネス

    やはり、私は今後もSI業界で達人プログラマーを目指したい - 達人プログラマーを目指して
    Nagise
    Nagise 2011/01/14
    現在のSI業界は変わるべきだが、SIという仕事が否定されるものではない。投資家的には爆発的成長が見込めないのはあるかもしれないが、そんなことで逃げるとか言ってたらどの業界にもいられない
  • SI業界(日本)のJavaプログラマーにはオブジェクト指向より忍耐力が求められている? - 達人プログラマーを目指して

    私自身は10年以上も前(JDK1.1の頃)にSJC-Pの認定を取って以来、Javaプログラミング関連の認定試験は受けていないのですが、昨日たまたまネットを検索して、SJC-Pとは別にJavaプログラミング能力認定試験という試験が存在していることを知りました。結構メジャーな認定試験のようですので、現役のJavaプログラマーJavaプログラマーを目指している学生さんで、今後受験に向けて勉強されている方々も多くいらっしゃるのではないかと思います。 試験は難易度に応じて3級から1級までランクが分かれており、2級まではJava言語の知識に関する筆記試験ですが1級の試験では実際のプログラムの修正を行う能力が実技試験として課せられます。試験範囲は以下で公開されています。 Javaプログラミング能力認定試験(試験範囲) 私は(自分で言うのも変ですが)、Javaプログラミングについてはこの道15年近くのキ

    SI業界(日本)のJavaプログラマーにはオブジェクト指向より忍耐力が求められている? - 達人プログラマーを目指して
    Nagise
    Nagise 2011/01/11
    ダメさ加減を理解するためにはそれなりの技能が必要なので、作られたシステムがいいのか悪いのかさえわからないケースが大半なんだよね
  • Java EEや.NETはCOBOLやVB6よりも本当に生産性が高いか? - 達人プログラマーを目指して

    プログラミングと設計は来切り離せないものなのではがすごい反響だったのですが、結局この記事で私が言いたかったことは、 Java EEなどの現代的な開発環境はCOBOLなどの古い言語を使った開発とは根的に設計の手法が異なる 多くの現場では未だに古い設計手法を使っているため、オブジェクト指向などの最近の開発環境のメリットが活用できず、低い生産性にとどまっている。 ということに要約できると思います。ただし、どうして、Javaではオブジェクト指向で開発しないといけないのか、どうして昔ながらの伝統的なやり方を改め、新しい設計手法を採り入れないといけないのかと疑問を持たれた方もいらっしゃるかもしれません。ここでは、開発手法と生産性の問題について、もう少し掘り下げて検討してみたいと思います。 レガシー言語の生産性 最近のCOBOLでは、オブジェクトやスタック変数すら使えますが、ここではCOBOL85の

    Java EEや.NETはCOBOLやVB6よりも本当に生産性が高いか? - 達人プログラマーを目指して
  • 1