portal shit!

ツイッターの連続投稿機能、便利だけどおっさんの長文投稿を誘発してそう。本当だったらブログに書いて記事リンク貼った方がよいけど便利なのでつい使ってしまう。短文のブログを駆逐しただけでは飽きたらず連続投稿機能で普通のブログも殺しにきてそう。 pic.twitter.com/sJMlejMnEQ

— morygonzalez (@morygonzalez) December 10, 2020

Twitter のスレッド機能で、投稿前の下書き段階からスレッド状態で長い文章を推敲しながら書くことができることを最近知った。推敲して長い文章を書けるのならブログを書く必要がないのではないか。これを知って自分は、 Twitter はブログの息の根を止めようとしているのだなと感じた。

スレッドの誕生

スレッドは 2017 年にリリースされていた。

Just a moment...

blog.twitter.com

確かにこの頃から長文を連投で投稿する IT 社長みたいなのをよく目にするようになった気がする。「フロハ」とか「ガバリ」とか「making coffee」とか書いてた頃の Twitter とは異世界になってしまった。

リリースノートによると、ユーザーが自分のツイートにリプライを書いて長い文章を書いている使い方に着目し、それをしやすくする機能としてスレッドを開発したようだ。長い文章を書けるようになったことで、それまで誰とも競合せず独自の市場（ Jaiku など同種の競合はいたがプラットフォームが持つ強力なネットワーク効果で蹴散らしてしまった）にいた Twitter がブログの世界に進出してきたのだ。

ブログの衰退

トラックバック

ブログでのコミュニケーションはとても衰退してしまった。いまでは信じられないかも知れないが、昔はブログにコメント欄やトラックバック欄があった。コメントはともかくトラックバックって何だと思う人はいるかもしれない。むかしのブログでは、誰か他の人の記事を参照して記事を書いたときにトラックバックする、という文化が存在した。

例えば A さんがうどんについての記事を書いていたとする。その記事を参照しながら B さんがそばについての記事を書いた。このとき、 B さんの記事から A さんの記事に対してリンクを張ることは可能だが、先に作成された A さんの記事から B さんの記事にリンクを作成することはできない。 A さんは自分の記事が B さんから言及されていることに気づくこともできない。関連した話題や言及されていることに A さんおよび A さんのブログの読者が気づくことができないのだ。

この問題を解決するのがトラックバックという仕組みで、 B さんのそばの記事から A さんのうどんの記事に対してトラックバックを送ることで、 A さんの記事内に B さんの記事へのリンクが表示される。 A さんは自分のブログに言及されていることを知ることができるし、 A さんのブログの読者は関連記事として B さんが書いたそばについての記事があることを知ることができる。

トラックバックボム

この仕組みは節度のある人だけがブログをやっていた時期には良かったのだが、徐々に相手の記事に言及することなく、自分のサイトへの誘導のためにトラックバックを送信する不届き者が出てくるようになった。 A さんのうどんの記事に B さんのそばの記事がトラックバックを送るのはまだわかるとして、 C さんが書いたバイクについての記事からトラックバックが届くとなると、全く話題に関連性はないし、バイクの記事から A さんのブログにリンクすることもないだろう。

こういうネチケット違反をする人だけではなく、最終的にはアフィリエイト目的で相手のブログと全く関係ない記事なのにトラックバックを送信するスパマーによって悪用されるようになり、トラックバックという文化は廃れてしまった。

議論の場となる Twitter

トラックバックが死ぬことで、ブログ上で議論するということがしづらくなった。 A さんのうどん記事に対して B さんがそばこそ至高という記事を書き、トラックバックを送った上で議論を挑むことができたのが、トラックバックがないのでネットの端っこでかみつくだけか、 A さんのブログのコメント欄に登場して議論をふっかけるしかない。しかしコメント欄もトラックバックと同じように衰退した。スパムのせいだ。静的サイトジェネレーターで生成されるブログではトラックバックはもちろんのことコメント欄も存在しない。ブログは議論の場として機能しなくなってしまった。

Twitter が流行ったからブログが廃れたという意見はかつてよく目にした。しかし Twitter が流行ったからというより、コメントやトラックバックという文化がスパマーによって破壊されてしまい、 Twitter の手を借りるまでもなくブログは勝手に死んでいったのだ。 A さんのうどん記事について「そばこそ至高」と言いたい人は、 Twitter で言及するしかなくなってしまった。この流れを加速させて、そもそも A さんも Twitter でうどんの話をするようにしたくて、 Twitter はスレッドを機能化することにしたのだろう。

コンテンツとの出会いの場としての Twitter

多くの人にとって、コンテンツとの出会いの場がポータルサイトやまとめサイトから、個々人のタイムラインに変わりつつある。みんなで同じ記事を見るのではなく、それぞれの小さなサークルの中でコンテンツを共有し合う感じだ。

いま、記事がバズったときのナンバーワンの流入元は Twitter だ。以前だったらはてブだったけど、はてブでホッテントリに入るよりも SNS でバズることの方がアクセスが集まりやすい。

はてブは一人にブックマークされただけではあまりアクセスが来ることはなく、矢継ぎ早に数人からブックマークされてホッテントリに入らないとバズれない。しかもホッテントリに入ったところではてブからのアクセスは精々 1 日で途絶えてしまう。みんなで一つのホッテントリを見てるので次々に新しい話題が出てきて、一つの記事がはてブのネットワーク内にとどまれる時間が短い。

一方で Twitter は、一人がシェアしてくれただけで割とアクセスがあり、フォロワーが沢山いるインフルエンサーによってシェアされるとあっという間に大量の流入をもたらしてくれる。しかもユーザーはそれぞれバラバラのタイムラインを見ているので、バズったときにネットワーク上にコンテンツが滞留する時間が長い。 Twitter 自体がタイムラインを単純な時系列順にせず複雑化させているし、一つの記事を別々の人がシェアすることや、リツイートの仕組みによって何度も人の目に触れさせることが可能になっている。おかげで一度バズると一週間くらいは流入を提供してくれる。

スレッドの最大の狙いは外部への離脱の抑制のはずで、これまでブログ記事や動画など、外部のコンテンツを参照する側だった Twitter が、スレッドによって長くまとまった分量のコンテンツをプラットフォーム内に持てるようになり、外に対してトラフィックを流すのではなく、プラットフォーム内にユーザーのアテンションをとどめておけるようになった。コンテンツとの出会いも消費も Twitter 内部で完結させたい、というのが Twitter の意図なはずだ。

タイムラインの滞在時間を最大化し、一つでも多くの広告を見てもらうことが Twitter のビジネスモデルにとって重要なはずだから、スレッドによるブログ殺しでバズの矛先を外部のブログではなく Twitter の内部とし、一人たりとも Twitter の外に逃したくないのだろう。

かつて日常について呟く場所だった Twitter が、日常についての短い文章に加え、長めの論説調の文章も有するメディアに変容しようとしているのだろう。プレースホルダーが "What are you doing?" から "What's happening?" に変わったのと同じ事情がそこにはある。

日常の出来事をブログに書く意義

こんにち、日記のような軽いブログ記事を見かける頻度がとんと落ちている。昔はもっとみんなライトにブログを書いていた。しかしそういうライトなブログは Twitter や Instagram などの SNS に飲み込まれてしまった。いまブログといえば、ある程度の分量のある熱のこもった記事か（暇な素人による社会時評とか）、芸能人のアメブロか、アフィリエイトか、プロが書いた商業的な記事しかない。普通の個人が書いた軽い記事を公開しづらい雰囲気が醸成されつつある。

ヒトデさんが年末にこういう記事を書いていた。

アウトプットの品質を下げておくと気軽に書けるようになる - hitode909の日記

12月であるし、アドベントカレンダーが回っていたりして、よくできた興味深いブログの記事を目にすることが多い。 よくできた記事ばかり見ていると、自分もちゃんとしたものを出さなければ、となってしまうことがありそう。しかしちょっと待ってほしい。 ブログ記事、といっても、プロの編集の手が入ったお金のかかった記事、一人で頑張って書いた大作、チョロっと書いて出てきた日記まで様々なものがある。 100文字くらいで終わっているものもあれば10万文字くらい書かれているものもあるので、文量に1000倍の差がある。 映像の世界で1000倍の差を出そうとすると、2時間すなわち7000秒の映画と、スマホで撮った7秒の動…

blog.sushi.money

#100DaysToOffload もこの考え方に通じるところがある。難しく考えずに、気軽にアウトプットすればよい。

100 Days To Offload

Can you publish 100 posts on your blog in a year?

100daystooffload.com

この感覚はとても重要で、いま我々は努めて軽いブログ記事を書くようにしないと、商業メディアや Twitter に飲み込まれて個人の簡便な意思表明がしづらい流れが固定化されてしまう。その日食べたもののことでも、その日見たテレビのことでも、その日読んだ本のことでも、その日遊んだゲームのことでも、何でもいいから SNS 以外の場所にも書くことが大事なのだ。 #100DaysToOffload のハッシュタグを付けて Twitter に何かを投稿するのは一見矛盾しているようで、 Twitter に過集中しつつあるインターネットのアテンションを再び個人ブログに取り戻そうという取り組みでもある。

なので皆さん、スレッドのご利用はほどほどにして、ブログを書きましょう

iPad を持っていないので確認していなかったのだけど、タブレットなど狭めの横幅のブラウザーでこのサイトのインデックスページを見ると残念な感じになっていたのでいい感じに調整した。横幅 1113px 以上だと past-entries セクションが 3 カラム表示になり、 1112px 以下だと 2 カラム表示に、 640px 以下だと 1 カラム表示になるようにした。これまでは 640px 以下のときの 1 カラム表示対応しかなくて、横幅が狭いブラウザーで見たときに悲惨なことになっていた。

その他、フッターの人気記事表示を変更した。インデックスページに最近の人気記事とはてブでホッテントリ入りした記事を表示するようにしたので、同じコンテンツがフッターにあるのは無駄だと感じた。かわりにフッターには今日と昨日の人気記事を表示するようにした。

よく読まれる記事の傾向はその日その日で結構違う。新しい記事を書くと当然その記事にアクセスが集まるのだけど、しばらく何も書いていないと意外な記事がアクセスを集めてたりして発見がある。例えば最近では Flickr の有料化についての記事がアクセスを集めていたが、 Google Photos の有料化が発表されたからだった。いっぱい記事を書いておくと、自分のブログへのアクセス傾向から世の中の動きが確認できて便利だ。

インデックスページをいじって各カテゴリーの最新記事 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 でたまにバズったときだけ読んでもらえる、ソーシャルメディアの肥やしにしかならない。

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

blog.8-p.info の過去記事ページの真似をして、 Archive ページにタグを表示するようにしてみた。

タグはあまり使っていなかったのだけど、一覧で記事タイトルだけ並んだときその記事にどんな内容が書いてあるのかを把握するためにはタグが便利だなと思い直し、タグを表示させてみることにした。いくつか過去のタグが付いていない記事にタグを振ってもみた。

このブログは技術情報からポエム、日々の日記まで何でもありのごった煮ブログなので、カテゴリーによる情報分類には限界がある。現在 13 個のカテゴリーがあるが、記事数にバラツキがあり、情報分類としてあまり機能していない。カテゴリーの粒度をもっと荒くして緩い分類に変更し、そこから先はタグによって超細かくラベリングすると情報の分類としてはまともになるのではないかと思った。

いま、カテゴリーの内訳がこんな感じ。

- "雑談":303
- "技術/プログラミング":272
- "映画/ドラマ/テレビ":150
- "Mac/iPhone":134
- "WWW":113
- "散財":95
- "旅行/ハイキング":70
- "ブログ":69
- "音楽":63
- "読書":34
- "写真":32
- "料理/食事":31
- "労働":27

もっと緩い分類にして以下みたいな感じにするとよさそう。

- 雑記
- パソコン・インターネット
- 見た・読んだ・聞いた
- 出かけた・撮った・食べた

カテゴリーとタグの使い分けは 10 年以上前から悩んでいる気がする。

情報分類の手法でありつつコンテンツの内容そのものを指し示すものでもあるからだろう。インスタグラムで #ラーメン #からの #うどん とかやってる投稿を見るととても嫌な気持ちになるのだけど、そういうことがされるくらいにタグというものは不安定なもので、正しく使おうとか気負わず、もっと緩く使えばいいのかもしれない。

もう廃れてしまったが、フォークソノミーが勢いを取り戻して、情報の発信者ではなく受け取り側がコンテンツにタグ付けできるような世の中になるとおもしろいのかもしれない。

フォークソノミー - Wikipedia

ja.wikipedia.org

Archive ページの月コンポーネント右肩にその月の記事数を表示するようにしてみた。その月の自分の頑張り具合が一目で確認できて便利。 Kazuyoshi Kato さんの blog.8-p.info の真似。

ただ、いま見てたら blog.8-p.info では記事の文字数も表示されるようになっていた。 blog.8-p.info の過去記事ページは非常に参考になる。

tech.portalshit.net の記事を取り込んだとき、記事ファイルの作成日を記事作成日として取り込んでいた。

tech.portalshit.net の記事を取り込んだ

75 件ほどあった tech.portalshit.net の記事を取り込んだ。実家に住んでいた 10 年前に始めた技術ブログで、最初は Rails 製の Mephisto 、その次に Jeky...

portalshit.net

Jekyll 移行後の記事の場合はそれで良いのだが、 Mephisto 時代の記事はデータベースから一度 Jekyll に移行した都合上、ファイルの作成日が Mephisto から Jekyll への移行作業を行った日になっており、 2011 年の 3 月 8 日に大量に記事を書いたことになっていた。作成日が 2011 年 3 月 8 日になってる全ての記事を見てまわって日付を元の記事作成日に変更する作業をやった。 Jekyll はファイルパスに日付が残る仕組みなのでその日付を使った。残念ながら作成時刻は調べようがないので諦めた。静的サイトジェネレーターを好きになれない理由の一つに記事の作成日時や更新日時がメタデータとして残らないことがあったのを思い出した。

今回の修正により 2010 年の記事数が増えて 2011 年の記事数が減った。 2011 年はブラック企業に転職するために福岡に引っ越してきたのでろくに記事が書けてなかったはずだが、それでも 57 記事書いていた。一つ前の記事が 2020 年の記事としては 57 個目だったので今年は 9 年ぶりに記録を更新した。 #100DaysToOffload に挑戦中なので 10 年ぶりの年間 100 記事達成目指して頑張りたい。

8 月は 11 記事、 9 月は 6 記事しか書けなかった。

8 月は結構駄記事を書いて量産したが、あまり大きな反響を得ることもなく不発に終わった。 Article of the month を自分で挙げるとするとプルドポークについて書いた記事になると思う。プルドポークはおいしいので是非お試しください。

プルドポーク

ハワイに行ったときにハワイ島のコナ空港のビアスタンドでビールを飲みつつプルドポークを食べた。プルドポークの存在自体は Netflix のバーベキューの世界1とかを見て知ってはいたが食べたことはな...

portalshit.net

9 月に関しては数は書けなかったがじっくり記事を書けたと思う。ウェブ縄文時代についての記事は結構反響があった。

ウェブ縄文時代の到来

secondlife さんがはてなブログの記事などを引き払って新しいドメインで個人ブログを作ってた。 心のざわめきを...

portalshit.net

Kazuyoshi Kato さんや「ウェブ縄文時代」という概念の提唱者の cho45 さんにもブログで言及してもらった。

• 懐古と復興 - blog.8-p.info
• ウェブ縄文時代への回帰 | tech - 氾濫原

その後 Blog Hacks 2020 という記事を書いた。これに関してはほとんど反響はなかったが、 r7kamura さんが頻繁にブログを更新するようになって個人ブログ界隈がにわかに盛り上がってきている気がする。この流れで今年はこれから年末にかけてウェブ縄文ムーブメントが来る気がする。

その r7kamura さんの記事にヒントを得て画像にキャプションを入れるやつをやってみたけどなかなか良かった。

画像にキャプションを入れる

画像にキャプションを表示させるようにした。 img 要素には alt 属性を細かく入れていたので alt の内容を抜き出して figcaption として表示させるようにした。やり方はまるっきり...

portalshit.net

こういうのができるのがセルフホストのブログを持つことの醍醐味だと思う。

もうちょいペース上げて書かないと 100 記事達成できないので10 月は頑張りたい。