144Lab の今津です。 ここ1年少し、うんこボタンの開発に携わっています。
うんこボタンのウェブアプリを開発することが決まった時に、どんな風に進めようと思ったのか、なぜそう考えたのかというあたりのお話を書いてみます。
まずはプロトタイプからだったとしても、サーバーサイドの開発を始めるにあたって、決めることは色々あります。
などなど。 当初は比較的短い期間で最低限の機能を持ったウェブアプリとボタンデバイス用のHTTP APIを開発する必要がありました。だから開発のスピードを保てることが大事なポイントのひとつ。 後から変更することは充分ありえるというつもりで、まずは最初のプロトタイプの開発を対象に考えました。
プログラミング言語
僕らが得意とするプログラミング言語としては、次の2つがトップ2。
- Python
- Go
僕にとっては、ちょっとしたプロトタイプを書いたりするにはPythonの方が速いんだけど、性能や動作環境を作ることを考えると、最終的にGoに持っていきたい、ということは最初から考えていました。
ウェブアプリの構成とかフレームワークとか
ウェブアプリの作りとして、HTMLを生成する部分をサーバー側でやってしまうと、テンプレートとかの移植時に考えることがすごく増えそう（テンプレートエンジンによってできることが違うし、ましてプログラミング言語を変更するとなるとそれはもう）だなあと思っています。これはホントにやりたくなかったので、HTMLレンダリングはサーバー側ではしない構成にすることは最初から決めていました。
HTMLレンダリングをしない分、クライアントはJavaScriptを使った今風なものにしたいと思っていました。これに関してはずっとうんこボタン開発を一緒にやってもらうことになる、ルンコシステム木下さんの提案をいれて、Vue.js＋Vuex構成にすることに決めました。 HTTP APIサーバーはGo言語を使ったRADIUSサーバー開発でもやってきたことだったし、分担して開発することで、スピードも稼ぎやすいかなという思惑もありました。
ということで、HTTP APIのサーバーと、HTML+JavaScript+CSSを別途サーブするという構成に決めて、HTTP APIサーバーはPythonで書き始めることになりました。
ちなみに採用したフレームワークはBottle。 URLのマッピングとリクエストを扱うユーティリティが必要最低限揃っていて、APIサーバーをささっと書くのにはとても適していると思ってよく利用しています。
システム構成
普段社内システム等で利用していることもあり、AWS上で動かすことは決めていました。 CloudFront、API Gateway、S3、EC2（ELB）、RDS（MySQL）あたりを使うことになるんだろうな、という合意をしたところで、もうひとつAmazon Cognitoを候補に挙げました。
うんこボタンでは、比較的初期からLINEログイン、Messaging APIの利用を想定していましたが、「どうせ他の認証方法も欲しくなったりするんじゃないの？」という点と、単純に「使ってみたかった」というのもあって、採用してみることに。
「使ってみたい」は結構大事な動機じゃないかなと思うんですよね。 対象が目的にそうものなのであれば。
開発手法のこと
もうひとつやってみようと思っていたのは、「紙から始めるプロトタイプを使って開発のサイクルを回しながら作っていく」こと。 紙から初めて、徐々に実際に動作するプロトタイプに進化させつつ、完成度を高めていく、というようなアレです。
でも、残念ながらこれは早々に挫折することになります。
ということで
「ところでうんこボタンって具体的に何」 何を使って開発するのかを決めたので、さっさとコードを書いていきたいところではありますが、作るものをハッキリさせないことにはどうにもなりません。 次回は、最初の仕様を決める時に考えたことなどを書いてみようと思います。
