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

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

所属している、ヘンリー社には、社内ラジオコンテンツがあり、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は良かったので、今後もどういう形であれ、こういう熱量のある登壇者と、熱量がある聴衆の会が続いてくれることを願います。

HonoとCloudflare Pagesでプロフィールサイト兼短縮URLサービスを構築した

関連: NFCタグ入りの自己紹介アイコンバッジを自作する

song.mu という結構良い短いドメインを確保しているので、これをプロフィールサイト兼、個人用短縮URLサービスにしたいと長らく思っていたので重い腰を上げて作った。

最近オフラインイベントが増えている中で、こういうプロフィールサイトを活用しているケースを見るようになったのがきっかけ。Webエンジニアとしてはこういうの自作したいし、自分のドメインでホストしたいと思っていたのだ。

song.mu がリンクが並んだプロフィールページで、 song.mu/blog でブログに飛び、 song.mu/x でTwitterに飛ぶ、みたいな具合。

技術スタック

こういうの作る時は興味がある技術の砂場にしたいので、HonoでSSGしてCloudflare Pagesでホストしている。ローカル開発でのTypeScript実行環境も mise で管理するようにして、ランタイムもBunを採用した。

当初はCloudflare Workersを使う想定だったが、別にリダイレクトするだけだったら、_redirects ファイルを生成するだけで良いということに気づいたのでPagesを使うことにした。短縮URL登録も別に動的に登録する仕組みを作らないで、設定を記述してサイトをデプロイすれば反映されるようにすればいいとは元々思っていた。以下のような build.ts を書いてサイトと_redirects ファイルを書き出している。

import { toSSG } from "hono/bun";
import app from "./src/index";
import { urls } from "./src/urls";

const comment = "# The following lines are generated by build.ts.\n";

const redirects = Object.entries(urls)
  .map(([key, site]) => `${key} ${site.url} 301`)
  .join("\n");

await Bun.write("static/_redirects", comment + redirects + "\n");

toSSG(app);

別にサイトのソースコードも公開しても良いと思っていたのだが、一部秘密にしておきたいURLも含まれてしまったので非公開にせざるを得なくなってしまった。

Hono

Honoは良かった。テンプレートがJSXで普通に書けるし、css HelperでCSSも普通に書けて、既存のフロント開発と同じ雰囲気で書ける。vim-jsx-prettyとかvim-styled-componentsでちゃんとシンタックスハイライトが利くのが嬉しい。

あと、Vite Plugins for Honoでvite使って開発できるのが良くて、高速なホットリロード体験が快適だった。

この辺、元々は標準APIのみ使うところからスタートしていたり、既存のエコシステムにうまく相乗りするように作られているところがセンスの良さを感じた。

Bun

Bunも良かった。速くて快適。コマンド体系的にも bun と bunx コマンドのみでランタイムやパッケージマネージャーが備える一通りの操作をおこなえるのは明確。既存のコマンドに対するDrop in Replacementとして動くのがわかりやすい。

Cloudflare Pages

以前、このサイトを引っ越した時に利用を検討したのだけど，断念することになって残念だったので、今回使えて良かった。Cloudflareの管理画面からGitHubの連携設定が簡単で、すぐデプロイできるのはお手軽で良い。ただ、GitHubへの広い読み取り権限を渡してしまうので、GitHub Actionsでdeployする方法に変更するほうが安全で、柔軟にもなるので、そのうち切り替えたい。

ちなみに、Cloudflareの環境上でBunを使うためには、環境変数 BUN_VERSION を指定すればbunコマンドを利用できるようになる。

ref. https://developers.cloudflare.com/pages/configuration/language-support-and-tools/

ちなみに、ドキュメントはされていないが、asdfの .tool-versions を見てくれるという話もあるようで、ドキュメントされてほしいし、この記事に書いてあるようにmise.tomlもサポートされてほしい。

再現性の無い多様なキャリアの前例があることに価値がある

大吉祥寺.pmの前夜祭「生存者バイアスナイト」で話してきた。

https://junkyard.song.mu/slides/survivor-bias-night/#0

同年代の優秀なエンジニアの方から「自分のキャリアは再現性が無いから他人の参考にならない」という話をよく聞く。果たしてそうだろうか。私はそういう人たちにもっと自分の経験の話をしてもらいたいと常々思っていた。

彼らは「思い込みの結果として上手く行った」「単に運が良かった」「だから普遍的なノウハウにならない」そんなふうに自覚している。だから、そんな普遍的ではないノウハウを偉そうに声高に話したがらないし、ましてや、それを押し付けるような老害的振る舞いになることを恐れているようにも見える。そういう謙虚なスタンスは好ましくも思う。

でも実際は一つ一つの経験には大きな意味がある。普遍的ではないかも知れないが、それでも話してみると、自分が思っている以上に多くの人の参考になったり、勇気づけられたりするものだ。むしろ、キャリアの進み方が普遍的な一本道に収束せず、多様な生き方があることに価値があり、業界に持続性がもたらされるのだ。

だから「生存者バイアスだから」とか「再現性がないから」とかそういう理由で経験を話さないままでいてほしくない。人間は、誰もがバイアスまみれで勘違いしながら生きている。それでも、そういう経験に価値がないわけではないのだ。

そういう課題意識もあって話したのがこのトークだ。私としては、自分がバイアスまみれであることを前提に置き、それをなるべくメタ認知しようと心がけることで、時にはその認知を上手く活用できるし、同時に自分の成功体験を他人に過度に押し付けるような老害化問題を緩和できる。そのように思っている。

人に「べき論」を押し付けず、自分の心躍った体験や思いを話せば誰かの参考になるかも知れないし、参考にしてもらえると嬉しい。それが、あまり人を傷つけない、伝わりやすい発信になるとも思っている。もちろん100%人を傷つけない発信など無いのだが。

人間はバイアスから完全に解脱することは難しいし、残念ながら私も無自覚な差別を色々していると思う。それでも自分の中の多くのバイアスから自由になり、差別を減らしたい。差別が少なく、より多くの人が幸せに生きられる世の中であって欲しいと思う。そっちのほうが自分も安心して生きられるからだ。

というキレイめなトークをしてきた。会の趣旨としては「自分はこういう経験をしたから生き残ったのじゃ、ガッハッハ」みたいなオフレコトークが期待されていた部分もあったようで、確かにキレイな話にしすぎたかもしれないと少し反省。そういう話も機会があればしてみたい。

ちなみに、大吉祥寺.pmの懇親会で「インターネット上で自分の過激な発言に起因して炎上した人がインターネットに文句言うのおかしくてインターネットが下手くそなだけじゃん。僕は大きな炎上したこと無いし」とか可燃性の高そうな発言をしてたんだけど、onkさんに「Songmuさんが炎上してないの運が良いだけですよ」って突っ込まれて、これは完全に生存者バイアスの話でしたね。

NFCタグ入りの自己紹介アイコンバッジを自作する

このバッジにスマホをかざすと、song.mu という自己紹介サイトに飛べるようにした。バッジにはNFCタグが仕込まれている。最近よくあるやつ。

缶バッジだとNFCタグが読み込めない罠

最近は自己紹介グッズとして、pixivFACTORY でアイコン缶バッジを作るのが、lacolaco手法として知られている。私も持っています。

参考: 自分のアイコンの缶バッジを作ると便利

しかし、缶バッジは金属製なのでNFCタグをくっつけても読めません。なので、こういう素人手作り感満載のグッズを作ることにしたのでした。ちなみに、pixivFACTORYはアクリルキーホルダーも作れるのでそれを活用しても良さそうです。

NFCタグシール

やったことは簡単で、以下のNFCタグシールを買って、NFC Tools でURLを書き込んでロックするだけ。

サンワサプライ NFCタグ(10枚入り) NXP NTAG213 ホワイト MM-NFCT
著者 :
サンワサプライ(Sanwa Supply)
発売日 :
ブクログでレビューを見る»

バッジどうするか

コンビニで光沢紙にカラープリントして丸く切ったやつの裏にNFCのシールを貼り付けて、以下のバッジの中に挟み込むだけ。

44mmサイズ

バッジ自体は44mmだが、中に入れる紙は直径41mmで切り出した。切り出しグッズも買った。

S.fields.inc アクリルブローチ 30個 透明バッジ 缶バッジ フォトバッジ ピンバッジ 手作りDIY 写真 (44ｍｍ)
著者 :
発売日 :
ブクログでレビューを見る»
エヌティー カッター 円切りカッター エコ 替刃付き 黒 eC-1500P
著者 :
エヌティー
発売日 :
ブクログでレビューを見る»

54mmサイズ

もう少し大きいサイズだとハメパチというものがあった。これも上の円切りカッターで切り出しても良いが、専用のパンチを使うのもお手軽そうだ。

[大王製作所]オリジナルバッジ ハメパチ バッジ 記念品 ハンドメイド 手作りバッジ 推し入れ 丸型 BM54 CAX-M54A 1個入 透明
著者 :
発売日 :
ブクログでレビューを見る»
ハメパチ クラフトパンチ 3L 丸型54mmφ用
著者 :
ダイキ
発売日 :
ブクログでレビューを見る»

まとめ

ということで自己紹介グッズを作ったのだった。興味ある方は是非真似してください。大吉祥寺.pmに持っていく予定なので実物興味ある方はお声がけください。

自己紹介サイトの song.mu はBunとHonoとCloudflare Pagesで作ったのだけどその話はまた別途。

ちなみに、Amazonのアソシエイトの画像が廃止になっていたのをスルーしていたのだけど、今回ブクログを使ってアフィリエイトタグを生成した。便利。個人サイトだと現実的な開放になりそう。API使って自作の仕組みを作りたいけど、その辺は追々。

新車を買って体験した最近のロードバイク事情

ロードバイクを新たに一台買った。久しぶりに外でのサイクリングを楽しんでいる。

新車はCannondaleのSuperSix Evo 3べースにホイールをMavicのKSYRIUM SLにアップグレードした。KSYRIUM大好き。

町田のたかだフレンドに10年以上ぶりに顔を出して組んでもらった。ORBEAのORCAが欲しかったのだが、扱いがなかったので勧められたこのバイクにした。信頼できるショップに組んでもらうことが大事。Cannondaleも僕がロードレース見ていた頃のSaecoチームの印象もあるし、このバイクも今どきのバイクにしてはそこまでゴツすぎないのも良かった。

ローラー台生活

コロナ禍始まった頃、健康への危機意識からローラー台を買って、部屋で毎日のようにロードバイクを漕ぎ出した。数年続けた結果、パフォーマンスが上がって、興が乗ってヒルクライムレースにでも出るかとなって、そのためにレース用に１台買うか、となったのがきっかけ。

このローラー台に固定しているやつは20年前に買ったやつで、時間的には十分長く乗った。今から20年後となると僕はもう60歳を越えている。まだ肉体的なパフォーマンスが辛うじて維持できているうちに、もう一台買ってもよかろうという判断。結果として今は部屋に3台ロードバイクがある。

今どきのロードバイク

正直あまり新しいロードバイクを買いたいとは思っていなかった。今どきのロードバイクの進化の方向性があまり好みではなく、それなのに異常に値上がっているというのが大きかった。いかにも懐古主義的な意見である。

上の青いバイクは、当時の最高グレードのフレーム、パーツ、ホイールで揃えたものだが、それでもトータル50万円台くらい。それを今同じグレードで揃えようとすると150万円位かかってしまう。今、50万円では当時から数段階グレードが落ちたバイクしか買えないのである。

今どきは見た目もゴツい。エアロ形状のためかもしれないが、スマートさに欠けて見えてしまう。ただ、僕がロードに乗り始めた20年前とかも「最近のバイクはフレームが太すぎる」と言われていたので、自分が乗り始めた頃のバイクが一番カッコよく見えてしまうという刷り込みみたいなものだとは思う。

あと、電動変速。これは心理的に受け入れるのには抵抗があった。とはいえ、プロ選手は全員電動変速を使っている状況だし、不可逆の変化として受け入れることにした。トレンドに抗っても仕方がないという大人の諦念。

電動変速に限らず、その他の面でも自分でメンテナンスするのではなくショップにお任せするのが強く推奨される流れになってきている。最終的には自分でほぼ全部メンテナンスできて然るべきだと考えて自転車いじりを楽しんでいた身からするとブラックボックスが増えてしまうのは少し寂しい。車の修理権的な話。とは言え、とんでもない速度でかっ飛んでいく乗り物なのだからプロにメンテナンスを任せるのは至極真っ当ではある。実際、多くのパーツがメンテナンスフリーになってトラブル率も減っているはず。

ということで、今回のバイク購入にあたっては、変に過渡期のものを買っても仕方がないと考え、最新のテクノロジーを積極的に導入することにした。具体的には、コンポーネントをSHIMANO 新型105 Di2にしてワイヤレス電動変速と油圧ディスクブレーキを導入し、ホイールをチューブレスレディにすることは狙っていた。

その辺りを満たせるものを買えたので良かった。結局70万くらいかかって当初の予算はオーバーしたが、妻には「もっと高いの買うのかと思ってた」とか言われた。良くわかっていらっしゃる。

気になる重量は8.3kg。元のバイクは8kgジャストだったので、重くなっている…。まあ、誤差の範囲内で、走りは良くなっていると思いたい。実際乗ってて快適なので満足はしている。

実際に買って、乗ってみると色々と時代の変化も感じられて面白い。ざっと書き出すだけでも以下のような新しい体験や知見があった。

YAPC::Hiroshimaの安心感と進化に感動した話

だいぶ時間が経ってしまいましたが、YAPC::Hiroshimaで「Blogを作り、育み、慈しむ ~ Blog Hacks 2024」というタイトルでトークをしてきた。

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

YAPC::Hiroshimaのテーマが "what you like" ということで、Blogについて話す機会となったのは良かった。いつもながらとっ散らかってしまったが、それなりに面白い話はできたんじゃないかと思う。昼イチのセッションで同時刻の別トラックのスピーカーが強力だったので、まあそんなに聴衆来なくても逆に気楽に話せるから良いか、位に考えていたけど、思った以上に聞きに来てくださったし、質問も出て嬉しかった。ありがとうございました。

ありがたいことにログミーTechで書き起こしていただいた。

IndieWeb周りはもう少し調べたかった。この辺はもう少し調べるなりしてbuildersconのプロポーザルを出そうと思っている。

書籍 Blog Hacks

トークタイトルはもちろん、miyagawaさんとnaoyaさんが代表著者の書籍、Blog Hacksにちなんだものだ。この本はBlogいじりの楽しさについても書かれた本であるが、それが2024年だとどうなるのかについて話したかったというのがある。この本は2004の本でなんとちょうど20年前の本なのだ。

広島にはBlog Hacksの書籍を持っていったが、前夜最後に941さん幹事の飲み会に混ぜてもらい、そこで著者のお二人からサインを貰うことができた。941さんもノリノリでサインの儀を執り行ってくださってありがたかった。

翌日の懇親会で「miyagawaさんとnaoyaさんと写真写ってた人ですよね？」とか若い人に話しかけられたりして面白かった。YAPC初参加とのことだったがRebuild.fmでmiyagawaさんとnaoyaさんは知っていたとのこと。若い人にリーチしていてすごい。

参加者448名！

旧交を温められて同窓会感がありつつも、若い人も多く、約半数が初参加ということで驚いた。

正直、地方開催するPerlの技術カンファレンスにこんなに人が集まると思っておらす、これは、完全に見くびっていた。所属のヘンリー社でのスポンサーも打診されていたのだが、僕の個人的な趣味でスポンサーする感じになると嫌だなと思ったこともあって見送っていたが、完全にこれは費用対効果あったし、ちゃんと情熱稟議を出すべきであった。これはPerl、YAPC好きとして慙愧の念に耐えない。

BASEのCTO川口(id:dmnlk)さんが「カンファレンススポンサーのススメ」というスポンサーLTで、初参加のYAPCながら、ちゃんとスポンサー稟議を通した話をしていて、完全に尊敬です。

何にせよ、これだけ盛り上がったのは、運営の努力の賜物であり素晴らしかった。

トークのごった煮感

Perlのイベントと言いつつ、いつも通りの全体的なトークのごった煮感は良かった。マネジメントの話・技術的にコアな話・事業の固有ドメインの解説とその実装の話など、ここまでトークが多様なカンファレンスもなかなか無い。ちゃんと毎回Perlのアップデートの話があるし、その他Perlの話があるのも良いですね。

個人的には「awkでつくってわかる、Webアプリケーション」が面白かった。

意外な旧交

とにかく旧交を温められたし、コロナ禍中にオンラインで知り合った人とも会えたりしてよかった。

意外な邂逅だとSugamo.cssの主催者だった、 Sig.さんと会えたのはめっちゃ良かった。今は広島に住んでいたこともあり参加したとのことで、僕のことも探して話に来てくれた。これは嬉しかった。

懇親会でも話して、お互いロードバイク乗りなので、一緒に自転車のヒルクライムイベントに出る話になり、ツールド美ヶ原に申し込んだ。実は、知らなかったが、前日の2/9(金)から丁度、富士ヒルのエントリーが始まっており、Sigさんは申し込んだということだったので、そっちに一緒に出るかという話もしていたのだが、その日の夜は既に申し込みを締め切っていた。富士ヒル恐るべし。

Sugamo.cssは実は僕が初めて深く交流した技術コミュニティなので思い入れがある。

杜甫々さんキーノート

参加者全員が何度も言っていることだが、とほほさんのトークはとにかく素晴らしかった。

これも誰もが言っているように、最後の「なぜ発信を続けられているのか？」という質疑に対して、「好きだから」という回答がでてきたのはすごかった。"what you like"がテーマのYAPCを締めくくるにふさわしかった。

僕も「好きだから発信を続けられている」というトークをしたので、完全にその上位互換の発表を目の当たりにして、ショックを受けつつもしびれました。

kobakenさんのクロージング

最後のkobakenさんの締めも良かった。話す姿が堂に入っており、特にスポンサー社名を一つ一つ丁寧に読み上げて感謝を伝える部分の途中で「これちょっと手疲れるかもしれないんですけど、頑張ってみてください。53あります」とおもしろめかして参加者に拍手を促しながら笑いを取っていた部分でめちゃくちゃ感動してしまった。

彼のことは若い頃から知っているのですが、そのリーダー的振る舞いをみて「これはリーダーとして越えられたかもな」とか感慨にふけってしまった。そのリーダーシップがYAPC::Hiroshimaの成功の大きな一因でもあると感じる。

YAYAPC

そのkobakenさんが企画した、YAPCの翌日のアフターイベントのYAYAPC::Hiroshima ～オフラインだからできる話〜も盛り上がって良かった。僕も、スタートアップとSOについての話をしてきました。内容は非公開です。

その後、てっぺん回るまで飲み明かしたのでした。

次回のYAPC::Hakodate 2024も楽しみにしています。

ISUCON13 カラアゲネイティブチーム 15位

近年ISUCON出場のBlogを書いていませんでしたが、一応毎年出場はしていました。ISUCON9は本戦が娘の運動会と被っていたため、予選を一人チームで出て当然惨敗した。それ以降、ISUCON10, 11, 12, 13は、motemen, toricls(トリ)と「カラアゲネイティブ」というチーム名で出場している。馬が合うメンツなので楽しく参加している。

ISUCON10は予選突破ならず。ISUCON11は予選突破できそうだったが次点1位で本戦出場を逃す。これはもう、ふらりと当日参戦するスタイルはやめてISUCON12は流石にちゃんと対策しようということになり、初めて事前のチーム練習を実施したが、結局予選を突破できずであった。これは結構ショックが大きかった。

今回のISUCON13は同じメンツで参加はする話はしていたが、個人的にはあまりモチベーションは高くなかったのが実際のところだった。それに、トリさんがUS出張でフライトの時間が被っていて、後半からの参加になることになり、それもあって、ゆるく頑張るか、というチームの雰囲気だった。果たして、事前の打ち合わせすら全くせず本番を迎えたのであった。

競技開始

開始前にチームのDiscordで音声通話を繋げて、3人で会話。競技開始前にトリさんは飛行機に搭乗し一旦離脱。競技が開始され問題を見たら、DNSが組み込まれている新機軸で一気にテンションが上った。すわDNSサーバー自作か、とか思うなどしたが、そこは落ち着いて問題を見て対策を立てていった。

NginxからのICON配信

とりあえず、ICON配信が一つの関門ぽかったので、餅は餅屋ということで静的配信Nginxに任せ、1台目のサーバーからICONを配信することとした。conditional getがちゃんとできるかは定かではなかったが、Nginxならできるやろ、とか思っていたが、どうもそうではなかったらしい。とはいえ、NginxからICONを配信するようにしたらスコアは上がったので結果オーライである。後から振り返ると、今回はこういう、正答ではないが暫定対応がうまくハマってスコアが上がったケースが多く、運が良かった。

ただ、ここのNginxの設定に苦戦した。アイコン画像がない場合に NoImage.jpg を配信する必要があった。これは try_files ディレクティブを使えばイケるやろ、と思っていたが、ここでは alias と error_page ディレクティブを組み合わせる必要があった。これに異常に時間を取られてしまったのは痛恨。

昼過ぎに、フライトを終えたトリさんがホテルから参加。長年チームを組んでいることもあって特に説明無くキャッチアップしてくれたのは良かった。

複数台構成

とりあえず、PowerDNSで使っているMySQLの負荷がいかんともしがたかったので、アプリケーション用のDBは3台目のサーバーに移すこととした。ついでにGoのアプリケーションも1台目と2台目に動かして分散するようにした。2台目のサーバーは必要になったらRedisも同居させる想定。実際この前後でRedisをmotemenが立ててくれた。どのサーバーにどのミドルウェアを置くかといった構成案はチームで既定路線の慣れた動きになっていて、阿吽の呼吸になっているのは楽。

あとは、encoding/jsonをgoccy/go-jsonに差し替え。毎年やっているので、以下の置換ワンライナーがシェル履歴から呼び出せて笑ってしまった。

$ perl -i -pe 's{"encoding/json"}{"github.com/goccy/go-json"}g' **/*.go

競技開始当初はバタついたが、トリさんも競技開始して、細かい改善も色々入りスコアとしてはこの時点で3万超えくらい。安定的に10位前後に位置取りできるようになってきた。TOP3辺りで、ヘンリー同僚のataganが参加している「都営三田線東急目黒線直通急行日吉行」チームが奮闘しており、励みになった。

しかし、ここもPowerDNSの負荷に向き合うのではなく、適当に負荷分散したら凌げた、という話なのでうまく噛み合った感がある。最終的な構成は以下。

10万点超えと終戦

後は水責め攻撃に対する抜本的な改善は諦めて、Redisに置けるデータはRedisに置くようにしたり、N+1を潰したり、複数台の負荷分散の調整などの作業を各自で実施して地道にスコアを上げていった。ここで、Go 1.21で入った新機能である sync.OnceValue を使えたのが個人的に少し嬉しかった。

今回は、再起動試験もちゃんと実施できたのは良かった。レギュレーションを読むと競技中の最終計測が競技スコアとなるようだったため、再起動後にスコア計測を何度か行い、105,751を提出スコアとした。

TOP10に入れるかと期待していたが、結果としては15位だった。まあ、カラアゲネイティブチームとしては最も良い成績を挙げられたので良し。

反省

カラアゲネイティブでチームを組むのが4回目で、勝手知ったる感じがあってやりやすかった。お互いがやってることをうまく把握し合いながらうまく戦えて楽しかった。

ただ、運が良く噛み合った感もある。本丸のDNS水責め攻撃は特にこれといった対処はしなかったし、ICONのconditional getもそう。何れも暫定対応がそこそこうまくいってしまった。

カラアゲネイティブのメンバーはスキルセットが似通っているので、やりやすさはある反面、技術領域のカバレッジがそこまで高くない所に課題がある。特に、インフラ面の弱さ。そんじょそこらのインフラエンジニアには負けないとは思うが、ウー馬場イーツチームとかと比べると差は感じる。PowerDNSに無抵抗だったのも結局そこが課題。

なので、このメンツでの伸びしろを感じづらくなってきているが、組んでて楽しいメンバーなので今後も機会があるなら出場を続けていきたい。4年間でチーム内でのノウハウも溜まってきているので、その辺りは別途アプトプットできればと思う。

今回も素晴らしい大会運営ありがとうございました。毎回、次回のISUCON開催が心配されますが、今回は特に不透明な状況かと思います。個人的にはISUCONには大変お世話になったので色々思いがあります。多くのOSS、技術カンファレンスやイベントが、実はすごく不安定ながら継続している儚いものであるということが改めて思い起こされます。インターネット自身がそうであるように。だからこそ、尊いものでもあるし、エンジニア個人としても興味を持ったらその時点ですぐに参加してみるのが大事です。もちろん継続性に向き合っていかないといけないものもありますが。ただ、いつまでも続くように見えているものが、あっけなく終わるということは、全然珍しいことではありません。

参考

静的サイトをFediverseに対応させる

当サイトをFediverseに対応させました。 @songmu.jp@songmu.jp でMastodonなどでリモートフォローできます。

やったことは、 このブログがFediverseに対応しました というtyageさんのエントリーをそのままなぞっただけです。このエントリーはh-cardのサイトトップへの掲出に関する説明が書き漏れていそうでしたが、それも実施しました。

当サイトは静的サイトであり、付随機能は外部サービスに頼りたいと考えている。例えば、コメント機能はDisqusを使っている。Fediverseに関しても何かそういうサービスがないかと思っていたが、Bridge Fedというサービスがあり、上記のエントリー内で懇切丁寧に解説されていたので導入は比較的簡単で、作業時間は小一時間でできた。大まかな手順は以下。

  1. Bridgy Fed というサービスを利用してサイトをFediverseに対応させる
    1. "/.well-known/host-meta"と"/.well-known/webfinger"を Bridgy Fed にリダイレクトする
    2. Bridge Fedが当サイトのコンテンツを解析できるように、htmlテンプレートにmicroformatのクラスをいくつか足す
      • h-card, h-content, e-entry等
  2. サイト更新時にBridgy Fedに通知する
    • 投稿記事のURLをAPI投稿
      • curl一行でいける
      • GitHub Actionsに仕込む
  3. webmention.io との連携
    • これは追加対応なのでやらなくてもいいが、単に <link rel="webmention" href="https://webmention.io/blog.tyage.net/webmention" /> と言ったタグを仕込むだけなのでやると良い
    • Webmentionは記事への反応や言及を通知するプロトコル
      • 現代版Trackbackとも言える存在で、2017年W3C勧告
    • Webmentionが実装されたサイトがwebmention.io
    • webmention.ioへのログインの仕組みがindieloginというやつで、例えば <a href="https://github.com/Songmu" rel="me">github.com/Songmu</a> というタグをトップページに仕込んでおけばGitHubログインできる(他のログイン方法も選べる)というもので、面白かった。

当サイトは、Rijiという自作のPerl製の静的サイトジェネレーターで生成したHTMLをFirebase Hostingで配信しています。

やっぱこういう個人サイト弄り楽しいよね、と言う話を来週の YAPC::Hiroshima 2024で「Blogを作り、育み、慈しむ - Blog Hacks 2024」というタイトルで話す のでご興味ある方はぜひ聞きに来てください！