1  スラッシュドットの日記 RSSに content:encoded が追加されたようだ - yoosee の日記

スラドの日記にも書いたが、スラッシュドット各ユーザの日記/ジャーナルのRSSに全文入りで html タグもそのままの content:encoded が追加されたようだ。コメントで教えていただいた通り、今日の修正メモ - sugi の日記 に修正・更新内容として書かれている。sugi さんは今のスラッシュドット・ジャパンのシステムの面倒を(多分 tachさんと一緒に)見てくれている方。

Bloglines や LDR で見る感じ、スラッシュドットで書かれた日記の RSS 購読率はあまり高くないようだ。今までが description に改行もリンクもなく全文入っている形だったので読みにくかったというのもあるだろうけど、これで安心して購読することが出来る。個人的には何より von_yosukeyan氏の長文日記が読みやすくなったのが嬉しい。

ちなみにスラドでアカウントを持っていて「友達」登録をしている人ならば、http://slashdot.jp/~(自分のID)/friends/rss を購読することで友達の日記の最新記事を購読することができるようだ。

1  RSS の CDATA 部分を微調整

LDR で h4 等の要素が無効化されて表示が崩れる問題に関して、h4 の直後とその後の本文部分の直後にそれぞれ br 要素を追加。bloglines 等のそういった無効化をしないリーダだと隙間が空いてしまうかも知れないが、とりあえず当面はこれで。またそのうち手を入れ直すかもしれない。なお手を入れたのは index.rdf のみで atom.xml はそのまま。

2  この blog の publish datetime

そう言えばこの blog の rss 講読者から「フィードが数日遅れで表示される」と言われたことがあるんだけど、済みません、dc:date が結構嘘ついてます。次の日以降に前日の日記を書くスタイルだとどうしても published と記載内容がずれるんだけど、どう解決するのが美しいのかなぁ。せめて modified は正直に出すべきか。

1  大量の comment spam 到来と対策

今日だけで 10,000回以上、ピークは 1分間に100発以上で、例によって botnet からなので IP Address では弾きにくい(600アドレス程度ある)。とりあえず全て文字列によるフィルタリングで spam 判定できていたものの、これが馬鹿なことに spam 判別しても cache をクリアして rebuild する流れにしてしまっていた。お陰で毎回重い処理が走って load average が 30 越えすると言う悲惨なことに。ここは raise して逃げるように手直ししたが、不具合が出るようでしたら教えてください。

(追記) その後の、24日には約 23,000回程度の spam が来たが、負荷はさほど上がらずに済んだようだ。攻撃パターンはほぼ一緒なので、単一の発信元なのだろう。攻撃元IPアドレスは 1,200程度で、やはり海外回線系が多い。国内ISPからの攻撃もある。

1  ライブドアがRSSリーダー「livedoor Reader」を公開

所謂 la.ma.la プロダクトだろうか。全体的には動作も軽快だしインターフェイスも良く考えられていると思う。スラドでコメントにも書いたが、個人的に感じた良い点と悪い点を。

良い点

• 動作が軽い
• インターフェイスがまとまっている(多少煩雑)
• ショートカットが充実していて使いやすい
• フォルダ・フィードの整理が直感的で簡単
• 複数のビュー形式が簡単に切り替えられる

良くない点

• フォルダをまとめて開くという操作がない
• 本文中の <h3> など、幾つかの block 要素が無効化されている(お陰でタイトルと本文が混ざったりレイアウトが崩れたりする)
• w3m から使えない (ログインできない)。携帯電話からは?
• Web API が無い(無いよね?)

個人的に追加で欲しいのは以下の機能

• クリップしたものを別フォルダとして管理する機能(mark as new 的なもの)
• フィード中のリンクから開いたページを記録する履歴機能
• 購読フィード内の詳細検索

個人的にはクリップはあまり強く興味は引かれなかったけど、もしかしたら使い方が良くないだけかも知れない。開発者Blog も活発に更新されているようなので、この辺が実装されるといいなぁと呟いておこう。

2  livedoor Readerに乗り換えるかな

feed readerは移行コストがほとんどないから、大変だよなぁ、作る側は。

基本的には同意なんだけど、bloglines の場合は email subs と言う機能、つまり bloglines が発行するメールアドレスでメールマガジンなどを登録すると bloglines でフィードとして読めると言う機能があるので、これだけは乗り換え障壁になっている。bloglines 自体は、使いやすいとは言え重いしメンテナンスが多いしで微妙なんだけど、まだ乗り換えるには至らないなぁ。ちなみに livedoor Reader もレーティングと言う機能は独自機能で opml export も出来ないから、使い続ければある程度の乗り換え障壁にはなるかもしれない。

1  Firefox のメモリ使用量

Firefox がメモリ喰いだと言うのは良く言われることだろうが、ふと手元の環境を 1.5.0.2 に上げた時に見たのがあんまりだったので記録しておく。環境は Let's Note CF-Y4, Mem 1GB, Debian GNU/Linux sarge, kernel 2.6.12.2pm, Firefox 1.5.0.1 。

まず Firefox を 3 日以上継続して使い、タブの数を 20 にした状態。

% free
             total       used       free     shared    buffers     cached
Mem:        906304     895784      10520          0      23260      91516
-/+ buffers/cache:     781008     125296
Swap:      1951888     183160    1768728

Firefox (20タブ) 終了後

% free
             total       used       free     shared    buffers     cached
Mem:        906304     305920     600384          0      23540      96900
-/+ buffers/cache:     185480     720824
Swap:      1951888     178972    1772916

Mem free が 589,864 KBytes も増えている。実メモリの 65% に相当する。buffers/cache で見ても free が 595,528 KBytes 増えている。Firefox (20タブ) 再起動直後

% free
             total       used       free     shared    buffers     cached
Mem:        906304     388672     517632          0      23800     113320
-/+ buffers/cache:     251552     654752
Swap:      1951888     178964    1772924

起動直後ならばタブが同数開いていてもメモリ使用量は 50MB 程度。

2  Firefox のメモリ使用量を減らす幾つかの方法

えむもじら - メモリ使用量スレッド FAQ あたりが参考にはなるが、たいして決定的な方法はない。例えば browser.sessionhistory.max_total_viewers は以前にスラドの記事にもなったが、ブラウザ全体でせいぜい 8ページ分、32MB の削減にしかならないし、config.trim_on_minimize はあくまで最小化したときにメモリを非アクティブ領域(多くは swap)へ追い出すだけの設定だ。Firefox/Thunderbird を起動中にメモリを喰うソフトを一時的に併用したいときは便利かも知れないが。

コードを見たわけではないので想像だけで書くが、Firefox は恐らくメモリの効率利用のために、確保したメモリをタブを閉じても簡単には開放せずに次の新規タブのために保持しているのではないか。最終的には OS のメモリ管理機構が swap を使うのに任せてメモリを確保し続けているような挙動に見える。そう言う意味で、これはメモリリークではないのだが、全セッションでの最大仮想メモリ利用サイズを設定してそれ以上は使わない、なんていう設定があっても良さそうな気がする。でもそんな項目は無いし、実現するのも辛そうだ。

1  RSSフィードへの全文掲載についてのアンケート

はてな日記の RSS フィードに標準で全文を載せるかどうか、と言うアンケート。これは問いかけ自体がおかしい。だって書き手が後から自分で選択可能な設定に対して、「そんなのどっちでもいい(初期設定のままで構わない)」と思っているユーザの初期挙動をどうすべきかと言う質問をしてるんだもの。

こんなのははてな側が自身のリスクで勝手に設定を変えて、その旨の説明文を初期設定ウィザードにでも入れておけば宜しい。基本的にはどうすべきかを問うのでは無く「フィードとは要約と全文が入っていて読み手が自由な形で読み方を選択できるもの」が普通だと言う認識を進めて欲しい。書き手は選択可能だけど読み手が選択出来ない事に対して、読み手が不便になる方向に舵を切る必要はないじゃない。Web2.0 なんだしさー、Webを進化させてよね。

2  フィードに全文を載せるのはそんなに嫌な事?

さて「全文を RSS で読まれるのは気に入らない」と言う方へ今更ながら。そもそも Plagger なりの HTML から全文をぶっこぬいて RSS にするツールを使うという選択肢が読み手にある以上、概要しか配りたくないと言う望みは基本的に達成できない。概要と本文の両方をフィードしておけば、読み手は好きな方を選んで表示することが出来る。また「RSS に全文がないんじゃ面倒だから読まない」と言う読者は一定数以上存在する。例えば私。

だったら最大限読み手に面倒がない方法を提供することで、読者を増やした方がいいんじゃないかと思うわけですよ。

1  FEEDBRINGER

Ruby on Rails で書かれた bloglines のような online RSS リーダ。JavaScript でサクサク動くのはいいけど、Bloglines に比べると使い勝手や見栄えは今のところ微妙。フォルダ名変更が簡単なのは良い。不満点はたださんが書いているものと同じもの + 記事単位の Collapse (タイトルだけを表示し、本文は折り畳んでおく機能) とモバイル版(w3m にも優しい)が欲しい。あと、Feed から URL をクリックして元サイトの記事を開いた奴は、弱い Clip として記録が残ると嬉しいなぁ。

この手のサービスは OPML の export/import で移行が済んでしまうので乗り換え障壁が低い。しかし Bloglines の場合は Email subs と言うメールマガジンなどを RSS として読む機能があるので、私は余り簡単に移行できないのだった。

2  オンラインWeb版のRSSリーダを使う理由

私の場合は未読管理を一括で行うために、Webベースで何処からでも使えるサービスを使っている。つまりは IMAP と同じ理由。RSS + IMAP なサーバはあるのかな、と IRC で喋っていたら hail2u に載っている Info Aggregator と言うのを教えて貰った。考えることは一緒か、と思ったが rss.blogstreet.com は A レコードすら存在してないな。

1  Bloglines.com

ここしばらくは Liferea も使っていなくてほぼ Bloglines のみで RSS を読んでいる。家でも会社でも w3m でも電車から京ぽん(AH-K3001V)経由でも(/mobile/の方を)読める上、IMAP のように未読管理が出来るのがありがたい。フォルダ毎にまとめて読めるのもなかなか便利だし、気になる記事を Clip しておけるのも宜しい。

しかし Bloglines で読んでいると description しかないサイトはわざわざ全文を読みにまで行かない事が多くなった。また、その場から直接コメントを書けないのでツッコミを入れることも減ってしまった気がする。この辺りは痛し痒しかもしれない。コメントフォームも RSS で供給すればいいのだろうか(本末転倒)。

1  Bloglines.com

Bloglines がメンテナンス明けでリニューアルされてた。Bloglines 内で Blog を書いて公開できるようになったらしく、「Bloglines で RSS feeds を読む」→「気になる記事を見つけたら [Clip/Blog This] をクリック」→「Blog として公開 or Clipping として保存」と言うことが出来るようになったようだ。CSS ベースでのデザインの変更や、訪問済リンクの色変更、フォントサイズ設定が可能になった、などの細かい点も改善が見られる。

2  Bloglines notifier

新しいアイテムが追加されたときに notify が飛ぶプログラムを入れてみた。

3  Add to bloglines.com

上記リンクをクリックするとこのサイトが bloglines に追加される。右側ペインにも同じリンクがあるんだけど、一応。