Windows 7の試験合格したんだけど、キャンペーン中だったことを少し忘れてた。
早期取得で先着100名にQUOカードプレゼントってやつ。
キタ。
でも、Microsoftからじゃなく、プロメトリックから。
ま、何を貰えたとか、誰から貰ったとか、あまり気にしないことにする。
重要なのは、先着100名に入ったってことだ。
開始から結構過ぎての受験だったから、無理かなって思ってたんだけど、そうでもなかったということか。
申し込みは無く、合格即自動エントリーって仕組みなので、純粋に順序で100名以内。
こういう結果を貰えるのは、まんざらでもない。
＃でも、実際は期間内に合格した全員にだったりして・・・
E(10のn乗)も処理できるようになったので、なかなか使えそうなものになった。
A2セルには「=-1.23456789012345E-21+123」と、普通に計算してみた。
当たり前だが、有効桁(Excelの場合15桁らしい)丸めで無視される大きさなので、A2セルの結果は123。
A1セルのHLADD(自作関数)ではちゃんと計算できている。
HLADDなら、小数点や符号を含みながらも、3万桁超(Excel2003以前は255桁)まで対応している。
因みに、E±9999まで入力可能にしたので、本来は文字列で指定した方がよいのだが。
残念なのは、まだ加算と減算しかできないってところか。
Excel関数にすると気になっちゃうのがEの処理。
文字列引数を受け取る関数にしたんだけど、ある程度の桁数の数値を引数に指定すると、E付きの文字列になっちゃう。
できればEを有効に読み取ってあげたいところ。
もうちょっと時間を掛けよう。
ので、少しうれしい。
何でもそうだけど、実際にやろうとすると、意外に手間取るよね～。
一応、走査回数は標準2回(最悪n^2オーダーになる条件が含まれるけど)でパースできるようにした。
＃本当は1回でやるべき。
符号は数値前のものだけ。
でも複数連続符号も認識できるように。
数値中のカンマや空白の読み飛ばし機能とか、数値前後の文字列を無視する機能とか、そういうのも実装。
米国ではすでにやられていたんですが、日本でもやってくれるらしい。
リベンジとか、MCPDとか受けておくかな。
2回目無料だと、1回目の受験時のプレッシャーが減るので、たとえ1回で合格できる試験でも、メリットがあると思う。
あとは、どこかで割引チケットを買うことができればOKなんだが。
＃旧NRIラーニングは割引販売してくれるっぽい・・・けど、「上記「お申し込み」ボタンよりお申し込みください。」のボタンが無いよ～。
＃＃問い合わせたらつけてくれたっぽい。
休眠中のT61をどうにかしてHyper-Vサーバ化したいと思っていた。
できればServerCoreで。
リベンジ学習のためとか、LAN内にちょっとしたファイルサーバを設置したいとか、そういう理由はさておき、T61を活用せねば、もったいないわけだ。
ServerCoreに関しては、コンポーネント数が少なければ、攻撃を受けにくいというのは分かる。
シンプルイズベストというやつだ。
使用リソースも少なくて済む。
Hyper-Vの親パーティションにするなら確かにServerCoreはベストかも知れない。
だが、こと操作に関してはベストじゃない。
CUIで同じことができるにせよ、GUIの操作性やヘルプの充実度にはそれなりのメリットがある。
そして、ノートPCでHyper-Vを構成した際に、単体でゲストOSの画面参照ができなくなるのは、大きなデメリットだと、常々思ってきた。
PRO: Windows Server 2008, Enterprise Administrator
不合格。
2科目目無料のアレで受けてきたのですが、1問足らずの不合格。
以下言い訳。
最近、サーバ触ってなかったんだよね。
やはり実機を動かしてみてナンボ。
特に、複数ドメインや複数サイト、フォレスト間の信頼とか、まぁいろいろ実際にやってないと。
多少日本語化が弱い問題もあったのだけど・・・、普通に力不足。
リベンジをどうするかは考え中。
＃これ、日本でもやってくれるなら即再受験を前向きに検討するんだけどね。
＃＃実機触れよ＞俺。
smart sizing:i:1
こいつは知らんかった。
個人的に、超便利なのでメモしておく。
XGAノートをQXGAで使えるかも？
ってことくらいは知ってる。
MCDBAも持ってるし。
ただ、どの情報の格納にデータベースを使えばよいかの判断について、皆目不明瞭だった。
情報を格納するのなら、ファイルでいい。
＃広義ではファイルシステムもデータベースだけど。
テキストファイルで良いのなら、その方が分かりやすい。
typeコマンドやメモ帳など、中身を見る手段はいくらでもある。
多量の情報を処理することも、一度プログラムを組んでしまえばどうということはない。
いくらISV試験を受けても、こういう実に基本的な事柄ってやつは、出てこないし、解決されない。
データベースというものがあって、どういうものかも分かる。
確かに情報を格納したり参照するといった処理をするのには便利な機能がいっぱいだ。
でも、今ここにある情報をデータベースに格納する意味はあるのかと。
帰路。
往路の逆なら確実に帰れるのは当たり前。
でも行きの候補経路にはいくつかあって、京都経由、大阪経由、名古屋乗換え、と時間的にはこの3つ。
大阪経由で帰ってみよう。
というのも、郡山から大阪までは1時間かからない。
＃静岡県内でいくと、静岡－浜松や静岡－熱海なんかより余裕で近いということになる。
大阪に何かあるかというと、何もないのだけれど、電気街をぶらついて、多少腹をこなした方がよかろうということで、難波まで行って、新今宮までぶらぶらすることに。
でかい唐揚げとしては、昨年、でからあげランチとして制覇している。
しかし、もっと東にも、やはりでかい唐揚げがあると聞き、行ってきた。
何が起きてるか分からんけど、どうやら、IISワーカープロセスが無応答になるらしい。
ワーカープロセス数を増やせば、ある程度抑制できるが、・・・
やはり、: Stream, IHttpModuleってのがマズイのかも。
と、思って、分離したんだけど、やはりダメ。
だって紙なんだもん。
ちゃんとしてても、さすがに何年も使ってると、手垢か湿気か知らんけど、縁が黒ずんでどうも格好悪い。
おまけに、印刷も掠れ薄れてきたし、今後も使い続けるものならば、何とかせねば。
前々から思っていたのだけれど、やっと決意。
仮に再発行を受けたとしても、対策方法が無いのでは、同じことの繰り返し。
そんなんじゃダメだ。
紙媒体を長持ちさせるには、一番の敵である水分から守るため、ビニール系のもので密封するのが一番。
ラミネーターだ!!
いや、発覚したからといってすぐに改修するわけではないが。
「/」へアクセスすると、何らかの既定ドキュメントを返すのはWWWサーバなら大抵持っている機能だけれど、IIS7.5ではどうやらモジュールがこの役割をしている・・・らしい。
＃そんな名前のモジュールが見えるよね。
で、これ、リダイレクトをさせるのではなく、また、ハンドラのように、自分で何か取ってくるわけでもなく、モジュール内でリクエストを繰り返しているっぽいんですよ。
詳しく調査したわけじゃないから、違うかも知れないけど。
ってか、もう少し早く気付けよってことで。
モジュールで受け取れるリクエスト情報にはクライアントのIPアドレスとそのホスト名があるんだけど、これ通常どちらも同じ情報が含まれている、というか、名前解決のコスト削減ってことなんだけどね。
だから、IPアドレスからホスト名を引っ張ってくる処理を入れてたわけ。
これが遅かった原因。
ログ書きをスレッド化したんだけど、そのスレッドに渡す変数(クラス)オブジェクトを構築する際にDNS引いてたから遅かった。
ログ書きスレッド内でDNS参照を行うよう変更したら、嘘のように軽くなった。
マジで、嘘みたいに軽い。
実際、カウント数集計と、レコード書き込みはどっちが先に行われているかは分からないけれど、あまり気にすることはない。
これなら、twitterの内容埋め込みもできそうな感じ・・・
＃twitter内容を定期的にローカルへ蓄えておく必要がありそうですが。
レスポンスのContent-Typeとステータスから条件判断してから、DBへのLog書きをThreadPoolに委託、フィルタチェイン構成となるよう、モジュールイベントを構成したんだけど、やはり遅い。
＃少しは改善したような気がしなくもないけれど。
さらにDB処理を削っても遅いため、恐らくDB処理は無関係だと思われる。
ならば、残りのフィルタStream自体が問題と思われる。
思われ・・・る・・・
このブログにカウンタを付けてみようかと思っていた。
普通はカウンタって、たとえば、imgタグで動的に画像を返すとか、JavaScript使ったりすると思うんだけど、それは、再リクエストを期待しないと無効なわけだし、レスポンスを返す時点でカウンタ値は決まっているわけで、いろいろと無駄があると常々思っていた。
たとえ、レスポンス一発であっても、CGI使うとか、サーバサイドインクルードとか、静的コンテンツには不向きだったりする。
前記事のとおり、IISならフィルタでレスポンス書き換えできるので、これでやってみようと思ったわけ。
.NET Frameworkでは、IHttpModuleを実装すると、IISを通過するリクエストやレスポンスを操作できるモジュールを作成できます。
たとえば、リクエストに合わせてレスポンス内容を変化させるなんてことも・・・
そう、いつも通り簡単にできるだろうと思っていました。
HttpResponse.OutputStreamの中にはレスポンスコンテンツが蓄えられるはずです。
これを読み取って、書き換えてしまえばよい、そう思っていました・・・
