blog.kyu08.com

『プログラミング言語C 第2版』を読んだ

Sun, 12 Apr 2026 17:48:08 +0900

Operating Systems: Three Easy Pieces(以下、OSTEP)に取り組むにあたって、C言語の知識があるとスムーズそうだったので読んだ。

プログラミング言語C - 共立出版

Brian W.カーニハン著

https://www.kyoritsu-pub.co.jp/book/b10011596.html

Cに関してはCS50で基本的な文法を学んだ程度であまり体系的には学んでいなかったので、CS50の内容を補完するような感じで読んだ。

CS50.jpでCSに入門した

CS50.jpの気になっていたトピックを学んでみたので振り返っておく。 CS50.jpとは CS50.jpの説明はサイトから引用する。このページ

https://blog.kyu08.com/posts/cs50-jp/

どんな本か

C言語の開発者であるB.W.カーニハンとD.M.リッチーによるC言語の解説書。

1989/06/15発売と、約40年前の本だが入門書としての評価が未だに高いようだったので買ってみた。(結果的にも普通に勉強になったので良かった)

二人のイニシャルをとってK&Rと呼ばれることもあるらしい。

ちなみに、

1.1 Getting Started に、例として掲載されている"hello, world"プログラムは、あらゆる「プログラミングの最初の例題」として定番となった。

https://ja.wikipedia.org/wiki/%E3%83%97%E3%83%AD%E3%82%B0%E3%83%A9%E3%83%9F%E3%83%B3%E3%82%B0%E8%A8%80%E8%AA%9EC

とあるように、hello, worldの生みの親としても有名らしい。（！）

各章に演習問題が豊富に用意されているので手を動かしながら学びやすかった。

また、付録を除くと231ページと比較的コンパクトなので、Cの全体像をざっと把握するのにちょうどいいボリューム感だった。

読み方

1,2章は演習問題をやりつつ読み、他の章は演習問題をスキップして本文だけ読んだ。
- Cを完全理解したり人に教えられるレベルになりたい、というよりはOSTEPでの実装がスムーズになれば嬉しいなーくらいの温度感だったのと、手を動かすのはOSTEPでできそうだったので知らない文法や仕組みを軽く頭に入れておくくらいの感じで読んだ。
#includeなしでboolが使えると多少楽そうだったのでC23で動かした。
- 演習問題を解いた実装はこちら。

sunaba/c/k_and_r at d15fb4fa20d3e478cc0f5ac6f9e89e7d0c668b21 · kyu08/sunaba

Personal sandbox. Contribute to kyu08/sunaba development by creating an account on GitHub.

https://github.com/kyu08/sunaba/tree/d15fb4fa20d3e478cc0f5ac6f9e89e7d0c668b21/c/k_and_r

学び

変数、関数の可視性の制御方法(static、extern)
#includeの機能("foo.h"と<foo.h>の違いなど)
aが配列のときa[i]と*(a + i)は同じ
共用体
- 結構使うのが難しそうなので相当パフォーマンスを重視したいときにしか使わないかも…?
関数ポインタ
マクロの基礎
etc.

まとめ

(すべての演習問題をやったわけではないのもあって)1週間ちょっとでCについて一通り簡単に学べて、ちょうどいいボリューム感だった。

ということでOSTEPに取り組む準備ができたので次は実際に着手していこうと思う。

『ネットワークはなぜつながるのか』を読んだ

Sat, 04 Apr 2026 16:45:52 +0900

ネットワークはなぜつながるのか第2版を読んだので感想などをまとめる。

どんな本か

ブラウザにURLを入力してからサーバーから返ってきたレスポンスをブラウザで表示するまでの間に起きることを順を追って説明してくれる本。

章の構成は以下。

Chapter Number	Title	Summary
第1章	Webブラウザがメッセージを作る―ブラウザ内部を探検	ブラウザにURLを入力してからブラウザがIPアドレスを解決し、HTTPメッセージを作成してプロトコルスタックに渡すまでに行うこと
第2章	TCP/IPのデータを電気信号にして送る―プロトコル・スタックとLANアダプタを探検	ブラウザから依頼を受けたプロトコルスタックがソケットを作成してから通信を終えてソケットを抹消するまでの流れ
第3章	ケーブルの先はLAN機器だった―ハブとスイッチ、ルーターを探検	LANケーブルへと送り出されたパケットがリピータハブ、スイッチングハブ、ルーターなどの機器を経由してインターネットに向かって進んでいく流れ
第4章	アクセス回線を通ってインターネットの内部へ―アクセス回線とプロバイダを探検	パケットがインターネット接続用ルーターを経由してインターネットの中に入って進んでいく様子
第5章	サーバー側のLANには何がある	サーバー側のPOPに入ったパケットがサーバーの手前にあるファイアウォール、キャッシュサーバー、負荷分散装置などを通過する様子
第6章	Webサーバーに到着し、応答データがWebブラウザに戻る―わずか数秒の「長い旅」の終わり	サーバーがリクエストを受信してからクライアント側のブラウザが結果を表示するまでの流れ

特に第1章 ~ 第3章の内容が普段のWeb開発と関わりが大きいかつ自分の知識が浅い領域だったのでとても面白かった。

なぜ読んだか

そもそも自分はコンピューターサイエンスをこれまで(大学などで)体系的に学んできていないのもあり、以下の目的でコンピューターサイエンスの勉強を隙間時間に進めている。

ソフトウェアエンジニアリング文脈の問題解決やスキル獲得の速度を上げたい
知的好奇心を満たしたい

去年はコンピュータシステムの理論と実装を読んでコンピューターについて広く浅く理解することができたので次はネットワーク周りを強化しようと思い、読んでみた。(他にはセキュリティ、データ構造とアルゴリズム、データベース、プロトコルスタック、シェルなどが気になっている)

『コンピュータシステムの理論と実装第2版』を読んだ

『コンピュータシステムの理論と実装第2版』を読んだので感想を書く。割と長いので得られた学びだけ読みたい方は## 学び、得た経験までジャンプして

https://blog.kyu08.com/posts/nand2tetris/

学びや気付き

「ブラウザにURLを打ち込んでエンターキーを押すと何が起こるか」という質問に暗記ではなく理解をもとに答えられるようになった。(はず) 特に以下に関しては今までより詳しく理解できた。

ブラウザが何をしているか
DNSが何をしているか
TCP接続においてプロトコルスタックが何をしているか
IPが何をしているか
イーサネットとは何か
インターネットとは何か

ネットワークの基礎を学んだことで今後の問題解決や技術理解の助けにもなってくれそう。

それぞれ現時点での自分の理解を書いてみる。

1. ブラウザが何をしているか

FQDNをもとにDNSにIPアドレスを問い合わせて解決する
HTTPリクエストを作成する
ソケットを作成する
プロトコルスタックにTCPコネクションの確立を依頼する
プロトコルスタックにリクエストの送信を依頼する
通信が終わったらソケットを抹消する

どんなシステムコールを呼ぶ必要があるのか気になったのでCで簡単なHTTP Clientを書いてみた。

sunaba/network/how_networks_work/myhttpclient-c/main.c at ea1ba354678e5c1616ea13a62ddcdb04ed34859f · kyu08/sunaba

Personal sandbox. Contribute to kyu08/sunaba development by creating an account on GitHub.

https://github.com/kyu08/sunaba/blob/ea1ba354678e5c1616ea13a62ddcdb04ed34859f/network/how_networks_work/myhttpclient-c/main.c

今回自分が実装したHTTP Clientでは以下のような流れでシステムコールや関数が呼ばれる。

getaddrinfo(3) を使ってドメイン名に合致するIPアドレス(の配列)を取得
socket(2)でソケットを作成しソケットへのファイルディスクリプタを取得する
connect(2)サーバーへの接続を確立する
2.で取得したファイルディスクリプタに対してwrite(2) でリクエストを書き込む
read(2) でレスポンスを読み込む
サーバー側がソケットをクローズしたらクライアント側でもclose(2)を使ってソケットをクローズする

なお、実装はgetaddrinfo(3)のEXAMPLESを参考にしたらほとんど完成してしまった。

getaddrinfo(3) - Linux manual page

https://man7.org/linux/man-pages/man3/getaddrinfo.3.html#EXAMPLES

比較のためにGoでもsyscallパッケージを使って書いてみた。

sunaba/network/how_networks_work/myhttpclient-go/main.go at ea1ba354678e5c1616ea13a62ddcdb04ed34859f · kyu08/sunaba

Personal sandbox. Contribute to kyu08/sunaba development by creating an account on GitHub.

https://github.com/kyu08/sunaba/blob/ea1ba354678e5c1616ea13a62ddcdb04ed34859f/network/how_networks_work/myhttpclient-go/main.go#L1

2. DNSが何をしているか

DNSサーバーに格納されているデータ

DNSサーバーには以下のようなデータが格納されている。

名前
- サーバーやメール配送先の名前
クラス
- 常にINが格納される。
- DNSができた当初はインターネット以外のネットワークでも利用も検討されていたが、現在はインターネット以外のネットワークが消滅したのでINしか入らない。
タイプ
- 名前にどのようなタイプの情報が対応付けられているかを表現した値。
- 具体例
  - A
    - IPアドレス(AddressのAらしい)
  - MX
    - メール配送先
  - CNAME
    - 名前にエイリアスを設定する

以下はDNSレコードの例。

名前	クラス	タイプ	クライアントに返答する項目
example.com	IN	A	192.0.2.226
example.test	IN	MX	10 mail.example.test
mail.example.test	IN	A	192.0.2.227

世界中のDNSサーバーが協調する仕組み

blog.example.comというドメインのIPアドレス解決を例に考える
DNSサーバは階層構造でレコードを分散管理しており、以下のように階層ごとに別々のDNSサーバーに格納されている(同じになることもあるが)
- ルートドメイン
- .com
- example.com
- blog.example.com
問い合わせはルートドメインから順番にたどるので以下のような流れになる
1. 最寄りのDNSサーバがルートドメインのDNSサーバにblog.example.com のIPアドレスを問い合わせる
  - レコードのIPアドレスはわからないが、comドメインのDNSサーバのIPアドレスはわかるからそっちに聞いてくれ、とcomドメインのDNSサーバのIPアドレスが返ってくる
2. 最寄りのDNSサーバがcomドメインのDNSサーバにblog.example.com のIPアドレスを問い合わせる
  - 同じ要領で example.com のDNSサーバのIPアドレスが返ってくる
3. 最寄りのDNSサーバがexample.comドメインのDNSサーバにblog.example.com のIPアドレスを問い合わせる
  - 同じ要領で blog.example.com のDNSサーバのIPアドレスが返ってくる
4. 最寄りのDNSサーバがblog.example.comドメインのDNSサーバにblog.example.com のIPアドレスを問い合わせる
  - blog.example.com のIPアドレスが返ってくる
DNSサーバにはキャッシュ機能があるので必ずしも毎回このようなステップになるとは限らない。
- 当然TTLも存在するので最新のデータが返ってくるとも限らない。

3. TCPでの接続の場合にプロトコルスタックが何をしているか

プロトコルスタックとはプロトコル(e.g. TCP, UDP, IP, etc.)を役割ごとに階層化して積み重ねたソフトウェア群を指す。ネットワークの文脈では主にSocketライブラリとLANドライバの橋渡しの役割を担う。

                   +---------------------------------------------------+
Application Layer->|  +---------------------------------------------+  |
                   |  | Network Applications                        |  |
                   |  | (Web Browser, Mailer, Web Server, etc.)     |  |
                   |  +----------------------------+----------------+  |
                   |  | Socket Library             | Resolver       |  |
                   |  +----------------------------+----------------+  |
                   +---------------------------------------------------+
OS Layer---------->| Protocol Stack                                    |
                   |  +----------------------+  +--------------------+ |
                   |  | TCP                  |  | UDP                | |
                   |  | (Connection-based)   |  | (Connectionless)   | |
                   |  +----------------------+  +--------------------+ |
                   |  +---------------------------------------------+  |
                   |  | IP (Route & Forward)                        |  |
                   |  |  +------------+              +------------+ |  |
                   |  |  | ICMP       |              | ARP        | |  |
                   |  |  +------------+              +------------+ |  |
                   |  +---------------------------------------------+  |
                   +---------------------------------------------------+
Driver Layer------>|  +---------------------------------------------+  |
                   |  | LAN Driver (Controls LAN Adapter)           |  |
                   |  +---------------------------------------------+  |
                   +---------------------------------------------------+
Hardware Layer---->|  +---------------------------------------------+  | 
                   |  | LAN Adapter                                 |  |
                   |  +---------------------------------------------+  |
                   +---------------------------------------------------+

『ネットワークはなぜつながるのか第2版』P96 図2.1 をもとに再構成

getaddrinfo(3) を使ってドメイン名に合致するIPアドレス(の配列)を取得
1. UDP担当部分にDNSサーバーへの問い合わせを依頼する
socket(2)でソケットを作成しソケットへのファイルディスクリプタ(以下fd)を取得する
1. ソケット1つ分のメモリを確保しそこに初期状態であることを記録して
2. アプリケーションにfdを返す。
connect(2)サーバーへの接続を確立する
1. アプリケーションからsocketのfdとサーバー側のIPアドレスとポート番号を受け取る
2. 以下の手順で3ウェイハンドシェイクを行う
  1. (クライアント側)送信元と宛先のポート番号やコントロールビット(SYN=1, ACK=0)を含んだTCPヘッダーを作成する
  2. (クライアント側)IP担当部分に送信を依頼する
  3. (サーバー側)IP担当部分がパケットを受け取ってTCP担当部分に渡す
  4. (サーバー側)TCP担当部分がTCPヘッダーを調べてそこに記載されている宛先ポート番号に相当するソケットを探し出す
  5. (サーバー側)該当するソケットに必要な情報を記録して、接続動作が進行中だという状態にする
  6. (サーバー側)送信元と宛先のポート番号やコントロールビット(SYN=1, ACK=1)を含んだTCPヘッダーを作成する
  7. (サーバー側)IP担当部分に送信を依頼する
  8. (クライアント側)IP担当部分がパケットを受け取ってTCP担当部分に渡す
  9. (クライアント側)TCP担当部分がTCPヘッダーを調べてサーバー側の接続動作が成功なら(SYN=1, ACK=1)「サーバーのIPアドレスやポート番号」と「接続完了を示す制御情報」等をソケットに記録する
  10. (クライアント側)サーバー側に接続成功を示すTCPヘッダー(SYN=0, ACK=1)を送り返す
2.で取得したfdに対してwrite(2) でリクエストを書き込む
1. 送信データを受け取ったプロトコルスタックはデータを相手に送る
  1. データが大きいときは分割して送る
  2. ウィンドウ制御方式(ACK番号の到着を待たず、複数のパケットを連続して送る方式) で効率化を図る。ウィンドウの大きさは受信側のバッファの空き容量をもとに調整される。
2. 送信するすべてのパケットにシーケンス番号(何バイト目か)を付与し、受信側はACK番号(受け取ったシーケンス番号の中でその時点で最大のものに1を足した数値)を返し、「ここまでは受け取ったのでこの番号のパケットを送ってください」というメッセージを伝える
3. 送信側はACK番号を見て必要に応じてパケットを再送する
データを受信した場合、受信したデータ断片とTCPヘッダーを途中でデータが抜けていないか検査し、問題なければACK番号を送り返す
read(2) でレスポンスを読み込む
1. 受信バッファに積まれたデータをアプリケーションに渡す
サーバー側がソケットをクローズしたらクライアント側でもclose(2)を使ってソケットをクローズする(なお、クライアントが先にソケットをクローズすることもあり、どちらになるかはアプリケーション次第になる。)
1. (サーバー側)がcloseを呼び出す
2. (サーバー側)プロトコルスタックがコントロールビットのFINを1にセットしたTCPヘッダーを作成し、IP担当部分に送信を依頼する
3. (クライアント側)FIN=1であるTCPヘッダーが届いたのを確認して、自分のソケットにサーバー側が接続動作に入ったことを記録する
4. (クライアント側)FIN=1であるパケットを受け取ったことをサーバー側に知らせるためにACK番号をサーバー側に送り返す
5. (クライアント側)サーバーからすべてのデータを受け取ったことをアプリケーション側に知らせる
6. (クライアント側)コントロールビットのFINを1にセットしたTCPヘッダーを作成し、IP担当部分に依頼してサーバーに送ってもらう
7. (サーバー側)クライアント側からFIN=1なパケットを受け取ったらACK番号を返す
8. (クライアント側)サーバーからACK番号が返ってきたことを確認し、サーバーとのやり取りを終了する

4. IPが何をしているか

IPの主な役割は宛先IPアドレスをもとにパケットの転送先を決定し、次のホップへ届けること。

IPヘッダー、MACヘッダーの作成
- 送信元・宛先IPアドレス、TTL(Time To Live)などを含むIPヘッダーをTCPパケットに付与する
  - TTLはルーターを経由するたびに1減らされ、0になったらパケットは破棄される(ループ防止)
- IPヘッダーの前にMACヘッダーを付与する
  - MACヘッダーには宛先MACアドレスと送信元MACアドレスが含まれる
- MACアドレスの解決にはARPを使う
  - ARPとは、IPアドレスからMACアドレスを解決するためにLAN内でブロードキャストを行い、対象IPアドレスのMACアドレスを特定するためのプロトコルである
  - キャッシュ機能もあるので毎回ブロードキャストするわけではない
ルーティング
- ルーティングテーブルを参照して「次にどのルーターにパケットを渡すか」を決定する
- 宛先IPアドレスとルーティングテーブルのエントリを比較し、最長プレフィックスマッチで転送先を選ぶ
- 宛先が同一LAN内であればそのままL2で届けられる
- あくまでIPは「どこに届けるか」を決める仕組みで、実際の転送はイーサネットを用いて行うためMACアドレスが必要になる

IPはベストエフォートの転送のみを担い、信頼性の保証はしない(それはTCPの責務)

ICMPとARPはIPの動作を補助する形で動く。

ICMP: エラー通知(宛先到達不能など)や疎通確認(ping)に使われる
ARP: IPアドレスからMACアドレスを解決するためにLAN内でブロードキャストされる

5. イーサネットとは何か

イーサネットはLAN内の機器間でデータをやり取りするための規格。IPがネットワーク間の転送を担うのに対し、イーサネットは同一LAN内の転送を担う。

アドレス体系
- MACアドレス(48ビット)を使って送受信先を識別する
- MACアドレスは原則的にはNICに割り当てられた固有の識別子
- IPアドレスが「建物の住所」なら、MACアドレスは「人の名前」に相当する
フレーム
- イーサネットではデータを「フレーム」という単位で送受信する
- フレームには送信元MACアドレス、宛先MACアドレス、データ、エラー検出用のFCSが含まれる
スイッチングハブ
- MACアドレスと接続ポートの対応表(MACアドレステーブル)を持ち、宛先MACアドレスに対応するポートにだけフレームを転送する
- 最初は対応表が空なのでブロードキャストし、応答を受け取ることでテーブルを学習していく

6. インターネットとは何か

なお「インターネット」は広範な意味を持つ言葉だが、ここでは本書のスコープ(ISP・POP・IXあたりの話)に限定して整理する。

インターネットとは、世界中のISP(インターネットサービスプロバイダ)のネットワークが相互接続された巨大なネットワークの集合体。

ISPとPOP
- ISP(Internet Service Provider)はインターネット接続サービスを提供する事業者
- POP(Point of Presence)はISPの設備が置かれた接続拠点。ユーザーのパケットはまずここに届く
- POP内にはルーターが置かれており、パケットを次の拠点に転送する
NOC
- POPから入ってきたパケットが集まる
- プロバイダの中核となる設備
- データ転送能力が数テラビット/秒を超えるルーターが使われることもある
IX(Internet eXchange)
- 複数のISPが相互に接続するための中立的な施設
- IXを介することでISP間のパケットのやり取りが効率化される
パケットの経路
- ユーザーのパケットはISPのPOP → ISPバックボーン → IX → 相手ISP → サーバーという流れで届く
- 経路上のルーターがBGP(Border Gateway Protocol)で経路情報を交換し合うことでインターネット全体のルーティングが成立している

Q&Aメモ

こちらのポストを参考にしてClaudeに質問を作成してもらい、都度Claudeに相談しながら回答を考えてみた。

あくまで「この質問に対しては暗記ではなく理解をもとに答えられるようになった」ということをメモしておくための自分用学習メモです。

No	質問	回答
1	TCPの3ウェイハンドシェイクはなぜ「2ウェイ」ではダメなのか	サーバーからクライアントへの経路が機能しているかどうかをサーバーが確認できないため。双方向の疎通を双方が確認するには3メッセージ必要になる。
2	DNSキャッシュのTTLを短くするデメリットは何か	キャッシュDNSサーバーから権威DNSサーバーへのリクエスト数が増加する。その結果以下が発生する。 • 権威DNSサーバーが処理しなければならないリクエストの量が増えるため、権威DNSサーバーのレイテンシが増加する • キャッシュDNSサーバーがキャッシュを返す割合が減るため権威DNSサーバーへのリクエスト分のレイテンシが増加する
3	NATがエンドツーエンド通信に何をしているか図で説明せよ	送信時はプライベートIPとポート番号をルーターのグローバルIP+任意のポート番号に変換し、受信時はその逆の変換を行う。結果として通信相手はNATを意識することなく、単一のグローバルIP+ポート番号とやりとりをしているように見える。
4	TCPとUDPの使い分けを「信頼性」以外の観点で説明せよ	前提として、UDPは接続確立や再送のオーバーヘッドがなく、輻輳制御も行わないため高速に通信を行うことができる。信頼性を多少犠牲にしてでも高速性を重視したい場面ではUDPの利用が有効なケースがある。たとえば遠隔運転システムでは、一瞬映像が途切れたとしてもリアルタイムに映像が表示され続けることが重要になるためUDPのメリットを享受しやすいと考えられる。
5	ルーティングテーブルの「最長プレフィックスマッチ」とは何か、なぜその方式か	ルーティングの際にルーティングテーブルの中から宛先IPアドレスとマッチする範囲が一番長いレコードにあるネットワークを次のルーティング先とする方式。 `10.0.0.0/8`に向けるデフォルト経路と`10.1.2.0/24`に向ける特定経路が存在する場合は後者を優先しないと意図したルーティングにならないため。
6	HTTPSでサーバー証明書が必要な理由を、鍵交換から説明せよ	MITMへの対策のため。証明書がないと鍵の交換相手が本物のサーバーなのか攻撃者なのかわからないため必要になる。
7	パケットロスが0%でもアプリが遅い理由を説明せよ	ここでは「アプリが遅い」 == 「クライアント側で見ているWebアプリの動作が想定よりも遅い」と仮定する。 • DNSサーバーのレイテンシが大きい • クライアントのマシンの動作が遅く、リクエスト送信までに時間がかかっている • アクセス回線にADSLが含まれるなどがそもそも低速な回線がボトルネックになっている • クライアントとサーバーが地理的に離れており、そもそも通信に時間がかかる • 経路上のネットワーク機器が古く、非効率な通信を行っている • サーバーの負荷が高く、CPUがスロットリングした結果、サーバーの処理全体が遅くなっている • マイクロサービス構成になっておりそもそも必要なネットワークIOの数が多い
8	サブネットマスクはなぜ必要か、IPアドレスだけでは何が足りないか	IPアドレスのうち、どこまでがネットワーク部でどこからがホスト部なのかがわからなくなるため。
9	ARPはなぜIPレイヤーではなくL2に属するのか	ARPはIPアドレスをMACアドレスに解決するプロトコルだが、L2のフレームで直接ブロードキャストし、IPルーティングを経由しない。つまりL3の仕組みに依存せずに動作する必要があるためL2に属する。
10	ping が通るのにHTTPが失敗するとき、最初に何を疑うか	ファイアウォールによるポートのブロックを疑う。 pingはICMPプロトコルを利用しており、そもそもポート番号を指定する必要がない。一方でHTTPはポート番号を指定する必要があるため。他にはサーバー側でサーバープログラムが起動していない可能性やTLSの証明書エラーの可能性も考えられる。

まとめ

読む前の期待以上にネットワークの解像度を上げられたので読んでよかった。

次はOperating Systems: Three Easy PiecesでOS周りの深堀りをしていこうと思っている。メモリ管理やプロセス、スレッド周りの解像度を上げたい。あと課題でCを書く必要があるのも若干良さそうに感じたポイントでもある。(Cを書くのは辛いが、その分頑張りが身になる感覚があり…)¹

Operating Systems: Three Easy Pieces

https://pages.cs.wisc.edu/~remzi/OSTEP/

軽く読んだ感じ、英語ではあるもののかなり平易に書いてくれているので読みやすそうだった。やっていく。²

(C言語はCS50で軽くさらった程度なのでせっかくなので『プログラミング言語C 第2版』あたりの入門書を一冊読むのもいいかもしれない)

“you will also learn the practical, including how an operating system does things like schedule the CPU, manage memory, and store files persistently.” とのこと。 ↩︎
なお、内容は無料でWebで公開されているので無課金で学習することも可能。自分は移動時間に読んだり書き込んだりしたかったのでPDFを購入した。(それでも$10という破格) ↩︎

Go Conference mini in Sendai 2026に参加した

Sun, 01 Mar 2026 09:00:32 +0900

2026/02/21(土)に仙台で行われたGo Conference mini in Sendai 2026に参加したのでその内容をまとめる。

Go Conference mini in Sendai 2026

2026年2月21日（土）開催 - Go Forward Together - 東北から広がるGoコミュニティ

https://sendaigo.jp/

【KeyNote】静的解析からみるGoの過去と未来

tenntennさんによるキーノート。

最後に紹介されていたGo1.27のアノテーションで静的解析をできるようにする機能は今まさに自分が欲している機能¹なので調べてみようと思った。

以下メモ。

//line a.go:1のような記法は知らなかった。
- 調べてみたところline directiveという名前がついているようだった。²
- こんな感じでコンパイラが出力するエラーメッセージなどが上書きされる。
  - https://go.dev/play/p/Thvs9U8Twvj
- 自動生成されたコードのエラーを元のコードの行番号で表示したいときなどに使われるらしい。(例えば自動生成されたGoファイルでのエラーに対してprotoファイルの行番号をエラーに表示したいケースなど)
go test -coverを実行すると裏側ではgo tool coverが実行され、計測用のコードが挿入される
Goがセルフホスティングされるようになったのは2015年（Go1.5）（それまではC）
- (まだ10年しかたってないんだなー)
- ここからコンパイラのコードが既存標準パッケージと共通化されたりするようになった
2019
- goplsが登場
- 最初はgolspだったがしれっと名前が変わったらしいw
Go 1.27
- アノテーションによる静的解析
  - 一点もののlinterを作らなくてよくなる。
  - //go:fix inline
    - https://go.dev/doc/go1.26#go-command
  - xxしたあとにyyする、みたいな制約をアノテーションで表現できるようになる（らしい。が一次情報は見つけられていない）

AI時代のGo開発2026 爆速開発のためのガードレール

UPSIDERのRyo MimuraさんによるAI時代の開発生産性を保つにあたっての課題と対策についてのセッション。

最近PRレビューをする機会が増えてレビュワーとPR作成者双方の負担を減らす方法を考えていたのでとても参考になった。

以下メモ。

AIの予期せぬ変更はRules / Skillsでもある程度は防げるがあくまで挙動は非決定的なためすり抜けてしまう可能性がある。そのためハード制約（決定的な処理による制約）を設けることが重要。
ハード制約の例
- internal packageで予期せぬ外部参照から保護する
- depguardによる依存性ルールの強制
- Package by Featureで凝集性を向上させることでコンテキストをうまく制御する
Fuzzing Test, Mutation Testingなどのテスト手法を活用してコード品質を保つ
開発者体験 = エージェント体験
- 両者は同じもの。
- 環境構築、テストとフィードバック、可観測性等開発者体験が悪ければAI Agentもうまく開発を進めることはできなくなる。

Go での並列処理「最初の一歩」から「次の一歩」へ

TakasagoさんによるGoでの並行処理についてのセッション。

並行処理の原理だけでなく、パターンを身につけておくといざ実装するとなったときに役に立ちそうだと思った。（なかなか毎月書くような機会がないのであまり定着してない…）

以下メモ。

Goは同期で書いておいて高速化したい箇所だけ並列化する、という書き方がやりやすいのが特徴。

Go.1.26のruntime/metricsが便利そうな件（？）

o_ga09さんによる発表。

goroutineリークをリアルタイムに検出できるの便利そう。

モジュラモノリスにおける境界をGoのinternalパッケージで守る

SODA inc.のmagavelさんによる発表。

メモ:

「結合はむしろ、忘れてはならない設計ツールだ。」
bounded_contextディレクトリを切っているのが印象的だった

お話したこと:

ディレクトリ構成について
- bounded_contextディレクトリの同階層にはmonolishディレクトリがある
  - これらは現状ワンバイナリになっている
- bounded_contextディレクトリの中には購入、xxx、yyyなどの境界づけられたコンテキストが並ぶ。
- たとえば購入コンテキストの中には購入モジュール、決済モジュールなどがある。
- 購入モジュールからは決済モジュールの公開されたIFを呼び出すようになっている。
- 公開したくないパッケージはすべてinternal配下に置くことで予期しない依存を防いでいる。
- 他にもdepguardを使って依存関係を制御している。

Go設計思想の深掘り

k_program510さんによる発表。

メモ:

発表者の方がオブジェクト指向言語に慣れていてGoにクラスがないことに驚いてGo誕生の背景を深ぼろうと思った、という自分の疑問に向き合う姿勢がとても素敵だと思った。
設計思想は「どこで使うべきか」を教えてくれるいい言葉だ。

database/sql/driverを理解してカスタムデータベースドライバーを作る

replu5さんによる発表。

メモ:

カスタムデータベースドライバーを作る理由
- ログをだしたい
- リクエストをDBのwriteインスタンスとreadインスタンスに振り分けたい
- sqlcを使っているが、sqlcが生成したコードに手を加えていくのは避けたい
- 本体をforkしてしまうと本体に追従するのが大変なので既存のドライバーをラップしたドライバーを作成することにした

お話したこと

sqlcだと引数に応じてwhere句を一部変更することができないと思うがどうやっているのか。
- そういうケースでは複数パターンのクエリを（愚直に）repository層に書いている。
- そもそも巨大で複雑なクエリにはsqlcは適していないので使うべきではないかもしれない。
  - （技術の思想や特徴を理解し適切な場所で使うべき、という姿勢は↑のk_program510さんの『Go設計思想の深掘り』とも通じることがあると感じた。）

nilとは何か〜言語仕様と設計者の葛藤から理解する〜

株式会社サイバーエージェント kurodaさんによる発表。

以下メモ。

Goで定義されているキーワード数を即答している人が数人いてすごかったw（25個らしい）
nilはキーワードではない。true, false, iotaと同じpredeclared identifier(事前宣言された識別子)である。
predeclared identifierのなかでデフォルト型を持たないのはnilだけ。
（ちょいちょいクイズが挟まっていて参加者を飽きさせない工夫があって発表の仕方が参考になった）
interfaceが==nilになるのは型情報もデータも両方ゼロのときのみ。
- なのでtyped nilは==nilにならない。
  - -> var err *MyError = nilのように初期化した値は==nilにならないのでnilをreturnしたい場合は明示的にnilを返す必要がある。（全然知らなかった）
nilに関する問題をどう解決するかの議論がなかなか前に進んでいないことを説明してからのerrors.AsTypeをセマンティクスを変えずにうまく問題を解決した例として説明する流れがめっちゃ綺麗だった。

Who tests the `Tests` ?

sivchariさんの発表。

メモ:

AI時代になってCIの重要性が増している。
カバレッジだけを追っていくと本質的でないテストコードが増えてしまう。
テストコードのテストとしてMutation Testingという手法を紹介する。
Mutation Testing
- プログラムの一部を意図的に書き換え、生成したミュータントに対してテストを実行し、失敗するかどうかを検証する手法。
  - 演算子の変更、elseブロックの削除など
- 失敗することを期待するテスト(KILLED: テスト失敗 == 期待した挙動、SURVIVED: テスト成功 == 期待した挙動ではない)
- どれくらい失敗したかを指標にする。
- ただこれは銀の弾丸ではない。実行時間とのトレードオフになる。
  - 100% KILLEDを目指すべきではない。
Mutation Testingをどう実装するか
- sivchari/gomuというMutation Testingライブラリを作成した。
- overlayを使うと実際のファイルを仮想的に変更して実行できる
  - ソースコードを汚さずに好きなように変更できる

感想:

overlayすごそう
気になったこと
- mutation testingの使い所について
  - 実際のプロダクションに導入するならある程度テストが整備されたあとにやるのが優先順位としてよい？（Mutation Testingがちゃんと動作することの前提としてある程度のカバレッジが必要そう）
  - あとは不慣れな巨大コードと向き合うときにmutation testを実行してみてテスト品質を把握する、というのもいいかもしれない。
- mutation testing以外のテスト品質保証手法について
  - あまりテストの品質を定量的、機械的に保証する方法をカバレッジ以外に考えたことがなかった。
  - mutation testing以外ではどのようにテストコードの品質や正当性を保証するのがよさそう？
  - たとえばk8sの内部実装などではどのように品質担保しているのか気になった（気になっただけで調べられてはいない）

Goから学ぶGCの仕組みとGreen Tea GCによる次世代最適化

go_poron10さんによる発表。

とても内容が高度で途中でついていけなくなってしまったのでいつかリベンジしたい。

【実装公開】Goで実現する堅牢なアーキテクチャ：DDD、gRPC-connect、そしてAI協調開発の実践

株式会社テレシーのDaisuke Sasakiさんによる発表。

お話したこと:

application層のQuery Serviceからdomain packageへの依存はOKにしている？それとも独自のreturn typeをQuery serviceで定義している？
- 依存OKにしている。
- domain層に以下の2種類があり、それぞれ別パッケージに定義している。
  - commandとqueryの両方から参照される型(tier1)
  - queryからのみ参照される型(tier2)

スポンサーブースで話したこと（一部抜粋）

ANDPAD
- 意外にもGo関連の勉強会でスポンサーブースを出すのは初とのこと。
  - スポンサーブースが抽選なので出展の機会を得るのは簡単ではないらしい。
  - 個人的にはGoに力を入れている会社のイメージを2年くらい前から持っていたので意外だった。
SODA
- CodeRabbitでレビュー負荷を下げている
- PRレビューはチーム全員で分担して特定の誰かに負担が偏らないようにしている

感想

ソロ参加だったがセッションの合間や懇親会でたくさんの人と交流できてとても楽しかった。
- 社外のエンジニアと話せるとかなり刺激&学びになるので今後も機会を見つけていろんな勉強会に参加してみようと思った。
- 勉強会に参加している人は自分の時間を使って勉強会に参加するくらいなのでモチベが高い（あるいは技術が好きな）人が多いというのはあるかもしれない。（考えてみれば当たり前だが実際に行ってみてそのことを実感できた）
今年はCSの勉強³と並行してGoのインプット & アウトプットを頑張っていこうと思っているのでモチベがいい感じに上がった。
- たくさんの強者を見たことで自分が目指す技術力の基準を上げられた感覚がある。
運営、登壇者、スポンサー、参加者の皆様ありがとうございました！

振り返り

セッションの合間は発表者の方に質問するためにウロウロしている時間が長かったのもあり、全スポンサーブースを回れなかった。もうちょっといい感じに時間を使えるとよさそう。（スポンサーブースで各社の方とお話するのは楽しいので全部回りたい気持ち）
懇親会の途中から他の人に自分から話しかけたりできたけど次回は最初からできるともっとよさそう。⁴

おまけ

土日に仙台でKing Gnuのライブがあった影響か、土曜は仙台駅付近のホテルがめっちゃ高かったので福島まで移動して宿泊してgot aことなきした。（ありがとうアパホテル）
福島で食べたお寿司が美味しかった。観光までする（体力的）余裕がなかったのが残念。
なんか新幹線が長かった。

大AI時代になりPRレビュー負担が肥大化しているのでCIで機械的にコード品質を担保するためにLinterを増やそうと思っているため。 ↩︎
https://pkg.go.dev/cmd/compile#hdr-Line_Directives ↩︎
今は（今更ながら）『ネットワークはなぜつながるのか』を読んでいる。 ↩︎
話しかけるときは普通に「お疲れ様です〜」とかでいいんだなという学びを得た。 ↩︎

開発環境現状確認 2026

Sun, 15 Feb 2026 00:00:08 +0900

2026年年始に複数の方（や会社）が開発環境について書いていたので2026年時点のスナップショットも兼ねて自分も流行りに乗って書いてみる。

開発環境現状確認（2026年） - Don't Repeat Yourself

覚えてたのでやります。 blog-dry.com 前提として、macOSです。エディタ Neovimを使っています。仕事ではKotlinを使用しています。KotlinのLanguage Serverは登場しましたが、相変わらずまだ安定的に使える状態にはないのでKotlinを書くときだけ仕方なくIntelliJを使っています。ちなみに別にIntelliJに強い不満があるわけではなく、がんばってlazygitをfloating windowで開かせてそれっぽい動作をさせるなどの涙ぐましいカスタマイズをしています。なお今年は一瞬Rustのコードレビューなどをする時間を仕事で得たのですが、Neov…

https://blog-dry.com/entry/2026/01/02/145952

開発環境現状確認 2026 - k0kubun's blog

@helloyuki_ さんと @giginet さんがやってて、自分との違いを眺めるのも面白いかと思ったので書いてみる*1。僕の以前の環境は後悔しているがやめられない開発効率向上術、Neovimを一瞬でVSCode並みに便利にする、自作PC2023: Ryzenをやめたあたりで書いた。 OS Linux、macOS、Windows の3つを、この順に多く使用している。使っている環境が多いほど面倒毎が増えるので、本当なら3つも使わない方が良い。 LinuxはUbuntu 24.04を使っている。よく使うDockerイメージやGitHub Actions環境と同じパッケージ名が使えたり、デス…

https://k0kubun.hatenablog.com/entry/development-environment-2026

ペパボパートナーの開発環境現状確認 2026 - Pepabo Tech Portal

「開発環境現状確認2026」に寄せて、ペパボパートナーの有志の開発環境を紹介します！@名前の環境詳細をみるをクリックして、各メンバーの詳細な環境を確認してみてください。

https://tech.pepabo.com/2026/01/23/development-environment-2026/

それではやっていきます。

OS

大学生くらいからmacOSを使っている。あまり不満がなくて好き。（仕事用端末もmacOS）

唯一あるとしたらゲームがあんまりできないのでこれがちょっとだけ気になっている。

Steam Machine

Your games on the big screen

https://store.steampowered.com/sale/steammachine

5年くらい前に買ったM1 MacBook Air(16GB RAM)の物持ちが良すぎて新しいMacを買うタイミングがなかなか来ない。新しいMacを買うのは楽しいので買いたい気持ちもありつついかんせん困ってないのでなあ…の気持ち。

エディタ

（就職した）2021年くらいからNeovimを使っている。厳密には2022年ごろまではJetBrains系のエディタと併用していたが、そこからはNeovimのみを使っている。

キーボードだけで操作しやすいのと起動が早いのとカスタマイズしやすいのが好きでつかっている。（もちろんvimの操作性も気に入っている）

最近はこんな感じでdiffview.nvimを使ってPRのdiffはすべてNeovim上で見るようにしている。コードをレビューしていると周辺の実装も含めて確認したいことがよくあるので、エディタ上でレビューしているとすぐに該当ファイルに飛べて便利。（octo.nvimにコメント周りのバグがあったのでレビューコメントの書き込みはGitHubのWebUIから行っている。）

GitHub - sindrets/diffview.nvim: Single tabpage interface for easily cycling through diffs for all modified files for any git rev.

Single tabpage interface for easily cycling through diffs for all modified files for any git rev. - sindrets/diffview.nvim

https://github.com/sindrets/diffview.nvim

今はGo/TypeScript/Rustあたりしか書いてないので特に困ってないが、JVM系をNeovimで書こうとすると若干辛みがあるかもしれない。（ちょっとだけJava/ScalaをNeovimで書いたことがあるが重かったり不安定だったりして辛かった）

AI時代になって設定を自分好みにするコストが格段に減ったのでNeovimのカスタマイズが捗っており嬉しい。最近はPRレビュー効率化のための色々をClaude Codeにやってもらっている。（Luaの書き方を覚える前にAI時代が来てしまった…）

久々に起動時間を測ってみたら60msくらいになっていたので気が向いたらもうちょっとチューニングしてもいいかもしれない。（たぶん30msくらいまではいけるはず）

一時期cursorも頑張って設定ファイルを作り込んだうえで慣れようとしてみたが、どうもVSCode系エディタとは思想が合わなかったので結局数日で戻ってきてしまった。

AIツール

ClaudeとDevin、GitHub Copilotを使っている。

ClaudeはDesktop App経由で壁打ちや検索用途で使ったり、Claude Codeでコードを書いてもらったりしている。

Claude Codeを使うときはNeovim plugin等ではなくtmuxのpaneを切ってそこで直接動かしている。

Devinは主にAsk Devinを使ってコードベースの調査などに使っている。レスポンスがめっちゃ早くてありがたい。

GitHub Copilotはエディタのインライン補完で使ったり、GitHubのWebUI上でタスクを依頼したりするときに使っている。特にこのブログの機能開発ではよく使っている。（issueさえ書けばそのままWebUIからタスクを依頼できて便利）

ターミナルエミュレータ

Alacrittyを使っている。ターミナルにはタブ機能がない方がcmd+w等を誤爆したりとかが起きないので好きで使っている。（iTerm2を使っていたときはたまに誤爆してシェルが消えて悲しくなっていた。）

正直早いかどうかはあまりわかってないが特に不満もない。（少し前に日本語入力もいい感じになったし）

GitHub - alacritty/alacritty: A cross-platform, OpenGL terminal emulator.

A cross-platform, OpenGL terminal emulator. Contribute to alacritty/alacritty development by creating an account on GitHub.

https://github.com/alacritty/alacritty

ターミナルマルチプレクサ

tmuxを使っている。1セッションに好きなだけウィンドウを開く運用で使っている。

tmux-fzfでのwindow切り替えがとても便利で気に入って使っている。

設定手順は過去にこちらに書いた。

tmux-fzfを使ってwindow切り替えをできるようにする手順

これはなにこんな感じでtmuxでwindowをfzfで切り替えられるようにするための設定方法手順 .tmux.confに以下を追記 set -g @plugin 'tmux-plugins/tpm' # す

https://blog.kyu08.com/posts/tmux-fzf-window/

前述の通りalacrittyとの相性がいい感じなのでよほどのことがない限りこの組み合わせは変えなさそう。²

Status Lineはこんな感じで画面下側にwindow名と現在時刻を表示している。

詳しくは後述するが、nvim-orgmode/orgmodeでClock In(時間計測)しているタスクがあるときはそのタスク名と経過時間をStatus Lineに表示するようにしている。1つのタスクに集中できて割と作業が捗っている。

その他のtmuxの設定とか工夫を紹介する記事は別で書きたい。

Zellijも試したことはあるが、自分の環境だとなぜか表示が崩れてしまったので使っていない。

シェル

zshを使っている。

元々はネットに落ちているshellのコードが（fishよりも）動きやすいから、という理由で使っていたのを惰性で使い続けている。

少し前にこの記事を参考にして起動を高速化したりした。（最近は測ってないが多分今も数10msくらいで起動するはず）

究極のzshプラグイン読み込み高速化: プラグインマネージャーの限界を越えろ【起動時間14.6ms】

https://zenn.dev/fuzmare/articles/zsh-plugin-manager-cache

2024/4頃からzeno.zshを使っていてよく使うコマンドの実行がかなり効率化できている。snippetがいい感じに展開されるのは言わずもがな嬉しいが、zeno-insert-snippetでzenoに登録したsnippetをfzfで選択&挿入できるのがとても便利。設定ファイルはまだyaml形式で書いている。

GitHub - yuki-yano/zeno.zsh: zsh fuzzy completion and utility plugin with Deno.

zsh fuzzy completion and utility plugin with Deno. - yuki-yano/zeno.zsh

https://github.com/yuki-yano/zeno.zsh

プロンプト表示にはstarshipを使っている。

GitHub - starship/starship: ☄🌌️ The minimal, blazing-fast, and infinitely customizable prompt for any shell!

☄🌌️ The minimal, blazing-fast, and infinitely customizable prompt for any shell! - starship/starship

https://github.com/starship/starship

こんな感じでk8sのcontextとnamespaceを表示するようにしている。

誤ってprod環境を壊すことがないようにこんな感じでcontextにprodという文字列が含まれていたら目立つようにしている。

設定はこんな感じ。

[kubernetes]
format = '[[$symbol]($style)\[ctx\]$context \[ns\]$namespace]($style) '
disabled = false
contexts = [
  { context_pattern = ".*dev.*", style = "blue", symbol = " " },
  { context_pattern = ".*prod.*", style = "bold red", symbol = "🔥 " },
]

その他の設定とか便利スクリプトを紹介する記事は別で書きたい。

ランチャー

AlfredとRaycastを併用している。

基本的に不満がないかつ操作性がRaycastよりも好みなので基本的にはAlfredを使っている。

使い道は至って普通でスニペットやweb検索、ローカルのファイル検索などに使っている。

あとはWorkflowを利用してよく使うアプリを以下のようなキーバインドで呼び出せるように設定している。

Alacritty: opt + space
Brave: cmd + esc
Slack: opt + opt
Notion: opt + n
Claude: opt + x
TickTick: opt + t
Spotify: ctrl + esc

今は治ってるかもしれないが、一時期Alfredのクリップボードの動作がとてつもなく重くなってしまったのでそこだけRaycastを使っている。

ウィンドウマネージャー

yabaiとskhdを使っている。設定をコード管理できるのが嬉しい。たまに動作が不安定になるのでそのたびにyabai --restart-service && skhd --restart-serviceを実行している。とはいえ特に不満もない。

GitHub - asmvik/yabai: A tiling window manager for macOS based on binary space partitioning

A tiling window manager for macOS based on binary space partitioning - asmvik/yabai

https://github.com/asmvik/yabai

GitHub - asmvik/skhd: Simple hotkey daemon for macOS

Simple hotkey daemon for macOS. Contribute to asmvik/skhd development by creating an account on GitHub.

https://github.com/asmvik/skhd

めっちゃ雑に書くとよく使うのはこの辺のやつ。

windowを右半分に表示
windowを左半分に表示
windowを左上に表示
windowを左下に表示
windowを右3/4に表示
windowを左1/4に表示

フォント

M+1Code Nerd Font Monoを使っている。まるっとしていて好き。nerd fontも入っているのでNeovimを使っていても豆腐が出ず嬉しい。（あまり原理はわかってないがCicaなどの他のnerd font対応フォントよりも豆腐が出なくてありがたい）

タスク管理

ここ1年くらいはnvim-orgmode/orgmodeを使っている。emacsのorg-modeライクな機能をNeovimで使えるようにしたプラグイン。

GitHub - nvim-orgmode/orgmode: Orgmode clone written in Lua for Neovim 0.11.0+.

Orgmode clone written in Lua for Neovim 0.11.0+. Contribute to nvim-orgmode/orgmode development by creating an account on GitHub.

https://github.com/nvim-orgmode/orgmode

少し前まで素朴にこんな感じのマークダウンファイルを毎日生成して管理していたが、期日が違うタスクをいい感じに管理したくて使い出した。

## TODO
- 実装

## DONE
- コードレビュー

Neovimでタスク管理できるのとタスクに優先度、期日を設定してそれをいい感じにソートして表示してくれるのがかなり肌にあっていて気に入っている。

最近は時間の使い方を振り返る目的でClock In的な機能を使ってタスクごとの所要時間も管理してみている。

これに関してはそのうち別の記事として詳しく書きたい。

ブラウザ

数年前からBraveを使っている。広告をブロックしてくれつつChrome拡張も使えるので便利。一時期Arcも使っていたが肌に合わない挙動があったので使うのをやめてしまった。（具体的には覚えていない）

よく使うChrome拡張は少し前にこの記事に書いた。

ソフトウェアエンジニア目線で使ってみて便利だったChrome拡張を紹介する

本記事はUnipos Advent Calendar 2024の13日目の記事です。本記事では使ってみて便利だったChrome拡張を紹介します。 Stylus Stylus ユーザー定義のCSSを

https://blog.kyu08.com/posts/chrome-extensions-for-dev-2024/

IME

Google日本語入力を使っている。

たまーにひらがなの変換がおかしいのが気になっているが全体的には割と満足している。

azooKeyも試したが辞書登録した単語の優先度が低いのが使いづらくて使うのをやめてしまった。（ライブ変換はとても便利だった。）

ならissueを立てんかい…という話ではあるがちょっとこのところ忙しくそこまではできていない。

CLI/TUIツール

よく使っているCLI/TUIツールはこのあたり。

fzf

GitHub - junegunn/fzf: :cherry_blossom: A command-line fuzzy finder

:cherry_blossom: A command-line fuzzy finder. Contribute to junegunn/fzf development by creating an account on GitHub.

https://github.com/junegunn/fzf

言わずと知れたあいまい検索ツール。
ディレクトリ履歴移動やファイル検索などあらゆるスクリプトで使っている。

lazygit

GitHub - jesseduffield/lazygit: simple terminal UI for git commands

simple terminal UI for git commands. Contribute to jesseduffield/lazygit development by creating an account on GitHub.

https://github.com/jesseduffield/lazygit

gitのTUIクライアント。
gitの操作はすべてlazygitでやっている。
add commit push pullなどの日常の操作やブランチ操作などをかなり少ないキー入力で行えるのがとても便利。
git rebase -i相当のことができたり、commitの一部だけstagingに戻したりと細かいこともできる。
ここ2年くらいで細々とPRを送っており、去年末頃に9番目にcommitが多い人になることができた。

k9s

GitHub - derailed/k9s: 🐶 Kubernetes CLI To Manage Your Clusters In Style!

🐶 Kubernetes CLI To Manage Your Clusters In Style! - derailed/k9s

https://github.com/derailed/k9s

GKEのリソースを見たり操作したりするときに使っている。とても便利。（画像はサンプル用にkindでローカル起動したクラスタのもの）
ログはあまり使いこなせてないので普段の開発ではDatadogやCloud Loggingを見ていることが多い。

<PRここから>

fzf-make

fzf-makeというmake targetをfuzzy finder形式で選択、実行できるTUIを開発している。

コマンド名やその内容を覚えずとも楽に実行できたり、履歴機能があるのが特徴。

現在はMakefileに定義されたmake target以外にも以下のようなコマンドに対応している。

package.jsonのscriptsに定義されたコマンド(pnpm, yarn, npmに対応)
justfileに定義されたrecipe
Taskfile.ymlに定義されたtask

次のようなコマンドでインストールできるのでぜひ使ってみてください。

brew install fzf-make

cargo +1.90.0 install --locked fzf-make

スターもしてもらえると嬉しいです🙏

GitHub - kyu08/fzf-make: A command line tool that executes commands using fuzzy finder with preview window for make, npm, pnpm, yarn, just and task.

A command line tool that executes commands using fuzzy finder with preview window for make, npm, pnpm, yarn, just and task. - kyu08/fzf-make

https://github.com/kyu08/fzf-make

</PRここまで>

キーリマッパー

Karabiner-Elementsを使っている。

vimmerなのでAの左側のキーを

単押しでesc
長押しでctrl

となるように設定している。

あとはよくある左cmdを英数、右cmdをかなにリマップする設定とか、ctrl+shift+hjklで←↓↑→が入力する設定とかを入れている。

キーボード

7sPro
- 2021/8から使っている。今は家でメインのキーボードとして使っている。
- キースイッチはYushakobo Fairy Silent Linear Switchを使用。
- https://shop.yushakobo.jp/products/7spro
EPOMAKER SPLIT70
- 2026/1に買って職場で使っている。分割キーボードかつガスケットマウントでとても打鍵感が良い。
- キースイッチは同じくYushakobo Fairy Silent Linear Switchを使用。
- https://epomaker.jp/products/epomaker-split70

その他

fuwari
- スクリーンショットを付箋のように画面上に貼り付けておけるmacアプリ。画面に表示されている何かをちょっとメモ的に見たいときにとても便利
- https://github.com/kentya6/Fuwari
- こんな感じで動く

まとめ

ここ数年で主要な使用ツール（Neovim, tmux, zsh）が変わっていないので安定して自分好みのカスタマイズが進められている。

AIツールの実装力がかなり上がったのもあり、Neovimやtmuxのカスタマイズも今まで以上にかなり捗るようになっている。

好みの環境で作業ができると作業自体が楽しくなって仕事や趣味のモチベーションも上がるので2026年もやっていき。

みなさんのこだわりもぜひ教えてください〜！

これ系の記事でNeovimの使用率が1位になってるの初めて見た。Neovimユーザーとしては嬉しい。 ↩︎
画面内の文字を検索するのにcmd+fをよく使うのでGhosttyは自分には合わなかった。 ↩︎

『解像度を上げる』を読んだ

Wed, 11 Feb 2026 13:00:41 +0900

おすすめしていただいて気になっていた『解像度を上げる――曖昧な思考を明晰にする「深さ・広さ・構造・時間」の４視点と行動法』を読んだ。

起業家に向けて書かれている記述が多かったが、いちソフトウェアエンジニアとしても非常に参考になる部分が多かったので自分に刺さったポイントを書いていく。

なお、引用は特別に断りがない限りすべて同書からのものです。

「解像度」の構成要素

解像度の高さが何によって構成されているかを考えたときに見えてきたのが、「深さ」「広さ」「構造」「時間」の４つの視点です。

解像度の構成要素を「深さ」「広さ」「構造」「時間」の4つと整理する視点を得られたのが本書を読んで一番良かったポイントかもしれない。

この視点があると「なんか解像度が低いぞ…」となったときにどの要素が足りていないかを考えることで効率的に再現性高く解像度を上げることができそう。他の人のアウトプットへのFBにもかなり便利に使えそう。

4要素は以下のように理解した。

深さ: 具体性を上げたり、因果関係を深堀りしたりする
広さ: 網羅性（幅広さ）を上げる
構造: 「深さ」と「広さ」のステップで出した各要素を構造化する（要素を分解したり整理したりする）
時間: 「過去」「現在」「未来」のような時間軸の観点を盛り込む

情報をツリー構造で整理する

ここまで、深さ、広さ、構造、時間の４つの視点で解像度をチェックしてきました。こうしたチェックをやりやすくする一つの方法としてお勧めなのが、一度自分の理解をツリー構造で整理してみることです。　

本書でも幾度となくツリー構造で分析を整理した図が紹介されていた。

ツリー構造で書いていくと色々なメリットがあって良さそうので取り入れてみようと思う。

たとえば思考の現在地が把握しやすくなることでかなり効率よく思考を深めやすくなる気がする。（今自分は仮説1の解決策2について考えているんだな〜みたいなのが一目でわかるので狭くなりがちな思考を広げられたり、他の要素と行ったり来たりしながら思考を深めやすそう。）

あとは目的意識なく深さと広さを広げすぎるとノイズが増えそうなので構造化するのを忘れないことも大事そう。（このあたりは実際にやってみて調節するのがよさそう）

解像度を上げる対象

上げるべきは、課題と解決策の解像度

ビジネスの文脈では特に課題と解決策の解像度を上げることが重要。

（文字にするとそれはそうという感じにはなってしまうが）「解像度が足りない」と感じたときに足りないのが課題の解像度なのか解決策の解像度なのか両方なのかを分けて考えられるとよりスムーズに成果に繋がりそう。

（直感的には課題の解像度が上がらないと解決策の精度や解像度は上がらなそうに思えるので前者が前提になりそう。）

課題の選び方

このように課題や問いが重要視される理由は、良い課題を選べるかどうかで生み出される価値がほぼ決まると言っても過言ではないからです。

『イシューからはじめよ』でもイシュー度が高い課題を解くことの重要性が説かれていたのを思い出した。

そういう意味でもまずは課題の解像度を上げることが重要かもしれない。（緊急度が高く重要度が低い課題とかはぱっと解決して早く次に行きたい種類の課題なので例外かもしれないが）

書くことで考える

まず取り組んでほしいのは、「今、何が最も重要な課題だと思っているのか、それはなぜなのか」を仮説で良いから最初に書くことです。

考え抜いた「結果」を書くのではありません。書くことは思考の「過程」です。書くことで私たちは考えることができます。

ブログに記事を書いたり（まさにこの記事とかがそう）チームで何か意思決定をする際に会議資料を書いたりすることで自分が考えていることがクリアになったり、思考が深まったりすることがよくあるので最後の2文にはすごく共感した。

文字にすることの効果はかなり感じているので今後も悩んだら（というか何かを考えたいときは）書くことで思考を深めていこうと思った。

書くときの留意点

課題の解像度を「深さ」の視点で上げるための方法として「現時点での自分の課題認識を書き出す」という方法が紹介されていた。

その際のポイントとして以下のような点が挙げられていた。

（他の人に読んでもらうための）わかりやすい文章を書くという観点でも非常に参考になりそうだったので一部を引用して紹介する。

最初の書き出しは箇条書きでも構いません。ただし、より詳細に課題を検討するときには、文章として長文で書くことをお勧めします。箇条書きを使うと、論理の飛躍や矛盾などに気づきづらいからです。

箇条書きだと論理的にわかりやすい文書になるかはかなり書き手に依存すると思っているので頷けた。（自分は箇条書き自体がダメだとは思ってないが注意深く使わないと読み手の解釈が一意にならないので気をつけて使おうと思っている派）

よくあるパターンでいうと以下のようなケースがあると思う。¹

（「なので」「とはいえ」「しかし」などの接続詞が省略されることが多く、）論理的なつながりがわかりづらい
列挙された項目がシーケンスなのか選択肢なのか、AndなのかOrなのかがわかりづらい

Amazonでも会議資料に箇条書きだけで構成されたスライドを使うのは禁止らしい。²（さすがに社員全員が同一のルールを実践してるとは限らないと思うが）

なんにせよ読み手が疑問を感じたり2パターン以上の解釈ができてしまうような文章を書かないことを心がけるのがよさそう。

主語が明確な文にする　

これも抜けがちだがクリティカルな齟齬につながりやすいので気をつけたい。（自分の場合はどちらかというと口頭で話してるときに抜けがちかも）

動詞を入れる　──　体言止めではなく、動詞を入れるようにしましょう。

体言止めも読み手に解釈の余地を与えがちなので注意したい。

たとえば「データ移行の切り戻しは手動。」とドキュメントに書かれていた場合、「手動で行う予定」なのか「手動でしか行えない」（制約の共有）なのか「手動で行った」（完了報告）なのかが明確ではなかったりする。³

スタートアップに関するエッセイで有名なポール・グレアムも、エッセイを公開する前には必ず声に出して読み上げて、友達に話すような言い回しになっているかを確認しているそうです（４）。

普段会議資料を書くときに最後は声に出して読んでみて詰まるポイントがないかチェックしているのでこの点も共感できた。うまく話せないところは論理が飛躍していたり変な結論になっていたりするのことが多いので、仕上げとして声に出して読むのは大事そう。

ことこのブログに関しては書いた後に声に出して読んだりはしていないが良さそうなので試してみようと思った。

深める

事例のサーベイが十分できているかどうかの閾値は、関連事例を「１００」程度知っているか

（起業ではなく）ソフトウェアエンジニアリングの場面では必ずしも100個必要とは限らないが、他社の事例を知っておくと引き出しが増えるので、知っておくに越したことはないと思う。

たとえばソフトウェアアーキテクチャのパターンやディレクトリ構成などは書籍やテックブログ、登壇資料で数多く紹介されているのでそういったアウトプットから学べるとよさそう。普段自分が仕事で関わっている領域ではゼロから何も見ずに自分で考えることに価値があるというよりは、効果的な施策や判断に価値があることが多いので重要な意思決定をする際には適切な情報収集をできるとよさそう。

また、そうしたネット上の資料は無料で公開されていることが多く、そうした環境にかなりお世話になっている自覚があるので自分もアウトプットを続けて少しでも業界、エコシステムに恩返しをしていければなと思う。

不慣れな分野のキャッチアップ

本屋に行って、端から端まで本を買う　事例のサーベイがある程度終わったら、次は大きめの書店に行き、自分の課題に関連する業界の本を端から端まで買うことをお勧めします。

著者によって異なる視点から同じ物事を見ることができますし、重複しているのなら、その情報は誰の目から見ても重要だということが分かります。そうして業界の構造やトレンドを深掘りしていくのです。

特に不慣れな分野に飛び込むときにはこのような方法は効果的そう。

同じような内容の書籍は1冊読めばいいのでは？と思っていたが複数の著者で共通した内容がある場合はその内容の重要性が担保されるという観点はなるほどと思った。

教える

教える　対話や質問のさらに一歩先の言語化として、教えるがあります。今考えている課題について、よく知らない人に教えるつもりで話してみましょう。

自分がブログを書いている理由の1つ。あまり人に教えられるような書き方まではできていないが、先の引用でもあったように書くことを通して理解や思考を深められている。社内外の勉強会での登壇などもこれにあたりそう。

コミュニティに参加する

コミュニティに参加すると、深く考えるためのヒントや、情報をもらえます。それに、誰かが近くにいることで、必然的に言語化や壁打ちの機会が生まれます。

これまであまりコミュニティには参加してこなかったが、今年はGoの知識を深めたいのでチャレンジしてみようと思った。（さっそく2/21のGo Conference mini in Sendai 2026に行ってみることにした）

まとめ

主に起業家や起業家を志す人に向けて書かれているように感じたが、いちソフトウェアエンジニアとしても参考になる部分が非常に多く、読んでよかった。

解像度を上げるための4つの視点「深さ」「広さ」「構造」「時間」は非常に有用なフレームワークだと感じたのでしばらくは意識的に使ってみようと思う。

この箇条書き複数パターンの例示であることが伝わっている…と信じたい。 ↩︎
https://forbesjapan.com/articles/detail/38119 ↩︎
文脈を読めばわかるだろという意見もあるかもしれないが、可能な限りローコンテキストに記述することで読み手の認知負荷低減に繋がり、結果としてコミュニケーションコストを下げられると考えています。 ↩︎

『CQRS Documents by Greg Young』を読んだ

Mon, 12 Jan 2026 00:27:58 +0900

CQRSに興味があったのでGreg Young氏のCQRS Documentsを読んでみた。

https://cqrs.wordpress.com/wp-content/uploads/2010/11/cqrs_documents.pdf

CQRSに興味を持ったきっかけ

ドメイン層のメンテナビリティの重要性を感じる中で、ドメイン層は書き込み系の振る舞いだけを担い、読み取り系の責務は別のモジュールに移譲してしまった方がドメイン層をシンプルに保てて良いのではないかと考えるようになった。¹

それってCQRSってやつじゃね？と思ったのでまずは原典に近いドキュメントを読んでみることにした。²

ここからはCQRS Documentsの内容をまとめていく。

“A Stereotypical Architecture”: 典型的なアーキテクチャ

“A Stereotypical Architecture"として、典型的なアーキテクチャが紹介されている。CQRS Documentsではこのアーキテクチャに対して段階的にCQRSを導入していく形で説明が進んでいく。

CQRS Documents by Greg Young P2より引用

このアーキテクチャではシステムはCRUDのみの機能を持ち、クライアントとは常にDTOを介して通信する。

おそらくクライアントがUpdateUserNameのようなエンドポイントに更新後のユーザーネームだけを渡すのではなく/userに更新後のDTOを丸ごと渡す、というようなことだと思われる。

サーバー側では受け取ったDTOをドメインオブジェクトに詰め替えてバリデーションを行い、永続化する。

このような設計ではアプリケーションサービスの責務はDTOとドメインオブジェクトの詰め替えに終始し、ドメイン層はバリデーションを主な責務として受け持つ。データの更新方法はクライアントに委ねられてしまうため、ドメイン知識の一部がクライアント側に漏れ出してしまう。

このようなアーキテクチャでは簡潔性によってオンボーディングコストが低くなるメリットがある代わりに、次のような課題が存在する。

スケーリング: 一般的なシステムでは読み取り操作は書き込み操作よりも2桁以上多い。読み取り操作から見ると非正規化されたデータ構造が適しているが、書き込み操作から見ると正規化されたデータ構造が適している。これらを単一のDBで扱おうとすると垂直スケーリングが必要になるが、垂直スケーリングには非常に高額なコストがかかる。
DDD適用の困難さ: この設計ではAPIがデータ指向のインターフェースを持つため、システム全体がCRUDの4つの動詞に縛られる。（データの更新方法がクライアントまたはユーザー側に漏れ出ておりドメイン知識をソフトウェアで表現することが難しいため）

ここまでの感想

さすがにこういったアーキテクチャのシステムは見たことがないので極端な例では…?とは思いつつ時代や場所によってはこういった設計のシステムも存在するのかもしれない。

CQRSとは

CQRSはBertrand Meyerが提唱した『Command and Query Separation Principle』にその起源を持つ。Wikipediaではこの原則を次のように説明している。

It states that every method should either be a command that performs an action, or a query that returns data to the caller, but not both.

Command–query separation - Wikipedia より引用

とあり、すべてのメソッドはCommandかQueryのいずれかであるべきであり、両方を兼ねるべきではないと説明されている。

これに対し、Martin Fowlerは以下のようにPopのような操作はCommandでありQueryでもあり、必ずしも上記の原則を厳密に守らなくてもいいのではないか、ということを述べている。

Meyer likes to use command-query separation absolutely, but there are exceptions. Popping a stack is a good example of a modifier that modifies state. Meyer correctly says that you can avoid having this method, but it is a useful idiom. So I prefer to follow this principle when I can, but I’m prepared to break it to get my pop. (Fowler)

CQRS Documents by Greg Young P17より引用

ここまでの感想

実際にWebサービスを開発していてもたとえばユーザー作成メソッドが作成したユーザーのIDを返すような処理は普通に書くし、自分もどちらかというと定義ほどは厳密に運用しなくても十分恩恵を受けられるのではないかという立場。

“A Stereotypical Architecture"にCQRSを導入する

“A Stereotypical Architecture"として最初に紹介されたアーキテクチャでは、ドメインモデルがCommandとQueryの両方に使用されていた。このアプリケーションにCQRSを適用するとQuery側とCommand側はそれぞれ次のようになる。

Query

Query処理側にはデータ取得のためのメソッドのみが含まれる。

元のアーキテクチャではドメインモデルを生成し、それをDTOにマッピングしたうえでクライアントに返却していた。多くの場合でドメインモデルとDTOは異なるモデルであるため、以下のような課題があるがこれがCQRSの適用によって解決される。

複数集約から1つのDTOを生成する場合、複数回DBにアクセスする必要がありパフォーマンスが低下する。また、集約の境界が曖昧になる。
ドメイン層にQueryの責務が多く含まれている（e.g. repositoryのinterfaceにQuery系のメソッドが多く含まれ、ページングやソート情報が含まれている）

After CQRS has been applied there is a natural boundary. Separate paths have been made explicit. It makes a lot of sense now to not use the domain to project DTOs. Instead it is possible to introduce a new way of projecting DTOs.

CQRS Documents by Greg Young P20より引用

とあるように、CQRSを適用することでCommandとQueryの処理経路が明確に分離される。この段階ではドメインモデルをDTOの生成に使用しない方が合理的である。

その代わりに"Thin Read Layer"という方法でDTOを生成することができる。

CQRS Documents by Greg Young P21より引用

この層はDBから直接データを読み取り（ドメインモデルを迂回し）DTOを生成する。

こうすることで、ドメイン層からQueryの責務を切り離すことができ、ドメイン層の純度を上げることができる。

Command

CQRSを適用するとCommand側のアーキテクチャは以下のようになる。

CQRS Documents by Greg Young P22より引用

元のアーキテクチャでは書き込み系の処理をする際もDTOをクライアントから受け取っていたが、CQRS適用後はデータ中心ではなく振る舞い中心の契約を採用している点と読み取り処理が分離されている点が大きな違い。（元のアーキテクチャでは書き込み時にクライアントからDTOを渡していたが、ここではメッセージが渡されるようになっている）

また、元のアーキテクチャでドメイン層に存在していた次のような課題が解決されている。

リポジトリに大量の読み取りメソッドが存在する
DTO構築のためにドメインオブジェクトの内部状態を公開するゲッターメソッドが存在する
DTO構築のために複数の集約オブジェクトをそれぞれ読み込むことで、非効率なクエリが実行される

ドメインイベント、イベントソーシング

本文にはドメインイベント、イベントソーシングについても記載があり読んだがここでは割愛。

ここまでの感想

ドメイン層からQuery系の責務を切り離すことでメンテナビリティが向上する、というのが自分が（直近）CQRSに興味を持っていた一番の理由だったのでそうだよなーと思いながら読んだ。

また（書いてあるとおりだが）読み取り単位を必ずしもドメインモデル単位にする必要がないためパフォーマンスの最適化が行いやすい点も大きなメリットだといえそう。

結局CommandとQueryはまったく別の責務なことが多いので両者を分離することでメリットを得られるケースは多そう。

作業習慣の違い

CQRS Documentsを読むまでは意識していなかったが、CQRSを採用することで

ドメイン層
リードモデル
クライアント

の3つの要素に分解して作業を進めることができるため、プロジェクトに関わる開発者数をより効果的に増やすことができる。（サーバーとクライアントの作業分担をできるのはCQRSかどうかにかかわらないが、重要なのは1つのサーバーアプリケーションを2並列で安全に進めやすいという点だろう。）

また、開発者には次のような観点の差異が存在する。

技術的熟練度
ビジネスドメインに関する知識
コスト
ソフトスキル

ドメイン層の実装には4つすべての項目が秀でた人材が最適である一方、リードモデルの実装にはそれらの開発者要件は必ずしも当てはまるとは限らない。

ここまでの感想

開発効率の観点は持ってなかったが、たしかにCQRSを採用することで（1つのアプリケーションが2つのモジュールに分離されるので）コンフリクトせずに開発を進めやすそう。（モジュール設計はプロジェクトによるので厳密には2つのモジュールとは限らないが）

感想

事前のイメージ通り、CQRSを適用することで開発効率を高められそうなイメージが持てた。

CQRS Documents内でも触れられていたが、結局CQRSにしろイベントソーシングにしろ一定のオーバーヘッドはあるので、システムやビジネスの課題や要件、今後の見通しを元に必要性を検討するのが（いつだって）重要そう。

というのはありつつ、ドメイン層のメンテナビリティを高めるためにCQRSを採用するのはかなり有効な選択肢の1つだとも感じているので、ひとまず個人のプロジェクトで検証してみたいと思う。

もちろんアプリケーションの状況にもよるが…。repositoryのRead系メソッドの返り値がドメインモデルと一致しないケースが多くなるような場合では特にCQRSのメリットが効果を発揮しやすいような気がしている。状況にかかわらずCQRSをやったほうがいいのかどうかはまだあまりわかっていない。ちなみにここでのCQRSは基本的には同一DBでCのアプリケーションコードとQのアプリケーションコードが分離されている、くらいの方法をざっくり想定して書いている。（CとQでDBを分けるパターンは流石にtoo muchなケースが多そうなので） ↩︎
厳密にこのドキュメントが原典であることを確認したわけではない。正確な情報をお持ちの方がいたら教えて下さい。 ↩︎

2025年を振り返る

Tue, 30 Dec 2025 12:00:00 +0900

年の瀬なので1年を振り返る。

OSS

PR

GitHubとGerritで55件のPR¹を作成し49件のPRがマージされた。(GitHub² Gerrit)

去年の数字が以下だったのでPR作成数、マージされたPR数ともに微増した。

49件のPRを作成し43件のPRがマージされた。

PR一覧は以下のような感じ。³

機能追加

ドキュメント関連

バグ修正

derailed/k9s - feat(pulse): map hjkl to navigate as help shows

CI、開発環境等の変更

翻訳

rust-lang/surveys - [Japanese] replace “prioritising work” with “problems to productivity” in 2024 survey

自作ツールのbrew release関連

寄付

この記事を書いたときから継続してNeovimとratatuiに5$/monthずつ寄付し続けている。

GitHub Sponsorsの寄付先にratatuiを追加した

OSSへの寄付の月予算を$10にした - laiso こちらの記事で寄付するOSSプロジェクトの選び方として次のような基準が紹介されていた。寄付するプロジ

https://blog.kyu08.com/posts/renew-oss-sponsoring/

だいたい累計$150くらい寄付したことになる。少しでも長く持続してくれると嬉しいのでこれからも続けていく。

振り返り

去年と同じくらいのペースでPRを送ることができた。（平均約4.5件/月ペース）
LazygitのトップページのContributors一覧に表示されるようになった。
- GitHubではcommit数が多い順に12人目くらいまでのアイコンがContributorsに表示される。
- 細々とcontributionを続けたところの9番目にcommitが多い人になれた。（2025/12/23現在）
- しばらくはこれを目標にlazygitへのcontributionを続けていたので嬉しい。
- CIの修正やGoのバージョンアップなど、地味めなPRがメインだったがいくつか機能追加PRもマージしてもらえた。（branchパネルで-を押すとgit checkout -相当のことができる機能とエラー内容をクリップボードにコピーできるようにする機能）
GoWikiへのcontributionに際してGerritを初めてつかった。
- GitHubとかなかなかメンタルモデルが違う感じだったので結構手間取った。
- 参考になったリソースなどをいつか記事にしたい。

OSSメンテナに感謝されるのは嬉しいし、見つけた問題を自分の手で解決するのも楽しいので引き続きやっていきたい。

社内でもOSSは楽しいぞーという話を何回かしたところ、それをきっかけにしてOSS貢献にトライしてくれる方が何名かいたのも嬉しかった。

個人開発

fzf-make

GitHub - kyu08/fzf-make: A command line tool that executes commands using fuzzy finder with preview window for make, npm, pnpm, yarn, just and task.

A command line tool that executes commands using fuzzy finder with preview window for make, npm, pnpm, yarn, just and task. - kyu08/fzf-make

https://github.com/kyu08/fzf-make

タスクランナー側で定義したコマンドをfuzzy finder形式で選択できるCLIツールを趣味でRustで開発している。

現在は以下のタスクランナーに対応している。

make
pnpm
yarn
just
task

gifを見てもらえれば分かる通り、プレビューウィンドウでコマンド内容を確認しながらコマンドを選択できるのが特徴の一つ。

スター数

2025/12/23現在では245スターを獲得している。

Star Historyによると2024/12/19時点では129スターだったので1年で大体倍くらいになった。🎉

来年も適度なペースで細々とメンテしていきます。(npm対応は早めにやりたい…！)

今年の変更点

2025年は筆者が74件のPRを作成&マージし、12個のバージョンがリリースされ、筆者とrenovateを含めて5人の貢献者により102のcommitが追加された。

TUIツールを個人開発をしているとなかなかユーザーの存在を感じづらいので昨年に引き続きissueを立てたりPRを送ってくれたりTwitterで言及してくれる方がいてとても嬉しい。🙏

もちろん使ってるよー！と言ってもらえるだけでも大変うれしいです！ぜひスターもお願いします！

今年行った主要な機能追加は以下の通り。

コマンドに引数を渡せるようにする@v0.58.0
go-task/taskをサポート@v0.60.0
コマンドのコピー機能を追加@v0.66.0

来年こそはnpm対応を入れたい。（npm対応のPRを送ってくれている方がいるので早ければ年始くらいにはリリースできるかもしれない）

sunaba

これまで素振り用のrepositoryはトピックごと（触りたいライブラリや読んでいる本など）ごとに作成していたが、まとめて管理したくなったので素振りごった煮repositoryを作成した。

GitHub - kyu08/sunaba: Personal sandbox

Personal sandbox. Contribute to kyu08/sunaba development by creating an account on GitHub.

https://github.com/kyu08/sunaba

今までは都度repositoryを作成していたが、ディレクトリを作成するだけでよくなったので若干楽になった。

ブログ

書いた記事

今年は14本の記事を書いた。

本を読んで記事を書くことで理解や記憶への定着が捗っている気がするので来年も適度にやっていきたい。

ブログの変更

今年はブログのデザインや仕組みについてもいくつか変更を加えた。

OGPを動的生成するようにした
Heading要素のデザインを変えた
プレビュー環境を整えた
ブログカードの表示

OGPの自動生成

CIで記事のタイトルを読み取ってOGP画像を自動生成 + commitするようにした。

Add dynamic OGP image generation by kyu08 · Pull Request #239 · kyu08/blog

close #238, close #120 Add satori and @resvg/resvg-js for OGP image generation Create OGP generation script that reads post metadata and generates images Add OGP template with dark theme design (b...

https://github.com/kyu08/blog/pull/239

こんな感じの画像が自動生成される。

Twitterで投稿したときに追加されるタイトル要素とOGPのメタ情報が被らないようになっているのが地味なこだわりポイント。

ついでにこんな感じでPRにコメントとして表示されるようにしたので投稿前に確認できる。（日本語だとたまーに特定の記号などが豆腐になってしまうのチェックしておきたい）

Heading要素のデザインを変えた

これまではレベルの異なるHeading要素の区別が付きづらかったので## OSSのようにHeading要素のレベルに合わせて#が表示されるデザインにした。

BEFORE
AFTER

@voluntasさんのこのツイートをみていいなーと思ったので真似してみた。

プレビュー環境を整えた

PRコメントにプレビュー環境のリンクが投稿されるようにした。出先などでも記事の推敲がしやすくなった。

PRごとにPreview環境を作成する by kyu08 · Pull Request #235 · kyu08/blog

A blog powered by hugo. Contribute to kyu08/blog development by creating an account on GitHub.

https://github.com/kyu08/blog/pull/235

ブログカードの表示

こんな感じでリンク先の情報を表示するようにした。便利。

Implement blog card link preview feature by kyu08 · Pull Request #246 · kyu08/blog

Implemented a blog card shortcode that displays rich link previews with: Automatic OGP metadata fetching (title, description, image) Manual parameter specification support Responsive design with d...

https://github.com/kyu08/blog/pull/246

読書など

読みかけのものは割愛。

タイトルからも分かる通りComputer Science、プロマネ、Kubernetes、Rustが今年の興味領域の中心だった。長期的に役立ちそう系と仕事ですぐ使える系とただ単に興味がある系をバランスよく摂取できた気がする。

特に『コンピュータシステムの理論と実装』は本当に読んでよかった。

CSを体系的に学んできていない自分にとっては論理回路を始めとしたハードウェアや、アセンブラ、コンパイラ、OSなどのソフトウェアの解像度を上げられたという意味で貴重な経験だった。（手を動かす分時間はかかったが）

ひとまずRust欲が落ち着いたので来年はComputer Science系をやりつつ、Goの深堀りにも時間を使っていきたい。Computer Scienceに関してはネットワークと並行プログラミング周りを深掘ろうと思っている。

勉強会

関数型まつり2025
VimConf 2025 Small

に参加した。

関数型まつり2025に参加した

2025/06/14(土)、2025/06/15(日)に中野セントラルパークで行われた関数型まつり2025に参加した。筆者はElmやRust

https://blog.kyu08.com/posts/fp-matsuri-2025/

VimConf 2025 Smallに参加した

2025年11月2日（日）にアキバプラザ・アキバホールで開催されたVimConf 2025 Smallに参加した。こちらはノベルティ。食器とかお箸はた

https://blog.kyu08.com/posts/vim-conf-2025/

勉強になったり刺激を得られたりしてよかった。来年はGoの勉強会にも参加してみようと思う。

生活

ジム

8月からジムに通い始めた。腰が痛くなりやすいので腰痛防止が主な目的。

無事に腰痛とはお別れでき、筋肉も4ヶ月で4kg増やすことができているので引き続きやっていき。活動できる量も増えるしやはり筋肉は正義なのだと実感した。

睡眠

今年の春くらいから就寝時間が0時半くらいになった。それまでは2時とかに寝て次の日なんかボーッとするなーということが多かったのでいい感じになってよかった。

朝散歩で日の光にあたったり運動や出社で体力を使うようにしたのが自分の睡眠にはいい影響があった気がする。（たぶん）

食事

これまではリモートで働いているとよく17時前後に集中力が皆無になってしまい、ちょっとゴロゴロしてから空腹を感じてご飯を食べる、というようなことをしていた。

ある日お昼ご飯をお腹いっぱい食べたところ夕方の集中力低下タイムがなくなったことに気づいた。シンプルに夕方に血糖値的なものが下がりすぎて集中力が落ちていた模様。地味に生産性が落ちていたので改善できて良かった。

舌下治療

去年の秋頃始めた舌下治療の結果がでて今年の春の花粉シーズンは例年よりも楽だった。

来年はもっと楽になることを期待。

サッカー

今年からJリーグ（カップ戦も含む）観戦にいくようになった。

非日常でめっちゃ楽しい。

仕事

転職し、2/1から新しい職場で働きはじめた。

プロダクトがたくさんのお客様に価値提供をできている実感があり、モチベーション高く働けている。

また、上期に関わったプロジェクトがうまくいき、MVPを受賞することができた。

会社全体としても好調なのでより一層事業成長に貢献していけるように全方面で頑張っていきたい。

技術的には引き続きGo、Google Cloud、Spannerなどを触っている。

このブログではあまり会社について詳しく話せていませんが、エンジニア採用を強化中ですので少しでも興味を持ってくれた方はTwitterのDMとかで連絡をください。ご飯やカジュアル面談などの調整をさせていただきます。（もちろんDMで聞きたいことを聞いていただいても大丈夫です）

Engineer Entrance Bookにもかなり詳しく情報がまとまっているのでぜひご覧ください。🙇

2026年の抱負

事業成長により貢献する
GoとComputer Scienceの理解を深める

おわりに

2026年もやっていき。

過去の振り返り記事はこちら。

便宜的にPRと表記しているが、GerritではCL(たしかChange List)と呼ばれる。 ↩︎
Ownerが自分以外のPublic Repositoryを対象に集計。 ↩︎
https://gist.github.com/kyu08/138f8d15c2badc8243ca2e126545ca36 を使って集計した。 ↩︎

Gerritで自分が作成したCL一覧を確認する方法

Thu, 25 Dec 2025 00:17:02 +0900

年末の振り返りを書いていて自分が作成したCL一覧が見たくなったときに地味に迷ったのでメモしておく。

tl;dr

以下にアクセスする。

<repo-url>/q/owner:<your-email>

こんな感じで表示される。

たとえばgoのrepositoryだったらhttps://go-review.googlesource.com/q/owner:<your-email>のような感じ。

以降はおまけ。

経緯

ここから行けるか…?とか思ったが…

マージ済みが表示されそうな項目はRecently closedしかないが、これだと最近のCLしか見れなさそうだった。

検索ボックスに打ち込むクエリを試行錯誤したところ冒頭の指定方法を見つけた。

GitHubと違ってrepository横断で検索できないっぽいので複数のGerrit repositoryから活動を集計するのは大変そう。（調べてないだけでやり方はあるのかもだが）¹

GitHubと違ってrepositoryごとにそれぞれでホスティングされてそうな雰囲気を感じるので直感的には難しそうではある。 ↩︎

『RustによるWebアプリケーション開発設計からリリース・運用まで』を読んだ

Mon, 22 Dec 2025 00:13:06 +0900

『RustによるWebアプリケーション開発設計からリリース・運用まで』を読んだので感じたことをメモしておく。

『ＲｕｓｔによるＷｅｂアプリケーション開発　設計からリリース・運用まで』（豊田　優貴,松本　健太郎,吉川　哲史）　製品詳細　講談社

★Rustによるアプリケーション開発のベストプラクティス！　Rustを現場で使うときがきた！ Rust経験豊富な筆者が、貴重な知識とテクニックを惜しみなく伝授。「蔵書管理アプリケーション」の実装を通じて、Rustによる設計、開発、保守、運用までをハンズオンで学ぶ！コードも丁寧に解説。【目次】第1章　本書で開発するもの第2章　開発環境の構築第3章　最小構成アプリケーションの実装第4章　蔵書管理サーバーアプリケーションの設計第5章　蔵書管理サーバーの実装第6章　システムの結合とテスト第7章　アプリケーションの運用第8章　エコシステムの紹介

https://www.kodansha.co.jp/book/products/0000398182

モチベーション

Rustという言語の開発体験がかなり好きでRustでサーバーサイドを書くのがどんな感じなのか純粋に気になっていたので読んでみた。（筆者がサーバーサイドの開発でガッツリ書いたことがあるのはほぼGoのみで、RustはCLIやTUIの開発にしか使ったことがないというバックグラウンド）

本書の概要

本書はRustで蔵書管理アプリケーションのサーバーサイドを実装しながらRustでのWebアプリケーション開発の仕方を学ぶことができる本。

ただ動くものを作る、というよりは業務の実際のサーバーサイドの開発でよく出くわす課題をRustではどう実装するのかが豊富に紹介されている。(DIやエラーハンドリングなど)

設計面ではレイヤードアーキテクチャを採用しており、レイヤー間の責務などが考慮された設計になっている。その意味でも実務での開発に近い内容になっていると言える。

あとはステップごとのコード差分が丁寧に書かれているので、本書に従って実装を進めるとWeb Serverの実装が出来上がる（はず）。¹

学び

コンパイル時間短縮の工夫
- アプリケーションを複数のクレートに分割することで変更があったクレートだけ再コンパイルすればよくなるためコンパイル時間が短縮できる。
- たとえば本書ではレイヤードアーキテクチャのレイヤーごとにクレートを分割していた。
Web開発で有用なクレート
- derive_new: new関数を実装してくれる。デフォルト値の設定などもできる模様。
- serde: 言わずと知れたシリアライズ/デシリアライズのためのクレート。
- sqlx: SQLを型安全に扱うことができる。
エラーハンドリングの方法
- クライアントに返すエラーはthiserrorで定義し、それ以外のエラーはanyhowを使って表現する。
RustでどうDIを実装すべきか
- ジェネリクスを用いてDIするパターン（静的ディスパッチ）
  - 動的ディスパッチと比較すると記述量が増える
  - 動的ディスパッチと比較するとパフォーマンスが高い
- トレイトオブジェクト（dyn <トレイト名>）を利用するパターン（動的ディスパッチ）
  - 静的ディスパッチと比較すると記述量が減る
  - 静的ディスパッチと比較するとパフォーマンス面で不利
  - 本書ではWeb開発において動的ディスパッチのコストが問題になることは少ないことを理由にこちらを採用していた。

実際にRustでWeb Serverを書いてみた感想（主にGoとの比較）

※なお、筆者のRustスキルは趣味レベルなのでRustを深く理解したうえでの感想ではありません。間違っている点や他の重要な観点などがある可能性があります。また、主には個人的な考えのスナップショットを自分用に残す目的で書いているので説明を端折っている箇所がある可能性があります。

ポジ

enumやパターンマッチ等を使って仕様をスマートに書ける。
null安全なので他の言語のnull相当の概念を型安全に扱うことができる。
if式を始めとした関数型ライクな言語機能のおかげで開発体験が良い。
変数がデフォルトでimmutableなので、mutableな変数を目立たせやすいし、自然とimmutableなコードが書きやすい。
あらゆるシンボルがデフォルトでprivateなのでカプセル化するようなコードが若干書きやすい。（意識的にpubを付けなければprivateになってくれる点で強い理由がなければprivateになりやすくなる、と考えている）

ネガ

コンパイル時間が長い。
コンパイル時間短縮のためにcrate分割が推奨されているが、依存関係の増減があるたびにCargo.tomlを手書きで編集しないといけないのが若干面倒。
- もしかしたらコードアクション等、エディタの支援が得られるのかもしれないがそこまで調べられていない。

Goに慣れているとRustのマクロやアトリビュートが若干黒魔術的に感じる。これらに慣れるまでは認知負荷が高そう。例えば以下。（『RustによるWebアプリケーション開発設計からリリース・運用まで』より引用）

#[derive(Error, Debug)]
pub enum AppError {
    #[error("{0}")]
    UnprocessableEntity(String),
    #[error("{0}")]
    EntityNotFound(String),
    #[error("{0}")]
    ValidationError(#[from] garde::Report),
    #[error("トランザクションを実行できませんでした。")]
    TransactionError(#[source] sqlx::Error),
    #[error("データベース処理実行中にエラーが発生しました。")]
    SpecificOperationError(#[source] sqlx::Error),
    #[error("No rows affected: {0}")]
    NoRowsAffectedError(String),
    #[error("{0}")]
    KeyValueStoreError(#[from] redis::RedisError),
    #[error("{0}")]
    BcryptError(#[from] bcrypt::BcryptError),
    #[error("{0}")]
    ConvertToUuidError(#[from] uuid::Error),
    #[error("ログインに失敗しました")]
    UnauthenticatedError,
    #[error("認可情報が誤っています")]
    UnauthorizedError,
    #[error("許可されていない操作です")]
    ForbiddenOperation,
    #[error("{0}")]
    ConversionEntityError(String),
}

DIが若干複雑
- Goならinterface使うだけなので考えることが少なくて済む。
非同期処理
- これもRustの非同期処理の仕組みへの理解²が大変浅いのであまり具体的に書けないが、自分の現状のRustスキルだとGoに比べて意図通りに動く非同期処理を書くのに数倍時間がかかる。

まとめ

本書を読むまではRustがWebサーバーサイド開発の銀の弾丸、とまでは言わないもののかなりいい選択肢の1つのように思えていた。主に型の表現力のおかげでドメインがうまく表現できたり、所有権などの言語機能や発達したリンターによって内部品質を高く保つことができ、その結果開発生産性が高まると考えていた。

しかし実際に本書でRustでサーバーを書いてみると上記のメリットはありつつも意外とRustでの実装でも手間や複雑なポイントがあり、Goのシンプルさや手軽さの良さを改めて認識した。

結果はともあれ実際にRustでサーバーを書くのがどんな感じなのかを知ることが本書を読んだ目的だったので解像度を高めることができてよかった。³

5章の途中までしかやっていないので「はず」と書いている。 ↩︎
あるいは単にコンピュータの仕組みへの理解が浅いとも言えるのかもしれない。 ↩︎
もちろんもっとDeep Diveしたら違う感想を持つかも知れないが、あくまで今時点の自分の感想としては上記のような感じ。 ↩︎

『コンセプトから理解するRust』を読んだ

Mon, 15 Dec 2025 19:21:35 +0900

Rustのことをもっと理解りたくて『コンセプトから理解するRust』を読んだ。

コンセプトから理解するRust | 技術評論社

Rustはメモリ安全、スレッド安全を保ちつつ、高パフォーマンスなプログラムを開発できるプログラミング言語です。また、手続き型、オブジェクト指向型、関数型でのプログラミングに対応できるマルチパラダイムの言語でもあります。ただ、そういったRustのポテンシャルを引き出すには、所有権やライフタイム、ジェネリクスやトレイトといった特徴的な仕様の理解が求められ、これらは初学者の壁にもなっています。本書ではそれら難解な仕様をピックアップし、他のプログラミング言語とコードレベルで比較しながら、「なぜそのような仕様になっているか」という言語のコンセプトからRustの理解を試みます。加えて、Rustのこまやかなエラーメッセージを読みつつ、Rustをうまく書くための知識もお伝えします。

https://gihyo.jp/book/2022/978-4-297-12562-2

前提

筆者のRustの知識はTour of RustやThe Rust Programming Languageを読んだり簡単なツール¹を作ったことがある程度で、非同期処理をスラスラ書けたり、スムーズに人に教えたりできるレベルではない。

過去にThe Rust Programming Languageを読んだときもスマートポインターまわりなどは飛ばしつつ読んでいたので本書での学びは多かった。

学び

Boxについて理解した。
Rc, RefCell, Weak周りをなんとなく理解した。たぶん空では書けないが、エラーになったら調べて解決できるくらいの理解にはなったはず。
トレイト境界についてちょっとわかった。
クロージャ, Fn, FnMut, FnOnceについて理解できた。
簡単な非同期処理の仕組みがわかった。

今まで全然わかっていなかったこれらの概念が少しだけわかった。やはりコードを書き散らかすだけでなく体系的なインプットも大事…。（それはそう）²

おそらく今後Rustを書いたりコンパイラと対話したりしていくともう少し深く理解していけると思う。³

全体を通してコード例が豊富だったので手元で動かしながら理解しやすくてとてもありがたかった。

まとめ

Rustの力がまた少しついた。

Rustを学ぶとRust自体への理解が深まるだけでなく、少なからずコンピュータの仕組みに近い低レイヤな部分の理解も一緒に深まるので勉強になる感覚があって楽しめた。

非同期処理周りはあまりちゃんと勉強したことがないので次はこの本を読んでみようと思う。（サンプルコードが主にRustで書かれているらしいのでこの本での学びも活かせそう）⁴

並行プログラミング入門

複数のプログラムを同時に実行する「並行プログラミング」は、処理速度を飛躍的に向上させる手法で、タスク管理、プロセス管理、スレッド管理をはじめ、複雑な仕組みについての幅広い知識とテクニックが必要となります。本書はRustとアセンブリ、そして一部Cを用い、CPUのアトミック命令、グリーンスレッド、アクターモデル、π計算、ソフトウェア・トランザクショナルメモリ、async/awaitなど、並行プログラミングに関する理論的な背景から実装までをカバー。さらに、アセンブリ実装の理解を深めるため、AArch64とx86-64アーキテクチャの説明も付録として収録。一歩一歩、着実に理解できるように、その仕組みから順を追って詳しく説明します。GitHub上で公開されているソースコードを実際に動かしながら、並行プログラミングの知識と理解を深めることができます。

https://www.oreilly.co.jp/books/9784873119595/

おまけ

The name “Tokio” is derived from Tokyo and mio, and the Tokio logo vaguely resembles the city emblem of Tokyo.

https://en.wikipedia.org/wiki/Tokio_(software)

Rustの非同期ランタイムのtokioの名前の由来の一部は東京らしい。

あとロゴも東京都の紋章を彷彿とさせるデザインになっているらしい。（実際調べてみたら似ているというかほぼ同じだったw）

fzf-makeというTUIツールを書いている。あとそういえばnand2tetrisもRustで書いていた。 ↩︎
趣味のプログラミングなのでRustを覚え始めた頃は楽しさ優先でまあ動けばOKという気持ちで書いていたが最近になってちゃんと理解したくなってきたので学んでいる。 ↩︎
あるいは各種概念を自作するという選択肢もあるかもしれない。Arcとか非同期ランタイムとか…。 ↩︎
他には詳解 Rustアトミック操作とロック、Async Rust 、RustによるWebアプリケーション開発　設計からリリース・運用まであたりもとても気になっている。 ↩︎

『つくって、壊して、直して学ぶ Kubernetes入門』を読んだ

Wed, 10 Dec 2025 00:04:41 +0900

0からKubernetesのキャッチアップがしたくて、高橋あおいさん著の『つくって、壊して、直して学ぶ Kubernetes入門』を読んだ。

つくって、壊して、直して学ぶ Kubernetes入門 | 翔泳社

動かなくっても、もう怖くない！トラブルシューティングを体験しながら学ぶ、実践的入門書。本書は、Kubernetesの実践的な知識をハンズオン形式で解説する書籍です。本書の特徴は、壊れにくいKubernetesをあえて壊しながら学ぶことで、初心者が挫折しやすいトラブルシューティングの知識や対応力が身に付けられることです。初心者でも、経験者でも、今度こそKubernetesがわかる！マンガや図解を多く掲載しているため視覚的に理解したい方にもおすすめです。・つくって、壊して、直して学ぶ - DockerfileからDockerコンテナをつくる - Kubernetesクラスタ上にアプリケーションをつくって、壊す - Serviceを壊す - kubectlでデバッグする - OutOfMemoryを発生させて、直す　... ・Kubernetesの構築、運用だけでなくオブザーバビリティも解説トラブル解決にむけてより多くの情報を得るための「オブザーバビリティ」、そしてトラブルを検知するための「モニタリング」についても説明します。・豊富なイラストとマンガで見てわかる章ごと、ハンズオンごとに導入マンガを掲載し、視覚的にも学習内容を理解できるようにしています。むずかしい概念もイラストで丁寧に図解してあります。 Part 1：つくってみようKubernetes Chapter 1　Dockerコンテナをつくってみる Chapter 2　Kubernetesクラスタをつくってみる Chapter 3　全体像の説明 Chapter 4　アプリケーションをKubernetesクラスタ上につくる Part 2：アプリケーションを壊して学ぶKubernetes Chapter 5　トラブルシューティングガイドとkubectlコマンドの使い方 Chapter 6　Kubernetes リソースをつくって壊そう Chapter 7　安全なステートレス・アプリケーションをつくるために Chapter 8　総復習：アプリケーションを直そう Part 3：壊れても動くKubernetes Chapter 9　Kubernetesの仕組み、アーキテクチャーを理解しよう Chapter 10　Kubernetesの開発ワークフローを理解しよう Chapter 11　オブザーバビリティとモニタリングに触れてみよう Chapter 12　この先の歩み方

https://www.shoeisha.co.jp/book/detail/9784798183961

そもそものモチベーション

今年の2月から仕事でKubernetesを使い始めたが、普段はk9sを使ってデプロイが完了したかどうかを確認するくらいでそれ以上高度なことは全然できていなかった。

そんな状態なのでトラブルシューティングや運用を独力で全然できないことに課題感を感じていた。

新しい技術を学ぶときは手を動かしながら学ぶのが好きなのでこの本を手に取ってみた。

特徴

本書は、Kubernetesの実践的な知識をハンズオン形式で解説する書籍です。本書の特徴は、壊れにくいKubernetesをあえて壊しながら学ぶことで、初心者が挫折しやすいトラブルシューティングの知識や対応力が身に付けられることです。初心者でも、経験者でも、今度こそKubernetesがわかる！

マンガや図解を多く掲載しているため視覚的に理解したい方にもおすすめです。

という書籍説明の通り、ハンズオン形式でKubernetesを学ぶことができる。

また、Kindというツールを使ってローカルでKubernetesクラスタを構築するのでクラウドの登録や課金を気にする必要がないのも手軽でよかった。

GitHub - kubernetes-sigs/kind: Kubernetes IN Docker - local clusters for testing Kubernetes

Kubernetes IN Docker - local clusters for testing Kubernetes - kubernetes-sigs/kind

https://github.com/kubernetes-sigs/kind

1つ1つの解説はそこまで文量がないので結構サクサク進めることができる。なので本書でKubernetesの全体感を本書で学び、深く学ぶのは別のリソースで補うのがよさそうだと感じた。¹

誤解のないように書いておくと、自分のようなKubernetes初心者にとっては各リソースの説明の文量が多すぎないお陰で短期間で全体感を把握できてとてもよかった。(気になったところは別途公式ドキュメントやLLMを使って深堀ったりした)

こんな雰囲気。漫画があって文量も多すぎず読みやすい。

商品ページより引用

以下の画像のように実行すべきコマンドとその結果がどうなるかが書いてあるのでKubernetesの経験が少なくても進めやすい。（実際自分もほぼ知識0で臨んだ）

商品ページより引用

こんな感じでk9sを常時起動しながらコマンドを実行するスタイルで進めたところリアルタイムでPodの変化が見れて理解が捗った。

GitHub - derailed/k9s: 🐶 Kubernetes CLI To Manage Your Clusters In Style!

🐶 Kubernetes CLI To Manage Your Clusters In Style! - derailed/k9s

https://github.com/derailed/k9s/

学び

kubectlの使い方
Pod、Service、Deploymentなどの基本的なリソースの性質や動かし方
Readiness probe, Liveness probe, Startup probeの特徴や使い方
Resource Requests/Limits, HPA, Affinity, HPA, VPAなどの性能やスケールなどに関する機能の使い方
Kubernetes自体のアーキテクチャ
etc.

感想

0からKubernetesの基礎を学ぶことができてとても良い本だった。
ちょうど仕事でmanifestを書くタイミングがあったので本書で学んだことがダイレクトに活きてとても助かった。物事の解像度が上がるのはいつだって楽しいな〜と再確認した。²
次はしばらく積んでしまっていた『体験しながら学ぶネットワーク技術入門』をやっていく。

本書後半でも紹介されているが本で詳しく学ぶならKubernetes完全ガイド第2版がいいらしい。 ↩︎
たとえばリクエストが全然きてないマイクロサービスのPod数が一瞬2倍になっているグラフをみて、maxSurge: 100%でRollingUpdateしてるな〜と思えたりとか。 ↩︎

『デッドライン』を読んだ

Sun, 23 Nov 2025 10:43:53 +0900

少し前にTwitterで紹介されていて気になっていた¹トムデマルコの『デッドライン』を読んだ。新品で売ってるところが見つからなかったのでAmazonで中古を購入した。²

プロジェクトマネジメントをするたびにその難しさを痛感しているので知見が得られたり思考が整理できたりすることを期待して読んだ。

同著者の本だと『ピープルウエア』が有名だがそちらは未読。『ゆとりの法則』とかも面白そうなのでいつか読みたい。

というわけで参考になったところを紹介していく。（なお(P84)のような数字はページ数を示す。）

生産性の向上(P84)

短期的に生産性を高める方法などない。生産性は、長期的な投資によって向上する。

（本筋ではないが）まずこれを読んだときに手作業の自動化のためのCI/CDを整備したら短期的に生産性はあがるのでは？と思った。

が、ここでの生産性は「期間あたりのアウトプット」のことを指していて、「期間あたりのアウトカム」を指しているわけではないのかもしれないと解釈してひとまず納得した。（そもそもそんなに細かい話はしていない、またはCI/CDのような比較的すぐにできて明らかに生産性に寄与する施策はすでに実施済み、という前提はあるのかもしれない。）

なので「生産性を大きく向上させるためには長期的な投資が重要なことが多い」くらいに捉えてみる。

たしかに長期目線でチームの生産性を大きく向上させるにはチームとしての練度を向上させたり、リアーキテクティングをはじめとした技術的負債を解消したり、スキルアップを図ったりといったことが必要になることが多いように思うのでその意味では同意できる文だった。

スタートアップではリソースが限られる中で短期的にマストでやらなければいけないことをこなす必要があったりするので長期的な施策への投資バランスが本当に難しい。（とはいえ少しでも時間を見つけて長期的な施策を少しずつでも進めていくしかないか）

リスク管理(P84)

リスクを管理することによってプロジェクトを管理せよ。

それぞれのリスクの実現する確率と予想コストを評価せよ

プロジェクトマネジメントをしていると「どう不確実性を取り扱うか」というのが難しく、かつ一番重要度が高いように感じる。

プロジェクト（以下PJと表記）を進めていると様々な不確実性によってスケジュール遅延が発生し、品質が落ちたり、計画を変更してPJ期間を延ばしたり、スコープを削ったり、あるいは人員を追加したりというアクションが必要になる。（場合によっては残業が増えたりもする）

そして何より、当初の見積もりを超過するとエンジニア当人が感じるプレッシャーが増えたりモチベーションが下がったりする。（自分だけかもしれないが）

なので可能な限り見積もりからのズレを減らしたくなる。（見積もりのズレが減って悲しい人はいないはず）

今のところは可能な限り見積もりからのズレを減らすためにはこのあたりのことを意識してみている。

見積もりがズレたらその原因を分析して次回以降に活かす
そもそも見積もりという行為自体が不確実性をはらんでいることを理解する
不確実性を早期に削減することでPJ後半に手戻りや遅延が発生する確率を下げる

1.に関しては組織、人によってまちまちだと思うが最近自分が発見したズレの要因はこのあたり。

（プロマネと実装を兼任する場合に）プロマネタスクのための時間を確保し忘れていた
設計をチームに共有するための資料等の準備時間やレビュワーからもらったフィードバックを反映する時間を見積もりに含めていなかった

特にプロマネと実装者を兼務している場合、状況が変わった際のスケジュールの組み直し、タスク実行順をどうするかの検討、ステークホルダーへの報告や相談などのプロマネタスクに意外と時間がかかることを直近のPJで学んだ。

2.への対策としては2点見積もり、3点見積もりのような手法を用いたり、見積もりをレンジで表現したりすることが考えられそう。（e.g. 「7月1日にリリースできそうです」と伝えるのではなく「7月前半にリリースできそうです」のように範囲で伝える。）

PJが進むに連れて不確実性が下がっていき、見積もりの精度も上がっていくはずなので徐々にレンジも狭くなっていくはず。なのでステークホルダーに一度伝えて終わり、というよりはチェックポイントごとに最新の見積もりを伝えるのが良さそうに思う。

3.については不確実性コーンに従って不確実性が下がっていくようにPJ初期の要件定義や設計の段階で大きな不確実性を潰しておくことが重要そう。

人材管理の智将(P94)

プロジェクトの初期にむだにする一日も、末期にむだにする一日も等しく打撃になる。

一日をむだにする方法はいくらでもある…しかし、一日を取り戻す方法は一つもない。

真理みがある。真理過ぎてあまり書くことがない。

これを見て小学校のころのサッカーのコーチの「そのリフティングの1回はもう帰ってこないよ（だから集中して取り組もう）」という言葉を思い出した。

プレッシャーの効果(P200)

プレッシャーをかけても思考は速くならない。

一時的なプレッシャーや残業は、人びとの焦点を定め、その仕事が重要であるという認識を高めるには有効な方法かもしれないが、プレッシャーをかけすぎると、かならず失敗する。

自分もプレッシャーが大きすぎるとパフォーマンスが落ちるタイプなのでとてもわかりみがあった。

振り返ってみると特に明示的でないプレッシャーがあるとパフォーマンスが落ちやすい気がした。「xx月yy日までにリリースしたい」のようなものではなく「なんか上司から圧を感じる。今のままだとダメな気がする…」みたいな状態。要求（の理解）が明瞭ではないので目標が定まらず、辛い感じになりがち。（今思えば上司とコミュニケーションをとって明確にするのがよさそうではある）

残業時間を増やすのは、生産性を落とす方法である。

残業が常態化し「あとで残業すればいっか〜」というマインドになってしまうと結局日中の生産性は落ちてしまい無駄が増えてしまうので気をつけたい。

一方で昼夜問わず猛烈にコミットして成果を出しまくっている人も身の回りに複数いるので必ずしも残業が悪とまではいえない気持ちにもなっている。（あくまで今の自分がそう感じるというだけ人/時期によっては残業しないことの重要度が高まることは普通にあるとは思う）

そういえば残業の話は『世界一流エンジニアの思考法』にも書いてあったなーと思い出した。

ここでの示唆は、業務だけに自分の時間を使ってしまうと

学習によって自分の生産性を向上させることがしずらい

残業前提で成果を出すため再現性が低い

ということだと思う。残業しすぎないことで学習の時間を確保したり、開発プロセスの改善やスコープの調整によってうまく成果を出せるようにできていることが重要なのだと思う。

https://blog.kyu08.com/posts/how-world-class-engineers-think/#%E3%82%BF%E3%82%A4%E3%83%A0%E3%83%9C%E3%83%83%E3%82%AF%E3%82%B9%E5%88%B6

スタッフの人数(P259)

初期に人数が多すぎると、プロジェクトは重要な設計作業を省略せざるをえない（全員に仕事を与えるため）。設計が完成する前に大勢に仕事を割り当てると、人や作業グループの間のインタフェースを最小化できない。

このため、相互依存性が高まり、会議が増え、やり直しが増え、フラストレーションがたまる。

チームの人数が多すぎる場合、設計段階で全員にタスクをふろうとすると対象ソフトウェアへの理解が不十分な段階で人為的にソフトウェアを部分に切り分けて担当をアサインすることになる。

そのため人と人とのインターフェースが無駄に複雑化してしまい、コミュニケーションコストが増大する、ということを言っていると理解した。

そのため設計段階までは少人数で進めてタスクを切り分けられる段階まできたら人数も増やしてもよいのではないか、ということが書かれていた。

ここで得られる示唆としては

対象ソフトウェアへの理解が曖昧な状態では正しく切り分けることができない（マイクロサービス化にもいえそう）
チームの人数をいたずらに増やすべきではない

というようなことかなと思った。（生産性以外にも様々な事情があるケースもあるとは思うので一概には言えないが）

まとめ

プロジェクトマネジメントについていろいろと示唆を得られてよかった。

物語調だったので隙間時間にサクサク読みやすかった。

数冊の積読があるので年内に消化できるようにやっていきたい…。（k8s本³とかネットワークの本⁴とか）

VimConf 2025 Smallに参加した

Sun, 02 Nov 2025 01:07:08 +0000

2025年11月2日（日）にアキバプラザ・アキバホールで開催されたVimConf 2025 Smallに参加した。

こちらはノベルティ。食器とかお箸はたくさんあっても困らないのでありがたい。

お茶碗
お箸
コースター
巾着
お茶

nvim-cmp retrospective: Exploring Completion and Facing FOSS Challenges

hrsh7thさんによる発表。

Explore Completion

nvim-cmpのcmpって「シーエムピー」って読むんだ（「コンプ」って読んでた）
補完プラグインってめちゃめちゃいろんなケースを考慮して作られているんだな…（全然詳しくないので薄い感想しか出てこない）

FOSS Challenges

大きなOSSプロジェクトをメンテすることになったことでの学びの共有。

もともとはユーザーが求めるものと自分のやりたいことが合致していた。自分がやりたいことをやることで感謝してもらえていた。
- あるときから自分のやりたいこととユーザーの要望が乖離してきた
  - やりたいこと
    - コード品質を上げたい
    - 実験的な新機能を追加したい
  - ユーザーが求めること
    - 安定した動作
- 結果モチベが下がった
- 予期せずプロジェクトが大きくなって責任が芽生えた
- モチベが低いならコミュニティ主導にすればいいのでは？という意見も見るが…
  - 直接話したこともない人をrepositoryに招待するのは危険だと感じた（ユーザー数も多いのでサプライチェーンアタックが怖い）
    - 実際にhrsh7thさんが作ったプラグインのコピープラグインがリリース1週間後にできて、そこにマルウェアが含まれていたことがあるらしい（怖すぎる）
  - 新メンテナのオンボーディングをサポートするのも大変
とはいえOSS開発は楽しい
- nvim-cmpを公開して「これめっちゃ便利だね！」といってもらえたのはとても印象に残っている
- 意図せず人気になってしまうと責任も生じる

感想

たくさんのユーザーを抱えるOSSのメンテ目線のリアルな心境を聞けてよかった。

大規模OSSのメンテナに憧れる気持ちもあるが、楽しいこともあればその分大変なこともあるんだろうな〜などと思った。（それはそう）

とはいえたくさんの開発者、プロジェクトに寄与するような大規模OSSメンテナへの憧れはあるのでコミットしたいOSSが見つかったら挑戦してみようと思う。

And Yet, Vim Survived: Thinking and Seeing in the Age of Code You Don’t Write

Λlisueさんによるコードリーディングに関する発表。

以下の3stepに分けてコードを読む。

Where - Seeing the flow
What - Seeing the structure
Why - Seeing the Reasoning

Where - Seeing the Flow

File Jumps
- gf / gF - open file under cursor
- これ知らなかった。go testの結果を見て失敗しているファイルに飛ぶときとかに便利そう。
Search Jumps
- /や?で検索しnでジャンプ
fall.nvim(fuzzy finder)
- 検索してnで飛ぶのに比べて<c-o>で直前の位置に戻れるので便利
Quickfix
- ]q / [qでジャンプできる

What - Seeing the structure

Window management
- <c-w> + s/v/h/j/k/l
- <c-w> + o: （複数ウィンドウを開いているときに実行すると）現在のウィンドウのみを表示する
  - nativeだと元の状態に戻れない
- goyo.vim¹を使うと<c-w> + oをもう一度実行するともとのウィンドウの状態に戻れる。
file treeは知らないファイルを探すために使う
fuzzy finderは知っているファイルを開くために使う

Why - Seeing the Reasoning

git blameを活用してコードの背景を理解しながらコードを読む

感想

ありすえさんが発表がうますぎてその点でも勉強になった。特にこのあたりのポイントが勉強になった。

論理構造が自然で理解しやすかった
話す速度、スライドの情報量が多すぎなかったのでついていきやすかった
ユーモアを交えていて楽しく聞けた
シンプルに滑舌が良かった（わかんないけどマイクの使い方とかも違うんだろうか。なんかとにかく声が明瞭で聞き取りやすかった）

Beyond Syntax Highlighting: Unlocking the Power of Tree-sitter in Neovim

atusyさんによるtree-sitterに関する発表。

GitHub - atusy/treemonkey.nvim

Contribute to atusy/treemonkey.nvim development by creating an account on GitHub.

https://github.com/atusy/treemonkey.nvim

便利そう

tree-sitterをもっと深く理解したくなった（趣味のプロジェクトでIndianBoy42/tree-sitter-justに依存しているので自分もメンテに参加できるようになりたい）

Designing Repeatable Edits: The Architecture of . in Vim

Satoru Kitaguchiさんによるドットリピートの解説。

.でリピートできる操作
- ノーマルモードから始まってバッファを編集し、ノーマルモードに戻ってくる
- undoツリー上のlast-change nodeを再実行している = 直前の編集チャンクを再適用する
daw, ci"などはリピートできる
Visual modeを含んだ操作などはリピートできない
- Visual modeでは内部的には選択された文字数や行数しか保持されないため

さらっとVimの内部動作を解説していてかっこよすぎた。Vimのコードを読んだのか、Vimの内部構造を解説しているsomethingがどこかに存在するのかちょっと気になった。かなり周到に調査されてスライドを作られてそうな印象を受けた。

便利なプラグインの情報を集めるのも楽しいが、たまにはちゃんとVim自体の機能を学んだ方がかえって効率よく日々の操作を効率化できそうだな〜と思った。

実践Vimを読みたい気持ちが芽生えた。（n回目）

LT

ryoppippiさんの https://github.com/ryoppippi/nvim-in-the-loop がかなり便利そう。

自分のVimの操作履歴を記録し、AIにどのようなキーマップを登録すると無駄な操作を減らせるかを分析させるというものらしい。すごい。

まとめ

学びや刺激を得られたので行って良かった。

発表内容もさることながらプレゼンが上手な方がいたり、（おそらく日本の方だけど）英語が超上手な方がいたりして、その意味でも刺激を得られた。

今回初参加なので他の回との比較はできないが全然Smallな感じがせず、満足感が高かった。（もしやSmallじゃない回は2トラックとかあったりする…?）

運営の皆さん、登壇者の皆さんありがとうございました！

おそらくこれ https://github.com/junegunn/goyo.vim ↩︎

『Tidy First?』を読んだ

Sat, 04 Oct 2025 08:21:10 +0000

『Tidy First?』を読んだ。

勉強になったところをまとめる。

「整頓」という概念

整頓はリファクタリングのサブセットだ。整頓は可愛くてふわふわした小さなリファクタリングなので、誰も嫌いになれないはずだ。

リファクタリングほど大掛かりなものではなく、数十分でできるような小さな改善を本書では「整頓」と呼んでいる。

具体的にはコードコメントを追加したり適切な位置に空行を配置したり適切な変数名に変更したりすることなどを指している。

この「整頓」という概念を知ることができたのが本書を読んで得られた最大の収穫だった。今までそのような行為に名前をつけたことがなかったが名前をつけることで使い所や意義が明確になり意識的に実践できるようになりそう。

なお本書では「整頓」と「振る舞いの変更」の順番やタイミング、粒度や意義について様々な角度から書かれているので気になる方はぜひ手にとってみてほしい。

第11章ステートメントを小分けにする

大きなコードのチャンクを読んでいると、「ああ、ここはこれをしていて、あそこであれをしているのか」とわかる。そのあいだに空行を入れよう。

長めの関数を読むとき、空行がまったくないことは少ないが空行の位置を改善できそうだと感じることがたまにある。

処理の塊ごとに適切に改行されているだけでそこそこ可読性が上がる実感があるのでやってみようと思う。（空行の追加/削除のみのPRであればレビュワーの負担もかなり少ないはず）

第13章ひとかたまり

細かく分割されているがゆえに、かえって理解を妨げているようなコードに出会うことはないだろうか。

超巨大な関数はテストしづらく可読性も低いので避けたいが、逆にすべての処理を関数として切り出してしまうと毎回定義ジャンプしないと処理の内容がわからないのでかえって読みづらくなってしまう。

テストが書きやすい程度に細かくかつ可読性が落ちない程度には大きく関数を切り出すのがよさそうで、いい塩梅を探るには複数のパターンを実際に書いてみて読みやすいかどうかを判断するのがよさそう。（実際に複数パターンを書いてみると意外とすぐに書けることが多いし、しかも実際に書いてみると事前の想定とは印象が違うことが多いように思う）

小さな部品に分けようとするのは、コードを少しずつ理解できるようにしたいからだ。だが、ときには、このプロセスが間違った方向に進むことがある。小さな部品のやりとりの仕方によっては、コードが理解しにくくなるのだ。明確さを取り戻すには、まずはコードを1箇所に集めて、それから改めて、簡単に理解できる部品を抽出する。

1000行の関数でこれをやるとさすがに辛そうだが、100行前後くらいであればひとまず1つにまとめてから再構成するのはたしかに良さそう。

第14章説明コメント

コードを読んでいて「なるほど、それでこうなっているのか」と声が出ることがある。これは貴重な瞬間だ。記録しよう。

コードリーディングの結果、必要なコメントが欠けていることに気づくことがある。

そういった場面でこれまであまりPRを作ったりはしてこなかったが、説明コメントの追加も立派な整頓であり将来の読者（当然将来の自分を含む）の時間を節約することに繋がるのでやっていきたい。

説明コメントの追加PRはレビュワーの負荷が少ない割にレビュイーとレビュワーのコード理解を深められる点で比較的コスパの良い取り組みな気がした。（正確な説明コメントを書くための調査が大変、とかはあるかもだが）

第19章リズム

1つの整頓にかける時間はここでは1時間くらいまでが許容範囲とされており、それを大幅に超過するようであれば変更の単位が大きすぎる兆候らしい。

こんな話を聞いたことはないだろうか。ある大学がたくさんの建物を造った。計画者は、それを結ぶ歩道をどこに造るか考えていた。だが、そこで経験にもとづいて注意深く推測するのではなく、建物のあいだのエリアに芝生を植えたのだ。数か月後、学生の歩いた跡によって芝生に道ができた。計画者は芝生がなくなったところを舗装した。

コードにおいて、振る舞いの変更は一部に集中する傾向にある。パレートの法則にあるように、80%の変更は20%のファイルで起こる。

（計画者天才すぎワロタ…）

変更の前に整頓することを続けていくと頻繁に変更される20%のコードがどんどん綺麗になっていく、ということを言っているのだと解釈した。

そうした取り組みを続けていくとコードの大部分は手直ししてないにもかかわらず整頓していないコードに出会うことは稀になる。逆に言うと仮にコードの50%を頑張って綺麗にしたところで、その50%に変更がまったく入らないのであれば投資対効果が高いとはいえないかもしれない。（当然、コード全体が複雑に絡み合っていて一部だけ再設計することが難しい場合や全体的に変更しないと一貫性がなくなる場合などはその限りではないと思う）

なのでコードを修正する際は単純にある時点のコードベースだけを見てコード品質に改善点が見つかったというだけの理由で修正する、というよりは修正すべき合理的な理由（e.g. 内部品質が課題で問題が起きている、よく変更が入る箇所が変更しづらくなっているなど）がある箇所から対応していくのがよさそう。

第21章先に整頓、あとに整頓、改めて整頓、整頓しない

整頓を変更の前にやるか、あとにやるか、将来時間がとれたときにやるか、あるいはまったくやらないかについて論じた章。

章のまとめにもあるように結局はビジネスにとって合理的なタイミングでやるのがよい、ということなのだと思った。（言葉にするとそれはそうという感じではあるが）

「改めて整頓する」と「あとに整頓する」の区別はあまり考えたことがなかったが、整頓が完了するまでの必要工数が大きいケース以外は「あとに整頓する」に寄せるのが良さそうに感じた。

第25章明日の1ドルより今日の1ドル

お金を生む振る舞いの変更を今すぐ実装して、あとから整頓できるなら、すぐにお金が手に入り、あとでお金を使うことになる(前述のとおり、ときには先に整頓してから振る舞いを変更するほうが整頓せずに変更するよりも安価なこともある。そんな場合は常に先に整頓する)。

ビジネス的なメリットがあるならば整頓を後回しにすることが合理的になるのは十分にありえる。(e.g. 12/1までにリリースできれば大企業A社の受注に繋がるが、それを超過してしまうと競合他社と契約されてしまい、A社と契約できるチャンスが消滅してしまう)

逆に、先に整頓したほうが変更が楽になるならそうする。コードベースへの理解、ビジネスへの関心と理解（デッドラインは最終的なものなのか、調整可能なのか）、一定の設計スキルなどがあるとこの判断の練度を上げることに繋がりそう。

第26章オプション

「次にどのような振る舞いを実装できるか」は、実装する前から、それ自体に価値がある。

これはあまり考えたことがなかった。「プログラムの変更容易性は将来の実装工数を削減するために重要である」というアイディアと本質的には近いことを言ってそうだが、「価値」という切り口で捉え直すとたしかに変更容易性は価値と等価ともいえそう。

（これが最重要なのだが）価値予測の不確実性が高いほど、オプションの価値は高い（今すぐ実装するのと比べて）。

価値予測の不確実性と変更容易性の価値についてもあまり考えたことがなかったが納得感があった。たとえばよくあるSaaSモデルのプロダクトであれば探索しながら市場の反応を見たり変化に対応したりすることが必要で、そのためには変更容易性が必要なのでその価値がより高まる、ということだと理解した。

第32章凝集

凝集性が低いモジュールの改善方法についての章だが、どちらかというと章の後半に書かれていた下記の記述が参考になった。

次の人のために少しだけコードを整頓しておこう。全員がこのボーイスカウトルール(「来たときよりも美しく」)に従えば、そのうちにより扱いやすいコードになっていくだろう。

これまではボーイスカウトルールというと「触ったコードの負債をできるだけリファクタリングして綺麗にすべし」のような考え方だと認識していた（これ自体は間違いではないと思う）。

本格的なリファクタリングまではいかなくとも、本書で「整頓」として紹介されている「コードコメントの追加」や「空行の調整」なども十分ボーイスカウト的な行為なのだなと考え直して少しハードルが下がる感覚を得た。

第33章結論

本書のタイトルにもなっている、どんなときに先に整頓すべきかについてのまとめの章。

以下の4つの観点で整理して決断するとよい、と書かれている。次に判断に迷った際には参考にしてみたい。

コスト
収益
結合
凝集

まとめ

164ページと全体がコンパクトにまとまっているのと、簡潔に書かれている（かつ、翻訳もとても読みやすい）ので短時間で読みやすかった。

「整頓」 という概念を知れたのが最大の収穫だった。今後は意識的に実践していきたいと思う。

次回作の構想もあるようなので楽しみ。

追いKeychron V4 Max

Thu, 28 Aug 2025 14:24:39 +0000

Keychron V4 Max を買ったで紹介したV4 MAXはオフィス用のV4 MAXになった。あまりにも使い心地がいいので家用のV4 MAXを買い足した。

前回はキーキャップとスイッチが家に余ってたのでベアボーンを買ったが、もう在庫はないし20$足せばキーキャップがついてくるので今回はフルセットの方を買った。（どうせ赤軸は苦手だからどのみちキースイッチは買うつもりだった）

送料込みで$112.99(¥17,400 JPY)だった。

8/24に発送連絡がきて8/28に届いた。中国からの発送なのに早くてすごい。

開封してちょっと触ってみたがやはり赤軸は苦手な感じだったのでオフィスにおいてあるV4 MAXと同じくKailh Box Silent Pink軸をAmazonで買った。¹

60%で本体重量が軽めで打鍵感が良さげな既製品キーボードが意外と少ないのでディスコンになる前に買えてよかったー。²

ディスコンらしいけどなんとかまだ在庫があって助かった〜 ↩︎
たしかこのモデルも発売から2,3年経ってた気がするので買えてラッキー ↩︎

Keychron V4 Max を買った

Thu, 19 Jun 2025 14:38:21 +0000

持ち運び用に軽めの60%メカニカルキーボードが欲しくなり、いくつか検討した結果、Keychron V4 Max(Barebone)を買った。

候補

持ち運び用として考えていたので以下のような条件で探していた。

ノーマルプロファイルのメカニカルキーボード
- ロープロファイルよりノーマルな方が好みなため
重量が軽め(600g前後)
- Magi65は900gくらいあり若干重い(あと結構打鍵音がでかい)
打鍵音が大きくなさそう(スイッチにも大きく依存するが)
- オフィスでも使いたいので
ホットスワップ対応
おおよそ2万円以内
60%

最初は候補として5つのキーボードが挙がっていたが、冷静になった結果NiZとREALFORCEは価格が高かったのでやめ、CIDOO QK61 V2は重量が重めだったのでこちらも候補から外した。

機種名	重量	ホットスワップ対応	価格	技適対応	備考
Keychron V4 Max	650g	対応	$84.99	対応	ガスケットマウントで打鍵感&打鍵音がよさそう
EPOMAKER Hack59	630g	対応	¥10,700	対応	ガスケットマウントで打鍵感&打鍵音がよさそう
NiZ Atom66	?	おそらく非対応	¥32,000	?	-
REALFORCE RC1	600g	おそらく非対応	¥35,860	調べてないがさすがに対応してそう	-
CIDOO QK61 V2	880g	おそらく対応	¥11,000	?	-

最終的にはKeychron V4 MaxとEPOMAKER Hack59で迷ったが打鍵音がより静かそうなKeychron V4 Maxを選んだ。

Keychron V4 Max

KeychronのWebサイトを見ると2つのオプションがあった。

オプション	価格	内容
Barebone	$84.99	キーボード本体のみ
Fully Assembled	$104.99	キーボード本体 + キーキャップ + キースイッチ

+$20でキーキャップとキースイッチがつくのでコスパでいえばFully Assembledの方がいいが、ちょうど家にキーキャップとキースイッチが1セットずつ余っていたのでBareboneにした。

価格は送料込みで$92.99(¥14,093)だった。注文から5日後に届いた。（意外と早かった）

ベアボーンな様子。

キースイッチ、キーキャップ

キースイッチはもともと使っていたKailh Box Silent Pinkを装着した。（今は廃盤らしい…）

普段7sProに装着して使っているYushakobo Fairy Silent Linear Switchより若干重くて押してる感じが適度にあってよい。

キーキャップは家にあったKeyreative The Old Seaside ABS Cherry Profileを装着した。

なぜか光る。

使ってみた感想

ガスケットマウントのおかげか打鍵感もよいし音もうるさくないので大満足。
普段HHKB配列の分割キーボード¹を使っているので右シフトがデカくてfnキーがないのは気になっていた。が、自分の使い方だと右シフトは?を入力するときにたまに使っていたくらいだったので、思い切って右シフトをfnキーにすることで事なきを得た。
軽いが使っていて位置がずれたりすることもなく、よい。

あとちゃんと技適申請が通っていて、かつ技適マークも表示されていて嬉しい。

おわりに

円高はよ〜。

7sPro ↩︎

関数型まつり2025に参加した

Sun, 15 Jun 2025 05:00:00 +0000

2025/06/14(土)、2025/06/15(日)に中野セントラルパークで行われた関数型まつり2025に参加した。

筆者はElmやRustの開発体験を気に入っており、Webアプリケーションのサーバーサイドを関数型言語で書くことに興味があったので参加してみた。

関数型言語テイスティング: Haskell, Scala, Clojure, Elixirを比べて味わう関数型プログラミングの旨さ - lagénorhynque/カマイルカさん

lagénorhynque/カマイルカさんによるHaskell, Scala, Clojure, Elixirの紹介と比較を行う発表。

部分適用や関数合成やパイプ演算子などElmで便利だった言語機能を思い出しながら聞いていた。

文法を見ていると、Elmの文法はかなりHaskellに近いようだった。(ML系と呼ばれるらしい)

あとは関数型かつ動的型付け言語の実際のアプリケーション開発での書き味が全然想像がつかないのでちょっとElixirやClojureを書いてみたくなった。質疑応答でも触れられていたが、実際にML系の言語とlispなどの動的型付け言語の関数型言語ではメンタルモデルが違うらしい。

発表の最後に関数型プログラマのメンタルモデルとして以下のようなことを紹介されていて、自分が関数型言語から得た学びと重なる部分が多かった。

適切な制約が解放をもたらす
- 純粋関数を基本にしてコードを組み立てていく
- いつでもどこでも破壊的に更新できるデータ構造は怖いため不変/永続データを基本に
- 適切な型を定義することで不正値を表現不能にしてより型安全に
単純で安定したブロックを基礎に全体を構成したい
- 式思考、宣言的、合成可能

関数型言語を採用し、維持し、継続する - 松澤有さん

Siiibo証券株式会社のCTOである松澤さんによる自社プロダクトのフロントエンド、バックエンドの開発言語として関数型言語(Elm, Elixir)をなぜ採用したのか、そしていかにして維持し、継続しているかについての発表。実は主にこの発表を聞くために関数型まつりに参加したので良い発表を聞けてよかった。

関数型言語を採用し、維持し、継続する

https://zenn.dev/siiibo_tech/articles/adopting-fp-languages

結局はラストマンシップを持って自分がなんとかするという気概が重要だという話が一番印象的だった。これは関数型言語を業務で書いているわけではない自分にも大いに参考になる話だと思っていて、結局どんな技術を採用したかやCTOかメンバーかなどにかかわらず、このラストマンシップを持っているエンジニアが多ければ多いほど開発組織は強固になるんだろうなと思った。

また「アウトリーチを怠らなければ意外と世の中にちゃんと仲間はいる」ということをおっしゃっていて、使用言語がメインストリームであろうとなかろうと外部発信を通してコミュニティに貢献したり認知を獲得することの重要性を改めて感じた。やっていき。

総じて松澤さんのエンジニアとしてのマインドセット的な部分がとても参考になった。

技術的な内容に関しては、コードレビューの話とUpkeepの話が参考になった。

コードレビューに関しては以下のようなことをおっしゃっていて、とても参考になった。特に2番目に関しては、前提としてコード品質を重要視するマインドがチームに装備されている必要があると思っていて、それをどう実現しているのか気になった。

自分がいいと思う技術であっても、それを伝道できなければあとが続かない
チームにとって良いコードとはどのようなものか、ということを感覚、信念として共有できる状態に持っていくことを目指している
人は忘れるし、一度言っただけで身につくことは誰であれないので繰り返し伝えていくことが重要

Upkeepとは維持費の意味で、ここでは依存ライブラリや言語自体のバージョンアップなどのことを指す。こまめにバージョンアップ作業をやっておくことでいざというときに言語やライブラリの新機能をすぐ取り込めたり、巨大なバージョンアップのせいでデグレするリスクを低減できたりと良いこと尽くめだと改めて感じた。（もちろん簡単ではないが）

あとはバージョンを最新に保つという行為に名前をつけたことがなかったのでUpkeepという語で表現するのはいいなーと思った。

以下発表を聞きながら取ったメモ。(発表を聞きつつスライドを見ながら書いたメモなので誤りが含まれる場合があります🙇)

技術選定の方針

CTO, Founding Engineerが技術構成を選ぶにあたっての観点
- まともなモノを継続的に提供するに足る機能があるか
- それを実際につくるヒトを継続的に集められるか
（スタートアップなら）
- （上記2点を説得材料として）カネを集められるか

非メインストリーム言語でどうやっていくか

ElixirやElmはメインストリームと目されているとは言えず、モノ・ヒト・カネの要素を自信を持って揃えるには弱い
とはいえ、良いと感じた技術があって、良いものを作れると検証できたのであればあとは自分がやるかどうかでしかない
- 勝手に機会は降ってこない
勇気と周りを巻き込んで走り続ける力が重要

コードレビューの技術

自分がいいと思う技術であっても、それを伝道できなければあとが続かない
健全で有意義なコードレビューのやり取りがどのようなものか？という経験とその内面化が重要
どういうコードがチームにとって良いコードかを伝道する
- 感覚、信念として共有できる状態に持っていきたい
以下の理由でコードレビューで繰り返し伝えていくことが重要
- 人は忘れる
- 新しい人は入る
- 一度言っただけで身につくことは誰であれ、ない

Upkeep

Upkeepとは維持費の意味で、ここでは依存ライブラリや言語自体のバージョンアップなどのことを指す。
Upkeep恐怖症にならずにこまめにやれる環境をつくる。
(バージョンアップ作業がやりやすいのは言語の大きな加点項目)
Elixirで静的型検査の導入が2022年に発表された
- Upkeepしておくと、こういった新機能もすぐに取り込める

情報収集

言語公式フォーラム, ML, Slack, Discordのウォッチ
- そもそもコミュニティがデカすぎないので最新動向をすべて追うのがそこまで大変ではない
コンパイラ、主要ライブラリのissue trackerも購読する
- チーム内で抱えてる課題と似たような話題も出たりする
Twitter

コミュニティ還元

フォーラムでの質問を見るだけでなく回答もする
- 小さいコミュニティなので自分が第一人者、Front Runnerである可能性もある
国内外の勉強会参加、主催協力も積極的に行う

採用

やれることをやり、アウトリーチもすることが採用に直結する
非メインストリーム言語だとその言語を業務で書くにはそもそも会社の選択肢が少なかったりするので、意外とマッチングしやすかったりもする

続けていく気概

結局大事なのは言いだしっぺがケツを持つ気概があるかどうか
アウトリーチを怠らなければ意外と世の中にちゃんと仲間はいる

産業機械をElixirで制御する - 菊池豊さん

菊池豊さんによる複数の水力発電の制御ソフトウェアをElixirで書いた経験を紹介する発表。

Elixirは書きやすく、コミュニティも盛り上がっているという話を聞いてちょっと書いてみたくなった。

以下メモ。

課題

Python
- 並行プログラミングができなかった
- コンパイラでの支援が期待できなかった
リプレイス先の候補はGo, Rust, Haskell, Erlang, Elm
- Elixir を使うようになった経緯〜電力システム制御の現場から〜

Why Elixir

世俗型関数型言語
- 関数型であることにこだわりすぎず使いやすさがある
- コミュニティも楽しかった
並行性
- アクターモデル
パイプ演算子
パターンマッチ

Elixirにないもの

型
- 静的型解析がほしい

Lean言語は新世代の純粋関数型言語になれるか？ - 井上亜星さん

井上亜星さんによるLean言語の紹介の発表。

この発表でLean言語という言語の存在を知った。純粋関数型言語でありながらforループやwhileループを書けるのはユニークだなーと思った。

What I have learned from 15 years of functional programming - Scott Wlaschinさん

Scott Wlaschinさんによる関数型プログラミングでの学びを共有する発表。

「直和型とレコード型を駆使しドメインモデリングを正確に表現することで保守性が向上するだけでなく動作可能なドキュメントとしても機能する」という話が印象に残った。

前者のメリットは以前から感じていたが、後者の観点はなかったので面白かった。（言われてみればそれはそうという感じだが）

以下メモ。

パイプライン指向で書くことで保守性の高いコードを書くことができる
- 以前はSOLID原則を満たすことを意識しすぎてしまいうまくいかなかったが、パイプライン的な志向でコードを書くことで自然と綺麗なコードを書くことができ、SOLID原則も自然と満たすことができるようになったとのこと
ドメインモデリング
- 直和型をうまく使ってドメインモデルを正確に表現する
  - 保守性が高くなり、バグが減る
  - 実行可能なドキュメントとしても機能する
Railway Oriented Programmingを使うことでエラー処理を伴う処理を保守性高く書くことができる¹

F#の設計と妥協点 - .NET上で実現する関数型パラダイム - 猪股健太郎さん

猪股健太郎さんによるF#の言語設計の特徴、設計意図を紹介する発表。

純粋関数型言語なのかと思っていたが、命令形っぽい書き方もできることは知らなかった。他の.NET言語との相互運用性があるのも便利そう。

以下メモ。

概要

OCamlに大きな影響を受けている
金融工学、データサイエンス、科学計算、Webアプリなどで活用されている
F#をJavaScriptにトランスパイルするコンパイラもあり、フロントエンドも書ける

F#の特徴

静的型付けの非純粋関数型言語である。
- デフォルトはイミュータブルだがmutableにもできる
- .NETランタイムは仮想マシン型
  - C#, F#など複数言語を.NETランタイム上で動かす前提で設計されており共通中間言語、共通型システム、共通言語仕様を備える
ホスト環境との相互運用性
- F#で書かれたコードは他の.NET言語から自然かつ安全に利用可能
マルチパラダイム言語
- 関数型プログラミングのパラダイムを核に、オブジェクト指向プログラミングの要素も備える
- クラスや構造体も書ける

言語設計の意図

プログラマーが命令的なコーディングから関数型のコーディングへ移行する際のハードルを下げることを意識した設計になっているらしい。

マイクロサービス内で動くAPIをF#で書いている - ayato-pさん

ayato-pさんによるマイクロサービスの1サービスをF#で書く際の設計や悩みどころを紹介する発表。

ドメイン設計の際に容易にOptionを使わずにenumの別のvariantとして表現する、という考え方はRustなどでも活かせそうだと思った。別の概念であれば別の型として表現するのが大事そう。

以下メモ。

どんなチームで採用したのか
- ペアプログラミングを中心に100人超の組織で開発している
- モノリス -> マイクロサービスの移行をやっている
- マイクロサービスの各APIは多種多様な言語で書かれている
F#導入以前のプロダクトチーム
- JVM系、Elixir, Go, Rust, OCaml, Haskellなども採用
- .NET系の言語は採用されていなかった
どう導入したのか
- システムのコアにいきなり採用するのはリスキーだったのでなにかあってもまずは影響が少ないサブシステムで採用
なぜF#か
- 静的型付け
- シンタックスが簡素
- .NETの資産を活用できる

F#らしさを活かした設計

Optionなどを入れずに判別共用体を使って設計する

e.g. 上場企業と非上場企業を表現するときにisListed: bool, listedAt: Option<DateTime>のように表現するのではなく…

type Company = 
  { id: CompanyId
    name: string
    isListed: bool
    listedAt: Option<DateTime> }

そもそも別のvariantとして表現する

type Listed = Listed of listedAt: DateTime

type CompanyProfile = 
  { id: CompanyId
    name: string }

[<RequireQualifiedAccess>]
type Company = 
  | Listed of CompanyProfile * Listed
  | UnListed of CompanyProfile

スポンサーブース

Jane Streetのエンジニアの方にお聞きしたがJane StreetではフロントエンドとサーバーサイドをOCamlで書いているらしい（！）ブースでお話した方も関数型言語が書きたくて入社したそうで、関数型言語への愛を感じた。

ブースでいただいたノベルティのTシャツもめっちゃOCamlだった。

ノベルティ

入場時にロゴ入りのトートバッグがもらえた。

Nulabさんのノベルティのマイクロファイバークロス。実用的でありがたい。

まとめ

今は業務で関数型言語を使うことはないが、関数型言語の考え方を取り入れることで非関数型言語でもより良いコードを書けるようになると改めて感じた。

個人で初めてオフラインの勉強会/カンファレンスに参加したが普通に楽しかったのでまた行ってみようと思う。

つけ麺情報

二代目えん寺がとても美味しかった。

Elm Patternsでも紹介されていたのを思い出した。改めて読み直してみよう。 ↩︎

cargoプロジェクトで依存関係を継続的に管理する

Tue, 20 May 2025 15:00:00 +0000

OSSに依存するプロジェクトでは依存しているライブラリのライセンス表記が必要になることがある。（体感的にはほとんどのライブラリはライセンス表記を求めているように思う）

そのため、依存ライブラリが増えた場合にはライセンス表記を更新する必要があるが、依存ライブラリの依存ライブラリに対しても再帰的にライセンス表記を見に行って自リポジトリの依存ライセンス表記ファイルを更新して…という作業を行うのは現実的ではない。

他にもうっかりコピーレフトなライブラリに依存してしまうとプロジェクトのライセンスを変更しなければならなかったりと案外注意すべきポイントが多い。

cargoプロジェクトにおいてこれらの労力を削減してくれるツールがいくつか存在している。

筆者は趣味プロジェクトとしてfzf-makeというmake targetやpnpm script, yarn script, just recipeをfuzzy finder形式で選択、実行できるCLIツール¹をRustで開発しており、このプロジェクトで最近それらのツールを導入したので使い方とともに紹介する。

tl;dr

以下のチェックをCIで実行することでcargoプロジェクトの依存関係を継続的に省力で管理できる。

cargo-machete: 不要な依存関係がないか
cargo-deny: 依存ライブラリに許容しないライセンスが含まれていないか
cargo-about: リポジトリのライセンス表記ファイルに更新漏れがないか

それぞれ紹介する。なお、コード例はそれぞれ以下のランナーを想定している。

環境	ランナー
ローカル	make
CI	GitHub Actions

`cargo-machete`で不要な依存関係を検出する

why

ある程度の期間開発を続けていると以前追加した依存関係が不要になったことに気付かずにcargo.tomlのdependenciesやdev-dependenciesに残ったままになることがある。不要な依存関係が残ったままになっているとrenovateやdependabotによるバージョン更新の手間が不必要に増えてしまうのでPRの時点で気付けるようにしたい。

what

cargo-macheteを使ってcargo.tomlに記述されている依存関係のうち、プロジェクトが実際には依存していない依存関係を検出する。

how(ローカル)

以下のようなmake targetを定義しておくとmake detect-unused-dependenciesで不要な依存関係を検出できる。

.PHONY: tool-detect-unused-dependencies
tool-detect-unused-dependencies:
	@if ! which cargo-machete > /dev/null; then \
		cargo install --locked cargo-machete; \
	fi

.PHONY: detect-unused-dependencies
detect-unused-dependencies: tool-detect-unused-dependencies
	cargo machete

以下は不必要な依存関係としてtempfileが検出されている様子。

how(CI)

以下のようなyamlを定義しておくと不要な依存関係がある場合にCIが落ちてくれる。

name: Detect unused dependencies
on:
  push:
    branches: [ "main" ]
  pull_request:

jobs:
  detect-unused-dependencies:
    runs-on: ubuntu-latest
    steps:
      - name: Checkout
        uses: actions/checkout@v4
      - name: Machete
        uses: bnjbvr/cargo-machete@v0.8.0

`cargo-deny`で依存ライブラリに許容しないライセンスが含まれていないか検証する

why

筆者はfzf-makeをより自由に利用してほしいと考えているためMITライセンスでプロジェクトを公開したい。コピーレフトのライセンスに依存してしまうとライセンス変更を余儀なくされるため、コピーレフトのライブラリに依存することを避けたい。

what

cargo-denyは依存関係のlint機能を提供する。fzf-makeでは、cargo deny check licensesを用いてホワイトリストに登録したライセンス以外のライセンスが依存ライブラリに含まれていないか検証している。

# deny.toml
[licenses]
allow = [
    "MIT",
    "ISC",
    "Apache-2.0",
    "MPL-2.0",
    "BSD-2-Clause",
    "BSD-3-Clause",
    "Unicode-DFS-2016",
    "OpenSSL",
]
confidence-threshold = 0.8
exceptions = []

[[licenses.clarify]]
name = "ring"
expression = "MIT AND ISC AND OpenSSL"
license-files = [
    { path = "LICENSE", hash = 0xbd0eed23 }
]

how(ローカル)

以下のようなmake targetを定義しておくとmake check-licensesで依存ライブラリに許容しないライセンスが含まれていないかを検証できる。

.PHONY: tool-check-licenses
tool-check-licenses:
	@if ! which cargo-deny > /dev/null; then \
		cargo install --locked cargo-deny; \
	fi

.PHONY: check-licenses
check-licenses: tool-check-licenses
	cargo deny check licenses

許可していないライセンスのライブラリに依存していることがわかると以下のようなエラーが出力される。

how(CI)

以下のようなyamlを定義しておくと不要な依存関係があるとCIが落ちてくれる。

name: Check licenses
on:
  push:
    branches: [ "main" ]
  pull_request:

jobs:
  check-licenses:
    runs-on: ubuntu-latest
    steps:
    - uses: actions/checkout@v4
    - uses: EmbarkStudios/cargo-deny-action@v2
      with:
        command: check licenses

`cargo-about`でリポジトリのライセンス表記が最新か検証する

why

冒頭でも触れた通り、多くのOSSでは依存ライブラリのライセンス表記を求めている。

fzf-makeではCREDITS.htmlというファイルを用意しておりそこに依存ライブラリのライセンス表記を記載している。

これまでは依存ライブラリを追加/削除した際に手作業でライセンス表記ファイルを更新していたが、漏れがちになっていた。

また、本来は依存ライブラリの依存ライブラリを再帰的にチェックしてすべてのライセンス表記をすべきなのだと思うが、手作業でそれをする気にはなれなかったので直接依存しているライブラリのライセンスしか表記できていなかった。

これらの課題をcargo-aboutを用いることで解決できそうだったので導入してみた。

what

cargo-aboutは依存ライブラリのライセンス表記ファイルを自動生成する機能を提供する。

以下のようなテンプレートを用意し、cargo about generate about.hbs > CREDITS.htmlを実行するとCREDITS.htmlにライセンス表記を出力してくれる。

<html>
    <head>
        <style>
            @media (prefers-color-scheme: dark) {
                body {
                    background: #333;
                    color: white;
                }
                a {
                    color: skyblue;
                }
            }
            .container {
                font-family: sans-serif;
                max-width: 800px;
                margin: 0 auto;
            }
            .intro {
                text-align: center;
            }
            .licenses-list {
                list-style-type: none;
                margin: 0;
                padding: 0;
            }
            .license-used-by {
                margin-top: -10px;
            }
            .license-text {
                max-height: 200px;
                overflow-y: scroll;
                white-space: pre-wrap;
            }
        </style>
    </head>
    <body>
        <main class="container">
            <div class="intro">
                <h1>Third Party Licenses</h1>
                <p>This page lists the licenses of the projects used in fzf-make.</p>
            </div>
        
            <h2>Overview of licenses:</h2>
            <ul class="licenses-overview">
                {{#each overview}}
                <li><a href="#{{id}}">{{name}}</a> ({{count}})</li>
                {{/each}}
            </ul>

            <h2>All license text:</h2>
            <ul class="licenses-list">
                {{#each licenses}}
                <li class="license">
                    <h3 id="{{id}}">{{name}}</h3>
                    <h4>Used by:</h4>
                    <ul class="license-used-by">
                        {{#each used_by}}
                        <li><a href="{{#if crate.repository}} {{crate.repository}} {{else}} https://crates.io/crates/{{crate.name}} {{/if}}">{{crate.name}} {{crate.version}}</a></li>
                        {{/each}}
                    </ul>
                    <pre class="license-text">{{text}}</pre>
                </li>
                {{/each}}
            </ul>
        </main>
    </body>
</html>

how(ローカル)

以下のようなmake targetを定義しておくとmake update-license-fileで依存ライブラリのライセンス表記が最新か検証できる。

.PHONY: tool-update-license-file
tool-update-license-file:
	@if ! which cargo-about > /dev/null; then \
		cargo install --locked cargo-about; \
	fi

.PHONY: update-license-file
update-license-file: tool-update-license-file
	cargo about generate about.hbs > CREDITS.html

how(CI)

以下のようなyamlを定義しておくと依存ライブラリのライセンス表記が最新でないとCIが落ちてくれる。

name: Check license file
on:
  push:
    branches: [ "main" ]
  pull_request:

jobs:
  check-license-file:
    runs-on: ubuntu-latest
    steps:
      - name: Checkout
        uses: actions/checkout@v4
      - name: Check
        run: make update-license-file
      - name: Check diff
        run: |
          git add .
          git diff --cached --exit-code

なお、デフォルトだと以下の部分のThis page...fzf-makeの部分がThis page lists the licenses of the projects used in cargo-about.として出力される。そのため、そのまま利用すると「cargo-aboutプロジェクトでは以下のライセンスに依存しています」という意味の表示になってしまうためユーザーが忘れずにcargo-aboutの部分をプロジェクト名に変更する必要があるという問題がある。²

<div class="intro">
    <h1>Third Party Licenses</h1>
    <p>This page lists the licenses of the projects used in fzf-make.</p>
</div>

これに関しては以下のissueを立ててみたのでcargo-about側と意見が一致したら修正するPRを送ってみようと思う。

[Feature request] change cargo about init to generate the statement including user’s project name.

おわりに

繰り返しの定型タスクをCIに任せることができたので開発により集中できるようになった。（趣味開発だと数ヶ月ぶりにコミットするとかもザラにあり、開発に必要なタスクを忘れがちなのでそういった意味でも自動化の範囲を増やすことができてよかった）

便利ツールをOSSとして公開してくれている人/企業に感謝しつつ利用するだけでなく自分にできる貢献はやっていきたい。

fzf-makeの紹介記事: [make,pnpm,yarn,justに対応]コマンドをfuzzy finder形式で選択できるCLIツール fzf-makeの紹介 ↩︎
そして実際に90件近くのプロジェクトでcargo-aboutのままになっている。 ↩︎

傾斜付きロープロファイルキーキャップNuPhy Oblivionを買った

Wed, 30 Apr 2025 13:49:03 +0000

傾斜付きロープロファイルキーキャップであるNuPhy Oblivionを買った。

Oblivion

Emerges from the structured chaos of programming, where logic dances with creativity and every line of code tells a story. Inspired by the stark elegance of terminal interfaces and the rhythmic flow of syntax highlighting, its deep gray foundation is illuminated by vibrant accents of green, blue, and orange—a palette that feels as timeless as the tools of a coder’s trade.

https://nuphy.com/collections/keycaps/products/oblivion

価格は送料込みで$53.98(8,000円)だった。注文から6日後に届いた。

IQUNIX Magi65を買ったでも書いていた通りロープロファイルでも傾斜付きのキーキャップがないかな〜と思っていたところ突如としてOblivionのリリース情報がTwitterで流れてきたので買ってMagi65に装着してみた。¹

良かった点

傾斜があって打ちやすい
(NuPhy Halo65のキーキャップと比べて)打鍵音が少し静かになった
ロープロファイル用なだけあって干渉せずに問題なく使える

手前の白いのがオリジナルのフラットなキーキャップ。

これが今回購入したoblivionのキーキャップ。Cherry Profileに近い形状で傾斜がついている。

気になった点

ホーミングキーの凹凸(よくFキーとJキーについてるアレです)が結構低いので若干わかりづらい。が、慣れればそんなに問題なさそう

HHKBっぽく使いたい都合で普段使わないキーを間違って押さないようにあえてキーキャップを交換していない。 ↩︎

『コンピュータシステムの理論と実装第2版』を読んだ

Tue, 29 Apr 2025 15:00:00 +0000

『コンピュータシステムの理論と実装第2版』を読んだので感想を書く。割と長いので得られた学びだけ読みたい方は## 学び、得た経験までジャンプしてください。

本書の構成

本書はnand2tetrisという通称の通り、NANDゲートからスタートして、CPUやコンパイラやOSなどを実装し、最終的にはそのプラットフォーム上でテトリス(のようなアプリケーション)¹が動くところまで実装するという内容のコースになっている。

lecture 7.pdf

https://drive.google.com/file/d/1BPmhMLu_4QTcte0I5bK4QBHI8SACnQSt/view

P3より引用

上図のとおりだが、大まかな流れとしては以下。

NANDゲートを使ってnot, and, orなどの基本的なチップを実装
加算機やALUを実装
レジスタ、RAM、Program Counterを実装
Memory、CPU、Computerを実装
アセンブラを実装(機械語の記号表現をバイナリ表現に変換する)
仮想マシンを実装
コンパイラを実装
OSを実装

各章末に課題とそれをパスしたことを確認するテストがある。基本的にはテストコードを使って動作確認ができるようになっているため、自分の実装が合ってるかを機械的に確認できるようになっており、手を動かしながら理解を深めやすいようになっている。

参考までに各章の実装に用いる言語を記しておく。

章	実装言語
第1章ブール論理	HDL(Hardware Description Languageの略で論理回路の構造を記述できる言語)
第2章ブール算術	HDL
第3章メモリ	HDL
第4章機械語	アセンブリ言語(Hackプラットフォーム独自の仕様)
第5章コンピュータアーキテクチャ	HDL
第6章アセンブラ	任意の言語
第7章仮想マシンI：処理	任意の言語
第8章仮想マシンII：制御	任意の言語
第9章高水準言語	Jack言語(本書で実装するJavaライクな独自言語)
第10章コンパイラI：構文解析	任意の言語
第11章コンパイラII：コード生成	任意の言語
第12章 OS	Jack言語

第6章 ~ 第8章と第10章 ~ 第11章は決められた入出力を持つCLIツールを書けばいいので任意の言語で書くことができる。筆者はRustで実装した。特にEnumとパターンマッチのおかげで構文解析関連の処理が書きやすかった。

ここからは各章の学びを簡単に書いていく。

第1章ブール論理

NANDを使って以下の論理回路をHDLを使って実装した。

not
and
or
xor
マルチプレクサ
デマルチプレクサ
not(16bit)
and(16bit)
or(16bit)
マルチプレクサ(16bit)
8入力or
4入力マルチプレクサ(16bit)
8入力マルチプレクサ(16bit)
4入力デマルチプレクサ
8入力デマルチプレクサ

マルチプレクサの実装に悩んだがいい感じの実装を思いついたときの爽快感がすごかった。

真理値表を丁寧めに書きながら進めた結果マルチプレクサの実装以外はそこまで悩まなかった。

第2章ブール算術

以下の論理回路を作成した。

半加算器
全加算器
16bit同士の加算
16bitの入力に1をインクリメントする回路
ALU(Arithmetic Logic Unit: 算術論理演算装置)

学び:

内部ピンにインデックスアクセスするには次のように書く必要がある。

Mux16(a=calculateResult, b=notCalculateResult, sel=no, out=out, out[0..7]=out0To7, out[8..15]=out8To15, out[15]=ng);

愚直な実装をしている箇所があったが、Mux16でスマートに書き直せることを知って感動した。

第3章メモリ

この章では、DFF(Data Flip-Flop)を用いて1-bit registerを作成し、それを組み合わせて16-bit registerを作成し、さらにそれを組み合わせてRAMを作成した。

lecture 3.pdf

https://drive.google.com/file/d/1boFooygPrxMX-AxzogFYIZ-8QsZiDz96/view

P47より引用

読み書き可能なメモリを作成したことで、コンピュータを作っている感が強まってきた。

作成した回路は具体的には以下。

Register(1bit)
Register(16bit)
RAM(8bit)
RAM(64bit)
ProgramCounter
RAM(512bit)
RAM(4K-bit)
RAM(16K-bit)

学びメモ

第2章までは時間に依存しない回路のみを扱っていたがこの章では過去の状態を保持する回路を作成した。
ここでは時間をクロックという単位で区切って扱う。
非同期チップ(組み合わせチップ): 入力値の組み合わせのみに反応し時間の進行には影響を受けない
同期チップ(順序チップ): 以前の時間単位での変化に対応する用に設計されたチップ
同期チップを利用することでシステム内のチップ間で信号が伝播するのにかかる時間を無視できる。
ただしクロックサイクルは「システム内のチップ間で信号が伝播するのにかかる時間の最大値」と「1チップ内で最も処理時間がかかる演算を完了するのにかかる時間」の合計値よりも大きく設定する必要がある。

DFFはout(t+1) = in(t)で表される出力を持つ。DFFを用いることで過去の状態を論理回路上で表現できる。

lecture 3.pdf

https://drive.google.com/file/d/1boFooygPrxMX-AxzogFYIZ-8QsZiDz96/view

P41より引用

次のようにマルチプレクサとDFFを組み合わせることで1-bit registerを作成できる。

CHIP Bit {
    IN in, load;
    OUT out;

    PARTS:
    Mux(a=dffOut, b=in, sel=load, out=mux);
    DFF(in=mux, out=out, out=dffOut);
}

1-bit registerは時刻tにおいてloadビットがアサートされるとout(t+1)がin(t)の値になり、アサートされていない場合はout(t+1)はout(t)の値になる。換言するとレジスタを利用することで過去の状態を保持できる。

lecture 3.pdf

https://drive.google.com/file/d/1boFooygPrxMX-AxzogFYIZ-8QsZiDz96/view

P25より引用

第4章機械語

第4章では以下のプログラムを機械語で書いた。

掛け算を行うプログラム
キーボードが押されているときだけ画面を黒くするプログラム

機械語

ハードウェアプラットフォームが実行するように設計されている基本的な命令セット
高水準言語は表現力やプラットフォーム間の互換性を目標に設計される一方で機械語は特定のハードウェアで直接実行され、そのハードウェアを完全に制御できるように設計されている。
機械語は決められた形式に従いプロセッサとレジスタを用いてメモリを操作するように設計されている。
バイナリ形式、記号形式の2パターンで記述できる。

メモリ

データや命令を保存するハードウェアデバイス。各セルはメモリ位置やメモリレジスタと呼ばれ、それぞれ固有のアドレスを持つ。

プロセッサ

プロセッサは中央演算装置(CPU) と呼ばれ、あらかじめ決められた基本的な命令セットを実行できる。
プロセッサは選択されたレジスタとメモリ位置からデータを取り出し、選択されたレジスタとメモリ位置に出力を書き込む。
プロセッサはALUとレジスタ、バイナリ命令の解析と実行を可能にする論理ゲートによって構成される。

レジスタ

プロセッサとメモリはそれぞれ独立したチップとして実装されており一方から他方へデータを移すには比較的時間がかかる。そのためほとんどのプロセッサにはいくつかのレジスタが備わっており、高速なローカルメモリとして機能する。
CPUに存在するレジスタは2つのタイプに分類される。
- データを保持するデータレジスタ(Dレジスタ)
- アドレスを保持するアドレスレジスタ(Aレジスタ)

Hackコンピュータのアーキテクチャ

Hackコンピュータは以下のようなアーキテクチャを持つ。

lecture 4.pdf

https://drive.google.com/file/d/1HxjPmIZkFHl-BVW3qoz8eD9dqEuEyuBI/view

P23より引用

アセンブラの役割

機械語はバイナリ形式、記号形式の2パターンで記述できると書いたが、記号形式で@xのように変数を宣言した場合にその変数を実際のメモリのどこに置くかを知るのがアセンブラである。アセンブラのおかげで記号形式のプログラム側は実装詳細を意識することなく変数を初期化、利用できる。

命令タイプ

Hack言語には2つの命令タイプがある。

A命令
- A命令はAレジスタに15ビットの値を設定する。
- A命令は1ビットのオペコード + 15ビットの値で構成される。(Hack機械語ではA命令のオペコードは0)
- A命令は3つの目的で使用される。
  - プログラムによってコンピュータに定数を入力する
  - Aレジスタのアドレスを設定することでその次のC命令でRAMレジスタを操作できる
  - Aレジスタにジャンプ先のアドレスを設定することでその次のC命令でジャンプを実行できる
C命令
- C命令では次の3つを指定する。
  - どういう計算をするか(comp)
  - 計算された値をどこに保存するか(dest)
  - 次に何をするか(jump)
- Hack機械語では一番左端の1ビットが1
- C命令は次のような形式で構成される。111accccccdddjjj
  - 111: 先頭の1がオペコードで、左から2,3ビット目は使用されないが慣例として1が設定されている。
  - a: ALUへの入力がAレジスタからの値化Mからの値か決定する(1ビット)
  - c: compフィールド。(6ビット)ALUに対して計算内容を指定する。
  - d: destフィールド。(3ビット)計算結果の値をどこに保存するかを表現する。左から順にDレジスタ、Aレジスタ、RAM[A]に値を保存するかを表現する。

lecture 4.pdf

https://drive.google.com/file/d/1HxjPmIZkFHl-BVW3qoz8eD9dqEuEyuBI/view

P129より引用

外部デバイス

Hackのハードウェアプラットフォームでは画面とキーボードの2つの外部デバイスに接続できる。どちらのデバイスもメモリマップを通してコンピュータと会話する。(メモリの中に画面とキーボード用のメモリ領域があり、そこに画面の各ピクセルの値や押下されているキーのキーコードが格納される。)

Hackプログラムの例

以下は掛け算を行うHackプログラムのソースコード。(Hackアーキテクチャで動作する機械語で書かれている) ハードウェアの構成要素を理解しながら手続き型チックに記述する必要があるため難しかったが理解が進んだ。

// 0に対して(R0-1)回R1を足すことで掛け算を実現する

  // n = 0
  @n
  M=0

  // R2 = 0
  @R2
  M=0
(LOOP)
  // if n == R0 then goto END
  @n
  D=M
  @R0
  D=D-M
  @END
  D;JEQ

  // R2 += R1
  @R2
  D=M

  @R1
  D=D+M

  // R2 = D
  @R2
  M=D

  // n++
  @n
  M=M+1

  // go to LOOP
  @LOOP
  0;JMP
(END)
  @END
  0;JMP

第5章コンピュータアーキテクチャ

第5章では、これまでの章で作成した論理回路を組み合わせてついに1つの汎用コンピュータを作成する。このコンピュータは第4章に登場した機械語のプログラムを実行できる。

ノイマン型アーキテクチャ:
- CPUがメモリデバイスと相互作用する。
- 入力デバイスからデータを受け取り出力デバイスへデータを送信する。
- コンピュータのメモリに保存されるデータはコンピュータが計算したデータだけではなくコンピュータに何を行うべきかを指示する「命令」も含まれる。
メモリ:
- 物理的にはアドレス指定可能な固定サイズのレジスタの並びで、それぞれが固有のアドレスを持つ。
- 概念的にはアドレス空間はデータと命令の保存という2つの役割を果たす。
- ランダムに選択されたメモリレジスタに瞬時に到達できるという要件からRandom Access Memoryと呼ばれている。
  - たしかにRAMはレジスタの木構造になっていたのである程度大きいRAMでも少ないホップ数で指定したレジスタにアクセスできそうだ。
- データ専用のメモリ領域をデータメモリ、命令専用のメモリ領域を命令メモリと呼ぶ。
CPU:
- CPUは現在読み込まれているプログラムの命令を実行する。
- 各命令はCPUに対して以下を指示する。
  - どの計算を実行するか
  - どのレジスタにアクセスするか
  - 次のどの命令をフェッチして実行するか
- CPUはこれらのタスクをALU、レジスタ、制御ユニットを使って実行する。

第5章の課題ではこれまでの章で作成した論理回路を組み合わせて以下を作成した。

Memory
CPU
Computer

正直CPUの実装、デバッグがはかなり大変だったが公式が提供してくれているテストツールとデバッガのおかげで効率的にバグを見つけることができた。

こんな感じで各ピンの出力や期待する結果とのdiffを比較的見やすい形式で表示してくれるのでありがたかった。

ここで作成したCPUの回路は次のようなもの。ここではヒントとして大まかな回路設計が与えられておりそれを参考にしつつ足りない部分を埋めていく形で実装を進めた。

lecture 5.pdf

https://drive.google.com/file/d/1Z_fxYmmRNXTkAzmZ6YMoX9NXZIRVCKiw/view

P31より引用

第6章アセンブラ

第6章では第5章で書いた機械語の記号表現をバイナリ表現に変換するアセンブラを開発する。

変数やラベルのアドレス管理を行うためにシンボルテーブルを利用する。シンボルテーブルには以下のような情報が格納される。
- ラベルの位置 e.g. (LOOP)
- 変数のアドレス e.g. @i(Hack機械語では変数は16以降のアドレスに順に割り当てられる)
- 定義済みシンボルのアドレス e.g. @SCREEN, @KBD

シンボル処理

アセンブリプログラムではシンボルが定義される前にシンボルラベルを使用できる。(goto命令の行き先を指定するのに利用する)

この挙動も考慮しつつバイナリを生成するには2パス・アセンブラと呼ばれる手法を用いる。

第1パス: シンボルテーブルを作成しすべてのラベルシンボルをテーブルに追加する。
第2パス: 変数シンボルを処理し、シンボルテーブルを使用してバイナリコードを生成する。

第6章からは好きな言語で実装できるのでRustで実装した。構文解析系はenumがある言語だと書きやすくて良い。

第7章仮想マシンI：処理

第7章ではVM変換器の一部を実装した。第8章で残りの部分を実装してVM変換器が完成する。ここまでの課題の中では一番大変で丸3日かかった。

HackプラットフォームのVMアーキテクチャとその利点

Hackプラットフォームにおいて、Hackプログラムは2段階コンパイルによって機械語に変換される。(更にその後アセンブラが機械語(記号表現)を機械語(バイナリ表現)に変換する)

    graph LR
    A[Jackコード
e.g. Foo.jack] -->|コンパイラが変換| B["VMコード(中間コード)
e.g. Foo.vm"]
    B -->|VM変換器が変換| C["機械語(記号表現)
e.g. Foo.asm"]
    C -->|アセンブラが変換| D["機械語(バイナリ表現)
e.g. Foo.hack"]

中間コードは仮想マシン(Virtual Machine; VM) と呼ばれる抽象化されたコンピュータ上で実行されるように設計されている。

高水準言語のプログラムを直接機械語に変換する方式だとハードウェアプラットフォームごとにコンパイラを作成する必要がある。この場合、コンパイラはソース言語(高水準言語)とターゲット言語(機械語)の両方に依存するためそれぞれの変更に追従する必要がある。

2段階でコンパイルする方式を採用するとコンパイラはソース言語の詳細に、VM変換器はターゲット言語の詳細にのみ依存するため変更への追従コストを下げることができる。 この方式ではコンパイラはハードウェアプラットフォームによらず利用することができ、ハードウェアごとにVM変換器さえ実装すればよい。そのためクロスプラットフォーム対応が比較的容易になるという利点がある。

VMフレームワークは上記の利点の代償として効率性が低下するという欠点がある。2段階の変換プロセスで生成するコードは直接コンパイルで生成するコードよりも冗長なことが多く、効率性が落ちる。

VM言語の設計

VM言語の設計にはバランスが重要で以下の要求を同時に満たす必要がある。

高水準側からの要求: 高水準言語のコードを表現できるだけの表現力と構造性を持たなければならない
低水準側からの要求: VMコードから生成される機械語がコンパクトで効率的になるようにVMコードは十分に低水準でなければならない

このような一見矛盾するような要件をスタックマシンが解決する。スタックマシンに基づく中間のVM言語を用いることで高水準言語の表現力と低水準言語の効率性という相反する要求を満たすことができる。

スタックマシンの挙動

スタックマシンの中心はスタックと呼ばれるLIFOのデータ構造にある。ここではいくつかの操作について説明する。(ここではスタックは下方向に成長するように記述する)

push操作の例

graph LR
    A[Stack: empty] -->|push 10| B[Stack:
10]

pushを行うとスタックの先頭に値が追加される。スタックではSP(スタックポインタ) という値を使ってスタックの先頭位置を保持している。SPはpush操作を行う際に値を追加する領域を指し示している。スタックのメモリアドレスが0からスタートすると仮定すると今回の例ではアドレス0に値がpushされたときにSPの値が0から1になる。

アドレス	値
0	10
1

graph LR
    A[Stack: empty] -->|push 10| B[Stack:
10]
    B -->|push 20| C[Stack:
10
20]

push操作を行うとスタックの先頭に値が追加される。このときSPの値は1から2になる。(補足:ここではSPは0-originとする)

pop操作の例

graph LR
    A[Stack:
42] -->|pop local 0| B["Stack: empty
local[0] = 42"]

pop segment_name indexと記述するとスタックの先頭の値を取り除き、指定したメモリセグメント、インデックスの位置に値を書き込む。

pop操作はスタックの先頭の値を取り除く。

算術演算(add)の例

graph LR
    A[Stack: empty] -->|push 10| B[Stack:
10]
    B -->|push 20| C[Stack:
10
20]
    C -->|add| D[Stack:
30]

算術演算の例としてx+yを行うケースを考える。

この処理は次のような流れで行われる。

スタックからオペランドx, yをpopする
x+yを計算する
計算結果をスタックにpushする

graph LR
    A[Stack:
10
20] -->|pop y=20| B[Stack:
10]
    B -->|pop x=10| C[Stack: empty]
    C -->|push x+y=30| D[Stack:
30]

この方法を拡張することで一般的な算術演算をスタックマシンで評価できる。

第7章では、以下の演算子を実装した。

push
pop
算術演算子
- add
- sub
- neg
- eq
- gt
- lt
- and
- or
- not

仮想メモリセグメント

ここで実装するVMにはシンボル変数は存在しない。そのかわりに変数はstatic, local, argument, this, that, pointer, tempのような名前を持つ仮想セグメントの要素として表現される。たとえばコンパイラは高水準言語プログラムで見つかった最初のスタティック変数をstatic 0に、その次に見つかったスタティック変数をstatic 1に、というように変換する。

ここでのVM実装では以下のような仮想メモリセグメントを持つ。

名前場所使用法

SP RAM[0] スタックポインタ：スタック最上位の次のメモリアドレス

LCL RAM[1] localセグメントのベースアドレス

ARG RAM[2] argumentセグメントのベースアドレス

THIS RAM[3] thisセグメントのベースアドレス

THAT RAM[4] thatセグメントのベースアドレス

TEMP RAM[5-12] tempセグメントを保持

R13, R14, R15 RAM[13-15] VM変換器が生成するアセンブリコードに変数が必要な場合、これらのレジスタを使用可能

P175より引用

名前	場所	使用法
SP	RAM[0]	スタックポインタ：スタック最上位の次のメモリアドレス
LCL	RAM[1]	localセグメントのベースアドレス
ARG	RAM[2]	argumentセグメントのベースアドレス
THIS	RAM[3]	thisセグメントのベースアドレス
THAT	RAM[4]	thatセグメントのベースアドレス
TEMP	RAM[5-12]	tempセグメントを保持
R13, R14, R15	RAM[13-15]	VM変換器が生成するアセンブリコードに変数が必要な場合、これらのレジスタを使用可能

LCL, ARG, THIS, THATには各セグメントのベースアドレスが格納されている。たとえば次のように指定されていた場合、pop this 2はスタックの先頭の値をRAM[2202]に書き込む。

アドレス	値	備考
0	256	SP
1	2000	LCL
2	2100	ARG
3	2200	THIS
4	2300	THAT

VM変換器の動作例

例として実際の変換例を示す。

push constant 7
push constant 8
add

今回作成した実装では上記のvmコードは次のようなアセンブリコードに変換される。

// init
@256
D=A
@SP
M=D
// body
// push
@7
D=A
@SP
A=M
M=D
@SP
M=M+1
// push
@8
D=A
@SP
A=M
M=D
@SP
M=M+1
// add
@SP
A=M
A=A-1
A=A-1
D=M
@SP
A=M
A=A-1
D=D+M
@SP
A=M
A=A-1
A=A-1
M=0
@SP
A=M
A=A-1
M=0
@SP
M=M-1
M=M-1
@SP
A=M
M=D
@SP
M=M+1
// end
(END)
@END
0;JMP

VM変換器の実装はハードウェアの構造を意識しながらだいぶ手続き的なコードを書く必要があるので大変だった。(記述量も多いしミスるポイントも多い。)

現代のおいては低レイヤを隠蔽してくれる便利な仕組みがあるおかげでソフトウェアエンジニアが少ない記述量でアプリケーションを動かすことができていることを実感した。

ただ、隠蔽されているからこそ自主的に潜っていかないと構造の理解を深めるのが難しかったりするので引き続きやっていきたい。

第8章仮想マシンII：制御

第7章では

push

pop

算術演算子

add

sub

neg

eq

gt

lt

and

or

not

以下の演算子を実装したが、第8章では以下の演算子を実装し、VM変換器を完成させた。

label
goTo
ifGoTo
call
function
return

これを実装することで次の操作が可能になりよりプログラムっぽい処理を行えるようになる。

任意のラベル位置へのジャンプ
if分岐
関数の宣言と呼び出し

関数の呼び出し(`call`)

Hackプラットフォームにおいてはcall {function_name}コマンドを使って関数呼び出しを行う。

スタックを利用することで関数の呼び出しと戻り値の取得をシンプルに行うことができる。

ここではfunc_aからfunc_bを呼び出すシナリオを例に関数呼び出しをスタックで実現する際の操作を説明する。

(func_aからfunc_bを呼び出す)
func_aの以下の呼び出し側の情報をスタックにpush(これらの情報はフレームと呼ばれる)(画像の灰色の部分)
1. リターンアドレス(: func_bの呼び出しが完了してreturnする際に戻るアドレス)
2. func_aのLCLセグメントのベースアドレス
3. func_aのARGセグメントのベースアドレス
4. func_aのTHISセグメントのベースアドレス
5. func_aのTHATセグメントのベースアドレス
ARG, LCLセグメントの値を更新
func_bのコマンドが定義されているアドレスにジャンプ
リターンアドレスラベルをコードに挿入

lecture 8.pdf

https://drive.google.com/file/d/1BexrNmdqYhKPkqD_Y81qNAUeyfzl-ZtO/view

P58より引用

関数からのreturn(`return`)

呼び出された関数の終了はreturnコマンドで行う。このコマンドが呼ばれることで呼び出し側に処理が戻る。

ここではfunc_aからfunc_bを呼び出した際にfunc_bからfunc_aに戻るシナリオを例にスタックの操作を説明する。

frameのアドレスを一時変数に格納
リターンアドレスを一時変数に格納
ARGに返り値を格納
SPをARG+1に設定
THAT, THIS, ARG, LCLを復元
リターンアドレスにジャンプ

lecture 8.pdf

https://drive.google.com/file/d/1BexrNmdqYhKPkqD_Y81qNAUeyfzl-ZtO/view

P73より引用

第9章高水準言語

第10章、第11章でコンパイラを実装するJackの言語仕様を解説した章。

Javaに近い感じの文法。

class Main {
   function void main() {
      var Array a; 
      var int length;
      var int i, sum;

      let length = Keyboard.readInt("How many numbers? ");
      let a = Array.new(length); // constructs the array
     
      let i = 0;
      while (i < length) {
         let a[i] = Keyboard.readInt("Enter a number: ");
         let sum = sum + a[i];
         let i = i + 1;
      }

      do Output.printString("The average is ");
      do Output.printInt(sum / length);
      return;
   }
}

第10章コンパイラI：構文解析

第10章の内容に入る前にJackのソースコードが実行可能な形式になるまでの流れをおさらいしておく。

    graph LR
    A[Jackコード
e.g. Foo.jack] -->|コンパイラが変換| B["VMコード(中間コード)
e.g. Foo.vm"]
    B -->|VM変換器が変換| C["機械語(記号表現)
e.g. Foo.asm"]
    C -->|アセンブラが変換| D["機械語(バイナリ表現)
e.g. Foo.hack"]

Jackコンパイラは構文解析器とコード生成器からなり構文解析器はトークナイザとパーサ²からなる。

lecture 10.pdf

https://drive.google.com/file/d/1CM_w6cxQpYnYHcP-OhNkNU6oD5rMnjzv/view

P4より引用

トークナイザはソースコードをトークンと呼ばれる「プログラムにおいて意味を持つコードの最小単位」に変換する処理を担う。

トークンのような表現に変換してからパースを行うことでプログラムの複雑性を軽減することができる。

例として以下のJack言語のコードのトークン列をXMLで表記すると以下のようになる。

class Main {
    static boolean test;

    function void main() {
      do Output.printString("Hello world!");
      return;
    }
}

<class>
  <keyword> class </keyword>
  <identifier> Main </identifier>
  <symbol> { </symbol>
  <classVarDec>
    <keyword> static </keyword>
    <keyword> boolean </keyword>
    <identifier> test </identifier>
    <symbol> ; </symbol>
  </classVarDec>
  <subroutineDec>
    <keyword> function </keyword>
    <keyword> void </keyword>
    <identifier> main </identifier>
    <symbol> ( </symbol>
    <parameterList>
    </parameterList>
    <symbol> ) </symbol>
    <subroutineBody>
      <symbol> { </symbol>
      <statements>
        <doStatement>
          <keyword> do </keyword>
          <identifier> Output </identifier>
          <symbol> . </symbol>
          <identifier> printString </identifier>
          <symbol> ( </symbol>
          <expressionList>
            <expression>
              <term>
                <stringConstant> Hello world! </stringConstant>
              </term>
            </expression>
          </expressionList>
          <symbol> ) </symbol>
          <symbol> ; </symbol>
        </doStatement>
        <returnStatement>
          <keyword> return </keyword>
          <symbol> ; </symbol>
        </returnStatement>
      </statements>
      <symbol> } </symbol>
    </subroutineBody>
  </subroutineDec>
  <symbol> } </symbol>
</class>

パーサはトークン列を言語の構文ルールに照らし合わせその構造を構文上の要素に変換する処理を担う。

ここでは再帰下降構文解析というアルゴリズムを使って構文解析を行った。

ちなみに、Jack言語の構文は次のように定義されている。簡単な部類の言語とはいえ実装量はこれまでの課題と比べると多めだった。趣味でCコンパイラを書く人をたまにTwitterで見かけたりするがすごいなぁという気持ちになった。

第11章コンパイラII：コード生成

第11章では、コード生成器を実装する。具体的には構文解析した結果をもとにVMコードを生成する。

lecture 10.pdf

https://drive.google.com/file/d/1CM_w6cxQpYnYHcP-OhNkNU6oD5rMnjzv/view

P4より引用

一般的にはソースコードをVMコードに変換する層をフロントエンド、VMコードを機械語に変換する層をバックエンドと呼ぶらしい。本書では第10章と第11章の内容がフロントエンドに、第6章~第8章の内容がバックエンドに該当する、と言えそう。

シンボルテーブル

コンパイラがlet y = foo(x);のような文に遭遇するたびにx, yが何を表しているのかを知る必要がある。

Jackではクラススコープとサブルーチンスコープの2つのスコープがある。クラススコープの変数にはフィールド変数、スタティック変数の2種類があり、サブルーチンスコープの変数にはローカル変数、引数の2種類がある。

ここではこれらの変数の情報はシンボルテーブルと呼ばれるデータ構造に格納することで管理する手法が紹介されていた。シンボルテーブルは変数の名前、型、スコープ、種類、インデックスを保持する。

lecture 11.pdf

https://drive.google.com/file/d/1CYOcXKxfAwRHaOERvoyuNKSwdlxMo_e3/view

P6より引用

Jackではクラススコープとサブルーチンスコープの2つのスコープがあるのでそれぞれ別のシンボルテーブルを保持する必要がある。Jackでは内側のスコープが外側のスコープよりも優先されるため、コンパイラはxという変数に出会ったときにまずサブルーチンスコープのシンボルテーブルを検索し、見つからなければクラススコープのシンボルテーブルを検索する。

コンストラクタのコンパイル

特定のクラス型の変数を宣言する。e.g. var Point p
クラスのコンストラクタを呼び出して実際にインスタンス化する。 e.g. let p = Point.new(2, 3)
1. 新しいPointインスタンスを表現するために必要な2ワード分のメモリブロックをヒープ上に確保する
2. 確保された2ワードがコンストラクタの引数として与えられた2と3で初期化される
3. pに新しく確保したメモリブロックのベースアドレスを割り当てる

実装自体が難しいというケースは少なかったが、純粋にVM変換器の仕様を忘れて思い出すのに時間がかかったりしたので可能な方は時間を開けずにやると思い出しにかかるコストを減らせておすすめです。

第12章 OS

第12章では最小限のOSを実装した。

ここではOSは以下の役割を果たす。

ハードウェア操作の抽象化
Jack言語でよく使われる処理を関数/メソッドとして提供

それぞれ具体的には次のようなクラスによって実現されている。

ハードウェア操作の抽象化
- Outputクラス: printString, printlnなどのスクリーンへのテキストの書き込み処理を提供
- Screenクラス: drawLine, drawCircleなどのスクリーンへの図形の書き込みを処理を提供
- Keyboardクラス: keyPressed, readLineなどのキーボードからの入力の読み取り処理を提供
- Memoryクラス: alloc, deAlloc, peek, pokeなどのメモリアクセス処理を提供
- Sysクラス: プログラム実行に必要な処理の提供
Jack言語でよく使われる処理を関数/メソッドとして提供
- Mathクラス: abs, devideなどの基本的な算術演算を提供
- Stringクラス: 文字列データ型とlength, setCharAtなどの関連処理を提供
- Arrayクラス: 配列の初期化とメモリの解放を行う機能を提供

この章ではこれまでまったく意識したことがなかったメモリ操作によってハードウェアを制御するという経験が得られた。クラスインスタンスの初期化のためにメモリから任意の大きさの空き領域を探して確保する処理や、2点の座標が与えられたときにそれらを結ぶ直線をスクリーン上に描画する処理など。想像に難くない通り、基本的にかなり泥臭い実装が多かったがその泥臭さを吸収するための層でもあるので仕方ないとは思う。

その過程でメモリ操作やビットを扱う処理に少し慣れられたのは大きな収穫の1つだった。普段のWeb開発ではbit演算やメモリ操作をする機会はなかなかないので貴重な経験だった。

軽く調べた感じでは、現実世界では(Linuxでは)システムコールやデバイスドライバがそれらを担っているらしい。

実装に関しては整数型のオーバーフローが原因で数時間費やしてしまった。CS50でC言語で課題を解いていたときも同様のハマりがあったのであるあるかもしれない。普段書いている言語は簡単にオーバーフローしなかったり場合によっては静的解析で指摘してくれたりするのでなかなか気付くことができなかった。

学び、得た経験

普段はWebアプリケーションばかり触っているので、それよりも数段下のレイヤーの解像度を上げることができた。今後新しい知識の習得やトラブルシューティングがスムーズになるといいなと思う。
- あとは普段触っているソフトウェア、ハードウェアの仕組みを知ることができて純粋に楽しかった。
難しい概念に出会ったときに「順を追って理解を整理したり、労を惜しまずに手を動かしていけばきっと体得できるはず」という感覚を持てるようになった。
- 自分のコンピュータサイエンスの知識と経験が薄いのもあり、本書を通して未知の概念とのたくさんの出会いがあった。
- まったく知らない概念でも、順を追って理解を進めて手を動かすことで知識を自分のものにすることができた。その過程で未知の技術に対する恐れや及び腰になる感覚が減った。
- 余談だが、大学受験のときにセンター試験の数2Bで一見すると難しそうな問題が出ることが多いように感じていて「いけるいける難しくない落ち着いて考えればわかる」と何回も念じながら問題文を読んでいたのを思い出した。「難しそう」と考えるよりも「わかりそう」とか「なんかいけそう」みたいな方向性のマインドを持っていたほうがパフォーマンスも高くなるなーと改めて思うなどした。³
難しい課題も小さい部分に分割して段階的に進めるとうまくいくことを実感できた。
- 0からコンパイラを実装するのは気が引けるが、仕組みを理解していくつかの部品に分解して進めることで、複雑なソフトウェアを着実に構築する経験を得ることができた。
コンパイラやアセンブラの実装で泥臭い処理をたくさん書いたおかげで泥臭さへの耐性が多少ついた。そもそも複雑なものは実装も複雑になりうるのでそういうケースでは特に実装力が大事だなーと思うなどした。

おわりに

『Goならわかるシステムプログラミング』を読んでからかなり気になっていた本だったので無事完走できてよかった。

最近のテーマであるCS力の強化をまた一歩進めることができた。

次は『体験しながら学ぶネットワーク技術入門』でネットワークの理解を深めていこうかなと思う。

あとはソフトスキル系でいうと『エンジニアリングチームのリード術-―Googleに学ぶインディビジュアルコントリビューターとマネージャーのための実践ガイド』も良さそうなので読んでみようと思う。

実際はテトリスではなく別のブロック崩しのようなゲームではある ↩︎
Twitterを見ているとパーザと表記する流派も存在する模様 ↩︎
近い話が何かがそれほど得意でなくても、世の中の平均よりは得意だと思っておいたほうがよい - Lambdaカクテルで綺麗に言語化されている。 ↩︎

IQUNIX Magi65を買った

Sun, 06 Apr 2025 09:50:34 +0000

ある日YouTube Shortsで流れてきて打鍵感と打鍵音がよさそうで気になっていたIQUNIX Magi65を買ってみた。

画像は公式サイトより引用: Magi65 Aluminum Low Profile Mechanical Keyboard

価格は送料込みで$128(20,169円)だった。注文から14日後に届いた。中国から送られてきたので妥当そう。（？）

Magi65はコトコト系の打鍵音 & いい感じの打鍵感なので普段使っている7sPro¹とはまた違った感じで気分転換になって楽しい。

打鍵音はこんな感じ。

- YouTube

Enjoy the videos and music you love, upload original content, and share it all with friends, family, and the world on YouTube.

https://www.youtube.com/watch?v=EClom7Y_hO0

重さも900gと適度にあるので安定感がありつつも持ち運びもそこまで辛くない。

ロープロファイルのキーボードには傾斜がないキーキャップが使われていることが多いがMagi65も例に漏れず傾斜のないタイプのキーキャップが採用されていた。

画像は公式サイトより引用: Magi65 Aluminum Low Profile Mechanical Keyboard

傾斜があったほうが打ちやすい派なのでNuPhy Halo65のキーキャップが使えたらいいなーと思いおもむろに装着してみたところなぜか普通に使えてしまったのでそのまま使ってみている。（色味が合ってないのが若干アレではあるが打ちやすさには代えられないのでよしとした²）

あと通常プロファイルのキーボードよりも高さがないので尊師スタイルでも使っても手が疲れにくいのも嬉しいポイント。

[追記]その後傾斜付きロープロファイルキーキャップNuPhy Oblivionを買ったので記事を書いた。

欲を言えばスペースキーが3つくらいに割れていて傾斜のあるキーキャップの選択肢が多いと嬉しい。（ハイパー高望み）

ロープロファイルのコトコト系キーボードが気になる方にはオススメです。

スイッチはYushakobo Fairy Silent Linear Switchを使っている。Magi65と比べるとより静音で打鍵感も軽いので疲れなくてこれはこれで良い。 ↩︎
Cherry Profileのキーキャップも装着してみたがそちらは高さが合わなかったのか、R2の列のキーキャップの戻りが悪くなってしまい使えなかった ↩︎

2024年を振り返る

Sun, 29 Dec 2024 02:03:53 +0000

年の瀬なので今年を振り返る。

OSS

PRでの貢献

49件のPRを作成¹し43件のPRがマージされた。(4件がclosedで2件がopenのまま)

簡単に分類すると以下のような感じ。詳細は別記事に書く予定。²

バグ修正: 3件
ドキュメントの修正: 11件
lint系の修正: 4件
typo修正: 9件
機能追加: 7件
CIのバージョンアップ: 5件
自作TUIのbrew release関連: 3件
その他: 1件

今年の抱負の1つとしてこう書いていたがこれは達成できたといってよさそう。嬉しい。

OSS貢献を続ける。何らかのOSSのアプリケーションコードにも貢献する。

https://blog.kyu08.com/posts/looking-back-on-2023/#2024%E5%B9%B4%E3%81%AE%E6%8A%B1%E8%B2%A0

基本的には仕事中や趣味開発中にバグを見つけたり、追加したほうがよさそうな機能を思いついたり、ドキュメントの誤りに気付いたタイミングでPRを送っていた。

振り返るとOSS貢献を通して次のような成長を得られた。

馴染みのないプロジェクトのコードを読むのに慣れてきた。困ったり疑問があったらとりあえずドキュメントを読んだりissueやPRを検索したりcloneしてコードを読む、というのを自然とできるようになってきた。
- 以前はとりあえず日本語のブログを探したりAIに聞いたりしていたが上記の動きができるようになってから困りの解消速度が上がった感触がある。
- 特にRustで個人開発をしていると使いたいライブラリにドキュメントやexampleが存在しておらずそうするしかなかったというのもあるが、そのおかげで結果的に情報収集力が上がったように思う。
(OSSプロジェクトでは基本的に英語でコミュニケーションを行うので)英語でのやりとりに対する抵抗がなくなった。DeepLに頼ることも多々あるので来年はその割合を減らしていけると英語力の向上に繋がっていいかもしれない。

OSS貢献を始める前は「自分がissueを立てたりPRを送ったりしなくても世界中にはたくさんの優秀なエンジニアがいるので自分が貢献する余地はないだろう」などど考えていたが、意外と自分のような普通の開発者でも貢献の余地があることを実感できた。

具体的には、ある程度利用者がいるOSSプロジェクトであっても意外と自分が思いついた改善のアイディアが採用されたり、超有名なOSSでもドキュメントに間違いがあったりする。

機能追加の例を挙げるとdlvhdr/gh-dashに対する以下のPRではローディング中にNo PRs were found ...のようなメッセージが表示されていたのでローディング状態を表すスピナーを表示するようにした。

feat: showing a loading message #364 - dlvhdr/gh-dash

gh-dashは2024/12/30現在で7.4kスターを獲得しているOSSプロジェクトでスター数から類推するにそれなりに利用者もいると思われるが機能追加で貢献できたのは当時の自分からすると意外だった。(有名なプロジェクトなので自分が貢献する余地はないだろう、という先入観があった)

また、ドキュメント修正の例だとAdd missing version specifications for go install #1343 - grpc/grpc.ioでgRPCのプラグインのインストールコマンドを修正したりdocs: Fix installation command via Homebrew #10416 - zed-industries/zedでzedのインストールコマンドの不備を修正する変更が受け入れられた。

このように大規模な有名OSSであっても意外と自分が貢献する余地があると感じられたのはよかった。2025年も「自分なんかができることはないだろう」と自分の可能性を狭めずに積極的に貢献していきたい。

また、OSS貢献はメンテナや利用者に感謝してもらえるし熱量が高い人と議論したり協力したりできるのでとても楽しい。これからも楽しみながら貢献を続けていこうと思う。

寄付

GitHub Sponsorsの寄付先にratatuiを追加したでも書いた通り毎月ratatuiとneovimに5$ずつ寄付しはじめた。

また、自分がソフトウェアエンジニアを目指して就活をしている際にJavaScript Primerに大いに助けていただいたことをふとしたときに思い出したのでazuさんにoneshotで10$寄付させていただいた。非情報系の大学/大学院に進んでいた自分にとってはとてもありがたい存在だった。

個人開発

サマリ:

fzf-makeのstar数が100を突破した
fzf-makeがhomebrew-coreに取り込まれた
goでWeb APIサーバを作る際のパッケージ構成について検討した

fzf-make

個人開発に関して言うと2024年はひたすらfzf-makeの改善を続けていた。

fzf-makeとはタスクランナー側で定義したコマンドをfuzzy finder形式で選択できるCLIツールで、現在は以下のタスクランナーに対応している。

make
pnpm
yarn
just

プレビューウィンドウが表示されるのでコマンドの内容を確認しながら選択できるのが特徴。履歴機能もあるので前回実行したコマンドを簡単に再実行することもできる。(fzf-make repeat)

2024年は筆者が108件のPRを作成&マージし、41個のバージョンがリリースされ、筆者とrenovateを含めて8人の貢献者により184のcommitが追加された。時折issueを立ててくれたりPRを送ってくれる方もいて大変ありがたい限り…！🙏

自分や自分の身の回りのエンジニアに使ってもらえてるのでFBをもらいやすいこと、Rustを書くのが楽しいことが要因で熱量高く取り組めている。

行った主要な機能追加は以下の通り。

コマンドの実行履歴機能の追加@v0.19.0
pnpm scriptsのサポート@v0.39.0
yarn scriptsのサポート@v0.43.0
利用中のバージョンよりも新しいバージョンが存在する場合の通知機能@v0.48.0
プレビューウィンドウのためにbatコマンドを実行する方式からsyntectを利用してsyntax highlightを行うように変更(パフォーマンスが向上した)@v0.50.0
justのサポート@v0.52.0

来年はnpm、taskfileのサポートやaptでの配信などにも着手しようと画策中。

また、ある程度機能が揃ってきたタイミングでユーザー数を増やすアクションをしようと思い、zenn、Reddit, Hacker Newsに記事を投稿した。

広報活動の甲斐もあってかGitHubのstar数が100を突破した。

記事へのリアクションはHacker News < Zenn < Redditの順で多かったが、流入数が一番多かったのはHacker Newsだった。おそらくアクティブユーザーのケタが違いそう。

さらには夢の1つだった自分のツールがhomebrew-coreに取り込まれるということも達成できた。実は本家homebrewに取り込まれるためにはある程度有名でユーザー数が多いこと、などの基準があるためいつかfzf-makeがある程度有名になったといえるタイミングでPRを送ろうと考えていた。

が、あるときたまたまhomebrewのメンテナによってfzf-makeがhomebrew/homebrew-coreに追加されるPRを発見しfzf-makeがhomebrewに取り込まれたことを知ることとなった。自分としては思わぬ早めのクリスマスプレゼントのような感じで本当に嬉しかった。

その喜びと感謝を伝えたところメンテナの方からこんなコメントをもらった。

In addition to maintaining Homebrew, I search for awesome software that we don’t currently ship so that I can add it for distribution. Was happy to find fzf-make and ship it! おめでとう〜！

https://github.com/kyu08/fzf-make/issues/195#issuecomment-2533563544

自分がつくったソフトウェアがhomebrewメンテナの方に必要だと思ってもらえて純粋に嬉しかったし、たった一言でもわざわざ日本語で祝福してくれたのも大変心に響いた。

GoでWeb APIサーバを作る際のパッケージ構成について検討した

業務のWeb APIサーバーの実装の課題と改善策を考えているときにふと「現時点での自分の理想のGo APIサーバーのアーキテクチャ」のぼんやりとした像はあれど実装したことがないことに気付いたので書いてみることにした。

GitHub - kyu08/go-api-server-playground: GoでAPI Serverを書くときのもろもろを検証するレポ

GoでAPI Serverを書くときのもろもろを検証するレポ. Contribute to kyu08/go-api-server-playground development by creating an account on GitHub.

https://github.com/kyu08/go-api-server-playground

Twitterのクローンアプリを題材にした。主にレイヤー分けの方法に注力しつつ次のような技術キャッチアップも兼ねて作った。(その他の使用技術はREADME参照)

gRPC
構造化ログ
runnを使ったE2Eテスト
docker composeを自分でイチから書く
sqlcを使ってsqlからコード生成

なんとなく形になりかけたところで忙しくなり中途半端になってしまったので来年どこかで再開したい。

ブログ

サマリ:

17本の記事を書いた
『ベタープログラマ』を読んだがはてぶのトップページに載った
こんな感じでデザインを変更した。

3月に書いた『ベタープログラマ』を読んだがたくさんの人の読んでいただけて、はてぶのトップページに掲載された。

優秀なエンジニアの振る舞いについて様々な角度から考察されていて大変参考になった。

他に印象に残っている記事は以下。

ブログでのアウトプットを通して自分の学びを整理したり、記憶に定着させることができている実感があるので来年も続けていく。

読書など

読んだ本や受講した講座:

CS50
ベタープログラマ
いちばんやさしいアジャイルの開発の教本
読み手につたわる文章 - テクニカルライティング
Goならわかるシステムプログラミング第2版

CS50を受講し、『Goならわかるシステムプログラミング第2版』を読んだことでCSの基礎的な部分を学ぶことができた。両方とも手を動かしながら学べる形式だったので楽しく理解を深めることができた。³

そこで得た学びをもとに、次は『コンピュータシステムの理論と実装第2版』をやっていく。その次はネットワーク系にも手を出したい。

生活

運動と早寝早起き

運動と早寝早起きによって頭がスッキリしてパフォーマンスが上がる感覚があったので今年の春くらいから意識的に取り組んだ。

リングフィットは運動のハードルを下げられるし楽しく運動できて良い反面、有酸素運動をするのであれば普通にランニングした方が運動強度を高めやすくて良さそう。（が、冬の時期は着替えが面倒だし寒いのでなかなか走りに行けなかった）

あとは早めに風呂に入ると早めに眠くなるので早寝早起きしやすい、という当たり前すぎることを感じた。

舌下治療をはじめた

11月中旬から開始した。来年の2月ごろには効果が出るらしいので楽しみ。

買ってよかったもの

スタンディングデスク(FlexispotのE7)
MX Ergo S
- MX Ergoから乗り換えたが静かでボタンの押し心地も良くなっていて満足。
LogicoolのWebカメラ(C980GR)
デスク用の足元パネルヒーター
脱衣所に置く小型セラミックヒーター
THE NORTH FACEのダウン

仕事

チーム内のコミュニケーションやドキュメンテーションなどチーム改善にコミットする時間が去年までよりも長かった。チームを変えることの難しさやうまくいったときの達成感を感じることができてよかった。
これまでよりも不確実性と向き合った。目的不確実性がある中でのプロジェクトの進め方、アサインやタスクの着手順などについて考えることが多かったのがいい経験だった。改めて『エンジニアリング組織論への招待』を読み返そうと思う。

2025年の抱負

仕事関係で大きめの変化があるのでしっかりとバリューを出して事業貢献できるように頑張っていきたい。
CSの勉強を続けてソフトウェアエンジニアの土台となるような知識を固めていきたい。来年はこのあたりに注力する予定。
- OS
- ネットワーク
- コンテナ技術(というかk8s)

おわりに

振り返ると結構いろいろやれた。来年もやっていき。

去年の振り返り: 2023年を振り返る

Ownerが自分以外のPublic Repositoryを対象に集計。 ↩︎
別記事を書くときのための自分用のメモ https://gist.github.com/kyu08/29f27ea93e8566759c89db001c47b3cb ↩︎
CS50の課題でC言語の大変さを学べたのもいい思い出。 ↩︎

RFC 2606: Reserved Top Level DNS Namesを読んで知らなかったことを書く

Sun, 15 Dec 2024 15:00:00 +0000

本記事はUnipos Advent Calendar 2024の16日目の記事です。

ふいに見かけたRFC 2606: Reserved Top Level DNS Namesを読んでみたところ発見があったのでその内容をまとめてみようと思います。

RFC 2606の概要

Abstract

To reduce the likelihood of conflict and confusion, a few top level domain names are reserved for use in private testing, as examples in documentation, and the like. In addition, a few second level domain names reserved for use as examples are documented.

対立や混乱を減らす目的でいくつかのTLD名が予約されている。用途はプライベートなテスト用、ドキュメントでの例示用など。
上記に加えて例示用にいくつかのSecond Level Domain Namesが予約されている。

予約されたTop Level Domain Names

There is a need for top level domain (TLD) names that can be used for creating names which, without fear of conflicts with current or future actual TLD names in the global DNS, can be used for private testing of existing DNS related code, examples in documentation, DNS related experimentation, invalid DNS names, or other similar uses.

DNSのプライベートテスト用やドキュメントなどの目的で使用できるTLD名が必要であるとのこと。（DNSへの解像度がとても低いので具体的にどんなテストが行われるのかの想像はついていない…）¹

To safely satisfy these needs, four domain names are reserved as listed and described below.
            .test
         .example
         .invalid
       .localhost
“.test” is recommended for use in testing of current or new DNS related code.

“.example” is recommended for use in documentation or as examples.

“.invalid” is intended for use in online construction of domain names that are sure to be invalid and which it is obvious at a glance are invalid.

The “.localhost” TLD has traditionally been statically defined in host DNS implementations as having an A record pointing to the loop back IP address and is reserved for such use. Any other use would conflict with widely deployed code which assumes this use.

上記のニーズを満たすために、次の4つのTLD名が予約されている。

.test: 既存のまたは新規のDNS関連コードのテストに使用することが推奨されている。
.example: ドキュメントや例示として使用することが推奨されている。
.invalid: 無効であることが確実で一目で無効であることが明らかなドメイン名をオンラインで構築する際に使用することを目的としている。
.localhost: 伝統的にホストDNS実装においてループバックIPアドレスを指すAレコードを持つものとして静的に定義されておりこのような使用のために予約されている。

.invalidの説明がわからなかったのでWikipadiaを参照してみたところ次のような記述があった。

This top-level domain is sometimes used as a pseudo domain name in Uniform Resource Identifiers (URIs) to convey either an error condition or in use of privacy protection.

https://en.wikipedia.org/wiki/.invalid より引用

要はエラーケースのテストのためやプライバシー保護の目的で擬似ドメイン名として利用されることがある、と理解した。(このあたりの深い理解は別途時間をとりたい)

これらのTLD名は見たことはあったがRFCとして明示されていることは知らなかった。

予約されたSecond Level Domain Names

3 Reserved Example Second Level Domain Names

The Internet Assigned Numbers Authority (IANA) also currently has the following second level domain names reserved which can be used as examples.
 example.com
 example.net
 example.org

example.com以外にもexample.netとexample.orgが予約されていることは知らなかった。

また、4. IANA Considerationsにも記述があるが、本文章で示されたTLD名およびSecond Level Domain名はInternet Assigned Numbers Authority(IANA)によって予約される。

著作権表示

Copyright (C) The Internet Society (1999). All Rights Reserved.

This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English.

感想

はじめてRFCを読んだ。部分的に馴染みのある内容だったし文量としても多くなかったのでスムーズに読めた。

これまでは「誰かがテスト用ドメインとしてexample.comを抑えてくれているのでテスト用に使ってOK」という程度の理解だったが、いくつかのDomain名がテスト、例示目的で予約されることがRFCで明示されておりIANAが実際にそれらを予約していることでテスト用ドメインが利用できているということを知ることができた。

物事を正確に理解するとトラブルシューティングや改善も素早くできるはずだし、知らなかったことをブログに書くと自分の理解も捗る(あと純粋に楽しい)ので、これからも自分の理解が曖昧なことを理解し共有する営みをやっていきたい。

改めてネットワークは本当に何もわからないのでこの冬に時間をとって勉強したい。² ³

Linuxで動かしながら学ぶTCP/IPネットワーク入門や体験しながら学ぶネットワーク技術入門あたりで腰を据えてネットワーク周りを学びたい…。 ↩︎
が、次はコンピュータシステムの理論と実装第2版をやると決めているのでやるとしたらその次かな…。 ↩︎
ちなみに、他のRFCを眺めていたらSHOULD, MUSTのようなキーワードが大文字で強調されていたが、それらのキーワードの解釈についてはRFC 2119: Key words for use in RFCs to Indicate Requirement Levelsで説明されていたのでよければ参照ください。 ↩︎

ソフトウェアエンジニア目線で使ってみて便利だったChrome拡張を紹介する

Thu, 12 Dec 2024 15:00:00 +0000

本記事はUnipos Advent Calendar 2024の13日目の記事です。

本記事では使ってみて便利だったChrome拡張を紹介します。

Stylus

ユーザー定義のCSSを手軽に適用できるChrome拡張です。

筆者の使い方としてはNotionのガントチャートを見やすくしたり、GitHubのUIの幅を大きくしたりしています。PR上で実行計画を見る際などにスクロールしなくてよくなり便利になりました。

Google search results shortcuts

Google検索結果のページでキーボードショートカットを使えるようにするChrome拡張です。

筆者がよく使うのは以下です。

↑: 1つ上の検索結果に移動
↓: 1つ下の検索結果に移動
Enter: 選択中の検索結果を開く

以下のような操作がキーボードだけでできるようになります。¹

Vimium

言わずと知れたvimのような操作感でChromeを操作できるChrome拡張です。

あらゆる操作をキーボードだけで行いたいと考えている筆者にとってはなくてはならない拡張です。²

基本的な操作方法についてはたくさんの情報があると思いますのでここでは筆者のキーマップや最近知った機能について紹介します。

まずキーマップについてですが、以下のようにして左手だけで操作しやすいように設定しています。

map q goBack
map d goForward
map s scrollPageUp
map a scrollPageDown
map w scrollDown
map e scrollUp

また、最近知ったvimiumの機能についても紹介したいと思います。ふとREADMEを眺めていたら

gi      focus the first (or n-th) text input box on the page. Use <tab> to cycle through options.

という記述を見つけました。

フォーカスできるテキストボックスが1つの場合はその要素にフォーカスが当たり、複数の場合はタブで切り替えることができます。これまではマウスを使ってフォーカスを当てていましたがこれを知ってからマウスへの依存をより下げることができました。

GCP console colorize

Google Cloudのプロジェクトごとにヘッダーの色を変更するChrome拡張です。

以下のようにプロジェクトごとに色を分けておくとうっかり間違って操作することを防ぎやすくなります。（環境ごとに適切な権限管理をするのは前提として）

環境	イメージ画像
project-a
project-b

LTTM

PRレビューの際にいい感じの画像を手早く貼ることができるChrome拡張です。

PR上でのコミュニケーションが捗っています。

find+ | Regex Find-in-Page Tool

正規表現を使ってページ内を検索できるChrome拡張です。

便利です。

Notion Sidebar Tamer

Notionのサイドバーにマウスカーソルが近づいたときにサイドバーが表示されるのを防ぐChrome拡張です。

1日に1回はこの挙動にストレスを感じていたのでQOLが上がりました。

たとえば次のようなNotionページの赤枠部分をコピーしたいとします。

コピーするには赤枠の左あたりにカーソルを持っていく必要がある³のですが判定が結構厳しいので意図せずサイドバーが表示されてしまうことがよくあります。

そこでNotion Sidebar Tamerを使うとカーソルをサイドバー付近に移動してもサイドバーが表示されなくなります。やったね！

おわりに

Chrome拡張開発者のみなさんに圧倒的感謝…！

ちなみに可愛い動物が表示されているのはTabby Catの機能です。cmd + Tで新しいタブを開くと可愛い動物たちとchillな時間を過ごすことができます。 ↩︎
早くNotionとSlackがキーボードだけで操作できるようになってほしいです。あわよくば誰か完璧なTUIクライアントを作ってください。 ↩︎
このケースだとカーソルを右側に持っていってコピーすることもできますが普段は左側に持っていかないとコピーが難しいケースが多いためこのように書いています。具体的なケースが思い出せたら記事を修正しようと思います。 ↩︎

Notionのダークモードのガントチャートが見づらいのをChrome拡張で修正する方法

Fri, 08 Nov 2024 14:34:37 +0000

できること

Notionのガントチャートが見づらいのをなんとかするスクリプト

Before

After

前提条件

NotionをChromium系のブラウザで利用していること

やり方

下記のリンクからStylusをインストール https://chromewebstore.google.com/detail/stylus/clngdbkpkpeebahjckkjfobafhncgmne?hl=ja
Manageをクリックして管理画面を開く
Write new styleをクリック

次のCSSを入力しURLのブロックにURLs starting with: https://www.notion.so/を指定しSaveをクリック

.notion-selectable.notion-page-block.notion-timeline-item a {
    background: rgba(255, 255, 255, 0.15)
}

みやすくなる

『Goならわかるシステムプログラミング第2版』を読んだ

Sun, 03 Nov 2024 12:42:30 +0000

『Goならわかるシステムプログラミング第2版』をサンプルコードを手元で実行しつつ一通り読んだ。(期間としては2024/6/8 ~ 2024/11/4でコミットした日数としてはおおよそ24日ほどだった。)

筆者は情報系の学部を出ておらず、CSなどの基礎知識があまりないので大変勉強になった。また、サンプルコードが豊富なので実際に自分のマシン上で動かしながら学ぶことができ解像度を上げながら理解を深めることができた。

低レイヤ、コンピューターサイエンスの学習に興味がある方にはとてもおすすめなのでぜひ買って読んでみてください。

Goならわかるシステムプログラミング第2版

Go言語による新時代のコンピュータシステム入門渋川よしき著 424ページ A5判 ISBN：978-4-908686-12-2 2022年3月23日第2版第1刷発行いつも開発に使っている言語やライブラリの裏側は、いったいどうなっ

https://www.lambdanote.com/products/go-2

手元で実行したコードは以下のリポジトリにまとめた。

GitHub - kyu08/go-system-programming: 『Goならわかるシステムプログラミング』の写経リポジトリ

『Goならわかるシステムプログラミング』の写経リポジトリ. Contribute to kyu08/go-system-programming development by creating an account on GitHub.

https://github.com/kyu08/go-system-programming

以下読書メモ。

第1章 Go言語で覗くシステムプログラミングの世界

デバッガを使ってfmt.Printlnの動作をシステムコールまで追った。¹
当然だがデバッガを使うと変数の中身に何が入ってるかがわかって便利。
デバッガを使ってみて別パッケージのprivate変数の中身を見ることができるのはプリントデバッグにはないデバッガの利点だと気づいた。

第2章低レベルアクセスへの入口1：io.Writer

io.WriterはOSが持つファイルのシステムコールの相似形
OSでは、システムコールをファイルディスクリプタと呼ばれるものに対して呼ぶ。
ファイルディスクリプタ(file descriptor)は一種の識別子（数値）で、この数値を指定してシステムコールを呼び出すと、数値に対応するモノへとアクセスできる。
ファイルディスクリプタはOSがカーネルのレイヤーで用意している抽象化の仕組み。
OSのカーネル内部のデータベースに、プロセスごとに実体が用意される。
OSはプロセスが起動されるとまず3つの擬似ファイルを作成し、それぞれにファイルディスクリプタを割り当てる。
- 0が標準入力、1が標準出力、2が標準エラー出力。
- 以降はそのプロセスでファイルをオープンしたりソケットをオープンしたりするたびに1ずつ大きな数値が割り当てられていく。

複数のファイルf1, f2をos.Create()する処理をデバッガーで追ってみたところ、それぞれファイルディスクリプタの値が3, 4²となっておりファイルディスクリプタの値が3からインクリメントされる様子を確認できた。

第3章低レベルアクセスへの入口1：io.Reader

エンディアン変換

リトルエンディアンでは、10000という数値(0x2710)をメモリに格納するとき下位バイトから順に格納する。
ビッグエンディアンでは、上位バイトから順に格納する。
現在主流のCPUではリトルエンディアンが採用されている。
ネットワーク上で転送されるデータの多くはビッグエンディアンが用いられている。
そのため多くの環境ではネットワークで受け取ったデータをリトルエンディアンに変換する必要がある。

`io`パッケージのいくつかの関数 / 構造体 / インターフェースの使い方

io.Pipe³
io.LimitReader: 先頭のnバイトだけ読み込む
io.MultiReader: 複数のio.Readerを1つのio.Readerにまとめる
io.SectionReader: offsetとnを指定して一部のデータだけ読み込む

第4章チャネル

普段goroutineを全然使わないので忘れていることが多かった。以下学んだことメモ。

バッファなしチャネルでは、受け取り側が受信しないと、送信側もブロックされる。⁴
for task := range tasks // tasksは任意のchのように書くと、チャネルに値が入るたびにループが回り、チャネルがクローズされるまでループが回る。

第5章システムコール

システムコールとは特権モードでOSの機能を呼ぶこと。

CPUの動作モード

OSの仕事は以下の2つ
- 各種資源（メモリ、CPU時間、ストレージなど）の管理
- 外部入出力機能の提供（ネットワーク、ファイル読み書き、プロセス間通信）
動作モード
- 実行してよいハードウェアとしての機能がソフトウェアの種類に応じて制限されている
- OSが動作する特権モード
- 一般的なアプリケーションが動作するユーザーモード

システムコールが必要な理由

通常のアプリケーションでメモリ割り当てやファイル入出力、インターネット通信などの機能を使うために必要なのがシステムコール
システムコールがなくてもCPUの命令そのものはほとんど使うことができる
しかし、ユーザーモードでは計算した結果を画面に出力したり、ファイルに保存したり外部のWebサービスに送信したりできない。

dtrussコマンドを使ってシステムコールの呼び出しを確認しようとしたがmacOSのセキュリティの設定上何も表示されなかったのでDocker上でLinuxを起動して確認してみることにした。

docker run -it --name stracetest golang:1.22.4-alpine3.19
apk add strace

go mod init kyu08/stracetest
# 任意のgoファイルを作成
go build ./...
strace -o strace.log ./実行ファイル
less strace.log

今回はf, _ := os.Create("test_file.txt")とdefer f.Close()を実行するだけのgoプログラムを実行したときのシステムコールのログを確認した。以下はその一部。

rt_sigaction(SIGRT_32, {sa_handler=0x70d90, sa_mask=~[], sa_flags=SA_ONSTACK|SA_RESTART|SA_SIGINFO}, NULL, 8) = 0
rt_sigprocmask(SIG_SETMASK, ~[], [], 8) = 0
clone(child_stack=0x400001c000, flags=CLONE_VM|CLONE_FS|CLONE_FILES|CLONE_SIGHAND|CLONE_THREAD|CLONE_SYSVSEM) = 890
rt_sigprocmask(SIG_SETMASK, [], NULL, 8) = 0
--- SIGURG {si_signo=SIGURG, si_code=SI_TKILL, si_pid=889, si_uid=0} ---
rt_sigreturn({mask=[]})                 = 1139696
rt_sigprocmask(SIG_SETMASK, ~[], [], 8) = 0
clone(child_stack=0x4000062000, flags=CLONE_VM|CLONE_FS|CLONE_FILES|CLONE_SIGHAND|CLONE_THREAD|CLONE_SYSVSEM) = 891
rt_sigprocmask(SIG_SETMASK, [], NULL, 8) = 0
futex(0x4000080148, FUTEX_WAKE_PRIVATE, 1) = 1
futex(0x4000048948, FUTEX_WAKE_PRIVATE, 1) = 1
prlimit64(0, RLIMIT_NOFILE, NULL, {rlim_cur=1024*1024, rlim_max=1024*1024}) = 0
fcntl(0, F_GETFL)                       = 0x20002 (flags O_RDWR|O_LARGEFILE)
futex(0x4000049148, FUTEX_WAKE_PRIVATE, 1) = 1
fcntl(1, F_GETFL)                       = 0x20002 (flags O_RDWR|O_LARGEFILE)
fcntl(2, F_GETFL)                       = 0x20002 (flags O_RDWR|O_LARGEFILE)
openat(AT_FDCWD, "test_file.txt", O_RDWR|O_CREAT|O_TRUNC|O_CLOEXEC, 0666) = 3
futex(0x115ea0, FUTEX_WAKE_PRIVATE, 1)  = 1
futex(0x115db8, FUTEX_WAKE_PRIVATE, 1)  = 1
fcntl(3, F_GETFL)                       = 0x20002 (flags O_RDWR|O_LARGEFILE)
fcntl(3, F_SETFL, O_RDWR|O_NONBLOCK|O_LARGEFILE) = 0
epoll_create1(EPOLL_CLOEXEC)            = 4
pipe2([5, 6], O_NONBLOCK|O_CLOEXEC)     = 0
epoll_ctl(4, EPOLL_CTL_ADD, 5, {events=EPOLLIN, data={u32=1549912, u64=1549912}}) = 0
epoll_ctl(4, EPOLL_CTL_ADD, 3, {events=EPOLLIN|EPOLLOUT|EPOLLRDHUP|EPOLLET, data={u32=3997171713, u64=18446585726557487105}}) = -1 EPERM (Operation not permitted)
fcntl(3, F_GETFL)                       = 0x20802 (flags O_RDWR|O_NONBLOCK|O_LARGEFILE)
fcntl(3, F_SETFL, O_RDWR|O_LARGEFILE)   = 0
close(3)                                = 0
exit_group(0)                           = ?
+++ exited with 0 +++

openat(AT_FDCWD, "test_file.txt", O_RDWR|O_CREAT|O_TRUNC|O_CLOEXEC, 0666) = 3の部分でファイルが作成され、ファイルディスクリプタに3が割り当ている
close(3) = 0の部分でdefer f.Close()に相当する処理が行われている

ということを確認できた。

第6章 TCPソケットとHTTPの実装

ソケットとは

ほとんどのOSではアプリケーション層からトランスポート層のプロトコルを利用するときのAPIとしてソケットという仕組みを利用している
HTTP/1.0と1.1はこのソケットのバイトストリーム上に作られたテキストを使ったプロトコル

ソケットの種類（本書で説明するもののみ）

TCP：一番使われている。安定性が高い。
UDP：通信開始が早い。相手に一方的に送りつける。
Unixドメインソケット：ローカル通信でしか使えないが最速。

ソケット通信の基本構造

どんなソケット通信も基本となる構成は次のような形態
- サーバー：ソケットを開いて待ち受ける
- クライアント：開いているソケットに接続し、通信する
GoではTCP通信が確立されると、送信側、受信側の両方に相手との通信するnet.Connインタフェースを満たすオブジェクトが渡ってくる

Goに組み込まれているTCPの機能（`net.Conn`）だけを使ってHTTPによる通信を実現する

net.Connだけを使ってTCPソケットの初期化や通信の確立などの普段ならnet/httpがやってくれている部分を実装した。
http.ListenAndServe()のコードを読んでみたら、golang/go/src/net/http/server.go#L3258で本書のハンズオンと同じようにTCPソケットの初期化を行っていることを確認できた。

素朴な実装の速度改善

①Keep-Aliveへの対応
- HTTP/1.1から入った規格
- HTTP/1.0ではセットの通信が終わるたびにTCPコネクションが切れる仕様になっていたが、Keep-Aliveを使うことで、しばらくの間はTCP接続のコネクションを維持して使い回すことができる。
- TCP接続の通信には一定のオーバーヘッドがあるが、Keep-Aliveを使うことでそのオーバーヘッドを削減できる。
②レスポンスの圧縮
- レスポンスを圧縮することで、通信量を削減でき速度向上につながる。
- レスポンスヘッダーは圧縮されないため、少量のデータを通信する場合は効率が悪くなる。そのため実際のデータ量に応じて圧縮するかどうかを判断する必要がありそう。
③チャンク形式のボディー送信
- 動画など大きいデータを送信する場合、データを分割して送信することでデータの送信が完了する前に受信側でデータを処理できるようになる。また、すべてのデータをメモリに展開する必要もなくなるのでメモリの使用量を抑えることができるというメリットもある。
- チャンク形式ではヘッダーに送信データのサイズを書かないかわりにTransfer-Encoding: chunkedというヘッダーを付与する。
④パイプライニング
- 送受信を非同期化する方法

第7章 UDPソケットを使ったマルチキャスト通信

UDPとTCPの用途の違い

UDPはTCPと同じトランスポート層のプロトコルで以下のような特徴がある。

誰と繋がっているか管理しない
データロスの検知をすることも通信速度の制限をすることもしない
パケットの到着順序も管理しない
複数のコンピュータに同時にメッセージを送ることが可能な「マルチキャスト」と「ブロードキャスト」をサポートしている。（TCPにはない機能）
UDPの利用例としてはDNSやNTP, WebRTCなどがある。

UDPのマルチキャストの実装例

マルチキャストはリクエスト側の負担を増やすことなく多くのクライアントに同時にデータを送信できる仕組み。

UDPとTCPの機能面の違い

TCPには再送処理とフロー処理がある。

再送処理

TCPでは送信するメッセージにシーケンス番号が入っているので、受信側ではこの数値をみることでパケットの順序を管理できる。
受信側はメッセージを受け取ると、受信したデータのシーケンス番号とペイロードサイズの合計を確認応答番号として返信する。
送信側はこの応答確認番号が受け取れなかった場合に再送処理を行う。

フロー処理

受信側がリソースを用意できていない状態で送信リクエストが集中して通信内容が失われるのを防ぐための仕組みをウィンドウ制御という。
- 具体的には、受信用のバッファ（ウィンドウ）をあらかじめ決めておき送信側ではそのサイズまでは受信側からの受信確認を待たずにデータを送信できる。
受信側のデータの読み込みが間に合わない場合には、受信できるウィンドウサイズを受信側から送信側に伝えて通信量を制御できる。これをフロー制御という。

フレームサイズ

UDPレイヤーで取り扱えるデータは約64キロバイトまで。
UDPではデータの分割などはアプリケーションで面倒を見る必要がある。

輻輳制御とフェアネス

輻輳制御とは、ネットワークの輻輳（渋滞）を避けるように流量を調整し、そのネットワークの最大効率で通信できるようにするとともに複数の通信をお互いにフェアに行うための仕組み。
TCPには輻輳制御が備わっており、そのアルゴリズムにはさまざまな種類がある。
UDPにはTCPのような輻輳制御の仕組みはなく、流量の制御はUDPを利用する各プログラムに委ねられている。そのため、UDPとTCPを利用するアプリケーションがそれぞれあって、UDPを利用するアプリケーションでフェアネスが考慮されていない場合には、両方の通信が重なった時に遠慮する機能が組み込まれたTCPの通信速度だけが極端に落ち込むこともある。

第8章高速なUnixドメインソケット

UnixドメインソケットはPOSIX系OSで提供されている機能で、コンピュータ内部でしか使えない代わりに高速な通信が可能。
Unixドメインソケットには、TCP型（ストリーム型）とUDP型（データグラム型）の両方の使い方ができる。

Unixドメインソケットの基本

TCPとUDPによるソケット通信が外部のネットワークにつながるインターフェースに接続するのに対し、Unixドメインソケットはカーネル内部で完結する高速なネットワークインターフェースを作成する。
Unixドメインソケットを使うことで、ウェブサーバーとNGINXなどのリバースプロキシとの間、あるいはウェブサーバーとデーターベースとの間の接続を高速にできる場合がある。
Unixドメインソケットを開くには、ファイルシステムのパスを指定する。サーバープロセスを起動するとファイルシステム上の指定したパスにソケットファイルが作成される。
Unixドメインソケットで作成されるのはソケットファイルと呼ばれる特殊なファイルであり、通常のファイルのような実体を持たない。あくまでもプロセス間の高速な通信としてファイルというインターフェースを利用するだけ。

以下はソケットファイルが作成されている様子。ソケットファイルは先頭が"s"で始まる。

UnixドメインソケットとTCPのベンチマーク

Unixドメインソケットを使った実装とTCPを経由した実装のベンチマークの比較をすると筆者の環境だとUnixドメインソケットの方が10倍ほど高速だった。

$ go test -bench . -benchmem
goos: darwin
goarch: arm64
pkg: github.com/kyu08/go-system-programming/bench
BenchmarkTCPServer-8                4165            327038 ns/op           52175 B/op        110 allocs/op
BenchmarkUDSStreamServer-8         42742             27837 ns/op           16762 B/op         59 allocs/op
PASS
ok      github.com/kyu08/go-system-programming/bench    4.788s

第9章ファイルシステムの基礎とGo言語の標準パッケージ

この章ではosパッケージとpath/filepathパッケージの主要な関数の使い方が紹介されていた。

ファイル/ディレクトリを扱うGo言語の関数たち

2つのファイルの同一性の判定: os.Samefile()
ファイルのパーミッション、オーナー、タイムスタンプの変更: os.Chmod(), os.Chown, os.Chtimes()
ハードリンク、シンボリックリンクの作成: os.Link, os.Symlink()
ファイル一覧の取得: dir, _ := os.Open(path) -> dir.Readdir()

OS内部におけるファイル操作の高速化

CPUにとってディスクの読み書きはとても遅い処理であり、なるべく最後までやらないようにしたい。LinuxではVFSの内部に設けられているバッファを利用することでディスクに対する操作をなるべく回避している。

`path/filepath`パッケージの関数たち

パスの最後の要素を返す: filepath.Base()
パスのディレクトリ部分を返す: filepath.Dir()
パスをディレクトリとパス名に分割する: filepath.Split()
ファイルの拡張子を返す: filepath.Ext()
/some/../pathやanother//pathのような形式のパスを整える: filepath.Clean()
パターンにマッチするファイルの判定: filepath.Match()
ディレクトリのトラバース: filepath.Walk()

想像よりも標準パッケージでいろんなことができるのでこの辺りの操作をしたくなったら自作関数を書く前に標準パッケージを探してみるのが良さそうだと思った。

第10章ファイルシステムの最深部を扱うGo言語の関数

ファイルの変更監視（`syscall.Inotify`）

プログラムでファイルを監視する方法には次の2種類がある。

監視したいファイルをOS側に通知しておいて、変更があったら教えてもらう（パッシブな）方式
タイマーなどで定期的にフォルダを走査し、os.Stat()などを使って変更を探しに行く（アクティブな）方式

アクティブな方式の方がコード量は少ないが監視対象が増えるとCPU負荷やIO負荷が増える。

パッシブな方式はファイルの変更検知が各OSでシステムコールやAPUIとして提供されている一方で環境ごとのコード差は大きくなる。

ここでは fsnotify/fsnotify.v1を用いてファイルの変更検知プログラムを作成した。

fsnotify.v1では、Linuxの場合はinotify系APIが、BSD系OSの場合はkqueueが使われている。

ファイルのメモリへのマッピング（`syscall.Mmap()`）

syscall.Mmap()を使うことでファイルの中身をそのままメモリ上に展開したり、メモリ上で書き換えた内容をそのままファイルに書き込むことができる。

edsrzf/mmap-goではmmap.Map()を使うことでファイルをメモリに展開できる。mmap.Map()は次のようなシグネチャを持つ。

func Map(f *os.File, prot, flags int) (MMap, error)

2つ目の引数に次のような値を指定することでメモリ領域に対して許可する操作を設定できる。

mmap.RDONLY: 読み込み専用
mmap.RDWR: 読み書き可能
mmap.EXEC: 実行可能にする
mmap.COPY: コピーオンライト

コピーオンライトが指定されると、複数のプロセスが同じファイルをマッピングしているときに、カーネル上は1つ分のみメモリ領域が使用され、それ以上のメモリを消費しない。

しかし、その領域内でメモリ書き換えが発生すると、その領域がまるごとコピーされる。このようにすることでメモリ消費量をうまく節約できる。

同期・非同期 / ブロッキング・ノンブロッキング

同期処理: OSにI/Oタスクを投げて、入出力の準備ができたらアプリケーションに処理が返ってくる
非同期処理: OSにI/Oタスクを投げて、入出力の準備ができたら通知をもらう
ブロッキング処理: お願いしたI/Oタスクの結果の準備ができるまで待つ（自分は停止）
ノンブロッキング処理: お願いしたI/Oタスクの結果の準備ができるのを待たない（自分は停止しない）

select属のシステムコールによるI/O多重化

非同期・ブロッキングは1スレッドでたくさんの入出力を効率よく扱うための手法でありI/O多重化とも呼ばれる。それを効率よく実現するAPIのことを本書ではselect属と総称する。

並行処理を使うことで小さい規模のI/Oの効率化は十分に行えるが、select属はC10K問題と呼ばれる、万の単位の入出力を効率よく扱うための手法として有効。

第11章コマンドシェル101

シェルとは、ユーザーがコンピューターを操作するために使う接点となるシステムにおいてコンピューターシステムの殻（shell）となるプログラムのこと。

シェルがないシステム

Distrolessと呼ばれるコンテナイメージはシェルがないため、セキュリティホールをついてシステムに侵入されることがない。⁵（当然攻撃の脅威がゼロになるわけではない）

シェルがコマンドを起動するまで

シェルがコマンドを起動するまでには次のようなことを行っている。

ユーザーの入力を受け付ける
入力されたテキストの分解
コマンドと引数の前処理
実行ファイルの探索
ワイルドカードの展開
プロセスの起動

「11.5.3コマンドと引数の前処理」で紹介されていたが、$(which nvim)と同様に`which nvim`でもコマンドの実行結果を変数に代入できるのは知らなかった。

第12章プロセスの役割とGo言語による操作

OSが実行ファイルを読み込んで実行するには、そのためのリソース（CPU、メモリ）を用意する必要がある。そのようなリソースをまとめたプログラムの実行単位のことをプロセスと呼ぶ。プロセスはOSが実行ファイルを読み込んで実行するときに新しく作られる。
プロセスにはプロセスごとにユニークな識別子がある。（プロセスID）。Go言語ではos.Getpid()で取得できる。

プロセスの入出力

すべてのプロセスは少なくとも次の3つの入出力データを持っている。

入力：コマンドライン引数
入力：環境変数
出力：終了コード

OSから見たプロセス

OSの仕事はたくさんあるプロセスに効率よく仕事をさせること
Linuxではプロセスごとにtask_struct型のプロセスディスクリプタと呼ばれる構造体を持っている。
- 基本的にはプロセスから見た各種情報と同じ内容だが、そこには含まれていない要素もいくつか存在する。
- 例えば、どこからどこまでが自分のメモリ領域かというメモリブロックの情報やスタック領域がどこにありプログラムが静的に確保するデータや動的に確保するデータがどのようにレイアウトされるかもOSが持つプロセスの情報の中にある。

プロセスの出力に色づけをする

プロセスの出力に色をつけたい場合にはANSIエスケープシーケンスを使うことができる。

自分が利用したことある⁶Rustのcoloredクレートも確認したところ実際にANSIエスケープシーケンスを使ってターミナルに色をつけていた。

    #[cfg_attr(feature = "no-color", ignore)]
    #[test]
    fn compute_style_simple_fg_blue() {
        let blue = "\x1B[34m";

        assert_eq!(blue, "".blue().compute_style());
    }

colored/src/lib.rs at 775ec9f19f099a987a604b85dc72ca83784f4e38 · colored-rs/colored

(Rust) Coloring terminal so simple you already know how to do it ! - colored-rs/colored

https://github.com/colored-rs/colored/blob/775ec9f19f099a987a604b85dc72ca83784f4e38/src/lib.rs#L805-L811

より

調べてみたところ\x1Bでも\eでもエスケープシーケンスを表現できるらしい。⁷

外部プロセスに対して自分が擬似端末だと詐称する

ライブラリによっては、自分が繋がっている先が擬似端末かどうかでエスケープシーケンスを出力するかどうかを決定している。

子プロセスの出力を色づけするためには、親を擬似端末だと詐称することでエスケープシーケンスを出力させることができる。

デーモン化

普通のプログラムはシェルのプロセスの子になってしまうので、ログアウトしたりシェルを閉じたりするだけで終了してしまう。

そのような場合でも終了しないように下記のような特別な細工が施されたプロセスがデーモンである。

セッションID、グループIDを新しいものにして既存のセッションとグループから独立
カレントのディレクトリはルートに移動
フォークしてからブートプロセスのinitを親に設定し、実際の親はすぐに終了
標準入出力も起動時のものから切り離される(通常はdev/nullに設定される)

第13章シグナルによるプロセス間の通信

シグナルには主に2つの用途がある。

プロセス間通信: カーネルが仲介してあるプロセスから別のプロセスへとシグナルを送るケース。自分自身にシグナルを送ることもできる。
ソフトウェア割り込み: システムで発生したイベントがシグナルとしてプロセスに送られる。シグナルを受け取ったプロセスは現在置くなっているタスクを中断してあらかじめ登録しておいた処理を実行する。

システムコールはユーザー空間で動作しているプロセスからカーネル空間にはたらきかけるためのインターフェースだが、その逆方向がシグナルだと考えることができる。

システムコールでは最大7つほどの引数を指定できるのに対し、ソフトウェア割り込みとしてのシグナルで送信できるのはその種類のみ。
プロセスは受け取ったシグナルを無視するか補足して処理する。

シグナルのハンドラを書く

Goでは次のようにsignal.NotifyContext()を使ってシグナルを受け取ることができる。

package main

import (
	"context"
	"fmt"
	"os/signal"
	"syscall"
	"time"
)

func main() {
	ctx := context.Background()
	sigctx, cancel := signal.NotifyContext(ctx, syscall.SIGINT, syscall.SIGTERM)
	defer cancel()
	toctx, cancel2 := context.WithTimeout(ctx, time.Second*5)
	defer cancel2()

	select {
	case <-sigctx.Done():
		fmt.Println("signal")
	case <-toctx.Done():
		fmt.Println("timeout")
	}
}

KubernetesやDockerでは外からタスクを終了させるとき、まずSIGTERMをアプリケーションに対して送信する。(SIGTERM: kill()システムコールやkillコマンドがデフォルトで送信するシグナル。プロセスを終了させるもの)

(GoアプリケーションのGraceful Shutdownの実装例でSIGTERMをハンドリングするのをよく見るのはだからか、と納得した。)

第14章 Go言語と並列処理

並行処理と並列処理の違い

並行処理: 1つのコアで複数のタスクを素早く切り替えながら処理すること
並列処理: 複数のコアを使って複数のタスクを同時に処理すること

チャネル

Go言語で簡単に並列処理を書くための道具としてgoroutineとチャネルがある。
チャネルを使うことでデータの入出力を直列化できる。

スレッドとgoroutineの違い

スレッドとはプログラムを実行するためのものであり、OSによって手配される。
プログラムからみたスレッドは「時間が凍結されたプログラムの実行状態」で、CPUが演算に使ったり計算結果や状態を保持したりするレジスタと呼ばれるメモリとスタックメモリが含まれる。
OSは凍結状態のプログラムの実行状態を復元して各スレッドに短時間ずつ処理をさせる。実行予定のスレッドはランキューと呼ばれるリストに入っている。
スレッドがCPUコアに対してマッピングされるのに対し、gouroutineはOSのスレッドにマッピングされる点が通常のスレッドとgoroutineとの最大の違い。
- goroutineはOSスレッドの1~2MBと比べると初期スタックメモリのサイズが小さい(2KB)ため起動処理が軽い。
- また、gouroutineはOSに処理を渡さずに作成できるのでカーネルとのタスク切り替えのコストも小さい。

goroutineのメリット

大量のクライアントからのリクエストを効率よく捌きたいとき（いわゆるC10K）に、クライアントごとに1つのgoroutineを割り当てたとしても少ないメモリ消費量で処理できる（前述の通りgoroutineは起動時の初期スタックメモリのサイズが小さいため）

第15章並行・並列処理の手法と設計のパターン

代表的な並行・並列処理の手法

マルチプロセス
イベント駆動
マルチスレッド
ストリーミング・プロセッシング

イベント駆動

主に並列化ではなく並行処理のために使われる。
I/Oバウンドなプログラムで用いられる。
OSに依頼したデータ受信の仕事が終わるたびにコールバックが返ってくる仕組み。
単体ではCPUを使いこなしにくい点が欠点。

マルチスレッド

同じメモリ空間内で多くのCPUが同時に実行するための仕組み
- Linuxではプロセスもスレッドもカーネル上は同じ構造体として表現されている。親のプロセスとメモリ空間を共有していなければプロセス、共有していればスレッド。
利点はCPUのパフォーマンスを引き出すことができる点。
欠点はプロセスほどではないが、OSのスレッドの場合は比較的大きなスタックメモリ（1~2MB）を必要とし、起動時間もややかかる。そのためスレッドプールを作っておき、必要になったらすぐ使えるようにする、ということが行なわれている。

Goにおける並行・並列処理のパターン集

アムダールの法則: 並列化を導入するとどれだけ効率が改善するかを表す数式

S(N) = 1 / ((1 - P) + P/N)

ここでPは並列化できる仕事の割合、Nは並列数である。

P = 0.5, N = ∞のとき、S(N) = 2倍になり、P = 0.9, N = ∞のとき、S(N) = 10倍になる。このことからもわかるように、並列数よりも並列化できるタスクの割合が支配的になる。

Pを改善するためのアイディアとして次のような手法が考えられる。

同期処理を非同期にする
非同期にしたものを同期化する
タスク生成と処理を分ける（Producer-Consumerパターン）
開始した順で処理する（チャネルのチャネル）
タスク処理が詰まったら待機（バックプレッシャー）
並列なForループ
決まった数のgoroutineでタスクを消化する（ワーカープール）
依存関係のあるタスクを表現する（Future/Promise）
イベントの流れを定義する（ReactiveX）
自立した複数のシステムで協調動作（アクターモデル）

同期 -> 非同期化

I/O処理などの重いタスクを非同期化する

非同期 -> 同期化

非同期化したタスクはどこかで同期化する必要がある。そのための一番簡単な手法がチャネル。

タスク生成と処理を分ける（Producer-Consumerパターン）

GoではチャネルでProducerとConsumerを接続することで簡単に実現できる。

開始した順で処理する（チャネルのチャネル）

チャネルを用いると複数の処理を終了した順に取り出すことができる。

// 終了した順に書き出し
// チャネルに結果が投入された順に処理される
func writeToConn(responses chan *http.Response, conn net.Conn) {
	defer conn.Close()
	// 順番に取り出す
	for response := range responses {
		response.Write(conn)
	}
}

チャネルのチャネルを使うと処理を開始した順で処理をできる。

// 開始した順に書き出し
// チャネルにチャネルを入れた(開始した)順に処理される
func writeToConn(sessionResponses chan chan *http.Response, conn net.Conn) {
	defer conn.Close()
	// 順番に取り出す
	for sessionResponse := range sessionResponses {
		// 選択された仕事が終わるまで待つ
        response := <-sessionResponse response.Write(conn)
	}
}

タスク処理が詰まったら待機（バックプレッシャー）

以下のようなバッファ付きチャネルを使うことで実現できる。

tasks := make(chan string, 10)

並列Forループ

forループ内の処理をgoroutineで実行することでループ処理を並列化できる。
ループ内部の処理が小さすぎるとオーバーヘッドのほうが大きくなり効率が上がらないことがあるので注意が必要。

決まった数のgoroutineでタスクを消化する（ワーカープール）

特にCPUバウンドな処理ではCPUのコア数以上にgoroutineを作ってもスループットは上がらないため、CPUコア数分のワーカーを作成してタスクを消化するのが効果的な場合がある。

依存関係のあるタスクを表現する（Future/Promise）

Futureをチャネルで表現すると、必要なデータが揃ったらタスクを逐次実行できる。

後続の処理に結果を引き継ぎたいが、処理自体は可能な限り非同期で実行したい場合に有効そう。

func readFile(path string) chan string {
	// ファイルを読み込み、その結果を返すFutureを返す
	promise := make(chan string)
	go func() {
		content, err := os.ReadFile(path)
		if err != nil {
			fmt.Printf("read error %s\n", err.Error())
			close(promise)
		} else {
			// 約束を果たした
			promise <- string(content)
		}
	}()
	return promise
}

func printFunc(futureSource chan string) chan []string { 
    // 文字列中の関数一覧を返すFutureを返す
	promise := make(chan []string)
	go func() {
		var result []string
		// futureが解決するまで待って実行
		for _, line := range strings.Split(<-futureSource, "\n") {
			if strings.HasPrefix(line, "func ") {
				result = append(result, line)
			}
		}
		// 約束を果たした
		promise <- result
	}()
	return promise
}

func main() {
	futureSource := readFile("main.go")
	futureFuncs := printFunc(futureSource)
	fmt.Println(strings.Join(<-futureFuncs, "\n"))
}

また、次のような構造体を定義することで上記のFutureの値を複数回読み取ることができる。（上記の実装ではバッファなしチャネルを使っているので複数回受信してしまうと処理がブロックされてしまう）

type StringFuture struct {
	receiver chan string
	cache    string
}

func NewStringFuture() (*StringFuture, chan string) {
	f := &StringFuture{
		receiver: make(chan string),
	}
	return f, f.receiver
}

func (f *StringFuture) Get() string {
	r, ok := <-f.receiver
	if ok {
		close(f.receiver)
		f.cache = r
	}
	return f.cache
}

func (f *StringFuture) Close() {
	close(f.receiver)
}

イベントの流れを定義する：ReactiveX

ここではRxGoを使ってイベントの流れを定義する方法が紹介されていた。まずこのようにwatcherを定義する。

watcher := observer.Observer{
    NextHandler: func(item any) {
        line := item.(string)
        if strings.HasPrefix(line, "func ") {
            fmt.Println(line)
        }
    },
    ErrHandler: func(err error) {
        fmt.Printf("Encountered error: %v\n", err)
    },
    DoneHandler: func() {
        fmt.Println("Done!")
    },
}

以下のようにするとNextHandlerに登録された関数にlineが渡される。

emitter <- line

そして次のようにするとErrHandlerに登録された関数が呼ばれる。

emitter <- err

渡ってきた値に応じて処理を分岐させたく、かつ何度も同一のイベントが発生するケースではこの方法を使うと良さそう。

自律した複数のシステムで協調動作：アクターモデル

アクターと呼ばれる自律した多数のコンピューターが協調して動作するというモデル。
各アクターは別のアクターから送られてくるメッセージを受け取るメッセージボックスを持つ。

第16章 Go言語のメモリ管理

仮想メモリ

現代のOSではプロセスはメモリを読み書きするのに物理的なアドレスを直接扱うのではなく、プロセスごとに仮想的なメモリアドレス空間があり、それを使ってメモリにアクセスしている。この仮想的なメモリアドレス空間のことを仮想メモリという。

仮想メモリのアドレスから実際の物理メモリにアクセスするためにページテーブルというデータ構造が使われる。ページとはメモリを管理する単位のこと。

仮想メモリのおかげで実際の保存領域が飛び飛びになっていたとしてもプロセスからはフラットなメモリ領域が確保されているように見える。

仮想メモリは物理メモリのアドレスと1対1対応しているわけではなく、物理メモリのあるアドレスが複数の仮想メモリから参照されることもある。こうすることで共有ライブラリなどを複数のプロセスで利用でき省メモリになる。

OSカーネルがプロセスのメモリを確保するまで

プロセスは起動時にOSからメモリをもらう。OSはプロセスごとに仮想メモリの領域を確保する。

ユーザーのメモリ空間は大きく3つの連続したメモリ領域に分かれる。3つの領域の間の空きスペース分はメモリの確保が行われない。

| ①プログラム + 静的データ | ヒープとして使われる領域 | ②共有ライブラリ |      | ③スタックなど |
小さいアドレス                                                                大きいアドレス ->

スタック

関数を呼ぶとリターンアドレスや新しい関数のための作業メモリ領域としてスタックフレームと呼ばれるメモリ領域が確保される。

スタックフレームはスレッドごとにあらかじめ確保されているメモリブロックに対して順番に追加したり削除されたりされるだけなので割当のコストはほぼゼロ。

Go言語でのスタックとヒープの使い分け

Go言語では変数のデータをヒープに置くかスタックに置くかはコンパイラが自動的に判断する。以下はその一部。

newで初期化してもその関数内でしか利用されなければスタックに確保される。
ローカル変数として宣言してもそのポインタを他の関数に渡したり、関数の返り値として返すような場合にはヒープに確保される。

Go言語でメモリがスタックとヒープのどちらに確保されるかを知りたい場合にはビルド時に-gcflags -mを渡すことで確認できる。

ということで次のコードを使って上記の挙動を確認してみる。

package main

import "fmt"

func main() {
	strValue := "Hello, World!" // スタックに確保される(関数内でしか利用されていないため)
	_ = strValue + ""

	strPtr := new(string) // スタックに確保される(関数内でしか利用されていないため)
	_ = *strPtr + ""

	strPtr2 := new(string) // ヒープに確保される(他の関数に渡されているため)
	receiveStrPtr(strPtr2)

	strPtrFromFunc := returnStrPtr() // スタックに確保される(関数内でしか利用されていないため)
	_ = *strPtrFromFunc + ""
}

func receiveStrPtr(argStrPtr *string) {
	fmt.Printf("argStrPtr: %v\n", argStrPtr)
}

func returnStrPtr() *string {
	str := "Hello, World!" // ヒープに確保される(関数の返り値として返されているため)
	return &str
}

-gcflags -mをつけてビルドしてみると次のようになりコードコメント通り、strPtr2とstrがヒープに確保されていることがわかった。

$ go build -gcflags -m main.go
# command-line-arguments
./main.go:19:6: can inline receiveStrPtr
./main.go:23:6: can inline returnStrPtr
./main.go:13:15: inlining call to receiveStrPtr
./main.go:15:32: inlining call to returnStrPtr
./main.go:13:15: inlining call to fmt.Printf
./main.go:20:12: inlining call to fmt.Printf
./main.go:7:15: strValue + "" does not escape
./main.go:9:15: new(string) does not escape
./main.go:10:14: *strPtr + "" does not escape
./main.go:12:16: new(string) escapes to heap
./main.go:13:15: ... argument does not escape
./main.go:16:22: *strPtrFromFunc + "" does not escape
./main.go:19:20: leaking param: argStrPtr
./main.go:20:12: ... argument does not escape
./main.go:24:2: moved to heap: str

ガベージコレクタ

Goをはじめとして多くの言語ではマークアンドスイープという方式が採用されている。

マークアンドスイープ方式では、まずメモリの領域をスキャンして必要なデータか否かをマークしていき、次のフェーズで不要なものを削除する。

マークアンドスイープ方式では、不要なメモリを削除する間にプログラム全体を停止する必要がある。（これをストップザワールドと呼ぶ）

Goではバージョンを重ねる事にストップザワールドの時間の短縮化が進んでいる。

第17章実行ファイルが起動するまで

最終的にCPUで実行されるバイナリはメモリ空間に単に命令が並んだもので、そこにはブロックのような概念は存在しない（Goでいうと{と}で囲まれた処理の塊）。

アセンブリ言語には関数のブロックのような概念はないが、その代わりにラベルという概念がある。

ランタイムの役割

Goに限らずC言語でもRustでも何かしらのプログラミング言語で生成したアプリケーションは「ランタイム」と呼ばれるライブラリを利用したプログラムになるのが一般的。

ラインタイムライブラリが最終的にはOSのカーネルにシステムコールを発行して仕事を依頼し、メモリ管理やファイルやネットワークアクセスを実現する役割を担う。

ラインタイムライブラリがなければ、OSに仕事を依頼するところも自分で作成する必要がある。

リンカーの役割

以下はWikipediaによるリンカーの説明。

a computer program that takes one or more object files generated by a compiler or generated by an assembler and links them with libraries, generating an executable program or shared library

Linker - Wikipedia から引用

上記を翻訳すると「コンパイラまたはアセンブラによって生成された1つ以上のオブジェクトファイルをライブラリと結合し実行可能ファイルまたは共有ライブラリを生成するプログラム」といった感じだろうか。

OSはリンカーが生成した実行ファイルがシェルから起動されると、実行ファイルの内容をメモリに配置する。

ロードが終わったら決め打ちされた「特定のアドレス」からCPUが命令を読み込んで実行が開始される。

実行中に発生する関数呼び出しはすでにリンカーによってアドレスが解決されているので示されたアドレスにジャンプするだけで高速に実行される。

実行ファイルのメモリ配置

OSがアプリケーションの実行ファイルを最初にロードしてくる部分についての解説。

まず、実行ファイルのフォーマットはOSによって異なる。

LinuxなどのPOSIX系OS: ELF形式
Windows: PE(Portable Executable)形式
macOS: Mach-O形式

また、実行ファイルには次のようなデータが格納されている。

この実行ファイルが対象としているCPUアーキテクチャの種類
実行ファイル中に含まれるセクションをどのメモリアドレスに配置するか、そのときのセクション名と実行権限
プログラム起動時に最初に呼び出す命令が格納されているアドレス
実行ファイルの実行に必要な共有ライブラリの情報
実行コードのセクション
静的に初期化された変数のセクション

セクションは実行ファイルフォーマットを構成するバイナリデータのブロックのことで以下のようなものがある。

TEXT: 機械語の実行コードが格納されるセクション
DATA: 実行コードを含まない静的に確保された初期化済み（データがすでに入っている）のメモリ領域
BSS: 変数が置かれる領域で初期化されていない（すべてゼロ）メモリ領域

OSはこの実行ファイルフォーマットに従って実行ファイルに含まれるセクションを適切なアドレスに配置していく。⁸その後実行ファイルフォーマットに書かれた初期実行アドレスを実行することでアプリケーションが起動する。

Goのプログラムの起動

Goで書かれたソースコードが実行されるまでの流れは以下。

Goで書かれたアプリケーションをコンパイルすると実行ファイルが作成される
コンパイル済みのGoプログラムを実行すると実行環境のランタイムにある$GOROOT/src/runtime/asm_(ARCH名).sというファイルのなかにある_rt0_(ARCH名)という関数が呼ばれる。このプロシージャの中では以下のような処理が実行される。
1. 最初のgoroutineの初期化
2. OSから渡されるコマンドライン引数os.Argsのパース
3. コンピュターで利用可能なCPUコア数の取得
$GOROOT/src/runtime/proc.goのschedinit()関数の中で以下のような処理が実行される。
- スタックを初期化
- メモリマネージャを初期化し、Mを初期化
- mapの内部で使われるハッシュアルゴリズムの初期化
- モジュール機能向けのモジュール情報や型情報の取得
- シグナルハンドラの初期化
- コマンドライン引数と環境変数の初期化
- ガベージコレクタの初期化

次に新しいgoroutineを作って$GOROOT/src/runtime/proc.goのmain()関数が呼び出される。そこでは以下のような流れで処理が進む。

runtime.lockOSThread()
(ランタイムの)init()
main・init()(アプリケーションのmainパッケージのinit()関数)
runtime.unlockOSThread()
main・main()(アプリケーションのmainパッケージのmain()関数)

まとめ

ここまでの理解をもとにいくつかの質問に対する答えを書いてみる。

プロセスとスレッドの違いは何か

プロセスはプログラムの実行単位であり他のプロセスとはメモリを共有していない。
プロセスは起動時に仮想メモリが割り当てられるためスレッドに比べて起動コストが高い
スレッドはプロセス内で実行される軽量な実行単位でプロセス内のメモリ空間やリソースを共有する。
複数のスレッドが同じメモリを操作する可能性があるためデータ競合を防ぐ必要がある。

プログラムはどのような流れで実行されるか

コンパイラがソースコードをコンパイルする
リンカーがコンパイル済みのオブジェクトファイルをリンクし実行可能ファイルを生成する
ユーザーが実行可能ファイルを実行する(e.g. ターミナルから呼び出す)
OSがプロセスを生成し、プロセスの実行に必要な仮想メモリ空間を割り当てる
OSが実行ファイルの内容をディスクからメモリに読み込み、仮想アドレス空間に適切に配置する
メインスレッドでプログラムが実行される(プロセスが生成されると自動的にメインスレッドが作成される)

感想

冒頭にも書いた通りCSを体系的に学んだ経験がない自分にとってはとても勉強になった。

次はこのあたりの書籍を読んでみようとおもう。

コンピュータシステムの理論と実装
Go言語による並行処理
つくって、壊して、直して学ぶ Kubernetes入門
Linuxで動かしながら学ぶTCP/IPネットワーク入門
体系的に学ぶ安全なWebアプリケーションの作り方

あるいは、 Webサーバーアーキテクチャ進化論2023 - blog.ojisan.ioを参考に学習ロードマップを立ててみるのもいいかもしれない。

Neovimでのデバッガの環境構築は nvim-dapでGolangのデバッグ環境構築を参考にした ↩︎
Sysfdの定義はgolang/go/src/internal/poll/fd_unix.go#L23(https://github.com/golang/go/blob/c83b1a7013784098c2061ae7be832b2ab7241424/src/internal/poll/fd_unix.go#L23) にある。 ↩︎
io.Pipeの使いどころに関しては Go言語のio.Pipeでファイルを効率よくアップロードする方法が大変参考になった。 ↩︎
cf. kyu08/go-system-programming/4-channel/unbufferedchannel/main.go#L8 ↩︎
Distrolessに対して「コンテナイメージが軽量になる」以外のメリットを感じていなかったが書かれている通りセキュリティ面でもメリットがあると気付いた。 ↩︎
fzf-makeの出力の一部に色を付けるために使っている。 https://github.com/kyu08/fzf-make/blob/12789acd19bc24daa60ba7eb84973dab18fe7a52/src/usecase/execute_make_command.rs#L5 ↩︎
https://ufcpp.net/blog/2023/12/escape-escape/ ↩︎
仮想メモリ空間についてはκeenさんのこちらの記事がとてもわかりやすかった。メモリとスタックとヒープとプログラミング言語 ↩︎

GitHub Sponsorsの寄付先にratatuiを追加した

Mon, 23 Sep 2024 15:02:46 +0000

OSSへの寄付の月予算を$10にした - laiso

こちらの記事で寄付するOSSプロジェクトの選び方として次のような基準が紹介されていた。

寄付するプロジェクトはこういう基準で選んでる

自分が使っていてなくなったら困る

マイナーであまり寄付されていない

今まで前者の基準に則ってneovimに寄付していたが、後者の観点を持てていなかったことに気付いた。そこで自分もOSSへの寄付を見直してみようと思った。

というわけで

タイトルの通りだが、GitHub Sponsorsの寄付先にratatuiを追加した。

ratatuiとは、手軽にTUIアプリケーションを作成できるRust用のライブラリで、筆者が個人開発しているOSSであるfzf-makeでも利用している。¹

ratatuiのおかげでこんな感じのUIを手軽に実装できている。

Rust製のTUIツールでは非常に幅広く利用されている印象だが、現在のスポンサー数が9人と少なかったので少しでも力になれればということで寄付先に追加した。長期間メンテされる状態が続いてくれると嬉しい。自分にもできそうなバグ修正があれば挑戦してみようと思う。

10番目のスポンサーになった様子。

これで現在の寄付額は$10/月で、neovimとratatuiにそれぞれ$5ずつ寄付していることになる。

他にも寄付したいプロジェクトは山ほどあるので山ほど稼いでいきたい。(あと円高頼む…)

まとめ

今後ともOSSコミュニティの持続可能性を高めていきたい。

make targetをプレビューウィンドウ付きであいまい検索によって選択&実行できるツール。brewやcargoでインストールできるのでぜひ。

GitHub - kyu08/fzf-make: A command line tool that executes commands using fuzzy finder with preview window for make, npm, pnpm, yarn, just and task.
A command line tool that executes commands using fuzzy finder with preview window for make, npm, pnpm, yarn, just and task. - kyu08/fzf-make
https://github.com/kyu08/fzf-make

↩︎

Cloud Spanner について知らなかったことを書く

Mon, 23 Sep 2024 01:44:54 +0000

普段業務でCloud Spannerを使っているが、雰囲気で使っている自覚が大いにあるのでドキュメントやブログを読んで知らなかったことを自分用のメモとしてまとめてみる。

Spanner のスキーマ設計の最適化 | Google Cloud

Spanner のスキーマ設計の最適化 | Google Cloud Documentation

https://cloud.google.com/spanner/docs/whitepapers/optimizing-schema-design?hl=ja

キー定義とインターリーブの2つはスケーラビリティに大きな影響を与える
Spannerにはルートテーブルとインターリーブされたテーブルの2種類のテーブルがある。¹

テーブルレイアウト

Spannerテーブルの行はPRIMARY_KEYによって辞書順に並べかえられる。したがって以下の特性を示す。

辞書順のテーブルスキャンは効率的
十分に近い行は同じディスクブロックに格納され、一緒に読み込まれてキャッシュされる

各Spannerレプリカ内のデータはスプリットとブロックという2つの物理階層レベルで編成される。

インターリーブ

ルートテーブルの各行をルート行と呼び、インターリーブされたテーブルの各行を子行と呼ぶ。ルート行とそのすべての子孫のコレクションは行ツリーと呼ばれる。

行ツリー内のオペレーションは他のスプリットとの通信を必要としないケースが多いため基本的には効率性が高い。ただし子行にホットスポットがある場合Spannerはホットスポットの行とそれ以降の子行を分離するためにスプリット境界を追加しようとする。そのため必ずしも効率性が高いという保証はない。

局所性のトレードオフ

以下の理由で局所性を高めることが重要。

通信するサーバが多いほど一時的にビジー状態のサーバに遭遇する可能性が高くなり、レイテンシの増加につながる。
複数のスプリットにまたがるトランザクションは二層コミットの特性によってCPUコストとレイテンシがわずかに増加する。

局所性の勘所

分散DBである以上、一定レベルの二層コミットや非ローカルデータオペレーションは避けられない。
すべてのオペレーションの局所性を完璧にするのではなく最も重要なルートエンティティと最も一般的なアクセスパターンについて必要な局所性を実現することが重要。その他のオペレーションについてはそのままにすることを推奨。

インデックスのオプション

デフォルトではインターリーブされていないインデックスを作成されるが、インターリーブされたインデックスを作成することもできる。
- インターリーブされたインデックスはインターリーブされたテーブルにデータを格納する。そのためデータとインデックスが強制的に同じ行ツリーに格納され、データとインデックスの結合効率が高くなる。

Spannerはテーブルと同じ方法でインデックスデータを格納する。 換言すると、インターリーブされていないインデックスはルートテーブルにデータを格納する。

そのため以下が推奨される。

検索範囲が単一のエンティティのときは常にインターリーブされたインデックスを使用する。
逆にデータベース内のどこからでも行を検索する必要がある場合はインターリーブされていないインデックスを使用する。

STORING

要求されたすべてのデータがインデックス自体に含まれる場合、STORING句を使用してインデックスを作成することができる。これによりベーステーブルと結合することなくクエリを完了できるためより効率的に結果を取得することができる。

現在はインデックスキーは16個、合計サイズが6KiBまでに制限されているため、STORING句を使用することで任意のインデックスに対してデータを格納することができる。

つまりSTORINGを使用するとWRITEコストおよびストレージコストの上昇と引き換えにREADコストを削減できる。

また、ドキュメントではSTORINGの便利な応用例としてNULL_FILTEREDインデックスとの併用を紹介している。それについてはこちらの記事が大変詳しいので参照されたい。

Cloud SpannerのNull Filtered INDEXの用途を考察する〜サブタイプ実装〜

https://zenn.dev/facengineer/articles/15e7a68fcc2fad

アンチパターン

ルートテーブルをタイムスタンプ順にしてしまうとテーブルの最後に巨大なホットスポットが生まれてしまう。

タイムスタンプ順に並んだレコードが必要な場合は以下の対策が有効。

他のルートテーブルの1つにインターリーブする（ただし各ルートへの書き込みレートが十分低くなるようにする）
シャーディングを使用して時系列的に連続したデータを複数のスプリットに分散する

この例ではPKにShardId(0~N-1)を追加する方法を紹介している。

スキーマ設計のベストプラクティス | Spanner | Google Cloud

スキーマ設計のベストプラクティス | Spanner | Google Cloud Documentation

https://cloud.google.com/spanner/docs/schema-design?hl=ja

次のような場合はキー列をタイムスタンプ降順に格納することでホットスポットを回避する。

最新の履歴を読み取る際、履歴にインターリーブテーブルを使用しており、親行を読み取る場合
連続したエントリを日付の新しい順に読み込む場合に、いつまで日付をさかのぼるか不明なとき

CREATE TABLE UserAccessLog (
UserId     INT64 NOT NULL,
LastAccess TIMESTAMP NOT NULL,
...
) PRIMARY KEY (UserId, LastAccess DESC);

筆者はこれまでこのようなケースではUserAccessLogテーブルにUUIDを付与しLastAccess降順なインデックスを作成することで対応することが多かった。この方法は選択肢として持てていなかったので必要になったら思い出せるとよさそう。

このケースはアクセスログなのでWRITE頻度が高いテーブルを想定していると思われる。インデックスで対応する方式と比較するとWRITEコストを下げることができる点でメリットがありそう。

と思っていたら続きにそのパターンの実装方法も書かれていた。

値が単調に増加または減少する列へのインターリーブされたインデックスの使用

次のようなテーブルがあるとする。

CREATE TABLE Users (
UserId     INT64 NOT NULL,
LastAccess TIMESTAMP,
...
) PRIMARY KEY (UserId);

このテーブルに対して次のような(インターリーブされていない && 最初のキーが単調増加する)インデックスを作成した場合、LastAccessは単調増加する値なので最後のスプリットに書き込みが集中し、ホットスポットが発生してしまう。

CREATE NULL_FILTERED INDEX UsersByLastAccess ON Users(LastAccess);

このようなケースでは次のような対処が考えられる。

インデックスにShardIdを追加する
（そもそも）インデックスをインターリーブする

セカンダリインデックス | Spanner | Google Cloud

セカンダリインデックス | Spanner | Google Cloud Documentation

https://cloud.google.com/spanner/docs/secondary-indexes?hl=ja

Spannerではセカンダリインデックスに次のデータが格納される。
- ベーステーブルのすべてのキー列
- インデックスに含まれるすべての列
- STORING句で指定されたすべての列

NULL値の並び替え順

SpannerではNULLを最小値として扱う。そのため昇順の場合はNULLが先頭に、降順の場合は末尾に並ぶ。

末尾のレコードの取得

次のようなクエリを実行する場合は結果をすばやく取得することができる。これはSpannerがテーブルの行をPRIMARY_KEYによって辞書順に並べかえるため。

-- テーブル定義
CREATE TABLE Songs (
    SongId INT64 NOT NULL,
    ...
) PRIMARY KEY (SongId);

-- クエリ
SELECT SongId FROM Songs LIMIT 1;

しかしSpannerではテーブル全体をスキャンしないと列の最大値を取得することができないため次のようなクエリはすばやく結果を返さない。

SELECT SongId FROM Songs ORDER BY SongId DESC LIMIT 1;

このようなケースでは次のようにPK降順のインデックスを明示的に作成することで読み取りパフォーマンスを向上させることができる。

CREATE INDEX SongIdDesc On Songs(SongId DESC);

Sharding of timestamp-ordered data in Cloud Spanner - googblogs.com

By Karthi Thyagarajan, Solutions Architect Cloud Spanner was designed from the ground up to offer horizontal scalability and a developer-friendly SQL interface. As a managed service, Google Cloud handles most database management tasks, but it’s up to you to ensure that there are no hotspots, as described in Schema Design Best Practices and Optimizing Schema Design for Cloud Spanner. In this article, we’ll look at how to efficiently insert and retrieve records with timestamp ordering. We’ll start with the high-level guidance provided in Anti-pattern: timestamp ordering and explore the scenario in more detail with a concrete example. Scenario Let’s say we’re building an app that logs user activity along with timestamps and also allows users to query this activity by user id and time range. A good primary key for the table storing user activity (let’s call it LogEntries) is (UserId, Timestamp), as this gives us a uniform distribution of activity logs. Cloud Spanner inserts log entries sequentially, but they’re naturally sharded by UserId, resulting in uniform key distribution. Table LogEntries UserId (PK) Timestamp (PK) LogEntry 15b7bd1f-8473 2018-05-01T15:16:03.386257Z Here’s a sample query to retrieve a list of log entries by user and time range:SELECT UserId, Timestamp, LogEntry FROM LogEntries WHERE UserID = '15b7bd1f-8473' AND Timestamp BETWEEN '2018-05-01T15:14:10.386257Z' AND '2018-05-01T15:16:10.386257Z'; This query takes advantage of the primary key and thus performs well. Now let’s make things more interesting. What if we wanted to group users by the company they work for so we can segment reports by company? This is a fairly common use case for Cloud Spanner, especially with multi-tenant SaaS applications. To support this, we create a table with the following schema.Table LogEntries CompanyId (PK) UserId (PK) Timestamp (PK) LogEntry Acme 15b7bd1f-8473 2018-05-01T15:16:03.386257Z And here’s the corresponding query to retrieve the log entries: SELECT CompanyId, UserId, Timestamp, LogEntry FROM LogEntries WHERE CompanyID = 'Acme' AND UserID = '15b7bd1f-8473' AND Timestamp BETWEEN '2018-05-01T15:14:10.386257Z' AND '2018-05-01T15:16:10.386257Z'; Here’s the query to retrieve log entries by CompanyId and time range (user field not specified):SELECT CompanyId, UserId, Timestamp, LogEntry FROM LogEntries WHERE CompanyID = 'Acme' AND Timestamp BETWEEN '2018-05-01T15:14:10.386257Z' AND '2018-05-01T15:16:10.386257Z'; To support the above query, we add a separate, secondary index. Initially, we include just two columns:CREATE INDEX LogEntriesByCompany ON UserActivity(CompanyId, Timestamp) Challenge: hotspots during inserts The challenge here is that some companies may have a lot more (orders of magnitude more) users than others, resulting in a very skewed distribution of log entries. The challenge is particularly acute during inserts as described in the opening paragraph above. And even if Cloud Spanner helps out by creating additional splits, nodes that service new splits become hotspots due to uneven key distribution. The above diagram depicts a scenario where Company B has three times more users than Company A or Company C. Therefore, log entries corresponding to Company B grow at a higher rate, resulting in the hotspotting of nodes that service the splits where Company B’s log entries are being inserted. Hotspot mitigation There are multiple aspects to our hotspot mitigation strategy: schema design, index design and querying. Let’s look at each of these below. Schema and index design As described in Anti-pattern: timestamp ordering, we’ll use application-level sharding to distribute data evenly. Let’s look at one particular approach for our scenario: instead of (CompanyId, UserId, Timestamp), we’ll use (UserId, CompanyId, Timestamp).Table LogEntries (reorder columns CompanyId and UserId in Primary Key) UserId (PK) CompanyId (PK) Timestamp (PK) LogEntry 15b7bd1f-8473 Acme 2018-05-01T15:16:03.386257Z By placing UserId before CompanyId in the primary key, we can mitigate the hotspots caused by the non-uniform distribution of log entries across companies. Now let’s look at the secondary index on CompanyId and timestamp. Since this index is meant to support queries that specify just CompanyId and timestamp, we cannot address the distribution problem by simply incorporating UserId. Keep in mind that indexes are also susceptible to hotspots and we need to design them so that their distribution is uniform. To address this, we’ll add a new column, EntryShardId, where (in pseudo-code): entryShardId = hash(CompanyId + timestamp) % num_shards The hash function here could be a simple crc32 operation. Here’s a python snippet illustrating how to calculate this hash function before a log entry is inserted:... import datetime import zlib ... timestamp = datetime.datetime.utcnow() companyId = 'Acme' entryShardId = (zlib.crc32(companyId + timestamp.isoformat()) & 0xffffffff) % 10 ... In this case, num_shards = 10. You can adjust this value based on the characteristics of your workload. For instance, if one company in our scenario generates 100 times more log entries on average than the other companies, then we would pick 100 for num_shards in order to achieve a uniform distribution across entries from all companies. This hashing approach essentially takes the sequential, timestamp-ordered LogEntriesByCompany index entries for a particular company and distributes them across multiple application (or logical) shards. In this case, we have 10 such shards per company, resulting from the crc32 and modulo operations shown above.Table LogEntries (with EntryShardId added) CompanyId (PK) UserId (PK) Timestamp (PK) EntryShardId LogEntry ‘Acme’ 1 2018-05-01T15:16:03.386257Z 8 And the index: CREATE INDEX LogEntriesByCompany ON LogEntries(EntryShardId, CompanyId, Timestamp) Querying Evenly distributing data using a sharding approach is great for inserts but how does it affect retrieval? Application-level sharding is no good to us if we cannot retrieve the data efficiently. Let’s look at how we would query for a list of log entries by CompanyId and time range, but without UserId:SELECT CompanyId, UserId, Timestamp, LogEntry FROM LogEntries@{FORCE_INDEX=LogEntriesbyCompany} WHERE CompanyId = 'Acme' AND ShardedEntryId BETWEEN 0 AND 9 AND Timestamp > '2018-05-01T15:14:10.386257Z' AND Timestamp The above query illustrates how to perform a timestamp range retrieval while taking sharding into account. By including the ShardedEntryId in the query above, we tell Spanner to ‘look’ in all 10 logical shards to retrieve the timestamp entries for CompanyId ‘Acme’ for a particular range. Cloud Spanner is a full-featured relational database service that relieves you of most—but not all—database management tasks. For more information on Cloud Spanner management best practices, check out the recommended reading.Anti-pattern: timestamp orderingOptimizing Schema Design for Cloud SpannerBest Practices for Schema Design

https://www.googblogs.com/sharding-of-timestamp-ordered-data-in-cloud-spanner/

タイムスタンプ順に並んだレコードをいかに効率よく挿入、取得するかについての解説記事。

レコードの挿入時

次のようにCompanyID、UserID、Timestampの3つのキーを持つログテーブルがあるとする。

CompanyId(PK)	UserId(PK)	Timestamp(PK)	LogEntry
Acme	15b7bd1f-8473	2018-05-01T15:16:03.386257Z

このスキーマにしたがって単純にデータを挿入していくとユーザー数が多い企業があるとホットスポットが発生してしまう。

そのための次のような疑似コードで表現できるEntryShardIdを用いることで挿入時のホットスポットを回避できる。

entryShardId = hash(CompanyId + timestamp) % num_shards

レコードの読み取り時

次のようなインデックスを追加する。

CREATE INDEX LogEntriesByCompany ON LogEntries(EntryShardId, CompanyId, Timestamp)

そして以下のようなクエリを実行する。

SELECT CompanyId, UserId, Timestamp, LogEntry
FROM LogEntries@{FORCE_INDEX=LogEntriesByCompany}
   WHERE CompanyId = 'Acme'
   AND EntryShardId BETWEEN 0 AND 9
   AND Timestamp > '2018-05-01T15:14:10.386257Z'
   AND Timestamp < '2018-05-01T15:16:10.386257Z'
ORDER BY Timestamp DESC;

こうすることでインデックスを使って10個の論理シャードから条件にあったレコードを効率よく取得することができる。

余談

前章のクエリのWHERE句内で以下のようにCompanyId, EntryShardIdの順で指定していたので正しくインデックスが使えるのか気になったので試してみた。

   WHERE CompanyId = 'Acme'
   AND EntryShardId BETWEEN 0 AND 9

準備

任意のGoogle CloudプロジェクトでSpannerインスタンスを作成し、以下のDDLを実行してテーブルとインデックスを作成する。

CREATE TABLE LogEntries (
  CompanyId STRING(36) NOT NULL,
  UserId STRING(36) NOT NULL,
  Timestamp TIMESTAMP NOT NULL,
  EntryShardId INT64 NOT NULL,
  LogEntry STRING(MAX) NOT NULL,
) PRIMARY KEY (CompanyId, UserId, Timestamp);
CREATE INDEX LogEntriesByCompany ON LogEntries(EntryShardId, CompanyId, Timestamp);

次にテストデータをINSERTする。

項目	条件
シャード数	10
Companyの数	5
従業員数	20

上記の条件で合計1000レコードを挿入するINSERT文を作成した。（スクリプトはこちら）

クエリの実行

これに対して次の2つのクエリを実行し、実行計画を確認した。

-- 記事で紹介されていたクエリ
SELECT
  CompanyId,
  UserId,
  Timestamp,
  LogEntry
FROM
  LogEntries@{FORCE_INDEX=LogEntriesByCompany}
WHERE
  CompanyId = 'amazon'
  AND EntryShardId BETWEEN 0 AND 9
  AND Timestamp > '2023-01-01T00:00:00.386257Z'
  AND Timestamp < '2023-01-01T00:00:05.386257Z'
ORDER BY
  Timestamp DESC;

-- CompanyId, EntryShardIdの順番を逆にしてみたクエリ
SELECT
  CompanyId,
  UserId,
  Timestamp,
  LogEntry
FROM
  LogEntries@{FORCE_INDEX=LogEntriesByCompany}
WHERE
  EntryShardId BETWEEN 0 AND 9
  AND CompanyId = 'amazon'
  AND Timestamp > '2023-01-01T00:00:00.386257Z'
  AND Timestamp < '2023-01-01T00:00:05.386257Z'
ORDER BY
  Timestamp DESC;

結果

結論からいうとどちらのクエリでも同様にインデックスを利用できていた。おそらくSpannerのオプティマイザがいい感じに判断してくれていると思われる。以下が実際の実行計画。

記事で紹介されていたクエリ

CompanyId, EntryShardIdの順番を逆にしてみたクエリ

Cloud Spanner におけるトランザクションのロックについて

Cloud Spanner におけるトランザクションのロックについて | Google Cloud 公式ブログ

https://cloud.google.com/blog/ja/products/databases/transaction-locking-in-cloud-spanner

Spanner におけるトランザクションのロックの粒度は、セル、つまり行と列の交点となります。

なのでREAD, WRITEの範囲(行および列)を最小限にすることでロック範囲を最小限にすることができる。結果として他のトランザクションに与えるパフォーマンス影響を最小限にすることができる。

他には複数のトランザクションが同時に実行された際の優先度について詳しく解説してあった。

Spanner の読み取りと書き込みのライフサイクル | Google Cloud

Spanner の読み取りと書き込みの有効期間 | Google Cloud Documentation

https://cloud.google.com/spanner/docs/whitepapers/life-of-reads-and-writes?hl=ja

Spannerのレプリカセットの構成については次の記事が非常にわかりやすい。

Cloud Spannerのスプリット分散をわかった気になる

https://zenn.dev/facengineer/articles/bca8790087b0e4

読み込みおよび書き込み時のロックの取り方について詳しく解説されていた。

読み取り専用トランザクション

ロックを取得せずに実行できるため高速
ステイル読み込みを使用できる場合はより高速にすることができる（他のオペレーションに与えるパフォーマンス影響も抑えることができる）
- Spannerはレプリカへの同期を10秒ごとに行っているため、10秒以上前のデータをステイル読み込みできる場合は読み取りのスループットをさらに高めることができる。

読み取り / 書き込みトランザクション

読み取った行に対して共有ロックを取得する
書き込む行に対して排他ロックを取得する

ちなみに複数のトランザクションが同時に実行された場合の挙動については次の記事が詳しかった。

Cloud Spanner におけるトランザクションのロックについて | Google Cloud 公式ブログ

https://cloud.google.com/blog/ja/products/databases/transaction-locking-in-cloud-spanner

SQL のベストプラクティス | Spanner | Google Cloud

SQL のベストプラクティス | Spanner | Google Cloud Documentation

https://cloud.google.com/spanner/docs/sql-best-practices?hl=ja

クエリパラメータの使用

クエリパラメータを使用することで次のメリットがある。

キャッシュが容易になるためクエリのパフォーマンスが向上する
文字列の値をエスケープする必要がないため構文エラーのリスクが減る
SQLインジェクションを防ぐことができる

範囲キーのルックアップを最適化する

キーのリストが短く、連続していない場合は次のようにIN UNNESTを使用する。

SELECT *
FROM Table AS t
WHERE t.Key IN UNNEST (@KeyList)

キーのリストが連続して範囲内である場合には次のように下限と上限を設定する。[@min, @max]の範囲をすべてスキャンするため効率的にスキャンできる。

SELECT *
FROM Table AS t
WHERE t.Key BETWEEN @min AND @max

結合を最適化する

可能な限りインターリーブされたテーブルのデータを主キーによって結合する

インターリーブされた子行とそのルート行は基本的に同じスプリットに格納されるためローカルで結合することができ、効率的に結合できるため。

結合の順序を強制する

Spanner側の最適化によって結合順序が変更され（この場合はSingers JOIN Albumsと記述したがAlbums JOIN Singersの順序に変更されたケース）パフォーマンスが低下した場合などはFORCE_JOIN_ORDERヒントを使用することで結合順序を強制することができる。

SELECT *
FROM Singers AS s JOIN@{FORCE_JOIN_ORDER=TRUE} Albums AS a
ON s.SingerId = a.Singerid
WHERE s.LastName LIKE '%x%' AND a.AlbumTitle LIKE '%love%';

JOINアルゴリズムを指定する

次のようにJOIN_METHODヒントを使用することでJOINアルゴリズムを指定することができる。

SELECT *
FROM Singers s JOIN@{JOIN_METHOD=HASH_JOIN} Albums AS a
ON a.SingerId = a.SingerId

JOINアルゴリズムについては次の記事が詳しい。

Cloud Spannerのパフォーマンスチューニングの勘所

https://zenn.dev/facengineer/articles/cc0cab5c7e9a1c#join%E3%82%A2%E3%83%AB%E3%82%B4%E3%83%AA%E3%82%BA%E3%83%A0

`LIKE`の代わりに`STARTS_WITH`を使用する

Spannerはパラメータ化されたLIKEパターンを実行時まで評価しないのですべての行を読み取ったうえでLIKE式で評価し、一致しない行を除外するためパフォーマンスが悪い。

適切なインデックスが作成されている場合はLIKEの代わりにSTARTS_WITHを使用するとSpannerはクエリ実行プランをより効率的に最適化することができる。

-- 非推奨
SELECT a.AlbumTitle FROM Albums a
WHERE a.AlbumTitle LIKE @like_clause;

-- 推奨
SELECT a.AlbumTitle FROM Albums a
WHERE STARTS_WITH(a.AlbumTitle, @prefix);

クエリ実行プラン | Spanner | Google Cloud

クエリ実行プラン | Spanner | Google Cloud Documentation

https://cloud.google.com/spanner/docs/query-execution-plans?hl=ja

CPUの消費量が多いクエリの場合、実行計画は30日間保存されている。

確認方法は以下。

クエリプランビジュアライザーを使用したクエリのチューニング | Spanner | Google Cloud Documentation

https://cloud.google.com/spanner/docs/tune-query-with-visualizer?hl=ja#view-sampled-queries

クエリごとにレイテンシや返された行数、スキャン行数の平均値や実行回数確認することができるためチューニングの際にかなり便利そう。

まとめ

Spannerの気持ちが少しわかった。すごく強引にまとめると以下のようなポイントが重要そう。

ホットスポットに注意する
結合コストを最小限にする
スキャン行数を最小限にする
ロック範囲を最小限にする

これまで漫然とドキュメントを読んで頭に入らなかったり記憶が定着しなかったりしたが、ブログにアウトプットしながら読むと理解度も定着度も（モチベーションも）上がるのでやってよかった。

次はCloud Runとも仲良くなりたい。

①ルートテーブル②インターリーブされたテーブル③インターリーブの子を持たない通常のテーブルの3種類だと思い込んでいたが③は①として扱われるようだ。 ↩︎

forkしたrepositoryのremoteを最新化しつつローカルにpullするスクリプトを書いた

Mon, 02 Sep 2024 15:54:12 +0000

前提

ghコマンドがインストールされていること
デフォルトブランチにいること

tl;dr

# forkしたrepositoryのremoteを更新しつつpullする
function git-sync() {
    REPO=$(git remote get-url origin | sed -E 's%.+github.com/(.*).git$%\1%')
    echo "🔄 Syncing ${REPO}...\\n"
    gh repo sync ${REPO} && git pull
}
alias gsy=git-sync

嬉しさ

もともとは以下の2ステップだったが前述のスクリプトを使うと1ステップにまとめることができる。

ブラウザでSync fork > Update branchをクリック
ローカルでgit pullを実行

ブラウザからforkすると遅いのでCLIからfork & cloneするスクリプトを書いた

Sun, 18 Aug 2024 06:52:01 +0000

モチベーション

GitHubにホストされているOSSにPRを出す時にforkしてからローカルにcloneするが、ブラウザのforkボタンを使ってforkすると時間がかかることが多くストレスに感じていた。

そのためCLI上でforkとcloneを行うスクリプトを書いた。

これまでの手順は以下のような手順が必要だった。

ブラウザでforkボタンを押す
forkの完了を待つ
ブラウザに表示されるcloneコマンドをコピー(gh repo clone owner/repoみたいなやつ)
ターミナルでコマンドを実行してforkしたリポジトリをcloneする

これを以下のステップでできるようにした。

リポジトリのURLまたはOWNER/REPO形式の文字列をコピー
コマンドに1. で取得した文字列を渡して実行

つくったスクリプト

以下を.zshrcなどに追加すると使えるようになる。aliasの部分はお好みで。¹

function git-fork-clone() {
    # 入力からowner/repoを取り出す。owner/repoのような形式でもURLでもOK
    REPO=$(echo $1 | sed -E 's@.+github.com/([^/]+)/([^/]+).*@\1/\2@')
    echo "🐙 ${REPO} will be forked and cloned.\\n"
    # -- 以降のオプションはgit cloneに渡される
    # See: https://cli.github.com/manual/gh_repo_fork
    gh repo fork ${REPO} --default-branch-only --clone=true -- --filter=blob:none
}
alias gf=git-fork-clone

前提

ghコマンドがインストールされていること。

使い方

$ git-fork-clone https://github.com/cli/cli

上記を実行すると以下のような出力が表示され、リポジトリのforkとcloneが行われる。

🐙 cli/cli will be forked and cloned.

✓ Created fork kyu08/cli
Cloning into 'cli'...
remote: Enumerating objects: 31, done.
remote: Counting objects: 100% (31/31), done.
remote: Compressing objects: 100% (30/30), done.
remote: Total 31 (delta 0), reused 10 (delta 0), pack-reused 0 (from 0)
Receiving objects: 100% (31/31), 20.41 KiB | 10.20 MiB/s, done.
From github.com:cli/cli
 * [new branch]      main       -> upstream/main
 * [new tag]         v1.0.1     -> v1.0.1
✓ Cloned fork

以下のような形式でも動く。

git-fork-clone https://github.com/cli/cli/pulls
git-fork-clone cli/cli

まとめ

また人類のOSS貢献力を加速させてしまいました。

完全に余談だがスクリプトのREPO=...の部分は https://www.tutorialspoint.com/execute_bash_online.php を使って出先で書いた。スマホでもシェルスクリプトが書けて便利。 ↩︎

『読み手につたわる文章 - テクニカルライティング』を読んだ

Wed, 05 Jun 2024 15:21:05 +0000

技術書典で購入した『読み手につたわる文章 - テクニカルライティング』を読んだので学びになったトピックについて書く。

1.2 「知らない」と書けない（P14）

そして自分が対象物を思っていたより「知らない」ということに、我々は気付いていないことが多いのです。上手な絵は、対象物のことを知らないと描けません。それと同じように、分かりやすい実用文は、文章力のあるなし以前に 対象物をよく知らないと書けない のです。

文字にすると当たり前のことのように感じるが、ブログを書いているとよく実感する。

技術的な内容であれば、当然対象を理解していないと書けないし、自分の考えでさえもいざ言語化しようと思うとなかなか筆が進まないことが多い。

そうした場合にはまず自分が何を言いたいのかを整理して理解するようにしている。

2.1.4 いつまでに何をしてほしいのか書こう（P25）

何の食べ物だか言わずにいきなり「食べて! ほら食べて!」とスプーンを差し出されると、「え、怖い。なになになに?」となって、とても素直に口を開く気にはなれませんし、食べたところで猜疑心で味もよく分かりません。そんなときは「初めて作ったプリンが思いのほか美味しくできたので一口食べて感想を教えてほしい」というように、どういう意図で読み手に何をして欲しいと思っているのかを先に説明してあげる必要があります。

引用部分の前に書かれていた例示のエピソードがわかりすぎて無限に頷いてしまった。認知負荷が高い文章を読むにはエネルギーを要する。

報告なのでただ把握だけしておいて欲しいのか相談がしたいので意見を求めているのかなど、読み手に求めるアクションを明示すると読み手の認知負荷が低くて良さそう。

結局伝えたいことが伝わらないことには意味がないので書いて満足、ではなくドキュメントを書くことの目的を見失わないようにしていきたい。

2.2 文書構造や文章量が適切だと分かりやすい

2.2.1 大枠から始めてだんだん細かくしていこう（P26）

文章で何かを説明するときには、先に大枠を理解してもらい、それから段々細かい内容にしていくという順番を意識しましょう。

以前上司にレビューで指摘してもらって以来意識するようになった。

コンテキストを共有していない人とコミュニケーションを取る時は特に重要だと感じている。自分と相手が持っている情報の差分を埋めるように情報を提示できるとスムーズにコミュニケーションを取れる印象がある。

2.2.3 既知から未知に繋ごう（P28）

文章を書くとき、「大枠から詳細へ」の他に意識すべきもう1つの順番は「既知から未知へ」です。技術ドキュメントを読んでいても、最初から知らない単語や知らない概念ばかりが次から次へと出てくると、「知らないことについて説明してくれているけど、その説明がまず分からない」という状態になります。

あまり意識したことがなかった。

一度にまとまった情報量を記述したい時にはこのあたりまで意識して書くと認知負荷が減ってよさそう。

2.4 再利用しやすい文章にする

2.4.2 並列はナカグロ（・）で書かない（P34）

文章の中で並列を表そうとして「ホーム・検索・マイページ・ヘルプのタブは非表示にできません」のようにナカグロ(・)を使っていると、再利用されて箇条書きになったときに、次のような見た目になることがあります。
着せかえの設定時、以下の機能は非表示にしたり、見た目を変更したりできません。
・ホーム・検索・マイページ・ヘルプのタブ
・トレンドワード機能
・ID連携機能

対策として、最初から箇条書きにしておくか、読点を使うといいとのこと。

いつもどう書くか迷っていたが・で並列関係を表現すると上記のデメリットがあるので読点を使うようにしてみようと思う。

2.4.4 リンクテキストを「こちら」にしない（P35）

リンク切れになったときやテキストだけコピーされたときにリンク先がどこを指しているのかわからなくなるため、以下のようにどういったページなのかも含めて書くのがいいとのこと。

また「詳しくはShops APIのAPIリファレンスをご覧ください」

また、読み手としてもリンクを踏む前にどんなページへ飛ばされるのかわかるというメリットも紹介されていた。

まとめ

具体的な知見が理由とセットで書いてあってとても勉強になった。¹チームで仕事をする上で認知負荷を下げる工夫の重要性を日々感じるのでこれから意識的に実践していきたい。

紹介したトピック以外にもたくさんの知見が紹介されていたので気になった方はこちらからぜひ購入してみてください。こちら ²

余談だがちゃんと理由まで書かれているとスムーズに理解できるのでちゃんと背景や理由を説明するのは重要だと感じた。 ↩︎
冗談です。リンクテキストにはリンクの内容がわかるようなものにしましょう。購入はこちらから。読み手につたわる文章 - テクニカルライティング - 技術書典マーケット ↩︎

『いちばんやさしいアジャイル開発の教本』を読んだ

Sat, 25 May 2024 15:48:56 +0000

2024/4からチーム異動してスクラムを実践しているチームに移ったのでアジャイル・スクラムのインプットをしたいと思い、『いちばんやさしいアジャイル開発の教本』を読んだ。

本書を読んで自分なりに勉強になったことをLessonごとに書いていく。（カッコ内のPxxはページを表す）

Lesson6. アジャイル開発とは何か（P28-31）

「継続的に改善することが前提」なので逆にいえば作りたいものが決まっているならばアジャイル開発を採用するメリットは薄いかもしれない。

Lesson7. カイゼン（P32）

世界で通じる日本語、“Kaizen”。このKaizenという言葉は日本においてもカタカナで 「カイゼン」 と表現されており、「改善」という単語とはあえて区別されています。

もともと改善という表現は「誤りや欠陥を正し、よりよいものにする」という意味があります。カイゼンは 「いまあるものをよりよいものにしていく」 という精神に基づいており、より前向きで積極的なものだということがわかります。

「カイゼン」という表記を見たことはあったが、文脈によっては「改善」とは別の単語として使われているというこれは知らなかった。

Lesson14. アジャイル開発の構造（P56）

マインドセット： アジャイルソフトウェア開発宣言
マインドセットを実現するための原則： アジャイル宣言の背後にある原則
現場での実践： スクラム・XP・FDD・カンバン・モブプロなど

Lesson17. 個人と対話（P66）

アジャイルソフトウェア開発宣言の 「プロセスやツールよりも個人と対話を」 について書いた章。

対話と議論の違いは何でしょうか。ざっくり説明すると、議論は自分自身の目線から主張を展開するものですが、対話は相手の価値観を尊重し、ともに考えていくものです。

プロダクト開発では不確実性が高いため、必ずしも正解がなく、あらゆる角度から課題を見つめることでより良い解決策を探っていくことが重要で、そのための有効な手段として「対話」があると解釈した。

また、対話を繰り返すなかで互いの認識のズレや齟齬を発見し解消していくことで、議論の前提にズレが生まれることが減り、よりスピーディーに問題解決を行うことができるようになりそう。（これはアジャイルに限らないが）

このように個人を尊重し、対話をしながらチームの課題と全員で向き合うことで相互理解が進み、それぞれが異なる立場からの視点を得ることができます。

盲目的にプロセスやツールに従うのではなく、個人との対話をして相互理解を深めることでチームが強くなる。そのようなチームでは信頼関係があり情報共有が活発に行われるため問題が起きても迅速にリカバリーできる。

Lesson.18 動くソフトウェア（P68）

アジャイルソフトウェア開発宣言の 「包括的なドキュメントよりも動くソフトウェアを」 について書いた章。

ソフトウェア開発においては課題とその解決方法を仮説として立て、実際にリリースして検証するという流れで開発を進めることが多い。

細かくリリースするのではなく、機能を全て作り込んでからリリースした場合、仮説と解決策の確らしさを検証できるのが遅くなってしまう。

なので、仮説を検証するために最低限必要な機能が備わっているプロダクト（MVP）を提供して仮説の検証を行うことでより素早く検証のループを回すことができる。

また、いくら社内で話し合ったところで実際の顧客の反応がわかるわけではないので、一定仮説を煮詰めたらリリースして実際の反応をみることが重要そう。

Lesson.19 顧客との協調（P70）

アジャイルソフトウェア開発宣言の 「契約交渉よりも顧客との協調を」 について書いた章。

自社開発の場合はこの契約交渉はどのような形となって現れてくるのでしょうか。たとえば、顧客からのフィードバックに対して「それは仕様が悪い」「仕様通りの挙動です」というようにいまのソフトウェアの挙動が正しいことを前提として判断してしまう、といった保守的な行動として現れます。

…(中略)…

ユーザーボイスを尊重しながら、そのままいわれたとおりに開発するのではなく、その声の裏側にある本当に要望を見極めていきましょう。

社内外からのフィードバックをフラットに受け取ってフィードバックの裏側の要求を見極めることでよりよいプロダクトを作っていけそう。

Lesson.20 変化への対応（P72）

アジャイルソフトウェア開発宣言の 「計画に従うことよりも変化への対応を」 について書いた章。

プロダクト開発においては常に最新の情報を基に仮説をアップデートすることが重要なので事前に決めた計画通りに進めることよりも、都度変化に適用することが重要そう。(それはそうという感じだが)

Lesson.22 自己組織化チームとリーダーシップ（P76）

図表22-2が示すように自己組織化チームとはひとことでいうと「自走できるチーム」です。自分たちがなぜここにいるのかを理解し、またお互いの得意分野がわかっているため自分たちで最適なフォーメーションを組みながらビジョンへと向かっていきます。リーダーの意思決定を待つことなく自己修復的に課題を解決していく。それが自己組織化チームの底力です。

『いちばんやさしいアジャイル開発の教本』P76より引用

チームの振り返りなんかでも、「どうすれば自己組織化チームに近付けるか」という観点で考えてみてもいいかもしれない。

自己組織化チームにおいて情報共有は重要な要素

よく透明性が大事、と聞くけどそれも個々人が自律的に行動するために情報は不可欠だからなんだろうなーと思った。

理想的な自己組織化チームとは？

(中略) 自己組織化し、それぞれのメンバーがリーダーシップを発揮できるようになると、 外からチームを見た際にはもはや誰がリーダーと呼ばれる役割なのかわからなくなるでしょう。

これは自己組織化されたチームの見え方の1つとして良さそうだとおもったので心に留めておきたい。

まとめ

まずは「自己組織化チーム」を目指していきたい。
実際にアジャイルの入門書を1冊読んでみて、とはいえまずはスクラムガイドをしっかり理解した方がよさそうだと思ったので次はスクラムガイドを読み込んでいこうと思う。

`Process failed to start: too many open files: "/opt/homebrew/bin/git"`というエラーが出てNeovimのプラグインが動作しなくなる問題の回避策

Mon, 13 May 2024 04:11:01 +0000

問題

ここ数日Neovimを使っていると、Process failed to start: too many open files: "/opt/homebrew/bin/git"といったエラーとともにプラグインが動作しなくなることがあり困っていた。

記憶にある範囲だとnvim-telescope/telescope.nvimやakinsho/toggleterm.nvimを使っているときにこのエラーが起きることが多かった印象。

筆者の環境

$ nvim --version
NVIM v0.9.5
Build type: Release
LuaJIT 2.1.1703358377

利用しているプラグインは後述。

回避策

この記事にしたがってファイルを作成したところエラーが出なくなった。

Macの「Too many open files」エラーを解消 - Qiita

「Too many open files」と出てで、ファイルが保存できないことがあった。 Railsを起動して、Gulpも起動してほげほげしてるとよく起こる。 Sublime Textでこのエラーが出ると設定も何もかも保存されないし、HotExitも効かないし、ファイルは開...

https://qiita.com/sou_lab/items/1ca051a1f3b906a23dc8

以下記事より引用。

sudo vi /Library/LaunchDaemons/limit.maxfiles.plist

viでもnanoでもcodeでもお好きなエディタのコマンドで下記コードをコピペ。

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
<plist version="1.0">
  <dict>
    <key>Label</key>
    <string>limit.maxfiles</string>
    <key>ProgramArguments</key>
    <array>
      <string>launchctl</string>
      <string>limit</string>
      <string>maxfiles</string>
      <string>524288</string>
      <string>524288</string>
    </array>
    <key>RunAtLoad</key>
    <true/>
    <key>ServiceIPC</key>
    <false/>
  </dict>
</plist>

参考

同時に開くことができるファイル数の上限に引っかかってしまっている模様。

もしかしたら一部のNeovimプラグインの特定のバージョンに原因があるのかもしれない。

もしかしたらこれをみた人の参考になるかもしれないのでlazy-lock.jsonを貼っておく。（原因特定までする元気はなかった）

{
  "Comment.nvim": { "branch": "master", "commit": "0236521ea582747b58869cb72f70ccfa967d2e89" },
  "alpha-nvim": { "branch": "main", "commit": "41283fb402713fc8b327e60907f74e46166f4cfd" },
  "barbecue": { "branch": "main", "commit": "cd7e7da622d68136e13721865b4d919efd6325ed" },
  "bufferline.nvim": { "branch": "main", "commit": "73540cb95f8d95aa1af3ed57713c6720c78af915" },
  "cmp-buffer": { "branch": "main", "commit": "3022dbc9166796b644a841a02de8dd1cc1d311fa" },
  "cmp-look": { "branch": "master", "commit": "971e65a6be0e75c3438fe7b176d4fc020cb89d7b" },
  "cmp-nvim-lsp": { "branch": "main", "commit": "5af77f54de1b16c34b23cba810150689a3a90312" },
  "cmp-nvim-lsp-signature-help": { "branch": "main", "commit": "3d8912ebeb56e5ae08ef0906e3a54de1c66b92f1" },
  "cmp-nvim-lua": { "branch": "main", "commit": "f12408bdb54c39c23e67cab726264c10db33ada8" },
  "cmp-path": { "branch": "main", "commit": "91ff86cd9c29299a64f968ebb45846c485725f23" },
  "cmp-vsnip": { "branch": "main", "commit": "989a8a73c44e926199bfd05fa7a516d51f2d2752" },
  "copilot.vim": { "branch": "release", "commit": "b603990a639bb4b8651d054ef8d5a8fe5db56e0c" },
  "dial.nvim": { "branch": "master", "commit": "27eb570085db2ef44bff4f620d3806039184651c" },
  "fzf": { "branch": "master", "commit": "24ff66d4a9d6889988e4d7e373f33f4098870b9e" },
  "gitsigns.nvim": { "branch": "main", "commit": "bc933d24a669608968ff4791b14d2d9554813a65" },
  "gotests-vim": { "branch": "master", "commit": "42abccb59e9889cd1ce427b11b2ffbb36f2a46a6" },
  "gruvbox.nvim": { "branch": "main", "commit": "dd0ab08b17d2ead7bdb4838b48e1d08034ead0f0" },
  "harpoon": { "branch": "harpoon2", "commit": "0378a6c428a0bed6a2781d459d7943843f374bce" },
  "indent-blankline.nvim": { "branch": "master", "commit": "3d08501caef2329aba5121b753e903904088f7e6" },
  "lasterisk.nvim": { "branch": "main", "commit": "bbcfcaeca50f686e338a03386e41645fc3305f44" },
  "lazy.nvim": { "branch": "main", "commit": "ebdd0499551765e6a7aba220cc8ae4e0cdb6be69" },
  "lazygit.nvim": { "branch": "main", "commit": "0ada6c6e7e138df92f5009b6952f4ac41248305a" },
  "lsp-lens.nvim": { "branch": "main", "commit": "48bb1a7e271424c15f3d588d54adc9b7c319d977" },
  "lsp_signature.nvim": { "branch": "master", "commit": "c6aeb2f1d2538bbdfdaab1664d9d4c3c75aa9db8" },
  "lspkind.nvim": { "branch": "master", "commit": "1735dd5a5054c1fb7feaf8e8658dbab925f4f0cf" },
  "lspsaga.nvim": { "branch": "main", "commit": "052234296f13e2705d5d290c7bd5a36d3dd81fde" },
  "lualine.nvim": { "branch": "master", "commit": "0a5a66803c7407767b799067986b4dc3036e1983" },
  "mason-lspconfig.nvim": { "branch": "main", "commit": "05744f0f1967b5757bd05c08df4271ab8ec990aa" },
  "mason.nvim": { "branch": "main", "commit": "751b1fcbf3d3b783fcf8d48865264a9bcd8f9b10" },
  "neo-tree.nvim": { "branch": "v2.x", "commit": "80dc74d081823649809f78370fa5b204aa9a853a" },
  "noice.nvim": { "branch": "main", "commit": "f4decbc7a80229ccc9f86026b74bdcf0c39e38a7" },
  "nui.nvim": { "branch": "main", "commit": "274fa89a9b4bed746647c2917091902f882509ec" },
  "nvim-autopairs": { "branch": "master", "commit": "14e97371b2aab6ee70054c1070a123dfaa3e217e" },
  "nvim-bqf": { "branch": "main", "commit": "52703d7adc3be3f7c09eea9a80c5b8caa615fb25" },
  "nvim-cmp": { "branch": "main", "commit": "8f3c541407e691af6163e2447f3af1bd6e17f9a3" },
  "nvim-hlslens": { "branch": "main", "commit": "3e8fceb2b030100857ee72741a8f48c9a1d8595e" },
  "nvim-jdtls": { "branch": "master", "commit": "8eb5f0dbe6e126b392ddcaf45893358619893e45" },
  "nvim-lspconfig": { "branch": "master", "commit": "ee450e6a9364fc740236166dd57aaca1ec7cdb48" },
  "nvim-metals": { "branch": "main", "commit": "c6268555d0b471262af78818f11a086ddf30688b" },
  "nvim-navic": { "branch": "master", "commit": "8649f694d3e76ee10c19255dece6411c29206a54" },
  "nvim-scrollbar": { "branch": "main", "commit": "35f99d559041c7c0eff3a41f9093581ceea534e8" },
  "nvim-treesitter": { "branch": "master", "commit": "4b70dde72753a179333b4bba02518d234a30510e" },
  "nvim-ts-context-commentstring": { "branch": "main", "commit": "a6382f744f584bbf71d0a563af789af7190aabda" },
  "nvim-web-devicons": { "branch": "master", "commit": "475fbcfcb6ee7c35aa33a6b6207ebd4032791d87" },
  "plenary.nvim": { "branch": "master", "commit": "08e301982b9a057110ede7a735dd1b5285eb341f" },
  "pounce.nvim": { "branch": "master", "commit": "0c044cad69571d57d8f64a41cca95332859b6abc" },
  "sqlite.lua": { "branch": "master", "commit": "d0ffd703b56d090d213b497ed4eb840495f14a11" },
  "telescope-egrepify.nvim": { "branch": "master", "commit": "728dc1b7f31297876c3a3254fc6108108b6a9e9d" },
  "telescope-frecency.nvim": { "branch": "master", "commit": "6b6565e6584c86ca501bdac485cbdc2ca64556e4" },
  "telescope-fzf-native.nvim": { "branch": "main", "commit": "9ef21b2e6bb6ebeaf349a0781745549bbb870d27" },
  "telescope.nvim": { "branch": "master", "commit": "fac83a556e7b710dc31433dec727361ca062dbe9" },
  "todo-comments.nvim": { "branch": "main", "commit": "a7e39ae9e74f2c8c6dc4eea6d40c3971ae84752d" },
  "toggleterm.nvim": { "branch": "main", "commit": "066cccf48a43553a80a210eb3be89a15d789d6e6" },
  "translate.nvim": { "branch": "main", "commit": "30cc9e9f339b61e7bd40bc1ba7af73ea193bf589" },
  "vim-illuminate": { "branch": "master", "commit": "e522e0dd742a83506db0a72e1ced68c9c130f185" },
  "vim-test": { "branch": "master", "commit": "eb5bd18d58a859e7d55d732d37e4e2b94fa50275" },
  "vim-to-github": { "branch": "master", "commit": "9ea9c75b6cd48bd42823a39c56a05a2ff8161536" },
  "vim-vsnip": { "branch": "master", "commit": "02a8e79295c9733434aab4e0e2b8c4b7cea9f3a9" },
  "vim-vsnip-integ": { "branch": "master", "commit": "1914e72cf3de70df7f5dde476cd299aba2440aef" },
  "yode-nvim": { "branch": "develop", "commit": "eaf3141b919c143ebf174d7ad180abd9c032b38c" }
}

CS50.jpでCSに入門した

Sun, 12 May 2024 06:32:42 +0000

CS50.jpの気になっていたトピックを学んでみたので振り返っておく。

CS50.jpとは

CS50.jpの説明はサイトから引用する。

このページは、ハーバード大学 CS50 の日本語版翻訳プロジェクトのページです。当サイトのドメインに掲載されているコンテンツは、Creative Commons ライセンスが適用されています。個人利用のほか、非営利に限って教材として利用することができます。

（中略）

ハーバード大学の CS50x は、コンピュータサイエンスとプログラミング技術を紹介するコースで、プログラミングの経験の有無にかかわらず、経験者と未経験者の両方を対象としています。David J. Malan が担当するエントリーレベルのコースである CS50x では、アルゴリズム的に考え、問題を効率的に解決する方法を学びます。テーマは、抽象化、アルゴリズム、データ構造、カプセル化、リソース管理、セキュリティ、ソフトウェアエンジニアリング、ウェブ開発など。言語は C、Python、SQL、JavaScript に加え、CSS と HTML を使用します。問題集は、生物学、暗号、金融、科学捜査、ゲームなどの実世界の領域からヒントを得ています。CS50x の学内版である CS50 は、ハーバード大学で最大のコースです。

カリキュラムは次のような構成になっている。

Week0 Scratch
Week1 C
Week2 Arrays
Week3 Algorithms
Week4 Memory
Week5 Data Structures
Week6 Python
Week7 SQL
Week8 HTML, CSS, JavaScript
Week9 Flask
Week10 Ethics
Security
Artificial Intelligence
Final Project

各章はレジュメと課題で構成されている。

課題を解いてコードを提出するとリモート環境でテストが実行され結果を確認できる。¹

正直にいうと日本語訳がなかったら取り組もうと思わなかったと思うのでCS50.jpの翻訳コントリビュータであるCODEGYM社には感謝してもしきれない。本当にありがとうございます。

そもそもなぜCSを勉強しているか

前提として筆者について補足しておくと筆者は電気系の学部・大学院を卒業しておりコンピューターサイエンスのバックグラウンドを持っていない。（かつSaaS企業でソフトウェアエンジニアとして働き初めて現在4年目）

「〜という分野に精通して自分の業務パフォーマンスを向上させる」のような明確な目的意識はないがおおむね以下のような理由でやっている。

CSの知識を習得することでソフトウェアエンジニアとして見える世界がどう変わるのか知りたい
普段触っている技術の裏側を理解することでよりよい選択ができたり、より素早い問題解決ができるのではないか、という仮説がある
知的好奇心を満たすことができて単純に楽しい

やったこと

Week6 Python以降は自分にとって大きな学びはなさそうだったのでWeek5 Data Structuresの課題（Lab & Problem Set）までを取り組んだ。2024/3/8~2024/5/3まで平日夜や土日の時間を使って取り組んだ。

自分のメモ用のリポジトリは以下。（解いた課題のコードも載っているのでネタバレ（？）注意）

GitHub - kyu08/cs50: https://cs50.jp/

https://cs50.jp/. Contribute to kyu08/cs50 development by creating an account on GitHub.

https://github.com/kyu08/cs50

学びや得たもの

CSの基礎

CSの基礎の導入部分くらいには触れることができたと思う。たとえばこのあたり。

ASCIIとは
Cで記述したプログラムが実行可能になるまでの流れ
アルゴリズム
- O記法とΩ記法
- 代表的なソートアルゴリズム
データ構造
- 連結リスト(課題ではダイレクトチェイニング法を用いた連結リストを使ってハッシュテーブルを実装した)

ただ、各週の講義動画は1.5hくらいのボリュームなのであくまでそれぞれのトピックの序章（または序章の導入部分）くらいの内容だとは思う。

C言語の基礎

あとはWeek1 ~ Week5までの課題はすべてC言語で課されたのだが、C言語の経験が得られたのは自分にとって貴重だった。(各Weekの課題が2~3問あり合計で14問の課題をC言語で解いた。)

特に

文字列の扱い（終端文字）
数値型のオーバーフロー

あたりが印象に残っている。（課題を解いていてこれらに起因するバグに何度か悩まされた）

C言語を触ることで現在自分がよく触っている言語であるGoやRustがいかに便利かを思い知った。

あとはC言語で書かれたOSSやサンプルコードの理解を多少は深めやすくなったので今後の学習・調査の助けになってくれそう。

まとめ

全体感としてはCSの勉強をやっていく上での基礎的な知識を学ぶことができ、今後の学習の足がかりになってくれそうだったので取り組んでみてよかった。あとはC言語の経験が得られてよかった。

やはり新しい分野や言語を習得するには時間を投資して手を動かすのが自分にはあっているように思った。引き続きやっていき。

テストケースはcs50/problemsにあるので参考にしながら課題を進めた。 ↩︎

tmux-fzfを使ってwindow切り替えをできるようにする手順

Wed, 10 Apr 2024 14:12:22 +0000

これはなに

こんな感じでtmuxでwindowをfzfで切り替えられるようにするための設定方法

手順

.tmux.confに以下を追記

set -g @plugin 'tmux-plugins/tpm' # すでにある場合は不要
set -g @plugin 'sainnhe/tmux-fzf'
bind-key "space" run-shell -b "${HOME}/.tmux/plugins/tmux-fzf/scripts/window.sh switch" # `prefix + space`で起動

run '~/.tmux/plugins/tpm/tpm' # すでにある場合は不要

prefix + Iでtpm経由でプラグインをインストール(prefix + iではないので注意)

クラムシェルでMacを使っているとき用のマイクとしてEarPodsを買った

Sat, 30 Mar 2024 15:00:38 +0000

前提

社でバーチャルオフィスツールとしてGatherを使っており、就業中は基本的にずっとログインしているため急に話しかけられることがある
- 普段はマイクをオフにしておき、話しかけられた時だけONにしている
机ができるだけスッキリするのが好きなので画像のようにMacをクラムシェルモードで使っている
- Macのマイクは使えないのでAirPods Proをマイクとして使っている

課題

同僚に話しかけられた時には

AirPods Proを装着
BluetoothでMacに接続されるのを待つ
GatherのマイクをONにする

という手順が必要なのだが、AirPods Proの接続を待つ必要があるので話かけられた相手を待たせてしまう。(話しかけられてから話せるようになるまでだいたい5秒くらい)

解決策

EarPods(AirPodsではなく)を買ってMacに常時接続しておくことで話しかけられたらGatherのマイクをONにするだけで話せるようにした。

これにより話しかけられてから1秒弱くらいで話せる状態にできるようになった。

特に音質が悪かったり声が聞きづらいみたいなFBはもらっていないので今のところ特に問題はなさそう。

GitHub Issuesをサイトのコメント欄として活用できるutterancesを導入した

Sun, 17 Mar 2024 13:06:40 +0000

このブログにコメント欄を設置した。

utterance/utterancesというGitHubのIssuesへのコメントを記事のコメント欄として使えるようにしてくれるOSSのツールを使っている。¹

導入に必要だったのは

コメント用のリポジトリ作成²
https://utteranc.es/でscriptタグを生成
生成したタグをブログに埋め込む

だけだったので10分くらいでできて大変お手軽だった。

(自分はこのブログのリポジトリのissueをコメント用に使いたくなかったのでそれ用のリポジトリを作成したが、もし既存のリポジトリを使う場合は1.は不要)

ぜひご自由にコメントを残していってください。

https://blog.orhun.dev/で使われていていいなと思ったのでこのブログでも導入してみた。 ↩︎
https://github.com/kyu08/blog-comments ↩︎

『ベタープログラマ』を読んだ

Wed, 06 Mar 2024 15:27:45 +0000

『ベタープログラマ』を読んだので自分的に刺さった点をまとめる。

6章航路を航行する

新たなメンバーが開発チームに参加する際にどのようにすれば速やかに生産的になることができるかについての章。

最善な策はすでにプロジェクトへの理解があるメンバーに導いてもらうこと。もしそれができなければ次のようなことを調べるとよい。

ソースの取得の容易さ

ソースの取得がどれだけ簡単か。健全なプログラムはコードベース全体を得るための単一のチェックアウトのみを必要とする。

コードのビルドの容易さ

一般的でないツールにビルドが依存していないか
コード自身に適切で簡単なドキュメンテーションがあるか
手作業なしで1つのコマンドでビルドを行うことができか
コードの一部に取り組んでいるときにその部分だけをビルドできるか
ビルド中に潜在的な問題を曖昧にしているかもしれない無数の警告が出ていないか

テスト

単体テスト・インテグレーションテスト・システム全体のテストがどの程度揃っているか
テストは自動で実行されるか。あるいは追加のビルドステップを必要とするか
テストはどれだけ頻繁に実行されているか
カバレッジはどの程度か
テストは適切できちんと作成されているか

コードとテストには普遍的な関連性がある。優れたテストが存在するコードはたいていきちんとリファクタリングされ、きちんと考え尽くされている。

ファイルの構造

ディレクトリの構造が領域・サブシステム・コードの階層を明確に表しているか
ディレクトリの構造が整っているか
サードパーティのライブラリはプロジェクトのコードからきちんと分離されているか

ドキュメンテーション

ドキュメンテーションは存在するか。わかりやすく、かつメンテナンスされているか

要件

プロジェクトの要件文書あるいは機能仕様書があるか。

プロジェクトの依存物

コードは特定のFWやライブラリを使っているか。それらについてどの程度学ぶ必要があるか
コードが言語の標準ライブラリをうまく利用しているか

コードの品質

品質の感触を得るためにざっと目を通す。

コードのコメントの量と質はどうか
多くのデッドコードがあるか
コーディングのスタイルは全体にわたって首尾一貫しているか

アーキテクチャ

ここまでの項目を通して主となる階層群を特定できるか
それらの階層がきれいに分離されているか

上記を実施すれば素早くプロジェクトについて把握できる。では実際にプロジェクトに取り組む際にはどのようにすればいいか。

やってみて学ぶ
- コードを読むことは読むことにすぎない。実際に取り組んでみて、間違いを犯すことによってのみコードベースを学ぶことができる
何か単純で小さな修正から着手する
コードを点検する
- コード検査ツールをコードベースに対して実行してみる
- コンパイルの警告が無効にされいないか調べる。無効にされていれば有効にして警告が表示されないようにコードを修正する。それによってコードベースの構造と品質の理解を深めることができる
調査、そして行動
- コードの小さな部分を調べ、批評してみる。弱点がないか調べ、容赦なくリファクタリングする。正しい命名に修正したり、長いコードを小さくて適正な命名をもつ関数に切り出す
- このような作業を数回行うことで、コードにどれだけの柔軟性があり修正や変更に対してどれだけ従順であるかの感触を得ることができる
維持管理
- ソースファイルを整頓したりディレクトリ階層を正しくしたりする
わかったことを文書化する
- コードに取り組み始める方法を説明しているトップレベルのREADMEは存在するか。しなければ作成してこれまでに学んだことを書く
- そのドキュメンテーションを経験のあるプログラマにレビューしてもらう

新たなコードベースに取り組むほど、新たなコードを効果的に学ぶことができる。

この章はプロジェクトのキャッチアップに必要な観点が多く記述されていてとても参考になった。

新しくプロジェクトに参加した際(業務・OSS関わらず)
既存のプロジェクトの課題点を整理する際

などのタイミングで特に参考にできそう。

14章ソフトウェア開発とは

ソフトウェア開発は退屈な仕事

ソフトウェア開発の仕事の多くは、楽しくありません。魅力的でもありません。(中略)有能なプログラマであるためには、退屈な仕事を恐れてはいけません。(中略)時には、私達はソフトウェアの清掃員にならなければならず、次のことが求められます。…

自分が学生のときには想像できていなかったソフトウェアエンジニアの現実、という感じがする。学生のときには毎日コードを書けるなんて夢みたいだ！と思っていたけれど、実際には楽しくない仕事もあるしコードを書かない日もある。ただ、自分が見てきた優秀なエンジニアたちはそういった仕事であっても着実に丁寧に素早くこなしていた印象がある。

あと、このところは

チームとして成果を出すためにはどうすればいいか
身の回りの人から信頼される振る舞いとはどのようなものだろう

を意識して行動するようにしていて、自分にとってタスクが楽しいかや成長に繋がるかということをいい意味で意識せずに仕事ができている。この意識を持つようにしてから仕事が楽しく感じられるようになったので自分にとってもかなりいい変化だった思う。

15章規則に従って競技する

自分達で決めた規則が必要です。私達が所有権を持つ規則です。特定のチームにおける文化、およびうまく開発できる方法を定めている規則です。これらは、大きくて、扱いにくい厳しい規則である必要はありません。新たなチームメンバーがすぐに一緒に開発できるように、単純なものでよいです。つまり、それらは単なる方法やプロセスよりも詳しく何かを記述している規則であったり、コーディング文化を記述している規則だったりします。すなわち、チームで優れた選手になるための方法を記述している規則です。

この 「チームで優れた選手になるための方法を記述している規則です。」 という部分が特にいいなと思った。チームメンバーとして活躍する方法が言語化されていることで、新しいメンバーが素早く立ち上がることができるだけでなく、すでにチームに所属しているメンバーもことあるごとに立ち返ることができて、方向性がずれかけてもうまく軌道修正できるなどのメリットがありそう。

個人的にチームで共通理解を持つことでチームの方向性がうまく揃い、軌道修正もしやすかった経験を部活のときにしたのでこの章の内容はとても腹落ちした。

18章変わらないものはない

コードのどの領域も、誰にも「所有」されていません。どの領域でも、誰もが変更を行うことが許されています。コードを所有するといった制度は避けてください。それは、変更を抑制します。

サーバーサイドの開発チームに初めて異動したときは「自分よりもサーバーサイドも経験が長いエンジニアたちが書いたコードだからどの部位も意図があり、設計も練られた上で今の実装になってるに違いない…！だから強い理由がないとなかなか変更を加えるべきではないのではないか」という思い込みがあったが、何ヶ月かサーバーサイドの開発の経験を積んで「なんか全然自分でも修正できそうなところあるぞ・・・！」と感じられるようになった。

いい意味でフラットな目線でコードベースに触れる意識を持てるとよさそう。

28章倫理的なプログラマ

プログラミングのキャリアの中で、最も頻繁に出会う人々は、チームメイトです。彼らは、毎日一緒に働くプログラマやテスターなどです。倫理的なプログラマは、彼ら全員と一緒に誠実に働き、各チームメンバーに敬意を払って、できる限り最善の結果を達成することに注意を払っています。

どれだけ成熟しているとか経験を積んでいるとかに関係なく、誰もが貢献できる価値を持っていることを常に信じてください。

誠実で信頼されるようになってください。誰にでも誠意を持って接してください。

大事。

倫理的なプログラマは、燃え尽きるような働き方をしません。それは、個人的に不都合であるだけではなく、チーム全体に対しても悪い影響を与えます。毎週、何十時間も残業すれば、疲れ切ったプログラマになり、必ず不注意な間違いを生み出し、悪い結果となります。驚くほど熱心に働く英雄のように思われるのは素晴らしいですが、倫理的なプログラマは、非現実的な期待に応えようとして、自身が燃え尽きてしまうのは悪い考えであることを理解しています。

直感では理解できるが、プロジェクトの種類によっては残業の量が成果に直結することもあり難しい。残業を最後の手段にしつつ必要なときはやる、くらいの感覚がいいのだろうか。(残業前提でスケジュールを組み出すと工夫をする発想がなくなり、効率が上がらず長期的には損だと思う。もちろん燃え尽きリスクが高まるという面でもそう。)

あとは現実的にビジネス的に絶対に守りたい締切があることはあると思う。現場レイヤー目線だと踏ん張りどこは頑張って、乗り切ったら少し休むようにし、マネジメントレイヤー目線だとそうならないように人員計画をいい感じにするとかがいいのだろうか（？）

ただ、チームをマネジメントする立場からみると長期間安定して働いてくれることも一定嬉しいとは思うので無理をしすぎないことも重要そう。

結び

ひどいプログラマと優れたプログラマを区別しているものは、態度です。それが、単なる適当なプログラマと並外れたプログラマを区別するものです。

態度は、技術スキルに勝ります。プログラミング言語の複雑な知識は、保守可能なコードを保証しません。プログラミングのモデルを多く理解したからといって、必ずしも優れた設計を生み出すとは限りません。あなたのコードが優れているかどうかと、あなたと一緒に働くのが楽しいのかどうかを決めるのは、あなたの態度なのです。

この記述がこの本を通して特に刺さった。シンプルだがとても重要なことだと思う。「何ができるか」も重要だが、それ以上に「どうしたいか」や「どこを目指しているのか」がより重要なのだろうと思った。ついついハードスキルばかりに目がいってしまうがそういった志向性を持つことにも同様に気を配りたい。

自分が見てきた優秀なエンジニアはこれを体現している人ばかりだったように思う。

最悪技術力の不足はレビューなどで他のエンジニアの力を借りて補うことができても、オーナーシップや主体性に限っては自分自身で持つしかない。¹そういった意味でもどのようにすれば良い態度を保ち続けられるか、はふりかえりや環境選びの重要な観点になるように思える。

感想

「優秀なエンジニアはどう振る舞うか」を主題に数多くのトピックが書かれていてとても参考になった。自分がこれまで接してきた優秀なエンジニアの振る舞いとも重なるところが多かった。優秀なエンジニアがなぜ優秀かをあらゆる角度から言語化していて理解を深めることができたし、自分も真似できそうなことが多くあったので実践していきたい。

次は久々に技術寄りの本を読みたくなったので次はRust関連の本を読んでみたいと思う。²

あとは「プログラマー脳」も気になるのでいずれ読みたい。

もちろん日々研鑽して自分の技術力を高めることも当然重要だと思っている。 ↩︎
「コンセプトから理解するRust」でRustの理解を深めて「詳解Rustプログラミング」でRustで低レイヤーを学んでいこうと思っている。 ↩︎

2023年を振り返る

Fri, 29 Dec 2023 15:03:17 +0000

趣味

OSS貢献

今年は初めてOSS貢献¹をできた年でもあった。2023年に行った貢献を種類ごとにリポジトリごとでまとめたものが以下。²

2023年8月以降で20個のPRをマージしてもらうことができた！ほとんどが簡単なPRだったとはいえ感謝してもらえることも多かったので単純に嬉しかった。

一定数OSSに貢献できたのは嬉しいが、ドキュメントやCIの修正など比較的ハードルが低めの貢献が多かったのも事実。

流石にOSSにPRを出すことには慣れてきたので2024年は上記のような貢献もしつつ何らかのOSSのアプリケーションコードへの貢献もしていきたい。

OSSメンテナ観点では、どのプロジェクトのメンテナも非常に紳士的で優しく接してくれる方が多かったので自分も見習っていきたい。特にRustコミュニティは初心者を歓迎する雰囲気があり、PRを送った際の体験がとてもよかったので真似したい。

Rustを書き始めた

2023年2月³ごろからRustを書き始めた。きっかけはkenkooooさんのこのスライドを読んで「Elmに似てて開発者体験がよさそう」と感じたので触ってみることにした。

満を持して始める Rust

入門に際して以下のようなことをやった。

Tour of Rustを読んでなんとなく雰囲気をつかむ
The Rust Programming Languageを手を動かしつつ(わからないところはいったん飛ばしつつ)一通り読む
RustでCLIアプリを作る

3. で作ったアプリをOSSとして公開した。

kyu08/fzf-make⁴

fzf-makeを公開した

こんな感じでMakefileに定義したtargetを曖昧検索で絞り込んで実行できるツールを作った。プレビューウィンドウがあるのが地味に便利なポイントでtargetの内容を確認しつつ実行できる。

Rustの理解を深めるのと自分の普段の作業を効率化したくて作ったがその両方が割と達成できているので満足している。特に所有権やスマートポインタに関してはThe Rust Programming Languageを読んだときにはイマイチ理解できなかったが実際に自分でコードを書いてコンパイラに指摘されてコードを修正することで理解を深めることができた。⁵

最初は身近な人に紹介して使ってもらったりしていたが、ある日面識のない日本人の開発者の方がバグ報告issue⁶を立ててくれて、インターネットの向こう側の人に自分のアイディアが届いて気に入ってもらえて、しかもわざわざバグ報告をしてくれたという事実がとても嬉しかった。

当然個人の趣味開発なので副業などとは違い時給を得て開発しているわけではないが、ものづくりを通して他者に喜んでもらうということが自分にとって最高の喜びだとわかっただけでも非常に良い経験だった。自分がOSSコミュニティに貢献したいと考えているのも究極は「人に喜んで欲しいから」なのかもしれない。

その後も何人かの人がstarしてくれたりTwitter(現X)で言及してくれたり⁷、issueを立ててくれたり、時にはPRを送ってくれたりして自分が書いたツールを通して海外のエンジニアとも交流できたのは自分にとって非常に刺激的だった。

これから開発したい機能や修正したいバグはまだまだあるので来年以降も引き続き開発を続けていきたい。Homebrewをはじめ、いくつかのパッケージマネージャでインストールできるのでぜひ使ってみてください。あとスターくれると大変嬉しいです！よろしくお願いします！

kyu08/fzf-make

Neovimへの寄付

筆者はNeovimには仕事・趣味のプロジェクトなど自分が行うすべての開発に収まらずちょっとしたタスク管理やブログ執筆などあらゆる場面でとにかくお世話になっている。

Neovim自体はOSSなので無償で利用できるわけだが、あるときNeovimコミュニティの成果にフリーライドに近い状態⁸になっている自分に気付いてからNeovimをはじめとしたOSSへの自分の関わり方に対し違和感を感じるようになったのでまずは経済的な支援でNeovimに貢献してみようと思い、GitHub Sponsorsを通じてNeovimに対して5$/Monthの寄付を開始した。⁹¹⁰

冗談抜きにNeovimのメンテナあっての自分の開発生活なのでこれは来年も続けたい。(本当のところはもっと稼いでもっと寄付したい)

ブログ

2023年は20個の記事を書いた。たまに「あの記事読んだよ！」的な反応をもらうことがあって嬉しかった。Twitterで話しかけたり感想を伝えてくれたりするのは嬉しいのでお待ちしています。

以下のような目的でやっているいて、後者はともかく前者は効果を実感できているので来年も適度に続けていきたい。

アウトプットを通して自分の理解と記憶への定着を深める
知見を共有して見た人の役に立つ

fzf-bookmark-openerを公開した

ブックマークをfzfで絞り込んで開くことができるCLIツール。自分が欲しかったので作った。

kyu08/fzf-bookmark-opener¹¹

同時期に書いたkyu08/gcp-url-generatorと組み合わせて業務でよく使っている。特定のGCPプロジェクトの特定のGCPサービスのコンソールをターミナルから開きたいことが多いので重宝している。

ktr0731/go-fuzzyfinderのおかげで100行程度のコードでやりたいことが実現できて大変助かった。

買ってよかったもの

Nuphy Air60 v2
klack
コアラマットレスのマットレス
オーダーメイド枕
Salomon XT-6
なすの天ぷら

大晦日に元気があったら記事として書きます。

仕事

やったこと

SaaSプロダクトのバックエンドエンジニアとして主に負債解消プロジェクトに取り組んでいた。

Scalaで書かれたアプリケーションのGoへの移行
DatastoreからCloud Spannerへの移行
E2Eテストの整備

などを行った。マイクロサービス何もわからないのでオライリーのマイクロサービス本あたりを読んで勉強したい。

学びなど

12月ごろからこれまでよりは大きめのプロジェクトを任せてもらっている。これまで担当したプロジェクトよりは自分で考える幅が広いのもありかなり楽しく働けている。引き続きより大きな信頼を勝ち取って自分の仕事の幅を広げていけるように頑張っていきたい。
ローカルでテストできる環境が整っていると開発速度が爆上がりすることを実感した。多少整備に時間がかかったとしてペイすることが多いと思うので他のプロジェクトでもうまいこと時間を確保して整備していけるとよさそう。
DBに関連する色々を雰囲気でやってしまっていると自覚があるので年末年始はRDBの基礎的な原理¹²や業務でメインで使っているDBであるCloud Spanner¹³の理解を深めていきたい。

2024年の抱負

引き続き仕事をモリモリがんばる。
OSS貢献を続ける。何らかのOSSのアプリケーションコードにも貢献する。

まとめ

最後まで読んでくれてありがとうございました！良いお年を〜

2024年もがんばるぞー

初めてOSS貢献したときの記事はこちら。 OSSに初めてPRを送ってマージされた話 ↩︎
(主に来年の自分向け)このスクリプトを使ってデータを集めた。GitHubで自分がOSSに送ってマージされたPRを集計するやつ.md ↩︎
tour-of-rustのメモリポジトリが2023/2頃にできていたのできっとこの頃から書き始めたはず。そういえばkeenさんのこのメモリの記事がすごくわかりやすかった。メモリとスタックとヒープとプログラミング言語 ↩︎
モチベーションになるのでスターください！拡散もしてくれると泣いて喜びます！ ↩︎
そういえばrust-lang/rustlingsというコンパイルエラーを修正していくことでRustの理解を深めるというコンセプトのリポジトリがあるので作りたいものはないがRustの理解を深めたい人にはおすすめかもしれない。（筆者はREADMEを読んだだけで触ったことはない） ↩︎
https://github.com/kyu08/fzf-make/issues/21 ↩︎
https://twitter.com/orhunp_/status/1692511841270841502 ↩︎
songmuさんも言っているようにOSSを使っていることを公言することもOSSプロジェクトにとってはプラスになるとは思うが、それぐらいでは済まないくらいNeovimに自分の開発人生を豊かにしてもらっている自覚がある。 ↩︎
初めてNeovimに寄付をしたときの話はこちら。GitHub Sponsorsを通してNeovimに寄付をした ↩︎
ちなみにNeovimへの寄付の使途はopen collective上で公開されている。 https://opencollective.com/neovim ↩︎
紹介記事はこちらyamlに定義したbookmarkをfzfで選択してブラウザで開くCLIツールをGoで作った ↩︎
SQLのインデックスとそのチューニングについてのオンラインブックや図解 DB インデックスあたりを読んでみようと思っている。 ↩︎
地道に公式ドキュメントを読んでいくつもり ↩︎

『世界一流エンジニアの思考法』を読んだ

Sun, 19 Nov 2023 01:41:50 +0000

Microsoftのエンジニアとしてアメリカで働いている牛尾剛さんが優秀な同僚から学んだ思考法について書いた著書『世界一流エンジニアの思考法』を読んだので学びになったトピックについて簡単に書こうと思う。

頭がよくても「理解」には時間がかかる

ある若くて優秀な同僚が新しいプロジェクトに参加するときにアーキテクチャの説明ビデオを「難しいので何回も見直している」と言っていたのに対して著者が衝撃を受けたというエピソードが紹介されていた。

なかなか他人の作業過程を観察する機会もないのでついつい「優秀な人は複雑な物事でも一瞬で理解してしまうのだろう」と想像してしまいがちだが、Microsoftの凄腕エンジニアでも理解に時間がかかることがあるという実例を知り、何だかとても励まされた気分になった。

新しい技術や概念の理解に時間がかかるとついつい仮想上の優秀な人と自分を比べて「はやくインプットしてはやくアウトプットを出さなければ」と焦るのをたまにやってしまうが「優秀な人でも物事を正確に理解するには時間がかかることもある」という心持ちでいるだけで焦らず着実にインプットしていけそうだと感じた。

そうして「正確に理解している概念」が増えていくほど新しい概念を理解する速度も向上するはずなので焦らず地道に理解することに努めたい。（もちろん時間的制約があるケースもあるので一概には言えないが）

このトピックに関しては以下の記事にもあるのでもし気になったら読んでみて欲しい。

プログラミングというより物事が出来るようになる思考法｜牛尾　剛

完全に余談だが、優秀な人をリスペクトしすぎると「自分とあの人は違うしな・・・」と自分にはそういった人のような素晴らしいアウトプットは出せないという思い込みを持ってしまいがちなので自分を卑下せずかといって奢りもせずフラットな気持ちで自分を励ましまくっていきたい。

Be Lazy(怠惰であれ)

より少ない時間で価値を最大化するという考え方。これを体現するために習慣として次が紹介されていた。

望んでいる結果を達成するために、最低限の努力をする。

不必要なものや付加価値のない仕事（過剰準備含む）をなくす。

簡潔さを目指す。

優先順位をつける。

時間や費やした努力より、アウトプットと生産性に重点を置く。

長時間労働しないように推奨する。

会議は会議の時間内で効率的かつ生産的に価値を提供する。

自分なりに抽象化すると

成果にフォーカスする
より効率的に成果が出るように工夫する

ということなのかなと思った。

とくに自分は成果を安定的に出せているかと言われると全然そんなことはないので、まずは「成果を出すこと」次に「より効率的に成果を出すこと」というステップで意識していくと良さそうだと思った。（あまり残業しないことばかりに意識を向けると結局期待される成果がでずに会社も自分も不幸せ、という状況に陥ってしまいそう）

ただ、成果を出す手段として長時間労働を第一の選択肢にしてしまうとさまざまな弊害があるとは思うのでそこは気をつけたい。

長期的な生産性を高めるためには

振り返りをして改善し自分 / 自チームの生産性を高めること
振り返りを通して得た気付きを共有して組織の生産性を高めること
自分のスキルアップに一定時間を投資すること

あたりは大事かなと思うのでやっていきたい。

タイムボックス制

以下のように紹介されていた。

タイムボックス制で、学習の時間を確保する

今までは、時短を試みても「アウトカム」重視派だったので、切りのいいところまでやろうと考えて、結局寝る直前までかかってしまうことが頻繁にあった。(中略)ソリューションは簡単だった。「タイムボックス」制だ。例えば、5時になったら仕事が途中でも、どんなに切りが悪くても、すぐに仕事をやめる。いつの間にか時間が過ぎてしまわないよう、5時きっかりにアラームをセットして。

絶対に時間をオーバーすることはないよう、しばらく無理矢理にでも「タイムボックス」で生活してみたらどうなったか？まず、5時に強制終了するようにすると、就業後にランニングできるようになった。頭がすっきりとリフレッシュするのがわかるし、夜に本を読んだり、ギターを弾いたり、ゲームしたりする余裕が生まれた。以前はそうした時間にすごく罪悪感を感じたが、一番イケてる人たちの意見をじることにしたのだ。タイムボックス導入と同時に朝型の生活にシフトして、必ず夜10時には寝るスタイルにしてみた。

すると1週間もしないうちに、というか翌日から頭が冴えて生産性が上がった。正直マジかよ！と思ったが、今までどれだけ働きすぎて頭の切れが鈍くなっていたかを痛感した。運動をしなければ、動物として何かがおかしくなるのも当然だし、深夜まで起きて作業したって、ろくに頭が働いていなかったのだ。人間は週40時間労働が一番生産性が上がるという説もあるし、確かに時間を区切ったほうが合理的だ。

仕事に使える時間を定めることで「たくさん残業して気合いで解決する」みたいな解決方法が第一の選択肢となることを防ぎ、工夫や改善によって生産性を上げることに繋がり持続可能な形で開発生産性を上げる文化に繋がりそうだと思った。

成果が出るならばより少ない時間でその成果が得られる方がいいのはそれはそうなので少し自分なりにアレンジして取り入れたい。具体的には「残業しすぎないように気をつける」くらいのマイルドな感じで取り入れてみようと思う。

ここでの示唆は、業務だけに自分の時間を使ってしまうと

学習によって自分の生産性を向上させることがしずらい
残業前提で成果を出すため再現性が低い

ということだと思う。残業しすぎないことで学習の時間を確保したり、開発プロセスの改善やスコープの調整によってうまく成果を出せるようにできていることが重要なのだと思う。

ときには多少残業をしないと厳しいこともあると思うし個人としても残業を1秒もしたくないというほどでもないのでこういう取り入れ方にしてみようと思った。

まとめ

というわけでマインドセットだけでなく具体的なプラクティスの面でも大いに参考になる内容が多かったのでとても勉強になったので折に触れてまた読み返したい。気になった方はぜひ読んでみてください。

ThePrimeagen/harpoon を使ってみた

Fri, 17 Nov 2023 15:20:13 +0000

ThePrimeagen/harpoonというNeovimプラグインを使ってみたので気になっている人の参考になればと思い感想を書いてみる。

できること

ファイルをマークしてquick_menu(マークしたファイルの一覧)からファイルを開くことができる。操作している様子は以下の通り。

1. ファイルをマークして

:lua require("harpoon.mark").add_file()を実行してファイルをマーク

2. quick_menuからファイルを開く

:lua require("harpoon.ui").toggle_quick_menu()を実行してマークしたファイル一覧からファイルを開く

機能は他にもありそう¹だが筆者はこの機能しか使ってないので割愛。

嬉しさ

個人開発などファイル数が少ないプロジェクトだとそこまで効果を感じないが業務では(当然だが)一定数のファイルがあり、かつ定義ジャンプを繰り返しているとバッファにはたくさんファイルが存在しているのでtelescopeなどのfuzzy-finderプラグインを使ったとしてもファイルの行き来には多少時間がかかってしまっていた。

harpoonの導入によってファイルの行き来が爆速になってかなり作業効率が爆上がりした。

推しポイント

1. マークしたファイルが一度エディタを閉じても保持される

LSPが不調だったりしてNeovimを再起動することがたまにあるので地味に便利。

(一度Neovimを閉じてもマークしたファイルが保持されている様子。)

2. 自由に編集できる quick_menu

作者自身もお気に入りと言及しているが²quick_menuは純粋なテキストなので自由に編集できる。

つまりこんな感じでdd -> yのようなコマンドで自由に順番を入れ替えたり削除したりできる。普段のvimの操作感で扱えるのでとても直感的で使いやすくて嬉しい。

quick_menuを自由に編集している様子³

まとめ

気になった方はぜひ試してみてください。

インストール方法はこちら

GitHub - ThePrimeagen/harpoon

Contribute to ThePrimeagen/harpoon development by creating an account on GitHub.

https://github.com/ThePrimeagen/harpoon?tab=readme-ov-file#-installation

余談

そういえばThePrimeagenの好きな動画があるので貼っておく。

- YouTube

Enjoy the videos and music you love, upload original content, and share it all with friends, family, and the world on YouTube.

https://www.youtube.com/watch?v=nMHxdz-N7EU

他にはターミナルを開く機能とかtelescopeやtmuxとの連携機能もある模様 ↩︎
https://github.com/ThePrimeagen/harpoon/issues/205#issuecomment-1241921113 ↩︎
ちなみにdemoで使っているcolorschemeはcatppuccin-mocha ↩︎

『採用基準地頭より論理的思考力より大切なもの』を読んだ

Sun, 22 Oct 2023 11:00:41 +0000

概要

McKinsey & Company出身の伊賀泰代さんがリーダーシップについて書いた『採用基準地頭より論理的思考力より大切なもの』を読んだ。ちょうど「リーダーシップとは」みたいなことが気になっていたので読んでみた。

コンサルティングファームでの出来事を中心に書かれているが、ITベンチャーでエンジニアとして働く自分にも参考になる点が多かったように思う。

学び

思考力とは

思考力とは以下の3つの要素からなる。

思考スキル
思考意欲
思考体力

このうち思考スキルはトレーニングなどで向上させることができるが、思考意欲と思考体力は一朝一夕で身につけることが難しいため筆者は面接時によく見ているらしい。

この部分を読むまで思考力といえば思考スキルや思考体力が主だと思っていたので思考意欲という概念は自分には目新しかった。

リーダーシップが全員に必要な理由

多くの欧米企業が社員全員にリーダーシップを求める理由が書かれていたので引用する。

マッキンゼーをはじめとする外資系企業の多くでは、すべての社員に高いレベルのリーダーシップを求めます。アメリカの場合は、大学や大学院の入学判定に使われる小論文でも、過去のリーダーシップ体験は常に問われる最重要項目です。(中略)全員がリーダーシップをもつ組織は、一部の人だけがリーダーシップをもつ組織より、圧倒的に高い成果を出しやすいのです。だから学校も企業も、欧米では（もしくは外資系企業では）全員にリーダーシップ体験を求めるのです。(中略)リーダーシップのある人は、「成果を出すこと」を「自説が採用されること」よりも優先します。

「全員がリーダーシップを持つ組織」と聞くと「全員自分の意見ばかり主張していては物事が前に進まないのでは…?」と考えてしまいがちだが、ここではリーダーシップを「チームの使命を達成するために、必要なことをやる人」と定義している。

たしかにそう聞くと多角的な視点からよりよい意思決定ができそうな気がしてくる。チーム・組織の全員がリーダーシップを体現できれば指示待ちが起こらず、生産性が高まりそうだなと感じた。

バリューを出す

まずは自分自身が期待されている(あるいは期待以上の)バリューを出すことでリーダーが最もこだわるべき成果の重要性を理解したりやそれにこだわる姿勢を身につけることができる。

ポジションをとる

自分はどう思うのか。情報を揃えて周りに判断を仰いでばかりではいつまでも指示待ち人間を脱することはできない。

自分の仕事のリーダーは自分

組織図を考える時に上司が上、メンバーが下というように考えるよりは自分を中心に捉えてその周りに他のメンバーや上司やその上司などが放射状に位置していると考える。
上司に決めて貰えばいいと考えるのではなく周りの人をどううまく使って自分の仕事を進めるかを考えることが大切。

まとめ

組織の全員がリーダーシップを体現することの嬉しさを知れたのが自分にとっては大きな収穫だった。

成果を意識してやっていく。

GitHubで自分がOSSに送ったPR一覧を表示するやつ

Sun, 22 Oct 2023 10:26:39 +0000

稀に自分がOSSに送ったPR一覧を見たくなるのでメモ代わりに書く。 (正確には「自分所有でないpublic repositoryに送ってマージされたPR一覧」を表示する方法)

tl;dr

https://github.com/pulls でクエリに


is:pr archived:false is:closed author:@me is:public -user:@me created:2024-01-01..2024-12-31

を指定して検索するとこんな感じで表示される。

余談

orgを所属組織とかに絞って検索すれば仕事の振り返りとかにも使えそう。
他にも https://github.com/pulls/review-requested にいくと自分がレビュワーとしてアサインされているPR一覧が見れて便利だったりする。ターミナル上で同じようなことをやりたい人は dlvhdr/gh-dash とかもオススメかもしれない。

go/src/cmdでLSPが動作するようにするメモ

Mon, 11 Sep 2023 15:12:17 +0000

gc(go compiler)のコード（具体的にはgo/src/cmd/compile配下）を読むために必要な手順があったのでメモ代わりに書いておく。neovimでしか確認していないが他のエディタでもきっと同じような感じなはず。

`packages.Load error: err: exit status 2: stderr: panic: runtime error: index out of range [-1] goroutine 1 [running]: cmd/go/internal/list.collectDepsErrors...`

というエラーを出力してLSPが停止する。go1.21.0のバグだった模様。

cmd/go: panic: runtime error: index out of range [-1] in collectDepsErrors · Issue #61816 · golang/go

https://github.com/golang/go/issues/61816

ローカルのgoをgo1.21.1に上げることでエラーが解決した。

`Error loading workspace folders (expected 1, got 0) failed to load view for file:///path/to/repo/go/src/cmd: err: exit status 1: stderr: go: downloading go1.22 (darwin/arm64) go: download go1.22 for darwin/arm64: toolchain not available`

src/cmd/go.mod の go 1.22をgo 1.21.0に書き換えることで解決した。

diff --git a/src/cmd/go.mod b/src/cmd/go.mod
index 1eaad916ff..da12b2adff 100644
--- a/src/cmd/go.mod
+++ b/src/cmd/go.mod
@@ -1,6 +1,6 @@
 module cmd

-go 1.22
+go 1.21.0

 require (
  github.com/google/pprof v0.0.0-20230811205829-9131a7e9cc17

`This file is within module ".", which is not included in your workspace. To fix this problem, you can add a go.work file that uses this directory. See the documentation for more information on setting up your workspace: https://github.com/golang/tools/blob/master/gopls/doc/workspace.md.`

リンク先のドキュメントの手順に従ってgo.workを作成する。

// src/cmd ディレクトリで
go work init
go work use ./compile

ということで

無事LSPを動作させることができた。

これでgo本体のコードがサクサク読めるぞー。

GitHub Sponsorsを通してNeovimに寄付をした

Thu, 10 Aug 2023 16:35:48 +0000

Neovimに対してGitHub Sponsorsを通してOne-time¹の寄付をしたという話。

Neovimには仕事・趣味のプロジェクトなど自分が行うすべての開発に収まらずちょっとしたタスク管理やブログ執筆などあらゆる場面でとにかくお世話になっている。

なんでもカスタマイズしたくなってしまうこだわりの強い自分には非常にあっていて数多のプラグインを使って快適に開発を行っている。

大変お世話になっているOSSプロジェクトなのでいつかPRで貢献したいな〜と思いつつ何の気なしにNeovimのリポジトリを眺めていたら「そういえばGitHub Sponsorsでの金銭的な支援も立派なcontributionじゃん！」と思ったのでとりあえず寄付することにした。

案外あっさりできた

今回はひとまずOne-timeで20$だけ寄付してみることにした。

初めてGitHub Sponsorsを使ってみたが必要なのは

請求先住所の入力
クレジットカード情報の入力

くらいだったので5分もかからずにできた。

手続きが完了するとこんな感じでSponsorsに自分のアイコンが表示される。(嬉しい)

さらには自分のプロフィール画面にNeovimのアイコンが表示される。組織の一員感がでて地味にいいですねこれ。(結構嬉しい)

日頃から「OSSにお世話になっている分コードを書いて恩返ししたい…。けどなかなかすぐに解決できそうなissueも見当たらない²」みたいなことを思っていたのでまずは寄付という形でOSSに貢献できてよかった。

今後はPRでもOSSコミュニティに貢献していくぞという気持ちになった。

と思っていた矢先

個人開発のプロジェクトで使えそうなGitHub Actionsを物色していたところ早速自分でも修正できそうな箇所があったのでOSSに初めてPRを送ってみた。

(docs): use environment files instead of set-output by kyu08 · Pull Request #57 · mislav/bump-homebrew-formula-action

Thanks for creating a great workflow! What this PR changes This PR changes usage example in the README.md to use environment files instead of set-output because set-output is deprecated. close #56 ...

https://github.com/mislav/bump-homebrew-formula-action/pull/57

その時の記事はこちら。 OSSに初めてPRを送ってマージされた話

今後

Neovimの話に戻るが冷静にもし自分がJetBrainsのIDEユーザーだったら毎年ライセンスを購入するのは厭わないだろうにNeovimを使い倒させてもらっている自分が今回のOne-timeの寄付だけじゃ全然足りなくね？という気持ちになった。

なのでこれからはJetBrainsのライセンスと同じくらいの額(10$/monthくらい？)はmonthlyで寄付していこうと思う。

いずれはPRでもNeovimに貢献していきたいが、直近のPRを軽くみた感じluaやCが書けた方がよさそうだった。

自分が今一番書ける言語はGoなので何かGoを使ったOSSに貢献できないかな〜と思っていたところ自分がよく使っているTUIのgit clientであるLazygit³がGo製でかつドキュメントも整っていた⁴のでまずはコードリーディングからチャレンジしてみようと思う。

定期的な寄付ではなく、一度きりの寄付 ↩︎
一時期Good First Issueを漁りまくったりしてみたが、typo修正やUT追加などの一部を除いてはプロジェクトについての理解が浅い状態で貢献できそうなissueはあまり見当たらなかった。やはり全体のアーキテクチャや実際の動作を理解した上でなんらかのissueに取り組むのがいいんだろうなと思ったので腰を据えて特定のプロジェクトへのcontributionを狙っていこうと考えを改めた。 ↩︎
GitHub - jesseduffield/lazygit: simple terminal UI for git commands
simple terminal UI for git commands. Contribute to jesseduffield/lazygit development by creating an account on GitHub.
https://github.com/jesseduffield/lazygit

↩︎
CONTRIBUTING.mdのようなドキュメントが整備されているだけでなく、authorのjesseさんが実際にLazygitに機能を追加する様子を収めた動画も公開されていたりと貢献に対してかなりオープンな印象 ↩︎

OSSに初めてPRを送ってマージされた話

Thu, 10 Aug 2023 16:32:27 +0000

個人開発のプロジェクトで使えそうなGitHub Actionsを物色していたところちょうど自分でも修正できそうな箇所があったのでPRを送ってみたところ無事にマージしてもらうことができた。

実際にマージされたPRはこちら。

(docs): use environment files instead of set-output by kyu08 · Pull Request #57 · mislav/bump-homebrew-formula-action

https://github.com/mislav/bump-homebrew-formula-action/pull/57

PRの作成

修正内容としては非推奨となったset-output¹をenvironment filesに置き換えるという簡単なもの。ちょうど業務で同様の修正を行っていたので特に詰まることなく修正できた。

修正内容はたった1行だったが、非同期だし時差もあるしでコミュニケーションの往復が増えることはお互い避けたいはずなのでできるだけ一発でマージしてもらえるように丁寧に背景や動作確認のログを書いた。(自分としても早くマージしてもらえた方が嬉しいし)

若干ソワソワしながら過ごしていると

PRを送った1日後には見事マージしてもらえた。念願の初OSS contribution！やったね！

2.2kものrepositoryで使われてるworkflowのcontributorsに自分のアイコンが載るのは結構嬉しい。(自分のプロジェクト²でも利用し始めたタイミングだったのでちゃっかりUsed byにもアイコンが載っているｗ)

commit logに載っている様子。嬉しい。

ということで

これからもOSSコミュニティへの貢献やっていくぞ〜！

Goの静的解析に入門した

Mon, 17 Jul 2023 05:21:29 +0000

tenntenn Conference 2023 にスポンサーし、Goの静的解析を完全に理解した話を読んでから静的解析が気になっていたのでこれをやってみた。

静的解析をはじめよう - Gopherをさがせ！

以下のようなソースコードからGopher型を探し出す簡単な解析スクリプトを通してGoでの静的解析の流れやASTの探索方法、型チェックを用いたより詳細な解析方法などを学べた。

package main

import (
        "fmt"
)

type Gopher struct { // ここ
        Gopher string `json:"gopher"`
}

func main() {
        const gopher = "GOPHER"
        gogopher := GOPHER()
        gogopher.Gopher = gopher
        fmt.Println(gogopher)
}

func GOPHER() (gopher *Gopher) { // ここ
        gopher = &Gopher{Gopher: "gopher"} // ここ
        return
}

https://golangtokyo.github.io/codelab/find-gophers/?index=codelab#2 より

解説がかなり丁寧でわかりやすかったので静的解析初心者にはかなりありがたかった。

静的解析を使えば単なるgrepではできないことができるイメージが実際に掴めたので早速linterを作ってみようと思う。

『ちょうぜつソフトウェア設計入門 PHPで理解するオブジェクト指向の活用』を読んだ

Sat, 15 Jul 2023 15:00:00 +0000

田中ひさてるさんの『ちょうぜつソフトウェア設計入門――PHPで理解するオブジェクト指向の活用』が話題になっていたので読んでみた。

全体を通して平易な日本語で書かれていたのとコード例が豊富だったので理解しやすくてよかった。

以下学びを簡単にまとめていく。

第2章パッケージ原則

より変更に強いパッケージ設計にするために注意すべき点として

パッケージの凝集性を高める
より安定度が高い(=抽象度が高い)パッケージに依存する

などがある。

また、凝集性の低さを表すシグナルとしてそのパッケージが変更される理由が複数あること・1つの変更の際に変更対象となるパッケージが複数あること(それぞれ同じ?)が挙げられる。

「抽象」については以下のように説明されていた。

抽象クラスやインターフェイスなど実装詳細を自身から排除したもの

上記のような詳細を持たないものだけに依存するロジック

固有の業務にも特定技術にも関係しない時刻や配列などの汎用概念とその操作

プログラミング言語そのものや言語標準ライブラリと同等レベルの業界標準

第3章オブジェクト指向

いい抽象を見つけるには

具体的な例を分析してそれらから抽象を見つけることで期待値の高い抽象を発見できる。

逆に先にひとりよがりの哲学をこねくり回して現実をかえりみない抽象化を先行させた場合は、役に立たない概念に縛られる無駄が起きやすくなる。（ペットショップのシステムなのに「Catには野良猫もいるかもしれない。必ずしもPetではないかも……」みたいなことを考えてしまうのは明らかに無駄）（抽象化においてもYAGNIが重要っぽい）

無限の可能性に向かって発散してしまわず、いかに可能性を削ぎ落として最小サイズで実際に起こりうるバリエーションをカバーできるかが汎化のポイント。

そういう意味でもドメインやビジネスの状況を理解しておくことはプロダクトの将来を考慮しながら設計するために必要なんだろうなと思った。

「多」態性がなくても役立つ

抽象と具象は必ずしも1対多の関係である必要はない。

具象と抽象に分けておくことで先に大枠を安定させることができるため、設計の見通しがつきやすくなる。

また、具象の数が複数になったときに対応しやすいというメリットもある。

これまで「抽象と具象が1対1対応なケースはわざわざDIする必要はないのでは」と思っていたが上記のメリットがあるので積極的にDIしていこうと思った。

第5章オブジェクト指向原則 SOLID

5-2 単一責任原則(Single Responsibility Principle(SRP))

クラスと責務は1対1対応すべき、という指針。

単一の責務のみつけかた

クラスの利用者がどんなときに別のクラスや新しいバージョンに交換したいと思うかを想像する。

実際に起こりそうな交換要求への想像が責務(= クラスのカバー範囲)を見極めるヒントになる。

たとえば記事クラスが存在し記事の入稿および購読というユースケースがある例では以下のように考えることができる。

ニュース記事を書く人の事情が変わったけれど、購読ユーザーには従来どおりのサービスを提供したい。逆に、入稿はそのまま、購読ユーザーへのサービスを拡張したい。そんなニーズが起きるのは容易に想像できます。入稿と購読のそれぞれを互いに影響を与えない独立したクラスとしておき、いつでも気兼ねなく別の実装に交換できる単位としておく方が、後で便利に決まっています。なので、ニュース記事管理の場合は、「入稿」と「購読」が、それぞれひとつの責務になります。

5-3 開放閉鎖原則(Open Close Principle)

拡張に対してオープン、変更にたいしてクローズドであるべき、という指針。

これは書籍内で紹介されていたコード例がわかりやすかった。

あとはどこが変化する仕様なのかを考えるために一度要件を抽象化してみる方法が紹介されていた。こちらもコード例が示されていたのでイメージが湧きやすかった。

第7章依存性注入

オブジェクトが使う機能の実体を得る際その解決を自力で行わず、常に外部から与えるようにすべき、という設計方針。

依存性注入を行うメリットの1つは生成の責務と使用の責務を分けられる点がある。

また、テスト容易性とDIについては以下のような記述があった。

単体テストしやすいクラスであることと、DI可能なクラスであるということには、正の相関があります。DIを単に「単体テストのためにやること」といった目的観で考えるのは視野狭窄ではあるのですが、単体テストがアーキテクチャへの気づきの手段として、とても有用なのは間違いありません。

テストが書きずらかったら設計を疑ってみるのも1つの手かもしれない。

まとめ

よく聞くSOLID原則もやっとちゃんと理解できたし依存性注入に対する理解も深まったので今後に活かしていきたい。

NuPhy Air60を買った

Sun, 11 Jun 2023 14:27:54 +0000

NuPhy Air60を買ったので簡単にレビューする

買った理由

普段は7sProを使っているが出社のときに持っていくのが大変だったり尊師スタイルで作業したりしずらかったりするので出社用・家での尊師スタイル用にキーボードを探していた。

コンパクトなキーボードが好みなので60%で探したいたところNuPhy Air60を見つけ、社の先輩がAir75を使っていたので少し触らせてもらったところ打鍵感がいい感じだったので購入を決めた。

NuPhy Air60のいいところ

(macのキーボードと比べて)打ちやすい

macの付属キーボードのような薄いタイプよりもメカニカルキーボードなどのようなキーストロークが深めなキーボードが好きなので(ロープロファイルとはいえ)比較的打ちやすい。

打鍵感 & 打鍵音がいい

コトコト系で心地よい感じ。以前Keychron K6を一瞬だけ使っていたときは底打ち感があって指が痛くなりやすかったがそういうことも現状ない。

打鍵音はオフィスで何も気にせず使える程度には静か。

デザインがかわいい

かわいい

コンパクト

60%なのでそれはそうという感じだがコンパクトで使いやすい。(65%のキーボードは一番右の列を間違って押してしまいがちなのでつらい)

ちなみに持ち歩く際はバード電子から発売されている HHKBスマートケース2 に入れて持ち運んでいる。ぴったりフィットしている。

気になったポイント

唯一惜しいと思ったのはキーキャップがフラットで傾斜がついてないこと（軽く調べた感じロープロファイルだと傾斜がついてないのがスタンダードっぽいのでNuPhy Air60特有の微妙なところかと言われると微妙ではある）

普段はスカルプチャードなキーキャップ¹を7sProに装着して使っているのでなかなか慣れない & 若干手が疲れる。(とはいえmacのキーボードよりははるかに打ちやすい)

まとめ

NuPhy Air60は打鍵感がよく持ち運びもしやすくてとても気に入っている。

あとは家で作業しているときもキーボードを変えると気分転換になることを発見したのでときどき意味もなくキーボードを入れ替えてみている。

NuPhyが気になった方は方はこちらのリンクを踏むと10%オフのクーポンが発行されるみたいなのでぜひ。(2023/6/18まで有効)

I can get you a discount at NUPHY®

Hey, if you're ever looking for NUPHY® products, let me know and I can get you a discount at NUPHY®. Here's a coupon if you need one now:

http://nuphy.refr.cc/kyusubsub

列によって傾斜や高さが異なるキーキャップのこと。キーキャップの形状についてはこちらの記事が大変詳しい https://buildersbox.corp-sansan.com/entry/2019/08/16/110000 ↩︎

GitHub Pagesでデプロイのたびにカスタムドメインの設定が消える問題の解決方法

Sat, 10 Jun 2023 14:14:42 +0000

困っていたこと

GitHub Actions経由でGitHub Pagesにデプロイするたびにカスタムドメインの設定が消えてしまい、デプロイ先がカスタムドメインからhttps://<username>.github.io/<repository>に戻ってしまう

解決方法

ドキュメントにある通り、cnameオプションを追加する必要があった。

name: deploy

on:
  push:
    branches:
      - main

jobs:
  deploy:
    runs-on: ubuntu-22.04
    steps:
      - uses: actions/checkout@v2
        with:
          submodules: true
          fetch-depth: 0

      - name: Setup Hugo
        uses: peaceiris/actions-hugo@v2
        with:
          hugo-version: "0.112.5"
          extended: true

      - name: Build
        run: hugo

      - name: Deploy
        uses: peaceiris/actions-gh-pages@v3
        with:
          github_token: ${{ secrets.GITHUB_TOKEN }}
          publish_dir: ./public
          # これが抜けていた
          cname: blog.kyu08.com

まとめ

ドキュメントちゃんと読むの大事

hugo-theme-terminal でOGPに任意の画像を設定する方法

Fri, 09 Jun 2023 17:02:33 +0000

hugo-theme-terminal でOGPの設定に少し詰まったのでやったことを書いておく。

前提

hugo version: hugo v0.112.5+extended darwin/arm64

困り

筆者はカバー画像を記事一覧・記事詳細画面に表示したくない、かつOGPは全共通の画像を使いたい
hugo-theme-terminalでは任意の画像をOGPだけに設定できない。（カバー画像をOGPとすることはできる）

やったこと

多少ハッキーな方法ではあるが以下の方法で実現した。

各記事のFront Matterにcover: "${OGP_URL}"指定(archetypesにテンプレートとして書いておくと便利)
以下のCSSを追加

.post-cover {
  display: none;
}

ブログ用にGifでキャプチャを作る時にやっていること

Fri, 09 Jun 2023 16:26:52 +0000

ブログ用によくGifをつくるので自分用の備忘録代わりに手順を記しておく。

追記(2023/11/29)

下記の方法だと生成後のgifに格子模様のようなものが入ってしまうので以下の記事で紹介されているffmpegを使った方法を使うようにしたところ綺麗なgifが生成できるようになった。

Mac で GIF 画像を作る技術 - Qiita

動画内で使用している色を最適化するために、パレット画像を生成します。
ffmpeg -i input.mov -vf "palettegen" -y palette.png
GIF 画像を出力します。サンプルでは、-r オプションでフレームレートを 24 に設定しています。
ffmpeg -i input.mov -i palette.png -r 24 -y output.gif

追記ここまで

前提

macOS
Kapがインストールされていること
Keycastrがインストールされていること

手順

1. Keycastrを起動

2. Kapでいい感じに範囲を選んで録画開始ボタンを押す

3. いい感じのサイズで保存(重要)

(あとから圧縮しようとすると思いのほか大変なのでサイズを小さくしたい場合はいい感じのサイズにするのを忘れない)

おわりに

(いざ書いてみると書くほどでもなかった)

このブログをhugoで作り直した

Wed, 07 Jun 2023 13:25:41 +0000

もともとこのブログはNext.js + Vercelの構成で作られていたが色々と辛くなってしまったのでお手軽にブログが作れそうなhugo + GitHub Pagesの構成に移行した。

動機

もともとNext.jsを触ってみたかったのでNext.jsで書いたでブログを運営していた。

このときのディレクトリ構成が以下のような感じになっていて、画像はrepositoryにアップロードして(PRのコメント欄とかに画像を貼って取得したhttps://user-images.githubusercontent.com/xxxxxのようなURLを使って)それをマークダウンから呼び出していた。

root/
  ├ posts/
  │　├ post1.md
  │　├ post2.md
  │　└ post3.md
  └ ...

ところがGitHubのrepositoryにアップした画像まわりの仕様が変わり¹、それ以降private repositoryにアップした画像は認証付きになったため画像のホスト方法の変更が必要になった。

そこで管理のしやすさから以下のようにマークダウンと同一ディレクトリに画像を配置する方法にすることにした。

root/
  ├ posts/
  │  ├ post1.md/
  │  │  ├ index.md
  │  │  └ image.png
  │  ├ post2.md/
  │  │  ├ index.md
  │  │  └ image.png
  │  └ post3.md/
  │     ├ index.md
  │     └ image.png
  └ ...

で、それをやろうとしたがどうにもうまく画像を読み込むことができなかった。(当然悪いのはNext.jsではなく1000億%自分の技術力のNASAです)

ちゃんとNext.js(やJSのツールチェイン周り)のお勉強をすればNextでもできたと思うが当面JS関連の技術を触る予定もないしブログの管理にそこまで時間をかけたい気持ちもなかったので諦めてhugoに移行することにした。

やったこと

テーマ選定(panr/hugo-theme-terminalを選択した)
フォントなどスタイルの調整
ファビコンの設定
デプロイの自動化
カスタムドメインの設定
GA4導入

以下部分的に補足する。

デプロイの自動化

以下のようなyamlを.github/workflows/deploy.yamlとして配置するとmainへのpush時に自動でデプロイが行われる。

カスタムドメインに指定したい場合はcnameを指定しないとデプロイのたびにカスタムドメインが404になってしまうので注意。

name: deploy

on:
  push:
    branches:
      - main

jobs:
  deploy:
    runs-on: ubuntu-latest # サポートされていないバージョンを指定するとGitHub Actionsがずっとrunningになるので注意
    steps:
      - uses: actions/checkout@v2
        with:
          submodules: true
          fetch-depth: 0

      - name: Setup Hugo
        uses: peaceiris/actions-hugo@v2
        with:
          hugo-version: "0.112.5"
          extended: true

      - name: Build
        run: hugo

      - name: Deploy
        uses: peaceiris/actions-gh-pages@v3
        with:
          github_token: ${{ secrets.GITHUB_TOKEN }}
          publish_dir: ./public
          cname: blog.kyu08.com # カスタムドメインの設定をしていない場合は不要

GA4の導入

こちらの記事を参考に進めたらできた。

1点だけ注意が必要なのはpartialsの扱いがthemeによって異なる(っぽい)こと。

panr/hugo-theme-terminalでは

<!--
To add an extended head section, please create
`layouts/partials/extended_head.html` in your Hugo directory.
-->

とのことだった²のでlayouts/partials/extended_head.htmlにタグの設定を記述した。

着手 ~ 公開まででかかった時間

たぶん6hくらい。

数箇所詰まったがドキュメントや先人のブログのおかげですぐに解決できた。

おそらくミニマムな状態(カスタムドメイン設定なし, テーマのデザインをそのまま利用, GA4なしなどなど)なら1hもかからずに公開までできると思う。

hugoのいいところ

既存のテーマを利用すると手軽に色々できる(TOC, シンタックスハイライト, 脚注などなど)。とにかくお手軽なのが最高。基本的にはテーマを選んで記事を書いてデプロイすればブログが公開できてしまうのですごい。
ドキュメント・themeのソースコードを読めば大抵解決する
watchオプションがあるのでhugo serve -wを実行するとホットリロードが有効になるので捗る

ハマったところ

~~長くなりそうなので別途記事にする予定~~

それぞれ記事にした。

実際の運用はこんな感じ

記事作成用のブランチを作成
記事を作成
PRを作成してmainにマージ
GitHub Actionsでビルド・デプロイが走る

2.記事を作成だけ軽く補足すると、Makefileに以下のようなターゲットを定義したので

.PHONY: new
new:
	@read -p "post id: " id; \
	hugo new "posts/$${id}/index.md"

こんな感じで動く。地味に楽。

ちなみにデプロイは1分くらいで完了するのでサクサク反映できて嬉しい。

おわりに

色々追加したい機能はあるけどとりあえず最低限の機能はできたのでヨシ！とする。

ブログたくさん書くぞ〜

感想はtwitterとかで呟いたりリプしてくれたりすると跳んで喜びます。

About Me

Tue, 06 Jun 2023 01:15:48 +0900

Go Elm TypeScript Neovim tmux Rust CLIが好きな6年目ソフトウェアエンジニアです。ご連絡はTwitterまで。

site	account
GitHub	kyu08
Twitter	@kyu08_
Bluesky	@kyu08.bsky.social
misskey	@kyu08

ブログの誤字や誤情報についてはこのブログのリポジトリでも受け付けています。

Makefileに定義されたtargetをfzfで選択して実行するCLIツールをRustでつくった

Fri, 31 Mar 2023 01:15:48 +0900

(2024/12/14追記) 内容を更新した紹介記事をZennに投稿しました。

[make,pnpm,yarnに対応]タスクランナーのコマンドをfuzzy finder形式で選択できるCLIツール fzf-makeの紹介

Makefileに定義されたtargetをfzfで選択して実行するCLIツールをRustでつくった。

GitHub - kyu08/fzf-make: A command line tool that executes commands using fuzzy finder with preview window for make, npm, pnpm, yarn, just and task.

A command line tool that executes commands using fuzzy finder with preview window for make, npm, pnpm, yarn, just and task. - kyu08/fzf-make

https://github.com/kyu08/fzf-make

こんな感じで動く。

fzf-makeがやっていること

Makefileからtargetを正規表現で抜き出す
skim(※)に実行オプションとtargetたちを渡す
skimがプレビューウィンドウ付きのfuzzy-finderを表示
skimから選択されたtargetが返ってくるのでmake ${target}を実行

基本的な動作はすべてskim任せになっていてRust側でやっているのはskimとのやりとりくらいになっている。

※lotabout/skim…Rust製のfuzzy-finder。Rustのライブラリとして利用することもできる。

(makeの文法が思ったより多彩っぽかったので自分が必要とするごく簡単なユースケース以外をカバーするのは早々に諦めた。(makeで1冊本が書けるぐらいだしそれはそうという感じではある))

brewコマンドでインストールできるので気になる方はぜひ。

brew tap kyu08/tap
brew install kyu08/tap/fzf-make

ソースも公開しているので、「こう書くといいよ」とかバグとかありましたらぜひissueやPRで教えてください。

GitHub - kyu08/fzf-make: A command line tool that executes commands using fuzzy finder with preview window for make, npm, pnpm, yarn, just and task.

A command line tool that executes commands using fuzzy finder with preview window for make, npm, pnpm, yarn, just and task. - kyu08/fzf-make

https://github.com/kyu08/fzf-make

実装

上述の通り処理の大部分はskim任せになっている。(書いたコードはテストを含めても200行程度)

ただskimをライブラリとして利用する実装サンプルがあまりなかったのがちょっと大変だった。特にプレビューウィンドウの表示にfzfの候補文字列を変数としたシェルコマンドの形で渡すことができることに気づくまでに時間がかかった

↓の{}にtarget名が入るイメージ。

let preview_command = r"line=$(bat Makefile | grep -nE '^{}\s*:' | sed -e 's/:.*//g'); bat --style=numbers --color=always --line-range $line: --highlight-line $line Makefile";

fzf-make/src/misc.rs at 3a627d0a1aa75b1bf1ff87f3443f63393afbcf10 · kyu08/fzf-make

A command line tool that executes commands using fuzzy finder with preview window for make, npm, pnpm, yarn, just and task. - kyu08/fzf-make

https://github.com/kyu08/fzf-make/blob/3a627d0a1aa75b1bf1ff87f3443f63393afbcf10/src/misc.rs#L18

あとはgoでいつもやっている感じでテーブル駆動テストっぽくテストを書いてみた。可読性も保守性も高いので割と気に入っている。

fzf-make/src/misc.rs at 3a627d0a1aa75b1bf1ff87f3443f63393afbcf10 · kyu08/fzf-make

A command line tool that executes commands using fuzzy finder with preview window for make, npm, pnpm, yarn, just and task. - kyu08/fzf-make

https://github.com/kyu08/fzf-make/blob/3a627d0a1aa75b1bf1ff87f3443f63393afbcf10/src/misc.rs#L145

動機

Rustが書きたかった。(以上)

最近Rustのやっていきが高まっており、The Rust Programming Language を1周したので何か作ってみるぞーという機運とMakefileのターゲットをfuzzy-finderで絞り込めたら便利そうだなーという気持ちが重なったのでRustでfzf-makeを作ってみた。 (あとはskimの存在を知っていたのも大きい。)

自分が欲しいCLIツールを手に入れつつRustの経験が積めたのでよかった。

ちなみにRustに入門した直接的(?)なきっかけとしてはこのスライドを目にして、「Elmっぽい！楽しそう！」と思ったのが発端だった。Rustに興味を持っている人はぜひ読んでみて欲しい。

満を持して始める Rust

Rustを触ってみて感じたこと

Rustを触る前に持っていた印象は「コンパイルが通りずらく、安全性が高い」「関数型っぽい」という感じだった。

実際に学んでみた印象は次のような感じ。

関数型っぽい書き心地
- 特にenumとパターンマッチング,Option型 ,Result型, 式指向な考え方などの関数型っぽい言語機能や極力データをイミュータブルに扱う思想などが心地よかった。筆者が大好きな言語であるElm(ウェブブラウザベースのGUIを作成するための純粋関数型)の好きな部分をほとんど含んでたのでElmに近い感覚で書くことができた。(もちろん慣れてないこともあってElmよりも全然難しかったけど)
- (Elmが気になる方はElm Guideがおすすめです)
↑に近いがNull安全なことに加えて所有権などの概念のおかげでコンパイルが通りさえすればちゃんと動いてくれるという安心感がある。
- リファクタもやりやすそう。(enumにバリアントを追加したとき、パターンマッチの全箇所を修正しないとコンパイルが通らなかったりすると思うので)
開発体験が良い
- エラーメッセージがとても丁寧。「ここがこう悪いで〜」とか「ここをこう直すとええで〜」みたいなことまでエラーメッセージに書いてくれてあるホスピタリティに感動した。こういったところもRustが生産性が高いと言われる所以なのかもしれない。
コミュニティの初学者をサポートする姿勢がすごい
- RustのOSSプロジェクトへのcontributionについては rust-lang/rustへのcode contributionをはじめからていねいにが詳しいが、Rust製のOSSプロジェクトにはE-mentorというタグがありissueを進めるに当たってメンターが指針を記してくれているらしい。（https://github.com/rust-lang/rust/issues/109099 これとかすごい。）
- いつかRustのOSSプロジェクトにもcontributionしてみたい
他の言語と比べて動くものをつくるまでに必要な学習コストは高いとは思うがRustをちゃんと書けるようになれば生産性高く安全なコードが書けると思うので必ずしも学習コストが高いとは言えないのかもしれない。（他の言語でも安全なコードを書くためには一定の学習や経験が必要だろうし）（※想像で喋っています）

総じて開発体験は良かったのでこれからもゆるゆるとRustの学習は続けていきたい。

余談

テスト実行に https://github.com/nextest-rs/nextest を使ってみたがテスト結果が見やすくて便利だった。

cargo runの結果

cargo nextest runの結果

カラフルで見やすい。

yamlに定義したbookmarkをfzfで選択してブラウザで開くCLIツールをGoで作った

Wed, 22 Feb 2023 16:15:48 +0000

つくったもの

yamlに定義しておいたbookmarkをfzfで選択してブラウザで開くCLIツールをGoで作った。

GitHub - kyu08/fzf-bookmark-opener: A command line tool that opens bookmark using fzf.

A command line tool that opens bookmark using fzf. - kyu08/fzf-bookmark-opener

https://github.com/kyu08/fzf-bookmark-opener

こんな感じで動く。

コードの話

コード自体は大変シンプルで

設定ファイルがなければ~/.config/fzf-bookmark-opener/config.yamlに作成
設定ファイルの読み込み
fzfで選択
選択されたブックマークをブラウザで開く

ということをやっているだけである。(main.goに120行弱だけという素朴なコード量)

fzf-bookmark-opener/main.go at main · kyu08/fzf-bookmark-opener

この記述量で作れたのは間違いなくktr0731/go-fuzzyfinderのおかげでした。このライブラリのおかげでgoのコードからfzfを簡単に呼び出すことができました。というかなんならこのライブラリの存在を知ったので使ってみたくなってfzf-bookmark-openerを作ったみたいなとこもあります。ありがとうございます。

ktr0731/go-fuzzyfinder

ちゃっかりbrewでも公開してみた

brewでインストールできるに越したことはないだろうってことで、brewでも公開してみたが思いのほか簡単だった。

brew tap kyu08/tap
brew install kyu08/tap/fzf-bookmark-opener

これだけでインストールできるので気になった方もそうでない方もぜひ。issueやPRもお待ちしています。(go installでインストールしたい方はこちら(go install github.com/kyu08/fzf-bookmark-opener@latest))

brew公開に関してはこちらのブログを参考にしたら30分弱でサクッと公開できた(想像より簡単だった)

【備忘録】Homebrewで自作ツールを配布する - ハイパーマッスルエンジニア

Homebrewでの配布は簡単だが毎回忘れる Goでバイナリ作ったり、ShellScript書いて配布したいなと思ったときにHomebrew使うことが割とある。が、その都度毎回調べてやり方を思い出しながらするのが億劫だったので、一回まとめてみる。ざっくり手順 Homebrew配布用のリポジトリを作る tagをpushしてReleaseノートを作る Formulaファイルを作ってpush 1. Homebrew配布用のリポジトリを作る自作ツールのインストールファイルを置くためのリポジトリを作る。このリポジトリにバイナリとかの成果物を置くわけではない。置くのはインストールファイルである.rb…

https://www.rasukarusan.com/entry/2019/11/03/211338

詳細は↑の記事を読んでいただければわかるが、リリースにバイナリを含めて配布用のrepositoryを作るだけなので本当に簡単だったのでツールを配布したい人はぜひ。

ちゃっかりヘルパースクリプトも公開した

現在お仕事ではGCPを使っているんですが、GCPのコンソールをプロジェクト、サービスを指定して直接開きたいことが多いのでプロジェクトのリストを渡すとGCPの主要なサービス(主観)のURL一覧をfzf-bookmark-openerの設定ファイルの形式で吐いてくれるスクリプトも公開した。

kyu08/gcp-url-generator

project名のリストとregionを渡すとこういう文字列を吐いてくれるイメージ。(以下は出力の一部)(この例だとregionは関係ない)

  - title: 'Home stg'
    url: 'https://console.cloud.google.com/home/dashboard?project=stg'
  - title: 'Home dev'
    url: 'https://console.cloud.google.com/home/dashboard?project=dev'
  - title: 'Home prod'
    url: 'https://console.cloud.google.com/home/dashboard?project=prod'
  - title: 'Datastore stg'
    url: 'https://console.cloud.google.com/datastore/entities?project=stg'
  - title: 'Datastore dev'
    url: 'https://console.cloud.google.com/datastore/entities?project=dev'
  - title: 'Datastore prod'
    url: 'https://console.cloud.google.com/datastore/entities?project=prod'

現在の対応サービスは以下で、Cloud Runに関してはサービス名の配列を渡すとプロジェクト*サービスの全組み合わせのURLを吐く。

Dashboard
Datastore
App Engine
Artifact Registry
Cloud Storage
Spanner
BigQuery
Cloud Scheduler
PubSub
Dataflow
Cloud Build
Cloud Tasks
Cloud Run
Cloud SQL
Cloud Functions
IAM
Secret Manager
AI Platform
Compute Engine
Logging
Monitoring
Workflows
Firebase Realtime Database (DB)
Firebase Hosting
Firebase Remote Config

これで生成したURLをfzf-bookmark-openerに食わせるとお使いのGCPプロジェクトの特定のサービスがコマンドラインからサクッと開くことができる。(詳しくはkyu08/gcp-url-generatorのREADMEを参照) こちらもissueやPRお待ちしてます。

余談1

Rustだとlotabout/skimを使うとktr0731/go-fuzzyfinderと同じようなことができるらしい。最近Rust熱が高まりに高まっている(Tour of Rustやり中)ので次に何かCLIでfzfなツールをつくるときは使ってみようと思う。

lotabout/skim

[追記] Makefileに定義されたtargetをfzfで選択して実行するCLIツールをRustでつくった。

kyu08/fzf-make

余談2

ふと気になってktr0731/go-fuzzyfinderをはじめとする依存ライブラリのライセンス表示はどうすればいいか気になって調べてみたところリポジトリにNOTICESとかCREDITSとかThirdPartyNoticesみたいなファイルを置いてそこに依存ライブラリの著作権・ライセンス表示をするのが一般的なようだった。

手作業でやるのは辛いので自動生成ツールを探したところGoだとこれが使いやすそうだったので使ってみたけど簡単でとてもよかった。ありがたや…。

GitHub - Songmu/gocredits: creates CREDITS file from LICENSE files of dependencies

creates CREDITS file from LICENSE files of dependencies - Songmu/gocredits

https://github.com/Songmu/gocredits

まとめ

ktr0731/go-fuzzyfinderはいいぞ〜

Tmux+NeovimでJetBrains IDEのScratchみたいな機能を実現している話

Sat, 04 Feb 2023 16:15:48 +0000

任意の構成のSandbox的な環境をTmuxのwindowとして用意するようにしたところターミナルから出ずにサクっと動作検証とかが行えてハッピーになったよ、という記事。ここではvanillaなGoのプロジェクトの例を紹介しますが、お好みの構成でSandbox環境を作ってみてください。

全然大したことをやっているわけではないですがTmux, Neovimやそれらのプラグインの普及活動になれば嬉しいので書いてみます。

動作イメージ

こんな感じでvanillaのGoプロジェクトをTmuxのwindowに開いておいて、確認したくなったときにすぐwindowを切り替えてコードを書いて実行結果を確認できるようにしている。(Gifの例はGoの書式指定子%+vの動作を忘れて試してみているところ)

Gifでやっていることは以下

GoのSandbox環境を開いたNeovimが起動しているwindowに切り替え
コードを書く
Neovim上でターミナルを表示
make runを実行してコード実行
結果を確認
元いたwindowに戻る

tmux-fzfなど筆者のターミナル環境については以下参照

開発の効率化のためにやっていることターミナル編

筆者はGoの動作を確認したいことがほとんどなのでこういった構成にしているが、必要に応じてよく使うFWをセットアップした環境を作っておくと便利そう。

プロジェクトの内容

Go固有の内容もあるので参考程度で。

├── .git
├── .gitignore
├── go.mod
├── go.sum
├── main.go
├── main.go.sample
├── main_test.go
└── Makefile

基本的にmain.goの中身を編集して、go run .で実行して実行結果を確認するということをしている。

Makefileの中身は以下のような感じになっていて、make runでコード実行、make clearでmain.goをまっさらにできるようにしているだけである。

.PHONY: run clear

run:
  @go run .

clear:
  @cp ./main.go.sample ./main.go

main.go.sampleの内容は以下。

package main

func main() {
}

あとはよく見返したくなるコードはmain.go以外のファイル名で保存したり、commitしておくと後からでもさっと確認できてよさそう。(筆者はそこまでやってない)

感想

ターミナルから出ずに作業が完結できてうれしい。

同様のことはGoの場合はブラウザからThe Go Playground(※)を開いても行えるが筆者は何でもターミナルでできると嬉しい人なのでできるようにしてみた。

※ブラウザ上で実行できるGoのエディタ + 実行環境がセットになったやつ。

Go Playground - The Go Programming Language

https://go.dev/play/

あとやるとしたらThe Go PlaygroundにあるURL発行機能とかを実現できると他の人への共有も楽になっていいのかもしれない。(今のところあんまり他の人に共有する機会がないので困っていない)

補足

最後に補足としてGif内で使っているNeovimのプラグインを紹介します。

ターミナル表示

voldikss/vim-floaterm

GoのSandbox環境のmain.goに書いたスクリプトを実行するために、Neovimからターミナルを表示するシーンで使っている。

コード編集してサクっと動作確認したいときなどに便利。(といいつつ最近動作の重さが目立ってきたので<C-z>でNeovimの起動元に戻ってターミナルを操作することが多い)

カーソル移動

yuki-yano/fuzzy-motion.vim

fmt.Printf("u: %v\n", u)のuから%vの位置にカーソル移動する際に使っているプラグイン。

動作のイメージはこんな感じ。

起動すると文字がグレーアウトするのでジャンプしたい文字列を入力するとその文字にジャンプするためのキーワードを表示してくれるというプラグイン。

同様の機能をもつプラグインとしてはeasy-motionなどのプラグインが有名だが、fuzzy-motionはジャンプしたい文字列をfuzzy-finder形式で絞り込んでくれるのが大きな特徴。(詳しくはリポジトリのREADME参照)

筆者はノーマルモードでfキーを押下するとプラグインが起動するように設定している。

カーソル移動の効率がよすぎて正直もうこれなしでは開発したくない。

LSP Server

neoclide/coc.nvim

Language Serverをホストするためのプラグイン。

すごく簡単にいうと補完や関数定義を表示したり定義ジャンプできるようにしたりしてくれる。

以上です。ここまで読んでくれてありがとうございました。

デザインパターンをひととおり眺めた感想

Wed, 01 Feb 2023 16:15:48 +0000

ずっと気になってはいたが2つ~3つくらいしか知らなかったデザインパターンをやっと勉強する気になったのでこのサイトを一通り眺めてみた。

デザインパターン

デザインパターンは、ソフトウェア設計でよく起きる問題に対する典型的な解決方法です。これらは、事前に用意された、問題解決のための設計図で、適宜変更して、自分のコードにおける特定の設計上の問題の解決に使えます。

https://refactoring.guru/ja/design-patterns

こちらのサイトは平易な文章とわかりやすい例で説明がされていて、各言語でのサンプルコードも載せてくれていたのでかなりサクサクと理解できてとてもよかった。(各パターンをC#, C++, Go, Java, php, Python, Ruby, Rust, Swift, TypeScriptで実装した例が紹介されていた)(すごい)

自分のデザインパターンとの向き合い方について

周りのエンジニアにデザインパターンについて聞くと、

すべてのパターンが今も有用かと言われるとそうでもないかも
よくある設計パターンの共通言語として知っておくとコミュニケーションの効率があがってよい
暗記までする必要はなくて設計のときの参考程度にするとよさそう

みたいなことを言っているのをよく聞くのですべてを自分のものにするというよりは軽く雰囲気を理解するくらいのテンションでサイトを眺めてみた。

感想

一通り眺めてみて、以下のようなことが重要なんだろうなと感じた。

interfaceをうまく使って抽象に依存する
データと振る舞いを分離する
依存の方向に気を付ける

いろんなところで言われていることだが、やはり責務の分離や単一責任の法則を意識することで変更しやすいコードにしていくことがよりよい設計に繋がることを再確認できた。

いいコードを書けるようになるにはこれらのことを意識しながら実際にコードを書いて実践していくことが重要だと思うのでたくさん試行錯誤していい感じのコード書き力を身につけていきたい。(とても経験豊富な先輩エンジニアも結局自分でサービスを運用して設計の失敗の痛みを感じるのが一番成長できる、というようなことを言っていた)

設計関連だと良いコード/悪いコードで学ぶ設計入門 ―保守しやすい成長し続けるコードの書き方とか Clean Architecture とかも気になってるので読みたい。

開発の効率化のためにやっていることターミナル編

Wed, 14 Dec 2022 16:15:48 +0000

【この記事はUnipos Advent Calendar 2022の記事です】

この記事では筆者が開発の効率化のために行っている工夫や使っているツールなどについて紹介します。「他にもこんなツールあるよ！」「こんな設定おすすめだよ！」などなどありましたらtwitterとかで教えてもらえると助かります。

今回はターミナル編です！

シェル

シェルはzshを使っています。一時期fishも使っていましたが、環境移行のコストが低かったりPOSIX準拠だったりするメリットに旨味を感じてzshに乗り換えました。

よく使うalias

zshではalias hoge='echo hoge'のように記述することでaliasを定義できます。

ここでは筆者がよく使うaliasをいくつか紹介します。

alias m='MEMODIR=~/code/memo; cd $MEMODIR; FILE=$MEMODIR/$(date +%Y%m%d).md; if [ ! -e $FILE ]; then echo "# todo \n\n# done\n" >> $FILE; fi; nvim $FILE'

日毎にyyyymmdd.md形式の名前のファイルを作成してvimで開く。ファイルが存在していなければ

# todo

# done

をファイルに書き込んだうえでvimで開く、という内容のワンライナーです。

実際に呼び出すとこんな感じです。

ちなみに筆者は

# todo
- タスクA
  - 子タスクa
  - 子タスクb
- タスクB

# done

のような感じでタスクを書いていき、完了したら以下のようにdoneに移すという素朴な方法でタスク管理をしています。

# todo
- タスクB

# done
- タスクA
  - 子タスクa
  - 子タスクb

alias ghw='gh repo view -w'

ghコマンドを利用して現在いるリポジトリをブラウザでGitHubで開くコマンド

alias pbc='pbcopy && pbpaste'

make test | pbcのように出力をパイプでpbcに渡すとクリップボードにコピーしつつ標準出力に出力してくれる。

コマンドの出力をコピーしたいけど出力内容もその場で確認したいときに便利。

こちらの記事で紹介されていた。

pbcopy で標準出力の内容をecho表示を維持しつつコピーしたい - それマグで！

pbcopy コマンドはクリップボードのコピーが出来て便利。 pbcopy コマンドを使うと、ターミナルの出力内容をコピーが出来る。便利なコマンドでも困ったことが有る。クリップボードにコピーされた内容を見れない。 takuya@~$ ls / Applications Network Users bin dev home lost+found net private tmp var Library System Volumes cores etc installer.failurerequests mnt opt sbin usr takuya@~$ ls / | pbcopy コピーされる…

https://takuya-1st.hatenablog.jp/entry/2017/05/30/093000

alias finder='open -a Finder ./'

現在いるディレクトをfinderで開くコマンド

ごく稀に使う。

ディレクトリ移動

zshにはcdrという、移動したことがあるディレクトリを自動的に保持してくれる機能があります。

これをいい感じにファジーファインダーから呼び出すスクリプトを公開して下さっている方がいたのでありがたく使わせてもらっています。

fzfで捗る自作コマンド一覧(zsh) - ハイパーマッスルエンジニア

みんな大好きfzf fzfは結果をインタラクティブに絞り込むだけのコマンドだが、組み合わせ次第でかなり使えるコマンドだ。日本ではpecoの方が有名だが海外ではfzfの方が人気らしい。 github.com 筆者が思うpecoと比較したときのfzfのメリットを述べる。画面クリアがなく目に優しい fuzzy search(曖昧検索)が可能絞り込んだものをパイプつなぎでコマンドを適用でき、結果をpreviewとして画面に表示できるカスタマイズが豊富特にfuzzy searchとpreviewできる点が素晴らしい。またfzfの絞り込み結果の画面サイズを指定できたりとカスタマイズ性が高いのもGO…

https://www.rasukarusan.com/entry/2018/08/14/083000

fzfをインストールした上で以下のスクリプトを.zshrcに記述するとcで呼び出すことができます。

# fzf-cdr 
alias c='fzf-cdr'
function fzf-cdr() {
    target_dir=`cdr -l | sed 's/^[^ ][^ ]*  *//' | fzf`
    target_dir=`echo ${target_dir/\~/$HOME}`
    if [ -n "$target_dir" ]; then
        cd $target_dir
    fi
}

# cdrの設定
autoload -Uz is-at-least
if is-at-least 4.3.11
then
  autoload -Uz chpwd_recent_dirs cdr add-zsh-hook
  add-zsh-hook chpwd chpwd_recent_dirs
  zstyle ':chpwd:*'      recent-dirs-max 500
  zstyle ':chpwd:*'      recent-dirs-default yes
  zstyle ':completion:*' recent-dirs-insert both
fi

# fzfの設定
export FZF_DEFAULT_OPTS='--color=fg+:11 --height 70% --reverse --exit-0 --multi'

これを実際に使うとこんな感じになります。ファジーファインダーを利用して効率的にディレクトリ移動できます。

やっていることは以下です。

.zshrcに定義したfzf-cdrを実行
移動したいディレクトリのパスの一部を入力
候補から移動したいディレクトリを選択する

コマンド履歴検索

実行したコマンドの履歴についてもfzfを使って絞り込みを行うようにしています。

これもスクリプトを公開して下さっている方がいたのでありがたく使わせてもらっています。

fzfを使ってzshのコマンド履歴検索をスマートに

https://techblog.sgr-ksmt.dev/2016/12/10/smart_fzf_history/

以下のスクリプトを.zshrcに記述すると、ctrl + rでコマンド履歴を呼び出すことができます。

function select-history() {
  BUFFER=$(history -n -r 1 | fzf --no-sort +m --query "$LBUFFER" --prompt="History > ")
  CURSOR=$#BUFFER
}
zle -N select-history
bindkey '^r' select-history

Git操作

Git操作のほとんどはGitのTUIクライアントであるLazygitを使っています。

GitHub - jesseduffield/lazygit: simple terminal UI for git commands

simple terminal UI for git commands. Contribute to jesseduffield/lazygit development by creating an account on GitHub.

https://github.com/jesseduffield/lazygit

Lazygitはターミナル上で動作するリッチなGitクライアントでGitに関する大抵のことを行うことができます。(機能が豊富すぎて何ができて何ができないのかを正確に把握できていない)

以下はLazygitを使って変更をaddしてcommitしてpushする例です。

見やすいですし、少ないタイプ数で操作できる点でおすすめです。他にも基本的なブランチ操作はもちろんのこと、git rebase -i相当のこともスピーディーにできるのでよく使っています。

ちなみに筆者はkdheepak/lazygit.nvimというプラグインを使ってNeovim上からLazygitを呼び出しています。

GitHub - kdheepak/lazygit.nvim: Plugin for calling lazygit from within neovim.

Plugin for calling lazygit from within neovim. Contribute to kdheepak/lazygit.nvim development by creating an account on GitHub.

https://github.com/kdheepak/lazygit.nvim

ターミナルエミュレータ

筆者はターミナルエミュレータ(以下ターミナル)としてAlacrittyを使っています。

GitHub - alacritty/alacritty: A cross-platform, OpenGL terminal emulator.

A cross-platform, OpenGL terminal emulator. Contribute to alacritty/alacritty development by creating an account on GitHub.

https://github.com/alacritty/alacritty

筆者は普段開発にNeovimを利用しているのですが、以前からプロジェクトの全文検索に時間がかかってしまう点が気になっていました。動作が高速なターミナルを探していたところRust製のターミナルであるAlacrittyにたどり着きました。

iTerm2からの乗り換えでしたが満足できるだけの速度になりました。ターミナルの速度を早くしたい人にはオススメです。あとは設定をyamlで記述できるのも好みなポイントです。

カラースキームはTokyo Nightを利用しています。

GitHub - zatchheems/tokyo-night-alacritty-theme: A slick dark theme for Alacritty based on the Tokyo Night VS Code theme and ported from the Vim theme of the same name.

A slick dark theme for Alacritty based on the Tokyo Night VS Code theme and ported from the Vim theme of the same name. - zatchheems/tokyo-night-alacritty-theme

https://github.com/zatchheems/tokyo-night-alacritty-theme

Alacrittyにはタブ機能がなくタブ的な機能を実現するためにはtmuxなどのターミナルマルチプレクサを利用する必要があるため筆者はtmuxを利用しています。設定・プラグインなどは後述しますが、tmuxの操作感も好みなので割と満足しています。

他にもRust製のターミナルとしてWarp, Weztermなどがありますが筆者の環境ではWarpはNeovimのcolorschemeの反映がうまくできず、Weztermは画面の再描画まわりの不具合が多少あったため、採用しませんでした。(Warp便利そうだしみやすいので使いたかった)

ターミナルのタブ管理

前述の通りAlacrittyにはタブ機能がないため、tmuxを使ってターミナルのタブ管理を行っています。

GitHub - tmux/tmux: tmux source code

tmux source code. Contribute to tmux/tmux development by creating an account on GitHub.

https://github.com/tmux/tmux

ステータスラインの表示

ステータスラインは比較的シンプルにしていて、

ウィンドウ一覧
現在時刻

を表示するようにしています。

普段の開発ではプロジェクトごとにウィンドウを開き、必要に応じて切り替える運用にしています。

ウィンドウの切り替え

筆者はふだんプロジェクトごとのウィンドウに加えてmemo用のウィンドウ・dotfiles用のウィンドウなども開いており、常時ウィンドウが15前後あります。筆者は簡単なタスク管理もmemo用ウィンドウに立ち上げたNeovim内で行っているため、ウィンドウの切り替えを頻繁に行います。

以前まではウィンドウ切り替えを

prefix + w でウィンドウの一覧を表示
目的のウィンドウの位置を確認
目的のウィンドウまで ctrl + n, ctrl + p で移動
選択する

という手順で行っていましたがウィンドウが増えてくると地味にウィンドウ移動が大変になっていきました。以下は従来のウィンドウ切り替えの様子です。

どうにかもう少し楽にウィンドウ切り替えをできないかと探していたところsainnhe/tmux-fzfに出会いました。

GitHub - sainnhe/tmux-fzf: Use fzf to manage your tmux work environment!

Use fzf to manage your tmux work environment! Contribute to sainnhe/tmux-fzf development by creating an account on GitHub.

https://github.com/sainnhe/tmux-fzf

sainnhe/tmux-fzfはファジーファインダーで効率的にtmuxを操作するためのプラグインです。

詳しくはリポジトリのREADMEに譲りますが、

セッション管理
ウィンドウ管理
ペイン管理
コマンドの検索

などが可能です。

筆者はウィンドウ管理機能の中のウィンドウの切り替え機能を使っています。 sainnhe/tmux-fzfを使うようにしたことでウィンドウ切り替えを

prefix + prefix でtmux-fzfのウィンドウ一覧を表示
目的のウィンドウ名の一部を入力
選択する

という手順でできるようになりました。文字にすると違いが伝わりづらいですが、ファジーファインダーを使ってウィンドウの選択を行うことができるようになったことでキーのタイプ数や切り替えの際の脳の負荷を大幅に減らすことができました。

おわりに

ここまで読んでくださってありがとうございました。

需要がありそうだったら

Neovim編
alfred編
chrome拡張機能編

なども書こうと思います。

『コンサル一年目が学ぶこと』を読んだ

Sat, 25 Dec 2021 16:15:48 +0000

コンサル一年目が学ぶことを読んだ。

何を期待して読んだのか

これまで技術の勉強はしたことがあったが、社会人として普遍的なスキルである

問題解決能力
仕事を円滑に進めるためのコミュニケーションの取り方

あたりをちゃんと学んだことがなく、一度入門書的なものに触れたいと思っていたので読んでみた。

学び

印象に残っているのは以下。

端的に話す
仮説を持って行動する
重要なことに時間を使う
期待値のすり合わせを怠らない
Quick and Dirty

それぞれ簡単に補足していく。

端的に話す(Talk Straight)

聞かれたことに対してストレートに答える。具体的には

端的に喋る
素直に話す

ことが重要。

これは相手の立場に立ってみれば当然で、質問をしたのにその答えがなかなか返ってこないと「結局何がいいたいんだ？」となってしまう。

とは言いつつも、自分自身も自分の思考が整理できていない時は特にだらだらと喋ってしまいがちなので、そういう時はいいチャンスだと思って一旦思考を整理するようにしたい。

仮説を持って行動する

1から10まで調査しきっていては時間が足りない。最低限の調査をして仮説を立てたら、検証 -> 仮説の修正のループを高速で回していくことで限られた時間で精度の高い結論を導くことができる。

仮説思考を身につける第1歩として、仮説を持つクセをつけるためにあらゆる事象に対して「自分はどう思うのか」「なぜそう思うのか」というスタンスを持つことを心がけたい。

重要なことに時間を使う

使える時間は限られているので費用対効果を常に意識して時間の使い方を決める。

仮説思考の話とも繋がるが優先順位を設定して重要な課題から手をつけていきたい。

自分に振ってきたタスクどうしの優先順位だけでなく、もう一段上の視座で自分/自チームが今本当に取り組むべきことは何なのか、という思考を心がけたい。

期待値のすり合わせを怠らない

求められていないことに時間を使っても成果には繋がらない。まずは自分が何を期待されているかを正確に把握することが重要。

自分の認識がズレていて後になって手戻りが発生することが稀によくあるので、タスクを振られた際などにその場で

そのタスクの目的
求められているアウトプット

を明確にするように心がけたい。

Quick and Dirty

3日間かけて100% のアウトプットを出すのではなく、まずは3時間で30% のアウトプットをだすべき。

こまめにアウトプットを行ってフィードバックを得ることができれば間違った方向に進んでしまって時間を浪費する前に軌道修正できる。

まとめ

この本を読んだことの収穫としては、自分の中でぼんやりと課題感としてあった

ただがむしゃらに取り組むのではなく効率よく問題を解決するにはどうすればいいのか

というイシューへの回答の1つである、

重要思考・仮説思考を用いる
Quick and Dirty
期待値のすり合わせを怠らない

という考え方に出会えたことが挙げられると思う。

また、コンサルタントのプロフェッショナリズムに触れて自分も周囲の期待を越え続ける存在でありたいと思った。

おまけ

「仮説思考をやっていこうと思いました」(意訳) という話を上長にしたところ『イシューからはじめよ』をおすすめされたのでこちらも読んでみようと思う。

Elmで固定長配列が扱えるライブラリelm-static-arrayを触ってみた

Thu, 16 Dec 2021 16:15:48 +0000

Elmで固定長配列を扱うためのライブラリelm-static-arrayを触ってみたので感じたことを書いていきます。

elm-static-array とは

elm-static-array はElmで固定長配列を扱うためのライブラリです。

配列の長さを型で表現できることが特徴です。

-- StaticArray
-- 長さ 4 の配列
arrayLength4 : StaticArray Index.Four String

-- 通常の Array
ordinaryArray : Array String

どんな場面で使ったか

趣味で開発している麻雀の点数集計アプリで使いました。

各プレイヤーの試合毎のスコアを記録して合計を表示するだけの簡単なアプリケーションです。(※実際には順位点やトビ賞の計算などもやっていますがここでは割愛)

ここで 参加者の名前 および その試合のスコア を Array String として扱おうとすると以下のようになります。

type alias Players = Array String

type alias Points = Array String

これではあらゆる長さの配列をとることができてしまいますが、仕様上どちらも長さ4もしくは5の配列しかとることはありません。そこでelm-static-arrayを使って配列の長さの情報を型で表現しました。

type Players
    = Players4 (StaticArray Index.Four Player)
    | Players5 (StaticArray Index.Five Player)

type Points
    = Points4 (StaticArray Index.Four Point)
    | Points5 (StaticArray Index.Five Point)

ここからは実際に使ってみて感じたことを書いていきます。

elm-static-array を使うことで得られるメリット

メリット①：仕様を型で表現しやすい

上でも触れましたが、長さが4もしく5の Point の配列はelm-static-arrayを使うと以下のように定義できます。

type Points
    = Points4 (StaticArray Index.Four Point)
    | Points5 (StaticArray Index.Five Point)

elm-static-arrayを使うことで型に配列の長さの情報を持たせることができるため、仕様を型で表現しやすくなりコードの可読性向上に繋がります。

また、それにともなって 仕様上ありえない状態が存在できないコードを書きやすくなるためバグの可能性を減らす ことができます。

たとえば以下の isDefaultRound関数は引数に取った値がデフォルト値かどうかを判定する関数です。

type Round
    = Round4 Round4Value
    | Round5 Round5Value


type alias Round4Value =
    -- 長さが 4 の StaticArray
    { points : StaticArray Index.Four Point
    , seatingOrder : Maybe SeatingOrder
    , tobisho : StaticArray Index.Four Point
    }


type alias Round5Value =
    -- 長さが 5 の StaticArray
    { points : StaticArray Index.Five Point
    , seatingOrder : Maybe SeatingOrder
    , tobisho : StaticArray Index.Five Point
    }

isDefaultRound : Round -> Bool
isDefaultRound round =
    case round of
        Round4 _ ->
            round == initRound4

        Round5 _ ->
            round == initRound5

仕様上 Points の長さは4もしくは5になるのですが、elm-static-arrayを使って書くと isDefaultRound関数のパターンマッチの中では仕様上ありえる値の分岐だけを扱えばいいことがわかると思います。

これをelm-static-arrayを使わずに書いた場合は以下のように仕様上ありえないパターンを扱う必要があります。

isDefaultRound : Round -> Bool
isDefaultRound round =
    case Array.length round.points of
        4 ->
            round == initRound4

        5 ->
            round == initRound5

        _ ->
            False

elm-static-arrayを使うことで仕様上ありえないパターンを扱う必要がなくなりバグの可能性を減らすことができます。

メリット②：配列の要素を取得する際に `Maybe` をハンドリングする必要がない

配列の要素を取得する際も通常のArrayとの違いを感じることができます。

以下は配列の要素を取得する get 関数の型定義です。

-- 通常の配列
get : Int -> Array a -> Maybe a

-- StaticArray
get : Index n -> StaticArray n a -> a

注目すべきは 返り値の型 です。

通常の配列では要素の型が a である配列の要素を取得する際の返り値の型が Maybe a になりますが、 elm-static-arrayでは返り値の型が a になります。これにより Maybe をハンドリングする必要がなくなるためよりシンプルに記述できます。

懸念点

逆に懸念だと感じたのは以下の2つです。

Arrayに定義されているすべての関数が定義されているわけではない
elm-static-arrayの書き方に慣れるまでは時間がかかる

それぞれ補足していきます。

懸念①：Array に定義されているすべての関数が定義されているわけではない

Arrayに生えている関数がStaticArrayには生えてなかったりするので、都度Arrayに変換して処理をした上で再度StaticArrayに変換する、というような工程が必要になる場面がありました。StaticArrayには最小限の関数しか定義されていないので例えば filter や foldl(foldr) などは一度Arrayなどに変換し、処理してから再度StaticArrayに変換しなおす必要がありました。

以下はStaticArrayをArrayに変換してfilterしてStaticArrayに戻すコード例です。

StaticArray.fromList がheadとtailを引数に取るため若干コード量が増えてしまいます。

headの要素を取り出す際にNothingをハンドリングしなければならないのがちょっと億劫ですね。(もちろんコンパイラはStaticArrayから変換されたArrayであることなど知るよしもないので仕方ないのですが)

filterStaticArray : StaticArray Index.Four String -> StaticArray Index.Four String
filterStaticArray staticArray =
    let
        filteredArray =
            staticArray
                |> StaticArray.toArray
                |> Array.filter ((/=) "")

        head =
            Maybe.withDefault "undefined" <|
                Array.get
                    0
                    filteredArray

        tail =
            filteredArray
                |> Array.slice 1 (Array.length filteredArray)
                |> Array.toList
    in
    StaticArray.fromList
        Length.four
        head
        tail

懸念②：StaticArray の書き方に慣れるまでは時間がかかる

たとえばインデックスを指定してStaticArrayの要素を取得するget関数を使おうとドキュメントを見ると、下記のような記述があります。

-- Gets an element of the array. Note that it only possible if the index is in bound. Therefore eliminating Off-by-one errors.
get : Index n -> StaticArray n a -> a

自分のElm力の乏しさのせいではありますがドキュメントに具体的なコード例が示されていないこともあり、動かすまでにそれなりの試行錯誤が必要でした。(当時はGitHubで検索しても引っ掛からずに絶望していましたが、検索の仕方が悪かっただけだということに執筆時に気付きました。) 実際には以下のような使い方をする必要があります。ちゃんと動くコードを書くのに1hくらい費やしてしまいました。

head : Element
head = StaticArray.get (Index.fromModBy Length.four 0) someStaticArray

まとめると、 多少の手間が必要になる ということかなと思います。このあたりがelm-static-arrayの作者が README の中で以下のように言っている所以かなと感じました。

Construction is a bit slower (should be neglectable for most cases).

ただ逆に言えばネガティブに感じたのは上記のそれくらいで、基本的にはメリットの方が大きく感じたためこれからも必要であれば使っていきたいと思っています。

まとめ

Elmで固定長配列を扱うためのライブラリelm-static-arrayを触った感想を書いてみました。

仕様を型で表現しやすくなるという点に魅力を感じたので今後も必要なケースでは積極的に使っていきたいと思います。

また、ひさびさに個人開発をして、なかなか時間が取れずコードの意図や全体像をよく忘れたりするので個人開発においても可読性が高かったり意図の伝わりやすいコードを書くことの重要性が身に染みました。

時間がなかなかとれないからこそ質の高いコードを意識的に書いていきたいなと思います。

自己紹介

Fri, 03 Dec 2021 01:15:48 +0900

今年の2月ごろから下書きを放置していて書いてなかったことに気付いてしまったので書きます。

都内でエンジニアをしています。

Neovim, Elm, TypeScript, 麻雀, ガジェットがすきです。

今月はブログたくさんかくぞ〜〜

おわり

2020年をかんたんに振り返る

Wed, 30 Dec 2020 16:15:48 +0000

このブログを作った動機でもある今年の振り返りを書いていきます。

今年はいろいろ大変な一年でしたが家にいる時間が増えた分たくさんやりたいことができた一年でもありました。

静的型付け言語デビューしたり(TypeScript, Scala)、内定先の選考インターンで課題だと感じた設計関連のインプット・アウトプットをたくさんできたのがよかったです。

あとはいくつか作りたいものをつくれて充実感があってよかったです。では振り返っていきます。

1月~2月

のちに内定先となる第一志望の企業の本選考インターン(の続き)をやっていました。いちおう詳細は伏せますが、メンターの方々に助けていただきながらがんばりました。Slackでやりとりをしていたのですが、年末年始も反応していただきとっても助かりました。

使った技術はReactです。

無事内定は頂けたものの、モデルはどういう基準で定めたの?という質問に対して全然うまく説明できず、設計関連の知識の足りなさを強く感じました。

3月

N予備校の"サーバーサイドプログラミング入門"と"実践サーバーサイドプログラミング"をやりました。

はじめて仮想環境をつかってssh接続しながら開発しました。

動くコードが載ってるだけでなく割と詳しめに背景となる知識を解説してあってかなりわかりやすかったです。自分も書いたコードの背景や実装の根拠をしっかりと語れるようになりたい…。

4月

本選考インターンでつくったWebAppのリファクタリングをしました。あとはTypeScriptの勉強をはじめました。やったことは

あたりです。始めて静的型付けの言語に触れて表現力の豊かさを感じました。わかりやすさと堅牢さが得られそう…、エディタがいろいろ教えてくれるので開発効率も上がりそう…などと感じました。

5月

CLIのtodoアプリをNode.js(TypeScript) でつくった
読みかけだったリーダブルコードをよんだ
Repositoryパターンを実装してみた

CLIのtodoアプリはCLIでTODOを確認したくなったのとTypeScriptで何か作ってみたくなったので作って npm で公開しました。

責務の分離を意識して書いたので今までよりは見通しの良いコードを書けたと思っています。

あとははじめてWebpackの設定を書いて、create-react-app の便利さを感じました。(今までcreate-react-appが何をしてくれているのかわかってなかった…)

6月

6月はたくさん本を読みました。毎日作業を始める前に1時間本を読むスタイルが自分にあっている感じでした。

RubyのOOP本は

単一責任で設計しよう
依存関係をちゃんと管理しよう

みたいなことが書いてあった気がします。依存関係についてあまり意識したことがなかったので新たな観点を獲得できました。

そのあと読んだ現場で役立つ~は"ドメインモデルとは"みたいな話が書いてあって今まで自分の中で整理できてなかったことが言語化してあってとてもスッキリしました。

↑の2冊を読んだ上で成瀬さんのDDD本を読んだのでスムーズに理解できました。我ながら結構いい感じの流れでDDD(の入り)を学んでいけた感じがしています。(あと成瀬さんの本がわかりやすすぎた…。とてもおすすめです！)

7月

Twitterのクローンアプリの設計 & フロントエンドの実装開始
Webを支える技術をよんだ

設計のアウトプットをしたかったんですが特にアプリのアイディアとかもなかったのでTwitterのクローンアプリを作りました。

事前に

要件定義
スケジュール
設計

をしてから開発に入ったので大きな手戻りなく開発できました。と同時になかなかコードを書き始められなくてもどかしく感じました…。

クローンアプリのことについてはまた別の記事で詳しく書きたいと思います。

8月

応用情報の勉強をはじめた
Twitterのクローンアプリのバックエンドの実装

大学・大学院で情報系を学んでいる&学んできた人たちに少しでも追いつきたいと思い応用情報を受けることにしました。(資格がとれるからというより試験があって合否があった方が頑張れるので…)

友達と毎日1時間くらいUdemyの動画をみる形で応用情報の勉強をやっていきました。(動画自体は40時間くらい)

Udemyで試験範囲を一通り学んだあとは、試験前2週間程度で過去問10回分を3周くらいしました。

午前問題はわりとはやくから安定して7割以上とれてたのでよかったんですが午後問題が6割前後しか解けなくてずっと不安でした…。

9月

Scalaの勉強をはじめた

scala-text や tour of scala とかをやりました。

TypeScriptと比較して、型まわりの機能が多かったり(共変、非変のあたりとか)ビルトインのメソッドが多かったりして、学習コストはあるけどちゃんと学んだら堅牢で表現力豊かなコードがかけそうだな〜という印象。

コップ本も買いましたが途中まで読んで積んじゃってます。再開したい。

10月

Evans本をよんだ
Vimに入門したけど2日で心がおれた

Evans本を読みました。成瀬さんのDDD本を読んでから望んだので前半はわりと理解できましたが後半はサッパリでした…。🤔

IntelliJちょっと重いなあ…ということでNeoVimに入門してみましたがPluginがなかなかうまく動かなかったりしてIntelliJでやってることができる状態にするのめっちゃ大変やん…となり挫折しました。

11月

Scala x PlayFrameworkで簡単なAPIサーバをつくった

学会準備のためあまり勉強できず、、

ScalikeJDBCの使い方が難しくて詰まった。あとScalaのimplicitがむずい。

12月

応用情報受かった
このブログをNext.jsでつくった

応用情報受かりました！🎉

午後が結構不安だったのでめちゃめちゃ嬉しかったです。(午前78%, 午後62.5%だった)

わりと広く浅く学べたのでこれからがっつり学ぶ必要が出てきたときの土台となってくれれば…と期待しています。。

Next.jsに入門しました。今までcomponentが増えてくると辛みが増していましたがcomponentを/pagesと/componentに配置するやり方が読みやすさ的にも書きやすさ的にもいいなと感じました。

あとはVercelへのデプロイが簡単すぎて感動しました。

詳しくはこちらをご覧ください。

まとめ

最後まで読んでくださりありがとうございます。

あと4ヶ月でエンジニアとしてのキャリアがスタートするのでそこまで頑張って力を高めていちはやく技術力で会社に貢献できるようになりたいです。

2021年もがんばります。

Next.js VercelでBlogをつくった

Sat, 26 Dec 2020 16:15:48 +0000

急にブログが書きたくなったのでつくった。

使った技術

Next.js
TypeScript
Vercel

感想

Vercelめっちゃ楽
Syntax Highlightできてうれしい

const age: number = 1  // こんなかんじ

これからやりたいこと

header footerつくる
独自ドメイン取得
全体的に見た目をまともにする
記事一覧ページに書いた日時・タグも表示する
簡単な自己紹介
各種SNSへのリンク
存在しないリンクへアクセスされたら記事一覧に戻す

blog.kyu08.com

『プログラミング言語C 第2版』を読んだ

どんな本か

読み方

学び

まとめ

『ネットワークはなぜつながるのか』を読んだ

どんな本か

なぜ読んだか

学びや気付き

1. ブラウザが何をしているか

2. DNSが何をしているか

DNSサーバーに格納されているデータ

世界中のDNSサーバーが協調する仕組み

3. TCPでの接続の場合にプロトコルスタックが何をしているか

4. IPが何をしているか

5. イーサネットとは何か

6. インターネットとは何か

Q&Aメモ

まとめ

Go Conference mini in Sendai 2026に参加した

【KeyNote】静的解析からみるGoの過去と未来

AI時代のGo開発2026 爆速開発のためのガードレール

Go での並列処理 「最初の一歩」から「次の一歩」へ

Go.1.26のruntime/metricsが便利そうな件（？）

モジュラモノリスにおける境界をGoのinternalパッケージで守る

Go設計思想の深掘り

database/sql/driverを理解してカスタムデータベースドライバーを作る

nilとは何か 〜言語仕様と設計者の葛藤から理解する〜

Who tests the Tests ?

Goから学ぶGCの仕組みとGreen Tea GCによる次世代最適化

【実装公開】Goで実現する堅牢なアーキテクチャ：DDD、gRPC-connect、そしてAI協調開発の実践

スポンサーブースで話したこと（一部抜粋）

感想

振り返り

おまけ

開発環境現状確認 2026

OS

エディタ

AIツール

ターミナルエミュレータ

ターミナルマルチプレクサ

シェル

ランチャー

ウィンドウマネージャー

フォント

タスク管理

ブラウザ

IME

CLI/TUIツール

fzf

lazygit

k9s

fzf-make

キーリマッパー

キーボード

その他

まとめ

『解像度を上げる』を読んだ

「解像度」の構成要素

情報をツリー構造で整理する

解像度を上げる対象

課題の選び方

書くことで考える

書くときの留意点

深める

不慣れな分野のキャッチアップ

教える

コミュニティに参加する

まとめ

『CQRS Documents by Greg Young』を読んだ

CQRSに興味を持ったきっかけ

“A Stereotypical Architecture”: 典型的なアーキテクチャ

ここまでの感想

CQRSとは

ここまでの感想

“A Stereotypical Architecture"にCQRSを導入する

Query

Command

ドメインイベント、イベントソーシング

Go での並列処理「最初の一歩」から「次の一歩」へ

nilとは何か〜言語仕様と設計者の葛藤から理解する〜

Who tests the `Tests` ?

『RustによるWebアプリケーション開発設計からリリース・運用まで』を読んだ