Play!の黒魔術を読み解こうとしてみる（未完 - @katzchang.contexts
この記事は、Play! framework Advent Calendar 2011 jp #play_ja : ATNDの11日目の記事です。 さて、軽めに行きましょう！（ということにさせてください… 僕とPlay! とあるWEBサービスの受託開発案件があり、自分を含めてメンバー的にJavaプログラマが多かったので、Javaが必然。で、環境面も含めてモロモロがフルスタックでサポートされてるフレームワークはないかなーということで、Play! Frameworkを使うことになりました。 2ヶ月ばかり携わったあとで私はその仕事を離れることになったのですが、無事サービスは開始されたようです。めでたしめでたし。 初めのPlayの印象は「黒魔術」の印象でしたが、それはControllerとviewの結合部分が黒いくらいだけで、それ以外の部分は案外素直な作りではあるので、学習にかかるコストは恐ろしく低
Javaプログラマが知るべき9のこと - @katzchang.contexts
はじめに ソースコードは設計であり、コードの記述は品質に直結するのは言うまでもない。ちなみに、プログラマにとって特に重要なのは保守性だ。コードは書いた直後から保守対象となるからだ。コードは要求文書の範囲で動けばいいと思っている人がいれば今すぐ、ソースコードをコピペして100klに増えるプラグインがいつの間にかインストールされる呪いをかけてあげよう。幸い、ここを読んでいる人にはそんな人はいないだろうと思うけれども。 ということで、コードの品質を下げる要因、すなわちシステム全体の品質を下げる要因となり、かつ使われやすいアンチパターンを挙げ、対策を検討していくことにする。対象は以下： 出力パラメータ 処理状態返却 意味のある配列 無意味な初期化 多すぎるtry-catch 暗黙の順序 コンパイラ警告の無視 過剰なコメント e.printStackTrace() 出力パラメータ メソッドの引数にオ
ソースコード改造の発注時に気をつけること - @katzchang.contexts
メモメモ。他にあれば、ぜひおしえてください。 ソースコード中の改変コメント（"// add 2011.02.03 katzchang start"等）は不要です。 元のソースコードのコメントアウトは不要です。必要ないコードはそのまま削除してください。 ifなどのブロック（"{ ... }"）の追加や削除の場合、ブロック中のソースコードに改変がないとしても、インデントを適切に増減させてください。 Javadoc コメントを記述する場合、定義と矛盾がないようにしてください。メソッドコメントの @param が特に矛盾しやすいようです。setter/getterのように自明であれば、省略しても結構です。 Javadoc以外で、ブロックコメント("/* ... */")は使わないでください。 SCMで適切に管理されていることが前提です。 追記 あぁ、大事なことを忘れていた。 VSSで管理しないでく
SI業界人は要チェック！！Subversionでのベンダブランチの運用手順。
外部から納品物に自分たちが手を入れるような場合や、他の人が作ったパッケージ製品を改造して提供するような仕事を管理する場合に使えるパターンです。つまり、SI業界には必須ともいえるパターンなはず。 レポジトリにvendorディレクトリを切っておき、その下でベンダから受領したブツを管理する。納品毎にバージョンtagをつける。そこから枝分かれさせたものを、自分のプロジェクトのサブディレクトリとして管理していく。こうやって管理することで、ベンダからの受領物を自分のプロジェクトにマージするときに、SVN力をいかんなく発揮させることができます。 参考：http://hide.xsv.info/tips/svnmanual/merge3/ 今更な人には今更だろうけど、今更じゃない人には今更じゃないよっていうのがこのセカイですので、もう気にしてません。サンタさん、僕はオトナになったよ…。 レポジトリの構成（
概要設計工程でRedmine導入してみた事例 - T/O
やっぱり事例だよねということで、自分とこの事例をまとめてみる。 お仕事の概要 規模 => 当初の見積もりは900時間。ただし、途中で2割くらい減った。 期間 => 2ヶ月 メンバー => 3~4名。自分込み。 2〜3名が設計書作成、自分はレビュアーとして参加しつつ雑務。 概要設計に先立ち、要件定義は完了。30項目ほど。 滝。 Redmineの設定など 「概要設計」をバージョンとして作成。 30項目の要件をチケットとして登録。 ターゲットバージョン => 「概要設計」 開始日 => 登録したその日 期限日 => 概要設計完了予定日の2w前 予定工数 => それぞれの見積もり値を設定 担当者 => 設定しない ユーザの権限は全て「管理者」。 5名程度なら問題ないんじゃないの？ チケットのフロー 新規 -> 担当 -> 作成済 -> レビュー済 -> 完了 運用方法 タスクの割り振り それぞれが
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
