私をリアルタイムで知っている人のうち何人が、このブログを知っているのだろうか。
おいそれと、危険な発言は出来ないな。と思う。
でも、それも窮屈な話ではあるので、きっと、危険な発言もするのだろうなぁ。
作者別: NAL-6295
4gの時計
http://arktrading.jp/tempo/tempo.htm
重量がわずか4gの時計です。
値段も安いし、クリップで留められるのは便利そうだしちょっと欲しいなぁ。
追記：
というわけで、注文してしまった。
Abyss Web Server X1
SSLやASP.NETも利用できるフリーのWebサーバー「Abyss Web Server X1」v2.5
窓の杜 – 【NEWS】SSLやASP.NETも利用できるフリーのWebサーバー「Abyss Web Server X1」v2.5
ASP.NETも利用できるそうです。
今更ながらSessionをInProcで持つのはやめましょうという話
正直なところ、
「SessionをInProcで利用してはいけない。」
というのは、誰もが知っている常識だと思っていたが、最近、仕事の中で案外そうでもない事に気づかされたので、あらためて解説します。
解説するのは以下の２点
１．なぜInProcで管理してはいけないのか。
２．どのタイミングでInProc以外にするべきなのか。
です。
まず最初に、「１．なぜInProcで管理してはいけないのか。」について解説します。
ASP.NETのプロセスは、ある条件（IISにて設定できる。経過時間だったり、特定の時間だったり、消費メモリ量だったり）に基づいて自動的に再起動するようになっています。
再起動するということは、プロセスに保持していた内容も最初からという事になります。
ということは、InProc(SessionをASP.NETのプロセス内で管理する。)だと、Sessionの内容が消去されてしまいます。
その仕組みを知らないままだと、知らないがゆえの原因不明のバグ（突然セッションの内容が消えた等・・・）に悩まされることになります。
特に開発時は発生しないためそのままリリースしてしまい、運用に入ってから突然発生して驚かされるという事になります。
そのため、SessionのモードはInProc以外(StateServerやSQLServerを利用して、プロセス外に保持するようにする。)を適用するようにしたいところです。
では続いて、「２．どのタイミングでInProc以外にするべきなのか。」について解説します。
最初に結論から述べると、
「開発の初期から。つまり最初から。」
となります。
ではなぜ最初からInProc以外にする必要があるのでしょうか。
それは、以下の２点
１．InProc以外のモードはシリアライズ可能なオブジェクトしか管理できない。
２．InProc以外のモードはSessionのEndイベントが発生しない。
について、InProcとそれ以外のモードでは動作が違うからです。
そのため、最初からInProc以外のモードを前提として開発していないと、いざ運用に入ってから
「シリアライズ可能じゃないから、セッションで管理できない。」
といった、例外が発生して、大幅な手戻り（セッションで管理しているオブジェクトがシリアライズ可能になるようにしなくてはいけない。）が発生する可能性や
「SessionのEndイベントが発生する前提で設計してしまった。」
といった事態が起きて設計の変更という手戻りが発生するが出てきます。
本来、最初からInProc以外のモードを前提としていれば、発生しない手戻りなわけです。
以上の事からも、
「運用時に利用するセッションのモードで最初から開発を行うべき。」
だという事が言えます。
今更感のあるエントリですが、あらためて解説してみました。
レビューの重要性
たいてい、プロジェクトの計画をする時に、責任者にコードレビューの重要性を説くのだが、真っ先に、その工程を省いてくれるので自分の作業時間を削って、抜き打ちで勝手コードレビューをする事が多い。
抜き打ちでルール違反を発見したら、修正をお願いし、ルールを遵守する重要性を説く。
しかし、保守フェーズに入って、抜き打ちでレビューできなかったコードを見ると、ルール違反している箇所が案外ある。
もちろん、守ってくれる人もいるし、割合的にはこちらの方が多い。
しかし、守ってくれない人も少なからずいるのだ。
そういう人は、ルールを守ることも仕事の一環であるという意識が薄いため、
「自分がいる間に、見つからなければいい。」
という動機で何度諭してもルール違反をする。
以上のことからも、ちゃんとコードレビューを行う事が大切であることがわかる。
いなくなってから、違反している箇所を見つけても遅いのである。
この話は、コードレビューだけではなく、設計レビューやその他のレビューにおいても言える事である。
レビューという一見何も生産していないように見える工程を省くことが多いが、「何も生産していない」というのは大きな間違いである。
#まぁ、昔から言われている当たり前のことを、こうやってエントリする必要性があるかと言われると微妙なのだけれども。
意味の無い変数名
お前らはウェブサーバか！
よく、若手に対して（私もまだまだ若いつもりですが）
「質問があったら固まってないで聞いてね。メールでいいから。
余裕のある時に返事するから。」
と言う事があります。
でも、なかなか質問してくれません。
ちょっと気になるので、後で
「どう？」
って聞くと案の定、質問したい事がたくさんあるようです。
そこで、いろいろと回答をするついでに、
「質問があったら固まってないで聞いてね。メールでいいから。
余裕のある時に返事するから。」
と言うのですが、相変わらず質問してくれないので、ポーリングします。
じゃないと、後で痛い目を見るのは私なので。
もう「お前らはウェブサーバか！」と突っ込みたくなります。
もちろん、わからないところは、自分で調べてから質問するべきですが、その上で、質問に来ないのは仕事をサボっているのと同義である。
よくある言い訳として、
「忙しそうだから。」
とか、
「申し訳なくて。」
とか聞きますが、
溜めるだけ溜めてからの方が、よほど困るのである。
世の中をそんなに悲観しなくてもいいよ
最近・・・というか、昔からそうなのだけれど、ニュースで様々な事件に触れる事ができる。
その過程で、「世の中はそんな事ばかりおきているのか。」と感じる事があるだろう。
でも、ちょっと待った。大事な事を忘れている。
何も起きていない平穏な日々は報道されない。
という事だ。
そして、昔は平穏な日々の一幕とされていたちょっとした出来事もネガティブなニュースとして報道されるようになったと言うことだ。
ちょっと自分に置き換えて考えてみればわかるだろう。
自分が買った商品に買っただけの価値があったとき、何事もなく使えたとき、あなたは積極的に人に情報を公開するか？
たいてい情報を公開する時は、何らかの不都合、不具合があったときが多いのでは？
だから、報道に惑わされて世の中を悲観しなくてもいい。
プロジェクトを推進する上で「みんなで決めましょう」は悪
プロジェクトを推進する上で、いろんな事を決めなくてはいけないが、その際
「みんなで決める。」
なんてことはしてはいけない。
違ったベクトルを持った人間同士が集うプロジェクトにおいて、そんなことをしていたらいつまでたっても決まらないし、決まっても指針のはっきりしないものになる。
とはいえ、意見を聞くなと言っているわけではない。
意見を聞かないような船頭もまた悪である。
意見は大いに聞けば良い。
ただ、最終的に船頭たる人間が信じる方針や指針に照らし合わせ、そして意見を吟味して決定する必要があるという事である。
もちろん、その際、船頭が自分自身の判断を信用できないようではいけない。
船頭はぶれないで、自信を持って決定し続ける必要があるのだ。
船頭にとって、プロジェクトの運営とは大小さまざまな決定の連続なのだ。
ぜひ、船頭たる人間には自信を持ってプロジェクトを遂行してもらいたい。
マイクロソフトからキーボードが届いた
とりあえず、交換してもらえることになってよかった。
キーボードが届いた。
先に、新しいキーボードが届いてから、故障したキーボードを送れば良い点は評価できる。
全体的に、サポートに繋がってからの対応は迅速だったが、サポートのワークフローやサポート情報の告知の仕方、そこにたどり着くまでのインタフェースに問題がある。
いずれ、解消されるだろう。