EvernoteAPI って若干使いにくくない？

前書き

ちょっと前に EvernoteAPI なるものと戯れていた。
そのときに、EvernoteAPI の使い方とかを調べるわけだが、まぁ少ない少ない。
自慢じゃないけど英語に対する苦手意識 100 点な私は、もちのろんで日本語サイトばっか探してたけど、それでも大体同じ方の記事くらいしか見つからない。

で、仕方なく本でも買って本格的にやるかーーと、ネットでろくに調べず本屋に行ったが．．．無い！！
Evernote の使い方みたいな本は腐るほどあるのに、EvernoteAPI に関する書籍が無い！！
なんてこったーーー！！そりゃ需要が無いからだろって？！ここに欲している人が居るでゴワす(ノД`)・゜・。

とゆーことで、自分で EvernoteAPI を触ってみた時のノウハウをここに残しておこうと思うのです___〆(・_・*)ﾒﾓﾒﾓ

まずは

Evernote の大きな概念としては、ノートブックとノートがある。簡単に言うとね。
ノートブックは複数のノートを束ねるものであり、ノートが末端の情報 1 つ 1 つを指す。
図だとこんな感じかな。簡単だけど。

EvernoteAPIでは？

じゃ〜 EvernoteAPI ではどうか。
API でももちろん同名のクラス達が居るので、もちろんこんな風に書けると普通なら（？）思うよね。

...
List<Note> notes = notebook.findNotes(...);
...

がしかーーし、世の中そんなに甘くはない(ノД`)・゜・。

EvernoteAPI では、NoteStore(.Client) というクラスが、ノートに関する振る舞いを司っていて、ノートブックを取得するのも、ノートを取得するのも、はたまたタグを取得するのも全てこの NoteStore.Client というクラスを介して取得する必要があるのだ。
具体的には以下のような感じ。

...
// ノートブックを取得
Notebook notebook = noteStore.getNotebook(authenticationToken, guid);
...

// ノートを取得
NoteList noteList = noteStore.findNotes(authenticationToken, filter, offset, maxNotes);
List<Note> notes = nodeList.getNotes();
...

// タグを取得
Tag tag = noteStore.getTag(authenticationToken, guid);
...

ちなみに上記のコードの中で使用している noteStore は、実際には NoteStore のインナークラスである Client というクラスを指す。
上記のコードに出てくるクラス達のパッケージ構成は以下のようになっている。

もう後書き

それではもう少し詳しく見ていきたいところをグッとこらえて、続きは次回ということで。
authenticationToken って何やねん？！guid って何やねん？！？！
怒らないでもう少し待ってて下さい(人；´Д｀)ｺﾞﾒﾝﾈ

今年一年の勉強会を振り返る

いや〜今年も終わりますね。年の瀬にたまにはプライベートでも振り返ってみようかなと。
で、何を振り返るかというと、今年一年開催してきた社内勉強会について振り返ってみようかな。
（プライベートと言っておきながら、半分社内やけど）

※社内勉強会なので、リンク先には PW が掛かってますので悪しからず〜(￣▽￣；）

Effective Java 読書会兼勉強会

まずは、昨年度からの継続で、書籍「Effective Java」を使った読書会兼勉強会を実施。
Effective Java は Java 中級者向けの書籍ということもあり、内容が少し難しい部分もあるが、出来る限りとっつきやすくて、出来る限り現場でも使えるようなテーマを選んで、昨年度から合わせて計5回開催してきた。

• Effective Java 読書会兼勉強会 #01
• Effective Java 読書会兼勉強会 #02
• Effective Java 読書会兼勉強会 #03
• Effective Java 読書会兼勉強会 #04
• Effective Java 読書会兼勉強会 #05

振り返り

・一番初めは手探りで始めたため、参加者の皆さんに勉強会で取り上げた各章を、勉強会の中で段落単位に読んでもらった
　→確かにその場で読むことで、その後の勉強会の内容が入ってきやすいかもしれないが、時間が掛かった。
・勉強会の FB を早くもらうために、勉強会の最後に LT を実施（１人１分）
　→時間は少し掛かってしまうが、FB もその場でもらえるし、参加者も LT のいい機会になる。これは個人的には良かったのではという感触。

単体テスト勉強会

続いて、単体テストに関する勉強会を実施。
現在携わっているプロジェクトで、「単体テスト」の重要性を再認識したので、勉強会のテーマとして取り上げた。
今回の勉強会では、レイヤーアーキテクチャを用いたある Web アプリケーションを題材に、各レイヤーに対する単体テスト（いわゆるディベロッパテスト）コーディングの書き方について勉強会を開催。

・データソース層：DBUnit
・ドメイン層：EasyMock（モックを使った振る舞いテスト）
・プレゼン層：Selenium（自動打鍵）

• 単体テストJUnit4 勉強会 #01
• 単体テストJUnit4 勉強会 #02
• 単体テストJUnit4 勉強会 #03
• 単体テストJUnit4 勉強会 #04

振り返り

・勉強会の題材として使用する Web アプリケーションを Spring Roo を使って準備
　→Spring Roo についていい勉強になった（笑）。Spring Roo についての記事は別途書く予定。
・同じ Web アプリケーションに対して、各レイヤのテストを書くことで、アプリケーションに対する説明の時間が少し省けた
　→題材としては「書籍管理」を取り上げたが、少し簡単すぎたかなと。なので、ドメイン層でのモックを使ったテストがイマイチだったかな。

リファクタリング

書籍「リファクタリング」の中から、あるまとまりのあるテーマ（例えばメソッドに対するリファクタリング）で題材をチョイス。
それらのリファクタリングテクニックを使う前と後のソースを使って、リファクタリングをしたことによる有用性を少しでもお見せできたかなと。

• リファクタリング勉強会 #01
• リファクタリング勉強会 #02
• リファクタリング勉強会 #03

振り返り

・今回は出来る限り現場でスグに使えるサンプルコードを心掛けたが、もう少しだったなぁ・・・
　→携わっていた業務の内容をリファクタリングのテーマに取り上げたが、その説明に３０分もかけてしまったのは大反省orz
・今回のテーマで初めて参加者の皆さんに事前宿題を課した。
　→提出率は（予想通り）低かったが、より参加者同士で様々な意見交換が出来た。

統括と来年に向けて

いや〜今年はほぼ毎月継続的に走り続けてきたよーー。
確かに大変だったよ。こくちーずの用意から、勉強会で使用する題材の用意。
途中からは案内メールの自動化に脱線したり、題材の準備を忘れててギリギリまで準備をしたり、本当に嘘じゃなくて、大変だったよ。
でも、間違いなく勉強になった。

題材の準備を通して、更なる内容の理解に努める良い機会になったのではと思う。
また、題材の準備を何とか効率化するために、様々なプロダクトに手を出して、ある意味いい勉強になった。
（Spring Roo、Evernote API、Selenium etc）

元々は、自分が得た知識やノウハウの整理のために勉強会を開催していたが、いつからか、「社内勉強会」をうまく運用するためにはどうすれば良いか？も考えていた。
「社内勉強会」についても、そのうち別途思うところを書こうと思う。

内容については、まずサンプルコードを積極的に見せる！これが無いとやっぱり参加者も話を聴いたり、パワポだけを見るだけだと絶対に飽きてくる。これは間違いないと思う。講師の話ベタなのも少なからずあるとは思うが・・・
あとは、そのサンプルコードも出来る限り分かりやすく、かつ簡単過ぎてはダメ。これが以外と難しいだわ。
複雑すぎる内容だと、参加者は内容の理解よりもサンプルコードの理解に頭がいってしまい、内容が入ってこない。
逆に簡単過ぎると、イマイチ内容の良さが伝わらない。この辺りはもっと自身の業務や勉強会の経験を増やして、より良いサンプルコードというのを目指していこうと思いまする！！

さて来年ですが、巳年ですね〜。特に何もないけど（笑）
来年は個人的な都合で恐らくあまり社内勉強会を開催できないかもしれないけど、出来れば継続して続けていきたいなぁ。
もっと言えば、来年は「講師（私）」→「参加者」の片方向だけでなく、双方向の勉強会を目指したいなと。

講師から参加者へはもちろんやけど、参加者はただ話を聴くだけ、というスタンスではなくて、
参加者からももっと積極的に意見を述べたり、「これがしたい」とか「こういうテーマが良い」とかをもっともっと言って欲しいなぁ。
もちろん講師である私が至らぬばかりに、参加者の声をもっともっと聞けなかったというのは否めないかもしれない。その辺りは今後の課題かな。

まぁ〜そんな一年だったけど、来年も良い一年でありますように〜。
よいおとしを〜( *｀ω´)ノ))

DevLove関西2012に参加してきた！！

選手末の土曜日に久しぶりに大阪に行く用事があり、ちょうどタイミングよくイベント開催日と重なったので、DevLOVE関西2012Driveに参加してきた。
今回はその個人的まとめ。
別に参加したセッションの内容紹介とかは、きっと他の人がされていると思うので、その辺りは省略。（自分がまとめていないだけです）

関西でこういうコミュニティに参加するのは初めてだったので、少し緊張しながら参加してきた（笑）

セッション０

開発現場を、駆動せよ -DevLOVE関西Driveがもたらすもの- by 中村洋さん ([twitter:@yohhatu])

ブログを書くまでが勉強会
ブログを書いて現場を変えるまでが勉強会

いい格言だな。
ただ、難しい！！勉強会に参加して、そこでのインプットを、現場にアウトプットする。これは簡単ではないけど、これくらいの意気込みがないと、勉強会当日のにあー良かったな。で終わってしまう。

情熱は自分自身だと。

うん、確かにその通りだ。
人の考え方を変えることはできないと思っている。
それはつまり、人の情熱を燃やしてあげることはできない。
（燃やすためのお手伝いは出来るかもしれないが）

じゃぁ自分の情熱を燃やしましょうよと。
自分自身・現場を Drive してやろうぜ！

セッション１（A-1）

乙女ゲーを支える技術 - play2.0 + Scala の開発事例 - by 粕谷 大輔さん ([twitter:@daiksy])

チームメンバがこれまで業務で使ったことのない、FWや言語について、日々の始業前30分で、勉強会を行う。そして、昼からの開発でそれを使う。
もちろん、これを毎日続けるとなると、きっと負担に感じてしまう。だから、週3日（月・水・金とか）とか間を明けて、集中してやる。

まさに Driveしてんなーと思った。

開発スタイルは、最初は担当者（きっと分析者？）が実装して、そのあと全員でコードレビュー。そして反映。
最初はこうすることによって、チーム全員のコーディング力が底上げされると。

うん。たしかに最初の頃（チームが成熟する前とか）だったらよいね。
でも、やっぱりこういうスタイルと続けると、どうしても時間が掛かってしまうので、ある程度コーディング力が底上げされたら、スタイルを変える。

次は、実装はペアプロ。

これにより、コードレビューの色も含まれているので、わざわざ全員でコードレビューする手間を省けるし、他人の目にもふれているので、自分よがりな実装にならない。
ただ、重要な昨日は全員レビューする。

うん。いいね。

セッション２（A-2）

CIの何か（仮） by [twitter:@kiy0taka] さん

Jenkins を導入してビルドからテストを実行する。
プロジェクトの立ち上げ当初とかであれば、ジョブの実行時間なんて（マシンスペックにはよるが）ほぼすぐ終わるはず。

しかし、これがプロジェクトの中盤から後半にかけてくると、実行時間が長くなってくる。
これは非常によくないよね。
だって、Jenkins を導入するってことは、テストの自動化とか（それ以外もあるだろうが）をやりたいはずだと思う。
それなのに、実行時間が遅くなってくるということは、FBが遅くなるということ。
Jenkins 上で遅いということは、個人の開発環境でテストとかを実行すると、それ以上に遅いということになる。
そうなると、開発者の心理として、自分の環境でテストを流さなくなる。
こうなってくると、負のスパイラルに上手く（？）のってしまうことになる。

ジョブの時間が掛かる →自分の環境でテストを流さなくなる→FBが遅れる→修正しようとしたら別の修正とコンフリクト→仕方なくその場対応→可読性低下→コードカオス

こうならないため、ビルドの時間が掛かってきたときの対策として、ビルドパイプラインを導入すると。
具体的に紹介されたプラグインは以下の3つ。

• Clone Workspace SCM Plugin
  • ブログ書いてみた！ちょー簡単だけど。
• Promoted Builds Plugin
  • ブログ書いてみた！これまた簡単だけど。
• Build Pipeline Plugin

詳細は…順次試してみて、ブログに書きます（笑）

セッション３（B-3）

チームづくりで１番大切なこと〜カラダで学ぶ？！チームビルディング by 福原　美砂 さん

非SEの人＆唯一の女性講師によるセッション。

チームで開発する場合のチームビルディングについてワークショップを含めたセッションでった。

チームメンバの「見えている所」だけではなく、「見えていない所」にも意識を傾ける。
「見えている所」「見えていない所」を、海に浮かぶ氷山に例えて説明が。
「見えている所」とは、相手の言葉とか。「見えていない所」とは、相手の感情とか。
見ている相手の言葉だけで相手に接するのではなく、見えていない所にも気を付けて相手に接する。

セッション４（B-4）

やる？、やらない？の対立を考える by 東 秀和さん([twitter:@oyukun])

個人的には論理的思考の命題・逆・裏・対偶の考え方とか、帰納法に近いな〜と感じた。
（それだけじゃないよｗ）

セッション５

クロージング：未来ために我々の帆をたてよう

事前に参加者から集めた「各自が抱える問題点」を元に、同じような問題点を抱える参加者でグループを作り、そのグループの中で、最も切羽詰まっている参加者の問題点について、グループの他の参加者で解決策を提示。

私もグループの中で問題だと思う点について発言したところ、なんと私の問題点が一番切羽詰まっているということに！！（笑）
その問題点はこれ。

リリースしたシステムの改修を、テストを流さずにリリースしようとする

まぁたしかに問題は問題だわな。
で、グループの他の参加者から頂いた貴重な意見は以下の通り。
みなさん、本当にありがとうございました！！！！

• ルールがない。基準が各個人。
  • →ルールを作り、意識共有・合意形成の努力をする。
• 意識・常識に依存している。
  • →修正は共有する。

• そのまま。
  • 「問題は未然に防がれている」と考え、現状を維持する。
  • 「再発可能性」は残る
• 「人間系」で解決
  • 「注意」「意識」など、「その当人への処置」のみ。
  • モチベーションは？
• 「ルール・プロセス」で解決
  • ルールを定義する。「それ自体が起こらない」「それが守られる」ようなもの。
  • 「チェックシート」「ダブルチェック」「ペアプロ」etc...
  • 「リリース後」「保守フェーズ用」用のルール。
• 「機械系」で解決
  • 「それが起こらない仕組み」を作りこむ。
  • 「コミットできない」「リリースが不可能」など。

• リスクの共有、ふりかえりを定期的に実施
• 気付ける仕組みをルール化

• リソースルールを明確にする
  • Jenkins の確認
  • 保守コードのテストコード
• コードレビューを入れる
• 当人の意識確認
  • 改善
  • リーダにお願いする

• リリース後の修正に対するフローを明確にしておくべきだった
• （テスト）→修正→レビュー→テスト→全テスト→CI→お客さんチェック→リリース
• Jenkins ビルド失敗をメール通知
• 相手の完了報告だけを鵜呑みにしない。表情・雰囲気とか見えていないところにも気を配る。

帰りの新幹線で

てな感じで、様々なセッションに参加してきた。
開発事例であったり、チームビルディングであったり、Jenkins 話であったり、TOCであったり。
挙げ句の果てには、他の参加者の方に、私が抱える問題点にまで解決策を考えていただいたりと、至れり尽くせりやな（笑）

冒頭でも書いた通り、ここで学んだことをブログには書いた。
よし、満足。違うか（笑）
でも、たしかにこうやってブログに改めてまとめてみることで、参加して感じた事とか、やってみようと思ったこととかを、体形的にまとめられるような気がした。
あの場で感じたことを Twitter とかでつぶやくだけであれば、簡単だが、どうしてもその場で終わってしまうような感じがしてしまう。これは個人的見解ですけど。

なので、ブログにまとめるっていうのは結構良いね。
（ちょっと日があいてしまったのは反省点だけど）

次は、このインプットを基に、会社なり現場なりにアウトプットせなあかんね。
一気に全部やる必要は無いと思うけど、少しずつやっていきたいね。

あとがき

とまぁ、色々なセッションやワークショップに参加して、様々なスライド（パワポ）を見て、すごい参考になった。

構成は大きく分けると以下の感じ。

• 自己紹介
• アジェンダ
• 内容

まぁ〜この辺りは別に普通と言われたら普通だと思うけど、社内のスライドとかを見てると、必ずしもこの辺りがちゃんとしているとは限らないのが現実。。

スライドの背景画像

あんまり考えずにスライドを作り始めると、大抵スライドの背景は、そのスライドのデフォルト（殆ど無地か小さなイラストのみ）になってしまうが、今回見たスライドの背景はどれもとっても個性的！！
具体的にいうと、そのスライドの内容にあった画像（主に写真）が背景として設定されていた。

このようなスライドを別に初めて見た訳ではないが、改めて考えてみると、確かに聞く側の注意を引く。
どうしても無地の背景に文字だけというのは、聞く側の集中力が続きにくいと思う。
それに、印象に残りにくい。

それに比べて画像が背景に設定されていると、聞く側は、スライドをただのスライドとしてだけではなく、一つの絵として見ることができ、印象にも残りやすい。

これは、どんなスライドでも適用できるかと言われるとそうではないかもしれないが、少なくとも社内勉強会とか、こういうコミュニティでは活かせられると思った。

当日運営をしてくださった皆様、スピーカーの皆様、一緒に Drive できた皆様、本当にありがとうございました！！

JUnit4 の実行順序

最近 JUnit にハマっています（笑）

アノテーションベースに生まれ変わった JUnit4

JUnit4 系では、アノテーションベースになり、テストがとても書きやすくなった（し、可読性も上がった）と個人的には感じている。
ただ、このアノテーション、結構な種類があり、どのアノテーションで定義されたものが、どのタイミングで実行されるのか、いまいち押さえられていない。ということで、今回はよく使われる @Before とか @After の他に、@RunWith、@Rule で指定できる TestWatcher の実行タイミングについても簡単に調べてみた。

テスト対象のクラス達

Runner

import org.junit.runners.BlockJUnit4ClassRunner;
import org.junit.runners.model.InitializationError;

public class DummyJUnit4ClassRunner extends BlockJUnit4ClassRunner {

    public DummyJUnit4ClassRunner(Class<?> clazz) throws InitializationError {
        super(clazz);
        System.out.println("DummyJUnit4ClassRunner");
    }
}

TestWatcher

import org.junit.rules.TestWatcher;
import org.junit.runner.Description;

public class DummyTestWacher extends TestWatcher {

    public DummyTestWacher() {
        System.out.println("DummyTestWacher");
    }

    @Override
    protected void starting(Description description) {
        System.out.println("DummyTestWacher#starting");
    }

    @Override
    protected void finished(Description description) {
        System.out.println("DummyTestWacher#finished");
    }
}

テストクラス

import org.junit.After;
import org.junit.AfterClass;
import org.junit.Before;
import org.junit.BeforeClass;
import org.junit.Rule;
import org.junit.Test;
import org.junit.runner.RunWith;

@RunWith(DummyJUnit4ClassRunner.class)
public class JUnitExecutionSequenceLearningTest {

    @Rule
    public DummyTestWacher wacher = new DummyTestWacher();

    public JUnitExecutionSequenceLearningTest() {
        System.out.println("SubTest");

    }

    @BeforeClass
    public static void beforeOnce() {
        System.out.println("@BeforeClass");
    }

    @Before
    public void before() {
        System.out.println("@Before");
    }

    @After
    public void after() {
        System.out.println("@After");
    }

    @AfterClass
    public static void afterOnce() {
        System.out.println("@AfterClass");
    }

    @Test
    public void test1() {
        System.out.println("@Test-1");
    }

    @Test
    public void test2() {
        System.out.println("@Test-2");
    }
}

結果

で、これを実行した結果がコレ。

DummyJUnit4ClassRunner
@BeforeClass
DummyTestWacher
SubTest
DummyTestWacher#starting
@Before
@Test-1
@After
DummyTestWacher#finished
DummyTestWacher
SubTest
DummyTestWacher#starting
@Before
@Test-2
@After
DummyTestWacher#finished
@AfterClass

ランナーは何よりも先に呼び出されるのね。
あと、@BeforeClass はテスト対象のクラスがインスタンス化されるよりも前に呼び出されるんだ〜。
確かに @BeforeClass は、メソッドシグネチャも public static じゃないと怒られるからな。そりゃそうか。
あとは、まぁ何となく予想通りかな。

@Rule の可能性

このルールクラスは何となくやけど、可能性がありそう。この辺りは別途調べて結果を載せるぜよ( *｀ω´)

注釈 − Annotation

「アノテーション」は、日本語に訳すと「注釈」となる。
つまり、ソースコードに付加情報を記すためのものである。
したがって、アノテーションの記述があってもなくても、プログラムの意味は変わらない。

「アノテーション」と「コメント」の大きな違いは、コンパイラによって処理されるか否かである。
「コメント」は、コンパイル時には無視される（空白と同じ扱い）。
「アノテーション」は、コンパイラによって、型チェックなどの処理が行われる。

つまり、「アノテーション」は、コンパイラによって処理される付加情報なのである。

実際のアノテーションの構文を見ればわかるが、アノテーションは、ある構文要素に付加情報を記述するための構文要素。
言い換えるなら「コードに関する注釈を書いたコード」だと言える。
対象となる構文要素は「宣言」である。
具体的には以下の６つ。

1. パッケージ宣言
2. 型宣言
3. フィールド宣言
4. メソッド／コンストラクタ宣言
5. 引数宣言
6. ローカル変数宣言

構文は以下の通り。

@アノテーション名 (
  キー = 値,
  キー = 値,
  …
)

フレームワークとか作ろうと思ったら結構役立つんですよね。

Git Plugin の導入に躓いた

Jenkins で SCM(?) からソースをチェックアウトして、ビルドして、テストする。
これを Git から行おうと思い、プラグイン管理から Git Plugin を入れて、ジョブの設定で対象の Repository を設定したのに、実行したら一瞬で失敗。ガーーン( TωT)
コンソールにはこんなエラーが出てうまくいかない。

ERROR: Workspace has a .git repository, but it appears to be corrupt.
hudson.plugins.git.GitException: Error performing command:  rev-parse --verify HEAD
	at hudson.plugins.git.GitAPI.launchCommandIn(GitAPI.java:892)
	at hudson.plugins.git.GitAPI.launchCommand(GitAPI.java:846)
	at hudson.plugins.git.GitAPI.launchCommand(GitAPI.java:856)
	at hudson.plugins.git.GitAPI.validateRevision(GitAPI.java:324)
	at hudson.plugins.git.GitAPI.hasGitRepo(GitAPI.java:123)
	at hudson.plugins.git.GitSCM$2.invoke(GitSCM.java:997)
	at hudson.plugins.git.GitSCM$2.invoke(GitSCM.java:978)
	at hudson.FilePath.act(FilePath.java:842)
	at hudson.FilePath.act(FilePath.java:824)
	at hudson.plugins.git.GitSCM.determineRevisionToBuild(GitSCM.java:978)
	at hudson.plugins.git.GitSCM.checkout(GitSCM.java:1134)
	at hudson.model.AbstractProject.checkout(AbstractProject.java:1256)
	at hudson.model.AbstractBuild$AbstractBuildExecution.defaultCheckout(AbstractBuild.java:589)
	at jenkins.scm.SCMCheckoutStrategy.checkout(SCMCheckoutStrategy.java:88)
	at hudson.model.AbstractBuild$AbstractBuildExecution.run(AbstractBuild.java:494)
	at hudson.model.Run.execute(Run.java:1502)
	at hudson.model.FreeStyleBuild.run(FreeStyleBuild.java:46)
	at hudson.model.ResourceController.execute(ResourceController.java:88)
	at hudson.model.Executor.run(Executor.java:236)
Caused by: java.lang.NullPointerException 	at hudson.Launcher.printCommandLine(Launcher.java:592)
	at hudson.Launcher.maskedPrintCommandLine(Launcher.java:614)
	at hudson.Launcher$LocalLauncher.launch(Launcher.java:700)
	at hudson.Launcher$ProcStarter.start(Launcher.java:338)
	at hudson.Launcher$ProcStarter.join(Launcher.java:345)
	at hudson.plugins.git.GitAPI.launchCommandIn(GitAPI.java:873)
	... 18 more

調べてみると、インストールしたGit を Jenkins に設定して(教えて)あげないといけないとな。そりゃそーだ。
とゆーことで、以下の通り設定して、

再度実行...これまた一瞬で失敗した( TωT)ガーーーン。
でコンソールを見てみるとこんなエラーが。

FATAL: Could not apply tag jenkins-test-project-17
hudson.plugins.git.GitException: Could not apply tag jenkins-test-project-17
	at hudson.plugins.git.GitAPI.tag(GitAPI.java:817)
	at hudson.plugins.git.GitSCM$4.invoke(GitSCM.java:1258)
	at hudson.plugins.git.GitSCM$4.invoke(GitSCM.java:1223)
	at hudson.FilePath.act(FilePath.java:842)
	at hudson.FilePath.act(FilePath.java:824)
	at hudson.plugins.git.GitSCM.checkout(GitSCM.java:1223)
	at hudson.model.AbstractProject.checkout(AbstractProject.java:1256)
	at hudson.model.AbstractBuild$AbstractBuildExecution.defaultCheckout(AbstractBuild.java:589)
	at jenkins.scm.SCMCheckoutStrategy.checkout(SCMCheckoutStrategy.java:88)
	at hudson.model.AbstractBuild$AbstractBuildExecution.run(AbstractBuild.java:494)
	at hudson.model.Run.execute(Run.java:1502)
	at hudson.model.FreeStyleBuild.run(FreeStyleBuild.java:46)
	at hudson.model.ResourceController.execute(ResourceController.java:88)
	at hudson.model.Executor.run(Executor.java:236)
Caused by: hudson.plugins.git.GitException: Command "XXXXXXXXX\bin\git.exe tag -a -f -m Jenkins Build #17 jenkins-test-project-17" returned status code 128:
stdout: 
stderr: 
*** Please tell me who you are.

Run

  git config --global user.email "you@example.com"
  git config --global user.name "Your Name"

to set your account's default identity.
Omit --global to set the identity only in this repository.

fatal: unable to auto-detect email address (got 'XXXXXX@xxxxxxxxxx.(none)')

	at hudson.plugins.git.GitAPI.launchCommandIn(GitAPI.java:885)
	at hudson.plugins.git.GitAPI.launchCommand(GitAPI.java:846)
	at hudson.plugins.git.GitAPI.launchCommand(GitAPI.java:856)
	at hudson.plugins.git.GitAPI.tag(GitAPI.java:815)
	... 13 more

更に調べてみると、Jenkins に Git のユーザとメールアドレスを教えてあげなきゃと。
確かに Git でソースをチェックアウト(clone) してくるときに、接続するユーザ情報を何も設定してなかったな。こりゃ失礼。
とゆーこで、更に以下の通り設定して...無事成功( TωT)！！

たかがビルドしてテスト通すのに躓きまくり。
まぁ次からはこんな事がないようにしたいよね。
その為のエントリだから！

ビルドパイプライン

先々日のDevLOVE関西2012Driveで Jenkins のビルドに時間が掛かってきたときの対策として ビルドパイプライン というのを学んだ。

とりあえず教えてもらったプラグインを覚書として載せておく。
使い方とかは...追々ね。

• Clone Workspace SCM Plugin
• Promoted Builds Plugin
• Build Pipeline Plugin