ちなみに

火曜日の空は僕を押しつぶした。

たくさんシーケン図の画像が欲しい

画像

最近は図を描くのに Excalidraw を使うことが多いのだけれど、シーケンス図は Mermaid が楽。 しかし、書いた図を画像にするのをどうするのかちょっと悩む。

mermaid-cli を使って Markdown を変換するのが楽だったので、今後はこれでやっていきたい。

こういう感じで複数のシーケンス図を Mermaid で書いて、

# A
```mermaid
sequenceDiagram
    A->>B
    B->>A
```

# B
```mermaid
sequenceDiagram
    A->>B
    B->>C
    C->>A
```

mermaid-cli で以下のようにやると out.md はシーケンス図の部分が画像に差し替えられて出力される。

$ mmdc -i in.md -o out.md -e png

画像に差し替えられたということは画像が生成されているということで、同じディレクトリに出力の Markdown と同じプレフィクスの画像が連番で生成されている。

$ ls -l
in.md
out.md
out1.png
out2.png

Markdown は捨ててしまってこの画像だけを使っている。

GhosttyでSSHした先でBackspaceなどが入力できない

技術

仕事始めということで年末に移行した Ghostty からSSHしたら制御シーケンスが入力できなかった。

調べたら TERM に xterm-ghostty が設定されていて、これが接続先の terminfo に登録されていないことが問題だった。

ghostty.org

公式にドキュメントがあるのでこれに従って設定することで解決した。

Host *
  SetEnv TERM=xterm-256color

管理権限もってないので今回は SSH の設定に SetEnv した。上は雑な例。

2025年の目標と2024年のふりかえり

2025年の目標

  • 全力で楽しむ
    • 去年はあんまり仕事を楽しめなかったという反省がある
    • 自分の生き方の原点に戻って私生活も仕事も思い切り楽しみたい

2024年のふりかえり

blog.nishimu.land

  • 捨てる
    • 物
      • 1年を通すと、物を買うことはかなり抑制できたが、捨てるのはさほど出来ていなかった
      • 後半で引っ越すのにあたって、いろいろ捨てられたので、まあ達成と言えそう
      • キーボード関連はどうしようかな...
    • 知識
      • これまでのやり方にこだわるのは捨てられていた気がする
      • 良い意味でも悪い意味でこだわりが減ってきている
  • 俯瞰する
    • 短いスパンではもっといい方法はたくさんあったと思う
      • 年初からめちゃくちゃイライラしていて短慮なことが多かった
      • なんかもっと穏やかなやり方があったと思う
    • 長いスパンでは今後の人生を俯瞰していくつか決断出来たと思う
      • 持ち家を買った
        • 別府に引っ越しきっかけが京都の家が高すぎたことだったのでこちらでもやんわり家を探していた
        • 偶然にめちゃくちゃいいところを見つけて購入に至った
        • たぶんこれ以上は望めないくらい良い物件で、前のオーナーさんもすごくいい人だった
      • 転職することにした (3月から)
        • 学生時代から付き合いがあって一緒に働きたいと思っていた友達と働けることになった
        • ずっと自分の実力に自信がなくて一緒に働くと失望されるのではとう恐怖があった
        • けど、たぶんカオスな環境で挑戦できるチャンスもだんだん減ってくるだろうし思いきって挑戦することに決めた
        • やるからには思い切り楽しみたい

家は最高

「Tidy First?」を読んだ

読書 技術

www.oreilly.com

Kent Beck 御大による、ソフトウェア設計に関する書籍シリーズの第一弾である「Tidy First?」を読みました。

この本では開発中に散らかってしまうコードをいかに片付けて、読みやすい状態を保つかについて説明されます。 ソフトウェアの設計は人間関係のエクササイズだとし、シリーズ第一弾である本書ではまずは一人で行える範囲の話題を扱います。

リファクタリングのサブセットとして、誰もが気に入って反対する人もいないくらいの小規模の改善と "Tidying" として定義して、代表的な Tidying のカタログと、その適用方法、そこから踏み込んで理論的な解説が続きます。

Tidying

どうして Tidying が必要になったかと言うと、御大は以下のように最近の「リファクタリング」という言葉の使われ方を嘆いている。

“Refactoring” took fatal damage when folks started using it to refer to long pauses in feature development. They even eliminated the “that don’t change behavior” clause, so “refactoring” could easily break the system.

「リファクタリング」は、機能開発を長期間止めることを指す言葉として使われるようになって致命的なダメージを受けてしまった。彼らは「振る舞いを変更しない」という条項さえ削除してしまってので、「リファクタリング」によって容易にシステムが破壊されるようになたのだ。

どうしてコードが散らかっていると駄目なのだろうか。

本書ではソフトウェアを変更するコストを、コードを理解するコストとニアリーイコールであるとしている。 コードが散らかっているとコードを理解するコストが上がり、結果的に開発速度も落ちてしまう。

つまり Tidying をしてコードが理解しやすくなると、将来的な変更のコストも下がって、選択肢が増えるということである。

Managing

コードの変更を「振る舞いの変更」と「構造の変更」に分けて解説している。「振る舞いの変更」は直接的な価値を生むが、「構造の変更」は間接的な価値しか生まない。

「構造の変更」= たとえば Tidying が価値を生むケースは cost(change) > cost(change + tidying) ということになる。 この式から分かる通り、Tidying によって理解しやすくなったコードを変更することによって、何もせずに変更する場合よりコストが下がる場合だけ適用すべきということになる。

つまり、Tidying は「振る舞いの変更」より長い時間をかけて行うべきではないことが分かる。

ではいつ Tidying をするべきかについても書かれている。コードを変更する前に行うのか、すぐ後に行うのか、ずっと後に行うのか、やらないのか。 これまで説明したとおり、変更のコストが下がるのであれば先にやるべきではある。ただし、どうやるべきかがはっきり見えてなかったりすると後でやった方がいいケースもある。 忙しくて時間がない場合もあるだろう。そういうときは Fun List (= Tidying は楽しいのでTODOリストではない) に書いておいてあとでやるということも可能である。 また、そのコードを二度と触らないのであれば、コードが散らかっていても問題はないと言えるので、やらない方がよい場合もある。

blog.nishimu.land

いつやるかというのは以前から僕も気になっていたテーマだったので、答え合わせのような内容でとても良かった。

他にも面白かったのが、レビューのコストについての話で、レビューのコストもチリツモで影響が出てくるので、Tidying による「構造の変更」についてはレビューするべきではないという書かれている。 逆にいうとレビューが必要なくらい複雑な変更は Tidying ではないということでもある。 ただし、これを実際にやるのはかなり勇気がいるので実践はできていない。

Theory

このパートはおもしろくて経済とソフトウェア開発について書かれている。 「ディスカウントキャッシュフロー」と「オプション取引」についてをソフトウェア設計に当てはめて解説されている。

「ディスカウントキャッシュフロー」は未来の価値より今の価値の方が高い。 つまり早く手に入れて、支払を出来るだけ遅らせる方が得という話で、これをソフトウェア開発に置き換えると、出来るだけ早く機能開発をすることで、顧客に届ける価値が高まるということになる。(=開発者は収益を得られる) 開発の初期段階はまだ何の価値も得られていないので、特にこの傾向が強まることで、直接的に価値を生む「振る舞いの変更」を優先してしまいがちである。

「オプション取引」は将来購入する権利を買う取引で、例えば「一週間以内に10,000円で株券を買う権利」を買ったとすると、株の値段が10,000円を超えたらお得だし、下回ると損になる。 ちなみにこれは「買う権利」でしかないので放棄することも出来るのがみそである。 これをソフトウェア開発に適用すると「構造の変更」を行うモチベーションになるという話である。 つまりコストを払って「構造の変更」を行うことで、将来の変更しやすさが高まり、システムとしての選択肢が増やせるので、その時に手に入る価値が妥当だと思うならコストを払うべきと言える。

ところで本書ではソフトウェア開発全体のコストを以下のように定義している。

cost(software) ≒ cost(change) ≒ cost(big change) ≒ coupling

つまり変更のうち大きな変更のコストが支配的で、そのコストは「結合」からきていると言うのだ。

「結合」しているとは「同時に変更する必要がある」ということであり、「結合度」が高いと同時に変更する箇所が増えてしまうので、変更のコストも上がるということである。 それではとにかく「疎結合」にすればいいかというとそうでもなくて、結合度が0のソフトウェアは存在しないし、結合度を下げるにもコストがかかるのである。 ここら辺は「要はバランスおじさん」が登場している。

Conclusion

最後に一番好きな一文を紹介して終わります。

The world is challenging enough that we can’t afford to ignore opportunities to make things easier for ourselves and others.

この世界は過酷なので、物事を簡単にする機会を逃すわけにはいかない

もうすぐ日本語版も出るみたいなのでとっ散らかったコードをなんとかしたいと思っている人はぜひ。

Tidy First? ―個人で実践する経験主義的ソフトウェア設計

Tidy First? ―個人で実践する経験主義的ソフトウェア設計

Amazon

また、第二弾の「Tidy Together?」も執筆中なので楽しみです。

tidyfirst.substack.com

TSVファイルをCLIでテーブル表示する

なんかあるやろと思ったら macOS にも標準で入っている column コマンドで十分だった。 miller とかを眺めていたが高機能すぎて持て余したのでこれで良かった。

これが、

$ cat service.tsv
Twitter X
G Suite Google Workspace
Office 365 Microsoft 365
HipChat Stride

こうなる。

$ cat service.tsv | column -t -s $'\t'
Twitter     X
G Suite     Google Workspace
Office 365  Microsoft 365
HipChat     Stride

ポイントは $'\t でまったく知らなかったのだけれど対応しているシェルだと $'<エスケープシーケンス>' と書くとエスケープシーケンスを解釈した結果に置き換えてくれるらしい。(see also)

最終的にやりたかったのは gh の結果をシュッとテーブル形式で表示するので以下のような感じで扱えて見栄えがよくなった。(スクショ参照)

$ gh pr list --json 'number,author,title,headRefName' -q '.[] | [ "#" + (.number | tostring), "@" + .author.login, .title, .headRefName] | @tsv' | column -t -s $'\t'

ちなみにこれだとデフォルトの表示の方が綺麗なのであくまでサンプルです。

tigでfixupを簡単にする

技術

2つ以上前のコミットを修正したいときに --fixup を使うのは近年ではよく知られている。

$ git commit --fixup <commit>
$ git -i --autosquash <commit>~ # rebase.autosquash = true にしておけばオプションは不要

しかし、この方法だと毎回 $EDITOR が開いてしまいちょっと面倒である。

これを回避する方法は GIT_SEQUENCE_EDITOR 環境変数を使う方法で GIT_SEQUENCE_EDITOR=true などとしておくと、エディタを開かずに rebase が完了する。

また git 2.44 以降は --interactive じゃなくても --autosquash が可能になったためさらに簡単になった (GitHubのブログが詳しい)

これを使うと以下のような alias を定義することができる。

fixup = "!f() { git commit --fixup \"$1\"; git rebase --autosquash --autostash \"$1\"~; }; f"

--autostash は自動で stash してくれるオプションで、他の変更があるときに先に fixup したいときにべんり。 残念ながら rebase.autosquash は interactive mode にしか有効でないので、オプションの指定は必須。

ここまでくると目的のファイルを stage に index しておいて、git fixup <commit> とするだけでコミットの修正が完了するようになる。

しかし、この commit hash をコピペするのも面倒になってきたので、今回 tig の設定に以下のような bind を追加した。

bind main F @git fixup %(commit)
bind log F @git fixup %(commit)
bind diff F @git fixup %(commit)

これで tig の main view などで目的のコミットにカーソルを合わせて F って押すだけになってめちゃくちゃ楽になった。