(おことわり)
この記事は、弊社のOrganization を利用して、社内サービス開発にScala+PlayFrameworkを導入するにあたっての作業内容や試行錯誤を記録した連続投稿になります。
基本的には内容が正しく、かつ読み手に有益な情報になるように配慮しておりますが、どちらかと言えば 社内での情報共有 を主目的としているため、
- まとまりのない情報の羅列
- 正確に検証されていない情報 などを記載することもあります。予めご了承ください。
これまでのあらすじ
- [第1回] 社内開発にScala+PlayFrameworkを導入したい
- [第2回]←いまここ
今回は、環境構築に当たっての事前情報の選定を行いました。
まだ実際に環境構築を実施していないため、*内容に不備がある可能性もある事 をあらかじめご了承ください！
【1】Play Frameworkのバージョン選定
下手に最新バージョンを選ぶと怖い・・・というRailsの例があるので、現行の最新である2.5.x系でで本当に良いのかチェック。
参考にした記事
【JavaでPlayFramwork2.4.6】プロジェクト作成 前編 | 株式会社ジェニシス
技術開発事業部blog
結論：2.5.x系の最新版を使う
- そもそも公式サイトの仕組み上、過去バージョンを使用するのが困難な仕組みになっている
- 2.4->2.5はそこまでドラスティックな変更ではないっぽい
- と言いつつ、結構変更は出ているので、2.4の技術記事を読むときには注意する。差分を熟読＆ブックマーク。
[トピック]Dependency Injectionn(DI, 依存性の注入)
あんまり知らなかったのでちゃんと調べておく。
- 主にテストコードの書きやすさを意識した実装のデザインパターンの事。
- ScalaがDI推進の流れにあるらしく、Playの内部実装がDIパターンで書き直されるbraking-changeなリリースが頻発しているらしい。
【2】Scalaのバージョン選定
結論：結論：2.11を使用
Play 2.3 and 2.4 supported both Scala 2.10 and 2.11. Play 2.5 has dropped support for Scala 2.10 and now only supports Scala 2.11. There are a couple of reasons for this:
とあるように、2.11に正式対応しているため。2.12は2016年11月リリースなので時期尚早と判断。
【3】開発環境・デモ環境構築
デモ環境・・・他の人に動作を見てもらうための環境の意です
-
結論として、AWS EC2でdev環境を作成して、個人開発とデモ用を兼ねることに。
- まだ1人開発なので、下手に開発用とデモ用を分けていちいちデプロイするよりもこっちの方がスピーディ
- 最初は多少環境構築がdirtyになっても気にせず突っ走る。ある程度慣れてきた時点で、ちゃんとサーバー構築手順を考えてステージングとか正式な環境を作る。
- vagrantでのローカル環境も最終的には必要だと思うが、最初からvagrantを使うと、amazon linuxとCentOSの違いを吸収するために、最終的にサーバー構築手順を二つ作ることになり、かなり面倒なので、AWS環境が安定するまでは見送り。
- 本当はぼちぼちDockerに移行したいけど、さすがにいっぺんにあれこれ導入するのは厳しい
- 本当はぼちぼちDockerに移行したいけど、さすがにいっぺんにあれこれ導入するのは厳しい
- ビルドを行う場所とか、実際のデプロイ手順についてはおいおい考えていきます（実はあんまりJava系のビルド運用に詳しくありません・・・。Play自体はコンパイル不要を謳っていたはずので、そこまでネックにならないと信じていますが、使ってみないとなんとも言えません）
【4】エディタ
-
Atomを使用する。
- いろいろな人やサイトに、IntelliJ IDEAをお勧めされるけど、他言語の開発と並行する可能性が高いのと、そもそも個人的にIDEっぽい機能をあまり使わないので。
- 同じ静的型付けのGoとかもAtomでやってましたが、ゆるーい補完機能でなんとかなってしまいました
- ちなみにremote-syncをつかって、SSH接続したサーバーと直接ソースコードを同期して、ビルドはサーバー上で行います。この辺りは他のプロジェクトでも実績があるので問題ないはず。
- Scalaのためのプラグインとかはあんまり考えない
- 必要だったら入れていくイメージで、プラグイン選定に時間はかけない
もし詳しい人がいたらアドバイスいただけますと幸いです・・・。
次回はいよいよ環境構築の実務へ・・・。