HTML文書作成日記

明けたもよう

記述年月日

2004年01月01日

なんというか、何故に年が明けた程度のことを祝わなければならないのかがサッパリわからず。って、祝わなければならないわけではないのだけれど、何を祝しているのかがわからないのであります。そうすると、安易に「明けましておめでとう! 」などと言う気になれないのです、ひょっとしたら物凄くアレな意味が込められているかもしれないわけでして。んじゃあ言わなきゃいいって程度の話でした。

というか、めでたいのは年が明けたことそのものよりも、もっとこう……違うことに対して係っているような気がしてならない。たとえば別れの挨拶で「さようなら」などと言うことがあるわけですが、この「さようなら」というのは「さようならば以下略」などという雰囲気があるわけです。これと同じに「おめでとう」ということについて考えると、「 (略) おめでとう」と言っているような気がするのです。「無事に明けましておめでとう」みたいな。

相変わらず書いている人間でさえなんのこっちゃサッパリな日記でありますが、本年もよろしくお願いしてみるテスト。よろしくできる相手がいれば、ですが (寂しがり) 。というか面倒くさくなって放置というのが妥当な行く末のような……。

いつまでも　あると思うな　俺のやる気

従兄弟とかに会ってみた

記述年月日

2004年01月02日

お正月くらいしか公然と会う理由もないということもあり、従兄弟とかに会ってきました。

久しぶりに会った彼らと少し話してみると今年度に高校受験を控えている様子でした。んじゃあってんで、ちっとばかし教科書でも見せてもらったところ、ほとんどの科目で教科書に書かれている意味がわからなかったのです。あ、意味はわかったのだけれども、テスト問題として出されたら解けないだろうなあという感じ。

理屈に頼れるような科目は教科書をしばらく眺めていればすぐに理屈を思い出せたのですが、暗記に頼るような科目は全くわからなかったです。おかげで従兄弟に「＊＊君、こんなのもわかんないの? 笑」などとバカにされました。ただまあ、教科書的な知識に限らず、物事は絶えず続けるということがある程度大事だということを思い出しました。

崩れた生活のサイクルの改善法

記述年月日

2004年01月03日

お正月休みなどで生活のサイクルが崩れてしまうと、いざ会社や学校がはじまったときそれなりにキツいのです。そんなわけでして、崩れてしまった生活のサイクルの手っ取り早い改善方法なんてものを尋ねられてもいないのに書いてみます。夜遅くまで起きているケースの改善方法です。

1. 頑張ってその日の夕方近くまで起きておく (即ち、夕方に就寝する) 。
2. すると、多くの場合、深夜に目が覚める。
3. そのまま寝ずに、会社や学校に間に合うよう準備をする。
4. 行く。
5. 後、普段の就寝時間に寝るようにする。

僕はこの方法ですぐに生活のサイクルを元に戻せてしまうのです。前日に行うのが不安な方は数日前から試みると良いでしょう。おすすめはしませんが (今更) 。というか前日に早めに就寝するのが一番な気もしないでもないですね。しかし僕は、眠くもないのに早くに寝るというのがどうにもできないので、頑張って夕方まで起きておくなんてことをしたりするのです。

いろいろ大げさ。

映画は吹き替えよりも字幕がいい

記述年月日

2004年01月04日

年の瀬から新年早々というのは夜中に映画がたくさん放送されていて楽しいですね。この時期に限らなくても深夜に映画はたくさん放送されているようですが、いわゆるゴールデンタイムに放送されるような映画、 You've Got Mail (トム・ハンクスさんとかメグ・ライアンさんが出演しているやつ) が深夜に放送されていたのにビックリしたのでありました。

先日も夜遅くまで起きていたこともあり、放送されていた映画をみたのですがこれもまた楽しかったのです。ペイフォワードという映画です。概要は、ねずみ講的なものを良い方向に向けたもの (ひどい説明) なのでありますが、ラストがアメリカ映画に似つかわしくなく主人公の男の子が死んでしまうというもの。

アメリカ映画というのは、僕の偏見なのですが、良い人は死なないという不文律があるような気がして、というか良い人が死んでしまっては後味が悪くなるからなのでしょうけれども、まあ良い人が死なないわけです。アクション映画に限らず猟奇殺人をモチーフにした映画であっても、基本的には子供は死なない (殺されない)。しかし先に挙げたペイフォワードという映画では、特に死ぬ (製作者に殺される) 必要がなかったのにも関わらず主人公の男の子は殺されてしまった。そうすると観ている方は「アレ? これって実話を元に? 」などと勘ぐる余地がでてきてこの辺が心に残るのです。適当な感想ですが。

しかしまあ、実話をもとにした映画 (ペイフォワードは実話かどうかは知りませんが (たぶん違う) ) であっても、元にしたというだけであって必ずしも実話どおりにしなくてもいいような、などと思うことが良くあったり。などといっても元になったお話を知らなければそうは思えるはずもなく。まあいいか。

そういえば、実話を元にしたものとしては「歴史」も似たようなものだななどと、今ふと思いました。

さて本題の「字幕の方が好みだ」というのは、ただ単に僕はテレビを見ているときに限らず、普段からとりあえずパソコンで (映画に限ると、僕は別に挿入歌に興味が薄いので) 音楽を流しているからなのであります。なにより字幕であると「 (外がうるさくて) 言葉が聞き取れなかった」などということにならないので、字幕の方が好みなのであります。字幕だと今度は「読み終える前に字幕が消えた」などという事態にもなりかねませんが、それは自分が悪いし、とわりきれるのです。

映画の挿入歌というのは、 HTML 文書における製作者 CSS みたいなものですねというお話でした。そんな話をした覚えはない。

教授と教示

記述年月日

2004年01月05日

• Google 検索: ご教授
• Google 検索: ご教示

きょうじ　けう― 0 1 【教示】

（名）スル

1. 〔「きょうし」とも〕おしえしめすこと。示教。
   • 「御―を賜りたく」
2. 実験・調査で、研究者の意図する行動を被験者にとらせるための指示。

きょうじゅ　けう― 【教授】

（名）スル

1. • 児童・生徒に知識・技能を与え、そこからさらに知識への興味を呼び起こすこと。
   • 専門的な学問・技芸を教えること。
     • 「国文学を―する」
     • 「書道―」
2. 大学などの高等教育機関において、専門の学問・技能を教え、また自らは研究に従事する人の職名。助教授・講師の上位。

「教えてクレヨ! 」というのを丁寧に言うのであれば「ご教授ください (あるいは願います) 」ではなく「ご教示〜」と言うのが正しいと書かれている文書を目にしたのです。しかし辞書を引きその意味によくよく目をとおしてみると、教授を願うのも強ち間違えではないような気がしてきました。とはいうものの、「ご教授〜」とは一般的には誤用とされているのでしょうけれど。そして、教授を願っている方々の多くは、 (おそらく) 教示という言葉とこんがらがって使ってしまっているのだろうなとは思いました、これといった根拠もなく。

それと、おそらくは誤用してしまっているのでしょうけれど、その誤用された言葉の方が検索に多く引っ掛かるのがなんとも面白かったのです。まあ検索なんてものは言葉の使われ方までは考慮しないので、一概に検索に引っ掛かった文章全てが誤用されているもの、とは言い切れませんが。

忘れないうちに

記述年月日

2004年01月07日

見てのとおり (のような) サイトの構造というか基本的な部分を少々弄ってみました。これは先日書いた HTML 文書における ID 属性値の問題絡みで。それで少しばかりメモしておきたいことが出てきたのですが、今は時間がないのでまた後日改めまして。という予告。

今回のことに限らず、以前からいくつか書きたいことがあるのですが、僕はどうにも時間の使い方がヘタなようでして、上手い具合に時間を調整できず、書きたいことがどんどんと溜まってしまう。しかし時間が経つにつれだんだんとどうでも良くなってしまい、結局は書かずじまい。これはなんだか寂しいことに思えて仕方がないのです。だからテーマを失念してしまう前に、予告を。

というか、知識に乏しいくせにそういったことに対しアレコレと書き連ねたい僕は、まあ知識が乏しいということでして、書きたいことの大半はいろいろと調べながらでないと上手くまとめられないものばかりなので、書き上げる労を見積もるとそれだけで気が失せてしまうのです。そもそも僕は、思考の文章化は苦手な人間でありまして。まあいいか。

そうそう。見出しにアンカーを入れてみました。見出しにアンカーを加えるた文書というのは一見すると MT っぽいですね。しかし残念ながら当文書は記事毎に個別文書化されるような素敵なあれではないので、まあアレで。なんちゃってっていう。ただまあ、見出しにアンカーを入れることによって、記事の URI の取得はしやすくなったと思うので、これはこれで悪くないような気もします。

ついで。密かに頑張っていた連続更新記録は 5 でストップ。嗚呼。日付の詐称をしようとしたのは内緒ですよ。

まだだ……まだ終らんョ!

記述年月日

2004年01月09日

別に閉鎖もまだしませんし、移転もまだしません。公開するファイルを間違えてしまっただけです。誰も気にしちゃいないでしょうが 苦笑。とりあえず更新のための更新。空更新もあれなんで適当に CSS ファイルを作ってみました。おかしなところがあっても気にしない。

suitable.css

suitable.css 適用イメージ

ハンドメイドな日記で十分だと思った (強がり)

記述年月日

2004年01月09日

面倒なので参考になりそうな文献は下部で紹介。

大した知識も無いのでありますが、せっかく (それなりに) マーク付けという概念を理解できたということで、ここはひとつ XML＋XSLT とかでラクしてみようと思い立ちインタァネットを徘徊したのでありますが、今の僕の知識では扱いこなせるような代物ではないことがすぐにわかったので、方向を少し変え、 CGI の設置が不可なサーバでもラクが出来る日記ツールを導入してみようということになりました。そうするとツールを配布しているサイトを探さねばならないわけでありますが、そんな面倒なことはやってられないというわけで、既知の日記ツールである nDiary と tclog で遊んでみたのであります。

で、 tclog, nDiary を配布している両方のサイトを覗き (サイトの) マーク付けが気に入り、尚且つ生成されるページが HTML4.01 の規格に準拠していることが保証されるという tclog をまず導入しようということになりまして、必要なものをだうんろーどしいざ遊ぼうとするも、いじってもいじってもまともに起動も出来ずイライラしどおし。……しばらく頑張ったかいあって、なんとか動かすことに成功したわけでありますが、そうしたらビックリですよ奥さん。WWW 上の最近数回分のファイルが書き換えられてしまっているではありませんか (昨日あたり、最近数回分のファイルがカラッポになってしまっていたのはこのためです。カラッポなまましばらく放置というのも気が引けたので、更新しなきゃなあとこの文章を書いていたりするわけです。ってゆーか、未だに tclog の使い方がわからない) 。で、「もういいや」となったのでした。

そんなわけでして、今度は nDiary を導入しようとするも、またこれも使い方がよくわからない。いや、わからないというよりも、僕の環境が特殊 (なのかな? ruby と nDiary のインストール先がそれぞれ違うだけなのですが、ドライブ単位で) なせいか、ディレクトリの指定が上手く行かずロクに動かすことができなかったのでした。でも、そういった環境でなければ、簡単に導入できます。

この日記では、いわゆる過去ログと最新分を同時に更新しているのでありますが、最近は慣れてしまったとはいえ解消できるのであれば解消したい問題だと思っているのは間違いなく、そうであればツールに頼るのが当然とまで思っていたのです。しかし、その心持ちとツールを使いこなす上で必要になるであろう知識や技術を得る方手間とを比較すると、ツールを使いこなす技術や知識の会得の方が (当社比で) 何倍も苦労することがわかり、「もういいや」みたいな雰囲気になってしまったのでした。

前述の 2 つのツールでは任意の文字列を適当なタグに変換したり、カテゴリ分けなんかを出来たり、別途ファイルに同一の内容の文章を吐き出させるわけなのですが、この作業はさすがに 2 年近くも日記を書いている人間 (というか僕限定だと思うけど) とってはあまり苦ではないような……などと思っていることも事実なのであります。ツールの導入があまりにも難しく感じられたのもまた事実。なにより、上に書いた 2 つのツールでは僕の需要は満たせていなかったのです。使えていなかったけれど。

僕が求めているものは、簡単にいうなれば、文字列の置換は全く必要なく、最新分のファイルに吐き出す文章は n 日分と判断するのではなく、n 回分として判断し吐き出してほしいのです。あるいは、入力した文章を指定したファイルの新しいものが上にくるように吐き出してほしい。これはまあ、書いたらすぐに公開しないような製作者しか使わないようなアレでありますが、まあこんな感じなのです ( nDiary でも出来そうですが) 。しかしまあ、 tclog も使いこなせなかったし、 nDiary も使いこなせなかったので残念というかなんというか。無知な人間には向いていないなあというか。

こんなことを書いていていたらなんだか腹が立ってきたので、今度はローカルで MT を使って遊んでみよう! なんて無謀なことを思い立ち即実行したのですが、これもまた悲惨な結果に。「出来ませんでした」というオチなのですが。

MT を使うには DB を使える環境を整える必要があり、そしてDBアクセス用のパッケージをインストールする必要があるらしいのですが、このパッケージのインストールがどうにも上手く行かなかったのでした (さすがに Perl はインストールされています) 。MySQL はインストール出来たのですがというか、あんなのサルでも出来るっぽいし。で、不貞腐れってわけでした。ちなみにパッケージをイントールしようとすると以下のようなエラーがでます。

• Failed to load PPM_DAT file

  Can't use an undefined value as a SCALAR reference at C:/Perl/site/lib/PPM.pm line1678, <DATA> line 40.

まあなんかダメなんだなとは窺えるのですが、どうにも無知甚だしく何がダメっぽいのか、そしてどうすればそれが解消されるのかがわからないのであります。 Perl のばーじょんは 5.6.1 build 635 だと思われます。もういい加減いやになってくる。っていうか、ローカルで MT が使えなくてもいいもんねー、ローカルで HTML-lint が動けばいいもんねーという勢い。

そんな感じ。そもそも僕は多機能なテキストエディタですら使いこなせない人間だったのだ。自分……不器用ですから!! (高倉健) みたいな。死ぬ。

参考に (というか個人的なメモ)

nDiary

nDiary導入用覚え書き

nDiaryUserWiki

tclog - a weblog application in Tcl/Tk

Windowsで Movable Typeを動かす

Movable Type 日本語化手順

MySQLのインストール/動作確認手順

ところで最近 Blog ツールを使用しているサイトが増えてきましたね (というのはつまり、僕がよく見ているサイトも導入しはじめたというわけです) 。カレンダーだなんだと閲覧者側に立ったとしても僕にはサッパリ必要のないものばかりで鬱陶しいなあなどと思っていたのですが、しかしマーク付けがある程度きちんとされているので結果的にはプラスになってる感じがしますね。糞厨房がなに言ってンだって感じがしないでもないですが。あと、日記ツールの導入日記を書くと長くなることがわかった。どこかの日記でも長くなっていたし (わからない人はわからなくていいです。もう嫌だ) 。

まとめと余談

• tclog や nDiary などはサーバ側の制限で CGI などの設置が不可なケースであっても、面倒な手作業をスクリプトが代替してくれるので、いろいろと複雑なことをやりたい方にはオススメなような気がします。

• MT などは HTML がわからない方であってもそれなりにきちんとしたマーク付けを施してくれるので、サイト製作者のみならずサイト利用者にも恩恵があるような。はてなダイアリーも然りです。

  ただ、 (これは主にはてなダイアリーで日記をつけている方にいえるのですが) CSS によって段組を表現したとしても、それはあくまでも表示上の結果であるので、日記の横 (?) に表示させているもの (主にアンテナ) は最新の日記よりも下に設置してほしかったりします。

  というのは、利用者側の回線の状況や、サーバの状況によっては思うように読み込みがされないことがあり、そうした場合でも、アンテナ等を最新の日記よりも下部に設置することによって利用者が欲するところである最新の日記を読むことが可能になる場合があるからです。

• ハンドメイドな日記で十分だと思った (強がり)

コメントアウトを表示させるブックマークレット

記述年月日

2004年01月09日

自分用メモというか。何を今更という感じがしないでもないけれど。

31 ：水先案名無い人 ：03/12/07 03:39 ID:5LiF5H3g

省略

• コメント（<!-- -->）を表示

  JavaScript:document.body.innerHTML=document.body.innerHTML.split('<!--').join('&lt;!--');focus();

ブックマークレットについては、興味がある方はご自身で調べてください。綴りは「 Bookmarklets 」となるようです。

で、スクリプトもまともにかけない僕なのですが、とりあえずということでブックマークレットの作り方をどこかから学んでこようと思ったのですが、これが僕が探した限りでは見つからなかったのです。あ、これじゃ語弊があるな。つまりですね、ブックマークレットというのはインターネットショートカットの URL 欄に適用したいスクリプトを記述し、実行させていると言えるのです。で、僕が知りたかったのはカラッポのインターネットショートカット単体の作成方法だったのですが、調べても見つかりませんでしたというあれです。

もう少し補足。インターネットショートカットというのは単に拡張子を url にすればよいような気もするのですが、ただ単に拡張子を url にするだけでは、URL 欄にスクリプトを記述することが出来ないのです。記述させることが出来ないというよりも入力欄が現れず、なのですが。とにかくそうなのでした。僕のコンピュータでは。ただ、インターネットショートカットが簡単に作成できるツールはありましたので、興味のある方は探してみると良いでしょう。

なんていうか、出来ませんでしたわかりませんでしたばっかりだな、この日記は。

TTT Editor を使った感想

記述年月日

2004年01月11日

メモ帳の機能に特に不満があるわけではないけれど、以前に「メモ帳よりはずいぶんと便利だ」と教えていただいたことがあったので、使いこなせるかとの不安はあったものの、物は試しとばかりにTTT Editorなる HTML エディタを使ってみることにしました。以下に気づいたこと (主に利点) を列挙してみます。読む上での諸注意は下部に書いていますので、先に目をとおすのも良いかもしれません。

では以下列挙。

テンプレートを作成できる

日記などを HTML でマーク付けする場合、多くの方がある程度の自分なりの規則 (div やら見出しのレベルやら) があると思います。そうした場合、あらかじめテンプレートを作成しておくことにより、面倒なテンプレートを一発で吐き出すことが可能です。

日付の挿入も可能

日記などでは日付を挿入される方も多いでしょう。そうした場合でも、日付を吐き出すショートカットを自分の使いやすいものに割り振っていると、いちいちと年・月・日などという文字を打ち出さなくて済むようになります。ボタン一発で! というわけですね。

そしてこの日付の挿入機能もある程度カスタマイズできますので、たとえば「西暦/月/日」というような形で吐き出させることも可能ですし、当日記のように「 200*年**月**日」というような形で吐き出させることも可能です。更には、西暦からではなく、単純に月日 (つまり mmdd という形) で吐き出させることもまた可能なのです。同じように時刻を吐き出させることも出来ます。

外部ツールの起動もできる

日記を書き上げたら FTP ツールを立ち上げて……というのが面倒な方は、常用している FTP ツールを外部ツールとして登録をしておくと便利です。これもまたショートカットキーを自身が使いやすいよう割り振っていると、手間がかからず大変使いやすいです。

特殊な文字も一発で表示できる

これはほかの方にはあまり関係ないことかもしれませんが、 HTML ソースなどを文字として表示させたい場合、&lt;や&gt;などを打ち込む必要があるのですが、これらもショートカットを割り振っているとボタンひとつ (あるいはふたつみっつ) で簡単に入力することが出来ます。

と、こんな感じなのですが、こんな文章を読むよりか、ラクしてみたいと思った方はさっさと作者さんのサイトへ足を運んでみると良いだろうなと思いました。

TTT Editor を使った感想を読む上での注意

• さっき使ってみて、今その感想を書いています。
• 小林自身は、 HTML エディタは TTT Editor 以外には使ったことはないので、他のエディタとの比較をしているというわけではないです。単純に使った感想ということです。
• 属性や属性値の色分けなどもあるようなのですが、それらに僕は興味がなかった (メモ帳の影響) のでその辺りについては、きれいサッパリ抜けています。
• タグの自動挿入なる機能もあるのですが、僕は簡単にタグが挿入できるという機能にはほとんど興味がないので、その辺りにつても、きれいサッパリ抜けています。
• 現時点でのTTT Editor のスクリーンショットなども。記念撮影。

高機能なエディタを探す

記述年月日

2004年01月11日

高機能なエディタを使っているとなんだかカッコ良さげだったので、 TTT Editor 以外にも何かないかと思い、少しばかり探してみました。で、結論から言ってしまえば、より高機能なものは僕には使いこなせそうもなかったこともあり、 TTT Editor で十分という感じなのですが、それだけではあんまりなので使いこなせれば大変便利そうだと感じたものをご紹介 (ではないなあ……。個人的なメモという感じです) 。

• なまらやる気のないぺぇじ
• 窓の杜 - xyzzy
• xyzzyページ
• xyzzy日記
• Google 検索: xyzzy

あと、あまり関係もなく使ったこともないものを紹介するのもあれなのですが、 Macintosh だとmiというテキストエディタが便利だということを聞いたことあります。更に関係ない話なのですが、 Google には電卓機能があるのですね。Google 検索: miを参照してみてはじめて気付きました。

記述年月日について

記述年月日

2004年01月11日

何度かこっそりと突っ込まれたことがあったので、今更とはいえ、誤解の無いように断っておきますと、見出し直下にある記述年月日というのは読んで字の如く記述した日であって、公開した年月日ではありません。したがいまして、「○月×日にアクセスしたが、その日には△△な文章なんてなかった」などと言われましても、僕としては「そりゃそうですよね、アップしてないませんでしたし」という感じに……。

書いたらその場でアップしてしまえば記述年月日と公開年月日が合致するので、誤解することもなく、また誤解されることもないのですが、アップロードが面倒くさく思えてしまうこともあって、そうしますと公開した年月日と記述した年月日がズレてしまいまして、結果、騙すということになってしまうのです。「んじゃあ、公開するときに年月日を添えればいい」と思われるでしょうが、僕は書き溜めることがよくあるので、いちいち溜めておいた文章に改めて年月日を添えるのは面倒くさく……。それから、書いた日と公開した日、どちらを残しておきたいかと比較した場合、僕は書いた日を残しておきたいというのもあったりなかったり。

以上のことをわかりやすいよう換言してみると、夏休みの宿題によくあった日記を休み明けに先生に提出するときだって年月日は書いた日じゃないですか! それと同じだよ! という感じで (というのは苦しい言い訳) 。いちおう僕が書いているのも日記ですし (最早泥沼……) 。

絶えつつ続けることは可能なのか

記述年月日

2004年01月11日

以前に絶えず続けるなんて言ってしまったのだけれども、果たしてこの語句は正しいのかどうかが気になるところであります。というわけで、頼みの綱の goo 辞書から引いてます。

つづ・ける 0 【続ける】

（動カ下一）[文]カ下二 つづ・く

1. 同じ状態や行為が終わりにならないようにする。
   • 「交際を―・ける」
   • 「研究を―・ける」
   • 「旅を―・ける」
   • 「ひまをみては編み物を―・ける」
2. 物事を間をおかずに繰り返して行う。
   • 「映画を―・けて二本見る」
3. 間を置かないで次の物事につなぐ。
   • 「部屋を二間―・ける」
   • 「授賞式に―・けて祝賀会を行う」
4. 付き従える。
   • 「御輿のしりに―・けたる/枕草子 278」

〔「続く」に対する他動詞〕

間をおかずに繰り返して行うのが「続ける」という言葉の意味 (のひとつ) であるのならば、間を置いてしまっては (絶えてしまっては) 続けるという事にはならない。そこから鑑みると、「続ける」という言葉の意味に「絶えなく」という意味も含まれているわけですから、絶えず続けるなる言葉は些か意味が重複してしまっている感があるような。

いやはや日本語は難しいですねというお話でした。

面倒くささを解消するために面倒くさいことはしたくない

記述年月日

2004年01月11日

普段からよく読んでいるサイトを眺めていたら、 TTT Editor の他にも (当たり前とはいえ) 高機能な HTML エディタがあることを知りました。

• ez-HTML : HTMLの編集に…
• Kaneto’s HP - HTML Project2

このふたつはまだ試してはいないのですけれどというか、ソフトの概説にチラっと目をとおそうとした途端あまりに膨大 (僕からすると多いんです) な量があることに気付き、ちょっと目をとおしただけで敢え無く断念。ただまあ、僕のような面倒くさがりの人はそうはいないとは思いますし、他の人がオススメと言っていたのは間違いないので、常用しているエディタに不満があって高機能なエディタに乗換えたいと強く望んでいる方にはオススメかもしれません。ポイントは今使用しているエディタより高機能なものに乗換えたいと強く望んでいるかどうか、です。

そもそも僕が高機能なエディタを導入しようとしている動機は「面倒くさいからラクをしたい」というものであって、しかもその面倒くさく感じているところがエディタでは解消されるわけもなく、とすると常用しているエディタから他の高機能なエディタに替える必要性も薄れてしまうというか。面倒くさがりを自称していたところではありますが、その面倒くささを解消するのも面倒くさいというわりとどうしようもない理由が……。日記なんて面倒なものをつけているくせに、そこには面倒をあまり感じず、機能を知るということに面倒くさく感じてしまうから、ホントどうしようもない。

もし最初に TTT Editor を選ばなかったとしたならばおそらくは、先に挙げた 2 つのうちどちらかを使っていたのでしょうけれど、既に TTT Editor を導入してしまったから更に動機が薄くなる (まあ動機は大きくズレているわけですが) 。しかし、どれもこれも OS 付属のエディタよりかは高機能 (多機能) でありますし、使いこなす手間さえ乗り越えられればラクが出来るようになりかもしれません。僕は比較検討してまで選り好みできるような人間ではなかったのだ。

高機能なエディタといえば秀丸も

記述年月日

2004年01月13日

• 秀まるおのホームページ−ソフトウェア−秀丸エディタ

そんなわけでして、秀丸も高機能として有名 (のような気がする) だったりするわけで、かなり前に僕も使用をしてみたのですが、起動のたびに「レジストしました? 」と尋ねられそれがひどく煩わしく思えてしまい、使用しつづけるのを止めてしまったのでした。ユーザ登録はせずとも使いつづけられるようなのですが。しかし僕はそういったものにお金を払いたくない人間でありまして、邪魔くさいなあなどと思ってしまったのです (罰当たり) 。

そもそもとして秀丸 (に限った話ではないのですが。たとえば xyzzy も該当します) のような高機能なエディタの素晴らしさに気付けなかったというのもあるような。今でもマクロって何? 喰えんの? って知識レベルです。ちなみに秀丸は鳩丸よもやま話 : Another HTML-lint 導入ガイドによると、ゲートウェイを経由せずに文法チェックをさせることも可能。

常識は常識

記述年月日

2004年01月13日

「自分の中の常識が世間では非常識にあたるかもしれないなんて常識だよね」

という俺常識。

愚痴はうざいよ

記述年月日

2004年01月13日

「愚痴られるのってうざいよね。この前なんてさ〜…」

という愚痴。

俺の方が不幸

記述年月日

2004年01月13日

「不幸自慢をしているやつの大半は俺より幸せ」

という以下略。

TTT Editor を利用する際の問題点

記述年月日

2004年01月14日

問題点という程でもないというか、ズレた話になってしまうのですが。

日記やらなにやらを書くのに TTT Editor を使ってみて、ある程度エディタの雰囲気に慣れてきたので、今度は HTML 文書やらのソースを表示する際にもこの TTT Editor を使用することにしたのです。今まではメモ帳を主に使用していたこともあり、文字コードの問題でもってソース (というか主に日本語部分) の読解が困難であったケースに遭遇し、その都度イライラとさせられてしまっていたのですが、エディタを乗換えたので先述した問題に遭遇することが減ったのです。嬉しい限りです (わりと) 。

……と喜んでいた矢先、問題が。 (大げさです。注意してください。ここで言う注意とは忠告やらの方面の意味ではないです。)

最近では MT なるツールを導入しているサイトなどを閲覧して回ることが増えてきたのですが、それが原因だったのです。MT が吐き出す文字コードは UTF-8 か EUC-JP どちらにするか決められるようなのですが、文字コードを UTF-8 と択一されてしまうと、ソースを読むためには UTF-8 を読解できるエディタでなければだめだったのです。しかし TTT Editor はあくまでも文書作成のためのツールであるので (という理由なのかはわかりませんが) 、 UTF-8 なんて文字コードは読解できるわけがなかったのです。残念。という問題。なんだかすごいレアケース……かもしれない。というか EUC-JP じゃダメなのでしょうか。 (根本的な理由がわからないのでありました)

余談というかちょっとした疑問。ブログといったら「引用→コメント」というパターンをすぐに連想できてしまうことから考えるに、実際に頻繁に行われているのでしょう。で、引用を頻繁に行っている方々は、相手文書の吐き出している文字コードが手持ちのエディタで読解が出来なかったらどうしているのだろう? などと。ぱっと思いつくところでは、ブラウザにレンダリングされた文字列をコピーして……というのが考えられるのですが、これだとマーク付けされた語句を取りこぼす可能性があるような。似たような問題で、はてなダイアリーからの引用もあったり。はてなダイアリーはどういったわけか、ある特定の語句に対し自動で説明文へのリンクを用意してくれるのですが、このアンカーの扱いも引用する方からするとまた微妙だったり。

さらにブログの余談。コメントを与える記事を参照リンクのみ (つまり引用をしない) で済ませ、閲覧者にはその参照リンクをされた記事を読んだものと前程 (想定) をされてしまうと、参照元の文書やらが失われたときに記事が成立しないので、リンクひとつで済ませてしまうのはあまり好きではなかったり。ただ、参照する側もされる側も長続きはしないような気もするので、記事の意味がわからないなどというケースはあまり発生しないかもしれませんけれども。でもあとから自分で読み返したときにも支障がでるかもしれないので、コメントを添えるのならば引用してしまう方がいいと思うのでした。ついでにもうひとつゴチャゴチャいうと、<a href="http://foo.com/">http://foo.com/</a>というリンクの仕方も好きではなかったり。Ctrl + v がラクなのはわかるのですが。んー。

などなど考えてみたものの、考えれば考えるほど「もうどうでもよくね? 」という短絡的な結論が出てきてしまうこの頃です。話もズレすぎましたし。ところで、遠めから「問題」という語句を眺めると、目立ちますね。

読まれない仕様書

記述年月日

2004年01月15日

備忘録2004年1月／趣味のWebデザインを読みまして。

とはいうものの、正規のヘルプや仕様は、いつもいつもなぜか読まれない。すると「読まれないような解説を書くやつが悪い」という意見がすぐに出てくるのですが、それは間違いです。HTML の仕様書がそうであるように、MT の仕様書もよくできています。わかる人には、これほどわかりやすい解説はないといってもいいくらいです。MT も HTML も一貫した流れに沿って設計されています。正規の解説には、その事実がよく現れています。

実際に「読まれないような解説を書くやつが悪い」とまでぶっ飛んだことを仰る方がいるのかはさて置き、仕様書はわかる人にしかよくわからない代物なので多くの利用者は仕様書を読まない。で、わかる人にしかわからない仕様書というのがわからない人にとって問題になるわけですね。

たとえば、MT や HTML の仕様について予備知識が無い方が仕様書を読んだところで、誤解せずにしっかりと使い方を理解出来るかというと疑問。家電の取扱説明書でもなんでもそうなのですが、説明を苦労せずに理解するためにはある程度の予備知識が必要になってくる。家電は日常生活でよく触れているので何となく使い方がわかりそれが予備知識となる。しかし HTML やら MT やらは身近な存在とは言いがたい。すなわち、予備知識に乏しい。そうするとたとえ仕様書にきちんと目をとおしたのにも関わらず、使い方がさっぱりわからないという方が出てくる。

で、HTML や MT の予備知識を得るのかというと、これはよくある「楽しげな解説」からなのでしょう、多くの方は。そこである程度の (そして誤解含みの) 下地を作り、更に興味が出てきた人はきちんとした解説に辿り着き、誤解を誤解と認識できるようになり、正しい使い方を学ぶ。やりたいことだけに着目し、囚われてしまった方々は誤解したまま使いつづける。

一見、正しい使い方を知ることが出来た方の方が幸せのように見られるのですが、誤解を誤解と認識できない人の方が実は幸せなのかもしれませんね、というお話。ルールというのはいつも厳しく、そして窮屈なものです。

追記。仕様書と取扱説明書は用途が違うような……。そうするとそれらを比べ合わせるのにも無理があって予備知識のあれもなあ……ごにょごにょ。などと自分で突っ込む (←なんだか卑猥) 。

del 要素の表示・非表示

記述年月日

2004年01月18日

端的に聞いてしまうと、del 要素としてマーク付けされた文字列を CSS によって非表示にしたとしても、文章として意味がとおるものにした方が良いのでしょうか? ということなのです。適当な例文が思い浮かばなかったので、例文その他をいろいろ丸投げ。

• ほげほげはぴよぴよである。
• ほげほげは<del>ぴよぴよ</del><ins>ふがふが</ins>である。
• ほげほげはふがふがである。
• ほげほげは<del>ぴよぴよ</del><ins>ではなく、ふがふが</ins>である。
• ほげほげはではなく、ふがふがである。

ユーザエージェントは、変更点を明確にするような方法で、挿入されたテキストあるいは削除されたテキストをレンダリングする必要がある。例えば、挿入されたテキストを特別なフォントで表してもよいし、削除されたテキストを全く見えないようにしたり、取消し線や特別な印をつける等して表してよい。

削除されたテキストを全く見えないようにしたりしても良いようなので、そうすると、del 要素を非表示として表示する (ってのもヘンですが) のも正当な挙動であるとも読み取れるわけですから、 del 要素を非表示にしても意味がとおるようにした方が良いみたいでした。わりと解決。以上マッチポンプ風味な日記でした。調べながら書くとダメですね。結論を持って書かないと。

ところで blockquote タグには base 属性 (とその値) のようなものも添えられると便利だよなあなどと思いました。あるいは、要素内のアンカーは cite 属性値からあれしてくれると。って、何か見落としていたりカン違いをしていたり……? あと丸投げした例文はひどい。

ドキ☆パッチだらけの云々サーバ (ポロリはどうなんでしょうか)

記述年月日

2004年01月18日

• Apache Maniax / 初心者編 / httpd.conf

Apache は初心者には敷居が高いということをよく見聞きしていたので、今までは AN HTTPD というソフトで遊んでいたのですが、ためしに Apache で遊んでみたところ、 AN HTTPD よりもずっと取っ付き易い印象を受けたのでした。とはいうものの、実際のところは AN HTTPD でいろいろなことに慣れたというあれがあるのかもしれませんけれど、とにかく Apache の方がラクな印象。

安心していると素っ破抜かれる

記述年月日

2004年01月25日

見出しで既に言いたいことを言い終えてしまいましたので、といっても何のことかサッパリだと思う方がほとんどでしょうけれども、とにかく安心していると素っ破抜かれるのです。というメモ。以下は関係ない話。

今年に入ってからは、日記の見出しをきちんとしたものにしようと心掛けているのですが、ふざけた見出しばかりを添えていた人間がいざやろうとするとなかなか苦労します。きちんとした見出しというのは人によりけりで、人によっては記事のテーマだったり記事の要約だったり、記事の結論だったりでしょうけれど。ちなみにテーマを見出しにする際は、記事を書く前に見出しを決めることができ、要約を見出しにする際は、書き上げた後に煩悶する羽目に。「もういいや」となると笑いに走った適当な見出しになる寸法。これはことあるごとに滑ってしまうのが難点であります。

ついでにもうひとつ関係の無い話。この日記は週末に更新されなかったらおそらく翌週まで更新されません。という知って得はしないけれど、何故かお得な情報です。一日 6 回程度しかアクセスされない日記サイトがなにを言うかという感じもしますけれど (厳密に言うとアクセス数というか、ログ取得用の画像が読み込まれた回数が 6 回とかその程度ということです) 。しかしこの日記は更新の有無に関わらず、アクセス数があまり変わらないようなのですが何故なのでしょうか。って、巡回先は更新の有無に関わらず巡回するという方が多いのだろうと予測をしているわけなのですが、明確な理由がわからないのはなんとも気持ちの悪い次第であります。

そういえば、以前に僕は、更新の度に足を運ぶのは非効率的な感じがしたので「月に一度程度覗いていただければ〜」というようなことを書いたのですが、これって考えてみたら、更新されるから足を運ぶ人に対してはあまり意味が無かったような気がしました。ではどうするか。更新作業は月に一度行えばよい、という結論に。だからといって、実行するか否かはまた別であります。

ちなみに、書いてすぐにアップロードしないのは、更新用と保存用の両方に同一内容の文章を作成するのが面倒だからであります (じゃあ、しなければいいってわけですが) 。で、その解決方法のひとつとして、アップロード作業を週に一度程度に抑えるようにしたわけです。こうすることによりコピーアンドペーストの作業が……ってわざわざと説明をするまでもなく、手間の削減はご理解いただけますでしょうから、省略。作成者と利用者の利害も結構一致するので、ハンドメイドで頑張っている人にオススメ。

ああそうだ、って連想ゲームをしているわけではないのですが、アクセス数の話ついでにひとつ。いわゆるアクセス数というのは、本文部分に自身の管轄以外のリソースへのリンクの多さにある程度比例するような気がします。比例の比率は内容によるような。情報発信系 (?) サイトが強いのはこの辺が理由のような。なんてことを考えたのですが、根拠はかなり薄弱です。と、こういったことを考える度に、アクセス解析をして、きちんと統計をとっておけばなあと思うのです。まあ、きちんと統計を取っていたとしても、なにぶん規模が小さすぎるので信用性の薄いデータなのですけれど。

あと書きすぎた。疲れたはずだ。

時には素養が邪魔になる

記述年月日

2004年01月25日

実際のところがどうなのかはわからないのですが、高校時代の恩師が「新卒はたとえ職歴があったとしても、その職歴は書かない方が採用されやすい」ということを言っていました。これはつまり、無駄な素養があると会社のルールに沿わない、あるいは以前の職場で得た知識でもって行動してしまう場合があるからだそうです。採用する方からすれば、自社の社員はきちんと自社色に染めたいのだそうです、とまでは言っていませんでしたが、まあそういうことなのだろうと思います。

ひょっとしたら前述のものはひとつの例え話であって、実のところは「わかった気」になっている方のカン違いを修正するのは難しいということ恩師は言いたかったのかもしれません。新しい概念に直面したとき、何かを知っている人よりも、何も知らない人の方が吸収率が高い場合があるのはこのためなのかもなどとときどき思うようになりました。

マークアップ言語だから誤解が広まったわけではない

記述年月日

2004年01月26日

今、感想を書き留めることに深い意味はないということと、見出しで言い切ってしまうのはごにょごにょだなあという点にお断りを……。

私も、疲れてくると「HTML はスタイル指定言語でもよかったんじゃないか」と思う。ブラウザの歴史がテキストブラウザから始まっている以上、それはありえない話なのだけれども……。ほとんどの人にとって、「スタイル指定に使えないなら HTML なんて意味ないじゃん」であるわけで、結局どうにもこうにもこのバカの壁を突破できない。一瞬は理解してもらえるのだけれど、持続しない。困った話である。

一般的な公開手段のひとつになっている HTML がたとえスタイル指定言語であったとしても、おそらくは現状と同じように、文法を守る人は (たぶん) 少数派になるだろうと思います。

結局のところほーむぺーじ製作者の多くは「 (文法なんてどうでもよくて) 見れりゃーいいよ」と考えている人が多く、また、 HTML がスタイル指定言語であったとしても、現状と同じようにブラウザの方に強力なエラー補正機能が施され (つまりマークアップ言語だから強力なエラー補正機能が施されているわけではないような) 、律儀に記法なぞ守らなくともそれっぽく表示されてしまい、結果、記法を重要視しない人が出てくる。窮屈なルールを守らなくてもそれっぽく表示されるのならば、人によってはそれを守る必要のないものだと感じてしまう人もいるでしょう。

そして、ルールをきちんと勉強していないあるいはルールを知らない人の (「裏技」を駆使した) 怪しい楽しげなほーむぺーじ作成講座のようなものが横行し、書籍もまあ似たようなものが増え、そうするとやっぱり騙される人が増えつづけ、きちんとした記法の存在に気付いている人々は少数に留まり、現状と同じように啓発に疲れてくる人が出てくるだろうと予測。

という説明 (というか半分は妄想でしたが) での「マークアップ言語だから誤解が広まったわけではない」という結論は強引かもしれませんけれど、結論は変わらず。つまり、製作者がこう使え、という通りに使う利用者ばかりではないという感じですね (僕の言葉じゃないですが) 。

で、つらつらと考えるうちに、一番のガンはルールなんて守らなくてもそれなりに表示してしまうブラウザのエラー補正機能のような気もしたのですが、でもこれのおかげで本来ならば参照できるはずのない (?) 文書もきちんと参照できているから困った話。逆にエラー補正機能がなければみんなきちんとルールを学ぶような気もしたのですが、ルールに厳しいブラウザは使用するうえでデメリットが目立ってしまい、使用されないから意味がない。そうすると抜本的な解決策は……?

「信者」の線引き

記述年月日

2004年01月29日

CSSとか弄ってみたくなったので近々リニューアルします。テキストサイトっぽくなる予定。本当はそんなことしてる暇ないのですが。テスト前になると必ず部屋の掃除をしたくなっていたあの頃から全く成長していません。

閲覧者という味方・敵。けっこう思い当たる点があります。私の場合は、cssベースのデザインにするとバイト先の偉い人（NN4ユーザ）から圧力がかかり、テーブルレイアウトにするとW3C信者の読者から苦情が来る、という板挟み状態に陥ってました。ユーザビリティの限界を分かってないと、矛盾が膨らんでいってモチベーションごと破裂してしまいそう。

実際に試しわけではないのであれなのですが、苦情を減らす手段 (文章の公開手段) としてはプレーンテキストで文章を公開というのもひとつの手のように思いました。これならまあ、窮屈なルールだとか信者からの苦情からも解放されるような気がします。で、プレーンテキストで公開しているのにも関わらず、「 HTML を使え! 」などといわれたら、それこそW3C信者の読者から苦情のように思えます。ここまでくると苦情ではなくなってしまいますが。僕の中の信者の線引きというのはこの辺。というか、信者という言葉に反応してしまっている時点で、そうではない人から見ると十分信者なのだろうななどと思いました。

はてなダイアリー用 CSS (第1版)

記述年月日

2004年01月29日

• はてなダイアリー用 CSS

はてなダイアリー用というか Win版IE を使用する際に適用させている CSS ファイルで、ついでに言うとはてなダイアリーを読む人用。しかも本文にしか興味がない人用。というか、僕自身はてなダイアリーはひとつふたつしか見ていないので、あれかもしれませんけれど。でもこういうときに、巡回範囲が狭いとラクだなあなどと思ったりもします。あと、はてなダイアリーだと文書構造が概ね共通しているのでその点でもラクなような。

それはさて置き、はてなダイアリーは使用してはいないのですが、外部 CSS ファイルの適用ができたら便利かもなあなどと思ったのでした。ちなみに、かなり前に一度はてなダイアリーを使用したことがあったのですが、これらの装飾を施す際にはひと月分程度の日記をローカルに保存し、そしてあれやこれやと装飾を施すと比較的ラクなような気がしました、オンラインで頑張るよりは。

っていうか、僕ははてなダイアリーを使っていないのにギャーギャーと騒ぎすぎなような気も……。「楽しそう! 僕も混ぜて! 」オーラが出まくり。で、はてなに限らず、誘われたら断るタイプ。それ以前に誘われないのでありました。クスン。

「CSS関係者に37の質問への回答」つまみ食い

記述年月日

2004年01月29日

よく見かける「〜に○○の質問」というものへのつまみ食い回答遊び。今回は第 1 回。 100 回回答したら終り。

CSS 云々だから答えてみたというわけではないですが。あと出典が消失してしまっているようなので Google 検索からあれして。

• Google 検索: "StrictなHTMLが、いわゆる『不思議マークアップ』のHTMLを（数などで）圧倒する日は来ると思いますか?"

StrictなHTMLが、いわゆる『不思議マークアップ』のHTMLを（数などで）圧倒する日は来ると思いますか?

Strict な HTML を心掛けている方の多くは、リソースの削除を良しとしないと考える傾向があるような気がします。で、いわゆる『不思議マークアップ』で頑張っている方の多くはすぐにほーむぺーじに飽きてしまい、「閉鎖します」というメッセージとともに自身が作成した文書などもバッサリと削除してしまう傾向があるように見受けられます (というか、こっちが主流 (?) のような) 。更に今後は、企業なども無視できないほどの実益という点からも Strict な マーク付けに注目が集められるような。

これらから鑑みると、 (どこを最終とするかにもよりますが) 最終的には Strict な HTML が増え、数に注目しても圧倒とまでは行かないまでも、これからは増えつづけるように思われます。というか前述のように Strict なマーク付けが成されている文書はあまり減らなく、不思議マークアップ文書は増えてもすぐに減るわけですから、ものすごく長い目で見ると比率は反転するような。

なわけないか……。

「考える若者に１００の質問」つまみ食い

記述年月日

2004年01月29日

よく見かける「〜に○○の質問」というものへのつまみ食い回答遊び。今回は第 2 回。 100 回回答したら終り。

若者じゃないのに答えようとしちゃってすみません。しかもつまみ食いで。

• 考える若者に１００の質問

ドラえもんの道具をひとつだけgetできるとしたら何がいいですか？　理由も。

ドラえもんの道具自体どのようなものがあるかよく分からないのですが、タケコプターが一般的なような気がするのでタケコプターがほしいです。値段にもよりますが、市販されていたらおそらく購入します。以下の問題点が改善されていたらですが。

どこで見聞きしたのかは忘れてしまったのですが、もし実際にタケコプターのようなもの、つまり頭にプロペラを乗っけてそのプロペラの力で飛ぶというものですが、それが実際にあったとしても、頭の皮がその力に耐えることができず、頭の皮が千切れるというようなことを何方かが仰っていたのを思い出しました。一見楽しそうなタケコプターも、出力設定を誤ると大変危ない。

質問の答えは以上です。

余談。質問を作成した結果、質問の数が 100 になったわけじゃなくて、 100 の質問を一生懸命考え作ったのだろうなあと感じました。それから、「考える若者に１００の質問」に対してのみというわけではないのですが、個人的に「○○の質問」というようなものは何故その質問を作成したのか気になるので、その辺を知りたかったりもします。「考える若者に１００の質問」ですと、ドラえもんの道具でほしいものと考える若者との繋がりが気になるというわけです。

ああそうだ、タケコプターがほしい理由を書くのを忘れていました。理由は空を自由に飛びたいからです。

「リアルタケコプターは頭の皮が千切れるぞ」ということを言いたかったらしいです、僕は。

インターネット利用者数とウェブサイトの開設・運用状況

記述年月日

2004年01月29日

なんとなくめも。それぞれ別個のデータですが。

個人ウェブサイトの開設・運用状況（N=1969）

1. 現在、開設運営している　14.1%
2. 現在、開設しているが、休止中である　6.2%
3. 今は開設していないが、今後開設する予定である　20.2%
4. 現在、開設していないが、以前は開設していた　4.6%
5. 現在、開設していないし、今後開設するつもりもない　54.9%

荒らしと釣り師の違い

記述年月日

2004年01月29日

なんでそんなに必死なの? いや僕がって話。書いたのもちろん僕じゃないですけれど。

74 ：水先案名無い人 ：03/11/19 04:31 ID:G274jM/i

俺が荒らしと釣り師の違いを教えてやろう。荒らしと言うのは、周囲を叩くことによって自分が偉くなったように錯覚する馬鹿だ。釣り師と言うのは、自分が馬鹿をやって周囲に叩かれる事でほくそ笑む変態だ。では、周囲に叩かれそうなキーワードを言って、数行後に釣れた！というのは何か。

残念ながらそいつは釣り師ではない。荒らしでもない。そいつは、2chの最下層カースト。悲しい「かまってクン」だ。真の釣り師は、決して自分が釣り師である事を告白しない。なぜなら、釣れた！と告白することは、逆に、自分が周囲の叩きに「釣られた」事を意味する敗北宣言でもあるからだ。真の釣り師のスレは、ライブ中は周囲を巧みな話術で煙に巻き、引き付け、熱中させる。そして、なにもかもが全て終わった後、ようやく数人が「あれは釣りだったのでは？」と気付くのだ。いま2chで釣り師を名乗っている奴は、大概が周囲のレスにまんまと釣られてしまった滑稽な"釣られ師"なのだ

まさに自称釣り師が横行する現在の２ちゃんの真理！

釣れた！と告白することは、逆に、自分が周囲の叩きに「釣られた」事を意味する敗北宣言でもあるってのが微妙。もうあれだよ、なんていうか「釣れた！」とか言われても悔しがらなきゃいいと思った。いつでもマジレスで。

クリックすると感染するウィルスがあるらしい

記述年月日

2004年01月31日

日本ネットワークアソシエイツ株式会社によると、米国 Network Associates は、同社の McAfee AVERT が、29日に発見された「W32/Mimail.s@MM」ワームの危険度を「中」とした、と発表した。

W32/Mimail.s @MM は、ユーザーが添付ファイルをクリックすると感染し、感染したマシンからメールアドレスを抽出、大量メールを配信する。

揚げ足を取るとか馬鹿にしているとかそういった意味ではなく、しかも単なる僕の知識不足ってオチなのかもしれないけれど、ファイルの実行ではなくて添付ファイルをクリックすると感染するウィルスなんて作れるのか疑問だったり (ダブルクリックってこと? ) 。よくわからないけれど、そのうちポインタを合わせただけで感染するウィルスとかも出てきそう。

あと、これは全く関係ない話なのだけれど、Tripod から Infoseek への自動転送が 1 月いっぱいで終了するらしい (と思っていたら、 2 月末まで平気らしい) 。今までは、

• http://hogehoge.tripod.co.jp/
• http://members.tripod.co.jp/hogehoge/

これらのアドレスを持つリソースへアクセスしても、

• http://hogehoge.at.infoseek.co.jp/
• http://members.at.infoseek.co.jp/hogehoge/

と、上記の方へリダイレクトされていたので参照に困らなかったわけですが、このサービス (なのかしら? ) が終了という感じです。と、自分用めも。ちなみに hogehoge というアカウントは存在していたりします、今確認した。あと、 Tripod は更新しなくてもアクセスがなくても、アカウントの削除はあまりされないことがわかった。一年二年程度は平気。トラブルを起こしたら消されるんでしょうけれど。 hogehoge が僕のというわけじゃないです、念のため。

2004年01月のUserAgent比率

記述年月日

2004年02月01日

記述したのは二月なのですが、便宜上一月分のファイルへ格納します。

比率を見ればわかるとおり、当サイトのようにアクセス数が少ないサイトですと、IP アドレスや解像度などの情報を取得せずともある程度まで「誰か」を特定できてしまうから感じがよろしくないような。つまり、同一の UA 名を持つブラウザでのアクセスは、おそらく同一人物なのだろうというわけです。なんだか嫌な感じがしますね、こうやって製作者にそういったことを知られてしまうのは。しかもですね、これがもっと高機能なアクセス解析サービスを導入するとより一層特定されてしまうから、余計に気持ちが悪い話。たとえばですね、リファラ (いわゆるリンク元) の取得なんかをされていると、自分のサイトのリンク集などから参照しに行った場合、それだけで「誰が来たか」の予測がついてしまう。ちなみに当サイトのアクセス解析 (ではないのですが) は UA 名しか取得できないので、その点でいえばまあ安心かもです。とはいっても、同一人物のアクセスがあるというのは、想像できてしまっているのですけれど。

「で? だから? 」という感じではありますが、そんなことを言われても困るのでした。あと、率を全て足しても 100 にはならないです。手動計算 (ってなんだ) なので、四捨五入があれでして。で、作成し終わってから「こういうものは表計算ソフトでも使えばよかったのでは? 」などと気付いてしまったものだから、悔しい話。(まあ使わないだろうと思ってアンインストールしてしまっているのですけれどねえ)

ってゆーか、今月は張り切りすぎた。