@kyanny's blog

My thoughts, my life. Views/opinions are my own.

GitHub Storage GB-months/GB-hours Converter

恥ずかしながら GitHub Spark で作った Web アプリを公開できることを知らなかった（社員なのに）。GitHub Pages にデプロイするより楽かつ自由度が高そうなので、GitHub Actions と GitHub Packages のストレージ使用量を計算・変換するツールを Spark で作ってみた。

現状、Spark で作ったアプリへのアクセスには GitHub アカウントでのログインが必要。

作った動機は、ストレージ使用量の GB-month と GB-hour の関係・変換方法がよくわからなくなってしまったから。以前からわかったような、わからないようなあやふやな感じで、Sample storage cost calculation の例を凝視してようやくわかったような気になる、というふうに苦労していた。

この例を丸ごとコピペして、「この仕様に基づいて、GB-month と GB-hour を変換するアプリを作って」と Spark に投げ、あとは提案を適当に受け入れたりしつつ（料金計算機能とか）、途中から思うように操れなくなったので Spark のプロンプトで命令するのは諦めて、リポジトリを作成→Codespaces を作成して Codespaces 内の Copilot Chat (agent mode) に細かい指示を出して完成させた。

ワンクリックデプロイで公開するところまで一気通貫でできるのは確かにものすごく早い。小難しいプロジェクトセットアップやライブラリのインストールは一切不要だし、基本的には待ってるだけで、最初のバージョンがデプロイされるまで 10 分もかからなかった。それでいて、最初からそれなりに完成度が高いものを出してくる。

ただ、細かい調整は苦手のようで、GB-month と GB-hour の入力欄の上下位置を入れ替えて、という命令は何度言ってもうまくできなかった。プロンプトが悪かったのか、ソースコード内での位置を確認して「すでに正しい順番です」とか判定していた。かつ、Spark の UI 上で直接コードを編集すると、ちゃんと反映されてるのかよくわからない感じになるし、後続のプロンプトで作業するときに巻き戻されたりして、制御が難しいと感じた。

あと、Spark 上で追加作業させたものが気に入らなくて「前のバージョンに戻して」と言うと、そのさらに前の、消したくない変更を消しに行ったりして、この辺りも扱いが難しいと感じた。おそらく vibe coding をする人は皆経験することなんだろうと思う。

■

謎の夢を見た。

個人のウェブサイト、英語で書かれている。、ブログだろうか、白地に黒文字のひどく殺風景なもので、いくつかの記事のリンクが「過去ログから復元」などとメモ付きで載っている。簡潔な文章で、ページの内容も長くはない。

そのページの最後のセクションに、個人ウェブサイト・ブログの歴史と役割、いかに進化してきたか、みたいな話の締めくくりとして、

これの最も興味深い例が KYANNY.ME である。このウェブサイトの主催者は、かつてコンテンツをインターネットに公開して、自らの考えを誰でも読めるようにしていた。

これはリスクをはらむ行為だが、云々

（細かい表現はやや異なるかもしれない、interesting ではなく、もう少し堅くて珍しい語彙が使われていた気がする）

などと（英語で）書いてあり、なぜ突然自分のドメインが言及されてるんだ？しかもなぜ過去形？と驚き、しかしこれが夢であることもわかっていたのだろうか、もうすぐそのテキストを読めなくなってしまうその前に少しでも覚えようと頑張って暗記して、

なぜか場面が変わってスーパーマーケットにいて、その文章の影響で自分のドメインに関心を持った人がいるか気になって、店内を歩きながら KYANNY.ME という文字列を検索してエゴサーチしていた（手元で文字列検索をかけると、店内の商品や客の手元のモノに検索クエリがヒットすると黄色くハイライトされる、という謎の仕組み）

過去形だったのは、これの影響で http(s)://kyanny.me/ にアクセスできなくなってしまったので、ある意味正しい（自らの考えをそこで公開していたわけではないが）。気にはなっているけど、自分で思っているより強く気掛かりなのかもしれない（インターネットに公開したものを取り下げることには、昔から強い抵抗があるので）

夢の中で読んだテキストの文脈では、「興味深い例」が指しているのはこのブログのことだと思うが、ここにも「自らの考え」を、かつてほどストレートに綴らなくなったので、その意味でも過去形なのはある意味正しく、やはり自分でも気になっているんだろうな、と思った。

最近は夢を見る（あるいは、見た夢を・夢を見たことを覚えている）ことが多く、だいたいどこかしらちょっと変なのが常だが、ウェブサイトを読んでる夢は初めて（あるいは、覚えていたのが初めて）で、ちょっと驚いた。

JINS のドライブレンズ（ドライブナイト）

夜間の運転用に新しい眼鏡を買った（手に入るのは来週）。

対向車のライトが眩しいときがあるのと、雨が降ると路面に光が反射して車線が全く見えなくなることがあり、怖いなと感じていた。去年から欲しいと思っていたけど、ようやく重い腰を上げた。

他社製フレームのレンズ交換もできるらしいので普段使っていない眼鏡を運転用にしようかとも思ったが、「予備のメガネはあったほうがいい」との奥さんのアドバイスに従って、フレームごと新しく買った。夜の運転中しか使わないので、フレームは店頭セールで安売りしていたものの中から適当に選んだ。視力検査もせず、日中の運転用の眼鏡と同じ度数で依頼した。

JAF の 10% 割引クーポンがあったがセール品には使えない、はずだったがレンズの価格には適用できるとのことで、数百円だけ安くなった。

果たしてどの程度効果があるのか、実感できるのか、気休め程度かもしれないが、ものは試し。

ドライブメガネ・サングラス（運転用レンズ） | JINS - 眼鏡（メガネ・めがね）

おまかせBIG(定期購入)見直し・おまかせtoto(定期購入)開始

二年前 に始めたおまかせBIGの定期購入を見直した。

これまで:

  • 100円BIG x 1 (100 円)
  • BIG1000 x 1 (200 円)
  • mini BIG x 1 (200 円)

これから:

  • 100円BIG x 3 (300 円)

同じタイミングでおまかせtotoの定期購入を始めた。

  • 下位が上位に勝つ：設定する（4試合）
  • ホーム/その他/アウェイ：設定する（5：4：4）
  • 買われていないパターン：買わない × 1口、買う × 1口

どちらも開催回ごとに購入。

計2口で200円なので、合計500円は変わらず。

Jリーグの試合や結果を見たり気にしたりするようになってきて、対戦カードによっては勝敗を手堅く予想できそう（少なくとも完全にランダムよりは確率が高そう）だな、と思って、これまで難しそうだと敬遠していた toto を見てみたら、3〜4試合くらいは結構自信を持って予想できる感触があった。

BIGの運任せよりも、当選金は減っても確率が上がるほうがいいんじゃないか、とか色々と考えて、

  • 100円BIGの口数を三倍に増やす（当選確率三倍）
  • 当選金の低いものをやめる
  • 浮いた分でおまかせtotoを試してみる

という感じに。toto自体も割とさくさくと予想できる感触があるので、自分で予想して買うことが増えたらおまかせはやめるかもしれない（予算の都合上）。

なお、丸二年のおまかせBIGで、当たったのは一番低いもの（数百円〜数千円）が二、三回ほどで、一万円にも届いていない。BIGは年間50〜52回開催されるらしいので、500×51×2=51,000 くらい使って、一割ちょっとの回収率か。あとでちゃんとデータを集計したい。

SFDC (Salesforce.com) Account Checker

仕事で、複数の Salesforce.com (SFDC) アカウント URL が同じアカウント ID のものか確認したくなることが、たまにある（月に数回程度）。URL は以下の 2 パターンが存在する。

  1. https://example.lightning.force.com/001ABCDEF123456AAA
  2. https://example.lightning.force.com/lightning/r/Account/001ABCDEF123456AAA/view

アカウント ID は 001 で始まる 18 桁の文字列で、上記の URL のように縦が揃ってないとぱっと見では同じかどうか判断しづらい。

URL をコピペしてテキストエディタで改行・削除したりするのも手間だし、かといってプログラムで処理するのも意外と手間で、ワンライナーや irb で秒殺というわけにはいかない。

ちょっと気が向いたタイミングだったので、チェッカーを作った。ブラウザで操作しているときに（URL をコピペしつつ）チェックしたいケースばかりなので Web アプリにした。

kyanny.github.io

最初は CodePen に手書きで書いていたが、エラーハンドリングなどに凝り出すと煩雑になってきて、フレームワークを使ったほうが良さそう。しかしどのフレームワークもソラで書けるほど習熟していない。そこで VSCode の Copilot (Agent mode) を使って実装させた。モデルは Claude Sonnet 4 を使った。

まず、Vue.js の最小構成プロジェクトを作らせ、出来上がったアプリを改良していったが、直接 Chat に指示を書くのではなく、README.md に仕様を日本語で箇条書きにして、テキストを選択→「選択した仕様を満たすようにアプリを修正してください」という形で指示を出した。機能追加も、追加仕様を追記して、その部分だけ選択して同じように指示を出した。

自分では一行もコードを書かず（プロジェクト名の文字列を一度変更したが、それすら Agent にやらせた）、ここまでのものができるのは確かにすごい。動作検証も含めて 30 分くらいでできたと思う。GitHub Pages サイトへのデプロイ方法を調べるほうが時間がかかったくらいかもしれない。見た目などの部分は、自力で作っていたらもっと殺風景なものにしかできなかっただろう（そもそもそこそこの見栄えレベルを目指しすらしなかっただろう）。

URL に含まれる ID が同じなら同じ、異なっていれば異なると結果を表示し、ID 文字列はコピペしたくなるケースもあり得るのでコピーボタンをつけ、ID 文字列で GitHub Issues を検索して「検算」したいケースもあるので GitHub Search するボタンもつけた。たとえば以下の URL のうち上二つをチェッカーにかけると一致と出るし、三つ全部をチェッカーにかけると不一致と出る。

https://example.lightning.force.com/001ABCDEF123456AAA
https://example.lightning.force.com/lightning/r/Account/001ABCDEF123456AAA/view
https://example.lightning.force.com/lightning/r/Account/001XYZ7890ABCDEBBB/view

なお、これらのアカウント ID は Copilot に聞いて生成させたダミー ID なので実在するかどうか不明だし、サブドメインも実際のものとは異なる。

GitHub Pages サイトへのデプロイもそこまでつまらずできて一件落着、と思いきや、独自ドメインではまってしまった。kyanny.me をもともと GitHub Pages サイトで公開していて、以前は HTTPS でも公開できていた気がするが、GitHub Pages の仕様が変わったのか、HTTPS だと証明書エラーになってしまっていた。SFDC Account Checker も kyanny.me ドメインで公開されたが、Enforce HTTPS にチェックを入れられず、HTTP で後悔することになってしまった。Cookie も使っていないページとはいえ、今どき http:// で公開するのはちょっと、ない。ということでどうにか解決しようと雑に調べて回ったが、一向にわからない。ドキュメントを読んでもさっぱりわからない。おそらく、そもそも kyanny.me ドメインに対する証明書を誰も発行してないから、ということなのかな、とぼんやり当たりがついたが、面倒くさすぎるので kyanny.me を GitHub Pages で公開すること自体をやめるという荒療治で無理やり辻褄を合わせた。実際にやった作業は、kyanny/kyanny.github.io というリポジトリの Pages を無効化した。念のため、Pages の設定画面で DNS 検証失敗？みたいなエラーになっていた kyanny.me カスタムドメインを削除してから無効化した。すると自分のアカウントのリポジトリから Pages に公開したサイトはカスタムドメイン kyanny.me ではなく kyanny.github.io ドメインで公開されるようになり、自動的に HTTPS も有効になった。