【gradle - Java】Jenkinsでビルドができない
先週のことでした。
久しぶりにJavaの「コンソール・アプリケーション」をメンテナンスすることになりました。
コードを書き終え、まずはローカル開発環境でのgradleビルドを実施。
まったく問題なく成功！！
メンバーによるプル・リクエストも合格し、Jenkinsでのビルドを行ったところ、ビルドに失敗してしまいました。
いったい、なぜ？？？
開発環境
- Windows10 2004
- JDK8
- IntelliJ IDEA 2019.2
- Gradle 5.6.1
Jenkins環境, 本番環境
- CentOS7.6
- JDK8
- Jenkins ver.2.195
- Gradle 5.6.1
環境は、OSの違いのみ。
JDK、GradleのVersionは、もちろん同一です。
ログ確認
Jenkinsの「コンソール出力」を確認してみると、testでエラーになっていました。
どうやら、RDBへのアクセステストでの接続が全滅しているようでした。ネットワークは正常だし、RDBへのアクセスも問題無いのになぜなのでしょう？？
[Pipeline] sh + gradle clean test checkstyleMain findbugsMain javadoc jar Starting a Gradle Daemon (subsequent builds will be faster) > Task :clean UP-TO-DATE > Task :compileJava > Task :processResources > Task :classes > Task :compileTestJava > Task :processTestResources NO-SOURCE > Task :testClasses > Task :test FAILED <<<<<<<< :
Jenkinsのコンソール出力では詳細までわからないので、Jenkins内に書き出されたテスト結果フォルダを根こそぎ取得して、内容を確認することにしました。
「/var/lib/jenkins/workspace/Pipeline_JavaAppName_Build/build/reports/tests/test」フォルダを取得して、index.htmlをブラウザで確認してみると、ログには次のように書かれていました。
Caused by: org.apache.ibatis.exceptions.PersistenceException:
### Error building SqlSession.
### The error may exist in sqls/MonthlyBacklog.xml
### The error occurred while processing mapper_resultMap[monthlyPayablesMap]
### Cause: org.apache.ibatis.builder.BuilderException: Error parsing SQL Mapper Configuration. Cause: java.io.IOException: Could not find resource sqls/MonthlyBacklog.xml
at org.apache.ibatis.exceptions.ExceptionFactory.wrapException(ExceptionFactory.java:30)
at org.apache.ibatis.session.SqlSessionFactoryBuilder.build(SqlSessionFactoryBuilder.java:80)
at org.apache.ibatis.session.SqlSessionFactoryBuilder.build(SqlSessionFactoryBuilder.java:72)
:
「sqls/MonthlyBacklog.xml」が存在しない！？
そんなはずはありません。実際、Windowsのローカル環境ではgradle Buildもまったく問題無いわけですし・・・
ちなみに、DBアクセスするすべてのテストがエラーになっていました。
原因
IDEAを立ち上げ、じっくり確認してみると、原因がわかりました。
このアプリでは、mybatisを使っているのですが、「mybatis-config.xml」で定義しているmapperファイルの名前と、実際に配備したxmlファイルの名前が異なっているじゃないですか！！
<!-- mybatis-config.xml --> <mappers> <mapper resource="sqls/MonthlyBacklog.xml"/> </mappers>
<!-- 実際のリソース --> sql/MonthlyBackLog.xml
MonthlyBacklog.xml と MonthlyBackLog.xml !!!
たしかにWindowsでは多くの場合大文字小文字を区別しませんが、Linuxでは区別するのでした。
なんとまあ、基本的なチョンボをしてしまったのでしょう・・・。
まとめ
いずれにしましても、本番環境での運用前に、LinuxのJenkinsで動作テストをしていて正解でした。
mybatisは、mybatisのconfigで正常に認識できないと、すべてのDBアクセスができないということもわかりました。
本来ならば、記事にするほどの内容でも無いのですが、自分への戒めとして書くことにしました。
何事も「原理・原則」が大事ということですね。
目標達成のために取り組んだ３つのこと
11/22（日）、ついにフルマラソンで「サブ４」を達成することができました！
2015年の夏から走りはじめ、サブ４を目指すと決意したのは、2019年の頭。
ランナー歴５年、目標を掲げてからは２年以内で、クリアできたことになります。
ここでは、自分なりに「これが良かったのではないか」と思うことを３つに絞ってまとめておこうと思います。
1. アファメーション、予祝を毎日行う
まず１つ目は、毎朝、「サブ４達成！」という画像を眺めて、ぼんやりと成功したときのイメージをし続けました。
つまり「予祝」ってやつですね。
これは、2019年1月1日から、達成のその日まで、毎日１日も欠かさず続けることができました。
「宝地図」の中の１枚の画像として見ていたわけですが、私はスマホの待ち受け画面も「宝地図」になっていて、１日何度も見ていたので、脳が「絶対に達成できる！」と認識してくれていたのでしょう。
2. 練習ルールを決めて、そのルールに忠実に従う
これは2020年からのルールなのですが、「ランニング練習に３連休は無い（ランオフは２日までOK）」というものを自分に課しました。
そうと決めたら、淡々と実行あるのみ。
体調不良と、大雨が続いた２回だけ「３連休」になってしまったことはあったのですが、「４連休」は皆無。
練習日には、「閾値走」や休日には２時間程度の「LSD」を行ったり、バラエティー豊かな練習に取り組むことができました。
いずれにしても、継続的な練習によって、「持久力」がアップしていったのだと思っています。
3. 目標達成のための手段を考え、行動し続ける
最後は、2019年から noteブログを連載したことが大きいと思っています。
正直、読者は数名。
とはいえ、自分自身のために、週１回書き続けると決めたので、毎週ネタを探して、感じたことや新しい気付きを書き綴ることができました。
さすがに毎週マラソンのことを考えていると、マラソンについて詳しくなるのは当たり前です。
練習方法で試したり、新アイテムを購入したりと、サブ４実現のための「手段」をどんどん行動できるようになります。
以上３つが大きな成功要因だと思っています。
レース後は、カラダはボロボロでした。正直、ギリギリ達成できるレベルだったのでしょう。
まあ、無事に目標をクリアすることができ、今は安堵感でいっぱいです。
今後はどうするか？
マラソンは脚が動く限り続けるつもりですが、今年中にはまた新しい目標を見つけて、攻略方法について戦略を練りたいところです。
実は、目標達成するよりも、達成するまでの「過程」を楽しむほうが好きなのかもしれませんね。
「JJUG CCC 2020 Fall」に参加しました（2020/11/07） #jjug_ccc
2020 Springもオンラインだったとはいえ、数多くのセッションが聴ける形でのオンラインは今回が初。
息子らのスポ少（野球）の練習を休んで、JJUGに臨みました。
毎回、同じことを書いている気がしますが、国内外の一流の方のノウハウや考え方に触れるだけで、「このままではいかん！」と熱い気持ちにさせてもらえます。つまり、自分が行動するための着火剤が「JJUG」というわけですね。
今回視聴したセッション
- Eclipse MicroProfileの進化状況と利用方法の展望について
- パフォーマンスのトラブルシュート入門
- Spring Boot ユーザの方のための Quarkus 入門
- Javaコードが速く実行される秘密 - JITコンパイラ入門
- 3つの視点(Biz Dev Ops)から見たQuarkusの威力
- マイクロサービスアーキテクチャをあきらめないための、モノリスで始めるアーキテクチャテスト
所感
世の中の標準、「クラウド・ファースト」「マイクロサービス」「コンテナ運用/自動管理」「サーバレス」などなど、まったくできていないので、すべてが刺激的でした。
しかし、一気に最新のもので、今管理しているアプリケーションをすぐに移行できるわけではないので、１つずつ検証しながら（手を動かしながら）新しいテクノロジーの原理・原則、有効性、メリデメなどを理解していこうと思っています。
今回は、サーバーサイドの話をメインに聞いたので、並行してフロントエンドの技術も学びながらになりますか。
さすがに幅が広すぎるので、とにかく「広く浅く」でいいので、知見を広げていかないといけません。
よく小さな子どもが「何で？」「なぜ？」「どうして？」などと親にすがって聞いてきますが、我々大人もそうでなくてはなりません。
「何でこんなことができるの？」「仕組みはどうなってるの？」「なぜここでエラーになるの？」「どうして思い通りに動かないの？」
これからは、この「なぜ？」「どうして？」をとことん追求していく必要がありそうです。
そのために、まずは「広く浅く」知ることなんです。
そして、決断を迫られたときに、迷いなく（少しはあるかも？）必要な技術を採用できたら嬉しいです。
まずは、k8s、Quakus、Eclipse MicroProfileに触れつつ、vue3、SpringBootは継続して学んでいこうと思っています。
「アイ・アム・冒険少年（2020/11/09）」を観て感動！！
YouTube動画は、毎日のように観ていますが、最近、めっきりTVを観なくなってしまっています。
録画して観ているのは、『相棒』、『麒麟がくる』、『ゴットタン』、『アメトーーク』、『ワイドナショー』の５本。
まあまあ、観ているほうかしら！？
そんな中、息子たちがハマっているTV番組を、俺も何気に一緒に観ていたら、超・感動してしまったので、記事にさせていただきました。
その番組は、『アイ・アム・冒険少年』です！
いよいよ明日７時‼️
— アイ・アム・冒険少年【公式】 (@boukenshounen1) 2020年11月8日
５日以内に全員連続で
バック転成功目指せ！！
『バック転島』🏖
パンサー尾形発案☝️
波うち際での倒立練習で
団長まさかのミラクル🤣
１日１回先生が指導！！
果たしてバック転🤸♂️
できるようになる！！？#岡村隆史#SnowMan#向井康二#目黒蓮#冒険少年 pic.twitter.com/tXVARqoxXk
（注）ここからは、ネタバレありです。
「バック転島」というタイトルの企画で、芸人５人が５日間で全員が連続でバク転を決めるというもの。
とても無理だろう、と思ってみていると、いやいや皆本気で打ち込んでいました。
１日ごとにやってくる先生達の教えを活かしながら、少しずつ補助を使っての「バク転」ができるようになっていく芸人さん達・・・。
厚切りジェイソンさんが怪我で離脱するも、最終日、残った４名がバク転にチャレンジ！！
リーダーのパンサー尾形さんがまずクリア！
次に若手のワタリさんも続きます。
３人目は同年代の星、安田大サーカスの団長が維持で決めてみせ、最後のサンシャイン池崎さんが、失敗してしまう展開・・・。
こうなると、また尾形さんから、やり直し。
１回のバク転で、かなり体力を削られているにもかかわらず、聞こえてきた一言。
尾形さん「気にすんな！ 何回でもやってやるって！」
本人はTV画面に写っておらず、声だけが聞こえてきたのが良かったのか、急に目頭が熱くなってしまいました。
果たして自分が同じ状況だったとしたら、そんな素敵な言葉をかけることができるでしょうか？
おそらく、「ドンマイ、ドンマイ！」とか言いつつも、またバク転をしなければならないのか！！などとネガティブな気持ちになってしまうと思います。
どんなバラエティ番組でも、いつもド真剣に取り組んでいる尾形さんが、本当に素敵でした。
尾形さんだけでなく、団長もチームワークを意識した言動が多くて、学ぶべきものがとても多かった。
この企画の結末ですが、３回目の挑戦で、サンシャインも見事、バク転に成功！
ハッピーエンドで幕を閉じました。
TVの時代は終わった、などと言われて数年になりますが、まだまだ捨てたもんじゃないですね。
この５人の企画があるときは、「アイ・アム・冒険少年」を見逃さずにしたいです。
サンキューーー！！！
「アンガーログ」を付けてみた
アンガーマネジメントに以前から興味があり、ようやくそれに関する本を先月に読み終えたところでした。
読んだ本は、次の２冊。
本の中で「アンガーログ」という名の「怒りの日記」を付けようと書かれていたので、まずは試しにやってみようと思い立ち、始めてもうすぐ１ヶ月になります・・・。
『はじめてのアンガーマネジメント実践ブック』には、アンガーログについてこう書かれています。
「アンガーログ」とは、イラッとしたこと、頭にきたことを記録することです。
文字化することによって、怒りの内容を具体的に「見える化」することが
できる有効なテクニックです。
ログは、怒りを感じたら、すぐに記録する必要があったので、Dynalist に付けることにしました。
パソコン上からも入力できますし、外であればスマホからも手軽に入力できますからね。
アンガーログの項目は、次の５点です。
1. 怒った日時
2. 怒った場所
3. 何があったか
4. 思ったこと
5. 怒りの温度（10段階。10が最大の怒り）
ログの結果
記録したログ件数は、全部で12件。
これは多いのでしょうか、少ないのでしょうか？
約２日に１回は怒りを感じたことになります。
怒りの温度別に見ますと、Lv７～９の怒りが３回。Lv４～５の怒りが３回。Lv２～３の怒りが５回でした（Lv1, 6, 10 はゼロ）。
怒りのクセ
日々、ログを書いてみて思ったのですが、自分が怒ってしまう事象には、特定のパターンがあることがわかりました。
そのパターンは、主に３つ。
１つ目は、仕事は真剣にやるべきという「べき」が強くあるということです。
業務中なのに、近くで雑談がひどいときなどに、イライラしてしまいがち。
別の人から見れば、「ワイワイ楽しく仕事をしようよ！」と思う方も多くいるとは思いますが、コードを書いているときなどは静寂の中で仕事をしたいと思ってしまいます。
中途半端な集中力であることが問題なのか？
究極の集中力で乗り越えていくしかないのでしょうか。
２つ目は、自己中な振る舞いを目にしたら嫌悪感を感じる点です。
「自分さえよければいい」という行動は、すぐにわかってしまいます。
人は皆自分自身が可愛いということはわかるのですが、職場などでそれを感じてしまった場合は、いつも激しい怒りを感じてしまいます。
同様に大きな声で挨拶をしても、相手に「無視」されたりすると、同じような怒りを持ちます。
う～、こうして言語してしていくと、自分が相当「頭の硬いおっさん」に思えてきました・・・。
最後は、会話をする中で、自分が求めている「答え」からかけ離れた返答があった場合に、少しイラッとしてしまうことがあります（例：結論からではなく、ストーリーから話を始められたときなど）。
そう思うのは、お互いの時間を大切にしたいという思いがあるためなんですが、結局、自分自身も「自己中」ということなのでしょうね。
俺からボールを返しやすい質問をしたり、発言をしやすい雰囲気を作ってあげることで改善できる事象ではあります。
少しずつスムーズなキャッチボールが増えるように、小さな努力を続けるのみですか！
アンガーログの効果
ログ書きを続けてみて思ったのですが、以前より無駄に怒らなくなってきたように思っています。
アンガーマネジメントの目的は、「目指すのは、起こるべきことには怒り、どうでもいいことには怒らないうようになる状態」と書いてありましたが、まさにそれが少しずつではありますが、実現できてきたように思います。
ログを俯瞰してみることで、感情のクセを知ったことが良かったのかもしれません。
ログを書いていると、時間の経過とともに、怒りの温度が下がっていくこともありました。
怒りそうになったとき、ログに書くのが面倒だから、怒らないでおこうと思ったこともあったはず。
いずれにしても、人生の時間の中で、今までより「怒り」の時間が減ったことは、カラダにもプラスのはずです。
まとめ
ログの書き出しをする習慣はできたので、そろそろ次のステップに進もうかと思っています。
怒りを感じたときにどう振る舞うか、今度は怒ってしまったとき、自分にあった具体的な「行動」をどう作っていくか？
「６秒待つ」など基本的なことはもちろんですが、怒りを鎮める「マジック・ワード」を作るなど、いろいろと試していこうと思います。
１秒でも怒りの時間を減らして、１秒も多く「ハッピー」な気持ちでいれるように、新しいことを少しずつ取り入れていきましょう！
iPhoneの認証用指紋は複数登録できる！
今月はじめのことでした。
職場でのワン・シーンです。
同僚Ｋ「・・・」（左親指でiPhoneの指紋認証を行う） 私 「あれ？ Ｋさんって左利きでしたっけ？」 同僚Ｋ「右と左、両方登録しているんです。」 私 「ええええ？？？（知らんかった）」
私は、去年からiPhone8ユーザー。遅ればせながら、指紋認証の素晴らしさを体感してもうすぐ２年です。
「指紋の登録は１つしかできないもの」という勝手な思い込みのせいで、これまで左手しか空いていない時は、わざわざパスコードを入力していました。
知らないって「罪」ですよね・・・という話です。
左親指の指紋を登録
これは登録しない手はない！
ということで、まずは、設定から「Touch ID & Passcode」を選びます。
ちなみに、私のスマホは、英語モードにしてあります。
英語力強化のためです。これが非常に苦しい・・・。
すると、「Add a Fingerprint...」のリンクがあるではありませんか！！！（感動です）
このあと、画面は無いのですが、左親指の指紋をグリグリとホームボタンに押し付けました。
見事、２つ目を登録できました！！！
オシャレに、名称も英語に変更しておきました。
これで、ようやく「両刀使い」になりました。野球でいえば、スイッチヒッターです。
高橋慶彦と呼んでください ♪
ちなみに、当然ですが「顔認証」は未経験です。。。
【AS400】物理ファイル「削除済みレコードの再使用」の検証
AS400のデータベース、すなわち「DB2 for i」についてです。
AS400のテーブルのレコードを物理削除していくと、削除レコードがどんどん増えていくことになりますが、その場合、バッチ処理等で「RGZPFM（物理ファイル・メンバー再編成）」をすれば、削除レコードはクリーンアップされます。
確かにそのやり方でまったく問題無いのですが、この処理すら省く方法は無いかな～？（楽をしたい！）
ということで、物理ファイルの設定で「削除済みレコードの再使用（REUSEDLT）」というオプションがあることを知りました。
早速、試してみましたので、検証結果をまとめておきます。
テスト・テーブル
今回、TESTPF01 というテーブルを準備しました。
中身は、こんな感じです。
RUNQRY QRYFILE(TIGERDB/TESTPF01)
KEY01 KEY02 FLD01 FLD02 FLD03
000001 A0001 1 1 500
000002 A0001 2 3 120
000003 A0001 3 3 150
000004 A0001 4 1- 10 値引き
000005 A0002 1 1 15,000
000006 A0002 2 1 5,000
000007 A0003 1 8 30
000008 A0003 2 8 25
000009 A0003 3 8 60
000010 A0003 4 1,000 5
000011 A0004 1 1 100
000012 A0004 2 1 200
000013 A0004 3 1 300
000014 A0004 4 1 400
000015 A0004 5 1 500
DSPFD FILE(TIGERDB/TESTPF01) : メンバーの合計数 . . . . . . . . . . . . : 1 使用可能でないメンバーの合計数 . . . . . . : 0 合計レコード数 . . . . . . . . . . . . . : 15 合計削除レコード . . . . . . . . . . . . : 0 合計メンバー・サイズ . . . . . . . . . . : 49152
物理ファイルの設定変更
テスト・テーブルの「削除済みレコードの再使用」の初期値は、「*NO」。
当然、初期値のまま、コンパイルしましたので、ここは「CHGPF」コマンドで設定変更をする必要があります。
CHGPF FILE(TIGERDB/TESTPF01) REUSEDLT(*YES)
物理ファイル変更 (CHGPF)
選択項目を入力して，実行キーを押してください。
入れたい記憶装置 . . . . . . . UNIT *ANY
強制書き出しレコード数 . . . . FRCRATIO *NONE
最大ファイル待機時間 . . . . . WAITFILE 30
最大レコード待機時間 . . . . . WAITRCD 60
オープン・データ・パス共用 . . SHARE *SAME
許される削除 ﾚｺｰﾄﾞ の最大 % . . DLTPCT *NONE
削除済みレコードの再使用 . . . REUSEDLT *YES <<<<
分類順序 . . . . . . . . . . . SRTSEQ *HEX
ﾗｲﾌﾞﾗﾘｰ . . . . . . . . . . .
言語 ID . . . . . . . . . . . . LANGID JPN
レコード様式レベルの検査 . . . LVLCHK *YES
メモリーに保管 . . . . . . . . KEEPINMEM *NO
ノード・グループ . . . . . . . NODGRP *NONE
検証作業結果
PFの設定を変更したので、ここから検証開始です。
①物理レコード削除
UPDDTAコマンド、SQLなどでレコードを２件物理削除しました。
※5番目と6番目のレコード
000005 A0002 1 1 15,000 000006 A0002 2 1 5,000
この段階で、物理ファイルを参照してみます。
メンバーの合計数 . . . . . . . . . . . . : 1 使用可能でないメンバーの合計数 . . . . . : 0 合計レコード数 . . . . . . . . . . . . . : 13 合計削除レコード . . . . . . . . . . . . : 2 合計メンバー・サイズ . . . . . . . . . . : 53248
ここまでは、お馴染みの動きですね（合計レコード: 15 → 13件、削除レコード: 0 → 2件）
②レコード追加
次に、レコード追加です。今回は、UPDDTAで追加しました。
ファイル中のデータ処理 モード . . : 挿入
様式 . . . . : RECPF01 ファイル . : TESTPF01
KEY01: A0005
KEY02: 1
FLD01: 3
FLD02: 700
FLD03: あいう
③物理ファイル確認
2件削除し、1件追加した後で、「DSPFD」コマンドで確認です。
メンバーの合計数 . . . . . . . . . . . . : 1 使用可能でないメンバーの合計数 . . . . . : 0 合計レコード数 . . . . . . . . . . . . . : 14 合計削除レコード . . . . . . . . . . . . : 1 合計メンバー・サイズ . . . . . . . . . . : 53248
削除レコードが2件から1件へ減少し、合計レコードが13件から14件へ増加しています！！
これなら、定期的な最適化処理はいらなくなりそうですね。
注意点
SQLでの呼び出しで注意点がひとつ。
途中でレコードが挿入されるため、SELECT句でのレコード参照では、「ORDER BY」を付けないと、予期せぬ並びになってしまいます。
SELECT * FROM TIGERDB.TESTPF01 -- KEY01 KEY02 FLD01 FLD02 FLD03 -- A0001 1 1 500 -- A0001 2 3 120 -- A0001 3 3 150 -- A0001 4 1- 10 値引き -- A0005 1 3 700 あいう <<<②で追加したレコード -- A0003 1 8 30 -- A0003 2 8 25 -- A0003 3 8 60 -- A0003 4 1,000 5 -- A0004 1 1 100 -- A0004 2 1 200 -- A0004 3 1 300 -- A0004 4 1 400 -- A0004 5 1 500
まあ、そもそも「ORDER BY」を付けないケースは、ほとんど無いとは思いますが・・・。
以上で検証終了です。
