uttsu.com > uttsuの日記 >

2002年10月17日

2005年 8月
2004年 5月
2003年 11月, 10月, 8月, 5月, 4月, 3月, 2月, 1月
2002年 12月, 11月, 10月, 9月, 8月, 5月, 3月, 2月, 1月
2001年 6月, 5月, 4月, 3月

2002年10月17日

# [program][uttsu.com] ことわざ表示スクリプト fortune

アクセスするたびに、ことわざや格言を1つランダムに表示してくれる機能をホームページに付けると面白いな、と思って作りました。SSIを利用しています。ちなみに名前は、UNIX系の同名プログラムから拝借。

_ uttsu.comに設置

早速uttsu.comに設置することに。データは、今回は百人一首を採用。気分によって変わっていくでしょう。

_ 公開へ

簡単なCGI/SSIのプログラムなら書けるようになってきたので、いろいろ公開することを検討中。

でもその前にURLをしっかり考えないと(いままでコロコロ変えているので…)。現在の候補は「/product/プログラム名/」。動作環境や言語などで細分するかはちょっと迷っている。というのも、移植などにより複数の環境に対応することもあるのでURLに動作環境などを入れるのは問題があるかなと。

productにsを付ける(products)かは、一大問題だけど、英語力がないので判断しかねる状態。productsやlinksの方が自然なのは分かるけれど。

それから、テキストファイルから自動でドキュメントに変換してくれるスクリプトも作ろうかな(だいぶ前に作ったのがあるけれど、改良しないと)。

# [CGI/SSI] XBitHack full

SSIを使ったページは、サーバからのレスポンスヘッダにLast-Modifiedヘッダが含まれなくなるけれど、サーバの設定ファイル(.htaccessまたはhttpd.conf)に

XBitHack full

の一行を追加すると、SSIで処理された場合でも、もとのHTMLファイルの更新日がLast-Modifiedとして返されるようになるとのこと。

さらに、XBitHack fullを使えば、拡張子が.htmlのファイルがSSIに対応していなくても、.htmlファイルに実行属性を与えることによりSSIの処理をさせることが可能。なので、全ての.htmlファイルをSSIに対応させた場合のようにサーバに余計な負荷がかかることもなくなる。

# [program] ことわざスクリプト改良

メッセージが(毎回ではなく)1日ごとに変わる機能をつけました。uttsu.comでも採用。

_ ActivePerlのバグ?

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] www prefix 問題

大きな企業のウェブサイトでは、www.という(サブ)ドメインが使われていることが大半だけど、見た目などの他に、機能的な面でなにかメリットはあるのかなと思って調べてみた。「Gabacho-Net - 「www.」は省略可能か?」によると、

 「www.」を省略可能にしようとすれば、「組織ドメイン名.jp」のようなホスト名省略のドメイン名に対応してウェブサーバのIPアドレスを答えるようにしておく必要があります。そうすると、そのウェブサーバにメールアクセスが来る可能性があります。通常、ドメイン名(ホスト名省略)を宛先とするメールの送り先を知るにはDNSでMX(Mail eXchanger:メール交換機)というアドレス情報の問い合わせをするのですが、万一それに失敗した場合、ドメイン名のIPアドレスに向けてメール送信を強行しようとするメールサーバがあるからです。そのようなメールも受け取れるようにしようとするなら、ウェブサーバでメールサービスも動かしておく必要があります。

とのこと。要は、

つまり、DNSがエラーを起こした場合、メールを失う可能性があるということかな。

他にも、管理が容易になったり、トラフィックなどの問題もあるだろうけど、それらは致命的な欠点ではないと思うので。

_ 実際の傾向は

たしかに、大手のサイトはwww.のサブドメインを使っているところがほとんどで、www.なしだと繋がらないところも少なくない。調べてみたところ、コンピュータやソフトウェア関連の企業の中で、wwwなしをデフォルトにしているサイトはごく少数のようだった。

_ wwwなしからありへの移行

www.なしからありのドメインへの移行はサーバのリダイレクト機能を使えば簡単にできるけれど、wwwなしを完全に廃止した場合、リンク切れを招いてしまう。それに、リダイレクトされるページは検索エンジンのロボットにとっても扱いにくいものだろうし。もしその可能性があるなら、サイトの規模が小さいうちに明確に決めておいた方がよさそうだな。

_ 蛇足だけど

ZDNet - ドメインをデザインしよう」によると、

 汎用JPドメインのもう一つの有利な点は,URLが短くなり印象に残りやすい点だ。これはTVや雑誌などで目にしたURLが入力しやすくなるだけでなく,携帯電話などの端末からURLを入力する場合にも有利だ。

 携帯電話を見ればわかるが,JPは2回の入力で可能なのである。最近はサイトにアクセスする手段として他にも多くのサービスがあるが,特別なソフトも要らず,メールも利用できるという点でも,汎用JPドメインは非常に有利である。

とある。たしかに。

でも、頭にwwwをつけていては、返って長くなってしまうなぁ。


2005年 8月
2004年 5月
2003年 11月, 10月, 8月, 5月, 4月, 3月, 2月, 1月
2002年 12月, 11月, 10月, 9月, 8月, 5月, 3月, 2月, 1月
2001年 6月, 5月, 4月, 3月

Copyright (C) Takashi Utsunomiya. All Rights Reserved.