2005-11 アーカイブ

仕様以外の点から考える target="_blank" の良くない点

はてなダイアリー日記 - リンクターゲットの設定を追加しましたにて、これまで一律 target="_blank" という指定がなされていたはてなダイアリーにおける ( http 記法での ) リンクの target 属性を変更できるようになりました。 何故 target="_blank" ではダメなのか ? target="_blank" の良くない点を論じようとすると、往々にして仕様云々の話になるため、今回はなるべく仕様に触れずに良くない点を考えてみようと思います。

回避策が無い

無いというと語弊がありますが、 target="_blank" に対応しているブラウザにて target="_blank" が指定されたリンクをクリックすると、閲覧者が新しいウィンドウで開きたい・開きたくないのどちらを望んでいるかに関わらず、新しいウィンドウで開きます。 ( リンクアンカーをポイントしてアドレスバーにドラッグすれば同じウィンドウで開くブラウザもありますが、それは「クリック」以外の方法での回避なので実質的な回避策とは言い難いです。 )

ブラウザによっては無意味

携帯電話に搭載されているブラウザが代表的ですが、そもそもマルチウィンドウという概念を持たないブラウザにとっては何の意味もありません。

使っていると絡まれることがある

私みたいな輩に。

はてな界では target="_blank" を消すのがトレンディ

はてな はてなスタッフより、はてなダイアリーユーザーの皆さまにお尋ねします。現在はてなダイアリーでhttp記法（URLの自動リンク）でのリンクの作成先は「・・というアンケートでも設定の変更を希望する声が 79.5% を占めています。 いや本当は 既存ユーザーも新規登録ユーザーも標準は「新規ウィンドウで開く」のまま（設定で変更可能） という選択肢だったのですが、設定によって変更が可能という選択肢がこれしか無いので、何とも微妙な設問のアンケートでしたが。

現時点 ( 2005-11-29T21:12:11+09:00 ) ではてなブックマーク - はてなダイアリー日記 - リンクターゲットの設定を追加しましたで読めるコメントやそこから辿れるダイアリーでも早速 target="_blank" の指定を消したという声が続々と !

ちなみにちょっとだけ仕様の話に触れると、そもそも非推奨な属性であるとか今後廃止される属性であるとか、そんな立ち位置 (?) なのです target="_blank" は。

自分のダイアリーから target="_blank" を消す

はてなダイアリー日記 - リンクターゲットの設定を追加しましたにて手順が説明されていますが、せっかく設定できるようになったので、いっちょスクリーンショット付きで説明しようと思います。

1. はてなにログインした状態で画面上部の「管理」をクリックします。
2. 管理画面の左端に並んでいる設定の部分から、「日記の設定」をクリックします。
3. 日記の基本設定画面の最下部付近に「そのほか基本設定」という部分があり、そこに「リンクターゲット」という項目があるので初期値の _blank を消去します。
4. 「この内容に変更する」というボタンをクリックして設定完了。お疲れ様でした。

他人のダイアリーから target="_blank" を消す

前項の設定で、自分のダイアリーから target="_blank" を消すことができました。 しかし他人のダイアリーはどういった設定になっているか分かりませんし、 target="_blank" を消してくれと頼んでも聞き入れてもらえるかは分かりません。 そこで、ブラウザ側で target="_blank" を消してみましょう。

以前、 Destroy target="_blank" という記事で、他人のサイトで設定されている target="_blank" を無効化する方法を紹介しています。 この方法を使うと、ダイアリーの設定がどうなっていても、 target="_blank" を消したのと同様の効果を得られます。 なお、 Firefox 1.5 では標準のオプションで同じことが実現できます。 消してしまったら新しいウィンドウで開きたくなった時に困るんじゃないかって ? その場合は Shift キーを押しながらリンクアンカーをクリックすれば、たいていのグラフィカルブラウザでは新しいウィンドウで開いてくれるので安心です。 ( Mac の場合は cmd キーを押しながら……だと思いますが自信がありません。 )

トラックバック送信先

はてなダイアリー日記 - リンクターゲットの設定を追加しました

スクリーンショット付きでリンクターゲットの設定方法を解説しています。

http://www.hatena.ne.jp/1133160932 に回答してみよう

gobbledygook - アイデア実装チェック。にて示されている方法にてはてなアイデアの期待値を出してくれという質問。 面白そうということと自分のアイデアの履歴を振り返るということで尻馬に乗ってみます。

はてなアイデア - id:hxxk の現状把握

はてなアイデア - id:hxxk の期待値算出

1-1.実装または却下になったモノ

(実装*倍率)/(実装+却下) = ( 1 個 * 3 倍 ) / ( 1 個 + 0 個 ) = 3

ということで、終了項目の期待値は 3 。

1-2.全ての発案アイデア

{(実装*倍率)+(検討中*倍率)}/(実装+却下+他の方法+キャンセル+要望中+検討中) = { ( 1 個 * 3 倍 ) + ( 1 個 * 2 倍 ) } / ( 1 個 + 0 個 + 0 個 + 0 個 + 1 個 + 1 個 ) = ( 3 + 2 ) / 3 = 1.6666... ≒ 1.667

ということで、全ての発案項目の期待値は約 1.667 。

1-3.実装倍率の和

私の場合は実装されたアイデアが 1 つしかないため、その倍率の 3 がそのまま実装倍率の和になります。

私見

gobbledygook - アイデア実装チェック。にて、 もう終わろうヨー的なエントリ と書かれているため、おそらくアイデア実装の期待値や実装倍率の和の低さが目立つことをアピールしたいのかな、と考えました。 そういう視点で見ると、はてなアイデア - id:hxxk のサンプルは母数が少ない上に比較的期待値が高いため、意図した答えになっていないかもしれません。

はてなアイデアは以前の[～の要望]キーワードと比べて、どう思いますか？への回答

以前から何度か「はてなダイアリーへの要望」を自分のダイアリー中に書いていましたが、個人的にはこのやり方の方が好きですね。

はてなアイデアは要望がサービスごとに分類され、またタギングも実装されていたので、どのような要望がユーザから挙がっているかを、無駄なく効率的に汲み取るには良い仕組みだったと思います。 しかし、アイデアポイントを用いることで、それが本当にクリティカルな不具合であっても埋没してしまうことになったり、あまり急を要しない要望が目立ってしまったりといった欠点が出てきたと私は考えます。 また、アイデアミーティングの俎上に上がって「検討中」になってもなかなか実装されないといったことがあったり、「実装済」になっても実は実装されていないといったことがあったりと、実際に上手く機能していたかというとううむと唸ってしまうあたり、はてなアイデアにあまり良い印象は抱かなかったです。

箇条書きメソッドでオフレポ

History of hxxk.jp で勝手に名付けた箇条書きメソッドですが、時系列に沿った行動を書く日記には適しているのではないかということで、 Tour "2005 Autumn Kyoto" のレポートに使用してみようと思います。 Tour "7" - Without You のレポートはどっち形式にしようかなあってそっちは後回しかい ! と自分ツッコミ。

計画から出発前夜まで

1. けっこう早い段階で京都話が持ち上がる。最初はその時期は仕事が忙しそうということで参加に消極的。
2. その数週間後、幹事より直々の御指名で「京都行こうぜー」みたいな誘いを受け、仕事の目処も立ちそうなので参加表明。
3. このシーズンの京都の宿は、当たり前だけど既に満杯状態なので梅田のホテルを予約。
4. 草原さん ( Diary - Notes | castle of sand ) が小樽ビールを買ってきてくれる。 ( 伏線 1 )
5. 小樽ビールを受け取る。
6. 小樽ビールうまうま。
7. そういえば真冬向けのコートや秋物のジャケットは持っているけど、晩秋～初冬向けのアウターを持っていないことに気付いて購入。これが 11 月 19 日のお話。
8. 11 月 25 日にばたばたと準備を済ませて携帯電話を充電器に繋ぎデジカメのバッテリーも充電器に入れて iPod mini はライブラリの更新がてら PC に USB で繋いで ( 伏線 2 ) お風呂入ってビール飲んで 23 時前には就寝。

11 月 26 日

1. 6 時 30 分頃自宅最寄りの駅から在来線乗車。まだ眠いので寝る。でも車内寒すぎ。
2. 7 時 30 分頃路線乗り換え。先は長いので iPod mini を取り出して 5 分でバッテリーが枯渇する。どうも USB 経由での充電ができていなかったみたい。 ( 伏線 2 回収 )
3. 実は初の新幹線乗車。切符をネットで予約していたので受け取りに行ったら、「ここじゃなくて中央口の方に行ってくだされ」と言われるプチイベントをこなしつつ無事乗車。 ( 伏線 3 )
4. 車内では寝たり本を読んだり仮に満充電でもすぐ枯渇する iPod mini のバッテリーを考慮して持ってきていた携帯電話での音楽再生セットで音楽を聴いたりして過ごし、予定通り京都着。
5. 京都駅北交番の近くのタクシー乗り場からタクシーに乗って興正寺に向かい、既に貸切観光タクシーで動いている先発隊と合流する算段。京都駅分かり辛い。
6. お、「タクシー」と書いてある看板があって人がいっぱい並んでいるぞ、きっとここがタクシー乗り場だろう。ところで交番なんて見当たらない気がするんですが。 ( 伏線 4 )
7. とぴあ通信兵にタクシーに乗る旨を伝え、凄く人が並んでいるので時間かかるかもと言うと「じゃあ迎えに行くよー」というありがたいお言葉。
8. 数分後、「タクシー乗り場にいるんだよね ? 」という電話が。どうにも話が食い違うのでにゃおりんと電話交代。「京都タワー見えてますよね ? 」「そんなもの私の視界にありゃしませんが」タクシー乗り場間違えていました。 ( 伏線 4 回収 )
9. 新たに指定した待ち合わせ場所で無事合流。タクシーからにゃおりんらしき人が飛び出してくる。いや、お互い顔を知らないから、そこは顔を知っているとぴあさんが出てくるべきでは !? この時点でのパーティ ( 違 ) はとぴあさんとにゃおりんと私。
10. お迎え隊との合流に手間取ったため、先発隊であるかっぱさんとシンヤさんといわいさんと kina さんとは西本願寺で合流。お寺の方の丁寧なんだけど小粋な説明を受けつつ堪能。大沢親分にゃおりんの「眼福」出ましたー。
11. 諸般の事情で先発隊のはずだったぴろたんと西本願寺を出るときに合流。
12. 本家尾張屋にて昼食を堪能。かっぱさんが本当に美味しそうに食べる姿に皆で和む。というかご馳走様でした。九州に来ることがあれば今度はこちらからご馳走を。
13. 南禅寺にて紅葉を満喫し、返す刀で永観堂も満喫。
14. 鍵善高台寺店にてお茶。これからは夜の京都を散策ということなので体を温めておこう……って、シンヤさんが頼んだグリーンティーには氷が浮いているんですが !
15. 清水寺に向かう道すがらお土産の八ツ橋を買ったりきなこソフトクリームを買って「ここにジュンたそがいたらネタにするだろうなあ」とか言いながら食べたりお土産の木刀を買ったりお土産のハバネロ七味を買ったりお土産の青龍麦酒を買ったりしてどんどん重装備に。しかも木刀持って歩いていたらすれ違った人が「あ、木刀買わないと ! 」と言っていました。私の木刀を見て思い出したのかなあ。あと青龍麦酒は 1 本はお土産で 1 本は自分用です。 ( 伏線 1 回収 )
16. 清水寺の夜間特別参拝を堪能。ここでにゃおりんが失言をかますという所業を行ってくれたけどまあ本人の名誉のために詳細は伏せ。
17. 豆ちゃで夕食会。ここは石塀小路の中でも一見さん可でお手頃価格なところとのこと。入店時ににゃおりんの失言パート 2 が繰り出されたけれど以下略。
18. 最初はビールで乾杯して、次からは冷酒をいわいさんとシェアしながらくぴくぴ。シンヤさんがお酒が進むごとにテンションが楽しくなっていったので、良い酔い方をするなあと思いました。

11 月 27 日

1. 実は終電ギリギリということが分かり、急いでタクシーを拾って京都駅へ急行。
2. タクシーを降りてダッシュで切符売り場に向かって切符を買って改札を通過するも京都まで行く終電は過ぎ去った後。後から「何故紙 ( 乗車駅証明 ? ) をもらわずに切符をわざわざ買うの」と言われたのですが、都会にはかようなシステムがあるのでゴザルか。まあ九州にもあるのかもしれないけど。
3. とりあえず出られるところまで電車で出ようということで高槻まで乗車。
4. kina さんに東京オフ中のみんな ( 誰 ) から電話がかかる。どうやら minatsu さん ( 津波荘 ) とお話ししているらしく、うわー羨ましいと思いつつきっと先方はこちらのことを知らないんだろうなあと思って電話のバトンはスルーしました。津波荘は CSS の切り替えで私に衝撃を与え、「なんでこんなことができるんだ !? 」→「ちゃんとした HTML であれば CSS を変えるだけで簡単に見栄えを変えることができるのかあ」ということを学ばせていただいたところなのです。これは History of hxxk.jp でも言っていたことですけど。 ( 伏線 5 )
5. 計 8 人だったので、方向などを考えて 4 人ずつに分けてタクシーに乗車。いわいさんに「誰も付き合う人がおらんかったら電話ください、飲みに行きますんでー」と言って別れる。 ( 伏線 6 )
6. 帰りの車中で既にこっくりこっくり。
7. ホテルにて枕の数が気になりつつも眠さが限界だと思ったのでやっぱり 2 件目無理と判断。軽く朝からの予定をメールで連絡取り合って btnq ( 伏線 6 回収 ) ( 伏線 7 )
8. 二度寝を考慮してセットしたアラームが 5 時 30 分に鳴る。
9. そして本来起きる時間だった 6 時ちょうどにアラームが鳴る。
10. 6 時 30 分に起きる。ちょっと諦めかける。諦めたらそこで試合終了だよ。
11. 予定していた新快速は逃すも、まだデッドラインには間に合う次の新快速に乗って待ち合わせ場所に何とか到着。ロッカーに荷物を入れようかと思っていたけど時間が厳しいのでそのままホームに行き ( 伏線 8 ) 、とぴあさんとにゃおりんと kina さんと合流。
12. 東福寺を堪能。
13. 出町柳に出て、ふたばで豆もちやお団子を購入して川のほとりでぱくぱくうまうま。
14. かっぱさんとの合流を三条京阪の土下座像に設定してしばし待つ。とある署名をお願いされるが断る。色々議論したかったけどいざと言うと上手く言えないなあ。にゃおりんの弁舌を堪能できたので良しとしよう。
15. 昼食はそのまま土下座像傍の店で定食。食べ終わってから窓の外を眺めていると、猛禽類と思われる鳥がびゅんびゅん飛んでいて驚く。
16. 午後の部一発目はインクラインを堪能。にゃおりんが楽しそうだったので「廃線とか廃墟とか好き ? 」と尋ねると「うん」との回答。
17. そのまま南禅寺や永観堂の脇を通り、哲学の道を散策。
18. ユキ・パリスコレクションにて kina さんととぴあさんがコレクションを堪能し、私とにゃおりんとかっぱさんはしばし休息したり辺りを散策したりのんびりお話したり。
19. そろそろ帰りの新幹線の時間が迫ってきたということで、烏丸今出川まで歩く。普段ならたいしたことのない距離だけど、荷物をそのまま持っている分ちと辛し。 ( 伏線 8 回収 ) ちなみに道中の口数が少なかったのは、話すために 2 列になって歩いていると自転車に追突されかねんと思ったことに起因します。自転車が歩道を走るなよと言いたいところだけど、あれだけ路上駐車が多くて交通量も多ければそういうわけには行かないだろうなあ。ただしこちらがちゃんと避けているのにベルを鳴らしまくったり、全く減速せずに通り過ぎたりする輩がいたのには辟易。
20. 京都駅に着き、挨拶を交わして在来線組であるにゃおりんとかっぱさんとお別れした後に、新幹線乗り場で kina さんととぴあさんとお別れ。お疲れ様でした !
21. ようやく腰を落ち着けられたので、乗り場で買っていたビールで早速ひとり乾杯。
22. 博多駅に到着し、改札に乗車券と特急券を入れて在来線へ乗り換え……って、これでそのまま在来線に乗ったらどうやって博多駅からって証明するんだろ ? 在来線改札出口で「切符飲ませちゃったんですがー」と尋ねると「新幹線の改札に言ってくだされ」と言われたので、戻って事情を話して乗車券をサルベージしてもらう。分からないならアクション起こす前に尋ねろと。行きも帰りもそんなんかい。 ( 伏線 3 回収 )
23. 無事帰宅後に IRC で東京組と話していると、 minatsu さんに hxxk.jp の人もいると言ったら通じていたという旨のことを聞く。それなら電話代われば良かった…… ! ( 現金すぎます ) ( 伏線 5 回収 )
24. ニュースサイトを見ていたら、信号無視、ひき逃げ…男性死亡 若い女、車３台と衝突 御堂筋で未明(11/26 16:06) という事件があっていたことが判明。二十六日午前三時三十五分ごろ、大阪市北区太融寺町の曽根崎東交差点で、乗用車が信号無視するのを府警曽根崎署のパトカーが発見、追跡を始めた。乗用車は御堂筋を南下し、梅新北交差点を信号無視して進入、横断歩道を渡っていた男性をはねた後、約百五十メートル南の梅田新道交差点でも信号無視し、走行中のタクシー三台と次々と衝突して停止した。運転していた女は車を乗り捨て走って逃げたって、曽根崎東交差点と梅新北交差点と梅田新道交差点って宿泊先の梅田 OS ホテルを取り囲むルートじゃないですか ! これが 1 日ずれていて、かついわいさんと一緒に飲みに行っていたら、もしかしたらもしかしたのかも…… ( 伏線 7 回収 )

メンバー紹介

とぴあさん

Clovery leaf pieces の人。 今回は通信兵を担当。 あと道中のルート探索にも威力を発揮。

にゃおりん

回顧録？の猫。 今回は幹事を担当。 No-Future!! No-Future!! No-Future!!

かっぱさん

宏精堂 家門表具店の表具師さん。 各地の案内や補講 ( 謎 ) 、その他プロデュース & 監修などを担当。 その他にも色々とお世話になりました。

シンヤさん

Hatena::Diary::Code-404 の人。 服とかバッグとかのセレクトがかっこよかった。 あと荷物を持ってもらったしと色々とありがとうでした。 そういえば Movable Type トークは全くしていない !

• Hatena::Diary::Code-404 - 京都オフ行ってきました

いわいさん

None の人。 相変わらずの口と頭の回転は健在。 全然喋っていないと言われたけど素直にすみませんとしか……。 歯の矯正を始めて、喋ること自体に少し恐怖というか不安を抱いてしまっているんですよねえ。 まあ、それと場を盛り上げないちうのは別レイヤーなので次はがんばります。 冷酒はおいしゅうございました。

kina さん

96*72 や kina_memo やつれづれ記録"19"(feel diary) の人。 今回はちょっと風邪をひいていたようで、苦しそうに咳をされていたのが心配。 うがー写真 ( 謎 ) を撮り損ねたのが心残り……。

• つれづれ記録"19"(feel diary)
• kina_memo - 京都行ってきた
• kina_memo - おみやげに豆もち

ぴろたん

outsider reflex の人。 どじっこ担当 ( 謎 ) 私がこのレポートを書いている今も復旧作業をがんばっているのかなあ。 やっぱ初代 iPod mini はバッテリ弱いよねー。

2 日間留守にします

Tour "2005 Autumn Kyoto" に書いていた通り、土日で京都に行ってきます。 土曜日の朝イチで出発して日曜日の夜に帰宅予定なので、記事の更新とかコメントのレスとか溜まっている 7 月のオフのオフレポとかは全て滞ります。

例の如くはてなダイアリー - 真琴＠臨時更新場にて携帯からの現地報告を行うかもしれませんので、動向が気になる方 ( たぶんいない ) はチェックすると良いかもです。

約束の日

明日から Tour "2005 Autumn Kyoto" に出かけますが、早くも次のオフツアーを企画しています。 現在確定しているのは 12 月 24 日の日中から 12 月 25 日の未明までのスケジュールと参加者。 これは皆で集まってわいわい、という類のものではないので参加者は募集しません。 まだ重要な点が確定していないのではっきりとは言えませんが、関係しそうな方はお仕事が終わった後の体を開けておいてくださいね。

デザインを外部委託してみようかなの続き

デザインを外部委託してみようかなで aamall.jp にデザインを発注してみようかという話をしましたが、実際には発注をしていません。 あの記事を書いた後にいくつかの反応をいただいたり、他に発注をされた方に進展があったりでやはり踏み切れていないのです。

1. Re: iMach - CSS
2. Re: cheerful*tearful : blog のオリジナルデザインを外注する価値
3. Re: ブログデザイン外注 aamall.jp は高い?　安い?
4. 人柱さんの結果

Re: iMach - CSS

受けて側の力量というかレベルというかセンスというか、そういうもので変化してしまう。 例のうちの上司などは、「自分には作れないとわかっているから、金を払うんだ」とおっしゃっていました。

なるほど、確かに明確な指標が無い分、クライアントの意向に沿うか沿わないかで高い安いも変化しますね。 ( 工数や素材数、 Flash の使用等による一定の価格基準はあるかもしれませんが。 ) そして Webにかかわらずデザインに相場は無い というのも良く納得できました。

結局のところの回答としては、仕事としては受けられないけど、好きにやっていいという条件であれば（&暇と時間があれば）やってみてえな、なんて思う自分がいるよ、という感じです。

こういう回答をいただけたのはがっかり半分嬉しさ半分。 仕事としての iMa さんイズム全開 ( 注 : iMa さんは web の仕事をメインにしている方ではありません ) のデザインが見られるチャンスを逃したのにがっかり、でも「やってみたい」と興味を示してくれたことを嬉しく思いました。

もし今後機会があれば、何の制約も課さずに好き勝手に遊んでもらいたいです。 それこそクロスブラウザとかサイトのイメージとかを全く考えずに。 ( まだはっきりとした話にはなっていませんが、同様に「思いっきり遊んでみたい」と言っている方がいらっしゃいます。 )

Re: cheerful*tearful : blog のオリジナルデザインを外注する価値

実際に私がブックマーク時にコメントをつけたときには、「相場」というものは全く考慮していませんでした。 件のサイトの「対応ブログポータル」には個人が気軽に（無料で）利用できるサービスが多数含まれています。 そういうサービスを利用している個人が気軽に注文するには、15,000円は少し敷居が高いかな、という印象をそのままコメントとして書いたのでした。

確かに、 aamall.jp が対応している weblog サービスは、その利用自体は無料でできるものがほとんどです。 中には利用料がかかったり有料オプションサービスがあったりするものもありますが、いずれも数百円 / 月のレベルであるため、それを使っているユーザが注文する場合には高いと感じるでしょうね。 かく言う私も人柱になろうとしつつ踏み出せなかったのは、 15,000 円という金額は自分にとって軽くはないという理由もありましたし。

私が思わずめまいを感じたのは デザイン用語説明はこちら と書かれた部分のリンク先です。

なんじゃこりゃ。

私が通常使用しているブラウザは Firefox なので、最初は 「あぁ、 IE 以外では確認していないのかな。仕事としてやっているのにそれはどうかと思うけれども、いろんな事情でそうせざるを得ない人もいるだろうからまぁ仕方ないのかしら」 と、諦め半分で IE を起動して同じページを表示してみたところ、再び目玉が飛び出ました。

IE で見ても表示が崩れてるんですけど！！！

特定のブラウザの表示確認だけで検証するのはよろしくありませんが ( 複数のブラウザで確認するとか、合わせて Validator にかけてみるとか ) 、全く表示確認をしていない ( と思われる ) のはちょっと……。

Re: ブログデザイン外注 aamall.jp は高い?　安い?

最低額の15000円を腑分けすると、aamall の取り分が3分の1、画像素材やソフトウェアなど諸経費が5000円、残る5000円が純粋な労賃、といったところでしょうか。 つまり、半日で完成させなければならない。 まあ、無理ですよね。

価格にばかり目が行って、その内訳は全く考えていなかったですね。 aamall.jp 自体の取り分も当然あるでしょうし。

いや、完成したものを見れば、「なーんだ、これなら俺、2時間あれば十分だよ」といいたくなる方は、正直いると思いますよ。 けれども、求める結果がわかっていれば2時間という話なのであって、何をしたらいいのかわからない状態から2時間で完成できるような人がそうそういるわけがないよ。

実際、デザイナーとクライアントが事前にやりとりを行ってイメージを固めて、それから制作に入る……という流れを汲んでいるようですので、工数と金額を比較すると決して高くはないと思えます。 そういった視点を持って見ると、何故その金額が設定されているかに考えを及ぼすことができて良いですね。 ( 逆に言うと私はそういった視点を持たずに金額だけを見て考えていたのですが。 )

滝口さんいわく 我々のデザイナーに関してですが、非常にお恥ずかしい話で恐縮なのですが、スタイルシートの対しての造詣が浅く、ゼロスクラッチでスタイルシートを制作することが現状ではまだ難しいのです。 我々共も今後、スタイルシートの制作に関しての知識を増やしていかなくてはならないと強い認識をもっているのですが とのこと。 プロの CSS デザインを見てみたい!　という用途に aamall は向きません。

ああ、 プロの CSS デザインを見てみたい! という気持ちも半分くらいありました……。

人柱さんの結果

• jazzanovaの日記 - 遂に完成
• はてなブックマーク - jazzanovaの日記 - 遂に完成

こういう結果になりました。 時期を逸したのでコメントは無し。 今後 hxxk.jp で aamall.jp を活用するかは分かりませんが、 hxxk.jp 以外の場でこっそり活用してみようかなあ。

MTArchiveDate はアーカイブ・マッピングには使えない ?

以前なにやらテンプレがおかしい・・・ - ゼロSP@BLOG という記事にコメントをしていたことがあり、その経過がどうなったのかなあと思っていたのですが、どうやら月別アーカイブのリンクバグの原因が判明 - ゼロSP@BLOG にて解決の目を見たようです。

このMT設定画面での月別アーカイブのアーカイブ・マッピングを次のようにしたら問題なくリンクできるようになりました。

idx/%y_%m.php

これで全て解決。 あの悩んだ日々はなんだったんだろうと・・・。 これで思うのは俺が最初に書いたidx/<$MTArchiveDate format="%Y_%m"$>.phpの書き方が不味いのかな？

へー、 MTArchiveDate をアーカイブ・マッピングに指定したらまずいのかあ……。 って、

このように、 hxxk.jp では存分に MTArchiveDate を指定していますが。 もちろん idx/%y_%m.php のような指定でも良いんでしょうけど、 MTArchiveDate も使えるはず……。

MTEntryBasename は Export で書き出されない

バグかどうかは分かんないんだけど、MTのログをエキスポート/インポート機能を使うとファイル名は復元してくれません。 エキスポートした時にファイル名のデータがない。

これって凄い困りませんか？ サーバ移転する時とかにエキスポートしてやるのが普通だと思うんだけど、それでデータを落としてインポートしてもファイル名は復元できないと・・・。 エントリーたくさんある場合はまた自分で入力するのめんどくさすぎだよ。

バグというよりは仕様で復元されないと言った方が良いかもしれません。 Movable Type 3.2-ja-2 において記事の書き出しを行うと、記事ごとに次の項目が書き出されるようです。

• author_name
• entry_title
• entry_status
• entry_allow_comments
• entry_convert_breaks
• entry_allow_pings
• entry_created_on
• entry_text
• entry_text_more
• entry_excerpt
• entry_keywords

そして記事に指定できる「エントリー・ファイル名」というのは entry_basename フィールドのことなのですが、この entry_basename は書き出しの項目には含まれていません。 デフォルトの個別エントリーアーカイブから URI を変更する場合の注意点で一度述べましたが、この entry_basename は Movable Type 3.0 から導入されたもので、 Movable Type 3.1x まではこの値を変更することはできず、また Import/Export の項目に含まれないため、非常に使い勝手が悪いものでした。

ただ、 Movable Type 3.2 になってこの値を変更することができるようになったため、これを活用するユーザは多くなっていると思います。 しかし、 Import/Export の項目は 3.2 以前のものをそのまま踏襲しているため、そのことを知らずに entry_basename を活用しているユーザがいざ Import/Export を行うと、今回のような問題に行き当たってしまうわけです。

entry_basename を自由に扱えるようになったのですから、 Import/Export の項目に含めて良いと思うんですけどねえ。 ちょっとサポートに問い合わせてみます。 Movable Type の個別記事の Permalink は、デフォルトの設定のままだと Export 時に失われるに続きます。

トラックバック送信先

月別アーカイブのリンクバグの原因が判明 - ゼロSP@BLOG

entry_basename が Import/Export の対象になっていないのは仕様ですが、自由に扱えるようになった以上 Import/Export できるようにした方が良いと思うので、サポートに問い合わせてみます。

BitBurger Pils

ドイツのピルスナービール。 ヨーロッパを代表する正統派のピルスナーとショップでは書いてありましたが、その通りと思える美味しさでした。 ……その分、他のビールのように特徴的な印象を抱かなかったので単に「美味しい」としか書けないのですが。 アルコール度数は 4.8% 。

はてなブックマークと dc:description の続き

はてなブックマークと dc:description にて、 rdf:RDF の記述やコンテントネゴシエーションがはてなブックマークの概要取得に影響を与えているんじゃないかなあと考えた件の続き。

引き続き IRC チャンネル #hxxk にて drry さん ( drry+@->Weblog ) やシンヤさん ( Hatena::Diary::Code-404 ) と共にああでもないこうでもないと実験しました。

はてなブックマークは Feed を探して概要を取得するみたい

自分の記事をいくつかブックマークしてみたのですが、その際にアクセスしてくる UA を見て気付いたこと。

4 回に渡って Hatena Bookmark/0.1 という UA でアクセスしてきた後に、最後に Feed::Find/0.06 という UA でアクセスしてきています。 ということは、やはり本文中の rdf:RDF 要素ではなくて Feed の description を取得しに行こうとしているみたいだ !

そこで、はてなブックマークと dc:description でもきちんと概要が取得されていた Lucky bag::blog の、「既に Feed には掲載されていない日付で、なおかつまだはてなブックマークにブックマークされていない」記事をブックマークしてみることにしました。 ( 勝手にテストさせていただきました、事後報告ですみません＞ e-luck さん ) すると、その前後の記事は ( おそらく最初にブックマークされた時点の ) Feed に含まれていた description がブックマークページの概要として取得されていますが、今回新たにブックマークした記事は Feed には掲載されていないためか、本文からブックマークページの概要が取得されました。

以前、概要が記述されるのは Feed ? meta 要素 ? RDF メタデータ ? で触れましたが、海馬日記 - Re: meta要素の使ひ道にて たとへばはてなダイアリーのフィードには最新の記事數件分(一定ではない模樣)しか掲載されません。 はてなダイアリーだけでなく、大抵のRSSがさうでせう。 此れでは昔の記事の概要は取得出來ません という指摘を受けていたことは正鵠を得ていたわけです。 Movable Type の場合は、デフォルトでは最新の 15 件の記事が Feed に反映されるため、仮にはてなブックマークの Feed::Find/0.06 が正しく概要を取得できる条件の weblog であっても、最新の 15 件の範囲でなければたちまち正しい概要を取得されることはなくなるのです。

Feed を提供していても概要が正しく取得されるとは限らない

しかし、 hxxk.jp でも Lucky bag::blog 同様に Feed は提供しています。 では何故概要が正しく取得されたり正しく取得されなかったりするのか ? 同じ Feed 提供とはいえ、以下のような違いがあることが分かりました。

1. まず最初に考えたのが「はてなブックマークは ATOM に対応していないんじゃないか ? 」ということ。そこで、 FeedBuener の提供形式を RSS 1.0 に変えてブックマークしましたが謎概要。
2. じゃあ FeedBurner による Feed じゃなくて、 Movable Type から生成した生 RSS 1.0 ( 何それ ) ならどうかとブックマークしましたが謎概要。
3. content:encoded で全文を提供しているから、そっちを見ているんじゃ ? Lucky bag::blog の RSS 1.0 は description しかないしということで RSS 1.0 から content:encoded を除外してブックマークしましたがやはり謎概要。

まとめそして一旦打ち切り

• はてなブックマークが取得する概要は、本文ではなく Feed から取得している
  • よって、 Feed に含まれない範囲の過去の記事は概要が取得されない
• Feed を提供していてもそれから正しく概要を取得するとは限らない

簡単にまとめるとこのようなことになります。 私としては Feedburner を使わずに RSS 1.0 を提供し、その中に content:encoded による本文掲載を行わなければ上手く行くかなあと思っていたんですが……。 これも上手く行かなかったのでこの問題は一旦放置することにします。

しかしそれはまだ良いとしても、 Feed に含まれない程度の過去の記事の概要が取得されないというのはぞんざいすぎやしませんか。 わざわざ Feed を探しに行かなくても、 dc:description が本文中にあるか無いかくらいの判断は実装できそうなものですけれど。

はてなブックマークと <$MTEntryExcerpt$> の続き

はてなブックマークと <$MTEntryExcerpt$> にて、 Lucky bag::blog は Movable Type 使用サイトだけれど、ちゃんとはてなブックマークは概要を見ているなあと気付いた件の続き。

IRC チャンネル #hxxk にて drry さん ( drry+@->Weblog またの名をミスドブロギ ) から 「 <$MTEntryTrackbackData$> の rdf:about の URI と、実際のリソースの URI が違うので別物扱いされているのでは ? もしくは rdf:RDF が 2 つあるのが影響しているかも」 といった指摘を受けました。

<$MTEntryTrackbackData$> の rdf:about の URI と、実際のリソースの URI

<$MTEntryTrackbackData$> をカスタマイズしたい & カテゴリを任意の順番でソートしたい - <$MTEntryTrackbackData$> の正体で触れましたが、 rdf:about には <$MTEntryPermalink$> にあたる URI が送られます。 hxxk.jp の場合はコンテントネゴシエーションを施した上で、 RemoveExtFromPermalink プラグインで <$MTEntryPermalink$> から拡張子を削除しています。 しかし、 <$MTEntryTrackbackData$> はショートカットタグであるため、このプラグインでは拡張子は削除されません。

ビール日記 2005/11/18 - サミクラウスという記事を例に挙げて考えてみましょう。 この記事の URI は http://hxxk.jp/2005/11/19/2340 ですが、実際は http://hxxk.jp/2005/11/19/2340.php という .php の拡張子のファイルがサーバ上には存在しています。 各種テンプレート内の <$MTEntryPermalink$> は http://hxxk.jp/2005/11/19/2340 として出力されますが、 <$MTEntryTrackbackData$> によって生成される rdf:about の URI は http://hxxk.jp/2005/11/19/2340.php として出力されているわけです。

2 つの rdf:RDF

hxxk.jp では、 <$MTEntryTrackbackData$> による rdf:RDF と、 Account Auto-Discovery による rdf:RDF が混在しています。

Account Auto-DiscoveryとTrackBack Auto-Discoveryを合わせる - 徒書によると、 どちらもRDFをXMLとして解析しているわけでなく、正規表現による検索で trackback:ping="url" や accountName="ID" 等を拾っているので、規定の記述から大きく外れていなければ何とか解釈してくれそうな感じです とのことなので、 2 つの rdf:Description を統合するのも良いかもしれません。

いくつかの Movable Type サイトを調べてみよう

Movable Type を使用していて、なおかつ <$MTEntryExcerpt$> を記事の先頭からの自動生成ではなく、手動で記述しているサイトをいくつか見て廻りました。

rdf:about が <$MTEntryPermalink$> と一致していない、あるいはそもそも rdf:about が記述されていない記事は、のきなみ謎概要になっていますね。 dc:description との紐付けができるかどうかが鍵なのでしょうか ? でも脳無しの呟きは rdf:about が記述されていないけれどきちんとした概要になっていますし、じゃあコンテントネゴシエーションをしているためか ? というと Lucky bag::blog がコンテントネゴシエーションをしつつきちんとした概要になっていますし。

まとめそして実験

これらのことより、次のような仮説を考えました。

• <$MTEntryTrackbackData$> を記事中に記述している
• コンテントネゴシエーションをしていない、あるいはコンテントネゴシエーションをしていても <$MTEntryPermalink$> を拡張子付きで生成している
  • <$MTEntryPermalink$> を拡張子無しで生成していても、 rdf:about も合わせて拡張子無しにしている

これらの条件が満たされればちゃんと概要を取得してくれるのではないか、ということです。 これからテンプレートを変更して、この記事をブックマークしてみて実験しようと思います。

Samichlaus Bier

オーストリアのトリプルボックラガービール。 元々はスイスで誕生したビールですが、現在はオーストリアで醸造されています。 アルコール度数が 14.0% と、かなりのハイアルコールの部類に入ります。 泡がほとんど立たず、非常に強い甘みが特徴的です。 ゆっくりと味わったのですが、気持ちよく酔ってしまいました。

Bière du Boucanier Blonde

先日のキャスティール ブロンドと同じ、ベルギーのトリプルゴールデンエール。 同じように香り高くて濃厚で甘味が強いビールです。 こちらの方がより香りが特徴的 ? ちなみにアルコール度数は 11.0% 。

はてなブックマークのコメントを収集して勝手に伝言ゲーム

以前から、複数名のブックマークコメントを収集してまとめてみたいなという考えがあったのですが、誰のコメントをサンプルにしようかと考えあぐねていたところでした。 何故そういったまとめをしたいと考えるのかというと、簡潔に表すなら「ブックマークコメントだけでそのブックマーク先の内容を知ることができるか」ということを試してみようということです。 weblog の伝言ゲームと言ってもいいかもしれません。 「本来の記事の作成者 → 各ブックマーカ → 私」という流れの伝言ゲーム。 どうせならブックマーク先の内容にあまり触れていない方が、より伝言ゲームとして面白いかなと思いました。

今回 ARTIFACT@ハテナ系 - はてブコメントの暴力性という記事があって、数名のブックマーカが取り沙汰されていたので、それらの方のブックマークコメントを収集してみました。 ある程度暴力的な ( とされる ) コメントは、どういった伝言ゲームの様相を呈する材料になるのでしょうか。

1. 読み進める前の注意あるいは前説
2. id:maroyakasa 編
3. id:French_Wooler 編
4. id:umeten 編
5. id:TakahashiMasaki 編
6. id:Leiermann 編
7. id:rAdio 編
8. id:ruku 編
9. id:kanose 編
10. 感想とかまとめとか

読み進める前の注意あるいは前説

• サンプルは無作為抽出でなく、 ARTIFACT@ハテナ系 - はてブコメントの暴力性で取り上げられた分を元にしているため、収集の時点である種のバイアスがかかっています。
• リンク論などをつらつらと羅列してみるで書いていますが、どういった感想を持ったか、自分なりにどういった要約をメモしたかを自ら曝け出すのがはてなブックマークのコメントです。
• よって、ブックマーカによってきちんと要約や感想が書かれていれば、ブックマーク先を見ずともある程度内容が把握できるはず。もしブックマーク先の中に既に私が読んだことがあるものがあった場合は、なるべくその内容を思い出さずに考えます。
• また、固有名詞などについてもなるべく知らないフリをします。「違いますよ○○は××ですよ ! 」とか突っ込まないように。
• 収集時点のブックマークコメントを数件ずつ引用して伝言ゲームをします。よって、この記事を書いた後に修正が行われていても、引用部を修正するつもりはありません。
• 各コメントに対する印象は、多分に私の主観が含まれていることを意識して見てください。

id:maroyakasa 編

id:French_Wooler 編

id:umeten 編

id:TakahashiMasaki 編

id:Leiermann 編

id:rAdio 編

id:ruku 編

id:kanose 編

感想とかまとめとか

もう少し荒唐無稽な伝言ゲームになるかなと思っていたんですが、意外と (?) きちんとブックマークコメントを書いている人が多くてネタ探しに苦労しました。 これから各ブックマーク先を読んで自分の想像との差異を楽しむことにします。

Google と dmoz

• ウェブディレクトリ - World > Japanese > コンピュータ > インターネット > ウェブ上の情報 > ウェブログ > ツール
• Open Directory - World: Japanese: コンピュータ: インターネット: ウェブ上の情報: ウェブログ: ツール

Lucky bag::blog: Google ウェブディレクトリと Open Directory Project にて、これらのページに掲載されていることを知りました。 dmoz の方はアクセス解析で何度か見かけていたので知っていましたが、 Google Directory の方は知りませんでした。

そしてうちは両方に掲載されていますけど、他の dmoz 掲載サイトの中には Google Directory には未掲載というところが確かにありますね。 反映されるまでのタイムラグ 説を支持したいところですが、 hxxk.jp に対する dmoz からのリファラは 10 月くらいから目にしていたような気もする……。

はてなブックマークに MTEntryExcerpt が反映されている ?

それでここからが本題。

• はてなブックマークの概要部分を編集できる裏技 - http://b.hatena.ne.jp/entry/ 以下の概要部分をいじることができるみたい
• はてなブックマーク正式版の気になる変更点 - 変更点 1 - 編集機能はバグでも裏技でもなかった
• 一つ一つの記事に含まれる概要と、その活用 - 概要が書かれている場合はそこから引用して欲しい

これらの記事で何度も述べたように、概要をちゃんと提供している我が hxxk.jp の記事がはてなブックマークにブックマークされると、その概要がスルーされて謎の概要が自動生成されるという件があったのですが、 Lucky bag::blog はちゃんと概要がそのまま使われていますね……何故だ。

Lucky bag::blog の被ブックマーク調査

はてなブックマーク - http://www.lucky-bag.com の新着エントリーから、 Movable Type によって作られている記事をいくつか抜粋してみます。

ちゃんと MTEntryExcerpt 部分が反映されています。

hxxk.jp の被ブックマーク調査

はてなブックマーク - http://hxxk.jp の新着エントリーから、 Movable Type によって作られている記事をいくつか抜粋してみます。

相変わらず謎概要……。

2 つのサイトに違いは無いはず

<$MTEntryTrackbackData$> をカスタマイズしたい & カテゴリを任意の順番でソートしたい - MTEntryTrackbackData の正体で触れましたが、 MTEntryExcerpt が使われている部分は、通常は <$MTEntryTrackbackData$> というショートカットタグが使われているため、カスタマイズはされていません。

実際に、 <rdf:Description ～ </rdf:RDF> の部分は Lucky bag::blog も hxxk.jp も同じ構造です。

……あ、一つだけ違う点があった。 hxxk.jp はカテゴリを使わずにキーワードで記事を分類しているので、 dc:subject="<$MTEntryCategory$>" 部分は空になっているんですが。 いやまさかそんなはずはねえ……。 とりあえずこの記事にカテゴリを設定して様子を見てみますか。

コメントスパム対策と実体参照を修正しました

コメントスパム対策と実体参照にて、実体参照と書くべきところを実態参照と書いていたので、修正しました。 ( title 要素も合わせて修正しました。 ) 誤りに気付いたのは entity = 実体 - 徒書からトラックバックをいただいたことによるものです。 北村曉さん ( 曉に死す ) 、ご指摘ありがとうございます。 以下、何故間違って書いていたかを振り返り、備忘としておきます。

元の語句を調べようとしなかった

entity reference という元の語句をちゃんと頭に入れていれば、実態参照というのは誤りだとすぐに気付くのですが、元の語句を調べることを怠っていたために間違ったまま覚えていました。

検索に頼りすぎていた

コメントスパム対策と実体参照を書く際に、「実体参照だったっけ実態参照だったっけ」という疑問は抱きました。 そこで「実体参照 実態参照」で Google 検索して、最初の検索結果ページにて実態参照の方が多く使われているようだったので、そのまま実態参照と書きました。

この考え方にまず誤りがあるのですが、多く使われている = 正しいということではないんですよね。 疑問に行き当たったら Google 検索で答えを得ようとすることが多いので、今後も気を付けないと。

仕様書をあたっていなかった

先ほど検索エンジンを変更して「実体参照 実態参照」で Yahoo! 検索したら HTML4 で使える文字実体参照が一番上に表示されました。 実はこの記事こそが 以前どこかのサイトで実体参照を網羅的に掲載しているサイトがあったと思う という記事で、仕様書からまとめたものであることが明記されています。

以前目にしたことがあって、それが仕様書から得られる情報であるというところまで知っていたはずなのに仕様書まで調べなかったのは私の怠慢です。

ふだん「仕様書によれば」みたいなこととか「本来の語句の意味は」みたいなことを言っているのにことごとく逆を行っていますね。 今回のミスを糧として自戒しないと……。

また、 DTDを参照しないXML文書(RSSとか)で使われることを考慮するならば、実体参照ではなく数値文字参照を使う方がよさそうな気がします といったことは考えが及んでなかったです。 数値の方が覚えやすいという理由で数値文字参照をずっと使っていました。

数値文字参照のトリビア

大したことじゃないんですが、覚えておくとちょっぴり便利かもしれないこと。 & や " 、あるいは Movable Type を使用している場合は $ を実体参照なり文字数値参照に置き換える機会が多くなると思いますが、いちいちどれがどの数値だったかを覚えなくても覚えなくても大丈夫。 と言ってもひとつだけは覚えないとなりませんが。

一般的なキーボード ( 何を以って一般的と言うんだと言われそうですが、この場合はヨドバシカメラやヤマダ電機等の店頭に並んでいるようなメーカー製パソコンのキーボードとします ) の 1 から 9 までのキーに書かれている記号を見てください。 そして、次に示す数値文字参照の早見表を見てください。

! の ! から、 ) の ) までは、キーボードに書かれている順番で数値文字参照の数値がインクリメンタルされている形になっています。 ということは、 ( ! を数値文字参照する機会はあまり無いので ) " の " を覚えておけば、そこから数えることで $ や & の数値文字参照を覚える必要が無い、というネタです。 もしくは「キーに書かれている数字」 + 32 = 「キーに書かれている記号の数値文字参照」という覚え方でも良いかも。

トラックバック送信先

entity = 実体 - 徒書

ご指摘を受けて該当記事を修正するとともに、「何故間違ったまま書いたか」を考えてみました。

weblog のデザイン比較 - 個別記事の URI 規則編

むだづかいにっき♂：ユーザーに罪はないけど、好きではないブログのデザインの例を見て、その中に URI 規則についての項目が無かったので自分で調べてみようと思いました。 URI 規則って実は重要だと思うのですが、それを weblog の選択基準にする人ってどれくらいいるんでしょうねえ。 私が Movable Type を選択した理由のひとつには URI 規則を自分の思い通りに設定できるという点がありましたが。

さて、一口に調べると言っても最近は weblog サービスの種類が増えていて把握しきれていないので、はてなブックマーク - 最近の人気エントリーで見かけた奥様、鼻毛が出ておりますことよ - ブログサービスの説明比較に挙がっているものを対象にしたいと思います。 あとこれら weblog サービスに含まれない weblog ツールもいくつか対象に入れてみます。

1. 記事内の用語定義
2. Movable Type の URI 規則
3. tDiary の URI 規則
4. rNote の URI 規則
5. blosxom の URI 規則
6. nDiary の URI 規則
7. sb の URI 規則
8. livedoor Blog の URI 規則
9. エキサイトブログの URI 規則
10. JUGEM の URI 規則
11. ココログの URI 規則
12. ヤプログ！の URI 規則
13. FC2ブログの URI 規則
14. Seesaa ブログの URI 規則
15. アメーバブログの URI 規則
16. goo ブログの URI 規則
17. ドリコムブログの URI 規則
18. Yahoo!ブログの URI 規則
19. Doblog の URI 規則
20. はてなダイアリーの URI 規則
21. 各 weblog の URI 規則一覧表
22. 修正・更新履歴

Movable Type の URI 規則

デフォルト設定では .../yyyy/mm/entrybasename.html となっていますが、設定次第でほぼ自由にカスタマイズすることができ、実際に Movable Type 使用の weblog を見ても色々な規則が見受けられます。

私が作成している hxxk.jp の場合はコンテントネゴシエーションを施して .../yyyy/mm/dd/HHMM という規則に基づいた無拡張子のリソースで提供しています。 これにより、実際に記事の内容を見なくても URI を見るだけで、記事が書かれた日時を容易に知ることができます。 また、各ディレクトリ毎にインデックスを生成していますので、アドレスバーにて URI を削っていくことで直感的に上位のディレクトリを辿ることができます。

同じく私が作成している Web Standards with MT ver.3.2 Strict の場合は .../category/sub-category/entrybasename という規則に基づいた無拡張子のリソースで提供しています。 こちらの場合は記事の日時よりも、その記事が属するカテゴリや記事自体の内容を URI から推し量ることに重点を置いています。

tDiary の URI 規則

.../?date=yyyymmdd となっていて、同一日内の見出しについては #pnn というフラグメント参照が付与されます。 また、 .../?date=yyyymm という URI にて月別アーカイブを表示するため、直感的に辿ることができると言えます。

いくつかの tDiary 使用 weblog を見て廻ったのですが、どこも同じ URI 規則だったので、おそらくこの部分はカスタマイズできないようになっていると思われますが、その分 URI から記事の日時を容易に知ることができます。

rNote の URI 規則

rinn@rNote や朝顔日記や CornerValley を見る限り自由にカスタマイズできるようです。 URI から記事の日時や内容を推し量ることができるかどうかは各作成者の方針に委ねられます。

blosxom の URI 規則

これも行動記録や煤 - Note や Note @ Temporary-Depot や Latest topics - outsider reflex を見る限り自由にカスタマイズできるようです。 URI から記事の日時や内容を推し量ることができるかどうかは各作成者の方針に委ねられます。

nDiary の URI 規則

津波荘や klee を見る限り、個別記事という単位では生成せず、 .../yyyymm.html という規則で生成される月別アーカイブが基本となるようです。 URI から記事の日時を容易に知ることができます。

sb の URI 規則

デフォルトでは .../log/eidEntryID.html という規則。 URI から記事の日時や内容を知ることはできませんが、同一 weblog 内では連番なので、大雑把に知ることができる場合もあります。

また、カテゴリごとにディレクトリを分けたり、 eidEntryID.html ではなく任意の文字列で個別記事の URI を作成したりといったカスタマイズが可能だそうですので、最終的には URI から記事の日時や内容を推し量ることができるかどうかは各作成者の方針に委ねられます。

livedoor Blog の URI 規則

.../archives/何らかの ID.html という規則の場合もあり、 .../archives/yyyy/mm/何らかの ID.html という規則の場合もあり。 後者は URI から記事の日時を大まかに知ることができますが、前者はできません。

エキサイトブログの URI 規則

http://UserAccount.exblog.jp/何らかの ID/ という規則で、恐らく固定の設定。 URI から記事の日時や内容を知ることはできません。

JUGEM の URI 規則

http://UserAccount.jugem.jp/?eid=EntryID という規則で、恐らく固定の設定。 URI から記事の日時や内容を知ることはできませんが、同一 weblog 内では連番なので、大雑把に知ることができる場合もあります。

ココログの URI 規則

/yyyy/mm/entrybasename.html という規則になっています。 ( おそらく TypePad ベースでることに起因するのでしょう。 ) 恐らく固定の設定。 URI から記事の日時や内容を推し量ることができます。

ヤプログ！の URI 規則

http://yaplog.jp/UserAccount/archive/EntryID という規則で、恐らく固定の設定。 URI から記事の日時や内容を知ることはできませんが、同一 weblog 内では連番なので、大雑把に知ることができる場合もあります。

FC2ブログの URI 規則

http://UserAccount.blogn.fc2.com/blog-entry-EntryID.html という規則で、恐らく固定の設定。 URI から記事の日時や内容を知ることはできませんが、同一 weblog 内では連番なので、大雑把に知ることができる場合もあります。

Seesaa ブログの URI 規則

http://HostName.seesaa.net/article/何らかの ID.html という規則で、恐らく固定の設定。 URI から記事の日時や内容を知ることはできません。

アメーバブログの URI 規則

http://ameblo.jp/UserAccount/entry-何らかの ID.html という規則で、恐らく固定の設定。 URI から記事の日時や内容を知ることはできません。

goo ブログの URI 規則

http://blog.goo.ne.jp/UserAccount/e/何らかの ID という規則で、恐らく固定の設定。 URI から記事の日時や内容を知ることはできません。 これまでの weblog サービスは数字のみの ID だったのに対し、英数交じりのランダムな文字列の ID 。

ドリコムブログの URI 規則

http://blog.drecom.jp/UserAccount/archive/EntryID という規則で、恐らく固定の設定。 URI から記事の日時や内容を知ることはできませんが、同一 weblog 内では連番なので、大雑把に知ることができる場合もあります。

Yahoo!ブログの URI 規則

http://blogs.yahoo.co.jp/UserAccount/何らかの ID.html という規則で、恐らく固定の設定。 URI から記事の日時や内容を知ることはできません。

Doblog の URI 規則

http://www.doblog.com/weblog/myblog/UserID/何らかの ID#何らかの ID という規則で、恐らく固定の設定。 URI から記事の日時や内容を知ることはできませんし、他のサービスと違ってユーザを識別する ID も数字のみなので、 URI だけだとどのユーザの weblog か分かり辛くなっています。

はてなダイアリーの URI 規則

http://d.hatena.ne.jp/UserAccount/yyyymmdd/Unix Time という規則もあったり、 http://d.hatena.ne.jp/UserAccount/yyyymmdd#Unix Time という規則もあったりと、 URI を見るだけで、記事が書かれた日時を容易に知ることができます。

また、時刻だけでなく、任意の文字列を設定して http://d.hatena.ne.jp/UserAccount/yyyymmdd/任意の文字列 として URI から記事の内容を推し量ることができるような設定も存在します。 ( →はてなダイアリーのヘルプ - 好きなname属性の見出しをつける（name属性付き見出し記法） )

ちなみに、「好きな name 属性の見出しをつける」は一律設定ではないので、 URI 自身の持つ情報に時刻を含ませたい場合と、内容を含ませたい場合を優先度においてその都度使い分けることが可能です。

各 weblog の URI 規則一覧表

これらの URI 規則を一覧表にしてみました。 ほとんどの項目はありか無しか、充実しているか充実していないかが基準になりますが、「カスタマイズ性」のみは他の項目によって基準が変化します。 ( 例えば、基本の URI 規則が良くない場合にカスタマイズ性が皆無だとどうしようもありませんが、基本の URI 規則が一定の基準を保っている場合は、カスタマイズできなくても問題は無いと考えます。 )

こうして見ると、ココログとはてなダイアリー以外の weblog サービスの URI 規則はどれも五十歩百歩という印象です。 URI から日付や内容を推測できることが重要なのか ? と思われる方もいらっしゃるでしょうが、私の場合はかなり重要です。

アクセス解析を見る場合に、ぱっと URI だけを見て日付を推測できれば「ああ、このリンク元は以前も見たなあ」というのがすぐ分かるのですが、日付を推測できなければ新たなリンク元かどうか分かりません。 それでも何度か繰り返し見れば、単なる数字でも覚えられないこともないのですが、 goo ブログほどランダム過ぎるとそれもままなりません。 あと Doblog は URI だけではユーザ自体の区別すら付け辛いので論外。

修正・更新履歴

2005-11-16T19:43:43+09:00

• 記事内の用語定義を追加しました。
• sb の URI 規則を追加しました。
• 各セクションの id を変更しました。
• Seesaa ブログの URI 規則の記述を修正しました。
• goo ブログの URI 規則の記述を修正しました。

Kasteel Bier Blond

ベルギーのトリプルゴールデンエール。 以前キャスティール ブリューンを飲んでその濃厚な甘さにびっくりしたのですが、この類のビールはゆっくり飲むと良いと言われたので、ゆっくり飲んでみたところ、その香りと濃厚な味わいを良く楽しむことができました。 ちなみにアルコール度数は 11.0% 。

[嘘]Liar's web のコメントスパム対策は是非再考を

[嘘]Liar's web:■エントリー編集ボタン（初）にコメントをしようと思ってプレビューしたら、プレビュー画面で表示されるはずのコメント本文が表示されません。 名前とメールアドレスと URL はプレビュー画面でも表示できているのに。 <$MTCommentPreviewBody$> をわざと外しているのかなとも思いましたが、わざわざそうする理由も無いでしょうし……。

じゃあ確認無しでコメントしてみるかと思ってもう一度最初から投稿してみると、今度は コメントの本文を入力してください。 というエラーが出る始末。

しょうがない、記事に書いてトラックバックを送るか……と思った際にふと思いついてプレビュー画面でもう一度コメントを入力して投稿すると、コメントが受け付けられてコメント保留の画面になりました。 おそらくプレビュー画面を経由しないとエラーを返すようなコメントスパム対策でしょうか。

はっきりと言わせてもらうと、仮にスパム対策としても現状のコメント周りは不親切極まりないと思います。 一旦プレビューをしないと投稿を受け付けないということはどこにも書かれていませんし、仮にそれが書かれていたとしても、プレビュー画面に遷移した際に一度記入したコメント本文が消えているのでは、コメントプレビューのテンプレートのエラーかと思ってしまう可能性がありますし、何より記入したコメントがクリップボード等に残っていなければまた記入しなければなりません。 是非とも再考をお願いします。

$ の実体態参照ってどう書くんだろう

さて、本来コメントしようとした内容は、 $ を実体参照で書くにはどうしたら良いかということ。 私は $ に限らず実体参照ではなく数値文字参照を使うタイプなので、 $ と書いてはどうでしょうかとアドバイスしました。

本当は実体参照で書く方法を教えたかったんですけど、手持ちの解説書の実体参照一覧表にも $ は掲載されていなかったので、数値参照の方で書き込んだのです。 どなたかご存知でしたら $ の実体参照コードを教えてください。 $ の実体参照は存在しないそうです。

以前どこかのサイトで実体参照を網羅的に掲載しているサイトがあったと思うのですが、見つけられませんでした。 WEB ARCHIVES だったけなあと思って leva さん ( Software Linkage ) が転載された XHTML/CSS リファレンス [WEB ARCHIVES REPRINT] をざっと眺めてみて、確かに XHTML 文字実体参照 [WEB ARCHIVES REPRINT] というリソースはありましたが、これにも $ については掲載されていませんでした。

トラックバック送信先

[嘘]Liar's web:■エントリー編集ボタン（初）

有り体に言ってコメント周りが不親切すぎるので、是非再考をお願いします。

住民票を取りに行ったら本人確認されなかったという話

• Pop or Die | 僕が確かに僕であることを証明する必要があるのではないかと思った

同居家族である母親の分の住民票を取りに行ったら、本人確認をされることなくすんなりと交付されたというお話。 まずポイントをまとめてみましょう。

• 本人以外の申請の場合には委任状が必要
  • ただし本人以外でも同居家族が申請する場合は委任状は不要
• 申請者自身の本人確認は行われなかった
  • 申請者が同居家族であるという根拠は ?
    • 申請者が同居家族でなくとも、委任状さえあれば ( 同居ではない家族を装って ) 他人の住民票を取ることもできるのでは ?

このへんの運用がどうなっているのか、この記事を読んで自分でも気になりだしたので調べてみました。 そういえば今年の 10 月から本人確認が義務付けられるといったニュースを目にしたようなしなかったような…… ?

1. 住民異動届の場合は本人確認を行うことが徹底されている模様
2. 住民票の請求自体には本人確認は不要と考えられている !?
3. 住民票の交付請求自体は誰のものでもできる !?
4. 考えられる抜け穴
5. トラックバック送信先

住民異動届の場合は本人確認を行うことが徹底されている模様

• NIKKEI NET：社会ニュース - 総務省、転出入届けで本人確認の徹底を通達
• 住民異動届の審査時における本人確認の厳格化　住民基本台帳事務処理要領の一部改正等

2005 年 2 月 23 日付けで通達が行われているようです。

本人が知らない間に他人が住民票を異動する「なりすまし住民異動届」を防ごうと、総務省は23日、全国の市区町村に窓口での本人確認を徹底するよう通達した。 役所で転居や転出入などの住民異動届を受け付ける際、届け出人に運転免許証やパスポートなど写真付き身分証明の提示を求める。 10月までに全国で実施する。

ああ、 10 月から義務付けられると私が思っていたのはこのニュースのことだったのですね。 それにしては住民異動届 本人確認 実施で検索すると各地の役所で実施時期がバラバラなのですが……。

一部の市区町村においては、既に実施済みのところもあり、今後、実施する市区町村は、住民への周知を図った上で、準備が整った市区町村から実施することとし、遅くとも平成１７年１０月１日から全国の市区町村で同様の取扱いとすることとしています。

なるほど、準備さえ整えば 10 月 1 日を待たずに実施して良いと。 まあ、今は既に 11 月なので全ての市区町村で実施されているはずです。

住民票の請求自体には本人確認は不要と考えられている !?

では、住民票の請求については本人確認は徹底されているのでしょうか ? soumu.go.jp 内で「住民票の請求 本人確認」で検索すると、 PDF ファイルが 1 件だけヒットします。 これを、住基および戸籍の部分だけ抜粋すると、次のような表になります。

これは住民基本台帳カードの利活用手法等に関する検討会 第３回会合（平成１７年９月２８日） 次第（資料）の中の資料の一部で、あくまで未定稿であり事務例であるので、全ての市町村が本人確認を行っていないとは断定できません。 しかし、住民票の請求自体には本人確認は不要であるというのが ( 役所間での ) 一般的な見解なのかもしれません。

住民票の交付請求自体は誰のものでもできる !?

本人確認をしないのだったら、誰だって住民票を請求できちゃうんじゃないの !? と思ったのですが、どうも住民基本台帳法自体がそのように定められているようです。

第12条 住民基本台帳に記録されている者は、その者が記録されている住民基本台帳を備える市町村の市町村長に対し、自己又は自己と同一の世帯に属する者に係る住民票の写し（第６条第３項の規定により磁気ディスクをもつて住民票を調製している市町村にあつては、当該住民票に記録されている事項を記載した書類。以下同じ。）又は住民票に記載をした事項に関する証明書（以下「住民票記載事項証明書」という。）の交付を請求することができる。 《改正》平11法133

２ 何人でも、市町村長に対し、自己又は自己と同一の世帯に属する者以外の者であつて当該市町村が備える住民基本台帳に記録されているものに係る住民票の写しで第７条第13号に掲げる事項の記載を省略したもの又は住民票記載事項証明書で同条第１号から第12号まで及び第14号に掲げる事項に関するものの交付を請求することができる。

この内容を分かりやすく解説したものが市民課職員の住民票の話３に書かれています。

住民票は「公開」だといっても、第３者の住民票を勝手にどんどんとれるということではなくて、法律でも「市町村長は、住民票の請求が不当な目的によることが明らかな場合は、これを拒むことができる。」と規定されています。

不当な目的とは、プライバシーの侵害につながるような場合です。 ただし、「プライバシー」という言葉は、条文には出てきません。 どういうものがプライバシーの侵害にあたるのかは、難しい問題です。

昨日、ちょうど市役所勤務の友人と会う機会があったのでさりげなく尋ねてみました。 「第三者の住民票を請求することができる正当な理由って何 ? 」と。

明確な実際の事例は教えてもらえませんでしたが ( それもそうだ ) 、例えば「お金を貸しているので、取り立てのために住所確認の名目で請求する場合」は間違いなく拒否されるそうです。 ( この例は請求事由以前に、「請求に係る人」の住所氏名が分からないので拒否されるケースでしょうけれど。 ) 逆に、例えば「ディーラーなどが車庫証明の手続きを行うために請求する場合」はたぶん受理するだろうとのこと。

よって、請求に係る人の住所氏名が分かっていて、なおかつ正当な請求事由があれば第三者でも住民票の請求は可能ということになります。

考えられる抜け穴

第三者の請求については、自分の住所氏名をきちんと明らかにできて、請求に係る人の住所氏名が判明していて、請求事由をしっかりと説明できないことには不可能ということになりますが、渦さんも示している通り 適当な家族のふりして年格好それっぽかったら どうなるのでしょうね ?

請求に係る人の住所氏名を調べて、なおかつ家族構成をある程度把握していれば、同居親族を装って請求すれば正当な請求事由も委任状も本人確認も必要無く請求できるということになってしまうような気がしますが。 誰でも交付請求ができることになっているとはいえ、本人および親族による請求と第三者による請求を分けて考えているのに、こういった抜け道を私や渦さんでも考えられるなら、せめて代理申請時には申請者の本人確認は行った方が良いと思うのですが。 ちなみに私の住んでいる所の場合は人口が少ないためか、そういったなりすまし請求を行っても一発で嘘とバレるので本人確認はあっても無くても変わりません。

トラックバック送信先

Pop or Die | 僕が確かに僕であることを証明する必要があるのではないかと思った

現状では、住民票の請求に関しては本人確認は不要だと考えられているようです。 ただ、現状の運用では親族になりすますことができる可能性を考えると、本人確認は行った方が良いと思います。

教える Movable Type

渦さん ( Pop or Die ) がよく教えるはてなダイアリー活動をなされているので、まねっこ ( 何か最近まねっこ多いな ) して教える Movable Type 活動でもしてみようかと。 おそらく過去の記事でも同じようなことをやっているものがあると思うので、それについてもキーワード設定を暇を見てやろうと思います。 あと 寡聞にしてこの方を存じ上げなかった と他人さん ( 他人の脳内 ) が仰っていましたが、他人さんと渦さんって接点が無かったのかと勝手にびっくり。 どちらも芸歴 (?) 長いのでどっかでニアミスしてそうだと思うのですが。

さてそれじゃ今回の教える Movable Type 活動。 Movable Type 3.2 - 858-861n の 858 さんの疑問に勝手に答えます。 というか久々に書き込もうと思ったらホスト規制で書き込めないから、こちらに書いて携帯から URI だけ書いて誘導しようというそんな心持ち。 そこまでする必要があるかというと多分無いと思います。 それと今日は久しぶりにスレッドを見て答えているだけなので、今後同様にスレッド内の疑問に答える確率は低いかも。

さて、スレッドに書かれていることを簡単にまとめてみると、 「カテゴリのソートをするために、カテゴリ名の先頭に番号を振っているけれど、それだと <$MTEntryTrackbackData$> にその番号が付いたカテゴリ名のまま出力されてしまうのでカスタマイズしたい」 ということだと思います。 勘違いだったらごめんなさい。

MTEntryTrackbackData の正体

以前概要が記述されるのは Feed ? meta 要素 ? RDF メタデータ ? - はてなダイアリーの head 要素内の RDF メタデータには dc:description が含まれていないでも書きましたが、 MTEntryTrackbackData はショートカットタグの一種で、次のような記述をテンプレート内に行ったのと同様の効果を一つのタグを書くことで実現します。 ( 今後、 Movable Type 自体のバージョンアップにより内容が変わる可能性があります。 )

<!--
<rdf:RDF xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"
         xmlns:trackback="http://madskills.com/public/xml/rss/module/trackback/"
         xmlns:dc="http://purl.org/dc/elements/1.1/">
<rdf:Description
    rdf:about="<$MTEntryPermalink$>"
    trackback:ping="<$MTEntryTrackbackLink$>"
    dc:title="<$MTEntryTitle encode_xml="1"$>"
    dc:identifier="<$MTEntryPermalink$>"
    dc:subject="<$MTEntryCategory$>"
    dc:description="<$MTEntryExcerpt$>"
    dc:creator="<$MTEntryAuthor$>"
    dc:date="<$MTEntryDate format="%Y-%m-%dT%H:%M:%S"$><$MTBlogTimezone$>" />

</rdf:RDF>
-->

カテゴリ名をトリミングする

さて、次にカテゴリ名をトリミングする方法を考えてみたいと思います。 858 さんがどのようなカテゴリ名にしているか分かりませんが、勝手に次のようなカテゴリ名にしていると仮定します。

1. 001-000-mt
   1. 001-001-template
   2. 001-002-plugin
2. 002-000-life
   1. 002-001-food
   2. 002-002-hobby

サブカテゴリを使っている可能性もあるので、 3 桁 - 3 桁の通し番号を振った例です。 Movable Type にはグローバル・タグ・アトリビュートとして trim_to という属性が用意されており、最初の N 文字を取り出すということが可能になっています。 しかし、この場合は最初の N 文字を取り出すよりも最初の N 文字だけ省きたいということですので、 trim_to では対応できません。

そこで、プラグインを使って機能を拡張することにします。 The blog of H.Fujimoto：カテゴリを任意の順番に並べ替えるに、そのまま実現方法が書いていますが、この記事中の cutfirstchar.pl を使えばカテゴリ名から最初の N 文字だけを省くことが可能になります。

解決例

前項のプラグインを用いてカスタマイズする例を考えてみます。 カテゴリのソートのために - まで含め 8 桁の通し番号を振っていますので、 cutfirstchar="8" として通し番号をカットして出力するようにしてみましょう。

<!--
<rdf:RDF xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"
         xmlns:trackback="http://madskills.com/public/xml/rss/module/trackback/"
         xmlns:dc="http://purl.org/dc/elements/1.1/">
<rdf:Description
    rdf:about="<$MTEntryPermalink$>"
    trackback:ping="<$MTEntryTrackbackLink$>"
    dc:title="<$MTEntryTitle encode_xml="1"$>"
    dc:identifier="<$MTEntryPermalink$>"
    dc:subject="<$MTEntryCategory cutfirstchar="8"$>"
    dc:description="<$MTEntryExcerpt$>"
    dc:creator="<$MTEntryAuthor$>"
    dc:date="<$MTEntryDate format="%Y-%m-%dT%H:%M:%S"$><$MTBlogTimezone$>" />

</rdf:RDF>
-->

強調部分が書き加えた箇所です。 858 さんがやりたいことを私が曲解していなければこれで解決すると思います。

箇条書きメソッド、あるいは何にでもメソッドをつけるとそれっぽくなるというメソッド

オイラのweb年表 - LIPPiN が面白かったので、まねっこしてはてなブックマーク de アバウトページに活用してみようと思いました。

Junkline - 今日は猛烈だった。でも思ったけど、箇条書きでテンポ良くまとめられていると読みやすいなあ。

はてなブックマーク - hxxk.jp に書いた年表のバックアップ

はてなブックマークのブックマークページは自由に編集できるので、自分が考えた分をここにバックアップしておきます。

1. 一番最初に購入したパソコンにバンドルされていた FrontPage Express を駆使して前身サイトの前身サイトのプロトタイプを立ち上げる。益体も無い内輪向けの日記が唯一無二のコンテンツ。というかほぼ毎日顔をつき合わせているのに web に書く意味って薄かった気がします。
2. HTML 解説本を買ってリニューアルを試みる。iframe 要素をフローティングフレームというのけぞる用語で称する怪しげな本をバイブルと仰ぎ迷走。( 今ぐぐったら microsoft.com の解説にも堂々と使われているんですねフローティングフレーム。 )
3. 前身サイトの前身サイトに見切りをつけて一旦サイト作成を休んだ頃に、 Another HTML-lint gateway の存在を知り、それと突き合せながら前身サイト作成。とりあえず 100 点を取ってみました的な div 多重サイト。
4. 確かこの前身サイトの頃に「mesh抜きでは日本におけるblog草創期を語れない」と言われるようなサイトにしていきたいですね。（言いすぎ？）騒動 ( いわゆる mesh 騒動 ) を目撃。特に言及はしなかったけど何言っているんだろうという感想を覚えた記憶あり。
5. 前身サイトも止め、再び潜伏。この頃に津波荘に出会い、 CSS による見栄えの分離ということに勝手に感銘を受ける。
6. mesh 騒動で嫌疑の目を向けていた Movable Type を何故か使おうと試みる。 どういう心境の変化だったかは忘れました。
7. 2004 年 8 月、 hxxk.jp を開設。初代スタイルは黒背景。
8. 2004 年 9 月、開設から 1 週間にも満たないうちにあるネタが大手ニュースサイトに取り上げられて驚きつつも、 IRC で親交のあった方とお会いするために大阪まで遠征。
9. 2004 年 10 月～ 11 月、 Movable Type のテンプレートを更にカスタマイズ。 2 代目スタイルになったけどやっぱり黒背景。
10. 2004 年 12 月、 IRC で親交のあった方の慶事があったので、東京まで遠征。人生初上京。発情今日って変換してくれた IME は流石だと思いました。
11. 2005 年 1 月、 Movable Type のテンプレートを配布開始。何人かの方がこのテンプレートを使って Movable Type を使ってくださっています、感謝。
12. 2005 年 6 月、サイトの構成も含めて大幅リニューアル。 3 代目スタイルにして初めて黒背景ではなくなる。また、 Musical Baton の経路をツリーにしてまとめた記事が色々なところで取り上げられる。
13. 2005 年 7 月、自分が言い出しっぺとなってオフ会ツアー敢行。しかし未だオフレポは 2 日目の前半までしか書いていません……。あと自宅が半壊
14. オフ会ツアー後に外国のビールに目覚める。
15. 2005 年 8 月、はてなグループ - 方言キーワードに参加。最近はあまり更新していませんが、また何かしらの方言ネタがあったら書いていくつもりです。そして、 6 月に書いた Musical Baton の記事がネットランナーに掲載される。一応人生初の雑誌掲載。
16. 2005 年 9 月、釈云麦という焼酎の存在を知り、ハマる。 e-luck さんと焼酎を通じてより親密に。
17. 2005 年 10 月、 Web Standards with MT ver.3.2 Strict テンプレートを公開。合わせて hxxk.jp テンプレートもこれをベースにしたものに変え、 4 代目スタイルに移行。より白くなりました。
18. 2005 年 11 月、秋の京都ツアーに参加。にゃおりんとシンヤさんと初顔合わせ。
19. 2005 年 12 月、冬のライブツアー実施。 Frigo に再び来店。
20. 2006 年 2 月、 5 代目スタイルへ変更。本文部分の背景は白で、それ以外の下地は黒。
21. 2006 年 3 月、春のもんじゃツアーに参戦。 lego さんと初顔合わせ。
22. 2006 年 4 月、異動により仕事内容が変わる。しかし hxxk.jp は何事も無かったように運営継続。
23. 2006 年 5 月、大阪ビールツアーに参戦。たっぷり堪能しました。
24. 2006 年 6 月、 VAIO type U を購入。モバイルコンピューティング環境をゲットし、書籍の打ち合わせのために上京。
25. 2006 年 8 月、 JILS のライブのために上京。
26. 2006 年 9 月、 MOMENT を作成し、気軽なアウトプットの場を確保。友人の結婚祝いのために上京。
27. 2006 年 11 月、 JILS のライブのために上京。ソフトバンクモバイルを脱会し、 au に改宗。
28. 2006 年 12 月、島根にてアサノさんと書籍の打ち合わせ。
29. 2007 年 2 月、共著で執筆した実践 Web Standards Design 発売。

Opera の実装が変だと思う

はてなリング - はてなCSSリング経由で trashcan+green (beta) - OperaとfirefoxのCSSでのhref属性値の扱いが違う。 これって後々気を付けなければならなくなりそうなのでメモ。 リンク先では href 属性値が http:// で始まるアンカーを外部リンクとしていますが、サイトによっては必ずしもそうではないことは覚えておいた方が良いかも。 ( hxxk.jp の場合は Copy URL+ を使ってアンカーを記述するので、自サイト内へのリンクでも http:// から始まります。 )

リンク先の記事を見て思った感想が、 operaは相対パスを絶対パスに変換してからhref属性値を扱い、firefoxは相対パスのままhref属性値を扱っているようだった というのは Opera の実装が変じゃない ? ということ。 quaa さん ( trashcan+green (beta) ) が 印刷用なんかにhref属性値を表示させたいときはoperaのように絶対パスが出る方がいい と仰る通り、絶対パスが出た方が便利な場面は確かにあります。

しかし、 CSS 3 Candidate Recommendation - Selectors を見ると、 E[foo^="bar"] というセレクタは an E element whose "foo" attribute value begins exactly with the string "bar" というように、 bar で始まる属性値にマッチするというセレクタですから、仮に絶対パスに変換するのなら href 属性値を扱った後に行うべきだと思います。 Opera 9.0tp1 の現状では、 http:// で始まっていない href 属性値も ( 絶対パスへの変換によって ) http:// で始まる属性値としてみなされてしまっているのですから。

逆の例を考えてみましょう。 quaa さんが trashcan+green (beta) における内部リンク ( この場合、 href 属性値が /quaa/ で始まるアンカーを指します ) にのみ特定のスタイルを反映させたいという場合も、 Opera 9.0tp1 では http://d.hatena.ne.jp/quaa/ という属性値として扱われ、内部リンクを指すはずのセレクタ ( 例 : a[href^="/quaa/"]::after{ content : "[in]"; } ) にマッチしないことになります。

ついでに content プロパティ関連の各ブラウザの実装の簡易まとめ

content プロパティによる文字列の扱いは Opera の方が好みなんですが、勝手に相対パスを絶対パスとして扱われるのは困ります……。 単純に content プロパティにて出力される際に変換されるならともかく、属性セレクタのマッチを調べる時点で変換というのは、 CSS を書く方にとっては煩わしいことうけあい。

トラックバック送信先

trashcan+green (beta) - OperaとfirefoxのCSSでのhref属性値の扱いが違う

パターンマッチを行う前に絶対パスに変換するのは、正しくない実装だと思います。

Pietar Chestnut Beer

フランスの栗の粉入りアンバービール。 物珍しさで買ったんですが、本当に栗の風味がします。 味わいは強めですが、苦味は控えめとなっているので飲みやすいビールでした。 ちなみにアルコール度数は 6.0% 。

小樽ビール ドンケル

小樽ビールのドュンケルビール。 濃色のビールで、カラメルフレーバーが特徴的。 これで Tour "2005 Autumn Kyoto" - オフ会といえばでいただいていた小樽ビールシリーズは終了。 ありがとうございました。 ちなみにアルコール度数は 5.2% 。

そろそろ見に廻るかな

はてなリング始動、とりあえずの雑感およびはてなリングに誤登録されていた ? と連続で扱ってきたはてなリングですが、参加することによるメリットがあまり感じられなかったので、自分のニーズにあった各種リングを見るだけにしようと思います。 はてなリング - 500 Internal Server Error も脱退。 気まぐれですみません。

短期間ではありましたが、実際にはてなリングを使った上で分かったことや、はてなリングについて触れている記事を見て分かったことをまとめておこうと思います。 なお、これは 2005 年 11 月 9 日時点で私がチェックできた範囲での情報なので、これ以外にも有用な情報はどこかに書かれています。 また、 10 日以降に新しい情報が出てきても、この記事に追記していくつもりは基本的にありません。 やっぱりちょっとだけ追記しました。

1. 不具合 : 登録サイト以外の記事もリング内の hotentry に掲載される ( 修正済 )
2. 不具合 : サイトの登録情報が正しくないものになる ( 修正済 ? )
3. 不具合 : サイトを一度削除してしまうと再登録ができない ( 未修正 )
4. 脆弱性 : リングロゴのコードに XSS 脆弱性が存在 ( 修正済 )
5. 活用例 : 有料コミュニティのモデルケース
6. 活用例 : 学校での活用例
7. 使用方法 : Feed を配信していないサイトをリングに登録する方法
8. 使用方法 : リング一覧を見るテクニック
9. 使用方法 : 作成できるリングの数
10. 使用方法 : その他 Tips 集
11. 使用方法 : ロゴが大きいのでどうにかしたい or target="_blank" なロゴのリンクをどうにかしたい or JavaScript オフの閲覧者にもリングのリンクを提供したい
12. 使用方法 : リングページにロゴ設置アイコンを表示するには

不具合 : 登録サイト以外の記事もリング内の hotentry に掲載される ( 修正済 )

はてなリング始動、とりあえずの雑感 - 何故 hxxk.jp が ? にてその実例に触れていますが、そのリングに登録されていないサイトの記事がリング内の hotentry に掲載されるという不具合がありました。

はてなリング日記 - 注目エントリーの不具合修正にもある通り、現在はこの不具合は修正されています。

不具合 : サイトの登録情報が正しくないものになる ( 修正済 ? )

はてなリングに誤登録されていた ? - 何故にくりらじ !? にてその実例に触れていますが、いくつかの Feed において本来登録されるべき情報が登録されず、無関係なサイトが登録されているように見える不具合がありました。 トラックバックをいただいた [観] はてなリングによると、私が確認したリング以外でも同様の不具合が発生していたようです。

はてなリング日記におけるアナウンスはありませんが、修正は行われている模様。

不具合 : サイトを一度削除してしまうと再登録ができない ( 未修正 )

先ほどの [観] はてなリングにて、登録を削除したサイトは同じリングに再登録できないという不具合が確認され、合わせてはてなアイデア - リングに一度参加したサイトを削除(退会)処理後、再度登録(入会)させようとしても登録できない(登録申請があったというメールは届くが管理画面には表示されず、承認もできない)というアイデアが出されています。

なお、この場合の再登録は同じ Feed で登録を行おうとすることを指すようです。 というのも、はてなリング - 500 Internal Server Error に参加する際に、 http://hxxk.jp/ で登録を行ったんですね。 その場合は RSS auto-discovery によって http://feeds.feedburner.com/hxxk という Feed が発見され、それで登録を行ったわけです。 その際にくりらじの件があったので一旦登録を止め、 http://hxxk.jp/appendix/rss.rdf の方で再登録を行っていました。 よって、同じサイトであっても、 URI が異なる Feed であれば再登録は可能なようです。 ( http://hxxk.jp/appendix/rss.rdf は、さとみかん徒然 (2) の件がどうしても解決しなかったので再び生成するようにしていたのです。 )

脆弱性 : リングロゴのコードに XSS 脆弱性が存在 ( 修正済 )

我らがけんたろたんが antipop - はてなにセキュリティ的な問題についてご連絡申し上げた件についてのメモにて指摘したもの。 ロゴの貼り付けを行うコードのサニタイズが不完全だったことと、 WinIE が MIME タイプよりもファイルの内容を優先してしまう謎実装なことが重なった場合に発生したようです。

はてなリング日記 - ロゴ貼り付け用 JavaScript のセキュリティホール修正についてにもある通り、現在はこの不具合は修正されています。

ちょっと本筋から外れますが、はてなブックマーク - antipop - はてなにセキュリティ的な問題についてご連絡申し上げた件についてのメモにて 2005年11月09日 mutronix 『[h*]1,2は一緒に書く必要あるんだろうか』 というコメントが書かれていたことについて。 ブックマークコメントの文字数は限られているためか、その疑問の理由までは書かれていませんが、 これだけの数の人間がブックマークしている 50% リリース論の中で 最低限の安全性は作りこまなくてはなりません と述べているにも関わらず XSS 脆弱性が存在していた、という事実をユーザが認識するためだと考えれば、並べて書く必要は充分にあると私は思いました。

活用例 : 有料コミュニティのモデルケース

かぶろぐ。 - はてなリングで有料コミュニティを構築できる？にて考えられているモデルケース。 ポイント送信者と RSS の紐付けが難しいかも、と思ったらはてなダイアリーユーザに限定することでその問題をクリアしていますね。 実行するかどうかは置いておいて、面白いアイデアかもしれません。

活用例 : 学校での活用例

大東亞外接日誌 - 気が付いたらこんなサービスが経由ではてなリング - 津山高専情報工学科。 情報処理の授業と Web サービスで触れた学校も、こちらを活用するとより面白くなるかもしれません。

使用方法 : Feed を配信していないサイトをリングに登録する方法

Take it easy - HTMLサイトのはてなリング登録方法にて、なんでもRSS 0.1b を利用して Feed を配信していないサイトをリングに登録する方法が詳細に解説されています。 HTMLサイト という表現が謎ですが、恐らく weblog ツールや weblog サービスを使っておらず、 Feed を配信していないサイトを指しているのだと思います。 ( まあ weblog ツールや weblog サービスを使っていれば必ず Feed を配信しているわけでもありませんし、そういったものを使わずにサイトを作っていても何らかの方法で Feed を配信している場合もありますが。 )

使用方法 : リング一覧を見るテクニック

この記事を書いている時点では、リングの一覧ページは準備されていませんし、一覧を見る方法も公式には紹介されていません。 ( 自分のリング一覧や、最新リングの一覧、リングに設定されたタグの一覧を見ることはできます。 )

あそびや in はてな - はてなリングの一覧で紹介されている、リング検索のクエリを半角空白にして全リングを取得する方法を用いればリング一覧を見ることができます。

なお、はてなアイデア - リング一覧が欲しい。タグ一覧ではなく、すべてのリングをリスト化したもの。リングの名前、日付、参加人数などでソートできるような。というアイデアが出されていますので、今後リング一覧ページまたはリング一覧表示機能が実装される可能性があります。

使用方法 : 作成できるリングの数

烏鹿庵 - はてなリング開始にて はてなリング - ヘルプには 作成できるリングの上限は5つまでです。 とありますが、これは メインアカウントで5つまでなのかサブアカウントを含めたアカウントで5つなのか不明瞭 という疑問が出ています。

その後、烏鹿庵 - はてなリングを使って雑感にて 1アカウントにつき5つまでのリングを主催できる(ようだ) という実験結果が示されています。 ということは、サブアカウントを駆使すれば最大 15 個のリングを作れることになりますね。

使用方法 : その他 Tips 集

Serendipity - はてなリングTip's（自分用memo）にて実際に使用してみての Tips が多数メモされています。

何故にくりらじ !?

モニタの前の皆さん今晩は。 毎夜毎晩世界各国のビールを片手に MT のテンプレートやはてダやはてブやその他諸々について語るコーナー hxxk.jp のお時間、パーソナリティは " ダイエットのためにビールを絶つならその分事前に運動したるわ ! " と意思が強いのか弱いのか分からないと評判の真琴です。 日々の消費カロリーは自転車操業 !

先日リリースされたばかりのはてなリング略してはてリ、何故だかさぶてくリングの hotentry に我が hxxk.jp が祭り上げられているという事態が起こったために、けんたろたんに何で何でと聞いてみたけどけんたろたん自身も何故かは分からず、なんらかのバグが絡んでいるのだろうと見ているというのが前回までのお話。

その前回の時には話題にしなかったんですけど、さぶてくリングの中に「～くりらじ～ 最新放送」というサイトがあって、しかもそのリンク先は http://subtech.ring.hatena.ne.jp/ になっていて訳が分からなすぎたのでこれもけんたろたんに聞いたんですよ。 「～くりらじ～ 最新放送って何さ」と。 これも何故存在するのか分からないということだったので見なかったことにしていたのですけど、内部エラーリングに hxxk.jp で参加したはずが、何故か hxxk.jp の名前が挙がるべきところが「～くりらじ～ 最新放送」に ! そしてそのリンク先も http://error.ring.hatena.ne.jp/ になっていてやっぱり訳が分かりません ! ウチはいつのまにかくりらじのコーナーとして認知されていたんですか、そこんとこどうなんですか !

……と、くりらじが Web ラジオのサイトということに絡めてラジオ風な文章を考え、今日帰宅したらネタにしようとか考えてここまで書いたのに、実際帰宅してみるとちゃんと修正されていて嬉しいような哀しいような。 スクリーンショットを取っていなかったのですが、確かにはてなリング - subtech やはてなリング - 500 Internal Server Error にくりらじとして登録されていました。 謎だ。

本人による登録と第三者による登録

さてここからは通常の口調に戻ります。 はてなリング始動、とりあえずの雑感に、yてらいの日記 - はてなリングで重要なのは，参加しているリングのロゴを自分のブログに設置する，ということというトラックバックが寄せられました。

自分が登録したリングのロゴだけをブログに設置すれば，勝手に知らないリングに登録されても，第三者が見たときに判断が付けられる．

なるほど、確かに参加リングのロゴを掲げておけば自分の意志で登録したのか第三者が登録したのかの区別は付けられますね。 ただ、はてなリングを全く使用しない人、「はてななんてそもそも知らないし」という人の場合に有効ではなくなってしまう点がネックかも。

ちなみに、本人による登録と第三者による登録を区別する手段としては、登録時に Account Auto-Discovery の有無があるかどうかをチェックして、リング画面に反映するという手法も考えられます。 もちろん、サイト毎に登録を行った人の ID を記録するだけでも良いのですが。 私は第三者による登録自体は構わないと考えていますが、いつ誰が登録したのかは公にして欲しいなと思っています。

……と、これもロゴを設置している人はリング画面でその旨表示されていますね。 少なくともリング画面でロゴ設置アイコンが表示されていれば、本人が登録あるいは第三者による登録でも充分に認知しているとみなせますね。

現時点でのまとめ

• 今日未明までは hxxk.jp で登録すると何故かくりらじとして登録されていた
  • その状態ではてなリング - subtech に誰かが登録を行った、あるいは何らかのバグで登録状態になったため、はてなリング - subtech の hotentry に表示されていた
• 今日の昼ごろに誤登録情報が修正される
  • はてなリング - subtech の登録状態も合わせて (?) 解除される
• 登録されたサイト以外の記事が hotentry に登場していた ? 状態も修正される

こういった感じでしょうか。 最初から Beta が付いていないサービスの割には、今日未明の時点ではなかなかカオスな状態だったような……。

はてなリングサービス開始

• はてなリング日記 - 新サービスはてなリングリリース

開始したてということで、どういったものに成長するか分かりませんが、私はおそらく「参加しての」活用はテスト目的いがいでは行わずに、傍観者としてネタ帳的に活用していくと思います。 はてなリングに限ったことではないのですが、自サイト以外にて活動を分散するほどキャパシティが無いというのが主な理由。 はてなグループ - 方言キーワードだけは hxxk.jp とは全く接点が無いので参加していますが。

とりあえず、自分にとって役立ちそうなリングの RSS を Bloglines に登録。

• はてなリング - Movable Type
• はてなリング - Firefox ユーザーリング
• はてなリング - サイクリング
• はてなリング - Hatena::Ring::CSS
• はてなリング - 500 Internal Server Error
• はてなリング - subtech
• はてなリング - Guinness
• はてなリング - iPod

役立つという基準以外にも自分の趣味のものも混じっていますが。

何故 hxxk.jp が ?

はてなリング - subtech の注目エントリに何故か hxxk.jp が挙がっています。 はてなリングのヘルプを見ると、

たとえば、いつも集まる車友達がいて、そのみなさんがブログを持っている場合。 carリングを作って、友達みんなをリングに誘いましょう。 すると、

リングアンテナで新着記事をチェック

リングメンバーの誰かのブログはアンテナが変わりにチェックしてくれます。 リングページを見れば、新着記事だけを効率的に読むことができます。

リング掲示板でコミュニケーション

次の集まりの予定、イベントの予定、質問などなどリングメンバーとの会話は掲示板で。 リングメンバーだけが書き込める専用スペースです。

注目のエントリー

新着記事の中でも、みんなに読まれるホットな記事は注目エントリーとしてピックアップ。 重要な記事も見落としません。※1

リングのタグで特定の話題をまとめ読み

リングメンバーの記事につけられたタグを見て、特定の話題をまとめてチェック可能です。 「car」タグを選べばリングメンバーによる車の話題が、「web」タグを選べばリングメンバーによるウェブの話題を一覧することができるでしょう。※2

リングロゴでつながる

リングのロゴは、お使いのブログに貼り付けられるようになっています。 またロゴには同じリングに参加している人のサイトが巡回できる機能が付いています。

と説明されています。 これを簡潔にまとめると、リングメンバーの記事の新着情報をチェックしたり、リングメンバーの hotentry をピックアップしたり、ということですよね ? 何故ついさっき初めて見たはてなリング - subtech のリングメンバーになっているのでしょう ?

リングメンバーであるけんたろたん ( antipop ) に IRC で尋ねてみましたが、けんたろたんも何故 hxxk.jp が挙がってきているかは分からないとのこと。 むむむ。

なるほど

裏紙草子 - はてなリングにて前項の疑問は解決。 人様のダイアリ・ブログを勝手にリング登録してしまえるようだ とのこと。 はてなリング - subtech もけんたろたん以外の誰かが登録したのかなあ。

そのリング自体の目的が不純であるとか、あたかもそのリングに自主的に登録したと見せかけて貶めるといった意図があるとかでなければ hxxk.jp を登録されることは一向に構わないんですが、本人以外でも登録でき、そして本人が登録したのか第三者が登録したのか分からないという現状では、第三者による登録を快く思わない人も少なからずいそうですね。

あ、はてなリング - subtech のどなたか存じませんが、もし何らかの定期チェックを行うために登録したのなら、私はそれを非常に嬉しく思います。 前項で何故登録されたか疑問に思ったり、リングの仕様に苦言を呈していたりはしていますが、「登録を外せ」ということではありませんので。

試しに

はてなリング - 500 Internal Server Error に参加してみました。 登録 URI は http://hxxk.jp/ で。 すると、とたんにはてなリング - 500 Internal Server Error - 注目エントリーにはてなリング - subtech - 注目エントリーと同じような記事がずらずらと。 ……ということは、前項の仮定は成り立たないということに ? 何か色々謎。

それと、 http://hxxk.jp/ で参加した後、 IRC でまきかずひこさん ( 底なし井戸の底の底 ) の了承を得て、 http://kaz.topaz.ne.jp/well/ で参加してみました。 ( 第三者による登録のチェック )

どちらも id:hxxk でログインした状態で参加申請をしたのですが、重複エラーの類など起こらずに登録できました。 これは裏紙草子 - はてなリングでも言われているように、後々いさかいの原因になる可能性は充分にありそうですね……。

まだ試したてなのでまとまりがありませんが一旦ここで記事を終了。 おそらく今日明日あたりでまた多くの人から何らかの指摘や意見などが出ると思うので、静観してみようと思います。

コメント / トラックバックの有無および受信の可否で表示を切り替える

今回は、 Web Standards with MT ver.3.2 Strict のテンプレートを例に出して Movable Type のテンプレートタグの活用方法を紹介します。 デフォルトテンプレートとは少々異なる書き方をしていますので、以後読み進める場合はテンプレートをダウンロードして、記事とテンプレートを見比べるとより理解しやすいと思います。 ( ←抱き合わせ商法 ( ←お金を取っているわけではありませんが ) )

ダウンロードされましたら、 archive_templates\individual_entry_archive.txt をご覧下さい。 79-109 行および 116-281 行の記述が今回のポイントとなります。 なお、今回は実例の紹介に留め、実際のテンプレートタグについては解説しません。 いずれ解説を行うかもしれませんが、テンプレートを見て分からない点があれば遠慮なくご質問ください。 また、 Movable Type 3.2x ではデフォルトテンプレートの記述でもこれに近い切り替えが実装されています。

今回紹介する例は、コメントやトラックバックが寄せられているか寄せられていないか、コメントやトラックバックの受信を行うようにしているかしていないかの各パターンにおいて生成される結果を変更する、というものです。 いくつかの組み合わせが考えられますが、そのパターンによってテンプレートを変更することなく、条件式タグを用いることで 1 つの記述で全てのパターンに対応できるように工夫しています。

1. これまでにコメントが寄せられておらず、コメントの受信を行わない場合の例
2. これまでにコメントが寄せられており、コメントの受信を行わない場合の例
3. これまでにコメントが寄せられておらず、コメントの受信を行う場合の例
4. これまでにコメントが寄せられており、コメントの受信を行う場合の例
5. これまでにトラックバックが寄せられておらず、トラックバックの受信を行わない場合の例
6. これまでにトラックバックが寄せられており、トラックバックの受信を行わない場合の例
7. これまでにトラックバックが寄せられておらず、トラックバックの受信を行う場合の例
8. これまでにトラックバックが寄せられており、トラックバックの受信を行う場合の例
9. 早見表

これまでにコメントが寄せられておらず、コメントの受信を行わない場合の例

まず、既存のコメントが無くコメントの受信も行わない場合を見てみましょう。 記事の作成時点からコメントを受信しないようにしている場合があてはまると思います。

この場合、記事の冒頭の概要欄の「コメント n 件」という項目自体が生成されず、コメント機能自体が無いように見えることになります。

また、コメントが投稿されていないのでコメントの表示は不要ですし、コメントの受信も行わないためコメントフォームも生成しません。

これまでにコメントが寄せられており、コメントの受信を行わない場合の例

次に、最初はコメントを受信するようにしていて既に 1 件以上のコメントが寄せられており、その状態からコメントの受信を行わないように変更した場合を見てみましょう。 いわゆるコメント欄を閉じた状態ですね。

この場合、既にコメントは寄せられているので記事の冒頭の概要欄の「コメント n 件」という項目は生成され、コメント表示欄へのフラグメント参照を示したリンクが付加されます。

また、既にコメントが投稿されているのでそれらのコメントの表示はする必要がありますが、これ以降コメントの受信は行わないためコメントフォームの生成は不要です。 よって、「現在、コメント投稿は受け付けていません。」という表示を行っています。

これまでにコメントが寄せられておらず、コメントの受信を行う場合の例

今度は、まだコメントは寄せられていないが、コメントの受信を行うようにしている場合を見てみましょう。 言い換えればコメント受付中だけどまだ 0 件という状態です。

この場合、まだコメントは寄せられていないので記事の冒頭の概要欄の「コメント 0 件」という項目は生成されますが、コメント表示欄へのフラグメント参照を示したリンクは付加しないようにしています。 ( まだコメントが無い状態なので、リンクによる誘導を行う必要が無いためです。 )

コメントが投稿されていないので「まだコメントは寄せられていません。」という表示を行い、合わせてコメントフォームを生成します。

これまでにコメントが寄せられており、コメントの受信を行う場合の例

そして、既に 1 件以上のコメントが寄せられており、継続してコメントの受信を行うようにしている場合を見てみましょう。

この場合、既にコメントは寄せられているので記事の冒頭の概要欄の「コメント n 件」という項目は生成され、コメント表示欄へのフラグメント参照を示したリンクが付加されます。

また、既にコメントが投稿されているのでそれらのコメントの表示を行い、合わせてコメントフォームを生成します。

これまでにトラックバックが寄せられておらず、トラックバックの受信を行わない場合の例

ここからはトラックバック編です。 まず、既存のトラックバックが無くトラックバックの受信も行わない場合を見てみましょう。 記事の作成時点からトラックバックを受信しないようにしている場合があてはまると思います。

この場合、記事の冒頭の概要欄の「トラックバック n 件」という項目自体が生成されず、トラックバック機能自体が無いように見えることになります。

また、トラックバックが投稿されていないのでトラックバックの表示は不要ですし、トラックバックの受信も行わないためトラックバック情報も生成しません。

これまでにトラックバックが寄せられており、トラックバックの受信を行わない場合の例

次に、最初はトラックバックを受信するようにしていて既に 1 件以上のトラックバックが寄せられており、その状態からトラックバックの受信を行わないように変更した場合を見てみましょう。 いわゆるトラックバック欄を閉じた状態ですね。

この場合、既にトラックバックは寄せられているので記事の冒頭の概要欄の「トラックバック n 件」という項目は生成され、トラックバック表示欄へのフラグメント参照を示したリンクが付加されます。

また、既にトラックバックが投稿されているのでそれらのトラックバックの表示はする必要がありますが、これ以降トラックバックの受信は行わないためトラックバック情報の生成は不要です。 よって、「現在、トラックバック送信は受け付けていません。」という表示を行っています。

これまでにトラックバックが寄せられておらず、トラックバックの受信を行う場合の例

今度は、まだトラックバックは寄せられていないが、トラックバックの受信を行うようにしている場合を見てみましょう。 言い換えればトラックバック受付中だけどまだ 0 件という状態です。

この場合、まだトラックバックは寄せられていないので記事の冒頭の概要欄の「トラックバック 0 件」という項目は生成されますが、トラックバック表示欄へのフラグメント参照を示したリンクは付加しないようにしています。 ( まだトラックバックが無い状態なので、リンクによる誘導を行う必要が無いためです。 )

トラックバックが投稿されていないので「まだトラックバックは寄せられていません。」という表示を行い、合わせてトラックバック情報を生成します。

これまでにトラックバックが寄せられており、トラックバックの受信を行う場合の例

そして、既に 1 件以上のトラックバックが寄せられており、継続してトラックバックの受信を行うようにしている場合を見てみましょう。

この場合、既にトラックバックは寄せられているので記事の冒頭の概要欄の「トラックバック n 件」という項目は生成され、トラックバック表示欄へのフラグメント参照を示したリンクが付加されます。

また、既にトラックバックが投稿されているのでそれらのトラックバックの表示を行い、合わせてトラックバック情報を生成します。

早見表

Web Standards with MT ver.3.2 Strict を使われている方がいました

まだステージング段階のようで、トップページには休止中と書いてあるので具体的な URI は出しませんが、 Web Standards with MT ver.3.2 Strict をダウンロードして使用されている方がいらっしゃいました。 ありがとうございます。

そうして客観的な目で自分のテンプレートを見直す機会を得たわけですが、そのおかげで致命的なミスと小さなミスを発見することができました。 以下にその内容と対処方を羅列します。 既に ver.1.00 および ver.1.01 をお使いの方にはご迷惑をおかけしますことをお詫び申し上げます。

1. index_templates\archives.txt の内容が全く違うものになっていた
2. 月別アーカイブへのリンクが間違っている箇所があった
3. パンくずリストに対するスタイル指定が間違っていた
4. トラックバック送信先

index_templates\archives.txt の内容が全く違うものになっていた

これは ver.1.00 の頃からだったのですが、 archives.txt の内容が main_index.txt のものと同じになっていました。 ver.1.01 以前をお使いの方は、 ver.1.02 をダウンロードして正しい archives.txt をお使いください。

ダウンロードや解凍をやり直すのが煩わしいという方のために、 ver.1.02 の archives.txt の内容を転載しておきます。

<?xml version="1.0" encoding="<$MTPublishCharset$>" ?>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
<html xmlns="http://www.w3.org/1999/xhtml" lang="<$MTDefaultLanguage$>" xml:lang="<$MTDefaultLanguage$>">
  
  <head profile="http://purl.org/net/ns/metaprof">
    
    <meta http-equiv="Content-Type" content="text/html; charset=<$MTPublishCharset$>" />
    <meta name="generator" content="Movable Type <$MTVersion$>" />
    <meta name="description" content="<$MTBlogName encode_html="1" remove_html="1"$>の全ての記事のタイトルを、時系列で羅列したページ。" />
    <title><$MTBlogName encode_html="1" remove_html="1"$> : 全記事アーカイブ</title>
    <link rel="stylesheet" href="<$MTBlogURL$>styles-site.css" type="text/css" />
    <link rel="alternate" href="<$MTBlogURL$>atom.xml" type="application/xml" title="Atom" />
    <link rel="alternate" href="<$MTBlogURL$>index.xml" type="application/xml" title="RSS 2.0" />
    <link rel="EditURI" href="<$MTBlogURL$>rsd.xml" type="application/xml" title="RSD" />
    <link rel="start" href="<$MTBlogURL$>" title="<$MTBlogName encode_html="1" remove_html="1"$> : メインページ" />
    <MTBlogIfCCLicense>
      <$MTCCLicenseRDF$>
    </MTBlogIfCCLicense>
    
  </head>
  
  <body class="master-archive-index" id="hxxk-wsmt32-strict">
    
    <ol id="hierarchical-menu">
      <li><a href="<$MTBlogURL$>" title="ホーム"><$MTBlogName encode_html="1" remove_html="1"$></a></li>
      <li>全記事アーカイブ</li>
    </ol>
    
    <h1><$MTBlogName encode_html="1" remove_html="1"$></h1>
      
      <div class="section entries" id="archive">
        
        <h2>時系列による全記事タイトル一覧</h2>
          
          <ol>
            <MTArchiveList archive_type="Monthly">
              <li><a href="<$MTArchiveLink$>"><$MTArchiveTitle$></a>
                <ol>
                  <MTEntries sort_order="descend">
                    <li><$MTEntryDate format="%x %X"$> - <a href="<$MTEntryPermalink$>"><$MTEntryTitle remove_html="1"$></a></li>
                  </MTEntries>
                </ol>
              </li>
            </MTArchiveList>
          </ol>
          
      </div><!-- div#archive END -->
      
      <dl id="menu">
        
        <dt>検索</dt>
        <dd>
          <form method="get" action="<$MTCGIPath$><$MTSearchScript$>">
            <fieldset>
              <legend><label for="search">全文検索フォーム</label></legend>
              <p>
              <input type="hidden" name="IncludeBlogs" value="<$MTBlogID$>" />
              <input type="text" id="search" name="search" size="25" value="検索語句を入力" />
              </p>
              <p>
              <input type="checkbox" id="CaseSearch" name="CaseSearch" /><label for="CaseSearch">大文字・小文字を区別する</label>
              </p>
              <p>
              <input type="checkbox" id="RegexSearch" name="RegexSearch" /><label for="RegexSearch">正規表現で検索する</label>
              </p>
              <p>
              <input type="submit" id="submit" value="検索する" />
              </p>
            </fieldset>
          </form>
        </dd>
        
        <MTIfArchiveTypeEnabled archive_type="Category">
          
          <dt>カテゴリ別もくじ</dt>
          <dd>
            <MTTopLevelCategories>
              <MTSubCatIsFirst><ul></MTSubCatIsFirst>
                <MTIfNonZero tag="MTCategoryCount">
                  <li><a href="<$MTCategoryArchiveLink$>"<MTIfNonEmpty tag="MTCategoryDescription"> title="<$MTCategoryDescription$>"</MTIfNonEmpty>><MTCategoryLabel></a> (<$MTCategoryCount$>)
                  <MTElse>
                    <li><MTCategoryLabel>
                  </MTElse>
                </MTIfNonZero>
                <MTSubCatsRecurse>
                </li>
                <MTSubCatIsLast></ul></MTSubCatIsLast>
            </MTTopLevelCategories>
          </dd>
          
        </MTIfArchiveTypeEnabled>
        
        <MTIfArchiveTypeEnabled archive_type="Monthly">
          
          <dt>月別もくじ ( <a href="<$MTBlogURL$>archives">全記事アーカイブ</a> )</dt>
          <dd>
            <MTArchiveList archive_type="Monthly">
              <MTArchiveListHeader><ol></MTArchiveListHeader>
                <li><a href="<$MTArchiveLink$>"><$MTArchiveTitle$></a> (<$MTArchiveCount$>)</li>
              <MTArchiveListFooter></ol></MTArchiveListFooter>
            </MTArchiveList>
          </dd>
          
        </MTIfArchiveTypeEnabled>
        
        <dt>最近の記事タイトル</dt>
        <dd>
          <ol>
            <MTEntries lastn="10">
              <li><a href="<$MTEntryPermalink$>"><$MTEntryTitle remove_html="1"$></a></li>
            </MTEntries>
          </ol>
        </dd>
        
      </dl><!-- dl#menu END -->
      
      <dl id="footer">
        
        <dt>Feed ( <a href="http://www.sixapart.com/about/feeds">Feed とは</a> )</dt>
        <dd>
          <ul>
            <li><a href="<$MTBlogURL$>atom.xml">Atom</a></li>
            <li><a href="<$MTBlogURL$>index.xml">RSS 2.0</a></li>
          </ul>
        </dd>
        
        <MTBlogIfCCLicense>
          
          <dt>ライセンス</dt>
          <dd>
            <p>
            <$MTBlogName encode_html="1" remove_html="1"$>は、<a href="<$MTBlogCCLicenseURL$>"><img src="<$MTBlogCCLicenseImage$>" alt="クリエイティブ・コモンズ・ライセンス" /></a>で保護されています。
            </p>
          </dd>
          
        </MTBlogIfCCLicense>
        
        <dt>各種ツール・素材</dt>
        
        <dd>
          <ul>
            <li>Powered by <a href="http://www.sixapart.jp/movabletype/">Movable Type <$MTVersion$></a></li>
            <li>Template by <a href="http://hxxk.jp/template/mt_3_2_strict/">Web Standards with MT ver.3.2 Strict</a></li>
            <li><a href="http://openlab.ring.gr.jp/k16/htmllint/htmllint.cgi?ViewSource=on;HTTPHeader=on">Check with Another HTML-lint</a></li>
          </ul>
        </dd>
        
      </dl><!-- dl#footer END -->
      
  </body>
  
</html>

月別アーカイブへのリンクが間違っている箇所があった

これは Web Standards with MT ver.3.2 Strict のサンプル weblog の当初の設定が残ったままになっていたのですが、 <$MTArchiveDate format="%Y/%m/"$> と書くべき部分を <$MTArchiveDate format="%Y%m/"$> と書いていました。 これは次に羅列するテンプレートに見られる誤りです。

• archive_templates\individual_entry_archive.txt
• system_templates\comment_error.txt
• system_templates\comment_pending.txt
• system_templates\comment_preview.txt

ver.1.02 をダウンロードしてこれらのテンプレートを置き換えるか、または Web Standards with MT ver.3.2 Strict : Changelog - ver.1.01 to 1.02 を参考にそれぞれ書き換えることをお願いします。

パンくずリストに対するスタイル指定が間違っていた

アーカイブテンプレートとパンくずリスト - パンくずリストの形で CSS による区切り文字の表示を紹介しましたが、この CSS の記述に一部誤りがありました。 ( 現在は修正しています。 )

ver.1.02 をダウンロードして index_templates\styles-site.txt を置き換えるか、 329 行目の ol#hierarchical-menu li a:before{ を ol#hierarchical-menu li:before{ に書き換えることをお願いします。

トラックバック送信先

まだテスト段階のようなので送信先は公開しません。

お出かけ前の 3 分リファクタリング

• [嘘]Liar's web:■MTtagsでmeta要素keywordsを入力？

<meta name="keywords" content="<MTTags><$MTTag$>,</MTTags>■■■" />

こんな感じかな？ 最後尾はなにかキーワードをあらかじめ入れておく必要有。

試してみたけれどうまくいかない・・・。 試行錯誤ちうです。

最後尾はなにかキーワードをあらかじめ入れておく必要有 というのは、おそらくキーワードの区切り ( , ) を MTTags コンテナタグ内に直接書いていることによるものだと推測。 コンテナタグ内に直接記述するのではなく、 glue 属性に書いてしまえば最後のキーワードの後ろに , が配置されることも無くなるでしょう。 また、 MTTags コンテナタグは weblog 全体のキーワードをリストアップするものなので、この場合は MTEntryTags コンテナタグを使う方が適切だと思います。 よってこのコードをリファクタリングすると、

<MTIfNonEmpty tag="MTEntryKeywords">
  <meta name="keywords" content="<MTEntryTags glue=","><$MTTag$></MTEntryTags>" />
</MTIfNonEmpty>

といった感じになります。 MTIfNonEmpty 条件タグで囲っているのは、キーワード欄に何も書かなかった場合のための保険です。

でも、元々そういうテンプレートタグがありますよ

前項のソースに出てくる MTEntryTags や MTTag というテンプレートタグは Movable Type の標準のテンプレートタグではありません。 Tagwire Plugin というプラグインをインストールすることによって使えるようになるテンプレートタグです。 これは entry_keywords フィールドの値を活用してタグ付け等を行うプラグイン。

ということは、 DB のフィールドを拡張しているわけではなく、既存のフィールドを使っているということ。 entry_keywords フィールドを表示するテンプレートタグを使えば良いのでは ?

<MTIfNonEmpty tag="MTEntryKeywords">
  <meta name="keywords" content="<$MTEntryKeywords$>" />
</MTIfNonEmpty>

このように、MTEntryKeywords をそのまま meta 要素に記述すればオーケー。 ただし、これはキーワード欄にて , でキーワードを区切っていた場合の話です。 Tagwire Plugin は , 以外にも ; や | や空白文字が区切り文字として使えますので、それらをキーワード欄に使用している場合は前項のソースの方を使用する方が良いでしょう。

トラックバック送信先

[嘘]Liar's web:■MTtagsでmeta要素keywordsを入力？

la1 さんのコードをリファクタリングしてみました。

Newton

ベルギーの……これフルーツビールという分類になるのかな ? 「青リンゴビール」とラベルには書いてあるのですが。 青リンゴ果汁が加えられており、ビールというよりは果実酒と呼ぶ方が近いかも。 リンゴの香りと甘酸っぱさが印象的でした。 ちなみにアルコール度数は 3.5% 。

よりみちよりみち

先日、母校の文化祭に顔を出したついでに釈云麦の取扱店にも立ち寄ってみました。 そんなに遠くないところなのにこういう機会が無いと行かないというのは、やはり基本的に出不精なんでしょうかねえ。 その割には大阪までドライヴしたり北海道までドライヴしたりするので、一度動き出せばそうでもないのかな ? その取扱店はベルギービールも数種類置いているので、もう少し足繁く通っても良いのですが、距離よりもむしろ方向の兼ね合いでなかなか足が向かないんですよね。

まあ、そんな前置きはさておいて、今回も買ってきました釈云麦。 前回は 720ml 瓶しか店頭に無かったのですが、今回は 1800ml 瓶も店頭に置いてありました。 何気なく置いてあるとはいえそこは販売店限定の焼酎、店頭にある分全てをゲットしたい欲望を抑え、私以外にも購入したい方はいるだろうと思って 2 本だけ購入しました。 2 本というのは、もちろん 1 本は自分用、もう 1 本はこの焼酎の存在を教えてくれた e-luck さん ( Lucky bag::blog ) 用です。 さて、 Thunderbird を起動してメールを書きましょうかね。

小樽ビール ピルスナー

小樽ビールのピルスナービール。 ピルスナーというのはまあ簡単に言うと「いわゆる日本のビール」。 普段ウィートエールやボックなど日本のビールとは異なる特徴的なものばかり飲んでいるため、ピルスナーの細やかな違いはよく分かりません。 一般的なものより少し苦味が少なくて飲みやすかった印象です。 ちなみにアルコール度数は 4.9% 。

デザインをオンライン注文

はてなブックマーク - 最近の人気エントリー経由でブログやCMSのオリジナルデザインを簡単5分オンライン注文。FLASHブログも可aamall.jp 。 はてなブックマーク - ブログのデザインをデザイナーに直接注文できるサービス「aamail.jp」を見ると、 15000円なら払う人は結構いそう ( id:kusigahama ) という感想や、 こうしてデザインの価格崩壊が ( id:wacok ) という感想や、 企業はともかく個人ユーザーには高すぎるでしょ ( id:lovely ) という感想が。 元々一般的な Web デザインの相場を知らないのですが、高いという感想もあり価格崩壊という感想もありでますます混乱気味な私です。

以前、 Movable Type 3.2 の Style Library と hxxk.jp の CSS - テンプレートを自作していた場合はで、ビジュアルデザインだけ外注しようかと考えていると述べましたが、これを試しに活用してみるのも良いかもしれません。

aamail.jp? aamall.jp?

どうせなら素早く人柱に名乗りをあげて、それをネタにしてしまおうなんて考えていたのですが、同じようなことを考える人はやはりいるもので、既に依頼をされた方がいらっしゃいました。

そして続けて jazzanovaの日記 - 続・ネタでデザインを依頼してみる。を読むと、 このサイトの名前をずっと「aamail.jp」と読んでましたが正しくは「aamall.jp」なんですね。 と書かれていましたが、これはおそらく INTERNET Watch の記事の title 要素が、最初は aamail.jp と誤記されていたからではないでしょうか ? http://b.hatena.ne.jp/entry/http://internet.watch.impress.co.jp/cda/news/2005/10/31/9691.html では aamail.jp という title になっています。 そして、このブックマークが編集された形跡はありません。 編集された形跡が無いということは、少なくとも最初にブックマークされた時点 ( おお、偶然にも (?) 最初にブックマークしたのは id:jazzanova さんだ ) では aamail.jp だったということになります。 よって、読み違えてしまうのも仕方がないかなと思います。

なかなか踏み切れない

他の人に先にやられてしまったという理由が無いといえば嘘になりますが、人柱になることをまだ踏み切れないでいます。 価格がどうとかという理由ではなく、 aamall.jp のトップページのソースが素晴らしい ( 皮肉 ) ものだったというのがその理由。 デザインを売り物にしているサイトなのに、その屋台骨がボロボロというのはなあ……という感想です。 ( 言うまでも無いことですが、デザインという単語は視覚的に見える部分だけじゃなくて、構造の設計や使い勝手の配慮などの総合的な造りを指します。 )

デザイナーの紹介ページを見てみましたが、作品の実績もほとんどがレンタル weblog サービスのものなので、設計部分の実力まではなかなか見えません。 山口暁亨さんという方が自己 PR で xhtml＋cssにによるデザインの構築 と書かれているので、この方に絞ってみようかなあ。

……でも、そういう理由で選ぶのならもっと確実に HTML のことを分かっておられる iMa さん ( iMach ) に頼んでみたいなあ、とも思います。 彼の CSS は良い意味で独特で、同じまたはそれ以上の代価を払うなら、 ( 失礼かもしれませんが ) よく素性を知らないデザイナーよりも彼に払いたいという。 本人は iMach - WEB製作のようなポリシーを持っておられるので難しいかもしれませんが。

iMach - WEB製作の カネをかける必要性無し という考えも共感できますが、私の場合は hxxk.jp で ( 広告収入やアフィリエイトなどの ) 利益を得るために作っているわけでもなく、作ること自体に楽しみを見出してやっているので、ある程度のお金を使うことも厭わないのです。 以前はよそ様のサイトに広告を出してみようということもありましたしね。

ちなみに、 iMa さんに限らず何人かそういった「お願いしたい方」はいたりします。 ある日突然何らかのアプローチをするかもしれません。 ( しないかもしれません。 )

トラックバック送信先

jazzanovaの日記 - 続・ネタでデザインを依頼してみる。

INTERNET Watch の記事の title 要素が、最初は aamail.jp と誤記されていた可能性があるので、読み違えてしまうのも仕方が無いと思います。

パンくずリストの COOOOL! な呼び方は ?

先日、 Web Standards with MT ver.3.2 Strict のリファレンス整備の目的でアーカイブテンプレートとパンくずリストという記事をまとめましたが、おかげさまでそれなりの数の方にブックマークしていただけたようです。

• はてなブックマーク - hxxk.jp - アーカイブテンプレートとパンくずリスト
• del.icio.us/url/a475b6cd3a347cf6540193d3c866d4e7

それらのブックマークにメモされたコメントの中にあった、 kazuhito さん ( del.icio.us/kazuhito ) の ちなみに僕は「パンくずリスト」とは呼ばない派です。 という一文が今回の疑問を投げかけるきっかけになりました。 確かに「パンくずリスト」という呼び方は正式なものではなく、意味としては通じやすいのかもしれませんが何だか野暮ったいものです。

仕様などで「正式にはこう呼ぶ」というものが無い以上、絶対的な正解というものも無いのですが、もっと分かりやすくて Web2.0 的な呼び方は無いものでしょうか ? パンくずリスト 2.0 とか ! ( ←何にでも 2.0 を付ければ良いってもんじゃないですよ ( ←けんたろたんを敵に回す発言 ( ←と思ったらいつの間にか 2.0 が無くなっていた ! ) ) )

パンくずリスト以外の主な呼び方

それじゃあパンくずリスト以外の呼び方って何があるんだろうと思って検索してみると、あっさり答えに辿り着きました。

• パンくずリストとは 【topic path】 ─ 意味・解説 ： IT用語辞典 e-Words

童話「ヘンゼルとグレーテル」で、森の中で迷わないようにパンくずを少しずつ落としながら歩いたという故事が由来である。 英語では、パンくずリストの直訳「breadcrumbs list」のほかに、意味を捉えた「topic path」(トピックパス)という語も使われる。

breadcrumbs list を使っているサイトはまだ見たことが無いなあ。 topic path を使っているサイトはいくつか見たことがありますけども。 今さっと思い出せるところを羅列してみると、

• SG::Acme
• BAZOOKA
• LIPPiN
• COZY-LiFE

……なんか、いくつかと言ったけどこの 4 サイトのうち 2 つは BAZOOKA の影響があってそうな気がしないでもないです。 SG::Acme も「 topic path 」とは明記していないけれど、この ./ の扱い方が BAZOOKA に影響を与えたとか与えていないとかという話を耳にしたことがありますし。 topic path もあまりポピュラーではないのでしょうか ?

ちなみに当 hxxk.jp では http://hxxk.jp/2005/11/01/2209 のように、 http:// 形式で URI をそのまま記述し、ディレクトリ階層ごとにリンクを張っています。 これは Arielworks.net の手法を真似たもので、特に名称は定められていないはずです。 私は勝手に「階層メニュー」と名付け、それを直訳して hierarchical-menu という id をそのメニューに指定しています。 Web Standards with MT ver.3.2 Strict で配布しているテンプレートにも同じ id を使用していますが、どうせなら COOL かつポピュラーな呼び名を id に指定した方が良いかなあと今回考えました。

breadcrumbs-list と topic-path のどちらかにしようかと考えていますが、どちらが良いでしょうかね ? 明確な根拠を伴ったご意見、「○○の方が語感が良い」といったご意見どちらでも構いませんので、コメント欄に書いていただけると幸いです。 もちろん、この 2 つ以外にも COOL な呼び方があるぜ ! っていう場合はそれを書いていただいても構いません。

Re: 小粋空間: .htaccess によるリダイレクト

MTタグを使って URL-path を自動的に生成していますが、残念ながらMTタグのみで「ドキュメントルートからのパス+ファイル名」というフォーマットを生成することはできません（いわゆるURL形式で生成されます）。

ユーザマニュアルに MTBlogRelativeURL というテンプレートタグが記載されています。 これを使えばドキュメントルートからの相対パスの記述を MT テンプレートタグだけで生成することが可能です。

<MTArchiveList archive_type="Individual">
<MTEntries>Redirect permanent <$MTBlogRelativeURL$><$MTArchiveDate format="%Y/%m/"$><$MTEntryBasename$>.html <$MTBlogURL$><$MTArchiveDate format="%Y/%m/"$><$MTEntryBasename$>.php</MTEntries>
</MTArchiveList>
<MTArchiveList archive_type="Category">
Redirect permanent <$MTBlogRelativeURL$><$MTSubCategoryPath$>/index.html <$MTBlogURL$><$MTSubCategoryPath$>/index.php
</MTArchiveList>
<MTArchiveList archive_type="Monthly">
Redirect permanent <$MTBlogRelativeURL$><$MTArchiveDate format="%Y/%m/"$>index.html <$MTBlogURL$><$MTArchiveDate format="%Y/%m/"$>index.php
</MTArchiveList>

これは Movable Type 3.2-ja-2 のデフォルト状態のアーカイブマッピングを例にしているため、小粋空間: .htaccess によるリダイレクトのソースと若干マッピングが異なりますが、基本的なソース形態はこのような形になります。 こう記述することで、 ファイルを生成した後、任意のエディタで開き、リダイレクトの設定で不要なドメイン部分を削除 するという手順は不要となります。

2 つのフルパス

これ以降、 Movable Type におけるフルパスの取り扱い方を解説しようと思いますが、一口に「フルパス」と言っても 2 種類あるため、まずはそれを説明します。

CGI や PHP など、内部処理で扱うフルパス

正式名称は知りませんが、いわゆる「 / で始まるフルパス」というものです。 例えば xrea の場合、「 public_html の直下に put されている index.html のフルパス」ですと /virtual/userID/public_html/index.html というパスになります。

http:// で始まるフルパス

実際にブラウザでリクエストする際に用いられるフルパスです。

内部処理で扱うフルパスと Movable Type のテンプレートタグ

内部処理で扱うフルパスを扱うために、 MTBlogSitePath というテンプレートタグが準備されています。 管理画面の「設定」→「公開」を開き、「サイト・パス」という欄を見るとそのテンプレートタグで表示されるパスを確認することができます。 ( /home/melody/public_html/weblog という例が書かれている部分です。 )

MTBlogSitePath で表示されるフルパスの他に、先ほど紹介した MTBlogRelativeURL で表示される相対パスがあります。 ユーザマニュアルには ブログの設定画面に指定された Site URL からの相対アドレスです と説明されています。 例えば、 Web Standards with MT ver.3.2 Strict で MTBlogRelativeURL を使ってみると、 /template/mt_3_2_strict/ という結果が返ってきます。

http:// で始まるフルパスと Movable Type のテンプレートタグ

こちらはお馴染みの (?) MTBlogURL を用います。 Web Standards with MT ver.3.2 Strict で MTBlogURL を使ってみると、 http://hxxk.jp/template/mt_3_2_strict/ という結果が返ってきます。

まとめおよび関連リソース

よって、小粋空間: .htaccess によるリダイレクトのように、 .htaccess をインデックステンプレートを用いて構築しようとする場合、リダイレクト元のパスを記述する場合は http:// で始まってしまう MTBlogURL ではなく MTBlogRelativeURL を用いるのが効率的ということになります。

なお、 .htaccess をインデックステンプレートで構築する手法については、 Redirect Template や entry_basename による URI からのリダイレクトを行う .htaccess の記述や Movable Type 2.x 形式の Permalink から Movable Type 3.x 形式の Permalink にリダイレクトする方法にて解説していますので、合わせてご覧ください。

MultiViews が使えるならば

.htaccess が使える環境ならば、合わせて Multiviews オプションを使える環境になっている可能性が高いと思います。 ( もちろん利用しているサーバによって異なりますが。 ) よって、せっかくリダイレクトを行うなら、アーカイブマッピングを .html から .php に変更するのではなく、 .html から拡張子無しに変更することをお勧めします。 今後 .php という拡張子が変更になる可能性もゼロではありません ( 事実、以前は .php3 だった拡張子が .php に変更になった経緯があります ) し、何らかの理由で .html に戻すことも考えられるためです。

<MTArchiveList archive_type="Individual">
<MTEntries>Redirect permanent <$MTBlogRelativeURL$><$MTArchiveDate format="%Y/%m/"$><$MTEntryBasename$>.html <$MTBlogURL$><$MTArchiveDate format="%Y/%m/"$><$MTEntryBasename$></MTEntries>
</MTArchiveList>
<MTArchiveList archive_type="Category">
Redirect permanent <$MTBlogRelativeURL$><$MTSubCategoryPath$>/index.html <$MTBlogURL$><$MTSubCategoryPath$>/
</MTArchiveList>
<MTArchiveList archive_type="Monthly">
Redirect permanent <$MTBlogRelativeURL$><$MTArchiveDate format="%Y/%m/"$>index.html <$MTBlogURL$><$MTArchiveDate format="%Y/%m/"$>
</MTArchiveList>

なお、拡張子無しにするといっても、サーバ上での実体は .php ないし .html などの拡張子が付いたファイルですので、合わせてRemoveExtFromPermalink プラグインで <$MTEntryPermalink$> から拡張子を無くすと良いでしょう。

トラックバック送信先

小粋空間: .htaccess によるリダイレクト

ユーザマニュアルに MTBlogRelativeURL というテンプレートタグが記載されていますが、これを使えばドキュメントルートからの相対パスの記述を MT テンプレートタグだけで生成することが可能です。

be all eyes

思えば学生の頃からインディーズの CD などを好んでいました。 別にアンチメジャー志向だったというわけでも「アイツらはメジャーに行って変わっちまったンだよッ……」なんてことを小池一夫の劇画風に呟いていたわけでもありませんが、メジャーデビューをきっかけで聴かなくなったバンドもいくつかありました。 もちろんメジャーデビューしても聴きつづけたバンドも同じようにあったわけですが。

まだインターネットが一般的でなかった時代、情報収集手段は雑誌などに限られ、書店の音楽雑誌コーナーに足繁く通っては目を皿のようにして小さな枠に書かれた情報を頼りにしていました。 今考えるとそうやって情報を追い求めること自体が楽しく、また情報を得てもなかなか手に入れにくかった、その分手に入れられた時の喜びはより大きくなったあたりにインディーズを好んでいた要因があったのかもしれません。 発表から発売まで 5 年くらいかかったデモテープなんてものもあったりしましたし。

さて、その頃熱心に聴いていたバンドもほとんどは解散ないし活動停止している今、私の興味はいわゆる同人 CD というものに移っています。 いわゆる同人 CD と言ってもこれも立派なインディーズ CD には変わりないので、自分の中では区別はありませんが。 ゲームミュージックの、個人によるリアレンジがほとんどですが、それ以外にも面白そうなものは種類にこだわらず手を出しています。 ( ちなみにゲームミュージックのリアレンジと言っても色々ありますが、ダウンロードして聴ける所で例を挙げると撃墜王決定戦や Live House S.S.H などが私の好みです。 )

しっぽとおしゃべり

さて、結構前の話になりますが、万能しっぽと schmooze という 2 つのイラストサイトをほぼ同時に知る機会がありました。 両サイトともに絵柄の方向性は違いますが、どちらも私好みのイラストが並んでいました。 その 2 つのサイトには共通点があり、さいたま CD だのラーメン CD だのトイレ CD だのぬるぽ CD だの、何ていうかタイトルから内容が想像できそうでいてその実どんな内容なのかやっぱり想像できそうにない CD が紹介されていました。

好みのイラストで飾られた、得体の知れない ( 失言 ) CD たち。 それは私の心の片隅にひっそりと記憶を植え付けってまあそんなスカした言い回しはともかく印象に残ったわけでして。 それからしばらくの月日が経った後、友人に連れられて入った某同人ショップの CD コーナーでぬるぽ CD を見かけた際に、思わずジャケ買いしてしまったのは言うまでもありません。 それをジャケ買いと言うのかは分かりませんが。

ラピュタじゃなくラピュータって言われると違うものを思い浮かべる

それからまた数ヵ月後、友人の車に乗って夜遊び ( カラオケですよ ) に出かける時や、友人の家に泊まった時に流れていた脱力トーク系の BGM に何故か心惹かれることがありました。 「何それ ? 」と尋ねると、「これかい ? イオシスっていうサークルのイカれした CD さ ! こないだみんなでふざけていた時に『俺無職だから金ねえよ ! 』ってアイツが言っていたのもコレを聴かせていた賜物だよ ! 」という深夜の通販番組ノリで答えが返ってきました。 通販番組ノリは若干嘘入っているとしても ( ということは大部分は真実なのか ) 、イオシスって名前が出たところで点は線へと繋がり、そして偶然とは恐ろしいもので、その問答があった朝はちょうど Final Fantasy シリーズのリアレンジ CD でも漁りに行こうかと話していたのです。

そして実際に漁りに行ったのですが、あいにく友人の家で聴いた CD は店頭に無く、同サークルの CD で目に付いたものを購入。 帰宅後にイオシスのサイトから買えないものかと調べていると、イオシスショップで通信販売を行っているとのこと。 購入意欲が高まっている間にレッツ購入 !

以前から info@ 系のメールアドレスを案内用に使っていた人には悪いけど

購入注文を出した後に、すぐオートレスポンダによる確認メールが届きました。 それによると、改めて振込先や振込金額が記載されたメールを送るとのことだったので、そこでいったん PC を落として就寝。

私のメールチェック体制は、 PC あてに届くメールはそのまま携帯電話に転送しているため、朝になると溜まっている info@ 系の spam を消去し、必要なものだけを朝食をとりながら読み、日中に届くメールも info@ 系は即消しで、必要なものは昼休みなどの休み時間に読み……といったもののため、 PC のメーラ ( Thunderbird ) でチェックをするのは自分からメールを送る時だけといった感じです。

さて、オートレスポンダによるメールは届いたけれど、肝心の振込情報を記入したメールが来ない。 まあ、最初に送ったメールも深夜だったし、先方にも何かと都合があるだろう……とのんびり構えていました。

もうお分かりですね。 オートレスポンダまで確認して就寝した後、振込情報メールは届いていたのです。 翌朝、基本的に低血圧で寝起きの悪い私は、寝ぼけ眼でメールの整理をし、 info@ 系の spam を消すついでに…… info@ で始まるアドレスから送られた振込情報メールも消していました。

何故それが判明したかというと、 IRC でよくお話をする某 P たん ( Piro たん ( outsider reflex) では無いので念のため ) がこのサークルの関係者 (?) らしく、「へえ、注文したんだ」みたいな話の展開になった時に「でも振込情報メールが来ないんですよねえ」と告げると、メンバーに連絡を取って下さって判明したという。 皆様、私の確認の不備でご迷惑をおかけしてすみませんでした。

schmooze のキリ番はニアピンだった思い出が

携帯電話から消していただけなので、 Thunderbird を開けば振込情報メールはきちんと残っています。 そのメールを開いてみると……文中に「おめでとうございます ! 」の文字が。 何だろうと思って読み進めると、実は IOSYS SHOP ご注文１００件到達感謝祭というものが開催されていまして、何と私の注文がちょうど 100 件目だったとのこと。

購入するときにそういったイベントがあっているのは目にしていましたが、元来こういったものは狙って外すのが私の常、変に意識せずに購入意欲に従って即日申し込みをしました。 それが功を奏したのか、今回の当選と相成ったようです。

ということで 5 セクションに渡り展開した「イオシスと私」、当選報告を以って締めさせていただきます。 御清聴ありがとうございました。 100 件目を鼻息荒く狙っていたイオシスファンの皆様ごめんなさい。

トラックバック送信先

IOSYS SHOP ご注文１００件到達感謝祭

今回は無欲の勝利ということで 100 件目をゲットしましたが、実はイオシス自体には以前から関わりがあったのです。