タグ

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

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

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

    Spring MVCでコントローラーのリクエストハンドラメソッドのメタ情報を記録する方法 - 達人プログラマーを目指して
    gidooom
    gidooom 2012/10/03
  • ソフトウェア技術者軽視のシステム開発を続けるのはもう限界かもしれない - 達人プログラマーを目指して

    つい先日、富士通がグループで抱える3万人ものSEを再教育して、職務転換を行う計画であるというニュースを知りました。 富士通の3万人SE職務転換大作戦は成功するのか? - GoTheDistance 一つのシステムを複数の企業などが利用するクラウドサービスがこのまま普及すれば、顧客の要望を聞いて個別システムを作り込むSEは仕事がなくなり、余剰人員問題が顕在化するからだ。 クラウドの普及により、オーダーメイドでシステムをゼロから構築する必要がなくなり、そもそも顧客からの要件をまとめてシステムを設計するSEの仕事が不要になったり、基盤を構築、運用するエンジニアが不要になるということは、最近になってよく言われることであり、特に新しいことではありません。もちろん、クラウドの普及によって、これらの伝統的なSEの仕事が少なくなり、人員が余るという議論は間違いではないと思います。 ただし、一方でより質的

    ソフトウェア技術者軽視のシステム開発を続けるのはもう限界かもしれない - 達人プログラマーを目指して
    gidooom
    gidooom 2012/01/27
  • 転職して感じたウォーターフォール文化とアジャイル文化の違いについて - 達人プログラマーを目指して

    今月から新しい会社に転職して、あっという間に半月が過ぎてしまいました。いろいろな会社の規則や、開発環境、フレームワーク、仕事の進め方など、とにかくたくさんのことを短期間で詰め込む必要があり、もともと想定していたことではありますが自分としてはかなりたいへんでした。 やはり、自分としては、外資系の会社で英語でのコミュニケーションが必要となるということが、最も気がかりなことでした。実際、初日の歓迎ランチはいきなり名前もわからない多くの外国人に囲まれる状況でしたし、電話会議を使って中国アメリカのチームと一緒に行う日々の進捗ミーティングも英語で行われています。自分としては、特に、リスニングが苦手ということもあり、いまだに完全に会話についていくのが困難なところはありますが、同僚やマネージャーもみんなすごく親切に教えてくれるので安心しました。私は新しい環境に慣れるのに結構時間がかかる方なので、まだまだ

    転職して感じたウォーターフォール文化とアジャイル文化の違いについて - 達人プログラマーを目指して
    gidooom
    gidooom 2011/10/22
    いろいろ同感
  • 普通のSI会社では評価されにくいのだけど、多くのシステムは研究熱心な技術者の小さな発見と工夫の積み重ねによって支えられているのでは? - 達人プログラマーを目指して

    昨晩遅く、id:backpaper0さんの以下のツイートが目にとまりました。 staticでない物の内部クラスは暗黙で外側のインスタンス(エンクロージングインスタンス)のthisにアクセスできる仕様なので、newを使った普通のインスタンス化の方法では決して外部のインスタンスが存在しない状態でnewできないようになっています。つまり、内部クラスのインスタンス化にはエンクロージングインスタンスの存在が前提となるというのが私が長年Javaのコードを書いてきた中での常識でした。 実際、エンクロージングインスタンスの外側で内部クラスのインスタンスを作成する場合、以下のようにnew演算子の前にエンクロージングインスタンスを書かなくてなならない仕様となっているため、これがnullでは決して内部クラスが生成できないように構文上工夫されています。 public class Outer { private

    普通のSI会社では評価されにくいのだけど、多くのシステムは研究熱心な技術者の小さな発見と工夫の積み重ねによって支えられているのでは? - 達人プログラマーを目指して
    gidooom
    gidooom 2011/04/30
    小さな発見と工夫は大事にする。
  • ドラゴンボールで学ぶオブジェクト指向 改 - 達人プログラマーを目指して

    ドラゴンボールといえば、大変に人気の高い国民的、いや世界的な漫画、アニメですが、昨日匿名ダイアリーでドラゴンボールをネタにしたオブジェクト指向の解説がホッテントリに入っていました。 ドラゴンボールで学ぶオブジェクト指向 多くの人に親しみやすい題材でオブジェクト指向の考え方を解説するというのは非常に興味深い試みなのですが、オブジェクト指向の説明としては不適切なところがあり、ちょっと残念な内容になっています。私自身ドラゴンボールの専門家(ドメインエキスパート)ではないため、不正確なところがあるかもしれませんが、ストーリーを思い出しながら、私なりにドラゴンボールをネタとしたオブジェクト指向の解説にリトライしてみたいと思います。 なお、オブジェクト指向でもプログラミング言語によって表現できる内容が異なるため、当然設計技法は違ってきます。ここではJavaC++、C#、Visual Basicといっ

    ドラゴンボールで学ぶオブジェクト指向 改 - 達人プログラマーを目指して
    gidooom
    gidooom 2011/03/27
    面白くて分かりやすい。
  • 業務系の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とその対策 - 達人プログラマーを目指して
  • 日本では職業上専門家たるプログラマーという地位が確立されていない?

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

    日本では職業上専門家たるプログラマーという地位が確立されていない?
    gidooom
    gidooom 2011/02/11
    人月計算やウォータフォールなどの世界ではプログラマは単純労働者として扱われがちだったかもしれない。専門家としてのプログラマ、マーケティングも分かるプログラマになりたい。
  • Java EEや.NETはCOBOLやVB6よりも本当に生産性が高いか? - 達人プログラマーを目指して

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

    Java EEや.NETはCOBOLやVB6よりも本当に生産性が高いか? - 達人プログラマーを目指して
    gidooom
    gidooom 2010/12/05
    「SIerのフレームワークと比較して、Seasar2、Spring Frameworkなど最近のOSSのフレームワークは、プログラマーの自由を奪わない*7(侵略的でない)ことが特徴とされています。」
  • プログラミングと設計は本来切り離せないものなのでは - 達人プログラマーを目指して

    最近はアーキテクトという役割で客先に常駐し、フレームワークの選定をしたり、事前に共通部品を設計したりする役割を担う仕事を引き受けることが結構あります。そこで運よくお客様のマネージャーがオブジェクト指向開発の経験が十分にある方だと、IDEなどの開発環境やインターネット接続環境を当然のように用意してくれるので最初から仕事がスムーズにできるのですが、そうでないとMS Officeしか入っていないロースペックのノートPCを渡されて、要件定義フェーズの期間中、フレームワークの設計をお願いしますとか、私としてはちょっと首をかしげてしまうような困ったことを言われてしまう場合があります。開発フェーズが始まる半年後まではコーディングは基的に不要という考え方です。アプリケーションのアーキテクトという役割では少なくともコーディング規約を考えたり、ツールやフレームワークの選定をしたりする必要がありますし、プロジ

    プログラミングと設計は本来切り離せないものなのでは - 達人プログラマーを目指して
    gidooom
    gidooom 2010/11/25
    「要件定義フェーズ中に一切プログラミングしないという厳格なウォーターフォールを採用しているプロジェクトでは、この点是非なんとか改善してもらいたいです。」
  • 1