正しいかどうか分からないが、埋め込みTwitterの取り込み処理と、そこからデータをDOM操作する処理を初回BackgroundWorkerでやってたのだが、BackgroundWorkerだとそのオブジェクトを生成するのに時間が掛かるらしい。
＃確かなことは分からないが、デフォルトドキュメントのカウンタログを見ると、/ と /index.htmlとの間に最大で5秒以上のタイムラグが発生しているらしい。
そこで、BackgroundWorkerをやめて、ThreadPoolを使うようにした。
すると、タイムラグは1秒以内に収まるようになった(今のところ)。
プール数とリクエスト数にも依存するかも知れないけれど、まずまずの結果かな？
これで問題が出なければ、今後、ThreadPoolを使える場所ではThreadPoolを使うことにしよう。
http://internet.watch.impress.co.jp/docs/column/jirei/20100816_387407.html
また、なんだかな(参考)。
暗号化目的のSSLの場合、自己証明だろうが、公的認証機関による証明だろうが、"通信経路の暗号化"を目的とするのなら、無関係。
SSL暗号化有無に関わらず、相手側サイトにクレジットカード情報などの個人情報を送りつけちゃったら、それを相手がどのように使用するかは、分かったもんじゃないってのが根本にある。
＃結局、通信経路の向こう側での扱いが悪意に満ちたもので、それを見抜けなかっただけって事例。
公的認証機関による、正しい証明書かどうかを確認するってのは、個人情報の扱いを委ね、相手を信頼する一つの材料でしかない。
最終的な判断は自分でするしかない。
その判断を正しくできなかったのが反省点じゃなかろうか。
とりあえず、方法だけ書いておくか。
IIS用のマネージモジュールで、HTMLコンテンツに対し、カウンタと一緒に書き換えフィルタ処理を入れてある。
＃フィルタを使ったマネージモジュールの創り方は、ウィジェットのサイトカウンタって文字列をクリックな。
ただ、書き換え時にいちいちrssを取りに行くと、twitterサイトが重いときとか、回線混雑のときに応答待ちが大きくなるので、定期的にメモリ上に取り込むのを別途タイマーかけてやってる。
本当にちゃんと保持できてるかは未確認だけど、一応、シングルトンクラス内でタイマー使ってるから、保持できているはずだ。
保持したrss(XML)をごにょごにょ弄って書き換えるのは、いちいちやってる・・・のは無駄だな。
＃本当なら、保持するのは書き換えに必要な加工状態のものでいいはずだよなぁ・・・ま、いいか。
サーバサイドでrssを読み込んでおいて、埋め込む。
仕組みは簡単。
実装は・・・力技。
クライアントに余分なアクセスを発生させないので、高速化に寄与？
一応、うまく動いているように見えるけれど、今回、Windowsサービスを使っていないので、ちょっと不安。
しばらく様子見。
掛かった時間は80分くらいかな。
問題なく完了。
懸案事項1つクリア。
できれば毎月バックアップしたいな。
バックアップソフトを立ち上げてバックアップするのも良いけれど、やはり、HDD丸ごとバックアップは、リストア不要で物理的に載せ替え復旧が可能なので、基本。
というわけで、このブログサーバを今夜、新たに買ってきたHDDでバックアップ(予定)。
打ち上げ花火は夏の風物詩だが、実は夏場の渇水対策のための雨乞いなんじゃないかと思う。
特に、あの音と煙は雨を呼ぶのに最適だ。
音は大気を揺らし、煙は微粒子。
大気中の水分を水滴や氷粒へと変えるきっかけになる。
水滴や氷粒は雨となって降り注ぐ。
渇水の心配が無く、逆に大雨で困る地域、またはその風上に位置する地域であれば、花火大会などの開催はもしかすると控えるべきではないかと思う。
ま、でも、風物詩だからねぇ・・・
サイドウィジェットとして、QRコードを入れてみた。
＃サイトトップ固定だし、このサイト、モバイル対応しているわけじゃないけど。
しかも、画像じゃなくて、テーブルとして。
これを動的に埋め込めるようになれば、おもろいかもなぁ～。
とりあえず、本サイトのサーバー証明書を差し替え。
オレオレエンタープライズ(ワイルドカード)サーバー証明書を、ルートCA局から用意して、差し替えた。
面倒っちゃー面倒だけど、全部毎回作り直しても、手間はあまり変わらないので。
で、サーバー証明書は既出のアレでも使えるので、取得手順書(画面キャプチャ枚数70枚超)も作ったんだけど、結構でかい。
精査前だけど、欲しけりゃ持ってけ。
エンタープライズじゃなくて、スタンドアロンにすれば、AD DS不要で、単純かも知れず、再挑戦予定。
四捨五入では、0.4495→0.450(小数点下第3位に丸め)→0.45(小数点下第2位に丸め)→0.5(小数点下第1位に丸め)→1(整数に丸め)のように何度も丸めを行うことはご法度になっている。
0.4495→0.4(小数点下第1位に丸め)であり、0.5ではないし、まして1に丸められることはあってはいけない。
有と無、切り上げられる側と切り捨てられる側は平等でなければならないと考えると、多重丸めは不平等だと言える。
どちらに有利かはさておき、最初に挙げた例のように1になってしまっては、0.5505(=1-0.4495)の存在理由が否定されてしまう。
実は、多数決ってやつが、丸めによく似ていると、最近気づいた。
そして、日本の政治とか選挙が、多重丸めで成り立っていると、気付いた。
