現場で使えるJavaライブラリーのサンプルを丸写ししてみた。

最近次のような本が発売されました。

現場で使えるJavaライブラリ
竹添 直樹 (著), 島本 多可子 (著), 小津 美夕紀 (著), 亀井 隆司 (著)
翔泳社 (2011/7/16)

で、早速そこに載っているライブラリーを試してみました。

charts4j

各種のチャートをWeb上で処理してくれるライブラリーです。

@Grab(group='com.googlecode.charts4j', module='charts4j', version='1.3')
import com.googlecode.charts4j.*;

def plot1 = Plots.newBarChartPlot(Data.newData(20, 100, 10, 30), Color.BLUE)
def plot2 = Plots.newBarChartPlot(Data.newData(50,  80, 30, 70), Color.RED)

def chart = GCharts.newBarChart(plot1, plot2)

chart.setTitle('Sample')
chart.setSize(400, 300)
chart.setBarWidth(40)
chart.setGrid(10, 10, 2, 2)
chart.addXAxisLabels(AxisLabelsFactory.newAxisLabels('A', 'B', 'C', 'D'))
chart.addYAxisLabels(AxisLabelsFactory.newAxisLabels('0', '50', '100'))

def url = chart.toURLString()

実行した結果のURL

http://chart.apis.google.com/chart?cht=bvg&chxt=y,x&chs=400x300&chtt=Sample&chbh=40,4,8&chg=10.0,10.0,2,2&chco=0000FF,FF0000&chd=e:Mz..GaTN,gAzMTNsz&chxl=0:|0|50|100|1:|A|B|C|D

実行結果の画像

なかなかやりおる。
コードがGroovyっぽくないので、すこしリファクタリングしないとダメですね。

ランダムの妥当性とは？～その2

前回はランダムを発生させるところまでやったのだが、発生するランダムな値が本当にランダムかわからないという問題があることがわかったので、今回は少し検証してみようと思う。

まずは、発生している値の平均値が10であるか検証。
これ基本です。

def getAverage = {map ->
    def size = map.size
    def sum = withPool {
        map.parallel
        .map{it.value}
        .reduce{s, i ->
            s + i
        }
    }
    sum / size as double
}

def testMap = [[key:1,value:11], [key:2,value:9], [key:3,value:10]]
assert 10.0 == getAverage(testMap)

下のassertは平均値を算出したメソッドが妥当かテストしているだけです。
では、おもむろにテストしてみる。

10.times{
    assert 10.0 == getAerage(getRandom(20 * 10))
}

とりあえず、大丈夫なようだ。

つぎは分散を算出する。これも基本です。

def getSigmaSquare = { map, avg ->
    def size = (map.size <= 2)? 2 : map.size
    def sum = withPool{
        map.parallel
        .map{
            def dif = it.value - avg as double
            dif * dif
        }
        .reduce{s, i ->
            s + i
        }
    }
    sum / (size - 1) as double
}

def testMap = [[key:1,value:11], [key:2,value:9], [key:3,value:10]]
assert 1.0 == getSigmaSquare(testMap, 10)

下のassertは分散を算出したメソッドが妥当かテストしているだけです。
では、おもむろに実行してみる。

10.times{num ->
    def rand = getRandom(10 * 20)
    def avg = getAverage(rand)
    def sigs = getSigmaSquare(rand, avg)
    def sigm = Math.sqrt(sigs)
    println sprintf("num : %2d / avg : %5.1f / sigs : %5.1f / sigm : %4.1f", num, avg, sigs, sigm)
}

実行結果

num :  0 / avg :  10.0 / sigs :  11.8 / sigm :  3.4
num :  1 / avg :  10.0 / sigs :  10.5 / sigm :  3.2
num :  2 / avg :  10.0 / sigs :  16.1 / sigm :  4.0
num :  3 / avg :  10.0 / sigs :  10.6 / sigm :  3.3
num :  4 / avg :  10.0 / sigs :  10.3 / sigm :  3.2
num :  5 / avg :  10.0 / sigs :  11.6 / sigm :  3.4
num :  6 / avg :  10.0 / sigs :   9.9 / sigm :  3.1
num :  7 / avg :  10.0 / sigs :  10.8 / sigm :  3.3
num :  8 / avg :  10.0 / sigs :   8.5 / sigm :  2.9
num :  9 / avg :  10.0 / sigs :   5.3 / sigm :  2.3

発生した値はだいたい、10 ± 3.5 程度にあるということになるのだろうか。

ランダムの妥当性とは？～その1

小難しいタイトルですが、ランダムの妥当性ってなんなのか考えてみることにしました。

とりあえず、スタートのスクリプトは@fumokmmさんのエントリー『Groovyで範囲内乱数』です。

では、スクリプトをどうぞ。(コピペ)

IntRange.metaClass.define{
    random{
        int from = delegate.isReverse() ? to : from
        int to = delegate.isReverse() ? from : to
        int size = to - from + 1
        (Math.floor(Math.random() * size) + from) as int
    }
}

これで、乱数発生の装置は作成できたので、おもむろに作成した乱数をListにぶっこむ処理を書いてみる。

range = 1..20
def getRandom = {run ->
    def values = []
    run.times{values << range.random()}
    withPool {
        values.parallel
        .map{[it, 1]}
        .groupBy{it[0]}.getParallel()
        .map{it.value = it.value.size();it}
        .sort{it.key}
        .collection
    }
}

そして、実行してみる。

getRandom(20 * 10)

予想される結果としては、1～20までの数値が10個を中心として発生するはず。 実行結果1

[1=4, 2=7, 3=7, 4=14, 5=12, 6=10, 7=12, 8=12, 9=5, 10=10, 11=10, 12=5, 13=8, 14=11, 15=12, 16=19, 17=6, 18=18, 19=10, 20=8]

実行結果2

[1=11, 2=8, 3=11, 4=5, 5=10, 6=10, 7=11, 8=7, 9=14, 10=12, 11=9, 12=11, 13=10, 14=14, 15=10, 16=10, 17=7, 18=12, 19=8, 20=10]

実行結果3

[1=10, 2=10, 3=10, 4=9, 5=14, 6=15, 7=8, 8=11, 9=10, 10=8, 11=7, 12=9, 13=10, 14=10, 15=11, 16=6, 17=10, 18=5, 19=10, 20=17]

む、一応、ランダムに数字が発生しているような気がするが、これはランダムと言えるのだろうか？

Android Bazaar Conference 2011 Summer に行ってきました。

国内最大のAndroidに関するイベントAndroid Bazaar Conference 2011 Summer に参加してきました。

私自身は一般参加として登録しましたが、Androidテスト部の展示のお手伝いをしてきました。

当初、monkeyrunnerでテスト部で作成したTwitterクライアントを実機上で走らせるデモを行う予定だったのですが、準備不足マシンの調子が悪く、スムーズにデモを開始できなかったため、一人TDDデモをやってみました。

ネタはいつものアレです。

お題：ボウリングのスコアを算出するプログラムを作成せよ。

• 条件
• テストコードとソースコードを作成する。
• 入力は配列もしくはjava.util.List<Integer>の形で与えられる。
• ストライクの後には0が設定されるものとする。
• ガーター、ミスはともに0が設定されるものとする。

というやつです。

これを声を大きくしながら実演すること6～7回。
さすがに疲れましたが、

• TDDというのを聞いたことがあったが、実際にこうやるものだと思わなかった。
• 非常に面白かった。
• 今度会社でやってみようと思う。

といった声をきかせていただいたので、非常に満足な結果になったと思います。

実はこれ、Androidというプラットフォームに関係の無いネタだったのです。
しかし、ソフトウェアの特性上、何らかの判断などを行うので、表示機能やセンサー周りでないモデル・ロジックの部分での開発にTDDを組み込んでいくというのは避けて通れません。
その点でTDDにより常にフィードバックを受けて、自信を持って開発していけると、最終的に(保守的にも新規機能追加に関しても)品質の高いソフトウェアを開発できると思います。

---

個人としてはAndroid Developers' Club （デ部）のゆかいな仲間たちによる「Android3.0/3.13.2 HoneycombとAPI解説」を聞いてきました。

最近人気のあるArduinoなどのサポートが強化されておりますし、各種コントローラーをつなげることもできるようになっているあたりは非常に面白いと思います。
また、3.0以降に追加されたFragmentについても簡単ですが解説されていて、実際触ってみたいと思いました。

…エミュレーターが重くなければなw

今すぐフォローしておきたいAndroid テストクラスタ

ネタでtweetしたら、色々追加されたので、改めて適当に脚色をつけて紹介。

• 
  @miyatay
  Android テスト部の部長です。
  エンタープライズでAndroidアプリを開発していて、JenkinsとかMavenとかも活用しているらしいです。テストを書かないでコミットすると以下略。
  
• 
  @ussy00
  「ぬ」社所属のクールなプログラマ
  淡々とチケットを登録して、タスクを消化していく様がとてもカッコイイ。コミットにチケットが関連付けられていないと気持ち悪いらしい。
  
• 
  @nowsprinting
  Android テスト部 ソースカツ課の頼れるリーダー
  Androidテスト部公認(?!)アプリ(リリースされていませんがw)testterの最もコミット数の多いリーダーです。testterのコンポーネントに関して胸ぐらつかみ合いの大げんかをして、「テストってなんだろう？」と海を見つめながら語った記憶が…(嘘)
  
• 
  @sassy_watson
  ダッフィー好きなプログラマー
  Android用くるくる回るブラウザを作ったり、Java初心者プログラマーにJUnitテストを丁寧に教えるイケメンプログラマー。イケメンと煽ると反応が(ry
  
• 
  @oota_ken
  テストについて語らせると、とどまることを知らないテストプロフェッショナル
  TDDに関しての研究や実績があるAndroidテスト部最強のソルジャー。実はAndroidよりWP7の方が(お察し下さい)。
  
• 
  @myb1126
  Android 横浜PF部の人で、相当なギーク
  Javaは知らない(自称)らしいですが、Jythonでmonkeyrunnerを走らせるのが得意。効率悪い仕事をするともれなく突っ込まれる。ほむほむと呼ぶとアイコンが変わるというもっぱらの噂。
  
• 
  @bols_blue
  大学院でgccポーティングオレオレコンパイラーを作った猛者
  JUnit～monkeyrunnerまで幅広くカバーするAndroidテスト部のきのこ。オレと住んでいるところが近いため、センドロにてただいま休戦協定中。著書多数。
  
• 
  @dicea
  所謂上流テストツールを作っている会社の結構偉い人
  Android、DS、iPhone、などの操作をシミュレートするツールを製作している会社の偉い人です。ガンダムマニアなので、ガンダムのネタを振ると食いついてきます。
  
• 
  @kandayasu
  chromeに詳しい頼りになるプログラマー
  Chromeの操作に迷ったら何でも教えてくれる、頼りになるプログラマー。Eclipseでのテスト実行の遅さを嘆き、Antでテストしていく強者。
  

オレあまりAndroidクラスタのコアな人達知らんので、これくらいしか挙げられんっす。情弱者ですいません。

番外編

Androidというよりはテストの人たち。

• 
  @snsk
  Androidテスト部の副部長
  マックとお酒とデシジョンテーブルを愛するテストマネージメントプロフェッショナルな勉強家。行動力もあって、流石副部長というお方です。
  
• 
  @goyoki
  組み込みTDD王子
  TDDの研究・普及に活躍するテスト会のイケメン王子。@snsk副部長のTDDの師匠であり、@oota_kenのよきパートナーである。テストでわからないことがあれば、迷わず質問すべきである。
  

オレ？
しがないエロオヤジですよ。

Apps API Japan kickoff mtg #1 2011-07-12に参加してきました…よ！

Apps API Japan kickoff mtg #1 2011-07-12に参加してきました。

参加者のつぶやきなどはtogetterにまとめられております。


印象に残ったことだけまとめます。
というか、ブログを書いているのが開催されてから数日経ってしまったので、忘れつつあるので。

@shin1ogawaさんによるApps APIって何なの？美味しいの？

資料はこちらです。

要点を課題解釈してまとめると、Google Apps Scriptは次の利点があるとのことです。

• Google Apps を利用しているユーザー(企業)であれば、ちょっとしたこと(結構色々とメールを送ったりとか、ワークフローを作ったりなど)をApps Scriptを書くことで効率化できる。
• 作ったApps Scriptはきっと他のユーザー(企業)も使えるものなので、Apps Script自体を売ることができる。したがって、今までシステムを利用するだけだったユーザー(企業)が、逆にシステムを提供する側に回ることができる。

まあ、最初の利点は特別なことでもないですが、二つ目の点は今後の企業におけるITのあり方を変える可能性があると思いました。

次に参考になったのが東大卒のGoogleの新入社員の方による発表で、Google Appsの覚え方(チュートリアル)を教えてもらいました。

手順は簡単らしいです。

• Google Docsの「ツール」→「エディタ」
• Apps Script Editorにて「ヘルプ」→「チュートリアル」
• チュートリアルにある「Beginner」「Intermediate」「Advanced」の順にこなしていくだけ

これで、かなりのものが作れるようになるらしいです。
オレも来月チュートリアルをこなしていきたいと思います。

さて、今回の勉強会では @nouzui2007さん にお会いしました。
@nouzui2007さん は第一回Android千葉支部MTGのあたりから
Twitterで絡むようになったのですが、
実はお会いするのも初めてで、かつ、実は埼玉支部の方だったので驚きました。
今後とも宜しくお願いします。

それから、会場にいらした皆様、今後とも宜しくお願いします。

Groovyで、簡単なファイルのリストを作る

最近にわかに流行ってきているGroovy。

早速、Groovyで簡単なファイルのリストを作るスクリプトを書きました。

と、いっても、これはGroovyだけでなく、Gantの記事でもあったりする。

お題 : ある特定のフォルダにあるファイルの一覧を取得して、「;(セミコロン)」でつないで表示する。

import groovy.io.FileType
libDir = 'C:/Users/mike/IdeaProjects/Slim3Sample-03/war/WEB-INF/lib'
def libs = []
new File(libDir).eachFile(FileType.FILES){
    libs << 'lib/' + it.getName()
}
println libs.join(';')

このソースをご覧になるとわかると思いますが、Slim3のライブラリーの一覧を取得するスクリプトです。
結果はこうなります。

lib/appengine-api-1.0-sdk-1.5.0.jar;lib/appengine-api-labs-1.5.0.jar;lib/junit-4.7.jar;lib/ktrwjr.jar;lib/slim3-1.0.11.jar

まあ、とくにどうということもないのですが、これをAntでコンパイルせぇ!と言われた時に、このスクリプトは役立ちます。

改題 : AntをGroovyから実行せよ

Gantを使います。

import groovy.io.FileType

srcDir = 'src'
bldDir = 'bin'
def libs = []
libDir = 'lib'
new File(libDir).eachFile(FileType.FILES){
    libs << 'lib/' + it.getName()
}

includeTargets << gant.targets.Clean
cleanPattern << '**/*~'
cleanDirectory << bldDir

target(compile : 'Compile java file into build directory'){
    depends(clean)
    javac(srcdir : srcDir, destDir : bldDir, classpath : libs.join(';'))
}
target(hello : 'default task'){
    echo(message : 'to compile java sources use : gant compile')
}

setDefaultTarget(hello)

Antのbuildファイルを作成するときに一番嫌なのは、classパスを色々とかくことで、これがGroovyで引っ張ってこれるなら、そうしておいたほうがらくでいいですね。

あとは、おもむろに次のコマンドを打てばおしまい。

gant compile

Java SE7 launch イベントに行ってきました。

JavaSE7が7/28(木)にリリースされます。
それに先んじてJavaSE7の機能を紹介するJavaSE7 launch イベント、『返ってきたJava HotTopicセミナー』が開催されましたので、参加してきました。
参考リンク : Oracleの方
参考リンク : 寺田さんの方

内容については、ブログを御覧になっている方もだいたい存じ上げていると思いますので(ｴ?)、省略しますが、togetterにも内容に関するつぶやきがまとめられていますので、参考にしてみてください。

また、一部の機能については「きしだのはてな - Java SE 7のjava.nio.file.Filesがとても便利な件」や、桜庭さん(@skrb)の「Java in the box Annex - Project Coin」などに実例が挙げられていますので、参考にしてみてください。

以上。


…


えっ、たりない。
そうですよね。

会場内での出来事を記述するにとどめますね。

InvokeDynamicのセッションの間ですが、
「うぁ～！オイッお前、いい加減なこと言ってんじゃね～よ！あんたLL言語詳しくね～だろ！」
と、参加者の方から発言がありました。

案の定、会場は凍りついてしまいました。
確かに、このInvokeDynamicの説明の時間帯のTLは発表内容に関係の無いことがずっと流れていたと思います。

例えば、この時間帯にオレが流していたのは、Project Coinの新機能、intの'_(アンダースコア表記)'に関する疑問についてでした。

int value = Integer.parseInt("1_000");

これをやると、もれなくjava.lang.NumberFormatExceptionが発生するということについてでした。

このセッションを担当されていた方は、自分で「LL言語はそれほど詳しくない」と誤っておりました。

じゃあ、なぜこのセッションを担当していたのか？なぜ、InvokeDynamicに詳しくないのかといったあたりが、オレとしては不思議に感じていました。


さて、この件については、あとでなるほどと思うことがあったのでそれを伝えたいと思います。

後ほど、懇親会に参加したのですが、そこでLT大会が開催されました。

そこで、JRubyおよびCRubyコミッターの@nahiさんの『JRubyでもInvoikeDynamic』というLTがありました。
このLTの後に寺田さんがフォローしていましたが、JavaSE7のInvokeDynamicはJRubyコミッターからの意見が積極的に取り入れられた機能であったとのことです。

なるほど、動的言語の側からの要求で仕様を策定したのだから、Java屋はうまく説明できないなと、さっきの疑問が妙に解決する感覚を覚えました。

…

というわけで、懇親会は本会ではわからないような重要なウラ話などを聞けるわけで、
こういう機会はなるべく積極的に参加したほうがよいと思います。

とか、言いながら二次会を回避しました←オイ。

なんとかDDをまとめてみた

情弱なので、なんとかDDというのがどういうものかあまり良くわかっていないので、キーワードだけでもと思って、まとめてみた。

TDD

Test Driven Development

テスト駆動開発。
私が初めて知ったなんとか駆動開発というやつです。
ソフトウェアのコンポーネントに期待する振る舞いをテストとして記述して、そのテストを通るように単純に実装していく手法(間違っていたら、ツッコミをお願いします)。比較的コンポーネントが単純になるので、変化に強いソフトウェアが作成される。
代表的なフレームワークにJUnitがある。

BDD

Behavior Driven Development

振る舞い駆動開発。
TDDの発展した形態の開発手法。要求仕様を自然言語に近い形で記述し、それをソフトウェアが満たすように実装していく。
代表的なフレームワークにRSpecがある。

DDD

Domain Driven Design

ドメイン駆動設計。

'複雑なドメインの設計はモデルベースで行うべきであり'、'また大半のソフトウェアプロジェクトではシステムを実装するための特定の技術ではなくドメインそのものとドメインのロジックに焦点を置くべき'とする
出典 Wikipedia

TiDD

Ticket Driven Development

チケット駆動開発。
Redmine、Trac、JIRA、BacklogなどのBTS/ITSに登録されたチケットをベースに開発していく手法。
現在のタスクの状況が把握しやすく、VCSとの連携により、どのようなコミットなのかも関連付けて管理できる。

23:33 @diceaさんからTiDDということを教えていただきました。

2011/07/06 20:38 追加
次のなんとかDDは、ktz_aliasさんに教えてもらいました。

RDD

Responsibility-Driven Design

責務駆動設計。
オブジェクトに必ず責務を持たせて設計する設計手法。また、その責務に6つのパターンを当てはめるという方法。
全然知らない言葉だったので、こちらを参考にどうぞ。
Pinto公開に向けて #16 ― 責務駆動設計で仕切り直すことに決めた - 岩本隆史の日記帳

こっから下はネタなので注意。

EDD

Excel Driven Development / Excel Driven Design

エクセルで設計、開発。
これは実は近年のアンチパターン。
COBOLの時代には効果があったかもしれない。なぜならCOBOLは一台しかなく、マシン上でテストする場合に事前にバグを取り除いておく必要があったし、いやそもそもマシンにコードを打ち込める人など限られた人たちだけだったから。
この時の開発手法に慣れた人がExcelでのドキュメントでバグを取り除くという考え方を引きずったまま、現代の誰でもIDEを持っている環境で、この手法を使うと、面倒なことを何度もやらなければならないので、プログラマーは間違いなくやめるか、職業プログラマーになり下がる。
一方で、プログラマーを単なる代替可能なリソースとしてしかとらえていない人からすると、Excelからプログラムを算出できるのは魅力的であり、Excelからプログラムを出力することに執念をかけている人もいる。

PDD

Politics Driven Development

政治駆動開発。
どんなに完全などを現場が提案しようと、もはや決まったものは決まったものとして実施せざるを得ない開発手法。
根回し、資本関係、上司とのコネクション関係、契約関係ありとあらゆる交渉上優位になる条件を確実に抑えていって、何が起ころうとも、すでに何もかもが決定しているという残念な開発手法。
ボッチプログラマーやコネクションがないプログラマーは、たとえ決まった方針が間違っているとしても従わざるを得ない。

SDD

Smoking-Room Driven Development

喫煙室駆動開発。
会議では建設的な意見が出てこないため、喫煙室でいい加減に言ったアイデアが通ってしまうという、非喫煙者にとって最悪な開発プロセス。
喫煙室ではお客さんもポロっと本音が出るために、意外と本当の要求が聞けたりするのだが、この手法の残念なところは、その情報を得た人たちが、喫煙所で決定した事項をなんらのWikiとかメールで共有することなく動く点にある。
そのため、会議室とか作業部屋で作業している人からすると、突然方針が翻ったりして、はっきり言って、喫煙野郎を殴ってやりたくなる。

DDD

Deadline Driven Development

締め切り駆動開発。
リリース日から逆算してスケジュールを決めていく開発手法。
とくに何の戦略もないPJがとる手法の一つ。
ただただ、人材が送り込まれてくるだけで、スキルもバラバラなので、どうしようにも手が負えない。
PJの末期状態。

ZDD

Zangyo Driven Development

残業駆動開発。
最初から社員の残業をあてにしてスケジュールを組んでいる、最悪なPJの開発手法。
いや、もしくは職業プログラマーが残業手当を見越してわざと残業しているという生産性無視の開発手法。
いずれにしても、PJの後半で体力的にきつくなって、倒れる人が続出するのでやめたほうがいい。

まあ、その他いろいろあると思うので、みなさん教えてください。

Selenium勉強会に参加してきました。

昨日(2011/07/03)、Selenium勉強会に参加してきました。

最近は殆どの業務システムはWeb化しているので、
テストの自動化には避けられないのがSelenium。

しかしながら、Seleiniumについては触ったことがなかったので、
勉強がてら参加してきました。

というか、この勉強会の趣旨は、
講師なし、皆で学ぶというものだったので、
かなりぴったりな勉強会でした。

今日はそこで勉強したことのまとめを
書こうと思います。

このページをご覧になるであろう方は、
ほとんどの方はSeleniumを触ったことの
ある方だと思いますので、簡単なことしか
書かれていません。

• Selenium IDEのインストール
• Selenium IDEでテストケース作成
• Selenium RCのインストール
• Selenium RCでテストケース作成

Selenium IDEのインストール

• Fire Foxをインストールする。
• Selenium IDEをインストールする。
• 
  
  • Windows の場合、Fire FoxでSeleniumのサイトからダウンロードリンクをポチる。
  • Mac/Linuxの場合、Fire Foxのツール→アドオンからSeleniumを検索して、ダウンロードする。

Selenium IDEでテストケース作成

• Fire Foxを起動する。
• Selenium IDEを起動する。
• Selenium IDEで新規テストケースを作成するを実行
• 赤丸ボタン(記録ボタン)を押す。
• 操作をする。
• 出力されて欲しい文字列を画面上で選択して右クリック→verifyほげほげを選択する。
• 赤丸ボタンを押して、記録を終了する。

Selenium RCのインストール

前提条件 : Java Development Kitがあること。

• Selenium RC のスタンドアローンサーバーをインストールする。
• 以上w

Selenium RCでテストケース作成(Java)

前提条件 : JavaのIDEがあること。

• Selenium RC のJavaバインディングをダウンロードする。
• IDEでJavaプロジェクトを作成する。
• Javaプロジェクト上で、Javaバインディングをライブラリーに追加する。
• Selenium IDEで作成したテストケースをJavaファイルに出力する。
• 出力したJavaファイルをIDEに取り込む。

Selenium RCでテスト実行

• コマンドプロンプトで次のコマンドを実行する。
• java -jar selenium-server-standalone-.jar
• テストケースを実行する。

といった基本を学んできました。

結構、オレオレメモなのであまり参考にならんかも…
まあでも、一人でSeleniumを勉強するよりは道連れ初心者同士が集まって勉強すると、不安がなくなりますね。

Shibuya.trac 第12回勉強会 【通常枠】に参加してきました。

Shibuya.trac 第12回勉強会に参加してきました。

詳細は@kimkou_26さんがtogetterしてくれるだろうから、それを待つとして、オレの勝手な印象だけを書いときます。

まずは結論

どのITS/BTSがいいなんて結論などないんですよ。もちろん開発がRubyの場合は、変にプラグインをいれて依存性地獄に陥らないためにRuby系以外のものでやるというコンテキストがありますが。

問題はいかにプロダクトを創りだしていくかであって、その間のプロセスはどうでもよいのだ！勝った！死ねい(Dio風に)

ただ、そこまでのプロセスがSIであれば人を詰め込むだし、プログラマーであればツールを用いてスマートにするわけであり、それぞれの物象形態がExcel、ITS/BTSなのだと思います。

で、それぞれのツールですが、

Trac

• Good : Trac Lighteningが非常に優秀。インストールとか超簡単だし。Apache、svn、Jenkins標準装備だし。
• Bad : 実はPythonほとんど読めないので、カスタマイズできないんです。
• Good : SQLの形でクエリを組むことができる。
• Bad : 言い換えると内部の仕組みを知らないと欲しいレポートが書けない。
• Bad : プラグインに統一感がない。
• Bad : 素のままだとかなり使いづらい。

Redmine

• Good : 個人的にですが、ubuntuでsudo apt-get install redmineするだけで、インストールできるのが好きです。
• Bad : 結構、動くようになるまで設定するのが面倒くさいです。最近やっと弊社(2011/07/01現在所属している会社)でもRedmineを使うようになったのですが(いや、オレが強引に使わせるように仕向けただけですが)設定で半日はかかっています。
• Good : UIの統一感がある。
• Bad : Ruby系開発だと動作環境に気を使わないといけない。
• Good : 個人的にRubyは読めるので、何がどうなっているかはわかる。
• Bad : カスタムタグを作るとすべてのPJで共有してしまうので、そのうちタグがカオス

JIRA

• Bad : 有償です。1,000JPY～
• Good : ショートカットキーが秀逸で、オレのようなThinkPad使いにはかなりイケテル
• Bad : まともに動くようになるまで、時間がかかる。パネラーの人で1日とか言っていたので、オレには多分1ヶ月はかかると思う。
• Good : iGoogleのようにガジェットを配置できるので、好きなように使える。

Backlog

• Good : Androidテスト部で使わせてもらっています。
• Bad : ヌーラボさんのサービスなのでカスタマイズ出来ません。
• Good : プログラマーだけでなく、デザイナーや、営業などプログラミング言語知らない人でも参加できる。
• ! : Jenkins連携機能があるらしい。初めて知りました。
• Bad : Git多分対応していないんじゃないかな～
• Good : 絵文字とかCacoo(ヌーラボさんのサービス)との連携など、SNS的な使い方もできる。

という感じです。
Trac/Redmine/JIRAはプログラマーがターゲットで、Backlogは他の人達もターゲットというあたりに特色を観ることができます。
第一部はこんな感じでしたが、第二部は実はどのツールでも共通することが語られていたと思います。

BTS/ITSってどうなのよ

• ツールは最初は規則として使っているが、そのうち協調へと変わっていく
• 一度デジタル化して、再びアナログ化する。アナログ化するのは一回のイテレーションが終わった後の振り返りで、ポスト・イットなどの物理的な媒体で記憶を想起させるため。
• Excelを愛している役立たずでコーディングもできない偉い人にも使ってもらうため、Excelのガントチャート出力などをしてあげる。
• 開発生産性は測りづらいので、開発する勢いのトレンドを管理する。

なんか、BTS/ITSの話というよりは開発プロセスの話だったので、あまりツールのあれがこれという話にはなりませんでした。しかし、このあたりは見習うべきことが多いですね。

Redmineを受け入れない現場への三箇条

• エライおじさんは見た目がExcelだと喜ぶ
• 決定権者には「Excelなんてよくない」とdisるのでなく、「Excelのここいいですね」と褒めつつRedmineを洗脳する。
• 便利な仕組みを使うことによって仕事が亡くなる人の仕事を用意してやる

これはExcelに凝り固まった現場でITリテラシーの低い人にもRedmineを使ってもらうための工夫だそうです。
特に最後の部分は発想にはないですね。

便利な仕組みを使うことによって仕事が亡くなる人の仕事を用意してやる #shibutra

@mike_neck 仕事しなくていいから家帰れ、残業代文無駄だ

わたし、後者の方とほぼ同じ意見です。
まあ、でも仕事を奪われる人たちの身にもなると抵抗勢力になってしまうので、やんわりと勧めるほうがよいようです。

結論ふたたび

• お金があればJIRAを使う
• 大人なプログラマーはEclipseなんて使いません
• 日本語対応なんかしていなくても、英語つかえばいいじゃん

最後のは名言だと思いましたw