- 追加された行はこのように表示されます。
- 削除された行は
このように表示されます。
!!!2005年03月の駄文
!2005年3月29日……いや、なんかもう…（汗）
最近、なーんかMSNメッセンジャーをオフラインにしておいたはずなのに勝手に「XXXXがログインしました」が出てくると思ったら、'''MSNメッセンジャーってアプリケーション終了させても常駐してやんの！'''
はぁ？もうここまで行くと完璧にスパイウェアの領域ですな。
速攻でタスクマネージャからプロセスを強制終了。
殺したつもりが死んでないアプリってやだなぁ。通信系なら尚更です。
先日から引き続きFSWiki3.5.7のhack。
……ダメだぁ。もうわけがわからん。
どうしてCGIパッケージがフォームのパラメータ取ってくる(param())時にUTF-8だったりEUCだったりするのさ？
ブラウザが悪いって事？
うーん、もう疲れました…。降伏。
CGIのPerlのデバッグって疲れるんだよなぁ何か。
箱庭作っていたときも確かにPerlだったから同じだろうって言われるとそうとしか言いようがないんだけど、パッケージの中とかでガリガリ使われている「オブジェクティブperl」ってヤツ、すごく見にくい。
コードを眺めて右脳で理解できないんだよなぁ…。
perlなんだからそんなにムリしてオブジェクト指向しなくてもいいじゃん！
手続き型でいこうよ、手続き型で！
非オブジェクト言語万歳！！！（←時代に反逆）
ちなみに、箱庭のソースは、上から順番に見ていって、サブルーチンに行って帰ってくるだけなので非常に見やすいです(爆)
オブジェクトはおろかパッケージも使ってないし。なにせperl5.0.xで動くようにできているから……。
私も段々プログラム界では古い人間になりつつあるのかな(悲)
Java箱庭のほうは遅遅として進まず。
やっと「新しい島を作成するルーチン」とか書いている。
今まで終わったのは、
*ユーザ情報をDBとやり取りする部分
*島の情報をDBとやり取りする部分
*島のHEXの情報をDBとやり取りする部分
*島のローカル掲示板の中身をDBとやり取りする部分
*島のオーナー情報とそのユーザ情報を結びつける部分
*島のHEX情報を座標でアクセスするためのラッパー関数群
こんなところか？
これ以上の部分になると、「ゲーム全体の設定パラメータ」が絡んでくる。
すでに「新しい島を作るルーチン」でも必要となってきているのだが、要は「島の縦と横のHEX数はいくつか」とか、そういう情報ってできるだけハードコーティングしたくないじゃん？(横浜弁？)
最終的にはプラグイン方式でコンパイル無しでも地形とかコマンド増やせるようにしたいなーとか考えている。
でも、最初からあんまりやりたいこと欲張るとどんどん完成が遅くなって本人の士気にかかわるので、とりあえず夏までにはWebじょうで曲がりなりにも動かせるものを作りたいなぁ。
仕事でやっている設計だの概要だのってメンドクサイ…じゃなくてキッチリとした作り方に比べたら、こっちなんて本当に日曜大工です。
ま、どっちかというと日曜大工プログラムのほうが好きだからしょうがないのだが…。
----
!2005年3月28日……SPAMとの仁義無き戦い
毎日毎日あまりにも大量のSPAMが来る。
いや、ホームページ自体が大昔からメールアドレスさらし続けなので仕方ないといえば仕方ないのだが。
でも奴等はどうせ名簿屋から買ったリストかロボットででも集めたメールアドレスをメーラーにセットしてボタン一発で後は鼻でもほじってるんだろう。
それを考えるとお世辞にも回線に余裕があるといえないこのサーバでそんなspamを受けてやるのはバカらしくなってきた。
まずは手始めに
/var/qmail/alias/.qmail-default
ファイルに
#
だけ書いて、あて先間違いのメールは全部消滅させる事にした。
だいたいさぁ、このサーバを見てどうして「finance@〜」やら「persident@〜」とか「ceo@〜」とかにメールを出すわけ？
大体が英語SPAMか文字化けしまくって何語か分からないSPAM(多分中国語か韓国語なんだろうな)なんだけど、アホらしい。
次はbsfilterでも仕掛けたいなぁ。
@NIFTYのメールアカウントには「迷惑メール対策機能」みたいなのがついて、Web上から迷惑メールを学習させることができるようになったけど、はっきり言って全然効果ない。
さしあたり、SPAMと判断したメールには題名に[SPAM]という文字を挿入するようにしたのだが、あんまりついていない。
先週あたりまではしゃかりきでWebからSPAMを覚えさせまくったのだが、ダメなのかなぁ…。
商用ISPだから、SPAMを本格的に弾くよりかは、SPAMじゃないメールをSPAMだと判断してしまってユーザからクレームが来るのを恐れているんだろうな。
ま、仕方ないか。
個人的にはもうyahooとかhotmailとか、その手の無料メールプロバイダからは一括してIP接続自体拒否したいぐらいなんだけど、箱庭の参加者もyahooやhotmail経由で問い合わせしてくるからそうもイカンし。
難しい…。
これでSPAM減ってくれれば気分的に助かるんだけど。
----
!2005年3月26日……不二家
ホワイトデーに何がほしい？と嫁さんに聞いておいたら「不二家に行きたい」とのことだったので、遅くなったが関内の不二家に行ってきた。
関内の不二家なんて入ったことなかったな…。港南区日野の不二家にならケーキ食べ放題やっていた時分に行ったことがあるような気がするが。
ホットケーキにカスタードクリームとバナナがのっているのを食べたが、かなりおいしかった。
ホットケーキがかなりおいしい。
侮りがたし。
最近、ホームページのトップをサーバーのトップに一致させようかと思っていまして、そのためにどうせなら何か更新が楽なものにしたいと思った。
ブログ形式のものにしようかとも思ったのだが、私のページには何かと技術的なものも多いのでブログだとまとまったドキュメントを作りづらい。
開発の途中経過とかを載せるのはいいんだけどね。
で、MoveableTypeとかも考えたんだけど、そのためだけにPHPを入れるのも気がひけるので結局wikiにすることに。（古っ）
wikiでもそのためにPHP入れるんだったりJavaが必要だったりするとしんどいので、Perl 100%でできているFSwiki」を選択。
早速ダウンロードしてみたが、ページタイトルに日本語を使うと文字化けすることが判明。
うーん、それは困るなあ…さすがに。
イロイロいじくってみたけど、どうもPerl5.8からのUnicode対応にうまく適合できていないっぽい。
いや、1行目にperl5.6を指すように#!/〜を書いてあげればいいのだけど、パッケージ類が恐らく5.8用になっているだろうから結局変なバグ踏んで悩みそうな気がする。
どうしようか？
徹底的に解析しまくってFSwiki-Perl5.8対応版を作ってしまうか、それとも他のに乗り換えるか？
むむむむ。
徹底的にやるほうはJava箱庭の開発と平行してやるのはちょっとなぁ…。
もう少し突っ込んでみて、ダメそうだったらやめよう。
でも、Perl5.8と5.6で文字列の内部文字コードが違う関係で、wikiで暗号化されたパスワードに互換性がないのがツライ。
どこかにいいwikiスクリプトがないかね？
それとも何か、やっぱり普通にHTML書けって事か?これは。
----
!2005年3月23日……varがあふれております！！
サーバから今朝のdaily checkメールが届いていないので「おや？」と思って調べてみたら、POPがささっていた。
ログインして調べてみたら/varの使用率が109％！
うぞ？！
でもdfとduの結果が違い、さらにファイルを削除しても全然dfの値が減らないことから、ファイルシステムレベルでの問題があることが確定。
fsckかけないと直らないだろうなぁ…。隣のSolaris君はまだ使いこなせていないのでシリアルポートの使い方がまだよく分からず、この状態でFreeBSD側をSingle User Modeに落とすのは危険と判断。
現状Webとdnsとsshは動いているので、とりあえず放置。
仕事が終わって帰宅してからSingle User Modeに落としてfsckします。
Multi user modeで動いているマシンから/var引っこ抜いたらどうなるかな…。やっぱりpanickだろうなぁ。やめた。
早くスタンバイ用のSolaris10を設定終えなければ。
ちなみに、Solaris10で標準でくっついてくるJava環境はTigerだった。
1.4でコンパイルしたclassも1.5で動くのだろうか？動きそうな気もするけど原因不明のバグに悩まされそうだからちゃんとJDK1.4.xをインストールします。はい。
FreeBSD側のは回線が遅いのでもうちょっとお預け。
----
!2005年3月21日……いぬのえいが
見てきました。
出だしがいきなりバカだったので、「終始この調子かなぁ…」とか思っていたら、結構まともだった。
それどころか、中村獅童がいい味だしていた。
結構オススメかも。
でも、この映画の良さと言うか共感どころは犬を飼ったことがないとイマイチピンとこないかもしれない。
私も飼ったことないけどさ。
----
!2005年3月20日……F1マレーシア戦
観に行って来ました！！今帰ってきました！！
……ウソに決まってるだろう、ウソに。
琢磨は熱が出てドクターストップ。うーん残念。
でもF1はシビアなので無理して出場して怪我したりさせたりするよりかはいいのかもしれないけど、やっぱりファンの本音としては残念だ。
次回に期待。
前回のオーストラリア戦を見逃したのでちゃんと把握していなかったのだが、今年からエンジンの交換だけでなくタイヤの交換も禁止になったんだね。
予選開始以降のセッティングの変更もウイングの角度調整ぐらいで、あとは基本的に「壊れるまで触っちゃダメ」らしい。
'''まじっすか？？'''
ピットでの芸術的なタイヤ交換や、解説者の解説ナシにはわからないほどの微妙なセッティング変更とか、なくなっちゃうわけですか？
実際なくなってたけど。
ホンダはエンジン火噴いて2台とも3周でリタイアしちゃうし、だれかは後輪1つパンクで吹き飛んでからやっと交換だし、後半なんてみんなタイヤが言うこと聞かなくてムリヤリスレスレで押さえ込みながら走っていたのがシロウトの嫁さんでもわかっていたし。
あそこまでやるともう既に危険なんじゃないのか？
コーナーで鬩ぎ合いして、ギリギリでブレーキ踏んだけどリアが流れてアウト側の車巻き込んでクラッシュって場面が3回ぐらいあったし。
13台しか完走できなかったって、いくら熱帯のマレーシアでもつぶれすぎでしょう。
選手に怪我がなかったからいいようなものの、誰か死んじゃう前にタイヤ交換だけは再開させてあげてほしいなぁ。
見ているほうも心臓に悪いっす。
最後に、トヨタが2位入賞と言うことで。ばんざーい！！
----
!2005年3月16日……今日の箱庭開発日記
書き終わってから読み返してみると、今日の日記は実につまらないかも。
まあ、本人の備忘録も兼ねているので許しておくれ。
帰ってきて張り切って今日もhibernateと格闘。
今日の課題：
'''1)一つの島レコードに対して複数のユーザーレコードを関連付けられるか？'''
具体的には、オーナーとサブオーナーという形で2人分のレコードが1つの島に関連付けられる
'''2)1つの島に対して他レコードからの複数のレコードの集合をどのように割り当てるか？'''
「島のローカル掲示板」とか「実行待ちのコマンド」とか、その手の集合がこのゲームには結構多い。これがhibernateの機能で実装可能でないとhibernateを使う意味があんまりない。
ってなわけで、まずは1番から。
結論を言うと「全然可能」。
単にオーナーのgetterの所のXDoclet記述と、メソッドの始まりの間に余計なコメント行がはさまっていたのが敗因。
XDocletとメソッドの開始行はしっかりと隣り合わせに記述しましょう。
次に、2番。
こっちはちょっと厄介。
というか「one-to-many」とかそういうのがキチンと理解できれば大丈夫ならしい。
例えば、「島テーブル：オーナー」と「ユーザ」の関係は、島テーブル側から見たら「many-to-one」。
ただし、「島テーブル：オーナー」には「重複禁止」のインデックスを付けているので実質的には「one-to-one」なのかも。でも「ユーザ」側から見て島は一意で決まらないのでやっぱり「many-to-one」でいいみたい。
データベースの標準的な例題で言えば「島：オーナー」は「発注テーブルの品目コード」にあたり、「ユーザ」は「商品マスター」にあたる。
一方、「島テーブル：ローカル掲示板」と「掲示板詳細」は「発注テーブル」と「発注詳細」にあたるのかな？
ってなわけで、「親子関係」なので島テーブルから見て「one-to-many」関係ということが判明。
とりあえず島テーブル側のインターフェースを「Set」で設定して読み書きテストを行ってみたら、とりあえずうまくいった。
意外に簡単？
でもこのままだとせっかくローカル掲示板詳細の中に「（島の中での）投稿番号」フィールドを持っているのに、Setは順番を保証しないから自前でソートしてやらないとならない。
それはやっぱり悲しいので、受け側のインターフェースがListになるように書き換えてやらにゃならん。
今夜はこの辺で遅くなってしまったので、続きはまた明日。
今日の感想。
島テーブルの読み書きテストでどうしてもConstrain Volutionが出ると思ったら、テストパターンの中で島レコードに登録されているユーザをユーザから削除してしまっていたことが判明！
なんだぁ、JUnitのTestCase#setUp()／tearDown()ってテストごとに呼び出されるんだね…。今気がついた。
ついでに、TestCaseオブジェクト自体もテスト毎に毎回newされているらしく、TestCase内で宣言したprivate変数すらキープされない！！がーん。
あー、なんつうこっちゃ…。
もうちょっとJUnitの勉強をせねば…。
あと、未だに島レコードのファクトリが作れていないのがつらい。今のところ島レコードは島レコード.setXXXXX(hogehoge)の嵐！
見づらいし、書くのしんどいし。
でも島を「新規作成」するルーチンってゲーム的なパラメータがいっぱいかかわってきちゃうから、その部分も作ってやらないとならない。
そっちのほうがめんどくさいし、エイヤで作ってしまうと後で一番泣きを見そうなパートなので、とりあえずデータアクセス周りがもうちょっと固まってからだね。
ゲームパラメータとデータアクセスと島ファクトリを完全に分離できないと結局あとから大工事が必要になりそうなので。
ちなみに、今日の悩みでもあった「参照されているユーザレコードの前に島レコードを削除すること」みたいな整合性に関する制約の解決はデータアクセスの上のレイヤーのルールプロセッサにお任せすることにします。はい。
とりあえず今はDBが言うこと聞いてくれるようになるのが先決です。
----
!2005年3月15日……ちょっと挫折＆いじくり
Java箱庭のHibernateの「関連」でちょっと挫折気味。
User部分はうまく行ったんだけど、Islandまわりでどうもよくわからない。
いや、根本原因はHibernateではなく、私自身が「関連」というものをよく理解していないからなのだが…。
many-to-oneとかone-to-manyとかone-to-oneとかmany-to-manyだとか、本当にわけわからん！
うがががが！！
おまけに、Islandの中で島のメインのオーナーとサブのオーナーを定義して、それぞれUserテーブルから参照させているのだが、どういうわけだかサブオーナーしか参照してくれない。
テーブルの中の2つの要素が同じ外部テーブルの別のレコードを参照しちゃイカンのか？？
そんなわけないよな。
XDocletの書き方が悪いんだと思いたいが、スキーマエクスポートのCREATE関係のSQLの中にも「オーナー」という文字が出てこないのはどういうわけだ？
じつはXDocletのバグ？？
いや、この程度なら誰かとっくに気がついているだろう。
明日はIslandの変わりにダミーのテーブルを使ってもう一回検証。
あっちこっちのSite見てみたけど、結局みんな「既にわかりきっちゃっていることだから省略しまくり」か「わかんないから英語の手引き棒約」のどっちか。
あーうー。もうちょっとほかの人がわかりやすく書いてくれよ〜なんて贅沢なお願いをしてしまう今日この頃。
でもHibernateとXDocletが使いこなせれば結構便利そうだな。
XDocletでResourceBundleの.propertiesファイルも作成する方法見つけたし。
これは便利そう。早速使おう。
久々にApacheにも手を入れて、AddOutputFilter DEFLATEを加えました。
htmlにしかかけていませんが、日記とか掲示板とかテキスト中心なサイトなのでこれで結構加速されたかな？
ついでにGIFも圧縮したほうがいいのかな？GIFは元々圧縮されているんだっけか？jpgは圧縮済みなのは覚えていたけど。
さらに、ネットワークインターフェースにコリジョンがすさまじい勢いで出ていたので、mediaoptでfull-duplexを強制。
これで収まらなければNICかダイアルアップルーターのどっちかが壊れている。
ここまできてダイアルアップルーター探すのは辛すぎるな。売ってないかもしれない。
そうなるといよいよ前職で拾ってきたCiscoの出番か？？
むむむむ。
----
!2005年3月10日……何か最近更新が隔日になっている？
ケーブルテレビの続報。
果たして次の朝にケーブルテレビ会社から電話があり、営業時間外だけど今日の夜私が仕事を終えて帰宅してから対応してくれるとの事。
仕事を定時で切り上げてさっさと帰宅する。
チューナーをつけてもう一回電話で状況を確認され、向こうからもう一度契約情報を送信してくれたらしい。
今度は写るようになった。
結局契約情報がうまくケーブルを流れてこなかっただけなのね。ふーん。
嫁さんは早速アニメチャンネル見ています。
タイムボカンとかプラレス三四郎とかやっていて面白い。
タイムボカンなんて今でも通用するバカらしさだよな〜。展開は毎回同じだから「水戸黄門」と言ってしまっても差し支えないだろうけど、それだけに妙な詮索や勘ぐりをしないでも手放しで笑える。
それにキャラがよろしい。今のただ絵的に萌え萌えなだけのキャラと違って「個性」が立ってるよな。
ネタなしついでに、Java Servlet版の箱庭ですが、わけあってもう一度作り直しています。
ごめんなさい。どうしても納得いかなかったもので…。
いや、実際は作りが悪すぎて時間が開いたら思い出せなくなったというところか。
今仕事で「仕様」とか「設計」とかもう一度勉強しなおしているのでそれを生かしてもう一度作ってみてます。
でも結局ドキュメントは作らないでコメントとjavadocに頼りっきりなんだけどね。
作り直しは「データ回りをちゃんと作ろう」という方針で、データのコア部分から。
Hibernateを使ってDBとアクセスし、アクセスクラスはちゃんと作るそばからJUnitでTestCase作りながら確かめていく。
何か仕事よりも丁寧にテストやっているような…。
もう一つ方針として、「できるところまで個々のクラスは単独でテスト可能にする」ということにした。
前の敗因の一つとして、TomcatにHibernateのSessionFactory持たせちゃったり、TomcatのSessionにオブジェクトが乗っている事を前提にしたクラスとかが多すぎてTomcatが立ち上がっていないとデバッグもできない状態だったのだ。
ちょっといくら設計を甘くしているとはいえ、これは劇甘を通り越して論外だったかな。
思想的に。
ま、でも、今日まででユーザ登録、検索、削除までのアクセスクラスはできたので寝るか。
----
!2005年3月8日……ケーブルテレビ映らず
CSだけなんだけどさ、でもコレが見たくて買ったわけだから…。
今日仕事から帰ってきてからケーブルテレビ局のフリーダイアルにかけてみた。
夜間担当の兄ちゃんが出て、たどたどしいながらも結構丁寧に対応して調べてくれた。
でも多分、機械方面の初期対応のための係りなんだろうな。
結局機械が悪そうなんじゃなくて契約方面の話みたいだから、「昼の担当の人」から明日電話があるそうだ。
CS放送は明日までお預け！
チャンチャン。
----
!2005年3月7日……配線天国
ウチの地域のケーブルテレビのデジタルチューナーが届きまして、早速取り付け工事しました。
……業者に頼むわけないじゃないですか。自前ですよ、自前。
テレビ回りの配線で1万円も取られてたまりますか。
っつうかですね、ウチのテレビの周りはすごいことになってしまっているので普通の人じゃ配線無理でしょう。
テレビ、ビデオ、WOWOWのデコーダー、ケーブルテレビのチューナー。
この4台をどれもちゃんとテレビに映せて、かつ地上波もケーブルテレビもWOWOWもビデオに録画できるようにしました。
もう一回やれと言われてもすぐには思い出せないかも。
本当はケーブルテレビでWOWOW見ることもできるんだけど、デジタルになっちゃうから視聴料が300円高くなるし、ということで嫁さん判断で申し込まなかったみたい。
（いや、そもそも今回のケーブルテレビのデジタル化は嫁さんがアニメチャンネルを見たいからというのが主な理由なんだけどさ。お任せにしてました。）
ついでといっては何だけどデジタルチューナーのおかげで地上波デジタルも見れるようになった。
今のところほとんど地上波アナログと変わらない放送内容な気がするけど。
でもチューナー側で「電子番組表」を参照できるのはいいね！便利です。
最後に1つだけ難を言うと、デジタルチューナーを通して見た画像は、テレビ（モニター）の都合で、一回り縮小されちゃうことかな。
どうも、放送側で横長画像の左右に黒の空白を入れて放送しているらしく、今のテレビだと画面左右の余白を画面外に切り捨てて画像を拡大するような機能がないのだ。
横長画面（シアターサイズ？）は左右切れないで見えるんだけど今度は上下に結構余白ができてもったいない。
うーん、新しいテレビ買えってことか？
（去年直したばっかりだからまだ買わないけど。）
----
!2005年3月2日……あ、そうか。
プログラマとかSEって「人間とコンピュータの通訳」なんだ。
そうかそうか。
でも多分人間のほうが実は物分りが悪い。
今、Javaを開発言語としてドキュメント作成のトレーニングをしておりますが、元々プログラム作るのが好きでプログラムやり始めた私にしてみると、設計とかやるよりもとにかく作ってしまった方が良くわかる！！ってことは多いんだけど、チーム作業ともなるとそうは行かないんだよ。
UMLとかXPだとか色々あるけど、結局あれはコンピュータに物を教え込むためじゃなくて、ユーザとプログラマの間で意思の疎通をはかるためのもの。
つまり、Aさんが書いた設計図でBさんにでもちゃんとAさんが意図したものを作れるようにするためのテクニック。
……そう考えるとプログラマーの世界って世の中のほかの技術より遅れているよな…。少なくとも「製造業」としては。
それから、プログラム言語とかOSとかプラットフォームって「文化」じゃなくて「宗教」なんだよね、結局。
今は大体どんな言語使って、どんなOSでどんなマシンでもやれることは大体同じ。
手間がかかるかからないというのも多少はあるけど、昔みたいに「CADはSGIじゃないと話にならない」とかそういうカテゴリー分けは成り立たない。
なんせできることはほとんど同じなんだから。
それよりも、OSやプラットフォームや開発言語選ぶ理由って、
「前のがそれで動いてたから」とか「こっちの方が扱いが慣れているから」「いいような気がするから」って程度じゃない？
さすがにドライバ書いたりするのをBASICでやろうとかいうチャレンジャーはいないだろうけど、Javaとか.NET程度ならどれも大体同じ。
「親が●●教信者だったから私も●●教信者です」っていうのと変わらなくないか？
本当の合理性や論理性に基づいてOSやプラットフォームや開発言語選ぶって事をしなければ、結局それは宗教と変わらないんだよ。
「Java信者」「.NET信者」「Windows信者」「Mac信者」
そうか、だからコンピュータメーカーはシェアとかを気にするのか。
結論、プログラマーは布教活動家である(笑)