昨年末に mixi2 出てちょっと話題になった。自分もアカウント作って使ってみた。最初はよく考えられてるなぁと感心したけど、なんか使いづらい。
自分として最も使いづらいと感じるのは絵文字の種類の少なさで、数が少なくて気持ちを表現しづらいと思っている。あらためて見てみると mixi2 の絵文字はのほほん系の絵文字しかなく、喜怒哀楽を表現しきれない。 🤔 のような、わずかでもネガティブなニュアンスのある絵文字は使えなくなっている。
リプライ欄のプレースホルダーも「やさしいことばで返信しよう」となっていて、返信内容を穏やかな方向に限定しようという意図が読み取れる。
mixi2 のメッセージとして、のほほんとしたコミュニケーションだけやって欲しいということなのだろう。
Threads が出たときに記事を書こうとしていろいろ調べていたが、改めて引っ張り出してきて見てみると、 Threads / Instagram 勢もこういうコミュニケーションをして欲しいという意図を持っている。 Threads がリリースされたばかりの頃、 Instagram の責任者の Adam Mosseri は Instagram や Threads は政治や重苦しいニュースではなく、頭を空っぽにして楽しめるお気楽コンテンツだけ見られるお花畑のような場所にしたいと言っていた。
Post by @mosseriView on Threads
Twitter が居心地がよかったのは人が多かった（自分が情報を知りたいと思う相手が多く Twitter を使っていた）というネットワーク効果的な側面もあるが、「こういうコミュニケーションをしろ」という制約が弱かったからだと思う。 Twitter がコミュニケーションの方向性を指示しようという試みは、せいぜい入力欄のプレースホルダーを "What are you doing?" から "What's happening?" に変えたこと（「あなたはいま何してる？」から「あなたのまわりで何が起こってる？」に変更）くらいだ。
ハイパー起業ラジオに MIXI の元社長の朝倉祐介さんが出ていて、いかに SNS として発展させるかばかりを考えていた当時のミクシィを多角化して立て直したかを話していた。
mixi2 の動きは朝倉さんがやったことへの反動のようにも思える。めっちゃ細かいところまでこだわった俺たちが考える最強の SNS を作ろうとしているのだろう。
果たしてコミュニケーションの方向性を限定するやり方はうまくいくのだろうか。
匿名掲示板のような無法地帯がよいとは思わないが、自分は自由にコミュニケーションできる場所の方が好きだ。
2024 年シーズンのマラソンの振り返り。 2024 シーズンは以下のレースに出た。
福岡マラソンに関しては個別に記事を書いた。ギリギリだがネットタイムでサブフォーできた。
福岡マラソンはなかなか良かったのだが、その後がダメダメだった。
シーズン二本目は青島太平洋マラソン。フラットなコースで記録を出しやすいと聞いていたのでエントリーしていた。福岡マラソンでサブフォーできなかったときにサブフォーを狙うための本命レースだと捉えていた。しかし想定外にもシーズン一発目の福岡マラソンでサブフォーできてしまったので練習に身が入らず、 30km 走もやらないままに本番を迎えてしまった。
前日入りした宮崎ではサウナに入ってチキン南蛮の名店おぐらに行って大盛りご飯を食べて食べ過ぎ状態となり、スタート直後からずっとお腹が重く、なんとレース中に初めて💩をしてしまった。ドン引き。
アオタイは 2023 年は暖かかったと聞いていたので Teton Bros. の Elv 1000 Sleeveless で走ったら、この年は寒く、特に高架の道路を走る区間で海風にさらされて体が冷えた。寒い時期のマラソンは汗抜けの良さよりも体幹部の温度を過剰に失わない工夫の方が大事だと思い知らされた。
32km 地点くらいで💩を出してからはペースを落として最後はファンランのようなペースでゴール。マラソン初挑戦したときの福岡マラソンよりも遅いタイムだった。
アオタイは高架道路を緩やかに登るのを繰り返すし、カーブ部分では路面が傾斜しているので足首に負担が来る。遮るものがないので海風をもろに受ける。各所でスライドが多く、歩行者の横断のためにコースが所々狭まったりするので結構走りづらいと感じた。福岡から宮崎はだいぶ遠いので、一回出たらもういいかなというのが正直なところ。観光しに来て朝こどもの国のあたりを緩くジョグするのは楽しそう。
こちらも二年連続出走できた。去年悔しい思いをしたのでリベンジを果たしたかったのだが、マラソンワースト記録を樹立するという屈辱的な結果となってしまった。
敗因は色々ある。まずは練習量の圧倒的な不足。仕事が忙しく、なかなかランニングのリズムを生活のなかに作れなかった。年末に風邪を引いたことも良くなかった。これで完全にランニング習慣が途絶えてしまった。加えて本番一週間前の牡蠣の食あたり（ノロウイルス）。一月から二月にかけては一週間の練習回数が一回、週間走行距離は10kmのようなていたらくだった。
次にシューズのミス。なんとマラソン用のシューズ（ ASICS MAGIC SPEED 2 ）と間違えてトレランシューズ（ ALTRA OLYMPUS 4 ）を持ってきてしまっていた。詳しくは個別に記事を書いた。
シューズがベアフットシューズだったこともあり、 20km 手前で力尽きてペースを落とした矢先に計測マットに足を引っかけて激しく転倒してしまった。右肩と肘のあたりを強打して結構血が出ていたし、靴も転倒で破けてしまったのでここでやめようかなとも思ったけど、とりあえず救護所まで行こうと走っているとなんとか走れた。ハーフ地点の救護所に寄って傷の応急処置をしてもらい、その後ゴールまでゆっくりジョギングすることにした。転倒時につった両足ふくらはぎが痛み、歩いたり走ったりを繰り返した。
転倒したせいで開き直って、記録を狙うマラソンでは食べない給食を積極的に食べた。熊本城マラソンはランチパックとか菓子パンとか一杯あった。いちごもいっぱいあったのでたくさん食べた。
去年走ったとき異常につらかった熊本港方面への直線は去年ほどつらくは感じなかった。去年は誰も知ってる人がいないためとても孤独に感じたが、足がハチャメチャにつっていたので沿道で冷却スプレーを持って応援してる人のところに駆け寄ってスプレーをしてもらうのを何度もやって、親戚のおばちゃんに励まされながら走ってるような気持ちになった。熊本を離れてもう 15 年も経つが、故地のような感覚はずっと持っている。もし熊本で就職していたらどんな人生を送っていたんだろうと想像しながら熊本城への道を走った。
最後、第一高校の裏手から熊本城への登りはきつかった。今年はかなり歩いたが、最後の最後の二の丸広場へ駆け込む登りはつって言うことを聞かなくなってるふくらはぎにむちを打って無理矢理走った。
練習不足、意図せずベアフットシューズで走ることになったこと、 20km 地点での転倒などトラブルだらけのマラソンだったが、リタイヤせず最後まで走れたことは福岡マラソンでのサブフォーよりも達成感があった。
熊本城マラソンに関してはめっちゃ悔しいので来年もう一回チャレンジしてみたい。熊本でサブフォー達成して故郷に錦を飾りたい。
福岡マラソンでギリギリサブフォーできたのはよかったが、課題の残るマラソンシーズンだった。月間 200km 走れていないのはまずい。週末のロング走が足りてない。 COROS アプリによると、ランニングレベル分析のうち、乳酸閾値レベル、スピード持久力、スプリントは 77 以上あるのに、有酸素レベルが 74 しかない。閾値走やインターバル走よりも、有酸素持久力ゾーン（ 5'46" ~ 6'51" ）でのジョグをみっちりやるべきなのだと思う。 10km くらいではなく 20km くらい。
とりあえずマラソンシーズンは終わったのでトレランしたり登山したりしていこうと思うけど、来年悔しい思いをしないよう、週末のロング走を今年はちゃんと頑張りたい。
バッチ処理を動かしている Docker コンテナ含めてすべての環境を Ruby 3 で動かせるようになった。以下の点に難儀した。
![[番外編 #12] mixiのV字回復はここから！朝倉祐介に訊く逆転のヒント - ハイパー起業ラジオ](https://portalshit.net/imageproxy/200/https://image.listen.style/img/zgHpjWKb1OuJ4iGrrupeHWLNZRTxzIQz3IPGfJvFkVo/resize:fill:1200:1200/aHR0cHM6Ly9kM3Qzb3pmdG1kbWgzaS5jbG91ZGZyb250Lm5ldC9zdGFnaW5nL3BvZGNhc3RfdXBsb2FkZWRfbm9sb2dvLzM5Njk0OTgzLzM5Njk0OTgzLTE3MDAwNjM5ODI3MDYtZTBkY2RkZTIxNGMwNS5qcGc.jpg)
DATABASE_URL を環境変数で渡すことで DB 接続設定を上書きできなくなってしまった
ついでにキャッシュも効くように修正した。 sinatra-cache がおかしかったのは Haml の挙動が変わって - form_tag としていたところを = form_tag とする必要があるのと同様に、 - cache_fragment を = cache_fragment にする必要があった。再びキャッシュが効くようになって高速になったが、一部 HTML タグが混ざって表示されることがある。 sinatra-cache.gem が依存する sinatra-outputbuffe.gem の方に問題がありそう。この gem は 16 年以上更新されていない。どこかでキャッシュ依存はやめないといけないかもしれない。
先週末と今日ガチャガチャやって、ようやく Ruby 3 にアップグレードすることができた。 Ruby 2.7.3 → Ruby 3.1.6 。ただ Ruby 3.1 は今年の 5 月に EOL を迎えるみたいなのでこちらもさっさと新しいバージョンの Ruby に上げないといけない。
やったことは一つ前の記事に加えて以下。
kaminari-sinatra の SinatraHelpers が Ruby 3 ＆ ActionView v6 対応していなかったのでちょこちょこと修正した。
次に padrino-helpers が Ruby 3 と Haml v6 に対応していないのを対応させた。具体的には form_tag の中身のタグが過剰に escape されてしまうので、あんまり良くないかもだが capture_html したやつを html_safe した。 form_tag の内側に来るものはユーザー投稿コンテンツではないはずなのでエスケープはサイト管理者側でできるはず。
ドキュメントでは
= form_tagを
!= form_tagにしろとは言われているが、 form_tag の中身で concat_contet してる片方（ capture_html(&block) の結果）が html_safe? => false になるので、 View テンプレート側で何かやっても意味がない（ Buffer が汚染されると View で html_safe しても汚染された部分の文字列はエスケープ済みになっている）。
kaminari-sinatra も padrino-helpers も本家にパッチを送ると良いのだろうが、職業プログラマーではなくなったのでなかなか腰が重い。 kaminari-sinatra はテストが通らないし、 padrino-helpers は git clone で submodule の clone に失敗するのでテストが実行すらできないかもしれない。
心の余裕ができたらやってみる。
ちなみに Ruby 3 化するにあたり sinatra-cache を完全に捨てたので負荷が上がるかも。オリジナルの gem は 15 年くらいコミットされてなくて fork して使い続けてきたけど Sinatra や Haml の変更に追従できる気がしないのでいったん捨ててみる。
人気記事を確認できるようにしたという記事を以前書いている。もう 7 年も前のことのようだ。
調べればこういうログ集約・集計系のサービスはあるようだったが、個人ブログなのでなるべくお金はかけたくない。
しばらくの間は集計後のログを捨てていたが、 2 年半前からログローテートするタイミングで日付ごとのファイルを書き出し保存するようにしていた。日付ごとのログファイルは Amazon の S3 にアップロードしてさくらの VPS サーバーからは待避させている。現状、 2022 年の 6 月 13 日のログから S3 上にデータが残っているので、その日以後の日ごとの人気記事を確認できるようにした。こんな感じ。
日付の選択は最初 React のライブラリを使って作ろうかと思ったが、そういや最近のブラウザーは <input type="date" /> とすると結構ちゃんとしたカレンダー UI と日付選択の機能を提供してくれるので楽をすることにした。
max と min を指定すると選べない日付は非活性にされるし、無理に選択すると form を submit したときにバリデーションしてくれる。
ブログの閲覧者からしたらいつどの記事が読まれていたかなんて興味ないだろうけど、著者である自分には興味深い情報になる。セルフホストのブログだからできる機能だ。
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 でも同じような結果だった。相変わらずインターネットは不便になってきている。