Elm-jp 2023でelm-pagesについて話したことなど

タイトル通りだが、Elm-jp 2023でelm-pagesの基本的な概念について話した。

https://zenn.dev/ymtszw/articles/elm-pages-v2-in-action

イベントは同僚の@y047akaがファシリテーションを頑張ってくれて、 小規模会場ではあったが久々のオフライン開催、オンライン配信も対応、雑談もありで楽しかった。参加者としては満足である。

ところで、会社役員になったことも関連して、最近は技術イベント主催者側の物事も気にかかるようになった。

小規模オフライン技術イベントなら会場費用をスポンサーするくらいは全くやぶさかでないんだが、 結局いい感じの会場を見つけたり、当日ロジ要員を確保したり、オンライン配信をやるための準備をしたり、 イベントファシリテータはやることが多い。それが数十名規模以上のものともなれば一大事だ。

コロナ禍以前から色んな会社が会場提供している技術イベントにカジュアルに顔を出していたが、 振り返ってみると会場提供ができるような会社はそれだけで実は貴重だし、協力人員も手配してくれているなら更にありがたい。 （Siiiboは2022年末に日本橋兜町に引っ越してちょっとオフィスが広くなったが、20名前後オフライン参加のイベントを開けるようなスペースはなく、 会場提供したくてもできず、げに歯がゆいことよ。）

また、会場や費用が企業スポンサーされるとしても、（企業の会場であれば）実際現場では時間外に有志社員が駆り出される。 イベント主催側にその企業の社員がいるのであればまだしも、そのイベントに直接興味のない社員であれば、純粋なヘルプ業務だ。 もちろん、採用広報・技術広報活動という名目のもとに手当を出すことも正当化できるかもしれないが、 たとえそこまでサポートされたとしても最終的に人間が業務時間外に拘束されることにはかわりない。

特定企業の好意に依存しないようにするにはイベント主催を委員会化してコミュニティメンバー有志で作業分担する方向性に進んでいくのだろうが、 それはそれで有志組織の構築維持や恒常的なメンバー募集という一種のサークル活動が必要になる。

そして万難排してイベント開催の体制は整えたとしても、結局有意義な発表や議論を提供できる参加者が一定数揃わないことには意味がないという大前提。

なかなか技術イベント開催を維持し続けるのは難しいということが改めて感じられたのだった。

発表の補足

発表後の質疑応答で、実際elm-pages (v2)はstatic buildするときどのタイミングでHTML生成を打ち切るのか、という質問があり、鋭いなと思った。

後に調べた範囲だと（調べきってはいないが）、

• ユーザが記述した内容の外側にelm-pagesが自動生成するコード（いわばelm-pagesランタイム）があり、
• その中でTEAの仕組みを利用して「ここまでで静的ビルドは完了」というmessageを飛ばし、
• それをPort経由でJS側に渡し、
• JS側のelm-pagesランタイムがそれを捕捉してビルド完了とする

といった流れになっているような気配は感じられた。SlackかDiscordでDillonさんに聞いてみようかな。

git管理Markdownファイルでの記事入稿

このサイトの記事は元々microCMSから入稿するようにJAMStack実装した。

https://ymtszw.cc/articles/elm-pages-and-headless-cms

ただ、Markdown記事入稿なら正直microCMS経由するよりgit管理のほうが楽というのがあり、発表後にちょっといじって対応した。この記事原稿もgit管理されている。

microCMSから降ってくる記事データ構造と合わせつつ、足りない情報はFrontmatter経由で注入して補うようにした。 もともとelm-pagesはFrontmatterつきMarkdownファイルで入稿することを想定したAPIが揃っているので、そんなに工夫していない。

mtimeなどローカルファイルのstatを読めるようDataSource.File.Extra.statを導入して情報をつなぎ込む布石も打った。 ビルドタイムPortでDataSourceを拡張できる設計は簡単便利で助かる。ただ、結局今回は利用しなかった。 （mtimeはファイル操作でカジュアルに書き換わってしまうので、記事内容の更新時刻を表現するのには向かない）