kazuk は null に触れてしまった

C# / .NET 系技術ネタ縛りでお送りしております

カテゴリーアーカイブ: 開発

バッチかリアルタイムか


世間的にはHadoopみたいなバッチソリューションでの分析や集計がこれからはやるって方向なんですが、ちっと異議ありーってところ。
 
確かにKVSだとテーブルにキーは一個だけ、あってもたかが知れてる個数しかないのはご存知のとおり。
これじゃ多様な分析ニーズを満たすなんてことはぜんぜんありえナスな事。
 
でも1テーブルしか更新しないって前提であればそうだったりするだけで、分析のニーズに応じて複数テーブルをInsert/Updateすればいいじゃないって話。RDBMSのサーバがINSERT/UPDATEで物理テーブルと同時にいくつものINDEXを更新するのは周知の事実でそれをプログラムコードでやればすむって話。
 
このときにテーブルのキー構造とインデックスのキーは必ずしも一致する必要はないし、分析側のニーズで必要なINDEXがあるならそれを別々のINDEXテーブルに持てば良いわけで、これでwhereで使えるキーが制約されるとか、そんなのお構いナッシング。Hadoopとかに代表されるMapReduceを使うとかの以前に DAL からビジネスレイヤよりの場所で見れば複数インデックスが付いたテーブルに見え、DAL以降では複数のKVSテーブルに分散格納された構造を作るのは決して不可能なこっちゃなく。
 
フロントの負荷?インスタンス増やして分散しれ!なんのためのクラウドじゃって話だったりするし。
 
確かにこれまでのBIは OLTP からバッチ的にETLしてキューブ作ってという手順踏んできたしそれが効率の良い方法っていうか、必要とされる処理効率に対しての解がそうだっただけで、それを延々とやるわけにはいかんだろーし、「データが見えるまでのラグタイムが発生する」事をいつまで顧客が納得して受け入れ続けるか、リアルタイム更新での分析データを競合が出せると言ったらどうなるか。
 
KVSではキーに制約があって…、既存の OLAP の流れで バッチによるETLで… そこでMapReduceですよHadoopですよって、流れは普通なんだがあからさまに普通ですねー感もしないでもなく。
とりあえずKVSはどの層に属するもんなんだという点で考えれば「トラック番号、セクター番号」でIOするディスクより何ぼかマシ程度の物理層なんじゃねーかとしてみる方向もないわけじゃないっすよと。
広告

本番環境は出来得る限り早めに用意し、早期からビルドを定期反映する


表題のとおりなんですが、リリース直前/前後の無用なトラブルを避ける為の鉄則でございます。

ただし、これをやる事での弊害が有ります。

  • 早期ビルドの(当然の)不安定性についての雑音がすごく多くなる

早期ビルドなんてへたすりゃまともに動くのなんて数割にも満たないと言っても過言ではないって事を理解しない人が早期ビルドを見て大騒ぎします。

その道を理解している人が安易に「よくある事です」というと「そんな事よくあっちゃ困ります」とすごい剣幕で乗り込んでくるパターンは非常によくある事です。

「技術的に問題を考察し、バグレポートを適切に書ける人」に早期ビルドを見せるのは多いにメリットがあります。

うろたえた挙句に「説明を求む」等と言いだして会議を招集し開発時間を奪い結果的に邪魔をしそうな人には見せてもデメリットしかありません。

見せても邪魔にしかならない人こそ見せろって声がでかいので、うるさい奴にほど見せちゃいけません。なぜなら「うるさいだけの役立たず」となる彼らは不安なんです、だからこそ見た瞬間にうろたえ、邪魔にしかなってない事をやり始めるのです。

うろたえずに、今何をやるべきかを考えれば、不具合のパターンを洗うとかできるはずだし、結果的に開発チームに貢献する事もできるはずなのにです。

  • 毎回のリリース手間を消化しないといけなくなる

自動化重要、とりあえず自動化できないなら、この鉄則は逆効果を生みかねないのでやめましょう。

その場合のお勧めの策としては「本番環境へのインストールリハーサルです!」と言い切ってリリース物は確認したら削除しちゃいましょう。「リリース物を入れてみた時に不足するコンポーネントやその他が無い事を確認する」のが第1義で、「その後の変更で依存コンポーネントの増減が発生しておらず、確認済の手順でインストール可能である事を確認し続ける」のをトレードオフとしてあきらめる事ができればインストールされた早期ビルドの入った環境など捨てて良いんです。

という訳で、来月リリースな物の早期ビルドの展開スクリプトを書いているナウ。

技術的な意味での腕力


政治的な意味での腕力っていうと小沢ですかねー、って似たレベルのヨタに近いお話だったりします。

 

どっちかというと使わずにすませられれば良いに越したことの無い技術力の話し。

例: System.Net.Mail.MailAddress クラスのコンストラクタでのメールアドレス形式のチェックが強すぎて local part を “” で括ってもエラー

→ 問題の無いコンストラクタパラメータでインスタンス生成してからリフレクションでフィールド書き換えればMailAddressでのチェックを迂回できるよ。

こういう類の「むりくりでもねじ伏せる」系のアプローチを自分的には「腕力」って言ってます。(とは言ってもこんぐらいはデコピン程度?)

 

やれ「フレームワークでサポートされないので」、「一般的にこのアーキテクチャでは…」システムの序盤はさておき、そこで問題を解決できなければ駄目って局面では腕力重要です。世の中のシステムって、きれいごとではたいていは済まなくて、床板をちょっとずらして覗いてみてみれば魑魅魍魎が闊歩する世界がある方が普通です。

んで、この辺の腕力をどうやって身につけるかなんですが、物が腕力だけに「鍛える」しかなく、鍛えるすなわち「血反吐を吐く思いをする」しかないんかなーと。

華々しく美しいアーキテクチャの話やその他、勉強するのはいいんすけど、若いうちに鍛える事もお忘れなく。

何に問題を押し付けたって、「動けば正義」は存在するし、解決できない以上は使えない奴、駄目な奴評価を甘んじて受けるしかないのが事実です。

 

無駄に腕力を使う筋力バカになれって意味じゃないですけど、学校では教えてくれない泥臭いところでは腕力必須ですって話。