映画【ミミック】は確かに面白い。ムシ好きにとっては垂涎の映画だ。しかし、スターシップ・トゥルーパーズ同様、ムシ嫌いには存在すら疑われる映画でもある。

仕事が終わんねえええええ！！！！
明日はぐったり休むけど日曜は出勤して仕事ですよ。そうでもしないとちょっと終わらん…。
今週１日平均１２時間は仕事していたせいか、昨日の晩は仕事してる夢を見てしまった。いっそ目覚まし時計に息の根を止めて欲しいぐらい辛かった。

以下、目覚まし時計に息の根を止めていただくための真剣な考察。

【定義】
・目覚まし時計
　→オーソドックスなジリリリリリとなるタイプの目覚まし時計。
　　文字盤はアナログ。
　　スヌーズ機能を搭載していて、上部のスイッチを押すだけでは一時的にしか止まらない。
　　音量は大きい。

・息の根を…
　→ゾンビとして命を開花させるために必要な儀式。
　　メメント。

【方法】
・目覚まし時計は主体的に攻撃してこない。
　決まった時間になるアラームによる音響攻撃のみである。
　打撃攻撃でもないので物理的な痛みはなし。

・人は音を耳で捉える。
　故に、音響攻撃がゾンビになるための一助となりうるには、必然的に耳を仲介してのことでしかありえない。

・『ジョジョの奇妙な冒険』の６０巻で、セッコがブチャラティに耳を破壊され、結果としてゴミ同然の扱いを受けていたことにヒントがありそうだ。

・しかし、ブチャラティがセッコの耳を破壊したのは、とてつもない爆音＋地中と言う極めて閉鎖的かつ限定的な場所である。しかも、セッコは耳がとても良い。

【音量】
・重要なのは音量だということがわかった。
　しかし目覚まし時計の鳴る音が致死量にまで届くかと言う問いには疑問の声が上がる。

・日常、あるいは非日常で起こる爆音について考えても、「間近でガスボンベが爆発したから」とか「新幹線が目の前を通り過ぎたから」とか言う死因は聞いたことがない。

・音が原因でゾンビになれるなら鉄っちゃんやパイロットの３割ぐらいは今頃ゾンビ化していることだろう。

【精神的効果】
・音の大きさではゾンビになれないようだ。

・目覚まし時計は、あらゆる人に感謝されながらも、同時に憎まれてもいる存在だ。
　快眠を邪魔する悪者の位置にありながらも、社会的に信用を失う遅刻を防止してくれるありがたいやつだ。
　快眠が終わる頃を出社時間にしない企業に対して憤慨している人は今のところあまりいない。

・目覚ましに対する苛立ちや憎しみは、確かに存在こそすれ、感謝の念や生活的依存により相殺されている。

【結論】
・眠いからもう寝る。

マジカルハッカー くるくるりすく

米シティグループがあんなことになったのが原因かどうかは判然としないけど、とにかくAmazonクレジットカードが誠実な意味でオワタ！になる。
しかしながら、シティカードの契約は当然続行。Amazonクレカは年内で使えなくなるが、それ以降シームレスにカードの利用が出来るようにと、昨日新しいシティーカードが送付されてきた…

いらねええええ！！！

Amazonクレカを作ったのはひとえにAmazonポイントが目当てであり、それ以上でもそれ以下でもなかった。誰が好んで何の特典もないシティカードの契約なんかするか…！
故に、送付されたばかりでなんだけど、週末にももう解約の手続きをしてしまおうかと。年会費も２回目の更新時からいるらしいしな。
んで新しくヨドバシカードを作ろうかと。なんだかんだで結構利用してるしね。VISA系列だし。

学生時代の時に学校の規約みたいなものでJCBカードを作って、その契約が残っているためまだ手元にJCBカードはあるんだが、VISAカードも持っていないといけない。
理由は、VISAの方が海外で使えるから。修学旅行でアメリカに行ったときにJCBカードはあんまり使えなかったことを確認した。
それはつまり、例えばアメリカの有料WEBサービスなんかを利用するときに不便を強いられることにもなる。
あるいは通販で海外のものを取り寄せるときとかも。
それに海外出張時も、JCBよりはVISAの方が心強い。

アルテルナータ可愛いよアルテルナータ

仕事がちょっと修羅場中。
正確に言うと、修羅場になる可能性があるかもレベル。僕の腕にかかっている。
てか納期が短すぎんだよ…チクショウ…しかも見切り発車気味だし。僕一人で開発するには規模が少しデカイ。複数のシステムに関係するシステムゆえ、アプリケーション設計が開発速度に即座に影響する。効率の悪い作り方してたら時間だけが一向に過ぎていく。幸い、システム設計自体は考え抜かれた汎用さを有しているので、相当な仕様変更がない限りは大丈夫だと思うが、そんな汎用さをプログラムとして実現するのは結構大変。

でも僕は勉強して、『インターフェイスによるコーディング』を心がけてる。デザインパターンのコアになるような部分なんだが、頭の弱い僕では理解するのに時間がかかった。

僕が勤務する会社では、開発するシステムには主にSQLServerを使用する。
そのため、ヒヨッコの僕は始め、SQLServerとの連携をクラス化し、こんな感じにコーディングしようとしていた。

Dim DBCon as new myDBConnect(Me._ConnectionString)
If DBCon.IsConnect() Then
DBCon.ExecuteSQL(Me.sqlquery)
End If

って感じに。DBへのデータ挿入等々、細かい実装は myDBConnect クラスで書いてある。SQLを引数に渡してあげたり、あるいはメソッドを実行するだけで、DBへの様々な処理を実現していたわけだが、ある日上司からこういわれた。

「もしもネットワーク障害が原因でSQLServerへ接続出来ない時のために、必要に応じてバックアップ用としてローカルに保持してあるMDBも参照するようにしようか」

僕が細かく実装してあった myDBConnect クラスはSQLServer専用クラスである。
中身には SQLClient名前空間のクラスやらメソッドやらプロパティやらがビッシリなのだ。

MDBも見れるようにするには、中身を全てODBCに変更してやる必要がある。
そうして作るクラス myODBCConnect は、myDBConnect とうまいこと併用しなければならない。
（ちなみに、SQLServerとMDBへの切り替えをmyDBConnectクラスで実装しようとするやつはプログラマ失格だと思う）
例えばこんな感じ。

Dim DBCon as new myDBConnect(Me._ConnectionString)
Dim ODBCCon as myODBCConnect

If DBCon.IsConnect() Then
DBCon.ExecuteSQL(Me.sqlquery)
Else
DBCon.dispose()
ODBCCon = new myODBCConnect(Me._ODBCConnectionString)

If ODBCCon.IsConnect() Then
ODBCCon.ExecuteSQL(Me.sqlquery)
End If
End If

僕「上司！MDBにも対応してやったぞ！」
上司「ご苦労！」

話がここで終われば万々歳。
しかしながら、仕様というのは変更が重なるものだし、要求というのは日々噴出してくるものだ。

例えばここで

上司「すまーん、Oracleも付け足してくれ」

なんていわれたら、これはもうたまらん。
クラスは一つ増やすだけだけど、コードが非常に見にくくなる。
せいぜい出来ることといったら

Select True
Case SQLDBCon.Isconnect

Case MDBCon.Isconnect

Case OracleCon.Isconnect

End Select

ぐらいのものだけど、処理効率としてはあんまりよろしくない。

そこでインターフェイスを使ったコーディングがモノを言う。
インターフェイスというと、クラスに対して共通のメソッドを用意できちゃうぐらいの認識しか持たれてないので、イマイチ何に使うのかよくわからないことが多い。というか僕はメリットがまったくわからなかったクチだ。だってImplementsだけして実装は各クラスの中で、って、なんかまだるこっしい。

しかしながら、『そのインターフェイスを持つクラスなら何でも実体を代入することが出来る』という用法に気付いたとき、インターフェイスの強力さが垣間見えた。

つまり、上記の例で言うとこういうことだ。

Dim IDB as IDBCon ←インターフェイスをフィールドとして持つ

IDB = new SQLDBCon(...

If IDB.Isconnect = false Then
IDB = new MDBCon(...
End If

If IDB.Isconnect = false Then
IDB = new OracleDBCon(...
End If

IDB.ExecuteQuery(Me.sqlquery)

この場合、
SQLDBConクラス、MDBConクラス、OracleDBConクラスは、IDBConインターフェイスを実装している必要がある。
即ち、各クラスはIsconnect関数とExecuteQuery関数を既に実装しているわけだ。
その前提さえあれば、インターフェイスに対してクラスの実体を代入することが出来、とても高い柔軟性が得られる。

例えばここで上司が

「水上くん、すまん、Postgreにも対応しなきゃならん可能性がある。いつでも対応できるように考えておいてくれ。」

なんていわれたら、最初だとIf文見直しから始めないといけなかったけれど、
インターフェイスを用いてコーディングを行った場合、クラスだけ作っておけば後からいつでも追加することが出来るってわけだ。

インターフェイスって便利ですね。

さらにさらに、Gang of Fourのデザインパターンを組み込むと、コーディングはさらにこうなる。

Dim IDB as IDBCon
IDB = new Factory.GetAdaptableDB()

IDB.ExecuteSQL(Me.sqlquery)

すっげ簡単！
ちなみにこれ、何かというとFactoryMethod。
いや、AbstractFactoryなのか？まだその辺よく区別ついてないけど、とにかく必要に応じてクラスを生成することの出来るもの。
Factory.GetAdaptableDB関数の中で、接続することの出来るDBを見つけ出す処理を走らせ、最後に

Return new SQLDBConnection(ConString)
だか
Return new OracleDBConnection(ConString)
だかなんだか知らないけど、IDBインターフェイスを備えたクラスを戻り値にしてやる。
すると、使用する側から見れば、どのDBを使っているのか『意識することなく』、DBを利用出来るってわけです。
クラスを生成する責務を担当したクラスがFactoryクラスだから、新しいDBを追加したりする際にはFactoryクラスだけをいじってあげればいい。

便利だなあああああああああああ！！！！！！！！！

ちなみに余談だが、プログラミングのインターフェイスはこのように概念的かつ職業的でわかりにくいけど、現実世界のものにたとえるとインターフェイスってものが途端にわかりやすくなる。
現代の発明品の中で、最も優れたインターフェイスを持つものは何か？という問いかけに対しては、『車』が上げられる。
車の種類はアホほどあるが、どんな車にも、
・燃料を補給
・ハンドルを回せば向きが変わる
・アクセルを踏めば走り出す
・ブレーキを踏むと止まる
と言う『機能』があり、全ての車はこの機能を搭載する。

だから、教習所でこの機能の使い方を学ぶだけで、（乗用車なら）どんな車でも運転できる資格を得ることが出来るようになる。
車の定義が種類によってバラバラなら、乗りたい車の数だけ教習所へ通う必要があったんだろう。けど僕らがそうする必要がないのは、車が明確なインターフェイスを持つから。

これをヒントにすれば、色んな物事を俯瞰して考えることが出来るようになり、とってもオトク。

『しくじったら、そん時は暴れて終わるさ』

アメリカの海外ドラマである『SUPERNATURAL』のシーズン３を全話見た。
このドラマは、超常現象に遭遇した不幸な人たちを助けながら旅をする二人の兄弟の物語だが、僕が今まで見てきたコンテンツの中で一番アツイ兄弟愛が描かれた作品だ。（もちろんアッー的な意味ではなく。てか二人ともイイ男なので腐女子な方々にはたまらない作品だと思うのだがどうだろう）

SUPERNATURALを見る利点は
１：世界中の説話・神話・寓話・伝説・怪物・悪魔などのフィクションな話題に通暁出来る（そしてwikipediaへのアクセス回数が増える）
２：ロックでクールな男に（気分だけ）なれる
３：家族を大事にしようと思う
４：涙腺が爆発する
だ。



＊以下、ネタバレ









二人の兄弟は様々な困難や危機を助け合って乗り越える。悪魔や怪物に片方が囚われても、もう一方が身を捨てても助け出すと言った具合に。
兄弟の父親は、息子たちを助けるため、シーズン２のラストに強大な悪魔によって地獄へと送り込まれてしまった。
その悪魔の手が兄弟にも迫り、シーズン３全編を通して回避策を練る。
しかし迎えた結末は悲惨。回避策は実現ならず、兄弟は引き裂かれてしまう。
最後の最後まで離れ離れになるまいとしていた兄弟だが、運命には抗えなかった。
弟は兄の死を嘆き、兄は弟の名を地獄から叫ぶシーンでシーズン３は終わる。

兄のいない状態でシーズン４は始まるのだろうけど、実際どう話が進むのだろうか。
基本的なストーリーとしては地獄から家族を救い出すという方向なんだろうけど、SUPERNATURALの醍醐味である、笑いあり涙ありのロードムービー的な冒険譚は二人の兄弟なくしては成立しえないように思う。

このSUPERNATURALは他の海外ドラマと比べれば少し認知度が低いけど、僕の中ではランク３には余裕で入るぐらいの傑作。色んな人に薦めていきたいなあ。