HTML5ベースの業務アプリケーションを開発するにあたり、開発環境を想定しています。業務アプリケーションですがセキュリティを確保することによりオープンな環境を利用することが出来ます。概要図を示しその役割についてまとめると共に悩んでいる部分をメモします。
今回は個人的な見解のみの内容です。不快に思われる方がいらっしゃいましたら申し訳御座いません。
またソーシャル系のお仕事をされている方には意味不明な内容かもしれません。
概要図
全体的な概要図を示します。これにタスク管理で使用する Redmine on AWS が加わります。
AWS に関してはアプリケーションサーバに対し ssh や デジタル認証、VPCなどを利用することでセキュリティレベルを高くすることが出来ます。もはや AWS を利用しない選択肢は無いと個人的には考えています。
よく外部にリソースを置くのはということを言う方がいらっしゃいますが、社内にリソースを置いた場合のリスクと比較した場合どうでしょう？むしろ AWS 上の方が安全ではないでしょうか？例えば、AWS はどこにデータセンターがあるのか明らかにされていません。AMAZONの社員でも分からないそうです。
開発機
開発クライアントですが、Web開発をしますので Windows ではなく Mac のほうが生産性は高いです。クライアントのオペレーティングシステムが何であるかはあまり問題になりません。むしろ様々な道具を利用するときに利用しやすいものを選ぶべきと考えます。
ただ、納品するお客様は Windowsマシンを使っていますので、テスト工程やフィジビリティ調査を行う要件定義では Windowsマシンは必須です。これはスクロールバー等の表現方法がオペレーティングシステムに依存しているためです。
フロント開発言語
語弊はありますが、フロント側を開発する言語は
です。ただ生産性を考えると次のアイテムを取り入れるべきと考えます。
- Sass.
- Compass
- CoffeeScript
HTML5 になり以前に比べフロントでの開発ボリュームが HTML4.01に比べ多くなったと思います。特に CSS に関してはレスポンシブルデザインやベンダープリフィックスにより３倍、４倍のコーティング量になったと思います。出来ることも増えましたので Sass、Compass のような言語は利用すべきです。
CoffeeScript の印象ですが、コーティング量を減らせるということよりも JavaScript の変なクセを吸収してくれる言語という感覚です。
業務ロジックを直接 JavaScript で記述したとしてもユニットテストロジックは CoffeeScript で記述するというのは良い考えではと思います。
フロント開発基盤
フロント開発基盤ですが Yeoman 若しくは Sencha を利用するのが最も良いと考えております。Java をやられている方はよくご存知だと思いますが Maven や ant のような機能を想像していただけたらしっくりくると思います。
Yeoman は node.js ベースですのでWebアプリケーションも搭載されています。本番では J2EE になりますがモックアップの開発、本番の画面開発には最適です。
単体テストの実行も Yeoman 上で行います。単体テストツールは QUnit、Jasmine 等色々存在しますが私は Jasime を利用しています。
Yeoman の話を致しましたが Sencha、spnejs の場合はオールインワンの構成になっておりますので残念ながら Yeoman の出番は無いです。Yeoman を利用する場合には backbone や AngularJS を使い場合に有効です。
業務アプリケーションでは、コーティングの難易度を考慮して Sencha か Yeoman (backbone) を選ぶのが吉と思います。
バックエンド開発基盤
ここ１０年間不動の従来通りの構成を選択します。
データベースに関してはライトに利用できるものを選択します。今回は SQLite を利用します。アプリケーションサーバも同様に今回は Jetty を利用します。
エディタ
エディタについて何でもよいが回答です。好きなもの、自身が一番生産性が高くなるものを選ぶべきです。
バージョン管理システム
バージョン管理システムとしては git 及び github のプライベート領域を利用します。git は分散型のバージョン管理システムであり Subversion の中央集権的なバージョン管理システムとはポリシーが異なります。
git の状態は
- Working Tree
- Index
- Repository
があります。この３つの状態はクライアントにあります。そして github に共有リポジトリを置きます。都合４つの状態があることになります。そして、いわゆる commit ですがクライアントにある Repository に状態を確定させるためのものです。
commit ということですので当然ユニットテストは完了しておかなければならないということと同値と考えます。更に考えると Jenkins のような CI（継続的インテグレーション）ツールの存在が気になります。ここでユニットテストを行う意味を明確にする必要があります。私の考えでは必要ないが回答になります。
継続的インテグレーション
git のような分散型バージョン管理システムを使った場合、中央集権的な CI ツールの存在については用途を見直すべきと考えています。
もし CIツールにUnitテストを行わせた場合、git commit、git push と分かれている意味があるのか、バージョン管理システムを分散型にする意味があるのかを考える必要があります。
最後に
HTML5(CSS, JavaScriptを含む)の技術が進みつつあり、クライアントモジュールの実装量が増大されていますので、開発環境、開発スタイルも見直すべきと思い記載させていただきました。
やはりプログラマがもっとも大事にすべきことは開発環境ではないかと考えています。そういった意味も一度自分が使っている環境を見直すのも良いかと思います。
