スクールアイドルです

冷やし中華はじめました

「また新しいフレームワークかよ」と言う人へ

「フレームワーク」を「プログラミング言語」や「アーキテクチャ」に置き換えてもよいです。技術を点でしか把握せず、APIの羅列を単純に丸暗記しようとして破綻してるパターンが多いように思われます。API丸暗記は負担のかかる作業なので、これを毎回繰り返すとあるものを一生懸命覚えている間に他のものが出てきてスピードが追いつかなくなります。

技術開発とは大体の場合において、設計者が以前困ったことや他技術からの影響、既存の技術に対する反発を動機として生み出されます。強い動機を持って生み出された技術は、コンセプトから設計、実装に至るまで動機が色濃く反映されます。素晴らしいことに人間の論理的推論能力は他の人間にとっても再現しやすいので、利用者がコンセプトから推理可能な範囲に、実装の大半は集中していると考えてよいでしょう。

この認識を持てば、単なる実装の羅列が、多くの推測可能で知的負荷の発生しない「驚きのない実装群」と、少しの推測不可能で知的負荷が高い「驚きのある実装群」に化けるということになります。極端を言えば、常用しないのであれば「驚きのない実装群」は必要に応じて参照する程度でもなんら問題ありません。コンセプトと「驚きのある実装群」、いわゆるはまりポイントだけに注意を払えば、支払う知的コストは小さいまま技術を習得できるということになります。

厄介なのは、いわゆるハウツーや小ネタだけを延々写経しても、ほとんどの場合このような理解には至れないという点にあります。点で得る知識は他と結びつけづらく、その場限りで消費されてしまうことが多いです。本当に右も左も分からない状態であれば十分に有効な学習手段ですが。

いくつか習得すれば、時系列順に並べてコンセプト間の関係性を一貫性のあるストーリーにすることができます。つまりは現実における歴史と同じように、「影響」や「反発」などの関係性を用いて説明できる歴史を自分の中で構築するわけです。自分の中でその技術に関する歴史を構築することで、次に習得する技術とそのコンセプトを関係性の中に取り入れ、定着させる素地が出来上がります。この歴史というのは習得スピードを上げるためのものなので、別に間違えていても、人に教えたり押し付けたりしない限り問題はありません。間違えていた時はさっさと撤回しましょう。

ここまで読んで「何を当然のことを」と思った方は正解です。人間は意識せずにこういう理解の枠組みを構築できるので、意図的にやればより効率的に理解できるという程度のことです。

Jest流行ると辛そう

なぜJestが全てをモックできるのか - Qiita

Node.js - FluxをJest以外でテストする - Qiita

Jestの「デフォルトで全てがモックされる」というコンセプト自体は素晴らしいと思う。ただ、

  • Node 0.8, 0.10でしか動作しない
  • Jasmine 1.3
  • jsdom 0.10
  • 全体的にちょっと古い
  • JasmineとJasmineのmatcherにロックインされる
  • testRunner書けばJasmine以外も使えるけどそこまでして使いたいか？
  • 肝になるModuleLoaderが1年ほどリファクタリングされず放置されている
  • sandboxの生成コストが大きい
  • sandbox内で実行していることを意識できない

など、このまま徐々に負債になるか、メジャーバージョン上げて負債ごとばっさり切り捨てられる予感がする。何よりReact.js, FluxのテストはJestでないとできないというわけではないので、習熟するだけ徒労に終わりそうだと感じた。

個人的には使い勝手の良い（≠枯れた）ものの最新版を組み合わせて使うことをよしとするので、最初から全部入っていてなおかつ微妙に古いJestはあまり魅力的に見えなかった。

真冬に水着を着ることについて

やんごとなき理由により年の瀬の東京ビッグサイトで水着を着ていた。所謂コスプレ。

年の瀬の関東なのでだいたい気温1桁だったけど、日照もあって本人は至って平気だった。本人以上に見ている側にとっての方が寒々しく見えるらしく、方々から「寒そう」「寒そう」と聞こえてきた。

本人は寒さのことよりヌーブラが剥がれないように押さえることに必死で、胸の谷間のポジション修正に執心していた。もう1枚ヌーブラ貼ればもっと盛れたはずなので次への反省点とした。ヌーブラは値段と粘着力が比例関係にある気がする。

そのほか、平時と比べてカメラマンに呼び止められることが多かった。水着だと被写体が三十路直前だとか季節が真冬だとかその他もろもろの事情を差し引いても撮りたくなるらしい。人の視線を集めるためにより過激な服装を選ぶようになる心性をわずかながら理解できた。

結論

水着で真冬屋外1時間より、2週間前の物販で屋外5時間の方が圧倒的に過酷だった。

ライブ参加などを目的に宿を大人数で借りる知見

μ's Go→Go! LoveLive! 2015参加組で旅館借りた。会場まで30分程度の地点で、土曜日宿泊が13人、日曜日宿泊が8人。前日泊はなし。初日は大部屋と4人部屋2部屋、2日目が4人部屋に連泊する形式だった。

基本は集団旅行となんら変わらないのだけれども、目的が目的なので集団旅行とも若干都合が違っていた。要点をメモ程度に残しておく。

モノと金の管理がガバガバになる

ガバガバになるというより、集団メンバーの中で一番管理能力が低い人間のレベルに固定される。メンバーの中でおそらく管理能力最低なのが自分で、服脱ぎっぱなし荷物置きっぱなしなので部屋全体が荒れ放題になっていた。連泊した部屋に掃除で仲居さんが入った時瞬間的に片付いたけど、数分後にはほぼ元どおりといった状況だった。

同じ趣味の人間が集まるので、必然的に同じグッズを持ってきて持ち主不明になる。OPENちゃんトートバッグが3つにNアンダーバートートバッグが2つあって、いちいち内容物を検分しないと誰の所持品かわからなかった。「次は個人の物品を管理するのに各人折り畳みコンテナ持参な」と言っていた。

シャツなども同様で、この季節はだいたい全員がヒートテックを着ている感じなので、割とカオスだった。物販が長期戦になることを覚悟してタイツ履いて来たはずなのに、帰るときには生足だった。誰かが取り違えてる気がするけど、そもそも履いて来たかどうか自体もあやふやなので特に気にしていない。

資金管理も割とガバガバで、宿代に加えてチケット代の貸借、移動の際のタクシー運賃分担、部屋飲み用の買い出し費用分担、「ついでに買っといて」などで記憶を頼りに精算していた。それでも特に問題発生しなかった点については、全員そこそこ気心知れたメンバーかつ社会人だったことが最大の理由だと思われる。そうでなければここまでガバガバの宿をやってはいけない。

移動開始宣言から実際の移動開始にタイムラグがある

主に深夜30時前後まで呑んだくれてたのが原因だが、とにかく移動開始の宣言と実際の移動開始に1時間近い開きがあった。

  1. そろそろ行くぞ
  2. ごめん忘れ物してたわ
  3. 忘れ物探している間に他のメンバーが雑談始める
  4. ひとしきり雑談して最初に戻る

上記の流れを無限に繰り返している間に、待ち合わせがある人間だけ移動開始した結果、予定の立っていない人間が開場時間過ぎても部屋でくつろいでいた。時間に追われる現代人にとってとても貴重な経験になった。開演時間という概念がなければエターナっていたことだろう。

もちろんチェックアウト時刻も遅ければ遅いほどいい。それでもチェックアウト1時間ぐらい前から部屋出るぞ部屋出るぞ連呼しないと間に合わない。

行きより帰りの方が荷物が増える

今回の目的はライブだったので物販だなんだで荷物は増える。しかし問題はそこではなく、部屋呑みの残りものを分配することで荷物が増えることにある。

部屋呑みなどの目的で買い出しを行う場合、不足して再度買い出しに出る手間が発生しないよう、多少余ってでも満足する量を最初に買っておくことになる。当然参加人数や諸々の条件からある程度の精度で必要量を見積もることは可能だが、参加人数が膨れ上がることにより予測と実際の消費量の間にあるぶれは大きくなる。そしてそのぶれは余った酒ツマミという荷物として分配される。

荷物は可能な限り少なくするか、荷物が多くなったとしても収納に余裕のあるカバンにしておかないと破綻する。した。

それを抜きにしても、観光旅行でもないので不足品があっても最悪近所で買えてしまう。持っていくかどうか迷った場合、持って行かないほうが正解である。というか、なぜ物理サーバと有線キーボードを持って行こうとしたんだ自分。

大きい方のトイレはフロントにあるやつを使う

個人的な要望。あと部屋に備え付けのものよりフロントのものの方が機能充実してる気がする。

結論

インフルエンザ集団感染のリスクもあるので、手洗いうがいはきちんとやる。私は日曜日深夜にウイスキーで消毒したので事なきを得た。

Rubyにパッチが取り入れられた（およびその過程）

Fail to break from a block with nested begin-rescue by MisumiRize · Pull Request #820 · ruby/ruby · GitHub

単純なバグフィックスだけど無事取り入れられた。CはK&R本で教養程度にしか覚えていない。

毎日trunk, masterをビルドする

毎日trunkの最新バージョンをビルドする。板前が朝に包丁を研ぐように、ミュージシャンが演奏ごとに楽器を調律するように言語処理系を継続的にメンテナンスする。いかにtrunkといえど２、３週放置するとバグに気づいてもすでに修正済みになっていたりする。

実稼働環境と同じに揃える必要があるなど特段の理由がない限り、このtrunkビルドを常に使う。おおよそのエッジケースはテストでカバーされているので、普通の人が頭をひねった程度で出てくる例はすでにテストされていると考えてよい。なので実際にgemを使ったりアプリケーションを動かしてみて、「まぐれ当たり」を引けるような使い方をしている。

あとどの言語でも最新バージョンに追加された機能周辺は他と比べテストの網羅性が甘く感じることが多い、組み合わせにより思わぬバグが出てくることがある。あった。

同じ環境の安定版と動作を比較する

要はxxenvを使う。「まぐれ当たり」を引いて意図しない挙動が発生した時に安定版と切り替え、原因を特定していく。その際、観測に影響を与えるコンパイラやミドルウェアの違いを排除するために、同じ端末に同条件で複数バージョン保持できて、なおかつビルド、インストールコマンド入力の手間を省けるxxenv, xx-build系は欠かせない。

動作がおかしいからといって即gdb使おうとしなくても、xxenvにprintデバッグとブレークポイントからのステップ実行を組み合わせることで、ある程度問題自体を理解することはできる。今まで即gdb使わないと解決しないレベルの問題にぶち当たったことがないから、そう言えるだけかもしれないが。

結局言いたいこと

どれもしっくりこないのでいいphpenv系を教えてください。今はphpbrewとphp-buildを組み合わせて使っている。

Haxe書いてた際の成果物

haxelib newコマンドが追加されていた - Qiita

いろいろあって年末年始はHaxeを書いていた。 本当はHaxeからJavaScriptへのコンパイルについて調査するつもりだったはずが、開発環境周りであれがないこれがないと言っていろいろ作った。

RubyにおけるGemはあれどBundlerが見当たらず、ライブラリをインストールするとすぐにディレクトリがゴミ箱のようになるのが気に食わなくて、それを回避する方法をひたすら探していた。

hxenv

MisumiRize/hxenv · GitHub

rbenvとかplenvと同様、haxe, haxelibのバージョンを管理するツール。使い方はrbenvと完全に一緒なのでrbenvの使い方で調べたら使える。

haxe-buildは用意してない、公式ビルドを拾ってきてexpandしたのをversionsの下に放り込んで、systemをHEADにして切り替えて使っていた。

$ tree -L 3 .hxenv
.hxenv
├── shims
└── versions
    └── 3.1.3
        ├── haxe
        ├── haxelib
        └── std

4 directories, 2 files

haxelibが~/.haxelibを見ているので、使うバージョンを切り替えるごとに~/.haxelibをガチャガチャ触る行儀の悪い仕様になっている。お気をつけください。

halc

MisumiRize/halc · GitHub

CLIツール作成ライブラリ。Haxe版bundlerを作ろうとした時の中間生産物。

Golangのcodegangsta/cli · GitHubのような感じで書けるように作っている。実際の使用例は後述のtsuzuraを参照。

tsuzura

MisumiRize/tsuzura · GitHub

haxelib newが見つかって頓挫したHaxe版bundler。installコマンドまで実装したところで頓挫した。

{
    "dependencies": {
        "lime": ""
    }
}

プロジェクトルートにlibfile.jsonという名前でJSONファイルを作成し、そこでtsuzuraをhaxelibから実行する。

$ haxelib git https://github.com/MisumiRize/tsuzura
$ haxelib run tsuzura

すると、libfile.jsonと同階層に.haxelibディレクトリが掘られ、そこに依存定義されたライブラリがインストールされる。結果的にhaxelib newしてからhaxelib installしたのと同じ状況になるので、あとはお好きにどうぞ。

現時点の感触

まだHaxeからJavaScriptへのコンパイルに着手していないが、Haxeという言語そのものは多少クセがあるもののとっつきやすい言語だった。むしろ情報が新旧混在しており、最新版の情報がいまいち不足しているあたりに厳しさを感じる。

とっつきやすい言語だったとはいえ、何かにつまづくとHaxeの内部実装を見ることになりOCamlが待ち受けているあたりはFlowと同じ。

Haxeの売りのひとつとされているマルチプラットフォームはWrite once, debug everywhere的なつらみしか感じなかった。