Webページをローカルで編集するとダウンロード、編集、アップロード、という手順をとらなくてはならない。リモートのディレクトリをマウント出来れば最高。手元にあるマシンが自分のマシンで無い場合はパスワードを入力。みんなで Webページ編集を前提にすればどうかな。
同じバックグラウンドでWikiがあるじゃないか。でもWikiはページ自体を編集しない。つまり、ページを表示するたびにcgiが呼び出される。いまどきのCPUは高性能だから気にすること無いかもしれないかも。でもそれってもったいなくない?これってエゴかな?
使ったことがあるWikiクローンはみんな乗り換えに困った。そんなことがあってから、どうも乗り換えのことを考えてしまいWikiクローン導入には二の足を踏んでるんだ。
Wikiのいいところはみんなで書き込みができる点だ。Wikiを公開する前に管理者がやらなければいけないことは、内容を濃くすることなんじゃないだろうか。つまり、良いものの周りには良いものが集まる、ということだ。つまり、朱に交われば赤くなる、ということだ。いたずら的な書き込みに対する、特権発動をどこまで制御するかはどのように考えればいいのだろう。これはe.cgiにも同じだといえる。不特定多数の訪問者から記事を募集するということは、この線引きが重要となってくるだろう。
Wiki文法を一般的なhtml文法に変えることで生じる最大の恐ろしさは、e.cgiで作られたページで別のページに飛ばすこともできるということだ。例えば、meteタグを使ってそのようなことができる。多くのブラウザではmetaタグによる飛ばしに確認メッセージを出さないから、e.cgiで編集されたページを経由して別のページに行っても、これに気づかないユーザもいるかもしれない。どうすればhtml文法を使うことを許可できるだろうか。それもなるべくスクリプトを複雑にしないで。
もしかするともっと別のことを考えたほうがいいかもしれない。つまり文書を作るのになにもhtmlでなくてもかまわないということだ。僕はよくLaTeXを使うから、LaTeX文法を解釈してしかるべきhtmlタグに変換して表示できればそれもよいのかも知れない。とくに文書の共有という点ではいいかもしれない。今まで書き溜めた文書を公開できるのならば。でもどうなのだろう。LaTeXに未来はあるのだろうか。LaTeXの文書の構造化という概念はhtmlでも実現可能なわけだし、構造化タグ付けもhtmlのほうが簡単なように見える。確かに組版を前提に作られているだけあって、印刷した場合はきれいだと思うけど、電子財産の共有という点では難しいのかもしれない。これ以降の紙メディアの動向にかかっているかもしれないな。でもCSSの差し替えとかをつかえば、印刷に適したフォーマットを提供するもの簡単だと思うんだけどな。
とにかく書き込み文法の問題が解決しない限りは、e.cgiは使用制限を掛けておかねばならないだろう。
Firefoxは書き込みのときにUnicodeで書き込む。Intenet ExplorerはShift-JISのようだな。XHTMLを出力するようにした。すると上で挙げたどちらのブラウザを使ってもUnicodeで書き込まれるようになった。XHTMLファイルの出力の1行目で文字コードをUTF-8にしたからかな。やったぁ。結局変わらなかった。やはりInternet ExplorerはXHTMLを理解してくれないようだ。じゃぁヘッダの中に文字コードはUTF-8という指定を書けばいいのかもしれない。本当はShould notなんだけど。この際仕方あるまい。
変な表示になったらブラウザの文字コード判定を使えばいいかな。文字コードを変えたくなったら、正しい表示が出来るまでブラウザの文字コードを変える、テキストエリアの中身を全選択してコピー、ブラウザの文字コードを替えたい文字コードに変更。テキストエリアに貼り付け、eボタンを押してテキストエリアの内容を保存。
ブラウザの文字コード判定を信用することにしよう。とかくcgiで文字コード判定をするのは面倒だ。勉強にはなるけど。
とにかくcgiのほうでインプットの文字コード判定をしなくてよくなった。これでプログラムが簡単になるな。少なくとも僕のユースではUnicodeのほうが嬉しい。
まずはDTDを読んでtextareaの中に入れてもいいデータを確認しないと。一番知りたいのは空白の取り扱い。HTMLエスケープせよということ。とにかく大事みたい。クロスサイトスクリプティング?
結論を先に言おう。ソースを見たとき<textarea>から</textarea>の間に<や>や&を含めてはいけない。文字参照(<、>、&)はブラウザによって対応する文字(<、>、&)に変換される。<textarea>の後に終了タグの開始を意味する<が出てきた時点でtextareaは終了しているとみなされる。XHTML 1.1ではtextareaの中身は#PCDATAでなければならない(Parsed Character Data)。
cgiで出力された文書の構造を考えれば、textareaの中身に文書自体の見出しを示すh1タグとか段落を示すpタグが含まれるのはおかしい。編集先の文書の構造とcgiで出力された文書の構造の間に関係は無いからだ。ゆえにtextareaの中に構造化タグを含めるのはおかしい。ソースを見たときに構造化タグを示す<や>がtextareaの中に含まれてはならない。では&はどうだろうか。
#PCDATAは構文解析対象文字データなので、textareaに含まれる内容はtexareaが含まれている文書構造ツリーの枝になれるということだ(頭に#がついているので子要素を自身の内に含むことができる)。でも、編集中の文書をe.cgiの文書構造から見れば、ただのデータであり、2つの文書の間に内容構造のオーバーラップがあってはならないはずだ。
書いたはいいが、いまだにDTDの読み方は良くわからない。特にXHTMLになってモジュール化されてよりわからなくなった。つまりどこを見れば目的の情報にたどり着けるのか良くわからなくなった。上に書いた情報も、Googleで探し当てた情報だし。
WindowsMeとWindows2000のInternet Explorerではなんとなく表示が違うような気がする。特にpreタグの中に書いた[]の形が。preタグの中に読みにくい[]があったらそのページの管理者はWebページの編集をWindows 2000で行っているのかもしれない。preタグの中身だけをmonospaceとかにすればいいのかな。どちらも年賀状ソフトなどを入れていないフォントに関してはクリーンなシステムを使っているはず。やめたほうがいいかなサンセリフ体。読みやすいって話を聞いたんだけど。読みやすいのは英語だったかな?
文字コードも読みやすさの指標なのかもしれない。このページはUTF-8にしているけど、UnicodeのフォントはWindows Meでは貧弱なのかもしれない。試しにマイクロソフトが開発したShift-JISコードで書き込んでみると、見やすい。さすがはマイクロソフトである。寡占化のセオリーに忠実だ。どこでも読めることを考えれば、Unicodeで書いといたほうがいいと思う。編集環境にShift-JISを理解できるコードセットが導入されているかわからないし。
おなじOSでもブラウザが変われば見た目も変わる。Firefoxではsans-serifを入れても入れなくても同じ様に見えた。Internet Explorerではぜんぜん違って見えた。特に半角英字がぜんぜん違った。やはり日本語で読みやすいとされているfont-familyはsans-serifではないのかもしれない。英語と日本語が混じっている文書の場合はcursiveのほうが見やすいような気もしてきた。
Windows 2000にインストールしたFirefoxとIEでみると、サンセリフは結構読みやすいと思った。結局今は下のようにサンセリフを指定している。Windows Meの場合も調べなければ。Windows Meのことを考えると、無理にフォント指定するのは労多くして益少なしなのかもしれない。下のように指定して、Windows MeのIEで見ると見にくいフォントでmonospaceの文字が表示されるように思う。不思議なことにWindows Meで見た場合はフォントファイリーの指定はないほうがmonospaceの文字が読みやすい。というわけで今のところフォントファミリーの指定はしていない。うちではまだWindows Meは現役真っ盛りなので。
*{font-family:sans-serif;}
pre{font-family:monospace;}
ちなみにserifを指定するとこうなる。
ちなみにsans-serifを指定するとこうなる。
ちなみにcursive を指定するとこうなる。
ちなみにfantasyを指定するとこうなる。
ちなみにmonospaceを指定するとこうなる。
日本語の読みやすさはどれも変わらないような気がする。結局のところ、フォントの指定はユーザ任せでいいんじゃないだろうか。多分どんなブラウザでもフォントの指定はできるのだし。Googleで見やすいPC画面上で見やすいと言われているフォントを探したところ、Verdanaというフォントがそうらしい。今のところこのサイトはfont-family:Verdanaである。
セーフカラーだけでやるのは少し大変そうだな。
問題はブラウザが対応しているかだな。たしかページ数とか、紙の大きさもCSSで指定できるんじゃなかったっけ?でも実際使ってみると余白とか紙の大きさとかはブラウザの対応状況が遅れているためにほとんど使い物にならないのだとか。ということは余分なものは最初からつけないようにしてページを作ればいいのか?
印刷時に広告表示をきってしまうのは犯罪か?まぁユーザが自発的にページの頭と尻尾につけられる広告を除いて選択して、選択した部分だけ印刷すればそれでいいんだけどね。
<link rel="stylesheet" type="text/css" href="a.css" media="all"> <link rel="stylesheet" type="text/css" href="p.css" media="print">
設置を簡単にするためにもスクリプトのサイズは小さく、数は1つで、ライブラリの読み込みはしない、モジュールは使わない、という前提でどうだろう。
これが出来なければコンパイラが書けないプログラミング言語みたいでだめだな。
ここからContentsになるのがいくつ生まれるかな。
立方体の中に1電子ある場合の固有値を求めると、nx2+ny2+nz2、のような項が出てくる。この項以外は定数。つまり、この項に比例してエネルギーの低い順に並ぶ。規格化条件を満たさないから、nはゼロを取れない。2乗するので、正負の区別無し。最低のエネルギーから10個分のエネルギーとnの組をほしい。
my $N = 4;
my ($x,$y);
my @S = map{$x = $_;
map{$y = $_;
map{[$x,$y,$_,&f($x,$y,$_)]}($y..$N)}($x..$N)}(1..$N);
print join'<br>',map{join' ',@$_[0..3]}sort{$a->[3]<=>$b->[3]}@S;
sub f{return $_[0]**2+$_[1]**2+$_[2]**2;}
上のような感じになった。作るのに10分くらい。やっぱりperlは楽だ。そういえばシュワルツ変換よりも早いソート法があるらしい。シュワルツ変換は上で使ってる。で結果は下。4カラム目でソートした。だから上から10個とればいい。
1 1 1 3 1 1 2 6 1 2 2 9 1 1 3 11 2 2 2 12 1 2 3 14 2 2 3 17 1 1 4 18 1 3 3 19 1 2 4 21 2 3 3 22 2 2 4 24 1 3 4 26 3 3 3 27 2 3 4 29 1 4 4 33 3 3 4 34 2 4 4 36 3 4 4 41 4 4 4 48
信用できるのは4カラム目が26まで。なぜって1+1+25=27だから。27以上は5の場合が含まれる。例えば1+1+25=27とか、1+4+25=30とか。ちなみに手計算でやったら17を見落としてた。
上の結果は縮退している。例えば、1,2,2の組からは、2,1,2や2,2,1が得られる。つまり、下から3番目のエネルギーは3重に縮退しているということだ。面白いのは、体積を同じにしてx軸方向に伸ばして、yz軸方向に等しい量縮めた場合には3重縮退が解け、上に1,2,2、下に2重縮退の2,1,1と2,2,1が現れる。言い換えれば、電子の含まれる箱の対称性が崩れることで、縮退が解けるということだ。もしyz軸方向にも自由に変化させたら、縮退はなくなるだろう。
2006年7月25日16時37分: 分割回数約90万回で、小数点以下8桁までは一致。
2006年7月29日16時54分: 分割回数約100万回で、小数点以下9桁までは一致。
コマンドって1つ1つ書かなくてもいいんだ。セミコロンで区切ればプロンプトを出さずに全部結果を出してくれる。下に書いたのはデータファイルの最終書き込み時間と結果の最後から10行を見るためのコマンド。良かったわねということ。
ls -l a.dat; tail a.dat
最近面白いものを見つけた。これは何かと面白そうである。数学は嘘をつかない。正しく使われれば。工学に欠けているのは数学だ。数学の摂理を用いればわれわれが使っている数々のよくわからない法則を一つにまとめることができるかもしれない。僕はそう信じている。悲しいことに工学畑の人間はユーザになることで満足なのだ。安上がりだ。もちろん製品を生み出すことが工学畑に人間の本分ならば、それも仕方あるまい。でもそれは賞味期限の短いものを生み出すに他ならない。目覚しい発展を遂げる分野で仕事ができるのは面白そうだが、裏を返せば自分の製品が永久に1番になることはほとんど無いのだ。ものづくりとは、そういう側面を秘めていることを忘れてはいけない。ここでいうものとはなにか。たぶん製品のことだろう。すばらしい車を作って、1000年後もその車が走っていることがあるのだろうか。理論、甘美な響きだ。数学的に論理を進めていった理論は、最初が間違わなければ以降決して間違えない。その代わり、最初が間違えていれば最後まで全部間違いだ。論理というのはそういうものだ。次のステップに進む時に選んだ道の正しさは100パーセント正解か100パーセント間違い、ルートをたった一つ間違えただけで以降の結果は100パーセント間違い。だからどこから出発するか、どのように進むかの両方が重要だ。工学畑の人間にとって、スタートは実験条件であり、ゴールは実験結果だ。これが守られていない理論は100パーセント間違いだ。スタートとゴールを間違える者はほとんどいない。でもルートが問題だ。そう、ルートの取り方が往々にして適当だ。つまり、実験結果に誤差が含まれている以上ルートを多少事実と曲げてとってもOKだろうという姿勢だ。これは悲しい。理論は現実を模写しなければならない。そこに一抹の適当が含まれることで、応用という点から見れば全く意味のない理論を生み出すことになってしまう。なぜシュレーディンガー方程式のポテンシャルは与えられていないのか。それは理論畑の人間にとって、グローバルに応用がきく方程式にローカルな量を入れることは、理論としての意味を無くしてしまう。工学畑の人間にとったら実際に物を作らなければいけないのだから、ポテンシャルの設定は不可欠。そこで事実を曲解した定ポテンシャルなどというものを設定してといてしまうわけだ。その理由が解きやすいとか、コンピュータでやっても時間がかかるからとかきくとほんとに悲しくなる。事実と違う条件を与えて解いたことろで出てきた結果は事実と異なる。これを誤差範囲内の一言で片付けてしまうことは問題だ。既知の情報に満足しては既知の情報をimproveさせる原動力は生まれない。不満足であれ。誰かが言った言葉だ。その通り。
Wick rotation〔ミンコフスキー空間で定義された物理量を、計算しやすくするために時間成分を i（虚数単位）倍して複素平面上における積分の経路を90度回転させることで、ユークリッド空間における計算に帰着させること〕
サーバとして使うなら、消費電力が小さいこと、ファンがないこと、ははずせないと思う。多少性能が弱くても、うるさいと眠れないし、電気のメータが回るのもいやだし。どっちにしてもCPUの空き時間が多いのがサーバの性だから、空き時間を有効に使うという点では性能が弱くてもいい。クロック数あたりの性能が高いほうがいい。
その理由は、Windows Meでも使えること、セットアップしなくても使えること、である。つまり、Windows MeとWindows 2000のマシン間ををUSBメモリなんかに入れて取り回しできるということだ。常に同じ環境で仕事ができるというのはありがたい。昔使ってたteratermはセットアップしないと使えないというわけではなかった。でもそれは推奨された使い方ではなかった。というわけでputtyである。でもこれも問題がある。多分puttyの設定はWindowsのレジストリに書き込まれる(TeraTermはたぶん設定ファイルに保存される)。言い換えれば、他人のマシンで仕事をした場合に誤って設定を保存してしまう恐れがあるということだ。不注意で、ユーザ名とかパスワードが流れる可能性も否定できない。どちらを使うかはユーザの判断である。どちらにしてもセットアップが必要なソフトは好きではない。解凍してすぐ使るとすごく便利なきがするんだけど。仕事の形が旧来の方法に変わってきているのに、いつまでもインストールの概念が抜けきれないのはどうなのかな。
こればかりではない。例えば、自分のマシンに接続されたネットワークアダプタにLINKLOCALアドレス169.254.*.*を割りふった場合、アダプタのポート139番へのアクセスを転送できる。つまり、ネットワークの設定を大枠を変えることなく対処療法できるというわけだ。このためにもputtyは使える。TeraTermにはlocalhostのポート転送はサポートしているようだが、自分の持っているローカルネットワークの任意アドレスのポートへのアクセスをWANのアドレスのあるポートに転送でくるという機能はついていないようである。嘘かもしれないけど。
USBメモリで情報をやり取りする場合、受け渡し用のUSBメモリと、ファイル編集用のメモリは別にするべきである。なぜなら、情報を渡された人が、編集ファイルの過去のデータにアクセスできてしまうからだ。いわゆる消去コマンドはファイルインデックス(ファイル名と情報への道を示した相対表)からファイル名を削除するだけで情報それ自体を削除するわけではないので。ある意味でファイル移動コマンドも注意かも知れない。ファイル移動コマンドはファイル名を書き換えるだけなので。
はっきりいって時間がかかりすぎる。25回の書き込みでは。
XMLとは何なのかということはさておいて、僕が感じたこと。XMLで面白いことができそうな気がする。Webページにラベルをつけて分類するとか。変換の大元の文書として、xmlを使うことはとても意味のあることだと思う。とりあえず、XMLでデータを書いて、XSLで見た目をつくったところまではよかったが、世の中にはxmlとか解さないブラウザもあるわけで、xmlのデータをそのまま表示させるには時期尚早な気がする。仕方ないので、Pure Perlで書かれたXSLTを探すわけだが、どうやら下に挙げたページによれば、Perlモジュールとして使用できるCSLTは3つあり、XML::XSLTはPure Perlなようだ。ためしにiswebに導入してみよう。
cpanからXML::XSLTをダウンロード、解凍、lib/XML/XSLT.pmをアップロード。このモジュールを呼び出すcgiで下の2行のどちらかを書き入れ。
push(@INC,'.'); use lib '.';
走らせるとXML::DOMがないといわれる。さらにXML::DOMをダウンロード、解凍、lib/XML/DOM.pmをアップロード。同様に走らせる。今度はXML::RegExpがないといわれる。同様にlib/XML/RegExp.pmをアップロード。XML::Parserがない。XML::ParserはPurePerlでないのでここで手詰まり。
iswebのサーバのPerlバージョンとOSがわかれば同じ環境を作ってコンパイルする手もあるそうな。どこかに公表されていたかな?iswebは公表してないか。うーん、サービスによっては結構公表しているとこもあるんだけど。しょうがないのでPerlの特殊変数を見る。$^Oがsolarisで$]が5.006002のようだ。solarisといってもいくつも種類があるわけで、どれかなぁ。@INC見る限りi86pc-solarisとあるからx86ファミリ用のSolarisかも。もしisweb動作のためのコンパイル済みのモジュールとかあったら、需要あるかな。XML::Perser使う場合は結構あるわけだし需要あると思いたい。さらにisweb側からしたらどうなんだろう。
iswebのサーバに存在しているperlモジュールはほとんどが使えるようになっているのだけれど、いくつかのモジュールは依存関係が解決されていない。それらは、*.soとか*.pmとかがないよ、と言う単純にどこかからコピーしてくれば何とかなりそうなものや、デバッグオプションつきで起動してますよとか、sendmailが見つかりませんとかだ。
Pure Perlで書かれたXSLTを探していたら、こんなものも見つかった。一通り眺めてみた限りでは動作に必要なパッケージとバージョンがだめなんだよなぁ。結局PurePerlではないのではないだろうかと思ってしまう。
TreePPでxslどこに書けばいいのか。という悩みがあったけれど。結局のところXMLのdocument関数で解決できたのでよし。データ部分はTreePPで操作して、見た目はxslで操作して。データ部分を別のファイルからdocument関数で参照し、そのファイルにXSLも入れておく。これでよいのかもしれない。
アクセス解析用のcgiのデータ構造をxmlに変えてみた。出来たファイルを読み込んで統計処理を行うようなxslがかければ、サーバ側にとってはxmlファイルをダウンロードさせるだけになり、クライアント側で統計処理することになるので、サーバに負荷がかからなくてよい。そんな感じのxslファイルをかければいいね。
サーバ上でのファイル編集が出来ても、ファイル操作が出来ないと色々と面倒である。たとえば、ファイルをコピー、リネーム、ファイルのシンボリックリンク、パーティションの変更、などが出来ないとだめである。シェルの代替になるようなものが無いとね。
フレームワークということで、ファイル操作を行って、この結果を取得して、結果を出力するフレームを作る。
$cmd = 'rename("old","new")';
$ERROR = eval $cmd;
$BODY .= printf("%s : %s", $cmd, $ERROR);