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