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

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

最近、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
ブクログでレビューを見る»

「趣味でOSSをやっている者だ」というポッドキャストを始めた

最近御存知の通り(?)ポッドキャストづいていて、ポッドキャストについて色々調べてサイト構築ツールなどを作っていたが、ツールを作ったらやはり使いたくなってポッドキャストを始めてみることにした。

以前アナウンスした拙作のポッドキャスト生成OSSのPodbardの実例を示す場にもしたかったので、運営リポジトリも公開している。是非参考にしてみてください。一応、同期しているprivateリポジトリもあって、そのあたりの仕組みは別途解説するかも。

更新頻度はあまり考えてないけど、月に数本、できれば毎週、30分程度のエピソードを出したいと思っている。第2回目までは録り終わっていて今週公開予定。ゲストも次の次まで決まっているので一応しばらく続くと思いたい。

名前の由来

お気付きの通り、ワンパンマンの有名なセリフ「趣味でヒーローをやっている者だ」のオマージュ。力が抜けつつも強そうで良い。

このセリフの英訳が I'm just a guy who’s a hero for fun. らしいので、ポッドキャストの英題も "Just a guy who develops OSS for fun." として、そこからサイトのドメインやハッシュタグを決めた次第。#oss4fun です。よろしく。思いがけず"ossan"に空目した、という意見もあって、なるほど、となった。

ドメインは取るつもり無かったのだけど、空いていたし、短くて気に入ったので取得した。funドメイン、割とお安めで良かった。

購読お待ちしています

少し話してしまったが、ポッドキャストについてはポッドキャスト内で話せればと思うので、ここではこれくらいにしておきます。もう少しノウハウ溜まってきたら、それはそれでエントリを書くかも知れない。

まずは購読してもらえると嬉しいですが、上記のハッシュタグかお便りフォーム(https://oss4.fun/voice)で感想や要望などいただけると更に大変嬉しいです。何も考えてないけど、上記リポジトリのDiscussionsとかに何か投稿してもらえるとだいぶ面白いと思うのでチャレンジャー求む。

おまけ

独自YAMLファイルをJSON SchemaでLSP補完する

Podbardはpodbard.yamlに設定を記述するが、これをエディタで補完したりヒントを出せたりするようにした。

yaml-language-serverとJSON Schema

普段vimで開発してて、GitHub ActionsのYAMLを触ってるときなどに、エディタが適切にヒントを出してくれるのを便利に感じつつ「多分LSPがうまいことやってくれてるんだろうな」くらいに考えて深く追いかけていなかった。これは、JSON Schemaで実現されていることを、今回podbard.yamlの仕様をJSON Schemaで記述している過程で発見した。

GitHub ActionsのJSON Schemaは https://json.schemastore.org/github-action.jsonやhttps://json.schemastore.org/github-workflow.json で公開されており、YAMLファイルを編集するときに、yaml-language-serverが、それをいい感じに読み込んで支援してくれる。LSPなので当然VSCodeやその他エディタでも利用できる。

JSON Schema Store

このいい感じにスキーマを読み込むための、世界共通のスキーマ類を管理しているのが、JSON Schema Storeというサイト。ここで、https://raw.githubusercontent.com/SchemaStore/schemastore/master/src/api/json/catalog.jsonという大きなJSONファイルが公開されており、どういったファイルがどのスキーマに対応するか、という情報が記述されている。以下はGitHub ActionsのWorkflowの例。

{
  "name": "GitHub Workflow",
  "description": "YAML GitHub Workflow",
  "fileMatch": [
    "**/.github/workflows/*.yml",
    "**/.github/workflows/*.yaml",
    "**/.gitea/workflows/*.yml",
    "**/.gitea/workflows/*.yaml",
    "**/.forgejo/workflows/*.yml",
    "**/.forgejo/workflows/*.yaml"
  ],
  "url": "https://json.schemastore.org/github-workflow.json"
}

yaml-language-server に yaml.schemaStore.enable という設定があり、これがtrueだとこのサイトから自動でスキーマを引っ張ってきてくれる。デフォルトでtrue。

独自のJSON Schema

もちろん独自のJSON Schema設定も記述できる。README.mdに詳細に書かれているが、 主に、yaml.schemas 設定と、YAMLファイル内にモードラインコメントを記述する方法がある。モードラインコメントは、プロジェクトのリポジトリ内で、チームメンバーに共通でスキーマを読み込んでもらいたい場合に重宝しそうです。これは至極単純で、YAMLファイル内に以下のようなコメントを記述するだけです。

# yaml-language-server: $schema=<urlToTheSchema>

$schema に指定する文字列は公開URL、絶対・相対パス形式、いずれも可能です。ちなみに、JSON Schemaは本来JSONで記述しますが、YAMLで記述したものを直接読み込ませることも可能でした。

今回のPodbardの場合、以下のコメントを書けばLSPの支援が効くようになった。GitHubのrawコンテンツを指定するだけでお手軽。

# yaml-language-server: $schema=https://raw.githubusercontent.com/Songmu/podbard/main/schema.yaml

JSON Schema Storeへの登録

さて、今回のPodbardの場合、できればモードラインコメントせずとも補完が効くようにしたい。これは https://github.com/SchemaStore/schemastore の catalog.json を編集してpull requestを送れば良いようだ。

しかし、ここにマイナーOSSの設定ファイルのスキーマを登録するのは少し気後れする。そこで、直近のpull requestをいくつか観察してみると、割と個人レベルでのOSSであっても、快く迅速に取り込んでくれている様子だったので、以下のpull requestを送ったら半日程度でシュッとマージしてくれてありがたかった。

https://github.com/SchemaStore/schemastore/pull/4091

{
  "name": "podbard.yaml",
  "description": "Configuration file for Podbard - a podcast site generator",
  "fileMatch": ["podbard.yaml"],
  "url": "https://raw.githubusercontent.com/Songmu/pokkdbard/main/schema.yaml"
}

変更内容は上記で、スキーマのURLにyamlを直接指定する暴挙にでているが、すでに登録されている設定でもYAMLを直接しているものもあったので、いけるかな思って恐る恐るpull requestを出してみたが取り込んでもらえた。まあ、podbard.yamlはYAMLでしか設定ファイルを提供するつもりは無いので、スキーマもYAMLで良いでしょというところ。

vim-lsp-settingsへの対応

これはおまけだが、大変お世話になっているvim-lsp-settingsでは、上記のJSON Schema Storeのcatalog.json をリポジトリ内に同期して保持し、それを読み込むようになっている。yaml-language-serverは前述の通り、実はJSON Schema Storeを直接見に行くようになっていたので対応不要だったが、このスキーマ情報は当然 json-languageserverやその他LSPでも使われるものなので、更新しておく価値はある。ということで以下のpull requestで取り込んでもらった。

https://github.com/mattn/vim-lsp-settings/pull/774

この記事で書いたように、このcatalog.jsonは結構カジュアルに更新されるものなので、自動更新の仕組みが入っても良いとも思ったが、そこまではやらなかった。

まとめ

YAML設定ファイルに対してJSON Schemaを書いておくことで簡単にエディタの支援が効くようになるのは、今更の話かもしれないが、かなりお役立ち情報だった。

また、JSON Schema Storeへの登録は割と気軽にできることが分かったのも収穫だった。当然節度は必要だが、皆さんも機会があれば自作OSS等定義した有用なスキーマを登録してみてはいかがだろうか。

Podbardというポッドキャストサイト構築ツールを作った

https://github.com/Songmu/podbard

結果としてできたものはyattecastとHugoの間の子のようなモノになった。音声ファイルとそれに対応するエピソードファイルをfrontmatter付きのMarkdownで記述する。最終的に静的サイトとしてポッドキャストサイトを生成する。

podbard-starterというテンプレートリポジトリがあるので、ここからリポジトリを作ればすぐにポッドキャストサイトを作成できる。このテンプレートはGitHub Pagesにデプロイするモノだが、Cloudflare Pagesにデプロイする、podbard-cloudflare-starterや、それを応用してプライベートプッドキャストを構築する、podbard-private-podcast-starterというのも用意している。

まだ不十分だがドキュメントも以下に用意してある。このドキュメントサイトもPodbardを使ってドッグフーディングしているのがおもしろポイント。ドキュメントをOpenAIのText to speechに読み上げさせたものを音声としている。

https://junkyard.song.mu/podbard/

作った動機

ポッドキャストはブログの拡張技術なので、そもそも作りたいと思っていた。発想はyattecastとほとんど同じだが、社内ポッドキャスト構築にあたって、GitHub Page以外にも簡単にデプロイできることや、音声ファイルをS3やR2などのオブジェクトストレージに分離するアプローチを取りやすくしている。

今だったら、Cloudflare Pagesにコンテンツを配置して、Cloudflare R2に音声ファイルを置くのが個人で始めるにはお手軽のおすすめ構成。

ブログとポッドキャスト

古いWebエンジニアであれば、ポッドキャストがブログの拡張から始まったことは知っている人は多いと思う。ブログの各エントリに音声ファイルを添付する、技術的にはブログのRSSの各itemにenclosure要素というものを追加し、そこに音声ファイルのURLを指定しておくだけでポッドキャストになる。例えばこんな具合。

<?xml version="1.0" encoding="UTF-8"?>
<rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom" xmlns:itunes="http://www.itunes.com/dtds/podcast-1.0.dtd">
  <channel>
    <title>Podcast Title</title>
    <link>https://example.com</link>
    <language>en-us</language>
    <description>This is a sample podcast description.</description>
    <item>
      <title>Episode 1 Title</title>
      <description>This is a description of episode 1.</description>
      <link>https://example.com/episode1</link>
      <guid>https://example.com/episode1</guid>
      <pubDate>Mon, 01 Jan 2024 00:00:00 GMT</pubDate>
      <enclosure url="https://example.com/episode1.mp3" length="12345678" type="audio/mpeg"/>
    </item>
  </channel>
</rss>

ポッドキャストは、オープンで枯れた規格であり、それは今も変わらない。なので、ブログ同様に専用サービスを利用せずとも、個人でサイト運営を始められる気軽な選択肢があって欲しい。ポッドキャストはそういうIndieな活動でもあるからだ。

専用サービスを使わずともポッドキャストができることはもっと知られて欲しいし、少なくともRSSを配信していないサービスがポッドキャストとか言われてしまうのはちょっと勘弁、という気持ちがある。

そういう思いや、単なる技術的興味、そして必要にかられたのにかこつけて、カッとなって作ったのがこのPodbard。

Podbardの由来など

当初は音声ファイル一覧からRSSを生成するだけのシンプルなものを考えていたが、やっぱり音声のメタ情報を書く場所が必要だと言うことに気づき、それをfrontmatter付きのMarkdownにするのが良かろうという考えに至った。結果としてyattecastと同じ発想に至っていた。

また、私は当ブログのエンジンであるRijiの開発や、はてなブログ管理ツールであるblogsyncのメンテナをしていていたりもするので、「またブログツールを作ってるな…」みたいな気持ちにもなった。

Podbardは、ポッドキャストのPodと吟遊詩人のbardを掛け合わせた言葉。色々候補名は考えたが、類似の名前も使われてなさそうだったんでこれにした。少し中世の雰囲気を出したかったので良かったと思う。今調べていて気づいたけど、GoogleのGeminiの旧称がBardでしたね。

今回名前候補を考える壁打ちだったり、starterのデフォルトCSSものベース作成などでChat GPTを活用した。あと、アイキャッチイラストもImageFX に出力してもらうなど、生成AIを活用した。音声読み上げにText to speechを使った話も冒頭に書いたが、こういう個人サービス開発でAIツールがかなり便利に活用できることを感じた開発だった。

Cloudflare PagesにそれなりにちゃんとBasic認証をかける

前回の、社内プライベートポッドキャスト実現方法で、ポッドキャストサイトを静的配信しつつBasic認証をかけるというアイデアを書いた。しかし、Basic認証などなかなか使わなくなり、ネイティブでサポートしている静的ホスティングサービスも少ない。今回はCloudflare PagesのFunctions機能でリクエストをラップするミドルウェアを書けば実現できることが分かり、その方式を採用することにした。多少実装必要になるのと、認証周りを自前で書くのはあまりやりたくはないが、廉価に比較的省力で実現できるので受け入れる。

ネット上にいくつかサンプルは見つかるが、今回実装するにあたっては以下の点を留意した。

これらを以下のように解決することとした。

ちなみに、定数時間比較については、サボって普通の文字列比較をしていたら、同僚が指摘をしてくれた。持つべきものは優秀な同僚である。やはりこういう処理は自分では書きたくないですね。定数時間比較は、Node.jsにもcrypto.timingSafeEqual が標準搭載なので便利な世の中になった。ところで、文字列の定数時間比較については10年前にも元同僚が、GitHubのWebhookの署名文字列の検証関連で指摘してくれたことも思い出したので昔から周囲に恵まれている。

ということで、作ったものが以下。これをプロジェクトリポジトリにfunctions/_middleware.ts として配置し、Cloudflare Pagesにデプロイすれば、Basic認証をかけてくれる。便利。これは、podbardのプライベートポッドキャストのテンプレートリポジトリでも公開している ものと同じなので、何か問題があれば指摘してもらえると嬉しいです。

// Created by Masayuki Matsuki (Songmu) on 2024-09-11
// Copyright © 2024 Masayuki Matsuki. Licensed under MIT.
//
// ref. https://developers.cloudflare.com/pages/functions/middleware/
// ref. https://developers.cloudflare.com/pages/functions/api-reference/#eventcontext
type EventContext = {
  request: Request;
  next: (input?: Request | string, init?: RequestInit) => Promise<Response>;
  env: {
    ASSETS: object;
    CF_PAGES: string;
    CF_PAGES_BRANCH: string;
    CF_PAGES_COMMIT_SHA: string;
    CF_PAGES_URL: string;
    [key: string]: any;
  };
};

type Middleware = (context: EventContext) => Promise<Response>;

type Middlewares = Middleware | Middleware[];

const errorHandler: Middleware = async ({ next }: EventContext):
  try {
    return await next();
  } catch (err: unknown) {
    console.log(`Error: ${err.message}\n${err.stack}`);
    return new Response("Internal Server Error. Please contact the admin", { status: 500 });
  }
};

const passEnvPrefix = "PASSWORD_";

const basicAuth: Middleware = async ({ request, next, env }: EventContext): Promise<Response> => {
  if (!request.headers.has("Authorization")) {
    return new Response("You need to login.", {
      status: 401,
      headers: {
        "WWW-Authenticate": 'Basic realm="Input username and password"',
      },
    });
  }
  const authorizationHeader = request.headers.get("Authorization");
  if (!authorizationHeader) {
    return new Response("Authorization header is missing.", {
      status: 400,
    });
  }

  const [scheme, encoded] = authorizationHeader.split(" ");
  if (!encoded || scheme !== "Basic") {
    return new Response("Malformed authorization header.", {
      status: 400,
    });
  }

  const buffer = Uint8Array.from(atob(encoded), (character) => character.charCodeAt(0));
  const decoded = new TextDecoder().decode(buffer).normalize();
  const index = decoded.indexOf(":");

  if (index === -1 || /[\0-\x1F\x7F]/.test(decoded)) {
    return new Response("Invalid authorization value.", {
      status: 400,
    });
  }

  const username = decoded.substring(0, index);
  const password = decoded.substring(index + 1);
  if (password === "") {
    return new Response("Password is empty.", {
      status: 401,
    });
  }

  const key = passEnvPrefix + username.toUpperCase();
  const storedPassword = env[key];
  const userExists = typeof storedPassword === "string";
  // Even if the user does not exist, a constant time comparison with a dummy string is performed
  // to prevent timing attacks.
  const matchPassword = await compareStrings(password, userExists ? storedPassword : "dummy");
  if (!userExists || !matchPassword) {
    return new Response("Invalid username or password.", {
      status: 401,
    });
  }

  return await next();
};

async function sha256(str: string): Promise<ArrayBuffer> {
  const encoder = new TextEncoder();
  const data = encoder.encode(str);
  return crypto.subtle.digest("SHA-256", data);
}

async function compareStrings(a: string, b: string): Promise<boolean> {
  const hashA = await sha256(a);
  const hashB = await sha256(b);

  // The buffer lengths must be the same, and they were aligned to the same length by hashing,
  // but we are checking to be sure because timeSafeEqual will throw an exception if the lengths
  // are different.
  // ref. https://developers.cloudflare.com/workers/examples/protect-against-timing-attacks/
  if (hashA.byteLength !== hashB.byteLength) {
    return false;
  }
  // ref. https://developers.cloudflare.com/workers/examples/protect-against-timing-attacks/
  return crypto.subtle.timingSafeEqual(hashA, hashB);
}

export const onRequest: Middlewares = [errorHandler, basicAuth];

社内プライベートポッドキャスト実現方法

所属している、ヘンリー社には、社内ラジオコンテンツがあり、Notion上に音声ファイルを置く形で実現されている。これを、ポッドキャスト化してポッドキャストクライアントで聞きたいというのが動機。ちゃんとしたオープンな規格としてのポッドキャストにしたい。

もちろん、公開はせずプライベートなものにしたい。ただ、ポッドキャストはオープンコンテンツ前提の規格になっているため完全な実現は難しい。認証のかかっていないRSSフィード及び、そのRSSフィードに埋め込まれたMP3等の音声ファイルにも認証がかかっていないことが前提となるからだ。

やるからには、あまりコストを掛けずに静的配信をベースにしたい。お手軽なプライベートポッドキャストサービスもあまりないようだ。

基本方針

それに対する現実的な妥当解を考え、その実現のために、まずポッドキャストサイトを生成するpodbardというOSSを作った。そして、それを使って、簡単にプライベートポッドキャストを開始できる、podbard-private-podcast-starterというテンプレートリポジトリも公開した。これは、コンテンツをCloudflare Pagesに、音声ファイルをR2にdeployする仕組みになっている。外部サービスを使わず、自前でポッドキャストサイトを生成するものだ。

podbardやこのCloudflareを利用したこのテンプレートに関して別途解説するが、ここでは、実験結果も踏まえ、プライベートポッドキャストの実現方法を解説する。完全にプライベートにするのは難しいが、多重に防御することで実現しようとしている。具体的には以下。ちなみに、上記のテンプレートはこれら対策がすべて盛り込まれている。

これで、よっぽどの機密情報が話されているとかではなければ、実用上は十分プライベートと言えるのではないだろうか。代表的な動画配信サイトのプライベート動画であっても、実は生の動画URLを入手できればダウンロード可能だったりする。ちなみに、GitHubのアップロード画像は、ちゃんと認証がかかるようになりましたね。

Spotifyにもプライベートポッドキャストの機能があるようだが、「プライベートRSSフィード」という言葉があるので、概ね似たような仕組みになっているのではないかと思う。Basic認証は使ってない気はするが。

さて、防御方法についてそれぞれ解説していく。

推測しづらいURLにする

例えば、以下のような具合。

FQDN(ホスト名)は平文DNSから漏れる可能性があるが、パスをランダム文字列にすればhttpsであればテクニカルにはURLが判明する可能性は低い。

Basic認証をかける

冒頭に「認証はかけられない」と書いたが、HTTPに備わっているステートレスな認証方式であるBasic認証はかけられる。これによって、URLが漏洩しても直ちに影響はないし、ユーザー毎に異なるパスワードも設定できるので退職時等の失効も可能。

ちなみに、Basic認証は以下のように認証情報をURLに含められる。この文字列が漏洩してしまうと、クリック一発でコンテンツにアクセスできてしまうので注意。

https://username:p4ssw0rd@mypodcast.example.com/{random-path}/feed.xml

この完全なフィードURLをポッドキャストアプリに登録してやれば、ポッドキャストの購読ができる。もしくは、認証情報を含まないURLであっても、認証情報を聞かれるダイアログが開いたのでそれに入力すれば購読できる。iPhoneのポッドキャストアプリや、私が使っているOvercast では、いずれの方法でも購読が確認できた。

クローラーを避ける

検索エンジンのクローラーを避け、余計なインデックス登録をブロックする。robots.txtを配置する。HTMLにはmetaタグを記述すればよいが、HTML以外のコンテンツのインデックス登録を防ぐために、HTTPヘッダも付与できると良い。

robots.txt

User-Agent: *
Disallow: /

参考:

リファラでのURL漏洩を防ぐ

Show Note上のリンクなど、外部サイト遷移時のリファラによるURL漏洩は避けたい。とは言え、現代のブラウザのリファラポリシーは基本的にはstrict-origin-when-cross-originになっており、外部遷移時の漏洩は実はそこまで気にする必要はない。URLのパスは漏洩せず、FQDNが渡るだけである。平文DNSがまだ多い現時点では、FQDNは漏れうるものだという前提に立った方が良い。

とは言え、要らぬ情報が外部に渡ることは避けたいだろうので、その場合はクローラー避け同様に、メタタグ及び可能ならHTTPヘッダにリファラポリシーを設定すると良い。

ポリシーはno-referrer でもよいが、同一オリジン内であれば、リファラがわたっても問題ないし、寧ろ遷移元情報が分かったほうが良いという話もあるので、same-originが良いのではないでしょうか。

参考:

音声ファイルに認証をかけないことについて

そもそも、サイトコンテンツは静的に書き出してBasic認証をかぶせる、音声は何らかのオブジェクトストレージにアップロードする、というのがお手軽なのでそうしたかった。

音声ファイルにもBasic認証をかけ、RSS内の音声ファイルのURLを https://username:p4ssw0rd@audiobucket.mypodcast.example.com/{random-path}/foo.mp3 のように、認証情報を含めた記述にするというのも機能するのかも知れないが(未検証)、その場合、RSSフィードをユーザーごとに動的配信したり、全ユーザー分書き出すなどの対応が必要になるので、やらないことにした。

何にせよ、せいぜいBasic認証しかかけられないし、それでも結局、完全なURL文字列が漏れたら、一発でアクセス可能なので、あまりリスク軽減になっていないというのもある。なので、オブジェクトストレージのバケットのルートにrobots.txtを置いておくくらいの対策に留めた。

まとめ

ということで、プライベートポッドキャスト実現方法について書いてみた。ご意見あればフィードバックいただけると嬉しいです。

また、podbard及び、podbard-private-podcast-starterは一応使い始められるようになっている。テンプレートリポジトリについては、そこから新たにリポジトリを作れば、すぐにこのページで解説した方法でのプライベートポッドキャストが実現できるようになっている。

使い方などは追って解説エントリを書きますが、是非試してみてほしいし、わからないことがあれば聞いてくれればできる限り回答したいので、ぜひお試しください。

Macでオンラインミーティング中に電球を点ける

夏休みに入って、子供たちが仕事部屋に乱入してくることが増えた。何番煎じかわからないが、オンラインミーティングが始まったら電気を点ける仕組みを作って投入した。カメラがついている時にミーティング中だという判定をしてライトを点灯する。概要は以下。

私以外にこの仕組みを使う人がいるとは思わないが、以下の手順で導入できる。

カメラのon/off検知

yoshioriさんがLinuxで同じようなことをやっているが、カメラの利用検知はMacだと案外難しい。そこで、カメラやマイクのon/offを検知してくれるOverSightというソフトウェアをインストールして利用する。これ自体危険性を孕むソフトウェアだが、そういう不正なカメラやマイク利用を検知するためのソフトウェアであり、ソースもGitHub上で公開されている。

検知をトリガーにプログラムを実行する

このOverSight、カメラやマイクのon/offのイベントを通知してくれるだけではなく、そのイベントをトリガーにしてプログラムを実行できる。

今回、その仕組みに乗っかってライトを制御するためにGoで作ったのが github.com/Songmu/mtglight 。これを適当なところに配置して、OverSightの設定画面から以下のようにしていする。ここでは直接していせずに .sh を指定しているが、これはシェルスクリプトでラップしているため。排他制御が気にならなければ別に直接しても良い。

この画面に示されているように、プログラムにはいくつかのコマンドライン引数が渡される。このコマンドライン引数を見ることで、イベントの種類やデバイスの状態を判断できる。

-device に cameraかmicrophone、-event に onかoff、-activeCount にアクティブなデバイス利用数の合算値が渡される。合算値というのはカメラとマイクの合計で、複数のオンラインミーティングを開いているときなどに複数プロセスからデバイスが利用されている場合には、その延べカウントになる。カメラとマイクの合算値になるのは少し使い勝手が悪い。

ちなみに、この -process という引数はデバイス呼び出し元のPIDが取れるので、そのプロセスの死活監視をすればミーティング開催中判定ができるのではないかと期待したが、その用途には使えなかった。このプロセスはオンラインMTG自体のプロセスではなく、デバイス管理プロセスかなにか別のプロセスであり、ミーティング終了後も基本的には生存し続けていたからだ。

今回、一番気になるのがカメラなので、cameraのonイベントが送られてきた時に点灯するようにした。また、ライトを消灯するのは、cameraのoffイベントが送られてきたときではなく、activeCountが0になった時に消灯するようにした。これは、cameraのoffイベントが通知されたとしても、別のウィンドウではまだカメラが使われている可能性があるからである。activeCountが0であればマイクも含めてすべてのデバイスがoffになったということなので、消灯してもよかろうという判断。また、これによって、MTG中に一時的にカメラをoffにしても消灯されてしまうこともない。

プログラムからIoTライトを操作する

プログラムからは Yeelight の電球を操作している。前項の mtglight のソースコードを読むとわかるが、同一ネットワークにつながったYeelightの電球を探し、黄色を最大輝度で決め打ちで点灯するようにしている。なので、自宅の外のネットワークに繋いだ時に、そこでYeelightが使われていたら勝手に操作してしまうかもしれない😎

操作するのは何でも良くて、yoshioriさんがやっているようにスマートプラグを使うのは自由度が高くて良いと思う。 mtglight でそのあたり抽象化しても良いかと思ったが、別にそこまでするまでもないと思ったのでやっていない。

多重実行を防ぐ排他制御をしこむ

mtglight はOverSightからイベントドリブンで呼び出されるため、多重起動される可能性がある。そこをちゃんと排他に直列で実行されるようにしたい。そこで setlock を使う。

setlock はバッチの多重起動を防ぐための古式ゆかしいコマンド。daemontoolsに同梱されており、MacでもHomebrewをお使いであれば、 brew install daemontools でインストールできる。Homebrewを使っていない場合、頑張って自分でビルドするか、moznionさんが作ったGo製の go-setlock があるのでそれを使っても良いかもしれない。

このsetlockを使って以下のようなシェルスクリプトをmtglightが配置されたディレクトリに配置する。これでこのスクリプトが多重で呼び出された場合であっても、mtglight は多重起動されず、別プロセスの終了を待って、直列で実行されるようになる。便利。

#!/bin/sh
cd $(dirname $0)
exec /opt/homebrew/bin/setlock ./mtglight.lock ./mtglight "$@"

まとめ

Yeelightはともかく、OverSightを使ってデバイスのon/offを検知するのと、それによってプログラムをトリガーして、排他制御にsetlockを使う、というのは応用が効くと思うので、他の方も是非試してみてほしい。

builderscon 2024に行って代打登壇もしてきた

復活のbuilderscon 2024に行ってきた。プロポーザル出して落ちており、チケット買うのも失念していたのだけど、大吉祥寺.pmでnasa9084さんから「実はあまり宣伝もして無いんですけどチケット売り切れそうなんですよね」みたいな話を聞いてその場で焦ってチケットを買った、ということがあった。その時に近くを通りがかった稲尾さんに声をかけてチケットを買わせるなどもした。

なので、今回は気楽に聴衆として参加予定だった。そうしたら前日夕方に、nasa9084 さんから「登壇者が一人急遽参加ができなくなりそうで、可能なら代打してくれないか」という連絡があった。なかなかないケースではあるが、そこに面白みも感じたし、お声がけは嬉しく引き受けることにした。登壇者が個人都合により登壇できなくなるということは確率的には起きうることで仕方がない。とは言え、シングルトラックのカンファレンスはこういう時に大変だな、とは思った。

今回元々出していたプロポーザルは、YAPC::Hiroshimaで話した内容をベースに、もう少し技術に踏み込んだ話にする予定だった。IndieWeb、Fediverse、Activity Pubなどについて調べて解説し実際に自分のWebサイトに組み込む、みたいなことをしたかったのだが、流石に前日では間に合わず、YAPC::Hiroshima以降のアップデートや、IndieWeb関連の話をした。

https://junkyard.song.mu/slides/builderscon-2024/#0

代打登壇ではあるが、buildersconに登壇できたのは本当に嬉しかった。これまでも今回も圧倒的な発表ばかりで「本物のbuilder」しか登壇できない、自分なぞが登壇して良いカンファレンスではない、位に思っていたが(でもプロポーザルは出していたわけだけど)、登壇できると素直に嬉しいものでした。

復活のbuildersconは参加者全員の熱量が高くて良かった。参加率もとても高く、部屋も埋まっていた。さっきシングルトラックのリスクについて書いたけど、逆に一つの部屋で皆で同じ話を聞くという体験が、一体感や密度の高いコミュニケーションにつながっていたように感じる。登壇後の質疑応答タイムに全トークでめっちゃ活発に質問が出てすごかった。

buildersconには、その「知らなかった、を聞く」というテーマにふさわしい、ノージャンルの技術トークを聞く楽しさはもちろんのこと、何より、そのbuildersconというカンファレンス名に「私たちは作り手なのだ」というメッセージが込められているように感じて、勝手にエモいと思っている。

今回のrebootは良かったので、今後もどういう形であれ、こういう熱量のある登壇者と、熱量がある聴衆の会が続いてくれることを願います。