By
—

ALL-IN を支える技術

ビジネスバンクグループ CTO の @shoutakenaka です。

「何で開発してるの？」と聞かれて、細かい説明をする時間がなさそうな時は 単に「Rails」と答えているし、 ステークホルダにも「Ruby on Railsというのを使って開発しています！」 としか言っていませんが、 実際には色々なライブラリやプロダクトの力を借りて、ALL-IN は作られています。

今回は、そんなALL-INの開発を支えているテクノロジーについてご紹介します。

Ruby on Rails

ALL-IN のバックエンドは Ruby on Rails で開発しています。

ゼロから開発をスタートした ALL-IN の最初の課題が、コアの部分を何で開発するか、 ということでした。 色々と悩みましたが、開発スピードのプライオリティがかなり高かったので、 僕が使える道具の中で一番スタートダッシュに向いている RoR を選択しました。

この辺りの決断や、その後のアーキテクチャの変遷については、いずれ別の機会に まとめてみようと思います。

AngularJS

ALL-IN のフロントエンドは AngularJS ベースで実装しています。

元々フロントはあまり厚くしないで、できる限り RoR の寄せる方針で設計していたのですが、 要件をまとめていく中でバックエンドには API 提供の役割を担わせて、フロントで結構がっつり 実装した方がよさそうだと判断し、AngularJS を採用しました。

ローカルのリポジトリを見たら、Backbone.js とか Knockout.js など、いくつか試したブランチがあって、 何を採用しようか悩んでいた形跡がありますw

結局、フルスタックなので色々組み合わせなくても一通り必要な機能が揃うことや、 書き方の縛りが割と強く、コーディングスタイルガイドでルールを たくさん作らなくてもある程度書き方が統一できそう、という辺りを重視して AngularJS の採用を決断しました。

Grape

RoR の部分は一部の例外を除き、簡単な HTML を返す役割と、 JSON のやり取りをする Web API の役割をになっています。

その Web API の部分の構築に Grape を使っています。

前に RoR の素のコントローラで Web API を実装したことがありましたが、 コントローラで頑張るのに比べると、 API 実装のためのシンプルな DSL を提供してくれて作りやすいです。

Rabl

ActiveRecord のデータを JSON に変換するのに使っています。

以前のプロジェクトで Web API を作った際、JSON への変換 (アプリ側では Hash への変換ですが) を ActiveRecord のメソッドとして実装していたことがありましたが、 ビジネスロジックと混ざりモデルがfatになってしまうという課題があったので、 今回 Grape とセットで採用しました。

悪くはないですが、例えばモデルのステータスによって JSON フォーマットを少し変更したい場合など、 Rabl テンプレートの中で分岐をして出しわけ処理をやっているのですが、 こういう条件付きのレンダリング処理をやるところが 少しわかりにくい実装になるなぁ、というのが悩みです。

Thinreports

帳票作成に使っています。

昔、猛烈に使いにくい帳票ツールに悩まされたことがあって、 それ以来できるだけ帳票ツールは避けてきたのですが (PDF生成が必要になったら wkhtmltopdf を使ってた)、 今回のシステムでは wkhtmltopdf だと表現するのが厳しい レイアウトの帳票がいくつかあったので、 初めて Thinreports を採用しました。

Chrome アプリとして提供されているデザイナ (前はスタンドアロンのアプリだったのですが いつのまにか Chrome アプリ化されてました) が使いやすく、アプリ側も Hash で 埋め込むデータを用意するだけなので学習コストが低くていい感じです。

Resque

オンラインバッチ処理に使っています。

処理をキューイングして、後でバックグラウンドで走らせることができるライブラリで、 キューを定期的にチェックして、ジョブがキューイングされていたらすぐに実行してくれます。

メール送信や帳票生成の処理で活躍しています。

Whenever

バッチ処理のスケジューリングに使っています。

わかりやすい表記法で cron の設定ができるようになります。 決まった時刻に実行する必要のあるバッチ処理は Whenever、 キューイングしたらできるだけすぐに実行してほしいオンラインバッチ処理は Resque、 という感じで使い分けています。

RSpec

バックエンドの単体テストに使っています。

昔 .NET の開発をメインでやっていた時は xUnit (Visual Studio Unit Test とか NUnit) を使っていたのですが、Ruby を使い始めた時何気なく触ってみた RSpec がすごく気にいってしまい、それ以来ずっとRSpec を使っています。

そんなわけで、特に他の選択肢は考えず、このプロジェクトでも RSpec を採用しました。

Shared Example や Shared Context、Context がネストできるあたりがお気に入りです (xUnit を使っていた時なんか書きにくいなぁと思っていた部分が解消されました)。

Capistrano

サーバーへのデプロイに使っています。

Rails デプロイ を読んで使い方を知ってから、 Rails でプロダクトを作る時は必ずセットで Capistrano を使っています。

コードの更新、DB マイグレーション、アプリケーションサーバーや Resque の再起動、 crontab の書き換え (Whenever の設定反映) などを簡単な設定だけでできるので、 とても重宝しています。

エンジニア募集中！

ビジネスバンクグループではエンジニアを募集中しています。

弊社が採用しているテクノロジや開発環境に興味を持った方は、 ここから是非エントリー を！