Windows の curl で SSL 証明書の失効チェックができない

前回の続き。備忘録。

Jenkins から curl で Google Chat に通知する - kntmr-blog

しばらくは問題なく動作していたが、いつ頃からか Jenkins から curl を実行したところで以下のようなエラーが出るようになった。

curl: (35) schannel: next InitializeSecurityContext failed: Unknown error (0x80092013) - 失効サーバーがオフラインのため、失効の関数は失効を確認できませんでした。

SSL 証明書の失効チェックができてないっぽい?

次のどちらかのオプションで回避する。セキュリティ的にはよろしくないかもだけど、社内の限定的な範囲でしか使わないのでよしとする。

  • --ssl-no-revoke: SSL 証明書の失効チェックを無効にする (Windows のみ)
  • -k, --insecure: SSL で安全ではないサーバー接続を許可する

参考

curl - How To Use

Jenkins から curl で Google Chat に通知する

備忘録。

社内の情報共有サイトに Google Chat で Webhook を使う方法が流れてたので、それを参考に Jenkins のビルドを通知する Bot を設定しました。

普段、Git と Jenkins を使っているのですが、現在の運用では、リリース内容によってはビルドするブランチを master から feature や release などに切り替えることがあります。で、今の Jenkins のビルド設定でどのブランチのどのコミットをビルドしたのかを手軽に知りたいと思いまして。

Git のブランチモデルについてまとめた記事はこちら。

Git ブランチモデル改善 (案) - kntmr-blog

前提

Webhook

Google Chat のルームから Webhook を設定する。以下のような URL が生成される。

https://chat.googleapis.com/v1/spaces/<ROOM_ID>/messages?key=<KEY>&token=<TOKEN>

Jenkins

今回は「Windowsバッチコマンドの実行」から curl で POST する。curl コマンドがない場合はインストールする。

Jenkins から curl が参照できない

この Jenkins が 32bit で動作しているのが原因なのか、C:\Windows\System32\curl コマンドが参照できないっぽい。なので、C:\Windows\SysWOW64\curl.exe を使うようにする。

リクエストエラー1

コマンドプロンプトから叩くと正常に実行できるのに、Jenkins から実行すると Payload が正しくないというエラーが返る。

$ curl -X POST -H "Content-Type:application/json" -d '{"text": "message"}' "%WEBHOOK_URL%"

リクエストの JSON をダブルクォートで囲って、中のダブルクォートをエスケープしたらイケた。ただ、^エスケープするだけでもよかったかも。

$ curl -X POST -H "Content-Type:application/json" -d "{\"text\": \"message\"}" "%WEBHOOK_URL%"

リクエストエラー2

Jenkins から curl を実行すると 400 Invalid request token が返る。原因は Webhook の URL に &% が含まれているため。& はクエリパラメータなのでいいとして、なぜ token に % が含まれるんだろうか...。

それぞれエスケープして ^&%% にする。

https://chat.googleapis.com/v1/spaces/<ROOM_ID>/messages?key=<KEY>^&token=aaaaaaaa%%3D

まとめ

最終的にこんな感じになりました。リクエストに thread を指定すると同一のスレッドにメッセージを送ることができる。今回は Jenkins の環境変数を利用して以下の情報を通知するようにした。(実際はもう少し気の利いたメッセージにしてある)

  • BUILD_NUMBER: ビルド番号
  • GIT_BRANCH: ブランチ
  • GIT_COMMIT: コミットハッシュ
set PROXY=http://<PROXY_HOST>:<PROXY_PORT>/
set WEBHOOK_URL=https://chat.googleapis.com/v1/spaces/<ROOM_ID>/messages?key=<KEY>^&token=aaaaaaaa%%3D
curl -X POST -H "Content-Type:application/json" -d "{\"text\": \"%BUILD_NUMBER% %GIT_BRANCH% %GIT_COMMIT%\", \"thread\": {\"name\": \"spaces/<ROOM_ID>/threads/<THREAD_ID>\"}}" -x %PROXY% "%WEBHOOK_URL%"

AirPods Pro を購入しました

AirPods Pro を購入しました。

これまで、「イヤホンを充電する」という行為がどうしても煩わしく感じてて、オーディオテクニカの普通のカナル型イヤホンを使い続けていました。

が、通勤であったり、最近は仕事中に耳栓代わりにイヤホンを着けたりしてて、やっぱりワイヤレスがいいかなとか思い始めまして...。あと、ノイズキャンセリング。これがどんなものなのかが気になってました。

で、モノは試しということで AirPods Pro をポチることに。ポチってから届くまで3週間ほど。

所感

持ち運びしやすそうなケースで、Qi に対応している。iPhone と同じ Lightning ケーブルで手軽に充電できるので、特に面倒に感じることはなさそう。

音質はイマイチ。特に中音域の抜けがイマイチ。音質にそこまでこだわるわけではないけれど、それでもイマイチに感じる。

ノイズキャンセリングはそこそこいい耳栓と同程度。仕事中にイヤホンを耳栓代わりに使うのでちょうどいい。それより外部音取り込みモードの聴こえ具合に驚いた。ただ、用途が分からない...。どういうときに使うの?

音質だけ目をつぶれば、この使いやすさでノイズキャンセリングが使えるならいいかなって。充電もそれほど煩わしくなさそうだし、とりあえず買ってよかった、ということで。

ECRS

昔のメモを読み返してたら ECRS という単語が目に留まりました。たぶん社内研修かなんかで聞いた単語をメモったんだと思われます。

ECRS は『業務プロセスを改善するためのフレームワーク』らしいです。

ECRS (改善の4原則) | 用語集 - JMAC

  1. Eliminate (排除)
  2. Combine (結合)
  3. Rearrange (再配置)
  4. Simplify (簡素化)

近頃、DX でモダナイゼーションがどうのこうの (雑) という話をよく聞きます。モダナイゼーションとは、老朽化したシステムの刷新、業務プロセスの改善や効率化などを指すようです。たぶん。

この業務プロセスの改善に ECRS の観点が大事なんだろうなぁと、ふと思った今日この頃です。

余談

全然関係ないけど、部屋の掃除や片付けをするときに ECRS が使えそう。今度子供に教えてみるか。

  • 不要なものは捨てる
  • 類似するものはまとめて収納する
  • よく使うものは手が届くところに置く
  • 使う頻度が低いものはクローゼットなどに入れる

JSUG勉強会 2020 その2 Spring Boot 1.x から 2.x への移行 に行ってきた #jsug

JSUG勉強会 2020 その2 Spring Boot 1.x から 2.x への移行 に行ってきました。簡単に所感をまとめます。

jsug.doorkeeper.jp

所感

普段あまり他社さんのバージョンアップの話を聴く機会は多くないかと思うので、なかなか興味深い内容でおもしろかったです。バージョンアップの流れとかハマりどころとかまとまった情報は重宝しそう。

細いけど、非推奨な機能を使ってるときに警告を出力する設定にしたり、小まめに PR してレビューコストを削減 (分散?) するのがわりとポイントかなと思ったり。

Micrometer の話は、去年の Spring Fest でも聴いたけど、とても便利そうだし使ってみたいです。なかなか使える機会がないけど...。(そもそも Boot アプリじゃない)

あとで読む。

以下、メモから抜粋。

決済サービスの Spring Boot のバージョンを2系に上げた話

www.slideshare.net

  • 2.x のリリースは 2018/03 なので 1.x を使ってる場合じゃない
  • 2.0.x は EOL 間近なので早めにアップデート
  • 2.0.x は Gradle 4+
  • バージョンアップ作業は半年くらい
  • まずは Gradle のバージョンをあげる
  • --warning-mode all が便利
    • Gradle 5 で非互換になる機能を出力してくれる
  • implementation
    • マルチジュール構成でハマった
    • モジュールが双方向に依存してるとつらい
  • プロジェクト直下の build.gradle でバージョン一元管理
  • hibernate-validator => javax.validation
  • spring-boot-starter-json
  • コネクションプールが Tomcat から HikariCP に
    • プロパティが url から jdbc-url に
  • HtmlEmail で null のときに Exception 投げるように
  • AWS X-RaySQL トレースで HikariCP が使えない
  • Flyway が2バージョンあがる (3.x ⇒ 5.x)
  • @ConfigurationProperties の prefix は必ずケバブケースで書く
  • Gradle と Lombok のバージョン相性問題
    • ClassCastException が起きる、などなど

Spring Boot 1.5 → 2.1 バージョンアップを経験して分かったハマりどころ

  • Migration Guide & Release Note でざっくり把握
  • 小さいリポジトリから着手
  • 変更点が多いのでモブレビューでコスト削減
    • 一気にPRすると大変なので小出しにする
  • maven-compiler-plugin の warning と非推奨ログを出力するように
  • Spring Data JPA
    • Query By Example のみに
    • PK による検索は *ById を使う
  • 2.1 から Bean の override はデフォルト禁止
    • allow-bean-definition-overriding で変更可
  • Mockito の any* や any(class) では null 禁止
    • isNull() か any() を使う
    • そもそも引数が nullable かどうか見直すこと
  • spring-boot-properties-migrator
    • 旧verの書き方のときに warning を出力してくれる
  • @SpringBootTest による結合テスト大事
  • バージョンアップをやり切ってから機能追加する

Metrics with Micrometer in Spring Boot 2

docs.google.com

  • 1.x でも /metrics は使える
    • 階層的なメトリクスしか対応してない
    • 時間計測は未対応
    • ネーミングの標準化は未対応
  • Micrometer
    • SLF4J のようなもの
    • 抽象化している
    • バックエンドに送るところは実装による
    • タグなどを使うことで多次元に分析できる
  • Spring とは別のプロジェクトで開発されている
  • 問題検知 & 分析
  • ログとは別にメトリクスを管理することでストレージを節約
  • 普段はインメモリでメトリクスを保持
    • いいタイミングでバックエンドに publish する
  • ネーミングルールなどのバックエンドによる違いは Micrometer が吸収してくれる
  • カスタムメトリクスを作るときはネーミングルールに気を付けること
  • 複数のバックエンドに publish することも可
  • publish する間隔はデフォルト1分
  • Controller で HTTP リクエストのメトリクスを取ると便利 (ステータスコードとか)
  • not boot アプリでも利用可
    • もちろん Auto Configuration ではない
  • 多次元の分析ができるバックエンドがおすすめ
    • Prometheus, Datadog など
  • jvm の shutdown-hook で publish する実装になっている

JSUG勉強会 2020 その1 Spring x Kotlin に行ってきた #jsug

JSUG勉強会 2020 その1 Spring x Kotlin に行ってきました。簡単に所感をまとめます。

jsug.doorkeeper.jp

所感

いくつか Kotlin 特有の事情はあるものの、Spring で普通に Kotlin が使えるようです。特に大きなメリットとしては Coroutine あたりだろうか。逆に言うとそれ以外は Java でも同じように書けるのかなって。となると、Java から移行するモチベーションってなんだろうか、というのが正直なところ。

ただ、Kotlin 自体、書いてて楽しそうな言語だし、新しくアプリを作るなら Spring x Kotlin は全然ありだなと思います。もちろん部分的な導入でもイケそう。

ここ数年、Spring 界隈は Kotlin 推しな雰囲気を感じるし、Kotlin が重要な位置付けにいるのは間違いないです。要チェック。

以下、メモから抜粋。

Kotlin で Spring 完全理解ガイド

  • Spring Initializr は Kotlin サポート済み
  • Gradle を使う場合は build.gradle.kts が生成される
    • Kotline スクリプトで書かれている
    • Gradle は Kotlin サポート済み
  • Kotlin のクラスはデフォルトで継承不可 (open 修飾子が必要)
    • @Service などのクラスは Spring によってサブクラスが生成される
    • allopen プラグイン
    • 任意のアノテーションが付いたクラスを open クラスとして扱う
  • バリデーション
    • Kotlin のプロパティは Java のフィールドとアクセサを組み合わせたようなもの
    • @NotNull などがフィールドにかからない
    • @field 指定 + Nullable 指定
  • Kotlin にはプリミティブ型はない
    • バイトコード上は int になる
    • Int? にするとラッパークラスになる (Nullable)
  • フィールドインジェクションしたい場合は lateinit + var を使う
  • Kotlin 向け DSL
    • Bean Definition DSL
    • Router DSL
  • ktlint
  • WebFlux + Coroutine
    • Reactor 対応の公式ライブラリがある
    • Coroutine で Mono/Flux を表現
  • Ktor
  • JUnit 5
    • @Nested した場合は inner 修飾子を付ける
    • inner を付けない場合は static クラスとして扱われる
  • AssertJ / assertk
  • モックライブラリは MockK がよさそう
    • モック生成は高コストなので使い回す (clearMocks 関数でリセット)
    • Coroutine は coEvery を使う
    • static メソッドのモック可
  • DBアクセスには JdbcTemplate を使っている
    • 他には Exposed など
  • Kotlin を使うことで特にビルド時間が遅くなることはない

Spring x Kotlin のいちばんのメリットは Coroutine なのかな #jsug Kotlin 触ったことないけど、それほど障壁はなく使えそう

Spring 5.2 における Kotlin サポート

www.slideshare.net

  • Spring の中でも Kotlin のサポートは増えている
  • Spring 5.2 から公式ドキュメントのコードスニペットに Kotlin 追加
  • Router Functions
    • WebFlux.fn / WebMvc.fn
  • Kotlin 向け DSL が提供されている
    • 引数: ServerRequest / 戻り値: ServerResponse
    • WebFlux では Mono の ServerResponse を返す
  • MockMvc DSL
  • @ConfigurationProperties
    • 複数プロパティへのバインディング
    • Relaxed Binding
    • Boot 2.1 までは lateint var で宣言する必要があった
  • 2.2.0 から @ConstructorBinding でコンストラクタを通して値を設定できる
    • Boot 2.2.1 からは scan の指定が必要
      • @ConfigurationPropertiesScan or @EnableAutoConfiguration
  • Coroutine
    • 軽量なスレッドのようなもの
    • 1スレッド上で複数の Coroutine が動く
    • async/await スタイルで記述可能
    • スコープによって Coroutine 同士の依存関係が管理しやすい
  • WebFlux の Coroutine サポート
    • 戻り値に Deferred / Flow が利用可能
    • Suspending Function
  • Coroutine Router Function DSL
  • Reactor ではなく Coroutine の型が利用できる
    • Kotlin の拡張関数によってサポートされている
  • Java と Kotlin は共存可能 (あまりおすすめしない)
    • テストコードだけ Kotlin とかはありかも
  • なるべく blocking なコードは呼ばない方がよい
    • スレッドに依存するコード/ライブラリを使うときは要注意

(参考) Kotlin Fest 2019 の登壇資料

www.slideshare.net

Bsize の AI みまもりサービス GPS BoT

通学や習い事で子供がひとりで行動する機会が増えたため、子供の見守りサービスとして Bsize が提供している『AI みまもりサービス GPS BoT』を購入しました。

www.bsize.com

端末は Bsize の公式サイトで会員登録して購入しました。Amazon でも購入可。

GPS BoT お子様の現在地や行動履歴を教えてくれるAIみまもりサービス - Amazon.co.jp

ポチってから数日で発送されました。

開封

f:id:knt_mr:20200121132611j:plain

サイズ感はこんな感じ。これに別売りのシリコンカバーを付けてストラップでぶら下げています。

GPS BoT シリコンケース (ラズベリー) - Amazon.co.jp

スマホGPS BoT アプリをインストールして端末とペアリングするだけですぐに使えます。初めて充電した日が利用開始日となり課金が開始されるようです。

通知

アプリから「通知スポット」が設定できます。例えば、小学校を登録した場合、GPS BoT が小学校の近辺に来るとアプリに通知されます。ただし、GPS などの位置情報を使っているため、多少の誤差はあります。

「AI みまもりサービス」というだけあって行動パターンを学習しているようですが、しばらく使ってるうちに通知スポットの精度などは向上するんだろうか。まぁ、正確な情報を求めるよりは、なんとなく「今このあたりにいるよ」くらいの感覚で使う感じになるかと思います。

また、バッテリー残量が少なくなるとアプリに通知されます。今は「頻度優先」に設定していますが、週1程度で充電すればよさそうな感じです。

1週間ほど使ってみた感じでは特に不満はありませんが、しばらく使ってみて様子を見てみようと思います。