2002 年 7 月の日記

今日から netfilter のお仕事が真面目に開始。んでも、開発水曜日までなのですが。

明日は仕事終わってから打ち合わせだし、明後日は BSD BOF だし。終わるのかぁ～?

引き続きお仕事。お仕事。お仕事……うがー。

du -sk でざっくり。182,654KB と出ました。で、何か?

du -sk * | sort -nr | less してみました。大きなものは images、files、binaries と順当な辺り。

本当に大きいのは RFC とか HTML 4 Spec. とか CSS2 Spec. などのミラーだったりするけど。これらはサイト内サーチを使わないと見つからなかったり。

今日は BSD BOF なので、とりあえず幕張へ。

ま、ここでも仕事ですが。

無線 LAN でサクサク繋がるのがいいですね～。IPv6 も使えるし。

3ffe::/16 なアドレスを持ったまま rtsol してたせいで、外部へ繋がらなかったのがちょっと悲しかったです。;)

朝から朝まで (謎無)。

今日も朝から朝まで (謎無)。

微妙に昼からかも……。

平日全くできなかったので、ただひたすらにやってみる。

とりあえず、イヤリング、猫耳 2 つをゲットできたので良し。その日の間に全部あげたけど。(^^;

グローブ 2 つを外して銀の指輪 2 つを着けるのはもったいないかなぁ。まぁ、グローブ 2 つも格安で知人に売り払ったので、もう装備は帰られないけど。;)

行動不能。どうにもなりません。

行動不能。さらにどうにもなりません。

Amaya 6.2 がリリースされました。国際化が施され、いくつかのエンコーディングへの対応が追加されたようです。

ということで、試さねば。

駄目過ぎ。以上。(お

せめて日本語フォントをレンダリングさせる方法だけでもわかれば……。

Amaya のソースはアレなので、当然ソースを書き換える、というのも却下です。Mozilla のソースが綺麗に見えるくらいってのは、もはや (略)。

火曜日に、無理に会社に行ったからか、調子が悪いけど早退せずに定時の間居たから、どうにも駄目。

ぶっ倒れスタート。

ぶっ倒れ継続。

ぶっ倒れ継続。

ぶっ倒れ継続。

かなり良くなったけど、とりあえず休んでおく。

明日は会社行けそう。

7 月末で今の出向先が契約終了決定とのこと。ま、倒れてほぼ一週間出勤できないのでは当たり前ですね。

しかし、最初の 1 週間で残業 40 時間弱に達しているって、ちと殺人的 (汗)。

BSD BOF や打ち合わせがなかったら、もう 15 時間位作業時間増えていたかも、と考えるとかなり怖い状況だった気がしないでもないかも。

世のプログラマさんってこんな過酷な仕事してたのでしょうか。カルチャーショック (謎)。

次は週残業 20 時間以内なところがいいな。というか、せめてゆっくり睡眠時間が取れる位で。

今回のこれは、今の出向先でも例外的なものであったと考えたいのですけど、どうなのでしょう。>該当者 (誰)

睡眠周期がぐちゃぐちゃになったせいか、布団に入っても 1 時間以上眠れなかったり、妙な時間に突然眠くなったりと、まだ影響が残っているっぽい。

胃の調子はかなり回復。痛みを覚えることもほぼなくなりました。まだちょっと、たまに胃薬で散らしたり。

昼を食べたときは、普通の食べ物食べたのが久しぶりだったせいか、異常に食べにくいというのはあったものの、なんとか食べ終えられたし、吐気もしないのでそろそろ大丈夫かな。

ということで、大丈夫です。メールで返事できなくてごめんなさい。>両親

仕事が終わる少し前に強めの痛みを覚えてかなり辛くなってみる追試発生。

急いで定時で帰って薬を飲んで寝てみたものの、なかなか収まらず。

食事しないと駄目だ、と無理に食べたのが駄目だったのかもしれないなぁ。

痛みで目が覚めたりしてしまうので、どうにもならないのでどうにかしてみた (謎)。

案の定副作用で行動不能に陥ってみたり。

お医者さんや製薬会社さんの言うことはしっかり聞きましょう (謎無)。

今回のは、過酷なスケジュールってよりも、昨日の打ち合わせでの心因性の部分も大きいかも (謎)。

今の出向先の状態としては、チームの性格的に無茶なスケジュールになりやすいというのもあるので、本来あるべき姿である定時内で綺麗に収まるスケジューリングはほぼ不可能というのがあるかと思います。

たまに、残業しないとどうにもならない、という事がある、というのは理解できますが、定常的に残業がある、というよりも残業しないとどうにもならない、というのは人数対業務量としては、ちょっと多すぎるのではないでしょうか。

企業的には業績を右肩上がりにしていきたい、というのは当然の事なので理解できますが、規模に見合わない膨張は破綻の原因になるのではないでしょうか。

一応大丈夫そうなので、ごー。

食事は摂れないっぽいので、当分ゼリーとかで生活かな。

ようやく取り掛かれそうなので、とりあえず全体の内容を決めにかかってみるテスト。

自分で書いてみてなんだけど、方向性が、多分違ってる気がする。

最終的な方向性は良さそうだけど、どうかな。

というか、シリーズ化して分けるっていうのは微妙微妙。

内容的には、分けるのも手なのかな、と思い始めてみたものの、分量が洒落にならない予感。

まぁ、でも、それもいいかな、と思ってみたり。

一番の問題は、旗を振っている人間が全然分かっていないっていうところにあるのではないでしょうか。

正直、悲観的になる理由がわかりません。

SMTP Authentication を有効にすることで、spam の踏み台になることは避けられるのではないでしょうか。

詐称は当然ながら、SMTP Authentication 使って防げるものではないですが。;-( この場合は別ネットワークから送られるでしょうから、別問題となります。

mod_gzip が有効な場合、HTTP 応答ヘッダの Server フィールドは Server: Apache/1.3.26 (Unix) mod_perl/1.26 mod_gzip/1.3.19.1a の様に変化するはずです。

httpd.conf で、LoadModule と AddModule を確認してみるとか。

敢えて非出力にしてたら別ですか。;)

あと、mod_gzip は 20KB 前後を境にリソースが大きい場合にだけ自動圧縮するとか、そんな感じだったと記憶しています。

ですから、テストにあまり小さな文書を使っても圧縮がかからない可能性もあります。

デファクトスタンダードは、果たして確立しているのでしょうか?

一般の方が HTML を自ら記述する様なヘビーユーザよりも、オーサリングツールを利用して作成している人の方が、私には圧倒的に多いと考えています。

そうしたオーサリングツールメーカがまともなものを揃えてくることで、大勢は容易に変わると考えています。

もっとも、オーサリングツールメーカがそう簡単に今の実装を捨てるとも思っていませんが。

アプリケーション開発者的な面からすると、実際現状は悪いことだらけで良いことは一切ありません。

しかし、それはパーサ開発者からの話であり、リソースを出力する Web アプリケーション開発者やオーサリングツール開発者が、まともなリソースを出力することが大変だと思い込んでいる、という点はあるかと思います。

実際、Mozilla Composer なども、劣悪限りない Netscape Composer のユーザインタフェースを継承している為、概念的にまともなリソースを作ること自体が困難となっています。

無理だ、と努力放棄をした時点で、可能性は 0 になると思っています。

思想的に Strict な文書の作成を、というのは地道な啓発により進めていくしか無いでしょうし、これに関しては一気に変わるようなことはあり得ない、と思っています。

しかし、XHTML による、少なくとも仕様に沿った文書の作成、というのは可能な範囲だと思っています。これは、invalid な文書の parsing に関して Microsoft でさえ音を上げたという事からも、限界に来ているというのは想像に難くないことです。

データ形式として不正なデータに存在価値はないという、単純にして当たり前の事さえ守れないような物は、一掃されてしかるべきものです。そうしたツールを作成する企業 (作者) に対してのアクション次第ではないでしょうか。

少なくとも、Web 標準化プロジェクトに関しては、旗を振っていた人自体が Web 標準化とはどういった事なのかを全く理解していなかった事から、少なくとも看板に偽りがあったことは間違いありません。あの活動を通して、Web 標準化は無理と考えるのは早計でしょう。というか、無理です。

あの活動は、間違いなく Mozilla で利用可能なサイトを増やすという一点にのみ注力が置かれていて、その活動範囲も非常に限定的でした。

また、活動の結果は結局のところ Mozilla で動作したらいいという範囲でしか無かった、と言い切ることができるでしょう。

Web を利用する方にとっては、結局のところ重要なのは、Web によるサービスの享受と情報の入手が重要な点です。これらを利用する側に関しては Web 標準について理解してもらう必要などは全くありません。

これらを提供する側に対し、如何に Web 標準の重要性を理解してもらうか、という点を考えるべきではないでしょうか。

こうした点を考えても、もじら組主体の Web 標準化プロジェクトはWeb 標準化という観点からは無駄だった、と言うことは可能かと思います。

私個人としては、一応今後何かしらの行動を行う予定です。まぁ、アレ (謎) です。

まともな文書ツリーを構成できない文書に対してスタイルシートを適用しようとしても、まともな文書ツリーが構成できない以上、まともに適用できるわけがありません。

CSS をまともに使いたければ、少なくとも文法上正しくマークアップされる必要があるのは自明のことで、CSS の仕様は、これが前提として成り立っています。

壊れたデータに対して、さらに加工しようとしても駄目なものは駄目、となるのは当たり前のことで。

ところで HTML 3.2 で十分という人は、本当に HTML 3.2 に従っていますか?

日本語の文章を記述しようと思ったら、ローマ字で記述するしか無いと思うのですが。

おぉ、まともな管理してますね。それが普通か (汗)。

pos.to のサーバは、/usr/local/apache/conf に行けば普通に見えました。……まぁ、それはそれでいいと思いますが。

そこから log の位置を探して定時的にアクセスログから www.ancientlibrary.net のログだけ引っ張り出してアクセスログを作り直していたのは、懐かしい思い出。もうやる気しません。(ぷ

Strict な思想とか、そんなのではなく、単に仕様に沿った HTML を記述することでしかないのに、なぜか蔑ろにされています。

メールで Message-Id をまともに出力しないだけであれだけ叩かれるにも関わらず、HTML で文法がおかしくても気にされない。こうした風潮から変えていかないと駄目なのではないでしょうか。

ちなみに Microsoft が腐ったデータに音を上げた事から parse error を出すようになったのは XML 対応回りから。もうこれ以上、腐ったデータを強引に復旧してレンダリングするのは止めさせてくれ、という意思表示に他なりません。

元々エラー回復してなんとかレンダリングする、という仕様をエラー表示おっけーにしてくれ、と仕様を変えてもらったのは Microsoft だそうですし。;)

これ読んでる方で、HTML に仕様が存在することを知らない、という人は居ないと思いますが、それでも特定 UA でレンダリングされればおっけーという考えの方は、せめて W3C Spec. に従った形式で書くようにして頂きたいものです。

日記スクリプトが出す HTML ががが、という方は、使用しているスクリプトの作者さんに働き掛けるだけでもいいかと思います。

とりあえず、試しに作業環境にだけ入れてみました。

Perl 5.8 な機能のテストはこれから。

文字を大きくしたいとか、色を変えたいとか、そういう需要は文字を大きくする、色を変えるのは何の為なのかという点を考えたらすぐに分かる気もするのですが。それさえ理解できないほど理解能力が無いとしたら、その程度の事さえ理解できないような人の文書など読む価値は無いと思えますが。その程度の理解能力の人がまともな文章を書けるとは考えにくいですし。

blockquote 要素を挿入するためのボタンに引用と書かれていて、その結果インデント付きで表示されたとしても、少なくともインデントとボタンに書かれていて blockquote 要素が挿入されるよりも間違いなく良い事ですし、利用者は blockquote 要素をインデントの為に利用していることを、目的のために手段を選ばない誤用である、と認識することができるでしょう。

現在のオーサリングツールでは、駄目なものはインデントボタンで ul 要素や blockquote 要素を挿入したりします。これでは HTML のソースを理解できないユーザが誤用している事を認識すること自体困難でしょう。

WISYWIG 系のものでも Word の様な設計であれば、ある程度まともなものは作成可能な筈です。実際、Word では文書構造とスタイル定義は分かれていて、さらに部分毎にスタイル変更が可能になっている、という実装です。Word の問題は、それにも関わらず腐ったデータを出力する点にありますが……。

見出しだから文字を大きくしたい、色を変えたい、というのであれば、見出しに対してそうしたスタイルを適用し、該当の部分を見出しとしたらいいだけです。

強調したいから文字を大きくしたい、色を変えたい、というのであれば、強調部分に対してそうしたスタイルを適用し、該当の部分を強調としたらいいだけです。

強調部分毎に文字の大きさや色を変えたい、というのであれば、オーサリングツールが個別に ID を振って、それに対してスタイルを適用したらいいだけの話です。

現在のオーサリングツールでは、ユーザが仕様に沿った意味を割り当てること自体ができないような作りになっている場合もありますし、標準でツールバーに出てくるボタンには視覚表現的なボタンだけが並び、論理的表現をマークアップする為にはメニューの深い階層から選ばないと駄目だったり、下手をするとインタフェース自体が用意されていない、などという場合があります。

一般ユーザの目に触れる部分こそが全てと考えるのであれば、視覚的な表現に偏ったオーサリングツールしか存在しない状態では、当然の様にユーザはその様なものなのだ、と HTML を認識するのは当たり前のことです。

私は、インデントを行いたいだけなのに、なぜ引用を利用しなければならないのだろうという疑問をユーザが持つことができれば、意味を基にマーク付けしようと考えてくれるきっかけになる可能性は十分に考えられると思います。

そうした疑問を持つ機会を奪い、ユーザに意識させずに誤ったマークアップの文書を作成してしまうオーサリングツールには、多大な罪があるでしょう。

ユーザに対し、正しい意味でマークアップしてくれと言うのは、それが容易にできる環境が整ってからなのではないでしょうか。

出ました。

今回は早紗らしい。

そもそもでかいテーブルを作る、という場合自体が考えにくかったり。

大抵のテーブルレイアウトは、昔の経験 (謎) により手でサクサク作っても大して時間に差が無いので、あまりメリットがありません。

……え、コンシューマ向けの話ですか? テーブルレイアウトを捨てたら問題ない話でしょう?(ぴゅあ)

久しぶりに秋葉原に買い出し。

今更だけど O'REILLY の Perl & XML とか買ってきてみたり。洋書版。

Beatmania II DX 6th (PS2) と専用コントローラを買ってきてみたり。コントローラでかいです。とりあえず、7 鍵練習。

秋葉で手短に買い物を済ませた後、いつも通りの上野燔楽。かし支障とともに、久しぶりに心行くまでしゃぶしゃぶ分 (謎) を補給。

ちょっと早めにスタートしたものの、定時 (何時) に差し掛かったところでエンカウント発生。やはり週末は遭遇率高いですか。CBUG とかで宴会をやってたり、何かイベント (花火?) があったみたいだから、確率は落ちると思っていたのに。

とりあえず、指にキーの位置を覚えさせるためにビギナーモードで一通り最初からプレイできる曲を練習。

これのレベル表示、昔の Beatmania と比べると、非常に納得いかない気がするのは気のせいですか?

ほぼ数年まともに Beatmania をやってない身には、LIGHT 7 の Lv3 でもかなりきついんですが。というか、Lv3 で 1 曲クリアできません。練習あるのみですか。

当然、Lv4 な曲は全然ダメダメ。話になりません。

これは DRILL mode で練習してからやれってことかな～。

DDRMAX は MAX300 が B、SO DEEP が A で、他は全部 AA になってるのだけど。やっぱ下から上に上ってこないとダメですか (違)。

レベル表記が納得行かないというのは、昔の Beatmania の 6 位が、2 とか 3 とか位の扱いになってる気が、という辺りです。

基準は何～、というのが。

ディスプレイにちょっとだけビールを飲ませてしまって 2nd ディスプレイが死んでみたり……。

窓を開けて乾燥するようにして会社に行ったら、戻ってきてから電源を入れてみたら問題なく映ったので代替ディスプレイの購入はなし。

ケーブル接触が怪しいから、買い換えないと駄目なんだろうけど。6 年選手だからか、映るまでの時間も結構かかるし、新しいディスプレイと比較すると発色も暗いし……。

概要案をまとめてみる……zzz。

大変お世話になりました。>該当者 (誰)