おくむらたんぶら

Jun 25 2009
「日本人には擦り合わせのDNAがもともとある」と言う人がいますが、それは違います。この強みは、長い歴史の中で、みんなで作ってきたものです
+
+

本書は、意味のある Javadoc(ドキュメンテーションコメント)をほとんど見たことがないという現実を何とかしようと思って書きました。確かに、多くの Java のソースコードにはドキュメンテーションコメントが記述されています。しかし、その多くは「メソッド名の日本語訳」「引数名の日本語訳」といったもので、本当に意味があるものではありません。メソッド findCustomers() に「顧客を検索する」というドキュメンテーションコメントがあったところで、それが何だというのでしょう。findCustomers() というメソッドを見れば一目瞭然なのに、なぜわざわざメソッド名の日本語訳をつけるのでしょう。

ドキュメンテーションコメントが必要なのは、ソースを読んだだけでは分からないことを補足するためです。ソースコードを読めばわかることは、わざわざドキュメント化する必要はありません。しかしソースコードを読んだだけでは分からないことは、ドキュメントとして表現するしかないのです。そのようなスタンスで書いたとき、ドキュメンテーションコメントは初めて意味を持ちます。

そうは言っても、いきなり意味のあるドキュメンテーションコメントを書くというのは難しいと思います。そこで、本書ではチェックリスト形式で、「何を書けばよいか」「何を書かなければならないか」を説明することにしました。チェックリストといっても、そんなに細々としたものではありません。メソッド引数に対しては 7 つ、メソッド主説明に対しては 8 つ、クラスに対しては 13 程度です。いきなり全部を意識する必要はありませんので、分かるところ、納得できるところから使って頂ければと思います。

また、読みやすい API 仕様書(javadoc コマンドで生成した HTML ファイル群)を作るための基礎知識についても説明を加えました。javadoc コマンドを使って単純に API 仕様書を生成した場合、引数や返却値の型として「java.lang.String」といったものが登場してしまいます。この程度ならまだ許せるかもしれませんが、「org.springframework.context.ApplicationContext」のような長ったらしい型名が記述されていると、あまりの読み辛さにイライラしませんか? ほんの少し手間をかけるだけで、もっと読みやすい API 仕様書は生成できます。その「ほんの少し」のお手伝いをするのが本書です。

Jun 23 2009
Jun 22 2009
Jun 18 2009
iPhoneでWebブラウジングしたあとは、ページを空にする
iPhone OS 3.0でSafariのメモリ解放が簡単に! - [Z]ZAPAブロ〜グ2.0より。safariはメモリ喰いなので常に心がけよ!
Jun 15 2009
Jun 01 2009
コスト構造を可視化するには、適切に把握できるような仕訳が必要である。科目や費目、適用が捕捉すべきコスト・レベルで設定されていなければならない。ということは、会計の費目構造から改めなければならない。
第4回 TCOは見えていますか?:ITproより。管理会計って、こういう事か。
May 31 2009
May 26 2009
+
May 21 2009
May 17 2009
return nil if (string.size - pos) < 0 # TODO: make more elegant

やってみたら想像以上にエレガントになった。

return nil if (string.size - pos) < 0 # TODO: make more elegant

やってみたら想像以上にエレガントになった。

May 09 2009
Apr 27 2009
単価が10分の1のマシンに変われば“市場規模が10分の1になる”ってことであり、それはすなわち、産業規模が10分の1に、その産業で働く人が(人の数、もしくは、その人の給与が)10分の1になる、ってこと
注目は法人パソコン市場 - Chikirinの日記より。「ネットブックもiPhoneも中身は一緒じゃないか」との違いはここか。
Page 2 of 22 Newer Entries →