2010-09-22 :-)
_ 朝ッ
0520 起床
_ 仕事
0830 出勤
_ ,
おい、もう定時だぞ!
_ 登山 de カメラ
朝通勤するときにチャリに乗りながら「去年富士登山したとき[ 20090731#p02 ] [ 20090801#p01 ]はコンデジで撮影したので今度 富士登山するときは一眼カメラ持っていくかなあでも重そうだしなあていうかレンズ破壊しそうだし (ノ∀`) 」などと夢想していたら BAT が富士登山に一眼を持っていってた。さすがだ 2010／9／4～9／5 富士登山 - こんな感じで。
持っていった機材はNikon D3s、Nikkor24-70mm f/2.8G、Nikkor16-35mm f/4G VR、三脚(velbon El Carmagne 443II、QHD-61Q)、リモートコード(Nikon MC-36)。
星空の写真が cool すぎる。
三脚を装備すればこれくらい撮影できるかー。むう
_ OpenBSD
Theo de Raadtは「OpenBSDが使ったり配布したりするソフトウェアはあらゆることに対して自由でなくてはならない。...そして、それはどんな目的に対してでも自由であるべきだ...その目的が改変、利用、漏洩、子供の根囲いをする機械やオーストラリアに落とされる核爆弾に対する実装であったとしても」と語った。
「テオ」じゃなくて「シオ」なんだ
_ OpenBSD開発者Theo de Raadt@本家 - スラッシュドット・ジャパン
[...]でも結局、そんな話題について扱った本では、徹頭徹尾、2パラグラフ毎に、同じことをくり返し書く必要があるだろう：
いまコーディングしているインターフェイスを理解しろ！
いまコーディングしているインターフェイスを理解しろ！と。
監査過程は、自分たちのOSの質を向上させようという欲求から生まれた。最初にそれを始めたときは、魅惑的で、楽しくて、そしてかなり狂信的に近いものがあった。約10人がその共同作業に携わって、原則としてお互いに教えあいながら事を進めてきた。「ホール」や「バグ」といったものより、ソース・コードにおけるプログラマの基本的な誤りや杜撰な点を探した。ずぼらな点を見つけるたびにソース・ツリーを繰り返したどるということを、ずっとやっていたのだ。プログラマが犯した誤りを見つけるたびに（たとえばmktemp(3)を使ってファイルシステム競合が起こるような場合）、ソース・ツリーを最初から最後までたどって、それら「すべて」を修正する。そうやって一つ直すと、他にも基本的な誤りを見つけるだろう。そうしたらまた「すべて」を修正する。そう、大変手間のかかる作業だ。でもとてもただならぬ見返りがある。ボーイングの技術者が、発生した配線の不具合を「すべて」は直さなかったらどうなるかなんて想像できる？ 少なくとも、ソフトウェアも同じようにやるように試みましょう。
8) コード監査
ATによる
コードを監査するに当たって、何かアドバイスをいただけませんか。今までバグを見つけてきた経験から有用だったtipsや方法に関して教えていただけるとありがたいです。出来立ての若いコードの場合は、まずどこを探りますか？ 古いコードの場合は？
テオ君：
一番のtipsは、今よりももっと良いプログラマになる、ってことかな。特に、対象のプログラムがどんな関数を使っているのか調べることと、そしてその関数の決まりごとをきっちりと守って使っているか確かめることが重要だ。これを読む人の中の果たして何人が、libcのすべての関数の完全で正しいセマンティクスを知っているんだろう。全部と言わずに、今監査しているプログラムの中で使っているlibcの関数についてだけでも、ちゃんと分かっている人はどれだけいるんだろうね。（どういうことかって言うと、今までソース・ツリー全部を調べてきて、strncat()やstrncpy()の呼び出しのだいたい半分は微妙に間違っていて、一文字余計にコピーしちゃってヌル終端しなくなるだけだとしても、それはやっぱりいい具合じゃないってこと。）
APIを完全に身に付けた時に、簡単にバグを見つけることができるようになるだろう。勤勉さが必要な他の仕事と一緒だと思うよ。注意深くあって欲しい。人は前例から学ぶものなのに、依然としてソフトウェアプログラミングの世界では、その途方もない複雑さが見つけにくいバグを生み、それはさらに新しいコードにコピーされているんだ。関数を間違って定義したマニュアルを見つけたことすらあるんだけれど、その時には多くのプログラマが、間違ったマニュアルに重ねて間違ったプログラムを書いていた…。
熱いでしあ
訳すひとによって口調が変わっている。
_ ,
こういうのは tumblr 使えよっていう
