« February 2007 | Main | May 2007 »

March 19, 2007

パッケージ開発

パッケージ開発とはパッケージソフトを開発することではなく、パッケージソフトを担いで開発することを指す。簡単に言えば、顧客が要望するシステムに必要な機能を開発する(プログラムを作る)代わりに、市販のパッケージソフトが持つ機能を利用してシステムを作り上げることになる。しかし「パッケージソフトを担ぐ」とは、そんな生易しいものではない。

たとえば、顧客にC言語で100KLのスクラッチ開発に相当するシステムを要望されたが、求められている機能の90%は市販のパッケージソフトが持っているものであり、それに10KL程度のコードを追加すれば、顧客が求めているシステムが出来上がるとする。その場合、顧客が想定する開発費用はパッケージソフト代と10KLの開発費で済むことになる。仮にC言語による1ラインあたりの開発費を2000円として計算すると2億円になるが、パッケージソフトを使用した場合は、パッケージソフト代+2000万円ということになる。ではパッケージソフト代はいくらになるのか?・・・しかし誰がどう考えたって、パッケージソフトに1億8000万円かかるとは思わないだろう。そして、顧客の金勘定にはパッケージソフトの代金は入っていても、システム全体の顧客要求仕様をまとめ上げる費用や、追加コードを開発するためにパッケージソフトが最低限どのような仕組みで動いているのかを調査する費用や、パッケージソフトの機能がホントに顧客の要求通りに動作するかどうかを検証する費用などは、ほとんど含まれていない。

世間一般の人がすぐに思い浮かべるパッケージソフトといえば、Windowsのようなオペレーティングシステムとか、Officeのような統合ソフトウェアだろう。これらであればせいぜい高くても10万円程度で購入出来る。当たり前の話だが、それらのソフトウェアを10万円そこそこで開発出来るわけではなく、価格設定は単価×予測販売数+αということになる。したがって、その計算方法は上記のパッケージソフト代にもそのまま当てはまる。WEBを検索してみれば分かるが、エンタープライズ系ソリューションパッケージソフトの値段を晒しているページなんてものはどこにもない。値段はすべて応談である。また、ソフトウェア会社がそのパッケージソフトを使って新たなソリューションを開発し販売する場合は、パッケージソフト会社との間にいろいろと複雑な契約が必要になる。

つまりパッケージソフトと言えども、しょせんは人間が汗水垂らして作ったものであり、多額の費用がかかっているということだ。だからパッケージソフトを開発する会社は、それを担いでソリューションを開発し販売するというソフトウェア会社から、そのパッケージソフトの開発にかかった費用を出来るだけ回収しようとするだろう。契約にもよるが、ソフトウェア会社のソリューションに要する機能が、仮にそのパッケージソフトの機能全体の半分であったとしても、パッケージソフトの開発会社はソフトウェア会社に対して全機能分の価格を要求することになる。「パッケージソフトを担ぐ」とはそういうことなのだ。

顧客の側にしても「パッケージソフトを使って、スクラッチ&ビルドよりも安価にシステム化します」と聞いた途端、妙なパッケージソフトを買わされるんじゃないかと警戒する。高額なパッケージソフトであればなおさらだ。普通の顧客なら、そのパッケージソフトが持つ機能の何%の機能を使用するのか聞いてくるだろう。そして、パッケージソフト会社から個別にパッケージソフトの見積りを取った上で、ソフトウェア会社のソリューションがそのパッケージソフトの機能を100%使うのでない限り、そのパッケージソフトの代金を丸々払おうとはしないだろう。そうなると使われない機能の代金は、すべてソフトウェア会社の持ち出しになる。最悪の場合、ソフトウェア会社は、パッケージソフトの開発にかかった費用と、その後の維持管理費用を全部負わされることになりかねない。当然、その過程で多くの狡猾な駆け引きも展開される。

このように考えると、ソフトウェア会社にとってのパッケージ開発なんてものは儲かるような気がしないし、品質や性能が悪いパッケージソフトを担いでしまったら大変なことになる。社員1000人程度の会社なら、いとも簡単に吹き飛ぶだろう。

| | Comments (0) | TrackBack (0)

March 18, 2007

結局オブジェクト指向って何だったのか?

これはいまだによく分からない。もうかれこれ20年ほど開発に携わっていて、当初から注目すべき技術項目だとは思っているが、業務では一度もオブジェクト指向の言語でプログラムを作ったことが無いし、作りたいとも思わない。当然ながら、作ったことも作りたいとも思わないようなプログラミング言語で開発しろと言われても、管理不能だ。しかし、今後もずっと修得不可能かというと、決してそうは思わない。

とにかく、オブジェクト指向プログラミング言語の関連図書を斜め読みしていると、当たり前のことがいっぱい書いてある。オブジェクト指向以前と以後で何が違うのかと言えば、ほとんどは機能の部品化とその運用がスムーズに出来るかどうかといった点に集約されるだろう。そして、こんなものを作ってしまったためにソフトウェア業界は自滅の道を歩むことになってしまった(笑)。これはまさに原爆と同じである。しかもそれを作って、無料で配っている会社まである。

顧客サイドで考えてみれば・・・たとえば、C言語で100KLのプログラムをスクラッチ開発する場合、Javaで作れば20KLになるなんて話を前後の脈絡無しに聞いてしまったら、誰だって開発費用は1/5で済むと思うだろう。これをC言語で100KL作るのと同じ金額で見積り提示したって、相手にされないことは目に見えている。まして頭の硬いおエライさん方なら、ピュアJavaで、スクラッチで作って20KLなら、実質作るのはその半分も無いだろう?くらいのことを言いかねない。かくして、100KLのプログラムを今までの1/10の工数で開発する羽目になり、デスマーチプロジェクトが開始されるわけだ。

こんな開発をウォーターフォールで仕様検討からやっていたら、納期を過ぎても要求仕様すらフィックスしないだろう。つまり、コーディングするプログラムの量と、全体の開発工数が比例すると考えているような顧客なら、上記のようなことを真顔で言ってくる。そして、開発が途中でヤバくなってくると、頼んだ会社が悪かったと思うのだろう。

さすがに2007年の現時点に至っても、上記のようなことを言っている顧客は少ないのだろうが、それでも10年前に比べたら格段に高い生産性を要求されていることだけは間違いない。大手の製造メーカはこのような事態に対して、ソフトウェア開発だけで採算をとろうなんてことは考えなくなった。おそらく、ハードウェアや運用にかかる費用の中にソフトウェアの開発費を潜り込ませて回収しようとするのであろう。むかしあった1円入札はその極端な例だ。もう、ソフトウェア開発だけやって儲けようなんて考えている会社はほとんど無いような気がする。

まさに覆水盆に帰らず・・・こうなってしまった以上どうしようもないが、それでも受託開発だけで利益率10%を目標に掲げる会社もある。それを遂行するための秘策とはいったい何なのか。私には想像も出来ない(笑)。

| | Comments (0) | TrackBack (0)

March 17, 2007

出来ない理由を考えてもしょうがない!

これは技術者に対するかなり強力な殺し文句。こんな絶対服従を強要するような言葉が飛び出したらヤバイと思った方が良い。当然、こんなことを言われるとリスク分析をする気がなくなる。「やりゃ良いんでしょ?」という気分になるだけ。つまり「俺が全責任を負うからやれ!」というふうに解釈したくなる。でも実際に言った本人にそういう意識は無いことが多い(笑)。

もうイマドキの開発はリスクが大きいかどうかは問題では無い。解決不能なリスクは顧客と調整するしかないのだ。あとは個々のリスクに対する対処が生産性をどの程度スポイルするかで、快適な仕事になるか、憂鬱な仕事になるかが決まる。

そして妙な技術やスキルを持っている奴は、リスクの大きい作業に回されるのが常だ。なぜかというと、そういう奴を楽な作業に回すと遊んでばかりいて、持っている能力を仕事に対して発揮しないことが目に見えているからだ。逆に言えば、そうだからこそそういう妙な技術やスキルを持つに至ったのだと組織は考えている。

プログラマにとって技術は生きる糧だが、組織にとってはそうではない。業務遂行に不要な技術は邪魔になるだけ・・・気にしてもしょうがないような、解決の無い、余計なリスク項目が増えるだけ。そして、後で何か重篤な問題が発生すると、当初は聞く耳持たなかったにもかかわらず「どうしてそれを最初に言わなかった!」と責めてくる。ひょっとしたら、最近起きている食品業界の不祥事?は、こういった組織の傲慢が原因なのかもしれない。

| | Comments (0) | TrackBack (0)

最近のCPUについて

私が今居る職場は客先で、ここではみんな割りと贅沢なPC環境を使っている。ほとんどの人は1台のPCに2台のモニタをつないでいるようだ。私はここの職場では他所者扱いなので、そんな贅沢なPCは使わせてもらえない。というか、昔からこの業界ではPCの使い方を知らない人ほど贅沢な環境を欲しがる傾向がある。私に貸与されているPCはペン4-2GHzの古いデスクトップPCで、液晶モニタは15インチくらいのXGAだ。他の人たちに比べると2世代くらい前のPCである。ただ、プログラムをガンガン作っている開発担当に「必要ならいくらでも性能の良いPCを与える」なんて言おうものなら、お金がいくらあっても足りなくなるので、誰もそんなことは言わない。

そう思っているところへ、数日前にCore 2 Duo搭載の新しいPCがドサッとたくさん納品されてきた。新品のモニタを2台注文した人も居るらしい。そういうPCを何に使うのかといえば、メールの読み書きとOfficeドキュメントの作成がメインである。大抵の人は片方のモニタにメーラ、他方のモニタにワードやエクセルのウインドウを大きく開いている。そんなことにCore 2 Duoやマルチモニタが必要なのかどうかはよく分からない。

まあ、そんなクダラナイ話は置いといて・・・本題に入る(笑)。

冗長構成の話の中で少し書いたが、すでに最近のPCアーキテクチャは破綻している。CPUはマルチコアでもハイパースレッディングでも何でも良いが、とにかくCPUの演算がいくら高速になっても、メモリやバスは旧態依然のままだ。この問題は何も今に始まったわけじゃなくて、SUNがSPARC搭載のワークステーションを出すたびに、性能の倍々ゲームをやっていた頃からある。それからもう10年以上も経っているのに、何ら画期的な方式が登場していない。

少なくとも、OSくらいはCPU上のキャッシュメモリにすべて読み込んで専用コアが実行する、その他のアプリケーションもメインに使用するものは、それぞれ専用コアとペアのキャシュメモリ上ですべて処理する・・・というくらいは既にやっていてもおかしくないのではないか。

要するに・・・そろそろコンピュータのアーキテクチャを根本的に見直した方が良いと思う。そして、既存のソフトウェアはすべて使用不可にする。そうすれば、またスクラッチ開発のオンパレードになって、ソフトウェア業界が潤うのだ。それにJavaみたいな発想でプログラムを作ろうとしてもロクなものは出来ないということを証明するような、画期的な方式が出てくればなお良い。

いずれにしてもマシンの特性を無視した開発が多過ぎる。WEBサーバだろうが通信サーバだろうが何でも同じ発想で作るから、どっかの通信会社みたいに大問題を引き起こす(笑)。結局、客がバカなら開発する方もバカにならざるを得ない・・・極端なことを言えば、通信ソフトにWEBページ制作と同レベルの生産性を求めようとするから問題になるのだが、最近ではもうそんなことは分かりきっていて、確信犯的にやっているケースがほとんどである。とくに通信会社は投資の回収において、長い目で見ると結局どっちが安いのか(ストーリー)で判断するのだ。

こういう状況では、きっと開発なんて仕事は面白くも何ともない。明らかに技術的なことよりもビジネス論理が優先している。毎日会社に行ってやることといったら、検討資料を書く、打ち合わせをする、議事録を書く、設計書を書く、プログラムを書く、プログラムを試験する・・・といったことを決められたスケジュールの中で他ごとを考える暇もなく機械的にやるだけ。給料は他の業界よりも多少高いかもしれないが、ベルトコンベアの横で流れてくる弁当箱にオカズを詰める作業とそれほど変わらない。自分のやっていることに何の疑問も抱くことはないし、そんな暇もない。時間が来たらすぐに退社させられる。何の夢もない業界になってしまった(笑)。

| | Comments (0) | TrackBack (0)

March 14, 2007

決めつけるな?

これまでインタネット上でメーリングリストに参加したり、こうやってSNSに登録したりして、多くのいろんな人と語り合ってきたが、なぜか決めつけるような言い方をすると嫌がる人が多い(これ自体も決めつけか・・・?)。誰かが自分の意に沿わない発言をすると「それはあくまで貴方の意見ですよね?」と聞き返しているのをよく見かけるが、それは当たり前じゃないだろうか?仮りに何かを読んで知り得た他人の知見であったとしても、それそのもの、あるいはそれに基づいて何かを言えば、それはその人自身の意見ないしは認識になる。何かを偉そうに語った後で「イヤ、これは実はこれこれの受け売りです」なんていうのは後出しジャンケンと一緒である。

また、如何にも一般的、普遍的な話であっても、それをその人が自分の考えであるかのように発言したのであれば、それは当然その人の意見であり、その人はその意見に準ずる考え方や認識を持っていると思ってよい。日本語は便利なもので「・・・のような気がする」とか「・・・かもしれない」という言い回しでオブラートに包むことが出来るが、その人は場の空気を考えて、軟らかい表現をしているだけで、考えていることが曖昧なわけでは無い。

なぜこんなことをくどくど言うかというと、コミュニケーションとは何らかの「決めつけ」から始まるからだ。「・・・かもしれない」とか「・・・のような気がする」と書かれていたら、それを読んだ人はその話の意図が何なのか理解出来なくても、「そうかもしれませんねえ」と言うことが出来る。逆に「AはBである」というように断定的な言い方をすると、それを読んだ人は「自分と同じ認識だ」と言う人とそうじゃない人にはっきり分かれるし、それに対して自分の認識を述べることが出来る。

別に何か決めつけるようなことを発言したからといって、一生そのような認識でいるとは限らないし、認識が変わったのであればそれを表明すれば良い。誰だって、今の時点でそう考えているだけなんだから。とにかく決めつけるように言い切ってくれないと、コメントのしようがないのだ(笑)。

| | Comments (0) | TrackBack (0)

March 12, 2007

社内SNSって?

最近はミクシィをはじめ、インタネット上のいろんなところでSNSが利用できるようになってきている。それならば、会社内でもSNSをやってみようじゃないか!という考えが出てきても、別に不思議では無い。自分が勤める会社でも2〜3ヵ月前から試行的にSNSが開設された。主な目的は開発技術/ノウハウなどの情報流通であり、社内で何か知りたいことや困っていることがあれば、お互いに助け合いましょう!という趣旨である。

結論を先に言うが、個人的にこういう形のSNSは上手く行かないと思っている。SNSとはコミュニケーション(遊び)の場であり、情報流通の場では無い。それにそもそも、数年前から本格的になった成果主義による評価と、社員同士の助け合いなんて、真向から矛盾するような気がする。隣席の社員と競争させておいて、でも「困っていたら助けてあげようね」なんて、口では何とでも言えるかもしれないが、ホントに心底困っている人のために何かしようと思えるものだろうか?・・・きっと困っている人のためというよりは、自分の成果のために情報提供するということになるのだろう。

上記は非常にネガティヴに思えるかもしれない。それは私がもともと職人的な職場に長く居たことによるものと思われる。職人の世界では自分の持っている技術を周囲に対して懇切丁寧に説明することはない。そう、技術とは習うものでは無く、盗むものと教えられている。これの意味は「お前は俺と全く同じようには出来ないはずだから、俺のやり方を見て自分なりにやってみろ」ということだと思っている。きっと非常に非合理的なやり方に見えるかもしれないが、職人とはそういう中で徐々に育っていく。

逆に最近の方法、とくにソフトウェア開発の世界では、技術的なことはすべて文書化されることになっている。これはある意味「職人的な」人を排除するかのような考え方だ。文書化出来ないようなものは(少なくとも組織にとって)管理すべき技術では無いということなのだろう。たとえば、ものすごくプログラムを作るのが得意で、生産性の高い、魔法使いのようなプログラマが居たとして、その人の技術レベルがホントに高いのであれば、そのノウハウを文書化して、周囲の人に横展開し、組織としてレベルアップすることが出来なければならない。そうなると、仮りにそれが出来なかった場合、その人が持っている技術や能力は全く評価されないことになる。組織のそういう方針が定着すると、社員は文書化出来ないような技術は誰も習得しなくなる。つまり技術や能力というのは管理するためにあるのであって、習得しなければならないという意識はどんどん無くなっていくであろう。

社内SNSに戻すと、上記のとおりノウハウというのは文書になっていなければならず、そうでなければSNS上で流通させることは出来ない。問題なのは組織の役に立つほどの技術なりノウハウなりを、忙しい業務中に書き込めるのか?という点だ。まるで一子相伝のような関係で仕事をしていても、なかなか伝わらないようなノウハウが、 SNSなどのツールを使えば上手く行くというのは、明らかにおかしい。組織としてはとりあえず目に見える対策をとらなければならないということでSNSをはじめたのであろう。それともうひとつは、メーリングリストなどと違って、SNS上ではノウハウの流通が行われているかどうかを観察することがかなり容易になるということなのだろう。

こういうような考え方は、技術やノウハウというものが職人にとって生きるための糧であるということを無視した、安易なやり方に思えてならないし、誰にでも実行可能なノウハウなんて気持ち悪くて仕方がない。きっと、そういうノウハウは誰も習得する気がしないし、すぐに忘れ去られる。誰だって文書化されているものを記憶したり習得したりしたいとは思わないだろう。

| | Comments (0) | TrackBack (0)

March 09, 2007

久しぶりのプログラム

今日はもうファイル転送処理のプログラムを作り終わってしまったので、ドキュメントを修正したり、試験項目を作成したりしていた。これはネムイ作業だ(笑)。ところが試験項目を作るために、処理条件のマトリックスを作っていたらバグを1件見つけてしまった・・・

会社でemacs-22.0.95.tar.gzをダウンロードしようとしているのだが、途中でエラーになってしまってなかなか出来ない。22.0.94までは月1回のペースだったのに、22.0.95は半月くらいで出てきた。22.0.94にバグが多かったからだろうか?機能的には何も変わらないと思うので、22.0.94でも何も問題ないのだが・・・逆に、自宅ではすでに22.0.95になっているがほとんど使わない。

会社のPCも出来れば、Windows+Linuxの環境にしたいのだが、Linuxをインストールしてもオンラインによるアップデートやパッケージの追加が出来ない。そういうことがLinuxの普及を阻害しているように思える。アップデート先をring serverにすれば良いのかもしれないが・・・会社のLinuxマシンというと、購入媒体からインストールした、ものすごく古いRHELしかなくて、あんまり面白くない。まあCygwinを入れればLinuxの勉強くらいにはなると思っている人も多い。また会社でLinuxを普及させるにはインストール方法や、標準的な設定方法などをイヤというほど資料化しなければならない。当然使い方も考えないといけない。使い方なんて、使う本人が考えれば良いと思われるかもしれないが、会社とはそういうところだ。そういうのはすべて言い出しっぺの負担になるので、誰もそんなことをみんなの前では言わない(笑)。これはむかし会社にMacを普及させようとしたときもそうだった。

いつも思うのだが、ターゲットシステムのOSくらい、日頃から使用して慣れ親しんでいないと、いざと言うときに困るような気がする。皮肉なもので、日頃からイヤというほど使っているWindows上の開発というのはあんまりやったことが無い。それに毎日使っているからといって理解できているわけでもないのだ。実際にWindowsのシステムを開発しろと言われても分からないことだらけだ。

やっぱり、使って楽しい、作って楽しいというのはEmacsだけか(笑)。

| | Comments (0) | TrackBack (0)

March 08, 2007

結論の出ない打ち合わせ?

誰でも結論の出ない打ち合わせはイヤなものだ。2時間くらい打ち合わせして、何も結論が出ないとみんなイライラするし、時間の無駄だと思うのだろう。なんでそうなるのかというと、結論を持ち寄って打ち合わせに臨まないからだ(笑)。

たとえば何か問題があって、それの対処を審議するとしよう。その打ち合わせには、当然打ち合わせメンバが検討した対処案が出てこなければならない。そして、打ち合わせのポイントは、その対処を導き出すのに前提とすべき事項、前提と対処案に矛盾が無いことの2点である。それを議論出来ないようなら最初から打ち合わせを行なう意味は無いし、無理矢理やっても話が発散するだけだ。

しかし・・・こんな当たり前のことで悩んでしまうマネージャっていったい何?って思ってしまう(笑)。

| | Comments (0) | TrackBack (0)

Bashでファイル転送処理─その2

昨日懸念していた、大量コマンドの処理は上手くいくようだ。たとえば以下のような処理である。実験ではdirコマンドを100回実行してみた、

ftp -n XXX.XXX.XXX.XXX << EOF
user username passwd
passive
dir
dir
dir
dir
dir
dir
dir
dir
dir
dir
......
bye
EOF

ftpを連続で何度も起動するとおかしくなる(コネクションを拒否される)というのは、どうやらxinetdのinstances値によるものらしい。まあ以下のように書いて実行すればすぐに分かることだ。

function ftptest () {
ftp -n XXX.XXX.XXX.XXX << EOF
user username passwd
passive
dir
bye
EOF
}
while true; do ftptest; done

他に今回いろいろ試してみて、たとえば以下のようなやりかたは上手くいかないことが分かった。これは意外に誰でもやりそうな気がする。

AWK="awk '{ print $2 }'"
ls -l | $AWK

これは以下のように書くのと結果が違ってくる。まあ、こういったことは-xオプションを付けて実行すれば何が問題なのか分かるはずだ。

ls -l | awk '{ print $2 }'

試行錯誤の結果、スクリプトは完成した。まあ、きっとしばらくすると忘れて同じ間違いを繰り返しそうな気がする(笑)。

| | Comments (0) | TrackBack (0)

March 07, 2007

Bashでファイル転送処理

このところ業務ではファイル転送スクリプトのことばかり考えている。ディレクトリ構造に収まっているファイルを一括で転送するには、通常のftpコマンドではちょっと役不足だ。しかし環境の制約があって、使いたい機能を好きなようにインストールすることは出来ない。仕方がないので、ftpでファイルリストを取ってきて、それをもとにディレクトリ構造を把握し、すべての階層からすべてのファイルをゲットするスクリプトを書いた。これはncftpならコマンド一発で出来てしまうものである。

最初は暢気にftpを何度でも起動して、順番にディレクトリを調べていけば出来るだろうと思っていたのだが、Bashスクリプトの中からftpをガンガン起動していくと、30個弱くらいで止まってしまう。サーバがコネクションを拒否してしまうのだ。netstatコマンドで見ると、使用したコネクションがTIME_WAITで残ってしまっている。きっとサーバがデータを転送し終わる前にクライアント側からbyeしてしまうからだと思われるが、 ftpをバッチモードで使用するのにデータをすべて受信してから終了するなんて出来るんだろうか・・・これは実際に監視系システムで使用する予定の処理なので、あんまりいい加減な方法では運用で問題が発生してしまう。

一応、それらしいキーワードで検索してみたが、ftpの自動処理でそこまで気にしている情報は無かった。

まあ、これは明日検証してみることにする。

| | Comments (0) | TrackBack (0)

March 06, 2007

SCP

SCPというコマンドがある。他にSFTPとかSSHとか・・・要するにOpenSSLを使ったセキュアシリーズだ。これを使ってファイルのリモートコピーを行おうとしているのだが、バッチ処理なので対話的にパスワード入力を求められると困る。そこで、事前認証を行なっておいてSCP実行時にはパスワードを聞いてこないように設定しようとしている。どころがこれがなかなかうまくいかない(笑)。

まあ、そもそもOpenSSLのことをほとんど何も知らないでやっているので、分からなくて当然だし、下手に上手くいっちゃうと後が怖い。運用中に何かエラーが出ても対処不能に陥る。こんなのの調査に1〜2日かけるんだったら、すごく面倒臭いけど、FTPを使ったディレクトリの再帰処理を書いていた方が面白いような気がするのだ。

ホントはncftpが使えれば、何も問題ない。

| | Comments (0) | TrackBack (0)

March 04, 2007

式の再評価

前にもちょっと書いたが、隣席の同僚はやけにPythonがお気に入りである。おそらく、現在開発に携わっているシステムにも一部Pythonが使われているので、習得すべきスクリプト言語だという意識なのだろう。

ただ、Pythonがスクリプト言語だというのなら、当然式の再評価が出来ないといけないと思うのだが、1日ちょっと調べた限りではそんなことはどこにも書かれていない。コンパイラ言語ばかりやっている人にとってはどうでも良いことかもしれないが、以下のようなことが出来ないのは非常に不便ではないだろうか?

$ file `which python`
/usr/bin/python: ELF 32-bit LSB executable, Intel 80386, version 1 (SYSV), 
dynamically linked (uses shared libs), for GNU/Linux 2.6.9, stripped

バッククォートで囲まれた部分は、シェルが二度評価しているので、上記のような結果が得られる。これを下記のように書くしかないスクリプト言語って、いったい何なの?っていう気がする。

$ file /usr/bin/python

もともとスクリプト言語というのは、書いたプログラムをインタプリタが読み込んで処理するので、プログラムは言わばインタプリタにとってのデータである。だからこそ、スクリプト言語は非常に柔軟な記述が可能になっているのだ。その柔軟さがないのなら、それを使用するメリットがなくなってしまう。 tryとかexceptなんていうタグが使えて、Javaみたいでカッコいい!などと暢気に喜んでいる場合ではないのだ(笑)。

| | Comments (0) | TrackBack (0)

感覚的なこと

人は良いこと、素晴らしいことだったら何でもやるかというと、そういうわけではない。良い学校を出て、良い会社に入って、出世して・・・というのは良いこと(王道?)なのかもしれないが、それをやりとげるのは非常に大変だし、たとえば、良い学校には入ったが、結果的に良い会社には入れなかったというと、それで大きく道筋が狂ってしまう。まあ、良い会社に入るまでは自力で何とかなるかもしれないが、その会社で出世出来るかどうかは分からない。逆に言えば、出世していく人間は「出来るかどうか分からないなんてことは考えない」傲慢なやつばかりだ(笑)。

技術的なことについても同様のことが言える。人は「これは技術的に素晴らしい」と絶賛されていることなら何でもやるかというとそういうわけではない。たとえば、私が大好きなEmacsなんて、いくら勧めても嫌な人は絶対に使おうとしない。こういうのは理屈じゃなくて、感覚が左右する問題だと思う。

組織においては「技術的に優れている人は、自分が持っている技術/ノウハウを組織に浸透させることが出来る人」という評価の仕方をする。これは組織なんだから当然の話だろう。だが、その前にそれを浸透させられる見込みがあるかどうかの判断がある。だから誰にでも自分の技術を組織の中でアピールするチャンスがあるわけでは無い。これも多分に感覚的な問題であるが、組織の中では「あんたなら出来そうな気がする」なんてことは言えないので、理にかなったような理屈が適当に作られる。

むかしのオジサンたちは部下に対して、是々非々、すなわち「問答無用!ダメなものはダメー!」というのが好きらしい。これも「こんなことで責任とらされるのはイヤだ」という意味であり、非常に感覚的なものだ(笑)。

| | Comments (0) | TrackBack (0)

March 03, 2007

Kerberos

ケルベロスというのは、冥王ハーデスの番犬で、3つの頭と蛇の毛を持つ化け物だ。MITのアテナプロジェクトが開発した認証システムの名前でもある。そんな名前がついているくらいだから、きっとものすごく強固なセキュリティを誇っているのだろうが、今関心があるのはそんなことではない。このケルベロスがあるせいで非常に迷惑しているのだ。用もないのに番犬が居るくらい邪魔なものは無い。そのマシン上には誰も使わないのにケルベロスがインストールされていて、ファイル転送をする場合はケルベロス対応のFTPクライアントが起動するようになっている。ところがそのマシンは外部からFTP要求を受け付けるとケルベロス対応でないvsftpdが起動するよう設定されている。

そういう環境でpythonを使ったファイル転送処理を書こうとしているのであるが、そんなもの上手くいくわけがないし、そういう場合はこうすれば良いなんてことを調べているヒマ人は地球上に1人も居ない。なので、私もそんなことを調査するのはやめて、/usr/bin/ftpとvsftpdのペアで処理するのか、あくまでケルベロスに固執するのかを確認中である。月曜日にどういう結論が出るか非常に楽しみだ(笑)。

| | Comments (0) | TrackBack (0)

March 02, 2007

冗長構成の考え方について

冗長構成とは簡単にいうと壊れたときでも予備が動く構成である。最近の言葉で言えばクラスタリング。ネット上に無数にあるWEBサーバはたいてい冗長構成になっていて、ノンストップで動き続ける。いまどき冗長構成になっていないサーバはあり得ない(もちろん個人サーバは別)。

昨年あたりから仮想マシン関連のソフトウェアがいろいろ出てきた。なので、あまり現実的ではないが、やろうと思えば1台のマシンで冗長構成をとることも可能になっている。しかし、仮想マシン技術の進歩はそんな単純なことをするためにあるのではない。一番大きな目的は、CPUの効率的活用だろう。最近の複雑なシステムは非常に多くのスレッドを同時並行で動かすために、マシンの性能を使いきれないことが多い。であれば、1個のCPU上で複数の仮想マシンを動かした方が効率的だ。そもそもハイパースレッディングというCPU技術は、性能の良いCPUにはアイドル時間が多いことが分かっているために出てきた。アイドル時間の原因はCPUとメモリの間のアクセスが非常に遅いことによる。CPUにはデータに1加算する命令が必ずあるが、これをレジスタに対して行なうのと、メモリに対して行なうのでは100倍ほど時間が違ってくる。つまり、メモリを参照し1加算してメモリを書き換えるという動作の間に、ものすごく多くのアイドル時間が発生してしまうのだ。その間に他のことが出来ると考えたのがハイパースレッディングの発想である。ただし、アイドルがいくらたくさんあるといっても、ハイパースレッドをたくさん増やすことは出来なくて、CPUとバスの接続を考えるとせいぜい2個までと思われる。なので、CPUにはまだまだアイドル時間がいっぱいあるわけだ。そうなると、もうアプリレベルでCPUを効率的に使用するなんてことを考えても埓があかないことに気がつく。そこで仮想マシン、つまり1個CPU上で複数のOSを動かすという発想が出てきたわけだ。

アプリケーション・スレッドなんていうのは、CPUから見たらホンの一瞬ずつしか動いていないように見えるのだろうが、OSのカーネルコードであればそうでもない。しかもひとつのCPU上で複数の仮想マシンを動かすのであれば、複数のOSが動くのだから、高性能CPUの空きクロックを使う良い方法になる・・・このような話は、アプリケーションソフトウェアの性能にボトルネックが一切無い、つまり複数のスレッドが相互の動作を一切邪魔しないよう巧妙緻密に練り上げられている場合の話であり、実際のアプリケーションソフトウェアにおいて、そんなことは絶対にあり得ないので、現場で動いているシステムの CPU空きクロックの多さは、間違い無くCPU設計者が想像する以上だろう。

別に私はVMware社の回し者でもなんでもない。ただ、顧客がハードウェアの性能をソフトウェアがちゃんと使いこなしているか気にし始めたときには、ストリームを1バイトずつ読み出すソフトウェアに作り変えるか、仮想化技術を活用するしか選択肢が無いように思えるのである。もちろん性能ボトルネックの原因の多くは使用する市販パッケージのコア部分にある。なので、そのパッケージを担いで開発してしまった以上、性能改善は基本的に無理である。仮りにそれを解決する能力が自分にあったとしても、そこは権利問題でガチガチになっていて手出しが出来ない領域なのだ。

これからのソフトウェアはそのあたりがますます巧妙になってきて、開発サイドが試験をしているうちは良いが、いざ現場に出すとボロボロの結果を招くことが多くなるだろう。つまり、ある条件を超えると動作が豹変するような性能特性を持ったソフトウェアが多くなっていくということである(顧客は金が無いし、そんなところは契約書にも設計書にも規定出来ないから?)。そんなものを扱っているのに、壊れたら代わりに動く予備マシンが無いとダメ(これって要するに思考停止以外の何物でもない)だなんて言っていると、痛い目に逢うような予感がしてならない。だって、予備系は現用系と同じ動きをするだけだから、何の解決にもならない(姑息な時間稼ぎにはなるか?)と思うんだけど。

とにかく、まずは「このシステムは無駄無くCPUを使っています」と胸張って言えるようにならないとダメで、次に考えるべきなのはサービスアプリよりもトラヒック制御を優先し、CPUネックが発生しているのであれば仮想マシンを動的に増やす、内部にIOネックが発生しているのであれば外部からの要求を規制する、といったような動きをさせる必要がある。しかもそういうことをシステムの実装検討の段階から考慮し、パッケージ選定しなければ上手くいかないだろう。

まあ、ハードウェアが冗長になっていなければ納得しないようなオジサンたちは、システム障害が発生すると運が悪かったとあきらめるしかないわけで、素直に顧客に誤りに言ってくれるし、われわれにもお咎めが無いので精神衛生的には良いのだが(笑)。

| | Comments (0) | TrackBack (0)

March 01, 2007

Emacsのコンパイル

一昨日、Emacs-23にかなり大きな更新があり、コンパイルしたらやはりエラーがあった。こういうことは以前からたまにあることなので、1日待っていればたいてい修正されるようになっている。また、コンパイルエラーが出るのに次の更新でも修正されないものは、自分の環境をチェックした方が良いかもしれない。

あれだけ大きな更新を1人でやるとは思えないので、コンパイル確認するわけにもいかないし、だれかがポカをやることは十分あり得る。全員がコミットして初めてコンパイルエラーに気がつくわけだ。

最近はEmacs関連のビルドは単にコマンドを並べただけのシェルスクリプトを作ってやっている。Emacs-22、Emacs-23の両方がビルドに失敗することはほとんどないので、たまにEmacs-23のビルドに失敗すると起動したときにEmacs-22が立ち上がってくる。Emacs- 21はほとんど使わないが、会社のLinuxマシンだとそれしか入っていないのでしかたなく使っている。ほとんど何のカスタマイズも出来ない。

今Emacs-23のビルドを行なっているが、コンパイルエラーの箇所は通過したので、また使えるようになるだろう。

| | Comments (0) | TrackBack (0)

« February 2007 | Main | May 2007 »