記事本文
Traquair House Ale
イギリスのストロングスコッチハウスエールビール。 麦汁濃度が高く、最高級ビールの栄誉を与えられているビールだそうです。 ( その分、ショップでも他のビールと比べて 2.5 倍くらいの価格になっていましたが……。 ) アルコール度数は 7.2% で、しっかりとしたボディが感じられました。
これを以って 2005 年最後のビールとし、合わせて 2005 年最後の記事としようと思います。 皆様、よいお年をー。
2005-12-31T22:59+09:00
トラクエア ハウス エールを飲みました。
リプライはまだありません。

イギリスのストロングスコッチハウスエールビール。 麦汁濃度が高く、最高級ビールの栄誉を与えられているビールだそうです。 ( その分、ショップでも他のビールと比べて 2.5 倍くらいの価格になっていましたが……。 ) アルコール度数は 7.2% で、しっかりとしたボディが感じられました。
これを以って 2005 年最後のビールとし、合わせて 2005 年最後の記事としようと思います。 皆様、よいお年をー。
リプライはまだ送られていないか、管理者の承認待ち状態です。 この記事に対するご意見やご質問、ご感想などありましたら個別記事ページの送信フォームからお送り下さい。
2005-12-31T22:49+09:00
ブリガンドを飲みました。
リプライはまだありません。

ベルギーのトリプルストロングエールビール。 アルコール度数が 9.0% と高く、力強い味わい。
リプライはまだ送られていないか、管理者の承認待ち状態です。 この記事に対するご意見やご質問、ご感想などありましたら個別記事ページの送信フォームからお送り下さい。
2005-12-31T22:42+09:00
クリスマスを飲みました。
リプライはまだありません。

ドイツのクリスマスビール。 ドュンケルボックタイプで、褐色の液体が綺麗でした。 アルコール度数はボックということで 6.8% とやや高め。
リプライはまだ送られていないか、管理者の承認待ち状態です。 この記事に対するご意見やご質問、ご感想などありましたら個別記事ページの送信フォームからお送り下さい。
ブログオーナーであれば誰しも、「自分のブログのどの記事でもいいから、ブクマが付いたら新着順で教えて欲しい」という欲求が出てきます。 それが上述した「特定『サイト』に関して、付いたブクマ『コメント』のリスト」です。 新着コメントリストがないと、ブログについたコメントを見落としてしまうように、 新着ブクマリストがないと、ブログについたブクマを見落としてしまうワケです。
これは、不完全ですが要望を満たすブックマークレットが存在します。 以前被はてなブックマーク状況を新着順で知りたいという記事を書きましたが、その時に作成 ( というか改造 ? ) した http://hxxk.jp/common/js/hb_siteentry.js を用いて、 javascript:(function(){var s=document.createElement("script");s.charset="UTF-8";s.src="http://hxxk.jp/common/js/hb_siteentry.js";document.body.appendChild(s)})(); というブックマークレットで自分のサイトの新着被ブックマークをチェックしています。 ( Firefox ですと「補助クリック」→「このリンクをブックマーク」でブックマークレットとして使えるようになります。 その他のブラウザでもほぼ同じ操作でブックマークレットとして使えます。 )
なお、このブックマークレット自体は fladdict.net blog: 今見ているサイト内で「はてなブックマーク」されてるエントリ一覧を表示するブックマークレットで公開されているものにほんの少しだけ手を加えたものです。 この場を借りて作成者の Taka さん ( fladdict.net blog ) には感謝の気持ちを表明。
前項のブックマークレットを作成した時は、はてなブックマークの特定の URI 以下の新着エントリの挙動が今と違っていたような気がします。 当時は確か純粋な被ブックマーク時刻でソートされ、たとえ過去にブックマークされた記事であっても、再度他の人がブックマークすれば新着として扱われていたと思います。 ( この辺りははっきりとしたソースが無いので、断言はできませんが。 )
しかし、現在では最初にブックマークされた時刻 ( いわゆる 1get の時刻 ) でソートされるようになっており、そのために
2ヶ月前の記事のブクマ数「○○users」の数字を見て、「以前より増えている!」などと気が付く方はいないでしょう。
という事が起こってしまうわけです。
これが以前の挙動に戻れば、前項のブックマークレットと組み合わせることで
自分のブログに対して付いたブクマコメントを洩らさず知ること
ができると思います。
ということで、 idea:7896 を出してみました。 85 文字制限があるためにブックマークをブクマと表現せざるを得なかったのが心残り。 最初から 800 ポイント突っ込んでいますが、賛同していただける方がいらっしゃいましたらよろしくお願いします。
ブックマークを新着順で知ることができるブックマークレットをご紹介。 ただし、現在のはてなブックマークの挙動では過去にブックマークされたものの人気が再燃した場合まではカバーできませんが。
現在のはてなブックマークの挙動では、過去にブックマークされたものの人気が再燃した場合まではカバーできません。 最初にブックマークされた時刻ではなく単純なブックマーク時刻でのソートをお願いします。
リプライはまだ送られていないか、管理者の承認待ち状態です。 この記事に対するご意見やご質問、ご感想などありましたら個別記事ページの送信フォームからお送り下さい。
2005-12-31T20:17+09:00
ヒューガルデン ホワイト樽生とセント・フューリエン・キュベ・デ・ノエルを飲みました。
リプライはまだありません。
ベルギーのウィートエール。 A red flower 2005 で再び Frigo に行く機会に恵まれたため、もう一度この樽生を飲むことにしました。 瓶では味わえない美味しさ、そして店内の雰囲気、久しぶりに再会した旧友、これらが相まって非常に美味しいビールでした。
ベルギーのクリスマスエール。 Frigo に行ったのが 12 月 23 日だったため、ゲストビールにはこのビールが据えられていました。 濃厚な味わいとはっきりと感じられる甘みが良い感じでした。 アルコール度数が 9% のため、少し酔いが回りましたが……。
リプライはまだ送られていないか、管理者の承認待ち状態です。 この記事に対するご意見やご質問、ご感想などありましたら個別記事ページの送信フォームからお送り下さい。
アクセスログを見ていると、 iPod 関連の検索キーワードで来られる方が結構多いことに気付きます。 一応キーワード "iPod" が設定された記事という分類で過去記事のまとめ読みもできますが、ここで自分用にいったん再分類したまとめページを作っておこうと思います。 関係無いけど決算期の音楽シーンってよくベストアルバムの類がリリースされますよね。 いや本当に関係はありませんけど。
カラーが若干変わったのと、 6GB モデルが登場したこと、何よりバッテリー駆動時間が従来の 8 時間から、 18 時間に大幅アップしたのが特徴的でした。
2 代目 iPod mini の登場に伴って、その他のラインナップでも容量の変更や価格改定、付属アクセサリの変更などが行われました。
iPod nano の登場により、 iPod mini はラインナップから外れました。 価格やスペックから鑑みて、 iPod mini の後継の位置に iPod nano は据えられているようです。
動画再生ができるようになった点が大きく違う他、従来の 20GB モデルの価格で 30GB モデルが購入できるようになったりと、コストパフォーマンスの向上が図られています。 ( もっとも、 FireWire が無くなったり AC アダプタが付属しなくなったりといった点もありますが。 )
何らかの原因で、パソコンに iPod を接続しても認識されなくなることがあります。 Windows 対応コンピュータが iPod を認識しない (Windows) や iPod が「iTunes」や Mac のデスクトップに表示されないに対処方法が掲載されています。
通常は、携帯電話のバッテリー表示のように目盛りで電池残量を表示していますが、これを数値で表示することができます。 詳しい方法は上記リンク先か、または iPod portal : 電池残量の数値化をご覧ください。
Notes フォルダに歌詞ファイルを作成し、その歌詞ページに曲再生のアンカーを埋め込むという Tips 。 まあ、 iPod nano や iPod(5G) などの新しい機種では標準的な機能になっているため、いずれ使わなくなる Tips ではあります。 ( iTunes 5: iPod nano の曲に歌詞を追加するをご覧ください。 )
ここは過去の記事の再掲ではなくて書き下ろしです。 ボーナストラックです。 というか自分で iPod mini を使っていて感じたことをメモしているだけです。
私が使っているのは初代の iPod mini で、バッテリの駆動時間は最大で 8 時間というものです。 既に購入してから 1 年近くが経ち、バッテリ自体も弱まってきていますが、それでも極端に稼働時間が短く感じるようになってきました。 アップル - バッテリー - iPod にその答えがあり、何故短くなったのか分かりました。 以下に「こういった使い方をしていたら途端にバッテリ切れを起こすようになった」という体験談を書いておこうと思います。
CD プレーヤや MD プレーヤと違い、曲の出し入れが比較的簡単であるために、色んな曲をつまみ食い的に入れることがよくありました。 そういった入れ方をしているために、聴く時もつまみ食い的になってしまい、スキップを頻繁に行うような使い方になりました。 当然ながらハードディスクへのアクセス回数が増えることになり、バッテリは見る見るうちに減ることになります。 残量の数値化をしていると更にその減り方は目に見えることに !
電車の中や室内などで使う場合はバックライトを点灯しなくても、 iPod mini 本体を手に持ってよく見れば操作は十分に行えると思います。 私は主に屋外、あるいはエアロバイクに乗っている時に使うため、本体は手に持たずにベルトクリップ等で固定し、クリックホイールのみで操作することになり、どうしてもバックライトが必要になります。 この点灯時間を 10 秒に設定していたがために、操作のたびに明々とバックライトが灯り、バッテリが減っていったわけです。 バックライトを全く点灯させずに使うと、通常の減りっぷりが嘘のように長持ちしました。
iTrip mini という FM トランスミッタを用いて、車で使うこともあるのですが、普通にイヤフォンで聴く時よりもバッテリの減りが早いような……。
DREAM THEATER の長尺な曲とか、ラジオ番組の mp3 を再生すると、その分キャッシュされるデータが大きくなってしまい、やはりハードディスクへのアクセス回数が増えることになります。
なお、
iPodのキャッシュは、平均的なファイルサイズ(9MB以下)を扱う際に最も効率的に動作します
ということのようです。
車で使った後、 iPod mini を車中にずっと置いておくと、真冬では停車中に温度が激しく下がることになります。 この状態で使用すると、バッテリが充分に残っているはずなのに、充電してくださいと言われてしまうことがあります。 iPod mini 自体があまりに冷えている場合は、ある程度暖めてから使用した方が良いようです。
リプライはまだ送られていないか、管理者の承認待ち状態です。 この記事に対するご意見やご質問、ご感想などありましたら個別記事ページの送信フォームからお送り下さい。
!important に未対応 ?巡回先である K's Web にて気になる記述を発見。
Win IE 以外のブラウザは "!important" の記述がある特定の値を優先して認識するが、Win IE は未対応のために、それ以降に別の値を記述し、これを上書きする。
色々と CSS の実装に不備が多い WinIE でも、
!important
による優先は実装しているはず…… ?
……と思ったら、 Internet Explorer (Windows) CSSバグリスト - 同一ブロック内では!importantが無視される(5.x/6.0) にて
同一ブロック内に1つのプロパティについて!importantキーワードがある宣言とない宣言を置いた場合、!importantキーワードは無視されより後にある宣言が有効になる。
と書かれているバグのことを指しているようですね。
よって、同一プロパティ内に
!important
無しの記述を書かないか、あるいは書いていても
!important
ありの記述よりも前に書けば問題はありません。
( 同一プロパティ内にて 2 つの記述をすること自体あまり考えられませんが。 )
ということは、
*{
visibility: visible !important;
visibility: hidden;
}
という記述を CSS に書くと、 WinIE ではページの内容が表示されないということになります。 ( 実際に試しました。 ページの内容は全く表示されませんでした。 )
もちろん、製作者スタイルシートを無効にしていたり、ユーザスタイルシートを使っていたりすれば内容を表示できますし、またそうでなくとも単にブラウザの画面上に表示されないというだけなので、 表示 (V) → ソース (C) としてソースを表示すれば内容の取得はできます。
実際にこういうことをやっても、製作者にも閲覧者にもデメリットは多くあれどメリットはあまりありません。 ただ、こういったバッドノウハウが存在するということだけをメモしておきます。
リプライはまだ送られていないか、管理者の承認待ち状態です。 この記事に対するご意見やご質問、ご感想などありましたら個別記事ページの送信フォームからお送り下さい。
2005-12-24T02:03+09:00
東京にいますよという報告と、今後書こうと思っている内容の予告。
リプライはまだありません。
日付上では既に昨日、23 日から JILS のライブに行くために東京入りしているのですが、ここ数日更新のペースよりも書きたいことの方が多くなってしまっています。 そんな状態で熱いクリスマスナイトを過ごしてくると、何を書きたかったのか忘れてしまう可能性が高いので、 To Do リストというか次回予告というか、そんなメモを残しておきます。
なお、例によって旅行中ははてなダイアリー - 真琴@臨時更新場にて携帯メール更新をしたりしなかったりしているので、動向が気になる方はチェックしてください。
はてなアイデアの idea:6444 が 12 月 6 日のアイデアミーティングで取り上げられた件についてと、それに関連して description を別途記入することについて。
既にある程度の内容は書いていて、あとはアイデアミーティングの文字起こしをすれば完成。
facet-? - id/name 属性や cite 属性をリンク化する Permalink+ というブックマークレットが登場したので、 cite 属性からリンクアンカーを手軽に生成のような記事をもう一度書こうかと思っています。
dashify プラグインという存在を知ったので、それが関係するいくつかの記事を修正予定。
じっくり取り掛かりたいので優先順位は低め。 でもテンプレート配布サイトは一度まとめておきたいのです。
Movable Type の Tips としての記事もそろそろ書いておかないと Movable Type サイトとしての意義が。 Movable Type サイトだったのかどうかはさておき。
ライセンス関連の記事が増えてきたので、改めてまとめ直したいです。
The opening is not a summary. で触れた、 RSS に記述する内容のことについて、もう少し触れようと思います。 触れる予定の記事はむだづかいにっき♂:RSSリーダーは部分表示? 全文表示?で、あと RSSの要約とか何とか - HsbtDiary (2005-12-20) や void GraphicWizardsLair( void ); // 大抵の日本語blogは最初に「要約」や「概要」を書かないから、英語圏blogツールの概要機能と相性が悪いと思うからいただいたトラックバックへのリアクションもしたいと考えています。
また、個別記事のメタデータ - 徒書で個別記事のメタデータを提供することについて触れられています。 これは以前書いたはてなブックマークと個別記事ごとのサマリを提供する Feed にも関連するので、記事として触れるか、あるいは個別記事の Feed の提供についての方針を転換するかしようと思っています。
Mobile Link Discovery という仕様が先日発表されましたが、これに合わせてモバイル環境に適した内容のリソースを提供しようと考えています。 XHTML Basic を基に、ナビゲーション部分は最低限のもののみにしてファイルサイズを節約し、携帯電話などの環境でも読めるように工夫したいと思っています。 ( 記事によっては本文自体が長大なものもありますが、小粋空間: エントリーアーカイブのページ分割などの方法を採用してみるのも手かも。 )
また、雑記 - 20051223-3 / イデアルリアルのように、携帯電話からだと文字化けして読めないという報告もあっているので、それも合わせて対応の予定。
うん、羅列してみたらいっぱいありすぎ。 羅列する前は年内いっぱいの課題にしようと思っていましたが、ちょっと間に合いそうにないですね。 のんびりやっていきます。
リプライはまだ送られていないか、管理者の承認待ち状態です。 この記事に対するご意見やご質問、ご感想などありましたら個別記事ページの送信フォームからお送り下さい。
2005-12-22T03:07+09:00
MOMENT という曲の歴史や解説を出来うる限り詳細に行いました。
はてなダイアリーの編集ページからのアクセス (2) にて音楽ファイルに触れたので、いつか補足しようと思っていた音楽ファイル - MOMENT/YUKIYA with kreis project について触れようと思います。
まず、 MOMENT という曲が最初に世に出た経緯から。
1998 年 5 月、インディーズレーベル Kreis に所属していた BLÜE というバンドが、メジャーデビューを機にレーベルを卒業することになりました。 その卒業イベントとなる Kreis/Tokyo が 1998 年 5 月 28 日に渋谷 ON AIR EAST で行われ、 BLÜE のヴォーカルの ARIHITO 氏がレーベル代表兼 D≒SIRE のヴォーカルである幸也氏に、 「レーベルのテーマ曲みたいなものを作って欲しい。 すぐ覚えられそうで、みんなで歌えるようなものが良いです。」 というお願いをします。
その時に作られた曲がこの MOMENT で、イベントに合わせて作られたレーベルのオムニバス CD Kreis にもシークレットトラックとして収録されました。 CD の発売日はイベント翌日の 1998 年 5 月 28 日。 シークレットトラックであったため、この時点では MOMENT という曲名は知る由がなかったのですが。
実は D≒SIRE は 1997 年 11 月 11 日のライブのステージ上で解散を発表し、 1998 年にラストツアーを行うことになっていました。 そのラストツアーは 1998 年 12 月 24 日にファイナルを迎え ( 実は 25 日にシークレットライブがあったそうですが ) 、 D≒SIRE は解散しました。 そういった背景の中で、幸也氏のひとつの節目となる作品、 MOMENT が YUKIYA with kreis project 名義で 1999 年 1 月 13 日にリリースされました。
これは一つの曲を様々なアレンジで収録する形になっており、全 4 曲のマキシシングルとなっています。
これは前述の MOMENT の再録版。
幸也氏本人は
いわゆるノーマルバージョン
と表現しています。
後半のサビでは Kreis レーベルの所属アーティストや関係者が合唱しています。
1 曲目の 1:49 ~ 2:54 部分が、 Kreis レーベルの所属アーティストや過去に幸也氏がプロデュースしたアーティストが交代でメインヴォーカルをとる形になっているバージョン。
という順番で歌い、その後複数名でのコーラスに移っていきます。
電器楽器を一切使用していないアレンジ。 使われている楽器は生のストリングスとアコースティックギターとアコースティックピアノだけだそうです。
他のアレンジでのギターは聖詩氏 ( ex.D≒SIRE ) と Saki 氏 ( BLÜE ) と KO-JI 氏 ( Ray ) が担当していますが、このアレンジでのアコースティックギターは Ryo 氏 ( Ray ) が弾いています。 幸也氏のために一生懸命練習をして、幸也氏はその心に打たれたために Ryo 氏のギターを採用したそうで、そのために R.K MIX という名前が付いているようです。 ( R.K = Ryozo Kobayashi )
これは 1 曲目または 2 曲目のアレンジのインストゥルメンタル版。
ちなみに、コーラスの中に名を連ねている chara 氏という方は、 Kreis レーベルがよく使用していた BAZOOKA STUDIO のエンジニア、朝野”ちゃら”克彦氏。 他にも Dir en grey のマネージャーや、吉本興業のパンチ UFO 氏なども関係者として参加しています。
そして 1999 年 11 月 11 日、 D≒SIRE のヴォーカル幸也氏とドラムの秀誉氏、 Vasalla のギター舜氏 ( 現在は俊介という表記 ) 、 ZENITH のギター MARIKI 氏によって JILS が結成されました。 その翌月、 12 月 22 日に Kreis レーベルオムニバス CD 第 2 弾、 Kreis 1999 が発売されました。
この CD は JILS と Ray と pleur が曲を提供している上に、 2 曲のボーナストラックが収録されており、そのボーナストラックとして MOMENT のデモバージョンが収録されています。 これは録音時期としては YUKIYA with kreis project のものより前で、オケはレーベルオムニバス CD 第 1 弾のものが使われており、ヴォーカルを幸也氏と ARIHITO 氏 ( BLÜE ) と HIROKI 氏 ( Ize ) の 3 人のみで担当しています。
ということで、 MOMENT という曲は合計で 6 つのバージョンがリリースされているということになります。 何度も使われているだけあって良いメロディで、かつ覚えやすい曲であるので私のお気に入りです。
それにしても、大好きなバンドの話をするのは楽しいなあ。 音楽ファイル - MOMENT/YUKIYA with kreis project の補足のつもりでしたけど、自己満足がかなり含まれています。 そしてこのテンションで、 JILS のライブに行ってくるのです。
MOMENT に関する補足をしました。 補足という建前の自己満足の日記かもしれませんが。
4 件のリプライが送られています。 この記事に対するご意見やご質問、ご感想などありましたら個別記事ページの送信フォームからお送り下さい。
>それにしても、大好きなバンドの話をするのは楽しいなあ。 それを読むのも楽しいなあ。とか。 “Da'vidノ使徒:aL”なんて単語、普通の生活送ってたら先ずお目にかかれない、笑い。にしてもKreis オムニバス収録音源はどれも名曲というか、Review for fateとか空オケ入ってればいいのに!いまだに見たことないです。
懐かしいバンド名が一杯だ!Da'vidノ使徒:aLなんて懐かしすぎます!このバンドはサウンド、ボーカルと独特でしたよねー。バンド名も読めなかったし、1stアルバム名も読めなかった、、、
うわー !! BLÜE とか今でもきっちり聴いていたり…懐かしさ全開ですよ。 Da'vidノ使徒:aL はビジュアルに惹かれてチェックはしていたのに結局音源聴かずじまいでした。 90 年代後半は良いバンドがホントたくさんありました…マジで思いで深いです。
すみませんレス遅れました。
> iMa さん
Review for fate は私も大好きです ! ( オムニバスでしか BLÜE を聴いたことがありませんが…… )
機種によっては JILS は充実しているんですけどねえ。 MOMENT が入っている機種も確かありますし。
> 101 さん
ツキノハコ、でしたっけ。 ( 文字が出ません…… )
バンド名は私も読めませんでした。
> ミユキさん
90 年代後半は今よりも音楽に熱中していましたねー。バイト代の大部分をつぎ込んでいました。 Laputa のカップリングベストを買った時は、所持金が 50 円になったり……
2005-12-21T23:15+09:00
はてなダイアリーの編集ページからのアクセスで書いていた疑問は、最新の日付においてもリファラを記録する設定ができるはてなダイアリーの特徴によるものだったことが判明しました。
リプライはまだありません。
以前、はてなダイアリーの編集ページからのアクセスという記事で、 http://d.hatena.ne.jp/UserID/edit?date=YYYYmmdd というアドレスのリファラが散見されるようになった何故だ何故だッと書きましたが、音楽ファイル - hxxk.jp - はてなダイアリーの編集ページからのアクセスにてその疑問が解けました。
リンク先に書いてありますが、はてなダイアリーは最新の日付とリンク先の日付の両方の日記にリファラを記録する設定があったのです、すっかり忘れていました。 だから、 hxxk.jp から音楽ファイルに対してリンクを張ったケース、すなわち Musical Baton の泥臭いまとめ→音楽ファイル - Musical Baton(ミュージカルバトン)というのが回ってきた。という流れのリンクでアクセスがあった場合、 http://d.hatena.ne.jp/SecretxStory/ と http://d.hatena.ne.jp/SecretxStory/20050615/p1 の両方にリファラが記録され、最新の日記の edit 画面に現れることもあると……なるほどなるほど。 ウシ井まゆこさん ( 音楽ファイル ) 、ありがとうございました。 ( 本館の方のハンドルで呼んでいいのかな )
あと、ひとつ勘違いしていたのですが、はてなダイアリーの編集ページからのアクセスで並べたリンク先は、全て Musical Baton の泥臭いまとめに含まれていました。 まとめを作っていた時はユーザスタイルシートを使っていて、そのサイトのデザインは記憶していなかったのが原因というか……まあ、言い訳に過ぎないのですけども。
ウシ井まゆこさんの反応のおかげで疑問が解決。 ありがとうございました。
リプライはまだ送られていないか、管理者の承認待ち状態です。 この記事に対するご意見やご質問、ご感想などありましたら個別記事ページの送信フォームからお送り下さい。
2005-12-20T21:51+09:00
Movable Type では、デフォルトでは年別のアーカイブは作成されません ( 作成できません ) 。しかし、フォーマットの関係上 yyyy/ というディレクトリが存在するため、年別のアーカイブは作った方が良いでしょう。そこで、年別のアーカイブの作成方法と、合わせて全記事の一覧を年ごとに分ける方法を紹介します。
昨日はヴァルシュタイナーを飲んだ後に釈云麦をロックでいただいていたので、日付が変わる頃にはすっかり良い気分になりました。 そんな折に IRC チャンネル #hxxk にて drry さん ( drry+@->Weblog ) に年別アーカイブに関する質問を受け、後日回答しますと言っていたのでちょっと解説してみます。 なお、環境は Movable Type 3.2-ja-2 を想定していますので、それ以外の言語のものや古いバージョンのものをお使いの場合は適宜解説を読み替えてください。
先日 Movable Type 3.2 の Archive File Path 形式のフォーマットと実際の出力フォーマットの早見表にて、デフォルトでの URI 設計について触れました。 エントリアーカイブの場合は yyyy/mm/entry_basename.html 、日別アーカイブの場合は yyyy/mm/dd/index.html 、月別アーカイブの場合は yyyy/mm/index.html のようになっています。 しかし、 yyyy/index.html のようなフォーマットで生成される年別アーカイブはありません。
そのために、 yyyy/ のディレクトリにアクセスしても、 403 Forbidden となってしまうか、あるいはディレクトリ内のリソースが全て丸見えになってしまうといったことになってしまいます。 ( サーバ側の設定によりますし、人によってはわざとディレクトリを丸見えにすることで年別アーカイブ代わりにしているケースもあるでしょうが、あまりスマートではありません。 )
実際のテンプレートソースを紹介する前に、プラグインの導入をお願いします。 デフォルトでは年別アーカイブが作られないということは、標準のテンプレートタグでは実現できないことと近似ですゆえ。
必要なプラグインは ArchiveYear Plugin と ArchiveLoad Plugin の 2 つなのですが、現在は作者のサイト自体が 404 Not Found のようです。 Junkline - MT の過去ログリンク表示を nDiary (ごにょり済み)風にという記事にプラグインのミラーが置かれていますので、そこから入手して plugins フォルダに put してください。
なお、Junkline - MT の過去ログリンク表示を nDiary (ごにょり済み)風にや、そこから辿ることができる Chitatopops: 年別アーカイブにてテンプレートソースの実例が書かれているため、これら 2 つの記事を見ていただくだけでも年別アーカイブは実現できますが、せっかくなので次項以降では hxxk.jp でのソースを紹介していこうと思います。
年別アーカイブを作る場合、まずはテンプレートから作成します。 Movable Type の管理画面から「テンプレート」→「アーカイブ」→「テンプレートを新規作成」とクリックしていき、次のソースを参考にしてテンプレートを作成します。 テンプレートの名前は任意で構いませんが、年別アーカイブであるということが分かりやすい名前にしてください。
<?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"$> の <$MTArchiveDate format="%Y"$> 年の記事タイトル一覧" />
<title><$MTBlogName encode_html="1" remove_html="1"$> - <$MTArchiveDate format="%Y"$> 年アーカイブ</title>
<link rel="stylesheet" href="<$MTBlogURL$>styles-site.css" type="text/css" />
<MTArchiveYearPrevious><link rel="prev" href="<$MTBlogArchiveURL$><$MTArchiveDate format="%Y/"$>" title="<$MTBlogName encode_html="1" remove_html="1"$> - <$MTArchiveDate format="%Y"$> 年アーカイブ" /></MTArchiveYearPrevious>
<MTArchiveYearNext><link rel="next" href="<$MTBlogArchiveURL$><$MTArchiveDate format="%Y/"$>" title="<$MTBlogName encode_html="1" remove_html="1"$> - <$MTArchiveDate format="%Y"$> 年アーカイブ" /></MTArchiveYearNext>
</head>
<body>
<h1><a href="<$MTBlogURL$>"><$MTBlogName encode_html="1" remove_html="1"$></a></h1>
<h2><$MTArchiveDate format="%Y"$> 年アーカイブ</h2>
<ol>
<MTArchiveYear order="descend">
<MTArchiveYearIfEntries>
<MTArchiveLoad>
<MTDateHeader>
<li><a href="<$MTBlogArchiveURL$><$MTArchiveDate format="%Y/%m/"$>" title="<$MTBlogName encode_html="1" remove_html="1"$> - <$MTArchiveDate format="%Y 年 %m"$> 月アーカイブ"><$MTArchiveDate format="%Y 年 %m"$> 月アーカイブ</a>
<ol>
<MTEntries sort_order="descend">
<li><$MTArchiveDate format="%Y/%m/%d" %H:%M"$> - <a href="<$MTEntryPermalink$>"><$MTEntryTitle$></a></li>
</MTEntries>
</ol>
</li>
</MTDateHeader>
</MTArchiveLoad>
</MTArchiveYearIfEntries>
</MTArchiveYear>
</ol>
</body>
</html>
少し変更を加えていますが、 hxxk.jp - 2005 の内容と同じような形式のテンプレートです。 その年の月別アーカイブおよび記事の一覧にリンクするようなアーカイブです。
次に、テンプレートの関連付けを行います。 Movable Type の管理画面から「設定」→「公開」→「マッピングを新規作成」とクリックしていき、「アーカイブの種類」は月別を選択し、「テンプレート」は先ほど作成した年別アーカイブテンプレートを選択します。
関連付けをした後に、出力フォーマットをカスタマイズします。
先ほど関連付けをしたテンプレートの横のプルダウンメニューをクリックし、「カスタマイズする」を選び、
%y/%i
と記述してください。
( Movable Type 3.2 以前のバージョンをお使いの場合、あるいは Archive File Path 形式を好まない場合は
<$MTArchiveDate format="%Y"$>/<$MTIndexBasename$><$MTBlogFileExtension$>
と記述してください。 )
出力フォーマットまで設定したら、あとは月別アーカイブを再構築して完了です。 以後、月別アーカイブを再構築する時、または記事を投稿および更新する時に年別アーカイブも更新されることになります。
ついでに、年別アーカイブのソースを利用して、全記事一覧を年ごとに分ける方法を紹介します。 hxxk.jp - 記事目次がそのまま実例になりますが、今度はインデックステンプレートの方に手を加えることになります。 ( 新たに作成しても構いませんし、「アーカイブページ」のテンプレート ( Master Archive Index ) に適用しても構いません。 )
<?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" />
</head>
<body>
<h1><a href="<$MTBlogURL$>"><$MTBlogName encode_html="1" remove_html="1"$></a></h1>
<h2>全記事アーカイブ</h2>
<ol>
<MTArchiveList archive_type="Monthly">
<MTArchiveDateHeader>
<li><a href="<$MTBlogArchiveURL$><$MTArchiveDate format="%Y/"$>" title="<$MTBlogName encode_html="1" remove_html="1"$> - <$MTArchiveDate format="%Y"$> 年アーカイブ"><$MTArchiveDate format="%Y"$> 年アーカイブ</a>
<ol>
<MTArchiveYear order="descend">
<MTArchiveYearIfEntries>
<MTArchiveLoad>
<MTDateHeader>
<li><a href="<$MTBlogArchiveURL$><$MTArchiveDate format="%Y/%m/"$>" title="<$MTBlogName encode_html="1" remove_html="1"$> - <$MTArchiveDate format="%Y 年 %m"$>月アーカイブ"><$MTArchiveDate format="%Y 年 %m"$>月アーカイブ</a>
<ol>
<MTEntries sort_order="descend">
<li><$MTArchiveDate format="%Y/%m/%d %H:%M"$> - <a href="<$MTEntryPermalink$>"><$MTEntryTitle$></a></li>
</MTEntries>
</ol>
</li>
</MTDateHeader>
</MTArchiveLoad>
</MTArchiveYearIfEntries>
</MTArchiveYear>
</ol>
</li>
</MTArchiveDateHeader>
</MTArchiveList>
</ol>
</body>
</html>
こちらはインデックステンプレートになるため、記事を投稿および更新する時に更新されることになります。
4 件のリプライが送られています。 この記事に対するご意見やご質問、ご感想などありましたら個別記事ページの送信フォームからお送り下さい。
mixiのMTコミュで質問のあった季節別アーカイブの作成を、導入したまま使用するタイミングを待っていたプラグインで実現してみた。
エントリー一覧を年毎に区切って一括で出力できないかと思って、こちらのサイトにたどり着きました。 悪戦苦闘すること4時間以上。 MTArchiveDateHeaderってデフォルトのタグじゃなくて、プラグインの機能なんですね。。。 お時間あるときにでも加えておいてもらえると報われます。。。。
MT3.2-ja-2でどんどん縦長になっていく月別アーカイブを年別に区切ってすっきり表示するカスタマイズを実装してみた。
2005-12-20T21:44+09:00
ヴァルシュタイナーを飲みました。
リプライはまだありません。

ドイツのピルスナービール。 ドイツでは醸造量、販売量共に No.1 のビールだそうで、日本で言うところのアサヒスーパードライのような位置付けでしょうか。 ( 個人的にはアサヒビールは好きではありませんが。 ) No.1 ということもあって万人向け……というか安定した美味しさだなあという感想を抱きましたが、同じドイツのピルスナーならばエク ピルスの方が個人的には好きな味です。 アルコール度数は 4.8% 。
リプライはまだ送られていないか、管理者の承認待ち状態です。 この記事に対するご意見やご質問、ご感想などありましたら個別記事ページの送信フォームからお送り下さい。
2005-12-19T19:35+09:00
多くの weblog で採用されてしまっている「本文の冒頭」≒「要約」という仕様。これが現状のデファクトスタンダードであることは否めませんが、それは果たして本当の意味での要約となっているのでしょうか。本文と要約は分けて記述できるようになっている方が、より的確な要約を提供できると考えます。
要約(や概要)しか入れてないにもかかわらず、「続きを読む」とか「文末を…で終わらせる」のような「これは要約です」という明示的なものがないようなのは勘弁してほしい。 RSSリーダーで読んでいる人はあれが要約だとは気がつかないんじゃないかな。 本家に誘導できないような要約はデメリットでしかないよ。
要約に
「続きを読む」
と書かれているとか、要約の
「文末を…で終わらせる」
といった「要約であることの示し方」は、単なる特定ツールの実装にすぎず、一定のルールに基づいたものではないと思います。
文末に ... のような文字が配置される例は、概要欄 ( excerpt ) を記入していない場合の Movable Type や、 tDiary などが該当しますね。 そして、 RSSに全文を入れるとか入れないとか - HsbtDiary (2005-12-13) 内で、要約であることが分かり辛い例で出されているのははてなダイアリーです。 といっても、これらの要約とはてなダイアリーの要約の違いは「文末に ... のような文字列があるか無いか」だけなんですけど、 ... があるか無いかの差ってそれほど大きいのかなあ。
ただ、情報量は多ければ多いほど、オレの場合は気にとめやすいというメリットは強調しておきたい
と言っているのに、要約がどうこう言っているのもちょっと疑問です。
と言うのも、例に出されている Don’t lose your temper の RSS Feed は要約だけでなく、
<content:encoded>
で全文を合わせて提供しているんですよね。
( はてなダイアリーの場合は「要約のみを提供」か「要約と本文を合わせて提供」か選択することができます。詳しくは Feed に全文を入れるとか入れないとかより、結局はより多くの人に行き渡る形態の選択と、記事自体の質の向上が大事だと思うにて触れています。 )
そして、自分でも FEEDBRINGER に Don’t lose your temper の RSS Feed を登録してみたんですが、要約と本文のどちらを表示するかの選択肢は無く、本文が表示されるようになりました。
要約にあたる部分の文末に ... のような文字を配置していたり、またちょっと実例が思い浮かびませんが、「続きを読む」という表現を要約に含めていたりする weblog は、極端に言ってしまえば「要約じゃないものを要約として配信している」状態ではないでしょうか。 先ほどの項で出した「概要欄 ( excerpt ) を記入していない Movable Type 」や tDiary やはてなダイアリーでは、本文部分の冒頭を以って要約としていますが、それは必ずしも要約足りえません。
本文部分の冒頭に、序論となるような意識を持った導入文 ( introduction ) を配置するなら要約足りえるかもしれませんが、冒頭を以って要約としている weblog のほとんどはそういった書き方をしていません。 ( この辺りの話は続きを読む ? 本文を読む ? で触れました。 ) では、本文部分の冒頭を要約にするのではなく、別途記入欄があって適切な要約を書くことができる weblog 、 Movable Type や goo ブログ ( gooブログ スタッフブログ:概要文が書けるようになりました ) はどうでしょうか。 本文部分の冒頭を要約とせず、別途要約を記入してるのであれば、その要約に「続きを読む」といった表現を含めたり、文末に ... のような文字列を配置したりすると不自然なことになります。 そして、それは果たして「要約であると明示されていない」ということに繋がるのでしょうか ?
Movable Type の話になりますが、要約にあたるものを本文とは別に書く欄として概要 ( excerpt ) の記入欄があります。 それについては概要 ( excerpt ) の重要性や概要 ( excerpt ) は有効活用されていない ? で触れましたが、漫然と冒頭から要約を作成するよりも、作成者にとって多少の手間をかけることになっても、私は作成者に概要欄を書いてもらいたいと思っています。 そして、同様の機能を持つ weblog ( 先ほど例示した goo ブログなど ) を使っている方には、同様に活用してもらいたいと考えています。
そういった機能を有する weblog にて活発な活用がなされれば、そういった機能を持っていない weblog であっても、いずれ実装されるかもしれない、そういった期待を私は抱いています。 そうなっていけば、「続きを読む」とか ... とかといった小手先の表現でなくとも要約が要約であると明示できるのではないでしょうか。
はてなブックマーク - むだづかいにっき♂:RSSリーダーは部分表示? 全文表示?の id:Dice-Kei さん ( はてなブックマーク - ブクマはじめますた ) の
来年の夏ごろのむだづかいにっきのメインテーマが「description(概要)の正しい使い方」になることを期待。
今のgooブログのままだと、冒頭だけ書いてあっても何のことかさっぱり分からん。
というコメントにもあるように、冒頭を以って要約を作るのは古い ! これからは要約を別途丹精込めて書いたり、鋭い切り口の要約を別途書いたりするのが来年のモテムーヴメントである ! と、断言しておきます。
それが的中するかどうかは保障しませんが。
単に冒頭部分を機械的に抜粋して文末に ... を配置したり「続きを読む」という表現を加えたりしていれば要約の明示となるのか、それならば本文とは別に記述されてある、本来の意味での要約は明示とならないのかを考えてみました。
2 件のリプライが送られています。 この記事に対するご意見やご質問、ご感想などありましたら個別記事ページの送信フォームからお送り下さい。
背中を見てみるとハンドアックスが刺さっていることに気がつく。
RSSに全文を入れるとか入れないとか - HsbtDiary (2005-12-13)に対し...
要は日本語で良く有る文章スタイルと、blogツール開発者の英語文化圏にある文章スタイルに違いが有るので、機能を別の方法で応用してしまっているってことじゃな...
2005-12-18T23:58+09:00
エッゲンベルガー ウアボック 23 を飲みました。
リプライはまだありません。

オーストリアのダブルボックラガービール。 ダブルボックということでアルコール度数が 9.6% と高く、非常に濃厚な味わいです。 色は褐色で、泡はあまり立ちません。 味わいも濃厚ですが、お酒としての効果も濃厚で、この日はこれ 1 本で心地よく酔うことが出来ました。
リプライはまだ送られていないか、管理者の承認待ち状態です。 この記事に対するご意見やご質問、ご感想などありましたら個別記事ページの送信フォームからお送り下さい。
2005-12-18T23:53+09:00
青龍麦酒を飲みました。
リプライはまだありません。

Tour "2005 Autumn Kyoto" the Report でちょこっと触れていた、京都で購入した京都清水限定のケルシュタイプビール。 草原さん ( Diary - Notes | castle of sand ) にお土産として無事渡せたので自分でも飲みました。 ケルシュタイプということで、上面発酵・低温熟成のビールとなっており、あっさり……というかシャープな味わいでした。 ( こういう時に自分の語彙の少なさを痛感します。シャープな味わいって文字で伝わるのかなあ。 ) アルコール度数は約 5% 。
ちなみに、ケルシュという呼称は本来はドイツ国内の、更に法律で定められた地域で造られたビールにしか使えないため、ケルシュタイプと記述させていただきました。 日本国内で製造されたカマンベールチーズのようなものでしょうか。
リプライはまだ送られていないか、管理者の承認待ち状態です。 この記事に対するご意見やご質問、ご感想などありましたら個別記事ページの送信フォームからお送り下さい。
2005-12-16T18:42+09:00
バージョン 1.5 以前の Firefox では target="_blank" なリンクをどうにかしたい場合は、拡張機能を用いたり Greasemonkey スクリプトを用いたりしなければなりませんでしたが、 Firefox 1.5 では標準のオプションで扱えるようになりました。
target="_blank"
以前から、 Destroy target="_blank" やはてなダイアラのための target="_blank" 講座などの記事で
target="_blank"
をどうにかする方法を紹介してきましたが、 Firefox 1.5 ではもっと簡単な方法で実現できることが分かりました。
昨日ようやく重い腰を上げて、 朝顔日記 - Firefox 1.5 への移行を参考にして Firefox 1.5 をインストールしたのですが、標準のオプションで「新しいウィンドウを開くリンク」をどう扱うかを設定できるようになっていたのですね。 オレンジニュース(2005-11-30) や vimrc diary / 2005-12 で Destroy target="_blank" が取り上げられていましたが、このような手順を踏まなくとも良かったわけです。
はてなダイアラのための target="_blank" 講座を書いたのが 11 月 29 日であったため、もう 1 日待ってすぐに Firefox 1.5 をインストールすれば間に合ったのになあ。
以下に示す設定方法は Firefox 1.5 におけるものです。 1.5 以前の Firefox を使われている場合は、 Destroy target="_blank" で紹介している Greasemonkey スクリプトを使うか、 Tabbrowser Extensions のシングルウィンドウモード、またはその類似の機能を持つ拡張 ( Tabbrowser Preferences や Single Window や Petit TBE ) を使うなどの代替手段を用いてください。
ツール(T) をクリックし、オプション(O) をクリックする。
「タブ」アイコンをクリックする。
「新しいウィンドウを開くリンクは次の場所に開く」のチェックボックスにチェックを入れ、「現在のタブまたはウィンドウ」または「新しいタブ」のラジオボタンのどちらかを選択する。設定は以上です。 最終的な挙動は「現在のタブまたはウィンドウで開く」か「新しいタブで開く」のどちらかになりますが、これはお好きな方を選んでください。
1 件のリプライが送られています。 この記事に対するご意見やご質問、ご感想などありましたら個別記事ページの送信フォームからお送り下さい。
aタグのtarget="_blank"属性を無視できるように ページ: 次期ブラウザへの要望 投稿者: john 優先順位: 低 状態...
preで折り返す設定 - HsbtDiary (2005-12-07) 、およびそこからリンクされている ◆2 CSS: 「折り返す」pre - ただのにっき (2005-09-22) に、 pre 要素の内容を CSS で折り返す方法が書かれていました。
CSS 3 で定義されている値を用いていたり、各ブラウザの独自の値や独自のプロパティを用いていたりと、手法としてもあまり積極的に薦められるものではないのですが、この「 pre 要素の内容を折り返す」という目的自体も、仕様のみを判断基準とするならば、あまり薦められるものではないと思います。
The PRE element tells visual user agents that the enclosed text is "preformatted". When handling preformatted text, visual user agents:
- May leave white space intact.
- May render text with a fixed-pitch font.
- May disable automatic word wrap.
- Must not disable bidirectional processing.
と書かれており、また CSS 2 の仕様でも
Conforming user agents may ignore the 'white-space' property in author and user style sheets but must specify a value for it in the default style sheet.
と書かれているため、 CSS で折り返しを指定していても、 UA はそれを無視しても良いということになっているようです。
また、当然ですが CSS に対応していない UA であれば折り返しの指定は無効になります。
( CSS を用いて pre 要素を折り返す手法なので、「 CSS に対応していない UA であれば~」という指摘はお門違いかもしれませんが。 )
pre 要素への CSS を用いての折り返し指定がよろしくない、あるいは UA に無視される可能性があるというならどうすれば良いのか ? pre 要素内に文字数の多い行があった場合は、そのまま折り返しをせずに表示させるべきなのか ? と思われるかもしれません。 それならば、 pre 要素に対する CSS の指定を次のようにしてはどうでしょう。
pre {
width: 100%;
overflow: auto;
}
こうすることにより、 CSS 対応のブラウザであれば、内部のテキストの長さが pre 要素の幅を超える場合は横スクロールバーを出してその幅に収めるようになります。
( この width は指定しなくても良いのですが、指定しなかった場合は IE にてスクロールバーが出ず、 pre 要素の幅をはみ出して表示されます。
あるいは、
overflow: auto;
ではなく
overflow: scroll;
と指定するという手法もあります。 )
なお、 MacIE では overflow プロパティに visible 以外の値が指定された要素が表示されないというバグがありますので、 MacIE をターゲットに含める場合は、この指定を回避するような記述をした方が良いかもしれません。
( 例えば、用途別CSSハック一覧表のバックスラッシュハックなど。 )
この手法であれば、 CSS による折り返しをせずに、かつ閲覧領域を突き破ることなく表示できます。 ( hxxk.jp ではこちらの方式を採用しています。 )
ただし、仕様ではなくユーザビリティを判断基準とするならば、横方向のスクロールバーが出てしまうということでお勧めできないのですが。 仕様を優先する ( 未勧告の値やブラウザ独自の値を用いない ) か、ユーザビリティを優先するかの判断が難しいところです。
うーん、preは投稿する時に適当に改行をいれて折り返すべきか、CSSでは見やすく改行されるから、RSSリーダーの読者には我慢してもらうべきか。
これは困った。
という点については、読者の方にお任せする方針で良いのではないでしょうか。
製作者スタイルシートにおいて折り返しを設定しているのですから、どうしても見辛ければ製作者スタイルシートが適用される方で見れば良いのです。
もしくは RSS リーダ側にユーザスタイルシートを設定するか。
全てのリーダでユーザスタイルシートが使えるかどうかは分かりませんが。
( Bloglines や FEEDBRINGER やはてなRSS などの、ブラウザを使用するタイプは比較的容易にユーザスタイルシートが使えると思います、 )
そして、
投稿する時に適当に改行をいれて折り返す
というのは本末転倒である、というのも読者任せにすべきである理由です。
pre 要素は整形済テキストをマークアップするものであり、改行自体もその整形というものに含まれます。
そこで折り返しという目的のために改行を入れるというのは、本来整形されるべき結果と異なってしまうと言えるでしょう。
また、適当な ( 適切な ) 改行を入れたつもりであっても、読者が設定しているブラウザ、あるいは RSS リーダの閲覧領域の幅は千差万別であり、適切な改行を行える可能性は低いと思います。
適当な改行を入れるよりも、適宜ユーザスタイルシートを使ってもらうか、あるいは製作者スタイルシートが適用された状態で見てもらうというように、読者にお任せする方針の方が良いと思います。
3 件のリプライが送られています。 この記事に対するご意見やご質問、ご感想などありましたら個別記事ページの送信フォームからお送り下さい。
毎度どもです、個人的にはCSSで強制折り返しなんてことを考える人の気が知れないので本題については置いといて、width指定を付けるとIEでもスクロールバーが出るというのは頗る有難い知識でした。放置していたIE対応ができて大感謝。
レス遅れましたー。
以前同じように悩んで、苦し紛れに width: 90%; のような指定を pre に行ったらうまくいったので、 IE はwidth が明示されていなかったら、そのボックスの内容から幅を算出するのかなあと勝手に想像している次第です。
このブログではサンプルコードを載せることが多いので、整形済みテキストのためのPREタグを結構使う。PREタグは、括られた部分を整形済みテキストとして扱い、...
2005-12-13T19:03+09:00
「公開の設定」の「アーカイブ・マッピング」部分の Archive File Path 形式のフォーマット。このフォーマットと実際の出力フォーマットの一覧表を作りました。これで一見しただけでは分かり辛い %hoge 形式のアーカイブ・マッピングもバッチリ !
リプライはまだありません。
にて Archive File Path 形式のフォーマットについて解説しました。 今回はデフォルトでの各種アーカイブ・マッピングにおける Archive File Path 形式のフォーマットと実際の出力フォーマットの早見表を作ってみました。 この表と、前回の Archive File Path 形式のフォーマットの一覧表を見れば、たいていの形式の URI フォーマットが実現できるのではないかと思います。
なお、 Movable Type 3.2 以前のように、テンプレートタグ形式での指定が好みだという方 ( 例えば私のように ) もいらっしゃると思うので、そちらの形式でのものも合わせて書いてみました。
ただし、空白を - に置き換えるもの ( %-a と %-c と %-C ) についてはテンプレートタグでの指定ができませんので、それを用いるものについては「代替できず」と記述しています。
また、週別アーカイブの %d-week についても代替できるテンプレートタグを見つけられなかったため、「代替できず」と記述しています。
| アーカイブの種類 | テンプレート | 出力フォーマット | Archive File Path 形式のフォーマット | テンプレートタグ形式での記述 |
|---|---|---|---|---|
| エントリー | エントリー・アーカイブ | yyyy/mm/entry_basename.html | %y/%m/%f |
<$MTArchiveDate format="%Y"$>/<$MTArchiveDate format="%m"$>/<$MTEntryBasename$><$MTBlogFileExtension$> |
| エントリー | エントリー・アーカイブ | yyyy/mm/entry_basename/index.html | %y/%m/%b/%i |
<$MTArchiveDate format="%Y"$>/<$MTArchiveDate format="%m"$>/<$MTEntryBasename$>/<$MTIndexBasename$><$MTBlogFileExtension$> |
| エントリー | エントリー・アーカイブ | yyyy/mm/dd/entry_basename.html | %y/%m/%d/%f |
<$MTArchiveDate format="%Y"$>/<$MTArchiveDate format="%m"$>/<$MTArchiveDate format="%d"$>/<$MTEntryBasename$><$MTBlogFileExtension$> |
| エントリー | エントリー・アーカイブ | yyyy/mm/dd/entry_basename/index.html | %y/%m/%d/%b/%i |
<$MTArchiveDate format="%Y"$>/<$MTArchiveDate format="%m"$>/<$MTArchiveDate format="%d"$>/<$MTEntryBasename$>/<$MTIndexBasename$><$MTBlogFileExtension$> |
| エントリー | エントリー・アーカイブ | category/sub_category/entry_basename.html | %c/%f |
<$MTSubCategoryPath$>/<$MTEntryBasename$><$MTBlogFileExtension$> |
| エントリー | エントリー・アーカイブ | category/sub_category/entry_basename/index.html | %c/%b/%i |
<$MTSubCategoryPath$>/<$MTEntryBasename$>/<$MTIndexBasename$><$MTBlogFileExtension$> |
| エントリー | エントリー・アーカイブ | category/sub-category/entry_basename.html | %-c/%f |
代替できず |
| エントリー | エントリー・アーカイブ | category/sub-category/entry_basename/index.html | %-c/%b/%i |
代替できず |
| エントリー | エントリー・アーカイブ | primary_category/entry_basename.html | %C/%f |
<$MTEntryCategory dirify="1"$>/<$MTEntryBasename$><$MTBlogFileExtension$> |
| エントリー | エントリー・アーカイブ | primary_category/entry_basename/index.html | %C/%b/%i |
<$MTEntryCategory dirify="1"$>/<$MTEntryBasename$>/<$MTIndexBasename$><$MTBlogFileExtension$> |
| エントリー | エントリー・アーカイブ | primary-category/entry_basename.html | %-C/%f |
代替できず |
| エントリー | エントリー・アーカイブ | primary-category/entry_basename/index.html | %-C/%b/%i |
代替できず |
| 日別 | 日付アーカイブ | yyyy/mm/dd/index.html | %y/%m/%d/%i |
<$MTArchiveDate format="%Y"$>/<$MTArchiveDate format="%m"$>/<$MTArchiveDate format="%d"$>/<$MTIndexBasename$><$MTBlogFileExtension$> |
| 週別 | 日付アーカイブ | yyyy/mm/dd-week/index.html | %y/%m/%d-week/%i |
代替できず |
| 月別 | 日付アーカイブ | yyyy/mm/index.html | %y/%m/%i |
<$MTArchiveDate format="%Y"$>/<$MTArchiveDate format="%m"$>/<$MTIndexBasename$><$MTBlogFileExtension$> |
| カテゴリー | カテゴリー・アーカイブ | category/sub_category/index.html | %c/%i |
<$MTSubCategoryPath$>/<$MTIndexBasename$><$MTBlogFileExtension$> |
| カテゴリー | カテゴリー・アーカイブ | category/sub-category/index.html |
%-c/%i |
代替できず |
リプライはまだ送られていないか、管理者の承認待ち状態です。 この記事に対するご意見やご質問、ご感想などありましたら個別記事ページの送信フォームからお送り下さい。
2005-12-09T23:22+09:00
Movable Type 3.2 より仕様が変わった「公開の設定」の「アーカイブ・マッピング」部分の出力フォーマット。このフォーマットの一覧表や、テンプレート内でも使用する方法をご紹介。
entry_basename.html と entry_basename/index.html で触れたアーカイブ・マッピングですが、 Movable Type 3.2 になってからは何だか短縮記法みたいな書き方が登場しました。
例えば、「公開の設定」の「アーカイブ・マッピング」の画面にてエントリー・アーカイブで yyyy/mm/entry_basename.html を選択した後、再度「カスタマイズする」を選ぶと、 yyyy/mm/entry_basename.html の部分が
%y/%m/%f
という表記に変わり、それをカスタマイズする形になります。
これの仕様ってどうなっているのかなあと思ってマニュアルをごそごそ読みふけったり、色々と検索してみたりしていると、 Movable Type 3.2 User Manual: E: Archive File Path Specifiers Archives というマニュアルページを発見しました。
これによると、
The following are the recognized specifiers to create a "custom" Archive File Path on the weblog Publishing settings page.
ということで、やはり「公開の設定」の「アーカイブ・マッピング」部分で用いるもののようです。
なお、この仕様については Movable Type: アーカイブ・マッピングの変更方法 [ItsMemo IT] にて日本語訳が掲載されているので合わせてご覧ください。
ここで、私は何となく「このアーカイブファイルパスってテンプレートタグで使えないのかなあ」と思い、拙作の Movable Type 3.2 のテンプレートタグ一覧を眺めていると、 MTFileTemplate というそれっぽいテンプレートタグが !
しかもこの MTFileTemplate のマニュアルを見ると、
Produces a file name and path using the archive file naming specifiers.
See Appendix E.
と書いてあるので、やはり使えそうです。
<$MTFileTemplate format="出力フォーマット"$>
という形式で記述します。
出力フォーマットによっては特定のコンテナタグ内でしか使えないものがあり、それに伴って使えるテンプレートや使えないテンプレートが分かれますが、後述する代替記述の内容から判断してください。
なお、テンプレート内ではなく「公開の設定」の「アーカイブ・マッピング」部分で用いる場合は出力フォーマットのみを書けばいいので、間違えないようにしてください。
また、 <$MTFileTemplate$> は Movable Type 3.2 以降のバージョンでのみ使用できるようです。
以下の表は、次に示すサンプルデータを用いた場合の表示結果を示しています。
表示結果を分かりやすくするために、わざと空白を含ませたり - を含ませたりしています。
m_a ko-to
changelog_ver101_to-102
information/c_h a-nge 更新履歴
2005-02-01T01:02:03+09:00
1210
php
| <$MTFileTemplate$> の記述 | <$MTFileTemplate$> の表示結果 | 各種テンプレートタグによる代替記述 | 代替記述の表示結果 | 備考 |
|---|---|---|---|---|
<$MTFileTemplate format="%a"$> |
m_a_koto | <$MTEntryAuthorDisplayName dirify="1"$> |
m_a_koto | MTEntryAuthorDisplayName ( 投稿者のプロフィール画面の「表示名」 ) を表示します。日本語が使われている場合は除去されます。 |
<$MTFileTemplate format="%-a"$> |
m_a-koto | <$MTEntryAuthorDisplayName$> ※若干の違いあり |
m_a ko-to | MTEntryAuthorDisplayName ( 投稿者のプロフィール画面の「表示名」 ) を表示します。日本語が使われている場合は除去されます。また、 <$MTFileTemplate format="%a"$> との違いとして、 MTEntryAuthorDisplayName に空白が含まれていた場合は - に変換され、また MTEntryAuthorDisplayName 自体に含まれていた - は除去されるため、 <$MTEntryAuthorDisplayName$> では完全には代替できません。 |
<$MTFileTemplate format="%b"$> |
changelog_ver101_to-102 | <$MTEntryBasename$> |
changelog_ver101_to-102 | 「エントリー・ファイル名」を表示します。 |
<$MTFileTemplate format="%c"$> |
information/c_h_ange_ | <$MTSubCategoryPath$> |
information/c_h_ange_ | MTSubCategoryPath ( 最上位カテゴリから現在のカテゴリまでのパスを / で区切ったもの ) を表示します。カテゴリ名に日本語が使われている場合は除去されます。 |
<$MTFileTemplate format="%-c"$> |
information/c_h-ange- | <$MTSubCategoryPath$> ※若干の違いあり |
information/c_h_ange_ | MTSubCategoryPath ( 最上位カテゴリから現在のカテゴリまでのパスを / で区切ったもの ) を表示します。カテゴリ名に日本語が使われている場合は除去されます。また、 <$MTFileTemplate format="%c"$> との違いとして、カテゴリ名に空白が含まれていた場合は - に変換されるため、 <$MTSubCategoryPath$> では完全には代替できません。 |
<$MTFileTemplate format="%C"$> |
c_h_ange_ | <$MTEntryCategory dirify="1"$> |
c_h_ange_ | MTEntryCategory ( プライマリカテゴリの名前 ) を表示します。日本語が使われている場合は除去されます。 |
<$MTFileTemplate format="%-C"$> |
c_h-ange- | <$MTEntryCategory$> ※若干の違いあり |
c_h a-nge 更新履歴 | MTEntryCategory ( プライマリカテゴリの名前 ) を表示します。日本語が使われている場合は除去されます。また、 <$MTFileTemplate format="%C"$> との違いとして、 MTEntryCategory に空白が含まれていた場合は - に変換され、また MTEntryCategory 自体に含まれていた - は除去されるため、 <$MTEntryCategory$> では完全には代替できません。 |
<$MTFileTemplate format="%d"$> |
01 | <$MTArchiveDate format="%d"$> |
01 | 記事の作成日を 2 桁で表示します。日付が 1 桁の時には先頭に 0 を配置します。 |
<$MTFileTemplate format="%D"$> |
1 | <$MTArchiveDate format="%e"$> |
1 | 3-letter language-dependent abbreviation of the week day. という説明になっていますが、実際には記事の作成日を 2 桁で表示します。日付が 1 桁の時には先頭に空白を配置します。 |
<$MTFileTemplate format="%e"$> |
001210 | <$MTEntryID pad="1"$> |
001210 | MTEntryID ( エントリー ID ) を 6 桁で表示します。 ID が 6 桁に満たない場合は先頭から 0 を使って 6 桁に揃えます。 |
<$MTFileTemplate format="%E"$> |
1210 | <$MTEntryID$> |
1210 | MTEntryID ( エントリー ID ) を表示します。桁数はそのままで表示します。 |
<$MTFileTemplate format="%f"$> |
changelog_ver101_to-102.php | <$MTArchiveFile$> |
changelog_ver101_to-102.php | MTArchiveFile ( 拡張子付のファイル名 ) を表示します。 <$MTArchiveFile$> だけでなく <$MTEntryBasename$><$MTBlogFileExtension$> でも代替が可能です。 |
<$MTFileTemplate format="%F"$> |
changelog_ver101_to-102 | <$MTEntryBasename$> |
changelog_ver101_to-102 | 拡張子が付かないファイル名を表示します。 |
<$MTFileTemplate format="%h"$> |
01 | <$MTArchiveDate format="%H"$> |
01 | 24 時間表記の記事の作成時間を 2 桁で表示します。時間が 1 桁の時には先頭に 0 を配置します。 |
<$MTFileTemplate format="%H"$> |
1 | <$MTArchiveDate format="%k"$> |
1 | 24 時間表記の記事の作成時間を 2 桁で表示します。時間が 1 桁の時には先頭に空白を配置します。 |
<$MTFileTemplate format="%i"$> |
index.php | <$MTIndexBasename$><$MTBlogFileExtension$> |
index.php | MTIndexBasename ( インデックスファイル名 ) を拡張子付きで表示します。 |
<$MTFileTemplate format="%I"$> |
index | <$MTIndexBasename$> |
index | MTIndexBasename ( インデックスファイル名 ) を拡張子無しで表示します。 |
<$MTFileTemplate format="%j"$> |
032 | <$MTArchiveDate format="%j"$> |
032 | 記事の作成日の年初からの日数を 3 桁で表示します。日数が 3 桁に満たない場合は先頭から 0 を使って 3 桁に揃えます。 |
<$MTFileTemplate format="%m"$> |
02 | <$MTArchiveDate format="%m"$> |
02 | 記事の作成月を 2 桁で表示します。月が 1 桁の時には先頭に 0 を配置します。 |
<$MTFileTemplate format="%n"$> |
02 | <$MTArchiveDate format="%M"$> |
02 | 記事の作成分を 2 桁で表示します。分が 1 桁の時には先頭に 0 を配置します。 |
<$MTFileTemplate format="%s"$> |
03 | <$MTArchiveDate format="%S"$> |
03 | 記事の作成秒を 2 桁で表示します。秒が 1 桁の時には先頭に 0 を配置します。 |
<$MTFileTemplate format="%x"$> |
.php | <$MTBlogFileExtension$> |
.php | MTBlogFileExtension ( 「公開の設定」の「アーカイブの拡張子」 ) を表示します。 |
<$MTFileTemplate format="%y"$> |
2005 | <$MTArchiveDate format="%Y"$> |
2005 | 記事の作成年を 4 桁で表示します。 |
<$MTFileTemplate format="%Y"$> |
05 | <$MTArchiveDate format="%y"$> |
05 | 記事の作成年を 2 桁で表示します。年が 1 桁の時には先頭に 0 を配置します。 |
空白を - に置き換えるもの ( %-a と %-c と %-C ) 以外は他のテンプレートタグでの代替が可能なので、積極的にテンプレート内で <$MTFileTemplate$> を使う必要はないかな、と思いました。
テンプレートの記述をなるべくすっきりさせたいという方は <$MTFileTemplate$> を用いると良いかもしれません。
しかし、テンプレート内ではなく「公開の設定」の「アーカイブ・マッピング」部分にてこの仕様自体はよく利用することになると思うので、早見表として先ほどの各種フォーマットとその内容の表をメモしていただくと良いかも。
2 件のリプライが送られています。 この記事に対するご意見やご質問、ご感想などありましたら個別記事ページの送信フォームからお送り下さい。
シンヤさん ( http://d.hatena.ne.jp/code404/ ) のアドバイスにより、
table:hover{
position: relative;
z-index: 9999;
}
とすることで一応の解決。 :hover 未対応のブラウザは解決していませんが。
2005-12-08T20:20+09:00
post_29.html という URI と、 post_29/ という URI の違いについて。 Movable Type におけるその設定方法は ? / で終わる URI にする理由は ?
リプライはまだありません。
私の巡回先にははてなブックマーク - 最近の人気エントリーが含まれています。 Bloglines で読んでいるので「巡回」しているとは言い難いかもしれませんがそれはさておき。 そして気になった記事については、それに寄せられたブックマークコメントにも目を通しています。 どういう要約がなされているか気になるからね !
今回気になったコメントははてなブックマーク - 浜崎あゆみとレタッチされるアイドルの時代の id:kurimax さんのもの。
2005年12月08日 kurimax 『[gotanda6]なんで「post_29/ 」なんてURLなんだろ』
この疑問にお答えしようと思うのですが、方法としては犬にかぶらせろ!: 浜崎あゆみとレタッチされるアイドルの時代を自分でもブックマークして id:kurimax さんへのコメントを書くか、あるいははてなブックマーク - 浜崎あゆみとレタッチされるアイドルの時代自体をメタブックマークして id:kurimax さんへのコメントを書くかという方法が考えられますが、自分のところの記事に書くことにします。 それで kurimax さん ( モテゼミ | 「俺」のターン ) に伝わるかどうかは分かりませんが、まあこだわりません。
犬にかぶらせろ!は犬にかぶらせろ!: はてなダイアーでもできるMovable type3.2への移行のススメという記事を書いていることからも分かる通り、 Movable Type 3.2 を使用しているようです。 Movable Type 3.2 ではアーカイブ・マッピング ( 各種アーカイブをどのような URI で生成するかのための規則みたいなものだと思ってください ) をプルダウンメニューから選ぶことができるようになっています。 ( プルダウンメニューから選ぶ以外にも、自分でカスタマイズした規則を用いることもできます。 )
エントリー・アーカイブのプルダウンメニューでは、デフォルトでは
yyyy/mm/entry_basename.html
になっています。
もし犬にかぶらせろ!がこの設定にしていたなら、「浜崎あゆみとレタッチされるアイドルの時代」は
http://mirror-ball.net/2005/12/post_29.html
というパスの記事が作られ、それがそのまま permalink の URI になります。
しかし、実際にはそのような URI にはなっていません。
犬にかぶらせろ!の設定は、おそらく
yyyy/mm/entry_basename/index.html
になっているのでしょう。
これにより、「浜崎あゆみとレタッチされるアイドルの時代」は
http://mirror-ball.net/2005/12/post_29/index.html
というパスの記事が作られ、何らかの処置を行って (?) 実際に permalink として weblog 内に表示される URI は http://mirror-ball.net/2005/12/post_29/ になっています。
gotanda6 さん ( 犬にかぶらせろ! ) が何故 yyyy/mm/entry_basename/index.html というアーカイブ・マッピングを選んでいるか。
それは当然ながら本人でなければ分かりませんが、何故それを選んだかを推測してみようと思います。
yyyy/mm/entry_basename/index.html
をエントリーアーカイブのマッピングに設定して何らかの処置をすると、 weblog 内に表示される URI の末尾は / になり、拡張子は表示されません。
閲覧者側で URI の後ろに index.html なり index.php なり index.shtml なりを手動で付けてもアクセスできるため、完全に拡張子を非表示にするわけではありませんが。
そもそも拡張子を表示することで生じるデメリットが思い当たらないので、理由としては弱いかも。
yyyy/mm/entry_basename.html
よりも
yyyy/mm/entry_basename/index.html
の方が SEO に適しているのではという仮説。
無作為研究所によると、
最近目立つランク上昇傾向としては、/ で終わるURL(サイトINDEXページだけでなく、ディレクトリINDEXページも)である
という傾向が存在するようで、もしこの予測が正しいものであれば
yyyy/mm/entry_basename/index.html
の方が ( post_29.html よりも post_29/ の方が ) SEO 効果が高いと言えるでしょう。
理由としてはそこそこ根拠がありそう。
/ で終わる URI の方が好きだ ! という仮説。 これは本人に聞かない限りは分かりませんが。
実は
yyyy/mm/entry_basename/index.html
に設定したのは失敗だったと思っているという仮説。
全然「何故それを選んだか」という推測になっていないですね。
思いつくのはこれくらいですかねえ。 「こうに違いない ! 」という理由を思い浮かばなかったので、本人によるアナウンスがあるといいなあ。 元々 id:kurimax さんの呟き的なブックマークコメントが発端なので、「本人に直接尋ねればいいじゃん」ってツッコミは無用の方向で。
あと今試してみたんですが、アーカイブ・マッピングを
yyyy/mm/entry_basename/index.html
に設定して再構築しても / で終わる URI にはなりませんでした。
( post_29/index.html のようになる )
何らかのカスタマイズをしているのかなあ。
<$MTEntryPermalink$>
の部分を
<$MTBlogURL$><$MTArchiveDate format="%Y/%m"$><$MTEntryBasename$>/
に置き換えるとか。
リプライはまだ送られていないか、管理者の承認待ち状態です。 この記事に対するご意見やご質問、ご感想などありましたら個別記事ページの送信フォームからお送り下さい。
2005-12-05T23:59+09:00
アンデックス ヴァイスドュンケルを飲みました。
リプライはまだありません。

ドイツのヴァイスドュンケルビール。 「ヴァイス」というのは本来「白い」という意味のドイツ語なのですが、その後に続く「ドュンケル」という言葉は「濃い・暗い」という意味のドイツ語です。 白色と暗色というのは矛盾するのでは ?
しかし、「ヴァイスビール」というのはウィート ( 小麦 ) を原料として作られ、瓶内二次発酵を伴うビールで、中に酵母が残ったままになるために白く濁っているのが特徴です。 それを考えると、ことビールに限って言えば「ヴァイス」は「白い」という意味よりも「濁っている」という意味だと考えられるのかもしれません。 ( 拡大解釈かもしれませんが。 )
なるほど、確かに色としてはダークカラーなのですが、ケストリッツァなどのように透き通ったダークカラーではなく、グラスに注ぐ際にその濁っている様を確認することができます。 アルコール度数は 5.0% とそれほど高くなく、ウィートエールらしい味わいと、ドュンケルの色合いや風味を同時に楽しむことができます。 これは一粒で二度美味しいビールかも。
リプライはまだ送られていないか、管理者の承認待ち状態です。 この記事に対するご意見やご質問、ご感想などありましたら個別記事ページの送信フォームからお送り下さい。
2005-12-05T21:17+09:00
1km 程度のジョギングで足首が痛むのです。その他の運動では何ともないのに。
往復で 6,000 段以上ある石段を昇り降りしたり、季節ごとに山に登ったり、 10kg 弱の荷物を抱えて京都の街を半日に渡って歩いたり、週に 3 回くらい自転車で 30km くらいサイクリングしたり、 200m 全力疾走したりしても何ともないのに、たかだか 1km 、しかも公道ではなくルームランナーで無理のないペースで走ったのにやたらと足首が痛むのは何故でしょうか。
昨年ちょっと通った整骨院にまた通うかなあ……。
2 件のリプライが送られています。 この記事に対するご意見やご質問、ご感想などありましたら個別記事ページの送信フォームからお送り下さい。
多分、往復で 6,000 段以上ある石段を昇り降りしたり、季節ごとに山に登ったり、 10kg 弱の荷物を抱えて京都の街を半日に渡って歩いたり、週に 3 回くらい自転車で 30km くらいサイクリングしたり、 200m 全力疾走したりしたツケが一気に来たんじゃないですか。
いや、本文中では言ってないですけど、元々左足に何かの問題があったんですよ。そして久しぶりに「そろそろ大丈夫だろう」と思ってランニングマシンを使ったら 1km で「やっぱムリ」と。
まあ、ランニング以外の運動でツケが溜まっている可能性も否定できませんが……。
2005-12-04T23:46+09:00
私の不手際であるライブのチケットを余らせてしまうことに。どなたかお付き合いいただける方を募集します。
Tour "A red flower 2005" は、内々で行う計画だったのでその内容を詳しく説明していなかったのですが、ちょっと事情が変わりました。 12 月 24 日というのは JILS というバンドのライブが行われる日であり、このバンドは私と iMa さん ( iMach ) が大ファンであるため、一緒に行きませんか、というお誘いをしていました。
iMach - JILS 6周年記念にてお誘いのことは書かれていますが、どうにもお仕事が忙しいということでライブを一緒に観るというのは無理くさいと。 それなら終わった後で一緒に飲みましょうということにしていました。
しかし、このライブは 2 部構成で、 2 部の開始は 24:00 。 それなら 2 部からなら一緒に楽しめるんじゃないかということで、当日ライブに同行する友人に頼んで 2 部のチケットだけ注文してもらっていたのです。 何故ならチケットの注文は 1 人あたり 2 枚までで、自分の注文分は自分と友人の 2 枚に駆使しており、 iMa さん達の分まで注文することは不可能。 そして 2 部にお誘いするのはある種のサプライズ的なことで計画していたので、まさか iMa さん自身に「チケ取っとってー ( 方言 ) 」とも言えないので友人に注文してもらったという。
しかし、本日 iMa さんから 24 ~ 25 日自体に急用が入ったとの連絡が入り、どうしようと思ったわけです。 急用ならばしょうがないし、だいいち私が黙ってかつ勝手にチケットを確保していたので iMa さんには瑕疵はありません。 しかしこのままではチケットが余ってしまうのも事実。 うーむ。
それなら JILS を知ってそうな知り合いを誘えばいいじゃないかという展開になるわけですが、私にぽんっと思いつかれた方々からすれば寝耳に水なお話。 101 さん ( zerosp.com | すぴりっつおぶぜろ ) は JILS の CD を買っていたので知っているのは確定。 ミユキさん ( Namamono ? Diary ) は知っているかどうか分からないけど、ボーカルの幸也さんと Laputa って親交深かったから名前くらいは知ってそう ! という見通し。
ただ、お二人とも東京の方ではないので気軽に「一緒に行きませんか」というのも気が引けるし、そもそも 1 部のチケットは押さえていないし、何より 2 部のチケットも本当に押さえられているかどうかは
公演日の約1週間前までに配達記録郵便で発送開始
されるチケットが届かないと確実には分からないし、だいいち 12 月 24 日に予定空けてくれって言って空けられるかというのが難しい。
12 月 24 日の 24:00 から 25 日未明まで予定が空いていて、なおかつ新宿に出てこられる方で、 JILS のことを知っていて、「しょうがねえなあ真琴って奴は、よっしゃちょっくら付き合ってやるか」っていう方は makoto[at]hxxk.jp まで ( [at] を @ に変更してください ) メールを下さるかこの記事のコメント欄に書くかしていただけるとありがたいです。 旅費や宿泊費までは難しいですが、チケット代はこちらで持ちますゆえ。
場合によっては自分のポリシー ( SNS は使わない ) を曲げて mixi あたりのコミュニティにてチケットを欲しがっている人を探すかも。
それと、勝手に話を進めていてすみませんでした> iMa さん 次がいつになるか分かりませんが、この埋め合わせは必ずッ……!
とりあえず、事前のチケットのやりとりはしないことにしました。 ( チケットが届きました。 ) 自分で購入した分で、友人の分まで含めて 1 部・ 2 部ともに入場はできるので、余った分は会場に持参して、そこでチケットを求めている方がいれば定価ないしそれ以下の値段でお譲りしようかなと考えています。
5 件のリプライが送られています。 この記事に対するご意見やご質問、ご感想などありましたら個別記事ページの送信フォームからお送り下さい。
チケ取っとってくれたとですか・・・。ほんとすいません。&無念。 あ、ポリシー曲げてmixiに投げるくらいなら自分がやってもかまいませんので。その際は一報下さい。 >次がいつになるか分かりませんが、この埋め合わせは必ずッ……! いやむしろ俺の方こそですがな。
まあ、チケットはこちらが勝手に画策していたものですからねえ、どうにかします。
今の JILS の勢いが分からんので、チケットがソールドアウトになるかも不明ですし、仮にソールドになっていれば後から買い注文した 2 部× 2 枚の方は選から漏れることもあるわけで、なかなかハラハラドキドキものです。
当日までチケットが宙ぶらりんになった時は会場付近でナn
まあ、これからも遊びには積極的に向かっていくので、近いうちにまたお会いしましょう。
JILS好きだから近場だったらぜひ行きたかったんですけどねー。
12/24と言えば私の愛するValentine D.C.が1日だけの復活ライブを東京でやるんですよ。
チケット即完ですが・・・。
行きたいライブって東京ばっかなんですよね(T_T)
JILS 知ってますよー。…とは言っても、バンドとメンバーのお名前だけなんですが…… ( 汗 ) 幸也さんの前のバンド ( D≒SIRE でしたっけ…違ったらごめんなさい ) の CD はいくつか持ってますです、はい。 金銭面の問題と、曲を知らないという致命的な問題ゆえ、興味はあるけど行けないですねぇ。時間だけはあるのに ( 笑 ) 101 さんと同じように近場だったら今から予習しまくって行くんだけど…
>101 さん
やはり距離がネックですよねえ。更にライブ本編はチケット取ってないので尚更ネックに !
Valentine D.C. が限定復活ですか、それは凄い。
>ミユキさん
D≒SIRE 来た ! イイヨイイヨー。
まあ、 2 部の方はライブよりもパーティみたいなものだそうですので、曲を知っている知っていないはそう関係ないかも。メンバーがシェイカー振ってカクテル作ってくれるとか、そういったものらしいです。
まあ急なお誘いでしたし、また何らかの機会があればお誘い申し上げます。>お二方
2005-12-04T19:16+09:00
複数人での weblog について考察するという内容を書きつつも、「 Movable Type のライセンス料金は高いよ ! 」という結論に帰結してしまった記事。
おさんぽさんぽ - ココログが使いにくくなったにて
セカンドライター制を入れているので、プロプランしか選択肢がないのですよ。
これが、他の無料Blogに移転できない最も大きな理由。
んでレンタルサーバでMovableType無料版などに移行できないのもこれが大きい。
と書かれていますが、確かに複数人で投稿できる weblog サービスというのはあまり多くないように思えますね。
というか私は weblog サービスに詳しくないため、複数人で投稿できるものがあるのかどうかすら分かりません。
( はてなグループ はひとつの weblog を複数人で投稿するものではないのでちょっと違うかと。 )
weblog ツールの方では ARTIFACT -人工事実- | Weblogツールリスト(サーバー動作タイプ)に情報が集められていますが、次に挙げるツールが複数人での投稿ができるようです。
私が知っている限りの複数人投稿の weblog をまとめてみます。
Movable Type を使用。
ネタフルには複数のbloggerがいます
という記述や、
おっと、ネタフルでは複数のauthorがいるのでライセンスを購入しなくてはなりませんね
という記述から、複数人で投稿していることが分かります。
ユーザー数無制限で対応できそうです。 ある意味、それで12,000円だったら安い気がします。 喜んで購入させて頂きます。
それって個人ライセンスなので、複数人投稿はできないライセンスなのですが……記述自体が 1 年以上前なので、今は正しいライセンスを購入しているかもしれません。
Movable Type を使用。 11 人の現在進行形な Author 、 3 人の終了した Author 、ゲストアカウントと、総勢 15 アカウントの豪華 weblog 。 サークルと呼んでいいのか分かりませんが、サークル的な利用を行っている好例だと言えるでしょう。
つい先日NewsHandler から Moavble Type に移行した weblog 。 3 人の投稿者で weblog を構築しているようです。
blosxom を使用。
某ブラウザやらなんやらの擬人化美少女をテーマにした萌える同人誌を作ろうじゃありませんかというプロジェクト
の制作状況を報じる weblog です。
現時点では 8 人の投稿者を確認できました。
Movable Type を使用。 blosxom.org なのに Movable Type かよ ! という理由は blosxom.org が MT な理由: blog.bulknews.net で書かれています。 現時点では 3 人の投稿者を確認できました。
前述の blosxom.org が MT な理由: blog.bulknews.net にて blosxom を使った複数人投稿の実例として出された weblog 。 現時点では 2 人の投稿者を確認できました。
他の weblog ツールをよく知らないので比較はできませんが、 Movable Type は複数人投稿を容易に行えるツールだと思います。 ユーザごとに権限を設定することができますし、同一の weblog を複数のユーザで扱うことができるため、柔軟な運営が行えるというのが大きな利点だと思います。
難点と言えば、複数人投稿を行う場合のライセンス料金が高いこと。 Crossing Fingers/クロッシングフィンガーズや blosxom.org のように 3 人の投稿者であれば 26,250 円 ( ダウンロードライセンスの場合の価格。ライセンスパックの場合は 31,500 円。 ) のライセンス料金で済みます。 ( それでもそれなりの額ではありますが。 )
自転車を徹底的に意識する: power's cycle diary のような大所帯になるとライセンスパックの 1 サーバー・ 5 ユーザー ( 31,500 円 ) + 追加 10 ユーザー ( 47,250 円 ) で 78,750 円という高額なライセンス料金に !
実は hxxk.jp ではない別のサイトにて複数人投稿の weblog を作ろうかなと考えていたことがあったのですが、このライセンス料金がネックになって止めた経緯があります。 ( どちらにしても別のサーバになるため、個人ライセンスの 5 ユーザー版を購入しました。 )
ライセンス料金がかからない weblog ツールを使うのはどうでしょう。 Movable Type はライセンス料金が高いので、 Serene Bach や blosxom あたりで。
6 件のリプライが送られています。 この記事に対するご意見やご質問、ご感想などありましたら個別記事ページの送信フォームからお送り下さい。
はてなダイアリーも、有料オプションをつければ複数人で投稿することができます(自分の他に編集できる id を指定する方式)。ただし、投稿者名が表示されないので、投稿者を明記したい場合は運用でカバーしないといけないのですが。
月額 180 ポイント ( 180 円 ) というのはリーズナブルですねえ。私の場合は独自ドメイン上でやりたいのでちょっとニーズが合いませんが、手軽に複数人で書きたいって場合に良いかも。
こんにちは。
ちょうど複数人でblogをやるかもしれないという話が出てとてもタイムリーな話題で参考になりました。
ありがとうございます。
でもMTはライセンス料ホントに高いですね…
もう少しリーズナブルなら使い慣れたMTでやりたいところなのですが…
こんばんは。私も今でも別のサイトで Movable Type を複数人で使おうかどうか検討中です。
やはり自分なりにノウハウを溜めているので、それを利活用したくなりますよね。
非商用専用の安価なサークルライセンスとか新設されればいいんですけど。
livedoor や seesaa なら複数人投稿も無料ですよ。他にも無料で複数人投稿に対応しているサービスがあるそうです。 http://blog.alamode.tv/blog_multi.html ちなみに livedoorPro では独自ドメインに対応。月額262円なので、MTと比較して、かなり安いのではないでしょうか。 非営利ユーザなら無料で使える高機能ブログツールではBlognPlusが有名でしょうか。sb や RingBlog もよいと思います。
レンタル weblog でも複数人投稿ができるものはあったのですね。最初から「レンタルだから複数人は不可だろう」と決め付けていた節があり、深く調べようとは思いませんでした。
LivedoorPro は独自ドメインかあ……。構造などにこだわらなければ選択肢に入れてもいいかもしれません。どうもありがとうございました。
2005-12-04T15:32+09:00
個別記事に指定できる ( または自動で生成される ) 「エントリー・ファイル名」 (entry_basename) は記事の Export では書き出されない上に、デフォルトのアーカイブ・マッピングではその entry_basename が用いられるために、 Export によって失われてしまうことになります。
MTEntryBasename は Export で書き出されないにて
記事に指定できる「エントリー・ファイル名」というのは entry_basename フィールドのことなのですが、この entry_basename は書き出しの項目には含まれていません
と書き、
ちょっとサポートに問い合わせてみます
と書いていましたが、その返答がきました。
まず確認として、現状の Movable Type の機能では entry_basename フィールドの内容が書き出されないというのは間違いないとのことで、今後の対応予定については明言されませんでした。 将来のバージョンアップ時の要望として受け取ったという旨が書かれてはいましたが、そう書かれるということは、これまで検討されたことはなかったいうことではないでしょうか。
記事の Import/Export を行う予定がある人は、当面の間は MTEntryBasename をアーカイブ・マッピングに用いない方が良いようです。 とはいえ、 Movable Type 3.01D-ja の頃からデフォルトの個別記事の Permalink は MTEntryBasename が用いられたわけで、そのデフォルトの Permalink が Import/Export によって失われるというのは大きなマイナスではないでしょうか。
MTEntryBasename を用いている Web Standards with MT ver.3.2 Strict をテスト対象にして、記事の Export をして、新規に作ったテスト weblog に Import してみました。 それによって MTEntryBasename がどう変わったかを調べてみました。
| 記事タイトル | Web Standards with MT ver.3.2 Strict | テスト weblog |
|---|---|---|
| Changelog - ver.1.01 to 1.02 | changelog_ver101_to_102 | |
| Changelog - ver.1.00 to 1.01 | changelog_ver100_to_101 | |
| ダウンロードページ | download | post_3 |
| リファレンス | reference | post_2 |
| メニュー部分が配置されていないテンプレート | no_menu_templates | post_1 |
| Changelog - 20051025-01 | changelog_2005102501 | |
| Changelog - 20051017-01 | changelog_2005101701 | |
| 各テンプレートのセクション一覧 ver.1.02 | template_section_list_1_02 | _ver102_1 |
| 各テンプレートの見出し一覧 ver.1.02 | template_heading_element_list_1_02 | _ver102 |
| Changelog - 20051015-01 | changelog_2005101501 | |
| Changelog - 20051014-01 | changelog_2005101401 | |
| 各テンプレートのセクション一覧 ver.1.01 | template_section_list_1_01 | _ver101_1 |
| 各テンプレートの見出し一覧 ver.1.01 | template_heading_element_list_1_01 | _ver101 |
| この構造やマークアップが変だよ、などのご意見はこの記事へ。 | please_point_out | post |
| 各テンプレートのセクション一覧 ver.1.00 | template_section_list_1_00 | _ver100_1 |
| 各テンプレートの見出し一覧 ver.1.00 | template_heading_element_list_1_00 | _ver100 |
| テスト記事 01 | test_01 | _01 |
いくつかの記事では「エントリー・ファイル名」を自分で指定していないものもあるので、それについては MTEntryBasename は変更されていませんが、自分で指定していたものはことごとく変わっています。 Movable Type 3.1x までは「エントリー・ファイル名」を変更することはできなかったので、 Export しても変更されてしまうことはなかったのですが、 Movable Type 3.2x では「エントリー・ファイル名」を容易に変更できるので、ハマってしまうユーザも多くなるかも。
どれかひとつでも条件が満たされなければ問題は発生しませんが、 Movable Type 3.2x ではデフォルトで個別記事の「アーカイブ・マッピング」に entrybasename を使うために、意外とすんなりと条件が満たされてしまいます。
サポートには要望として受け入れてもらえましたが、対応予定のバージョンなどは明言されませんでした。
5 件のリプライが送られています。 この記事に対するご意見やご質問、ご感想などありましたら個別記事ページの送信フォームからお送り下さい。
わざわざ問い合わせして頂いてありがとうございました。
やはり6Aでは気づいていなかったというかエキスポートまでは検証されていなかったのでしょうね。。。
せっかくMTEntryBasenameにしたんですけど、元のkeywordをファイル名戻そうかなと思っちゃいます。
entry_basename はこれまでは変更不可でしたからねえ、 Export の項目に含まれなくても問題は無かったのでしょう。 ( entry_title から生成するため )
SEO を心がける人は、「エントリー・ファイル名」にも気を遣うと思うので、この罠に引っかかる人は後から顕在化してくるかも。
一応、この問題には解決策があります。ファイル名をMTEntryBasenameにしている方のほとんどは、全ての入力可能項目を埋めてはいないはずなので、下記リンク先に記載の方法が使えます。
http://enjolras.s101.xrea.com/blog/archives/mt/0504/141251.html
なるほど、書き出し機能ではなくて、書き出しのためのテンプレートを作成するのですか !
これは盲点でした。正式にサポートされるまでは、この方法が良さそうですね。
2005-12-03T18:13+09:00
はてなブックマークに description を取得してもらうために、 content:encoded を含まず、 FeedBurner を使わず、最新記事ではなくその記事ごとのサマリを提供する Feed を作りました。
はてなブックマークと <$MTEntryExcerpt$> やはてなブックマークと dc:description やはてなブックマークと RSS Auto-Discovery 、および Lucky bag::blog: はてなブックマークに概要が反映されなくなったなどで話題になっているっていうか自ら話題にしたはてなブックマークの概要取得についてですが、その処理がどのように行われているかを naoya さん ( naoyaのはてなダイアリー ) が直々に発表してくださいました。
処理の流れですが、
- 該当エントリーに Feed Auto-Discovery を実行する
- その中で最初に見つかった Feed (link タグで一番上にあるもの) を GET する
- Feed を parse して、ブックマークされた URI を link 要素にもつ要素を探す
- その要素に content 部分 (RSS 1.0 なら content:encoded、Atom なら content) があればそれを取得、なければ description を取得
という感じになっています。 このいずれかの流れでその取得に失敗した場合は、HTML コンテンツの中からそれっぽい部分を取得する、という感じになっています。
とのこと。
それなら、各記事のサマリだけを提供するような RSS ( 当然ながら content:encoded を含まないもの ) を記事ごとに
rel="alternate"
で提供すれば description を取得してくれるのでは !
と考えました。
その考えは naoya さん自身も記事中で
Permalink URI の中にはもう一つ別種類の、そのエントリーだけが格納されているフィードを探す Auto-Discovery な手段があるといいなと思いました。
はてなダイアリーみたいなフルに動的なコンテンツ管理ツールだと実装は結構簡単です。 Movable Type のような静的ファイルを作るものも、各エントリーごとにもう一つファイル(フィード)をはき出すようにして、一度全部 Rebuild してやれば ok だと思います。
と書いていますし、 nulog > 2005 > 12 > 03 - for Hatena::Bookmark でも
個別ページの alternate を設定して、個別ページ用の XSLT を書いといた。
という方法が提唱されていますので、間違ってはいないと思います。
けど微妙にうまくいってない気がする
と書かれているのが気になりますが。
ということで、個別記事のサマリを提供する Feed のテンプレートを作ってみました。
<?xml version="1.0" encoding="<$MTPublishCharset$>"?>
<rdf:RDF
xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"
xmlns:dc="http://purl.org/dc/elements/1.1/"
xmlns:content="http://purl.org/rss/1.0/modules/content/"
xmlns:sy="http://purl.org/rss/1.0/modules/syndication/"
xmlns:admin="http://webns.net/mvcb/"
xmlns:cc="http://web.resource.org/cc/"
xmlns="http://purl.org/rss/1.0/">
<channel rdf:about="<$MTEntryPermalink$>">
<title><$MTBlogName encode_xml="1"$></title>
<link><$MTEntryPermalink$></link>
<description><$MTBlogDescription remove_html="1" encode_xml="1"$></description>
<dc:language><$MTDefaultLanguage$></dc:language>
<dc:creator><$MTEntryAuthor encode_xml="1"$></dc:creator>
<dc:date><$MTEntryDate format="%Y-%m-%dT%H:%M:%S" language="en"$><$MTBlogTimezone$></dc:date>
<admin:generatorAgent rdf:resource="http://www.movabletype.org/?v=<$MTVersion$>" />
<MTBlogIfCCLicense>
<cc:license rdf:resource="<$MTBlogCCLicenseURL$>" />
</MTBlogIfCCLicense>
<items>
<rdf:Seq>
<rdf:li rdf:resource="<$MTEntryPermalink$>" />
</rdf:Seq>
</items>
</channel>
<item rdf:about="<$MTEntryPermalink$>">
<title><$MTEntryTitle encode_xml="1"$></title>
<link><$MTEntryPermalink$></link>
<description><$MTEntryExcerpt encode_xml="1"$></description>
<MTEntryTags case_sensitive="1">
<dc:subject><$MTTag encode_xml="1"$></dc:subject>
</MTEntryTags>
<dc:creator><$MTEntryAuthor encode_xml="1"$></dc:creator>
<dc:date><$MTEntryDate format="%Y-%m-%dT%H:%M:%S" language="en"$><$MTBlogTimezone$></dc:date>
<trackback:ping rdf:resource="<$MTEntryTrackbackLink$>" />
</item>
</rdf:RDF>
これを通常の Permalink の URI の末尾に _summary.rdf が付くようにアーカイブ・マッピングを設定して、かつ Individual Entry Archive にて、最新記事の情報を含む Feed を読み込む行より上にこの Feed を読み込むように書き換えて個別記事を再構築。
ちなみに、
<MTEntryTags case_sensitive="1">
から
</MTEntryTags>
までの部分は Tagwire Plugin を使用している前提での記述なので、 Tagwire Plugin を使用していない場合は
<dc:subject><$MTEntryCategory encode_xml="1"$></dc:subject>
と書き換えてください。
再構築作業の後に投稿したビール日記 2005/12/01 - 金しゃち名古屋赤味噌ラガーという記事をブックマークしてみましたが、
の限定品赤味噌ラガービール。
アルコール度数は 6.0% と決して高くはないのですが、ハイアルコールビールのように泡がほとんど立ちません。
色は暗い赤褐色で、スタウトに似た感じ。
で、飲むと本当に味噌の味わいがあります。
しかしこれはこれで楽しく飲めました。 ちょっと苦みが強いので万人におすすめできるものではありませんが。
のように、やはりヒューリスティクスなサマリになっています、うーむ。
とりあえず検証結果だけは得られたので、ここで一旦締めて近所の寄り合いの忘年会に行ってきます。
個別記事ごとに、その記事のサマリだけを提供する Feed のテンプレートを作成してみました。 hxxk.jp ではうまく description を取得してくれませんでしたが……。
個別記事ごとに、その記事のサマリだけを提供する Feed を提供してみましたが、やはりヒューリスティクスなサマリになっています。
nulog の手法に倣って個別の Feed を提供してみましたが、こちらもうまくいきませんでした。
4 件のリプライが送られています。 この記事に対するご意見やご質問、ご感想などありましたら個別記事ページの送信フォームからお送り下さい。
Serene Bach で作成した記事が はてなブックマーク に登録された際に、本文の一部ではなく記事の概要を取得してもらう方法。
Serene Bach で作成した記事が はてなブックマーク に登録された際に、本文の一部ではなく記事の概要を取得してもらう方法。
すみません、トラックバックが2重になってしまいました。お手数ですが一方の削除をお願い致します。
それと、こちらの記事を参考にさせて頂いたおかげで、Serene Bach でも はてブ に概要を提供することができました。ありがとうございます。
トラックバックについては対処しました、ご報告ありがとうございます。
ところで、このはてなブックマークに概要を提供する手法ですが、 http://www.akatsukinishisu.net/itazuragaki/xml/metadata_of_entry.html のような話もあるので、もう少し考えを整理しようと思っていました。もしかしたらまた違う手法や考え方を再度書くかもしれません。
2005-12-03T17:33+09:00
金しゃち名古屋赤味噌ラガーを飲みました。
リプライはまだありません。

名古屋の地ビールブルワリー、ランドビールの限定品赤味噌ラガービール。 アルコール度数は 6.0% と決して高くはないのですが、ハイアルコールビールのように泡がほとんど立ちません。 色は暗い赤褐色で、スタウトに似た感じ。 で、飲むと本当に味噌の味わいがあります。 しかしこれはこれで楽しく飲めました。 ちょっと苦みが強いので万人におすすめできるものではありませんが。
ちなみに "2005 Autumn Kyoto" にてにゃおりん ( 回顧録? ) から手土産としていただいたもの。 私からは釈云麦を手土産に渡しています。
リプライはまだ送られていないか、管理者の承認待ち状態です。 この記事に対するご意見やご質問、ご感想などありましたら個別記事ページの送信フォームからお送り下さい。
※共著
※共著、現在絶版