日々の破片
| 著作一覧 |
2005-04-02
_ まとめサイトは作らないけど
3項演算子について、1人だけ嫌いと書いてる人を見たけど、「わからない」とか「わかりにくい」と書いてる人は見かけなかったな。そもそも論では本気でわからない人がもし存在したら何も言わずにif文を死ぬほどたくさんネストさせているという罠。使い方を教えてやってくれ。
とは言え、多重になっている場合についてはわかりにくいというのは僕を含めて2人いたから、規約的にはせいぜい「複雑にネストした3項演算子は使わないようにしましょう」くらいなものでしょう。
っていうか、ある言語を使ってプログラミングの仕事をするって話のときに、文法として存在しているものをわかりにくいとは何のことなんだろう？ とか言うと、Cにはgotoがあるけど使うのか、とか全然関係無い話をしだしたりするんじゃなかろうか。
もちろん、使う。必要ならば。そして、使わせる、必要ならば。
本当にへたくそな人間がgotoを使わないとどういうコードを書くかみたことはあるまい。僕も再現はできないけど、こんな感じになるのだ。
int aflag = 0;
int bflag = 0;
int cflag = 0;
while (condition) {
if (x) {
...
if (xx) {
aflag = 1;
}
}
if (!aflag) {
...
if (xx) {
bflag = 1;
}
..
if (!bflag) {
...
// ネストが深くなりすぎて元に戻していたり
if (!aflag && !bflag && !cflag) {
...
dflag = 1;
}
...//本当は、a0からはじめてz999くらいまである
}
頼むからgotoを使ってくれ。これは読めない。と言うとけげんそうな顔をして、「でもgotoは使うなと教わりましたが何か？」とか。教えるなよ。教えるなら「gotoはif, while, for, do などの制御構造で以降の処理をスキップしたい場合に、制御構造の直下に配置したラベルに対して利用してください」と教えて欲しいものだ（追記：ああ、そうか。これだとbreak使えばすむから確かにちょっと違うな。でも思い出せないやというか思い出したくも無いというか）。何しろへたなんだから、whileの中をうまく構成することもできずに、次々とフラグを立てていって後続の処理をスキップさせていったりするのだ。であれば、とりあえずgotoを使わせてすっきりしたコードを書かせて、そこから少しずつ変えていったほうが効率が良い。
もし、そのプログラマがへたならば、制限させるととてつもなくへたな工夫をすることになる。だったら、制限なんてしないほうが良い。選択の余地がたくさんあると、本当にへたならば、どうしたらよいかわからなくなって聞きに来る可能性がある。その時、考え方を示せば良いだろう。そして、うまくやれる人間ならば、もちろん、余分な制限なんてないほうがうまくやれる。
規約の本質は、見てくれの雰囲気を合わせて、誰が誰のソースを見ても同じように見えるようにすることにあるんじゃないか？ つまり日本語の文書であれば、「である」で統一とか「ですます」で統一とか。でも「非同期」という用語はわかりにくいから使用禁止とか、「推測」という漢語はわかりにくいから「と考えられます」と記述しろ、とか決めないと思うんだが。ある演算子を規約で利用させないってのは、そういう次元の馬鹿馬鹿しい話だ。結局、K&Rで行くか、GNUで行くか（勘弁して欲しいけど）、といった()や{}なんかの位置とインデント幅、そのくらいがあってりゃ十分だ。
_ 今更だが
やっと、ハッカーと画家を読んだ。といっても相当部分はshiroさんのサイトで読んでいたりするわけだが。
で、P.201を読んでいてそりゃそう書くよなと思った(というか、こないだクロージャについて書いてあったのに反応してそう書くと書いてるし)あとに、「これは整数でしか動作しないという点で元のスペックに届いていない」と評されていて、あ、そうかと納得してしまったり。でもそれはなんかいんちきだな（追記：shiroさんのコメントと引用されているURL先を見て、読み直してみたら全然いんちきじゃない。P.198に「数n」という書き方をしているから、整数nに限定されてしまう時点で「元のスペックに届いていない」となるからだ。Javaだとそういう場合はObjectを使うしかないからこんな感じかな。1.5だともう少しすっきりと書けそうだ）。素直に単純ではないと書いたほうが良さそうだ。
2005-04-03
_ すごくおもしろい本を読んでいる
アマチュアの生物学者、ロボット工学者（？）による、人工知能を持つロボットの開発の記録。と要約すると違うような。
しかし、落ち着いて読んでられないので、全然読み進めていない。別の本を読んじゃったり。
これは、不思議だな。まっさきに読みたくてスタックの先頭に置いてあるんだけど、逆にウェイトがかかり過ぎていて下のほうの軽いやつが上に出てきちゃうんだ。たとえば拾い読みできるからハッカーと画家を読んでたり。そのほか、こまごまと。
で、この調子だと一体いつ読めるのか、それとも永遠にスタックのトップにいるくせに追い抜かれていって結局読まないのかわからないな、とここで書いておいてみたり。
何気なく六本木の警察の横の本屋で買ったんだがすごくおもしろい。とはいえ、最初の数章しか読んでないんだけど。
書いてる人間が無茶苦茶なやつだ。まあイギリス人だしな(とつなげると、イギリス人は一般的に無茶苦茶だという意味になるから不思議なものだ。もちろんそんなこたないだろう)。高校時代は生物学に興味を持ったけど何かの気の迷いで小学教師になってみたものの、子供の前で何かを教えるなんてうまくできず、そこでプログラマになったらどうだろうとゲームプログラマになったけど、そこではろくな扱いもしてもらえずうんざりしていたが、ちょっとしたゲームのアイディアを思いついて（クリーチャーズというのだそうだ。ポピュラスとかシムシティみたいな感じなのかな？）それが爆発的なヒット。おかげでゲーム会社の企画部門みたいなところに昇進してマネージャをやらさせられて失敗して馘首になった（ぼやかして書いてあるから良くわかんないけど）まさにその日にゲームで外貨獲得に貢献したから（なんかビートルズとかを想起したり）っていうので女王から勲章をもらって少しは気が晴れて、そこで、家でこつこつと本当の人工知能を持ったロボットを開発することにした、というマッドサイエンティストって世の中に本当にいるんだな、と思わずにはいられないような紆余曲折人生。
で、とりあえず現在はバナナをバナナと認識するオランウータンロボットができたので、さらに次へと進めるための資金稼ぎがこの本だということらしい（が、最初の数章を読んだだけなので以下同文の言い訳）。
アマチュアの生物学者と名乗っているけど、プログラマーだし、電子工作屋だし、なんなんだろう。でも、うさんくさいかと言うとそれはうさんくさいのだが、帯にリチャードドーキンスが絶賛とか、瀬名秀明(解説も書いてるし)の推薦文とか出てるし、なにやら本気らしいし、実際に動くというか認識するロボットがあるみたいだし。
ロボットを作っているというとAIBOなんかと比べられるから説明が難しいと書いているがそれはそうだろう。させたいことをプログラムして、命令してそれをさせるのではなく、したいことをするプログラムをプログラムしてるんだから。抽象度が1段高い。バナナをバナナと認識するっていうのは、AIBOにオーナー登録コマンドで顔と声を覚えさせ、その声や顔を見たら目を緑に光らせるというプログラムとは全然異なることのようだ。
おもしろいなと思ったのはこの人の方法だと視覚情報が重要らしい点だ。おそらく素人工作屋なので1番制御しやすいデバイスがカメラだからかな？ カメラは接続するだけなら非常に単純なデバイスだが入力デバイスとしては圧倒的な情報量を送りこんで来るし、それにプログラムのこちら側へのフィードバックも得やすそうだ。
_ P.201をJavaでやってみる。
これならどうだろう？
import java.math.*;
import junit.framework.*;
public class PG extends TestCase {
public interface Acc {
public Number call(Object i);
public Number call(double i);
}
public static Acc foo(final Object n) {
return new Acc() {
BigDecimal s = new BigDecimal(n.toString());
public Number call(Object i) {
s = s.add(new BigDecimal(i.toString()));
return s;
}
public Number call(double d) {
s = s.add(new BigDecimal(d));
return s;
}
};
}
// 一応試してみたり
public void testInt() {
Acc a = foo(new Integer(16));
assertEquals(17, a.call(1).intValue());
}
public void testLong() {
Acc a = foo(new Long(987654321L));
assertEquals(987654322L, a.call(1).longValue());
}
public void testDouble() {
Acc a = foo(new Double(1234.56));
assertTrue(1235.56 == a.call(1).doubleValue());
}
public static void main(String[] args) {
junit.textui.TestRunner.run(new TestSuite(PG.class));
}
}
ますます見苦しいけど。あと、public static Acc foo(double d);を付け加えれば一応OKかな。
見苦しい原因は、プリミティブ型とObjectを同一に扱えないからだ。と思ったけど、1.5で作ればオートボクシングがあるからそのあたりは問題ないのか。（これは1.4.2で作った）
戻り値にlongVlaue()とかをつけなければならない点はルール違反かも。でもNumber型を返してはいるから、大目に見ることにしようかな。
2005-04-04
_ モエモエ〜
例によって地下鉄の中のことだ。
iPodから適当に音楽が流れてくる。
と、激しい弦楽が流れる。まるでマーラーみたいだな。でも、そんなものは入れた覚えはない。
と、チャカチャカした打楽器とポコポコした打楽器が重ねあって、その上にシロホンみたいなのが重なる。一時のJapanみたいだが、違いそうだ。
と、女声が入ってきた。
「萌え萌え〜」
へ？
インテンポで、上のほうにはシンセサイズされたストリングで、下のほうは打楽器群、ときどきポコポッコッポケ、ポコポッコッポケと入る。
で、
「萌え萌え〜」
あまりのくだらなさに笑いそうになってしまう。
でも、音そのものはきれいなんで、早送ってしまうには惜しすぎる。
でも、
「萌え萌え〜萌え萌え〜」
増えている。
笑いが止まらない。いやだね。
これだな。って言うか、聴けるのか（いや、聴けない。萌え萌えが始まる前で切れてしまう）。
_ rjbを使ってS2を呼んで見たらどうなる？
Java側でメインスレッド以外からしか介入しないように制御すれば呼べるとは思うけど、スクリプト＋xml（による設定）って、あんまり嬉しくないような気もするんだけど。
でも、どんな使い方がうまい方法かなんて、まだわからないわけで、是非ともいろいろ試してください。
2005-04-05
_ rjb
実はドキュメントは、ext/rjb.cは当然として、test/test.rbにあったりして。
たとえば、importしたクラス（メタデータ）のクラス名は次のように参照できる。
def test_metaclass
cls = import('java.lang.Class')
assert_equal('java.lang.Class', cls._classname) #これはrjbのメソッド(_で始まってるのが特徴)
assert_equal('java.lang.Class', cls.getName) #これはJavaのClass#getName
assert_equal(17, cls.getModifiers)
end
インスタンスが属するクラスの名称も同じ_classnameメソッドが利用できる。
def test_scalar
cls = import('java.lang.String') #Stringのクラス(メタデータ)を移入
assert_equal('java.lang.Class', cls._classname) # そりゃそうだ。
assert_equal('class java.lang.String', cls.toString)
str = cls.new #Stringのインスタンスを生成
assert_equal('java.lang.String', str._classname) #インスタンスが属するクラス名も_classnameが利用できる
一応、ほかのやつで試してみた。
require 'rjb'
o = Rjb::import('java.lang.System').out
o.println('jarh')
p o._classname
実行すると
C:\temp>ruby out.rb jarh "java.io.PrintStream"
と、outのクラス名が出力されることが確認できる。
2005-04-06
_ dRuby
coLinuxが動いているといろいろ使えそうだな。とメモ。
_ ServletRequest#setAttribute
Attribute names should follow the same conventions as package names. Names beginning with java.*, javax.*, and com.sun.*, are reserved for use by Sun Microsystems.
うが。次からちゃんとやろう。
というか、HttpSession#setAttributeにはそんなこと書いて無くて、どうやってベンダー依存の属性名を決めるのか不思議だったのだが。
でもServletContext#setAttributeにもちゃんと書いてあるな。
Attribute names should follow the same convention as package names. The Java Servlet API specification reserves names matching java.*, javax.*, and sun.*.
というか、Sunがリザーブしたのか、Servlet API仕様がリザーブしたのかくらい統一して書けばいいような。まあ、ドキュメンテーションはかように難しいものである。
2005-04-07
_ 指紋
そりゃ、冤罪はあるし、疑わしきは叩いたり（長野のほうであったな）、マスコミがすぐに筆誅を（風説ていどで）くだしたりするような国じゃ、何に利用されるかわかったもんじゃないし、たまたまそこに指紋が見つかりました（10000個のうちたまたま読みとり可能だったとか）、とかで容疑者とか言われたりしてはかなわん（で、容疑者＝極悪人と短絡するマスコミと尻馬に乗る人たちとかがすぐに想像できるわけだし）、と考えるだろう。
隠れて生きることが得策に見えるシステムが構築されてるってことだな。
では、これをうーんとオープンなシステムに変えるためには何が必要か？ あるいは、何が不要（＝さっさと切り捨てるべきもの）か？
_ おもしれぇ
バカが来た、最高。
_ ブリコラージュ
次々ととっかえひっかえしていくのではなく、手近な、よく知っている、知り尽くしている、手に馴染んだものを利用して、新たな世界を獲得していくこと。
で、僕は、これを読みながら同じくつまりこれってあれじゃないかと思ったのだった。あれっていうのは、ポールグラハムにとってのLISPだ。
_ 諸悪の根源IUnknown
ちぇ、なひさんに取られた。
2005-04-10
_ 温故知新
おもしろい。UCLAと京大の講義。
（この部分は抜き出しやすいが、
平たく言うと「パンか病気か死かというぎりぎりのところで生きている人々にとっては、百ドルコンピュータよりパンなのではないか」というコメントを投げかけた。面白い質問である。Alanの答えの一つは、例えば病気で死ぬ子供を救うには、一人一年当たり1ドルかけて予防接種を行うと大きな効果がある。原価90ドルのコンピュータを89ドルで作るようにして、89ドルコンピュータプラス予防接種注射キットのようにして販売することもできるはず、というものだった。米百俵みたいな話でもあるな。もう一つ挙げていたのは、過去の大きな進歩と言うのは最初に記念碑的大事業を打ち出し、実際の成果はその後何十年もかけて進むものである、ということである。宇宙計画は「月に人間を送る」という目的のために、サターンロケットのように40階建てビルの大きさの爆発物の端っこに3人の人間をちょっと置いておく、と言うとんでもないやり方で行われた。でも、その後25年間の宇宙研究の進歩は記念碑がなければ進まなかった。100ドルコンピュータもそのような記念碑的事業を目指している、というものであった。もしかしたら失敗するかもしれないが(僕が思うには"15-50"の目的が達成されないかもしれないが、と言うことに近いと思う)、それでも大きな企業を「おどろかす」には十分のはずなので、大きな効果が期待できる、ということである。
2番目のやつとか、とにかく金を作り出して大儲けするんだ、と錬金術師があれこれやって化学が成立した（これ自身、伝説のような気もするんだが）とかみたいだな。）でも全体を通してさらにおもしろく（ってことは示唆的だったり教養的だったりいろいろだ）読めた。
追記：発明は2回ってのとも通じる話だ。グーテンベルクのやつとかも。ただ2回目をどこに見るかというのは相当恣意的（グーテンベルクに関してはこれはどうしようもなく決定的なことなんだろうが）に思える。
2005-04-11
_ 映画見た
といってもコナンだけどな。
今回のは、こないだの飛行機のやつよりは面白かった。すさまじく不自然なアリバイ工作を可能にするためにはこうやってああやってと考えるのか、それとも最初に考えてから工作を考えるのか、ああいうのってどういう手順で導くのかなぁ、と考えたり。ということは、映画としてはそんなにおもしろかないってことか。映画として見てるわけじゃないってことだ。つまり物語の映画が成立してるってことだな。しかしいろいろ伏線を張るって作業は、これもストーリーから導いて後から伏線を張るのか、それとも伏線とそれが使われる状況を同時に発想するのか、いろいろ考えてみる。障害発生シナリオとそれへの防御や対応なんかを導くのと同じようなもんなのかなぁ。
で、星になった少年の前売りを買わされたり（象のぬいぐるみ）。象がいっぱい出てくるっておもしろいな。それにしても妙な動物だなぁ。
リチャードギアの鼻ってすごいな、と思ったり。でも、あの電車からダンス教室を見つけるシーンは映画だった。
_ 作り手と受け手の問題はいつも気になる
作り手側の経験があると、そもそも「テレビに楽しませてもらう」という意識が希薄なのである。
メタなところに目が行くからという可能性がある。例）
バラエティとはそれを知らないとどうなるかという非常識を見せているだけであり、視聴者自身にとって得る物は少ない。
得る物が少ないとわかっているから、楽しませてもらえられない。（この話題はここまで、あとは、選択して見るということに話が移る。でも、選択するためには見なければわからないという罠）
楽譜からレコード（CDでも良いけど)に消費が移動するというのは、19世紀から20世紀にかけて西洋音楽が直面した問題だし、この10年ちょっと前くらいに、プログラミング雑誌が消えて無くなったことと同じことだろうけど。で、代わりにオプソ活用法とかに変わるわけだけど。まあ、問題領域に絞るってことはそれはそれでOKではあるが。
作るな、作るな、作るな、か。はいはい。
でも、おれは作るけどね。どんどん作ればいいんだよ。
2005-04-13
_ SetとList
Setに入ってる要素はインスタンス1つ1つに意味がある。なんかSetという名前と裏腹だ。
いずれにしたって、Set#remove()とか、Set#get()とか、なんかどれでもいいから1個取り出そうったってそうはいかない。Iterator i = set.iterator();i.next();i.remove(); と3つも段階が必要だ。
Listってのは要素の位置に意味があるはずだけど、位置なんて飾りです。
いずれにしたって、List#remove(0)とか、List#get(0)とか、なんかどれでもいいから1個取り出すのは簡単だ。
序列ってのはそういうもんだね。一見すると序列ってとても意味ありげだが、単に抜きやすくするためのインデックスが付いてるだけだってことだ。
でも、わさわさいろいろ入れてあればそう簡単にはいかないはずだ。
でもCollection#clear()があるという罠。
2005-04-14
_ Tiger
そういえばPantherでは1.4.2までしか出てないけど、TigerにはTigerが載ってるんだろうか？ （とクリックした後になって考えてみたり）。
_ UCLA-京大の遠隔講義
あまりに面白かったので、子供にやらせてみた。でも間違えて(元のだと同一の四角を複数使ってく)正三角形と正方形ではじめさせてしまった。当然、正五角形でできるわけないし、正六角形でももちろんできない。今度いろんな四角でやらせてみよう。
あと平方数は見つけられなかった。そんなもんかなぁ。というか、四角形の面積は底辺×高さだくらいは当然知ってるんだから気づけよな、と思ったり。では、なぜ正三角形でも平方数になるのかとか。
_ COM-1994
An interface is not a class
An interface is not a component object
Clients only interact with pointers to interfaces.
Component objects can implement multiple interfaces
Interfaces are strongly typed.
Interfaces are immutable
11年前だよ。
2005-04-15
_ 6:00だ
いつの間にか眠っていたようだ。というか目が覚めたのはもっと早いが。
_ C#
すげ。キーワードはあれだがちゃんと使える形になってんだ（実際に使うかどうかではなく、使いたい時に使えるってことが重要）。
でも、同じ機能がJavaに入ると、規約で使ってはならないとかが公開されそうな予感(だから入らない)。
2005-04-17
_ 昨日の資料
一応、置いておく(PDF変換済み)。
COM―古きを訪ねて新しきを知る(4/18 2:30 Dualのページのタイポ修正)
ご利用はご自由に。
笹田さん、高橋さん(長くなったのでRoRについてのが聴けなかったのがちょっと残念)、お集まりの皆様、久々にCOMの話とかして、おもしろかったです。っていうか、ASRの実装を久々に見たりして。ありがとうございました。
2005-04-18
_ 煙草と珈琲
久々に映画らしい映画を見た。それにしてもすごく混んでる。何が起きたんだろう？
煙は白いが光の白さとは違う種類のゆるやかなうねりを映すからきれいだ。オーティスレディング。thin line between love and hate。というか、ジョニーギターだろう。
・奇妙な出会い
ダウンバイローの撮影中に作ったのかな？ モダンな倉庫風なバー。たくさんのカップ。代わりに歯医者。最後のロングが良い。
・双子
ヘッケルとジャッケル。これも旧作のようだ。光はストレンジャーザンパラダイスの部屋みたい。ロビンミューラーが撮影。ヨタ話を語る男とその反応というのはロングバケーションから延々と続く得意なパターン。YES、YES/NOの合唱のリズム。双子は必ずイーヴィルとグッドに分かれる。実はキングにも兄貴がいた。死んだことになってるがカネがないから養子に出したんだ。ある日兄貴がやってきた。キングは暖かく迎える。兄貴が言う。おれもステージで歌ってみたい。キングは良いことを考える。音楽業界にはちょっと疲れた。代わりにツアーに行かせよう。だが、この兄貴はイーヴィルだった。ラスベガスに白い服を着てぶくぶくに太って出て来たんだ。おもしろくないのか？ YES。キングのこと好きじゃない？ YES。やつは10ドルで無名な黒人の音楽家から曲を買ったんだ。いや、それは兄貴に違いない。イーヴィルが吸ってるのはセブンスター。グッドは手巻きの煙草。ボスから隠してくれと給仕が隠れると体をずらす。
・？
ドラッグストアらしき場所のボックスシート(列車風)。イギーポップ。トムウェイツがやって来て渋滞に巻き込まれて赤ん坊を取り上げるのが大変だの、ボールペンで切開するだのヨタ話。禁煙しているから堂々と煙草を吸えるというトムウェイツの論理、内ポケットからさっと取り出す。ジュークボックスに無いということが転換点になる。イギーいいヤツ。去った後ジュークボックスを確認。
・？
レストランかな。テラスの内側という感じ。煙草に火を着けようとする度に邪魔が入る。昼食が煙草と珈琲じゃ体に悪い。珈琲飲んでるじゃないか？ 高速な夢。子供。手振りだけ。すごい札束。7ドル与える。煙草を手に取る。子供。日本製の豆。4ドル。豆を食って吐き出す。子供逃げる。高級品なんだ。
・ノープロブレム
フランス語で会話。何の用だ？ ノープロブレム。眼鏡を外す。立ち去る。
・いとこ
ホテルのラウンジらしいソファ。最後、女優が去ったとたんに禁煙にする声。
・ルネ
静かで高級なレストラン。間の取り方の見本のようだ。色も温度も丁度良かったのに。ミルクを継ぎ足して色を変える。給仕がいなくなる、出てくる、手でカップを塞ぐ、言い訳していなくなる（昼飯に、昼飯じゃないとか）。の繰り返し。
雑誌の内容が映る瞬間。グロリアって女殺し屋（じゃないけど）からの引用かなぁ。でも、その後で雑誌の内容に気付くし。
・テスラのコイルを説明する
四角目な顔の地味な女。地味な男が熱を込めてテスラの話をする。世界がテスラを認めていたら今頃ネットワークも交通もみんなフリーだったはずだ。オタですか？ 当然のように、女はまったく興味ないようだ。場が白ける。せっかく持ってきたんだからコイルを見せることになる。コイルに電気を入れる。放電。給仕が来てびっくりする。放電。突然止まる。男困る。女しばらく考える。考える。原因を推測する。男、女の推測の正当さを悟る。修理のためにコイルを台車で運んで退場。女、テスラについて考える。
・いとこ？
かまぼこの内側のような空間。紅茶。24アワピープル。フランスの煙草と言いながらシガレットケース。受け取るが吸わない。サイン。紙をあわてて取り上げる。英国と米国じゃ携帯に互換性がない。自宅の電話。プライバシーポリシー。スパイクという言葉に反応。スパイクリー？ スパイクジョーンズ。地球環境を守る会のハイキング。自宅の電話。気を悪くする？ もちろん。立ち去る。くそ。
・ビルマーレー
ドラッグストア風。ボビーデジタルと？。オルターネイティブ医療。怪しいね。これまた紅茶かと思うとビルマーレー。ゴーストバスターズ。ジャグでいきなり呑み始める。煙草も吸いはじめる。これまで出てきたネタ（寝る前にコーヒーを呑むと高速な夢を見るとか）を繰り返す？、その内容を顔で再現するビルマーレー。咳き込む。オキシドールや換気扇用洗剤でのうがいを勧めるボビーデジタル。スタジオへ去ろうとするとうがいの音。
・シャンパン
工事現場か工場の外。2人とも正面を向いて腰掛けている。後ろに影で掃除をする人。実際には同じ側にいるが、影が映るようにガラスの扉か窓がある。第3者が意味なくその場に居るというのはニコラスレイ。マーラー。まずい珈琲。2分間で永遠の眠り。
・クレジット
リスペクト。テスラとかたくさん。1行おいてストラマー。
コーヒー & シガレッツ (初回限定生産スペシャル・パッケージ版) [DVD](ロベルト・ベニーニ)2005-04-19
関数プログラミング (情報数学セミナー)(萩谷 昌己)_ 変態といえば
ソフトウェア考現学―基礎概念への最新おもしろガイド (Fine soft series)(萩谷 昌己)
BASIC FORTRANかて一緒やで。7カラム目ばっかり考えとったら、アルゴリズムもくそもあらへん。
FORTRAN 7カラムをばかにしょったな。もう許せへん。
PL/I まま、おっさんら、ちょうまちいな。
APL せやせや、ここはわしらにまかせんかい。
FORTRAN なんや、このIBMの回し者めが。でかいずうたいしよって。
PL/I でかいずうたいは生まれつきや。すかんおっさんやな。下手に出とったらええ気によって、ほんまに。
APL まあまあまあ、落ちつかんかい。
BASIC 何やこいつ、ええかっこしよって。この変態キャラクタ・セットめ。
APL 何ゆうとんねん。せこい体しくさって。くやしかったら、行列の掛け算1行で書いてみい。
――『ソフトウェア考現学―基礎概念への最新おもしろガイド』萩谷 昌己
あ、構文じゃなくてキャラクタ・セットだったか。
これ読んでしばらくして、IBMと通信するプログラムを書くことになった。で客先でIBMのプログラマと一緒にトライ＆エラーしてたんだが、こっちが半分アセンブラみたいな言語でガシガシ書いてるのに、あっちはなんかちょろちょろっと書いてる（こっちが1時間かけるのに対して向こうは10分くらい）んで、一体何を使ってるのかと思ったらPL/Iだった。確かにでかい図体でなんでもできるんだなぁ、と感心したのを覚えてるんだが、「リトライは100ミリ秒くらいで……」とか言ったら「10秒単位にしてくれ」(だと思ったけど、今となってはそのシステムそのものが存在しないし思い出せないや)とか言われて目が点になったのも覚えていたり。逆にそんなでっかな単位にするのがえらく大変で閉口したものだ。でかい図体だけあって時間間隔が違うのか、確かにゾウの時間、ネズミの時間だなとも思ったり。あれはSNAだったかな？
2005-04-20
_ ミキシン
今更ながら便利だな、と思った。
Javaでこれをやるにはどうしたらいいか。thisを動的に評価するしかないけどそれはちょっとバカくさい感じだ。interfaceを組み合わせればいけるかも。
混ぜたいメソッドを定義したクラスを用意し、その中で参照するメソッドをinterfaceとして抜き出して、includeしたいクラスはそのinterfaceを実装しておく。で、混ぜたいクラスに対してthis（をinterfaceとして）与える。
2005-04-23
_ ツールプログラミング
2〜3日ほど、HTA+ASR+Excelでツールをえんえんと作っていたのだが、最後の最後でHTA終了時にExcelがクラッシュする。
（中途半端にクラッシュするから、OKをクリックだとゾンビ化してしまうので、キャンセルをクリックして、でもデバッガを起動しないで完全に殺す）
これは不思議だな。
ASR（Win32OLEも）は、RubyのオブジェクトとしてCOMのインターフェイスを保持するから、完全には参照カウンターのゼロ化はできない。GCがかかればいけるけど。でも、Excelの場合、これがとてつもなく厄介なことになる。
たとえば、コレクション.レンジ.レンジ.メソッドのような呼び出しが結構出てくるけど、間に入ったレンジオブジェクトをスクリプトからは直接触れない（Win32OLEには参照カウンターをデクリメントするための最終兵器が用意されているから、オブジェクトさえあればどうにかなる）ので、結局GC頼みとなる(Win32OLEというかASRはRubyのオブジェクトを生成しているけど実際には参照をスクリプトが保持していないということまではわからない)。で、HTAがさっさと終了してしまうと参照カウンタが残っているのでプロクシとスタブの両方が生きた状態のままとなっているからまずいはまずいのだろうが、でもなぜ終了した瞬間にExcelがクラッシュするんだろう？
でもツールだし、とりあえず見るのは面倒だからいいや、と気にしないで使ったりしているのだが、でもクリックするのは逆に面倒だし、ゾンビがどかどかたまるのも嫌だ。
でもまじめにデバッグするほうがむしろ面倒だからいいや、とループしたり。2000/2000の組み合わせ固有の問題だといいな、と思ったり。
というか、こういう時は参照カウンターは厄介であるな。JNIのDeleteLocalRefも同じようなことなんだろうか。
_ ワインバーグはただのバーグじゃないみたいだ
スピルバーグもただのバーグじゃないが、さらにすげぇや。イーグル村通信を読んでた頃はあまりわからなかった。でも、ワインバーグが15年間のプログラマ、プログラムの指導とかの果てに書いたこの本を今読むと良くわかる。それもすごく。イーグル村の頃は僕には早すぎたのかも知れない。
というわけで『プログラミングの心理学』の25周年版をつい手にとったのが運の尽きで読みふける。
手にとって最初に目に止まったのは次の1節。
わかりにくいところをはっきりさせる、という仕事をコンピュータ自身に委ねている。
そう言えば、ちゃんと読んだこたなかったな、と気付いて買ってみた。
しかし、厚いので全体をぱらぱら見た後に細かく読んでみたり。
ああ、当時こんなものがあったら、どんなすごいことがやれただろう! ううむ、実は当時やったと同じことをやったんじゃないかなあ。そう、本物のプロなら誰でもやるようなことを。つまり、もっとたくさんの道具を作る、ということを。
でも、第4部を読んで少し悲しくなる。
だが私は、メタ言語をはじめとする各種の道具類を利用してコンパイラを補完する、という話には大いに興味を持っていた。
MDLとかDSLとか。
全体としては、この実験はうまくいかなかった。（中略）すぐれた道具は、劣った言語の寿命を引き伸ばす役しかしないのだ。
劣った言語っていうのはなんだろう？
でも、変わらないことの最たるものは
自分のプログラムを審美的対象として眺めてみる、ということをたまにはしてみないプログラマは、真のプログラマとはいえないだろう。
ということじゃなかろうか。
それが審美的対象であるということは、谷川俊太郎が好みの人もいればサンボリズムが好きな人も、俳句が好きな人も、でもバイロンは嫌いとか、ボードレールは鼻持ちならないとか、好みがいろいろということだ。ところが、プログラムに対してコーディングルール(特にスタイル)というものを設けるという発想は、審美的対象を一方的に押し付ける試みである。そんなのは学校でやればよいことだ。今日は俳句の授業なのでみんな5-7-5で書いてください。5-7-5で書けたかどうかはcheckstyleが判定してくれます。バッカじゃなかろうか。スタイルを強制してどうするよ？
（追記：そうだ。僕は書く人のほうが読む人より常に偉いということを自明の前提としている。だから、Emacsがあの恐るべきGNUスタイルで書いてあっても読むし、K&Rも普通に読むし、MFCのソースがハンガリアン記法を駆使したMS流儀でももちろん読むし、UCCだろうがLCCだろうが_結合だろうが当然のように正しく読める――ただしオブスキュアスタイルは話が別だけど。中原中也も読めれば萩原朔太郎も読める、それだけのことだ。ところがこの重要な価値原則がコペルニクスよりもっと大胆不敵に転倒している人達がいるということは、恐ろしいことだ。）
ここで「育てる」とは、彼らに何らかの「最良」の思考形式を強制することではない。（中略）プログラマにほかの人の思考スタイルに沿って考えることを強制すれば、必ずそのプログラマの問題解決能力を削ぐことになるのだ。だから最大の挑戦は創造的思考にあるのではなく、創造的コミュニケーションある。つまりわれわれの考えを、それぞれ独自のスタイルを持ったほかの人々に理解可能なように表現する、ということが重要なのだ。
ってことは、仮にもプロフェッショナルな仕事をする場が学校なのか？ という疑問さえ湧いてくる。というか、確かに韻も踏めないような連中がプログラムを書いていたりするわけな状況ってのは確かにあるのだが。つまり「真の」ってのが問題だな。教育されていない人間が実際に使われるシステムを作ってたりするってのはなんなんだろう？ (追記：学校というよりはやはり徒弟という感じだな。それはそうで僕もそうだった時期があるわけだし、と思い返してみる。っていうか今でも学ぶことは多いわけだし。むしろ、1番下に合わせるという手法と、教育をきちんと弟子として扱うのではなく取りあえず前線に送っちまえ――軍隊ですら最前線に送る前に教育があるわけだが――という手法の問題だろう)
プログラムの審美的価値と実用的価値に相間があるのは、決して偶然ではない。目や心に快いものは、正しいという可能性が高いのである。
（もちろん、読む側に立ってのことではない。書く側に立っての「審美的価値」のことだ）
BTW、狂った爆撃機に陥る可能性について常に注意を払う必要がある、ということは重要だ。他山の石にしよう。
追記：アプソリュートモン、アブソリュートメント、読みが異なるのは語尾だけではない。
_ 車輪の謎
突然、わかった。「オレが発明した」車輪は2度と発明しない、が正解だ。「オマエが発明した」車輪は「オレがもっとうまく」実装する。
注）これは「心構え」であって、「技能」がより重要なのは自明である。
_ ハック、ハッカー、ハッキング
読ませるね。いったい誰がこんなにわかって書いてるんだろうと思ったらma2さんだった。でも惜しむらくはちょっとタイミングが早かったせいか、big fool man以来の最強ハッカーbitchcheckerが出てこないことだな(もちろん彼についての本は永遠に出ることはないだろうけど、言及くらいは欲しいね。話題性に関しては2005年のナンバー1ハッカーのはずだ。追記：原文を読むと実は――と棒読み――bitchcheckerはすべてをお見通しで帯域の消費をたくらんでいるんだ。なぜならば、最初からbitchcheckerはlolと叫んでいるではないか。lolから右端のlを削除して語が持つ対称性を崩す。そうloだ。それにしてもDSTとhackをgoogleに適用するとその破壊力と浸透力が見える)。
紹介している本に闇のダンテとかケビンの身と肉みたいなソーシャル系の連中が出てこないところもいいな。
悪魔のパスワード (講談社文庫)(脇 英世)ちなみにろくでもない本だが（いろいろ工夫はしているんだけどね）、1985年という早い時期に書かれたということでは脇英世の悪魔のパスワードについても触れて欲しかったかも。妻がなぜかハードカバーで（ということは出版されてせいぜい2年くらいということだ）買って途中で投げたので代わりに読んだのだが、いっぱい脚注を入れて（何となくクリスタルみたいだ）しかもその中にいろいろ言い訳が書いてあって、しかもすべて外していて妙にうら悲しい本であった。
_ 新しきものは古くなり古いものが新しくなる
Unix型プログラマとメインフレーム型プログラマという2分法を考えてみる。
そんなことを最初に思ったのは、中村正三郎がIBMのオフコンのファイルシステムを絶賛したのに対してBSDハッカーから集中砲火を食らったのを目撃したときだ。
僕はその時、BSDハッカー側がどうも中村正三郎の書いた内容を正しく読み取ってないように思った。
とは言ったって（しかしなんて名前のオフコンか忘れたけど）を実際には知らないからそこは想像でしかないんだけど、PL/IかCOBOLかどっちを使うにしろ、そこではプログラマはファイルシステムをまったく意識しないでコードを書くんだろうな、という見当がつくからだ。ネットワークファイルシステムデータベース（以降、全部こいつの間違い。NFSじゃないんだからまったく）を利用してレコードを単にたどっていくだけなのだろうということだ。それは僕が使ったことがあるファイルシステムを強く意識しなければならない環境でのCOBOLのプログラムからの想像なのだが。
もちろん、推測だから間違っている可能性はあるんだけどこんな感じになるんじゃなかろうか。
def Foo : ここにファイルマッピングに関するメタデータかまたはJCL上のメタデータとのリンクが記述される attr_accessor :bar, :baz, :key, :content def Foo.root #単なる宣言 end end a = Foo.root #aはディスクから読まれる a.content = "a" #"a"はディスクに書き込まれる b = a.bar #bはディスクから読まれる b.blabla = 384 #384はディスクに書き込まれる
でも、メモリーマップトファイルの場合、プログラマがマッピングを意識する必要は確実にある。無いライブラリを作るという手段もあるかも知れないけど。ネットワークデータベースみたいにはうまく整理してくれるとも思えない。もちろんファイルシステムを作ればよいのだけど。でもそんなものはいらないだろう。というところからファイルシステムがファイルのスキーマを持つシステムと持ちたくないシステムの差というのが正確かも知れない。(追記：これ、ぶれている。多分実際にはスキーマをプログラムで決めていないと想像できる点は重要なんだけど、そういうことは論点じゃなくて、あくまでもディスク上のファイルシステムと主メモリがシームレスという点が論点だったように思い出してきた。とすれば、中村正三郎が的を外しているんだけど、でもおそらく感じたであろう点ははプログラムではなくストレージが自分を知っているという点だったんじゃないかなと思う。)
その結果、片方は（ファイルシステムがスキーマを持つために）プログラムの中での表現について語れるからそうしているのに、片方はシステムの機能について語っているように見えたということだ。
つまり、stdio.hやio.hが存在しない世界のプログラムをここではメインフレーム型プログラムと呼び、明示的なopen（別にio.hの必要はなくてIO.openでいいんだけど）がある世界をUnix型プログラムと呼んでいるだけのことだ。
多分、メインフレーム型プログラムの世界は死滅したんじゃないかな、と思っていた。もちろんメインフーレムとその文化圏じゃ生きてるだろうけど。
ということと、以前から不思議に思っていた、なんでそんなにO/Rマッピングしたがるんだろう？ 直接SQL書いたほうが効率も良いし、記述も明確だし、まったく理解できないなぁ、多分、ResultSetが常にSQLExceptionとか投げてかったるいし、テーブルスキーマを抽象データ型とみなした場合の型安全性の問題なのかな（ResultSetから取り出す場合は綴りミスがあり得るカラム名指定か、番号ずれがあり得るインデックス指定しかできない）と漠然と思っていたことが、そういう実利的、実装技術的なことではなくメインフレーム方プログラムという思想と同根じゃないかな、と思い当たった。ちなみにインピーダンスミスマッチという言葉を理解しているかどうかはこの場合関係ない。
『プログラミングの心理学』の制約に関するところを読んでいてのことだ。
メインフレーム型プログラムの発想からいけば、自分(ではなく、プログラマということだ)でIOを制御する（たってSQLであって制御してんのはRDBMSなわけだけど）なんて、とんでもない、ってことなのか。だからJDBCを直接使わせないようにするにはどうしたこうしたみたいな話になんのかな。するとOODBMSというのもそっち系統の発想なのかも知れないな。っていうかネットワークファイルシステムと同じように見えるし。
CMPってのも考えてみたら、そういう仕組みだ。配備記述子は（発想としては）開発者が記述するのではなく配備者という名の運用者が記述する。JCLでのユニットアサインやファイルマッピングと同じことだったのか（と思い当たってすごく納得する）。どうりで、嫌われるはずだ、まともな開発者からは。
でも、それほど利用されていないらしき状況から想像すると、多くの開発者はそれでもUnix型プログラムにまだ近い場所にいるのかも知れないのかな、と考えてから、いやそうでもあるまい、きっとUnix型プログラムのリテラシが今現在では意思決定のヘゲモニーを握ってる傾向があるってことなんじゃないかな、とも思う。
しかし、さっさと自動化できるところは自動化しちまうべきだな、と強く思うのだが(そうすりゃ、書き方教室みたいな話は機械にやらせりゃいわけだし)、まだ4半世紀か。言葉の発明から文字の発明まで人類がどれくらい時間をかけたかを想像すると、当分は無理かも知れないな。
2005-04-26
_ 菜の花
そっか、あれは、「いちめんの」か。言われてみればそうですね。いい詩だな。
たくさんのXXXXというフレーズはじゃあなんなんだろう？
たくさんのお月さま(ジェームズ・サーバー)たくさんのとつくと思い出すが（もともと思い出したかったフレーズとは関係ないが）『たくさんのお月さま』は小学生の頃に読んだ本の中でも、表紙が不気味だったので（宇野 亜喜良という人のイラストは非常に気味が悪い。非常に洗練されているのだが、子供にはきつい感じだ。なんか悪意を感じる）印象が強い。
物語は大雑把にしか覚えていないが、こんな感じだ（まったくもって正確ではない）。
お姫様がある日、王様に月が欲しいと言い出す。月が欲しくてたまらなくなり、ついに病気になってしまう。
王様は困る。
家臣Aに、「お前、月を持って来い」という。
A「無理です。だって、あれは空に空いた穴ですから。無を持ってくることはできません」
王様は困る。
家臣Bに、「お前、月を持って来い」という。
B「わかりました。あれはチーズですから、同じようなチーズを作りましょう」
でも、お姫様はそのチーズを見て言う。「それは月ではない」
王様は困る。
家臣Cに、「お前、月を持って来い」という。
C「わかりました。あれは物体Xですから、XでX'を作りましょう」
でも、お姫様はそのX'を見て言う。「それは月ではない」
王様は困る。
と繰り返す。転機はどこにあったのかな？
役立たずの道化師に、「お前、月を持って来い」という。
道化師「わかりました。ところで王様、お気づきですか？」
王「何をかな？」
道化師「月がたくさんあることに。家臣達は、皆、違う月を持ってきたではありませぬか」
王「皆、間違っているのだ。月は夜空に輝くあれ1つであろう。あれは実際にはただの光の渦なのだ。どうして取って来る事ができよう」
道化師「そうではありませぬ。人はそれぞれに月を持っているのです。お姫様の月はいったいなんでしょう？」
王「これはしたり」
王様、お姫様に尋ねる。
「お前、月はいったいなんなんだろうね？」
姫「それは銀でできた親指の爪くらいのペンダントです」
王「なるほど、すぐに月を持ってこよう」
王様は細工師に「お姫様の」月を作らせる。
お姫様、月をもらって病気も治る。
めでたし。
よく考えようインタビューは大事だよ。真の要件は違うところにある、というわかりやすいお話である。
2005-04-27
_ 恋するプログラム Rubyでつくる人工無脳
秋山智俊著 毎日コミュニケーションズ
（追記：修正しました。ご指摘感謝)
献本をいただきました（ASRを使われているからです）。とりあえず2章まで読んで、後はぱらぱら眺めた状態での紹介を。
Ruby入門書としても使えるように書かれているので、最初の2章は駆け足Ruby入門です。ASRのインストールからはじまって、irb、メソッド呼び出し、ブロック、制御構造、ハッシュ、クラスの作成と進みます。文章は読みやすく、うまくまとまっていていい感じです（ここまでで全体の1/5）。
3章以降、徐々に人工無脳プログラミングに入っていきます。
GUIにはVisualuRuby計画（仮称）を利用。形態素解析には茶筅を利用。
「はじめに」で触れられていますが、対象が人工無脳プログラミングなので、実装に必要となる文字列処理、ファイルアクセス、正規表現、などプログラミングの基本となる技術が網羅的に、しかしそれぞれについて要点を絞って書かれています。最後の章ではSOAPを使ってGoogleとインタラクションしています。
印象として対象は中学から大学2年くらいまでかな。自分で先を調べる力があればまったくプログラムの経験がなくても試していくうちに使えるようになるかも知れません。逆にRubyを既に知っていると最初の2章は読み飛ばしても良いかも知れません（僕は、書き方というか説明の仕方に学ぶべき点があったのでちゃんと読みましたが）。全体として、文章量は少なめで例が多く、読み手が自分で先に進むために必要となる手がかりはきちんと抑えてあるという感じです。
優れた書き手である著者の秋山さんがお亡くなりになったのは非常に残念です。慎んでご冥福をお祈りいたします。
2005-04-28
_ 車輪の再発明（おれ、本当にこの言葉のバカっぽさって好きなんだよね）
もしかしたら、こういったことって、海の向こうだから強調する意味があるんじゃないの？
と、専門家における日米の気質の違い（の部分）を読んで思ってみたり。
日米の専門家を比較して思うのは、日本の専門家はおそろしく物知りで、その代わりアウトプットが少ない。もう公知のことだから自分が語るまでもなかろうという自制が働く。米国の専門家はあんまりモノを知らないが、どんどんアウトプットを出してくる。玉石混交だがどんどんボールを投げてくる。そんな対比をすごく感じる。
もし、この梅田氏の言葉を鵜呑みにすればだ、どっかで誰かが既にやってるはずだとかせせこましいことは言わずに、ひたすらモクモクと自分の狭い了見に閉じこもって、とりあえず車輪をばかすか再生産してはがんがん転がしたり放り投げたりしたほうがいいんじゃないの？
その上で（つまり同じ土俵ができたところで）はじめて、悪とか言えばいいじゃん。結局、そういう受け売りの言葉が出る芽を潰すとかと表裏一体になるんだよ。
「モクモクと自分の狭い了見に閉じこもって、とりあえず車輪をばかすか再生産」が実は非常に高い見識と広い度量を持ち、それを受け売りの概念で否定することこそ狭い了見と低い志を持つことなのだ。
2005-04-29
_ 今日のバグ
えらく梃子摺った。
public class FooSet {
List<Param> params = new ArrayList<Param>();
public Param add(Foo f) {
Param p = new Param(f);
params.add(p);
return p;
}
public Param add(Param p) {
Param op = (Param)p.clone();
params.add(op);
return op;
}
public Param findByName(String s) {
for (Param p : params) {
if (s.equals(p.getFoo().getName())) {
return p;
}
}
return null;
}
public class Param implements Cloneable {
Foo foo; // Fooはイミュータブル。
Param(Foo f) {
foo = f;
}
public Object clone() {
return super.clone();
}
public String bar() {
return foo.bar(this);
}
public Foo getFoo() {
return foo;
}
...
}
}
public class Foo {
String name;
public Foo(String initName) {
name = initName;
}
public String getName() {
return name;
}
public String bar(FooSet.Param p) {
....
return barResult;
}
}
というような感じ。FooSet.ParamはFooの入れ物兼Foo用のデータの提供/保持者、Fooはストラテジ。で、たまたま特殊なFooが必要となった。
public FooSet {
public Param {
...
public Param find(String key) { // 追加
return findByName(key);
}
}
}
public class SpecialFoo extends Foo {
public SpecialFoo(String name) {
super(name);
}
public String getData(FooSet.Param p) {
StringBuilder sb = new StringBuilder();
FooSet.Param o = p.find("BAR");
if (o != null) {
sb.append(o.bar(p));
}
sb.append(super.bar(p));
return new String(sb);
}
}
こんなのも作る。
public class FooSetTest extends TestCase {
// 追加
public void specialFooTest() throws Exception {
FooSet f = new FooSet();
f.add(new Foo("BAR"));
f.add(new SpecialFoo("BAZ"));
FooSet.Param p = f.findBy("BAZ");
assertEqulas("BARRRRBAZZZZ", p.getData());
}
}
すべてはうまく行くかのように見える。でも、うまく行かない。
次のように修正。
public class FooSet {
...
public Param add(Param p) {
Param np = new Param(p);
params.add(np);
return np;
}
...
public class Param {
...
Param(Param p) { // 追加
foo = p.foo;
}
// clone()は削除だ。
}
}
_ モンティホール問題
数の悪戯だろうと思ったが、試してみた。
if ARGV.length != 1
puts 'usage: ruby montyhall.rb count'
exit(1)
end
class Gamer
def initialize()
@win = 0
@door = [false, false, false]
@door[rand(3)] = true
end
attr_reader :win
end
class NoMover < Gamer
def play()
@select = rand(3)
@win += 1 if @door[@select]
end
end
class Mover < Gamer
def play()
@selection = rand(3)
open = next_number(@selection)
if !@door[@selection]
if @door[open]
open = next_number(open)
end
end
new_selection = next_number(@selection)
if new_selection == open
new_selection = next_number(new_selection)
end
@win += 1 if @door[new_selection]
end
private
def next_number(n)
(n + 1) % 3
end
end
def show(title, player)
(1...ARGV[0].to_i).each do |x|
player.play()
end
puts "#{title} won #{player.win} times."
end
show("no-mover", NoMover.new())
show("mover", Mover.new())
とりあえず100000回やりゃいいだろう。
c:\home\arton\test>ruby montyhall.rb 100000 no-mover won 33554 times. mover won 66698 times.
まじですか！
と、落ち着いて考えればMover#playにプログラムしてる通りじゃん。なんかごちゃごちゃ書いているが結局これってこういうことだな。
def play()
@select = rand(3)
@win += 1 if !@door[@select]
end
ジェズイットを見習え |
Before...
_ shiro [「これは整数でしか動作しない…」というのは、「Lispなら動的型付けだから整数じゃなくてもOKよ」という意味ではなく..]
_ arton [なるほど、言われてみればそうですね。 なんか口惜しいから作ってみました。いんちきかなぁ。]
_ arton [すみません、上で「言われてみれば」とか書いていますが、読み直してみて納得しました。単に僕の読みそこないでした。]