Mackerel 個人ダッシュボード使いこなし術

この記事は Mackerel Advent Calendar 2023 の12月1日の記事です。トップバッターいただきます。

お前誰よ

Mackerel チームでエンジニアリングマネージャーをやっている id:onk です。最近は特に OpenTelemetry 対応を進めているチームのそばにいます。

今日の話

個人で Mackerel をどう使っているかの一部をチラ見せします。

まずはこのダッシュボードを見てくれ。

我が家のダッシュボード

リモートワークになってから快適に暮らすために、気温、室温、二酸化炭素濃度、気圧なんかを測って投稿している。二酸化炭素濃度が上がるとアラートを鳴らして換気するなどのアクションを取りたいし、気圧が急激に下がるときは頭痛ーるのようにアラートを投げたい。というわけで Nature Remo や Netatmo を利用して測定しています。

測っている値は 3 年前から特に変わっていないんだけど、その間にダッシュボード側が進化したのでそれぞれ紹介していく。

数値ウィジェットのトレンド表示

僕は数値ウィジェットの隣にグラフを置いて「上がっているか下がっているか」を把握しやすいようにというダッシュボードを作っていたんだけれど、数値ウィジェット単体でも把握しやすくなった。

左右にグラフと数値ウィジェットを並べている例

数値ウィジェット内に「↑」「↓」が表示されるようになったので、グラフと並べずに、数値だけで上昇傾向か下降傾向かを判断し得る。例えばこうして上段に数値ウィジェットだけをまとめて、高さ当たりの情報量を増やすことが可能かもしれない。

数値ウィジェットだけが並んでいる例

この機能は はてなリモートインターンシップ2023 で id:laminne さん id:ucciqun さんが開発してくれました。メンターを担当した id:mds_boy さん id:rmatsuoka さん、機能を提案した id:heleeen さん、デザインした id:issan883 さん、お疲れさまです！

数値ウィジェットのフォーマットルール

ダッシュボードを一目見ただけで健康かどうかを把握したい。二酸化炭素濃度は分かりやすくアラートの基準としているので、そのものズバリで Critical な見た目になるようにしました。

問題がある二酸化炭素濃度だと数値が目立つようになる

ダッシュボードを見たときに「オッ」となるので便利です。業務でもアラートが鳴る -> ダッシュボードを見る -> ヤバいところが目立っている、という体験ができます。

id:azukiazusa さん id:inommm さん id:issan883 さん id:mechairoi さん、機能を提案した id:arthur-1 さん、お疲れさまです！

グラフウィジェットの縦軸固定

気圧のグラフですが、気圧は 990hPa〜1030hPa ぐらいの値を取るため、何も工夫せずにグラフにすると、増減がまったく分からないグラフになります。

この気圧グラフはどういう変化をしているのだろうか

これを避けるために offset(..., -1000) して表示していました。-990 ぐらいにしておかないと台風の日なんかにマイナスになるんですが、グラフの縦軸の数字の分かりやすさを優先してしまった。。

低気圧の日はグラフがマイナスに突き抜ける

グラフ縦軸固定機能が入ったので、offset で頑張らなくても自然に表示できるようになりました。

縦軸の数字も実際の値で良いですね

id:arthur-1 さん id:yohfee さん、お疲れさまです！

実務では、このように足切りしたいようなグラフや、稀にスパイクが起きるようなグラフで使って貰うと良いのかなと思います。上限を遙かに突破されると、しばらく変化が見づらくなるので。

異常値があるせいで他の変化が見づらくなっている例

より直感的なダッシュボードに育てる

このように、カスタムダッシュボードには色んな機能が最近 (今日紹介したのはそれぞれ今年開発されたものです) 増えているので、より直感的に把握できるダッシュボードになるようカスタマイズしてみてください。

Mackerel Advent Calendar 2023、明日 2 日目は id:rmatsuoka さんです。

【PR】Mackerel Meetup #15 Tokyo を2023年12月19日 (火) に開催します

書かなければいけない宣伝。こうした機能を提案、実装した 開発者に会いに行けるサービス である Mackerel は、12/19 (火) に Mackerel Meetup #15 を開催します。

「チームとコミュニティで監視を育てる」をテーマに、監視を育てるスタート地点でもあり、考え方でもある「SRE」の概念やその導入方法、具体的な実装について知ることのできるコンテンツを用意しています。明日から自分たちの監視やシステムを育てるヒントにしていただけたら幸いです。今時点で Mackerel を使っていない方でもぜひご来場ください！

詳細とご応募はこちらから！

mackerelio.connpass.com

ISUCON13 に参加した

いつものメンバーで参加した。このメンバーで組んだのは ISUCON9 からなので、もう 5 年になるのかー

いつメン

東京、京都、シアトルと、全チームの中でも地理的にはかなり離れているチームなんじゃないかな。

今回は僕がインフラ担当。3 人ともどこでも担当できるのは面白いメンバーだと思う。

最終スコアは 39,560 で、https://isucon.net/archives/57993937.html を見る限りは 40 位っぽい。再起動試験を含まないポータルのランクでは 49 位。

準備

素振りは 2023/9/10 (12予選) と 2023-11-04 (11本選) の 2 回やった。本番と同じ形で、8h 一本勝負。どちらもそこそこの点（本選出場チームの真ん中ぐらい）は取れたので、そのぐらいはいけるんじゃないかという感覚。

素振った結果として、僕の時間の使い方は以下で行こうと決めていた。

  • 10:00
    • ベンチ一発流す
  • 10:00-10:30
    • repository 作って各サーバを git clone したものに入れ替える
  • 10:30-11:00
    • 秘伝のタレを撒く
    • alp/pt-query-digest をいつでも誰でも実行できるように
    • 任意のサーバにデプロイできるスクリプトの共有
  • 11:00-11:30
    • INDEX 直したり
  • 11:30-12:00
    • 複数台構成とか
  • 12:00
    • この辺で多少暇になってそうなので何か手伝えそうな気がする
  • 13:00
    • N+1 も潰し終えてきてそろそろ大玉が何か分かってくる？
  • 16:00
    • この辺で最終形の複数台構成にしたい
    • あとは dstat 見ながら調整
  • 17:30
    • ログ消す
    • ベンチガチャ回しつつ祈る

また、EC2 はとりあえず 6 台立てて好きに使えるサーバを増やしておこうという話をした。

  • 最初から複数台構成にしたい
  • 各自のビルド環境だったり確認環境だったりをローカルに整えるのはちょい面倒

という理由。

やったこと

リポジトリは公開している。https://github.com/onk/isucon13

10:00

リポジトリ作って撒く。rust/target 以下が .gitignore されていなくてイラついたけど、ちょっと待ったら git add できたのでそのままコミット

10:30-11:00

入っているミドルウェア等を把握して、いつもの conf を適用。

あとで分かったけど、ここで静的ファイルにキャッシュ入れてたわ。私が戦犯です。

11:15

alp、pt-query-digest 取得

この時点では「icon を静的化しよう」「statistics はどうにかする必要がありそう」「あとは INDEX 張ってから考える」までしか僕は分かってない。

11:25-11:40

INDEX 足すねー、と言って足す。最速でできたと思う。

やったのは ruby/app.rb から SQL っぽいものを抜き出して、眺めながら WHERE 句と ORDER BY 句に入っているものを愚直に index にしただけです。まだアプリは何も読んでないが INDEX だけなら勘でできる。

例えば

SELECT * FROM livecomments WHERE livestream_id = ? ORDER BY created_at DESC

を見たら

alter table livecomments add index livestream_id_and_created_at (livestream_id, created_at desc)

と書く感じ。この作業は機械でできそう。

11:40

pprof 取得して会話

  • icon 静的化
  • tag は redis にキャッシュ

という話をしたはず？

13:00

ADMIN PREPARE が出ないように interpolateParams=true に

12:00-13:15

デプロイ周りの整備したり複数台構成にする準備をしたり

明らかに MySQL が 100% 食っているので、アプリが使うデータストアを分離。

  • s1: nginx, app, powerdns
  • s2: mysql, redis
  • s3: 空き

N+1 倒したら redis 置く隙ぐらいあるだろうと思って適当に。

INDEX 足して 2 台構成になって状況変わったので作戦会議

statistics は redis に sorted set でランキングを持つ、各値も redis に持つ。pt-query-digest も pprof もコレだと言っているので、これはやる。

13:30-16:00

icon 静的化にここまでかかった……。try_files でデフォルトアイコンを出す？ユーザが無いときは 404 にしなきゃいけないんじゃない？みたいなので途中で作戦変更することになった。

結局、初期ユーザは NoImage.jpg を置いておく (initialize でコピーする)、register 時にも NoImage を置く、アイコン変更 (postIconHandler) 時に静的に書き出す、とした。icon はこれで静的に返せるので、あとはまるっと nginx 任せ。

なお If-None-Match の件は僕はマニュアル読んでなくて気づいてない。

16:10

Tag を redis に cache をデプロイ (2h 前に完成していたのでさっさと入れたかったね……)

fillLivestreamResponse の N+1 が潰れる。tags も DB から外して redis にのみ持つようになったはず？

16:20-16:35

pprof に出ていた moderateHandler を潰す。NGWord のループが潰れて、謎の DELETE 文は素直になった。

16:40-17:45

alp に出ていた GET reaction と GET livecomment の N+1 を潰そうとするが解決に時間が掛かる。結局最後に revert。

そしてベンチはひたすら「新たに設定したアイコンが反映されていません」と言ってくる。謎。

17:45

redis 化していた getLivestreamStatisticsHandler を、もうベンチ全然通らないしとエイヤでマージ

18:00

今回 fail で終了だー、と自棄になりつつとにかく enqueue しまくる

18:01

なぜか最終点がベストスコアで出ている

反省

作戦はまぁミスってない、とにかく手が遅い！！！

  • reaction の N+1 の解決こんなに時間掛かってどうすんだ
  • theme や icon hash はさっさと user にカラム追加して一発で取ってきたかった

インフラ的にも酷い感じだった。

  • 結局 3 台構成にできてないのが最悪。N+1 潰しが終わらないのを見に行くとかやっている間に分散しておけば良かった
  • 何気なく入れていた設定の存在を忘れていた。これが今年は一番影響が大きかったね……

あと isudns にインデックス張ってないのを眺めに行ったにも関わらず見逃したのも酷かった。追試した感じこれは大差なかったですが。

2 人で 1 つをやらずに別の N+1 を潰しに行っていたら多分あと 2-3 手はやれたなーと思っていて、30 位は普通に行けましたね。。 matsuu/aws-isucon で追試したら 2 台構成のままでも N+1 2 つ潰しただけで 50,000 点が出たので本当にアプリ側書く手の早さだなーと思う。そして nginx の config は本当にベンチの不安定さに繋がっていたので戦犯。

まったくベンチ通らない様子

よく最終点出たよね。運が良すぎると思う。

反省の残る回だった。来年また来ます。

1 年ぶりに本番に出た感想としては、練習ではベンチを任意のサーバに対して流し放題なのに対して本番では制限があるので、ベンチを流す回数が圧倒的に少なくなるなと思いました。開発のリズムがまったく違うので、本番相当で練習した方がヨサソウです。

matsuu/aws-isucon で複数台で試したい方向け

ベンチを流す前に、

  • env.sh で ISUCON13_POWERDNS_SUBDOMAIN_ADDRESS を ベンチ対象の IP アドレス に向ける
  • ./webapp/pdns/init_zone.sh して *.u.isucon.local を ベンチ対象の IP アドレス に向ける

で、ベンチ実行は

$ ./bench run --enable-ssl --nameserver ベンチ対象のIPアドレス --webapp ベンチ対象のIPアドレス

です。

Ruby/Rails の勉強に何読んだらいいかと聞かれたとき

「次の職場が Ruby なんだけど」と読み書きそろばんを聞かれたのと、大阪Ruby会議03、大江戸Ruby会議10、Kaigi on Rails 2023 と Ruby/Rails 関係のイベントに続けて参加して、作者の皆さまと会ったので。

「読める」になるために

言語仕様は何らかの本 1 冊の冒頭の方を読めば雰囲気は掴めるだろう。

Ginza Rails27 igaiga - Speaker Deck

著書や技術顧問、健康診断レポート でお馴染みの @igaiga555 さんの作った表で、難易度別にまとまっている。

たのしいRuby か、プロを目指す人のためのRuby入門 が定番かなぁ。

できることを知る

は読んでいて面白いのでオススメです。まずはサラッと目を通す感じ。

なんか書く

Rails で何かアプリを作る。まず 1 個ぐらいは手を動かしておきたいね。

作るものが思いつかなかったら、Rails Girls のガイドを見ながら画像アップロード機能のある Web アプリを作ったり、Rails チュートリアル をやったりすると良いんじゃないか。

チュートリアルは長いので、サクッと rails new してナルホドと言えるぐらいのサイズで良い。

ライブラリを知っていく

「何か gem があるんじゃないかと疑う」を基本行動としながらしばらく暮らす。

The Ruby Toolbox は昔からあるサイトなので、かなり古いメンテされていない (2010 ぐらいが最終更新の) ライブラリも載っている。古いのは見なかったことにしつつ、一番有名なのを触ると良いです。基本的に困るまでは有名どころしか使わなくても生きていける。

awesome-ruby はいつもの awesome- シリーズです。ちゃんとメンテされている（感謝）

アプリを作ったら dependabot や renovate でバージョンアップの指示があるたびに中を読みながら上げていくのも良いですね。現在進行形で開発されている現場の空気が分かっていくので。

Real World Rails にある各アプリの Gemfile を読むのも効いてきます。これも世界の現場感が身に付いていく。

こういう「gem を読む」を自然にやるためには、gem-src と ghq を入れておくのがオススメです。自分のアプリと gem との距離感がどんどん減っていって「読むのがふつう」になっていきます。

実践的な開発に参加する

Enumerable や ActiveSupport の core/ext でできることを知って、代表的な gem が分かっていたら、ほぼコードの読み書きする分には困らなくなっていると思う。

  • テスト
  • API サーバ
  • パフォーマンスチューニング
  • CI/CD

辺りが次の話題かな。

まさに Kaigi on Rails はこういった話題を取り扱っているのでぜひ見て欲しい。

他は

とかになるんじゃないか。

手当たり次第に読む

あとは技術的な興味をどこまで持ち続けられるかみたいな勝負になる。新しい話題が次々飛び込んでくるように自分のアンテナをしっかり張っておきましょう。

という感じ。ではでは ruby-jp や各地域 Ruby コミュニティ、カンファレンス等でお会いしましょうﾉｼ

作業者じゃなく開発者でありたい

自分がこうありたいというメモ。

作業者と開発者の違いとして、問題解決への寄与だとか、創意工夫の余地があるかというのがありそう。

これは今 GPT-4 に聞いた。

Q: 作業者と開発者の違いを100文字ぐらいで教えて。

A: 作業者は指定されたタスクや手順を実行する人を指し、特定のルーチンや手順に従って作業を進めることが主な役割です。一方、開発者は新しい製品やソフトウェアを設計・構築する人を指し、創造性や技術的なスキルが求められます。作業者は指示に従い行動し、開発者は新しいアイディアや解決策を生み出します。

単なるタスクの遂行でなはく、より多くの責任とリーダーシップを求めている

  • コードを書くだけではなく、問題解決や創意工夫の余地が多くあるタスクが欲しい
  • 自分のアイディアをベースとして、形にすることで、プロジェクトを完遂したい

そもそも何が問題なのかを明らかにするだとか、最適な解決策を見つけるのが、仕事をしていて一番面白いところだと僕は思っている。

仕事の定義を

理想の状態になることを阻害している問題を見つけて，
問題を解決する手段を考え，解決すること

と 以前書いたことがある。

機能やサービスを開発する過程で出てくる課題を、よりクリエイティブに解決するのは、全能感が出て気持ちいい。

新しいアイディアやアプローチを考えて実際のプロジェクトに取り入れていくのも、テクノロジーやテクニックの進歩によってより良い状態に辿り着いていると思う。

常に新しい方法を模索する姿勢は、成長や、自己実現の欲求に効く。自分のアイディアを形にする体験、形にしたものに対してユーザーからフィードバックを受ける体験が、僕らがプログラマになった原体験だろう。

組織の目標達成への強い関与

  • より広い視野で物事を考え、計画をする体験を得たい
  • 複雑な状況を解きほぐして解決する経験をもっと積みたい

中腹じゃなく頂上に立てってヤツかなぁ。

広い視野があると、各タスクや機能がどう全体と連動しているのかを理解できる。理解から、より価値に対して効率的な進め方を模索できる。自分のタスクだけでなく他のメンバーの作業状況も見えるので、全体の流れをスムーズにすることを考えられる。戦略ゲームのプレイヤーの位置で日々暮らしたいという欲求と思う。

複雑な状況というのは、クネビンフレームワークで言うところの複雑《Complex》。問題が何なのかが明らかになっていない状態。現代のソフトウェア開発は概ねこの状態からスタートすると考えている。(Chaotic な状態だとタスクフォース的に急いで何かを手を打つだろう、Complicated な状態はもうやるだけになっている (やるだけ距離 がまだ遠いことはある) ので、マネージではなくコントロールして着地に向かうプロジェクトだろう)

何をやるのかを明らかにして、やるだけな状態に持って行くには、分かったことを積み重ねて、仮説を立て、対策していくというアプローチが効く。つまり OODA ループ。観測して (observe)、方向付けて (orient) 、意思決定し (decide)、実行する (act)。実験や試行錯誤を通じて何が効果的であるかを見つける楽しさがここにある。

やるだけになっているものを進めるのでも十分難しいとは思うが、誰も明らかにできていなかった問題に対して自分が輪郭を削り出すことに成功するのは最高に気持ちいい。モデル化に成功すると人類の叡智が一歩前に進んだ気持ちになる。同じ問題には同じ対策が効く。

組織目標はだいたい複雑な状況であるので、複雑な状況を任せられるようになると関与度が上がっていく。

全体設計の楽しさ

  • アーキテクトとして、システム、「系」を構築する
  • プロジェクトマネージャーとして、実行計画を立てる

抽象的な要件を具体的なシステム設計や実行計画に変換するのは、とてもクリエイティブな楽しさがある。また、この過程で新しい技術やツール、プロセスを取り入れる機会をねじ込み、自分やチームの経験領域を広げることができる。

目標や成果物を明らかにし、それを達成するための戦略やアプローチを定義するプロセスは、戦略的な思考を活かすことができ、自己効力感がある。

まとめ

単なるメモなのでまとめも何もないが。

仕事をする上で、何らかのクリエイティブな取り組みがなかったらつまらないと思う。僕はこういう仕事をやりたいし、みんながこういう仕事をやれる (ように経験資源を配れる) 状態だといいなと思っています。

このエントリは HatenaBlog Workflows Boilerplate を用いて GitHub から publish しました。push したら公開されるのは個人でも便利。

手を動かさないマネージャーを試している

2 月から、Mackerel チームの所属になった。

これを期に、せっかくなのでコードを読まないマネジメントスタイルを試してみようと思って、実践している。

今までは自分が一番プロダクトのコードベースに詳しい状態を作ってきていて、障害対応でも嬉々として先頭に立つようなテックリードスタイルだった。

この姿が天職と思っているが、今までの人生で、コードの細かい話が通じない (というか、共通言語や会話のレイヤーが違う) けれども非常に信頼できるマネージャーと仕事をしてきた経験はあるので、自分も彼らのようなムーブが可能なんだろうかとやってみたくなったのだ。知識欲が減衰した老害化現象ではないと思う。きっと、たぶん。

もう半年以上業務ではコードを触っていないが、ISUCON に負けたとき用の言い訳を用意しているわけではない。今年の ISUCON 13 はチーム No.117 で参加します。勝ちに行くぞ！

「掌握する」をやる

さて、異動にあたって、観察と干渉のバランス を意識しようと考えた。

僕の言葉ではこれは「掌握する」となる。

dictionary.goo.ne.jp

［名］(スル)《手ににぎる意》自分の思いどおりにすること。全面的に自分の支配下に置くこと。「政権を―する」「部下を―する」

※一応書いておくけど、以下は個人の感性に基づく感想です

「把握」は「独力で説明できる」状態を指している。観察の結果として割と早期に獲得できる状態だが、あくまで説明できるだけで、有事に判断を下すことは「把握」だけだと難しい。

一方「掌握」は「変えようと思ったら変えられる」状態を指している。（こういう状態を (control と対比した) 《manage》と言うんじゃないか、というのは 以前書いた）

掌握するとは、どこを変えたらどこにどんな影響が出るかの検討が概ね終わっている状態を指している。この「意のままにできる」感を表現したくて、「掌握」という言葉を使っている。

というわけで

  • どこに変更を入れると、どんな風に波紋が広がるかを、自分の言葉で言えるようになっている
  • 変更を入れようとしたときに大きな反発が起きない

というのが目指す姿だった。

なお「この音とまれ！ ＃118」の「掌握する」のシーンは最高に痺れるからぜひ読んで欲しい。単行本では 28 巻に収録されています。

初動の失敗

異動後に、以前のチームにも引き続き同じように顔を出す、というのをやっていた。どうせ当面のアクションは「観察」なので、言うて社内異動だしある程度知っていることもあるだろうから、片手間っぽくても成立すると油断していたのだ。

実際には片手間ではまったく無理で、1ヶ月経った時点で何も判断できるようになっていない自分に気がついて、ようやく焦って動きを変えた。

具体的には

  • Slack のチャンネルの並び順を変えて、自チームのチャンネルのみを一等地に置き、他のチャンネルは視界に入りづらいように押し込める
  • デイリースクラムの司会を貰う
  • 既存の Issue をとにかく読む

をやった。あと意識的に旧チームから離れた。

この結果、何も進捗しなかった1ヶ月とは打って変わって急速に「掌握」に辿り着けたんじゃないかと思う。

各リーダーからのヒアリングや 1on1 さえやっていたら片手間で辿り着けると思っていたが、思っていた以上に無理で、これは自分でもビックリした。

僕は自分の意識の大半を向けないと、想像を膨らませる遊びができなくて無能になるっぽい。想像を膨らませるというのは、どうやら、仮にこの仕事を〜〜がやったとしたら上手くいくか、チームをこう分割すると認知負荷が減るか、リーダーを誰に任せると覚醒し得るか、という思考実験を脳内で無限に繰り広げている、らしい。最近気づいた。

オチはない

コードを読まないマネジメントスタイルを試してみているが、果たしてできているのか、このスタイルが良いのか悪いのかはまったく判断できていない。

自分の感覚としては、コードを読んでいたときとそんなに全能感は変わっていない。各サブシステムの関係性のみの把握でなんとなく運用を理解することはできているし、判断する際にもどちらが正しそうかを選べているんじゃないかと思う。が、根拠の幾つかが伝聞に変わっているので、危うさはありそうな気がする。

コードを読んでいたときは、コードベース上に表現されるアーキテクチャに対して想像を膨らませて遊んでいた。現在はチーム上に表現されるアーキテクチャに対して想像を膨らませて遊んでいそう。変化させる対象がコードベースからチームに変わっているかもしれない。

似たような話が Hatena Engineer Seminar #26 「エンジニアリングマネージャー編」 でもありましたね。

手を動かさないスタイルを試し過ぎた結果、戻れなくなることがあるのかどうかもまだ判断できない。なんとなく、丸 3 年ぐらいなら戻って来られそうな感覚はある。

特にオチはない。

株式会社はてなでは、マネージャーをとてもとても募集しています。

サブカル業界Developers 勉強会 Vol.5 で Cache Stampede の話をした #subcul_dev

登壇

サブカル業界Developers 勉強会 Vol.5 (オンライン/オフライン同時開催!!) - connpass

前日に急に寝台特急の存在を思い出したので、サンライズ出雲で上京した。寝台車は寝てたら勝手に着くので便利だなぁ。強制的に 7 時から活動させられるので朝活しやすいのもポジ。

登壇枠

Cache Stampede (検索用ワード: Thundering Herd) という話をした。

Cache Stampede 対策のうち 3 案は以下のスライドから貰ってきた。

www.slideshare.net

ZOZO さんも同じ分類で話をしていましたね。

techblog.zozo.com

4 案目とした SWR も 6-7 年前から定番かなー。

＼キャッシュと上手に付き合おう!!／

パネルディスカッション

主に「サブカル企業のスタッフはオタクなのか」というお題で 5 社でパネルディスカッションしました。

パネルは「toB v.s. toC」という枠に当てはめようというモデレータの力が働いていた気がする。これはプロダクトにはかなり影響するが、社内文化は違いを感じないなというのが自分の感想だった。

実際、熱量を持っている開発者と意思決定者との距離は、施策選びにとても影響がある。そこで距離の近い共同開発を行える関係性、任せて貰える信頼関係を作るのに腐心している。

一方で、社内文化については、オープニングでも触れられたが、雀魂 夏の企業対抗戦 2023 が特徴的で面白かったなと思う。パネル登壇 5 社中 3 社が出場している。

こういうイベントにどんどん参加できる環境とか、およそどんな話題でも食いついてくる人がいる社内 Slack とかは福利厚生だろう。

懇親会

前回に引き続き、オフライン懇親会も開催した。オフライン懇親会は新しい人との繋がりを作りやすいのが本当に便利で、知り合いと知らない人とが親しそうに話をしているところに「どんな繋がりなんですか」を携えて入っていくと、どんどん繋がっていく。これを繰り返して顔なじみを増やしてきたんだよなぁ、と再認識した。

一方で、はてなからも 2 人参加していたけどあまり引率できなかったのは失敗だった。懲りずにまた来てください。次は紹介して回ります。

サブカル業界 Developers は引き続き開催していくつもりなので、connpass で Join Group して新着イベントを拾える状態にしておいてください。

git revert 時は理由を入れよう

コミットを何らかの理由で取り消したいときに git revert を使う。

git revert -m1 MERGE_COMMIT したときは

Revert "Merge pull request #1 from onk/repo"

This reverts commit 35b7e7c517c438b805d442ff45242334bb91eda5, reversing
changes made to 07989ab9643e204a0d26a19152c5ace2657cf421.

という commit になる。

GitHub だと UI 上からも revert できて、そのときは以下のようになる。

Pull Request を revert する画面。本文は「Reverts onk/repo#1」
「revert」ボタンを押すと revert PR を作成する

どちらも、このまま進めることはできてしまうが、「revert した」という事実だけしか残っていない。なぜ revert する羽目になっているのかという Why がどこにもない。これは後世でとても困るのです。

revert commit のコミットメッセージもしくは revert PR の description に、理由を入れて欲しい。

「... の考慮が漏れていて動作確認時に ... というエラーが出たため」とか。Slack のリンクだけでもいいです。

理由が全員の記憶から揮発してしまったら「前回 revert した記憶があるが、当時ダメだった理由って潰せてるんだっけ？」という質問に答えられず、不安の中で次のリリースをすることになるからです。