舎路(シアトル)日記

シアトルで働く日本人プログラマの日記です

今日に聞いた Planet Money は、2015年の再放送で、サンタスーツと関税の話だった。

サンタのコスチュームは通常は催事用のもの (festive articles) という扱いになって、外国から輸入する際に関税がかからないんだけど、しっかりした作りのものは洋服扱いになって、高い関税がかかってしまう。

And customs looks at this nicer Santa suit and says to Marc - this is not a festive article. You made this so nice this is clothes. And clothes go under a different part of the tariff code. To import this suit, Marc has to pay a 32 percent tax on the jacket and a 29.2 percent tax on the pants.

という件で Rubies Costume Company というコスチュームの販売会社の人が政府に対して訴訟を起こしていたらしい。ちょっとのネタバレになってしまうけど、面白いのは、この人は以前は国内生産のサンタスーツを売っていて

Back in the ‘90s, on the other side was Marc Beige, was Rubie’s Costume Company. He has completely switched sides.

そのときはサンタスーツは洋服であるので関税をかけるべきだ、という立場で訴えを起こしていたらしい。

Planet Money とは

Planet Money は NPR (National Public Radio) がやっているラジオ番組で、私はポッドキャスト経由でたまに聞いている。お金にまつわることを中心に、いろいろなテーマを取り上げていて面白い。

今年に聞いたものだと

  • North Korea’s Capitalists: 北朝鮮はミサイルをどう買ったのか? という疑問を導入に、ドンジュとよばれる資本家/起業家的な人々や、その育成プログラムについて。
  • The Basic Income Experiment: ベーシックインカムの試みと、フィンランドでの実験と、デザイン思考について。
  • Shrimp Fight Club: アメリカにおける事業仕分けと、そこで「えびファイトクラブ」と名指しされ研究の意義を問われた科学者のはなし。

ここらへんは特に面白かった。英語を聞くだけでは辛いという人には Transcript もあります。

最近は Lombok 以外にも色々あるみたい。

AutoValue

Google の人々が開発していて、google-java-format と同じように、設定できるところがあまり無い。出来る/出来ないことについて opinionated で、理由を読んでみると勉強になる。

一方で、AutoValue with Builders

As explained in the introduction, the AutoValue concept is that you write an abstract value class, and AutoValue implements it. Builder generation works in the exact same way: you also create an abstract builder class, nesting it inside your abstract value class, and AutoValue generates implementations for both.

というように Builder は生成してくれなかったり、インターフェースから生成はできないの? という問いに

Interfaces are not allowed. The only advantage of interfaces we’re aware of is that you can omit public abstract from the methods. That’s not much.

と冷たく突き放してみたりで、お前はボイラープレートを減らしたいんじゃなかったのか、と存在意義を問いたくなるところもある。

Immutables

名前に “Immutables” とある割になぜか mutable なものも生成できたり、@Value.Style で色々設定できたりと、とにかく節操がない。

The Morning Paper で紹介されていた論文を読んでいる。全体像について書くと The Morning Paper の翻訳になってしまいそう1なので、個人的に見所だったところだけ紹介。

スマートフォン時代のクライアント

SVE は動画を GOP (group of pictures) という短い動画に変換して扱っていて、その分割はクライアントの側で行われている。

The first change is that the client breaks the video up into segments consisting of a group of pictures (GOP), when possible, before uploading the segments to the front-end. Each GOP in a video is separately encoded, so each can be decoded without referencing earlier GOPs.

GOP 分割は必須ではなくて、古いクライアント向けにはフォールバックも用意されている。

Some older clients cannot split videos into GOP segments before uploading. The preprocessor does the GOP splitting for videos from those clients.

さらにクライアントは動画の再エンコードさえすることもある。

We decrease the latency for uploads through client-side re-encoding of the video to a smaller size when three conditions are met: the raw video is large, the network is bandwidth constrained, and the appropriate hardware and software support exists on the client device. We avoid re-encoding when a video is already appropriately sized or when the client has a high bandwidth connection because these uploads will already complete quickly. Thus, we prefer to avoid using client device resources (e.g., battery) since they will provide little bene t. Requiring all three conditions ensures we only do client-side re-encoding when it meaningfully decreases pre-sharing latency.

私はいまだに「クライアントは非力で API も少ないし、色々複雑な作業はサーバー側でやったほうが、エラーもログも簡単に収集できるし平和だよね」というクライアント == ブラウザ時代の空気感を暗黙の前提にしてしまいがちで、SVE のクライアント == スマートフォンむけに Java/Objective-C や C++ で書かれているソフトウェアが頑張る感じは新鮮だった。

HHVM と Hack

Facebook でも、こういうバックエンドのシステムだったら Hack とか使わずに Java なり Python で書くのかな、となんとなく思っていたら

All workers are equipped with HHVM, a virtual machine supporting just-in-time compilation for all SVE tasks, which in turn are Hack functions deployed continuously from our code repository. During execution, each task is wrapped within framework logic that communicates with SVE components to prepare input, propagate output, and report task results.

普通に HHVM + Hack で動いているらしい。”Hack functions deployed” なんて言い回しはちょっと AWS Lambda っぽくもある。

To be shared

論文全体に渡って

Uploading and processing are on the path between when a person uploads a video and when it is shared. Lower latency means users can share their content more quickly.

“used” みたいなぼんやりした動詞ではなくて、ずっと “shared” を使っているのも印象的だった。

Taken together, these improvements enable SVE to reduce the time between when an upload completes and a video can be shared by 2.3x-9.3x over MES.

単純に「シェアできる状態になる」というのが全体のパイプラインのうち重要なマイルストーンなのかもしれないけど、サービスを特徴づける動詞があって、それをエンジニア側もメトリクスとして使っている、というのは、なんか会社としてちゃんとしていて良いなあと思う。


  1. 翻訳を読みたいひともいるかもしれないけど、プログラマと英語 1: 野良翻訳で書かれている色々に同意する部分もあり、自分では翻訳しません。 [return]

まわりのひとが英語の話を書いていて、

触発されたのと、自分の TOEIC スコアをすぐには探し出せなかったので、ここ10年くらいのまとめを書いてみた。振り返ってみると色々やっている。

書いてみて改めて思ったけれど、アメリカに引越してかの勉強はちょっと停滞している。TOEIC のように、英語能力を数値で測るのをやめてしまったのも良くない。来年は iKnow, Duolingo 以外のなにかを見つけたい。

2007

プログラミングが好きな大学生でした。当時に書いていたブログを読みかえすと、日本語でブログを書きつつも、タイトルだけは英語でつけるというこだわりがあったみたいだけど、全く理由が思い出せない。

この時点でも、公式のリファレンスは英語、エラーメッセージは英語、みたいな状態にはある程度の慣れはあって、なんとか英語は読んでいた。

2008

日本の会社をいくつかうけて、そのうちのひとつに就職した。

2009

  • TOEIC:605 (リスニング:300 / リーディング:305)
  • ブログをたまに英語で書くようにしていた

この年に初めて TOEIC を受けて、605点をとった。

2010

当時の Kindle は日本語さえ諦めてしまえばライフチェンジングな体験ができるデバイスだった。本が安く買えるし、すぐ届くし、本棚のスペースを気にしなくていい。何冊か英語の技術書を買ったり、当時は無料だった PragPub をダウンロードしてみたり、色々と読んでいた。

こういったメリットは結局のところ電子書籍のメリットなので、日本語の電子書籍が普通に買える2017年だと「だから英語を読もう」とはならないと思う。今だったら O’Reilly の Safari は近いかもしれない。普通に買えばそれなりにする本を、必要な部分だけ読んで、残りの部分は読まない、ということが図書館にもどこにも出かけずに出来るのは結構ライフチェンジングな体験だ。ガジェット成分がないことだけが残念。

2011

  • 英語だけでブログを書いていた
  • TOEIC:750 (リスニング:395 / リーディング:355)
  • イーオンに行きはじめた
  • RubyKaigi 2011 で海外から来ていた人々と夕飯を一緒に食べたり、よく話しかけたりしていた

振り返るとそれなりに狂っていて、日本に住んで、日本の会社に勤めているのに、なぜかブログを全て英語で書いていた。

RubyKaigi はたまたま友達に誘われて1日目の最後に海外から来ていた人々と夕飯を食べる機会があって、それでスイッチが入って、その後も色々な人に話しかけていた。プログラミング言語系のカンファレンスは、日本に住んでいるプログラマが英語しか話せない、けど共通の話題がある人々に話しかけるいいチャンスだと思う。

イーオンに行きはじめたのもこの年だった。当時も Skype 英会話はいくつかあったけど、会社の補助があったのと、なんとなくさぼったりフェードアウトしたりしづらいかなあというのとで、物理的な英会話教室に決めた記憶がある。

2012

  • TOEIC:795 (リスニング:425 / リーディング:370)
  • 転職した

ここで外資の大企業に転職して、上司も英語、チームメイトも半分近くが英語、ミーティングで使う言語も英語、という状態になった。

転職したのは、世界の色々なところに拠点のあるような大企業での開発をみてみたかったのもあるし、英語を日常的に使おうと思ったのもある。日本の携帯電話がスマートフォンに駆逐されつつあったころで、日本語の話せる人々を東京に集めてソフトウェアを開発しても、結局はアメリカ企業に勝てないんじゃいかと悲観的に思っていたことも、少しある。

TOEIC スコアは転職前 (5月末) のものなので「TOEIC スコアが795点くらいでも、外資でエンジニアとして採用されることはある」と言える。まあ、サンプル数は1だけど。

2013

  • TOEIC:870 (リスニング:455 / リーディング:415)
  • iKnow を使いはじめた

これが自分がうけた最後の TOEIC になった。外資で働きはじめたら一発で満点とれました! とはいかなかった。

2014

  • シアトルに引越した
  • iKnow に加えて、Lang-8 を使って英語で日記を書いたりした

日本で働いていたチームが無くなってしまうというので、本社のあるシアトルのチームに引越すことにした。チーム解散即解雇ということはなく、日本に残る選択肢もあったんだけど、このチャンスを逃したら海外で働くことなんてないかもなあと思って、後悔が少なくなるような選択肢をとった。

日本で数年働いてからアメリカの本社/支社に行く場合、H1B ではなく L1 という種類のビザで行けて、これは H1B ほど取るのが大変ではない。これについてはラッキーだった。1

というわけで、タイトルに戻ると「TOEIC 605点のエンジニアがアメリカで働くようになるまでには5年かかった」ということになる。サンプル数は1です。

2015

  • iKnow に加えて、Duolingo を使いはじめて、英語のスキルツリーを完了した
  • グリーンカードの手続きをはじめた

Duolingo の英語コースは正直あんまり難しくないので、もっと早くにやったほうが良かった。

2016

  • iKnow と Duolingo をやっていた
  • 子供が生まれた

2017

  • iKnow と Duolingo をやっていた
  • グリーンカードが届いた

グリーンカードをとって転職できる身分になった。

まとめ

自分の経験から、TOEIC 605点のエンジニアが

  • 795点になるまでに3年かかり
  • そうなると外資の会社に、エンジニアとして採用されることもあり
  • そこから870点になるまでに1年かかり
  • そうなるとアメリカで働けることもある

という話を書いてみた。

あくまで自分の話なので、サンプル数は1、再現性は保証できないけれど「TOEIC で何点くらいでは、何々は出来ない」という警告みたいなものは世の中にあふれているので、ちょっとくらい「TOEIC で何点くらいでも、何々は出来る」という話があっても良いんじゃないかと思う。


  1. その後にソフトウェアエンジニアのUSビザという記事を @splhack さんが書いてくれたので、詳しくはそちらをどうぞ。 [return]

週3ブログ生活

Dec 13, 2017

11月の末から、ここ2週間くらい月水金とブログを書くようにしていた。karino2 さんが書いていた

やっぱりどれだけどうでも良い話を書けるか、という所が中堅どころがブログを続けられるかの勝負どころだと思うのですよね。

というのは正しくて、更新する日を決めると、自分の中の基準を下げざるをえなくなる。なんだか、以前に morrita さんが生焼け四半期なんて言っていたのをなぞっているだけな気もするけれど。

現地就職してからの1年とその前後にあった

歳をとったせいなのか、何か話し始めたり書き始めたりすると、関連して言っておきたくなっちゃうみたいなのがポロポロ出てきてしまって止まらないのって普通なんだろうか。聞き手をお待ちしております。

というのは、めっちゃわかるけど、それは単純に書く回数が減っているからでは、とも思う。