  |
はてなキーワード: visual basicとは
今から25年前の1997年ののこと。当時小学生だった自分の1歳年上の従兄が、夏休みにお婆ちゃんの家にこのゲームを持ってきていたのが全ての始まりだった。
「タクティクスオウガっていうゲームがあるんだ。すげーから一緒にやろうぜ。」
従兄に勧められるままゲームを始めたのだが、タクティクスオウガが『すげー』ことはすぐに分かった。
中世ヨーロッパ風の権謀術数渦巻く世界観。重厚なBGMの中で敵味方がターン関係なく立体的なマップで繰り広げるリアルな戦闘。
背中に翼の生えたキャラクターが民家の屋根の上に移動して弓を射ると放物線上に矢が飛んでいくわ、ふわふわと宙に浮かぶ幽霊が魔法を唱え敵が炎に包まれると足元の草が焼けるわと細部までこだわったビジュアル。
とにかく衝撃的なゲームだった。いてもたってもいられなくなり、従兄がお婆ちゃんの家から帰った直後にお小遣いを握りしめて町のゲーム屋さんに走った。
お店のレジで商品を買うときにすごくドキドキしたのを今でも覚えている。スーパーファミコン版のタクティクスオウガの商品パッケージは英語でタイトルが書かれており、フォントが英語の旧字体みたいな形だったので、読み方があっているかな、間違って別のソフト買っちゃうんじゃないかなとすごく緊張したのだ。ぜんぜん自信が無かったが、店員さんにタイトル合ってるか確認して無事に買うことができた。
ワクワクしながら商品を持ち帰り、ゲームを始めたが小学生にとっては、難易度が高く難しいゲームだった。初回プレイ時にはキャラクターの強さを表すパラメータが多すぎてさっぱり分からなかった。
だけど作りこまれたチュートリアルとオンラインヘルプ等の親切な機能がたくさんついていたおかげで何とかゲームを進めることができた。一番助かったのは戦闘中の中断セーブ機能だ。小学生の時には、1日ゲームは30分までというルールがあったので非常に助かった。
さて、ゲームを買ってから2週間くらいの時のこと。難しいながらも俺はどうにかChapter1の終わりまでシナリオを進めていた。このゲームはプレーヤーが会話中の選択肢を選ぶことでシナリオが分岐するんだけど、途中で出てきた選択肢が衝撃的だったのは今でも忘れられない。ネタバレになるので詳細は伏せるが小学生には重たすぎる内容だった。無茶苦茶悩ましい選択だったが、片方を選んでゲームを先に進めてみた。だが、すぐにゲームに行き詰った。キャラクター育成をよくわからずに進めていたので自軍のユニットが弱く戦闘で勝てなくなったのだ。このまま先に進めないのも悔しかったので攻略本を買うことにした。
ここで話は少々脱線するのだが、俺の生まれ育ったのは日本海側の田舎町だ。町の本屋さんはあまり大きくない。なので、地元の本屋さんの攻略本コーナーにはメジャーな作品のものしか置いてないわけだ。ゼルダの伝説とか、ドラクエとかFFとかまあそれくらい。それらに比べるとタクティクスオウガはマイナーだった。苦労を重ねて隣町の古本屋さんで偶然攻略本を見つけて手に入れるまで1か月かかった。その後は攻略本を熟読してゲームシステムの理解を深めて1から再挑戦したのだが、家の方針で1日のゲーム時間が30分に制限されていたので、クリアするまでにはさらに2ヶ月ほどの時間を要した。だけどその分クリアしたときの達成感は大きかった。興奮冷めやらぬ俺は、小学校の同級生たちにタクティクスオウガのすごさを布教したが上手くいかなかった。俺がタクティクスオウガに出会った1997年当時、家庭用ゲーム機の主役はスーパーファミコンからプレイステーションに移行しつつあり、同級生たちはファイナルファンタジー7やファイナルファンタジータクティクスといったスクウェアの大作ゲームに夢中になっていたのだ。
同級生のN君に、「タクティクスオウガってファイナルファンタジータクティクスのパクリでしょ？」と言われたのは傷ついたなあ。なんていうか、自分がイケてると思ったゲームをディスられるという経験がなかったので。残念ながら、うちの地元では最初にタクティクスオウガを紹介してくれた従兄以外に周りでタクティクスオウガファンを見つけることができなかった。
それから2年後の1999年。俺は中学生になり、田舎町の我が家でもインターネットが使えるようになった。ネットが使えるようになってすぐに、以前はまっていたゲームのタクティクスオウガの攻略情報を調べてみた。地元の田舎町にはいなかったタクティクスオウガファンは、ネットの向こうにはたくさんいるようだった。ファンの集めた情報は膨大で、攻略情報にとどまらずゲームの舞台背景の考察やクリエイターの音楽の趣味までカバーしていて、中学生の俺の知的好奇心はガンガン刺激された。ディレクターの松野氏の名前もこの時に知った。余談だが、「タクティクスオウガとファイナルファンタジータクティクスは主要な開発スタッフが同じ」というのも同時期に知ったので、小学生の時にパクリ呼ばわりしてきたN君に対して「両方同じ人が作ってんだよ、適当言うなざまあ」という気持ちが芽生えたのはここだけの話である。
ネットの情報から刺激を受けた俺はゲームの世界観をもっと味わいたくなって、前作の「伝説のオウガバトル」もプレイしてみた。ディレクターの松野氏が好んでいたらしいQueenの楽曲を聞いてみたくなり、生まれてはじめて洋楽のCDを買いにも行った。コーヒーを飲めるようになった時のように、背伸びして少し大人になった気分がした。
そのうち自分でも似たゲームを作りたくなって、おこづかいでVisual Basicを購入したりもした。プログラミングの入門書片手にそれらしい画面までは作ったが、しょせんは中学生。体系だったプログラミング言語の知識がないためサンプルコードのコピペに終始し、1年くらいかかって紙芝居のようなものが出来て終わった。その後は、高校入試・大学入試で忙しくなったのでしばらくゲームから遠ざかっていた。
そこからさらに時が流れて俺は社会人になった。中学生の時のゲーム作りの経験から、ソフトウェアエンジニアの適性は無いなと思ったのでハード系のエンジニアとして就職した。タクティクスオウガから受けた影響は俺の人生を変えたのである。ゲームから遠ざかっていた俺だが、2010年にタクティクスオウガの1度目のリメイクのニュースを聞いて再び情報を集めだした。そこでたまたま開発者の松野氏のプロフィールを見つけたのだが、なかなかの衝撃だった。
まずはスーパーファミコン版のタクティクスオウガ開発時の年齢。発売日の時点で29歳なのである。ゲームの開発期間が2年くらいだとすると、開発開始時は27歳くらいだろうか。その若さであの革新的なゲームの開発指揮を執ってたのかよ！松野氏と面識のあるゲームクリエイターがインタビュー記事で天才という理由が分かった気がする。次に出身地。新潟県の妙高市となっている。地方出身であのゲームの重厚なシナリオを描くだけの知識を身に着けたのか！というのがもう一つの驚きだ。
先に俺の出身地が日本海側の田舎町だと書いた。地方で育ったからわかるのだが、地方はゲームの攻略本に限らずあらゆる情報が都会に比べて乏しい世界だ。タクティクスオウガの世界観を形成している中世ヨーロッパの歴史や文学の知識を松野氏はどこで得たのだろう？世代的にインターネットが無い時代なので、俺が田舎で育った時よりもさらに情報は手に入れにくいはずである。これは今でも気になっているので、今度出る予定のリメイク版の開発者インタビューでだれか聞いてみてほしいところである。
最後になったが、今回出る2回目のリメイク版もすごく楽しみにしている。なんていうか2回もリメイクが出るだけでもすごいのに、2回ともオリジナルの開発メンバーがかかわっているのがまた驚きなのだ。
発売元のスクウェア・エニックスはFF・ドラクエ等の過去の作品をよくリメイクしているけど、オリジナルのスタッフが何度もかかわるケースは珍しくないだろうか？しかも開発者の松野氏はリメイク前にスクウェアを退社しているのだ。それでも声がかかるのだから、本人のカリスマ性がメチャクチャ高いのだろう。過去に会社を辞めた人が2回も開発現場に呼ばれるって相当なことだと思うんよね。
VBA（Visual BASIC for Application）からプログラミングを始めて、「プログラミングとはこういうもの」という感覚を身につけてしまった人は、絶対に他のプログラミング言語の世界に入ってきてはならない。
一度VBAに慣れてしまうと、プログラマとしての正常なセンスを身につけることがほぼ不可能になるからだ。
これは、ヒトラーやポルポトや金日成などを良しとして政治に入門した人が、ふつうの政治の感覚を身に付けるよりも大変なことだ。
VBAでプログラミングに入門した人は、これからもVBAだけをやること。間違ってもプログラマになろうなどとは思わないこと。そして、プログラミングを知らない人にVBAを推薦したりしないこと。
以上。
エンジニア仲間どうしで年に何回か情報交換を兼ねて飲み会を開催していたのだが、今年はコロナウイルスのせいでZoom呑みに変更した。結果的に、これ以上この会意味あるんだろうかと思うようになってきたので吐き出しておく。
最初のうちは感染の拡大や緊急事態宣言による仕事への影響や、リモートワークの生産性の話をしたり、最近上中里にも店舗ができたらしいオメガラーメンの食レポめいた話題が出たりした（参加者にはラーメン好きが多い）。
雲行きが怪しくなってきたのは、いちばん年上の方のムラタさんが会話を独占し始めてからだ。Visual Basic一筋でもう20年以上やっているフリーランスで、いろいろな知識をシェアしてくれて悪い人ではないのだが、もともと朴訥というか突っかかるような話し方をする人で、酔っぱらうとそれに拍車がかかる。最近やっと住宅ローンを組んで町屋にマンションを買ったのだが、コロナのせいで案件が細ってきて、返済がやばいという話をして場を暗くしていた。
そこまではまだいいとしよう。問題は、ユウダイを絶対に許すなとムラタさんが強硬に主張し出してからだった。
ムラタさんによれば、ユウダイという名前の響きがまずよくない。ユウダイはキラキラネームに属するべきもので、一般に広く普及するべきではない。それなのに、平成の頃にユウダイと名付けられた男児が大きくなって社会のメインストリームに大量に出てくるようになって、テレビなどでもごく普通にユウダイを見かけるようになった。これは非常によくない、ジェネリックな名前なら太郎とか一郎にしておくべきであって、ユウダイは許されない、現状はコロナウイルスよりも危機的状況である。もとはといえば、ユウダイなどという響きの名前がかっこよいと思って名付ける、ゆるゆるの平成ママが悪いのだが（名付けるのは母親だけとは限らないと思うのだが、ムラタさんの頭の中ではユウダイは母親が名付けているらしい）、もはやどうしようもない。残された道は「日本全国のユウダイを許さない会」を結成し、ユウダイの社会侵食を防ぎ、いずれ根絶することである。
画面の向こうではムラタさんの目が据わってきて、ボサボサの髪を振り乱し、他の参加者に向かって、お前らも「日本全国のユウダイを許さない会」に加入しろ、おのれっユウダイ、許さんと叫んでいた（リアルでおのれとかいう人をはじめて見た）。若干コミュ障気味のムラタさんは最近祐大か雄大という名前の人事担当者に干されたのかもしれないが、ユウダイに対する深い怨恨の原因は結局不明である。この状況がしだいにだるくなってきたので、iPadの充電が切れそうだから寝ると言ってWindowsをシャットダウンしてから歯を磨いた。
このプログラミング言語はMtGだと多分この色の組み合わせだろう。
みたいなのをまとめたら次のようになった(TIOBEのランキング順トップ50)。
後半は知らない言語もあって怪しいが、おおよそこのようになると思われる。
※改めて見てみると何箇所か違和感があったので最初の版からちょっとだけ修正した。
| 順位 | プログラミング言語 | 色の組み合わせ | 内訳 |
|---|---|---|---|
| 1 | Java | アブザン | 白黒緑 |
| 2 | C | ゴルガリ | 黒緑 |
| 3 | Python | ティムール | 緑青赤 |
| 4 | C++ | ジャンド | 黒赤緑 |
| 5 | C# | バント | 緑白青 |
| 6 | Visual Basic .NET | セレズニア | 緑白 |
| 7 | JavaScript | ボロス | 赤白 |
| 8 | PHP | グルール | 赤緑 |
| 9 | SQL | 無色 | |
| 10 | Swift | 4C(緑欠色) | 白青黒赤 |
| 11 | Go | ゴルガリ | 黒緑 |
| 12 | Assembly language | 黒単 | 黒 |
| 13 | R | イゼット | 青赤 |
| 14 | D | グリクシス | 青黒赤 |
| 15 | Ruby | 赤単 | 赤 |
| 16 | MATLAB | イゼット | 青赤 |
| 17 | PL/SQL | 無色 | |
| 18 | Delphi/Object Pascal | アゾリウス | 白青 |
| 19 | Perl | ラクドス | 黒赤 |
| 20 | Objective-C | エスパー | 白青黒 |
| 21 | SAS | アゾリウス | 白青 |
| 22 | Visual Basic | 緑単 | 緑 |
| 23 | Dart | ジェスカイ | 青赤白 |
| 24 | Scratch | 白単 | 白 |
| 25 | Scala | 5C | 白青黒赤緑 |
| 26 | Groovy | ナヤ | 赤緑白 |
| 27 | Transact-SQL | 無色 | |
| 28 | F# | アゾリウス | 白青 |
| 29 | Rust | マルドゥ | 赤白黒 |
| 30 | COBOL | オルゾフ | 白黒 |
| 31 | ABAP | アゾリウス | 白青 |
| 32 | Lisp | シミック | 緑青 |
| 33 | Kotlin | 4C(緑欠色) | 白青黒赤 |
| 34 | Logo | 白単 | 白 |
| 35 | RPG | ディミーア | 青黒 |
| 36 | Lua | 緑単 | 緑 |
| 37 | Fortran | スゥルタイ | 黒緑青 |
| 38 | PowerShell | ジェスカイ | 青赤白 |
| 39 | Ada | ディミーア | 青黒 |
| 40 | LabVIEW | ディミーア | 青黒 |
| 41 | Erlang | 緑単 | 緑 |
| 42 | Julia | イゼット | 青赤 |
| 43 | ML | 青単 | 青 |
| 44 | Scheme | シミック | 緑青 |
| 45 | Haskell | エスパー | 白青黒 |
| 46 | TypeScript | ジェスカイ | 青赤白 |
| 47 | OpenEdge ABL | アゾリウス | 白青 |
| 48 | LiveCode | アゾリウス | 白青 |
| 49 | PostScript | 無色 | |
| 50 | ActionScript | ジェスカイ | 青赤白 |
見返してみるとおおよそ次のルールに従って決めているような気がした。
緑の判定があやふやな気が若干しないでもない…
| 色 | イメージ |
|---|---|
| 白 | 高レイヤ、初心者向け |
| 青 | 浮世離れ、ベンダー |
| 黒 | 低レイヤ、黒魔術 |
| 赤 | 速い、先進的 |
| 緑 | 基盤、グルー |
| 無色 | 道具 |
何かの参考とかにしたらダメです。書き始めて半年経つんだけどこっからどう直したらいいんだか（何をゴールにしたらいいのか）わからない。。
追記：合流性とか強正規化可能性とか停止性とか、全部チューリング不完全で、事前の静的解析で使うメモリの最大量が確定できる、とかそういう風に読み替えられる人を増やしたいのです、数式の添え字とΣと∫にびびらない人を増やしたいようなもので
数理論理学の一分野である証明論から成長した、数理論理学と理論計算機科学の境界領域の研究領域である型理論(type theory)は、大規模なプログラムの内的な整合性のチェックを行うための方法論を必要とする情報処理技術の分野で関心を集めている。
そもそも「型」(type)とは何か。プログラミング言語は一般的にはレコードや関数といったプログラムを構成する「値」(value)の定義をする道具である(*1)。その言語のコンパイラ作成者はこれらレコードや関数などの値、もしくは第一級の対象(first-class object)の種類を区別する型システム(type system)を必要とする。抽象代数学の観点からすると、「型」とはこれらの値もしくは第一級の対象が属する高階の対象(higher order object)としての空間(space)ないし代数系(algebraic system)で、型システムはそれら「型」とそれら相互の関係(relation)つまり型のなす順序構造(order structure)ないし束構造(lattice structrure)であるといえる。
プログラムを構成する値すべてに型が付くためには、曖昧でない(*2)こと、自己矛盾していないこと、悪循環を含まないこと、それぞれの値の内容をチェックするために無限の時間を要しない(*3)ことなどが必要で、これらを満たすなら、プログラムは有限時間で実行を終え、停止する。手続き型言語では無限ループ、型無しラムダ計算では無限再帰によって型付け不能なプログラムを書くことができるが、型理論はこれらのチューリング完全な計算機を意図しない停止しないプログラムから守る装甲でもあり、再帰やメモリ確保で好き勝手をさせないための拘束具でもある。型が付くプログラムには単に停止するというだけでなく、可能な実行経路（訂正：経路→方法）のすべてで同じ結果を出すなど種々の良い性質がある。
1)この定義は現実に使われているプログラミング言語の特徴を覆い切れていない、狭い不満足な定義だが本稿では都合上この定義に立脚して限定的に議論する。例えば変数(variable)というものを持つプログラミング言語もあり広く使われているが、これについてはレコードや関数と同じように性質の良いものとして扱うことが難しい。難しさの原因は次の注の内容と関連する。近年は変数を扱うかわりに値の不変のコピー(immutable copy)やその参照に名前を付ける機能を持つプログラミング言語が増えている。
2) 現実の情報システムでは、COBOL言語のレコード再定義やC言語の共用体、一般的な関数ポインタやVisual Basic言語のvariant型変数のように、同一領域に異なる型の値が共存する共用型(union type)の値がしばしば必要となる。共用型の値はgoto文を排除した構造化／オブジェクト指向プログラミングにおいて条件キャストやクラス分岐などによる実行経路の複雑さの主要な原因になるが、これは和型(sum type)すなわち相異なる型の非交和(disjoint sum)として定義することで曖昧さなく定義できる。
3) ゲームプログラムやネットワークサービスにおいてしばしばみられるように、入力として無限リストや任意に深い木のようなものを想定する場合には明らかに（条件を満たさない限り）停止しないことが正しい動作となり、この場合は最外周のループを（←どうする？）メモリリークを起こさないなど別の考慮が必要となる。
外部ライブラリが果てしなくあり、
← それはPythonに限ったことじゃないでしょ。JavaでもRubyでもPerlでもCでも同様。主要言語はほぼそうでしょ。
それはむしろ逆。Python のスローガンは There's Only One Way To Do It で、これは Perl のスローガン There's more than one way to do it. を意識したもの。
https://wiki.python.org/moin/TOOWTDI
なお、個人的には C# は良さそうだなとは思うけど、Windows以外のプラットホームではどうなんでしょう。（よく知らない。） これは Visual Basic についても同様。
外部ライブラリが果てしなくあり、似たような機能を実現する方法が複数あるので、本によって書いてあることが違ったりする。
逆説的ではあるが、初心者は、Visual BasicやＣ＃あたりから入るのがいいような気がしてきた。
逆引きハンドブックのような本を片手に、チュートリアル本を手打ちでコードを動かしながら読了すると、Visual BasicやＣ＃の世界は一通り把握できる。わからないことは索引を見ればだいたい出ている。Visual BasicやＣ＃があんまり尊敬されてなくて、限界や不満もあることもだんだん理解できる。
Visual BasicやＣ＃でも相当なことができるし、そこからスマートな言語に移行すれば、比較対象となるものがあるので、守備範囲を自分のペースで広げていける。
その発言した増田ではないが、その発言は少し無責任な気がするので補足。
まずRはやめるべき。
逆に統計くらいでしか使わないので、貴方が算術処理をバリバリやるのでなければ使用するべきではないだろう。
Pythonも言語だが、Rに比べると汎用的であり、かつ機械学習（scikit-learn、NumPyやPandas等の統計ライブラリ主体だけど）などでも使われていてホットな言語である。
ホットな言語だと、書籍やネット情報が豊富にあるので、学ぶ分には困らないのでもしプログラミング言語をやりたいのであればPythonをお勧めする。
そして、Excelマクロも一応Visual Basic for ApplicationというVBを下敷きにした言語なので、その言語を今から学ぶのであればPythonを学べばいいのではないかというのが先の発言の趣旨ではないかと推察する。
しかしながら、言うまでもなく、Excelのセルに書かれたデータをあれこれしたい（主に業務で活用したい）という要件ならVBAが最適である。
プログラム言語って得意／不得意があるから、やりたいことに合わせて使う言語を変えたほうが幸せになれます。（本格的なプロジェクトだと選択の余地はなかったりするけど）
なお、おうちで触りたいというレベルなら私もPythonをお勧めします。
MacでもWindowsでも同じ書き方で、Excelに囚われず色々な処理ができる。AIやIoTなどで需要が高まっているので覚えておいて損はないし。
「これだけ凄いから導入許可をください」と情シスに掛け合えるレベルまで成長したら会社でも使えばいい。
ただ、対象者はちょっとしたプログラミング言語を覚えて、手間がかかることを自動処理とかしてみたいなぁと考えられる人。Excelが効率よく使えれば十分って考えの人にまでお勧めするものではないので、その辺は誤解がないように。
ホッテントリメーカーで作るような煽りタイトルって、みなさんもう見飽きてると思うんですよね。
今調べたらホッテントリメーカー2008年だそうで。どうりでねー。古臭いなーと思いましたよー。
「一から学ぶJava」ってのをね、1.0にするだけでこんなに素敵なタイトルになるんだから面白いですねー。
タイトルを思いついただけだったんですけど、思いついたらやっぱりちゃんと中身も書かないと行けないじゃないですか。やだー
面倒くさいんですけどね。ちょっと1.0から学んでみましょうか。
Javaの1.0がリリースされたのは1996年1月23日ですね。発表されたのが1995年5月23日でJavaの誕生日といった場合にどちらを取るかで揉めることがあります。
かれこれ20年前なわけで、当時のパソコンというとハードウェアはCPU が Pentium 133MHz メモリ16M とかそんな感じだったかなあ。今どきの携帯電話の例としてiPhone 6sを挙げるとCPUが1.85GHz メモリ 2G ってんだから凄いですね。OSは1995年11月23日にリリースされたWindows95とかそんな時代背景です。インターネットがようやく一般に普及し始めたところでしょうか。
今から思うと相当弱いハードウェアですけども、そろそろVM方式を採用しても良さそうな、そんな時代でした。インタープリタだと流石に遅い、でもC言語のようなコンパイル言語だと"Write once, run anywhere"とはいかない、という判断もあったのだろうと思います。Javaが純粋なオブジェクト指向言語ではなくintなどのプリミティブ型を持つというのは、当時のマシンスペックを考えた場合、ある程度妥当な判断だったと言えるでしょう。これが後々苦しくなってくるわけなのですが。
Javaを作った会社はSun Microsystems(サン・マイクロシステムズ)というアメリカの会社で、2010年1月27日にオラクルにより吸収合併され今はありません。SolarisというOSとSPARCプロセッサでUNIXサーバーの販売で90年代後半までは一人勝ちのような状況だったと聞きます。当時にすでに「ネットワークこそがコンピュータ」（The Network is the Computer）というモットーを掲げてたんだからおかしい。1996年リリースのJavaが標準でネットワーク機能を備えていたのもこのあたりの思想から来ているのかもしれませんね。
当時のプログラミング言語としてC++が挙げられますが、C++でのプログラマへの負担といいますか、ヒューマンエラーの起きやすさといいますか、その辺を改善する目的で開発されたのがJavaだったわけです。
1996年の時点にこんな言語が登場したのですから革新的でした。
いろんな企業がJavaに賛同します。その中にはMicrosoftもありました。この時期、Microsoftは次期のWindows開発用のプラットフォームにJavaを据えようと考えていました。その後、袂を分かつことになるのですが……。
プログラム言語として構文などを見ると、C++を強く意識した構文なのは間違いなく、しかしポインタ演算を廃してポインタを機能を限定した「参照」に置き換えるなど簡素化が多く見られます。C++からはいろんな機能が削られています。関数ポインタ、構造体、演算子オーバーロード、テンプレート((テンプレートについては実装が間に合わなかったという話を聞きます))などなど。そのためC++の劣化であるように揶揄する人もいますが、こうしたものを捨てて言語仕様を比較的小さくシンプルに抑えた点は評価に値すると思います。しかし、今でもこうした削減された機能を愛する人からはJavaを腐す要素として挙げられてしまうのでした。
Wikipediaからピックアップすると1.1での大きな機能追加は
といったところです。当初よりJavaの内部文字コードはUnicodeで文字を表すchar型は16bitで設計されていました。Unicodeは当時それほど普及しておらず、Unicode対応のテキストエディタさえ少なかったと記憶しています。時代を先取りしていると言えますが、大きな誤算はUnicodeが当初16bitのコードポイントに世界のあらゆる文字を格納しようとしていたことで、漢字圏の我々からすると16bit=65,536程度の空間に文字が全部入るわけないだろ！というものだったが故に早々に破綻し、Unicodeは21bitのコードポイントに拡張されることになるのです。これはまた後の話。
なんにせよ、日本語が対応されたのは1.1からで、日本でのJavaの採用が始まったのはこの頃からと言えましょう。
当時のJavaのGUIはAWTというものでしたが、これを用いたGUIの開発は当時は結構行われていたイメージですね。Visual BASIC でGUIを作るプロダクトも結構あったと思います。GUIのためのオブジェクト指向言語としてJavaが使われていたイメージがありますね。JavaBeansもそのための仕様でした。件のsetter/getterの話題に繋がっていくのですが。
JDBCはJavaとデータベースをつなぐインターフェースです。RMIではあるJava VMから別のJava VMにオブジェクトを送って実行する、といったことができます。こうした機能が用意されたことで、ソフトウェアのフロントとしてのGUI、裏方の実装のためのネットワーク機能、データベース機能、さらにはソフトウェアを配布するためのJava Appletという布陣でJavaでのソフトウェア開発が加速していた時代といえます。
Microsoft Visual J++ もこの時代ですよ。
Java 1.1以降のバージョンのものは互換性確認のためにOracle Java Archiveからダウンロードすることができ、今でも入手することができます。もちろん、Java7ですら2015年4月にEOL(End of Life,サポート終了)となっているので、通常利用するのはJava8としてください(本稿執筆時点)。
当時のドキュメントを見るのも一興です。現在と比べると標準APIがかなり小さい。なお、当時のjavadocは今とはデザインが大きく異なります。
この時代であれば、全パッケージを舐めて標準APIを学ぶこともそう難しくはありませんでした。この時代から触っている人間は新バージョンが出るたびに増えるAPIを順に学んでいけたのです。しかし、現代にJavaを学ぶ場合、どのバージョンでは何があって……というのをいちいち学ぶ必要はほぼありません。Java5以前は一緒くたでいいと思いますし、一部のAPIで歴史的経緯があってねーというのを知っていればおそらく十分ではないでしょうか。
strictfpキーワードは浮動小数点演算をやる人は覚えておきましょう。JavaはパフォーマンスのためにCPUの浮動小数点演算を扱うことが許されており、そのため実行するCPUによって精度が異なることがあるんですね。まあ今時のCPUだと大丈夫だとは思うんですが。
リフレクション機能ではJavaのクラスを抽象的に扱うことができます。設定ファイルに書かれたクラス名のclassをロードして実行する……みたいなことができるんですね。フレームワーク的なものを作る場合には多用することになります。
1.2からは新しいGUIのSwingが採用されました。AWTがOSごとのGUIパーツを用いていたためデザインに違いがあったのに対し、Swingでは統一的なルック・アンド・フィールが用いられるようになりました。まぁ今ならJavaFXを使うのが良いと思います。
初期のJavaはやはりVM方式の実行速度の遅さが指摘されていました。実行時の構文解析を伴わないだけインタープリタよりは早いものの、実行バイナリを作るC/C++よりは遅い、そうした評価です。ここではサン・マイクロシステムズのVMにJIT(ジャストインタイムコンパイラ)が乗ったことが挙げられていますが、JIT自体は別の会社が先駆けて開発していたことは記しておきたいと思います。
JITコンパイラは実行時にJavaのバイトコードを環境のネイティブコードにコンパイルして動かす技術です。この後、JITコンパイラ、動的再コンパイル技術、世代別ガベージコレクションを備えたHotspotといった様にJavaVMは進化していきます。現代では実行時の最適化が進み、大きなスケールで見た場合、Javaの実行速度はC/C++での実装と比べてそれほど遅れるものではありません。遅くても倍の時間は掛からない程度といったところでしょうか。
あとは特記すべきはコレクションフレームワークです。皆が多用しているであろうjava.util.Listやjava.util.Mapといったライブラリが整備されたのがこの時なのです。それ以前はjava.util.Vectorやjava.util.Hachtableというクラスが可変長配列の機能を一手に担っていました。今ではVectorやHashtableは使うべきではありません。
Java の開発はSun Microsystems が主導していたけども、すべてがSunのものだったというわけでもなく。Javaには多くの会社が出資していてその中のひとつがMicrosoftだったわけですね。
Microsoft の Visual J++ では delegate とか独自機能拡張もありましたけど、裁判で問題になったのは J++ でコンパイルしたclassファイルはMicrosoftのVMでしか動かないという部分ですね(他社製のVMで動くclassファイルを作ることもできる)。classファイルがどこのVMでも動くの大事だろ、"Write once, run anywhere"だろ、お前何してくれてんの！と喧嘩になったわけです。当時のMicrosoftはブラウザまわりでも独自拡張がやりたい放題、標準規格？なにそれ美味しいの？みたいなスタンスをあちこちで見せていたものです。
結局、この事件でMicrosoftのJavaはバージョン1.1相当でストップ。好き勝手にやれないなら独自に言語作るわーとばかりに.NET フレームワークと C# といった方向に舵を取ります。
JavaがPC上でのUI開発の主力になろうとした勢いはここで潰えます。
Java SE とは別にこの時代に Java EEがリリースされていることは特記しておきたいですね。これ以後、それまでのCGIに取って代わって、JavaはWebサービスの開発のプラットフォームとして多用されるようになります。
2000年あたりからはJavaはGUI開発というよりは、Webサービスの開発が主流という流れになっていきます。インターネットのサービスが非常に発達していった時代、背後ではとてつもない量のJavaのプログラムが支えていたわけです。ただまあ、こうした産業利用は一般的なユーザーの目にはあまり入らないわけです。一般人からすればJavaといえばJava Appletみたいなイメージはずっと残っていたでしょうが、実体としてはJavaといえばServletという時代になっていたわけです。
企業で用いられる社内システムにもServletは多く採用されました。
理由はいろいろ挙げれると思うのですが
というのが大きな理由だろうと思います。JSPというテンプレートエンジンを用いてHTMLを整形してWebページを作り出す、というアーキテクチャはある意味では便利で簡単でした。
もっともHTMLの表現力に足を引きずられるため、GUIの機能性という点では後退したわけなのですが。それでもメリットが大きいと判断されたのでしょう。というか、まともにGUIを組めるプログラマがほとんどいないから、GUIのシステム開発がなかなか成功しないってのもあったんでしょうけどね。
2000年あたりというと携帯電話の普及も取り上げなければなりません。現代のスマホ、ガラケーに比べれば非常に機能は貧弱で、まさに携帯「電話」でした。要するに電話とメールぐらいしかできなかったんですね。
そこにdocomoのiアプリ、Jフォン(ボーダフォンを経て現ソフトバンク)のJavaアプリ、auのEZアプリという携帯電話上でちょっとしたアプリが動くよ！というのが乗るようになってきたんです。これがJavaを組込み用途にコンパクトにしたJava MEというものが土台となっていて(正確にはiアプリはちょっと違う)Servletと並ぶJava言語の大きなもうひとつの領域となっていました。
iアプリは当初は容量が10k byteまでといった制約があり、容量制限が非常に厳しかったのですが、新機種が出るたびに容量は緩和されていきました。
docomoはiアプリ含めiモードによって一世を風靡します。こうした土台を作ると、その上で商売をしたい人がたくさんやってきて、勝手にコンテンツを作ってくれる。docomoはそれらから手数料を取るので労せずして大金を稼げるというわけです。賭場の胴元というわけです。
この賭場が、将来にAppleのiPhone, GoogleのAndroidに荒らされることになります。docomoがなかなかiPhoneを出さなかったのもiモードという自前の賭場を失うことを良しとしなかったためです。金づるを失ったdocomoはSamsungと組んで独自の携帯向けOSであるTizenの開発に乗り出します。そんなTizenですが鳴かず飛ばず。噂ではインドあたりではリリースされたとか、なんとか。
話を2001年に戻しましょう。
Microsoft離反でGUIのプラットフォームとしてのJavaというものは存在感を弱めていました。この分野の復権に寄与したのはJava 1.4 (2002年2月6日)で導入されたJava Web Startです。
Java Appletがブラウザ埋め込みで動作したのに対し、Java Web Startではブラウザから起動しつつも独立したアプリとして起動するのです。
Webシステムが企業の社内システムに採用された話は先に述べたとおりですが、やはりWebシステムのGUIというのはHTMLに引きずられて貧弱だったんですね。
端的に言えば入力値が数字かどうか？みたいなチェックがなかなか難しい。HTML上でJavaScriptでやるわけなんですが、なかなか気持よく入力できるような感じにはならなかったんですね。
また、Ajaxによるブラウザのページ遷移を伴わない通信というのが出てきたのも2005年ぐらいなので、入力値に対してサーバ問い合わせするようなことはできなかった。当時だと一旦画面遷移させないとできなかったわけです。
こうした事情から、クライアントサイド、要するにPC側でもっとリッチなUIが使いたい！という要望があったわけです。Webシステム使いにくい！という不満の噴出と言ってもいい。そこで出てきたのがRIA (Rich Internet Applications)というわけです。
Javaは1.0時代のAppletからそうですが、ネットワークを介して別のPCにプログラムを送り込み、そこで動作させるという能力を持っていました。それこそまさにRIAに求められる機能性だったわけですね。
RIAの代表とされるのは
あたりです。三つ巴の戦い、どこに軍配が上がるのか！？と注目されましたが、勝利したのはHTML / JavaScriptでした。
Google MAP で注目を浴びたAjax技術、それまでブラウザでは不可能と思われていた高級なGUIをHTML / JavaScriptで実現させました。もうやめて欲しいですよね。せっかく脱ブラウザの流れが来たと思ったのにまたWebシステムに逆戻りですよ。
RIAが失速した理由として考慮して置かなければいけないのはスマートフォンの台頭です。RIAでは端末を選ばずどこでも同じアプリが動かせる点がポイントのひとつでしたが、スマートフォンではそうは行かない。"Write once, run anywhere"を破壊したのはスマートフォンだったというわけです。
しかし、先日インストールなしでアプリを実行するAndroid Instant Appsが発表されたりしまして、結局RIAの思想といいますか、要求というのは今でも息づいているのだなと思った次第です。
1.3 / 1.4 では機能追加はあっても言語構文が大きく変わることはありませんでした。大きく変わったのはJava 5です。この時からバージョニングが変わって1.5ではなく5と表記されるようになりました。
Java5の特徴はなんといってもジェネリクス。それまでjava.util.Listにデータを出し入れするのにはキャストが必須だったわけですが、ようやくキャストから開放され型の安全度がぐっと高まりました。その他に以下のような変更があります。
言語としては随分変わっったわけですが、もうかれこれ10年以上前のことですからこれらの機能が「Java5から導入された」という知識は今となってはあまり必要とされません。これらの機能が使えないJava 1.4で開発をする事案が殆ど無いからです。0ではないのが悲しいところではありますが。
Java 6 (2006年12月11日)がリリースされた後、Java 7 (2011年7月28日) が出るまでJavaは停滞してしまいます。その間にSun Microsystemsという会社がなくなってしまったためです。
Sun Microsystems の経営状況が悪化しており、ついに身売りをすることになりました。身売り先はIBMともGoogleとも噂されましたが結局2010年1月27日にオラクルに吸収合併されました。
Javaの停滞中にはJava VM上で動く非Java言語も台頭してきました。Scalaなどですね。
やや戻って2007年にAndroidが発表されます。Androidの開発言語にはJavaが採用されていますが、実行環境はJava VMではなく、ライセンス的な事情でJava(TM)は名乗らない微妙な位置関係にあります。
Java 5 以降で大きく言語仕様に手が入るのは Java 8 (2014年3月18日)です。並列処理を行うためのStream APIと、そのために簡易に関数を定義するためのラムダ式が導入された点が大きいですね。日付APIも刷新されました。
このように、Javaは1.1の黄金時代から今に至るまで利用ジャンルを転戦しながら産業の土台となって支えてきた歴史があります。ジャンルの趨勢により浮き沈みもあります。今後についても決して楽観視はできないでしょう。Javaを学ぶことはプログラミングを学ぶステップとしては意義はあると思いますが、Javaを学べばゴールというわけではありません。プログラム言語も次世代へと移りつつあります。業界動向には注視していきましょう。
好きに表記すればいいと思いつつも見ると内心もやもやしてしまう。
やっぱりJavaと表記してほしい。Java……かっこいいじゃん！
※ Javaだけだと馴染みのない人もいると思うので似たような例を挙げる。
× SKYPEアプリ ○ Skype × PHOTOSHOPソフト ○ Photoshop × YOUTUBEサービス ○ YouTube
大まかには次の二点だと思っている。
COBOL、LISP、ALGOL、FORTRAN、PL/I、APL、BASIC……
今はFORTRANも新しいFORTRANはFortranと名乗っているし、BASICもBASICの派生はVisual Basicなどと名乗っていたりする。
時代に逆行してJavaをJAVAと表記してしまうとJavaがあたかも古い言語であるかのような印象を与えることになる。
× JAVA ← 1960年代の言語ですか？ ○ Java ← 今時の言語っぽい！
「言語」という接尾辞をつけてしまうと二重敬語のようなまわりくどい印象を与えることになる。
Cのようにググラビリティが低いため止むを得ずC言語と表記するという場合もあるが、Javaならそういった問題は無い。
コンピュータ関係で他のJavaと衝突していないか？それは大丈夫だ。
https://ja.wikipedia.org/wiki/%e3%82%b8%e3%83%a3%e3%83%90
Scalaちゃんは今日も「余裕でした(´･_･`)ﾄﾞﾔｯ」とツイートするんだろうか。
IsNumeric Function (Visual Basic)
IsNumeric returns True if the data type of Expression is Boolean, Byte, Decimal, Double, Integer, Long, SByte, Short, Single, UInteger, ULong, or UShort, or an Object that contains one of those numeric types. It also returns True if Expression is a Char or String that can be successfully converted to a number.
ここは普通のことをいっている。 IsNumeric が True を返すのは以下のとき。
Indicates that no beginning value has been assigned to a Variant variable. An Empty variable is represented as 0 in a numeric context or a zero-length string ("") in a string context.
Empty は context にあわせて以下のように解釈される。
というわけで IsNumeric(Empty) は Empty が数値として解釈されて 0 になるので True を返す。
前いた会社を辞めた時に、部下がくれたアドバイスを思い出した。
同僚の三倍程度の仕事量をてきぱきとこなし、涼しい顔で毎日定時に帰っていく。上司の俺が何も指示していないときに、社内を歩きまわって、同僚や先輩に仕事を「お願い」していた。
けれども、そいつを悪く言うやつはいなかった。笑ったときのえくぼが印象深い奴だった。
経験だけはあったが、他にその役につく人間がいないという理由で、ロケット鉛筆のように押し出されてそのポジションに付いた。
かつて新人だった頃は、プログラマーとして四苦八苦しながら、作る喜びを糧にしていたものだった。
だが月日が経って、机の位置が変わった。プロジェクトを指揮するようになった。部下が増えた。いつしか俺はコードを離れ、代わりに人間を扱うようになっていた。
責任が増えると共に、やりがいも増えた。チームをまとめて、目標に向かっていく。自分一人ではできないことを、仲間たちと力を合わせて達成する。砂漠の中にピラミッドを建てるように。
プロジェクトを完遂すると、メンバーがガラリと変わった。力になってくれた仲間たちは、別のチームでその才能を発揮することになる。俺の元には営業がやってきて、新しいプロジェクトの発足を告げる。
程なくして新しいメンバーがやってくる。俺は別なチームとともに、別のピラミッドを建てるのだ。
そんなループを何度か繰り返したある日、プロジェクト終了直後の閑散とした社内を眺めて、缶コーヒー片手にボンヤリしている時に気がついた。
味がしない。缶コーヒー、ジョージア・エメラルドマウンテン・ブレンド（つめた〜い）の味がしない。
いやもちろん缶コーヒーなので、本来そんなに旨くない。街の喫茶店はおろか、スターバックスで女子高生がカップで飲んでるやつにも及ばない、いわゆる”コーヒー飲料”なのだが、初めの頃はうまかったのだ。
入社当時、Visual Basic の教本を片手にキーボードにしがみついていた時に机に並べていたエメラルドマウンテン・ブレンドは、もっとスカッとした味だった。
抜けた空のような味。
何かが違う。そう感じた。
iPodを作った天才、スティーブ・ジョブズはかつてこう言った。
私は毎日、自分に問いかけてきました。「もし今日が人生最後の日だとしたら、今からやろうとしていることをするだろうか」と。「違う」という答えが何日も続くようなら、何かを変えなければならない時期にきているということです。
一週間の後、俺は退路を歩むことを決めた。
退社まで残りひと月と迫って、引き継ぎが一段落したある週末に、俺は例の、できる部下と酒を飲むことになった。
そのときの部下は会社の期待のエースとして注目を集め、人より多くの責任と仕事を与えられていた。しかし本人はプレッシャーに怯むことはなく、むしろ水を得た魚のように、やる気に満ちていた。テカッテカだった。
酒の席に誘うと忙しいにもかかわらず、嬉しそうに快諾した。へんなやつだ。
その夜、俺は柄にもなく酔っぱらい、いつのまにか部下に向かってだらだらと仕事上の愚痴をこぼしつづける、情けない中年オヤジになっていた。
聞くと部下も結構酔っていると言ったが、俺は知っていた。こいつは顔は真っ赤になるが、それでいて実態は”ザル”だ。笑顔を崩さず、俺の話に機械的に相槌を打っている。
俺の話が一段落したときに、すべりこむように部下が横槍を入れた。「でもね上司さん。そういうのって上司さんが悪いんですよ。」
失礼ですけど。
顔を上げて確認すると、部下は笑顔の目元に困ったような表情を乗せていた。俺が息を呑むと、覚悟を決めたように、話を続けた。
何から何まで自分のアタマで考えないと気が済まない、そんなタイプの人間がまれにいます（ご指摘の通り、俺がそうだ）。
確かに、自分のアタマで考えるということは、ものすごく気持ちがいいですよね。なにかすごく『意味のあることをした感覚』を得られます。
最高責任者とか芸術家とかでない限り、自分のアタマで考えたことは「誰かに説明して納得してもらう」というフェーズが必要です。
相手が上司さんの上司さんであるなら、例えば説得はこんなふうに行われます…
お偉いさんの元を尋ねて、現状の問題を分析するとこういう構造になってて、どこがどう問題と考えられるので、このようにやりかたを変えれば、このくらいよいことが起こるでしょう、みたいなのを説明して、話の前提をちゃんと共有しないと理屈が通らないから、考えに至る前提条件とかを事細かに説明して、相手との認識が合わなかったら合うように、考え方の違いに注意しながら調整して、ようやく自分のアタマで考えたこと、を分かってもらえたら次は、それって絶対・100%・間違ってたら責任取るの？ とか聞かれます、でもそんなん100％なんて世の中にありえないだろ、と思っても言い出したのは自分だし、時間をかけて分かっていただいた手前もあるし、それら有象無象を踏まえて相手のプライドを考慮しつつ、こちらの責任が大きくなりすぎないように、うまく首を縦に振ってもらうように、知略の限りを尽くして言いくるめるんです。
一方で、去年と同じで行きましょう、ならサラッと通ります。
競合他社と同じ戦略で行きましょう、偉い人の方針をまるごと継承しましょう、とかでも。
冷静に、比べてみてください。自分のアタマで考えた場合のコスト。
説明のために、ものすごいコストや苦労をかけてストレスをためこみ、結果自分の責任が増しただけ。
自分のアタマで考えようとして、なんにも結論が導き出せなくなることがあります。
どの因子がどう関わってるのか整理しきれない。どこの範囲まで前提として考慮に入れるべきかがわからない。「Aと言う視点なら正しいとも言えるし、Bという視点なら間違いとも言える」みたいな項目ばかり。
なにを考えても「他人が出した別案」に引っ張られる。なんとかごまかしつつ、ちょっと甘いかな、って思いながら考察した結論を他人に見せる。でも、アタマの鋭い人はどこでもいるもので。
ピンポイントでその弱いところを突かれちゃったりする。自分でも「俺バカなのかな」と薄々感づいてる点を、改めて他人にも認識させられることになります。痛恨の一撃です。大ダメージです。
ゼロから考え直すなら、誰だって結論を間違えたり、推論を見失ったりすることがありえるんですけど、『自分のアタマで考えている俺』に酔っていると、そういう基本的なことは、忘れちゃうんです。
根拠のない自信を持ってる人ほどひどい結果になりがちです。
「自分は天才とまでは言わないけども、周囲の中でまあまあ使える、ほうだし、今は流されてるけど、本気出せば自分で考えて結論出すようなこともできるもんね！」
そんな自信は崩れ去ります。
失った自信を取り戻すのには、より多くの時間が必要です…。ご年配の方ほど、必要な苦労は過酷なものになるでしょう。
その仕事が得意な人、エキスパートに全部お任せする、というのでも。
挫折が無ければ、その間仕事ができた。挫折があるから、周辺分野へ再び手を伸ばすことが、おっくうになった。
例えば、さっきお酒持ってきてくれたの店員さん。カウンターで寂しそうにひとりで飲んでるオジサン。自分のアタマで考えているように見えますか？
たいていの人たちは、流されています。考えが浅いし、近視眼的です。リスク管理の面から見ても、脆弱です。
でも、その人たちって、不幸ですか？
かなり幸せそうじゃない？ 自分はすごいという自信のもとに楽しく過ごし、うまくいかなかったことは運が悪かった、また次があるさ、と片付けてポジティブに生きてる。掘り込んだ原因分析なんてしないで、場当たりに生きてる。若者から人生訓を聞かれたら嬉々として語っちゃう、的な幸せさに溢れてるw
偉そうにｗ 生意気言うやつだなｗ とその晩は軽くたしなめて別れたけど、
よくよく思い返すといい話ではあった。なんだか、ずっと温めていた感もあるし。
俺は今まで、自分のアタマで考えてきた。それを誇りにしていたというほどではないけど、出来る限り自分でやってみる、が俺のモットーだった。
けれども、それで、何が残っただろうか。
すり減ったり、焦ったり、自己嫌悪に陥ったり。紆余曲折を経て、何が残ったのか。
ひょっとすると、俺は自分の人生の将来や、手に入れられる幸福や可能性から、目を逸らしていたかっただけなんじゃないか。
実感を求めて効率を犠牲にする。それで誰かの足を引っ張る。あるいは、身の程をわきまえて、歯車として、自分に与えられた役割を果たす。その分岐路で立ち尽くしている。アタマで考えても前に進めない。思考停止すれば進める。『結果』を手に入れる。上手く行けば成功できるかもしれない。彼女のように。慣性は惰性だ。だから、プライドは捨てる。直感は捨てる。生き方を変える。
(以上。なんかディティール盛り過ぎてる感があるけど、部下の言いたかった、本筋のところは外していない？)
-----------------------------------------------------------------------------------------------------
後書き：
id:uxlayman さんの元エントリ、分析エントリです。
俺の考えでは、元となるアイデアが良ければ、読みやすくするためにストーリーを与えて、読んでて途中で躓かないように、注意深く、入念に推敲すれば、ある程度伸びます（俺はこの文章の推敲に６時間かけました。ヒマスギシヌ）。
コアとなるアイデアはなんでもいいわけではないようです。というのも、同じようなストーリーで同じような語り口の記事を過去に書いたことがあるんですけど、そっちは全然伸びませんでした。
追記 (7/30 1:35時点)：
頂いたコメントより
ネットを一切見ないで Visual Studioと マニュアル 参考書だけで 基本的なテトリスを作れるかどうか？ ８時間以内
とかでいんじゃね？
隔離した部屋で やれば できるやつは簡単にできるし
できない奴は １日かけてもできないだろ
別に ブラウザのみとかVisual Basicのみとかでもいいけど、言語はなんでもいい。 ネットを見ないでテトリスが作れないなら、採用しない方がいい。
ぷよぷよは難しいけど テトリスは簡単に作れる。グラも四角形だけでいけるから簡単
あとは出来上がるまでの時間とか作りこみ （移動とか回転とかブロックの色とか、次のブロックとか 対戦まで作るか？とか）で評価を上げていけばいい
大学時代の俺で初めて触るX11の練習として授業中にこっそり作って、（当時今みたいなネットはなかった）最小限のテトリスで２－３時間ぐらいだったはず。
そのレベルで 初級ぐらいだとおもう。 ただ 今はもう年齢が高いからな速く作るのは逆に難しいから 年齢は考慮してほしいな。
Visual Basic 2010 Expressでプロジェクトを発行すると以下の様なエラーが出ます xxxはユーザー名の置き換えです
プロジェクトの新規作成から作った初期状態のプロジェクトを発行しても同じエラーが出ます
エラー 1 プロジェクトがビルドできなかったため、発行できません。
警告 2 項目 '.NETFramework,Version=v4.0,Profile=Client' が 'C:\Users\xxx\documents\visual studio 2010\Projects\WindowsApplication1\WindowsApplication1' で見つかりませんでした。
警告 3 項目 'Microsoft.Windows.Installer.3.1' が 'C:\Users\xxx\documents\visual studio 2010\Projects\WindowsApplication1\WindowsApplication1' で見つかりませんでした。
エラー 4 必要なファイル 'setup.bin' が 'C:\Users\xxx\documents\visual studio 2010\Projects\WindowsApplication1\WindowsApplication1\Engine' で見つかりませんでした。 WindowsApplication1
C:\Program Files\Microsoft SDKs\Windows\v7.0A\Bootstrapper\Engine\setup.binをC:\Users\xxx\documents\visual studio 2010\Projects\WindowsApplication1\WindowsApplication1\Engineにコピーするとエラー4がこのように変わります
エラー 4 ブートストラップをビルドするために利用可能なリソースがありません。 WindowsApplication1
Visual Studioを修復したりMicrosoft SDKをインストールしたりしましたが、解決しませんでした。
どうしたらよいでしょうか。
C:\Program Files\Microsoft SDKs\Windows\v7.0A\Bootstrapper\Engine\setup.binをC:\Users\xxx\documents\visual studio 2010\Projects\WindowsApplication1\WindowsApplication1\Engineにコピー
更に
C:\Program Files\Microsoft SDKs\Windows\v7.0A\Bootstrapper\Engine\jaをC:\Users\xxx\documents\visual studio 2010\Projects\WindowsApplication1\WindowsApplication1\Engineにコピーしたら発行できました
参照URL
http://msdn.microsoft.com/ja-jp/library/ms228158%28v=vs.90%29.aspx
