僕は、twitterできわめて少数の人しかフォローしてません。そんな僕のtwitterタイムラインでも、何度も言及されていたのが次のブログエントリー： いっしょに仕事をしたいプログラマ 5つの特徴 - たごもりすメモ 本文は「なるほどね」という感想なんですが、コメント欄に驚くべき発言があります。 まずは本文から紹介すると、「いっしょに仕事をしたいプログラマ 5つの特徴」が挙げられていて、それらの特徴で「欠けているところがあれば、少なくとも自分はその人といっしょに仕事をしたいとは思わないだろう」と。 5つの特徴のひとつに「人のコードにパッチを送る」（適切なパッチを書ける能力）があるのですが、それに対するコメントが： ミッションクリティカルなシステムでは自分が再利用しようとする既存コードにバグがあった場合は、まるっとコピーしたうえで修正したものを使うことが多いです。 「まるっとコピー」って、い

ある程度の経験を積んだ技術者／プログラマであるかどうかを判断したいとき、「リビジョン管理システムを普通に使えるかどうか？」という基準はけっこう有効な気がした。 以下の使い方は、「使ってみれば便利さが分かるから」とか言ってなんら説明をしなかった僕の責任です -- と前置きしますが： proj/2009-10-23/, proj/2009-11-10/ なんてディレクトリが、リビジョン管理下になっている。 同じことだが、foo.c, foo-v2.c, foo-v3.c なんてファイルがある。 リポジトリのワーキングコピーとは別に、“ほんと”のワーキングディレクトリがあり、ほんとのワーキングディレクトリから一端リビジョン管理下ワーキングディレクトリにファイルコピーしてからコミットしている。 複数人参加単一プロジェクトのディレクトリ構成が、proj/tanaka/, proj/suzuki/,

（[追記 date="翌日"]文言を少し改善し、注意を付け足したりしました。[/追記]） HTTPメソッド、URL、動詞（verb）に関して次の記事を書きました。 HTTPメソッドの正統的使い方と現実的対処法 HTTPメソッド、URL、そして標準化された動詞 訂正補足：HTTPメソッド、URL、そして標準化された動詞 問題点がほぼ明らかになり、全体の状況も見えてきたので、総括したいと思います。これで決定版にしたいのですが、実のところ、まだ考えが変わる可能性は否定できません。現時点では、以下に記述する案が最善だと思っていますがね。 内容： 用語の注意 事の発端，事の成り行き URLの意味と用途を分類する リソース種別ごとに動詞を考える さらにリソース種別ごとに動詞を考える GETに乗せるか、POSTに乗せるか インターフェースとしてのリソース種別と動詞 リソースとクラス 用語の注意 HTTP

長男：「おとうさん」 父親：「んぁっ」 長男：「オヤジって呼んでいい？」 父親：「ええー、オヤジ、か？」 長男：「うん、俺の友達でもお父さんのことをオヤジって呼んでる人いるよ」 父親：「まー、いるかもしれないな」 長男：「だから、オヤジでいいでしょ」 父親：「んーー、まーいいか」 長男：「いいのね」 父親：「ああ」 長男：「よー、オヤジ、おい、オヤジィ」 父親：「ちょ、ちょと待て」 長男：「…」 父親：「なんか違うような気もするなー」 長男：「オヤジー」 父親：「いや、だからちょと待てって。やっぱり、この件は考えさせてくれ」

あまり強調されないようですが、Erlangでは、その構文と実行メカニズムとがあいまって、状態遷移のプログラミングがとても容易です。 例題として、正規表現 /aa?b*c/ とマッチする文字列を認識するオートマトンを作ってみましょう。まず、状態遷移図を描き*1、それから遷移表を書きます。図と表のなかで、EOSは End Of String のマーカー、◎は終状態です 遷移表： 0から3までの各状態について、入力ごとの遷移先は次の通り。×はエラーです。 状態 文字a 文字b 文字c EOS その他 0 1 × × × × 1 2 2 3 × × 2 × 2 3 × × 3 × × × ◎ × この表を見ながら、Erlangコードを書きます。以下のような感じ。 accept(N) -> % 引数Nが状態 case N of 0 -> receive $a -> accept(1); _ -> e