Test 書いてて思ったんだけど、Duck Typing Friendly な Assertion てどう書くのがいいんだろう？
assert_instance_of は使わないのが基本で、assert と Object#respond_to? とかで適当にごまかしてるんだけど、チェックしたいメソッドの数が多いとめんどい。
MethodSet みたいなんを定義して適当な assertion と組み合わせたりとか考えたけど、それって単なる interface なんじゃ…とか思って、けっきょく結論出ず。
なんか定番のやり方があるのかなぁ。
意識していないとついやりがちなので、自戒のために。
◯報告するとはなにか
○報告するとは何ではないか
自分が言いたいこと、言うべきだと自分が感じていることの八割は要らない内容だ。(たぶん)
それを受け取った場合に聞き手は何を得て、何が可能になるのか自問すること。聞き手に何も変化を起こせないなら、それは単なる自己顕示欲の現れであることを自覚すること。
実践するためには端書きで良いので、一度箇条書きにして取捨選択してから話をするのがいい。そのときに情報を構造化できれば、さらにいい。
トワイライトセピアに一目惚れ。ひさしぶりに物欲が刺激される〜。
IXY DIGITAL 1000 の高感度撮りがかなり良くなってるみたいだから、L4 の高感度も期待できそうだよなぁ。
明日、実機を見てこよう。。
SimpleConsole とても良い。予想外に良い。ので、もうちょっと詳しく紹介エントリを書くつもり。予定は未定。
風呂敷広げると、SimpleConsole から入って、Rails に抜けるというチュートリアルを書きたい。現在主流の Model ありきの（というか、script/generate scaffold から入る）チュートリよりも、その後のアプリの作り方が見えやすい気がする。
社内勉強会も AWDwR の読書会から切替えるかも。（いまいち習熟度が見えないし。）
Ringo's Weblog さんで紹介されていた Tim Berners Lee の提案書が面白い。一読されることをオススメします。素晴らしい文書をご紹介・翻訳して下さっている ringo さんに感謝。
1990年にTim Berners Leeが提出した、最初のWebブラウザ開発の提案文書は、優れたプロジェクト・マネジメントの手本となる文書である。
と書かれているとおり、何かが目を見張るほど卓越した提案書というわけではないが、非常にバランスが取れ、よく練られた内容の提案書になっている。（特殊な技法が使われていてスペシャルな存在になっているとかいう類ではなくて、ベーシックなスキルの積み重ねで全体として高品質な提案書になっている。）
個人的に好きな点は、
この言い回しは、技術文書だとわりと見かけるのだけど、他の界隈ではあまり見ない気がする。たとえば、スコット・アンブラーの「アジャイルモデリング」でも、『アジャイルモデリングとは何であり、何でないか』という項があり、わかりやすかった。ぜひ取り入れたい書き方だ。
# 「見通し」の部分は原文の scope のニュアンスが絶妙で、相手がプログラマであれば、そのままスコープと呼んでしまいたい気がする。「対象（範囲）」だと重たいんだよなぁ。「照準」だといくぶん良いけど、やっぱりスコープの方が良いよなぁ。
