考えたこと・その 1 : SQL についてさらに考。まえに先生が「データベースの世界では、力点は スピードよりもむしろ結果の正当性にある」といっていたのを思い出した。 この観点からすれば、SQL のような宣言型の言語は非常にいい。なぜなら、 手続き型のプログラムでは、ユーザがほんとうにやりたいことは「操作」のなかに埋もれてしまい、 あいまいにしか表現できないからだ。宣言型のほうが明らかに正しいものを正しく書ける (なお、ここでいっている「正しさ」というのは、「正義」という意味ではなくて、 与えられた仮定のもとで「妥当 (valid)」だということだ。しかしこの「妥当」という単語さえも 普段の日本語のニュアンスとは違う。まったくややこしいことよ!)。
たとえば次のような Prolog 風プログラムを考えてみる (これは架空の言語である、 実際には prolog はこんなふうにはかけない)。
これはフィボナッチ数列だが、次の obscure な手続き型言語よりも圧倒的にわかりやすい:f(1, 1). f(2, 1). f(n, f(n-1)+f(n-2)).
def f(n):
a = 0
b = 1
for i in range(n):
c = b + a
a = b
b = c
return c
ただし SQL の不幸は、それがデータベースしか操作できないということである。 それ以外のデータ操作をおこなうプログラムの大半は、全部 Prolog で書くか、それはほぼムリなので、 手続き型言語で書いてそれなりの論理を使った validator (この技術自体がまだ発展途上) で 検証してやらねばならない。で、ほんとに重要なのはそっちのロジックのほうなので (PL/SQL まで宣言型だったら、すごかったんだけど)、結局システム全体のバグを防ぐのにはあまり役立たない。
ふつうにプログラマが使える唯一の宣言的手段 (?) は assert である。
考えたこと・その 2 : 上を書いているうちに忘れた。思いだしたらまた書く。
運命論的に考えれば、こうなる。「それ」は、あなたに発見されるのを ただ待っている。遅かれ早かれ、いずれそれは発見される。
だが別にそう考えたところで何が解決するわけでもなし。
考えてみれば、いまの研究テーマはべつに「自分で発見した」 わけではないんだよな。はやく自分で見つけだせるレベルにならなければ。 いや、すでにそれは kind of 見つけだしているのだが、そこに回帰するチャンスがまだ来ない。 しばらく来なそう。
結局、オレは最終的にどんどん戻っていくような気がする。 いちばん最初に自我が確立したころの決心というのは、以外と長持ちするらしい。 まあ、これまでのところ、寄り道もまた悪くないけど。
といっても新山は工業高校に行ったわけではないのだが、 オレが小学生ぐらいのころは漠然と「将来は工業高校に行きたい」と思っていた。 むかしからキカイ類が好きだったのである。おまけに、そのころ小学生の新山はすでに 悪の道 (=コンピュータ) にはまりこんでいた。 あとどうも「工業」という響きが自分はわりと好きらしい。 うちの実家の近くで「工業高校」と名のつくところというと、一番近いのは 長野工業高校であった。ここはわりと優秀なところである (と聞いた)。 実際には、もっと近い中野実業高校 (通称「ジツコー」) にも 機械科や電気科はあったのだが、そのときはまだそんなこと知らなかった。 しかし、そのうち中学生になり「世の中には工業大学というものがアルらしい」 ということを知った。じゃ、どうせ行くならそっちにすっか、ということで 高校はしかたなく普通科に行った (高専はなんとなく「優等生の行くところ」という雰囲気があったので最初から除外していた)。 しかしその後ぶじに工業大学に進んでも、なんか周囲は負け犬っぽい奴が多いし (なぜか「東大に行きたかったけどダメだったので東工大にしました」とかいうのが多かった、 オレに言わせればそういう連中はみんな負け犬だ)、大学の雰囲気もちっとも 工業工業してなかったのでガッカリしてしまった。 いまだにこれが正しい道だったのかどうか定かではない。 まあ、今さらもうどうでもいいけど。
研究者というよりもつねに practitioner でありたい、とは依然として思っている。 研究者になるには、いまより 30倍ぐらい頭が狂ってないとだめだな。(いろんな意味でだ)
(追記 nov 20) きょう発表したおじさんは Cornell の人だが、見たらきのうの授業 (heuristic problem solving) に 見学に来ていた人だった。そういえばこの授業は珍しいらしく、よく見学にくる人がいる。 こないだもノルウェーかどっかの大学生の団体さんがなぜか見学に来ていた。 というか、日本の大学でもやればいいんだよな、こういう授業。 制御工学科では創造設計とかやってて、NHKが取材にくるほど人気あるんだから (まだやってるのだろうか?)、 情報系でも似たようなことをやればいいんだよ。まあそこまで元気のある先生がいないんだろうけど。
まあいいや。で、きょうの発表は「プライバシーを保ったままデータマイニングする研究」についてだった。 どうでもいいけど、この発表を聞いて思ったのは、今じゃ 「ただ統計をとることをデータマイニングって呼んでないか?」 ってことである。まあ、いまどき「統計をとる」っていうよりも「データマイニングする」っていったほうが カッコいいんだろうよ。それはいいとして、この種の統計をとるにはいつもかならずプライバシーの問題が つきまとう。全体の傾向をつかむには、まず個々人の趣向を知る必要があるからである。 だがいつも匿名調査ですむかというと、そうでもない。 彼が例としてあげていたのが Amazon の「この商品を買った人はこんな商品も買っています」機能だった。 これをさらに拡張して、自分の蔵書をぜんぶ Amazon に登録しておき、 「こんな本を持っている人がこの商品を買っています」ということは技術的には可能だろう。 が、多くの人は自分の持っているすべての本を他人 (この場合は Amazon) に知られるのはいやだ、と思うかもしれない。 このとき、個々人が (原理的に) 特定できないような方法で Amazon が統計をあつめる方法は あるのだろうか? じつはこれは 80年代から研究されている「Randomized query」という手法に関連していて、 ようするにデータベースにある情報を問い合わせたいのだが、自分がどんな情報を欲しているかを 相手に知られたくはないという場合、自分の query のほかに「カムフラージュ用の」ランダムな query をいくつもまぜておき、相手にすべての結果を返させるのだ。 そうすると向こうは結局のところ自分がどの query を発行しているか 完全には断定できないから、プライバシーが保たれる、という寸法。情報の世界におけるプライバシー保護の 武器はたいてい暗号か、乱数のどちらかだな。統計の場合にも、自分の個人情報にわざとランダムなものを まぜて、それでも全体としてみると傾向が現れるようにする方法がある。
ところが、「randomization はかならずしもすべての人のプライバシーを保護するわけではない」 というのがこの研究の第一の発見。たとえば先の蔵書情報を Amazon に申告する例を考えてみると、 かりに「A,B,C という本をもっている人が全体の 1% である」という知識がすでに得られていたとする。 この場合、すべての人が自分の蔵書にランダムに情報をつけ加えたり削除したりして Amazon に送るので、 {A,B,C} をもっている人も {A,C} としか申告しなかったり、逆に {D,E} をもっている人が {B,D,E} だと 申告したりするわけだが、ここで統計を有意なものにするためには、そのランダムな情報も統計に 従っていなければならない。だから A,B または C をもっていない人が、この「ニセの蔵書」を 加える可能性は非常に小さい。これを情報を受けとる側 (Amazon) にからみると、もしある人が 「A,B,C をもっている」と申告したとすると、A,B,C がそもそも非常につけ足される可能性が低いので、 その人は 98% 以上の確率で「本当に A,B,C をもっている」ことがバレてしまう、 というのである。つまり既存の Randomization の技術は「標準的な人々」のプライバシーを保護するには そこそこ役立つが、「マイノリティ」のプライバシーを保護することはできない場合がある。 そして、プライバシー保護というのは「平均的に安全」ではだめで、「最悪のケースで安全」でないと、 プライバシー保護とはいえない…という話だった。これは気づかなかった。 で、かれらはこれを解決するために prior な確率と posterior な確率の比を考え、それをある一定範囲に 抑えるような (この比率は情報を送るユーザ側が調整できる) randomization の手法を開発した。
で、もうひとつの面白い成果が「randomization 情報の圧縮」である。 randomization は余計な情報をたくさんくっつけて送るので、通信量が非常に 大きくなってしまうという欠点がある。で、かれらが発見したクールな方法というのが 「どうせ完璧に定まった情報を送る必要はないんだから、randomization した結果の 乱数列を送るんじゃなくて、もともとの情報が含まれているような乱数列を生成できる 種 (seed) だけを送信すればよい」というもの。あったまいい! ただしこれはクライアント (ユーザ) 側で必要な情報をふくんだ seed を発見する必要があるので、 ある意味、通信コストを計算コストで置き換えているだけともいえる。 そして、これは (上にあげた方法は全体的にそうだが) 二値情報の列にしか使えない。 連続した値域の値 (たとえば年収など) をどうやってプライバシーを保護したまま相手に送るかについては、 依然として未知である…ということだった。
よく見ると、PTB にはまだオレの知らないタグがいっぱいあるんだなあ。 UCP ってなんだ? (NP-)HLN って? NAC とか RRC って何よ?
Guest lecture: Software Development in the Corporate Systems eBusiness
Group at MetLife, on Dec. 1, 5-7 in 101 WWH.
Several people, led by Dave Ditillo, will speak.
The topics will include group programming issues: Group dynamics, team
work, an overview of processes, etc.
Outline:
# Introductions & Agenda Review
# Code Quality: Is it really that simple?
# Importance of Code Quality from the point of view of:
* Business Analyst
* Developer
* Project Manager
* Quality Assurance Team
* Infrastructure Support Team
* Campus Recruiting for MetLife IT
お昼時にマタ fire alarm がなって追いだされて憤怒 (フンヌ)。 しょうがないので BN へいき来年のカレンダーーをみてくるが、 どれもいいのがない。つぎは何にしようかなあ。
本日のすらっしゅとっど: ビル・ゲイツ、スパム受信量は世界一 : 毎日 400万通。
答え: パブロ・ピカソのほうが長い。その証拠。
でもプレゼンがウケたからいいのである。とりあえず今回は新山らしく爆発したプログラムであった。 みんなと逆の方針でやる! という。でも結構まともに動いてたりして。
しかも目ざましもなしで自然に悪夢から目覚めたんだぜ! ちなみにきょうの悪夢はどういうのかというと、 なんか、買ってきた安物のパンに「なんとか茸」という菌類が生えていて それを食うとよくないとか (死にはしないけど、腹の調子が感情の起伏を受けやすくなるらしい)。 それでオレはわけのわからない旅行から歩いて大岡山にたどりつくとそこは なぜか長野の高校で (意味不明)、「コピー用紙は節約しよう」というデカデカ看板が たっていて、高校のクラスのみんなが出迎えてくれるのだがほとんどみんな すでに結婚しており「ハート型の愛妻弁当をつくるような奴は信用できん」という話で 盛り上がっていてオレはカヤの外。なんだったんだあれは。あの人が出てこなくてよかった!
このまえ東欧にいったとき、よく駅の地下街なんかでお花を売ってるおばさんを見た。 こっちでもときどき市場で売っているのはみかけるが、「道端で花を売る」というのが なんかオレはスキらしい。まああんまり裕福な人がやる商売じゃなさそうだが、 オレは貧乏が好きなのよ。
where column = NULL ではだめだが
なぜか where column is NULL ではいいらしい。
そんなん、マニュアルのどこに書いてあんだよチクショウめ!
だいたいなぜ is と = を分けるのか理解に苦しむ。
そういえばオレは Python でも is ってほどんど使ってないなあ。
(追記: SQL では a is 5 などとは書けないらしい。 is のあとにこれるのは NULL だけのようだ。 それならそれで (腐った構文だが) 筋は通っている。)
-----------------------------------------------------
1. UNIGROUP'S NOVEMBER 2004 GENERAL MEETING ANNOUNCEMENT
-----------------------------------------------------
When: THURSDAY, November 18th, 2004 (3rd Thursday)
Where: ** FIELD TRIP MEETING **
Apple Computer
153 East 53rd Street, 29th Floor
Midtown, NYC 10022
** RSVP is MANDATORY **
Time: ** EARLIER START TIME **
6:00 PM - 6:15 PM Welcome and Introductions
6:15 PM - 7:30 PM BSD and MAC OS X Talk
7:45 PM - 8:30 PM Apple Hardware Overview
8:30 PM - 9:00 PM Q & A
----------------------------------------------------
Topic: Apple OS/X Operating System and Comparison to *BSD,
a Technical Talk with Demonstrations.
----------------------------------------------------
Speakers: Patrick Dennard, AE Apple Enterprise,
Leslie Schwartz, AE Apple Enterprise,
Ed Eigerman, Sr. Systems Engineer,
Kevin Boland, Consulting Engineer,
Apple Computer <http://www.apple.com>
ある程度は、そう思う。 でも、そういう大規模データ処理で使われている SQL は、 もう「本来の SQL」ではない、と思う。本来の SQL とは何か? 新山が勝手に想像するに、もともと SQL というのは 「べつに手続き型な考え方にも慣れていないしストレージについても何も知らない 経理のおねえちゃんとかが、お気楽に検索式を手入力できるように」 設計されたものだと考えている。だから理想的な DBMS は、 最適化などまったくされていない O(n^3) なクエリでも 100漫研 (なんて変換だ skk!) のデータから 瞬時に検索してくれるものでなければならない。 新山としては、この目標を批判するつもりはまったくない、それはすばらしいことだ -- もし実現できるのなら。しかし現時点ではそれは不可能なので、 結局のところほとんどの (まともな) プログラマは「手続き的に処理されることを意識した SQL」 を書いているはずだ。それには結局 DBMS の内部構造をある程度把握していないとだめで、 本来の SQL の目的からは外れた使われ方をしている。
まあ、標準化されて普及しているからいまさら変えられないのだろうし、 いまのところこれで用が足りてるらしいからオレとしては別に どうでもいいんだけど、でもどうせ「わかっているプログラマ」が書くのなら、 最初から手続き的に書いたほうが速いはずである。 ただし、本当に「何から何まで」手続き的に書いたほうがいいのか? については自信がない、おそらく (たとえ天才プログラマにとっても) ちょっとは 宣言的なヘルプが必要なのかもしれない。けれども SQL はあきらかに「理想」を 中途半端にひきずった設計になってしまっており、プログラマにとっては 足手まといになっているように思える (これが後知恵にすぎないことはじゅうじゅう承知しております)。 もちろん、エンドユーザが小規模なデータについて使うならまったく問題ないんでしょうけど、 そういう使われ方っていまはマイナーなんじゃないかなあ。
とはいっても、将来的には SQL オプティマイザがめちゃくちゃ賢くなって、 もう DBMS のことなんか何も考えなくてもいいようになるのかもしれない。 まあ、「賢い翻訳エンジン」なんかよりも、こっちのほうが 将来的に実現する可能性がずっと高そうだが…
ちなみに Shasha (新山が受けているデータベースの授業の先生) は その道のチューニング関係で有名なヒトであり、さいきんは AQuery という「時系列データの検索に最適化された拡張 SQL」を 研究している (その学生はいま IBM の DB2 チームにいるそうな)。 これの例をみると、あきらかに時系列データは既存の SQL ではうまく扱えないような気がする (ここは金融街が近いので、このアプリケーションは明確に株価分析を意識している。 聞いた話だと NYSE のデータって全銘柄をあつめると 1日 数GBytes になるらしい)。 もちろん手続き的にデータを配列として扱えば高速に計算できるような場合は 多々あるのだろうけど、先生がいうには「ある程度は宣言的な風味をのこしたい」んだとさ。 たぶん、どっかで (金融分析屋とかから) そういう要望があるんだと思う。 その妥協点がどのようなものなのかは業務の知識のない新山にはわからないけど。 SQL は COBOL のようなものだろう。 COBOL も最初は「本来プログラマじゃない人向け」に開発されたものなのに、 いまやプログラマしか使わなくなって、おまけに普及しちゃったのでいまさら変えるわけにもいかず、 あちこちで足をひっぱってるわけだし。
HTML も似たような運命をたどっているような気がする。 テキトーに設計して、普及しちゃったために (後知恵の人々から) 「なんでこんなヒドい設計にしたんだ!」と ボロクソ言われるという… そしてその反省を生かしてみんな「改良版」を作るのだが、不幸にもそれらは普及せずに消えてゆく。 新山はいまでも手でタグを書いているけど、世の中の多くの HTML はすでに自動生成されたものだろう。 しかし設計者の当初の意図を考えると、彼らを責めるのはおかど違いというものだ。 いまの COBOL/SQL/HTML は彼らの前提を大きくはずれたところで使われているのだから。 一体、こりゃ誰が悪いのか? これは人間の本性にもとづくもので、ある意味「なるべくしてなった」結果なのかもしれない、とも思える。 けっきょく、これもまた「人間は歴史から学習しない」ということの一例にすぎない。 プログラマもまた歴史から学習しないのだ。だけどそもそも本当に「人間は歴史から学習できる」のか。 まだ誰もそんなことができるって証明してないんだけど、だいたいプログラマなんて 20年ぐらいしか「生きて」ないんだぜ、どうやって歴史から学べというんだ!
こういうことって、絶対すでに誰かが 10年ぐらい前にどこかで言ってるんだろうけど、 思わず書いてしまいました。
ところで、つぎに現れる「犠牲言語」は何だろうね?
てくるで、きょうお昼時にいつもの wsq のドサ屋へ行こうと思ったら、 ものすごく混ンでてあきらめた。寒いのにみんなインド料理が大好きらしい。 あのおやじは「冬もやるぜよ」みたいなこと行ってたけど、この調子だと 冬になっても客がいそうだね!
てくるで LWN の新アプリケーションのコーナーを見ていたら ほとんど Python で書かれたやつばっかりで、いーかげんウザくなってきたな、Python も (まあ、こっちの人は、とうの昔からウザいわ、と思ってるかもしれない)。 きょう、データベースの授業のときに TA の xiaojian と話していたら 言語の話になって、かれは K プログラマーなのだが 「なんだ yusuke お前も Python か! オレの周りはみんな Python ばっかじゃないか!」 といわれた。どうやらオレも「烏合の衆」のひとりに数えられてしまったらしい。 新山はもともとマイノリティに向かう人間なのだるが、 いいものは本来マイナーなはずなのになぜだ??
おろそろしいことにもう大学に来てしまったんですねええこの早いのに。 さすがにこの時間はまだ誰もいない。PATH 9st. を降りたらちょうど日が昇ったあたりだった。 Washington Sq. も誰ぁ〜れもいない。掃除のおじさんだけ。 ところで早朝の Broadway は紙くずやら食べ物の包み紙やらが散らかってて ひどくバッチイのですが、いつもこんななんだろうか?
まあ、昨日 3時間ぐらい寝坊したので、埋め合わせに 2時間ぐらい早く来ても 別にいいと思う。ちっとも埋め合っていないけど!
ところで「ヤンキーな」というのは新山にとっては中立的な表現なので、 それは決して「不真面目な」を意味しない。 というかそもそもオレは優等生っぽいのがキライなので、「ヤンキーな」というのはむしろ肯定的な響きをもつ。 ただ決して社会の主流にはなれないような雰囲気だな。 べつにオレは、それでいいと思いますが…
ちなみに新山はときどき人の日記や時事ネタに反応することがあるが、 そのソースをわざわざここに書くようなアホなまねはしない。 (なぜなら、自分がわかればそれでいいから)
てklde、イン演算子ハgeneratorモ引数トシテとルンダネ., as in:
def foo(): yield 1 yield 2 return 2 in foo() → True
IT Consultant ==
IT Constraint
新山は、ミーティングのときにいつもニヤニヤしてるか、ムッツリしてるかの どちらかだが、たいていニヤニヤしてるときは何か (新山にとって) 笑えることが 起きているときであり、ムッツリしているのは考えごとをしているときである。 で、きょうはたぶんニヤニヤとムッツリが交互に起こっていた。 スドウさんの就職が内定した (内定? まあ、内定だろう) お祝いに、 へれんがケーキを持ってきたのだが、それがオレの苦手な中華ケーキ (チャイナタウンのどこかの餅屋で売っているデコレーションケーキ、 いちおう洋風なのだが、色使いがド派手) であった。 ちなみに餅屋とは中国語でパン屋のことである。あー、 これダメなんだよなオレは。なんたってマズイのである。 正直、洋菓子についていえば、チャイナタウンよりもヨーロッパ系の ベーカリーで買ったもののほうがずっとうまいのだが (チャイナタウンでうまいのは 中華料理だけだ、それ以外は期待しちゃいけない)、なぜかへれんが買ってくるのは いつも中華ケーキなのだ。たぶんこっちのほうが安いんだろうなあ。 でも、安くてまずいなら別にわざわざケーキじゃなくてもいーじゃん、 もっと他のもんにしようよ…と思うのは、 オレがケーキのケーキ性たるものをわかっていないという 証拠なのであろうか?? 名より実だろう。
そして、そのケーキの断片は、まだ新山の机の上にある。
> 日本における.STストリートドメインの働きぶりは見事なものです！
そうですか!
> ホームページにリンクやバナーを貼ることによって、数分で立ち上がって走り出せます。
それはすごい! アシモもびっくり!
ちなみにこのページの日本語辞書サーチ機能は秀逸。 だれが「tsuide.st」なんてドメイン取ろうと思うんだ、というツッコミを除いても、 日本語とは思えない単語がいくつか見つかる。「maniwa」とか、「dakora」とか。これ、どっかの方言?
そうか! PTB でテストすればよかったのか! こんなカンタンなことにいままでなぜ気づかなかったん
だ!!!
!!!!
ヨナタン国王のおなり!!
7階の掃除機
オーバーフロー
顔が解けると
手も溶ける
(ほおんとうは冷蔵庫、ほんたぅー-は)
ちなみに件のケーキはまだ机上にある。今日中にたいらげねば天罰がくだる
(もったいないおばke)。
日本は言霊思想があるのでそれは体系的に体系的な天罰がくだる
ぞよ。
(さいきん改行を効率的に使いすぎ、こうりつてきに)
。。。。。食った。やはりマズかった。コーヒーで流し込まなかったらやっていられない。 これをウマイと思って食っているのなら、オレは中国人の味覚も疑い出すぞ。
…ぱちぱち君にやられた。
きょうはなぜか相撲をとらされている夢を見て、 「はっけよ〜い♪ のこった!」で思いきり前へ出ようとしたら その瞬間に目がさめて思わずベッドから落っこちそうになった。だ。
NULL が値として入っている (= 値の入っていない) カラムは、
WHERE column=NULL では取得できない。
WHERE isnull(column) としなければならない。
なんでも手続き的に考えるクセがついてしまっているので、 いちいち where 句に直すのがひどく面倒くさい。 まるで Prolog を書いてるみたいだ。おまけに中でなにがどう最適化されてるか わからないので、下手をするとアホみたいにスピードダウンするから笑える。 「別のテーブルに含まれていないものをすべて削除する」みたいな 処理の場合は WHERE の中でさらに SELECT を使うと尋常じゃなく遅くなりそうなので (index していればいいのか?)、いちいち LEFT JOIN して仮のテーブルをつくってから NULL になったものを消す、というようなことをしなければならない。たぶん。 SQL はデータが少なかったり、素人が簡単な query のみを発行するような場面であれば 便利だったのだろうが、スピードが問題となるような場面ではこういう宣言的な言語は ややこしいだけだな。
しかし新山はいつも「なんでも単純に、明示的にしとけ」と思っている。 この視点からいえば RSS みたいなのはイイのではないか? だが、同時に「なんでもアノテーションする世界はうんざりだ」とも思っている。 これらは矛盾してるのではないか? そうは思わないが、これについてはまたあとで考える。
いつも CNN を見ているが、たしか Ted Turner は結構ひどいこと (「ニュースは売れなきゃダメだ」とかなんとか) をいってたような気がするが、 その引用が web をさがしても見つからない。あれはなんといったっけか…。
ところでおはよう
ところでこんにちは
ところでこんバンワ
てくるで、日本では地区大会は「日本」しかないのに、 米国はニューヨークだけで 1つの地区なんだなあ。 まあ、デカいからそれでいいのか。
…どうでもいいが、国際大会の過去の記録をみると 優勝したのはロシアばっかりだな。
ところでおやみす
(←← てくるで)
unagi.py
を公開痛しました。
日本語の文章はまだです。そのうちの予定
(なめ茸のビンを開けるのにさんざ苦労した朝に記す)
[[といっても、もう朝じゃない]]
追伸: さいきん、神様にはお会いになりましたか? このごろ神様は例の選挙に勝ったチンパン爺がことのほかお気に入りのようでございます。 っていうか、あのチンパンが神の子なのか。だよな。いまや世界を代表する 宗教者は例のバカチン四国にいる例のホウ王ではなく、あのチンパンなのでありますから。
現在の新山のキリスト今日のイメージ == アレ
いや長生きはるすもんだ。
ミルクチャンは英語版でも「milk chan」と呼ばれている。 日本語版では、ミルクチャンが罵声をあびせるときは「ばかっつら!」というらしいが、 英語版では「you dumbass!」という。でもこれってかなりキツイ表現だよね…。 日本語で「ばかっつら」と言われてもとくに腹は立たないが、英語の「dumbass」は、 まともな人なら、絶対「むかっ」とくると思う。 そしてミルクチャンは電話をとったときに「はいこちらショムニです、な〜んつってな〜」 とか言うらしいのだが (日本語では)、英語では「なんつってなー」の部分は「Ju〜st Kidding〜」 になる。でも「ショムニ」とかの部分は変わっていないらしく、じつは英語でも、 さいしょ「シャムニー」と聞こえたので、シャムニーってなんだ? と思ったが、 字幕を見るとちゃんと "this is the Shomuni." と書いてある。 ほかにも、ダスキンのお取り換えがどうとか (途中で Akiko Maitake なるナゾの人物の一人語りが入っている、これまた意味不明)、 新沼謙二のハト軍団がどうとか、 非常にシブいジョークが英訳されているみたいなのだが、こんなの日本人だって 意味不明なのに、アメリカンには到底わからんと思うけど。 まあ「アメリカンジョーク」というのは、ワケがわからなければ なんでもとりあえず笑う、みたいなので、所詮その程度のものでもウケるということか。 でもこれよか ATHF のほうが絶対おもろい。 はっきりいって、ヘンにブラックだったり風刺がきいてる South Park よりも、こっちのほうが 新山は好きである。Super milk chan はわざわざ夜ふかししてまで見る価値はなさそうだが、 これ (ATHF) はわざわざ見る価値がある。いや、新山にとっては。
決定的な違いは、ほかのアニメでは、ストーリーの途中がヘンでも いちおう話としては筋が通っていてオチがある (ワルモンをやっつけるとか) のだが、 ATHF のすごいところは筋書きが完全に論理的破綻してて、 話の流れなんかドーでもよくなっていることである。頭クラクラするね。 ある意味、あの感じはモンパイに似ているといえなくもない。
ある国に何人かの浮気亭主がいた。あるとき、その国の女王様がこう言われた。 「この国には少なくともひとりの浮気亭主がいる。 妻は自分の夫が浮気をしていると確信できたら、その日の夜にすぐさま夫を殺すべし」。 ただし、妻たちは自分の夫が浮気をしているかどうかは知ることができない。 そのかわり、国じゅうのそれ以外の浮気している夫はすべて知っている。 そして昼間のあいだに「昨日の夜は何人殺されたか」を知ることができる。 1日目の夜が過ぎたとき、誰も自分の亭主を殺していなかった。 2日目の夜が過ぎても、誰も殺されなかった。 しかし 13日目の夜に、それなりの数の亭主が一斉に殺された。 このとき殺された浮気亭主の数は全部で何人か? そしてそれはなぜか? なお、国民はすべて女王が嘘をつかないことを知っており、 他の国民がそのこと (女王が嘘をつかない) を知っているということも知っている。なお、これは完全に論理的なパズルで、変てこなトリックはありません。
…オレはおれはまたバカを。
きっとそうだ
そうにちがいね
っていうか、また寝坊した。それはつまりころきあを寝とばしたことを意味する。 死にたい。なんぜ毎週金曜はこうもネボるのか? 実はオレは、ころきはには 行きたくないと思ってんじゃないか? だがそれはちがうね。それはちがう! 夜ふかししすぎて、寝るときには「マア、明日起きれるだろ」と毎回、軽い気持ちで思うのである。 そして実際起きれない。こんちくしょうめ。ぬんだってんだもうこんな奴は死んでしまえばいい。 思うに、寝坊というのは数ある一般的なポカの中でもとりわけダメージがでかいもののひとつである。 なぜなら、ほかの多くの失敗はたいてい復元できるのだが、寝とばしてしまったものは復元できない。 ああでもどうしよう、きょうはマック (= マクドナルドのこと、新山は自分に罰を与えたい気分のとき 我慢してこれを食うことにしている) 食いたくないなあ。だってあれ食うとずっと腹の調子が 悪いんだもん…。正式には腹の調子が悪いというよりは胃腸が汚れた感じがして精神的ダメージ なのである。どうすればいいんだこんなろ。かといって壁に頭を打ちつけたりしてはならないよ! これは一瞬、気分がよくなるが、そのあと甚大な後悔をおよぼす。まあどうでもいい。 今日はやけにくだらんことまで書いてるよなオレ。 まあいつもくだらなくなくないかといえばそういうわけでもなくないのであるけれどもですね、
だめだ、これは読みにくい。
雨がふっていて外へ出たくないなあ。
フレンチフライもちゃんと残さず全部食べること!!
(まあ、それはムリというものだろうが)
あっ。
食パンきらしてた!
オレの最初の ssh マニュアル翻訳をみると 2000年 11月になっている (メールアドレスもまだ @cl.cs.titech.ac.jp だった)。 考えてみたらもう 4年間もメンテしてきたわけだ。われながらよくやってるよ。
まあこの日記も考えてみたらもう 8年ちかくやってんのか。 よくやるのう。
for i in range(10):
\
if (i % 2) == 0:
\
print 'even:', i
\
else:
\
print 'odd: ', i
print 'finished.'
大丈夫じゃない → 大丈夫じゃないじゃない → &んbsp; → 大丈夫じゃないじゃないじゃない。
ですか???
どうでもいいけど
また負けた… ・ ・ ・ 。