【JavaでPlayFramwork2.4.6】プロジェクト作成 前編

株式会社ジェニシス　技術開発事業部の遠藤　太志郎(Tacy)です。

業務都合によりPlayFramworkを始めました。
ここまでの下勉強により、PlayFramworkのバージョンは2.4.6にすることにしました。

では、いよいよプロジェクトの新規作成に行ってみましょう。

Activatorのダウンロード

さて、PlayFrameworkの最初は「Activator」という管理ツールのダウンロードから始まります。
ダウンロードサイトはこちら。

• https://www.playframework.com/download

しかしですね～、ここで一つ、驚きの事実が発覚します。

これね、2.2、2.3、2.4、2.5と色々とリンク揃ってるでしょ？
2.3～2.5は全部同じなんですよ。
何でこんなことになっとるんじゃ！！
ともかく、「よっしゃ。俺は2.4.6を使うから2.4.6をダウンロードするぞ！！」なんて指定には何の意味も無いのでどれでもいいから目に入ったヤツを適当にダウンロードしたってください。

しかし、2.2以前は違います。
前回の記事でPlayはバージョン毎の差異が結構あって、特に2.2と2.3の間の隔たりが大きいと書きましたが、その一番の理由がコレです。

「Activatorは2.3以降だけ。2.2以前はActivatorではない」

2.2までは「Playコマンド」っていう旧体系のものなのですね。

なのでコマンドプロンプトで「Play ……」ってやっているサイトが出てきたら、それは古い情報です。
2.3以降はこのActivatorコマンドを使用します。

Activatorのインストール

インストールについて特記事項は無いのでサラリと済ませましょう。
ダウンロードしたファイルを解凍して適当に置き、binフォルダに環境変数でパスを通せばＯＫです。

公式サイトにあるように済ませて下さい。

• https://www.playframework.com/documentation/ja/2.4.x/Installing

プロジェクト作成

Activatorにパスが通ったらプロジェクトの新規作成が可能になっています。
プロジェクトの作成は簡単です。
わざわざこのブログに記述せずとも公式サイトを見てそのままでＯＫかと思いますが、一応簡単にご紹介を。

• https://www.playframework.com/documentation/2.4.x/NewApplication

プロジェクトを作成したい場所に移動し、コマンドプロンプトで「activator new」とすればプロジェクトの作成が始まります。

• 1) minimal-akka-java-seed
• 2) minimal-akka-scala-seed
• 3) minimal-java
• 4) minimal-scala
• 5) play-java
• 6) play-scala

「akka」というのはTypesafeが開発している並列分散フレームワークのakkaのことです。
並列分散？
つまり、サーバを１台、２台ではなく、ズラッと沢山並べて大規模処理を分散することを想定したフレームワークです。
今回は取り扱いませんが、こういうのもあるということだけ覚えておきましょう。

「minimal-java」は必要最小限のプロジェトの土台を作るだけのモード。
本当にちょろっとしか無いです。
詳しく知っている人ならともかく、初心者がここから構築していくのは無理じゃないかなぁ。

「play-java」はプロジェクトが一通り構築された状態から始められるコースです。
基本的にこの「play-java」を選ぶのが効率的スタートの起点となるでしょう。

なお、「scala」というのはJavaではなくscalaでプロジェクトを作るという意味です。
PlayFramworkはJavaでもslacaでもどちらでも使えるフレームワークですが、今回の連載はJavaで進行するので割愛。

では、play-javaを選んで次に進みます。

プロジェクト作成済み。しかし……

プロジェクト名は「play-sample」として、無事にプロジェクトが完成しました。

プロジェクト構成は一通り出来上がっており、「Hello World!」が表示可能状態です。
実に簡単ですね！！

しかし、ちょっと待って下さい。
「play-sample/project/plugins.sbt」を見ると以下のような記述があります。

• addSbtPlugin("com.typesafe.play" % "sbt-plugin" % "2.5.3")

そう、PlayFrameworkのActivatorは「自動的に最新バージョンを取得する」という仕様なのです。
つまり、このプロジェクトは「2.4.6」ではなく「2.5.3」で作られてしまっているわけです。

ここが最初の山場です！！

PlayFrameworkは最新バージョンで作成するのは簡単ですが、古いバージョンを指定して作る機能が見当たりません。

私もネットで散々探したのですが、どうやら「activator new version=2.4.6」みたいに簡単にスパッと作るコマンドは無いみたいなのです。

終わりに

次回後編は本番。

「PlayFrameworkを古いバージョンで始めたい場合にどうすれば良いのか？」

情報がどうしても見つからないので私が体当たりで編み出した荒技をご紹介します。

【JavaでPlayFramwork】バージョン選定⇒2.4.6

お久しぶりです。
株式会社ジェニシス　技術開発事業部の遠藤　太志郎(Tacy)です。

業務都合によりPlayFramworkを始めました。

が、実際にアプリ構築に入っていくまでにはまだＳＴＥＰがあります……。

要事前調査

PlayFramworkは慣れてしまえば簡単に開発していける……はずですが、全然枯れていないので猪突猛進に開始出来ないのが厄介な所です。
構築前に予備知識を得てから始めることをオススメします。

バージョン選定

PlayFramworkはバージョンが沢山ある上にバージョン毎の違いも大きいです！！
まず2016年5月時点でのリリース状況を見てみましょう。

• https://www.playframework.com/download

.X系のバージョンアップだけ見ても以下のような状況です。

• Play 2.5.3 (activator) Apr 27 2016
• Play 2.4.6 (activator) Dec 14 2015
• Play 2.3.10 (activator) Aug 3 2015
• play-2.2.6.zip Nov 14 2014
• play-2.1.5.zip Sep 20 2013
• play-2.0.8.zip Sep 20 2013

ここ数年で2.0⇒2.5まで上がってしまっていますね。
しかも.X.Y系まで見ていると早い時は２週間でバージョンアップしたりします。

つまるところ、今プロジェクトを開始したところで、完成する頃には古くなってしまっているわけですよ。
そりゃライブラリはいつか古くなるものですけど、リリース前から旧式ってのは余り気分が良いものではありませんね。

しかも.X系の間では互換性が無いっぽい。。。
実際に今、2.4.6と2.5.3では違ってますもん。
これらを考慮しますと、私TacyはPlayFramworkを導入する上では.X系の一個前を選ぶことをオススメします。

つまり、2.5.3が最新である現時点では、一個前の世代の最終版である2.4.6を選ぶという意味です。

2016年5月現在、2.5系は情報が殆どありません。これを採用するのは人柱もいいとこ。
でも2.4.6だとまだいくらか情報がありますからね。

新しさと安定性のバランスを踏まえるとこれくらいが良いバランスでしょう。

2.2系からの卒業

このサイトに流れ着いてくる人の中には現在進行形で困惑している人もいるかもしれませんね。

PlayFrameworkは2.2と2.3以降では大きく違います。
そして、ネット上の情報はどうも2.2系が多いんですよ！！

私も自分のＰＣに入っているのが2.4.6なのに2.2の解説サイトを見てたので全く無駄な労力を費やしました。

何故こんなことになっているのか……。
恐らく、原因はコレ。

• Play Framework 2徹底入門 JavaではじめるアジャイルWeb開発

掌田 津耶乃氏による、ほぼ唯一と言って良い日本語のPlay Frameworkの参考図書です。
私も購入しましたが、これが2.2系なんですよ。
この参考書が日本PlayFramework界に支配的な影響を及ぼし、結果として情報サイトが2.2に占拠される結果になったとしか思えません。

でも、この参考書は2013年の古い情報ですからね。
この本のうち８割くらいは今でも通用しますが、２割くらいは別機能に差し替わっています。
そして、詰まる所に限ってこういう場所なんです。

PlayFrameworkはタダでさえバージョン毎の違いが目立ちますので、情報を調べる際は常に「この記事はいつのバージョンの話をしているのか？」「自分のバージョンと差異がある部分か？」を最初にチェックする必要があります。
それには公式サイトと照らし合わせて裏を取るしかありません。

• https://www.playframework.com/documentation/ja/2.4.x/Home

幸い公式サイトのドキュメントは充実しており、部分的ですが日本語化もされています。
Strutsみたいな枯れ果てたライブラリと比較すると不足ですが、現状でも何とかやっていけるんじゃないかと思います。

終わりに

このように、PlayFrameworkはまだまだ過渡期にあるフレームワークであると言えるでしょう。

情報サイトが求められている状況ですので、このブログがその一翼を担えるようになれば幸いです。

【JavaでPlayFramwork】概論２

お久しぶりです。
株式会社ジェニシス　技術開発事業部の遠藤　太志郎(Tacy)です。

業務都合によりPlayFramworkを始めました。

今回も本格的な技術的検証に入る前の概論です。

何でPlayか？

前回でも記述しましたように、今はWebフレームワークは群雄割拠の時代……と言うよりは一通り出揃っているので何でもアリな時代です。

「明らかにコレが最強！！」って時代であれば迷わずそれを使えば良いんですけど、今の時代はWebシステムくらいどうにでもなりまっせ。。。
選択肢が多過ぎるというのは逆に不便でもあります。
採用フレームワーク検討の段階で決め手に欠きますからね。

今回はPlayFramworkを採用する為の根拠についてお話しましょう。

Railsライクである

私が推す一番大きい点はここ、「Ruby on Rails」ライクであるということですね。
「ライク」というのがまた絶妙にいい加減な表現ですが、ともかくRuby on Railsの思想を引き継いでいるんですよ。

Ruby on Railsとは言わずと知れたRubyWebシステムにおける世界標準の最強フレームワークです。
「設定より規約」という設計思想があり、一定のコーディングルールに従って作っていくことで余計な設計作業をしなくて良く、これによって開発効率を高めるものです。
この思想は世界的に大好評の支持を得ておりまして、Ruby on Rails登場以降、Ruby on Railsの思想に影響を受けたフレームワークが多数登場しました。

要するに、


「Ruby on Railsの思想をパクって別言語で同じ事やったろ」


この発想で作られたフレームワークが沢山あるんですよ！！
PlayFramworkもその一種。

つまり、PlayFramwork単品で見ると数あるJavaWebフレームワークの一つでしかありませんが、
Ruby on Railsパクリブラザーズの一員と見ると、「最強フレームワークRuby on Railsファミリーの一角」という後ろ盾を得られます。

それがどういう利点をもたらすかと言いますと、例えばこのTacy。
2016年5月の現時点においてPlayFramwork開発の経験はありません。しかしRubyOnRailsの開発経験はあります。
そのTacyがPlayFramworkの解説サイトを見ると……、内容が分かるんですよ。

RubyOnRailsと同じ思想のフレームワークであるから、RubyOnRailsの知識を流用した着眼点でPlayFramworkを見ることで速やかに技術背景を得ることが出来る。


「PlayFramworkは知らないけどRubyOnRailsなら知ってまーす」


こういう要員を戦力として投入することが可能なんですよ。
今後の開発フェーズで要員を探すことも容易になりますし、その後の長期的保守の観点でも要員調達のハードルが下がる。

これが大きい！！


フレームワークの世界は寄らば大樹の陰であり、使っている人間の数の多さが正義である！！


この意味でPlayFramworkは軌道に乗っています。

ちなみに同じRuby on Railsパクリブラザーズの一角にPHPの「CakePHP」があります。
これも同じく、RubyOnRailsを知っていればスルッと入っていけるフレームワークです。
私はCakePHPも経験ありますが、あの時も勉強期間３日くらいで設計に入って行けました。

今後も同じ感覚で色々な所で使っていけるでしょう。


一度勉強すれば一粒も二粒も美味しい。


技術背景をRubyOnRailsファミリーで固めるのはエンジニアのキャリア戦略として絶大な価値をもたらしてくれるのです。

Grails

ちなみに、JavaVM上で動くRubyOnRailsライクのフレームワークという意味では、PlayにはGrailsという兄貴分がいます。

• https://grails.org/

私は一度だけこの開発の経験があって、確かに革新的で光るものがあるフレームワークでした。
一時期はコイツが注目された時代も過去にあったと噂を聞きますが……、
現時点で見ると特に流行っているようには思えませんね。

何でも、開発者がサボってアップデートを怠っているうちに折角来そうだったブームが過ぎ去ってしまったそうな。(泣)

運命の巡り合わせがあればこの記事もPlayではなくGrailsだったかもしれないと思うと忍びないですね……。
もしまた時代が来たらTacyはGrailsにも参戦しますよ……。

終わりに

以上でPlayFramwork概論は終了です。
次回からは実際にPlayFramworkを使いつつ検証していきたいと思います。

【JavaでPlayFramwork】概論１

お久しぶりです。
株式会社ジェニシス　技術開発事業部の遠藤　太志郎(Tacy)です。

業務多忙により更新が止まってしまっていましたが、再び復活して連載します。

前回まではAndroidStudioの検証を行っていましたが、業務都合により今回からテーマを変更。
テーマはWebフレームワークの「PlayFramwork」です。

• https://www.playframework.com/

昔を振り返る

PlayFramworkは、まあ単なるJavaのWebフレームワークですね。
別にそれほど特別なものではなくて、あくまで標準的に使用されるべきフレームワークの一つと言えるでしょう。

• Struts1
• Spring
• Seasar2(SAStruts)

これら有名JavaWebフレームワークの同族です。

私は自分をJavaWebプログラマーとしては極めて平凡な道を歩んできたと思います。
Struts1で社会人入り、Springで炎上し、Seasar2で快適生活……。
上記に挙げたフレームワークはJavaWebフレームワークの首領達であり、これを知らずしてJavaWebの歴史は語れません。

しかし、あの頃から時代も流れ、現在はこんな状況……。

• Struts1　⇒　サポート終了
• Spring　⇒　炎上プロジェクトの代名詞
• Seasar2(SAStruts)　⇒　サポート終了

何と、必殺のキラーコンテンツだった「Struts1」「Seasar2」がサポート終了を迎えてしまいました。

Struts1は言わばJava全体のキラーコンテンツのようなものであり、何故今の時代にJavaがこれだけ普及しているかと言うと、それはStruts1があったから。
「スーパーマリオブラザーズが人気だったおかげでファミコンが普及した」と言っていいくらいの勢いでJavaの普及に貢献した伝説的フレームワークでした。
しかしサポートが終了してからセキュリティ脆弱性などが見つかってもう使えるシロモノではありません。（まあ、ごり押しで使ってるトンデモ現場もありま……ゲホゲホ）

Seasar2(SAStruts)は、日本製フレームワーク。
日本を代表するプログラマーひがやすを氏によるフレームワークで、これも日本人なら知らぬ者無し。
しかしSeasar2のWeb部分であるSAStrutsって内部ではStruts1を使っているそうじゃないですか。
Struts1サポート終了してからも随分と延命して下さいましたが、そろそろ限界の模様。
ひがやすを氏ご本人が卒業を勧告しておりますから、全人類はこれに従ってSeasar2の時代を終焉させるべきですね。

• http://d.hatena.ne.jp/higayasuo/20150928/1443415547

そしてSpringは……、申し訳ありませんね。
Spring自体は良く出来たものなはずなのですが、どういうワケか私の人生では１００％炎上しているのですよ。
Springは大規模プロジェクトに導入されることが多い為か、フル活用する為には熟練した知識が必要な為か……。
ともかく、何か呪われているような印象がありまして、実際やっぱり色々と難しい部分もあって、小規模プロジェクトに気軽に導入するようなものじゃないと思いますよ。
同じ意見の人も少なくないと思います。なので最近は採用率が下がり気味な印象……。


以上のように、かつて一斉を風靡していたJavaWebフレームワーク達はその役割を終えて新しい時代が到来してきているのが昨今のJavaWeb業界です。

では、これら伝説のフレームワークに続く新時代のフレームワークは……、ありません！！

そう、JavaWebフレームワークは群雄割拠の時代。
問答無用の最強フレームワークが無いご時世なのです。

何で無いんだろう……。
色々あるでしょうが、私としては以下のような持論を持っています。

JavaでWebシステムを作る必要性が無くなった。

そもそもコレ。PHPやRubyなど色々な言語が普及してノウハウも蓄積してきた昨今、Javaに拘る理由が無くなってきているんですね。
現在私が参画しているシステムは業務用でバッチ出力などもあるから全言語をJavaで統一して気合い入れて作る話になっているものの、そうでもないちょっとしたWebサイト開発だったらスクリプト言語ベースの方が小回りが効いて良いですもんね。

実装の必要が無くなった。

最近はパッケージやクラウドサービスも普及してきましたからね～。
「Salesforce」などが代表格ですが、自社用業務アプリを自社開発するより、既に存在するサービスに使用料を払って使った方が機能もコストパフォーマンスも優れていることも多いです。
必然的にJavaで必死に実装するシチュエーションも減ってきました。

悲しいですが、私みたいなプログラマーの出番があるということは、それはその業務が洗練されていないだけであり、本来はパッケージ製品で業務出来るように運用を見直すのが真の理想、というのが真実の姿かと……。

スマホ対応

最近はスマホが普及してきたのでWebシステムの需要もスマホに盗られ……、たわけではありません。
スマホが通信している先はサーバであり、そのサーバでは気合い入れてJavaが動いています。
問題はですね、スマホ、タブレット、ＰＣなど色々な端末に対応する為には「JSONでデータをやりとりするWebAPIである」のがベストってことなんです。

WebAPIとて所詮はHTTP通信するWebシステムってことに代わりはありませんからWebシステムと言えばWebシステムです。
しかし、かつてのようなＰＣ向け画面を作っていた頃のWebシステムと、JSON文字列をストリームで送り返すだけのWebAPIではやっぱり根底が違いますよ。

jspが無いことを始めとして、インターフェース部分が全然違いますからね。

Webフレームワークってのは「画面フォームから受けたパラメータをどうやって受け取るか」ってのがデザインの見せ所なんです。
でもWebAPIって基本、クエリがチョロって来るだけじゃないですか？
気合い入れてWebフレームワークを導入する話じゃないっていうか……。

私だったら自前でそのWebAPIに特化したフレームワークを作るでしょうね。
高機能なWebフレームワークの極一部だけ拝借するよりも、自前で作った方がずっと高速でスリムなシステムを作れるでしょうから。

なのでスマホ用サイト構築の場合は、Webサイトだったら別言語で作り、WebAPIだったらフレームワーク無しでＯＫ、とJavaWebフレームワークの出番が来ない。


まとめますと、最近は技術やノウハウが蓄積されて昔みたいなStruts単細胞野郎が淘汰され、ケースバイケースで色々な言語、製品、フレームワークを選択するようになった結果、「これさえあれば最強！！」みたいな単純な時代では無くなったというのが私の所感です。

何故PlayFramworkか？

このような選択肢の多い群雄割拠のこの時代、では何故、今回私がPlayFramworkを採用することを思い立ったのか……。
もちろんこれには理由がありますが、一番のポイントは、

• Ruby On Railsのフォロアーであること

これですね。
この辺り、フレームワーク採用の評価ポイントについては、次回に続きます。

終わりに

フレームワークはただ効率良く使えれば良いというものではなく、何故それが他と比べて優れているかを他者に説明出来る必要があるのだ。

PlayFramwork編は長期連載になると思いますが、末永く宜しくお願いします。

【AndroidStudio】FindBugs導入

株式会社ジェニシス　技術開発事業部の遠藤　太志郎(Tacy)です。

最近はAndroidStudioの検証を進めています。

現在は快適な環境構築を目指してプラグイン探しをしています。
本日はFindBugsに行ってみましょう。

FindBugsとは

FindBugsとは、一言で言えばプログラムの静的解析ツールとでも言いましょうか。
Java業界では結構有名なツールで、ソース中のバグらしき箇所を発見してくれる機能を提供してくれます。

結構有名なツールですので、調べれば色々出てくるでしょう。

前回紹介したCheckStyleと静的解析という意味では似ていますが、
CheckStyleは変数のネーミング規約とかそういう『可読性』に関するチェック機能に対し、
FindBugsは処理に問題無いかどうかという『ロジック』についてチェックしてくれるものです。

まあ正直言いますと、FindBugsで検出出来るバグって「自分で気付けよ！！」っていう程度の低レベルバグですので、
これに依存しているようではプロジェクトの品質はボロボロに決まっておる。。。
実装を根本から見直した方が良いでしょう。

とは言え、導入しても別に損はありませんから、入れるだけ入れるに越したことはありません。

では、入れてみましょう。

インストール

インストール手順は、前回のCheckStyleとほとんど同じ。

設定画面から「QAPlug」で検索するとCheckStyleと一緒に出てきます。

どうなってんだ？？？

CheckStyleとFindBugsは用途としては似たものですが、本来別物なんですけどね。
親切な人が便宜上一纏めにしてくれているのかもしれませんね。

上記画像に出ている「Hammurapi」と「PMD」とは？

どうやら全部静的解析ツールのようです。
今回のテーマはFindBugsですが、もういっそ全部インストールしてみましょう。

全部纏まって入りましたね。

設定とカスタマイズ

後は設定するだけですが、実はこれも前回と同じ。。。
「設定 ⇒ Other Setting ⇒ QAPlug」にある「Coding Rules」から設定をカスタマイズしていけばＯＫです。

ようやく分かってきました。
「CheckStyle」「FindBugs」「Hammurapi」「PMD」を全部一纏めにしてくれているのが「QAPlug」なわけですよ。

どこからどこまでがCheckStyleで、どこからがFindBugsで……。
Eclipseのプラグインだとこれらはそれぞれ別々にインストールして別々に設定する必要がありますが、
こちらQAPlugを使用すればそんな境界線を気にする必要はありません。

スパッと全部入れて、スッキリ品質の良いコードを書いていけばＯＫです。

終わりに

引き続きAndroidStudio関連の調査を継続していきます。

【AndroidStudio】CheckStyle導入

株式会社ジェニシス　技術開発事業部の遠藤　太志郎(Tacy)です。

最近はAndroidStudioの検証を進めています。

現在は快適な環境構築を目指してプラグイン探しをしています。
本日はCheckStyleに行ってみましょう。

CheckStyleとは

かなり有名なツールなのでCheckStyleの存在をご存じな方も多いかと思いますが、手短に噛み砕いてご説明しましょう。
代表的なコードの静的解析ツールで、つまりJava実装のコーディング規約をリアルタイムでチェックしてくれます。

例えば、実装における一般的な規約として「ローカル変数の頭は小文字で始める」というのがあります。

• String name = "遠藤　太志郎";

しかし、実装に慣れていない人が実装すると、こういった規約まで配慮が行き届かなくてガタガタになってしまうケースがあります。

• String NaMe = "遠藤　太志郎";

こういう時、先輩格のSEが目視でレビューするのは大変ですよね？
そんな時がCheckStyleの出番です。
こういう規約に沿っていない箇所に警告を出し、目視し易いようエディター上に黄色く表示してくれます。

これで作業が随分と楽になります。
効率的な実装作業には欠かせないツールと言えるでしょう。

AndroidStudioにもこのプラグインを入れてみたいと思います。

インストール……失敗

では、インストールしていきましょう。
設定画面からCheckStyleを検索します。

え……。沢山出てきたのですが。。。

意味分かりませんが、とりあえずインストールしてみました。

まず、一番上の「CheckStyle-IDEA」って、これ罠だろう！！

プロジェクトを読み込めません : com.intellij.ide.plugins.PluginManager$StartupAbortedException: com.intellij.diagnostic.PluginException: org/infernus/idea/checkstyle/CheckStylePlugin : Unsupported major.minor version 52.0 [Plugin: CheckStyle-IDEA] [Plugin: CheckStyle-IDEA]

起動しなくなりましたわ。

起動しなくなったのでアンインストール画面も起動出来ねえし……。

こうなったら強制削除しかありませんね。
うっかり入れてしまった人は以下フォルダの該当フォルダを手動削除してください。

• ユーザホーム\.AndroidStudio1.5\config\plugins

よく見ると画面に「INSPECTION(評価版)」って書いてありますね。

ログの「Unsupported major.minor version 52.0」ってのは、実行JREのバージョンが古かったりする時に見るエラーログなんですが、環境変数見直したりJREを再インストールしなおしても結局直りませんでした。

もしかしたらAndroidStudioの本家である「IntelliJ IDEA」なら普通に動くのかも。だとしれば、もしかしたらプラグインも最新版ではなく少し古いバージョンなら動く……。
など考えましたが、結論としてはもう一つのプラグインを使うことにしましたので調査打ち切り。

デバッガーの人なら何か手があるのかもしれませんが、初心者は寄りつかない方が賢明でしょう。

インストール

仕切り直していきましょう。

QAPlugというプラグインの方が正解です。

QAPlugとは、日本語情報が全くありませんが、どうやらIntellij IDEAのプラグインのうち、コード解析を中心に活動しているプロジェクトのようです。

• http://qaplug.com/

CheckStyle以外にもプラグインを提供しています。
他のプラグインは後日記事にしますので、今回はCheckStyleのみ。

QAPlugは

• 本体プラグイン：QAPlug
• 拡張プラグイン：QAPlug - CheckStyle

この二段構えになっていますので、両方インストールして下さい。

設定とカスタマイズ

インストールすると、「設定 ⇒ Other Setting ⇒ QAPlug」が出現しています。
デフォルトでもある程度設定されていますが、Coding Rulesから設定をカスタマイズしていきましょう。

この画面の「+」ボタンを押すとこのような画面が出てきます。

このようにEclipseで作成した設定ファイルをこちらにインポートすることも出来るわけですね。
Eclipseで使っていた設定ファイルをこっちに持ってこれるので楽チンです。

実行

では、登録したCheckStyleの設定でソースを走査してみましょう。

これがまた分かり辛いんですが、右クリックなどで「分析」などを探して、そこから「Analyze Code」を実行すれば良いです。
AndroidStudioにはCheckStyle以外の分析機能も備わっていますから「CheckStyleで分析」とか書いていてくれないとどれがどれやら分からねえ……。

次の画面ではどの設定でチェックするか選択出来ますので、先ほど自分で作成した設定でチェック実行。

コンソール画面にチェック結果が出てきました。

後は警告が無くなるまでこれを繰り返して綺麗なソースを作るだけですね。

終わりに

やっぱりEclipseとは相当使い勝手が違いますね。
慣れるまでは時間をかけて使っていく必要がありそうです。

引き続きプラグイン探しを行います。

【AndroidStudio】フォーマッター設定(Eclipse Code Formatter)

株式会社ジェニシス　技術開発事業部の遠藤　太志郎(Tacy)です。

ただ今、業務都合によりAndroidStudioの検証を進めています。

今週からは色々とプラグインを探しつつ、快適な実装環境を模索していきたいと思います。

フォーマッターを使おう！！

新しく開発環境を導入した時に最初に着眼するべき所は必ずコレ。フォーマッターです。
ご存じの方も多いかと思いますが、話の前振りとしてフォーマッターの意義をご説明しましょう。

まず、言うまでもありませんがソースというのは可読性が非常に重要になります。
偶に「え？　動けばいいんじゃね？（＝何もしなければコストダウンに繋がる）」みたいな事を言う人もいますが、
いやいや、可読性が低いソースを残すことはいずれ大きな弊害を招きます。
バグの見落とし然り。開発効率の低下然り。

とは言え、既に本番稼働に入ってしまったソースを修正するのは新しいバグを生み出す可能性も高く、
上記の通り「動いてるんだから何もするんじゃねえよ」という話に繋がってしまい、未来永劫に修正する機会を得られないケースも少なくありません。

このような事態を未然に防ぐ最善完璧ベストの手段は、もちろんコレです。

• 最初から綺麗なソースを書く。

コレですよ。最初が肝心。
綺麗に実装出来る環境を最初に整えることが一番肝心なのです。

しかし、綺麗な実装というのはある程度の実力者ならば可能ですが、
チームメンバーは全員が実力者揃いばかりとは限らず、実力者同士の組み合わせであっても個人の癖があります。

キチッと統制を取ってやらなきゃソースの可読性なんてあっという間にガッタガタ。
開発効率は日を追うにつれてどんどん下がっていきます。

そんな時、フォーマッターを導入することである程度まではソースの癖を統一して可読性を向上させることが出来ます。

開発リーダーが最初にやるべきことは、メンバー全員の開発環境を洗練して統一することなのです。
その第一歩がフォーマッターの導入というわけですね。

「戦争のプロは兵站を語り、戦争の素人は戦略を語る」(アントワーヌ＝アンリ・ジョミニ)という格言がありますが、
開発で言うとこんな感じですかね。

• 「開発のプロは環境を語り、開発の素人は技術を語る」(Tacy)

ＯＫ？

フォーマッター実行

細かいカスタマイズは後述しますが、まずはAndroidStudioでフォーマッターを実行するコマンドはこれです。
さあ、やってごらんなさい。

• Ctrl+Alt+L

ガシャツっとソースが動いたら、それはあなたが今までフォーマッターを使っていない危険環境で実装していたことを意味しますのでご注意を。

なお、「ソース保存時に自動的にフォーマッターを実行する」ということも出来るようです。
しかしこちらはマクロを組んだりする必要があり、ちょっと大変なのでまた後日。

フォーマッターのカスタマイズ

フォーマットするだけなら上記のコマンド一発で完了です。
しかし、やっぱりソースに拘りを持つ者としてはフォーマッターの設定をカスタマイズしたいところですよね。

AndroidStudioはデフォルトでフォーマッターが入っており、カスタマイズする場所は以下です。

• 設定　⇒　Editor ⇒　Code Style

設定は細かい所まで出来ますのでそれぞれの現場で最もマッチする設定を模索してみると良いでしょう。

問題は、作った設定の共有。。。
自分で構築した設定をチーム内に共有するにはどうすれば良いのだろう？

調査すると「androidstudioホーム/config/codestyles」に設定ファイルがあるという情報を見つけたのですが、そんなフォルダ無えよ。。。

真相不明ですが、この設定って古いAndroidStudioの話なんじゃないの？
今のAndroidStudioだと「設定のエクスポート」を使う以外に手段は見つかってないです。

しかしこれはフォーマッター以外にも色々と一緒になってエクスポートしてしまったりして、
ちょっとチーム共有という観点だと柔軟性に欠けるという印象。。。

そんな時は次、Eclipseのフォーマッターを使っていきましょう。

Eclipse Code Formatter

EclipseをメインとするJavaエンジニアのTacyとしては、やっぱEclipseの資産を使っていきたいなぁ。。。

そう思っていたら、ありました。やっぱみんな想いは同じなのですね。
Eclipseのフォーマッター設定をAndroidStudioに移植する人気プラグインが存在しています。

その名は、Eclipse Code Formatter。

公式プラグイン置き場にありますので、さっそくインストールしてみましょう。

インストールして再起動すると、設定にEclipse Code Formatterが増えています。

後はEclipseからエクスポートしてきたフォーマッターをセットすれば良いという寸法です。

注意点は「Eclipseで設定してからAndroidStudioに持ち込む」という二段構えの設定である所ですね。

AndroidStudioだけで全て完結している現場だったらシンプルにデフォルトのフォーマッターでやりくりすれば良いかと。
しかしEclipseと二刀流をやっている現場ではEclipse Code Formatterの方が馴染み易い印象。

まあ、この辺りは絶対的な決まりは無くて、開発者の好みな部分の気がしますね。
実際に現場に導入してみて、評判を見てどちらか一本の統一するのが良いでしょう。

終わりに

引き続き環境構築向けのプラグイン調査を行っていきます。