windyakin.net

Notion + Astro + Cloudflare Pages で作ったブログ

2026-04-29T00:00:00Z

Notion + Astro + Cloudflare Pages でブログをつくった。

note.windyakin.net

記事を公開する場所としては「ここ」もあるのだが、すべてを GitHub 上で管理していることもあって、どうしてもどっしり腰を据えて書くことが必要という感じになってきている。かといって Bluesky の文字量だと伝えきれないこともままあるので、今後は弊サイト、上記の新サイト、 Bluesky と3並行で更新していくことにする。

最初に公開したポストは読書の感想である。

読了「アフリカから来たランナーたち」

気づいたらうっかり記事っぽい分量を書いてしまったが、今後は気軽なメモ書きみたいなのも公開できるといいなあと考えている。メモ書き側の記事を清書してこっちに持ってくるということもあるかもしれない。更新頻度が増えるといいね。

そして今回のブログのためにつくったビルドシステムはこちらに公開しておく。既に似たような構成を自作する人は多く、 AI 時代にいまさら目新しさも何もないと思うのだが一応ね、一応。

windyakin/note

Cloudflare Worker で Notion API を叩いて、更新があれば Cloudflare Pages のビルドを行い、 Astro によって生成した静的サイトが公開されるという構成になっている。外部リンクの OGP にも対応したため、記事数が増えたらビルド時間が長くなってしまう可能性もあるのだが、今のところ致命的ではない。そういった問題は悩むほど記事が増えてから考えることにした。

元々この新サイトに公開する温度感の記事については、 note.com で公開するかと考えていたものの、最近あの場所の空気感が少し苦手になってきたこともあって、自作することにした。そしてその空気感のイメージが note という一般名詞に付くことに抗う意味もあって、リポジトリ名は windyakin/note としている。

note.com のアカウントのほうの記事は残しておくが、今後も更新はほとんどしないだろう。

XとYouTubeを見なくなって4ヶ月経った

2026-03-12T00:00:00Z

XとYouTubeを見なくなって4ヶ月ぐらい経った。

去年の11月ぐらい、多忙も重なったことで精神的にかなり辛い状態になってしまい、各方面に迷惑をかけてしまっていた。反省し、色々顧みた結果、今のXやYouTubeを見る生活によって蝕まれているものが多すぎるという結論になり、身の回りの環境を整理している。

結果として、自分の精神状態については悪くはない方向に進んでいると感じている。

各種サイトを見れなくし、注意を逸らすものを切る

かねてよりプライバシーの懸念から、 DNS over HTTPS を実現する NextDNS というサービスを使っていたのだが、これのペアレンタルコントロール機能や、拒否リストなどをつかうことで、特定のサイトを見れない環境を作り出している。 NextDNS は Android スマホもネイティブで対応しているので、スマホからも見れないし、 PC からもごく一部の回避方法を取らない限りは見れないようになった。

YouTube については、サイトそのものを見れなくなったものの、副作用として YouTube の動画を埋め込みしているサイトが世の中には多く存在し、それらが見れなくて不便することも多い（どうしても必要な場合については、 DNS over HTTPS を使わないブラウザで見ることはある）。

また、Xについては、完全にログアウト。各方面には今後連絡手段として使わないようアナウンスした。自分が運営する組織のアカウントから告知などを発信する必要がある場面については、委任アカウントを設定して、完全に人任せにすることで、義務的な場面で目にする必要もなくなった。

可処分時間の増加

ここからはこれらの選択の結果、起きたことを書いていく。

まず身の回りで起きた変化といえば、なによりも可処分時間が増えたことである。最近の YouTube の動画は1本あたり20〜30分とか、悪ければ1時間近いものが当たり前になってきていて、それが自動再生でダラダラと続くので、気づいたら1〜2時間はなくなっていることもあった。ただ動画を見なければそんなことは起きない。

一方でそれまでほぼ欠かさず見ていた様々なチャンネル共々見れなくなったので、最初は葛藤や寂しさも感じていたものの、そもそも見れなければ次第に興味も失っていくもので、現在ではあまり気にせずに生きている。

空いた時間で何しているかというと、買い漁った新書を読んだり、自作アプリのコードを書いたり書かせたりしている。「もうやること無いから寝る」みたいなことも多くて、そういえばコロナ禍前の自分の生活ってこんな感じだったよなと思うことがある。

スマホが「つまらないもの」になった

前は何かあればスマホでXやYouTubeをだらだら見ていたが、両者とも見れなくなくなった現在、たいしてやることがない機械となっている。通知のスマートウォッチ連動もやめ、スマートフォン自体に届く通知も極限まで減らし、気を逸らされないようにしている。

ただひとつだけ白状すると、唯一 Bluesky を見たり更新することは続けている。ただ、 X よりは圧倒的に流れが遅いものだし、知らない人間による感情を煽るポストも流れてこないので、かつての「Twitter」をしていた頃に戻ったような感覚で生きている。

スマホを「意識的に視界に入れない・届かない場所に置く」というのも心がけていて、これも非常にスマホ離れへの効果のある施策の一つだった。仕事するときはここ、ソファに座るときはここ、というように、視界に入らない・少し手を伸ばさないと届かない場所を定位置として運用することで、格段に手に取る機会が減ることがわかった。

情報メディアの変化

情報に関してもキャッチアップする場所を変える必要があった。 X が見れなくなっているので、最新の話題にはかなり疎くなっているというような感覚はある。そのため、ある程度は自分で拾いに行くことが重要となってくるのだが、これもなるべく無駄に感情を煽られないものを選択したい。

インターネットで見ているメディアは以下の通り。Feedly で購読しているものもあれば、適当に自分からアクセスする場合もある。

アニメ関連の情報については、個人的に追いかけていたコンテンツが一段落したこともあって、積極的な発信も少ない状態になっているのも大きい。たまに公式サイトを見たりもするようにしていて、そのときに自分から欲しかった情報に出会えると嬉しいものがある。 SNS でよく知らない人間を経由して持たされる一報より、自分から発信元に足を運び、そこで得られたほうが驚きも価値も大きい。

新聞を読むようになった

情報メディアの変化に関連して、特筆するべき点として、年明けから静岡新聞を購読しはじめたことも挙げておく。まあ以前静岡新聞社の協力を得て開催したイベントから、仲良くなったこともあって購読を始めてみたのだが、これがどういうわけかなかなかよかった。

先述の可処分時間についても、朝もそれなりに時間が取れるようになったので、始業前にコーヒーを飲みながらだったり、オフィスに出社する日は新幹線で読むというのが習慣になりつつある。

読み始めてからの変化としては、まず興味が沼津市だけではなく、静岡県全体に広がるようになった。県紙なので内容が沼津だけにとどまらないのは当たり前なのだが、今まであんまりきにしてこなかった中部・西部の話題も自然と目に入るようになって理解が深まりつつある。

もちろん静岡県以外の国際・国内の社会情勢についても報道されるし、どちらかといえばそういった話題のほうに接する機会が増えたのも気に入っている点のひとつだ。

今や新聞社はその旧態依然っぽさから「オールドメディア」として揶揄されることもあるが、PVを稼ぐために無駄に感情を煽る見出しや内容を書き連ねる無責任な「自認メディア」よりはよほど健全だと思う。

退化ではなく選択

かつて私がSNSやYouTubeに費やしていた時間は明らかに異常だった。それは、各ソーシャルメディアが様々な方法で人間の注意を惹き、滞在時間を増やし、広告収益を上げようと躍起になっているからだ。

あなたも自分が何に時間を差し出しているのか、一度立ち止まって考えてみてほしい。アルゴリズムはあなたの将来のことを考えてはくれていない。あなたの可処分時間を1秒でも多く奪うことだけを、最適化し続けている。

私もいきなりこの生活ができるようになったわけではなく、この4ヶ月間、色々な試行錯誤や失敗を経験して、今はなんとかこの形に落ち着いているというだけである。1ヶ月後にはアップデートされてまた変わっているかもしれないし、この試みそのものに失敗してまたSNS漬けの生活で心を痛めているかもしれない。これらはほぼ「依存症」との戦いと同じなのである。

もちろん全員に「新聞を読め」とか「SNSをやめろ」と言いたいわけではない。今回自分が選択した結果がたまたまそうだったから紹介したまでであるが、あなたは今の生活で問題ないと感じているだろうか。あなたが昨日スマホで費やした2時間で、何か一つでも、あなたの生活に残るものはあっただろうか。

現代の情報スピードについていかない選択をしたと言われてもしょうがない感じもある。自分でも「コーヒー飲みながら新聞読んでる」なんて、「ジジイかよ」と言われるような生活をしているのはわかっている。しかしながら、かつてのような情報の接し方は、生活を蝕み、精神的によくないことをもたらしていたのも事実だ。そこから逃れるためならば、これは「退化」ではなく「選択」なのである。

Twitterの報酬系を刺激する部分だけを取り出してウェブツール化した

2025-12-12T00:00:00Z

Twitter (X) をしてたときに、何が一番気になっていたかって考えると、やっぱり通知欄だった気がするんですよね。特に用事もないのに無限に開いては更新していた気がする。

だから、ツイートしてそれに通知が来さえすりゃいいんじゃないかと。そこに必ずしも他者という人間が介在する必要があるかというと、必ずしもそうではないのではないかと。知らん誰かなんてNPCみたいなもんじゃないですか。あくまで「数字」として受け取っているもののほうが多かったような気がするわけです。個人的には。

なのでそれだけを取り出したものを作ってみました。

https://modoki.windyakin.net/

何ができるのか

ツイートの投稿ができます。投稿したツイートはインターネットには送られず、内容はブラウザ内の localStorage と IndexedDB に保存されるようになっています。

投稿したポストには、定期的に誰かからのリアクションが自動でつくようになっています。頻度は適当ですが、一応設定から比重を選べるようにはなっています。

リアクションがつくと通知欄にバッジがついて、数字が増えるようになっています。開くと既読になって消える。

主だった機能はそれだけです。

個人的には、先述の通り、通知が来ることと、その通知の数字を消すこと無意識に繰り返していた節があり、実際使ってみていると、全然これだけで何十分と時間を消費できてしまうんですよね。

なのでこの通知欄の数字こそが「報酬系を刺激する部分」だったのだろうと思っています。もちろん人それぞれだとは思いますが。

Claude Code

コードはほとんど Claude Code に書いてもらいました。人間が介在したのは機能の提案とコンポーネントの設計がよくないときにそれを指摘するぐらい。

現状、コンポーネントで共通化させるには人間が言わないとしてくれない感じがします。ただ共通化したいのは人間の認知範囲に限界があるからというのが主だった理由で、コーディングエージェントだけが稼働している世界になったとき、彼らにとってはあんまり気にすることでもないのかもしれません。

各アイコンとかの SVG は Claude Code が勝手に作り出したんですが、あまりにもそのまんますぎるのも扱いに困りますね。

ロゴアイコンは最初本当にそのままの鳥が出てきたので、「オマージュ的なものにして」と指示を出したところ現状のものになりました。一応下側のふたつの円が胴体と羽と言い張ってるんですが、全然そうには見えません。溶けてる鳥かな？

この先

すぐ思いつくのは、タイムラインに LLM による他者を介在させたいというところですよね。何人かにこのツール見せたとき、だいたいそういう提案をもらいました。

ただ現状の「バックエンドが介在しない」というのがこのツールの利点でもあるので、あんまり実装に乗り気ではないです。 Chrome がブラウザから JavaScript で LLM を呼び出す API を実験機能として出しているっぽいので、そういうので解決できればいいですよね。

結論

インターネットをやめたい人におすすめです。

Aqours の Finale ライブへ行くために、ラブライブ！サンシャイン!!ラッピングバスの貸切運行をした

2025-06-25T00:00:00Z

バスを借りて会場入りした

今回貸し切り運行した富士急ラブライブ！サンシャイン!!ラッピングバス (E3408)

6月21日・22日に埼玉県のベルーナドームを会場に行われた、 Aqours Finale LoveLive! 〜永久stage〜の開催に合わせ、沼津から会場まで直行する貸切バス「【特急】永久stage」の運行を、沼津移住者コミュニティうみねこの主催として行った。

概要についてはうみねこのウェブサイトにも掲載しているので、そちらを見てほしい。

ラブライブ！サンシャイン!!ラッピングバスを貸し切ってAqoursのFinaleライブ会場に向かいました

本記事では、今回のバスの貸し切り運行に関する紆余曲折と、今後同じことをやる人が居たときのためになんとなくの知見を共有する。

会場入りできるバスを探せ

ライブの開催については1年ほど前から告知されていたことや、日程・場所の公開も去年の11月には発表されていたこともあり、昨年の12月には「Aqours のラッピングバスを借りて会場入りできないか」という模索が始まっていた。

うみねこのメンバーの中に、過去に伊豆箱根鉄道の HAPPY PARTY TRAIN 仕様の列車を貸し切り運行した経歴を持つ人がおり、その人が中心となって進めることになった。

「ラッピングバス」と一言で言っても、実は様々な種類が存在する。沼津駅や市内でよく見かけるのは、東海バスや伊豆箱根バスのいわゆる「路線バス」だが、路線バスは一般道での走行を前提として作られており、乗客用の座席にシートベルトなどが装備されていないため、貸し切ることができたとしても、それで会場まで向かうことは難しい。

これは路線バスなので高速道路は走れない

しかしながら、東海バス・富士急シティバスには、高速バスに Aqours ラッピングを施したものが存在する。

東海バスが所有しているラッピング高速バスは、普段バスタ新宿に乗り入れる路線に現役で供用されている。 Brightest Melody の衣装の9人と共に、「Aqoursは沼津にいます」というメッセージ性の強いバスだ。

富士急シティバスについては、2018年頃投入された車体で、かつて東京駅から沼津に直通する高速バス路線で使われていたのだが、コロナ禍以降その路線は休止状態となっており、最近では会社の通勤用送迎バスや、三島駅から河口湖を結ぶ路線に投入されている姿をよく目撃されている。

この2つの編成のどちらかが使えれば嬉しいのだが、一方で西武ライオンズの球場に西武グループの伊豆箱根の通常の観光バスで向かうのも、「浦の星女学院のPTAによる団体旅行」っぽくて味があるなということで、とにかく12月中には沼津でバスを運行している3社（東海バス・伊豆箱根バス・富士急シティバス）にコンタクトを取り、見積もりなどを集めることになった。

運行ルートと駐車場

運行ルートについては、距離はそこまでではないものの、「往復するかどうか」の問題があった。往復する場合については、まず帰りのバスが出発できる時間がいつになるのかが読めないという、この会場特有の問題があった。帰りに鉄道を使わない場合でも、基本的に規制退場による誘導がなされるので、終わる時間がなんとなくわかったとしても、なかなか「この時間までに集合」というのは難しい。

ベルーナドームは退場が難しい

また、ライブ中も乗務員を待機させることになるため、拘束時間が長くなること。そのために交代用の追加の乗務員が必要になること。沼津に到着する頃には日付を回ることから深夜労働手当などの割増料金が発生し、一人当たりの負担額もそれなりになってしまうことなど、様々な理由から復路についての運行は早々に諦めることとなった。

あと、諦めた理由のもう一つがバスの駐車場の問題である。ベルーナドーム周辺にはバスが停められるような場所はなく、基本的に各社とも運行を依頼する我々が駐車場を用意する必要があった。ただ唯一、西武傘下の伊豆箱根バスは駐車場を自身で確保してくれそうな返答に見えたのだが、それがグループの成せる技なのか、そもそも伝え忘れていただけなのか、真偽は不明である。

まあ、そもそも 2 DAYS 開催のライブなので、往復しても乗らない人も多いだろうということで、本運行の経路は往路（沼津→ベルーナドーム）のみ絞ることとなった。

富士急トラベルとの面談

問い合わせの結果、東海バスについては、貸し切りバスの運行はできるものの、ラッピング仕様車については、通常の運行路線への充当があるので難しいという回答であった。一方で富士急トラベル（富士急の旅行代理店）からは、二つ返事でOKという回答とともに見積もりが届いた。貸し切り運行の実績はあったのはなんとなく知ってはいたが、こうもあっさりできるとは。やってみるものである。

というわけで今回借りることとなった富士急シティバス保有のE3408

見積もりについては、経路を往路だけにしたことで、拘束時間も減り、ある程度の人数を集めさえすれば現実的な金額で返ってきたこともあり、富士急にお願いすることにした。

富士急でのバスの貸し切りは当団体としては初めて（というか私の人生としても初）だったので、挨拶も兼ねて直接オフィスに伺って担当の方と打ち合わせをした。担当してくださった方も、オタクの我々に優しいと言うか、移住者についても興味を持って聞いてくれるなどし、お互いに「それではよろしくお願いします」ということで、運行が決定した。

運行にあたっての募集

団体旅行において広く一般に参加者を募るためには、「旅行業法」によって、所定の管轄に登録が必要とされており、この登録がない個人や団体が勝手にSNS上で募集を行う行為はできない。

そのため、本貸し切り運行については「知り合い同士の団体旅行」、いわば自治会などで行われる団体旅行みたいなものという扱いにする必要があるため、運営スタッフの知り合いへ声をかけるのみに制限した。参加者への事前のSNSへの投稿も厳しく制限し、法への抵触や、当日の混乱を避けることにはとにかく気を使う必要があった。

結果、20名程度が集まり、まあ負担額も普通に電車で行くよりは高くなるものの、価値のある体験を得たいという人が集まったのはよかった。

沼津のめぐみ！いろどり弁当

今回、バスの運行は12時を回ることから、参加者には沼津駅の駅弁業者である桃中軒が販売している「沼津のめぐみ！いろどり弁当」の購入オプションを提供することにした。結果全員申し込んだので、オプションにした意味はあまりなかったのだが。というか駅弁ですらラブライブ！コラボがある当地よ。

（まさかこのパッケージ絵が伏線になるとは…。）

通常、桃中軒の弁当の注文は、本社工場にある外商部に行うよう案内されているのだが、電話するとどういうわけか「その弁当については沼津駅の売店から注文して貰う必要があります」と言われ、そのように対応した。

そもそもこの弁当は沼津駅でしか販売されておらず、土日祝しか販売されていないなど、おそらく桃中軒の内部でも特殊な立ち位置にいるのだろう。

受け取りに関しても、通常の大口注文では行ってくれる配達には対応していないとのことなので、駅南口の売店で直接受け取ることになった。売店の方の対応も親切で、売店は10時開店である一方で、我々の出発時間も10時だったため、弁当を待っての出発となる可能性もあったのだが、工場からの到着後すぐに引き渡していただくなど、色々と融通を効かせてくださった。また、何度か電話することがあったのだが、どなたが電話に出ても「21日にラブライブ！の弁当を20個注文している…」というと、「ああ！」と言ってくれたので、その後の話もスムーズだった（特殊すぎる客なのでわかりやすかったのだと思うが）。

LED行先表示器風のボード

#つくった

盛り上げのためというか、雰囲気作りとして、LED行先表示器風のボードを作った。

最初は Illustrator でそれっぽいものを作ろうと思ったのだが、LED行先表示器はいわゆるドット絵なので、 Illustrator の分野ではないかもしれないと思い、 AI と相談しながら、ブラウザで動くドット絵用のツールを作った。

なるべく本来のバスについている行先表示器と雰囲気を合わせるために、バスの写真からマトリックスのサイズをなんとなく揃えたり、永久stageの文字も単純な文字ではなく、ロゴを参考にするなどした。砂時計のイラストの中のドットは「9つ」にするなど、細かいこだわりポイントなどもある。

路線バスであればもっと解像度が高く自由が効くのだが、今回はかなり解像度低めで苦労した

これをコンビニで印刷し、余っていたスチレンボードにスプレーのりで貼り付けて完成。沼津に来て5年、物が増え続けた結果、だいたいの工作部品が自宅にある。

運行当日にこれを持っていったところ、結構喜ばれ、いろいろな人が写真を撮ってくれた。撮影会をしていると、運転手の人に「バスに貼り付けますか？」と言われ、停車中のバスにマスキングテープで貼り付けて撮影させてもらった。というか適当に作った割に、サイズぴったりすぎ。

貼り付けられたスチレンボードくんサイズぴったりすぎワロタ

出発、沼津と内浦を心に刻む

当日朝もなんとか大きなトラブルもなく、バスは沼津駅北口を出発する。

バスは一路、作品に登場する「浦の星女学院」のモデルとなった、長井崎小中一貫学校のある内浦へ向かった。途中、バスをみかけた子どもや、あげつち商店街にある商店の店主の方が気づいて手を降ってくれるなど、バスは終始和やかな雰囲気となった。

この日はいつにも増して本当に海がきれいだった

天候にも恵まれ、夏には珍しく、ちょうど富士山も顔を出してくれており、まさに作品で描かれた沼津や内浦を体感できる行程となり、非常によかった。

バスの車窓から淡島と富士山を望む

下車

そのまま、バスは伊豆縦貫道、東名高速をひた走り、会場となるベルーナドームへと向かった。特に大きな渋滞もなく、トイレ付、クーラーの効いた車内でそれぞれが思い思いに過ごす快適な旅路となった。

しかしながら、本運行における最大の難点はこれからである。それは下車場所の確保だった。

過去に参加した 6th SUNNY STAGE のときに会場周辺を歩いた際、接続道路の路側帯にパイロンが立てられていた記憶があり、事前に目星をつけていたバスが退避できる箇所も塞がれている可能性があった。そのため、下車場所の選定には入念な打ち合わせを行い、降りられなかった場合には、所沢駅のバスロータリーを利用するというプランBも用意していた。

会場前に着くとやはり路側帯にはパイロンが置かれており、予定していた場所での下車は叶わなかったのだが、運転手さんの機転によって、運良く近くに停車ぐらいならできそうな場所を見つけ、そこで乗客全員速やかに下車することにした。

バスを見送っている自分うれしそう

下車するときに、運転手さんが「あと何周すればいいですか？」と言ってくれたので、（何周でもするの！？）と思いつつ「追加でもう1周してきてください」と伝え、我々もベルーナドームの前を通るバスを写真に納めることができた。そもそもこの運行自体がオタクのわがままに付き合っていただいているというだけにもかかわらず、運転手さんのサービス精神も豊富だった。大変ありがたい。

会場前道路はファミリーマートの待機列などもあり、注目度は抜群

結果、予定していた15時より大幅に早い14時には会場に無事到着でき、バスも回送して帰ったことを確認して、会場入りをXでポストした。

【特急】永久stage 🚍️
本日、有志一同で富士急シティバス様所有のAqoursラッピングバスをお借りして、沼津駅から出発し、無事ベルーナドームに到着いたしました🚌
本企画にご協力いただいた皆様、ありがとうございました。
#Aqours_finale_Day1 #特急永久stage

https://x.com/umineco_nmz/status/1936310571143663924

感想

今回の Finale ライブでは、オープニングで沼津駅やあげつち商店街、内浦の景色が描かれており、まさに今回のバスでやってきた経路と同じものを見ることができており、ライブの没入度を高めることができて本当にいい体験だった。

あと、開演まで X でいろいろな人が目撃したというポストを見つけては、ニヤニヤしていた。すみません。

貸し切りバスでの来場は、半分ぐらい「盛り上げ」のためだったのだが、沼津からベルーナドームに行く移動手段として見たときに、乗り換え無しで行けることや、移動時間も他の移動手段と比べても見劣りしないため、実は一番快適な移動手段ではないかと思った。

次の約束はないものの、またこういったことをする機会が生まれることを願ってやまない。

最後に今回の運行の手配をしてくださった、富士急トラベル様、及びバスを貸してくださった富士急シティバス様、発案・見積もりなど事務処理をしてくださったぷらむさん、ご乗車いただいたすべての皆様に感謝します。ありがとうございました。

Finale ライブを迎えるにあたって

2025-06-19T00:00:00Z

前回の記事から1年が経とうとしている。

そして今、 Aqours が Finale ライブを迎えるにあたって、何か今の気持ちを書いたほうがいいのではないかと思って、とりあえず書き始めてみる。

去年の6月30日に、「あと1年」というタイムリミットを突きつけられた自分は、冷静ではなかった気がする。その時は Finale というものがよくわかっていなかったし、さらにその先の未来について考え、どうなってしまうんだろうという不安に襲われていた。

そのような中、7月にリバーサイドホテルで行われた、ヨハネ誕生祭に参加する機会を得る事ができ、そのイベントのゲストとして小林愛香さんと降幡愛さんが登場した。上土商店街の方がゲストの2人にインタビューをする中で、受け取ったメッセージは、「Finale ライブを迎えても Aqours の全部が終わるわけではない」ということだった。

中でも小林愛香さんは、生放送でも「私が、沼津を守ります」と言っていたこともあったので、それは「終わらせなんてしない」という強い意思にも感じられた。

300人ぐらいしか参加できないイベントに幸運にも参加でき、そのメッセージを、普段暮らしている沼津の地で受け取れたことは大きく、その後の1年も全力で取り組もうと思えたし、そこまで悲観しなくてもいいのかもしれないと、考えられるようになった。

思い返せば、2020年に引っ越してきた時も、TVアニメと劇場版が一段落し、コンテンツとしてもとっくに一区切りついて、今後「ラブライブ！サンシャイン!!」がどうなるのかという未来が具体的に描かれてない状態にあった。

そんな最中に引っ越してきた自己の興味としては、「コンテンツが下火になるだろう今後の沼津を見届けるのだ」ということだった。今考えれば不謹慎というか浅はかだったと思える。

実際、その予想は裏切られることとなった。 Aqours はコロナ禍という誰も経験したことないような、混乱の時代に入ってもなお、我々、そして沼津とのつながりを絶とうとしなかった。 DREAMY COLOR の実写PVや、地元愛まつりの開催を通し、沼津とより強い結びつきを生み出し、ついには新たなスピンオフTVアニメーションまで生み出し、この街に影響を与え続けた。

結局のところ、私が沼津に移住してから、沼津と Aqours のかかわりは、下火になるどころか、色濃くなるばかりであった。それに呼応するように、自分の中の Aqours という存在の大きさは日に日に増していくばかりであった。

Finale ライブの開催をお知らせしてからの1年も、9人は何度も沼津に訪れ、この街と僕たちを結びつけるシンボルとしてそこにあり続けてくれていたように感じている。

しかし、最初は長いように思えた1年という期間はあっという間で、最初は受け入れられたと思っていたことも、あと半年、あと1ヶ月、あと1週間となっていくごとに、不安になっていくばかりである。

そんな状況になって改めてTVアニメや劇場版を見返すと、そもそもラブライブ！サンシャイン!!という物語自体が、「『その後』の歩み方」についての話に感じられ、まさに今の我々にとっての道しるべとなってくれているのかもしれないと感じた。

全部、全部、全部ここにある。ここに残っている。
ゼロには、絶対ならないんだよ。

誰しもがそうだとは思うが、 Finale ライブの後に自分がどうなっているかなんて、全く考えられもしない。

だけども、自分はこの1年を通して、その未来はまったくの暗闇ではないと感じ取ることができている。

だからこそ今は、彼女たちが伝えたい想いを全力で受け取りに行きたいと思う。

今の感情

2024-07-01T00:00:00Z

生放送を見た

知り合いの家で何人かで集まって見た生放送、正直言って前から漂っていた嫌な予感が的中したというか、考えられる最悪のシナリオを突きつけられた形だった。

正直どう受け止めればいいのかわかりかねているのが率直な感想である。生放送以降はSNSもほとんど見ることができず、次の日も仕事できるか怪しいぐらいの感情だったが、逆にラブライブ！サンシャイン!!以外のことに集中してないと辛いなと思って、結局朝から仕事をしている。

まあただ、目論見通り没頭できるかといえばそんなことはなくて、生放送で伊波さんが言葉を選んでいる姿を思い出したり、自分は今後どうなるんだろうというすごく漠然とした不安に襲われているばかりで、結局ほとんど仕事もできないというのが現状である。

自分の今の気持ち

思えば、自分がラブライブ！サンシャイン!!に抱いていたものとは何だったのだろうか。考えれば考えるほど具体的な言葉にできなくなってくるが、とにかく「楽しい」という感情。彼女たちが居なければ、ライブという文化に触れることもなく、福岡や旭川に旅行で行ったりすることもなかっただろうし、いま自分の周りにいる人達にだって会えなかっただろう。それぐらい、今の自分のアイデンティティに深く根付いているコンテンツで、もはや無いということが考えられない。想像できない。

だから、わがままを言えば自分が死ぬまで続いてほしい。続けてもらわないと、「自分」という存在を維持することができないと思うぐらいに、このコンテンツが存在することが、自分にとっての自然な状態なのだ。取り上げられたら、本当に何も無い人間になってしまうのではないか。

ただ、これまでにそういったことを一度も考えなかった訳ではない。ここ最近あったμ'sのイベントに参加して、その姿を未来のAqoursに重ねることはあった。正直、その姿を見て、想像して、これまでと同じぐらい楽めるのかと言われれば、肯定はできない。やはりライブがあって、キャストが飛んで跳ねて、アニメと同じパフォーマンスをする「シンクロパフォーマンス」こそが自分にとってラブライブ！と出会ったときの原体験で、今でも渇望しているものであり、それを与えてくれるのがAqoursというグループなのだ。見れなくなるならラブライブ！である必要がない。

しかし、現実を見ると、彼女たちに今後もこの活動を続けていってもらうためには、彼女たちのいろいろなものを犠牲にさせてしまうのではないかという考えもよぎってしまう。自分がメンバーとほとんど同世代であるがゆえに、年齢という壁を原寸大で感じることがある。ただでさえ難しいパフォーマンスを求められているというのに、そこに年齢という壁を乗り越えるのは、普段の生活にも求められるものが高いだろうし、努力や練習も並大抵のものではないことは容易に察することができる。

結婚とかそういうのも、Aqoursでいる限りは「しづらい」という視線を感じてるだろう。実際、キャストが結婚するとなったとき、そのことを自分は心から祝福できないかもしれないと考えてしまうことがある。でも適齢期とかそういうのを考えると、自分はなんてわがままを女性に押し付けてるんだろうと思い、自分がファンであることが嫌になる瞬間がある。そういったことからしても、活動に一旦の区切りをつけることは、必要なことなのではないか。

沼津のこと

Aqoursの結成日に沼津に越してきて、今年で5年目になる。最近色々な活動も始めたこともあって、改めて思うのは、沼津は本当に奇跡の場所である。コンテンツがやってきて、そこへの乗っかり方が絶妙だった。役所のサポート、コンテンツ側の資金や協力の姿勢、地元の人たちの理解、各所におけるキーパーソンの存在、そこにやってくるファン、これ以外を含むすべてが絶妙なバランスで成り立っていて、今の沼津が存在できている。

自分が沼津に来た理由を人に説明するとき「アニメは沼津を知ったきっかけでしかない」と言う事が多かった。実際、自分の生活観に合ってて住みやすいなあと思いながら暮らしているが、今回の発表で気持ちが揺らいでいないといえば嘘になる。奥底ではアニメの聖地に住んでいるということが、心の支えであったと痛感したし、実家の事情でいつかは帰らないといけないかもということもあって、それがより具体的な未来として思い浮かんでしまう。

うみねこの活動なんかも、「たった今」の話をすればモチベーションがほぼ無いに等しい。1周年イベントを乗り越えて力尽きていたところに今回のことがあったので、本当にメンタル面にまで深く響いている。何をやろうにも「いつかみんな居なくなるんじゃないか」と考えてしまい、じゃあ今やってることって何のためにやってるんだとなってしまう。

唯一の支えとなっているのは、以前から「沼津がラブライブ！に依存するのは良くない」みたいな新聞の社説や、意見があるという話への反骨精神である。おそらくそういった意見の人達にとって、我々が迎えた現実は「それみたことか」と言いたくなるような状態なんだろうが、もはやこれほど歴史と言えるまで根付いたものが、そうすぐ無くなったりするかと言えば、逆に難しいだろう。そもそも今から早々にキリをつけてみすみす手放したとき、残った自分たちだけでこれだけのムーブメントを作れるのか？それとも誰かがやってくると思っているのか？とは思う。逆に「まだ1年ある」のだ。そこでいかに次に繋げていくかではないか。

いろいろ考えて

冒頭に「考えられる最悪のシナリオ」と言ったが、1年という猶予期間があるということを考えれば、突然解散や休止を発表されるよりよほどマシかもしれない。

そう考えると、ヤケになったり、落ち込んでいる暇はあまりなくて、残りを全部本気で取り組むしかないことは確かだが、その道を全力で1年間走りきったとき、自分や周りがどうなっているかは、本当にわからなくて不安だ。

ただ、気になっていること（コンテンツの締めくくり方や、その後の形）からくる不安は、徐々に発表されていくだろうから、時間が解決してくれるだろう。今の自分には、それが少しでもAqoursや周りの人たちにとっていい方向になればいいなと願うことしかできない。

1年後、この記事を見た自分へ

1年経ってどうですか？1年前に抱えていた不安は少しでも解消されましたか？あなた自身が、周りのみんなが、納得のできるような未来が示されているでしょうか。

多分まだ噛み砕けてないことも多いと思うし、もしかしたら1年前の自分とは違う不安を抱えているかもしれませんが、もしよかったら感想を聞かせてください。

地方移住者が移住者のためのコミュニティを立ち上げたら100人集まった話

2024-06-09T00:00:00Z

沼津に引っ越して3年で得た変化

2023-06-30T00:00:00Z

私が沼津市役所で転入届を出して沼津市民となったのは Aqours の結成日である6月30日。その年は5周年だったAqoursが、今年8周年を迎えるということは、わたしの沼津市民生活も3年目を終えたということだ。

ちょうどいい機会なのでここまでの3年間を振り返ってみて、自身にどういう変化があったかについて雑に書いていこうと思う。

バイクを買った

地方都市の問題として乗り物が無いと困ることが多いというのがある。住んでる場所次第では最悪無くても生きていけるのだが、気軽に買い物や内浦に行ったりしたいのであれば、あった方が好ましい。

とはいえいきなり車を買う勇気はなかったことと、実家でリトルカブを乗り回していたこともあって、これを機会にバイクを購入することにした。ただそこそこ交通量のある沼津で 50cc は大変だと思い、ある程度の排気量のバイクに乗るために、免許の取得からすることにした。

フレックスタイムや半休などを駆使して無理やりねじ込み、1ヶ月半ぐらい自動車学校に通って、中型二輪免許を取得した。免許自体は 400cc まで乗れることになっている。

購入するバイクはホンダクロスカブ110 にした。信頼と実績のスーパーカブの兄弟車で、工事車両みたいなイエローとブラックで配色された見た目のかわいさと、税金の手頃さなどから 110cc のバイクを選んだ。クロスカブは今となっては人気車種で半年から1年待ちなんて言われているが、当時はまだ人気が出始めたぐらいの頃で、近所のバイク屋さんで注文して1ヶ月もしないぐらいで納車されたので、本当にタイミングが良かった。

125cc 以下のバイクは自動車専用道や高速道路には乗れないが、下道では一番小回りとスピードが両立できるサイズである。見知らぬ細い道に入って行っても怖くないし、大きい道でも周りの車と同じ速度で走ることができる。

自然現象に関心を持つようになった

沼津は海と山の両方を楽しめる自然に囲まれた地だ。季節ならではの自然現象も多く、沼津では「しおくずばんば」と呼ばれる海霧や、水平線に沈む夕日が蜃気楼のようになって見える「だるま夕日」、夏の訪れを告げる「夜光虫」など、見所は枚挙にいとまがない。

そしてやはり沼津にとって富士山は欠かせない。子供の頃から沼津に住んでいる人が言っていた「富士山はいつ見ても飽きない」と言っていたのは本当にそうだなと思う。案外毎日少しづつ違いがあったりするもので、冠雪が増えた・減ったとか、空気が綺麗だとよく見えたり、雲のかかり方ひとつとっても季節性があったりするので面白いのだ。

東京に住んでいた頃は気温や雨が降るのかぐらいしか気にしたことがなかったが、沼津に来てからは自然を感じるシーンは格段に多くなった。

新幹線で通勤するようになった

現職は現状フルリモートをやっていないので、週に1回ぐらいオフィスへ出社することがある。沼津からの通勤には新幹線を使っている。実は三島・沼津エリアから東京への通勤というのはあまり珍しいものではない。というのも三島駅に新幹線の車庫があり、朝・晩の時間帯だけ車庫に出し入れする列車を営業列車にした三島発着のこだま号が結構な頻度で運行されているため、昔から三島から東京の会社に通っているという人は少なくないのだ。

三島・沼津間の列車は新幹線に合わせてダイヤが組まれているので乗り継ぎもよく、片道2時間ぐらいあれば通勤が可能できる。遠いは遠いが、こだま号の自由席はほぼ確実に座れるので、首都圏の通勤列車の硬いロングシートでの移動に比べれば楽な方かもしれないなと思っている。

自動車を買った

バイクを買って1年後、車を買った。最初こそバイクだけで十分じゃん〜とか思っていたのだが、冬のバイクの過酷さを完全に舐めていた。とはいえ、沼津は冬も比較的温暖な地方だし、雪の心配をすることもないので、乗ろうと思えば乗れるのだけども、寒いもんは寒い。

買ったのは Honda N-ONE RS のマニュアル車である。「なぜマニュアルを」とよく聞かれるが、よくある「人生で一度ぐらいはマニュアル車に乗りたい」という思いからである。最初は軽トラも候補にあったのだが、普段遣いのことを考えて乗用車となった。

初の新車購入の車なので大事に乗っている。とはいえ通勤には使わないし、もともとバイクもあるので、あまり動かさない週もあるのだが、雨の日の移動や、ライブ会場の遠征などに使えるので非常に便利である。バッテリーさえ持っていけばワークスペースとしても機能させることができて便利である。

馴染みの店ができた

これまであまり決まった店に行くということがなかった。外食という選択があまり自分の中で優先度が低く、行ってもチェーン店とか、そういったところで済ませる事が多いのが実情だった。また、個人店となると（勝手に）入りづらいと思ってしまい、あまり進んで行く感じでもないタイプである。

沼津は聖地巡礼者向けに Twitter をやっている店が多いため、事前に店の雰囲気を知ることができる。よく行っている「ねこと白鳥」というバーは、 Twitter で存在を知った店の一つである。そもそもそれまでバーというものに縁遠かったのだが、 Twitter で雰囲気を知ったり、聖地巡礼で訪れた観光客を拒まない雰囲気が良いなと思い、初めて入店したのは私が移住する前の出来事である。それ以降、沼津に行くと訪れることも多かったのだが、移住をきっかけに頻度が上がり、今ではほぼ毎週通うぐらいになった。

また、市場町にあるマリー・ルゥという喫茶店は、移住してから散歩しているときに知ったお店である。少し大通りから離れたそのお店の雰囲気は、昭和〜平成初期のままで、2023年の今でもランチはサラダ・ドリンク付きで800円という良心的な価格で提供しており、個人的に応援しているお店だ。

木曜日にランチメニューで出るオムライスが気に入ったので、毎週食べに行っていたら、どうやら「オムライスの人」として認知されたらしい。店主の人も気さくに話しかけてくれるので、仲良くしていただいている。

ラブライブ！サンシャイン!! の勢いがとどまることを知らない

沼津という土地で避けて通れないのがラブライブ！サンシャイン!! である。自分自身ラブライブ！で沼津という街を初めて知った身である。そこから沼津そのものが好きになり移住までしたというのは、移住者にはよくある話である。

自分が入植した2020年は、アニメも劇場版まで終わって一段落し、ラブライブ！シリーズでも新しいグループが出てきたので、もうこれ以上はないのではという雰囲気だった。そこで自分は勝手に「これから下火になっていくかもしれない沼津を見届けるんだ！」という気持ちだったのだが、その予想は外れることになる。なんと2023年になっても、新たにJR東海とコラボをして駅の装飾が増えたり、また新しくスピンオフアニメが始まったりと、8年目の今日も勢いが増していくばかりなのだ。

まだまだ何が起こるかわからない沼津の変化は、これからも自分を驚かせてくれるだろうと思っている。

良いことばっかり言っているがデメリットはないのか

個人的な話として田舎で生まれ育ったというのもあり、自分には都会での生活はどうしても馴染めなかったという過去がある。沼津での生活は東京に比べて居心地が非常にいいと思っている。

ただ都会の生活に慣れている人からすると、おそらく信じられないぐらい娯楽がないと思うだろう。イベントや演劇といったものは都会でしか行われないことが多い。まあただ沼津は時間とお金さえあれば、在来線でも東京に行けるぐらいの距離にあるので、東京のイベントに行こうと思えばいけなくはない。気軽さは減るだろうが。

他にも沼津には映画館やショッピングモールはあるものの、それ以外の遊び場は本当に限られる。自分はただバイクで走って季節を感じるだけでも楽しめる人間なので、娯楽施設は必要としていないのだが、刺激的なことがしたいとか、新しいことをやりたい！みたいなキラキラした人には向いてないのが事実である。

4年目にやっていきたいこと

沼津生活もついに4年目になり、自分的には非常に満足度が高い日々を送っている。一方で自分自身が他者とのつながりや地域コミュニティへの参加という部分が希薄という部分に問題を感じている。

沼津に住んでいる移住者の知り合いは少なく、ここ最近ようやく増えて何人かと仲良くさせてもらっている。しかし同じように沼津に移住したという人はもっと多いはずなのに、その実態は殆ど見たことがない。 Twitter を見ていると、それぞれ小さなつながりはあれど、横のつながりがないというのが現状のようだ。

自分はこれを少しでも解決できないかと思っている。中には何かに困っていたりして、コミュニティがあれば参加したいという人も少なくはないはずだ。同じ理由で同じ場所に移住してきた者同士で、相談や情報交換とかができるような場所を作れないかと思っていて、今まさに活動している真っ最中である。

実現にはまだ道半ばだし、もしかしたらうまくできないかもしれないが、できることから頑張っていこうかなと思う。

さいごに

「お前がそこまで推す沼津に興味がある」、「行ってみたい」などがあれば、沼津旅行のご案内や、旅程のコーディネートだけでも相談に乗ります。すでに何名かの方にはご案内し、ご満足していただいた実績もありますので、ぜひ気軽にお声がけください。

それではまた沼津でお会いしましょう。

eplus の Stremaing+ を快適にするためのブラウザ拡張機能 "Streaming+ sequencer" をつくった

2023-02-19T00:00:00Z

Streaming+ の操作がしづらいという問題

eplus のライブ動画配信サービス Streaming+ というものがある。アーティストのライブを有料でオンライン配信する際に利用されるプラットフォームなのだが、一定期間アーカイブ視聴できる機能があって、自分もよく利用している。

ただこのサービス、配信の動画品質や転送速度には不満は無いのだが、画面上での動画の操作が非常にしづらいという欠点がある。例えば、「あ、今のシーンよかったな。もう一度みたいな」と思う場面があったときに、時間を操作するための UI がシーケンスバーしかなく、その上動画の長さが3時間とかあるため、細かい操作ができずにイライラさせられることが多かった。

この問題を解決するためのブラウザ拡張機能を作った

毎回ライブ動画を視聴する度に、このことを不満を感じていたのと、 Twitter でも同じような悩みを持つ人を観測したので、問題を解決するため、 "Streaming+ sequencer" というブラウザ拡張機能を作った。

この拡張機能は、 Steraming+ で再生中の動画に表示されるコントローラの部分に、動画の再生位置を10秒スキップ・10秒巻き戻すためのボタンを追加してくれるものである。

押すと実際に10秒行ったり戻ったりの操作が行われるのだが、実際に自分で使っていても当初の目的を達成できて、非常に便利なので満足している。というか eplus が利用している Video.js のプラグインを入れて機能として提供してくれれば、こんなまどろっこしいことをしなくて済んだのだけども。

機能実装の方法について

ちなみに、実現方法としてはごくシンプルに HTMLVideoElement の API を使っているだけである。拡張機能側は live.eplus.jp というドメインにアクセスすると、必要な JavaScript と CSS を流し込むだけで、特に環境を汚したりとか、 eplus 側に負荷をかけて迷惑がかかるということもないだろう。

実装コードは GitHub にも公開しているので、どういった実装になっているか気になる人は見てもらうこともできる。

windyakin/streaming-plus-sequencer

ただ今後の課題としては、配信画面の実装が変わったときにデバッグするのが困難なことであろうか。まさに「ペイウォール」に阻まれているので、動かなくなった報告を受けても自分で確認するのはなかなか難しいものがあるなと感じている。

Ruby Gem が依存している Gem の参照先をプライベートリポジトリなどに変更したい場合

2023-02-16T00:00:00Z

Ruby アプリケーションの依存先の参照指定

Ruby のアプリケーションだと、依存するライブラリ(Gem) を Gemfile に書くことが多いが、その際に RubyGems.org ではなく、 GitHub の特定のブランチなどを指定してインストールする構文がある。

# application/Gemfile
gem 'awesome_fluent_logger', github: 'windyakin/awesome_fluent_logger', branch: 'specific_branch'

こうすることで、プライベートリポジトリを参照させたり、 Fork して独自の対応をしたコードなどを読み込ませて、アプリケーションを稼働させることが可能になる。

では Gem 自身の依存はどう表現されるか

一方で、参照される Gem 側にも依存する Gem が存在する。そういった情報は gemspec というファイルに書くことになっている。

Gem::Specification#add_dependencies は依存する Gem のバージョンを細かく指定できるが、 Gemfile のように「GitHub のリポジトリなどを指定する」といった情報は書くことができない。

ではこのとき、どうするかというと、 Gem 側にも Gemfile が存在するので、そこにアプリケーションと同じ構文で指定することによって、読み込み先を変更することができる。

# example/example.gemspec
spec.add_dependency 'fluent-logger', '~> 0.9'

# example/Gemfile
source "https://rubygems.org"

gemspec

gem 'fluent-logger', github: 'windyakin/fluent-logger', branch: 'specific_branch'

この状態で、 Gem の開発環境上で bundle install などを実行すれば、 Git リポジトリから落としてきたコードを利用することができるようになる。

参照しているアプリケーション上ではどうなるのか

一方、この指定は Gem として読び出しているアプリケーション側に継承されることはなく、 bundle install をしても RubyGems.org から該当する名前の Gem とバージョンを参照してくるようになっている。

わかりにくいので、下記のような関係の場合において考えてほしい。

Application (A) -> Example Gem (B) -> Dependency Gem (C)

例えば Example Gem (B) が依存する Dependency Gem (C) の参照先を GitHub に向けたいとする。

このとき、 Example Gem (B) の Gemfile に Dependency Gem (C) の参照先として GitHub を記述しても、 Application (A) はその情報を読み取ることはなく、 RubyGems.org にある Dependency Gem (C) を参照するようになっている。

もし、 Dependency Gem (C) の参照先を GitHub に変更したい場合は、 Application (A) 側の Gemfile 上で Dependency Gem (C) の参照先を記述するとよい。アプリケーション側で直接利用していなくても、こうすることで解決することができる。

# application/Gemfile
gem 'awesome_fluent_logger'
gem 'fluent-logger', github: 'windyakin/fluent-logger', branch: 'specific_branch'

参考にした情報

External Secrets で Doppler を使っている

2023-01-13T00:00:00Z

Sealed Secrets の運用の問題

Kubernetes で Secrets の管理というのは簡単そうで面倒なものの1つである。特に GitOps をしようとすると、 Secrets リソースをそのまま置いたりすることもできないので、何かしらの対応を考える必要があるのだが、自分の場合はこれまで Sealed Secrets を使って対応してきた。

導入当初はこれで問題なく運用していたのだが、しばらくすると問題が浮き出てきた。

まず Secrets の内容を変更・追加したい場合のオペレーションが煩雑で（できなくはないのだが）、何度かオペレーションミスを起こすことがあった。

また、自分の場合、運用している Kubernetes クラスタ複数あることも問題だった。 Sealed Secrets が暗号化・復号のために利用する秘密鍵は、基本的にクラスタごとに異なった鍵を用いるので、クラスタごとに異なる Sealed Secrets を保持する必要が出てきてしまう。

Doppler との出会い

このような問題を解決できるのが External Secrets というもので、ざっくり言うと Secrets を外部サービスに保存して、クラスタに登録するのは外部サービスとの連携キーだけにしようという仕組みである。

1年ほど前に存在を知ってから、何度か移行しようと検討してきたのだが、「Secrets を保存する外部サービス」というのが問題で、 AWS や GCP が提供しているものは無料枠が限られており、特に保存したい Secrets の数で課金されるというのが、個人的に微妙なポイントだった。

そんなこんなで半年ぐらい手を出せずに居たのだが、最近 External Secrets のドキュメントにある「連携できるサービス」の一覧に Doppler というサービスが加わったことに気づいた。

聞き馴染みのないサービスだったのだが、調べてみると共同編集5ユーザまでなら基本機能が無料で、SLO等は保証されないものの、当然自分はホビーユースなのでそんなに気になる点でもないため、試しにフリーライドさせてもらうことにした。

External Secrets の運用

Doppler の使い方そのものについては、既に色んな場所で紹介されていると思われるので割愛するが、環境(integration / staging / production)ごとに Secrets の値を別けて持てることから、まあそれなりに便利に使っている。

しかし、これにも1つだけ問題があって、「External Secrets のために Secrets が必要」という点で、先程述べた通り External Secrets が外部サービスの API に接続するために使う認証キーを Kubernetes クラスタ上に Secrets リソースで保持する必要があるのだ。

つまり、当初の目的である複数クラスタでの GitOps を実現したい場合だと、当初の問題と同じような問題に直面してしまうのである。

自分の場合は、 External Secrets 用の Secrets を Sealed Secrets にするという運用にしている。 Secrets の内容の更新の頻度より、クラスタの置き換えなどが発生する頻度のほうが明らかに少ないし、最悪でも External Secrets 用のキーを再発行・暗号化すればよいので、いくらかマシであるという判断だ。

釈然としないと思うが、そんな感じで今の所満足して運用している。

また時間が経てば別の問題を感じるようになるかもしれないので、その時はまた解決法を考えて記事を書こう。

ウェブサイトを作り直した

2023-01-04T00:00:00Z

前々から自分のウェブサイトを作り直したいと思っていたのだが（n回目）、正月休みに特段やることがなかったのでようやく手を付けることにした。

シンプルすぎやしないか

これまで、人よりかは様々なウェブサイトを作った経験があると自負しているが、それによって得られた知見としては、ぬるぬると動くサイトは格好がいいのだが、その後の維持管理にかかるコストがでかすぎて手に負えなくなるということである。そこで、そういったコストをかけたくない自分のサイトにおいては、「とにかくシンプル」に「伝えたいことを伝えられるだけのサイト」となるようにした。

具体的に目指したのは「CSS が欠損しても最悪どうにかなる DOM 構造にする」で、結果として CSS 装飾ほぼなし・ JavaScript は一切なしという、阿部寛のホームページもびっくりな過激サイトが完成してしまったのである。

ブログについても、これまではてなブログを使っていたのだが、自身のコンテンツを第三者が左右できる状態にあるという状態がどうも落ち着かないので、これを機にサイトと統合することにした。直近公開していたいくつかの記事については、新しいサイトにもアーカイブとしてコピーしてきたが、既にはてなブログ側で公開している記事については、各所からハイパーリンクで参照されている可能性もあるので、デッドリンクとしないために残しておくことにする（今後ははてなブログを更新をしないつもりでいる）。

Eleventy を使った

ちなみに今回のリニューアルに際して、使用することとしたサイトジェネレータは、昨今話題の Eleventy である。冒頭に書いたこのサイトのコンセプトがあるため、テンプレートをイチから自身で書くことになったが、初めて触った割にはすんなり動かすことができて概ね満足である。

リポジトリについては以下の通り。

windyakin/windyakin: windyakin's profile and portfolio

今後について

ウェブサイトの構成はまだ詰めきれていないのだが、完璧を目指すよりまず終わらせろということで、公開してから調整することにする。

あとコンテンツについてももう少し拡充するつもりである。以前から温めている職務経歴書が公開できるとよいのだが。

右クリックしたリンクのURLをAPIに送信するためのブラウザ拡張機能「かんかんみかん」を作りました

2022-05-14T00:00:00Z

ブラウザでリンクを右クリックしたときに、そのリンクのURLを特定のAPIエンドポイントへPOSTデータとして送信することができるブラウザ拡張機能を作った。

この拡張機能は、前々から筆者が Twitter の投稿のブックマークを目的として作成した Cloud Functions のエンドポイントに URL を送信するために使っていたものを、 API エンドポイントの指定や、 POST する JSON のフォーマットをテンプレートで設定できるようにすることで、一般にも利用しやすくすることで公開したものである。

現時点で公開している最新版 v2.0.0 で設定できる項目は以下の通り。

Post URL
- リクエスト送信先のURL
Content-type
- application/json と application/x-www-form-urlencoded から選べる
Post data template
- 送信する Body とする JSON のテンプレート
- {{{ url }}} が右クリックで選択しているリンクのURLに展開される
Fillter (Regexp)
- 右クリックで選択したリンクのURLが正規表現に当てはまらなかった場合にリクエストを送信しないようにすることができる

これらの機能は、自分が使うために必要最低限の機能として実装したもので、若干高度なオプション設定が多く、作りとしても粗雑なことは否めないので、ぜひ使ってくださいとも言いづらいが、例えばブックマークサービスのAPIエンドポイントにURLを送信するとか、何らかの開発に役立てることができればと思う。

GitHub にスクリプトも公開してあるので、必要であれば参照してほしい。

napple-team/kankan-mikan: 从c*・ヮ・§

最後に愚痴になるのだが、2022年5月現在ブラウザ拡張機能を取り巻く環境は正直言って微妙で、ほんの少し前まで Chrome と Firefox で共通のプログラムで管理できていたのだが、 Chrome Web Store が Google の利益を目的として Chromium が独自に提唱している Manifest V3 という新しいフォーマットでしか新たな拡張機能の投稿を受け付けなくなってしまった。これのせいで Firefox とまた道を分かつことになってしまっており、そのために2つのブラウザの差分を吸収するように別々のスクリプトを管理することになっているので、煩わしさがすごい。

今回作った拡張機能はまだ Manifest V3 の変更による影響を受ける箇所は少なかったが、今後様々な拡張機能がこういった対応をしなければならないと思うと、なかなか大変そうな話だと思う。

シニアエンジニアになった

2022-04-26T00:00:00Z

4月1日から職場での肩書が「シニアエンジニア」になった。この肩書は勝手に名乗っているわけではなくペパボの職位等級制度によるもので、全部で8段階ぐらいある等級の中、入社時には3等級の「エンジニア」のだったのものが、1つ上の4等級となった。等級は数が大きいほど強いという意味になるので、ちょうどキルラキルの極制服ようだなとかねがね思っている。

この職位等級制度の詳しいことについては、ペパボのHRブログに書いてあるのでそちらを確認してほしいのだが、今回はちょうどいい区切りなので、自身が普段どういう専門性を持って仕事をしているのかについてかんたんに説明しようと思う。

今の自分の所属チームについて

ペパボへの入社は2019年の夏頃で、入社当初の配属はEC事業部のプロダクトチームであった。このチームは主に「カラーミーショップアプリストア」というサービスの運用とそれらに関係する諸々の領域を担当をしており、後に事業部のチームの配置転換の際には「アプリストアチーム」として名前を改められ、私も現在に至るまでこのチームに所属している。

またそれとは別に2年ほど前からアプリストアチームと兼任で、可用性向上プロジェクトのメンバーとしてもアサインされて活動中である。このチームはメインの商材であるカラーミーショップの可用性を向上させるために、インフラ周りを中心に改善を行っていくために組織された事業部を超えた横断的なプロジェクトである。その中でも自身がメインで関わっているのが、可用性向上のための既存システムを Kubernetes 上でスケーラブルに動かす仕組みづくりで、 Kubernetes 上で稼働させるために必要な既存システムの改修などを行っている。

Vue(Nuxt) のフロントエンド開発

アプリストアチームでは主にバックエンドに Rails 、フロントエンドに Vue(Nuxt) が使われている。特にデベロッパーサイトと呼んでいる、アプリストアへアプリを提供しているデベロッパー向けのダッシュボードがあるのだが、それの立ち上げに大きく関わった。

カラーミーショップデベロッパー

ちなみに立ち上げは入社してすぐの頃であったのだが、前職ではフロントはほぼ触っていなかったものの、CSSフレームワークなどを使ってウェブサイトを作っていた経験や、業務とは関係なく Nuxt を使ったウェブサイトを試しに作ったりして知見を高めた。その結果。年末ごろにはゴリゴリ Nuxt を書けるようになり、デザイナーさんが上げてくるモックアップから、デザインフレームワーク(Vuetify)のコンポーネントなどを提案して、それらを使って画面の実装することができるようになっていた。また素人ではあるもののデザインに関する基本的な感覚があったので、よりモックアップに近いものを作れる能力があることに気づいた。

既存システムの Docker & Kubernetes 化のための改修など

可用性向上プロジェクトでは、主にカラーミーショップという商材を Kubernetes 上で稼働させるために、それらに関係することであればアプリケーションの改修や、ミドルウェア・インフラ面にも踏み込んで対応を行っている。例えばこれまで行ってきた内容は以下の通り。

アプリケーションをコンテナイメージ化するため作業

開発用のコンテナというのはかねてから存在したものの、コンテナ単体でシステムが動くものではなかったので新たに Dockerfile を作成
それらを GitHub Actions でイメージビルドする CI/CD パイプラインの整備
- 当時はまだ全社的に GitHub Actions が導入されはじめたばかりだった
- それにあたって必要になった自作 GitHub Actions の作成もした

ログのフロー設計とそのためのアプリケーション改修

当初 Pod の Sidecar から直接 BigQuery に転送していたが、諸々の検討した上でログを集約する Statefulset な Fluentd のサービスを新たに立ち上げた
Rails でそれまでファイルに吐き出していたログを直接 Fluent への転送ができるようにした
- その際に依存する Gem を最小限にするために新たにシンプルな Gem を製作して導入

シンプルに Fluentd にログ転送ができる RubyGem "awesome_fluent_logger" をつくった - windyakinってなんて読む

Kubernetes の上での設計やアプリケーション動作のために必要な Manifests を作成

基本的にゴリゴリ書いていく感じ
現状でもアプリケーションロールこそ分離されているものの、以降に際して1つの Pod に詰め込む単位などを検討
Twelve-factors に沿ってアプリケーションで読み込んでいる設定値を環境変数に逃がして読み込めるようにしたりする

ファイルキャッシュを永続化するためにストレージサービスを利用したシステムを構築

Kubernetes のライフサイクルとファイルキャッシュの相性が悪いので小さなアプリケーションを新たに用意して資産を活かせる形とした

レガシーなアーキテクチャをKubernetes上でも活かすために - Pepabo Tech Portal

開発支援のためのツール開発

Kuberenetes の環境を作って終わり！じゃなくて、実際に開発者に使ってもらえるようにするために開発を支援するためのツールを作っている。

ブラウザ拡張機能

開発環境の切り替えに必要な作業を簡略化するために初めてブラウザ拡張機能を作った。作った時期が悪くて Chrome の Manifest V3 に対応する羽目になった件については後日書く。

Slack Bot

Chat Bot というよりかは、最近 Slack が推している Slash command を使ったインタラクティブな画面を実装。開発者が自分の環境を Slack から作ることができるようになる。

大量アクセスによるインシデント対応

大量にアクセスが来ると色々と困ることがある。 k8s に完全に移行するといくらか軽減されるかもしれないが、まだ移行できていないためシステム全体に影響が波及しやすい。もちろんそういったことが起きない起こさせないために日々改善はしているが、起きてしまったときの対応も必要である。

実際に起きた時に何が原因になっているのかの初動の調査や、必要なアクセス制限の判断などを積極的にハンドリングしていた。またそれらをドキュメントやダッシュボード化してなるべく自分以外の人でも対応できるようにしていた。

最近は未然に防げる仕組みが整ってきたので出動回数は減ってきている。

安定したサービス提供のための改善レポート【2022年1〜3月】 | お知らせ・最新情報カラーミーショップ無料で本格的なネットショップ作成サービス

登壇・執筆等

口下手と言うか、単純にしゃべるのが下手すぎるのでこういう登壇の機会はあまりないのだが、一応表立ってしゃべることもある。

執筆というほどではないが、会社のテックブログには手厚めの文書がいくつかある。自分はどちらかというと、文章を書く方が得意なので「なにをやったのか」「どうやったのか」を世に出していくにあたっての質を大事にしているし、世の中は常にそういうものを求められるようになっていると思う。なんでも手軽にできる時代だからこそ、信頼度の高い内容を出していかなければならないように感じている今日このごろ。

シニアエンジニアになってどうですか？

実際のところ仕事内容には大きな差が生まれていない。ペパボの場合、シニアへの昇格は追認行為なので、立候補する際にはシニア相当の働きをしていると認められないとシニアになれないことになっている。であるからして、シニアになったからといって何かが劇的に変わるかというとそうでもない。ただ求められるレベルはこれからも上がっていくと思われるので、日々精進していくのみですかね。

10年前に公開していたCGIプログラムで脆弱性が見つかりCVEに登録された話

2022-03-30T00:00:00Z

かつて「ぜろちゃんねるプラス」という２ちゃんねる型スレッドフロート掲示板システムの開発と公開をしていたことがある。

ぜろちゃんねるプラス

とはいえ開発をしていたというのは自身がまだ学生だった10年以上前の話であり、現代において Perl CGI のプログラムを保守・運用しようというのがなかなか厳しい話なので、ウェブサイト上では2015年ぐらいから開発の終了も明言していた。ただホスティング元のOSDN(当時はSourceForge.jpであった)が現在までサービスの提供を続けてくれていることと、すでに利用している人に向けたアーカイブを目的として、特に非公開化することもしていなかった結果、現代でも一部のコミュニティなどで使われるという謎の代物となっていた。

開発者への脆弱性の報告

そんなこんなで絶賛放置していたのだが、3月22日の10時頃、開発用の掲示板に「クロスサイトスクリプティングが行える脆弱性」があるという内容の報告がもたらされた。自分はその掲示板を常に見ていないのだが、開発メンバーの1人がそれに気づいて同日の22時ごろに Twitter の DM 経由にて自分を含む当時の開発メンバーに通知された。調べると連絡が来るより数日前からすでにこの攻撃は一部で横行しているようで、このスクリプトを使っているサイトの運営者はなんらかの対応を行う必要がある状態となっていた。

しかし先述の通り、そもそも開発の終了を宣言しているプロジェクトである。開発元からの対応はしないならしないでもよいとも考えられるのだが、職業をエンジニアとしている者としては、一度出したものに「脆弱性がある」という状態のまま放置するのも居心地がわるいので、今回は特別に該当箇所のホットフィックス版をリリースをすることとした。

修正までの過程

まずは報告を受けた内容の真偽を確かめつつ原因の調査をする必要があるのだが、そのためにはサンドボックス環境を用意する必要がある。脆弱性への対応であることや、すでに攻撃が発生していることから、インターネット環境で試すことはあまり好ましいことではない。できればローカル環境で実験したいのだが、当時開発に使っていたXAMPPなんてとうに捨てており、また現代において Perl CGI が動く環境を用意するのはそこらへんの Rails を動かすより手間であるかもしれない。

ただこの問題については、数年前に気まぐれでプロジェクトを Docker イメージ化をしていたので割とすぐ用意することに成功した。数年前の自分の気まぐれはなかなかのファインプレーであった。

zerochplus/zerochplus-docker: 🐳 zerochplus on Docker

またぜろちゃんねるプラスのリポジトリは SVN である。一応 GitHub にもプロジェクトの Organization とミラーリポジトリっぽいものがあるのだが、実は SVN とは履歴も状態が乖離している。我ながらひどい状態で放置していたものである。結局数年ぶりに SVN コマンドを叩くことになった。

ただ脆弱性の起因となるコード箇所の特定は比較的スムーズに行うことができた。これは当時の開発メンバーへの連絡により比較的早い段階で人手を招集でき、それぞれが調査を行ったおかげである。こういった緊急事態の初動は人手が多いほうがよい。

その他にもリリースパッケージの作成などリリース作業で手こずる場面は多かったのだが、23日0時にホットフィックス版であるぜろちゃんねるプラス v0.7.5 をリリースをした。後から気になって調べたが、前回のリリースから約3,000日ぶりの更新であったらしい。今回開発者への初報を受けてから約14時間、開発者の招集からは3時間弱での対応となったが、3,000日ぶりのリリースにしてはかなりスピード感があるほうではないだろうか。

IPAへの報告

ぜろちゃんねるプラスには自動アップデートの機能は備え付けられておらず、サイトの運営者が自身で情報を取りに来なければ脆弱性が含まれていることを察知できない。そのため情報の発信していく必要があるのだが、ぜろちゃんねるプラスのサイト上では最大限告知をしたとて限度がある。そこでIPAへ今回の脆弱性を報告をすることで、JVNからの発信を行ってもらうことにした。これで万全というわけではないことは重々承知だが、使えるチャンネルはできる限り使ったほうがよいだろうという判断である。

報告後、何度かメールのやりとりを行ってレポートが作成された。すでに攻撃が発生しており修正版も出ている内容だったためか、JPCERTの方には素早い対応をしていただき、3月30日にJVN上で公表されている。

JVN#59576930: ぜろちゃんねるプラスにおけるクロスサイトスクリプティングの脆弱性

なお今回は CVE の番号 CVE-2022-27496 も採番された。自身の関わったプロダクトに CVE が採番されるのはなかなか複雑な気持ちではあるが、経験値としては悪くないだろう。

なぜ今回対応できたか

冒頭にも書いたが今回そもそも対応するかどうかは判断が微妙なところだった。ほぼ義理と人情みたいなところで動いているのだが、一番大きかったのは会社でのインシデント対応によって培われた突発的な事象への対処能力かもしれない。正確には能力というよりかは気持ち的な問題で、いざコトが起きてしまったときに、ただ悲観的になって立ち止まったり放棄するのではなく、「よしやるか」とギアを入れ替えて問題に挑めるようになってきたような気がしている。

今回も報告を受けたときに比較的早い段階で「対応する」という方向に舵を切って対処し、忘れ去っていたリリース方法までがんばって思い出してリリースできたことは非常によい経験だったように思う。

今後のぜろちゃんねるプラスについて

改めて言うが、今回のホットフィックス版のリリースは極めて異例の対応である。今後また同じような報告を受けた際に同じような対応ができるかについては明言を避けたい。これを機会にぜろちゃんねるプラスの利用者には「開発を終了しているもの」を使っているというリスクを理解し、適切な対処をしてほしいと思っている。

復旧までのタイムライン

2022年3月22日 10:00
- ぜろちゃんねるプラスの開発掲示板にクロスサイトスクリプティングに関する脆弱性の報告
21:45
- 報告を受け当時の開発メンバーが招集
22:30
- ローカル環境にて報告内容の再現を確認
23:00
- パッチコード作成完了
- リリース向けのパッケージ化や準備を開始
2022年3月23日 00:30
- ぜろちゃんねるプラス v0.7.5 リリース
10:00
- IPA へ脆弱性関連情報の届出
2022年3月30日 12:00
- JVN より脆弱性情報の公表

日付・時刻はすべて日本時間

Kubernetes の Pod を定期的に再起動させる

2022-03-27T00:00:00Z

イメージのバージョン管理面倒くさい問題を定期的な再起動で解決する

前回のエントリで k3s を運用している話を書いたが、 GitOps 運用の中で私はコンテナの Docker イメージのバージョン管理をサボっている。現状各アプリケーションのイメージはすべて latest のタグが振られているのみで、イメージを更新しても GitOps に使っている manifests のリポジトリを更新される仕組みも用意していない。

だけどもこれだと Pod が生きている限りイメージが更新されても Pod が使うイメージが変わらないままになっていまうので、 CronJob を使って Deployment で起動している Pod を定期的に再起動している。これに併せて imagePullPolicy: Always を指定しておけば、 Pod の再起動の度に最新のイメージを取ってくることができるという目論見である。

ServiceAccount を用意する

ServiceAccount と (Cluster)Role と (Cluster)RoleBinding を用意する。自分は最初この3者の関係がよくわかっていなかったのだが、色々調べていくうちにでいうと Role と ServiceAccount の多対多の関係を表現する中間テーブルが RoleBinding であると理解した。要は Google の IAM 管理で行う「権限」のグループを作ってその権限をユーザに割り当てる行為と同じである。また Role / RoleBinding の頭に Cluster がついて ClusterRole や ClusterRoleBinding になると、その権限は namespace を超えて実行することができる。

まずは Role について。最終的に ServiceAccount が使えるようになる Kubernetes API を一覧にする。 kubectl コマンドで kubectl [verbs] [resources] が使えるようになるという理解が近い。ここに apiGroups という概念も登場する。 Pod は apiVersion: v1 と表現されるが、この場合はコア機能であるので "" (空文字) が指定される。一方 Deployment は apiVersion: apps/v1 と指定するため apps を指定することになる。

kind: ClusterRole
apiVersion: rbac.authorization.k8s.io/v1
metadata:
  name: pod-restarter
rules:
  - apiGroups:
      - ""
    resources:
      - pods
    verbs:
      - get
      - list
      - delete
  - apiGroups:
      - apps
    resources:
      - deployments
    verbs:
      - get
      - list

次に ServiceAccount。特に凝ったことはしないのでそのまま名前をつけるだけ。

apiVersion: v1
kind: ServiceAccount
metadata:
  name: pod-restarter

最後に Role と ServiceAccount を紐付ける RoleBinding を記述する。

kind: ClusterRoleBinding
apiVersion: rbac.authorization.k8s.io/v1
metadata:
  name: pod-restarter
subjects:
  - kind: ServiceAccount
    name: pod-restarter
    namespace: default
roleRef:
  kind: ClusterRole
  name: pod-restarter
  apiGroup: rbac.authorization.k8s.io

CronJob を用意する

Pod を再起動させる方法は色々なあるが、 delete pods を定期的に実行されるようにした。これだとダウンタイムが出るが、自分が使うサービスなのでこのままにする。おそらく通常は Deployments の annotate に日付を入れると manifests の更新とともに Pod が再作成されるという方法をとることになるが、自分の環境は ArgoCD で即刻上書きされるので向いていないためこうした。

bitnami/kubectl のイメージ上から kubetl の jsonpath で Deployment の名前の一覧のみを出力し、その結果を xargs にパイプして delete pods を実行させるようにしている。

apiVersion: batch/v1
kind: CronJob
metadata:
  name: pod-restarter
spec:
  schedule: "0 2 * * *"
  concurrencyPolicy: Replace
  jobTemplate:
    spec:
      template:
        spec:
          serviceAccount: pod-restarter
          restartPolicy: Never
          containers:
            - name: pod-restarter
              image: bitnami/kubectl:latest
              command: ["/bin/sh", "-c"]
              args:
                - |
                  kubectl get deployments -o=jsonpath='{range .items[*]}{.spec.template.metadata.labels.app}{"\n"}{end}' | xargs -I "{}" kubectl delete pods -l app={}

効果

いまのところ毎日深夜2時に再起動がかかる運用になっており、最長1日待てば最新のイメージが落とされるようになっている。普段は依存パッケージのセキュリティ更新しかしないためこの運用で問題なく感じている。

ただここまで紹介したのは結構な面倒くさがりの所業で、一般公開しているサービスなどでこれをするのは非常におすすめしない。一旦はこれで運用ができているのはあくまで個人の管理しているサービスだからである。

k3s を運用している

2022-03-17T00:00:00Z

個人的なプロジェクトを外部公開するときや、私的なツール郡を動かすためにVPSを借りている。基本的に自分が作ったサービスたちはコンテナ化されているため、それらのコンテナの起動管理についてはこれまで docker-compose を使っていた。しかし業務で Kubernetes を使う機会が多くなり、コンテナや Kubernetes の運用に関するいろいろな知見も溜まってきたので、自前で Kubernetes のクラスタが欲しくなったのだが、趣味にしては維持費が高い。正直そこまで可用性が必要もないが、 ArgoCD で GitOps による自動デプロイとかそういう楽なことだけはしたいという欲が湧いてきたので、 k3s をつかってシングルノードの Kubernetes を運用することにした。この記事ではその際どういったことをしたかなどをまとめる。

k3s のインストール

おもむろに k3s をいれるが、ワン・コマンドで入れられるので便利。なんならアップグレードもこれでできるのですごい。

curl -sfL https://get.k3s.io | sh -

ただしこのままだと kubectl を叩く度に sudo が必要になるので面倒。もう少しよしなにしたい。 Linuxbrew で入れた kubectl で使えるようにするために、 ~/.kube/config に接続設定を含めて出せばいちいち sudo しなくてもよくなる（セキュリティはパーミッションなど最低限のことはやったほうがよい）。

sudo kubectl config view --raw > ~/.kube/config

SealedSecret

Git で Kubernetes の Manifests を管理するとき、 Secret をそのままコミットすると危険なのだが、 SealedSecret を使うことで暗号化した状態にできる。暗号化を行うために一度クラスタに Secret を読み込ませる必要があったり、情報の更新が若干面倒というデメリットもあるが、そのあたりは GitOps したい度とのトレードオフだろう。

kubectl apply -f https://github.com/bitnami-labs/sealed-secrets/releases/download/${VERSION}/controller.yaml

${VERSION} は SealedSecret のリポジトリの最新を使うとよい。

Secret 情報の暗号化は kubeseal コマンドを使って行う。Secret の manifests が用意できていれば以下のようなコマンドを実行する。

kubeseal --scope namespace-wide -o yaml < secret.yaml > sealedsecret.yaml

ArgoCD

GitOps のために ArgoCD を入れる。 core-install.yaml はコア機能のみで Web UI などはインストールされない。

kubectl create namespace argocd
kubectl apply -n argocd -f https://raw.githubusercontent.com/argoproj/argo-cd/stable/manifests/core-install.yaml

初めて触れるなら Web UI はあったほうがよさそうに思う。リソースの管理がどういうものかとか、更新のタイミングなども見ることができるので面白い。

ArgoCD の使い方は公式のドキュメントが一番くわしい。

Getting Started - Argo CD - Declarative GitOps CD for Kubernetes

CLI で操作する場合は argocd コマンドなどを導入すると GitOps につかうリポジトリの登録や、実際のアプリケーションの設定などがコマンドからできて便利。

argocd repo add git@github.com:windyakin/k8s-manifests.git --ssh-private-key-path ${SSH_PRIVATE_KEY_PATH}

argocd app create argocd-applications \
  --repo git@github.com:windyakin/k8s-manifests.git \
  --path argocd-application \
  --auto-prune \
  --dest-namespace default \
  --dest-server https://kubernetes.default.svc \
  --revision HEAD

k3s 運用してみてどうか

もともとは microk8s を導入していたのだが、どういうわけか liveness probe を入れたあたりから Kubernetes の API が重くなってしまい、 kubectl すらまともに使えなくなってしまったため、 k3s に乗り換えたという経緯があった。コンテナを立てて運用する程度であれば k3s の機能でも十分であり、 microk8s に比べるとオーバーヘッドも少なく助かっているところではある。

またもともとやりたかった GitOps による運用ができたのも楽でよい。基本的にほったらかしで、監視等も入れていないのだが、不自然な挙動などはなく正常にうごいている。ただ貧弱なサーバーのシングルノードなので可用性の向上や、スケーリングといった恩恵は受けることは出来ない。 Kubernetes の美味しいところを知っていてそれにあやかりたい場合は、趣味の割り切りとして使ってよいのではないだろうか。

エマージェンシーコール～緊急通報指令室～

2022-02-23T00:00:00Z

ふと休日の夕方に見ていた NHK で放送されていた番組がすごくよかった。

エマージェンシーコール〜緊急通報指令室〜 - NHK

この番組の舞台は119番でつながる先にある緊急通報指令室。この回では横浜市消防局が取り上げられている。

命の危機が迫っているとき最初に頼る人たち

119番といえば命の危機が迫ったとき一番最初に頼るところでもあるのだが、その存在はあまりにも身近ではない。筆者自身119番にかけた経験はないし、できれば今後も書けることがないことを祈っているが、この番組ではその舞台でどういったやりとりが行われているのかを詳らかにしてくれている。

番組内では実際に起きた緊急通報の事例を、実際の指令室の音声とかかってきた電話の音声を加工・収録したものを使って再現しており、非常に緊迫した場面が伝わってくる。突然の事態に気が動転している通報者に対しても、ただ冷静に情報を聞き出しながら的確な指示を行う指令室の方たちにただ感服させられる。

番組の構成は至ってシンプルだがこれが一番おもしろい

番組は基本的に緊急通報の事例を取り上げながら進行していくが、ナレーションなどは一切ない。途中に指令室の方への軽いインタビューシーンなどを挟みながら、刻々と進んでゆく指令室の一日を描いていく。

この番組のフォーマット自体は海外の番組から輸入したもののようであるが、下手な脚色を加えたりされていない分、現場の非常に緊迫した雰囲気がリアルに伝わってくる。

最近他のNHKの番組でノーナレというナレーションのないドキュメンタリーがあり、そちらも面白いと感じていた。もしかしたらドキュメンタリーはナレーションがないほうが、余白が生まれ、それぞれのおもしろさにピッタリハマるのかもしれない。

これ以上はグダグダ言わないので見てくれ

NHKプラスに入会していれば3月2日まで見れるらしいのでもう一度リンクを貼っておく。

https://plus.nhk.jp/watch/st/g1_2022022327916

自分があれこれ言うよりも、この30分の番組を見てほしい。ドキュメンタリーが好きな人なら絶対好きなはずだし、そうでなくても自分がいざ119番するときの一助になるだろう。

Fluentd で使いたい Gem の依存関係の解決は Bundler に任せられる

2021-10-24T00:00:00Z

Fluentd は Gem によるライブラリの追加ができて、例えばログを直接 BigQuery に転送したいのであれば fluent-plugin-bigquery のような Gem をインストールしておくことによってそれを実現することができる。

こういったプラグインを追加するコマンドとして提供されているのが fluent-gem というコマンドで、例えば先程挙げた Gem をインストールしたいのであれば

fluent-gem install fluent-plugin-bigquery

のようにコマンドを叩けば Gem をインストールしてくれる。こういった Fluentd 向けのプラグインは rubygems.org にて様々提供されているので、使っているうちにあれもこれもと追加したくなるのだが、徐々にパッケージの依存関係がややこしくなっていき、最終的に人間による依存関係の解決はできなくなってしまう。

Fluentd でも Bundler が使える

Fluentd で使う Gem をインストールするためには fluent-gem という特別なコマンドを使うので、コマンドの裏ではさぞ特殊なことをやっているのだろうと思ったのだが、ソースコードを見るとそんなことはなく、ただ単純に Gem をインストールしているだけのようだった。

fluentd/fluent-gem at master · fluent/fluentd

また Fluentd の起動オプションには Gemfile を読み込ませる --gemfile オプションがあり、これで指定した Gemfile を使って起動時に Bundler が Gem をインストールしてプラグインが使えるようになる。

Plugin Management - Fluentd

つまり Fluentd においても Gem の依存関係の解決は Bundler に一任することができるようになっている。

Dockerfile にしてみる

例えば fluent-plugin-bigquery と fluent-plugin-google-cloud を同時に使いたい場合、このような Gemfile を書くことになる。

source "https://rubygems.org"

gem 'fluentd', '~> 1.13.x'
gem 'fluent-plugin-bigquery', '~> 2.2.x'
gem 'fluent-plugin-google-cloud', '~> 0.12.x'

Dockerfile ではビルド時に bundle install しておくことをおすすめする。 Fluentd の起動時にも bundle install は実行されるが、 Gem のインストール時に必要なネイティブライブラリなどは予め用意しておく必要があるからである。また Fluentd の公式イメージである fluent/fluentd をベースイメージとする際は、実行ユーザーが fluent になっているため、 apt-get install などを実行するのであれば予め root を指定する必要がある。ただし bundle install の実行ユーザーは fluent になっているほうがファイルの権限管理などに面倒がない。

FROM fluent/fluentd:v1.13-debian

COPY Gemfile Gemfile.lock /fluentd/etc/

USER root

RUN apt-get update \
  && apt-get install -y --no-install-recommends \
    build-essential \
  && apt-get clean \
  && rm -rf /var/lib/apt/lists/*

USER fluent

RUN cd /fluentd/etc \
  && bundle install -j8 --path vendor/bundle

CMD [ "fluentd", "--gemfile", "/fluentd/etc/Gemfile" ]

また、このとき Gemfile.lock をどう用意するかも考える必要があるが、一度 Gemfile.lock なしでビルドしたイメージから docker cp などを使って /fluentd/etc/ 以下にある Gemfile.lock を取り出すと一応用意することができる。

% docker build -t fluentd .
% docker run --rm -d --name fluentd fluentd tail -f /dev/null
% docker cp fluentd:/fluentd/etc/Gemfile.lock .
% docker kill fluentd

ここまでの流れをサンプルリポジトリにまとめたので参考までに。

windyakin/fluentd-plugin-gemfile-sample

Nuxt2でコンポーネントから今表示しているページのタイトル要素を取りたいとき

2021-09-29T00:00:00Z

Nuxt2 でコンポーネントから今表示しているページのタイトル要素を取りたいケースがある。

具体的に言うと Twitter のツイートボタンを自前で実装するときに使えるリンク形式でツイートを発行できる機能があり、このツイートするテキスト部分ににページのタイトルを含めたかった。

https://twitter.com/intent/tweet?url=[ツイートしたいURL]&text=[タイトルを含むテキスト]

このとき、 Nuxt のコンポーネント側からタイトルを知る方法として一番最初に思いつくのは document.title という JavaScript の古典的な API である。

export default {
  data() {
    return { pageTitle: '' }
  },
  mounted() {
    this.pageTitle = document.title
  }
}

これは確かに最初に表示したページやコンポーネントがロードされたタイミングのページのタイトルを取得することはできるが、 Nuxt 内に <nuxt-link> のを含んでいて、遷移の際にコンポーネントがそのまま表示され続けるような場合は値の変更がされない。考えてみれば「それはそう」だし。単純に自分の想定があまい。

じゃあページ変更をトリガーすれば良いんだろうということで、 $route を watch によって監視することでページ遷移のタイミングで document.title を取得し直せばよいのだろうということでこういうコードを書いた。

export default {
  data() {
    return { pageTitle: '' }
  },
  mounted() {
    this.pageTitle = document.title
  },
  watch: {
    $route(newValue) {
      this.pageTitle = document.title
    }
  }
}

しかしこれもうまく行かなかった。たしかに watch.$route はページ遷移のときに通っていくのだが、このタイミングで document.title を叩いても返ってくるのは遷移前のページのタイトルなのである。つまり document.title が変更される前にここを通っているため、ページ遷移をすると1ページ前に見ていたタイトルしか取得できないように見える。

最終的に StackOverflow でこういう記事を見つけた。

javascript - Add a watcher to document.title in Nuxt.Js - Stack Overflow

記事内のコードに書いてあるとおりで、HTML DOM を監視する JavaScript API である MutationObserver を使って <title> タグを監視して更新するといったもの。

書いてみるとまあ確かに動く（単純に Mutation Observer を使っているだけなので）。

export default {
  data() {
    return { pageTitle: '' }
  },
  mounted() {
    this.pageTitle = document.title
    new MutationObserver(() => {
      this.pageTitle = document.title
    }).observe(document.querySelector('title'), { childList: true })
  }
}

動いたのはいいが、なんだかもやもやするコードである。本当は上位から表示しているページのタイトルの内容を通知するといいのだろうが、 layout に埋め込まれているコンポーネントの場合、そのデータのやりとりが若干ややこしくなってしまう。正直ページタイトルを取得するためにそこまでやりたくはないし、こういうユースケースはよくありそうなので、できれば Nuxt 側で取れるようになってほしいなと思った。

GitHub Actions をつかって Google Cloud Functions にデプロイする

2021-03-19T00:00:00Z

Google Cloud Functions ってやつ、 Slack の Webhook 系のアクションだとか、情報を整形して別の API に横流しするだけの Proxy 系アプリケーションなんかのホスト先として便利に使ってたのだけども、その簡単さからCDの構築をサボっていて、よくリポジトリの状態と実際に展開されているコードが違うみたいな状態のまま放置してしまうなどどうにもうまく管理ができていなかったんですよね。まあ先述の通りそんなに重要なアプリケーションを管理しているわけでもないので、長らく自分の中での「動いてるからいいや」の代表的な存在だったのですが、やっぱりCVEなんかで報告されているような脆弱性を抱えるライブラリをそのまま放置するのはよくないなという気持ちになり、重い腰を上げてCD環境を整備することにしたのでそのメモ。

お誂え向き

もともとソースコード管理のメインは GitHub のリポジトリで、そのリポジトリを GCP の Cloud Source Repository にミラーリングし Cloud Functions にポチポチしてデプロイするみたいなフローだったのだけども、いつからか Cloud Source Repository に自動で反映されなくなってしまい（調べてないがおそらく Webhook の設定がおかしいのだと思う）、直せばいいのだけど「面倒だな」と思って放置した結果、「面倒だな」の連鎖が発生してやる気を完全に削ぐ原因になっていた。で、「じゃあ GitHub Actions から直接 Cloud Functions にデプロイできねえのか」と思って探したらすんなり見つかったんだよね。さすが2021年。

google-github-actions/deploy-cloud-functions: A GitHub Action that deploys source code to Google Cloud Functions.

「え〜めちゃくちゃ便利じゃん〜」と思って早速使おうと思ったのだけど、なぜかリポジトリの Star が2021年3月時点で30個ぐらいしかついてなくて、 Organization の名前に「google」って入ってるけど非公式なの？と思って調べたのだけど、 People 欄に表示されている人が Google の公式 Organization にも所属しているのでおそらく大丈夫なのだろうと（本当に最近できた Org なのだと思う）。そんなわけで実際に使ってみることにしたわけ。

サービスアカウントを作る

Actions を実行するためには当然だが Cloud Functions にデプロイするためのサービスアカウントのキーが必要になる。GCPのアカウント権限周りの設定は毎度わからんという気持ちになるがこのような愚痴はグッと飲み込んで、プロジェクトの「IAM と管理」→「サービスアカウント」の画面から cloudfunctions.serviceAgent (Cloud Functions サービスエージェント) 権限を持つアカウントを作成してやる。その他の「条件」は必要であれば入れる。鍵が流出したときのリスクとかを制御できるのでそう考えると入れたほうがよいのは当然なのだが、使い回すにはいちいちアカウントつくったりしなきゃならんので個人管理のものであると面倒である。

そのままサービスアカウントのキーも作成してしまい、発行された JSON キーをそのまま GitHub リポジトリの Settings → Secrets へ登録するとよい。

Actions のジョブにデプロイするステップを追加する

このとき設定できる内容については google-github-actions/deploy-cloud-functions の README を見れば全て書いてくれている。注意したい点としては環境変数を与えているのであればここで指定しておく必要があるということ。

- id: deploy
  uses: google-github-actions/deploy-cloud-functions@main
  with:
    name: clound-functions-application
    runtime: nodejs12
    entry_point: application
    credentials: $
    env_vars: >-
      SECRETS_ENVIRONMENT_1=$
      ,SECRETS_ENVIRONMENT_2=$

たいてい秘匿情報とかがあるので Actions 側の Secrets に登録する羽目になる。複数ある場合なんかはカンマで繋げる必要があるが YAML のヒアドキュメントである >- なんかを組み合わせて使うと改行できて便利。

実際に動かしてみる

実際に Actions を動かしてみると、おお動くという感じになると思う。デプロイにはすこしだけ時間がかかるものの、 Actions 側はデプロイしたアプリケーションが適用されたことを確認できるまでポーリングするので Actions が終了したらデプロイが完了したものと思えば良さそう。

これで GitHub のリポジトリが Google にミラーリングされているかどうかを気にしたり、デプロイのためのポチポチ業から開放されたわけだ。便利。

curlコマンドでHTTPステータスコードだけを取得する場合は--write-outオプションを使うと良い

2021-03-09T00:00:00Z

シェルスクリプトを書いているとcurlコマンドなんかで指定したURLのHTTPステータスコードだけがほしいという場合がある。

結論から言うと --write-out / -w というオプションを使うと実現できる

% curl -s -o /dev/null --write-out "%{http_code}" https://www.example.com/
200

-o /dev/null にしているのは取得内容を標準出力に表示しないようにするもので、こうすることで文字列として出力されるのはHTTPステータスコードだけになりパイプやシェルスクリプトで処理がしやすいなどのメリットがある。

`--write-out` で出力できる内容いろいろ

ところで --write-out とはなにか。こういうとき、脳死でGoogle検索すると上位にQiitaというウェブサイトがでてきてしまうのだが、原典をみるのが一番確実である。

curl - How To Use

curl が指定URLにアクセスしたときに取得する様々な情報を簡易的なテンプレート表現で出力させることができるコマンドで、HTTPステータスコードの %{http_code} 以外にも、アクセスのために必要な処理にかかった各種の時間なども出力させることができる。

curl のバージョンによっては使えないパラメータも多々あるので、手元のバージョンで使えるものを確認するには curl --manual で --write-out の項を確認するとよい。

windyakin.net

Notion + Astro + Cloudflare Pages で作ったブログ

XとYouTubeを見なくなって4ヶ月経った

# 各種サイトを見れなくし、注意を逸らすものを切る

# 可処分時間の増加

# スマホが「つまらないもの」になった

# 情報メディアの変化

# 新聞を読むようになった

# 退化ではなく選択

Twitterの報酬系を刺激する部分だけを取り出してウェブツール化した

# 何ができるのか

# Claude Code

# この先

# 結論

Aqours の Finale ライブへ行くために、ラブライブ！サンシャイン!!ラッピングバスの貸切運行をした

# バスを借りて会場入りした

# 会場入りできるバスを探せ

# 運行ルートと駐車場

# 富士急トラベルとの面談

# 運行にあたっての募集

# 沼津のめぐみ！いろどり弁当

# LED行先表示器風のボード

# 出発、沼津と内浦を心に刻む

# 下車

# 感想

Finale ライブを迎えるにあたって

今の感情

# 生放送を見た

# 自分の今の気持ち

# 沼津のこと

# いろいろ考えて

# 1年後、この記事を見た自分へ

地方移住者が移住者のためのコミュニティを立ち上げたら100人集まった話

沼津に引っ越して3年で得た変化

# バイクを買った

# 自然現象に関心を持つようになった

# 新幹線で通勤するようになった

# 自動車を買った

# 馴染みの店ができた

# ラブライブ！サンシャイン!! の勢いがとどまることを知らない

# 良いことばっかり言っているがデメリットはないのか

# 4年目にやっていきたいこと

# さいごに