「入門監視」を読んだ

読書メモ

入門監視を読んだ

入門 監視 ―モダンなモニタリングのためのデザインパターン

入門 監視 ―モダンなモニタリングのためのデザインパターン

  • 作者:Mike Julian
  • 発売日: 2019/01/17
  • メディア: 単行本（ソフトカバー）

最近仕事で、アプリケーションのアラート周りの整理をしている。

一緒にやってる同僚がこの本の読書会を社内で企画して、せっかくなら読んでみようと思ったのがきっかけ。

アンチパターンがまとまっている

SQLアンチパターンなんかもそうだけど、「こうするといいよ」以上に「これはやめとけ」がまとまっている方が実用的な気がする。

正解は割とコンテキストによっていつも違うけれど（というかない）、アンチパターンは割とどんな場合でも変わらないことが多いと思うから。

運用も含めて学べる

何をどう監視するか、ということも勿論丁寧に書いてあるんだけど、それを日々運用していったり、改善することをイメージできるように書いてあると思う。

アラートを仕込んで、じゃあアラートが飛んできたらどうするんだっけ？みたいなことを想像できる。

監視の起点

監視の起点がシステムというよりは、エンドユーザーとかビジネスKPIという感じで書かれていて、いいなぁと思った。

ツールは目的じゃないけど

ツールが目的にならないようにという警告をしているんだけど、一方で SaaS の活用を推奨している。

すごく同意できるなぁと思った。

OSのメトリクスはあんまり？

OSのメトリクスは直接的には何も分からないので、監視としては微妙というようなことが書いてあった。

それはそうだなと思いつつ、「何か起きている可能性がある」とか「何が起きているか分からないのでどこから調べるか」の大きなヒントになった経験があるので、大事にしたいなとは思うのだった。

たぶん相対的な重要度の話をしているのだとは想像しつつ。

難しいところもあった

難しくてわからないところもそれなりにあった。

たとえばネットワーク監視のあたりとか。

デファクトっぽいツールの紹介も聞いたことがなかったり。

インフラエンジニアの人だったら常識なのかなとか、オンプレだと結構身近なキーワードだったりするのかなとか。

まとめ

監視を起点にまとまった本は読んだことがなかったので、とても勉強になった。

入門監視 読書メモ · GitHub

Web API の JSON レスポンス等で、null を返すのかプロパティごと削除するのか

概要

表題の通りの疑問なのですが、個人的な結論は出ていないです。

返しても意味がないなら消してよいのではという意見

まぁそうだよねぇ、という気がする。

softwareengineering.stackexchange.com

required と nullable は同様に扱おうという意見

クライアントを混乱させるなってことっぽいけど確かに、という話。

でもどっちがいいとは書いてない。

opensource.zalando.com

感想

意味がない値なら返さなくていいかなー、という気がする。

そもそも null に意味をもたせるのは可能な限り避けたいし。

ただ配列の場合は空配列を返したほうがいいのかなって思う。

これは Effective Java なんかで言われてる、空のコレクション返すのと同じ理由。

AWS CLI v2 の Docker イメージで JSON が Parse Error になる #AWS #Docker

AWS docker

概要

AWS CLI を Docker Image 使って利用してみたのだが、出力に jq を噛ませたところ parse エラーになった。

出力に制御文字が入り込んでいるみたい？

tty オプションを外してみたら解消された。

動作環境

  • Mac OS 10.15.5
  • Docker for Mac
  • Docker version 19.03.12, build 48a66213fe
  • aws-cli/2.0.36 (Docker Image を使用)

AWS CLI のイメージを使う

docs.aws.amazon.com

公式に従って導入する。

認証情報の設定等はこの記事では省略。

下記のような感じでコマンドが叩ければ OK 。

$ docker run --rm -it -v ~/.aws:/root/.aws -v $(pwd):/aws amazon/aws-cli --version
aws-cli/2.0.36 Python/3.7.3 Linux/4.19.76-linuxkit docker/x86_64.amzn.2

長いので、 alias を設定しておく

alias aws='docker run --rm -it -v ~/.aws:/root/.aws -v $(pwd):/aws amazon/aws-cli'

jq を噛ませると Parse Error が発生する

AWS CLI で iam list-access-keys を実行する。

JSON 出力した結果を jq に噛ませたら Parse Error になってしまった。

$ aws iam list-access-keys | jq .
parse error: Invalid numeric literal at line 1, column 2

一度ファイルに出力して中身を見てみると、制御文字？っぽいものが紛れ込んでいた。

[?1h=
{[m
    "AccessKeyMetadata": [[m
        {[m
            "UserName": "xxxxxx",[m
            "AccessKeyId": "xxxxxx",[m
            "Status": "Active",[m
            "CreateDate": "2020-08-01T08:21:24+00:00"[m
        }[m
    ][m
}[m

[K[?1l>

tty オプションを外してみる

色々調べてみたところ、 tty が悪さをしているようで、改行コードが CRLF になっちゃっているみたい？

tty オプションを外してみると、制御文字が入らないようになった。

alias aws='docker run --rm -i -v ~/.aws:/root/.aws -v $(pwd):/aws amazon/aws-cli'

※ -it を -i にしている

参考

GAS (Google App Script) の Moment.js の出どころを調べる #gas

gas

概要

GAS でも Moment.js が使えるらしいが、どこもプロジェクトキーを書いてあるだけだったりして、出どころがよく分からない。

そもそもプロジェクトキーはサポートが終了したようなので、スクリプトIDを知りたい。

Moment.js の公式サイトや GitHub リポジトリにそれっぽい話はない。

Google が作ってるって書いてある人もいるけど、ホントか。。？となったので調べてみた。

あるサイトからスクリプト本体へたどり着く

public な GAS ライブラリをまとめているっぽいサイトを見つけた。

Moment - GAS Library Management (public)

Moment.js が Google の下にあるが、そもそもサイト自体ももうメンテナンスされていないようである。

ただ、ここからスクリプトの本体にはたどり着けた。

https://script.google.com/a/connehito.com/d/MHMchiX6c1bwSqGM1PZiW_PxhMjh3Sh48/edit?usp=drive_web

ライセンスとかも明記しているし、ちゃんとしている感。

バージョンは Moment.js 本体とは別物のようだ。

関係者っぽい人

同じサイトから、データの元になっているスプレッドシートを見つけた。

More Google Apps Script Libraries - Google スプレッドシート

「More Info」に期待してクリックすると 404 なのだが、URL を見ると今はなき Google+ で、アカウント名っぽいのは分かる。

https://plus.google.com/u/0/+EricKoleda/posts/ThnVjUgU3E9

んで、探してみると、 Google の中の人のようなことと、 GSuite 関連の開発をしている人っぽい。

https://twitter.com/erickoleda

https://github.com/orgs/gsuitedevs/people

Google+ の投稿が消えてるので想像になるが、おそらく「GAS で Moment.js 使えるようにしたぜ！」的なアナウンスだったんじゃなかろうか。

まとめ

結局個人でやったものなのか、Google として出しているものなのか確証はない。

GAS で公開ライブラリ探したり使ったりするときは皆どうしているのかな？

なんか GAS で外部ライブラリ積極的に使おうって気持ちにはならなかった（Google公式の拡張みたいなやつは別にして）。

「SCRUM BOOT CAMP THE BOOK」にコラムを書きました (そして旧版の思い出) #scrumbcbook #devsumi

Scrum

SCRUM BOOT CAMP THE BOOK【増補改訂版】 スクラムチームではじめるアジャイル開発

SCRUM BOOT CAMP THE BOOK【増補改訂版】 スクラムチームではじめるアジャイル開発

5/20 に SCRUM BOOT CAMP THE BOOK の増補改訂版が発売されました。

学習と成長を促進する Scrum ですが、 Scrum 自身も成長を続けています。

スクラムガイドの改訂を取り込み、よりパワーアップしているので、ぜひ読んでみてください。

ご縁があって、僕もコラムという形で参加しています。

とても思い入れのある本なので、自分の名前が載ることになったのは非常に感慨深いものがあります。

発売イベントも開催予定（オンライン）なので、よかったら参加してみてください（枠追加されたようです）。

connpass.com

「SCRUM BOOT CAMP THE BOOK」の思い出

ここからはただの個人的な思い出話です。

旧版を読んだのは 2013年の2/14です。

なぜこんなに正確に覚えているかというと、デブサミの会場で購入したためです。

当時の僕はチームやプロジェクトのリーダーをやるようになっていて、ある程度の自信を付け始めていた頃です。

要件定義をして、設計してテストして。。みたいなことを割とうまくやっていたと思います。

そんな中、新規サービスの立ち上げに関わらせてもらっていたのが正にデブサミのタイミングでした。

event.shoeisha.jp

サービス開発において無力だった

新規サービスではそもそも要求や要件がまったく定まっていません。

ああでもない、こうでもない、という会議が繰り返され、一体いつになれば作り始められるのか、作り始めたと思ったらやり直し、ただ時間だけが過ぎていく。。そんな状況でした。

そんなとき、たまたま手にとったのが (旧)SCRUM BOOT CAMP THE BOOK でした。

すぐ読み終えた

帰りの電車で読み始めて驚きました。

不確実で不透明な状況に立ち向かうためのヒントが SCRUM BOOT CAMP THE BOOK には散りばめられていたからです。

そのままの勢いで読み進め、その日の夜にはもう読み終えていたと思います。

直人さんの話を聞きに行く

タイミングとは不思議と噛み合うもので、デブサミの二日目に著者の一人である西村直人さんのセッションがありました。

当然、是非話を聞きたいと参加を決めたのでした。

event.shoeisha.jp

Action!!

その年のデブサミのテーマは「Action」でした。

それゆえか、直人さんの話も何か「行動を始めよう」という主旨の話だったと記憶しています。

「ひとりでペアプロを始めた」という本気か冗談か分からない話を聞いて、自分は強く背中を押されました。

Scrum に大きな魅力を感じたのは間違いありませんでしたが、少し距離を感じていたのも事実です。

プロジェクト自体はウォーターフォールだし、チームのリーダーと言ってもサブチームの一つにしか過ぎないし、そもそも関われる範囲は開発に限られるし。。

やらない理由はいくらでもありました。

でもこの講演を聞いて、「できることは何か少しでもあるはずだ」「どんな形でもいいから始めるんだ」という気持ちに切り替わりました。

Scrum を始めてみた！

土日を挟んで週明け、「やり方を変えてみたい」と、チームのメンバーを集めて思いを伝えました。1

プロダクトバックログというよりも、Excel に書いたただの TODO リストだったかもしれません。

スクラムマスターも、プロダクトオーナーもいませんでした。

見積もりは、カードもないプランニングポーカーでした（せーので数字を言う、みたいな）。

でもあの時、一歩を踏み出したことから色々なことが動き出したと思っています。

何よりも、変化と学習と成長を楽しめるようになりました。

よりパワーアップした SCRUM BOOT CAMP THE BOOK が、僕と同じように、誰かが一歩を踏み出すきっかけになればいいなと思います。

  1. 当時「やってみましょう」と賛同してくれたメンバーのみんなには今でも感謝しています↩

「みんなの Java 」を読んだ

読書メモ Java

みんなのJava　OpenJDKから始まる大変革期！

みんなのJava　OpenJDKから始まる大変革期！

主に Java のリリースサイクルの変更とか、結局 JDK どれ選んだらいいの？みたいなところを整理したくて読んでみた。

関心が低いところは流し読みだったり全く読まなかったりした。

第1章　Java 9からJava 14までに起こった変化から見るこれからのJava

新しい言語仕様や標準ライブラリの変更が分かりやすく紹介されている。

すぐに使えそうなものも多いし、どんどん便利になっていてワクワクする。

ただ一方で今後も含めて出来ることが増えていくと、ベタープラクティスを見つけていくのが大変になるかもなぁと思うなどした。

第2章　JDKに関する疑問と不安解消！JDKディストリビューション徹底解説

ちゃんと理解できたかは怪しいけど、自分の扱う領域で考えるとしたら↓のような優先順位かなぁと思った。

  • 最新に追従していけるなら Oracle Open JDK
  • LTS を使うなら Amazon Corretto
  • 有償サポートを検討するなら Oracle JDK

第5章　ネイティブイメージ生成で注目！ Javaも他言語も高パフォーマンスGraalVM

ユニバーサル VM すごい。

他言語の処理を手軽に十分なパフォーマンスで呼び出せるのは夢がある。

GraalVM のネイティブイメージがどんどん洗練されていったら、 Web なんかだとそっちを利用することの方が多くなるのかな。

今後も注目。

第6章　マイクロサービス，クラウド，コンテナ対応［新世代］軽量フレームワーク入門

もともとちょっと気になっていた Micronaut は AWS Lambda との連携も簡単にできるらしい。

「ドメイン駆動設計入門」を読んだ

DDD 読書メモ

ドメイン駆動設計入門 ボトムアップでわかる! ドメイン駆動設計の基本

ドメイン駆動設計入門 ボトムアップでわかる! ドメイン駆動設計の基本

  • 作者:成瀬 允宣
  • 発売日: 2020/02/13
  • メディア: 単行本（ソフトカバー）

最近は言葉が独り歩きしているような気もするドメイン駆動設計の本。

DDD に限らず設計の話は抽象的になりがちなので、この本は入門書として「実際のところコードはどんな感じに書くのよ？」っていうのが軸で分かりやすかった。

ただそれゆえにパターンの理解としてはいいんだろうけど、ドメイン駆動設計の本質的な、ドメインに向き合うことへどう繋げていくかというのが次のテーマになるんだと思う。

あと個人的に、コードの記述量やファイルが増える問題に対する解決策が自動生成というのはかなりもにょるのであった。

ドメイン駆動設計読書メモ · GitHub