第一回tab APIハッカソンに参加してきました

8/25に開催された、http://tab.do/ のAPIを利用したアプリ/サービスを開発するハッカソンに参加してきました。
tab API ハッカソンお申し込みフォームで募集されていたものです。
午前10:30に会場集合(ハッカソンとしては早い)、午前中にアイディアソンらしいアイディア出しを行い、参加者のやることを決めて実際に取り掛かるのは午後というスタイルでした。

少々遅れて会場着(すみません)

前日にAPIをざっとは読んでおいたものの、作るものはあまりしっかり決めずに会場へ到着。他の方の自己紹介を伺っていると、元々tab APIを使っていらっしゃる方や割と中の方など、アウェイな感じ((((；ﾟДﾟ)))

あ、tabのステッカー頂きました(^o^)

当初からローカルな情報をうまく教えてくれる仕組みを作りたい、と考えていたのですが、アイディアソンで他の方のネタを伺っている中で段々とネタが固まっていき結局作ったのはこういうものでした。

12.08.25 tab api hackathon from Kei Nakazawa

反省箇所などいくつか。

私の場合ハッカソンでは、サービス面・技術面共に何かしら自分の慣れてるエリアを活かしつつ不慣れなエリアの勉強機会にする、というようにしています。今回触ってみた不慣れエリアは以下ようなものでした。

OAuth 2.0(なにげにごく一部の環境でしか使ったことなかった)
→.NET用、PHP用共にそれなりにしっかりしたライブラリが提供されているので特に問題無し。プロトコル自体で謳っているように、OAuth 1.0よりもシンプル。ただ、アクセストークンの有効期間が短め(デフォルトで900秒)&期限切れ時にはリフレッシュトークンを用いて認証/認可状態を継続するというフローについては触れなかったので別の機会にやる必要がある。
twitter bootstrap(身の回りで使ってる人は結構居るけど自分では使ってなかった)
→ボタンの装飾ぐらいにしか使わなかったし、スマフォ/PC両方で使いやすいUI作りというあたりまで踏み込んではいないけれど、一応使った。割と直感に反しないクラス切りがされているので、結構良い感じ。サクサクと知識を広げていけそう。この先数回機会あるごとに使っていけば良いかなーと。
サービス全体を.NET系(ASP.NET)で書いてAWSで動かす
→System.Data.SQLiteのバイナリイメージが不正と言われ問題解決出来ずにかなり時間をかけてしまった。
配布されてるSQLite.dll自体は64bitイメージのはずだし、もし32bitとしても.NETコード側の出力を32bit/64bitそれぞれ指定して尚みてもダメだったのが解せない。この方面は、やはり実プロジェクトで使ったことのない環境なのでひとつひとつハマっていってしまう。こればっかりはしょうがない。
一方で、ODBC経由でRDS上に立っているMySQLへアクセスしてみようかとも思ったのだけどODBCのMySQLドライバを用意する時点でバイナリイメージの問題がSQLiteと同様に発生する可能性がそれなりにありそうだったので避けた。

時間が不足しそうになったらPHPへフォールバックしてガンガン書けば良いという想定のもと.NET系の実験をやっていたので、失敗は失敗で一つの成果かなと。今回やったVisual Studioに統合されたAWS SDK経由でのインスタンス設定、デプロイあたりはこの先にも生きそうだし(Elastic Beanstalkのテンプレートを立ち上げ時点で細かくいじれるのかは検証出来なかった)。

ゆくゆくはWindowsインスタンスを用意せずLinux+Mono系でASP.NET利用するモデルを確立したいと考えてるので、この方面のトライアルは引き続き行なっていこうと思います。

そして時間的余裕がかなり無くなり最速構築出来る環境で作った結果、こうなりました。

サーバOS: Ubuntu 12.04.1
Web/アプリケーションサーバ: Apache2.2+PHP5.3.10
使用ライブラリ: PHP-OAuth2, facebook-php-sdk, Twig

tab API自体について感じたこと

割としっかり作られてる。単機能ベースで不足を感じることはほとんど無かった。複数種類の画像URIも用意されていて、結構楽
ただ、その分レスポンスサイズが大きくなりがちかも。必要なフィールドのみに取得対象を絞り込む機能とかあれば良いかな
この先について、だけどtab APIリファレンスに各APIの更新履歴が付くと開発者の追従面で便利そう
プライバシーに配慮した上で、ユーザのロケーション履歴を取得&API利用者が何らかの形で使えるようになると良さそう
ユーザの利便性を考えると1つのオペレーションにtab APIコールが5回以上必要になりそうなものもあり、ネットワーク的に離れた場所(herokuとか)から使う場合にはコールのバッチ化がサポートされてると嬉しそう
現状は読み出し系、書き込み系、個人情報といったフルセットがひとまとまりになっているけれど、OAuth的にはもう少し細分化してユーザがアプリに対して与える権限を管理出来るようにしたほうが良いのかもしれない。まだ早いかもしれないけど、カジュアル化に伴ってリスクが増大するプライバシー問題をなるべくユーザ・サービス提供者共に不利益なく解決するためにも
サービスに対するプッシュ型のAPIもあると良いかも。ただ、OAuthで付与する権限をもう少し切り分けてからのほうが良いかも

頓智ドット社からメンター的に参加頂いたエンジニアの方には、実装中に出てきた疑問へ即答頂けて結構良いペースで実装を進めることが出来ました。

他参加者の方もそれぞれぶっ飛んだものを作られてて面白かったです(多分頓智ドット様の公式blogに公開されると思うのでここでは割愛します)。

なにかっつーと、楽しかったっすヾ(*´∀｀*)ﾉｷｬｯｷｬありがとうございました。
是非次に開催されることがあれば呼んで下さいまし。