めりくるくるりん: Java

仕事中のお話しです。

周りの声から、
ソースコードが単体テストを行うのに不向きとなっているという言葉が聞こえました。

ただの推測でしかありませんが、
ここでいう単体テストはJUnitのようなライブラリを使ったテストだと思われます。

なるほど、
確かに意識して書かないとテスト可能な実装になんてまずなりません。

ならないからこそテストを先に書く必要性があり、
TDDが生きてくるわけです。

でもまぁ、
先にテストを書けを言われて簡単に書ける人はそうは居ないでしょう。

なのでテストを多少後回しにしても大丈夫な指針でも出してみます。

別に難しいお話しではありません。

JavaならCheckStyleを使って良いスコアを叩き出せば良いだけです。

クラス・メソッドの行数、
引数の数、
入れ子の深さ、
サイクロマチック数、
結合度、
このあたりに閾値を設定しておいて、
警告が出ないようなコーディングを行えばかなり良くなります。

問題があるとすれば、
下手な人はいつまで経っても警告を消せないということです。

テストを前提としたコーディングでは、
今までごまかしてきたコーディングのレベル差が出やすいのです。

それも早い・遅いではなく、
できる・できないレベルに達するほどです。

自分はTDDが必ずしも必要だとは思いませんが、
こういったふるい分けができるという点では大好きです。

まあ管理的には顔面蒼白ものかもしれませんが…

もしも自分のチームでTDDを導入するのであれば、
・元から全員レベルが高い
・TDDを教えるプロフェッショナルが居る
・出来ない人を切り捨てて構わない
のいずれかを満たしてないと辛いのではないでしょうか。

結局何が言いたいかというと、
不相応なレベルで導入しようとすると痛い目をみますよってことです。

レベルが不足しているのであれば、
テストが不能なソースコードが生成されることを甘受するしかありません。

とりあえずTDDは考えず、
CheckStyleを守れるか守れないかで測定してみては？
※JavaではないならSourceMonitorとかでどうぞ。

2013年7月4日木曜日

InternetDateFormat for RFC3339

Java isn't supported RFC3339.

Because I made InternetDateFormat class.

But it hasn't tested very much.

If you use this class, you need a few test.

FYI:Japanese Edition

2013/07/31: Update detail.
2013/12/16: Bug fix "parseFractionalSeconds".
2017/09/18: Bug fix "parse" (Thanka comment!)

2012年12月30日日曜日

意外な相性問題？

Ubuntuにeclipseと入れたら、
奇妙な現象に出くわしました。

PropertiesのInstalled JREsのページがエラーで表示できないのです。

調べてみると、
どうやらOpenJDK7を入れているときに起こる現象のようです。

手っ取り早い解決方法は、
eclipse.iniに以下の設定を加えることです。

-Dcom.ibm.icu.util.TimeZone.DefaultTimeZoneType=ICU

情報の出処はこちらです。

…つまり、OpenJDK7のTimeZoneになんかあるってことですかね？

第5回 Java7はここが違う！

前回＜＞次回

登場人物

NRT
猪突猛進なプログラマー
考える前に体力勝負でプログラミングするタイプ。
たまに鋭い洞察力を見せるため、
周囲からは落ち着いてさえいれば…と言われている。
SSK
冷静沈着なプログラマー
20:80の法則に習い、実は仕事の一部分を学習に当てている。
他の人はそれに気がついていない。
Java7についても以前からチェックはしていた。
SKR
紅一点なプログラマー
暗算は早いけど、プログラミングはそこそこ。

※登場人物は忍者ではありません。架空のプログラマーです。

新機能：Improved Compiler Warnings and Errors When Using Non-Reifiable Formal Parameters with Varargs Methods

～～～　社内－会議室　～～～

SSK「どうして…こうなった…」

SKR「仕方ないわね、本当にJava 7を使うことになっちゃったんだし。」

NRT「へへっ！腕が鳴るってばよ！」

SSK「とりあえず、構文のみに絞るからな。
       クラスの変更や追加は流すくらいにしかやらない。
       せっかくだし新しいJavadocにでも慣れればいい。」

SKR「新しいJavadoc？Java 6とどう違うの？」

SSK「ハッキリ言って別物に見えるくらい違う。
       …そんなことよりも、今回の本題を始めるぞ。」

NRT「よっしゃー！どんとこい！」

SSK「今回は強化された警告について説明する。
       とりあえず、この2つのソースを見てくれ。」

＊ひとつめ＊

List fooList = new ArrayList<number>();
List<string> barList = fooList;

＊ふたつめ＊

public static <t> void foo(List<t> list, T... elements) {
    // 何かの処理
}

public static void bar(List<string>... l) {
    // 何かの処理
}

SSK「Java7では、こいつらは警告扱いになる。」

NRT「ど、どういうことだってばよ！？」

SKR「ひとつめは分かるわ。…というより、今まで警告が無かったの？」

SSK「そうらしいな。
       ひとつめは総称型が違うものへの代入、
       ふたつめは…可変長引数の使い方だな。」

NRT「あ！俺もひとつめは分かったってばよ！
       でもふたつめがぜんぜんわかんねぇぇ…」

SKR「もしかして、可変長引数にListを使っているのがいけないのかしら？」

SSK「そう思っていてだいだい間違いはないと思う。
       具体例が出せなくて悪いが、
       この実装を避けるように組んでくれればそれでいい。」

NRT「なら簡単だってばよ！」

SSK「おまえにこんな処理が必要な箇所は任せないから安心しろ。」

NRT「な、なにお〜！」

前回＜＞次回

2012年10月29日月曜日

Log4j2はもう試した？

肩赤な話題ですが、
Log4jのバージョンが2.0になってしばらく経ちました。

公式ページを覗いてみると、
今までとはガラリと変わった仕様の数々を垣間見ることができます。

今まで自作していたあのアペンダが、
2.0では不要になる…かもしれません。

そろそろどこかが特集でも組むかと思いましたが、
ググった限りでは(日本語記事は)まだ無さそうです。

Java7の記事をさっさと終わらせて、
自習代わりにこいつの記事を書きたいものです。

いや、記事を書く気力がね？
次回の中身は半分くらいできてはいるのですが…

そんな早朝…

2012年9月6日木曜日

FizzBuzzの亜種問題を解く

White scenery @showyouに掲載されていた問題を解いてみることにしました。

邪法なのでこれから解こうという人の参考にはならないと思います。

問１の解答

JavaScriptで解きました。

この手の問題では手垢のついた方法ですが、
正規表現を使っています。

4の倍数、100の倍数、400の倍数は、
実は正規表現に有利だったりします。
※おそらく最悪なのは7の倍数とかかな？

しかし通常の方法とは違い、
4桁年までしかサポートしていない欠点を持っています。

まあ頑張ればそこも直せるでしょうけど、
もうめどいんでいいです。

問２の解答

Javaで解きました。

Java6から和暦をサポートしているので、
それさえ知っていれば赤子の手をひねるようなものです。

と言っても、
これはバージョン2だったりします。

最初のバージョンは日単位でループさせていたのですが、
デバッグ中にDAY_OF_YEARの仕様に気がついて年単位に修正しました。

その結果、
なんとif文が登場しないソースコードになりました。

え、卑怯？
車輪の再発明を防いだと言ってくださいよ。

こういう風にプライベートでも前向きにプログラミングに望める人なら、
才能は無くても上達できる可能性はあると思います。

…それが3分なのか3000時間なのかは分かりませんけどね。

2012年7月24日火曜日

Eclipse BIRT vs Jasper Report

レポーティングツールはいくつかありますが、
Javaですぐに使えそうなのは表題の2つではないでしょうか？

今まではJasper Reportを使っていたのですが、
最近はBIRTの方がいいじゃないかと思っています。

理由はいくつかありますが、

まずは必要なライブラリが少なくて分かりやすい点です。
Jasper Reportは最小限ってだけでも結構なjarファイルを要求されます。

そしてレポートテンプレートの開発ツールです。

どっちもeclipseのプラグインが提供されていますが、
eclipseと仲がいいのは断然BIRTです。

基本的に経験の有無はそれほど加点対象には含めないので、
BIRTかな～っと思うわけなんです。

…なんてあれこれ言ってますが、
仕事場ではそれを扱うであろう部署のレベルの関係で使われないだろうという皮肉。

2012年7月12日木曜日

標準出力をJUnitでテストするには

久しぶりにソースを公開してみます。

標準出力に結果を出すプログラムをJUnit 4.1でテストする方法とかで解説されていますが、
それを汎用的にしてみました。

名付けて、StandardOutputSnatcherクラスです。
略してSOS！

ちなみにLog4jの出力テストにも使えることにお気づきでしょうか？
そうです、ConsoleAppenderで出力すれば、
Log4jで出力した内容をStringで取得できるのです。

適当にコピー＆ペーストでお試しあれ。
…ちゃんと意味を理解したうえでね。

2012/07/08追記：微妙に修正

2012年1月31日火曜日

ごめんねGCViewer

Java6使えないな～
更新されないかな～

っと思っていたら、
ちゃんと更新されていました。

色々改善されていて良い感じです。
これなら簡単にGCログを解析できます。

そりゃそうだ、
あんなに良いツールに開発引継ぎが無いはずがない。

これからも使わせていただきます。
(自分の日本語化版はそっと消しておくことにしましょう。)

2012年1月19日木曜日

開発環境だけは整う

メイン機のDドライブに、
eclipseを主軸とした開発環境を整えました。

一本化すると重くなりそうなので、
言語ごとに分割しています。

今のところは、
C/C++、Java、Ruby、PHP、Android(Java)
でしょうか。
(順次追加予定)

追加が必要なプラグインは、
適宜追加予定です。

後は遊撃部隊のような役割として、
meadow(emacs)で穴を埋められたらと思います。

eclipseを縦串として、
emacsを横串として使うイメージです。

これが使えるかはさっぱりですが、
しばらくはこの構成で進んでみることにします。

2011年9月10日土曜日

第4回 Java7はここが違う！

前回＜＞次回

登場人物

NRT
猪突猛進なプログラマー
考える前に体力勝負でプログラミングするタイプ。
たまに鋭い洞察力を見せるため、
周囲からは落ち着いてさえいれば…と言われている。
SSK
冷静沈着なプログラマー
20:80の法則に習い、実は仕事の一部分を学習に当てている。
他の人はそれに気がついていない。
Java7についても以前からチェックはしていた。
SKR
紅一点なプログラマー
暗算は早いけど、プログラミングはそこそこ。

※登場人物は忍者ではありません。架空のプログラマーです。

新機能：Type Inference for Generic Instance Creation

※前回から会話が続いています。

SKR「SSK君、他にJava SE 7で変わったところって何？」

SSK「そうだな…ならさっき少しだけ出たハッシュテーブル関連でいくか？」

SKR「曜日をハッシュテーブルに入れた場合ね。
こんな感じかしら？」

// Java SE 6 で曜日のハッシュテーブルを表現
Map<String, int> weekly = new HashMap<String, int>();

SSK「さて、Java SE 6なら全く問題ないわけだが…
       何か思うところはないか？」

SKR「ここまで振りがあったら推理は簡単ね♪
       またもっと良い書き方があるんでしょ？」

SSK「その通り、NRTみたいに無駄が多いコードと付き合う必要はもう無いわけだ。
       …というわけでこうなる。」

// Java SE 7 で曜日のハッシュテーブルを表現
Map<String, int> weekly = new HashMap<>();

SKR「なるほどね。
       同じことを2度書かなくて良くなったわけか…」

SSK「慣れは怖いな、総称型を使うときの欠点にいつの間にか慣れてしまっている。
       本当は無駄な表現がどれだけ多いことか…(ため息)
       そうだ、こんな例もあるぞ。」

Map<String, List<String>> myMap = new HashMap<>();

SKR「二重に使っていた場合でも、まとめて省略して構わないわけね。」

SSK「これでフィールドの初期化は、随分きれいになるだろうな。」

前回＜＞次回

2011年8月15日月曜日

第3回 Java7はここが違う！

前回＜＞次回

登場人物

NRT
猪突猛進なプログラマー
考える前に体力勝負でプログラミングするタイプ。
たまに鋭い洞察力を見せるため、
周囲からは落ち着いてさえいれば…と言われている。
SSK
冷静沈着なプログラマー
20:80の法則に習い、実は仕事の一部分を学習に当てている。
他の人はそれに気がついていない。
Java7についても以前からチェックはしていた。
SKR
紅一点なプログラマー
暗算は早いけど、プログラミングはそこそこ。

※登場人物は忍者ではありません。架空のプログラマーです。

新機能：Strings in switch Statements

SKR「SSK君、ちょっといいかな？」

SSK「どうした？」

SKR「SSK君なら、これをどう実装するかと思って。」

public int toConstantFieldValues(String dayOfWeek) {
    if (dayOfWeek == null) {
        throw new IllegalArgumentException();
    } else if (dayOfWeek.equals("日")) {
        return 1;
    } else if (dayOfWeek.equals("月")) {
        return 2;
    } else if (dayOfWeek.equals("火")) {
        return 3;
    } else if (dayOfWeek.equals("水")) {
        return 4;
    } else if (dayOfWeek.equals("木")) {
        return 5;
    } else if (dayOfWeek.equals("金")) {
        return 6;
    } else if (dayOfWeek.equals("土")) {
        return 7;
    } else {
        throw new IllegalArgumentException();
    }
}

SSK「…言いたいことは分かった。
       もっといいやり方がないかってことだな。」

SKR「SSK君だったら、やっぱりハッシュテーブルを使う？」

SSK「(NRTならそんな疑問を抱くこともないんだろうな…まあいい)
       いや使わない。同じ実装にする。
       大した個数じゃないし、何より変化しない要素だ。
       暦が変わったのなら話は違うけどな。」

SKR「う～ん、何か歯がゆいわね～。他に手段はないの？」

SSK「enumを使うっていう手もあるが、
       割に合わない複雑さになると思う。
       Java SE 7になれば改善されるんだが…」

SKR「え？どうなるの？」

SSK「switch文で文字列が使えるようになる。
       さっきのはこう書き直せる。」

public int toConstantFieldValues(String dayOfWeek) {
    if (dayOfWeek == null) {
        throw new IllegalArgumentException();
    }
    switch (dayOfWeek) {
        case "日": return 1;
        case "月": return 2;
        case "火": return 3;
        case "水": return 4;
        case "木": return 5;
        case "金": return 6;
        case "土": return 7;
        default: throw new IllegalArgumentException();
    }
}

SKR「ふ～ん、nullチェックは変わらないのね？」

SSK「ああ、チェック無しだとNullPointerExceptionになる。
defaultに来るのはnullを除いたその他になる。」

SKR「これいいわね～、正規表現とかはできないの？」

SSK「(仕様を斜め読み)…できないみたいだな。
あくまでもequalsの置換だけのようだ。」

SKR「文字列なんだから、そこまでやって欲しかったわね。」

SSK「equalsとmatchesの見分けが付けば、俺もありだと思う。」

SKR「あ～そっか、いつも正規表現するってわけじゃないものね。」

SSK「今後の発展に期待…かな。」

前回＜＞次回

2011年8月8日月曜日

第2回 Java7はここが違う！

前回＜＞次回

登場人物

NRT
猪突猛進なプログラマー
考える前に体力勝負でプログラミングするタイプ。
たまに鋭い洞察力を見せるため、
周囲からは落ち着いてさえいれば…と言われている。
SSK
冷静沈着なプログラマー
20:80の法則に習い、実は仕事の一部分を学習に当てている。
他の人はそれに気がついていない。
Java7についても以前からチェックはしていた。
SKR
紅一点なプログラマー
暗算は早いけど、プログラミングはそこそこ。

※登場人物は忍者ではありません。架空のプログラマーです。

新機能：Underscores in Numeric Literals

※前回から会話が続いています。

SSK「しかし、これはこれで見にくいな。」

   0b0001001000110100 
 & 0b0100001100100001
// 0b0000001000100000 ←これが答え

結果：544

NRT「見にくい？“0”と“1”が並んで見やすいってばよ？」

SSK「じゃあこの計算結果を暗算で出すとしたらどうだ？」

NRT「なぬ～！？(目をこらして)…6ビット目と9ビッ」

SSK「(さえぎる)そこで間違えているぞ。6ビット目と10ビット目が正解だ。
       32＋512で544になる。」

NRT「そんなこと言ってもよ？
       こんなに“0”と“1”が並んじゃ………ハッ！？」

SSK「そういうことだ。
       数字が長く並ぶほど読みにくくなる。
       別に10進数でも起こりうることなんだが、2進数では特に顕著だ。
       SKRなら間違いはないだろうが…嫌な顔はされるかもな。
       NRT、どうしたらいいと思う？」

NRT「普通に考えたら4桁ごとに区切ればいいってばよ？」

   0b 0001 0010 0011 0100 
 & 0b 0100 0011 0010 0001
// 0b 0000 0010 0010 0000 ←これはコンパイルエラー

NRT「うげ、コンパイルエラーだってばよ…」

SSK「だがその発想で正解だ。
Java SE 7からは“_”(アンダーバー)で区切れるようになった。」

   0b0001_0010_0011_0100 
 & 0b0100_0011_0010_0001
// 0b0000_0010_0010_0000 ←これが答え

NRT「おお！コンパイルが通ったってばよ！？
       でも“0b”と数字の間には使えないのか…」

SSK「ああ、“0b_0010”や“0x_11BF”のような書き方はできない。
       そこは制限だと思ってくれ。
       代わりに、“123__456”(アンダーバー2連続)な書き方はできる。
       前後の兼ね合いで長めに伸ばしたい場合でも何とかなるわけだ。
       だが小数点の前後“3._14”、“1_.14”はアウトだ。」

NRT「う～ん、使い方を間違いそうでおっかないってばよ…」

SSK「そこまで身構える必要はないだろ。
       コンパイルエラーならIDEが自動検知できるしな。」

NRT「IDE………そういや、なんでさっきからeclipse使わずにメモ帳なんだってばよ？」

SSK「eclipseの公式サポートはまだらしい。
       β版があるそうなんだが、まだ入れてない。
       数ヶ月もすれば出るんじゃないか？」

NRT「了解♪じゃあ、俺はそれまでゆっくりしてるってばよ～」

SSK「(勉強しろよ…)」

前回＜＞次回

追記：ああ、Rubyでは実装済みなのね…

2011年8月3日水曜日

第1回 Java7はここが違う！

前回＜＞次回

登場人物

NRT
猪突猛進なプログラマー
考える前に体力勝負でプログラミングするタイプ。
たまに鋭い洞察力を見せるため、
周囲からは落ち着いてさえいれば…と言われている。
SSK
冷静沈着なプログラマー
20:80の法則に習い、実は仕事の一部分を学習に当てている。
他の人はそれに気がついていない。
Java7についても以前からチェックはしていた。
SKR
紅一点なプログラマー
暗算は早いけど、プログラミングはそこそこ。

※登場人物は忍者ではありません。架空のプログラマーです。

新機能：Binary Literals

SSK「NRT、これがいくつだかわかるか？」

(Javaのソースを見せる)

0x1234

NRT「ん、1,234だろ？それがどうかしたかのかよ？」

SSK「(ため息)…こんなやつが同じチームだとはな。」

NRT「な、なにを～！」

SSK「よく見ろ、頭に“0x”が付いてるだろ。」

NRT「それが？」

SSK「………この場合16進数表記になるんだよ。ほら…(エンターキーを押す)」

System.out.println(0x1234);

結果：4660

NRT「何だと～！？え～と、二桁目が16×3だから、え～と、え～と…」

SSK「SKRは10秒くらいで答えていたぞ。」

NRT「さっすがSKRちゃんは優秀だってばよ！」

SSK「お前も見習え…で、次はこれだ。…別に10進数で答えなくていいからな。」

0x1234 & 0x4321

NRT「今度は間違えない！ビット演算だなぁ～………で、あれがこれで、それが～あ～だから…」

SSK「もういい、今日の話はここだ。」

NRT「どういうことだってばよ？SSK！？」

SSK「Java SE 7からは2進数が書けるようになったってことだ。
“0b”もしくは“0B”を頭につけた数は、2進数として扱われる。
つまり、さっきのはこう書き換えられる。」

0b0001001000110100 & 0b0100001100100001

SSK「改行を入れるとさらに分かりやすくなる。」

   0b0001001000110100 
 & 0b0100001100100001

NRT「これなら簡単だってばよ！つまり、答えはこうなる！！」

   0b0001001000110100 
 & 0b0100001100100001
// 0b0000001000100000 ←これが答え

結果：544

SSK「どうやら気が付いたようだな。
       このように2進数表記で書くと、読みやすくなる部分は多い。
       NRTでも簡単に読めるようになるってわけだ。」

NRT「ぐっ…くやしいけどその通りだ…！
       でも、何で今まで無かったんだってばよ？」

SSK「………そういえばそうだな。
       難しくはないはずなんだが…」

前回＜＞次回

2011年8月1日月曜日

第0回 Java7はここが違う！

＞次回

もっと揉めて遅くなるんじゃないかとか、
実は妖精の見せていた幻覚なんじゃないかとか思っていました。

しかし7月28日、本当にJava7がリリースされてしまいました。

何やら/.Jではバグ話で盛り上がっているみたいですが、
そのうち修正されることでしょう。
(そもそもファーストリリースは一律信用しないものです。
わ～石投げないでくださいよ～(泣))

なので、普及する前にJava7の構文について特集しようと思います。
全部で7項目なので、全7回の予定です。

間に無関係なおバカ投稿も挟むかもしれませんが、
ちゃんと回ごとにリンクを貼るようにします。

また、英語レベルが低いので誤訳がいっぱいあります。(確信)
ブログを見に来たエロイ人は、
問答無用で誤訳を切り捨ててください。
ちゃんと修正します。

本人はRubyに移行する気満々ですけど、
Javaは仕事で使うし、仕方ないね。

では、次回にまた会いましょう。

＞次回

2011年7月22日金曜日

強制ログローテート

t-katochinさんが開発したlog4jの拡張アペンダをさらに拡張してみました。
[log4j] いいとこどりAppender

名前は「org.mericle.log4j.ForcedDailyRollingFileAppender」です。

どんな拡張かというと、
ログローテートを*必ず*実行する機能です。

例えばバッチ処理でログに加工を行う場合、
バッチが動作するまでにログローテートが行われている必要があります。

ですが今までのアペンダには、
ログローテートのタイミングは*最初の*ログ出力時という問題があります。

日次でローテートを行い、
バッチ処理が0時05分だったとしましょう。

もしも0時丁度から0時05分までにログが出力されなかったとき、
その日のバッチ処理が行えないことになってしまいます。

今まではそうした要件がある場合、
ログローテートのためにログ出力を行うことで対応していました。

ただそのためだけに、
別のバッチ処理が発生することになってしまいます。

また、ローテート用のあまり意味のないログが出力されることにもなります。
要件次第ではこれが許されないことがあります。

同じことを要求される案件が3つ目を迎えたとき、
このアペンダの作成を決意しました。

このアペンダは日次なら0時丁度にログローテートされます。
分次、週次、月次、年次にも(理論上は)対応している憎いやつです。

スレッド処理があるので不安がありますが、
JMeterでの10万回試験では問題は見つかっていません。
…きっと大丈夫！

同じ悩みを抱えたマイノリティな仲間がいましたら、
その助けになることを祈ります。

○バイナリ
log4j-extention-1.21.jar
※JDK6でコンパイルしています。

○ソース
log4j-extention-1.21-sources.jar
※Seasarファウンデーションソフトウェアライセンスに従ってください。
※2011-07-26追記：ちょっとコメントを直しました。
※2011-11-30追記：ローリング→ローテートに変更。なぜかこう言ってしまう…あ、アペンダ名か！

2011年6月16日木曜日

Javaでフォルダ内のファイル一覧をフィルタリングする

久しぶりにJavaの話題でもします。

Fileクラスでフォルダ内のファイル一覧が取得できますが、
そこにファイル名や拡張子でフィルタリングをしたいときがあります。

if文を使っている方…もっと良い方法があります。
FilenameFilterを使う方がスマートです。
使い方はJavadocでも読んでください。

まあインターフェースを継承して実装する必要があるので、
普通はApache Commons IOのファイルフィルタを使うでしょう。

では一から実装する場合はどうするのがスマートなのか？
ひとつの解答がこちらです。

つまり正規表現で何とかするわけです。
ファイル名でのフィルタリングなら、
ほぼこれひとつでどうとでもなることでしょう。

正規表現の書き方？
Javadocを…というかまずはそれを読め！

追記：ああ、Apache Commons IOにも正規表現フィルタはあるんで、
興味本位以外ではそっちを使ってくださいね。

登録: 投稿 (Atom)