2004-10 アーカイブ

http://hxxk.jp/2004/10/

Re: ねこめしにっき - よそ様の CSS を被せる実験に思索

記事データ

投稿者

望月真琴

投稿日時

2004-10-31T22:57+09:00

タグ
概要

「他所の CSS を適用したり適用させたりしてみる」について多くの助言をいただいたので、それに対するお返事を。 だいぶ間が空いちゃいましたが……。

リプライ

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

記事本文

TuneDoc とか作る前にお返事を優先しましょう

他所の CSS を適用したり適用させたりしてみるについて多くの助言をいただいたので、それに対するお返事を。 だいぶ間が空いちゃいましたが……。

div.section と div.subsection

まず、最初に自分の設計の甘さを晒すことになりますが、 hxxk.jp 内の記事などの文章のグルーピングの意味で <div class="section"> 〜 </div> で囲み、その中でまた細かく分かれる際に <div class="subsection"> 〜 </div> としていることに、確固たる信念や設計思想はありません。

現行のスタイルでは div.section に border プロパティや background プロパティを指定していますが、 div.subsection については、何のプロパティも指定していません。 次にスタイルを変えるときに、違う class 名にしておいた方がラクかなあ、といった安易な見通しで subsection という class 名になっています。 ということは、先に CSS ありきで class 名を付けているということであるので、そもそもの順番が間違っているということにもなります。 ( まず HTML で論理的な構造を示すために class 名を付けるべきであって、それの後に CSS をあてていくのが正しい順番 )

ウチのサイトの HTML における div.section 入れ子構造は、 XHTML2 の <section> / <h> 構造を睨んでのモノ。 とあったので、 XHTML2 の <section> / <h> 構造を初めて見てみたんですが、 ( section と subsection の差異はあれど ) 現行の hxxk.jp の構造もこんな感じだなあと思いました。 私の場合は XHTML 2 を視野に入れていたわけではなく、単に hn 要素に対して id を振るという形式がしっくりこなかったので、 <div id="entry-yyyymmdd-hhmm" class="section"> ないし <div id="sub-yyyymmdd-xx" class="section"> としていたということなんですが。

「ある見出し要素に暗幕的に従属する範囲の明示化」というこの div の使命は、見出しレベル (あるいは div 入れ子の深さ) に依存しないワケだから、いつも同じ section という class であるベシ というくだりに納得したので、近々予定している Movable Type のテンプレート書き換えの時に、 <div class="section"> 〜 </div> で統一しようと思います。

狭義の HTML の構造と id と class

hxxk.jp の真琴たんは、 HTML の構造や、各要素の class や id に依存したものになっている と述べているけれども、classid の差違も「構造差違」と言ってしまって良いと思う。

私が 他所の CSS を適用したり適用させたりしてみる - 適用して分かったことで言っていた HTML の構造という言葉ですが、これは HTML 文書内に各種の要素をどのように配置するか、という意味で使っていて、 id や class などの属性は別物だろう、と無思慮に決め付けていました。 よくよく考えると、 Descendant selectorsChild selectorsAdjacent sibling selectorsClass selectorsID selectors も、どれもセレクタとして扱われているし、 class や id によって意味付けされるものも構造であるということは確かです。

多くの場合、 CSS は任意の HTML/XML 群に適用される事のみを前提に作られていて、それは至って正常な営みで、何も問題ない。 というのも充分に頷ける話で、たしかに hxxk.jp の CSS は hxxk.jp の構造に適用させることを前提に作っているわけです。 ありみかさん ( 娘々飯店しるきぃうぇぶ ) も私がそういったことを今回の件で再認識しているのを見てそういうことを言っていただいたのだと思います。

まあ、他所の HTML に自分の CSS を適用してみたら 「かなり見た目がバラバラになった !! もう少し汎用性のある CSS を作らねば !! 」 といった思いを抱いたわけではなく、「バラバラになるもんだなあ」と単純な感想を抱いただけというのがあの記事の締めなのですが。 もう少し時間と根気があれば、単に現行の CSS をあてるだけでなく、逆にそれぞれの HTML において見た目が同じになるように、それぞれのサイト用に CSS を書き換えてみるという モノヅクリのタノシミ 方もあったかもしれません。

HTML/XML の構造のほうを CSS に合わせて変化させる

ある特定用途向け CSS を、どうにもその構造上ムリのある HTML/XML にすんなり自然に適用したいと思い、そのためにどんな手段もいとわないとするならば、 HTML/XML の構造のほうを CSS に合わせて変化させるなんてのがよくあるパターン。 この場合、「 HTML ありきの CSS 」という大事な大事なお題目が大ピンチ (笑) なので、なるべく避けたいバイアスがかかるのが普通の信者 (誰)。

私は知らず知らずにこのバイアスを持ってしまっていたのかもしれません。 antipopCSS を適用する際も、 HTML の構造をいじらないという自分向けの縛りを科していましたし。

逆に、そういったバイアスをかけずに、柔軟に対応した例がタイミングよく作られたので紹介。

やたー!うんちぽ捨てて hxxk.jp スタイルになったよー! とのことです。 まさか逆に向こうから適用されるとは思っていなかったので、ちょっとびっくりしました。 最初は前述の div.section に指定している border プロパティや background プロパティがうまく再現されていなかったのですが、 HTML の構造を変えて見事に再現するようにしたそうです。

ちなみに、本筋とは関係ないのですが、現行の hxxk.jp のスタイルには h2{ text-transform: uppercase; } と指定しています。 そのせいで、本来だったら (`・ω・) らくがきである見出しが、(`・Ω・) らくがきになっていて激しく脱力します。 思わぬ副産物。 ( か ? )

リプライ

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

TuneDoc template set

記事データ

投稿者

望月真琴

投稿日時

2004-10-28T21:06+09:00

タグ
概要

実験も兼ねて URI メモ用のテンプレートを作ってみました。公開用というよりは自分用、もしくは RSS リーダ用と言った方が良いかもしれません。

リプライ

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

記事本文

練習がてらに作ってみることにした

けんたろたん ( antipop ) とのやりとりの中で、 Movable Type は Weblog ツールとしてだけでなく、 CMS 的な使い方もできるんじゃないか、といった話になりました。

CMS 的な使い方と言えるかは分からないけど、 hxxk.jp を複数の Movable Type による Weblog で構成していることの考え方の根本はそれですよ、今は同じような形のものを複数作っているけど、いずれはブックマークなんかも専用のテンプレートを作るつもりですよ、と私が言ったため、実験も兼ねて URI メモ用のテンプレートを作ってみました。

  1. 特徴
  2. 使用条件
  3. ダウンロード
  4. 内容
  5. 設定手順
  6. 記事投稿時のイメージ
  7. 関連リソース

特徴

  • TuneDoc はつんどくと読みます。 ( TuneDoc のスペリングはアサノさん ( Mushline ) からアイデアをいただきました。 )
  • 記事タイトルにリンクアンカーテキスト、記事本文に URI 、記事概要にそれに関するメモコメントを書くだけ。タグを書く必要はありません。
  • ひとつの URI メモごとに RSS に記録します。
  • URI メモは、いつメモしたかが後から重要になってくるため、日付ごとにひとつの記事としてまとめるようにしています。
  • Movable Type 3.11-ja version と Movable Type 2.661 version を用意しています。
    • Movable Type 3.11-ja version はサブカテゴリに対応しています。
  • コメント機能を使っていません。
  • トラックバック機能を使っていません。
  • Valid XHTML 1.0 Strict です。
  • 一部の UA を除き、 HTTP ヘッダは application/xhtml+xml で提供されます。 ( MT hxxks - Another HTML-lint と text/html と Movable Type )

要するに、公開用というよりは自分用、もしくは RSS リーダ用と言った方が良いかもしれません。

使用条件

  • PHP を使っている部分がありますので、 PHP を動かせるサーバに Movable Type を設置していることが条件になります。
    • と言っても、 UA 判別と include くらいしか使っていませんので、それを使わなければ HTML ベースでも充分使えます。
  • CSS は同梱していませんので、自作してください。
  • TuneDoc template set の改変はご自由にどうぞ。というか改変しないと色々と機能が足りないかと思います。
    • あくまで実験を兼ねて作っただけですので、機能追加の要望や質問などに対応するつもりはありません。
  • 使用報告は不要です。 ( 禁止ではありません )
  • TuneDoc template set を使って作成した Weblog 内に配布元へのリンクを入れることも不要です。 ( 禁止ではありません )

内容

どちらの version も、テンプレートの内容が少し違うだけで、書庫の内容に違いはありません。

  • archive_template
    • tunedoc_category.txt
    • tunedoc_daily.txt
    • tunedoc_item.txt
    • tunedoc_monthly.txt
  • index_template
    • tunedoc_archives.txt
    • tunedoc_index.txt

設定手順

どちらの version も、設定は同じです。 設定項目名は Movable Type 3.11-ja に準じていますので、 Movable Type 2.661 を使っている方は適宜読み替えてください。

  1. Movable Type の管理画面の「新しいウェブログの作成」より、新規の Weblog を作成します。
  2. 「テンプレートの設定」
    • 「メインページ」の出力ファイル名を index.php に変更し、テンプレートの中身に tunedoc_index.txt の内容を貼り付けます。
    • 「アーカイブページ」の出力ファイル名を archives.php に変更し、テンプレートの中身に tunedoc_archives.txt の内容を貼り付けます。
    • 「個別エントリーアーカイブ」のテンプレートの中身に tunedoc_item.txt の内容を貼り付けます。
    • 「日別エントリーアーカイブ」のテンプレートの中身に tunedoc_monthly.txt の内容を貼り付けます。
    • 「カテゴリーアーカイブ」のテンプレートの中身に tunedoc_category.txt の内容を貼り付けます。
    • 「新しいアーカイブ・テンプレートを作る」をクリックし、「テンプレートの名前」を「日別アーカイブ」と書き、テンプレートの中身に tunedoc_daily.txt の内容を貼り付けます。
  3. 「ウェブログの設定」→「設定」
    • 「新規エントリーのデフォルトのテキストフォーマット」を「なし」に変更します。
    • 「優先するアーカイブのタイプ」を「日別」にします。
    • 「アーカイブ・ファイルの拡張子」を「 php 」にします。
  4. 「ウェブログの設定」→「アーカイブの設定」
    • 「個別」にチェックを入れ、「アーカイブ・ファイルのテンプレート」の欄に <$MTArchiveDate format="%Y/%m/%d/%H%M"$>_inc.inc と記述します。
    • 「月別」にチェックを入れ、「アーカイブ・ファイルのテンプレート」の欄に <$MTArchiveDate format="%Y/%m/"$>index.php と記述します。
    • 「カテゴリ別」にチェックを入れ、「アーカイブ・ファイルのテンプレート」の欄に <$MTSubCategoryPath$>index.php と記述します。 ( Movable Type 2.661 の場合は、 <$MTArchiveCategory dirify="1"$>index.php と記述します。 )
    • 日別アーカイブの追加
      1. 「新しく、テンプレートとアーカイブを関連付ける。」から、「アーカイブの種類」を「日別」、テンプレートを「日別アーカイブ」として「追加」をクリックします。
      2. 「日別」にチェックを入れ、「アーカイブ・ファイルのテンプレート」の欄に <$MTArchiveDate format="%Y/%m/%d/"$>index.php と記述します。
  5. 「サイトの再構築」を行って完成です。

記事投稿時のイメージ

新規記事投稿画面 記事タイトルにリンクアンカーテキスト、記事本文に URI 、記事概要にそれに関するメモコメントを書くだけ。タグを書く必要はありません。 概要を書かなかった場合は、自動で URI が記事内に記述されます。

実際の記事画面 実際のサンプルは、 TuneDoc - 2004/10/28 をご覧ください。

関連リソース

リプライ

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

新潟県中越地震に関する義援金・支援物資提供窓口のまとめ

記事データ

投稿者

望月真琴

投稿日時

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

タグ
概要

「中越地震」「義援金」といった検索キーワードで「はてなで義援金を送付する手順」に辿り着く方が多かったため、さらにジャンルごとに各窓口をまとめています。

リプライ

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

記事本文

この記事について

「中越地震」「義援金」といった検索キーワードで はてなで義援金を送付する手順に辿り着く方が多かったため、その方たちに対して微力ながら情報提供をする目的で書きました。

この記事内にない情報をご存知の方は、是非コメント欄にてお教えいただくと幸いです。 在宅時であればなるべくこまめに情報を追加していこうと思います。

都道府県庁による義援金・物資提供に関する情報提供、問い合わせ窓口など

トップページから辿り着けるものしか探していないので、漏れがあるかもしれません。 なお、新潟県の県地震災害対策本部設置について:平成16年新潟県中越地震に関する情報にリンクを張っているだけのものは除外しました。 また、義援金・物資提供に絞って調べているので、「特に見当たらず」と書いているところも、単に募集等をしていないだけで、何らかの支援などを実施している・実施したところがほとんどですので、誤解の無いようにお願いします。

新潟県庁
1 希望物資
食料品
  1. パックごはん、カップ麺、缶詰、菓子類、乳児用ミルク、離乳食
  2. お茶(PET)、飲料水(PET)
生活必需品
  1. 紙コップ、紙ざら、歯ブラシ、石けん、シャンプー、タオル、トイレットペーパー、ティッシュ、生理用品、ラップ
  2. オムツ、大人用オムツ
  3. 毛布
  4. 使いすてカイロ、電池

衣類、靴類については、既にご連絡いただいたものから順に対応しています。

2 照会窓口
新潟県 災害対策本部 出納部 (102会議室)
  • TEL (025)−280−5987
  • FAX (025)−280−5989
  • Email kyuen@mail.pref.niigata.jp 携帯メールは返信が困難となります(添付ファイルがあります)。 パソコンのメールでお願いします。
  • 受付時間 8:30 〜 20:00

※ホームページに掲載してある市町村については、品目が合致した場合には上記窓口に連絡は不要です。 (直接お送り下さい。)

3 その他
  • 義援物資の受付は、市町村でも受付しています。
  • ホームページ公開は2市町です。
  • 他に6市町村で受け入を行っていますが、既に連絡をいただいたものを順に振り向けています。
  • 状況がかわりましたらホームページに掲載します。
  • 〒950-8570新潟市新光町4番地1 新潟県 災害対策本部 出納部 (102会議室)
  • TEL:025-280-5987 FAX:025-280-5989
  • E-mail: kyuen@mail.pref.niigata.jp
3 受付期間

平成16年10月25日(月)から平成16年12月30日(木)まで

4 義援金取扱口座
(1) 銀行振込の振込口座
受付機関 金融機関 口座番号 口座名
新潟県
  • 第四銀行県庁支店
  • 北越銀行県庁支店
  • 大光銀行新潟支店
  • 新潟県信連本店
  • 新潟県労働金庫新潟南支店
  • (普)1262027
  • (普) 248088
  • (普)2215887
  • (普)0002256
  • (普)0628655
新潟県災害対策本部
日本赤十字社新潟県支部
  • 第四銀行白山支店
  • 北越銀行田町支店
  • 大光銀行学校町支店
  • 新潟県信連本店
  • (普)1546059
  • (普) 245195
  • (普) 652800
  • (普)0002245
日本赤十字社新潟県支部
(注)
  1. 第四銀行、北越銀行、大光銀行及びJA(農業協同組合)・JAバンク新潟県信連の各本支店における窓口での振込については、手数料は無料です(ATM及びインターネットバンキングでの振込は有料となります)。
  2. 労働金庫は全国の労働金庫の窓口での振込について、手数料は無料です(ATM及びインターネットバンキングでの振込は有料となります)。
  3. 上記以外の他金融機関からの振込については、有料扱いとなります。
(2) 郵便振替の振替口座
受付機関 口座番号 口座名
新潟県 00510-8-725 新潟県災害対策本部
日本赤十字社新潟県支部 00530-2-2000 日本赤十字社新潟県支部
(注)
  • 窓口での振替手数料は無料です。(ATM及びインターネットバンキングでの振込は有料となります。)
  • 日本赤十字社新潟県支部に払込む場合は、通信欄に「新潟地震」と明記してください。
5 現金での受付は次の場所で行っています
  • 新潟市新光町4番地1 県庁10階  新潟県出納局管理課決算・資金係
  • 新潟市関屋下川原町1丁目3番12号  日本赤十字社新潟県支部

(注)受付時間は、土曜、日曜、祝日を除く午前9時から午後5時までです。

北海道庁
  • 特に見当たらず
青森県庁
  • 特に見当たらず
岩手県庁
宮城県庁
  • 特に見当たらず
秋田県庁
  • 特に見当たらず
山形県庁
福島県庁
  • 特に見当たらず
茨城県庁
  • 特に見当たらず
栃木県庁
  • 特に見当たらず
群馬県庁
埼玉県庁
  • 特に見当たらず
千葉県庁
東京都庁
  • 特に見当たらず
神奈川県庁
  • 特に見当たらず
富山県庁
石川県庁
  • 特に見当たらず
福井県庁
  • 特に見当たらず
山梨県庁
  • 特に見当たらず
長野県庁
岐阜県庁
  • 特に見当たらず
静岡県庁
  • 特に見当たらず
愛知県庁
  • 特に見当たらず
三重県庁
  • 特に見当たらず
滋賀県庁
  • 特に見当たらず
京都府庁
  • 特に見当たらず
大阪府庁
  • 特に見当たらず
兵庫県庁
  • 特に見当たらず
奈良県庁
  • 特に見当たらず
和歌山県庁
  • 特に見当たらず
鳥取県庁
  • 特に見当たらず
島根県庁
岡山県庁
  • 特に見当たらず
広島県庁
  • 特に見当たらず
山口県庁
徳島県庁
  • 特に見当たらず
香川県庁
  • 特に見当たらず
愛媛県庁
  • 特に見当たらず
高知県庁
  • 特に見当たらず
福岡県庁
佐賀県庁
長崎県庁
  • 特に見当たらず
熊本県庁
  • 特に見当たらず
大分県庁
  • 特に見当たらず
宮崎県庁
  • 特に見当たらず
鹿児島県庁
  • 特に見当たらず
沖縄県庁
  • 特に見当たらず

リプライ

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

2004-10-27T15:00+09:00 - ポイントで募金! < jizo.net

はてなダイアリー - はてな義援金窓口  ちょっと調べてみたら、上記のサイトを見つけた。  なるほど・・・って感じ。  これだと募金者にとってのハードルは低い。  かつ企業にもメリットが出てくる。  知名度は低いが、同じようなものにこういうのもある。 2ch検索: ...

概要 ( excerpt ) の実装状況調査

記事データ

投稿者

望月真琴

投稿日時

2004-10-26T03:05+09:00

タグ
概要

他の Weblog ツールや Weblog サービスでも概要 ( excerpt ) は実装されているのか ? という疑問を抱きました。 この疑問を解決するには、実際にトラックバックを送ってもらえば良い、そう考えたため、トラックバックを募集します。

リプライ

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

記事本文

概要 ( excerpt ) は Movable Type 以外の Weblog でも実装されているのか ?

概要 ( excerpt ) の重要性にて概要 ( excerpt ) についてつらつらと述べましたが、果たしてこれは他の Weblog ツールや Weblog サービスでも実装されているのか ? という疑問を抱きました。

というのも、はてなで義援金を送付する手順という記事を書き、はてな義援金窓口 - 「平成16年新潟県中越地震」義援金の受付についてに対してトラックバックを送ったのですが、そこに送られた一連のトラックバックを眺めて、あることに気付いたのです。

まず、私が送ったトラックバック。 これはあらかじめ概要 ( excerpt ) を記述した上でトラックバックを送っています。 その部分のソースを見てみると、 <li><a href="http://hxxk.jp/memo/2004/10/24/1937.php" title="こうした試みがあるなら是非賛同したいということで、こちらを通じて義援金を送付しようと思います。これまでに、一度もはてなを利用したことがない方でも義援金を送られるように手順を示します。">はてなで義援金を送付する手順</a></li> といったように、 MTPingTitle ( 記事タイトル ) がアンカーテキストとなって、 a 要素の href 属性に MTPingURL 、 title 属性に MTPingExcerpt が記述されています。

次に、はてなダイアリーユーザーから送られたトラックバックを見てみます。 <li><a href="http://d.hatena.ne.jp/von_yosukeyan/20041024">http://d.hatena.ne.jp/von_yosukeyan/20041024</a></li> といったように、 Movable Type でいうところの MTPingURL がそのままアンカーテキストとなっています。

ここで、同じはてなダイアリーユーザーから送られたトラックバックにも、もうひとつのパターンがあることに気付きました。 <li><a href="http://d.hatena.ne.jp/nmomose/20041024#niigata" title=" 昨日新潟で大きな地震が起きたのをきっかけに、地震予知関係の掲示板などのページをアンテナに加えた(サイドバーの「他webのアンテナ」のボックス)。 昨日の夜はヒヌカン☆クラブでチャットをやっていて、新 ...">[一般]新潟県中越地震のこと</a></li> といったように、私が送った形式と同じようにトラックバックが送信されているのです。

はてなダイアリーのトラックバックの送信方法がどう設計されているのかを水月るりさん ( All you need is LOVE!!! | love all ... personal memo ... ) に尋ねると、トラックバック ping を入力するフォームはあるけれど、概要を記述するフォームはないそうです。 では、はてなダイアリー同士のトラックバックに、どうやって <li><a href="http://d.hatena.ne.jp/nmomose/20041024#niigata" title=" 昨日新潟で大きな地震が起きたのをきっかけに、地震予知関係の掲示板などのページをアンテナに加えた(サイドバーの「他webのアンテナ」のボックス)。 昨日の夜はヒヌカン☆クラブでチャットをやっていて、新 ...">[一般]新潟県中越地震のこと</a></li> のような送り方をしているのか ? はてなダイアリー以外のサービスやツールは ?

実際にトラックバックを募集してみる

この疑問を解決するには、実際に様々な Weblog ツール、 Weblog サービスからトラックバックを送ってもらえば良い、そう考えました。 しかし、ただ送ってもらうだけでは私にしかメリットがないので、送っていただける方にもメリットがあるようにしなければなりません。 わざわざ記事をひとつ書いてもらい、さらにトラックバックまでよこせと言われて、はいやりましょうと同調してくれる人はそう多くはないでしょう。

そこで、記事の内容をある程度こちらで定めておき、概要部分では自分の Weblog の宣伝をしてもらうという方法を考えてみました。 以前、私は 無分別なトラックバックは spam と何ら変わらない - アフターフォローをするのか ? にて、 トラックバックは関連のある記事と記事との通信を可能にする技術であり、宣伝などの手段に用いられるものではない と書きましたが、今回は宣伝をしてもらうことを前提とした記事に対して、宣伝トラックバックを募集するという形式になりますので、充分記事同士の関連性は確保できると思います。

募集要項

まず、記事の冒頭に、 Weblog 自体の概要を書いていただきます。 以下の例を元にして、コメントアウトしている部分を書き換えてください。

<p>
<a href="http://hxxk.jp/2004/10/26/0305">概要 ( excerpt ) の実装状況調査</a>にて<q cite="http://hxxk.jp/2004/10/26/0305" title="概要 ( excerpt ) の実装状況調査">記事の内容をある程度こちらで定めておき、<em>概要部分では自分の Weblog の宣伝をしてもらう</em></q>という試みが行われているので参加してみます。
</p>

<dl>
  
  <dt>Weblog の名称</dt>
  <dd>
  <p>
  <!-- あなたの Weblog の名称を書いてください -->
  </p>
  </dd>
  
  <dt>Weblog のトップの URI</dt>
  <dd>
  <p>
  <!-- あなたの Weblog の URI を書いてください -->
  </p>
  </dd>
  
  <dt>あなたのお名前</dt>
  <dd>
  <p>
  <!-- あなたのお名前を書いてください ( ハンドルで構いません ) -->
  </p>
  </dd>
  
</dl>

次に、概要、またはそれに類するものを記述する部分に、 あなたの Weblog のキャッチコピーを書いてください。 トラックバックの技術仕様 - excerpt によると、 Movable Typeでは、この文字列が256文字以上の場合は252文字に削られ、最後に「...」が付きます。 とあるため、ある程度限られた文字内で、効果的なキャッチコピーを書く必要があります。

概要まで書き終えたら、概要 ( excerpt ) の実装状況調査 - トラックバック受付記事に対してトラックバックを送信してください。 ( この記事に対して宣伝トラックバックを送らないようにしてください。 ) なお、記事の冒頭に参加表明文と、 Weblog の名称と URI 、あなたのお名前を記述したあとは、何も書かなくても構いませんし、この試みに対するご意見やご指摘を書かれても構いません。

なるべく多くの種類の Weblog ツール、 Weblog サービスの実装状況が知りたいので、気軽に参加していただけると嬉しいです。 よろしくお願いします。

現在は締め切っています。 また後日改めて募集するかもしれません。

予想される質問と回答

Q. Weblog ツールやサービスの種類は ?

A. 何でも構いません。 hxxk.jp は Movable Type を使用していますが、 Movable Type からのトラックバック送信も歓迎します。 また、既に同じツールやサービスを使われている人がトラックバックを送信していた場合でも、遠慮せずに送信してください。 ( 調査対象は多い方が望ましいため。 )

Q. 特にツールやサービスを使わずに自前で記事を書いているが参加したい

A. 概要 ( excerpt ) の実装状況調査 - トラックバック受付記事 - Trackback form からトラックバックを送信することができます。 あらかじめ記事を書いた上で、各フォームに必要事項を記入して送信してください。

Q. 記事のタイトルは統一しないのか ?

A. 統一しません。 トラックバックを送っていただく記事を指定することで統一は図れますし、記事のタイトルはその人の個性が出やすいものであると思うので、私からは「こういった記事タイトルでトラックバックをしてください」といった指定は特に行いません。

Q. 本文中にタグを記述できないシステムなのですが ?

A. Weblog サービスによってはそういったものもあるかもしれません。 そういった場合は、 Weblog の名称 : あなたの Weblog の名称 のように、適宜記述方式を変更してください。 ( ただし、言い回しは変更しないように注意してください。 )

Q. 概要を書く欄がない、または分からない

A. そういった場合は、通常行っているやり方でトラックバックを送信されて構いません。

Q. いつまでトラックバックを募集するのか ?

A. 無期限に募集するつもりはありませんが、まだ明確な募集締め切りは決めていません。 ある程度トラックバックが集まった時点で締め切りを検討し、この記事内で告知します。

現在は締め切っています。 また後日改めて募集するかもしれません。

Q. 参加者リストなどを別途作るのですか ?

A. 未定です。 今後の考察をどうするかにもよりますが、Weblog ツール、 Weblog サービスごとにまとめなおすかもしれません。

Q. トラックバックの表示順は ?

A. 新しいものが一番下に来るようなテンプレートになっています。

募集締め切りについて

2004-10-26T03:27:44+09:00 現在、絶賛募集中です。

現在は締め切っています。 また後日改めて募集するかもしれません。

リプライ

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

概要 ( excerpt ) の重要性

記事データ

投稿者

望月真琴

投稿日時

2004-10-25T00:04+09:00

タグ
概要

ほとんどのトラックバックは概要 ( excerpt ) を記述していないために、トラックバック欄に表示される内容が記事の冒頭部分となってしまっているものばかりです。トラックバックを受信した側は、そういったトラックバックでは記事の概要をつかめません。

リプライ

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

記事本文

Movable Type で概要 ( excerpt ) を書かない人が多すぎる

常々思っていたことですが、 Movable Type によるトラックバック機能において、概要 ( excerpt ) を正しく使いこなしていない人が多い、というものがあります。

例えば、 Movable Type 日本語版サイト: Movable Type 3.1日本語版の提供を開始のトラックバック欄を見ると、やはり新バージョンのリリースということで多くのトラックバックが寄せられています。 ( というか、私が送ったトラックバックもその中に混じっていますが。 ) しかし、ほとんどのトラックバックは概要 ( excerpt ) を記述していないために、トラックバック欄に表示される内容が記事の冒頭部分となってしまっているものばかりです。

Movable Type のトラックバックの表示方法

Movable Type におけるトラックバックの表示方法はどうなっているか。 デフォルトの個別エントリアーカイブの該当箇所を見ると、次のようになっています。

<MTPings>
<p id="p<$MTPingID$>">
» <a href="<$MTPingURL$>"><$MTPingTitle$></a> from <$MTPingBlogName$><br />
<$MTPingExcerpt$> <a href="<$MTPingURL$>">[続きを読む]</a>
</p>
<p class="posted">トラックバック時刻:  <$MTPingDate$></p>
</MTPings>

テンプレート・タグ - MTPingExcerpt を見ると、

MTPingExcerpt

送られてきたトラックバックの概要。

とあります。 次に、トラックバック - pingの送信を見ると、 クエリーのパラメータには以下があります: title (エントリーのタイトル)、excerpt (エントリーの概要。80文字以上の場合は80文字に削られ、最後に「...」が付加)、url (エントリーのパーマリンク(permalink))、およびblog_name (エントリーが投稿されたウェブログ名) とあります。 よって、 <$MTPingExcerpt$> は、 ping によって送られてきた <$MTEntryExcerpt$> ということになります。

しかし、記事中に <$MTEntryExcerpt$> が書かれていなくても記事は成り立ちます。 そもそも、どう使うかを知らない人の方がもしかしたら多いのかもしれません。 そういった記事の場合の <$MTEntryExcerpt$> は、記事の最初の 20 語から自動的に生成されます。

概要に載せる文字数

<$MTEntryExcerpt$>タグを使うときに、エントリーの概要が未設定の場合は、概要がエントリーの最初のN個の文字から自動的に生成されます。

デフォルトで概要の文字数は20です。

ここでは 20 文字とありますが、英語版の方の WEBLOG CONFIGURATION - Number of words in excerpt を見ると、 When you use the <$MTEntryExcerpt$> tag, and you have not defined an excerpt for your entry, the excerpt is auto-generated from the first N words of your entry. とあるため、訳の時点で誤りがあったと見て、 20 であると捉えた方が良いと思います。 また、トラックバックの技術仕様 - excerpt によると、 Movable Typeでは、この文字列が256文字以上の場合は252文字に削られ、最後に「...」が付きます。 とのことなので、「...」を含めて、 255 バイト分が <$MTPingExcerpt$> に割り当てられたフィールドということになります。 <$MTEntryExcerpt$> を記述する場合、あまり長くなりすぎないように気を付ける必要があります。

概要 ( excerpt ) を書かないことによる弊害 (1)

単純に、トラックバックを送信した際に、トラックバックを受信した側で記事の概要をつかめないということが弊害として挙げられます。 ( Movable Type の検索テンプレートでも <$MTEntryExcerpt$> が関連してきますが、それはまた別の機会に。 )

<$MTEntryExcerpt$> が記述されていなければ、記事の最初の部分を概要として自動生成がなされます。 しかし、それは果たして概要たりえるのでしょうか ? 私のように、後半の簡単なまとめ部分を <$MTEntryExcerpt$> に記述することが多い場合は、最初の部分を抜粋されても全く概要になりません。

Movable Type 日本語版サイト: Movable Type 3.1日本語版の提供を開始のトラックバック欄を見てみると、冒頭にて お待たせいたしました。Movable Type 3.1日本語版の提供を開始いたしました。 といった movabletype.jp のアナウンスを引用している weblog がいくつか見受けられ、それをそのまま概要として自動生成してトラックバックを送っている状態になっています。 要するに、引用元であるトラックバック先の記事内に、その引用した文を概要として送りつけているのです。

これは概要云々よりも文章として矛盾を孕んでしまうため、トラックバックを送ると決めている場合は、冒頭でいきなり引用文から始めずにこれから書こうとすることを簡単に説明するか、あるいは素直に概要 ( excerpt ) 欄に概要を記述するようにすべきだろうと思います。

概要 ( excerpt ) を書かないことによる弊害 (2)

普段、一般的なブラウザで Movable Type による記事を閲覧する場合に、概要 ( excerpt ) を意識することはほとんど無いと思います。 個別アーカイブエントリーの head 要素には <$MTEntryTrackbackData$> が配置されているので、ソースを表示すれば見ることはできるのですが。 たとえば、この記事の前項までの部分を一旦投稿してできたソースから <$MTEntryTrackbackData$> を抜粋すると、

<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="http://hxxk.jp/mt/2004/10/25/0004.php"
    trackback:ping="http://hxxk.jp/sys/mt3/mt-tb.cgi/224"
    dc:title="概要 ( excerpt ) の重要性"
    dc:identifier="http://hxxk.jp/mt/2004/10/25/0004.php"
    dc:subject="policy"
    dc:description="ほとんどのトラックバックは概要 ( excerpt ) を記述していないために、トラックバック欄に表示される内容が記事の冒頭部分となってしまっているものばかりです。トラックバックを受信した側はそういったものでは記事の概要をつかめません。"
    dc:creator="makoto"
    dc:date="2004-10-25T00:04:32+09:00" />
</rdf:RDF>

というように、 rdf:Description 要素の dc:description 属性に <$MTEntryExcerpt$> が記述されています。 これは <$MTEntryTrackbackData$> という名が示す通り、トラックバックを行う際に用いるデータのため、閲覧者にとって直接的に関わりのあるものではありません。

しかし、ブラウザではなくて RSS リーダなどに視点を移すとどうでしょうか。 Movable Type では RSS 1.0 、 RSS 2.0 、 ATOM 0.3 などを標準で提供しています。 これらは description 要素 ( ATOM の場合は summary 要素 ) を持っており、ここに <$MTEntryExcerpt$> が記述されています。 ( ただし、 Movable Type 3.11-ja の RSS 1.0 と RSS 2.0 のデフォルトテンプレートでは、何故か <$MTEntryBody$> が記述されていますが……何で description に <$MTEntryBody$> を持ってくるのか理解に苦しみます。 )

これも同様に、能動的に <$MTEntryExcerpt$> が書かれていなければ記事の冒頭部分を概要として自動生成します。 トラックバックの場合に比べ、 RSS の場合はそれでも各記事の概要を掴めるかもしれません。 しかし、機械的に生成された概要よりも、能動的に作者が書いた概要の方が、よりサイト ( または記事 ) の概要として適していると思います。

リプライ

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

2005-02-26T15:57+09:00 - stanaka

こんにちは、田中です。最近、旅行記向けのMT用テンプレートを作成したいと思って、色々と試してみてで概要がnullだと勝手に本文の内容が入ってしまうので変だなーと思っていました。このサイトで疑問が解決しました。 実は概要のところを旅行記のテンプレートでその日の観光ポイントを入れる場所にでもと思っていたのですが、こちらの投稿を読むと邪道と言われそうですね。観光ポイントなので概要といえないことはないのですが厳密に言うと違う。 では、きちんと概要を書かせるのかと言うと人間というのはさぼりたがるものだし、手間を増やすのなら何らかのモチベーションアップとなるような利益がないと結局は面倒だとなりやらないことになります。概要を書くことによりアクセスアップにつながるとかそのようなことが仕掛けとしてあれはばいいのでしょうが。

2005-02-27T21:45+09:00 - 真琴

どうも、こんばんは。 概要が null だと本文が入ってしまう、というのはやはりあまり知られていないのでしょうか ? 私は最初から概要を入れていたので、「入れなかったら本文から持ってくるのかあ」と勝手に納得していました。 また、「観光ポイントを入れる場所」や「モチベーションアップとなるような利益」については良い材料になりそうなので、後日別途記事にするかもしれません。

2005-04-04T00:18+09:00 - 半年経ってやっと理解できた < 時間捻出家ユウキの徒然日記

MovableType3.01D-jaを使用してサイトを運営していたのですが、今頃になってやっと「概要(excerpt)」の使い方がわかりました。要はあれが「概要(excerpt)」なんだわ。↑おーい・・・。キーワードと間違えて概要にキーワードぶち込んでPING飛ばしたらキーワードが表示され...

2005-04-21T21:02+09:00 - カテゴリーアーカイブと月別アーカイブはタイトルのみ表示 < Nakamura's Weblog

カテゴリーアーカイブと月別アーカイブのページをPHP化してページ分割したところ、...

2005-04-29T03:18+09:00 - iwaim

判別できるはずの引用部分を自動生成する概要に含めてしまう MT の実装が腐っていると思いました。

2005-04-30T15:29+09:00 - MTEntryExcerptタグのバグ? < klaxon.org

「MTEntryExcerpt」タグで、「convert_breaks="1"」のアトリビュートを使うと、個別エントリーアーカイブ、カテゴリーアーカイブで入力した概要が反映されず、自動生成された概要が表示されるが、「no_generate="1"」を使うことで解決。

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

確かに、判別できるはずですよねえ。 blosxom はそのへんどうなんでしょう……と思っていわいさんのところの RSS を見てみたら <description>nothing</description> とだけしか書いてありませんでした……。

はてなで義援金を送付する手順

記事データ

投稿者

望月真琴

投稿日時

2004-10-24T19:37+09:00

タグ
概要

こうした試みがあるなら是非賛同したいということで、こちらを通じて義援金を送付しようと思います。これまでに、一度もはてなを利用したことがない方でも義援金を送られるように手順を示します。

リプライ

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

記事本文

はじめに ( 追記 )

この記事は各種義援金受付窓口が開設される前に書いた記事です。 記事を書いた時点ではまだ義援金受付窓口がほとんど開設されていないという状況であり、そんな中比較的素早く義援金受付を開始したはてな義援金窓口についてのみ記述してあります。 現在はこれ以外にも多くの義援金受付窓口が開設されてありますので、はてな義援金窓口に拘らず、ご自分が利用しやすいものを選択するようにしてください。

義援金という検索キーワードでこの記事に辿り着く方が多く見受けられたため、この部分を追記しました。 新潟県中越地震に関する義援金・支援物資提供窓口のまとめにて義援金や物資提供の窓口に関する URI をまとめましたので、合わせてご活用ください。

「平成 16 年新潟県中越地震」義援金

既に各種報道でも多くの情報が発表されている今回の新潟県の地震 ( 関連情報は雑念雑記:2004年10月分 - 新潟県中越震災関連情報リストを参照 ) ですが、水月るりさん ( All you need is LOVE!!! | love all ... personal memo ... ) から、インターネットから義援金を送ることができるということを教えていただきました。

私ははてなダイアリーのユーザーではありませんが、はてなアンテナの方はよく使わせていただいていました。 お世話になるばかりでしたので、こうした試みがあるなら是非賛同したいということで、こちらを通じて義援金を送付しようと思います。

義援金送付手順

これまでに、一度もはてなを利用したことがない方でも義援金を送られるように手順を示します。 クレジットカードをお持ちの方は、カード購入を利用すればコンビニエンスストアや銀行、郵便局などに出向く必要はありません。

  1. まず、はてな - 1)ユーザー登録しましょうをよく読んだ上で、はてな 新規ユーザー登録からユーザー登録を行います。 ( 既にユーザーである方はこの部分は必要ありません。 ) なお、ポイント送信時に、いくつかの送信システム上の制約が課されますので、ユーザー登録の前に義援金送付時の注意点を読まれることをお勧めします。
  2. はてな ポイント購入へ行き、自分が一番とっつきやすい方法でポイントを購入します。今回、私はコンビニエンスストア支払いによるポイント購入を選択しました。
  3. はてな コンビニエンスストア支払いによるポイント購入にて、購入希望ポイントを選択し、次に支払い先のコンビニエンスストア ( セブンイレブン、ローソン、ファミリーマートのいずれか ) を選択します。今回、私は自宅から一番近いという理由でセブンイレブンを選択しました。
  4. 購入ポイント ( 1 ポイント = 1 円 ) + 手数料 ( 250 円 ) の合計額と、払込票番号が表示され、「インターネットの代金支払」とレジにてお申し出の上、払込票番号「*************」をお伝え下さいといった支払い方法を指示されます。 ( 同様の文面でユーザー登録時のメールアドレス宛てにメールが送信されますので、それを携帯電話に転送しておくか、メモとして控えておくといいでしょう。 )
  5. セブンイレブンのレジにて「インターネットの代金支払をお願いします」と告げると、先ほどの払込票番号を尋ねられるのでそれを伝えます。店員の方がその番号を打ち込んだ後、名前 ( ユーザー登録時に登録した名前、すなわち本名です ) と払込額を確認してきますので、間違いがなければその金額をレジにて支払います。
  6. しばらくすると入金確認のメールが届きますので、はてな ポイント支払・受取履歴にアクセスして、購入した分のポイントが加算されていることを確認します。
  7. はてな義援金窓口 - 第1回義援金募集についてをよく読み、義援金の趣旨をもう一度確認します。
  8. はてな ポイント送信から、 id:hatenacontrib に対してポイントを送信します。 ( 次項で詳しく解説します。 )

義援金送付時の注意点

  • 受付終了期日を2004年11月7日(日)までとさせていただきました。11月7日一杯は受け付けますとのことです。
  • 送信先ユーザー名のミスがないかよく確認してください。これを間違うと義援金として受け付けていただけない可能性があります。送信先ユーザー名は hatenacontrib と入力します。
  • 送信ポイントをよく確認してください。ポイント送信時には、5%の手数料が必要となりますし、送信後の残高が300ポイントを下回る場合は、送信できません。また、これ以降はてなのポイントを用いるサービスを利用予定の無い方は、この 300 ポイントは使えずに残ってしまうことになります。そのことをご理解いただいた上でポイントを送信してください。 2006 年 2 月に、このポイントの下限は撤廃されています。
    • 現在持っているポイントを x ポイント、送ろうとするポイントを y ポイントとすると、 x - 1.05*y が 300 以上になるような不等式を考えるといいと思います。
    • たとえば、現在 10,000 ポイント持っているとすれば、送ることができる最大のポイントは上記の式より 9,238 ポイント 9,524 ポイントとなります。
    • もちろん、送ることのできる全てのポイントを義援金として送る必要はありません。今後のポイントの使用予定と照らし合わせて、送るポイントを決めてください。
    • また、ご意見有難うございました。システムの制約上、手数料を無くすことができませんが、5%のポイント送信手数料については、そのまま同額をはてなにて上乗せして寄付したいと思います。とのことですので、 5000 ポイント送ったとすれば、株式会社はてな側で上乗せして、 5250 ポイント ( = 5250 円 ) として寄付してくださるようです。
  • 寄付内容の公開
    • お送り頂いたポイントについては、以下の情報の公開を検討しています
      • お送り頂いたポイントの総数(合計○ポイント)
      • お送り頂いた方のユーザー名(匿名の場合には匿名)
    とありますので、ユーザー名を公開されたくない場合は、匿名で送信するのチェックボックスにチェックを入れてください。

以下にスクリーンショットを用いて実際の手順を示します。 送信先ユーザー名やポイント数をしっかり確認しながら送付してください。

  1. サムネイル送信先ユーザー名、送信ポイントを確認して送信ボタンをクリック。
  2. サムネイル送信確画面で最終確認。 ( この画面で送信を押すとポイントが送信されます。 )
  3. サムネイル無事ポイントの送信が完了しました。確認メールがはてなから送られます。

最後になりますが、被害に遭われた方々にお見舞いを申し上げるとともに、僅かですが義援金を送らせていただいたことをこの場よりお伝えいたします。

リプライ

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

Valid Movable Type !!

記事データ

投稿者

望月真琴

投稿日時

2004-10-24T02:24+09:00

タグ
概要

私は、サイトの構築の一手段として Movable Type を選んだものを前者 ( Weblog ) 、とりあえず流行りに乗って、 Movable Type を使うことを目的としているものを後者 ( 「ブログ」 ) だと漠然と考えています。 ( 後者には、いわゆるレンタルブログサービスを含めてもいいかもしれません。 ) そういった意味では、悉くとまでは言わないまでも、大多数が inValid であると言われても仕方がないのかもしれません。

リプライ

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

記事本文

not Valid Movable Type ?

世間のMovable Typeで構築されてゐる「ブログ」のHTML文書が悉くinvalidなのは何うよ?

Movable Type は、デフォルトのテンプレートは少々難アリだけれど、テンプレートをカスタマイズすれば充分 Valid になりますよ、と思い、それを証明するために Movable Type によって構築され、かつ Valid なサイトを探すことにしました。

デフォルトのテンプレートも一応 The W3C Markup Validation Service では This Page Is Valid XHTML 1.0 Transitional! となりますが、よくよく見ると「とりあえず何とか Validator 通しました」といった印象を受ける箇所があるため、 The W3C Markup Validation Service で Valid であり、かつ正確な HTML であるものを選定しようと思います。

判断基準

  1. Google 検索: "Powered by Movable Type" "Valid XHTML" で検索
  2. 単に文章中の "Powered by Movable Type" が検索にひっかかった可能性もあるので、実際に Movable Type を使用しているか確認した上で、 Movable Type 使用部分のトップページを辿る
  3. The W3C Markup Validation Service でチェックし、 Valid であるもののみをリストアップ
  4. 次に、 Another HTML-lint gateway でチェックし、減点対象外のごく軽度のエラーなどで適宜判断

Another HTML-lint gateway のチェックについては、仮に満点であっても選定漏れの判断基準にするものもありますし、逆に減点対象のエラーであっても選定漏れの判断基準にしないものもあります。

たとえば、 HTTPレスポンスヘッダに指定されているメディアタイプ text/html は XHTML1.1 には指定しないようにしましょう。 というエラーは減点対象ですが、私は減点すべき対象ではないと個人的に考えていますので、このエラーがあっても選定漏れの判断基準とはしません。 ( Another HTML-lint と text/html と XHTML 1.1 )

逆に、 Movable Type のデフォルトのテンプレートの場合、 body 直下に #PCDATA を記述して、 div 要素で囲んでいるだけといった部分 などがありますので、その部分を改善しないまま使っている場合は選定漏れの判断基準としています。

選定結果

Chitatopops
Junkline
WASTEPAPER BASKET
:: y3 Land ::
orange waffle
drry+@->Weblog
柳田研究室 : yanagida-lab.com
Diary-bokuchin.net Weblog
SSのMovableType
小人さんへの置き手紙
Weblog Polyrhythm
Alternative Design Project by Momomo
まったり日記。
403
404
冷麺
Software Linkage
硝子の欠片を集める者達

感想

予想よりも選定に残ったサイトの数は少なかったです。 しかし、選定に残ったところはどこもしっかりと作りこまれている所ばかりでした。 文書構造という意味でも、スタイルシートという意味でも、そして記事の内容という意味でも。

ただ、そういったサイトはれっきとした Weblog であり、 「ブログ」 とは一線を画すものではないかという印象も受けました。

私は、サイトの構築の一手段として Movable Type を選んだものを前者 ( Weblog ) 、とりあえず流行りに乗って、 Movable Type を使うことを目的としているものを後者 ( 「ブログ」 ) だと漠然と考えています。 ( 後者には、いわゆるレンタルブログサービスを含めてもいいかもしれません。 ) そういった意味では、悉くとまでは言わないまでも、大多数が inValid であると言われても仕方がないのかもしれません。

リプライ

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

Movable Type 3.11 のサブカテゴリ機能についての所感 (4)

記事データ

投稿者

望月真琴

投稿日時

2004-10-24T01:14+09:00

タグ
概要

category/<$MTSubCategoryPath$>/index.html とアーカイブ・テンプレートのファイルに記述することによって、サブカテゴリの階層を保持したままディレクトリ構造を作ることができます。

リプライ

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

記事本文

カテゴリアーカイブのディレクトリ構造

Movable Type 3.11 にてサブカテゴリ機能というものが実装される前は、どのカテゴリにおいても全て同じレベルのカテゴリとして扱われていました。 すなわち、カテゴリアーカイブを置くディレクトリ以下に、全てのカテゴリアーカイブが並べられていたのです。 しかし、サブカテゴリと名がつくならば、親カテゴリより下位のディレクトリに置かれるのが自然だろうと思います。

Movable Type 3.11 のサブカテゴリ機能についての所感 (2) - MySQL 使用時におけるサブカテゴリの扱いにて用いたモデルを元に考えてみます。

  • www
    • internet
      • browser
        • firefox
          • extension
      • email
    • website
      • accessibility
      • bookmarklet
      • css
      • html
      • php

従来のカテゴリアーカイブのディレクトリ構造

前項のモデルを、実際に Movable Type 3.0 以前のものでカテゴリの設定を行った場合の URI は以下のようになります。 なお、カテゴリアーカイブが置かれる URI は、ウェブログの設定アーカイブの設定にてアーカイブ・ファイルのテンプレートを設定することで変更できますが、この例では category/<$MTArchiveCategory dirify="1"$>/index.html と設定したとして進めていきます。

  • <$MTBlogArchiveURL$>category/www/index.html
  • <$MTBlogArchiveURL$>category/internet/index.html
  • <$MTBlogArchiveURL$>category/browser/index.html
  • <$MTBlogArchiveURL$>category/firefox/index.html
  • <$MTBlogArchiveURL$>category/extension/index.html
  • <$MTBlogArchiveURL$>category/email/index.html
  • <$MTBlogArchiveURL$>category/website/index.html
  • <$MTBlogArchiveURL$>category/accessibility/index.html
  • <$MTBlogArchiveURL$>category/bookmarklet/index.html
  • <$MTBlogArchiveURL$>category/css/index.html
  • <$MTBlogArchiveURL$>category/html/index.html
  • <$MTBlogArchiveURL$>category/php/index.html

このように、元々トップレベルカテゴリの概念もサブカテゴリの概念もないため、 <$MTBlogArchiveURL$>category/ の直下に、全て同一レベルで配置されます。

サブカテゴリを含むカテゴリアーカイブのディレクトリ構造

次に、実際に Movable Type 3.11 でサブカテゴリの設定を行った場合の URI について考えてみます。 ウェブログの設定アーカイブの設定にてアーカイブ・ファイルのテンプレートの部分に何も設定をしなかった場合は以下のようになります。

  • <$MTBlogArchiveURL$>/www/index.html
    • <$MTBlogArchiveURL$>/www/internet/index.html
      • <$MTBlogArchiveURL$>/www/internet/browser/index.html
        • <$MTBlogArchiveURL$>/www/internet/browser/firefox/index.html
          • <$MTBlogArchiveURL$>/www/internet/browser/firefox/extension/index.html
      • <$MTBlogArchiveURL$>/www/internet/email/index.html
    • <$MTBlogArchiveURL$>/www/website/index.html
      • <$MTBlogArchiveURL$>/www/accessibility/index.html
      • <$MTBlogArchiveURL$>/www/bookmarklet/index.html
      • <$MTBlogArchiveURL$>/www/css/index.html
      • <$MTBlogArchiveURL$>/www/html/index.html
      • <$MTBlogArchiveURL$>/www/php/index.html

サブカテゴリを含むカテゴリアーカイブのアーカイブ・ファイルのテンプレート

さて、前項のように、サブカテゴリのレベルに合わせてカテゴリアーカイブのディレクトリが作られました。 ただし、これはウェブログの設定アーカイブの設定にてアーカイブ・ファイルのテンプレートの部分に何も設定をしなかった場合の話です。

何も設定をしなかった場合は <$MTBlogArchiveURL$> の直下に配置されますが、設計段階で <$MTBlogArchiveURL$>category/<$MTCategoryLabel$> のように、カテゴリアーカイブは category/ 以下にまとめて、管理をスムーズに行いたいと思うことがあるかもしれません。

そういった時に今までと同様 category/<$MTArchiveCategory dirify="1"$>/index.htmlウェブログの設定アーカイブの設定にてアーカイブ・ファイルのテンプレートを設定した場合、トップレベルカテゴリとサブカテゴリの区別なく、 <$MTBlogArchiveURL$>category/<$MTCategoryLabel$> として一様に配置されてしまいます。

きちんとディレクトリ構造を持ったまま設定したい場合はどうすればいいのか。 ウェブログ設定ガイド - アーカイブの設定を一通り読んでもそういった記述は特に見当たりません。 そこで、テンプレート・ タグに似たような機能を持ったタグがないか、それによって代替できないかを探してみました。

MTSubCategoryPath

テンプレート・ タグ - MTSubCategoryPath というテンプレート・タグがあります。

MTSubCategoryPath

ショートカット・タグ(通常のタグ)。 以下のテンプレート・コードが使われているかのように戻ります。

<MTParentCategories glue="/"><MTCategoryLabel dirify="1"></MTParentCategories>

この説明中にあるテンプレート・ タグ - MTParentCategories の解説を見てみると、

MTParentCategories

現在のカテゴリーの最上レベルの親から始まり、コンテナの各再帰で、現在のカテゴリーまでのパスまで続くコンテナ・タグ。

アトリビュート:

glue

リストをつなぎ合わせるテキスト

exclude_current

「1」を設定するとリストから現在のカテゴリーを除く

よって、今回のモデルにおける一番下位のレベルにある extension カテゴリを例にとって考えると、最上レベルの親 ( www カテゴリ ) から始まり、 internet → browser → firefox と続いて extension カテゴリまでつながります。 ( 各カテゴリは glue="/" の指定によって、 / で連結されます。 )

これより、 category/<$MTSubCategoryPath$>/index.html とアーカイブ・テンプレートのファイルに記述することによって、サブカテゴリの階層を保持したままディレクトリ構造を作ることができます。

  • <$MTBlogArchiveURL$>/category/www/index.html
    • <$MTBlogArchiveURL$>/category/www/internet/index.html
      • <$MTBlogArchiveURL$>/category/www/internet/browser/index.html
        • <$MTBlogArchiveURL$>/category/www/internet/browser/firefox/index.html
          • <$MTBlogArchiveURL$>/category/www/internet/browser/firefox/extension/index.html
      • <$MTBlogArchiveURL$>/category/www/internet/email/index.html
    • <$MTBlogArchiveURL$>/category/www/website/index.html
      • <$MTBlogArchiveURL$>/category/www/accessibility/index.html
      • <$MTBlogArchiveURL$>/category/www/bookmarklet/index.html
      • <$MTBlogArchiveURL$>/category/www/css/index.html
      • <$MTBlogArchiveURL$>/category/www/html/index.html
      • <$MTBlogArchiveURL$>/category/www/php/index.html

なお、従来は category/<$MTArchiveCategory dirify="1"$>/index.html のように dirify 属性を使うことで、日本語や空白文字が含まれるカテゴリ名への対処を行っていましたが、 MTSubCategoryPath は <MTParentCategories glue="/"><MTCategoryLabel dirify="1"></MTParentCategories> と同様のコードとなるため、 dirify="1" を改めて指定する必要はありません。

リプライ

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

Movable Type 3.11 のサブカテゴリ機能についての所感 (3)

記事データ

投稿者

望月真琴

投稿日時

2004-10-23T22:13+09:00

タグ
概要

<MTEntries> 〜 </MTEntries> の代わりに、 <MTEntriesWithSubCategories> 〜 </MTEntriesWithSubCategories> とすることで、そのカテゴリにサブカテゴリが設定されている場合、サブカテゴリの記事も含めて表示することになります。

リプライ

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

記事本文

カテゴリアーカイブにサブカテゴリを表示させる

Movable Type 3.11 のサブカテゴリ機能についての所感 (2) サブカテゴリの設定の失敗例 にて、 デフォルトのテンプレートでは、ある記事にサブカテゴリのみを設定していた場合、親カテゴリのアーカイブにはその記事は含まれません と述べました。 今回は、親カテゴリを指定することなく、サブカテゴリの指定のみで親カテゴリのアーカイブに反映させるテンプレートについて書きます。

デフォルトのカテゴリアーカイブ

デフォルト・テンプレート - カテゴリーアーカイブを見ると、そのカテゴリに属する記事の内容が <MTEntries> 〜 </MTEntries> で囲まれているのがお分かりでしょうか。

テンプレート・タグ - MTEntries - category=``category name'' によると、 MTEntries テンプレート・タグに category 属性を指定することで、そのカテゴリに属する記事を表示することができるということになります。 しかし、カテゴリアーカイブはそのアーカイブ自体が属するカテゴリを内部的に持っているため、 category 属性を指定してはいけません。 ( 指定しても、再構築時にエラーとなるわけではありません。 しかし、仮にカテゴリアーカイブにて <MTEntries category="mt"> 〜 </MTEntries> といった記述をしてしまうと、全てのカテゴリにおいて <MTEntries category="Foo AND mt"> 〜 </MTEntries> と指定したことと同じになってしまうため、 mt カテゴリに属していない記事は表示されなくなってしまいます。 )

よって、カテゴリアーカイブにおける <MTEntries> 〜 </MTEntries> は、そのカテゴリに属する記事を全て表示する、ということになります。 ( category 属性以外の属性、たとえば lastn 属性などで更に絞込みをすることは可能です。 )

しかし、これはあくまでそのカテゴリのみが表示対象となるため、そのカテゴリにサブカテゴリが存在していても、サブカテゴリは別のカテゴリとして扱われ、サブカテゴリの記事は含まれません。

MTEntriesWithSubCategories テンプレート・タグ

そこで、サブカテゴリ機能の実装と共に追加されたのが、 MTEntriesWithSubCategories テンプレート・タグです。

MTEntriesWithSubCategories

サブカテゴリーを認識しているMTEntriesコンテナ・タグの代わり。 これをカテゴリー・アーカイブ・テンプレートの中でMTEntriesの代わりに使って、テンプレートにそのカテゴリーに属するサブカテゴリーの全エントリーを含めるようにします。

アトリビュート:

Category

設定されると、MTEntriesWithSubCategoriesは、カテゴリーのOR付きリストとそのすべてのサブカテゴリーにまで拡張します (例: ``Parent Category OR Sub Category 1 OR Sub Category 2 OR Sub Sub Category 3 ... '')

そのほかの引数はすべて直接MTEntriesに渡されます。

<MTEntries> 〜 </MTEntries> の代わりに、 <MTEntriesWithSubCategories> 〜 </MTEntriesWithSubCategories> とすることで、そのカテゴリにサブカテゴリが設定されている場合、サブカテゴリの記事も含めて表示することになります。

MTEntriesWithSubCategories の実例

実際に、 <MTEntriesWithSubCategories> 〜 </MTEntriesWithSubCategories> を用いたカテゴリアーカイブがどのように作られるかを示してみようと思います。

Movable Type 3.11 のサブカテゴリ機能についての所感 (2) サブカテゴリの設定の失敗例にて例に出した Template sample 3.11 default: firefox アーカイブですが、 <MTEntriesWithSubCategories> 〜 </MTEntriesWithSubCategories> を用いる前は、 extension サブカテゴリを持っているはずの firefox カテゴリアーカイブに、 extension カテゴリの記事が表示されないという状態になっていました。

そこで、 <MTEntries> 〜 </MTEntries><MTEntriesWithSubCategories> 〜 </MTEntriesWithSubCategories> に書き換えて再構築をすると、 firefox カテゴリアーカイブに、無事 extension カテゴリの記事を表示することができました。

親カテゴリにおける注意点

カテゴリの運用方法にもよると思いますが、サブカテゴリ機能を使っていると、記事が存在しない親カテゴリというものが生じることがあります。 先ほど別件で作成した、 TuneDoc を例にとってみましょう。

TuneDoc - permutation-city というカテゴリアーカイブがあります。 これはトップレベルカテゴリが favourites カテゴリであり、そのサブカテゴリである irc カテゴリの更にサブカテゴリとして存在します。 このとき、 irc カテゴリや favourites カテゴリは、サブカテゴリを総称する意味しか持っておらず、その直下には記事が配置されていません。

こういったカテゴリにおける問題点については Ogawa::Memoranda: サブカテゴリー機能について考えてみた。 - 問題点の説明に詳しく書かれてありますが、 親カテゴリーのアーカイブがそもそも生成されないという現象 が発生します。 実際に http://hxxk.jp/mt/template_sample/tunedoc/favourites/irc/http://hxxk.jp/mt/template_sample/tunedoc/favourites/ にアクセスしても、 index.php ( この場合はカテゴリアーカイブ ) が存在しないために 403 Forbidden が返されるはずです。

デフォルトのテンプレートでは、 Main Index にカテゴリが階層化された状態で表示され、記事が存在しないカテゴリについてはリンクを張らないような条件式のテンプレートタグが使われているので、あまり気にする必要はないのかもしれません。 しかし、サブカテゴリのアーカイブを表示して、そこからブラウザのアドレスバーの URI を削って上の階層を見ようとした場合、またはカテゴリアーカイブ上で上の階層へのリンクを作成した場合などに不都合が出る可能性は充分にありますので、気に留めておいた方が良いかもしれません。

なお、親カテゴリがサブカテゴリを総称する意味で存在しているのではなく、基本的に親カテゴリに記事を配置して、その中でさらにカテゴリを絞る意味でサブカテゴリが使われている場合 ( たとえば、 TuneDoc - newsTuneDoc - mass-communication の例 ) はこの問題は関係ありません。

リプライ

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

2004-11-11T19:50+09:00 - http://uneri.daa.jp/weblog/archives/2004/11/1020.html < うねり。

10月20日に掲載した"記事の右肩に日付とカテゴリーを載せたんですが・・・"で困...

2005-01-09T15:19+09:00 - 使えるようで使えないサブカテゴリ < Mugifa_Net

MovableType 3.1x以降、標準装備されたサブカテゴリー機能。 「わーい、便利ー」と思ったのも束の間、壁にぶち当たってしまった。 なぜなら、※「あるカテゴリーに属するサブカテゴリにエントリが追加されたとき、その親カテゴリーにエントリーが一つもない場合、再構築さ...

RFC によるメールアドレスの local-part におけるピリオドの取り扱いについての考察

記事データ

投稿者

望月真琴

投稿日時

2004-10-23T12:28+09:00

タグ
概要

RFC 2822 における、 Some of the structured header field bodies also allow the period character (".", ASCII value 46) within runs of atext. An additional "dot-atom" token is defined for those purposes. という記述と、 If the string can be represented as a dot-atom (that is, it contains no characters other than atext characters or "." surrounded by atext characters) という記述が、 メールアドレスの@の直前にはピリオドは使ってはいけない ということの根拠になると思います。

リプライ

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

記事本文

よそで参考記事として出されるのは嬉しい

RFCを読まなかった携帯キャリアの罪 - Webビジネスコンサルタントのネタ帳のコメント欄にて、北村さん ( 曉に死す ) が メールアドレスに使える文字を参考記事として提示して下さっていました。 自分で活用しやすいように整理して web に記録していくので、必要とされる情報が私の記録の中にあるのならどうぞご活用ください、というのがこのサイトのスタンスです と言っているのですが、実際に活用されると非常に嬉しいものです。

メールアドレスに使える文字の補足

補足というか要点のみの抜粋ですが、 Some of the structured header field bodies also allow the period character (".", ASCII value 46) within runs of atext. An additional "dot-atom" token is defined for those purposes. ( いくつかの構造化されたヘッダフィールドボディはまた、一連のatext中ピリオド(".", アスキーコード46)が許可されている。 追加の「dot-atom」トークンがその目的で定義される。 ) という記述と、 If the string can be represented as a dot-atom (that is, it contains no characters other than atext characters or "." surrounded by atext characters) ( その文字列がdot-atomとして表現され得るならば(つまり、atextとatextに囲まれた「.」以外の文字が存在しないならば) ) という記述が、 メールアドレスの@の直前にはピリオドは使ってはいけない ということの根拠になると思います。

例を挙げて示すと、

  • "." で始まる local-part で構成されるメールアドレス ( 例 : .makoto@hxxk.jp )
  • "." で終わる local-part で構成されるメールアドレス ( 例 : makoto.@hxxk.jp )
  • "." が連続する local-part で構成されるメールアドレス ( 例 : makoto..mobile@hxxk.jp )

これらのような local-part に存在する "." は、 atextに囲まれた「.」 ではありません。

RFC 2821 ? RFC 2822 ?

RFCを読まなかった携帯キャリアの罪 - Webビジネスコンサルタントのネタ帳にて根拠として取り上げられている RFCRFC 2821 の方ですが、私は RFC 2822 の方で前項のように理解していました。 これは単純に検索で Request for Comments: 2822 - Internet Message Format を見つけただけであって、 RFC 2821 の方を読むべきなのか RFC 2822 の方を読むべきなのかはあまり気に留めていませんでした。 RFC 2822 の方も知りたい情報のみを斜め読みしただけですし。

@の直前にピリオドがある等、RFC に準拠していないアドレスを含むメッセージを送受信できないでは、

概要

この資料では、Exchange 2000 Server と Exchange Server 2003 で、インターネット メール アドレスが xxxx.@xxxxxx や xx..xx@xxxxxx のように、ピリオドがメール アドレスの最後についていたりピリオドが連続しているような RFC2821 に準拠していないアドレスを含むメールを送受信できない現象について記述しています。

原因

Exchange 2000 Server と Exchange Server 2003 の SMTP サービスは、アドレスのフォーマットが RFC2821 に準拠していない場合エラー "501 5.5.4 Invalid Address" を返します。 RFC2821 では、"@" の前の文字列をピリオド"." で区切ることを許可しておりますが、区切り文字であるピリオドや"@" 等を連続して使用することを許可しておりません。 従いまして、このようなアドレスを持ったメッセージの送受信を拒否しています。

これは Exchange 2000 Server と Exchange Server 2003 の仕様です。

と書かれてありますし、 RFC 2821 を参考にした方が良いのかもしれません。

RFC 2821 を読んでみる

Request for Comments: 2821 - Simple Mail Transfer Protocol の、メールアドレスに関する部分の記述を読んでみると、

Mailbox = Local-part "@" Domain

Local-part = Dot-string / Quoted-string
      ; MAY be case-sensitive

Dot-string = Atom *("." Atom)

Atom = 1*atext

Quoted-string = DQUOTE *qcontent DQUOTE

String = Atom / Quoted-string

と書かれてあります。 Dot-string = Atom *("." Atom) とあり、かつ Atom = 1*atext とあるため、 Dot-string = 1*atext *("." 1*atext) と読み換えて良いでしょう。

これは Request for Comments: 2822 - Internet Message Format における dot-atom-text = 1*atext *("." 1*atext) という記述と同じですので、同様に If the string can be represented as a dot-atom (that is, it contains no characters other than atext characters or "." surrounded by atext characters) であると考えて良いと思います。

ただ、私は先に Request for Comments: 2822 - Internet Message Format を読んでいたからこの根拠を持っているわけであって、 Request for Comments: 2821 - Simple Mail Transfer Protocol だけを読んでいたら分からなかったかもしれません。 dot-atom-text = 1*atext *("." 1*atext) という記述自体が、 If the string can be represented as a dot-atom (that is, it contains no characters other than atext characters or "." surrounded by atext characters) であることを表しているのならば、 Request for Comments: 2821 - Simple Mail Transfer Protocol だけでも xxxx.@xxxxxx や xx..xx@xxxxxx のように、ピリオドがメール アドレスの最後についていたりピリオドが連続している local-part は RFC 2821 に準拠していないと判断できると思いますが、この記述方法がそれを表しているかといういうことまでは私には分かりません。

リプライ

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

2006-06-02T12:32+09:00 - DoCoMoの説明にある「RFCに準拠しています」はウソ < Web屋のネタ帳

NTTドコモのこのページがいつからこのように書かれているのかは知らないが、こう...

2006-11-22T15:34+09:00 - メールあれこれ RFC2821 RFC2822 < 音のない声

 なんかこう、携帯電話でE-Mailが普及してからというもの、アドレスがありえないことになってる人が多い気がする。以前Hxxk.jpさんで紹介されていたよ...

Movable Type 3.11 のサブカテゴリ機能についての所感 (2)

記事データ

投稿者

望月真琴

投稿日時

2004-10-21T23:07+09:00

タグ
概要

サブカテゴリさえ設定してしまえば、トップレベルカテゴリを設定する必要はありません。ただし、デフォルトのテンプレートでは、ある記事にサブカテゴリのみを設定していた場合、親カテゴリのアーカイブにはその記事は含まれません。

リプライ

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

記事本文

サブカテゴリと、カテゴリアーカイブ

Movable Type 3.11 のサブカテゴリ機能についての所感 (1) に続いて、サブカテゴリ機能について試してみました。 今回は Movable Type のシステム上、というかデータベースにおいて、サブカテゴリがどのように扱われるかについてです。

サブカテゴリを設定するときは、トップレベルカテゴリも設定しなければならない ?

Movable Type 3.1 の新機能ガイドサブカテゴリ機能の部分には書かれていないので、もしかしたらサブカテゴリに属する記事は、トップレベルカテゴリも指定しなければいけないのでは ? と思ってしまう方がおられるかもしれません。 というか、私は最初そのように思い込んでいました。

結論から先に言うと、サブカテゴリさえ設定してしまえば、トップレベルカテゴリを設定する必要はありません。 ただし、サブカテゴリをカテゴリアーカイブ上にどう表示したいかによって、テンプレートに手を加える必要がでてくる可能性がありますが、それはまた別の記事にまとめます。

MySQL 使用時におけるサブカテゴリの扱い

データベースに MySQL を使用している場合を例にとって、データベース上でカテゴリとサブカテゴリがどう扱われているかを調べてみました。 Movable Type 3.11 のサブカテゴリ機能についての所感 (1) で示した、 Movable Type 2.661 使用時のカテゴリをサブカテゴリ機能を用いて階層化した場合のモデルを、 WWW hxxks のもののみ抜粋すると次のようになります。

  • www
    • internet
      • browser
        • firefox
          • extension
      • email
    • website
      • accessibility
      • bookmarklet
      • css
      • html
      • php

これらのカテゴリを実際に Movable Type 3.11 上で登録した後に、 phpMyAdmin を使ってデータベース上の mt_category テーブルの category_id を確認したところ、次のように id が付与されていました。

  • www ( category_id : 74 )
    • internet ( category_id : 85 )
      • browser ( category_id : 82 )
        • firefox ( category_id : 83 )
          • extension ( category_id : 84 )
      • email ( category_id : 86 )
    • website ( category_id : 87 )
      • accessibility ( category_id : 91 )
      • bookmarklet ( category_id : 92 )
      • css ( category_id : 89 )
      • html ( category_id : 88 )
      • php ( category_id : 90 )

category_id は auto_increment で追加されるので、トップレベルカテゴリもサブカテゴリレベルも関係なく、 category_id はカテゴリの作成順に付与されます。

さて、これだけではどのカテゴリがトップレベルカテゴリなのかサブカテゴリなのか分かりません。 しかし、今回のサブカテゴリ機能の実装に伴い、 mt_category テーブルにおいて、 category_parent というフィールドが追加されています。 この category_parent が、サブカテゴリがどのカテゴリの子にあたるかを示しているのです。 カテゴリ名 ( = category_label ) と category_parent とサブカテゴリのレベル ( ここでは階層の深さを指すこととします ) をまとめると次のようになります。

category_label category_id category_parent トップレベルカテゴリ サブカテゴリ ( レベル 1 ) サブカテゴリ ( レベル 2 ) サブカテゴリ ( レベル 3 ) サブカテゴリ ( レベル 4 )
www 74 0        
internet 85 74        
browser 82 85        
firefox 83 82        
extension 84 83        
email 86 85        
website 87 74        
accessibility 91 87        
bookmarklet 92 87        
css 89 87        
html 88 87        
php 90 87        

このように、サブカテゴリはそれぞれ直接の親カテゴリの category_id を category_parent として持っており、それを辿ることでどのトップレベルカテゴリ ( = category_parent が 0 であるカテゴリ ) に属しているかを知ることができます。 これらのカテゴリは、全て www カテゴリ ( = category_id : 74 ) に属していることがお分かりでしょうか。

なお、管理画面よりサブカテゴリの移動 ( 属する親カテゴリの変更 ) を行えますが、その操作によって category_parent の値が変更され、属する親カテゴリを変更、またはトップレベルカテゴリへの変更としているようです。 また、 3.1 以前のバージョンの Movable Type によって作られたカテゴリは、全てトップレベルカテゴリ ( = category_parent が 0 ) として扱われるようです。

サブカテゴリの設定の失敗例

サブカテゴリを設定するときは、トップレベルカテゴリも設定しなければならない ? では、 サブカテゴリに属する記事は、トップレベルカテゴリも指定しなければいけないのでは ? と思い込んでいたと書きました。

たとえば、 extension カテゴリは、カテゴリの階層という視点から見ると www > internet > browser > firefox > extension という階層に位置することになります。 最初に私がこのカテゴリに属するテスト記事 ( Template sample 3.11 default: カテゴリテスト記事 -サブカテゴリレベル 4 のみ- ) を書いた際に、 extension カテゴリのみを設定していました。 そして、 firefox カテゴリのアーカイブを見ると、そのテスト記事も一緒に表示されるはずが、表示されません。

Template sample 3.11 default: extension アーカイブ

extension カテゴリを設定している Template sample 3.11 default: カテゴリテスト記事 -サブカテゴリレベル 4 のみ- が含まれています。

Template sample 3.11 default: firefox アーカイブ

firefox カテゴリは extension カテゴリの親カテゴリであるので、 Template sample 3.11 default: カテゴリテスト記事 -サブカテゴリレベル 4 のみ- が含まれるはずですが、実際には含まれていません。

このように、デフォルトのテンプレートでは、ある記事にサブカテゴリのみを設定していた場合、親カテゴリのアーカイブにはその記事は含まれません。 親カテゴリを指定することなく、サブカテゴリの指定のみで親カテゴリのアーカイブに反映させるテンプレートについては次回。

リプライ

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

2004-10-23T21:56+09:00 - カルチョ

はじめまして。 MTのサブカテゴリ機能で辿りつきました。 サブカテゴリ設定をした際に、アーカイブ ファイルのテンプレートに、記載するパーマリンク に関して、質問があります。 サブカテゴリにwww > internet と設定し 記事名をキーワードで設定しようと思っています。 ※※/※※/<$MTEntryKeywords dirify="1"$>.php この※の所にサブカテゴリ設定したwww/internet/ のURLを入れようとしているのですが、悩んでおります。 大変お手数をお掛け致しますが、 ご教授の程お願いします。

2004-10-24T01:27+09:00 - 真琴

はじめまして。ざっとマニュアルを当たってみましたが、 <$MTSubCategoryPath$> を使うと良いのではないでしょうか。 http://hxxk.jp/mt/2004/10/24/0114 に別途まとめましたので、これを参考に試してみてください。

2004-10-24T02:08+09:00 - カルチョ

早速のご返答有難うございました。 参考ページを拝見の上、納得の上解決 する事ができました。感謝感激です。

Movable Type 3.11 のサブカテゴリ機能についての所感 (1)

記事データ

投稿者

望月真琴

投稿日時

2004-10-20T19:32+09:00

タグ
概要

同一の Weblog 内では、トップレベルカテゴリ、サブカテゴリといったカテゴリのレベルに関係なく同じカテゴリ名は使用できません。

リプライ

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

記事本文

Movable Type 3.11 の新機能であるサブカテゴリ機能について、あれこれ試してみました。

真っ先に試したのは、トップレベルカテゴリ・サブカテゴリで同じ名前のカテゴリは作れるのかという点です。 私は、現行の Weblog hxxks 、 MT hxxks 、 WWW hxxks 、 xxxk memo をそれぞれトップレベルカテゴリに設定し、既存のカテゴリをサブカテゴリに設定して、 Movable Type によって複数作成している Weblog をひとつにまとめようと考えていました。 ( xxxk memo - Movable Type 3.01D-ja ではなく Movable Type 3.11 にアップグレードするかも - Movable Type 3.11 の使用感によっては構成を変えるかも )

現行ではまだそういったパターンはありませんが、今後の運用如何によっては、トップレベルカテゴリとサブカテゴリに同じ名前を設定しようとするケースは充分に予想できます。

たとえば、現行の hxxk.jp 内の Weblog のカテゴリを、サブカテゴリ機能を用いて階層化した場合のモデルを考えると、次のようになります。

一例を挙げます。 mt カテゴリの中に template カテゴリがあり、更にその中に distribution カテゴリを作成しています。 これはいずれ私がカスタマイズしたテンプレートを配布する予定で作成しているカテゴリですが、その際に参考にしたテンプレート配布サイトを、 bookmark カテゴリにて紹介しようとするかもしれません。 その際に、 bookmark カテゴリの中に distribution カテゴリを作ろうとすると、 同じ名前のサブ・カテゴリーは設定できません というエラーが発生します。

ならば distribution ではなく Distribution ではどうか。 カテゴリーの設定ができません: Insertion test failed on SQL error Duplicate entry '10-Distribution' for key 2 というエラーが発生し、やはり作成できません。 大文字・小文字の区別なくカテゴリ名の重複は許されていないようです。

まあ、 Movable Type 3.1 より前のバージョンでもカテゴリ名の重複は許されていなかったから、当然なのかもしれません。 ただし、データベースに MySQL を使用している場合は ( 他のデータベースはよく知りません ) 、 mt_category テーブルにおいて category_blog_id レコードが同じでなければ、 category_label が同じ値 ( = 同じカテゴリ名 ) で重複していても問題なかったので、 category_id をユニークなキーとして扱うようにすれば category_label が重複しても問題ないと思うのですが。 ( 私はデータベースに関しては全く無知なので、 category_id をユニークなキーとして category_label を重複させることが可能かどうかは分かりません。 でも、 category_id は auto_increment で追加されるので、ユニークなキーとしても問題はないと思うのですがどうでしょうか。 )

以上の点をまとめると、同一の Weblog 内では、トップレベルカテゴリ、サブカテゴリといったカテゴリのレベルに関係なく同じカテゴリ名は使用できないということになります。

コメント欄にて (o) さん ( Ogawa::Memoranda ) がご指摘して下さっていますが、 アーカイブファイルの名前が衝突する可能性がある ということに気付いていませんでした。

Movable Type 3.11 のサブカテゴリ機能についての所感 (4) - サブカテゴリを含むカテゴリアーカイブのアーカイブ・ファイルのテンプレートで私自身が書いているように、アーカイブ・ファイルのテンプレートに <$MTArchiveCategory dirify="1"$> と記述した場合、トップレベルカテゴリ・サブカテゴリの区別なく <$MTBlogArchiveURL$> の下の同一階層に配置されますので、たとえ categoy_id が異なるものであっても、 category_label が同じであればアーカイブファイルの名前が衝突してしまいます。

また、大文字小文字の区別についてですが、 <$MTArchiveCategory dirify="1"$> のように dirify 属性を指定した場合、仮に Distribution といったカテゴリ名を設定していても、 小文字(abc...)に変換され て distribution という値になりますので、それを考慮して大文字小文字の区別なく ( Case insensitive ) 、カテゴリ名の重複を許可していないのだろうと考えました。

リプライ

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

2004-10-25T04:25+09:00 - (o)

はじめまして。よく調べていらっしゃいますね。 Case insensitiveに同名のカテゴリーが生成できないのは、アーカイブファイルの名前が衝突する可能性があるためでしょう。もちろんDB上は可能です。 サブカテゴリー機能について私も思うところを書いておりますので、もしよろしければご覧ください。 http://as-is.net/blog/archives/000922.html http://as-is.net/blog/archives/000923.html

2004-10-26T01:58+09:00 - 真琴

どうも、はじめまして。 ご指摘のとおり、アーカイブファイルの名称の重複という問題がありましたね。すっかり失念していました。追記にて考察を加えてみました。 (o) さんの書かれた記事は非常に参考になります。 3.11 についてはオフィシャルに日本語でドキュメントが提供されているため、記事を探すよりは自分でマニュアルを眺めていたのですが、その手間を大きく軽減できそうです。

Movable Type 3.01D-ja から Movable Type 3.11 へのアップデート手順

記事データ

投稿者

望月真琴

投稿日時

2004-10-19T21:05+09:00

タグ
概要

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

リプライ

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

記事本文

Movable Type 3.01D-ja から Movable Type 3.11 にアップデートしたので、その手順をメモしておきます。 参考にしたページは mtinstall - Movable Typeのアップグレードです。

  1. Movable Type Publishing Platform - Movable Typeの入手方法についてからログイン ( TypeKey のアカウントを事前に取得しておいてください。 )
    1. Movable Typeの入手方法についてにて「ダウンロードへ」をクリック
    2. 「すでに取得したライセンスのダウンロードはこちらへ」をクリック
    3. ライセンスを確認し、「ダウンロード」をクリック
  2. パッケージの種類でアップグレードを選択します。 ( アーカイブの種類は zip でも tar.gz でもどちらでも構いません。 )
    1. 「パッケージの種類」でプルダウンメニューから「アップグレード」を選択
  3. ダウンロードしたアーカイブを解凍してできたファイルを、 Movable Type をインストールしているディレクトリに全て put します。ただし、 extlib ディレクトリ内のファイルをアップロードするときは、以前Movable Typeをインストールしたときにインストールしたライブラリをどれも上書きしないよう注意。
  4. install directory/mt-upgrade31.cgi をブラウザから実行します。 ( Movable Type 3.01D-ja 以外のバージョンからのアップグレードは、実行するスクリプトが異なります。 mtinstall - Movable Typeのアップグレード - アップグレード・スクリプトの実行を参考に適宜読み代えて下さい。 ) アップデートに成功すると、
    Upgrading your databases:
    Running 'alter table mt_blog add blog_ping_technorati tinyint'
    Running 'alter table mt_blog add blog_children_modified_on datetime'
    Running 'alter table mt_blog add blog_custom_dynamic_templates varchar(25)'
    Running 'update mt_blog set blog_custom_dynamic_templates = 'none''
    Running 'alter table mt_template add template_created_on datetime not null'
    Running 'alter table mt_template add template_modified_on timestamp not null'
    Running 'alter table mt_template add template_created_by integer'
    Running 'alter table mt_template add template_modified_by integer'
    Running 'alter table mt_template add template_build_dynamic tinyint'
    Running 'update mt_template set template_build_dynamic = 0 where template_build_dynamic <> 1'
    Running 'alter table mt_template modify template_build_dynamic tinyint not null'
    Running 'alter table mt_category add category_parent integer'
    Running 'update mt_category set category_parent = 0'
    Running 'alter table mt_category modify category_parent integer not null'
    Running 'alter table mt_entry modify entry_basename varchar(50) not null'
    Running 'create table mt_fileinfo (
        fileinfo_id integer primary key auto_increment,
        fileinfo_blog_id integer not null,
        fileinfo_entry_id integer,
        fileinfo_url varchar(255),
        fileinfo_file_path text,
        fileinfo_template_id integer,
        fileinfo_templatemap_id integer,
        fileinfo_archive_type varchar(255),
        fileinfo_category_id integer,
        fileinfo_startdate varchar(80),
        fileinfo_virtual tinyint,
        index(fileinfo_blog_id),
        index(fileinfo_entry_id),
        index(fileinfo_url)
    )
    '
    Creating Dynamic Site Bootstrapper.
    Creating Dynamic Pages Error Template.
    
    Done upgrading your schema! All went well.
    といったメッセージが表示されます。
  5. install directory/mt-upgradexx.cgi をサーバ上から消去します。

以上の手順でアップデートした結果が、 Template sample 3.11 default です。 これから色々と新機能を試してみようと思います。 現在はデフォルトテンプレートページの公開は停止しています。

リプライ

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

2004-10-21T16:28+09:00 - 3.11にアップグレード? < Little Olive

つい先日、MovableType3.01を入れたところなのに、何気なくMTのホームページを見てみると「3.11にアップグレード!」なんて書かれている。

2005-07-19T17:10+09:00 - 人妻密会倶楽部 < [ Trackback spam ] 代表取締役:真理子

spammed from 220.150.171.241

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

記事データ

投稿者

望月真琴

投稿日時

2004-10-19T20:17+09:00

タグ
概要

ただいまアップグレードファイルを使ってアップグレード中。

リプライ

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

記事本文

記事のタイムスタンプを見る限り、 19:08 より少し前にリリースされたみたいです。 ただいまアップグレードファイルを使ってアップグレード中。

しかし、こういった公式サイトのアナウンスに寄せられるトラックバックを見てると、 Weblog hxxks の方のネタになりそうなものもいくつかあるなあ、と余計なことを考えてみたり。 とりあえずアップグレードとテストに専念しますが、いずれ突っ込み記事を書くかも。 それと、 Movable Type 3.01D-ja と 2.661 の違いを探る (2) の検証作業は中止することにします。 違いを探すよりは新機能の検証の方が役立ちそうだと思いますので。

リプライ

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

他所の CSS を適用したり適用させたりしてみる

記事データ

投稿者

望月真琴

投稿日時

2004-10-17T01:33+09:00

タグ
概要

期間限定 antipop day 開催中。合わせて他所のソースに自分の CSS を適用してみる試み。

リプライ

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

記事本文

他所の CSS を適用してみる

どうやら原因は halt さん ( 武蔵流プログラマへの道 ) らしい antipop day ですが、賛同してやってみました。 ( トイレの落書き - うんけ!が発端という説もあります。 )

  • hxxk.jp ( antipop day )

数日で元に戻しますが、現在は元に戻しています。 こうして手軽に模様替えできるのが CSS の強み、というのを再認識。 ちなみに細かい点が antipop と違いますが、その辺りは各要素の class 名の差異によるものか、または HTML の構造の違いによるものでしょう。

他所のページに hxxk.jp の CSS を適用してみる

ただ真似するだけでは単なる二番煎じなので、私なりに別の遊び方を。 逆に、 hxxk.jp の CSS を各人のソースに組み込んでみました。 なお、その際に以下のようなルールで組み込んでいます。

  • 適用させるページは 2004-10-17T00:58:59+09:00 時点付近のもの
  • xml 宣言や meta 要素の charset は EUC-JP に変更
  • それ以外の部分はいじらない ( よって、デッドリンクや、 img 要素による画像の取得ができない可能性がある )
  • 適用させるページは比較的親しい方のページのみ ( それを免罪符にするわけではありませんが、結果的に無断でテキストなどをコピーしています。快く思われない場合は撤回しますので、ご連絡ください。 )
  • 2004-10-17T02:30:52+09:00 時点で私が祭参加を確認できたページに適用

hxxk.jp の CSS の適用結果

antipop
antipop および hxxk.jp の CSS 適用のスクリーンショット
  • antipop サムネイル
  • antipop with hxxk.jp CSS サムネイル
トイレの落書き
antipop および hxxk.jp の CSS 適用のスクリーンショット
  • トイレの落書き with antipop CSS サムネイル
  • トイレの落書き with hxxk.jp CSS サムネイル
武蔵流プログラマへの道
antipop および hxxk.jp の CSS 適用のスクリーンショット
  • 武蔵流プログラマへの道 with antipop CSS サムネイル
  • 武蔵流プログラマへの道 with hxxk.jp CSS サムネイル
YES I 液
antipop および hxxk.jp の CSS 適用のスクリーンショット
  • YES I 液 with antipop CSS サムネイル
  • YES I 液 with hxxk.jp CSS サムネイル
Web Cafe' Weblog ( あんちぽまつり )
antipop および hxxk.jp の CSS 適用のスクリーンショット
  • Web Cafe' Weblog with antipop CSS サムネイル
  • Web Cafe' Weblog with hxxk.jp CSS サムネイル
ねこめしにっき ( あんちぽまつり )
antipop および hxxk.jp の CSS 適用のスクリーンショット
  • ねこめしにっき with antipop CSS サムネイル
  • ねこめしにっき with hxxk.jp CSS サムネイル
はてなダイアリー - love all ... personal memo ... ( あんちぽまつり )
antipop および hxxk.jp の CSS 適用のスクリーンショット
  • はてなダイアリー - love all ... personal memo ... with antipop CSS サムネイル
  • はてなダイアリー - love all ... personal memo ... with hxxk.jp CSS サムネイル
はてなダイアリー - kina_memo ( Antipop祭 )
antipop および hxxk.jp の CSS 適用のスクリーンショット
  • はてなダイアリー - kina_memo with antipop CSS サムネイル
  • はてなダイアリー - kina_memo with hxxk.jp CSS サムネイル
回顧録? ( ワショーイ )
antipop および hxxk.jp の CSS 適用のスクリーンショット
  • 回顧録? with antipop CSS サムネイル
  • 回顧録? with hxxk.jp CSS サムネイル
朝顔日記 ( antipop スタイル )
antipop および hxxk.jp の CSS 適用のスクリーンショット
  • 朝顔日記 with antipop CSS サムネイル
  • 朝顔日記 with hxxk.jp CSS サムネイル
Short Communication ( 2004年10月17日 )
antipop および hxxk.jp の CSS 適用のスクリーンショット
  • Short Communication with antipop CSS サムネイル
  • Short Communication with hxxk.jp CSS サムネイル
A DAY IN THE LIFE ( あんちぽ祭り )
antipop および hxxk.jp の CSS 適用のスクリーンショット
  • A DAY IN THE LIFE with antipop CSS サムネイル
  • A DAY IN THE LIFE with hxxk.jp CSS サムネイル
Seven Deadly Sins. ( antipop祭 )
antipop および hxxk.jp の CSS 適用のスクリーンショット
  • Seven Deadly Sins. with antipop CSS サムネイル
  • Seven Deadly Sins. with hxxk.jp CSS サムネイル
脱 三日坊主 宣言! ( antipop 祭り )
antipop および hxxk.jp の CSS 適用のスクリーンショット
  • 脱 三日坊主 宣言! with antipop CSS サムネイル
  • 脱 三日坊主 宣言! with hxxk.jp CSS サムネイル
Junkline ( Junkline - あんちぽまつり便乗中 )
antipop および hxxk.jp の CSS 適用のスクリーンショット
  • Junkline with antipop CSS サムネイル
  • Junkline with hxxk.jp CSS サムネイル

適用して分かったこと

けっこうサイト……というか、ソースによって見た目が変わっているということ。 ということは即ち、hxxk.jp の CSS は、 hxxk.jp 内における HTML の構造や、各要素の class や id に依存したものになっている、ということです。

たとえばねこめしにっきへの適用結果を見ると分かりますが、太い border で囲まれたセクションが hxxk.jp に比べて多重構造になっています。 これは hxxk.jp の CSS において

div.section{
  border:  10px solid #0055ff;
  color:  inherit;
  background:  #000000 url("../materials/index_section.jpg") right top no-repeat;
  }

と指定しているためで、 <div class="section"> の入れ子を行わない、と自分の中で決めていることによります。 現在は <div class="section"> の入れ子を行っています。

人によっては <div class="section"> の入れ子を行うようにしている場合もあります。 そういった時に、自分の CSS を当ててみると少し予想と違った結果になるかもしれません。 ねこめしにっきへの適用結果が正に好例。 ( <div class="section"> の入れ子がダメと言っているわけではありません、念のため。 )

そういった視点では、たとえば Appendix > CSS List - outsider reflex の strict.css はそういった現象が起こらない ( div, span, class, id 等に頼らないことを目標にしているので、当然かもしれませんが ) ので、汎用性の高い CSS だと言えるでしょう。

あと最後に気付いたんですけど、これって要するに hxxk.jp の CSS をそのままユーザースタイルシートにして各サイトを見ている状態を形にしたという事みたいなものですねえ。

リプライ

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

日本シリーズ第 1 戦の中断に関するメモ

記事データ

投稿者

望月真琴

投稿日時

2004-10-16T20:53+09:00

タグ
概要

私はふだんプロ野球にあまり興味がありませんし、中日も西武も地元球団ではないため、どちらのファンでもありません。たまたまテレビを見ていて抗議場面に行き着き、状況が複雑で分からなかったので、意見や考察を含まずに状況だけをメモします。

リプライ

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

記事本文

前提

私はふだんプロ野球にあまり興味がありませんし、中日も西武も地元球団ではないため、どちらのファンでもありません。 たまたまテレビを見ていて抗議場面に行き着き、状況が複雑で分からなかったので、意見や考察を含まずに状況だけをメモします。

当該場面直前の状況

試合データ

プロ野球日本シリーズ第 1 戦 ( ナゴヤドーム )

イニングおよび得点状況

5 回裏、西武 2 - 0 中日

打席状況

1 死 1 塁、打者 7 番谷繁、 1 塁走者リナレスでノーストライクツーボール

該当場面 ( 中日ドラゴンズ応援速報 )

  1. 0−2から打つも、打球は本塁ベース付近に転がる。球審はフェアの判定。
  2. 捕手の野田は、谷繁にタッチにいった後、二塁に送り、その後一塁へ転送。
  3. 併殺打かと思われたが……。落合監督は、谷繁へのタッチで一度はアウトがコールされたため、フォースプレーとなり、タッチされなかったリナレスは二塁に生きるのではないか、との抗議。
  4. これが認められたため、今度は伊東監督が抗議する。
  5. 伊東監督が譲らず、中断が30分を経過したため、両監督と選手団が本塁付近で協議を始めた。
  6. その後、いったん両監督がベンチに下がった後、審判団が再び協議。
  7. しばらくたって場内アナウンスがあり、2死二塁ということで試合再開が告げられる。だが西武ナインは納得せず、グラウンドには現れず。
  8. 審判が再びアナウンス。球審が谷繁にタッチアウトの宣告をした後、二塁審判も封殺の判定でアウトを告げた、とジャッジミスを認めた。
  9. その後、西武ナインがようやくグラウンドに出てくる。中断時間は約50分間にも及んだ。谷繁の判定はキャッチャーゴロで1アウトのみ。
  10. 2死二塁で試合再開。先ほどのミスを取り戻したかった英智だったが、内角ストレートに詰まってキャッチャーファウルフライに終わった。

該当場面 ( 西武ライオンズ応援速報 )

  1. 1死二塁。2ボールからの3球目、内角のストレートを打って、打球は足元に転がる。
  2. 結果はフェアの判定で、野田がすぐさま二塁へ投げて、2−6−3とボールが送られる。結果は、キャッチャーゴロ併殺打と思われた。
  3. しかし落合監督は、主審の橘高がフェアのコールの後に、野田が谷繁にタッチしたとアウトのコールをしたから、一走のリナレスはフォースプレーではなく、タッチプレーじゃなければアウトじゃないと抗議。
  4. 審判はそれを受け入れ、2死二塁から試合再開をしようとするが、今度は伊東監督がそれを受け入れず。
  5. 審判が伊東監督を説得する。
  6. 審判団は西武ベンチで説得を続けていたが、中断が30分を過ぎると、グラウンドに誰もいないのがおかしいということで、落合監督と伊東監督、審判がホームベース付近で協議を始めた。
  7. 結果、橘高審判が「2死二塁から試合再開します」とマイクでコール。
  8. しかし西武ベンチは納得いかず。ベンチからだれも守備につかず。
  9. さらに塁審が、「主審が谷繁君のタッチアウトで2死になって、二塁のプレーはタッチプレーになるにも関わらず、塁審がフォースプレーでアウトと認めてしまったミスがあった」と説明。
  10. さらに「審判の不手際でプレーが中断して申し訳ありません」と異例のマイク。
  11. 49分の中断後、谷繁のプレーは一走のリナレスを二塁に進めるキャッチャーゴロ。2死二塁から試合が再開される。
  12. 2死二塁。1ストライク1ボールからの3球目、145キロの内角のストレートで詰まらせて、キャッチャーファウルフライ

ダブル誤審 ?

ドラゴンズの谷繁選手の打球をライオンズ野田捕手が拾い、タッチしようとするも、 ( VTR を見る限り ) そのタッチは当たっていません。 そして、球審はこれをアウトとコール。

次に、野田捕手の 2 塁への送球を 2 塁塁審はアウトとコール。 この 2 つのアウトコールが、問題を大きくこじれさせる原因となったようです。

最初のタッチが誤審であるなら ?

そのままインプレーとなり、 2 塁に向かっていたリナレスはフォースアウトとなるため、 2 塁塁審のジャッジは正しいものとなります。

最初のタッチが誤審でないなら ?

最初のタッチが誤審でないならば、 2 塁に向かっていたリナレスはフォースアウトとならず、またタッチされていないためにセーフとなります。 よって 2 塁塁審のジャッジは誤審となります。

結局、最初のタッチの時点でアウトであるということになり、 2 塁塁審のジャッジの方が誤審であった、ということになりました。

他の方の印象を聞いてみたい

ふだんプロ野球を見ないため、こういったケースにおける、審判のなすべき正しい対応というものが分かりません。 ここを見ている方で野球に詳しい方、おられましたら是非ご意見をお寄せください。 感情論でない、冷静なご意見をお願いします。

リプライ

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

2005-09-08T03:15+09:00 - 匿名

橘高 審判とググッ(google)てきた通りすがりのものです。 というのもこの審判が昨晩また誤審(!?)をしたもので。 http://2chart.fc2web.com/kittaka.html この記事にコメントがないのは、「日本の野球の審判がそんなもの」だからだと思います。 相撲と違い映像チェックしない野球の判定は事実と異なる事が度々です。

2005-09-08T22:34+09:00 - 真琴

ほんとだ、この記事の今日のリンク元は Google が 80% 近くなっていますねえ。 お教えいただいたリンク先を読みましたが、過去にも何度か問題が起きているみたいですね。 審判も人間であるため、ジャッジが絶対ではないのも分かっていますし、しかしそれには従わなければならないのも分かりますが、「日本の野球の審判がそんなもの」という認識があるのならちょっと残念かなあ……。

Movable Type 3.01D-ja ではなく Movable Type 3.11 にアップグレードするかも

記事データ

投稿者

望月真琴

投稿日時

2004-10-16T16:20+09:00

タグ
概要

ひとつの weblog に Weblog | MT | WWW | Memo | Bookmark といったメインカテゴリを作成し、現状の各 weblog 下のカテゴリをサブカテゴリとする……といった運用に変えるかもしれません。

リプライ

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

記事本文

そろそろ Movable Type 3.11 リリース ?

米国では8月31日のリリースを予定しております。 日本語版のリリースは、米国でのリリース後45日以内を予定しております。 詳細については、後日改めて発表させていただきます。

Movable Type 3.1 のリリースが 8 月 31 日に行われ ( Movable Type Publishing Platform: Movable Type 3.1 Launched )、バグフィックスが施された Movable Type 3.11 が 9 月 3 日にリリースされています ( Movable Type Publishing Platform: Movable Type 3.11 Released: Bugs fixed ) 。

Movable Type 日本語版サイト: Movable Type 3.1の主な新機能についてのアナウンスから計算すると 10 月 15 日までに Movable Type 3.1 の日本語版がリリースされているはずなのですが、未だアナウンスは行われていません。 Movable Type 3.11 のリリースから計算すれば、 10 月 18 日まで、という解釈もできそうですが。

Movable Type 3.11 の使用感によっては構成を変えるかも

現在、 hxxk.jp 内で Movable Type を利用しているコンテンツは

の 4 つですが、 サブカテゴリー:新しいカテゴリー管理用インタフェースによって、記事の分類と表示をより細かに管理できます。 がどれほどのものかによって、ひとつの weblog に Weblog | MT | WWW | Memo | Bookmark といったメインカテゴリを作成し、現状の各 weblog 下のカテゴリをサブカテゴリとする……といった運用に変えるかもしれません。

現状の、複数の weblog による構築だと、欲しい情報のみを厳選して読みたい場合に便利な反面、全ての記事を時系列によって追いかけることが難しくなっています。 テンプレートをどうカスタマイズすればそれを解決できるかは分かっていますけど、それを対処するつもりはあまりありませんし。

何にせよ、 Movable Type 3.11 日本語版のリリース待ち……。

現在は、再び weblog をひとつに統一しています。

リプライ

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

シンプル志向に基づいた複雑な構成

記事データ

投稿者

望月真琴

投稿日時

2004-10-16T05:07+09:00

タグ
概要

あれもこれも Movable Type によって自動化しているからといって、決して複雑なことをしているわけではありません。自動化しすぎて Movable Type から離れられないのでは、と思えてしまうかもしれませんが、 Movable Type を使わずともほぼ同様の構築を手作業で行うようにすることはできます。

リプライ

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

記事本文

あれもこれも Movable Type な私

続きを読む ? 本文を読む ? - 先を越された ? で紹介した 404 : テンプレート公開(欠陥指摘を促す試み)のように、 Movable Type のカスタマイズに関する記事を読むのが好きです。 今回もそういった記事を受けての記事です。

シンプル志向の MovableType カスタマイズを読んで、ふむふむと頷きながらも、私は逆にあれもこれも Movable Type にお任せ状態になっちゃっているなあ、と思いました。 全く設定を変更せず、デフォルトのテンプレートのまま Movable Type を使用する場合と比較してみると、

  • 最新記事へのリダイレクトを行う .htaccess の自動生成 ( Latest Entry Redirect Template )
  • Site map 用のインクルードファイル
  • カテゴリ別のアーカイブ
  • カテゴリ別の記事タイトル一覧
  • 日毎のアーカイブ
  • 月毎の記事タイトル一覧
  • 年毎の記事タイトル一覧

といった用途を追加しています。 各種のアーカイブやタイトル一覧だけでなく、リダイレクトやサイトマップの作成にも Movable Type を活用しているため、一見 何でも自動化してみたくなる というケースに当てはまっているいるように見えるかもしれません。 テンプレート一覧スクリーンショット テンプレートの数も非常に多くなっていますし。 ( サムネイルをクリックすると、原寸大のスクリーンショットを表示します。 なお、諸事情によりスクリーンショット内から出力ファイル名を消去しています。 )

しかし、あれもこれも Movable Type によって自動化しているからといって、決して複雑なことをしているわけではありません。 Latest Entry Redirect Template は非常に単純なソースコードですし、サイトマップに活用しているテンプレートも、各 weblog のテンプレートのナビゲーション部分を作成しているときに書いたソースコードをその部分だけ流用して PHP で include しているだけです。 例えるなら天ぷらを作ったときに出てくる天かすでたぬきそばを作った、みたいな。 何か微妙な例えですが。

私が Movable Type を導入した理由は「最初にこれを知ったから」であり、それ以外の理由は特にありません。 導入にあたって、デフォルトのテンプレートの HTML ソースがお世辞にも良いものではないと分かったときに、自分の納得の行く HTML を生成してくれるようにテンプレートを見直していった過程で、現在のような構成を構築しました。 もしもデフォルトのテンプレートがより良い HTML ソースであったなら、こうしてカスタマイズしていなかったかもしれません。

作業負担は変わったのか

自動化を目的としたカスタマイズではなく、納得のいく HTML ソースを生成するためのカスタマイズとはいえ、やはりテンプレートの記述には多くの時間を割くことになりました。 それによって今後軽減されると予想される作業時間と比較しても、ちょうど相殺されるくらいではないでしょうか。

ただし、そういった記事ごとのアーカイブや、それのナビゲーションに対して消費する作業時間よりも、記事本文に対して消費する時間の方が圧倒的に多いのは Movable Type 導入以前も以後もさほど変わりません。

<div id="sub-yyyymmdd-01" class="section">
  
  <h4>小見出し 1</h4>
    
    ( ブロックレベル要素で囲んだ本文 )
    
</div>

<div id="sub-yyyymmdd-02" class="section">
  
  <h4>小見出し 2</h4>
    
    ( ブロックレベル要素で囲んだ本文 )
    
</div>

エディタ上ではこういった記述になっています。 ( セクションを分けず、小見出しの不要な短い記事の場合は直接本文のブロックレベル要素から記述します。 ) エディタで一通り書き終わってからバックアップフォルダにテキストで保存した上で全文をコピーし、記事の新規投稿画面にてペーストして更新しています。 Movable Type の管理画面のテキストエリアに直接打ち込むことはありません。

いつ MT の使用をやめても大丈夫なように

hxxk.jp は、一見自動化しすぎて Movable Type から離れられないのでは、と思えてしまうかもしれませんが、 Movable Type を使わずともほぼ同様の構築を手作業で行うようにすることはできます。 私の場合、コメントやトラックバック機能は「あるから使っている」程度の認識ですので、無ければ無いで純粋に記事のみを記録していくでしょう。 そのため、 いつ MT の使用をやめても大丈夫なように という徳保隆夫さん ( 趣味のWebデザイン ) の心構えは共感できました。

Movable Type の大きな特徴はやはりテンプレートのカスタマイズの自由度だと思います。 凝れば凝るほどより自動化でき、作業時間を減らすことができます。 逆に、 Movable Type の持つ機能は最低限に抑え、そのほかの部分を手作業とすることで、決め細やかな HTML ソースを生成することもできるでしょう。

私はまさに今 楽しい間 のさなかに居ると思います。 今後カスタマイズで行き詰ることがあれば、手作業で対応することも充分視野に入れておこうと思います。

ただし、現在はキーワードによるインデックスを作成しているため、手作業に戻るのはなかなか難しいかもしれません。 もし Movable Type が使えなくなったら、 XMLXSLT を勉強して半自動化することになるかも。

リプライ

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

続きを読む ? 本文を読む ?

記事データ

投稿者

望月真琴

投稿日時

2004-10-16T00:20+09:00

タグ
概要

ソースの状態でしか眺めていませんが、よくまとまったテンプレートだな、という印象を抱きました。MainIndex.txt の中の記述なのですが、 extend 部分が正しく使われているというのも良いです。

リプライ

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

記事本文

先を越された ?

404 にて Movable Type のテンプレートが公開されています。

HTML をきちんと書ける人がテンプレートを公開してくれるのは頼もしいというか、先を越されたというか……。 そもそもテンプレートを公開するつもりでいるくせに動きが停滞している自分が悪いんですが。 ちなみに今 hxxk.jp の各記事に使用しているテンプレートは、 Junkline - テンプレ請うかいにて公開されているものをベースとして私なりのカスタマイズを加えています。 加えていますっていうか面影は全く残っていませんが……。

実際に適用してはいませんが

ソースの状態でしか眺めていませんが、よくまとまったテンプレートだな、という印象を抱きました。 実際に自分の Movable Type に適用したわけではないので、細かいところまでは目が行き届いておらず、イソムラさん ( 404 ) の言う 記述の間違いやよりベターな方法を心に秘めた手練れ Movable Typer(造語)に助言を求めよう という要望にはお答えできていないかもしれませんが……。

ひとつだけ、助言というか、感心した点を。 MainIndex.txt の中の記述なのですが、 extend 部分を

<div class="entry_body">
  <$MTEntryBody$>
  <MTEntryIfExtended>
  <p class="guidance"><a href="<$MTEntryPermalink$>">続きを読む</a></p>
  </MTEntryIfExtended>
</div>

としているところ。

Movable Type および類似の weblog ツール、 weblog サービス利用者で、 extend ……というか、「続きを読む」の使い方を間違っている人が多すぎると常々思っていました。 本来の追記の意味ではなく、単に excerpt をほんの少し表示し、「続きを読む」というアンカーで Individual Entry Archive にリンクし、全文表示をするといった使い方。 それは「全文を読む」といったアンカーにすべきでは ? といつも思っています。

404 の場合は、記事に対する補足や訂正が発生した場合にのみ、 Main Index の記事中に「続きを読む」というアンカーが発生するので、何か補足や訂正が行われた場合にすぐ分かります。 ( 各種アーカイブの場合は、 extend 部分も含めて全文を表示 )

ちなみに、 hxxk.jp で使っているテンプレートの場合は、わざわざ extend を使用する必要性は薄いと判断したため、 ins 要素にて補足部分や訂正部分を表しています。 私も早く公開できるバージョンのものを作らないとなあ……。 hxxk.jp template set -standard- を現在公開中です。

マニュアル自体が微妙な表現だと私は考えています

これら2つのフィールドがエントリーの内容を形成します。 この2つのフィールドは好きなように使用できます。 たとえば、エントリーを2つのフィールドに分けることもできれば、完全に「追記」を無視して「エントリーの内容」だけにテキストを入力することもできます。 Movable Typeでは、そのエントリーを表示する際に、より柔軟にエントリーを分けることができます。 たとえば、非常に長いエントリーを書いた場合、それをすべてインデックス・ページに表示するのは避けたいと思うかもしれません。 このときにこの2つのフィールドを使うと、表示する内容と表示する場所を調整できます。

この2つのフィールドのテキストを、公開しているウェブログに出力すると、段落(2つの行替えで区切られたテキストのブロック)は自動的に、あなたが選択した「テキスト・フォーマット」オプションで変換されます。 デフォルトのフォーマットでは、段落を<p></p>タグで囲み、改行を<br>タグに変換します。 このフォーマットを望まない場合は、テキスト・フォーマットに「なし」を選択します。

extend という名前を定義しているのなら、その言葉通りに解説をすべきですが、マニュアルではどうも extend という言葉を拡大解釈をしている感が否めません。 記事の内容をあらかじめ body と extend に分けて記述し、 <MTEntryIfExtended> 〜 </MTEntryIfExtended> で表示を操作するというのは、 extend ではなく divide だろうと思うのですが。

非常に長いエントリーを書いた場合、それをすべてインデックス・ページに表示するのは避けたいと思うかもしれ ないなら、適切な excerpt を記述し、それをインデックス・ページに表示した上で「全文を読む」といった類のアンカーから Individual Entry Archive にナビゲートする方がよほどインデックス・ページはすっきりします。

<div class="entry_body">
  <$MTEntryExcerpt$>
  <p class="guidance"><a href="<$MTEntryPermalink$>">全文を読む</a></p>
</div>

そもそも、インデックス・ページに最新数日分、あるいは最新数件の記事の <$MTEntryBody$> を記述すること自体、それは Index ではなくて Recent Entries Archive ではないだろうか、と私は思っていますので、構造という視点から見た Movable Type の用語の定義よりも、言葉の意味を重視する傾向が強いのかもしれません。

リプライ

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

2004-10-19T09:08+09:00 - イソムラ

マニュアルの日本語もちょっと微妙な感じですし、そもそも「これが正しい使い方です」というのが明確なツールが登場したとしても、使いやすい・使いたい独自の方法を展開する人は現れるでしょうね。というようなことを、fieldset伝説(legend)のときにも思ったような。要は「どういうツールか」よりも「誰が・どう使うか」が大きいとか。

2004-10-19T22:07+09:00 - 真琴

>使いやすい・使いたい独自の方法を展開する人 こういった人が現れるというのは悪い面ばかりでなく、良い面もあったりするので難しいところですね。意外な活用法を発見したりとか。 と言って、サイトマップなどにも Movable Type を ( 半ばムリヤリ ) 活用している自分を弁護してみます。 本来の意味を逸脱しなければ構わないとは思いますが、今回の場合は excerpt というれっきとしたものがあるので、 extend でムリに代替する必要はないのでは、という思いから書いてみました。

幼児はそんなことするわけがない、と思い込んでいた

記事データ

投稿者

望月真琴

投稿日時

2004-10-14T18:48+09:00

タグ
概要

私はふだん子供 ( というか幼児 ) に接する機会がありません。 単にウェブ上の情報を拾い集めて考えただけですので、実情と違う思い込みをしているかもしれません。 もし同様のことを悩まれた経験のあるお父様やお母様、または保育士や幼稚園教諭の方がこの記事を読まれて、何か感じたことがあれば遠慮なくご意見をお寄せください。

リプライ

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

記事本文

最初に話を聞いたときはびっくりしたけど

この間、保育士をしている友人とお酒を飲む機会があったんですが、その中の会話の一こま。

お昼寝の時間に、無意識なんだろうけど机の足に股をこすりつけている女の子がいるんだよね。 注意した方が良いのかなぁ。 でも、分からないままやっているんだろうし、注意した方が良いにしても、何て言えばいいのかが難しい……。

その時の私はけっこうお酒が廻っていましたので、どういった会話の流れからこういう話になったのか覚えていません。 その場に居た友人たちからの有効な回答はなかったような気もしますし、別に私個人に向けてなされた相談ではなくて、「最近仕事はどう ? 」みたいな流れからぽつりと出た話題だったと思います。

特殊なケースなのか ?

その子だけの癖なのか、それともその年代なら自然に行い得るものなのか私には分からなかったので、まずはそのあたりの点を重視して調べてみました。

自慰行為は発達段階でよくみられます。

2歳から5歳くらいで見られる動作です。 男子は外性器に対し、いじったり、女子は足をすり合わせたり、またつくえに性器をすりあわせる動作をすることもあります。

女子はまず、何かそのあたりに皮膚炎が出来、それがきっかけからその部に興味を示してからということもありますし、男子は興味でいじってからと言うことからでしょう。 時に恍惚となる顔になったり快感を味わったり、あるいはてんかん発作と稀に間違えることもあります。

女子ならまずそのあたりにかゆみを生じてるような皮膚あるいは性器症状がないかを確かめてみてください。 乳幼児ではおむつかぶれや湿疹でかゆくなること、またそれがきっかけになることも、ありますので。

オナニーとよばれる性器をこするクセは、幼児の間で、そんなに珍しいことではありません。 たいていの方が、ひどくびっくりされて、「性的異常があるのではないか」とか、「ちゃんとした大人になれないのでは」などと、相談に来られますが、ご心配はご無用です。 対応の仕方さえ正しければ、いつか消えてしまうものです。

……と、珍しいことではないみたいです。 私にはまだ子供は居ませんが、もし自分の息子や娘がこうした動作を行った際に慌てなくていいように、このことをしっかりと覚えておこうと思います。

自分の 2 歳から 5 歳くらいの頃を思い返してみれば良いのかもしれませんが、あいにくほとんど覚えていません。 思い出せるのは、保育園児だった頃のお昼寝の時間はいつも目が冴えて眠れずにいた、ということくらいです。

適切な対処法

さて、次にこうした動作を目にした場合の適切な対処はどうすればいいのか。 そもそも友人が対処すべきなのか、それはその子の親が対処すべきなのかも合わせて考えてみます。

確かに幼少時からオナニー(自慰)はあります。

女子の子供において、臥床時にあり、両足を密着させて、足と足で股間を摩擦しあっているような動作です。 それで苦しそうな(あるいは顔を紅潮させます)顔に見えると思います。 男子は外性器に興味をもっていじることで解りますが、性器を出さなくても刷り合わせることで快感を得ようとすることもあります。

これは本人も「なんでもない」ということで解ってるとも思いますが、なにせ2歳から5歳なので、止めることもなかなか理解できるかどうかもわからず、「怒らず、慌てず」に動作をしないような姿勢をとらせて、あと興味をほかのものに転換させるようなことにしたら自然に直ると思います。 口やかましく怒ったり、特別なこだわりをもつと逆効果になります。

お母様が、直接言うより、幼稚園の先生の言葉のほうが、早くきいたみたいです。 お家で真剣に、「ママ、おしっこする所は、すごーく大事なの、きれいにしておかないと、いけないんだよ。」言っていました。 と、苦笑しておられました。

叱るのはあまり効果がないと考えられています。 手持ち無沙汰のときに起こりやすいので、興味を他に向けさせるというのが一番です。 それから、不安なときやさびしいとき起こってくることもあるので、一緒に眠るなどスキンシップかよい効果をあげることもあります。

注意する、やめさせる、ということではなく、それ以外のものに興味が行くようにする、と……。 しかし、お昼寝の時に無意識に行ってしまう場合はどうなのでしょう ? 日中の活動時にストレスを感じさせないようにしてあげれば良いのでしょうか。 ( ストレスによって起こる動作とは一概に言えませんが )

ただあまり心配なときはかかりつけの先生に一応局所だけは見ていただくほうがいいでしょう。 実際自慰行為でなくてそこが痒いことも考えられますので。

確かに、こういったケースも考えられますね。 色々調べていくと、親御さんが対処してあげるべきといった記述もあれば、幼稚園の先生の言葉が効果的だったという記述もあります。

保育士である私の友人が気付いたのなら、けして特別なことではないことを最初に告げ、友人から親御さんにご報告差し上げるのが一番良いのかな、と思いました。

とは言っても

以上の考えは私一人が考えたものであり、そして私はふだん子供 ( というか幼児 ) に接する機会がありません。 単にウェブ上の情報を拾い集めて考えただけですので、実情と違う思い込みをしているかもしれません。

もし同様のことを悩まれた経験のあるお父様やお母様、または保育士や幼稚園教諭の方がこの記事を読まれて、何か感じたことがあれば遠慮なくご意見をお寄せください。 友人の助けになればという思いと、未来の自分のためになるかなとの思いという利己的な動機ではありますが、よろしくお願いします。

リプライ

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

2004-10-17T04:54+09:00 - こに

はじめまして! うちの3歳になる息子もいじっていますよー。 特にお風呂とかトイレの前後、丸出しになっている時ですね。 多分、目に見えるし、興味があるんでしょうねえ。 うちでは、男の子だし、まだそういう知識もない筈ですから、罪悪感があるわけでもないだろうし、本当に目に見えるからとりあえずいじっているのかなと思って、半分放置です。 でも、トイレの後はそこからばい菌が入って炎症を起こすと大変なので、「手で触ると痛くなるよー」と脅しています。(^_^;) 知り合いの女の子も床にこすりつけていたことがあると話していたことがありました。 心配して保育園の園長先生に相談したら、やっぱりこの時期の子にはよくあることだから、心配しないようにと言われたということです。 もしお知り合いの保育士さんに話すことがあったら、ぜひ他の同僚や先輩に相談してみたらと勧めてください。 経験豊富な先輩や園長先生なら、多分対処法を知っている筈です。 では

2004-10-19T22:03+09:00 - 真琴

こにさん、はじめまして。そして具体的な情報どうもありがとうございます。 「手で触ると痛くなるよー」というのは良いですね。 そして、やはりよくある事なんですねえ……。友人はまだ新人に近いせいか、こういうケースに遭遇したのは本当に初めてなのかもしれません。 ( 私も友人から話を聞いて初めて知ったのですが ) こにさんの仰る通り、先輩や園長先生に相談するように勧めてみます。どうもありがとうございました。

2005-03-13T01:43+09:00 - kudagonbe

初めまして。 次男の自慰を見て、検索してこちらのやってきました。 いろいろなHPがまとめて紹介されているのでTBさせていただきますね。 今までにいろいろな文献で目にして来た内容だったので、次男の自慰現場を目撃しても『ああ・・・これが・・・』くらいで慌てませんでしたが、他のママにも知って欲しい内容です。

bloger? blogger?

記事データ

投稿者

望月真琴

投稿日時

2004-10-13T01:11+09:00

タグ
概要

1 母音字 + 1 子音字で終わる語の場合、その末尾の子音字を重ねた上で語尾に er を付すのが原則となります。 weblog という単語は Weblog hxxks - weblog という言葉でも述べたとおり、 web と log という単語を繋げて一語としたものであり、そこから派生して blog という単語が生まれたので、正式な英単語というわけではありません。 しかし、元々の log という単語を基本にして考えると、 1 母音字 + 1 子音字で終わる語となりますので、 logger と記述するのが正しい動詞形です。 よって、 blog という名詞の er 動詞形は blogger とスペリングするのが自然だと言えると思います。

リプライ

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

記事本文

宣伝コメントの実例

無分別なトラックバックは spam と何ら変わらないで紹介したきまぐれTの個人的(?)情報発信の現時点での最新記事に、宣伝コメントが寄せられていました。

この記事へのコメント

ブログのランキングサイトがOPENしました☆この機会にぜひご参加の検討をよろしくお願いします。

ブロガーズ・ランキングhttp://www.blogers-ranking.com/

Posted by ブロガーズ・ランキング at 2004年10月10日 14:18

Google 検索: ブログのランキングサイトがOPENしました☆で分かるように、複数サイトに同一の文面で投稿しているようです。

blog という言葉自体が造語ではあるけれども

Blogers Ranking--ブログの総合ランキングサイト--というサイト名ですが、 bloger という表記はスペルミスだと思います。

Google 検索: blogerGoogle 検索: blogger の検索結果の件数の違いを見ても明らかですし、何より Google 検索: bloger の場合は もしかして: blogger というアンカーが出現します。

また、「名詞 + er 」で「〜する人、もの」を表すこととなる単語で、 1 母音字 + 1 子音字で終わる語の場合、その末尾の子音字を重ねた上で語尾に er を付すのが原則となります。 例えば、

  • nipper ( nip + p + er )
  • runner ( run + n + er )
  • stopper ( stop + p + er )

といった単語がそうです。

そして weblog という単語は weblog という言葉でも述べたとおり、 web と log という単語を繋げて一語としたものであり、そこから派生して blog という単語が生まれたので、正式な英単語というわけではありません。 しかし、元々の log という単語を基本にして考えると、 1 母音字 + 1 子音字で終わる語となりますので、 logger と記述するのが正しい動詞形です。 よって、 blog という名詞の er 動詞形は blogger とスペリングするのが自然だと言えると思います。

妥協策というか、一応の対策案

揚げ足取りだけでは何ですので、私なりの対案を。 と言っても、 blogers-ranking.com というドメインを取得してしまっている以上、サイト名の変更やバナーの再作成は良くても、 URI の方はどうしようもできません。

同様のケースがないか探してみると、ロリポップ!レンタルサーバーが同様にスペルミスのドメインを所有していてるのが分かりました。 ( ロリポップは lolipop ではなく lollipop とスペリングします。 )

おそらくそれに対する指摘も多々あったのでしょう。 教えてロリポおじさんという、チャットを模した Q&A がありますが、これに「スペル間違っているよ」と書いて質問すると、 それは言わない約束だぽ! と返ってきます。 ある種の開き直りなのですが、それが逆にユーモラスさを醸し出していて、大きなマイナスにはなっていないと思います。 真似をしろというつもりはありませんが、切り抜け方の参考にすると良いと思います。

リプライ

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

無分別なトラックバックは spam と何ら変わらない

記事データ

投稿者

望月真琴

投稿日時

2004-10-12T21:49+09:00

タグ
概要

Seesaa BLOG の BLOG ガイドツアーに、トラックバックというものの解説が書かれています。 その解説を読んで、きちんとその意味を解しているならこういった宣伝トラックバックは行わないはずです。きまぐれTの個人的(?)情報発信: お詫びと修正にてフォロー記事が出されています。今回問題になった原因は、 「利己的な宣伝を目的とするTB自体がマナー違反」 よりも、関連のない weblog に対してトラックバックを送ったことにあると思います。

リプライ

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

記事本文

トラックバックというものの概念を理解していればこうした行動をしないはず

読解力が無いのか、マナーを持ち合わせていないのか、あるいはその両方か。

  • きまぐれTの個人的(?)情報発信: TBありがとうございます。

これ以降の項は、該当記事の本文及びそれに関するコメントまで読まれたことを前提として記します。

現在は該当記事は削除されています。 簡単に説明すると、小説を出版しましたという旨の記事で、本関連の weblog や有名人の weblog や人気の weblog の最新記事にランダムでトラックバックを送っていたのです。

読解力が無い ?

hxxk.jp について - トラックバックに関することにて述べていることと重複しますが、トラックバックという技術を最初に実装した Movable Type の仕様には、 Using TrackBack, sites can communicate about related resources. For example, if Weblogger A wishes to notify Weblogger B that he has written something interesting/related/shocking, A sends a TrackBack ping to B. ( トラックバックを使うことで複数のサイトが、お互い関連するリソースに関する通信が可能になります。 ウェブロガー A さんが何かおもしろいこと(あるいはB さんに関連していること、またはショッキングなこと)を書いたので、そのことをウェブロガー B さんに伝えたいとします。 ) と記されています。

これはあくまで Movable Type における仕様ではありますが、 Movable Type 以降の weblog ツールもこれに準じてトラックバックを実装していったのだと思います。 きまぐれTの個人的(?)情報発信: TBありがとうございます。のようなトラックバックのやり方に、 Using TrackBack, sites can communicate about related resources. といった概念は全く含まれていません。

きまぐれTさん ( きまぐれTの個人的(?)情報発信 ) は Seesaa BLOG をお使いになっているので、もしかしたら Movable Type のドキュメントには目を通していないのかもしれません。 しかし、 Seesaa BLOG の BLOG ガイドツアーにも、トラックバックというものの解説は書かれています。

トラックバックとは、誰かのブログにある記事に対して、あなたのブログの内容を表示してもらったり、リンクを張ってもらうための機能です。

たとえば、あなたが誰かのブログの記事を読んで、その記事に関連した記事を自分のブログに作成したいと思ったとします。 その場合、元になる記事へのリンクを自分の記事の中に埋め込むだけで、元の記事を読んでいる他の人にはあなたの記事の存在が分かりません。 しかし、トラックバックを行うと、あなたが元にした記事が掲載されているページに、あなたの記事の内容や、あなたの記事へのリンクが紹介されるのです。

このトラックバックバックの機能を使うと、例えブログの作者たちがそれぞれ違うブログのサービスを利用していたとしても、互いの記事に関連を持たせることができるようになるのです。

この解説を読んで、きちんとその意味を解しているならこういったトラックバックは行わないはずです。 仮に「宣伝手段としてトラックバックが存在する」といった解説をしているサイトがあったとしても、他の解説サイトと合わせて読めばそれが間違いであることは分かるはずですから、読者からきまぐれTさんはトラックバックに対してのリテラシが低い ( あるいは全く無い ) と思われても仕方がありません。

マナーを持ち合わせていない ?

本関連のブログ様、有名人・人気ブログ様を中心にTBさせて頂きました。 最新の記事においてランダムにTBさせて頂いております。 と冒頭にありますが、本関連の weblog ならまだしも、有名人 の weblog や人気 の weblog にトラックバックを送る必要があるのでしょうか。

今も存在するのか分かりませんが、「相互リンク」という謎の文化が隆盛だったころ、人気のウェブサイトにはその相互リンク依頼がひっきりなしに来ていました。 メールで依頼されたり、掲示板などに依頼書き込みをされるという形が一般的であったと思います。 また、掲示板の書き込みに自分のサイトの URI を残せる形になっているものは、そこから閲覧者が流れてくることを期待して投稿された宣伝書き込みもよく見られました。 これはサイトの管理者からすると、マナー違反の行為として捉えられていました。

今回は、それがトラックバックというものに置き換わっただけで、本質的には全く変わっていません。 記事的には全く無関係な宣伝トラックバックがきまぐれTの個人的(?)情報発信に寄せられることを想像したら、このような行為に及ばないと思うのですが。

アフターフォローをするのか ?

この行為、および寄せられたコメントを本人がどう捉えているかによるでしょう。 同じ作者の手によるみんなの”厳選”書籍広場みんなの”厳選”書籍広場: ■はじめに・注意事項など■にて

〜・〜 その他注意事項 〜・〜

申し訳ないのですが、本に関連しないこと及びアダルトに関するトラックバックは受け付けておりません。 見つけ次第、管理人の裁量によって削除させて頂きますので予めご理解下さい。

自ら 本に関連しないトラックバックは受け付けておりません と謳っているので、「その weblog のテーマに関係のないトラックバックがいけないことだとは思わなかった」ということはないと思うのですが。

きまぐれTの個人的(?)情報発信: お詫びと修正にてフォロー記事が出されています。 そしてきまぐれTの個人的(?)情報発信: TBありがとうございます。の方は削除され、きまぐれTの個人的(?)情報発信: 出版しました!という記事でトラックバック送信部分以外の、出版に関する部分だけを再掲する形の記事が投稿されています。 事の経緯を明確にするためには、このフォロー記事を投稿するだけで充分だと思うのですが……。 ( 元の記事を削除してしまうと、経緯が不明確になってしまいます。 )

また、今回問題になった原因は、 「利己的な宣伝を目的とするTB自体がマナー違反」 よりも、関連のない weblog に対してトラックバックを送ったことにあると思います。

仮にねこばばという本がチャリティ等の目的で出版されたもので、売り上げは全額寄付することとなっていたとして、それをトラックバックを用いて宣伝した場合、果たして一概に利己的であると言えるでしょうか。 もちろん、完全に利他的であるとも断言できませんが、 「利己的な宣伝を目的とするTB自体がマナー違反」 とするならば、利己的ではない宣伝にトラックバックを利用するのは、トラックバックの利用法としては間違っているとしても、マナー違反にはならないという理屈になります。

前項で述べているとおり、トラックバックは関連のある記事と記事との通信を可能にする技術であり、宣伝などの手段に用いられるものではないのです。 例えば、みんなの”厳選”書籍広場では本のジャンルごとにトラックバックを集める形式で運営されています。 各人がお勧めの書籍に対する記事を書いて、それをトラックバックとして送信しているのですが、これは「書評を集める」という記事と、各人の書いた書評の記事に関連性があるため、正しいトラックバックの利用だと言えるでしょう。 それにより、結果的に書籍の宣伝になることもあるでしょうけれど、それはあくまで結果論であるため、トラックバック自体の目的としては正しいものであると言えます。

あれこれ細かいことを書いてしまいましたが、トラックバックを行う前に、自分の記事はそのトラックバックを送ろうとしている記事に対して本当に関連性があるかをよく考えるようにすれば、自ずと本来の目的から外れたトラックバックを行わずにすむと思います。

トラックバック送信先

リプライ

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

2004-10-16T00:03+09:00 - お詫びと修正 < きまぐれTの個人的(?)情報発信

http://kimagure-t.seesaa.net/article/715401.html こちらの記事(削除済み)においてブログ業界(?)をお騒がせしております。 まずは、ブログ業界をも騒がし、また、皆様にご心配をお掛けしたことについては 率直に詫びなければならないと思います。 申し訳ありません...

2005-05-23T11:44+09:00 - TrackBackって・・。 < (`∀)y-~~ブログとやら

えっと、俺はBlogはそれ程長いこと書いているわけでは無いが、意味がわからんときがある。 実際にネタとして引用しようの無い、ウェブチラシの裏状態の俺のBlogに...

iCapture と ieCapture

記事データ

投稿者

望月真琴

投稿日時

2004-10-11T00:54+09:00

タグ
概要

Linkage Note! - iCapture稼働中にて iCapture のサービスが再び稼動していることを知りました。また、 Linkage Note! の作成者の方の本家サイト、 Software Linkage 内の iecapture - Software Linkage にて ieCapture についての詳しい解説……と言うかレビューがなされているので合わせてメモ。

リプライ

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

記事本文

iCapture 再稼働

2004年10月10日の日記 - Linkage Note! - iCapture稼働中にて iCapture のサービスが再び稼動していることを知りました。 せっかくなので、各ブラウザでのスクリーンショットと合わせてメモ。

同様のものに ieCapture というものもあります。 これは Linkage Note! の作成者の方の本家サイト、 Software Linkage 内の iecapture - Software Linkage にて詳しい解説……と言うかレビューがなされています。 こちらも合わせてメモ。

Safari 1.2

iCapture にて 1024*768 ピクセルでスクリーンショットを取得し、 800*600 ピクセルにリサイズしました。 サムネイル画像からフルサイズ画像にリンクしており、フルサイズ画像のサイズは 134KB です。

Safari 1.2 による hxxk.jp のスクリーンショットのサムネイル

Firefox 0.9.1

Web Developer Extension を用いてウィンドウサイズを 1024*768 ピクセルにした状態でスクリーンショットを取得し、 800*600 ピクセルにリサイズしました。 サムネイル画像からフルサイズ画像にリンクしており、フルサイズ画像のサイズは 145KB です。

Firefox 0.9.3 による hxxk.jp のスクリーンショットのサムネイル

Internet Explorer 6.0

Webnail2 を用いて 1024*768 ピクセルでスクリーンショットを取得し、 800*600 ピクセルにリサイズしました。 サムネイル画像からフルサイズ画像にリンクしており、フルサイズ画像のサイズは 138KB です。

Firefox 0.9.3 による hxxk.jp のスクリーンショットのサムネイル

リプライ

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

コメントスパムメモ 2004/10/10

記事データ

投稿者

望月真琴

投稿日時

2004-10-10T23:55+09:00

タグ
概要

コメントスパムと思われるコメントが寄せられた場合、逐次公表することにしています。主な判断基準は、文面で検索して全く同様のコメントが各所で見受けられた場合など。

リプライ

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

記事本文

コメントスパムと思われるコメントが寄せられた場合、逐次公表することにしています。 主な判断基準は、文面で検索して全く同様のコメントが各所で見受けられた場合など。

コメント投稿記事
コメント投稿日時
  • 2004/10/09 19:51
コメント投稿者名
  • purchase buy order
コメント投稿者メールアドレス
  • suggestions@buy-cheap-soma.com
コメント投稿者 URI
  • http://www.buy-cheap-soma.com/
コメント本文

Hi. Just stopping buy to say high! I am new to the internet and I have been surfing all night. I really enjoy your website. :)

検索結果

リプライ

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

メールアドレスに使える文字

記事データ

投稿者

望月真琴

投稿日時

2004-10-10T15:39+09:00

タグ
概要

RFC2822 を元に、メールアドレスに使用できる文字を調べてみました。

リプライ

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

記事本文

以前同じようなことを調べた

思考/謎 - 2004年10月 - メールアドレスに使える文字を見て、そういえば以前同じようなことを調べたなあ……ということで、自分が読み返しやすいように掲載しておきます。

RFC 2822 - 3.4. Address Specification

Request for Comments: 2822 - Internet Message Format ( 和訳 ) を見ると、 3.4. Address Specification および、 3.4.1. Addr-spec specification という項があります。 そこからメールアドレスを構成する部分の記述を抜粋すると、次のようになります。

address         =       mailbox / group

mailbox         =       name-addr / addr-spec

addr-spec       =       local-part "@" domain

local-part      =       dot-atom / quoted-string / obs-local-part

domain          =       dot-atom / domain-literal / obs-domain

domain-literal  =       [CFWS] "[" *([FWS] dcontent) [FWS] "]" [CFWS]

dcontent        =       dtext / quoted-pair

dtext           =       NO-WS-CTL /     ; Non white space controls

                        %d33-90 /       ; The rest of the US-ASCII
                        %d94-126        ;  characters not including "[",
                                        ;  "]", or "\"

私がこのサイトで使用しているメールアドレス "makoto@hxxk.jp" を例にとると、 local-part にあたる部分が "makoto" 、そして "@" が現れて、それに続く domain にあたる部分が "hxxk.jp" となっています。

RFC 2822 - 3.2.4. Atom

次に、 local-part や domain を構成している、 dot-atom について。

Several productions in structured header field bodies are simply strings of certain basic characters. Such productions are called atoms.

Some of the structured header field bodies also allow the period character (".", ASCII value 46) within runs of atext. An additional "dot-atom" token is defined for those purposes.

和訳の方の同じ項を見ると、

構造化されたヘッダフィールドボディのいくつかの産物は、単にある基本的な文字列である。 そのようなものをatomと呼ぶ。

いくつかの構造化されたヘッダフィールドボディはまた、一連のatext中ピリオド(".", アスキーコード46)が許可されている。 追加の「dot-atom」トークンがその目的で定義される。

とあります。

これを逆の視点で見ると、 dot-atom トークンが定義されているヘッダフィールドボディでは、 atext の中に "." ( &#46; ) を記述することが許可されているということだと私は捉えました。 そして今の引用部分のすぐ下を見ると、 atext についての説明が書いてありました。

atext           =       ALPHA / DIGIT / ; Any character except controls,
                        "!" / "#" /     ;  SP, and specials.
                        "$" / "%" /     ;  Used for atoms
                        "&" / "'" /
                        "*" / "+" /
                        "-" / "/" /
                        "=" / "?" /
                        "^" / "_" /
                        "`" / "{" /
                        "|" / "}" /
                        "~"

ASCII 文字コード表に定義されている文字のうち、 制御文字 ( 0x00 ~ 0x1f および 0x7f ) と SP ( 0x20 ) とspecials ( 特殊文字 ? ) を除いたもののようです。 ちなみに specials は、同じ RFC 2822 中の 3.2.1. Primitive Tokens にて示されています。

specials        =       "(" / ")" /     ; Special characters used in
                        "<" / ">" /     ;  other parts of the syntax
                        "[" / "]" /
                        ":" / ";" /
                        "@" / "\" /
                        "," / "." /
                        DQUOTE

これらより、 atext には specials であるところの "." ( &#46; ) は含まれないということになりますが、 local-part には dot-atom トークンが定義されているため、 "." ( &#46; ) を用いることができるという結論になると思います。

"." ( &#46; ) の注意点

allow the period character (".", ASCII value 46) within runs of atext ( 一連のatext中ピリオド(".", アスキーコード46)が許可されている ) とあるように、前後に atext が存在する場合にのみ "." が許可されているということなのでしょうか。

If the string can be represented as a dot-atom (that is, it contains no characters other than atext characters or "." surrounded by atext characters) ( その文字列がdot-atomとして表現され得るならば(つまり、atextとatextに囲まれた「.」以外の文字が存在しないならば) ) という記述や、

dot-atom        =       [CFWS] dot-atom-text [CFWS]

dot-atom-text   =       1*atext *("." 1*atext)

という記述があることから考えても、 atext で囲まれていない "." が存在する場合は dot-atom トークンにはなり得ないということだと考えられますので、「 "." の連続使用」と「 local-part の最初や最後に "." の使用」はできない ( atextで始まり,間にatext又は"."が来てatextで終る ) と覚えておいた方がいいと思います。

リプライ

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

2006-02-24T04:43+09:00 - メールアドレスに使える文字列 < JE no hitori chat

&'*+/=?^_@example.com こんなメールアドレスでもいいみたい。...

燃費のカタログ値はあくまで目安

記事データ

投稿者

望月真琴

投稿日時

2004-10-09T18:48+09:00

タグ
概要

走行状態によって燃費というものは大きく変わりますので、カタログ値はあくまで目安として考えていた方が良いと思います。

リプライ

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

記事本文

2004年07月12日に届いた新車のWAGON Rの燃費がよろしくない。 12km/L ってどう云う事よ? カタログでは20km/L と書かれているのになぁ。

20km/L の燃費ということは、いくつか種類がある 660 FX の中で、 4AT の FF の方でしょうか。 ちなみに、この 20km/L という値は 10・15 モードのもののようです。

Q&A/基礎知識8 によると、 10・15モードとは、10の走行パターンを想定したテストを3回行った後、15の走行パターンのテストを1 回加えたテストの結果による燃費の表示方法です。 10モードはやや市街地に近い走行パターン。 15モードは郊外で条件の良い道路を走ったときを想定したパターンです。 とのことで、加減速は少々緩やかなものとなっています。 交通の流れなどもありますし、 AT だと MT に比べてエンジンの回転を細やかに制御できません。 そういった点からカタログ値よりも低くなってしまうのでしょう。 ( 20km/L から 12km/L という減り幅は果たして妥当なものかは分かりませんが。)

私の場合はカタログ値 11.6km/L の 6MT の車で、実測ではだいたい 10 〜 11km/L くらいですね。 ただし、これは自宅が郊外であるために加減速が市街地よりも少ないことと、あまりエンジンの回転を上げずにギアチェンジをしていることに起因しているのだと思います。 休日に市街地の方へ出かけたりすると、やはり 8 〜 9km/L まで落ち込みますし。 逆に、先日遠出をした際に、ある給油地点から次の給油地点までの間にずっと高速道路を走行していたら、その間の燃費は 18km/L という値も出ました。

このように、走行状態によって燃費というものは大きく変わりますので、カタログ値はあくまで目安として考えていた方が良いと思います。

リプライ

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

2004-10-10T21:45+09:00 - 燃費がよくない。 < まったり日記。

2004年07月12日に届いた新車のWAGON Rの燃費がよろしくない。12km/L ってどう云う事よ?カタログでは20km/L と書かれているのになぁ。 でも、我が家で所有していた車の中で一番燃費が良いらしい。15年前まで乗っていたTOYOTAのマークIIが5km/L、3年前から父が乗っている三...

2004-10-10T22:11+09:00 - まな

真琴さん、燃費についての詳しい情報、ありがとうございます! >20km/L の燃費ということは、いくつか種類がある 660 FX の中で、 4AT の FF の方でしょうか。 はい。http://www.suzuki.co.jp/dom4/lineup/wagonr/price/index.htmlから照合するとそのタイプのようです。 思い当たったのですが、最近は所属しているサークルの関係で、車で市街地へ出向く機会が増え、燃費が20km/L(公称値)→12km/L(実際の燃費)になったのかな?と気付きました。田舎と比べ、赤信号で一時停止している回数が相当多いんです。 走行状態によって燃費って大きく変わるんだって事を、以後 心得ておきます。

架空請求実例メモ 2004/10/09

記事データ

投稿者

望月真琴

投稿日時

2004-10-09T17:50+09:00

タグ
概要

頭の悪いスパム と書かれている通り、穴がありすぎる請求メールです。全く関係のない、しかしもっともらしい名前の法律を持ち出して詐欺を行おうとしています。

リプライ

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

記事本文

本当は自分の所に届いたものをネタにすべきかもしれないけど

幸いというか残念というか、私は未だ架空請求メールというものが届けられたことがありません。 ただ、来るべき時 ( おおげさ ) に備え、それがどういったものなのかを把握しておくに越したことはないでしょう。 ということで、 サル並日記りろぉでっど(2004-10-08) - 電子消費者契約通信未納利用料金請求通達 をメモ。

頭の悪いスパム と書かれている通り、 PC 総背番号制 - 突っ込み所が多すぎる次世代コードと同様に穴がありすぎる請求メールです。 サル並日記りろぉでっど(2004-10-08) - 電子消費者契約通信未納利用料金請求通達内に書かれていたメールアドレスで検索すると、同様のメールを受け取って突っ込みを入れているページ ( ようこそ spam 君 - お客様コード:AB-1234567 ) を見つけたので、そこと重複しないように突っ込み所を探してみます。

これまで貴殿の利用料につきましてはコンテンツ事業者方に未だご入金がなくまた、誠意ある回答も頂いておりません。 よって「電子消費者契約民法特例法」上、以上の理由から信用調査会社を経由して弊社に貴殿の個人情報を利用料金支払遅延者リスト(ブラックリスト)掲載要請が弊社に届きました。

電子消費者契約民法特例法 って、 電子消費者契約及び電子承諾通知に関する民法の特例に関する法律の第三条のことでしょうか。 これって全く「料金未納によって個人情報をブラックリストに掲載を要請すること」と関係ないと思うのですが。

(電子消費者契約に関する民法の特例)
  • 第三条 民法第九十五条ただし書の規定は、消費者が行う電子消費者契約の申込み又はその承諾の意思表示について、その電子消費者契約の要素に錯誤があった場合であって、当該錯誤が次のいずれかに該当するときは、適用しない。 ただし、当該電子消費者契約の相手方である事業者(その委託を受けた者を含む。以下同じ。)が、当該申込み又はその承諾の意思表示に際して、電磁的方法によりその映像面を介して、その消費者の申込み若しくはその承諾の意思表示を行う意思の有無について確認を求める措置を講じた場合又はその消費者から当該事業者に対して当該措置を講ずる必要がない旨の意思の表明があった場合は、この限りでない。
    1. 一 消費者がその使用する電子計算機を用いて送信した時に当該事業者との間で電子消費者契約の申込み又はその承諾の意思表示を行う意思がなかったとき。
    2. 二 消費者がその使用する電子計算機を用いて送信した時に当該電子消費者契約の申込み又はその承諾の意思表示と異なる内容の意思表示を行う意思があったとき。

市民生活課/消費生活相談についてに簡単な解説があります。 インターネットなどによる電子商取引の場合、消費者の操作ミスによる契約の救済(契約を無効とする条件の緩和)、契約の成立時期について、相手へ到達した時とする到達主義の採用を定めたもの とあり、検索などでこの法律の条文を見つけることができれば、全く関係のない、しかしもっともらしい名前の法律を持ち出して詐欺を行おうとしているのが分かります。 ( 他の部分の文面から明らかに詐欺って分かるだろうと思いますが。 )

架空請求事業者データベースにも載っていた

PC 総背番号制へのトラックバックで知った、 夢ならというサイトがあるのですが、架空請求事業者データベースといったコンテンツがあり、「何か覚えの無い業者から請求が来たけど、架空請求業者かな ? 」という時に調べるのに活躍しそうです。

実際に、サル並日記りろぉでっど(2004-10-08) - 電子消費者契約通信未納利用料金請求通達の主役 (?) である「株式会社日本データー管理機構」を検索してみると、 2004-10-09T17:46:48+09:00 時点の検索結果は 31 件となりました。 それだけ多くの人に請求通達を送っているということなのでしょう。

リプライ

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

強調するための文字間の空白の是非 (2)

記事データ

投稿者

望月真琴

投稿日時

2004-10-07T22:15+09:00

タグ
概要

ココログベーシックの場合、個別の要素に対するスタイル指定は基本的には不可。 b 要素は、その内容をボールドで表示する要素で、フォントファミリをブロック体にする要素ではありません。 blink 要素は NN の独自拡張であり、現状では使うべきではありません。

リプライ

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

記事本文

空白を空ける = 強調 とする表現もある

強調するための文字間の空白の是非 (1) を公開した後に、 ドイツ語圏では、ゲシュペルトといって文字間隔を広げるのは強調の意味になります ということを某氏より教えていただきました。 ( クローズドな場での発言だったので、名前を出して良いものか分かりませんでした。 あとでその件についてお伺いします>某氏 )

そして、同じく強調するための文字間の空白の是非 (1) で取り上げた weblog でも、 スペースを開けるという掲示板的やり方(ドイツ式ともいう) と、同様のことを述べられていたことを確認しました。

また、組版ソフトの解説ページでは、 ドイツ語文書では,強調部を(イタリックではなく)隔字体 (Sperrsatz) 処理することがあります(フラクトゥア体のようにイタリックを持たないドイツ活字体においては,強調部は隔字体で組まれるのが普通です)。 といった記述も見受けられました。

文字間隔を広げることが強調になるということは初めて知ったので、目から鱗が落ちた気持ちです。 それはさておき、ゲシュペルトと隔字体をどう web ドキュメントにて表すかを考えてみようと思います。

ゲシュペルトによる強調を HTML で表現

ゲシュペルトについて検索してみると、 web ドキュメントにおいてゲシュペルトをそのまま文字間に空白を挿入することで再現しているケースはほとんど無く、それぞれ代替案を用いているようです。

  • 原文の強調(隔字体・ゲシュペルト)は斜体・太字に換えた。
  • 原文でゲシュペルトになっている箇所は、HTMLにはゲシュペルトの概念がないし、また、検索の際に厄介なので、ボールドで表示することにした。
  • ゲシュペルトで表現されている箇所は太字にて示しました。
  • 下線による強調は原文ゲシュペルト

これは HTML において、そういった視覚的効果を得られる要素が存在しないからこその手法だと思います。 ( 仮に gesperrt 要素 ( 仮名 ) が存在していたとしても、必ずしもそういった視覚的効果を以ってブラウザ上に表現されるかは断言できませんが。 ) 視覚的な差異を以って構造を表す紙媒体の文章と、論理的な意味付けを以って構造を表す HTML を同列に考えることにそもそも無理があるため、 em 要素を用いて、論理的に強調であるというマークアップを行えば充分だと思います。

「 em 要素では、単なる強調もゲシュペルトによる強調も一緒になってしまい、その違いを表現することができない !! 」と思うのであれば、 class 属性を用いて <em class="gesperrt">ゲシュペルトによる強調部分</em> とマークアップし、強調するための文字間の空白の是非 (1) - 文字間隔は CSSで示したようなスタイルを指定すれば、論理的にも視覚的にもゲシュペルトによる強調を実現できるはずです。

Re: ココログはstyle属性を付けられる?

スタイルシートはほとんど使ったことがないし、ココログが変更できるかどうか、ようわからんけど とのことなので、調べてみました。

ココログベーシックの場合、 デザインは「レイアウト」「コンテンツ」「並べ方」「スタイル」の4つで決定 されるということのようです。 個別の要素に対するスタイル指定は基本的には不可。 ( uau:ココログのCSS のような方法もありますが。 ) ココログプラス / ココログプロであれば CSS も自由にカスタマイズできるようです。

となると、 CSS のカスケーディング処理の利点が生かされない手法になりますが、特定の em 要素に対して直接 style 属性を指定する方法を取らざるを得なくなります。

とにかくコピペで実験してみよう。

お願いです、機種依存文字を使わないで下さい!

成功している?

成功しています。 ココログは、記事本文中に記述されたタグを解釈して表示しているのでしょう。 ただし、町村さんの仰る通り、 <font size="5">お願いです、機種依存文字を使わないで下さい!</font> と指定するのとあまり意味は変わらなくなってしまいます。 ( 非推奨要素である / 非推奨要素ではない、という点を考えなければ。 )

やはり、 CSS を自由にカスタマイズできない環境の場合は、あまり視覚的な効果に囚われず、 <em>お願いです、機種依存文字を使わないで下さい!</em> というマークアップにしておくのが確実だと思います。

b 要素と blink 要素

<b>お願いです、機種依存文字を使わないで下さい!</b>←ブロック体になるはず<br />
とか<br />
<blink>お願いです、機種依存文字を使わないで下さい!</blink>←点滅するはず

b 要素は、その内容をボールドで表示する要素で、フォントファミリをブロック体にする要素ではありません。 よって、 こうして実験してみると、まずもともとブロック体の仲で<B>タグを使っても意味がなかった というのは、意味がないということはないと言えます。 まあ、単に「ボールドで表示する」と指定するだけ ( 実際にボールドで表示されるかはブラウザの実装に依存 ) で、そこに強調の意味は含まれていませんが。

また、 blink 要素は NN の独自拡張であり、 IE など他のブラウザでは点滅表示はされません。

Note. The BLINK and MARQUEE elements are not defined in any W3C HTML specification and should not be used.

【注】BLINK要素とMARQUEE要素は、W3CのどのHTMLの仕様にも定義されていないものです。 コンテンツ制作者は、それらを使用すべきではありません。

仮に IE などで点滅表示されたとしても、現状では使うべきではありません。

7.2 Until user agents allow users to control blinking, avoid causing content to blink (i.e., change presentation at a regular rate, such as turning on and off). [Priority 2] (Checkpoint7.2)

7.2 ユーザーエージェントで点滅(blink)に関する設定が可能になるまでは、内容を点滅させることは避ける(つまり、規則的に表示されたり消えたりというような表現は別の表現に変更する)。 [優先度2] (チェックポイント7.2)

まとめ

ここまで長々と書いてきましたが、実は一言にまとめられます。

視覚的効果をあれこれ模索するより、 <em>強調したい部分</em> とマークアップして、文章自体をよりよいものとするよう心がけるべき。

em 要素で論理的に強調であるとマークアップしていれば、あとは UA がボールドなりイタリックで表示してくれるなり ( ゲシュペルトで表示するブラウザも存在しないとは断言できません ) 、音声の調子を強めて読み上げてくれるなりしてくれます。

リプライ

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

2006-02-08T00:24+09:00 - とおりすがり

「ゲシュペルト」は gespelt ではなく gesperrt です。 内容は面白く拝見しました。

2006-02-08T00:34+09:00 - 真琴

ご指摘ありがとうございます。本文中の表現を修正しました。 初稿時期としてはかなり前の記事なので記憶があいまいですが、「ゲシュペルト」という音から想像して「 gespelt 要素」や <em class="gespelt"> といった表現をしていたようです。

強調するための文字間の空白の是非 (1)

記事データ

投稿者

望月真琴

投稿日時

2004-10-06T21:11+09:00

タグ
概要

「民法?・?」と表示されます とのことなので、おそらく Windows 環境ではない方なのでしょう。しかし、この記事の記述は音声ブラウザ使用者から、お願いです、無意味な空白を文章中に挿入しないでください !! と言われかねないのでは、と思いました。 em.gespelt { letter-spacing: 1em; } と CSS に記述して、該当箇所を <em class="gespelt">ゲシュペルト強調したい部分</em> とマークアップすれば、ゲシュペルト強調を実現できます。

リプライ

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

記事本文

空白を空ける = 強調 ?

適当に色んなサイトをうろうろしている際に見かけた記述。

コメントに書いてあげようと思ったが、書き込めないのでこちらに書いてしまう。

お 願 い で す、機 種 依 存 文 字 を 使 わ な い で 下さい!

多分、「民法I・II」と書かれているのでしょうが、私には「民法?・?」と表示されます。
ウェブでは、ローマ数字や丸付き数字は避ける、ローマ数字はIとかVとかXとかのアルファベットで代用し、丸付き数字は仕方ないから[1]などと表記することをお勧めします。

出版社なら(それもブログを使おうという意欲的なところなら)、みんなに見やすい紙面・画面つくりということに意を尽くして下さるものと期待してます。

「民法?・?」と表示されます とのことなので、おそらく Windows 環境ではない方なのでしょう。 機種依存文字はたいてい普通の (?) 文字で代替が可能ですから、仰っている意味はよく分かります。 しかし、この記事の記述は音声ブラウザ使用者から、お願いです、無意味な空白を文章中に挿入しないでください !! と言われかねないのでは、と思いました。

紙媒体などで、均等割付を実現するために文字間に空白を挿入することはよく見受けられますが、紙媒体ではないウェブコンテンツ上では、アクセシビリティの低下を招く手法でしかありません。 私は音声ブラウザを持ってないので、憶測で物を言う形になってしまいますが、 お願いです、機種依存文字を使わないで という、おそらく強調の意図を込めていると思われるこの記述は、 Web系メモ - ホームページ・リーダー v3.01 の読み上げメモを参考にしてホームページ・リーダー v3.01 での読み上げを想像すると、 「お」「ぶらんく」「がん」「ぶらんく」「い」「ぶらんく」「で」「ぶらんく」「す」、「き」「ぶらんく」「たね」「ぶらんく」「い」「ぶらんく」「ぞん」「ぶらんく」「ぶん」「ぶらんく」「じ」「ぶらんく」「を」「ぶらんく」「し」「ぶらんく」「わ」「ぶらんく」「な」「ぶらんく」「い」「ぶらんく」「で」「ぶらんく」「ください」 といった読み上げ方になると予想できます。

文字間隔は CSS

と、いうことでこの問題をクリアしつつ同じような表現を実現できる代案を。 CSSletter-spacing プロパティを使用します。

em 要素に対して指定
em {
  letter-spacing:  1em;
  }

CSS に記述して、該当箇所を <em>お願いです、機種依存文字を使わないで下さい!</em> とマークアップすれば良いです。

class を指定した em 要素に対して指定

全ての em 要素にこのスタイルが適用されてしまうのがまずいならば、

em.gespelt {
  letter-spacing:  1em;
  }

CSS に記述して、該当箇所を <em class="gespelt">お願いです、機種依存文字を使わないで下さい!</em> とマークアップすれば、 class 指定をしていない em 要素には適用されません。

スタイルシートを変更できない weblog サービスの場合

もしかしたら、 weblog サービスによってはユーザーからはスタイルシートを変更できないものもあるかもしれません。 その場合は妥協策として、 style 属性を使用します。

該当箇所を <em style="letter-spacing:1em;">お願いです、機種依存文字を使わないで下さい!</em> とマークアップすれば、スタイルシートを変更できない場合でも実現できます。

スタイルシートを変更できない、本文中にタグを記述できない weblog サービスの場合

そういう weblog サービスがあるのかどうかは知りませんが、その場合は実現不可能です。 まあ、同じ文章中に、通常の文字間隔と異なる文字間隔を指定する必要が生じる場面などほとんど無いと思いますので、 ドイツ語圏ではゲシュペルトという、文字間隔を広げて強調とする手法がありますが、それをそのまま web ドキュメントに用いているケースはほとんどありませんので、 半角 / 全角スペースを一文字ごとに挿入するということはせず、通常の em 要素による強調で表現するようにしてください。

リプライ

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

2004-10-07T08:35+09:00 - ココログはstyle属性を付けられる? < Matimulog

機種依存文字を使うなというエントリに強調表示のつもりでスペースを多用したら、読み

Movable Type 3.01D-ja と 2.661 の違いを探る (2)

記事データ

投稿者

望月真琴

投稿日時

2004-10-05T02:04+09:00

タグ
概要

既に 2 つ投稿してある記事の内の片方に、テストコメントとテストトラックバックを送ってソースを比較してみます。

リプライ

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

記事本文

コメントやトラックバックを投稿してみて比較

Movable Type 3.01D-ja と 2.661 の違いを探るの続き。 既に 2 つ投稿してある記事の内の片方に、テストコメントとテストトラックバックを送ってソースを比較してみます。

そのために、ウェブログの設定にてトラックバックをデフォルトで受け付けるにチェックを入れるという変更を行いました。

  • Template sample 2.661 default: 3.01D-ja Main Index の Lint 結果のコメント
  • Template sample 2.661 default: 3.01D-ja Main Index の Lint 結果のトラックバック
  • Template sample 3.01D-ja default: 3.01D-ja Main Index の Lint 結果のコメント
  • Template sample 3.01D-ja default: 3.01D-ja Main Index の Lint 結果のトラックバック

これから実際のソースの比較を行い、結果を追記していこうと思います。

Movable Type 3.11 がリリースされたので、検証作業は中止します。

リプライ

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

Copy URL+ をカスタマイズ

記事データ

投稿者

望月真琴

投稿日時

2004-10-03T05:47+09:00

タグ
概要

plant4 - Firefox拡張copyurlplusのメモを参考にして自分用のサンプルを作ってみました。

リプライ

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

記事本文

この記事は obsolete です。 Copy URL+ 1.3.2 のまとめ。導入からバグへの対処、カスタマイズの例まで。を参照していただくようお願いします。

Copy URL+ をインストール

Mozilla Firefox には拡張機能をインストールすることで自分好みのブラウザに仕立て上げることができるという大きな特徴があります。 今回は、表示しているページの URI や title 要素の内容をクリップボードにコピーしたり、 user.js のカスタマイズによって a 要素によるリンクや blockquote 要素による引用、 q 要素による引用をサポートすることができる拡張 Copy URL+ をメモ。 情報元はえむもじら Copy URL+: url+タイトルをコピーです。

詳しい説明やカスタマイズ方法は plant4 - Firefox拡張copyurlplusのメモが詳しいので参照してください。 以下私の環境 ( Mozilla/5.0 (Windows; U; Windows NT 5.1; ja-JP; rv:1.7) Gecko/20040626 Firefox/0.9.1 ) での手順をメモ。 ローカルファイルのパスなどは一部伏せています。

  1. mozdev.org - copyurlplus: index から、 Copy URL+ をインストールする。 ( mozdev.org - copyurlplus: installation )
  2. C:\Documents and Settings\UserName\Application Data\Mozilla\Firefox\Profiles\xxxxxxxx.xxx\user.js に、カスタマイズ用の記述 ( 次項を参照 ) を追加
  3. Firefox を再起動
  4. 完了

正常に完了した場合、 web ページ上でコンテキストメニューを出すと、このスクリーンショットのように各種機能が出てくるはずです。 Copy URL+ --> Copy URL + Title, Create Link, Create Cite, Create Blockquote, Create Quote

Copy URL+ をカスタマイズ

user.js に以下のような記述を加えることで、より便利な機能を実現することができます。 plant4 - Firefox拡張copyurlplusのメモを参考にして自分用のサンプルを作ってみました。 ひとつの機能に対し、記述するコードは 2 行になります。

記述例

上の行ではコンテキストメニューに表示される機能名を、下の行ではクリップボードにコピーされるコードを設定します。 両方の行で、変数 n は同じ数字を記述するようにしてください。

user_pref('copyurlplus.menus.n.label','機能名');
	user_pref('copyurlplus.menus.n.copy','クリップボードにコピーされるコードの書式');
Create Link

現在表示しているページの URI と title 要素の値を用いた a 要素によるリンクを作成します。

user_pref('copyurlplus.menus.1.label','Create Link');
user_pref('copyurlplus.menus.1.copy','<a href="%URL%">%TITLE%</a>');

クリップボードには以下のような形式でコピーされます。

<a href="URI">Title</a>
Create Link ( Remote )

a 要素によるリンクが行われているテキストをドラッグした際に、その href 属性の URI と、ドラッグしたアンカーテキストを用いた a 要素によるリンクを作成します。

user_pref('copyurlplus.menus.2.label','Create Link ( Remote )');
user_pref('copyurlplus.menus.2.copy','<a href="%RLINK%">%SEL%</a>');

クリップボードには以下のような形式でコピーされます。

<a href="URI">Title</a>
Create Link with Cite

Create Link を更に cite 要素で囲んだ a 要素によるリンクを作成します。 出典や参照先を表す際に使用します。

user_pref('copyurlplus.menus.3.label','Create Link with Cite');
	user_pref('copyurlplus.menus.3.copy','<cite><a href="%URL%">%TITLE%</a></cite>');

クリップボードには以下のような形式でコピーされます。

<cite><a href="URI">Title</a></cite>
Create Blockquote

blockquote 要素での引用に使用します。 cite 属性に現在表示しているページの URI を、 title 属性に現在表示しているページの title 要素の値を用いた blockquote 要素を作成します。

引用したいテキストをあらかじめドラッグしておくことで、その blockquote 要素内の p 要素内に引用したいテキストを挿入することができます。

user_pref('copyurlplus.menus.4.label','Create Blockquote');
user_pref('copyurlplus.menus.4.copy','<blockquote cite="%URL%" title="%TITLE%">\n\n<p>\n%SEL%\n</p>\n\n</blockquote>');

クリップボードには以下のような形式でコピーされます。

<blockquote cite="URI" title="Title">

<p>
#PCDATA
</p>

</blockquote>
Create Quote

q 要素での引用に使用します。 cite 属性に現在表示しているページの URI を、 title 属性に現在表示しているページの title 要素の値を用いた q 要素を作成します。

引用したいテキストをあらかじめドラッグしておくことで、その q 要素の内容に引用したいテキストを挿入することができます。

user_pref('copyurlplus.menus.5.label','Create Quote');
user_pref('copyurlplus.menus.5.copy','<q cite="%URL%" title="%TITLE%">\n%SEL%\n</q>');

クリップボードには以下のような形式でコピーされます。

<q cite="URI" title="Title">#PCDATA</q>

類似の拡張

Camino べんりセットという Bokmarklet にも類似の機能が備わっています。 Camino べんりセット - リンクタグ作成や、 Camino べんりセット - ページタイトルなどがそれにあたります。

私は本来これを愛用していたのですが、 Mozilla Firebird 0.7 から Mozilla Firefox 0.8 にアップグレードされた際に一部の機能が使えなくなってしまっていたのです。 その中にリンクタグ作成も含まれていたので、今回の Copy URL+ を知ることができたのは嬉しいです。

ちなみに、一部機能以外は現在でも使える上に、どれも痒いところに手が届く機能が満載なので、このべんりセットも入れるとより便利になるかもしれません。

http://www.remus.dti.ne.jp/~a-satomi/bunsyorou/Camino_benriSet/beta/ にて配布されているバージョンだと無事動作しました。 Copy URL+ と両用でばしばし活用していこうと思います。

トラックバック送信先

リプライ

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

2004-10-04T01:01+09:00 - Firefox拡張copyurlplus < データバックアップメモ - extended -

plant4 - Firefox拡張copyurlplusのメモで同様の機能を持つMozilla用の拡張機能が紹介されている。Mozilla系ブラウザの情報を紹介してるえむもじらでも記事になっているようなので、既に試してみた人も多いだろう。 copyurlplus 以前の記事で紹介した表示しているページの...

2004-10-06T12:45+09:00 - のり

うちでは、べんりセットの「リンクタグ作成」動いてますよ。 http://www.remus.dti.ne.jp/~a-satomi/bunsyorou/Camino_benriSet/beta/ にあるやつです。

2004-10-06T21:59+09:00 - 真琴

こんにちは、情報ありがとうございます。教えられて思い出したんですが、わたし http://www.remus.dti.ne.jp/~a-satomi/nikki/2004/04b.html#d28n01 の日記も目にしていたんですよね…… ( 「読んで」いたか ? と問われると怪しいですが ) 「基本機能にまだまだ不足の多い Camino (旧称 Chimera) を、ちょっとだけ便利にするかも知れない小ネタ集。」ということで、 Firefox の最新版で動かなくてもしょうがないか、 Firefox べんりセットじゃなくて Camino べんりセットなんだから Firefox のバグフィックスをする義理もないわけだし、多少不具合があっても充分にべんりであることは間違いないし、いざとなったら類似の拡張 ( それこそ今回の Copy URL+ のように) を使えばいいし、といった感じで捉えていたので、ベータばんまでは気が廻っていませんでした。 今回の記事内でべんりセットを取り上げたのも、別に「何々が使えないからダメ」という意味ではなく、 Copy URL+ の紹介にかこつけてべんりセットも紹介したかったという意味なのです。 ベータばんを入れてみて、記事を訂正しようと思います。どうもありがとうございました。

2004-11-06T22:46+09:00 - Firefoxで簡単アソシエイト | Technasia | Crazy on Textpatter < Technasia

このサイト右のメニュー欄に「My Musique」という項目があるのがおわかりでしょうか。9枚のCDジャケットのサムネイルがあり、それぞれAmazon.co.jp アソシエイト・プログラムを経由したペ...

2005-07-20T14:51+09:00 - FireFoxプラグインCopyURL+でカスタマイズ < のまのしわざ(改め)ガンダム部長

goodpicさんのところで見かけて早速パクってみました。...

2005-11-29T20:27+09:00 - Google Analyticsのクリック追跡向けにCopy URL+をカスタマイズ < しげふみメモ

前回の記事でGoogle Analyticsでリンクのクリック追跡 ができましたが、リンクを作成する時に少し手間がかかっていました。 Firefoxの...

2005-12-22T15:55+09:00 - 誤解していたエクステンション「Copy URL+」 < くーすーって美味しいよね

以前記事にしたFirefox 1.5 にインストールするたった3個の拡張機能でマイBest3に取り上げた「Copy URL+」だけど、その機能を大きく勘違...

2006-03-29T13:39+09:00 - Firefoxの追記 < 1yard

もう一個エクステンション入れたので、これは設定の覚え書き。 Copy URL+ と、このエクステンション、このままだと、開いてるタブのURLと...

2006-05-10T04:50+09:00 - CopyURL+ < Fight or Escape

  昨日、リンクタグを作るブックマークレットを紹介しましたが、書きながらふと気付いてしまいました。せっかく CopyURL+ を入れているんだから、そっち...

2006-06-11T16:29+09:00 - FireFoxの拡張機能URL+のカスタマイズ < 発見の日々

 ブログの更新作業の効率化のためにCOPY URL+という拡張機能を使っている。この技は『Life Hacks PRESS ~デジタル世代の「カイゼン」術...

2006-09-20T19:15+09:00 - Firefox 拡張、 Copy URL+のカスタマイズ。 < ケセラセラBrand-new!

user.js の使い方。 右クリックで、サイトのタイトルやURLがコピーできるようになる、 Firefox の拡張、

最初にジュンさんから話を聞かされたときは全く信じていなかったけども

記事データ

投稿者

望月真琴

投稿日時

2004-10-01T22:53+09:00

タグ
概要

末永くお幸せに過ごされることを願い、見届けていこうと思います。

リプライ

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

記事本文

祝福の言葉よりも先に、懐疑的な言葉が出てしまってごめんなさい

えーと、ふだんお酒飲まないのにこういうときだけタイミングよく飲んじゃったりしてぽあぽあしてるんですが。

酔っているときってけっこー失言をすることが多いので一言だけ。

おめでとうございます。

一夜明けて

このサイトでは酔っ払い更新なんてやるつもりはなかった ( このサイトって、別に他に持っているわけじゃないけど ) んですけど、せっかくの嬉しいニュースはその日の内にお祝いしておこう、ということで短いながらもお祝いをしたわけですが。

冷静になって思いを巡らせてみると、お二人がこうして WWW 上に発表するということは、 WWW で親交がある人からすれば、私たちにきちんと報告してくれてありがとう、と言えることだと思います。 その反面、全く知らない人から色々と揶揄されるかもしれない ( そういう人はひとりも居ないと信じたいですが ) といったマイナス面を内包しているのもまた事実。 それでも、堂々と報告してくださったおふたりの誠実さには頭が下がります。

私を含めて、多くの方がお祝いのコメントを寄せたり、それぞれのサイトでお祝いメッセージを発表していたりする辺りに、おふたりの人望が伺えるような気がします。 きっと本人たちは、その各種のお祝いをしっかりと受け止めていることでしょう。

おふたりとも各種のリソースを取りまとめるのを得意としていますが、自分たちへのお祝いをまとめて公表することは、照れなどもあって多分しないだろうということで、お祝いメッセージを勝手にまとめてみました。 ( おふたりの日記に寄せられたコメントは改めてまとめる必要がないので割愛しています。 ) 2004-10-09T15:04:06+09:00 現在で私が確認できたもののみをまとめています。 また、単純にお祝いのまとめという目的以外の意味は持っていませんが、おふたりのうちどちらかひとりでも、あるいはおふたりともがこれを好ましく思わなかった場合は、速やかに撤回します。

きっと、確認できたこれら以外にも多くのお祝いメッセージが寄せられていることでしょう。 改めて、おめでとうございます。 末永くお幸せに過ごされることを願い、見届けていこうと思います。

リプライ

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

Movable Type 3.01D-ja と 2.661 の違いを探る

記事データ

投稿者

望月真琴

投稿日時

2004-10-01T02:35+09:00

タグ
概要

Movable Type 3.01D-ja と 2.661 のテンプレートの違いを確かめるために、実際に共存させてみました。

リプライ

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

記事本文

Movable Type 3.01D-ja と 2.661 を実際に共存させる

Movable Type 3.01D-ja と 2.661 のテンプレートの違いを確かめるために、実際に共存させてみました。

  • Template sample 2.661 default
  • Template sample 3.01D-ja default

この時点ではどちらの方にも記事を投稿していませんし、これ以外の各コンテンツはまだ 2.661 のままで構築しています。 これからサンプル記事を投稿してみたり、色々カスタマイズしてその違いを確かめてみたりしようと思います。

なお、 2.661 の方は、 Milano::Monolog: 日本語化パッチで配布されている日本語化パッチを適用した状態のものを指しますので、全くのデフォルトとは言えないかもしれません。

現在はサンプルの公開は終了しています。

テンプレートを見比べて比較

weblog の設定やテンプレートのカスタマイズを全く行わない状態で、テンプレートを比較してみました。 なお、 Main Index や 各種アーカイブなどについては、テンプレートの記述の比較ではなく、実際に記事を投稿してみて比較しています。

ATOM
  • <issued><$MTEntryDate format="%Y-%m-%dT%H:%M:%S"$><$MTBlogTimezone$></issued><issued><$MTEntryDate utc="1" format="%Y-%m-%dT%H:%M:%SZ"$></issued> に変更になっている以外は同じです。

RSD
  • 全く同じです。

RSS 1.0
  • <dc:language>ja</dc:language><dc:language><$MTDefaultLanguage$></dc:language> に変更になっている以外は同じです。

RSS 2.0
  • 大きく違っています。 2.661 の方では名前空間を指定した要素で構成されていましたが、 3.01D-ja では名前空間を指定した要素はありません。

styles-site.css
  • 冒頭の @charset "Charset ( mt.cfg で設定した文字コード ) " の記述がなくなっています。

    デフォルトテンプレートの XHTML ソースの head 要素でも、 rel="stylesheet" が指定されている link 要素において、 charset 属性は指定されていません。 そして、デフォルトの状態での styles-site.css には日本語の値は含まれていませんが、 font-falily プロパティの値や :after 擬似要素の content プロパティの値で日本語を使用することは充分に考えられます。

    一応サーバ上に生成される CSS は、 mt.cfg の設定を元にして文字コードを決定するようです。 FTP でダウンロードしてみると、 EUC-JP になっていました。 よって、必ずしも @charset が必要というわけではありませんが、無いよりはあった方が確実性は増すと思います。

    ただし、私が検証した 2.661 は日本語パッチを当てた状態のものですので、もしかしたら本来の英語版の 2.661 には @charset は記述されていなかったのかもしれません。 ( 文字化けに気を遣う必要もほとんどないでしょうし。 )

Comment Listing Template
  • コメントの投稿フォームが、 <MTCommentFields> というテンプレートタグによってまとめられ、別途展開するように変更されています。

Comment Preview Template
  • コメントの投稿フォームが、 <MTCommentFields> というテンプレートタグによってまとめられ、別途展開するように変更されています。

Comment Error Template
  • コメントの投稿フォームが、 <MTCommentFields> というテンプレートタグによってまとめられ、別途展開するように変更されています。

  • <br /> <br /> といった記述が p 要素に改められていたり、 <b> 〜 </b><strong> 〜 </strong> に改めていたりと、ある程度論理的なマークアップに近付いている印象を受けました。 ( 個人的にはエラー理由を強調する意味は無いと思いますが。 )

コメント保留のテンプレート
  • 2.661 には存在しないテンプレートです。 コメントスパム防止用のテンプレートでしょうか。

TrackBack Listing Template
  • 各項目の表示形式が少し変わっていますが、抜本的な変更は無いようです。

Uploaded Image Popup Template
  • img 要素の border="0" が無くなり、また空要素として /> で記述されるように変更されています。

    そもそも DOCTYPE 宣言すらないので、どちらの形式を取るべきなのか判断しかねますが。

記事を投稿してみて比較

weblog の設定やテンプレートのカスタマイズを全く行わない状態で、両方の weblog にそれぞれ 2 件の同じ記事を投稿してみました。 以下実際の記事を見比べての感想など。

全般的な XHTML ソースについて
  • xml 宣言が無いのは 2.661 も 3.01D-ja も変わらず。 charset を UTF-8 以外にも設定できるような設計になっているのだから、是非とも xml 宣言をすべきだと思います。

  • 2.661 では <span class="description"><$MTBlogDescription$></span> として配置されていた weblog の概要が、 3.01D-ja では <h2><$MTBlogDescription$></h2> として配置されるように改善されています。

  • 2.661 も 3.01D-ja も一応は Valid XHTML 1.0 Transitional! のようです。 しかし、 body 直下に #PCDATA を記述して、 div 要素で囲んでいるだけといった部分もあり、 Valid ではあるけれど設計思想に甘さが見えてしまう構造なのは 3.01D-ja でも改善されていません。

  • サイドバー、とでも言うのでしょうか、ナビゲーションを記述している部分が、 2.661 では <div id="links"> 〜 </div> となっていたものが、 <div id="right"> 〜 </div> に改悪されています。

    同様に、本文部分も <div id="content"> 〜 </div> となっていたものが、 <div id="center"> 〜 </div> に改悪されています。

Main Index
  • カレンダー、検索、アーカイブ、最近のエントリ、 Powered by 〜 の表示、そして本文という構成は変わらず。

  • Main Index からコメントを投稿する際に、 2.661 では JavaScript によるポップアップだったものが、 Individual Entry Archive の #comments にナビゲートされるようになっています。 これは個人的には非常に嬉しい改善だと思いました。 ( 2.661 の時に、「なんで Individual Entry Archive にコメント投稿フォームがあるのに、わざわざポップアップさせるの ? 」と思っていたので。 )

  • Main Index の本文部分から Individual Entry Archive へのナビゲーションは相変わらず投稿時間をアンカーテキストとしたもののまま。 投稿時間を示す文字列と、 Individual Entry Archive 自身とに全く関連性が無いと言うつもりはありませんが、 Movable Type によって作られたサイトを見慣れていない閲覧者は戸惑うのではないでしょうか。 まだ h3 要素の記事タイトルから Individual Entry Archive へのリンクを行った方が良い気がします。 ( 私はその方式も好ましく思っていませんが、それはまた別の機会に。 )

Master Archive Index
  • 特に大きな違いは無いようです。

Individual Entry Archive
  • <$MTEntryPermalink$>URI の命名規則が、 2.661 では <$MTArchiveLink$><$MTEntryID$>.* となっていたものが、 3.01D-ja では <$MTEnteryTitle$> を基本としたものとなっています。 ( 色々試したのですが、テンプレートタグでは再現できませんでした。 ) これにより、閲覧者は URI を見るだけである程度の投稿時期が分かりますし、また weblog の作成者は過去の日付の記事を投稿する際に URI の整合性を気にする必要はなくなるでしょう。 ( 2.661 の <$MTArchiveLink$><$MTEntryID$>.* は auto_increment なので、後から過去の日付の記事を投稿するのは躊躇われていました。 )

Data-Based Archive
  • URI の命名規則が、 2.661 では <$MTArchiveLink$><$MTArchiveDate format="%Y_%m">.* となっていたものが、 3.01D-ja では <$MTArchiveLink$><$MTArchiveDate format="%Y/%m/">index.* となっています。 これはおそらく前項の変更に伴うものなのでしょう。

Category Archive
  • デフォルトでは使用されないため、検証していません。

リプライ

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

補足情報

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