2006-09 アーカイブ

告知を忘れていました

これから、 If you're 555, then I'm 666 のお祝いのために上京します。 関係者各位への現在地連絡は MOMENT で適宜お知らせします。

アンチブログ

ここ最近は HTML や CSS の事ばかり記事に書いています。 ( 時々 Movable Type のことや iPod のことに寄り道していることもありますが。 ) これは今取り組んでいることに生かすために書いているわけですが、そればかりに取り組んでいるとアウトプット欲 ( 何だそりゃ ) が詰まってしまいそうなので、合間を縫ってお手軽にアウトプットできる場を作ることにしました。

hxxk.jp の記事を書く場合は、「後から自分が読み返してもちゃんと内容を把握できるように」をモットーにしています。 現在では納得いくまで本文を徹底的に書き、タイトルを考え、効果的な要約になるように文章を読み直して要約を書き、過去の記事との整合性を取りながらタグ付けをして、どうにもまとまらなかったら翌日以降に持ち越して……といった書き方になっています。 改めてこう書いてみると、手間をかけすぎですね。

そして、 Movable Type によってほとんど自動化されているとは言え、日付によるロギングを行い、タグによる分類を行い、コメントやトラックバックの受付も行っています。 これは典型的な weblog の形態と言えるでしょう。

そこで、手軽にアウトプットする場はそれの逆張りで行こう ! ということで、ほとんどの機能を無くしていわゆる「本文」だけを書くようなコンテンツを作りました。 それだと辛うじて weblog ではあるかもしれませんが、考察もしないコメントやトラックバックも無い記事の分類もしないのは、人によっては ( いわゆるカタカナの ) ブログ ではないと捉えられるかもしれません。 更にそれどころか一定件数を超えたら消えていくようにしたので、 weblog ですらなくなっています。

ちなみに、逆張りとかアンチとか言っていますが、 antipop | subtechグループ - The best solution for most alpha geek wannabes would probably be to stay out of Plagger's way | antipop.vox.com のけんたろたんを意識したわけじゃないですよ、たぶん。

どういったコンテンツか

その日の呟きをただただ吐き出すためだけのコンテンツ。 手軽な投稿を実現するために、 moblog ゲートウェイによって携帯電話からの投稿を可能にしていますが、一定件数以上のログは残さないので moblog や weblog の類ではありません。

このコンテンツは、以下のような特徴を持ちます。

• ログを残しません。そのページに適当に書き連ねていって、古い分から消えていきます。検索エンジンのノイズにならないよう、 robots.txt で対処済み。それでもクロールするような検索エンジンにはそのページがノイズとしてひっかかるかもしれませんが、それはもう私が対応する範疇ではありません。
  • ログを残さないので、文章中に特定個人に対する愚痴や中傷は絶対に書かないようにします。愚痴以外でも、実生活に関する人は個人が特定されないようにするよう心がけること。
  • 各種 Web リソースからのリンクや引用について。 WWW に制限なく公開されているリソースへのリンクや引用などは、許可など取らず自由に行うべきですのでご自由にどうぞ。ただし一定の件数を超えるとその内容は消えますので、その時点でリンクはデッドリンクになりますし、引用は引用元が消える形になります。
  • SBM でブックマークすることも自由ですが、リンク・引用と同様その元の内容はいずれ消えます。そのことを踏まえてご自分で取り扱い方を考えてください。
  • なお、 hxxk.jp について - 著作権およびリンクでは全文の転載も認めていますが、基本的に WWW 上に現存しているものについてそう認めています。
• コメント機能やトラックバック機能はありません。どうしてもそのページの内容について私に物申したいのなら makoto[at]hxxk.jp までメールを送るか、あるいはこの記事のコメント欄にコメントを寄せてください。
• カテゴリ分けやタグ付けはしません。
• Feed を配信しないサイトは自分自身チェックする気が削がれるので、 Feed 配信だけは行います。
• 旅行中などの近況報告に転用する場合がしばしばあります。その際はなるべく hxxk.jp 内で予告するつもりです。

リソースの統合を図っていく

はてなダイアリーは運用目的が似ていたので、使用しないことにしました。 また、リソースを自分のドメイン内に集約していくというのもサブ的な目的としてありますので、 Vox の運用も近々見直すつもりです。

iPod の各シリーズのラインナップが一新

• アップル、新しいiPod nanoを発表
• アップル、新しいiPod shuffleを発表
• アップル、新しいiPodを発表

時期的にそろそろかなあと思っていましたが、やっぱり来ました新ラインナップ。 定番ネタということで、新旧ラインナップのスペックの比較表を作りました。

1. 旧 iPod nano と 新 iPod nano のスペック比較表
2. 旧 iPod shuffle と 新 iPod shuffle のスペック比較表
3. 旧 iPod と 新 iPod のスペック比較表
4. Amazon でも取り扱い開始

旧 iPod nano と 新 iPod nano のスペック比較表

• 1GB モデルの廃止
• 8GB モデルの新登場
• 全体的に低価格化
• カラーバリエーションが追加 (4GB モデル )
• 再生時間の飛躍的な向上
• 液晶の明るさの増加

と、多くの変更点が挙げられます。 最長 24 時間の音楽再生いいなあ……。 ( 最長 8 時間の初代 iPod mini と最長 14 時間の旧 iPod nano を持つ身として、これが一番羨ましいのです。 )

旧 iPod shuffle と 新 iPod shuffle のスペック比較表

• 512MB モデルの廃止
• クリップ型への形状変更
• 低価格化
• ホワイトからシルバーへの本体色変更

あたりが変更点となります。

もちろん新しいアルバムを聴くときなど、曲を順番通りに聴くこともスイッチ一つで簡単にできます とのことですが、これって一番最初のモデルからでしたっけ ? ……と思ったら、 iPod shuffleで、自分の好きな曲だけを聞くには？ / デジタルARENA という 2005 年 2 月の記事にて お気に入りのアルバムはシャッフルプレイではなく曲順に聴きたいとか、自分でアレンジしたお気に入りの順番通りに聴きたいという場合のテクニックも解説しておこう。 iPod shuffleは曲順再生ができないという誤解があまりにも多いからだ と書かれていました。 すみませんずっとシャッフル再生しかできないと思っていました……。

旧 iPod と 新 iPod のスペック比較表

• 60GB モデルの廃止
• 80GB モデルの新登場
• 全体的に低価格化
• 再生時間の向上

あたりが変更点となります。 ところで、この比較はスペック表から行っているのですが、液晶の明るさが向上した代わりに色数が落ちてしまっているような…… ?

Amazon でも取り扱い開始

よーし比較したところでいっちょ Amazon の商品紹介をしてみっかと思ってみたら、まだ Amazon では取り扱っていないようですね。 旧ラインナップばかりがヒットします。 新しいラインナップも Amazon に登場しました。

ちなみに The Apple Store (Japan) では既に取り扱いを始め、 24 時間以内の発送になっているようです。 ( ただし iPod shuffle のみ出荷予定は 10 月になっています。 ) 以下 Apple の回し者リンク。

The Apple Store (Japan) から買う

• The Apple Store (Japan) - iPod shuffle
• The Apple Store (Japan) - iPod nano
• The Apple Store (Japan) - iPod

Amazon から買う

• iPod shuffle
  • iPod shuffle 1GB
• iPod nano
  • iPod nano 2GB シルバー
  • iPod nano 4GB シルバー
  • iPod nano 4GB ブルー
  • iPod nano 4GB ピンク
  • iPod nano 4GB グリーン
  • iPod nano 8GB ブラック
• iPod
  • iPod 30GB ホワイト
  • iPod 30GB ブラック
  • iPod 30GB U2
  • iPod 80GB ホワイト
  • iPod 80GB ブラック

「http://www.example.com/mt/mt-tb.cgi/***」へのトラックバックは失敗しました: HTTP error: 403 Throttled

発端は Re: i d e a * i d e a - ブログにコードを貼り付ける方法で悩むの巻から i d e a * i d e a - ブログにコードを貼り付ける方法で悩むの巻へトラックバックを送った時にエラーになった件から。

以前にも #movabletype-ja に参加しましたから #movabletype-ja (Kickstart my heart) にトラックバックを送ったら同じエラーになったことがあったので、この機会に調べてみることにしました。

1. Throttling 機能とは
2. コメントに対する Throttling の流れ
3. トラックバックに対する Throttling の流れ
4. OneHourMaxPings と OneDayMaxPings
5. 管理者向けの mt-config.cgi 設定ガイド
6. MT::App::Trackback.pm を修正するという手段もアリ
7. FAQ ももう少し詳しく書いて欲しいなあ
8. トラックバック送信先

Throttling 機能とは

そもそも Throttled ってなーに、っていう方もいると思うので簡単に解説。 Throttling 機能とは Movable Type 3.1 から実装された機能で、コメントやトラックバックなどが大量かつ連続して送られてきた場合に、システムが過負荷状態に陥らないようにコメントやトラックバックの受付を行わなくする機能です。 よって、 Throttled というのはコメントやトラックバックの受付制限を超えてしまい、受け付けられなかったということです。

その機能の設定は mt-config.cgi 内で ThrottleSeconds ディレクティブを設定することで行えます。 このディレクティブの初期値は 20 となっており、また Movable Type 3.3 以降の mt-config.cgi ではそのディレクティブはコメントとしても記述されておらず、管理者が自ら記述しない限りは変更されないため、多くの Movable Type による weblog では 20 になっていると思われます。 なお、この値はコメントやトラックバックの受付の他に、検索機能の実行間隔にも影響します。

これはコメント投稿の場合は、「同一 IP からの 20 秒以内の連続コメント投稿はスロットリングを行う」ということになり、「コメント・エラー」の画面を表示します。 よって、この値を大きくすればするほど連続投稿に対する制限としては厳しくなるということです。 ちなみに、エラーメッセージとしては 不必要なコメントの投稿を防ぐために、連続した投稿を受け付けないように設定しています。 しばらくしてから、もう一度試してみてください。 といったものが出力されるようです。

なお、 ThrottleSeconds ディレクティブの値を変更すると、 OneDayMaxPings ディレクティブにも影響を与えるのですが、それは後述します。 また、トラックバックに関しては IP アドレスのチェックを行わないようになっていますので、他の人とのトラックバック送信とほぼ同タイミングになった場合、連続投稿していないつもりでもスロットリングされてしまうということも起こり得ます。

なお、いくつかの記事を見て廻りましたが、トラックバックに関して同一 IP のチェックを行わないという動作をバグとしているところがかなりありました。 ( 私も以前のそういった記事を読んでいて、てっきりバグなんだとばかり思っていましたが……。) ThrottleSeconds ディレクティブの説明を見る限りでは、バグではなくそもそもそういう仕様としているようですね。 ちなみに、 トラックバックでは、一定時間内にトラックバックを受け付けない設定として使われます というのは、 ThrottleSeconds によって直接的にスロットリングするのではなく、 ThrottleSeconds の値によって OneDayMaxPings の基準時間を設定するという間接的な働きをするということで、誤解を招きやすい表現になっていると思います。

コメントに対する Throttling の流れ

さて、それではコメントが連続して寄せられた場合の流れを考えてみましょう。

1. コメントの初弾が投稿される
2. 同じ IP アドレスからの第 2 弾コメントが
   1. ThrottleSeconds ディレクティブの値よりも短い間隔で投稿される
      • スロットリングされ、データベースに記録されない
   2. ThrottleSeconds ディレクティブの値よりも長い間隔で投稿される
      • スロットリングされず、 SpamLookup プラグインによる判定へ
        1. SpamLookup プラグインにてスパムと判定される
           • 「迷惑コメント」としてデータベースに記録される
        2. SpamLookup プラグインにてスパムと判定されない
           • コメントとしてデータベースに記録され、 weblog 内に公開される
   3. 同じ IP アドレスからの連続したコメントが 8 個に達するまでの時間が
      1. ThrottleSeconds*10-1 秒よりも小さい
         • スロットリングされ、それ以上のコメントはデータベースに記録されない
      2. ThrottleSeconds*10-1 秒よりも大きい
         • スロットリングされず、 SpamLookup プラグインによる判定へ
           1. SpamLookup プラグインにてスパムと判定される
              • 「迷惑コメント」としてデータベースに記録される
           2. SpamLookup プラグインにてスパムと判定されない
              • コメントとしてデータベースに記録され、 weblog 内に公開される

手動によるコメント投稿の場合でも、極端に短い間隔であればスロットリングされます。 また、機械的なコメントスパムの場合は、同一 IP から 8 個以上のコメント投稿があった場合に、より長い時間でスロットリング判定を行います。

トラックバックに対する Throttling の流れ

次に、トラックバックが連続して寄せられた場合の流れを考えてみましょう。 Ogawa::Memoranda の (o) さんからコメントをいただいて、誤っていた点を書き直しました。

1. 1 時間以内に送信された ping の数が OneHourMaxPings ディレクティブの値よりも多いか、あるいは ThrottleSeconds*4000+1 秒以内に送信された ping の数が OneDayMaxPings ディレクティブの値よりも多い
   • スロットリングされ、データベースに記録されない
2. 1 時間以内に送信された ping の数が OneHourMaxPings ディレクティブの値よりも少なく、かつ ThrottleSeconds*4000+1 秒以内に送信された ping の数が OneDayMaxPings ディレクティブの値よりも少ない
   • スロットリングされず、 SpamLookup プラグインによる判定へ
     1. SpamLookup プラグインにてスパムと判定される
        • 「迷惑トラックバック」としてデータベースに記録される
     2. SpamLookup プラグインにてスパムと判定されない
        • トラックバックとしてデータベースに記録され、 weblog 内に公開される

OneHourMaxPings と OneDayMaxPings

トラックバックの場合は ThrottleSeconds において IP アドレスのチェックを行わないため、 OneHourMaxPings および OneDayMaxPings というディレクティブを用いて、 1 時間あたり、あるいは 1 日あたりの最大の ping 数の制限を行っています。

OneHourMaxPings ディレクティブの初期値は 10 となっているため、「 1 時間以内に 10 回 ping 送信が行われた場合、以降の ping 送信についてはスロットリングを行う」ということになり、「http://www.example.com/mt/mt-tb.cgi/***」へのトラックバックは失敗しました: HTTP error: 403 Throttled というエラーメッセージを返すことになります。

また、 OneDayMaxPings ディレクティブの初期値は 50 となっているため、「 1 日以内に 50 回 ping 送信が行われた場合、以降の ping 送信についてはスロットリングを行う」ということになり、「http://www.example.com/mt/mt-tb.cgi/***」へのトラックバックは失敗しました: HTTP error: 403 Throttled というエラーメッセージを返すことになります。 なお、この場合の 1 日は 24 時間ではなく、 ThrottleSeconds*4000+1 秒ということになっているようです。 ( 先生、最近トラックバックスパムがひどいんです。 - Ogawa::Memoranda ) よって、例えば ThrottleSeconds を 60 にしていた場合、 60*4000+1=240001 ということで、 240001 秒が OneDayMaxPings の判定基準となります。 しかし、 ThrottleSeconds によるスロットリングは行わないのに、そのディレクティブの値が OneDayMaxPings に影響を及ぼすというのもおかしな話ですね……。

最近のスパムトラックバックのペースを考える限り、 1 日に 50ping という制限ではあっという間にスロットリングの基準に達してしまいます。 そして、 ThrottleSeconds の値によってはスロットリングを行う状態が 1 日以上続き、仮に解除状態になってもすぐスパムトラックバックによって再びスロットリングを行う状態になると思われます。

管理者向けの mt-config.cgi 設定ガイド

以上を踏まえて、正規のトラックバックでも HTTP error: 403 Throttled を発生させないようにする mt-config.cgi の設定を考えてみました。

ThrottleSeconds

OneDayMaxPings との兼ね合いを考え、 20 以下を目安に設定 !

OneHourMaxPings

これはあまり大きくするとスパムトラックバックをスロットリングしなくなるので、初期値 (10) よりも小さくしても良いかも ? これまでのトラックバックの受付実績を考えて設定 !

OneDayMaxPings

昨今のスパムトラックバック事情を考えて、初期値 (50) よりも大きく設定 ! 特に ThrottleSeconds をやむなく大きく設定している場合はそれに比例して大きく設定してください。 でないと常時スロットリング状態になります。

しかし、 OneHourMaxPings と OneDayMaxPings って、大きくすればそれだけスパムトラックバックを通しやすくなるし、かといってあまりにも小さくすると正規のトラックバックをスロットリングしてしまうし、悩ましいですね。

MT::App::Trackback.pm を修正するという手段もアリ

また、 ThrottleSeconds ディレクティブによるスロットリングで、同一 IP のチェックを行わないという仕様を、同一 IP のチェックを行うようにする、という解決方法もあります。

MT::App::Trackback.pm にパッチをあてるというのがその解決方法ですが、 3.2-ja-2 UO Patch - Ogawa Code にて Movable Type 3.2 用のアンオフィシャルパッチが公開されています。 Movable Type 3.3 用のパッチは公開されてないようなので、そのソースを参考にするか、あるいはそのパッチの元になったここギコ！: MovableType 3.2、MT::App::Trackback.pmの修正という記事を参考にして MT::App::Trackback.pm を修正すると良いでしょう。

FAQ ももう少し詳しく書いて欲しいなあ

実は、 9 月 4 日付けで技術的なよくある質問の中に、エラー「HTTP error: 403 Throttled」でトラックバック送信に失敗するという記事が投稿されていました。

が、回答としては トラックバック先において、何らかの制限を設けている場合や、トラックバックを拒否するような設定が行われている場合にトラックバックが失敗することがあります。 トラックバック先における受信設定については、該当のサイト管理者にお問い合わせください。 とだけ書かれてあるだけで、サイト管理者に対してどの設定を問い合わせて良いかなかなか分かりません。 管理者に mt-config.cgi のどのディレクティブを確認してもらえば良いかを書くか、あるいはマニュアルの該当部分へのリンクを書いてもらえば親切なのになあ……と思いました。

トラックバック送信先

エラー「HTTP error: 403 Throttled」でトラックバック送信に失敗する

回答部分に、 ThrottleSeconds および OneHourMaxPings と OneDayMaxPings ディレクティブについての解説あるいはマニュアルへのリンクを添えてもらうとより分かりやすくなると思います。

ソースコードのマークアップについて以前書いたなあ

i d e a * i d e a - ブログにコードを貼り付ける方法で悩むの巻を読んで、ソースコードのマークアップについて何度か記事を書いたことを思い出しました。 hxxk.jp は自分のための備忘録サイトです ! ( 何度も書いてアピール )

それら過去の記事を交えて、 i d e a * i d e a - ブログにコードを貼り付ける方法で悩むの巻の内容について触れてみます。

pre 要素でソースコードをマークアップするなら

以前 CSS を書く前に読んでもらいたいことでも書きましたが、 CSS 2 では、 IE や Firefox や Opera や Safari などの UA はデフォルトスタイルシートと呼ばれるスタイルシートを持っており、それを適用せねば、あるいはそうであるかのように動作せねばならないと示しています。

User agent: Conforming user agents must apply a default style sheet (or behave as if they did) prior to all other style sheets for a document. A user agent's default style sheet should present the elements of the document language in ways that satisfy general presentation expectations for the document language (e.g., for visual browsers, the EM element in HTML is presented using an italic font). See "A sample style sheet for HTML 4.0" for a recommended default style sheet for HTML 4.0 documents.

Note that the default style sheet may change if system settings are modified by the user (e.g., system colors). However, due to limitations in a user agent's internal implementation, it may be impossible to change the values in the default style sheet.

そしてそのデフォルトスタイルシートは、デフォルトスタイルシートのサンプルに沿って作られるようになっています。 一般的なパソコンの Web ブラウザにおいて、文書製作者によるスタイルシートやユーザスタイルシートが全く適用されない場合でも、 em 要素の強調部分がイタリックで表示されたり、 strong 要素の強調部分がボールドで表示されたりするのはこのためです。

もっとも、 This appendix is informative, not normative. とあるように、あくまで参考であって必ず守らなければならないものではありません。 例えば初期の携帯電話のように、文字をイタリックやボールドで表示することができない UA ではこれに準拠していないことになりますがそれはさておき。

さて、このデフォルトスタイルシートのサンプルの pre 要素に関する部分だけを抜粋してまとめてみると、次のようになっています。 ( ちなみに、 CSS 2.1 のデフォルトスタイルシートのサンプルでは少し内容が異なっていますが、 white-space や font-family の指定は変わりありません。 )

pre {
    display: block;
    font-family: monospace;
    white-space: pre;
    unicode-bidi: embed;
}

@media print {
    pre {
        page-break-inside: avoid;
    }
}

@media speech {
    pre {
        pitch: medium;
        pitch-range: 0;
        stress: 0;
        richness: 80;
    }
}

よって、ソースコードを pre 要素でマークアップするのなら、 white-space: pre; を指定する必要は特にありません。 ( 製作者スタイルシートやユーザスタイルシート内でユニバーサルセレクタを使って * { white-space: normal; } とでもしていれば別ですが。 )

もちろん、指定しても全く問題はありませんが一応「冗長な指定ですよ」ということで。 同様に、 font-family: monospace; とも指定されているので、 font-family プロパティを指定しなくても等幅フォントで表示されることになります。 ( なお、 code 要素もデフォルトスタイルシートは font-family: monospace; と指定されています。 )

pre 要素でマークアップすると、横方向にはみ出る ?

overflow指定なしもすっきりでいいかもしれませんが、横幅が長いコードを貼り付けると全体のレイアウトが崩れる可能性がありますよね と書かれてある部分ですが、以前 pre 要素による整形済文字列をどう扱う ? という記事を書きました。 i d e a * i d e a - Lifehacks by 100SHIKI.COM の……すみません著者情報を見つけられなかったので名前が分かりませんが「 i d e a * i d e a の中の人」は、 overflow プロパティの値に auto を用いるか scroll を、 IEですっきり見えるscrollの方にしますかね ということで決めていますが、 overflow: auto; という指定でも、合わせて width プロパティを指定しておけば IE でもはみ出る部分はスクロールバーを表示してすっきり見せてくれます、ご参考まで。

また、 コピペして使ってもらう という目的に重きを置くなら、 <pre><textarea cols="n1" rows="n2" readonly="readonly">ソースコード</textarea></pre> というマークアップ ( n1 と n2 は任意の数字 ) をすれば、 Ctrl+A によるソースコードのみの選択も可能です。 ( 私は pre 要素内に textarea 要素を配置することはあまり推奨しませんが、 XHTML 1.1 および XHTML Basic 以外の DTD なら、仕様上は配置することが可能です。 )

overflow指定したらCTRL+Aでtextarea内だけ選択できるかと思ったら全然だめでした・・・orz。 と書かれてありますが、おそらく pre 要素にて囲まれたボックスを textarea と混同しているのでしょう。 元来、 textarea 要素でマークアップされた部分は、 Windows の一般的なブラウザではその部分をクリックして Ctrl+A することにより、その部分のみの選択をすることができます。

実体参照をどうするか

皆さんコードを貼り付けるときはきっと単にコピペしているだけだと思うのですが実態参照はどうしているんでしょうね とありますが、私の場合はソースコード部分だけをテキストエディタにコピーして、 $ を &#36; 、 & を &#38; 、 < を &#60; 、 > を &#62; に置換して、記事中の文章にペーストしています。 なお、文字実体参照ではなく数値文字参照にしているのは私の好みです。

ちなみに、 $ は文字参照しなくても構わないのですが、私のように Movable Type を使用している場合は、 Movable Type のテンプレートのソースコードを記述する際に、 Movable Type のテンプレートタグと混同して誤動作してしまわないように文字参照しています。

ちょっとした tips

みなさんの方法も教えてくれるとうれしかったり・・・ごにょごにょ。 ということで、 hxxk.jp で使っているテクニックをご紹介。 ちなみに、「ソースコードをどのようにマークアップするか」という点はソースコードは blockquote でマークアップ ? にて書いていますが、 pre+code 派です。 なお、ソースコードのマークアップに関する議論リンク集というものもありますので、これを見てみるのも良いかもしれません。

さてテクニックの紹介と言っても、過去に書いた記事を紹介するだけですが。 pre 要素でソースコードの説明に詳しく書いていますが、 pre[title]::before という属性セレクタと擬似要素セレクタを組み合わせて、 pre 要素に title 属性を記述している場合のみに、その title 属性の値を ::before 擬似要素で表示するということをやっています。 残念ながら IE ( 7 を含む ) はこれに対応していませんが、「対応していない場合でも問題は無く、対応していればなお便利」という類のものなので、試してみてはいかがでしょうか。

トラックバック送信先

i d e a * i d e a - ブログにコードを貼り付ける方法で悩むの巻

私のサイト hxxk.jp は、 pre+code 派です。 また、合わせて overflow プロパティをどうしているか、文字参照をどうしているか、 title 属性による補足情報の提供方法などを解説してみました。

FeedBuerner Top40 っていうものがあったんですね

Lucky bag::blog: ldR の購読者数が Bloglines を抜いたにて初めて知ったんですが、 FeedBurner ( 日本語版 ) の登録者・講読者数のランキングっていうものがあったんですね。 「ランクアップのためにクリックお願いします♪」的なランキングは大嫌いですが、こういった登録者・講読者数の指標は特に嫌いということはありません。 そういう意味では livedoor Reader の登録数ランキングも同じですね。

何故嫌いではないかというと、単なるクリックによって集計するランキングは組織票や騙しクリックなどが容易で、あまり信頼できないイメージがあるんですよね。 もちろん登録者・講読者数によるランキングも、アカウントを大量取得して不正にランクアップという可能性もありますが、単なる閲覧中のワンクリックとレジストレーションではだいぶ障壁の高さが違いますので、ある程度信頼できるかなあと。

hxxk.jp は FeedBurner ( 日本語版 ) ではなく FeedBurner ( 英語版 ) の方を利用しているのでランキングには入っていませんが、もし FeedBuerner Top40 の中に入れ込むなら、一応 Top10 には入るくらいの講読者数なんですねえ。 もちろん、現在 FeedBurner ( 英語版 ) を利用している weblog が全て FeedBurner ( 日本語版 ) に移行すれば、 Top40 にすら入らない可能性も充分に考えられますが。

まあ、講読者数ランキングのためにサービスを移行するなんてことはしませんので、現在講読中の方はそのまま FeedBurner ( 英語版 ) による Feed をご講読ください。

更新をしなくてもページビューが落ちていなかった

さて、これが久々の更新となり、前回の記事である Safari と content プロパティ (3) から実に 2 週間以上間が空いたわけですが、実はページビューとしてはほとんど落ちていません。 Feed を講読している人が 500 人以上いるのだから、更新しなければ単純に 500PV くらい減少するのではないかと思いますが……。

もちろん、 Feed を講読している人は Feed リーダで読んでいる方も多いと思いますので、 Web ブラウザによるページビューには現れないのかもしれません。 しかし、よくよくアクセスログを見ていると、検索によるアクセスがかなりの率を占めていて、新着記事だけを読みに来る方の分のアクセスが無くても、全体としてはあまり減少しているように見えないということに気付きました。

アクセスログから分析する「はてなブックマーク効果」と「ニュースサイト効果」と「検索エンジン効果」でも検索エンジンによるアクセス効果について触れましたが、やはりランキングの順位を上げることや講読者数を増やすことに注力するより、記事を書くこと自体に力を入れていった方が結果的にアクセス増につながっていくのかなと思いました。 まあ私はアクセス数自体にはこだわっていないので、的確な分析が出来ていないかもしれませんが。 ( アクセス増によって疑問への回答や、私の間違った認識に対する補足の増加につながることは嬉しいのですが、数字自体の増加にはあまり関心を持っていません。 )

ちなみに、 2 週間以上記事の更新が止まっていたのは、本業やその他の行事が立て込んでいるうちに、だんだんと「書かなくてもいいかなあ」という気持ちになっていったためです。 ずるずるとそう考えてしまうというのは危険なので、まだ色々と立て込んだままですがちょっと記事を書くことにしました。 なお、 Lucky bag::blog の e-luck さん同様、 hxxk.vox.com の方ではもう少し頻繁に益体の無いことを書いています。 時間が取れたら、これまで d:id:hxxk に書いた内容も hxxk.vox.com に移そうかな。

FeedBuerner Top40 を見ていて気付きました

ちなみに、 FeedBuerner Top40 に挙がっている weblog の内、知っている weblog が 4 つしかないあたりに私の weblog 界隈への興味の狭さが窺えます。 講読している Feed 自体は少なくないと思うのですが、いわゆる有名 weblog はあまり見ていないなあと。

……ところで、 FeedBuerner Top40 という title になっていますが、 FeedBurner Top40 ですよね ?