JenkinsのJDK自動インストールで間違ったアカウントを設定すると以後使えなくなる件について

古いJDKをダウンロードするにはオラクルアカウントが必要になる。

Jenkinsでも例外ではなく、初期にアカウントの入力が求められる。

しかし、どうやらこのアカウント入力ははじめの一回しか行えず、

画面で後からいじることが不可能になっているみたい…。

つまり、初期入力でアカウントを間違えると、

再設定ができずに、自動インストール機能が使えなくなってしまうようだ。

初期設定後にアカウントを弄りたいときは

/descriptorByName/hudson.tools.JDKInstaller/enterCredential

へアクセスすれば良いようだ。


2014年04月21日追記
再設定はジョブの結果にリンクが貼られていた。
相変わらずログの情報見落とすな…。

P.S.

JDKに関する設定ファイルは下記に保存されている。

JENKINS_HOME/hudson.tools.JDKInstaller.xml

ファイルのアカウント部分を削除してみても設定画面に

再度アカウント入力のリンクが出現しなかった。

その為設定ファイルを削除してJenkinsを再起動することで、

アカウント情報の削除が行えた。

Gradleのビルドスクリプトにて"Could not read script"エラー

久しぶりにJenkinsのビルドジョブを実行したら下記のエラーが…。

handshake alert:  unrecognized_nameとは一体？
SSHの鍵の問題でもなく、メイン機でも同様に発生。
調べてみるとJava1.7のバグらしい。
Could not read script "URL" due to handshake alert: unrecognized_name #29

下記を参考にJAVA_HOMEを1.6に書き換えることで動くようになりました。
OSXでJavaのバージョンを切り替える

2014年04月21日追記
下記のようにgradle.propertiesでGradleの設定ファイルを作ってSNIを無効にするのが一番いいかも。


P.S.
ついでに出て間もないJava1.8で試してみたら同様のエラーが出ました…。

Jenkinsのワークスペースパスがおかしい

Jenkinsにて空のジョブを作成して実行すると下記エラーが出るんやけど... 

.@2ってなんですのん？ 

Started by user hogehoge
Building on master in workspace .@2
java.io.IOException: Failed to mkdirs: .@2
 at hudson.FilePath.mkdirs(FilePath.java:1072)
 at hudson.model.AbstractProject.checkout(AbstractProject.java:1405)
 at hudson.model.AbstractBuild$AbstractBuildExecution.defaultCheckout(AbstractBuild.java:652)
 at jenkins.scm.SCMCheckoutStrategy.checkout(SCMCheckoutStrategy.java:88)
 at hudson.model.AbstractBuild$AbstractBuildExecution.run(AbstractBuild.java:557)
 at hudson.model.Run.execute(Run.java:1679)
 at hudson.model.FreeStyleBuild.run(FreeStyleBuild.java:46)
 at hudson.model.ResourceController.execute(ResourceController.java:88)
 at hudson.model.Executor.run(Executor.java:230)
Finished: FAILURE

 

[Jenkinsの管理] -> [システムの設定] -> [高度な設定]

で設定できたー。

参考

5.3.2

root_pathが定義されていないとのエラー。 他のページはうまくいくんに…。 guardを再起動したら治ったっぽい？

Rubyのお勉強

Javaばっかりやってきていたので、動的言語が気になり、
Rubyになんとなく目が止まったのでRails使ってWEBサイトちょちょいと
作れるようになりたかったのでお勉強中。

「初めてのRuby」写経し終わり、「パーフェクトRuby」の4章まで進んだところで、
Rails Tutorialの日本語版が出たとのことでそっちに専念してます。

動的言語ってことでIDEの補完機能に頼ってばっかりもいられなくなったので、
タイピング能力高める+エディタの乗り換えのため、

HHKBと「実践Vim」を購入。

実践Vimには編集土台となる文章が公開されているので、
gitのリポジトリ作って編集しやすいようにしといた。

以上

今更ながらTDDBC Tokyo 2013

メモがあったので乗っけとく

TDDBC TOKYO
twada和田拓人
gihyo.jp
動作する綺麗なコード…
動くー綺麗か？

②つの道がある。
１．汚い・動かない→※②汚い・動く→綺麗・動く
２．汚い・動かない→※①綺麗・動かない→綺麗・動く

※①綺麗さには限界がないので、期限に間に合わなくなる。
　完璧主義沼地。
　ソフトウェア開発手法はまだまだ未熟。
　→動かして初めて分かることのほうが多い。

※②堕落沼に落ちる。
　コードを綺麗にすることを怠ってはいけない。

２．のほうがTDD。

TDDとは？
　目標を考える（TODOリスト。設計リストを作成。)
　作業を選択する。
　RED,GREEN,REFACTORのサイクルを回す。
　　→つまり２．のサイクルを繰り返す。
　　　何をしてるのかを常に意識することがアジャイルでは大事！
　矢印があるということは目的がひとつということ。
　
　GREEN…取りあえず動くコードを書く。【汚くていい】。
　Refactoring…小さいうちに片付ける。
　　リーダブルコード、リファクタリングの有名なやつ
　　2冊本がおすすめ。

大事なこと１．
　大きい問題をそのままテストするのではなく、
　小さい問題に分けて、それを組み合わせて
　大きい問題を解くようにする。
大事なこと２．
　サイクルを素早く、回数を行う。
大事なこと３．
　自分が最初のユーザである
　(自分が作るものをまず初めに自分が使う。)
　　→テストコードで使う。
大事なこと４．
　【不安なこと】をテストする。
　　→不安でないことはテストしない。
　　　getter,setterにはいらんでしょ？

TDDのメリット
　ソフトウェア工学的なメリッドもあるが、最大の理由は
　【心理的なもの】【健康】
　　→即座にフィードバックが得られる
　　→書いたコードに自信をもつため
　　→これから書くコードに自信をもつため

　健康なら毎日REDBULL＋終電ダッシュはしなくていい。

TDD採用(MS,IBMの例)
　管理者見積もりによる増加コード実装時間
　　15%~35%
　テストコードはプロダクトコードの30%〜90%

　コーディング行・時間は増えるが、
　デバッグの時間が減るので全体の時間は減る。
　　デバッグにかかる時間はブレが大きいが、
　　そのブレを抑える働きがある。

TDD応用
　テストのないコードがたくさんある…
　　レガシーコード改善ガイド本
　すでにデータの入ったデータベースがある…
　　データベースリファクタリング本
　SlowTests…
　　メモリに対するテストより、DB、ネットワークに対する
　　テストのほうが時間がかかる。
　　→フィードバックにかかる時間が増えてしまう。
　　xUnitTestPatterns本…英語
　　　ネットのwikiをまとめたもの。
　テストをどこまで行えばよいか・何をテストすればよいか…
　　ソフトウェアテスト技法ドリル本
　実際の複雑なテストをどう行うか？
　　実践テスト駆動開発

TDDはスキル！
　才能ではなく習得可能！
　量は質に変化する！
　写経！！

**********************
実践テスト駆動開発の著者の一人
スティーブフリーマン(Steve Freeman)

　新しい機能を追加するのではなく
　既存の機能をリファクタリングすだけなら
　リファクタリング用のテストコードを書いて、
　リファクタリングを行う？

　●テストダブルを行う理由は？
　オブジェクト間のメッセージが飛びかっていて、
　(オブジェクトが頂点でメッセージが辺のようなグラフ)
　　その中のやり取りが上手くフィットしているか
　　確認するってのが１０年前に言われて、
　　今もそれが目的だと思っている。

　　テストを細かくするため。
　　たくさんエラーが出た時にどれが問題かを判断するため。

　●不可能なテストをどのように対応するか？
　　　→レガシーコード改善ガイド本見て。
　　依存関係を切っていく。
　　大きな塊でやっていく。
　　
　小さく取り出して安全な形で変えていく(リファクタリング？)
　そのうち状況が変わったり、
　解決につながるアイディアが思い浮かぶ。

和田問写経

Githubリポジトリ
TDD伝道師の和田さんが出された問題が話題になったのでやってみた。
というか、黒魔法リフレクトを唱えるのもめんどくさくて、
解説見てから良さそうなやつを実践した。

解説で問題を解くパターンがたくさん紹介されているので、
それぞれメリット・デメリットがわかりやすくてとてもタメになります。

私が今回実践したのはSelf Shunt。
わかりやすく実践しやすい上に強力。

脆いテストにならないように注意して多用しようと思う。

〜追記〜
Junit4でテストクラスで継承を行った場合に下記例外が発生した。

java.lang.Exception: Test class should hava exactly one public zero-argument constructor

どうもテストフレームワーク側で引数なしのコンストラクタを使用しているため、
引数ありのコンストラクタのみしかない場合に例外になるようだ。

プロダクトコードに引数ありのコンストラクタしかない場合はSelf Shuntは使用不可なのか？