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

0:00

miyagawa: 昨日何かイベントがあったらしいですけど。

naoya: そうそう。JAWS DAYS っていう、AWS の。

miyagawa: JAWS っていうのは？

naoya: JAPAN AWS、かな。Amazon の会社の方じゃなくて、ユーザーが集まってやってるほうですね。

miyagawa: ユーザーコミュニティみたいな？

naoya: そうそう。もう1つ AWS Summit ってすごいでっかいイベントがまた夏にあるんですけど、そっちは Amazon 主催でやってるから、結構 Enterprise track とかもたくさんあってっていう感じで。JAWS の方は本当にユーザーコミュニティが主体なんで、わりとテクニカルな話が中心に全体が進んでいく、みたいな感じの雰囲気ですね。

miyagawa: naoya さんはそこの、Immutable Infrastructure track の先頭を切って、みたいな感じですね。

naoya: そうですね。一番最初に話しました。会場1000人くらい来てたかな。

miyagawa: 1000人！？マジっすか。

naoya: CROSS やったのと同じ西新宿のベルサール新宿グランドっていう会場だったんですけど、1000人くらいは多分入ってた気がしますね。

miyagawa: すごいなぁ。何 track かあるんでしょ、でも。

naoya: 5 track 並行、って感じでした。

miyagawa: Immutable Infrastructure が一番人気ですか、そのなかでも？

naoya: そうそう。結局、僕のセッションが最優秀スピーカーに選ばれたんですけど。

miyagawa: おー、さすがです。

naoya: ただ、しゃべりがどう、っていうより、Immutable Infrastructure が単純にすごい注目を集めてたから。それがほとんど、みたいな感じですけどね。

miyagawa: こないだ、Podcast じゃないとこで kenn と話してたんだけど、Immutable Infrastructure っていう言葉を使ってるの、ほとんど日本語のブログ、Twitter ばっかりなんですよ。

naoya: ほうほう。

miyagawa: だから、元々その言葉を作ったって意味では Chad Fowler さんのブログが最初だったりするけど、それがバズワード的に盛り上がってるのは日本の Twitter、ブログ界隈が多そうかな、っていう印象を受けた。

naoya: こぞって乗っかりましたからね。その辺やってる人たちが。

miyagawa: そこはね、この番組の episode 25とかでそういうバズワードを増幅するようなことをやってるんで。

naoya: （笑）

miyagawa: それも一役買ってるかもしれないけどね。

naoya: 昨日は Immutable Infrastructure 以外も track いくつかあったんですけど、常に Immutable Infrastructure track が立ち見であふれかえってて、全然他の人が入れないくらい盛況でしたね。

2:49

miyagawa: Immutable Infrastructure がね、難しいからね発音が。

naoya: そうなんですよ。一応昨日のカンファレンスのなかでは「II(アイアイ) って略しましょう」って話が出たんだけど、II じゃよくわかんねえな、みたいな。

miyagawa: （笑）それ Twitter とかの検索ビリティがめっちゃ低い。

naoya: （笑）そうそう。

miyagawa: まあでも、コンテキストを共有してる場所ではいいかもね。すごい噛むし。

naoya: 僕10回以上噛みましたね。

miyagawa: （笑）

naoya: Immutable Infrastructure と、Infrastructure as Code って言わなきゃいけなかったんだけど、Infrastructure が言うのがつらいんですよ（笑）

miyagawa: つらいねー。Infra で切っちゃえばいいんじゃない？とりあえず。

naoya: Immutable Infra...確かに。で、そんな感じですごい盛り上がりました。資料はもうブログにアップロードしたんで、もし気になる方はブログの方読んでもらったりとか。

miyagawa: そうですね。Show Notes の方からリンク張っておきますのでお願いします。

先週の Podcast がすごい盛り上がったんですけど。kenn が出てくれて、API のバージョニングとかについて話して。いろいろフィードバックがあって面白かったんですけど、一番面白かったのは yohei さんが書いてるブログで。REST とか media type とか HATEOAS とか言い出すと、こういう界隈の人に引っかかるんですけど（笑）

naoya: （笑）

miyagawa: 僕が「media type とか RESTful とか Hypermedia は素晴らしい」とか言ってしまったら、「そういう側面もあるんだ。意外だった」みたいなね。

naoya: （笑）miyagawa さんが、ですよね。

miyagawa: そうそう。一応釈明しておくと、そこまで厨房的な発言をしたつもりはなくて、Podcast の側面上二人とも同じような話に同じような態度で話していくと、「そうだよね」「そうだよね」で終わっちゃうんで。「こういう見方もあるよ」っていうのを提示したかった、っていうのはあるんですけど。

naoya: REST 厨（笑）

miyagawa: Hypermedia 厨とかね、media type 厨とか言われてまして。

naoya: media type 厨だいぶミクロだ。

miyagawa: かなりニッチだね。実際、今作ってる API は media type を最初は使ってたんですよ。要は、JSON で吐くんだけど、その JSON のなかに含まれてる data type はクライアントが欲しいデータによって変えられる、みたいなことを実はやっていて。最初は「うまく出来たなー」と思ってたんですけど、実際にクライアントを作ってみると「そういうとこで凝ってもしょうがない」というか、JSON のデータが決まっていてそれが落ちてくるほうが楽だったりもするので、そういうとこは実践重視でやっちゃってたりもしてるんですよね。

みんな「バージョン2はいらない」とかいう風にタイトルであおってますけども、実際に今の仕事の API はバージョン3くらいになっていて。そっちのバージョンを使うアプリが先週くらいに最終的に全部 launch したって感じになってるんで。意外と時間かかりましたけど、うまく移行できたかなという感じですね、今は。

naoya: そもそも、そんなにバージョニングするくらい API 作ってる人いるのか、って話ありますよね。

miyagawa: （笑）これもね、結構ニッチな話かなあと思うんですけどね。この Podcast 面白くて、例えば Immutable Infrastructure もそうだし、この API バージョニングの話もそうだし、「こんなの聞きたい、こういうの実際に現場で使いたい人いるのかな？」とか思う回はものすごい反応が良かったりするんですよね。

だから意外と、ブログとかで紹介されない話なところがよかったのかもしれないですけどね。

naoya: たしかに昨日の Immutable Infrastructure も、そこのセッションがすごい人気で何百人も聞きに来てるけど、実際にやろうとすると Docker も全然安定してないし、それ以外の部品もいろいろ必要になって。実際のところは PaaS 使うならともかく、自分たちで Immutable な感じにしようとすると相当ゴールが遠いじゃないですか。なんだけど、何百人も聞きに来てて。「こんなに聞きに来てるけど、仕事に応用できる人ごく一部しかいないと思うんだけど」みたいな。

miyagawa: うーん。でも、Immutable Infrastructure っていうのが出てきた界隈の話から言うと Docker とかコンテナとかっていう話になっちゃうけど、そうじゃなくて AWS とかでイメージ作って Auto Scale するとか。Cookpad の成田さんの話もあったけど、いろんな考え方っていうのがあると思うんで。実際に Immutable Infrastructure やりたいけど Docker がまだ安定してないっていうのは、もちろんそういう見方もあるけど、そういう考え方を頭に置きながら今使える技術で同じことを実現するっていう感じかな。

naoya: そうそう。現実的にはそういう感じなんですけど。ああいうカンファレンスに行って僕たち喋ってると、みんながすごい大規模な Web サービス作ってて、みんなが Immutable やりたがってるみたいな感覚に間違っちゃうときがあるんですけど。実は大半の人は「サーバー10台もない Web サイトをたくさん作ってる」みたいなケースが多くて、「それだったら Heroku 使えばいいじゃん」みたいなのもあったりとかして。

でも一方でやっぱりそういうトレンドの話をすると、たくさん人が聞きに来るから。現実に使うかどうか別に、そういう大きなトレンド、技術の方向性みたいな話はやっぱりみんな聞きたがっていて、API とかもそういう感じちょっとありますよね。

miyagawa: たしかに。今 #rebuildfm でも出てるけど、自分たちで大規模運用していない、経験がない、API をこれから作りたいんだけど将来的にどういう感じに伸ばしていけばいいのか不安がある、とかいう人が結構いると思うんで。そういう、「今まで経験してないところを見ておきたい、聞いておきたい」っていうところはあるんだろうね。

9:12

naoya: そうですね。API に関しては、miyagawa さんのさっきの話はモバイルの話だと思うんだけど、モバイルアプリが主流になってきてみんな API を作るようになってきた、っていうのもありますよね。昔は API っていうと Web API 公開するみたいな「ほんとに好きだからやってる」みたいなのが多かったけど、最近は普通に、アプリケーション設計的に API で、っていうのが前提になってることも多いから。

miyagawa: 確かに。サードパーティに公開したい API っていうのと、自社のモバイルクライント向けの API っていうのとね。先週この話したんで、興味ある人、まだ聞いてない人はエピソード35が聞けます。あと transcript ももう出てるんで、時間がないという人はそれを読むのもいいかもしれません。

9:58

miyagawa: さっき Docker の話出ましたけど、新しい 0.9 ってのが出てましたね。

naoya: 先々週くらいに出てましたね。

miyagawa: 読んでてちょっと面白かったのが、今まで Docker って「LXC のラッパーだ」って言う人が結構多かったと思うんですよ。で、この 0.9 で大きく変わったな、って思うのは、LXC は複数ある実行環境の一つっていう風になってるんですよね。LXC の他に libcontainer っていう Go のライブラリを自分たちで作って、LXC がやってることを Go のネイティブのライブラリで出来るようにした、っていう。そういう感じになってて面白いかなぁ、と。

naoya: libcontainer はブリッジみたいになってて、仮に他の OS でも同じような Container の機能持ってたら、インターフェースをその libcontainer が吸収してあげて複数対応できるように、っていうのが今後のロードマップだと思うんですけど。

miyagawa: そうですね。今あるのは OpenVZ、qemu、BSD Jails とか、chroot とかも対応してるんで、Docker が LXC を使いやすくしたって意味でもすごく注目を浴びてたとこはあるんですけど、そうじゃなくてもアプリケーションの実行環境を抽象化した、そういうスタンダードを提供したってところも結構あると思うんですよ。Dockerfile とかもそうだし。そこは見方を変える意味があるかな、という気がしますね。

naoya: そうなんですよ。最新号の WEB+DB PRESS におもいっきり「Docker は LXC を使いやすくするツール」みたいなこと書いたら、その号が発売した10日後くらいにそうじゃなくなっちゃって（笑）

miyagawa: （笑）

naoya: 紙媒体の悪いところが出ちゃったというか。

miyagawa: 連載とかはそういうのありますよね。でも、LXC を使いやすくしたというだけでも素晴らしいとは思うんですけどね。

naoya: でも、LXC のフロントエンド、みたいなこと言い切っちゃったんでちょっとまずかったかな、と。この話って Vagrant のときと似てて、Vagrant は最初のバージョン1.0 くらいのときまでは VirtualBox しか対応してなかったんで、VirtualBox のフロントエンドツール、VirtualBox をプログラマブルに Ruby で扱えるようにするツール、みたいな感じでみんな言ってたんだけど、「VirtualBox、VirtualBox」ってばっかり言ってたら、1.1 で cloud-provider みたいな機能が追加されて、裏側で AWS とか DigitalOcean みたいな好きなクラウドサービスや実装に切り替えられるようになった、みたいな流れがあったんで。

miyagawa: そうですよね。実際、Mitchell Hashimoto 氏はあんまり VirtualBox 好きじゃないみたいで。VMWare の方が安定してるぞ、って最近 Twitter とかでよく書いてますよ。VirtualBox はいろいろバグが多いからムカつく、みたいなことを書いてますよ。

naoya: （笑）たしかにバグというか、変なバッドノウハウみたいなのを時々使わなきゃいけなかったりするんだよね。

miyagawa: Docker の Go のやつは、こないだDocker の人に meetup で会ったときに話したら、次に 0.10 っていうのを出して、それが 1.0 への Release Candidate になるらしいですね。1.0 で Production Ready っていうことを宣言したいので、0.10 で 1.0 に向けての基本的な機能は freeze して安定性を高める、潰せるバグは全部潰して、っていう感じで、夏前には 1.0 を出すって言ってましたね。

naoya: ちょうど一年くらいですかね。6月くらいだったから、たしか。

miyagawa: そうですね。そんな感じで一年でここまで注目を集めてるのすごいと思うけどね。

13:50

miyagawa: Vagrant 1.5 ってのがこないだ出たんですけども。

naoya: 実用性っていう観点でいうと割とドラスティックな変更、新機能が入りましたね。

miyagawa: そうですね。synched folder に rsync とか SMB とかが入ってるのは、より高速に、とか、ファイルシステムの変更をもっと簡単に、ネイティブのファイルシステムを使って検知できるようにするっていうところだと思うんすけど、それ以外にも大きい変更があるんすよね。

naoya: Vagrant Share っていう 、VM で立ち上げてる Web サーバーとかをコマンド一発でインターネットの世界に公開できるっていう機能で。これ、ローカルの VirtualBox のなかの VM で Rails アプリとか作ってて、それをデザイナーに見せたいっていうときに、今までだとチョコチョコ変な bad hack みたいなのをしてなんとか見せていたのが、そのときに vagrant share ってコマンドを叩くとインターネット上の、クラウド上にある vagrantshare.com が proxy してくれて転送してくれるから、オンデマンドで public URL 振って渡すことができるって感じですね。

miyagawa: これは実際にはインスタンスはローカルで普通に動いてるんだけど、そこにリバースプロキシみたいな形でインターネットから叩けるってことですよね。

naoya: そうそう。Vagrant share 立ち上げると、ローカルの OS X の側にちっちゃいプロキシサーバーが立ち上がって、そいつが TCP コネクションをクラウドサーバー側と張りっぱなしにするんですよね。そこでコネクション確立して、あとはクラウド側で指定の URL にアクセスが来ると確立されたコネクションから逆にリクエストをこっちに送ってきてくれる、みたいなアーキテクチャになってるんですけど。

で、Vagrant のなかにポートフォワーディングの機能があるんで、「VM のなかで8080番立ち上がってるのを OS X の何番で見れるようにする」みたいな。そのポートのセットアップとかも vagrant share コマンドでやってて、コマンド一個叩くだけでインターネット - OS X - Vagrant のなか、みたいなのが全部一気にトンネリングされるんですよね。

miyagawa: これなかなか便利ですよね。実際、似たようなツールに ngrok とか localtunnel っていうのがあるんですけども、これは Vagrant に限らず任意の開発サーバー、例えば rails s とかで立ち上がる localhost の 3000番で動いてるサーバーを外から叩けるようにするっていう、そういうソフトウェアがあるんだけど、それを更に Vagrant のところにもう一段かまして、って感じですね。もし Vagrant Share がなくても出来なくはないけど、ローカルにもう一回プロキシサーバーを立てないといけないから。

naoya: そう。Vagrant のポートフォワーディングで、どこのポートでマッピングするっていうのも結構固定的に頑張らないといけないんだけど、Vagrant Share だとそこまで含めて全部やってくれるから、ワンストップで出来るっていうのが非常にいいですね。

miyagawa: いいよね。例えば、実際に開発してる途中のやつをオフィス内だったら IP アドレスがあって叩けるんだけど、そうじゃないときに、リモートにいるクライアントとかリモートで働いてて同僚に見せたいときとかにも使えるし、あとはよくあるパターンなのは Webhook とかですね。例えば GitHub から受ける Webhook とかを作りたいんだけど、プッシュするまで GitHub のサーバーから自分のテストスクリプトに到達できないんで。

naoya: あーそうそう、それすげぇあった。

miyagawa: （笑）

naoya: いちいちね、動作確認のために Heroku にあげたりとかしましたね。

miyagawa: そうそう。Webhook 作るときに僕がよくやるのは RequestBin っていうサイトがあるんですよ。requestb.in っていうサイトなんだけど。ここは一日だけ使える Webhook の エンドポイントをボコボコ作れて、そこの URL に POST とか PUT とか GET とか来ると全部ログしてくれるんですね。でそれのヘッダーとか中身を全部見れて。それを見ながらそのスクリプトをローカルにコピーしてきて、それを自分のサーバーに対して LWP (Perl) とかで投げて、「あ、動いてるな。よし。」みたいな感じで、それでプッシュするって感じだったんだけど。

こういう ngrok とか localtunnel とか VirtualBox 使って Vagrant Share とかだと、実際に動かしながらテスト出来るんで、そこは全然違いますよね。

naoya: 今まで Vagrant って、作っては壊し、作っては壊しみたいな、なかで直接開発するっていうよりは、ちょっとときどき動作確認したり Serverspec とかでインフラ構成したいときのために使うっていうのが僕は多かったんですけど。Vagrant 自身に開発のユーティリティみたいなのがどんどん追加されてくと、Vagrant VM のなかで普通に開発するっていうのももしかしたらありかな、って思うようになってきてますね。

miyagawa: 確かにね。

naoya: なんだかんだで Rails アプリとか OS X のうえで動かしちゃうんですよね。VM 作ったりするのめんどくさいから。こうやって便利になっていってるのを考えると、もしかしたら VM のなかで隔離されてる方が楽になっていくかもなぁ、と。

miyagawa: 実際ね、VM 使えば Linux とかの OS のバージョンをプロダクションと揃えるとかっていうメリットもありますしね。

naoya: そう。そうするとね、Boxen とか頑張ってローカルやらなくても、VM で Chef とかでやればいいじゃん、っていう考えになっていく。

19:39

miyagawa: 確かに。あと、Vagrant の1.5に戻ると、Boxes 2.0 っていうのがあって。ちょっとまだ試してないんですけど、説明を読むと、「作った VM、box を共有したり出来る」ってことなのかな。

naoya: そうそう。クラウド側に送り込んで、他の人がそれを Docker みたいに ID を指定するとダウンロード出来るとか、多分そういう感じだと思うんすけどね。

miyagawa: 今、まさに Docker の Registry みたいな感じだなぁ、と思ったんだけど。

naoya: 多分ほとんどそれとおんなじような機能ですね。

miyagawa: 会社の組織とかで Organization 作って、そこのベースイメージとかを作って社員で共有したりとか、クライアントと共有したりとか。そういう感じなのかな。

naoya: 多分それを狙ってるんじゃないかと。結構ね、Vagrant とか Packer とかそうだけど、割と Hashimoto さんが Visionary っていうか、Immutable Infrastructure とかの動向を見てどんどんそれに必要な機能を追加していて。さっきの Box を共有する機能も今は Docker Registry 程度の感じがするけど、将来的にはそれこそ Docker とくっついて云々、みたいな、そういうロードマップもありそうだなぁ、っていう風に見てました。

miyagawa: 多分、すでに出来るのかもしれないけど、Box の名前を指定して、例えば hashicorp/なんちゃら っていうイメージを持ってきて、それを DigitalOcean にデプロイするとかって普通に出来るんですよね、多分ね。だから、DigitalOcean とか Amazon とかみたいに、サービスプロバイダーが提供してるイメージ一覧とか自分で作ってアップロードしてるイメージとかもちろんあるんだけど、そこに更に Vagrant で作られたやつは何でもアップロードできる、とかだったらかなり強力だよね。

naoya: なんか、ほんとはただの VirtualBox を簡単に使える道具だったんですけど、1.0のときは。1.5まで来たらそういうデプロイとか、リモート環境をローカル環境を揃えるためとか、そういう感じに使えるようになってきてるんで、なかなか面白い道具というか。作ってる人がすげぇなと思いますね。

miyagawa: かなりの Visionary だよね。Immutable 界隈。

naoya: Immutable 界隈（笑）

miyagawa: （笑）

22:06

miyagawa: じゃあ、ここでスポンサーを紹介します。先週もスポンサーついてもらいましたけど。今週のスポンサーは idobata というチャットサービスですね。永和システムマネジメントさんが作ってるチャットサービスなんですけども。チャットのサービス、ソフトウェアとか色々あると思うんですが、Web とかソフトウェアの開発者が使うチャットサービスに特化したところが特徴でして。

idobata では、GitHub、Travis-CI、Heroku とかのよく使う開発サービスとの連携、Hook 的なものとかですね。そういうのを簡単にセットアップできます。僕もやってみたんですけど、Heroku とか GitHub のアカウントを oAuth で関連付けて、ボタン一つ押すとリポジトリにプッシュされたコミットとかを全部チャットルームに通知されてきたりとか、Heroku の Deploy Hook とかも用意されてるんで、git push heroku で新しいバージョンがデプロイされるとそれが通知されたりとか。あとは New Relic とか Travis-CI みたいなツールも対応してるみたいです。

あと、最近ですね、実験的な機能なんですけども、hubot っていうチャットスクリプトがあって。GitHub が開発してるやつなんですが。この bot も idobata のチャットルームのうえで動かせるようになったということで、色んなチャットでメッセージを送ったりとか、あるいはイントラネットで hubot のインスタンスを動かすと、イントラネットのサーバーからしか見れないような情報とかもチャットルーム上で見ることが出来たりとか。実際にデプロイ自体を hubot からやるとか、そういう使い方も多分出来ると思いますし。色んな使い方が出来ると思います。

iOS アプリも出てるので、これを使うと @ でメンションしたときに iPhone アプリでプッシュ通知を受け取ることも出来ます。今はベータ版が終わって正式バージョンとして出てるんですけども、今のところ当面の間無料で使うことが出来るということです。試して頂いて、感想を idobata のスタッフの皆さんがぜひとも聞きたいということなので、サービス内の方にフィードバックのフォームもありますし、Twitter のハッシュタグ #idobataio でフィードバックやメッセージを送っていただけると良いかと思います。

3月27日の木曜日の夜に恵比寿にある Engine Yard さんのオフィスで idobata 会議という meetup を開催するらしいです。詳細は blog.idobata.io の方か Twitter のハッシュタグ #idobataio で検索すると出てくると思いますので、興味ある人はそちらの方も参加してみてはどうでしょうか。

これも関連してるんですけど、Twitter で4月15日までの間にハッシュタグで #idobataio とツイートしてもらった人のなかから、抽選で3名様に idobata の5月1日時点での master にある Gemfile をプレゼントします。よくわかんないプレゼントなんですけども、idobata.io で使ってる Gem の一覧が見れてちょっと嬉しいっていうことらしいんで、使ってみての感想とかフィードバックとかあればこのハッシュタグ #idobataio というところに送ってみてください。

サイトのほうは idobata.io からサインアップできます。Show Notes とか、RSS の方からもリンク張っときますんでチェックしてみてください。スポンサーどうもありがとうございました。

25:33

naoya: チャット、結構重要じゃないですか。僕らの開発において。

miyagawa: そうですね。

naoya: なんだけど、色んな会社とか行ってると、案外チャット使わないで開発とかしてる会社がまだまだ多くて。ただチャットっていうだけだと「別にそれコミュニケーションの手段だから他でもいいんでしょ」って感じがあるんだけど、ロボットがすごい重要っすね。

miyagawa: そう、bot がね。あとは通知とかがちゃんと連携するってのがすごく大事だと思いますよね。

naoya: 例えばデプロイとかも、普通にチャットとかなしでやってると、特に Capistrano とかでやってると誰がいつデプロイしてるとかって実は全然わからなくて。オフィスにいると「デプロイしまーす」「お願いしまーす」とかって出来るんだけど、リモートだと他の人がデプロイしてて「あ、今デプロイしてんだ」みたいなステータスをいちいち聞かないとわかんないとか、ね。

miyagawa: そうなんすよね。idobata さんは Hook できるのが一覧として GitHub とか Travis とか Heroku とかは最初からそういうのが用意されてるんですけども、一応ジェネリックっていう Hook のエンドポイントも用意されていて、自分で API KEY を発行すれば、例えば Capistrano でデプロイしててもそのデプロイ結果を idobata のチャンネルの方に流すっていうのもちょっとしたプラグインのインストールをすればできるようになってるんで、なかなか良く出来てるなっていう印象ですね。

naoya: なんか、コマンドの結果をチャットで受け取るってのもあるんだけど、そもそもチャット上でロボットに命令出すとそのロボットがコマンドを肩代わりしてる、みたいなことがあって、最初は「なんでわざわざロボットにコマンド発行しなきゃいけないの？そんなのローカルでやればいいじゃん」って思ってたんだけど、誰かがそのコマンドを打っていて、その出力が本人もあんまり気にせずに実はチャット上で共有されてるってのがむちゃくちゃ大事なんだよな、って。

miyagawa: そうなんですよね。そういう記事をブログで読んで、URL 忘れちゃったけど、やっぱり新入社員とかもそうだし、そういうログとかを見たときにコンテキストってのがすごく伝わるのが結構大事で。例えば、サーバーの台数は何台で、load average がいくつ、とかいうのは、そういうコマンドをサーバーに入って自分で実行すれば分かるんだけど、わざわざ hubot にコマンド発行して load average がばーっと出るとみんながそれを見るわけですよ。そこで共有されていて、かつログも残るっていうとこがすごく大事だな、って気がしますね。

naoya: そうそう。ほんとにそうなんですよね。だから、Skype とかでもチャット出来るし、HipChat とかも機能けっこう似てるんだけど、ロボットとか開発しやすいとか他のサービスから API で通知受け取りやすいみたいなのが実は開発の文脈ではかなり大事で。なるべくそういうプログラマブルに扱えるサービスを使ったほうがあとあと便利だな、って思いますね。

miyagawa: そうですね。まだまだ始まったばかりのサービスだと思うんで、興味ある人は使ってみてフィードバックを #idobataio で送ってもらえるといいと思います。

28:44

次。あと2つくらいネタ行きたいんですけど。GitHub の Atom エディタって、前も紹介しましたけど、試しました？

naoya: 少し試して、例によって Emacs の引力に引き戻されて。

miyagawa: （笑）

naoya: 地球の重力に（笑）

miyagawa: 僕はね、今週からもうちょっともう一回試してみようかな、と思ってちょっとやってるんですけど。

naoya: お、ついに Emacs を捨てる？

miyagawa: いや、そういうわけじゃないんですけどね。でも、けっこう良く出来てて、一番よかったのは Markdown のプレビュー機能とか、あとたまに最近 Golang を書くんですけど、Go のフォーマットとかをセーブするときに勝手に hook するっていうのが。もちろんそれ Emacs でも出来るけど（笑）

naoya: （笑）そういうの言い出すと、「全部 Emacs でも出来るし」ってなっちゃう。

miyagawa: なっちゃうんだけど、でもやっぱりね、モダンなんですよそこが。パッケージのインストールとかも apm、Atom Package Manager っていう、これ npm のラッパーだと思うんだけど、それでインストール出来るし。なんかね、Emacs みたいなめんどくさい .el をコピーしてきて .emacs ファイルに設定書いて、とか、そういうのないんですよね（笑）

naoya: そう。Emacs も一応パッケージ管理ツールが24からついたんだけど。あれなんですよね、インストールだけやってくれるんだけど、その後のパッケージのバージョン管理とか全然してくれないから。なんかね、全然ダメなんですよ（笑）

miyagawa: （笑）

naoya: 全部使うようにしてるんだけど、bundler とか brew みたいなものだっていう風に期待して使うと結構肩透かし食らうみたいな感じで。しかもそれを自分でちょっと拡張しようと思うとまた elisp が出てきて、とか「いやだなぁ」とか。

miyagawa: （笑）ほんとそうなんだよね。一応今、Rebuild のサイトは Jekyll で書いてるんですけど、そこの編集とかを Atom を使ってやってみて。実際、Markdown のプレビューが出来るってだけでも Emacs には出来ないことなので、そこだけでも価値があるかな、っていう感じはしていて。

あとね、Go のツールか Perl のツールだったか忘れたんですけど、インストールしてうまく動かなかったんですよ。で、そのときに、設定画面のプラグイン一覧から Open in Atom っていうのを押すと、そのプラグインのソースコードが読めるんですよね。で、プラグインのソースコードは普通の CoffeeScript で書いてあるので読めるわけですよ。

naoya: （笑）

miyagawa: 読めて直せるんですよね。いじってセーブしてリロードすると、普通に console.log とかでログが出せるわけね。そういうの Emacs でやるの相当つらいというか。

naoya: elisp 覚えるのちょーつらい。

miyagawa: （笑）そうそう。だから、そういう意味ではアクセシビリティが高いかな、と。

naoya: それはね、僕は長期的に見るとそういうとこが一番大事だと思ってて。エコシステムに参加する人数がどれだけいるかで決まるじゃないですか、こういうのって。やっぱみんながよく知ってる言語が中枢になってるってのはやっぱいいなぁ、と思ってて。Sublime で Python なんでしたっけ？

miyagawa: そう、Python だね。

naoya: Python はやっぱり Python 好きな人とか仕事でやる人しか触らないけど、JS とか CoffeeScript だとね、Web アプリケーションエンジニアだったらほぼ100％全員触るから。

miyagawa: そうそう。

naoya: 自分の知ってる言語だからって「ほいっ」って触れるみたいなの、結構あるじゃないですか。

miyagawa: そうなんだよね。あとね、Sublime はね、Python のバージョンが 2.x だったり 3.x だったりってのがちょっとあるし、API が基本的に全部 Undocumented らしいんですよ。

naoya: （笑）

miyagawa: （笑）だから、プラグインとか書いててよくわかんないの質問しても全然答えてくれない。で、ソースコード公開されてないから手探りでやるしかなくて、そこがつらいって言ってましたね。

naoya: そういう感じなんですね。

miyagawa: GitHub もそういう意味では、Atom の本体のソースコードは今は公開されてないから。そこはちょっと不安点ではあるけども、こないだ話したみたいに、これからソースを公開する予定もあるみたいなんでね。そこはもうちょっと期待できるんじゃないかな、と思うんですけど。

naoya: Node-webkit 使ってるんですよね。

miyagawa: そうそう、Chromium の V8 をベースにして Node とかでやってるみたいですね。最初、先々週かな、話したときには「ちょっとパフォーマンスとかどうなのかな」とは思ったんですけど、確かに若干もっさり感はあるんですよね。けどまあ、問題ない範囲かな、っていう気もしないでもない。

naoya: 一年二年経てばね、コンピューターの性能上がっていくし。

miyagawa: そうなんだよね。Emacs をね、ターミナル経由でやるのと比べると軽量さ加減には負けるかもしんないけど（笑）

naoya: （笑）まあ Emacs 重いからね。

miyagawa: そうそう、重いから。そういう意味ではあんまり問題ないかな、って気はするんですけど。

naoya: いやーなんかね、僕も Emacs 捨てたいというか、やめれるならやめたいんだけど。

miyagawa: naan もこないだ言ってたけど、かなり何年かかけてリハビリしないとダメだよってことを言ってたね。

naoya: なんか、僕が Emacs に後ろ向きな発言をすると、熱心な Emacs ユーザーから「naoya さんがそんなこと言っちゃダメだ」とか言ってくる（笑）

miyagawa: （笑）

naoya: 時々そういうお叱りを受けて。いや、実際にはすごい便利に使ってるし欠かせないツールなんで、オススメはするんだけど。

miyagawa: そうね。

naoya: ただ、elisp 書かないと拡張できないとか「ぐぬぬ」ってなっちゃう。

miyagawa: さっき、JS とか CoffeeScript とかの話しましたけど、GitHub の Atom がCoffeeScript で書かれるのはどうなんだ！？っていう。これ結構面白い話で、確かに素の JavaScript で書けばいいじゃん派と、GitHub が決めたことなんだから CoffeeScript でいいんだ派っていうのがあってですね。CoffeeScript ってどう思いますか？

34:43

naoya: 僕はそんなに良いも悪いもなくて。ていうか、僕あんまりプログラミング言語の美しさとかにそんなに関心が高くない感じなんですよね、自分自身が。だから、CoffeeScript のこういうところがイケてない、とか、いろんな指摘があるんだけど僕はあんまりピンと来なくて。なんか JavaScript 直接書くより読みやすいし、JS のバッドノウハウみたいなところも隠してくれるからいいじゃん、くらいに軽く思ってないんですよね。

miyagawa: なるほどね。まあそれが一般的、大部分のソフトウェアエンジニアだとは思うんですけどね。JavaScript が好きな人とかは、CoffeeScript で JavaScript を吐くっていうのがあまり好きじゃないって人もいるし。あとは CoffeeScript って書くのは簡単なんだけど、ちょっと後で読んだときに読みづらくなるコードを書きやすいかな、っていう気はするんですよ。インデントとかで表現するって意味だと Python と同じなんだけど。コードを見たときにパッと構成がわかりづらいこともあるかな、っていう。

それ、Perl と同じなんですけど。要は、Perl でもきれいなコード書けるけど、Perl ってすごく短く書けるじゃないですか。CoffeeScript も JavaScript と比べるとすごくいろんなものを短く書けていったりとか、矢印を多用するとコールバックとかがすっきり書けたりするんだけど。何ヶ月か経ってみると、「これ何してんだ？」ってなったりすることも結構あるかなって気はするんだけど。

naoya: 逆にあれですよ、CoffeeScript の短く書けるところ、DSL 的に使える側面みたいなのもあるじゃないですか。シンタックスが余計な記号がないから。Grunt の設定ファイルとかは絶対 CoffeeScript で書いた方が読みやすいというか、設定ファイルっぽくなるんで。CoffeeScript じゃないと厳しい、そこまでいかないかもしれないけど、絶対そっちの方がいいってケースは確かにあるんですよ。

なんで、Grunt の設定ファイルとかは CoffeeScript で書くことに異論を唱える人はほとんどいないんだけど、アプリケーションロジックをちゃんと書きましょうっていうとこでこれ使うのどうか、っていうのは、嫌いな人は「嫌い」ってハッキリ言ってる感じがしますね。

miyagawa: 確かに。そういう意味だと、GitHub の Atom はプラグインとか設定ファイルを CSON っていう JSON の CoffeeScript 版みたいなのを使うのはすごく理にかなってるんだけど、だからと言って CoffeeScript が JavaScript より優れてるとか、そういう話には一概にならないってことだよね。

naoya: だから、AltJS の一番人気で使われてるものなんだけど、そういうのを見てると CoffeeScript は AltJS にしなきゃいけないほどカバーしてないっていうところが結構一方であるらしくて。例えば他だと型システムを JS に導入するための AltJS とか、コンパイルがすごく速くなるやつとか色々あるじゃないですか、Dart とか TypeScript とか。

そういう明らかに AltJS じゃないと出来ない部分っていうのが乗ってるから、結構そっちを使うメリットがあるって言ってる人は多いんだけど、CoffeeScript はただシンタックスを書きやすくするというか、シンタックスシュガーでしかない感じなんで。唯一あるとしたらクラスシステムだけど、ただクラスはね、Pure JS 書いてる人ほど「いや、そんなのいらないでしょ」って感じあると思うし。ちょっとポジション的に中途半端ってのがあって。ま、逆にあんまりやらないからこそこんなに広まってった、てとこもあると思うんだけど。そこで必ず議論になりますよね。

miyagawa: そうだね。このスレッドも、JavaScript とか ECMAScript 6 を使えばいいじゃん派と、GitHub が決めたことだしそれで参入障壁が上がるんであればそれはそれで CoffeeScript とかの良さをわかってる人だけが Contribute するからいいことだって人と、二つに分かれてて面白いですけどね。

naoya: 実際、あそこでギャーギャー言ってる人たちは Atom で書いてなくて、外野でギャーギャー言ってるだけじゃないか、みたいな指摘もあったからね。

39:05

miyagawa: （笑）そういう気もする。

じゃあ、次。

naoya: 多分、今日のメイントピック。

miyagawa: （笑）メインなのかわかんないですけど。Rebuild で話すためにネタを投下してるんじゃないか、っていう気がしないでもないんですけど。

naoya: いや、そんなことは。

miyagawa: コードレビュー的な話ですかね。

naoya: JavaScript の minify ね。

miyagawa: 一応その発端は、naoya さんのブログ記事が発端ではないと思うんだけど。

naoya: いや、違うんだけど。僕がちょっと燃料投下気味に書いたらプチ炎上してしまいました。

miyagawa: 一つここの話はタイトルがさ、「瑣末なコードレビュー」ってなってるけど、前半はあんまりコードレビュー関係ない話ですよね。

naoya: これ、ちょっと僕のなかでコンテキストがいっぱい混ざっちゃってて。ちょっとそれは良くなかったなって思ってるんですけど。大きい話としては、コードレビューのときもそうだし、JS を minify すべきかしないべきかとかいうのもあるんだけど、文脈っていうのがやっぱ背景にあって。例えば、システム全体のアーキテクチャを論じなきゃいけないときに、JS の minify がなってないとか、そういう話ってすごい相対感としてはちっちゃいじゃないですか。

で、コードレビューのときもやっぱりそういうことがよく起こりやすくて。木を見て森を見ず、みたいな状態になりがちなんすよね、こういう話って。そうなっちゃいけないよ、って話を書いたつもりだったんだけど。

miyagawa: （笑）

naoya: 二つ混ぜたせいで「ユーザーはコードレビュアーじゃねえぞ！」とか言われてて、「いや、そんなことは言ってないんだけど」って感じになってて（笑）

miyagawa: （笑）そうね。コードレビューの話はもうちょっとするとして、前半の話で僕も読んでてすごい違和感があったのは、JavaScript が重いと言って JavaScript を見てみたら何万行ある JavaScript で、コメントがそのまま残ってる、と。だから品質が低いんじゃないか、とか、難読化されてないとか、難読化って言葉は良くないですけどね。minify するのがプロなら当たり前だろ、とか。すごく好き勝手言ってるっていうところがあって。

naoya: そうっすね。

miyagawa: それは全然関係ないよな、とは思うんですよ。で、むしろ思ったのは、最初これ確かブログ二個くらいあったんですけど、もし minify してたらその人は /js を見て「こんな汚いコード書いてるんだからダメに違いない」って思うのかな、って思ったんすよ。

naoya: （笑）

miyagawa: 「なんだこれ、はてなの JavaScript 改行してないし変数名全部一文字だし」とか（笑）

naoya: （笑）それはひどい。

41:44

miyagawa: そういうリアクションになったんじゃないかな、っていう。どっちでも結局同じような反応なんじゃないかな、と思ったんですけど。ま、それはいいとして、コードレビューの話なんですけどね。Cookpad もね、二週間くらい前にスタイルガイドラインっていうドキュメントを GitHub に公開していて、Ruby のコード書くとき、Java のコード書くとき、JavaScript のコード書くときはこういうスタイルで書きましょう、っていうドキュメントですね。

GitHub でも同じようなドキュメント公開してるんですけど、そういうのを公開することによって、人の趣味に寄って「ここのインデントが2つなのはおかしい」とか、「ここは4つの方が僕は個人的に好きです」とか、そういう無駄なツッコミを避けるっていう意味でもそういうガイドラインを作るっていうのが一つあったんですよね。

naoya: インターネットに公開するのはやっぱりすごくいいな、と思ってて。社内文書でコーディング規約とかよく出るんだけど、社内に公開されてるだけだと結構それを軽んじる人とかがちょっと出てきちゃうんですよ。「社内のどっかに置かれてる規約でさ」とか言って、守られてるかどうかも分かんないじゃん、みたいな感じになってくるんだけど、やっぱりネットに公開されてるとパブリックな人たちが沢山見てて、「Cookpad ってインデント2なんでしょ？」みたいな。そんなツッコミしてくる人はいないんだけど、そういうのをちゃんとオーサライズされた情報なんだ、箔付けが出来るから。

miyagawa: 確かにね。

naoya: コーディング規約作ったらデベロッパーブログとかに出せるなら出したほうがいいかな、みたいなのはありますね。

miyagawa: コーディングガイドラインはある方がいいんですけど、一番理想的にはそれをコードで解決出来る方がよくて。Perl だったら Perl::Critic とか、Ruby にも同じようなツールがあるんですけど。

naoya: Rubocop。

miyagawa: うんうん。そういうのである程度自動化出来たほうがいいなと思っていて。コーディングガイドラインがあることによって良くないのは、「ガイドラインに沿ってませんよ」ってツッコミをしたくなっちゃうんですよ。

naoya: そうそう。それがね、不毛なんすよね（笑）

miyagawa: （笑）で、それは新入社員の人とか、OJT 中の人とかに対してやるのは全然 OK なんですけど、そうじゃないときに大きいコード、デザイン的にレビューして欲しいのに「ここのスペース間違ってます」とか来ると非常に腹立たしくなってしまって。

naoya: めっちゃ萎えるっすよね（笑）その話と、JavaScript のコードをペロッと開いてみたら minify されてない、みたいな話が僕の中ではすごいかぶってて、背景として。要は JS のコードをペロッと開いて、例えば「これだとこういう書き方したらあそこのパフォーマンスが遅い」とか、「こういう抽象化だと全然ダメじゃん」っていう指摘だったら、「お、すいません」って感じなんだけど。「いや、minify すべきでしょ」みたいなのが来ると「最初そこじゃないでしょ」みたいになる。

miyagawa: （笑）

naoya: ていうのがあって混ぜちゃった、というのが背景にあって。ちょっとコードレビューの話に戻すと、プルリクとか出してレビューついた！、と思ったら、「インデントがおかしいです」とか、「ハードタブじゃないとダメです」とか言って。めんどくさー、みたいなね。

miyagawa: どうしてもそういうの指摘したいときがあるってのはわかるんですけど。そういうときのために最近はね、うちは square blacket に nits っていう、nit-picking って言うんですけど。重箱の隅つつきですよ、っていうのを自分で明示した上で [nits] って書いたりとか。あと、最近流行ってるのが、雑談っていうタグを貼って、「このプルリクエストにまったく関係ないけど、ここでこういうことすると他でこういうことになったことが昔あります」みたいな。

もしそういうのを雑談タグなしで書くと、「ほんとにそうなのかな？」っていう風に受け取る方が身構えちゃうから、いちいち「ほんとにそうかもしれないな」と思って調べちゃうんですけど、「これ雑談ですよ。そういうこともあるってことを頭の隅に入れといてね」みたいなイメージとかが出来るんで。

naoya: スルーしてもいいよ、ってことですよね。

miyagawa: そうそう。

naoya: レビュイーが真剣にそれを考えて「これ対応しなきゃいけないのかな」みたいなことを考えさせないで済むようになるっていう。そういうのすごい大事っすよね、コードレビューではね。MUST とか SHOULD とか、これは別にスルーでいい、とか、そういう情報なしに単にテキストだけで「これはこうしたほうがいいっしょ」とか言うと、軽く言ったつもりがみんなが一生懸命それに頑張ってる、みたいなことが起こっちゃう。

46:09

miyagawa: あとは実際にね、こないだも言いましたけど画像を使うとかね。そういう雰囲気的なところを伝えるってのもあるし。一個盛り上がってたのは、プルリクエストを出すタイミングっていうのも盛り上がっていて。要は、開発が終わった段階でプルリクエストが来て、「これ全然ダメだな」と思ったとするじゃないですか。そのときに、「これ全然ダメなんでやり直してください」っていうのは、オープンソースでは全然 OK なんだけど、会社でそういう風になってしまうのはよくないよね、っていうのがいくつか上がっていて。そういうときにはどういう風にすれば避けることが出来るのか、みたいな話もちょっと盛り上がってたんですよね。

naoya: それはあれですか、いわゆる WIP、Work In Progress？

miyagawa: Work In Progress のプルリクを作って、そこで議論をして、そこにチェックボックス、GitHub のプルリクエストの Markdown のところに square blacket でリストを作っておくとチェックボックスになるので、そこを進捗状況と合わせてどんどんプッシュしていって、それごとにレビューをしてもらう、っていうパターンですよね。

naoya: うん。僕も最近は全部それでやってて。コード一行も書かないでも、要件がある程度固まってるんだったらすぐプルリクを飛ばしちゃってそこから始める、みたいな感じで。もうプルリクエスト最初、みたいな感じになってきてますね。

miyagawa: でも、最初にコードがないとプルリクエストできないよね？

naoya: ドキュメントとかにちょろっと何か書いてそれをプッシュしちゃう、みたいな感じっすね。

miyagawa: それか --allow-empty で空コミットを作ってから。

naoya: そう、そういう感じでやってますね。

miyagawa: 昔はね、GitHub って issue をまず作って、issue で議論した上でそこをプルリクエストに変えるっていう機能が今も多分あるんですけど。

naoya: 廃止するらしいっすよ。

miyagawa: GitHub はあんまそれ良くないと思ってるらしくて、廃止される方向らしいんですよ。

naoya: なんで良くないんだろ。

miyagawa: いくつか理由があるんだけど、多分ほとんどは技術的な理由で。一つは issue をプルリクエストにしてマージされると、もしそのプルリクエストが不適切であった場合に元の issue (問題)は残り続けるわけじゃないですか。で、そのまずかったプルリクエストを revert するんだけど、issue はプルリクエストに一回変わると reopen できないんですよ。だから、もう一回 issue を開かなきゃいけない。そうするとログが二個に散らばっちゃう。

それが多分理由の一個で、もう一つはオープンソース的な考え方でいくと、issue っていうのは問題を解決するかどうか、仕様なんですよね。プルリクエストっていうのはそれを実現するコードだから、それと issue と PR っていうのは別々に議論されるべきだ、っていう考え方があって、例えばここのエディタでこういう操作をするとクラッシュする、っていう issue があって、それに対する fix は何通りか考えられるわけですよね。

この人はここを直すのがいい、この人はここを直すのがいい、っていうのがあって、それをプルリクを二個送って、マージする人がどっちがいいかを選んでマージするっていう感じで。で、もう一つのプルリクエストはリジェクトする。なので、そういう考え方でいくと issue を勝手にプルリクエストで乗っ取るのはよくないっていう、そういうことじゃないかと思うんですけどね。

naoya: そういうことか、なるほど。

それで、Work In Progress のプルリクを飛ばしてって話だけど、これやっぱり良いのは、単純にコードレビューを途中で挟めるってだけじゃなくて、同僚の進捗とかをいちいち「今どうなってる？」って聞かなくても、みんながそのフローでやってるとコミットのタイムライン見てるだけで他の人がどのくらい開発が進んでるかってのが全部見えるようになるんですよね。今までだとやっぱり「進捗どうですか？」「進捗ダメです」とか（笑）

miyagawa: （笑）

naoya: そういうのを聞いて、「君の実装そのあとコンフリクトしそうだからさ、ちょっと事前に見せてよ」みたいなことをやってたんだけど、そういうコミュニケーション取らなくても非同期で「あいつのはここまで行ってるんだったらこの辺でこっちをマージしといた方があとあと楽そう」とか、そういう判断が出来るようになるのはすごくいいんですよね。

miyagawa: あとね、さっき言ってたみたいにチェックボックスでリストを作っておくと、例えば10個リストを作っておいて、そのうちの4つがチェックされてるっていう状態になると、プルリクエスト一覧のところで「今40% Done」っていうのが見れるんですよね。だから、一覧のところで「これはもうすぐ complete しそうだな」とか、進捗管理とまでは言わないけど、ビジュアル的に見れるっていうのもあるし。

あと、こないだなんかで見たんだけど、Circle CI とかみたいなツール使うと、プルリクエストで動いてるコードを実際に Continuous Integration するだけじゃなくて、デプロイして試せる環境を作る、みたいなのもあるじゃないですか。

50:57

naoya: そうそう。

miyagawa: 確か Circle CI で Heroku でデプロイするのかな。

naoya: Circle CI は CI が完了したときにデプロイっていうアクションがあって、そこのなかちょろちょろっと書いてやると、Heroku とか自分たちのサーバーに「CI でテストが通ったらデプロイアクションを実行する」みたいなのが出来るんで、そういうのを多分使うんだと思う。

miyagawa: それいいですよね。UI のチェックだったらそれで実際に動いてるの見るのが一番いいし。

naoya: そうそう。それで昨日 Immutable Infrastructure のところで、Quipper っていう会社あるじゃないですか。あそこの会社が Heroku でプルリク一本だったか Feature Branch 一本なのか忘れたけど、git push するたびにアプリケーション立ち上げちゃって、URL 一本貼るから、それをデザイナーと交換するだけで楽でみんなハッピーだ、みたいな話をしてて。結局それってコンテナベースでオンデマンドでそういうの作れて、とか、そういう環境があるからできることじゃないですか。

miyagawa: そうね。

naoya: だからそれとの絡みで話したんですけど、やっぱそこの話はすごい引きが。みんな「あー、そういうことできるんだ」って言ってて。

miyagawa: やっぱテストとかステージング環境作るのとかにコンテナはすごく向いてる技術かな、と思いますよね。うちの会社でも同じようなことやってるんすけど、実際にステージングのサーバーにタグつけてデプロイすると、タグ名.staging みたいなところでアクセスできるんだけど、ちょっと重厚なんですよね。実際のデプロイするのとまったく同じなんで。

naoya: そうそう。

miyagawa: だから、そこをコンテナとかを使うとすごく軽量にできそうだし、いいですよね。

naoya: ほんとにね、ブランチごとにアプリが立ち上がるみたいなの、ものすごい良くて。やりたいんだけどなかなかね、やっぱ Heroku とか使ってないとね。結局いまだと開発機とかが一人一台とか持ってて、そこに開発者が自分でデプロイしてデザイナーに見てもらう、とか、さっきの Vagrant Share みたいなの使うみたいな感じで。それだとどうしてもトリガーが開発者の側にあるから、デザイナーの人とかがいちいちお願いしなきゃいけないんですよ。「仕様確認したいんで今作ってるやつ上げてください」「わかりました」とか言って。そういうコミュニケーションも相手のやってること中断させちゃうから、なるべく減らしたくて。そういうのも git push してプルリクエストがあれば必ずそこに URL があるからそこ見りゃ確認できる、みたいなね。そうするとみんな非同期で開発できるんで。そういうことやりたいんすよね。

miyagawa: それこそあれですよ、idobata に hubot 置いて「このブランチを Heroku にデプロイ」とかやったら見れるようになる。

naoya: 確かにね。

miyagawa: そういうのよさそう。ていうか、GitHub は hubot 使ってそういうのやってると思う。

naoya: そうそう。

miyagawa: ブランチがあるとそれが全部 GitHub にあって。あと多分 GitHub の場合は本番にもデプロイしてるんじゃないかな。本番のステージングの何インスタンスかにデプロイしてて、スタッフのアカウントはその機能有効にしてテストできるとか、そういう感じらしいですよ。

naoya: まあ何にしても、途中のものとかをいかに可視化するかっていうのが、プルリクとかの重要なポイントだなと思っていて。そうしないとね、やっぱり「終わった」となって「いや、これ要求仕様違うんで開発やり直してください」となる。

miyagawa: 確かに（笑）

naoya: デスマーチって感じになっちゃう。

miyagawa: そうなんだよね。プルリクエストがあるとはいえ、そこはうまくツールを使ってね、WIP とかで可視化するって結構大事かなと思いますね。

naoya: そうっすね。

54:22

miyagawa: ちょうどいいすかね、時間的に。

naoya: コードレビューに関してなんかいろいろ言いたいことがあったんだけど。

miyagawa: なんかちょっと足りない気がしないでもない（笑）

naoya: また次回、いや次回だと温度下がっちゃって「もういいや」って言いそう。

miyagawa: そうですね。

naoya: そうそう、僕なんでそんなに「コメントが！」ってことに対して「う～ん」って思ったのかっていうのは、あそこに書かなかったんだけど過去の経験がいろいろあってですね、僕が思った一つは Perl がやっぱあるんですよ。

miyagawa: ほう。

naoya: Perl を僕らはずっと今でも使いますけど、Perl 書いてると絶対しょうもないこと言われるじゃないですか。

miyagawa: （笑）

naoya: Perl って言語はもう古い、とか、記号が読みづらい、とか。

miyagawa: あー、そういうことね。

naoya: なんかそういうこと言われるんだけど。ずっと言われ続けてきて、でも Perl で実際に大規模な環境で使ってきたら全然そんなことどうでもいいと思っていて、そんなことより本質的なのはちゃんと Perl でスケーラブルなアプリケーションが作れるか、とか、Perl でも破綻しない設計、長期的に保守できるものが書けるか、っていうのが重要なポイントで。どんな言語も本格的に使い込んでいくと、言語が持ってるシンタックスの細かいところっていうのは、最終的にはすごく相対的にちっちゃくなりますよね。

そうなんだけど、インターネットではすぐ Perl と Ruby 比較すると Perl は記号が多いとか、なんか Ruby の方がいい、みたいなことを、たいてい最初みんな書くじゃないですか、わかんないときって。でも、あとあと「いや、そんなことはなあ」って思うんだけど、そこにいちいちツッコんでるとそんな時間無駄だから、誰もそんなことは言わないでネット上にどうでもいい評判みたいなのが広まっちゃう、みたいなね。

それで10年位ストレスを感じ続けてきてて、それがあの一件でちょっと爆発しちゃったかな、と。

miyagawa: どうなんだろな。そういう表面でしかものを見れない人が寄ってこないって意味でいい、って見方もあるかも（笑）

naoya: （笑）そうねぇ。いや、これは非常に難しい問題で、じゃあ自分がほんとにプログラミング言語初心者のときにそういう話しなかったか、というと、むちゃくちゃしてたから。

miyagawa: （笑）

naoya: それくらいしか比較できる知識がなくてね。

miyagawa: 自分の過去を振り返って反省する、みたいなね。

naoya: おじさん特有の現象かもしれない。

miyagawa: （笑）

naoya: 結構、なんで怒ってるかわからないっていうコメントが沢山ついてて。あー、そっか、若い人とかだとそんなことに腹を立てたことがないのかもしれない、と。特に最近の若い人は、若い人って言うのやなんだけど（笑）最近プログラミング言語とか最初からそれなりに洗練されたものが使えて、グチャグチャしたとこ通らずにスッと正解から入る、みたいなことが多いから。

57:08

naoya: さっき、Node-webkit の話をしてちょっと思い出したのが、最近学生の間で Node.js がすごい人気があるんですって。結構意外だなぁと思ったんだけど、この話前にしたっけな？

miyagawa: いや、してないと思いますよ。

naoya: なんでかなって聞いたら、大学の授業で最初に JavaScript 使うらしいんですよね。スタティックな言語だとコンパイラがいるし、スクリプト言語だと実行環境がいるけど、一番最初に授業で触らせるときに JS だとブラウザが一個あれば動くからそれが都合がいいって言って JS で教える大学が増えてるらしいんですよ。そうすると大学生が「自分は JavaScript は書けるから、ブラウザ上だけじゃなくてサーバーサイドやりたい」ってなって、言語を知ってるしってことで Node.js を選択するっていうね。

そうするとほら、イベントモデルとか僕らの場合はまず prefork を通ってからイベントモデルに行ってるんだけど、彼らはもういきなりイベントモデルで Socket.IO でリアルタイム、みたいな感じだから。僕らと知識を獲得する経路が全然違うから、僕らが当然だと思ってるような常識が彼らにとっては非常識だったりとか、またその逆っていうのが結構あって。それが最終的にはイノベーションに繋がってく、って話だと思うんだけど。そういうのは結構感じることは増えてきてますよね、ここ最近。

miyagawa: へぇ。そうね、僕も今仕事とかでインターンの人とかたまに来たりしてて。相対的な知識の量とかはもちろん僕らのほうが経験とかも含めてあるんだろうけど、やっぱり余計なこと知らない分発想が豊かというか。「こういうのやってみたらどうすかね」みたいな、「そんなこと考えもしなかったわ」みたいなことを言ったりとか。その辺がやっぱり、とか言い出してるとね、完全に年寄りだな、って思っちゃう（笑）

naoya: （笑）あんまりこの話するとこうなっちゃうからアレなんだけど。もっとこう大局的にね。

miyagawa: そうそう。でもやっぱり、JavaScript を学校とかでやるっていうの、知らなかったけど。

naoya: そうそう。なんかね、慶応の理工がそうだっていってましたよ。

miyagawa: ライセンスとかいらないしね。プロプラエタリな部分とかあんまりないし。

naoya: 「めっちゃみんな Node 使ってますよ」とか言ってて、なんかすごいなぁと。

miyagawa: （笑）それは面白いっすね。

59:15

naoya: あと、イベントモデルの Web アプリケーションって、僕らがサーバーサイドをやってたときって、まだそういう実装があんまりなくて、だから Perl の POE とか、これは Ruby で言うところの EventMachine みたいなやつなんだけど、そういうのを最初覚えるときに結構苦労したじゃないですか。概念がよくわかんない、みたいなところから入るから。

で、OS の実際のイベントドリブンのアーキテクチャとかそっちから調べて、徐々にプログラミングモデルに慣れていく、みたいな感じだけど、今って Node とかでいきなりそっちから入るから。ユースケースを知った上でイベントモデルの知識を深める形になってて、絶対そっちの方が早いんですよね。イベントモデルのアプリケーションってこういうものだよ、みたいなのがボコボコいっぱいあって、「あぁ、ああいうもの作るときはこういうアーキテクチャね」って順番で理解できるから。

miyagawa: そうだね。昔だと、GUI を作るデスクトップのプログラミングをするプログラマーと、サーバーサイドのプログラマーって全然断裂していて、僕ら全然クライアントサイドとかやらないで GUI とかやったことないっす、みたいな人が多かったんだけど、今だとフロントエンドの JavaScript で GUI みたいなデータバインディングとかで書く人がサーバーサイドもイベントドリブンで書くって意味だと、プログラミングのメンタルモデルが基本的に一緒なんで、そこはあんまり差がなくなってきてるからね。

naoya: うん、そうね。メンタルモデルの導入が早いっていうのが多分いいところだなぁ、と思うんだけど。

miyagawa: そうだね。あと、プログラミング言語自体にそういう機能がついてるかどうかってのも大きいし。要は Perl とか Ruby とか Python とかは非同期機能はもちろんあるけど、言ってしまえば「後付け」というか。

naoya: そう、オプショナルっすから。

miyagawa: で、OS のライブラリを使ってその上に作るっていう感じなんだけど、Go とか Node とか Scala みたいに、イベント駆動型とかがデフォルトだったりとか言語に組み込まれたりするって意味では違いますよね。

naoya: そうっすね。まあ、そんな背景があり。

miyagawa: なるほど。

naoya: ちょっと過激に書いたのが失敗だったな、と。

miyagawa: いや、いいと思いますよ。

naoya: すいませんでした（笑）

miyagawa: 何年か前の naoya さんっぽくっていいですよ（笑）

naoya: なんかねー。

miyagawa: いや、いいと思う。そういうツイートとかブログとか書くとさ、あんまり心臓に良くないというか、すごい反応を気にしてしまうんですよね。

naoya: 一日仕事にならない（笑）

miyagawa: （笑）

naoya: だから朝書いちゃダメですよ。夜書くと寝れないってのはあるけど。

miyagawa: （笑）あるある。

じゃあ、そんなところですかね。

naoya: はい。

miyagawa: 今回のエピソードの Show Notes とかはね、色々今日は話したんで、リンクとかは全部 rebuild.fm/36 で見れます。あと最近、さっきも言いましたけど、文字起こしを販売していて、rebuild.fm/transcripts に行くか、サイトの方にボタンがついてますんで、そこをクリックすると transcript を買うことができますので、興味がある人は見てみてください。

今日のスポンサーは idobata.io でした。どうもありがとうございました。あと、スポンサーに興味ある方は rebuild.fm/contact からご連絡をいただければと思います。

ではそんなところで。

naoya: はい。ではまた。

miyagawa: naoya さんでした。どうもありがとうございました。

naoya: はーい。

---

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