_ 今日はずっと家のちかくにいたり家でごろごろしたり走ったりした。 こういう一日を送ったのは何か月ぶりだろうかと思った。
_ ここ1〜2週間は目が覚めてから寝るまでずっと頭痛だったりで辛かった。 高血圧だった頃に日常的に体験していたので、また血圧上がってきたのかなあと 思い帰れるときは早く帰って早く寝るように心がけていたのだが、 そういうときに限っていろいろトラブル続きで思い通りに行かなかったりした。
_ 今日は目を酷使することはやめてできるだけ寝ようと思っていたので、 目を酷使せずなるべく多く寝られるように運動することにした。というわけで ゆっくり2時間弱かけて走った。14.3km。といっても2.5km分くらいは歩いている。
_ 走る習慣は続いているものの、先月は平日にはほとんど走ることができなかったので 週1〜2回のペースだった。したがって走る能力が戻ってきているという感じがしない。 今日も10km越えたあたりからずっとしんどかった。ゆっくりペースで走っていたので 以前なら走りながら疲れを乗り越えるようなことができていたように思うんだけど、 今日はそういう気配もなかったので予定より2kmほど少ない距離で切り上げた。
_ 先月からかなり忙しく働いて、通常の仕事をしつつショー向けのデモを作ったりして 過ごした。デモについては、期間を考えるとこのくらいのボリュームで 抑えないといけないかな、という見積りを作業開始前に行って、実際はその 60%程度しかできなかった。期間が短かく割り込みも多いので、注意深く 時間を作って優先度を明確に決めて進めるという点では今までで最もよく できたように思うし、優先度の決めかたも的確で、直前になって打つ手がなくなった というようなこともなかった。そういう点だけを見るとまあまあうまいこと やったんだなという気にもなるし、他の仕事も人を動かしてそれなりにこなして いたので、先月〜今月はかなりよく働いた方だという手應えを持っている。 が、それでも当初の見積りの 60%しかできていないわけで、しかもそのうちの2割強は他の人にやってもらっており、 能力の見積りがうまくできていないという点で全て帳消しになった気分だ。
_ 過去に何度も限界近く、あるいは限界を越えたことがあって、それなりに 教訓を得ていた。今回もいろいろと得るものが多かった。 今回は自身の体調や周囲の状況、自分や他人の時間を把握するといったことについて それなりに気を配ることができていたように思うので、まあ年齢相応に 成長はしているんだろう。これ以上進んで限界を越えれば100%のところまで 行くことはできるだろうという感蝕はあったものの、その手前で早々に まとめあげる方向に進んだというのも、まあ年齢相応の分別というやつ なのかもしれない。夢中で死力を尽して取り組んで、結果玉砕しました、 というようなことはこの先も起きないだろう。その反面、 自身の能力はおそらくこのあたりがピークなのだろうというさほど根拠のない 感蝕を抱いた。
_ 体調については予想よりも早く悪化した。これも見積りが甘かった ということだろう。限界を越える選択をしなかったというのはよいけど、 その判断は「これ以上やったら体壊す」というところにあったわけで、 実はちょっと手遅れだったという点では見積り通りになっていない。
_ 今後は自身の能力を謙虚に把握しなおして、 進めかたにもっと工夫を凝らして、必要に応じて限界を越えるタイミングを 見計らうといったあたりが自身の持てる能力セットになるのかなと思った。 外から見れば10年前と大差ないのかもしれないけど。 人を使うことができる立場にいる (管理職じゃないのに) という点でも 10年前とはいろいろ違う。人を使うというのは選択肢であり制約条件でも あるので、自分のことで精一杯ということではまったくメリットを生かせない。
_ ともあれ、限界の手前で引き返し(たつもりだったがうまくいってなかったのかも)、 つねに落としどころと、まとめかたを探りつつ先に進む自身の様子を見て浮かんだ フレーズが表題のものだった。
_ 「臆病者のための株入門」で魅せられて、以降この人の本を読み続けているんだけど、 どうも魔法が解けたような気分になっている。
_ 起こっていることを分析し説明するという方法論は変わっていないように思うし、 ハシズムの分析なんかはさすがと思わせる出来なんだけど、どうもなんというか 毎回同じような語り口と手口に見えてしまって、そちらの方に気をとられて 肝心の中身まで至ることができないという読み手としては致命的な問題を抱えている。
_ ARM熱は冷めていないもののやる時間がとれていない。が、本は読んでいる。 NEONのことは書かれていないが、ARMのCとアセンブラの話、アーキテクチャの 話が万遍なく出ていて勉強になった。
_ x86だとah/alとかaxとeaxとかがあるので、レジスタの下位8/16/32ビットだけを 使うということが簡単にできるけど、ARMの場合はそうはいかないので、 unsigned char とかを使うのは意外とコストがかかる話らしい。 なるほど考えたこともなかった。
_ ここで書いていることが事実であれば、 妻は賢明な人間なのでこの程度のことはあらためて言われるまでもなく 分かっているとは思うけど、私が根本的に思い違いをしている可能性もあるので、 私が発した「預かりの本来の目的」というのは、こういうことを指しているのだ ということは明確にしておきたいと感じたので、自分なりに理解したことを書いておく。
_ まず前提 (として私が理解しているもの) の確認。一時預かりというのは、 保健所に来た動物たちを、一時的に保護して、新しい里親さんが 見つかるまで預かるという役割をしている。預かりさんで組織された 団体は、寄付金やその他で医療費等の諸経費を賄っている。組織によっては 里親さんにそれまでの費用を一部負担してもらうということもあるらしい。 団体を構える理由は、個人と法人の違いと同様に、個人では賄いきれない リスクやキャッシュを維持管理してゆくというところにあるのだろう。
_ 一時預かりの役割は、いわゆる「バッファ」というやつだろうと理解している。 保健所に来る動物は時と場合を選ばず、里親さんも都合よく見つかるわけでは ない。捨てられる動物の数や、里親になろうと思う家族の量も一定ではない (なんとも言えない話だが、連休前には動物が捨てられやすいらしい)。 一方、動物が収容されてから殺処分されてしまうまでの期間は決まっており、 その期間内に里親さんが見つからなければその子の一生はそこで終わってしまう。
_ 一時預かりは、そうやって発生する動物たちの残された時間と、 里親さんが見つかるまでの時間を埋め合わせるために存在するのだと思う (預かりさんとの生活の中で、里親さんになる可能性のある人々により強く アピールすることができるという効果もあるだろうけど)。「バッファ」というのは そういう様子を意図して表現している。 こうして一時預かりさんの元で暮らすことになった動物たちは、 劣悪な境遇から解放されて、新しい里親さんを見つける準備を始めるわけだ。 一時預かりさんの家庭の事情や、組織の事情の許す限り 時間を自由にかけてよいわけで、あと何日かでこの子の一生が終わってしまう、 ということに比べれば雲泥の差と言える。
_ 一時預かりというのは上記の通り「バッファ」の役割を持っているので、 なかなか里親さんが見つからない (預かりさんの手が空かない) というのは 役割だけのことを考えれば不利益につながる。また、 預かっている中で本当の里親に自身がなりたい、と思うことは (人として自然な感情だとは思うけど)、一時預かりという役割を持つ世帯が 一つ減ることを意味しており、これも不利益と言えるだろう。 冒頭で書いた私の科白はこのあたりのことを指している。
_ ただし、この話には一時預かりの方が里親になってくれる人よりも貴重な資源である ということが暗黙の前提としてある。もし一時預かり希望が供給過多になっていたり、 預かったものの里親さんが一向に見つからない、という状況なのだとしたら、 預かりの本来の目的は、できるだけ早く里親になるということになる。 もちろん、現実はそうではないだろう。もし一時預かりが後から後から 出てくるのであれば、ボランティアベースではなく職業としても成り立つはずだし、 その方がトラブルがあったときにはよっぽど対応しやすい。
_ ただし、一時預かりの犬たちが卒業するまでの 期間がそれなりに長いというのは里親希望が少ないということでもあると思う (うちの夫婦の行いが悪いのでなかなか見つからないという可能性もあるが)。 あと、一時預かりに求められるスキルは里親に求められるものとは 異なるのではないかと想像している。スキルの高低ではなく質が違うのだろうと 思っている。一時預かりに生じる可能性のあるモラルハザードのうち、 容易に思いつくものとして、いつでもリセット(団体に戻すことで預かりの役割を 放棄)できるとか、それに加えて、預かりたい動物をとっかえひっかえしてよいと 思うとかがある。
_ 組織内のごだごだは預かっている動物にとって何のメリットも ないものだし、信頼できる預かりさんを確保しておくというのはきっと 大変なんだろうと想像する。(預かりを始めて2年ちょっと、預かった犬が数頭という 状態の妻の言動を見る限りではそんな感じがするという程度だけど) といった経緯で、 預かるたびに里親になりたいと思っていたら預かりなんて 務まらないのでは、という理解の上で冒頭の科白が出ている、というのが 結論になる。
_ おまけ。一時預かりとか団体の評価の話。団体として成功しているとか、 一時預かりとして評価が高いというのはどういうものを指すのかなあという 疑問がある。里親さんをみつけた数ということであれば、 できるだけ貰われやすそうな子を選んで保護する団体/一時預かりの評価が 高いということになるが、そんなに割切れた話でもないだろう。 (言葉を選ばずに言えば)程度はどうあれ今目の前にいる子を助けたいという 気持は自然だと思うし、 最初に書いた通り、預かりが「バッファ」としての役割であるということであれば、 みすみす目の前の子を見殺しにしていたら役割を果たしていることには ならないという考えかたにもなる。
_ とはいえ、現実問題として保護には費用がかかる。里親さんが見つからないまま 長期間が過ぎたり、体が悪くて通院を繰返す子であれば尚更だろう。 一時預かりが貴重な資源であれば、なるべく早く里親さんが見つかるような 子を優先的に選ぶというのも自然な反応だと思う。 日々「トロッコ問題」に繰返し直面しているようなものだろう。 特に落ちは用意していないが、 ボランティアだからといって経済や競争と無縁でいられるわけではないだろうし、 難しいところだと思ったという話。
_ 記録を書く頻度が激減している。しんどいながらもまあまあ元気でやっているが。
_ すでに第3版が出ているが図書館にあったのは第2版だった。 極めてよい本だった。これを読まずによく今まで生きてきたものだと恐しくなった。 .NET Frameworkを使って仕事をする場合にはこれを読まないと 始まらないのではないだろうか。過去何度も疑問に思って、結局中のソース 読まなきゃわからない(けどソースがないしMonoのソースはどの程度参考になるのか いまひとつ分からないし) というもののうちかなりのものがこの本に載っていた。 読んだ結果、疑問が氷解したのかというと、そういうものと、そうでもないものが 混じっていたりするものの、少なくとも読む前と後では問題への取組みかたが だいぶ違うように思う。これは最新版を読まなければいけないな。
_ Effective Javaで読んだ内容だなあというのが多い気がして (それは感想として 適切なのかどうかはともかく) いまひとつ乗れないものがあった。 ちょうど現時点での興味の対象が性能やメモリ負荷の話だったので、その点が ほとんど満たされなかったというのが、乗れてない理由の大部分のような気もする。 とはいえ、 Enumで0にあたるものを定義しとかないと困るとか、なるほど考えたこともなかった〜 というようなtipsも多くて勉強になった。
_ 「武王の門」は上下巻。室町/南北朝時代というのはあまり馴染はないが興味は あったのでとても面白かった。読んでいる最中はかなり興奮していたのだけど、 読み終わっていろいろ資料をあたってみると(いろいろ資料をあたってみるというのは 大抵の場合Wikipediaを読んだというのと同義だったりするのでひどい話だが)、 かなり著者の創作が入っているみたい。作品中の人物達が出来すぎなくらい かっこいいので、そういう点で熱く読みふけっていたのだけど、やっぱり 出来すぎだったらしい。不明な点の多い人物やエピソードを大胆な仮説で... とかならさほど気にならないんだけど。
_ 「陽炎の旗」は「武王の門」の続編にあたるもので、「武王の門」の 登場人物や、その子、孫が出てくる。歴史の授業で出てくる 「義満が倭寇を鎮圧して明との貿易を再開した」というあたりと、 それまでは懐良親王が日本国王として明と貿易していたというあたりの 隙間を埋める構図になっていた。さすがにこちらは前作の予備知識もあったので そういうものだとして楽しむことができた。「懐良親王の夢」に影響されている 人物が多く出てくるが、その受け止めかたや置かれた立場はそれぞれ違っていて、 夢を継ぐとか、夢を追うというような構図とは異なり、そこがまたよかった。
_ 8割がたはWebですでに読んでいたもの。週刊といいつつまったく 週刊になっておらず、言い訳してみたり何事もなかったように進めてみたり、 毎回工夫が凝らされていてそれだけでも面白い。 毎回着地点が見えないというか、毎回うまく落ちているんだけど最初から 狙ってそうなっているのか？という不思議さがある。そしてその落ちかたは 毎回微妙に期待を裏切っていて得体が知れないというか底が知れないというか。 ファンの贔屓目だろうか。
_ それにしても「プログラミング .NET Framework」はよかった。 この手の本はJavaにもあるのかな。JVMの仕様があるのは理解しているが、 どのあたりまで実装依存なのかがよくわかっていない。
_ ARMアセンブラと並行してVM巡りつつVMのアセンブラやる というのも面白そうだなと思った。.NET(というかCLI)だとCILというのがあるし、 JVMもいろいろアセンブラがあるらしい。 CLIとかJVMは膨大なクラスライブラリがあって文字列やオブジェクトを扱うための 命令を供えているとてもリッチなアセンブラとして見るとなかなか面白いと思う。
_ そうそうBEAMも触ってみたいところだ。BEAMの役割がよくわかっていないので。 どこがBEAMの機能でどこがOTPなのか、など...
_ へー面白い。そして生ホッピーがとてもおいしそうだ。
_ 昨日。先週と同様なコースで、13kmほど。前回よりもだいぶ楽だった。まだ 桜は咲いていないが気温は寒くもなく暑すぎず気持よかった。
_ 久しぶりにジョンと8km弱。妻もつぼみを連れて途中まで一緒に出ようとしたのだが ハーネスをつけた後にスイッチが入ったジョンに噛まれて負傷のため中止。 けっこうえげつない傷になっていた。過去最高かもしれない。絆創膏を切らしていたので コンビニで買ってきて、ついでにプリンも買ってきた後にジョンを連れて走らせてきたところプリンを消化して経緯をマンガにして(片手で描けるからタイプより 楽らしい)アップしていた。いい根性しとる。
_ 最近ほとんど噛みつくことはなく、じゃれている間に興奮したり 怖いと思っても寸止め(歯を当てるくらい)で済ませてくれていたので、 ちょっとは良い傾向なのかなと思っていたけど、そうでもないらしい。まあそれだけ こっちも油断したということなんだろう。 ジョンの心の中を支配していたのは怖い＆興奮という感情なんだろうけど、 やはりもうこの段階まで来るとどんなに信頼した相手であっても 身を任せるということは一生期待できないのかな。と、なかなかヘヴィな体験だった (傷口が貫通している妻はもっとだろうが)
_ なお普段走っているコースの途中に自転車やバイクにまたがった青年達が大量にいて超こわかったので迂回した。そして向かいのみさと公園ではバイクで疾走していると覚しき大音響が聞こえていたのでそれもこわかった。 走っている最中ジョンがいつも以上に神経質になっていたのはそのせいだったらしい。
_ ジョンは最近ほどんと走っていないが体重はそのままなのでムキムキな感じは 減ってきて少し丸みを帯びてきた感じがする。かわいらしいといえばかわいらしいが、 平たく言うと太ったということなのだろう。
_ 今日はARMとCILをやった。
_ ARMはCalling Conventionを学んだのでそれに従ってコード調整したりした。 だいぶ書きやすくなった。add/sub系はsつけないとフラグが変化しないというのを 逆に覚えてしまっており、sつけるとフラグが変化しないものだと思って 使っていたのではまった。gdbでフラグの状況を調べるには p/x $cprs するしか ないのだろうか。けっこう分かりづらい。スタック系の命令は条件実行できないのね。 条件が成立したときだけreturn的なことがしたいと思ってもできない。まあ なくて困るというほどではないが。
_ CILはMonoでも楽しめるようなので安心。スタックマシンといっても スタック以外にある程度ランダムアクセスできるもの (引数とローカル変数) があるので、 そんなにマッシブではない。ただ命令とスタックの変化が掴みきれていないので なかなかうまく書けなかった。ブランチ系の命令はスタックが変化しないものだと 勝手に思っていたので、ループの終了条件となる数値をあらかじめスタックに 入れておいて、都度比較して...とやろうとして終了条件がスタックから 消えてしまった...!! というような感じ。 何かするたびにスタックの中身がなくなってしまうので (という印象を持つこと自体慣れてない証拠なんだろう)、けっこう考えかたを 改めないとうまくいかないらしい。例外を作って投げたり、 ループしたりというあたりで時間切れ。
_ しかしそれなりに補助するモードがないと書くの大変。 EmacsにはCIL-modeのような酔狂なものはおそらくないだろう。 いちいちメソッドのシグネチャやクラスのフルネームを記述しなければいけないので、 補助なしで書くのは難しい。デバッガのサポートも欲しい。スタックの状況が どうなっているのかがどうしても気になってしまう。それも慣れていないだけなのかも しれないけど。Visual Studioだとこういったあたりをなんとかしてくれるのかしら？ 時間みつけてやってみよう。
_ 妻がこちらに向かって手をかざして唸っているので何事かと思ってしばらく 見ていたところ、「止まれー止まれー」と言い出したのでますます わけが分からなかった。どうやら心臓を止めようとしているらしいと気付いたのは 1分ほど経ってからだった。こんな分かりやすく馬鹿馬鹿しい殺意を 直接向けられたのは生まれて初めての経験だったので若干感動してしまった。
_ OfficeやVisual Studioは、バージョンアップをするたびに 境界をあいまいにして立体感を出さないデザインになっている気がする。 2013は、それがネクストステージに進んだ感じがする。 そこにタブがあるということを知らない人が見たらただのラベルの羅列にしか 見えないし、セルの行番号を示す部分と実際のセルのコントラストがほとんどない。 何かを押し進めているうちに副作用でそうなってしまったというよりは 意図しそのように進めているように見えるんだが、その理由がよくわからない。
_ 突然ジョンが怯えきった表情で吠えだした。 私が膝の上に載せていじっていたMacBookの背面で光っているリンゴマークが 本気で怖かったらしい。あんなに切羽詰まった怖がりかたは初めて見た。
_ 早起きして、ジョンと2日連続で走った。昨日は10kmほど、今日は8km弱。 桜がとても綺麗だった。昨日はなるべく多くの桜を見ようと、みさと公園もまわって みたりしたが、結局公園の中にはほとんど桜がなくて、周囲の道路の方が 多かったので今日はそのあたりを走った。
_ あいかわらずリュックがないのでメッセンジャーバッグを背負っている。 2日連続で背負って走るのは初めて。どうも姿勢に無理が来るのか 腰が痛くなった。あと久しぶりに靴ずれに。やはり普通の靴下だと縫目が 多くて走るのには向いていないようだ。
_ お勉強会で書いたループのコードは以下のようなものだった。
.method static int32 Main() cil managed {
.entrypoint
.locals init (int32, int32)
.maxstack 8
ldc.i4.5
stloc.0 // max counter
ldc.i4.1
stloc.1 // current count
loop:
ldstr "Test"
call void [mscorlib]System.Console::WriteLine(string)
ldloc.0
ldloc.1
ble exit
ldloc.1
ldc.i4.1
add
stloc.1
br loop
exit:
ldc.i4.0
ret
}
たかがループで貴重なローカル変数を2つも使ってしまっており非常に不満。
スタックに入れても比較とかで使われちゃう (という発想はおそらく
おかしいんだろうが、スタックマシン脳になりきれていない頭ではそう思えてしまう)
という点については、スタックのトップを複製する命令は当然あるだろうなあと
思って探してみたところ、dupというのがまさにそれだった。
_ dupを使うことでカウンタをローカル変数に持たなくても済むようになった: (追記: もともと乗せていたコードは動かなかったので修正。 実は例外を作って投げるテストも並行でやっていたので、loop抜けると 例外を吐いて終了させていたのだが、コードのっけるときに見づらいと思って その部分を単純に取り除いたらスタックにデータがまだ残っている状態だった。次に出てくるコードも同様)
.method static int32 Main() cil managed {
.entrypoint
.locals init (int32)
.maxstack 8
ldc.i4.5 // max counter
stloc.0
ldc.i4.1 // current
loop:
dup
ldstr "Test"
call void [mscorlib]System.Console::WriteLine(string)
ldloc.0
bge exit
ldc.i4.1
add
br loop
exit:
pop
ldc.i4.0
ret
}
悪くない。けど、単に繰返したいだけだしカウンタの値を使いたいわけでもないのに
ローカル変数を消費するというのはやはり業腹だ。が、
dupはスタックのトップを複製するだけなので、トップとその次を複製しないと
今回の要件は満たせないような気がするなあ...というところで
C#でループのコード書いてmonodisでCILのコードを眺めてみた...なるほどその
手があったか...
_ 書き直した結果ローカル変数をなくすことができた。
.assembly extern mscorlib {}
.assembly test {}
.method static int32 Main() cil managed {
.entrypoint
.maxstack 8
ldc.i4.0 // current
loop:
dup
ldc.i4.5
bge exit
ldstr "Test"
call void [mscorlib]System.Console::WriteLine(string)
ldc.i4.1
add
br loop
exit:
pop
ldc.i4.0
ret
}
比較するところで終了条件を単にスタックに積んでいるだけだった。
for文の構文を思い浮かべながら書いていたので、あらかじめ必要なものは
積んでおかないと...というように思いこんでしまっていた。
なお、C#のコードではカウンタにあたるものだけはローカル変数として
確保していた。テストしたときのコードはカウンタそのものは
利用していなかったのでローカル変数にする必要はないのだが、
カウンタの値が必要な場合はさすがにローカル変数にしたほうがよい場面が
多いような気がする。
_ CILの仕様はECMAのドキュメントがかなり分かりやすいのでそれを使っている。 命令数はそんなに多くないので全貌の把握はそんなに難しくなさそう。 ただ、命令のコストに関するものがまったく分からないので(VMなんだから 当然なのかもしれないが)そのあたりがきつい。例えば、 引数、ローカル変数は4つまでは1バイト命令でひっぱってくることが できるようになっていて、それ以上の場合は2バイト以上の命令になるのだけど、 4つまでとそれ以上のときの差がどのくらい出てくるのかという感覚がわからない。 スタックで済ませる場合とローカル変数を使う場合のコストの差とかも。
_ 先程のカウンタ云々の件も、 ここで起こったことだけを見ると、スタックを積む場所と使う場所があんまり 離れてると大変、という教訓を得るわけだけど、スタックマシンというのは たとえば、 「1 2 3 4 * / + 」 で (3 * 4) / 2 + 1 ができるというように スタックを積む操作とそれを使う操作が離れていてもよいという面もあるわけで、 今回の教訓を生かすとなると、「1 2 3 4 * / +」じゃなくて 「3 4 * 2 / 1 +」と書きましょうね、ということになる。もちろんその方が 書きやすいけど、じゃあ効率はどっちがいいの？というような疑問が出てくる。 手元で試してどちらかが有利という結論が出たとしても、それはdocumentedな 挙動なのかどうかすらわからないということになるような。
_ 仮にCILを手で書くことに一定の利点を探ろうとするなら、 高級言語の仕様では実現できない動きをさせるとか、コードサイズを小さくする という程度ならある程度現実的だけど、手で一生懸命書いたからといって C#とかのコードよりも性能のよいものが作れるのかというととても疑問だ。 いくつか実際に書いてみて比較してみるか...たぶんたいして変わらないか、 理解が浅い分むしろC#で書いたほうが速いという結論になりそうな気もする。
_ なお、Visual StudioにはIL SupportというExtensionがあった。が、.il を 認識できるようになって、シンタックスハイライトができるようになった くらいらしい。Intellisenceが利くわけでもなく、デバッガでスタックの様子を 見ることができる気配もない。さすがにこれではきついな。
_ また、インラインアセンブラみたいに使うことができるクラスもあるようだ。 DynamicMethodというらしい。 CILを直に書くよりは現実的なのだろうか...???
_ 親しみやすい設定でアルゴリズムを解説しており、プログラミングに明るくない 人や、あまりアルゴリズムに親しみのない人でもイメージが沸きやすいように思う。 公開鍵暗号を絵の具で例えてみたり、かなり大胆なデフォルメがあったりするけど、 わかりやすいし、そのわかりやすさのために何を犠牲にしたのかがきちんと 書かれているので好印象。
_ 何を基準に「もっとも強力な」アルゴリズムを 9個選んだのかということも冒頭にきちんと表明しており、これも好印象。
_ セカイ系というのは言葉としては聞いたことがあったけど、具体的に何を 指すものなのかは理解していなかった。独特な設定で構築された世界観を 持った話なのかな？といった誤った想像をしていた。
_ この本ではどういう文脈で使われているかを 辿ったり、起源を辿ったりしているが、いろいろと因縁のある用語のようだ。 思い入れがないだけに、 そんなバズワードを軸にするなんて危なっかしいなあと思いつつ読み進めた。 バズワードではなく明確な定義を辿って、この用語の周辺で起きた出来事を まとめているので言いがかりなのだが
_ エヴァンゲリオンが残した傷跡の大きさは何なんだろうなあと常々思っていて、 この本で出てきたエピソードたちはかなり腑に落ちるものがあった。
_ 「トロッコ問題」から辿って見つけた本。短篇集だった。 SFというと宇宙船やら他の星やらが 出てくるものばかりだと思っていたが、この中に入っている短編は いろんな設定があって、SFといってもいろんなものがあるのだということを知った。
_ 表題作はSFの古典的な名作とされているらしい。実際そういう評価を 聞いたからというわけではないと思うんだが、この短篇集の中でも表題作の 存在感は別格な感じがする。SFでは 同様な設定で違う結末を描く「方程式もの」というジャンルができているらしい。
_ 為末大のエッセイ、なのか。為末といえばたまにtweetで文章を見掛ける。 なかなか流麗で力強い文章を書く人だなあと思っていた。
_ 全体的に上記の印象を敷衍するような内容ではあった。「心と体の声を聞け」という くくりで出てきたのは、 先日書いた中で出したかった結論に 近いものを感じた (もちろん本書の方はこのようなすっとぼけた展開ではない)
_ 「一番を目指す」というくだりについては違和感を覚えた。 一番を目指していないというのは、なれない自分を直視しないために 最初から興味がない態を装っているだけだ、という感じの展開なのだが。 自分の胸に手を当てて考えてみると...どうなんだろ。中学のときの作文では 「一番でないと意味がない」的なことを書いていた気がする。 当時どのような思いでそれを書いたのかはもう思い出せない。 確かに何らかの諦めや逃げによってこういう心境になって、無意識のうちに それを隠しているという可能性はある...のかなあ？正直あまりに自然に 「一番であること」への欲求が見当たらないので、自分では区別がつかない。
_ つづき。 前回、ローカル変数をなくすことはできたものの、1回のループでブランチが 2個あるというのがどうも気に入らない。そういえばC#で書いたループでは 最初に比較ロジックにジャンプさせていたなあと思いながら以下のようなコードを 書いてみた。
.assembly extern mscorlib {}
.assembly test {}
.method static int32 Main() cil managed {
.entrypoint
.maxstack 3
ldc.i4.0 // current
br.s loop_0 // （゜∀゜）
loop:
ldstr "Test"
call void [mscorlib]System.Console::WriteLine(string)
ldc.i4.1
add
loop_0:
dup
ldc.i4.5
blt.s loop
pop
ldc.i4.0
ret
}
しかしなぜかうまく動かない。（゜∀゜）の部分を生かすと addのところで
System.InvalidProgramExceptionになってしまう。（゜∀゜）のところを
コメントアウトすると動く。何が悪いのかさっぱり分からない。
_ Windows環境で試したところ (.NET Framework 4.0) 問題なく動いた。 ECMAのドキュメントを見てもInvalidProgramExceptionのことは書かれていないようで、 どういう条件のときにそれが出るのかがいまいち分からないのだが、 軽く試した限りでは、
_ Visual StudioのIL Supportは、コードのステップ実行ができるので デバッガがまったく使えないわけではないようだ。それだけでもけっこう助かる。 ilasmとmonoだけではどうにもならない気がしてきた。MonoDevelopを試してみるかな。
_ Monoのソースを見て何が原因で例外吐いているのか調べるのはやぶさかではないが、 今使ってるマシンでは調べものをしながら統合開発環境を使うのはむずかしい。
_ そういやSSCLIなんてのもあったな。 比較するにはよいかもしれない。
_ 食感はクリームみたいなんだけど甘いわけではないので、食感からくる予想との 差異が大きくて混乱しているらしい。 混乱しすぎて私はなぜ歯みがき粉を食っているのだ？と一瞬思った。もちろん 味はまったく違うが、なにしろ混乱しているので何か知っているものに 近づけなければどうにもならなかった。 ヨーグルトだと思って食べるより 柔らかいチーズのようなつもりで利用したほうがいいのかなあと思った。
_ JavaScriptとLLVMのまわりはいろいろ動きがあって面白いな。