Posts

MySQL 環境で SQL を書く練習をしたい。この環境は使い捨てにしたいので、Docker で環境を作ることにした。 Docker Hub に MySQL の公式イメージがあるので、目標は簡単に達成できると思っていたが、実際には色々と苦労したので、未来のためここに手順をメモしておく。 苦労したのは日本語の入出力まわりである。Docker イメージ側の設定、mysqld の設定、MySQL クライアントの設定のみっつが必要となる。 具体的には次のようにした。 まずは Dockerfile を適当なディレクトリに置く。内容は次の通りだ。 FROM mysql:8.0.29 RUN apt-get update && \ apt-get install -y locales && \ rm -rf /var/lib/apt/lists/* && \ echo "ja_JP.UTF-8 UTF-8" > /etc/locale.gen && \ locale-gen ja_JP.UTF-8 ENV LC_ALL ja_JP.UTF-8 RUN { \ echo '[mysqld]'; \ echo 'character-set-server=utf8mb4'; \ echo 'character_set_filesystem=utf8mb4'; \ echo 'collation-server=utf8mb4_general_ci'; \ echo 'skip-character-set-client-handshake'; \ echo '[client]'; \ echo 'default-character-set=utf8mb4'; \ } > /etc/mysql/conf. [Read More]

テスト駆動開発について学んでいる。手始めに、かの有名な @t_wada さんのライブコーディングデモ動画を眺めてみた。

テスト駆動開発については耳年増のようになっており、「Red -> Green -> Refactoring」のマントラや「プログラムのテストはテストコードで行い、テストコードのテストはプログラムで行う」という考え方については「知識としては知っている」という状態であった。「…とはいえ、実際にテスト駆動で開発を進めるのは難しいよね」と思っていたが、デモ動画を通して、それが「現実世界で実行できるプラクティスなんだな」と感じられた。

耳年増な自分が知らなかったこととしては「アサーションルーレット」がある。これはひとつのテストにたくさんの assertion がある場合、テストに失敗した時どの assertion に失敗しているのかわからない、という問題である。正直、そういうテストコードを目にしたことがあるし、自分もたくさん assertion を並べたことがある…。

これを解決するプラクティスは「One Assertion Per Test 原則」と語られていた。そのまま過ぎるけど、そういうことである。

前職の友人と久しぶりに再開した。彼は過去に XP (eXtream Programming) を実践する会社に所属していたこともあり、会ったばかりの頃は XP のプラクティスのひとつであるペアプログラミングを会社に導入したがっていた。僕は彼より先に転職してしまったが、彼は今でも同じ会社に勤め続けている。

「ペアプログラミングは導入できた? “全社的に” とは言わずとも、チーム内とかで」と聞いたら、彼は「この会社でペアプログラミングをするのは諦めた」と言った。なぜなのか。彼が語った話は実に面白かった。内容は次の通りだ。

ペアプログラミングは単にペアでプログラムを書くという行為を指すわけではない。これはコンスタントなコードレビューでもある。つまり、ペアプログラミング中はレビュー目的のプルリクエストは必要ないし、そもそも Git でブランチを切る必要すらない。しかし、会社では main ブランチへの直接のプッシュは禁止されている。プルリクエストでレビューされていないコードをマージすることもできない。つまり、ペアプログラミングを導入するためには開発フロー全体を見直す必要がある。そこまでの労力は割けない。

なるほど、と思った。

僕は知らなかったのだが、これは「トランクベース開発」というものであり、これ自身もよく知られているプラクティスのようだ。

トランクベース開発では (略) マージリクエストの代わりにペアプログラミングやモブプログラミングの仕組みがよく採用されています。これらにおいては、開発期間中、継続的に他者の目でコードの内容が客観的に評価されるため、作業完了時に既に一定の品質が確保されるものと考えられます。

ペアプログラミング (ひいては XP のプラクティス全般) は、ボトムアップで導入する場合でも、開発戦略全体を統括する立場の人間を巻き込まないと実践は難しいのだなあ、と感じた。

少し前に自宅回線を Nuro 光にしたのだが、気づいたら勤務先がホストしている VPN サーバーに WireGuard (VPN) で繋げなくなっていた。テザリング環境では接続できるので Nuro 光のせいで繋げられなくなったのだろうと仮定して、ルーターの設定をいじってみた。

我ながら間抜けな方法だと思うけど、Nuro から貸与されたルーター (SGP200W) の設定項目から怪しいものを端から on/off してみた。最終的には「パケット転送における IPv6 ファイアウォール制御を有効化」というチェックをオフにして解決できた。この “パケット転送における IPv6 ファイアウォール” はどう振る舞うものなのか、ぼんやり想像することくらいしかできないけど…。

半年くらい前に価格コムで同じ (と思われる) 問題に遭遇している方がいたので、誰かの助けになるかもしれないと思って記事にした。

追記

次の記事を読んだ。

• NURO光以外の光回線も危険！？ セキュリティに問題あり 安全に使う方法は？

「ルーター + ONU」であるところの SGP200W で IPv6 ファイアウォールを無効にしても僕のデバイス群では問題ないだろう。しかし、家族が使う端末でも問題がないとは言い切れない (公開ポートが限定されているとは限らない)。IPv6 ファイアウォールを無効にするだけでは妥当な問題解決とは言えなそうだ。

そこで、元記事の内容に加えて IPv6 そのものを無効にした。

(「経路広告を有効にする」と「DHCPv6サーバを有効にする」のチェックを外している)

これで IPv6 の IP アドレスが割り振られなくなった…はず。少なくとも What Is My IP Address からは Not detected と言われるようになった。

あと数年で 40 代に突入する。ありがたいことにソフトウェア開発産業は売り手市場で、40 代でも転職は難しくなさそうだ。「ソフトウェアを開発する仕事」と一口に言っても、その内容は様々である。次に職場を変えるとしたら、どのようなソフトウェア開発をしたいだろう。

僕は「風上に向かいたい」と考えている。

これは上流工程を志向している、という意味ではない。空気は風上から風下に流れるが、そのような流れから逆行したい、ということだ。たとえば、理系の学生が文系に転向することはままあるけれど、文系の学生が理系に転向することは稀である。したがって、理系を志向することは「風上に向かう」ことだと考えている。これは僕が考える風上の定義なので、異論はあるだろう。「僕はそう考えている」という以上の意味はない。

ソフトウェア開発における「風上」とは何だろう。僕は次のように考える。

• API を使うより、API を作る方が「風上」である
• ユーザーランドで動作するアプリケーションより、カーネルの方が「風上」である
• マニフェスト (YAML / JSON) を書くより、マニフェストを読み込むプログラムを書く方が「風上」である

「風上である」ことと「重要である」ことは関係がない。上記のリストは「風上」と「風下」がおおむね対になっていて、両方が存在してはじめて意味を成す (e.g., API を使う / API を作る)。僕は「風上」を志向している、というだけの話である。

意識しないと「風上へ向かう」のは難しい。自分を鼓舞するため、わざわざ記事にしてみた。

2021 年の出来事を振り返ってみる。 家庭 何よりも大きいのが第二子の誕生である。彼が産まれてから生活は激変した。今回は三ヶ月の育児休暇を取得した (第一子のときは一ヶ月)。 読んだ本 2021 年に読んで印象深かった本を列挙する。 感想をブログ記事にした本 デザインされたギャンブル依存症 ユニコーン企業の秘密 Learn or Die リモートワークの達人 NO HARD WORK! 技術書 達人プログラマー (第二版) 「達人プログラマー」は過去に第一版も読んだ。 第二版は中身が大きく改訂されており、楽しく読めた。 Kubernetes 完全ガイド (第二版) 「Kubernetes 完全ガイド」は通読できていないけど、読んだ部分はかなり丁寧に書かれていて良かった。 漫画本 ムーちゃんと手をつないで 「ムーちゃんと手をつないで」は Kindle で購入して読んだ。 自閉症児の育児について「参考になるな」という気持ちで読んだ部分と、どうにも感情移入してしまって涙ぐんでしまう部分があった。 その他の本 長男のために読んだ絵本の「みえるとか みえないとか」はとても良かった。障害とは何か、幸せとは何か、読みながら考えさせられた。 仕事 職場では主に TypeScript/JavaScript でプログラミングをした。引き続き Individual Contributor として仕事をしている。 大きめの仕事としては AWS を全社的に導入するリードをした。具体的には AWS Organizations を使った AWS アカウントのセットアップや運用ポリシーの設定、IAM や MFA の設定などである。GCP 一辺倒であったところに AWS を導入したけど、それほど混乱なく受け入れられたので、ひとまず成功と言ってよさそうである。 その他、認証基盤の Auth0 マイグレーションや OpenAPI Spec をベースにしたドキュメントの整備などもした。 [Read More]

「デザインされたギャンブル依存症」を読んだ。

とあるブログ記事で本書が紹介されていて、興味を持った。そこでは「ギャンブル中毒者は (大金を得るためではなく) “ゾーン” に居続けるためにスロットマシーンをプレイする」と書かれていた。

プログラマーの生産性はいかに効率よくゾーンに入るかにかかっている。ギャンブルにハマりたくはないが、プログラミングにハマるのは健全だ (たぶん)。そう考えて、カジノ業界がいかにプレイヤーをゾーンに導くのか、その手口を知りたくなったのだ。

しかし、本書の主眼はそこではない。

プログラマーがゾーンに入って丸一日仕事をすると、心地よい疲労感と充実感が得られる。しかし、ギャンブル中毒者はそうではないらしい。「なぜ自分はギャンブルをやめられないのか」「なぜ排泄感があっても台から離れられないのか」と考えてしまうらしい。僕はゾーンに入る体験は幸せなものだと思っていたが、必ずしもそうではないようだ。

本書を読んで良かったのは、心理学者のミハイ・チクセントミハイ氏が唱える「フローに入るための4つの必要条件」を学べたことだ。

1. 行動のそれぞれの瞬間には小さな目標がなければならない
2. そのゴールを達成するためのルールが明確でなければならない
3. その行動が、その人の立場で、瞬間ごとに確信が得られるように、即座のフィードバックを与えるものでなければならない
4. その行動の作業が操作上のスキルと合致していて、制御と挑戦が同時に起こっているという感覚を与えるものでなければならない

最近 LeetCode で少しずつランダムに問題を解いていて、楽しいと感じている。おおむね 30分~数時間程度で問題を解く (もしくは理解できずに解説を読む) ということをしており、この「問題を解く」ときに自分はフローに入っているように感じる。かなり高い集中力で、問題のことだけを考えているのである。

これは僕にとって LeetCode がミハイ氏の4つの条件を満たしているからだと思う。目標は「問題を解くこと (= 自動テストを通すこと)」であり、そのルールは明確である。またテストを通せたかどうかは数秒でわかるし、プログラマとしてのスキルセットで問題を解くときには制御と挑戦が同時に起こっているようにも思う。

もっと自分を意識的にフローに持っていけるように訓練していきたい。

2021年9月26日に新型コロナウイルスワクチン (米ファイザー社製) の二度目の摂取を完了した。ワクチン接種にともなう副反応も治まったので、僕の副反応の経過について書いてみる。

一度目の接種は2021年9月5日であった。このときは注射をされた側の腕が少し痛む程度で、他には大した副反応はなかった。

二度目の接種のときは発熱と倦怠感、頭痛があった。具体的には次の通りである。

• 9月26日10時: ワクチン接種
• 9月26日13時: 頭痛 (発熱なし)
• 9月26日16時: 頭痛が治まる (発熱なし)
• 9月26日21時: 就寝 (発熱なし)
• 9月27日07時: 起床 (38.2℃の発熱と倦怠感あり)
• 9月27日 (日中 + 夕方): 37.2℃ ~ 38.9℃ の発熱 (上がったり下がったりを繰り返す)
• 9月27日20時: 就寝 (就寝時は37.4℃)
• 9月28日06時: 起床 (36.7℃)

接種当日と翌日はぐったりしてしまい、ほとんど仕事や家事ができなかった。現時点では三度目のブースター接種にともなう副反応は二度目と同程度と言われているので、仮にブースター接種を受ける場合には二日間は作業ができなくなることを見込むのが良さそうだ。

「ユニコーン企業の秘密」を読んだ。著者の Spotify での経験をまとめた内容になっている。序盤で Google, Amazon, Facebook を「スタートアップみたいに運営されている 企業」として「ユニコーン企業」と同一視している。僕の感覚ではそれらの企業はだいぶ風土が違うので、違和感があった。

「Spotify は Spotify モデルを使っていない」という話がある。これについては「訳者あとがき」にも書かれている。本書を読んだ者としては、単に「Spotify モデルは変わり続けている」ので、ある時点のスナップショットと比較すると「Spotify は過去と同じモデルで運営されていない」という表現が正しいと思う。一方で Spotify カルチャーの原則は時代を通して安定しているように感じる。

「自身の勤務先に Spotify 風の文化を取り入れるのは難しそうだ」と思った。本書で繰り返し言われている「権限を与えて」「信頼する」ことを実践できるのは自分なのか? そもそも権限を与える権限が自分にはないぞ…というようなことを考えてしまった。

例えば my-secret という Secret オブジェクトが Kubernetes の default ネームスペースに存在するとき、その .data.apiKey をランダムな UUID で置き換えたいとする。そのときは次のようなコマンドを実行すればよい。 kubectl get secret my-secret -o json | jq --arg apiKey "$(cat /proc/sys/kernel/random/uuid | tr -d '\n' | base64 -w 0)" '.data["apiKey"]=$apiKey' | kubectl apply -f - 十分に読める内容だと思うけど、説明をすると次のようになる。 cat /proc/sys/kernel/random/uuid でランダムな UUID を取得する Kubernetes の Secret は base64 値で保存する必要があるので、パイプでつなげて base64 にしている (結果を apiKey という変数に保存する) 現状の my-secret から .data.apiKey を apiKey で置き換えて、それをパイプ経由で kubectl apply する 補足 本来であれば Kubernetes に変更を加えるときは、変更履歴を追えるようにするべきだ。具体的には YAML ファイルを Git で管理して、Git リポジトリへのプッシュをトリガーにして Kubernetes に変更を加えるようにするとよい。なお Helm や Kustomize を使う場合でも考え方は同じで、変更内容をファイルとして Git で管理して履歴を残すのが正しいプラクティスである。 [Read More]