portal shit!

Facebook にウェブサイトの URL をはっつけるとき参照される HTML メタ情報の仕組みに Open Graph Protocol ってのがある。 Facebook に URL を貼ると bot が URL の内容を読みに行ってページの概要や画像を取得し Facebook 内に埋め込み表示するというもの。 Facebook を見ている人はリンク先の内容をクリックする前に概要を把握できるので、リンクをクリックして見たい情報じゃなかった、ということを避けられる。 Facebook が考案して策定した仕組みだけど、 Facebook に限らずいろんなサイトで OGP タグを出力してるし読み込んでる。 Twitter にも似た仕組みあって Twitter Card という。この辺の対応は結構前にやってた。

アドベントカレンダーに備えて Open Graph protocol に対応

昨日飲みに行って今朝起きてからふとコード書きたくなって、アドベントカレンダーもあることだし（去年の Adventar で自分のブログだけ og:image がなくて画像が出てなくて残念だった）、...

portalshit.net

ただ自分のサイトが OGP タグを提供するだけではつまんないなと思ったので自分のブログにペロッと URL を貼ったときに相手先に OGP タグがあればそれを出力するようにしてみた。こんな感じ。

しかしここで困ったことがあって、↑でリンクしてる Circle のサイトは HTTPS で配信されておらず、単純に Circle のサイトで og:image に指定されている画像を SSL 化されているこのブログで読み込むと Mixed Content になってしまう。せっかく HTTP/2 で配信していたのに台なしになってしまう。またそもそも og:image は Facebook でシャアされることを想定されていることがほとんどなので、画像サイズがデカすぎていい感じにスクエアに表示するためには CSS の小技を駆使したりする必要があった。

いい感じに解決する方法ないかなと調べていたら良いのが見つかった。

GitHub - willnorris/imageproxy: A caching, resizing image proxy written in Go

A caching, resizing image proxy written in Go. Contribute to willnorris/imageproxy development by creating an account on GitHub.

github.com

Go で書かれた Image Proxy Server で、 HTTPS Proxy は当然のこと動的リサイズもできる。使い方は簡単でバイナリを落としてきて動かすだけ。 Go なんで ImageMagick をどうしたりとかを考えなくて良い。 そもそも Docker イメージも提供されているので Docker をインストール済みなら docker run するだけでも動く。 めっちゃお手軽。

こいつのおかげで HTTPS で配信されていないサイトの OGP タグを読み込んでも Mixed Content にならずに済むようになった。また og:image は適切にリサイズできるようになった。画像変換サーバーとかは結構難しいやつで個人のブログでこんなに簡単に使えるものだとは思ってなかったので正直ビックリした。

AWS の登場で大企業じゃなくても CDN 使ったり仮想サーバーでウェブシステムを構築したりできるようになった。さらには Go や Docker といった技術のおかげで複数の込み入ったソフトウェアを組み合わせて構築していく必要があったシステムが、まるで jQuery を使うような感覚でポン付けで使える時代になってきている。とても素晴らしい。

ちなみに OGP の取得には open_graph_reader という gem を使っている（昔からある opengraph という gem はメンテナンスされておらず最近の Nokogiri で動かない）。 open_graph_reader の作者が結構 Opinionated な人で、以下のような Anti-featurs を掲げている。

http://ogp.me/ の仕様に準拠していないサイトのことは完全無視というつくり。個人的にはこういう思想は好みだが、現実問題として使い勝手が悪い。例えば hitode909 さんのブログの OGP タグを取得しようとしたところ以下のようなエラーを出して取ってくれなかった。

article:published_time は ISO8601 形式の datetime であるべき、とのこと。はてなブログはかなりシェアが大きくリンクする機会が多いので残念。

🤩人気記事を表示するようにした - portal shit! で人気の記事を表示するようにしたけど、人気のエントリー（直近一ヶ月間でアクセス数が多い記事）に加えて、ホットエントリー（はてなブックマークでブックマーク数が多い記事）も表示するようにしてみた¹ところ興味深い結果になった。

短期的に膨大なアクセスを集める記事と長期的に安定したアクセスを集める記事は全く異なる。はてブのようなサービスで見つけられるのは前者で、後者のような記事を見つける場所が意外にネットにはないのではないかと思う。前者を動的な人気記事だとすれば、後者は静かな人気記事だと言えるだろう。こういう静かな人気記事だけを紹介するウェブサービスがあっても面白いのかもしれない。ちなみに人気のエントリーのリンク元は Google を除くとだいたいヤフー知恵袋か 2ch の過去ログが多い。

ツイッター歴10年を超え、どういうウプダテスをしたらファボをもらえるかはだいたい予想がつくようになってきたけど、それよりも前からやってるブログに関してはどうやったらバズるかがわからない。 mizch さんがブログを書く前にどのくらいブックマークが付くか想像できると言ってた気がする¹けどそういうのすごいと思う。「もうちょい反応あるんじゃないかな」と思った記事が全然伸びなかったり、逆に完全に自己満足のために書いた記事がバズったこともある。ツイッターもブログも商売と同じで読み手に価値を提供することができたら良い反応があるものだと思う。ツイッターに関しては面白ツイートで読み手に価値を提供できている（自分が面白いと思うものが読み手にとっても面白いと評価されている）のだろうけど、ブログでは価値を提供できていない（少なくとも狙ってはやれていない）のだろう。

短文で面白おじさんを演じるのは簡単だけど、長文だととても難しくなる。自分で自分が書いた過去の記事を読んでも「滑ってるなぁ」という感じしかしない一方で、たとえば寿司について書いた記事はいま自分で読んでも「攻めてるなぁ」と感じる。また仕事で社内ブログに記事を投稿してもそこそこ反響得られてるので文章を書く能力が著しく低いわけではないのだと思う。

つまるところ自分はブログで記事を書くときに、自分の興味関心とオーディエンスの興味関心を一致させられていないのだろう。ツイッターや社内ブログでは読み手が誰であるかを把握するのが簡単なので事前にコンテキストを共有した上で記事を書ける。コンテキストが共有されているのでどんな内容が受けるかを想像しやすいのだ。しかしブログの場合は誰が読むかは見当がつかない。パソコン関係の記事が受けるのか、日記的な雑文が受けるのか、蓄財についての記事が受けるのか、あるいはそれ以外か、全く見当がつかない。

15年前にブログが流行ったとき、ブログはテーマを絞った方がいいというアドバイスをよく目にした。思えばそれは読者の種類を絞り、読み手とコンテキストを共有することで記事を書きやすくするためだったんだろうなぁと思う。

自分はなんでもブログに書くスタンスでやってきたので今更書く内容を絞ったりはしたくないんだけど、今年は読み手とのコンテキストの共有を意識してインターネットしていきたい。

ウェブはバカと暇人のものから 10 年も経っていないけどインターネットの世界は大きく変わった。NHK を含む大手マスコミが Twitter を賑わせた事象の解説をニュースで行うほど。低所得の暇人しかいないというのも違ってきてる。 Facebook や Instagram には裕福な生活を満喫していて金持ちアピールに余念がない人たちが掃いて捨てるほどいる。アフィリエイターはカスばっかりというのも嘘で、おそらく士業についてる高収入な人たち¹がマイル乞食をしてハワイに行ったりビジネスクラスに乗って箸でスッチーのスカートをつまみ上げてパンティーを覗いたりしてる様子を公開してる。ネットは決してバカと暇人だけのものではなくなってしまった。ネットに社会的地位や経済力がある人たちが流れ込んできている。スマートフォンが登場し、誰でもいつでもネットに接続できるようになった。金持ちもネットの魔力に抗えなくなってきたのだろう。明石家さんまは相変わらずブログをやってなさそうだが²、 SMAP は解散しジャニーズ事務所を辞めた連中はブログを書いてるし Twitter も始めたし AbemaTV に出てる。中川淳一郎さんのウェブに対する当時の考察は当たっている部分もあったとは思うが、自分が当時の書評記事の最後で書いているように Twitter 、 Facebook 、 Instagram など³が日本で本格的に浸透して結果的には全く違う状況になってしまった。本当に面白い。

ウェブはバカと暇人のもの

梅田望夫的な楽観論を否定し、ネット利用者は金と時間に余裕のない「バカと暇人」が中心であり、発言の重みは誰が発言するかで決まりやすいと指摘。ネットはテレビや雑誌と異なる振る舞いを示し、企業やメディ...

portalshit.net

ブログに人気記事を表示するようにしてみた。やり方はめっちゃ雑で、 Nginx の access_log を集計して Bot や Crawler 、 RSS Reader からのアクセス、画像や CSS 、 JS ファイルへのアクセスを除外してアクセス数を集計して結果をテキストファイルに出力し、 Ruby で parse してフッターに表示してる。

仕組み

こんな感じのシェルスクリプトを置いて cron で実行してる。

#!/bin/bash

zcat -f /path/to/access.log* \
  | grep -vE 'useragent:.+?(bot|Feed\s?Fetcher|Crawler|Fastladder|Feed|Ruby|Aol\sReader|proximic|Hatena\sAntenna|Mediapartners-Google|subscribe)' \ # bot や Crawler を除外
  | cut -f5 | sed -e 's/request_uri://' \ # request_path だけ抜き出し
  | grep -vE '(favicon\.ico|index\.atom|\.js|\.json|\.css|\.jpe?g|\.png|\.gif|\.txt|\.php|\/admin|^\-$|^\/$)' \ # HTML 以外へのリクエストを除外
  | sort | uniq -c | sort -nr | head -100 | sed -r 's/^[ \t]+//g' \ # 集計して上位 100 件だけを得る
  | tee /path/to/public/access-ranking.txt # テキストファイルに書き出し

zcat -f しているのは gzip 済みのログファイルも cat したいため。このやり方だと現存するログファイルからしか調べられないので logrotate で設定している期間（自分の場合は 30 日）の集計しかできない。またサーバーを複数並べて運用しているようなアプリケーションではアクセスログがばらけるのでこんな雑なやり方は使えない。

Nginx のログのフォーマットは LTSV にしているので grep でのフィルタリングがやりやすい。まず User-Agent で bot っぽいアクセスを除外したあと、ログから request_uri のフィールドだけを切り出し、静的ファイルなどへのアクセスを除外したあと sort -> uniq -c -> sort -nr してる。

Ruby （ Lokka ） の方では以下のようなコードを書いて access-ranking.txt を読み込んでる。これをやらないと記事のタイトル表示やリンクが生成できないため。

class Entry
  class << self
    def popular(count = 5)
      access_ranking = File.open(File.join(Lokka.root, 'public', 'access-ranking.txt'))
      slugs = {}
      access_ranking.each.with_index(1) do |line, index|
        access_count, path = *line.split(" ")
        slug = path.split("/")[-1]
        slugs[access_count] = slug
        break if index == count
      end
      all(slug: slugs.values, limit: count).sort_by {|entry| slugs.values.index(entry.slug) }
    end
  end
end

フッターは適度にキャッシュしているのでスピードはそんなに遅くならない。

感想

アクセスランキングを表示してみて、意外と Twitter やはてブでバズった記事へのアクセスは継続的には多くないことがわかる。最近だと ARC'TERYX や SIERRA DESIGNS のパーカーの記事が人気があるようだ。これはおそらく寒くなってきててそういうキーワードで検索してたどり着く人が多いのだろう。 GarageBand でのアナログレコード録音の方法は前から人気ある。はてブとかは大して付いてないが、 Yahoo! 知恵袋や 2ch の過去記事・まとめサイトからのアクセスが多いようである。謎なのが痔ろうの記事へのアクセス数の多さ。痔ろうの症状・治療方法を結構詳細に書いたので Google 先生が良記事判定してくれているのかも知れない。家の記事ははてブでバズって 2000 ブックマーク以上付いたが、それでもやっと 5 位という感じ。バズっても短期的なアクセスしか得ることができず（人の噂も 75 日！！！、！）、長期的に細々とトラフィックを集めるためには特定の属性の人にだけ響く詳細な記事を書くのがよいのかもしれない。

以前、 The Old Reader について書いたとき、クローリングが遅くて不満だ、というようなことを書いていた。

The Old Reader はフィードの更新間隔がクソで、プレミアムアカウントのユーザーが登録しているフィードは 30 分おきにフィードをフェッチするとあるんだけど、全然そんなことなくて、平気で 4 時間遅れたりする。偏りがあって、頻繁に更新されるブログのフィードは頻繁にチェックされるけど、頻繁に更新されないブログのフィードはあまりチェックされないみたい。クローラーのつくりとしては正しいのかもだけど、利用者としては不満が残るなぁ。

— The Old Reader - portal shit!

そしたら以下のようなコメントを Pinboard でたまわってた。

フィード・リーダーのクローラーが遅い問題の話。Feedlyもそうだけど、クローラー側のポーリングは4時間ごとくらいで良くて、ユーザー（サービス）側がPubSubHubbbub使って欲しいな。

— https://pinboard.in/u:hail2u/b:e25b4cfe2a4a

確かにその通りなのでこのブログでも PubSubHubbub 使うようにしてみた。 Sidekiq とか入れたら Worker にやらせることできていい感じにできるんだろうけど、とりあえずこんな感じで乱暴に通知してる。

class Entry
  after :save do
    if Lokka.production? && !draft
      system("curl -s https://pubsubhubbub.appspot.com/ -d 'hub.mode=publish&hub.url=https://portalshit.net/index.atom' -X POST")
    end
  end
end

爆速で The Old Reader や Inoreader に更新が反映されることを確認したので Feedly とかでも更新後に即反映されるようになってると思う。

このブログ（ Lokka ）の DB は MySQL を使っている。 MySQL のバージョンは 5.7 なので、 column encoding を utf8mb4 、 collation を utf8mb4_general_ci とかにしておけば emoji を使えるかと思ってたけど使えなかった。長らく DataMapper が 対応してないかと思ってたけどリポジトリを覗いてみたら随分前に対応されてた。どうも Lokka 側に問題があるっぽい。

support for mysql utf8mb4 encoding by npeer2004 · Pull Request #76 · datamapper/do

added mapping for utf8mb4 encoding, which is supported by the underlying C driver and mysql. http://dev.mysql.com/doc/refman/5.7/en/charset-unicode-utf8mb4.html

github.com

Lokka の DB 接続設定は dsn を URL として記載するようになっている。 DataMapper は ActiveRecord のように Hash オブジェクトを DB 接続の引数に渡せるので、 encoding: 'UTF-8-MB4' をオプションとして渡せるようにしてやればよいっぽいが、いまの Lokka のコードでは encoding オプションを指定できないのでこれではダメっぽい。

ちょっと Lokka 側のコードをいじって encoding オプションを渡すようにしてみたところ無事 emoji が使えるようになったので lokka/lokka に Pull Request 出しておこう ⌨️