HTML文書作成日記 : 2004年02月

2004年02月

XREA にお引越し。

なぜマークアップの概念を理解できたのか

記述年月日: 2004年02月08日

で、何故僕がマークアップという概念 (というか、 HTML ) を理解できたのか考えてみたのです。結論から言ってしまえば、 CSS で装飾を施していたらなんか知らんけど HTML を正しく使えるようになっていた、というよくありがち (?) なもの。

僕は当初、 HTML を正しく使おうと思い立ち HTML を勉強したわけではなくて、かっこいいサイト……具体的にはCSSでイケてるデザインサイトリンク集に列挙されているサイトを閲覧し、そして僕も「かっこいいほーむぺーじを作りたい」という衝動に駆られ、前述のリンク集に列挙されているサイトの構造っていうかまあ文書と装飾を眺め、その過程で CSS による装飾をするためには HTML 文書レベルでをきちんとしなければならいことを知り、そうすると当然の如く HTML って何ぞ? という疑問が噴出し前述のリンク集に列挙されているサイト群を眺める機会が増え、それらのサイトの過去のコラム等では「 HTML を正しく使おう」と書かれていることが多く、そこで啓発のでした。

以上をまとめると、

かっこいいほーむぺーじを作りたい (あるいは、したい)
CSS による装飾をするとよいらしい
CSS できちんとした装飾を施すためには、元になる HTML 文書レベルでどうにかしなくてはならない
HTML (「マーク付け」やブロックレベル・インライン要素の概念) を学ぶ
自然と論理マークアップをするようになる
装飾も「うまー」みたいな

というわけなのでありますが、「CSS できちんとした装飾を施すためには、元になる HTML 文書レベルでどうにかしなくてはならない」っていうのは、なんだかちょっと強引なような。

……と、至った過程の半分くらいウソっていうか後付けっぽくて、実際にはっていうかいい加減な記憶として脳に収められているものとして、<br />って何かお洒落! というわけのわからない (今思い返しても本当にわけがわからない) 感情の元、改行する歳には<br />を使っていて、その後しばらくした後Another HTML-lint gatewayを知り、ためしに自分が作成した文書をチェックしてみたらひどいことになっていて、それをあれやこれやと修正していったら何となく正しく HTML が使えるようになってましたーっていう。ようするにチェッカの存在が大きかったような。

補足として。僕はサイトを公開する当初から少々アレな使い方とは言えど既に CSS を使っていたことには変わりなく、その辺も現在に至っている一因になっているような。 CSS の適用方法は外部ファイルでっていうのを採用していたし、段落は p タグで括っていたわけですが。ただまあ、当たり前のようにテーブルでレイアウトはしていました。とはいうものの、サイト作成当初からそれなりに誤っていたとは言えど多少の知識はあったような。ちなみにその頃いろいろと参考にしていたサイトはたろたまというサイト。

結局のところ HTML 単体を教えてすんなりと理解してもらうのは難しいのでしょうね。「かっこいいサイトにしたい」というような動機があって、そのためには HTML をきちんと用いないとダメですよと誘導してしまうのが妥当なような、「 CSS ではここまでカッコ良くできます! 」みたいなアレとセットで。これもまた遠回りのような気もしますが。いや、でも現状では HTML で装飾モドキができてしまっているから難しいか。

で、何故僕はマークアップという概念を理解できたのかは、謎のままなのでありました。

製作者 CSS は必要なのか

記述年月日: 2004年02月08日

数ヶ月前から自前の簡単なユーザ CSSを適用したブラウザデフォルトの装飾がお洒落に見えて仕方が無いのであります、理由はわかりませんが。そういった理由もあって当日記は基本的に面倒な手順を踏まなければ製作者 CSS の適用がされないわけなのですが、なにより当日記のような構造が単純な文書だと、わざわざこちらで CSS を用意せずとも視覚で構造がある程度判別可能だから用意していないっていうのもあったり。何よりブラウザデフォルトのそれに頼っていれば、レンダリングは必ず成功するわけですから、「見づらい (読みづらい) んですがー」なんて面倒なことを言われずに済むから感じがいいのです。

そもそも読みやすくそして勝手の良い装飾を追求すると、どうしてもユーザ側で対処してもらわなければならなくなるように思うのです。文字サイズの好みも人それぞれですし、行間だって (致命的な問題にならないとは言えど) 好みがある。本文の表示領域だって窓いっぱいに広がってしまうのは鬱陶しいとおっしゃる方もいるわけでして。そうこう考えてると製作者 CSS はいらない (必要度が低い) ように思えて仕方が無くなってきたりするのです。

HTML をきちんと用い、 CSS でのみ施していれば、どんなに見づらい装飾といえど CSS をオフにしてしまえばいいわけですから、問題はないのかもしれないのですが、製作者と装飾の好みが合わない閲覧者、あるいは閲覧者の環境では致命的な崩れが発生する状況だと、アクセスの度に CSS をオフにしなければならいわけですから、それならば「閲覧に支障がでるのであれば、 CSS をオフにしてください」と言うよりも「殺風景なのが嫌ならば、製作者 CSS を適用してください。ただし、不具合については対処しません。」という態度でいたほうが、両者の手間がかからず良いような、と。

ただまあ、やっぱりそれなりに力を注いで作成した CSS ファイルならば完全に排除してしまうのも勿体無いと思っているわけでして。以下 (眠いので) 略。

あと念のために断っておくと、「製作者 CSS はウゼぇからデフォルトではオフにしてくれ」って言いたいわけじゃないですよ。

セクションアンカーは必要なのか

記述年月日: 2004年02月08日

セクションアンカーっていうんですかね。ちょっとそういうのわからないのですが。試しにはてなのキーワードで調べてみたら、そのような言葉はキーワード登録されていなかった。使えないと思った。

で、本題。

はてなダイアリーでも十分に固定リンクっぽさは出ているけれども、MT系(?)は記事毎に1枚1枚HTMLファイルを生成するところが最大の利点で、これとTrackBackが組み合わさって最強の言及しやすくされやすい環境が整ってて、さらにHTMLファイルが増える分、Googleにも拾われやすいというおまけ付きなので柊さんは今すぐMTに移行しちゃってほしい、というしつこい圧力。

上記の引用文は少々端折ってあります。ちなみにこの記事を書いた方は、旧態依然としたテキストサイトの一番ダメなところはこのピンポイントリンクが出来ないところと言って間違いない。ともおっしゃられていました。あと、僕は柊さんじゃないことも断っておきます。あと、言及目的という前程で書きます (言及は「される」ではなく「する」で) 。

バカの一つ覚えの如く同一の主張を繰り返すのはまさにバカっぽいかもしれないですけれど、とある記事に対しての言及であれば、必要に応じに引用をし (たとえ参照のためのリンクを用意していたとしても) 閲覧者がその言及記事を読むときには言及の発端となった記事を参照せずとも意味のとおる記事にしてほしい。これは手間もあって記事の作成の敷居は高くなってしまうかもしれませんけれど、発端となった記事が消失したときでもどういった主張に対しての言及なのかわかるという利点もあります。更に、ピンポイントリンクが出来なくても問題はありません。引用してしまえば問題もなくなるので、ダメなところとはならない。

いや、でも、「○○というサイトの××月△△日の記事で云々」なんて文章の場合は、セクションアンカーがないと勝手は悪くなるか……。そういった記事は「これを読んで云々」と書いてしまう方が多いですけれど (そうされると意味が伝わらないというか、これは少し別の問題) 。

あと、 TrackBack があると何で言及しやすくなるのか、わからなかったです。(TrackBack 云々はされやすい環境に係ってるのかな)

以下は別の方が書いた記事。

テキストサイトで「記事単位でリンク」という発想がなかったのは、必要なかったからだと思う。「この記事に対して僕はこう思った」という文中リンクよりも、「この人と遊びに行った」という文中リンクのほうがずっとする機会が多かったから。意見の内容に価値を見いだすブログと、作者のキャラクターに価値を見いだすテキストサイト、それぞれの良さがある。だから私は、個別の記事にリンクできないことが欠点だとは思わない。

いわゆるネットバトルだと引用しますしね。全部が全部ではないにせよ。

そういえば、この記事に対して僕はこう思ったという文言を目にして、ブログって男性っぽいよなと思った。女性がやっているってイメージがないような。なんてことを言うと田嶋陽子さんみたいな方に怒られたりして。とは余談。余談ついでにもうひとつ。この人と遊びに行ったと「この人」を A 要素するわけだけれど、そんなことしなくても、閲覧者の大半は参照せずとも「この人」がどういった人なのか知っているんですよね。周辺単位で巡回してるひとが多いから。あと、閲覧者はその製作者の人柄よりも、「遊びに行った内容」に注目することが多かったり。 (本件とかなりズレた話ですが) オフレポとか。とか根拠の無いことを言ってみた。

あと「あと」が多すぎ。

セクションアンカーは必要なのか #2

記述年月日: 2004年02月09日

つまり僕が言いたかったことは、文書を参照するさせるのであれば要約も添えてくれってことかもしれない。

人が楽しそうにしていると不愉快になる

記述年月日: 2004年02月11日

便乗して僕もはてなの感想とかを。

はてなのつまらない・嫌なところ。

なんか「はてな」って面白いな。

僕は圧倒的に「つまらない・嫌なところ」の方に納得してしまう。どうやら僕の中には、はてなに対する拭いがたい不信感があるようだ。こうして利用していながらもそれは一向に薄まらない。この“敵意”はどこから来るのだろう、と考えながら、「はてなの嫌いなところ」を書こうとしたけど、言語化してみたらしてみたで笑えない結果になりそうだったので、この問題は心の小箱にしまいこむ。

僕も (と一緒くたにしてしまうのは語弊がありそうですが) はてながあまり好きじゃないわけなのですが、何故嫌いなのかを端的に表すと「なんか楽しそう! だからむかつく」というわりとどうしようもない理由であることになってしまった。「だから」が全く後述に繋がっていないのですが、なんだか楽しそうにしている人をみるとイライラとしてしまうわけです。このはてなに対している僕の不快感 (不信感ではなく) はおそらく、一昔前に界隈でよく見かけた人気サイトに対する嫉妬というのの亜種なのだろうと思います。

僕にとっては人の不幸は蜜の味にはならないのですが、人の幸福は苦々しい味になるのです。っていう感情を言葉としてあらわしてみたら、なんだかどうしようもない人間に思えてきた。

で、話は変わりはてなダイアリのようなツールの利点として、更新の敷居が低くなるというのがよく言われているところなのですが、意味を履き違えていた今までは「なんであのシステムで敷居が下がるんですか。むしろ面倒くさくなりませんか」何て思っていたのですが、更新の敷居というのはつまり、マークアップ云々や FTP で云々というのではなく、パスワードとログイン名さえわかれば FTP でアップロードする環境が整わなくても更新できるってことなんだろうなということに気付いたのでありました。ついでに言うと過去ログとかの自動生成も。はてなではないにせよ CGI を使った更新にも似たようなことが。

僕は出先で更新するだとか、携帯電話から更新したいだとか全く思わず、過去ログの自動生成も手間だったとはいえ積極的に改善したいというほどの問題でもなかったのものですから、はてなやそれに似たようなものに魅力を全く見出せなかったのでした。むしろ、ツールを使っての更新は手元にログが残らない (いちいち手元で残すように作成しているのならば、ツールを使う意味もないような) わけで、そうするとサーバの障害などでデータが吹っ飛んでしまったら復旧は困難になるわけですから、またそれで足が遠のく。

話は戻って。で、はてなの不快感というのは、見ている方からするとなんだか閉鎖的だなあと感じてしまい、その中で楽しんでいる人が多いから、やっぱりむかついてしまうのでした。と、相変わらずワケのわからない感情。そもそも閉鎖的な空間なんてどこもいっしょなわけですし。ただまあ、「はてな」というブランド (?) が添えられるとその (見ている方から感じる) 閉鎖的な雰囲気は助長されるんですよね。言ってしまうと、はてなダイアラは胡散臭い集団に見えるのです。なにが胡散臭いのかわからないのですけれど。

まとめると、ダイアラを個人としてみると楽しそうでなんだかむかついてしまい、集団としてみると胡散臭い人々に思えるという感じですか。どうしようもないな、これ。もちろん全てのダイアラがこれに該当するというわけではなくてというか、これ、たぶん偏見というかイメージなのかも。

それからあとひとつ。「はてなのつまらない・嫌なところ。」では以下のように述べられていた。

納得できる点が多いけど、あえて「つまらない」と思えるところを逆に挙げてみる。

みんな同じようなこと（サブカル＆アーバン系の映画や本の感想など）を書いている

ＣＳＳの話は、過不足なく読める程度のサイトならあまり文句ないので興味に乏しい

システムを自分のものと勘違いしている奴らがいる（はてなダイアリークラブのかたがたとか。まぁあちらは目立たないので共存できますけどね）

いちばん上の人が時々うるさい（頑張っている証拠か）

どうでもいいところでどうでもいいリファがある

キーワード登録＆削除方面に、様々なレベルと方向の厨房がいる

おそらく事実の指摘なのでしょうけれど、いくつかは価値観を変えてしまえばつまらないところではなくなると思えました。とは自分にも言えること。

っていうか、まるっきりガキの言動だなあと思った。自分のそれに対して。

「胡散臭い」は「気色の悪い」に置き換えて。

XREA さん、どうぞよろしく

記述年月日: 2004年02月11日

そんなわけで、 XREA さんに引っ越してきたわけです。

XREA さんは立場上、電波にからまれたら是非を問わずユーザのデータを削除してしまわれるようなので (そりゃそうだ、面倒ごとなんて種から削除してしまう方が無難) 、僕も電波にからまれないよう頑張ろうと思うのでありました。

ALT 難民キャンプ

XREA に苦情を呈した方はほとんど電波だよねって話。批判と中傷をごっちゃにしてて。

そもそも自分の言論の正当性に自信があるのならば、批判 (というか誤認の指摘?) をされたところでサーバの管理者になんて泣きつくことはしない。反論をすれば済む話だから。言論に自信がない、つまり批判に対する有効な反論できなく、尚且つ、自尊心が肥大しているから正当な批判であっても腹を立ててしまい、自身を咎めてる記事の存在そのものを許しがたく思い、サーバの管理者に泣きつく。

自身の言論に自信があるのにもかかわらずサーバ管理者に泣きつく、あるいはサーバ管理者への削除要請が自分の価値観の中で正しいことだと思っているのであれば、それは電波、僕からすれば。相手からしても同じなのでしょうけれど、意見交換が出来ず、更に言論そのものを言論以外の手段で潰そうとしているから。

picoBBS に書き込みお知らせ機能を付ける

記述年月日: 2004年02月11日

picoBBS といえば、出力する HTML は、HTML 4.01 Strict / HTML 4.01 Transitional / XHTML 1.0 Strict に準拠しているはずであったり、素敵な返信機能 (具体的には返信すると原本が blockquote 要素とされ、そのようにマーク付けされる) があったりと僕の嗜好にどんぴしゃりなスクリプトなわけですが、書き込まれるとメールで通知というような機能が無く、少々残念な思いをしたのですが、少し探してみたところそのような機能を加えられることがわかったので、その記事を引用。……というか転載なのかな。

せっかくだからコードを公開しときます。sendmail が使えるサーバーじゃないと使えません。

#-----------------------------------------------------------------------
# 投稿をメールで送信
#-----------------------------------------------------------------------
sub send_mail()
{
    my $mail = 'username@server.ne.jp';  # ここで設定したアドレスに送る
    $sendmail = '/usr/sbin/sendmail';    # sendmail のパス

    my @work = (gmtime($NOW))[5,4,3,2,1];
    $work[0] += 1900;
    $work[1]++;
    my $datetime = sprintf("%04d/%02d/%02d %02d:%02d", @work);


    if(open(MAIL, "|$sendmail $mail")){
        print MAIL "To: Username <$mail>\n";
        print MAIL "From: Username <$mail>\n";
        print MAIL "Subject: BBS Report\n";
        print MAIL "Content-Transfer-Encoding: 7bit\n";
        print MAIL "Content-Type: text/plain; charset=iso-2022-jp\n\n";

        print MAIL "name: $FORM{'name'}\n";
        print MAIL "mail: $FORM{'mail'}\n";
        print MAIL "date: $datetime\n";
        print MAIL "rep_number: $FORM{'rep_num'}\n";
        print MAIL "host: $HOST_NAME_IP\n";
        print MAIL "subject: $FORM{'subj'}\n";
        print MAIL "data: $FORM{'data'}\n\n";

        close(MAIL);
    }
}

このサブルーチンを picobbs.cgi の最後にでも追加して、sub do_post あたりで &send_mail; をやれば完了です。

だ、そうです。僕は知識に乏しいので、&send_mail; をやればというのがよくわからなかったですけれど。や、文句をつけているわけではなくて。

話は変わって。当日記 ( /net/ 以下のリソース) では SSI によるアクセス解析をしていて、片っ端からリファラを採取しているのですが、誰も掲示板にアクセスした形跡がない (掲示板からのリファラがない) のがなんだか面白かったです。気分的にはにらめっこ。先に書き込んだほうが負け。

……で、あれやこれやと試していたところ、書き込みお知らせ機能の設置に成功しました。ヤッタ! という感じ。方法は……ってまあ、わざわざと書かなくてもみなさんはわかるのでしょうけれど、僕は喋りたがりなので書いておきます。

前述のコードを picobbs.cgi に追加。 (僕は末尾に追加しました)

「投稿処理」の末尾に &send_mail; を追加 (つまり投稿の処理時に追加したサブルーチンを実行させる (?) )。具体的には以下。

#-----------------------------------------------------------------------
# 投稿処理
#-----------------------------------------------------------------------
sub do_post
{
    (省略)
    &do_normal;
    &send_mail;
}

以上。

簡単ですね。簡単といいつつ、僕は最初できませんでしたけれど。

以下余談。 XREA について。アカウント取得当初にいろいろと試していたのだけれども、 CGI の設置そのものをしていたときに (なにエラーだったか忘れたのですが) 全てのファイルの参照ができなくなってしまったことがあったりなかったり。これはたぶん、ファイルのパーミッションやらの問題もからんでくるのだろうとは思うけれど、ちょっと釈然としないところがあったので少し調べてみたところ、以下のような記事があった。

７．アカウント取得直後はCGIを正常に設置してもうまく動かないことがあります。

この場合はに１～２日待つだけで正常に動作しますので、焦らずにお待ち下さい。

これが原因だったのかなあなどと思いつつも、僕はお知らせ機能の追加が出来て既に満足。

というか、僕は CGI やらの動作環境はローカルで整えているから、パーミッションやらに対して全く無知だったのでありました。 (いやでも、パーミッションを間違えた程度で全てのファイルの参照が不可になるのかな。まあいいですけれど。)

もうひとつ余談。 pre タグの中ではタブによる整形は非推奨っぽかった。根拠は以下。

NN行目の <PRE> 内にはタブを書かないようにしましょう。

<PRE>～</PRE> 内にタブ文字を書くことは避けるように、HTML4.0(J)で強く要請されています。タブ文字は空白文字に置き換えられて表示されるのが普通ですが、モノによって期待通りの結果を得られないことがあるというのが理由です。つまり、<PRE> の整形済みという主旨に反するということです。

水平タブ文字

水平タブ文字 ([ISO10646]及び[ISO88591]の十進9) は、視覚系ユーザエージェントによって、通常、8文字毎に出現するタブ区切り箇所に適合する、1つ以上で最小の空白列として解釈される。本書は、整形済テキスト中で水平タブを用いることは避けるよう、強く要請する。なぜなら、編集の際にタブ区切り幅を8文字以外の値に設定することはよくあることだが、これが誤った配置の文書を生み出す元となるからである。

.htaccess 拡張子非表示無し

記述年月日: 2004年02月11日

わけのわからない見出しは検索エンジン用。

で、 .htaccess を使って (?) ファイルの拡張子を明示せずとも参照できるようにする方法なんてものを。相変わらず「見つけたから引用 (転載) しちゃう! 」みたいな勢いなのですが。

phpファイルで「test.php」があった場合、それを「test」と言うように、拡張子なしでアクセスするにはどうすればいいでしょうか？

Options +MultiViews

でできます。ファイルの拡張子 php はつけたまま，拡張子抜きでアクセスできます。(拡張子付でもアクセスできますが)

詳しくはApache Content Negotiationを。

htmlファイルは、「.htaccess」ファイルを作成し

DirectoryIndex *

DefaultType text/html

にて出来ました。

これはあまりよろしくないですね。この場合も Options +MultiViews を指定し，ファイルの拡張子 html をつけたままにしておいた方がよいでしょう。

この引用文では php について書いているのですが、 php ファイルだけではなく、 html ファイルであったり、 shtml ファイルであったとしても有効。ってまあ、拡張子に依存しているわけではなくて、ファイル名そのものをチェックして表示しているわけですから当たり前と言えば当たり前なのですけれど。詳しくは以下を。

MultiViews の効果は以下のようになります:サーバが /some/dir/foo へのリクエストを受け取り、/some/dir/foo が存在しない場合、サーバはディレクトリを読んで、foo.*にあてはまるすべてのファイルを探し、事実上それらのファイルをマップするタイプマップを作ります。そのとき、メディアタイプとコンテントエンコーディングは、そのファイル名を直接指定したときと同じものが割り当てられます。それからクライアントの要求にもっとも合うものを選び、そのドキュメントを返します。

だ、そうです。これがどの程度サーバに負荷をかけるのかはわかりませんが、でもまあ MT やらが流行っている昨今では気にするほどでもないよなあなんて (傍迷惑) 。

ちなみに、当日記のファイルも、拡張子は明示していないのですが、実体 (というのかなあ) は shtml ファイルだったりします。各ファイルの末尾に .shtml と付記しても同一のリソースが参照できます ( .html では無理です) 。同一のリソースならば一見無意味のようにも思えるのですが、何かしらの事情 (ってなんだ) により拡張子を変更せざるをえなくなってしまったときには、それなりに有効なように思えました。

それから、表紙のファイルは index ではなく、 cover です。つまりってまあ、どうでもいいようなことですが、

http://klezer.s53.xrea.com/net/
http://klezer.s53.xrea.com/net/cover
http://klezer.s53.xrea.com/net/cover.shtml

これらの URI から参照できるリソースは全て同一とかそういう感じでありましたとさ。なんかすごいよねって話。 ./cover/ はだめですけれど。

そういえば、「はじめっから拡張子を付けずに……なんてことをしたらどうなるんだろう? 」と思って実行してみたのですが、ローカルだと平気だったり WWW 上ではダメだったりブラウザによっても平気だったりダメだったりと、実用性に乏しい結果に。

拡張子無し HTML 文書てすと

ちなみにこれは、前述のとおり shtml ファイルでもなければ html ファイルでもなく、拡張子そのものを付けていないファイル。良い子は真似しちゃダメだと思う。悪い子はまあ、好きにするといい。

人がたくさん来た

記述年月日: 2004年02月13日

こっちでは日記ファイル全ての PV (ってのもヘンか) を取っているからちょっとした錯覚もあるのでしょうけれど、今までは一日 6 回程度しかアクセスされない日記サイトだったのに、移転した途端人がたくさんきました。 188 とか笑えた。今までのおよそ 30 倍。赤いアイツ風に換算すると 10 倍。ついでに言うと、人じゃないのもたくさんきてる。はてなのろぼっと? まあいいか (頑張れば除外することも可能なのでしょうけれど) 。ひとつ面白かったのが Another HTML-lint でのアクセスというか、誰かがチェックしたのでしょうけれど、それまで解析に引っ掛かっている点。へえ、と思ったのでありました。

しかしこれも、「どのファイルにアクセスすれば、最新の日記を参照できるのか」などの勝手がわかったり、人気サイトによる参照からの一時的なアクセスなどが無くなる 2, 3 日後には落ち着き払う予感。ちなみにリンク元は界隈の情報発信系サイトだったのですが、これはなんというか芋づる式でありました。つまり、参照された記事は同一の内容。それはさて置き、移転の告知よりも人気サイトからの参照の方が来訪が多いのにごにょごにょ感を覚えました。っていうか、この文章を公開する頃には既に従来どおりのアクセス数になってるんだろうなー。

で、リファラの採取をしているわけですが、リンク元のうちのいくつかは意想外というか簡単に表すと、方面系の方だろうと彷彿していしまうような方もウォッチしてくださっているようで、生来よりのビビり性であるところの僕は、ガクガクブルブルしてしまったのでした (たぶん手違いで補足しちゃったんでしょうけれど) 。どれくらいビビり性かっていうと、あお向けで就寝できないくらいのビビりし性であります。上から何か落ちてきたら顔面に直っちゃうじゃないですか、だから恐いの (可愛い) 。

例によって関係ない話。危うく「人の来訪」とか書きそうになりました。いや、でもこれはアリなのかな。人以外がたずねてくるのも「来訪」といえるのか、この辺がポイントのような。

らいほう　―はう 0 【来訪】

（名）スル

人がたずねて来ること。

⇔往訪

「―者」

「知人が―する」

辞書によると知人が―というのもアリっぽいんで、人が来訪というのもアリと思ったのであります。ありあり。いや、でも「知人」は人目知人科だしなあ。とすると、単純に「人」がたずねてくるときは、「人が来訪～」ではなく単に「来訪～」と書いた方が適切な雰囲気。っぽ?

転載の危険性

記述年月日: 2004年02月13日

ちょっと古い記事ですが。

【衝撃！】消し去ったはずのWebページga保管する

223 名前：権兵衛投稿日： 01/11/03 02:13 ID:jT2xMmhP

例えば、Aさんがプライバシー侵害で訴えたページ。これが削除されたとする。ところが、アーカイブに残っていて、Aさんの個人情報が流出するおそれがあるわけ。すると、Aさんからすれば、たまったものではない、精神的苦痛を受けて、訴えた意味がなくなる。すぐに、ページ管理者が削除依頼を出さねばならない。

しかし、向こうは世界規模であるため、なかなか、すぐには削除されないかもしれない。削除されるまで、ずっと、Aさんは苦痛を味わうことになる。

2chの削除依頼の煩わしさから考えてもあり得る。

さらにもっと怖いのは、二人ともアーカイブの存在を知らなかったら大変なことになること。削除依頼を出さなかったので、知っている第三者だけが、個人情報をえるとか。

ようするに、 (権利を侵害されたなどの) 被害者になる可能性のある方があれやこれやとしなければならない、というのが問題。事あるごとにちょさっけんちょさっけん言う方もアレにみえることがよくありますが。

InternetArchive や Google キャッシュなどは知識さえあれば対処できるのですが、しかし換言すると無知な人間は対処も出来ず、また無知な人間に対しては権利を侵害していいのかというわけであります (たとえば、セキュリティがザルなサーバだからといって、不正アクセスしていいわけではない、みたいな ) 。さらに、ロボットで収集しているのならば、前述のように技術で対処できるのですが、相手が人間だと中々そうもいかない場合がよくあるのです。

と言ってしまうと、僕が転載されるのを嫌っているように思われかねないのでいちおう断っておくと、「当日 (たとえ著作物とされていたとしても) 記は好きにしてください」という感じで。誰もそんなことしませんかって。

159 名前： Name_Not_Found 投稿日： 01/11/01 03:50 ID:1IcuHgcF
とりあえず.htaccessに
order allow,deny
allow from all
deny from .alexa.com
を入れてる。

だ、そうで (最近こんなんばっかだ) 。 .htaccess についてはミケネコの htaccess リファレンスで詳しく解説されています。と自分用めも。

Web制作板にあったテキスレ

記述年月日: 2004年02月14日

テキスレといってしまうと語弊があるかな。っていうか、なんで制作板に? と思った。

以下ついで。

タグの正しい読み方

僕は div を「ディヴ」と心の中では読んでいたのだけれども、なんだか恥かしくて声には出せなかったのだ。しかしスレを眺めてみると少なからずの人が div タグを「ディヴ」と読んでいる方もいらっしゃるようで、なんだか勇気が湧いてきたのでありました。まあ div はDocument Division の意味 (略?) らしいから、ディヴと読んでも平気っぽかったけれど。ちなみに「 div は Document Division の意味」と書いてあったのは、手元のタグ事典。久々に見たっていうか、書籍は目的の言葉をパパっと検索できないから面倒。索引からでもってことですよ。

もういっこついで。

トラックバック

これってつまり、スレッドへのトラックバック送信フォームってことなのかな。おじさんはもうついていけん。

はてなアンテナってうざいらしい

記述年月日: 2004年02月14日

アンテナのアクセス程度で「負荷が! 負荷が! 」といっている人はバカかと思った。負荷がというのであれば、むしろ更新されているかどうかアンテナではなく、ふつうに (ってなんだ) アクセスされた方が負荷がかかるように思えた。よくわかりませんが。たとえば 100 人がそれぞれ別々に更新の有無をふつうに (ってなんだ) アクセスして確かめるのと、ひとつの更新情報を 100 人が共有するのとではどちらがサーバに負荷がかかるかということ。

リファラにプライベート設定のアンテナが引っ掛かるのがウザいとおっしゃる方もいたけれど、それだったらアンテナからのアクセス全てを解析結果に吐き出さないようにすればいい。そういうのが出来ないのは自分の技量不足。それを棚に上げてゴチャゴチャ言う方がおかしい。で、自分のサイト (で、なくてもいいけれど) の登録者が気になるのだったら http://a.hatena.ne.jp/include?URI で調べれば解決できる。これならプライベート設定のアンテナは引っ掛からない。

以上は主に製作者側ができる改善方法。以下は文書利用者側からの別にしなくてもいい改善方法。

要するにプライベート設定のアンテナからのリファラがアクセス解析の結果に表示されなくなればいいわけだから、話は簡単なような。いくつか解決案が浮んだので書いてみます。冗談半分ですけれど。

ひとつはアンテナの設定で更新の有無を調べる URL とアンテナからのリンク先 URL を弄くればいい。アンテナからのリンク先 URL については以下を。

ページの編集 - リンクURL （詳細モード）

更新をチェックしたいURLとリンク先にしたいURLが異なる場合は、この項目を書き換えてください。

例えば

更新をチェックしたいURLがhttp://www.hatena.ne.jp/new.html

アンテナからリンクをしたいURLがhttp://www.hatena.ne.jp/

のような場合、前者をURL追加欄に入力し、後者をリンクURL欄に入力してください。

で、このアンテナからリンクをしたいURLを http://www.google.com/search?&q=URL と書き換えたり、あるいは http://ime.nu/URL などにすれば参照元もそのようになるので、プライベート設定のアンテナからのリファラは残らない。ちなみにここで施したアンテナの設定は全ユーザ共通のものとなるので注意が必要です、たぶん。あと ime.nu からのリファラは別の意味で嫌がられそうなのでこれもまた注意してください。

もうひとつはリファラを採取されないようブラウザの設定を弄ればいい。 Opera は設定でリファラの吐き出すか否かを設定できるし、 Mozilla であってもMozilla プロファイルなどを参考にカスタマイズすればリファラを吐き出さずに済む。 IE は知りません。たぶん無理 (のような) 。

そもそも公開されている文書の製作者が参照元そのものに対してゴチャゴチャ言うのはおかしい。もし問うのならば (リンク元という意味も含めた) リンクそのものではなく、参照の内容であるべき。よって、内容のないアンテナからのリンクに対しあれやこれやと言うのはおかしい。とか思うのでした。

以下アンテナついで。関係ない話。っていうかめも。

「なつみかん」オフィシャルサイト

XREA さんで設置できるのかなー。

バレンタイン

記述年月日: 2004年02月14日

世はバレンタインデだというのに、僕はなにをやっているか。発情している浮かれた番は妊娠に困ってしまえ! と少しだけ思った。ちなみに男性が浮気をするのは、自身が妊娠をしないためであります。女性はふつうに考えて自身のお腹 (というか膣) から出てくる子はまず間違いなく自分の子 (つまり自身の遺伝情報を受け継いでいる) でありますし、何より、「子孫を残す」ということから考えたら妊娠をしてしまえばそれ以上種を欲しなくてもいいわけですから……以下略。反面男性は、妊娠をしないので子孫を残すということから考えた場合、論理に基けば自身の子供であると認識できるわけでありますが以下略。(つまり僕が言いたいのはバレンタインといったらロッテの監督だろうがって話)

あと、最終更新の日付を出すようにしてみました。よくわからないのでヘンなところがあるかもしれませんが、そのようなときは「ああヘンだ」とか思ってやってください。

ルール違反を指摘すると「いちゃもん」になる

記述年月日: 2004年02月14日

マークアップ

プレーンテキストにタグをつけて、ウェブ上での閲覧に耐えるようにすること。変な形の場合は、「不思議マークアップ」というような言いかたでいちゃもんをつける人間もけっこう多い。

ふりがな

まーくあっぷ

カテゴリー

ウェブ

品詞

普通名詞

こういうのって書いた人わからないんですかね。

妄想

記述年月日: 2004年02月18日

XHTML 2.0

暇つぶしに読んでみたのですが、和文ではないということもありさっぱり意味がわかりませんでした。

で、行内での引用を表す際に用いられていた従来 (?) の q タグにかわり quote タグが定義されたそうなのですが、いちいちとブロックレベル要素とインライン要素を区分面倒だななどと思ったわけです。僕の中での理想の振る舞いは、 HTML4.01 の del/ins タグのように内包される要素によって引用要素もブロックレベル要素と振舞うかインライン要素として振舞うかを決定してほしいのです。さらに、いつの時点で引用したかを示すことができる datetime 属性なんかも加えられると嬉しい。

その他にもたとえば、 a 要素に内包されている a 要素を示した際、少なくとも HTML4.01 では文法違反になってしまうのだけれども、これについても、そう示した際に文法違反にならないようにしてほしいとか思った。しかしそれがまかり通ってしまうと、たとえば、

<a href="http://foo.com/"><a href="http://bar.com/">文字列</a></a>

このような構文も当然アリになってしまうわけで、そうするとやっぱり問題もあるし云々。というかまあ、この例はテキストそのものに問題があるような気もしますけれど。こういう事態を上手く考慮してあれしてほしいわけです。

あとは dfn タグに cite 属性を添えられると個人的には嬉しい。 cite 属性には定義の由来を示せるとかそのような振る舞い。 (ちなみに、 cite の解釈を由来としたのはciteの意味は「由来」？＠9/4のコラムに影響されて)

そんなことをつらつらと考えてしまったのですが、僕のような人間が考えつくような事柄なんて既に考慮され、そしてその上で現在の定義に落ち着いたのだろうと思った。そもそも前述の datetime 属性なんて引用元がきっちりと del/ins を示しそしてきちんと datetime 属性を付記していれば、引用側がいつ引用したかなんて示す必要もないわけだし。とか。

まあいずれにしても、勧告されたところで僕は XHTML2.0 は使わないだろうなあ。

メールは届かないかもしれません

記述年月日: 2004年02月18日

klezer@s53.xrea.com
klezer_@hotmail.com

xrea の方のメールアドレスにメールを送信して、もし届かなかったら hotmail の方に送信をしてみてください。ちなみに送信に失敗 (というわけではないのですが) すると、エラーメールのようなものがすぐさま返ってくるので、そういうのが出なければ平気だと思ってください。送ったはずなのに返信が来ない場合は、単に僕が怠けているだけですので、あまりお気になさらないでください。もし送信した方がいらっしゃったら、の話。

そういえば上記ふたつのメールアドレスは、文字数が同じですね。なんだか得した気分になりました。なにを得したのかは内緒。

あと例によって関係のない話なのですが、「返信 (返事) を返す」という言い回しをしそうになったのですが、これはなんだか変だと思いました。返信 (返事) は返すものではなく、するもの。だからといって、しなければならないものではないですが。

日本語は罠ばっかだなっていう話。

役に立たないサイト検索

記述年月日: 2004年02月19日

そういえば、「面白いサイト」より「役に立つサイト」の方が需要があるように思えました。

角度如何によってはそれ以外も可能 (かも)

記述年月日: 2004年02月19日

「進出」は前以外にも出来そうな雰囲気があったので、ためしに辞書を引いてみたところ前進することともあったので、微妙な雰囲気。しかし進み出ることともあったので、そちらの意味で使うと「前以外にも進出」は可能なように思えた。

あとやっぱり関係ない話なのだけれども、 Google で検索する際に「 Google 検索」ボタンを押して検索をかけると検索結果に大半のブラウザでは、検索ボタンをクリックしなくてもEnterキーを押して、サーチできます。と表示される。Enterキーを押して、サーチしているのにこういわれると、なんだか腹が立って仕方がない。ちなみに Tab キーで「 Google 検索」ボタンにフォーカスを移して Enter キーを押しているわけですが。

製作者が薦める文字サイズは受け入れていません

記述年月日: 2004年02月19日

考えるきっかけとなった文章ということで、引いておきます。引用文の筆者さんにどうこう言いたいわけではなく、文字サイズにデザイン性を求めている人へという感じで。

デザインをリニューアルする際、自分の場合まず基調となる色を決めて配置を決めてCSSファイルをいじっておおまかなデザインを完成させるのですが、いつも最終的に悩むところがフォントサイズの指定について。今までは、メインとなる文章についてはスタイルシートで font-size:90% などと「%」で指定していました。理由は、閲覧者がブラウザ上で大きさを変えられる方がいいと思ったからです。しかし、1ページに詰め込む文字数が多くなると、デザイン上（あくまでも自分のPCの解像度・ディスプレイ上での話しですが）なんだか許せない部分も出てきました。ここ数日、当ページに来てくださっていた方はお気付きだと思いますが、めまぐるしくフォントサイズを変えて「あーでもない、こーでもない」とやっていたわけです。結果、思い切って（？）久しぶりの絶対指定にしてみました。

しかし、やっぱりなんだか心配…。

というわけで、GOINGMAMEWAY:ワンクリックでテキストサイズ変更を参考に、ページ上でフォントサイズを3段階に選べるようにしてみました。

基本的に CSS で見た目を制御しているのであれば、相対値だろうが絶対値だろうが font-size の値に悩む必要はないようなと思ったのですが、製作者が提供する CSS を適用して閲覧してもらいたいならば、という前程で語ると、やっぱり絶対指定よりも相対指定の方が望ましい。

文字サイズの好みは人それぞれであって、仮に製作者が提供する固定化された (如何に関わらず) 文字サイズが気に食わなかったら、文字サイズを自分好みに変えてしまうでしょう、 CSS がある程度わかるユーザならば。そうすると、製作者が意図したデザインになりません。それは構わないのだろうか。それだったら、提供する文字サイズは font-size : 100%; でも良いような。つまりここで僕が言いたいことは、妥協できる範囲を広く取っておいたらどうかということです。

さらに。ユーザ CSS を適用しなければ読みづらいデザインと、そうではないデザイン。どちらが優れているかと考えると、僕は読むのに手間がかからない後者のデザインの方が優れていると思うのです。もちろん絶対値で指定しまっても構わないのですが、比較の問題としてどちらが好ましいかという。ただし、絶対値で指定された文字サイズの提供は閲覧者が好むとは思えない。閲覧者はそれぞれ自分好みの文字サイズを設定しているでしょうから、場合によっては迷惑ともなる。(この段については「読む」のに適したデザインと「眺める」のに適したデザインをごちゃにしてしまっている、僕がって話)

しかし相対値指定をしていたとしても、設定によっていわゆる豆字になってしまうでしょう。そういった点から考えると、たとえ相対値指定をされていたとしても端的に言うとうざっざいことこの上ないので、文字サイズの固定はマシなのかもしれません。しかしサイズ固定は前述したように好ましくありませんから、相対値で指定しましょう。文字サイズに迷ったら font-size : 100%; と指定するのが無難なのではないか、ということです。

以上が一般論とでもいうか、論になってないですけれど。それから、ここで書いた「好ましい」「望ましい」というのは「不特定多数が閲覧する際に、煩わしさを覚えない」という感じで。以下は個人的な考え。こっちがメイン。

前述のように製作者がより良いと思っているデザイン (たとえば文字サイズ) を提供したところで、それを受け入れないユーザがいるということは知っておいて損はないような (そう多くはいないかもしれませんけれども) 。たとえば僕がそうです。

僕は、大きなあるいは小さな文字サイズにイラつくことが多かったので、しばらく前から製作者が指定している文字サイズを殺すユーザ CSS を常態化しています。いんちきくさい部分もありますが、参考に。以下がそうです。ちなみに製作者指定のフォントファミリも無効にしています、これは IE の機能で。

html, body, p, div, blockquote, ul, ul li, ol, ol li, dl, dl dt, dl dd, address, pre, a, q, em, strong, kbd, cite, code, span, img, abbr, acronym, b, u, i, dfn, ruby, rb, rt, center, font, tt, s, small, strike, label, iframe, table, tr, td, th, textarea, input {
- font-size : 100% !important;
}

僕はこの CSS を常態化しているので、僕個人は文字サイズは何でもいいと思うのでした。ついでにいうと、文字サイズによるたとえば強調などの装飾は好ましくないと思っているわけです、これは一般論ではなく至極個人的な事情で。枠線や前景色は背景色でなんとかしてほしいところ (とまでは思ってはいません) 。

あと、 font-size : 90%; などと指定している方が結構多い (のかなあ) ように感じるのですが、なんで小さくしたいのかよくわからない。僕も昨年あたりはたぶんそのような指定をしていたと思うのですが、記憶がさっぱり抜け落ちていて「なんでだっけ」という始末。 90% とかに設定していると利用者もちょうど読みやすい文字サイズになるからなのだろうか (それってすごいな) 。あ、 90% ……というより 100% 以外に指定しているサイトが結構多いってのは、日記サイトでの話です。

Opera ではリダイレクトがきかない模様

記述年月日: 2004年02月21日

今になって気付いたのですが、Opera では、設定でオートリダイレクトをに有効するにチェックを入れていないと、まあ当たり前なのですが latest から指定先のファイルへのリダイレクトがきかない模様です。僕はこの Opera 設定は InternetExplorer のそれと同様に META Refresh によるリダイレクトのみが無効になると思っていたのですが、どうもそうではないようでして。どうもすみません。

ちなみにこの Opera の設定で返されるエラーは 302 Found というものなのですが、この 302 Found というのはHTTP status messagesによると、

302 Found

リクエストされたページは新しい URL に一時的に移動しました。

というものらしいです。知っておくとひょっとしたら得をするまめ知識。あと、あまり関係ないのですが、返すエラー間違ってるんじゃないかと思いました。というか、見合うエラーがないだけのような気も。ちなみにエラーの原文というか Opera で表示される内容は The document has moved here. だったり ( here がアンカーになってる) 。まあこれはそれぞれで違うんでしょうけれど。

で、話は戻るのですが、 302 を返されても「ここをクリック！」みたいなアンカーが用意されているようなので、積極的には改善しない方向で。アクセスのたびにいちいち参照を要求されるのが面倒だという方は、「面倒くせぇなあ」と思いつつクリック (とか) するか、設定を変えるといいかもしれません。どうもすみません。

ちなみに InternetExplorer で META Refresh を無効にする設定はセキュリティレベルのカスタマイズでページの自動読み込みを無効にすると出来ます。これもマメ知識。さらについでに。異なるドメイン間のサブフレームの移動を無効にしていると、そのような事態に遭遇したとき、一瞬だけ「リンクがきかない……?! 」なんて錯覚に陥ることができます。っていうか設定項目にあるサブフレームの意味しているところってなんだ (いわゆる「ピュア」な疑問っていうのかな) 。

あと、僕が InternetExplorer とか Opera とか言い出したらそれは Windows 版のものだと脳内補完してください。

間違っていたのは僕でした

記述年月日: 2004年02月21日

あと、あまり関係ないのですが、返すエラー間違ってるんじゃないかと思いました。というか、見合うエラーがないだけのような気も。なんて書いたのですが、どう考えても間違っているのは僕の方でした。見合うエラーというか、見合う (転送方法……んー、ちょっと違うな) 方法がないってのは的外れではない気もしますが。

Redirect

2004年02月22日日記

記述年月日: 2004年02月22日

嘘日記ですが。という断りも今後はしない予定。

ギリギリ午前中と呼べる時間帯に起床した。天気もよく温かかったのでお出かけ日よりなわけだったけれども、出かけなければならない事情がない限りは家で遊んでいたタイプの人間 (引き篭もって生きていけるなら引き篭もりたいタイプ) である僕は、昨年末に貰った本のうち残りを読み進めることにした。

僕は基本的に貧乏性なので「あげる」といわれたものは何でも貰ってしまうので、その後も度々「あげる」と称して僕に処分をしてもらおうとの目論みの元、本を譲り受けたのだけれど、捨てるのも勿体無いし、かといって誰かに譲るというのも気が引けるし、新しく貰った本に興味深いものがあったものだから、今読んでいる本をさっさと消化して次に移りたかった。

その前にまず腹ごしらえというわけで適当に料理をしてみる。何とか食事として耐えうる「何か」が出来上がる。まあいうまでもなく、あまり美味しくはない。しかし目的は空腹を満たすということなので、最低限の味さえあれば不味かろうが上手かろうがどうでも良かった。ちなみに僕の作るご飯は、知人曰く「ご飯ってより餌? 」だそうで。そういえば 1 回、自分が作ったチャーハンの出来にむかついたことがあったなあと思い出す。アレは確かに「餌」っぽかった。

そんなこんなで気付いたらお昼を回っていた。別段面白い本ってわけじゃなかったけれど、さっさと読み終えたいのでダラダラと本読み開始。

本なんて別に日があるうちから読まなければならないわけでもないのだけれど、冬場の夜は暖房をたいてしまい、その暖かな風ですぐに中途半端な睡魔が襲ってくるので、冬場の読書はできるだけ日のあるうちに済ませたい、と。僕のペースと残りのページ数から考えると、今読んでいる本は夜までには読み終えることができるだろうという雰囲気。だった。

いい感じで集中してきた矢先、電話が鳴る。切れるまで放置を試みるも、中々あいては諦めない。うるさくて仕方がなかったので電話に出てみると知人だった。

「暇。うちこいよ」

「いや、面倒だし」

「なんか予定あんの? 」

「特には」

というわけで、なんだかよくわからないままというか断るのも面倒だったので、知人宅へ足を運ぶことになった (放置をしたら放置をしたでまた後が面倒) 。電車で行けばわずか数分の道のりを貧乏性な僕は徒歩で行く。約 30 分で知人宅に到着。僕は既にグッタリ。

当然のことのように暇な人間がいくら集まったところで暇は解消されるはずもなく、結局、暇人 2 人がひとつの狭苦しい空間におさまっているだけだった。暇つぶしが「暇だよな」と口にすることにも虚しさを覚え始めた (覚えてもすぐに忘れるところがアレ) 頃、さてどうしようとなる。だいたい、この年になっての遊びなんて思いつかないわけで。そんなこんなで仕方がないので他の友人も巻き込み酒を飲むことに。これが 16 時頃。

しばらくした後友人到着。その後はまあ実に下世話な話を肴にダラダラと酒を飲む。一頻り飲みつづけると、彼らは泥酔。僕はまあそれなりに。彼らと飲むと僕はいつも酔っ払いを介抱する側に立たせられるので、なんだか損をした気分になる。トイレにそのまま流してしまいたくなることもあるわけで。やらないというかできないけれど。

知人らが潰れて寝入ってしまったもので、僕はひとりで暇を持て余す。本を持ってくればと少し後悔。それはさて置き、寝ている人間を相手にしたところで面白くもなんともないので、ひとこと「帰るわ」と耳打ちしたのち知人宅を後にする。ちなみにこれは、僕の中で「言った」事実を作るための行為。これであとから何かを言われても僕の心の中にはひとつの正義があるわけで、正当性を主張出来る。実際に相手が認識していたか否かはあまり関係ない、というかこれこそ関係ない話。このあたりはおそらく 21 時。

さすがに僕も酔っていたので、電車を使って帰ろうと思ったのだけれど、腹立たしいことに知人宅に財布を忘れる。財布を取りに帰って電車で家路に着いた方が明らかに時間も労力も短縮できたのにもかかわらず、何故だか知らないけれど、そのまま歩いて自宅に帰ることにした。さすが酔っ払い。

まだ 2 月ということもあって、気温は昼間に比べ驚くほど低く風は冷たかった。しかしアルコールの力もあってか、その冷たさが心地よかった。その心地のよい風の中約 30 分歩きつづけ、周りに目をやると既に自宅近くだった。目には自宅が映っていた。

「ただいま」と僕。特に反応はない。何故だか今日は疲れ、お酒も入っていたので、シャワーも浴びず着替えもせずに少々早めの就寝に。気がついたら寝ていた、というのもヘンだけれども、布団に潜った瞬間に睡眠に。 1 日の終りが 22 時。

寝起きた今は変わって午前 5 時。

見出しのお話

記述年月日: 2004年02月24日

以前に安心していると素っ破抜かれるでちょこっと触れた見出しについてへの感想の (少々別の視点からの) 感想。っていうか、我ながらひどい見出しだ……。あと内容と綺麗に反比例して無駄に長くなってしまっているので、えーっと、その。

見出しをつけるのは確かに大変ですね

読む人によってはあまり気にしていないのかもしれないですが

付ける側はかなり気になってしまうものです。

だからココでは見出しを書かないことにしているのですが。

確かに読む人によってはあまり気にしていないのかもしれないので、気にならない人にとってはきちんとした見出しは必要ないものなのですが、しかし読む人によっては見出しが記事の要約だったりすると利用しやすいわけですよ。なにより仮にきちんと見出しがつけられた記事であっても、見出しがなんだろうと気にならない人は気にしなければいいわけですから、見出しそのものが邪魔になることはないわけで。

最近流行りのブログなんかではある記事を引用し何かを書く、という形もあります。そうした場合でも見出しがあると (またこういった話をすると煙たがられそうですが) 引用要素の title 属性に困ることもなくなるわけで、そういったときにも見出しがあると原本をあたる上で手間がいくらか軽減されるような (原本をあたる必要のない引用の仕方をすればいいわけですが) 。

そういったこともあってか僕は見出しは添えた方が宜しいのではないか、と今は考えています。純粋な日記サイト (ってなんだ) ならば日付も記事の中で重要な要素となるでしょうから、日付でもいいですし、また、見出しを添えるのが手間という場合であったとしたならば、それも日付を見出しにすればいい、とか。内容如何によってはないよりはあったほうがマシという程度かもしれないので、手間と恩恵の比較によって「見出しなんていらないや」と思われるかもしれませんが。

ただ、あまりに「適切な見出し」をつけることに固執してしまうと、見出しに縛られてしまうような事態にも見舞われることがあるので、えーっと、まとまらなくなってきた。 (放り出し)

さらに少しずれた話。以下ちょっとした前提条件が必要になります。

たとえば Mozilla なんかですと、拡張すれば見出し間のジャンプも可能になって (ジャンプという表現は奇異ですけれど便宜上この表現で) 、ふらっと立ち寄った日記サイトなんかでそれを利用すると、きちんとした見出しだったら興味をそそられた記事を手軽に読めるようになりますし、少しズレた話になりますけれどセクションアンカーが用意されていたら IE なんかでもゆなリンク ( MenuExt Library で配布されています) などを利用すれば Mozilla のそれと似たようなことが出来るようになります (いや……どうだろ?) 。

以下は個人的な話というか単なる与太。僕も日付を見出しにしようとは思ったのですが、これ、見出しにセクションアンカーを設けてしまうと重複しちゃうんですよね。 1 日に 1 つの記事というタイプの日記ではないから。んじゃあ時間までを見出しにすればいいんじゃないかってわけですが、時間を添えるはなんか嫌だったという。

あと、僕は基本的には記事の見出しは記事の要約が好ましいと思っているわけなのですが、これは何も「記事」という単位に当てはまることではなくて、文書そのもの (というかサイト) のタイトルにも当てはめていたりします。そんなこんなで「HTML文書作成日記」に……。自分で言うのもアレなんだけど、アレだ。うん。前の方が格好は良かった。しかし、 title 要素は文書の要約というのが頭にあって、それもひとつのあるべき姿のような感じがし、そのあるべき姿にしたいという欲求もあって。

しかしださいよな。「HTML文書作成日記」ってタイトル。

XREA サーバでなつみかんは無理

記述年月日: 2004年02月24日

なつみかんを設置する上で必要になるものを調べてみたら、どうも XREA サーバでは設置は無理なように思えてきたのです。なんか gzip とか cron とかが利用できないとダメらしい。難しいことはわからないのですけれど。

でまあ、できない予感がしているなつみかんの設置に奮闘するのもアレなような気がしてきたので、「もうはてなアンテナでいいさ」「麦を食うさ (麦飯好きだし) 」ってな感じで僕は既に諦めていたのですが、光明が見えてきたので少しメモ。

http://raccy.s1.xrea.com/test/which.cgi

と言うことで、"/bin/gzip"です。他のパスを調べるのにも使えるようにソース付です。

どういうことなのかさっぱりわからなかったのですが、 gzip のパスは/bin/gzipということらしい。オーケー。

さてお次は cron のパスを……というわけで、これもまた調べてみたところ、XREA SUPPORT BOARD - cronは使えないのでしょうかなんてスレッドを発見したわけで。その返答が。

サポートです。

利用できません。

おっしゃるとおり、負荷軽減のためです。

だ、そうで無理らしいです。

しかし無知であるところの僕は cron なんて使えなくたって設置できるんじゃないのか? などと思っていたりもして、そもそも cron が行うことってなんだろう? って言う疑問があったので、ついでとばかりに cron について調べてみたら、どうやら以下のことをしてくれるものらしいということがわかった。

cronは、UNIX系OSに、装備されている自動実行ツールの一つです。指定したタイミングで、繰り返し実行されるので、よく使われます。

つまり、いわゆるアンテナが当たり前のように行っている自動巡回を行うもののようで (たぶん) 。そうすると cron が使えないとなるとアンテナお得意の自動巡回も行えないわけで以下略。しかし自動でチェックをしてくれないてだけの話で、設置そのものはできそうな雰囲気。手動で実行をすれば手間だけれどもアンテナっぽくなるような、などと思ったのでした。やりませんけれど。

ESEHATENAの設置が出来て満足

記述年月日: 2004年02月26日

先日、XREA サーバでなつみかんは無理なんてことを書いたのですが、少々悔しかったので代替案を考えていたところ、 ESEHATENA なんて便利なものを発見したのでそちらを利用することにしてみました。 ESEHATENA というのは簡単に説明するとはてなアンテナのデータを取得してリスト表示するＣＧＩらしいです。この他にも以下のような理念があるようです。

私は生死判定付ブックマーク代わりに、はてなアンテナを利用しています。はてなアンテナは実に便利なんですが、ときたま落ちるのが玉に瑕。ある日、はてなアンテナが落ちたままなかなか復帰しなくて、記憶力に非常に難のある私はアンテナに登録した巡回先のＵＲＬがさっぱり思い出せず、はてなアンテナが復帰するまでは手動での巡回すら出来ませんでした。

そこで、せめて登録したＵＲＬをどっかにバックアップしておければいいなあということで、そういう機能を持ったＣＧＩを作成しました。

それはさて置き、はてなアンテナのデータを取得してリスト表示するわけだから、相変わらずはてなさんを利用しつづけなければならないわけだけれども、これを使えばひとつのサーバで完結 (ってなにをだ) 出来るので当初の目的は達成できそうな勢い。仮にはてなさんから退会することになってもデータの取得を他のアンテナから行えばいいわけで。意味がないようなきもするけれど。

そんなわけで、 ESEHATENA のスクリプトを少々改造して出来上がったのが当サイトのブックマークです。やったね。

ブックマーク

僕はいつまで経っても喋りたがりのままなのでやったことを書きますと、 SSI を使って esehatena.cgi をブックマークを読み込むたびに実行し、そして書き出しているという寸法です。  とかそんなんで。負荷が気になる感じがしたのですが特別参照される数が多いわけでもないですし、 MT やらが流行っている昨今では以下略。というわけで、怒られるまで現状維持で。

そういえば perl って構文ミスに甘いプログラムなのですかね? 禄にわからぬままあれやこれやと弄っているのですが、これといったエラーに遭遇したことはなくて。というかプログラミングなんて高尚なことは僕はさっぱり出来ないので何かと比較してってわけじゃないのですけれど。

はてなでチェックしている人に

記述年月日: 2004年02月26日

こういうことを言ってしまうと、「リンクは自由であるべき」ってのに抵触 (大げさ) するようであまり好ましくはないのかもしれませんけれど。

いちおう表紙の方でも日記の最終更新年月日を出しているのですが、どうもはてなアンテナだとその辺の変動の差異を見出せないようでして、更新をしてもはてなさんは無反応なままっぽいです。そんなわけでして、更新有無をチェックするために表紙を登録しているのだとしたら、あまりオススメできない雰囲気があります。これを逆手にとってはてなアンテナを単なるオンラインブックマークとしているのであれば、表紙を登録するのもアリっぽいのです。

っていうか、更新チェック範囲うんたらってのを誰かが弄っているだけなのかもしれませんけれど (自分んとこは面倒なので登録していないからわからないんです) 、もし原因がそのよう場合であったら適当に使いやすいようにしておいてください。そこまでは介入する気ははないので。

ところで何で利便性の低い表紙へリンクするのかがよくわからないのですが、何故なんですかね。最新の更新が目当てならば表紙を通過せずに直接 (ってのもヘンですが) 最新の月にアクセスすればいいのに、と思うのですが。

前述の利便性と似たようなもの……ではないのですが、 http://foo.com/ と http://foo.com/index.html なんてあったら利用者の大半は http://foo.com/ にリンクなりブックマークなりするんですよね。仮に Home への href 属性値が index.html だったとしたならば、キャッシュとかそういうのを考慮すると http://foo.com/index.html へアクセスしてしまった方が無駄が少ないと思うのですけれど、どうなんでしょう。ユーザはホームページに帰りたがるというような記事文言を~~どこか~~ナビゲーションについての方針で目にしたことがあったのですが、それ関係なのかな。

話がずれた。

RSS の配信がしたいのですが、できませんでした

記述年月日: 2004年02月28日

最近どうも RSS に興味が出てきてしまってどうにか頑張って僕のところでも配信できないものかと駄々を捏ねていたわけなのです。で、そのようなスクリプトがないものかと探してみたらありました。 (端から作る気がないのが僕です。っていうかそもそも作れないし)

RSS関連のPerlスクリプト

ここで列挙されているもののひとつに RSS Generator というものがあって、それを使えば何とか出来そうな勢い。以下がその説明。

指定したウェブページからRSS 1.0形式のRSSファイルを生成するPerlスクリプト。どんなウェブページからでも可能というわけではありませんが、大概のウェブページからは生成できると思います。

スクリプトが勝手に任意のファイルからどうこうしてくれるのかはちょっとわからないのですが。ちなみに動作に必要なものは以下。 readme.txt から引用。

Perl 5.6系

Jcodeモジュール

LWP::Simpleモジュール

URIモジュール

さっぱり意味がわかりませんでした。というわけで、この辺で。(もじゅーるってなんだ……。自分で用意できるものなのでしょうか)

めも

あれだよな、 perl コミュニティとかあればいいんだよな。「この辺をグルグル周っていると何となくわかってきます」的なコミュニティが。

アクセス解析云々

記述年月日: 2004年02月29日

そんなわけで簡単なアクセス解析の結果を公開しているのですけれど、僕はあれ以外にの情報も見ることが出来るので、その辺は念頭においておくといいかもしれません。そもそも僕がわざわざと解析を設置するまでもなく親切な XREA さんは生ログとかそういうのを見せてくるれるので、ドキュメントルート以下へのアクセスの経緯などはある程度わかるって寸法です。たとえば、はてなのアイツが巡回しにくると以下のような情報を僕は知ることが出来ます。

43 [26/Feb/2004:07:35:00 +0900]　 p2026-ipbffx01douji.kyoto.ocn.ne.jp

HEAD /net/latest HTTP/1.1 302
-
Hatena Antenna/0.4 (http://a.hatena.ne.jp/help#robot)

44 [26/Feb/2004:07:35:01 +0900]　 p2026-ipbffx01douji.kyoto.ocn.ne.jp

HEAD /net/200402 HTTP/1.1 200
-
Hatena Antenna/0.4 (http://a.hatena.ne.jp/help#robot)

45 [26/Feb/2004:07:35:01 +0900]　 p2026-ipbffx01douji.kyoto.ocn.ne.jp

GET /net/latest HTTP/1.1 302
-
Hatena Antenna/0.4 (http://a.hatena.ne.jp/help#robot)

46 [26/Feb/2004:07:35:01 +0900]　 p2026-ipbffx01douji.kyoto.ocn.ne.jp

GET /net/200402 HTTP/1.1 200
-
Hatena Antenna/0.4 (http://a.hatena.ne.jp/help#robot)

これによって何がわかるってわけでもないのですけれど (いやわかりますけど) 、いろいろと気になってしまう方は HTTP とかそういったものを勉強すると良いかもしれません。 UserAgent 名を偽装してプロクシサーバを経由すればある程度隠匿できますけれどって子供っぽいなあ……。まあそんな感じで。

そういえばアクセス解析がどうたらって記事をみたのですが (というかその記事を読んだのでこの記事を書いてるわけですが) 、 SSI でスクリプトを実行して解析してしまえば利用者には解析していることもわからないので、「アクセス解析されるのは気分が悪い」って方には優しい手段だと思った。

Last-Modified ヘッダを出す

記述年月日: 2004年02月29日

めもっていうか。

SSI と Last-Modified・Content-length ヘッダ

や、まだ読んでいないのであれなのですけれど、手間がかからないようでしたら出してみようかなと思っているわけです。どうもすみません。というか、自前の回線とコンピュータで公開しているわけではないので、過負荷目的ではないアクセスならばあまり気にせずにどうぞといった感じです。って取得方法を別個で指定というのは出来ないのかな。