Fujiwara Tech Conference 2025に行ってきた
Table of Contents
先日Fujiwara Tech Conference 2025という、実質@fujiwaraさんのファンミーティングがあったので参加してきた。
張り切りすぎて開場30分前に着いたのは内緒。
思い出 #
fujiwaraさんとはカヤックの同僚・先輩エンジニアとして10年以上の付き合いがある。 自分の入社が2010年(新卒)、fujiwaraさんが2011年(中途)の入社だったので、在籍期間は同じくらい。 もちろんエンジニアとしてのスキル・キャリアともにfujiwaraさんのほうが32枚くらいウワテで、 特に自分が自社サービスを担当するようになってからはお世話になりっぱなしだった。
当然fujiwara-ware(当時はそんな呼称もなかった)は馴染みが深く、 殊デプロイに関してはそれらのツール無しでの運用はやったことがないと言っても過言ではない。
mirage-ecs1で起動しknockrdでアクセス制限した開発環境でQAする。 ecspressoとlambrollでアプリケーションをデプロイする。 ecspressoで使うTask Definitionに実リソースの値を埋め込むためにtfstate-lookupで参照する。 異常終了したコンテナのログをtracerで取得してSlackに通知する。 maprobeやsardine、 cloudwatch-to-mackerelでメトリクスを収集する。 rinでRedshiftに取り込んだログを集計する。
まさに空気のように毎日当たり前に使っていたので、今回のイベントに100人近くの人が集まってくれたことは、自分事のようにうれしかった。
トーク #
現在に戻って、トークのはなし。
終始「わかる〜」「それな〜」という感想を持ちながら聞いていた。 極端な汎用性があるわけではなく、解決したい課題が明確なツールの話なので、共感できる部分しかなかった。
特に@mackee_wさんの 「課題があるから解決策であるツールが生まれる」「課題(具象)と解決策(抽象)を行き来する」という話は共感度が高かった。 fujiwara-waraは課題をいい感じに切り出してツールとして実装する、その精度が高い。 UNIX哲学のように一つのことをうまくやるのとはまた違って、それらのツールを組み合わせて一つの課題をうまく解決する。 @aerealさんのトークにあった「djb-wareとの類似性」という解釈は言いえて妙だった。
トークに対する質問が少なかったのも、課題とそれを解決する方法が会場内で共有されていたからなのではないか。 決して内容が面白くなかったわけではないし、当たり前の話題でつまらなくかったわけでもない。 ツールを使う状況や応用方法に発見があったうえで、「わかる〜」という反応になっていたように思う。 質問ではない、同意のリアクションをとる方法があるとよかったかも2。
LT #
急に自分が出てきてびっくりした。
転職活動をする中で「いまカヤックにいます」という話をすると「fujiwaraさんがいるところですよね」と言われることが何度かあった。 fujiwaraさんに気軽に相談したりレビューしてもらったりできる環境をわざわざ離れる必要があるのだろうかと悩んだ末の転職だったので、 自分が転職を伝えたタイミングでfujiwaraさんの転職を知ることになって複雑な気持ちになったことを覚えている。
次回もあるらしい #
カヤックの現役メンバーはもちろん、昔在籍していたメンバーも参加していて、半分同窓会のようになっていた。
ちなみに今回のイベント名にある「2025」は、「2026」が開催されることを示唆しているとのこと。
ありがとうございました。次回が楽しみ #fujiwara_tech_conf
— NAGATA Hiroaki (@handlename) January 17, 2025
また来年も会いましょう。
-
これは@acidlemonさんが原作のアプリケーションではあるが、最近のコミットはほぼほぼfujiwaraさん。 fujiwara-ware advent calendar 2024でも取り扱われている。 ↩︎
-
Conva Liveとか、CommentScreenとか。 ↩︎