new T()したいケースへの対処法 - プログラマーの脳みそ
Javaのジェネリクスの話題のひとつにnew T()したいができないので困る、というテーマがある。 先日のセッションではこの対策についても簡単に述べたが今日はそのまとめ。 まず第一に疑うべきは本当にnew T()する必然性があるか？というのが持論だが、ある種のフレームワークではその必然性がある。 O/RマッピングのフレームワークでPOJOにデータを詰めて返したい WebフレームワークでHTTPリクエストをPOJOに詰めてControllerクラスに渡したい （このあたりの議論はJavaのジェネリクスで，T.class や new T() ができず悩んだ話 （型パラメータのインスタンス化に関し、フレームワーク設計からケーススタディ） - 主に言語とシステム開発に関してによくまとまっている） ここで、これらのPOJO(Plain Old Java Object - 端的に言えばデータを格納する
Tracに足りない4つの機能 - プログラマーの脳みそ
ITの地殻変動はどこで起きているのか？: プログラマの思索を読んで思い出したことをまとめておこう。 TracなどのBTS(バグ管理システム)を用いたチケット駆動の開発というスタイルで、アジャイル開発を実践されている方も多いことだろう。 私がTracを使っていて感じた不足をここに挙げておく。 インシデント管理 顧客からの要望などのインシデント票と呼ばれるものと、開発の為のタスク（チケット）は別のものだ。私も当初はこれらを混在してつかっていたのだけど、顧客からの問い合わせや要望といったものと、実際の開発作業の間には大きな溝がある。 例えば「Tracにインシデント管理機能をつけてよ」と言われた段階で「インシデント管理機能を作成」というチケットをあげてはいけない。 XPで言うところの計画ゲームをする際のタスクカードと、TODOであるところのTrac上のチケットは分けた方がいい。アイデアとしては出た
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
