| @ブログ

noisy-ads.jpg

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

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

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

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

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

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

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

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

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

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

追記 2020-04-13

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

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

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

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

| @ブログ

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

スパムコメント

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

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

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

コメント一括削除

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

NG ワード

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

スパムの状況

| @ブログ

Rubbish

ブログで使ってる 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 が空になります 🈳🈳🈳

| @ブログ

GEORGIA at Dark

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

フィードは 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 のすぐ後ろにセミコロンを付けている。

Screenshot - 2020-04-08 08.58.24.png

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

| @ブログ

今宿駅近くのバー

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

Feed Crawler Ranking

なんと一位はフィードリーダーの 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 でブロックされないようにしているのだろう。

| @ブログ

関連記事

各記事の一枚目の画像をカバー画像とみなすようにして、関連記事にサムネイルを表示するようにしてみた。画像があるだけで記事をクリックしてみたい感が高まると思う(残念ながら Google Analytics で見る限り直帰率は改善してない)。人間は、文字だけを読むよりもイラストや画像など視覚的な情報を一緒に見ることで物事の理解度が高まると本で読んだ。自分で過去記事を読み直していても画像があると関連記事をクリックしてみたくなるし、満足感のある改修だった。

なおカバー画像の判定処理は記事本文を読み込んだ上で正規表現で調べているので多分重い(ベンチマークを取ったらタイトルを表示する処理に比べて二倍くらい遅かった)のだけど、関連記事表示部分はキャッシュしてるのでそんなに体感速度は悪化してないはず。

| @ブログ

dark-mode-and-light-mode.jpg

このサイトのデザインは黒地に白文字でダークモードという概念が出てくる前からダークモードだった。家のパソコンで見るときには見づらいと思うことはなかったが、外出先で日中にスマートフォンでサイトを見ると黒地に濃い赤色のリンクは見づらいなぁと思うことがあった。最近、 Mac や iPhone でダークモードの概念が浸透してきたので、自分のサイトの場合は昼間用のライトモード対応を行うことにした。こういう感じのメディアクエリを書けばよい。

@media (prefers-color-scheme: light) {
  ...
}

ただ、元々の CSS が結構ぐちゃぐちゃな書き方で難儀した。ダークモードとライトモードの切り替えが行えるサイトは必然的に CSS のメンテナンス性が高い状態だと思う。明暗を反転したときにこの色はこうなる、という対応関係が綺麗に提示できるような状態は、利用するカラーをシステマティックに整理できているということだと思う。 Sass で書いてあるなら利用する色はきちんと変数化されていて適切な命名がなされているとかそういう状態だと思う。 CSS の設計健康診断としてダークモード・ライトモード切り替え対応をやってみるのは結構いいと思う。