Location via proxy:   [ UP ]  
[Report a bug]   [Manage cookies]                

タグ

ブックマーク / bn.dodgson.org (5)

  • steps to phantasien t(2007-06-01) ChangeLog の作法 つづき

    Subversion の開発者が ChangeLog について面白い記事を書いている. 記事の要旨はこうだ: ChangeLog (Subversion なので commit log) を書くのは面倒だよ, メーリングリストもあることだし書かなきゃダメ? ってよく訊かれる. 書きましょう. バグトラックもあるけど, 書きましょう.これらのツールは補完しあっている. メーリングリストはノイズが多いし, 変更を特定するには情報が足りない. バグトラックはバグの記録がメインだからコードの話を細々書くのは邪魔になる. 変更については ChangeLog に書くのがいい. プログラマは ChangeLog を読む. 記録を検索して, どの関数に何が起きたかを調べるものだ. この類の記録は ChangeLog を読まないとわからない. 逆に ChangeLog を書く時は, それを特定できるように省略

    poppen
    poppen 2007/06/05
    ChangeLog の作法 つづき
  • ChangeLog の作法 steps to phantasien t(2005-10-13)

    ソースコードなどの変更履歴を ChangeLog と呼ぶ. オープンソースのソフトウェアで変更履歴を "ChangeLog" というファイルに書いたのが ChangeLog のおこりだと思う. 最近は Subversion などに登録された変更履歴も change log, あるいは commit log などと呼ぶ. 以下ではそれらを ChangeLog と総称する. 最近わけあってこの ChangeLog をどう書いたものかと考えている. コーディング規約には山ほど資料がある. コメントの書き方もよく議論される. しかし ChangeLog についての読み物は少い. GNU コーディング規約 は数少ないそうした文書である. この説明はよくかけている: ChangeLog は将来のメンテナがバグの原因を探るのに使うものだ. コメントに書くべきものはコメントに書け. 関数名を並べろ...

    poppen
    poppen 2007/06/05
    ChangeLog の作法
  • 最近読んだ本 : Working Effectively With Legacy Code - Backnumbers: Steps to Phantasien

    良いだった. 思わず知り合いに電話してカート投入を強要してしまった. 単体テストに挫ける, コストではないもう一つの要因がある. 技術的な難しさだ. テストには技術が必要だ. "テストで手を抜く" にはそのことを書かなかった. テストをしない言い訳にされるからというのと, このではその難しさに挑戦する. このではまずテストを議論するための枠組みを定義し, それからテストが困難なコードをいかにテストするかを Q&A 形式で示している. まずレガシーコードを "テストされていないコード" と位置づける. ここでいうテストは単体テスト. QA チームによるテストは含まない. それは開発のターンアラウンドを改善しないからだ. 単体テストの定義にもうるさい. 単体テストに 1 ケースの実行が 1/10 秒で終わることを要求している. 件数が増えた時にターンアラウンドが落ち, やがて実行されなく

    poppen
    poppen 2007/01/04
    Working Effectively With Legacy Code読書感想
  • steps to phantasien t(2006-09-01)

    2006-09-01 近況 いまの余暇コードは Makefile のかわりに SCons を使っている. Scons は python 製の make alternative. (概要は Radium Software に記事があった.) "#include" によるヘッダファイルの依存関係を勝手に解決してくれるのがいい. 私は何度やっても Makefile の dep ターゲットをうまく書けない. 泣きたくなる. gcc -MD で作った .dep ファイルが どのタイミングで Makefile に incldue されるのか, 実のところ未だによくわかっていない. 少し前にやった仕事でも, 試行錯誤の末になんとなく動いた Makefile をおそるおそる使っていた. (マニュアルをぱくったんだっけ...でも sed なんて使わなかったような...) 一体何がどの順序で評価されるのかさっ

    poppen
    poppen 2006/09/05
    rake のコードを眺める
  • steps to phantasien t(2006-04-02) - JavaScript の暗黒面を覗く

    2006-04-02 近況 Shibuya.js のイベント に申しこんだ. が, メールアドレスを間違えたらしく登録確認のメールが来ない. 再申しこみをしようとしたら満員御礼. がっくり. JavaScript なんて嫌いだ. 今日は JavaScript の悪口を書こう. "Ajax IN ACTION" を読んで以来 AJAX 界隈を信じきれずにいる. ただ私も他人をとやかく言えるほど JavaScript のことをよく知らない. Bookmarklet を書いたり仕事のデモを作る程度. 文法の知識もいいかげんで, 型なし Java のサブセットのように使っていた. そこで不信感を晴らすべく少し JavaScript を勉強してみることにした. Web アプリケーションで仕事をしている友達に教えを乞うと, 仕様書がいちばんわかりやすいとのこと: "ECMAScript Languag

  • 1