2015-10-23

CheckStyleでテストクラスだけ日本語メソッド名OKにする方法

Java

CheckStyle の設定で苦労したので、作業メモを残しておきます。

やりたいこと

テストクラスはメソッドを日本語で宣言したいので、
テストクラスのメソッドだけを CheckStyle のチェックから外したい。

MethodName モジュールの仕様

メソッドの命名チェックを行っているのは “MethodName" というモジュールです。

<module name="MethodName"/>

CheckStyle の設定ファイルではこんな感じで設定されています。
デフォルト値は省略されていますので、明示的に属性値を書いてみると以下のような感じに。

<module name="MethodName"
               format=“^[a-z][a-zA-Z0-9]*$"
               allowClassName=“false"/>

format 属性で「小文字英字で始まって」「英数字のみ」という命名ルールが規定されています。
記号も日本語もダメ。
allowClassName 属性はクラス名と同じ名前のメソッドを宣言してもよいかどうか（当然 false）。

excludesClassName みたいな属性があれば、「ファイル名が “Test.java” で終わるもの」と
指定できたりしますが、このモジュールは残念ながらそういう属性はありません。

なんとかがんばるしかありません。

SuppressionFilter を使う

SuppressionFilter を使うことで、各モジュールが行うチェックの対象外を指定することができます。
http://checkstyle.sourceforge.net/config_filters.html#SuppressionFilter

便利そうです。

だけれど、ちょっとやっかいです。
いつもの CheckStyle 設定ファイルとは別で、ファイルを作らないといけないです。

いつもの CheckStyle 設定ファイルには
以下のように「SuppressionFilter の設定は別ファイルを見てね」と設定追加します。

<module name="SuppressionFilter">
  <property name="file" value="docs/suppressions.xml"/>
</module>

その参照先となる、別ファイル suppressions.xml を作ります。

<?xml version="1.0"?>

<!DOCTYPE suppressions PUBLIC
"-//Puppy Crawl//DTD Suppressions 1.1//EN"
"http://www.puppycrawl.com/dtds/suppressions_1_1.dtd">

<suppressions>
  <suppress checks=“MethodName” files=“.*Test.java$” />
</suppressions>

<suppress> の checks 属性に対象のモジュール名を指定します。
files 属性に正規表現で対象外としたいファイルを指定します。ここではテストクラスの想定。

通常の CheckStyle でファイル指定する感じで “*Test.java” とか指定すると
実行エラーになるので注意です。

suppressions.xml のパス指定がやっかい

いつもの CheckStyle 設定ファイルに suppressions.xml（ファイル名は任意です）のパスを
指定するのですがこれが厄介者です。
いつもの CheckStyle 設定ファイルかの相対パスで見てくれたらいいものの…

CheckStyle を実行する際の作業ディレクトリかどこかからの相対パスっぽいです。
（きちんと調べてませんが、システムプロパティの ”user.dir” とかだと思います）

なので、ひと工夫が必要です。

<ケース１> Eclipse Check Style Plugin の場合

<property name="file" value=“${config_loc}/suppressions.xml"/>

もしくは

<property name="file" value=“${samedir}/suppressions.xml"/>

という感じで変数を使うことで、いつもの設定ファイルがあるディレクトリパスを指定できます*1。
Eclipse Check Style Plugin が ${config_loc}, ${samedir} といった組み込み変数を
用意しているみたいです。

${samedir} よりも ${config_loc} を使っている人が多そうなので、
以降は ${config_loc} を使っていきます。

<ケース2> Maven の場合

Eclipse でチェックできるようになったから、次は Maven でチェックだ*2。
という流れで、「mvn checkstyle:checkstyle」するとエラーになります。

${config_loc} は Eclipse Plugin の組み込み変数なので、Maven が知らない変数になります。
Maven として config_loc の変数をセットしてあげる必要があります。

pom.xml に CheckStyle plugin がこんな感じで設定されているとして…

<plugin>
   <groupId>org.apache.maven.plugins</groupId>
   <artifactId>maven-checkstyle-plugin</artifactId>
   <version>2.8</version>
   <configuration>
     <configLocation>${basedir}/config/checkstyle.xml</configLocation>
   </configuration>
   <executions>
     <execution>
       <phase>verify</phase>
       <goals>
         <goal>check</goal>
       </goals>
     </execution>
   </executions>
 </plugin>

タグにひと工夫を加えます。
タグを追加して config_loc という変数をセットします。

   <configuration>
     <propertyExpansion>config_loc=${basedir}/config</propertyExpansion>
     <configLocation>${config_loc}/checkstyle.xml</configLocation>
   </configuration>

これで Eclipse でも Maven でも、
いつもの設定ファイルからの相対パスで suppressions.xml を指定することできます。

「mvn checkstyle:checkstyle」も動くはずです。

参考にしたサイトなど

色々なサイトの情報をつぎはぎしながら解決しました。

補足

・JavadocMethod（メソッドの Javadoc 必須チェック）についても同じような感じで
　対象外指定できます。
・Eclipse Plugin で提供される GUI で設定ファイルを編集ようとすると、
　一部の設定情報が欠損したりします。直接ファイル編集したほうが早いです。

- - - -

私の Eclipse 環境だと、${config_loc} や ${samedir} で置換されるパスが末尾”/"付きになっていたので、実際は
<property name="file" value=“${config_loc}suppressions.xml”/> という設定です。

いつもは Gradle 使いですが、今はお仕事の都合上 Maven 使ってます。

*1:私の Eclipse 環境だと、${config_loc} や ${samedir} で置換されるパスが末尾”/"付きになっていたので、実際は <property name="file" value=“${config_loc}suppressions.xml”/> という設定です。

*2:いつもは Gradle 使いですが、今はお仕事の都合上 Maven 使ってます。

2015-07-22

HTML5プロフェッショナル認定試験の勉強をはじめました

HTML5

約半年ぶりのブログ。
長らく放置でしたが、最後の投稿から半年しか経っていないのかという感じです。
1年くらい前…な感じです。

HTML5プロフェッショナル認定試験（http://html5exam.jp/）の
お勉強をはじめました。

Why？

HTML5/CSS3 にはもともと興味を持っていて、きちんと使いこなしたい
…というよりもまず、きちんと理解したいという思いが長い間ありました。

そういう資格試験があるんだということを今年に入ったくらいに知って
今年度の会社の目標設定に含めて、勉強＆受験しようと思った次第です。

レベル２のためにしっかり勉強しないと…

まずは「レベル１」を早々に合格して（そんなにレベル高くないと踏んでる…）
「レベル２」も今年中か今年度注に受験しようという目論見です。

「レベル１」は問題集が２冊くらいあるので安心ですが、
「レベル２」は問題集もなく、内容もハードそうです。

ということで、しっかり勉強しながら受験に臨まないと「レベル２」は落ちてしまいそう。
色々とサンプルとかも作りながらお勉強しようと思っているので、
ついでにブログにもアップしようという魂胆です。

気づきがたくさん

レベル１の問題集をざっと読んでみましたが、
知っていること半分、知らないこと半分という感じです。

"知らないこと” といっても、
HTML や CSS の仕様を知っていればスマートにできたのに
がんばって JavaScript でガリガリ書いてしまっていたな…
という感じの発見＆気づきがほとんどですね。

さいごに

ブログ復活のリハビリも兼ねて、
ちょろちょろとサンプルや気づきをアップしていきます。

HTML5プロフェッショナル認定試験に関するブログは少なそうなので
アクセス数アップも期待できるかも…(￣ー￣)ﾆﾔﾘ

2015-01-06

『Web API: The Good Parts』を読んでみた

読んでみた JavaScript

Web API: The Good Parts

posted with ヨメレバ

水野貴明オライリージャパン 2014-11-21

Amazon

実務として、Web API（Web サービス）の開発に携わっているわけではありませんが、
Ajax を使用した非同期処理を実装することが多くなってきており、
その場合のサーバ・クライアント間のやりとりをうまく実装できていない不満足感がありました。

エラー発生時のレスポンスの返し方がうまく統制が取れていなかったりしています。
どういう具合に返すのがよいのか理解できていませんでした。
この点について、３章あたりでエラー時の返し方について言及されているので勉強になりました。

サーバ側は Java ですが、Servlet で Web サービスっぽく、JSON を返すようにガリガリ実装しているのですが、
Java API for JSON Processing などを使って、次はうまく作りたいと思っています。

きれいな API の事例を見ていると、気持ちがいいです。

Web API なので、当然 JavaScript や JSON の話が多いのですが、JavaScript はここまで奥が深いのかと驚かされました。
JSONP（JSON Padding）とか初耳でした。実に不勉強です。
一方で、発見も多いので JavaScript を勉強するのはおもしろいです。

オライリーの動物本なので翻訳本だと思っていたら、実は翻訳ではなくて、著者が日本人でした。
事例に、楽天や鑑これといった"日本ならでは"なものが出てきます。

また、翻訳版の出版が直近だったとしても、原書は５年も１０年も前に出版されていて、
情報が古くて残念なことが多いですが、その点では情報が新しくてよかったです。

次は『APIデザインの極意』も同じような感じでおもしろそうなので読んでみようと思っています。

APIデザインの極意 Java/NetBeansアーキテクト探究ノート

posted with ヨメレバ

Jaroslav Tulach インプレスジャパン 2014-05-23

Amazon

2014-10-16

チームを小さく保つ理由

読んでみた Agile

『エッセンシャルスクラム』の第11章開発チーム（197ページ）に次の一節を見つけました。

Mike Cohn は、チームを小さく保つ理由をいかのように述べている。
・誰かがやってくれるから自分はやらなくてもよいという「社会的手抜き」が少ない。
・小さなチームは建設的なやり取りが頻繁に発生する。
・調整に必要な時間が少ない。
・誰も陰に埋もれることがない。
・小さなチームのほうがメンバーを満足させることができる。
・有害な過度の専門化が発生しにくい。

逆説的に考えてみると、
「大きいチーム（≒大規模開発）における弊害」みたいなものが見えてきまして…

「あっ…ウチのことや」と。 (TдT)

それはさておき、使える一節なのでメモメモ。