hxxk.jp - 2005-02 アーカイブ

ある日曜日の気まぐれ

記事データ

投稿者

望月真琴

投稿日時

2005-02-27T19:32+09:00

タグ

概要

独白調日記のテスト。

リプライ

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

記事本文

本来ならば休日であるはずの今日、仕事を終えて帰る途中にふと欲しくなったものがあった。それは 30km ほど離れた隣の隣の町の店にしか無いものだったが、せっかくなので日曜のドライブを洒落込もうと思い、家へと曲がる角をまっすぐに進む。元々気まぐれで起こした行動だったので、途中のルートもいつもと違う角を曲がり進んで行くと、そこにあったこと自体を忘れていた店があった。

そして、気まぐれで思い立った行動は、気まぐれに辿り着いた店で気まぐれに終わりを迎えた。要するに、探していたものはそこにもあったのだ。ここなら、隣の隣の町まで行かずともいいじゃないか。それでも 10km ほどの距離はあるのだが、渋滞でもしていない限りはお気に入りのインストゥルメンタルナンバーを 1 曲聴き終わる頃には着くことができるだろう。

まさにそのインストゥルメンタルナンバーを聴きながら家路に着く途中、曲が Universal Mind の部分になった辺りでふと道路の表示を見て気付く。 ……ああ、そういえば隣の町は、隣の隣の町と一緒になったんだった。新聞やニュースで目にしていた、しかし右から左に聞き流していた事実をふと再認識した。結局は、距離こそ違えどあの町に買い求めに行くという事実には変わりはなかった。

いつもならその距離に少し辟易としていた買い物も、こうした発見があるなら悪くないのかな、と思いつつ買ってきた黒い瓶の栓を開ける――。

リプライ

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

LiVEMARK の機能変更と著作権

記事データ

投稿者

望月真琴

投稿日時

2005-02-27T01:03+09:00

タグ

概要

LiVEMARK のキャッシュ機能ですが、その機能自体が廃止されたようです。廃止に関するアナウンスを見つけることができませんでしたが、高木浩光＠自宅の日記 - とりあえず「キャッシュ」じゃなく「ミラーコピー」と称してくれないかによると廃止となった模様。

リプライ

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

記事本文

LiVEMARK のキャッシュ機能は廃止されました

各種ソーシャルブックマークサービスの転載状況で触れていた LiVEMARK のキャッシュ機能ですが、その機能自体が廃止されたようです。廃止に関するアナウンスを見つけることができませんでしたが、高木浩光＠自宅の日記 - とりあえず「キャッシュ」じゃなく「ミラーコピー」と称してくれないかによると廃止となった模様。

私もあの機能はキャッシュではなくむしろミラーリングだと思っていたので、途中までそれに関する記事を書いていましたが、「高木浩光＠茨城県つくば市の日記」跡地 - 技術用語「cache」が政治的な言葉として拡大利用されるにかなり詳しく書かれていますので、これを参考にすることにして、記事を書くのは中断しました。

著作権の侵害と親告罪

しかしながら、私の著作物については私が侵害とみなさなければよいとも言えます（親告罪）。

以下の条件に従ってくださった場合には、私の著作物（上記のもの）については黙認することにします。（http://livemark.jp/ における使用に関して。）

高木浩光＠自宅の日記 - とりあえず「キャッシュ」じゃなく「ミラーコピー」と称してくれないかに、上記のような文面があります。著作権侵害は親告罪にあたるので、高木浩光さん ( 高木浩光＠自宅の日記 ) が訴えない限り著作権を侵害しても罪に問われないということです。

著作権法に次のように定められています。

第123条第119条、第120条の２第３号及び第４号並びに第121条の２の罪は、告訴がなければ公訴を提起することができない。

２無名又は変名の著作物の発行者は、その著作物に係る前項の罪について告訴をすることができる。ただし、第108条第１項ただし書に規定する場合及び当該告訴が著作者の明示した意思に反する場合は、この限りでない。

要するに、著作権法第 123 条第 1 項の罪について告訴できるのは著作物の発行者であり、その発行者からの告訴が無ければ公訴ができないということです。第三者が告訴をすることはできません。 ( 著作権の侵害ではないか、という指摘はできますが。 )

ただし著作権者の告訴が無ければ公訴が提起されず、罪に問われないというだけであって、著作権者の告訴が無ければ侵害行為にはならないということではないという点に気を付けてください。こういった Web サービスの類によく Google のキャッシュが引き合いに出されますが、単に訴えられていないだけであって、免罪符となるものではないのです。

とは言え

何度も述べますが、私個人ははてなブックマークによる記事本文の掲載についての考察 - と、長々と書いてみたけれどの通り、私の想像の及ばないよほど悪質な例でも出てこない限り、特には転載やミラーリングについて訴えることはありません。しかし、こう考える人間が全てではないため、 hxxk.jp に留まらず、広範囲で行われるものについてはこれからも取り上げていこうと思います。

リプライ

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

2005-02-27T08:30+09:00 - 北村: > 廃止に関するアナウンスこちらで見かけました。 http://livemark.jp/dev/archives/2005/02/deliciousaaaaaa_1.html

2005-02-27T21:42+09:00 - 真琴: 「del.icio.usインポート」までしか目に入っていませんでした……。ちゃんと「&キャッシュ」って書いてありましたね。どうもありがとうございます。

Movable Type 2.x でトラックバックを一括管理するテンプレート

記事データ

投稿者

望月真琴

投稿日時

2005-02-26T22:48+09:00

タグ

概要

Movable Type 2.x は各記事の編集画面からしかコメントやトラックバックを削除できないので、 Recent Reaction template ver.3 を改造して、一括管理するテンプレートを作ってみました。

リプライ

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

記事本文

Movable Type 2.x はトラックバックを一括管理できない

現在トラックバック止めてます - スピリッツオブゼロ@blog

MTのVersionを3にあげればメニュー画面からでも簡単に削除できるのかなぁ。

そうそう、 Movable Type 2.x は各記事の編集画面からしかコメントやトラックバックを削除できないんですよね。いやあ不便でした。 ( 昔を懐かしむな )

で、疑問にお答えすると、 Movable Type 3.x だとコメントやトラックバックの一括管理ができます。

チェックボックスにチェックを入れて、一括でトラックバックを削除することができます。
トラックバック元の記事への直接リンクが作成されます。 ( mt.cgi のファイル名がリファラに残るので、そこからリンクを辿るのはお薦めしませんが。その理由は Movable Type における CSRF の可能性と各種対処法 - 管理画面のトラックバックのリンクアンカーを絶対にクリックしないを参照してください。 )
トラックバックのフィルタリングが可能です。フィルタリングの種類は
- タイトル ( title )
- 送信元 ( blog_name )
- 概要 ( excerpt )
- ip
の 4 つです。

Movable Type 2.x でトラックバックを一括管理する

管理画面から管理できないのなら、管理するテンプレートを作ってしまえばいいのです。 Recent Reaction template ver.3 で記事ごとにトラックバックをまとめるテンプレートを作成しましたので、それを元にしたテンプレートを作ることで、管理を効率よく行うことができます。必要なプラグインやソースコードの解説は Recent Reaction template ver.3 を参照してください。

ただし、次項で提示するテンプレートを利用する場合は、 Movable Type における CSRF の可能性と各種対処法 - weblog 内に mt.cgi へのリンクアンカーを作成しないをよく読んだ上で利用してください。具体的な対策としては、「テンプレートの出力ファイルを BASIC 認証をかけたディレクトリ内に作るか、出力ファイル自体に BASIC 認証をかけるようにする」、または「自分にしか見えない [編集] リンクを作る | alectrope を参考にして cookie の判別を行うようにする」などの対策が考えられます。逆に、これらの対策を採らない、もしくは採ることができない場合は次項のテンプレートから Edit 周りの記述を削除してください。

トラックバック管理テンプレート

<?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" xml:lang="ja" lang="ja">

<head>
  <meta http-equiv="Content-type" content="text/html;charset=<$MTPublishCharset$>" />
  <title><$MTBlogName$> - トラックバック管理</title>
</head>

<body>

<h1><$MTBlogName$> - トラックバック管理</h1>
  
  <dl>
    <MTEntries recently_pinged_on="1000">
      <dt>
        <a href="<$MTEntryLink$>"><$MTEntryTitle$></a>
        <!--[ <a href="<$MTCGIPath$>mt.cgi?__mode=view&#38;_type=entry&#38;id=<$MTEntryID$>&#38;blog_id=<$MTBlogID$>">Edit</a> ]-->
        <!-- http://hxxk.jp/2005/05/13/2105#sub-20050513-15 の対策を採ることができる場合のみこの Edit リンクのコメントを外す -->
      </dt>
      <dd>
        <ol>
          <MTPings lastn="1000">
            <li><a href="<$MTEntryLink$>#p<$MTPingID$>"><$MTPingDate format="%Y/%m/%d %H:%M"$></a> : <a href="<$MTPingURL$>" rel="nofollow"><$MTPingBlogName$> - <$MTPingTitle$></a></li>
          </MTPings>
        </ol>
      </dd>
    </MTEntries>
  </dl>
  
  <p>
  Powered by <a href="http://www.movabletype.org">Movable Type <$MTVersion$></a>
  </p>

</body>

</html>

補足

Movable Type 2.661 でも recently_pinged_on Plugin は動作するようです。 xrea サーバにインストールした Movable Type 2.661 では確認できました。

なお、今回はトラックバックに限定していますが、コメントも同様に管理することができます。適宜ソースコードは改変してください。

トラックバック送信先

リプライ

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

2005-05-15T15:06+09:00 - スト印メンテ：TB spam対策 < スト印: 　メールをチェックしてると、来ました来ましたスト印へ大量のspam投稿メールがヽ(;´Д｀)ﾉと、よく見たら今回はコメントspamではなくてトラックバックs...

2006-10-01T15:40+09:00 - トラックバックスパム < riemagu log: 最近ひどい…ので、対策を施してみた。うまくいくかな？参照：BiancaのTrackBackSpam対策【トラックバックスパム対策】それからこれまでのト...

Recent Reaction template ver.3

記事データ

投稿者

望月真琴

投稿日時

2005-02-26T20:58+09:00

タグ

概要

Recent Reaction template ver.2 とほぼ同じテンプレートですが、使用するプラグインを別の物に変えることでテンプレートの記述を簡潔にしました。

リプライ

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

記事本文

Recent Reaction template ver.3 の概要

Recent Reaction template ver.2 とほぼ同じテンプレートですが、使用するプラグインを別の物に変えることでテンプレートの記述を簡潔にしました。

recently_pinged_on Plugin
必須プラグイン
テンプレートの作成手順
テンプレートの記述例
サンプル
Recent Comments の解説
Recent Trackbacks の解説
活用例
関連リソース
トラックバック送信先

recently_pinged_on Plugin

Ogawa::Memoranda: recently_pinged_on Plugin

この際なので随分前に作ったMTEntriesコンテナにrecently_pinged_onというオプションを追加するプラグインも公開しておきます。 recently_commented_onと同様に下のような感じで使えます。

recently_commented_on のトラックバックバージョンだと考えて差し支えありません。トラックバックを受信した順に記事を並べ、記事ごとにトラックバックを羅列します。

必須プラグイン

Ogawa::Memoranda: recently_pinged_on Plugin

これ以外のプラグインは特に必要ありません。解説は前項と同じなので省略します。

テンプレートの作成手順

スクリーンショットは使い回しですので、ファイル名などの細かい部分が違いますが、大した問題じゃないのでそのままにしています。適宜読み替えてください。

テンプレートをクリックします。
新しいインデックス・テンプレートを作るをクリックします。
テンプレートの名前を Recent Reaction template ver.3 にし、出力ファイル名を recent_reaction_3.html にしてください。 ( これらは一例です。お好きな名前にしていただいて構いません。また、 Movable Type の使用環境に合わせて、拡張子を適宜 .html や .shtml や .php に変更してください。 ) インデックス・テンプレートを再構築するときにこのテンプレートを自動的に再構築するにチェックを入れてください。
テンプレートの中身をテンプレートの記述例を参考にして記述します。
保存をクリックします。
このテンプレートを再構築するをクリックして完成。

テンプレートの記述例

最低限の要素と、該当部分だけを記述しています。スタイルシートやナビゲーションなどは各自追加してください。

<?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" xml:lang="ja" lang="ja">

<head>
  <meta http-equiv="Content-type" content="text/html;charset=<$MTPublishCharset$>" />
  <title><$MTBlogName$> - Recent Reaction ver.3</title>
</head>

<body>

  <h1><$MTBlogName$> - Recent Reaction ver.3</h1>
  
  <h2>Recent Comments</h2>
  
  <dl>
    <MTEntries recently_commented_on="1000">
      <dt><a href="<$MTEntryLink$>"><$MTEntryTitle$></a></dt>
      <dd>
        <ol>
          <MTComments sort_order="descend">
            <li>c<$MTCommentID$> - <a href="<MTCommentEntry><$MTEntryLink$></MTCommentEntry>#c<$MTCommentID$>"><$MTCommentDate format="%Y/%m/%d %H:%M"$></a> : <$MTCommentAuthor$></li>
          </MTComments>
        </ol>
      </dd>
    </MTEntries>
  </dl>
  
  <h2>Recent Trackbacks</h2>
  
  <dl>
    <MTEntries recently_pinged_on="1000">
      <dt><a href="<$MTEntryLink$>"><$MTEntryTitle$></a></dt>
      <dd>
        <ol>
          <MTPings lastn="1000">
            <li>p<$MTPingID$> - <a href="<$MTEntryLink$>#p<$MTPingID$>"><$MTPingDate format="%Y/%m/%d %H:%M"$></a> : <a href="<$MTPingURL encode_xml="1"$>" rel="nofollow"><$MTPingBlogName$> - <$MTPingTitle$></a></li>
          </MTPings>
        </ol>
      </dd>
    </MTEntries>
  </dl>
  
  <p>
  Powered by <a href="http://www.movabletype.org">Movable Type <$MTVersion$></a>
  </p>

</body>

</html>

サンプル

hxxk.jp - Recent Reaction ver.3

これはサンプルなので、 2005-02-26T20:30:48+09:00 時点のコメントやトラックバックで作成しており、自動での再構築はしないようにしています。必ずしも最新のコメントが反映されているとは限りません。

Recent Trackbacks の解説

基本的には Ogawa::Memoranda: recently_pinged_on Plugin の記述を参考にしています。ただ、あちらの記述では dt 要素に対して dd 要素を複数並べているのに対し、一つの記事に対するトラックバックは一つの dd 要素にまとめ、その中で ol 要素を使って羅列しています。

サンプルでは <MTEntries recently_pinged_on="1000"> および <MTPings lastn="1000"> のように指定していますが、これはトラックバックが送信された記事を最大 1000 件表示し、さらに記事ごとに最大 1000 件のトラックバックを表示するという結果を得ることができます。サイドバーなどに用いる場合は適宜この値を減らしてください。ちなみに、 <MTPings lastn="n"> の値をあまり小さくすると、多くのトラックバックが寄せられる記事の場合は古いトラックバックは表示されなくなることがあります。

活用例

独立したテンプレートとして使用するのでなく、ソースの一部分を各種テンプレートに組み込み
コメントやトラックバックの管理に

トラックバック送信先

リプライ

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

各種 iPod シリーズの比較表

記事データ

投稿者

望月真琴

投稿日時

2005-02-25T21:47+09:00

タグ

概要

前回は iPod mini のみの新旧比較表でしたが、せっかくなので全ラインナップの新旧比較表を作ってみました。

リプライ

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

記事本文

ついでに。

clippingグループ - ::memo:: type-R - iPod mini の新モデル (旧モデルと新モデルを比較してみる)

旧モデルと新モデルの仕様比較表。 iPod に限らず、 Apple のサイトは新モデルが出ると旧モデルの情報が一切なくなってしまうので困る。

新モデルが出たので自分の旧モデルと比較してみようと思っても、ままならないんですよね。旧モデルのスペックの記述を消去するんじゃなく、どこかに移動させるという方法は取れないものでしょうか……。

せっかくだから、 iPod mini 以外のものも比較しておこうと思います。他機種の動向も掴んでおいた方が何かと (?) 便利ですし。

なお、 iPod と iPod shuffle と iPod U2 Special Edition は新モデルが登場したわけではありませんが、スペック表に細かい差異があったので記載しておきます。

新旧モデル比較 - iPod
新旧モデル比較 - iPod mini
新旧モデル比較 - iPod photo
新旧モデル比較 - iPod shuffle
新旧モデル比較 - iPod U2 Special Edition

新旧モデル比較 - iPod

	旧モデル 20GB	旧モデル 40GB	現行モデル
価格	33,390 円	44,940 円	32,800 円
カラーバリエーション	ホワイト
容量	20GB	40GB	20GB
バッテリー駆動時間	最長 12 時間
ディスプレイ	2 インチ ( 対角 ) グレイスケール LCD 、 LED バックライト付き
本体入出力ポート	Dock コネクタワイヤードリモコン用コネクタステレオヘッドフォンジャック
接続方法	FireWire 400 USB 2.0 ( Dock コネクタ経由 )		USB 2.0 FireWire 400 ( 別売りのケーブル使用時 ) Dock コネクタ経由
充電時間	約 4 時間 ( 2 時間でバッテリー容量の 80% を高速充電 )
オーディオフォーマット	AAC ( 16 〜 320Kbps ) MP3 ( 32 〜 320Kbps ) MP3 VBR Apple lossless WAV AIFF Audible	AAC ( 16 〜 320Kbps ) プロテクト付き AAC ( iTunes ミュージックストアから購入 ) MP3 ( 32 〜 320Kbps ) MP3 VBR Audible ( フォーマット 2、3、4 ) Apple lossless WAV AIFF
サイズ	104.1x60.9x14.5mm	104.1x60.9x17.5mm	104.1x60.9x14.5mm
重量	158g	176g	158g
付属ソフトウェア	iTunes for Mac iTunes for Windows
付属アクセサリ	インナーイヤー型ヘッドフォン AC アダプタ FireWire ケーブル USB 2.0 ケーブル	インナーイヤー型ヘッドフォン AC アダプタ FireWire ケーブル USB 2.0 ケーブル Dock	インナーイヤー型ヘッドフォン AC アダプタ FireWire ケーブル USB 2.0 ケーブル

iPod は新モデルが登場していませんが、便宜上「旧モデル / 現行モデル」と記述させていただきました。 40GB モデルが無くなって 20GB モデルのみとなり、価格が僅かに安くなっているようです。

表中では FireWire 400 ( 別売りのケーブル使用時 ) と書かれていますが、 FireWire ケーブルは付属アクセサリに含まれているので、おそらく記述ミスだと思います。

新旧モデル比較 - iPod mini

	旧モデル	新モデル 4GB	新モデル 6GB
価格	28,140 円	21,800 円	27,800 円
カラーバリエーション	シルバーゴールドブルーピンクグリーン	シルバーブルーピンクグリーン
容量	4GB		6GB
バッテリー駆動時間	最長 8 時間	最長 18 時間
ディスプレイ	1.67 インチ ( 対角 ) グレイスケール LCD 、 LED バックライト付き
本体入出力ポート	Dock コネクタワイヤードリモコン用コネクタステレオヘッドフォンジャック
接続方法	FireWire 400 USB 2.0 ( Dock コネクタ経由 )	USB 2.0 FireWire 400 ( 別売りのケーブル使用時) Dock コネクタ経由
充電時間	約 4 時間 ( 1 時間でバッテリー容量の 80% を高速充電 )	約 4 時間 ( 2 時間でバッテリー容量の 80% を高速充電 )
オーディオフォーマット	AAC ( 16 〜 320Kbps ) MP3 ( 32 〜 320Kbps ) MP3 VBR Apple lossless WAV AIFF Audible	AAC ( 16 〜 320Kbps ) プロテクト付き AAC ( iTunes ミュージックストアから購入 ) MP3 ( 32 〜 320Kbps ) MP3 VBR Audible ( フォーマット 2、3、4 ) Apple lossless WAV AIFF
サイズ	91.4x50.8x12.7mm
重量	103g
付属ソフトウェア	iTunes for Mac iTunes for Windows
付属アクセサリ	インナーイヤー型ヘッドフォンベルトクリップ AC アダプタ FireWire ケーブル USB 2.0 ケーブル	インナーイヤー型ヘッドフォンベルトクリップ USB 2.0 ケーブル

FireWire ケーブルと AC アダプタが付属しなくなった分、価格が安くなっています。また、バッテリー駆動時間が飛躍的に延び、容量が大きくなったモデルもラインナップに追加されています。

表中には書いてありませんが、新しいiPod miniのクリックホイールの操作アイコンはボディカラーに合った色に変更され、ボディカラーも色が鮮やかになったようです。

新旧モデル比較 - iPod photo

	旧モデル 40GB	旧モデル 60GB	新モデル 30GB	新モデル 60GB
価格	57,540 円	70,140 円	38,800 円	49,800 円
カラーバリエーション	ホワイト
容量	40GB	60GB	30GB	60GB
バッテリー駆動時間	音楽再生時間 : 最長 15 時間 BGM 付きフォトスライドショー再生時間 : 最長 5 時間
ディスプレイ	2 インチ ( 対角 ) 65,000 色カラー LCD 、 LED バックライト付き		2 インチ ( 対角 ) 65,536 色カラー LCD 、 LED バックライト付き
本体入出力ポート	Dock コネクタワイヤードリモコン用コネクタステレオヘッドフォンジャックオーディオおよびコンポジットビデオ出力 ( ヘッドフォンジャック経由 )
接続方法	FireWire 400 または USB 2.0 ( Dock コネクタ経由 ) コンポジットビデオおよびオーディオ出力 ( ヘッドフォンジャックまたは iPod photo Dock のライン出力経由 )
充電時間	約 5 時間 ( 3時間でバッテリー容量の 80% を高速充電 )
オーディオフォーマット	AAC ( 16 〜 320Kbps ) MP3 ( 32 〜 320Kbps ) MP3 VBR Apple lossless WAV AIFF Audible		AAC ( 16 〜 320Kbps ) プロテクト付き AAC ( iTunes ミュージックストアから購入 ) MP3 ( 32 〜 320Kbps ) MP3 VBR Audible ( フォーマット 2 , 3 , 4 ) Apple lossless WAV AIFF
Photo サポート	対応フォーマット : JPEG , BMP , GIF , TIFF , PNG ( iPod photo で表示可能なサイズに変換 )
サイズ	104x61x19mm		103.5x61.8x16.1mm	103.5x61.8x19.1mm
重量	181g		166g	183g
付属ソフトウェア	iTunes for Mac iTunes for Windows
付属アクセサリ	iPod photo Dock インナーイヤー型ヘッドフォンキャリングケース AC アダプタ FireWire ケーブル USB 2.0 ケーブル iPod photo AV ケーブル		インナーイヤー型ヘッドフォン AC アダプタ (USB) USB 2.0 ケーブル

一見かなりの値下げに見えますが、付属アクセサリがだいぶ削られています。まあ、 Dock などを全てのユーザが必要としているわけではないでしょうから、アクセサリの付属の有無を選択できるようになったと考えると良いかもしれません。

また、 40GB モデルは無くなり、新たに 30GB モデルがラインナップに追加されました。

新旧モデル比較 - iPod shuffle

	旧モデル 512MB	旧モデル 1GB	現行モデル 512MB	現行モデル 1GB
価格	10,980 円	16,980 円	10,980 円	16,980 円
カラーバリエーション	ホワイト
容量	512MB	1GB	512MB	1GB
バッテリー駆動時間	最長 12 時間
ディスプレイ	なし
本体入出力ポート	USB コネクタステレオミニジャック
接続方法	一体型 USB コネクタを USB 1.1/2.0 ポートに接続
充電時間	約 4 時間 ( 2 時間でバッテリー容量の 80% を高速充電 )
オーディオフォーマット	MP3 ( 8 〜 320Kbps ) MP3 VBR AAC ( 8 〜 320Kbps ) プロテクト付き AAC ( iTunes ミュージックストアから購入、 M4A , M4B , M4P ) Audible ( フォーマット 2 , 3 , 4 ) WAV		MP3 ( 16 〜 320Kbps ) MP3 VBR AAC ( 16 〜 320Kbps ) プロテクト付き AAC ( iTunes ミュージックストアから購入、 M4A , M4B , M4P ) Audible ( フォーマット 2 , 3 , 4 ) WAV
サイズ	85x25x8.5mm
重量	22g
付属ソフトウェア	iTunes for Mac iTunes for Windows
付属アクセサリ	インナーイヤー型ヘッドフォンネックストラップ USB キャップ		インナーイヤー型ヘッドフォン lanyard USB キャップ

iPod shuffle は新モデルが登場していませんが、便宜上「旧モデル / 現行モデル」と記述させていただきました。付属アクセサリが一部違っていたり、オーディオフォーマットの最低ビットレートが違っていたりしますが、ほぼ同じだと考えて良いでしょう。

新旧モデル比較 - iPod U2 Special Edition

	旧モデル	現行モデル
価格	40,740 円	38,800 円
カラーバリエーション	ブラック ( 裏面には U2 のメンバーのサイン有り )
容量	20GB
バッテリー駆動時間	最長 12 時間
ディスプレイ	2 インチ ( 対角 ) グレイスケール LCD 、 LED バックライト付き
本体入出力ポート	Dock コネクタワイヤードリモコン用コネクタステレオヘッドフォンジャック
接続方法	FireWire 400 USB 2.0 ( Dock コネクタ経由 )	USB 2.0 FireWire 400 ( 別売りのケーブル使用時 ) Dock コネクタ経由
充電時間	約 4 時間 ( 2 時間でバッテリー容量の 80% を高速充電 )
オーディオフォーマット	AAC ( 16 〜 320Kbps ) MP3 ( 32 〜 320Kbps ) MP3 VBR Apple lossless WAV AIFF Audible	AAC ( 16 〜 320Kbps ) プロテクト付き AAC ( iTunes ミュージックストアから購入 ) MP3 ( 32 〜 320Kbps ) MP3 VBR Audible ( フォーマット 2、3、4 ) Apple lossless WAV AIFF
サイズ	104x60.9x14.5mm	104.1x60.9x14.5mm
重量	158g
付属ソフトウェア	iTunes for Mac iTunes for Windows
付属アクセサリ	インナーイヤー型ヘッドフォン AC アダプタ FireWire ケーブル USB 2.0 ケーブル

iPod U2 Special Edition は新モデルが登場していませんが、便宜上「旧モデル / 現行モデル」と記述させていただきました。価格が少し安くなっているようです。

表中では FireWire 400 ( 別売りのケーブル使用時 ) と書かれていますが、 FireWire ケーブルは付属アクセサリに含まれているので、おそらく記述ミスだと思います。

トラックバック送信先

clippingグループ - ::memo:: type-R - iPod mini の新モデル (旧モデルと新モデルを比較してみる)

リプライ

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

2005-09-08T09:04+09:00 - iPod 情報： iPod Nano iPodnano -iPod塾 < iPod Nano ニュース - iPod塾: iPod Nano に関する基本情報と、トラックバック受付所です。

2005-09-08T19:57+09:00 - iPod nano 発表に伴う iPod mini とのスペック比較 < hxxk.jp: iPod nano と iPod mini のスペック比較表を書きました。

iPod mini の新モデル

記事データ

投稿者

望月真琴

投稿日時

2005-02-24T22:40+09:00

タグ

概要

バッテリー駆動時間の短さがネックだった iPod mini に新モデルが登場。これまでの 8 時間から 18 時間に大幅アップ。他にも色々と変わっているので、比較してみました。

リプライ

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

記事本文

待てコラ。

アップル、「iPod photo」「iPod mini」の新モデル　デジカメ画像を直接取り込めるオプションも用意：デジタル家電総合情報サイト：Digital Freak 2005/02/24

6GB モデルというのも衝撃的ですが、それよりももっと衝撃的なのはバッテリー駆動時間の大幅な延長。 iPod mini のネックって、バッテリー駆動時間が他モデルに比べて短かった点だと思っていたので、この新モデルは非常に悔しい……。

旧モデルと新モデルを比較してみる

	旧モデル	新モデル 4GB	新モデル 6GB
価格	28,140 円	21,800 円	27,800 円
カラーバリエーション	シルバーゴールドブルーピンクグリーン	シルバーブルーピンクグリーン
容量	4GB		6GB
バッテリー駆動時間	最長 8 時間	最長 18 時間
ディスプレイ	1.67 インチ ( 対角 ) グレイスケール LCD 、 LED バックライト付き
本体入出力ポート	Dock コネクタワイヤードリモコン用コネクタステレオヘッドフォンジャック
接続方法	FireWire 400 USB 2.0 ( Dock コネクタ経由 )	USB 2.0 FireWire 400 ( 別売りのケーブル使用時) Dock コネクタ経由
充電時間	約 4 時間 ( 1 時間でバッテリー容量の 80% を高速充電 )	約 4 時間 ( 2 時間でバッテリー容量の 80% を高速充電 )
オーディオフォーマット	AAC ( 16 〜 320Kbps ) MP3 ( 32 〜 320Kbps ) MP3 VBR Apple lossless WAV AIFF Audible	AAC ( 16 〜 320Kbps ) プロテクト付き AAC ( iTunes ミュージックストアから購入 ) MP3 ( 32 〜 320Kbps ) MP3 VBR Audible ( フォーマット 2、3、4 ) Apple lossless WAV AIFF
サイズ	91.4x50.8x12.7mm
重量	103g
付属ソフトウェア	iTunes for Mac iTunes for Windows
付属アクセサリ	インナーイヤー型ヘッドフォンベルトクリップ AC アダプタ FireWire ケーブル USB 2.0 ケーブル	インナーイヤー型ヘッドフォンベルトクリップ USB 2.0 ケーブル

FireWire ケーブルと AC アダプタが付属しなくなったのを除けば、価格や容量、バッテリー駆動時間などは新モデルが全て上になっています。また、新しいiPod miniのクリックホイールの操作アイコンはボディカラーに合った色に変更されています。そして、新モデルは少し色が鮮やかになったような…… ? ( 私は旧モデルのブルーを所持しているので他の色の違いは分かりませんが、少なくともブルーは明らかに違う色だと思います。 )

それと、アームバンドもこれまでは黒色のみだったものが iPod mini Armbandは、グレー、オレンジ、イエロー、ブルー、ピンクのバリエーションからお選びいただけますとなっています。アームバンドは黒色の方がスタイリッシュだと思うのですが。 ( 負け惜しみ ) って、オレンジやイエローのように、本体に無い色のアームバンドを買う人っているんでしょうか…… ?

各種 iPod シリーズの比較表にて iPod mini 以外のラインナップの比較を行っています。

カラー液晶の iPod mini ?

結局は噂話だったようですが、カラー液晶というネタもあったようです。まあ、カラー液晶を求めるなら iPod Photo というラインナップがあるわけですし、 iPod mini はグレースケールでも問題ないかと思います。

これは多分旧モデルなんだろうなあ

MINI 3RD ANNIVERSARY MODEL

2/26(SAT) 300 台限定リリースとのことですが、タイミングから見ても新モデルが搭載されるとは考えにくいなあ。というか接続ケーブルだけ売ってもらえないものでしょうか。接続ケーブルがどういったものか分からないので、 2003 年モデルのオーディオにケーブルを接続できるのか分かりませんが。

Dog on the MINI 〜MINI購入記〜 - iPod - 新型iPodが出ていますね

MINI 3RD ANNIVERSARY MODELにも iPod mini が付属するはずですが、これは新型？旧型？

どちらでしょうかね？

私の他にもこう書いている人がいるということは、やはりどちらのモデルかの公式発表はあってないのでしょうか。 3RD ANNIVERSARY MODEL を買うわけではありませんが、気になります。

早くも購入した人が !

love all ... personal memo ... - ある意味皆の期待を裏切らない

やはりブルー以外も濃くなっていますねえ。クリックホイールのアイコンもボディカラーに合わせてあるのは細かいながらも嬉しい変更かも、と写真を見て思いました。

リプライ

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

Movable Type 自体の再インストールと環境の復旧

記事データ

投稿者

望月真琴

投稿日時

2005-02-22T22:05+09:00

タグ

概要

Movable Type をアップデートしたらログインできなくなり、再インストールをしたというお話。でもたぶん復旧できると思います。

リプライ

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

記事本文

まったり日記。: やらかしてしまった。

テンプレートがデフォルトのものに……。もう一度インストールしなおしました。また一から構築し直そうっと… との事だそうです。

ただ、 Movable Typeを3.151-jaへアップグレードしたら、ログインできなくなりましたということは、アップデート手順に何かミスがあったのでしょうか。まったり日記。のキャッシュを見ると、バージョン表記が Movable Type 2.661 となっていたので、 mt-upgradexx.cgi の実行手順が怪しいと睨んでいるのですが……。

バージョン2.6、2.61、2.62、2.63、2.64、2.65、2.66、または2.661からアップグレードする場合

mt-upgrade30.cgiを実行したあと、mt-upgrade31.cgiを実行します。

これ以外にも、例えばデータベース上から mt_author テーブルが何らかの原因で消えた場合にもログインできなくなることがありますが、前述の通り今回はアップデート手順の方に原因があると思います。

どのようにインストールし直したかで変わりますが、また元のように復旧することも可能かもしれません。もし復旧を行うつもりがあれば、ご相談いただければ復旧のお手伝いをしますよ ? ( また一から構築し直そうというのが復旧を諦めた上での発言なのか、これを機に心機一転で構築するつもりの発言なのか判断できなかったので、復旧するかしないかはまなさん ( Namamusu ) 次第ですが。 )

……と、ここまで書いて初心者運転講習会。: まったり日記。などのログが残っていることに気付きました。 Movable Type によって静的に生成されたファイルを消去する場合は Movable Type の管理画面からではなく FTP クライアントなどを使わないと消せないため、残っているのでしょう。また、 Movable Type 2.661 と Movable Type 3.x では Individual Entry Archive の URI 規則が異なるため、現行のまったり日記。で使用している Movable Type 3.151-ja によって上書きされることはありません。

復旧を行うなり、一から構築し直すなり、どちらの手段をとるかに関わらず、サーバ上のこれらのファイルは、まだ消去しないことを強く推奨します。

リプライ

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

2005-06-21T01:05+09:00 - ムーバブルタイプ Movable Typeのインストール方法 < blog.ps4.jp: ムーバブルタイプ Movable Typeのインストール方法について xrea...

2005-06-21T01:06+09:00 - ムーバブルタイプ Movable Typeのインストール方法 < blog.ps4.jp: ムーバブルタイプ Movable Typeのインストール方法について xrea...

各種ソーシャルブックマークサービスの転載状況

記事データ

投稿者

望月真琴

投稿日時

2005-02-22T03:35+09:00

タグ

概要

はてなブックマークばかり触れていたので、それ以外のサービスについても調べてみました。 LiVEMARK のキャッシュ機能ははてなブックマークよりも大胆な転載かも。

リプライ

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

記事本文

各種のソーシャルブックマークを比較してみる

前回までははてなブックマークに対して色々と考察をしてきましたが、それ以外のソーシャルブックマークはどういった運用になっているのか ? という疑問が出てきたため、比較をしてみました。私が知っている範囲での比較なので、これ以外にもソーシャルブックマークサービスの存在を知っている方がおられましたらコメント等で教えていただけると幸いです。

比較結果

ブックマーク先の内容の転載を行うかどうかを中心に比較しています。

del.icio.us

ユーザーによるコメント付与形式 ? ( ちょうど 503 Service Unavailable が頻発したため確認できず )

ソーシャルブックマーク::LiVEMARK(ライブマーク)

ユーザーが概要となる部分を指定して転載 ?
キャッシュ取得も行う。文章どころかデザインもそのままコピー。
- 基本的にそのままコピーされますが、 HTML ソースの先頭に <BASE HREF="ブックマークの URI"> ( DTD の種類に関わらずこの記述 ) が挿入されます。
  - XML 宣言や DOCTYPE 宣言よりも前に挿入されるため、当然ながら not Valid な HTML になってしまいます。これひとつで Another HTML-lint gateway の採点は 100 点から -51 点まで減点されます。
livemark.jp :: トピックを表示 - キャッシュについての考え方を教えて頂けませんか？にて問題提起はなされている模様。

はてなブックマーク - ソーシャルブックマーク

はてなブックマークによる記事本文の掲載についての考察やはてなブックマークの概要掲載は必要なのか ? で触れた通り、本文の一部を概要として自動で転載します。
はてなブックマーク日記のコメント欄にて何度か問題提起がなされていますが、はてな側のポリシーは発表されていません。

webshotsブックマーク - ソーシャルブックマーク

webshotsとは？ - webshot - 説明文はユーザーが直接入力。
120*90 ピクセルのサイズで、スクリーンショットからサムネイルを生成します。
ブックマーク先が保有する著作権に対しての意見やポリシーは特には書かれていないようです。

実は LiVEMARK も色々と問題を内包していますね……。次回はもう少し深く掘り下げてみようと思います。

リプライ

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

2005-03-08T10:35+09:00 - e-luck: 先日、このエントリーに幾つかSBMのサービスをコメントしたんですが、見事に反映されなかったっす（笑）まぁ、それは良いとして、最近は雨後の竹の子のように似たようなサービスが出てきていますね。僕自身はdel.icio.usを使っていますが、アバウトさが結構好きですね。他の人から見ると一見散らかっているように見えるけど、本人にからすると、いやこの状態で管理出来ているんだから、勝手に片づけないでくれ！って言う性格の人には合っているように思います（分かりづら！）

トラックバックスパムの対策を講じてみた

記事データ

投稿者

望月真琴

投稿日時

2005-02-22T00:54+09:00

タグ

概要

トラックバックスパムが来たため、トラックバックスパム対策プラグインをメモ。また、小粋空間の記述を用いてプラグインをカスタマイズしました。

リプライ

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

記事本文

数日間の流れを一記事に凝縮

これだけの流れを一日のうちに行ったわけではありませんが、一連の内容として一つの記事内に収めることにします。

トラックバックスパムの予兆 ?
トラックバックスパム対策メモ
Quasi-Spam Filter Plugin にフィルタ対象を加える
トラックバックスパム対策（その2）: 小粋空間の記述との違い
トラックバック送信先

トラックバックスパムの予兆 ?

先ほど、 weblog という言葉に対してスパムと思われるトラックバックが行われました。残しておいても意味は無いので削除しましたが、以下その内容を自分的にメモ。

tbping_id: 104
tbping_blog_id: 1
tbping_tb_id: 2
tbping_title: texas hold'em
tbping_excerpt: Every possible idea therefore may be said to be us...
tbping_source_url: http://www.tigerspice.com
tbping_ip: 63.96.247.20
tbping_blog_name: texas hold'em
tbping_created_on: 2005-02-20 20:39:59
tbping_modified_on: 20050220203959
tbping_created_by: NULL
tbping_modified_by: NULL

トラックバックスパム対策メモ

今回はこの 1 件のみだったので手動削除で良かったのですが、いずれ大量のトラックバックスパムに悩まされるかもしれません。と、この部分までを数日前に書いていたら、続々とトラックバックスパムが届き出しました。スパムが届き出してからようやく重い腰を上げた形になりますが、トラックバックスパム対策をメモしておこうと思います。

mt-tb.cgi 自体の書き換え

Bianca: BiancaのTrackBackSpam対策【トラックバックスパム対策】

Movable Type カスタマイズあれこれ - コメントスパム対策その 1 と同じ発想の対策です。 mt-tb.cgi を直接書き換えるため、 Movable Type 自体のアップグレード時に再度書き換える必要が生じる可能性があります。

プラグインの使用

Ogawa::Memoranda: Quasi-Spam Filter Plugin

トラックバックスパムのみならずコメントスパムにも対応したプラグインです。半角英数字のみのコメントスパムを弾くプラグイン - Trackbacks にて (o) さん ( Ogawa::Memoranda ) 自ら教えてくださいました。 ( というか教えていただいたのに使っていなかったのですか自分 )

Movable Type 自体のアップグレード時も、変更を行わなくて良い可能性があります。 ( もちろん Movable Type 自体に大幅な改変があればこの限りではありませんが。 )

Quasi-Spam Filter Plugin にフィルタ対象を加える

スパム判定ルーチンやリダイレクトURL決定ルーチンの「例」を示すことはあるかもしれませんが、単体のスパムフィルターとしての機能を充実させること自体はこのプラグインの目的ではありませんということなので、フィルタ対象を増やしたい場合は自分でコードを書き換える必要があります。

既に書き換えられたコードがトラックバックスパム対策（その2）: 小粋空間で公開されていますが、その提示方法があまり良くない ( コード自体に問題があるわけではないことに注意 ) と感じたので、「こう提示した方がより良いですよ」という意味を込めて同様のコードを掲載します。なお、 The Artistic License ( 日本語訳 ) に基づき、オリジナルの所在と改変内容を次に明記し、改変したものをソースコードの形で示します。

オリジナル

Ogawa::Memoranda: Quasi-Spam Filter Plugin

改変内容

トラックバックスパム対策（その2）: 小粋空間の記述を用いて tbping_title の文字列もフィルタの対象とするようにする。

ソースコード

sub tbping_filter {
    my ($eh, $app, $ping) = @_;
    return !is_tbping_spam($ping->excerpt);    
    return !(is_tbping_spam($ping->excerpt) | is_tbping_spam($ping->title));
}

sub tbping_throttle_filter {
    my ($eh, $app, $tb) = @_;
    my $q = $app->{query};
    return !is_tbping_spam($q->param('excerpt'));
    return !(is_tbping_spam($q->param('excerpt')) | is_tbping_spam($q->param('title')));
}

sub tbping_error {
    my $app = shift;
    my $q = $app->{query};
    my $mode = $q->param('__mode') || $app->{default_mode};
    return if $mode ne 'ping';
    if (is_tbping_spam($q->param('excerpt'))) {
    if (is_tbping_spam($q->param('excerpt')) || is_tbping_spam($q->param('title'))) {
    $app->add_methods('ping' => sub { });
    $app->_response(Error => 'Spam TBPing!', Code => 403);
    }
}

トラックバックスパム対策（その2）: 小粋空間の記述との違い

ブラウザに表示されるコードとしては、ここで掲載したものと小粋空間での記述は同じですが、 HTML ソースとしては大きく異なります。

$ を $ 、 > を > として記述
削除部分を <del> 、追記部分を <ins> でマークアップ

前者は「よりベターな書き方」という感じなので、必ずしもこう書かなければいけない、というわけではありません。 > を > ( または > ) とするのはよく聞きますが、 $ を必ず $ とする必要はありませんし。 ( ただし、記事内に Movable Type のテンプレートタグの記述をする際は、本来のテンプレートタグとバッティングする可能性があるので、 Movable Type ユーザーは癖付けておくと良いかもしれません。 )

後者の場合は、よほど <font> や <s> を使わなければならない事情が無い限りは <del> や <ins> でマークアップした方が良いでしょう。実際、私が小粋空間のコードを見た時はたまたまページの色指定を無効化していたため、訂正部分が分からなくなってしまっていました。 <del> や <ins> でマークアップしている場合は、ブラウザが適宜 ( 視覚系、音声系などのブラウザの形式によらず ) 扱ってくれるため、色などによる指定より分かりやすくなります。 ( ただし、 XHTML1.1 では pre は ins / del を内容に持てないため、 XHTML 1.1 で <pre> でソースコードをマークアップする人は、訂正部分は <em> や <span> で代用することになります。 )

トラックバック送信先

リプライ

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

iPod mini の電池残量を正確に知るようにした

記事データ

投稿者

望月真琴

投稿日時

2005-02-18T20:46+09:00

タグ

概要

満充電時の 510 という値と、電池切れとなる 200 前後という値をちゃんと頭に入れておくこと。

リプライ

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

記事本文

iPod portal : 電池残量の数値化

まとめサイト自体は iPod mini を購入する前に教えていただいて、この数値化の方法もすぐに導入しようと思っていたのですが、何故かずっと忘れていました。

今日唐突に思い出したので、この手順に倣って電池残量表示を数値化。その後充電を完全に行うと、 510 という数値が出ました。

数値が約100前後で電池切れになります。（miniの場合、200前後で電池切れになるようです）とのことなので、満充電時の 510 という値と、電池切れとなる 200 前後 という値をちゃんと頭に入れておくこと。＞自分

リプライ

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

2005-02-18T23:38+09:00 - Piro: しかし分かってはいても、ついついほったらかしにしちゃって、クリッカーの設定とかが元に戻ってしまうんですよね……今日もまたやってしまったし orz マメに充電すればいいんですが、そうすると今度は電池の寿命を縮めてしまいそうで。とほほほ。

2005-09-08T04:08+09:00 - [ ping 送信先間違い ? ] Appleから、iPod NANO, iTunes 5, iPod機能搭載携帯電話 Motorola ROKR E1発表！ < -- MACIST マッキスト --: Appleから、iPod NANOとiTunes 5, Motorola ROK

2005-09-08T04:58+09:00 - [ ping 送信先間違い ? ] 新型iPod発表iPod nano(速報) < ORCABREEZE: ついさっき、日本時間AM2時ころ、APPLEのカンファレンスにより新しいiPodの発表がありました。　"iPod nano"容量4GByte、表示ディスプレ...

はてなブックマークの概要掲載は必要なのか ?

記事データ

投稿者

望月真琴

投稿日時

2005-02-18T00:07+09:00

タグ

概要

リプライ

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

記事本文

現行のシステムを堅持する必要があるのだろうか

はてなブックマークによる記事本文の掲載についての考察でははてなブックマークのシステムの根幹はそのままで、概要が掲載されることが前提で robots.txt への対応とかガイドラインの作成とかを要望していました。が、同記事のコメント欄にていわいさんから指摘を受けて、何故自分は今のベータ版のシステムを変えない範囲の要望をしているのだろう、そもそも堅持するほど完成されたシステムなのだろうか ? と思いました。

問題点 1 - 許可無き転載が横行する可能性

これははてなブックマークが現行のシステムを続けるのであれば完全には回避できない問題です。ブックマークの登録を行う前に、ユーザーが必ず事前の転載の許諾を得るのかという点を考えると、むしろそれを行う方が少数派だと思います。

仮に転載の許諾を必ず得ること、というルールがあったとしてもそれが守られるとは思えませんし、それをするくらいならこれまで通りブラウザのブックマークに留めた方が手軽です。また、多くのユーザーはブラウザのブックマークと同列に考えているのではないでしょうか ? 内容の転載を行っているという意識を持たないままにブックマークしているケースもかなりあると思われます。

問題点 2 - 転載した張本人が簡単に姿を隠せる

先日、テストという名目で Pop or Die | 教えたはてなダイアリー（第2回）をブックマークしました。これは渦さん ( Pop or Die ) の許可は得ていませんでしたので、この記事を書き始める前に削除を行いました。

しかし、はてなブックマーク - Pop or Die | 教えたはてなダイアリー（第2回）の方は残ったままになっています。この記事は私しかブックマークしていなかったのですが、現在は私が削除したため、誰もブックマークしていないけれど内容の転載部分は残っているという状態になっています。仮に自分を含めて 10 人がブックマークしていたとしても、自分のブックマークから削除してしてしまえば、他の 9 人が内容の転載を行ったように見えます。

たとえば、はてなブックマークに内容が転載されることを好まないサイト製作者がいたとして、ブックマークを行っている人ひとりひとりに注意をしようと思っても、既にブックマークから削除してしまったユーザーには注意できません。すなわち、ブックマーク先の許諾条件を確認しないままにブックマークしていて、後から「無断転載はそれ相応の手段を以って対応します」といったサイトだと気付いた場合でも、自分のブックマークから消してしまえば証拠は表には残らないのです。

問題点 3 - ブックマーク先のタイトルは任意に付けられる

ブックマーク先を貶める意味でのブックマーク行為が簡単にできてしまいます。

はてなブックマーク - うんけぶろぎ

ブックマーク先の内容を自動で取得するのに対し、タイトルはブックマークする側で任意に作成することができます。同じページをブックマークしている他のユーザーがわかります。 似たような話題を追いかけている人を探すことができるでしょうというなら、タイトルこそ title 要素から自動取得して、ユーザーの意思が介入しないようにする方が良いと思います。

まとめ

ブックマーク先の使用許諾条件を必ず事前にチェックするようにしなければ、無断転載が横行する
- はてな側が積極的にアナウンスを行うべき
- ユーザーひとりひとりが厳しく自らを律するべき
ブックマークから削除した場合も何らかの履歴を残すようにした方が良いのでは
タイトルを任意入力できるようになっているなら、むしろブックマークするユーザーのコメントを付けられるようにして、内容の転載を行う挙動を中止すべき

結局はブックマーク先の内容を「概要」と称して掲載することについて、はてな側がどういった認識を持っているかが焦点になる気がします。

リプライ

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

はてなブックマークによる記事本文の掲載についての考察

記事データ

投稿者

望月真琴

投稿日時

2005-02-15T21:33+09:00

タグ

概要

はてなブックマークという新サービス、開始当初はブックマークするページによってはそのページの全文を転載する結果になりました。現在は文字数制限が課せられていますが、そこに至った経緯、そしてそれを行ったことにより、開始当初の状態が孕んでいた問題を考えてみようと思います。

リプライ

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

記事本文

はてなブックマークについて触れようと思っていたけれど

はてなメールマガジン『週刊はてな』 - はてなブックマークベータ版登場！フォトライフにキーワード機能を追加

つい先日にベータ版のサービスが開始されたはてなブックマークですが、昨日の時点でいくつか指摘したい部分がありました。しかし、昨日は記事にする時間がなかったので放っておいたら、他の方からの指摘を受けて改善されたようです。

コメント群が縮図となっている

はてなブックマーク - 「はてなブックマーク」でさらば、クソブログ :: TextOcean

現在は内容の冒頭が概要として掲載されていますが、 2 月 13 日の午前に私が見た時は全文が転載されていました。それに対し、転載された側の方がはてなブックマーク日記 - 2005-02-12 のコメント欄にて不満を唱えています。以下に関係のあるコメントのみを抜粋して引用します。

# textocean 『何故全文転載されますか？迷惑です、やめてください。』(02/12 16:48)

# molio 『全部見える方が嬉しいなけどなあ。まあ、選択出来るほうがいいかもしれませんけど。転載されて困るようなモノはウェブに載せる方がそもそも間違ってる気がしますね。もっとコントロール出来る所に載せればいいと思います。』(02/12 21:30)

# ytatena 『まるで安倍某のような言いぐさですね。「自分で「素敵だな」と思ったサイトをはてなブックマークに全文転載」って感じですか。はてなさんは長い間ブログサービスを展開していますから、引用と転載の違いくらいは理解していると思っていたのですが、どうも違っていたようです。』(02/12 21:54)

# Yuichirou 『beta版だっていうのにそうカッカしなくとも。上の私のコメントにあるように、逆に収集されない場合もある。ただ単にプログラムが未経験でバカなだけ。というか、個人的にはGoogleキャッシュとかと変わらないと思う。 Googleキャッシュの方はデザインまで転載するけど。』(02/12 22:13)

# otsune 『Googleキャッシュの場合はrobot.txtでもMETAヘッダーでも簡単に「転載」を防御できます。はてなブックマークには技術的な防御方法はまだ無いみたいですね。（*.hatena.co.jpからくる"Hatena Bookmark/0.1"のuser-agentのアクセスであればBODYを空白にするという処理が考えられますが、それは最終手段として）』(02/13 08:12)

# textocean 『>転載されて困るようなモノはウェブに載せる方がそもそも間違ってる気がしますね。無断転載はひどい場合裁判沙汰ですよ。冗談も休み休み頼む。あ、なおってる。 >ytatenaさんひどい世の中になった物ですね』(02/14 04:58)

# hoshikuzu 『otsuneさんの御意見に賛成いたします。標準的な方法でのmeta要素記述やrobot.txtを参照するのは最低限のエチケットでしょう。標準的に検索結果のキャシュが許された時にはじめて、あらためて<meta name="Hatena::Bookmark" content="noindex">を調べるべきです。』(02/14 12:56)

現在は全文を掲載することはせず、最大でも 250 文字強の掲載に留めるように変更されていますし、 meta 要素による掲載拒否の意思表示にも対応しています。しかし、このコメント群で話されている内容は、はてなブックマークにおける問題点や今後の課題を、縮図として表しているように思えます。

ページによっては内容が全文転載されてしまっていた

これは既に改善された点なので細かい所までは触れませんが、 Movable Type などの weblog ツール、また weblog サービスなどの、いわゆる「概要」を記事内容の項目として持っているものに対しては、その部分を掲載していたようです。試しに、はてなダイアリーの記事別表示への要望と疑問をブックマークしてみたら、

はてなダイアリーの記事別表示は、現状では前後の記事へのナビゲーションが実装されていません。また、コメントやトラックバックは記事別ではなく日毎のものが表示されます。

といったように、私が書いた概要部分が掲載されていました。ただし、全てのページに対してこういった挙動を行うわけではなかったようで、それこそ前述の TextOcean が使用していた Textpattern で作られたページは、全文が掲載される事となったようです。実際に全文転載された「はてなブックマーク」でさらば、クソブログ :: TextOcean では、冒頭に summary として「はてな」が国内初と称して新たなるサービスを展開する。いよいよ日本にも本格的なフォルクソノミー旋風が巻き起こりそうな予感。ウェブログが日本に登場したときも「ブログは日本に根付くか」な議論が出たわけだが、次はいよいよソーシャルブックマークマネージメント（以下SBM）に白羽の矢がたったようである。といった部分を用意していたのですが、そこのみを拾うという挙動には至らなかったようです。 ( この sammary が Textpattern で用意された項目なのか、アイザワレンさん ( TextOcean ) が手作業で書いていた部分なのかは分かりませんが。 )

そして、アイザワレンさんはわたしのことと、ここのこと :: TextOcean にて転載の条件を明示しています。

以下の条件に従う場合に限り、自由に:

本作品を複製、頒布、展示、上演、演奏、口述、上映、公衆送信することができます。

二次的著作物を作成することができます。

従うべき条件は以下の通り

by

帰属. あなたは原著作者・実演家のクレジットを出さなければなりません。

nc

非営利. あなたはこの作品を営利目的で利用してはなりません。

sa

同一条件許諾. もしあなたがこの作品を改変、変形または加工した場合、あなたはその結果生じた作品をこの作品と同一の許諾条件の下でのみ頒布することができます。

再利用や頒布にあたっては、この作品の使用許諾条件を他の人々に明らかにしなければなりません。

この作品の権利者から許可を得ると、これらの条件は適用されません。

参考：Creative Commons Deed

そして実際にはてなブックマークによって記録されたページを見ると、元記事への URI こそ併記されているものの、原著作者のクレジットが書かれているとは言えません。

何故はてなブックマークの全文転載が良くなかったのか

全文転載がなされていたタイミングでは、転載される側がそれを防ぐ術はありませんでした。 ( ドメインと UA 情報によって判別して取得を防ぐという対応も考えられるので、皆無というわけではありませんが。 ) 一部分であれ全文であれ転載を拒みたい場合は、ブックマークを行う側のユーザーの良心に任せる他無く、また一部分の転載は認めるが全文の転載は認めないという場合は、はてなブックマークのプログラムの挙動がどうなっているかに左右されるという運任せの状態でした。

先に引用したコメント群において、もっとコントロール出来る所に載せればいいと思います。といった発言が出ていますが、コントロールしようにもその手段が無かったのです。また、転載されて困るようなモノはウェブに載せる方がそもそも間違ってるという考えは非常に危険だと思います。

Google キャッシュを引き合いに出しているコメントもありましたが、 Google キャッシュは robots.txt や meta 要素の指定で避けることができます。しかしこの時点では、はてなブックマークに対して制作者が取れる自衛手段は無かったので、同列に考えることはできなかったでしょう。

結局、最大でも 250 文字程度の内容の掲載制限と、 meta 要素の指定への対応という形で変更がなされました。翻せば、その対応ができていなかった状態が、転載する側のやり得、やった者勝ちであったということの証明なのかもしれません。

ただし、 250 文字程度に制限されたとはいえ、そもそもブックマーク先の内容を転載すること自体が必要だとは思えません。

更なる改善の要望

……と、ここまでの論調だと、私ははてなブックマークというサービスに否定的な人間だと思われるかもしれません。しかし、決してそういったつもりはなく、むしろはてなならより一層の、迅速な改善を行ってくれるだろうと思ってこの記事を書いています。

robots.txt の参照

meta 要素による掲載拒否の意思表示にも対応したとはいえ、制作者側に大きな負担を強いることになってしまいます。例えば、 Movable Type を使用している場合はテンプレートの修正で、ある程度まとめて変更できますが、それ以外の weblog ツールや weblog サービスを使用している場合に同様の対処ができるかどうかは分かりません。

それに対し、 robots.txt であればルートディレクトリに配置するだけですので、制作者の負担は軽減されます。これも使える環境にある制作者は限られますが、選択肢が多くなるのはプラスになると思うので、ご検討をお願いします。

概要掲載のガイドラインの作成

はてなブックマーク - Weblog hxxks - はてなダイアリーの記事別表示への要望と疑問のように、 Movable Type で作られたページで概要を手動で記述している場合は、それが取得されて掲載されています。これは良い挙動だと思っています。

しかし、はてなブックマーク - Pop or Die | 教えたはてなダイアリー（第2回）のように、 sb で作られたページで概要を手動で記述している場合は、それが取得されずに記事の冒頭が掲載されています。 Movable Type と同様、 dc:description="教えたはてなダイアリーの記録。第二回目。" といった形式で記述されているので、同様に dc:description を取得してくれると期待したのですが……。

全てのツールやサービスへの対応を書けというのは無理がありますが、主要なツールやサービスにおいての概要の取り扱いをどうしているのか、それを示していただくと、制作者も予期せぬ内容が掲載されて困惑するということは防げると思います。

これはブックマーク先の内容を転載することを許容した上での要望だったので、改めて「ブックマーク先の内容を転載することの見直し」を要望しようと思います。

と、長々と書いてみたけれど

私自身は About this site - Copyright & Link で示している通り、記述したのが私である旨を明記した上で、かつ恣意的な改変や編集を行わない限りは全文を転載されるのは一向に構いませんし、 Google キャッシュなどの回避も特には行っていません。

ただ、 WWW 上で文章を発表する人全てがこうした考えを持っているわけではありませんので、全文の転載ということについては転載するであろう側、転載されるであろう側、お互いに気を付けねばならないと思います。合わせて引用ではない引用を正当化 ? を読んでいただくと良いかもしれません。

トラックバック送信先

はてなブックマーク日記 - 2005-02-13

リプライ

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

2005-02-16T04:41+09:00 - No beer, No Name!: 論点おかしいよ。otsuneさんの提示した案はあくまでも最終手段。彼が言っているようにね。この問題の論点は著作権。要するに*許可のない*「転載」そのものがおかしいんですよ。もちろん私的利用の範囲ならいいんですけどね。 robots.txt の参照なんかはレイヤーが違うんです。解釈すべきは使用許諾条件。例えば、クリエイティブコモンの RDF ってありましたやん。あれですわ。

2005-02-16T21:09+09:00 - 真琴: otsune さんの提示した案をどうこう言うのは関係なくありませんか ? 別に私は「 otsune さんの手段をとればはてな側の対処を待たずに自分で防げるから、それを行える環境ならば自衛策を事前にとっておくべきだ」とも、「自衛手段を取らないユーザーは無断転載されてもしょうがない」と主張しているわけではありませんし。著作権を論点にすると、はてなブックマークはほとんどの場合黒でしょう。一部であろうと全部であろうと許可の無い転載になりますし。 ( 一部分の概要のみであろうと、これは引用ではなく部分転載でしょう。 ) 結局はブックマークする側のユーザーが、どれだけブックマークしようとするページの使用許諾に注意を払うか、またはてな側がどれだけユーザーに対してその必然性を周知させるかに尽きると思います。今のままの形態でサービスを続けるのならば。私自身ははてなブックマークがブックマーク先の内容を ( 現在は一部分に変更されたとはいえ ) 転載する必要は無いと思っています。ブックマーク先の URI や、 title くらいでいいんじゃないの、と。それで足りないなら、ブックマークレットから追加する際に「ユーザー自身の言葉で」コメントを書き添えるようにすれば良いのではと思います。私ははてなブックマークのサービスには否定的ではないと本文中にて述べていますが、この「転載」という挙動については否定的なスタンスです。ただ、 hxxk.jp についての転載ははてなブックマークに限らず認めていますので、その辺りには触れなかったのです。今回は「全文掲載という挙動を改善した」という部分についてのみ語っていたので誤解を招いたかもしれませんが、使用許諾条件を解釈すべしという主張には賛同します。

2005-02-17T15:09+09:00 - iwaim: だからさ「更なる改善の要望」にあるのって全然改善になってないんですよ。こんなこと書くとキャッシュをもつ検索エンジンや Web アーカイブ系のものはどーするっていう人がでてくるのはわかってるんだけど。

2005-02-17T15:10+09:00 - iwaim: うぉ。今気づいたけど「641 : Anonymous」になってたのか…orz 名前いれたつもりだったんですけどね。すみません。それも私ですわ。

2005-02-17T23:13+09:00 - 真琴: ああ、確かに「改善」という私の表現は今考えると間違っていますね。現行のシステムの根幹を変えないままでの妥協点を求めているというか、根本的な問題に私が目を瞑ってしまっているというか。ブックマーク先の内容を取得せずに URI だけにするか、あるいは RSS などで積極的に公開していると判断できるサイトのみ取得するようにするとか、が改善にあたりますかね ? # Anonymous になってしまっているのは、こちらのテンプレートに何か問題がある可能性がありますのであまり気にしないで下さい。

2005-02-18T12:48+09:00 - iwaim: > ブックマーク先の内容を取得せずに URI だけにするか、こっちは改善で > あるいは RSS などで積極的に公開していると判断できるサイトのみ取得するようにするとか、こっちは変わらない。「RSS で積極的に配信」!=「転載OK」ですからね。そこは同じじゃないんです。その論理だと「WWW で積極的に配信」が「転載OK」の意だということと同じですから。つまり、「自分の著作物の公開」と「他人への転載の許可」は別物だということです。こう書くと当たり前に思うでしょうけど。

2005-02-18T20:25+09:00 - 真琴: 確かに、「RSS で積極的に配信」=「転載OK」としてしまうのはいささか乱暴な理論ですね……。色々と混同してしまっていたようです。ありがとうございます。

はてなダイアリーの記事別表示におけるコメント表示や投稿についての考察

記事データ

投稿者

望月真琴

投稿日時

2005-02-14T23:52+09:00

タグ

概要

はてなダイアリーはこれまで、日付ごとへのコメント投稿という形式でしたが、記事そのものに対するコメント投稿も可能になりました。ただ、それに対する解説が少し不足しているように思えます。「コメントを書く」のリンクを記事ごとに準備できないものでしょうか ?

リプライ

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

記事本文

はてなダイアリーの記事別表示に、コメントなども対応

記事ごとにコメントやトラックバックが可能になったとのことなのでためしてみました。

これまでどおり「最新の日記」を表示した状態でコメントすると、「その日付」へのコメントとなり、記事毎のページを表示した際にはコメントが表示されない。

逆に、記事に対してコメントをつけるには、該当記事の見出しアンカーをクリックして記事毎のページを表示してからコメントを書かねばならない。

「日付毎のページ」には、日付に対するコメントと記事に対するコメントがまとめて表示される。

水月るりさん ( love all ... personal memo ... ) の解説でも状況は把握できますが、自分でも実際に試してみました。今回はコメントのみを試しましたが、トラックバックについても同じように捉えて大丈夫です。

http://d.hatena.ne.jp/hxxk/20050214

hxxk.jp - 2005/01/24 archive の概要部分をコピーして書いたダイアリーです。

記事に対してコメントを投稿

それぞれ、 iPod mini 購入および使用報告書のコメントと眼鏡を買いましたのコメントをテスト用に転載しました。

これらのコメントは、記事別表示の時はもちろん、 http://d.hatena.ne.jp/hxxk/20050214 ( 日付表示の時 ) にもコメント欄にまとめて表示されます。

日付に対してコメントを投稿

http://d.hatena.ne.jp/hxxk/20050214#c

……と、記事別表示の時に投稿されたコメントは、日付表示の時にも表示されますが、それはこれまでの表示と同様どの記事に対するコメントなのかは分かり辛いです。 ( これまでのシステムで投稿されたコメントとの整合性を取るためなのかもしれませんが。 )

そして、このコメントのように日付表示のページから投稿された分は記事別表示の時には表示されません。

http://d.hatena.ne.jp/hxxk/ (「最新の日記」を表示した状態 ) や http://d.hatena.ne.jp/hxxk/20050214 ( 日付表示の状態 ) でコメントを投稿すると、各記事のコメント欄には表示されません。これはどの記事に対して投稿されたコメントであるか判断できず、またこの機能が実装される前に投稿されたコメントの表示も問題なく行うための措置だと思われます。

欲を言うと

hxxk.jp - 2005/01/24 archive のように、日付表示の際にも各記事のコメント欄が表示されて、それぞれの記事に対するコメントを表示するような方法が取られると良かったのですが……。

それを実現するためには、これまでのシステムで投稿されたコメントを切り捨てるか、無理矢理現在のシステムに適合させるかといったことが必要となると思いますので、容易ではないと思います。

しかし、表示の切り分けは無理かもしれなくても、各記事に対するコメント投稿へワンクリックで行けるようになって欲しいと思うのは私だけでしょうか。「コメントを書く」のリンクを記事ごとに準備できればいいのですが、現状では

http://d.hatena.ne.jp/hxxk/ を開く
http://d.hatena.ne.jp/hxxk/20050214/1108386415 を開く
http://d.hatena.ne.jp/hxxk/comment?date=20050214&section=1108386415#c からコメントを投稿

このように、各ユーザーのはてなダイアリーのトップページから入り、記事のみを一旦表示してからコメントを投稿しなければなりません。小さなことかもしれませんが、意外と不便に感じます。

トラックバック送信先

リプライ

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

にょぼしチガウ。にぼしチガウ。

記事データ

投稿者

望月真琴

投稿日時

2005-02-14T20:18+09:00

タグ

概要

日本は語呂合わせの記念日って多いですよね。ということで、今日は Luxin day です。

リプライ

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

記事本文

だ、そうです。酒に紅茶に甘味好きのヴァンパイア様。

……というか、「あまみすきのヴぁんぱいあ」ってタイプしたら、「奄美好きのヴァンパイア」って変換されました。そういうことだったのですか ? ( 何 )

リプライ

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

はてなダイアリーの記事別表示への要望と疑問

記事データ

投稿者

望月真琴

投稿日時

2005-02-11T23:33+09:00

タグ

概要

weblog と日記の違いをうまく言い表すのに、記事主体か日付主体か、といった視点が一例に挙げられそうです。はてなダイアリーは他の weblog サービスに追従することなく、オリジナリティを保つようにしても良いと思います。

リプライ

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

記事本文

はてなダイアリーの記事別表示モード

はてなダイアリー日記 - 記事別表示モードの追加について

だいぶ前の話題ですが、気付いたことがあるので取り上げてみます。これまでは最小で一日単位の表示だったはてなダイアリーを、設定を変更することで一日に複数の記事を書いた場合に、その記事ごとに表示するようにできるというものです。

身近なところでその設定を使っている方のダイアリーを例示させていただくと、

これまでの表示

love all ... personal memo ...

記事別表示

といった感じで、リンクなどの際もどちらか一方に限定されることなく、好きな形式を選ぶことができます。

記事別表示モードへの要望

はてなダイアリーへの要望というキーワードをはてなダイアリー内で書くと、はてなダイアリー - 「はてなダイアリーへの要望」を含む日記にリンクが張られるということなので、改めてはてなダイアリー - 真琴＠臨時更新場にも書きますが、記事別表示モードにおいても「前の記事」や「次の記事」といったナビゲーションのリンクアンカーおよび <link rel="prev" href="http://d.hatena.ne.jp/..."> や <link rel="next" href="http://d.hatena.ne.jp/..."> といった head 要素内の link 要素によるナビゲーションを実装して欲しいです。はてなダイアリー - 真琴＠臨時更新場 - はてなダイアリーへの要望に書きました。

私ははてなダイアリーはメインに使っていないので、ダイアリーユーザーというよりは一閲覧者としての要望になるかもしれませんが、はてなダイアリーが一記事一ページ : NDO::Weblog で閲覧者にも、SEO的にも優しい1記事1ページでのpermalinkですと仰っているので、閲覧者としての要望にも耳を傾けてくれると信じています。

手前味噌になりますが、私は自分のサイトでその理想形を既に Movable Type で実現しているので、その例を出しておこうと思います。

日単位表示での例

hxxk.jp - 2004/12/20 archive

記事単位表示での例

日単位の表示であればその前後の日のアーカイブへのナビゲーション、記事単位の表示であればその前後の記事へのナビゲーションを作成しています。こうしておけば、検索などで日単位の表示のページに辿り着こうが、記事単位の表示のページに辿り着こうが、その前後のページへスムーズに移動することができるはずです。

記事別表示モードへの疑問

前項の要望を書く前に、既に同じ要望を出している方がいないかをはてなダイアリー日記 - トラックバック - http://d.hatena.ne.jp/hatenadiary/20041228 から探そうと思ったのですが、はてなダイアリー日記 - 記事別表示モードの追加についてへのトラックバックは、はてなダイアリー日記 - 2004-12-28 に存在する複数の記事のどれかに対するトラックバックであり、必ずしも記事別表示への追加に対するトラックバックであるとは限りません。そのため、トラックバックから同じ要望を探すのは中止しました。

そこではてなダイアリー - 「はてなダイアリーへの要望」を含む日記の 2004 年 12 月 28 日付近から探してみましたが、同じような要望を出しておられる方はいらっしゃらないようでした。

こうした経緯から、「記事別表示にしてもコメントやトラックバックは日単位のままなのは不便だな」と思いました。それについての疑問や要望は複数見受けられましたので、いくつかリンクしておきます。

betaグループ - 香雪?GB日記 - コメントが日付別にしかつけられない現状では、記事別表示モードは閲覧者には「優しくない」: 現在のはてなダイアリー・はてなグループの欄の仕様では日付単位のコメント欄なので、記事別表示モードを使用した際に当該記事とはまったく無関係のコメントが表示されてしまうときがあります。これは閲覧者の混乱を招きそうです。文脈の理解の妨げにもなりますし、コメント欄の利用もわかりづらくなるだろうし、自分自身ですら一瞬「あれ？」って思いそう。閲覧者にも、気をつかわなくてはならない書き手にも「優しくない」仕様になってしまっています。この事態を完全に避けるためには今のままではどうしようもなくてコメント欄を閉じるしかありません。
はてなダイアリー - KLaxon - O.P. on HATENA - 昨日取り上げられなかった、はてなダイアリーの機能拡張もろもろ: アンカーを記事別にしておいてしまうと「記事とコメントのズレ」が目立つのでとりあえず今までの通りの設定にしてあります。このコメント欄問題はけっこう大きいですねぇ…なんぞ良い対策とかないのかな、余所の記事に直接リンクしたときなんか困るかも、なのです。
おぎうちの日記 Powered by はてな - はてなダイアリーへの要望: 1見出し1ページ時代のコメント & トラックバック: ただ，その場合でも記事の下に表示されるコメントはその日の日付の分がまとめて表示されます．また，トラックバックも日付レベルまでしか対応していません．ということは，特定の記事だけ表示させている場合に記事の内容とコメントがかみ合ってなくて訳がわからなくなったり*2，あるトラックバックがその日付のどの記事に対するものなのかわからなくなったりします．つまり，読む側から考えるとちょっと不便なわけです．

というわけで，「(日付レベルではなく)記事レベルでのコメントやトラックバックを可能にする」というオプションがあればうれしい人が割といるのではなかろうかと思うのですがいかがでしょう．従来とのデータ形式の一貫性を考えるとかなり難しいかもしれませんが．

これまでのコメントおよびトラックバックが日単位に対して投稿されたものであるため、それらの記事単位への移行というのが難しいのだろうと思いますが、こういった要望が多く出ているというのでは、記事単位の表示方法は片手落ちであると取られかねません。

また、これは個人的な意見ですが、はてなダイアリーであるため、記事別表示や、それに対する個別のコメント・トラックバックの実装が必ずしも必要であったのだろうかと思うのです。既に多くの weblog ツールや weblog サービスで個別の記事表示やそれに対するコメント・トラックバックの実装は行われているため、はてなダイアリーはそれに追従することなくオリジナリティを保っていても良かったと思うのですが。

上記の要望を出している方達を否定するわけではありませんが、はてなダイアリーでは、同じ日付内に全く異なる内容を羅列するという使い方自体がそもそも向いていなかったのでは、と思うのです。それはあくまではてなダイアリーを「日記ツール」として捉えるならば、という前提付きでの話ですが。いずれ別の記事にまとめるかもしれませんが、 weblog と日記の違いをうまく言い表すのに、記事主体か日付主体か、といった視点が一例に挙げられそうです。

トラックバックを辿るうちに、 anteroom annex: blog 化するはてなダイアリーという記事を見付けましたが、なかなか的確な視点でこの件を分析されていると思います。 ( コメント・トラックバック問題をいずれ解決するのであれば ) 記事別表示の方が便利だと私も思います。しかし、それがはてなダイアリーに必要であるか、そこが疑問として残るのです。

トラックバック送信先

リプライ

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

track feed と XHTML の相性

記事データ

投稿者

望月真琴

投稿日時

2005-02-10T23:48+09:00

タグ

概要

track feed というサービス、簡単に設置できるのに対して、便利さは格別なのですが、書き出しに docment.write を使っているため、 application/xhtml+xml で送出される XHTML の場合は使用できません。

リプライ

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

記事本文

track feed を試してみた

基本的には次のようなスクリプトを、リンクが張られる可能性がある HP に貼り付けるだけで設置が完了します。

<script src="http://trackfeed.com/usr/abcdef01243.js"></script>

blogなどではテンプレートを編集するだけで簡単に設置できます。

type 属性が書かれていない ? とか、ソース内のどこに貼り付ければいいの ? といった疑問を抱きつつ、貼り付けた位置には、次のいずれかの画像が表示されますということなので、フッタ部分に貼り付けることにしました。というか、最初は head 要素内に貼り付けようとしてしまいました。

フッタ部分は別テンプレートに書き出して、各テンプレートから include しているので、手間をほとんどかけずに設置完了。しばらくしてから、生成された RSS を見てみると、確かに hxxk.jp に対してリンクを張っていただいたページや、検索エンジンの検索結果などが item 要素として羅列されていました。

ログからリファラを抽出してチェックする手間を省けるため、自前でアクセス解析を行っている場合でもなかなかのメリットがあります。もちろん、自前でアクセス解析を行っていない場合はより大きなメリットになるでしょう。

Firefox で表示されていない ?

しかし、設置してしばらくして気がついたのですが、 Firefox では track feed の画像が表示されていません。何故 !? と思って Opera を起動してもやはり表示されていません。

おかしいなと思って IRC のメンバーにも確認してみたら、 Firefox や Opera を使っている人は、 OS などに関係なく表示されませんでした。

IE 6.0 でのスクリーンショット

Mozilla Firefox 1.0 でのスクリーンショット

Opera 7.53 でのスクリーンショット

`document.write` のことを失念していました

以前どこかで、 application/xhtml+xml の XHTML ( というか text/html のもの以外 ? ) では document.write は使えないという話を小耳に挟んでいましたが、自分は使わないしなあということですっかり忘れており、 IRC にてそのことの根拠を kota さん ( Webweaveres - weavin' | clippingグループ - clippin' ) に教えていただきました。

Does document.write work in XHTML?

No. Because of the way XML is defined, it is not possible to do tricks like this, where markup is generated by scripting while the parser is still parsing the markup.

You can still achieve the same effects, but you have to do it by using the DOM to add and delete elements.

で、 track feed のスクリプトがどうなっているのかというと、

ref=document.referrer;
if(ref==parent.document.URL)ref=top.document.referrer;
ref=escape(ref);
url=escape(document.URL);
document.write('<a href="http://trackfeed.com/?r=24739cfc18" target="_blank"><img src="http://trackfeed.com/img.php?r=24739cfc18&ref=',ref,'&url=',url,'" border="0" alt="track feed" /></a>');

といったように、 document.write でバナーを表示させ、その際に呼び出された元のリファラを track feed のシステムに送信しているようです。

hxxk.jp では Another HTML-lint と text/html と XHTML 1.1 - IE にのみ text/html を指定するで書いた通り、 IE 以外には HTTP ヘッダの Content-Type を application/xhtml+xml として送出しているため、実質 IE 以外では track feed のバナー表示やリファラ収集は行えません。

実際に、以前から使っていたアクセスログとの照合を行うと、 Firefox や Opera によるアクセスのリファラは track feed には記録されていませんでした。

また、 Firefox の JavaScript コンソールを見てみると、しっかりと エラー: uncaught exception: [Exception... "Object cannot be created in this context" code: "9" nsresult: "0x80530009 (NS_ERROR_DOM_NOT_SUPPORTED_ERR)" location: "http://trackfeed.com/usr/24739cfc18.js Line: 5"] と書かれていました。

track feed への要望

Q. BETA版ということですが、正式版と何が違うのですか？

A. β版は、提供サービスのさまざまな検証を目的としています。そのため、予告なくサービスの一時停止などのメンテナンスが入る可能性があります。よろしければサービス向上のため、いろいろな意見をお寄せください。

ということなので、以上を踏まえてメールを送ってみようと思います。

document.write ではなく DOM での実装はできないのか
できれば target="_blank" は使わないで欲しい

主にこんな感じで。私が DOM を習得していれば、ソースをそのまま送るということも出来ますが、実際は DOM の知識が皆無なので、要望するだけになりそうです。

リプライ

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

2006-01-02T11:52+09:00 - XSLTで記述したjavascriptをFirefoxで表示する（１２） < WWW備忘録: [主題]前記事のテスト中、インラインJavascriptの表記方法によっては IE6 Firefox1.5が動作不良を起こすことに気づいた。や、の使い...

2006-01-02T11:55+09:00 - XSLTで記述したjavascriptをFirefoxで表示する（１１） < WWW備忘録: [主題]前記事の結果が、インラインJavascriptでも成立するか調べる。やはり、Firefox+xml+xsl+javascript+document...

2006-01-02T11:58+09:00 - XSLTで記述したjavascriptをFirefoxで表示する（１０） < WWW備忘録: [主題]元記事のXSLを、IEで動作する範囲でいろいろ変えて、Firefoxの動作を見る。 [暫定結論]Firefox+xsl+javascript+d...

2006-10-22T15:17+09:00 - にゃるら、: 確かGoogle Adsenceをapplication/xhtml+xmlなサイトで表示するのに使われていたテクニックだと思いましたが、 HTML4.1にdocument.write()を含んだコードを埋め込んで、 Object要素でコードを埋め込んだHTMLを表示するというのが有ります。それを利用してみるのはどうでしょうか？

2006-10-28T12:10+09:00 - 真琴: object 要素かー。その手がありましたか。どうしても使いたくなった時は考慮してみます。

Safari と content プロパティ

記事データ

投稿者

望月真琴

投稿日時

2005-02-07T01:32+09:00

タグ

概要

このバグの存在は私も知りませんでした。そして、 UCS-2 以外の charset では @charsetを明示したとしてもエスケープが必要ということなので、エスケープ手順をメモしておこうと思います。

リプライ

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

記事本文

Safari のバグ

症状

外部スタイルシートでcontentプロパティの値に日本語などの多バイト文字を指定すると文字化けして表示される。

補足

外部スタイルシート内でバックスラッシュを用いたエスケープを行えば文字化けしません。

または、外部スタイルシートの文字コードをUCS-2にすることでも文字化けを回避できるそうです。しかし、それ以外の文字コードを使用した場合は@charsetを明示したとしてもエスケープが必要になります。

このバグの存在は私も知りませんでした。そして、 UCS-2 以外の charset では @charsetを明示したとしてもエスケープが必要ということなので、エスケープ手順をメモしておこうと思います。

バックスラッシュを用いたエスケープ方法の手順例

使用している外部 CSS 内で、 content プロパティの値に日本語を使用しているものをリストアップ。

数値文字参照用変換スクリプトにて、 16 進数の html 数値文字参照に変換。

例えば、 【追記 という文字を変換した場合、 【追記 という数値文字参照になるので、 &#x を \ に置き換え、各文字の最後の ; を消去。 \3010\8FFD\8A18 といった形式になるはずです。

前述の方法でエスケープした文字を、 content プロパティの値に日本語を使用している部分に貼り付け。

こういった感じで 16 進数のエスケープが行えます。私が知らないだけで、このようなスクリプト + 手作業ではなく、完全にスクリプトのみで変換できるページがあるかもしれません。

http://www.eris.ais.ne.jp/~haza/css/ref というページだと、スクリプトのみの変換が可能です。コメント欄での補足、ありがとうございます。

http://www.eris.ais.ne.jp/~hiro/css/ref にリソースが移動した模様。重ね重ねコメント欄での補足、ありがとうございます。

:before 擬似要素 / :after 擬似要素の活用例を参考にされた方で、ブラウザのターゲットに Safari を含めている方は、この対策を行うようにしてください。

トラックバック送信先

Lucky bag::blog: contentプロパティの文字化け

リプライ

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

2005-02-07T22:50+09:00 - drry: このバグの存在は私も知りませんでした。そして、直ぐに私もこの脅威からエスケープしました。参考になりました。

2005-02-08T20:25+09:00 - No beer, No Name!: http://www.eris.ais.ne.jp/~haza/css/ref 同サイトのこちらを紹介すべきかと>真琴さん

2005-02-08T22:16+09:00 - 真琴: http://www.eris.ais.ne.jp/~haza/html/numref の最下部からリンクが張ってあったんですね……完全に見落としていました。

2005-12-18T18:58+09:00 - PCとIT関連の覚え書き < PukiWiki/TrackBack 0.2: CSS関連 † ↑CSSのcontentに関するSafariのバグ † http://hxxk.jp/2005...

2005-12-19T17:49+09:00 - CSSメモ < PukiWiki/TrackBack 0.2: CSSのcontentに関するSafariのバグ † 下記ページでバックスラッシュのエスケープに変換すれば解決。 http://www.e...

2006-09-28T01:20+09:00 - ちゃんかず: はじめまして。いつも参考にさせてもらっています。ところで、変換スクリプトは http://www.eris.ais.ne.jp/~hiro/css/ref に移転した模様です。お役に立てば幸いです。

2006-10-02T20:43+09:00 - 真琴: あー、ちょうど数日前にまた変換をしようと思って訪れて、 404 になっていて「えええええええええええ」と思っていたところでした ! 助かりました !

hxxk.jp template set -standard- 1.03 を公開

記事データ

投稿者

望月真琴

投稿日時

2005-02-06T04:30+09:00

タグ

概要

MT hxxks - hxxk.jp template set -standard- のテンプレートのコードで、 include できそうな物は別ファイルに書き出し、 include するような形に変更しました。ただ、それ以外の部分は手を付けていませんので、最終的に生成される HTML は ver. 1.02 のものと変わりありません。

リプライ

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

記事本文

カテゴリアーカイブとナビゲーションリストで紹介した、 MTInclude や PHP や SSI を使ってコードを include する手法は、各種のテンプレートの共通する部分の記述を簡略化する目的でも使えます。

ということで、 hxxk.jp template set -standard- のテンプレートのコードで、 include できそうな物は別ファイルに書き出し、 include するような形に変更しました。ただ、それ以外の部分は手を付けていませんので、最終的に生成される HTML は ver. 1.02 のものと変わりありません。

リプライ

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

カテゴリアーカイブとナビゲーションリスト

記事データ

投稿者

望月真琴

投稿日時

2005-02-04T02:32+09:00

タグ

概要

カテゴリアーカイブは、性質上カテゴリの絞込みが自動で行われるため、カテゴリリストや新着記事のリストを作る際に落とし穴にはまりやすいのです。

リプライ

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

記事本文

カテゴリアーカイブの特徴

Movable Type 3.11 のサブカテゴリ機能についての所感 (3) - デフォルトのカテゴリアーカイブでも同じようなことを述べましたが、改めて述べます。

カテゴリアーカイブは、大雑把に言うと category=``category name'' を指定した状態と同じようなアーカイブです。例えば、 MT hxxks - customize titles という、 customize カテゴリの記事タイトル一覧のアーカイブがありましたが、その中の <MTEntries> は <MTEntries category="customize"> と指定したのと同じ状態になります。

よって、カテゴリアーカイブ内のナビゲーション部分で記事リストを作ろうとすると、既に category name で抽出された中から作られます。例えば、 customize カテゴリにおける <MTEntries lastn="N"> という指定は、 <MTEntries category="customize" lastn="N"> と指定されたことと同じになってしまい、 customize カテゴリの中の最新 N 件の記事リストが作成されます。

同様に、カテゴリアーカイブ内のナビゲーション部分でカテゴリリストを作ろうとすると、これも既に category name で抽出された中から作られます。例えば、 customize カテゴリにおける <MTCategories> という指定でカテゴリ一覧を作ろうと思っても、 customize カテゴリ以下に存在するカテゴリのリストしか作れません。

カテゴリアーカイブ内でも全カテゴリのリストを作る

カテゴリアーカイブ内でも、その他のページと同様にカテゴリリストを作成したい場合は、 MTSubCategories を MTTopLevelCategories に置き換えれば良いです。テンプレート・タグ - MTTopLevelCategories にて解説されていますが、

MTSubCategoriesのクローン。ただし、カテゴリー階層の最上位で常に開始します。

というように、現在のカテゴリ階層に関係なく最上位、すなわち weblog 全体のカテゴリからカテゴリリストを作成します。

カテゴリアーカイブ内でも全記事の新着記事リストを作る (1)

カテゴリアーカイブ内で、カテゴリの中での最新 N 件での表示ではなくて、全体の最新 N 件の記事リストを作りたい場合はいくつかの方法があります。一つは、 MTInclude を用いる方法です。

MTInclude には module 属性と file 属性のどちらかを指定するようになっています。

module

主にテンプレートの記述を簡略化する目的で用います。

例えば、ヘッダなど、すべてのHTMLファイルに共通する部分があって、その部分をMovable Typeを使って管理したいとき、共通部分をテンプレート・モジュールにして、その名前をHeaderに設定した後で、<MTInclude>を使って、次のように読みこみます。
<$MTInclude module="Header"$>

あくまでモジュールであるため、本来のテンプレートの性質を継承します。

file

外部ファイルを読み込むことで、本来のテンプレートの性質に関係なく、記事リスト等を作成できます。

今回のような目的で MTInclude を使う場合は、 module 属性ではなく file 属性を指定します。 module 属性を使った場合、モジュールを呼び出した時点ではテンプレートタグを読み込んでいるだけなので、実際のアーカイブ生成の際はカテゴリアーカイブの性質を継承してしまうためです。

「メインページ」テンプレートから、新しい記事を表示する部分をコピーします。
```
<ul>
<MTEntries lastn="10">
<li><a href="<$MTEntryPermalink$>"><$MTEntryTitle$></a></li>
</MTEntries>
</ul>
```
「新しいインデックス・テンプレートを作る」から、新規テンプレート「 recent_entries 」を作成し、テンプレートの中身に先程のコードを貼り付けます。ここでは、ファイル名を「 recent_entries.html 」と設定します。なお、「インデックス・テンプレートを再構築するときにこのテンプレートを自動的に再構築する」のチェックを外さないようにしてください。
カテゴリアーカイブのテンプレートの、任意の場所に <$MTInclude file="recent_entries.html"$> と記述して、再構築を行うと完成です。

カテゴリアーカイブ内でも全記事の新着記事リストを作る (2)

MTInclude 以外に、 PHP や SSI を使って include する方法もあります。前項の手順で、アーカイブテンプレートの <$MTInclude file="recent_entries.html"$> を PHP または SSI の記述に置き換えるだけです。

この方法と MTInclude は、似ているようで大きな違いがあります。

このファイルはページがリビルトされるそのときに読み込まれます。 SSI (Server Side Includes)と混同しないように注意してください。 SSIはウェブサーバにリクエストが来るたびに、毎回外部ファイルを読み込みます。 <MTInclude>を使う場合は、まず外部ファイルを編集した後、編集されたページを読み込むためにリビルドしてください。

新たな記事を書いた場合、 recent_entries.html 自体は自動でリビルドされます。しかし、 MTInclude で recent_entries.html を読み込んでいる場合、その読み込んでいる元のアーカイブをリビルドしない限り、前回のリビルド時点の recent_entries.html が読み込まれたままになります。例えば、月別アーカイブとカテゴリアーカイブの両方で recent_entries.html を読み込んでいた場合に、一方だけをリビルドし、もう一方をリビルドしないでおくとその違いが分かると思います。

対して PHP や SSI で include している場合は、 UA からのリクエストがあって初めて recent_entries.html を読み込むため、読み込んでいる元のアーカイブをリビルドしようとしまいと、最新の recent_entries.html を反映します。

また、 MTInclude の場合は recent_entries.html を読み込んだ状態でサーバにファイルを put しますが、 PHP や SSI の場合は、あくまで読み込みの命令が書かれた状態でサーバに put されるため、サーバの容量をあまり圧迫せずに済む、という利点もあります。例えば、 recent_entries.html が 10KB のサイズで、カテゴリアーカイブが 10 個あり、それぞれの本体が 50KB のサイズだとすると、 MTInclude の場合は合計で ( 50 + 10 ) * 10 = 600KB のサイズとなるのに対し、 PHP や SSI の場合は合計で 50 * 10 + 10 = 510 KB のサイズとなります。

まとめ

カテゴリアーカイブ内でカテゴリリストを作る場合は MTTopLevelCategories を使う。
カテゴリアーカイブ内で全体の新着記事リストを作る場合は PHP や SSI が使える環境であればそれで include する。使えない環境の場合のみ MTInclude を用いる。

リプライ

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

2005-03-08T07:35+09:00 - やりました！メインページ以外の２カラム化 < ななたまご: 時間にして２時間弱。こんなにかかってしまいました･･･(；´Д｀)ｳｳｯ… 最...

2005-05-20T05:53+09:00 - MTInclude とダイナミックパブリッシング < MovableType Tips by Sonots: テンプレートをモジュール化し、MTInclude テンプレートタグでとりこむことで、テンプレートの編集が楽になります。ダイナミックパブリッシング時には、MT...

2005-07-29T18:30+09:00 - アーカイブのカテゴリーリスト表示 < Jubilee: 各アーカイブページのテンプレを整えました。 …が、そこで「カテゴリアーカイブではカテゴリリストが正常...

2005-10-05T12:57+09:00 - にいじま: 「カテゴリアーカイブ内でも全記事の新着記事リストを作る（１）」を参照させていただきました。感謝です！

2005-10-12T00:46+09:00 - 真琴: どうもです :) これ、シンプルなことだけど意外とはまりやすいんですよねえ……。

2005-12-24T22:17+09:00 - MT：全カテゴリで共通のナビゲーションを表示 < kawama.jp: <MTSubCategories>の変わりに<MTTopLev...

2006-04-15T04:40+09:00 - アーカイブページの性質とサイト全体で共通のナビゲーション < Blog.37to.net: エントリーアーカイブでコメントとトラックバックを付けたついでに、トップページ...

2006-04-15T11:47+09:00 - 真琴: トラックバックをいただいた http://blog.37to.net/2006/04/post_24.html に書いてありますけど、 <MTArchiveList> テンプレートタグで実現できますね。いずれ作る新コンテンツではちゃんと扱おう……

2006-04-17T06:23+09:00 - アーカイブページの性質とサイト全体で共通のナビゲーション < Blog.37to.net: エントリーアーカイブでコメントとトラックバックを付けたついでに、トップページ...

2006-04-17T06:29+09:00 - 37to: 初めまして、先日トラックバック送信させて頂いた、37toと申します。エントリを修正した際に再びトラックバックが送信されてしまい、 2重トラックバックになってしまいました。申し訳ございません。お手数ですが、削除願います。

2006-04-18T23:54+09:00 - 真琴: 対処しました。 Trackback Auto-Discovery が有効になっていたのでしょうか ?

2006-04-20T14:33+09:00 - 37to: ２重トラックバックの件、お手数掛けまして申し訳ございません。 Trackback Auto-Discoveryという設定を初めて聞いたので、真琴さんの記事を読ませて頂きました。自分のブログを確認したところ、Trackback Auto-Discoveryは無効になってます。エントリー投稿時にトラックバックPINGを指定してトラックバックを送信してたのですが、エントリー内容を修正して保存する時に、トラックバックPINGの送信先が残ってると、再度トラックバックが送信されてしまう事を知りませんでした。今後エントリーを修正する際は、以前に送ったトラックバックPINGを消してから再保存することで、対処していきます。ご迷惑かけて申し訳ございません。追伸：真琴さんのブログは参考になる記事が多く、とても為になります＾＾今後もちょくちょく寄らせて頂くと思いますので、宜しくお願いしますm(_ _)m

2006-04-23T02:03+09:00 - 真琴: あらら、普通はトラックバックの送信に成功した時点でトラックバック送信先の欄から Ping URI はクリアされるはずなんですけどね。何らかの原因で残ったままになっていたのかもしれませんね。

2006-07-12T23:13+09:00 - ひろろ: カテゴリアーカイブ内でも全記事の新着記事リストを作る (1)を参考に、カテゴリアーカイブ内で、ほかカテゴリの記事リストを表示することができました。イロイロ調べてもみつからなくて、無理だクライアントに謝ってゆるしてもらおうと思っていたところで、このサイトに出会いました。ありがとうございます！ほんと涙がでそうなくらい嬉しい。

2006-07-15T12:31+09:00 - 真琴: (1) の方だと、記事を追加するたびにカテゴリアーカイブをリビルドしないといけないのがちょっとネックです。その点だけお気をつけください :-)

2006-07-18T20:05+09:00 - ひろろ: 真琴さんのいったとおり、クライアントからツッコミがはいりました(T_T) そこでのように修正してみたのですが動作しません。ファイルをフルパスで指定してもだめで。にするとヤフー表示されるのですが。。 phpの知識が乏しいので、何はひっかかっていることがあるのか。現在またしてもはまってます。movable type甘くみてたっす。

2006-07-18T20:09+09:00 - ひろろ: タグが消えてしまってました。＜?php include('recent_entries.html'); ?＞ヤフーは＜?php include('http://www.yahoo.co.jp'); ?＞

2006-07-18T23:49+09:00 - 真琴: フルパスって言っても 2 種類ありますからねえ。 (http://hxxk.jp/2005/11/01/2209) MTBlogSitePath (http://www.sixapart.jp/movabletype/manual/3.3/a_template_tag_reference/#MTBlogSitePath) を使って、<$MTBlogSitePath$>recent_entries.html のような指定をしてはいかがでしょう ?

2006-07-19T11:34+09:00 - ひろろ: ＜$MTBlogSitePath$＞を使うとうまく動作しました。「ウェブ・ブラウザーで表示するURLとファイルが実際に保管されるパス」があるのですね。勉強になります。真琴さん、ありがとうございます。

2007-03-25T23:41+09:00 - MT：カテゴリーアーカイブなどでの最新記事の表示 < kubolog - クボログ -: カテゴリーアーカイブを見たときに、サイドバーの最新の記事の部分が、そのカテゴ...

Movable Type 3.121 から Movable Type 3.15 へのアップデート手順

記事データ

投稿者

望月真琴

投稿日時

2005-02-02T00:18+09:00

タグ

概要

Movable Type 3.121 から Movable Type 3.15 にアップデートしたので、その手順をメモしておきます。

リプライ

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

記事本文

Movable Type 3.15 がリリースされました

Movable Type 日本語版サイト: Movable Type 3.15の提供を開始

Movable Type 3.121 から Movable Type 3.15 にアップデートしたので、その手順をメモしておきます。

Movable Type 3.15 のアップデートファイルの入手方法
アップデートファイルを put する前に
アップデートファイルを put し、再構築する
関連リソース
トラックバック送信先

Movable Type 3.15 のアップデートファイルの入手方法

まずはアップデートファイルの入手です。 Movable Type 3.11 から Movable Type 3.121 へのアップデート手順 - Movable Type 3.121 のアップデートファイルの入手方法と同じですが、再掲しておきます。

Movable Type Publishing Platform - Movable Typeの入手方法についてからログイン ( TypeKey のアカウントを事前に取得しておいてください。 )
「すでに取得したライセンスの一覧」をクリックします。
ライセンスを確認し、「ダウンロード」をクリックします。
パッケージの種類で「アップグレード」を選択します。 ( アーカイブの種類は zip でも tar.gz でもどちらでも構いません。 )

アップデートファイルを put する前に

今回は 3.1x というバージョン内でのマイナーバージョンアップなので、アップデートファイルを全部 put しなおす必要はありません。アップデートファイルのタイムスタンプと、既にサーバ上にあるファイルのタイムスタンプを照合し、新しいものだけ put するようにすると時間が短縮できるかと思います。 drry+@->Weblog - Upgrade to Movable Type 3.15-ja にて、今回更新があったと思われるファイルを調べておられるので、それを参考にするのも良いかもしれません。

その他の注意点として、

extlib ディレクトリの内容は put しない
検索用のテンプレートをカスタマイズしている場合は search_templates ディレクトリの内容は put しない
lib/MT/Template/Context.pm をカスタマイズしている場合は、その時の変更点をメモしておくか、現存のものをリネームしておく

といったことが挙げられます。私の場合、 Movable Type カスタマイズあれこれ - コメント欄の名前のアンカーの target="_blank" を外すにて Context.pm をカスタマイズしていたので、新しい Context.pm にも同様のカスタマイズを行ってからサーバに put しました。

アップデートファイルを put し、再構築する

ダウンロードしたアーカイブを解凍してできたファイルのうち、今回更新があったファイルを put します。
管理画面にアクセスすると、バージョン表示が 3.15-ja になっていることが確認できるはずです。 ( 3.1x からのアップデートの場合、 mt-upgradexx.cgi を実行する必要はありません。 ) その状態で再構築を行うと、実際に公開されるページのバージョン表示も 3.15-ja になります。

なお、 3.121 以前のバージョンを使っていて、 Movable Type 3.121 以前の脆弱性と、その対策で紹介したプラグインを使用している場合は、 3.15-ja にアップグレードしたらプラグインを削除するようにしましょう。 ( 3.122 を使っていた場合は、対策済みのパッケージですのでプラグインは使っていないと思います。 )

トラックバック送信先

drry+@->Weblog - Upgrade to Movable Type 3.15-ja

リプライ

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

Bloglines と Feed

記事データ

投稿者

望月真琴

投稿日時

2005-02-01T01:14+09:00

タグ

概要

Bloglines における Feed 提供側の心得と、 Feed 登録側の心得。心得というかちょっとした手引きかもしれません。

リプライ

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

記事本文

Bloglines の subscribers

Bloglinesで、自分の日記が登録されてる数とかわかるじゃんすか。

あれでいつまでたっても登録数が1なので相方に馬鹿にされてたんですが…

実はyuzuho.lillian.jp/index.rdfとか801.unke.jp/index.rdfとかdiary.sins.jp/atom.xmlなどなどとばらばらに登録されてた罠。

つかhttp://diary.sins.jp/index.rdfで統一してください！！登録してる皆様（ｗ

ということで自分の Bloglines を確認してみたところ、 http://yuzuho.lillian.jp/index.rdf で登録していました。確か Bloglines を活用しだした時期が、 sins.jp が Suspend になった時から取り戻した時の間だったから、 yuzuho.lillian.jp で登録して、今に至ったのでしょう。

一番の罠は相方が801.unke.jp/index.rdfで登録してたこと…orz　今すぐ直せ！即刻なおせ！キィキィ！

なるほど、 http://diary.sins.jp/index.rdf で統一 ……と口では言いながら、実は http://801.unke.jp/index.rdf で統一して欲しいと。御意。

……という黒いジョークは置いといて、何故そういった事態になったかの新展開が。

Bloglinesの罠についてなんですが、漏れの罠だった！！

相対パスで書いてたせいで、参照URL によって参照しろっていう URL が違わけです。

つことで修正します（；ｘ；）

私が見た時は既に修正されていましたが、おそらく <link rel="alternate" type="application/rss+xml" title="RSS" href="/index.rdf"> といった感じで以前は指定されていたのでしょう。そこを <link rel="alternate" type="application/rss+xml" title="RSS" href="http://diary.sins.jp/index.rdf"> と変更したようです。

ただし、 Feed の提供側が修正を行っても、既に登録済みの場合は登録者側で修正を行わなければなりません。いざ変更しようとやってみたところ、 edit subscription からは Feed URL の変更ってできないみたいなので、 http://yuzuho.lillian.jp/index.rdf での登録分を一旦 unsubscribe して、改めて http://diary.sins.jp/index.rdf で subscribe 。めでたく http://diary.sins.jp/index.rdf で登録しなおすことができました。

Bloglines の Feed 追加方法

Bloglines にて、 My feed にチェックしたい Feed を登録する場合、 2 つの方法があります。

まずひとつは、その Feed の URI を直接指定する方法。これは予めページ内などに表示されているアイコンなどから Feed の URI を知り、それを指定することで登録できます。たとえば、前項の場合だと http://diary.sins.jp/index.rdf を直接指定することになります。

そしてもうひとつが、 Feed を提供しているページの URI を指定し、ページの中から Feed を自動的に抽出して、そこから登録する Feed をユーザが選択する方法です。そのページが Feed を提供しているページで、かつ Feed がひとつしかない場合は選択をする必要がなく、ユーザが Feed の URI を意識する必要はありません。しかし、この方法で Feed を複数提供しているページを登録する場合、少し話が変わってきます。

複数の Feed を提供するページの Bloglines の取り扱い (1)

Feed を複数提供しているページを登録する場合、 Bloglines のシステムが自動的に Feed を検索し、どの Feed を登録するかの選択を促します。私はこの Feed の検索の挙動に曖昧な点があると気付きました。

2005-01-31T00:57:58+09:00 の時点で http://diary.sins.jp/ から再度登録をしようとすると、

http://801.unke.jp/index.rdf
http://diary.sins.jp/index.rdf
http://diary.sins.jp/atom.xml
http://yuzuho.lillian.jp/index.rdf

の 4 つの Feed が登録候補に現れました。はて、 ~~http://801.unke.jp/index.rdf で~~ 統一してくださいと言っているのに、異なるドメインの物が出ていますね…… ?

http://diary.sins.jp/ から各 Feed に辿れる部分が存在しているかを調べてみると、

http://801.unke.jp/index.rdf

実はyuzuho.lillian.jp/index.rdfとか801.unke.jp/index.rdfとかdiary.sins.jp/atom.xmlなどなどとばらばらに登録されてた罠。
一番の罠は相方が801.unke.jp/index.rdfで登録してたこと…orz　今すぐ直せ！即刻なおせ！キィキィ！

http://diary.sins.jp/index.rdf

<link rel="alternate" type="application/rss+xml" title="RSS" href="http://diary.sins.jp/index.rdf">
最新の更新情報取得：antenna.lirs・hina.di・index.rdf・atom.xmlをご利用ください

http://diary.sins.jp/atom.xml

<link rel="alternate" title="ATOM Feed" type="application/atom+xml" href="http://diary.sins.jp/atom.xml">
最新の更新情報取得：antenna.lirs・hina.di・index.rdf・atom.xmlをご利用ください

http://yuzuho.lillian.jp/index.rdf

実はyuzuho.lillian.jp/index.rdfとか801.unke.jp/index.rdfとかdiary.sins.jp/atom.xmlなどなどとばらばらに登録されてた罠。

と、 Feed らしき URI があり、それがサーバ上に存在していれば、とりあえず有効なものとして選択肢に含むようです。この結果を見ると分かるように、 a 要素や link 要素の href 属性に含まれる値であろうとなかろうと含みますし、そして http: が記述されていないものであろうとなかろうと含みます。この場合、作成者の柚帆さんは yuzuho.lillian.jp/index.rdf と 801.unke.jp/index.rdf を Feed として記述したつもりは無かったはずです。しかし、 Bloglines のシステムからは Feed として扱われるようになってしまっています。

この例ですと、「 Bloglines の Feed 抽出は ( 過剰なほど ) 強力」ということであって、別に曖昧な点はありません。では、何故私は「曖昧な点がある」と言ったのか。次に、同じ内容が書かれてある http://diary.sins.jp/20050128.html から Feed を抽出しようとすると、 http://diary.sins.jp/index.rdf と http://diary.sins.jp/atom.xml だけを選択肢に含みました。これは a 要素または link 要素で指定されている Feed だけを抽出したということでしょうか。ディレクトリを指定した場合との挙動が違う……これが曖昧と言った点です。

複数の Feed を提供するページの Bloglines の取り扱い (2)

http://diary.sins.jp/ での挙動を見た後に、ふと自分のところはどうだろうと思い、 http://hxxk.jp/ で登録を試みました。すると、

http://hxxk.jp/appendix/rss.rdf
http://hxxk.jp/appendix/rss2.xml
http://hxxk.jp/appendix/atom.xml

の 3 つの Feed が登録候補に現れました。しかし、ディレクトリを指定した場合に先ほどのような抽出を行うのなら、 http://hxxk.jp/forum/appendix/rss.rdf も抽出するはずです。

次に、 http://hxxk.jp/weblog/ で登録を試みると、 http://hxxk.jp/weblog/appendix/rss.rdf だけが登録候補に現れました。 http://hxxk.jp/weblog/ における link 要素での Feed の提供は http://hxxk.jp/weblog/appendix/rss.rdf だけですので、 http://diary.sins.jp/20050128.html での挙動と同じなのかもしれません。ということは、ドメイン直下のページを指定した場合と、それ以外のページを指定した場合に挙動が違うということでしょうか。しかし、ドメイン直下でも http://diary.sins.jp/ と http://hxxk.jp/ でも挙動が違いますし……謎です。

hxxk.jp の subscribers

今回取り上げた柚帆さんの例では、違うドメインから提供されている Feed を統一する ( してもらう ) ことで、 subscribers の正確な数を把握するということを行っていました。

しかし、私のように同一ドメインから複数の異なる Feed を提供している場合、 subscribers の数をまとめることはできません。 ( 皆が public で登録しているわけではありませんし、同じ人がいくつかの Feed を登録している場合もあるため。 ) 一応、各 Feed の subscribers を調べるためにここにリスト化しておこうと思います。

ちなみに、 http://hxxk.jp/appendix/rss.rdf などの hxxk.jp の Feed 以外は各コンテンツのみの新着記事のサマリを、 hxxk.jp の Feed は全ての新着記事のサマリを提供しています。いっぱいあって、どれを登録すればいいか分からないという場合は http://hxxk.jp/appendix/rss.rdf をお試しでどうぞ。

トラックバック送信先

Seven Deadly Sins.(2005-01-28)

リプライ

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

2005-02 アーカイブ

記事データ

記事本文

リプライ

記事データ

記事本文

LiVEMARK のキャッシュ機能は廃止されました

著作権の侵害と親告罪

とは言え

リプライ

記事データ

記事本文

Movable Type 2.x はトラックバックを一括管理できない

Movable Type 2.x でトラックバックを一括管理する

トラックバック管理テンプレート

補足

トラックバック送信先

リプライ

記事データ

記事本文

Recent Reaction template ver.3 の概要

recently_pinged_on Plugin

必須プラグイン

テンプレートの作成手順

テンプレートの記述例

サンプル

Recent Comments の解説

Recent Trackbacks の解説

活用例

関連リソース

トラックバック送信先

リプライ

記事データ

記事本文

ついでに。

新旧モデル比較 - iPod

新旧モデル比較 - iPod mini

新旧モデル比較 - iPod photo

新旧モデル比較 - iPod shuffle

新旧モデル比較 - iPod U2 Special Edition

トラックバック送信先

リプライ

記事データ

記事本文

待てコラ。

旧モデルと新モデルを比較してみる

カラー液晶の iPod mini ?

これは多分旧モデルなんだろうなあ

早くも購入した人が !

リプライ

記事データ

記事本文

リプライ

記事データ

記事本文

各種のソーシャルブックマークを比較してみる

比較結果

リプライ

記事データ

記事本文

数日間の流れを一記事に凝縮

トラックバックスパムの予兆 ?

トラックバックスパム対策メモ

Quasi-Spam Filter Plugin にフィルタ対象を加える

トラックバックスパム対策（その2）: 小粋空間の記述との違い

トラックバック送信先

リプライ

記事データ

記事本文

リプライ

記事データ

記事本文

現行のシステムを堅持する必要があるのだろうか

問題点 1 - 許可無き転載が横行する可能性

問題点 2 - 転載した張本人が簡単に姿を隠せる

問題点 3 - ブックマーク先のタイトルは任意に付けられる

まとめ

リプライ

記事データ

記事本文

`document.write` のことを失念していました