付箋は便利なのですが、 下線を引いたり注釈を書いたりした場合に近隣の文章を隠してしまい、 可読性が損なわれる点がよろしくありません。

元文章を隠してしまう付箋

スクリプト言語や Java が隆盛を極めている昨今の風潮からすると、 あまり流行りでは無いのかもしれませんが、 弊社では C 言語による（そこそこの規模の） 開発案件もコンスタントに手掛けています。

そういった案件で既存のソース（あるいは利用するライブラリ） の調査を行う場合、 文字列ベース（e.g.: grep 結果）ではなく、 C 言語としての文法解釈を経て得られる情報が必要となることもあります。 例えば、 連結操作（"##"）マクロによるシンボル定義はコード上からは見えない、 といった問題があるためです。

今時は C 言語の字句解析用定義（所謂「lex ソース」） も構文解析用定義（所謂「yacc ソース」ないし「BNF 定義」） も入手可能なのですが、 ではこれだけあれば C 言語のソースを解析可能かというと、 実はそうではありません。

今回は "10. Handling repository events with hooks" を読みます。

Mercurial では、 構成管理におけるイベントの発生を 「フック（hook）」と呼ばれる仕組みで通知することで、 イベント発生そのものを通知する以外にも、 イベント契機となった処理そのものの継続の可否を制御することができます。

CVS のイベント通知の un-documented っぷりで苦労した身としては、 フックの API （起動契機と情報受け渡し方法） がきちんと文書化されているのはありがたい限りです。

ASCADEでは以前から成果物の量を取得して査定のデータに使用したりしています。
基本的に全ての成果物はプロジェクトごとのリポジトリで管理されているので、データの収集もスクリプトを用いて収集します。誰がある期間内にどの程度の成果物を作成したかは基本的には自動でわかるわけです。
ただ、数値を取得すること自体は簡単なのですが、数値の羅列がたくさんあっても、「状況」はわかりにくくて、可視化したいと思いつつ放置していました。