20050329（レポートはTIFFに対応）
スレッドが前後してしまうが、VisualFoxPro9.0のレポート出力はPDFへの対応はなかったものの、TIFF画像フォーマットでレポートを出力できる。（詳細はVisualFoxPro9のページに掲載）最近までペーパーレスを目指しPDFへの出力を苦労して構築してきたが、セキュリティをある程度確保できる環境であればTIFFで充分だし手軽だ。コードもシンプルというか、レポートフォームが完成すれば作業は終わったようなものである。
20050329（VisualFoxProの今と昔）
昨年からVisualFoxPro2.XX時代に構築された巨大なシステムを現在のVisualFoxProにコンバートする仕事を経験している。昔のVisualFoxProのコードのかなりの部分が現在でも有効ではあるが、メモリとCPUパワーが少ない2.XXの時代のコーディングは仲々興味深いもので、象徴的なのはメモリ変数とファイルオープンの方法である。メモリ変数は極力ローカル変数が使われ、ファイルのオープンも処理それぞれで関連ファイルを開くようなコーディングが行なわれている。パネル自体の形式の一つが今は無くなっているが、これもメモリの少なさを補う工夫だろうか、パネル自体が変数を保存する機能を持っていた。今なら全てをパブリック変数に処理すれば済みそうだ。ファイルだって全部最初から開いた方が処理速度も上がる。ファイルのオープンクロース自体のロスも気になるのが昨今ではある。
20050211-20050225（PDFで出力は間違い？TIFFに対応）
ＶｉｓｕａｌＦｏｘＰｒｏ9.0をまだ入手出来ていないので大きな事は言えない。でも9.0は標準でPDFを出力するそうで、大変な期待をしている。クリスタルレポートだから当然という見方もあるが、結果的にアクロバットのお世話になれば一緒である。アクロバットと同等のPDFが出力出来れば即買いだと思う。しかしその後の報告でPDFには残念ながら対応していないという追加報告を貰った。しかしVisualFoxProを利用してAdobeのPDFエンジンやAyumiというPDFドライバーの利用は既に多くの方法が寄せられているので、大した問題ではない。むしろGDI+をVisualFoxPro9.0から利用できるために今までC++で可能になった画像処理の多くがVisualFoxProでも可能になる。過去のXbase開発者や詳細を知っている人々の間ではMS-DOSのXbaseのイメージが強くあることは事実であるが、VisualFoxProはそれらとは全く異なるObject思考の言語と考えた方が正解でる。実はVisualC#で作成したDLLをそのまま利用出来たりするとか、OCXは自由に使えるので、VBでも物を作るのに近い。VisualC++やVisualC#でコンポーネントを作成し、それを組み合わせてアプリケーションにまとめるのがVisualFoxProの役目の大きな部分と理解すると解りやすい。ＭＳはVisualFoxProをアプリケーションビルダーと位置づけている。一つの大きな理由はVisualBasicで作って不安定だったものが安定し、軽いというメリットがあるからだ。これはいつも最新のアーキテクチャーに対応しなくてはならなかった実験的な意味を持つVisualBasicとは対照的にVisualFoxProは実践的な言語という性格を持っている。実用的であることがVisualFoxProの使命なのである。とはいうもののVisualFoxProではWin31FunctionもOCXも古くから利用できたりと、Windows環境において必要な物は提供されてきた。唯一.NETは自らのライブラリーをツールキットとして提供し、C#等で継承させているが、全く対応しなかった訳ではない。１週間程度でVisualFoxPro9.0が手元に届くので更にレポートを続けたい。
20050210（VisualFoxProを何処使うのか？使わないのか？）
ＶｉｓｕａｌＦｏｘＰｒｏを現在使っているユーザーには二種類。私のようにXbaseを推進していて、他に選択枝がなくなった技術者とアセンブラからCやJavaまで何でもこなし、ＶｉｓｕａｌＦｏｘＰｒｏが最も使いやすいと感じた技術者だ。現在の日本ではＶｉｓｕａｌＦｏｘＰｒｏを使うのは大変だ。まず書籍が全くなく、日本語でサポートしてくれる場所はない。ＭＳに聞いてもそれは何処の製品と聞き返される。会社で仕事に使おう物なら責任は全て自分。公的な場所で認識されているのはどうも海外青年協力隊ぐらいで、ボランティアではお金にはならない。個人で使う範囲は良いけど、仕事では遠慮してしまうのが大半だろう。営業的に仕事は取りにくいし、さてどうしたものか？ではＶｉｓｕａｌＦｏｘＰｒｏでなくては出来ないものがあるのか？これもない。恐らくC++なら全てカバー出来る。良いことにＶｉｓｕａｌＦｏｘＰｒｏと比較してC++なら開発時間が数倍掛るからお金も取れる。良いことづくめである。ここまで来て気付くのはＶｉｓｕａｌＦｏｘＰｒｏはエンドユーザーにとっては実にありがたく、開発でお金を頂くソフトハウスには都合の悪い開発言語と言える。でもACCESSはＶｉｓｕａｌＦｏｘＰｒｏよりも工数はかなり少ない。あまりお金が取れないね。でも何故使うの？ＶｉｓｕａｌＦｏｘＰｒｏで出来た物と比較してACCESSはどうなの？これは両方を知っている技術者ならＶｉｓｕａｌＦｏｘＰｒｏはC++で完璧なアプリを作ったレベルまで追い込めるけど、ACCESSはまあ使える程度でしかないと全員が答える。日本でACCESSになる理由はそれしか出来ないからが理由の大半だと想像される。ただ今の日本はACCESSすらユーザーが少なくて、何でもExcelだそうだ。WordよりもExcelというのは笑えるが、真剣に考えると不安になる。ＶｉｓｕａｌＦｏｘＰｒｏは6.0まで80486の66MクラスのCPUで動いていて、完全な32ビットの8.0になるまで66Mとか133Ｍで充分に動いた。これがC++並に追い込める理由の一つで、現時点で最も軽い開発言語の一つであり、VBにもそこは負けない所か、遙かに上を行く言語という点、理解して頂きたい。
20040827（VisualFoxPro日本語版は何処に）
FoxProは数年前？まで秋葉原のLAOXで販売されていた事実を知る人も少なくなったと思いますが、これは全く本当の話で、MAC版とDOS版とWindows版の三種類が売られていました。はっきりした購入年度は覚えていませんが、私はMAC版とWindows版のVersion.2.5のライセンスを保有しています。その当時の2.5とか2.6はWindowsの古いマシンなら今でも動きますが、300ＭHzを越えるクロックのマシンでは「0で除算しました」というエラーで止まります。これを速いマシンで動かす方法は複数のプログラムを同時に起動（WorｄとExcelとFox）してみると、タイミングによって何故か動くのです。不思議ですが本当の話で、ＰＣのクロック落ちたようにFoxに見せ掛けると動くわけです。実際にそうやって動かした2.5が以下の画面です。1993年の製品ですから11年前なんですね。でも今でもマシンによっては動きます。このバージョンの問題は当時のWindows95の日本語版ではまともに動かなくて画面周りとかおかしかった事です。それが理由で私も放っておいたのですが、その後Windowsの4.0とかでまともに動く事を確認しています。2000でもXPでも動くようですが、300MHzのクロックオーバーではダメです。その後2.6だけは300ＭＨｚのクロックオーバーでも動作するバッチが用意されたようですが、既にVisualFoxPro6.0のユーザーになっていましたので、今更ねーでした。恐らくこの2.5が当時の日本語のWindowsでサクサク動いたらかなり様子は違っていたのだと思います。VisualFoxPro5.0からは日本語が問題なく使えるようになって今でも活躍していますが、少し遅すぎたようで、LAOXの店頭からは2.6以降はなくなってしまいました。
VisualFoxPro2.5の画面です。
20040726（ANSIの失敗）
1990年代の前半から半ばに至るまで全世界でXbase言語のANSIによる標準化の準備が進められておりました。（ANSI X3J19ミーティング）1990年の前半は日本の本屋さんに行くと何処にでもXbaseの本が今のACCESS並に置かれていたのです。当然システム開発の主流もXbaseでした。日本の名だたるコンピュータベンダーがXbaseを専門に開発している技術者と積極的に付き合おうとしていたのもこの時期です。実際の標準化についてはマイクロソフト、ボーランド、コンピュータアソシエイツ、サザンパシフィックの４社のプロダクツを中心にコードの標準化が進められていたのですが、丁度Windowsへの移行時期とも重なり、各社のWindows対応の内容には大きな隔たりがありました。ANSIで標準化されている言語の大半がDOSの時代に作業を終え、Windowsへは拡張で対応としているのに対して、XbaseではWindowsの部分まで標準化しようとした事も失敗の理由だったと言えます。もう一つ、日本のユーザーはまだ大半がDOSで生きていた為にWindowsの拡張部分が理解出来ていないという問題があったのも事実です。日本ではJCXL（Japan Council Xbase Language）という名前の組織でした。私も委員を務めておりましたが、事務所はサザンパシフィックに間借りし、当時の資料は全てコピーを会員に配布という、今にして思えば偉くお金の掛かる時代でした。ブロードバンドもなく、インターネットも普及しておりませんでしたので、資料の配布や連絡もNiftyのメールか、郵便や電話という時代でした。こうした背景が標準化はこれ以上は無理だと言う結論に至らせた理由だったと思います。その後はご存知のようにインターネットが徐々に幅を利かせ、WEBに特化した言語が世界中で注目を浴びるようになりました。
