人気記事集約用のシェルスクリプトは自己流で書いてたのであまり自信がなかったので、ものは試しにと ChatGPT にリファクタリングしてもらった。今日の集計と昨日の集計と全期間の集計で似たようなコードがあるのにコードを共通化できていなかったので共通化を提案されたが、そのまま適用するとちゃんと動かない。重要な細かい仕様をなかったことにしたりもする。 Copilot も試してみたが似たような感じだった。生成 AI はチャットでベストプラクティスを聞いたり、細かい作法を尋ねたりするのには向いているかもだが、ソフトウェア開発者を丸々置き換えることはできないと思う。少なくとも現状は。実際に動かしてみて期待通りに動くかのチェックは絶対に必要だし、人間が細かいところで楽をすることはできるけど、完全に ChatGPT とか Copilot だけでシステムを構築するのは難しいだろう。 AI は人間が知ってることしかできない。人間が知らないことは人間にしかできない。
YouTube の OGP 読み込み
YouTube の OGP が読み込めない問題があって、回避策をいろいろ考えていた。
YouTube は未ログインで bot っぽい User Agent でアクセスすると OGP のタグが入ってないページを返すようだった。
検索すると facebookexternalhit/1.1 (+http://www.facebook.com/externalhit_uatext.php) という UA でリクエストすれば OGP タグ入りのページを返してくるようだった。
このやり方を試してみようとしたが、使っている gem が UA の上書きに対応していないので面倒くさそうだった。
追加でいろいろ調べてみると、そもそも YouTube は埋め込み用の HTML 片を返す API を用意しているようだった。
動画の ID がわかっているなら https://www.youtube.com/oembed?url=動画のURL という風に GET リクエストを投げると、動画のメタ情報に加えて埋め込み用の iframe スニペットを返してくれる。こんな感じ。
{
"title": "Ride - Vapour Trail (Live on KEXP)",
"author_name": "KEXP",
"author_url": "https://www.youtube.com/@kexp",
"type": "video",
"height": 113,
"width": 200,
"version": "1.0",
"provider_name": "YouTube",
"provider_url": "https://www.youtube.com/",
"thumbnail_height": 360,
"thumbnail_width": 480,
"thumbnail_url": "https://i.ytimg.com/vi/9bVS9j8NoZ0/hqdefault.jpg",
"html": "<iframe width=\"200\" height=\"113\" src=\"https://www.youtube.com/embed/9bVS9j8NoZ0?feature=oembed\" frameborder=\"0\" allow=\"accelerometer; autoplay; clipboard-write; encrypted-media; gyroscope; picture-in-picture; web-share\" referrerpolicy=\"strict-origin-when-cross-origin\" allowfullscreen title=\"Ride - Vapour Trail (Live on KEXP)\"></iframe>"
}結果はこんな感じ。
こういう仕組みは標準化されていて oEmbed というっぽい。そういえば一昔前に聞いたことがあるような気がする。
OGP カードのようにしようかなと思ったけど、 YouTube 動画ならその場で再生できた方が便利かなと思ったので、 YouTube 動画の URL はすべて埋め込みとして表示することにした。
ちなみに YouTube にまつわる何かを検索しようとするとなかなか知りたい情報にたどり着けなくて困った。 YouTube OGP みたいなキーワードで検索すると、大量に OGP について解説している YouTube 動画がヒットする。技術寄りの内容というよりマーケターっぽい人向けの情報。これは地獄みがある。 Google だけでなく DuckDuck Go でも同じような結果だった。相変わらずインターネットは不便になってきている。
OGP 読み込み君をインラインバージョンにした
OGP 読み込み君が悪用されていて困ったという記事を書いた。
OGP 読み込み君が踏み台にされてた
OGP 読み込み君を作ってよそのサイト（自分のブログの過去記事含む）の OGP をいい感じに iframe で表示していた。 ...
portalshit.net
Referer でブロックされるようなサイトからリンクするときに OGP 読み込み君をかませて掲示板やブログのコメント欄に URL を投稿しまくっていたのだと思う。調べたら 73 万件以上のリンクが OGP 読み込み君によって生成され、リンク先の OGP カードがキャッシュされていて、ディスク容量を 2.8GB も消費していた。許せん。
認証なしで使える OGP 生成カードのようなエンドポイントを露出していたのがそもそもの間違いだった。スパマーのはびこる今日のインターネットではこういう無防備なことをはするべきではなかった。
ということで iframe で OGP を展開する方式をやめて、インライン表示するようにした。普通に OGP 表示用の HTML を生成してキャッシュしている。なので初回に OGP を読み込むときにめっちゃサイトのレスポンスが遅くなった（ iframe であれば非同期読み込みできてメインの HTML の描画は高速だった）。
良くも悪くも、インターネットは巨大になってきていて、ちょっと穴のあるシステムをインターネットに公開してしまうと悪意をもった人に悪用されて膨大なダメージを負ってしまう可能性がある。難しい世の中になってきている。
OGP 読み込み君が踏み台にされてた
OGP 読み込み君を作ってよそのサイト（自分のブログの過去記事含む）の OGP をいい感じに iframe で表示していた。
しかし最近この機能がスパマーに悪用されているようだ。自分がこのブログ内で言及した覚えのない URL へのアクセスが一杯あり、そのせいでめちゃくちゃにサイトの負荷が高くなっているようだった。 OGP 読み込み君はキャッシュする機能はあるが、基本的に Ruby でよそのサイトに HTTP リクエストを投げるので悪用されると負荷が高くなってしまう。
Nginx で悪用されたくないパスへのリクエストには Referer 制限をするようにしたのでこれで負荷が下がってほしい。
追記
ロードアベレージが平均 3 、高いときは 20 くらいになってたのが 0.1 くらいに戻った。
海外のスパマー、本当に色々酷いことやる。日本語読めないのに OGP 読み込み君の仕様を突き止めて悪用してる。多分、こんなことしても利益は 1 円もないのに何がしたいんだろう。他人にダメージを与えられればそれでいいんだろうか？
puma のバージョンを上げたら Encoding::CompatibilityError が多発
偶発的に puma のバージョンを上げたところ Encoding::CompatibilityError: incompatible character encodings: UTF-8 and ISO-8859-1 が多発して厳しい感じになった。
このブログでは puma は v4 系を使っていたが、調べると最近 v6 もリリースされたようで v5 系に上げてみることにした。すると忘れていたのだが puma は v5 系から daemonize する機能が削除され、デーモン化は systemd を使うべしということになっていた。プロセスのデーモン化は puma にやってもらわないと capistrano で deploy するときに面倒なので以前は v5 に上げるのを諦めて v4 を維持していたのだった。
capistrano3-puma が systemd に対応していたのでえいやっと puma を v5 に上げて deploy してみたところ、冒頭の Encoding::CompatibilityError: incompatible character encodings: UTF-8 and ISO-8859-1 が多発してページが全く表示されなくなってしまった。
一方で管理画面やアーカイブページは表示に問題がなかった。どうもファイルの読み込みが発生するページ（このブログではキャッシュを多用していて、ファイルに書き出したキャッシュを読み込んでいる）でエラーが発生しているようだった。
自分で fork した sinatra-cache.gem でファイル読み込みする部分で encoding オプションを指定してみたりしたが問題が直らない。 Haml や Sinatra のバージョンも古いのでこれらも上げてみようかと試みたが、そうするとより盛大にエラーが出てしまう（ Haml を v6 にすると html_safe している出力もさらにエスケープされて HTML がぶっ壊れる）。
気になるのはローカル環境（ Mac ）ではこのエラーが発生しないこと。「これは環境起因では？」と思い至ってガチャガチャやってみたところ修正することができた。
Lokka では Encoding.default_external を参照しつつ String#force_encoding しているところがある。「ひょっとして Encoding.default_external の値がローカルとサーバーで異なるのでは？」試してみたところ、ローカルでは #<Encoding:UTF-8> となる Encoding.default_external の結果が、サーバーでは #<Encoding:ISO-8859-1> となっていた。
以下のブログを参考に、環境変数 RUBYOPT でエンコーディングを指定して puma を動かすことでエラーを回避できた。
systemd 経由で puma を動かすときに環境変数を設定するのは結構難しい。最初は puma が RACK_ENV=production で動かず困ったが、 systemd 用の設定ファイルで EnvironmentFile のパスを指定し、環境変数用のファイルの中で各種環境変数を定義してやる必要があった。こんな感じ。
systemd の設定ファイル
[Unit]
Description=Puma HTTP Server for portalshit (production)
After=network.target
[Service]
Type=simple
WorkingDirectory=/var/www/deploys/portalshit/current
# Support older bundler versions where file descriptors weren't kept
# See https://github.com/rubygems/rubygems/issues/3254
EnvironmentFile=/var/www/app/.config/systemd/user/portalshit_env
ExecStart=/var/www/app/.rbenv/bin/rbenv exec bundle exec --keep-file-descriptors puma -C /var/www/app/portalshit/config/puma.rb
ExecReload=/bin/kill -USR1 $MAINPID
StandardOutput=append:/var/www/deploys/portalshit/shared/log/puma_access.log
StandardError=append:/var/www/deploys/portalshit/shared/log/puma_error.log
Restart=always
RestartSec=1
SyslogIdentifier=puma
[Install]
WantedBy=default.target環境変数の定義ファイル
RACK_ENV=production
RUBYOPT=-EUTF-8
puma v5 に移行しようとしている方の参考になれば幸いです。
MySQL の FULLTEXT インデックスによる全文検索
MySQL だけでお手軽に全文検索ができるということを知らなかった。 MySQL 5.6 から入っていたようだった。 Tantivy および Tantiny を使ったやり方を以前記事に書いてサイトで実装しているが、 MeCab によるトークナイズでは二文字の熟語がセットになって四文字になっているようなパターンを取り逃すことがあった（「関連記事」は「関連」と「記事」に分割され、「関連」や「記事」というキーワードで検索したときにはヒットするが「関連記事」で検索するとヒットしない）し、記事追加時の検索インデックス更新処理が不要（ MySQL にレコードが追加されたときに勝手に更新される）なので試してみることにした。
やり方は以下の記事を参考にした。
最初にデータベースに全文検索用のインデックスを作成した。
ALTER TABLE `entries` ADD FULLTEXT INDEX index_entry_fulltext(title, body) WITH PARSER ngram;その後、検索部分のコードを書き換えて以下のようにした。
class Entry < ActiveRecord::Base
scope :search,
->(words) {
return all if words.blank?
where('MATCH (entries.title, entries.body) AGAINST (? in BOOLEAN MODE)', words)
}
endめっちゃ簡単。
このブログは記事数が 1500 記事くらいなのでぶっちゃけ LIKE 検索でも実用的な速度（ 100msec 以内）で結果を取得できるが、 FULLTEXT インデックスを使うと 10msec 程度で結果を取得できる。
ただし Tantivy と比べて劣る点もあって以下は注意が必要。
- なぜかわからないが
Vimで検索すると何もヒットしない。またRailsで検索すると Rails について触れていない記事もヒットする。 ngram によるインデックスというのはこんなものなのかもしれない。検索ワードが日本語のときはいい感じに結果が表示される。 - 複数のテーブルにまたがるデータを一個の検索インデックスにまとめることができない。例えば Tantivy のインデックスは記事のタイトル、本文、カテゴリー、タグをインデックス対象としているが、 MySQL の FULLTEXT インデックスだとテーブルごとにしかインデックスを作れないので（当たり前）、複数のテーブルにまたがる検索をするときにはテーブルを JOIN するしかない。 OR マッパーを使っている場合には利用しづらい。
1 の問題に関しては、 MySQL 5.7 からインデックス生成時の PARSER に MeCab などを指定できるようになったのでそうすると回避できるかもしれない。ただし MeCab のインストールや設定を行う必要があるので要注意。
2 の問題に関しては全文検索システムを入れた方が良さげ。 Tantivy であれば非常に簡単に導入できる。
現状、このサイトでは右上の検索窓から検索したときのインクリメンタルサーチとアーカイブページでの絞り込みは Tantivy を、インクリメンタルサーチの結果で必要な情報が得られなかったときの「全文検索する」と 404 Not Found ページの検索は MySQL の全文検索を使うようにしている。
Homebrew でオプション指定してインストールできなくなっていた
Homebrew で入れた SQLite で load_extension() が動かなくなっていた。
どうも以前は --enable-loadable-extensions でビルドできていたらしいが、 Homebrew 全体でオプション指定をできなくする変更が 4 年前にあったみたいだ。
オプション指定できるのは UX として良くない（ビルド済みのバイナリをダウンロードできない）し、オプション指定を Homebrew のチームでテストしていないからだそう。
TF-IDF で関連記事を表示する機能は SQLite の拡張に依存していたので、最近 Homebrew で入れた SQLite だと機能が動かなくなってしまった（エラーが発生する）。
対策としては自分で SQLite をビルドするしかない。 Mac でそれやるのは面倒なのでこういうのは全部 Docker でやることにした。
Homebrew のウリはビルド済みのバイナリをサクッとダウンロードできてローカルでビルド不要なところではあると思うが、ちょっと凝ったことをしようとするとソースコードをダウンロードしてきて手元でビルドしないといけなくなってしまった。依存パッケージをまとめてインストールできてたことも便利だったんだけど、カスタムインストールをしたいときは昔みたいに依存関係を自分で調べて都度都度インストールしていかないといけなくなった。開発チームの考えもわからなくはないがちょっと残念だ。
ちなみに Homebrew のリポジトリ（ homebrew-core ）の過去のコミットログを調べるのがめっちゃ大変だった。 tig Formula/sqlite.rb しても 3 分くらい反応がなかった。 git log -Sextension Formula/sqlite.rb してそれっぽいコミットのハッシュ値を見つけて GitHub で検索して何とか上記の Pull Request と Issue に辿り着いた。超巨大なプロジェクトのソースコード管理は Git でやると大変そうだ。