HDE BLOG

コードもサーバも、雲の上

Tool to help developing AWS Lambda function in Python on your local machine.

We are trying to migrate some part of our service from daemon on EC2 server to serverless function on Lambda. By doing this, we will be able to save some pennies on AWS service and save some time from server maintainence.

At first, we did some development in Javascript on Lambda. And the development went quite well with the awesome tool lambda-local developed by Ahmad Shiina san

ashiina.github.io

With this tool, we are able to develop and debug Javascript code on developer's machine without having to upload it to the cloud. With a shortened develop-deploy-test-fix cycle, we managed to develop features really fast.

We were just about to go all with Javascript when AWS enabled developing Lambda functions in Python2.7 at re:Invent 2015.

Using Python in an AWS Lambda Function | AWS Compute Blog

Since part of our stack is based on Python2 and most of our developers are more familiar with Python than Javascript. We decided to give it a try.

However, one problem is that there is no tool like lambda-local for Python right now. So we built one by ourselves and opensourced it on github.

github.com

We have also released it on PyPI

pypi.python.org

So you may try it our by installing it into a Python2.7 environment with just one command:

$ pip install python-lambda-local

Currently, it is quite feature complete except lacking enough support for the Context API. We will continue improving it.

The usage of the python-lambda-local command is quite similar with lambda-local. So there should be no hassle if you are familiar with lambda-local.

Ideas and pull requests are welcomed.

Happy hacking!

AWS re:Invent 2015行ってきました & 新サービスAmazon Snowballについて

■AWS re:Invent 2015行ってきました

f:id:miyamotokazuaki:20151022185547j:plain

 Amazon Web Serviceの巨大イベント、AWS re:Invent 2015に参加してきました。ラスベガスです。昼も夜も渋谷より騒がしい街があったことは衝撃的でした。うちの会社(HDE)は昔から渋谷にあり、私自身もかつて渋谷に住んでみたこともあって、"昼も夜も渋谷ほど騒がしい街は世界中どこにもないだろう"という確信を持っていて(あまりに落ち着かないので、さすがに自宅は半年で渋谷区じゃないところに転出したのですが)、まぁしかし、その数倍騒がしかったですね、ラスベガスは。Crazyです。

 というわけで、今日はラスベガスの若干の写真と、re:Inventの全体の雰囲気、今回Amazonから発表されたサービスの一つを紹介しつつ、最後にちょっとした宣伝(!)をさせていただく、という構成にしています。是非最後までお読みください。

 さて、まずはラスベガスらしい写真をいくつか上げておきます。

f:id:miyamotokazuaki:20151022185736j:plain
↑とりあえず肉は食っておこう、みたいな感じ

f:id:miyamotokazuaki:20151022185754j:plain
↑カジノに手を出すのはやめました

f:id:miyamotokazuaki:20151023103253j:plain
↑世界最大の観覧車High Rollerから見下ろすホテル群

f:id:miyamotokazuaki:20151022185829j:plain
↑ホテルでかすぎて、入り口入ってから迷う、迷う。ツアーメンバーがFacebookグループに「会場までの近道」を写真入りでアップしたらそれにたくさんいいね!がつくぐらい。

■会場の様子

 上の写真にある、一番繁華街のストリップ通りに面したベネチアンっていうところが会場でした。

 AWS re:Inventでは毎年、Amazon Web Serviceの様々な新機能発表がされます。今年もたくさん発表がありました。簡単にデータ分析ができる、Amazon QuickSight, 大量のデータ移行につかえる、Amazon Snowball, そしてKinesis Firehose, AWS Config Rules, Amazon Inspector, AWS Database Migration Service, AWS Schema Conversion Tool, Kinesis analytics, 新しいEC2インスタンスファミリーX1や、コンテナをより使いやすくする新サービスAmazon EC2 Container Registry, Python for Lambda, AWS Mobile Hubおよび、とどめAWS IoT。小さいものを含めるともっとたくさんあります。

 個々のサービスの内容は、数百人に登る日本からの参加者の皆さんがblog等で紹介されているので、このあたりから辿ってもらえればと思います。

aws.typepad.com

 全般的にはAmazonの「ビジネス面」の勢いを感じさせるものが多かったです。私の記憶では、数年前には、「システムのテストフェーズとかで使うと便利だからどんどん使ってくださいね」というトーンでした。今年は、「製造業や金融のミッションクリティカルかつ巨大なデータを扱う実環境としていけますよ!」と。データベース、データ分析のツール、IoT関連、いずれも出てくる事例は大企業、時代が変わっていっていることが見てとれます。

f:id:miyamotokazuaki:20151022185945j:plain ←BMWの事例

f:id:miyamotokazuaki:20151022185953j:plain ←工場でのIoT利用モデル

■個人的に一番印象的だったのはAmazon Snowballというサービス

 個々の新サービスの紹介をしはじめるとキリがないので、個人的に象徴的だと思ったものを一つ上げたいと思います。それはAmazon Snowball。これはなんとアプライアンスです。

f:id:miyamotokazuaki:20151022190008j:plain

 メジャーなクラウドベンダーがアプライアンス的なものを出すのは初めてじゃないでしょうか。

 これ、何の目的に使われるかというと、オンプレミスのデータをAmazonのS3に引っ越すためのものです。Amazon Snowballをオンプレミスのサーバに繋いでデータを吸い出して、それをAmazonに送るとAWSのS3にセキュアにアップロードしてくれるというもの。1台で50TBのデータを扱えます。

 我々も、エンドユーザ様から過去のメールを弊社サービス(HDE One)に入れてくれ、みたいな要望をいただいたり、そのアップロードの際に、転送速度をうまくコントロールしないと翌月の請求額が跳ね上がったり、そういう経験をしているので、こういうの必要だよね、と改めて感じました。データを引っ越す時に気になること、たとえば物理的破損だったり、セキュリティだったり、予想外の請求額だったり、そういったエンジニアや担当者が留意すべきところを全部考えなくていいよ、という隙間ソリューションです。例え、「フルスタックエンジニア」であっても、HDDが破損しない梱包の仕方とかっていうノウハウは持ってないですからね。  そして、そういう足回りのベタなところを(周りのサードパーティーがやるのではなくて)Amazon自身がやるんだということに少し驚きましたし、ここまで徹底してやるから伸びているのか、とある種の納得を感じました。

■実物見てみると

 このSnowball、そばでみるとごっついです。アメリカンサイズ。床に落とすと床の方が壊れるんじゃないかと(Keynoteでは床に落としてみせてましたが)。最近の超小型HDDとか見ていると、ちょっとびっくりするぐらいゴツい。

 ちなみに、何でsnowballっていう名前かっていうのを会場で聞いてみたところ、雪の球を投げつける=物理的なものを移動する=アプライアンスを搬送する、というようなことでした。加えて、帰国してからネットで調べると、「Cerro Torre(邦題:クライマー パタゴニアの彼方へ)」っていう2013年の映画の副題が a snowball's chance in hellっていって、ここから取ったのかも、というニュアンスの記事を見つけたので、これが(も)ビンゴかもしれません。

f:id:miyamotokazuaki:20151022190030j:plain

f:id:miyamotokazuaki:20151022190037j:plain

■いずれは消えるサービスだが、時代を象徴しているサービス

 このサービス、世の中のデータがことごとくクラウドに移行されちゃったら消えるサービス(?)ではないかと思います。オンプレミスからクラウドへの移行期ならではの象徴的なサービスかと。

 とはいえ、クラウドへのインポートだけではなく、export/importの両方をうたっています。説明ではImportの話が印象的だったので、てっきり、「Amazonにロックオンするone wayなサービスキター」と思ってたんですが、後からサイトを見ると「緊急時の復旧等の目的でexport使えるよ」って書いてありました。

 値段もお手頃。

 デバイス処理 $80.00〜$99.00(リージョンによって異なる) : 処理されるストレージデバイスあたり  データ読み込み時間 $2.49〜$2.99(リージョンによって異なる) : データ読み込み時間あたり。(2015/10/23時点)

 ただし、東京リージョンでは現時点(2015/10/23時点)ではまだやってません。アクセスすると、

Import/Export Snowball is not available in アジアパシフィック (東京). Please select another region.

 って表示が出ちゃいます。

 あと、「SnowballをAmazonに送る時にGPS付けてたらデータセンターの場所がバレちゃったりしないのかな?」というのは、re:Inventツアー参加メンバーの中で少し話題になっていましたが、さすがに会場では訊けずじまいでした。

■ペタバイトは今年のre:Inventのキーワードの一つ

 さて、このSnowballの説明には、”to transfer petabytes of data into or out of AWS(ペタバイトのデータを出し入れできるよ)"って書いてあります。この「ペタバイト」っていうのは、今年のre:Inventの隠れたキーワードのような気がしました。  キーノートの前日に開催されたパートナーサミットでもAndyがもうデータのサイズがペタバイトを超えるのは普通だ、って発言してました。私が聞きに言ったセッションの中にも、”Security and Compliance at Petabyte Scale”っていうゲノム解析データの事例が出ていました。  Amazon Japan様によれば、日本ではまだペタバイトのデータをAWSに預けているところって数社のようですが、これから増えていくでしょうね。

f:id:miyamotokazuaki:20151023103529j:plain ←パートナーサミットの様子

■宣伝!ペタバイト祭りやるよ

 さて、ここから宣伝です(笑)。

 HDEでもついに、AWSに預けているデータがペタバイトを超えました。そこで、これを記念するとともにAWS技術者に感謝するために、「ペタバイト祭り」なるものを催すことにしました。

 YAPC主催の牧大輔さん(@lestrrat)、AWS界隈で有名なMichael H. Oshitaさん(@ijin)を迎えて、「ペタバイト級データを支えるクラウドサービスの表と裏」〜ペタバイトまでの道のりと障害、そして、開発と運用のチームをどのように融合するかについて〜というテーマでパネルディスカッションやります。  モデレータは、なんと今話題のソラコムの玉川 憲さん!豪華な布陣ですが、無料です。場所はみなさんの大好きな渋谷です。面白そうだと思ったエンジニアの方は是非おいでください。

 f:id:miyamotokazuaki:20151023102707j:plain  f:id:miyamotokazuaki:20151023102502j:plain

 参加希望はFacebookイベントページ「ペタバイト祭り」

 https://www.facebook.com/events/1496829413966727/

 にて、「参加希望」ボタンをポチッと押してください。

 どうぞよろしくお願いいたします。

 以上です。

SORACOM Air/Beamはどんな問題を解決するのか、IoT素人の目線で考えてみる

こんにちは。HDEの小椋です。SORACOM リリース記念リレーブログ に参加させていただいております。

僕は機械・電気系はまったくの音痴、IoTも素人です。でも、クラウドは一応素人ではないので、オンプレミス機器をどんどんクラウドに移行したように、物理的な機器もどんどんクラウドのパワーを活用して、現実世界を豊かにすることができるんじゃないか、ということをよく妄想します。しかし、その時にいつも壁として立ちはだかるのが、物理セキュリティの問題です。

SORACOM Air/Beamが、それらの問題をエレガントに解決してくれたことに、とても興奮しています。うまく説明できるかどうかわからないのですが、以下チャレンジしてみます。

たとえば、家の玄関のチャイムを、クラウドとRaspberry Piのような安価な機器で実現することを考えてみましょう。面倒くさいので、とりあえず通話機能とかその他の機能とかはのぞいて、チャイム機能だけ考えることにします。

要件:玄関に来た人がボタンを押したときに、スマホに通知したい

という単純な問題を考えてみます。

f:id:goura:20151006023827p:plain

ボタンの部分はRaspberry PiとかEdisonとかにして、家の無線LAN経由でクラウドに接続し、クラウド側の何かのAPIを呼び出して、スマホに通知を送る。こうすれば、Raspberry Pi以外に特別な機器も要らないし、良さそうですよね。クラウドが得意な人なら、ちょっと電子工作するだけでできちゃいそうなので、一瞬ワクワクします。

でも、よく考えるとそう簡単でも無いんです。この時、Raspberry Pi側には、少なくとも二つの大事な情報が格納されています。一つは無線LANの認証情報、もう一つはクラウドのAPIの認証情報です。もしRaspberry Piだったら、実機を盗まれたら簡単に読み取れてしまう情報ですよね。

もし悪意を持った人が、玄関先にあるRaspberry Piを盗んだらどうなるか。無線LANの認証情報は、もし盗まれたら家の無線LANにタダ乗りされてしまったり、家のLANに侵入されてしまうかもしれない大事な情報です。クラウドのAPIの認証情報のほうは、万が一盗まれたら、いつでもどこでもピンポンが鳴らせる、無制限完全ピンポンダッシュが成立してしまいます。

  • 無線LANの認証情報は、家で普段使っている無線LANと別の無線LANにしておけばいいじゃないか
  • クラウドのAPIは、盗まれたことがわかった時点で認証情報を無効化すればいいじゃないか

と思うかもしれませんが、家で普段使っている無線LANと別の情報にしたとしても、タダ乗りは防げません。また、認証情報の無効化については、盗まれたことが検知できるならばそれでもどうにかなるかもしれませんが、検知に失敗し、盗まれたことに気づかないとどうしようもありません。たとえば、物理的にRaspberry Piを盗むのではなくて、盗んで素早くSDカードの中身をコピーして、また元に戻したらとしたらどうでしょうか。情報が盗まれたこと自体に気づかないかもしれません。

ちょっと考えただけでも「安心できる状況」を作るのは結構面倒くさいということがわかります。

SORACOM Air/Beamを使えば、こうした問題を解消できる可能性があります。

SORACOM Beamは、「SIM単位の認証と通信経路の保護をSORACOMが代わりに引き受ける」機能だと表現することができます。SORACOM Beamを使うと、SIMそのもの以外、Raspberry Pi側にはなにも認証情報を置かずに、そのSIM経由での通信が来た時のみ、SORACOMが代理で、あらかじめ登録してある認証情報を付加して第三者のクラウドAPIを呼び出すようなことが可能になります。クラウドAPIを呼び出すにあたっては、IMSIと呼ばれるSIMの識別番号の情報も付加することができます。

つまり、Raspberry Piは、SORACOMのSIM、SORACOM Airを使って通信さえすれば、無線LANの接続情報も、クラウドのAPIキーも、Raspberry Piには置かなくていいのです。証明書ストアの更新とか、そうしたことも忘れていい。大事な情報は全部、第三者に手の届かないクラウド側に置くことができます。

いわゆる「クローン携帯」が存在していないことを鑑みても、SIMを複製したりすることは相当に難しそうなので、SORACOM Beamは、問題をだいぶ単純化してくれる現実的な解であることがわかると思います。

上では触れませんでしたが、「100台置きたかったらどうするか問題」もあります。100台それぞれに別々の認証情報を設定することを考えると面倒ですし、一方全部同じ認証情報を設定してしまうと、万が一盗まれたときの被害が大きくなりますし、機器の入れ替え等で、数台だけアクセスを取り消したい、というような状況も面倒臭そうです。SORACOM Air/Beamを活用すれば、認証情報を各機器に格納する必要が無いため、100台全部に同じソフトウェアをデプロイした上で、どの機器にどのSIMカードを刺したかだけを記録しておけば良く、アクセス許可や、認証情報についてはクラウド側で集中管理することができます。

チャイム程度なら、他の無線テクノロジーでどうにかできるかもしれませんが、例えばドローンとか、デジタルサイネージとか、ロボットとか、クラウドから機器をコントロールするものの応用範囲は無限にありそうです。可能性が一気に拡がった感じで、ワクワクしませんか。そもそも3Gモジュールの値段がまだ高すぎたり、まだSORACOMが日本でしかサービスしていなかったり、まだまだ解決すべき課題はたくさんありますが、少なくとも大きな前進であることは間違いないですよね。

少し前に、うちの会社のインターン生がRaspberry Piで作った、クラウドベースのデジタルサイネージの社内導入を検討した際、上記のような話が問題になり「金属製のケースを作って南京錠でロックしてはどうか」などと議論した挙句面倒くさくなって話が立ち消えになるのを経験した私としては、例えば一般企業で、社内で実験的にIoT機器を導入したりするにあたっては、リスク受容できるところまでだいぶハードルが下がったのではないかと感じました。

さて、僕の文章は必要以上に長く、退屈なことで有名です。ここまで読んでいただき、ありがとうございました。ここで終わりと言いたいところなのですが、せっかくなので上記の話を実感するために、玄関チャイム的なものを試しに作ってから終わりたいと思います。

実際に作ってみる

用意するもの

  • Slack
  • SORACOMのSIMで通信可能な、Raspbian jessieが入ったRaspberry Pi
  • プッシュスイッチ、ブレッドボード、ジャンパ線

「SORACOMのSIMで通信可能なRaspberry Pi」が現在若干ハードル高めですが、このリレーブログシリーズが終わるころには、きっといろんな選択肢が説明されていることと思います。僕は @j3tm0t0 さんの

を参考にFS01BU(SORACOM自身が販売している)を使いました。

難しければ、とりあえず今回はあくまでもproof of conceptですので、SORACOM Airを刺したWiFiルーターとかスマホ(への無線LAN経由でのテザリング)とかの普通の接続で代用して、あとは心の中でPPP接続をしましょう。とにかくRaspberry PiがインターネットにアクセスするときにSORACOM Air経由で行くようにすれば以下の実験は可能です。

通知には、一番簡単なSlackを使います。Raspberry Piにつながったボタンを押すとSlackに通知が飛ぶようにしてみましょう。スマホにSlackのアプリを入れておけば、スマホ宛に通知を送ることもできますよね。

f:id:goura:20151006150145p:plain

こんな感じで、Raspberry PiはSORACOM Beamに対し、SORACOMの内部ネットワークを通じてHTTPでリクエストを送り、それを受けたSORACOM Beamが(特定のグループに入っているSIMからの通信の場合に限り)Raspberry Piの代わりに認証情報(APIトークン)を付加して、インターネット経由でHTTPSでSlackにAPIリクエストを送ります。

Raspberry Pi側には、SIMカード以外の認証情報は置きません。

今回は、SlackのWeb APIのうち、「chat.postMessage」 を使います。

このAPI呼び出しに必須となる引数は

  • token
    • 認証情報
  • channel
    • 宛先
  • text
    • メッセージの内容

の三つです。今回の試みでは、メッセージの内容はRaspberry Piから送り、SORACOM Beamで認証情報と宛先を付加します。

Slack Web APIの引数は "can be passed as GET or POST params, or a mix" という仕様なので、今回は行儀悪くmixする方向で行きます。

Raspberry PiはPOST paramでtextを送信し、そのリクエストに対し、SORACOM BeamがGET paramsとしてtokenchannelを追加します。

Beam側の設定を変えれば、Raspberry Piに変更を加えずに宛先や投稿するSlackのチームを変えることも可能な例を考えてみました。

SlackのAPIトークンの取得

https://api.slack.com/web の下の方に、簡易的な、全権を持ったトークンを発行するボタンがあります。今回はこれで試してみましょう。

f:id:goura:20151006031443p:plain

ボタンを押すと、上の図のボタンの左「none」と書いてあるところにAPIトークンが入りますので、控えておきましょう。

SORACOM Beamの設定

Beamの設定はユーザーコンソール「グループ」から行います。適当なグループを作った後、そのグループの「SORACOM Beam設定」から「HTTPエントリポイント」を追加します。

f:id:goura:20151006031602p:plain

「エントリポイント」のパスに/を、「転送先」のホスト名に「slack.com」を入れます。「転送先」のパスには、

/api/chat.postMessage?token=<<APIトークン>>&channel=@kazuhiro

を登録します。 <<APIトークン>> は上記で発行したAPIトークン、@kazuhiroのところは自分のSlackの@IDに置き換えてください。(画像では途中で切れていますのでご注意ください。&channel=@kazuhiroを忘れずに)

f:id:goura:20151006113048p:plain

このグループに、Raspberry PiからアクセスするSIMを登録します。SIM管理画面からSIMを選んで「詳細」です。

f:id:goura:20151006113858p:plain

この状態で、このグループに登録されているSIMが刺してあるRaspberry Piから http://soracom.io:8888/ にHTTP POSTすると、SORACOM Beamが https://slack.com/api/chat.postMessage?token=<<APIトークン>>&channel=@kazuhiro に同じ内容をPOSTしてくれるはずです。

Raspberry Pi上のcurlから、試しにリクエストを投げてみましょう。

設定が間違っていなければ、

$ curl -X POST -d 'text=hello' http://beam.soracom.io:8888/
{"ok":true,"channel":"D0BSL33EX","ts":"1444063662.167012","message":{"text":"hello","username":"bot","type":"message","subtype":"bot_message","ts":"1444063662.167012"}}

のような応答が帰ってきて、slackbotから "hello" という内容のDMが届くはずです。 (僕の環境だと、スマホにプッシュ通知が来るのは30秒後ぐらいだったので、玄関チャイムとしてはちょっと実用性に難あり)

プッシュスイッチの結線

ここまでできれば、後は押しボタンを付けるだけです。……とはいえ僕は電気はまったくの素人です。 押しボタンの結線、押しボタンを押したことの検知は、以下の記事を参考にしました。

O'Reilly Raspberry Pi Cookbook http://razzpisampler.oreilly.com/ch07.html

記事を参考に、GPIO 18番とGNDにプッシュスイッチをつなぎます。

Raspberry Pi 2の場合は、ピン配置が少し違いますので注意しましょう。

www.raspberry-pi-geek.com

そして、以下のPythonプログラムをどうにかして、Raspberry Pi上にswitch.py として保存します。

短縮URL作りました。curl -L https://goo.gl/4ijyJi > switch.py等で取得できます)

で、そのswitch.py を、同じくRaspberry Pi上で

$ sudo python switch.py

として起動すると、ボタンを押すたびに画面に

button pressed
text=hello%21

のような文字が表示されて、SlackにDMが届くはずです。

ということで、完成!

f:id:goura:20151006032159j:plain

Lチカから先に進んだことが無かったド文系の僕でもIoTできました。感動です。

Raspberry Piは、単に http://beam.soracom.io:8888/ にアクセスしているだけで、何の認証情報も設定していません。仮にこれをプロダクトにして100台、それぞれ全く違う家庭に販売することになったとしても、SDカードの中身は全部同じでいいはずです。SIMの所属するグループが異なれば、異なるSORACOM Beam設定が適用可能なので、機器毎に違うSlackに投稿させることもできます。SORACOM Beam、便利ですね。

後片付け

遊び終わったら、ここで使ったAPIトークンは忘れずに無効化しておきましょう https://api.slack.com/web の右上の "My Auths" をクリックした後の画面のゴミ箱マークから無効化が可能です。 f:id:goura:20151006114711p:plain f:id:goura:20151006114724p:plain

まとめ

図をノートPCのトラックパッドだけで描こうとするのは無謀

YAPC::Asia Tokyo 2015に参加しました

こんにちは、クラウドプロダクト開発部の篠原です。

20-22日にYAPC::Asia Tokyo 2015が開催されました。同僚に主催者の牧さんがいたり弊社もスポンサードしていたりという縁もあり、初めてYAPCに参加してきました。 (HDEがスポンサードするようになった経緯はこちら: HDE Inc x YAPC::Asia Tokyo 2015 - HDE BLOG

YAPCの興奮が冷めないまま週が明け出社したところ、突然向かいの席にいる牧さんから

と言われてしまったため、わたしもブログを書くことにしました。

Perl Conference?

YAPCは「Yet Another Perl Conference」の略で、Perlのカンファレンス…ではありません。 YAPCでは、Perlに限らずGolangやJavaScriptなどPerl以外のプログラミング言語のトークからリモートワークやエンジニアとしての姿勢など働き方のトークまで、多種多様なトークが発表されました。わたしは普段はJavaScriptやGolangを使っているので、YAPCは今までPerlのカンファレンスと思ってスルーしていました。完全に騙されました。

Comment about Talks

YAPCのトーク一覧とスライドは、公式ページのTalksで確認できます。感想などは、公式ページの感想エントリまとめや、Togetterで確認できます。ためになるトークばかりだったので、ぜひご覧ください!折角なので、個人的に印象に残ったトークをさくっとご紹介します。

我々にできるOSSとそのコミュニティの育てかた - @tagomoris

www.slideshare.net

Treasure Dataの@tagomorisさんの発表です。OSSを公開する理由からOSSをどうやって育てていくかとい発表でした。弊社も過去にOSSを公開して苦労したので、発表の間は頻繁に共感していました。発表の中で印象的だったのが「IssueやPullRequestは常に英語を使う。日本語のPullRequestは即却下」といった英語の重要性です。弊社は会社の共通言語として英語を採用予定で、現在進行形で英語に激しく苦労しているため、激しく同意せざるを得ませんでした。

Effective ES6 - @teppeis

www.slideshare.net

Cybozuの@teppeisさんの発表です。先々月仕様が公開されたECMAScript6についての発表でした。わたしは普段フロントエンドエンジニア的な仕事をすることが多いので興味津々でした。内容は、ES6の仕様をかいつまんだわかりやすい説明でした。ES6の仕様は、Pythonなど他の言語と似た仕様が多く、使いやすそうで学習コストも少なそうという印象を持ちました。これからはES6の時代ですね。また、ES6からES5のコードを生成するTranspilerであるBabelを紹介されていました。「これからはバベっていこう」がキーワードでした。バベっていきましょう。

YAPC::Asia Tokyo 2016?

以上ですが、簡単なトークの紹介でした。

とてもためになったので来年もYAPCに参加するぞ!と意気込んでいたのですが、なんとYAPC::Asiaは今年で最後らしいです。まさか初参加で最後とは…。YAPCのように垣根のない多種多様なカンファレンスは貴重なのでかなり名残惜しいです。が、つぎはPerlという冠がないカンファレンスが開催されるとかされないとかいう噂が!?楽しみです!

最後になりましたが、YAPCの運営スタッフの皆様、お疲れ様でした!

GopherCon 2015に参加してきました

クラウドプロダクト開発部たなべです。

去る2015年7月にアメリカはコロラド州デンバーで開催されたGopherCon 2015に参加してきました。 アメリカ出張は昨年のDockerConに続いて2度目です。

デンバーはみんな大好きサンフランシスコから約1900km離れています。Google Mapによれば車で18時間だそうです。飛行機なら2時間ですので西海岸からのアクセスも良好と言えそうです。昨年からは成田空港、デンバー国際空港間で直行便の運行が始まり便利になったそうです。

今回はエクストリーム和装家としても有名なCTOと一緒に行きました。

上の記事でも触れられていますが、滞在期間中のデンバーはあまりパっとしない天気で、どちらかといえば日中もすこし肌寒い気温でした。

f:id:nabekent:20150803142655j:plain

GopherCon二日目は晴れ間が見えましたが、滞在中は雨が降ったり止んだりと不安定な天候でした。

会場となったのは上の地図で上げたコロラドコンベンションセンターです。コロラド州といえばロッキー山脈などの大自然です。

f:id:nabekent:20150803141052j:plain (熊もGopherConに興味津々の図)

f:id:nabekent:20150803142008j:plain 会場前にはCoreOSトラック(バス?キャンピングガー的なもの?)が止っていました。ひょっとしてCoreOSチームはこれに乗って1900kmもはるばる来たんでしょうか…?

f:id:nabekent:20150803141347j:plain

まずGopherConで驚いたのは参加者に配られるグッズの豪華さでした。

f:id:nabekent:20150803141550j:plain

ただのリュックではありません。参加者がほぼ開発者であることを見越して、きちんとラップトップ収納用スペースがあり、バッテリーやケーブルなどの細かいものもきちんと入れられるものでした。

f:id:nabekent:20150803235202j:plain

ロゴ入りのコップです。アメリカンな大きさですが、この季節、麦茶をめいっぱい入れて飲むのに使っています。お気に入りです。

他にもスポンサー提供のグッズがリュックに大量に入っていました。

GopherCon 2015のメインセッションはシングルトラックで二日間で計22セッションが行なわれました。そのためセッションは朝から夕方までびっしり入っています。

f:id:nabekent:20150803143230j:plain

朝7時すぎから朝食が用意されました。

f:id:nabekent:20150803143634j:plain

コーヒー、甘いもの、そしてオートミール。メニューは両日とも同じでした。

f:id:nabekent:20150803143756j:plain

Wikipediaを読むと健康食として人気のようです。ただ、見た目がアレでCTO曰く、日本人でちゃんと食べたのは私が初めてとのことです。シュガーやドライフルーツを入れればおいしく食べられました。

13時から昼食でしたが、ビュッフェスタイルにも関わらずパイプラインが4本程度しかなくスループットがまったく出ていませんでした。そのため会場の外に人が溢れ返っていました(Goのカンファレンスなのに!!)。そしてお昼の写真は取り忘れました…。

朝食と昼食は見知らぬ人との絶好の会話の機会です。どういう仕事をしているのか、どういう技術スタックを使っているのか、どこで苦労しているのかなどを情報交換できるのがカンファレンスのもう1つの目的です。今回は英語が話せるCTOもいたため興味深いGoのユースケースを聞くことができました(そして大抵そういう話は書けない)。

f:id:nabekent:20150803155647j:plain

ホール外にはスポンサーブースがありました。今回はCoreOSのetcd Tシャツをゲットしました。

f:id:nabekent:20150803155806j:plain

いくつかのセッションについて触れたいと思います。すべてのセッションのスライドと動画は http://blog.golang.org/gophercon2015 から辿れます。

動画では省略されていますが、MCはCoreOSのKelsey Hightower氏でした。

ベテラン司会者を彷彿とさせる軽快なトークとジョーク(みんな笑ってるけど英語がまったく聞き取れず笑えなかった)で笑いを量産していました。いよいよ今月となったYAPC Asiaでのトークがとても楽しみです(同時翻訳付き!!)。

Go teamからはオープンソースコミュニティとしてGoについてのトークがキーノートそしてクロージングで行なわれました。

Goはもともと数名の少数チームで言語デザインを行なってきました。初期にはこれらはうまく行きましたが、Goのエコシステムが拡大するにつれコミュニティと協力してこれらのGoを作っていくことが重要という趣旨をGo teamが繰り返し話していたのが印象的でした。

  • vendoringについて: 従来Googleでは問題ではなかったとの姿勢だったのが『Goコミュニティは「問題」として認識していること』を認識し、Do Less, Enable Moreに基いてGo 1.5に実験的機能(GO15VENDOREXPERIMENT)を入れ、よりよいベンダリングのための仕組みを設計していく
  • Code Of Conductついて: コミュニティを形成していくにあたりCode Of Conductの必要性があるのではないかという発議
  • デザインプロセスの明文化: 提案の仕方、提案の評価、提案の履歴などを残せるように仕組みを用意していく

次の5年(10周年)に向けての足固め的セッションだと感じました。私も影ながら見守っていきたいです。

そして、英語

こうして海外のカンファレンスに行けるのはこのブログでも何度も触れているように英語の社内公用語化を来年に控えているためです(つい最近コピー機の言語設定が英語になりました)。

CTOは帰国子女で私から見ればペラペラです。しかしそれでもセッション後の質疑応答の聞き取りには苦労したそうです。無論、私はまったく聞き取れませんでした。

日本国内にいてそれなりに日本人の話す英語、アジア人が話す英語が聞き取れるようになった私ですが、やはりネイティブが話す英語を聞き取るにはまだまだ訓練が必要(そして私にとっての今の壁)であることを再認識したアメリカ出張でした。

ともあれ、言語習得に近道はなさそうですから、来年はもうちょっと成長して海外出張に行けるようまた1年がんばりたいと思います!!

f:id:nabekent:20150803155847j:plain

労いの肉!の図(ごちそうさまでした!!!!)

OSCON 2015に参加してきました

f:id:lestrrat:20150720110743j:plain

OSCON 2015に参加してきました。実はOSCONは初参加です。

f:id:lestrrat:20150721123220j:plain

場所はオレゴン州ポートランド。アメリカ北西部の町です。着いた週末は熱波に襲われていたようで地元の人達は暑さにあえいでいたようですが、東京から来た自分は「湿気がないだけでずいぶん過ごしやすいな」程度の感想でした。滞在中は天気にも恵まれ、大変過ごしやすかったです。反面熱波が落ち着いてくると、夜はかなりひんやりした感じでした。

f:id:lestrrat:20150721050701j:plain

一般客のチェックインはセルフサービスだったようです。私はスピーカー枠だったので別部屋でした。OSCONで少し印象的だったのは、かなり明らかに参加者の中にヒエラルキーのようなものがあり、一般参加者、スピーカー、スポンサー、とかなり提供されるサービスに差があったということです。仕組み的には当然だとは思うのですが草の根活動的なカンファレンスばかり主催していたので印象に残りました。

最初の二日間はチュートリアル等がメインです。チュートリアルは一枠3時間のものと6時間のものとあり、かなりガッツリ行われている印象です。自分は諸事情によりほとんどこれらには参加していませんが、ミーティング等の間にMesosのチュートリアルに参加してみたりしました。

ハンズオンセッションだったのですが、講師の方々はプロのエンジニアですがプロのチュートリアル講師ではないので進行に若干不満が残りました。内容はなかなかおもしろいものでした。ちなみにほんの一昔前までは聴講者にチュートリアル用の環境を用意するのはなかなか大変な事でしたが、今は「Vagrantを入れておいて」程度の周知をした上で6GBくらいのイメージを渡せばそれで済むのですからバーチャリゼーションやコンテナ技術に感謝感謝といったところです。

f:id:lestrrat:20150720101208j:plain

聴講している以外の時間は主に来場者達と色々な話をするか、自分のスライドの準備に費やしていました。去年日本で会ったDave Cheney氏や今年のYAPC::Asia Tokyo 2015で来日予定のCasey West氏とKelsey Hightower氏にも会うことができました。

f:id:lestrrat:20150721044148j:plain

会期中はずっと昼食が提供されていました。かなり広めのホールにテーブルがずらりと並べられ、プレートをもらってセルフサーブで盛ったご飯をテーブルでいただく感じです。

f:id:lestrrat:20150721051607j:plain

自由に情報を貼り付ける事ができるボードがあり、ここで求人や求職活動が行われていました。こういうオープンな活動はもっと日本でもやれればいいのになーとは思うのですが、やはり文化の違いですね。

f:id:lestrrat:20150721051620j:plain

なおその横にはBoFの集まりを知らせるスケジュールもありました。こちらも空いている時間に自分で企画した集まりを告知して参加者を募ることができます。

f:id:lestrrat:20150722101903j:plain

こんな落書きスペースもあります。

f:id:lestrrat:20150722022646j:plain

二日目はOSCONタイミングを合わせてkubernetes 1.0 のリリースを記念したkuberconが開催されていたのでそちらも覗いてきました。やはりみんな気になるようでかなり盛況でした。

f:id:lestrrat:20150721094501j:plain f:id:lestrrat:20150721095156j:plain

チュートリアルの最終日夜には「Ignite」という名称のLightning Talkです。このセッションではスライドは20枚のみで15秒ごとに強制的に切り替わり、確実に5分で話は終わります。運営側の無駄に時間を長引かせないための努力が見られる形式でした。

f:id:lestrrat:20150721095858j:plain

なお発表者の女性率の高さが印象的でした。これが「印象的」となってしまう事実はカンファレンス運営者としては反省しなくてはいけないですね。

三日目からキーノートと一般セッションが始まります。朝一番のブロックのキーノートではPaul Fenwick氏とAllison Randall氏のトークがなかなか印象に残りました。どちらも動画が提供されています


They&#39;re Here. What Now? - Allison Randal Keynote ...


The Future is Awesome - Paul Fenwick Keynote ...

セッションは12トラックもあるのですが、その合間合間には様々な企画が催されています。

f:id:lestrrat:20150722091353j:plain f:id:lestrrat:20150722091914j:plain

Expo Hallではいわゆる展示会的な催しがあり、時間によっては軽食も振る舞われていました。

f:id:lestrrat:20150723042801j:plain www.oscon.com

自分のトークはこれまで自分がYAPC::Asia Tokyo等で発表してきた物の英語版だったのですが、今回参加してみてこのチョイスは若干ミスだったと思っています。

OSCONは良くも悪くもすでに一大展覧会であり、オープンソースの意義や啓蒙についてのイベントです。現場エンジニアのレベルの話より業界を変えていく話だったり、業界全体の技術トレンド等について興味がある人が集まるということです。その中で技術そのもの、しかも言語間の根源的なトピックについて話すのは微妙だったな、というのが正直な感想です。次回参加する場合はそのあたりを踏まえ、もう少し上のレイヤーの話を用意して行こうと思います。

www.oscon.com

イベントの楽しみ方としてはやはりトークそのものよりトーク前後に関係者を捕まえて四方山話をするほうが遙かにためになりそうでした。トークの内容に関しては技術的に細かい話はそれほど多くないので、トレンドを読み解くという意味ではスケジュールを見れば見えてくるものがあるのでそれで事足ります。さらに突っ込んだ話はパーティーやレセプション、そして廊下での会話の中でしか得られないという気がします。

f:id:lestrrat:20150722030714j:plain

ちなみに今回のテーマは明らかに"Cloud Native Applications"とKubernetes, Mesos, Docker等を用いたマイクロサービスアーキテクチャだったと思います。正直に言うと業界トレンドとしてはそうなのだと思いますが、現場でコードを書いている身からするとわりと今更感があったので、それを五日間繰り返し繰り返し連呼されるのは最後にはおなかいっぱいという感じでした。

おまけ

ポートランドダウンタウンのKenny and Zuke's のルーベンサンドイッチが超絶うまかったです。

f:id:lestrrat:20150720113757j:plain

あと偶然会場までの経路にベトナム人街があったので、会場以外でご飯を食べるときはそこでフォーを食べていました。日本のフォーもおいしいのですが洗練されすぎててなかなか納得がいかないので、アメリカで手に入るフォーが大好きなのです…

というわけで色々楽しいポートランド滞在でした!

English as a Second Presentation Language という取り組みを始めてみました

HDEでは近いうちに公用語が英語に切り替わるということもあり、月一のテクニカルセッションは英語だったり、ミーティング等も英語だったりします。そのようなわけで英語に触れる機会はそれなりに多いのですが、やはり議論や質問をする場があったほうがいいなぁと思い新しい取り組みを始めてみました。

アメリカンスクールに通う子供で英語を(十分に)しゃべれない子供はESL (English as a Second Language)というカリキュラムに入れられてまず英語を重点的に勉強させられるのですが、それにひっかけて "English as a Second Presentation Language"として、プレゼンを通して英語の疑問をぶつけたりそれに答えたりする企画です。これまでもいくつか英語でプレゼンをする集まりはあったと思うのですが、具体的な質問をしたりプレゼンに対してのフィードバックをする時間を設けよう、というのが趣旨です。ちなみに私は小6の時に海外に引っ越しした際にアメリカンスクールにぶち込まれ、ESLに1年間在籍した経験があります。

f:id:lestrrat:20150721082237j:plain

今回は初回ということでまず私がどういうことを気をつけるべきかを含めた話をさせてもらったあと、社内から次のテクニカルセッションで登壇する予定の二人から練習をする形で発表をしてもらいました。

私の発表は以下に置いてあります。読まれる場合はスピーカーノートを開きながら読んでいただくとよいかもしれません(プレゼンテーション表示中に"s"を押してください)。

いくつかのポイントとしては

  • 英語の細かい規則にこだわるより観客に伝えることを考えよう
  • 得意でない言語でプレゼンをするなら、プレゼンの基本的なテクニックをより意識しよう
  • 具体的なtipsをいくつか

というようなことについて語らせていただきました。

プレゼンテーションのあとは質問タイムで、20〜30分ほど質問を最初は英語その後日本語で受け付けて答えたりしました。この英語で質問をする、というのが意外と重要なのでこれをもっと推していけるような仕組みを作るべきと感じました。もちろん日本語でも良いんですが…

その後は社内の二人からの発表。本来はこちらのほうがメインのコンテンツです。発表がおわり、これまた10分〜20分ほどのディスカッション時間を設けました。発表者と聴講者両方からの質問がありました。ディスカッションの内容は発表の内容、言い回し、時制についての注意等が出ていました。

なお本番は1週間後ということもあり、まだ準備中のスライドでしたが、だからこそこのタイミングで英語やプレゼンの構成をみんなでディスカッションする意義があると個人的には思っています。

今回は初めての回ということでとりあえずどうなるか見るために徒手空拳で開催してみました。主催側からの次回の改善点としては

  • もう少し発表者・聴講者から質問等を出しやすい(強制的に出す?)フォーマットを作る
  • ディスカッションに参加しやすいように事前準備をする
  • なんとかして英語で質問をしてもらう

というような事を考えました。ともあれ、第一回としてはなかなか良い感じだったと思います。

うまく回るようになればもっと一般から参加者を募って開催したいと考えていますので、もしこのような企画に興味がある場合は是非私(@lestrrat)のほうまで連絡ください!