エクサデータの現実

最近Oracle社のエクサデータ関連の仕事をしているが
世間の評判とは違い、私の印象を一言で言うと
足が速いだけのバカ
です。
機体を極限まで工夫したおかげで最高速度は400km出るが、
肝心のドライバー(Oracleオプティマイザ)の人工知能が貧弱で
機体性能の良さが十分に生かせず、
街中、高速道路問わずしょっちゅう道に迷うわ
事故りまくるわで、全く言うことを聞いてくれない
自動運転車という例えがわかりやすいかもしれません。
どんなに道路情報(統計情報)を最新化しても、
ヘンテコなナビゲーションで、海に向かって
ひたすら突き進んでく始末。
間違った方向に行かないように、あらかじめ随所に緑のおばさん(ヒント)を
配置しておかないと、無事に目的地にたどり着けない幼稚園児レベルの低脳
この完成度、まだ売っていいレベルじゃないよホント・・

複雑なものを複雑なまま理解できない奴に単純化させるな

複雑な業務やシステムにはそれなりの理由があります。

賢いヤツは複雑なことを単純化して理解し説明することが得意と言われますが、中途半端にかしこい奴は自分の理解能力を超える複雑なことを、ろくに理解もせずに、経験則や思い込みだけで単純化して理解したつもりになり(自己洗脳)、多くの矛盾点に気づかず重要な情報が抜け落ちます。

プロジェクト全体がこの状態におちいっていないことを見極めるのが、要件定義の中で一番重要なことです。

大人数の会議ではシンプルな意見ほど合意形成がされやすく、発言力の強い人が理解できないレベルの複雑な意見は無視され、間違った方向に進みがちです。

複雑なものは複雑なまま理解してから体型的に整理し単純化することができないならば、その過度な単純化はただの劣化です。

OJTは無免許運転

IT業界では今年も新人が大量に配属され、OJTの名を借りた無免許運転が始まりました。
ユーザー企業が高いお金を払ってプロに依頼したはずのプログラムのほとんどは
ろくな専門教育も受けていない学生上がりのド素人が、ぶっつけ本番で現場投入され
納期に追われ、意味もわからないままやっつけ作業で作らされているのが現実です。
経営者はプログラミングの難易度を、居酒屋チェーンのバイト作業程度に思っているのでしょう。
当然バグが大量に出て、品質は酷いありさまです。
この数十年この業界に身を置いていますが、生産性は一行に向上する気配がありません。
また、自社要員のOJTならまだしも、下請けのOJTに付き合わされるのは勘弁して欲しいものであります。

VB.NETで外部アプリケーションを呼び出し、終了するまで再描画を停止せずに待機する方法

通常、VB.NETで外部アプリケーションを呼び出し、終了するまで待機させようとすると、呼び出し元プロセスが完全に待機状態となって
再描画すら抑制されてしまいます。

これを簡単に解決するためには、BackgroundWorker、ShowDialogを利用します。
以下のようなクラスを作成して、Runメソッドに実行ファイルパスを渡してやります。


Public Class ShellUtil

Public Shared Sub Run(ByVal pName As String)

Dim a As New DummyForm
a.pName = pName
a.ShowInTaskbar = False
a.StartPosition = FormStartPosition.Manual
a.Top = -1000
a.Width = 0
a.Height = 0
a.ShowDialog()

End Sub

Private Class DummyForm
Inherits System.Windows.Forms.Form

Public pName As String = ""
Private EndFlg As Boolean = False

Private Sub DummyForm_Shown(ByVal sender As Object, ByVal e As System.EventArgs) Handles Me.Shown
Dim b As New System.ComponentModel.BackgroundWorker
AddHandler b.DoWork, AddressOf DoWork
b.RunWorkerAsync()
Dim Timer1 As New Timer
AddHandler Timer1.Tick, AddressOf Timer1_Tick
Timer1.Interval = 100
Timer1.Enabled = True
End Sub

Private Sub DoWork(ByVal sender As System.Object, ByVal e As System.ComponentModel.DoWorkEventArgs)

Shell(pName, AppWinStyle.NormalFocus, True)
Me.EndFlg = True

End Sub

Private Sub Timer1_Tick(ByVal sender As System.Object, ByVal e As System.EventArgs)
If Me.EndFlg = True Then
Me.Close()
End If
End Sub

End Class

End Class


【呼び出し側】


ShellUtil.Run("C:\Program Files\Microsoft Office\Office\EXCEL.exe")

24時間365日稼動の嘘

オープン系システムにおいて、
「過去数年以上24時間365日稼動の実績があります!」
と言うセールストークを耳にした際には、必ず「計画停止」があるかどうかを
確認しましょう。


稼動実績に「計画停止」は含まないという回答が返ってきた場合には、
必ず、「計画停止」の頻度、最大停止時間、「計画停止」の通知が
どの程度事前に行われたかについて、詳細な実績データを提示させることを
お勧めします。

実際に24時間365日、休むことなくサービスを提供した実績があるシステムは
皆無であることがわかるでしょう。


基本的にシステムの可用性を高めようとすると、100%に近づくにつれ、
それを実現するためのコストが発散する傾向があります。

そのため、安価に高い可用性を実現できるという場合は当然何かカラクリがあると
思った方が良いです。


最近、流行のSLA(サービス品質保証)契約も約束した水準に満たない場合は
満たなかった分の代金を返却するというもので、
たとえば、月10万円のサービス料金、SLAで99.9%の稼働率を保障という場合、
サービスが10%しか運営されず、それにより大きな被害をこうむったとしても
1ヶ月分の利用料金(10万円)以上の保証は行われません。

99.9%の稼動そのものを約束せず、99.9%の稼働率を謳うことができる
サービス提供側にとって都合の良い契約形態なわけです。

VB.NETで固定長文字列を生成する。

システム間インターフェイスで固定長ファイルを扱うケースがあると思いますが、
VB.NETC#で固定長の文字列を作ろうとしても、そもそも.net framework には
標準で固定長文字列(ShiftJIS)を生成する機能が用意されていません。
全角(2バイト)文字を考慮すると、以下のような関数が必要となります。




''' -----------------------------------------------------------------------------------------
'''
''' 文字列を指定されたバイト数の固定長文字列に変換します。

'''
''' 対象となる文字列。
'''
''' バイト数(Shift-Jis)
'''
''' 固定長文字列

''' -----------------------------------------------------------------------------------------

Public Shared Function GetSJisFixedString(ByVal Str As String, _
ByVal ByteCount As Integer)

Dim wkstr As String = Str.PadRight(ByteCount)
Dim hEncoding As System.Text.Encoding = _
System.Text.Encoding.GetEncoding("Shift_JIS")
Dim btBytes As Byte() = hEncoding.GetBytes(wkstr)
wkstr = hEncoding.GetString(btBytes, 0, ByteCount)
If hEncoding.GetByteCount(wkstr) > ByteCount Then
wkstr = hEncoding.GetString(btBytes, 0, ByteCount - 1) & Space(1)
End If

Return wkstr

End Function

グローバル一時テーブルの使い道(SQLSERVER)

SQLSERVERの一時テーブルには、
ローカル一時テーブル(テーブル名が#〜)とグローバル一時テーブル(テーブル名が##〜)の2種類が存在します。
ローカル一時テーブルは、同一セッション内のテーブルを作成したスコープおよび子スコープからのみ参照でき、テーブルを作成したスコープの終了とともに自動的に削除されます。
それに対してグローバル一時テーブルは、別セッションからも参照でき、全ての参照がなくなったタイミングで自動的に削除されます。
通常、作業領域として一時テーブルが必要な場合、通常ローカル一時テーブルを使います。
では、グローバル一時テーブルの使い道は?

一つの例は排他処理(悲観的)です。
通常、悲観排他が必要な処理(画面オペレーションを伴うような処理)の最初に排他用のフラグをオンに更新して排他状態としておき、コミットした後、本処理を行い、処理終了のタイミングで排他フラグをオフに戻し排他状態を解除します。
ただ、これだと処理を途中で強制終了した場合に、フラグがオフに戻らず永久に排他状態となってしまうことがあります。(対策として定期的にフラグ戻しジョブを走らせたりします。)

クライアントプログラムから直接DBに接続するタイプのクラサバ型システムの場合、排他フラグをグローバル一時テーブルの存在状態に置き換えることで、この問題を簡単に解決することができます。

Webシステムなどの場合はこの方法は使えないため、排他フラグに排他時間を持たせるなどの設計が必要となります。