読者です 読者をやめる 読者になる 読者になる

zenhack 2016 fallで僕らはどのように開発を進めたかその1

先日、鎌倉は建長寺で開催された、

禅ハック2016 Fallにメンバーを集めて参加してきました。
www.zenhack.jp

チームkoiki
f:id:takahiro-f:20161004200330j:plain


結果優勝することは出来ませんでした。
しかし、技術的にはかなり様々なブレイクスルーを短時間の内に経験し、
チームとして、アウトプットしたプロダクトに満足することが出来ましたし、達成感もありました。
また、一緒に参加していた別のチームの多くの方々から良い評価を頂けたのも嬉しい点です。

この記事では、
・どのように僕らが作業を分担して開発を進めたのか
・プレゼンではお話出来なかったより具体的なarchitecture
・課題と解決、反省点(これは次回の記事で)
など、まとめていきたいと思います。
※今回はほぼ備忘録的な記事になっています。すみません。

前置き

f:id:takahiro-f:20161004195321j:plain
まず、建長寺でやれるってことを知らなくて汗
お寺でプログラミングだー!って感じなだけだったんですが、
いざ行ってみたら、まずお寺すげー!ってなりました。
歴史、由緒あるお寺の中で、開発に集中できたこの経験は、
禅ハックでしか味わうことが出来ないものだと思います。

僕らがつくったもの

最初に、僕らが作成したプロダクトのデモを紹介します。
今回、「SPOT4U」というWebアプリを作成しました。
f:id:takahiro-f:20161004195657p:plain
f:id:takahiro-f:20161004200031p:plain

このアプリは、今自分の近くにあるスポットの写真が紹介され、

・興味がある、行ってみたい所を右にスワイプ(興味がないものは左)
・一定数見た所で、自分の興味がある場所のリストを表示できる
このリストには、

・自分の現在地からの距離
・スポットの名前(とれる場合)
・現在地からのルートへのリンク

といった情報が表示されます。
(youtubeにあげたものでは、スポットの名前が取れてないんですが、
これはnabがコード直せば再びでるようになるはずです笑)

youtu.be


簡単にいうと、現地で「次どうする…??」みたいなことになった時に使って、
身近にあるいけてるスポットを見つけられるっていうアプリです。

発表時のスライドは、speaker deckにあげていますので、
こちらも興味があればみてみてください。
speakerdeck.com

Zenhackのタイムスケジュール

今回のzenhackのタイムスケジュールは、
Schedule 2016 - ZenHack
にも書かれていますが、このようになっています。

1日目
09:30 建長寺の門の前に集合(北鎌倉駅から徒歩15分) まとまって入場&受付スタート
10:00 オリエンテーション、ルール説明、インプット
11:30 チームビルディングワークショップ
13:00 ランチ
13:45 ハック開始
15:00 おやつ
18:00 夕食&企業プレゼン
19:30 入浴
20:45 就寝準備
21:00 就寝

2日目
03:00 起床
03:20 本堂集合
03:30 座禅
04:10 ハック再開
06:00 朝食(お粥・建長寺提供)
07:00 ハック再開
08:30 おやつ
12:00 ランチ
13:15 ハック終了、会場準備
13:30 発表会
15:00 審査、休憩
15:30 表彰、総括
16:00 集合写真撮影
16:30 終了・解散

この中で、プロダクトを作ることができる時間は下記の通りです。

1日目
11:30~13:00 案出し
13:45~18:00 4.25h

2日目
04:10~06:00 1.83h
07:00~12:00 5.00h
12:30~13:15 0.75h

合計 案出し+約11.83h
今回、僕らは5人で参加したので、実作業時間は60hといった所です。

案出し

事前に各々少しアイデアを考えていたんですが、ブレストが始まって、
結局その場で考えたアイデアをベースにして作りました。
考えたアイデアの中から2案を各々がピックアップして、
それを参加者みんなで見て回って、いいと思ったやつに★をつける、といったことをやりました。
その中で、うちのチームで一番票を集めたのは、
kojiroくんの
・写真を見せた時の「心拍数」を測定して、その写真がいいかどうかを判定し、
興味がありそうな場所、おすすめの場所を教えてくれる
というものでした。

ここから、実際に作るプロダクトを考えようとなった時に、
・「心拍数」はかれるデバイスないやん
・これでやりたいことは、余計な情報を見ずに(写真だけみて)
ユーザが純粋に良いと思う感覚をもとにレコメンドできること
みたいな話になって、SPOT4Uの原型が朧げながら出来たという感じです。

フリックするUIを選択したのは、
心拍数を測る、みたいにユーザにアクションなしで自動で判定することはできないまでも、
より多くの情報をユーザが短時間に興味があるかないか判断できるようにしよう
という所から来ました。

また、最初は探したいスポットを入れて、
その場所の近くを検索するという案もありましたが、
ユースケースを限定して、よりそのアプリを使う目的を明確にしよう
という所と、
UIのステップ数を可能限り減らす
ユーザに情報入力させたくない
という所から、
今いる場所の近くを探すという使い方に限定してまずはアプリを作成することに決めました。

メンバー構成・役割分担

メンバー構成

下記のメンバーで参加しました。
今回、全員エンジニアなのと、僕がデザイン周り好きなこともあって、
自分がデザイナーっぽい立ち位置のロールをしました。
受付でエンジニアですか?デザイナーですか?って聞かれて、
「デザイナーです。」って答えた時に新たな自分になった気がしました笑
個人の仕事ではやってたことは一応あるんですが。

  • taka66(僕) / Design,HTML,CSS,JS(モックアップ) + プレゼン資料作成
  • sideroad / FrontEnd(SinglePageApplication(React.js)) + interaction animation(js) + Infra(Heroku)
  • nab / API
  • kojiro / API + Infra(AWS)
  • okame / Photo search Engine

役割分担

後ほど詳細を書きますが、今回役割分担はかなり上手くいったと思っていて、
上記の作業時間で、誰かの手があいたり、ブロッカーの作業が発生するといったことがほとんどありませんでした。
これは、作業開始時に各プロダクト(FrontEnd/API/Engine)の役割分担を明確にして、きっちり分けたことが良かったと思っています。
結果としてEngine周りの細かいロジックは分かっていない所もあって、近々お互いの実装について説明しあうことが必要だなと思っています笑

アプリケーション構成

上の役割分担からおおよそ構成もつくかもしれませんが、アプリケーションの構成は下記のようになっています。
f:id:takahiro-f:20161004195805p:plain

SPA(フロントエンド)

・フロントは、React使ってシングルページアプリケーションとして作りました。
最終的なアプリの機能・使い方としてはネイティブアプリで作っていいな、という内容でもありましたが、
・時間内にサイトを公開したかったこと
・各人のスキルセット
を考慮して、このような選択をしました。

API(バックエンド)

APIはnab,kojiroの2人がrubyがいいっすってことだったので、rubyでやってもらいました。
アプリをきっちり分担したことで、各プロダクトで各々が得意な構成で作ることができました。
kojiroくんが持っている環境(AWS)があったので、そこにAPIをのせることになりました。

写真を集める

・最後に写真を集めるところですが、ここはみんな知識がそんなに無かったんですが、
ここは万能エンジニア、頼れるもと同期のokameさんの力を借りまして(というか任せて)、実現してもらいました。

Hackathon期間中の成果としては、
1)Flickr,Twitterから位置情報つきの画像を集める
2)FacebookのGraph apiで位置情報からスポットの場所を特定する
ということができるようになりました。

Flickr,Twitter,FacebookAPIなどをリクエスト時にcallするという方法もあったんですが、
できればレコメンドしたいねって話になった時に、
一回それの解析やるためにデータとって解析するところは別で作ろうって話になり、スクレーピングするスクリプトを作ってもらいました。
実は結果としてレコメンド組み切る所までの実装は出来なかったので、ここの実装、仕組みについては、もう考えようもあったなと今は思っています。

IBMのWatsonの中にAlchemyVision apiという機能があって、
画像のカテゴリとスコアを返してくれるAPIがありました。
これも使えたなー、、とあとから。
http://qiita.com/knao124/items/60dc430fc31bf85b0e60#2-2-alchemyvision

InstagramAPIももちろん使いたかったのですが、申請が間に合わず。
こういうAPIセットはhackathon時は事前に用意しておくべきですよね、、(毎回思うんですが笑

ということで

フロント2名
バックエンド2名
エンジン1名
っていう分担です。

PaaS

PaaSは、お互い使い慣れた環境でやってしまおうということで、Heroku,AWS上でそれぞれのアプリを動かしていました。
オリエンテーション時では、スポンサーのIBMさんがBluemixの紹介をされていたので、
次こういった機会があれば使ってみたいな、という話をしていました。

hackathon

さてさて、あとは時系列別にどんな感じでアプリが出来ていったのか
ということをまとめていきたいと思います。
とはいえ、他のロールの進捗を完全に把握しているわけではないので、
近々みんなでもう一度集まってヒアリングしたい気分です笑

コミュニケーションはslackで行っていました。

1st(13:45~18:00 4.25h)

最初の30分〜60分位は
・作るもののイメージを固める話し合い
・アプリの大まかなアーキテクチャ
・役割の確認
をしていました。
その後、各自作業を開始しました。

taka66(僕)

・なんとなくのUIの絵を描いて、話し合い with sideroad
IllustratorでUIデザインを作成(15:30に一度目のデザイン案が完成)
・最初にTOPページを決めちゃってベースのHTML,CSSを作成(16:16に最初のpush)
・その後他のページのHTML,CSSの実装を始める(途中まで)

sideroad

・SPAのベースのプロジェクト作って、herokuにdeployできるようにする(~14:20)
API側のインタフェース要件を考える(~14:40)
・TOPページのHTML,CSSをあてる
・ベースの作り込み

nab + kojiro

APIのベースプロジェクトを作る
・sideroadとAPI要件のすり合わせ
AWS上にRubyのアプリをdeployできるようにする(~15:40)
・画像LikeするAPIの作成(~16:21)
・画像を登録するAPIの作成(~17:29)
・レコメンドAPIの作成(途中まで)

okame

・写真とるのにいいAPI探してAPI仕様の確認をする
twitterから位置情報付きの写真を集めるスクリプトの作成
・スクレーピングしたデータの投入(~17:49)

そのあと、お風呂に入る時間の合間の時間が少しあったので、

taka66

・最後のページのUIがいけてないことに気づいて作り直す(~20:55)
f:id:takahiro-f:20161004195334j:plain
から
f:id:takahiro-f:20161004200031p:plain

nab

facebookapiで座標から場所特定できることに気づく(~20:47)
みたいなことをしていたみたいです。

2nd&3rd(04:10~12:00)

座禅後に始まったハックの時間ですが、禅の効果なのか、、、
04:00-08:00位に、めざましく進捗した感じがありますw
07:00くらいから、mockではなく、実際にデータ使って一通り動かせるようになってきて、
エンジニア勢はみんなテンションが上がってました。
やっぱり、エンジニアにとって、動くものを作り出せたタイミングのこの気持ちは何にも代えがたいです。

taka66(僕)

・バグ修正
・HTML,CSSの改善
・結果表示のHTML,CSSの実装
・Like用のHTML,CSSの実装
・アプリ名とロゴデザインをどうしてもうやりたくて始める笑(~05:15)
・フリックアニメーション用のアイコンの作成
・TOPに表示する為の画像の撮影、動画の撮影+加工
・デモの練習
・プレゼン資料の作成、及びプレゼン内容の作り込み(たしか09:00位からやってました)
結果には結びつかなかったのであれですが笑、
個人的に、これくらいの時間からプレゼン資料の作り込みと、発表内容の整理が出来たのは良かったです。
発表時間が5分と短かったので、その時間の間でデモと発表を終わらせる構成を作っていました。
そのおかげで、最後のプレゼンはデモから初めて、プレゼンの完了まで、時間通りに終わりましたし、
質問対応用のスライドも使えたりして、いろいろ準備が役に立ちました。

sideroad

・フリック用のアニメーションの作成
・結果表示のHTML,CSSの当て込み
・現在地からの距離の表示
・load用アニメーションの作成
・ロゴの反映
・バグ修正

nab + kojiro

Facebookapiで座標からスポット名を取得できりょうにする(~05:16)
Googleのcloud vision apiを試す
・クロスオリジンとかの対応
・cloud vision apiでタグ取れるようにする
・プレゼン用の素材写真撮影被写体(nab)
・バグ修正

okame

・システムの改善
・問題がある写真を取り除く(~05:12)
Flickrからもデータを集めるようにする(~07:13)
Flickrからタグを取れるようにする(~08:56)
・スクレーピング

4th

ここは細かい改善をしてました。
最後までコードpushしてdeployしまくった結果、終了10分前くらいまでアプリ動かなかったっていう笑

とりあえず最後に

振り返りとかもあるんですが、ここまでまとめるのに疲れてしまったので、
こちらは後ほど記事を追加したいと思います!
思い返しても楽しかったなー。体力的には疲れたし、畳の上で作業してたら腰が痛くて、、
(姿勢が悪いから
あとは、slackとか使うとある程度のログが残るので、見返すのに最適ですね。