猿頁

ここまで勢いで書いてきて、同時並行で勉強も続けていくと。…やっぱりあちこち勘違いや間違いがぼろぼろ出てきますね。
のでちょろちょろとあちこち文章や図を差し替えたりしてあります。
コンテンツもベータ版、などと言いつくろってみたりして。とほほ。

開発環境は、ある意味開発者が苦労すれば済む舞台裏なので別にいいと言えばいいです。
いゃ、もちろん開発する側にとってはむちゃくちゃ一大事なんですけどね。

でもここで言いたいのはそゆことではなく。
できあがったプログラムを受け取ってインストールして実務に趣味に使うユーザ側にとっての.netってのはどぅなんでしょ。

ただし。現在(2001/10/23).net Framework SDKもVS.netもベータ版。リリース版としては存在していません。
11月にWindows XPが発売になります(各メーカーはすでに受け取って製造ラインに載せているはず。個人でもOEM版なら10/26くらいに入手可ですし)が、たぶんこれに.net Frameworkが実装されている可能性はまずありません。

ので、たぶんIEやDirectXのよぅに別配布、＋リリース後、WinXPにバンドルって感じになると思います。

雑誌の付録や、VS.net製大手アプリケーションなんかにも同梱されるでしょうし、MicrosoftやVecterなどのサイトからのダウンロードもできるでしょうから、まぁ入手に困ることはないんでないかと。

正確な値はわかりませんが、DirectX 8.0aのSDKが144MB・ランタイムが11MB (Win2000用なら7MB)といぅ状況から類推すると、.net Framework SDKが131MBですので そのランタイムもまぁ10MB前後なのではないかなぁとタカをくくっています、私。

2001.10.31 追記
ランタイム、出てましたね。SDKと同じページで。
各国語版があるらしく、日本語版はJapanese REDIST。
約18MBありました。…上記の推測は、当たったうちに入るんでしょうか。

2006.03.28 追記 えー、今時点ではもう.NET Frameworkは2.0なんですよね…。
つことで各バージョンの入手先とかそのへん。

• .NET Framework Redistributable 1.0(日本語) 20.5 MB
  .NET Framework 1.0 Service Pack 3 9.8MB
• .NET Framework Version 1.1 再頒布可能パッケージ 23.2 MB
  .NET Framework Version 1.1 日本語 Language Pack 1.4 MB
  .NET Framework 1.1 Service Pack 1 10.2 MB
• .NET Framework Version 2.0 再頒布可能パッケージ (x86) 22.4 MB
  .NET Framework 2.0 日本語 Language Pack (x86) 1.8 MB

いやぁもうどうにでもしてくれって感じで。サイズ以前に、何DLしなきゃならんのか説明するだけで一苦労状態です。

投稿者: さるべーじ 日時: 00:01 | パーマリンク | コメント (7) | トラックバック (0)

えー、VB.netの言語仕様とかについては項を改めてまた後日書き綴るつもりなので、ここではもぅ少し開発/動作環境に絞って話を広げたいと思います。

VS.netのIDE。

従来のVSは、その中に各種言語のコンパイラやツールやソース/リソースを作成するためのIDEなんかが1セットになっていました。つまり、VSを買わない限りVBやVC++でのプログラム作成はできなかったわけです。
(もちろんVBやVC++の単体売りパッケージもありますが。それにしてもそれを買わないとプログラム作成ができなかった、ってのは同じです。)

ところが、今回の .net では、コンパイラは .net Framework SDK で提供されるんですね。
もちろんVS.netには.net Framework SDKが機能の一部として提供されているので含んで大なりなのですが、極論を言えば

ってことになります。プログラム作成に必須ではないVS.net。…ちょっと違和感があります、私。

VB.netのコンパイラであるVBC.EXE、C#.netのコンパイラであるCSC.EXE、VC++.netのコンパイラであるCL.EXEはすべて.net Frameworkの中にあります。

ので、テキストエディタで正しいソースを記述できるだけのスキルがあるのなら、なにもわざわざIDEを使わなくとも実行ファイルは作成できます。
(実際には、簡単なWeb用のスクリプトならともかく、中～大規模のソース/リソースをIDEなしで作成するのは非現実的な選択であろぅよと私は思っていますが。)

さて、コンパイラと密着しなくなってしまったIDEとしては、ではどこを目指していくのか。

とことんまでリソース作成機能ややヘルプ機能(MSDN)と密着し、ある程度のソース自動生成機能やチーム開発にも対応した開発環境として一本立ちしていこうとしているよぅです。

ので、どぅも動作を見ている限りでは、IDEそのものはほとんど言語依存していないよぅなんですね。
新しい言語が出てきても、その言語仕様のデータとヘルプを組み足せば、その新しい言語に即した動作ができる開発環境として動作できるよう作ってある感じです。

そぅいえば、つい先日(2001.10.12)Visual J#.netのベータが発表されましたね。製品版のリリースは2002年末くらいになりそぅですが。
もちろんこーいぅ後付けで出てきた言語に対しても、VS.netのIDEは対応していくとMicrosoftは明言しています。
実際、すでに20種類以上の言語が.netに対応していくと声を上げているそぅですし。
ただしこの20種類の言語が何々なのかは、ちょっと調べがつきませんでした。COBOL.netとかPL/I.netとかPascal.netとか出るのかなぁ…具体的なラインナップをご存じの方はいらっしゃいますか？
あ、こないだPerl.netはなんか見かけたよぅな気がします。C#のソースに変換するソフトだそぅで…それでも.net対応って言えば確かにそぅか。ちょっと目からウロコ状態。

MicrosoftがJAVAの取り扱いでSUNとケンカし(といぅか、あれはSUNはJAVAの主導権を主張してケンカ売って、Microsoftに「じゃあJAVAのデフォルトサポートなんかやめてやるぅ」って怒られた途端に泡喰って「WindowsにJAVAをデフォルトで入れろ」キャンペーンなんか張ったりして…って感じの騒動でした。な、情けない。)、てっきりJAVAから手を引いたと思っていたのでJ#.netの発表はちょっとびっくり。
でも、J#.netは「Java言語開発者向けのツール」であり「Java言語のスキルをそのまま活用」できるとは言っていますが、「J#.netはJAVAである」とは言っていないんですね。逆に、「Microsoft Visual J# .NET はマイクロソフト社の製品であり、サン マイクロシステムズ社との関連性は全くありません。」と言い切っちゃってるし。
うーん。おもしろいけど、これ、SUNとまた一悶着あるんだろぅなぁ。

CrystalReportsについてはシングルプロセスエンジンだったのが使いにくく、また製品版へアップグレードしよぅとした時の日本語版販売代理店のあまりにもお粗末な対応に失望したせいもあり、あまりいい印象を持っていません。
せめて同梱版できちんと使い物になるマルチプロセス対応のものであればいいなぁと淡い期待をしておりますが。

あ、それと。VisioXP(英語版)が同梱されておりましたよ。
IDEから実行すると、その時点でのクラスやらオブジェクトやらが描画オブジェクトとして自動生成されます。
ちょっとオブジェクトのデザインに私なんかは違和感を感じますが、ドキュメント作成補助まで考えてくれている姿勢は前向きに評価したところですね。

VB.netのコンパイラは、C#.netコンパイラなどと同じ独立した実行ファイルとしての提供になりました。ので、まず従来のように「IDEから[実行]ってやるとコンパイルなしでいきなり動作開始」ってことはできなくなりました。(正確には今までだって、動作単位ごとにp-codeコンパイルしながら実行してたんですけどね。オプションに、順次コンパイルのON/OFFってありましたでしょ？)
必ずビルド(VBで従来呼んでいた「コンパイル」じゃありませんよ)をした後に実行。もっともいきなり[実行]ってやると、自動でビルド→実行の手順を踏んでくれちゃいます。
で、今まではコンパイルした際にエラーがあると、最初に見つかったエラーにフォーカスが当たって実行停止。何ヶ所もエラーが内在している場合は、一ヶ所直して実行→次に指摘されたエラーを直してさらに実行、って繰り返していかなきゃならなかったんですけど。ビルドの場合はソースを先に読んで全部コンパイルして、全部のエラーをリストアップしてくれます。
今までのVBに慣れ親しんでいる方にはかなりな違和感かもしれませんが、ふつーコンパイラってそぅいぅものです。VC++もBorlandの一連の製品も、もっと言えばCUIの時代からコンパイラってそーいぅものでしたので、私なんかはよぅやくコンパイラとしてあるべきスタイルになったよぅな気がします。

で、なんでそんな仕様になったかといぅと、たぶんこれ、他言語とビルドの手順や中途生成物を同じレベルにしておきたかったんでしょうね。
その時々でのオペレーションの結果生成される中途生成物/最終生成物が同じレベルのものであるとどぅいいことがあるのか。

こ、これは嬉しい。
今までVBのサブルーチンをVC++で作るなら、VC++側をDLLにして、しかもそのつながりをテストするためにVB側をネイティブコード(最適化なし、シンボリックデバッグ情報を生成)コンパイルして、さらにVBソースの位置をVS IDE側にセットしてデバッガにかけていかなきゃならなかったんです。
それが今度は、なーんの考慮もなしでいきなりデバッグに突入できる。しかもひょっとすると、VB.netのソースとC++.netのソースを混ぜ合わせて1実行ファイルとしてビルドできる(んじゃないかなーと思ってるんですが、本当にできるかどぅかはまだ調べてません)。

この状態が成り立つのであれば、チーム開発において言語を絞り込む必要がなくなります。各々が自分のもっとも得意とする言語を任意に選びつつ、完成品はひとつのEXEとして提供できるようになるんですね。
(ただしここではチームメンバー内でのお互いのソースに首を突っ込む必要がある、という側面は考慮していません。また、納品後メンテナンスを担当する人間のスキルも考慮していません。そこまで考えると、商売としてプログラムを組む場合にはちょいと難しいかもしれませんね…。)

今まで他言語に対して孤立していたVBが

と解釈していいんじゃないでしょぅか。
そのためのVS.netのIDEへの参入であり、作成過程の統一なんだと思いますよ。

あちこち資料をあさりながらVS.netを勉強したりここらへんのコンテンツを書いたりしているわけなんですが、どぅも用語や概念があっちとこっちで食い違う、なんてことが今回多いんですよ。

• MSILはインタプリタ実行される
  MSILは実行時にはネイティブなマシン語コードに変換されるのでインタプリタのよぅな実行エンジンは持ちません。


• CLRの説明のはずなのに「CLS」と呼んでいる
  CLSはCLRのサブセット相当の共通言語仕様ライブラリです。


• C++.netでのネイティブなマシン語コードをアンマネージドコードと呼ぶ
  CLR配下にない非管理のコードはすべてアンマネージドコードなのであって、C++.netのネイティブなマシン語コードだけをアンマネージドコードと呼ぶわけではありません。

そこに持ってきて私の側の理解ミスなんかもきっとあるでしょうから…結果として、本コンテンツはかなりあやしげな確度にしかなっていません。とほほ。

でもまぁそんなにイタいレベルで大間違いはしていないと思ぅので。
よそ様よりは平易に、プログラマに必要だと思う情報をいち早く書き並べているつもりなので、そのへんの意を汲んでひとつご勘弁いただきたいところではあります。

もしミスや誤解を見つけられた方はご一報いただけると幸いです。

投稿者: さるべーじ 日時: 00:00 | パーマリンク | コメント (0) | トラックバック (0)

検証環境　自作ATX(Cerelon533/VT6X4/384MB)
Windows2000ProSP2/IE6.00Jp/VS.netB2J

マシン語だから。

すいません、嘘です。VS.netに含まれる言語で作成したプログラムは、基本的にはマシン語になりません。

じゃ、なんになるかというと。MSIL(Microsoft Intermediate Language)と呼ばれる中間コードになります。

中間コード。
VBでプログラミングしてきた方にはおなじみの響きですね。

ぶぶー。これは間違いです。どぅも今までの技術と1対1で紐づけて把握できる構成ではないようですよ。

上の図は、Visual Studio 6の開発フェーズにおける各プログラム/ファイルの関連の概念図です。単独実行ファイル(.EXE)としては、まぁこんな感じになるわけですね。

VBでは、ソースを書くための機能(IDE)と実行ファイルを作るための機能(コンパイラ)が同じひとつのプログラム(VB6.EXE)にまとめられています。ですから開発者は、ソースの書き始めから実行ファイルの作成までをひとつのプログラムの中でシームレスに行えます。
また、VB6.EXEは大まかに2種類の実行ファイルが作成できます。p-code(中間コード)とネイティブコード(マシン語)ですね。

一方VC++は、ソースを書くための機能(IDE)と実行ファイルを作るための機能(コンパイラ/リンカ)が分かれています。
コンパイラは単にソースをマシン語に置き換えるだけの作業しか行わず、これをいろんなWindowsファイル(やそのライブラリ)と組み合わせて実際にWindowsOSから動作を開始できるような実行ファイルに編み上げるためのリンカというプログラムが別に存在します。
ですから実行ファイルを作成することをコンパイルとは区別してビルド(コンパイル & リンク)と呼びます。
まぁ実際にはIDEからでもビルドはできるんですが、これはIDEがコンパイラ/リンカを呼び出しているんですね。
VC++が作成できる実行ファイルは、こちらも大まかに分けて2種類。MFC(VC++用ライブラリファイル)を別に必要とするタイプと、MFCが不要・もしくは自分自身の中に埋め込まれて単体ファイルで実行できるタイプですね。

今度の図は、VS6で作成したプログラムの実行フェーズにおける各プログラム/ファイルの関連の概念図です。

VB/p-codeの場合EXEそのものは中間コードなわけですから、これを解釈・実行する実行エンジンが別途必要になります。これをVBランタイムと呼びます。ですからp-codeプログラムの場合、実際に動作するマシン語はランタイムのそれであり、EXEファイル自体は実行手順を格納したデータファイルという扱いになります。
VB/ネイティブコードの場合は、一応動作手順はきちんとソースを元にマシン語化されたコードとして格納されていますが、実行中に使用する関数などの大部分はVBランタイムの中のコードをサブルーチンのように呼び出す形式を取っています。
ですので、p-codeにせよネイティブコードにせよVBランタイムは必須なわけですね。どちらが主か従かの違い程度です。

VC++ではすべてマシン語コードとして実行ファイルを生成します。
もっともMFCを外部に必要とするタイプのプログラムの場合は、配布ファイルの大きさやインストールの煩わしさはVBと大差ありません。
もちろんVC++で作ったプログラムの方がVBで作ったプログラムよりも、ふつー高速に動作します。 ざっと理解していただけましたか？
厳密に説明しよぅとするともっとあれこれ噛んでくるんですが、まぁ大ざっぱな理解としてはこの程度でいいのではないかと。
配布形態をどぅしよぅとか、より高速な/コンパクトなコード提供をどぅしよぅかと悩む程度であれば、まずはこのくらいのレベルで把握していれば考え出すことはできるわけですし。

まずIDE部分が、VB.netをも取り込んで1本のプログラムにまとめられました。
もちろん使用する言語によっていろいろ作業手順は異なりますが、まずオペレーションが統一されたのは大きいです。
また、デバッグがむちゃくちゃ楽になります。
さらに、どの言語を使ってもビルド後に生成される実行ファイルはMSILです。

実は、唯一C++だけは従来のマシン語コード実行ファイルを生成できます。これができないとデバイスドライバやらの低レベルな実行ファイルが作れなくなっちゃうので、ここんとこは残されて当然だと思います。
Microsoftとしては、もはやマシン語コード直書きはWindowsアプリケーションのスタンダードスタイルではない、といぅスタンスのように見てとれますね。

まぁ作成される実行ファイルがすべて同規格のMSILなんですから。実行フェーズとしては当然言語に依存しない単一の環境を用意しておけばいいわけなんですけれども。
このMSILファイルが実行時に少しずつマシン語にコンパイルされながら実行されます。
このへんちょいとややこしいんですが、呼び出される機能単位で必要になったつど(JIT：Just In Time)コンパイルされながら、CLR(Common Language Runtime)の管理下で動作していきます。
大ざっぱに言うと、使っている最中にコンパイルされながら動くプログラム形式なわけです。
…これ、けっこぅ効率の悪い方式のような気がするんですが。…まぁこのへん、もぅちょいいろいろ調べてからまた項を改めて説明したいと思います。

で。

ってことですね。

CLRも、VBのランタイムといぅよりは、VC++のMFCライブラリとOSのメモリ管理・セキュリティ管理機能を併せ持つといぅややこしい位置付けと捉えた方が正確っぽいです。

投稿者: さるべーじ 日時: 00:03 | パーマリンク | コメント (0) | トラックバック (0)

VS.netが使えるよぅになったところで。

実は私、言語仕様がどのくらい変わったかってことよりも、自分の作ったプログラムが安定供給/動作できる仕組みかどぅかの方がやたらと気になってるんですね。

VB4や5の時に、SP(バグフィックス用のパッチ)を当てたとたんに古いEXEが動かなくなったり動作が変わっちゃったりしたことがあったんです。
IEやOfficeのバージョン違いで動作が不安定になるなんて話もありましたね。
VB6/IE5/Office98(2000?)くらいになってかなり安定してきて、そのへんの不整合でで動作しないなんてことはなくなってきたんですけどね、最近。

で、ここへ持ってきて大幅な仕様の変更でしょ？…またOSや各種製品の不整合がぶり返さないのかなぁ。
ぶり返すとしたら、どこらへんに着眼して対処を考えればいいのかなぁ。

また、従来のVBの配布上の泣き所はランタイムでした。
他の言語で作ったプログラムと違って、VBは動作に絶対ランタイムファイルが必要なんですね。
これが1.5～2MBくらいあった上に、インストールプログラムをカマしてレジストリにばりばり登録しまくらないとならなかったので、配る方ももらう方もたいそうな時間を割かれてしまうってのがあったんです。
(当時はモデム～ISDNくらいの通信速度でしたし。ADSLなどブロードバンドにも耐えられる技術が普及を始めた現在、2MBなんか1分以内って感じになってきてはいるんですけどね。)

このへんの仕組みを調べていったら、話はどぅもVBだけでまとめられない感じだといぅことがわかってきました。

ので。
ちょっと話が遠回りになって申し訳ないんですが、ざっと.netのあたりから理解しておく必要がありそぅです。

Microsoft .netとか.NETとか、どぅもMicrosoftの中でも用語が統一されていないよぅな印象を受けます。従ってマスコミの記事回りでもこのへんの呼び名はバラバラ。私は本コンテンツ中では .net で統一しておきます。

簡単に言うと、今まで1台のパソコン+ひとつのOSでプラットフォーム(プログラムが動作する環境)としていた考え方を、インターネット(技術)を媒介とした複数のコンピュータ+それぞれのOSでひとつのプラットフォームという考え方に変えてしまえ、ってことですね。

えー、ピンときました？
まず、インターネットを介しての各種サービスが、近年むちゃくちゃ多様化/複雑化してきました。かなり高機能なビジネスモデルを実現したいなんてニーズも市場として確立してきています。

これらビジネスモデルの実装を行うには、サーバの構築、サーバ上でのサービスの作成、クライアントの構築、クライアント側のプログラムの作成なんて作業が必要です。
これがWeb機能やらメールやらをややこしく組み合わせたり、今流行のブロードバンド技術による動画の表示なんてことまで考えると、いろんなコンピュータ/OS/言語とか各技術の仕様なんかをそれぞれ調べて組み合わせてどぅのこぅのと、割と大変だったり途中で破綻したりしていたわけです。

で、これをひとつの開発環境にまとめてしまえと。サーバサービスからクライアントまでをひとつの開発環境でまとめて作成できるなら開発が簡単になるし、その後のメンテナンスもちょー楽ちんになるでしょ、と。
で、開発環境がひとつなんだから、もぅOSの枠に囚われずにこの開発環境丸ごとひとつのプラットフォームと考えちゃえ、と。

とまぁこんな感じの理解でいいかなと思います。

もちろん、この考え方は広くインターネット一般の開発環境をフォローするものではありません。
サーバからクライアントまで全部Microsoft製でなきゃいけないわけですし。
ですから、これは不特定多数に対する情報提供などを実現するモデルではなく、特定のサーバ/クライアントの関係を持つビジネスモデルの構築時に効果を発揮するんでしょうね。

趣味でのみインターネットを利用している方にはピンと来にくいかもしれませんが、企業内での情報インフラとか企業→顧客への特定サービス提供なんてのにもインターネットは活用されてまして、正直インターネットで金になるビジネスはこの部分です。
ので、Microsoftとしては一番金になる部分をみごとに取り込んだアプローチを開始した、と私は思っているんです。

ちょっと繰り返しますが。
前述のMicrosoftの公式説明では、サーバサービスはすべてWindows2000(XPも？)Server上でのみ実装されます。
いぇ、このへんを取り込んで .net Enterprise Servers と呼んでいますね。
また.netに対応するクライアントOSとしては Windows CE/2000/XP ということになっています。
ですから、現在インターネットサーバとして定評のあるUNIX/linuxはこの対象外ですね。パソコン以外のコンピュータももれなく対象外です。またクライアントとしても、UNIX/linuxやMacintoshは対象外となります。
さらに、たぶんクライアント上での動作保証ブラウザはIEのみになります。ので、趣味でサーバを立てて不特定多数のいろんな環境の人に利用してもらえるよぅな高度な情報提供が.netで実現できるかといぅと…まず無理なんではないかと。

うーん。なんか、MicrosoftのMicrosoftによるMicrosoftのためのインターネットって感じがしてきました。

ただし。
Macintosh用にはOfficeやIEも提供されていますし、いずれMac用の.netコンポーネントなんかも提供されそぅな気もします。
linuxは…なんかコミュニティ側で独自に作っちゃいそぅな気も…。

投稿者: さるべーじ 日時: 00:02 | パーマリンク | コメント (0) | トラックバック (0)

検証環境　自作ATX(Cerelon533/VT6X4/384MB) Windows2000ProSP2/IE6.00Jp/VS.netB2J

とりあえずはインストールしてみなくちゃ始まらない。ので、インストールしてみました。

でも、雑誌の付録に付いてきたのはDVD-ROM。私のマシンにはCD-RWドライブしかついていません。
ので、少ないお小遣いを握りしめて断腸の思いで買いましたよ、DVD-ROMドライブ。
いゃ、プレイヤーソフト込みで\8,000.-なにがしだったんですけど。
それでも妻子持ちのサラリーマンにはイタい出費ですね。とほほ。

で、フルインストしてみました。

もっとも、Win2000にIISをインストールしていないので(Webサーバ立てるわけではないのでいらんですよこんなもん。CodeRedの温床にしかなりません、今の私にとっては)、それに関連したモジュールはあるいはインストールされていないのかもしれませんが。別にWebアプリを作りたいわけではないのでいーです、今んとこ

。 なんかシステムドライブが1GB弱くらい食われちゃったよぅな気がするんですけど。
プログラムドライブも3GBくらいヤラれたよぅな気がするんですけれども。で、でけぇ。

Microsoftの言い分では、「本ベータは最適化を行っていません」のだそぅです。
ので、HDDもむちゃくちゃ食ぅ上に動作もむちゃくちゃ遅い、のは現時点ではしかたのないことですね。
このへんをベータで評価するつもりはありません。

しかし。
初回起動時に「ヘルプを更新しています…」のメッセージの後、システムエラーを出して落ちてしまぅのはどぅか。
いゃ、これもベータ版なのでシステム的に不具合があるのは当然のこと。
Microsoftへレポートを促すダイアログが出てきても別に文句はないです。

ないのですが。

これではちっとも評価作業が始められないではありませんかこんちくしょう。えーん。

えーと。
ヘルプの更新中にシステムエラーが発生するんですから、ヘルプをまったくインストしない状態にしてみたらどぅでしょうか。
ってことで、MSDN全アンインスト→VS.net起動。

…おぉ、起動した。

しかし。
まったくドキュメントなしで新製品をいじくるのもかなりつらいものがあります。
ので、VB .net回りのドキュメントだけ追加インスト→VS.net起動。

…おぉ、これでも起動する。

ってことで、MSDNのインストールオプションを1個ずつチェックして追加インスト→VS.net起動を繰り返してみました。

結果。
「その他のドキュメント」をインストしなければ、私のマシンではVS.netは正常に起動しました。
いいや別に「その他のドキュメント」くらい。ベータのサポート技術情報見たってどってことないし、MicrosoftのWebページで読めるし、手動でMSDNフォルダ以下を全部HDDにコピーしたらとりあえず全コンテンツ読めるみたいだし。

Microsoftのニュースグループ(日本語)を読むと、同じ症状に出くわした方が一人だけいらっしゃいました。

ってことは、割とまれな現象なのかなぁ。どぅもMSDNブラウザっぽいのでIE6jpとかそのへんのせいなのかも。

まぁ何はともあれ、なんとか動作できる環境は整いました。
さて、遊んでみましょうか。

今回このへんを勉強するにあたって、あちこちの掲示板やらMLやらNGやら読みまくっているんですが、なんかベータ版の意味を勘違いしているよぅな文面をちらほらと見かけるよぅな気がします。

仕様が最終的に確定しておらず、重大なバグが数多く内包されている状態で、建前上バグ出しを主目的として配布されるのがベータ版です。
評価する側の本音としては当然製品出荷前に勉強しておきたいんでしょうけれども、それにしたって不具合が多々あるだろぅことは当然念頭に置いての作業になるはずです。

のに、どーして「これこれの機能が正常に動作しません。」の次に来る文章が、

• どうしてですか。
  　↑ベータ版だからです


• 回避方法を教えてください。
  　↑どーして回避法があると決めてかかるんでしょ


• バグじゃないんでしょうか。
  　↑だからバグですって

ここには、「ベータ版はただで他人よりも早く入手できる製品版である」という誤解の匂いがぎゅんぎゅんします。
ついでに、MLやNGを自分のサポート代わりに考えている教えて君の匂いはもっとします。

• 同様の状態になった方はいらっしゃいますか。


• 回避できた方はいらっしゃいますか。

投稿者: さるべーじ 日時: 00:01 | パーマリンク | コメント (0) | トラックバック (0)

えぇと。

ついにVisual Studio .net Beta2日本語版(以下VS.net)が、びんぼーな私にも手が届く形で配布されました。VB Magazine 2001.11月号にDVD-ROMで付録としてくっついたんですね。私、さっそく買いましたとも。

聞くところによるとMicrosoft系やC系のいくつかの雑誌でも同時期に付録として配布されているよぅなので、C系プログラマな方やWindows/Web系な方もけっこう入手されているんではないでしょうか。

で。2002年第一四半期(3月末までに、ってことになりますが、今までのVisual Studioのリリース時期の遅れ具合を見ていると4～5月以降くらいになるかもしれませんね)に製品版リリース、その前の2001年11月にWindowsXPリリースというインフラの変化を考え併せると、そろそろVB6/VC6++で飯を食っている私としても、次世代のパラダイムに対してのスタンスを考えていかなければならない時期にさしかかっているよぅに思います。

って書くとなんかエラそぅですが、要は

と不安になりました、ってことですね。

ので、今のうちからあれこれイジってみよぅと思います。

投稿者: さるべーじ 日時: 00:00 | パーマリンク | コメント (0) | トラックバック (0)