Perl ドキュメンテーション 和訳プロジェクトα版（ボランティア募集） - Japan Perl Association運営ブログPerlドキュメントを和訳していくプロジェクトを始めてみました。古くはJapanized Perl Resources ProjectことPerldocJPプロジェクトが存在していますが、いくつかの点を鑑みてJPAでも同様のものを立ち上げて見ることにしました。
naoyaのはてなダイアリー - Hatena-Keyword-0.02
前のエントリのモジュール、とりあえず CPAN に up できる形にしてみました。 http://bloghackers.net/~naoya/lib/perlmodules/Hatena-Keyword-0.02/ http://bloghackers.net/~naoya/lib/perlmodules/Hatena-Keyword-0.02.tar.gz それに合わせていくつか修正も加えてます。 RPC::XML::Client->new の引数の渡し方が間違ってた。 Jcode は $keyword->jcode で取得するように変更した。 POD 書いた。英語がやばげ。 という感じ。まだ CPAN には up してません。懸念事項が幾つか。 retrieve というメソッド名。引数に与えたテキストに含まれるキーワードを取得する、というのでこの名前は適切か。 名前空間。Hatena
だいありー
# # # class AutoLoggedFile < File def self.open *args file = self.new(*args) if block_given? begin r = yield file ensure file.close end r else file end end def initialize repository, path, *args @alf_backbone = check_backbone(repository, path) super(@alf_backbone.open_path, *args) end def close super @alf_backbone.commit end ALFBackbone_Systems = [] def check_backbone repository, path ALFBackbone_
Route 477(2009-06-26)
■ [ruby][prog] リファレンスとドキュメントの話 反応をいただいた。 http://d.hatena.ne.jp/ku-ma-me/20090625/p1 僕は説明書はとりあえず一通り目を通してみる方です(笑)。 が、メソッド単位の解説しかないという状態は、ケータイでいう「ぶ厚い方のマニュアル」しか入ってないようなものであり、 そんなもんをいきなりユーザに読ませるのは間違っていて、つまり我々が必要としているのは「ケータイ買ったときに入ってくるペラペラな方のマニュアル」 なのだな。 最近見た例だとerectorの公式サイトが、 SYNOPSYS SYNOPSIS 「User Guide」 RDoc と3段階揃ってて良かったです。
ダメなマニュアルの特徴 - まめめも
めちゃくちゃ遅い反応ですが、「よく言ってくれた！」という話。 現状のRDocはユーザリファレンスに向いてないと思ってる。 RDoc書いただけで「リファレンスは完璧だお！」とか言ってるやつなんなの - Greenbear Diary (2009-06-04) 以下関係あるようなないような話。わが身は振り返らない方向で。 ダメなマニュアルの特徴 rdoc に限った話ではないですが、以下はダメなマニュアルに共通する特徴だと思います。 クラスやメソッドを ABC 順に並べている メソッドの説明が長い サンプルコードがない こういう文書は読み手を普通のプログラマだと思ってません。 なぜダメか ABC 順だと、どこから読めばいいかわからない。砂漠の真ん中で迷子になったような気分になります。早く使ってみたいのに使えない歯がゆさ。 説明が長いのは、メソッドの名前が適切でない可能性や、無駄に全機能を列挙しよ
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
http://www.typemiss.net/blog/kounoike/20060120-54
Amazon.co.jp: エンジニアのためのJavadoc再入門講座: 現場で使えるAPI仕様書の作り方: 佐藤竜一: 本
