生命保険の選び方（と少しだけ日米比較）

生活環境にいろいろと変化があったので、生命保険を見直してみました。一番のポイントは、アメリカの生命保険という点です。

例えば、こういうサイトで生命保険の見積もりが取れます。（当然ですが、健康診断の結果によって、保険料が変わることがあります）

保険金額を $1,000,000 としたときの保険料はこんな感じです。（個人的に、終身保険には意味がないと思ってるので、定期保険のみ調べてます。）

"Term Life", "ROP" (Return Of Premium) というのは保険の種類で、"Term Life" が「掛け捨て」で、"ROP" は、「払い込んだ保険料が満期時に返還される」という保険です。

* ここで「返還されるってことは無料で保険に入れるってことだからおトク」と思った人は、悪質な金融業者に騙される可能性が高いので、「今日の 100 円と明日の 100 円とは価値が違う」という言葉の意味が分かるまで、金融商品には手を出さないことをお勧めします。

* 保険引き受け会社は適当に選びました。

保険期間は、自分の年齢と予想定年時期を考えて設定すれば良いでしょう。例えば、25 年後に退職予定なのであれば、25 年後以降に死亡しても家計の収入に影響がないので、25 年以上をカバーするのは意味がないと思います。

"Term Life" と "ROP" はどうやって選んだら良いでしょうか? 「ROP を購入した時の満期の償還額」と「Term Life を購入し、差額（ROP と Term Life との差額）を運用したときの残高」とを比較して、多い方を選ぶというのが良さそうです。

計算結果を表に追加しました。

"Total Payment" は、ROP の保険料の総支払額（= monthly premium × 12 × 保険期間）です。この金額が、満期時の償還額になります。"(B - A) * 12" は「ROP と Term Life との差額（年額）」です。

黄色のセルは、「『差額』を毎年積み立てて、それぞれの利率（2% ~ 6%）で運用した時の満期時（20 年後、25 年後、30 年後）の残高」です。

この表から次のことが分かります。

• 保険期間 20 年の場合、2% 以上で運用する自信があるなら、Term Life を買って、差額を自分で運用する方が得。自信がないなら ROP を買うべき。
• 保険期間 25 年の場合、4.x% 以上で運用する自信があるなら、Term Life を買って、差額を自分で運用する方が得。自信がないなら ROP を買うべき。
• 保険期間 30 年の場合、5.x% 以上で運用する自信があるなら、Term Life を買って、差額を自分で運用する方が得。自信がないなら ROP を買うべき。

次に気になるのは、「自分で運用したとして、X% で運用できるのか?」という問題です。これは難しい問題で、投資経験や運が影響しますが、1 つの指標として国債の利回りを考えることができます。国債はリスク 0 の投資なので、この利回りが下限となります。

Yahoo! のサイトで米国債の利回りを見ることができます。米国債に 20 年満期、25 年満期はないので、30 年満期と 10 年満期を調べました。

このデータと、

• 2013 年現在、景気はかなり底であって、これからは上昇するだろう
• 株式投資の利回りは米国債利回りより高い（高くなければいけない）

という "予想" "感覚" "直感" を考慮すると、「20 年間 2% 運用」は達成できそうです。「25 年間 4.x% 運用」「30 年間 5.x% 運用」は、景気次第と言えそうです。

国債だけでなく、各種ファンドの利回りとも比較すると、"Term Life" と "ROP" のどちらが良いか、より自信を持って判断できると思います。

最後に少しだけ、生命保険の日米比較を・・・。$1,000,000 "Term Life" をライフネット生命と比較しました。

保険金額 "Coverage" が微妙に違うとはいえ、保険料が 3.5 ~ 5 倍も違いますね。これは、ライフネット生命がいかにぼったくりか・・・ということでは全くなくて、日米の運用利回りの差によるものです。保険会社は保険料を運用するので、そもそも日本市場の利回りが低いと保険料を高く設定せざるを得ません。

営業コストを減らすことで、保険料を安く抑えているライフネット生命ですらこれですから、営業コストの高い大手生命保険会社の保険料は推して知るべしですね。

アメリカの生命保険に加入できる人はアメリカで加入することを考慮した方が良いかもしれません。ただしその場合は、死亡時の手続きが非常にめんどくさくなることは覚悟しましょう。

はじめての育児休暇を終えて - 買い物リストとか

はじめに

初めての子どもが生まれてから 3 週間が経ちました。これまでの育児の感想は、「予想どおりに大変」です。楽でもないけど予想以上に大変でもないです。
これは、日本では長い方であろう 3 週間の育児休暇を取って、育児に集中できたことが大きいと思います。おかげで、いろいろ気づいたこともあるので、買ったものリストをまとめました。

なお、パパ・ママ向けの「Amazon ファミリー」 というサービスに登録すると、お急ぎ便が使い放題になる Amazon プライムが 3 ヶ月間無料になるのでとても便利です。履歴を見たところ、3 週間で 19 件注文してました。クロネコヤマトの人に「なんだこの家? 毎日注文しやがって」と思われていることでしょう。

基本方針

基本的な方針は次の 2 点です。

1. 「数千円のものはどんどん買う（結果的に無駄になっても気にしない）」
   育児の機会は一生に 1, 2 回（日本の出生率は 1.4）であることを考えると、一回の育児で例え 10 万円無駄遣いしたとしても、生涯支出から見れば誤差の範囲です。買うか買わないか悩む時間がもったいないです。
2. 「楽をする、不安を無くすことを優先」
   親に時間的・精神的余裕が無いと良い育児はできないと思います。時間を買える、不安をお金で解決できるなら出費しましょう。

買い物リスト

（以下の項目は、私が特に便利だと思ったものです。購入アイテム全てではありません。）

哺乳瓶・哺乳瓶消毒器

はじめに「ピジョン 母乳実感哺乳びんプラスチック240ml」を 3 本買ったのですが、これだと「飲みやすすぎる」ようで母乳を飲むのがうまくならないようなので、「ピジョン 桶谷式直接授乳訓練用 母乳相談室 乳首SSサイズ」を買って、付け替えました。
さらに、最初は煮沸消毒をしていたのですが、これはちょー面倒（大きな鍋を用意 & 大量のお湯を沸かす & 哺乳瓶を熱湯でゆで続ける）だったので、急いで「コンビ 消毒じょ~ず & 衛生ケース HW」を購入しました。レンジに 5 分入れれば良いだけなのでかなり楽になります。

そもそも「煮沸消毒は必要なのか?」という疑問はあるのですが、それは方針 2 に則って余計な不安を抱えないようにしました。

哺乳瓶はなぜ 3 本なのか?

新生児には 3 時間ごとに授乳する必要があります。例えば 0 時（深夜）に授乳すると次は 3 時、6 時、9 時・・・となります。
新生児の親も人間なので、夜は眠いです。授乳のために起きるのは仕方ないとしても、夜間の作業は最小限にしたいところです。哺乳瓶が 1 本しかないと、3 時間ごとに哺乳瓶の洗浄・消毒作業が必要になります。ミルクをあげるのは（ミルクを飲んでる子どもがかわいいので）眠くても耐えられますが、夜間に台所仕事はしたくありません。
2 本だと 0 時の授乳後（1 時ぐらい）に洗浄・消毒したとして、次は（9 時の授乳に備えて） 8 時ごろに洗浄・消毒が必要になります。3 本だと 0 時の授乳したら、次は 11 時ごろに洗浄・消毒すれば良いことになります。

「8 時まで寝られれば十分じゃないか」という意見もあるかもしれませんが、「0 時の時点で全ての哺乳瓶を使い切ってない」「搾乳のために哺乳瓶を 1 本余分に使う」などのケースがあるので、2 本だと危険です。
なお、消毒後の哺乳瓶はそれなりに清潔な場所に保管しなくてはいけないので、「30 本買っておく」という戦略はよほど広い家に住んでないと難しいでしょう。「コンビ 消毒じょ~ず & 衛生ケース」には、ピジョンの哺乳瓶を 3 本入れて保管できます。4 本は入らないような気がします。

粉ミルク

「明治 ほほえみ」「森永 はぐくみ」「ビーンスターク すこやか」と試しましたが、違いはよくわかりません。「すこやか」をのみ始めた頃から便秘が直りましたが、同時期に母乳をよく飲むようになったので、どっちが効いたのかわかりません。（Amazon にも「便秘に効いた」というコメントはありますね）

なお、「ビーンスターク」は、大塚製薬の赤ちゃん向けブランド名です。カロリーメイトとポカリスエットの会社かと思うと微妙な気持ちになりますが。

おむつ

病院で使っていた「パンパースのはじめての肌へのいちばん スーパージャンボ 新生児68枚」、試供品をもらった「グーン はじめての肌着 Sサイズ 104枚」と、その上位機種 (?) の「グーン プレミアム 天使の産着 新生児用 62枚入」を使いました。
パンパース (P&G)、GOO.N (大王製紙) ともに、おむつには「プレミアム版」と「スタンダード版」があるんですね。

新生児用おむつ一枚あたりの値段 @ Amazon.co.jp	プレミアム	スタンダード
パンパース (P&G)	はじめての肌へのいちばん 19円	さらさら コットンケア テープ 14円
GOO.N （大王製紙）	プレミアム 天使の産着 24円	はじめての肌着 14円

競合であろう「パンパースのはじめての・・・」よりも 25% も高く値付けした「プレミアム 天使の産着」のプライシングは（皮肉じゃなく）素晴らしいと思います。「天使の産着」というネーミングも素敵です。産着っていうかおむつですけど。触った感じだと、たしかにパンパースよりも厚みがあって柔らかい感じがします。そして、腰の部分の色が何色用意されていて高級感があります。この値段だと普段使いは難しいですが、勝負おむつとして常備しておいても良いかもしれません。
「はじめての肌着」は、薄くてちょっと残念な感じです。おそらく「パンパースのはじめての・・・」を使い続けることになるでしょう。

おむつ処理ポット

「コンビ におい・クルルンポイ 紙おむつ処理ポット」は、赤ちゃん用布団セットを買ったときのおまけでもらったのですが、重宝しています。今住んでいるマンションには、いつでもゴミを出せる集積所がないので、おむつ（燃えるゴミ）を数日家の中においておかないといけません。なので、におわないゴミ箱は必須です。

ベビーバス

新生児の育児作業の中で一番難しいのは、何といっても沐浴でしょう。そもそも、ばたばた暴れる新生児を片手で柔らかく支えながら、もう一方の手で洗っていくという作業そのものが困難な上に、緊張感が違います。オムツ替えに失敗したところでせいぜい部屋が汚れるくらいですが、沐浴に失敗（溺れる、頭を風呂桶に打ち付ける、etc.）すると赤ちゃんが死ぬかもしれません。

というリスクを考慮し、「ふかふか ベビーバス グリーン」を購入しました。これは、風呂桶全体が柔らかい（子供用ビニールプールと同じ）ので頭を打ち付けても大丈夫です。そして、ストッパーに座らせたり、足を置いたりすることで体を安定させることができます。ビニールプールなので壊れ（破け）やすい気がしますが、2000 円なので、壊れたらまた買うということで。

加湿器 & オイルヒーター / 温度・湿度計

これから寒くなりますが、風邪をひかれては困ります。子どもにとって良くないのはもちろんですが、病院に連れて行くのは時間・費用がかかり、親へのダメージもあります。部屋の湿度が高いと風邪ウイルスが床に落下して感染しにくくなるという話があるので、「ダイニチハイブリッド式加湿器 HDシリーズ ブルー HD-5012-A」を購入しました。あと、もともと持っていたデロンギ社のオイルヒーターを使ってます。エアコンは空気を乾燥させるし、石油ファンヒーターは空気を汚すので。

加湿器は、「イオン XXX」とか「プラズマ XXX」とかいう余分な機能がついてないという点と、気化式（水を含ませたフィルタに空気を当てて湿度の高い空気を送り出す）が良かったのでこれにしました。

そして「CASIO (カシオ) 置時計 WAVE CEPTOR 電波時計 温度・湿度表示 DQD-700J-8JF」を購入して、室温 20 ~ 23 度、湿度 60% を保つようにしています。

赤ちゃん用体重計

新生児の育児作業は、授乳・沐浴・オムツ替えなど、頭を使わない単純肉体労働です。では何が難しいかというと、「健康に育ってるのかよくわからない」という不安が常にあることです（特に長子の場合）。この不安を解消するには、できるだけデータを計測して、変化を早くキャッチする（キャッチできるという安心感を得る）しかないと思います。
ということで、赤ちゃん用体重計「ベビースケール TH996」を購入しました。新生児の体重は、20~30 g/日増加していくので、100 g 単位でしか計測できない大人用体重計は使えません。

その他に、体温、ミルクの量・回数、尿・便の回数を記録しています。というか、親が医者じゃない場合、これぐらいしか計測できるものがないです。

カーシェア / チャイルドシート

風邪を引いたり、具合が悪くなったら病院に連れていかなくてはいけません。一ヶ月検診などもあります。新生児を電車・バスに載せるのは危険なので、カーシェア (タイムズプラス) に入会し、車を借りて病院まで行ってます。安全性を考えるとタクシーが良いのですが、車の運転に慣れておきたいという、育児とは無関係な個人的な事情があるので、カーシェアにしました。
チャイルドシートは今のところレンタルしています。そのうち買うかもしれません。

手袋（自分用）

子どもが生まれると、水仕事が多くなります。（母乳のために）3 食きちんと食べるようになるので、食事の準備と食器洗い、哺乳瓶の洗浄、沐浴、ベビーバスの洗浄、オムツ替え後の手洗い、洗濯。すぐに指先がひび割れて、水仕事もキーボードを打つのも辛くなりました。台所仕事用の手袋と、オムツ替え用の使い捨て手袋を使ったところ予想外にいろいろ捗ったので、買っておくと良いと思います。数百円ですし。

空き時間にやること

父親にとっての育児休暇とは、産後の大変な時期に家族のサポートをする時期であると同時に、育児と仕事をどう両立していくかを探る時期でもあると思ってます。
数週間の育児休暇の後も育児は続くわけで、例えば、授乳と授乳の間の 2 時間でどの程度の作業ができるか、を把握することは大切だと思います。
技術書を読むとか、コーディングの課題を解く、など手を付けやすい ToDo を用意して、育児とどの程度両立できるのかを調べましょう。

・・・というのが表向きの理由で、精神安定剤としてエンジニアリング的な何かをやってたかった、というのが本当の理由です。
上にも書きましたが、（この時期の）育児は単純肉体労働なので、何か知的労働をしないとバランスが崩れる気がしました。

ちなみに私は、Coursera の Scala コースと Compilers コースのビデオを見たり、課題を解いたりしてました。余談ですが、Coursera の資料はとてもよくできている（+ 英語の勉強にもなる）のでオススメです。

最後に

「（特に父親は）育児休暇が取りにくい」という問題はよく聞きますが、なぜでしょうか?
最初に書いたように、日本の出生率は 1.4 です。ということは、育児休暇の期間が 4 週間だとしても、1 人の社員が生涯 (= 35 年 x 52 週/年 = 1820 週) で取得できる育児休暇は 6 週間弱、生涯労働時間のたかだか 0.33% しか影響しないわけです。
0.33% の労働力の減少が企業経営に影響を与えるとは思えないのですが。

育児休暇は少なくとも 3, 4 カ月前には取得時期が確定するので、「突然いなくなって、業務の継続性に問題が」という問題も起こりえません。

同様に日本企業の問題点である「サービス残業」については、「まともに残業代を払うと、人件費が 1.X 倍になって会社がつぶれる」というホンネは理解できます。（だからといってサービス残業を肯定するわけではありません。）
しかし、0.33% の影響しかない育児休暇が取りづらい（取らせたくない）というのは、本当に何でなんですかね?
今の 20~30 代の男性は、「育児なんて男のすることじゃないぜ」という世代ではないはずですしね。

アメイジング・スパイダーマン (3D) の短い感想

桜木町の映画館ブルク 13 で、アメイジング・スパイダーマン (3D) を見た。3D 映画は、アバターに次いで 2 回目。難しいことを考えずに見られるアクション映画としてよくできている。「絶対見なきゃいけない傑作」とは言わないが、ちょっと非日常的な時間を過ごしたいときにおすすめです。

パラレルストーリー

これは前シリーズのパラレルストーリーなんですね。10 年ぐらい前に

ソニーピクチャーズは、シリーズ物に力を入れていく。全く新しい話は当たり外れが読めなくてリスクが大きいが、シリーズ物だと観客数が読みやすい。

という話をどこかで読んだ気がする。シリーズものだと流石にいつまでも続けられないので、同じ設定でパラレルストーリーとして描くのは賢いと思う。

3D

スパイダーマンという話の設定上、マンハッタンで空を見上げたり、ビルの上から見下ろしたり、ビルの間を飛び回ったりするシーン、つまり、画面の深さを描く場面が多い。こういうところに 3D が効いている。アバターのときより 3D の価値があった気がする。
ところで、ストーリーと関係ないけど、普段からメガネをかけているものとしては、裸眼 3D が開発されないかなーと思う。メガネの二重がけはかなり重い。実際、部屋の中で 2 人が話しているような 3D が不要なシーンでは、3D メガネを外してしまった。ちなみにブルク 13 の 3D 方式は XpanD だそうだ。

ストーリー・構成

クモに咬まれた主人公の肉体能力が向上し、おじさんの死をきっかけに正義に目覚め、なんやかんやあって、ボスを倒す、という前シリーズ一作目と全く同じ話。ただし、今作では、肉体的な進化（改良）によって手首から糸を出すのではなく、手首に専用機械を取り付けることで糸が出せるようになっている。疲れると糸が出せなくなるのではなく、機械が壊れると糸がだせなくなる。・・・という機械を作れるくらい、主人公の能力は高いという設定。

スパイダーマンがヒーローとして人々に認知されていく過程の描写が無かったり、学校のいじめっ子といつのまにか友達になってたり、「娘に近づくな」という彼女の父ちゃんの遺言をあっさり破ったり、と構成上突っ込みたくなる点はいくつかある。が、そういう出来を見る映画では無いだろう。「お前らどうせ前シリーズ見てるんだから、スパイダーマンがヒーローになったり、2 作目で彼女と結婚するの知ってるよな。その辺は手抜いてるけど、分かるよな。」ということだろう。

SF はどのように楽しむべきか

読書の幅を広げようと思って SF というジャンルに手を出してみたが、どうにも楽しみ方がわからない。SF を罵倒する意図はないが、どのように楽しむものかを誰かがコメントしてくれたら良いなと期待しつつ、まとめてみる。

ジャンルに依らず、私が好きな構成は「一見関連なさそうな事実がいくつか用意され / 紹介され、最後に全ての事実に整合的なストーリーが提示される」というものだ。

分かりやすい例としてはミステリーが挙げられる。（よくできた）ミステリーでは、事件や証拠 / 証言が提示されるが、それが何を意味するのか最初は分からず、最後に探偵役が何が起こったのかを説明する。ここで読者には「あーそういうことだったのか」という驚きが与えられる。

最近読んだミステリーじゃない例としては「銃・病原菌・鉄」がある。この本では、ニューギニア人の疑問「あなたがた白人は、たくさんのものを発達させてニューギニアに持ち込んだが、私たちニューギニア人には自分たちのものといえるものがほとんどない。それはなぜだろうか？」に、生物学・言語学など様々な分野の知見をもとに答えていく。（誰もがきっと一瞬は考える）「ニューギニア人は馬鹿だから」という誤った根拠や、「文明を発達させたのがヨーロッパだから」という表層的な根拠ではなく、初めての人類がアフリカで誕生してから今までに何が起こったのかを解き明かそうとしていて、多くの驚きを含んだ名作だった。

で、SF だが、「幼年期の終わり」（長編）と、「あなたの人生の物語」（短編集）のうち「バビロンの塔」「理解」「ゼロで割る」を読んでみた。前者はどこかの SF マニアブログで「最高傑作」と言われていたし、後者は「ネビュラ賞」なるものを受賞しているので、そんなに間違った選択ではないはずだ。

以下全力でネタバレしてます。

「幼年期の終わり」は、「オーバーロード」と呼ばれる宇宙人が地球に侵攻してくるが、やけに友好的で、地球を平和にし地球人文化の発達を助けてくれる、というストーリー。「オーバーロードの目的は何なのか」というのが、主題（大きな疑問）だろう。
最後に明かされる答えは「オーバーロードより上位に、オーバーマインドという別の宇宙人がいて、オーバーロードはオーバーマインドに仕えている。オーバーマインドは（ドラゴンボールのセルみたいに）完全体になるために人間を吸収したいが、そのためには人間が幼年期を脱する必要があり、オーバーロードにその手助けをさせていたのだった」だ。

この話が気に入らないのは、オーバーマインドという存在を最後に突然登場させて、それで全てを説明している点だ。伏線がまったくない。それで許されるんだったら「地球人を美味しく食べるために育てていた」でも「危険な星を地球人に探索させるために、地球の科学を発達させていた」でも「オーバーロードは実は未来の地球人で、過去の地球人をかわいがっていた」でも、何でも良いではないか。
一般的に言って、観測されたデータに整合的な解釈をするために、新たな概念を持ち出すのはスジが悪い。新しい概念を使えば、どんなものでも説明できてしまうからだ。オーバーマインドを登場させたいなら、登場させなければいけない理由を伏線として提示するべきだろう。

「バビロンの塔」は、世界設定は多分聖書の時代。その世界の空には「天井」があり、その地方の人々は「天井」の先に何があるのか知りたくて、ものすごく高い塔を作った。で、ある男がついに「天井」に穴をあけて、どんどん上っていったら地上に到達して、「そうかー、天井は地上につながっていたのかー、世界はループしていたのかー」という話。
これもそういう結論になる必然性が感じられない。天井の先が、天国だって、平行世界だって、自宅のトイレだってオチつけれるじゃない。地上につながってると何かおもしろいの?

「バビロンの塔」がそんな感じだったので、「理解」「ゼロで割る」は流し読みしただけ。「理解」は「アルジャーノンに花束を」みたいな話しだと思った。薬を注射された男がどんどん賢くなっていったが、同じように賢い男によくわからないやりかたで殺される。えーと、なんで死んじゃったの? ちゃんと読めばわかるのかな。

「ゼロで割る」は、「好きな人を理解しようと頑張ったら逆に嫌いになっちゃった」みたいな話を、ゲーデルの不完全性定理が生まれた時代背景などに掛けている。「数学の完全性を証明するために頑張ってたら、不完全性が証明されたでござる」みたいな。この話に気に入らない点は特に無いけど、特におもしろくもない。あと余計なお世話だけど、不完全性定理の意義が分からない人はこの話の意味も分からないと思うんだけど、SF の読者ってそんなに理系なんですか?

そんなこんなで SF を楽しむに至っていない。コンピュータ関係者で SF 好きって結構多いように思うので、私も仲間に入りたいんですけどねー。

Yesod の Scaffold を使って Wiki らしきものを作ってみた

Haskell の文法とか理論的なところとかは少しわかったので、具体的なアプリケーションを書いてみようと思ったのだが、今どき具体的なアプリケーションと言ったらウェブアプリに決まってるので、Yesod を触ってみた。
初心者が言うのも何だが、Yesod book は内容が足りないと思う。書籍版では内容が追加されていることを期待したいが、Amazon.com の Look Inside を見る限り、ウェブと同じ内容のようだ。残念。

Yesod book の Examples は、1 アプリケーションが 1 ファイルに記述されていて、読みやすいのかもしれないけど、全く実用的ではない。あと、せっかく scaffold があるんだから、そのサンプルも欲しいところだ。

ということで、"scaffold を使って何か作る" という目的でとりあえず Wiki、というと Wiki ファンに怒られるようなものを作ってみた。どういう点で怒られるかというと、

• markup なし
• ページ一覧なし
• 履歴管理なし
• ユーザー管理なし

ということで、要するに

• ページが作れる
• 編集できる

だけ。今気がついたけど、ページ削除機能作るの忘れてた・・・。

早速 Yesod の scaffold を使ってみる。（Yesod は "cabal install yesod-platform" とか入力すればインストールできるし、インストール情報は結構あるので、ここでは省略する。）

cabal で yesod >= 1 を確かにインストールしておいたのに、最初に yesod init したときは、なぜか 0.8.x が使われてしまったので、yesod version でバージョンを確認しておくと良いだろう。

yesod init で聞かれることは、以下の 3 つ。（以前は Yesod instance にするデータタイプ名も聞かれたけど、無くなったようだ。）

• 名前: ライセンス表記に使われる
• プロジェクト名: cabal 名に使われる。全部小文字にして単語をハイフンで繋ぐのが Haskell 的（かな?）
• データベース: 本格的なアプリを作るなら PostgreSQL を選ぶのだろうが、ここでは SQLite にする

最後に、なんだかよくわからない ASCII art とともに、次に入力すべきコマンドが表示される。

Twitter で「cabal-dev 使っとけ」的な発言を見かけたので、cabal-dev を使うことにする。cabal-dev install は時間がかかる。私の場合は 21 分かかった。かかりすぎ。このすきに珈琲をいれよう。しかし珈琲も冷めるだろう。
yesod --dev devel すると、アプリケーションが起動して http://localhost:3000/ でアクセスできるようになる。こんな感じ。

さて、あらためて hellowiki ディレクトリを見ると、こうなっている。ただし cabal-dev ディレクトリは省略した。

hostname:/tmp/hellowiki% tree
.
├── Application.hs
├── Foundation.hs
├── Handler
│   └── Home.hs
├── Import.hs
├── LICENSE
├── Model
├── Model.hs
├── Settings
│   ├── Development.hs
│   └── StaticFiles.hs
├── Settings.hs
├── config
│   ├── favicon.ico
│   ├── models
│   ├── robots.txt
│   ├── routes
│   ├── settings.yml
│   └── sqlite.yml
├── deploy
│   └── Procfile
├── devel.hs
├── hellowiki.cabal
├── main.hs
├── messages
│   └── en.msg
├── static
│   ├── css
│   │   └── bootstrap.css
│   └── js
├── templates
│   ├── default-layout-wrapper.hamlet
│   ├── default-layout.hamlet
│   ├── homepage.hamlet
│   ├── homepage.julius
│   ├── homepage.lucius
│   └── normalize.lucius
└── tests
├── HomeTest.hs
└── main.hs

ここからの開発方法はいろいろあると思うが、config/route を最初に変更して URL の設計をするのが良いだろう。

hostname:/tmp/hellowiki% cat config/routes
/static StaticR Static getStatic
/auth   AuthR   Auth   getAuth

/favicon.ico    FaviconR GET
/robots.txt     RobotsR GET

/               HomeR   GET POST
/new            NewR    GET POST
/wiki/#String   WikiR   GET POST
/wiki/#String/edit      EditR   GET

WikiR と EditR は 1 つのハンドラにしたいが、そういうことができるのか知らない。

yesod --dev devel を起動しっぱなしにしておくと、ファイルを書き換えるたびにコンパイルされる。Omake の polling mode みたいな感じ。config/route を編集してセーブした直後に、こんな感じでいろいろ怒られる。

Application.hs:27:1: Not in scope: `getNewR'

Application.hs:27:1: Not in scope: `postNewR'

Application.hs:27:1: Not in scope: `getWikiR'

Application.hs:27:1: Not in scope: `postWikiR'

Application.hs:27:1: Not in scope: `getEditR'
Build failure, pausing...

怒られたので、Handler ディレクトリに以下に、New.hs, Edit.hs, Wiki.hs を作り、そして Application.hs に import を追加する。例えば Handler/New.hs はこう書いた。

module Handler.New where

import Data.Text
import Import

import Model.WikiForm

getNewR :: Handler RepHtml
getNewR = do
  (formWidget, formEnctype) <- generateFormPost $ wikiForm Nothing
  defaultLayout $ do
    setTitle "Creating new wiki page"
    $(widgetFile "new")

postNewR :: Handler RepHtml
postNewR = do
  ((result, _), _) <- runFormPost $ wikiForm Nothing
  case result of
    FormSuccess (title, body) -> do
      runDB $ insert $ Wiki title $ unTextarea body
      redirect $ WikiR $ unpack title
    _ -> undefined -- エラー処理してない・・・

更にいろいろ怒られるはずなので、がんがん直していく。なお、"yesod --dev devel" はいかなる変更も完璧に拾ってくれるわけではないので、困ったときは "rm -rf dist" して "yesod --dev devel" を再起動するとよい。

試行錯誤を繰り返して、"yesod --dev devel" が文句を言わなくなったら、今作ったページにアクセスしてみよう。例えば http://localhost:3000/new とか。「Haskell ではコンパイルが通ればほぼバグは無い」と言われているのだから、これで動くはずだ。

動かない・・・。"yesod --dev devel" の出力を見ると、

Devel application launched: http://localhost:3000
GET /new
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8

Exit code: ExitFailure 11

となっている。

これが今回の最大の敵だった。"ExitFailure 11" では何もわからないし、Yesod book にも何も書いてない (*1)。困ったなと思って Twitter でつぶやいたら天の助けが。

これが正解で、hellowiki.cabal を編集すれば動くようになった。まぁアプリケーションが落ちる気持ちは分からなくはないが、ExitFailure 11 からそれは推測できない、絶対に。(*2)

このバグ（yesod のバグ?）さえなければ、あとはコンパイラのメッセージを見つつ、型合わせをしていけば動くようになる。

というわけで、Yesod の Scaffold を使ってみるという目的が達成できたので、Wiki まがいのアプリ自体には改良の余地が広大に残っているが、これで終わったことにする。コードはこちら。コメント・批判は大歓迎。

完成画面。なんと、"Pages"と"About"はどこにもリンクしていない・・・。

正直、Yesod の中身は未だにほとんど理解できていない。特にフォーム周りとか。Yesod book にも記述があるけど、これだけじゃねぇ・・・。しかし、全然理解していなくても、型を合わせていくと動いてしまうところが Haskell の凄い（怖い）ところ。ジグゾーパズルやってる感じ。が、それで良いはずはないので、ドキュメントの充実を望みたい。

個人的には、

• テストの書き方
• Shakespearn Templates の使い方。hamlet でコメントどう書くのか、とか。

を知りたい。あと、Hackage で、例えば getBy404 が出てこないのはそういうものなんだろうか?

ここまで書いたものを読み返してみると、文句ばっかり書いているようだが、Yesod は素晴らしいフレームワークだと思う。
Rails を最初に触ったときは、「フルスタックフレームワーク」というものに感動したものだが、Yesod はフルスタックフレームワークの手軽さに加えて、Haskell の type check を活かした堅牢性（というのか?）にさらに感動できる。
リンク切れを起こさない routing や、テンプレート内の変数が提供されること、XSS が起こらないことが、全て "type check" によって保証されている。Rails では、テストで確認するか、運を天に任せるしかできなかったことだ。（私の Rails の知識は 3 ~ 5 年前で止まってるので間違ってたらすみません。）

次は、実用的なアプリを作って見よう。

(*1)
と思ったら、ここに軽く書いてあった。

(*2)
よく見ると、"yesod --dev devel" が最初に警告していた。

WARNING: the following source files are not listed in exposed-modules or other-modules:
./Handler/Edit.hs
./Handler/New.hs
./Handler/Wiki.hs
./Model/WikiForm.hs

exposed-modules と other-modues との違いは分かってない。

同窓会サービスのセキュリティ問題

前職の会社から同窓会ネットワークへの招待メールが届いた。退職はしたものの本当に素晴らしい会社・同僚・文化だと思っているので、同窓会に招待してもらったは大変うれしい。うれしいのだが・・・。

これが招待メール。社名と私の個人情報に関わる箇所は赤でマスクした。

"Alumni Network website" リンクをクリックすると、secure.imodules.com というサイトが開き、名前と旧従業員番号の入力を求められる。

問題は、このメールにもそのサイトにも、前職の会社（以下 G）との関係を証明するものが何もないということだ。メールやサイトのデザインは、見る人が見れば G 社のものだとすぐに分かるが、こういうものはほぼコスト0で完全にコピーできる。
サイト自体にはサイト証明書がついていて、Imodules Software Inc. という会社が運営していることがわかる。この会社が同窓会サービスを請け負ってるんだと思うが、そんな話は在職時には聞いたことがないので、Imodules Software に個人情報を渡していいのかどうか判断できない。

「あなたの従業員ナンバーを入力する必要があります」と書いてある。私の ID 確認も結構だが、そっちの（サービスの） ID も確認させてくれと言いたい。

私が退職したことや私の前職を知ってる人はそれなりにいるので、このタイミングでこういう phishing を仕掛けてるのはありそうな話だ。

まぁそうはいっても、私はこのサイトに登録することになるだろうと思う。前職の人とのネットワークは重要だし、（証拠は何も無いが）これが phishing であることはない「気がする」。G 社に電話して「これ本物ですか?」と聞くのもめんどうだ。

しかし、これこそが悪意の無い insecure なサービスによる最大の害であって、こういう経験を積むことで「セキュリティ、セキュリティって言ってるけど、そんなうるさいこと言わなくても全然問題ないよね」と感覚が麻痺して、いつの日か本当の詐欺にあうことになる。そういうユーザーを増やすことに加担している。

そもそもこれをセキュアにするのは難しい話ではない。G 社のサイト証明書つきのウェブサーバに「G 社は同窓会サービスを Imodules Software Inc. に委託しています。下のリンクをクリックすると Imodules Software Inc. のサイトにジャンプします」というページを用意し、招待メールからこのページにリンクすれば良い。
そうすれば、（G 社のサイトが不正に改竄されていない限り）Imodules の同窓会サービスの正当性を確認できる。

なんてことをここに書かずに、G 社に言うべきなんだろうけど。同窓会サービスに関するコンタクトを見つけたからメールするべきなのか? それもなぁ・・・。

zshとscreenを少し便利にした。主にgit向け。

メインの開発環境が git になり、かつ複数の作業を平行してやってるため、「あ、しまった。この変更はこのブランチじゃなかった」と今週だけで 3 回は叫び、git stash -> git checkout XXX -> git stash pop を繰り返してしまった。

会社の他の人のターミナルを盗み見ると、プロンプトの一部にブランチ名を表示している人が多かったので、やり方を調べてブログにまとめよう・・・と思ったが、すでに A Zsh prompt for Git users という素晴らしい記事があり、このとおりに設定できてしまったので、書くことがない。

現在のターミナルはこんな感じ。zsh であることを見せびらかすように、ブランチ名は右プロンプトに、目立つように赤で表示させた。ついでに時刻も表示させた。「この処理何分かかったっけ」と考えることがたまにあったので。普段は幅 180 カラムで使ってるので、これでも全然狭くない。

ついでに GNU screen のステータスバーの表示も少し見直した。直前のコマンドが "cd" なら異動先のディレクトリ名を表示、そうじゃなければコマンド名と第一引数を表示するようにした。ただし第一引数がハイフン '-' で始まる場合は引数は表示しない。（今考えるとこの特別扱い不要だな）

まず、GNU screen のステータスバーを表示するように .screenrc を設定する。

hardstatus alwayslastline "[%02c] %-w%{=b bw}%n %t%{-}%+w"

次に、preexec_update_screen_status というファイルを作り、

emulate -L zsh
local -a cmd; cmd=(${(z)2})
case $cmd[1] in
  cd)
      if [[ $#cmd -eq 2 ]]; then
        echo -n "^[k$cmd[2]^[\\"
      else
        echo -n "^[k$HOME^[\\"
      fi
      ;;
  *)
      if [[ $#cmd -eq 2 && ! ("$cmd[2]" =~ "-.*") ]]; then
        echo -n "^[k$cmd[1] $cmd[2]^[\\"
      else
        echo -n "^[k$cmd[1]^[\\"
      fi
      ;;
esac

と書いておく。"^[" はエスケープシークエンスなので注意。Emacs だと Ctrl+Q ESC で入力する。（このファイル自体もどこかからコピーした気がするが忘れてしまった）

ほとんど分かってないが、"^[k" と "^[\" で囲まれた文字列は、（普通に出力されるのではなく）ウィンドウのタイトルに設定されるようだ。で、hardstatus で設定した "%t" が、「ウィンドウのタイトルをステータスラインに表示する」という意味らしい。（余談だけど、エスケープシークエンス・コントロールシークエンスは複雑すぎて覚える気にならない）

最後に、この preexec_udpate_screen_status 関数を、コマンド実行直前に評価するように、以下の内容を .zshrc に追加する。

typeset -ga preexec_functions
case "$TERM" in
screen)
  preexec_functions+='preexec_update_screen_status'
  ;;
esac

$TERM で場合分けしないと、screen 使ってないときに表示が乱れる。

というようにツールを整備したので、来週は効率10倍で働いてコミット10倍します。あ、まだエイプリルフールじゃなかったか。来週は効率1.05倍で働いてコミット1.05倍します。[追記: 日本ではすでに 4/1 だった。]

zsh とか screen とかもっと便利に使える気がするが、あとどれだけ時間をかければ何が得られるのか分からないので時間のかけようがないのがつらいところだ。