タグ

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

  • すでに定年を過ぎていますが、Amazonで引き続き達人プログラマーを目指すことになりました。 - 達人プログラマーを目指して

    このたび9月末日をもってオージス総研を退職し、10月よりアマゾンジャパン株式会社に入社しました。今後はSoftware Development Engineerとして、日をはじめ世界各国のAmazonのモバイルWebアプリケーションの開発を担当することになる予定です。 およそ7年間にわたり、前職のオージス総研ではソフトウェアアーキテクトとして、SOAやEAといった全社的なシステムのアーキテクチャから、上流のモデリング、Java EEを使ったアプリケーションの開発など、技術者として様々な経験を積ませていただきました。私自身はこのブログでも何度も取り上げてきたように、モデリングやオブジェクト指向といった技術を用いて、実際の基幹業務システムの設計などに活用することで、高品質で保守性の高いシステムの構築に貢献したいという思いがありました。そのようなシステムを構築、維持するためには高品質なアーキテ

    すでに定年を過ぎていますが、Amazonで引き続き達人プログラマーを目指すことになりました。 - 達人プログラマーを目指して
  • EJBコンテナが分散コンポーネントモデルから軽量なDIコンテナに変化してきた歴史を振り返る - 達人プログラマーを目指して

    十年一昔といいますが、文字通り一昔前の書籍ではJ2EEのEJBコンポーネントはプロセスが分散化されたリモート呼び出しにより処理を行う分散コンポーネントとして説明されています。そして、残念ながら現状Java EE関連の日語の書籍はこうした古い時代に書かれたものがほとんどとなっています。それゆえ、 開発効率がきわめて悪い 実行性能が悪い*1 仕様がきわめて複雑で理解が大変 といった悪いイメージが定着してしまっているのではないかと思います。しかしながら、最新バージョンのJava EE6では、Spring、Guice、SeamなどのOSSの軽量コンテナのアイデアを取り込むことにより、以前とは比較にならないくらい開発効率が改善されているという事実があります。 ここでは、Hello WorldのEJBの書き方を以前の古いバージョンから順次振り返りながら比較してみることで、EJBのプログラミングモデル

    EJBコンテナが分散コンポーネントモデルから軽量なDIコンテナに変化してきた歴史を振り返る - 達人プログラマーを目指して
    t_yano
    t_yano 2011/05/29
    EJBの歴史まとめ。歴史自体は知らない人は知らなくてもいいが、いまから知る人が知るべきは、今後はCDIだってことだな。ギャビンGJってことか。
  • SpringのTypeDescriptorを使うと型パラメーターを簡単に取得できる - 達人プログラマーを目指して

    以前に、Java5の型システムを理解するにはリフレクションAPIを使ってみるのが最短の近道になる - 達人プログラマーを目指してで、Java5からリフレクションAPIで総称型を扱うために導入されたTypeインターフェースについて説明しました。復習しておくと、 Classクラスからは型消去された実行時の型情報のみが取得できる Typeインターフェースを使うと、拡張されたリフレクションAPIを使って、フィールドやメソッドなどで宣言されている総称型の情報を得られる ということでした。しかし、そこでの例で示したようにリフレクションAPIを使って総称型の情報を得るのはチェック例外の処理が面倒ですし、また、例外を無視しても、結構回りくどい処理が必要となります。 今のところあまり知られていないようですが、もし、Spring3が利用できるのであれば、TypeDescriptorというクラスを利用すると、こ

    SpringのTypeDescriptorを使うと型パラメーターを簡単に取得できる - 達人プログラマーを目指して
    t_yano
    t_yano 2011/04/29
    総称型の型情報を取得するSpringのTypeDescriptor。あとで調べる。
  • システム系の例外は実行時例外+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でハンドリングするのがベスト - 達人プログラマーを目指して
    t_yano
    t_yano 2011/02/21
    AOPでまとめて処理するのは現実的な対応として良いと思う。APIとしては今呼んでいるものがリモートメソッドであることはプログラマが意識したほうがいい気はしてるけど、結局例外処理は共通化するだろうなあ。
  • 1