portal shit!

USB DAC を導入したので 20 年以上前に買った曲を聞いたりしてる。大学近くの新星堂で試聴して買った Brittle Stars というバンドが好きだということは 10 年以上前から何度もブログに書いている。今にして思うと、アメリカのインディーズレーベルのバンドの曲を郊外の住宅街の CD 屋で試聴できてたってのはめっちゃすごいことだった。

最近は天神のタワレコですら棚がスカスカで、いま自分が大学生だったらこういう音楽との出会いはなくて、アルゴリズムにおすすめされるひたすらメジャーな曲を聞くだけの人生になってしまいそう。

めっちゃ久々にタワレコに来たら棚はスカスカであんまりCD売ってなくて、ポスターとかヘッドフォンとかグッズとかが増えてて、CD棚減らした分はイベントスペースになってた。レコード屋はもう知らない音楽と出会う場ではなく、熱心なファンが限定盤を買ったりイベントで訪れる場所になったっぽい。

— morygonzalez (@morygonzalez) May 4, 2022

アルゴリズムが推薦してくるものには偶然の出会いがないと思う。「このアーティストが好きな人はこのアーティストも好きな傾向があります」ということで、必然の出会いしか起こらなくなる。統計学の前提からはみ出るような偶然の引き合わせみたいなのがないと人生つまらなくなるんじゃないだろうか。

ちなみに自分が学生の頃よく行ってた新星堂は 2014 年に閉店していた。

ブログ過去記事の閲覧 UI にはこだわりがある。これまで何度か記事を書いた。

このブログの維持管理で一番時間を割いているのが Archives ページだ。しかしアクセスログを見ると自分以外はほとんど利用していない。完全に自己満なのだが、過去の自分を振り返ることができてとても自分には有意義なページだ。

過去記事を振り返るときには検索をしたくなる。タイトルのみであればページ内検索で探せるが、やっぱり本文込みで検索したい。 Lokka の検索はあるが、検索結果ページは 7 件ずつ（この値はカスタマイズできる）表示で全文表示される。自分は検索キーワードに関する記事が存在するか知りたい訳ではない。著者なのでキーワードに関連する記事があるかないかくらいわかってる。じゃなくて過去の自分がいつ頃どの密度でそのトピックについて書いていたかを知りたいのだ。

タグやカテゴリーで絞り込む手もある。しかしカテゴリーやタグは理想的な分類ではない。二つのカテゴリーを横断するような記事があるし、タグは設定し忘れていることが多い。全文検索が一番頼りになる。

SQL で全文検索的なことをやろうとするとパフォーマンスが良くないだろう。やっぱり全文検索システムが欲しい。

Tantivy と Tantiny

とはいえ、個人のブログで全文検索エンジンを導入するのはしんどい。確かに Apache Solr や Elasticsearch を個人ブログに入れるのはきつい。もっと手軽に使えるものはないか探していて、 Rust 製の全文検索システム Tantivy と、その Ruby クライアントの Tantiny を発見した。

これがめっちゃ簡単で昨日数時間サンデープログラミングをして導入できた。システム環境に適合するビルド済みのバイナリが GitHub にあれば Rust 環境のセットアップすら必要ない。 Gemfile に gem 'tantiny' と書いて bundle install するだけで使えてしまう。

うまくいかなかったもの

最初、同じ Rust 製で Wasm までセットで提供してくれる tinysearch を試した。 JSON 形式で全ファイルを書き出すだけで使えるやつだ。しかし残念なことに日本語では全く使えなかった。自然言語処理をやろうとしていてあるあるのパターンだ。日本語は MeCab などでトークナイズしてやる必要がある。

デフォルトのトークナイザーでもそこそこに優秀な Tantivy

Tantivy にもトークナイザーをカスタマイズできる仕組みはあるが、標準の Simple Tokenizer でもそこそこ精度が高い。固有名詞にちょっと弱いが、辞書ファイルがないので仕方ないだろう。

個人ブログでも全文検索できる時代

このブログは個人ブログだが、画像のリアルタイムリサイズサーバーを動かしている（おかげで S3 の転送量が安くて済んでいる）し、 TF-IDF で関連の高い記事も表示している。それに加えて全文検索まで入れてしまった。こういうのは大手のブログサービスを利用しないと使えない機能だったが、 OSS と新しいプログラミング言語（ Go や Rust ）のおかげで個人でもそこそこのスペックのサーバーでこれらを利用することができるようになってきた。 MovableType でサイトを構築していた時代から何も進歩していないようで実はとても進歩している。こういう文化の灯火が消えないようにしていきたい。

ゴールデンウィークに Instagram 見てたら登山愛好家の皆さんがめっちゃ遠くの山に行っていて正直うらやましかったのでいても立ってもいられなくなり、北アルプス行きの予約をした。

去年、福岡から北アルプスへの行き方に関しては調べてブログに書いていた（福岡から北アルプス（上高地）までの行き方）。 9 月の頭あたりに行こうかと思っていたが、緊急事態宣言が出ていたので諦めてしまった。今年は巷にコロナに打ち克った感あふれてるし行けそうな気がしてる。

松本までは飛行機（ FDA ）で行くことにした。金額が高くなっても結局は飛行機の方が時間と費用を加味した総合的な移動コストが安い。セントレアや名古屋空港を経由しても上高地までの移動にバスを挟んで時間がかかってしまうので時間コストが大きい。マイルが貯まっていてセントレアまでの移動費をゼロにできる場合を除いておとなしく FDA で松本まで行った方がよい。天候的にキャンセルせざるを得なくなったときはキャンセル料を払って諦めることにする。

何時頃上高地に着くかによって山行プランが変わる。自分は奥穂高岳に行こうと思っているが、槍ヶ岳の人も似たようなプランになるだろう。

朝一番の飛行機で松本入りすると上高地着が 14:00 過ぎになる。そこからその日のうちに歩いて行けるのは徳沢か横尾までだ。徳沢も横尾も山小屋があって宿泊できる。初日はここに泊まって、翌日一気に奥穂高岳に登頂するのが良いだろうと考えた。登頂後は穂高岳山荘に泊まり、翌朝奥穂高岳にもう一度行って涸沢岳にも立ち寄ってから一日で下山。 13:30 頃に上高地に着くので松本に移動して後泊する（ FDA の 17:30 の便には間に合わない）。後泊も入れて三泊四日の旅程になる。

一方、登山開始前日の午後に家を出発し、新幹線（か名古屋・セントレア行きの飛行機）と夜行バスを乗り継いで早朝に上高地入りすると、早朝 5 時半頃から歩いて一日目¹に涸沢まで行ける。一日目の夜は涸沢の山小屋に泊まり、二日目に奥穂高岳に登頂できる。ただし山の上でマジックアワーを見たりご来光を見たりはできず、その日のうちに涸沢まで戻って小屋泊することになる。最終日は急いで下山すればその日のうちに帰宅できるが、山では何があるかわからないし予備日は設けておきたいところ。後泊すること前提で予定を組んだほうが良い。ゼロ日目の移動も合わせて四泊五日の旅程になる。

夜行バスで上高地入りする早朝着プランの方が安いような気がしてしまうが、福岡から向かう場合だと結局大阪か名古屋まで新幹線か飛行機を使うので大して金額的なメリットはない。旅程が長くなり、長時間の移動・夜行バスで疲れ、日の出どきやマジックアワーを山頂付近で過ごせない。東名阪に住んでいる人であれば夜行バスの早朝着プランは安く行けてメリットありなのだが、それ以外の地域から行く人にとっては午後着プランの方が無難だろう。

あとは天候が良くなることを祈るばかりだ。

このサイトは Amazon の Product Advertising API を利用して小銭を稼がせてもらっている（毎月 300 円くらいインターネットの恩沢がある）。去年も 5 月頃に記事を書いているのだが、 30 日間で一個もこのブログ経由で商品が売れなかったので Product Advertising API の利用が制限されてしまった。

Product Advertising API は 2020 年の春に Version 5 への移行が義務づけられ、 30 日間で一回も商品を売れなかったサイトは API の利用ができなくなってしまうのだった。

春は入学や就職、引越の準備で忙しくて誰もこのような泡沫ブログを読んだりしないのだろうか。春は買い物する機会自体は多いと思うので、買い物していないわけではなく、趣味性の高い商品のアフィリエイトが踏まれにくくなるのかもしれない。

一昔前までインターネットは常に見えるものだった。 Web 1.0 の個人テキストサイトや Web 2.0 のユーザー参加型ウェブサービスでも、ベーシック認証がかけてあったり非公開コンテンツというものもあったがこれらは例外的な存在で、インターネットでは目立つこと、オープンであること、また他者の注目を引くことが善だったしメインストリームの価値観だった（少なくとも自分はそう認識していた）。しかしその構図が崩れようとしている。インターネットがみんなのものになったからだ。

多くの人はインターネットで自分の情報をさらけ出したいなんて思っていない。これまでブログが下火になってきた理由を考察することが何度かあった。手軽に個人が情報発信できる Twitter や Instagram のような SNS が登場してきたからだと思っていた。かつてブログを書いていた人が書かなくなってきた理由としてはその通りだと思う。しかしスマートフォン時代になってからインターネット活動を始めたような人達（イノベーター理論のグラフで言うと Late Majority 以降の人達）はそもそもブログを書くということは選択肢に入らなかったはずで、こういう人達が増えてきたことで相対的にブログ執筆人口が減ってしまったと考えられる。

インターネットでは誰もが情報発信できると言われた。しかしできることと実際にやることの間には大きな壁がある。仕事で関わっているサービスでは、ユーザーが作成したコンテンツを公開するかどうかはユーザー自身が選べる仕様となっている。コンテンツを公開するユーザーが増えるほどネットワーク効果が働くし、 Google の評価が高くなり SEO 上のメリットもあるのでコンテンツ公開率を上げようと努めてきた。しかし頑張ってもコンテンツ公開率はある程度のところで頭打ちとなってしまった。この結果から二つの仮説が考えられる。公開を促す努力が足りないか、そもそも誰もコンテンツを公開しようとは思っていないか、ということだ。実は最近まで後者の観点が抜けていた。というのはインターネットでは誰しもコンテンツを公開すべきだ、という先入観があったからだ。

ここ数年での成長が著しい Netflix や Spotify でユーザーはコンテンツの公開を求められることはほとんどない。 Twitter や Facebook 、 Instagram などの CGM では基本的にはコンテンツを公開することが求められたのとは対照的だ。 Netflix や Spotify でユーザーはコンテンツを消費するだけでよいのだ。消費の仕方を Netflix や Spotify は観察し、この傾向のユーザーにはこういうコンテンツがおすすめだというアルゴリズムを洗練させていく。ハチャメチャに優れた推薦アルゴリズムにより、ユーザーは自分にマッチした未知のコンテンツに出会うことができ、益々サービスの利用を深めていく。ひたすら受動的にコンテンツを受容し続ければよいだけだ。

コンテンツの投稿・公開を求められる Twitter や Instagram でも、実は見る専（ ROM ）の割合が高まってきているのではないかと推測する。 以下の記事によると、 Twitter の投稿の 97% が 25% のユーザーによって行われたものだったそうだ。

さらに驚くことに、 Reply や Retweet を差し引くと投稿されるコンテンツの 18% のみがオリジナルの投稿ということらしい。やはりコンテンツを作る人の割合というのは非常に小さく、ほとんどの人はインターネット上のコンテンツを消費しているだけなのだ。

インターネットの初期時代からインターネットにどっぷり浸かってきたインターネット老人の我々のような世代がウェブサービスを設計すると、ついつい人々はインターネットで自己表現をしたいのだという前提で考えがちだ。しかしあとの方になってからインターネットを使い始めた人々にとっては、インターネットとは自分から情報を差し出す場ではなく、情報を摂取する場なのだ。買い物をしたり、動画を見たり、音楽を聞いたりしているだけだ。自分でウェブサイトを持ってブログを作ったりしている我々は、今日のインターネットにおいて決してマジョリティではない。

受動的にインターネットを使うだけの人に、 1990 年代の終わりに我々インターネット老人が感じたのと同じような興奮や感動を与えられるのだろうか。多分、発想を転換しないと難しいだろう。我々が面白がったインターネットと彼らが欲しているインターネットは別のものなのだ。ただ受動的に使っているだけでより便利になり、快適になっていくインターネットをどうやって作っていくかが見えないインターネットの時代のテーマになると思う。

OS の設定に応じて自動的にダークモードとライトモードを切り替える（メディアクエリで prefers-color-scheme: light とかやる）ようにしていたが、自分でブログを見ていてダークモード状態で閲覧する時間が短いことに気がついた。考えれば当たり前で夜は寝てるのでダークモードで閲覧する時間が短くなるのは当然だ。個人的には自分のブログはダークモードのときのデザインが気に入っている（ 10 年くらい変えてない）ので、 OS のテーマ設定に加えて閲覧者が自分でダークモードかライトモードかを選べるようにした。設定値は Cookie に保持するようにしてる。個人的に便利になった。切り替えは About ページ内か以下の テーマ変更 ボタンでできるようになっている。

テーマ変更

Lokka の検索はキーワード一つにしか対応していなかった。例えば うどん ラーメン と入力すると、確実に うどん ラーメン という語順で検索が行われる仕様になっている。これはちょっと不便だと思ったので半角スペースでキーワードを分割して AND 検索するようにした。つまり確かに うどん ラーメン という語順で文章が書かれていなくても、 ラーメン うどん という語順だったり、そもそも うどん と ラーメン が離れたところに書いてあるような文章でもオッケーな仕様にした。 diff はこんな感じ。

一般的な検索システムだと入力された検索キーワードを品詞分解したりして半角スペース入れたりせずともいい感じに検索できるのだろうが、データベースから直接検索するシステムではこれくらいできれば十分かなと思ってる。どうせこのブログで検索してるの自分一人くらいだし。