2004-09 アーカイブ

http://hxxk.jp/2004/09/

Another HTML-lint と text/html と Movable Type

記事データ

投稿者

望月真琴

投稿日時

2004-09-28T21:12+09:00

タグ
概要

Another HTML-lint gateway が頑としてこれに OK サインを出さないと書かれているのを読んで、そこまで気にするエラーじゃないですよ、と思いつつ一応の解決方法をそっと教えてみる次第。Another HTML-lint と text/html と XHTML 1.1 で紹介した判別コードを Movable Type のテンプレートに組み込む方法。

リプライ

4 件のリプライがあります。

記事本文

Movable Type において、 IE にのみ text/html を指定する

Another HTML-lint と text/html と XHTML 1.1 - IE にのみ text/html を指定するで書いたコードを Movable Type のテンプレートに組み込む場合はどうすればいいのか。 これは PHP を用いた UA 判別ですので、 Movable Type を設置しているサーバに PHP がインストールされている必要があります。

テンプレート内に直接記述

判別部分のコードをテンプレートの先頭 ( XML 宣言や DOCTYPE 宣言よりも前 ) に書けばいいので、テンプレートの記述は以下のようになります。 なお、この例は文字コードを EUC-JP とし、 DOCTYPE 宣言を XHTML 1.0 Strict として記述しています。

<?php 

$accept = $_SERVER['HTTP_ACCEPT']; 
$ua = $_SERVER['HTTP_USER_AGENT']; 

if (eregi("Opera", $UA)) { 
  header ("Content-Type: application/xhtml+xml; charset=EUC-JP"); 
}  elseif (eregi("Another_HTML-lint", $_SERVER['HTTP_USER_AGENT'])) { 
  header ("Content-type: application/xhtml+xml; charset=EUC-JP"); 
} elseif (ereg("application/xhtml\+xml",$accept)) { 
  header ("Content-Type: application/xhtml+xml; charset=EUC-JP"); 
} else { 
  header ("Content-Type: text/html; charset=EUC-JP"); 
} 

?>

<?php echo '<?xml version="1.0" encoding="<$MTPublishCharset$>"?>'."\n"; ?>

<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">

( 以下省略 )

別ファイルに書き出してテンプレートから include

判別部分のコードの記述は、テンプレートの種類には全く関係がありません。 すなわち、 RSS などを除いた全テンプレートで共通の記述となります。 よって、判別部分のコードのみを記述したファイルをサーバに put しておき、 include で呼び出すようにすれば、ソースの簡略化が図れます。

この例では、判別部分のコードを ua.inc というファイルに記述し、ローカル・サイト・パス 直下に put したとして記述しています。

<?php include_once("<$MTBlogSitePath$>ua.inc");?>
<?php echo '<?xml version="1.0" encoding="<$MTPublishCharset$>"?>'."\n"; ?>

<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">

( 以下省略 )

実際に生成される XHTML ソース

前項の例を用いたテンプレートで作られた記事の XHTML ソースを見ても、成功しているかどうかは確認できません。 HTTP ヘッダとして Media Type や Charset を送っていますので、実際のソース中には何も現れないからです。

これを確認するためには、 View HTTP Request and Response Header などのサービスを使うと良いでしょう。 ( ただし、このサービスで使われる UA である Web-Sniffer は、今回の判別コードでは考慮されていないため、 text/html として送出されます。 ) また、 Another HTML-lint と text/html と XHTML 1.1 - Another HTML-lint の小技で紹介している方法で確認するのも良いでしょう。

Another HTML-lint に拘りすぎないように

この方法は、 Another HTML-lint に対して、決め打ちで application/xhtml+xml として送出するようにするという方法なので、必ず行わなければならないというものではありません。 XHTML 1.0 を宣言している場合は text/html でも Another HTML-lint と text/html と XHTML 1.1 - XHTML 1.1 において、 text/html で Another HTML-lint による検証を行うで述べたようなエラーは出力されませんし。

XHTML 1.1 を宣言した文書は、 application/xhtml+xml として送出することが Should であると XHTML Media Types では述べられています。 しかし一部の未対応 UA に配慮して、 Should not と自覚しながら text/html として送出する際に、 Another HTML-lint ではエラーとして取り扱われる。 ならば text/html という妥協 ( この表現は適切でないかもしれません ) を行った時点で、このエラーが出力されることは致し方ないものとして捉えても良いのではないでしょうか。

404 : Another HTML-Lint の挙動に困惑にて Another HTML-lint gateway が頑としてこれに OK サインを出さない と書かれているのを読んで、そこまで気にするエラーじゃないですよ、と思いつつ一応の解決方法をそっと教えてみる次第。

トラックバック送信先

リプライ

4 件のリプライが送られています。 この記事に対するご意見やご質問、ご感想などありましたら個別記事ページの送信フォームからお送り下さい。

2004-09-28T23:30+09:00 - イソムラ

実際にIEとMozilla、Operaで確認したときには問題なく閲覧ができたので気にすることもなかったのですが、ふと思い立ってAHLのチェックにかけてみたところ「減点」と断定されて躍起になったりしていました。別に減点されて困ることもないのですが(実際閲覧できてるわけだし)。 というわけで、お教え頂いたのとほぼ同じ記述(http://bluestar.s32.xrea.com/text/php3.php)でPHPでの振り分けにも手を出したりしていたのですが、サーバで何か設定がしてあるのか(この辺りは全然知識が足りていないので判断しかねるのですが)header関数の記述された行にエラーが出るため実装不可能でした。じゃどうしてエラーが出るのか?というところは本当に基礎知識なく判断できない、ということで一からPHPの勉強をしてみることにしました。 長々と近況報告みたいになってしまいました、スミマセン。

2004-09-30T01:27+09:00 - 真琴

なるほど、てっきり HTTP ヘッダをどう送信するかという時点で躓いているのだと思いました。http://php.s3.to/man/function.header.html によると、「HTTPヘッダが既に送信されていない限り、 header()をコールすることでステータスは常に上書きされます。」とのことなので、これを逆に考えると「HTTPヘッダが既に送信されてると、 header()をコールしてもステータスは上書きされない。」ということになりますね。 headers_sent 関数 ( http://php.s3.to/man/function.headers-sent.html ) で HTTP ヘッダの送信状態を調べることはできますが、その解説にも「ヘッダーブロックが一旦送信されてしまった後でheader()関数を使って新たなヘッダ行を送信することはできません。」と書いてあるだけで、解決方法は書いてありませんし。 おそらく、イソムラさんも同様のリソースにたどり着いたのではないでしょうか。「対策方法はわかったけれども対応できない」と書かれてあったので……。 私もこのあたりの事は不勉強で、躓いては場当たり的に調べて解決、といった事しか行っていないので、知識が足りていません。お役に立てなくて申し訳ありません。

2004-09-30T02:29+09:00 - 真琴

「header関数の記述された行にエラーが出る」というのは、「Warning: Cannot modify header information - headers already sent by...」といったエラーでしょうか。 某氏に尋ねてみたところ、 ob_start(); 〜 ob_end_flush(); でバッファリングを行うと良いのでは、というアドバイスをいただき、またサンプルコードを書いていだたきました。 バッファリングなし : http://hxxk.jp/temp/20040930_01.php バッファリングあり : http://hxxk.jp/temp/20040930_02.php xrea の場合はサーバの設定により (?) 、どちらも 最後の header が出力されますが、同様のコードをイソムラさんのサーバに put して IE でリクエストすると、 20040930_01.php の方はダウンロードになり、 20040930_02.php の方はブラウザ上で表示されるはずです。

2004-10-01T23:09+09:00 - PHP の header 関数であれやこれやの続き < 404

結局まだ先へ進めていない PHP 化。

Another HTML-lint と text/html と XHTML 1.1

記事データ

投稿者

望月真琴

投稿日時

2004-09-28T02:48+09:00

タグ
概要

PHP を用いて、 application/xhtml+xml として XHTML 文書を送出しつつ IE には text/html を送出する方法。同様に、 Another HTML-lint の XHTML 1.1 検証におけるエラーについて解説。

リプライ

リプライはまだありません。

記事本文

XHTML 1.1 において、 text/html で Another HTML-lint による検証を行う

DOCTYPE 宣言において XHTML 1.1 を宣言していて、かつ meta 要素内で <meta http-equiv="Content-Type" content="text/html; charset=EUC-JP" /> といった記述を行っている場合、 Another HTML-lint gateway ではエラーとして扱われます。

hxxk.jp は XHTML 1.0 Strict を宣言しており、更にこの辺りにあれこれ手を加えているので、このエラーは生じていません。 なので、ぱっと頭に思い浮かんだサイトを勝手に検証してエラーを再現させてもらいました。

http://mushline.com/junky/ を XHTML1.1 としてチェックしました。 14個のエラーがありました。このHTMLは 99点です。タグが 41種類 590組使われています。文字コードは UTF-8 のようです。

先頭の数字はエラーのおおまかな重要度を 0〜9 で示しています(減点数ではありません)。 少ない数字は軽く、9 になるほど致命的です。0 は減点対象外のごく軽度のエラーで (グレイのかっこつき) でメッセージされています。

  • 1: line 5: <meta> に指定されているメディアタイプ text/html は XHTML1.1 には指定しないようにしましょう。 → 解説 143
  • 1: line 554: HTTPレスポンスヘッダに指定されているメディアタイプ text/html は XHTML1.1 には指定しないようにしましょう。 → 解説 143

Should not? Must not?

なぜこのようなエラーを出力するのか。 おそらく W3C Note の記述を根拠にしているのだと思われます。

Note that a meta http-equiv statement will not be recognized by XML processors, and authors SHOULD NOT include such a statement in an XHTML document served as 'application/xml' (and 'application/xhtml+xml' as well for that matter).

なお、XML プロセサは meta http-equiv による指定を解釈しないこと、そのため制作者は application/xml として提供される XHTML 文書にそのような指定を記述すべきでないことも記しておく。 これは application/xhtml+xml についても同様である。

この記述を元に、 1: line 5: <meta> に指定されているメディアタイプ text/html は XHTML1.1 には指定しないようにしましょう。 → 解説 143 というエラー項目を作成しているのだと私は想像しました。

これはあくまで Note であり、 This document is a Note made available by the World Wide Web Consortium (W3C) for your information. Publication of this Note by W3C indicates no endorsement by W3C or the W3C Team, or any W3C Members. と冒頭で書かれてあるとおり、参考情報に過ぎません。 ( W3C勧告プロセスの概要 - W3C Notes / Working Group Notes )

そして、 記述すべきでない という表現は Should not であり、してはならないということではないのです。 ( XHTML Media Types - 2. Terms and Definitions )

XHTML Media Types - 3.5. Summary によると、 meta http-equiv による指定のみならず、 Media Type 自体についても XHTML 1.1 における text/html は Should not であると書かれています。

よって、減点対象のエラーとする必要はないのかもしれませんが、そこは作者である石野 恵一郎さんなりの判断基準があるのでしょう。

何故 text/html にこだわるのか

XHTML 1.1 において、 text/html が Should not で、 application/xhtml+xml が Should であるなら、 application/xhtml+xml を指定すればいいのです。 しかし、実際は text/html としているところがほとんどです。

依然ブラウザのシェアの大部分を占める IE が application/xhtml+xml に対応しておらず、 application/xhtml+xml が指定された XHTML 文書を表示できないということが理由として挙げられます。 実装に妥協して text/html を指定することの是非はここでは論じませんが、こういった現状のブラウザ事情への配慮の結果だと私は思います。

IE にのみ text/html を指定する

私は閑古鳥 -> 呟き -> Content-Typeを振り分けるいくつかの方法のコードをそのまま用いて、 application/xhtml+xml に対応している UA には application/xhtml+xml を、そうでない UA には text/html を送出するようにしています。

閑古鳥 -> 呟き -> Content-Typeを振り分けるいくつかの方法では目的に応じたコードがそれぞれ書かれてあり、また追記等もあってコード全体が書かれていないため、勝手にまとめたコードをここに記述しておきます。

<?php

$accept = $_SERVER['HTTP_ACCEPT'];
$ua = $_SERVER['HTTP_USER_AGENT'];

if (eregi("Opera", $UA)) {
  header ("Content-Type: application/xhtml+xml; charset=EUC-JP");
}  elseif (eregi("Another_HTML-lint", $_SERVER['HTTP_USER_AGENT'])) {
  header ("Content-type: application/xhtml+xml; charset=EUC-JP");
} elseif (ereg("application/xhtml\+xml",$accept)) {
  header ("Content-Type: application/xhtml+xml; charset=EUC-JP");
} else {
  header ("Content-Type: text/html; charset=EUC-JP");
}

?>

これをそのまま PHP ファイルの先頭に記述するなり、このコードだけを別ファイルに保存して PHP ファイルの先頭にて include するなりすれば、 UA の対応状況に応じた HTTP ヘッダが送出されます。

Another HTML-lint と text/html と Movable Type にて Movable Type でのテンプレートへのコード記述方法を書きました。 Movable Type ユーザーの方は合わせてお読みください。

Another HTML-lint の小技

Another HTML-lint : How to use htmllint.cgi - 問い合わせ変数一覧に書いてありますが、 HTTP ヘッダがどのように送られているかを調べることができます。 HTTPHeader という変数に on を代入すればいいのです。

たとえば、 hxxk.jp のトップページの検証を行い、かつソースの表示および HTTP ヘッダの表示を行いたい場合、 http://openlab.ring.gr.jp/k16/htmllint/htmllint.cgi?URL=http://hxxk.jp/;ViewSource=on;HTTPHeader=on という URI をリクエストすると、前述の条件で検証結果を返してくれます。

Another HTML-lint gateway にて、 URL指定のときHTTPレスポンスヘッダを表示します。 にチェックを入れても同様のことが行えますが、上記の方法は検証結果に直接リンクできるので、記事などの中で用いるときに便利かもしれません。

リプライ

リプライはまだ送られていないか、管理者の承認待ち状態です。 この記事に対するご意見やご質問、ご感想などありましたら個別記事ページの送信フォームからお送り下さい。

Tour "Shake hands" - 005

記事データ

投稿者

望月真琴

投稿日時

2004-09-27T21:00+09:00

タグ
概要

Tour "Shake hands" の各人のレポートのまとめ。

リプライ

リプライはまだありません。

記事本文

リプライ

リプライはまだ送られていないか、管理者の承認待ち状態です。 この記事に対するご意見やご質問、ご感想などありましたら個別記事ページの送信フォームからお送り下さい。

Tour "Shake hands" - 004

記事データ

投稿者

望月真琴

投稿日時

2004-09-27T20:00+09:00

タグ
概要

Tour "Shake hands" 3 日目、水木しげるロードレポート。

リプライ

リプライはまだありません。

記事本文

Tour "Shake hands" - 9 月 26 日 - GOOD-BYE

さすがは 3,800 円。 昨日に比べるとやはりそれなりのベッドだということをぼんやりと考えながら目を覚まし、酔い覚ましを兼ねてシャワーを浴びると、約束の時間の 9:00 がだいぶ迫ってきていました。 草原さんが準備を済ませて待っているといけないので、電話をしてみることに。 ……やはり眠そうな声で返事が返ってきました。 私も多少寝坊気味だし、今日は帰路に着くだけなのでチェックアウトの時間を遅らせることに決定。

ロビーで草原さんを待っているときに FUMING さんから「バスに乗りました」とのメールが。 そういえば昨日は眠りこけてしまったので結局お別れの挨拶をしてなかったなあ……。

Tour "Shake hands" - 9 月 26 日 - WILD ROAD

軽めの朝食をミスタードーナツで摂り、向かうは鳥取県境港市。 ここは一部界隈では有名な地で、島根方面に行くと決めたときからここに行こうと決めていました。 道中の会話で、ここを知るきっかけになったものを 2 人とも目にしていたことが判明。 それなら話は早い。

目的地に到着し、徒歩で向かうは水木しげる記念館。 水木しげるの生い立ちや多種多様の妖怪の展示など、ファンにはたまらない構成になっていました。 以前ここに来ようとして、時間の関係で行くことが適わなかった友人のためにパンフレットをお土産として購入。 そして記念館を後にして水木ロードへ向かおうとした時に、急に目の前に現れるねずみ男。 「うわ !! 」と素で声を挙げてしまいました。

水木ロードはそこかしこに妖怪のブロンズ像が作ってあったり、市民が制作したオブジェの優秀作品が飾られていたりで、ただ歩くだけでも楽しいものでした。 しばらくのんびりと歩いていると、さっきのねずみ男が前を歩いているのを発見。 どうやらロード内をゆっくりと往復し、写真撮影に応じているようです。 これを逃すわけにはいかぬ、ということで草原さんにカメラを託し、写真撮影をお願いしてツーショットを撮ってもらった後、「草原さんもどうですか」と言うと、「いや、僕は……」と尻込みをする草原さん。 そして「遠慮すんなよ兄ちゃん」とばかりに手招きをするねずみ男。 こんなフレンドリーなキャラじゃない気もするんですけど、ねずみ男って。 よく見ると鬼太郎も歩いているわ、目玉のおやじが人力車 ( 無料 ) を引いているわ、なんというかサービス精神旺盛な観光スポットでした。

Tour "Shake hands" - 9 月 26 日 - Baby, you're my home

以上で観光は終わりだけれど、せっかくだからのんびり帰ろうか、ということで国道を西進しながら帰ることに。 それならばということで、途中で出雲市内に入って割子そばを食す。 美味しい。 そしてずっと国道を通って行き、山口 IC で高速に乗ろうと思ったのですが、山口 IC 付近のマクドナルドの屋根にでっかいドナルドがいたのにビックリし、そしてうっかり高速入口をスルーしてしまいました。 ドナルドの野郎……。 ( 違 )

高速に乗ってからは特筆すべきことも無く、無事福岡入り。 締めはやっぱりラーメンだろう !! という流れでとらやというラーメン屋にて夕食。 ついつい豚骨バターという響きに惹かれてしまっておなかいっぱいに……。

そして草原さんを家に送り届けて、今回のツアー "Shake hands" は全行程を終了。 るりさんは「家に帰るまでが遠足」だと言っていたみたいですけれど……。 皆様、お疲れ様でした。 唐突かつ適当すぎる発案にも関わらず、多くの人にお会いすることができて楽しかったです。 また福岡にお越しの際はお知らせください。 ばっちりと案内を務めます !!

草原さんが ( おい )

リプライ

リプライはまだ送られていないか、管理者の承認待ち状態です。 この記事に対するご意見やご質問、ご感想などありましたら個別記事ページの送信フォームからお送り下さい。

Tour "Shake hands" - 003

記事データ

投稿者

望月真琴

投稿日時

2004-09-27T19:00+09:00

タグ
概要

Tour "Shake hands" 2 日目、大山〜すまねレポート。

リプライ

リプライはまだありません。

記事本文

Tour "Shake hands" - 9 月 25 日 - in the shape of wing

さすがは全日空ホテル。 ベッドの心地よさは自宅のそれとは大違い。 このまま惰眠を貪りたい衝動を何とかはねのけ、まだ微かに残る酔いを覚ます為にシャワーを浴び、約束の 8:30 に朝食場所へ赴くと、 FUMING さんが程なくして姿を現しました。 ……で、草原さんは ?

電話をかけてみると、昨日のハキハキとした喋りではなく、眠さの残る声で「おはようございますー……」と言われました。 なにやら一度は目が覚めたけど二度寝をしてしまったとのこと。 焦らずに準備しておいでー、と告げて FUMING さんと二人で先に朝食。 ビュッフェ形式だったので、ここぞとばかりに食べる食べる。 ごはんがちょうど切れてたのでパンを食べていたのに、後から見たらごはんが追加されていたのでごはんも食す。 以前泊まりの出張で、ベッドにすら辿り着けない泥酔状態になった翌朝も、二日酔い状態でごはんをおかわりしたという逸話を残したほどよく食べるキャラなので、別に不思議なことではありませんが。

9:30 にホテルをチェックアウトし、既に伊丹空港で合流を済ませているかっぱさんとるりさんを追いかける形で出発。 昨日見た「夜の大阪」とはまた違う表情を見せてくれた「朝の大阪」は、渋滞も無くスムーズに走れたのですけれど、 4 車線もある一方通行には最後まで慣れませんでした。 以前札幌に行った時も同じ印象を抱いたのですが、こればかりは頻繁に通らない限りは慣れないでしょう。

西宮 SA で落ち合うことにしていたので、 SA が近づいたところで草原さんにもうすぐ着く旨を電話してもらうと、「すぐ行くから待ってて」とのこと。 あれ、先に行っていたんじゃないんですか ?

どうやら、合流した時点で私たちがまだチェックアウトしていなかったため、滑走路付近で飛行機を眺めることにしたのだそうで。 実際に待ったのは 15 分くらいでしょうか、それほど長くはない待ち時間を経てかっぱ号も SA に到着。 そしてみんなでルート会議。 道中はるりさんと FUMING さんを各々の車に交代で乗せながら、一路すまね ( 島根の意 ) へ。 勝央 SA の昼食にて草原さんと FUMING さんが「せっかくだから俺はこの赤の方を選ぶぜ !! 」とばかりにセレクトした激辛ラーメン ( ハバネロ入り ) に私はビックリ。 ( ←辛いのダメな人 )

高速を降りた後、一度車を停めて景色を眺めたり写真を撮ったりしました。 るりさんがにこにこしながら私を撮るので尋ねてみると、「同じカメラで景色を撮っている図を撮った」とのこと。 そう、私とるりさんのカメラは同じ DiMAGE G400 なんですねー。 ( 何故か自慢げ) かっぱさんはご自慢のスチールカメラを取り出して本格的に撮影。 なんでも本格的に写真を撮るためには、機材などにかなりお金がかかるそう。 私はちょっとしたモノをデジカメで撮るだけだなあ……。

Tour "Shake hands" - 9 月 25 日 - We shake hands with her.

道中、予想よりも少し時間が押してきたので、一旦アサノさんと連絡を取る事に。 #順列都市で鳴らした俺達の連絡方法は勿論 IRC で !! ( 激しく間違っています ) 山中なので Air H" の電波も悪く、最終的には電話で直接話したのですが。 予定では松江駅まで行っていったんホテルにチェックイン、そしてるりさんとアサノさんが握手を交わした後るりさんとかっぱさんはそれぞれ帰宅、そしてすまねオフという流れだったのですけれど、時間的要因などの理由でアサノ塗装店へ直行することに変更。 ……大まかな場所は分かったので近くまで行くも、最後の細かいところが分かりません。 私はアサノさんに電話、草原さんは iBook で地図を検索、かっぱさんは道行く人に道を尋ねるという三者三様のことをやりつつ何とか到達。

ヌコ ( 猫の意 ) と戯れてみたり、アサノ塗装店の看板を激写してみたり、あれこれ挨拶したり、握手したり。 アサノさんが「クルマの写真撮っていいですか ? 」と言われたので快諾すると、なにやら色んな角度で撮ったり接写したりしていて、「これがアーティストの視点かッ…… !! 」と詠嘆することしきり。 でもここ数週間、土日が雨続きで洗車していない上に長距離を走ってきたので、やたらと薄汚れてしまっていたのですよね……。 果たしてどんな写真が撮られて、どのように活用されるかわくわくしておきます。 Junkline - Tour "Shake hands" 便乗オフ in すまね 2004/09/25 にて写真が使われています。

飛行機の時間が迫っているため、握手を交わしてるりさんは帰路へ。 ( 空港まではかっぱさんのエスコート ) 私とアサノさんと草原さんと FUMING さんの 4 人ですまねオフ突入。 と言ってもお酒が得意ではないアサノさんと、運転手である私はノンアルコールで臨んだわけですが。 それでも話題は尽きることなく、ジュースに「デカ !! 」と突っ込んでみたり、カクテルに「デk ……要するに、ビール用のジョッキにジュースが入ってきて、本来ならジュースが入ってくるであろうグラスにカクテルが入れられてきたと。 あと最後に頼んだお茶漬けもデカかったです。

過去に Timo たん ( 誰 ) とおてて比べをしたのに倣って、私とアサノさんもおてて比べ。 さすがと言うかなんと言うか、指が細くて長くていかにもピアニストってイキフンな手でした。 あとアサノさんと言えばメガネ、ってイメージがあるのに、わざわざお願いしてすっぴん ( 素メガネ ? ) の写真を撮らせてもらったりもしました。

話題が色々ありすぎてとても紙面 (?) に収まりそうにないので割愛しますが、 web に関する話題や業界の話題、鉄拳や雷電や各種ゲームハードの話題など、食べるものはしっかりと食べつつすまねの夜は更けていくのであった……という感じ。 あと体格の話が出たときに「けっこーガッチリ系ですぬー。」と言われたのが印象的でした。 確かにジムりんぐを初めてそこそこ経ったけど、自分じゃ実感が湧かないのですよね……。 ちなみに大胸筋とか上腕二頭筋とかは重点的にやってるけど、腹筋はあんまりやってないのです。 なので、「もしかして腹割れてます ? 」と聞かれて「いんや、むしろ出てます」と言ったのはボケでもなんでもなく素なのです……。 普段が座り仕事だから、脱ぐと凄いんです。 腹が。

オフも終わり、アサノさんを自宅に送ったのちに松江駅前のホテルへ。 ここはシングルが 3,800円という破格の値段なので、行く前から「どんなホテルなんだ !? 」「レポよろ」と言われていました。 そしてまたも草原部屋に集まり、途中で買い込んだ酒を煽りつつ IRC をしていたわけですが、運転の疲れからかいつの間にやら寝入っていました。 気が付いた時には FUMING さんは自室に戻られていたので、草原さんに明日は 9:00 集合とだけ伝えて自分も自室に戻ってすぐに睡眠の世界へ。

Tour "Shake hands" - 9 月 25 日 - IMAGE OR REAL

以下は参加者の印象というか感想などを。

るりさん

予想よりも背が高かったです。 ( それかっぱさんの印象と同じ ) ひとことで言うとお姉さんキャラ ? ( キャラ言うな ) やはり同じカメラ持ってるとなんだかむず痒いですね。

アサノさん

予想通りというか、アサノ塗装店に向かう時に家の特徴ではなく服で見つけたのはヒミツです。 声が予想より低かったかな ? そしてメガネを外した顔はやっぱり友人に似ていると改めて思いました。

リプライ

リプライはまだ送られていないか、管理者の承認待ち状態です。 この記事に対するご意見やご質問、ご感想などありましたら個別記事ページの送信フォームからお送り下さい。

Tour "Shake hands" - 002

記事データ

投稿者

望月真琴

投稿日時

2004-09-27T18:00+09:00

タグ
概要

Tour "Shake hands" 1 日目、夜の北新地レポート。

リプライ

リプライはまだありません。

記事本文

Tour "Shake hands" - 9 月 24 日 - drive to MY WORLD

予定通り、 7:00 に家を出る。 長く、そして初めての遠出となる旅に向けて、走る。

……渋滞。

途中の道がかなり混んできたので、適当な所を見つけて草原さんに連絡を取ると、予想以上に丁寧な物言いで驚きました。 道中少々迷いつつも無事草原邸に到着。 自慢の (?) Audi はガレージの中だったため、お目にかかることは適いませんでした。 次回こそは。

これから大阪までは 2 人のみの旅路なので、実際に会ってみてソリが合わなかったらどうしようと思っていましたけれど、非常に爽やか好青年な上に話題や知識も豊富で飽きることがありませんでした。 しっかりとナビを務めてくれましたし。 iBook を持ち込んでいたため、高速道路から IRC に Join ( もちろん草原さんが ) という離れ業もやってみました。

道路自体は特筆すべきところもなく、強いて言えばトンネルが多く、運転手である私はそれに辟易していたため、トンネルが近付くたびに草原ナビは「もうすぐトンネルにさしかかりますよー」と知らせてくれました。 そのたびに「またですかー」と嫌そうな声をあげる私。 ……草原さん、それを見越してトンネルが近付いていることを知らせてくれたわけじゃありませんよね ?

大阪市内に入り、阪神高速に乗ったところで夕方の渋滞に遭遇。 阪神高速を降りたらそんなには混んでなかったんだけど、交差点が非常に大きくてびっくりしました。

なんとかホテルにたどり着き、 FUMING さんに到着したメールを送り、ロビーで待つこと 10 分あまり。 なかなかメールが返ってこないなあと思っているうちに程なくして会うことができたのですが、 FUMING さん曰く「 2 人とも浮きすぎ」とのこと。 確かに、この場には似つかわしくないジャケットだったかもしれません。 というか周りを見渡すとビジネスマンばかりですし、向こうではいかにも社長って感じの中年男性が「今日は若いのを連れて E 社の社長に会いに行こう」とか言っているし。

そして一行は夜の北新地へと赴くのであった……

10 月 26 日になって、「ロビーに到着しました」というメールが届きました……。

Tour "Shake hands" - 9 月 24 日 - B.BEERing

夜の北新地。 こう書くと何だか歌の題名みたいですけれども。

一次会会場のビアレストラン キリンケラーヤマトに向かうと、既に表具師かっぱさんと inugamix さんが私たちを待っておられました。 ……グラサンは ? カヌーは ? ( 内輪ネタ )

店内に入り、それぞれ飲み物を注文。 そして料理を注文という流れになったのですが、どれも美味しそうで悩みます。 せっかくだから私はこの茄子のミルフィーユを選ぶぜ !! と即決 ( 悩んでないじゃん ) したところ、他の方はまだ迷っていたため、 FUMING さんが「今日のオススメを全部流してください」という漢 ( をのこ ) らしいオーダーをなされました。 ほんとうはみんながあれこれ悩んでいたので、スパッと頼んでくれたということなんですが。 ええ、 FUMING さんが食いしん坊だと言っているわけではありませんよ念のため。

黒ビールとペールエールを飲んだところで、シュタインヘイガーという冷凍酒をいただくことに。 かなり強めのお酒だったけれどこれはこれで美味しかったです。 そして 4 杯目は焼酎「奄美」をロックで。 「けんたろロックだー !! 」とか言ってひとりハイテンションでした。

店内の会話はごくごく普通のもので、たぶん他のお客さんからは「ああ、会社の同僚か何かかな」とでも思われるようなものでした。 ふふふ、まさかインターネットの猛者 ( 何それ ) 揃いとは夢にも思うまい。 でもよくよく聞いたらみんな言葉が違うので、違和感を感じたかもしれませんが。 いちおうラスト付近で「どうして Valid な HTML を心がけるようになりましたか ? 」という質問をすることができたので、これについてはまたどこかで書くことができたらいいなと思いました。

Tour "Shake hands" - 9 月 24 日 - D.O.D. ( DRINK OR DIE )

そして、二次会にていわいさん、 Piro さんとも合流。 梅田センタービルの GLILL & PUB MOONSHINE というところに行きました。 向かう道中で Piro さんに「そういや何の集まりか知ってます ? 」と聞いたら実は微妙に分からないまま参加しているような答えで、ちょっと笑ってしまったり。 後日のオフレポ にてサイト分からんかったと書かれているけれど、その時は hxxk.jp のことは伏せていたので、分かるはずもなく。

店内に入ってマティーニと焼カマンベールチーズを注文。 ……あの、何かチーズが燃えたまま運ばれてきたんですけど。

ここで、「いかにも福岡 !! 」をコンセプトに、ひとりひとり違うものを選んだという変な気合の入ったお土産を配布。 何を買うかを、デパ地下であれこれ選んでいる最中がいちばん楽しかったということはありませんよ、決して。 たぶん。

誰に何を差し上げるかは決めずに買っていたので、その場の雰囲気で配ることに。

  • inugamix さんは何故かひよこまんじゅうの袋に怯えていたので、克服する為に (?) ひよこまんじゅうを。
  • いわいさんには箱の裏に博多の方言講座が書かれているにわかせんぺいを。是非会社などで披露してください。
  • Piro さんには博多通りもん。実は何たら賞受賞も知らなかったし、食べたこともないので喜んでいただけるか微妙だったのは秘密。
  • FUMING さんには筑紫もち。あの蜜が何とも言えず旨いのですよ。
  • 表具師かっぱさんには千鳥饅頭。自分的には一番スタンダードなものだと思ったのですが如何でしたでしょうか。
  • 草原さんには何もなし。まあ土産も何も地元民やけんね。

表具師かっぱさんと inugamix さんを駅まで見送った後、ホテル組と終電逃し組は珈琲館へ。 チョコシフォンが美味しかったです。 でも実はけっこー酔いが廻っていたので、何を話したかをあんまり覚えてなかったり……。 Piro さんに Tabbrowser Extensions では非常に ( 一方的に ? ) お世話になっていますと告げた覚えはあるけれど。 あとノートとかを持ち込んでレポートのようなものを書いている人が見受けられたのはまだいいとして、画板 (?) を持ち込んで何かを描いていたお姉さんにはびっくりしました。

ホテルに戻って、いったん草原さんの部屋に集まって軽く明日の打ち合わせ。 8:30 に朝食の場所に集まることにして解散、おやすみなさい。

Tour "Shake hands" - 9 月 24 日 - IMAGE OR REAL

以下は参加者の印象というか感想などを。

表具師かっぱさん

予想よりも背が高かったです。 喋りが流暢というか、軽快でおもしろかったです。 カヌーが見当たらないのが残念だったけれども。 ( 内輪ネタ、まだ言うか )

inugamix さん

けっこー予想通り ( えええ ) というか。 うちの職場の先輩と色々似てます。

FUMING さん

これ別に FUMING さん本人の印象というより広島の方の印象なんでしょうけど、「〜じゃけぇ」という方言が印象的。 あとお酒に強いと思いました。

いわいさん

inugamix さんも仰ってたけど、喋り用の CPU は一体何 GHz を搭載なされているのでしょう。 あとツッコミがサクッと突き刺さるのはイメージ通りというか、ほんとにチーズ盛り合わせは食べることが適わなかったのですが。

Piro さん

スラっとしていて、かつ穏やかな雰囲気だったのでけっこう予想外。 ( 某「就活用」のイメージが強かった ) MOONSHINE では席が離れていたので、また機会があればじっくりとお話しましょう。 ( 珈琲館の会話はだいぶ記憶が飛んでいます。 )

とりあえず、目が充血してるみたいで蝶・心配なんですが!→それはデフォです みたいな話はした覚えがあります。

草原 翼さん

方言使いましょうよー。 でも彼の非常に丁寧な言葉遣いは見習わねば ( 自戒 )

総評

私はコンタクトレンズ常用のため、突如勃発したメガネ交換会のときはちょっと寂しかったり。

リプライ

リプライはまだ送られていないか、管理者の承認待ち状態です。 この記事に対するご意見やご質問、ご感想などありましたら個別記事ページの送信フォームからお送り下さい。

Tour "Shake hands" - 001

記事データ

投稿者

望月真琴

投稿日時

2004-09-27T17:00+09:00

タグ
概要

Tour "Shake hands" の発案の経緯や参加者一覧など。

リプライ

リプライはまだありません。

記事本文

はじめに

この記事を書いたのは、実際はかなり後になってからなので、 1 日で書いたとは思えない量の文章を書いています。 よって、いくつかの記事に分けられていることをあらかじめご了承ください。

なお、一連の記事に対してリンクを行う場合は http://hxxk.jp/2004/09/27/ にリンクを行うことで、まとめて表示することができます。 ご活用ください。

Tour "Shake hands" 勃発

ふだんは Weblog を書いたり Movable Type をいじったりして遊んでいる我がパソコンライフですが、そのパソコンライフのうち大きな比重を占めるものに、 IRC で遠く離れた地の人たちとお話しする、というものがあります。 まあ Join しているメンバーに言わせれば、遠く離れているのは言うまでもなく私の方だろうという意見が多数を占めるとは思いますが。

距離や地域の差を感じさせないということがインターネットの素敵な面でもありますが、やはり近場にメンバーがいる場合はオフラインでも会ったりしているようです。 すごく近いメンバーだと、何気なくランチを一緒に食べようね、といった会話がなされていて羨ましく思います。

そういったことを常々思いながら夏の終わりを感じていたある日、夏期休暇を消化しきれていなかったことに気付きました。 「ああ、そういえば 7 〜 8 月は何かと忙しかったしなあ……というか夏が終わるとか言ってる場合じゃないですよ自分。残したままじゃ終われないですよ、完全燃焼してこそ夏ですよ。」 などと訳の分からないことをのたまいつつ、 2 日という中途半端な休暇をどう使おうかと考えました。

その結果、土日とくっつけて少し遠出をしてみよう、大阪くらいまでドライブしたら楽しそうじゃないか ? と思い、 Tour "Shake hands" 構想を立ち上げました。 IRC で話を持ちかけてみたり、計画専用の Wiki を作ってみたり、結果的には準備の時点からその準備自体を楽しむようなものになりました。

ここではその記録をまとめておこうと思います。

Tour "Shake hands" データ編

日程

9 月 24 日 7:00 出発 〜 9 月 26 日 23:30 帰宅

参加者 ( 順不同、日記へのリンクを行っています )
走行距離

1526.2km ( この時点での総走行距離の実に 12.56% )

燃費

15.6km/l

平均速度

56.9km/h

費用
合計

約 53,000 円

9 月 24 日
  • 福岡 IC 〜中国池田 IC 普通車 : 12,250 円
  • 下松 SA 昼食 : 700 円くらい ?
  • 阪神高速道路 普通車 : 700 円
  • ハイオクガソリン 40l : 5,040 円
  • キリンケラーヤマト : 2,000 円
  • ムーンシャイン : 2,000 円
  • 珈琲館 : 1,000 円くらい ?
  • 大阪全日空ホテル シングル : 10,000 円
  • 大阪全日空ホテル 駐車料金 : 1,000 円
9 月 25 日
  • 阪神高速道路 普通車 : 700 円
  • 中国池田 IC 〜蒜山 IC 普通車 : 4,750 円
  • 勝央 SA 昼食 : 600 円くらい ?
  • ハイオクガソリン 35.3l : 4,447 円
  • かば : 2,200 円
  • 島根アーバンホテル シングル : 3,800 円
  • 駐車料金 : 600 円
9 月 26 日
  • 水木しげる記念館 入館料 : 700 円
  • 3 段割子そば定食 : 880 円くらい ?
  • 山口 IC 〜福岡 IC 普通車 : 3,900 円
  • ハイオクガソリン 42.4l : 5,342 円
  • とらや 豚骨バターセット : 800 円

同乗者負担もあるため、これらの小計は 53,000 円よりも多くなります。 実際に使ったお金が約 53,000 円ということです。

リプライ

リプライはまだ送られていないか、管理者の承認待ち状態です。 この記事に対するご意見やご質問、ご感想などありましたら個別記事ページの送信フォームからお送り下さい。

稚拙 = 頭が悪いというわけではないけれど

記事データ

投稿者

望月真琴

投稿日時

2004-09-21T23:33+09:00

タグ
概要

口頭で伝えるのではなく文字として抗議の意を示す場合に、対象が限定された表現を使ったり、むかつくというただの感情をぶつける言葉を使っているというのは TPO を弁えておらず、言葉の使い分けが身についていないということなのでしょう。

リプライ

リプライはまだありません。

記事本文

Movable Type 3.01D-ja と 2.661 の共存による弊害でちょっと引用した404 : 頭の悪いヒット作に対する反応という記事ですが、引用を行った Movable Type に関する部分以外にも興味深い点が。

Posted by : 望 : 2004/09/19 - Sun. 15:00
最低!このページを作った人は、最低!!!私は、ディープラブを読んで、めっちゃ感動した!泣いた!世の中をただ、世間体、理論なんかで考えているのは、大人だけ!日本も、どんどん汚くなってきている。 私も、最初は、エロいだけと思っていたけど、中盤からは、感動とは違う感情の涙を流していた。

直前のやり取りなどに興味のある方は 引用元 をご覧下さい。

最低!このページを作った人は、最低!!! と言われている人 ( イソムラさん ( monologue : anytime, anywhere. | 404 ) ) と、このページ ( おそらく 404 : 頭の悪いヒット作で紹介されている成城トランスカレッジ!! ―戯言@はてな―の一連のレビューのことを指しているのだと思われます。 ) を作った人は全くの別人ということを判断できていない時点で、この望さんという方の読解力というものの底が見えてしまいますが。

望さんが 感動とは違う感情の涙を流していた というのは事実なのでしょう。 で、望さんは このページを作った人 に対してその事実を以って何を伝えたいのかが全く読み取られません。 もう一度読んで感情の涙を流して欲しいのか、レビューを撤回して欲しいのか、それとも単に自分語りなだけなのか。 私の読解力が至らないために、望さんのコメントから読み取ることができないだけであって深いメッセージを内包しているのかもしれませんが。

引用元のコメントもなかなか面白いのです。

Posted by : レイナ : 2004/09/06 - Mon. 10:57
何が頭が悪いんだよ!バリむかつく!

登場人物の名前をそのままハンドルにして抗議コメントを書くあたりとか、 バリ という作中の表現をそのまま使用しているあたりが。

まあ、「とても」とか「かなり」といった意味で使われるバリという表現は方言でも見受けられますし、私自身同年代の友人との会話で使うこともあります。 けれども、口頭で伝えるのではなく文字として抗議の意を示す場合に、こういった限定された表現を使ったり、むかつくというただの感情をぶつける言葉を使っている時点で TPO を弁えていないというレッテルを貼られても仕方ありません。

私自身、どちらかというと活字にあまり触れずに過ごして今に至っているわけですが、それでもある程度の文章をこうして書いています。 きちんと書けているのか、という判断は私にはできかねますが。 口に出して喋る言葉と、文字として認める言葉の使い分けくらいは普通は身につくものだと思うのですけどね。

リプライ

リプライはまだ送られていないか、管理者の承認待ち状態です。 この記事に対するご意見やご質問、ご感想などありましたら個別記事ページの送信フォームからお送り下さい。

Movable Type 3.01D-ja と 2.661 の共存による弊害

記事データ

投稿者

望月真琴

投稿日時

2004-09-21T19:39+09:00

タグ
概要

現在は、 Movable Type 2.661 と Movable Type 3.01D-ja のシステムが両方有効になっています。これはある種イレギュラーな運用とも言え、共存させることによるメリットもあまりありません。いずれは Movable Type 3.01D-ja に統一しますが、完全に移行が終わるまでは Powered by 〜 の部分がころころ変わる、ということをお知らせしておきます。

リプライ

2 件のリプライがあります。

記事本文

MT 2.x hxxks を MT hxxks に改称しますにて、 随時 3.x 仕様へと変更していこうと思います と書いていますが、じゃあ変更途中である現在の hxxk.jp 上の Movable Type のシステムはどうなっているのか ?

現在は、 Movable Type 2.661 と Movable Type 3.01D-ja のシステムが両方有効になっています。 私がテストしてみたところ、 Movable Type 3.01D-ja と 2.661 を共存させると、それぞれの管理画面からそれぞれのバージョンの投稿ができてしまうみたい という結果を得ることができました。

異なるバージョンを共存させるためには少々発想をひねらないといけないのですが、共存させて得られると思われるメリットが少なく、混乱することの方が多くなるだろうと思うので詳しい実現方法については述べません。 私のように複数の Movable Type 上の weblog を作成していて、バージョンアップによる違いを試すようなことをしない限りは共存させる意味もありませんし。

MT 2.6x、つまりリニューアル以前に使っていたツールが実はまだいつでも稼働可能な状態で残してあって、検索なんかでたどり着いてコメントやトラックバックを残すことが可能な状態になっていた。

こういったことも有り得るようです。 これを書いている時点での hxxk.jp 内の weblog は、全て Movable Type 2.661 のシステムによってコメントやトラックバックの処理がなされています。 Movable Type 3.01D-ja のシステムも、使える状態でサーバ上に存在していますが、実際に閲覧者から見える状態にはなっていません。 しかし、今後の移行およびテスト段階ではそのシステムも混在していくかもしれない、というか混在させるつもりなので、注意しておかなければなりません。

とりあえず応急処置ということでフォームの一部とトラックバック URI の表示を削除。

とあるため、どういった状態になっていたのかは分かりませんし、現在の 404 では Movable Type 3.01D-ja のシステムでのみコメントやトラックバックを扱えるということになっているなので、これ以降は特に問題もないでしょう。

しかし、今後 hxxk.jp で予想される現象として、 Movable Type 2.661 の管理画面から記事の更新なり weblog の再構築を行った場合は Powered by Movable Type 2.661 として構築され、 Movable Type 3.01D-ja の管理画面から記事の更新なり weblog の再構築を行った場合は Powered by Movable Type 3.01D-ja として構築されるというものがあります。 予想されるというか実際にテストしたんですが。

これはバージョンアップ前とバージョンアップ後のシステムから生成される weblog の各記事やアーカイブの URI が同一で、かつ異なるバージョンのシステムが共存している場合にのみ起こるもので、バグと言うよりは私のイレギュラーな運用によって起こるものです。 いずれは Movable Type 3.01D-ja に統一しますが、完全に移行が終わるまでは Powered by 〜 の部分がころころ変わる、ということをお知らせしておきます。

現在は Movable Type 3.151-ja に一本化しています。

リプライ

2 件のリプライが送られています。 この記事に対するご意見やご質問、ご感想などありましたら個別記事ページの送信フォームからお送り下さい。

2004-09-22T13:36+09:00 - イソムラ

はじめまして、404のイソムラです。 2.6xと3.0の共存による弊害として一番大きいかも知れないものは、RSS配信している(RSSを誰かがチェックしている)場合、どちらかにコメントが投稿されるとそっちのシステムで自動的に再構築されてしまうことではないかなぁと思います(実際それで3.0のRSSが2.6xによって上書きされていることに気付きました)。 2.6xと3.0で同じデータベースを共有している、というような場合だと問題ないかも知れませんが。それでもMTのバージョンを読み取って更新された、と勘違いするチェッカーもあるかも知れません。

2004-09-27T22:30+09:00 - 真琴

どうも、はじめましてー。実際に異なるバージョンのそれぞれのシステムで更新して、どのような挙動をするのかをまだ確認していませんが、 RSS 等は確かに影響を受けそうですね……。 私は 3.x の方でも TypeKey を用いたコメント認証を行うつもりはありませんが、おそらく TypeKey を活用した状態でかつ共存を行っている場合、 2.x 側の方にコメントが投稿されたら、 weblog 全体が 2.x の状態、すなわちコメント認証が行われない状態になるのではないか、と予想しています。 私はどちらのバージョンでも同じ DB を使い、同じ URI で構築するようにしているので、最終的に完全に 3.x のみの運用にしてしまえば問題はないかもしれませんが……。 イソムラさんのように 3.x アップグレードを機に URI の命名規則を変更し、かつ 2.x 時代のエントリも残しているような場合は注意が必要なのでしょう。

MT 2.x hxxks を MT hxxks に改称します

記事データ

投稿者

望月真琴

投稿日時

2004-09-21T00:31+09:00

タグ
概要

Movable Type 3.x へのアップグレードを拒む必要がなくなったので、随時 3.x 仕様へと変更していこうと思います。 合わせて MT 2.x hxxks から MT hxxks に改称し、テンプレートにも若干の修正を加えようと思っています。

リプライ

リプライはまだありません。

記事本文

「ウェブログ」の定義は何ですか? もしMovable Type上の複数のウェブログを使って、1つのサイトを構築している場合は?

「ウェブログ」とは何か、という問題は、少々あいまいなところがありますが、基本的には次のような回答になります - もしMovable Type上の複数のウェブログを使って1サイトを構築している場合、ライセンス上は1ウェブログと計算します。

ライセンス上では、この問題は次のような言い回しで扱われます:“ウェブログ”とは、一つのURL(ユニフォーム・リソース・ロケーター)から閲覧可能な、一つのウェブサイトのことで、Movable Typeの「新しいウェブログの作成」機能で作成された1つ以上のウェブログから構成されます。

念のため、ウェブログ・サイトを構成する下位ウェブログは、ライセンス上のウェブログ数には数えられません。

例:もしあなたのウェブログ・サイトが、Movable Type上は4つのウェブログで構成されていた場合、つまり一つが文字ベースのメイン・ウェブログ、一つがリンク集、一つが音楽リスト、一つが書籍リスト、という構成の場合、ライセンス上は1ウェブログとみなされます。

多くのMovable Typeユーザーが、非常に頻繁にこういう設定をしています。 例えば、Movable Type公式サイト(movabletype.org)は、Movable Type上は3つのウェブログから構成されています。 現在、技術的見地から、この区別をよりシンプルにしようとしていますが、この説明によって(ウェブログ数に関する)疑問が解消されることを望みます。

恥ずかしながらこのアナウンスを見逃していたために、 Movable Type 3.x では現在の hxxk.jp のような運用 ( 複数の weblog を作成し、カテゴリよりもより大きな記事の分類を実現 ) ができない、と思い込んでいました。 MT hxxks ではなく MT 2.x hxxks とコンテンツ名を名付けたのもこの思い込みに由来します。

これにより、 Movable Type 3.x へのアップグレードを拒む必要がなくなったので、随時 3.x 仕様へと変更していこうと思います。 合わせて MT 2.x hxxks から MT hxxks に改称し、テンプレートにも若干の修正を加えようと思っています。

現在はキーワードによる分類を行っているため、 weblog 自体は hxxk.jp に一本化しています。

リプライ

リプライはまだ送られていないか、管理者の承認待ち状態です。 この記事に対するご意見やご質問、ご感想などありましたら個別記事ページの送信フォームからお送り下さい。

Bookmark の運用方法を変更します

記事データ

投稿者

望月真琴

投稿日時

2004-09-20T20:47+09:00

タグ
概要

Bookmark にも Movable Type を利用しようかな、とぼんやりと考えています。実際に Movable Type を使った形態にするのは、他の部分の再構築が終わってからの話ですが。

リプライ

リプライはまだありません。

記事本文

Bookmark にも Movable Type を利用しようかな、とぼんやりと考えています。 現在は XBEL で記述して、 XSLT を用いて XHTML 1.0 に変換していますが、なかなかメンテナンスを行おうという気を起こすまでに至らないというのが正直なところです。 ブラウザのブックマークからエクスポートするような運用だとこの手法は便利なのかもしれませんが、私の場合はサイトで公開するブックマークとブラウザのブックマークが大きく違うので、 XBEL を用いるメリットがあまりないのです。

実際に Movable Type を使った形態にするのは、他の部分の再構築が終わってからの話ですが。 その際は単なるリンクアンカーの羅列だけでなく、そのブックマークごとの紹介を書いておこうと思っています。 その方が自分が後から見返すときも便利だと思いますし。

ただ、そこまで手が廻るのはまだ数週間先の話だと思うので、それまではこの hxxk.jp にブックマーク候補をメモしていこうと思います。 以上、お知らせでした。

運用方法を変更しました。 ( xxxkmark はじめました )

リプライ

リプライはまだ送られていないか、管理者の承認待ち状態です。 この記事に対するご意見やご質問、ご感想などありましたら個別記事ページの送信フォームからお送り下さい。

Movable Type 3.01D-ja と 2.661 の共存テスト (2)

記事データ

投稿者

望月真琴

投稿日時

2004-09-18T17:44+09:00

タグ
概要

Movable Type 2.661 の管理画面から投稿してみる。

リプライ

リプライはまだありません。

記事本文

Movable Type 2.661 の管理画面から投稿してみる。

リプライ

リプライはまだ送られていないか、管理者の承認待ち状態です。 この記事に対するご意見やご質問、ご感想などありましたら個別記事ページの送信フォームからお送り下さい。

Movable Type 3.01D-ja と 2.661 の共存テスト

記事データ

投稿者

望月真琴

投稿日時

2004-09-18T17:38+09:00

タグ
概要

Movable Type 3.01D-ja と 2.661 を共存させると、それぞれの管理画面からそれぞれのバージョンの投稿ができてしまうみたいです。

リプライ

リプライはまだありません。

記事本文

私の想像が正しければ、このエントリが投稿されても Movable Type 2.661 のままで保存されるはず……。

Movable Type 3.01D-ja と 2.661 を共存させると、それぞれの管理画面からそれぞれのバージョンの投稿ができてしまうみたいです。 両方で投稿してみましたが、 Powered by <a href="http://www.movabletype.org">Movable Type <$MTVersion$></a> のバージョンが、最後に投稿したバージョンのものになっていました。

リプライ

リプライはまだ送られていないか、管理者の承認待ち状態です。 この記事に対するご意見やご質問、ご感想などありましたら個別記事ページの送信フォームからお送り下さい。

各種 weblog ツールおよび weblog サービスの CSRF 脆弱性対応状況

記事データ

投稿者

望月真琴

投稿日時

2004-09-14T23:12+09:00

タグ
概要

http://hxxk.jp/2005/05/13/2105 にて触れた脆弱性に対する、各種 weblog ツールおよび weblog サービスの対応状況を記録しています。

リプライ

2 件のリプライがあります。

記事本文

この記事について

Movable Type における CSRF の可能性と各種対処法にて触れた脆弱性に対する、各種 weblog ツールおよび weblog サービスの対応状況を記録しています。

これは私が把握しているもののみ記述しています。 私が未対応と書いていても既に対応済かもしれませんし、私が対応済と書いていてもまだ穴が残っているかもしれません。

  1. Movable Type
  2. はてなダイアリー
  3. sb
  4. tDiary

Movable Type

2.x 、 3.x ともに未対応と思われます。

ユーザー側の自衛策として以下のようなものがありますので、参照してください。

mt.cgi のファイル名を変更
weblog 内から直接 mt.cgi の各種編集機能に対してアンカーを配置している場合に、自分にのみ表示されるようにする
Referer のチェックを行うようにする
ユーザーの権限を変更し、 weblog 自体の削除を未然に防ぐ
ブラウザを、ブラウジング用のものと更新管理用のものとを使い分ける
mt.cfg の保護
削除の確認画面以外からの削除を不可にする

はてなダイアリー

2004 年 9 月 13 日対応済。 ( はてなダイアリー日記 - はてなダイアリーの不正な自動操作についての脆弱性について )

ただし、まだセキュリティホールが残っているかもしれません。 ( Another 朝顔日記 - はてなダイアリーの不正な自動操作についての脆弱性 )

9 月 13 日の対応については リファラ切っていると駄目 という状態だったようで、 7 月 15 日に改めて対応されたとのことです。 ( Another 朝顔日記 - CSRF 脆弱性対策 )

sb

2004 年 8 月 13 日対応済。 ( sb - バグトラッキング | [B074] 管理操作に関する脆弱性 )

ver 0.20 時点で対応済となっています。

tDiary

特にアナウンスはなし。

各種環境での対策案

2005 年 7 月 20 日対応済。 tDiary 2.0.2 ( 安定版 ) または tDiary 2.1.2 ( 開発版 ) 時点で対応済となっています。

リプライ

2 件のリプライが送られています。 この記事に対するご意見やご質問、ご感想などありましたら個別記事ページの送信フォームからお送り下さい。

2004-10-26T00:10+09:00 - Weblog ツールの脆弱性 < 45rpm

MTをインストールしたら真っ先に行うべきセキュリティ対策別所でMTを使用中なので興味深く読んでしまった。私の理解の及ぶ範囲では、mt.cgiのURIが...

2005-07-18T23:36+09:00 - [はてな]CSRF 脆弱性対策 < Another 朝顔日記

d:id:nyama:20041227:1104116475 とかで書いていた脆弱性がようやく修正された模様。以前は以下のような内容が書かれた html ファイ...

MT をインストールしたら真っ先に行うべきセキュリティ対策

記事データ

投稿者

望月真琴

投稿日時

2004-09-13T21:05+09:00

タグ
概要

この記事は obsolete です。 Movable Type における CSRF の可能性と各種対処法 ( http://hxxk.jp/2005/05/13/2105 ) を参照していただくようお願いします。

リプライ

20 件のリプライがあります。

記事本文

この記事は obsolete です。 Movable Type における CSRF の可能性と各種対処法を参照していただくようお願いします。

何故こんな記事を書くのか

通常、私は自分の力量の範囲で調査・考察し、自分で「理解できた」と判断したもののみを記事として書くというスタンスでサイトを運営しています。 それは 真琴が興味のあることを調査、ないし考察したことについての記録を行うサイトです と書いている通りで、知ったかぶりをしないように自戒するための意味を持っています。

しかし、今回の記事は緊急を要するものであり、 検索してみた所、記事の少なさから、この問題に対する意識の低さを感じました と元記事にあることを受け、多くのユーザーが記事を書くことで元記事への関心を示し、問題に対する意識を持っていると表明することに繋がると判断したために、拙いながらも自分の分かる範囲からちょっと背伸びして記事を書くことにしました。

この記事を目にした方で Movable Type ユーザーである方は、貴方なりにこの問題に対する記事を書いてくれませんか ?

この記事を目にした方で Movable Type ユーザーではないけど何がしかのウェブサイトを持っている方は、 SG::Acme : attacking MT 1 および SG::Acme : attacking MT 2 を一読して、良ろしければ貴方のサイトにてこの 2 つの記事を紹介してもらえませんか ?

何故緊急を要するのか

実際の問題の詳細は SG::Acme : attacking MT 1 に書かれているため、ここでは割愛します。 要点のみをまとめると、

  • MT3のコードも目を通してみたのですが、対策が為されていないようです。
  • MTに限らずCookieでのセッション管理を行う多くのWeb Applicationにありうる。(MT自体の脆弱性と言うには語弊があることに注意)
  • urlをクリックした瞬間、何の前触れもなくblogの消去やentryの投稿など、任意の動作が実行されてしまう
  • はてなダイアリーにも同じ脆弱性がある
    • この脆弱性は知人が8月上旬頃(15日?)にはてなへ通報済みですが未だ対応されてません。
    • 更新だけではなく削除や設定変更なども可能
    記事を書いているうちに、対応がなされていたようです。 ただし、まだ油断はできないので、友人のスーパーハカー ( 笑うところ ) たちのテストの結果次第ではまた追記します。 ( はてなダイアリー - はてなダイアリー日記 - はてなダイアリーの不正な自動操作についての脆弱性について )
  • 表面化していないだけで、 Cookie を利用してユーザーログインを行っている weblog ツール・ weblog サービスのほぼ全てに同様の脆弱性が存在すると思います。

利便性をあまり損なわず、ある程度確実性も保たれる対策

mt.cgiの名前を変更することです。 以下にその理由を説明します。

Movable Type の管理画面は、 /Install directory/mt.cgi からアクセスする形になります。 そして、当たり前ですが管理画面からは変更できません。 ( この脆弱性がなければ変更する意味もほとんどありませんし。 )

通常では weblog を公開するディレクトリと Movable Type のシステムファイルを置いておくディレクトリ ( Install directory ) は別のものを設定していると思います。 だからといって Install directory は閲覧者には知る術がないのかというと、そんなことはありません。 全くテンプレートをカスタマイズしていない Movable Type 2.661 を例にとってみても、以下のような手段が考えられます。

コメント投稿フォームから探す

Main Index や Monthly Archive の、各記事のコメントというアンカーに、 /Install directory/mt-comments.cgi?entry_id=id という URI が示されています。

また、 Indiviaual Entry Archive にはコメント投稿フォームが配置されていますので、その form 要素の action 属性を見れば /Install directory/mt-comments.cgi という URI を知ることができます。

トラックバックから探す

各記事のトラックバックというアンカーに、 /Install directory/mt-tb.cgi?entry_id=id という URI が示されています。

また、 Indiviaual Entry Archive の head 要素には <$MTEntryTrackbackData$> として /Install directory/mt-tb.cgi という URI が示されています。

検索フォームから探す

Movable Type 内の検索フォームの、 form 要素の action 属性を見れば /Install directory/mt-search.cgi という URI を知ることができます。

このように、簡単に Install directory を知ることができますので、 Install directory/mt.cgi にアクセスすれば、そのサイトの Movable Type の管理画面が表示されるはずです。 もちろんこれだけでは、 ID/PASS を入力しない限りは実際の編集は行えないはずです。 しかし、 SG::Acme : attacking MT 1 で説明されている通り、 ターゲットのMTの環境に関する僅かな情報があれば、Cookie認証を済ませたユーザーに任意の操作を行うmt.cgiへのクエリを含んだurlを踏ませることで、確認なく 記事の投稿や weblog 自体の消去を行わせることができます。

ここで述べられている ターゲットのMTの環境に関する僅かな情報 というのは、 Install directory のパスと、編集画面の CGI のファイル名が mt.cgi であるか否かという 2 点だけです。 Install directory のパスは前述の通り容易に知ることができます。 そして、 mt.cgi であるか否かは、実際に /Install directory/mt.cgi にアクセスしてみれば判断できます。 この 2 点さえ分かってしまえば、あとは Movable Type のユーザーにトラップを仕掛けた URI をクリックさせてしまえば攻撃はほぼ成功するということです。

この書き方だと、攻撃は特定のターゲットに対して行われるのかと捉えられるかもしれませんが、そんなことはありません。

たとえばMTを攻撃の的としたいなら

  1. http://ping.bloggers.jp/ などのping鯖で公開されているrdfをごそっと取得
  2. そのなかからMTで生成されたものを選別
  3. 悪意のあるスクリプトがあるURLを、上で選別されたMTサイトに自動でトラックバックする
  4. 管理者が管理画面からそのURLを踏む or (管理画面じゃなくってサイトから)普通にクリック
  5. refererのURLからmt.cgiの場所を推測
  6. javascriptやmeta refreshなどで自動でPOSTやGETを送信させる
  7. 記事が全削除される
  8. (゜д゜)クマー

上記の方法をスクリプトなどで実行することにより、数十人はひっかかって全記事削除されると思います。

こういった、多数のターゲットに対する攻撃方法の予測もなされています。

しかし、 mt.cgi のファイル名を本人にしか分からないように変更してしまえば、攻撃者は目標を失います。 mt.cgi のファイル名を変更しても、影響を受ける部分はほとんどありませんので、定期的にファイル名の変更を行えば、ファイル名を推測されて攻撃される危険性も激減します。 mt.cgi のファイル名変更対策で見落としやすい穴に気を付けておけば、確実性を高く保ったまま運用を続けることができます。

利便性を度外視するが、確実性の高い対策

Cookie を有効にしないこと、あるいは編集作業を始めたら他のウェブサイトを見ずにそれのみに集中し、編集作業を終えたら直ちにログアウトすることです。

この対策を行えば、編集を行う度に ID/PASS の入力が必要となりますが、そのために悪意ある URI をクリックしたとしてもその攻撃は成功しません。 利便性さえ考えなければ確実な対策と言えますし、 Movable Type のシステム自体には何ら変更を加える必要がないので、素早く対策を取ることができます。 ( ただし、一度でもログアウトを忘れるとその確実性はたちまちゼロになりますが。 )

なお、前述の mt.cgi のファイル名変更対策と組み合わせると、より強固なセキュリティを得ることができます。

普段ブラウジングに使っているブラウザと、更新管理とかに使うブラウザを別にするという方法 を取るのも良いでしょう。 通常のブラウジングに使っているブラウザで編集画面のログインを行わないようにして、編集画面のへのログインはそれ専用のブラウザを使用すれば、毎回ログアウトを行うよりは利便性も保たれます。

mt.cgi のファイル名変更対策で見落としやすい穴

mt.cgi のファイル名変更対策には、落とし穴があります。 ファイル名を変更していたとしても、それを Movable Type のユーザー以外でも知る術が残っていればたちまち確実性はゼロになります。 よって、以下に示すセキュリティホールとなり得る要因の対策も同時に行う必要があります。

管理画面のトラックバックを絶対にクリックしない

スクリーンショット Movable Type の場合、トラックバックを受信すると、管理画面にそのアンカーが表示されます。 「トラックバックが来た !! 」なんて喜んで、不用意にそのアンカーをクリックすると、トラックバック送信者に向けてファイル名変更後の .cgi のファイル名を Referer として教えてしまうことになります。

また、管理画面にトラックバックのアンカーが表示されるということは、すなわち Cookie が有効な状態である場所にアンカーが表示されるということです。 SG::Acme : attacking MT 1 にある通り、 一見無害なurlで 攻撃を仕掛けることができるため、よりユーザーのクリックを誘発しやすくなります。

/Install directory/search_templates/default.tmpl の修正

/Install directory/search_templates/default.tmpl というのは、検索結果を出力する際に使われるテンプレートです。 これは Movable Type の管理画面からは変更できないため、テンプレートをカスタマイズしている人でも見落としがちなテンプレートですが、デフォルトのままだとこの脆弱性に対する大きなセキュリティホールを抱えています。

<MTSearchResults>
	
	  <MTBlogResultHeader>
	  <h2 class="date">Search Results from <$MTBlogName$></h2>
	  </MTBlogResultHeader>
	
	  <div class="blogbody">
	  <h3 class="title"><a href="<$MTEntryPermalink$>"><$MTEntryTitle$></a></h3>
	  <$MTEntryExcerpt$> <$MTEntryEditLink$><br />
	  <div class="posted">Posted in <$MTBlogName$> on <$MTEntryDate$></div>
	  </div>
	
	</MTSearchResults>

<$MTEntryEditLink$> というのは検索テンプレート専用のテンプレートタグで、その他のテンプレートでは使えません。 よって検索テンプレート同様このテンプレートタグの存在自体を知らない人も多いかもしれません。 これは検索結果ごとにその記事を直接編集できるアンカーを作るもので、 Movable Type ユーザーにとってはなかなか便利なものです。

mt.cgi のファイル名変更対策で mt.cgi のファイル名を変更していた場合、 /Install directory/lib/MT/App/Search.pm を書き換えないと <$MTEntryEditLink$> は正しく機能しません。

sub _hdlr_entry_edit_link {   
    my($ctx, $args) = @_;
    my $user = $ctx->stash('user') or return '';
    my $entry = $ctx->stash('entry')
        or return $ctx->error(MT->translate(
            'You used an [_1] tag outside of the proper context.',
            '<$MTEntryEditLink$>' ));
    my $blog_id = $entry->blog_id;
    my $cfg = MT::ConfigMgr->instance;
    my $url = $cfg->AdminCGIPath || $cfg->CGIPath;
    $url .= '/' unless $url =~ m!/$!;
    require MT::Permission;
    my $perms = MT::Permission->load({ author_id => $user->id,
                                       blog_id => $blog_id });
    return '' unless $perms && $perms->can_edit_entry($entry, $user);
    sprintf
      q([<a href="%s%s?__mode=view&_type=entry&id=%d&blog_id=%d">Edit</a>]),
      $url, $ENV{MOD_PERL} ? 'app' : 'mt.cgi', $entry->id, $blog_id;
}

この mt.cgi の部分も合わせて変更しておかないと、 <$MTEntryEditLink$> で生成されるアンカーは mt.cgi のままです。

しかし、合わせて変更しておくということは、攻撃者が Movable Type 内を検索して、 <$MTEntryEditLink$> で生成されたアンカーを発見してしまう可能性を生じさせるということなのです。 mt.cgi のファイル名変更対策を行う場合は、 /Install directory/search_templates/default.tmpl 内の <$MTEntryEditLink$> の記述自体を削除するようにしてください。

<MTSearchResults> 内に表示されるアンカーは、 ブラウザ側のCookie を読み取り、ログイン済みならば表示させる、という処理 が行われているようですので、 <$MTEntryEditLink$> の記述自体を削除する必要はないかもしれません。

なお、 EntryEditLink plugin というプラグインを使えば、検索テンプレート以外でも <$MTEntryEditLink$> を使えるようになりますが、攻撃者に対して mt.cgi の新しいファイル名を自ら教えていることになりますので、この脆弱性に対する対策を取るならば使用しないようにしてください。

どうしても <$MTEntryEditLink$> の機能を使用したい場合は、 brain-dump.com - Frontend Editing for MovableType で配布されている AdminLinks Plugin を使用するようにしてください。

Edit アンカーの撤去

実は、ちょっと発想を変えれば前述の <$MTEntryEditLink$> はプラグインなど使わずとも実現できます。 実際に私は以前のサイトで同じようなことを書いていましたが、ARTIFACT ―人工事実― | MovableTypeの記事修正を楽にするなどで紹介されている方法がこれにあたります。

<a href="<$MTCGIPath$>mt.cgi?__mode=view&_type=entry&id=<$MTEntryID$>&blog_id=<$MTBlogID$>">Edit</a> とテンプレート内に記述することで、プラグインを使わずに <$MTEntryEditLink$> を実現できるのですが、これも攻撃者に対して mt.cgi の新しいファイル名を自ら教えていることになります。

前項と同様に、どうしても <$MTEntryEditLink$> の機能を使用したい場合は、 brain-dump.com - Frontend Editing for MovableType で配布されている AdminLinks Plugin を使用するようにしてください。

スクリーンショットにも注意を

Movable Type の手順解説などを書く場合、自分の Movable Type をサンプルとしてスクリーンショットを掲載しているケースはよく見られます。 ( MT hxxks もその一部です。 ) このときに、アドレスバーの URI を隠しておかないと、攻撃者に対して mt.cgi の新しいファイル名を自ら教えていることに繋がってしまいます。

Latest Entry Redirect Template の記事において、スクリーンショットのアドレスバーを処理していたことに気付いた方はおられたでしょうか ? このように、システム外のところにも気をつけておかないと、自らセキュリティホールを作り出してしまいます。

簡単なまとめ

Movable Type をベースに説明してきましたが、これは Movable Type に限った話ではありません。 それぞれがツールの特性を知った上で、自衛する必要があります。

この脆弱性の怖いところは、ユーザーに悟られることなく罠を仕掛けることができ、かつ罠自身は攻撃を仕掛けない、というところです。 サーバをクラックするわけでもなく、ウィルスやバックドアなどを仕込むわけでもありません。 ユーザー自身のブラウザによって改竄が行われるのです。 Phishing 詐欺ならぬ Phishing アタックとでも言えるかもしれません。 クリックしたら最後、 weblog が綺麗さっぱり消去されてしまったということもあるかもしれません。

あまり危機感のみを煽るのもよくありませんが、かと言って根拠なく安心しているわけにもいきません。 多くの人がこの問題に関心を持ち、それぞれ自衛するなりツールやサービスのシステム自身の改善を要望するなりしてくれることを望みます。

リプライ

20 件のリプライが送られています。 この記事に対するご意見やご質問、ご感想などありましたら個別記事ページの送信フォームからお送り下さい。

2004-10-25T00:07+09:00 - 自分メモ:mt.cgiのファイル名変更とapp.pmの編集 < Studio-HYG

MTのアップグレードついでに,MT hxxksのMT をインストールしたら真っ先...

2004-10-25T16:44+09:00 - MTのセキュリティ対策

MTをインストールしたら真っ先に行うべきセキュリティ対策に怖いことが書いてあったのでちょっと対策してみました。

2004-10-27T11:43+09:00 - MT をインストールしたら真っ先に行うべきセキュリティ対策 < 日々更新中

MT をインストールしたら真っ先に行うべきセキュリティ対策なる頁発見。ふーん、なるほどなるほど。 うちの頁の場合、index頁に%lt;a href="./mt/mt.cgi" $gt;Login$lt;/a$gt;なんて書いてあってバレバレでした。 そんでmt.cgiを適当にわかりにくい名前に変更。そしてLogi...

2004-10-28T01:23+09:00 - MTのセキュリティ対策 < のまのしわざ

MT3.1 mod_perlでググッたらこんなサイトを見つけました。丁度セキュリティ対策をどうしたらいいのか考えていたところなので、凄く勉強になりました。近いうちになんらかの対策をしなきゃ・・・ MT hxxks - MT をインストールしたら真っ先に行うべきセキュリティ対策MT を...

2004-11-01T23:00+09:00 - MT で CSRF

ちょいと Movable Type の話をしていて yuuさん (w3j.org) に教えていただいたのですが、Movable Type には CSRF攻撃の問題があるみたいですね。「MT をインストールしたら真っ先に行うべきセキュリティ対策 (hxxk.jp) 」 しかし、ちゃんと CSRF という名前があるのに�...

2004-11-02T00:26+09:00 - MT の脆弱性? < ogaoga's blog

MT hxxks - MT をインストールしたら真っ先に行うべきセキュリティ対策 これを見てびっくり。とりあえず、Basic 認証をかけてみたけど、それて対策になるのかなぁ......

2004-11-06T03:47+09:00 - MovableType利用者が真っ先に行うべきセキュリティ対策 < IGALOGる

この内容はもうちょっと広く知られておくべき記事です。MT hxxks - MT ...

2004-11-11T00:03+09:00 - MTのセキュリティ < ●●●ForAmusement●●●

全く別の問題の解決策を探していて見つけたのですが どうやら対策しておくに越したこ...

2004-11-14T01:07+09:00 - ウェブログを削除するリンク < nlog(n)

自分のウェブログを削除するリンクが作れる。そのリンクは、個別記事に置いておくと便利な「編集リンク」と同じような形をしていて、どこにでも置くことができる。「トラックバックをたどって行ってみると、知らないうちに自分で自分のウェブログを削除していた」、そんな...

2004-12-29T16:11+09:00 - CSRF - クロスサイトリクエストフォージェリ < Preview

CSRFの概略  CSRFはCross Site Request Forgeriesの略です。  恥ずかしながら私は最近こういったこういった攻撃方法があることを知りました。日頃のアンテナの低さがバレますね。  CSRFはサイトに対する正規のユ...

2005-01-20T22:47+09:00 - MT/MTでもセキュリティ対策が必要!? < kankichi@blog:SAKURA edition

MTのカスタマイズをしていくうちに、MT hxxks:"MTをインスト...

2005-02-03T15:21+09:00 - MovableTypeセキュリティ問題 < SAKSAK RECORDS WEB SITE

MT hxxks - MT をインストールしたら真っ先に行うべきセキュリティ対策...

2005-02-18T21:19+09:00 - MTへの修正 < ゑBLOG

MT-3.151が出たようなのでアップグレードしようと思ったんですが、その前に現状のMTに入れた修正点をメモしておきます。

2005-02-23T13:44+09:00 - MTをインストールしたら… < S-log : 慎悟のマイナス思考ログ

すごく今更ながらですが、取り急ぎメモ。 MT hxxks - MT をインストールしたら真っ先に行うべきセキュリティ対策 水無月ばけらのえび日記さんの過去日記より。...

2005-04-19T01:11+09:00 - takato

Version 3.151-ja を使っています。 <$MTEntryEditLink$>を使うために /Install directory/lib/MT/App/Search.pmを書き換えようと思っていますが、 該当の文字列が見当たりません。 526行目から同名のサブルーチンがありますが、 バージョンアップにともないSearch.pmが変更に なったようです。 どのように変更したらよいのかご教授いただけると幸いです。

2005-05-02T00:35+09:00 - 真琴

すみません、お返事が遅れました。ご質問のあたりも含めてこの記事は全面改訂しようと思いつつ、ちょうど多忙な時期と重なってしまいました。 さて、ご質問の件ですが、 MT 2.x の Search.pm で mt.cgi と指定している部分は MT 3.x では $cfg->AdminScript となっています。 これは設定ファイル ( mt.cfg ) の AdminScript の値を参照しているので、 mt.cfg の # AdminScript mt.pl と書いている行のコメントを消して ( 先頭の # と半角スペースを削除 ) 、mt.pl の部分を mt.cgi から変更した後の名前に変えれば良いと思います。 ( 私は <$MTEntryEditLink$> を使わないので、実際に試してはいませんが。 )

2005-05-12T20:59+09:00 - セキュリティ情報(Movable Type) < Kyan's BLOG II

Movable Type Publishing Platform: 【重要】 第三者による不正アクセスを許す危険性の対策について ユーザ各位は対応をどうぞ。 当方では Movable Type Technotes: 盗聴によるパスワードやCookieの漏洩...

2005-05-13T01:17+09:00 - Movable Typeの脆弱性 発覚! < 新妻blog(もう新妻じゃないけど)

とうとう出ちゃいましたよ:14: 【重要】 第三者による不正アクセスを許す危険性...

2005-05-13T07:16+09:00 - 【緊急】【その他の対策】 第三者による不正アクセスを許す危険性の対策について < *mt3::MRU

 だいたいのMovableTypeユーザの方ならご存知かと思いますが、致命的なセキュリティホールがあることが確認されました。  パッチが早々に公開されるとは思いますが、それまでの応急処置が公式で発表されています。なお、拙ブログでは公式とはまた違ったアプローチでの応...

2005-05-13T10:37+09:00 - MT3.X日本語版全てに不正アクセスの脆弱性! < fromshun.

MTの管理画面の右はじにこんなアナウンスが。 【重要】 第三者による不正アクセ...

ニュースソースとしての記事の考察

記事データ

投稿者

望月真琴

投稿日時

2004-09-09T01:19+09:00

タグ
概要

PC 総背番号制がニュースサイト等で紹介され、多くのアクセスを記録しました。被リンクという観点から考察してみようと思います。多くのサイトに紹介されてびっくり半分嬉しさ半分。

リプライ

リプライはまだありません。

記事本文

自分は触れないだろうと思っていたアクセスネタ

普段はアクセス数の推移などは気にしませんが、今回は色々な考察ができそうなことになったので気にしてみることにします。

9 月 7 日から、 PC 総背番号制がニュースサイト等で紹介され、多くのアクセスを記録しました。 今日は被リンクという観点から考察してみようと思います。

紹介元サイト別アクセス数

2004-09-07T00:00:00+09:00 から 2004-09-07T23:59:59+09:00 の間に、 /memo/ ディレクトリに対して 5776 件のユニークアクセス、重複を含めると 6919 件のアクセスがありました。 なお、 URI の直接入力やブックマークを除外して、リンク元を取得できた件数は 5026 件です。 このうち、検索やリファラ誤爆を除いたリンク元を集計してみます。

  1. 電脳遊星D - 2724 件
  2. カトゆー家断絶 - 1365 件
  3. RinRin王国 - 488 件
  4. 驚異の新技術「個人識別コード」 はカウンターぽいが、whois検索で問題のドメイン登録者情報が見つかる::[アキバBlog] - 220 件
  5. ARTIFACT ―人工事実― | 驚異の新技術「個人識別コード」 - 29 件
  6. 日記 - 4 件
  7. VK45 - 3 件

ここで、上位 2 サイトに着目してみましょう。 それぞれのサイトの同日のアクセス数は分かりませんが、 [ReadMe!] Daily Report (1/50) を見てみると、 集計期間: 9/7 21:00:00〜 9/8 21:00:00 において、カトゆー家断絶が 30434 件、 電脳遊星D ( ランキングページでは「それゆけ!!だよもん星」という名称 ) が 12681 件というアクセス数になっています。

これを単純に比率で表すと、カトゆー家断絶では 1365 / 30434 * 100 ≒ 4.485% という IN/OUT 比になり、電脳遊星D では 2724 / 12681 * 100 ≒ 21.481% という IN/OUT 比になります。 私のアクセスログ集計期間と ReadMe! JAPAN の集計期間が異なりますし、紹介の仕方によってもアンカーをクリックする・しないの確率は変動しますから、この 2 つの IN/OUT 比はかなり誤差が含まれることになりますが、一回の更新で紹介するニュースの数が IN/OUT 比に影響を与えているのだと推測できます。

PC 総背番号制が紹介された日付の電脳遊星D の記事紹介数は 17 件、カトゆー家断絶の記事紹介数で 166 件となっています。 ひとつのサイトでひとつのアンカーしかクリックできないというルールはありませんから、単純に電脳遊星D の IN の 1/17 や、カトゆー家断絶 の IN の 1/166 が PC 総背番号制への OUT になることはありません。 しかし被リンクを受ける側からすれば、同時に紹介される記事が少ない方がより多くのアクセスを得られる結果になります。 ( ただし、紹介記事が多いニュースサイトは、そのサイト自体が多く閲覧される可能性も高いので、紹介記事が少なければ即ち良いニュースサイトであるということではありません。 )

記事の伝播ルート

アクセスログを調べると、 2004-09-07T00:19:56+09:00 に記録された http://planet-d.hp.infoseek.co.jp/ をリンク元とするアクセスが、一連のアクセスの最初のもののようです。 それ以前までは、 PC 総背番号制からトラックバックを行っていた ARTIFACT ―人工事実― | 驚異の新技術「個人識別コード」からのアクセスしかなかったため、最初の紹介元は電脳遊星D と考えて良いでしょう。

これ以降、上記の集計にあるサイトを調べてみると、以下のような記事の伝播が行われていることが分かりました。 ニュースソースを明記しているところを抽出し、そのニュースソースを直接の親とするツリー図です。

こうしてみると、ニュースサイト界隈 (?) は色々な所をニュースソースにしているのだな、と思いました。 私はふだんニュースサイトを見ずに、自分のお気に入りのブックマークなどで気になる話題があった場合にそれを取り上げる程度で、積極的にネタ探しをしないので勉強になりました。

今回の PC 総背番号制も、たまたま ARTIFACT ―人工事実―を見て 「何これ、ブラウザ変えたら個人識別番号変わるじゃない」 と思って突っ込みを入れたという次第。 通常は Movable Type をいじくった際の記録などをちまちまと書いているため、こうして多くのサイトに紹介されてびっくり半分嬉しさ半分といったところでしょうか。

リプライ

リプライはまだ送られていないか、管理者の承認待ち状態です。 この記事に対するご意見やご質問、ご感想などありましたら個別記事ページの送信フォームからお送り下さい。

Null またはオブジェクトではありません

記事データ

投稿者

望月真琴

投稿日時

2004-09-07T23:58+09:00

タグ
概要

Individual Entry Archive にてスクリプトエラーが生じています。時間のあるときにスクリプトの記述をもう一度洗いなおしてみようと思いますが、それまではスクリプトエラーが出たままになることをご容赦ください。

リプライ

リプライはまだありません。

記事本文

IE 6.0 で起こっている現象なんですが、 Individual Entry Archive にてスクリプトエラーが生じています。

'author' は Null またはオブジェクトではありません。

JavaScript をほとんど勉強したことがないのに、 Movable Type の標準テンプレートの JavaScript の記述を変更してしまったのが原因なのでしょうか。 一応エラーの意味を調べてみたのですが、実際の HTML 中にその変数が記述されていないといったもののようです。 ( もしかしたらその解釈が大きく間違っているかもしれません。 )

<form method="post" action="<$MTCGIPath$><$MTCommentScript$>" onsubmit="rememberMe(this)">

  <p><input type="hidden" name="static" value="1" /><input type="hidden" name="entry_id" value="<$MTEntryID$>" /></p>

  <dl>

    <dt><label for="comment-author">Name</label></dt>
    <dd>
    <p>
    <input id="comment-author" name="author" size="30" tabindex="1" value=" " />
    </p>
    </dd>

    <dt><label for="comment-email">Mail address</label></dt>
    <dd>
    <p>
    <input id="comment-email" name="email" size="30" tabindex="2" value=" " />
    </p>
    </dd>

    <dt><label for="comment-url"><abbr title="Uniform Resource Identifier">URI</abbr></label></dt>
    <dd>
    <p>
    <input id="comment-url" name="url" size="30" tabindex="3" value="http://" />
    </p>
    </dd>

    <dt><label for="comment-text">Comment</label></dt>
    <dd>
    <p><textarea id="comment-text" name="text" rows="7" cols="50" tabindex="4">コメント本文の入力は必須となっています。</textarea></p>
    </dd>

  </dl>

  <p>
  <input id="button-preview" type="submit" name="preview" value="Preview" />
  <input id="button-post" type="submit" name="post" value="Post" />
  </p>

</form>

form 要素周りのテンプレートの記述はこのようにしていますので、 author の書き忘れやスペルミスという線はないと思うのですが……。

ちなみに head 要素で読み込む JavaScript の記述は別ファイルに書いて script 要素で読み込んでいます。 ( /appendix/comments.js ) スクリプトの内容は Code-404 のものを勝手に参考にさせていただいています。

というかほとんど丸写しであり、 Code-404 でエラーが出なくて、 hxxk.jp で出るという時点でエラーの原因がつかめていないのが現状です。 時間のあるときにスクリプトの記述をもう一度洗いなおしてみようと思いますが、それまではスクリプトエラーが出たままになることをご容赦ください。

2005-05-11T00:35:42+09:00 時点ではデフォルトのスクリプトに戻しています。

リプライ

リプライはまだ送られていないか、管理者の承認待ち状態です。 この記事に対するご意見やご質問、ご感想などありましたら個別記事ページの送信フォームからお送り下さい。

Latest Entry Redirect Template

記事データ

投稿者

望月真琴

投稿日時

2004-09-07T21:28+09:00

タグ
概要

最新の Individual Entry Archive へリダイレクトする .htaccess テンプレートの作り方をスクリーンショット付で解説しています。

リプライ

リプライはまだありません。

記事本文

このテンプレートの意味

index に最新記事を配置することのメリットとデメリットであれこれ考察をしましたが、じゃあ実際に index に最新の記事を配置しないということを実現するにはどうすればいいのさ、というお話です。 Movable Type での手法ですが、 weblog ツールによっては同じような手法を取ることができるかもしれません。 なお、このテンプレートを使った手法は、 .htaccess をサーバ上に置くことができることが前提となっています。 よって、 apache サーバにて Movable Type を使用していることが必須条件となります。

考え方としては、 latest.html などといった最新の記事を表す URI を index からナビゲートし、そのリクエストに対して Redirect で最新の Individual Entry Archive の URI を返す、というものです。 ここでは、 hxxk.jp の構成を基にテンプレートのコードを紹介します。

とりあえず現時点での最新記事に Redirect

hxxk.jp は、 /public_html/ を weblog のルートとして公開しています。 この記事を書いている段階での hxxk.jp の最新の記事は http://hxxk.jp/2004/09/06/2148 ですので、 latest.php にリクエストがあった際には、この URI を返せば最新記事へリダイレクトしたことになります。

Redirect seeother /latest.php http://hxxk.jp/2004/09/06/2148

.htaccess にこのように記述することで、 http://hxxk.jp/2004/09/06/2148 を最新記事としてリダイレクトできます。 ( 最後に改行コードを記述するのを忘れないようにしてください。 )

しかし、これでは私が新たな記事を書くたびに、先頭の / よりも後ろの部分、ここでは 2004/09/06/2148 の部分が変化することになります。 そのたびに .htaccess を書き換えていたのでは、 Movable Type を使っている意義が薄れてしまいます。 そこで、なんとかこれをテンプレートにして自動化できないものかと考えました。

実際のテンプレートの作成方法を以下に示します。 なお、 Movable Type のバージョンは 2.661 で、 Milano::Monolog: 日本語化パッチで公開されている MovableType2.661 日本語化パッチを適用したものとして説明しています。 ( Movable Type 3.x をお使いの場合は適宜読み替えてください。 )

Redirect Template

  1. スクリーンショット Template の編集をクリックします。
  2. スクリーンショット 新しいインデックス・テンプレートを作るをクリックします。
  3. スクリーンショット テンプレートの名前を Redirect ( これは一例です。お好きな名前にしていただいて構いません。 ) にし、出力ファイル名を .htaccess にしてください。 インデックス・テンプレートを再構築するときにこのテンプレートを自動的に再構築するにチェックを入れてください。
  4. スクリーンショット テンプレートの中身を以下のように記述します。
    Redirect seeother /latest.php <MTEntries lastn="1"><$MTEntryPermalink$></MTEntries>
    
  5. スクリーンショット 保存をクリックします。
  6. スクリーンショット スクリーンショット インデックスをリビルドして完成。

以上の手順を終えた時点で、 FTP で直接 .htaccess ファイルを確認してください。

Redirect /latest.php http://hxxk.jp/2004/09/06/2148

このように、その時点での最新記事へリダイレクトするような記述になっているはずです。 あとは index から、この latest.php に対して適切なナビゲーションを行うようにしてください。 なお、サーバ上に実際に latest.php を配置しておく必要はありません。

なお、 AddType や Options などの、その他の .htaccess ディレクティブを指定している場合は、一緒にテンプレートの中身に記述してください。 既にローカルで .htaccess を作成してサーバ上に put していた場合、リビルド時にその内容が上書きされて失われてしまいます。

リプライ

リプライはまだ送られていないか、管理者の承認待ち状態です。 この記事に対するご意見やご質問、ご感想などありましたら個別記事ページの送信フォームからお送り下さい。

index に最新記事を配置することのメリットとデメリット

記事データ

投稿者

望月真琴

投稿日時

2004-09-06T21:48+09:00

タグ
概要

index に最新記事を配置することによる実質的なメリット・デメリットを挙げてみて考察。自分が使っている weblog ツールや weblog サービスの設計は自分が納得のいくものであるのか、 index における記事配置という側面から、この記事がそういったことを考えるきっかけになってくれるといいな、と思います。

リプライ

リプライはまだありません。

記事本文

前回との違い

前回の index に最新記事を配置するということでは、 weblog ツールや weblog サービスの HTML の構成についてや、設計思想についてメタ的なことを書きました。 インデックスをインデックスとしてなんていう大仰な言い方をしていますし。

今回は、 index に最新記事を配置することによる実質的なメリット・デメリットを挙げてみて考察してみようと思います。 始めに断っておきますが、 index に最新記事を配置することが良いとか悪いとかを論じるつもりはありません。

なお、以下の考察は一般的な weblog サービスの構成 ( アカウントのルートディレクトリの index に最新の数件の記事を配置、カレンダーや「最近の過去ログ」のようなナビゲーションがサイドバー的に表示されるもの ) を基に行っています。 それそれお手持ちのブックマークから、ココログgoo BLOGlivedoor BLOG などを使用しているサイトを開いておくと分かりやすいかもしれません。

index に最新記事を配置する場合のメリット

閲覧者が戸惑いを感じることが少ない

前回の index に最新記事を配置するということで示した通り、 weblog ツールや weblog サービスを使用しているサイトのほとんどが同じような構成をしています。

確かにウェブログツールを使うと構成が画一化してしまって、それは利用者にしてみれば大きく迷わなくてよいこともあるんですけど、今のトップに最新記事というのはちょっと否定的で、まぁそれは置いておくとしてもユーザーが表示の仕方を(それこそラジオボタンみたいなので)選べるようになればいいなと思ってます。

leva さん ( Software Linkage | Linkage Note! ) がこう述べられている通り、画一化された構成というのは、ユーザーがそれに慣れてしまえば利便性という面で大きなメリットになります。 違うツールやサービスのものであっても、だいたい同じような位置に同じようなナビゲーションが配置されていれば、初めて見るサイトでも特に戸惑いを感じることはないでしょう。

ただし、これはあくまで現時点でのツールやサービスが index に最新記事を配置しているから成り立つメリットであって、今後の動向によってはメリットでなくなる可能性があります。 その時こそ、 ユーザーが表示の仕方を(それこそラジオボタンみたいなので)選べるように なっているものが大きな利便性を発揮するのかもしれません。

閲覧者が常に最新の記事を読むことができる

weblog の流行により、各個別記事に対して直接リンクを行うケースが増えています。 しかし、記事に対してリンクを行うのではなく、そのサイト全体を紹介するという意味でリンクを行う際は、トップページに対してリンクを行うケースもあるでしょう。 そういった場合に、そのサイト内で最も新しい話題を直接 ( = アンカークリック等の手間をかけさせずに ) 閲覧者に提供することができるというのは、時系列で記事が並べられることの多い weblog では、メリットと言えるでしょう。

index に最新記事を配置する場合のデメリット

検索エンジンの検索結果と齟齬が生じる

index に最新記事を配置する、それは言い方を変えれば記事が追加される度に index の内容が変化するということです。 たとえば、私がこの記事を書いている時点で関心の高い話題、台風 18 号について各 weblog を検索してみましょう。 ( Google 検索: weblog 台風18号)

そして、私が行った検索結果 ( weblog 台風18号 の検索結果 約 16,800 件中 1 - 10 件目 (0.21 秒) ) のうち、 index に最新記事を配置している weblog のみを抽出してみます。

このうち、デジタル台風:ニュース・ウェブログは正に台風の情報のみを掲載しているので、後日同様の検索を行っても台風の情報が得られるでしょう。 しかし、他の 3 つの weblog については色々な種類の記事がある中で台風 18 号について書いており、それが検索にひっかかったのだと思われます。 そして、その記事は数日後には index から消え、各個別記事ないし時系列アーカイブ・カテゴリ別アーカイブの中に存在するようになるでしょう。

検索エンジンのキャッシュ機能を使えばその記事を目にすることはできますが、逆にその機能を使わなければ、既に index から消え去った記事を求めてサイト内を探し廻らなければなりません。 もちろん個別記事ないし時系列アーカイブ・カテゴリ別アーカイブは存在していますし、それが検索にひっかかることもあるでしょうが、 ( 記事追加ごとに内容が変化する ) index もひっかかってしまうというのが現状です。

Blogless Google というものも作られています。 ウェブログの記事が大量のノイズになってしまい、困っている人がいるため作った物である と述べられており、 これからの検索エンジンは、比較的きちんとしたHTMLで、複数ドメインから相互にリンクを張り合う、「マイ・ウェブログ」がWWWに溢れかえることを念頭に検索システムを設計しなければならないだろう という但し書きを添えた上で、 weblog の記事が検索結果のノイズになってしまっていることを作成の動機として挙げられています。

これは記事の質を取り上げてノイズだと述べられていますが、ものの数日で index から記事が消えてしまう構成になっているものも、検索エンジンにとってはノイズだと言えるのかもしれません。 それならば、記事は記事として permalink を持ったものだけを作成して index からナビゲートする方が、検索にヒットした時にそのページから記事が消失しているといった事態を防げて良いと思います。

index の記事に対する直前の記事が分かり辛くなる

これは weblog ツールや weblog サービスの設計上の問題かもしれません。

たとえば、最新 3 日分の記事をインデックスに配置している weblog があるとします。 閲覧者はその 3 日分を読み終えて、それ以前の記事を読みたいと思ったとき、それを直接辿ることができるケースはそう多くありません。 統計をとったわけではありませんが、カレンダーなり月次アーカイブへのリンクなりを辿って、比較的直近の過去ログを類推して探すケースが多いようです。

私は、前回の index に最新記事を配置するということでこう述べました。 weblog サービスでは、はてなダイアリーDiary Notegoo BLOG などは、 <前の3日分<前のページ といったナビゲーションを用意しています。

逆に、それが用意されていない場合は、カレンダーなどのナビゲーションから探さねばなりません。 これが意外と非効率だと思うのは私だけでしょうか ?

ちなみに、 weblog ツールにもこういった機能を備えているようなものはあまり多くないと思います。 Movable Type 2.x では、 lastn 属性と offset 属性を組み合わせてテンプレートを修正しないと実現できません。 ただし、やはり自分好みに (?) カスタマイズしている方の中にはこういったナビゲーションを用意している方もおられます。 index に最新記事を配置するということ - weblog ツールのアカウントルート調査で調査したサイトを見回してみると、以下のようなケースが見られました。

Junkline

>> More... という、最新の月次アーカイブにリンクしているアンカーを準備

コル

« mona records、加藤千晶、ロムチアキ、ラーメン

2004年09月のタイトル一覧

という、 index に配置されている記事のうち一番古いものの一つ前の記事へリンクしているアンカーと、最新の月次アーカイブにリンクしているアンカーを準備

( « mona records、加藤千晶、ロムチアキ、ラーメン というアンカーテキストは調査時のもの )

いぬ日記

《前の週2004年08月27日(金) このあたりを含む七日間分 という、最新の週次アーカイブにリンクしているアンカーと、 index に配置されている記事の日付の付近の七日間分を含む週次アーカイブへリンクしているアンカーを準備

( 《前の週2004年08月27日(金) というアンカーテキストは調査時のもの )

CornerValley

≪ 6-10 | 1-5 という、 index に配置されている記事と同じ数の分の直近の過去ログへリンクしているアンカーを準備

Daily Resource

前の月 という、最新の月次アーカイブにリンクしているアンカーを準備

Note @ Temporary-Depot

Go to next page »

Default page

という、 index に配置されている記事と同じ数の分の直近の過去ログへリンクしているアンカーを準備

煤 - Note

< - 1 --- 1 - 2 - 3 - 4 - 5 - 6 - 7 --- 49 - > という、 index に配置されている記事と同じ数の分の直近の過去ログへリンクしているアンカーを準備

( < - 1 --- 1 - 2 - 3 - 4 - 5 - 6 - 7 --- 49 - > というアンカーテキストは調査時のもの )

こういったナビゲーションが用意されていれば、 index に配置された記事を読み終えても、そのサイトの他の記事も読もう、という気になります。 逆に、カレンダーなどから辿らねばならない場合は、 index に配置された記事だけ読んで「もういいや」と感じて他のサイトに移ってしまうことがよくあります。 これは私の偏見かもしれませんが。

一長一短 ?

長々と述べてしまいましたけど、これが正解だ、というものはないと思います。 それぞれメリットがありますし、それぞれデメリットがあります。

hxxk.jp ドメイン内の各 weblog は index に最新記事を配置していませんが、閲覧者によっては戸惑う方もおられるかもしれませんし、トップページからリンクアンカーを辿る回数が多くて煩わしいと思う方もおられるかもしれません。 私なりに使いやすい設計をしてみたつもりではありますが、それも主観によるものですし、全ての人が納得のいく設計というものは実現できません。 ( それでも一人でもより多くの人が使いやすいと思える形を追求するべきであるとは思います。 )

ただ、自分が使っている weblog ツールや weblog サービスの設計は自分が納得のいくものであるのか、 index における記事配置という側面から、この記事がそういったことを考えるきっかけになってくれるといいな、と思います。

リプライ

リプライはまだ送られていないか、管理者の承認待ち状態です。 この記事に対するご意見やご質問、ご感想などありましたら個別記事ページの送信フォームからお送り下さい。

PC 総背番号制

記事データ

投稿者

望月真琴

投稿日時

2004-09-05T18:00+09:00

タグ
概要

PC個別に割り当てられている個人情報を特定可能な次世代コードだそうですが、そんな技術は未だ実現していません、仮にこのページにアクセスしてしまったとしても何ら恐れることはありません。しかし、場合によっては問題になる可能性がありますので、ARTIFACT ―人工事実― | 驚異の新技術「個人識別コード」で、該当ページに a 要素でのアンカーを記述しているのは無用な損害を引き起こす可能性があるのではと思いました。

リプライ

5 件のリプライがあります。

記事本文

突っ込み所が多すぎる次世代コード

ARTIFACT ―人工事実― | 驚異の新技術「個人識別コード」で知ったネタ。 いつの間にか日本は超情報統制社会になっていたようです。 年金番号や住民基本台帳ネットワークによる国民総背番号制なんて目じゃない、 PC 総背番号制の始まりです。

ARTIFACT ―人工事実― | 驚異の新技術「個人識別コード」で紹介されていたアンカーをクリックすると、以下に引用したような内容が表示されました。

★Angel-net に登録ありがとう★

個人識別コード

あなたのプロバイダーは ***** です。 個人識別コード ********** を登録いたしました

個人識別コードはPC個別に割り当てられている個人情報を特定可能な次世代コードです

ご利用期間

60日間

ご利用料金

\15000

振込先

UFJ銀行 新大阪支店 普)3599970 ミヤガワミノル

支払期限

登録日より4日以内

注意

支払期限以内にお振込み下さい。 また、支払い期限を過ぎても入金確認が出来ない場合、 規約に基づき個体識別番号をもとに住所、氏名、電話番号をお調べし当番組管理部より延滞料金30,000円、延滞1日に付き1,000円の損害金を加算してご自宅、ご実家、勤務先などに直接請求されることがあります。

あなたの払込みID番号は ********** です。 ご不明な点は、再度利用規約のページをご参照ください。

さて、これらに突っ込みを入れてみましょう。 その行為自体が無粋だという突っ込みは受け付けません。

あなたのプロバイダーは ***** です。

そんな事は私が一番知っています。 アクセスしてきたクライアントのリモートホストを表示するというのは、覚えたての技術を誇示したいのでしょうか。

個人識別コードはPC個別に割り当てられている個人情報を特定可能な次世代コードです

いつの間にインターネットの技術は革新したのでしょう ? 仮にそういった技術が実現できたにしても、それを活用するとなると種々の問題が発生し、大きな反発を呼ぶと思いますが。

IPv6 の普及で、家電などにも IP アドレスの割り当てがなされるという動きがありますから、それと勘違いする人はいるかもしれません。 また、 MAC アドレスは工場出荷時に個別に割り当てられるので、 PC個別に割り当てられていると言えるかもしれませんが、それがどの消費者の手に渡ったかを管理・識別しているわけがありません。

そして、ほぼ同時刻に同一の PC から同じ IP でアクセスしているのに、 IE と Firefox と Opera でアクセスした時にそれぞれ違う個人識別コードが表示されるのは何故ですか ? 個人どころか UA の識別すらできていないじゃないですか。 PC に個別に個人情報が割り当てられているなら、ブラウザを変えたくらいで個人識別コードを取り違えないでください。

支払い期限を過ぎても入金確認が出来ない場合、 規約に基づき個体識別番号をもとに住所、氏名、電話番号をお調べし当番組管理部より延滞料金30,000円、延滞1日に付き1,000円の損害金を加算
(消費者が支払う損害賠償の額を予定する条項等の無効)

第九条 次の各号に掲げる消費者契約の条項は、当該各号に定める部分について、無効とする。

  1. 当該消費者契約の解除に伴う損害賠償の額を予定し、又は違約金を定める条項であって、これらを合算した額が、当該条項において設定された解除の事由、時期等の区分に応じ、当該消費者契約と同種の消費者契約の解除に伴い当該事業者に生ずべき平均的な損害の額を超えるもの 当該超える部分
  2. 当該消費者契約に基づき支払うべき金銭の全部又は一部を消費者が支払期日(支払回数が二以上である場合には、それぞれの支払期日。以下この号において同じ。)までに支払わない場合における損害賠償の額を予定し、又は違約金を定める条項であって、これらを合算した額が、支払期日の翌日からその支払をする日までの期間について、その日数に応じ、当該支払期日に支払うべき額から当該支払期日に支払うべき額のうち既に支払われた額を控除した額に年十四・六パーセントの割合を乗じて計算した額を超えるもの 当該超える部分

消費者契約法にはこのように定められています。 支払い期限が過ぎてから起算して、一年間支払いをしなかった場合、延滞料金 30,000 円 + 損害金 1,000円 * 365日 = 395,000 円が加算されることになります。

これを年利として計算しなおすと、 395000 / 15000 * 100 = 2633.33333...% になります。 法で定められた利率の約 180 倍ですね。

まあ、よくある架空請求と同じようなものです。 前述の通り、個人情報を特定可能なわけがありませんので、仮にこのページにアクセスしてしまったとしても何ら恐れることはありません。

だからと言って安易にクリックして良いわけではない

ただし、職場などからの接続の場合は話が別です。 個人は特定できなくても、リモートホストから組織を特定できる可能性は充分にありますし、場合によってはそういったページにアクセスしたという事実が知られるだけで問題になる組織もあるでしょう。 ( *.go.jp など ) 多少頭の回る架空請求業者なら、そういった組織のアクセスを確認した場合に、法に触れるか触れないかのスレスレのところで金銭の要求をしてくる可能性がありますので注意してください。 ( そういった組織の場合は、金銭の要求がなくても、アクセスした当人の危機管理意識が問われることになると思いますが。 )

そういった意味では、 ARTIFACT ―人工事実― | 驚異の新技術「個人識別コード」で、該当ページに a 要素でのアンカーを記述しているのは無用な損害を引き起こす可能性があるのでは……と思いました。 ( もちろん、アンカーをクリックする・しないは当人の自己責任ですが。 ) ARTIFACT ―人工事実― | 驚異の新技術「個人識別コード」で、該当ページに a 要素でのアンカーが記述されていましたが、現在は単なる文字列に修正していただいています。

天罰覿面。

ARTIFACTの記事のリンクを開いたら、「個人識別コード」をばつちりとられてしまひましたよ。 職場のパソコンからでもおれが誰か特定されてしまふのか〜〜〜。 上司とかにバレたらどうしよう。

懸念していたことが現実に。 佐藤 俊さん ( DIVE ) の会社がどういった性質の会社であるかにもよるでしょうけど、実際に会社相手に請求をしてくるとは考え難いです。 実際に請求をせずとも、不安から自発的に振込みをする人が居るから成り立っている詐欺ですし。 延滞料金や損害金が法を逸脱した利率であり、実際に請求があったとしても国民生活センター内の、NCAC: 悪質な「利用した覚えのない請求」が横行していますNCAC: 全国の消費生活センターを参考にして毅然とした対応を取られれば、業者側も粘ろうとはしないでしょう。 一人に固執するよりも、投網のように広範囲をターゲットにして、取りやすいところから取ろうとするはずです。

この Angel-net という業者に限らず、同様の手口のものがいくつか存在するようです。 ( Google 検索: 個人識別コード ) 同じように請求をされても毅然と対応するか、無視をすれば良いだけです。

しかし、金銭目的ではない模倣犯が現れたらどうでしょうか ? リモートホストを表示するようなページを作成するのに、そう深い知識は必要ありません。 そして、大企業や公的機関からアクセスがあった場合に、その行為自体をあげつらう目的で似たようなページを作る人間が出てこないとは限りません。 それが、前段の「どういった性質の会社であるかにもよる」と述べたもうひとつの理由です。

特に公的機関の場合はドメインであっさりと機関が分かりますので、集中して狙われるかもしれません。 もし私がこういった詐欺を行うなら、法外な利率を設定するよりも、 「お支払いいただけない場合は、貴方様の勤務先のネットワーク管理部門にアクセスログを提出し、ご利用された事実を確認いただいた上で再度正規の料金を請求いたします。」 とでも書いておくと思います。

インターネット社会において、リテラシの不足やうっかりミス、危機意識の不足といった点はすぐさま弱点となりえます。 もちろん一人一人が気をつけていればこういった詐欺は成り立ちませんが、その弱点を的確に突かれてしまっているのが現状と言えるでしょう。 こういったサイトを紹介する場合は、アンカーとしてリンクを行わず、 URI のみを記述して、注意書きを添えておかないと付け入る隙をより多く与えてしまうのではと思います。

リプライ

5 件のリプライが送られています。 この記事に対するご意見やご質問、ご感想などありましたら個別記事ページの送信フォームからお送り下さい。

2004-09-07T17:53+09:00 - 加野瀬

ご指摘を受けてリンクを修正、注意書きを追加しておきました。

2004-09-07T23:34+09:00 - 真琴

お手数をおかけしました。 リンクをクリックするのはあくまで当人の判断ですけれど、単にクリックするのと違い、一旦 URI の文字列をコピーしてペーストするのではやはりひと呼吸間が空きます。 そのひと呼吸の違いで、無用な心配をしてしまう人を減らせられるならと思い、名指しで指摘いたしました。 対応していただき、ありがとうございました。

2004-10-07T20:24+09:00 - 「個人情報を特定可能な次世代コード」について < 夢なら admin diary

 「個人情報を特定可能な次世代コード」について、パソコン関連会社へ意見を求めてみました。その結果、現在までに2社からのご意見をいただきました。 インテル株式会社  インテル・ホットラインサービスにお問い合わせいただき、ありがとうございます。  ご指摘のウ...

2005-09-10T23:49+09:00 - 【裏情報】 個人情報、簡単流出!! < ◆ 珍 問 屋 ◆

ニュースやテレビの特番で、よく見かける「インターネット犯罪」。昔、流行ったのが「迷惑メール」や「ワンクリック詐欺」などと呼ばれる架空請求するもの。アダルト画像...

2005-09-10T23:51+09:00 - 【裏情報】 個人情報、簡単流出!! < ◆ 珍 問 屋 ◆

ニュースやテレビの特番で、よく見かける「インターネット犯罪」。昔、流行ったのが「迷惑メール」や「ワンクリック詐欺」などと呼ばれる架空請求するもの。アダルト画像...

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

記事データ

投稿者

望月真琴

投稿日時

2004-09-04T22:07+09:00

タグ
概要

反則金というのは自動車と原動機付自転車の軽微な交通違反に適用される行政罰であり、自動車と原動機付自転車に含まれない自転車の交通違反は、全て刑罰となるというお話。

リプライ

1 件のリプライがあります。

記事本文

反則金とは

何故自転車には反則金という概念がないのか ? まず、反則金というものの持つ意味を調べてみました。

反則者(無免許運転者、酒気帯び運転者及び反則行為によって交通事故を起こした者等を除いた交通違反者)が、反則行為(比較的軽微な道路交通法違反行為)をした場合、刑事手続きに先行して行政手続きとして処理する制度です。

反則金を納付すれば、当該道路交通法違反については公訴を提起(少年の場合は家庭裁判所の審判)されないという制度です。

交通違反に関わる刑事手続きの数を減らすため、また金銭的なペナルティを科すことにより、反則者の反省を促すための制度ということのようです。 たとえば、軽微な速度違反や駐車違反などで取締りを受けた場合、青色の切符 ( 交通反則告知書 ) を渡されます。 その切符に記された期日までに、定められた反則金を納付すれば、以降その反則について咎められることはありません。 反則金を納付するということで、既に行政罰を受けたということになるからです。 ( もちろん、反則点は別途加算されますから、それまでの違反歴によっては別に免許停止や免許取り消しの処分を受けることはありますが。 )

謂れのない取締り ( 例えば、街路樹の枝葉が道路標識を遮るような形になっており、するつもりのない違反をしてしまったなど ) を受けたとして、反則金を納付せずに刑事裁判で争うといったケースも稀にニュース等で見かけます。 反則金を納付するということは、即ち自らの違反を認め、交通違反通告制度に基づく罰を受ける意思があるということを示すことです。

反則金が科される対象

さて、その交通違反通告制度が科される対象となる範囲はどういったものか。

交通反則通告制度の考え

交通反則通告制度は、自動車、原動機付自転車などの運転者のした違反行為のうち、比較的軽いもの (反則行為といいます) については、一定期間内に郵便局 (簡易郵便局を含む。以下同じ) か銀行に定額の反則金を納めると、刑事裁判や家庭裁判所の審判を受けないで事件が処理されるものです。

このように、自動車、原動機付自転車などの運転者とされています。 一般的に言うところの四輪車、バイク、原付です。 そして、この定義に軽車両は含まれていません

9.自動車

原動機を用い、かつ、レール又は架線によらないで運転する車であつて、原動機付自転車、自転車及び身体障害者用の車いす並びに歩行補助車その他の小型の車で政令で定めるもの(以下「歩行補助車等」という。)以外のものをいう。

10.原動機付自転車

内閣府令で定める大きさ以下の総排気量又は定格出力を有する原動機を用い、かつ、レール又は架線によらないで運転する車であつて、自転車、身体障害者用の車いす及び歩行補助車等以外のものをいう。

11.軽車両

自転車、荷車その他人若しくは動物の力により、又は他の車両に牽引され、かつ、レールによらないで運転する車(そり及び牛馬を含む。)であつて、身体障害者用の車いす、歩行補助車等及び小児用の車以外のものをいう。

11の2.自転車

ペダル又はハンド・クランクを用い、かつ、人の力により運転する2輪以上の車(レールにより運転する車を除く。)であつて、身体障害者用の車いす、歩行補助車等及び小児用の車以外のもの(人の力を補うため原動機を用いるものであつて、内閣府令で定める基準に該当するものを含む。)をいう。

よって、比較的軽微な道路交通法違反は、前述の通り交通反則通告制度の適用により、行政罰として取り扱われることになりますが、それは自動車または原動機付自転車に限るということになります。 軽微でない道路交通法違反、および軽微であっても自動車・原動機付自転車以外の車両であれば刑罰として取り扱われることになります。 それは道路交通法 第 125 条にも

この章において「反則行為」とは、前章の罪に当たる行為のうち別表の上欄に掲げるものであつて、車両等(重被牽引車以外の軽車両を除く。次項において同じ。)の運転者がしたものをいい、その種別は、政令で定める。

のように 車両等(重被牽引車以外の軽車両を除く と明記されています。

行政罰と刑罰

刑法 第9条にある通り、 死刑、懲役、禁錮、罰金、拘留及び科料がその種類となります。 ただし、車両の運転における最も重い罪は危険運転致死傷罪になりますので、死刑はありません。

アルコール又は薬物の影響により正常な運転が困難な状態で四輪以上の自動車を走行させ、よって、人を負傷させた者は10年以下の懲役に処し、人を死亡させた者は1年以上の有期懲役に処する。 その進行を制御することが困難な高速度で、又はその進行を制御する技能を有しないで四輪以上の自動車を走行させ、よって人を死傷させた者も、同様とする。

2 人又は車の通行を妨害する目的で、走行中の自動車の直前に進入し、その他通行中の人又は車に著しく接近し、かつ、重大な交通の危険を生じさせる速度で四輪以上の自動車を運転し、よって人を死傷させた者も、前項と同様とする。 赤色信号又はこれに相当する信号を殊更に無視し、かつ、重大な交通の危険を生じさせる速度で四輪以上の自動車を運転し、よって人を死傷させた者も、同様とする。

人を死亡させた者は1年以上の有期懲役とありますので、 15 年の懲役が罰の上限となります。 ( 刑法 第12条 )

逆に、罪の下限は科料となります。 ( 刑法 第17条 ) 科料は、千円以上1万円未満と定められており、場合によっては前述の反則金の方が金額的には高くなることがあります。 しかし、反則金が過料という行政罰であるのに対し、科料は刑罰です。 ( 区別するために、過料をあやまちりょう、科料をとがりょうと読む場合もあります。 )

よって、自転車を運転中の交通違反は全て刑罰が科されます。 実情としてあまり取り締まられていないだけで、ある日「これくらいで ? 」と思いがちなことで捕まっておかしくないのです。 危険な運転や著しい違反をしているなと思い当たる節のある方、安全な自転車の運転を心がけてください。

リプライ

1 件のリプライが送られています。 この記事に対するご意見やご質問、ご感想などありましたら個別記事ページの送信フォームからお送り下さい。

2009-06-09T08:26+09:00 - bluemoon1007

社会責任を具体化するには反則金制度を自転車にも創って適用すべきでありんす。

Movable Type で作成した記事の内容をマウスで選択できないという現象

記事データ

投稿者

望月真琴

投稿日時

2004-09-03T23:46+09:00

タグ
概要

IE 6.0 では position: absolute; が指定されたブロック内のテキストを選択できない現象が発生することがあります。そして、 Movable Type のデフォルトのスタイルシート ( style-site.css ) では position: absolute; を使用しているので、たびたびその現象が発生しているようです。そういった場合の対処法をいくつか考察。

リプライ

1 件のリプライがあります。

記事本文

IE と position:absolute;

ある場所で見たやり取りを自分なりにメモします。 どうやら、 Movable Type で作成した記事の内容をマウスで選択できないという現象が存在するようです。 ( TricksteR: おっぱいボーン!! ) しかし私が確認したときは現象が再現しなかったので、常用している Firefox 0.9 ではなく、 IE 6.0 で確認してみると、確かに質問された方のサイトの Individual Entry Archive の内容が選択できません。

最初に IE 6.0 で確認していたらうーむと悩んでしまったかもしれませんが、既に Firefox で再現しないことを確認していたため、 IECSS バグが怪しいなと思いました。 そこで検索してみると、 IE 6.0 では position: absolute; が指定されたブロック内のテキストを選択できない現象が発生する、といったことが分かりました。 ( あまりに類似の記事が多かったため、検索結果のみを示します。 Google 検索: IE 選択 テキスト position absolute )

要するに、 Movable Type が原因の問題ではなく、前述の通り IECSS バグが原因の問題です。 position: absolute; の指定をしない CSS にすれば解決するようですが、 Movable Type のデフォルトのスタイルシート ( style-site.css ) では position: absolute; を使用しているため、 Movable Type で構築しているサイトをブラウジング中にこういった現象に遭うことが多いかもしれません。

サイトの制作者に改善をお願いするのも解決策の一つですが、改善までにタイムラグが生じてしまいますし、簡単に position: absolute; の指定を外すことができるスタイルであるとは限りません。 それに、 IE 6.0 のバグに由来する現象ですので、対応をしてくれないかもしれません。 ( 仮に私がこの現象に遭遇しても、 IE のバグに関するものは放置すると思います。 )

CSS のバグが原因であるので、仮に制作者側が対応しなくても ( あるいはできなくても ) 、閲覧者側で CSS の適用を解除すれば問題は解決します。 しかし、 IE の機能の中に CSS の解除というものはありませんので、 Bookmarklet などを別途使用する必要があります。 あるいは、 IE 以外のブラウザを使用するのも良い解決策でしょう。 ( IE 6.0 でしか発生しない現象なのですから。 ) もしくは、一度 Ctrl + A で全文選択してメモ帳やエディタなどにコピー & ペーストし、必要な部分だけを再度コピーするという方法でも良いでしょう。

なお、 CSS の適用を解除する Bookmarklet について別項にまとめています。 IECSS を解除する Bookmarklet を合わせて参照してください。

ページ内検索でフリーズ ?

この現象が発生したサイトでは、既に position: absolute; の指定を変更して対処しているようです。 しかし、

おまいら聞いて下さい。ついにトップページで検索かけてもフリーズしなくなりましたヽ(゚∀゚)ノ

原因不明。どうやったら治ったかも不明・・・( ;´Д`)ナンデ…

1:20 追記:今やってみたら固まりやがった・・・_l ̄lΣ・;`,.・○

といった現象も発生しているようです。

知ってる(被害にあってる)方もいらっしゃると思いますけど・・・。 DonutP使ってる方、TricksteRで「ctrl+F」で検索かけるとブラウザが固まります。ご注意を。 なんでですか・・・ヽ(`Д´)ノウワァァン!!

8 月 15 日の時点で話題にしていたようです。 ( 私がこのサイトを知ったのはつい先日ですが。 ) IE 6.0 で検証してみたところ、固まらなかったため、後で DonutP をインストールして検証してみようと思います。

再現しなかった

DonutP をインストールしてみましたが、現象が再現しませんでした。 アプリケーションのフリーズの場合は、必ずしも HTMLCSS の記述に起因するとは限らないので、詳しい再現条件が欲しいところです。 ぢぢさん ( TricksteR ) の追加情報待ちですかね……。

念のため、私の検証環境を書いておきます。

OS

Windows XP Home Edition Version 2002 ( SP1 適用 )

CPU

Intel Pentium 3 1.00GHz

メモリ

256MB RAM

Software version
  • Internet Explorer 6.0 SP1
  • DonutP .5.0 Beta 4 ( 20030720 Release )

トラックバック送信先

リプライ

1 件のリプライが送られています。 この記事に対するご意見やご質問、ご感想などありましたら個別記事ページの送信フォームからお送り下さい。

2007-06-23T21:08+09:00 - IEでテキストを選択できないバグ < 素人のWebデザイン

昨日の続き。 テキストの一部を選択しようとしても何故か全体が選択されてしまうのは...

IE で CSS を解除する Bookmarklet

記事データ

投稿者

望月真琴

投稿日時

2004-09-03T20:52+09:00

タグ
概要

IE などの、 UA 自身の機能で CSS の解除などの操作ができない UA でも、 CSS の ON/OFF 切り替えや解除などを行う Bookmarklet をメモ。

リプライ

リプライはまだありません。

記事本文

真新しいことではないですし、ソースコード自体もかなり以前にどこかのサイトで見かけて自分用のメモに記録していたものから引っ張り出しているのですが、すぐ参照できる位置に書いておいた方が便利 ( 私が ) ということで書いておきます。 IE などの、 UA 自身の機能で CSS の解除などの操作ができない UA でも、そういった機能を実現できるようにする Bookmarklet です。

なお、各種 UA での動作確認はしていません。 基本的に最近リリースされた主な視覚系ブラウザはこの機能を持っていますし、 CSS 自体に非対応の lynx や携帯電話などではこの機能は無用の長物であるためです。 au の携帯電話に登載されている Opera にこの機能が実装されているか、私は知りません。 以下の説明は IE を想定したものであることを予めご了承ください。

CSS の ON/OFF 切り替え

javascript:var i=0;if(document.styleSheets.length>0){cs=!document.styleSheets[0].disabled;for(i=0;i<document.styleSheets.length;i++) document.styleSheets[i].disabled=cs;};void(cs=true);

CSS の ON/OFF の切り替えを行いたいページを開いた上で、このコードをコピーして、アドレスバーに貼り付けて移動をクリックしてください。 CSS が解除されます。 もう一度移動をクリックすると、再び CSS が適用されます。

なお、代替スタイルシートを提供しているサイトの場合、 CSS を解除して再び適用すると、全てのスタイルシートを適用してしまいます。 その場合は、更新をクリックするか、 F5 キーを押してページの更新を行ってください。

CSS の解除

javascript:function%20usr_disableCSS(){var%20ss=document.styleSheets;for(var%20i=0;%20i<ss.length;%20i++)ss.item(i).disabled=true;}usr_disableCSS();

CSS を解除したいページを開いた上で、このコードをコピーして、アドレスバーに貼り付けて移動をクリックしてください。 CSS が解除されます。

ON/OFF 切り替えと違い、解除のみです。 更新をクリックするか、 F5 キーを押してページの更新を行うことにより再び適用されますので、代替スタイルシートを使用しているページにはこちらを使った方がいいかもしれません。

リプライ

リプライはまだ送られていないか、管理者の承認待ち状態です。 この記事に対するご意見やご質問、ご感想などありましたら個別記事ページの送信フォームからお送り下さい。

自転車の事故や違反についてのメモ

記事データ

投稿者

望月真琴

投稿日時

2004-09-03T00:09+09:00

タグ
概要

自転車事故は安全を確認せず交差点や路上に飛び出し、事故に遭うケースが多いというニュースと、自転車も道路交通法によって自動車同様に刑罰が定められているというメモ。

リプライ

2 件のリプライがあります。

記事本文

ご注意!!自転車事故急増

自転車事故は安全を確認せず交差点や路上に飛び出し、事故に遭うケースが多かった。

小学生の頃に、路地から勢いよく右折して、出会い頭に高校生くらいのお兄さんの自転車と激突したことがあります。 こっちが明らかに悪かったのに、だいじょうぶ ? と心配して下さったのを今でも覚えています。 「だいじょうぶです ! お兄さんごめんなさい ! 」 と謝ると、笑って危ないから道に出るときは気をつけなよと言って去っていきました。

こういった経験から、自転車を運転するときは必ず交差点や道路への入り口は一旦停止するように心がけていますが、やはり全く減速せずに突入する人も多いですね。 見ている方がハラハラします……。

あなたの自転車交通法規、間違っていませんか?~ふぁんらいど

交通法規に関しては一部を除き、自動車とほぼ同じです。 信号無視、「止まれ」の場所での不停止、手ばなし運転、無灯火、2人乗り、右折方法違反などなど・・・。 もちろんこれらは「道交法違反」となり、処罰(懲役や罰金)の対象となります。

自動車ですと軽微の違反は反則金で済みますが、自転車は反則金という概念がないのです。 違反であれば ( そしてそれを厳密に取り締まるなら ) 最低でも科料という罰則が科されるということです。 これに関する法律や制度がどう定められているかを、別項自転車には反則金という概念はないにまとめています。

自転車の運転が免許制でない以上、こういったことは義務教育などできっちりと教えておくべきことだと思うのですが。 ( 小学生の頃に交通安全教室で運転の仕方を習った記憶はあるけれど、違反等について習った記憶はありません。 )

リプライ

2 件のリプライが送られています。 この記事に対するご意見やご質問、ご感想などありましたら個別記事ページの送信フォームからお送り下さい。

2004-09-07T17:19+09:00 - No beer, No Name!

「自転車の無灯火運転」ですが、よく 「自分は見えるから良い」と言う人が居ます。 が、他人(他の自動車,自転車,歩行者)から見て貰う ためだから、自分が見えるかどうかは無関係。 てのを教えないのも、まずいと思うのですが。 薄暗いときの自転車が、どれだけ見えにくいものか・・・

2004-09-07T23:26+09:00 - 真琴

そうなんですよね。「前を照らす」という目的以上に、「自分の存在を他者に示す」ためのものですから。 夜道で真正面から無灯火の自転車が近付いてくると、かなり接近するまで気付かないことがあります。 無灯火で走行している人は、自分が歩行者である状況や自動車運転者である状況を思い浮かべて、「どう見えるのだろうか」と想像してほしいものです。

トラックバックが送信された記事を表示するようにカスタマイズ

記事データ

投稿者

望月真琴

投稿日時

2004-09-02T22:32+09:00

タグ
概要

インストールを繰り返すうちに、途中でつまづくこともなくなり、ある種機械的に手順をこなすようになり、必要なプラグインのインストール漏れと、ユーザーテストの実施忘れをしていしまい、その結果 leva さんに要らぬ心配をさせてしまいました。申し訳ありませんでした。

リプライ

リプライはまだありません。

記事本文

トラックバックが反映されない

実は Movable Type をインストールするのは、この hxxk.jp で 5 回目くらいになるのです。 インストール直後の設定変更やテンプレートのカスタマイズはもう慣れっこ。 これまでの経験から、テンプレートの記述を簡略化しつつリビルド時の負荷を軽減し、かつサーバ上に静的に生成されるファイルのサイズ節約のノウハウなどもたくさん学べました。

しかし、慣れは同時に手抜きを生み出します。 インストールを繰り返すうちに、途中でつまづくこともなくなり、ある種機械的に手順をこなすようになりました。 そこで起きた今回の失敗が、必要なプラグインのインストール漏れと、ユーザーテストの実施忘れです。

トラックバックを送ったけどhttp://hxxk.jp/2004/09/02/0132には反映されていないみたいなので、あちらのトラックバックフォームを通じてもう一回送ったら、http://hxxk.jp/weblog/ではどうやら反映されている様で二重トラックバックになってしまいました、しかもパースエラーが。 真琴さん、お手数をおかけすることになってホントにごめんなさい・・

既に、この失敗に起因することによって leva さん ( Software Linkage | Linkage Note! ) が謝られているのですが、これは完全に私のミスなのです。 私がカスタマイズしたテンプレートでは、トラックバックが行われた場合に、 Main Index にて hxxk.jp に向けてトラックバックを送信した記事と、トラックバックが送信された hxxk.jp の記事を表示し、 Individual Entry Archive にて hxxk.jp に向けてトラックバックを送信した記事その概要を表示させるようにしています。

しかし、 Movable Type 2.x のインストール直後の状態では、これは実現できません。 インストール後に、以下の作業を行う必要があります。

  • MTPingedEntry Plugin のインストール
  • /Install directory/lib/MT/App/Trackback.pm の書き換え

これらの作業については、既に Junkline - MTPingedEntry Plugin および Junkline - Individual Entry Archive と Date-Based Archive にも TrackBack を自動で反映されるようにし隊という実践記事があるため、ここで手順を書くことは割愛します。

で、これらの作業をすっかり抜かせたまま公開していた Weblog hxxks ですが、どういった現象が起こってしまうかを記録しておこうと思います。

Trackback.pm を書き換えた場合と書き換えなかった場合

標準状態の Trackback.pm では、

$app->rebuild_indexes( Blog => $blog )
        or return $app->_response(Error =>
            $app->translate("Rebuild failed: [_1]", $app->errstr));

といった記述になっています。 大雑把に表すと、「トラックバックを受信したらインデックス・テンプレートをリビルドする」といった感じでしょうか。 逆に言うと、 Individual Entry Archive などのアーカイブ・テンプレートはリビルドされません。 トラックバックを受信した後に、その記事に新たにコメントが投稿されるか、記事の作成者がその記事を修正して保存するかなどの能動的なアクションがなければトラックバックは反映されません。

よって、トラックバックを送った人が Indevidual Entry Archive を確認しても、 トラックバックを送ったけどhttp://hxxk.jp/2004/09/02/0132には反映されていない といった状況が生まれます。 そこで、

$app->rebuild_entry( Entry => $entry )
    or return $app->_response(Error =>
        $app->translate("Rebuild failed: [_1]", $app->errstr));

という記述を追加して、「トラックバックを受信したら各エントリもリビルドする」ようにすることにより、トラックバックを受信したら自動的に反映することができるようになるのです。

MTPingedEntry Plugin をインストールしなかった場合

MTPingedEntry Plugin をインストールしているという前提で書いた私の Main Index テンプレートの Recent Trackbacks 周りの記述はこのようになっています。

<dl>
  <MTPings sort_order="descend" lastn="10">
    <dt><MTPingedEntry><a href="<$MTPingedEntryLink$>"><$MTPingedEntryTitle$></a></MTPingedEntry> へのトラックバック</dt>
    <dd>
    <ul>
      <li><a href="<$MTPingURL$>"><$MTPingBlogName$> - <$MTPingTitle$> : <$MTPingDate format="%Y-%m-%d %H:%M"$></a></li>
    </ul>
    </dd>
  </MTPings>
</dl>

このソースコードの中に登場するテンプレートタグの中で、

  • <MTPingedEntry>
  • <$MTPingedEntryLink$>
  • <$MTPingedEntryTitle$>

の 3 つが MTPingedEntry Plugin によるオリジナルのテンプレートタグであり、プラグインをインストールしていない限りタグとして認識されません。 プラグインをインストールした状態でトラックバックを受信すると、インデックス・テンプレートがリビルドされ、

<dl>
  <dt><a href="http://hxxk.jp/weblog/2004/09/02/0132.php">index に最新記事を配置するということ</a> へのトラックバック</dt>
  <dd>
  <ul>
    <li><a href="http://diary.sakura.ne.jp/?date=20040902#p05">Linkage Note! - [weblog] トップページに最新記事を配置と言うこと : 2004-09-02 04:56</a></li>
  </ul>
  </dd>
</dl>

といったようなソースコードとして生成されます。 しかし、プラグインをインストールしていない状態でトラックバックを受信し、インデックス・テンプレートがリビルドされると、

<dl>
  <dt><a href=""></a></MTPingedEntry> へのトラックバック</dt>
  <dd>
  <ul>
    <li><a href="http://diary.sakura.ne.jp/?date=20040902#p05">Linkage Note! - [weblog] トップページに最新記事を配置と言うこと : 2004-09-02 04:56</a></li>
  </ul>
  </dd>
</dl>

といったようなソースコードとして生成されます。 em 要素で強調していますが、強調するまでもなく分かるとおり、 well-formed ではなくなっています。 また、 XHTML ではない要素の終了タグ、 </MTPingedEntry> も出現しています。

hxxk.jp のほとんどのリソースは、 HTTP ヘッダの Content-Type を application/xhtml+xml としてサーバからクライアントに送り出すようにしているので、この状態で application/xhtml+xml に対応している UA で表示しようとしても、

XML パースエラー: タグが整合していません。必要なタグ: </dt>.
場所: http://hxxk.jp/weblog/
行番号 167/列 30:

<dt><a href=""></a></MTPingedEntry> へのトラックバック</dt>
-----------------------------^

といったパースエラーの結果が返ってくるだけです。 ( なお、 application/xhtml+xml に対応していない UA ( IE など ) には Content-type を text/html として返しているので、パースエラーは起こりません。 not Valid な HTML であることに変わりはありませんが。 )

お詫び

こうして、事前にテンプレートなどの検証を行って、万全を期したつもりで公開したつもりが、 leva さんにご迷惑をかける結果になってしまいました。 現在は修正を行い、二重トラックバックも片方を削除しています。 leva さん、こちらのミスでご心配をおかけして申し訳ありませんでした。

トラックバック送信先

リプライ

リプライはまだ送られていないか、管理者の承認待ち状態です。 この記事に対するご意見やご質問、ご感想などありましたら個別記事ページの送信フォームからお送り下さい。

index に最新記事を配置するということ

記事データ

投稿者

望月真琴

投稿日時

2004-09-02T01:32+09:00

タグ
概要

web サイトの構成として捉えると、インデックスに最新の記事を配置することは自然ではないと言えるかもしれません。インデックスをインデックスとして扱い、最新の記事も過去の記事も等しく辿られるようにしていた方が、 web サイトの構成として自然であると言えるのではないでしょうか。インデックスに最新の記事を配置することが間違いであると述べるつもりはありませんが、最新の記事を配置しないという構成をしているところがほとんど無かったので、ぼんやりと考えてみました。

リプライ

1 件のリプライがあります。

記事本文

weblog サービスのアカウントルート調査

weblog ツールや weblog サービスで作られた weblog は、たいてい index.* に最新の記事を配置している印象があります。 実際のところはどうでしょうか。 思いつく限りの weblog サービスを調べたところ、以下のような結果が得られました。

はてなダイアリー

http://d.hatena.ne.jp/account/ に最新の記事を表示

Diary Note

http://diarynote.jp/d/account/ に最新の記事を表示

ココログ

http://account.cocolog-nifty.com/ に最新の記事を表示

ブログ人

http://account.blog.ocn.ne.jp/ や http://account.blogzine.jp/ に最新の記事を表示

ウェブリブログ

http://account.at.webry.info/ に最新の記事を表示

livedoor Blog

http://blog.livedoor.jp/account/ に最新の記事を表示

goo BLOG

http://blog.goo.ne.jp/account/ に最新の記事を表示

エキサイトブログ

http://account.exblog.jp/ に最新の記事を表示

Doblog

http://www.doblog.com/weblog/myblog/account/ に最新の記事を表示

JUGEM

http://account.jugem.jp/ に最新の記事を表示

weblog ツールのアカウントルート調査

では、 weblog ツールを自分で設置している場合はどうか。 カスタマイズを行っている人が多いだろうという思い込みで、さとみかん - 日記とかから、 weblog ツールを使用しているということを body 要素内に明示しているサイトを分類してみたところ、以下のような結果が得られました。

Movable Type
tDiary
rNote
WordPress
Hyper NIKKI System Project
wdiary
blosxom
Nucleus
HIMMEL
  • Memo : /memo/ に最新の記事を表示
nDiary
  • klee : /~kusumi/klee/ に最新の記事を表示
Akiary

index に最新の記事を配置するということに疑問を投げてみる

今回の調査では、 weblog ツールや weblog サービスによる weblog は、全てにおいて weblog のルート ( weblog サービスの場合はアカウントのルート ) に最新記事が配置されています。 weblog サービスでは構成を変更できるものはほとんどありませんし、テンプレートなどをカスタマイズできるツールを使用している場合でも、構成自体を全く変えてしまうカスタマイズをすることは稀だと考えられますので、自然なことだと言えるかもしれません。

しかし、 web サイトの構成として捉えると、インデックスに最新の記事を配置することは自然ではないと言えるかもしれません。 たとえば、最新 3 日分の記事をインデックスに配置している weblog があるとします。 閲覧者はその 3 日分を読み終えて、それ以前の記事を読みたいと思ったとき、それを直接辿ることができるケースはそう多くありません。 統計をとったわけではありませんが、カレンダーなり月次アーカイブへのリンクなりを辿って、比較的直近の過去ログを類推して探すケースが多いようです。

これは weblog という言葉が登場する前の web サイトにも言えることですが、それらのサイトは weblog ツール / サービス系のサイトに比べて、 「直近の過去ログへ」といった類のアンカーを作成していることが多かった印象があります。 インデックスに配置された最新記事から、ある程度スムーズにそれに近いログを辿ることができたわけです。

しかし、そもそもインデックスをインデックスとして扱い、最新の記事も過去の記事も等しく辿られるようにしていた方が、 web サイトの構成として自然であると言えるのではないでしょうか。 インデックスに最新の記事を配置することが間違いであると述べるつもりはありませんが、最新の記事を配置しないという構成をしているところがほとんど無かったので、以上のようなことをぼんやりと考えてみました。

ちなみに、この hxxk.jp ではインデックスに最新の記事を配置しない構成にしています。 更新のあった記事 / フィードバックのあった記事、時系列による過去ログ、カテゴリごとのログを文字通りインデックスしています。 最新の記事は http://hxxk.jp/latest から参照できるようになっており、その記事から link rel="prev" が指定されている記事を辿るなり、上位のディレクトリを辿るなりといった方法によって、過去の記事の参照を容易にしています。 そういった構成の実現方法はまた別の機会に。

リプライ

1 件のリプライが送られています。 この記事に対するご意見やご質問、ご感想などありましたら個別記事ページの送信フォームからお送り下さい。

2004-09-02T04:56+09:00 - [weblog] トップページに最新記事を配置と言うこと < Linkage Note!

今の最新記事配置形式が良きにしろ悪きにしろ、ウェブログツールも表示形式を選択できる様になればいいなと・・思うわけです。

補足情報

著作、講演、制作実績など