色つけツール colr に、逆に受け取った標準入力から色を消す --erase オプションを追加した

Golang

地味に普段から重宝している colr に --erase オプションを追加しました。

colr についての紹介エントリは以下をご覧ください。

k1low.hatenablog.com

色をつけたいことがある。そして色を消したい時がある

colrによってカジュアルに色をつけた標準出力を得ることができるようになったのですが、一方で色を消したいときもあることに気づきました。具体的にはエスケープコードを外したい。

標準出力をファイルやクリップボードなどに保存するとき、ツールによっては擬似端末かどうかに関わらず色つけ用のエスケープコードを強制的に出力するものがあります。

colrもそうです（理由についてはエントリを参照）。

意外に消したいタイミングは多くその度にそのコマンドの色消しオブションだったりsedなどで対応していたのですが、毎回ググるのもアレなので実装することにしました。

別コマンドにするか迷いましたが、あまりに小さい機能だったのでcolr にオプションとして追加しました。

使い方は簡単で colr --erase をパイプに繋げるだけです。

$ any-colorful-command | colr --erase

具体的な実装ですが、 mattn/go-colorable の NonColorable をそのまま活用しています。便利！

v1.0.0

他に追加の機能が思いつかなかったので v1.0.0 としました。安定板。

このまま枯れたコマンドとして生きながらえてくれるといいなと思います。

filtに tail -Fなストリームだけでなくcat /path/to/access.log のような標準出力に対しても何度でもコマンドを試行錯誤できる機能を追加した

Golang

"トライアルアンドエラーパイプ"ことfiltに、tail -F /path/to/access.log なストリームだけでなく cat /path/to/access.log な標準出力に対しても何度でもコマンドをパイプで繋げて試行錯誤できる機能を追加しました。

k1low.hatenablog.com

今回新たに追加された機能もあわせて、使い方を紹介します。

使い方

filt v0.5.0の時点で使い方は2種類あります。

ストリームデータ（従来の使い方）

連続してデータが流れ続けてくるような標準出力には、パイプで filt を繋げます。

$ tail -F /path/to/access.log | filt

このときのユースケースとしては、

「今リアルタイムに流れているデータに対して 何度でもコマンドを試行錯誤したい」

というものになると思います。

filtの標準入力にはそのまま途切れずにデータが流れてきます。

オプションなしのデフォルトの filt のとき、filtが提供するプロンプトでパイプで繋げるコマンドを入力すると、filtはそのコマンドに都度 その時流れてきたデータから 流します。つまり、コマンドを入力するまでのデータは保持せず捨てます。

これによりリアルタイム性を保持したまま、ストリームに対して「何度でもコマンドを繋げて試行錯誤する」ということを実現しています。

終端がわかっているデータ（新しい使い方）

保存済みのアクセスログの検索や整形など、データの終端がわかっているような標準出力には、--buffered オプションをつけてパイプで繋げます。

$ cat /path/to/access.log | filt --buffered

このときのユースケースとしては、

「/path/to/access.logの先頭から終端までに対して 何度でもコマンドを試行錯誤したい」

というものになると思います。

filt --buffered のとき、filtはまずデータの終端までバッファに読み込みます。そして、filtが提供するプロンプトでパイプで繋げるコマンドを入力すると、filtはそのコマンドに、都度 バッファに保持したデータを最初から 流します。

これにより、標準入力で受け取ったデータに対して「何度でもコマンドを繋げて試行錯誤する」ということを実現しています。

v1.0.0に向けて

これで、ほとんどの標準出力に対してとりあえずパイプでfiltを繋げてコマンドを試行錯誤するということができるようになったと思います。

filtは私自身日常的に使っているツールです。しばらく使って使い勝手に問題がなければ、微調整後 v1.0.0 にして出そうと思っています。

「とりあえずパイプでfilt」

で開発体験がより良くなれば幸いです。

PostgreSQLの運用練習の成果をコードで残していっている

PostgreSQL

RDBMSのレプリケーションなど、なんとか調べてギリギリ理解して組んで、その後新規レプリケーションを組むか障害が発生したとき、また一から調べている気がするので、動く環境として記録していくことにしました。

github.com

これはなに

今のところ、PostgreSQLの ストリーミングレプリケーションの構築->フェイルオーバー->再レプリケーション までをひと通りMakefileにまとめたものです。

2019年10月時点では、非同期と同期のストリーミングレプリケーションを1種類づつ作っています。

コードでまとめることで良かったこと

何度も試せる

まず何度も試せるのが良いです。設定変更の検証などもすぐです。

私は今回試行錯誤した結果、2桁はレプリケーションを組んだので、レプリケーションがあまり怖くなくなりました。

設定に多くのパターンがあることがわかった

実際に手を動かすと頭に入ってくるということだと思います。知らないことが多すぎた。

レプリケーションの種類でも2種類（ストリーミング、ロジカル）、ストリーミングレプリケーションのほうだけでも、同期非同期、トランザクションにも数種類、マスタ昇格の方法、スタンバイ方法、リカバリ方法、etc...

興味があるところだけ作ってみましたが、再現可能なコードになっているので他の設定も試しやすいです。

CIが利用できる

CIを利用して、複数の環境で検証することが楽になります。

その結果、PostgreSQLのバージョンをまたいで同じ設定が使えるかどうかなどがわかります。

とりあえず、PostgreSQL12ではrecovery.confを使ったリカバリはサポートされていなさそうだということを知りました。

他の人に共有できる

再現可能なコードで残っているため他の人に共有がしやすいです。

なんなら（作っている範囲であれば）ハンズオンも簡単です。

有識者から指摘を受けられる可能性がでてくる

コードなので、設定も想定運用も全てコードで見えます。

そうするともしかしたらインターネット上の有識者から「pg_rewindを使ったほうがいい」「そのパラメーターは少し間違っている。こっちのほうがいい。なぜなら〜」などの指摘をもらえる可能性があります。

これからしたいこと

このリポジトリは完全に自分の練習の成果を残すもので、これからもいじっていく予定です。永遠のWIP。

Dockerの環境でできる範囲でですが、いろいろなパターンも試してみたいと思っています。

また、今後現場でも体験するであろうPostgreSQLのバージョンアップなどもコードで残していきたいと思います。

第5回Web System Architecture研究会に参加した #wsa研

第5回がまた福岡で開催されるということで、第2回参加から久しぶりでしたが、参加・発表してきました。

発表内容

予稿

github.com

発表資料

発表内容は、「関係する（コンポーネント間で通信をしている）コンポーネントのログの流量の間には相関があるはずで、その相関をみることで異常や異常箇所特定の足がかりにできるのではないか」というものです。

発表してみて

先行研究の発見

着眼した個所は多少違うのですが、「複数の関係する時系列データの相関を見ることで異常個所を特定する」というアイデアが、 matsumotoryさんの学部時代の研究と全く同じだったのは驚きでした。もしサーベイするならmatsumotoryさんの学部卒業論文からですね。 あれ？ブログからかな？

この私のログの研究？は、要はシステムにおいて経験値が大きいエンジニアと経験値が小さいエンジニアの差を埋めるのでは？と思って行なっています。研究者ではないのでそこまで時間は取れませんが、その分肩肘張らずにやっていきたいと思います。

こういうことを教えてもらえるのも研究者が参加しているWSA研の良いところです。

多くのフィードバック

たった15分の発表ですが、今回も多くのフィードバックをもらうことができ、頂いたアイデアやフィードバックに知識インデックスがはられました。

WSA研では、質疑応答にも発表時間と同じ15分の時間がとられていることと、（今のところ）発表者＝参加者なので、発表者-参加者間の距離が小さいことが良い効果を発揮しているのかも？と思っています。

幅広い、そして興味深い発表

Web System Architecture 研究会のサイトにも予稿やスライドがアップされていますので是非みていただきたいのですが、どれも興味深く聴くことができました。

残念ながら最後のセッション4は子供の体調不良で途中退席せざるを得なかったのが本当に残念でした。

今回も楽しく参加できました。ありがとうございました！

filtのコマンド履歴を保存できるようにした

Golang

"トライアルアンドエラーパイプ"ことfiltで、パイプに繋いだコマンドの実行履歴を保存して次回filt実行時に補完候補として利用できるようにしました

k1low.hatenablog.com

コマンド履歴保存の有効化方法

以下のコマンドを実行することで有効化できます。

$ filt config history.enable true

無効化は

$ filt config history.enable false

です。

コマンド実行を再利用したい人は有効化してみてください

"2 hours" のような文字列をパースして time.Duration を取得する duration パッケージを作った

Golang

Harvest のログ取得期間指定をより柔軟にできるように --duration オプションを追加したかったのですが、

  • 標準の time.ParseDuration() ではあまり柔軟ではない
  • 既存パッケージを探したけれども time.Duration を返すものを見つけられなかった

ので作りました。

github.com

使い方

duration.Parse() は time.ParseDuration() と同じように利用できます。

time.ParseDuration() と異なる点は 4hours や 1minute などの単位表記も判定できるという点です。

package main

import (
    "fmt"

    "github.com/k1LoW/duration"
)

func main() {
    d, _ := duration.Parse("3 days 4 hours")
    fmt.Printf("%s", d)
    // Output: 76h0m0s
}

これだけです。

というわけで

--duration オプションを作りたいときに、ご検討ください。

debパッケージをダウンロードURLを指定して直接インストールしたい

「yumコマンドならできるのに」

そんなことを思ったことが何度もありました。皆さんはどうしているんでしょうか？

シェルスクリプトで書くならどんな感じかなと思って書いてみました。

そして、そのシェルスクリプトを毎回コピペするくらいならスクリプト自体もcURLで取得して実行するようにしてみました。

github.com

使い方

$ curl -L https://git.io/dpkg-i-from-url | bash -s -- [DEB_URL]

以上です。

使ってみても全然便利になった気持ちになれないのはなんなんでしょうかね。。。？