MultiJson.dump(OpenStruct.new(code: 200)) #=> "{\"table\":{\"code\":200}}" の謎

Oj.dump でそうなる OpenStruct のインスタンスは内部に @table というハッシュを持つ Oj がどこかでそのハッシュ自体を検知して JSON にするのだろうがどこでやってるか追えてない

げんしけん「そんな未来」考察

「ーーで『げんしけん』の話なんですけど、実際『そんな未来』ってありえると思います？」

「あれねぇ。ふつう無いよねぇ」

「そうなんですよ、咲視点で班目の好感度があがる要素ってたぶんなくて。むしろ悪印象しかない」

「そもそもマイナスからのスタートだしね。あと火事騒動とかもフォローになってない失言でポイント失ったり」

「にもかかわらず『そんな未来もあったかもね』。このセリフをどうとるべきか、そこが問題なんですよ」

「ふむ。あれかね、『好きになってくれるひとが好き』ってパターン。コーサカの能天気な好意より班目のうじうじした好意のほうが、気付いてる咲にしてみればわかりやすい。コーサカの好意に自信が持てなくなって、安心できる男を選んだ、とか？」

「それもありですが、それだとなぜ四年耐えられたのか、の根拠が弱くないですか？実は僕ちょっと考えてることがあって」

「ほう。それで？」

「僕はこのエピソードで鍵になるのは班目が振られてスッキリ吹っ切れた直後のシーンにあると思うんですよ。ほら咲が泣くじゃないですか」

「うむ」

「あそこで咲はこう言うんですよ、『言ったでしょ 私から見たら4年前からだって 絶対 思わせぶりな態度は取らないって決めてたけど』。これを、何故このタイミングで言うのか」

「（無言で先を促す）」

「だって四年もですよ、思わせぶりな態度をとるまいと決めて守り続けた咲が、振ったそばから思わせぶりなことをいっている。『そんな未来』ってのは、そういうことでしょう？」

「ふむ。つまり？」

「つまりですね、これは咲の本心、もしくは願望なのではないかと。四年間頑なに班目の気持ちに気付かないフリをしてきたのは、咲からしてみればまだ恋愛が始まってもいなかったからで。その少し後で笹原妹が言ってますが、班目の気持ちに咲が気づいていることを班目が自覚したときが本当の恋愛の始まりってことなんですよ。咲が自分から切り出すことはない、コーサカと同じ土俵に上がってもこない班目は比較対象たりえない。しかしひとたび幕があけられたならば、その恋愛はどうなるか咲自身にもわからない」

「あーなるほど、」

「しかし不運にも班目の恋愛は始まってすぐ終わる運命だった。咲の答えは最初から決まっていて、班目はどうしたってあそこで振られるんです。しかし、しかしですよ、一瞬で幕が降ろされたその恋愛に咲は思わせぶりな態度をとる」

「（何か言おうとして口を開く）」

「それは何故か。咲は終わらせたくなかったんです、正確には終わらせたかったし終わらせたけど、終わってほしくなかったんですよ。だからあそこであんなことを言った。ずっと言うまいと思っていた相手に、ずっと言うまいと思っていたことを」

「あー、つまりあれだ、『本当の戦いはこれからだ』メソッドだな」

「そう！そうなんですよ、咲は班目に諦めてほしくなかったんじゃないでしょうか？一度振られたくらいで諦めずに、今度こそ真正面からアタックしてきて欲しかった」

「なるほどねぇ。コーサカを振る理由が欲しかったのかもしれないね。そうまでして好いてくれる人になら、なびいても仕方ないと、周囲に対する言い訳が欲しかったんだな、自分も含めて。いやむしろ奪って欲しかったのか」

「そう考えると Spotted Flower の立ち位置がまた興味深くなると思っていて、あれ実はパラレルワールドじゃなく、未来そのものなんじゃないかと」

「たしかに。恋愛から逃げることをやめた班目、彼の気持ちに向き合い自分に向き合ってくれる彼を選んだ咲、そういう過程を経てこその『元カレと同席して周りの空気重くするのなんか〜』だと考えるとまた意味が違ってくるな」

「でしょ？重いですよね、あの一言」

「重いね。いやあなんかだいぶリアリティ出てきたなぁ」

「いやーぼくますます Spotted Flower が楽しみになってきましたよ」

「あ、そうか、『あったかもね』は一種のミスリードなのかな？あそこは本当は『あるかもね』であるべきなのか、」

「先輩？」

「『あるかもね』は実現可能な仮定、『あったかもね』は実現するはずのない仮定の表現。だからあそこで実現可能な未来の話を咲はするわけにはいかなかったのか。それは実現してしまうだろうし、その実現を願うということは不実につながるから」

「おーい（顔の前で手を振る）」

「心の底では願望としてありつつも、無意識に避けたがゆえの仮定法であり、相反する感情の板挟みになっているがゆえの態度、なのか。深いな……」

「なんか先輩ひとりの世界に入っちゃったみたいですね。まぁ言いたいことは聞いてもらえたから満足だけど。たまにはこういうスタイルもいいですね。みなさんはどう思いましたか？よかったら感想聞かせてくださいね。ではまた」

「……もしあそこで班目が仮定法を使わなかったら……？」

Withings Smart Body Analyzer WS-50

二年くらい前から欲しかったが、ついに買った。色は家電？らしく白。運動不足でお腹が気になる猫の体重測定をまめにやるため、という名目。

猫を抱いて体重計に乗ると5.8キロほど体重が増えるのだが、ちゃんと？別人の体重と判定された。俺は元々体重の変動幅で本人か別人か判定するのだと思っていたけど、奥さんの意見は「足の裏の指紋とかで照合するのでは」というもので、しかしそうではなさそうだった。いったいどうやっているんだろう。体重差とか体格？で決定するとしたら、双子がいる家庭では役に立たなくなるんだろうか。

いざ使ってみると猫の体重測定には思ったほど便利ではなかった。いわば「容器」である俺自身の体重が1キロ程度変動するので、猫のプロフィールの体重変動をみても誤差がありすぎて役に立たない。同時刻の俺の体重を都度引かなくてはいけない。それなら体重を計ったときに引き算して記録するのとあまり手間が変わらない。

乗った人の測定データが体重計をセットアップした俺のアカウントに自動的に連携されるので、奥さんからは「体重を測るたびにあなたに知られるのは嫌」と不評を買った。アカウントを独立させれば見られずに済むよ、と招待メールを送ったが、忙しくてまだアカウントを作っていないようだ。

セットアップはスムーズだった。アプリとネットワークを介して連動とか、作ったりテストしたりするの大変だろうに、さすが家電？の品質はすごいなぁと感心した。体重測定が終わるまでにけっこう長い時間（10秒くらい？）乗り続けてないといけないのは最初よくわからなくて測定をミスったりしていた。あと、ハードウェアの質も安っぽさがなくて良い。

iOS アプリは Fitbit と比べてデザインがやや垢抜けてない印象。マテリアルデザインっぽいので好みだし、 Android アプリはさすがにいい感じ。測定データがタイムライン表示されるのは思ったよりもだいぶよかった。見ていて面白く感じる。タイムラインというものに慣れすぎているせいな気もする。ダッシュボードは Fitbit のほうが見た目がよいぶんだけ勝ってる印象。

Fitbit との連携は、ネットのブログ等では隠し機能かのごとく言及されているが、 Withings 側からは Web 版の「パートナー」メニューからあっさり Fitbit を探して連携ページにたどり着けた。 Fitbit 側からは確かに探せないようだが。サービス間のデータ連携のタイムラグもそこまで遅くなく、10分以内には同期されていそう。

当初の目的に対してはやや期待外れだったが、総じて満足している。実家の両親にプレゼントするのもありかもしれない（帰省したときにセットアップまで済ませておくのがよさそうだが）

なお、公式サイトからは複数のネットショッピングサイトへリンクしており、どこも値段なんて変わらんだろと思いつつも念のため Apple Store と Amazon を見比べてみたら、前者が定価なのに対して後者は 5000 円ほど安かった（日本正規代理店）

Withings Bluetooth・Wi-Fi対応 体重計 Smart Body Analyzer WS-50 体脂肪/心拍数/室内環境分析 ブラック 70023101【日本正規代理店品】

Spotted Flower（1）

偶然みつけて即買った。まさか俺たちの「げんしけん」真ルートが描かれていたとは。「これ春日部さんか？芳乃では？」と思わなくもないが、まぁ。内容がだいぶアレなのでアレだが、やっぱり斑目が報われてこそ「げんしけん」本当の完結だろうと思うのでこれでよい。

Spotted Flower 1

そしてずっと前に単行本で読んだ初代の告白未遂シーンと、こちらは読んではいなかった二代目の告白玉砕シーンもあわせて読んだ。

「それは斑目次第でしょ？」

「ーーさて　まぁ　久しぶり　かな」

「……僕だって　斑目さん好きなんですよ」

「ーーそんなに俺　バレバレか？」

「あんたが私にネコミミつけた時に初めて　ーー『あぁこいつ私に気があるな』って思った」

「ーーまた　黙っちゃったね」

「ごめん　コーサカいるから　斑目とはつき合えない」

「……　そんな未来もあったかもね」

そんな未来、あったよちゃんと。斑目おめでとう斑目。

げんしけん（９） (アフタヌーンコミックス)

げんしけん（１３） (アフタヌーンコミックス)

げんしけん（１４） (アフタヌーンコミックス)

---

これはノロケだけど、自分は斑目ほどコアなオタクではないがメンタリティ的にはまさにああいうタイプだと自認していて、奥さんはまんま春日部さんどストライクなタイプなので、あの二人にはけっこう自分の状況を重ねあわせてしまうところがある。のでなおさらよかった（Wikipedia で連載時期を調べたら、まさに初代クライマックスの頃が関係を深めていった時期で、なんというか図らずも人生のターニングポイントをともに過ごした漫画だった。そういえば「げんしけん」の連載が終わった年にアフタヌーンを買うのもやめた気がする）

私のソースコードの書き方

note.mu

なるほど自分も同じような感じでやっているなぁ、と思った。もうちょっと詳しく書くと、

• まず変更しようと思っている部分の周辺のコードを読んで、「ここらへんをいじればよさそう」と当たりをつける（当たりのつけかたにもいろいろあるのだが後述）
• 土地勘を養ったところで具体的な変更の仕方を考える。必要に応じて紙に下手くそな図を書いたり、考えを箇条書きにしたり、実際にコードを試しに変更してみたりする
• この方針でいけそう、と道筋が見えたらいよいよコードを書き始める。細かい単位でコミットするかどうかは場合によるが、少なくとも git add はこまめに行う（エディタの undo でせっかく書いたコードを失わないため）
• 道筋が見えなかったり、プロトタイプ的に書いたコードが望み薄そうだったら潔く諦める。煮詰まっていることを自覚して、コーヒーを買いにいったり、オフィスの外を散歩したりして頭をリフレッシュさせる（歩いてる最中に別のアイデアが思いつくことも少なくない）
• 無理のない設計でちゃんと動くものができたら仕上げに入る。テストを書いたり、マークアップを調整して見栄えを整えたり、など

だいたいこれが基本方針で、どんな種類のコードを書くときも概ねこういう感じ。それに加えて、新機能追加とバグ修正のどちらのコーディングか、またサーバサイド（Ruby on Rails）とクライアントサイド（Marionette.js）のどちらのコードを書くかによってアプローチが違ってくる。

サーバサイド & 新機能追加

できる範囲でテスト駆動開発のスタイルを取り入れる。が、無理はしない。実装後にテストを書くのも許容する。

仕事の場合、「正しいプログラミングプラクティスを実践すること」ではなく「要求を満たす製品を妥当な時間・妥当な品質で作ること」に対して対価をもらっているのだから、当然この優先順位になる。

サーバサイド & バグ修正

できる限りテスト駆動開発のスタイルを守る。バグを再現するテストで 1 コミット（push して CI を red にする）そのバグを修正する実装で 1 コミット（push して CI を green にもどす）この 2 コミットのコメントは極力丁寧に書き込む。必要に応じてリファクタリング。

とはいえ難しいこともあるので無理はしない。場合によっては実装まで終えた状態からテスト部分のみ 1 コミットとして先に push したりする。

以前はテストとバグ修正を合わせて 1 コミットにしていたが、これだと「本当にその修正で直ったのか？」を示せないので、あえて一回テストを落として証拠を残すスタイルに宗旨替えした。

クライアントサイド & 新機能追加

機能が一通り動くようになるまではテストのことは一切考えない。もちろんテストは実装が終わってから書く。このタイプの実装をするときが最も手戻り・やり直しが頻繁に発生するので、テスト駆動開発のスタイルでやろうとすると手間がかかりすぎるため。

サーバサイドのプログラムに比べて一つの関数の責務が多くなりがち、かつテストを書きづらいので、必要に応じてテストの書きやすさのためにプロダクトコードに手をいれることも許容する（必須ではない関数の切り出しを行ったり、必須ではない getter/setter を用意したり、など）。

クライアントサイド & バグ修正

できる限りテスト駆動開発のスタイルを守る。が、やっぱり難しいものもあるので無理はしない。その代わり、バグ修正のコミットのコメントは極力丁寧に書き込む。

必要に応じて、バグのデモンストレーション用に jsbin のような外部サービスで再現コードを実装して、それの URL を書き添えたりもする。エッジケースのバグの場合、プロダクトコード上でも発生するタイミング等がシビアなことがあるので、最小の再現コードで原理を説明したほうが理解しやすいため（そしてプロダクトコード上でそれに相当する変更というのは得てして意図がわかりづらくなるため）

---

「当たりのつけかた」について。いま名付けたが、だいたいこんな感じで使い分けている。もちろんいちいち「今回はエンドツーエンド型でいってみよう」などと考えたりはしない。

ボトムアップ型 ダイブイントゥ型

MVC アーキテクチャでいう Model の部分に着目して、いきなりピンポイントに飛び込んで当たりをつけにいくアプローチ。ビジネスロジック、というか単純な計算をしている部分を変更したいときなど、どこを変更すべきかすでにわかっているときにとる方法。

2016/07/19 10:39 更新: ボトムアップって感じじゃないな（上がっていない）むしろ直接飛び込む感じだな、と思ったので改名した。

エンドツーエンド型

ボトムアップ型と真逆で、システムのアウトプットから順にソースを辿っていって目当ての場所にたどり着くアプローチ。システムが複雑で当たりをつけられないときに、ソースコードの調査を進めつつ探索範囲を絞り込むために使う方法。具体的には、 JSON API のレスポンスデータから「このデータをシリアライズしてるのはこのクラスで、データを提供しているのはこのインスタンスで」のように一ステップずつ進んでいく。手間はかかるが闇雲にソースファイルを開いて回るよりも早く目標にたどり着ける。

リクエスト・エンドポイント型

ボトムアップ型とエンドツーエンド型の中間くらいのアプローチ。ピンポイントで明らかにはなっていないが、ある程度まではすでに絞り込み材料がある場合にとるアプローチ。具体的には API のエンドポイントやアプリケーションのルーティングなど、 URL とそれに対応するハンドラ部分を起点に探索していく。サーバサイドの変更の場合はもっぱらこのアプローチをとることが多い。

モジュール・ネームスペース型

機能を実装するモジュールや、プログラム内のネームスペースなどで絞り込んでいくアプローチ。複数箇所から共有されているコンポーネントなど、 URL から一意にたどり着きづらいが逆に機能名が特徴的なものの場合にとるやり方。 Marionette.Module を使って構造化しているクライアントサイドの変更の場合にこのアプローチをとることが多い。