ちゃたろう日記－ちゃたろうふぁんくらぶ

今年はいろいろあった．

なんだか普通の5年分ぐらいあった気がする．もはや訳が分からなかった．
今年の新年の総括をしようにも，あまりにもかけ離れすぎて話がつながらない．
もはや社会の変化に自分の変化が追いついていないのか？

今日は普通？　の年越．
どぶろくを送ってきてあって飲んだのだが，うまかった．何かの機会があったらまた買おうと思う．

紅白も一部見たよ．ドリカムは仕事人だと思った．
最近の子供は青函連絡船を知らないだろうが，津軽海峡冬景色をどう聞くのか，微妙に気になった．

■ おいおい ■
day : 2007/12/29 url : https://old.chatarou.net/diary/200712.html#29 0歳児って納豆くうんかよ．ビックリだわ．

■ 双日て ■
day : 2007/12/27 url : https://old.chatarou.net/diary/200712.html#27 借りてるレンタルサーバの会社，さくらインターネットが債務超過で困ってると言う話だったんだけど．さくらインターネット，双日が救済へ …双日かあ．大手なのはいいけど悩ましいなあ．

■ 惜しかったね ■

day : 2007/12/26 url : https://old.chatarou.net/diary/200712.html#26

週末はイロイロ惜しかった．
偶々テレビをつけたら高校駅伝をやっていたので，思わず見てしまった．
最後の最後まで微妙だったけど，結局，仙台育英が勝った．
けど，外人選手入ってるのってひどくない？　とか，やっぱ長聖って微妙に高地トレーニングの成果が入っているんだろうか(凄い贔屓しまくり)とか思ってしまった．
まあ残念ながら高校駅伝ではまたもや勝てなかったけど，長聖出身の大学生って今や箱根の花形なんだよね．まだ高崎(え，前橋か？　やっぱ高崎だよね笑)の花形になった選手は聞いた事がないけど，そんな風になる選手が出てくるのも近い先なんだろうねえ．

今回負けた方も，それを糧に次回を目指し，そして勝って欲しい物だ，とつくづく思いました(ここだけ一般論に拡張)．

はてさて，週末の間にuser_prefsをいじったついでに，と言うか共連れでサイトのプログラムにも若干の修正を加えた．
Jcode関連の修正．
大雑把に言うと，コンピュータが使う日本語には何種類かあって(JISとかShift-JISとかEUCとかUTF-8とか)，それらの間の変換をするのにPerlでは昔からjcode.plと言うライブラリがデファクトスタンダードで使われていた．このサイトを作った頃ももちろん，そう．
でも，Perlも進化するもので，当時はPerl4だったような気がするけど，今はPerl5が主流で，pl(Perlのlibrary)だったものが今ではpm(Perlのmodule)が標準になっている．
で，今はjcode.plは主流ではなく，それをmodule化したJcode.pmが標準にとって変わりつつある(いや，今やJcode.pmすらEncode.pmのWrapperであるけど)．
なので，一部サイト内で使っているjcode.plをpm置き換え処理を行った．

なんでこれが共連れかと言うと，サイト内でPerlからsmtpを叩いてメールを送る処理を実装しているところがあるんだけど，今までは何も考えずにShift-JISで送っていたんだが，実はメールのbodyは本来JISで送らないと怒られるらしいから．で，その処理を書こうと思ったら，やっぱjcodeか…いやあ，今だったらJcodeだよなあ…とかなって，そう言えば他にもjcode.plの所が残っているよなあ…とか波及してしまった訳だ．
まあそうは言えどもjcodeを使っているプログラムは実にたくさん動いていて(Grepしたら50件ぐらい出てきて『そんなに動いてるのかよっっ』と突っ込みたくなった)，一部だけ最新に置き換えても骨格が古いままだからうまく動かないよおとか，Jcode.pmとEncode.pmどっちを使った方がいいんだ？(Jcodeを使うかEncodeを使うかで処理速度に差が出るらしい)とかイロイロ出てきて，まあ一部だけ刷新して古いものもいっぱい引きずったままで，…とか相変わらずベータに終わってしまった．
まあメール送信部分だけは最新に置き換えたので，バッチリ，スコアが下がりました．せっかくなので，今回はSubjectもISO-2022-JPでエンコードしてあげるよう処理を変えてあげましたとさ．めでたしめでたし？

■ user_prefs その2 ■

day : 2007/12/21 url : https://old.chatarou.net/diary/200712.html#21

前の記事：user_prefsの続編．
最新記事はこちら．

さて，spamassassinのフィルタリングにuser_prefsを導入してしばらくたったんだけど，効率がかなり向上した．自分の手元にspam(迷惑メール)がham(迷惑でないメールとご認識)として落ちてくることはほとんどなくなった．
が，逆の大問題も若干発生．閾値を下げたので，本来hamのメールをspamとして認識してしまう事例が増えた．これは当初から懸念していたことではあるのだが，困ったことである．

一般的にはspamフィルタリングのミスと言うのは2通りあって，
　　(A) spamをhamと見なす
　　(B) hamをspamと見なす
で，(A)よりも(B)を重大な問題として捉えるべきだ，と言う考え方が標準的だ．
稀に間違って迷惑メールが届いちゃうケースは腹立つけどしょうがないじゃん．でも，迷惑でないメールが受信できていないと，迷惑メールに埋もれた中から探すハメになり，分別している意味が全然ないじゃんよ，と言うお話．

中でも，自分の携帯メールを受信できないのには困った．そこで，spamと判定された携帯メールのヘッダを漁ると，以下の通り判定がされていた．

X-Spam-Status: Yes, score=13.9 required=10.0
X-Spam-Report:
* 7.5 BAYES_99 BODY: Bayesian spam probability is 99 to 100%
* [score: 1.0000]
* -0.1 CONTENT_TYPE_PRESENT exists:Content-Type
* -0.1 ISO2022JP_CHARSET ISO-2022-JP message
* 0.1 JPHANDPHONE Mail from KEITAI
* 0.1 SAKURAWEB Japanese spammer uses footstool web hosting service:*.sakura.ne.jp
* 2.1 RCVD_NUMERIC_HELO Received: contains an IP address used for HELO
* -0.1 ISO2022JP_BODY BODY: ISO-2022-JP message
* 2.2 TVD_SPACE_RATIO BODY: TVD_SPACE_RATIO
* 3.0 KEITAIFROMISP KEITAI mail from ISP
* -0.8 AWL AWL: From: address is in the auto white-list

…まあ，簡単に言えば閾値をデフォルトの13に戻してもダメな訳だ(笑)．

ここで高く判定されている物を分析すると，以下のようなことが分かった．
■BAYES_99 BODY：仕方ない．ちゅうか，携帯からメールを送る時はなるべく情報を減らすから，SUBJECTもBODYも文字削りまくりな訳で．対処不能．
■RCVD_NUMERIC_HELO：これはおかしい．つうか，ここ一ヶ月ほど観察して分かったのだが，「RCVD_NUMERIC_HELO」はほとんどのメールが当てはまる．なぜかと言うと，今はNATで家庭内で別ネットワークを組んでいるケースが多く，内部LANのIPでHELOを叩いたりするケースが多い．すると，あっという間にスコアを上げられてしまう．この判定はそもそも現代のネットワーク事情を考えると，スコアを上げること自体がおかしい．
-2007.12.27追記-
上記表現は若干語弊があった．さくらインターネットの仕様で，「ウイルスメールのチェックを(サーバ側で)する」とすると，サーバ側でFSecureが走るのだが，このウイルススキャンされたメールがなぜかドメイン名ではなくIPアドレス直打ちでメールをピンポンしている．ので，いずれにしてもさくらインターネットでは上記判定条件にスコアを付ける事はナンセンスだ．(もちろん，上記のようなNAT内のアドレスも丸見えになっているのも事実だ．例えば，192.168.0.11がHELOしているメールなど多々ある．)
-End 2007.12.27追記-
■TVD_SPACE_RATIO BODY：これもおかしい．これも上記と同様に，ほとんどのメールが判定を食らってしまう．「TVD_SPACE_RATIO BODY」と言うのは，文章の中にどの位の割合で空白文字が入っているか，を判定しているらしいのだが，英文なら単語の境界がspaceだけど，日本語のメールは基本的にspaceはほとんど使わない．従って日本語環境下では，このスコアを上げることは意味を持たない．
■KEITAIFROMISP：残念ながら，これは仕様だ．メールの通信経路内に「携帯会社」と「SAKURAWEB(とかSONETDYNIP等も)」が同時に含まれると，判定を受けてスコアが上がる．これは世の中的にはアリだが，僕の場合は「出し手→携帯」「受け手→SAKURA」と限定されている特殊環境である以上，判定されてしまっては困る．

等々の結果を受けて，自前のuser_prefsを以下の通りに改変した．
(chatarouの文字列等はspam除けのため若干いじってあります)

include tlec_prefs

#
# more information (default spamassassin rules)
# -- about : http://spamassassin.apache.org/tests_3_2_x.html
#

#
# Obsolete rules The Bat! still exists, so it come back into rules : 2007/12/21 by [chatarou]
#
header USER_AGENT_THEBAT X-Mailer =~ /(The Bat)/
describe USER_AGENT_THEBAT spammer's choice of X-Mailer
score USER_AGENT_THEBAT 7.0

#
# Default domain(_c|h_atarou.sakura.ne.jp) is not used at our mailservice. : 2007/12/21 by [chatarou]
# webmaster@_c|h_atarou.net often used by only spammer... : 2007/12/21 by [chatarou]
#
header ILLEGULAR_CHATAROU_TO To =~ /\@_c|h_atarou\.sakura\.ne\.jp|webmaster\@_c|h_atarou\.net/
describe ILLEGULAR_CHATAROU_TO To: @_c|h_atarou.sakura.ne.jp or webmaster@_c|h_atarou.net
score ILLEGULAR_CHATAROU_TO 7.0

#
# "TVD_SPACE_RATIO" means " eval:tvd_vertical_words('0','10'):Very few space-character used".
# -- This has almost no meanings in Japanese mail. : 2007/12/21 by [chatarou]
# "RCVD_NUMERIC_HELO" means "contains an IP address used for HELO".
# -- This has no meanings in NAT(private address) environments. : 2007/12/21 by [chatarou]
#
score TVD_SPACE_RATIO 0.0
score RCVD_NUMERIC_HELO 0.0

#
# We use SAKURAWEB as SMTP. so the following rule has no meanings. : 2007/12/21 by [chatarou]
#
score KEITAIFROMISP 0.0
score SAKURAWEB 0.0

required_score 10.0

この設定ファイルに差し替えて，再度携帯メールを受信したところ，スコアが6.7まで下がった．と言うことで実用性としてだいぶ妥当に入ったかな．
これでまたしばらくの間様子を見ます．

せっかくメールの話題なので蛇足の話題もいくつか．
【迷惑メールに対する送信認証について】
Gmailのヘッダを見ていて気づいたのだけど，GmailはSPF(IPアドレスによる送信ドメイン認証)の判定をしている．例えばこんな具合．

Received-SPF: pass (google.com: domain of hoge@example.net designates 10.0.0.1 as permitted sender) client-ip=10.0.0.1;
Authentication-Results: mx.google.com; spf=pass (google.com: domain of hoge@example.net designates 10.0.0.1 as permitted sender) smtp.mail=hoge@example.net

ウチのレンタルサーバもSPFの設定(つうてもTEXTレコードを追加するだけだが)をやってあるので，自分のアドレスからメールを送信してもちゃんとSPFをPASSしてくれる．おかげでどこかでspam誤判定を受けるリスクは若干低いわけで，助かった．
-2007.12.27追記-
http://www.chatarou.net/2014/01/29/sakura_spf/で最新の設定を公開．
-2007.12.27追記END-
迷惑メール対策(送信者が誤判定されるのを防ぐ努力)としては，他にも「電子署名方式」と言うのがある(所謂，Domainkeysとか)のだが，残念ながらこっちは署名を受けてくれるサーバが別途必要になるので，簡単に構築はできない．

迷惑メールに対する対策のあるべき姿，とか言うのを議論始めると難しい訳だけど，調べる中でこんな記事を見つけた．
　mnx.ne.jpとzero.ad.jpがDNS逆引き設定の無いメールサーバからのメールをspam扱いしはじめた件
本題は若干ずれる訳だけど，この記事に書かれていることはもっともな訳で，非常に参考にさせてもらった．
特に気になるのが，昨今はかつての「GeetKeeper問題」と言うのを受けて，外部に出て行くグローバルIPにドメインを振らない対策を採っている場所をしばしば見るわけだ(まあ，ドメイン振らなくたってIPから所属機関を調べるなんて大したことではないけど)．こう言う人も，迷惑メールに引っかかってメール送信できなくなるわけ？　とか思ってしまう．

で，上記記事の中からリンクされているJEAG(Japan Email Anti-Abuse Group)と言うところのrecommendationを読ませてもらったけど，通常のメールサーバはSPFかDomainkeysかいずれかをやってあれば問題ない，と言う見解らしい．そこまでは安心できるのだけど，さらにrecommendationは続いて，「メーリングリストはSPF，Domainkeys両方の認証を採用すべきである」とあるのには少々困った．ウチはML立ち上げてるけど，こっちは将来的には違反と見なされる可能性あり，ですか．まあ，厳密に適用されることはないだろうし，ウチのMLは不特定多数発信型ではなくあくまで限定登録者型だから，登録者にホワイトリストに入れてもらえばいいわけだけど，あまり気分ヨロシクないなあ．ML管理する立場としては気をつけておかねばならない話だなあ．

【RFC違反の携帯会社ってどうよ？】
ちなみに，上述の記事を書いている方は，ドコモもauもいいかげんにメールアドレス設定の仕様を直せ．などと言う記事も書いていらっしゃって，これも面白かった．携帯のメールって，RFCに違反なんですか…．ありえなすぎ．
過去に設定出来ちゃったモノはしょうがないとしても，今後については認めないようにしないと困るんじゃないでしょうかねえ．

まい > 日記用メール受信モジュールのテストです

まい > 日記用メール送受信モジュールもspam判定されないよう書き直しました．

■ VIEW's NETだめじゃん ■

day : 2007/12/19 url : https://old.chatarou.net/diary/200712.html#19

年末なので，「そろそろビューサンクスポイントの振替でもせにゃあいかんなあ」と思い，JR東日本のビューカードのページから会員ログインした．
で，つらつらと眺めていて「会員情報変更」の画面があったので，「そう言えばViewカードって会員情報変更ってネット上でどこまでできるんだろう？」と思い実行してみた．

会員情報変更のページを開くと，「登録しているメールアドレスを入力してください」と言うアナウンスが出る．で，そこでメールアドレスを入力すると，メールにて「会員情報を変更できるページのURL及び受付番号」が送信されてくる．
つか，会員ページがhttpsなのに重要な情報を無防備かつ保証担保のないメールで送っちゃうその仕様どうなのよ，とか思いつつもメールで送られてきたページを開き，「受付番号」「サービスID」「パスワード」を入力する．
…パスワードエラーが出て，ログインできない．
「あれえ，全部間違いがないはずなのになあ．つかさっきトップページでログインしたんだし，間違いようがないじゃん」とか思いながら何度かやっていたら，アカウントがロックされてしまった．
で，仕方ないのでビューカードのサービスデスクに電話して，アカウントのロックを解除しろ，と伝える．
で，ロックは解除してもらったんだが，ログインできない理由についてサービスデスクで問い合わせると，とんでもない仕様が分かった．

僕は「パスワード」を14桁で登録した(登録した頃は，8桁以上，と言う制限しかなかった)．
のだが，現在では「パスワードは8桁以上，12桁以下」と言う仕様になっている(現在では，13桁以上のパスワード登録は出来ないらしい)．
で，通常のトップページでは，12桁より先の溢れ分に関しては，substringか何かで無視して確認しているので整合する．
一方，会員情報変更のページでは，溢れ分もそのまま含めて一致確認しているから整合しない．

つか単純に仕様ミスじゃん．しかも，典型的な辻褄あわせミス．
View'sネットは，今年に入ってからPASMOとの相互利用の時にもでっかいトラブル出していたし(2007年2月19日の記事参照)，それ以降も何度か仕様変更していた感じだった(昔はサービスIDはシステムが勝手に発行するものでユーザが変更できなかったけど，今は変更できるようになっていたりする)けど，その中で古い仕様を変更する際に根本解決しないでごまかしをしたツケを払うハメになった訳だ．

せめて
「他のページでも古いパスワードでも認証する」
と暫定対応した上で，恒久対策として
「パスワードの仕様が変わったことをアナウンスする」
「トップページでも古いパスワードでは認証しなくするか，他のページでも古いパスワードでも認証するかどっちかに一本化する」
とやらないとダメでしょ．

まあサービスデスクの人にシステム仕様の話をしてもしょうがないよなあとか思いつつ，一応忠告だけしておいた(まあサービスデスクの人も，電話でサービスIDとパスワード文字列を口頭で確認とかよろしくないとは思うけど)．
パスワードの仕様変更の危険性については，JEISの中の人よりもニコ動の中の人の方が遥かにまともな対応をするということが良く分かった(笑)

■ 信書 ■

day : 2007/12/17 url : https://old.chatarou.net/diary/200712.html#17

僕はけっこう頻繁にメール便を利用する．
圧倒的に頻度が高いのが，amazonマーケットプレイスで不要な本を処分する時なんだけど，本は折りたたむわけには行かない．ので，「A4サイズ，厚み2cmまでならOK」なメール便はとっても便利だった訳だ．
とは言いつつも，実はメール便も最近改悪されてしまった．昔は『重さを基準』にしていたので，小さいけど厚い本(専門書は大概そうである)の送料は安かったのだけど，最近は『厚みを基準』にしているので，小さくてもちょっと厚い本だと高くついたりして腹立たしかったりする．まあ，店で一々重量計で測るより，ゲージ通すだけの方が手間もかからないと言う事情も分からないでもないけど．

で，今週のダイヤモンドを読んでいて(今週の週刊ダイヤモンドは郵便局特集)，やたらと『信書』と言う言葉が出てくるので気になった．
言われて見れば，メール便を出す時も「これは信書ではありません」とか言うのに毎回チェックさせられていたけど，あれって何の意味があったんだろう…．つか，わざわざ毎回客に手でチェックさせるのって面倒じゃないの？　とか思ってチラリとネットで検索．
　信書のガイドライン
へぇ～へぇ～へぇ～．結婚式の招待状はメール便で送ってはいけないんだ．
つか，今まで信書なのにメール便で送っているものがあるような気がしないでもないが…まあ無視しよう．

ちなみに週刊ダイヤモンドの場合，定期購読の読者への配送を発注しているのはヤマトさんなのでダイヤモンドは基本的に「ヤマトさんを持ち上げて，郵便を落とす」ように書くはずです．まあそこまで深読みする必要はないんだけどね．

■ 驕らず，限界を知り，極める ■

day : 2007/12/16 url : https://old.chatarou.net/diary/200712.html#16

昨日は『かわさんの御披露目会』に強行乱入．

(顔写真なので拡大はありません)
まあホントギリギリまで「無理だけど，都合ついたら乱入するよー」とか無茶なこと言って済まんかった．
でもイロイロな人に会えたし，話も出来たしよかった．僕としてはイロイロ思うところあってイロイロな人に対してイロイロな問いを投げかけたけど，皆さんの言葉一つ一つの違いを楽しむことが出来て，とても有意義だった．

そうそう，いたるさんとは「Net(訳：純)」と「Gross(訳：総)」の違いで少々惑わせてしまった．学位取りの忙しい，微妙な時期にあんな禅問答のような話をしたのは少々まずかったかなあと後悔した．
でも，長い目で見たときは絶対に必要になる概念だから，知っておいて欲しかった．

例えば．

(1) 5x ＝ 3x 200
　x＝？

(2) 6y 300 ＝ 12y - 300
　y＝？

と言う簡単な方程式を考えたとしよう．

Netでは，この問題は等価である．
だって，x＝y＝100なんだから．

でも，Grossではこの問題は等価ではない．
x＝y＝100である点については異論がないが，
5x ＝ 3x 200　≠　6y 300 ＝ 12y - 300
だからだ．

NetとGrossの違いを考えなければいけない時．それは，時間の矢に基づくのだろうと思う．即ち，state(時間の矢がない)ならばNetで問題ない．しかし，process(時間の矢がある)ならばGrossを考えなければいけない．
いたるさんはmass balanceだと言っていたけど，固液の反応を見ているようだから，それはprocessであり，Grossであるはずなのだ．

ちなみに，皆さんが無意識に使っている言葉でもキチンとNetとGrossは区別されている．例えば，GNP(国民総生産)，GDP(国内総生産)のGはいずれもGrossである(だから訳語にも『総』がつく)．

■ うーむ，冬型だ ■

day : 2007/12/15 url : https://old.chatarou.net/diary/200712.html#15

今日は天気がいいので，一気に布団を干しつつ窓掃除をした．
ウチは基本的にあまり風が吹き込まないので窓が汚れ難いのだけど，さすがに長いこと放置してあると窓の曇りが気になるようになってきたので一気に拭いてしまった．まあ乱雑に仕上げたので若干の吹きムラはあるが，気にしない♪

で，窓を拭くときにカーテンを動かすと，やたらと埃が立つ．うーむ，そうか，すーちゃんの仕業だな．
すーちゃんはよくカーテンの隅に隠れるので，カーテンを持ち上げると猫毛がメチャメチャ立つ訳だ．どーせだから，と一通りバタバタと埃を立てた後，一気に窓を開け放して空気の入れ替えをして埃を追い出してみた．
でも，まだ埃が空気中を浮遊していて，くしゃみがでる．まったく，面倒な奴だ(笑)

最近，やたらと「www.chatarou.org」からのリファラのお客さんが多いので，「何故？」と思ったら，Googleで「chatarou」を検索すると，chatarou.orgの方が検索順位が高いのね．
まあ一時的な問題だろうけど，そんなこともあるんだなあと．

さて，暫定対策ながらトップページと日記のページをFirefoxに対応させた．
もう，IE6.0とFirefox両対応のために力ずくでスタイルシート使ったり云々…(結局面倒なのでtableレイアウト廃止はやめた)．
まあ都合まだ未対応なページも残っているけど，まあいっか．
どこぞの大手サイトのサービスも「常にBeta」だもんね．ウチもそれに見習おう(笑)

■ 久しぶりの雨 ■

day : 2007/12/13 url : https://old.chatarou.net/diary/200712.html#13

うーむ…はやくこのサイトのcss tableレイアウトに手を入れねば…．

Firefoxって気づいたんだけど，STYLE="ime-mode:active"が効かないのね．入力フォーム等で自動でIMEのON/OFFを切り替えてくれるんだけど，IE独自拡張だったのかあ．使っているページがあるので，どう対処しようか悩み中(まあ入力そのものが面倒になるわけではなくて，あくまで不便なだけなのでしばらくpending)．

さて，僕は自分のことをいろんなニックネームで呼び現すのだけど，「知っている人間には分かるが，検索エンジンには知られたくない」場合は「mai」を，「検索エンジンに知られても構わない」場合には「chatarou」を使う．(まあ他にもニックネームはあるけど秘密)．
これの言わんとしている所には妙味があって，「mai」と言う単語はあまりにありふれていてネットの検索エンジンでは埋もれてしまうのだ．一方で，僕を知っている人は同時に僕がmaiであることも知っている場合が多い．のでこれを使う．
一方で，「chatarou」はドメインを使っているので検索効率が非常に良い．これはある意味便利だが，面倒な場合もある．従って使わない場合も多い．
この辺の使い分けはまだ模索中で，他にもいくつかニックネームがあるんだけどどう活用しようか悩み中．
kumasukeは公式に使えなくなったしなあ(まあkumasukeが活用されるのは良いことだけど)．

もうちょっと解説しとくと，問題は，ある一般名詞「A」の有名度(母数とでもしておこう)と，その一般名詞「A」における固有割合の関連だと言うことかな．
例えば一般名詞「小泉」と言った場合，このサイトを見ている人は「あー，koiね」となる訳だけど，一般的には「小泉」≒「小泉元首相」と解釈されるだろう．
例えば，ニックネームを選ぶ際には，
[A]母数が小さく，その母数の中に占める固有割合も少ない単語
[B]母数が小さく，その母数の中に占める固有割合は多い単語(chatarou)
[C]母数が大きく，その母数の中に占める固有割合が少ない単語(mai)
[D]母数が大きく，その母数の中に占める固有割合も多い単語
等が考えられる訳かな．
これはニックネームに限らず所謂「検索単語」全般に言える定跡で，SEOを行う際には「如何に固有割合を高めるか(検索順位を上げるか)」と「如何に検索単語の認知度を上げるか」の両面で見なければいけない，と言うことか．
まあ一般的なSEOは「最初は有名でない単語を見つけ出し，それの固有割合を高めた上で認知度を上げる([A]→[B]→[D]と遷移させる)」と言う戦略をとることが多いようだけどね．(認知度を上げるために，テレビCMで『詳しくは○○で検索！』等とやっていますねえ)．

■ Firefox難しい ■

day : 2007/12/7 url : https://old.chatarou.net/diary/200712.html#7

さて，なんだかんだ言いながらやっとFirefoxの環境移行が終わりかけてきた．
まだまだ気に入らない部分が多いけど，まあ妥協しようかなと言えそうな状況までは出来てきた．
移行してみても，「うん，これは便利だ手放せない」と言うかというと微妙な感じ．でも世の中的にGecko遵守のHTMLを書くところが増えてきたし，そうなるとGeckoエンジンのブラウザの方が早いしなあ(まあ誤差だろうけど)と消極的な移行ではある．

で，さて移行してみて，自分のサイトが我ながら情けない．まあIE6に最適化してあって，Geckoさんのことは一切無視で作ってきてあったサイトなんだけど，それにしてもデザイン崩れすぎ．
でも，これを直すには忌まわしき「TableレイアウトからDivレイアウトへの組み換え」をしなきゃいけないんだよなあ…．これまた面倒な作業だ．

■ ふくみぃさんおめでとう ■

day : 2007/12/4 url : https://old.chatarou.net/diary/200712.html#4

なんとなくFireFoxに移行する準備継続．
FireFoxって凄い便利なんだけど，いかにもクロスプラットフォーム用と言うか，Windows標準と挙動が違うので悩む部分が多い気がする．試しにFireFox側から日記更新しているけど，IMEの表示の仕方が他のアプリと違うし…まあ，そのうち慣れるか，Windowsっぽい表示に出来るツールを見つけるかするんでしょう．

とりあえず，最初の課題だった「画面の左端にマウスカーソルを合わせると自動でブックマークが表示される」機能は，「Optimoz Tweaks」と言うアドオンを追加することで実現できることが分かった．
あとはGoogle Calendar(G'Calと言うらしい．計算機と紛らわしいじゃん！)のカスタマイズに試しに「Better Gcals」と言うアドオンも入れてみた．

やっぱり，FireFoxは細かいところを改造できて便利ではあるんだけど，改造前提で作りすぎていて素の状態では使い難いと言うか，なんと言うかな気がする．
でも，なんだかんだ言って皆使ってるんだよなあ…(このサイトのログを見ても最近はIE6のシェアは5割切ってたりする)．

javascript，cookieをONにしてもらえると（とくにちゃっと・掲示板で）ありがたいです．
email

(spam対策のため、画像表記になっています。上記アドレス宛にはspam判定が厳密に行われますので、正しく受信されないおそれがあります。)