# # # 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_
■ [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 順だと、どこから読めばいいかわからない。砂漠の真ん中で迷子になったような気分になります。早く使ってみたいのに使えない歯がゆさ。 説明が長いのは、メソッドの名前が適切でない可能性や、無駄に全機能を列挙しよ
7/7 七夕の日に、オブジェクト倶楽部 2009 夏イベントに登壇させていただきます。 タイトルは、「テスト駆動開発者は三周目で死ぬのか」。講演の概要として、次のようなことを考えています。 テスト駆動開発 (TDD) に入門し、開発をテスト駆動で行うようになり、日々快適でめでたしめでたし、というわけにはいかないのが現実世界の難しいところです。TDDが机上の空論や、恵まれた環境のみで成り立つものといった意見は最近では減ってきましたが、開発の前線で行う TDDには、現実を直視する世界ゆえの難しさがあることも事実です。 過去の自分が書いたテストの無いコード、テスト内容や組み合わせの複雑化に伴いメンテナンスが難しくなっていくテストコード、実装が変わる度にテストを失敗させるモック、もはや仕様を写し取ってはいないテストコード、次第に下がってゆく自分自身の記憶力やテンション、そして現実と直面する故に訪れ
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く