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

WindowsPCのキーボードにあわせてFedora・Ubuntu等の

Linuxディストリビューションのキー配列が設定されているので

これらをVMWare Fusion上で動かしているとMacのキーボード

とのキー配列の違いで困ることがある。

このためだけにWindowsPC配列のキーボードを買うのもなんだし

どうしようか...とりあえずもう少し調べてみることにする。

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

ここ。会社から評価されるためにオープンソースをやろうと

書いているようにみえる、会社からの評価を目的にするのでは

志が低いし...長続きしない。朝から終電まで(場合に

よっては土日も)プログラムを書いている人間に、リフレッシュ

するための僅かな余暇を削ることになる、効果があるかわからない

行為を推奨するのはどうかと思う。

(三度の飯よりプログラミングが好きという人間はトライしてみても

いいとは思うが...)

オープンソースのプロジェクトを開始するにしても２番煎じ

(猿真似)では評価されない、新規性がないと駄目等、開始するに

あたって注意すべき事柄は多い。

会社から評価されるためにオープンソースをやろうと書くのなら、

作るプロダクトに関してのアドバイス等、自身の経験を踏まえて

の実践的な内容にしないと、リンクした文章のように中身のない

空っぽな文章になる。

SIで優秀なPGが評価されないのはSI業界の構造的な問題(顧客から

の受注時に採用されている人月による見積もり等)が関係している、

それは一朝一夕に解決する問題ではない。

「オープンソースプロダクトの開発が(SIで優秀なPGが評価されない)

現状を打破する銀の弾丸になる」というような主張には何の根拠もない。

「オープンソースプロダクトの開発が上司に認められて

会社からの評価が上がったSIerの社員がいた」というだけでは

根拠にはならないのである。

会社からの評価UPを望むのなら、「オープンソースプロダクトの開発で

会社から評価を勝ち取る」などという不確実で非効率な手段よりも、

確実で効率の良い手段を探したほうが良い。

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をコストセンタからプロフィットセンタに

位置づけし直すことはありえない。

Perl6は何処にいった？

Perl6の登場がアナウンスされてから５年以上になるが、未だ実用に

足る実装が出ていない。

数年前、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化されていたので、修正しました。

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

　ここ。あいかわらず「KY」な連中...。個人が好き勝手に

書いていることに逐一反応する。いい加減、きもい。

数年前から何の成長もみられない。

個人が自分の思いで書いているブログに100%(?)の論証を求めること

自体、間違っていることに全く気づいていない。

自分達は自分たちのプロダクトの優位性について100%(?)の論証が

できていると思っているに違いない、できていないんだが...。

この連中、反論すればするほど、相手の反論の粗を探してそこを攻撃

してくるから反論するのは時間の無駄。

この本文の著者は本当に書きたいことの半分も書けていないと思う、

いわば書きかけの文章。その文章に一々食いつく。

この著者が問題にしているのは「アーキテクト」としての生産性であり、

「プログラマ(製造)」の生産性ではないだろう。

それを読み違えて、この著者の「アーキテクト」としての生産性に対して

狛犬もどきの連中は「プログラマ(製造)」の生産性で反論していて全く

かみ合っていないように感じる。

「アーキテクトとしての視点で見れば、狛犬もどきの製品はこじんまり

と纏まりすぎていて工夫の余地がない」というようなことがこの著者が。

書きたかったことだと思う。

「狛犬もどきの製品はそのプロダクト群の中で完結していて発展性が

ない、また、かっちりと作られすぎていてカスタマイズの余地もない」

とこの著者は感じているのではないだろうか？

狛犬もどきの製品はそのまま使用するのには向いているが、カスタマイズ

の余地はない(あるいはカスタマイズするにはソースをいじるしかない)、

狛犬もどきの製品はカスタマイズを考慮されていない、

と感じている人間は案外多いような気がする。

#選ぶことが大事じゃなくて作ることが大事なのでは。

「KY」なひで〜コメント、作るコストは誰が負担するんだ。

自分が作るコストを負担する余力のある(あるいは帰社時間に融通のきく)

会社にいるからいえるんだろうけど、えぐいな。

クライアントがそんなコスト、負担しないのは周知の事実。

自分のスタンスを相手に押し付けるのはどうかと思うが、見事に押し付け

てるな。

追記：

　　アーキテクト自身が生産性を考慮して、プロジェクトに最適化された
アーキテクチャとそのアーキテクチャに基づいた基盤を用意できれば、

プロジェクトの生産性も向上する、
個々の汎用プロダクト(部品)がプロジェクトの生産性を大きく左右する
わけではないと著者はいいたかっただけ。そもそも汎用プロダクト(部品)で
事足りるなら個々の案件にアーキテクトを配置する必要はない罠。

Kubuntu 8.04 KDE 4 RemixとKDE4

インスール時に使用言語を日本語に設定しているにも関わらずKDEが日本語化されない。

language-pack-ja.deb language-pack-kde-ja.deb

(Ubuntu 8.04 日本語ローカライズド Desktop CD のリポジトリから取得) 

をインストールするとKDEの設定画面で日本語が設定可能になる。