生活のメトリクスを取るのが難しい
ここ最近調子が悪い気がしている。気がしているだけでなく、間違いなく調子は悪い。
しかしながら、どれくらい調子が悪いかというのを知るのは意外と難しい。
これまでに指標としてきたのは主にコミット数であった。しかし、これは思ったより機能しなかった。
調子を計測するためのメトリクスは意外と難しい。睡眠時間やコミット数などは客観的な指標と、一日をいい気分で過ごせたか、起きるときにすっきりと起きられたかなどの、主観的な指標も大切だ。
しかしながら、主観的な感覚はそもそも指標にするのが難しい。おそらく細かな値でとるのは不可能だし、5段階評価程度でも絶対的な数値にするのは難しく、前日との比較などでとるのが適切であるような気がする。だが、その見方はグラフにして直観的に把握するには不向きである。
最近ぼんやりと考えているのは客観的な指標と主観的な指標の両方を取りつつ、主観的な感覚に相関性のある客観的指標を見つけることで、その客観的指標を主観的感覚の代替とすることで、主観的指標をグラフから直観的に読み取れるのではないだろうかという仮説だ。
ただ、生活のこのPDCAを回すのは時間がかかる。数日単位では意味のある値は出てこないので、一月程度はやってみる必要があるだろう。そして、データも大量にとればよいというものではない。私の性格上、あまりに多くのデータを記録しようとすると、投げ出してしまうことが目に見えている。そうなってしまっては元も子もないから、項目はある程度絞る必要がある。不完全であれ、毎日ちゃんと記録を取るということを習慣づけて、年単位で続けていかなくてはならない。
記録するアプリも、まずは記録する習慣をつけることを優先して、かなり適当に選んでいる。よくある失敗パターンとして、良いアプリを探しすぎて始められなかったり、完璧なデータを取ろうとしすぎて続かなくなったりすることがある。今回は、記録をする習慣をつけるということを最大限に意識して、アプリやデータの質についてはあえてあきらめるというスタンスを意識している。最低限の機能として、値をグラフ表示できることと、データをエクスポートできること、それ以外は無視して選んだ。
春くらいにはグラフから調子がある程度把握できるようになっていたいところだ。
V-DEV のメンバーなった
布団に入って寝る前の読書もそろそろ終わろうかなと思ったところで、V言語 の discord からの通知。
そもそも英語が得意ではなく、チャットについていけないので、discord で発言することは少ないし、だから通知が来ることなんてめったにない。
何事かと思って開いてみると、見覚えのないチャンネルで welcome と言われていて、そこはコアメンバー用のプライベートチャンネルだった。
そして、自分のアイコンが V-DEV の一覧に表示されていて、V-DEV のメンバーになったことを知った。
継続的なコントリビューションを続けて約2か月。いつかメンバーになりたいというのは意識していたことではあるが、実際のところ加われるのは春くらいになるだろうと思っていた。V-DEV のメンバーは 20 名強で、そこに招待してもらえたというのはそれだけの評価をしてもらえたということであり、当然のことながらうれしい。
「招待ありがとう。改めてよろしく」を英語でどういえばいいのかわからなくて 30 分くらい調べていたら、眠気はすっかりと吹き飛んで、ただでさえ崩れかかっている生活習慣がピンチ。
とまれ、一つの目標に到達したことはうれしいことで、健全な多幸感とともに夜更かしをする日というのは人生に必要なものだろう。
体調管理のメトリクスとしてコミット数を計測するスクリプトを書いた
体調管理とメトリクス
食事量や睡眠時間など、体調管理のために定量的なメトリクスを取ることは非常に大切。双極性障害を患っている人にとっては特に。
往々にして、そんなものを取らなくても体調くらい感覚でわかると思いがちだが、それはまずありえない。記録を取ってみると分かるが、自分の感覚と数値として出てくるものはかなり乖離する。
GitHub と体調管理
体調管理の指標として、どれだけコードが書けているかというのが私の場合は大きい。嫌々コードを書くということは基本的にないので、たくさんコードを書けているということは、楽しく生活できているということだ。
ということで、普段から GitHub の Contribution (いわゆる草）を指標にしている。
草の欠点
ただ、この草を見るだけでは足りない部分があることがわかってきた。
まず、草の色が相対的かつあまり細かく色分けされないこと。以前はやる気が出ないと真っ白になっていたのでそれでも問題なかったが、最近毎日 1 contribution をすることを意識するようになって、基本的に色がついているので、分かりづらい。
そして、デフォルトブランチ以外への commit が反映されない。自分のレポジトリにコミットするときは基本的にデフォルトブランチにそのままコミットしてしまうので問題なかったが、最近は V 言語のコードを書いていることも多く、PR を作るかマージされないと contribution として記録されない。
スクリプトを書いた
ということで、簡単なスクリプトを書いた。各リポジトリから git log を集めて、日付ごとにテキストファイルに書き込む。テキストファイルの行数がそのままコミット数になる。
公開する意味は特にないが、スクリプト部分は公開してみた。集計結果もリポジトリにしているが、プライベートなリポジトリ名が入っているので、そっちは非公開 github.com
プライベート部分のスクリプトはこうなっている。
n=${1:-7}
for i in $(seq $n)
do
d="-$i day"
day="$(date -d $d '+%Y-%m-%d')"
zone="$(date -d $d '+%z')"
file="$day.txt"
echo "$day ..."
zsh ./collect-commits/collect-commits.zsh \
--dirs "$GHQ_ROOT/github.com/zakuro9715" \
--since "${day}T00:00:00${zone}" \
--until "${day}T24:00:00${zone}" \
>> $file
cat $file | sort | uniq > $file
done
11 月から集計してみるとこんな感じだった。
wc 2020-*.txt -l
1 2020-11-01.txt
1 2020-11-02.txt
4 2020-11-03.txt
4 2020-11-04.txt
5 2020-11-05.txt
15 2020-11-06.txt
25 2020-11-07.txt
17 2020-11-08.txt
2 2020-11-09.txt
1 2020-11-10.txt
3 2020-11-11.txt
47 2020-11-12.txt
1 2020-11-13.txt
6 2020-11-14.txt
5 2020-11-15.txt
21 2020-11-16.txt
1 2020-11-17.txt
5 2020-11-18.txt
4 2020-11-19.txt
0 2020-11-20.txt
8 2020-11-21.txt
20 2020-11-22.txt
10 2020-11-23.txt
10 2020-11-24.txt
1 2020-11-25.txt
10 2020-11-26.txt
2 2020-11-27.txt
1 2020-11-28.txt
30 2020-11-29.txt
3 2020-11-30.txt
2 2020-12-01.txt
1 2020-12-02.txt
0 2020-12-03.txt
0 2020-12-04.txt
1 2020-12-05.txt
2 2020-12-06.txt
4 2020-12-07.txt
8 2020-12-08.txt
3 2020-12-09.txt
0 2020-12-10.txt
4 2020-12-11.txt
21 2020-12-12.txt
5 2020-12-13.txt
1 2020-12-14.txt
1 2020-12-15.txt
1 2020-12-16.txt
5 2020-12-17.txt
322 合計
59 合計
ところで、当然コミットしないと集計されないので、設計に頭を悩ませていたり、issue や PR での議論に時間を使っていても数字として出てこない。
万能の指標はなく、いろいろな指標を組み合わせて使うべきなのは当然ではあるが。
V 言語に Contribute を始めてしばらくたった
無職になって暇なので OSS 活動でもやろうかと思い、V 言語に Contribute している。
V 言語を選んだのは、活発に開発されており、将来性もありそうに感じたので、今後有名になった時に自慢できそうという結構打算的な理由である。
正直なところ V 言語それ自体を特別気に入っているというわけではなく、嫌いではないけど特別好きでもない。
V 言語の開発体制の話。
とにかく開発が活発でスピード感があり、出した PR は 24 時間以内にマージされることが多い。レビューも結構適当で、明らかに間違っているコードがマージされたりもする。
標準ライブラリにメソッドを足す PR が出してから 10分程度でマージされたのには驚いた。
そういう感じなので、OSS 初心者でも PR が出しやすいプロジェクトだと思う。
ただ、PR は squash してマージされるので、Contribution のコミット数は少なくなりやすい。コミット権のあるメインの開発者は master に直接コミットしているので、Contribution 数が多くなっている。正直ずるい。しかも普通に master を壊したりする。
2週間 GitHub に草をはやした
意識してみれば意外と簡単なことだった。重要ではないが簡単なタスクをプールしておいて、何もしてない日の終わりにそれをやればよい。
ただし、意識しないと難しい。ほかの用事であまり開発をしない日というのはあり、毎日草をはやすという意識がないと何もせずに終わってしまう。
簡単な割には結構な満足感があってお得なので、次は一か月を目標に、できるだけ長く続けていきたい。
ところで、PR の作成とマージでは草が生えるが、その PR にコミットを追加しても草は生えない。若干の罠だった。
32型 4K モニタ生活が当たり前になってきた。
少し前のことになるが、奮発して 4K モニタを買った。給付金と会社の補助でいろいろ揃えた。ありがとう政府と会社。会社はなくなったが…。
余談だが、このとき私は「スピーカーは専らPCに接続するし、仕事中に音楽を聴くことで生産効率が上がる。ゆえにスタジオ用モニタリングスピーカーは規則にあるPCに該当する」と主張して認められた。本当に良い会社だった。
大型モニタにして一番変化したのは、映画がきれいとかゲームがきれいとかそういうことではなかった。そもそも映画は 4K プランなどに入っていないし、ゲームは GPU がボトルネックになって60 fps は維持できないことが多くなったので、むしろ劣化している。
では何が変化したか。それは、画面を分割するという概念が発生したことだ。これまでは開発をするとき、エディタとブラウザは別のモニタに表示していた。しかしこれだと物理的には大型モニタより大きいため、視線移動の距離が首を動かす必要がある程度には大きくなる。
ところで、シングルモニタにしたかというとそうではなく、前首を動かさないと見れない場所ではあるがサブモニタも使っている。ここに Tweet Deck を表示していると、普通に作業している分には目に入らないが、見たくなった時にウインドウを切り替えなくてよい。その分気軽にツイッターができるが、首が微妙な角度になるので長時間見続けることをしなくなった。画面が一つだと、TweedDeckを表示すると30分ながめており、その間にやる気が消滅していることがよくあった。
ところで、4Kにしてからフォントが異常に細く読めないサイトというのが存在することに悩んでいた。テキストエリアで頻発しており、特に goplayground で該当するのが生産性を多いに損なっていた。しばらく我慢していたが、さすがにまずいだろうということで調査してみたところ、font-family が monospace の場合に発生しているようであった。そして、少なくとも Chrome では、monospace のデフォルトが MS Gothic になっていたので、適当なフォントに変更した。
全体としては Twitter がいい感じでできるようになったという内容になってしまったが、これは生産性向上のためには意外と重要なポイントである。Twitter は脳への負荷が小さいので、放っておくと Twitter ばかりみてしまう。ここに、身体的に疲れるという制約をかけられたのは良かったように思う
