Googleのキャッシュられたページは、テキストのみのバージョンで見ることができる、ようになったらしい。
＃いつからかは知らん。
このサイト、いろいろ弄った甲斐あって、テキストのみのバージョン(恒久URLか不明)にしたところで、ツイッターもQRコードも、ちゃんと見える。
残念ながらコメントフォームだけは見えなくなっちゃうけど、殆どの情報は損なわれていない。
＃インデックスページにはもともとコメントフォーム無いけどね。
ゴテゴテ飾り立てるだけが全てじゃないよね。
特に、トップページがFlashだけのサイトとかさ、もうちょっと考えたほうがいいと思う。
正しいかどうか分からないが、埋め込み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)の存在理由が否定されてしまう。
実は、多数決ってやつが、丸めによく似ていると、最近気づいた。
そして、日本の政治とか選挙が、多重丸めで成り立っていると、気付いた。
http://www.dospara.co.jp/goods_pc_topics/share.php?contents=shizuoka_close_100531
なくなっちゃうんですか！
いざという時に便利だったんだけど。
まぁ、移転するたびに市中心部から遠ざかってたからなぁ。
立地悪いんだよね。
駅までの無料送迎バスとかだせばよかったかも。
残念過ぎる。
そのまんま知事が困った顔で報道されてるのは少し見たけど、口蹄疫ってヤバいらしい。
拡散力というか、感染力めちゃくちゃ強いらしい。
予想以上にヤバいらしい。
知らなかった。
人への感染例は少ないってだけで、「絶対感染しない」とは言えないらしいし。
なぜ、こういうことを報道しないんだろう？
とりあえず、できることはなるべく移動しないこと。
移動して、感染土を踏んだりしたら、たとえ消毒したとしても、菌を持ち帰る可能性がゼロでなくなる。
空気感染もあるらしい。
感染拡大に加担しならないように、たとえ支援したいからといっても、安易に感染地域へ行くのは避けるべきだと思う。
・・・なのに、某幹事長は・・・
朝鮮半島(多分震源)でも大流行らしい。
別に、クローラーによって、httpsへのアクセスがあってもいいんですけど、さすがにhttps側のインデックス化は、オレオレ証明書サイトにとっては、ちょっとね。
http側にもほぼ同じ内容があるわけで、普通はhttp側をインデックス化するはずだと思っていたんだけど、ちょいとググったら、https側の検索結果。
まぁ、内容改ざんの危険性が無い方を優先ってことなら文句は言えないんだけど、にしても、http側の方が暗号化無い分、若干レスポンス速いと思うので上位に来てもいいはずと思っていたんだけど、このあたりどうなのか。
とりあえず、ググルさんからのボットアクセスに対しては、httpsリンクを張らないように手を入れてみたので、またしばらく様子見。
メモ。
カウンタログを眺めていて、何となくおかしな感じがしていた。
コメントを暗号化して送りたいときに使うと良いと思う程度だけど、一応、SSL(HTTPS)に切り替えるためのリンクを上部に作成。
これもIISでモジュールフィルタ使って書き換えている。
サイト内リンクをhttpsに書き換える処理も入れてある。
＃トラックバックURLも書き換えちゃってるけど・・・
オレオレ証明書(ワイルドカード)なので、証明書エラーとか出まくるけど、暗号化は可能。
エラーを無くすには、ルート証明書をインストールすればいいんだけどね。
＃ルート証明書、公開してもいいと思うんだけど、躊躇中。
それこそ、気になったらコメント下さい。
＃サポートサイトでもSSL効くんだけど、オレオレだからリンク自粛。
証明書の有効期限もあるので、そのうちオレオレ認証局設置からオレオレワイルドカードSSL証明書取得やIISへのインストールまでの自己流手順書を作成しようかと思っている(予定)。
単純に、URL毎のアクセス数を見てみただけなんだけど。
SQL文はこんな感じ。
SELECT RequestUrl, COUNT(*) AS Hits
FROM dbo.LogTable
WHERE (IsCrawler = 0)
GROUP BY RequestUrl
ORDER BY Hits DESC
※実際にはビュー化しています。
トップページ(インデックス)に次いで70-680記事へのアクセスが多い。
そんなにみんなWindows 7の試験好きか。
こんな記事読む前に、受けちゃえばいいのに。
でも、ま、リンク先の資料は少しは役立つかな？
意外なのはVGAダミーアダプタ記事が9位に入っている点。
このブログ、ほとんどのアクセスって検索サイト(ほぼgoogle)経由なんだよね。
だから、どんだけVGAダミーアダプタに興味があるのかって、ことが分かる。
もっとコンパクトで出っ張り少ないものを売りだせば売れるかもね。
個人的には、小さなRJ-45ループバックコネクタの方が利用価値あると思うけど。
＃小さなRJ-45ループバックアダプタの記事は旧ブログに書いたはず。
ノートPCに刺しっぱなしで、今も使ってるし。
ってか、簡単にこういう、カスタムな解析ができるのは、自宅サーバならでは。
もっとデータ集まったら、ページ毎のアクセス数推移グラフとか、カウンタログ専用サイトを設置しようかと思っている。
まとめとくか。
MOTへの挑戦は、再就職できたらと考えたけど、結局そういうこともなく、断念。
で、その不合格あたりからはじまった2009年でござった。
やはり懐具合の厳しさを理由に、毎月アキバは終了。
今年喰ったものの中では、
あたりが印象的でござった。
そういえば霊峰参りには行かなかったな・・・
昔の味では無くなったし、元旦でも月曜日じゃなければ営業とか、半端無いスタイルが消失しちゃったから、なんていうか、ありがたみ半減って感じ？
おいしいイチゴスパなんて、どうかしている。
カキオコも行ってないな。
スタンプラリーも終わっちゃったし、何より、鈍行日帰りってのはめちゃくちゃ疲れるんだよ。
でも、あの景色はいい。
今年は飯田線に乗ったけど、山岳の路線より、カキオコ日帰りの方が見える景色に変化があって良いと俺は思う。
とりあえず、できたっぽい。
favicon.icoのマネージハンドラ。
できたっぽいんだけどね。
時間(JST)を埋め込むようにしてみたんだ。
アクセスする都度変わるとおもろいと思ってたんだけど・・・
Expires指定してもfavicon.icoはキャッシュ更新されないのですよ。
なんででござろうか。
キャッシュから削除してアクセスすれば取得してくれるので、キャッシュチェックしていないわけじゃなさそうなんですが。
IE8だけかな？
ま、動くハンドラができたことと、favicon.icoが無くてログに404を記録されることが無くなったことは良いかな。
ユーザーが制御できない「秘密cookie」、半数強のサイトが利用 - ITmedia エンタープライズ
薄々わかっていたことだけど、トレーサーだったわけね。
C++でフォームアプリつくってたら、デザイナの挙動がおかしくなって、しまいにはデザイナエラー。
仕方ないので、C#。
でも、結果としてC#の方が楽だった。
なにやら超胡散臭い方法を多々取り入れつつできたのだけれど、なぜ例外が発生していたのか、さっぱりわからない。
try catchでも捉えきれないってのは、tryブロック外か、catchブロック内で例外になっているのかも知れないんだけど、それでも超想定外で、さっぱり。
でも、とりあえず、動くようになったから、一応信じておくとするか。
今のところ、高機能なものはいらない。
投稿さえできれば、面倒は極端に減る。
ならばというわけで、シンプルなものをつくってみた。
絶対ダメなもののダメ理由が、「法律により処罰対象になるから」という、いわゆる、「ほら、怒られちゃうからやめようね」的な、本質とは異なることにすり替えちゃうような報道や会見ではいけないと常々思う。
せっかく役者がそういう場に立つのであれば、ダメ理由を分かりやすく、たとえば、目の焦点をわざと外して、半笑いでよだれを垂らしながら、見た目に明らかにヤバい人を演じて欲しかった。
もし、やってくれてたら、インパクト絶大だっただろうに。
幼少期ならトラウマになるかも。
逆に、普通の人をやっちゃうから、本来のダメ理由が霞む。
「やってもバレなければ普通の人なんだぜ、きっと、だから大丈夫」と思わせるような報道ならしない方がマシ。
記事エクスポート／インポートがうまくできずに、完全再構築。
処理速度は上がったのだが、やはり、mt-xmlrpc.cgiがタイムアウト。
何が原因か、不明・・・
かなり重い。
管理サイトはSSL＆CGIなので、やはりかなりの負荷が掛っているようだ。
PerlCGI動作時のCPU負荷は限界まで一気に跳ね上がる。
X41以外のマシンで再構築すべきだろうか。
前期型のX60を利用してみるか・・・
このサイトも実はDDNSを利用している。
MyDNSというDDNSを利用させてもらっているのだが、他のDDNSサイト同様、定期的にアドレス通知を送る必要がある。
＃というか、それでDNS情報を更新できるからDynamicDNSなわけだが。
Windows Live Writerの設定時に、mt-xmlrpc.cgiへのアクセスでタイムアウトする。
エラー時に表示されるURLは正しい。
とすれば、mt-xmlrpcの処理の問題か。
だが、なぜタイムアウトするのか、よくわからない。
ユーザ名に問題があるのかもしれない。
サーバ負荷が問題なのかもしれない。
SSL証明書に問題があるのかもしれない。
OSのイベントログには処理がタイムアウトしたことのエラーが記録されている。
CPUかディスク(無いけど)アクセスの遅さが原因かも知れない。
コメントの管理までやるには、管理ページへアクセスする必要があるし、それはSSL暗号化できてるから、いいのだけれど・・・
自己証明書からドメイン証明書に変更。
＃ワイルドカードオレオレ。
ドメインルート証明書をインストールしておけば、SSL証明書のエラーは出なくなる。
だが、なぜかWindows Live Writerはうまく動かない。
あとわかったことは、/mt/ディレクトリ(標準名)もブログ表示側で公開しておく必要があるらしいということ。
非SSLでログインしようとすればできちゃうんだよな、どうしようかしら。
＃どうしようもない。
8GBのCFでWindows7運用は、やはり厳しい。
全体をNTFS圧縮しても、アップデート一発で、空き容量はすぐに警告レベル。
16GBのCFへ載せ替えたいところ。
このブログは、8GBCFと4GBSDHCでゼロスピンドル化したThinkpad X41を利用し、Windows7＋IIS7.5＋MovableType4.2の構成で構築しました。
非力なので、今月は様子見運転とします。
