10年先(１)

10年先の予測として

WindowsがクライアントOSとして支配的なシェアを維持できているか。
この点については役所などでLinux採用ニュースを聞いたり、ウィルスの蔓延状況をみて、Windowsの将来について一抹の不安を感じる人は多いのではないかと思います。
実際、私もボランティアでプログラムを作成している営利団体でないLinuxが将来、Windowsに変わるのは必然かと思っていました。Microsoftは財務内容の良い会社でしょうが、一方は営利を目的とした企業ではないのです。例えば赤十字とGMとどちらが永らえるかといった問題とさして変わりません。
Linuxは赤十字ではないけれど、実名で自分の作成したプログラムを公表できるということで、プログラマーが自分の実力を示すための場として必要とされているものです。Linus Torvaldsは誰でも知っています。そういった必要性があり、営利を目的としない組織はつぶれません。不死の人間と寿命比べはできないということです。そう言った意味でWindowsの将来には暗澹たる不安を感じるのです。

こう考えて、LinuxでのGUI環境であるBorland Kylix3を開発環境として検討してみました。
結論から言うとこれは使えません。
Kylix3はプラットホームとしてRedHat7.2を標準としています。私はRedHat9.0を使いたいのです。RedHat9.0は実際良くできていて、このブログもRedHat9.0のMozillaから書いています。Kylix3を試用するためでもRedHat7.2を使おうとは思いません。7.2が出た当時は良くできているな、と思いましたが、9.0を知ってしまった後、7.2を使う気にはなれないということです。
実際のところ、昨年買ったPCに7.2をインストールしようとしましたが、XlAi5200を認識させることができず、XWindowを起動できなかったのです。もっと工夫すればインストールできるのでしょうが、ここ数年で発売されたPCでXの起動が問題になるようなら、10年先は絶望です。じゃ、9.0でKylixを使えるかというと、これがまた、種々の問題を抱えているのです。Borlandがサポートしないので問題は解決しません。結局、今Kylix3で作ったプログラムが10年先に使用できる可能性はほどんど無いと思います。
LinuxでGUIの開発ツールを求めること辞退無理なのかもしれません。しかし、GUI環境でなければ100個コントロールを並べたフォームを作成する気には到底なれないのです。
(100個は大げさかな、50個位にしておきます。)

Linuxはバーションごとにみると良くできていると思いますし、サーバーとして特定のソフトを走らせて安定に稼働させるといったことでは最高です。しかし、クライアントとなると全く別のものを求められます。頻繁なバージョンアップはボランティアでプログラムを作成している人のことを考えると必要だし、そうしないと開発の意味はないでしょう。しかし、Kylixの場合がそうであるように、頻繁なバージョンアップはメーカーのサポートを拒絶しているようなものです。メーカーからすると大した大きさでもなく、種々のディストリビューションの乱立するLinux市場にさほど魅力を感じないのでしょう。
今回、Linux上でのプログラム開発ということを検討してみましたが、GUIの開発ツールがないこと、頻繁なバージョンアップで開発したプログラムの互換性が期待できない、ということで、Linux上でのプログラム作成はあきらめました。Linuxでクライアント用の業務用のソフトを数年にかけて開発するということは実際、無理な相談です。
10年先、Windowsが今のような支配的なシェアを維持できているかどうかはわかりません。しかし0％になっているということはないでしょうし、代替OSとしてLinuxが開発プラットフォームとして無理ということになると、選択枝としてWindows以外にはありえないということになってしまいます。

最近のニュースでIBMが昨年、業務用に使用しているPCのOSをLinuxに全面的に切替えると表明していたにもかかわらず、あまり進んでいないというものがありました。IBMにしてLinuxの切替えが進まないのなら、一般ユーザーで切替えが進むわけがありません。やはりWindowsしか選択枝はないのか。

じゃ、どうするか。
来年、Windowsはバージョンアップします。64ビットOS Longhornです。WindowsはWindows2000で32ビット化が終了して、その次の次のバージョンでは64ビット化します。LonghornではWin16APIはサポートされません。Win32APIはサポートされます。16ビットOSから64OSまでの経緯を考えてみると、
概略こんな具合ではなかったかと思います。

1985年頃 8ビットから16ビット(CP/M から MS-DOS)
1995年 16ビットから32ビット化へ(MS-DOSからWindows95)
2006年 32ビットから64ビット化(WindowsXPからLonghorn)

約10年で移行が行われています。当然、次は128ビット化するわけですが、それを2015年頃と予想します。

今後どうするか(２)

そういことで、10年先のことを考えて今からある程度、準備しておかなければならないかと思っています。実際、今回にしてもLinuxの試用から数えると完成まで5年位はかかっています。5年後新しく作り始めなれればならないとしたら、新しい言語に慣れておかなければなりません。
(実際、勤務時間にこんなことができるのなら、余裕があるのですが、そこは中小企業で余暇の時間をさいてやらなければならないところがつらい。)

このことについて以下、以下書いてみたいと思います。

今後どうするか

長々と書いてきましたが、「ブログにするようなことかよ！」と言われても仕方のない内容でした。
なんでブログに投稿させてもらったかと言うと、これからの内容を書きたいがためでした。

一度、製作した販売管理プログラムはできれば100年使用したい。外注で作成したプログラムに限らず、プログラムそのものは機械部品のように償却しません。できれば末永く使用したいのが本音です。
しかし、実際問題、これまで２回更新した経緯を考えてみてもどんなに長くても10年が限度と考えなければなりません。これを何とか20年にしたいというのが希望なんです。
プログラムを更新しなければならない動機はいくつかあります。

１．使用する側の状況が変わり、プログラムが実情に合わなくなってしまう。
２．主としてプリンターなどのハードを更新する際に対応するドライバーが無くなってしまう。あるいは使用できてもエラーメッセージを頻繁に吐くようになってしまい、使用に耐えない。

この二つだと思います。「１」は自作した場合、状況に応じてプログラムを修正していくので、動機にはなりにくいですが、問題は「２」です。
Windows95 から今回更新しなければならなかったのも、元はと言えば、プリンターを更新したのが原因でした。プリンタードライバが多分、原因で、「一般保護エラー」が頻繁でるようになってしまいました。さらに、Windows95は現在販売されている、PCにはクロックが速すぎてインストールできません。そのため、OSを更新しなければならず、Bitrieveが更新したOSに対応していない。結局、作り直ししかないという状況になったのです。

製作後の印象

Accessの悪いところばかり書きましたが、やはりAccessで製作したのは間違っていなかったと最近思います。
１．何と言っても情報量が豊富。
困った時にインターネットで調べますが、ほとんどの問題は解決します。もし、日本語で検索して参考になるものがなければ、英語で検索すれば問題解決の幅はもっと広がります。
２．一人で開発するのならAccessで問題ない。
よく、「Accessでのプログラム開発はよした方が良い。」といった内容のものを見ますが、プロのベンダーが言っていることで、「チームを組んで行うプログラム開発には適していない。」とか、「バージョンアップが難しい。」とか言ったことで、自分で作って、自分で使うのにはあまり関係ないことです。逆に言えば、Accessは中小企業が自分でプログラムを開発するためにピッタリのツールと言えるのではないかと思います。
(しかし、本当のことを言うとバージョンアップの問題は頭が痛いです。この件は後述します。)
３．「レポート」が最高
今回、専用伝票、A４、B４といった用紙を使用して伝票印刷、帳票作成を行いましたが、CristalReportはVisualBasic4に標準でついていたもので試しただけでしすが、CristalReportより、Accessのレポート機能の方が使い易いと思いました。
４．カレントレコードの複数行表示ができる。
最近調べたのですが、VisualBasicとかDelphiではカレントレコード１明細を２行とか３行とかに表示することができないのではないかと思います。(調べた範囲では)
dbMagicではこれができていたので、Accessでできても特に不思議にも思わなかったのですが、Delphiで同じことをしようとするとできないようでした。実際、Delphiのデータベース連結フォームのサンプルでは主要なファールドをリストボックスにして、その他のフィールドはサブフォーム状に別途、表示するというになっていました。これだと、一覧性が非常に悪くなります。
VisualBasicでも１明細を複数行に表示するコントロールは見たことがないので、多分できないのではないかと思います。


データベースにPostgresSQLを使っているので、PostgreSQLのメーリングリストを読んだりするのですが、Accessはあまり良い言われ方はしていません。オープンソースの開発メンバーからみると、Microsoftに対してあまり良い印象を持っていないこともあるのでしょう。Accessは不当に低い評価をされることもあるようです。そのくせクライアントをWindowsからLinuxに移行するのに、「Accessに代わるツールがLinuxに無いのが問題だ！」なんて言われることもあります。Windowsを使用する上でAccessが非常に重要なツールであることは事実なんです。

やっとできた(２)

Accessの問題点として、もう少しあります。
３．最適化しなければならない。
Accessを使用していると、特にAccessにデータを登録しているわけでもないのに、Accessのファイルサイズがだんだん大きくなります。これはAccessの内部で作成されたテンポラリーファイルをAccessが自分で削除しないためです。そのため、定期的に「最適化」してやらなければなりません。PCのことがよくわからないオペレーターに「一日に一回、最適化してね。」と言ってもはじまりません。プログラム的に必ず、最適化するようにしなければなりません。Access97は手動で最適化する場合は、メニューから最適化できますが、プログラムでやろうとすると、外部からcompactしてやらなければなりません。
私は、Accessに最適化用のフラグを持ったテーブルを用意して、一日一回外部の最適化用mdbファイルを起動してクライアントプログラムそのものを最適化しています。
一応、これで間に合っているのですが、オペレーターは「何でこんなことする必要が？」と思っていることでしょう。プログラムサイズなんか気にしない人ばかりですから。残念！
４．ヒープメモリーを開放していない！？
メモリーは512MByte積んでいるのですが、「メモリーがなくなったよ！」というメッセージがよくでます。どうもAccessがコントロールに使用したヒープメモリーを開放していないではないかと思います。この辺も1997年当時で64MByte程度しか積んでいないPCで使用したらどうなっていたのだろうと思います。
「メモリーのお掃除屋さん」というソフトを常駐させて、ガーベージコレクションさせていますが、効果はありません。Accessが開放しないメモリーは外からは使用中としか見えませんから、ガーベージコレクションの対象にはなりません。結局、ログオンし直しています。
５．Accessそのものがおちる
そう頻繁でもないのですが、Accessそのものがエラーメッセージをはいて止まるのではなく落ちてしまいます。通常のプログラムエラーだとエラーメッセージがでて停止するんですが、exclametionマークがでて終了してしまうんです。これは作成したプログラムのせいでしょうか。