もはやいろんなシステムが分散システムと同じような複雑さに取り組むようになっている
- 技術が進化すると今までの信頼性モデルが破綻する、というのはなんか逆説的
ソフトウェアでプローブ効果が発生したことってある？
- マルチスレッドプログラミングしてるとき、デバッグ用のprint文を入れたら壊れた、みたいな
- 中国人Aさんが自分用のお茶を淹れた時だけ一定時間不通になる有線ネットワーク | スラド IT
機械工学出身のエンジニアとして、カオスエンジニアリングの位置づけを解釈してみた、みたいな感じ
- ソフトウェアの世界では抽象度を高くするように発展してる気がするので逆ですね

18. HOP Meets Chaos Engineering

原則５意図的な対応が重要である: Intentional Response Matters が何を指してるのかわかりにくい
- 特に intentionaly の部分
この原則の出典はどこだろう
- わからない･･･
- The 5 Basic Principles of HOP (Human and Organizational Performance) | Posts | Intelex Community
- Welcome To RELIABILITY - Welcome
- Quora で質問してみれば分かるかも
- 人事系のナレッジなのかもしれない

19. Chaos Engineering on a Database

TiDBの開発を通じての事例
正直期待外れだった
- RDBを利用する立場での取り組みならよかったのに

参考情報

2020-12-13

testcontainers のための Docker への接続情報を環境変数で指定する

development java docker

前提

Java プロジェクト
ビルドツールは Gradle
テストコードで testcontainers-java を使ってる

課題

利用する Docker は環境変数で制御したい
なるべく既存の環境変数は変更したくない

解決方法

環境変数をいい感じに解決するため dotenv-gradle を利用する
- build.gradle へプラグインを追加
環境変数を設定する .env ファイルの作成
- .gitignore で除外ファイルにしておいたほうがいいでしょう
test タスクへ環境変数を渡すため environment プロパティを指定する

例

ファイルレイアウトはこういう感じになります。

./build.gradle
./settings.gradle
./src/main/java/xxxx
./src/test/java/xxxx
./.env

.env ファイルの内容は次のような感じです。

$ cat .env
DOCKER_CERT_PATH=/path/to/docker/certs
DOCKER_TLS_VERIFY=1
DOCKER_HOST=tcp://dockerhost:2376

最終的な build.gradle は次のような感じになります。

plugins {
    id 'java'
    id 'co.uzzu.dotenv.gradle' version '1.1.0' // プラグインの追加
}
group = 'com.example'
version = '0.0.1-SNAPSHOT'
sourceCompatibility = JavaVersion.VERSION_11

repositories {
    mavenCentral()
}

dependencies {
    testImplementation('org.junit.jupiter:junit-jupiter-api:5.3.1')
    testRuntimeOnly('org.junit.jupiter:junit-jupiter-engine:5.3.1')
    testImplementation('org.testcontainers:junit-jupiter:1.14.3')
    testImplementation('org.testcontainers:postgresql:1.14.3')
}

test {
    useJUnitPlatform()
    // environment で指定した環境変数だけになるので、System.getenv() も指定しないとおかしなことになる
    environment = System.getenv() + [
        'DOCKER_HOST'      : env.fetch('DOCKER_HOST', 'unix:///var/run/docker.sock'),
        'DOCKER_TLS_VERIFY': env.fetch('DOCKER_TLS_VERIFY', ''),
        'DOCKER_CERT_PATH' : env.fetch('DOCKER_CERT_PATH', ''),
    ]
}

2020-12-06

KPT の K が溢れそうなときにやること

development

何度か KPT をやったことはあるけど、こういう考え方をしたことも教えてもらったこともなかったのでやったほうがいいよ。

KPT は期待する振る舞いとその結果を可視化する
Keep にはそうすることが自分たちに価値のある行動が集まっていく
自分たちに価値のある行動は、自分たちの期待する振る舞いそのものになる
だから Keep にいつまでも残っている行動があるなら、ワーキングアグリーメントや完成の定義に移動しよう
単純に不要になった行動には価値がないので捨ててしまおう

イメージ

f:id:yujiorama:20201206133435p:plain

参考リンク

Ryuzee.com | スプリント1を始める前にどんな準備をするか

スクラムガイド(2020年)

2020-12-06

Sonarqube REST API の OpenAPI 定義を書いた

development

趣旨

Sonarqube の管理系操作を別のプログラムで実現しようと思った
/api にアクセスするとそれっぽい API 定義をダウンロードできる
人間にも読める感じだけどそのままでは扱えない感じ
べたにクライアントを実装するのはつまらないから、OpenAPI で API 定義を記述してみた

Sonarqube REST API

ユーザー、グループ、プロジェクト、権限テンプレートに適用できる操作の一部しか書いてないけど、こういう感じになる。
(Swagger Editor とか Swagger UI で見たほうがわかりやすい)
今はこの定義から Go のクライアント実装を生成するようにしてます。

sonarqube.yaml

2020-12-06

PCでもQRコードを読みたい

development

背景

オンラインイベントで資料のリンクをQRコードで紹介する場合がある
いちいちスマートフォンのQRコードスキャナからリンクをPCへ送信するのは面倒
PCでQRコードを読めるようにすればいい
ついでに自分でもQRコードを作れるとなおよい

解決方法

QRコードを作成するにはqrencodeを使う
QRコードの読み取りにはZBar bar code readerを使う

QRコード画像を作る - qrencode

WSL 環境ならたいていのディストリビューションにパッケージが入ってるはず。

たとえば Ubuntu/Debian ならこれだけでよい。

apt update && apt install qrencode

QRコード画像を作るときはこうする。

qrencode -o google-qr.png https://www.google.com

f:id:yujiorama:20201206132126p:plain

Windows のコマンドプロンプト（PowerShell や cmd や Git bash）から実行したいときはwslコマンドで実行すればいいと思う。

先にWSLの環境に qrencode をインストールしておく必要がある
出力ファイルのパスはWSL環境で解釈できる形式にしないといけない

wsl qrencode -o google-pr.png https://www.google.com

QRコード画像を読み取る - zbarimg

WSL 環境ならたいていのディストリビューションにパッケージが入ってるはず。

たとえば Ubuntu/Debian ならこれだけでよい。

apt update && apt install zbar-tools

上で作ったQRコード画像はこういうふうに読み取ることができる。

WSL環境ではLinuxのdbus機能が動作しないため、必ず --nodbus オプションを付けないといけない
先頭の QR-Code: は消せないのでいい感じに加工しないと使えない

$ zbarimg --nodbus --quiet google-qr.png
QR-Code:https://www.google.com

2020-11-17

第8回 Chaos Engieering 読書会@リモートのログ

javaeestudy chaosengineering

learning.oreilly.com

javaee-study.connpass.com

引き続き Discord によるオンライン開催。

こちらのリストで次の本を検討してます。

次回は 17. Let’s Get Cyber-Physical の Chaos Engineering as a Step Beyond FMEA から。

javaee-study.connpass.com

トピック
ディスカッション
参考情報

トピック

iPhone 12 Pro は以外と大きいみたいなので買うかどうかで悩ましい
Apple Silicon な新 mac は Docker が動かないのは悩ましい
Cyberphysics は IPA の情報処理技術者関係の試験にも出てくる概念だった
WFH を改善するため引っ越すことにした
Raspberry Pi で自宅 Kubernetes クラスタを組んでみたり

ディスカッション

15. Chaos Maturity Model

15.1 Adoption 採用

組織として重大インシデントの経験があるかどうかも重要だと思う
- もう少し条件がありそう
障害やインシデントに対する事業価値を計測できるようなると同時に導入するのが理想的じゃないかなぁ

15.2 Sophistication 啓蒙

ゲームデイは必要
いきなり汎用的なソリューションを開発しようとするのはよくない
意味がわからないんだけど「一定期間内に消費できるKPIの猶予として「カオスバジェット」を設計する」
- 実験によりビジネスの望まない損失が発生しないことを保証できるようになる
- 実験の仮説を立てるときに織り込み済みなんだと思ってたので、ここで改めて登場する話なのかなとも思った
  - 実験を自動化することに伴うヒューリスティクスの実装という理解でいいのかな
納得した「実験が進化すると対象はインフラストラクチャ、アプリケーション、ビジネスロジックの順に進んでいくことになる」
- 「ビジネスロジック」について、一定の割合である商品の購入に失敗する、みたいな実験のほうがよっぽど簡単そう
  - ビジネスとしては VM 落とすとか手段はどうでもいい
- つまり「ビジネスロジック」から実験していくほうが簡単そう

15.3 Putting It All Together

16. Continuous Verification

ChAP の自動カナリア、、、プロアクティブな実験、、、何のことを言ってるのか分からない
- 自動カナリアって CD の範疇だよね
- プロアクティブな実験って、カオスエンジニアリングってそういうものだったよね
GitHub - Netflix/vizceral: WebGL visualization for displaying animated traffic graphs はすでに利用されてないそうです
Continuous Verification: The Missing Link to Fully Automate Your Pipeline – The New Stack
- CD はデプロイすることが目的で、CV は最適化することが目的

17. Let’s Get Cyber-Physical

https://www.linkedin.com/in/nathanaschbacher/

デジタルツインという考え方が流行ってる
- いまさら聞けない「デジタルツイン」 (1/2) - MONOist（モノイスト）
- Digital twin - Wikipedia
IEC 61508 - Wikipedia
FMEA の欠点をカオスエンジニアリングのプラクティスで回避できるんじゃないかという考え方
- 想像ではなく実際の値を確かめる
- 機械が漏れなく確かめる
CPS 固有というより最近の電子デバイス一般と言える話題のような気がする
著者は、自動車の自動運転という枠組みで、本番環境で実験することをどうやって実現しようとしているのか

参考情報

2020-10-18

JPA のエンティティクラスに必要なデフォルトコンストラクタは直接記述する

development java

JPA のエンティティクラスにデフォルトコンストラクタとして Lombok の @NoArgsConstructorを利用すると開発の邪魔になる問題が発生するので使わないほうがいい。

@Entity
@Table(name = "staff")
@Data
@AllArgsConstructor
@NoArgsConstructor(onConstructor = @__(@PersistenceConstructor))
@With
public class StaffEntity implements Serializable {

    private static final long serialVersionUID = 1374L;

IntelliJ IDEA ではこういう見た目になる。（ちょっとわかりにくいけど L19 の @__ がコンパイルエラーになっているため赤字になっている）

あらゆる場所でエラーの存在が喧伝される状態になるため、本当に問題がある場所が分からなくなってしまう。なので、デフォルトコンストラクタだけは直接記述したほうがいい。

f:id:yujiorama:20201018141701p:plain

詳細

JPA のエンティティクラスには引数無しコンストラクタが必要。

ただ、Spring Data を使ってる場合は @PersistenceConstructor で指定したコンストラクタを利用することもできる。面倒なので一致させておくけど。

Lombok の @NoArgsConstructor を利用すると簡単にデフォルトコンストラクタを生成できる。生成したコンストラクタに @PersistenceConstructor を指定するには onX 機能を利用する。

@__ は、括弧の中身をコンパイラに解釈させず注釈プロセッサで処理することを指示するための特別な記法。要するに @__(@xxx) と記述したら Lombok の生成したコードに @xxx を指定することになる。しかし IDEA の構文チェッカ―は @__ を解釈できないので見た目上はコンパイルエラーになってしまう。

@__ の代替記述として属性名を onConstructor_ とする方法もあるけど、やはり IDE の構文チェッカ―には解釈できないためコンパイルエラーになる。

こちらの方法は左辺値が確定しないため、右辺値を入力するときにコード補完が効かなくなる。つまり @__ を使う場合より都合が悪い。したがって、こちらの方法を採用するわけにいかないので、結局直接記述するのが一番だという結論になる。