墜落日記 - 2008年の墜落 (最新10日)
2008年7月19日
メタボ検診
５月末くらい、朝方の極端な膨満感でのたうってからビクビクしつつ１ヶ月を過ごし、同じ症状が頻発するようになってしまって病院に行った自分。
エコー検査で唐突に胆嚢結石が見付かったのが 7/8 で、結石の先がエコー検査では見えないからと CT 検査で輪切りになったのが昨日。
ついでに血液検査の結果も貰ってきた。
結論から言うと、今回の色々な検査は結果としてメタボ検診となってしまった。
要は「太ってる、やせろ」ということである。
胃と腸の間に炎症が見付かったが、細胞を採取しての検査の末、単純な胃炎で悪性ではないとの結論が出た。
胆嚢結石は「うひょ～………」と思うくらい見付かってしまったが、素人考えで症状を調べていた胆嚢結石症ではないとの結論。
胆嚢結石自体は爆弾として保持していることが分かってしまったが、今回の症状には直接の関係はないらしい。
で、結局のところ問題となっていたのは食道裂孔ヘルニアらしい。
食道と胃の間、横隔膜をぶち抜いている部分の食道裂孔が弛んで、胃が胸部側にせり出している状態だ。
先天性の場合もあるようだが、自分の場合は太りすぎで腹圧が上昇して軽い食道裂孔ヘルニアを誘発したらしい。
食道裂孔ヘルニアの症状としては(1)むねやけ、(2)胸痛、(3)つかえ感が見られ、強く自覚するのは夜間就眠時（特に明け方）ということだ。
あ～、言われてみればまさにその通りの症状である………
血液検査の結果は自分が思っていた以上に正常値だったが、唯一尿酸値がやや高いという部分が見付かった。
ま～この辺りは年に一度の健康診断で分かってはいたのだが、取り敢えず万一のためにプリン体を控えることにする。
と言っても自分は日頃からプリン体を多く含む物を食する習慣はないので、意識して減らすにも限度がある。
だから尿酸を尿として排出するために、主としてやせる必要があることになった。
とどのつまりは日頃の不摂生が祟ったということである。
と言うわけで、今回の検査はメタボ検診の様相を呈してしまったわけだ。
う～ん………胆嚢結石も見付かってしまったことだし、不摂生な生活の改善作業から始めないと………(涙)
2008年7月13日
次のDD、MDD
ホームタウンドルパ大阪５で限定販売されるドルフィードリームとミニドルフィードリームの情報が出揃ったようだ。
今回のミニドルフィードリームは斬魔大聖デモンベインから魔導書アル・アジフの化身アル・アジフ、同じく魔導書ナコト写本の化身エセルドレーダ。
ドルフィードリームは新世紀エヴァンゲリオンより綾波レイ メイドドレスVer.と、惣流・アスカ・ラングレー メイドドレスVer.となる。
ま～なんちゅ～か、新世紀エヴァンゲリオンはかつて綾波レイだけＤＤ化していたけど、正直アレは結構お粗末と言うか、そんな感じだったし。
手に入れられなかった人や新世紀エヴァンゲリオンというだけで飛びつくフリークには良いかもしれないが、自分的にはイマイチ琴線に触れないしメイドドレスも全然欲しいと思わないのでスルー確定。
斬魔大聖デモンベインの方は、いくら何でも両方ともＭＤＤにするのは如何な物かと思うが………
たしかにアル・アジフもエセルドレーダも幼い外見はしていたけど、ＭＤＤほど頭身の狂ったキャラデザではなかったわけだし、あそこまで巨頭だと逆に違和感が………
いっそオビツの MIZUKI で頭だけ載せ替えるとかがスケール的には丁度良いかもとか思ってしまう自分が居る。
ま～逝くとしたら多分エセルドレーダかな？
自分的には今回で一番良さげなのはエセルドレーダだと思う。
ただ、妙にアイが深い位置にあるから、アイホールを裏側から削ってやらないと違和感バリバリなんだけどな(汗)
なんにしろボーナスも減ったしで経済的にきついので、逝くか逝かないかは不透明なわけだが………
そう言えば、「エセルドレーダ」って名前の響きは結構好きなんだよな～とか思ってみる。
元ネタは、大魔術師アレイスター・クロウリーが何匹も飼っていたブラッドハウンドの一頭である「レディ・エセルドレーダ」から来ているわけだが。
自分的にもこの名前はいつか何処かで使ってやろうと思っていたり(爆)
2008年7月8日
ドブネズミ共が手を組んだ
ドブネズミ共が手を組んだ。
言うまでもない。
ドブネズミ共とは Microsoft とアイカーンだ。
Microsoft は頼まれもしない Yahoo! 買収を持ちかけて（人それを敵対的買収という）、一端は引き下がった。
しかし今度は企業乗っ取り屋（要は金融ヤクザの一種だ）のアイカーンと手を組んで、Yahoo! の検索事業だけを買収しようとしている。
しかも Yahoo! 取締役会のクーデターによって手に入れようとする、どこからどう見てもヤクザの論理によって、だ。
Microsoft にとって Yahoo! の全社買収は損だ。
検索事業だけを手に入れれば Yahoo! をガタガタに出来るばかりか、最大の競争相手である Google と Yahoo! の提携ですら意味のない物に出来る。
だから、Microsoft とアイカーンは手に手を取って Yahoo! の解体に乗り出した。
Yahoo! 取締役会が言うように、アイカーンには Yahoo! の企業価値を高めるプランなど無いだろう。
アイカーンは Yahoo! を切り売りしてその過程で利益を得たいだけで Yahoo! の企業価値を向上させる必要はない―――尻馬に乗りたい投資家連中が Yahoo! の株価をつり上げるその最大瞬間風速だけでいいのだ。
だからそんな物は最初から持ち合わせていない―――金融ヤクザとは元々そう言う物だ。
このことからもアイカーンという金融ヤクザは長期的な企業価値の向上や既存株主の利益よりも個人の資産を増やすことにのみ興味があるドブネズミだと間接的に証明された。
Microsoft がドブネズミなのは今に始まった事じゃない―――Microsoft はソフトウェア企業でありながら何一つ自分で生み出して来られなかった世界一先進性の乏しい企業である。
まあ、実際ドブネズミ共の悪巧みが上手くいって首尾良く Yahoo! の検索事業だけを買収できたとしても、Microsoft が何か新しい物を生み出してこれる可能性は全くない。
そんなことは誰でも知っている―――世界共通の暗黙知だ。
だが Windows の標準検索エンジンが刷新され、Internet Explorer が Netscape Navigator を追い出し、Media Player が Real Player などを追い出したのと同じことが起こるだろう。
ビル・ゲイツは去るらしいが、下逸と呼ばれた Microsoft はこれからも残り続けるだろう。
だが、もしかしたら今後はビル・ゲイツが居た時よりももっと凄まじい下方向に逸脱する Microsoft が見られることになるかもしれない。
金融ヤクザと手を組んだ Microsoft、真の悪の帝国はこれからなのかもしれない―――
近況追記。
本日は仕事を休んで（何ヶ月ぶりの有給休暇だ？）、病院で検査。
エコー検査と内視鏡検査をやってきた。
で、エコー検査でイキナリ胆石発見………(涙)
日頃の不摂生がモロに出たけど、今回の症状としては胆石自体は関係ないのではないかとのことで、爆弾を持っていることだけ理解させられた(涙)
ま、極度に疲れたりしないかぎりは発作は起こらないとの事だし、発作が起こらない限りは放っとく類の物らしいので、極度の無茶はしないことだ。
―――って、仕事するなってことか？？
続いて内視鏡検査。
内視鏡検査は初めてだが、最近のは鼻から突っ込むらしい。
喉から突っ込んで「うごごっ」とか言うのかと思ったけどそうでもない………と思ったらやっぱり「うごごっ」だった。
（ま、昔よりは遙かに楽なんだろう、涙目になる程度で済んだし）
で、内臓は食道から胃、十二指腸辺りの腸の入口までまんべんなく調べて、なにげにキレイだったみたいだ。
ただ、胃と腸の間辺りに炎症が見られ（ポリープでは無さそう）、多分コレが原因ではないかと言うことで組織を採取。
ちなみに、内視鏡検査はその一部始終を見せて貰った。
で、正式な結果は後日と言うことになった。
ちなみに胆石が見付かった絡みでエコー検査では見えなかった部分があるので、同日に CT 検査で輪切りになる予定………(涙)
さてさて、日頃の不摂生は認識済みとしても、どうなることやら………
更に追記。
先日、共通部品をイージーに直されて腹立っていた件だが、修正点を解析した時の自分の記憶が定かなら潜在バグが発生しているはずだと、湯船に漬かりながら思い至った。
明日出社したら早速調べてみるつもりだが、もし本当に潜在バグが見付かったらまた怒り狂うかもしれん。
こんな事やってるから胃炎なんか起こすんだろうな………(涙)
2008年7月7日
死んで治る馬鹿は大したことない
随分昔に 4,000 行から 5,000 行が BEGIN と END の間に敷き詰められている、無茶苦茶に低脳な PL/SQL で壮絶に腹が立った話を書いたと思うが、また、似たようなヤツと取っ組み合いしている。
今回は前回よりもやや少ない 3,000 行程度だが、なんちゅ～か………
-
やたらとデカイ、主部の BEGIN ～ END。
深く入れ子になった IF ～ THEN ～ ELSIF ～ ENDIF と DML の羅列で異様に追っかけづらい。
しかもインデントが不揃いという爆弾付き。
-
グローバル変数かと思ったら実は実質ローカル変数だった変数群。
もしかしてこいつはローカル変数の存在自体を知らないのでは？？
宣言する場所を変えただけでグローバル変数が半分減ったっ！！
-
やるだけ無駄な中途半端なハンガリアン記法。
変数の接頭語には "w_" を付けているにもかかわらず（多分 "work" の "w" だ）、定数にも "w_" が付いていて代入式を探す羽目になる。
見付けてみたらプロシージャの先頭で CONSTANT 宣言されていた。
-
Ｚ読みに近い目視検査だけでぞくぞく見付かる潜在バグ。
こんな物が共通部品として我が物顔で動いているかと思うと寒気がする。
ホントこのコードを書いた本人は、このコードが素晴らしいと自分で思っているのかね？
低脳の証明にしかなっていないこのコードを！？
億単位の大規模プロジェクトに集められる要員のレベルの低さと言ったらホントに想像を絶する物があるが、「何で自分はこんな巫山戯た糞ソースと取っ組み合いしてるんだろうか………？」と本気で悩むことがある。
プログラマの 35 歳定年説がまことしやかに囁かれているが、これは多分、最新技術に追い付けなくなるとかそう言う類の話ではない。
10 年もこんな巫山戯た糞ソースと取っ組み合いしてりゃ、辞めたくもなる。
これはもしかしたら IT 業界の構造的な問題だ(爆)
（ちなみに自分はまだ 35 歳前だし 10 年も続けていない）
さて、そんなこんなで色々とあって悶々としつつ下手すりゃまた暴れ出しそうな精神状態の自分だが………ちょっと面白い本を見付けた。
面白いと言うか、職業的プログラマ連中に是非とも読んでほしい本だ。
-
すべてのプログラマに効く
危険なプログラムの処方箋
(ISBN978-4-7973-3873-7)
職業的プログラマの量産する禁じられたプログラムに関して実例を交えつつ何がダメなのか、なんでダメになったのかを述べている。
後半は C や C++ に特化した禁じられたプログラムも多くなるので若干普遍性が薄れるが、それでも全体的に見て普遍性のある内容が網羅されている。
プロジェクト管理などのマネージメント上の問題ではなく、あくまでも禁じられたプログラムというソースコードレベルの内容を重視しているのも良い。
C や C++ に特化した内容が書かれているにもかかわらず C や C++ を高級言語と認めていない部分もよい。
この作者は C や C++ をアセンブラと同様の低級言語だとちゃんと認識して書いている。
そして何より、これを読むと自分が常日頃からイライラしているダメコードがほぼ網羅されてしまうからよい。
脳味噌が破壊され尽くした２年目、３年目の連中に対して行う再教育プログラムの導入部には、この本の内容は非常に良いかもしれない。
つまり二等兵以前のお笑い三等兵共に「きさまらはクソだ、そびえ立つクソだ」と最初にストレートパンチをお見舞いできるのである(爆)
まだ半分も読み込んでいないが、これは一読をオススメする。
2008年7月6日
再教育プログラムの必要性
この土日、共通部品をイージーに直されて腹立った事件から回復できず悶々としていたのだが、今日の夕方に結論を出した。
その共通部品がさる事情で別プロジェクト向けにフォークしていたので、現在進めている案件のついでに統合して運用・メンテナンスを簡素化しようと目論んでいたのだが、共通部品をイージーに弄りくさる事象が現実に発生したので統合を見送らせてもらう旨を提言する。
共通部品をイージーに弄って、弄った本人が全く知らない別システムがすっこけて損失が出るよりはずっとイイが、ハッキリ言って屈辱だ。
こんな些細なことで警戒線を張らなければならないほど、自分のやった共通化は脆弱な物ではなかったはずだ。
さて、経緯は別として、今回のことで色々と思ったことがある。
と言うか、ビジネスで職業的プログラムをしていて常々思っていることを今回の件で認識し直したわけだが、とにかくまともなプログラマは希少であるし、量産されたダメなプログラムは殊の外多いということである。
グローバル変数を多用してドコで何が起こるか分からないプログラムがある。
１メソッドの行数が数千行のプログラムがある。
意味のないコメントや巫山戯たコメント、間違ったコメントが書かれたプログラムがある。
そもそも構造化すら考えられていない、オブジェクト指向ではなくオブジェクト試行ないしオブジェクト嗜好なプログラムがある。
その他色々、小はコードの書き方から、大は実装ポリシーまで、枚挙に暇がない。
驚くなかれ、ビジネスで構築されたプログラムにこそこの手のダメなプログラムは多い。
自分も大した能力を持っているわけではないが、その自分から見てもどう考えても目に余る物が多すぎる。
プログラムは動けばいいのではない。
正常に動き、可読性が高く、仕様変更が容易であって初めて良いプログラムと言える。
かつてスイス連邦工科大の Niklaus Wirth 教授は教育用言語として PASCAL を作った。
ALGOL の流れをくんだこれは、Edsger Wybe Dijkstra によって提唱された構造化プログラミングに取り組んだ言語として、後の言語の元になっている。
しかしココで言う教育用とは、ずぶの弩素人相手の教育用ということではない。
ココで言う教育用とは、COBOL なんかでプログラムを囓った人間相手に正しいプログラミングを教育する為の教育用という意味である。
これと同じ事をやらなければならないのかもしれない。
つまり、唐突に VisalBasic や JAVA なんかでプログラミングの世界に入って、ろくな教育も受けないまま、構造化プログラミングもまともに出来ずに脳味噌が破壊され尽くした２年目、３年目の連中に対して、再教育プログラムを考えないといけないのかもしれないのである。
しかしこれは一大事だ。
脳味噌が破壊され尽くした２年目、３年目に対して、エレガントで普遍的なコーディングを教えるためにはどうしたらよい物か………？
何をやってはいけないかは身の回りにあるプログラムを見渡せば実例に事欠かないが、正しいプログラムの例は驚くほど少ない。
（そもそも“正しい”という考え方自体が宗教論争的で微妙だ）
言語の選定も大変だ。
ガーベージコレクションを前提とした言語や、CPU に対しての高率化を最優先した摩訶不思議な仕様を抱えた言語では普遍性がない。
どうする？
これは本気で取り込むとそれだけで本が書ける内容になるぞ？
取り敢えず読んどけ的な本があればよいのだけど………探してみるか………？
2008年7月4日
自分は真性の手前勝手プログラマらしい
今日は自戒を込めて墜落してみる。
自分は真性の手前勝手プログラマらしい。
ちょっと本気でそう思った。
「真性のプログラマ」なのではなく「真性の手前勝手プログラマ」である。
例えるなら、そう、オープンソース開発やエンタープライズな大規模開発に居てはいけないタイプの手前勝手である。
で、どうして唐突にそう思ったのかというと………
自分のコントロールを離れてしまったソースを久しぶりに眺めて、自分の設計理念と 180 度違う修正をされていることに気付いて、本格的な怒り狂ったのである。
その修正に関連するデータベースのテーブル定義の変更を調べて、そのあまりの節操の無さに机を思い切り殴りつけた。
ソースを詳細に解析する間、鬱屈した気分を抱え込んでイライラが収まらなかった。
自分の努力が全否定された気がして、全てがどうでも良くなった。
冷静さを取り戻すのに１時間かかった。
冷静さを取り戻してから修正の経緯を問い合わせたのだが、いきなり電話しなかったのは僅かばかり残った忍耐力のなせる技だろう。
正直、危なかった。
ちなみにそのソースコードは共通部品として徹底的にチューンしていた。
自分のポリシーとして、共通部品には特定の呼び出し側の事情を勝手に認識して有効にされるような処理を仕組んではいけないと考えている。
どうしても仕込まなければならない場合、端から見ると共通部品のひとつのモードの様に振る舞うインターフェイスを構築して、呼び出し側にその機能の有効化を指示するように求める。
もちろん呼び出し側がその機能を有効化しない場合には今までと同様に動作する。
それが特定の呼び出し側の為だけの処理であると使う側に気付かせない様にして、共通部品としての独立性をギリギリまで維持するわけだ。
前述の通り、そのソースコードは共通部品として徹底的にチューンしていたので、特定の呼び出し側だけに必要なコードが無節操に入り込むのは自分の設計理念と 180 度違うわけである。
その自分の設計理念と 180 度違う実装は共通部品の共通部品たる独立性を阻み、利用する側に無用な考慮や注意を強いることになりかねない。
それは共通部品としてエレガントではないダメ実装、と、思うのである。
だが、そのソースコード、たしかに最初にコーディングしたのは自分だが、そのコントロール権は自分にはない。
ぶっちゃけちゃうと他人の持ち物であって、自分が四の五の言っていい類の物ではないのである。
つまり怒り狂うこと自体が筋違いなのである。
心の片隅に残った冷静な部分がこの認識を叫んだから、なんとか踏みとどまれた。
さて、そう考えると自分の悪癖が見えてくる。
自分が最初にコーディングしたソースに対してコントロールを維持したい、そのソースコードに対して最初の自分の理念を貫かせたい、自分はそう思う傾向が強い―――が、そう思うのは少なくともエンタープライズな大規模開発では邪魔な思想だ。
たとえ共通チームのチーフプログラマだとしても、そんな自分勝手は通らない。
それに大規模になればなる程に底辺の開発者のレベルはどん底まで落ちるから、事実上コントロールしようとする行為自体が無理になることもある。
呼び出し側のソースのクオリティを維持することも難しいばかりか、共通化チームが構築する共通部品ですら最初の自分の理念が維持できないことも多い。
そんな現実の中で敢えて組織的に特定のソースのコントロールを特定のプログラマに委ねていたら、単純にそのプログラマがクリティカルパスになって危険性が増すだけだ。
ではこれがオープンソースだったらどうだ？
オープンソース開発では最初の内はよくある伽藍方式だろうが、成熟していくとバザール形式に移行するケースがある。
伽藍方式はどちらかと言えば企業などで一般的に行われていたり、クローズドソースなフリーウェアの形式であるが、バザール形式はもう見事なまでにフルオープンだ。
四方八方からアイデア、意見があつまり―――それ自体はとても良いことだ―――そのコーディネートを中心人物が行うか、議会形式で決定する。
そうなるとお互いの話し合い、意見の応酬は当然あるだろうが、自分の最初の構想と 100% 同じ方向を向くとは考えにくい―――自分も納得する方向転換なら話は別だが。
ここで自分のような意固地になる人間がいると、プロジェクトに不協和音が生まれるか、さもなくばフォークしてしまう。
建設的でないフォークはむしろ貴重なヒューマンリソースの分散を招く罪悪で、自分の癖はその引き金になりかねない。
結局、どちらのケースでも自分の癖は邪魔になる気がする………(笑)
う～ん………結局なにか？
自分が人様に迷惑かけないようにするためには、ひたすらに独立独歩でいくしかない、という事なんだろうか………？？
大きな仕事には参画せず、自分一人で制御しきれる程度のソースコード量の仕事をちまちまと片付けて日銭を稼ぐような………個人事業主？？(爆)
さもなければ最後まで自分がコントロールを維持できるパッケージでも作って売り歩くか………？
う～ん………(汗々)
2008年7月3日
Scalix 11.4 リリース日確定、らしい
現在導入準備をすすめつつ試している Scalix だが、最新版の 11.4 日本語版のリリース日が 7/10 に確定したらしい。
今回目玉になりそうなのが、自分的には、
- Firefox 3.0 への正式サポート
- CentOS 4、5 への正式サポート
あたりかな？
CentOS 5 系最新で Scalix サーバを構成して、Firefox 3.0 で利用するという、現在目指している環境が全て出揃うわけである。
これで本格的にメールサーバの移管に踏み切れそうな気配だ。
詳しくはこちらで。
2008年7月1日
検索するな、マニュアル読め
ここ数ヶ月煩っているというか、のたうっている胃痛だが、とうとう本日病院に行ってきた。
ま、初診だったりしてイキナリ検査とかいうことはなかったが、来週エコー検査と内視鏡検査をしてくる予定。
単純に胃の働きが弱っているか、胃幽門狭窄症だろうという話だが、最悪だと胃潰瘍の疑いがある様だ。
なんか胃痛で病院に行くって、切なくなってきた………俺ももうそんな歳か………(涙)
で、今日の本題はソコではない。
最近の若い連中、特に１年目とか２年目の初学者ですらないペーペーがプログラミングしている姿を見ていると、ふと思うことがある。
何か分からないことがあるとまず Google で検索しているのである。
で、氾濫する情報の中から正しい情報が選別できずに時間だけ掛かっている………
いや、お前ら、まずはマニュアルを読め。
安易に Google に頼るな、むしろググるな。
予測で適切なキーワードを指定する能力も、溢れる情報の中から正しい情報を選び取る能力もない、まったく経験の足りないずぶの弩素人が、Google 検索でどんなに頑張ってみたところで糞の役にも立たない。
精々が無駄な時間ばかりかけて「取り敢えず動いた」でバグだらけの役に立たないコードを量産するだけだ。
根本的に間違っている。
たしかに Google なんかで検索するのは便利ではあるが、それは情報の取捨選択が出来る基礎知識が備わっている人間の言うことであって、基礎知識のない人間は素直にマニュアルを読まなければいけない。
検索で情報を探すのは、あくまでも基礎知識を得た後の話である。
平気で最下層の成績をマークしつつなんとかかんとか学生を卒業できたような俺みたいな馬鹿よりもずっと勉強の仕方を知っているはずの連中が、なぜかここにきてそのセオリーをひん曲げている。
お前ら、勉強するのにイキナリ Google で検索したのか！？
三角関数が分かりませんとイキナリにググったのか！？ 違うだろっ！？ まずは教科書と取っ組み合いしたはずだ！！
と、思うのだが………
今日も弩素人が Google 検索で貴重な時間を無駄にしている………
もしかしてこいつら………
円周率が 3 だと思い込んでいる連中なんだろうか………？
検索エンジンが便利になった反面、人間はどこまでも退化していくのかな～と思ってしまう。
そう、まるで日本語変換が発達したおかげで漢字が書けなくなった俺のように(爆)
2008年6月24日
再考、技術革新と技術寿命
どうも、次期 PHP 6 でサポートされる名前空間が PHP 5.3 でもサポートされるらしい。
今まで PHP には名前空間のサポートが無かったので、キチガイじみた長い名前の関数名やクラス名が飛び交っていた。
その様はもはや魑魅魍魎が跋扈する地獄絵図だ。
自分が汎用的に公開されている PHP のライブラリを使いたくない原因のひとつでもあった。
これを解決する名前空間のサポートが PHP 5.3 にバックポートされるらしい。
（ま～元々は PHP 5 で名前空間のサポートがされるはずだったんだけどね）
ちょっと嬉しいニュースだ。
手元版 Ag:PURE の 2.0 を名前空間前提で再設計してみる価値がある。
で、こっそり次の案件で使ってみてバグ出しを………(爆)
そう言えば MySQL 5.1 の安定版もそろそろ出るのではないか？
今の所 Release Candidate だが、もう Generally Available になっても良い頃の筈だ。
ま～新型ストレージエンジン Falcon は MySQL 6 から標準サポートらしいから楽しみはまだ先なのだが………
なんちゅ～か基本的に新しもの好きだが alpha geek って程でもないので安定版を待ってしまうヘタレな自分ではあるが、PHP 5.3 と MySQL 5.1 はちょっとそろそろ試してみようかと………
考えてみれば PHP 5 は Beta から付き合ってたわけだしな(笑)
前置きはこの程度にして、本題に入る。
さて、最近は最新技術だ alpha geek だと最新技術を追っかけるのがトレンドというか、もはや強迫観念になっている感じがする。
最新技術に明るく、新しい技術を革新的な技術に育てていく、そしてそういう現場にいる技術者が英雄扱いだ。
しかし、はたしてこの風潮、現実的なビジネスの世界で本当に良い状態なのだろうか？
自分は必ずしも良い状態ではないと思ってしまう。
と言うのも、技術革新が速いことは、技術寿命が短いことと同義なのだ。
特にオープン系で技術寿命の短さは顕著で、これは企業生命を預ける基幹システムの構築に適さないことに直結する。
例えば 10 億円かけて Solaris + JAVA + Oracle 辺りで WEB の基幹システムを作ったとしよう。
しかし稼働してから 4 年後にはハードウェアの保守期限が来る。
（通常は 5 年だが、それほどの規模のシステムとなると稼働 1 年前程度にはハードウェアが用意されていることが多いので、自動的に稼働後の寿命は短くなる）
これが単純に保守期間の更新だけなら可愛いが、保守部品が無くなるから新しいハードウェアを買えと迫ってくるからたまったものではない。
さて、ではハードウェアの入替だけで済むかというと、ほとんどの場合は済まない。
5 年も経てば OS をバージョンアップせざるを得なくなる。
JAVA もきっと EOL を迎えてバージョンアップを余儀なくされ、それに伴いミドルウェアもバージョンアップ―――最悪の場合では代替策への入替―――が余儀なくされる。
そうするとプログラムの改修作業が発生し、設計、実装、単体、結合、総合、受入と必要になり―――結局 1 億円以上の追加投資と多大な内部工数が発生したりする。
よくあるオープン系で基幹システムを作った場合のシナリオだ。
これが昔の大型汎用機＋COBOLで組まれていたり何かすると、実は大型汎用機ってとっくの昔にハイパーバイザ形式の仮想環境になっていたりするので、文字通り載せ替えだけで済むことがある―――というか自分はそのケースを何度か目にしている。
オープン系は新しい技術でありながら大型汎用機＋COBOLという昔の技術の運用性能に遠く及んでいない。
これはオープン系が技術革新が速く技術寿命も短く、さらにオープンであるが故の問題の顕在化である。
IT 系の技術者や情報源は実はこの辺りを全く度外視して最新技術を追いかけているから質が悪い。
こんな技術はとてもではないが安心して企業生命を預ける基幹システムの構築には使えない。
企業は自分達の企業活動と直接関係ない技術と心中することは出来ないのである。
以上は仕事を進める上での問題だが、IT 技術者の人材という面でも実は問題があると思う。
掲示板での会話でふと思ったのだが、5/28 に開催された IPAX2008 で、IPA 理事長の西垣浩司氏が伊藤忠商事の取締役会長、丹羽宇一郎氏の「入社して最初の10年は泥のように働いてもらい、次の10年は徹底的に勉強してもらう」という言葉を引用しつつ「10年は泥のように働けます、という人は？」と学生に挙手を求めたところ、手を挙げた学生は 1 人もいなかったらしい。
（参考・引用：「10年は泥のように働け」「無理です」――今年も学生と経営者が討論）
この発言自体はプログラマから始まって、エンジニア、マネージャとステップアップする（日本型の会社組織でよくある型にはめられた）出世コースをイメージしているのだろうが、彼らが現役だった時代、果たして今ほど技術革新が速く、技術寿命が短かっただろうか？
そんなはずはない。
ぶっちゃけ大型電算機＋COBOL（オフコン＋COBOLと言い換えても良い）のパラダイムは 10 年やそこいらのスパンではなかった。
だから 10 年間泥のように働いてもその後に利用する技術基盤にさしたる変化はなかった。
しかし今は 10 年間泥のように働いてしまったら現場の仕事をまわす技術は付いてもその後の 10 年間を戦える技術は付かない可能性が高い―――つまり 10 年間の努力が報われるビジョンがない。
最悪 10 年という時間が単純に浪費されてしまう。
そんな現状では当然 IT 業界へのネガティブイメージはドンドン強くなり、タダでさえ人材が枯渇しているのに新しい人材が入ってこない閉塞状態に陥りかねない。
これは技術革新の速度と技術寿命の短さに経営陣が追いついていない悪い例だと考える。
最新技術を追いかけるのも良いし、alpha geek をやりたきゃやれば良い。
それ自体は悪いことではない。
その背後にあるのが加熱しすぎて崩壊寸前の資本主義経済（もしくはマネー主義経済）の暴走だとしても、IT 技術自体に罪があるわけではない。
だが、ちょっと立ち止まって、本当に必要な技術、本当に安心できる技術という側面から考えることもすべきだ。
それが企業生命を預ける基幹システムなら尚更のこと、技術寿命が長い、運用性能の高い技術も考慮すべきだ。
そして基幹システムをガッチリ固めた上で、戦略的フロントシステムを最新技術で運用するようなメリハリが必要になるだろう。
さて、貴方はどう考えますか？
2008年6月22日
自宅メールサーバ再構築開始
少し前に自宅サーバのハードディスクがヤバくなった時にメールサーバを別立てにしようと画策したわけだが。
メールサーバのハードウェア自体は用意が出来た。
型遅れの Northwood コア Pentium IV 2.8GHz と安い PATA ハードディスクで組んだだけなので耐障害性とか度外視していたりするが、ま～小型且つ低予算で組めたので良しとする。
んで、セットアップに勤しんでみた。
メールサーバとして利用、かつメールサーバに Scalix を利用するつもりだったので openSUSE を放り込んでやろうとしたのだが、なんだか面倒くさくなって、CentOS にシフトした。
CentOS 自体は Red Hat Enterprise Linux 互換だし、今回用意したハードウェアはもうなんちゅ～か枯れまくっているので、難なくインストール成功。
Scalix も最初の依存性解決の部分だけ気をつけてやれば難なく成功。
割と拍子抜けした。
ま、この後にサーバ機《みりぃ》の Postfix にスマートホストの設定したり、ネットワーク制御機《どったん》の Postfix の自ドメインメールの転送先を《みりぃ》から新型メールサーバに移行したり、テストしたりと後工程がタンマリ残っているのだが、それは追々やっていくことにしよう。
作業手順などに関しては、そのうち Ag:Techsol の方にでもアップする予定。
一応手順自体は全て記録しているので………(笑)
以下、追記。
仕事の合間にちょっと気が向いたので、まだ独立している Scalix メールサーバにユーザを追加してみる。
で、Scalix Web Access に Firefox が繋いでログインしてみると………
There was no SOAP-ENV:Body in the xml payload sent by the server.
と出てしまってログイン出来ない。
Internet Explorer 6.0 SP2 だと問題なく入れる。
ググッでみると Scalix Community Forums で Firefox 3 でこの問題が発生するらしき書き込みを発見した(涙)
どうもこれは Firefox 3 Beta の頃からずっと出ている問題で、Scalix 11.4 でないと対応できないらしい。
むっはぁ～！！ コンチクショーっ！！
Opera や Safari は最早当然の如くブラウザチェックではねられるし、SWA を使うには現状 IE しか無いってことか～………
知ってれば Firefox 2 を維持したのにな～………(涙)
