AWSの話題を中心に、日々の業務やプログラミングの徒然を綴るエンジニアブログです。

HANDS LAB

HANDS LAB ENGINEERS BLOG

ハンズラボエンジニアブログ

おみやげAPIの裏側〜re:Invent企画〜

Pocket

10月にラスベガスで開催された「AWS re:Invent 2015」。

AWS re:Invent 2015

参加したメンバーは考えた…。
新サービスについて紹介するだけなら、”某ブログの会社”の方が早いし詳しい…。
それなら、新サービスを使って何かを作ればいいんじゃないか!?と。

そこで、メンバーに配るおみやげを抽選できる
おみやげAPIをつくるべく、「おみやげAPIプロジェクト」が発足!
無事おみやげは配れたのか?
今回は(やっと)その全貌・開発の裏側に迫ります!

おみやげAPIの立ち上げ

チーム構成は、
re:Inventに参加した 井上、今井。そこにAWSエンジニア加藤がJoin。
さらにデザイナー田名網も加わり強力な布陣に(えっへん)。
おみやげの写真撮影などサポートを青木が担当。

過去のブログ
おみやげAPIをつくろう〜AWS re:Invent参加メンバー企画スタート!
おみやげAPIをつくろう〜絶賛開発中!re:Invent企画〜
来たよ!re:Invent〜展示エリア(Central)を楽しもう編〜

写真の数はざっと20枚。ですが、実際には同じものやサイズ違いなどもあり、商品数はもっとありました!

おみやげ配布大会(re:Invent報告会)スタート!

計3名分ともなると、長机に乗り切らないほど!
omiyage02

多くのメンバーが参加しました〜おみやげ応募は事前に案内して「応募しておいてね」と伝えていました。

reinventhoukokukai

おみやげに応募する画面はこのような感じです。
希望のおみやげを選択して、エントリー。

omiyagegamen

管理側(抽選する側)の画面です。ラスベガス風。

chuusengamen

おみやげAPIの裏側

決め事としては、以下の2つです。
・できるだけAWSの新サービス(re:Inventで発表されたもの中心)を使う
・NoEC2

また、ざっくり要件は以下のとおりです。
・ユーザー側機能
 -おみやげの一覧を見ることができる
 -欲しいおみやげに応募できる
・管理者側
 -応募状況が確認できる
 -おみやげの抽選が行える

設計したものがこちら。ついた字名が「新技術の無駄遣い」。

omiyageapisekkei

・アプリケーション
 -JavaScriptによるシングルページアプリケーション
 -iOSアプリもあり
 -配信はCloudFront(S3オリジン)
 -無駄にWAF

iOSアプリのアイコンはこちら(デザイナー田名網作)
omiyageicon

・認証
 -Facebook

・権限付与
 -Cognito

・データ
 -応募やユーザー作成はAPIGateway
 -APIGateway+Lambdaを経由してDynamoDBへ
 -LambdaはPythonを使用(JS非同期処理多い…Pythonならシンプルにいける)
-Lambda SNS使って処理が管理者に飛んでくる
 -登録状況確認 無駄にcron使いたかった
 -DynamoDBに入った応募データはLambdaからFirehoseでS3経由Redshiftへ
  (ただ、Lambdaコンテナ上のSDKが古くてFirehoseが呼び出せず→実現せず)
 -Lambdaの定期実行(CRON)を使って応募状況をSNSでサポート

やってみてよかったこと

新サービスを無理やり使う方針によって
・どんなサービスがあったか復習できた
・想定ユースケースの確認ができた

新サービスを使ってみて
・サービスの概要を把握できた
・一回手を動かしてみることで、苦手意識が低下した
・Lambda力がました
・APIGatewayが使えるようになった
・Node.jsの辛さを再認識した
・Pythonに目覚めた
・サーバレスアーキテクチャも行けそうな気がしてきた

サーバレスアーキテクチャについて
・APIGatewayの登場により、より現実感が増した
・2 Tireアーキテクチャは用途が限定的なイメージ
・デプロイ系はまだこなれてない
・開発方法、運用方法についてノウハウの蓄積が必要
 デプロイ方法の確立(JAWS frameworkなど)
 ブラウザでポチポチするのは辛い
 ログまわり(CloudwatchLogs辛い)
・認証まわりがまだふわっとしてる(自分の中で)
・うまくいけばコストダウンになりそう

・新しい技術を学ぶのには”しばり”があると面白い
新サービスしばり、Lambdaしばり、EC2レスしばり…

エンジニア井上が資料にまとめておりますので、こちらをご覧ください。
AWS活用の今までとこれから-東急ハンズの事例-

なお、抽選にはちゃんとドラム音が鳴り、無事おみやげたちはメンバーの手に渡っていきました!

Pocket

Baby Engineerはつかまり立ちをした。

Pocket

ひよっこエンジニア、ケイティのエンジニア成長記、2回目です。今回はローカルストレージを使ったメモ帳をJavaScriptで作成してみました!今回も本文・日本語訳ともケイティ本人が書いています(日本語は少しだけブログ担当が直してますが)

Fall is by far my favorite season; mainly for all the holidays it holds: Halloween, Thanksgiving, and Christmas. How was your Halloween?
Even if you don’t celebrate this holiday, it’s still entertaining to see all the costumes. What do you think of mine? (You could only grab this mask for a limited time at Tokyu Hands during Halloween.)
秋は私の断然お気に入りの季節です。主に秋には色々行事があります:ハロウィーンや勤労感謝の日やクリスマス。皆さんのハロウィーンはいかがでしたか? ハロウィンを祝わないとしても、誰かが仮装するのを見るのは楽しいです!私の仮装はいかがですか?(このマスクはハロウィンの間、東急ハンズでゲットできたものです!w )

IMG_4107

I have been busy lately with learning how to use Javascript with a little Local Storage thrown in. Two other coworkers and I participated in a class called “Javascript for REAL.” Funnily enough, after completing this course, I believe I have a better grasp of Unicage.
最近は、Javascriptでのローカルストレージの使い方を学ぶことに忙しかったです。私ともう二人同僚と一緒に二ヶ月半の間 「ほんきでJavaScript」 の講座に参加させて頂きました。おもしろいことに、この講座の後ではユ二ケージを前よりもよく把握できたと信じています。

For this class we created our own memo pad from what we learned in class. It was super challenging, and I could not do most of it on my own. My team leader likes to grin and say that he felt like he passed the course even though he didn’t officially take it.
このクラスでは、講座で学ぶ内容を使って自分のメモ帳を作成します。このプロジェクトはとてもやりがいがあり、一人ではほとんどできませんでした。(復習を手伝ってもらったので)私のチームリーダーは「ぼくは講座受けてないけど、これだけやればきっと受けたようなものだね!」とにやりとして言っています。

My memo pad is quite simple; the reason for that is because I wanted to understand how to properly use local storage and see how everything is supposed to flow together.
私のメモ帳はまったく単純なものですが、わざとそう作成しました。理由は、どのようにローカルストレージをキチンと使用して、どのように全体が一緒に流れるべきかを理解したかったからです。

Although my goals have altered a little from what I originally set out to do, I achieved most of them which I’m pleased about.
今回発表するものは、そもそもの目標設定からは少し変更されたけれども、ねらいはほとんど達成したので私は喜びました。

I created two input fields-one for the title and one for the text-which gave me some trouble.
私はtitleとtextの2つのinputフィールドを作成しましたが、それらによっていくつかトラブルが起きました。

At first I had all the code crowded together, but I have since learned it’s better to break it apart into smaller chunks.
最初は全てのコードを一緒に組み込んでいましたが、そのとき、小さいまとまりに分けることが良いとまなびました。

The priority button uses the toggleClass API. I want to find a more practical use for it, but for right now that’s all it does.
重要度ボタンは、toggleClass API機能を使用します。今はそれで終わりですが、私はもっと実践的な使用法を見つけたいです。

If we decide to edit it, the information is pulled into these two hidden input text boxes. Here we can edit and save the changes back to the selected memo. Even if we have multiple memos it always saves to the original selected memo. I’m currently looking into getting the delete button to work the same way.
もしメモを編集しようとするなら、情報は2つの非表示にしたinput textにひっぱられます。ここで選択されたメモに対して、編集、差分の保存ができます。たとえ複数のメモが合っても、オリジナルの選択されたメモに対して保存ができます。削除ボタンも同様に動く方法を探しています。

 

First we input some words, and press add memo where it is automatically saved to Local Storage
最初に、input内に何か言葉を記入し、メモ追加ボタンを押します。それはローカルストレージには自動保存されています。

Currently it only saves the top most memo, but when I incorporate the auto save with numbers perhaps that will change.
現在は一番上のメモのみが保存できますが、私が自動保存機能と数字等を組み込みことができれば、おそらく変わると思います。

Local Storage is really useful, so get out there and start using it if you aren’t already!
ローカルストレージとは本当に便利なものなので、まだ 使ったことがない人は早速使ってみてね !

Pocket

ハンズラボ本棚の更新通知をSlackに流したい!

Pocket

はじめまして。ハンズラボ歴3ヶ月、pythonista歴3日の倉嶋です。

ハンズラボでは技術書は経費で落ちますので、みんなドンドン買ってきます。
総務担当がポチポチGoogleスプレッドシートに蔵書登録していたのですが、登録が間に合わず、未登録の蔵書が散見されるようになりました。
解決のため、BooklogにWeb本棚を作りました。
BookLog

モバイルアプリからもバーコードで登録できて便利!各自で登録できる!
ついでに新規登録した蔵書をSlackに流したい!ということでBooklogのRSSフィードを使って作りました。
ハンズラボっぽい縛りは以下のとおりです。
* せっかくだからAWS使おう。新機能のLambdaのScheduledEventだ!
* Lambdaでpython使えるようになったし、pythonで書いてみよう!

・・・と勢いこんで作ってみたはいいものの、python+lambdaの落とし穴にハマるハマる。
* python書くの初めてで、標準ライブラリか外部ライブラリかがわからない。
* 外部ライブラリはzipアップロード時に含める必要あり。pipで落とすときに-tオプション使ってディレクトリ指定する。
* 「1時間前の時刻を取得したい」ところなんですがRSSの時刻表記をYYYYMMDDにしたり時間計算したりがうまくいかない・・・。
* Lambdaのpythonは2.7なので、UTF-8文字列は明示的にu’’。
* UTF-8文字列のURLエンコードでハマる。asciiじゃないよエラーいっぱい出て泣く。
* AWSコンソールでは日本語文字列使えないぽいので、zipで固めてuploadする。(Lambdaのコンソールでコード書いてsaveすると文字化けする。コメントもろとも)
* zipファイルアップロード時に「fileb://」ってつけないとNG。
aws lambda update-function-code --function-name check_booklog_tl --zip-file fileb://booklog2slack.zip
* アップロード時、本体のファイル名はlambda_function.py固定。
* def lambda_handler(event, context)がないと動かないのでローカルでのテスト時にいちいち書き換えないといけない。
* Scheduled Eventの登録で謎のエラー・・・いつの間にか登録できてたのでエラーの原因がわからん・・・。

半日くらいの見込みだったのですが80行のコードに2日位かかって、ようやく完成しました。
github

Booklog_Lambda_Slack_IF
おかげさまで社内ではそれなりに好評です。
反省点は、「公式ドキュメント、大事」「似たようなことやってる人を探すの、大事」です。
いきなりやりたいことをやる前に、公式のサンプルプロジェクトをやっておけば半分の時間で完成できた気がします。

ちなみに、シェルスクリプトで作った参考実装は1時間くらいでできました。Lambdaでbashが動いてくれれば・・・。

Pocket

おみやげAPIをつくろう〜絶賛開発中!re:Invent企画〜

Pocket

エンジニアブログからこんにちは、マーケ担当の青木です。

AWS re:Invent 2015に参加したエンジニア、井上&今井のアイディアから生まれた
「おみやげAPIをつくろう」というプロジェクト。
re:Inventでゲットしたおみやげは無事メンバーの手に渡るのか!?
スーパーAWSエンジニアの加藤もJOINし、プロジェクトは進行中。
中間報告をレポートします!

omiyageicon

アイコンはデザイナー田名網作 Amazon風?

前回のブログでお伝えしたように、今回はre:Inventでゲットしてきたおみやげを
メンバーに配ることが目的。

事前準備として、以下の項目が入った「おみやげリスト」を青木が作成。

・おみやげの内容(例:DockerTシャツ)
・サイズや量(例:Lサイズ、2枚)
・商品写真 (例:DockerTシャツの写真)
dockertshirt

おみやげAPIは、ざっくり以下のようなイメージです。
・web&iPhoneアプリ対応
・Facebookでログイン
・商品一覧が出てきて、3つまで応募できる
・抽選ボタンが出てくる
・当選かどうか確認できる

10/23時点では以下AWSサービスを利用して構築しています。
1) API Gateway
2) Lambda/Pythonの利用
3) Cognito / Facebook認証
4) WAF
5) サーバーレス(NoEC2)

また、以下も考えています。

1) Firehose の利用
entry -> DynamoDB stream -> lambda -> s3 -> redshift
2) Lambda cron の利用
entry 状況をメールでお知らせする

構成図については近日公開予定!お楽しみに!

これが当たっちゃったらどうしよう…

snowball

注:SnowBallの重さは約23kgらしいです

Pocket

Amazon様とAmazon Machine Learning ハッカソン/Meet-up を開催しました

Pocket

臼井です。
他の皆がリアルタイムに 10月の re:Invent の報告をしている中、
なんと9月中旬から下旬にかけて行われた Amazon Machine Learning ハッカソン/Meet-up について報告します!
今回はADSJ様(Amazon Data Service Japan)による主催・運営と、
ハンズラボによるデータ提供とサポートによる共催でした。
以下、このハッカソンについてお知らせしていたページを記します。

Amazon Machine Learning ハッカソン/Meetupを開催します|ニュース|ハンズラボ株式会社
Amazon Machine Learning ハッカソン with ハンズラボ 2015年9月12日【Amazon ML ハッカソン】
Amazon Machine Learning Meet-up with ハンズラボ 2015年9月29日【Amazon ML Meet-up】

どのようなハッカソンだったか

概要

今回ハッカソンという名称で開催しましたが、1,2日こもってアイデア出しから始めてアプリケーションを作る!
というよく聞く感じのものとは少し違います。
イベントタイトルにもあるように、今年ローンチされた、
Amazon Machine Learning(以下、AWS ML と表記)を使用して、
素材データからお題に対する解を得てスマートアプリケーションを作る、
という、ややデータハッカソン要素のあるものです。

AWS ML については、以下のADSJ様の記事をご覧下さい。
Amazon Web Services ブログ: 【AWS発表】Amazon Machine Learning – Data-Driven Decision at Scale

データハッカソンについては、有名どころで言うと、Kaggleが主催のものが挙げられます。
Competitions | Kaggle
常時、企業や組織の実データに基づく課題を受け付け、
一般のデータサイエンティストらが、それらに対してよりよいモデルを作成しようとし、結果を出そうと常に競っています。
モデルの買取があるし実データいじるのが楽しいしで、皆必死ですw

今回のAWS ML ハッカソンは、以下の様な特徴が有ります。

  • 必ずAWS ML を使用して、予測モデルの生成に使用するというレギュレーションの存在。
  • 参加者はデータサイエンティストだけではなく、アプリケーションエンジニアも想定する。

非データサイエンティストでも、データサイエンスの果実を自ら手を動かして一定の程度得ることが、
手を出しやすい分析サービスの存在により既に容易に可能となっている、ということを、
実データと最新のサービスを用いて実感してもらう、という想いで、
ADSJ様と二人三脚で進めて参りました。

スケジュールは、
2015/09/12 ハッカソン初日開催。
~2015/09/28 ハッカソン初日開催日から引き続きHacking.
参加者の皆様とはSlackでコミュニケーションをとりつつ、ADSJ様と共にサポート。
2015/09/28 Meet-up にて成果発表!
という流れでした。

使用データとテーマ

テーマはずばり、以下です。

2015/09/14(月)~ 2015/09/20(日)の 東急ハンズの店舗毎の売上予測をして下さい!

であれば、上記を行う為に必要なデータは……?

2010年9月から現在(2015/09 上旬)までの、 東急ハンズ全店のPOS取引データ!

ということでした。

今回公開したPOS取引データというのが、多少の加工をしていますが、
テキストファイルにして80GB程度と、たまたまですが絶妙な量で、
みんな大好きMacBook Pro程度のローカルPCのスペックやストレージサイズで、
全体を一度にストレス無くETL(Extract, Transform, Load)をするにはギリギリ、程度のサイズでした。

他細かい実施要項については、スライドを公開してますので、そちらを見て下さい。

Meet-up

9/12 の20名を超えるハッカソン参加者のみなさまのうち、結果を提出して頂いた6組7名様の成果を、
9/29 のMeet-upにて披露して頂きました。
ハンズラボ賞と、オーディエンス賞(ハッカソンに参加してなくてもMeet-upに出席頂いた人の投票)の2つの賞を用意しておりました。
それぞれ、以下の様に評価し、決定しました。

  • ハンズラボ賞 : 売上予測が、店舗×日付それぞれについて、売上実績値を真値とした相対誤差20%以内であった割合にて、50点満点の評価。他、ハンズラボメンバーによるプレゼン、アイデアの評価でさらに5,60点程度。
  • オーディエンス賞 : 各チームの発表について、会場にいるみなさまに各自5段階評価してもらい、その合計値。ハンズラボ賞とは完全に別個に評価。

売上予測の正解を相対誤差20%以内としたのは、
1桁%ではつらいが50%を超えていると正解とは直観的に言い難い、
誤差20%とかなら、現実の小売を考えて、ぶれたとしても上下のぶれを考えたらそこそこ相殺されて、
会社はすぐには潰れないだろう、程度の後付けの根拠となっていますw

売上予測結果

なんと最も正解率が高かった方は、正解率50%をたたき出しました。
参加者の中では、10%正解するのも難しい中、これは驚異的でした。
また、MLのモデル作成は出来たが、締切までに予測実施が間に合わず途中提出の方がいたのですが、
提出分だけの1店舗で見ると7日中6日正解、つまり正解率85.7%の方がいて、ざわざわしましたw

ちなみに東急ハンズは、店舗にいる管理や庶務会計系の社員が毎月翌月の売上予算を日別に計算し、本部に提出しているのですが、
今回の売上予測の正解基準である相対誤差20%以内でジャッジにかけると、正解率はなんと8割に迫る勢いで、
現場感覚すげーな、負けてらんないな、と思った次第です。

売上予測の実施手法

では、参加者がどのような手法で上記の予測をしたのか、紹介していきます。

ETL

参加者みなさんそんなに大きな差は無く、

  • S3->Redshift->ML
  • S3->EMR(Hive)->S3->ML

という感じでした。

MLのデータソースはS3上のCSVかRedShiftであることが必要だったので、
このようなパターンに収束したと思われます。
EMR(Hive)は、S3上のCSVに対してSQL叩けるらしいです。知らなかった。

また、8月のハンズメッセや、12月のクリスマス商戦など、売上が際立っている期間は、
チームによっては異常値として除外している所が多かったです。
異常値として処理せず、時間軸の自明な周期成分を除去することで処理したチームもありました。
フーリエ変換とかラプラス変換とかデジタル信号処理とかいう単語が浮かびますね。

説明変数の決定

お渡ししたデータのカラム数はさほど多くなかったこともあるのと、
Meet-up当日までのやりとりでも変数が多すぎてもつらいという空気が出来ていた認識です。
参加者が使用してプレゼンで紹介していた変数の和集合をとると、以下の様な感じになりました。

  • 店舗コード
  • 売上
  • 過去数日分売上のウィンドウ集計
  • 曜日
  • 祝祭日か
  • 休日かどうか
  • ハンズメッセ期間内かどうか
  • 天気
  • 降水量
  • 店舗最寄り駅の乗車人数
  • 温度
  • 不快指数

思いついたけど使用できなかったと発表があった変数や要素としては、

  • 競合他店データ
  • 床面積
  • 在庫高。震災時の在庫高による売上キャップチェック

というのが出ました。

先の結果と合わせて考えると、
数百以上も説明変数を使用する必要は必ずしもないのではないか?という印象を受けます。

そもそもの原点に立って考えると、東急ハンズの各店舗の売上を予測する、ということなので、

  • 総売上はひとりひとりのお客さんが買ってくれた金額の合計である
  • その日にお客さんが何人来たか
  • 来たお客さんのうち何割くらいが買ってくれたか。入店カウントは結構しているので、来店した人とレジを通った人の比率は概数値で既知である
  • 客単価の平均や分布がどんな感じか
  • etc…

という、小売業界の社員、特に管理職とかだったらそういうこと考えなきゃモグリでしょ?(個人の感想です)
レベルの発想から変数を洗い出し、ブレークダウンして考えていけば、
いたずらに変数を増やしすぎず、でも人間がやるには大変だ、
という程度の数の説明変数に自然となるのではないでしょうか。

例えば、その日にお客さんが何人、というのは、
お客さんの来店理由には、商品指名買い、たまたま来た、などの種類があり、
それぞれのクラスタに対して異なった購買に至る確率があると思います。
指名買いの場合は購買確率が高く、たまたま来た人は普通ですよね。
そして、たまたま来た、という人の人数は、
ハンズがある街を歩いてる人の人数を従属変数に持っていると考えられます。
街を歩く人の内一定の割合の人が東急ハンズという魔窟に吸い込まれ、
さらにそのうち一定の割合の人がうっかりお買い上げになってしまう、という美しい流れです。
これはさらに、日付・曜日や店舗の所在地、
天候や最寄り交通機関の運行状況などを従属変数に持っていると考えられます。

と、こんな風に、誰が考えてもわかりやすい要因を挙げ、それらがどのような変数の関数であるか、
という考えを再帰的に突き詰めていけば、
どのような説明変数を使うべきか、ということが考えられると思います。
実際には上記の様に綺麗に考えることは難しいと思うので、
これも変数じゃね?あーこれは別のあの変数の従属変数だな、のように、
発見的になることもありそうです。

また、天候や最寄り交通機関の運行状況などは重要でありながら、
せいぜい確率的にしかわからないはずなので、
こういった変数をどのように活かすか、あるいは使用しないか、という判断も必要になると思います。

MLのモデルの作成

チームによって若干の違いがあり、大きく以下のように手法が分かれました。

  • 全店共通の1モデル。店舗コードを説明変数に持つ。
  • 1店舗毎の約50モデル
  • 東急ハンズ業態の店舗と、ハンズビー業態の店舗の2モデル(売上規模によって2分)

売上予測の結果は、
店舗毎モデル>業態別モデル>全店共通モデル
の順に正解率が良いチームがはっきりと分布していました。
なので、今回は店舗コードをカテゴリカルな従属変数にするよりも、
店舗毎の隠れた変数を、店舗毎のモデル生成に繰り込んでしまうのが正解だった、
と言えそうです。

可視化

特徴的だった方は、

  • ML->S3->Lambda->Kibana
  • Tableau
  • Elastic Beanstalk + DynamoDB WebApp

でした。
Kibanaやっぱりかっこいいなー、という小学生並みの感想。

また、前述の様に天気は本来確率的にしか予測できないので、その矛盾を解消するために、
天気ごとの予測売上を出すアプリケーションを作った方がいました。

まとめ

データ分析におけるETLにかかる時間の割合は非常に大きく、もちろん今回のハッカソンでもそれは例外ではないようでした。
元データを取り回してMLに投げられるデータを作るに至るまでの苦労が、ほとんどの参加者の発表から伺えました。
普通の統計解析だろうが、機械学習だろうが、避けて通れない道なのだなというのを改めて感じました。

また、機械学習だから大量の説明変数を使えるからといって、対象によっては、無理に増やさなくてもそれなりのモデルは作成可能なのではないか、という印象も受けました。
それはそれで、得られる結果が古来よりある多変量解析と何が違うんだという気もしますが……

また、ハンズの店舗の管理系社員が作成した予算の精度、本当にすごいなというのが、
ハンズラボメンバーの感想です。
在庫高、仕入れや販売の流量などが肌感覚でも帳簿の上でも詳細にわかっているからというのもあるかもしれませんが、
それにしても8割方誤差20%以内の日であるというのはすごいものだなと思います。

ハッカソン、Meet-up 共に、参加者の皆様には楽しんで頂けたようで、
おかげさまで開催してよかったと思えるイベントとなりました。
以下の様に、まとめと感想も書いて頂いております。
Amazon Machine Learning ハッカソン with ハンズラボに参加しました – Qiita

今後も、また何か一般公開のハッカソンをやるかも……?
AWS QuickSight を使ってやるとかも良さそうかなと。早く使えるようになるのを待ってます。
Amazon Web Services ブログ: 【AWS発表】 Amazon QuickSight – 高速で簡単に利用できるビッグデータ用BI(Business Intelligence), 従来型ソリューションの1/10のコストで実現

最後に、今回のハッカソンを共に推進してくれたハンズラボメンバー、
ADSJの皆様、そしてハッカソン参加者の皆様、本当にありがとうございました!

AmazonMLHackathon2015

Pocket