2005-10 アーカイブ

http://hxxk.jp/2005/10/

情報処理の授業と Web サービス

記事データ

投稿者

望月真琴

投稿日時

2005-10-31T22:46+09:00

タグ
概要

授業で一斉にはてなのアカウントを取得し、はてなダイアリーを用いて授業を行うことについて。

リプライ

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

記事本文

はてなダイアリーを授業に用いるということ

はてなブックマーク - 最近の人気エントリー経由で入江製作所の業務日誌 - これがはじめてのブログです.。 どういった現象かということは403 Forbidden - はてブでいきなりグーグルとヤフーのトップページがホッテントリ化した件についての記録が詳しいのでまずご一読を。

さて、 誰でも簡単に始められ と謳われ、利用規約でも「教材としての利用」の禁止は明記してありませんので、ルール上ははてなダイアリーを授業に用いることは問題ないかもしれません。 ( 当社の承諾無く本サービスを転用・売却・再販する行為 という条文がありますが、使い方を工夫して教材とすることが転用に当たるとは言い切れません。 )

しかし、そういった目的により向いているはてなグループというサービスがありますので、そちらを使うのが筋じゃないかなと思いました。 ( 情報処理 4B の部屋というグループが作成されていますが、こちらは現在教員のみしか参加されていないようです。 ) ちょっと調べれば分かりますが、この授業の目的は インターネットの仕組みついて学び,ネットワークを活用したコンピュータの利用方法を身につける. ということになっています。 はてなダイアリーを使うことが本来の目的ではなく、あくまで授業の一環として利用しているというのは理解できますが、教室内で顔を突き合わせて交わされているようなやりとりがそのまま WWW にパブリックにされているので、できるなら有料オプションを利用して、まずはプライベートモードでインターネットに関するリテラシを培ってからパブリックにするというステップを踏んでも良いのではと思いました。 人数から見ておそらく 6,400 ポイント / 月になりますので、教材費などの名目で計上できない範囲ではないと思います。

本筋には関係ないつぶやき

  • 4B ってことは生物工学科の 4 年生ということですよね……。年齢的には 18 ~ 19 歳となる学年なのですが、入江製作所の業務日誌 - これがはじめてのブログです.から辿れる日記を見ると「 18 ~ 19 歳のリテラシってこれくらいかあ」と考えさせられます。まあ自分が同じ年代の頃はパソコンなんて未知の機械だったから何とも言えませんが。
  • いくつか見て回ったけど早速「みんなのプロフィール」がコメントしているダイアリーがあって流石だなと思いました。
  • 八代高専なら、はてなダイアリーよりもごろっとやっちろを使った方が、より地域密着で良いんじゃないかなあと思ったり。
    • ごろっとやっちろINTERNET Watch でも紹介された地域密着型ポータル & ソーシャルネットワーキングサイトです。
      • 記事中では八代市行政管理部行政システム課が開発を担当と書かれていますが、実質はその中の 1 人がほぼ 100% を担当したと聞いています。
      • スタート時の予算は○万円だったそうな。 ( 言っていいのか分からないので伏字。というかこの数字公表すると業界の相場が変わっちゃいますたぶん。 )
  • 魯介先生を絡めたボケは分かりにくすぎます。三大姐 ( スリー・アネーゴス ) て書かれなかったら見落としていたかも。

トラックバック送信先

入江製作所の業務日誌 - これがはじめてのブログです.

教材として用いるのなら、はてなグループあるいはごろっとやっちろを活用する方がより良いと思います。

403 Forbidden - はてブでいきなりグーグルとヤフーのトップページがホッテントリ化した件についての記録

魯介先生を絡めたボケは分かりにくすぎます。三大姐 ( スリー・アネーゴス ) て書かれなかったら見落としていたかも。

リプライ

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

2005-11-01T12:27+09:00 - gnt

あわわ。場末の日記への久々のトラックバック! しかもギークと名高いhxxk.jpさんから! なので叩かれてるんじゃないかとドキドキしました(批判されてもしょうがない行為ではあるし)。 なんと言うか、無断リンク禁止と言ったりムダにグーグルにリンクさせたり、教育現場は忙しいことだなあ、というのが感想です。高専ならば1人や2人ギークなヤツがいて、身内で指摘しても良さそうなものではないか、とも思いますね。 あ、あとご指摘に基づき、ボケには一応(c)表示を付けておきました。あしからず。

2005-11-02T11:30+09:00 -

先生の?Dに?Gの掲示板への誘導あるんですが、これグループメンバー以外投稿できない設定になっているのでまさに「掲示板」として機能させるつもりなんすかね?謎だ。

2005-11-03T02:24+09:00 - 真琴

>gnt さん 私はギークだったのですか ! ( 初耳 ) 後からはてなグループも使用しているあたり、ある程度はてなの活用法は分かっていそうですね。 gnt さんのご指摘の通り、できれば学生達がアカウント作成する時点で、誰かギークな学生がグループの提案をしていたら良かったかな、と思います。 しかし魯家介先生はタイムリーなのか…… 3 巻がタイムリーっちゃタイムリー ? >渦さん 来週になったら学生達がグループメンバーになっていたりするかも ? 書き込みをメンバーに制限してプライバシーが保たれると考えていたら危ないなあ……。

2005-11-04T22:46+09:00 - 真琴

こういう記事書いたら「三大姐」で Google 検索結果のトップに……。 http://www.google.com/search?q=%E4%B8%89%E5%A4%A7%E5%A7%90&lr=lang_ja

2005-11-08T18:58+09:00 - 入江です.

さっき,皆さんのコメントをみて, 自分の大失態に気がつきました. なんとコメントして良いかわかりませんが,皆さんのご指摘の通りです.まったくもって反省してます.  気をつけていたつもりが,かなり甘かったですね.

2005-11-09T19:09+09:00 - 真琴

>入江さん どうもこんばんは。 流石に住所や生年月日まで書いていた学生はいなかったと思いますので、最初の段階で分かって良かったというか。 授業にこういった Web サービスを活用するのは面白いと思うので、より適したサービスをご利用になることを期待しています。 ( 文中にもありますがごろっとやっちろやはてなグループ、あとつい先日のリリースですがはてなリングも適しているかと思います。 )

ビール日記 2005/10/30 - アンデックス ドッペルボックドュンケル

記事データ

投稿者

望月真琴

投稿日時

2005-10-30T23:26+09:00

タグ
概要

アンデックス ドッペルボックドュンケルを飲みました。

リプライ

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

記事本文

Andechser Doppelbock Dunkel

  • アンデックス ドッペルボックドュンケル

ドイツのドッペルボックドュンケルビール。 ドュンケルはドイツ語で濃い・暗いという意味で、その名の通り赤褐茶色をしています。 ボックのうんちくでも触れた通りハイアルコールのラガービールで、アルコール度数は 7.1% となっています。 しかし重いという印象はあまりなく、甘さの方が印象に残りました。

リプライ

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

ビール日記 2005/10/29 - ブルッグス

記事データ

投稿者

望月真琴

投稿日時

2005-10-29T23:56+09:00

タグ
概要

ブルッグスを飲みました。

リプライ

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

記事本文

Brugs

  • ブルッグス

ベルギーウィートエール。 ヒューガルデン ホワイトと同じ種類ですね。 最近ヒューガルデン ホワイトを飲んでいないので比較はできませんが、ウィートエール自体が自分の好みに合っているためか、美味しくいただきました。 ちなみにアルコール度数は 4.8% です。

リプライ

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

ビール日記 2005/10/28 - 小樽ビール フェスト

記事データ

投稿者

望月真琴

投稿日時

2005-10-29T18:29+09:00

タグ
概要

小樽ビール フェストを飲みました。

リプライ

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

記事本文

小樽ビール フェスト

  • 小樽ビール フェスト

小樽ビールの季節限定ビール。 オクトバーフェストのために作られるビールと同じ製法で作られているそうです。 少し軽めの味わい。 ちなみにアルコール度数は 5.6% です。

リプライ

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

アーカイブテンプレートとパンくずリスト

記事データ

投稿者

望月真琴

投稿日時

2005-10-28T22:07+09:00

タグ
概要

各種アーカイブテンプレートにおけるパンくずリストの記述方法を、実際のソースを交えて解説しています。

リプライ

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

記事本文

アーカイブテンプレートにパンくずリストを配置する

これは weblog に限ったことではありませんが、現在表示されているページが、そのサイトのどの位置にあたるものなのかよく分からなくなるということがあります。 それを防ぐために、サイトのトップページから現在表示されているページへの経路のリンクを並べるという手法があります。 これは一般的にパンくずリストと呼ばれ、大抵はページ上部などの見易い位置に配置されます。 実は HTML / XHTML には link 要素というものが用意されていて、これを適切に記述すればこのようなパンくずリストは不要……というか蛇足となるのですが、現状では大部分のブラウザが対応しているわけではないというところです。

今回はそのパンくずリストについての論議はともかく、どういった形式のリストを作るか、それをどうテンプレートに組み込むかを解説しようと思います。 また、この部分のマークアップをどうするかも意見が分かれるところですが、今回はひとつのパラグラフとみなして p 要素でマークアップする例と、経路を順に辿る、すなわち序列リストであるとみなして ol 要素でマークアップする例を紹介します。

  1. パンくずリストの形
  2. 日付アーカイブのパンくずリスト - p 要素版
  3. 日付アーカイブのパンくずリスト - ol 要素版
  4. カテゴリアーカイブのパンくずリスト - p 要素版
  5. カテゴリアーカイブのパンくずリスト - ol 要素版
  6. エントリアーカイブのパンくずリスト (1) - p 要素版
  7. エントリアーカイブのパンくずリスト (1) - ol 要素版
  8. エントリアーカイブのパンくずリスト (2) - p 要素版
  9. エントリアーカイブのパンくずリスト (2) - ol 要素版
  10. 他にも色々
  11. Web Standards with MT ver.3.2 Strict には

パンくずリストの形

weblog の URI ( MTBlogURL ) を起点とし、そのアーカイブに辿り着くまでのリンク経路を示す形で作ります。 なお、リストにおいてそのアーカイブ自身 ( すなわち現在表示しているページ ) にはリンクを張らないこととします。

また、それぞれのリンクの区切りは p 要素版では > を用い、 ol 要素版ではそれぞれ li 要素で区切られていると考えることができるため、特に区切り文字は用いません。 ol 要素版でも区切り文字を表示したい場合は、次のように CSS に記述すると良いでしょう。

/* リストを横並びにする */
ol#hierarchical-menu li{
  display:  inline;
  }

/* 各リストの前に > を表示する */
ol#hierarchical-menu li:before{
  content:  "\000020\00003e\000020";
  }

/* リストの先頭の前には > を表示しない */
ol#hierarchical-menu li:first-child:before{
  content:  "";
  }

p 要素版でも CSS による区切り文字表示を行ってもよいのですが、 ol 要素版と違って CSS オフの状態で区切りが明確にならないため、直接 > を記述するという考え方です。

日付アーカイブのパンくずリスト - p 要素版

Web Standards with MT ver.3.2 Strict > 2005年10月 Movable Type 3.2 では、設定で自発的にアーカイブをサイト・パスとは別のパスで公開する設定にしない限りは、アーカイブはサイト・パス直下に配置されます。 デフォルトでは日付アーカイブは月別アーカイブとして作られ、 yyyy/mm/index.html として作成されますが、 yyyy/index.html は存在しないため、月別アーカイブが実質のサイト・パス直下のアーカイブと考えて良いでしょう。 「ホーム > 月別アーカイブ」という形になります。

<p id="hierarchical-menu">
<a href="<$MTBlogURL$>" title="ホーム"><$MTBlogName encode_html="1" remove_html="1"$></a> &#62;
<$MTArchiveTitle$>
</p>

日付アーカイブのパンくずリスト - ol 要素版

Web Standards with MT ver.3.2 Strict > 2005年10月 前項の日付アーカイブのパンくずリストと考え方は同じです。

<ol id="hierarchical-menu">
  <li><a href="<$MTBlogURL$>" title="ホーム"><$MTBlogName encode_html="1" remove_html="1"$></a></li>
  <li><$MTArchiveTitle$></li>
</ol>

カテゴリアーカイブのパンくずリスト - p 要素版

Web Standards with MT ver.3.2 Strict > information > download カテゴリアーカイブは日付アーカイブと違い、少々複雑になります。 サブカテゴリの階層によってリストの階層も変わりますし、テンプレートタグの組み合わせが難しくなっています。 「ホーム > カテゴリアーカイブ」という形になりますが、そのカテゴリがトップレベルカテゴリかはたまた何かのカテゴリのサブカテゴリであるかによって、一つだけ記述したり、再帰的に記述したりします。

<p id="hierarchical-menu">
<a href="<$MTBlogURL$>" title="ホーム"><$MTBlogName encode_html="1" remove_html="1"$></a><MTHasParentCategory> &#62;</MTHasParentCategory>
<MTParentCategories glue=" &#62; " exclude_current="1">
  <MTIfNonZero tag="MTCategoryCount">
    <a href="<$MTCategoryArchiveLink$>"<MTIfNonEmpty tag="MTCategoryDescription"> title="<$MTCategoryDescription$>"</MTIfNonEmpty>><MTCategoryLabel></a>
    <MTElse>
      <MTCategoryLabel>
    </MTElse>
  </MTIfNonZero>
</MTParentCategories>
&#62; <$MTArchiveTitle$>
</p>

カテゴリ部分において <MTIfNonZero tag="MTCategoryCount"> と指定することで、記事数が 0 のカテゴリ ( = アーカイブが作成されないカテゴリ ) はリンクではない文字列として表示します。 また、 <MTIfNonEmpty tag="MTCategoryDescription"> と指定することで、「カテゴリーの説明」欄が書かれていればリンクアンカーの title 属性にそれを記述するようにしています。

また、 <MTParentCategories glue=" &#62; " exclude_current="1"> と指定すると区切りが発生しない場合 ( = トップレベルカテゴリ ) でも 1 つは glue 属性の区切り文字が現れてしまうため、 &#62; が一つ余分に記述されてしまいます。 それを回避するために、ぬりかべブログ::カテゴリアーカイブのパンくずリストを参考にして、 <MTHasParentCategory> &#62;</MTHasParentCategory> とし、親カテゴリがあれば ( = トップレベルカテゴリでなければ ) &#62; を記述するようにしています。

カテゴリアーカイブのパンくずリスト - ol 要素版

Web Standards with MT ver.3.2 Strict > information > download 前項のカテゴリアーカイブのパンくずリストと考え方は同じです。

<ol id="hierarchical-menu">
  <li><a href="<$MTBlogURL$>" title="ホーム"><$MTBlogName encode_html="1" remove_html="1"$></a></li>
  <MTParentCategories glue="" exclude_current="1">
    <MTIfNonZero tag="MTCategoryCount">
      <li><a href="<$MTCategoryArchiveLink$>"<MTIfNonEmpty tag="MTCategoryDescription"> title="<$MTCategoryDescription$>"</MTIfNonEmpty>><MTCategoryLabel></a></li>
      <MTElse>
        <li><MTCategoryLabel></li>
      </MTElse>
    </MTIfNonZero>
  </MTParentCategories>
  <li><$MTArchiveTitle$></li>
</ol>

こちらは直接区切り文字を記述しないため、 <MTHasParentCategory> &#62;</MTHasParentCategory> の指定はありません。

エントリアーカイブのパンくずリスト (1) - p 要素版

Web Standards with MT ver.3.2 Strict > 2005年10月 > ダウンロードページ エントリアーカイブの標準の出力フォーマットは yyyy/mm/entry_basename.html ですので、パンくずリストは「ホーム > 月別アーカイブ > エントリアーカイブ」という形になります。

<p id="hierarchical-menu">
<a href="<$MTBlogURL$>" title="ホーム"><$MTBlogName encode_html="1" remove_html="1"$></a> &#62;
<a href="<$MTBlogArchiveURL$><$MTArchiveDate format="%Y/%m/"$>"><$MTArchiveDate format="%Y年%m月"$></a> &#62;
<$MTEntryTitle$>
</p>

エントリアーカイブのパンくずリスト (1) - ol 要素版

Web Standards with MT ver.3.2 Strict > 2005年10月 > ダウンロードページ 前項のエントリアーカイブのパンくずリスト (1) と考え方は同じです。

<ol id="hierarchical-menu">
  <li><a href="<$MTBlogURL$>" title="ホーム"><$MTBlogName encode_html="1" remove_html="1"$></a></li>
  <li><a href="<$MTBlogArchiveURL$><$MTArchiveDate format="%Y/%m/"$>"><$MTArchiveDate format="%Y年%m月"$></a></li>
  <li><$MTEntryTitle$></li>
</ol>

エントリアーカイブのパンくずリスト (2) - p 要素版

Web Standards with MT ver.3.2 Strict > information > download > ダウンロードページ エントリアーカイブの出力フォーマットは、標準の yyyy/mm/entry_basename.html 以外にも選択肢が多くあります。 ここではもう一つ、 category/sub_category/entry_basename.html の形式を考えてみます。 パンくずリストは「ホーム > カテゴリアーカイブ > エントリアーカイブ」という形になります。

<p id="hierarchical-menu">
<a href="<$MTBlogURL$>" title="ホーム"><$MTBlogName encode_html="1" remove_html="1"$></a><MTHasParentCategory> &#62;</MTHasParentCategory>
<MTParentCategories glue=" &#62; ">
  <MTIfNonZero tag="MTCategoryCount">
    <a href="<$MTCategoryArchiveLink$>"<MTIfNonEmpty tag="MTCategoryDescription"> title="<$MTCategoryDescription$>"</MTIfNonEmpty>><MTCategoryLabel></a>
    <MTElse>
      <MTCategoryLabel>
    </MTElse>
  </MTIfNonZero>
</MTParentCategories>
&#62; <$MTEntryTitle$>
</p>

カテゴリアーカイブのパンくずリスト - p 要素版の最後にエントリアーカイブを付ける感じですね。 リンクを行わない文字列はエントリアーカイブになるため、 exclude_current="1" の指定は外しています。

エントリアーカイブのパンくずリスト (2) - ol 要素版

Web Standards with MT ver.3.2 Strict > information > download > ダウンロードページ 前項のエントリアーカイブのパンくずリスト (2) と考え方は同じです。

<ol id="hierarchical-menu">
  <li><a href="<$MTBlogURL$>" title="ホーム"><$MTBlogName encode_html="1" remove_html="1"$></a></li>
  <MTParentCategories glue="">
    <MTIfNonZero tag="MTCategoryCount">
      <li><a href="<$MTCategoryArchiveLink$>"<MTIfNonEmpty tag="MTCategoryDescription"> title="<$MTCategoryDescription$>"</MTIfNonEmpty>><MTCategoryLabel></a></li>
      <MTElse>
        <li><MTCategoryLabel></li>
      </MTElse>
    </MTIfNonZero>
  </MTParentCategories>
  <li><$MTEntryTitle$></li>
</ol>

こちらも同様にカテゴリアーカイブのパンくずリスト - ol 要素版の最後にエントリアーカイブを付ける感じですね。 リンクを行わない文字列はエントリアーカイブになるため、 exclude_current="1" の指定は外しています。

他にも色々

アーカイブの出力フォーマットは、用意されたものから選ぶだけでなく、自分でカスタマイズすることも可能です。 今回出した数々のソースはあくまで一例ですので、これらを参考に、ご自身の weblog に合わせたパンくずリストを作ってみてください。

Web Standards with MT ver.3.2 Strict には

Web Standards with MT ver.3.2 Strict で配布しているテンプレートには、それぞれのアーカイブテンプレートに、日付アーカイブのパンくずリスト - ol 要素版カテゴリアーカイブのパンくずリスト - ol 要素版エントリアーカイブのパンくずリスト (1) - ol 要素版を記述しています。

なお、 ver.1.00 では CSS による区切り文字表示の指定が不充分な点があるため、お手数ですが index_templates\styles-site.txt の 323-330 行 をパンくずリストの形で紹介した記述と置き換えるか、または ver.1.01 を改めてダウンロードしていただくようお願いします。

リプライ

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

2006-02-01T13:51+09:00 - パンくずリストをつくる < うらかわのbloq

MovableType初心者なので、とりあえずパクってくるところから始まるわけだw...

2006-02-05T01:59+09:00 - パンくずリストをつくる < うらかわのbloq

MovableType初心者なので、とりあえずパクってくるところから始まるわけだw...

2006-05-31T18:45+09:00 - パンくずリストを構造化 < asamuzaK.jp

パンくずリストを構造化して出力する自己流テンプレート

2006-05-31T19:05+09:00 - パンくずリストを構造化 < asamuzaK.jp

パンくずリストを構造化して出力する自己流テンプレート

2006-06-01T10:40+09:00 - kazz

記事に加筆したときにうっかり2発目のトラバを送ってしまいました、すみません。 いつも大変参考にさせていただいています。

2006-06-07T00:13+09:00 - 真琴

2 個目のトラックバックは消去しました ( 対処だけ先にやって、レスが遅くなってすみません ) 。 単なる序列リストでパンくずリストを作るか、それとも kazz さんのように構造化してパンくずリストを作るか、どちらがより良いマークアップかまた後日考えてみたいと思います。もちろん、リストではなくパラグラフでマークアップするという選択肢もありますが。

2007-03-29T22:12+09:00 - パンくずリスト(MovableType 用) < WebRoom

『パンくずリスト』とは、今見ているページの階層を表示するナビゲーションです。 例えば【 Index...

リンク論などをつらつらと羅列してみる

記事データ

投稿者

望月真琴

投稿日時

2005-10-28T18:47+09:00

タグ
概要

14. に注意してください。何は無くとも 14. です。

リプライ

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

記事本文

あまり推敲をせずに書いたので、綿密に項目の突き合せをしないように !

  1. 14. に注意してください。多くのブラウザでは序列リストには番号が振られますので、その番号をよく見てください。序列リストの番号表示に対応していない環境の場合は、お手数ですが適宜数えてください。
  2. 以前に比べて hxxk.jp がリンクされることが増えて把握が困難になったり、知らないところで話題にされていることが多くなったりしたため、無断でリンクされることが嫌になってきました。よってリンクをされる方は、事前にトップページに設置しているゲストブックにその旨を書き込み、私の了承の返答があった場合のみリンクをするようにしてください。拒否の返答があった場合または返答なき場合はリンクをしないでください。
  3. リンクをクリックすると、その内容がブラウザ上に表示されるというのはある意味転載ですよね。ということは無断でリンクされるってことは無断転載されるということと等価ではないでしょうか。
  4. 検索エンジンでリンク許可を申請してくるところってありませんよね ?
  5. ご意見や質問があれば、コメント欄に書くか、ご自身のページに書かれてトラックバックを送ってください。それ以外は意見として認めません。
  6. hxxk.jp は Movable Type で作成している weblog です。時系列に沿って log を記録しているので、制作者の意図を充分に理解するために、記事目次から日付の古い順にご覧下さい。なお、現時点で 400 弱の記事があるのでガッツが必要。
  7. この部分は 7. になっているはずです。
  8. WWW および実社会には、以下のような定義や一般に知られているとされる常識があります。
    • WWW におけるリンクとは、 A relationship between two anchors , stored in the same or different database . と定義されており、そのアンカーの関係が無数に張り巡らされることによって WWW が成り立っていると言えます。アンカー同士の関係を示しているだけに過ぎず、転載とは全く異なるものです。
    • WWW では世界中のあらゆる所から見られる可能性があるものです。もし間違ったことを書いているページがあれば、それを指摘して間違いが拡散しないようにするというのは大事なことです。指摘と中傷は別モノ。
    • 本や新聞を必ず前書き・目次から、あるいは一面から読まなければならないという決まりはありません。途中のページから、あるいは最後のページをいきなり開いたら自動的に内容が抹消されるスパイ本が実用化されればともかく。あと子供の頃って新聞のテレビ欄の方が一面だと思っていませんでした ?
    • 大きな広場でパフォーマンスを披露しておいて、その広場に行きたい人が通行人や交番に「どこどこに行きたいのですが」と尋ね、「ああ、あそこはこういう行き方で……」と教えることや、あるいは広場の中やその近くに案内板を設置することを制限することはできません。喩え話しなので細かい点は違いますが、 WWW にページを公開すること、およびそこにリンクされることというのはそんな感じです。
    • 認証を行って特定の人だけに公開する技術や、会員制を取って会員のみに公開できるサービスがあるらしいですよ ?
  9. hxxk.jp は私がその都度調べたことや思ったことを記録するサイトです。新しい記事の方がより正確になっているとは思いますが、本のようにあらかじめ全ての筋道を立てて書いているわけではありません。 weblog 内に設置している検索機能やキーワード分類で必要な記事だけを探すのが COOL! COOL! COOL!
  10. hxxk.jp は特定のディレクトリ以外は robots.txt による内容の取得の制限は行っていません。検索エンジンやその他 Web サービスに拾われることで、同じようなことを考えていたり同じようなトラブルでつまづいていたりする人が見てくれる機会が増えますので。
  11. hxxk.jp はアクセス解析を行っており、どういったキーワードで検索してきたか、どのページからリンクが行われているかを定期的にチェックしています。
  12. はてなブックマークって自分のブックマークを公開して、そのブックマークにどういった感想を持ったか、自分なりにどういった要約をメモしたかを自ら曝け出すサービスです。どういったページをブックマークしているのか、およびそのブックマークの感想や要約をどう書いているのかを見ると、ある程度そのブックマーカの選球眼というか度量が見えて面白いですよね。被はてなブックマーク状況を新着順で知りたいという手法で、効率的にブックマーカ観察を行わせてもらっています。あとごく稀に 2ch やその他のいわゆる匿名掲示板で取り上げられていますが、リファラから辿れるものであれば拝見させていただいています。コメント欄やトラックバック以外でも貴重なご意見が出されるというのは作成者冥利に尽きます。
  13. トップページに設置しているゲストブックは、特定の記事に関連しない全般的な質問や、ちょっとした感想のために設置しています。
  14. このリストは後の方に書かれている内容を優先します。それぞれの項目を突き合わせて矛盾があるように見える場合は、後の方の内容を重視してください。
  15. 以上を踏まえてもう一度 1. からお読みください。ちなみにこの項は 15. になっているはずです。

リプライ

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

Tour "2005 Autumn Kyoto"

記事データ

投稿者

望月真琴

投稿日時

2005-10-27T23:51+09:00

タグ
概要

来月末に京都へ旅行することになりました。北海道みやげもいただいたので、今度はこちらが京都みやげを買ってこよう。

リプライ

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

記事本文

寺社仏閣巡りとか木刀とか

来月末に京都へ旅行することになりました。 まだ仕事が入ってしまう可能性を消しきれていないのですが、新幹線の予約を早めにしないと埋まっちゃうというので見切り発車で予約完了。 明日の朝には確定メールが届くはずです。

他の人のスケジュールとの兼ね合いもあって、当日の朝から動き出すのはちょっと辛いなあ……ということで、ひとり前日に大阪辺りに先行して入ってプチオフ会でもしようかとも考えましたが、最終的に当日の朝に動き出しても大丈夫みたいということで前日のプレイベントは無しで。

前日に先行入りして、親交のある ( と思っている ) 関西の Movable Typer ( 造語 ) にお会いできたらいいなと考えていましたが、それはまたの機会に。 と言っても親交があって関西だと分かっていて今ぱっと名前が出てくるのはミユキさん ( Namamono ? Diary ) や lego さん ( LIPPiN ) くらいですが。 もし「自分も関西でそしてアンタと親交があるはずだぞ ? 」という方は名乗り出ていただくと次回の関西遠征時に参考にします。 いつになるか分かりませんが。

オフ会といえば

小樽ビール 3 種類 同じ県内ということもあって、ちょくちょくお会いする草原さん ( Diary - Notes ) が先日北海道へ行ってきたということで、厚かましくも地ビールよろしく ! と頼んでいたので、別件で有給を取ったついでに受け取ってきました。

今度は私が京都で何か買ってくるよってことでまとまったのですが、はてさて何を買いましょうか。 木刀は別の友人が是非買ってきてくれと言っていたので、木刀以外で。

出発までには書き上げないと

Tour "7" - Without You の未執筆分をいい加減書き上げないとなあ、という事実。 ( まだ書いてなかったのか )

Web Standards with MT ver.3.2 Strict のドキュメントがある程度揃ったら着手しようかな。

リプライ

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

2005-10-28T18:13+09:00 - シンヤ

オレオレ。関西っすよ。 Movable Typer かと聞かれたら詰まるけど。 京都のおみやげ街道には怪しいものがいっぱい売ってますよ。変な T シャツとか未だに売ってるかも。 京都の名所では嵐山(だったかな)が好き。すごく落ち着けて川原で団子とか食べんの。超気持ちいいっ!

2005-10-28T19:28+09:00 - ミユキ

パッと名前を思い浮かべていただけて嬉しいのですが、実は私、名古屋住まいなんですよー。 別件で関西方面に関係あるサイトを運営している所為なのか、よく勘違いされるのですが… ( 苦笑 ) でも、関西方面はよく遊びに行くし、関東よりはぜんぜん行きやすい場所ですので、次に来られる予定ができましたら、お声をかけていただけたら幸いです。もちろん、名古屋にいらっしゃる機会ができたときにでもかまいませんしね。一度、真琴さんとはじっくり Laputa 話とかその他音楽話をしてみとうございますゆえ。

2005-10-28T20:04+09:00 - 真琴

>シンヤさん あれれ、何故か関東だと思ってました……。 http://d.hatena.ne.jp/code404/20051015 とか見て「結構軽いノリで遠出する人だなあ」とか思ってましたすみません。 怪しい土産かあ。そういうのは喜んでしまう友人ばかりなので拍子抜けかも (w >ミユキさん あら、シンヤさんに引き続き勘違い。まさに以前見かけたサイトの内容で記憶してました……。 名古屋もいいですねえ。山……とかいらんこと言うと実現しそうなんでやめとこう。 名古屋なら、 101 さん ( http://zerosp.com/ | http://d.hatena.ne.jp/soz/ ) も交えて V 系カラオケとかも楽しそう。

2005-10-29T21:15+09:00 - lego

ぬ。関西こられるのですね! 京都、大阪、神戸あたりならスパーンと移動できるので、またの機会があればMovable Talkingしたいです。 上でシンヤさんがおっしゃっている通り嵐山お勧めです。来月末だと紅葉はちょっとずれてるかもですが。

2005-10-30T23:46+09:00 - 真琴

>lego さん わーい lego さんまで外れてたらどうしようかと思いました ( おい ) まだ日程の計画段階ですが、いちおう主目的は紅葉鑑賞です。 1 日目はある程度決まっていて、 2 日目はそこそこ空白、という感じですねえ。

メタ検索トラックバック

記事データ

投稿者

望月真琴

投稿日時

2005-10-26T02:20+09:00

タグ
概要

検索トラックバックを送るための方法を検索で探しているのでしょうか。もはや言い訳が入る余地が無いような spam の種になりそう。

リプライ

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

記事本文

こうして検索トラックバックを送る輩がまた一人

今日のアクセスログを眺めていると、面白い検索キーワードで来られた痕跡が。

これで何か有効な方法を見つけたら、それを利用して検索トラックバックを送りまくるんでしょうかねえ。 いや検索トラックバックかどうかは断定できませんが。 検索トラックバックを送るための方法を検索する、正にメタ検索トラックバック !

幸いなことに、上記のキーワードの検索結果をざっと眺めても、具体的な方法を解説しているところはありませんでした。 しかしここまで露骨なキーワードだと、もう「同じ話題を扱っているから、役立つだろうと思って」とか「より多くの人に見てもらいたい内容だから」といった苦しい言い訳すら入る余地はありません。 ただただトラックバックを大量に送ることを命題としているだけ。 「トラックバック」の部分を「メール」に置き換えて考えてみると、いかに spam と一般的に呼ばれる行為を行おうとしているか分かります。 「トラックバックを大量に送る方法」を知った上で、自衛策を講じたいと思って検索したのかもしれませんが、やはり spam トラックバックを送ろうと模索しているように見えてしまいます……。

リプライ

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

Movable Type のテンプレートと「メニュー部分」

記事データ

投稿者

望月真琴

投稿日時

2005-10-25T23:40+09:00

タグ
概要

メニュー部分があるテンプレートは「メインページ」と「アーカイブページ」、メニュー部分がないテンプレートはそれ以外となっています。何故そのような区別がなされているのでしょうか。また、「メインページ」と「アーカイブページ」以外のテンプレートでメニュー部分を配置したい場合の注意点は ?

リプライ

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

記事本文

ここで言う「メニュー部分」とは

Movable Type のテンプレートにおいて、メニュー部分とは、大抵の場合検索フォームや各カテゴリアーカイブ・月別アーカイブへのリンク、最近の記事へのリンクなど、本文部分以外の各種メニュー的なリンクを指すと思います。 明確な定義がされているわけではありませんが、ここでの説明では以下「メニュー部分」と表す場合は、そういったリンクの羅列を指します。

Web Standards with MT ver.3.2 Strict をダウンロード された方は、 index_templates\main_index.txt または index_templates\archives.txt をご覧ください。 ダウンロードされていない方は、ご自分の Movable Type の管理画面から、「メインページ」または「アーカイブページ」のテンプレートをご覧ください。

Web Standards with MT ver.3.2 Strict テンプレートをご覧になっている場合は <dl id="menu"></dl> という部分、 Movable Type の管理画面をご覧になっている場合は <div id="beta"></div> という部分 ( Movable Type 3.2x より前のバージョンである場合や、テンプレートをカスタマイズしている場合、あるいはどこかの配布テンプレートを適用している場合はこの限りではありません ) がメニュー部分ということになります。

「メニュー部分」があるのはインデックステンプレートのみ

さてこのメニュー部分ですが、 Movable Type を使用したことがある方は、テンプレートによってその部分があったりなかったりすることにお気付きだと思います。 メニュー部分があるテンプレートは「メインページ」と「アーカイブページ」、メニュー部分がないテンプレートはそれ以外となっています。 さて、こういった部分の有無を決める基準は何でしょうか。

もちろん、「エントリアーカイブや日別アーカイブやカテゴリアーカイブには不要である」という理由があるかもしれません。 しかし、そのような想像のレベルでなく、現実的な部分で推測できる理由があります。

アーカイブテンプレートにメニュー部分を配置すると、記事を追加するごとに再構築しなければならない

記事を追加すると、最近の記事へのリンクやカテゴリアーカイブ・月別アーカイブの記事数も変わります。 「メインページ」と「アーカイブページ」は記事が追加される際に同時に再構築されるようになっているため問題はありませんが、アーカイブテンプレートは全てが再構築されるわけではありません。 ( 追加された記事のエントリアーカイブやその前後のエントリアーカイブ、関係するカテゴリアーカイブ・月別は再構築されますが、それ以外のアーカイブ――例えば、 10 月 25 日付けで記事を書いても、 9 月の月別アーカイブは再構築されません。 )

記事を書くたびに手動でサイト全体を再構築するなら問題はありませんが、サーバ負荷や手間などの関係で難しいでしょう。 アーカイブテンプレートにメニュー部分を配置する場合、そのアーカイブによってはメニュー部分が常に最新の状態となるわけではない可能性があるのです。 なお、この問題はダイナミック・パブリッシングでは発生しないかもしれません。 ( 私はダイナミック・パブリッシングを利用していないため、あくまで想像ですが。 )

カテゴリアーカイブテンプレートにメニュー部分を配置すると、そのカテゴリ以下でのカテゴリ一覧や最新の記事を抽出する

以前カテゴリアーカイブとナビゲーションリスト - カテゴリアーカイブの特徴でも説明しましたが、カテゴリアーカイブ内では MTEntries コンテナタグや MTCategories コンテナタグなどの働きが他のテンプレートと異なります。

カテゴリアーカイブテンプレートにメニュー部分を配置する場合、メニュー部分の一部がそのカテゴリ以下の記事のみを対象としてしまう可能性があるのです。

これらの可能性は回避策があるにはあるのですが、テンプレートに対するより高度な理解が必要になったり、またサーバなどの環境に左右されたりするため、それを適用してまでアーカイブテンプレートにメニュー部分を配置する必要があるのか、ということで配置していないのではと私は考えています。

回避策その 1 - PHPSSI の include またはダイナミックパブリッシングを用いる

カテゴリアーカイブとナビゲーションリスト - カテゴリアーカイブ内でも全記事の新着記事リストを作る (2) で一度説明していますので、詳しい説明は省きます。 アーカイブテンプレートとは全く別個にメニュー部分を作り、ブラウザからリクエストがある度に呼び出すようにすれば、「メインページ」や「アーカイブページ」との同期もきちんと行うことができ、「アーカイブテンプレートにメニュー部分を配置すると、記事を追加するごとに再構築しなければならない」という問題を回避することができます。

MTInclude とダイナミックパブリッシング - MovableType Tips by Sonots によると、ダイナミックパブリッシングを用いても同様の回避策が取れるようです。

回避策その 2 - MTTopLevelCategories を用いる

これもカテゴリアーカイブとナビゲーションリスト - カテゴリアーカイブ内でも全カテゴリのリストを作る で一度説明していますので、詳しい説明は省きます。 MTTopLevelCategories を用いることで、カテゴリアーカイブ内でも他のテンプレートと同様に全てのカテゴリを扱うことができ、「カテゴリアーカイブテンプレートにメニュー部分を配置すると、そのカテゴリ以下でのカテゴリ一覧や最新の記事を抽出する」という問題を回避することができます。

なお、 PHPSSI の include を用いてカテゴリアーカイブとは別個にメニュー部分を作る場合は、自動的にこの問題は回避されます。

リプライ

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

Web Standards with MT ver.3.2 Strict テンプレート ver.1.00 リリース

記事データ

投稿者

望月真琴

投稿日時

2005-10-25T03:55+09:00

タグ
概要

Web Standards with MT ver.3.2 Strict のテンプレートの ver.1.00 をリリースしました。ただし、少し予定を前倒ししたため、まだ解説等は全くありません。

リプライ

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

記事本文

テンプレートを公開しました

Web Standards with MT ver.3.2 Strict のテンプレートの ver.1.00 をリリースしました。 Web Standards with MT ver.3.2 Strict : ダウンロードページからダウンロードすることができます。 ただし、少し予定を前倒ししたため、まだ解説等は全くありません。 リファレンスを準備しました。 随時このページに追加していきます。

前倒しの理由

テンプレート公開するかもって段階でうーたん ( BAZOOKA ) と色々水面下で話をしていたんですが、 Blogサイトで見かける変なHTML のコメントでうーたんもテンプレート公開する宣言をしたので、一応先に言い出した身としては先に公開したいな、という。 あまり前倒しの理由になってないかもしれないソレ。

あと、 Movable Type のデフォルトテンプレートに照らし合わせて考えると、やはりアーカイブテンプレートには、配布時点ではメニュー部分は付けない方が良いだろうと思って取っ払いました。 後から付け足すのと、最初から付いてるものを取り外すのってだいぶ重みが違う気がするので。

リプライ

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

2005-10-25T07:15+09:00 - wu

うわーなんだかごめんなさい。 こういうしっかり作られたMTのテンプレをダウンロードできる場所が増える事はいいことだなーって思ふ。 今回ハテナに取り上げられた記事の反応を見てみても、みんな自分のBlogのソースを少なからず気にしているようですね。記事を読んで気にしだした人も多いかもしれない。

2005-10-26T00:53+09:00 - 真琴

ダボロボ ( 謎 ) 経由でもお話したけど、何だかんだで個別ページは本文だけの表示になりました。方向性が似たようなものになった以上、先に公開しちゃえっていうちょっとズルい考えもあったり。 うーたんが CSS の装飾に使えるようなテンプレートなら、こっちは色々な拡張性や豊富な解説を売りにしようかなーと思っています。 Movable Type を使う人は、他のレンタル系 weblog を使う人と違ってある程度ソースについて気にしている度が高いんじゃないかなあと思います。 そういう人たちがテンプレートを積極的にいじってくれるように、既に Movable Type できちんとした HTML を実現できている人はどんどんテンプレートを公開してくれるといいなあ。後発とかそんなの関係なく選択肢の充実というか。( さっき「先に公開しちゃえ」って言ってませんでしたか真琴さん )

はてなブックマークだってブックマーカが作る検索エンジンのようなもの

記事データ

投稿者

望月真琴

投稿日時

2005-10-20T20:05+09:00

タグ
概要

乱暴に言ってしまえばはてなブックマークだって検索エンジンのようなものですし、はてなスタッフはそう考えてはいないとしても、 robots.txt は検索エンジンだけが主な対象というわけではないので、 robots.txt による制御を受け付けないという根拠にはならないと思います。

リプライ

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

記事本文

無断リンク禁止という寝言はともかく、 robots.txt や <meta name="robots"> については解釈しても良いのでは

はてなブックマークの利用拡大に伴い、「はてなブックマークへの登録は無断リンクである」「robots.txtの設置により検索エンジンに表示されないようにも対策をしている」などの理由でウェブページ管理者からリンク削除のお問い合わせを頂くようになりました。 という件について、はてな側が考えているスタンスについて述べられています。

特に認証等を行わずに公開されているリソースについてリンクを行うことは、制限されるべきことではなく自由であるというのは WWW においては常識とも言えることですし、どうしてもはてなブックマークからのリンクを拒否をしたいなら 221.186.146.26 ( 現在のはてなブックマークサーバの IP アドレス ) を拒否すれば良い、というのも納得できます。 はてなブックマーク日記 - エントリーページへの概要掲載についてで紹介されている <meta name="Hatena::Bookmark" content="noindex"> という指定をした上で、ブックマークサーバからのアクセスを拒否すれば、ブックマーク行為自体を無効化することとほぼ同等の効果を得られるでしょう。

しかし、 robots.txtやmetaタグの設置は主に検索エンジンを対象としたものであり、ソーシャルブックマークシステムを対象とするものではないと考えている というのはちょっと解釈としておかしいなと思いました。 検索エンジンのロボットと、 Hatena Bookmark/0.1 という UA 名を名乗るシステムはどう違うの ? Web ページの内容を取得して、その内容をインデックス化して情報を提供するという点で変わりはないのでは ? と。

The Web Robots FAQ - What other kinds of robots are there? に、次のような記述があります。

Robots can be used for a number of purposes:

  • Indexing
  • HTML validation
  • Link validation
  • "What's New" monitoring
  • Mirroring

このように、 robots.txt にて制御されることになるであろう対象のロボットとは、検索エンジンだけでは無いということが分かります。 The W3C Markup Validation Service のような Validator もロボットですし、 WWWCはてなアンテナなどの更新情報をモニタリングするものもロボットですし、 Web ページの内容をミラーリングするものもロボットです。 そして、はてなブックマークは概要とはいえ、ブックマーク先のページの内容をミラーリングしている、という解釈になるのではないでしょうか ? また、仮に概要掲載が撤廃されたとしても、ブックマークが一覧で表示され、また検索機能が備わっている以上、やはり検索エンジンと全く異なるものであるとは考えにくいでしょう。

robots.txt によるブックマーク拒否を認めない、というのはブックマークされる側にとっての自衛手段の選択肢を減らしているとしか思えません。 ベータ版が開始された時にも触れましたが、自衛手段を考慮しないままここまで来て、問題が顕在化されたという印象です。 他の人がどのような感想をもっているか、どのような要約を行っているかを知ることが できるという名目ではてなブックマークにコメント機能が実装されましたが、そのコメント機能の使われ方が異なる方向に向いている現状で、「ブックマーク自体は構わないけれど、ブックマークコメントは嫌い」ということを言っている方を何人か見かけました。 そういった声ははてなスタッフには届いていないのでしょうか ?

meta 要素を尊重していると言うのなら

本題とは関係ありませんが、 既にmetaタグを尊重して本文のアーカイブ化は行わないなど、必要最低限の措置は行っていると考えている という表現も気になりました。 <meta name="Hatena::Bookmark" content="noindex"> を尊重していると言うのなら、 meta name="description" も尊重してブックマークページの概要に活用してください

今日は引用文と cite 要素と cite 属性がブックマークされましたが、やっぱり自動生成の概要は変です。 ちゃんと <meta name="description" content="引用元の情報を示す cite 要素および cite 属性のそれぞれの定義と、その使用方法について。" /> を尊重して欲しい !

hxxk.jp 、そして真琴自身は

とまあ一通り異議を唱えたわけですが、私自身および hxxk.jp 自体はブックマークされることは大歓迎です。 ブックマークコメントも喜んで拝見します。 ただ、皆が皆私のような考え方じゃない、ブックマークされることやブックマークコメントを好ましく思わない人もいる、というのをはてなスタッフやはてなブックマーカには考えていただきたいなと思いました。

トラックバック送信先

はてなブックマーク日記 - はてなブックマークにおけるリンクの考え方について

robots.txt が想定している対象は検索エンジンだけじゃありません。ソーシャルブックマークによる内容取得も充分に該当すると思います。

リプライ

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

2005-10-20T23:25+09:00 - ymer

人間によるリンク集(+ユーザ数という形でのモデレート)をロボットと言ってしまうのは乱暴であるように思います。 「検索エンジン」ではあっても、例えばYahoo!ディレクトリはrobots.txtの想定からは外れているでしょう。 傍からは自動に見えるにせよ、収集を行なっているのは紛れもなく人間であり、個々のブックマークは個人のリンク集に過ぎません。ブックマークのトップページは、単にそれを集計したまとめに過ぎないと思うのですが。

2005-10-20T23:30+09:00 - purprin

はじめまして。もうすでにかなりの頻度で、しかも無断でdel.icio.usにブックマークさせて頂いていました。真琴さんの記事はいつも大変ためになる内容で、楽しみにしています。今後とも拝読させて頂きます。それにしてもWWWのリンクに関しては今までもこれからも議論が絶えませんね。

2005-10-21T00:00+09:00 - ちはや(智猫)

酸素不足でハイな脳味噌でコメント書いちゃいますが、うちは「はてな」のサービスのほとんどが他人の懐を掻き回すようなサービスばかりで嫌いなんですが(アンテナとか)、特に「はてなブックマーク」は嫌いですねぇ……「はてなブックマーク」ユーザーの使い方のある程度がブックマークされたURLの著者を貶める行為に使ってるようですし。 他の共有ブックマークサービスを見たことは無いですが、ここまでひどい共有ブックマークサービスは無さそうな気が…… それでもアサマシ根性(アサマシと言う単語自体理解出来なかったんですけど「浅ましい」からのようで)で、Account-Auto-Discoveryの仕様が決まって採用されてから奇特なかたがブックマーク時にポイントを送信してくれるんじゃないかと「はてな」のIDを取得してBlog日記にもAccount-Auto-Discoveryを導入しはしましたが~ ……Account-Auto-Discoveryを発案したかた自体が微妙なサイトへの批判のために「はてなブックマーク」を使ってるのを見たようなみなかったような…… 追伸: はてなブックマークからの来訪を拒否するためにHTTP_REFERERに「^http://b.hatena.ne.jp/」があるものをdenyしてたこともあります。 ブックマークを利用して来訪したユーザーがHTTP_REFERERを遮蔽/隠蔽/詐称/偽称してないと言う前提条件がありますが。

2005-10-21T02:35+09:00 - 真琴

>ymer さん 概要にも私自身が書いている通り、はてなブックマーク = 検索エンジンというのはかなり乱暴なくくり方だとは思います。 Yahoo!ディレクトリを例に出されていますが、あれは作成者が申請を行って、サーファーと呼ばれる人がページを見にくるというものでした。他薦による場合もありましたが、基本的に「 Yahoo!ディレクトリに登録されたくなければ、申請をしなければ済む」ものでした。 はてなブックマークは作成者の意図に関係なく、登録が行われます。似たようなものに、人間が文法をチェックしようとして Validator を用いる場合も、作成者自身の意図は特に汲まれません。 しかし、 robots.txt はその Validator 等の UA ( ここでは「人間の代わりにアクセスし、情報のチェックや取得を行うシステム」とします ) に対する動作制御を行うことができます。それなのに、はてなブックマークの UA はそれに従わせるつもりは無い、というのはおかしな話ではありませんか ? 今後検討されるかもしれない「登録拒否のためのタグ」と、既に一般的な手段として確立している robots.txt や meta name="robots" に一体何の違いがあるのですか ? と問いかける意味で今回の記事を書きました。 ( おそらく、「主に検索エンジンを対象としたもの」という表現は主観が多分に含まれているのだと思いますが。 ) >purprin さん 時々リファラにてお見受けするので、ブックマークされているのは気付いていました :) 記事内で主張したことと被りますが、私はブックマークは無断でどんどんされて構いませんし、ブックマークされる方も皆それを喜べるというのが理想の在り方だと思います。しかし、ブックマークされることを全ての方が好むとは限りませんので、何らかの自衛手段が用意されていた方が良いと考えています。 >ちはや(智猫)さん アンテナは単にページの内容を取得して更新情報を得るだけだから、あまり引っ掻き回されるという印象はないですねえ。 ブックマークの場合はコメント機能があり、またその使われ方が少し変わってしまっているために衝突が起きる可能性があると考えています。 ( del.icio.us にもコメント機能がありますが、はてなブックマークに比べて「どういった内容なのか」をその人なりに要約しているコメントという印象が強く、メッセージ的に使われていることは少ないです。 ) 今ふと考えたんですけど、「コメント」機能ではなくて「メモ」機能だったらもう少し本来の使われ方をしていたのかなあと思いました。 HTTP_REFERER による deny ははてなブックマーク日記で言われていることと同じような自衛手段ではありますが、ブックマークされる時点で防ぐことができればよりベターな気もしますね。

2005-10-21T04:30+09:00 - otsune

なかなか興味深い視点ですね。 ちょっと考えてみました。 del.icio.us以前に存在した類似のものとして「投稿できるリンク集CGI」というのが有った記憶があります。 URLの他にサイト名とジャンルと★評価などのメタ情報が付けられたりもしました。 このリンク集CGIはrobots.txtを読んでその制御に従うべきだと考えますか? 「リンク集がrobots.txtによって制限されるなんておかしな話ではありませんか?」と言われる可能性は大きいと思います。 この話は「Webページは自我の一部であり、そこに言及する行為は自分をあげつらう行為である」という「ホームページは私の家みたいなもんだ感覚」が確実に関わっていますよね。(実際にWebサイトを例えると、家ではなくて「広場に張り出したポスター」のほうが正確だと思いますが) また 1.はてなブックマークの概要に自分のサイトの文章が転載される 2.コメント欄で言及される 3.URLで無断リンクされる これは全て分離して語るべき話題だと思います。 はてなのアナウンスは3.に対してスタンスを説明したものだと思いますし、それは正しいと思います。 ただ1.に関してrobots.txtを読まないのは反論としてアリだと思いました。

2005-10-21T08:45+09:00 - mount-root-yy

http://i.hatena.ne.jp/idea/6702  ↑関連するアイデアをあげておきました。  結局のところ、どのラインで妥協するかだと思います。

2005-10-21T22:38+09:00 - 真琴

>otsune さん 投稿形式のリンク集、ありましたねえ。ちょっと具体例を思い出せないのでどういった挙動か分かりませんが、ユーザが「投稿」を行うことで CGI 等がそのリンク先にアクセスし、ページ内の情報を ( はてなブックマークのように ) 自動的に収集するなら robots.txt をできれば読んでもらいたいと私は考えます。 もし、「サイト名」「作成者名」「ジャンル」「★評価」などのメタ情報を投稿者が記入し、 CGI 等はリンク集ページ側にその記入情報を反映するだけなら、 robots.txt は読まなくても構わない……というか、その場合は CGI 等はリンク先へのアクセス自体を行わない可能性があるので、そもそも読まれないと言った方が正確かもしれません。 もし投稿型のリンク集 CGI の多くが前者だったとして、そして robots.txt を用いて検索エンジンへの登録を防ぐのと同様にそういったリンク集への登録を防ぐというのは、「リンクをされたくない」という方の主張としては筋が通るのではと思います。 ( ただし、アクセス制限等を行わずに「リンクされることを制限したい」という時点で間違っているとは思いますが。 ) 1.2.3.といった話題の分離ですが、元のはてなブックマーク日記中で混在していたため、私の主張もごちゃごちゃになっていますね。 突っ込みを入れる際にきちんと分離すべきでした。 まず 1. についてですが、 <meta name="Hatena::Bookmark" content="noindex"> という方法で既に自衛策の選択肢は用意されているので、これについては異論はありません。これに加えて robots.txt にも対応してくれたらなお良いな、というくらいで。 ( 自動生成が変だとか descriotion を見てくれというのは転載を防ぐのとは違うレイヤーだと思いますし。 ) 2. について。 otsune さんは Web サイトを「ポスター」と喩えられましたが、これは良い喩えだと思います。私もほぼ同じ考えですが、「広場でフリーマーケットを行うような、フルオープンなスペース」のような考え方を持っています。スペース内に展示されたものを、道行く人は好きなように見たり見なかったりでき、変なものが並べられていたら「その品は欠陥品じゃ ? 」「これ取っ手が壊れてるんだけど ? 」みたいなことを自由に言うことができる、そんなイメージです。 そして、はてなブックマークの場合は、そのフリーマーケットの会場外で「ここには○○が並べてあった」「あそこは綺麗に並べられていて見やすかった」といった感想を述べているといった感じ。しかし、一部の感想の中には会場外で「あれは欠陥品みたいだったけど、そこんとこどうなんだろう」「あそこの商品札、名前間違ってなかったか ? 」と、本来その場で言うべきことを言っているものがあり、それについて不快感を示す人がいると考えています。 もちろん、その本人が会場外に出ていけば、そういった声があることを知って改善できるかもしれないけど、人によっては会場の外でそんなこと言われているなんて思いもよらなかったり、また知っていてもわざわざ会場外に行ってまで聞きたくはないと思ったりする場合もあると思います。 http://mohican.g.hatena.ne.jp/otsune/20051021/p1 にて言われていることと根底は同じだと思いますが、「酒場で話題に出来ないようにすれば~」というのは根本的な解決策にはならず、間違っていることはちゃんと本人に伝わるように、本人に伝わらない可能性があるブックマークコメントではない手段で伝えるようなリテラシが普及するのが解決につながると考えます。しかしそれに期待できない現状ではブックマーク自体を拒否したい、と考える人もいるのだろうと思っています。 今ふと、 Account-Auto-Discovery あたりを利用して「ブックマークされるのは構わないが、コメントを書かれるのは拒否したい」という意思表示ができないかなあと思いました。そこまで実装するとなると、システムとして複雑化しすぎるかもしれませんが。 3. についてはリンクは本来自由であるという認識を示した上で、「はてなブックマークのサーバを拒否すれば良い」というのは現実的かつ真っ当な対応だと思っています。 >mount-root-yy さん アイデア拝見しました。 確かに落しどころだとは思いますが、掲載自体はされても良いんじゃないかなと思います。 otsune さんへのレスを書いていて考えたことですが、「リンクは自由に行うもの」の理念に沿って、ブックマークされること自体を防ぐ策を準備しない、というスタンスでも問題はないかな、と。 私がはてなスタッフに気にかけて欲しいのは、「ブックマークコメントをされることを好まない」人であって、「無断リンクを是としない」人ではないので……。

2005-10-22T11:30+09:00 - rna

すみません、そもそも robots.txt ってコンテンツを被リンクから守るためのものなんですか? robotstxt.org のドキュメントを見てもロボット自身によるトラフィック増からサーバ資源を守るというのが目的のようですが。。。 リンクさせないことによる人間のトラフィックの制御まで robots.txt の守備範囲にするのは無理がないでしょうか。

2005-10-22T19:37+09:00 - yum

>今ふと、 Account-Auto-Discovery あたりを利用して「ブックマークされるのは構わないが、コメントを書かれるのは拒否したい」という意思表示ができないかなあと思いました。そこまで実装するとなると、システムとして複雑化しすぎるかもしれませんが。 はてなブックマークコメントも短いなりに「言論」ですし、また、ブックマークされる側が管理している場ではなく他人が管理する他人の言論の場ですよね。エントリー元に付随したものではないと考えますが、その点はいかがでしょうか。 そういう考え方で行くと、ブックマークされてもコメントは拒否しようというのは、ブックマークユーザの言論を封じることになりませんか。言論の自由・表現の自由を侵害する行為にあたり、基本的人権の重大な侵害です。当然、実装はまず無理でしょう。 自分に自由に文章を公開する権利があるように、他の人にもその文章に対して自由に言及する権利があります。それが言論の自由です。名誉毀損や個人情報の侵害等、別の問題が発生したときのみ訂正や削除を求めることができると考えます。自分は自由に書いてよい、しかし他人には物を書かせないのはおかしい。自分が公開の場で言ったことに対して、はてなブックマークも含めた「どこかの場」で誰かになにか言われたくないなら、自分も公開の場で物を言わないことしか根本的な解決はありません。 ブックマークコメントを制限しようと考えるのは人権侵害につながる考え方で問題のある、と、私は考えます。

2005-10-24T21:25+09:00 - 真琴

>rna さん あくまで ( 人間の目ではない ) UA がリソース内の情報を検索したり取得したりすることを防ぐためのものだと思っています。結果的に検索エンジンへの登録およびそこからのリンクを守ることになるかもしれませんが、リンクされること自体から守るものではありません。 otsune さんへのレスを返した際に私の考えを再整理しましたが、私が考える robots.txt で制御されるべき部分は、 1. Hatena Bookmark/0.1 がブックマーク先の内容を取得して、自動で設定する http://b.hatena.ne.jp/entrylist?cname=**** というカテゴリ 2. Hatena Bookmark/0.1 がブックマーク先の内容を取得して、自動で設定する http://b.hatena.ne.jp/keyword/**** というキーワード 3. Hatena Bookmark/0.1 がブックマーク先の内容を取得して、自動で生成する「概要」と称される転載部分 あたりだと考えます。 1. および 2. については今のところ被ブックマーク側にはそれを防ぐ手段はありませんが、 3. については <meta name="Hatena::Bookmark" content="noindex"> という手法がはてな側から提示されています。 meta で対応しているということは、少なくともはてな側も、「はてなブックマークは制作者側の制御意思をある程度受け付けるべきである」と認識しているのだと考えます。 だからこそ、 meta 要素で対応しているから robots.txt への対応は要らない、というのが不自然だと思ったのが今回の記事のきっかけです。 meta 要素による制御は <em>robots.txt の設置ができない場合に</em>行うものであり、またはてなブックマークが対象とするサイトは、その全てが robots.txt の設置ができないというわけではありませんので。 >yum さん はてなブックマークのコメント機能は言論ではないと考えます。「どのような感想をもっているか、どのような要約を行っているか」を自分のために記録するためのもので、他のユーザもそれを見ることができるようになっているだけにすぎません。 ( 参考 : http://hatena.g.hatena.ne.jp/hatenabookmark/20050222/1109076964 ) 仮にそういった「感想や要約」を言論であると仮定しても、自由であるはずのその言論が、はてな側が独自に定めた、たった 50 文字という基準に<em>制限</em>されていることについてはどうお考えですか ? また、はてなブックマークのコメント機能はサービス開始時には存在しておらず、後から付け加えられたものです。付け加えられる前の、無言で URI を記録する状態を、または今後何らかの仕様変更があってはてなブックマーク自体から撤廃された状態を「言論が封殺されていた / 封殺されている」と表現するのでしょうか。

2005-10-27T23:54+09:00 - 制作者から閲覧者へ、機械的に意図を伝える仕組み、汲み取る仕組み < Flagyx.blog

ブックマークのコメントは鋭鋒になりがちだね。「ブックマークされたくない」という人がいたら、どんな手段がとれるんだろう。

2006-10-16T21:51+09:00 - 天井冴太 (AmaiSaeta)

どうも、天井冴太と言います。初めまして。 yumさんと議論されているはてブのコメント欄の制限についてですが、私はするべきではないと思います。……いえ、言論の自由云々ではなく。 http://hxxk.jp/2006/05/08/2241 で真琴さんが話題に上げておられるように"via族"と言うのも存在します。彼らのようなブクマ先への言及以外でコメント欄を使う人がいることを考えると制限はナンセンスではないでしょうか。 #はてな側が想定していなかったと思われる利用法ですが、だからと言って無視していい訳では無いでしょうし。

2006-10-21T06:53+09:00 - itochan

robots.txtから派生して、 linkpolicy.txt みたいな仕様を作ったらどうでしょうか?

2006-10-21T12:50+09:00 - 真琴

> 天井冴太さん ええと、私自身はブックマークのコメント機能事態の制限は望んでいないですよ。自分でも積極的に活用していますし。 ブックマークによるコメントを好まない人もいるということを忘れずに、何らかの自衛手段があったらいいなあと思っているくらいで。 ( 特に meta 要素という次善策の方への対応を実装しているのですし。 )

2006-10-21T12:54+09:00 - 真琴

>itochanさん そういうのおアイデアとしてはいいかもしれませんね。ちょっと大仰な気もしますけど…… ちなみに、これだけ論をぶっていながらも、 hxxk.jp はブックマークも ブックマークコメントも大歓迎なので robots.txt は設定していなかったり。

記事中にちりばめられた関連記事への導線は辿られるのか

記事データ

投稿者

望月真琴

投稿日時

2005-10-19T23:33+09:00

タグ
概要

「リニューアルで古くなった URI を新しい URI にリダイレクト」自体には書かれていなかったために「説明されていない」と取られてしまったファイルごとのリダイレクト方法。しかし、その方法への導線は実はちりばめられていたのです。

リプライ

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

記事本文

自分のための記録であることと、第三者に対する配慮

hxxk.jp の作成の目的は「自分のための記録、備忘録」です。 もちろん、他人の記事に対して何かの意見を言ったりする記事もありますが、それも大きな視野で見れば「誰々の記事に対して感じたことを文字にして、『あの時の自分はこう考えていた』ということを確認できる」という記録になると言えるでしょう。

自分のために書いているのなら、その時は明確な答えを得られなかったことについても、後から解決の目を見たら古いものは「これはこないだ解決したもんなあ」で済ませればいいのですし、似たような話題を扱っている記事もおぼろげながら記憶に残っています。 よって、特段分類をしたり補記をしたりということはしなくても構わないという理論もできあがりますが、やはり自分の記憶だけでは全てをフォローできません。

そこで、 Movable Type のキーワード記録機能と Tagwire Plugin というプラグインを使って キーワードによる記事の分類を行っています。 また、このプラグインの機能を用いて、各個別記事には ( 同じキーワードが設定されているという意味で ) 「関連のある記事」をリストアップしています。 この分類や関連性というものには私の主観によるところが大きいのですが、それでも全くの未分類よりは私にとっても、またご覧になっている方にとっても便利であると信じています。

キーワードや「関連のある記事」も見て欲しい

何故、前項のようなことを再確認するように書き出したか。 たまたまリファラに HTTP 301ヘッダで、MT2.xのアーカイブからMT3.xのアーカイブにリダイレクトする :Heartlogic という記事があるのを見つけ、リニューアルで古くなった URI を新しい URI にリダイレクトが参考にされていることを知ったからです。

いや、参考にされたからそういったことを考えたというわけではなく、 ディレクトリごと移転する場合はこのようにすれば良いようだけど、「絶対パス」がどこのパスを指すのかイマイチ分からないし、ファイル1本ごとの場合も説明されていない。 と書かれていたからと言った方が正解に近いでしょうか。

確かにその記事内には直接 「 パーマリンクのURLの作られ方が違う 場合のリダイレクト方法」は書かれていません。 HTTP 301ヘッダで、MT2.xのアーカイブからMT3.xのアーカイブにリダイレクトする :Heartlogic の一つ前の記事に Web2.0時代に、ユーザーが経験しておくべき10のこと :Heartlogic という記事があり、 あらゆるリソースはリソース単位でランダムアクセスされる、ということの経験 とあるように、他の記事には書いている内容だったとしても、「その記事内」に書かれていなければ読まれない可能性があるというのも分かっています。

しかし、それをある程度考慮して、キーワードおよび「関連のある記事」による類似記事への到達性を高めているのだから、そこに少しでも目を向けて欲しかった、「関連のある記事」の部分に並べられたリンクアンカーから、あるいは記事の冒頭のデータ部分から htaccessリダイレクトというキーワードを見つけ、そのキーワードを集めたページから、デフォルトの個別エントリーアーカイブから URI を変更する場合の注意点に辿り着いて欲しかったと思いました。

または、もう一度言葉を借りるなら、 Q&Aサイト等で質問、回答をする ということをして欲しかったとも思いました。 hxxk.jp は Q&A サイトではありませんが、もし「ファイル 1 本 1 本ごとにリダイレクトする方法はありませんか ? 」と尋ねられていたら、喜んでデフォルトの個別エントリーアーカイブから URI を変更する場合の注意点を紹介したでしょう。

小林さん ( Heartlogic ) が辿り着いてくれなかったこと自体を非難するつもりはありません。 サイト内の記事全てに目を通して初めて 説明されていない という判断をするには手間がかかりすぎます。 ただ、辿り着いていてくれさえすれば、 百本以上のアーカイブ全部についてこのように新旧URLの対応を列記する という回りくどい方法を取らせることもなかったのになあ……という残念な思いから書きました。

各個別記事において、関連のある記事や検索フォームを活用していただく旨の注意書きを記述しました。

Movable Type 2.x 形式の Permalink から Movable Type 3.x 形式の Permalink にリダイレクトする方法

さて、既に解決しているようですが、折角なので簡単に Movable Type 2.x 形式の Permalink から Movable Type 3.x 形式の Permalink にリダイレクトする方法を解説しようと思います。 前項までで終わっていたら、私の単なる愚痴にしか見えませんし。

なお、 .htaccess の Redirect permanent ディレクティブを用いるため、 .htaccess を使える環境にあることが前提条件となります。 また、解説内の項目名は Movable Type 3.2-ja-2 を元にしています。

  1.  管理画面から「テンプレート」をクリックします。
  2.  「テンプレートを新規作成」をクリックします。
  3.  テンプレートの名前を適当な名前にし、出力ファイル名を .htaccess にします。テンプレートの中身に次のようなコードを記述します。
    <MTEntries lastn="1000">Redirect permanent <$MTBlogRelativeURL$>archives/<$MTEntryID pad="1"$>.html <$MTBlogArchiveURL$><$MTEntryDate format="%Y/%m/"$><$MTEntryBasename$>.html
    </MTEntries>
  4.  テンプレートを保存し、「このテンプレートを再構築する」をクリックします。

以前に Latest Entry Redirect Template で扱った、 .htaccess をインデックステンプレート化する方式と同じ手法です。 なお、既にローカルで .htaccess を作成してサーバ上に put していた場合は、テンプレート内にその記述も合わせて行うことに注意してください。 一緒に記述しないと、テンプレートの再構築時にその内容が上書きされて失われてしまいます

テンプレートのコードについていくつか説明します。 Movable Type 2.x のデフォルトの設定では、 Permalink には <$MTEntryID pad="1"$> で生成された値が使われています。 対して、 Movable Type 3.x のデフォルトの設定では <$MTEntryDate format="%Y/%m/"$><$MTEntryBasename$> で生成された値が使われています。 ( Movable Type 3.2 の「公開の設定」では yyyy/mm/entry_basename という表現になっていますが、テンプレートタグで表現するとこのようになります。 ) これらを MTEntries コンテナタグで囲み、 lastn を 1000 としてテンプレートを作れば、全ての記事の Permalink をリダイレクトするテンプレートができるというわけです。 ( もし記事の数が 1000 個以上ある場合は、 lastn の値を適宜増やしてください。 )

トラックバック送信先

HTTP 301ヘッダで、MT2.xのアーカイブからMT3.xのアーカイブにリダイレクトする :Heartlogic

既に解決しているようですが、折角なので簡単に Movable Type 2.x 形式の Permalink から Movable Type 3.x 形式の Permalink にリダイレクトする方法を書きました。

リプライ

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

2005-10-19T23:50+09:00 - 小林

こんにちは。なるほど、直で.htaccessを生成するという手もありますね。 私の場合、記事のインポート/エクスポートを行って記事IDが全部変わってしまっているのでこの手は使えなかったのですが、DBをそのまま移している場合等には使えますね。ためになりました。ありがとうございます。

2005-10-21T01:52+09:00 - 真琴

ああ、インポート / エクスポートをしていると確かに ID 変わりますね。まあ、 .htaccess の作成も既に終わられていたので、参考程度に読んでいただければ。 ちなみに、これと同じ考え方で、「常に最新の記事へリダイレクトさせる .htaccess 」を作ったりもできます。 ( 詳しい解説は http://hxxk.jp/2004/09/07/2128 にて。 )

引用文と cite 要素と cite 属性

記事データ

投稿者

望月真琴

投稿日時

2005-10-19T00:18+09:00

タグ
概要

引用元の情報を示す cite 要素および cite 属性のそれぞれの定義と、その使用方法について。

リプライ

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

記事本文

cite 要素か cite 属性を使うとより適切ですよ

<div class="quotetitle"></div><address></address> というように、適切な要素 ( または属性 ) が定義されているのにそれが使われていないので、適切な要素を使った方が良いですよ、というお話。 まずは仕様を見てみましょう。 HTML の現時点での勧告済み最新バージョンは XHTML 1.0: The Extensible HyperText Markup Language (Second Edition) ですが、要素ごとの詳細な解説は無いので HTML 4.01 Specification を見ることにします。

cite 要素を使う場合

cite 要素は、 Contains a citation or a reference to other sources. ( 引用か、他のリソースへの参照であることを示す。 ) のように定義されています。 引用を行った場合の引用元のリンクアンカーを <cite></cite> 囲んで使用する方法の他にも、引用を行っていない場合でも参考リソースを示す場合に使用するようになっています。

なお、 cite 要素による引用元の明示を行う位置については『blockquote要素の中に出典を示すcite要素を包含すべきか』に関する議論リンク集 @ CD にそれぞれの場合の利点や欠点がまとめられているので、是非ご一読されることをお勧めします。

cite 属性を使う場合

cite 属性は、引用部分であることを示す blockquote 要素または q 要素の属性として定義されています。 ( del 要素と ins 要素の属性としても定義されていますが、引用における用途とは少し違うので割愛します。 ) 属性の形式は %URI; とされており、 The value of this attribute is a URI that designates a source document or message. This attribute is intended to give information about the source from which the quotation was borrowed. ( この属性の値は、元文書あるいは元記事を指し示すURIである。 この属性は、当該の引用がどこから引かれたものであるかについての情報を提供することを目的としている。 ) のように定義されています。 引用を行った場合に、合わせて cite 属性で引用元の URI を示すことができます。

ちなみに、 cite 属性による引用元の明示がされていても、それをどう取り扱うかの実装は各ブラウザによって異なる点に注意が必要です。 CSS の :before 擬似要素や :after 擬似要素で引用元を表示することができますが、 IE は :before 擬似要素や :after 擬似要素自体に未対応、 Firefox は :before 擬似要素や :after 擬似要素によるテキストを選択してコピーするということはできないという制限があります。 ( Opera はコピーすることが可能です。 )

また、 Firefox の場合は引用元を拡張機能やブックマークレットで手軽に表示することができますし、 IE でも Bookmarklet - パソコン遊戯 - ナビゲーションなどのブックマークレットで引用元を表示することができますが、標準の機能としては提供されていません。 ( Mozilla Suite では提供されていたような気もします。 ) cite 属性で引用元を表示する場合は、文意を損なわない程度に a 要素によるリンクも併記すると良いでしょう。

ちょっとあれれ ? と思ったところ

この記事を書くことになった発端は あいにくgooブログでは div class が有効ではない為に、この部分をaddressタグに変更しました という文を目にして、 「何で address 要素なんだろ、 cite 要素を知らないのかなあ」 と思ったことです。 でもえっけんさん ( むだづかいにっき♂ ) ははてなブックマーク - むだの素R / 引用にて先月の引用論争関連の記事をいくつかブックマークされているし、知らないはずは無いと思うのですが……。 基本的な使いかた - goo ブログ - 利用可能なHTMLのタグ一覧にも cite 要素は明記されていますし。

えっけんさんが Firefox を使っているかどうか知らないけど、もし Firefox を使っているなら拙筆の Copy URL+ 紹介記事「選択箇所を blockquote 」の紹介記事を見てもらうといいなあ、記事中で cite 要素についても触れているし、と思ってトラックバックを送ろうと思ったのですが、「選択箇所を blockquote 」の紹介記事はえっけんさんにブックマークされていることに気付きました。

うーん、以前も似たようなことがあったけど、私の説明スキルはやはり低いのでしょうか……。 まあ、あくまでブックマークなので、冒頭部分だけ読んでクリップだけしている、という可能性もあるとは思いますが。

トラックバック送信先

引用タグ作成Bookmarklet(Win版IE用) : ポトフの散歩道 -北国tv

javascript:var url=location.href;var title=document.title;var linkTag ='<blockquote><div class="quotetitle"><a href=\''+url+'\'>'+title+'</a></div>'+document.selection.createRange().text+'</blockquote>';var x = prompt('',linkTag); ではなく、 javascript:var url=location.href;var title=document.title;var linkTag ='<blockquote><cite><a href=\''+url+'\'>'+title+'</a></cite>'+document.selection.createRange().text+'</blockquote>';var x = prompt('',linkTag); とした方が構文的にはより正しいと思います。

むだづかいにっき♂:引用文作成用ブックマークレット

引用元へのリンクには、文書自体の問い合わせ情報を示す address 要素を使うべきではありません。引用元の情報を示す cite 要素または cite 属性を使うべきです。

リプライ

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

2005-10-19T18:59+09:00 - えっけん

citeを使わなかった理由です。 僕はW3Cに対するこだわりが無いのですが(拘っていたらgooブログは使えません)、これまでの引用方法では、citeを使っていました。 ところが、このブックマークレットを使うと、インラインタグであるciteを使うと、そのあとに改行タグを入れなければなりません。 何回かciteタグで括るのも試したのですが、gooブログの仕様で、改行タグを入れた文章を再編集すると、その改行タグが消失してしまうのです。 割と頻繁にアップした記事の訂正を行うものですから、cite+brを使うのは得策ではないな、と考え、苦肉の策としてaddressタグを使うことに。 但し、ちょっと工夫すればciteを使っても何とかなりそうなので、もうちょっと試行錯誤してみることにします。

2005-10-19T20:35+09:00 - えっけん

Firefox導入も考えたのですが、使い慣れたあんドーナツを離れられそうにも無いので、いろいろ考えていて、ようやく分かりました。 gooブログは公式発表は無いけれど、Pタグが使えるようになっていたはずなので、citeタグをPタグで括ればいけるような気がします。 ありがとうございました。

2005-10-19T20:53+09:00 - えっけん

citeをpで括ればうまく行きましたよ!! gooブログでpタグが使えるようになったことは公式発表されていないのですが、いつかの仕様変更以来、こっそり使えるようになっていたのを忘れていました。 ブックマークレットをいじって、大丈夫な事を確認! 後日、訂正文を追記します!

2005-10-21T01:46+09:00 - 真琴

> 改行タグを入れた文章を再編集すると、その改行タグが消失してしまう それは仕様というより不具合というのでは……。 で、下の方で解決しているので今更言ってもしょうがないのですが、 W3C の仕様が云々ということを考えなくても address を使うというのはどうかと思いました。 「とりあえず address は使えるから使う」というのは、極端な話「トラックバックて宣伝行為に使えちゃうんじゃね ? それなら使っちゃおう」という考えと同じじゃないのかな、と。 煽りを交えて言っちゃうと、えっけんさんらしくないなあ、と一回目のコメントの時は思ったのです。 最終的によりベターな方法を取られたので、その心配は無用に終わりましたが。 > gooブログは公式発表は無いけれど、Pタグが使えるようになっていた p 要素が ( 公式発表上では ) 使える要素の中に無いってすごいですね……

全面リニューアルのお知らせ

記事データ

投稿者

望月真琴

投稿日時

2005-10-17T02:53+09:00

タグ
概要

Movable Type のテンプレートを全て一新し、合わせて CSS も新しくしました。いくつか問題点を残したままにしているので、ここにメモして随時対応しようと思います。

リプライ

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

記事本文

とりあえず報告まで

Movable Type のテンプレートを全て一新し、合わせて CSS も新しくしました。 新しいテンプレートは、 Web Standards with MT ver.3.2 Strict テンプレートの予告で存在を匂わせていたテンプレートと同じものを hxxk.jp 向けにカスタマイズしたもので、近いうちに一般向けのバージョンを配布用として公開するつもりです。

残っている問題点その 1 - IE でだんだん左にずれていく

 これは Internet Explorer (Windows) CSSバグリスト - 左右ボーダーとパディングを設置した要素に後続する部分がずれるの事象と同じなので、対応は取りやすいと思います。 近日中に対処するつもりです。 対処しました。 IE でもずれなくなりました。

残っている問題点その 2 - IE で謎の border

 dt には border-bottom を設定しているのですが、 dl.metadata dt ではその border-bottom を打ち消すようにしています。 ……が、何故か IE 6.0 では意図せずに残ったまま。 もしかしたら前項のバグリストに載っているかもしれませんが、すぐに思い出せないので、当分そのままにしておきます。 色々試してみたけど解決できず……。

残っている問題点その 3 - DisableSidebarForHxxkJp に変更を加えてもらう必要がある

hxxk.jp - Disable sidebar for hxxk.jp で紹介した、 hxxk.jp のメニュー部分の表示 / 非表示をワンクリックで切り替えられる Greasemonkey スクリプトですが、今回 CSS も新しくしたため、変更を加える必要があります。 現在、ちょうど DisableSidebarForHxxkJp が公開されているサーバが停電のため稼動していないということで、スクリプトがどのように書かれていたかの確認はできませんが、メニュー部分を display:none; にして、メニュー部分だけ margin を取っていた分を広げるようなものになっていたと思います。

新しい CSS では、メニュー部分は dl#menu でグルーピングしており、かつ次に羅列する width:70%; としている部分の width を 100% ないしそれに近い値にすれば良いと思います。

  • p#hierarchical-menu
  • ul#common-navi
  • h1
  • ul#directories
  • dl#description
  • div.section
  • dl#footer

リプライ

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

2005-10-19T13:27+09:00 - ちはや(智猫)

真琴さん、全面改装お疲れ様です。 IEというかIEHTMLレンダリングエンジン使用のブラウザ(というかWrapper?Dunut系やIEコンポーネント時のlunascapeやSleipnirその他)で見ると凄いですね……縦線横線が縦横無尽に…… エントリーの文章も左寄りにはみ出して見えますし(余計なボーダーのせい?)。リンクを張った文面などがあるとそこをマウスカーソルを通すとその行だけ想定している位置を思われる右にずれたりと(IEでは良くあること……(苦笑)) Firefox1.07で見るとすっきりしてるのに…… うちはIE用Wrapper的ブラウザやFirefoxでもブックマークを完全に共有してるので、IE,DonutRapt,Firfoxのどれで閲覧しても良いんですがー(笑) でも、ちょっとだけでも解消してもらえると嬉しかったりします。

2005-10-21T01:33+09:00 - 真琴

左にはみ出したり、リンクアンカーがいきなり元の位置に戻ったりする方は対処完了しました。 もう一つの問題の dl.metadata に謎の横線が出る問題は解決の糸口がつかめていません……。

高橋名人 on Stage

記事データ

投稿者

望月真琴

投稿日時

2005-10-14T23:03+09:00

タグ
概要

ポップジャムに高橋名人が出演しますよ !

リプライ

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

記事本文

テレビのスイッチを 16 連射せよ !

見なきゃ見なきゃと思いつつ IRC で言われるまですっかり忘れていましたが、今日 ( カレンダー的には明日か ? ) のポップジャムに高橋名人が出演しますよ !

ところで、今日の深夜にポップジャムの放送があります。 前回にも紹介したとおり、「スターソルジャー」のテーマを使って、「何か」をしてみましたので、見られたら見てくださいね。 こんな事もできるんだと、気がつかれる方もいらっしゃると思いますよ。

ということで、どんなステージになるか予想もつきませんが、興味が湧いた方は是非どうぞ。 某所で「高橋名人に似てるよね ? 」と言われた真琴からのお知らせでした。 それは喜んでいいのか悪いのか。

リプライ

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

動画対応 iPod 発表に伴う旧 iPod とのスペック比較

記事データ

投稿者

望月真琴

投稿日時

2005-10-14T19:38+09:00

タグ
概要

「きっと比較表を作るだろう」と思っていた貴方 ( 誰 ) 、正解です。 2005 年 10 月 13 日に発表された動画対応の新 iPod と、 2005 年 6 月 28 日に発表された旧 iPod のスペック比較表を作りました。

リプライ

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

記事本文

iPod の新バージョンは動画対応

[☆] 新iPodは動画対応以外にも多くの weblog やニュースサイトで取り上げられていますが、 Bloglines で Keep New にしていたのでここをニュースソースとさせていただきます。

この動画対応についての詳細などには触れませんが、いつものごとく旧バージョンとのスペック比較表を作りました。 「きっと比較表を作るだろう」と思っていた貴方 ( 誰 ) 、正解です。 これもいつも言っているのですが、新モデルや新バージョンが出たら、旧来のものの仕様が見られなくなるのはどうにかして欲しいです。 そのおかげで (?) こうしてネタには困らないわけですが……。

旧 iPod と 新 iPod のスペック比較表

  旧 iPod (20GB) 旧 iPod (60GB) 新 iPod (30GB) 新 iPod (60GB)
発表日 2005 年 6 月 28 日 2005 年 10 月 13 日
価格 32,800 円 45,800 円 34,800 円 46,800 円
カラーバリエーション
  • ホワイト
  • ホワイト
  • ブラック
容量、曲数 20GB (5,000 曲 ) 60GB (15,000 曲 ) 30GB (7,500 曲 ) 60GB (15,000 曲 )
バッテリー駆動時間
  • 音楽再生時間 : 最長 15 時間
  • BGM 付きフォトスライドショー再生時間 : 最長 5 時間
  • 音楽再生時間 : 最長 14 時間
  • スライドショー再生時間 : 最長 3 時間
  • ビデオ再生時間 : 最長 2 時間
  • 音楽再生時間 : 最長 20 時間
  • スライドショー再生時間 : 最長 4 時間
  • ビデオ再生時間 : 最長 3 時間
ディスプレイ
  • 2 インチ ( 対角 ) カラー LCD
  • LED バックライト付き
  • 220*176 ピクセル
  • 65,536 色
  • 2.5 インチ ( 対角 ) カラー LCD
  • LED バックライト付き
  • 320*240 ピクセル
  • 約 26 万色
本体入出力ポート
  • Dock コネクタ
  • ワイヤードリモコン用コネクタ
  • ステレオヘッドフォンジャック
  • オーディオおよびコンポジットビデオ出力 ( ヘッドフォンジャック経由 )
  • Dock コネクタ
  • ステレオミニジャック
  • オーディオおよびコンポジットビデオ出力 ( ステレオミニジャック経由 )
接続方法
  • FireWire 400
  • USB 2.0 ( Dock コネクタ経由 )
  • コンポジットビデオ
  • オーディオ出力 ( ヘッドフォンジャックまたは iPod with Color Display Dock のライン出力経由 )
  • USB ( Dock コネクタ経由 )
  • コンポジットビデオ ( AV ケーブル ( 別売 ))
  • オーディオ出力 ( ヘッドフォンジャックまたは iPod Universal Dock ( 別売 ) のライン出力経由 )
充電時間 約 5 時間 ( 3 時間でバッテリー容量の 80% を高速充電 ) 約 4 時間 ( 2 時間でバッテリー容量の 80% を高速充電 )
オーディオフォーマット
  • AAC ( 16 ~ 320Kbps )
  • プロテクト付き AAC ( iTunes Music Store から購入 )
  • MP3 ( 16 ~ 320Kbps )
  • MP3 VBR
  • Audible ( フォーマット 2、3、4 )
  • Apple lossless
  • WAV
  • AIFF
Photo サポート
対応フォーマット
  • JPEG
  • BMP
  • GIF
  • TIFF
  • PSD ( Mac のみ )
  • PNG ( iPod で表示可能なサイズに変換 )
ビデオサポート 未対応
対応フォーマット
  • H.264 ビデオ ( 最高 768Kbps 、 320*240 、毎秒 30 フレーム、最高レベル 1.3 のベースラインプロファイル (最高 160Kbps の AAC-LC ) 、 48kHz 、 .m4v/.mp4/.mov ファイルフォーマットのステレオオーディオ
  • MPEG-4 ビデオ ( 最高 2.5Mbps 、 480*480 、毎秒 30 フレーム、シンプルプロファイル ( 最高 160Kbps の AAC-LC ) 、 48kHz 、 .m4v/.mp4/.mov ファイルフォーマットのステレオオーディオ
サイズ 103.5*61.8*16.1mm 103.5*61.8*19.1mm 103.5*61.8*11mm 103.5*61.8*14mm
重量 166g 183g 136g 157g
付属ソフトウェア
  • iTunes for Mac
  • iTunes for Windows
付属アクセサリ
  • インナーイヤー型ヘッドフォン
  • AC アダプタ (USB)
  • USB 2.0 ケーブル
  • インナーイヤー型ヘッドフォン
  • USB 2.0 ケーブル

新バージョンには 30GB モデルと 60GB モデルの 2 つがありますが、バッテリー駆動時間が異なるようです。 また、旧バージョンと新バージョンでの違いとして目立つのが、アクセサリやポートが減ったことでしょう。

  • ワイヤードリモコン用コネクタが無くなった
  • FireWire 400 による接続方法が無くなった
  • AC アダプタ (USB) が付属しなくなった

また、アクセサリ等が減りましたが、価格は旧バージョンより若干高くなっています。 ( これは 日本は為替の関係で価格改定がありました ということで、アメリカでの価格は同一のままだそうです。 ) ただし、従来の 20GB モデルは 30GB モデルに刷新されているため、お買い得になっていると言えるかも。 あと、 iPod U2 Special Edition はラインナップから消えているみたいですね。

リプライ

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

Movable Type 3.2x と Recent Reaction template

記事データ

投稿者

望月真琴

投稿日時

2005-10-13T22:55+09:00

タグ
概要

拙作の Recent Reaction template ですが、 Movable Type 3.2x で使う場合は Movable Type 3.2-ja-2 へのアップデートと、 recently_pinged_on Plugin の ver.0.18 以降のインストールが必要です。

リプライ

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

記事本文

Recent Reaction template が使えなくなっていました

Movable Type 3.2-ja-2 へのアップデートを無事に済ませたわけですが、拙作 Recent Reaction template ver.3 が実は使えなくなっていたという事実が。

前回のアップグレードで、3.17時代の Recent Reaction テンプレートがrecently_commented_onの問題で使えなかったのですが、今回の3.2-ja-2で解決しとりました。

「 Movable Type 3.2-ja にしたら Recent Trackback 部分のテンプレートがおかしくなっているなあ」とは思っていましたが、その部分だけ 3.2-ja としての再構築はしないようにして凌いで、問題解決を先送りにしていました。 そこで MT3.2-ja-2にアップグレード - LIPPiN を見て「 Movable Type 3.2-ja-2 にもアップデートしたしそろそろやんべえか」と思ってもう一度再構築してみたのですが、やはりおかしいまま。 本当なら「トラックバックを受け付けた記事のみを抽出」して、「トラックバックを受け付けた時刻の順」に並べて、「トラックバックを受け付けた記事を親として、寄せられたトラックバックをその子としてツリー状に」並べるはずが、トラックバックを 1 件も受け付けていない記事までリストアップしています。

何故だ ! ちゃんと 3.2-ja-2 のシステムの plugins ディレクトリに recently_pinged_on Plugin もインストールしているのに ! ( Movable Type 3.2-ja をインストールした際に、アップデートではなく別ディレクトリに新規インストールしたので、プラグインの入れ忘れを別件でやらかしていたのです。 )

……って、 Ogawa::Memoranda: recently_pinged_on Plugin にて Movable Type 3.2で正常に動作するように修正 という追記がなされていますね。 私が入れた分は以前から使っていたものだったので、修正されたバージョンのものを新たに入れ直して解決。

Movable Type 3.2x における Recent Reaction template の対応

ということで、以下の条件を満たしておけば、 Movable Type 3.2x 環境でも Recent Reaction template ver.3 のコードを元に作られたテンプレートのコード自体には特に修正の必要はありません。

  • recently_pinged_on Plugin の ver.0.18 以降を plugins ディレクトリに put している。
  • Movable Type 3.2-ja-2 にアップデートしている。

プラグイン作成者の (o) さん ( Ogawa::Memoranda ) とテンプレートの使用報告者の lego さん ( LIPPiN ) に感謝しつつ、プラグインを前提にしたテンプレートを公開しているならプラグインのバージョンくらいチェックしろと自分に言い聞かせて了。

リプライ

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

Movable Type 3.2-ja-2 にアップデートしました

記事データ

投稿者

望月真琴

投稿日時

2005-10-13T22:18+09:00

タグ
概要

recently_commented_on や Berkeley DB 環境における MTEntryNext などに不具合を抱えていた Movable Type 3.2-ja ですが、バグフィクス版がリリースされたのでアップデートしました。また、その手順をメモしておきます。

リプライ

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

記事本文

Movable Type 3.2-ja と Movable Type 3.2-ja-2 の違い

Movable Type 3.2-ja では recently_commented_on や Berkeley DB 環境における MTEntryNext などに不具合があることがリリース後に浮き彫りになっていましたが、それを修正した Movable Type 3.2-ja-2 の提供が開始されました。 以下、プレスリリースから変更点を引用します。

  • Berkeley DB環境にて、エントリーの投稿を行うと MTEntryNextなどのナビゲートリンクが消える不具合を修正しました。(ooba, ogawa)
  • Berkeley DB環境にて、再構築時におけるメモリー使用量の増加により、再構築できない現象が発生する不具合を修正しました。(ogawa)
  • recently_commented_onの処理により、パフォーマンスが低下する現象を修正しました。

不具合対応のためのリリースなので、バグフィクスのみとなっています。 Movable Type 3.2-ja-2 での新機能はありません。

Movable Type 3.2-ja から Movable Type 3.2-ja-2 へのアップデート手順

xrea サーバで、 MySQL を使用した場合のアップデート手順です。 Berkeley DB についてはバグフィクスが当てられていますので、もしかしたら違う手順が必要になるかもしれません。 あくまで私の環境において成功した手順ということで。

  1. Six Apart - Movable Type: ダウンロードから、所持しているライセンスに沿って Movable Type 3.2-ja-2 アーカイブをダウンロードします。
  2. greenplastic.net: Movable Type 3.2日本語版 Release-2小粋空間: Movable Type 3.2-ja-2 リリースを参考にして、次のファイルをサーバに put します。
    • install directory\lib\MT\ObjectDriver\DBM.pm
    • install directory\lib\MT\Template\ContextHandlers.pm
    • install directory\lib\MT.pm
    • install directory\mt-static\docs\mtchanges.html
    • install directory\php\mt.php
  3. 再構築を行って、 <$MTVersion$> の部分が 3.2-ja-2 の表示になっていれば OK 。

リプライ

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

Bloglines のちょっとした仕様変更

記事データ

投稿者

望月真琴

投稿日時

2005-10-13T19:06+09:00

タグ
概要

Bloglines の My Feed 画面に小さな仕様変更が行われました。しかし、小さいとはいえなかなか便利な仕様変更だと思っています。

リプライ

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

記事本文

これまでの仕様

今日の何時ごろかは分かりませんが、午前中くらいに Bloglines の My Feed 画面にて仕様変更があったようです。 少なくとも午前 3 時頃までは変更があっていなかったのを確認しました。 いやいつもはそんな時間までは起きていないんですけど、ちょっと仕事がたてこんで自宅作業していたというかまあそんなことはどうでも良く。

で、どういった仕様変更かと言いますと。 これまでは Keep New をチェックして未読状態を保っていた記事の数を、 weblog ごとに表示していたんですね。 たとえば hxxk.jp の Feed を Bloglines でチェックしていたとして、未読のままにしておきたくて Keep New にチェックを入れた記事が 5 つあったとすれば、 hxxk.jp (5) のように表示されていました。

しかし、この未読状態を保っている weblog に新規の記事が投稿された場合、「未読状態の記事の数 + 新規記事の数」が表示されることになります。 たとえば新規の記事が 1 つ hxxk.jp に追加されたとしたら、 5+1 で hxxk.jp (6) というように。 意図的に未読にした記事も、新規の記事も、どちらも未読状態であることには変わりないので、その動作がおかしいということではありませんが、「この数のうち、いくつが新規記事なんだろう」と思うことはよくありました。 今までに意図的に未読にした記事の数を覚えていれば問題はないかもしれませんが、全部覚えている方はいないでしょう。 貴方は今までに食べたパンの数を覚えていますか ?

新しい仕様

さて、では新しい仕様はどういったものか。 先ほどのように、意図的に未読にしている記事の数を 5 つ、新規に追加された記事を 1 つとしましょう。 すると、 Bloglines の My Feed 画面では hxxk.jp (1:5) のように、「 weblog 名 (新規記事の数:意図的に未読にしている記事の数) 」という表示がされています。 これにより、意図的に未読にしている記事の数が多いユーザでも、新しい記事のチェックをスムーズに行うことができると思います。

なお、この仕様変更はフォルダに対しても行われているため、特に更新頻度の高い Feed だけ特定のフォルダにまとめておいたり、意図的に未読にすることが多い Feed だけ特定のフォルダにまとめておいたりすると便利かも。

Bloglines とブックマーク

ところで、この Keep New を使って「意図的に未読」にしてブックマーク代わりにしている方ってどれくらいいるんでしょうかねえ。 私は Feed を講読しているものについては SBM を使わずに、この機能をフル活用しているのですが、もしかして少数派なのかしら。

そして Feed を講読していないものでは SBM を活用しているかというとそうでもなく、記事として取り上げたりブラウザ自体のブックマークに登録したりしているので、やはり SBM はあまり活用していないという結論に。 SBM 自体は嫌いじゃないどころかむしろはてブラヴな勢いなんですけどね、自分じゃあまり使わないというだけで。

リプライ

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

サイトの影響力って ?

記事データ

投稿者

望月真琴

投稿日時

2005-10-11T22:52+09:00

タグ
概要

サイトの影響力、っていう目に見えない存在について考えてみましたが、それってどう定義されるものなのか、どう測るものなのか難しいというつぶやき。

リプライ

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

記事本文

面白そうな質問

人力検索はてなで ( 寄せられた回答を眺めるのが ) 面白そうな質問があったので、私なりの回答をしてみました。 私の場合は「影響力」を一つの指針として回答していますが、既に他の人がされている回答や、これからされるであろう回答と比較して読むとまた面白さが増すかもしれません。

質問者に興味、そして意外なつながり

この質問を行ったのは id:catfrog さんかあ、どんな人だろう、という疑問を持ちましたが、そういえばはてなブックマークでブックマークコメントも合わせて読むためか、この ID を見かけたことが何度かあります。

自分のサイト関連でもブックマークコメントされていたっけな……と思って catfrogのしっぽ内を検索してみましたがヒットしません。 どうもよく見受ける = ブックマークされたことがあると勝手に思い込んでいたようです。

しかしつながりが見つかりませんでした、それだけじゃ悔しいので「好むと好まざるとにかかわらず hxxk 」で Google 検索してみました。 無理矢理つながりを作るというか、これまで話したことの無いあの人に何とか話すきっかけをと思って薄い共通点を探すようなそんなアレ。 そこで一件目に見つかったのが RERO!! - 「はてなブックマークを代表するような日記」について

へええ、こういうネタがあったのか……というのがまず最初の感想で、で「何故そんなネタで hxxk がヒットするんだ ? 」と思って下の方まで見ていると、 hxxk.jp も含まれていたんですね……全然知りませんでしたというか、まさかこういうリストの中に入っているなんて全然思いもしませんでした。 一定期間以上継続をして、かつある程度のアクセスを得るようになると、良くも悪くもそれなりの「影響力」を持つようになると思います。そして、その影響力を少なからず自覚しているというのが、一人前としての判断の一つの指針となるのではないかと思います なんて偉そうに回答したくせに全然自覚ないじゃん、という。 いやこのリストに入る = 影響力がある、と直結するのは危険な気もしますが。 はてブバイアス ( ←今考えました。ブバイアスって何かの名前みたいだなあ ) がかかった状態のリストですし。

自サイトにひきこもるから、よそのことが分からない ?

あと個人的に興味深かったのが、これらの 158 サイト中、自分が熱心に読んでいるのは 6 サイト、 Feed を講読して、概要やタイトルでぐっと来た時に読むことがあるのが 13 サイト、残りは全く知らなかったか、名前程度しか知らないサイトという事実。 元来「有名どころだから」という理由では定期的に読むサイトに分類せず、何かしら自分のサイトに関連があるとか、リンクやコメントやトラックバックで知ったサイトを定期的に読むようにする、ある種自サイトひきこもり状態だったのを目の当たりにさせられた感じです。

自分はこのリストに挙がっているサイトの大部分を知らないわけだけど、「代表するような~」と銘打たれているからには「有名どころ」と呼ばれるサイトで、ある程度の影響力のあるサイトなのでしょう。 そして、その影響力はおそらくは ある程度継続して 良質の記事を書いて、それによって ある程度アクセスがある 状態になったために生じたものだと思います。

じゃあ、その「影響力」を測る指標は何なんだろうと。 そんなの簡単に数値化できるもんじゃないと認識しつつも疑問に思ったのです。 もしかしたら、自サイト関連以外にも目を向けてもっと広い視野で多くのサイトを見ていれば、その見えない指標が見えてくるのかもしれませんが。 ……自分で回答に「影響力」という言葉を使いましたが、その定義や大きさの指標が実は分からないのでは、回答としては不十分ですね。 ブロガーとして一人前 と判断できる指標のまとめがいずれ好むと好まざるとにかかわらずでまとめられるかもしれませんので、楽しみに待っておこうと思います。

……と、こうしてはてなの質問を通じて他人に宣伝記事を書かせてしまう、というのもひとつの影響力なのかな、と最後に思いつきました。

トラックバック送信先

はてな 「半年以上継続」かつ「アクセス数累計が一万以上」のブログを運営している方にお聞きします。「これを経験してるとブロガーとして一人前」と言えるよ・・

回答の補足……というか、回答をしたことによって生じた疑問を逆にぶつけるような、そんな回答者からのつぶやき。

リプライ

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

2005-10-12T00:23+09:00 - laiso

件のリストの「代表するような」というのは http://d.hatena.ne.jp/keyword/%A4%CF%A4%C6%A4%CA%A5%C0%A5%A4%A5%A2%A5%EA%A1%BC%A4%F2%C2%E5%C9%BD%A4%B9%A4%EB%A4%E8%A4%A6%A4%CA%C6%FC%B5%AD からの借用ですのでとくに意味はありません。 実際、このリストはブックマークされる確率や総ブックマーク数ではなく、20users以上のブックマークがいくつあったかでリストが変動してますので、サイトごとの影響力と言うよりは「記事個別の注目度」を集約したリストのような感じになってます。

2005-10-12T00:29+09:00 - laiso

表題の「代表するような」は http://d.hatena.ne.jp/keyword/はてなダイアリーを代表するような日記 からの借用なので特に意味付けはないです。 実際、件のリストもサイトのブックマークされる確率やブックマーク総数から算出したものでもなくて、20userd以上のブックマークがあったエントリがいくつあるのかを基準にして出ていますので、サイト自体の注目度,影響力というより「個々の話題になった記事」をサイト単位で集約したカタチになっています。

2005-10-12T00:31+09:00 - laiso

表題の「代表するような」は「キーワード『はてなダイアリーを代表するような日記』」からの借用なので特に意味付けはないです。 実際、件のリストもサイトのブックマークされる確率やブックマーク総数から算出したものでもなくて、20userd以上のブックマークがあったエントリがいくつあるのかを基準にして出ていますので、サイト自体の注目度,影響力というより「個々の話題になった記事」をサイト単位で集約したカタチになっています。

2005-10-12T00:31+09:00 - laiso

表題の「代表するような」は「キーワード『はてなダイアリーを代表するような日記』」からの借用なので特に意味付けはないです。 実際、件のリストもサイトのブックマークされる確率やブックマーク総数から算出したものでもなくて、20ユーザー以上のブックマークがあったエントリがいくつあるのかを基準にして出ていますので、サイト自体の注目度,影響力というより「個々の話題になった記事」をサイト単位で集約したカタチになっています。

2005-10-12T00:39+09:00 - 「はてなブックマークを代表するような日記」について。について < memo::laiso

コメント5回エラー出て泣きそうだったのでコピペしてTBで代用。半角文字全部無くしてみたりしたんだけど、ブラウザの設定か何かで引っかかっているのかなぁ。 ...

2005-10-12T00:58+09:00 - 真琴

トラックバックにもありますが、コメンターからはエラーに見えているけれどその実しっかりと登録されている謎。今日から Movable Type 3.2 に全面移行したのが明らかに臭いので、どうにかしないとなあ……。 フィルタ関連のプラグインは何もいじっていないので、何か別の要素だと思いますが、参考までにどういったエラーメッセージだったかを教えていただけると幸いです。 ( ここはまたエラーになるかもしれませんから、 http://d.hatena.ne.jp/hxxk/ あたりで。 ) で、本題ですが、「代表するような~」がキーワードから名づけられたというのは知りませんでした。 集計方法については http://private.ceek.jp/archives/001443.htmlhttp://labs.ceek.jp/hbr/ も合わせて見たので、「サイト自体 ( あるいは全体 ) 」の注目度や影響力ではないとは思っています。しかし、やはり耳目を集める記事を複数書けるというのは、やはり何らかの光るものを持っているのだろうなとも思います。 コメントエラーでは何度もお手間をかけて申し訳ありませんでした。なるべく早めに問題を解決したいと思います。

2005-10-12T01:03+09:00 - 真琴

コメントは即時公開にしているはずなのに、何故か自分のコメントは保留状態に……謎。

2005-10-12T01:04+09:00 - 真琴

あ、一度コメントしたら OK なのか。……でも、 laiso さんの一回目のコメントは保留にならなかったし…… ???

Web Standards with MT ver.3.2 Strict テンプレートの予告

記事データ

投稿者

望月真琴

投稿日時

2005-10-10T01:12+09:00

タグ
概要

Web Standards with MT ver.3.2 Strict テンプレートの配布の予告と、構造をストイックにすることの有効性について。

リプライ

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

記事本文

予め設定された class や id

Movable Type 3.2 のデフォルトテンプレートの酷さは Movable Type 3.2 Beta 2 の華麗な div 捌きを見よ ! で述べた通りですが、 Movable Type 3.2 の Style Library と hxxk.jp の CSS でも触れた通り、 Style Library があるためにテンプレートの構造を変更するカスタマイズに踏み切れなくなってしまう人が出る可能性があります。

そういうことを考えていたら、 tDiary の元ユーザからも同様のことが、 nulog > 2005 > 10 > 03 - CSS をテーマにするのはいいけれど @tDiary で触れられていました。

構造が気持ち悪い。 とりあえず tDiary の話。 はてなにも言えるけどはてなはソースを変えられない時点で「諦め」があるので論外。

tDiary には CSS によるテーマ機能があって、(たぶん) それがウリなんだろうけど、そのせいで構造が変えにくい。 「変えにくい」ってのはテーマを使いたいからでなく、スキンファイル*1 が難読になっていたり、プラグインの吐くソースがキモかったりする。 「どうせテーマを使ってもらうんだから構造は決めうち。スキンファイルは開発側が編集できればいいや」 みたいな。

デフォルトの状態であれこれ class やら id やらが無節操に振られていると、それに合わせた CSS を書かなければならず、またそうやって書かれた CSS を使用してしまったら、それを適用する HTML の構造は容易に変えられなくなります。

だったらどうすれば良いか。 構造をできる限りストイックなものにして、 CSS は class セレクタや id セレクタに頼りすぎないようにすれば良いと考えました。 そうすれば、例えばある人が後から 「自分はこの部分を <div class="hoge"></div> で囲んで、 div.hoge{ color: #ffe; } という指定をしたいな」 というようにカスタマイズをしたいと思っても、自分で書き加えれば済みます。 少なくとも既存の CSS との兼ね合いを考える可能性はぐっと低くなるはず。

Movable Type のテンプレートを作ってみた

ということで、できる限りストイックに、というコンセプトで Movable Type のテンプレートを書いてみました。 いやまあ nulog > 2005 > 10 > 03 - CSS をテーマにするのはいいけれど @tDiary を目にする前からテンプレートの構想はあったのですけど。 ちなみに、全く class を設定しないという縛りを自分に課してみようかとも思いましたが、使った方が良い部分まで制限するのはどうかと思い、最低限は使用しています。

  • 各テンプレートごとの body 要素に、それぞれのテンプレートを表す class 名
    • main-index
    • master-archive-index
    • category-archive
    • date-based-archive
    • individual-entry-archive
    • comment
    • search
  • h2 レベル以下の見出しが属する div 要素に section
  • 記事アーカイブを内包する div 要素に entries 、個別記事を内包する div 要素に entry
  • 記事ごとのメタデータを記述する dl 要素に metadata
  • アーカイブテンプレートにて、前後のページおよび上位カテゴリへのナビゲーションを行う ul に navigaton

もう少し子セレクタなどをうまく活用すれば、 metadata と navigation の 2 つの class は指定しなくても良くなるかもしれません。

まだ配布はしません

この Movable Type テンプレートは近いうちに配布をしようと考えていますが、まだ完成形ではありません。 もう少し HTML の構造や見出しの扱いに検討の余地がありそうなので、配布を行う前にサンプルの方を公開して、自分じゃ気付いていない点を指摘していただこうと思っているからです。

ということで、 Web Standards with MT ver.3.2 Strict のサンプルページを見て、突っ込みどころを見つけられたストリクタの方々は、 Web Standards with MT ver.3.2 Strict : この構造やマークアップが変だよ、などのご意見はこの記事へ。へコメント等でご意見いただけると幸いです。

リプライ

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

Movable Type での、受信したトラックバックの取り扱い方

記事データ

投稿者

望月真琴

投稿日時

2005-10-07T19:23+09:00

タグ
概要

Movable Type や一部の weblog サービスでは、受信したトラックバックがどの記事に向けられたものか分からない ! 実は Movable Type ではプラグインを導入することですっきり解決できます。

リプライ

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

記事本文

うんうんとうなずいたトラックバックスタンス

Dullahan さん ( 脳無しの呟き ) なりのトラックバックに対するスタンスの分かりやすいまとめ。 言及しても内容的に薄ければ、TrackBack はしない とか うなずきレベルのエントリは、恥ずかしいから絶対に TrackBack なんてしない とかいう下りは、こうしてキーボードに指を踊らせて記事を仕立て、思わずうなずきトラックバックを送ってしまいそうになるほど同意。あと明確には書いていないけれど、トラックバックを送る際の概要を、本文冒頭からの自動生成ではなく分かりやすく手動編集されている点にも同意。 ( 例 : 検索ロボットの CSS ファイルのクロールについてと、それを拒否する手段へのトラックバック ) って、同意て言いながらうなずきトラックバックを送るって、それ同意した内容に矛盾しますから !

Recent Trackback の罠

いやまあそんな自己ツッコミをしたくてわざわざ記事を一つ書きたかったわけではなく。 気になったのはこの部分。

このブログでは、右のカラムに受け付けた TrackBack を表示するようにしております。 TrackBack 元のエントリを表示する仕様なのだけど、よくよく考えてみると、これって「言及リンクあり」が前提の仕組みなんですよね。 というのは、右帯に表示されているリンクからは、どのエントリに TrackBack があったのかわからないのですよ。 TrackBack 先のエントリ(ブログ)を見て、初めて「どのエントリに TrackBack があったかわかる」のですな。

ここを見ている人がトップページを閲覧中、右帯にある TrackBack に気が付いたとしましょう。 興味が湧いてクリックしたとして。 そのエントリに言及リンクがないとですね、そのエントリが脳無し側のどのエントリに TrackBack を送ったのかわからないのですね。 当事者である私はどのエントリに TrackBack があったのか知ることができるけど、他の方々はそれを知ることができないわけです。

稀にある誤解で「トラックバックはお互いの記事にて相互リンクを自動で実現するものです ! 」というようなものがあり、私はその考えには否定的なのですが、確かに「どの記事に送られたトラックバックか分からなくなる」というのは問題だと思いました。 ( Dullahan さんが「トラックバック = 相互リンク機能」だと誤解していると言っているのではありません、念のため。 )

各種の weblog ツールや weblog サービスについて調べることはしませんが、ぱっと思いつくものを挙げてみると、 Movable Type は標準のテンプレートタグではどの記事に送られたものか判別できず、また goo ブログも同様に判別できません。 はてなダイアリーのトラックバックモジュールでは、トラックバックが送られた記事を判別できるようになっていますねえ。

言及リンク無しでエントリを書かれた側を閲覧している人達は、まさかそれが脳無し側へ TrackBack されたエントリであるなんて知る由もないでしょう。 この辺りを徹底されているのは真琴さん。 TrackBack を送ったエントリには、必ず TrackBack 先の記述をされているので、話の繋がりがわかりやすい。

……と、実は文中で名前を出されていたり。 これはどこにトラックバックを送ったかを第三者に示すというよりは、自分のための備忘という意味合いが強いので、分かりやすいと言われるとなんだか照れますね。 実は、 Movable Type には MTPingsSentMTPingsSentURL という、トラックバックの送信先のリストを作るテンプレートタグは用意されています。 しかし、これは送信先の MTEntryTrackbackLink にあたる URI をリストアップするだけで、記事自体の URI をリストアップしてくれるわけではありませんし、「どういった概要を書いてトラックバックを送ったか」までは記録できません。 そういう理由から、手動でトラックバック送信先の記述をしているのです。

Movable Type で、どの記事にトラックバックが送られたのかを分かるようにする

思いついた解決策としては2つ。 言及無し TrackBack は受け付けない方向にするか、サイドバーでの TrackBack 表示を止めること。 各エントリには受けた TrackBack を表示するようにしているので、どちらかの解決策で問題は起きないような気がしたのだなぁ。

そこでお節介にも 3 つ目の解決策を提示 ! 前項で「標準のテンプレートタグではどの記事に送られたものか判別できず」と言いました。 そう、標準のテンプレートタグでは。

Movable Type にはプラグインによってテンプレートタグを拡張することができます。 そして、送信されたトラックバックがどの記事に向けられたものかを明確にするプラグインも既に作られています。 ヤヤ、こんなところにお誂え向きなサンプルが !

具体的な解説は Recent Reaction template ver.3 で既に行っているので、改めての解説は行わず、また解説自体も脳無しの呟き - 言及無し TrackBack に関してふと思ったこと自体に触発されて書いたものではないので、言及無しのままトラックバックを送って完了。

トラックバック送信先

脳無しの呟き - 言及無し TrackBack に関してふと思ったこと

トラックバックがどの記事に送られたか分かれば、受付を停止したり表示を止めたりしなくても良いのでは、ということで第三の解決策を提示。

リプライ

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

2005-10-07T20:56+09:00 - でゅらはん

>ヤヤ、こんなところにお誂え向きなサンプルが ! このようなページは特に公開しなくとも、自身の管理用に作成しておいても良い気がしました。現在は TrackBack を受けたときのメールが管理帳代わりなのですが、やはり一覧の方が断トツで見やすいですね。うん、これは便利だ。 ちなみにスタンスの話で「内容的に薄ければ」の件ですが、当然自己判断なので、TrackBack を送った後に「あちゃぁ」と思うこともあります。そういう経験から、エントリをアップするときと一緒に TrackBack を送るのは止めました。アップされたものを読んで問題なさそうなら、ということにしています。(それでも誤字脱字は防げないわ、後から読んでみて内容ダメダメなことに気が付くこともある…… orz) そういうわけで、大変有益なエントリ、どうもありがとうございました。 解説ページのほうは、改めてゆっくり読んでみます。このタイミングで週末というのは、なんだかステキです。 それでは〜。

2005-10-08T18:16+09:00 - Recent trackback の表示方法を修正 < 脳無しの呟き

先日書いた『言及無し TrackBack に関してふと思ったこと』に対して、Trackback が2つ。どちらも真琴さんからのものだった。

2005-10-08T21:26+09:00 - トラックバックなど < OreBlog

いまどきの世の中は世知辛くなったわけで、多少話題が関連しているくらいでは気軽にト...

2005-10-12T00:50+09:00 - 真琴

さっき判明したんですが、 Movable Type 3.2 だと Recent Reaction template ver.3 の記述じゃ上手くいかないようです。 でゅらはんさんのサイトでは上手くいっているようですが、もし 3.2 にアップデートする際はお気をつけください。 ( 近いうちに 3.2 でもうまくいくように検証します。 ) あと、一覧を単体ページに作って公開するかどうか、というのは自由です。私は「最近の~」という区切りで、それ以前を切り捨てるのはあまり好きじゃないので、こうして古いものでも辿れるように公開しています。

2005-10-17T21:31+09:00 - 続トラックバックなど < OreBlog

前回のつぶやきに対してhxxkさんからPingedURLというプラグインを紹介し...

2005-10-17T21:40+09:00 - kade

先日はコメントありがとうございました。早速ゴニョゴニョと改造し、実験とばかり再度トラックバックさせていただきましたが敢えなくタイムアウトで実験失敗! どうもDB汚して申し訳ありません。

2005-10-17T22:03+09:00 - 真琴

あれ、上手くいってませんか ? http://www.kadesoft.com/mt3/oreblog/archives/2005/10/200510170010.html でもトラックバック送信先としてこの記事が書かれていますし。 よくある誤解なのですが、トラックバック送信時のタイムアウトは、 1.weblog A からトラックバックを送信する 2.weblog B がトラックバックを受信し、記事に反映したのちに A に対する「トラックバック成功のレスポンス」を返す 3.weblog A が weblog B からの成功レスポンスを受け取る の、 3. の部分がタイムアウトになっていることがほとんどです。 しかし、 2. の時点でタイムアウトになっていると考えてしまう人がどうも多いような印象があります。

2005-10-18T00:54+09:00 - kade

チェックありがとうございます>真琴さん。 タイムアウトしてても大抵はTB成功しているのは判っております。で今回のTBを送った時点では見かけ失敗じゃ情報取得&DB登録はしない仕様だったので、悔しいからSQL手打ちで登録しちゃいました(笑) その後修正してTB失敗っぽくてもも登録を試みるようにしましたけどね。

2005-10-21T01:26+09:00 - 真琴

あら、釈迦に説法って感じでしたね>タイムアウト しかし、 __mode=rss を付けて情報を取得する方法は良さげですね。

2005-10-23T13:13+09:00 - kade

いえいえ、むしろ馬の耳に念仏といったほうがいいかも。 __mode=rssもいいんですけど、普通にトラックバック送った際に同様の情報が返ってくるというのが本来あるべき仕様だと思うんだなぁボクは。

2005-10-24T21:32+09:00 - 真琴

はてなダイアリーみたいに、 Permalink と Trackback Ping が同じという仕様が一般的だったなら良かったかもしれませんね。 あれって method=post だったら ping と判断するとか、そういった処理をしているのかなあ ?

2005-10-31T21:52+09:00 - kade

どもです。間が空きましたがはてなさんはそういうナイスな仕様になってるのですか。勉強になりました。 送信された内容で切り分けするのはワタシでも出来たくらいだからはてなさんなら朝飯前でありましょう。

Movable Type の限定個人ライセンス ( 無償 ) を使える条件

記事データ

投稿者

望月真琴

投稿日時

2005-10-05T22:42+09:00

タグ
概要

Movable Type の限定個人ライセンス ( 無償 ) を適用できる条件は、実は厳しいものだったりします。個人使用・非商用利用・ログイン ID * 1 ・サーバ * 1 という条件を全て満たさなければいけません。

リプライ

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

記事本文

ライセンス関連を簡潔にまとめてみる

またも Movable Type のライセンスの話です。 今回は限定個人ライセンス ( 無償 ) についてです。 これまで調べたことのおさらいですが、量が膨大になったので改めてまとめてみました。 詳細について知りたい場合や、これ以外のライセンスについて知りたい場合は次に羅列する記事を参照してください。

限定個人ライセンス ( 無償 ) を適用できる条件

限定個人ライセンス ( 無償 ) を適用できる条件は、実は厳しいものだったりします。 次に挙げる条件を全て満たしていなければなりません。

非商用目的である

商用目的の場合は、限定個人ライセンス ( 無償 ) はおろか個人ライセンスも適用されません。 商用目的の場合は通常ライセンスが必要となります。

なお、アフィリエイトを行う場合は、それが主目的でなければ非商用目的とみなされるようです。 ( Six Apart - Support アフィリエイトを利用したいのですが、商用扱いになるのでしょうか? )

個人使用である

「限定個人ライセンス(無償)」という名称が示す通りです。 クラブ・サークル等で使用する場合は、人数分の通常ライセンスが必要となります。

ログイン ID ( = ユーザ数 ) を 1 つしか使用しない

同一人物が使用するログイン ID はユーザ数と呼ばれていますが、限定個人ライセンス ( 無償 ) ではユーザ数が 1 と定められているため、複数使用は認められていません。

よって、 moblog ゲートウェイや、 BlogPet の自動投稿機能などで、メインのログイン ID ではなく別のユーザ ID を使いたい場合は、個人ライセンスが必要になるという解釈になると思います。 ( メインのログイン ID で moblog ゲートウェイや BlogPet の自動投稿機能を使う、という回避策もありますが……。 )

インストールするサーバは 1 つのみで、かつそのサーバ内で使用するシステムも 1 つのみ

これは、限定個人ライセンス ( 無償 ) に限った話ではありませんが、それぞれのライセンスはサーバ 1 つに対して適用されます。 この「サーバ」というのが曲者で、仮に同じサーバ上に異なるドメインが存在する場合 ( マルチドメイン ) でも、トラックバック用 URI や検索フォームの URI をそれぞれのドメインで使い分ける場合、その使い分ける数だけライセンスが必要となるようです。 ( Six Apart - Support マルチドメインでMovable Typeを使うには? )

また、異なるサーバで複数の Movable Type を使用する場合、それらのサーバでそれぞれ限定個人ライセンス ( 無償 ) の要件に該当する可能性が出てきます。 しかし、仮に全ての運用において限定個人ライセンス ( 無償 ) の要件に該当しそうな場合でも、限定個人ライセンス ( 無償 ) が適用されるのはどれか 1 サーバのみに限定されるため、 2 つ目以降のサーバについては個人ライセンスを購入する必要が生じます。

これは私が今まで調べたり、また問い合わせをしたりして得た私なりの結論ですので、 「この解釈は違うんじゃないの ? 」 というご指摘は歓迎します。

また、使用するライセンスをどれにすべきか迷った場合はこの解釈を鵜呑みにせず、 Movable Type に関するお問い合わせから問い合わせしていただく方が確実です。

リプライ

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

Movable Type のライセンスの質疑応答

記事データ

投稿者

望月真琴

投稿日時

2005-10-05T20:18+09:00

タグ
概要

Movable Type のライセンスについての疑問や質問をほぼ同時に見かけたので、それに対して行った私の回答を再録。

リプライ

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

記事本文

Movable Type のライセンスに関する疑問や質問にコメントしたり回答したりした

偶然ではありますが、ほぼ同時期に Movable Type のライセンスについてサイト上で疑問に思われている方がいらっしゃったり、はてなで質問をされている方がいらっしゃったので、コメントや回答をさせていただきました。

今後の記事の話題の種になりそうですし、回答したことをまとめておいた方が良いと思ったので、メモとして残しておきます。 再録とも言います。 むしろリレコーディング ! そういえば、 weblog って音楽 CD をリリースすることに通じていると思いませんか ? 日々の更新をシングルとすると、月別アーカイブはフルアルバム、カテゴリアーカイブはコンセプトアルバム、たまに手動でより抜き記事を集めたりするときはベストアルバム……って、これでもうひとネタ書けそうなのでそろそろ本題へ。

Namamono ? Diary - MT のライセンスへのコメント

同じサーバ上でマルチドメイン運用をする場合であっても、ドメインごとに独立したシステムを用いる場合はその分もライセンスが必要なの ? という疑問。 確かに、以前は同一サーバ上のマルチドメイン運用について、システムを分ける場合は別サーバとみなすといった表現は無かったように記憶しています。 そこで、システムを分ける場合は別サーバとしてカウントするという新しい基準と、以前私が問い合わせをした結果を踏まえて次のようにコメントをしました。

http://hxxk.jp/2005/05/26/2320#sub-20050526-12 の事例と似ていますね。 私は Six Apart に問い合わせをした結果を踏まえ、現在 hxxk.jp の方で限定個人ライセンス ( 無償 ) 、もうひとつのドメインで個人ライセンスを使用させてもらっています。

トラックバック用 URI なども含めて各ドメインで完結させるなら、 SUPPORT の記述の通りその分だけライセンスが必要になります。

しかし、いずれかのドメインが限定個人ライセンス ( 無償 ) の範囲に収まるなら、 ( 実際に運用するドメイン数 ) - 1 = ( 購入が必要なライセンス数 ) と捉えて良いみたいです。

よって、複数のドメインでの運用であっても、どれか一つが限定個人ライセンス ( 無償 ) の範囲に収まるような運用であれば、ライセンスの購入数を抑えることは可能です。

はてな Movable Typeのライセンスについて質問です。Mobable Type3.2を利用して、アフィリエイトサイトを作成の予定ですが、その際には、商用ライセンスを使・・への回答

アフィリエイトサイトを作成する場合のライセンスはどれを用いるべき ? 個人ライセンスで複数ユーザの利用ができるが、そのメリットは ? 個人ライセンスや通常ライセンスにあって、限定個人ライセンス ( 無償 ) には無い機能は ? という質問。 ライセンス利用にあたって、多くの人が行き当たる疑問だと思います。 以下のように回答させていただきました。

日記やニュース等の紹介が主で、それに付随してアフィリエイトを行う場合は商用ライセンスを使う必要はありません。 ただし、個人で運営を行うとしても、アフィリエイト自体が目的であるサイトの場合は通常ライセンス ( ≒商用ライセンス ) を利用する必要があります。

また、ユーザ数についてですが、個人ライセンスの場合は、ライセンス保持者が同一サーバ内で投稿者名を使い分ける場合 ( 例えば、 BlogPet を別名で管理する場合など ) にユーザ数が加算されることになります。 ここで注意しなければならないのは、 5 ユーザ = 5 人 ではなく、あくまで利用できるのは 1 人だけということです。 上の方で mizunoto さんが「複数人で記事を書いていたりする場合は個人ライセンス版が必要になってきます。」と仰っていますが、複数人で記事を書く場合は個人ライセンスではなく通常ライセンスが必要となりますので、お間違えのなきよう。

また、仮に同一人物であっても、異なるサーバに Movable Type をインストールする場合は、それぞれのサーバにおける利用状況に則したライセンスが必要となります。

ちなみに、無料版に無くて個人ライセンスや通常ライセンスにある機能というと、「複数の投稿者を使うことができる」「問い合わせに対する回答などのサポートを受けられる」が挙げられます。 純粋な Movable Type の機能としては違いはありません。

ですから、仮に silentlion さんが「 1 つのサーバにしか Movable Type をインストールせず」、「投稿者名を 1 つしか使わず」、「アフィリエイトがメインではない」といった条件を満たした場合は、限定個人ライセンス ( 無償 ) でも構わないということになります。 逆に、どれかひとつでも満たさない場合は、その条件に応じて個人ライセンスまたは通常ライセンスが必要、ということになります。

この回答を書いていて改めて思ったんですが、「個人ライセンス」で「ユーザ数」という表現は混乱しやすいのではないかなあと。 個人ライセンスの場合は基本的にユーザ数としては 1 人 ( 例外的に家族・友人が使用し、 2 人以上になることもあります ) なのですから、「ログイン ID 数」と表現した方が分かりやすいのではないかと思います。 「 1 サーバ・ 5 ログイン ID 」あるいは「 1 サーバ・ログイン ID 無制限」のように。

はてな Movable Typeのホスティング・ライセンスについて質問します。参考サイト:http://www.sixapart.jp/inquiry/quote_hosting.html1.ホスティング・ライ・・への回答

ホスティングライセンスはライセンス料金が必要なのか ? 必要なのであれば、ホスティング数で価格帯が設定されているのか ? 複数の会員会社に Movable Type を設置しようと考えているが、その場合もホスティングライセンスが必要なのか ? という質問。 これは以前実際に問い合わせた際の質問には含まれていなかったので、憶測を多少含んだ回答になりました。

http://www.sixapart.jp/inquiry/quote_hosting.html
Six Apart - Inquiry: ホスティング・ライセンスお問い合わせフォーム

ホスティングライセンスの「登録料」としては料金は発生しないと思います。 しかし、ユーザ数によって、それに応じた相応のライセンス料金はかかるようです。 上記 URL の「ホスティング・ライセンスお問い合わせフォーム」によると、 500, 2000, 5000, それ以上という区分を設けているように思えます。 ( 具体的にいくら、というのは分かりません、ごめんなさい。 )

http://www.cozy.biz/
ビジネスサイト向けトータルソリューション cozy.biz

こちらのサイトが、ホスティングライセンスによるサービス提供を行っています。 ここの利用価格を参考にされてはいかがでしょうか ?

回答に書くのを忘れていましたが、通常ライセンスが適用されるケースとして、 ウェブ構築業者がMovable Typeを使ってシステム構築やインストール代行をする場合 が挙げられています。 よって、

ホスティングライセンス

ウェブサーバ自体をウェブ構築業者が所持し、そのサーバに Movable Type をインストールしたホスティングサービスとして不特定多数のクライアントに提供する場合。 クライアント自身はライセンスを所持しない ? ( 例 : ビジネスサイト向けトータルソリューション cozy.biz )

通常ライセンス

Movable Type のインストール作業やメンテナンス作業をウェブ構築業者が請け負う場合。 特定のクライアントにサービスを提供する場合に適用 ? この場合、ライセンス所持はケースバイケース ? ( クライアント自身がライセンスを購入し、構築・インストール作業料金だけを支払って作成してもらうケースもあるでしょうし、ウェブ構築業者がライセンスを購入し、構築・インストール作業料金 + ライセンス料金を支払って作成してもらうケースもあるでしょう。 )

といった使い分けになり、必ずしもホスティングライセンスが必要となるわけではないと考えています。

トラックバック送信先

はてな Movable Typeのホスティング・ライセンスについて質問します。参考サイト:http://www.sixapart.jp/inquiry/quote_hosting.html1.ホスティング・ライ・・

補足ですが、ホスティングサービスとして不特定多数へのサービスを提供するのではなく、単に会員に対して設置作業を行うというのであれば、ホスティングライセンスではなく会員の数だけの通常ライセンスを購入すれば済むかもしれません。

リプライ

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

2006-03-10T04:26+09:00 - (

こんにちわ。 ほんとにあやふやで困っていたのですがこちらのまとめのおかげで質問の数を 減らすことができ助かりました。折角なので今回問い合わせた内容を紹介します。 状況としては任意団体(複数人の個人)が所有する1つのサーバ上で各個人に 対してマルチドメインでWebサーバを提供しているような、ミニプロバイダ? みたいなケースではどのライセンスが必要かという問題です。 最初、説明が足りなかったのか、団体なら通常ライセンス(マルチドメインする なら通常ライセンスを複数←そんな予算はない)しかない、個人ライセンスは 個人が契約したサーバにのみ適用されるとの回答でした。 そこで、再質問したところ、どうやら「サーバの所有者」でなく「サーバ領域の 占有者」ごとにライセンス契約者になれると解釈できる回答を得ました。システム を分けると別サーバとみなすというやつの応用編で複数人数版ですね。 最近始まったlacoocan.nifty.comで個人ライセンスが通って、なぜうちではダメ なのか焦りましたが、一件落着です。

2006-03-10T04:26+09:00 - (か)

すいません、名前、入れそこないました。

2006-03-12T23:19+09:00 - 真琴

lacoocan.nifty.com って個人ライセンスなんですか、知りませんでした。 lacoocan に MT を設置したサイトのトラックバック URI などを見ると、それぞれのサブドメインの中で CGI が稼動しているように見えるのですが……。 (か)さんのケースを含めて考えると、いまいち Six Apart 自体がライセンスの解釈に不透明な面が見えてしまいます。

概要が記述されるのは Feed ? meta 要素 ? RDF メタデータ ?

記事データ

投稿者

望月真琴

投稿日時

2005-10-04T23:42+09:00

タグ
概要

一つ一つの記事に含まれる概要と、その活用 ( http://hxxk.jp/2005/10/02/1127 ) に対するご指摘をいただき、私の出したはてなアイデアの表現に至らない部分があったことに気付きました。 Feed の description から生成して欲しいという表現だと、新しくない記事については概要が取得できない可能性が出てきます。

リプライ

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

記事本文

idea:6444 の表現の不備

一つ一つの記事に含まれる概要と、その活用について、海馬日記 - Re: meta要素の使ひ道にて反応をいただきました。

たとへばはてなダイアリーのフィードには最新の記事數件分(一定ではない模樣)しか掲載されません。 はてなダイアリーだけでなく、大抵のRSSがさうでせう。 此れでは昔の記事の概要は取得出來ません。 否、件數の多少等は問題ではなく、RSSが更新情報を提供するリソースであるとすれば、其の性質から言って或文書の概要を取得するだけの目的で利用するのには無理があるのではないか、と。

RSS が提供する情報は更新情報には限りませんが、今回提示した idea:6444 における Feed とは、更新情報の提供が主目的であるものと考えられるでしょう。 ( 何故なら、はてなダイアリーの RSS を根拠に語っているため。 ) よって、 昔の記事の概要は取得出來ません というご指摘はもっともだと思います。

これは私の書き方が悪かったのですが、一つ一つの記事に含まれる概要と、その活用 - 概要が書かれている場合はそこから引用して欲しいで書きたかったことは、見出しにもある通り「何がしかの概要が適切に提供されている場合はそれをそのまま用いて欲しい」ということであって、その「何がしかの概要」は ( Feed を提供している記事の head 要素内に往々にして同時に提供されている RDF メタデータの ) dc:description を指しているつもりでした。 しかし、そこで Feed の description と dc:description を混同して、アイデアに出してしまいました。

はてなダイアリーの head 要素内の RDF メタデータには dc:description が含まれていない

じゃあ、コメントなどで「 RSS では古い記事の概要が取得できない可能性があるから、 dc:description などから取得した方がよりベター」という補足をしようか……と思ったら、はてなダイアリーの head 要素内の RDF メタデータには dc:description は含まれていないんですね。 今さら気付くというのも片手落ちですが、私が慣れ親しんでいる Movable Type と、はてなダイアリーの RDF メタデータは同じような構成だろうと思い、確認を怠っていました。

Movable Type の場合、 head 要素内には <$MTEntryTrackbackData$> というテンプレートタグで RDF メタデータが埋め込まれます。 このテンプレートタグはショートカットタグと呼ばれ、これをテンプレートに記述することで、実際は次のような記述をテンプレート内に行ったのと同様の効果をもたらします。

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

それに対し、はてなダイアリーの RDF メタデータは次のような構成になっています。

<!--
<rdf:RDF xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"
         xmlns:dc="http://purl.org/dc/elements/1.1/"
         xmlns:trackback="http://madskills.com/public/xml/rss/module/trackback/">
<rdf:Description
  rdf:about="記事の URI"
  trackback:ping="記事の URI"
  dc:title="記事のタイトル"
  dc:identifier="記事の URI" />
</rdf:RDF>
-->

うーん、現状がこのようになっているなら、 idea:6444 がもしアイデアミーティングで取り上げられたとしても、取得する概要が無いということで却下されてしまうかも……。 ベットしてくれた皆さん、私の表現が至らなかったばかりにポイントを無駄にさせてしまうかもしれません。

記事の冒頭部分から生成された概要は概要たり得るか ?

と云ふか。 はてなダイアリーのフィードのdescription要素ははてなブックマークの「概要」と同じで自動的に拔粹された物ですから、現状の「自動生成」と大差無かったり……。

もりやまひろしさん ( 海馬日記 ) は、このようにはてなダイアリーの Feed の description について述べられています。

確かに、機械的に生成される点でははてなブックマークが自動生成する概要と大差はないかもしれませんし、それが適切な概要であるかというと、おそらく違うでしょう。 しかしながら、記事本文の冒頭部分から、先頭からの一定文字数を抜粋して生成された Feed の description と、記事本文から、 ( ユーザが一見しただけでは分からない ) 何らかのアルゴリズムで生成されたはてなブックマークの概要は大きく違うとも私は考えます。

前者は、執筆者がその挙動を知っていれば、冒頭の段落に意識的に概要になりそうな文章を書くことで、自動生成であっても適切な概要を提供することができます。 ( はてなダイアリーユーザではありませんが、そう心がけて書いている方を 2 名ほど知っています。 ) 対して、後者は執筆者がどれだけ文章に気を使っていても、文脈を無視されたり、あげく文頭に句点が配置されたりするので、例え冒頭から一定の文字数で作られた概要であっても、これよりはましだろうと考えました。

もちろん、私の理想ははてなダイアリーの編集画面に概要を記述する欄が用意され、それによって Feed や head 要素内の meta要素 あるいは RDF メタデータの description が作られたり、またそこからはてなブックマークの概要が作られることですが、そういった欄が標準で用意されている Movable Type でさえほとんど気に留められていない現状を見ると、気合を入れてそのメリットを説かないと、実現はまだまだ遠そうです。

トラックバック送信先

海馬日記 - Re: meta要素の使ひ道

「昔の記事の概要は取得出來ません」というご指摘は確かにその通りだと思います。 Feed からではなく、 RDF メタデータから取得するようにアイデアの文章に書けば良かったのですが……。 ( ただし、 RDF メタデータから取得するアイデアだと、はてなダイアリーで概要を取得できなくなってしまいますが。 )

リプライ

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

2005-10-05T00:00+09:00 - 真琴

ちなみに、 head 要素内に RDF メタデータを記述すること自体の是非については http://www.akatsukinishisu.net/wiki.cgi?Hatena_ID_Auto%2DDiscovery%A4%CB%B4%D8%A4%B9%A4%EB%B5%C4%CF%C0 にある、 Hatena ID Auto-Discovery 導入時の議論が詳しいです。 ( RDF メタデータを記述すること自体の是非についてまで含めて本文に書くと冗長になるので、コメント欄で補足。 )

はてなブックマーク de アバウトページ

記事データ

投稿者

望月真琴

投稿日時

2005-10-03T18:20+09:00

タグ
概要

はてなブックマークでサイトのトップページをブックマークして、そこの概要を使ってアバウトページみたいにしてみてはどうでしょうか、という試み。

リプライ

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

記事本文

概要話に至った流れ

ちょっと話の流れとしては逆転しますが、一つ一つの記事に含まれる概要と、その活用で触れたはてなブックマークの概要生成は、元々ははてなブックマーク - 闇黒日記の自動生成された概要について、野嵜健秀さん ( 闇黒日記 ) 自身が憤られていたことに端を発します。

現在は hkt_o さん ( 日記グループ - id:hkt_o ) の手によってはてなブックマーク - 闇黒日記の内容は書き換えられ、闇黒日記がどういったコンテンツであるか理解しやすいようになっています。

第三者による解説の場となるか ?

はてなブックマーク - 闇黒日記の例は、概要を手動で編集するにあたっての良い方向のモデルケースとなっていると思いました。 もちろん、自動生成による概要がもう少しましな物であったなら、例えば 正字正かな專門サイト「言葉 言葉 言葉」のおまけ記事。 ウェブ日記あるいはニュースサイト。 という闇黒日記の description から取得したものであれば、わざわざ人の手を煩わせることはなかったでしょう。

しかし、こうして手動で自由に編集できるというのは、本来作成者が用意したアバウトページではなく、第三者の客観的な視点で見た解説を書ける土壌となるという見方もできるのでは ? と思いました。

概要を編集しているところを探してみた

よく読ませていただいているところから、 http://b.hatena.ne.jp/entry/サイトの URI の概要を編集しているところをピックアップしました。 200 サイトくらい調べてみたのですが、編集していたのはこの 3 サイトのみ。 はてなブックマーク - 闇黒日記と違い、第三者ではなくご本人が編集されているようですが……。

この記事を見てけんたろたん ( antipop2.0 ) がはてなブックマーク - antipop2.0 にあんちぽの歴史を書いてくれたよ !

もちろん、安易に第三者による編集を推奨してしまうと、悪意ある概要にされてしまう可能性もありますが、試みとして編集してもらうのは面白いかも。 言い出しっぺが人柱ということで、どなたか hxxk.jp の概要を編集してみませんか ?

History of hxxk.jp で年表を書いたので、はてなブックマーク - hxxk.jp に反映させてみました。

リプライ

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

2005-10-03T23:47+09:00 - 186

ぎゃぁ(;´Д`) あれははてなアイデアに出すときにテスト用に編集したんで、カウントしない方が。

2005-10-03T23:57+09:00 - 真琴

じゃあ、それっぽく編集しなおしてください ! ( とか ) 「テスト」とかそんな無味乾燥な内容じゃなかったので、カウントに入れました。 あといもけんぴ食べたくなってきた……

2005-10-04T23:11+09:00 - ちはや(智猫)

ぎゃ~!また真琴さんにネタを提供してしまった…… なんというか誰かが登録して自動で変な部分を掲載される前に、Blog日記の概要部分を掲載してしまえと言うことで…… それにしてもAccount-Auto-Discoveeryでの「投げ銭」の実装と、どれほどの結果が出るか確認するために「はてな」のIDとサブアカウントを取得したけども、はてなのサービスの有効な使い方が解らない今日この頃。 一番利用方法が解らないのがブックマークだったり……

2005-10-04T23:56+09:00 - 真琴

> Blog日記の概要部分を掲載してしまえ そうそう、最初は「そこを自動でやってくれよー」と思っていたんですけど、闇黒日記や趣味のWebデザインみたいなサイト紹介に使うと面白いかなとも思ってこのネタに。けんたろたんに美味しいところをかっさらわれた気もしますが ! >一番利用方法が解らないのがブックマーク 同感です。はてな RSS は使っていませんが、用途ははっきりしています。 はてなブックマークは稀にテストしてみますが、やはり用途がつかめません。以前のコメントでも言いましたが、「何故このページをブックマークしたのか」という<em>自分に向けての</em>コメントを書く欄が、記事の作者に向けて書かれているケースが多くなっていますし。

一つ一つの記事に含まれる概要と、その活用

記事データ

投稿者

望月真琴

投稿日時

2005-10-02T11:27+09:00

タグ
概要

はてなブックマークの概要部分は編集できるようになったとはいえ、自動生成は相変わらず中途半端な概要になります。そこで、 Feed の description を活用してはいかがでしょう、というアイデアを出してみました。

リプライ

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

記事本文

meta 要素内に概要を記述する方法

はてなブックマークによる自動生成の概要が中途半端であるので、 meta 要素の description といったデータを用いればよいのではないか、という意見と、それに対する現状を踏まえての意見。

だいたい、ブログの記事一つ一つについて、meta 要素に概要を記述しているケースなんて見たことがない。 ブックマークの使われ方と現実に存在するウェブリソース群の状況から考えて、現在の仕様は悪くないと思う。

うちはそれやってまっせー、ということを表明しておきます。 meta 要素こそ馬鹿な検索エンジン対策をするサイトが多すぎて、一時期 Google などから完全に無視されるに至った代物 という意見には同意なので、海馬日記 - meta要素の使ひ道の意見には思想的には賛同しますが、現状では実装されにくそうだと捉えています。

一応、 Movable Type ユーザ向けに実現方法を解説します。 エントリー・アーカイブのテンプレートにて、 head 要素内に <meta name="description" content="<$MTEntryExcerpt remove_html="1"$>" /> という記述を追加して、 MTEntryExcerpt 部分 ( 記事の投稿画面で言うところの「概要 (excerpt) 」部分 ) を毎回きちんと記述するようにすれば OK です。

概要が書かれている場合はそこから引用して欲しい

はてなブックマークによる自動生成の概要については私も何度か取り上げましたし、はてなアイデアにアイデアを出して概要の編集機能も実装していただきました。

実装していただいた以上、その機能は存分に活用させてもらっています。 しかし、編集できるとはいえ自動生成の概要の変な点は見過ごせません。 例えば、はてなブックマーク - hxxk.jp - Movable Type 3.2 のテンプレートタグ一覧では、

。 そこそこ使用頻度が高いテンプレートタグなのですが、 Movable Type 2.x には無かったもののせいか、マニュアルには正式には掲載されていません。 ) テンプレートタグの存在を調べる方法 実は、 lib\MT\Template\ContextHandlers.pm を見ると default_handlers 、つまり標準で用意されているテンプレートタグの存在を調べることは可能です。 そこで、 Movable Type 3.2 の lib\MT\Template\ContextHandlers.pm ...

hxxk.jp - Movable Type 3.2 のテンプレートタグ一覧

という概要が自動生成されています。 冒頭に句点が来るってのは流石にどうかと……。

しかし、よく考えたら前項で触れたように、何がしかの概要が適切に提供されている記事は、本文部分を解析して概要を生成するのではなく、提供されている概要を用いれば、わざわざ手動でユーザが概要を編集しなくても良い気がします。 meta 要素の description ではなくとも、例えば RSS や ATOM などの Feed の方の description を取得するとか。 Feed ならはてなダイアリーでも使われているので、現状にも則していると思いますし。

ということではてなアイデアに投げる

85 文字に収まらなかったので書いていませんが、はてなブックマークの概要をきちんと修正できるようになりそう - 自動生成の概要は検索の対象 ? でも触れたように、 http://b.hatena.ne.jp/keyword/*** の *** にあたる部分は本文から生成されているようなので、その仕様は残したまま、概要部分だけを description から取得して記述するようにして欲しいと思っています。

トラックバック送信先

海馬日記 - meta要素の使ひ道

自動生成は私も中途半端だと思っています。 そこで、 meta 要素ではなく ( はてなダイアリーで標準的に使われている ) RSS の description を活用する方法はどうかと考えてみました。

日記グループ - id:hkt_o

うちは記事一つ一つに概要を記述しています。 meta 要素が安易な SEO 対策によって形骸化してしまっているのには同意。

はてなアイデア - RSS などの Feed で description を提供している weblog であれば、その description から概要を自動生成するようにして欲しい。本文からの自動生成は description が提供されていない場合のみに。

検索用のキーワードにあたる部分は、これまで通り本文から生成されるようにしたままで良いと思っています。

リプライ

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

Movable Type 3.2 日本語版におけるライセンス体系の変更

記事データ

投稿者

望月真琴

投稿日時

2005-10-01T23:51+09:00

タグ
概要

Movable Type 3.2 日本語版が正式に提供開始されたことで、そのライセンス体系に変更が加えられたため、それについて触れようと思います。

リプライ

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

記事本文

Movable Type 3.2 日本語版でもライセンス体系に変更あり

以前から、 hxxk.jp では Movable Type のライセンス体系については詳しく触れてきました。

Movable Type 3.2 日本語版が正式に提供開始されたことで、そのライセンス体系に変更が加えられたため、それについて触れようと思います。

Movable Type 3.2 日本語版の限定個人ライセンス ( 無償 ) でもウェブログ数は無制限に

Movable Type 3.2 英語版におけるライセンス体系の変更 - Movable Type 3.2 英語版の限定個人ライセンス ( 無償 ) ではウェブログ数は無制限で触れていましたが、 Movable Type 3.2 英語版の Free Edition ライセンスでは、従来 3 つという制限があったウェブログ数が無制限に変更になりました。

Movable Type 3.2 日本語版の限定個人ライセンス(無償)においても、同様にウェブログ数の制限は無くなりました。

Movable Type 3.2 日本語版の個人ライセンスでは期間限定の値引きは無し ?

Movable Type 3.2 英語版におけるライセンス体系の変更 - Movable Type 3.2 英語版の個人ライセンスは期間限定で 30 ドル引きで触れていた期間限定の値引きは、 Movable Type 3.2 日本語版では特に無いようです。 まあ、よく考えたら、英語版のライセンスを日本国内から購入することも可能だったわけで、日本語版がリリースされたからまた期間限定で値引きをするだろうというのは虫が良すぎる考えだったのかもしれません。

なお、Six Apart - Movable Type: ダウンロード - 注意事項(必ずお読みください)に、 ベータ・テストにご協力いただきました方には、個人ライセンスのご優待販売を予定しております。 後日、あらためてご連絡させていただきますので、しばらくお待ちください。 というアナウンスもあっているので、ベータテスタについては値引きがあると考えても良いかもしれません。 まあ、限定個人ライセンス(無償)ではなく個人ライセンスが必要になるケ―スは、 Movable Type 3 の個人ライセンス - 個人ライセンスが必要となるケースのような場合だと思いますので、ベータテスタのうち何人が個人ライセンスを購入するかは分かりませんが。

リプライ

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

補足情報

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