最近ちょくちょく見に行っているサイトです。
結城浩さんはプログラミングに関する本をいくつも書かれていて、ぼくもPerlの本を読みましたがとても分かりやすかったです。「読み物」には仕事や生活の上での心がけなどが書いてあってとてもためになります。「日記ダイジェスト」もおすすめ。
STUDIO KAMADAは、ぼくはまだ読んでないコンテンツの方が多いですが、日記で扱われている内容はジャンルの幅が広くてレベルが高いです。多くの言語の翻訳ができる翻訳・辞書のフォームも便利そう。
hirax.netは他のもの検索していて偶然見つけたんですが、糸井重里さんのコラムにもでてくるくらいなので、有名なサイトみたいです。日常的な事象を科学的に考察していて、それが図を多く用いて語られています。面白いです。
トップページにつけた、百人一首を1日に1句表示してくれる機能は、自分でもなかなか気に入っている。6年ほど前に16bitコンピュータで百人一首を題材にしたゲームを作ったほどで、俳句や和歌などは意味は理解しないでも毛嫌いするほどでもないので、自分のサイトだけどついつい見にいってしまう。1日ごとに句を替える機能を付けたのがよかったみたい。
27日の続き。
データを1ヶ月単位で管理すると限定するなら、スレッドのIDはyyyymmdd_nではなくyyyymm_n（年月_番号）にした方がよさそう。yyyymmとnの間に_（アンダーバー）を入れるのは、その方が人間が見て、yyyymmが年月だと推測しやすいと思うから。
どれがいいかな。
作ってて気付いたんだけど、データを1ヶ月ごとに管理することのメリットは、ファイル名から内容を知ることができるので、ファイルアクセスを減らせるということ。これまでの掲示板だと、効率をよくするためにスレッドのタイトルなどの情報は別のファイルにまとめているものが多いけれど、データファイル名とデータ内容を対応させることで、個別にインデックスファイルを設けなくてもよくなる。
たとえば、トップページでは最新の書き込みを表示するわけだけど、タイトルだけでなく本文も表示するならデータファイルを読み込む必要があるわけだし。スレッドのレスを全部表示する場合も同様。過去ログのスレッドタイトルの一覧の表示も、月ごとに表示するので、これもそのファイルだけを読み込めばよいということになる。
データファイルがシンプルになると、エディタなどで直接編集したりするときにも便利だし。
タイトル一覧をツリー形式で表示すると、誰がレスをしているのかが一目で分かるというメリットがある。これはやっぱり便利かもしれないなぁ。これを使うなら、レスごとにタイトルをつけられるようにするか、それともレスの本文の文頭から数文字ほど抜粋するのがいいかも。
なので、データの汎用性を考えると、レスごとのタイトルのフィールドを設けておいた方がいいかもしれない。
SSIを使って実現できそう。でも、SSIだと実行時のカレントディレクトリが呼び出し元のHTMLの場所になるみたいだから、外部ファイルとかを扱いにくいんだよな…。設定ファイルを読み込むのも一苦労。
掲示板のスクリプト作成を計画中。考えている仕様は以下。
データとURLをずっと使えるようにするので、最初にデータ形式などの基本設計をしっかりと考えておかないと。
マルチスレッドといっても、2ちゃんねるのようではなく、普通の発言は新規投稿でし、返事を書くときはその発言へというものを考えている（普通のレスタイプ）。なので、スレッドごとにはファイルを作らずに、データは1つのファイルにまとめ、期間やファイル容量などによって分割していった方が便利そう。
ファイルを分割するのは、容量によるものが動作の効率的には一番いいだろうけど、ファイルの管理のことも考えて、月ごとに1つのファイルにするのがいいかなと考えている。
また、過去の発言内容もずっと見られるようにしておく訳だけど、レスがつけられるのは一定期間内にしておくのが、ややこしくなくて過去ログファイルの管理上もよさそう。レスがつけられる期間はスレッド作成から2ヶ月くらいを検討中。
URLを保って全ての記事への後方参照を可能にするために、スレッド（話題）ごとにURLを与えて、その中のレスごとにアンカーをつけるのがよいかな。また、後方参照は「>>ID番号」でできるようにするつもりだけど、ID番号からいつの記事かを判断できると便利そうだし、ID番号を年月日をもとに決めるのがいいかも。yyyymmddn#nというように。ただ、>>200210273#8などとなって少し長くなってしまうけど（URLでも参照できるので、その方が実用的かも）。同じスレッド内では#以降（この場合だと>>8）で参照できるようにする予定。
いくつかスレッドタイプやツリータイプの掲示板を見てみたところ、スレッドの全レスを表示するモード以外に、1つ1つのレスを表示するモードも採用しているものが多かったけど、閲覧上は全レスが表示されるモードが便利なので、個別のレスだけ表示するモードはつけない予定。また、スレッドにはタイトルをつけて投稿するけれど、レスではつけない予定。
スレッドごとのレスの数は、制限を設けない予定。
URLは、たとえばbbs/200210273#8などになる予定。この場合だと、2002年10月27日に作られた3つ目のスレッドの8番目のレスという意味。URLは次のようなものが候補。
bbs/ 掲示板トップ bbs/200210271 2002.10.27の1つ目のスレッド（全レス表示） bbs/200210271#12 ↑の12番目のレス（全レス表示） bbs/200210 2002.10のスレッドタイトル一覧
掲示板のトップページでの表示形式は、スレッドタイトルのみ、スレッド展開状態（いくつかのスレッドが内容も表示される）、ツリー形式、新しい発言順などが一般的だけど、レスごとの表示モードはつけないので、ツリー形式を採用するならスレッドタイトルのみの方がシンプルで分かりやすそう。新しい発言順の方式は、レスのみ並べてもどのスレッドへのレスかは分かりにくいので、最後に発言のあったスレッド順に表示するのがよさそう。
スレッドタイトルを、スレッドが作成された日時順で固定すると混乱が少なそうだけど、新しい投稿を見つけるには最新のレスの投稿順がよさそうだし。
携帯での表示については考慮中。
過去のバージョンのものも置いておけるように、これからはファイル名にバージョンなどの情報を入れるようにしようかな。最近公開したものではすでに実施済み。
作成中。
掲示板は、利用目的によって求める機能がほんとに様々ですねぇ。奥の深さを知りました。
おすすめの掲示板スクリプト配布サイトはレッツPHP!。Perlではないけれど、ぼくの作りたいと思っている機能はだいたい入ってます。
世界的に最も広く使われている米国のインターネット検索サイト「グーグル（ｇｏｏｇｌｅ）」に韓国の公務員と大学教授、一般市民の住民番号を含めたプライベートにかかわる情報が無差別に公開されていることが、２３日分かった。
http://japan.donga.com/srv/service.php3?biid=2002102516328
情報が流出した原因は分からないけど、「コンピューター・セキュリティー管理者が作業の利便性のため、外部でも文書管理ができるように『バックドア（裏門）』を設置したため、強力なグーグルの情報検索エンジンがこれに入り込んだのかも知れない」というのは、検索エンジンのクローラーはアクセス制限のかかっているページの情報は集められないので、もし原因がこれだったら管理者のセキュリティー意識が低いというしかないような…。
サーバーにあるテキストファイルをもとに、動的にHTMLドキュメントを出力してくれるスクリプトを作りました。HTMLドキュメントを簡単に書けるようになります。日記システムのテキスト変換エンジンを流用したので思ってたよりも簡単に完成。
それで、このスクリプトも公開したいと思うんだけど、説明用のドキュメントを書くのがめんどうで…。
というオチでした(^_^;
ドキュメントを書いたら公開する予定。
23日の続き。
検索エンジンで、検索結果ページでのリンクのクリック数を記録している（であろう）ところは、gooがあった。MSNやInfoseekなどは普通のリンク。
TTL（Time To Live）は、パケットがいくつのルーターを通過するまで有効か、ってことだったんですね。そういえば、DNSのZoneの設定で、時間関係のものがいくつかあったなぁ。
フランスとドイツのGoogle検索結果から、反ユダヤやナチス擁護など100以上のサイトが削除された。ハーバード大学のベッカーマンセンターが10月24日公表した報告書で明らかになった。
http://www.zdnet.co.jp/news/0210/25/nebt_02.html
個人的には、あまり必要以上の情報操作はしてほしくないな。過度の情報操作は本当に危険だし、それにGoogleの検索システムは精度が高いので、自然淘汰に任せてもそれなりの検索結果にはなると思うので。
今は検索エンジンではGoogleが一人勝ちの状況だけど、やっぱりある程度競争が行われていた方が適正な情報のためにもいいのかな。
今気付いたんだけど、google.co.jpでは検索結果の各ページへのリンクが、そのページのURLではなくgoogle.co.jpのCGIを通したURLになったみたい。google.comの方では今までと同じでそのページへのURLになっている。
リンクを直接そのページのURLにせずに一度CGIを通すことによって、リンクごとのクリック数を記録できる。Googleでは検索結果のページに、ページの一覧とともにそのページ内のキーワードに関する短い文章が表示されるようになっているので、ユーザーはそれをもとに判断し、よりキーワードに関係したページをクリックすると予想される。google.co.jpは多分、このことを利用してクリック数を検索結果に反映させ、検索の精度を上げる目的があるのではないかな。
一度CGIを通す欠点は、いくつかあると思うけど、訪問済みのリンクが分からなくなってしまうというのもあるなぁ。ブラウザの機能で、一度訪問したページ（URL）へのリンクの場合は色を変えて表示してくれるけど、CGIを介したURLは新しく作られたURLなのでどれも未訪問のページとして表示されることになってしまう。
それから、リンクをクリックしたときに、検索で指定されたキーワードなどの他にも情報が収集されてそうで、ちょっと嫌な気もするなぁ。検索精度が上がることは歓迎だけど。
このCGIを介したリンクは、昨日まではなかった気がするけど、一時的なものなのかな。google.comなどでも移行していくのか気になるところ。
あれ？ 今見たら元に戻ってる。なんだったんだろう。
HTMLファイルから自動的に目次を作成してくれるスクリプトです。便利ですのでよかったらどうぞ。
なかなか奇抜な発想のカウンターです。
ことわざ表示スクリプト「Fortune」を公開しました。
ローカルでの編集が大変なので、省略していたindex.htmlへのURLを記述することに。でもuttsu.comのトップだけは省略を続行。
SSIによって出力されるページでもLast-Modifiedヘッダを返すようにしたのはいいけど、ページが更新されていないとブラウザにキャッシュされたページが表示されるので、fortuneによって表示されるメッセージが更新されなくなってしまった。これを解決するには、
というのが思いつくけど、毎回ページが出力されるようになるので、どちらも必要以上のトラフィックを招いてしまう。
でも、仕方ないのでSSIでLast-Modifiedヘッダを返さないようにすることに。
.htaccessに
XBitHack on
とすれば、実行属性のファイルが自動的にSSIで処理されるようになります。XBitHack fullの場合と違って、Last-Modifiedヘッダは返されなくなります。
最新の日記以外の月ごとの日記は昇順で表示するようにしました。最新のものは、新しい日記が上にくる降順表示です。
トラフィック抑えるために、最新5日分（デフォルトでは）の日記を表示するようにしました。
たとえば、コンピュータ・ウィルスなどのように、プログラムなどが生物的な特徴を示すことは結構ある。最近では逆に、生物の特徴を観察して、それを技術に生かす研究もされているくらいである。
ネットワークのプロトコルとして使われているEthernetでは、パケットによってデータのやりとりをしている。パケットの先頭には「ヘッダ」という情報がつけられ、この中に送信元や送信先の情報が入っているが、ヘッダの先頭には「プリアンブル」といわれるダミーの情報が付加され、これによってデータの先頭を知ることができるようになっている。これは、いきなり通信が始まって最初の方のデータを受信しそびれても通信ができるようにするためとのこと。
ところで、生物のDNAでもこれと同じような仕組みを持っている。DNAが転写されるとき、その開始位置はpromoter領域とよばれる、データ部の前にある領域の情報が参照される。promoter領域の中にあるTATA boxと呼ばれる領域の塩基配列は、TATA{T/A}A{T/A}A…というのが続いているらしいけど、これがEthernetの場合のプリアンブルに相当するのではないかな（専門ではないので間違っているかもしれないけれど）。
このように考えると、人工的な技術も、より面白く感じるなぁ。
インターネットのサイトでは、ドメイン名の前にwwwをつけるサイトが多いようだけど、これももしかしたら、口頭で伝えるときに最初の方（http://やwww辺り）を聞き逃してもアドレスが伝わるという、ちょっと生物的な性質があるかもしれない。
アクセスするたびに、ことわざや格言を1つランダムに表示してくれる機能をホームページに付けると面白いな、と思って作りました。SSIを利用しています。ちなみに名前は、UNIX系の同名プログラムから拝借。
早速uttsu.comに設置することに。データは、今回は百人一首を採用。気分によって変わっていくでしょう。
簡単なCGI/SSIのプログラムなら書けるようになってきたので、いろいろ公開することを検討中。
でもその前にURLをしっかり考えないと（いままでコロコロ変えているので…）。現在の候補は「/product/プログラム名/」。動作環境や言語などで細分するかはちょっと迷っている。というのも、移植などにより複数の環境に対応することもあるのでURLに動作環境などを入れるのは問題があるかなと。
productにsを付ける（products）かは、一大問題だけど、英語力がないので判断しかねる状態。productsやlinksの方が自然なのは分かるけれど。
それから、テキストファイルから自動でドキュメントに変換してくれるスクリプトも作ろうかな（だいぶ前に作ったのがあるけれど、改良しないと）。
SSIを使ったページは、サーバからのレスポンスヘッダにLast-Modifiedヘッダが含まれなくなるけれど、サーバの設定ファイル（.htaccessまたはhttpd.conf）に
XBitHack full
の一行を追加すると、SSIで処理された場合でも、もとのHTMLファイルの更新日がLast-Modifiedとして返されるようになるとのこと。
さらに、XBitHack fullを使えば、拡張子が.htmlのファイルがSSIに対応していなくても、.htmlファイルに実行属性を与えることによりSSIの処理をさせることが可能。なので、全ての.htmlファイルをSSIに対応させた場合のようにサーバに余計な負荷がかかることもなくなる。
メッセージが（毎回ではなく）1日ごとに変わる機能をつけました。uttsu.comでも採用。
srand()を使って乱数を初期化しようとしたところ、なぜかsrand()を使うと、rand()関数で毎回同じ値が返ってくるように。
実はこの現象は昨日も起こっていたのだけど、Perl5.004以降はrand()関数が呼ばれるときに乱数が自動的に初期化されるのでsrand()を使わずに済ませていました。けれど、1日ごとにメッセージを変えるには必要なので調べてみたところ、ActivePerlではこの現象が起こるようです。
でも、サーバの方ではActivePerlではないので、アップロードすると正常に動きました。
ちなにみ、1日ごとにランダムな値を返す（同じ日の間は同じ値を返す）には、乱数を初期化するseedに、そのときの時間の「日」より大きい値を入れてやればよいです。
my ($sec, $min, $hour, $day, $month, $year) = localtime(time); srand($year*1200 + $month*100 + $day);
大きな企業のウェブサイトでは、www.という（サブ）ドメインが使われていることが大半だけど、見た目などの他に、機能的な面でなにかメリットはあるのかなと思って調べてみた。「Gabacho-Net - 「www.」は省略可能か？」によると、
「www.」を省略可能にしようとすれば、「組織ドメイン名.jp」のようなホスト名省略のドメイン名に対応してウェブサーバのIPアドレスを答えるようにしておく必要があります。そうすると、そのウェブサーバにメールアクセスが来る可能性があります。通常、ドメイン名（ホスト名省略）を宛先とするメールの送り先を知るにはDNSでMX（Mail eXchanger：メール交換機）というアドレス情報の問い合わせをするのですが、万一それに失敗した場合、ドメイン名のIPアドレスに向けてメール送信を強行しようとするメールサーバがあるからです。そのようなメールも受け取れるようにしようとするなら、ウェブサーバでメールサービスも動かしておく必要があります。
とのこと。要は、
つまり、DNSがエラーを起こした場合、メールを失う可能性があるということかな。
他にも、管理が容易になったり、トラフィックなどの問題もあるだろうけど、それらは致命的な欠点ではないと思うので。
たしかに、大手のサイトはwww.のサブドメインを使っているところがほとんどで、www.なしだと繋がらないところも少なくない。調べてみたところ、コンピュータやソフトウェア関連の企業の中で、wwwなしをデフォルトにしているサイトはごく少数のようだった。
www.なしからありのドメインへの移行はサーバのリダイレクト機能を使えば簡単にできるけれど、wwwなしを完全に廃止した場合、リンク切れを招いてしまう。それに、リダイレクトされるページは検索エンジンのロボットにとっても扱いにくいものだろうし。もしその可能性があるなら、サイトの規模が小さいうちに明確に決めておいた方がよさそうだな。
「ZDNet - ドメインをデザインしよう」によると、
汎用JPドメインのもう一つの有利な点は，URLが短くなり印象に残りやすい点だ。これはTVや雑誌などで目にしたURLが入力しやすくなるだけでなく，携帯電話などの端末からURLを入力する場合にも有利だ。
携帯電話を見ればわかるが，JPは２回の入力で可能なのである。最近はサイトにアクセスする手段として他にも多くのサービスがあるが，特別なソフトも要らず，メールも利用できるという点でも，汎用JPドメインは非常に有利である。
とある。たしかに。
でも、頭にwwwをつけていては、返って長くなってしまうなぁ。
URLを統一するため、index.htmlを省略することにしたのはいいけど、案の定、ローカルでの編集がかなりやりにくくなった。/で終わるURLのリンクを開くと、ディレクトリ内容の一覧が表示される状態になるので。
この状態では、編集どころかリンク切れなどの確認もしにくいので、ローカルではan httpdでサーバを立てて確認している。けれどもこの方法では、ページをブラウズ中に編集したい個所があっても、「編集」ボタンで編集ができない。IEに、ローカルでのブラウズ中には、/で終わるURLのときはindex.htmlを表示するようなオプションがあれば便利なんだけど。
もう少し運用してみて、様子をみてみよう。
リンクのページは長い間更新していなかったので、無効になっているリンクを更新した。
知り合いのサイト以外にも、自分が普段見ているサイトをリンク集に加えたいな。また時間があるときにでも。
この間設置した検索BOXでは、Googleの検索結果ページの検索BOXの中に「site:○○」（uttsu.comならsite:uttsu.com）という文字が表示されるけど、これを表示されないようにするには、フォームの「name=as_sitesearch」を「name=sitesearch」にするといいみたい。
<input type=hidden name=sitesearch value=uttsu.com>
また、サイト内検索と、インターネット全体からの検索をラジオボタンで切り替えられるようにするには、
<input type=radio name=sitesearch value=uttsu.com checked>uttsu.com <input type=radio name=sitesearch value=>the web
とすればOK。スペースを節約するために、チェックボックス1つだけで表示するなら、
<input type=checkbox name=sitesearch value=uttsu.com checked>uttsu.com内
とすればOK。
インターネット全体からの検索ならGoogleのオフィシャルサイトでできることなので、自分のサイトにつけるのはサイト内検索機能だけにしておくのがおすすめ。書いておいてあれだけど。
インターネット上でもっとも充実している情報は、おそらく、ホームページ制作に関する情報でしょう。日々苦労(?)と発見を繰り返しつつ、ホームページを作っている人は、やっぱりホームページ作りに関する情報を発信したくなるというわけ。
やっぱりコンピュータ関係が多い。学術関係なども少しはあるけれど、まだまだ充実しているとは言えないのが現状。ホームページ制作に関する情報と同様、インターネットをよく使う人はコンピュータ関係への関わりも大きい人が多いという話。先日のMITのOpenCourseWareのような活動が盛んに行われるようになるといいな。
いまや環境問題は、インターネット上にまで広がっている――という訳ではないけれど。
検索エンジンのデータベースの情報は、日々クローラーといわれる自動巡回プログラムによって収集されているわけだけど、CGIによって出力された情報なども収集される。CGIは動的にページを出力するわけで、たとえばこの日記システムでは、月ごとと当日の全く同じ情報が2つのページ（URL）として存在しているけれど、それらを厳密に判別することは難しい（というより、デメリットの方が大きい）ので、そのどちらもが収集される。
これによって、検索エンジンの記憶装置の容量と、クローラーが情報を収集するためのCPUのパワーと時間が（ほんの少し）無駄に消費されることになる。これって、ネット上の資源の無駄遣いみたいなものかな？ そういう意味では、最新の日記用CGIではなく、手書きでHTMLを書く方が環境にやさしいということになるなぁ。
まぁ、個人の日記程度なら小さいことだけど、意図すればCGIで無限にページ（URL）を生成することは簡単にできるので、みんなで意識して資源を守るようにする日が来るのかな？
そういえば、こんなページがあったな。
uttsu.comに掲示板をつけないの？ という質問をときどき受けるけど、掲示板をつけるのにはちょっと抵抗がある。
掲示板はだれでも書き込めるので、（今のuttsu.comでは）唯一の自分以外の人の手が加わる”コンテンツ”となる。それだけでなく、掲示板は更新速度が速いから（誰かが書き込んだだけで更新されるので）、多分人気コンテンツの一つとなると思う。他のコンテンツの更新があまり出来ていない状況では、掲示板がもっとも人気のあるコンテンツとなり、それが自分だけの「カラー」のものではないのでちょっとツマラナイな、という気がするので、設置をためらってしまう。ま、日記がメインコンテンツとなりつつある現状も、同じようなもんか。
もし掲示板を設置するとなれば、自分でスクリプトを書こうかな。出来合いのものに手を加えて使ってもいいんだけど、掲示板のスクリプトを替えるたびにURLが変わるのも困るし。それに、シンプルなものだったら結構簡単にできそうだし。
といっていると、なかなか設置できなくなりそう…。
各県や市町村のドメインは、「<組織ラベル>.<市区町村ラベル>.<都道府県ラベル>.JP」という形式になっているよう。例えば、市の場合は「city.市名.県名.jp」となる。
このドメインは、市区町村の場合は「組織名」（cityやtowm）を付けない方がスマートではないかな。町から市へ変わったときなどもドメイン名を変更せずに済むし。市区町村の統廃合などで名称が変わる場合は仕方ないけれど。
日記の中で画像を表示するためには、画像ファイルをサーバーにアップロードしておく必要があるけど、どのディレクトリを使うかがなかなか難しい。
というのも、日記の原稿ファイル自体はテキストファイルとして専用のディレクトリに格納されていて、日記のURL（例えばdiary/20021015.html）とは別のところにある。そして、それは一応外部からアクセスできない場所に置いてあるので、そこに画像ファイルを置いても日記には表示されないことになる。これを解決するには、いくつか方法が思いつくんだけど、
というのがある。ただ、前者だと原稿ファイルと画像ファイルを別のディレクトリに置くことになるので、ちょっと管理がしにくくなる。後者は、原稿ファイルと画像ファイルが同じディレクトリにあるので、関連が一目瞭然で管理がしやすいけれど、URLの階層が深くなってしまう欠点がある。
上の2つの方法の長所を組み合わせたスマートな方法は、
というもの。これなら、原稿ファイルと同じように、リソースファイルの数が増えてきても、ディレクトリを分けることで整理もできる。
これを実現するには、apacheのRewrite機能を使えばよい。リソースファイルは原稿ファイルと同じディレクトリに置いておき（このディレクトリは外部からアクセスできなくてもよい）、diary/yyyymmdd.htmlへのアクセスなら、今までどおり日記を出力し、diary/resource/○○へのアクセスなら、CGIを通して画像ファイルを出力すればよい。
でもこの方法にも、欠点がある。
また、diary/○○というURLが一番すっきりしているけれど、もし上記の理由などでこの方法が使えなくなっても同じURLで運用できるように、diary/resource/などのようなURLを使ったほうがいいかもしれない。
uttsu.comでは、diary/resuorce/というディレクトリに置く方法を検討中。
文字装飾のタグをいくつか使えるようにしました。HTMLのものと同じタグを採用することに。
米マサチューセッツ工科大学（MIT）は、同大学が提供している全コースの講義録などをオンラインで提供することを決定した。しめて10万7840ドルの価値があるという。
http://www.zdnet.co.jp/news/0210/11/nebt_16.html
http://ocw.mit.edu/index.html
すごい…。
http://www.hyuki.com/yukiwiki/wiki.cgi?MitOpenCourseWare
大学の講義禄のような質の高い情報が広く公開されるようになれば、もちろんその情報自体の価値も何倍にも上がるだろうし、インターネットの価値もかなり高まるんじゃないかな。インターネット上には学問の専門的な情報が不足しているように思うから、日本の大学や他の機関ももこれに続いてくれればいいな。
以下の機能を追加しました。
それから、セクションのカテゴリの指定方法は、[ ]で囲んで行うことに決定。まだ実装していないけど、これからの日記にはカテゴリも指定していくつもり。
今まではArialを指定していたけど、Verdanaにしてみることに。Verdanaはマイクロソフトがモニタ画面用に作成したフォントらしい。
ローカルでのチェックがしやすいように、各ディレクトリのindex.htmlファイルへリンクをしていたけど、それだと単にディレクトリ名を指定した場合と合わせて2つのURLが存在してしまうことになるので（検索エンジンなどは正しく認識しているのだろうけど）、index.htmlへのリンクをディレクトリ名へのリンクに統一することにした。
デフォルトインデックスを使うもう一つの利点は、例えば将来SSIやCGIを使うようになって、ファイル名がindex.htmlからindex.shtmlやindex.cgiに変わっても同じURLを保てるというのもある。
日本人が取得するドメインとしては、gTLDの.com、.net、.orgや汎用jpドメイン、ccTLDなどがあるけれど、ドメインによってやっぱり微妙にイメージが違ってくる。僕も自分のサイトに使うドメインを決めるのは随分迷ったけれど、結局uttsu.comに落ち着いた。
.netは、フリーソフトを開発して公開するのにはよさそうだし、.orgはやや控えめだけど非営利というイメージがかっこいい。ccTLDは、日本人が運営してるサイトに対する印象は、.netなどのドメインの場合とあまり変わらないけれど、他の国でもccTLDに対してはこんなイメージなのかな。.jpは、1文字だけだけどgTLDよりも短いのと、何よりも日本語で伝えやすいのがいい。
そういう訳でいろいろ迷ったけれど、結局最後の決め手は、.comは国際的にも一番通用しそうというのでuttsu.comを使うことにした。
最近は.nameや.infoのような新しいgTLDドメインが出来てきてるけれど、個人的にこれらはあまり好みではない。.proは取得に一定の資格が必要なので、それなりのステータスにはなるかも知れないなぁ。
結城浩さんの、「サイト内の検索にGoogle.comを使う方法」をもとに、uttsu.comにGoogleによるサイト内検索ボックスをつけました。精度はかなりいいです。
上のページには、独自ドメインでない場合のサイト内検索の方法も書いてあります。プロバイダのスペースを使っている人も見てみてはいかが。
URLのドメイン名にwwwをつけるのを標準にしているサイトと、つけないのを標準にしているサイトがあるけど、wwwをつけないことによる大きなデメリットはあるのかな。個人的にはURLは短い方が好みなので、uttsu.comでは付けない方を標準にしている。ちなにみ、w3cはwww有りが標準で、www無しはSlashdotがあった。全体的にはwwwを付けるサイトが多いみたい。
uttsu.com内のファイルに、拡張子無しでアクセスできるようになりました。例えば今日の日記の場合は、/diary/20021013 のような明快なURLでアクセスできます。
コンテントネゴシエーションのメリットとしては、ブラウザの設定によって日本語と英語のページの出力を自動的に振り分けたりできるけど、ローカルで管理するファイルの拡張子が少しややこしくなってしまう。あと、半永久的に不変なURLにするときにも役立つ。本格的に運用するかはもう少し様子を見てから決めよう。
ちなみに設定方法は、apacheの場合は.htaccessファイルに次の一行を追加するだけです。
Options +MultiViews
やっぱり、ローカルでのリンクが働かなくなることかな。apacheをインストールすればいいのだろうけど。
それから、コンテントネゴシエーションに対応していないサーバーに移転することもできなくなるなぁ。ほとんどは対応してると思うけど。
NTT東日本の電話回線の線路情報で調べたところ、自宅からNTT収容ビルまでの線路距離は約5kmと出ました。
線路距離長（エンドユーザ〜ＮＴＴ収容ビル）：4970m
伝送損失：48db
ちなみに、ADSLのスループット値は600kpbs程です。
関連リンク
以前に出ていたアイデアをもとに、少し改良しました。アイデアは以下のようなもの（メモ書きですが）。
サブセクションを設定できるようにしました。一つの話題が長くなりそうなときに使うと便利でしょう。
データファイルを再起的に検索というのは、日記のテキストファイルを格納しておくディレクトリのサブディレクトリからも、日記データを探してくれる機能です。これによって、年ごとや月ごとにディレクトリを作ってデータを格納することが可能になります。
今後特につけたい機能は以下のもの。
画像を表示する機能をとりいれる前に、まずディレクトリ構成を決める必要がありそう。日記のテキストファイルはどこに置いても、表示するときには適当なURL（yyyymmdd.html）で表示されるけど、画像へのリンクを張るなら画像は決められたディレクトリに置いておく必要があるので。
,,,でテーブル表示というのは、カンマで区切ったデータを自動的にテーブル表示してくれる機能で、YukiWikiで採用されているもの。簡単にテーブルが表示できてとても便利そう。
サブセクションにも対応したので、今までよりも長い文章も書きやすくなった。その分、だらだらとした文章が増えてしまいそうな気もするけど…。