2015年12月30日水曜日

2015 年を振り返って

残すところ 1 日となったので、2015 年を振り返ってみたいと思います。

仕事

インフラ関係

実りある一年でした。3 点目の experiment framework は game changer だった。コロンブスの卵というやつ。
  • tail latency(リクエスト 100 個のうち最も遅いやつの処理時間)の改善
  • アプリケーション sharding を動的に変更する
  • システムレベルの変更を実験できる experiment framework の実装

開発体制の改善

各チームの責任範囲の明確かなど。
"It's wise to structure organizations the way you'd like to structure your software architecture" という人もいるように、システムとそのシステムの開発組織との対応関係を明確にすることは開発をスケールさせるためにとても重要。どこで聞いたか忘れたけど「大規模システム開発はエントロピーとの戦いだ」という言葉もある。
マイクロアーキテクチャは一つのソリューションだろうけど、マイクロアーキテクチャにそぐわないシステムもあるので、パフォーマンス上の理由とかで。

プロダクト

(振り返ってみると意外に)プロダクトに関わってた。カルーセル、ユーザープロファイルへの広告表示、ビデオ広告、Promoted Moments などなど。


2016 年は選択と集中をもっと頑張らないと。「コードレビューは(自分がレビューしたいもの以外は)しない」とか「個人宛にきた質問はチーム全体にふる」とかやってるけど、まだまだ時間が足りないなぁ・・・。

家庭

第二子誕生

一人目の経験があるので、二人目は何かと楽ですね。とはいえ、小さいのが二人いるとプライベートな時間がなくなるね。


第一子がプリスクールに

日本語・英語環境のプリスクールに通い始めました。Montessori のプリスクールなのでいろいろ勉強(「お仕事」という)しているようです。ある日突然「南エリカ」とか言い出すから新しい友達かと思ったら「南アメリカ」のことだった。「世界地図をトレースする」という仕事があるらしい。

家を購入

メンテナンスがとてもめんどくさい。近いうちに売ってしまうかもしれない。「家をメンテナンスする」という仕事は自分に合ってないようだ・・・。

交通事故に遭う

もらい事故。保険屋と話したり、車を修理屋に持ってったり、大変だった。


2016 年は、まぁ粛々と・・・。こどもが大きくなってきたのでバケーションに時間をとるようにしたい気もするが、子供とどっか行く方がストレス大きいような・・・。

2015年11月15日日曜日

Facebook のトリコロール機能は有料にすべき

Facebook で自分のアイコンにトリコロールを重ねられる機能について。

なぜフランスだけなのかとか、フランス(を始めとする先進国)も空爆によって無差別殺人してるじゃないかとかいう指摘はもっともだと思うが、正直それを議論し始めると何も行動できないし、もっと正直に言うとこの程度のダブルスタンダードは今の所諦めるしかないと思う。世界は(まだ)公平じゃない。

私が思ったのは「この機能は有料にすべきだ」ということだ。具体的には「$10 寄付すれば、3 日間あなたのアイコンにフランス国旗を重ねて表示します」というのが良いと思う。理由は 2 つある。

まず、この機能の目的が、フランス人に対する哀悼の意であろうが、反テロリズムの意思表示であろうが、具体的な活動にはお金が必要だということだ。被害者の救済にしても、テロリズムの根本的な解決(それが何なのかわからないが)にしてもお金がないと活動できない。

そして、この機能が無料であることで、トリコロール化した人が本当に哀悼の意を表しているのか、テロ反対を表明しているのかよくわからなくなってるというのが勿体ない。「$10 もったいないから、トリコロールいらないや」という人がいたら、大して被害者のことも気にしてないし、テロ行為にも興味ないんだな、と私は思う。極端な話、テロリストだってアイコンをトリコロールにしてるかもしれない。その人が本当にある主張に賛同してるのかどうかを確認する最も確実な方法は、お金を払わせることだ。

Facebook の月間アクティブユーザーは 15 億人なので、10% が $10 寄付したら 15 億ドル。これだけあれば何か意味のあることができると思うんだけどね。少なくともアイコン変えるだけよりは、世界変えられる可能性が高いよね。


・・・というようなことは Facebook 社内でも議論されたんじゃないかと思うんだけど、なんで実装されないのかな。ちなみにこれ実装すると、ユーザーのクレジットカード情報も取れるから Facebook としても嬉しいと思うんだけど。

2015年5月24日日曜日

動物園の入場料比較

子供がいると、休日を何もせずのんびり過ごすというのが不可能になり、何かしないといけなくなる。で、今日は Oakland Zoo に行ってきた。以前に San Francisco Zoo にもいったことがあるので、この辺(SF 及び北東地域)の Zoo は制覇したことになる。


ふと気になって、動物園の入場料について調べてみた。メインの客は小学生だろうと仮定して、大人の入場料と小学生の入園料は以下のとおり。

(日本の動物園のうち、富士サファリパークは私立、他は公立)

日本の公立動物園の入園料の安さは一見して明らかだ。
誰でも入園できるようにという意図なのだろうが、赤字分は税金から補填されているはずで、それは公平な税金の使い方だとは思えない。動物園に行ったこともない納税者も多いだろうに。

そもそも動物園に行くという行動の価格弾力性は低いと思う。メインの客が子供を連れた家族だと仮定するなら、個人的な経験から言うと、入園料よりも例えば移動にかかる時間や移動の手間の方が負担だ。
子連れで(特に東京では普通であろう)電車で移動するのはとても苦痛だ。乗り換えの手間や車内で静かにさせる手間を考えれば、入園料が 600 円だろうが 1,200 円だろうが大して問題ではない。
また、「入園料が 1,200 円なら年 1 回しか行かないけど、600 円なら 2 回行く」というのも考えづらい。だったら 1,200 円に設定した方が良いだろう。受益者負担の原則にも則っている。

まぁ東京都はお金持ちなのでいいとしても、財政危機の横浜のズーラシアは入園料を見直した方が良いのでは・・・。

2015年5月23日土曜日

アメリカで交通事故にあった話(その 2)

MetLife のウェブサイトから事故のレポートをしたところ、約 3 時間後に電話がかかってきた。
簡単に事故の内容を伝えたあと、修理費用を見積もるという話に。「一番簡単な方法は、iPhone アプリで写真を撮ってこっちに送ることね」ということなので、その方法ですすめることに。
MetLife Choice Express というアプリをインストールして起動すると、「オドメーターの写真を撮れ」「故障箇所全体写真を撮れ」「ディテールの写真を 4 枚撮れ」との指示が。そのとおりすると、「24 時間以内に見積もり送るから待っとけ」というメッセージが。
修理の見積もりだって簡単に取れちゃうんです、そうアイフォーンならね。(注:android 用もあります)



2 時間後に notification があり、見積もり完了。これを修理屋に持っていって作業を依頼した。
「どのくらい時間かかるの?」「はっきりとしたことは言えないけど、今見えてる部分の修理だけでよければ、3, 4・・・」「(3, 4 時間か?)」「3, 4 日かな」「3, 4 日!!!」
そんなにかかるのかーーー。レンタカー必要じゃん。それも MetLife に連絡しなきゃ・・・。車の修理って時間かかるんだな・・・。数時間トンカンすれば直せるのかと思ってた。無知って怖いわ。

ちなみに、もし、実際の修理費用がこの見積もりを上回る場合は、修理屋が MetLife と話してくれるそうだ。まぁこれ以上面倒なことにならないよう祈るのみ。

2015年5月22日金曜日

アメリカで交通事故にあった話(その 1)

ベイエリアは公共交通機関が比較的発達している、とはいっても所詮アメリカなので、車を運転する機会が多いのですが、ついに昨日(軽い)交通事故に巻き込まれました。日米通算で初事故。私の過失ではありませんが。

この辺りで信号待ちで止まってたら、急に「ドン」という衝撃が。バックミラーには、「やっちゃた・・・」という顔の後続車のドライバーが映ってました。

「保険会社とかと話さないといけないのか。めんどくさー」と思いつつ、車をおりると、向こうのドライバーも降りてきた。
"Hey. are you ok? I'm so sorry."
えー「事故を起こした時に "I'm sorry" というと自分の責任を認めたことになるので、言ってはいけない。全部保険会社に任せること」が私の中での「アメリカでの交通事故」の常識だったのですが、ふつうに "I'm sorry" と言ってましたね。(後で調べたところ、California や Massachusetts には「"I'm sorry" は法廷での証拠として使えない」という法律があるみたい)
こういう "I'm sorry" には何て答えればいいんですかね? 普通なら "it's ok" とか "no problem" とか言うんだけど、この状況では明らかに使えないし・・・。

と困っていると、相手は事故慣れ (?) してるようで「免許証と自動車保険証ある? 交換しましょう」と促されるままに、免許証と保険証の写真を携帯で取り合う。
「事故初めてだから、どうして良いかわからないんだよね」と素直に伝えると「保険会社に連絡しても良いんだけど、保険使うとプレミアムが上がるかもしれないから、私が直接払っても良いよ。これは完全に私が悪いし。あと証拠にお互いの車の傷の写真を撮っておきましょう」と、やけに手際の良い相手。
車は軽傷だったし、プリスクールの迎えで急いでたので、「どうするかまだ決めてないけど、決めたらまずあなたに連絡するよ。連絡先教えて」とメールアドレスを交換して、その場は終わり。

振り返ってみると、写真撮るだけではどちらの責任かわからないし、今は「私が悪い」って言ってるけど、あとで態度変えられたら泣き寝入りのケースですね。会話を携帯で録音するべきだったけど、事故の直後はそこまで頭が回らなかった・・・。

今調べたところ、車後部の衝突 "rear-end collision" は "No-doubt liability" に該当し、大抵のケースでは後ろからぶつかった側の責任になるみたい。"A basic rule of the road requires a vehicle to be able to stop safely if traffic is stopped ahead of it." 「基本的には、前の車がいかなる理由で止まっても、安全に停止できなければならない」

あと「California では、軽微な事故で警察呼んでも来てくれない」という情報もあったんだけど、本当かな? 財政難だから? 複雑なケースだったら事実認定は誰がするんだろうか?

翌日(今日)近くの修理屋に行って車を見せて「こういう事故で、こういうダメージがあって、相手は直接払うって言ってるんだけど、どうかな?」と聞いてみた。
親切なお兄さんによれば、「保険会社に連絡したほうが良いよ。小さなダメージに見えるけど、マフラーがすこし曲がってるし、内部にも損傷があるかも。保険はどこ? MetLife と XXX だったら、MetLife の方が対応が良いから、オレならそっちに連絡するね。」とのことだったので、MetLife のウェブサイトの "file a claim" で事故を報告したところ。

ああー、やっぱりめんどくさい・・・。(続く

2015年5月21日木曜日

日本人におすすめの店 in Berkeley

Berkeley に引っ越してもうすぐ 1 年が経つ。日本人的には、Berkeley というと UC Berkeley が有名だが、私が住んでるのは North Berkeley と呼ばれるところで、UC Berkeley から車で 20 分ぐらい北西に行ったところ。Albany という町との境目に近い。Albany は日本では聞いたこともない小さな町だが、学区が良くて、不動産も高い。

San Francisco からの引っ越し先を探していた 1 年前、たまたま Albany の Marin Avenue を通ったときに、街並みが気に入ってこの辺に住むことに決めた。
引っ越してから気がついたが、日本人向けの店が多くて住みやすい。
ということで、まとめてみた。

North Berkeley 周辺の地図。自宅は中央のモザイクがかかってるエリア :)

Monterey Market
うちから歩いて 3 分のところにある grocery store。創業者が日本人だそうで、外壁にデカデカと家紋がついてる。安い。日本野菜(大根とか)も売ってる。

Tokyo Fish Market
これも grocery store。Tokyo という名前の通り、日本の野菜、お菓子、冷凍食品が売ってる。fish market というだけあって(日本ほどじゃないが)魚介類が多い。

Yaoya-San
「八百屋さん」という名前だけど、肉も乳製品もお菓子も売ってる普通の grocery store。
San Francisco 周辺で最も「日本のケーキ」っぽい Patisserie Norina のケーキが買えるのイーストベイではここだけ。毎週火曜日と土曜日。

Berkeley Bowl
大きな grocer store。どういう関係か知らないが、ここも日本野菜、冷凍食品が売ってる。他ではなかなか見つからない大豆の水煮缶も売ってる。

Whole Foods Market
みんな大好き Whole Foods。品質も値段も高い。ここに入ってるパン屋のブリオッシュがとても美味しい。

Kiku Sushi
寿司屋。今日初めて行ったら、美味しくてびっくりした。青魚もあります。5 月だから鯉のぼりが飾ってあった。

Ippuku
焼き鳥屋(日によってそば屋)。焼き鳥は普通に日本の焼き鳥。「ぼんじり」などもある。そばは食べたことがないけど期待できる。

Iyasare
おしゃれな日本食や。なんでも美味しい。ラーメンも美味しい。うな丼もあるので、いつか試してみたい。

Kirala
レストランと togo 専門店とがある。togo しかしたことないけど、カツ丼とか天丼がある。日本のコンビニぐらいの味。手っ取り早く日本の味が食べたくなったときに。

Kim's Cafe & Sandwich
ベトナムサンドイッチや。安くて美味しい。東南アジア系の店はハズレが少ない(= 日本人の味覚に合うことが多い)気がする。

Pedro's Brazil Cafe
ブラジルサンドイッチ(というジャンルがあるのか知らないが)や。タコスやブリトーの皮をパンに変えた感じ (?)。美味しい。

Zachary's Chicago Pizza
"deep dish" スタイルのピザ。「美味しんぼ」で見たときから一度食べてみたいと思ってて、ようやくここで食べれた。ものすごい量のソースが入ってるけど、しつこくなくて美味しく食べられる。

Gioia Pizzeria
もう一つのピザや。こっちは「一切れ $2」とかで買えるアメリカンスタイル。美味しい。

Philz Coffee
有名コーヒー屋。いつも「今月のおすすめコーヒー豆」を買ってる。ここのコーヒーは(新鮮な豆で淹れると)ちゃんと「豆」の香りがする。

Happy Donuts
よくあるドーナツやと思いきや、他のドーナツ屋(例えば T 社のとなりのとなりにあるドーナツ屋)より確実に美味しい。Krispy Kreme Donuts の方が好きだけど、こっちの方が安い(し、Krispy Kreme Donuts は近くにない)。


Berkeley にお越しの際は、食をご堪能ください。

2015年5月20日水曜日

経済的弱者と自己責任論と経済格差

なぜ若者は遣い潰されるのか -- 日本のアニメはブラック業界」を読んだ。多くのアニメーション製作者が、社員ではなく個人事業主であるとは知らなかった。社員であれば(雇用されていれば)最低賃金や労働時間などについて労働法で保護されるが、個人事業主には適用されないため合法かつブラックな状況にあるようだ。

社会に出たての若者に「君たちは労働者ではなく個人事業主である」と刷り込んで、ひどい環境に追い込むのはもちろん(違法ではないにしろ)ブラックだが、それは根本的な問題ではない。社員になるか個人事業主になるかは自由な選択であるべきだし、そもそもブラックな環境からは人が減るべきで、人を採用するために環境がホワイトになっていく、というのがあるべき姿だ。
であるのに、この環境が改善されない原因は 3 つあると思う。

流動性のない労働市場

今更書くこともないが、転職が一般的でない状況では、「アニメ業界はブラックだから転職しよう」という意識が生まれない。生まれたとしても受け入れる業界がない。アニメ業界でしばらく働いて「この業界はやばい」と気がついたときには、もう逃げ道がなくなっている。

「好きなことを仕事にしよう」 教

よく似た宗派に「お金のために働くのは悪だ」教がある。これを布教してるのは、「好きなことを仕事にして」成功した(またはそれなりに暮らせている)人である。これで幸せになれる人は限られている。
まず、「ユーザー・顧客として好きなこと」と「働くのが好きな業界」とは異なるのが普通だ。「アニメが好き」だからといって「アニメ業界で働くのが好き」ということにはならない。現にそうではない人が多いから問題になっているわけで。
私はゲームが好きだが、ゲーム業界で働くのが楽しいとは思えないし、読書(オンラインのも含めて)が好きだが、執筆者・編集者になろうとは思わない。(自分では)稼げなさそうだからだ。優れたゲームデザイナーになれるとも思えないし、出版業界はそれ自体が斜陽産業に見える。

そうではなくて「お金を稼げる仕事をしよう」と言うべきだ。「社会に貢献できる仕事をしよう」と言い換えてもいい。資本主義社会では基本的に同じことだけど。

この教えを信じた人がアニメ業界に吸い込まれて、気付いた時にはもう手遅れなのだとしたら、救いのない話しだ。
などと書いている私も、学生時代に深く考えることなく、好きなこと(プログラミング)を仕事にした。今それなりに豊かな生活が送れているのは単に幸運だったからだと言える。

経済的弱者への厳しさ

もとの記事でも触れているが、こういう状況に対して「それは自己責任だから」という反論が考えられる。アニメ業界に就職したのはたしかに自分の選択の結果だが、最初の就職先がブラックで、転職も難しい状況で、それを自己責任で片付けるのは厳しすぎる。政府の警告を無視して紛争地帯に行って捕虜になるのとは話が違う。

たいした根拠のない主観だが、この「弱者に対する厳しさ」は、強者と弱者との差が小さいからではないかと思う。弱者と自分との差が大きくなければ、例えば年収 300 万円と 200 万円なら、「おれは努力してるから 300 万円を稼げるんだ。あいつらも努力すればできるはずだ。援助は不要だ」という考えに至ってもおかしくない(気がする)。これが年収 2000 万円と 200 万円なら「200 万円で生活してる可哀想な人たちのために何かできることがあるはず」という憐憫の情になり、自己責任を持ち出したりしないのではないか。

先日、職場のメーリングリストにこんなメールが流れた「オフィスの前の通りにいつも座ってるホームレスは、今日が誕生日なんだって。みんなでケーキを買ってプレゼントしない?」このスレッドはかなり長くなり、結局何人かがケーキを買って写真を取っていた。
正直言って、このメールをみたときに違和感を覚えた。今日ケーキを買ったところで彼の生活は何も変わらないし、彼がホームレスをしている原因の一つが、われわれソフトウェアエンジニアの高給と、それによる San Francisco の物価高騰であることは間違いないだろう。
しかし、平均年収約 $130,000 のソフトウェアエンジニアは、多分 $10,000 もないだろうホームレスに「自己責任」は求めないし、(どの程度の覚悟があるのかはわからないが)「助けてあげたい」と思っているようだ。

若干(かなり?)こじつけ感のある話だが、ようするに「もっと格差が大きくなれば、『自己責任論』を持ち出す人は減るのでは?」と思ったのだった。でもそうなる前になんとかしないといけないんだけどね。(Wikipedia にあった国別ジニ係数の推移。 )
経済格差を示すジニ係数。日本は上昇中で 0.28 @ 2005。アメリカは 0.4 に近い。


2015年5月19日火曜日

Raft: もう一つの consensus algorithm

Paxos について調べていたら、Raft という別の Consensus Algorithm にたどり着いた。Raft は「理解しやすさ」を重視して設計したそうで、Paxos について
Paxos is exceptionally difficult to understand. The full explanation [15] is notoriously opaque; few people succeed in understanding it, and only with great effort.
Paxos を理解することは並外れて難しい。正確な説明は極めて不可解で、ほとんどの人は理解できない。できるとしてもものすごい努力を要する。
と批判している。「よく分からん」 と思ったのは私だけではないようだ。

また、Chubby の実装者のコメントを引用している。
There are significant gaps between the description of the Paxos algorithm and the needs of a real-world system. . . . the final system will be based on an unproven protocol [4].
Paxos アルゴリズムの記述と実世界のシステムとの間には 大きなギャップがあり、最終的に構築したシステムは、証明されていないプロトコルに基づくことになった。
たしかに、Paxos の論文は数学的なので、そのまま実装できるものではなかった。

で、Raft の論文を読むと、これがとてもわかりやすい。まずプロトコルを説明して、それから safety を証明する、という computer science の人に優しい構成になっている。一読して理解できたので、Paxos のように「解説の解説」を書く必要がない。

面白かったのは、「Raft は Paxos より理解しやすい」ことを実証するために、Stanford と UC Berkeley の学生に、解説ビデオを見せ、その後にテストを行い結果を比較したということ。当然 Raft のほうが成績がよかったそうだ。まあそうだろうな。

2015年5月18日月曜日

Paxos の解説の解説(その 4)

前回 proposer の振る舞いは説明したので、次は acceptor の説明。

"prepare" request と "accept" request のどちらについても、acceptor は自由に無視できる。無視してもアルゴリズムが誤動作することはない。
"prepare" request を無視すると、proposer は(前回説明した)集合 S を作れなくなり、その提案は破棄される。つまり、合意を取るのが遅れることになるが、誤った値が選択されることはない。
"accept" request を何人かの acceptor が無視し、半数未満の acceptor だけが受理したとする。すると、「値 v がいくつかの acceptor によって受理されるが、全体としては選択していない(合意していない)」という状況が生まれる。これは問題だろうか?
当然ながらこの提案は「選択」されない。ではどういう影響があるかというと、この提案が現時点で最大の proposal number を持つので、次の "prepare" request のときに、値 v が proposer に返される。そして、ペアとなる "accept" request で過半数の acceptor が v を受理することになる。もしかしたら、いくつかの acceptor が "accept" request をまた無視するかもしれないが、何ラウンドか繰り返すことで、いつかは過半数を達成するだろう。なので、これは問題なさそうだ。

(これは私の理解であって、解説には書いてないが)結局 Paxos プロトコルは proposer が acceptor を「説得」していく手続きだと思う。proposer の競合やネットワーク障害によって、1 ラウンドの "prepare"/"accept" request では合意に達しないことがある。そのときは、次の "prepare" request が「最も最近発行された(が合意に達しなかった)値を再提案し、より多くの acceptor に受理させる。」そうすれば、いずれ過半数の acceptor が受理し、合意に達するだろう、というのがポイントだ。
もちろんこのプロトコルが停止することは保証されてなくて、それは解説でも触れられている。2 つの proposer が "prepare"/"accept" を順番に発行すると、いつまでも合意に達しない。(「停止性」を保証した改良版 Paxos もあるらしい)

話を元に戻すと、acceptor はリクエストを自由に無視できる。逆に無視しなくてはいけないリクエストがある。proposal number N の "prepare" に応答したらそれ以降は、proposal number が N より小さいリクエストは「無視しなくてはいけない」。それ以外の場合は受理して良い。
直感的には、"prepare" request とは、proposal number N 未満の世界において過半数の acceptor の集合を確認する操作なので、これを応答した後に、N より小さいリクエストによって状態を変えてはいけない、ということになる。

これを acceptor への条件として要請する。
P1a. acceptor は、proposal number N より大きい "prepare" request を受け付けてないとき、そのときのみ、 proposal number N のリクエストを受理する。
これは「P1. acceptor は最初に受け取った提案を必ず受理する」より厳しい条件である。

この条件によって、acceptor が proposal number N の "prepare" request にすでに応答している場合は、N 未満の "prepare" request は無視して良い、という最適化が可能になる。というのは、仮に "prepare" request M (M < N) に応答したとしても、ペアとなる "accept" request は無視しなくてはならないからだ。(なので、"prepare" request に応答する意味がない)


以上で、最初のエントリの最後に書いたプロトコルで、正しく合意が取れることがわかった。

2015年5月17日日曜日

Paxos の解説の解説(その 3)

前回のエントリで、このプロトコルは、
P1. acceptor は最初に受け取った提案を必ず受理する
P2b. 提案 [m, v] が選択されたとする。ある proposer が n > m となる提案 [n, u] を発行するならば n = v である。
という 2 つの条件を満たせば良いことがわかった。

P2b を満たすには、proposer は、すでに選択されている値 v を、新しい提案を発行する前に知らなくてはならない。どうすれば v を知ることができるのか? その前に、ある提案があったときに、P2b を満たしているかどうか証明する方法を考える。

まず簡単のために、P2b の仮定を拡張し「提案 m, m+1, m+2, ..., n-1 が全て、値 v を持つ」とする。つまり、
P2b'. 提案 [m, v], [m+1, v], [m+2, v], ..., [n-1, v] が選択されたとする。提案 [n, u] が発行されるならば、u = v である。
また、一般に提案が選択されるには、過半数の acceptor から成る集合 C が存在し、C の要素である acceptor は全てその提案を受理しなくてはならない。これと P2b -> P2b' の拡張とを組み合わせると、P2b' の前提部分は次のように書き換えられる。
提案 [m, v], [m+1, v], [m+2, v], ..., [n-1, v] が選択されたならば、過半数の acceptor からなる集合 C が存在し、C の要素である acceptor は、提案 m, m+1, m+2, ..., n-1 を受理する。また m, m+1, m+2, ..., n-1 は値 v を持つ。
ここから、P2b を満たすには P2c を満たせば良い、と書き換えられる。
P2c. 提案 [n, v] を発行するときには、以下の条件を満たす、過半数の acceptor から成る集合 S が存在する。
  • S のどの要素も proposal number が n 未満の提案を受理していない、または
  • S の各要素が今までに受理した n 未満の提案のうち、proposal number が最大の提案は値 v を持つ。
ここは理解が難しいので、逆向きにも考えてみる。つまり、P2c が満たされたら、P2b がなぜ満たされるのかを考えてみる。

まず、「S の各要素が今までに・・・最大の提案は値 v を持つ」ような S が存在せず、「S のどの要素も proposal number が n 未満の提案を受理していない」ような S しか存在しないとする。ということは、n 未満の提案は、発行されていないか、されたとしても半数未満の acceptor にしか受理されていないことになる。したがって、まだ何も選択されていないことになる。この場合は P2b の前提「提案 [m, v] が選択されたとする」が成立しないので、P2b 全体は成立する。

つぎに「S の各要素が今までに受理した n 未満の提案のうち、proposal number が最大の提案は値 v を持つ」ような S が存在したと仮定する。この「proposal number の最大値」を Mn とする。帰納法の仮定により、提案 Mn が少なくとも 1 つの acceptor に受理されたことから、Mn は選択されたことがわかる。

  • Mn == m の場合、提案 [Mn, v] (つまり [m, v])を過半数の acceptor が受理していたことになるので、P2b が成立する。
  • Mn < m の場合、提案 m は選択されなかったので、上と同様の議論で、P2b は成立する。
  • Mn > m の場合、再帰的に P2c を適用することで、P2b が成立することがわかる。

これで、P2c を満たせば、P2b が満たされることはわかった。(この部分を正しく理解できているか怪しい)

したがって、P2c を満たせるようなプロトコルを考えればよい。これが、最初に説明した "prepare" request と "accept" request の 2 種類のリクエストとなる。
"prepare" request は、acceptor に対して「すでに提案を受理したか」「受理したとしたら受理した値は何か」を確認し、P2c における集合 S を確定するためのリクエストだ。注意が必要なのは、非同期なネットワーク通信を仮定しているので、proposal number n を処理した後に、n より小さい提案が届く場合があるということだ。そのため、"prepare" request は「今後 n 以下の request は受理しないように」と要請する必要がある。

これで、proposer のあるべき振る舞いはわかった。あとは acceptor の挙動と、ちょっとした optimization について論じている。それはまた次に。

2015年5月16日土曜日

Paxos の解説の解説(その 2)

前回の続きで、Paxos プロトコルの正しさについて、この解説をもとに解説する。

まず、acceptor が一人しかいない世界を考える。この世界では簡単に合意が取れる(その acceptor が選択した値がただ一つの「合意した」値となる)が、この acceptor が single point of failure となるので良くない。したがって acceptor が複数動いている状況を考える。この状況では、以下の 2 つのルールを守れば、「選択される値は 1 つだけである」という要請を満たせる。(が、以下に書くように、このルールでは結局うまくいかない)

  • acceptor はたかだか 1 つの値しか受理しない
  • 過半数の acceptor が値 x を受理した時に値 x が選択される
この状況において、2 種類以上の値が選択されることはない。

つぎに、proposer が一人しかいない状況で、この proposer が値 x を提案したとする。ネットワーク障害やプロセスダウンなどがない完璧な世界では、x は選択されなくてはならない。そうでないと、いかなる提案も無視されることになり、合意は全く成立しない。したがって、このプロトコルは、
P1. acceptor は最初に受け取った提案を必ず受理する
という条件を満たす必要が有る。
が、しかしこれだけでは十分ではない。2k 個の acceptor が存在する状況で、2 種類の値が同時に提案され、それぞれ k 個の acceptor が受理すると、どちらも過半数に達しないので、どの値も選択されない。

「acceptor は最初に受け取った提案を必ず受理する」という条件と、「過半数の acceptor が値 x を受理した時に値 x が選択される」という条件とを満たした上で、なんらかの値が選択されるために、「acceptor はたかだか 1 つの値しか受理しない」というルールを破棄し、「acceptor は一つ以上の値を受理できる」こととする。
つまり、「acceptor は最初に受け取った提案を必ず受理する」と「acceptor はたかだか 1 つの値しか受理しない」とを同時に要請すると、「最初に受け取った提案を受理し、その後は何もしない」という意味になり、上記の「2k 個の・・・」の例で行き詰まってしまう。

ここまでの議論で、1 つの proposer は複数の提案をする(可能性がある)ことになった。そこで、複数の提案を区別するために、proposal number を導入する。proposal number は自然数とする。また同じ propose による異なる提案は、 異なる proposal number を持つものとする。
つまり、「提案 (proposal)」とは「提案される値 v」と「proposal number n」とのペアとなる。これを [n, v] 書くことにする。「提案」と「提案される値」とを分けて考えることに注意する。acceptor は複数の「提案」を受理することができるが、受理された複数の「提案」は、同じ「提案される値」を含まなくてはならない。したがって、
P2. 提案 [n, v] が選択されたとする。m > n となる提案 [m, u] が選択されたら、u = v でなくてはならない。
という条件が要請される。この条件によって「選択される値は一つである」という要求を満たすことができる。

値が「選択」されるには少なくとも一つの acceptor に「受理」されなくてはならないので、以下の P2a を満たせば P2 を満たすことができる。(P2a は P2 より厳しい条件である。)
P2a. 提案 [n, v] が選択されたとする。m > n となる提案 [m, u] が任意の acceptor に受理されたら、u = v でなくてはならない。

さて、ここで次の状況を考える。
  • 提案 [n, v] がすでに選択されている(= 過半数の acceptor が受理した)
  • acceptor c は(例えばネットワーク障害により)これまでに全く提案を受理しなかった。したがって も受理していない。
  • 新しい proposer が起動し、[m, u] を提案した (m > n and u != v)
この場合、「P1. acceptor は最初に受け取った提案を必ず受理する」というルールにより、c は [m, u] を受理してしまうが、これは P2a に反する。したがって、P2a では不十分だとわかったので、さらに条件を厳しくする。
P2b. 提案 [n, v] が選択されたとする。m > n となる提案 [m, u] が任意の proposer によって提案されたら、u = v でなくてはならない。

P2b を満たすには、proposer は、提案する前に現在選択されている値 v を知らなくてはならない。(そうでないと u != v となる u を提案してしまい、P2b に反する)
どうすればこれが実現できるのか・・・、は次回に続く。

2015年5月15日金曜日

Paxos の解説の解説(その 1)

Google の distributed 系の論文を読んでるとほぼ必ずでてくる Paxos。複数のプロセス間で合意を取るためのプロトコル (consensus protocol) で、リーダー選出などに使われる。
元論文はこちらだが、これが一般人には分かり難かったらしく、同じ著者 Leslie Lamport が解説を書いているので、こっちを読んでみた。

まず基本的な概念から。なお以下で、「値 x が選択される」とは「値 x で合意が取れる」と同じ意味である。
3 種類のエージェントを考える。proposer は値を提案する人。acceptor は提案された値を受理する(もしくは受理しない)人。learner は選択された値を受け取る人である。(実際には一つのインスタンスが複数のエージェントとして振舞うことがある)
ただし、learner については難しいことはないので、特に説明しない。複数の proposer が提案する値の中から、どうやって一つの値 x で合意するか、というのが目的となる。

シンプルだが正しく動かない例を挙げてみる。
2 つの acceptor a1, a2 が存在し、それぞれ最初に受け取った値を accept する(= 選択する = 合意する)ものとする。2 つの proposer p1, p2 が、同時点でそれぞれ値 v1, v2 を提案したが、p1 -> a2 と p2 -> a1 の通信が失敗したとする。すると、a1 は v1 を、a2 は v2 を「選択」してしまい、合意が取れないことになる。これは明らかに良くない。

consensus protocol が満たすべき要求は以下の 3 つだ。

  1. 選択された値は、必ず提案された値である。
    === 誰も提案していない値が選択されることはない。
  2. 選択される値は一つである。
    === みんなが同じ値に合意する。
    === 複数の値が選択されることはない。
  3. 値 x が選択されたときに限って、「値 x が選択された」という情報を受け取る
    === 偽の情報を受け取ることはない。
上記のシンプルな例は 2 を満たしていない。

答えを先に書くと、正しいプロトコルは以下の通りである。まず前提として、

  • "prepare" request と "accept" request との 2 種類がある。全てのリクエストは、提案・合意される「値」とは別に "proposal number" と呼ばれる整数を持っている。
  • proposer は整数カウンタを 持つ。これは proposal number を生成するために使われる。
  • acceptor はいかの 2 つの値を記憶している。
    • これまでに受け取った "prepare" request のうち最大の proposal number。これを Mp と呼ぶ。
    • これまでに受理した「値」とその proposal number。これを Pa と呼ぶ。ただし、まだ何も受理していない場合は Pa = null となる。
このプロトコルは 2 つのフェーズから成る。

Phase 1: prepare phase
  • proposer は proposal number N の "prepare" request を(少なくとも)過半数の acceptor に送る。
  • acceptor は、N <= Mp であれば、この "prepare" request を無視する。N > Mp の場合は、Pa をレスポンスとして送り返す。
Phase 2: accept phase
  • proposer は、"prepare" request に対するレスポンスを過半数の acceptor から受け取った場合は、proposal number N と提案する値 V の "accept" request をその acceptor に送る。V は以下の条件で決まる。(なおレスポンスが過半数に満たない場合は、この「提案」は失敗なので、カウンタを increment して Phase 1 からやり直す。)
    • 一つ以上の acceptor が Pa != null を返した場合は、複数の Pa のうち、最大の proposal number を持つ Pa の値とする。
    • 全ての acceptor が Pa == null を返した場合は、proposer は任意の値を V とする。
  • acceptor は、proposal number N の "accept" request を受け取ったら、N >=(現時点での)Mp なら、値 V を受理する。N < Mp なら無視する。

このようにプロトコル自体はとてもシンプルである。問題は「このプロトコルでなぜ正しく合意が取れるのか」であり、この解説もそこにページ数を割いている。「正しさ」については次のエントリで書きたい。


2015年5月14日木曜日

"The Age of Diminishing Expectations" の切り抜き

ktdiskのブログ」のどこかに書いてあった(記事が見つからない)ように、読んだ本で気になったところを記録する試みを始めようと思う。あんまり本読まない(←良くない)が。とりあえず昔読んだ本から。

クルーグマン教授の経済入門

なぜか手元に見当たらないので、英語版と私の拙い訳でどうぞ。

The Age of Diminishing Expectations -- Paul Krugman

P.18
This is not an answer that inspires fervent political support -- especially when one bears in mind that the causes of the productivity slump are not obviously tied to declining investment in plant and equipment or in education. In fact, the American economy placed about as high a share of its resources into investment, and a higher share into education, in the 1970s and 1980s as it did in the 1950s and 1960s. It just didn't work as well.
拙訳([] 内は私の注釈)
これ [= 生産性向上のためには、今の消費を抑えて投資に回すこと。そうすればいつかはわからないけどいずれ生産性は上がるだろう] は、政治家が熱烈に支持するような答えではない。生産性の落ち込みが、工場・設備投資や教育への投資と結びついていることが明らかでない状況では特に人気がない。実際のところ、アメリカ経済は [生産性が伸びた] 1950 - 60 年代と同等の投資と、それ以上の教育費を 1970 - 80 年代に費やした。でも、生産性は向上しなかった。

これは "Productivity Growth " という章の一節。この章は「生産性は [経済の] 全てではない。でも長期的には生産性でほぼ全て決まる」から始まる。そして「でも、経済学者は、生産性がなぜ落ちるのか、どうしたら向上するのかを説明できない。」と続く。
「重要なことが説明できないから、みんな重要じゃないことを議論するんだ。たとえばインフレとか国際競争とか。」と、何が本質的で何が枝葉かと明快に(そして軽快に)説明できるところが素晴らしい。書いてるのが、怪しい経済評論家(笑)じゃなくて、ノーベル経済学賞を受賞したクルーグマンなので、信頼できる(と思ってる)。

2015年5月13日水曜日

現役 / 老人比率が 1.2 になる国

デマこい! - いま失敗すれば、日本終了。」から抜粋
1.2 人
何の数字か、お分かりだろうか。

2050年における現役世代と老後世代の人口比だ。現在の日本では現役世代2.4人で老人1人を養っている。しかし、2050年にはこれが半分になり、現役1.2人で老人1人を支えることになる。私たちの子供世代は高額の社会保険料と重税に苦しめられ、優秀な人から順番に海外に脱出するだろう。国民皆保険は、たぶん崩壊する。年金は、おそらく有名無実のものになる。
1.2 というのはスゴイ数字だ。現役世代のほぼ全員(6 人中 5 人)に老人 1 人が割り当てられ「この老人の面倒をみてくださいね、あなたの負担で」ということだ。(現状の 2.4 も十分キツイ数字なのだが)

著者の主張はこうだ。

  • 出生率をあげて現役 / 老後比率を改善する
  • そのために年間所得 500 万以上の世帯を増やす
  • そのために賃上げ要求する and 女性の雇用拡大
最初の 2 点はよくわかるが、最後の点は賛成できない。
著者は労働力が不足している社会を想定しているように見える。そういう社会では労働者を確保するのが困難なため、賃上げ要求は通りやすいだろう。また、女性が雇用されることで、共働き世帯が増え、世帯収入も増えるだろう。

しかし、労働力が供給過剰な世界では、全ての労働者が一致して賃上げ要求をしない限り、要求は通らないと思われる。代替の労働力がすぐに見つかるからだ。また女性の雇用拡大した結果、男性の雇用が下がってしまっては、マクロでの家計所得は増えない。

結局、目新しくない結論だが、賃上げ要求と女性の雇用拡大の前に、企業活動を活発にして、労働需要を増やさなくてはいけなくて、そのために現実的にできることは、金融緩和ぐらいしかないのではないか。あと消費増税はするべきではなかった。片足でアクセルを踏みながら、もう一方の足でブレーキを踏むのは良くない。10% への増税が延期されたのは良い傾向だ。

折しも Facebook が契約社員の最低時給を $15 に上げたことがニュースになったが、これは Facebook がとりわけ generous な会社だからではなくて、利益をあげていて、より良い契約社員を集め、契約社員のモチベーションを高めたいからだ。


2015年5月12日火曜日

「人を蹴落として偉くなる」のか?(地獄のシリコンバレーより)

4 月中頃にベイエリアを中心に(小さく)燃え上がった「地獄のシリコンバレー」。すでに完全に鎮火した感があるけど、ちょっと気になったコメントがあったので。

上記リンクにある tweet の一つから抜粋。
これも相対評価だから、どの社員よりも自分が優れてないといけない。人を蹴落としてでも上に登りたい上昇志向で自分のスキルを常に磨く準備はあるのか。
この「人を蹴落としてでも上に登る」という意見は、何回も見た/聞いたことがある。それもアメリカで働いている人や働いたことのある人からだ。
しかし個人的には、(プロモーションも昇給も経験しているが)蹴落とした、蹴落とされたと感じたことはない。どこからこのイメージが生まれてきたのだろうか?

仮説 1. 「人を蹴落とす」業種・業界がある

完全に妄想だけど、そういう業種・業界があるのかもしれない。セールスやトレーダーなんかは蹴落としあってるイメージが私にはある。どちらもコミッションベースの給与であることが多いので、個人プレーになりやすいのかな、と思う。

エンジニアはたいていコストセンターなので、給与にコミッションが入ることはまずない。トレーディングアルゴリズムを開発・運用している会社のように、エンジニアがプロフィットセンターならありえるかもしれない。

仮説 2. 日本の大企業と比べると「人を蹴落とす」感がある

私はいわゆる日本の大企業で働いたことがないのだが、聞くところによると「年次」という概念があって、同じ年に入社した社員は全員同額の給与をもらい、全員等しく昇給していくそうだ。(もちろん役職手当とかはあるが)
こういう給与体系と比べると、(おそらくシリコンバレーでは標準であろう)「パフォーマンスに応じて job level, 給与が変わる」仕組みは、「人を蹴落とす」感があるのかもしれない。でもまぁ「パフォーマンスに応じた給料」は日本でももうそれなりに一般的だよねぇ (?)

仮説 3. 昔のアメリカは「人を蹴落としてた」

この話の他にも「アメリカでは書類を引き出しに入れて鍵を掛けてから帰る。同僚が書類を盗むかもしれないから」みたいな話も聞いたことがある。「アメリカは個人主義」というやつだ。
この手の話はいくつかあるので、そういう時代もあったのかもしれない。また、「Japan as No. 1 の時代の日本企業を研究して、『チームワーク』『会社は家族』のような考え方を取り入れた」という話も読んだことがある。なので、昔は「人を蹴落としてた」けど、今では「チームワーク重視」になった。ということがあるのかもしれない。

仮説 4. 見知らぬ社会での恐怖感の裏返し

これが結構あるのではないかと個人的には思うのだが、人はよく知らないものには恐怖感を持ち、敵意を抱きやすい。見たこともない生物が目の前に現れたら、子供なら興味を持って近づいていくかもしれないが、大人は逃げ出したり攻撃したりするだろう。
というのは極端な例だが、同じ文化の中で育った同じ民族なら、ちょっと会話をするだけで相手のことがわか(ったように思い込んだりす)るが、英語が流暢じゃない日本人が、コミュニケーションの作法が異なる外国人について「コイツ何考えてるのかわからない」と思い、自分を蹴落とそうとしてると感じることはありそうな気がする。
仏頂ずらのまま早口でまるで怒ってるかのようにまくしたててる人は結構いるし、その内容がわからず、「わからないからもう一回言ってみて」と聞き返すこともできない状況で蓄積したフラストレーションが元で、相手に悪感情を持つというのは、自分にも経験はある。


とくに結論はないのですが、「競争社会だから、蹴落としたり蹴落とされたりするんだよ」っていうのは、「アメリカ一般」には該当しないんじゃないですかね。アメリカは日本より多様性がある(と思う)ので「アメリカ一般」というのがそもそも無意味なのですが。

2015年5月11日月曜日

出生証明書と出生届

アメリカは出生地主義をとっているので、アメリカで生まれた子供はアメリカ国籍を持つことができる(出生地主義は世界の 20% 以下だそうで。少ないんですね)。一方、日本は血統主義を採用しているので、(どちらか一方の)親が日本人なら日本国籍を持つことができる。
ということで、よく知られているが、日本人がアメリカで産んだ子供は両方の国籍を持てる。

出生届を出す手続きをする部署が病院内にあって、生まれた翌日に呼ばれ、書類にサインすると 2, 3 週間後に Birth Certificate と SSN が貰える。
本当にどうでもいいトリビアだが、通常 birth certificate はカウンティ(たとえば Alameda county)の発行になるが、Berkeley の場合は "City of Berkeley" 発行になる(と日本領事館の人が言っていた)。Berkeley は Alameda county に属しているのだが。

City of Berkeley 発行の birth certificate と日本用の出生届。字が汚い・・・。

この birth certificate を持って、日本大使館・領事館で出生届を出すと日本の戸籍に登録される。
この出生届は海外向けで、「日本国籍を留保する」というような普通の出生届にはない項目がある。あと、住所は「アメリカ合衆国」から記入することになっていて、「アメリカ合衆国カリフォルニア州バークレー市アシュビー通・・・」と書くのは新鮮であった。日本語でこれを書くことはもう二度とないだろう。

日本のパスポートを撮るには、戸籍に載るのを待ち(1.5 ヶ月)、戸籍を取り寄せ(大使館・領事館では発行できないので、日本の役所に依頼する)、大使館・領事館でパスポート申請となる。たいへん。
アメリカのパスポートは・・・どうするのか知らないな。


ところで、SSN は 10 進 9 桁しかなくて 10 億しか発行できないのだが。アメリカ人口は 2 億を超えているはずなのだが。使い回すにしても、もう少し桁数がないと運用上問題が出るんじゃないですかね。

2015年5月10日日曜日

二回目の育児休暇 - 買い物リスト

4/14 に 2 人目の子供が生まれたので、このエントリに倣ってまた買い物リスト。

体重計: 生まれた直後は(一人目と同様に)母乳がうまく飲めずに体重が減ったので、またもや体重計を購入。

ミルク: 日本にもあるのか知らないけど、アメリカにはすでに液状になったミルクが売ってる。ペットボトル感覚で「開けて飲む」だけ。温めることもない。とても楽ですが、若干高いです。8 本入りで $8 ぐらい。
ただ、付属の乳首だとミルクが出すぎるので、うちでは別の哺乳瓶に移してから飲ませてます。その辺を気にしなければ、哺乳瓶を洗う必要さえないので、最高に楽なはず。

Supplemental Nursing System: 単純に上記のミルクを与えてしまうと、母乳をうまく飲めなくなる(あまり吸わなくてもミルクが出てくるため)ので、母乳育児にはよくない。でも母乳だけだと、うまく飲めないので体重が減ってしまう。というときに、この SNS (Supplemental Nursing System) の出番です。
母乳を飲むときに、写真下部の細い管を一緒に加えさせ、点滴の要領でミルクを流します。ミルクの量は手元で調整可能で、「赤ちゃんが乳首を 5 分ほど吸った後にミルクが出るように調整してください」と指導されました。こうすることで、「吸わないとミルクでないんだな」と赤ちゃんを教育しつつ、十分な量のミルクを飲めるようにするわけです。うまく飲めるようになるまで、数日間使いました。
Amazon.co.jp にもあったけど、1 万円か・・・。

哺乳瓶消毒用バッグ: 哺乳瓶を入れてレンジでチンするためのプラスチックの袋。
ただ、1 人目の子供が凶悪な汚染源になる(床を触った手で赤ちゃん触ったり、赤ちゃんに向けてくしゃみしたり)ので、2 人目になると、哺乳瓶を煮沸消毒する意味が薄れる気がしますね。前回は毎回煮沸消毒してたのに、今回は 1 日 1 回という手の抜きよう・・・。

おむつ: 高級版(上)と普通版(下)。日本のおむつの方が圧倒的に質がいいです。高い方が 1 枚あたり $0.26。以前のエントリによると「グーンプレムアム」が 1 枚 24 円だそうなので、こっちの方が高いんだけどなぁ・・・。

2015年5月8日金曜日

アメリカでの不動産購入と税効果

[Disclaimer: 私は税金の専門家ではないので、このエントリの内容が間違っている可能性は十分にあります。]

「日本の多くの会社員が年末調整だけをやって確定申告をしなくていいのは、どれだけ税金を払っているか彼らに気付かせないためである」という若干陰謀論めいた話を聞いたことがあるが、そもそもこの話の前提は「年末調整を会社が行うのは日本ぐらいだ」ということで、確かにアメリカにはそんなものはない。

私は幸か不幸か日本でも確定申告を経験したが、アメリカとの大きな違いは、控除額の多さだ。全ての納税者が一律 38 万円まず控除され(基礎控除)、いわゆるサラリーマンの場合はさらに給与所得控除で、例えば年収 1 千万の場合は 220 万円控除できる(平成 25 年以降の場合)。
(ところで、所得税率自体が累進課税なのに、さらに給与所得控除額にも累進性があるのはどういうことなのか?)

これほど高額な控除はアメリカには存在しない・・・住宅ローン減税(のアメリカ版)以外には。

アメリカで住宅ローン (mortgage) を組んで家を買うと、その利払い分と property tax (固定資産税のようなもの)を所得から控除することができる。州税については州によるらしいが、California の場合は控除できる・・・らしい。

例えば、世帯年収 $150,000 の人が $500,000 のローンを 4.00% のレートで借りて家を購入し、property tax が $10,000 とする。
初年度の利払いは $20,000 (概算 $500,000 x 4%)なので、property tax と合わせて $30,000 を支払うことになる。
世帯年収 $150,000 の federal tax bracket は 25%California tax bracket は 9.3% なので、$30,000 x (25% + 9.3%) = $10,290 が控除額となる。

あれ、これでも約 120 万円の控除か。基礎控除 + 給与所得控除に全然負けてた・・・。

というように、アメリカで所得控除を受けるのはとても大変なのです。

2015年5月7日木曜日

メールに返信しない人が多いからこそメールに返信したほうが良い

Facebook で流れてきた「ktdiskのブログ - メールに返信をしないアメリカ人のメンタリティ」を読んだら夜中に笑ってしまった。日本だと、コールセンター / お客様サポートに電話して何かをお願いすれば、ほぼ確実に遂行されるだろうという期待があるけど、こっちでは全然ない。つい最近も、ある商品の返却を電話で依頼したら「明日ピックアップさせます。8 時から 6 時の間にきます」という返事をもらい、翌日だれも来ず、ということを 2 回繰り返し、3 回目にやっとピックアップされた、という事例があった。「8 時から 6 時の間」って、一日中家にいろってことかい。(ちなみに、「ポーチに置いといていい?」と聞いたら「無くなったらお客様の責任になりますよ」と言われた)
アメリカ人(の定義が難しいが、まぁアメリカで働いている人)がメールに返信をしないか、というと確かにしない人が多いように私も思う。「メールに返信をしないのはそんなに失礼なことではない」と思っている人が多いように思う。

ただ、みんながメールを返信しないからと言って、メールに返信が無くても当然と思っているわけではない。メールに素早く返信する人やグループ宛のメールに頻繁に返事する人は、reliable な team-worker と評価される(私の環境では)。

エンジニアは optimization が好きなので、メールフィルターをガチガチに設定して、自分に関係ないメールは inbox に入らないような設定をしている人は結構いるようだが、そういう local/short-term optimize はやめたほうがいい。
とある会社のロンドンオフィスにいた同僚 C は、噂によると「メールフィルターを一切設定せず、全てのメールに目を通し」ていたそうで、チーム内では「C はなんでも知ってるよね」「それは C に聞いてみよう」というように visibility が高まり、結局 team lead になっていった。

もちろん、「メールに返事をくれる便利な人」と思われるだけではダメだが、「自分のやりたいことはこれだから、これ以外には一切目を向けない」というのもリスクが高い。「あの人はコミュニケーションが取りやすくて、いろいろヘルプしてくれる人」という短期的な結果をだしつつ、「XXX というプロジェクトのリードをした」という長期的な結果を出すのが良いだろう。

「アメリカの会社は個人主義。他人の仕事は手伝わない」というのは都市伝説です。

2015年5月6日水曜日

塩レモン作ってみた

裏庭のレモンの木から実がぼとぼと落ちて困っていると書いたところ、「塩レモン作れ」とのお声をいただいたので、作ってみました。

スーパーで保存用のビン($2 ぐらい)を買い、庭からレモンを 3 つもいできました。でかいです。比較用に iPhone 5 を置いて撮影しました。重さは 246g, 339g, 272g でした。

レモンを切っていきます。このページによると、X 型に切るのが良いみたい。みてわかるように、異様に皮(というのか。白い部分)が厚い。もしかしてレモンじゃないのかも・・・?

ビンに詰めてみた。3 つ全部入るかと思ったが、1.8 個しか入らなかった・・・。これで 500g

塩 120g と砂糖 30g。砂糖は入れなくても良かったのか。

蓋が錆びないようにラップして、蓋して完成。2 週間後には食べられるらしい。

塩とレモンが発酵したものってどんな味になるのか見当がつかない。楽しみです。

2015年5月5日火曜日

ゴミの捨て方 in Berkeley

「アメリカ人は大雑把だからゴミの分別なんてしない(できない)だろう」と思ってる人もいるかもしれない(私は思ってた)が、ここベイエリアの人たちは「エコ」が大好きなので、ゴミの分別をしなくてはいけない。
といってもルールはとてもゆるくて、Berkeley では市のゴミ回収で集めるものは 4 種類に分類することになっている。

  • ダンボール、チラシ、新聞などの紙類
  • プラスチック容器・ペットボトル・ガラス瓶
  • 生ゴミ・植物の残骸
  • その他
これ以外に、粗大ゴミ、特殊なゴミ(乾電池、携帯電話など)を捨てる場合は、回収センターまで持っていかないといけない。
ところで、回収センターでは金属とプラスチックとを別の場所に捨てるので、この二つが混ざっているものはどうやってすれてばいいのかよくわからない。

Berkeley リサイクルセンター

さて、実は粗大ゴミの捨て方にはもう一つあって、それは「道端にただ置いておく」という方法だ。

たまに、使い道のなさそうなモノが置かれているのを見る。例えば、引き出しが幾つかなくなってるタンスとか、座ったら壊れそうな安物の椅子などだ。
「こんなもの誰も持っていかないだろう」と思うのだが、意外に回収 (?) される。一体誰がなんのために持っていってるのか謎だ。
私は、古いベビーカー(これは使える)、IKEA の子供用ベッドガード(ベッドに固定する部分がおかしくなってるので使えない)、車のホイールカバー 1 個(うちの前の道路に捨てられてたので、道端に寄せておいた)を試したことがあるが、全てきれいに無くなった。

ここまで来ると「回収されるモノの下限」を知りたくなる。ので、「壊れてるおむつ用ゴミ箱」を試してみることにした。こちらがその商品です。

これは、1. 壊れている 2. (実際にはきれいに掃除したとはいえ)不潔感がある 3. 新しく買っても安い($30 ぐらい)、という意味で回収する価値がなさそうだ。

これをこんな感じで道端に置いておく。

数日間放置してみよう。これも回収されるのか・・・。

2015年5月4日月曜日

英語環境に入る前に知ってたら良かった tips

英語環境で働くようになって 5 年(と約 1 ヶ月)が経った。やっぱり英語には苦労してるので、英語 tips をまとめてみた。

Right

日本語の「はい」「いいえ」のつもりで、英語の "Yes", "No" を使って間違えたことは日本人なら誰でもあるはず。"Do you think this computer doesn't work?" "This computer doesn't work, right?" という質問に「はい、動かないと思います」のつもりで "Yes" と言ってしまうと「動くと思います」の意味になる。
日本語では、相手に同意できるかという意味で「はい」「いいえ」を使うが、英語の "Yes" は常に肯定文とともに、"No" は常に否定文とともに使われる。コンピュータが動かない場合に、"Do you think this computer doesn't work?" なら答えは "No", "Do you think this computer is broken?" なら答えは "Yes" だ。 "Yes, this computer works" か "No, this computer, doesn't work" のどちらかであり、"Yes, this computer doesn't work" という言い方はない。

これは慣れるまで難しいので、「あなたに同意してますよ」と言いたいなら "right" と言うのが良い。これは "You're right" の略なので(だと思う)、「あなたが言ってることは正しいと思います」の意味になり、日本語の「はい」に近い。

(訂正: "do you think..." に "right" と答えるはおかしかいので、例文を訂正。"do you think ...(否定文)...?" の場合は自分はなんて答えてるのだろうか・・・?)

Should

日本の英語教育だと "should" は「・・・するべきだ」と覚えるが、実際には「・・・のはず」という意味で使われることがよくある。"This program should work"「このプログラムで動くはず(動かしたことないから知らんけど)」という感じ。

Let me ...

同様に "let" は "let's play baseball" 「野球やろうぜ」みたいな文脈ででてくるが、"let me open the door" 「ドア開けますね」や "let me tell you how to do ..." 「どうやって・・・するか教えてあげますよ」のよう "let me" で使われることがとても多い。

I would ...

"I'd ask Tom about that" という文章を初めてメールで見た時「この人が Tom に聞いてくれるのかな」と思ったけど、そうではない。これは "If I were you, I'd ask Tom about that"「私があなただったら、Tom に聞くけどね」の略で、つまり「Tom に聞くと良いよ」の意味である。"Can you ask Tom about that?" などより間接的で丁寧な印象がある。

一般に would を使って仮定形にすると丁寧な言い方になる。"I would advise you call Tom" だと「(あなたからアドバイスは求められてないけど、もしアドバイスするとしたら)Tom に電話すると良いと思うよ」というような感じだ。

Not really / Not exactly

「日本語では物事を曖昧に表現しがちだが、英語は "Yes"/"No" をはっきり言う」という認識はそこそこ一般的だと思うが、実際にはそこまで違わない、というのが私の理解だ。
某社で英語のトレーニングを受けた時に、先生に言われたのは「"No" は表現が強すぎるので、あまり使わないほうが良い。"Not really/exactly" のほうが柔らかい」ということだ。

英語でも「こんなにストレートに言ったら、相手は気を悪くするかな・・・?」という気遣いは必要なのです。

2015年5月3日日曜日

不動産売買とオークションの種類

Redfin など不動産サイトには販売価格が表示されているが、これは list price と呼ばれるもので、この金額でその家が買えるわけではない。その list price を参考に buyer がオフォーをいれて、(大抵は)最も高い価格をつけた buyer が手に入れる・・・というオークションになっている。実際の売買価格は sale price と呼ばれる。

sale price / list price は地域によって異なるが、Berkeley 周辺だと 10% の場合もあれば 40% まで上がってしまうケースもある。(学区がいいから。前のエントリ参照。)
list price = $749,000 / sale price = $1,100,000 の例。恐ろしい。

このオークションは、いわゆる first-price sealed-bid オークション(一番高い bid をした人が勝ち、bid した金額を払う)なので、bid 価格を考えるのがとても難しい。
「この物件の価値は $1 million だと思うけど、他の人はそこまで高く bid しないだろうから、$950k で bid するかー。でもそれで負けちゃったらやだなー」などと悶々と考えなくてはいけない。

オンライン広告のオークションでよく採用されている second-price sealed-bid オークション(一番高い bid をした人が勝ち、2 番目に高い bid + ε を払う)だと、この悩みは無くなる。

ただし、second-price オークションは、「公正なオークショナー」の存在が前提となる。家のオークションの場合、オークショナー = seller なので、次のようなズルができる。
「1 番高い bid が $1M で、2 番目が $900k か。じゃあ、友達に頼んで、$990k の偽ビッドをしてもらおう。そうすれば sale price が $90k 高くなるぞ」

不動産売買に公正なオークションを提供するサービスがあれば second-price オークションができるのだが・・・、second-price オークションとか分かりくいし、ただでさえ不動産売買には関係者が多い(seller agent, buyer agent, loan agent, appraiser, etc.)のに、さらに増えるのも面倒だしなぁ。

2015年5月2日土曜日

レモンの食べ方募集

うちの裏庭にはレモンの木があって、一年中実がなっている。レモンってそういうもんだっけ?

写真では分かりづらいが、実はかなり大きくて、体積比で日本のレモンの 3 倍ぐらいある。レモンなんてそう食べるものではない(っていうかまず食べない)ので、実は増える一方である。で、熟した実は当然落ちるので、こうなる。

そして腐っていく・・・。部分的に白くなりかけている。どんどん落ちてくるので、拾って捨てるのも追いつかない。さすがにレモンなので (?)、腐っても虫がわくことはなく、ただ乾燥していくだけなのが救いだ。

というわけで、レモンを大量に消費するレシピがあると良いのだが・・・。

追記
塩レモンをおすすめされたので作ってみます。

2015年5月1日金曜日

アメリカにおけるヒーロー観

タイタニックをネタにした小話にこういうのがある。
タイタニック号が沈み始めた時、船長がイギリス人男性客に言った「君はジェントルマンだろう? ジェントルマンは女性と子供を先に助けるものだ。」アメリカ人に言った「君はヒーローになりたくないのか? ヒーローは女性と子供を先に助けるものだ。」ドイツ人に言った「女性と子供を先に助けるのがルールだ。」日本人に言った「みんながそうしてるから、君もそうしなさい」
こういう話が作られる程度には、「アメリカ人はヒーローになりたがっている」というのは常識なのだろう。

Oxford dictionary によると「ヒーロー」とは「勇敢な、良い行いをすることでみんなから尊敬されている人物」だそうだ。個人的にアメリカ人(アメリカ文化が身についている人という意味)の heroic さを感じるのはこういうときだ。

親切

もちろん日本にも親切な人はいるし、アメリカにも不親切な人はいるのだが、感覚的にはアメリカの方が助けてくれることがおおい。"let me help", "let me do ... for you" というフレーズはものすごくよく聞く。ドアを通り抜ける時に扉を抑えてくれて、"after you" と言って先に通してくれるとか、階段を登る時にベビーカーを持ってくれるとか。電車が混雑してる時(こっちにもラッシュはあるのです)に、すでに乗ってる人が "let's squeeze!" と叫んでもっと人が乗れるようにするとか。

裏表がない = 裏を見せない

「日本人は言動に裏表がある」というのはよく聞くが、これは「アメリカ人は裏表がない」ということではなくて「裏をめったに見せない」ということだ。同じことかもしれないけど。
日本だと、ちょっとタバコ吸いに行った時に「部長には A って言ったけどさぁ、俺は本当は B じゃないかと思うんだよね」みたいなことを言っちゃうイメージがある。イメージだけど。アメリカではこれは考えられないし、聞いたことがない。consistency 重視というか、相手によって言うことを変えるのはとても卑怯な行為だという認識がある、と思う。

ポジティブ、大げさ

これもよく言われることだけど、たとえネガティブな内容でも、ポジティブに表現されることがとても多い。「うまくいってない」ときには "struggling" とか言ってはダメで "challenging" というし、「困難にぶちあたったときは」は "we have a problem" じゃなくて "we have an opportunity" という。こういうのに慣れてくると "challenge" という単語を見るだけで、「あぁ何かうまくいってないんだな」と思えてくる。
聞いた話だが、こちらでは小学校・中学校でも留年があるらしい。あるらしいのだが、それは "bonus year" と呼ぶそうだ。「やったーもう 1 年もらえたー」みたいな感じだろうか。

大げさに表現する、という意味での言葉のインフレーションもすごい。"good", "nice" では弱すぎるので、本当にすごいときは "excellent", "awesome", "terrific" ぐらいは言わないといけない。バッチ処理が遅れそうなときに、そのユーザーに「遅れるよー」というメールを出しただけで、"Ken did an excellent job!" と言われたことがある。



これらが「良い行為」であることに異論はないと思うが、日本人としてはなんとなくもやもやする。「"after you" とか要らないからさっさと先に通ってくれ」と思うときもあるし、納得いかないときに愚痴りたくなることもある。メール送るだけで "excellent" と言われるのは恥ずかしいし、そんなことで褒められたくない。「正しいことばかりじゃ、大変だよ / 面倒だよ」という感覚だ。
こういう感覚がこっちにはない、・・・と思う。それがこちらの生活の生きやすさと関係あるのかもしれない。

読み直してみると、最後の「ポジティブ、大げさ」は hero とは関係ないような・・・。まぁいいや。

2015年4月30日木曜日

不動産価格と API (Academic Performance Index)

アメリカ生活を始めて 2 年が過ぎた。この 2 年間の生活面(仕事じゃなくて)で何が大変だったかというと、やはり子供に関することだと思う。アメリカで生活してみたい、働いてみたいという方には、独身時代、もしくは結婚直後子供が生まれる前に試してみることを強くお勧めします。東大ドクター新卒で 1,800 万もらえるなら早く来てみるといいと思いますよ、本当に。

教育について日本と一番違うのは、公立校が(も?)全てランク付けされていて、学校のランクと住居費用(レントも売買価格も)とに強い相関があることだろう。

カリフォルニアの学校は Academic Performance Index (API) というスコア(多分、生徒のテスト結果の平均点とか?)でランク付けされる。これは 200 - 1000 のスコアで、知り合いに聞いたところでは 850 ぐらいが良い学校かどうかの閾値っぽい。
もちろん学校を測る指標は学力だけではないが、この値が重視されるのは当然だろう。「先生がフレンドリー」みたいな指標は数値化できないし。(そういえば日本も私が子供の頃は全国統一テストがあって、その後廃止されたような気がするけど、あれは何でだっけ?)

この API は不動産価格との相関がとても強い。ベイエリアで最も学区が良いのは多分 Cupertino だと思うのだが、ほぼ全ての小学校の API スコアが 900 以上になっている。Redfin というサイトで不動産価格を見てみると、$/sq.ft.(スクエアフィートあたりの価格)が $800 から $1000という恐ろしいことになっている。隣の Santa Clara (API / Redfin)や Sunnyvale (API / Redfin)と比較すると、Cupertino の高さが際立つ。ちなみに Santa Clara も Sunnyvale もほかの地域に比べると十分良い学区だし、不動産は高い。
不動産が高いと高収入の家族しか住めないし、そういう家庭はたいてい教育環境も整っていて、そういう子供が通う学校の API スコアが上がる。それが不動産価格を押し上げ、さらに高収入の家庭が集まる、というポジティブフィードバックが働いているんだろう。

日本/東京でももちろん不動産が高い地域と安い地域があるが、それが公立校の成績とリンクしているというのは聞いたことがない。

「じゃあ安い地域に住んで、私立校に行けばいいじゃないか」という話もあるが、私立校は年間 $30,000 ぐらいかかる(と聞いた)ので、どっちが経済的にメリットがあるかはわからない。というか、経済的にバランスするように不動産価格が動いている気がする。


あと、病院・医療と日本語教育について書こうと思ってたけど、十分長くなったのでこのへんで。あんまりたくさん書くとまたネタに困るし。


追記
書き出しと内容がリンクしてなかった・・・。
これがなんで子供と関係あるかというと、子供がいなければ API を気にせず、安い(けどそれなりに安全な)地域に住めるから。子供がいると、学区が悪いところには住めない。

2015年4月29日水曜日

エンジニアの集まりに行ってきた

せっかく地獄のシリコンバレー近傍に住んでるし、paternity leave 中に普段できないことをしようと思って、某エンジニアの集まり in SF に行ってきた。このイベント自体は転職・採用目的だけど、今のところ転職する予定はない。まあ passive job seeker ということで。

誰もが知ってる(多分)IPO 間近な会社から、利益を出し始めてるところ、stealth mode で何やってるか曖昧にしか教えてくれない会社まで、いろいろなステージの会社の人と話せて勉強になった。

考えてみれば当然なんだけど、会社・サービスが若いほど、バックエンドのパフォーマンス・スケーラビリティはあまり考えない(必要ない)ので、そのステージの会社にバックエンドエンジニアが入るのは難しいように感じた。「ad server のスケーラビリティとかパフォーマンスとかやってます」と自己紹介しても、「うちのサービスはそこまでのスケーラビリティは(今は)必要ないね ー」と言われたり。

iOS / android エンジニアにジョブチェンジするか、フルスタックエンジニア(って何だ?)にレベルアップしたほうが、本当にスタートアップの会社には求められる気がする。働きたい会社のためにジョブチェンジするというのは本末転倒な気がするけど。
「スタートアップ -> high risk / high return」「IPO 間近 -> low risk / low return」なので期待値は同じだけど、数人の会社でがしがしプロダクトを作るというのも面白そうだ(適当)。

あと、もう 2015 年だというのに未だに「全部 PHP です」という会社もあって、PHP は罪深いなぁと思った。最初から Scala / Java で書くべきだとは思わないけど、Ruby とか Python とかもっと他にあるだろうに。逆に、「バックエンドは C++」という ex-Googler がやってる会社もあった。
サービス初期においてはテクノロジーの選択とサービスの成功とはほとんど関係ないんだろうけど、採用には影響あるんじゃないかな。PHP だと話し聞く気が萎えると思うんだけど・・・。

2015年4月28日火曜日

自分の context switch のコストを下げたい

意識的に思考をアウトプットしてみよう、と思って毎日 blog を書く予定(ただし back filling は許す)だったが、早くもネタ切れ状態。つまり意識的に考えてる時間があんまりないということだろう。

じゃあ何に時間を使っているかというと・・・、
  • 子供 1 の世話: preschool の送り迎え、弁当作り、ご飯食べさせる(2 時間)
  • 子供 2 の世話: ミルク飲ませる、哺乳瓶洗う、オムツ替える、病院に連れて行く(1 時間)
  • 家事: 買い物する、ご飯作る、洗濯する(2~3 時間)
  • 自分のこと: ネット見る、本読む、テレビ見る、ジョギングする(3 時間)
  • その他: 家探し、子供 2 の保険や戸籍の手続きなど(?)
これで 8~9 時間。と考えると、もう少し時間が作れそうだけど、時間が細切れになると context switch のコストが高くて効率悪くなる。うーん、仕事してるときの悩みと同じだなこれは。

作業の順序は変えられない(interrupts が入ってきて、だいたいリアルタイムに処理しないといけないため)という前提で、context switch のコストを下げる life hack を考えたい。

2015年4月27日月曜日

写真は Dropbox で管理することにした

子供が生まれると写真を撮ることが多くなって、Mac のディスクを圧迫し始めた(しかも仕事用 Mac)のと、妻が撮った写真とまとめて管理したいよねということで、写真整理について真面目に考えてみた。

単に写真を管理するだけなら、Picasa, Flickr, iPhoto などの選択肢があるが、複数人が同じ場所に写真をアップしたい、というニーズを満たしてくれるツールはあまりない。見つけられないだけかもしれないが。
例えば旅行に行くと、自分は自分の携帯で、妻は妻の携帯で写真を撮るが、これはまとめて保存しておきたい。

Dropbox が良さそうだが、無料アカウントの 6GB だと写真には足りない。夫婦で Dropbox Pro アカウント (1TB x 2) にすると $200/year かかって、ちょっと高い気がする。セキュリティ上はあまり好ましくないが、夫婦でアカウントを共有して、$100/year 払うことにした。
こんなことができるのは、Dropbox をたいして活用してないからで、Google や Apple のアカウントを共有するのはちょっと無理だ。

Dropbox は写真管理に力を入れつつあるようで、Carousel という iPhone/android アプリを使えば、携帯で撮った写真を簡単にアップロードできる。ウェブの UI もなかなか良い。EXIF を読んで、時系列に並べ、地名をつけてくれる。
Picasa や Flickr のような編集機能がないが、そもそも編集機能はほとんど使わないので、まあいいか。使いたくなったらその写真だけ、Picasa/Flickr にアップすればいいし。
Carousel UI 画面右のスライダーが良い感じ
以前 iPhone から android に移行した際に、iPhoto に入れていた写真を全て Picasa に移動したのだが、今度はまた Dropbox に移動することになった・・・。
Google - Dropbox 間でデータを移動するのが理想的だが、そういうサービスはないので、古典的に、まず Google からローカルに落として、Dropbox にあげることにした。ネットワークの無駄遣いだがしょうがない。

Google Takeout は Google に置いているデータをバルクダウンロードするサービスで、写真もここからダウンロードできる。
Google Takeout 良いサービス名 
デフォルトでは日付が名前となったアルバムになるらしい
Google Takeout からは、2GB ごとの zip ファイルとしてダウンロードできるので、それを復元すれば Dropbox に入れられる。

2010 年ごろからの写真を全ていれて 35GB になった。1TB 埋め尽くすことはない・・・かどうかはカメラの解像度の進化によるなぁ。

2015年4月26日日曜日

料理もやってます


paternity leave 中なので料理もしている。やっぱり自分が好きなものを作るのは楽しいね。

エビマカロニグラタン。Costco で買ってきたブラックタイガーをふんだんに使用した一品。ベシャメルソースを作るときに、ダマにならないようにするには、小麦粉をバターで炒めたものを、鍋底の広い鍋で冷やしておいて、沸騰した牛乳で溶かすと良い。「温度差が重要」というのは某料理本に書いてあったが、大きな鍋で作ると、暑い牛乳に触れる表面積が大きくなるので良いみたい。後ろの緑色の山はサラダです。

パウンドケーキ。こっちのスーパーでは、たいていくるみやアーモンドが売ってるので、材料を揃えるのは楽である。みんな何に使ってるんだろうか。ケーキばかり焼いているわけではないだろうに。これでもかというぐらいに、レーズン、くるみ、アーモンドスライスを投入した。これは材料をヘラ一本でとにかく混ぜていくだけなので簡単に作れる。が、腕が筋肉痛になる。

美味しくいただきました。

2015年4月25日土曜日

TaPL chapter 5: lambda と評価戦略

TaPL 5 章は lambda calculus の復習。今日は "Recursion" の前までしか読めなかった。

評価戦略のまとめ。

  • full beta-reduction: 簡約できるところは全部簡約する。どこを簡約するかは自由
  • normal order startegy: 最も左の、最も外側の redex から順に簡約する
  • call by name: normal order に似てるけど、lambda abstraction の中(関数の中)は簡約しない。
  • call by need: call by name の変形版。一度簡約した redex を記憶しておき、同じ redex を複数回簡約しない。Haskell のやつ。
  • call by value: 引数から先に簡約する。lambda abstraction の中はしない。多くの言語(C, Java など)で採用されてる。この本では call by value を使う。

それから、基本的な関数(例えば整数の equality check とか)を lambda calculus でどう書くかという話。例えば、リスト [x, y, z] を
  \c. \n. c x (c y (c z n))
と表すとすると、nil, cons などは以下のようになる。(exercise 5.2.8)

---
nil => \c. \n. n

---
cons = \h. \t. \c. \n. c h (t c n)

---
isnil = \t. t (\x. \y. fls) tru

isnil (\c. \n. c z n) = (\c. \n. c z n) (\x. \y. fls) tru
                      = (\x. \y. fls) z tru
                      = fls


---
head = \t. t (\x. \y. x) fls

head nil = (\t. t (\x. \y. x) fls) (\c. \n. n)
         = (\c. \n. n) (\x. \y. x) fls
         = fls

head (\c \n. c z n) = (\t. t (\x. \y. x) fls) (\c \n. c z n)
                    = (\c \n. c z n) (\x. \y. x) fls
                    = (\x. \y. x) z fls
                    = z


---
nils = pair nil nil
ss = \t. \p. pair (snd p) (cons t (snd p))
tail = \t. fst (t ss nils)

tail [x, y] = tail (\c. \n. c x (c y n))
            = (\t. fst (t ss nils)) (\c. \n. c x (c y n))
            = fst ((\c. \n. c x (c y n)) ss nils)
            = fst (ss x (ss y nils))
            = fst (ss x (pair (snd nils) (cons y (snd nils))))
            = fst (ss x (pair nil [y]))
            = fst (pair [y] (cons x [y]))
            = [y]

tail [] = tail (\c. \n. n)
        = fst ((\c. \n. n) ss nils)
        = nil

こういうのはパズルなので考えればできると思うが、そもそも true を \t. \f. t と、1 を \s. \z. s z と表せばうまくいく、という考えにどうやってたどり着いたのか謎だ。


・・・で、そもそもなんでここで lambda の復習してるんだっけ。この後で使うんだろう、多分。

2015年4月24日金曜日

TaPL はじめました

Types and Programming Languagesを読み始めました。毎日 1 チャプター読めるといいなぁ。


今日は 3, 4 章を読んだ。
3 章は、今後の説明に使われるであろう、シンプルな言語 arith の導入。boolean と integer しかない。
4 章は arith の evaluator のインプリメンテーション。例は OCaml だったので、Haskell で書いてみた。

data Term = TmTrue
          | TmFalse
          | TmIf Term Term Term
          | TmZero
          | TmSucc Term
          | TmPred Term
          | TmIsZero Term
          deriving Show

isNumVal :: Term -> Bool
isNumVal TmZero = True
isNumVal (TmSucc t) = isNumVal t
isNumVal (TmPred t) = isNumVal t
isNumVal _ = False

isVal :: Term -> Bool
isVal TmTrue = True
isVal TmFalse = True
isVal t = isNumVal t

eval1 :: Term -> Maybe Term
eval1 (TmIf TmTrue t _) = Just t
eval1 (TmIf TmFalse _ t) = Just t
eval1 (TmIf t1 t2 t3) = eval1 t1 >>= \t -> Just $ TmIf t t2 t3
eval1 (TmSucc t) = eval1 t >>= \s -> Just $ TmSucc s
eval1 (TmPred TmZero) = Just TmZero
eval1 (TmPred (TmSucc nv)) | isNumVal nv = Just nv
eval1 (TmPred t) = eval1 t >>= \s -> Just $ TmPred s
eval1 (TmIsZero TmZero) = Just TmTrue
eval1 (TmIsZero (TmSucc nv)) | isNumVal nv = Just TmFalse
eval1 (TmIsZero t) = eval1 t >>= \s -> Just $ TmIsZero s
eval1 _ = Nothing

eval :: Term -> Term
eval t = case eval1 t of
  Just s -> eval s
  Nothing -> t

ghci で動かしてみるとこんな感じ。
*Main> eval $ TmIsZero $ TmPred $ TmSucc $ TmZero
TmTrue
*Main> eval $ TmIsZero $ TmPred $ TmSucc $ TmSucc $ TmZero
TmFalse