(いわゆるpush型のパーザを使う場合)
... At 37, Nisan is already balding, and his remaining hair has gone gray. "I can't eat meat because of my diabetes," he said, chomping on a forkful of lettuce and okra. "I'm just an unlucky guy." As Nisan and I talked, Nemutan stared demurely at her pumpkin soup. It was a national holiday, and the restaurant was packed with young families. Several mothers gave Nemutan inquisitive looks, but the majority seemed not to notice her.オーケイ、このインタビューは真実であるだろうし、 こいつはたしかに不幸な奴かもしれない。しかしなぜコイツなんだ?? どう考えても nytimes はわざわざ bizzare なものを探しているとしか思えない。 しかしべつに NYTimes が悪いというつもりはなくて、オレは 「日本人だっておんなじことをやっている」と言いたいのである。 人のふり見てわがふり直せ。ニイサンは37歳にしてすでに禿げており、彼の髪は白くなっていた。 「糖尿病なもんで、肉が食べられないんすよ」 レタスとオクラをほおばりながら彼が言う。 「ぼくは、運が悪いんですよね」 ニイサンと話しているあいだネムタンは、はにかんだように 自分のパンプキン・スープ (訳注: これは何?) を眺めている。 この日は祝日だったので、レストランは家族連れでごった返していた。 何人かの母親がネムタンに好奇の目を示したが、ほとんどの人はこの人形に気づかないようだった。 ...
それはいいとして、なんの話だっけ? そうそう、暑いという話だった…。
いやいや、それよりもオレは昨日、競技用水着が認可されたとか拒否されたとかいう話を読んで
思ったことがあったんだ。まず、あんなドーでもいいニュウスが新聞の乱し見出しになりうるというのが
狂ってるのだけど、しょせん日本の新聞はぜんぶスポーツ新聞みたいなもんだから
別にかまわない (赤旗と聖教新聞を除く)。それよりも、この手の話で興味ぶかいのは
「どこに線をひくか?」とゆう問題である。つまり
(ガス切れ。あとで書く)
p.s.
ついでに。温度もバカだ。
こんにゃろ</samll>
実際にはこれはムリだな (部屋に一人いるときにしか使えないし)。 しかし、人がまばたきしてる時というのは、その人にとって「視覚が失われている」時なわけだ。 これを応用する方法はほかにもいくつかあるような気がする。
今度のはすごいね! なんたって、ウラに「臓器提供の意志表示欄」がある。
そしてそして、とくにこの中でも注目したい部分は
「○ その他 ( ) 」
という部分だる。
ここはあらゆる類の冗談 (all sorts of jokes) の対象になるだろう。
ちなみにオレは「食用に的する」と書こうかどうか迷ったが、やめておいた。
なぜならそれだけの文字数が入るスペースがないので。
and that's the way it is.
しかし、アルジャジーラのこの手の報道を見ると、新山はいつもきまって
「(ポカーん)」
「一体オレは、このニッポン国で、ナニをやっているんだ??」
「(ポカーん)」
…という気分になってしまう。しかし、こんなことに感情移入している場合ではない。
自分には自分の遂行すべきアジェンダがあるのだ… (ような、気がする)。
それにしても。
統計というのは、ある意味、世の中の見たくない部分を手短かに見るための方便だる。
きのうは夕方ごろは涼しかったのに夜中になってからまた温度が上がり、 そのことでアッタマに来てたらムカついてますます眠れなくなってしまった。
比べるとすんごい似てるよね。まずビッグバンドの演奏からはじまり、 バンドリーダーとホストとの掛け合いがあって、毎回ゲストを呼んで喋る。 ジョークのあとで必ず「お囃子」が入るところとか、 最初の節回しを間延びさせるところまでそっくりだ。 雰囲気的には日本の「笑っていいとも」と似ているが、これが夜のゴールデン枠で、 しかも30年間続いていたというのが怪物的。Lettermanももう20年近く続いてるらしいが、 はげ頭のポール・シェイファーとのかけ合いがいい味だしてるよな。 それにしても、新山は Carson の喋り口がかなり好きである。 こういう番組が生で見られなかったのはとても残念なことだ。 それにしても、いまの日本でこういう番組ってあるのかね? ニュースを除けば、いまの日本ではオトナがテレビを見る理由は何もないように思える。
てくるで、例の発表が Linux界隈でかなり評判悪い受けとられ方をしていることに驚く。 もはや誰もアノ会社を善人とは思っていないらしいよ? アノ会社が自家製のOSを出すんではないか、 という噂はずっと前からいわれていたが、この話は誰もが注目する「切り札ネタ」のはずである。 それをこの時期に使っちゃうというのは、つまりあの会社はもうそれほどネタが尽きているということなのか? 個人的な予想では、おそらく今回の発表が Googleにとって大々的に衆目を集める 最後の機会になるだろう。あと残っているのは、究極の音声認識システムを開発して 人々の寝言や、道端で盗聴したささやき声などをテキスト化して、 検索可能にすることぐらいしかない。この発想の貧弱さを笑うべし。
どういうことかって? たとえば、以下のような手続きがあるとしよう:
一見、これはお互いに独立した2つのことを実行しているように見える。PowerOnLight() # 明かりをつける UseMicrowave() # 電子レンジを使う
なぜでしょう?# 動かない例 UseMicrowave() # 電子レンジを使う PowerOnLight() # 明かりをつける
答え: じつは電灯をつけるためのスイッチが 電子レンジ用のコンセントと連動していて、先に電灯をつけなければ 電子レンジは使えるようにならないのでした!
こんな問題、ズルい、と思うだろう。
ところが現実のシステムでは、こんなことはしょっちゅうある。
問題は「関数の名前が、その体を正確には表していない」ところにある。
やるべきことをやっていないケースはもちろん悪いが、
「想定された以上のことをやっている関数」というのもまた
同様に悪いのだ。こういう場合、もとの関数 PowerOnMicrowave() は
以下のような名前に変更されるべきだろう:
PowerOnLightAndMicrowaveTap() # 明かりと電子レンジ用タップをつける。 Useicrowave() # 電子レンジを使う
もちろん、関数の名前なんかで判断せずに仕様やコードを きちんと見るべきだ、というのは正論だが、あんたは毎回それをやっているか? もし yes なら、おそらくあなたは非常に仕事がトロいプログラマとして知られているだろう。 たとえ最終的には中身まで見るのだとしても、名前によるフィルタリング (いわゆる“偏見”) は通常かなり重要なのである。
さて、そうすると、なにが重要になるかっつうと、 「名前をつける能力」あるいは「名前となる単語を選別する能力」である。 それも、対象となるモノ・動作の性質をひとことでピッタリ言い表すような単語を選ぶ能力が必要なのであり、 つまりはこれは“語彙力”ってことなのだ。たとえば、似たような動作をするが 使われる状況はまったく違うような関数には、「似たような意味をもつが、 ニュアンスはまったく違う名前」をつけなければならない。なかなかいい例が見つからないが、 たとえば、なにか部分木のパスようなものを表現するオブジェクトを、"path" とか "thread" とか呼ぶと、ほかの意味と間違えて混乱するから "strand" と呼ぶことにするとか、 そういうことだ。ほかにも監督役のオブジェクトを擬人化した名前で、たとえば "chairman" と 呼ぶとか、クリエイティブな工夫が必要になる場面はいくらでもある。 しかし同時に“一貫性”を保たねばならず、あまり用語をつくりすぎるとかえって ワケわかんなくなるのでバランスが必要といえる。
一見すると、こうした能力はプログラミングとは何の関係もないことのようにみえる。
が、じつはものすごく重要だ。国語ができないやつは、決してまともなプログラマになれない、
というのはおそらくこういうことを指しているのだろう。
…ちなみに、悪い例はいくらでもあるが、とくに全世界的に被害が大きい例は
Win32 API だ。CloseWindow が実際にはウィンドウを最小化させるだけで、
実際に閉じるのは DestroyWindow だとか、ShowWindow はあるのに
HideWindow はなくて、かわりに ShowWindow(hwnd, SW_HIDE); を
実行しなければならないとか、まるでギャグの世界だ。
まあ、終了するのにも「はじまり ("スタート")」メニューを開かなきゃいけない OS だから仕方ないか。
...NO!!
てくるで、 openssh 0day説はどうやらハッタリらしい。 (一説によるとどこかの管理者が自分のミスで侵入されたのを openssh のせいにしたとか…) ネットはいいかげんな噂が広まるのが速くて怖いよ。
それにしてむモし暑いね。
さて、最近また画面キャプチャーを youtube かどこかに投稿しようと思って (pygame講座もまだ終わっていないし)、vnc2flvなる新プロジェクトを始めている。 なぜならvnc2swfでFLVに変換するのはどうしようもなく面倒くさいし遅いから…オレは難しいことはキライなんだよ! Linuxのデスクトップを直接 FLVに録画できるのが欲しいんだよ! てなわけで作り始めたのだるが、VNC (RFBプロトコル) の解析を大幅単純化して、 ついでにいままでの制御構造を根本的に変えることにした。 いままで、RFBとかのプロトコルの解析は、なるべくプログラミングが楽なように 「制御を完全にあっち側に渡す方法で」設計していた。どういうことかっていうと、 parser がつねに必要なだけデータを読み、きりのいいところまで進んだら返ってくる、 というやりかたである。いわゆる XML でいうところの "push parsing" である。
てくるで、この「push型」「pull型」という用語は XML 以外でも一般的に使うものなんかね? XMLにかぎらず、一般的なストリーム処理 (おもに文字列処理) のアーキテクチャとして、 push型とpull型の区別というのはかなり重要なんだけど、これまでもこの用語で呼ばれていたのかどうか 自信がない。まあいい。一般にいって、push型の解析というのは以下のようなものである:
### push型のパーザを使う。 # ファイルを開く。 fp = open(filename) # parserにファイルを食わせ、解析結果を取得する。 result = parser(fp) # (この時点で、fpは最後まで到達している)
この方法の利点はとにかく簡単だということである。 パーザを設計するのも簡単だし、使う側のコードも短い。 しかし、この方法は「パーザの制御がきかない」という欠点がある。 いったん、パーザが始まってしまったら、ファイルのどの部分をいつ、どのように読むのかは 完全にパーザまかせになる。そして解析が完了するか、 あるいはエラーが発生するまで、こっちには制御が返ってこない。
この状況を、新山の頭の中でイメージすると、以下のようになる:
…こうしてみると、新山の頭の中ではこの方式は "push型" というよりも むしろ "pull型" といったほうがぴったりくる。なぜなら、ここでは パーザがユーザを「引っぱっちゃって」いるからだ。ともあれ、 この方式の問題点は、データが巨大になってきたり、データをネットワークから取得してきたり、 あるいはより厳密なエラー処理をしたいときに非常にコントロールしにくいことである (不可能ではないが、基本的にスタックの一部を保存しておかねばならないため、 ものすごくキタナいし、バグも出やすい)。 そのため、新山はわりと次の "pull型" (でもオレの頭の中では "push型"と呼ばれている) の 設計を好むことが多い:
### pull型のパーザを使う。 # まず、Parserオブジェクトを作成する。 parser = Parser() # ファイルを開く。 fp = open(filename) # parserにデータを食わせる。 while 1: data = fp.read(BUFSIZ) parser.feed(data) # 解析結果を取得する。 result = parser.finish()
解析結果は途中でイベントとして取得される場合もあるし、 あるいは最後に一気に受けとる場合もある (だからこの区別は必ずしも DOM や SAX といった差異とは関係ない)。
新山の頭の中では、この状況は次のようにイメージされている:
というわけで (? どんなわけだ)、VNCの場合も、ネットワークからの 入力が中途半端な場合、そのあいだクライアントが止まっちゃうよりは 中途半端なりに解析ができたほうがいいので pull型のアーキテクチャにしたわけである。 ブラウザの HTMLエンジンなども、pull型のほうがたぶん一般的だろう (Gecko がどっちかは知らないが)。 しかし、pull型の大きな欠点は、状態管理をぜんぶ自前でやんなければいけなくなるために、 パーザを書くのがかなり大変になるとゆうことだ…。とくにVNCの場合は分岐が多いのである。 VNCは「次のバイトが 0x01 だったら、その次には 32ビット整数がくる、そうでなければ 8ビット整数+その長さだけの文字列がくる」といった感じの文脈依存なプロトコルになっていて、 終端が簡単に決定できない。Twisted を使ったらラクになるんだろうか? …と思ってみてみたが、Twistedもやはり行ベースのプロトコルであれば 簡単に deferred を使えるようだが、VNCのような不均一なものは大変みたいだ。
とはいえ、もう実装は終わったのだけど。
…てくるで (ところで)、似たような議論に「ipv6 に移行するのに日本は今までいくらカネを費やしてきたのか / これから (少なくともマトモに使えるようになるまでに) いくらかかるのか」ってのがある。 おそらくこうしたコストをきちんと見積れる人は、日本にほとんどいないに違いない。 なぜなら、これに関わっているあらゆる人間にほとんど正常とは思えない バイアスが存在してそうだから。
ちなみに 米国 商務省の IPv6移行コスト試算 では、まだ未確定要素が多すぎてよくワカランらしく、非常に曖昧な結論になっている。 ちなみに、中規模程度の企業 (システム管理者が3人いて、スイッチが 150台ほど存在する) の 移行コストは、最終的に2億円以上になるらしい (Appendix A)。米国の企業全体の移行コストは 今後25年間で 250億ドル (≒ 25兆円) と見積られているが、ipv6 によるコスト削減も 100億ドル程度と見積られているから、差引で 150億ドル程度になるんだと。 しかし、これがお役所の見積りであることを忘れてはならない。 つうか、お役所にせよ民間にせよ、いままで IT関係の 見積りが当たったことってあるのかね? かすりでも?
しかし、米国ではこうした資料がネット上で見つかるからいい。 日本ではオレはまだ寡聞にして知らない。ipv6を「国策」で推進しておきながら、 この手のオープンな議論がまったくないってのは、そももそ 日本人にはネットは高すぎるオモチャなんじゃないかと思うのはオレだけか?
godot~[13301]$ cd ~/Site/unixuser.org godot~/Site/unixuser.org[13302]$ sortbytime.py | head 1998/04/26 15:18:58 ./doc/kanjicode/jiseuctab.gif 1998/04/26 15:18:59 ./doc/kanjicode/sjistab.gif 1998/12/14 11:27:14 ./doc/semnet/fig1.obj 1998/12/14 11:35:38 ./doc/semnet/fig2.obj 1998/12/14 11:56:58 ./doc/semnet/fig4.obj 1998/12/14 12:03:55 ./doc/semnet/fig5.obj 1998/12/14 12:41:44 ./doc/semnet/fig6.obj 1998/12/14 13:02:23 ./doc/semnet/fig7.obj 1998/12/14 13:08:17 ./doc/semnet/fig8.obj 1998/12/14 13:16:59 ./doc/semnet/fig10.obj
おお、コレか…。 たしかこれって SuperPaint で描いたんだよな。もちろんフォントは Osaka だ。 いまでは「漢字Talk」という言葉も死語になったんだね… (遠い目)。
なんでこんなドーでもいいニュースに注目してんだか自分でもまったくわからないけど。
Document ID: c54993845317894dc0d2a0924f0c2f6b
Yusuke Shinyama