Lycolog

前回の記事からすると約一年ぶりの更新となる変革シリーズ。

今回はケトルから電気ポットへの先祖返りということで、電気ポットを買ってきた話をする。

ケトルのあった風景と、電気ポットに置き換えた風景

ケトルは省スペースでコンパクトだった。

電気ポットは場所を取り、やや目立つ。

ケトルを電気ポットに変えた理由

漆器の摩耗防止

まず一つは漆器の摩耗防止だ。直湯調理による漆器椀の摩耗を抑えるでも書いたが、漆器は高温に弱い。

これまでは湯を注ぐ前に具を敷き詰めたり、水を敷いたり、ケトルを沸騰させてしばらく放置したり、ケトルが沸騰する前に止めたり、様々な施策をしていたが、疲れた。

前述の記事にもある通り電気ポットにすればそもそも90度で止まるのだから何も考えなくていい。これが理由の一つだ。

沸騰した湯が熱すぎる

うちのケトルには温度調整機能がないので基本的に湯温は100度になる。すると、これでお茶やインスタントみそ汁を作ると100度のものができる。

そんな熱いものは飲めないので氷を入れたりしないといけないが、氷は事前に用意してないと切らしていることもある。そうすると氷の管理が面倒だし、氷を入れるときにお湯が跳ねてその辺りに散るのも面倒だった。

電気ポットなら90度設定にしていればここは気にする必要がない。

連続して使いづらい

ケトルで湯を沸かしスープを作って飲んで、しばらくしてまた飲みたいとなると、また水を入れて沸かさないといけない。予め多めに注水していても基本的に沸かし直しが必要で面倒だ。

電気ポットは多くのモデルがケトルより容量があるので、この辺りは改善される。実際、今回買った電気ポットもケトルの約3倍の容量がある。

湯がすぐに使えない

ケトルは毎回沸騰させるのですぐにお湯を使えない。一々待っているのも面倒だし、放置してたらいつの間にか時間が過ぎ去って冷めていることもざらにある。

電気ポットはあらかじめ水を入れていれば常にお湯がすぐに出るので便利だ。欠点としてはお湯を入れ忘れてると詰むことくらいだが、その時は鍋で沸かせばいいだろう。

あとがき

今まで使っていたケトルは2020年製で、当時使っていた電気ポットの調子が悪くなってきたので買い替えた記憶がある。

Xのアーカイブから当時の景色を眺めた限り、当時は電気ポットかケトルのどちらかを買うかについて「ポットの方が良さそうだけどケトルを使ったことがないから使ってみよう」的な判断をして買い替えたようである。それから5年半でポットに戻ってきた辺り、私にはポットの方があっていたようだ。

しかし電気ポットの価格を見て驚いた、私の記憶違いかもしれないが昔はこんなに高くなかったような…？というので、中々おいそれと買い替えするのも難しいなと思った。いや、そんな気分で買い替えなくていいとは思うが…ｗ

取り敢えず15年くらいは持ってくれるはずなので、当面はこれを使い続けるだろう。

それとポットの前面についても色々あり、反った形になっているもの、絶壁のような形になっているもの、凹んでいるものがあった。

注ぎ口の下が出っ張ってると器の縁に湯がかかったりして使いづらそうだし、絶壁になっているのも使いづらくないのかな？と思った。

個人的には前面が注ぎ口の下に向かって凹んでいる方が器を奥まで押し込めるので、注ぎやすいと思ったが、もしも大きなお皿に注ぎたいとかある場合は、凹んでいる方が左右の出っ張りが邪魔で逆にやりづらいとかはあるのかもしれない。

幾つかのポットを指で測ってみたが、注ぎ口と本体の差は中指1.9～2.3関節分が最も多く、今回買ったタイガー魔法瓶の製品は第三関節まで行けたので、かなり深みがあった。

深みがあると、このように器をセットしたときにいい感じのところまで来てくれるので便利である。

UIが余りにも好みではなかったので戻した時のログ。

結論から言うと簡単に戻せた。

• 確認環境
• 手順
• あとがき
  • 切り戻した動機
  • UIが嫌なのにバージョンを上げた理由
  • どうにかして元に戻そうとした夢の跡
• あとがきのあとがき

確認環境

• バイナリから起動しているMastodon
• Mastodon本番環境をGitで管理している

手順

1. DBのロールバックを行う。34世代前に戻すと4.5.4になる

   RAILS_ENV=production bundle exec rails db:rollback STEP=34
   

2. 4.5.4時点までgit revertする
   • 参考ログ
3. Mastodonのアップグレードと同じ方法でコマンドを叩いてゆく

   sudo su - mastodon
   # Rubyのアップデート用
   cd ~/.rbenv/plugins/ruby-build
   git pull
   cd ~/live
   RUBY_CONFIGURE_OPTS=--with-jemalloc rbenv install
   # install
   bundle install
   yarn install
   # DBがアカンことがあるので叩いておく
   RAILS_ENV=production bundle exec rails db:migrate
   # いつものリビルド
   RAILS_ENV=production bundle exec rails assets:clobber
   RAILS_ENV=production bundle exec rails assets:precompile
   exit
   # 再起動
   sudo systemctl restart mastodon-web mastodon-sidekiq mastodon-streaming
   

4. 動いてれば終わり

あとがき

切り戻した動機

v4.5.4	v4.6.0

4.5系から4.6系でUIが大幅に変わること自体は知っていたが、UIの変更が余りにも多く、個人で元に戻せるレベルではなかったため切り戻しすることにした。

app/javascriptやpackage.json, yarn.lock, config/viteを戻してもバックエンドと結びついてるやつがいるようで上手くいかなかった。

以下、v4.6.0で気に入らなかった部分の一例。端的に言うと目が痛いし、ダサい。

フォロー・フォロワー一覧にある「フォローされています」が余りにもデカく、ダサすぎる。

また二枚目にある便利メニューが消えた。私はこの便利ボタンを頻繁に使用しているため非常に困った。このボタンそのものは簡単に復活させられた。

日本語翻訳がまた消えた。翻訳が消えるのはMastodonにはよくあることだが毎回翻訳キーを調べて書き換えるのが嫌になった。ここ以外にも未翻訳部分はある。

ユーザーハンドルのポップアップが変わった。前の方が良かった。説明が薄いし、Copy handleのボタンも直感的でないと思う。あと翻訳してほしい。

左に寄りすぎたタブと、直感的でなく操作に手数がかかるフィルタUI。返信を表示は今までタブとしてあったのに、4.6.0では「投稿とブースト」プルダウンをクリックし、トグルボタンを切り替えないといけない。これはとても直感的でないと思うし、そこまでして操作したくない。

自己紹介編集画面が縦長になりすぎた。自己紹介の編集画面が空白まみれになり縦長になりスクロールが必要になったうえ、更に個別の項目に編集ボタンがあり、編集しづらい。なんで初期状態で編集可能にしないのか…。

自己紹介の補足情報が一行に複数入って気持ち悪い。

自己紹介で絵文字が出ない、要素が変に改行されたりトリムされている。

ハッシュタグのコントラスト比が高く目が痛い。

スクロールバーが太くなった。スタイリッシュさが消えた。

テキスト入力欄にフォーカスが入ると枠が出るようになった。光りすぎてて目が痛い。

未読チェックが左側に出るようになった。右側に出てくれた方が押しやすい。スクショ貼るのが面倒なので以降スクショなし。

タイムラインのメニュー展開ボタンが左側に出るようになった、右側にｒｙ。

非ログインユーザーの表示が標準ではライトテーマになっており、見た目を調整するには両方のテーマを直すか、ライトテーマを消し去るしかなく、UIの保守コストが増大した。（厳密にはブラウザのテーマによって変わる）

UIが嫌なのにバージョンを上げた理由

実はこうなることは事前にある程度知っていたのだが、Wrapstodonが使いたかったからバージョンを上げたところがある。

しかし全く容認できないUIだったため切り戻すことにした。

どうにかして元に戻そうとした夢の跡

4.5系のUIを部分的に復活させた #4で、vibe codingを利用して直そうとしたものの、破綻が酷く、結局半分くらい自分で書いたが、結局変更箇所が多すぎてどうにもならなかった。

あとがきのあとがき

取り敢えずDBを壊さず、ロールバックもせず綺麗に戻せてよかった。

あるリポジトリのファイルだけを抜いてきて新たにgit管理していたが、元々のリポジトリの履歴と繋げたくなったのでやった内容。

リベースやマージを経ないためコンフリクト解消が不要でお手軽。とにかく履歴さえくっつけばいい場合に向く。

確認環境

MSYS2上のGitで確認している

前提

• 元となったリポジトリをA、リポジトリAの履歴を捨てて新しく作ったリポジトリをBとする
• どちらにもmainブランチしかないものとする

手順

1. 事故が起きると面倒なため、まず作業用フォルダを作る
2. リポジトリAをgit cloneする
3. 最新のコミットハッシュを取得する

   git rev-parse HEAD
   

4. この状態でリポジトリBをリモートリポジトリに追加する

   git remote add new リポジトリB
   

5. リポジトリBを別ブランチにチェックアウトする
6. チェックアウトしたブランチで最古のコミットハッシュを取得する。過去に連結歴のあるリポジトリでやると複数出るので注意

   git rev-list --max-parents=0 HEAD
   

7. メインブランチに戻る
8. 元となったリポジトリAに、新しいリポジトリBを繋ぎこむ。
   この時、リポジトリB側のコミットハッシュはすべて変更され、署名も消える

   git replace --graft リポジトリBの最古のコミットハッシュ リポジトリAの最新コミットハッシュ
   

一括でやるコマンド

上に書いたことをコマンドに落としただけのもの。動作確認はしていない。

$new_repo=/path/to/.git
BASE_END=$(git rev-parse HEAD)
git remote add dest $new_repo
git fetch new
git checkout -b new dest/main
NEW_START=$(git rev-list --max-parents=0 HEAD)
git replace --graft $NEW_START $BASE_END

あとがき

リベースもマージもgit mvも何もせず、異なるリポジトリを無理やり繋げたのにも拘らず、ファイル名の変更が繋がってるのが凄いと思った。

恐らくAとBで同じパスのファイルがあれば、それは同じものとして繋げてくれていると思うのだが、これは便利だ。

これによってリポジトリを分離する前の履歴が見れるようになり、過去の経緯が追えるようになったので助かった。

あとMSYS2のGitは非常にパフォーマンスが悪く重いので、こういう作業で使うと非常に遅かった。

ステータス管理画面のCachetをさくらのレンタルサーバーに設置したときのログ。

開発版の3.xを利用しているが、軽く叩いた感じはとりあえず使える気がする。

• 確認環境
• 手順
• 備考
• トラブルシューティング
  • Illuminate\Database\QueryExceptionが出る
• あとがき
  • ステータスページを作る以上の機能が中区、外形監視はしてくれなかった
  • 親切だったユーザー作成ウィザード
  • 簡単なものなら自作できそう
  • ほぼ自分しか使ってないサーバーのためにこんなリッチなものが必要なのか…？

確認環境

確認時点でのさくらのレンタルサーバーではSQLiteでの動作は出来なかった。これはPHP拡張がJSONをサポートしていないからと思われる。

Cachetには正確なバージョン番号がなさそうなのでコミットハッシュを書いている。最新のハッシュのコードが入っていることを確認済。

またCachet 3.xの中身は事実上からっぽで、vendor/配下にあるcachethq/coreが本体なので、そちらのバージョンも併記している。

手順

以下のコマンドはすべてzshで実行しているため、さくら標準のcshでは動かない箇所があるかもしれない。

1. composerがなかったのでcomposerを入れた。ここから先は~/bin/にPATHが通っていることを前提で進める

   php -r "copy('https://getcomposer.org/installer', 'composer-setup.php');"
   php -r "if (hash_file('sha384', 'composer-setup.php') === 'c8b085408188070d5f52bcfe4ecfbee5f727afa458b2573b8eaaf77b3419b0bf2768dc67c86944da1544f06fa544fd47') { echo 'Installer verified'.PHP_EOL; } else { echo 'Installer corrupt'.PHP_EOL; unlink('composer-setup.php'); exit(1); }"
   php composer-setup.php
   php -r "unlink('composer-setup.php');"
   
   mkdir ~/bin
   mv composer.phar ~/bin/composer
   

2. Cacheの取得と設置

   git clone -b 3.x https://github.com/cachethq/cachet.git
   cd cachet
   
   composer install --no-dev -o
   # composerでエラーが出てupdateしろといわれたためupdate、これでインストールまでしてくれる
   composer update
   # 本体のアップデート
   composer update cachethq/core
   # 環境変数の編集
   cp .env.example .env
   

3. .envの編集
   デフォルトでAPP_DEBUGがtrueなのでfalseにした方が良い。まだ開発版のためかTIMEZONEを設定してもトップ画面には反映されない。管理画面の一部では反映される。

   APP_DEBUG=false
   APP_TIMEZONE="Asia/Tokyo"
   APP_URL=https://status.example.com
   DB_CONNECTION=mysql
   DB_HOST=DBホスト
   DB_PORT=3306
   DB_DATABASE=データベース名
   DB_USERNAME=データベース名
   DB_PASSWORD=パスワード
   

4. Cachetのセットアップ

   php artisan key:generate
   
   php artisan vendor:publish --tag=cachet
   php artisan migrate
   
   # envを閲覧不能にする
   cat <<'EOF' | tee .htaccess
   <Files .env>
   deny from all
   </Files>
   EOF
   
   # 403になることを確認
   curl https://status.example.com/.env
   
   php artisan cachet:make:user
   

5. crontの設定。ステータスページ表示する機能しかないのにやる意味があるのかは謎。

   *   *   *   *   *   php /home/<username>/www/path/to/artisan schedule:run >> /dev/null 2>&1
   

6. さくらのコンパネからドメインを開き、Web公開フォルダーをpath/to/cachet/publicにする。

備考

Cachet v3.x is currently in development and not yet released. The following instructions are intended for development purposes only and are subject to change.

現時点では上記のようにあり、開発版なのでバグはあると思われる。

トラブルシューティング

Illuminate\Database\QueryExceptionが出る

SQLiteを使っていて次のようなエラーが出る場合、MySQLに変えると直る。恐らくさくらのレンサバに入ってるSQLite拡張がjson_eachをサポートしてないのが原因。

!Illuminate\Database\QueryException

Internal Server Error


SQLSTATE[HY000]: General error: 1 no such table: json_each (Connection: sqlite, SQL: select *
from "webhook_subscriptions" where ("send_all_events" = 1 or exists (select 1 from
json_each("selected_events") where "json_each"."value" is component_updated)))

Expand vendor frames

app/Http/Middleware/TrustProxies.php :32

あとがき

ステータスページを作る以上の機能が中区、外形監視はしてくれなかった

外形監視をして、その結果をステータスに表示してくれるツールだと思っていたら、ステータスの設定を行う機能と、それを表示する機能しかなかった。

つまり手動でメンテナンス中とか出したり、外形監視からAPIを蹴って何か表示するのには使えるが、このツールにはそれ以上の機能はないようだ。

これはダッシュボードを作る画面とAPIを提供してくれるツールということだ。

親切だったユーザー作成ウィザード

install.phpにアクセスして設定を書き換えるみたいな、一瞬ではあるものの脆弱な瞬間がないのは便利だと思った。

簡単なものなら自作できそう

Cachetは画面操作によってステータスを変えたり、履歴を出したりできるが、curlを投げて落ちてたら画面に表示くらいならパパっと作れそうだなと思った。

とはいえ、画面のリッチさや、APIからも操作できることなどを考えると、そんなのを作るのも大変なので、Cachetのようなツールを使った方が楽なのは間違いない。

ほぼ自分しか使ってないサーバーのためにこんなリッチなものが必要なのか…？

まぁあった方が豪華だし…みたいな…。

保守やオペのコストの方が高いので結局使わずじまいになる可能性も無きにしも非ずではある。

Forgejo v11のエディタがスマホから扱いづらいのでv15に上げて扱いやすくするのが目的。

この作業で解決する問題

Forgejo v11ではAndroid Edgeでエディタ上をロングタップするとJSでカスタマイズされたメニューが出てしまい、全選択や全選択→切り取りみたいなコンボができない問題があった。

Forgejo v15に上げることで、ブラウザ標準のコンテキストメニューが表示されるようになった。但し全選択→切り取りは上手くいかず、ファイル先頭を選択しそこから末尾までドラッグした上で切り取る必要があった。とはいえ、ほとんど全く操作できなかったところから操作できるようになっただけでも十分だ。

個人的にスマホでコードを触る場合、ほとんどは小規模な編集なので、いったんはこれでも事足りる。

参考までに、この変更はForgejo v14で行われていた。

前提条件

• DBはSQLite
• Forgejo 11.0.15+gitea-1.22.0から15.0.3へのアップグレード

手順

基本的にはアップグレードガイドを読みながらやる。

# v15の取得
wget https://codeberg.org/forgejo/forgejo/releases/download/v15.0.3/forgejo-15.0.3-linux-amd64

# バックアップの作成
sudo -u git /usr/local/bin/forgejo \
 --config /etc/forgejo/app.ini \
 dump --file /home/git/forgejo.zip

# ジョブキューを吐き出す
sudo -u git /usr/local/bin/forgejo \
 --config /etc/forgejo/app.ini \
 manager flush-queues

# サービスを止める
sudo systemctl stop forgejo.service
# バイナリを上書き
sudo cp forgejo-11.0.15-linux-amd64 /usr/local/bin/forgejo
sudo chmod 755 /usr/local/bin/forgejo
# サービスを再開
sudo systemctl start forgejo

あとがき

特に何事もなく移行でき、バックアップファイルも使うことがなかったので良かった。

UI全体としてもブラッシュアップされ、いい感じになっていると思った。

昨日の今日でv11がv15を上げた感じだが、そもそもなんでv11を入れたんだっけ…？と思ったが、多分リリースページの真ん中にv11がいて、v15は画面の上の方にあったので、前回のインストール作業時に見えていなかったのだと思う。

前回の記事でForgejoのIssueを立てるための検証をしたときに最新がv16だったので、やけにバージョンがすっ飛んでるな、WinampやPHP方式か？と思ったら、単に私が見落としていただけだったか…という感じだ。

あと全然関係ないのだが、Forgejoのコントリビューターはオタクっぽい人が多いなと思ったのと、Forgejo同様にFOSSを使っていてCodebergでも採用されているAnubisの開発者もなかなかのオタクに見えるので、この二つのFOSSに何かの縁を感じたりもした。