portal shit!

ずっと過去記事をどうやって効率よく見せるか（自分自身が効率よく読むか）ばかり考えている。一つ前の記事では絞り込み UI について書いた。

Archive ページの絞り込み UI をセレクトボックスに

年とカテゴリのテキストリンクを React Select のセレクトボックスに置換し、項目数増加による冗長さを解消。子コンポーネントで選択を受け親の setState を更新する構成を採用し、スマホで

portalshit.net

ブログというものが生まれたとき、誰も 10 年以上にわたってインターネットに文章を書くことを考えていなかったと思う。多くの人は途中で脱落してブログを止めたり飽きてほかのところ（ Facebook や Twitter ）に移ったりしただろう。ただ、同じ場所でしぶとく書き続けている人たちもいる。自分もその一人だ。

そういう人たちにとって、過去に自分が書いた記事をどうやって閲覧するかというのは大きな問題だ。過去記事を探すのに本文込みの一覧ページをページネーションしていくのはあまりにも効率が悪すぎる。一覧でガッと見たい。

というわけで、インターネット老人にしか用のない機能かもしれないが、過去記事一覧ページの UI/UX は非常に大きなテーマだと思う。問題点と対策を整理してみた。

過去記事が溜まることの問題点は、過去記事が探しづらくなることだ。対策としては各記事に関連記事へのリンクを表示する方法と過去記事の一覧ページを用意して探しやすくすることがあると思う。

過去記事の一覧ページは以下を満たしていて欲しい。

1. 記事を一覧できること
   • 一覧性が重要なのでページネーション、本文は不要
   • 記事の作成日（公開日）順に並んでいて欲しい
2. 記事を絞り込めること
   • 年やカテゴリーで絞り込めるとよい
3. 件数がわかること
   • どの時期にどの密度でブログを書いていたかがわかるため

10 年以上続いてるブログを書いてる人たちは多かれ少なかれ同じような問題（過去記事へのアクセシビリティ）を抱えているはずで、他の人たちがどうやっているのかを調べてみた。以下は長く続いているブログの Archive ページ。

Hail2u

ながしまきょうさんのブログ。

雑多な記録

ウェブ開発に関する話題が中心でしたが、もはやそれに限らず備忘録に近いものです。

hail2u.net

ブログのトップ自体が過去記事インデックス（タイトルのみ）になってる。本文を含む記事一覧ページはない。静的に生成してあって速い。絞り込むような UI はない。

氾濫原

関連記事のアルゴリズムやデザインなどを結構パクらせてもらっている cho45 さんのブログ。

アーカイブ - 氾濫原

写真・文章による、ある普通の人間の人生の記録

lowreal.net

本文込みの一覧ページとは別に年がずらっと並んでいる。記事の一覧はない。クリックすると年月ごとの記事一覧（本文込み）が表示される。記事を書いた時期を覚えておく必要がある。

Daring Fireball

Markdown の生みの親、 Apple ブロガー John Gruber のブログ。

Daring Fireball: Archive

daringfireball.net

本文込みの一覧ページとは別に年月ごとにグルーピングされた記事一覧（タイトルのみ）がある。このブログの Archives ページの UI に近い。検索窓があるが、 DuckDuckGo のサイト内検索に飛ばされる。スマートフォン用の画面がなく非常に見づらい。

hitode909の日記

hitode909 さんのブログ（はてなブログ）。

記事一覧 - hitode909の日記

以前はプログラミング日記でしたが、今は子育て日記です

blog.sushi.money

本文込みの一覧ページとは別に、本文が短く表示される過去記事一覧ページがあるが、一覧性は高くない（ページネーションが必要）。グローバルフッターに年月ごとの記事一覧へのリンクがあるほか、サイドバーにもカレンダー式のアーカイブ導線がある。「月別アーカイブ」は年をクリックすると月別のアーカイブ一覧が展開表示される。デフォルトだと今年（最新年）が展開表示されている。年・月・カテゴリーそれぞれの記事数がわかるのは便利だと思う。

Tatsuhiko Miyagawa's Blog

Blog Hacks の著者 miyagawa さんのブログ（ Medium ）。 Bulknews 時代からの過去記事がいっぱいあるはずだけど現在は 2011 年分からしか公開されていないみたいだった。

Archive | Tatsuhiko Miyagawa’s Blog

A blog about software engineering, podcasting, gadgets, and productivity.

weblog.bulknews.net

タイトルのみの記事一覧ページはなく、一覧性は高くない。本文込みの一覧ページの上部に、年ごとの絞り込み UI が表示されている。年を選択すると月ごとの絞り込みができる。はてなブログに近い。

Medium が酷いのはこのアーカイブページへの導線で、トップページには最近の記事が数件表示されるだけで、過去記事への導線はページ下部に申し訳程度に置いてあるのみ。しかも Medium というサービスの利用規約ページへのリンクと並んでいるので存在に気がつきにくい。

先日の記事（ 蟻地獄と個人ブログ - portal shit! ）では Medium はまとも陣営に分類したけど、個人のブログ内で回遊することを極力できないようにしようとしているのが伝わってくる。蟻地獄感ある。

Island Life

『ハッカーと画家』などポール・グレアム本の翻訳もされている shiro さんのブログ。

Archive/l0

Island Life

blog.practical-scheme.net

本文込みの一覧ページとは別に、本文が短く表示される過去記事一覧ページがある。年による絞り込みがあり、少し前のこのブログの Archives ページに近いが、 2002 年から記事があるので年のリンクが 19 個ある。 10 年後、 20 年後のことを考えると UI 上の問題が発生しそうだ。

portal shit!

最後にこのブログ。

portal shit!

本文込みの一覧ページとは別に年月ごとにグルーピングされた記事一覧（タイトル、カテゴリー、日付が表示）がある。年やカテゴリーによる絞り込みができる。

考察

Hail2u 、 Daring Fireball 、 Island Life など記事のタイトル一覧が表示されるタイプが好みだ。 Medium の一覧性のなさは最悪だが、年月の絞り込み UI はおしゃれだと思った。

個人的にはこのブログの Archives ページが一番使いやすい。自分で作っているので当たり前だ。スマートフォンでの閲覧性も問題ない。記事一覧の状態で本文で絞り込めるやつがあれば完璧なので、少ししたらチャレンジしてみたい。

多分自分しか見てなくて月間の PV も 10 しかない Archives ページで、これまで年を選択していない場合は直近一年間の記事だけを表示するようにしていたのを全期間表示するようにした。このブログは 1300 記事くらいあって、全部一気に取得するとそれなりにレスポンスが遅くなる（ 2 秒弱かかる）。待ってる時間が少々長くなるのでローディングスピナーを表示するようにしてみた。

結構いい感じで気に入っている。使ったのは以下。色の変更なども簡単だった。

GitHub - davidhu2000/react-spinners: A collection of loading spinner components for react

A collection of loading spinner components for react - davidhu2000/react-spinners

github.com

React Spinners

A collection of react loading spinners

www.davidhu.io

全期間の記事が表示されるとカテゴリーごとに絞り込んだときにそのカテゴリーで通算何件くらい記事を書いているのかが確認しやすくなってとてもよい。完全に自己満足のサイト改善。

スマートフォンで検索していてある大手ブログサービスでホストされているブログの記事に辿り着いた。記事を読んでいくと、ページ構造が「パーマリンクとは？」という感じになっていて驚いた。まるで蟻地獄で、下にスクロールしても終わりがなく、一度入り込んだら逃げられない感じだった。一つの URL に一つのコンテンツというインターネットのお約束を無視していて、 URL は個別記事のものだけど、下までスクロールすると次の記事の本文が読み込まれる。さらにスクロールするとそのまた次の記事が読み込まれる。 AutoPagerize がページャーのないところでも有効化されている感じで、読者の好みで無効化できない状態になっていた。

記事と記事の間には芸能ニュース記事へのリンクが差し込まれたり、そのブログサービス内で人気の記事ランキングが挟まれたりする。 A さんのブログを読んでいたはずなのに気がつくとゴシップニュースか他の人の炎上記事を読むことになっている。おまけにそこに広告も挟まれてくる。ページ内で URL が指し示すオリジナル記事の分量が 10% に満たないこともあるんじゃないだろうか。書き手にとっても読み手にとっても体験が良くない。大手のブログサービスはどこも同じような感じで、他のニュース記事や人気記事への誘導が激しい。

Twitter を追い出されたあとの Evan Williams が Medium を始めたときは意味がわからなかった。今時ブログサービスなんて始めてどうするんだろうと思った。はてなブログに関しても、なぜいま新しいブログサービスが必要なのかわからなかった。しかしいまならその理由がわかる気がする。

インターネット上でのコミュニケーションの場がブロゴスフィア（死語）から SNS へ移り、ブログの読者は SNS を流し読みしていてタイムラインに流れてきたコンテンツを消化するだけ。著者はコンテンツを提供するだけの存在となってしまい、両者の間でインタラクティブなやりとりが生まれなくなった。そんな状況でもう一度著者と読み手を中心に据えようとして始まったのが Medium だったのではないだろうか。

Attention Required! | Cloudflare

medium.com

Medium もはてなブログも広告は表示されないか表示されても少しだし、 Medium の人気記事への誘導は控えめで、はてなブログは同一ブログ内の記事しかお勧めしてこない。

はてなブログを開始されて間もないときに jkondo が書いている記事の最後にこんなフレーズが出てくる。

なぜ今、ブログなのか - jkondoの日記

はてなブログを11月7日にベータリリースしました。 リリース以降、予想を上回る勢いでベータ版の利用申し込みを頂いており、上限を拡げるたびに、すぐに人数が上限に達する状態が続いています。 先日の500人追加応募の際は、募集開始1分で160人の応募がありました。驚くべき勢いです。 日本のブログブームが本格的に始まったのは、はてなダイアリーをリリースした2003年から。まさにはてなダイアリーが日本のブログブームのきっかけでした。 それから8年後の今、なぜ改めて今、ブログなのでしょうか。 つぶやくだけが、文章じゃない ブログには当初、「自己表現ツール」と「コミュニケーションツール」の2つの要素が含まれ…

jkondo.hatenablog.com

「個」としての活動が、人生に新しい展開を持ち込み、より豊かな人生につながります。

SNS 、ブログ、あらゆるところで巨大なサービス（＝プラットフォーム）が幅を効かせて個人を飲み込もうとしているいま、どこでブログを書くと一番記事の価値を毀損しないかまで考えてブログを書く場所を選んだ方がよいと思う。はてなブログや Medium 、 note も流行ってるっぽいが、自分としてはやっぱり自分のブログを持つのが最高だと思ってる。

自分のブログを持つのが最高

Rebuild.fm の回を聞いてブログプラットフォームの変遷と独自ドメインの重要性を考察。Medium が独自ドメイン制限や頻繁なログイン促進で読者体験を損なう点に触れ、プラットフォームに依存すると

portalshit.net

独立自営のブログをやる人の選択肢を増やすために、今後も Lokka のメンテナンスはやっていきたい。やりたい・やると宣言して出来てないことだらけで申し訳ないけど、少しずつこのブログの機能を master ブランチに移植していって 2020 年でも常用できるブログにしていきたい。ちなみに以下は Markdown をオン・ザ・フライでプレビューする機能の Pull Request 。

Add on the fly preview by morygonzalez · Pull Request #254 · lokka/lokka

The Problem Existing POST to preview is a bit weird and costs full screen rendering. I want GitHub like on the fly preview. The Solution

github.com

あと Slack に Workspace を作った。何年か前に調べたときは lokka.slack.com が空いてたんだけど誰かに取られてたので lokkahq.slack.com となった。良かったら入ってください。ちなみにまだ僕しかいません。

Slack

join.slack.com

追記 2020-04-13

cho45 さんの昔のブログ記事を読んでたらわかる（わかる）という記事があったのでリンクしておきます。

CGMサービスの矜持について - 氾濫原

だいぶ前 (数年前) からからモヤモヤしてて何度も似たようなことがある度に↓みたいなツイートとかはしていたんですが、ちゃんと日記に書いてなか...

lowreal.net

個人サイトは終わってしまったのか - 氾濫原

各種ブログサービスとか Twitter とかその他 SNS とか、そういうのは、ないよりはいいけど、なんか違う。どう違うか、どう違うだろう。...

lowreal.net

ノウハウ蓄積みたいなコンテンツってASP型で預けるのは不安がありすぎるので、自力で配信しようねみたいなウェブ縄文時代みたいな話になるんですが……

— CGMサービスの矜持について - 氾濫原

ウェブ縄文時代 ってのは言い得て妙だと思いました。残念だけど一周回って個人ウェブサイトは縄文時代を迎えつつあるんだと思う。

最近、やたらこのブログにスパムコメントが来るようになった。コメントがあったらメールで通知されるようにしてるのだけど、コメント通知メールが一日十件くらい届く。

Google の reCAPTCHA を入れたことでほぼほぼスパムコメントは弾けていたのだけど、最近のスパムは reCAPTCHA をすり抜けるようになってしまったっぽい。加えて Akismet のスパム判定ロジックもポンコツになってしまったようで、ほぼほぼすべてのコメントをスパムと判定しなくなってしまった。

Lokka では Akismet でスパム判定されたコメントは一括削除できるようになっている（この機能は自分で作った）が、スパム判定されなかったコメントはちまちま一つずつ削除しなければならないのが非常に煩わしかった。

なのでコメント一覧にチェックボックスを表示して、チェックを入れたコメントを一括で削除できるようにしてみた。めっちゃ便利。

Akismet プラグインも少し改造して、自分で NG ワードを設定できるようにした。最近のスパムは露骨に Viagra とか Cialis みたいなキーワードが入ってて、どうしてこんなわかりやすいやつを Akismet は素通りさせてしまうのかわからないのだけど、自前の NG ワードフィルターで二重にチェックするようにした。

最後にアクセスログからスパムっぽいコメントの数を集計して管理画面のダッシュボードで閲覧できるようにした。引き続き監視していきたい。

ブログで使ってる Amazon S3 のバケットの画像のほとんどをミスって空ファイルにしてしまった…。 S3 に上がっている画像、 Cache-Control ヘッダーが付与されていないのですべての画像ファイルに Cache-Control ヘッダーを付与しようとしての事故だった。ファイル一覧を取得して AWS SDK Ruby で Cache-Control だけ付与するつもりだったのにファイルそのものを空で上書きしてしまって無となった。

大した操作じゃないと思って事前にバックアップを取っていなかった＆ S3 に上げておけば安心だと思って日常のバックアップも行っていなかった。スーパーアホ。写真ならアップロードし直すことは可能だけど、キャプチャとか、アニメーション Gif とか、ブログの内容に合わせて OmniGraffle で描いた画像は基本的には元のファイルが残ってなくて元に戻すことができなかった…。

CDN に残っていたものとローカルでキャッシュされていたものを探したが、 500 ファイル以上が失われてしまった。つらい…。

画像の吹っ飛び、過去にも何回か起こっている。レンタルサーバーの障害で消えたパターンもあったけど、自分のミスで消してしまうパターンが多い。自分が一番信用ならないので画像はプロに管理してもらうのが一番だなと身にしみて思った…。とりあえず S3 バケットのバージョンコントロールを有効にしたいと思います…

追記

AWS SDK Ruby での正しい Cache-Control ヘッダー付与の仕方は以下だった。

object.copy_from(object, cache_control: 'max-age=2592000,s-maxage=31536000', metadata_directive: "REPLACE")

#copy_from の引数に medata_directive: "REPLACE" を渡す必要がある。

🙅🏻‍♀️🙅🏻‍♀️🙅🏻‍♀️以下は NG なので注意されたし ☠️☠️☠️

object.put(cache_control: 'max-age=2592000,s-maxage=31536000')

これやるとファイルの body が空になります 🈳🈳🈳

一つ前の記事で結構 Feed Crawler からのアクセスが多いことがわかった。

誰がこのブログのフィードを読みに来ているのか

ブログのフィード閲覧ログを解析し、上位アクセス元が想定外にSlackbotや各種リーダーのクローラーだったことを報告。FeedlyよりFastladderや有料サービスの存在が目立ち、購読者数をUAで

portalshit.net

フィードは PubSubHubbub で利用する都合上、キャッシュしていない。しかもいまは 20 件記事を配信しているのでレスポンスが遅い。平均で 4 秒くらいかかっている。何とか効率的にキャッシュできないものかと思って FeedBurner を試してみることにした（サービス終了したかと思っていたけど、 .jp ドメインは終了しているものの .com の方は Google の中のサービスとして生き残っていた）。

FeedBurner からのアクセスの時だけ動的にフィードを生成し、それ以外の UA からのアクセスのときは FeedBurner の URL にリダイレクトするようにしてある。この記事を公開してちゃんと機能しているか確認したい。

追記

PubSubHubbub が機能しなくなってしまった😰 Googlebot に対しても動的なフィードを読ませないといけないのかもしれない…

追記 2020-04-08

PubSubHubbub の Google の Crawler は FeedFetcher-Google という文字列を含んでいるようだったので、以下のような記述を Nginx の設定ファイルに加えた。

if ($http_user_agent ~* (FeedBurner|FeedFetcher-Google\;)) {
    proxy_pass http://puma;
    break;
}

なぜ ; （セミコロン）を付けているのかというと、 Feedly などの Crawler も FeedFetcher-Google を名乗っているから。 Google の Crawler は FeedFetcher-Google のすぐ後ろにセミコロンを付けている。

Google と FeedBurner の Crawler にのみ本体のフィードを読ませ、それ以外の Crawler には FeedBurner のフィードを読ませるようにしている。

このブログのフィードを誰が読みに来ているのか調べてみた。一ヶ月間で 100 回以上見に来ている上位の UA は以下。

なんと一位はフィードリーダーの bot ではなく Slackbot だった。 Googlebot よりも多い。もはや Slack が一番のフィードリーダーになっているのかもしれない。こうなると PubSubHubbub とかの仕組みに乗っかって無駄なクローリングが発生しないようにして欲しい。フィードを購読する Slack の Workspace が増えるほどクローリング回数が増えてしまうと負荷がバカにならない。

三番目の Hatena::Russia::Crawler/0.01 ってのは Hatena と名前に入っているが本当にはてなのクローラーなのだろうか。 Russia という文字列が怪しい。

Feedly はもっと多いかと思ったが非常に少なかった。意外と Fastladder が多い。みんなどこかのサーバーで運用しているのだろう。ご苦労様です。

今回、ログを調べていて Feedeen といったサービスが存在していることを初めて知った。他に Feedbin などいくつか有料の RSS リーダーが存在しているようだ。 Google Reader や Livedoor Reader が終了した後、国内外で有料のフィードリーダーが開発されサービス提供されているのだろう。 Feedeen は料金が月 200 円で安い。日本人が作っているというのも安心感がある。自分は Google Reader 終了後はまず The Old Reader を使っていたけどいまは Inoreader を使っている。 Inoreader も開発元はルーマニアのインディー感あふれる会社で、フィードリーダーの世界は独立系の企業やデベロッパーによって活況を呈しているようだ。よいことだと思う。昔のインターネットを思い出す。

ちなみにフィードリーダー系の Crawler は UA にそのフィードの購読者数を表示しているのがおもしろい。こんだけ購読者数がいるんですよ、ということをブログ主に伝えて UA でブロックされないようにしているのだろう。