Rebuild A Podcast by Tatsuhiko Miyagawa. Talking about Tech, Software Development and Gadgets.

0:00

miyagawa: Satoshi Nakamoto。

kenn: （笑）紛らわしい名前だよね。

miyagawa: 似たような名前の友だちとか結構いるんで紛らわしいんですけども。Newsweek が「こいつが Satoshi Nakamoto だ」って言って記事を出したんだけど。ロスアンゼルス郊外に住む67歳の日系アメリカ人ですか。

kenn: なんか見たことある感じの人だよね。

miyagawa: ちょっと見た目が「あれっ？」って感じなんだけど。鉄道オタクでね。昔政府系の組織でコントラクトをやっていて、数学に詳しくて、みたいな。状況証拠から組み合わせて、こいつが BitCoin を作ったやつに違いない、っていう風に Newsweek は結論づけたわけですけども。記事が出てから結構、アメリカの報道系が家に押しかけて、カーチェイスしたりとかね。

kenn: カーチェイスって（笑）なんか違ったよね。

miyagawa: なんか、Associated Press の人と飯を食いに行くっていって、寿司を奢ってもらって。で、俺は関係してない、と言ったらしいですけどね。

kenn: それって、ほんとのとこはどうだったかってまだ分かってないんだっけ？

miyagawa: そこは分かってないけど、本人は完全に否定してるんだけど、

kenn: 本人だったとしても否定はするよね。

miyagawa: やっぱり狙われるからね、色んな人からね。

kenn: ちょっとね、今はタイミングがよくないもんね。

miyagawa: でも、仮に本人である可能性があるとして、こんなヴァーチャルな貨幣とかを作る人がほんとの自分の名前使うかね？って思うけど。

kenn: まあねー。ずっと謎だったのにね、今になって「見つかりました」っておかしいよね。

miyagawa: で、元々 BitCoin を発表した P2P のサイトのフォーラムには「俺は Dorian Nakamoto じゃない」っていう風に

kenn: （笑）

miyagawa: 彼の名前が元々サトシナカモトってのが日本の名前で、アメリカに帰化した時に Dorian Prestine Satoshi Nakmoto っていう風に改名したんだけど、そのフォーラムでは「俺は Dorian じゃない」っていう風に書き込みしてるんで。

kenn: （笑）ややこしいな。

miyagawa: ややこしい。よくわかんないけどね。

kenn: ていうか、震源地は日本だったわけでしょ？

miyagawa: 騒動のってこと？

kenn: そう、Mt.Gox の

miyagawa: そうね、最近ちょっと盛り上がってるのは、Mt.Gox っていう BitCoin エクスチェンジ、実際の貨幣と BitCoin とを交換するサービスが色々あるんだけどそのうち一番大きなものが Mt.Gox ってサイトで。本社が日本にあるんですよね。これ面白いのが、Mt.Gox ってのは全然 BitCoin と関係ない名前で、

kenn: あ、そうなの？

miyagawa: Magic the Gathering Online Exchange っていうのの略なんすよ。

kenn: えーーー（笑）まじ？？

miyagawa: そう。

kenn: それは知らなかった。

miyagawa: で、Magic the Gathering のカードを交換するトレーディングサイトで、ドメイン持ってて。で、BitCoin に興味あるやつが元々のやつを作ったんだけど、プログラミングあんまり詳しくないから興味あるやつに売るよ、って言って、今の Mt.Gox の社長が買って、それで日本の渋谷にオフィス作って運営してるっていう。

kenn: あ、自分の会社じゃなかったんだ。

miyagawa: 元々は違ったらしいですね。

kenn: そういうことか。

miyagawa: で、Show Notesにリンク貼っとくんですけど、Wired で「Mt.Gox のインサイド」みたいなのが出てて、これも面白かったです。気になる人は読んでみたらいいと思うんですけど。去年にも1回問題起こしたらしいんですよ。で、サイトが1週間くらい止まってて。結構 BitCoin のコミュニティって協力的な人が多いから、BitCoin の開発者でオープンソースのライブラリとか作ってる人が東京にやってきて、空港から渋谷のオフィスに直行して寝ないでみんなで助けてあげたのに、本人は「週末はいいだろ」って言って出社してこなかったりとか。なんかすごかったらしいっすよ。

kenn: えー、やる気があるんだかないんだか。

miyagawa: いや、ないでしょ、完全に。

kenn: ていうか、インパクトがあるっていう自覚がなかったってことだよね、実体経済に対する。

miyagawa: ロシアのハッカーがさ、ここのソースコードを盗み出したってことで TechCrunch で公開されてたけど、PHP のだいぶ酷いコードだったよ。

kenn: （笑）

miyagawa: あと Mt.Gox で働いてるエンジニアの話によると、ユニットテストみたいなものは全く存在しなくて、バージョンコントロールも最近までしてなかったって。

kenn: えー、どうやってたんだろね。

4:47

miyagawa: いやもう、単純にディレクトリごとコピーしてそのまま PHP を FTP でアップロード、とかじゃないの（笑）

kenn: （笑） すごいなそれは。

miyagawa: 世の中そんなんでも何百億を動かす金融サイトを運営できるってことですよ。

kenn: ま、最後がよくないけどね（笑）

miyagawa: （笑）

kenn: だからこうなったんだ、ってオチだけど。そっかー。あれでも、お金を盗まれたってのは何が原因なんだったっけ？

miyagawa: BitCoin のプロトコルにちょっと弱いところがあって、トランザクションを偽造して送った時に fail するんだけど、同じような成功したトランザクションを何回も投げると、それを繰り返してしまうっていうバグがあったらしくて。

kenn: おーーぅ。

miyagawa: みんなそれは分かっててパッチを当ててるんだけど、Mt.Gox はちゃんと当ててなかったってのが1つだね。

kenn: しょぼい（笑）

miyagawa: もう1つ、これは別のサイトに書いてあったけど、陰謀論っぽい話で。一応 BitCoin の秘密鍵 とかはコールドストレージに保存していて、

kenn: はいはいはい。切り離すよね、ネットからね。

miyagawa: そう、ネットから切り離されたところに置いてあったんだけど、マネーロンダリング的なとこに使われていたので CIA とかに押収されたんじゃないか、って説があるけど。

kenn: えー、それはないんじゃない？だって、資産は日本にあったんでしょ？

miyagawa: うん。

kenn: CIA はそこまで権限及ばないね。

miyagawa: う～ん、よく分かんない。Show Noteで貼っときますけどね。それは陰謀論的な話なんでよく分かんないっす。

kenn: まゆに唾つけながら（笑）

miyagawa: そうそう。

kenn: でも相当金額でかいからなぁ

miyagawa: 何百億だっけ？

kenn: そうだよね。その金額になると確かに、政治的な意図を持ったやつがいてもおかしくはない気はするけどね。

miyagawa: そうだね。

kenn: Easy Target だし、Mt.Gox。パッチも当ててない PHP っていう（笑）

miyagawa: （笑）BitCoin のプロトコルとかについては僕は3年前の drikin.tv で結構話してたんですよ。

kenn: なんか話してたよね。

miyagawa: うん、でもその動画消えちゃってて見えないんですけど。BitCoin については詳しい人が僕らの周りにいるんで、その人たちが話したければ出てもらってもいいんですけどね。

kenn: ちなみにみやーんはどうなの、前向きなの？BitCoin に。

miyagawa: BitCoin のプロトコル自体は面白いと思うし、例えば Coinbase とかそういうところに投資してる人もいっぱいいるからね。ちゃんとした運営をしてる BTC であれば。金融機関の無駄なフィー、取引手数料とかをスキップできるしいいモノだと思うんですけど。どうしてもきな臭いよね、こういうのは。

kenn: まあね。特に初期はやっぱり色々とトラブル起こるよね、どうしても。だから長い目で見ればこういうのも色々落ち着いて、

miyagawa: ただやっぱり、Mt.Gox とかが潰れて彼らにとっても、預けてた人たちにとっても良くないことではあるけど、それでもまだ BitCoin って続いてるわけですよ。価値とかが一瞬下がったんだけど、また今反発してたりしてるのね。だから、そういうのがあっても一瞬で潰れたりしなかったっていう意味では、長期的に見て更にまた信頼感が増す可能性はあるかな、っていう。

kenn: そうね。こんだけの事故あってもちゃんと reflect した、っていうかね。ま、貨幣の力ってそういうとこで、集合的な意思決定が積み上がって1個の価値になるという。

miyagawa: そんな感じですね。

kenn: これでも、全部のトランザクション見えちゃうんでしょ、みんなに。で、それを隠すために色んなややこしいことやってんだよね。

miyagawa: 個人のアイデンティティとトランザクション履歴はトラック出来ないんだけども、鍵の ID と「この ID の人が今いくら持ってる」っていうのは全部見れるんで。そこと本人の ID が紐付いちゃうと、もう完全に、「あ、この人はこないだどこそこでいくらの買い物をした」みたいなのがわかっちゃうんで。

kenn: だよね。

miyagawa: そこはもちろんトラック出来ないようになってるけれども。

kenn: あと、お金沢山持ってる人はやっぱり分散するようにするじゃない、一箇所にあると危ないから。ロンダリングじゃないけど、ロンダリングバイデフォルトというか。

miyagawa: そうだね。そういう意味だと Satoshi Nakamoto とかは全体の何十パーセントとか持ってるんで、その ID でトラックしてる人が絶対いるはずなんだよね。だから彼が今のをキャッシュアウトすれば完全にわかる。

kenn: はいはいはい。

miyagawa: で、IRS とかそういう人たちが黙ってないから。

kenn: 使えないね、なかなか（笑）

miyagawa: 何百億の資産を持ってたとしてもなかなか使えない、っていう状況ではあると思うけどね。

kenn: BitCoin 自体は IRS は手出せないよね？換金しないとダメだよね？

miyagawa: 貨幣として認めるか認めないかって話で。

kenn: そういう話だよね。

miyagawa: 日本の財務省とかは「認めない」と言いつつ、それによってものを買ったりした場合は消費税を徴収するとか、色々よくわかんない感じに最近なってるね。何日か前にそういう発表してた。

kenn: あ、そうなんだ。

10:10

miyagawa: 要はどこの省も自分の管轄にしたくないけど、とりあえずお金が動いてるんだったら金よこせ、みたいな感じで。

kenn: どこも一緒だね（笑）やっぱ国税が一番最初に出てくるね、そういうとこはね。他のことはどうでもいいけど、金だけは出せって（笑）

miyagawa: BitCoin については色々長くなりそうなんで、そんな感じです。

kenn: そうね。

miyagawa: えっと、先週から公開を始めた Rebuild のトランスクリプトなんですけども、文字起こしですね。先週の段階で先週のエピソード34と、昔 Jesse が出てキーボードの話をしたエピソード9、唯一の英語のエピソードなんですけども。それの文字起こしも公開してますんで、rebuild.fm/transcripts ってとこに行くと文字起こしがされてるエピソードの一覧が見れて、そこから買えるようになってます。なので、興味がある人は買ってみてください。

kenn: 結構気合入れて起こした English バージョン。

miyagawa: そうだね。あと、サイトの方からチラ見が出来るようになってるんで。例えば rebuild.fm/34 ってとこに行くと、最初の5分くらいの会話全部見れるんで。「あ、こういう感じの話をしたんだな」とか、「こういう風な文字起こしされてるんだな」ってのが分かるようになってると思います。そこを参考にしながら買ってもらえるとちょうどいいかな、と。

kenn: フォーマットは？

miyagawa: フォーマットはですね、テキストと PDF と EPUB で買えます。全部 DRM かかってないんで、テキストは自分で加工したい人とか、そういう人が使ってもらえばいいし、iPhone とか Android とかで見る人は EPUB が一番いいかな、と思うんですけど。そういうフォーマットで公開をしてます。

kenn: いいね。

miyagawa: はい。kenn もいくつか見たでしょ。

kenn: うんうん。よく出来てる。

miyagawa: もちろん聞いてもらうのが一番いいんですけども。時間がない人とか昔聞いてて単語が分かんなかったとか、そういうのを補完する意味でもいいかな、と思いますんで。ぜひぜひ買ってみてください。

で、今週 MacBook Retina の 13インチを買いました。

kenn: おー、とうとう。ずっとその話ばっかりしてたよね。

miyagawa: そう？ちょっとオンラインでね。前から買おうと思ってたんですけど、マイグレーションがめんどくさいとか、そういう後ろ向きな年寄り臭い理由で避けてたんですが。

kenn: フレッシュインストール派じゃないもんね。

miyagawa: そうなんだよ。ただね、やってみたんだけど、Air から MacBook Retina の 13インチに、普通にMigration Assistantを使ってやったんですけど全く問題なかったです。

kenn: ほぇー。1回もやったことない（笑）

miyagawa: （笑）どうなんだろうね。

kenn: そうなんだ。でもそしたら OS 古いままってこと？

miyagawa: いや、まず Air の方を Mavericks にアップデートしてから。

kenn: あ、そういうことね。

miyagawa: そっちのアップデートの方で半日くらいかかったかな。Homebrew がぶっ壊れたりとか。そっちを半日かけて直した後、Time Machine にバックアップしてから新しいのに入れたので。

kenn: なるほどね。新しいドライバとか OS 上げたときに入ってるってことか。

miyagawa: 基本的には問題なかったね。

kenn: なるほど。Retina 13 どうですか？

miyagawa: いいね、かなり。

kenn: Air と比べて？

miyagawa: Air と比べると、スピードが全然違うし。Air が2011モデルとかで結構古いんで、それがだいぶ良くなったっていうのがあるし。

kenn: そういうことね。

miyagawa: あとは、解像度がデフォルトだと Air より狭いんですけど。要は Retina モードの場合ですね。で、スケールして Air と同じようになるようにして、ちょうどいいですね。

kenn: ピクセルいくつのやつ？

miyagawa: 1440x1080 (x900) かな。

kenn: はいはい。じゃ、Air と完全に一緒って感じだ。

miyagawa: そうだね。

kenn: そうね、だいたいあれ一段階くらい上げるといいよね。15インチもそうなんだけど。

miyagawa: あ、そうしてんの、15でも？

kenn: うん。15だと標準が1400なんだけど、それを1600で使ってるね。

miyagawa: ま、あんまり True Retina かそうじゃないかで、

kenn: うん。どっちもきれいだよ。

miyagawa: 全然わかんないというか。

kenn: そう、あれ最適解像度とか言ってるのは、単にきっちり2倍になってるから速いっていうだけだと思うんだけど。最初の Retina 出た頃はすごいスクロール遅くなったりとかしたけど、今は問題ないから。解像度は好きなやつで使えばいいと思うんだよね。

miyagawa: そうだよね。で、Mac Pro とかもそうなんですけども、4K ディスプレイ、外付けの 4K に Retina で出来るか出来ないか、っていうのが、ギークの間では気になってたとこだと思うんですけど。今までは出来なくてね。今週、OS X Mavericks の10.9.3ですか、最新のベータが出て 4K ディスプレイの Retina ピクセル、要は 4K のディスプレイに対して1920x1080の Retina のピクセルで出せるっていうのが10.9.3で対応したっていう話はありますね。これで Mac Pro を買う理由が出来たんじゃないの？

kenn: （笑）まぁ、そうね。今まで多分みんな、それで渋ってたんだと思うんだけど。でも、Mac Pro 未だに納期すごい長いよね？買ってもすぐには来ないよね？

miyagawa: 発売開始から3日後くらいに買った人が今週届いたって言ってた。

kenn: あ、そういうレベルなんだ。相当売れてんだね。売れてんのか弾数が少ないのか分かんないけど。

miyagawa: 多分、数が少ないんだろうね。

kenn: 今 Available to ship が April になってるから。やっぱ1ヶ月以上待つんだね、今でも。これテキサスで作ってんでしょ？

miyagawa: Made in USA かな。Assembled in USA だっけ？部品はさすがに中国で作ってんのかな？

kenn: そうだよね。確かになぁ、なるほど。

miyagawa: そんな感じだと思うけど。

kenn: でも、4K で1900の解像度って、あんまり大きい画面じゃないよね。

miyagawa: 画面サイズによるよね。4K で20ちょいくらいのちょうどいいサイズがあればいいけど、28インチとかでっかいやつで、1920x1080だとちょっと、

kenn: ちょっと余るよね。2000ちょっとくらいは欲しいし。だからその中間くらいの解像度にまたなるんじゃないか、って気はするけどね。

miyagawa: （笑）

17:00

kenn: Best for Retina だと1920なんだけど、

miyagawa: そうだね。ノートでも出来るらしくてさ。要は MacBook Pro の Retina でも 4K ディスプレイに対応するみたいで。

kenn: なるほど。

miyagawa: ただ、リフレッシュレートが 60khz ではない、みたいな。

kenn: え、そこ変えるの？

miyagawa: 今んとこそういうサポートになってるらしくて。今後もっとリフレッシュレートが速くなるのかもしれないけどね。

kenn: てか、GPU いつまで経ってもいるんだね、そういう意味では。どんどん解像度あがるからね。大変だね。

miyagawa: そうだね。

で、もう1個時事ネタ行きますけど、kenn が出てくると毎回 DigitalOcean の話をしてる気がしていて。

kenn: （笑）なに、そういう役回り？

miyagawa: わかんないけどさ。今週 DigitalOcean が37.2ミリオンの投資を Andreessen Horowitz から受けたっていうので盛り上がってきてますよね、段々更に。

kenn: そうね。これ前話したっけ？DigitalOcean が Amazon よりも早く成長しだしてるって。

miyagawa: うん、ちょっと話したかもしれない。

kenn: 勢いすごいあるよね。

miyagawa: あと、年末に出てもらった時に「シンガポールのデータセンターを作る作らない」って話をしてたんだけど、こないだ使ってみたらシンガポールはもう出来てました。

kenn: はいはいはい。速度はどう？

miyagawa: ちょっとそこは微妙で。日本においてあるサーバーに対して API 的に叩くようなスクリプトを書いた時に、サンフランシスコにあるところからのレイテンシと比べて7割くらいになるかな。

kenn: あ、そんだけしか変わんないの？

miyagawa: うん。だからちょっと速くなるけども、そんなにかな、って気もする。ただ、やっぱり DigitalOcean って、他もそうだと思うけど、インスタンスごとの運とかがあるじゃない？異常に重いインスタンスにあたったりとか、やっぱりあるんで。そこはちょっと分かんないんですけども。何回か試してみて、多少まだレイテンシあるな、って気はしたんだけども、まぁ太平洋越えるよりはいいですよね。

kenn: もうちょっと劇的によくなるイメージだったんだけどね、シンガポールからだと。なんか、DigitalOcean すごい気軽に使えるじゃん？

miyagawa: そうなんだよ。

kenn: だからすごいものいいんだけど、BitCoin 掘るやつが増えて、

miyagawa: （笑）

kenn: それのせいでみんな CPU が調子悪いんだよね。

miyagawa: そこにまた BitCoin が繋がってくる。

kenn: （笑）そうそうそう。それを、@moiseyuretsky って DigitalOcean の Developer Management 的な人がいるんだけど、彼曰く「BitCoin 掘るのに使ってる奴を throttling するように今 tweak してる」って話ししてたけどね。

miyagawa: でももう BitCoin をマイニングするのって割にあわない状況になってるんじゃないかと思うんだけど。

kenn: そうそう、特に CPU でやるのなんて意味がないから、DigitalOcean 使わないでくれって言ってるんだけど。まあそう言ってもね、やる人はやるから。

miyagawa: DigitalOcean 使ってみたんだけど、EC2 とかと比べても立ち上げがすごい簡単にできるんだよね。コンソールからパパっとやったらすぐ立ち上がるし。あと、Image っていうのがあって、初期設定で OS を選ぶんだけども、それ以外にアプリのインストーラーみたいなのを入れることが出来るのね。そこにあるのが Wordpress とか Ghost、ブログシステムの、とか、あと Docker とか Dokku とかが初期インストールされた状態でイメージが60秒ですぐ立ち上がるっていうのがあって。

で、こないだ Dokku、Docker を使ったミニ PaaS、ミニ Heroku みたいなものなんすけども、のイメージをテストに試そうかなと思って。で、同僚は Vagrant を使ってやってたんですよ。で、僕は長年の経験から、Heroku みたいなドメインとか SSH とかワイルドカードとかを使うようなサービスを Vagrant でやるのはかなり yak shaving なんじゃないかな、っていう気がして、DigitalOcean にアカウントを作ってサクッと1分で「出来たよー」ってやってたんだけど。やっぱり同僚は、Vagrant で SSH するときに vagrant ユーザーと違うユーザーを作んなきゃいけなくて、みたいなところでハマったりとか。

21:17

kenn: （笑）だいぶ手前で。

miyagawa: そうそうそう。そういうのが年を取ってくると感覚として分かるようになるっていうね。

kenn: あー、そういう良いように解釈してるのね。年を取ると手抜きをしたくなるってことなんじゃないの（笑）

miyagawa: （笑）それもそうなんだけどね。

kenn: もっと掘って、自分でやりたくなるのが若者の、

miyagawa: そうそうそう。そういうので学ぶのが若者の特権なんで、全然良いんですけど。

kenn: うまいこと言ったね。

miyagawa: 実際 Dokku の開発者の Jeff Lindsay だったかな、progrium っていう人が DigitalOcean に先々週くらいに入ったらしいんです。で、この投資を受けたのもあるし、すごい hiring をしてる感じですね。

kenn: この人らニューヨークだよね？

miyagawa: そうなんだよね、ニューヨーク。東海岸でこういうのが出てくるってのも面白いですけど。

kenn: そうそう。まぁ Linode も東海岸だし。ちょっとずつ増えてきてるよね。

miyagawa: そうだね。

kenn: 段々 Diversity が広がってきてるというか、リモートの人も増えてるしね。

miyagawa: 確かに。progrium も Austin の人なんで、普段はリモートでやるっていう話をしてました。

kenn: あ、行かなかったんだ。

miyagawa: うん、そんな感じらしいです。

kenn: そっか。relocate しろ、って言われて辞める人もいるけどね。

miyagawa: なんかいたね。

kenn: Tim Bray（笑）Google がベイエリアに来いって言って。

miyagawa: あれバンクーバーだっけ？

kenn: そうそう、バンクーバー。

miyagawa: カナダ人にとってはちょっと受け入れがたいところはあるよね。

kenn: それはわかるけどね。アメリカのしかもベイエリアって。ハードル高いよね。

miyagawa: ベイエリアは人種差別的だし物価も高いしっていうのはちょっと分かるけどね。ま、バンクーバーも物価高いけどなぁ。

kenn: だよね。ただ、医療制度とかね、

miyagawa: その辺はね。家族がいる場合は特に、だよね。

kenn: 色々なものがぶっ壊れてないから、カナダは。

miyagawa: 確かに。

じゃあ、ちょっとここでスポンサーの紹介をします。先週スポンサーを募集したんですけども、早速ついてくれましたんで。Ruby on Rails Tutorial っていう英語の書籍があるんですけども、それの日本語版ですね。Ruby on Rails チュートリアル ー実例を使ってRailsを学ぼうー っていうサイトがありまして、railstutorial.jp っていうアドレスです。これはShow Noteとか Twitter の方からリンクしておきますんでそこをチェックしていただきたいんですけど。

2013年に Rails Tutorial っていう大型のチュートリアルをリリースしました。Twitter のようなマイクロブログサービスを題材にして、実際に手を動かしながら学んでいくスタイルのチュートリアルです。

これ、英語版は元々公開されてるんですけども、それを有志の力で1ヶ月で日本語に翻訳したということで。実践的な内容を重視してて、Ruby や Rails を学べるだけじゃなくて、RSpec を使ったテスト開発とか、Git とか GitHub の使い方、バージョン管理の仕方とか、実際に Heroku を使ってサービスをデプロイするところまで包括的に学ぶことが出来るチュートリアルです。なので、これを読み終わる頃には Web サービスの開発から公開までを体験を通して理解できるようになってる、と。そういう感じのチュートリアルです。で、実際の書籍で言うと725ページというすごい大きいものなんですけども、HTML は全て無料で公開していて、有料の電子書籍版、これは PDF と EPUB、それから ZIP で公開されてるんですけども、これは達人出版会の方から購入することが出来ます。

電子書籍版の方も DRM フリーになっていて、ライセンスは Creative Commons の BY-SA3.0 なので、1回購入すれば勉強会とか企業研修なんかで、コピーしてライセンスの範囲内で配布することが出来ます。実際にこのライセンスが使いやすいということもあって、多くの企業、大学、コミュニティで教材として採用されてます。

それでですね、この電子書籍版なんですけども、定価が2,980円なんですが、今日の朝から来週の3月16日の23時59分まで1,980円と1,000円引きの特化でセールをしますので。Rails に興味がある人とか新しくサーバーサイドのプログラミングを勉強をしたい人とか、あるいは他の言語、Python とか Java とか Perl とかを使っていて、ちょっと Rails を勉強してみたい、とか、そういう人にすごく良いドキュメントだと思うので、買ってみてはどうでしょうか、という感じです。railstutorial.jp から買うことが出来ます。

僕もこの英語版を昔読んだんですけども。全部読んだというよりは流し読みをした程度なんですが、他の言語とか Web のフレームワークをやった人から見ると公式のドキュメントを前から読んでいくのって結構だるいところがあって、こういうチュートリアルスタイルのドキュメントの方が読みやすいということもあるので、興味がある人は見てみてください。

26:05

kenn: これいいね。なんか、テーマ的にも Rebuild にピッタリじゃない？

miyagawa: そうだね。今日もこの後 Rails の話をもしかしたらするかもしれないんで。

kenn: うん、開発者のね。

miyagawa: そう、サーバーサイドの開発者もそうだし、最近モバイル系の開発の話をよく Rebuild でしてるんだけど、やっぱりクライアントサイドの開発をしつつサーバーサイドを人に頼まないといけないとか、でもプロトタイプを作りたくて早くサーバーサイドのコードをちゃちゃっと動かしたいみたいなときに、Rails ってすごくいいフレームワークだと思うんですよ。小さいものから大きいものまで対応出来るって意味では。だから、そういう人にもすごくいいんじゃないかな、という気がします。

kenn: 確かにね。これ、Heroku に出すようになってるからそれもいいよね。

miyagawa: あと、バージョンなんですけど、3.2に対応したバージョンが最初に出ていて、4.0のアップグレードとか、切り替えて読めるようになってるし、3.2から4.0にアップグレードするときの注意点みたいな章もあるんで、そこら辺も見てもらったらいいんじゃないかと思います。

kenn: ちゃんと Sublime も入ってるしな。

miyagawa: はい。スポンサーどうもありがとうございました。先週ね、スポンサー募集したところ当日にメールをもらって、トントン拍子でスポンサーしてもらえることになりましたんで、ありがとうございました。スポンサーをサポートしてもらえると、間接的にこの番組をサポートしてることになりますんで、ぜひこの特価セールの間に買ってもらうといいかな、と思います。

そうですね、じゃあリモートワーキングの話がね、naoya さんが出た時にちょっと盛り上がったんですけども。2回位前かな。kenn も結構リモートワーキングずっとやってるでしょ？

kenn: そう、もうずっとだからね。Infoteria USA のときの途中、最後の方くらいからずっとリモートだからね。で、パンカクのときも日本とこっちだったし、今は完全にバラバラだね。CEO がロンドンにいて、僕がラスベガスにいて、マーケッターの人がクリーブランド、オハイオにいて、デザイナーがニューヨークにいるっていう。で、デベロッパーがもう1人ロンドンにいる、みたいな感じですね。もう完全に、タイムゾーンも何もかもバラバラ。

miyagawa: 最初のさ、Infoteria のときっていうのは、こっちに支社を作ってローカルで hire してたりしたでしょ？

kenn: そうそう。最初は全員ローカル hire だったんだけど、途中でニューヨークのデザイナー hire して。でも最終的にその人は「引っ越せ！」って言って西海岸に引っ張ってきたんだけど、でも結局サンフランシスコに住みだしたら出社しなくなってきて。近くにいるんだけどリモート、みたいな感じになりだして。

miyagawa: あともう1人エンジニアが確かいたと思うんだけど、すごい朝型の人でさ、kenn がオフィスに行く頃にはもう帰ってる、みたいな感じじゃなかった？

kenn: そうそうそう（笑）朝6時位に来て、2時位になると帰っちゃうっていう。で、俺が朝行くの遅いからかぶってる時間短い、みたいな。でもみんな仕事早いからいいんだけどね。

miyagawa: で、パンキアみたいな、日本に会社があってそこにリモートで働くっていうのは僕も今もそういう感じなんだけど。そういうのと、例えばスタートアップで3～4人みたいなチームでリモートで出来るもんなのか、それともそれなりの難しさがあるのか。その辺はどうなのかな？

kenn: やっぱり難しい部分っていうのはどうしてもあるっちゃあるけど、でもいい部分もやっぱあるよね。自分のペースで集中してやれる、とか。だから、ほんとに考え方次第だとは思うけどね。開発の人にはいいんじゃない、リモートワーキングは。

miyagawa: 逆に言うと開発以外の仕事はちょっと難しいところがある？

kenn: うん、やっぱりコミュニケーション中心だもんね。だから、テレマーケティングとかテレセールスみたいな人だったらいいのかもしれないけど、実際マネジメント的な仕事をしてる人ってやっぱり顔見て話したいってのもあるし。

miyagawa: でも小さい会社だとマネジメントっていうのはそもそも必要なかったりするじゃん？

kenn: まあね。マネジメントと言うよりは「相談」というか。「どうしよかな～」みたいな、あるじゃん？具体的にタスクをやっつけてくっていう顔合わせじゃなくて、「いや～、これじゃちょっとねぇ。どうしてくかね、今後」みたいな。

miyagawa: （笑）

kenn: のんべんだらり的な話ってやっぱ、ねぇ。スケジュール決めて「じゃあ今日の9時からやりましょう」みたいな話し方でもないじゃん。そういうところがどうしてもやりにくくなっちゃうよね。だから決まった方向を変えるのが難しくなっちゃうよね。

miyagawa: 一旦決めた方向に突っ走るのはある程度リモートでも出来るけど、それを修正してくのがなかなか言い出しにくいみたいなのはありそうかな。

30:55

kenn: 方向を変えるのってすごい慣性があるっていうか、パワーも持って進んでる物の方向を変えるのってすごい大変だから、もうずっと押し続けないといけない、みたいな。それをやるのはやっぱコミュニケーションの力だから、定期的なミーティングとかそういうタスクやっつける時間のなかで伝えきるのはかなり無理があるというか。そこが一番大きなハードルだろうね。

miyagawa: kenn の場合もう1人のデベロッパーがロンドンにいるって話だけど、そこは結構、

kenn: そうね、そこはもうタスクベースでつながってるから「これをじゃあやりましょう」みたいな感じでアサインができるからいいっちゃいいんだけどね。それよりも、会社の方向性みたいなね。

miyagawa: 例えば CEO は今ロンドンにいるから、結構タイムゾーンが違うよね。

kenn: そうそう（苦笑）だからこっちの早朝にやったり、結構時間もまちまちなんだけど。

miyagawa: オーバーラップする時間が2～3時間って感じかな？

kenn: そうそうそう。だからお互いに時間をずらして生活するしかない、っていう。

32:06

miyagawa: でも、もしかしたら今後、合流してっていうこともありえるわけだよね。

kenn: そうそうそう。US に最終的に来るから、それで僕が東海岸に行くとかってなったら合流することにはなるけどね。だから、リモートではなくなるってことかもしれないけど。

miyagawa: リモートじゃなくなるの久しぶりってことだよね？

kenn: そうだね。コミュニケーションが重要ってことは結局ツールが重要って話になるんだけどね。

miyagawa: やっぱりチャットとかビデオチャットとか、

kenn: そうそうそう。普段から大体 HipChat 開けっ放しにしといて。僕 Lingr とか作ってるけど、色んな製品使ってみないとイカン、と思って。

miyagawa: それ言い訳？

kenn: 言い訳（笑）HipChat を一応使ってみてるんだけど。で、なんかあったら垂れ流し、用事があれば @name で呼び出して、みたいな。それ以外の場合、定期的なミーティングは全部 Skype でやってるけど。そういうツールがあるおかげでそんなに違和感はないというか、ちゃんと仕事は出来るよね。で、実際タスクやる部分は GitHub のイシューとかプルリクエストベースで進むから。

miyagawa: GitHub のプルリクエストとかはね、すごく非同期のコミュニケーションがしやすいようになってるからね。

kenn: そうそうそう、そのためのもんだからね。素晴らしい。今の時代でよかった（笑）

miyagawa: 確かに（笑）テクノロジーがどんどん進化してると、その辺やりやすくなってはいるけどね。

kenn: そうね。ただ、競争相手もみんなおんなじ状況だから、自分たちだけが優位になってるわけじゃなくて、どんどんその前提で hiring とかもするようになるじゃん。だから「リモート」っていうのを benefit にして hiring する人が増えると、そういう人たちのところに優秀な人が流れていく、とかね。そういう現象も段々起こってはきてはいるけど。

miyagawa: うん。37Signals、今は Basecamp に変わったんだけど、そこは Job Board ってのを昔からやっていて。で、最近名前が変わって、We Work Remotely っていうジョブサイトに変わったんだよね。つまり「リモート専門」の Job Board になってて、試しに求人広告を出すステップを調べてたんだけど、最初の画面で「リモートの求人広告ですか？ はい いいえ」ってボタンがあって、「いいえ」ってやると戻っちゃうの（笑）

kenn: （笑）なるほど。

miyagawa: フォームが閉じちゃう。

kenn: やっぱ Opinionated。

miyagawa: そうだね。Job Board ってやまほどあるから、特化した Job Board 出したほうが、

kenn: 差別化になると。

miyagawa: うん、探す方もいいと思うんすけどね。

kenn: そうだよね。なるほどねー、色々考えるなぁ。

miyagawa: まあそんなところですか。リモートワーキングは色んな人が最近してるし、ゲストに色々な人が出てくれると思うんで、その度に話を聞いていこうかな、とは思ってますけどね。

kenn: なるほど。

35:12

miyagawa: はい。じゃあ最後になると思うんすけども、こないだ Twitter でね、API のバージョニングっていう細かい話ではあるんですけども、kenn が呟いたのをきっかけに盛り上がったんで。まずはブログポストを kenn が今週書いてたんだけど。ざっくり話してもらえますか？

kenn: はい。書いた話としては、API のバージョンってみんななんとなく必要な気がしていて、最初 API 設計する段階で入れとくっていう風にしてると思うんですけど。それを api/v1、api/v2 みたいな形で URL にして決めてる人ってのが結構多くて。これ有名なサイトがみんなそうやってるからだと思うんだけど。URL に入れるかってのと、コントローラーを分けるかっていうのは別の話なんだけど、それをコントローラーを分けるという風に設計してる人っていうのも世の中には一定数いて。で、それでやるとあとあと大変になるよ、と。というのが、僕昔それでやってたときにハマった落とし穴だったので、そういう大局で分岐するんじゃなくてパラメーターとして v1 とか v2 っていう情報をとっといて、必要なところで最小限の if 文で分けていく、っていう方がいいんじゃねえの？っていう話をしたんですよね。

miyagawa: なるほど。実際、ハマったっていうのはどういうとこですかね？

kenn: 基本的には v2 作る時点でまず全部コピペですよね。で、設計を変えたいから v2 にしてるわけなので変えるところは沢山あるんだけど、かぶってる部分っていうのも当然いっぱいあるわけで。そこの部分っていうのがどうしても二重になってるのが気持ち悪いまま。「これ v3 無理だなぁ」って v2 の時には思うっていう状況に陥ったんですよね。

miyagawa: そうね。このポストはいろんな側面の話が載ってるんですけども。賛成するところも賛成しないところも僕はあって。まず最初に、kenn もさっきも言っちゃってたんだけど、URL を分割するかというのと、コントローラーをコピーするかっていうのは、必ずしも同じではないと思うんだよね。

kenn: うんうん、それは同じではないね。

miyagawa: ロードバランサーで /v1 と /v2 を違うホストに分けたりとか、あるいはコントローラーのルーティングのところで「v数字+」でマッチして同じ実装に飛ばす、てこともありえるし。まあ必ずしも一対一ではないんだけど、普通の Web フレームワークとして考えた場合は、ディレクトリが分かれていてコントローラーが分かれているみたいなことになるよね、っていう前提で話をしてるわけだね。

kenn: そうだね。

miyagawa: そうはその通りだと思っていて。複数のやり方が多分あって、どれがベストかっていうのは人によって違うよね、って話で終わっちゃうかもしれないんですけども。多分比較してるのは「1つの実装があって、そこで複数のバージョンの差異を吸収する」のがいいのか、「複数バージョンを持っていて、バージョン1、バージョン2 っていう複数の実装があってそれをメンテし続けるのかし続けないのか」みたいな話ですよね、基本的には。

kenn: そうですね。

miyagawa: で、最初に細かいツッコミをすると、このポストの最初の方に「リクエストコンテキスト」っていうのが出てくるんですよ。これはどういうことかっていうと、API の実装が1個だったとすると、そのリクエストがバージョンいくつで来たかっていうのを判断しなきゃいけないよね。それが URL だろうがパラメーターだろうがヘッダーだろうがなんでもいいんですけど、kenn の主張は、Ruby の話ですけど、スレッドローカルな変数を作ってそこにどこからでもアクセスできるようにしよう、っていうことですよね。それは、なんでリクエストオブジェクトとかに生やさないのか、っていうのが1つなんですけど。

kenn: あー、まあそれでもいいっちゃいいんですけどね。ただ、リクエストっていうオブジェクトってモデルから見えなくなっちゃうよね。だからそれをモデルからも参照できるようにするために入れてるって感じ。

39:40

miyagawa: 要は言い方を変えるとグローバル変数ってことだよね？

kenn: そうそうそう。

miyagawa: モデルの方に「今のリクエストはどういうリクエストか」っていうのが侵食していくのは、どう考えてもあんま良くないんじゃないかなって思うんだけど。

kenn: うん、まあそれも書いてはあるけどね（笑）

miyagawa: それに関する反論はないの？

kenn: だから多分、みんなあんまりやったことないんだと思うんだよね。それ自体の痛みっていうのもやってみないと分かんないし。僕はやってみた限り一応ありだな、っていう感触を得てるのね。

miyagawa: リクエストのバージョンが1か2かによってモデルのなかのメソッドの実装が分岐する可能性があるってことだよね？

kenn: そう。で、何も API のバージョンが渡されてない場合には最新のものが使われるっていう、GitHub と同じようなやり方。GitHub の API は v3 って指定しなければ v3 になるというか、current のものが使われるっていう風になってると思うんだけど、それと同じような形で動くようになる。

miyagawa: なるほどね。それに関連してるのかもしれないけど、kenn が「REST については信用出来ない」っていうツイートを書いていて、

kenn: なんか色んなところにぶつかってるな、俺（笑）

miyagawa: どういうツイートだったっけな…

kenn: REST はあんまり宗教的な信じ方してない、ていう話だよね。

miyagawa: 「ちなみにRESTfulについては、名詞＝リソースを扱うというアイデアまでは良いのだけど、数万語ある豊穣な英語の動詞を、限られたHTTP methodsだけで無理やり表現しようというところが同意できないので、信じ切れない。」と。

kenn: それだ。

miyagawa: 僕はね、半分同意だけど。僕は REST は結構いいモノだと思っていて、基本的にはね。REST のポイントは名詞が URL でメソッドが動詞だってこととは全然違うと思ってるんで、ちょっと違うんですよ。

kenn: なるほど。

miyagawa: じゃ REST とは何か、てこと話出すとおわんない話になっちゃうんですけど（笑）

kenn: （笑）でも知りたい。

41:40

miyagawa: 僕は REST のポイントはリソースだと思っていて。URI ＝ リソースで、リソースに対する操作を HTTP のメソッドで表現する、と。で、それが1つなんですけどそれだけじゃなくて。例えば表現形式、ブログのポストっていうのを JSON で取るとか XML で取るとか YAML で取るとかっていうのは Rails とかだと respond_to とかで入ってるんだけど、それってただのフォーマットだと僕は思っていて。JSON だろうが XML だろうがデータの表現形式は同じだと思うんですよ。それを、フォーマットを変えられるのが REST のいいとこだ、っていうのはちょっと違っていて。最近は media type っていうのを注目することが多いんですよね。

kenn: ほう。

miyagawa: Hypermedia とか HATEOAS っていうのかな、Hypermedia as the Engine of Application State て言うんですけど。要は、同じデータなんだけど形式が変わっていくっていう物、それのエンコーディングが JSON だったり XML だったり YAML だったりするっていう、そういう二段階になるのが media type だ、っていう考え方で。例えば application/json っていうのは、media type ではないんですよ。それはただ JSON って言ってるだけで、そのなかに何のデータが入ってるかっていうのは何もいってないから、クライアントはどういうデータが返ってくるかわかんないわけ。

kenn: はいはいはい。

miyagawa: だけど、media type っていうのはそこから行って、(application/)vnd.github.v3.comment+json とかやると、GitHub のコメントをバージョン3形式で JSON にエンコードしたものをくれ、ってことになるわけですよね。で、それに対して v4 を今作るから v4 をくれ、って MIME Type をちゃんと使えば出来るってのがあって。じゃあ普通に query parameter で v=4 って書くのと何が違うの？って思うと思うんですけど、まあやってることは一緒なんですよ。だけど、それが HTTP の semantics の上に乗ってると、キャッシングとかコントローラーの実装とか、フレームワークが REST、HTTP のレイヤーの上に実装するのとすごく相性が良いというかね。

kenn: そういうことか。だから、そのリソース自体にバージョンというか、media query みたいなやつにバージョンが乗っかってるってことね。

miyagawa: そう。そういうのもあるし、あとは、リソース同士の接続っていうのかな、Link ってのもあるんですよ。Hypermedia っていうのは Hypertext とかいうと思うんすけどね。要はインターネットのリンクってあるじゃん、"a href" の h は hyper なんだけど、あるオブジェクトからあるオブジェクトへのリンクっていうのが a タグで表されてるんだけど、そういうのも Hypermedia を使うと「このオブジェクトのコメント一覧はこの URL で取れるよ」とか、そういうリンクを張ることが出来る。なんかそういうのが Web のスタンダードなところに乗るのが REST、Hypermedia だなぁ、っていう風に思っているので。REST は意味がない、っていうと僕は賛成しかねるっていう感じですね。

kenn: はいはいはい。そういう意味ね。だから、Web のアーキテクチャとしての REST って話と API としての REST っていうのはまた別の話だよね。

miyagawa: うーん、別というか、Web としての REST を API にマッピングすると Hypermedia API になるよね、っていうのが最近の考え方の1つで、それが正しいのかどうかとか、それが他よりベターかどうかっていうのは、もう宗教論だと思うんですよ。だから、そういう考え方もあるし、そういうのを無視して「REST は良くない」とか「REST は全然現実にそぐわない」とかっていうのはちょっと違うな、って。それだけの話なんだけどね。

45:21

kenn: そういう意味ね。じゃ、踏んじゃいけないしっぽを踏んじゃった感じだね、僕の場合は。

miyagawa: それもあると思うんだよね。で、この話をしててもキリがないんですけども（笑）

kenn: （笑）

miyagawa: このポストで同意するのは、v1 とか v2 っていうのは、設計を根本から変えたいときに変えるべきだ、っていうのは僕も賛成なんですよ。つまり、ちょっとここのフォーマットのパラメーター名を変えたい、とか、ここがハッシュだったのを配列にしたい、とかで、v1 とか v2 とかにするのはあんまり良くないなぁ、と思います。

kenn: あ、そうなんだ。配列にするのダメ？

miyagawa: いや、互換性がちょっとなくなるくらいの変更を、v1 とか v2 とかでコピーするっていう意味でね。

kenn: そしたらそれはどうやってやるの？例えば、型が変わるって難しいじゃない。

miyagawa: そうね、だから僕は今やりたいと思ってるのは、基本的な RESTful な API はまずあって、そこはクライアントに対しては基本的に互換性を持ったままに、できるだけ伸ばしていこうっていう風に思っていて。例えばフォーマットが変わるんであればキーの名前を変えるとか、要は両方の実装が同一で存在できるようにするっていうことですね。それはどこまで出来るかっていうのは結構難しいところはもちろんあって、どうしてもパラメーターの型がクライアントから送られてくるのが変わったりとか、そういうのは全部が判断できるかっていうと難しいんだけど。今僕が作ってる API だとローンチしてから1年くらい経ってるんだけど、互換性を壊す変更はいまんとこ1回も入れてないので。それは出来ないことはないだろう、という風には思っています。

kenn: なるほどね。ちなみにね、そのバージョンで気軽に変更すると言ってるけど、僕が実際にやった変更って4年間運用しててバージョン5までいったのかな。だから、1年に1回くらいなんすよ、まとめてやるって感じで。だから1年目だと分かんないよ（笑）

miyagawa: （笑）

kenn: 来年くらいになったらまたなんかやりたいかもしんない。

miyagawa: でも、今のその言い方だとさ、数が多いわけではないからやってもいいっていう感じじゃないっすか？

kenn: うーん、まあね。

miyagawa: 要は逆に言うと、数を多くするならあんま良くないっていう風にも聞こえるんだけど。

kenn: そうだね。分岐がたくさん増えるってありえないよね。だからすっごい痒いところだけを対処するっていう。

miyagawa: わかる。でも、クライアントの開発とかをちょっとやってみて思ったんですけども、クライアントが全部自分の管理できるところにあれば、そういう変更を入れてね、「ここちょっと変わるから変えて」っていう風に言うのは出来るんだけど、モバイルクライント、iOS のアプリとか Android のアプリとかは、1回出したアプリが結構ずっと使われたりするわけだよね。

kenn: そうなんだよねぇ。

miyagawa: だから、いつまで deprecate 期間を持たせるかとかっていうのも結構難しくて。それも1つあるのと、あとやっぱりそういう互換性のない変更はなるたけ少ない方がいいっていうのがサーバーサイドの考え方なんだけど、クライアントはそんなこと知ったことじゃなくて、どんどんいい風にしていきたいわけですよ。で、そこのせめぎ合いっていうのが多分あって。Netflix のブログとかを紹介してるブログで最近出てきた考え方の1つが、LSUD vs SSKD って言うんですけども。large set of unknown developers って、要は「多数の自分のビジネスとはステークホルダーが違うデベロッパー」と、small set of known developers 「数が限定されていて、自分の限りなく内部に近いデベロッパー」を相手にする API と、そういう2つの API があるよね、っていう話をしてるんですよね。

kenn: なるほど。

49:20

miyagawa: 僕が思ったのは、kenn が話してるやつは large set の方に入るんじゃないかな、と。

kenn: そうだね、コントロール出来ない世界の話だね。

miyagawa: だから、例えばPankiaとかの API を SDK で配って、古い SDK を使ってる人がずっといたりとか、特定のクライアント、アプリだけに特化した API を出すのではなくて一貫した API を用意してみんなにそれに合わせて使え、ってやり方だと思うんですよ。で、Netflix がやってるのは、Netflix の API っていうのはもちろんあるんだけど、テレビとか Xbox とかがアクセスする API なんで、限りなく内部のクライアントに近いんだよね。

で、API 開発者が Xbox とか AppleTV 用とかに API をゴニョゴニョ用意するのは現実的じゃないんで、そういうクライアントを開発する人たちがサーバーサイドに API を開発できるようにしようよ、っていう流れが最近ちょっとあるかなぁ、とは思ってるんすよね。

kenn: それが前言ってた Orchestration 層みたいな話につながる？

miyagawa: それに繋がってくるね。

kenn: じゃあ Cookpad もそういうことやろうとしてんの？

miyagawa: 僕もまだここは始めたばっかりのトライアルなんですけども。どういうことかっていうと、今僕が作ってる API とかね、iOS とか Android とかから使われていて、1つの API で複数のクライアントが叩くんですけども。設計自体は RESTful で実装されていて、デザイン自体はいいものだと僕は思ってるんですけども。やっぱり、他のクライアントが「こういうデータを返して欲しい」とか、「この Android のページをロードするときに、この API を叩いた後 ここの API を叩いてこの API を叩かなきゃいけない」みたいなケースが結構出てくるわけですよ。

kenn: うんうんうん。

miyagawa: バッチの API とかも用意してるんだけども、どうしてもそれ専用の API を用意したほうが良くて。でも、じゃあクライアントの数がどんどん増えていくと、API チームが iOS のトップページ用の API これ、Android のトップページ用の API これ、とかいうのをどんどん生やしていくいくと、コピペとおんなじ話になっちゃうわけですよね。

kenn: （笑）それはひどい話だ。

miyagawa: だからそれ難しくて。でもかと言って「そういうことは出来ない、どっかのデバイスに特化した API を作ることはうちらはやらないから」って言ってると、スピード感とかもなくなるしクライアントのユーザーエクスペリエンスが低下するわけですよね。実際に API を叩く数が増えるから。モバイルだとレイテンシとか下がってくるんで。

kenn: ありえないね。画面起動するまでに10回呼ぶ、とかね。

miyagawa: そうそう。非同期で出来るとはもちろん思うんだけど、そういうのはどんどん最適化していく方がいいわけですよ。

kenn: 順序性があったりすると、やっぱ縦に呼ぶしかなくなるからね。

miyagawa: だから、API っていうのは2つの役割があるかな、と思ってて。Web API もそうなんすけど。要は、モデルに対するアクセスをインターフェースとして提供する Web API っていう役割と、単純に iOS とか Android とかのクライアントに対するリモートプロシージャ的な API っていうのが多分あって。それを1つの API で両方対応しようとするのはちょっと無理があるかな、って最近思ってるわけです。

kenn: ほー。つまり、ジェネリックな REST API 自体はそもそも限界がある、と。

miyagawa: 限界があるというか、そこ自体の需要はもちろんあるんだけれども、それで全てをさばくのはちょっと難しいかなと思っている。だからそこをラップするというかね。

kenn: それはね、ずっと悩ましいことなんだよね。今まで一度も解決されたことがなくて。例えば、集計演算みたいなものってすごい難しいものじゃない。ユーザーの数を数えるみたいなのを API なしにやるって不可能じゃない。実際に全部取ってきて数えるしかない、みたいな。すっごい無駄だし。

miyagawa: 単純に API の数が多すぎるっていう問題も1つあるし、後は今みたいにサーバーサイドに何か処理を動かさなきゃいけないようなときは、単純に HTTP の REST を何回も呼べばいい話ではないので、サーバーの方にコードを置いて動かしたい、みたいな話もあるし。そこの両方だなぁ、と思っていて、それを解決する方法が「これだ！」っていうのはまだないんですけども、一応 Netflix の事例とかを参考にさせてもらいながら今は研究していて。

Netflix の例だと、クライアント開発者が JVM の Groovy か何かでラッパーのコードを、Heroku のような Platform as a Service みたいな感じでデプロイすると、それが API のバージョニングが勝手にどんどん上がっていって、クライアントはそこを叩けばいい、と。で、API チームのリリースサイクルと、クライアントチーム用の API のサイクルは全然独立してる、っていう。

kenn: これ、クライアント開発をしてる人たちがサーバーサイドのスクリプティングもしちゃう、ってことでしょ？

miyagawa: そういうことだね。例としては、API チームが管理しないところのパスにクライアントチームがコントローラーいつでも置けるよ、デプロイしていいよ、っていうのが多分それの原始的なパターンだと思うんだけど。それによってコントローラーが出来る範囲が全く抽象化されてないわけじゃないですか。コントローラーで出来ることが多すぎる、とかね。やっぱりそこは API 通した方が一段抽象化があって、バグ修正の箇所とかが減るとか。そういうところは多分あると思うんですよ。

これはあんまり話してない話だと思うんだけど、Cookpad には昔は iOS とか Android のアプリ専用の API っていうのがあって、別コントローラーになってたんですよ。僕は当時は「これはあんまりよくないな」と思ってたんだけど、今考えるとそういうニーズを満たすためには

kenn: それしかなかった、と。

miyagawa: そう、良い所もあったという風に思っていて。で、今はそういうのがなくなって、1個の API で統一されていていいんだけども、逆にそういうフレキシビリティが失われつつあるので、そこを両方考慮しなきゃいけないな、っていうのは思っている。

55:06

kenn: はいはいはい。これでも現実にやるのすっごいハードル高いよね。サーバーサイドでスクリプティングする、例えばデータベース叩く API みたいなのをほぼ関数レベルで用意するみたいな話だと思うんだけど。Facebook が買った BaaS、parse.com みたいなことが出来るものをサーバーサイドに用意するってことだよね。

miyagawa: 基本的には MongoDB みたいなジェネリックな Query Interface を用意してあげて、それを簡単なスクリプトで API 化出来て、それが理想的には本体の API のデプロイと無関係にいつでもデプロイ、変更、バージョニングできるって風になってるといいんだろうなっていうのがあって。だから、技術的なチャレンジと、そういうプロセス的なチャレンジっていうのもあると思うんですよ。

今の API 変更とかは API チームがレビューして OK 出してデプロイするんで、そういうワークフローを無視して出来るようにするってとこもあるから。両方チャレンジだな、と思っている。

kenn: これ、もう1個スタートアップ作ってるようなもんだよね。ある意味（笑）

miyagawa: （笑）そういうことだね。

kenn: Parse を社内で作ってる、みたいな話でしょ。

miyagawa: parse.com がやってることがそうなんで、そういうものが必要だって話。「parse.com でいいじゃん」って言われればもちろんそうなんだけど、完全ではないと思うので。

kenn: 実際、自社のデータベースにアクセスするってなると自分たちで作るしかないから。なかなかすごいね。なるほどねぇ。

miyagawa: バージョニングっていうのも、多分そういう話になってくると、クライアント開発者が作る Orchestration 層、ラッパー層のバージョニングになってくると思っていて。コアの API の方のバージョニングはもちろん設計を大きく変えるんであれば変えるんだけど、クライアントのバージョンに合わせて変えるっていうのは PaaS のところでやればいいから、もうちょっとフレキシブルに出来るんじゃないかな、とは思ってる。

kenn: どういう API になるんだろうなぁ、そこがすごい興味あるな。単純な REST じゃなくなるよね。DB 直接触れるようにしたりする API ってことだよね、ある意味。

miyagawa: 多分 REST ってよりは HTTP の Query Interface みたいになって、それこそ Mongo みたいな感じで。それとか ElasticSearch みたいなクエリに文字列書いてそれが実行できる、とか。もしスキーマが定義出来れば「レスポンスは JSON になって」とか出来て、Android とか Objective-C から簡単に型情報が呼べるとか。そういうクライアント開発に特化した API になっていくとは思うんだけどね。そこに REST が使えるかもしれないし使えないかもしれないっていう、そういうとこかな。そこは「REST にならないからこういう API はダメだ」とかいうのはあんまり現実的ではなくて、REST のフレームワークとしての力が使える場所もあるし、無理やり合わせて大変になるよりは REST とか無視して単純に RPC みたいなの実装した方がいいところもあるかもしれないし、とは思うよね。

kenn: 逆に言うとクライアント開発者がそこは自分で決めりゃいい、ってこと？

miyagawa: そうだね。そういう話になってくると思う。

kenn: サーバーサイドの API と呼んでいるものはもっと後ろに、下のレイヤーに下がるってことだよね。

miyagawa: うん、そういうことだね。下がることによってボトルネックが増えるとか、

kenn: 予想できない問題とか。

miyagawa: レイテンシが増えるんじゃないかとか。そういうのは付随する問題点、チャレンジとしてはあるとは思うけど。

kenn: レイテンシっていってるのは「更にバックエンド叩くから」ってこと？

miyagawa: そう、そういうこと。

kenn: それはでも Ethernet のなかだから0.1ミリセカンドとかの世界だと思うけど。

miyagawa: そうだね。例えば10個リモートの API を叩くよりは、1個叩いた先で10個ローカルでやる方が絶対速いとは思うから。

kenn: うん、絶対速い。

miyagawa: そこはもちろんそうだと思うよ。

kenn: なるほどね。そこずっと課題には思ってたから。バッチ用の API 用意したりとかそういう風にみんなやるんだけど、なんかあんまりうまくいってなかった印象があるから。これは確かに来るかもしんないね。

miyagawa: こういう流れは多分あるな、と思っていて。僕はどうしても前の仕事とかだと、kenn もそうだと思うけど、不特定多数に対して API を作るっていう考え方だったので、API として芯の通ったものがあってそれに対してクライアントが合わせるべきだっていう風に考えてたんだけど。

kenn: そうそうそう。

miyagawa: モバイルの世界でいくとそういう考え方だけではダメなのかな、っていう風に最近考え方を変えてきた、っていう感じですね。

kenn: なるほどね。UI を早く作るために必要な方に寄せる、と。クライアント側で作る工数が増えてきてるからね、そっちを早くすることの方が重要になってきてるってことだよね。

59:58

miyagawa: うん。あと、技術的にもクライアント開発者が API をサクサク作れるようになって欲しい、なるべきだと思うんですよ。だから、クライアント開発者に「うち Rails でサーバー作ってるから Rails の勉強してこい」ではね。まあそれでもいいんですけどね。Rails チュートリアルを買ってこい、でもいいんですけど。

kenn: （笑）

miyagawa: それプラス、やっぱり並列性に強い言語ってのはもちろんあると思うんですよ。Rails って REST とかの API を実装するにはいいフレームワークだと思うんだけど、例えば Node とか Scala とか、フルスタックな API を作るにはちょっと向かないかもしれないけど、並列性に優れたラッパーみたいなの作るにはすごく向いてる、みたいなことってあると思っていて。

kenn: はいはいはい。

miyagawa: そういうところに出番があるかな、っていうのはちょっと思ってる。

kenn: そうか、間に1個入るからそこの選択の自由度も増えるわけか。

miyagawa: そうなんだよね。

kenn: なるほどね、それは面白いね。

miyagawa: そういう細かい話になっちゃいましたけどね。これどんだけ伝わってんのかな、っていう。

kenn: いやー、難しいんじゃないかな（笑）

miyagawa: （笑）

kenn: だって v2 に行ったことある、っていう人が今まで1人も出てないくらいだからね。痛い目に合わないとなかなか。

miyagawa: 最初の話に戻りますけど、v1 とか v2 を用意すること自体は悪くはないと思うんですよ。

kenn: まあね、準備としてね。

miyagawa: ただ、パスにするよりはホスト名とかでやった方がいいかな、って最近思っていて。細かい話ですけど。さっき言ったみたいに設計自体を変えるっていう話だと、1つの実装で複数をさばくっていうよりは根本から変える、みたいな実装とか別言語で実装して複数のインスタンスを走らせておく、みたいな事になったほうがいいと思うんだよね。

kenn: いやー、それうまくいかないことがあるんですよ。何故かと言うと DB の構造とか変わるから、開発が進んでる先の方で。そうするとどうしても吸収するレイヤーを古い方にも追加してやんないといけなくなったりして。

miyagawa: そこはでもね、一瞬思ったんだけど、DB の構造変えるのって…「それが必要なんだ」って言われればそうなんだけど。あんま良くないよね、とは思うんですよ。

kenn: 基本的には追加するだけで済めばいいんだけど、ALTER TABLE としては。

miyagawa: だから、DB のスキーマはもちろん ALTER とかするかもしれないけれど、DB のモデルのコードは古くてもある程度は許容出来た方がいいよね、と僕は思って。

kenn: いや、もちろんそうなんだけどね。

miyagawa: そうしないとロールバックが出来ないじゃん、デプロイするときにさ。

kenn: そうね。

miyagawa: ただまぁ、ある段階で古いモデルのコードはアクセスできなくなるっていう可能性がもちろんあるのは分かっているんだけど。

kenn: そう、だからそこまでして切り離すときっていうのは多分それぐらいの変化が起きるときの可能性が高いから、結果的にうまくいかない可能性が高いかな、という気がする。

miyagawa: 確かに。ちょっと言葉だけでどんだけ伝わってるかわかんないんすけど。naoya さんが「伝わってるよ！」って言ってくれてるんで（笑）

kenn: おー、素晴らしい。さすが。

miyagawa: Show Notesにね、Netflix の記事とか kenn のブログもそうだし、色々参考になりそうなページにはリンクしときますんで。興味ある人は見てもらうといいと思いますし、あとトランスクリプトがもしかしたら出るかもしれないんで、補足したい人はそれを見てもらうとか。そういう形でやってもらうといいかな、と思います。

Show Notes rebuild.fm/35 から見れます。このエピソードは、Rails チュートリアルのスポンサーでお送りしました。興味ある人はぜひ見てみてください。スポンサーどうもありがとうございました。

じゃ、そういうことで。

kenn: うん、そんなとこですかね（笑）

miyagawa: （笑）

kenn: 続きはまたの機会にね。

miyagawa: 続きはまたね。僕もね、色々スキップしちゃったんで、言い足りてないとこがあるんですけども。でも言ってももうしょうがないんで（笑）

kenn: （笑）

miyagawa: はい、じゃあそういうことで。

kenn: じゃあ。

---

Transcribed by @harupong http://blog.harupong.com/