Meister Hackersの技術選定について

外部の仕様についてはいろいろ発信していたり、実際に触ってみることでわかるのだけれども、内部でどんな技術をつかっているのかというところは、しっかり発信しないと伝わらないと思いました。

そこで、今回は、MesiterHackers v1.1.0をベースに内部の技術情報について発信しようと思います、よろしくおねがいします。

バックエンド

Rails on Railsを採用しました。これは、サービスの企画段階で集まっていたメンバーがRuby on Railsを学んでいたため、Rails一択でしたので、議論の余地はありませんでした。

RSpecを書くかどうかは、議論しました。結果的には個人が書きたければ各方針にしましたが、あまりテストを書く人がおらず、結果的にはほぼテストは書かれていません。品質よりもスピードを今回は優先しています。

DBは、PostgreSQLです。とくに、こだわりはありません。

フロントエンド

RailsのSlimを採用するか、Vue.jsを採用するかでもめました。集まったメンバーのうち3人はVue.jsが書けますが、残り3人は書けません。担当をバックエンドとフロントエンドにわけるのではなく、機能ごとに分けて、設計からテストまでを一気通貫して担当してもらう方針は決まっていたため、Vue.jsを導入するかどうかが焦点でした。

Vue.jsとSlimが混合することはどうしても避けたかったです。なぜなら、今後の保守性を考えると、最悪だからです。しかし、結果的にはメンバーそれぞれの裁量でVue.jsとSlimのどちらかを選ぶことにして、統一感のないフロントエンドとなりました。

これは、悩ましいです。保守性はサービスを継続する側の理由ですが、このプロジェクトは各自が自分の技術力を向上させるために、無償でコントリビューションしていますので、自分にメリットがあることはモチベーションがわかないし、無理強いはしたくないです。

いろいろ議論しましたが、各自のコントリビューションのモチベーションを優先して、今回は思い思いの実装をすることになりました。

しかし、開発の後半になってくると、結局Vue.jsでフロントエンドを書かられることが多くなりました。そこで、Slimは廃止して、Vue.jsで書き換えるリファクタリング計画を今後の計画として立てています。

CSSフレームワークは、Bulmaを採用しています。CSSを直書きするかどうかも議論の焦点になりましたが、できるだけ開発のコストを省きたいことと、だれもがCSSを書けるわけではないこと、統一感を持ちたいこと、などの理由でCSSフレームワークを採用することにしました。メジャーなデサインは避け、マイナーそうなBulmaを採用しました。

インフラ

Herokuを開発用と公開用サーバに選びました。はじめはユーザもそんなに多くないだろうし、AWSやさくらVPSはオーバースペックです。Herokuがベストチョイスです。HerokuのReviewApp機能や、Staging環境も設定しました。継続的デリバリーも簡単に設定できたので、採用しました。

また、開発環境には、Docker(docker-compose)を用意しましたので、サクッと環境構築ができました。そもそも、Dockerを知らないひとも半分くらいいましたので、チーム内でDockerハンズオン講座を実施しました。

開発環境

GitHubを使ったプルリク駆動開発をしました。GitHubを有効活用するノウハウを持ったメンバーがチーム内に2人いたことで、スムーズにGitHubに慣れていないメンバーもサポートできました。GitHubの活用は、すべてのメンバーが感銘を受けています。これは大きなテーマなので、記事を分けて誰かが書いてくれるでしょう。ここでは触れません。

また、Slackを利用して普段はコミュニケーションしました。GitHubと連携させることで、強力な情報共有ができました。週1回はオフラインのもくもく回とGoogleHungoutを使ったオンラインミーティングを行いました。

外部連携サービス

Siderを取り入れることで、RubocopとEslintによるチェックを必須かして、コーデング規約に従わないコードはmasterブランチにコミットさせない仕組みを構築しました。

ほかにも、NewRelicによる死活監視、Dependabotによるgemの自動更新など、面白そうなサービスはよく試しました。

まとめ

今回は、技術選定について書きました。チーム開発をすると、個人開発とは違い、好みがあるため、当然意見が衝突します。そういうときは、メリットとデメリットを考慮して、論理的に話し合うことが大切だと、学びました。

以上