2008年8月18日月曜日

ECMA Script(≒JavaScript)の次期仕様に大変動

http://d.hatena.ne.jp/asip/20080818#1270774839

大阪桐蔭、優勝

1点を争う接戦になるかと思っていたので、あの展開は予想外だった。

在学時、初出場初優勝のとき、3年以外の在校生全員で甲子園で
応援したのも今はいい思い出、応援合戦のときは絵文字のパネル
の一枚を持ってました。

2008年8月14日木曜日

24時間365日サーバ/インフラを支える技術

高負荷サイトを実際に運営されている会社の方がこの本を
執筆されていることは勿論、この本をレビューして自分の
ブログの書評で高評価をされていた方もいたので購入しました。

発売前にAmazonで注文し、発売数日後に届きました。

自分(たち)のノウハウを公開しないポリシーの人間(会社)が
多い中、高負荷サイトのインフラ構築の技術的なノウハウ
が技術者の視点で詳しく書かれているこの技術書は
かなり貴重です。

読み始めたばかりですが、良い本です、勉強になります。

WEBサービスサイト等WEB系システムのインフラ構築に
携わろうとしている技術者だけでなく、インフラ上で動く
システムの開発に携っている(あるいは携わろうとしている)
技術者も読むとかなり勉強になる本だと思います。

今日の大阪桐蔭×東邦の試合、ABCテレビのアナウンサー、アナウンサー失格

あのABCテレビのアナウンサー、東邦が8・9回にチャンスを作ると
異様に東邦を持ち上げ、しまいには部員数まで持ち出して、個人的に
東邦の逆転を願っているのか東邦の逆転が既定路線のような発言まで
する始末、アナウンサーは中立が本分違うんかい、とむかついた。
おまけに、試合後に「桐蔭が相手のミスに"つけこんで"得点を重ねた」
(「桐蔭が相手のミスを上手くついて得点を重ねた」と発言すべきところ)
「一本(ホームラン)が出れば桐蔭を立ちすくませることができた」
等の発言をする始末、あのアナウンサー、アナウンサー失格。

何故、むかつくかというと大阪桐蔭は母校だから。自分の在学中あたりは
並の進学校だったけど、卒業してから数年後に中高一貫にしてから
進学校としてかなり躍進したと風の噂で聞いた。
ちなみに野球部等体育会系は別コースとなっていて、文武両道というわけ
ではありませんでした、在学時。今も別コースのまま変わっていないと
思います。

今回に留まらず、本来中立であるべきアナウンサーが自分の個人的な見解
や自分の考えで発言するようになっている、放送局の堕落だろうか?

Intel MacでVMWare Fusionを使っていて困ること

WindowsPCのキーボードにあわせてFedora・Ubuntu等の
Linuxディストリビューションのキー配列が設定されているので
これらをVMWare Fusion上で動かしているとMacのキーボード
とのキー配列の違いで困ることがある。
このためだけにWindowsPC配列のキーボードを買うのもなんだし
どうしようか...とりあえずもう少し調べてみることにする。

2008年7月25日金曜日

SIerで優秀なPGの給料が低い=>OSS開発で評価UP??

ここ。会社から評価されるためにオープンソースをやろうと
書いているようにみえる、会社からの評価を目的にするのでは
志が低いし...長続きしない。朝から終電まで(場合に
よっては土日も)プログラムを書いている人間に、リフレッシュ
するための僅かな余暇を削ることになる、効果があるかわからない
行為を推奨するのはどうかと思う。
(三度の飯よりプログラミングが好きという人間はトライしてみても
いいとは思うが...)

オープンソースのプロジェクトを開始するにしても2番煎じ
(猿真似)では評価されない、新規性がないと駄目等、開始するに
あたって注意すべき事柄は多い。

会社から評価されるためにオープンソースをやろうと書くのなら、
作るプロダクトに関してのアドバイス等、自身の経験を踏まえて
の実践的な内容にしないと、リンクした文章のように中身のない
空っぽな文章になる。

SIで優秀なPGが評価されないのはSI業界の構造的な問題(顧客から
の受注時に採用されている人月による見積もり等)が関係している、
それは一朝一夕に解決する問題ではない。

「オープンソースプロダクトの開発が(SIで優秀なPGが評価されない)
現状を打破する銀の弾丸になる」というような主張には何の根拠もない。
「オープンソースプロダクトの開発が上司に認められて
会社からの評価が上がったSIerの社員がいた」というだけでは
根拠にはならないのである。

会社からの評価UPを望むのなら、「オープンソースプロダクトの開発で
会社から評価を勝ち取る」などという不確実で非効率な手段よりも、
確実で効率の良い手段を探したほうが良い。

2008年7月21日月曜日

SIerの行うシステム構築は

利益を生み出すモノではなく、コストを削減するモノでしかない。
基本的に事務作業等の恒常性のコストを削減するのみ。

つまり、顧客にとってSIerの行うシステム構築の価値とは基本的に
コスト削減に尽きる。

コスト削減にすぎない以上、顧客はその年度の社内システム整備に
割り当てた予算の範囲内で社内システム構築に投資する。

自分たちの行うシステム構築が顧客にとってどんな価値があるのか
理解している若いSE・PGは少ない。

[追記]
SIerの行うシステム構築とは社会システム等公共システム及び医療
システム等の一部を除くと結局、事務作業等の恒常性の作業に関して
人間が行う作業のうち機械化できる部分を機械化して人間の手間を
減らすことで作業を効率化し、人的コストを削減するだけ。

効率化によって生じる時間的余裕を別の作業に振り向けることで
顧客に利益が発生したとしても、それはSIerの行うシステム構築
の産物ではない。

SIerのしくみとは基本的に

営業がプロフィットセンタ、SE・PGはコストセンタ。
営業は収入(≒利益)を生み出し、SE・PGはコストを生み出す
と考えて経営されている組織。

SIerの経営とは結局、営業がとってきた案件を如何に安いコスト
で仕上げ、利益(≒収入-コスト)を最大化するかという点に
尽きる。

最初に案件の生み出す収入が確定する以上、SE・PG
の携わるシステム構築フェーズで発生するコストを最小化
するしかその案件での利益を最大化する方法はない。

再度繰り返すが、SE・PGは本質的には(専門技術を有すると
いう点を除けば)、SIerにおいて総務部門等と同じコストセンタ
に属する存在である。

この点を誤解しているSE・PGは多い。

SIerにおけるSE・PGはクリエイティブな仕事でそれに見合った
対価が支払われるべきだ等の幻想は今すぐ捨てたほうがいい。
(SIerにおいてSE・PGが経営陣にコストセンタだと思われている
以上、見合った対価が支払われることはありえない。)

SIerの経営陣がSE・PGをコストセンタからプロフィットセンタに
位置づけし直すことはありえない。

2008年7月20日日曜日

Perl6は何処にいった?

Perl6の登場がアナウンスされてから5年以上になるが、未だ実用に
足る実装が出ていない。

数年前、Ruby2.0(Rite)とPerl6、どちらが早くリリースされる?かは
未知数だった。

ところが、蓋を開けてみると、現状はこうだ。

Rubyは2.0(Rite)のリリース前に先鋭的な機能を見送りVM化に
重点を置いた1.9.0(開発版)が昨年末にリリースされ、今現在も
1.9.1(安定板)のリリースに向けたブラッシュアップが今年の
クリスマスに向けて行われている。

対して、Perl6はHaskellで実装されたPugs等の実装が登場した
ものの、その全機能を俯瞰できる実装は未だ出ていない。

リリース競争におけるRubyの勝因は先鋭的な機能を見送り
(機能を絞り)VM化に注力したこと、笹田氏がYARVを開発し、
VM化のキーパーソンとなったこと等が挙げられる。


RubyのVMであるYARVとPerl6のVMであるParrotのスタンスの違いも
開発速度に大きな差を生じさせている。
YARVがRuby専用のVMとしてポジショニングされているのに対し、
Parrotは最初から多言語用の汎用VMとしてポジショニングされている
点である。
長期的には汎用VMを指向するにしても、短期的には特定の言語に特化
したほうが実装コストを削減でき、早期リリースに繋がると思う。

汎用VMとして成功しているのは.NetのCLRくらい、これは大企業が
フルタイム開発者を動員して開発しているからできる芸当だろう。
M$はスクリプト言語用にDLRという汎用VMをリリース済み
(開発続行中)。
.NetのOSS実装Mono、SilverLightのOSS実装MoonLightは共にOSS
ではあるものの大企業(Novell)がフルタイム開発者を動員して開発
しているという点ではオリジナルと同じ。
大企業がかまないOSSで同規模のことをやるのは難しい。

DLRにしても、1.0ではJavaScriptのみに対応し、2.0でのRuby、
Python等対応予定となっている。

よもやま話を一つ。
汎用VMとして将来有望なのはLLVM(Low Level VM)、ネイティブ
言語に適用でき、動的最適化可能という変わり種。既に
Mac OS X TigerのCore Image等での採用実績がある。


RubyとPerlはそのリリース戦略に大きな違いがあった。

Rubyは先鋭的な機能を盛り込んだ2.0のリリースに注力するよりも、
Ruby1.8の機能をブラッシュアップしつつ、VM化した1.9をリリース
するという現実的な解を選んだ。

(Pythonも先鋭的な機能の投入を抑えた現実路線を選択している。)

Perlは先鋭的な機能を盛り込みつつ、OO言語として生まれ変わり
VMの入れ替えも行うという姿勢を崩していない。

Perlも先鋭的な機能の搭載を保留し、OO言語化に的を絞った
バージョンのリリースに専念した方がよいのではないかと思う。

Perlの現状のリリース戦略ではPerl6のリリース時期は不透明すぎる。


Perlの開発期間の長さも、Perl6のリリース時期を予測不能にしている。
現行安定板5.10の開発に5年以上が費やされている。

Perlの「1つのことをするのに複数の方法を用意する」という設計思想
が、実装を複雑にし、開発の進捗を遅らせている点も無視できない。

開発期間の長期化は現実のニーズとの乖離を引き起こす可能性がある。


スクリプト言語のトレンドやニーズの変化は見逃せない。

5年以上前に策定されたPerl6の仕様が現在のニーズにマッチしているか
甚だ疑問である。

...Perl6の仕様、昨年末にFixされる予定だった模様。Fixされたのだろう
か?Fixされていないとすれば、そのリリース時期は更に混沌としてくる。

Perl6のリリース時にその時点でのニーズにPerl6がマッチしている
とは考えにくい。

だからといって、新しいニーズをどんどん仕様に盛り込んでいると
何時までたってもPerl6はリリースされない。

Perl6の仕様を再考しないと何時までもリリースできないのではない
だろうか?

ここによると、今年のクリスマスまでにPerl6の最初のアルファ版が
リリースされるらしい、ホンマかいな。安定版が何時リリースされる
かは全くの未知数。

#Perl自体はPerl5.xで既にVM化されていたので、修正しました。

2008年6月18日水曜日

「Springの生産性」への狛犬もどきの反応

 ここ。あいかわらず「KY」な連中...。個人が好き勝手に
書いていることに逐一反応する。いい加減、きもい。
数年前から何の成長もみられない。

個人が自分の思いで書いているブログに100%(?)の論証を求めること
自体、間違っていることに全く気づいていない。
自分達は自分たちのプロダクトの優位性について100%(?)の論証が
できていると思っているに違いない、できていないんだが...。
この連中、反論すればするほど、相手の反論の粗を探してそこを攻撃
してくるから反論するのは時間の無駄。

この本文の著者は本当に書きたいことの半分も書けていないと思う、
いわば書きかけの文章。その文章に一々食いつく。
この著者が問題にしているのは「アーキテクト」としての生産性であり、
「プログラマ(製造)」の生産性ではないだろう。
それを読み違えて、この著者の「アーキテクト」としての生産性に対して
狛犬もどきの連中は「プログラマ(製造)」の生産性で反論していて全く
かみ合っていないように感じる。
「アーキテクトとしての視点で見れば、狛犬もどきの製品はこじんまり
と纏まりすぎていて工夫の余地がない」というようなことがこの著者が。
書きたかったことだと思う。
「狛犬もどきの製品はそのプロダクト群の中で完結していて発展性が
ない、また、かっちりと作られすぎていてカスタマイズの余地もない」
とこの著者は感じているのではないだろうか?
狛犬もどきの製品はそのまま使用するのには向いているが、カスタマイズ
の余地はない(あるいはカスタマイズするにはソースをいじるしかない)、
狛犬もどきの製品はカスタマイズを考慮されていない、
と感じている人間は案外多いような気がする。

#選ぶことが大事じゃなくて作ることが大事なのでは。
「KY」なひで〜コメント、作るコストは誰が負担するんだ。
自分が作るコストを負担する余力のある(あるいは帰社時間に融通のきく)
会社にいるからいえるんだろうけど、えぐいな。
クライアントがそんなコスト、負担しないのは周知の事実。
自分のスタンスを相手に押し付けるのはどうかと思うが、見事に押し付け
てるな。

追記:
  アーキテクト自身が生産性を考慮して、プロジェクトに最適化された
アーキテクチャとそのアーキテクチャに基づいた基盤を用意できれば、
プロジェクトの生産性も向上する、
個々の汎用プロダクト(部品)がプロジェクトの生産性を大きく左右する
わけではないと著者はいいたかっただけ。そもそも汎用プロダクト(部品)で
事足りるなら個々の案件にアーキテクトを配置する必要はない罠。

2008年5月30日金曜日

Kubuntu 8.04 KDE 4 RemixとKDE4

インスール時に使用言語を日本語に設定しているにも関わらずKDEが日本語化されない。
language-pack-ja.deb language-pack-kde-ja.deb
(Ubuntu 8.04 日本語ローカライズド Desktop CD のリポジトリから取得
をインストールするとKDEの設定画面で日本語が設定可能になる。

Fedora9とKDE4

Fedora9Betaで発生していた現象は流石に解消。
インスール時に使用言語を日本語に設定しているにも関わらずKDEが日本語化されない問題は放置のまま。
kde-l10n-Japanese-4.0.3-4.fc9.noarch.rpmをインストールディスクからインストールすると
KDEの設定画面で日本語を選択可能になる。

2008年3月29日土曜日

Fedora9BetaとKDE

インストーラでデスクトップ環境としてKDEのみを選択して
インストールしてから、再起動後にログインしようとすると
ウインドウマネージャの起動が途中で中断されてログイン画面
に戻る。

Fedora9のログインマネージャにKDEのセッションに関する設定
がないため、このような現象が起こっているようだ。

いくらGNOMEびいきだからといって、これはないだろう、Redhat。
ベータ版といっても...。この問題が解決するまでFedora9は様子見。

基本的にGnome嫌いなのでGnomeを使う選択肢は自宅マシンではない。
 

2008年2月27日水曜日

達人に学ぶ SQL徹底指南書

この本の帯には「DBエンジニアに必要なSQLの
正しい書き方・考え方が身につく」とありますが、この本はDBエンジニア
のみならずプログラマにもお奨めです。

自分は外部結合くらいまでを理解してそれから先には踏み出してきません
でした、その必要も感じてきませんでいた。

ところが、この本で目から鱗が落ちました。

SQLの初級者を中級者に引き上げる教科書が今までありませんでした
、今はこの本があります、その教科書になりうる一冊です。

図を交えるなど文章が工夫されていて、集合論等のえてして小難しく
なりがちなテーマがかなり解りやすく説明されています。

SQLのライティングレベルを初級から中級に引き上げたい人は必読の
一冊です。

2008年2月17日日曜日

SI屋の語るミッション

「お客さまのため、お客様第一」は建前、本音は別。本音を建前でくるん
で誤魔化しているだけ。顧客の前では建前を本音のように語ることも必要、
それが駆け引きというかセールストーク。
SI屋が建前を前面に押し出すと苦労するのはそのSI屋の下についている
人間。本気で「お客さまのため、お客様第一」と思っているSI屋がもし
いれば、ついていくのは危険、そんなSI屋はまずいないが...。
「お客さまのため、お客様第一」を本音的に掲げるSI屋の下についた
人間はきっと土日出勤・徹夜当たり前の日々を(定期的に?)エンドレスに
送ることになる。数年(10年以内)でリプレースされるシステムにそこまで
自分の時間(人生)を捧げることに意味があるのか、甚だ疑問。そのSI屋へ
のそこまでのコミットに見合った対価を下についた人間が得られていれば、
それはそれでいいかもしれないが...そんなケースは稀。(断っておくが対価
は金銭だけを指しているわけではない、充足感・達成感・数年で陳腐化
するような技術知識は対価に当たらない。)

「お客さまのため、お客様第一」を本音的に掲げるSI屋はエンジニアの
不平不満を抑え込むためにエンジニアの前でも「お客さまのため、
お客様第一」を念仏のように唱え、エンジニアを納得させようとする。
対顧客向けのトークをエンジニアに対しても展開している時点でその
SI屋の底の浅さを感じる。

「お客さまのため、お客様第一」という言葉には水戸黄門の印籠のような
効果があるんだろうか?(いや、ない。)

SI屋は解らないが、エンジニアはクライアントのために働いているわけ
ではない。

[補足]
SI屋の手掛けるシステムはクライアント企業の業務と深く結びついている
ので、クライアントの業務手順に大きな変革があれば、システムは
リプレースされる。リプレースされない場合には原形を留めないほどの
大改造となる。SI屋の手掛けるシステムはクライアントの業務の小さな
変化には対応できるが変革と呼ばれるほどの大きな変化に対応できる
ほど柔軟には作られていない。クライアントの業務の小さな変化への
対応は無論、システムの小規模な改造。クライアント企業の業務変革の
スパンは数年(10年以内の)間隔でやってくる。

2008年2月9日土曜日

SIerでは何故ギーク志向エンジニアが評価されない(育たない)のか

SIerの身分制度と収益構造が密接に結びついているから。
SIerの身分制度は言わずもがなで、経営陣>コンサルタント>SE
>>プログラマ。
まず、収益構造からみてみる。
1つのプロジェクトに投入できる人数はコンサルタント<SE<<プログラマ。
つまり、プログラマの担当する製造の日数を契約時の工数で最大化すれば、
会社は儲かる。製造の人月を契約時の工数で最大化するためには単価の安い
平凡なプログラマを投入することで製造日数を多く見積もるのが一番、
その副次効果としてテストの日数も多く見積もれる。
この方法だと、プロジェクト単体から得られる利益がその規模に比例するよう
にできるので、SIerにとっては都合が良い。
優秀なプログラマを育てると、少ない人数で製造でき、バグも少ないので、
製造に掛かる日数とテストに掛かる日数が激減し、プロジェクト単体から
得られる利益が減少する。
プロジェクト単体から得られる利益がその規模に比例する状態を維持するには
プログラマを育てないで使い捨てにするのが一番なのである。
製造の日数を最大化する現状の方法ではプログラマを育てないことで
プログラマに払う報酬を安く抑えプロジェクト単体の人数の最も多い身分の
人件費を最小化するのがコスト削減に繋がっている。

SIerの身分制度については組織構造と収益構造が深く結びついている。
SIerでの人数分布は経営陣<<コンサルタント<SE<<プログラマ。
SIerの年間の売上が決まっている(プロジェクト単体では受注時に決まる)
中で、人数が少ない身分により多くの報酬を払うようにすれば、SIerは
儲かる。一番人数の少ない経営陣にとっては自分たちへの報酬が最大化し、
都合が良い。
SIerのピラミッド構造は今後も変わることはない。、
SIerの組織の中ではプログラマを評価しない仕組みが既に出来上がって
いるので、優秀なプログラマが行う行為が設計かどうかを議論する
ことに全く意味はない。

毎年毎年、大手・中堅のSIerには安い賃金で働かせることのできる
新入社員がわんさか入ってくるので、入社後数年の若手社員は
プログラマとして扱ってそれからSEにジョブチェンジさせている。
足りない分は外注・派遣で補い、単価を抑える。外注のほうも大手・中堅
のSIerに単価の安いエンジニアを薄利多売で投入して利益をあげる(外注の
場合は単価の高いエンジニア(SE)数名と単価の安いエンジニア(PG)の
セット売り、比率はSE<<PG)。外注・派遣業者のほとんどは自分たちの
利益を圧迫する人材育成にコストを掛けることはない。
専門学校や大学からの安くつかえるプログラマの供給は途絶えないので、
このSI業界の体制が変わることは当分ない。

そこにギーク志向エンジニアを育てる土壌はない。

[蛇足]
原価 + 利益 = 価格、クライアント向けと内向けでの原価が違うこともある。
クライアントの出せる金額は上限が決まっていることが多い。原価を低く
抑えることで利益の部分を大きくする。

2008年2月3日日曜日

何故SunはRubyを推すのか?

その理由の一端はRubyの型の扱いにあるように思う。
Rubyは全ての型をオブジェクトとして扱い、それらの型はRubyの
クラスライブラリとして外部に公開されている。
Rubyは変数への代入時にその型が決定され、変数は代入される度に
代入されるオブジェクトにより型が変化する。
Rubyは扱うオブジェクトの強い型付けが行われていながら、変数への代入時に
動的片付けを行う。Rubyは強い型付けと動的型付けの両方を採用している。

ちなみのPHP4は型が完全に実行環境の中に隠蔽されている、弱い
型付けの言語。

型の他にもJavaの将来の言語仕様にも取り込みやすい素地が揃っていて、
Javaにコミットしてきた企業にもその類似点から薦め易いLLだから
SunはRubyに熱心なのではないだろうか?

SI屋はRubyを勘違い?

SIを商売にする人たちはとかくRubyとJava(C#?)について自分たちの
閉じた世界での見解をあたかも全てであるかのように発信する。

RubyとJava(WEB限定)でできることに差がないならJavaを選択する
よね、というのがその最たるもの。そこに「自分たちの業界では」
という注釈が付くことは稀。

Javaは時間を掛けてかっちり組むのには向くけど、短期間(数日)で
アイデアを形にしてリリース・継続的変更のサイクルを数時間~
数日単位で行っていくのには向かない。Java自体がそもそもコード
量を減らして開発をスピーディに進めることを主眼にした言語では
ないし、EOD(Ease Of Development)、EODとJavaで騒いだところで
対LLではその生産性には埋まらない溝がある。
Javaの親であるSunが何故Rubyに投資しているのか、考えたほうが
いい。

変化が緩やかな業界では保守性等を考慮してJavaでシステムを組む
ことに意味があるが、日々急速に変化する業界では今日リリースした
サービスが近日中には陳腐化するので、保守性等を過大評価して生産
性の見劣りする言語で組むことに意味はない。

サービス(顧客にどんなサービスを提供できるか)に軸足をおいた場合、
Javaで開発することに意味はない。そのサービスで何ができるかが
問題であって、そのサービスが何で作られているかには何の意味も
ない。サービスの迅速な提供が重要になるので、サービスを短期間で
開発できる生産性の高いプログラミング言語が必須となる、
サービスの開発に時間をなるべく掛けないことが求められる。

SI屋の業界では状況が異なる。SI屋はクライアントに提供する
ソフトウェアで何ができるか(そのソフトウェアが顧客にどんなサービス
を提供できるか)ではなく、そのソフトウェアの構築に掛かった時間で
対価を受け取る。SI屋は構築したソフトウェアをクライアントが利用
しなくても別に損はしない。何故なら、仕様についてクライアントと
合意さえできていて、そのソフトウェアに仕様以外の深刻な問題が
なければ、クライアントとの契約を満たしているので、SI屋の構築
したソフトウェアが実用にたえなくても、クライアントは契約に応じた
対価をSI屋に支払わなくてはならないからである。何故支払わなくては
ならないかは自明、顧客と受注時にそのように契約を交わしているだけ。

ちなみにSI屋は変化が緩やかな業界をターゲットに商売をしているケース
が大半。短期間(数日)でアイデアを形にしてリリース・継続的変更の
サイクルを数時間~数日単位で行っていくことが要求される業界では
上記のようなSI屋のビジネスモデルは成立しない、だから、そのような
業界をSI屋は避けてとおる。

そして、SI屋は自分たちの構築するソフトウェアを高級そうに見せること
ができ、その構築により多くの時間を掛けることのできるプログラミング
言語を選択する。何故なら、短時間で構築できては商売にならないから。

そこでJavaの登場、LLとの比較では実行速度や保守性等を引き合いに
出して、クライアントを説得する。生産性よりも保守性・実行速度が
etc大事ですよとクライアントに...。

言語自体の実行速度ならJavaはRubyに勝てるが、Rubyでは実行速度が
要求される部分はCorC++で組まれて拡張モジュールとして言語に
アドインされるので、トータルとしてみた場合は言語自体の実行速度に
あまり意味はない。

(特定の)クライアントを相手にするせよ、(不特定の)カスタマーを相手に
するにせよ、サービス(顧客にどんなサービスを提供できるか)が大事で
そのサービスを支える技術には意味があるが、そのサービスを提供する
ソフトウェアの構築にどの技術を使うか、その優劣について議論すること
に意味はない。更にいえば、その時々で変化する技術のトレンドについて
本質ではなく、重箱の隅を議論することには何の意味もない。

<蛇足>
Java製フレームワークを作ってRails対抗を打ち出している人種は何故
そのコードを読む人間が作者界隈にしかいないのかも考えたほうがいい。
そのフレームワークは作者周辺にしかわからない、他の人間は容易には
解読できないようでは...読みやすい、理解し易いコードというのも生産性
の一端。作者界隈にしか解読できないフレームワークは商用プロダクト
と大差ない、OSSはお墨付きではない。タダで使って利用者が社内で付随
コストを負担するか、商用サポートを購入して付随コストを外部に支払う
か、ただ、それだけの違い。だから、学習コストだけで済む枯れた
フレームワークから利用者は中々新しいものに移行しない。

<蛇足>
エンジニアは自分がコミットした技術を他人に押し売りしたがる。
その最たるものが「狛犬もどき」、関東方面では何処にでも出没
して、自分たちのプロダクトはブレイクスルーだと喧伝する、
LL使いからは何処がブレークスルーだと白い目で見られている
模様、かのRuby設計者は「Javaの世界ではブレイクスルーなんだろうね」
のフィーリングで呆れかえっているらしい。
「狛犬もどき」は技術をこねくりまわして喜んでいる集団、それも
技術の本質ではなく重箱の隅を。
「狛犬もどき」が世界に通用しないのは技術の重箱の隅をこねくりまわ
しているから。Rubyが世界に通用した一端は本質的な技術に取り組んだ
から。

2008年1月4日金曜日

日本のSIerにギークの居場所はあるのか?

全くといってよいほど、ない。(真の)ギークを目指すなら、
SIerに居続けるのは時間の無駄、スーツにいいように
使われて人生を浪費し、自分の精神をすり減らすだけ。

SIerに居続けるならスーツに転向するしか生きる道はない。
顧客の業務を理解し(理解するためにはまず覚え、頭の中で
咀嚼しなくてはならない)、顧客と折衝し、プロジェクトを
まわし、金勘定をする方法を覚えるしかない、ギークの
ロジックを捨てスーツのロジックを身に纏うしかない
のである。
一部にSIerの中で自分の立ち位置を確保するギークがいるが、
その人は例外中の例外に当て嵌まった人物であり、稀少な
存在、それを目指すのはやめたほうが良い。同じ会社では
尚更近い世代に同じ立ち位置のギークな人材は僅かしか
必要とされない。この狭き門に挑むのは茨の道を往くことで
あり、最後に薔薇色の未来が待つ可能性は限りなく低く、
そこに到達できる人間も極僅か。

OSSというSIerにとっては無料(タダ)で使える有難いソフトウェア
群が現れ、その傾向は益々強くなっている。

一応、スーツに転向したからといって薔薇色の未来が待ち受けて
いるわけではないことも付け加えておく。他のスーツにいいよう
に使われる局面は回避しやすいかもしれない。

スーツを指向しない、あるいはスーツが自分に向かない
のなら、SIerに勤めるのを辞めて、業務システム開発
以外の道に進むのが最善の選択肢である。

少なくとも、ギーク指向の本人にとってはどうでもいい
システムを作って人生を浪費する苦痛からは開放される。

システムを実装する技量があることと、業務システム開発
に魅力を感じないことは別次元の問題。

SIerでの業務システム開発に魅力を感じる(真or真指向の)ギーク
はいない。

ギークとスーツの間に横たわる深い溝(2)

ギークかつスーツであろうとする、とち狂ったスーツも
いるようだが、そんな存在は100%ありえない。
まぁ、精々、スーツ兼"なんちゃって"ギーク"が関の山。

ギークかつスーツの両方を満たすことができると考えている
時点で、そもそもギーク・スーツの根本的な違いを把握
できず、枝葉末節(表面)のみを見て、その違いを自分の
ロジックで捉えようとしている、お馬鹿なスーツという
ことになる。実際、その御仁の文章ではギーク・スーツ
の根本的な違いについては一切触れられていない。

ギークのロジックとスーツのロジックは完全に別物。
ロジック≒行動原理・論理、ギークとスーツは
この根本(根底)、魂(?)の出発点が異なる。
真の意味では"ギーク"と"スーツ"は対極に位置する
存在なのである。

人間をおおまかに分類すると、(真の)ギーク、(真の)スーツ、
なんちゃって"ギーク"、なんちゃって"スーツ"、その他
ということになる。
(真の)ギーク兼なんちゃって"スーツ"、
(真の)スーツ兼なんちゃって"ギーク"、
なんちゃって"ギーク"兼なんちゃって"スーツ"
は存在しうるが、(真の)ギーク兼(真の)スーツという
存在はありえない。
人間はその行動原理によって"スーツ"、"ギーク"の
どちらかに傾いている。"スーツ"、"ギーク"の中庸
に位置する人間はいない。

2008年1月1日火曜日

A Happy New Year 2008!

  謹賀新年、あけましておめでとうございます。