これからのプログラムの作り方 – 文字エンコーディング検証は必須
最近PostgreSQL、MySQL両方にSJISエンコーディングを利用している際のエスケープ方法の問題を修正がリリースされています。この件は単純に「データベースシステムにセキュリティ上の脆弱性があった」と言う問題ではなく「アプリケーションの作り方を変える必要性」を提起した問題です。
Dojo Javascript Toolkit
IBMが更にDojoを支援するらしいです。
Dojo Toolkit enabling internationalization of applications and making them fully accessible to persons with disabilities through a variety of assistive technologies,
Ajaxを使うとアクセシビリティが問題になりますが、アクセシビリティも考慮すると言うことらしいです。デモはなかなか良くできています。この近いうちにこのツールキットを使ってなにか作ってみよう。
trackbackもDNS逆引きなしホストから拒否します
海外からのコメント/トラックバックspam対策としてコメントだけはDNS逆引きなしのホストを拒否（というか登録したように見えても実際には反映しない）していたのですが、最近は一度に数百のトラックバックスパムを送ってくるSEO/SEM業者がいます。
コメントスパムに比べるとトラックバックURLを知った上でスパムを送信する必要があるのでコメントスパムに比べてトラックバックスパムの方が若干手間がかかるのですが、スパム業者もそれくらいの手間は惜しまなくなったようです。
DNS逆引きなしのホストからはトラックバックは受け付けないようにソースを修正しました。普通のまっとうなISPの場合、必ず逆引きは設定されているので普通のユーザは困ることはありません。（少なくとも日本は）逆引きくらいは簡単に設定できるのであまり意味が無いように思えますが、実際にSpamを送信してくるホストに逆引きが設定されていないケースが多いので多少は役に立つはずです。
# 三浦さんのspamパッチを試さないと…
ところでspamメールでは結構おなじみのドメイン名を使ったSpam効果測定を行っていると思われるspamが連続して送信されていました。例えば以下のドメインです。
4109.mejsef.info
(サーバはオーストリア、ドメイン所有者はポーランド、ネットワークアドレスが26ビットなので大口の一般ユーザ(?)のように思えますが逆引きはISPが設定した(?)ままの状態のようです）
4109がなんらかのIDと思われます。サイト識別IDにしては4109は短すぎるのでキャンペーン番号のようなID番号なのでしょう。いちいちDNSに登録するのが面倒では?と思われるかも知れませんが、ずっと前のspamメールのエントリにも書いたようにドメインをIDとして利用するのは、ワイルドカードをサポートしたDNSなら非常に簡単です。ほとんど手間もかかりません。DJBDNS、Apache 仮想ホスト、サーバサイドスクリプト少々、なんらかのデータベースシステム等があれば簡単に汎用的な仕組みが出来てしまいます。
マウスをぐるぐる回して高速化!?
前のエントリで
本当かどうか知らないのですが「マウスでぐるぐるポインタを回しているとPCが速く動作する」と言うバカバカしいと思われる知識
と書いたのですが、divineさんから「Word の「印刷」を劇的に速くする方法を発見。ホイールを上下するだけ!」と言うブログへのリンクを教えていただきました。（divineさん、ありがとうございます）「マウスをぐるぐるして高速化」はバカバカしいように思えるのですがマウスホイールを回すと実際に速くなる場合もあるようです。以下が速くスプールできる理由の推測です。
ご存知の様にWindows95より前（Windowsは3.1まで）はコーポレイティブ（非プリエンプティブ）なマルチタスク（アプリが自分で処理をOSに返す）でした。MS Officeの開発は少なくともWindows 3.xの頃（Windows 3.1上でOffice 4.xを実際に使っていました。実際の開発ルーツはもっと前でしょう）までさかのぼれますが、Wordの印刷処理をバックグラウンドで行うには現在のようにスレッドを作ってOSに任せる事が出来ませんでした。昔のアプリケーションではバックグラウンド処理を行うには擬似的にスレッドを実行するような感じのコードを書く必要がありました。この擬似スレッドの様に動作するコードのためにイベントが発生するたびに、より速いタイミングでバックグランド処理が行われる仕様となってしまったアプリケーションができたのだと思います。Wordのスプールの場合、再描画のスレッドとスプール処理が関連している（リンク先（Word の「印刷」を劇的に速くする方法）を参照）ためマウスのホイールを動かしてスクロールさせると速くスプール出来てしまう動作（仕様）になってしまったようです。
# 今のOfficeならこんなコードを捨てて普通にスプール用の
# スレッド作るだけで劇的にスプールが速くなると思います。
# 推測ですが。
とにかく「マウスでぐるぐる回しているとPCが速く動作する」というノウハウは100%嘘ではなく、一部では本当に処理が高速化できる！という事は書いておなければと思いここに書いています。（注：とは言っても単純に「マウスポインタだけ」をぐるぐるしているだけでは処理は速くなりません）
さて、マウスやキーボードを使っていると処理が速くなるケースはUNIXでもありえます。/dev/randomはマウスやキーボードなどからの入力を乱数生成に利用しているので一部のアプリケーション（特に強度が強い暗号処理）で乱数のシード待ち状態が発生する事があります。このような場合にはマウスポインタをぐるぐる回すと結果として処理が早く完了します。
Windowsだけでなく昔のMac OSもWindowsと同様にコーポレイティブマルチタスクでした。探してみればWindows、Mac OSがコーポレイティブマルチタスクだった頃の名残りで「マウスを動かしている（イベントを発生させている）と処理が速くなる」ケースは結構沢山あるのかも知れませんね。
マウスぐるぐるでアプリケーションの動作が高速化する場合が他にもあるでしょうか? もしご存知の方、是非教えてください。
RFC原理主義者ではないですが… 迷惑な迷惑メール対策に反対！
RFCの位置づけも、絶対的に崇め奉る技術者がいたり、そもそも読んでない(あることを知らない)なんて技術者がいたりとまちまちだが、相互接続に影響する部分は準拠しておいてほしいと思う。携帯各社のメールアドレス仕様でユーザより「PCのメールからメール送受信ができない！」とクレームを受けたことのあるタレコミ人としては、ユーザに対しきっちり警告も行わないままで、相互接続に問題がある形式を採用するのは迷惑なだけ、と思うのだが、みなさんはいかが？そもそも、メールの相互接続は保障していない！って？”
DoCoMoもAUも何を考えているのだろう?
想像力が不足しているように思えます。不正なメールアドレスを使って他のドメイン/サーバからの迷惑メールを防ぎたいなら、自分のドメインからのみ受信できる状態をデフォルトにすれば良いだけでは?
このような迷惑な仕様によって発生するサポートコストは「DoCoMoとAUに請求したいくらいだ」と思っている人も多いと思います。
時間があるAUユーザは是非自分のメールアドレスを非RFC対応メールアドレスに変更してAUサポートに電話をお薦めしたいくらいです。
ユーザ：「PCからのメールが届きません！」
サポート：「メールアドレスに一部に一般的に使えない文字が含まれているからです」
ユーザ：「使ってよいとしたのはそちらなので使えるようにして下さい。機械の事はよくわからないので受信できるようにしてもらいたいのです」
サポート：「連続した.（ドット）や@直前に.は使わないでください」
ユーザ：「もうこのアドレスにしたよ、って友人送っちゃいました。アドレス変えて送り直すってことですか?」
… 以下延々と …
と言ったサポートコールが山のようにあれば改めるかな?一端広げた仕様を狭めるのは非常に難しいので出来るだけ早く修正されることを期待したいです。
文字コードといい、いい加減なのは技術者でなくて、技術をよくわかっていない上司の鶴の一声だったりするのかも知れません….
それともユーザから「どうしてこの文字はアドレスに使えないのか?」といった問い合わせが多いのかな? 「DoCoMoでは使えるよ！」とか?
ところでこの投稿のリンク先に書いてあったAU, DoCoMoの迷惑メール対策も「いかがなものか」と思います。
半角英数字と「- (ハイフン)」「. (ピリオド/ドット)」「_ (アンダーバー)」などの記号を組み合わせた長いアドレスが、迷惑メールの防止に効果的です。
http://www.au.kddi.com/notice/meiwaku/email/mail_address/
メールアドレスの文字数別に迷惑メール受信率を調査したところ、文字数が多いほど迷惑メールを受信してしまう率が低いという結果が出ています
http://www.nttdocomo.co.jp/info/spam_mail/measure/change_add/
AU, DoCoMoは「長いメールアドレスが迷惑メール防止に効果的だ」としていますが、長いメールアドレスが迷惑メール防止に役立つとは思えません。単純に迷惑メールに辟易したユーザが長い別の新しいメールアドレスを取得しただけだと思います。
当り前ですが迷惑メール業者はメールアドレスをデータベース化し、そのデータを元に送信しているはずです。データベースに登録されるか?されないか?はメールアドレスの長さや使っている文字に関係しません。（迷惑メールを送る業者がわざわざメールアドレスがRFC準拠かチェックしているとは思えない）長いメールアドレスが迷惑メール防止に役に立つ、と言う技術的根拠を示してほしいものです。（統計的に役に立っている、という議論は無意味）
私は携帯、PHSメールアドレスを送信にはほとんど使わない&Webサイトに登録しないので迷惑メールは全くきません。@前のユーザ名部分もいつも使っている”yohgaki”です。しかもこのアドレスはずっと以前から使っています。さらに私が他のメールサービスなどでメールアドレスを設定する場合、yohgakiがユーザ名に使用できれば必ずyohgakiを使っています。yohgakiをユーザ名にすることにより迷惑メールを送信されるリスクは高くなると思われます。にも関わらず迷惑メールは受信していません。メールアドレスのユーザ名部分が分かりづらいから迷惑メールがこないのでは無く、メールアドレスがデータベースに登録されていないから迷惑メールがこないのです。
# ちなみに公開メールアドレスのyohgaki@ohgaki.netに
# は毎日数百通のSPAMメールが世界中から送信されてき
# ます。
統計的に長いメールアドレスを持つユーザが迷惑メールを受信していないのは
SPAMメールに辟易
↓
新しいアドレスの取得を試みる
↓
分かり易いアドレスはほぼ全て使用済み
↓
仕方が無いので分かりづらい長いアドレスを設定する
↓
結果として新しいメールアドレスになる ←ここだけが迷惑メールを防ぐポイント
↓
当然新メールアドレスはSPAM業者のデータベースに登録されていない
↓
当然、SPAM業者からSPAMメールが来ない
と考えるのが妥当と思います。メールアドレスが分かりやすいか、長いかはSPAMメール対策に何の効果ももたらしません。
更に短いメールアドレスを持つユーザは「長い期間」そのメールアドレスを使用していると考えられます。その結果として複数のSPAM業者のデータベースに登録されてしまい、多くのSPAMメールを受信していると思われます。「短いメールアドレスを持つ」事と「SPAMを受け取りやすくなる」事には全く因果関係はありません。実際、@ohgaki.netの1文字メールアドレスには1通もSPAMメールが来たことがありません。
長いメールアドレスが迷惑メール対策に有効と宣伝するのは「嘘をついている」言われても仕方ないと思います。
本当かどうか知らないのですが「マウスでぐるぐるポインタを回しているとPCが速く動作する」と言うバカバカしいと思われる知識（追記：WORDでは処理タイミングの問題で印刷スプール処理が速くなる場合があるそうです。私が聞いたのはEXCELファイルの読み込み中にマウスをぐるぐる回している速く読み込める、と言うものでしたがもしかしてこれも本当だってりします?マウスイベントでスプール処理が速くなるのはWindowsとOfficeの歴史からも納得できるのですがEXCELのファイル読み込みでも同じ現象が確認できるでしょうか?ご存知の方、是非教えてください。）を本気で信じている初心者の方も多いらしいです。「長いメールアドレスが迷惑メール対策に有効」と宣伝するのはこれと変わりありません。
# 一部のアプリケーションでスクロール中にマウスを動かすと
# 速くスクロールするのですが、この仕様が誤解の原因??
とにかく、技術的根拠が全くない迷惑な迷惑メール対策には強く反対です。RFCに違反していると知りつつ大手ネットワークサービスプロバイダがRFC違反するのにも強く反対です。RFCが気に入らないなら、RFCを変えてから変更するか、本気になってRFCの変更を提案する姿勢を見せてほしいものです。