portal shit!

インデックスページにカテゴリーへの導線を作るべきということを書いたがさすがにラディカル過ぎた。

インデックスページの刷新

インデックスページをいじって各カテゴリーの最新記事 4 件を配置するようにしてみた。最近の個人サイト復興ブームでみなさんインデックスページを工夫されているのを見ていて真似したくなってやった。 ...

portalshit.net

インデックスページのコンテンツ数が増え、ページの応答速度が 800ms ほどになっていた。 DOM サイズも大きくなり、転送量が増えてユーザーフレンドリーではないなと思った。確かにユーザーの回遊性は高まるかもしれないが、ページがごちゃごちゃしていて快適ではない。これではブログサービスでブログをやっているのと大差ないと思い直し、インデックスページの記事数を最小限に絞った。

全カテゴリーの最新記事の表示はやめ、最新の 7 記事だけ表示するようにした（最新の記事だけ大きく表示するというスタイルは残している）。カテゴリー一覧ごとの最新記事は別途 カテゴリー一覧ページ を用意してそちらに移した。

またページ下部に最近閲覧数が多い記事とはてブでホッテントリ入りした記事へのリンク¹を付けた。これまではフッターに表示していたが、フッターのリンクはあまりクリックされていない疑惑があるし、結構面白コンテンツだと思うのでインデックスページのメインコンテンツとしてしつらえることにした。そもそも 21 世紀のブログでフッターなんてものはいらないのかもしれない。

シンプルにしたインデックスページは応答速度が 200ms を切っていてまぁまぁ高速で Google PageSpeed Insights でも 90 点くらいを取れる。個人ブログなのでシンプリシティは大切にしたい。

音楽のサブスクリプションは 2018 年の春頃から Apple Music を使っている。ただ最近、 Spotify のレコメンデーションが良いという話を複数の友だちや Podcast 、仕事先で立て続けに耳にしたので久々に使ってみたら、確かに Daily Mix というやつが聞いたことないけど絶対に好きな感じの曲で埋め尽くされていてビックリした。 Spotify は 4 年くらい前にお試しで 2 ヶ月使っただけで、それ以後は使っていない。そのときに自分の iTunes ライブラリや聞く音楽の傾向を解析してレコメンデーションの土台としていたのだろう。すごい。

Apple Music にも For You というやつがあって「金曜日のプレイリスト」的なやつが表示されるが、半分くらいがライブラリにある曲、半分くらいが知らないけど全然好きじゃない曲が混じってたりする。 Apple Music のレコメンデーションでは まだ知らない新しい音楽（だけど好き） との出会いがない。どっちかというと Apple Music は個人に最適化されたプレイリストよりも「2010年代 ヒップホップ ベスト」みたいなプレイリストのようなキュレーションされたものの方がまともな感じがする。パーソナライズされたレコメンデーションはダメダメだ。

また、 Spotify にはあるけど Apple Music にない曲というのが結構多い。 Spotify のプレイリストで良かった曲を Apple Music で DL しようとすると曲がなかったりする。以前、ストリーミングサービスの一ストリーミング再生ごとのアーティストへの支払額みたいなやつの比較を見てて、確か Apple Music が一番高かった。どうせ聞くならアーティストに手厚くお金を払っているサービスを使いたいと思って Apple Music を選んだのだが、意外とインディー系のアーティストは Apple Music には楽曲提供しておらず、 Spotify の方に出しているようだった。

こうなってくると Spotify に乗り換えたいなと思うのだけど、 Apple Music はファミリープランに入っているので自分の一存で Spotify に移行することができない。ファミリープランは個人用プランからすると著しく安い価格設定になっているが、その理由はチャーンの抑制にあると思う。意思決定者を複数人にすることで他サービスへの乗り換えが困難となる。よく考えられた価格設定だ。

結果としていまは広告に耐えながら Mac の Spotify で好みの曲を探し、ちまちま Apple Music でライブラリに追加して iPhone で聞くという生活をしている。スマートフォン版の Spotify は無料状態だと完全シャッフルになるしめっちゃ広告入るので厳しい。 Apple Music と Spotify に二重支払いできるくらいの金持ち¹になりたい。

2 年半くらい前に嫁さんに買ってもらった BOSE の QC 35 のイヤーパッドがボロボロになってきたので交換した。

🎧 BOSE QuietComfort 35 をもらった

Google アシスタントに対応した後継機種（ QC 35 II ）が出たことで BOSE の QC 35 旧型が 1 万円近く安くなっていたのでクリスマス、誕生日、バレンタインデーの合算プレゼ...

portalshit.net

純正品ではなく Amazon で 1500 円で売られていたイヤーパッドを使った。純正品は 4000 円もしてなかなか高いが、模造品で全く問題なかった。

以前使っていた SONY の MDR-1RBT のときは 4 年くらいもったようなので、 QC 35 のイヤーパッドはダメになるまでが早かった。

ヘッドフォンのイヤーパッド交換

SONY の MDR-1RBT を使っているけど、最近イヤーパッドが破れてきて黒い破片が耳の周りにまとわりつくようになっていた。 SONY の純正品は片方 2000 円で、両方交換すると 400...

portalshit.net

使用後に耳の周りの皮脂がイヤーパッドに残ることで劣化するらしいことを MDR-1RBT のイヤーパッドを交換したときに学んだので、気にして使用後はウェットティッシュなどで拭いていたのだけど延命効果はなかったようだ。

ヘッドフォン本体の調子は問題ないのでまだまだ 2 年くらいは使いたい。

インデックスページをいじって各カテゴリーの最新記事 4 件を配置するようにしてみた。最近の個人サイト復興ブームでみなさんインデックスページを工夫されているのを見ていて真似したくなってやった。

昔ながらのブログだとインデックスページというのは最新の記事 10 件くらいが表示されていて、「次へ」を押すと古い記事が出てくるという構成になっている。以前のこのブログもそうだった。

しかし自分自身が他人のブログで「次へ」を押して次々に記事を読んでいくということをやった記憶がほとんどない。自分のブログでだって何か目的があって特定のキーワードで検索したあとに引っかかった記事を読むという感じなので、時系列に本文とセットで記事が 10 件ずつ表示される UI というのは意味をなしていないと思った。そもそもインデックスという名称なのに最近の記事数件しか表示していないのはおかしい。インデックスというからにはすべての記事の目次になるべきだ。

このブログはカテゴリーがあるので、サイトマップを作るとするとこんな感じになると思う。

+----------+        +------------+        +-----------+
|          |        |            |        |           |
|   Blog   +---+--->+  Category  +------->+   Entry   |
|          |   |    |            |        |           |
+----------+   |    +------------+        +-----------+
               |
               |
               |    +------------+        +-----------+
               |    |            |        |           |
               +--->+  Category  +---+--->+   Entry   |
                    |            |   |    |           |
                    +------------+   |    +-----------+
                                     |
                                     |
                                     |    +-----------+
                                     |    |           |
                                     +--->+   Entry   |
                                     |    |           |
                                     |    +-----------+
                                     |
                                     |
                                     |    +-----------+
                                     |    |           |
                                     +--->+   Entry   |
                                          |           |
                                          +-----------+

第一階層がインデックスページで、第二階層がカテゴリートップ、そして各記事がある。なのでインデックスページは二階層目の一覧ページになっているのが望ましいはずだ。しかし伝統的なブログはカテゴリーという記事をまとめる概念がありつつも、インデックスページから各記事ページへ直接遷移するのが主な導線だった。常に最新の記事が時系列順に並んでいるだけでは味気ないし、常連の読者ではないコンテキストを知らない訪問者には不親切だろう。

しかも SNS の隆盛で個人のブログのインデックスページが参照される機会というのはとんとなくなってしまった。個人が書いたブログ記事は SNS 経由で読まれ、個別記事だけが読まれる。インデックスページやトップページが読まれることはほとんどない。 SNS でシェアされている URL をクリックして個別記事を読んで、それ以上そのブログのほかの記事を読むことなく離脱してしまう。前後のコンテキストは無視して、一つのコンテンツだけがつまみ食いされてしまう。そんな流れにあらがいたいと思った。

これまで関連記事を記事下に表示するなどやってきたが、気に入っていくつか記事を読んで「ホーム」（ = インデックスページ）を訪れたユーザーがもう少しブログを深掘りしてみたくなるようにインデックスページを各カテゴリーの最新記事一覧とするようにしてみた。このブログは現在カテゴリーが 13 個あるので、それぞれから 4 件ずつ記事を取得すると 52 記事になる。全カテゴリーからまんべんなく 4 記事ずつ取得して表示するのは簡単なようで結構難しい。普通の SQL ではできない。 OR マッパーではまず無理だろう。

いろいろ調べてみた結果、 MySQL では GROUP_CONCAT というのが使えそうだった。以下のような SQL を書いた。

select entries.id
from entries
inner join (
  select
    category_id,
    GROUP_CONCAT(id order by created_at desc) as entry_ids,
    max(created_at) as last_created_at
  from entries
  where entries.draft = false
  group by category_id
) as grouped_entries
on grouped_entries.category_id = entries.category_id
and FIND_IN_SET(id, entry_ids) between 1 and 4
order by last_created_at desc, entries.id desc;

GROUP_CONCAT と FIND_IN_SET という関数を組み合わせることで、各カテゴリーから作成日の降順に記事を 4 件ずつ取得できた。このクエリでは記事 id のみ取得して、もう一回 DB に記事を取得するクエリを ActiveRecord で投げる。 ActiveRecord でクエリを組み立てるときは N+1 が起こらないように関連テーブルを JOIN する。

query = <<~SQL
  select entries.id
  from entries
  inner join (
    select
      category_id,
      group_concat(id order by created_at desc) as entry_ids,
      max(created_at) as last_created_at
    from entries
    where entries.draft = false
    group by category_id
  ) as grouped_entries
    on grouped_entries.category_id = entries.category_id
    and find_in_set(id, entry_ids) between 1 and 4
  inner join categories on categories.id = entries.category_id
  order by last_created_at desc, entries.id desc;
SQL
entry_ids = ActiveRecord::Base.connection.select_all(query).rows.flatten
entries = Entry.includes(:category, :user, :tags, :comments).where(id: entry_ids)

PostgreSQL のときに最初に取得した entry_ids の並び順通りに結果が受け取れるかは怪しいが、 MySQL の場合は一回目のクエリで取得した id 順に各レコードが ActiveRecord のクエリ結果として取得できた。あとはこれをカテゴリーごとにグルーピングして View でよろしくやれば良い。

なお各カテゴリーはカテゴリー内の最新の記事の作成日で降順ソートするようにしている。例えば現在のインデックスページの最下部には音楽カテゴリーがあるが、これは音楽についての記事を最後に書いたのが一年以上前だからだ。もしいま音楽の記事を書けば音楽カテゴリーがトップに浮上するようになっている。

見た目に関しては各カテゴリーの記事最新一件は大きなサイズで表示している。最も最近書かれた記事なのでより多く人の目に付いた方がよいだろうという考えだ。またすべての記事にサムネイルというか、アイキャッチ画像を表示するようにした。画像がない記事に関してはデフォルトのサイトアイコン画像を表示するようにしている。やっぱり視覚的に情報を捉えられるのは重要だ。画像がごちゃごちゃ表示されるのを嫌う人もいるかもしれないが、テキストだけでは人間の認知というのはどうしても追いつかない。

あわせて今回、インデックスページの冒頭部にこのサイトについての説明文を載せることにした。ながしまきょうさんや r7kamura さんがやっているののパクりだ。伝統的なブログのインデックスページは初めて訪れた人のことを無視しすぎていたと思う。そのブログ自体について説明するページがあるブログは少ない。最初の記事でブログを始めた経緯みたいなことが書かれたきり、そのブログは何なのか、誰が書いているのかが書かれることは希だ。きちんとブログについての説明ページと著者についての説明ページがあっても、左右のサイドバーやトップのナビゲーションの端っこに押し込まれて見られることはない。これではいけないだろう。というわけでインデックスページの一番目立つ位置にブログと自分自身の簡単な紹介を入れた。

ブログはなぜ衰退したかを考えてみると、 Facebook や Twitter の隆盛はあるにせよ、ブログ自体に初めて訪れた人に読まれるための工夫が欠けていたのだと思う。誰も自分のブログの継続率を計測したりコホート分析したりはしない。読者が前後の記事を読んでいることを前提に書かれた記事やサイト構成では初めて訪れた人はどうやっても離脱してしまう。特に書き手が芸能人でもない一般人の場合はなおさらだ。誰も RSS フィードを購読していないし、ほとんどの読者は初めて訪れる人なのだから、そういう人たちが読んでブログのテーマや著者の人となりが分かる構成にしていかなければならないのだと思う。でないと SNS でたまにバズったときだけ読んでもらえる、ソーシャルメディアの肥やしにしかならない。

この新しいインデックスページが正解なのかどうかは分からないが、ブログ衰退の流れにあらがっていきたい。

画像を拡大できるようにしたいという欲求は前々からあった。この手のものでは Lightbox が有名だが、 jQuery べったりなのでいまさら使いたくない。 P_BLOG の頃は FacyZoom というやつを使っていて好きだったが、 2008 年から更新されていない。何かいいのがないかなと探していて Medium Zoom というのを見つけた。

Medium Zoom - A JavaScript library for zooming images like Medium

A JavaScript library for zooming images like Medium

medium-zoom.francoischalifour.com

ブログサービスの Medium の画像拡大機能のコピープラグインだ。 npm パッケージになっているので導入も楽だった。

実際のこんな感じ。

一つ前に「キャンプもんなんてするもんじゃない」という趣旨の記事を書いたが、その記事を書いた日の午後に佐賀のキャンプ場までキャンプをしに行った。

家族はテントの中で寝たが、自分はハンモックで寝てみたいと思っていたので外で寝ることにした。 9 月の連休に久住のキャンプ場に行ったときはキャンプサイトが原っぱでちょうどいい感じの木が生えておらずハンモックを張れなかったので初めて実際のフィールドでハンモックを使うことになる。

ちなみに以前書いた記事ではウキグモ Light （ダウンハンモック）を買ったということは書いていたが、その後ヤフオクを物色していてトップキルト（ハンモック用掛け布団）のウンカイ Light が安く出品されているのを発見したのでサクッと落札した。これによりウキグモ Light とウンカイ Light 、 Exped Hammock Trekking Tarp （軽量タープ）のハンモック泊三種の神器がそろい、温かい低山であればいつでも野営できるようになった。

ウンカイ Light に関しては以下のブログが参考になる。

for 夏のハンモック泊 [AXESQUIN ウンカイ light] : 山に野に川に呑みに

いろいろ悩んだけど買ってみたら良かったです。ハンモック用トップキルト 「AXESQUIN ウンカイ light」 (色はロコウチャ)(AXESQUINの商品はすぐリンク切れするので商品一覧へのリンクです)ハンモックで一晩過ごそうと思ったら、マット的なものとシュラフ的なものはやっぱり必

sapporopotato.blog.jp

メーカーのアクシーズクインのページと GRiPS のブログも。

2025SS | アクシーズクイン | 機能性の高い登山・アウトドアウェアの新製品ラインナップ

www.axesquin.co.jp

『ウキグモ&ウンカイLight』

 こんばんは。 ウキグモLight、GW前の販売予定が、最後の修正に時間がかかりようやく販売開始です。 今回は解りやすい動画を作ろうと、私が説明しながら音声付…

ameblo.jp

実際に張っている様子は以下。

キャンプ場の標高は 550m くらいで、ふもとの気温と標高差からこの日のキャンプ場の最低気温は 15 度前後だったと想像される。ウキグモ Light の快適使用温度は 15 度以上となっていて、またウンカイ Light とも組み合わせていたので条件的には問題ないはずだが、明け方に風が吹くと寒さで目が覚めてしまった。

9 月下旬の久住のキャンプで寒さ対策の必要性を痛感していたので今回は寝るとき用にスウェットパンツと厚手のセーターを着込んでいた。それでも風が吹くと背面が冷えた。 XERO SHOES のサンダルを履いていた都合上、足は裸足で靴下ははいていなかった。ウンカイ Light には足を突っ込めるフットボックスがあるが、それでも足下からも冷気が入り込んで足が冷えた。またウンカイ Light からはみ出している頭にも寒気を感じたので、一度ハンモックから這い出して薄手のウィンドシェルをセーターの上から着てフードを被ってハンモックに入り直した。そうすると随分寒さは軽減されたが、 5 時頃からキャンプ場に合宿に来ていた少年野球クラブの子ども達がわーわーと騒ぎ始め、またあたりが明るくなってきたことにより寝付けなくなってしまった。結局 3 時間しか寝られなかった。以下の学びを得た。

• ハンモックは寒い。寝るときは厚着が必要。
• トップキルトからはみ出る頭の部分や足が冷えるのでフードのある服かニットキャップが必要。靴下もはいておく。
• ハンモック＆タープでは外の影響をもろに受ける。周囲の音や日の出で目が覚めるので早寝早起きが快適。

ダウン入りハンモックなので九州の低山であれば真冬でも使えるのではと期待していたが、やはり山は寒い。この感じだとやはりウキグモ Light ＆ ウンカイ Light は晩春から早秋にかけてしか使えない、夏用の寝具と捉えるしかない。どうしても冬場も使いたいなら、ブランケットで体をぐるぐる巻きにするか、ハンモックをまるごと覆ってしまうモグを検討するしかないだろう。

モグ連載③　モグの特徴とラインナップ

ハンモック専用の寝袋「モグ」の発売は当初の予定よりも少し早くなって8月20日頃になりそうだ。前回まではモグの企画開発背景についてお話ししてきたが、今回はいよいよモグの詳細についてお話ししよう。気になるラインナップは次の通り。モグwoolinsulationウールの中綿を採用した湿気に強いモデル。湿気の多い夏の渓を中心に春や秋にも使用できる。冬のシノギングではウキグモlightなどと併用して寒さを凌ぐこともできる。快適使用温度の目安：15℃前後（中に着込むものや個人差で変動）本体価格：￥39,800カラー：銀煤竹表地：旭化成10dn×10dn28g/㎡マイクロリップストップナイロン裏地：旭化成10dn×10dn28g/㎡マイクロリップストップナイロン中綿：lavalanwoolinsulation60g/㎡...モグ連載③モグの特徴とラインナップ

blog.goo.ne.jp

テントと寝袋を買いそろえると高い（テントが 5 万円、寝袋が 3 万円、マットが 1 万円くらいする）し重い（テント 1kg 、寝袋とマットで 1kg くらい）から、ハンモックなら軽いし安く宿泊装備がそろうはず、と思って揃えたハンモックシステムなので、これ以上何か買って本末転倒にならないように気をつけたい。

去年の春からキャンプするようになった。何度かキャンプをしに行くうちに、キャンプというのは思ったほど気軽に行けるものではなくてかなり段取りが必要なアクティビティであることが分かってきた。

キャンプ道具沼問題

まずはお金がかかる。テントなど一式道具を揃えればその後はお金がかからないと思っていたけどそんなことはなさそうだ。ホテルや旅館に泊まる旅行だと一回の旅行で最低でも 2 万円くらいは宿泊代がかかってしまう。キャンプなら精々キャンプ場に払うお金くらいだから気軽に行けるに違いないと思っていたが、全然そんなことはない。確かにキャンプ場に払うお金は高くても 5000 円程度だが、キャンプに行くと周りの人たちのキャンプ道具の充実ぶりに圧倒されて、キャンプに行くたびに道具を買い足してしまい、結局ホテルや旅館に泊まるのと変わらないくらいの出費になってしまう。いわゆる沼というやつで、これはいくら道具を買ってもキリがないのだと思う。道具が増えれば車が手狭になり、車にルーフキャリアーを付けたり、物置が手狭になって物置の増設、最終的には大きな車への買い換えなどで底なし沼的に出費が膨らんでいく。キャンプなら宿泊費を安く抑えて遠出ができると思っているとしたら多分それは大間違いで、キャンプに手を出したが最後、その後は後戻りができないキャンプ道具沼で死ぬまでキャンプの呪縛から解放されることはなくなってしまうだろう。

キャンプ場混みすぎ問題

次にキャンプ場混みすぎ問題だ。ホテルや旅館に泊まる旅行だと事前に宿の予約をしないといけないのが面倒で思い立った日にいきなり旅行に出かけることは難しい。いまは便利な世の中なのでインターネットでポチポチとやれば当日中にその日の宿を見つけることは不可能ではないが、当日だと高かったり宿を見つける作業が大変でわずらわしかったりする。キャンプならば宿の予約のような面倒な作業から解放されて思い立ったが吉日的におもむろに出かけてテントを張り、豪快に野外飯を作って適当に寝て、翌日はチェックアウトの時間など気にすることなく目が覚めた時間に起きて適当に帰ればいい、実に気楽に泊まりがけの遠出ができるはず、と思っている人がいるかもしれない。実は全然そんなことなくて、キャンプ場も大抵予約しないといけなくて、いきなり行って利用できるキャンプ場というのは非常に限られている。というかほとんどない。そもそもキャンプ場の予約システムは IT 化されておらず、ウェブサイトから予約申し込みをすることができない。電話で予約というところが圧倒的だが、電話で予約が完結するならまだマシな方で、酷いところだと電話後に FAX や文書のやりとりが発生したり、最も面倒なところだと事前の打ち合わせで実際にキャンプ場に訪れる必要があるところもある。なぜこういうことになるかというと、キャンプ場をやっているのは大きな会社ではなく個人か自治体だからだ。

個人経営キャンプ場

そもそもキャンプ場の利用料というのは高くはない。テント一張り 1000 円くらいのところから、高いところでも 5000 円くらいだ。 30 区画あったとして、週末にすべて予約が入ったとしても ¥5000 × 30 区画 = ¥150000 の売上だ。毎日 15 万円の売上があるわけではなく、キャンプ場は土曜日しか混まず平日は基本的にほとんど利用者がいないと考えられ、平日の収益はほとんどゼロなはずだ。加えて毎週末満員になるわけではなく、週末に天気が悪ければお客さんは来ない。しかも雨天のキャンセルの場合はキャンセル料を取らないキャンプ場が多いので、週末雨が降らなかったとして月の収益は 15 万円 × 週末 4 回 = 60 万円くらいとなる。この規模の個人経営のキャンプ場が予約システムの構築にお金をかける余裕はないだろう。家族経営でキャンプ場の維持管理をするだけでいっぱいいっぱいだろう。

自治体運営キャンプ場

意外かもしれないが、キャンプ場は自治体が運営しているものが多い。子どもの頃に子供会や学校の行事で訪れたキャンプ場は大抵自治体運営のやつだ。こういう自治体運営のキャンプ場も IT 化されておらず、平日 9 時から 5 時までの間に自治体の施設管理課か、自治体が運営を委託しているシルバー人材センター的なところに電話して空き状況を確認する必要がある。電話で予約が完結すればラッキーな方で、その後さらに書面での申込みや一度往訪しての打ち合わせが必要だったりする。なぜそうなっているかというと自治体の条例で決まってるからだ。何とか町施設利用条例みたいなやつがあって、利用者は利用したい日の 30 日前までに書面で申し込み、一度利用内容を説明して役場の承認を得ること云々、みたいなやつだ。こういう条例的なやつが足かせになってウェブで申込み完結、みたいな状況にはならないのだろう。それでも自治体運営キャンプ場は無料かお金がかかっても信じられないくらいに安いので利用者が殺到するから、ウェブ化して利用者の使い勝手を改善しようということにはならないし、役所の担当の人は日々申込み者からかかってくる電話や送られてくる書類の対応に労力を割かなければならない。

全然予約できない

キャンプ場は利用料が安いこと、土日に需要が集中すること、キャンプは雨が降ると中止せざるを得ないこと、予約システムがウェブ化されていないことによって、予約はすさまじいほどに面倒くさい作業になっている。利用料が安いのでみんなとりあえず何ヶ月も前から週末の予約を野放図に入れる。すると「今週末は天気がよさそうなのでキャンプでも行こうかな」というくらいののろまがキャンプ場に問い合わせたときにはどこも埋まっていて「おととい来やがれ」的な対応を受けることになる。全然気軽に行けるものではないのだ。むしろ金さえ払えば確実に泊まれるホテルや旅館を利用する旅行の方が手軽だ。

結論 キャンプに行くためには金と時間が必要

というわけで、キャンプは全然手軽ではないし、旅館やホテルに泊まる旅行に比べてお金を節約できたり自由気ままに行えるアクティビティではないということをわかってもらえたらと思う。天候やキャンプ場の予約の難易度も加味すると、キャンプはできて年に 2, 3 回なのではという気がする。 10 回も 20 回もキャンプに行ける人はお金もキャンプ場探しをする時間もある人だけだ。マイルを貯めて毎年特典航空券@ビジネスクラスでハワイに行くような人種こそがキャンプを趣味にしていそうだ。