2003-05-27
_ Trusted Computing
と言っても Microsoft のそれではないですが :-)
- Adamantix （TrustedDebian 改め）
- TrustedBSD
TrustedDebisn の名称変更に際して何があったのかは知りません :-)
TrustedBSD はたまたま ring の BSD のとこをふらふらしてたら見つけたのですが、なんだかまだよく分かっていません(^^; てゆーか OpenBSD でいいんじゃないの？とか思うのですが…。何が違うの？
_ 地上波デジタルラジオ
http://www.zdnet.co.jp/news/0305/26/cjad_kodera.html
ノーマークでした。いや完全に。
地上波デジタルは実は期待しています。なぜって衛星なんて天候に左右されやすいものはダメですよ。表日本に住んでる人は知らんでしょーが、裏日本じゃ衛星なんてダメダメです。冬場はノイズ乗りまくり。もっと声高にこういうこと言ってくれる偉い人はおらんのか。
_ こんな Web ページはいやだ@/.-j
http://slashdot.jp/pollBooth.pl?qid=124&aid=-1
基本的なことが抜けているので補足。
- font size="-1" しまくり
- 全部ボールド
は勘弁してほしい。blink や配色ほど目立たないが、だからこそ凶悪な気がする。font size="-1" はどう考えても IE のデフォルトサイズ向けの対処なんだけど、そんなもん「ユーザーの好きにさせろ」っての。
2005-05-27
_ for でぶん回して clamscan
恥ずかしながらファイルサーバ内にマクロウィルスを発見。メールはプロバイダがスキャンしているので、これは基本的にリムーバブルメディアを介して入ってきたんだろうなぁ。
さて、ここから先が問題。ファイルサーバは Mac で動いているので Windows では認識できないファイル名などが散在している。運良く手元の機械は OS X だが、とりあえず今回のマクロウィルスに感染する可能性のある Excel のファイルのリストを作成するにはどうしたらよいか？
とりあえず Information List という Classic アプリに頼ったが、今なら Unix 系のアプリと AppleScript でなんとかなるかもしんない。AppleScript はまったく経験がないので今回は Information List でタイプ、クリエータ情報まで含めてリストを生成し、改行コードを lf に変換して awk でそれらに対して検索を掛け、Excel ファイルだけのフルパスのリストを作成する。*1Classic Mac の世界では拡張子は文化として存在しないのでタイプ、クリエータに対して検索を掛ける必要があるのと、リストがタブ区切りで生成されるのが分かっているので、こういう場合は awk がすごい便利。
そうしてできあがったリストに対して今度はスキャンを掛けるのだが、Information List の吐くリストは Classic 流で、フォルダの区切りに : が使われているので
sed -e 'y/\/:/:\//'
で / と : を入れ替えて clam に食わす。しかしここでリストを
for i in `cat list`; do clamscan $i; done
ってやると「半角スペースを含んだ名前が分割されちゃって正しくスキャンできない」。慌てた私はファイルのリストに対してエスケープを書き加えてみたが、これは間違い。正解は
IFS=$'\n'
とシェル変数を設定し、「改行だけを for 文のパラメータの区切りにする」ことで対処するのが簡単。
ログは -l でログファイル名を指定して吐くよりリダイレクトした方がなんだか望みの形になったのでそうした。
で、問題のファイルを特定したら対処開始だ。ここから先は今回のテーマじゃないので割愛。フルスキャン掛けないと意味ないんじゃねーのってゆー正論も今回は無視。*2
★ OS X で作業するときはファイル名は Unicode なので普段の作業の都合上 EUC に設定している人は注意。
2007-05-27
_ 個人的によくあること
- 見知らぬ人にモノを尋ねられる
- 昔は公園でよく幸せを祈らせてくれと頼まれた
- 外食産業で注文を忘れられる
南禅寺前の交差点で外国の方に道を尋ねられた。えーとワタシも観光客ですが。まぁ看板はすべて読めるけれども。とりあえず「こっちだと思う。たぶん。maybe.」と答えた。ありがとうと言われなかった。珍しい人だな。こっちの答え方がよくなかったかなぁ？
その後、三条河原で MealMUJI とやらに入る。へー、無印はこんなこともやってるのか。いいなぁ。こういうの、田舎には増えないだろうか。MealMUJI のようなスタイルでは注文忘れが発生しようがないので安心だ。いや、増えてほしいのはそういう理由じゃなくて、「たいがいの定食屋は量が多すぎるので減らして安くしてほしいと思っているから」です。
2008-05-27
_ 『インターフェイス指向設計』読了
最初にオススメポイントだけ書いておく。この本には
- テスト容易性の確保
- 複雑性保存の法則への対処
へのヒントが詰まっている。
kakutani.com にアサマシセンターがあるのかと思ったけどなかったので自分ので貼っちゃうよ。献本なのに自分のアサマシ貼ってるなんてふてぇやつだよ、オレ。
読み手に推奨される準備
まずはじめに「本書の読者対象」を挙げておくと、
本書は、ある程度のプログラミング経験と、オブジェクト指向設計の基本的な知識を持つ開発者を対象にしています。オブジェクト指向に深い造詣がある読者でも、インターフェイス指向のアプローチを学ぶことで、これまでにはなかった設計の概念を得ることができるようになるでしょう。また、インターフェイスを理解することは、SOA（サービス指向アーキテクチャ）の設計においても有用です。
と書かれている。
正直に告白すると自分はこれをなめていた。普通に UML もデザインパターンも出てくる。もっとも、この本に出てくる図は十分に簡単だし最低限の説明はなされている。またデザインパターンもインターフェイスに注目してごくわずかしか出てこない。なんだけど、覚悟しておくのとしていないのとでは雲泥の差。早めに覚悟しておこう。UML もデザインパターンも普通に出てくるよ。
あと前提知識としては当然 Java 的な意味での interface（PHP 5 以降にもあるね）、あるいは Ruby で言う Module がどういうものか分かっていないとつらい。それに継承の問題について自覚的であった方がよい。継承がいかに扱いにくいかを普段感じていないと、サンプルのコードだけではいたずらに複雑になっただけに感じられてしまう。丁寧に書かれているんだけど、問題意識がなければたぶん通じないんじゃないかな*1。
内容
I部、特に3章と4章では本書で扱うインターフェイスに関する用語が怒濤の勢いで出てくる。リファレンス的な部分。その前の2章で契約というキーワードでインターフェイスを考えるための材料が整理されている。
またこの中でさりげなくだけど何度もインターフェイスの変換について触れられている。これはのちのち効いてくる。
5章ではポリモーフィズムを継承ではなくインターフェイスを使って実際に組み立てていく。Role を使ってフットボールチームの話をしているうちはよかったんだけど、Java の InputStream に縁のない自分はちょっとこの辺で意識が飛んでしまった。
II部では開発を進める段取りと実際の作成。7章でインターフェイスに注目しながらユースケースを作り、それをテストしようと試みる、IRI カードなどの話。メソッドが明確になったら実際にテストコードが出てくる。8,9,10章は動くものの話。内容的には Web 系が中心でなじみやすい印象。
最後 11 章でインターフェイス指向からパターンをおさらいして終了。
感想
一言で言うと素晴らしくオライリーらしい。歯ごたえたっぷり。悪く言えばもっと内容を噛み砕いてほしかった。噛み砕く手間と分量で値段は上がってしまうだろうけど、この本は例え1000円高くなっても3600円。十分通用するんじゃないかなぁ。オライリーだし。
実際のところ特別難しいわけじゃないと思うんだけど、個人的な好みはもっと図やサンプルを多くしてほしいんだな。自分は言葉だけでは覚えられないタイプで、何かしら頭の中にビジュアルやアニメーションが思い浮かべないとダメなんで、それを用意しておいてくれるととても嬉しい。いやユースケースやシーケンス図や IRI カードは出てくるんだけど、なんかそういうものじゃないんだなぁ。うまい言葉が見つからない。
なんていうか結構いろんな説明がサラッと出てきていて、もったいないなぁと感じる部分がちらほらあった。ここは重点的に説明しようと感じられたのは「継承とインターフェイス」の部分くらいで、あとは「ま、フツーに知ってるよね？」的な印象。Dependency Injection なんか「あるいは Dependency Injection パターンを用いて実装を設定できます。」とか「おいおい、それだけ？」みたいな。実際のコード間のインターフェイスをどう作り上げていくか、すごく大事な部分のような気がするんだけど、その辺はインターフェイスに注目して分析、設計していく過程としてはあまり重視されていないのかしら。それともやはり使えて当然か*2。そういう意味では経験で補いながら、手を動かしながら読む感じ。例えば DOM と SAX の違いってサンプルコードだけで分かるのかな。自分は幸い両方経験があったからすんなり分かったけど、そうでない場合は一つ一つ噛み砕くのにそれなりに時間掛かるんじゃないかな*3。
あと当然なんだけどインターフェイスという言葉がたくさん出てきてその意味が文脈によって変わるので、特に前半の説明の部分でなかなか頭の痛い思いをさせられた。より一般的な常識的な意味でのインターフェイスであったり、ある程度の機能のまとまりを意味していたり、Java用語的な Interface を意味していたりする。その使い方をいくつかに分類して、ここではこういう意味、ここではこういう意味と、例えば type face を変えるなどして明確にできていたらこれはかなり画期的な本になっていたのではないかと思う。
なんだろう、この出だしの滑らかさとは裏腹にいきなり歯ごたえたっぷりな内容に移行する感じ、覚えがある…と思っていたら、読み終える直前に気づいた。
この本、『プレファクタリング』の人が書いてた。
実はわたくしこの『プレファクタリング』、途中で挫折しております*4。いちばんの理由は Java のコードを読むのがたるいというものなんだけど、今回も終盤はその呪いを解くことはできなかった。だいぶ端折ってしまった。疑似コードもあんまり読みやすい気がしなかったけど、これはオレのセンスがないのかなぁ。内容はいいと思うんだ、内容は。
オライリーの本て、なんかそういうとこあるよね。*5
ただ思いっきり自分の言葉で要約すると
- テスト容易性の確保
- 複雑性保存の法則への対処
へのヒントは確実に詰まっていると思う。高凝集、疎結合という言葉が帯にはあるんだけど、自分としては上の二つの言葉の方が断然しっくりくる。この視点で振り返ると、インターフェイスの変換の話がいくつも出てくるのは実はこのためかと気づく。
オススメと言えばオススメ。でもコレ読むとすごくよく分かるよ！新しい発見があるよ！という意味ではなく、これは通過しておくべき、という意味なのかなぁ。さらっと読めば読めちゃうと思うんだけど、さらっと読んじゃダメというか。たぶん自分はこの先何回もこの本を開き直すと思う。API を使ってゴニョゴニョとかするときにもそのインターフェイスの意味、機能、他のインターフェイスへの変換などのヒントになると思うから。
とりあえず今度もう一回『プレファクタリング』に挑戦してみる。今見直したらプレファクタリングにもインターフェイスの話出てくる。あー、今読めばイケるかもな、これ。コード全体を変更に強くする、どちらかというと実装のためには『プレファクタリング』を、分析、設計のためには『インターフェイス指向設計』を読むのがいいみたい。まさに合わせて読みたい。
あとちゃんと『リファクタリング』と『達人プログラマー』も読んだ方がやっぱいいんだよね？ （実はちゃんと読んだことがない。）
直接関係しないんだけど、PHP 5 で interface が入ったじゃないですか。でも名前空間は相変わらずないんですよ。なんか interface の機能はいいんだろうけど、名前争奪戦が激しくなるだけなんじゃないの？という印象を持ちました。やっぱまだロジックは Ruby で書いてテンプレートを PHP で書くのが最強という印象は変わらないなぁ。
*1 もちろんこの本に興味を持つ人は当然問題意識も持ってるんだと思うけど。
*2 というよりインターフェイス指向そのものではないから端折られているのか
*3 これくらいサクっと読めて当たり前ですかそうですか。
*4 予備知識なしに店頭で即買いしてた。これもとてもいい本だと思っている。もしかしたら今度は読めるかもしれない。
*5 例えばコード片の部分の見栄えを少しだけ変えるとか、そういう工夫してくれないじゃん。ああいう細かいところが少しずつこちらの頭を疲れさせていって、最後はなんだか難しい本だった的な印象を残すんだよね。この本は正直、値段と分量をどう受け取るか、結構その人次第な部分が大きい気がする。自分としては実りの多い読書体験だったし、この値段は安いと思うけど、みんなにオススメなのかというと、なんかそれも違うような。自分と同じようなモヤモヤを感じている人には絶対オススメなんだけど、自分より上のレベルの人はこんなこと言われなくてもフツーにできてそうだし、逆に自分より下の人にこの本を読んだことでうまく説明できそうか、あるいはこの本を読ませて成長できそうかと言うとそれもちょっと違うような。
_ かくたに [丁寧な書評ありがとうございます! 献本してよかったw kakutani.comでの対応が遅れていてすみません。]
_ wtnabe [やった！ ほめらりた！]