日頃、ニュースを読むための手段をスマートニュースからFeedlyに変えた。
たぶんここ2〜3年くらいはスマートニュースの世話になっていた。
当時ニュースアプリをいくつか比較した結果、一番しっくりきたので使っていた、と思う。
特に面倒なことを考える必要もなく、手軽にニュースが流し読みできて確かに便利だった。
ただ、次第に不満を覚えるようになってきた。
最大の不満は、個人的に読みたくない・読む価値を感じないニュースソースが少なからずあるにも関わらず、そういったソースをブロックする手段が存在しないところ。
きっと大人の事情なんだろう、とは思うものの、クソみたいな記事が視界に入る記事一覧の質を主体的に維持できない状況は、はっきり言ってストレスだった。
どうしたもんかと考えているうちに、ふと、Feedlyに思い至った。
Feedly自体は、かつてGoogleリーダーが 大掃除 されて以来、普通にRSSアグリゲータとして使ってきた。
こいつに読みたいニュースソースをじゃんじゃん追加してしまえばいいじゃない。
むしろ、なぜ今までそうしなかった?
ところで、Feedlyの無料プランにはいくつか機能制限がある。
無料プランのままでもまあ良いかな、と一時は思っていたものの、結局のところProプランにアップグレードした。
購読しているソースのうち、提携しているソースの記事を転載しているものがあって、そういった記事を排除できるフィルタ機能が決め手になった。
あと、思い返せば長いことお世話になっているので、お布施的な意味も大きい。
Feedlyに唯一抱いていた懸念は、未読件数をプレッシャーに感じないか、ということだったけれど、使い始めて程なく気にしなくなった。
どうせ全部は読みきれない。
そのために期間指定で既読にする機能があるんだろうし、実際使ってみると、Todayタブのおかげで未読件数を目にする機会がそもそも少ない。
2018年にお金を払った購読型サービス – r7kamura – Mediumが興味深かったので、真似して書き出してみる。
こうやって俯瞰してみると、まあどれも納得できる感じかな、と思う。
DAZN以外は。
IIJmio
¥3,000 / 月 + 通話料(多くて数百円)
携帯電話を含むモバイル回線。
内訳は、ミニマムスタートプランで音声回線を2本、うちメインの1本にだけ留守番電話サービス。
サブの回線は今ではiPadに使っているので音声契約である意味がないのだけど、バックアップ的な位置付けでそのまま維持している。
出先で重い通信をすることが滅多にないので、クーポンは毎月余らせている。
@T COMヒカリ
¥3,800 / 月
自宅の固定回線。
今の部屋に引っ越した時に、電器屋で洗濯機を買い換えるついでに契約して以来ずっと使っている。
途中で光コラボの一括契約に変更して数百円安くなった。
安定して不便のない程度の速度が出れば良い、くらいにしか考えていないので、特にこれと言って不満もない。
さくらのVPS
¥10,267 / 年
ここ88171.netのインフラ。
既に存在しないプランを使い続けていて、中の人が取り回しに気を揉んでいないだろうか、なんて勝手に心配している。
別のサービス、具体的にはAWSに移ることを考えたこともあるが、結局それに足るだけのメリットは見つけられなかった。
PlayStation Plus
¥5,000くらい / 年
PS4でやるゲームが大体オンラインなので、払わざるを得ない。
とは言っても、一応ネットインフラ界隈に身を置く人間としては投げ銭に近い心持ちではある。
たまにオッと思うようなタイトルがフリープレイに出てきたりもして、そんな時はお得感すらあったりする。
Netflix
¥1,200 / 月
平日は夕飯どきに孤独のグルメや孤独のグルメをだらっと流していたり、暇な休日には映画なんかを節操なく見たりしている。
利用頻度も満足度も高い。
DAZN
¥1,750 / 月
10年振りくらいに「そうだ、F1、観よう」と思い立って8月に契約し、シーズン後半から観ていた。
生中継はちょっと不安定なこともあるが、概ね満足できるレベル。
F2やGP3やラリークロスなんかもたまに観てはいたが、全戦追いかけるのは時間的に難しく、料金の高さも相俟って総合的なコスパは悪く感じてしまう。
車輪の再発明。
indexに長いエントリがどんと載ると正直邪魔な感じがするので、いわゆる「read more」を実現したい。
ただseemoreのように自分で区切り位置を指定するのは面倒。
なので、そこそこ良い感じに勝手に切り詰めてくれるプラグインを可能な限りお手軽に実装してみたら、こうなった。
最初は一応汎用性を考えて、MarkdownソースからHTMLに変換した後にHTML::TruncateやHTML::Splitを使って切り詰めようと思っていたのだけど、なかなか思うような結果にならなかった。
そこで汎用化はさっさと諦めて、 Markdownソースの先頭から1024バイト以降に初めて出現した空行 を基準として切り詰めることにし、さらにmicrotemplateといった、少なくとも条件分岐が可能なテンプレートエンジンを利用していることを前提とした。
ASCII文字列が多い場合に見かけ上のボリュームが結構ばらついてしまうので、文字単位ではなく敢えてバイト単位で数えている。
空行を区切りにしているのでマルチバイト文字に対する害はない。
タイトルやマークアップまでカウントしてしまうが、そこは諦めた。
プラグインのファイル名を 01more のようにナンバリングして、Markdownプラグインよりも先にロードさせる。
するとindexの出力時に(だけ)切り詰めが行なわれ、同時に $more::truncated というフラグが立つ。
story.html でフラグを見てあれこれしつつ、スタイルシートで頑張る。
定義を削除してしまうケースがどうしてもあるので、参照スタイルのリンク記法([id]: URL)が使えなくなるという不可避な弊害がある。
個人的には多用していないので許容できたのだけど、もしそうでないならレンダリング後にクライアントサイドで処理するしかない。