2005-03 アーカイブ

髪が汚れていると泡立ちません

• 私たんニュース - 2005-03-30_20:30
• じっぷろぐ: すごく髪が汚れているとシャンプーは泡が出ないの？
• asahi.com： すごく髪が汚れているとシャンプーは泡が出ないの？-ふしぎ玉手箱

私たんニュース→じっぷろぐ経由で。

頭の皮膚には、ふだんから汗や皮脂が少しずつ出ていているの。 髪をつたって３０分で１０センチくらい進むらしいから、夕方ごろ髪がしっとりするのは、そのせいね。 運動すると、もっと汗や皮脂の量が増えて、ちりやほこりがくっつきやすくなって汚れるのよ。

私は脂性なので、徹夜で仕事をするとすごく髪がベタついて不快になります。

◇ののちゃん　なんで汚れると泡が出ないの？

◆先生　シャンプーの泡って、界面活性剤という成分が球状にたくさん並んだものなの。 せっけんやいろいろな洗剤の泡も同じよ。 この成分は、皮脂などにくっついた汚れがあると、それを取り囲んで水と一緒に流れやすい状態にしてくれるの。 たくさん汚れがあると、たくさんの界面活性剤が取り囲むことになるわね。 すると、どうなるでしょう？

◇ののちゃん　あ、そうか。泡になる界面活性剤がなくなっちゃうのか。

そして、仕事を終えて帰宅してお風呂に入るときは、普通に洗ってもなかなか泡が立ちません。 理由は上記引用の通りです。

髪が汚れている時のシャンプーのコツ

先に結論から書くと、髪が汚れている時のシャンプーのコツは、「 2 回シャンプーする」というものです。

シャンプーを多量に使うといった必要はなく、最初に少量のシャンプーを手に取り、軽くなじませます。 この段階で丁寧に洗う必要はありません。 さっとなじませ、一旦お湯で流します。 そして、改めてシャンプーをすると、きちんと泡立ちます。 ( 2 回目のシャンプーの量も、普段の 1 回シャンプーする時より少なめにするくらいでちょうど良いです。 )

シャンプーを使う際に、一度洗った後、二度目のシャンプーを使う時には、シャンプーの量はごく少量でも一度目よりもずっとたくさん泡が立つ。 そんなことを、学生時代、銭湯で僕が彼に言ったという。

記憶にはないが、確かにそういう現象に対する自覚はあるから、何かの拍子に言ったかもしれない。

「それで？」

「いや、昔はシャンプーなんか一度しかしなかったからピンとこなかったけど、二度洗いをしてみると確かにその通りだから、それからシャンプーで頭を二度洗いする度に、頭を泡だらけにしながらお前の言葉を思い出すんだよ」

原田 宗典氏のエッセイ集、できそこないの出来事の後書きでデザイナーの原 研哉氏はこう書いています。 この部分を読んだ学生時代の私は何故かそれを深く印象に思い、そして徹夜で仕事をした時のシャンプーの度に思い出しています。 もちろん、今回私たんニュースを目にした時も、真っ先にこれを思い出しました。

トラックバック送信先

• じっぷろぐ: すごく髪が汚れているとシャンプーは泡が出ないの？

アンケートシステムについての感想

はてなアンケートを使ってみました - 質問編でアンケートを行った動機は書きましたが、実はその直接の動機以外にも動機がありました。 元々はてなアンケートというシステムに興味があったので、いつかやってみようと思っていたのです。

私が考えるはてなアンケートの特徴として、

• ユーザ数が多く、ある程度しっかりした数の母集団が見込める
• 対象者の年齢や性別を限定することにより、ターゲットを絞ったアンケートを行える
• 終了ポイントを予め設定することにより、回答者数を一定の数にできる
  • 途中終了により、予定した数よりも少ないうちに終了することもできる
  • 追い銭のような形でポイントを払うことにより、予定した数よりも多く回答者を募ることもできる
• 択一回答方式、複数回答方式の 2 つの回答方式が選択できる
• 選択肢は最大 12 個設定できる
• 回答は完全匿名
• 掲示板「いわし」を使うことで選択肢に限定されない回答を募ることも可能

といったものがありますが、今回は年齢や性別を限定する意味が無い質問だったため、その辺りについてはまた何かの機会に検証してみたいと思います。 今回は出店地域が限定されているジョイフルというファミリーレストランを知っているか、知っているならその印象はどうなのかということを知りたかったため、ある程度の人数に聞いてみたかったのです。 そこで、 300 人という人数を設定してアンケートを行ったところ、 ( 土曜日の夜という条件も重なったのでしょうが ) 短時間で回答を集めることができました。

きっかけとなった IRC のチャンネルの方たちも回答してくれたり、のっかりポイントを送信してくれたりと協力的だったため、ついでに重複投稿ができるかを試してもらったら、 「特にエラーなどにはならなかったけど、 2 回目の回答では回答の途中経過に変化が無かったし、自分のポイントも増えなかった」 ということだったので、重複投稿は無効になるような設定になっているのでしょう。

初めての使用とあって、まだ私のチェックが行き届いていないかもしれませんが、特に不満な点は見当たらなかったため、良く出来たシステムだと言って良いのではないでしょうか。 ただし、誰が回答しているのかを調べる術が無いため、正確なリサーチを行いたいというニーズには応えられないのかもしれません。 逆に、今回の私のように、個人的なちょっとした疑問を払拭したいという場合には有用だと思います。

実際のアンケート結果についての感想

さて、実際のアンケート結果ですが、 そんなファミリーレストランがあるんですか ? を選んだ人が最も多かったです。 全体の約 60% が知らなかったという計算になります。 店舗の分布が九州に集中しているとはいえ、九州オンリーではないのだからせめて 50% くらいかと思っていましたが、それを上回る結果になりました。

更に、 知ってるけど入ったことはないなあ が 58 人いたため、知らなかった人と合わせると 300 人中 236 人がジョイフルに行ったことが無い、ということになります。 かくいう私も就職してからは行く機会が激減しましたが……。

他はまあ平均的に分布しているというか、総合して「安さ」や「場所」としてのメリットに票が集まった感があります。 また、掲示板「いわし」にて改めて意見を述べてくれた方もいらっしゃったので、自分の疑問を晴らすという目的と、はてなアンケートを実験してみるという目的は達せられたと思います。 ご協力くださった皆様、ありがとうございました。

なお、質問は既に終了していますが、まだジョイフルについて語り足りない人、または見かけた時には既に終了していて残念な思いをしてしまった人はこの記事のコメント欄に是非一言どうぞ。

トラックバック送信先

• はてな ファミリーレストランのジョイフルってどうですか ?

自転車には反則金という概念はないの実例

• asahi.com : マイタウン千葉 - 朝日新聞地域情報 - 自転車に違反切符　信号無視で

自転車で赤信号を無視して走行したとして、千葉南署が千葉市内の無職男性（２６）に、道交法違反容疑（信号無視）の交通切符（通称赤切符）を切っていたことが２３日、分かった。 自転車に乗った人に対して、警察官が警告に従わなかったとして交通切符を切るのは県内で初めてという。

調べでは、無職男性は１５日、同市緑区誉田町１丁目の市道で、警察官らに「戻りなさい」などと呼びかけられたにもかかわらず、赤信号を無視して道路を横断した疑い。 同署員らが同日、近くで自転車の安全運転を呼びかけるキャンペーンをしていた。

警察官に注意されてもなお無視して横断すれば、警察官としても流石に見逃すわけにはいかないでしょう。 まさか、「自転車だから捕まらない」とでもたかをくくっていたのでしょうか。

（信号機の信号等に従う義務）

第７条　道路を通行する歩行者又は車両等は、信号機の表示する信号又は警察官等の手信号等（前条第１項後段の場合においては、当該手信号等）に従わなければならない。 （罰則　第119条第１項第１号の２、同条第２項、第121条第１項第１号）

まあ、自転車に限った話ではなく、 道路を通行する歩行者又は車両等 と定められているので、歩行者なら捕まらない、というわけでもありませんが。

具体的な罰則は ?

信号無視での赤切符ということですから、

第119条　次の各号のいずれかに該当する者は、３月以下の懲役又は５万円以下の罰金に処する。

1の2．第７条（信号機の信号等に従う義務）、第８条（通行の禁止等）第１項又は第９条（歩行者用道路を通行する車両の義務）の規定に違反した車両等の運転者

という罰則になります。 原動機付自転車や自動二輪車、自動車などの場合は交通反則通告制度によって、いわゆる青切符によって通告される反則金が科されることがほとんどです。

しかし、以前 自転車には反則金という概念はない - 反則金が科される対象で述べた通り、自転車の場合は反則金が科されることは無いため、今回のようなケースは即赤切符ということになります。

もしかしたら、ニュース記事だけを読んで 「おいおい赤切符かよ、ずいぶん罰則が重いな」 なんて印象を抱いた方もいるかもしれません。 しかし、自動車などと違って、自転車の違反に切符を切る時は赤切符しか無いのです。

まあ、交通反則通告制度も、あまりに自動車などの交通違反が増加し、その都度出頭を求めて略式命令を言い渡していてはとても手が回らないといった理由で施行されたという背景があるため、このまま自転車の交通違反が増えれば、自転車にも交通反則通告制度が適用されるように道路交通法が改正され、頻繁に取締りが行われるようになる……かもしれません。

類似例

• 自転車　悪質運転に赤切符　大阪府警 (産経新聞) - goo ニュース

こちらの方が日付は前になりますが、どうも私が見落としていたようです。

今年に入り大阪の交通事故死者数が全国最悪の水準となり、府警は九日までに、死者増加の大きな要因になっている自転車の悪質な交通違反に、刑事処分につながる「交通切符」（赤切符）を切る異例の取り締まりに乗り出した。 制度上、自動車やバイクの比較的軽い違反に、前科とはならない反則金を科す「交通反則切符」（青切符）は自転車に適用できないため、罰金を含むより重い処分となるが、府警は「大阪の自転車の違反は目に余る」と強行策の採用を決めた。

二月上旬に府警交通部が各警察署に通達した。 対象は、自転車についても道路交通法で禁じられている信号無視や二人乗りなど。 警察官が再三注意しても続ける悪質な違反には躊躇（ちゅうちょ）なく赤切符を切ることにした。

こちらのケースでも信号無視が含まれていますね。

すでに先月二十四日、大阪府枚方市内で何度も指導、警告したのに自転車の二人乗りをやめなかった男子大学生（１９）について、道交法違反（定員外乗車）容疑で赤切符を切って摘発。 この大学生は近く家裁送致される見通しになっている。

定員外乗車は６月以下の懲役又は10万円以下の罰金と、信号無視よりも刑罰が重くなっています。

府警交通総務課は「取り締まり強化で事故増加に歯止めをかけたい。 『たかが自転車』といって違反すれば、加害者にも被害者にもなることを訴えたい」としている。

この 「たかが自転車」 という意識が事故の増加の原因の一端を担っていると思います。 「軽車両」という名の車両を運転している自覚を全ての自転車の運転者に持っていただきたいものです。

青切符と赤切符

• 自転車　悪質運転に赤切符　大阪府警 (産経新聞) - goo ニュース

前項と同じニュースですが、青切符と赤切符の違いについて分かりやすく書いているので、メモしておきます。

昭和４３年、車社会の発達で「１億総前科」と呼ばれるほど違反者が急増、比較的軽い違反者に対して刑事処分の代わりに反則金ですます「反則通告制度」を規定した改正道交法が施行。 反則金納付を求める告知書などの書類を「交通反則切符」（青切符）と呼ぶ。 一方、悪質な違反者に出頭を求める書類が「交通切符」（赤切符）。 赤切符の場合、交通即決裁判所で略式命令を受けるのが一般的で、罰金刑以上なら前科になる。 道交法改正当時、自転車の違反は想定されていなかった。

この 違反者が急増 という事が理由になっていたのなら、やはりこのまま自転車の違反が増加していけば、交通反則通告制度の適用範囲の俎上に乗ることが検討される可能性も無いとは言えません。

Firefox 1.0.2 日本語版リリース

• Reread(2005-03-24) - Firefox 1.0.2 (ja-JP) リリース済み？

Firefox 1.0 から 1.0.1 への自動アップデート方法を書いた時点では Firefox 1.0.1 の日本語版は自動アップデートに対応していなかったので、対応するのを待っていたのですが、その間に 1.0.2 のリリースが行われました。 こちらは既に自動アップデートに対応しています。

旧バージョンをアンインストールしましょう

しかし、

とりあえず、手順が少しややこしかったですが、いつものようにアンインストール→インストールで移行しましたよ。こうしないと旧版のアンインストール情報が残ってしまうので。（いつになればこれが直るのだろう？）

という記述や、 Another 朝顔日記 - Bug 247884にて紹介されている Bug 247884 - Upgrading doesn't remove / uninstall the old entry from Add Remove Programs - Windows にあるように、 一度旧バージョンをアンインストールしてから 1.0.2 をインストールした方が良いようです。 アンインストールせずに 1.0.2 にアップデートしたらどうなるかは自分では試していませんが、コントロールパネルの「アプリケーションの追加と削除」の中に 1.0 と 1.0.1 と 1.0.2 が混在してしまった、という話も出ているようです。

そして、私は勘違いをしていたのですが、旧バージョンをアンインストールしてもプロファイルは消えません。 ( よく考えれば当然なのかもしれませんが、アンインストール = プロファイルも消える、と捉えている人はそこそこいるようです。 ) 次項で手順を示しますので、それを参考に 1.0.2 へのアップデートを行ってください。

Firefox 1.0.2 への自動アップデート方法 ( スクリーンショット付 )

手順は Reread(2005-03-24) - Firefox 1.0.2 (ja-JP) リリース済み？に書かれているものをなぞっただけです。 なお、環境は Windows XP Home Edition SP2 を想定して書いています。

1. Firefox のすべてのウィンドウやタブを閉じておきます。
2. メニューバーの右端に小さなアイコンがあるはずですので、それをクリックします。
3. Firefox 1.0.2 (ja-JP) Software Update が更新項目の中にあり、かつチェックボックスにチェックが入っていることを確認して「今すぐインストール」ボタンをクリックします。
4. インストーラーが起動するが、即座にキャンセル します。
5. 確認のアラートが出ますが、「はい」を選んでキャンセルしてください。
6. Firefox を一旦終了し、 Firefox のインストールフォルダの下の UninstallFirefox.exe を実行します。 ( Windows ですと、 C:\Program Files\Mozilla Firefox\uninstall\UninstallFirefox.exe というパスにあると思います。 もちろん、このパスは環境によっては違います。 )
7. 環境にもよりますが、これまでの行程でデスクトップ上に Firefox Setup 1.0.2.exe が保存されていると思いますので、それを実行します。
8. 先程はキャンセルしたインストーラを、今度は「次へ」を選択して進んで下さい。
9. インストーラの指示に従ってインストールしていくと、無事 1.0.2 にアップデートされるはずです。 なお、ブックマークや拡張機能などはきちんとプロファイルから引き継がれています。

トラックバック送信先

• Reread(2005-03-24) - Firefox 1.0.2 (ja-JP) リリース済み？

私が要望したから、というわけではないのでしょうけど

• はてなダイアリー日記 - 見出し別表示時のナビゲーションの追加について

はてなダイアリーの記事別表示への要望と疑問 - 記事別表示モードへの要望および、はてなダイアリー - 真琴＠臨時更新場 - はてなダイアリーへの要望で要望していたことが実現されました。 私以外にも同様の要望を出していた方 ( 悠 々 日 記 - はてなダイアリーへの要望 ) がいらっしゃったようです。

これは私の偏見ですが、こういった機能の実装って目に見える部分にしか適用されないことが往々にしてあるため、 link 要素による前後の記事へのナビゲーションについてはあまり期待していませんでしたが、これもきちんと実装されていました。 こういった細かい対応は、流石はてなだと思います。

<link rel="prev" href="/hatenadiary/20050322/1111492597" title="はてなツールバーバージョンアッ...">
<link rel="next" href="/hatenadiary/20050322/1111477010" title="携帯メールの更新不具合について">

このようなナビゲーションになっているため、 Opera や lynx 、 Firefox + Link Toolbar などでのはてなダイアリー巡回がよりやりやすくなっています。 IE な人には body 要素内のナビゲーションも用意されているので安心。

……ただ、カテゴリを設定するようにしているダイアリーだと、カテゴリ名までそのナビゲーションのリンクアンカーテキストに含まれてしまうのがちょっと残念。 更に、複数カテゴリを設定することが多いユーザのダイアリだと、カテゴリ名だけでリンクアンカーテキストが埋め尽くされてしまいます。 この辺りは再考をお願いしたいところ。 はてなダイアリー - 真琴＠臨時更新場 - はてなダイアリーへの要望 - リンクアンカーテキストにて要望を出しました。

誰かが覚えてくれていたということ

• love all ... personal memo ... - 見出し別表示時のナビゲーションの追加について

以前、真琴さんが要望を出していた件ですね。

私があーだこーだ言ってたことを、しっかりと覚えられていたことがちょっと嬉しかったです。 るりさんが私の名前を出して書いてくれていたおかげで、このナビゲーション追加も見逃すことなく知ることができましたし。 ( 普段からはてなダイアリー日記もチェックしていますが、自分のはてなダイアリーは専ら携帯電話を使ったサブ的更新に使っているので、あまりしっかりと読んでいるわけではないのです。 )

トラックバック送信先

• はてなダイアリー日記 - 見出し別表示時のナビゲーションの追加について
• love all ... personal memo ... - 見出し別表示時のナビゲーションの追加について

不名誉なリンク集についての雑感

とあるサイト上に、「不名誉なリンク集」というものが数日前にありました。

「ありました」と書いているのは、既に WWW 上から消えているためです。 そのページに書かれた内容は理論として穴が多く、そして幾分攻撃的な文体であり、またそのリンク集に取り上げる基準も曖昧であったためか、批判が殺到したのでしょう。

とは言え全く破綻した理論ではなく、一部分には同意できるものもあったため、考察を加えてみようと思います。 と言っても、巡回先でこの話題に触れていたところの意見を元にしただけなので、考察じゃないかもしれませんが……。

なお、ここで語るポイントは「認証が必要な SNS にのみ CG や文章を公開すること」についてです。 SNS に重点を置き、結果的に本来のサイトの更新を疎かにすることはその人の配分によるものなので、考察から除外します。

そして、主に mixi をターゲットにして語りますが、それ以外の SNS にも共通するものになるだろうと思います。

1. SNS にのみ公開することのメリット
2. SNS にのみ公開することのデメリット
3. 非ユーザから見た SNS
4. まとめ
5. トラックバック送信先

SNS にのみ公開することのメリット

反応が得られやすい

これはコメントをもらいやすいという雰囲気やインターフェースにもよるのでしょうが、やはりコミュニティ、またはグループといった機能による部分が大きいと思います。 共通項が多いほど、コメントをする方も気軽にコメントできますし。

公開するためのコストが少ない

SNS に限った話ではなく、レンタルの weblog サービスにも言えることかもしれませんが。

ウェブサイトに関する知識が無くても、日記を公開することができます。 画像をアップロードすることもできます。 そして、同じような趣味・嗜好を持つ仲間を見つけることが簡単にできます。

仮にウェブサイトに関する知識をふんだんに持っていたとしても、 SNS ならデザインを考えたり過去ログを作成したりといったことを考えなくて済みます。 ブラウザからちょちょいとアクセスして、文字を打ち込んだりパソコン内の画像を指定するだけで公開できるので、 SNS 外にサイトを持っていたとしても、公開コストの低い方に傾くということは充分に考えられます。

SNS にのみ公開することのデメリット

限られた人にしか公開できない

「閲覧者を選んでいる ! 選民思想だ ! 」 なんて言うつもりではありません。 単純に 「閲覧者が限定されてしまう」 ということです。 もちろん、閲覧者を限定したいのならそれはデメリットになり得ませんが、どうしてもメリットよりもデメリットが大きくなると思います。

現状の mixi ユーザがどれくらいいるのか知りませんが、仮に 25 万人としましょう。 その場合、どうしても 25 万人以上の人には見てもらえないということです。 インターネット全体だと何億人という単位で見てもらえる可能性があるのに。

単純に数だけの物差しでは計れないかもしれませんが、逆にどうしても自分の文章を読ませたい、どうしても自分の CG を見てもらいたい、そんな人がいたとしても、その人が SNS に参加していなければ叶いません。

サービスの枠を抜けられない

これも SNS に限った話ではありませんが。

自分でウェブサイトを作れば、構成や見た目などのデザインは思いのままです。 weblog サービスも、若干自由度は制限されますが、多くの場合カスタマイズが可能です。

もちろん、単純に、本当の意味での日記のみを書きたいとか、同好の士を探したいとか、そういった目的であればいいでしょう。 ただ、本格的に文章を発表したいというニーズには mixi の日記の機能では耐えられない可能性がありますし、 CG などの作品を発表する人は、サイトデザインも含めて見てもらいたいというニーズがあると思います。

しかし、 SNS のほとんどは構成や見た目は固定されており、自分の色を出すのが難しくなっています。

非ユーザから見た SNS

この項は私の場合について語ります。 他の非ユーザはまた別の考え方を持っているでしょう。

私も以前は mixi を使っていましたし、 orkut や GREE も利用していました。 しかし、 hxxk.jp を始めるにあたり、 SNS に参加することに求められる 「パーソナリティの公開」 ということをしたくなかったため、全て退会しました。

そうして、当初は自分に関することは秘匿したまま Movable Type などの技術的な weblog を作っていました。 ( 現在は xxxk memo - personal titles で断片的に触れていますが。 ) また、 WWW 上ではこうしたスタンスでも、 IRC などではどんどん曝け出していたりもします。

私が常駐している IRC のチャンネルのメンバーで構成したコミュニティが mixi 上に存在し、それが結構盛り上がっている、とも聞いています。 しかし、私は自らの意思で SNS から離れたため、それを見れないことについて不満を述べることはしていません。 気にならないと言えば嘘になりますが、どうしても見たいのなら自らのスタンスを変えて、誰かに invite してもらえばいいのですから。

mixi のみで更新して一般サイトの更新をおろそかにしてるずるいやつなんか晒しちまえ……って言うのが趣旨なのだろうか。 なら、「BASIC 認証かなんかで一部コンテンツへのアクセスを制限しているサイト」もずるいんですよね、晒していただこうか？ とかふと思った。

パスワードで制限してるだけじゃん、パスすら調べられない方が悪い？ じゃあ、mixi には入れないのは友達がいないからですよね？ そういう友達作れない方が悪い――って論法は駄目ですかそうですか(穴があるから駄目ですけど)。 自助努力しないやつにはそれ相応の扱いでいいとは思いますが。 まぁこれは自戒も込めてますけどねorz。

かろかろさん ( CornerValley ) は 穴があるから と仰っているので、おそらく分かった上でこう発言しているのでしょうが、 「 mixi に入れない = 友達がいない」 と等価で結ぶのは確かに穴のある理論だと思います。 ( 私の場合は mixi に入らない と表現した方がいいかもしれませんが。

……って、これじゃ論点がずれていますね。 私の場合は 「 mixi 内のコンテンツは見ない」 であって、 「 mixi 内のコンテンツを見たいけど見られない」 じゃないので。 何だか、売り言葉に買い言葉で反論しているように見えたので、ちょっと忠告。

まとめ

結局のところ、 SNS 内にコンテンツを公開することって、公開する側の自由だと思うのですよ。 ( それまとめになっていない ) SNS 内にコンテンツを公開することのメリットとデメリットは先ほど述べた通りですが、それをどのバランスで保つかは本人次第ですし。

「不名誉なリンク集」 は 「絵師サイト」 に主眼を置いており、そして私は絵師サイトとの交流があまり無いため、的外れな考察になっているかもしれません。

リンク集として具体例を出してあげつらうのではなく、言い方を考えて 「 mixi と絵師サイトの更新頻度との関連」 といった形で問題提起すれば、真摯に耳を傾ける方も多かったのではないでしょうか。

トラックバック送信先

• CornerValley - “不名誉なリンク集”を見て

生存報告

これほど揺れたのは生まれて初めての体験でしたが、幸い身体的・物的な損害は皆無でした。 ただ、亡くなられた方や怪我をなされた方もおられるので、喜んでばかりもいられないのですが。

その時間帯は 2 日連続の徹夜明けの仕事中だったため、最初は眠気が足に来たのかと思いました。 しかし、周りの人も同様に揺れ、ざわめきが起こったので地震と気付きました。 聞くところによると社長室にある何かのガラスケース ? が破損したそうですが、それ以外は携帯電話がつながりにくくなった程度でさしたる被害も無く、どうにか 3 連続の徹夜は回避することができました。

回避はできましたが、その分次の日の仕事に廻してしまったため、また数時間後には出勤しなければなりませんが……。

巡回先のご近所さん、その 1

• Diary - Notes(2005-03-20) - 比較的大きな地震がありましたが

大丈夫です、生きてます。

揺れに驚き起きてみると頭の横を掠めるかたちでEX5が倒れていました。

大丈夫というよりは危機一髪な気が……。

というか、あの時間帯にまだ寝ていたんですか !! 羨ましい……。

私はナチュラルハイで頑張っていたというのに !! エキサイトォォォォォォ !!!! ( 壊 )

巡回先のご近所さん、その 2

• 煤 - Note : 地震きてる(((；゜д゜)))!!

福岡10:50 過ぎから。 でかいのが来た後まだずっと断続的に揺れてるんですが…長怖ぇー。

M7 、震度6 弱(((；゜д゜))) 。 福岡でこんなの滅多に。

滅多に、というか、ほとんど無いんじゃないでしょうか。 ニュースでも 地震空白域 と形容されるくらいですし。

というか、ドメインなどから勝手に北海道の方だと思っていました……。 ご近所さんだったんですね。 ( いや単に同じ県ってだけでは )

トラックバック送信先

• Diary - Notes(2005-03-20) - 比較的大きな地震がありましたが
• 煤 - Note : 地震きてる(((；゜д゜)))!!

そんなにニーズのある話題とは思っていませんでした

ここ最近、 メールアドレスに使える文字や RFC によるメールアドレスの local-part におけるピリオドの取り扱いについての考察に検索などでたどり着く人が多くなったような気がします。

気がしますというか、実際に 1 月 1 日から 3 月 14 日までのログの統計を取ってみると、Google 検索でやってきた人が WWW hxxks 全体のアクセスから hxxk.jp 内のリンクやリファラスパムなどを除いた分の 68.6% を占めており、その検索語句にはほぼ全部と言っていいくらい「メールアドレス」「ピリオド」「 RFC 」といった単語が含まれています。 そして、その次の次に RFCを読まなかった携帯キャリアの罪 - Webビジネスコンサルタントのネタ帳からやってきた人が 2.63% という割合で続きます。

メールアドレス中のピリオドの扱いや、関連する RFC について調べる人ってそんなに多いのでしょうか ?

一応自分でも体験しました

先日、学生時代の後輩…… A 君としましょう。 A 君が、「携帯電話のメールアドレスを変更しました」というメールを私のプロバイダメールアドレスあてに送ってきました。 その時私は外出中だったので、自動転送によって自分の携帯電話あてに届いたメールでその事を知りました。

しかし、どうにも表示されているメールアドレスがおかしい。 @docomo.ne.jp なんてアドレスが愛機 J-SH53 の背面サブディスプレイに表示されています。 この時点では後輩からのメールだとは気付かず、 「 local-part が全く無いアドレスって何だろ ? 番号表示をしない ( 非通知ではなく、そもそも表示をしない ) ワン切りみたいな spam メールかなあ ? 」 なんて思いながらメールを確認しようと携帯電話を開きました。

そこで初めて後輩からのメールであると気付いたのですが、よくよく内容を表示してみると、要するに local-part の最後に "." を配置したメールアドレスだった、という結末だったのです。 身内のメーリングリストに「 A 君からアドレス変更のメールが来たので返信したいんだけど、このアドレスって返信できなくない ? 」と投げてみると、「君の携帯電話からなら、一応返信はできるはず。」との答えが返ってきました。 結局、面倒臭くなって返信は行わなかったのですが……。

その友人の返答が結構早かったので、実はこの問題って認知度が高いのかもしれません。 ( その友人は携帯電話の情報に精通しているので、たまたま知っていただけかもしれませんが。 )

どのキャリアでも RFC に準拠しないアドレスに設定できる ?

ここで、各携帯電話キャリアにおけるメールアドレスの設定について考えてみます。

DoCoMo

• DoCoMo Net - メールアドレスの変更

• 「.」（ピリオド）をアドレス内で連続使用したり、アドレスの最後に設定すると、一部のプロバイダとメールを送受信できない場合があります。
• 先頭文字は英文字にして下さい。

vodafone

• オリジナルメール設定 ヘルプ

• ※ 先頭の文字に数字はご利用いただけません。
• ※ 「.」（ピリオド）をアカウント（@よりも前の部分）の最後に使用することはできません。
• ※ また、アカウント内で連続使用すると、一部のプロバイダとメールを送受信できない場合があります。

au

• KDDI au: EZwebmultiコース > Eメールアドレスの変更方法

• 「. (ピリオド)」の連続使用や最初と最後での使用はできません。

これを総合すると、次の表のようになります。 hxxk.jp と書いている domain 部分は各種携帯電話キャリアのドメインに読み替えてください。

実際に禁則処理を行っているかは分かりませんが、 au はピリオドによって RFC に準拠しないアドレスに設定されることは無いようです。 vodafone は @ の直前への配置を禁じているだけで、連続使用は注意書きだけに留めています。 DoCoMo は注意書きだけで全く禁止していません。

RFC に準拠しないアドレスへの送受信はできる ?

これは RFCを読まなかった携帯キャリアの罪 - Webビジネスコンサルタントのネタ帳のトラックバックから辿って得た情報ですが、当時の現場の方は頭を悩ませたようです。

• falling foo NEWS section | 過剰反応かもしれませんが

もちろん、某社の携帯電話におけるメールシステム開発者はRFCの存在を知っていますし、読んでいます。 だけれども、最大手業者さんにメールが送れないとか受信できないというのはありえない事なんです。

考えるまでもなく、最大手業者さんのユーザ様は非常に多くいらっしゃいます。 その多くのユーザとメールのやりとりができないというのはサービスとして致命的です。

だからと言って、RFC違反をいつまでも放置する事もできませんでした。

そこで私が提案した内容が、「受容のみ」という選択をしたのです。 私のポリシーとして、通信においては「寛容な受信と厳密な送信」が理想的であると思っています。

ですので、「許容するけれども自分のアドレスに設定はできなくした」と記憶しています。

明言はされていませんが、恐らく au の関係者だった方だと思います。 ( DoCoMo ではないのは確実、そして vodafone は設定関連に穴があるため。 )

これを見る限り、最初に最大手業者が RFC に準拠しないアドレスの設定もできる状態でサービスを開始し、他キャリアはそれに歩調を合わせざるを得なくなったのでしょう。 許容するけれども自分のアドレスに設定はできなくした という選択は妥当だと私は思います。

あとは、最大手業者が現在も RFC に準拠しないアドレスを設定できるようになっている状態をどうにかすれば、自然に解決に向かうと思いますし。 現在そういったアドレスを使用しているユーザに変更を促すのは難しいかもしれませんが、これから設定を行う分について禁止することは充分に可能だと思います。

Firefox 1.0.1 日本語版リリース

• Firefox 1.0.1 日本語版リリース - えむもじら

私は日本語版が出てからアップデートしようと思っていたので、これを待っていました。

Firefox 1.0 から 1.0.1 への自動アップデート方法 ( スクリーンショット付 )

2005-03-13T21:48:03+09:00 時点ではまだこの方法は使えません。 Firefox 1.0.2 のアップデートは、一旦旧バージョンのアンインストールが必要にて、 Firefox 1.0.2 へのアップデート方法を紹介していますので、そちらを参照してください。

朝顔日記 - Firefox 1.0 から 1.0.1 へのアップグレードにて自動アップデートとマニュアルアップデートの 2 通りの方法が紹介されていたので、せっかくなら簡単な方を選びました。 のりさん ( 朝顔日記 ) の訳した手順でも充分分かりやすいのですが、より分かりやすいようにスクリーンショットを取り入れてみることにします。

1. まず、アップデートする前に Firefox のすべてのウィンドウやタブを閉じておきます。
2. もしメニューバーの端の方に小さな赤いアイコン（使用しているテーマによっては必ずしも赤くありません）があれば、それをクリックします。 もしアイコンが無いようなら以下の手順を。 デフォルトテーマでは青色の上向き矢印のアイコンでした。 スクリーンショットのサムネイルはオリジナルサイズのスクリーンショットにリンクしていますので、それを参照してください。
   1. ツールメニューから、オプション設定へいって
   2. オプションダイアログの詳細設定を開きます
   3. 画面をスクロールさせて「ソフトウエアの更新」のところにある、今すぐ確認ボタンを押します。 スクリーンショットはこのひとつ前の手順と一緒にまとめています。
3. Firefox 1.0.1(ja-JP)のラベルがついた緊急アップデートのチェックボックスがあるはずです。 2005-03-13T21:48:03+09:00 時点では残念ながらチェックボックスが出現しません。 対応するまで待つか、 朝顔日記 - Firefox 1.0 から 1.0.1 へのアップグレードを参考にマニュアルアップデートを行ってください。
4. 直ちにインストールボタンを押します。
5. インストールが終わるのを待ちます。
6. セットアップウィザードに従い、続けます。

ということで、自動アップデートができるようになっているかをちょくちょくチェックし、対応した段階で速やかにアップデートすること＞自分

いっぱい来ています

今この時点で、今日の WWW hxxks のリンク元は、 Google 検索が 72.1% という高い確率で占有しています。 ( ふだんは 40 〜 50% くらい。この率でも充分高い気はします。 ) そして検索キーワードは

• Google
• キャッシュ
• 文字化け

の 3 つがほとんど。 このキーワードで検索結果のトップに来ているわけでもないのにこれだけビジターが増えるということは、みんな驚いているということでしょうか。

確かに、 hxxk.jp のキャッシュを見ると文字化けしています。

1. 文字化けするキャッシュ
2. 文字化けしないキャッシュ
3. 簡単なまとめ
4. 解決しました

文字化けするキャッシュ

どうも、 charset が Shift_JIS や EUC-JP のページだとキャッシュが文字化けするみたいです。 ( おそらく JIS のページもだと思いますが、それを使用しているサイトをぱっと思い出せませんでした。 )

Shift_JIS

• 闇黒日記のキャッシュ

EUC-JP

• hxxk.jp のキャッシュ

キャッシュのソースを見ると、先頭行に <meta http-equiv="Content-Type" content="text/html; charset=Shift_JIS"> や <meta http-equiv="Content-Type" content="text/html; charset=EUC-JP"> といった記述が挿入されていますが、実際のソースは UTF-8 で記述されているようで、ブラウザの文字コードを UTF-8 に手動で変更すればこれらのキャッシュをちゃんと見ることができます。

文字化けしないキャッシュ

対して、元々 UTF-8 だったページのキャッシュは文字化けしません。

• drry+@->Weblog のキャッシュ

Google キャッシュによって挿入された meta 要素の charset と、本来の meta 要素の charset が同じだからでしょうか。 ( 今日は即席で記事を書いているので、 HTTP ヘッダまでは調べていません。 )

簡単なまとめ

• 元々 UTF-8 だったページのキャッシュは文字化けしない
• 文字化けしてしまっても、ブラウザの文字コードを手動で UTF-8 にすれば大丈夫

正当なコメントもフィルタリングしていた

トラックバックスパムの対策を講じてみたで Quasi-Spam Filter Plugin を導入しましたが、スパムではないコメントもフィルタリングしてしまっていたようです。

659 : e-luck : 2005/03/08 10:35

先日、このエントリーに幾つかSBMのサービスをコメントしたんですが、見事に反映されなかったっす（笑）

データベースを覗いても、それらしきものが残されていなかったため、おそらくフィルタリングの対象になってしまったのでしょう。 e-luck さん ( Lucky bag::blog ) 、申し訳ありませんでした。

何故フィルタリングしてしまったのか ?

これは私が Quasi-Spam Filter Plugin を導入した際に、自分で動作テストを行わなかったことに原因があります。 Quasi-Spam Filter Plugin の機能自体に問題があるわけではありません。

# Set your spam pattern
our $COMMENT_PATTERN = '<h1>|<a\s'; # H1 or A elements

Quasi-Spam Filter Plugin をノンカスタマイズで使用した場合、コメント中に <h1> または <a  という文字列が含まれていると、フィルタリングを行います。 そして、フィルタの動作は コメントが成功した場合と区別が付かないが、裏では削除されている というものになります。

そして、この条件ではスパムではないコメントもフィルタリングに引っかかる可能性が高いのです。 例えば、 e-luck さんが 「カラー液晶の iPod mini は年内に出荷されるみたいですよ」 という、文中にリンクを交えたコメントを投稿しようとした場合、コメント欄に書き込む文字列は <a href="http://www.lucky-bag.com/archives/2005/02/ipod_mini.html">カラー液晶の iPod mini は年内に出荷されるみたい</a>ですよといったものになると思います。

すると、 <a  というフィルタルールによってフィルタリングが行われてしまうわけです。 おそらく、 e-luck さんの当該コメントも、私にソーシャルブックマークサービスを教えて下さろうとしたためにフィルタリングに引っかかってしまったのでしょう。

対策その 1 - Quasi-Spam Filter Plugin をカスタマイズする

正当なコメントに対する意図しないフィルタリングを防ぐ為には、プラグインの記述をカスタマイズするという手段が考えられます。 これは更に 2 つの方法に分かれます。

<a  というフィルタルールを除外する

これは一例ですが、 our $COMMENT_PATTERN = '<h1>|<a\s'; # H1 or A elements という記述を、 our $COMMENT_PATTERN = '<h1>'; # H1 elements とすると、 a 要素によるフィルタリングは行わなくなります。

しかし、多くのコメントスパムが自サイトへのリンクを書き込もうとするために、この対策はスパムフィルタリングとしては現実的ではありません。 ただし、正当なコメントの投稿者が <a href="http://example.com/">hoge</a> 形式の内容を含めることが予想される場合には a 要素のフィルタリングは外した方が良いでしょう。

フィルタリアクションを CommentFilter 以外のものにする

フィルタリアクションのデフォルトは CommentFilter であり、これは コメントが成功した場合と区別が付かないが、裏では削除されている といったものですので、スクリプト等によるコメントスパムには効果的でも、正当なコメントをしてくれる方には「何で反映されないの ? 」という疑問が残ることになります。

そこで、 CommentError などのリアクションにしておくと、スクリプトによる投稿以外にはとりあえず「投稿できなかった」ということを通知できます。 ( ただし、正当なコメントでも投稿が行えないことに変わりはありませんが。 )

対策その 2 - Quasi-Spam Filter Plugin をノンカスタマイズのままで対処する

プラグインのカスタマイズはよく分からない、変にいじって動作しなくなったらどうしよう、という場合はプラグイン以外の場所を工夫することになります。

やはり最も簡単なのは、コメント投稿欄の近くに 「 <a href="http://example.com/">hoge</a> 形式の記述はできません。 URI は自動でリンクアンカーを付与するのでそのままお書きください。」 といった感じの注意書きを書くことでしょうか。 ( 注意 : 自動でリンクアンカーを付与するかどうかは「ウェブログの設定」に依存します。 )

先ほど自分でテストして分かったのですが、ノンカスタマイズの状態では、 「投稿は正常に行われたように見えるが実際には反映されず、また投稿した内容を取り戻すことはできない」 という結果になります。

ノンカスタマイズでフィルタリングを行う場合、注意書き等を明記しておかないと、せっかくコメントをしてくれようとする方の気分を害してしまう可能性がある、ということを覚えておいてください。 ( 私も自戒を込めて覚えておきます。 )

私が取った対策

現時点では、 COMMENT_PATTERN から <a  を除外することで対処としました。

元々コメント中に HTML タグの記述を許可していなかったため、 a 要素が含まれたコメントスパムも ( 消去する手間がありますが ) 実害はありませんでした。 そのため、スパムが投稿されたらその都度文面から特徴的な単語 ( poker とか ) をフィルタリングの対象にするという「後手」の対応を敢えて取ることにしています。 ( もちろん、今後の状況によってはまた変更するかもしれませんが。 )

解決しました

Can't call method "status" without a package or object reference at system directory/lib/MT/Template/Context.pm line 666. で書いていた、記事の保存ができない件ですが、解決したので記録しておこうと思います。

なお、 Movable Type の使用環境として、データベースに MySQL を利用し、その管理には phpMyAdmin 2.5.4 を用いました。 また、 Movable Type のバージョンは 3.151-ja です。

1. 大まかな経緯と原因
2. Context.pm をカスタマイズしてエラーメッセージを分かりやすくする
3. カスタマイズ後のエラーメッセージ
4. 復旧手順
5. まとめ ?

大まかな原因と経緯

大まかな原因としてはデータベースの中におかしなレコードが何らかの原因で存在しており、それによって記事保存時のエラーが発生していました。 そのレコードを削除することで正常に動作するようになりました。

その原因となるレコードのおおよその作成日時も見当がつきましたが、特段おかしなことは無かったと思います。

Context.pm をカスタマイズしてエラーメッセージを分かりやすくする

Movable Type 3.151 の Context.pm の記述では、今回のようなトラブルが起こった場合に、 Can't call method "status" without a package or object reference at system directory/lib/MT/Template/Context.pm line 666. というエラーメッセージが出力されます。

私は perl について不勉強だったので、とぴあさん ( Clovery leaf pieces ) に Context.pm のソースを見ていただいたところ、 MT::Category もしくは MT::Placement あたりが怪しいとのこと。 そこで、 Context.pm の記述に一行書き加えて、以下のようにカスタマイズするよう勧められました。

for my $entry_id (@ids) {
    my $entry = MT::Entry->load($entry_id);
    if (!ref($entry)) { die "illegal entry id $entry_id on placement table"; }
    push @entries, $entry
        if $entry->status == MT::Entry::RELEASE();
}

em 要素で強調した部分が追加行です。

カスタマイズ後のエラーメッセージ

復旧に手一杯でスクリーンショットを取るのを完全に忘れていたのですが、前項のようにカスタマイズした後のエラーメッセージは以下のようになります。

エラーが発生しました:

illegal entry id 566 on placement table at system directory/lib/MT/Template/Context.pm line 666

illegal entry id 566 on placement table というのは、 mt_placement テーブルにおける placement_entry_id フィールドに、何かおかしなレコードが混じっている、といった感じの意味です。 今回のケースは placement_entry_id フィールドの値が 566 であるレコードが変だということになります。

placement_entry_id フィールドの値と、 mt_entry テーブルにおける entry_id フィールドの値が同じレコードは、同一のエントリを指しています。 例えば、 hxxk.jp 全体の現時点での最新エントリは 本日の TBS の番組はほぼ全て放送中止 ? ですが、このエントリは placement_entry_id フィールドの値も entry_id フィールドの値もどちらも 644 となっています。

復旧手順

そして、 illegal entry id 566 と示されたエントリが実際にあるかと言うと……ありません。

正確に言うと、以前下書き状態か何かで作成して、既に削除したエントリなのです。 mt_entry テーブル上にも entry_id : 566 のレコードはありません。 しかし、 mt_placement テーブル上には placement_entry_id : 566 のエントリは残っています。 他のレコードを見る限り、 Movable Type の管理画面から「エントリを削除」で削除したエントリに関するレコードは mt_entry テーブルにも mt_placement テーブルにも残らないはずです。

そこで、次のような手順で該当レコードを削除しました。

1. まずデータベースの dump を取ります。 ( 万一に備えて、データベースをいじくる前の状態を保存するのです。 )
2. Context.pm をカスタマイズしてエラーメッセージを分かりやすくするを参考に、 Context.pm の記述をカスタマイズし、サーバに put します。
3. Movable Type の管理画面から、エラーとなる記事の保存を再度行います。
   1. エラーメッセージが出力されるので、その entry_id をメモします。
   2. phpMyAdmin にて、 mt_entry テーブルの entry_id フィールド上に、その id を持つレコードが無いことを確認。
   3. phpMyAdmin にて、 mt_placement テーブルの placement_entry_id フィールド上で、その id を持つレコードを消去。 ( なお、複数のカテゴリを指定したエントリの場合、カテゴリ数の分だけ同じ placement_entry_id の値を持つレコードが存在するので、消去漏れが無いように注意して下さい。 )
4. 再度 Movable Type の管理画面から、エラーとなる記事の保存を行います。
   • 場合によっては違う entry_id でエラーメッセージが再度表示されるので、その場合は「エラーメッセージが出力されるので、その entry_id をメモします」の手順から繰り返します。
   • 記事の保存を行ってエラーが出なければ復旧完了です。

まとめ ?

結局のところ、「どういったエラーが原因で保存ができなくなっているか」は分かりましたけど、「何故このエラーが発生したのか」は分からず仕舞い。 あくまで想像ですが、「管理画面からエントリを削除した際に、何らかの原因で mt_placement テーブルに削除したはずのレコードが残ってしまった」という感じだと私は思います。 その残骸レコードを消すとエラーは無くなったわけですし。

最後に、 IRC で丁寧にエラーを探って下さったとぴあさん ( Clovery leaf pieces ) に感謝の意を込めつつ記事を締めくくろうと思います。

記事保存時のエラー

今回が初めてではなかったのですが、記事を保存する際にエラーが出ることが時々ありました。 Can't call method "status" without a package or object reference at system directory/lib/MT/Template/Context.pm line 666. というメッセージで、 system directory は Movable Type のシステムを置いているディレクトリです。

発生条件

• 最初にこのエラーが出たのがいつだったか覚えていないのではっきりとは言えませんが、 Movable Type 3.15-ja および Movable Type 3.151-ja にて発生するようです。 Movable Type 3.11 時代に発生していたかどうかはよく覚えていません。
• 記事の主カテゴリに、「子カテゴリを持つカテゴリ」を設定すると発生し、記事の保存ができません。
  • ただし、主カテゴリを「子カテゴリを持たないカテゴリ」にして一旦保存すると記事が保存できます。その後に「複数のカテゴリーを設定する」で副カテゴリに「子カテゴリを持つカテゴリ」を設定すると、エラーにはなりますがそのカテゴリも設定された状態で保存できます。
  • 「子カテゴリを持つカテゴリ」のみを設定したい場合、まず適当に「子カテゴリを持たないカテゴリ」を主カテゴリに設定してから、本来設定したいカテゴリを副カテゴリに設定し、主カテゴリの設定を外すという手順を踏まないと保存できません。
• このエラーが発生する状態で再構築を行うと、カテゴリアーカイブの再構築にて同じエラーが発生します。
• MT hxxks でのみ発生します。
  • 全部の weblog を試したわけではありませんが、 Weblog hxxks や WWW hxxks では発生しません。「子カテゴリを持つカテゴリ」のみを設定しても問題なく保存できます。

エラー箇所付近のソース

# push @entries, $entry の行が問題の箇所

my $is_and = $cat_name =~ /AND/;
my $count = @cats;
my @ids = $is_and ? grep { $entries{$_} == $count } keys %entries :
                    keys %entries;
$saved_entry_stash = $ctx->stash('entries') || [];
if (@$saved_entry_stash) {
    my %temp = map { $_ => 1 } @ids;
    @entries = grep { $temp{$_->id} } @$saved_entry_stash;
} else {
    for my $entry_id (@ids) {
        my $entry = MT::Entry->load($entry_id);
        push @entries, $entry
            if $entry->status == MT::Entry::RELEASE();
    }
}

私の想像

perl の構文は全く分からないので、 Context.pm の記述が正しいのか間違っているのか分かりません。 しかし、同様の事例を検索しても、 Movable Type における例が見つからないことや、 MT hxxks でのみ発生し、同じ Context.pm を使用しているはずの Weblog hxxks や WWW hxxks では発生しないため、 Context.pm 自体には問題は無いと思います。

発生条件で書いた通り、記事の保存時のみならずカテゴリアーカイブの再構築時にもエラーが出るようです。 記事を保存した場合は、同時にインデックステンプレートや関係する日別アーカイブ、カテゴリアーカイブ、個別アーカイブの再構築を自動で行っているため、「カテゴリアーカイブに関するエラーが記事保存時にも発生している」と見る方が自然かもしれません。

となると、カテゴリアーカイブのテンプレートの記述か、カテゴリの設定自体がおかしいのだろうと思いますが、テンプレートの記述は MT hxxks も Weblog hxxks も WWW hxxks もほとんど変わりません。 カテゴリ名などに何か不備があったのでしょうか…… ?

Re: http://hxxk.jp/2004/10/25/0004#c651

実は概要のところを旅行記のテンプレートでその日の観光ポイントを入れる場所にでもと思っていたのですが、こちらの投稿を読むと邪道と言われそうですね。 観光ポイントなので概要といえないことはないのですが厳密に言うと違う。

邪道でしょうか ? 旅行記であるならば、観光ポイントを概要欄に書くというのは理に適っていると思いますが。

概要 ( excerpt ) の重要性で述べていることは「トラックバックを送信する際の概要」に注目しているので、 stanaka さんの仰る旅行記の各記事の概要とは少し性質が違うかもしれません。 Movable Type の場合、概要欄が空白であれば本文の先頭から生成するため、逆に毎回本文の先頭に概要を書くという手法も考えられます。

あの記事では、「正しい概要とは」を論じるというよりは「概要を書いていないと色々とマイナスですよ」といったことを述べたつもりでしたので、「概要を書くことによるプラス面」は得られにくかったかもしれません。

概要を書くことによりアクセスアップ ?

概要を書くことによりアクセスアップにつながるとかそのようなことが仕掛けとしてあれはばいいのでしょうが。

例えば、テンプレートの head 要素内に <meta name="description" content="<$MTEntryExcerpt$>" /> と記述するようにすると、アクセスアップにつながるのかもしれません。 ( meta 要素に description を書くことがどれくらいの効果があるのか知りませんが。 )

概要を利用したテンプレート

もしくは、アクセスアップや RSS リーダのためといったような裏方 (?) 的なことではなく、もっと目立つところで概要を活躍させるという手法もあります。

たとえば、旅行記のサイトであるなら、以下のようなテンプレートなどいかがでしょうか。

<MTEntries>
  <ol>
    <li>
    <a href="<$MTEntryLink$>"><img src="<$MTEntryDate format="%Y%m%D%H%M"$>_thumb.jpg" width="320" height="240" alt="<$MTEntryTitle$>のベスト写真" /><$MTEntryExcerpt$></a>
    </li>
  </ol>
</MTEntries>

インデックステンプレートにこういった感じで記述し、記事の投稿日時を元に名付けた旅行写真をアップロードすれば、各記事の写真と、概要から生成されたキャプションを活用した写真アルバムのようなインデックスページを作ることができるでしょう。

デフォルトテンプレートのままだとその恩恵はなかなか感じにくいですが、テンプレートをカスタマイズして概要をどんどん活用すれば、より多くのアイデアが生まれるかもしれません。

関連リソース

• 概要 ( excerpt ) の重要性
• 概要 ( excerpt ) は有効活用されていない ?

OCN からお知らせが来ました

以前、 日本テレコムによる悪徳商法まがい行為 - NTT の ADSL が使用不可能ににて書いた通り、日本テレコムの直収電話サービスであるおとくラインを申し込むと、 NTT の ADSL サービスは利用できなくなります。 そのことに関して、私が利用しているプロバイダである OCN からお知らせが届きました。

【必ずお読みください】OCNサービスに関する重要なお知らせ

OCN ADSL「フレッツ」をお使いのお客さまへ

平素は、OCNをご利用いただき、誠にありがとうございます。

現在OCNサービスをお使いのお客さまが、KDDIの「メタルプラス」、日本テレコムの「おとくライン」および平成電電の「CHOKKA」など（=以下「直収電話サービス」）に変更されますと、下記のような影響が生じる場合がございます。 直収電話サービスへの切り替えをご検討のお客さまは、事前に「カスタマーズフロント」までお問い合わせください。

OCNサービスに生じる影響点

• 「フレッツ・ADSL」（電話共用型（タイプ1））がご利用できなくなることにより、OCNのADSL接続サービスおよびIP電話（OCNドットフォン等）は、ご利用できなくなってしまいます。
• マイライン・マイラインプラスは、自動的に解約されます。 それにより、OCNの「マイラインセット割引」をご利用されているお客さまは割引料金適用外となってしまいます。
• 今までご利用可能であったOCNのダイヤルアクセス（ダイヤルアップ接続）がご利用できなくなってしまう場合があります。

本件については以下のホームページに掲載しておりますのでご確認下さい。http://www.ocn.ne.jp/personal/support/dc/?mfa

本メールは、2005年2月中旬時点の情報に基づき、配信させていただいております。 直収電話サービスへの変更はOCNの多くのプランに影響がありますので、既にプラン変更等のお申し込みをされたお客さまは、ホームページで該当プランの影響点をご確認ください。

今後とも変わらぬご愛顧を賜わりますよう、お願い申し上げます。

私はフレッツ ADSL ユーザなので、 OCN ADSL「フレッツ」をご利用のお客さまにて確認。 直収電話サービスに変更されますと、「フレッツ・ADSL」（電話共用型（タイプ1））が利用できなくなることにより、OCNのADSL接続サービスおよびIP電話（OCNドットフォン等）は、ご利用いただけなくなります とのことです。

OCN 側が他社の直収電話サービスの営業状況をどれだけ把握していたかにもよると思いますが、少々お知らせが遅かったと私は思いました。 既に申し込んだ方も大勢いらっしゃるのではないでしょうか ? 直収電話サービスを行う側が、申し込みに伴って利用不可となる点をきちんと事前説明をしていれば、問題は無いのかもしれませんが。

日本テレコム側の告知

おとくライン 重要事項 - （2）お申込みにあたっての注意事項に書かれています。

「おとくライン」とADSLを同じ電話回線でのご利用ご提供は、2005年3月よりYahoo！BBが開始となる予定です。 その他の事業者については、順次ご提供を開始いたします。 「おとくライン」お申込み後、開通手順や提供エリア等によりご利用可能になるまでお待ちいただく場合がございます。

• ※ ADSLを継続してご利用の場合、番号ポータビリティでのご利用が必要です。 番号ポータビリティでない場合はADSL継続利用のお申込みはできませんので、ご注意ください。
• ※ ADSLと同じ電話回線でご利用をご希望の場合、ISDN回線ではご利用になれません。
• ※ お客様がご利用中のADSL接続サービスが「おとくライン」に対応していない場合、「おとくライン」でADSLをご利用になることはできません。
• ※ ご利用のADSL接続サービスの「おとくライン」対応有無等の詳細は、事前に必ず各接続プロバイダまでお問合せください。
• ※ 受付した「おとくライン」ご契約回線が、Yahoo! BBのADSLサービスをご利用中であるかの確認を行う場合があります。 あらかじめご了承ください。
• ※ 「おとくライン」にお申込みいただいたNTT東日本・NTT西日本のご契約回線が、ADSLサービスをご利用中であるかについて、弊社が代行してNTT東日本・NTT西日本に確認を行う場合がございます。 確認の結果、ADSLサービスをご利用中のお客様には、ADSLサービスの提供開始時期まで、「おとくライン」の申請手続きについて保留とさせていただく等の旨、別途確認のご連絡をいたします。 あらかじめご了承ください。
• ※ 「おとくライン」とADSLを同じ電話回線でご利用の場合､「おとくライン」解約時は、ADSLも解約されます。 ADSLを解約する場合は、ご利用の接続プロバイダまでお問合せください。

ADSL 利用者であった場合、利用可能になる時期まで申請手続きを保留にするといった措置が取られるようになったようです。 日本テレコムによる悪徳商法まがい行為 - NTT の ADSL が使用不可能にの時は使えなくなると説明があっただけだったので、多少の改善が見られます。

KDDI 側の告知

KDDI メタルプラス - お申し込み上の注意に書かれています。

• メタルプラス電話をお申込みの回線では他社の提供するADSLサービス（現DION-ADSLを含む）を利用することは、現状できません。

• メタルプラス電話にご加入の際、NTT東日本・NTT西日本の加入電話は解約または休止となります。
  • ※ NTT東日本・NTT西日本からの切替の場合はKDDIが代行して解約または休止手続きをさせていただきます。
  • ※ NTT東日本・NTT西日本の加入電話を解約された場合は、NTT東日本・NTT西日本等への再加入時に施設負担金等が必要となります。

ADSL 利用者であった場合、利用不可になるという説明はあります。

平成電電側の告知

CHOKKA ADSL（でんわ石火） - ADSL サービスに書かれています。

Q. 今、他社のADSLを利用していますが、CHOKKAに加入した場合引き続き利用できますか？

CHOKKAでは「電光石火」以外のADSLサービスのご利用はできません。 誠に申し訳ございませんが現在お使いのサービスを解約し、「でんわ石火」へお申込みください。

※ 現在ご利用になっている、平成電電提供以外のISP（インターネットサービスプロバイダ）[例：OCN・BIGLOBE 等]は、CHOKKA切り換え後はご利用できません。 グローバルIPアドレスは弊社からの付与となります。 ただしプロバイダによっては、でんわ石火（電光石火）を使ってメールサービスなどがご利用可能なケースもございます。 ご契約されているプロバイダ事業者様に、他ネットワークからのご利用可能なサービスについてご相談ください。

Q&A 形式で分かりやすく書いています。

結局のところ

分かりやすさや取り扱いの大きさに差異はあるものの、 NTT 側も直収電話サービス側も一応のアナウンスは行っています。

ユーザ側も申し込みを行う前に、申し込みによって現在の通信環境がどう変わるかをよく考えた上で申し込むべきでしょう、とありきたりなことを言いつつ NTT の ADSL と直収電話サービスにおけるメモを終了します。