やっとというか名残惜しくもというか、最終話がさっき終わりました。
まず、「今期のアニメが全部ゴミに見える」っていうコメントには、ものすごく共感しています。一気見補正は実際にあるのですが、「魔法少女まどか☆マギカ」以上の名作で、今年前半に自分とはいったいなんだったのか考えてしまいました。まどマギよりも終わり方も展開もよかったです。前半は言われていたほど退屈ではありませんでした。そして、後半の文句をつけようがない出来。
SEEDみたいだと騙されてみてよかったです。
劇場版と外伝も観たくなりました。TSUTAYAに行ったら探そうかと思います。もう見るっきゃ無いです！（覚えていたらの話なんですけどね。（∀｀＊ゞ）テヘッ）
因みに見るにあたって、あんまりいいことだとは思っていなんですけど、Wikipediaで予習しました。この作品は予習しといてよかったと思います。予習しとかないとよくわからなかったところがとてお多かったはずです。
「大人がかっこいいアニメ」というコメントがいっぱいあったんですが、ホントにその通りでとても新鮮でした。あんなにいい大人は希少種らしいです。「日本沈没」もその例外の一つで、あんな大災害が実際に起きた場合、本の通りにはいかないとか。新国連は、相対的に悪く見えるのは仕方ないというか。でも、事務総長のワインを飲んでるところとかああゆうのは、なんか赦せないです。
溝口さんは、もう神がかっていました。もう伝説です。
さて、やっとこれで勉強に集中できます。(；´Д｀)

数学Ⅲ・Cやってるんですけど、全くわかりません。ノート（実際はルーズリーフ）が真っ赤です。もうよくわかりません。というか、気がついたらA,B,Ⅰ,Ⅱの範囲もよくわかってない気がします。とりあえず、やってみてどれくらいまでなるのか考えないとまずいです。

SquirrelはLuaと違って引数が無くても第一パラメータにコンテクストを指定しないといけないみたいです。なので、sq_callでは引数の数は1以上にしないと、"wrong number of parameters"になって悲しい事になります。実際に長い間なってました。(・へ・)
それから、Squirrelの標準ライブラリ（ http://www.squirrel-lang.org/doc/sqstdlib3.html ）にあるregister系の関数を使うときは、先にsq_pushroottable()しとかないとエラーになります。そして「sq_reseterror()って何？」レベルでエラーがそのままなので注意が必要です。
エラーハンドリングは、やっぱり難しいので頭の良い人にもっとうまくやる方法を学びたいです。orz

空耳はずっと嫌いだと思っていたんですけど、そうとしか聞こえなくなるともう開き直るしか無い気がします。「ここがそう楽園さ」が実際の歌詞みたいです。
蒼穹のファフナーで翔子が死んだのが、鬱系がこわい身としてはとてもよかったです！ 声優さんの気の抜けた声はちょっと浮いていましたけど、自爆ENDがとても鬱でした。脱出でできない兵器というのは｜ ゜Д゜｜ ノ　イカガナモノカと思うわけですけど、鬱系なのでもっと絶望的に脱出できないというはいいシチュエーションだと思います。

「アニメで読む世界史」という本を読んでいるんですけど、「母をたずねて三千里」の章で長年（実際はそれほど長くない）の疑問が解消しました。
アルゼンチンは、南米の国なので黄色人種がもっと多いはずだと思っていたんですけど、アルゼンチン人のサッカー選手メッシュは思いっきり白人です。なのでメッシュみると、いつももやもやしていました。
「母をたずねて三千里」の章で、１９世紀のアルゼンチン（主人公の母親がいる国）について解説があって、端的に言ってしまうと昔はヨーロッパからアルゼンチンに行く移民の人が多かったみたいです。その時のアルゼンチンは世界的にも豊かで日本よりも豊かだったとか。それで、主人公の住んでいるイタリアはまとまりが無かったり、まあ大変だったらしいです。そんなわけで、移民が多いってことはそこで子どもを授かる人も多いわけで、ヨーロッパの血がどんどん混じったのだと想像します。
そんなわけで、また一つ使われない知識が増えてめでたし、です。

ここ最近、Jenkinsのシステム設定が使えなくて困っていたんですけど、さっき解決方法を見つけました。
- http://jenkins.361315.n4.nabble.com/can-t-access-configure-page-after-upgrading-1-432-to-1-433-or-1-433-td3895116.html
によると、"Jenkins Slave Setup Plugin"を無効化すると元に戻るみたいです。たぶん、なんかのバグなんでしょうね。こうゆうのをサンドボックスでうまく守ってるソフトはうまいなーと思います。JenkinsもDebian系のパッケージも新しくユーザつくって悪い事しないようにしてるのも似たような機構なんですけど、如何せん大雑把なせいかカバーしきれないようです。
めでたしめでたし。

このページに書いてあった。
http://d.hatena.ne.jp/gnarl/20111122/1321938292

JenkinsのノードをJNLPで使おうとしたんですけど、GUIしかうまく動かせなくて困っていたんですけど、CUIの動かし方（というかslave.jarの場所）がやっとわかった（このページのおかげ: https://wiki.jenkins-ci.org/display/JENKINS/Distributed+builds ）ので、なんとか動かせました。ただ、なぜかビルドするノードが最後に接続したノードになって全部のノードでビルドする方法がよくわかりませんでした。
とりあえず、http://yourserver:port/jnlpJars/slave.jar にあるslave.jarをwgetして、ノードの管理画面に書いてあるコマンドを打てばいいみたいです。

「とらドラ！」でわたしが誰に似てるか考えたんですけど、川嶋亜美かなー？、っていうのが結論になりました。あんなに可愛くなかったり、頭も良くないし、察しも良くないんですが、一番わたしにしっくり来ると思います。そして、理想とする人は櫛枝実乃梨です。あの明るさとか、理由はいくつかあるんですが大きいのは川嶋亜美が嫌悪してた理由に近いものだと思います。
Fate/Zeroが配信されてて観たんですけど、ウェイバーさんの見せ所がBパートにあったのはよかったです。原作でも好きな場面でした。小物なのに妙に謙虚なところとか想像してた通りで安心しました。それと、ランサー陣営はどうしてああも不運なのかと頭を抱えるばかりです。最後まで不遇ですけどね！ セイバーの不遇は本編のヒロインだから仕方が無いというか、第五次聖杯戦争を待てな感じでした。
輪るピングドラムは、BLOOD-Cみたいで変に伸ばしてるのが少しツマラナイです。ピンドラは１クールくらいで、BLOOD-Cは一時間ずつの前・後編くらいでよかったのではないかと。一挙放送とかなら見たいかもしれません。

ニコニコで、「とらドラ！」の一挙放送があってタイムシフト予約したのを観ました。一応、観たことあるんですけど、改めて見ると前に観た時よりもよかったです。「生徒会長vs手乗りタイガー」は迫力があったと思っていたんですけど、ニコニコのコメントで騒然となっているのを見るとやっぱり面白いですね。
そして今日、蒼穹のファフナーが５話くらい配信されていたんですけど、こっちもよかったです。ちなみに、こっちはリアルタイムで見ていません。「鬱系こわい、鬱系こわい、鬱系こわい、鬱系こわい、鬱系こわい、鬱系こわい、鬱系こわい」ってずっと言い続けたいくらいいいですね、鬱系。
それから、今日は声優さんが大幅に変わったルパンでした。日テレなのにフジテレビが出てきたり、石田彰が安定していたり、作画がジブリの人でけっこう動いたり、まあ、色々あるんですけど、いいですね！ まだ、最後まで見てないんですが、じっくり観たいです。
最後に、「〜なんて怖くないもん」って言ってる人は、きっとホントに怖いんでしょうね。そうゆう人をあまり追い詰めないように気を遣う必要があると思いました。基本的に愉快犯なわたしには難しそうですけど。

luabindのdebug.hppのアイディアはけっこう好きなんですけど、デバッガ無いと使いづらかったので、なんか魔改造してみました。
びふぉー： https://github.com/luabind/luabind/blob/master/luabind/detail/debug.hpp
あふたー： https://github.com/take-cheeze/langbind/blob/master/nutbind/detail/debug.hpp
Squirrel用のコードになってるのは割愛して、まず、ただのassertだった場所についてです。
元のコードは、assertがdebug.hppにそのまま書かれているので、debug.hppにあるassertの位置をアサーションが失敗した時に表示してきます。これでは色々とだめです。事件は会議室で起きてません。なので、stack_checker_typeは肥大化しますが、マクロで取得した行番号、ファイル名、関数名をstack_checker_typeに記録しています。因みに、これは特別なメモリアロケータを使う時によく使われているテクニックを応用です。こうゆう時に役立つんですね。
次は、エラーメッセージについてですけど、折角比較しているのでやっぱりテストみたいに期待した値と実際の値を表示したいです。また、スタックに積まれているオブジェクトの型も比較しています。原理はstd::vectorにstackの型（enum）を積んで、デストラクタが呼ばれてるいる時に比較してるだけです。書いてて思ったんですけど、こうゆうメッセージの整形ってけっこう大変ですね。（参考画像１： http://twitter.com/#!/take_cheeze/status/139672460713930752/photo/1 , 参考画像２： http://twitter.com/#!/take_cheeze/status/139672323841212416/photo/1 ）
今回は、あまり経験がなかったデバッグ用のライブラリを書けて面白かったです。assert()だらけのソースコードはやっぱりよくないですね。

ちょろっと書きましたけど、Jenkinsをeasy-rpg.orgにインストールしてもらいました。URLは http://easy-rpg.org:8080/ です。
設定とかは、言い出しっぺのわたしがしたんですけど、パッケージのインストール（超絶めんどくさい）はサーバの管理人さんにやってもらいました。で、なんとかビルドできています。SCMのポーリングは、一時間おきにしてみました。一応、自分でやった経験が役に立っていますよ。
それと、easy-rpg.orgのサーバ構成みたいなのをちょっと聞いたんですけど、VPS羨ましいです。まずは、それです。＄4.5/monthらしいですけど、さくらVPSとかKDDIがやってるのよりも、リーズナブルな気がします。一概に比較はできないんですけど、CPUはけっこういいやつらしいので、速かったです。4コアなんてわたしのマシンではちょっと無理だと思います。
それから、自分の立てたサーバだと使うのに気がひけていたJenkinsのIRCボットも使ってみました。最初はあまりうまく動いていなかったんですが、設定をガチャガチャやってたらなんかなりました。freenodeの#easyrpgにニックネームeasyrpg-jenkinsで常駐してます。"!jenkins help"で、使い方をみてみたんですが、想像していたよりも色々なことができるみたいです。まだ、よくわからないので、IRCボットにユーザ権限は与えていないんですが、また機会があればつかってみたいと思います。
さて、これで自分のところのJenkinsがあんまり要らなくなった感じです。プラグインHellしてるのでかなり消したいと思っています。他にもビルドしてるプロジェクトがあるので、しないと思いますけどね。

termをちゃんと設定すれば、emacsもちゃんと使えることがわかったので、ちょこちょこ試してから、
chsh -s /usr/bin/screen
でログインシェルをscreenにしました。サーバの接続を切っても、簡単に再開できると評判だったので、ちょっと遠いリモートからのsshの時に使う時にはこっちの方がいいかなと思ったので思い切ってやった感じです。メインマシンのは流石にちょっとこわいんですが、仮想マシンならこうゆうの気軽にできていいですね！
こうゆうのを毎回使うたびに思うんですが、$TERMの設定で毎回必ずコケてる気がします。もっと自動的にやってほしいです。
tmuxというフォークがあるみたいですけど、screenとの互換性がもっと高ければ使いたいなと思いました。横分割も羨ましいんですが、screenの方がまた分がある気がします。

因みに現在の~/.screenrc:
term xterm-256color
shell /bin/zsh

startup_message off
altscreen on
autodetach on

bindkey "^T" focus

<< EOF

「Jenkinsの管理」で「シャットダウンの準備」はあるんですが、再起動する方法がないので困ったのですが、プラグインのインストールなどをしていた時にとあるアイデアが閃いて使えたのでメモです。
ここでは、例として今日、開通させてもらったeasy-rpg.orgのJenkinsを例として使います。 "http://easy-rpg.org:8080/" にあるJenkinsを再起動させるには、/updateCenterすなわち "http://easy-rpg.org:8080/updateCenter/" にアクセスして「インストール完了後、ジョブがなければJenkinsを再起動する」をチェックすると再起動します。本来はプラグインのアップデートとかインストールに使うものみたいなんですが、そうゆう状態でなくとも素でアクセスできるようです。
近い未来で、脆弱性になりそうな気がしますけど、なかなか使えるなと思いました。

Squirrelで最近、遊んでるんですけど、HSQUIRRELVMをunique_ptrで管理できないかと思いたち、実際にできたので、メモしときます。
コードは↓な感じです。想像以上に長くなりました、はい。STACK_SIZEは1024とか4096とか適当な定数です。深い意味はありません。
"std::unique_ptr::type, std::function> vm(sq_open(STACK_SIZE), sq_close);"
まず、unique_ptrでの肝はstd::functionです。最初は、関数ポインタ（sq_closeの）をそのまま渡したんですけど、コンパイルできなくて、ググったところどうも関数ポインタは受け付けないそうで。なので、std::functionに出てきてもらって、見事解決！です。std::functionはよく見かけていたので、特に使い方に迷いませんでした。
次に、「typedefは時々お節介ですね」というお話です。別に、ヘッダをgrepして定義を見てもいいんですが（最初は実際に観ました。struct SQVMみたいな名前だった気がするんですが、struct付けるの怠いです。C++なので別にいいんですけど）、それはそれで仕様が変わった時に困るので、type_traitsを使ってポインタのtypedefから型だけゲットしました。"::type"を忘れたなんてしょーほてきなミスはしなかったわけでもしたわけでもしたかもしれないかもしれませんが、それはさておき、やっとtype_traitsさんの使い方がわかりました。ありがたやー。
で、まあ、これで終わればよかったんですが、HSQUIRRELVM以外に、HSQOBJECTというオブジェ（クト）があります。そして、どうせならこれも、C++（標準のスマートポインタ）で管理したいと思って少しだけ妄想してました。結論は、HSQOBJECTはポインタじゃないのでデリータに載せるとかそうゆう方法を使わないと無理という判断で、やめにしています。時前で構造体を書くのはめんどくさいです。ヘッダにしたとしてもutilityなんて敗北宣言にも等しいところに置かれるのが関の山な気がします。

家にHEROESのDVD Boxがあったので、最後のシーズンを見て最初のシーズンから見ました（漢文みたいな順序なので、ちゃんと書くと４→１→２→３って順番です）。勉強があるのに、そんなことしててもいいのかと聞かれると、「BGMだから大丈夫だもん（汗」です。
「贖罪」は、元ダース・モールさんがかっこよかったです。それ以外は、特に印象に残ってない気がします。ヒロが突然治ったのは、(´･ω｀･)ｴｯ?な感じだったり、ラスボスが小物であまり盛り上がらなかったり、まあ、いろいろある気がしますけど、それはなかったことに...。なんというか、蛇足でした。いっそ、スピンオフにと思います。
シーズン１は、思ったよりも長かったです。テッド（主に放射線を出せる人）は能力だけ長寿でしたね。それから、伏線のはりかたがうまいなーととても感心しました。
シーズン２は、マトリックス・リローデッド的な位置付けな気がします。剣聖武蔵編は、面白かったです。マシ・オカは和服を着てたのでお腹が気になりませんでした。わたしも見習って肥ったら和服にしようかと思います。今回の危機については、バイオテロってなんか地味な印象なのであんまり危機感をお裾分けいただけなかったです。（両親が医療関係者だっていう影響もあるかもしれません）
シーズン３は、前半がよかったです。ペトレリ家の壮大な家族喧嘩なだけな気がしますけど、父親のラスボス風格はとても(・∀・)ｲｲ!! ペトレリ父は最後にあっさりやられちゃうのが残念ですけど、最高の敵でした。それから、アダムのギャグにしかならなかったところも、別の方向で最高の敵でしたね。前回のラスボスがあんな雑魚に見えるなんて、いい演出です。ヒロとのやりとりもボスとは思えないほどギャグでした。
シーズン３の後半は、消化試合みたいで、観てて物足りなかったです。ペトレリ父に全てを持っていかれたといいますか、消化できる伏線がもうほとんどない失速感といいますか。ただ「反逆者」の意外な正体は、意表を突かれました。
最後に、サイラーはメイン・ヒロインではないかと思うくらい、特殊なキャラでした。ダーク・ヒーローさは、この作品で一番だと思います。最後まで殺されなかったスタッフは、偉大です。何度、死んでしまえと思ったことか。でも、シーズン３・４でのデレはとっても可愛かったです。「贖罪」でサイラーを更生させたのは、とても評価できます。
っと、まあ、そんな感じです。こうしてちゃんと見てみるとスーパードラマTVで見てた時とは違いますね。特典映像はそんなに見てないので、また、時間を見つけたら見たいと思います。（もちろん、BGMとして！）

続いて、ハリー・ポッターです。昨日、Blu-ray Boxが来たのでYear 7だけ観ました。
内容ですが、原作は既読でしたが半分以上忘れてました（一度読んだことを忘れないような才能が望まれる限りです）。ただ、マッドアイの魔眼がどこにいったのかとか余計なことは少し覚えています。
ヴォルデモート卿を見て思ったんですが、悪役にはもっと崇高な野望とか、嫌なヤツだけど人を惹きつける魅力とか、決してDQNだけじゃないところが欲しかったです。でないと、この人、魂を裂かれるような（実際に裂かれていますけど）思いをしてまで何をしたかったのか巨大な疑問が渦巻きます。
それくらいです。７年分、全部見返すのはちょっと怠いので、やめときます。

バッテリーの持ちが良くなると聞いて早速やってみました。
とりあえず、iTunesにつないで、アップデートの確認を押して、1GB未満のアップデートファイルをダウンロードしてインストールできました。本体の更新よりも、ファイルのダウンロードのほうが時間がかかった感じです。
感想は、・・・特に無いです。あんまり変わった気がしません。たぶん、バグフィックスとかソフトウェアのマイナーな改良しかやってないんでしょうね。0.0.1変わったくらいで、ガラっと変わったら逆に困ります。
たまたま、KindleにAppleのハードでAndroidを動かすプロジェクトのスライドが入っていたので読んだのですが、脱獄必須だったので動かす方向にはそこまで興味が沸かなかったです。ただ、ハードウェアそのもののリバースエンジニアリングは面白そうでした。
それと、そのついでに入っていたIceRobotのスライドもそこそこ真面目に読んだのですが、Appleで言うともしもOS XとiOSを統合したらという仮定でのお話みたいで、将来性をとても感じました。折しも、今日Apache Harmonyが終了する話を聞いたので、さらに将来性を感じます。ただ、GNUのライセンスの制約はあんまり好きじゃないので、その点では微妙かもです。

そういえば、ワールドカップ予選のタジキスタン戦を観ました。前半だけ観たのですけど、事前に聞いてたグラウンドの酷さは、選手のプレイがよかったのか、よくわかりませんでした。タジキスタン側から何度か放たれたシュートはこわかったんですけど、結局守りきったそうです。
相手はカウンターしか攻撃手段がなさそうな感じだったので、一点くらい返せたのかな？と期待していたのですが、そうゆうことはなかったようです。日本代表強いですね。（イマサラ

CMakeの${EXECUTABLE_OUTPUT_PATH}や${LIBRARY_OUTPUT_PATH}には、${CMAKE_SOURCE_DIR}系を使っちゃいけないことにやっと気が付きました。代わりに、BINARYがついているの変数を使ったほうが色々と楽です。
理由はいくつかあるんですが、ビルドしたファイルを消しやすい、のが一番かもしれません。ソースコードは消したくないけど、ビルドしたファイル（ライブラリ、実行ファイル、etc.）は邪魔なので消したい時があるんですけど、Gitに頼りつつ消すのは正直めんどくさくて、ビルドディレクトリごと消せた方がはやいです。LLVMは、そうゆう事情でソースコードとビルドのディレクトリを分けないといけないんだと思います。ああゆう大きなプロジェクトではそうゆうことは手に負えないのでしょう。(；´Д｀)
それと、CURRENTが付いている変数もあまり使わない方がいいですね。ソースコードの参照の時は、いいんですがOUTPUT_PATHで使うとビルドしたファイルを消す時に、分散されて消すのに手間がかかるようになります。なので、${CMAKE_BINARY_DIR}/binとか${CMAKE_BINARY_DIR}/libに出力した方ががっと消せますし、Jenkinsで成果物を保存するとき、指定するファイルをワイルドカードで選択するのがずっと容易です。テストもその方が結果ファイルを集めるのが楽ですし、どこにあるのか迷わずに済みます。
っと、まあ、またビルドシステムをいじっていて特に進まなかった報告でした。

昨日は、ビルドできないプロジェクトを脱却するべく、glsl_typeっという車輪の再発明もはなはだしいプロジェクトのビルドを通してました。glsl_typeとは、...簡単に言ってしまうとGLSLで使えるデータ型をC++でも使えるようにするヘッダオンリーなライブラリです。ソースコードは、githubにおいてあります。ちなみに、速度とかSIMDとかそうゆうのは、気にしたいのですが、どうにもわからないので放ってある自己満足なライブラリになっております。
それで、なぜビルドできていなかったかというと、Boost.PPの使いすぎでコンパイラのチェックすら通過していなかったのです。原因はいくつかあるのですが、まず、クラス定義をPPで生成しているおかげで、エラーの箇所が全くわからないので、エラーメッセージの文脈から大体の場所を推測するしかありません。そして、使っているコンパイラにも問題がありました。
clangはメタメタしたコードやPPピーしたコードのコンパイルエラーを直す時にあまり役に立ちません。親切が仇になっているというのでしょうか？ デフォルトで設定では、表示されるエラーの数は少ないですし、エラーひとつに何行ものご親切な解説がつらいです。それに比べてgccは、すっきり・最小限・デフォルトでエラー数の上限なしの大変不親切仕様ですが、PPピーやメタメタしたコードの時は、大量のエラーを俯瞰することが大事なので大変役に立ちます。（それから、システムの都合でC++11のライブラリが動かしやすいのはとてもいいですね！）
っと、まあそんな感じで、ビルドシステムを通さずにgccでコンパイルをした時の方が幸せでした。clangのエラーメッセージが天使に見えていた時期がわたしにもあったわけです。今はどちらかというとお節介かもしれません。コンパイラにも渡したフラグについてもけっこうウルサイですし。それと、PPピーした時は列が4桁になるなんてこともあるので、右端で折り返す設定になってるときは、どこがエラー箇所なのかホントにわからないです。
最後に、エラーを取り除き終えた時には全く無意味なことをしていたと時間を浪費したと後悔しました。C++こわいです。
orz

Instapaperをブラウザから使っていたんですが、ついこのあいだ有料版を買って、今まで「っぺ」と蔑んでした有料版が、ブラウザ版を「っぺ」と蔑む理由になりました。使い勝手が全く違います。
まず、オフライン機能がついているのは大きいです。いくらiPhone 4Sが3G回線につながっていると言ってもネットワークを使うとどうしても遅くなることがあります。
そして、カユイとこに手の届くネイティブアプリケーションならではの（？ iOSやHTML5の詳しい仕様は知らないです）機能もいっぱいありました。ブックマークレットの登録方法もいくぶんか親切です。
ただ、ブラウザ版でも満足してたのは事実で、Instagr.amのように特定の環境からしかアクセス出来ないなんてことはないのは、今でも満足しています。Web版は、こういったアプリケーションに用意する基本的な備えとよく聞くのですが、こうゆうのをちゃんと守っているのはGJです。

Instapaper（＾ω＾）ペロペロ。