おそらくはそれさえも平凡な日々

gopkg.in/yaml のアーカイブと乗換先やメンテナンス継承議論

この話は、goccy/go-yaml 作者のgoccyさんと、YAMLの話を…止めない!という私のポッドキャストエピソードでも話した内容だが、口頭では説明が難しかったり、上手くまとまってなかった部分もあったので、補足的にエントリーを書いた。ポッドキャストでは裏話的な話やgoccyさんの生の意見も聞けるので、そちらも是非聞いてみて欲しい。

GoのYAMLライブラリとそのアーカイブ事件

GoのメジャーなYAMLライブラリには大きく以下の2つがある。

他にもYAMLライブラリはいくつかあるが、実態は、gopkg.in/yaml のラッパーであることがほとんどだ。例えば、github.com/ghodss/yamlや sigs.k8s.io/yaml等。

gopkg.in/yaml は k8sやdocker compose内部でも使われている世界的に標準的なライブラリで、我々ソフトウェアエンジニアを支えている重要なライブラリと言える。そして、その開発リポジトリが正式にメンテナンスを停止し、アーカイブされるという事件があり、乗り換え先選定やメンテナンス継承等に関わる色々な動きが起きている。

アーカイブの影響

直ちに問題はなく、大事になっていない。ライブラリとしては利用可能なままだし、そもそも、gopkg.in/yaml のメンテナンスは実質的に大分前から止まっていたようなものなので、状況が大きく変わったわけではない、という見方もある。

ラッパーライブラリが多く存在するのもそのためだ。足りない機能やGoらしくないインターフェースをラップするために、ラッパーライブラリ経由で gopkg.in/yaml を操作する使い方がされている。YAMLの仕様は余りにも膨大であるため、イチからライブラリを実装するのは多くにとって現実的ではないという話もある。

とは言え、アーカイブされたライブラリに依存するのは長期的には不安定なので、乗り換え先を選定するか、既存のソースのメンテナンス継承を検討する必要がある。

そこで、有力な乗り換え先として注目されているのが goccy/go-yaml である。

2つのYAMLライブラリの比較

私は元々、goccy/go-yaml を好んで使っていた。そっちの方が使いやすく、品質も高いと考えていたからだ。作者のgoccy(五嶋)さんに対する信頼度が高いことも後押ししている。

2つのライブラリの簡単な比較は以下。

実装をもとに作られたgopkg.in/yamlと、仕様をもとに作られたgoccy/go-yamlとアプローチが異なるのが面白い。開発の世界では良くある話でもある。

個人的には、goccy/go-yaml への乗り換えが進んでいくのだろうと思っていた。gopkg.in/yaml はそもそもメンテナンスに困っており、引継先なども模索した上で、それが難しいと判断してアーカイブされたのだろうから、今後引き取り手が現れる可能性も低いと思っていた。

ただ、goccy/go-yaml も個人プロジェクトではあるし、gopkg.in/yaml とのインターフェースの差異もあるため、乗り換えコストを払うことが見合うかどうかは様子見されている雰囲気も感じる。

そして、ここで、(あまり注目されていないが)大きな動きがある。YAML本家による、gopkg.in/yaml のメンテナンス継承である。

YAML本家によるメンテナンス継承

YAMLオーガニゼーション はYAMLの総本山であり、YAMLの仕様に加えて、LibYAMLやPyYAMLの実装、YAMLテストスイートなども公開・開発・管理している。YAML自体がPerl出自の技術であることもあってか、Perl6の実装も公開しているのも面白い。そこが、gopkg.in/yaml のメンテナンスを引継を計画して進めている。そのリポジトリが以下だ。

(ちなみに、元々の gopkg.in/yaml のリポジトリはgithub.com/go-yaml/yamlなので、仕方がないのだが、紛らわしく、説明に苦労する。)

これは、客観的に見たら悪くない話ではあるだろう。メンテナンスに困ったOSSの受け皿として、このようなオープンな団体が手を挙げるのは良いことだ。ただ、リーダーシップ不在のまま引き取られたOSSが、結局放置される事例は多い。「墓場」の様な揶揄がされることもある。

gopkg.in/yaml の保守性の悪さからメンテナンスに苦労していた現実もある。そういう「死にかけている」ライブラリに対して無理に延命措置を講じることが本当に良いことなのか、という話もある。gopkg.in/yamlがその性質上、Goらしくないコードになっていることや、YAML本家のチームにGoのエキスパートがいなさそうなのも不安要素である。

この継承に関する議論は、CNCFのSlackの #go-yaml チャンネルで行われており、誰でも閲覧可能だ。CNCF内で議論されているというのが面白い。

ただ、最近のCNCF Slackのプラン変更により、90日以上前のメッセージが閲覧できなくなるので見たい方はお早めに。該当チャンネルは、4/25作成のチャンネルなので、今ならまだ全部のログが読める。

goccyさんとYAML本家との対話

goccyさんも上のSlack上に投稿し、議論がなされている。YAMLの大本の作者である、Ingy döt Netさんが精力的に議論に参加していてアツい。

ここで、出てきた面白い観点としては、gopkg.in/yaml はLibYAMLの移植であり、Goらしいコードになっていないことが彼らにとって寧ろ好ましいという点だ。

これは言われてみれば無理もない話だろう。彼らは、LibYAML, PyYAMLも同時にメンテナンスしているわけで、go-yamlも含めて、それらが似通った実装になっている方がメンテしやすいというのは道理だろう。Goに詳しい人がいないから尚更だ。

そして、もう一つの観点として、「仕様が正か。実装が正か」というソフトウェア開発で頻出の話がある。彼らは、YAMLの仕様も、汎用的で網羅的なテストスイートも公開しているので、元々は仕様を正にすることも考えていたのだと思う。ただ、実際はLibYAMLやPyYAMLの振るまいが事実上の標準仕様となっていることを受け入れ、その方針で進めているようだ。だから、尚更、gopkg.in/yaml の実装がLibYAMLに近いことが好ましいという話になる。

実際、YAML仕様の記述には曖昧な点があり、テストスイート自体が正しいか、という話もある。

ちなみに、gopkg.in/yaml のテストスイート網羅率は73%であり、goccy/go-yamlは88%である (2024年12月時点)。そもそも100%を目指す様な者でもなく、その必要性も疑わしいという話もある。

私は、YAMLのテストスイートが網羅されている実装は存在しないと認識していたが、実は2020年に、本家が全てのテストケースが通る参照実装を公開していた事を今回の議論の中で知った。そして、それを参考にテストスイートを網羅するライブラリも少ないながら出てきているとのことだ。

https://github.com/yaml/yaml-reference-parser

それと同時に、この参照実装は実用性に欠け、彼らがメンテナンスしているPyYAMLやLibYAMLも意図的に仕様から逸脱していて、テストスイートを網羅していないことも議論の中で明かしている。

現実問題としては仕方ないとも思うが、仕様から実装を進めていたgoccyさん的にはびっくりする話だっただろうが、その辺りの公式のスタンスが今回知れたのは良かったとは思う。

KubernetesのYAMLライブラリの移行

ちょうど本日、6月26日、Kubernetes本体から、gopkg.in/yaml の依存がドロップされ、新しい go.yaml.in/yaml (yaml/go-yamlのライブラリ名) へ移行するpull requestがmasterに取り込まれた。

Drop usage of forked copies of goyaml.v2 and goyaml.v3 by dims · Pull Request #132357 · kubernetes/kubernetes

現実問題としては、インターフェースやコードベースが同一の後続ライブラリに移行するのは丸い選択肢だとは思う。この新しいyaml/go-yaml はKubernetesが正式に採用することになり、CNCFも巻き込んで議論されているので、メンテナンス体制の不安もある程度払拭されたと言えるかも知れない。

私Songmu個人的には、引き続き、goccy/go-yamlを使い、推していきます。

おまけ: yamlscript

今回の議論の中で、YAML作者のIngy氏は現在yamlscriptという恐ろしい名前のプロジェクトに積極的に取り組んでいることも分かった。YAML愛が凄い。Ingy氏についての話や、yamlscriptについては、冒頭にも書いた、YAMLの話を…止めない!というポッドキャストエピソードで話しているので是非聞いて欲しい。

また、今回のSlack上での議論については、その半公開の性質上引用は控えた(多分やっても問題ないとは思うが)。議論を見たい方は、Slackに参加して #go-yaml チャンネルを覗いてみて欲しい。6/4~6/6辺りの議論なので、8月一杯くらいでアーカイブが消えてしまうのでお早めに。

単にブランチを作るだけのGitHub Actionを作った

Songmu/action-create-branch

READMEにも書いてあるが以下のように使う。これは、指定ブランチがあれば作るし、無かったら何もしない簡単なGitHub Actionだ。分岐元指定のrefにはブランチ名、タグ、コミットハッシュを指定できる。refは省略可能でデフォルトではgithub.refを使う。

- uses: Songmu/action-create-branch@v0
  with:
    branch: feature/new-feature
    ref: main

何故作ったか

先のエントリーの、action-push-to-another-repositoryのフォーク元には、元々、create-target-branch-if-needed という、指定ブランチがなかったら作るオプションがあった。しかし、私がフォークしたものからはそれを削除した。コードの複雑性が増してしまっていたし、その機能を内包する必要性も感じなかったからだ。

ただ、一時ブランチを作って、そこにpushするユースケースは確かにあるだろう。であれば、前段に、ブランチがなかったら作るというステップを定義すれば良い。

そういう、単純にブランチを作るだけのGitHub Actionはきっとあるだろうと思ったが、案外良い物が見当たらなかった。具体的には、分岐元のrefにブランチ名、タグ、コミットハッシュを柔軟に指定したいが、それができるアクションを見つけられなかったので、作った。

APIで操作するので、事前にcheckoutする必要がないのも嬉しいポイント。

action-push-to-another-repositotyとの組み合わせ

リポジトリのREADMEにも追記したが、以下のように使えば良い。

- uses: actions/checkout@v4
  persist-credentials: false
- name: Create branch if needed
  uses: Songmu/action-create-branch@v0
  with:
    repository: 'owner/dest-repo'
    branch: 'new-feature'
    ref: develop
- name: Push to another repository
  uses: Songmu/action-push-to-another-repository@v2
  with:
    destination-repository: 'owner/dest-repo'
    destination-branch: 'new-feature'

こちらの方が、１つのアクションに変にオプションを増やすよりも明確で分かりやすい。この様に、シンプルな部品を作りシンプルに留めること、それらを上手く組み合わせて使うのがソフトウェア設計全般で大事なことの１つだ。

実際、action-push-to-another-repositoryのスクリプトは50行程度だが、action-create-branchは133行と実はこっちの方が分量が多くなっている。なので、ブランチを作る処理はやはり内包したくない。

ちなみに、aciton-push-to-another-repositoryのコード行数が比較的少ないのは、コミット処理をsuzuki-shunsuke/commit-actionに委譲しているからだ。

また、action-create-branchのコード行数が比較的多いのは、指定されたrefからコミットハッシュを解決する処理がそこそこ複雑だからだ。それを今回はGraphQL APIを使って、一撃でcommitハッシュを取得するようにしてあるのが面白ポイントなので、興味ある方はコードを見て欲しい。

このアクションの開発ではClaude Codeに大半のコードを書いてもらった。便利ですね。

リポジトリの内容を別リポジトリにpushするGitHub Actionを公開した

あるリポジトリの一部または全部を別リポジトリのルートなりサブディレクトリにpushしたくなることがたまにある。一般的にもニーズがありそうだが、ちゃんとメンテナンスされているモノが見当たらなかったので、以下に公開した。かなり便利。

これはイチから作ったわけではなく、cpina/github-action-push-to-another-repository をforkしたものです。このfork元は、私も使っていたのですが、メンテナンス停止が宣言されており、signed commit対応などもされなさそうなので新たに開発することにしました。

そう、signed commit対応が今回公開したGitHub Actionの目玉です。actions/create-github-app-tokenを使ってトークンを発行し、そのトークンでsigned commitするという仕組みです。

ユースケース

privateリポジトリで作成したコンテンツを公開リポジトリにプッシュしたり、あるリポジトリの内容を別リポジトリのサブディレクトリにpushするなど、色々活用法は考えられますが、私のユースケースを以下に紹介します。

Songmu/oss4.fun-private -> Songmu/oss4.fun

プライベートリポジトリでポッドキャストのコンテンツを事前に作成しておき、公開時に公開リポジトリにpushさせている。これは、リポジトリ丸ごとsyncしています。

詳細は Workflow fileを参照ください。

Songmu/ghq-handbook -> Songmu/zenn.dev

ZennのGitHub連携は、ある人やオーガニゼーションの複数の記事や本を１つのリポジトリでまとめて管理する仕様になっている。これを、もともと単独リポジトリで管理していたgithub-handbookと連携するために、ghq-handbookのjaディレクトリの内容を、zenn.devのbooks/ghq-handbookディレクトリにpushさせている。

詳細は Workflow fileを参照ください。

まとめ

今回の目玉である、signed commit対応ですが、これは、suzuki-shunsuke/commit-actionを内部で使わせてもらって楽させてもらいました。ありがとうございました！

結構便利だと思うので是非使ってみてください。

TaskMD Shelf - 積極的棚上げを由とする怠惰なタスク管理

フリーランスになって、複数の案件を同時に進める必要が出てきたこともあり、タスク管理方法を見直した。何なら手法やツールも自作してしまおうと考えた。何かを始めるときに、まず道具から作り始めてしまうのは自分らしい振る舞いで面白い。

これをTaskMD Shelfと名付け、仕様を公開した。

https://github.com/Songmu/TaskMD-Shelf

これは、1 タスク = 1 Markdownファイルとして管理する手法。各ファイルはTaskMDと呼び、それに最小限のメタデータ設計と運用ポリシーを定めたもの。単純なアイデアで、類似の方法でやっている人も既にいるだろう。

既にこれでタスク管理をしていて上手く回っている。ObsidianのDataviewプラグインがとにかく役に立っているのだが、その辺りの話は別途。

怠惰な自分でも続けられる手法

個人的に、強すぎる制約があるタスク管理手法は長続きしづらく、続けていてもどこかで躓くと途端に折れて諦めてしまうことが多かった。

なので、怠惰な自分でも続けられるシンプルなタスク管理を目指した。

具体的には「今やらなくて良いことは積極的に棚上げする。ただし、見直し日は必ず定める」、という「積極的棚上げ」を基本戦術とした。

個人タスク管理に求めること

個人タスク管理に求める事は以下である。

GTD(Get Things Done)インスパイア

古来から提唱されている優れた手法であるGTDが目指す所も近い。実際GTD本を改めて読み返して、かなり参考になった。ただ、以前、GTDの実践を試みたこともあったが、その時にネックだったのが、とにかくタスクリストのメンテナンスに労力がかかることである。

「ネクストアクション」「備忘録ファイル」「プロジェクトリスト」「いつかやるリスト」etc., 確かにどれも重要だ。これらを「週次レビュー」で、しっかり定期的に時間をとってメンテナンスする必要がある。そして、週次レビューを怠ると、途端に本当に一瞬でシステムが崩壊するのだ。なので長続きさせられなかった。

ベースの哲学は優れているので、ツールや仕組みを工夫して手間を減らし、同様のことを実現したい。

なので、TaskMD Shelfでは全てのタスクをセマンティックプロパティを付与したテキストファイルを使ってデジタルで一元管理する。フィルタやビューを活用して、複数のリストのメンテナンスを不要にする。

新装版 はじめてのGTD ストレスフリーの整理術
著者 : デビッド・アレン
二見書房
発売日 : 2025-05-01
ブクログでレビューを見る»

積極的棚上げ戦術による自然なWIP(Work in Progress)制限

WIP制限はとても重要だ。そして「言うは易し、行うは難し」の典型例でもある。その制約を守れれば良いが、現実的にはとても難しい。これも心を折ってしまうような強すぎる制約になりがちである。

WIP制限は理想状態であり、そこに向かっていける仕組みが重要である。WIP制限を課すのではなく、結果としてWIPが制限されている状況を作るのである。

ここで「積極的棚上げ」戦術である。今日やらないと決めたことは「棚上げ」して、机の上(実行中リスト)から片づける。ただし「見直し日」を必ず設定して、その時に再開するか、再度棚上げをするかを決める。それだけのことだ。

レビューやメールの返信待ちなど、待ち状態のタスクも棚上げする。ここで重要なのは、それらにも必ず「見直し日」を設定することだ。これによって適切に催促できるし、有耶無耶になって立ち消えてしまうことを防げる。

TaskMD Shelfでまず実現できること

これらを踏まえて、TaskMD Shelfでは以下のようなことが実現できる。

これらのTaskMDファイル群を管理するために自分で自由にツールを作っていくことができるが、取り急ぎ、ObsidianのDataviewプラグインが非常に便利で、これを使って進行中タスクリストなどのビューを作成している。

プレーンテキスト指向

TaskMD ShelfはNotionのデータベースなども使うこともできる。様々なビューも作れるのでとても便利だろう。

しかし、プレーンテキストファイル群で管理することをお薦めしたい。それがまさしく、タスクの棚たるTaskMD Shelfである。

Obsidian CEOであるSteph AngoのFile over appの哲学にとても共感しているが、データフォーマットが決まったファイルが手元にあることはとても自由だ。IndieWebの思想に通じる物もある。個人が一生に抱えるタスクのデータ量なんて大したことはない。自前で充分に管理できる量だ。Gitを使えばバージョン管理もできる。

AIに支援してもらう

自分の管理下にTaskMDを置けば、AIに学習もさせやすく、支援も受けやすくなる。

今回、TaskMD Shelfを作るにあたってまず仕様をまとめたのは、根幹となる基本のデータ設計をしっかりやるSoR的な発想もあるが、それと当時に、AI支援を受けやすくすることや、ツールを作ってもらいやすいようにするという狙いもある。実際、このTaskMD Shelfを操作する為のCLIやMCPもClaude Codeに書いてもらっている。それらは公開するつもりである。

将来的には、TaskMS Shelfの内容を学習したAIが、次にやると良さそうなタスクを提案してくれたり、滞っているタスクのケツを叩いてくれたり、もう実現が不可能そうなタスクをそっと諦めさせてくれたりすると嬉しいと思っているし、それが出来るようになるとも考えている。

まとめ

しかし、仕様をまじめ腐って書いたらかなりの分量になってしまった。恐らくタスク管理手法考案者全員が「省力で長続き出来る方法」を当初は志向、模索しながらも、結局重厚になってしまう歴史を辿ってきたのだろうな、というのを体感した。

今回TaskMD Shelfを考えるに当たって、自宅にあるGTD本を含めたタスク管理手法の本を読み返すとともに、新たに気になっていたタスクシュートの本も何冊か読んだ。改めて非常に参考になった。タスクシュートからは一日にやることを絞ることや、実際に「できた」ことを記録すること、そこから成功体験を積み重ねることが重要だと再認識した。

その辺りのリサーチや、実際にTaskMD Shelfを運用してどうだったかは、大吉祥寺.pm 2025で話したいのでプロポーザルを提出する予定です。

提出しました → 怠惰で持続可能な、自由なタスク管理 - TaskMD Shelfの実践

先送り0(ゼロ)―「今日もできなかった」から抜け出す[1日3分!]最強時間術
著者 : jMatsuzaki
技術評論社
発売日 : 2024-02-24
ブクログでレビューを見る»

フェロー就任と独立のお知らせ

2025年4月より、所属していた株式会社ヘンリーは非常勤となり、フェローという肩書きを拝命しました。フェローとしては技術広報や採用広報の支援を中心に活動します。

ヘンリー理想駆動ラジオ というポッドキャストを始めたのもその一環で、今後書き起こしなども出していく予定です。

背景としては、プライベートの状況や色々もあってフルタイムで働くのは辞めようと考え、そういう状況でVPoEの責務を果たすのが難しくなったというのがあります。元々は退職予定でしたが、パートタイムで在籍を残させてもらうことになりました。

独立

元々個人事業主ではありましたが、フリーランスとしても正式に(?)独立となります。しばらくあまり稼働時間は増やさず、自分がやりたいことにもう少しフォーカスしたいとは思っています。

やりたいこととしては、今、本を書いているのですが、そういう文筆業だったり、OSSやBlog、ポッドキャストを含めた発信や創作活動を、自分の仕事の中心にできないかと模索していくつもりです。

自分でプロダクト作ったり事業を始めたりする可能性もあるとは思っていますが、まだノープランです。

企業への支援業など

現状、ヘンリー社の他に、元々、MOSH社の技術顧問を務めていて、そちらも継続します。

他にも企業への支援業はお声がかかれば受けていきたいと思っています。ただ、ありがたいことにすでに何社かにはお声をかけていただいており、自分の仕事のペース的にも、そこまで急に何社も増やすことは考えていないです。

色々支援できることはあると思っていますが、私自身、器用貧乏というと謙遜が過ぎますが、出来ることは多いものの、あまり「コレ」といった売りを作ってきたわけではないので、やれることを整理したいとは思っています。その辺りは改めてアナウンスできればと思っています。

何にせよ、面白そうな連絡をいただければお話などはさせていただければと思っています。いただく連絡の量によっては捌ききれない可能性もありそうなので、その際はご容赦ください。

ISUCON14参戦記 (カラアゲネイティブ 14,987点)

今年もISUCONに参戦した。今年も無事に開催され、素晴らしい出題と運営で良かった。ありがとうございました。

いつものカラアゲネイティブなメンツで出ようと思っていたが、 @toricls さんが出場できなかったため、私が技術顧問を務めているMOSH社CTOの村井さんを無理やり誘ってチームを組んだ。と言うことで、今年のカラアゲネイティブは、 @motemen, @RyosukeIketeru, @songmu の3名。言語はGo。リポジトリはこちら。

https://github.com/motemen/isucon14

序盤の作戦会議

前半戦

この頃合いに、motemenと村井さんがpt-query-digestを見ながらインデックスの追加だったり、テーブル構造の変更などをやってくれていた。

だいたい、前段のやるべきことは終え、後半戦は想定通り本命のマッチングと通知の改善かな、と言うところに至った。ただ、この時点で15時近くなっていた。てこずって時間をかけすぎたのでこのあたりもう少しスムーズにやりたかった。何はともあれ、通知周りの改善は他の二人に任せ、僕はマッチングの改善に取り組むことにした。

後半戦

と言うことで、終了間際に回したベンチが通って、14,987点でフィニッシュ。順位は多分103位。

反省

技術系アドベントカレンダーの歴史に思うこと

この記事は pyspa Advent Calendar 2024 の14日目の記事です。この記事で言いたいことを先にまとめると以下になります。

技術系以外のトピックでもアドベントカレンダーが作られることがありますが、この記事では便宜上それらも含めて技術系アドベントカレンダーと呼称します。

技術系アドベントカレンダー

日本の主に技術系のインターネット界隈では毎年12月になると、技術系アドベントカレンダーというムーブメントが発生します。ある技術トピックに対して、12月1日から25日まで複数人が持ち回りでブログを書くというのが基本的なスタイルです。

ニッチなトピックに対して一人でがんばって全部書くスタイル、技術以外のトピックのカレンダー、企業単位で社員持ち回りで書くなど、様々な派生を見せています。私が所属している株式会社ヘンリーも去年、今年と実施しています。

これは、お互い背中を押し合って、普段ブログをなかなか書く機会がない人がブログを書く機会になったり、結果として多くの有用なコンテンツがインターネットに放流されたりするので、良いイベントで、長く続いて欲しいと願っています。

技術系アドベントカレンダーの歴史はこれまでも多くの場所で語られていますが、今後この文化を長く続けるためにも歴史を知っておくことは有用だと思うので、改めて歴史をひも解きます。

原義の物理アドベントカレンダー

そもそもアドベント(待降節・降臨節)とは、11月末からクリスマスイブにかけて、キリストの降誕を待ち望む期間のことと日本語のWikipediaに書かれています。

そして、アドベントカレンダーとは、その期間に使う、ビンゴ的UIの日めくりカレンダー的アイテムです。それぞれの日付の扉を開けると、絵や聖書の一節、お菓子などが現れる仕組みです。カレンダーの開始日はその年のアドベントの始まりの日もしくはシンプルに12月1日、終了日は12月24日か25日のようです。これも、英語版のWikipediaに書かれていました。

つまり、降臨を待ち望む期間の日めくりのカウントダウンカレンダー的なアイテムであり、特に子供向けで毎日小さなお菓子が出てくるものが良く知られています。日本でも近年はカルディなどおしゃれな輸入食品を扱うようなお店で見られるようになりました。

つまり、そもそもは宗教的な催しでありアイテムなのです。

技術系アドベントカレンダーの萌芽

このアドベントカレンダーをモチーフに2000年に作られたのが、英語のPerl Advent Calendarです。これが恐らく技術系アドベントカレンダーの発祥です。2000年から始まったこの本家アドベントカレンダーがまだ今年まで存続しており、アーカイブも残っていることに感動を覚えます。

Perl Advent Calendar Archives

2000年から2004年にかけては、創始者のMark Fowler氏個人によるPerlモジュール紹介リレー形式になっていました。そして、彼が当初書いたAboutページがまだ残っており、その冒頭が奮っています。

This goes along way to proving what I always say: I come up with the best ideas when I'm hung over.
-- https://perladvent.org/2000/about.html

訳すと「これは私が常々言っていることを証明するものだが、二日酔いの時に最高のアイデアが浮かぶ。」と言った具合でしょうか。このページを読み進めると、London.pmの会合がその二日酔いの原因で、その勢いで翌日の昼休みにこのAdvent Calendarを作ったと書かれています。

それが、2024年まで継続していることは胸熱ですが、海外では他言語や技術コミュニティにその文化が輸出されることはあまりされていないようです。これは私の観測範囲の問題かも知れないのでご存知の方がいれば教えて下さい。

ちなみに私も2015年に "Perl and Redis" という記事を寄稿しました。お誘いのメールをいただいたときは大変嬉しかったので引き受けたことを覚えています。翌年も誘ってもらったのですが、それ以降残念ながら寄稿できていません。

日本への輸入

この技術アドベントカレンダーが日本のPerlコミュニティにより輸入されたのが2008年です。これも、ちゃんと当時のコンテンツが残っていて素晴らしいですね。

JPerl Advent Calendar 2008

記念すべき初日の記事は定数の展開という記事で、サンプルコード含めて6行しかなく、何なら誰が書いたかすらも書かれていない、非常にシンプルなTipsの紹介記事です。

始まりの経緯はtokuhiromさんの技術的アドベントカレンダーの有用性についてという記事に残っています。初年度は前日にアップした人が翌日の人を指名しながら、バトンを繋いでいく形式で、必然的に5分でさくっと書けるようなtipsが集まっていたようです。確かに毎日ちょっとしたお菓子が食べられるという原義のアドベントカレンダーともコンセプトがマッチしています。

バトン形式で繋いでいく方式も緊張感はありますが、その分全日埋まることは期待されていなかったように感じます。逆に案外初年度がちゃんと埋まってしまったというところでしょう。上記の記事内の寿司奢る云々も多分ネタだったのではないでしょうか。

実際、その後のエントリー形式になった2012のHacker Trackの3日目で、gfxさんが体調不良により記事を落としています。

@__gfx__は病欠です

今では見られませんが、代理でgfxさんのアイコンがぐるぐる回るアニメーションが投稿され、コミュニティ内で楽しんでいたのを覚えています。当時はそういうゆるさがありました。

上で"Hacker Track"と書きましたが、2年目の2009年ではHacker TrackとCasual Track、その他2トラック合わせて合計4トラック構成になりました。

私もこの2009年のCasual Trackの15日目に「PerlでEmEditorマクロを書こう」という記事を初寄稿しています。Perlコミュニティに初めて参加できた喜びを感じたのを覚えています。

ちなみに、当時の記事投稿方法はCodeReposのSubversionリポジトリのコミット権をYappoさんから貰い、はてな記法で書いた記事をコミットするとサイトが更新されるという方式でした。

この記事のエントリのタイトルの通り、私は当時はWindows上のEmEditorでPerlを書いていました。しかし、TortoiseSVNで上手くCodeReposにコミットできず、焦って当日ヨドバシカメラにMacbookを買いに走り、セットアップして、なんとか記事のコミットに漕ぎ着けたことを覚えています。これが私にとっての初Macでした。これはもちろんWindowsやTortoiseSVNの問題ではなく、当時の私が何も分かっていなかったという笑い話です。

2010年は8トラック、2011年は9トラックとなり、この頃がPerlのアドベントカレンダーの最盛期と言えるでしょう。その後、独自サイトはやめて、2013年からはQiitaで記事を募る形をとっています。

独自進化と定着期

これが日本では他の技術コミュニティに速やかに横展開され、すでに2011年時点でかなりの数が実施されていることが以下の記事に記録されています。

また、2012年にエンジニア向けナレッジシェアサービスであるQiitaにアドベントカレンダー機能が追加され、同年に技術記事以外にも気軽に使えるアドベントカレンダープラットォームであるAdventarがリリースされたことにより、アドベントカレンダーの開催がとても簡単になりました。それが追い風となり、その後数えきれない程の技術系アドベントカレンダーが作られることになり、完全に独自の文化として定着して今に至ります。

今の技術系アドベントカレンダーは毎日ちょっとしたお菓子が出てくるというよりも、毎日ホールケーキが出てくるような様相を呈していますが、それも面白い変化です。ただ、力を抜いた昔のようなアドベントカレンダーもあっても良いと思っています。

上記2サービスは、日本の技術系アドベントカレンダーの発展に大きく寄与したと言えます。しかも、Adventarは @hokaccha さんの個人サービスです。彼はGitHub Sponsorを開けているのでご利用の方は是非スポンサーを検討してみてください。私は先程小額ですがスポンサーしました。

https://github.com/sponsors/hokaccha

文化の盗用への懸念

ここまで書いてきた通り、この技術系アドベントカレンダーは、元々宗教色のある物がアレンジされ、日本で独自発展しているものです。私はこれが文化の盗用(cultural appropriation)のような形で批判されないか少し心配しています。

私としては元々の文化が理解されて敬意が払われており、アドベント期間を有意義に過ごすためのアイデアというコンセプトを外さなければ問題無いと考えています。元々の本家の英語のPerlアドベントカレンダーがアドベント期間に開催されているように。

ただ、アドベント期間を外れているのにアドベントカレンダーを名乗るのは良くないと私は考えています。それは元の文化への理解に欠ける行為に感じるからです。

そういった一部の逸脱が行きすぎた結果、それが文化の盗用だという妥当な批判をされ「アドベントカレンダーという名前は適切じゃないからみんな使うのを止めよう」となってしまうかも知れません。それは、この文化が好きな私としては悲しいですし、そうなって欲しくありません。

この技術系アドベントカレンダー文化を長く楽しく続けるためにも、歴史や元のコンセプトの理解が大切だと思い、このエントリーをしたためた次第です。

ソフトウェアエンジニアという人生の選択肢

最近、Webエンジニア界隈で、共通項を感じる印象的な出来事があった。具体的には以下の2件。

共通項はそれぞれ長めのブランクがありながら、ソフトウェアエンジニアリングの世界に戻ってきて一線級以上の活躍をしているということだ。二人とも僕と同世代かそれ以上の年齢でもある。これは勇気と希望をもらえることだ。

もちろん彼らの能力の高さゆえに第一線に戻ってこられたのかもしれない。ただ、どちらにせよ、別のことに興味があれば、職業エンジニアを離れて、フォーカスする期間があっても良いと言うことだ。能力不足ならなおさら中途半端になるよりフォーカスしたほうが良いとも言える。

それに多分戻ってこられる。ゆーすけべーの様に世界的エンジニアになるのは難しいにせよ、別に満足に働けるくらいには戻せるのではなかろうか。

技術は日進月歩で、キャッチアップを怠ると途端に置いていかれる不安があるかも知れない。でもそこにしんどさを感じ始めているのなら無理しないほうが良い。それに、そんな厳しい業界だったら新しい人が誰も参入できなくなって、消え去ってしまう。実際には優秀な若者が新たにどんどん業界に入ってきてくれている。

もちろん、若い人の方が我々よりも優秀であるという事実はあるが、経験や結晶性知能で勝っている部分もある。AIなどのテクノロジーに補助してもらえる部分も増えている。眼鏡がそうであるように。何より、いくらAIが発展しようと、ソフトウェアエンジニアは足りない状況が続くので、少ないパイを競って蹴落としあう必要はなく、寧ろ皆で高めあっていく必要がある。

人事になりました

私事ですが、10月から人事に異動しました。正式には「株式会社ヘンリー 経営管理部門 人事本部 VP of Engineering」というタイトルです。

私はなんだかんだでこれまで兼務ベースで約10年エンジニア採用やエンジニアリング組織開発にも携わっていて、知見やノウハウもあるのでフォーカスする期間があっても良かろうというところ。

今後はエンジニアとしての発信だけではなく、採用や組織的な発信も増やしていければ良いかと思っている。エンジニアとしての経験を活かし、人事関係のノウハウを抽象化してパブリックに公開するというのをもっとやりたい。

なので、今はプロダクションコードを書いていないが、またいずれコードを書く仕事に戻る気持ちは全然ある。今、どういう役割の帽子をかぶって、どこにフォーカスするかが大事。必要に応じて柔軟に帽子をかぶり変えて行きたい。

冒頭の話もあって、いつだって戻ってこられる安心感が強まったから別のところにフォーカスしようと思えたのもある。元々、プレイングマネージャー否定派ではあった。プレイングマネージャーやってた時期も長いけど。

家族や子育てにフォーカスしたって良い(当たり前)

別に子育てに限った話ではないが、結婚や子育てを機に、以前ほど趣味のエンジニアリングに時間や情熱を割けなくなっていることを不安に感じている人が結構見られる。私も感じることはある。

でも別に働くことや趣味のエンジニアリングを緩めて、家族や子育てに集中する時期があっても良いと思う。それは間違いなく人生を豊かにする。私自身も最近それを強く感じるようになった。自己正当化バイアスかもしれないが、そんなバイアスなら歓迎である。

これも当たり前だけど、家族や子育てに比重を置くのもあくまで個々人の選択であって、別のところに目を向けてみたって良い。

怖いのは情熱が枯渇すること

結局怖いのは情熱が枯渇すること。例えばエンジニアリングへの情熱が以前より失われているとかそういったこと。枯渇させないためにも、休んだり、気分転換で別のことをやったり、別のことにフォーカスしてみたりすることが大事。

何かにフォーカスすることで情熱が生まれることもある。そして何かにフォーカスしないとなかなか情熱は生まれづらい。その結果として、エンジニアリングへの情熱が失われたとしても、他のことに情熱を持てればそれでも良いとも言える。中途半端に色々なことをこなすことに終始して、消耗してしまうのが巧くない。

自分の人生のリソースには限りがあり、やりたいことを全部やれないもどかしさを抱えながら生きる人も多い。私もそう。寧ろそういう人が幸せと言える。そういう中でフォーカスポイントを変化させながら情熱を持ち続けることが幸せに生きるコツなのだと思う。選択と集中である。

「選択と集中」における選択の重要性

「選択と集中」はよく言われる言葉で、集中・フォーカスすることの大事さはよく説かれるが、それと同じように選択できることも大事である。

歴史上の選択と集中の失敗例として、発展途上国が一部の一次産品に生産を集中した結果、余計貧困が進んだ、と言う話がある。いわゆるモノカルチャー経済である。選択し直せる選択肢を失って袋小路に入り込んでしまったという点が示唆的である。

人生でも事業でも、その時その時のフォーカスポイントを定めることはとても重要だが、それと同時に定期的に選択し直せるように選択肢を確保しておくことも非常に重要なのだ。

ソフトウェアエンジニアは人生において有力で魅力的な選択肢だと思う。私自身もそういう選択肢を常に持っていることは幸せだし、人生を充実させてくれるものだと確信している。万人に向いてるかどうかは分かりませんが、オススメです。

緩やかに変化し続けるソフトウェア

当ブログのRSSを全件配信するようにした。Perl製OSSの拙作ブログエンジンであるところのRiji側に手を入れた。ファイルサイズが大きくなるし、RSS分割を実装するのもめんどいので単純に直近30件配信にとどめていたが、今日日普通に1ファイルで全件配信して良いだろうと思い変更した。時代の流れで富豪的アプローチが許容される(?)よくある話。

ちなみに、全件配信しようと思ったきっかけは、ポッドキャスト「趣味でOSSをやっている者だ」を始めるにあたって、RebuildのRSSを観察したところ、全件配信しているのに気付いたので、じゃあいいか、となったというのがありました。

その昔の以下のnaoyaさんの19年前の記事で、RSS内に単独エントリの全文配信の是非について書かれているが、今や全件全文配信である。

RSSの全文配信をはじめました

Riji v1.1.1をリリースした

https://github.com/Songmu/p5-Riji/releases/tag/v1.1.1

ということで、実に2年10ヶ月ぶりのリリースとなった。最新のPerl 5.40.0で依存モジュールも最新化しても、ちゃんとテストもビルドも通るのが素晴らしい。Perlの後方互換を大事にする文化の賜物だと感じる。もちろんPerl自体の変化が緩やかになっていて、ライブラリの更新が活発にされることが減っているのも一因にあるとは思うけど。

Carmelとcpm導入して依存ロックした

https://github.com/Songmu/p5-Riji/pull/39

依存をバージョンロックしなくてもそんなに困っていなかったのだけど、ghcrに上げるコンテナビルドの再現性のために依存モジュールのバージョンをロックすることにした。令和だし。具体的には、Carmelを導入して、cpanfile.snapshotを作って、Dockerビルド時にはcpmでモジュールインストールするようにした。cpmがcpanfile.snapshotをちゃんと見てくれるので良かった。ちなみに、CPANに上げるtarballにはcpanfile.snapshotは含めないようにしている。

この辺のツールチェインがちゃんと動くのは嬉しい。このサイト構築に使っているコンテナもビルドし直せたので、まだまだ戦える。

緩やかに変化し続けること

ソフトウェアを数年放置してても、ちょっとメンテナンスすれば、ちゃんと最新に更新できるのは素晴らしい。Perlのエコシステム含めた変化が遅くなって、追随しやすくなっているという側面はあるが、Perl自体は毎年更新されて新バージョンがリリースされているので進化は止まっていない。

最近ソフトウェアの変化の速度について思うところがある。変化し続けることは必須だが、速すぎる変化はソフトウェアの寿命を縮めてしまうのではないか、当事者が燃え尽きやすくなってしまったり、追随できない人を振るい落としすぎてしまうのではないか、そんなことである。着実に変化・進化し続けられるラインを模索する必要がある。

Perlの使用をもはや積極的に勧めるものではないが、このRijiのように、普段は塩漬けにしておいて、数年に一回くらいお手入れをするくらいで使い続けられる、そんなソフトウェアもあって良いと思っている。

R2を同期するr2syncというツールをRustで書いてcrate公開した

https://crates.io/crates/r2sync

コマンドラインツールであり以下でインストールできる。

$ brew install Songmu/tap/r2sync
# or
$ cargo install r2sync

これはローカルディレクトリの中身をCloudflare R2に簡易的に同期するごく単純なツールで以下のように使う。

$ r2sync ./dir r2://your-bucket/path

リモートに同一ファイルが存在する場合にputをスキップするようになっていて、それが欲しくて作った。ちなみに、--public-domain というオプションを付けると、同一ファイルチェックを公開URL経由で行うようになってAPIアクセスを減らせる。

$ r2sync --public-domain files.example.com ./dir r2://your-bucket/path

ファイルの同一性チェックは、Content-LengthとETagを見ている。S3やR2はETagがコンテンツのMD5ハッシュ値なので、それで同一性チェックをしている。この挙動が未来永劫担保されるかわからないが、単にContent-Lengthだけ見るのも嫌だったし、実際にContent-Lengthだけ主に見ている aws s3 sync がたまにハマるという話も聞くのでそうした。

GitHub Actions

カスタムアクションも公開していて、以下のように使える。oss4.funでも導入した。

- uses: Songmu/r2sync@v0
  with:
    r2_account_id: ${{ secrets.R2_ACCOUNT_ID }}
    r2_access_key_id: ${{ secrets.R2_ACCESS_KEY_ID }}
    r2_secret_access_key: ${{ secrets.R2_SECRET_ACCESS_KEY }}
    src: ./audio
    dest: r2://<your-bucket>/audio
    public_domain: files.example.com

作った動機

ポッドキャストの音声ファイルのアップロードをGitHub Actionsでやっているが、ディレクトリ内の全部の音声ファイルを毎回素朴にputしていたので流石に富豪すぎるので解決しようと考えたのが契機。

案外、既存の良いツールが見つけられなかったのと、aws s3 sync を使っても良かったのだけど、前述のETagの話もあったし、せっかくR2はエグレス料金が無料なのだからファイルの同一性チェックを公開URL経由でおこなうアイデアを盛り込んで作った。

Rust

習作がてらちょっとしたものをRustで作ってみたいと思っていたので、ちょうどよい題材だった。strとStringの使い分けとか、unwrapを使いすぎだったりとかまだまだお作法が分からない部分が多いが、とりあえずcrate公開までいけたのは良かった。Resultとかパターンマッチ含めた言語自体の書き味はかなり良い。

思っていたよりクロスビルド周りが難しくて、各プラットフォームにバイナリを提供するのに手こずった。とりあえず、GitHub Actions上で作るのは一旦断念して手元でバイナリをビルドしてGitHub Releasesにghrでアップロードするという一昔前のスタイルでお茶を濁した。

Rustを書き始めるにあたって「Rustの練習帳」が参考になった。Rustの考え方やコマンドラインツール作成について実践を通して学べる点で有益だった。Goでもこういう本があると良さそう(すでにあるかも)、とか思った。

Rustの練習帳 ―コマンドラインツールの作成を通してRustを学ぶ
著者 : Ken Youens-Clark
オライリー・ジャパン
発売日 : 2024-01-18
ブクログでレビューを見る»