_ 体調を崩した。胃のむかつきがひどくて電車に乗るのにも苦労するような日々だった。 酒飲みすぎたかもしれない。2日ほど粗食をして、その後頭痛と悪寒と倦怠感がひどく2日ほど寝込んだ結果少し元気になった。
_ 寝込んだ結果仕事が溜まった。締切のあることなので仕方がないが ここで無理しても悪い循環が続くだけなので、少し態勢を整える日を作らないと いかんと思う。それはそれとして締切は迫っているのでやむなく休日でカバーする。 来週末は長目に休みとろうと思う。
_ どこかの書評で読んで気になったので借りた。単行本の方。
_ 不愉快な読後感になるのではないかというのが 読む前の印象というか予想だった。予想を大きく裏切る内容で圧倒された。 電車の中で鼻から汗が出そうになってしまった...。
_ 進行性筋ジストロフィ患者の鹿野靖明という人を見つめつづけて、 彼自身とその周囲で起こっていることを必死に捉えようとしている様子が 飾らない文体で迫ってくる。一気に読み進めた。 中盤くらいまでは、あまりに著者が悩みつづけているので、 この人は題材に負けているのではないかと不安になりつつだったけど。
_ エピローグの著者の分析に納得して深い感動を覚える程度には感情移入して 読むことができた。 映像でなくて文章だというのがよかったと思う。実際に動いて喋っているところを 見たら、その印象が邪魔をして理解できなかったかもしれない。
_ 福祉に対する関心が強まったのかというと...どうなんだろう。 鹿野氏はただただすさまじい人だったという感覚は間違いなくある。 忘れられない1冊になりそうだ。
_ p176で描かれている「自立観」は重要な視点だと思う。 健常者であれば他人に遠慮することと自分の望むものを得ることは 必ずしも矛盾しないが、 24時間常に介護が必要な鹿野の場合はそれでは自分の望むものを得ることができない。 鹿野の横暴ともとれる態度、厚かましさ、わがままは、 他人の力を借りなければ生きてゆけない重度障害者が自立するために必要な 手段だったということになる。
_ もちろん、ボランティアに依存して介護を受けないと一日として生きてゆけない 鹿野にとっては危険を伴う行為であるのは間違いないわけで、同じことをやって 誰でもうまくいくわけではないだろう。見放されれば死につながるし、少なくとも 自立した生活を行うことはできなくなるわけだ。 鹿野の下から去る人も多いが、それでも常に人が集まってきて自立した生活を 送っているのは鹿野のキャラクターによるところが大きいようだ。 ワガママに人生を感じる (p303) というのはなかなか複雑な味わいのある文章だ。
_ 介助の形、障害者との関係について。 「健常者である自分の生活感情・信条を基盤にして『おかしい』ことは『おかしい』と 言えばいいのだが、同時に『おかしい』のはひょっとしたら自分なのかもしれない、という視点を 手放してはならない。常識的に対応すればいいのだが、常識を疑ってみることも大切である (p316)」 「あまり人の性格の奥というか、深みというか、そこのところを考えていくと、まったくわからないので、やめて、もっと現実の表面に出ている部分を見ればいいんじゃないでしょうか。そして、自分の理解できることはちゃんと受けとめ、責任を持つ。 (p392 あるボランティアの手記)」 本のどこかで、障害者の接しかたと外国人の接しかたは似ているというようなことが 書かれていたが、ここで引用した内容はいずれも障害者との関係に限らないなあと 思う。 価値観の違いを乗り越えるにはこういう考えかたが結局のところ大事なのだと私も思う。
_ この本は今年になって文庫化されたようだ。文庫版は順番待ちが長くてキャンセルしてしまったが、 また時間を置いて読みなおすために予約した。文庫で加筆されている部分もあるだろうし。
_ さかどん君のfacebookの投稿で、 初心者にRoR学ばせても...とか、SASSみたいなのは教育によくない...といったような話を読んだ。 ひらしょーさんの本を読んでから、初心者向けに何を薦めるかということには 敏感になっているので、 ひとしきり読んでやっぱりどこでもそういう話はあるんだねえと思った。 それ自体の話は別の機会に書くかもしれない。 その流れで、表題の本は初心者に適しているというようなことを書いている人がいたので興味を持って借りた。 頭を抱えた。 以下の感想は、
_ 主人公がようやく入社できたのが絵に描いたようなブラック企業で、 幼女のような見た目だけど凄腕のエンジニアである先輩SEと衝突したり 助け合ったりしながらこの世界で生きてゆく決意をするという話、だと理解した。
_ その先輩SEの主人公に対する言動は横暴を通り越して支離滅裂で、 主人公の抱く怒りや闘志もどこから湧いたんだよと思うような不自然感があった。 そしてなんだかんだで前に進めている主人公の基本能力は 高いんじゃないのかと思う(悩み続けてまったく何もできない、 というのがよく見掛ける光景なので意外というか御都合主義というか、 リアリティを感じなかった)。 先輩SEが寝食を惜しんで、絵に描いたように無軌道な経営者の無茶な要求に答えて 自分の都合より客の都合を優先している様子を見た主人公は、 この人はプロフェッショナルなんだという結論に至り、彼我の差と、 そこまでに至る自信も意思もないことを発見して去ることを決意したが、 タイミングを見ている間にトラブルに巻き込まれて、そこで得た 「システムを組み上げる喜び」に魅せられて、結果として前段落の通りこの 世界で生きてゆく決意をしたということらしい。
_ 主人公がそう思ったという話なので、それに対して目鯨を立てるのもおかしい 気がするが、 そもそも著者はこの本で何を伝えたかったのかがいまひとつ分からない。 プロとして生きてゆく覚悟がなくても、物を作り上げる喜びを感じられるのであれば なんとかなるよ、というメッセージと理解すると、なんだかとても危うさを感じる。 後書きを見る限りではとくにそういうわけでもない気がする。 単にSEは大変だった、という経験を元に書いたファンタジー小説ということなのだろうか？ それならそれでいいが、読むきっかけが「初心者にすすめられる」本という文脈からだったので、それはこちらの不幸というべきなのかもしれない。 確かに自分の理解できないものを適当にひっぱってきて使うなといった教訓レベルの話はそれはそれでいいのかもしれないが...
_ そもそも「先輩SE」はプロフェッショナルというよりは 単に搾取されているようにしか見えない。 「先輩SE」が並べる理屈も、搾取されていることに気付いてないか 見ぬふりをしているのか、自身の身を守りつつ振舞うという視点が決定的に 欠けており (主人公が部下についたことによってそういう自覚が 芽生えたと思えなくもない描写はあるが)、これが目指すべきSE像であれば確かに 経営者は大助かりだなという気がする。
_ 「先輩SE」については、見掛けよりも歳をとっている、生い立ちが厄介、 人間関係の構築が苦手、大企業に 勤めた経験があるらしい、等の思わせぶりな設定が出ているが、特に 消化されることもなく終わってしまった。なんだそりゃ、と思った(が、 続編があると知ったのでそういうもんなのかという程度にトーンダウンした)
_ これだけ小さい所帯でネットワークのことだけをやる会社というのも なんかイメージがわかない(と思ったが、これも Wikipediaを見る限りでは とくにネットワーク専門の会社というわけでもないらしい)。 客の横暴ぶりは、まあそんなこともあるかねという気もしたが、 ひと悶着あった後に恐縮している様子はまったくリアリティを感じなかった。 自分の非を認めるような物分かりのいい奴が、相手の立場をまったく考えない横暴ぶりを発揮するというのが支離滅裂だと思った。
_ 主人公の身にふりかかっていることは確かにひどいもんで、 そこには確かにリアリティはあると思う。読んでて気分が悪くなるのは、 荒唐無稽というよりはむしろ身に覚えがあるからだろう。そして世の中には もっとひどい事例がいくらでもあるという予感もあるのだと思う。 そういう意味ではこの世界をうまく描き出している...のかなあ？ 全体として見るとやっぱり荒唐無稽な印象になってしまう。 もちろん狙っているんだろうけど。幼女みたいなSEなんてのが出ているのだし そもそもそこまでリアリティを追求したらただの企業小説になってしまうようにも思う。
_ といったところで悶々としたまま読み終えた。結局何だったんだ？というのは 分からないままだ。
_ そうそうこの本は図書館で借りたんだが挿絵のところに図書館の印鑑が 押されていた。スキャン対策かな。今までこの手の本を借りたことがないので 初めての経験だった。
_ マップというのが適切でもあり混乱の元でもあるように思うんだが、 どこから始めていいのかというのがぱっと見分からない。 マップと説明の順序の関連が分からないと言ったほうが正確か。
_ もうちょっと技術よりのサポートを期待してもいいように思う...のは、自分が 技術者だからだろうか。カセットテープかぁというような逡巡もある。
_ しかし全体的に着実に時間をかけて繰返しやればよいというアプローチはよいと 思う。この歳になってくると、じっくり地道にやるのが結局一番よいとか、 かならず身につけることができるとか、そういう言葉に弱くなる。若い頃は もうちょっと無謀というか、取り組むことに意義があるというような負け惜しみとも つかない言葉を思い浮かべつつ挫折することにあまり抵抗がなかったもんだが。 加齢にともなって、地道に何かをやるということが少しずつできるように なってきているということなのかなと思う。遅すぎる気もするが仕方ない。
_ 仕事はしたがうんざりすることが多くてやる気が出ないな。
_ 帰りは人身事故で遅れた。
_ 12章つづき。前回から時間が開いてしまったのでちょっと迷子気味だ。 いろいろ思い出しながら取り組む。
_ 縦0縦1やめちゃうのか。回転するときに困る気がするが... 言われるままに削ってみる。もちろん部分プログラムはそのままだ。
_ ついに出力を入手した。が、「マス目位置を計算する」でまた メモリ[0] の世界に逆戻りしてしまった... まあ頑張ってヒープ管理するものを 作ってもよいし、メモリ0〜10あたりはレジスタの世界だと思えばいいか。
_ 回転のときに別に困らなかった。「マス目の位置を計算する」のおかげだ。
_ 「正しく消えない」以前に一番上で回したときに落ちるほうが気になるな... と思ったらサンプルでは起きないな。...ああ次の落とすときに 回転を元に戻していないからか。忘れてた。
_ あと、一定以上のスピードで↑を連打すると回転してくれない。 これはサンプルでも一緒だ。もちろん60連射以上しているわけではない...
_ もっとうまい列の消しかた。最初に思いついたのは「底だけ見てればいいんじゃないのか」だったけどもちろんそれではだめで、一番底に隙間があったら消せない。 下から探して消せる行があったら上を落として、またその行を調べて落とせるようなら 落として...消せなくなったら終わり、とか。 最初に思いついたのはそれだった。うまいのか？やってみる。
_ こんな感じになった:
指定列は消せる？(縦) とは 消える？ → 1 横 → 1 横 <= 10 なかぎり 消える？ → 消える？ * (メモリ[100 + (縦 * 12) + 横] = 1) 横 → 横 + 1 出力 → 消える？ 列を消す() とは 縦 → 18 終わり？ → 0 (縦 >= 0) * (終わり？ = 0) なかぎり 消える？ → 指定列は消せる？(縦) 消える？ なら 終わり？ = 0 なかぎり 終わり？ → 指定列を消す(縦) 1 - 消える？ なら 縦 → 縦 - 1 指定列を消す(縦) とは 消える？ → 指定列は消せる？(縦) 消える？ なら 横 → 1 横 <= 10 なかぎり メモリ[100 + (縦 * 12) + 横] → 0 四角(縦, 横, 0) 横 → 横 + 1 ずらす(縦) 出力 → 1 - 消える？しかしこれうまいうまくない以前に正しいのか？という問いに答えるのが大変だな。 本文の「回転 = 3のときにおかしい」というのも、気付くのはけっこういろいろいじってからだろうし。
_ 今週は体調悪くなる前にあらかじめ休みをとっておいた。山場は超えたので 明日の午後から休む予定。
_ おもしろかった。ニュートンの伝記は読んだことがなかったので ニュートンがこんなに生き生きと(?)造幣局の官僚として働いているというのは 初めて知った。 錬金術に取り組んでいたことも知らなかった。この本では 錬金術と贋金づくりが陰影をなしていて面白い。イギリス国教会と対立していたというのも興味深い。
_ 「南海泡沫事件」というのも知らなかった。それにしてもこの頃 (17世紀後半〜18世紀、名誉革命以後)のイギリスは滅茶苦茶だな。 もともと抱いていたイメージ(スチュアート朝がなくなって立憲君主制に一歩近づいた)とはだいぶ違う。
_ 13章。3つにするためにいじらなければいけないのは部分プログラムのみ。 感動。メモリ[0]〜 の威力だな、と思ってしまうかもしれないけど。
_ なるほど、回転はテーブルを使ってやるのか。一気にすっきりした。 回転でまとめてから、種類ごとにつくるという順番。これなら4つになっても 同じ仕組が使える。逆だったら大変だ。
_ そして速すぎて埋められない。そもそもテトリスは苦手だった。スピードを落として 楽しむことにする。6でもだめだった。8にするか...8でもだめだった (何回のループで1マス落ちるかの話をしている) なんてむずかしいゲームなんだ!
_ そして4つにする。テーブルを入力... は、むりでした。サンプルからコピペで動かしてしまった。 3つのときのテーブルですら面倒感を覚えてしまっていた。 それにしても読み飛ばし前提で構成するというのもすごい。これが初めての展開ではないが。
_ 表を小さくする工夫。頭がこんがらがってきた。そして 回転軸のとりかたは実は難しいことがようやくわかった。 2x2のブロックを回転させると移動してしまう。「壁蹴り」というのも あるらしいしなあ。
_ 表は結局パターン(種類)の数だけあればよい。というのは最初から 分かっていたことであるが、回転を考えながら表を減らしてゆくのは なかなか頭を使った。
_ 「早見」をあらためて眺める。剰余はない。 除算があるので作ればいい。本で使っていない機能は「定数」と 「ファイルの挿入」か。もうちょっと規模が大きくなったら便利そう。 英語風の「早見」も見てみた。英語風だと前置になるんだな。 そしてPython風度が一気に上がった。
_ 14章。 次のアプローチ。Sunabaでもっと遊ぶ、Sunaba以外の言語に進む...など。
_ Sunabaでもっと遊ぶ。作ったプログラムをもっといじる。別のプログラムを書いてみるなどが思い浮かぶ。
_ Sunaba「を」もっと遊ぶ、というのも考えている。 当初から興味があったSunaba実行環境について 理解を深めたり自分の都合のよい環境で動くようにしたり...など。 互換環境を作りたいわけではないし、Sunabaの互換性を損うようなことをしては 教育用言語としての生命を縮めるようなものだとは思うが、コンパクトで 親しみやすい環境なので、単に学習用とだけするのは勿体ないなあと思うのもまた事実。 このあたりはゆっくり考えようと思う。
_ それにしてもテトリスが苦手すぎるのでこれを使って練習しようかなと少し思った。 思いっきり遅くして。↓で落とせるようにする必要もあるか。
_ そしてあらためて本当にテトリスできちゃったんだなあということに じんわりと感動を覚える。本としての感想や次の取組みについては別途書く予定。 本に対する取組みは1巡したが、取組みまだまだ続く。
_ Wikipediaを見た。 教育用に作られたというのは本当なのか。 そして教育の効果はどうだったんだろう。 まあ、慣れるまでは何らかの効果はあるんだろうな...
_ こないだ書いた判定ロジックだと、 Wikipediaにある「スプリット」「ワン・ツー」というやつに対応できないな。 消すときはかならずつながっているはずだと思っていたが考えが甘かった。
_ 昨日はだらだら過ごした。あれをやろう、これをやろうかと考えつつ結局何もしないという結果の連続は心身の健康上あまりよくない。
_ 体調崩したり忙しかったりで4週間ぶりになってしまった。 久しぶりなので無理せず5kmほど。5kmのうち2kmちょっとは歩いているので、 実際には2km程度しか走ってない。
_ やっぱり走るのは気持いいな。
_ 前回の続き。 Sunaba関係では以下3点の取組みがあるのかなあと思っている。
_ 2にはいろいろねらいが考えられると思う。
_ Bはいろんなお手本を示すという意味ではAに近い。 ただ、いっしきさんの書いているSunabaのソースを晒していない理由は たしかに悩ましい問題だ。いろんなソースを見ていじって遊べる (たとえばGLSL Sandboxのような) 環境というのがあったらよいと考えがちだけど、 一方で教育用言語としての特殊性 (調べても出てこない) が失なわれてしまうわけで、それがよいことなのかどうかと 言われるとなんとも言えない。
_ ずっと使うにはおもちゃだけど、 卒業するにはよくできすぎているというのが 私のSunabaに対する評価で、私にとって悩ましく映るのはまさにその「できすぎ感」のせいだ。 本来は悩むものでもないのだろう。余計なことを考えなくて済むような コンパクトな環境で取り組むことの新鮮さと大事さは理解できているつもりなので、 たまに思い出していじるような存在として自分の中に残ればいいのかな。
_ 3(Sunabaの環境をいろいろいじる)は、Sunabaの取組みとは関係がなく、 単純に技術的な興味でやりたいと思っているもの。 特にSunabaを拡張したいわけではない。Sunabaはコンパクトで遊びやすいので、 日頃の自分の(Sunabaとは別の)取組みにうまいことリンクできそうなねたがいくつか 思いつくのだ。
_ ひととおり取り組んだので感想を書く。
_ 取り組みの目的は以前書いた通りで、 ゲームプログラムの経験がないので取り組みながら学んでみたいというのと、 他の人に薦めるにあたってまず自分で取り組んでおきたいという2点。
_ ゲームづくりの初体験としては、うまく導かれた感が強くて気付いたら 出来上がっていたという感じ。もっと自分の頭で考えることをしても よかったように思う。もっともこれは繰返しやるとか、自分で他の課題を見つけてやるなどで補ってゆくもののようにも思う。
_ 他人に薦めるために読むというのは、きちんと薦めたいというのと、 ひらしょーさんの意図をよく理解して余計なアドバイスをしないようにしたいという 2つの目的があった。後者については「必要なことは全部本の中に書いてある」 ということがよくわかったので、本の中で理解したことだけを 使ってアドバイスするというのがいいのかなと思っている。もっとも初心者が つまずくところがほかにないのかと言われるとよくわからない。 あったあったで貴重な経験だと思う。
_ 誰に薦めるか...まず妻には読んでみてもらいたいところだ。 妻はプログラム未経験というわけではないし、Sunaba自体も触ったことがあるので 本のターゲットとして適切かどうかは分からないが、 妻のプログラミングの世界がどう変わってゆくのかは見てみたい気がする。
_ この本は誰に向いているんだろうな。いや、向いているのはおそらく じっくり取り組んで自分の頭で考えながら進めてゆくことができる人、 そうしたい人といった人物像が容易に浮かぶが、 そういう人がこの本以外でうまく学べないものなのかというのがよくわからない。 今までの取組みでだめだった人の中でどのくらいの人がこの本で できるようになるのだろう？
_ この本のおかげでプログラムが書けるようになったという人が増えたり、 もっと気の長い話をすればこの本をきっかけでプログラムを生業にするようになった、 というような人が出てくればいいだろうなと思う。そういう人は確実にいるだろう。
_ このあたりは想像していても仕方のないことなので、身近の機会を生かして 薦めていって、なるべく本人の体験を邪魔しないように見守ってゆき、 できれば記録に残すといったことができると私なりの貢献になるのかなと思う。 取り組んでいる本人の記録もあると御互いが補完できていいんだろうなとも思う。
_ さて、早速Sunabaで遊んでみる。SDLに親しんできた人間としては 新しい環境で最初に試すといえばやはりtestspriteだろう。
_ 始める前にルールを決めておいた。 まず、Sunabaとその追加パッケージを使ってよいものとする。したがって 本には書かれていないが早見に書かれている機能は使ってよい。 また、SunabaImageConverterも使ってよい。
_ それ以外に使ってよいのはエディタやフリーで手に入る画像編集ソフトのみとする。 別のプログラム言語を使って、 プログラムを生成するプログラムを作る等は禁止。エディタの置換くらいはよいが 正規表現は駄目。Sunabaで初めてプログラムの学習を始めた人とだいたい条件を 合わせたいと思うので上記のようなルールにした。 作業経過はlaunchpadに上げる。 ただなんか最近特に調子悪いみたいなので乗り換えるかもしれない。
_ さてtestspriteを書く。いきなりiconちゃんを描くようにする前に、まずは ドットを動かすようにしてみる。できあがったのがこれ。 ループのカウンタを足し忘れたり、変更した値をメモリに書き戻すのを 忘れていたりでひどいもんだったがなんとか30分程度で動いた。
_ 続いてiconちゃんをうごかしてみる。icon.bmpをSunabaImageConverterを使って プログラムに変換する。できあがったソースは メモリ[60000] → 999999...といったのが延々と並んでいるだけのもので、 これだけだと画面左上に表示することしかできない。 悩んだ末、エディタで「メモリ[6 」 を 「メモリ[p + 」 に置換して、 p をうまいこと準備してやることにした。できあがったものを 組み込んだのが revision 2。 なお、オリジナルのiconちゃんは32x32で、Sunabaの画面(100x100)にはでかすぎるので8x8に縮小した。 でもconvertの-geometryを使っただけなので、なんだか輪郭すらよくわからないものが動いているだけだ。
_ そしてカラーキーに対応できていないので背景の白まで描画されてしまった。 icon.sunabaをいじってカラーキー部分をコメントアウトさせる等の対応をすれば よいが、正規表現なしの置換では手作業になってしまう (64行しかないから別にいいのかもしれないが)。 今後画像差替のことも考えると真面目にやる必要がありそうなので修正した。 できあがったのがrevision 3。 icon.sunabaをいじって任意の場所に書けるようにした。 そしてその場所に書いたiconちゃんをカラーキーを意識しつつ6万台に コピーするロジックを書いた。convertの-geometryを使ったせいで 中間色が多用されてしまい綺麗に抜けていないが、いずれ画像を差し替えれば問題ないのでよしとする。
_ SunabaImageConverterでできたコードは画面にそのまま出せるように 作られているので、ワークエリアに展開すると無駄が多い(横幅が100前提になってしまうので)。 今はとくに気にしないことにした。気になるのであれば1回展開した後に詰めなおすような機能を作ればよいだろう。
_ 手元の環境で20個を動かそうとすると60fpsを割ってしまうな。 今のコードは毎フレーム画面全体を消して書きなおしているが、 iconちゃんを1個1個消そうとするとさらに遅くなって、30fps未満になってしまった。 2重ループはよほど遅いのかしら？移動をきちんと意識して書換えられない場所だけを 消すようにすればもっと速くなるだろうけど、カラーキーを意識しつつやるのは かなり面倒だ。そしてそれは取り組むべき努力なのだろうか？というのが よくわからない。 今まで親しんできたコードはだいたい毎フレーム書きなおしにしていたし、 私もそうしてきた。 ひらしょーさんのQAを読む限りでは、 これは必要な努力なのか技術的な制限なのかが読みとれない。
_ (追記: ここの内容は間違いが多い。取り消し線を使って訂正の上追記している) 今度はSunaba自体をいじるほう。こちらは原則として自分の手持ちの道具を なんでも使ってよいものとする。 公開されているSunabaのソースを改造することはしない。 調査のためにソースをいじることはあるが、改造はしない。言語仕様をいじったり VMの仕様をいじったりもしない。 Sunabaの内部構造を解説することを目的としない。自分の取組みにとって必要な ところだけを書く(もちろん無保証)。
_ 互換環境を作ることをは目的とはしていないが、作らないという縛りを設けることもない。 作る場合は互換性について最大限の努力を払うし、公開されているSunabaの仕様には素早く追従する。 こちらのルールはこんな感じだ。とにかくSunabaに迷惑をかけないようにする。 この範囲で何ができるのかを考える。
_
いろいろやりたいことはあるが、まずはSunabaで何ができて何ができないかを
明確にするために、VMを自分なりに作って動かしてみるところから始めようと思う。
まずはソースを読む。Sunabaのロジックの大部分はSunabaLibというC++の
ライブラリ側にある。コンパイラやVMもそちら。SunabaLibのソースは
公開されていないので、公開されているソースでできることは実はそんなに多くない。
(追記: SunabaLibのソースはSunabaCliWrapperとしてsrcの中に入っている)
_ 公開されているC#のソースは主にUI部分を受け持っていて、 キーやマウスの入力をSunabaLibに中継したりしている。画面の更新は ウインドウハンドルをSunabaLib側に渡しているのでC#側の仕事ではない。 SunabaはC/Sの形をとっており、SunabaLib側でサーバを上げて、 クライアント側でバイトコードを流しこむと実行できるという仕組らしい。 コンパイルはSunabaLib側のメソッドを呼んでいる。 実行も同じ仕組をとることは可能だろうけど、C/S方式をとっている理由は 「Sunabaの設計と実装」に明記されている。
_ バイトコードのフォーマットは仕様には書かれていないが、C#側のコードを 見る限りでは、コンパイルの結果として受け取れるUInt32の配列をバイト配列に 変換して投げているだけのようだ (実際に投げるコードはSunabaLib側にあるのでプロトコルはまだわからない)。 したがってsrc/include/Machine/Instruction.h を見ながら解析をすればいいだろう。 Sunabaを立ち上げておいて127.0.0.1:9999 にバイトコードを投げれば 実行してくれるんだろう。 (追記: 擬似ソケットを有効にしてビルドしている場合はTCP/IPでの通信ではない)
_ ということでバイトコードの中身を見てみることにする。 ソースをまったくいじらずに見るにはデバッガで止めて眺めるという方法があるが Ubuntu環境でやるのはちょっと難しそう。 サーバのハンドル(Socket)を無理矢理閉じて、待ちうけを止めさせるという 方法もあるか。 でも面倒なので素直にソースをいじる。 Sunabaのソースにちょっと手を加えて、クライアントが接続するポートを変える。 変えたポートに待ち受けているサーバをこしらえて、受けとったものを本来の ポートに転送させる。なおソースを見たりビルドしたりはMonoDevelopで 問題なくできている。すごいソフトだな....
_ ...うーんうまくいかない。そういえばWineで動いているプロセスのlocalhostと ホスト側のlocalhostの関係がどうなっているのかわからんな。 マニュアル見ても要領を得ないし出先なのでネットもつながってない。保留。
_ ...帰ってきた。特にネットワークとして特別なことが必要という記述はないな。 FAQの記述が若干気になる程度か。 wineのiexplore.exeを起動してUbuntu側のlocalhostで上げているWebサーバに 普通にアクセスできるな。うーんわからん。今日はここまで。
_ 朝大きな地震があった。そしてダイヤが乱れているらしい。会社に行く気持が 蒸発したので休むことにした。
_ 休日に遅れを取り戻すという発想になりがちで、 残業よりも効率がよいのは間違いないが、まあやりすぎはよくないよねという話なんだろう。 置かれている状況を鑑みてめりはりを考えつつやっているつもりだが、 傍目から見るとそもそも休日に出ることそのものが異常事態だと言われれば 特に反論できない。
_ 久しぶりにとんかつ教室見たらロースおじさんがたまにみせるかっこよさを 見せていて、さらに壊れかたがいつもと違う感じで興味深かった。
_ 他の本でもたびたび引用される「只管朗読」というアプローチを提唱している人の本。 「同時通訳の神様」らしい。恥ずかしながら知らなかった。 最後の方にある対談の相手である杉田敏さんはラジオやっていたので知っている。 当時高校生だった私には難しすぎてついてゆけなかったけど。
_ そういえば高校時代はけっこう音読をしていたなと思い出した。ラジオ聞いて 音読したり、語数制限本を音読したり。それ以来音読自体をほとんどしてこなかった。 言われてみると、口に出して読むというのはもっと活用してよい気がする。
_ ↑の本を出版している会社。京成に乗ってるとしょっちゅう見掛ける 深見氏の経営している出版社で、万能の天才を名乗る深見氏の 強烈なキャラクターが印象的。 言葉を選ばずに言うならこれ以上ないくらいうさんくさい。 で、自著以外の出版もしているのかと意外な気分になった。
_ 深見氏はこれまた印象深い「みすず学苑」の学苑長でもあるようなので、 おそらくあの奇抜極まりない広告も彼のキャラクターが強く反映されているんだろうと想像している。
_ 6.5kmほど。今日はジョンと一緒。
_ 4週間もブランクがあると筋肉痛からやりなおしらしい。まあ仕方ない。 かわりに足首の痛みなどはリセットされたので大事にしてゆきたいと思う。
_ 晩飯前くらいからなんだか気持悪くなってきた。食あたりか食べすぎか？ 胃薬飲んで寝よう。
_ 月曜日はだいたい週末に生活リズムが狂ったせいで寝起きが酷いんだが今日はさほどでもない。むしろすっきり目が覚めた。
_ ひらしょーさんにご指摘いただいた。 一昨日の記述には誤認や思い込みによる 間違いが多すぎた。Sunabaに迷惑をかけないと書いておきながらそもそも 記述のレベルで迷惑かけるというのは最低だ。本当に申し訳ありません。
_ C++側のコードがないというのはひどい勘違いだが、SunabaCliWrapperって何の役割なんだろう？と思ったり、 incというディレクトリの中のヘッダは何なのだろう？と思ったり、 そしてどちらも思っただけで追求しなかったりでひどい記述になってしまいました。 擬似ソケットのコードも確認しました。
_ 今のところSunabaという環境がどうやってできているのかということに 興味を持ちつついじったり眺めたりしている段階です。 思考の過程を書くことも目的のひとつではありますが、 せめてもっと調べてから書くようにします。
_ カラーキーについては、これからの取組みに欠かせない要素というわけでもないので 今後は省くかもしれません(背景があるわけでもないし)。 黒縁のスプライトにして書きつつ消すというのが 現時点では有力です。
_ とくに新しいことはしていない。こないだのtestspriteをVista環境で動かしてみた。 うーん速いな。スプライト50個でも60fpsきちんと出ている。 全画面消すのではなくスプライトを1コ1コ消すようにしても60fps出るし、 さらに「負荷」が半分くらいになった。
_ Wine経由だとエミュレーションのオーバーヘッドによってボトルネックの位置が 変わってしまうのか。な。となるとWine環境で取組みを続けるのは少し無理があるかもしれない。 少なくとも割切りが必要だな...
_ あいかわらずいそがしい。まだ刈取りには時間がかかりそうだ。 万遍なくやってどれも終わるのに時間がかかるという状態の連続だったのが、 ここ1ヶ月くらいは締切が次々に迫ってくるので結果的に各個撃破のような状態になっている。 そっちのほうが結果としてうまく進むように見えるのは 仕事ができない人間の特徴だろう。
_ 10人ちょっとの相手にインタビューをしているという話の続き。 インタビュー結果はFreeMindで一人1マップという形式でまとめているんだが、 Sphinxで報告を書くときに複数のマップから同じ話題を集約するというのが 手作業だとかなり時間がかかるのが気になっており、今回はそのあたりを どうにかしたいと思っていじっている。
_ FreeMindのマップ (.mm) は XMLファイルなので、 xml.dom.minidomを使ってparseしていじる。FreeMindのソースを流用したほうが 問題は少ないのかもしれないがどうもJavaをいじるというのは 最初の段差が高くてよくない... Javaの言語をいじることそのものもあまり 気軽な感じがしないし、Eclipse起動するのも相当億劫だ。その点Pythonなら だいぶ気軽。
_ 通勤の電車1往復半くらいを費してようやくそれっぽいものができてきた。 これで編集作業がだいぶ楽になる。
_ 昨日の続き。いくつか気になる点を直してひとまず完成とした。
_ 意識して使うようにしてきたおかげか、Pythonもだいぶ手に馴染んできた。 よいことだ。ようやくPerlから卒業できたと宣言してもよいタイミングに なったのかもしれない。Perlなんてここ10年ほとんどいじってないけど、 それでもスクリプト言語で一番利用時間が長いのはPerlという状態が 続いていた。
_ 平日に走るのは実に久しぶりだ。そしてMy Tracksの記録が途中で止まっていた。 GPSのシグナルがとれなかったのかしら。こんなことは初めてだ。 まあ最近無線通信もうまくいかないときがあったりするので、 いよいよ寿命なのかもしれない。
_ 箱根駅伝を見たり寝込んだりしたのがつい先月のことのように思えるが 気付いたらもう年末だった。
_ バイナリデータをいじるのにちょっと苦労した。このあたりのことをやるときは やはりErlangに手が伸びがちだ。
_ キョート編の2冊目まで読んだ。ここまで惰性で読んできた感じだが、 アマクダリ・セクトが出てきたあたりから俄かに面白く感じられてきた。 ここに至るまで2000ページ以上読んでいるので、自分の中では ひどい立ち上がりの遅さだけど、まあ面白ければよいだろう。
_ ようやく疲労困憊のループから脱することができたようだ。 先週きちんと土日休んだのも大きいのかな。といいつつ今週は土日とも出ていて 世話のない話だが、さすがに仕事が詰まりすぎて自分がボトルネックになっているのが 明白なので仕方がない。
_ ジョンと5kmほど。今日はあまり寒くないので快適だった。
_ 今週は残業少なめで推移する予定。
_ Firefoxが常にCPUを25%前後使っている。アドイン類を無効にするセーフモード的なことをすると解消するので、 どれかのアドインが悪さしているのだろう。 「firefox cpu usage」で検索してみると、25%、50%、100%といった違いはあるものの、 FirefoxがCPUをたくさん使うという話がたくさん出てくる。 要するにコア1つ使いきっているという話なのかなあと思う。 こまったもんだ。
_ 先日体調崩してから酒を控えるようにしている。が、飲みたい。ので、 少し試してみると体調が悪くなる。やはり本調子ではないらしい。
_ こんな夜更けにバナナかよの著者の新刊。
_ この人はすごいな。身を削って取り組んでいる様子が素朴で力強い文体で迫ってきて 圧倒される。相手に向ける眼差しは暖かいものばかりでなく、自らの 予断や失望や肩入れ、それから、話を聞いてまわるにつれ深くなってゆく迷いなどを隠さない。
_ そしてインタビュー相手との交流を読んでいるとものすごく居心地が悪い。 疎外感、他所者に対して警戒心を隠そうとしない。 居心地が悪く感じるほど臨場感があるということなのだと思う。 私が普段生活している空間でこんな性質をむきだしにしていたら とても生きてゆけないと思うが、こういう土地では自然に獲得される性質なんだろうと思う。
_ 「無人駅」は話のきっかけでしかないようで、 それよりも、無人駅となってしまった駅の周辺の人達の暮らしやそこから 生まれてくる疑問をひとつひとつ追ってゆくということに心を砕いているようだ。 それは実際「あとがき」にも明記されている。
_ 以前は電車を動かすのにもっと人手が 必要だったという当たり前のことに今更気付いた。 駅の「無人化」というのは、そういう人手がだんだん不要になって、無人でも 運営できるという前提があってのことなのだな。 幼少の頃に地方にいなかった人間としては あまり想像ができないことだった。
_ いろいろのっぴきならない。
_ 小さくて軽くなった。軽さは原著ほどではないが。
_ 旧版は5回くらい読んでいるし、原著も2周くらいしているので流し読みした。 流し読みした限りでは今までと大きく変わったものは発見できなかった。
_ のっぴきならない、っておもしろい語感だよな。起きていることはまったく面白くないが
_ GLSL SandBoxを見て、 少しのコードで複雑で派手なことができて楽しそうだなあと思ったので 自分でもやってみたくなった。
_ GLSL SandBoxはネットにつながってないと使えないのかな。 そうでないような気もするし、 GitHubにソースが 上がっているようなので、たぶんどうにでもなるんだろうけど、 まあそれに近いアプリケーションを練習がてら作って、 そこでGLSL遊びをすることにした。
_ GLSL SandBoxでいじっているのはフラグメントシェーダというやつらしい。 フラグメントシェーダだけでこんだけいろいろ遊べるのか... すごい。 OpenTKのサンプルコードをベースに GLSL SandBoxに上がっているGLSLを表示できるように取り組んだ。 timeとresolutionとmouseはアプリケーション側から渡すらしい。 なるほどシェーダというのはこういうふうにできているのか。
_ 久しぶりのOpenGLなので多少詰まったがなんとか動くようになった。 mouseの座標入れるのは面倒なので後まわしにして、 timeとresolutionを入れるだけ。ほとんどのサンプルはだいたいそれらしく 動いている。 i-saintさんのraymarchingのサンプルも動いている。
_ なおGLSL ESは互換性問題に悩まされるらしい。Android使っている人は大変らしい。
_ 動いた、よかった、ではいじって遊ぼう、と思ったら、 GLSLで簡単2Dエフェクト << demoscene.jp にある「フィードバック効果」が うまく動かないことに気付く。backbufferというものの存在を知る。 前フレームのテクスチャが入っているのか。 30分ほど格闘してみたが期待通りに動いていない。 GLSL SandBoxのソースを読んで考えなおすことにする。
_ 満足度の極めて低い本だった。 分からないことを分かるようにさせるという意思が伝わってこなかった。 シェーダとは何なのか、なぜvertexとfragmentの2つがあるのか、 何ができるのか、といった説明がほとんどない。 後半の「第2部」にそういう説明が入っていて、なんだこっちを先に読んだほうがいいのか？と思いきや、 やはり説明が十分でなくて分からないことは分からないままだった。
_ ソースが毎回「全て」が再掲載されている。 C++側の、下請け関数的なものもふくめて全て。フラグメントシェーダをちょっと いじっただけなのに、C++側も含めて全て再掲載されている。したがって 大量のソースの中にちょっと説明があって...という繰返しなので 説明の密度も極めて低い。
_ 他の資料を読んでおおまかなところを理解してから再度読んでみると、 そういうことを説明しているんだなあということは分かるようになってきた。 それを分からせるための本なんだろうけど、私には無理だった。
_ なお、この本は「都立図書館」の蔵書らしい。他区の図書館から借りたことは何度もあるけど、都立図書館は初めてだな...
_ GLSL SandBoxのソース眺めながらリファクタリングしたりしつついじっている。
_ GLSL SandBoxの主要ソースはindex.htmlの中にある。 最初はEmacsで開きつつ見ていたのだがインデントが深く折り返しがはげしいので MonoDevelopの中で見るようにして、タブの切替が億劫になったのでFireFoxのソース表示で見るようにした。コードハイライトはしてくれないみたいだが さほど不自由ではない。
_ そしてindex.htmlをFireFoxで表示させたら普通に動いていることに気付く。 コード変更したらきちんと反映されるし。なんだこれでいいじゃないかという 気持でいっぱいだが、まあ自分でフラグメントシェーダ遊びをするためのお膳立てを 理解しておくことは今後必要になることだろうと判断して気にせず進めることにした。
_ 以前作った、Zxingで映ったバーコードを ISBNとしてamazonに投げて結果をとってくるというアプリ (C/S) を久しぶりに 使おうとしたらうまく動かなかった。
_ 戻りの中にエラーメッセージがはいっていて、見てみると 「AssosiateTag」なるものが入ってないと怒られている。どうも呼び出しかたが 変わったらしい。
_ しかしもう2年半も前のことなのか。時間の流れの速さに眩暈がする。それはそれとして 動くようにしないといかん。
_ 以前書いた通りあほみたいに虹色アイコンが 出続けて音量変えるのに30秒かかるMacBookのメモリを増やすことにした。 いろいろ調べてみたらかなり簡単そうなのと、新しいOSが出たらPCごと 買い換えてしまおうと思っていたのにOSは無料だし新機種は出ていないしということで あてが外れたので、もうしばらくMacBookにがんばってもらうことにした。
_ 親切なドキュメントがあるのでそれに従う。 ノートはキーボード外したりいろいろしないといけない機種が多いのに対して、 MacBookは裏蓋外すだけでメモリとHDDが露出するのでとても楽ちん。 20分足らずで終了した。2GBから一気に4倍の8GBに。
_ 効果は絶大で、メモリの余裕ができたのは勿論、全体的に「現在非使用中」の メモリの回転がよくなっているように思う。結局メモリ管理の戦略がおかしいのではないかという気持が晴れることはないが、 もう2GBでどうにかなるという時代でもないのかもしれない。
_ 余勢を駆ってMarvericksに上げた。アップデートにえらい時間がかかったが作業自体は特に問題なく進む。 sshで入れなくなって焦った。どうやら最近はauthorized_keys2というのは 使わなくなったらしい。sshd_configを見て知った。 authorized_keysに名前を変えたらうまく行った。
_ Macは不足気味なので、重すぎて倉庫行きになっているiMacも同じように メモリ増やしたりしてみようかなと思う。 親切なページを見る限りではそんなに難しくなさそうだし...
_ 以前試して挫折した件をもう一度試してみた。 「Switch!」を通勤電車の中で聞きながら読もうとすると5往復以上かかるので さすがにもうちょっとスピードアップしたくなってきた。といっても30%以上速くすると 音質的にも聞きとりづらくなってしまうので、 スピードアップしてもせいぜい1往復分くらいしか浮かないけど。
_ で、やはりうまくいかない。rbpitchはビルドはできるんだが使おうとすると落ちてしまう。 rhythmbox-scaletempoはプラグインとして認識されている気配がない。
_ 30分ほど格闘して、英語を聞くときだけは別のプレイヤーにするかなという気持に なってきた。紆余曲折の末、foobar2000とfoo_dsp_soundtouch.dllを Wineで動かすことにした。結果は非常に良好だった。最初からこうしていればよかった。
_ さすがにWineの中で動かすのはしんどいようで、裏でいろいろ動かすと音が 途切れたりすることもあるが、英語を聞くという用途を考えれば特に問題ないだろう。 同様に、設定の問題かフォントの問題かは判然としないがタグの 日本語が盛大に文字化けしているという問題もあるが、これも英語を聞くという用途であれば特に問題ない。
_ foobar2000は初めて使った。なかなかよくできているなあ。初めて使う環境が Wineというのもなかなかすごい話だ。今はWindows環境でもiTunesしか使ってないし、 それより前はkbMediaPlayerを使っていたように記憶している。 先日WinAmpが開発終了になるといったニュースが出ていたがWinAmpって使ったことないんだよな。 x11amp→xmmsは散々使ったけど。
_ Rhythmboxだとずっと昔に作ったMP3のタグが化けて表示されてしまうのに困っていた。 表題の環境変数でデフォルトのエンコーディングを指定できるらしい。 UTF-8はそれはそれで認識してくれるようなので、それ以外のときはこれ、といった ことが可能なようだ。したがってここにCP932を入れて読みなおさせることで うまく認識させることができるようになった。 リストに登録させるときだけ生きていればいい設定なので普段から有効に させておく必要は必ずしもないと思う。 とはいえまたリストを1から作りなおすなんてことをしたくなったときには困るので常に有効にしてもいいのかもしれない。
_ 昨日は妻が早朝から外出だったので一人で寝ていたのだが ジョンとつぼみは誰かにくっついて寝るのを好むので暑いし狭いしで とても寝苦しかった。身体から引き離してもすぐにくっついてくるし、 離れようとしてもすぐに寄り沿ってくるのでだんだん身体が動かせなくなってきて おかしなことになってしまった。うれしいが眠れない。
_ この本の存在は10年以上前から知っていた。確か橋本治と数人が対談している 記事か本か何かで読んだのだったと思う。 橋本治という人の本を初めて読んだのは「『わからない』という方法」で、 記録を探ってみると2001年7月のことだったらしい。
_ その後、西田さんの記述で久しぶりに存在を思い出して、 いずれ機会があったら読みたいとは思っていたが、復刊される気配も感じられず、 そのまま4年半が経過。老後になって読みたいと思っても手に入るのかしら？ とちょっと不安になってきた。ひとまず図書館で借りてみた。
_ 想像していたよりもずっときちんと編物の本になっていた。変な感想だけど。 そして文庫か新書を想像していたので思ったよりでかい本だった。イラストや 写真も豊富で、やはり文章がいかにも橋本治っぽくて面白い。 まったく肌に合わない人も多いような気がするけども。
_ 知らない人に新しいことを教えようとするときに見習うべきことが多いというのは 本当だった。これを読んでいる対象はこの文章を読んでいる瞬間に どういう状態なのか？ということを実に的確に把握しているように思う。
_ いろいろファンタスティックなことが起きている。
_ よく寝た。
_ 橘玲の小説。前作 (マネーロンダリング) の 登場人物も名前だけであるが出てきたりする。 読み口が軽いので1200ページ読むのに3時間程度しかかかっていない。
_ 無理にミステリにしなくてよいような気がとてもした。そのままでも面白いのに、 ミステリにしてしまうとミステリの出来ばかりが気になってしまう。
_ そのミステリの出来としてはあまりいただけない感じだった。よく言えば端正、 悪く言えば派手さがないという感じ。 ええっそうだったの!? という熱い驚きよりは、あらあそうなんですかーという 緊張感に欠ける驚き。これは前作でも一緒だった。
_ そして前作と似た手口を使っているので、分かりやすすぎるだろうと 思いながら読んでいた。さすがにまったく同じというわけではなく、 ひとひねり加えられているのは確かだけど、 ひねりというよりは二段構えにしただけとも言えるので、結果として受ける印象は あまり変わらなかった。
_ ミステリ云々を置いておけば、きちんと面白かった。 依頼者が租税回避に死力を尽くしている理由が 明らかになるあたりは迫力もあったし、ヒロインが救われてゆく様子には 心を動かされるものがあった。
_ 結局のところ、感想としては前作の感想の3段落目と同じということに。 読後の印象も悪くない。
_ どうしても乗り気じゃない仕事が残りがちだ。残った仕事は締切真近にならないと やらないので、結局ストレスフルな状態で作業することになってしまって、 それがフィードバックになってもっとその仕事が嫌になるというループ。