2023年の振り返りはさぼりましたが、2024年を振り返ります。前回の記事はこちら
総合
2024年は、お手伝いしていた成果が世の中に出た年でした。喜ぶ人が観測できてよかったです。2025年も新しいことへのチャレンジに取り組んでいます。2025年は自社のために時間を捻出できそうなので形にしていきたいです。
インフラ的なお仕事は「サービス全般を一人で見るのは難しい」です。だからこそチームを作ってサービスを支えることが必要です。幸いにして、2022年から見ていたチームが素晴らしく、サービスを支えられています。チームに尊敬と感謝を改めて表明します。振り返るとIaC 100％、CI/CDを通したワークフロー整備がチーム育成の土台になりました。IaCはプロジェクトの地力を高めるを証明になったので、今後もよりよくなっていくように頑張ります。
2024年になってもわからないことが多く、何もわかっていないことを痛感します。ただ、ChatGPTをはじめとする生成AIを利用することで、これまで独力で試行錯誤していることに、壁打ちという武器を得ることができて開発イテレーションが早くなりました。生成AIを使うとこれまでの限界を超えることができるので、2025年もAIに置いて行かれないように学び続けたいです。
経営
2024年は外部への協力に注力しました。これは2025年から自社のサービスを立ち上げるための準備として当初から計画していたことです。無事に準備が整ったので、2025年は作りたかったものを自社で作っていく予定です。
プログラミング
今年はC#メイン、HCL、Bashへ注力しました。
C#
C# 13が出て、手元のコードの多くを.NET9に書き換えをしました。.NET8のCollection Expressionほどのインパクトがある変更はすくないですが、Spanを最優先でAPIをそろえていける手ごたえがあっていいですね。
C#でずっとやりたいなぁと思っていたことに2024年は取り組んで形になりました。いずれどこかで発表したいものです。2025年も長年C#でやれなかった宿題があるので、引き続き取り組んでいきたいです。
C#言語機能そのものの改善もいいのですが、2024年はC#でZxを使っていける手ごたえを得られたのが大きかったです。ようやくCIにおけるスクリプトをBashからC#へ置き換え検討できそうです。つまり、ProcessXとConsoleAppFramework v5が欠かせない部品になりそうですね。
Bash & PowerShell
この5年あまりはBashを使い倒しました。Bashはいいものです。ただ人によって書き方がバラバラすぎるので、チーム向けにスタイルガイドguitarrapc/bash-styleguideも作成しました。Googleのスタイルガイドを参考にしつつ、Bashの特性を生かしたスタイルガイドにしたつもりです。Bashをどう書くと挙動を安定させつつ、チームでメンテできるかを考えるのは楽しいです。
PowerShellへ傾倒をした次のステップとしてBashにも同程度に傾倒する必要があると考えてこの数年やってきました。私がPowerShellで悩んでいたのは本ブログのPowerShell記事が減ったことでもわかる通りですが、Bashと向き合うことは今後PowerShellをどう使っていくか考えるにあたり欠かせないチャレンジとなりました。
改めてBashを考えてみましょう。BashはPowerShellとは違い、ネイティブコマンドと組み合わせたときに挙動を制御できるのが強みです。PowerShellはネイティブコマンドと組み合わせたときに挙動を制御できないのが弱みです。BashもPowerShell同様にコマンドを書き連ねたり2,3行書く分には申し分ないのですが、それ以上のスクリプトを書くのは強く避けるべきと痛感しました。Bashでスクリプトを書くこと自体はそれほど難しくないですが、「Bashの言語構文はスペース1つに左右される繊細さ」1と「コマンドの挙動を理解する必要がある」ためスクリプト言語として難しいと言わざるを得ません。Zxに注目しているのはこのためです。
さて、PowerShellの利用範囲を広げるためにはBashのように「ネイティブコマンドと組み合わせたときに挙動を制御できるようになる」必要があります。たったの数行であってもネイティブコマンドが出た瞬間にPowerShellは候補から外れ、将来ネイティブコマンドを使うことを考えて選択肢にいれないこともあります。PowerShellの利用範囲を広げられない大きな原因の1つなのは疑いようのない事実です。しかし2023年にリリースされたPowerShell 7.4で、PowerShellとネイティブコマンドの組み合わせ課題が解消されるPSNativeCommandErrorActionPreferenceとPSNativeCommandPreserveBytePipeが入りました。PowerShellがクロスプラットフォームに使えるシェル、スクリプト言語のスタートラインに立ったといえます。2025年は、この新機能を踏まえたPowerShellの利用方法について紹介していきたいです。
なお、Windowsのデフォルトは今後もしばらくWindows PowerShell 5.1のままでしょう。PowerShellが.NETをベースとする以上、LTSで3年程度の.NETと各OSのサポート期間バランスを取るのは難しいからです。
ちゃんとチームでメンテしていくなら、スクリプトをZxで書くことを最優先に検討したほうがいいと考えています。Goなどの任意のコマンドで書くことも同様に検討する派ですが、話がずれるのでそれはまた別の機会に。
HCL
Terraformは多くの機能が入り、おおむねほしい機能が揃いました。特にmoved/import/removedブロックは、コードからterraform stateを制御できるようになる点からワークフロー革命です。インフラのリファクタリングをPR+CIで完結できるようになったので、terraform stateを使っているのであれば早くTerraform 1.10にアップグレードしてやり方を変えましょう。terraform stateを実行するワークフローは事故の原因です。
Terraformの運用は悩ましいものがありますが、やはりモジュールに実装を押し込める手法が最も安全で運用しやすいと感じています。Terraformのモジュールはクラスと捉えることができ、モジュールは循環参照できません。このため、モジュールのvariables/outputsを適切に設計すると、コード間の依存関係を明確に制御できます。モジュールの外に関心が漏れることも防げます。Terraformのコード設計によって循環参照をなくせるのは、インフラを維持、改善するにあたり大きなメリットです。チームに対する設計方針の説明もしやすく、コードレビューのスコープも狭まり、コード品質の維持管理もしやすくなります。
Terraformは新サービスやプロバイダーの追加が早い一方、世の中のリリースはもっと早いので追いつけていないと感じます。IaCもそろそろ次のステージに行けるといいですね。個人的にはCrossplaneのようにKubernetesからクラウドをすべて管理するのは違うと感じますが、aws-controllers-k8sのようにKubernetesから一部クラウドリソースを管理するのはありですし使っています。2025年は次のIaCにも注目しています。
記事
2本、過去最少!今年は毎日更新したい謎の欲求があります。頑張りましょう。
原因は記事を書くスタイルを変えたはいいものの、記事を書くのがストレスだったからです。以前は記事を書くときははてなブログからさくっと書いてましたが、2023年末からGitHubで書いてはてなブログに同期する手法へ変えました。この時PRをマージすると公開されるようにしていなかったのと、textlintでの校正が苦痛で仕方なかったのがストレスの原因です。2024年末にHatenaBlog Workflows Boilerplateをベースとした記事スタイルに変更したのと、textlint校正の大半を完了したので、記事を書くのが楽になりました。今年は記事書きたい。
ライフスタイル
コロナが収束している気が一切しないので、マスク生活をやめていません。2024年についに罹患したのですが、発症前にラーメンを食べているときに隣の席のお客さんが咳をしていたので、その時罹患したと推測しています。幸いにして、手洗い・マスクをしている4年は体調を崩しにくくなったので、これからも衛生には気を付けて続けていきたいです。
2025年は?
PowerShellの新しい利用を紹介していきたいです。Terraformでいくつか実践的に投下したいものがあるので、それも試したいです。C#でもいくつか書きたいライブラリがあるので書いていきたいところです。
やりたいこといっぱいですね、頑張りましょう。
- ShellCheckでもBashの言語構文の異常はカバー仕切れないですしね↩
