2024-06-29に向けてjune29の残党を狩っていく (済!) ✎ #juneboku

2023-06-29に転生したらjunebokuだった件をやって、おおむねスムーズに転生できたと思う。

上記については移行にハードルがあってjune29を使い続けてきた。けれどもjunebokuに移行するに越したことはないので転生から1年を迎える2024-06-29までに移行できるように、具体的な移行の手順を考えていきたい。

こんな感じに進めていけたらいいな

june29.jpドメイン

june29.jpはブログ形式のウェブサイト
- 2006-06-29から蓄積してきた記事群があるので、基本は保全を続けるつもり
- Hugoで出力した静的なHTML/CSS/JavaScriptたちを置いているだけなので維持コストは低い
api.june29.jpはjuneboku的ななにかに移行したい
- juneboku.app的ななにかを用意して、そこに機能を並べていこうか
- これが済んでからの方がScrapboxの移行をやりやすいんだよな〜〜

新しくjunebokuプロジェクトをつくる
june29プロジェクトのデータをエクスポートする
junebokuプロジェクトにデータをインポートする
june29プロジェクトにアクセスした人に向けての移行案内を表示したい
- プロジェクト名を「今後は /junebokuを見てね」のようにしておく？
- カスタムのCSSで「今後は /junebokuを見てね」を表示させておく？

いけそうな気がしてきた。

api.june29.jpの日記短縮リンクのやつ、リダイレクト先をjunebokuに変えた方がいいってことに気付いた
- api.juneboku.xyz的なやつを用意して、今後の分はこっちに寄せていくといいかなあ
  - インポートする前にapi.june29.jpをぜんぶ置換できるといいな
app.juneboku.xyzをつくったので、こっちに寄せていく
https://api.june29.jp/nikki/yyyy-mm-dd へのアクセスを https://app.juneboku.xyz/nikki/yyyy-mm-dd にリダイレクトするだけの簡易なアプリケーションをapi.june29.jpで動かしておけばいいかな
- FaaSで事足りるくらいの要件
- Cloudflare Workersでも使ってみると楽しいかな

新規にjunebokuユーザを用意して、必要なリポジトリに招待してもらう
手元のGitの設定もjunebokuに合わせて、どうしても必要なときだけjune29を呼んでくればいいか
- git-configの動的切り替え機能を活用するなどして、なんとかなるでしょう
  - https://git-scm.com/docs/git-config#_conditional_includes

自分はまた転生をやりたくなりそうなので、今後はなるべくUserよりOrgにリポジトリをつくって、Userを乗り換えたときの影響が小さくなるようにしていくといいかも
- https://github.com/junebako というOrgをつくったので、ここを使っていこかな

2024-06-17やったこと
- /june29 からページのデータをエクスポートして、あらたにつくった/juneboku にインポートした
- /june29/このプロジェクトは更新を停止して /junebokuに移行しました

2023年に転生しまして、june29からjunebokuの移行を進めてきた。

2024年の夏には魂の移行がだいたい済んだが、GmailとGoogle Calendarについてはjune29時代のものを使い続けているところがあって。他者にカレンダーの予定を入れてもらったりファイルの共有を受けるときに juneboku@ じゃない、ってのがややこしい。

ここも気合いを入れて juneboku@ に寄せていこうかな、と思えてきた。相手から見える部分のメールアドレスは juneboku@ に揃えられたらいいよな。やっていくか。

ウェブブラウザのプロファイルを整理していたら、そういう機運が高まってきた。