mySQLにUTF-8で漢字を入れて、中身見れるんだ！CSEだと！！

つみきのCSEを、ODBC経由でつなぐと・・・

ここのブログ

MySQL 5.0にCSEで接続する方法
http://d.hatena.ne.jp/trench/20070426/1177563411

にかいてあるとおりに、

（１）MySQL Connector/ODBCを使って、
（２）コマンドラインから、odbcad32を実行
　　　開いたら、そこにあるように設定する。
（３）my.cnfを書く（と、短縮電話アイコンになったけど無視）
（４）CSEで、設定すると・・・

すげー（＠＿＠！）見えたよ・・・

このエントリ、書いた人、偉大！

オブジェクト指向で開発の最初から最後までの手順例－その１６：アクティビティ図を再度作る

　オブジェクト指向でやる場合の最初から最後までの流れを、実際の例を挙げて書いていくシリーズ「オブジェクト指向で開発の最初から最後までの手順例」、ここの順番でいくと、今回は、「（５－２）プロセス解析ルート」の「（５－２－２）今回コンピューター化した場合の業務の流れをアクティビティ図に書く」です。

---

■AsIsモデルとToBeモデル

　アクティビティ図は、すでに、（５－２－１）で作っています。
　しかし、このときの図は、現状の機能の様子です。
　これを、AsIsモデルといいます。

　この現状のモデルの中から、なにをコンピューター化していくかということを、（５－２－２）でまとめ、ユースケース図にしたわけです。
　この、コンピューター化する段階で、一部の機能は、コンピューター化去れたものに置き換わったり、一部の機能が追加されたり、省略されたりします。

　そこで、そのコンピューター化されたときに、新しい（コンピューター化された）機能で、どのように、業務を進め、その業務を進めるときにあたって、入出力のもれはないかを確認する作業がここになります。
　そして、ここの「コンピューター化された新しいモデル」がToBeモデルになります。

---

■といっても作業は・・・

　基本的には、（５－２－１）と同じです。（５－２－２）で出てきたユースケースをアクティビティとして、そのアクティビティを行う人のところに書いていきます。

　ただし、追加の作業として、アクティビティの入出力に対して、ER図に出てきているデータでちゃんとできるか、漏れがないかをかくにんしながらやると、いいかもしれません（ってことは、CRUDとか作りながらやったほうがいいのかな）

---

■でも、今回は・・・

こんかいは、（５－２－１）のときから、かわりようがなく（＾＾；）

・発注者は、受注者に、商品を発注する
・発注者は、発注を確認する
・発注者は、発注を編集する

　です。ただし、これ以外にも、発注企業（＋部署、店舗、納品先）、受注企業、商品などのマスタの作成、編集、参照（検索）削除という作業があり、コンピューター化にともなう発生業務すべてというのであれば、それも書くことになりますが。。。

　とくに、マスタ関係のデータの発生に関しては、かくにんしておいたほうがいいかも？（商品登録等は、電文が来て自動敵にというケースもある）

---

■ToBeモデルのアクティビティ図に文章を補うと。。
　逆に、ここで書いたアクティビティ図、ToBeモデルのアクティビティ図とよびましょうか、それを

　「スイムレーンの人」が、
　「アクティビティの入出力」を、
　「アクティビティ」する

　というかたちで単文にまとめていくと（あと「何々のとき」という条件とかもかきますが）、ユースケースシナリオとなります。

　お客さんとは、このシナリオベースで確認したほうが、わかりやすいかもね。。

---

　ということで、今回の、ToBeモデルのアクティビティ図を作る話はおしまい。

テーブルで、名称から一意になる場合のIDについて

　テーブルを設計するとき、名称だけで、すでに一意になる場合がある
　たとえば、会社の場合、部名と課名をあわせると一意になるときがある
（って、ならないと困るよ！違う部で同じ課名はOKだけど、同じ部で、同じ課の名前で、実態が違うって言ったら、わかんなくなってしまう（＞＿＜！）


　このような場合、IDを振らなくても、名称を主キーにするケースがある
　（もちろん、同姓同名が合ったり、課名変更があるので、主キーにしたくないというケースがあるのは別。そうではなく、まず、名称が、そう変わる危険もない場合。種別コードなどで、特にありえる）。

　上記のケースにおいては、正規形の立場をとれば、IDと名称は、従属関係になるので、IDはいらないということになる。
　そこで、このとき、IDをもつことの有利不利について、ちょっとまとめ。

---

■IDを振ったほうがいい理由

・ハッシュテーブルのとき、連番のほうが、きれいに散る

　ハッシュキーを計算式で求める場合、キーが一様のほうがきれいに散る（シノニムが出来にくい）が、名称だと、そーいかないかも・・・


・文字列を検索することになる
　それって、おそくない？

---

■IDを振らないほうがいい理由

・JOINが多くなる。
　ユーザーにIDを見せるわけにはいかない場合、名称を入力することになる。
　その場合、たとえば、部、課、係とあったとき、
　部名、課名、係名を入力してもらったら、

　もし、IDを振らず、名称がキーなら、係名テーブルを検索するだけでOK
　（部名、課名は、係名テーブルの外部キーとして入っている）

　それに対し、IDを振った場合、部名テーブル、課名テーブル、係名テーブルをJOINし、そのテーブルから検索することになる。
　このように、JOINが増える危険がある（実務上、JOIN数には限度がある）

---

ふとおもいついたのは、こんなかんじかな・・

オブジェクト指向で開発の最初から最後までの手順例－その１５：ユースケース図をつくる

オブジェクト指向でやる場合の最初から最後までの流れを、実際の例を挙げて書いていくシリーズ「オブジェクト指向で開発の最初から最後までの手順例」、ここの順番でいくと、今回は、「（５－２）プロセス解析ルート」の「（５－２－２）ユースケース図にまとめる」です。

---

■アクティビティ図からユースケース図へ

　アクティビティ図におけるアクティビティのうち、コンピューター化するアクティビティをユースケースとしてとりあげます。

　そのユースケースに対して、入出力があるわけですが、その入出力が、外部からくる場合、アクターになります。入出力は実際にはデータなわけなのですが、データそのものではなく、データを入力する人（コンピューターの場合もあるけけど）、データを受け取る人をアクターとして、人の形で書きます。

---

■今回の場合

　ユースケースは、

　　　発注する
　　　編集する
　　　確認する

　で、「発注する」のアクターは発注者と受注者
　「編集する」、「確認する」のアクターは発注者
　です。

---

■ただし、この場合も・・・

　アクティビティ図のところに書いたように、この業務以外にも、マスタの作成として、事前にやっておかないといけないことがあります。
　つまり、発注企業（＋部署、店舗、納品先）、受注企業、商品などのマスタの作成、編集、参照（検索）削除。

　これを、ユースケース図に含めるかどうかは別として、システムとしては、つくらないといけません。

---

　ということで、簡単ですけど、ユースケース図もおわりにします。

悲しいときー。サーブレットからXMLを書いてもブラウザにすら何も表示されないときー。。

　クライアントがAJAXで、サーバーをサーブレットでやろうとしたとき、どーしても、XMLHttpRequestで受け取った結果を、responseXMLでうけとると、firstChildですらNULLになる（responseXMLの結果自体は、入ってくる）。

　で、ブラウザで、そのサーブレットのURLを打っても、帰ってこない（前の画面のまま。ちゃんと帰ってくればXMLの構造が表示されるはず・・・）


ということに、ある人がはまりました（ウィリアムのいたずらではない、他の人）

おかしい・・・

悩みました・・・

答え：

UTF-8でXMLで書いているので、出力する前に、
response.setContentType("text/xml; charset=utf-8");

とすべきところを
response.setContentType("text/html; charset=Shift_JIS");

と、HTMLでシフトJISと送っていた。。


　ごめんよお（＞＿＜！）
　たしかに、まず、JavaでHello World の サーブレット (Servlet)編で、Hello Worldをだして、そのあと、出力部分をXMLに変えてね！っいったけど・・・

写真やWikipediaを連想検索 富士フイルムがラボ開設、API公開

メモメモ
ここのニュース
写真やWikipediaを連想検索　富士フイルムがラボ開設、API公開
http://www.itmedia.co.jp/news/articles/0707/24/news078.html
によると（以下斜体は上記サイトより引用）


富士フイルムが、自社ソフト技術を公開するラボサイトを開設。第1弾として、シソーラス辞書をもとにタグ情報から画像を検索するエンジンのAPIを公開。デモアプリでは、Flickrの写真とWikipediaの記事を連想的・直感的に検索できる。



で、そのフジフィルムのラボサイトは、以下のとおり。
FUJIFILM Internet Technology Labsについて
http://www.fujifilm.co.jp/corporate/tech/itlabs/index.html

そこから、そのAPI,TRIPITにいける。

情報大航海プロジェクト・コンソーシアムのリンク先にいって、遭難してしまった（＞＿＜！）

日本経済新聞の今日（７／２４）の１面に、

日立　類似画像、検索速度２０倍に

　という記事がある。どうやら、保存時に、画像の特徴量をだし、類似しているデータごとにグループ分けしておき、そこから検索するらしい。

　そーいえば、たしか（これは、特許になっていた気がしたけど）画像特徴量を遺伝子化する（各種の特徴点を、遺伝子のようにつなぎ合わせるのだと思う）というのがあったと思うけど、あれを保存時にやれば。。。

あれって、情報大航海かなんかで、やってなかったっけ？

とおもって、（ここからが本題）

情報大航海プロジェクト・コンソーシアム
http://www.meti.go.jp/policy/it_policy/daikoukai/index.html#02

から、下の

情報大航海プロジェクト・コンソーシアムのページ
http://www.jyouhoudaikoukai-consortium.jp/

にいったら・・・



このサーバは、さくらのレンタルサーバで提供されています。

---

月額換算125円/300M～！
お試し期間2週間！

ジュース１本分のリーズナブル価格。大容量な共用レンタルサーバサービスです。さくらのサブドメイン2つ＋お客様の独自ドメインどちらも使えて、サーバの管理は楽々、さくらまかせ。また、さくらのドメイン取得代行サービスと併せてご利用いただくと、月額換算275円～で独自ドメインプランが可能！簡単。便利。高機能。そして安定しています。趣味で、ビジネスで。いろんなニーズで使って欲しいサービスです。



おお、情報大航海がレンタルサーバー、
じゃなくって、あれあれ・・・さくらレンタルサーバーのページにいっちゃうけど。。。？？

情報大航海プロジェクトは、どこにいったのお・・
と、（航海せずに）遭難しているのは、ウィリアムのいたずらだけ？？
（どこにいったんだろう　（－＿－；）

オブジェクト指向で開発の最初から最後までの手順例－その１４：アクティビティ図をつくる

　オブジェクト指向でやる場合の最初から最後までの流れを、実際の例を挙げて書いていくシリーズ「オブジェクト指向で開発の最初から最後までの手順例」、前回までで、ここの順番の 「（５－１）データ解析ルート」が終わったので、今回は、「（５－２）プロセス解析ルート」の「（５－２－１）アクティビティ図をつくる」です。

---

■アクティビティ図

　アクティビティ図は、UMLの図の１つで、業務として行うこと（アクティビティ）を、その担当者のところ（スイムレーン）に書き、順番をテキトーに（いや、適切に）線で結ぶものです・・

・・・いい加減な説明ですが（＾＾；）

---

■要求文から、アクティビティ図に

　で、もう、はるか昔のコトなのですが、

（４）動詞から、
　　　（どういうときに）誰が、何を、どうするという
　　　単文にまとめる

ということをしました。

　このなかで、「どうする」というのが、アクティビティ、
　「誰が」が、スイムレーンになります。

なので、

（１）「誰が」という主語の分だけ、桁をつくる（スイムレーンを作る）
（２）そこに順番に、「どうする」を楕円で書き（アクティビティ）
（３）それをつながりがある場合、線で結ぶ。
　　　誰から誰へというところは、担当者間で横に線が引かれる（はず）
　　　並行処理とかは（二本線で間に書くんだけど）アクティビティ図の
　　　書き方に従ってください。

---

■今回の場合・・・

　今回の場合は、

・発注者は、受注者に、商品を発注する
・発注者は、発注を確認する
・発注者は、発注を編集する


なのですが、これらは、それぞれ独立していることなので、
ひとつアクティビティを書いて終わり。。。
になってしまいます（＞＿＜！）

ちなみに書く場合、スイムレーンは発注者のところに書きます。

---

■業務以外のアクティビティ

　しかし、「データ解析ルート」で出てきたように、業務に関係しない内容（＝マスタデータをあらかじめ作るなど）でも、やらないといけないことがあります。

　今回の場合、発注企業（＋部署、店舗、納品先）、受注企業、商品などのマスタを作らないといけません。

　それを、アクティビティ図に描くかどうかは別として、機能にあるということは、意識しないといけません。

---

ということで、次回は、「ユースケース図にまとめる」話です。

AJAXでアジャイルで開発する手順例

　新人の人で、画面のレイアウトはあるんですけど、この後どうやってやったらいいんだかわかんないんですう（＞＿＜！）という人のために。

　かりに、AJAXで、アジャイルっぽくやるとすると。。

（１）とりあえず、画面をHTMLでつくれ。

（２）できたら、イベントがおこるところ（ボタンをクリックするか、
　　　リストボックスが切り替わったところ、初期画面表示（BODY のonLoad)
　　　は、Javascriptの関数をよぶから、そこの関数を適当に作れ
　　　　　→中身は、からでOK,メッセージをだしてもいい。
　　　　　→イベントが起きるところは、たいてい指示が書いてある

（３）関数から、サーバーアクセスするところについて、
　　　（サーバーからデータをとってくるところ）
　　　サーバーアクセスの方法は、どっかから拾ってきてくれ。
　　　→このブログにも確かある。
　　　ダミーのサーブレットをつくる（中身の処理は固定値を返す程度でよい）

（４）もし、DBアクセスが自動化されてないなら、
　　　DBアクセスのところを、ダミー関数をつくって、（３）の関数から
　　　適当に呼び出せ。

（５）仕様書にもとづき、コメントで、
　　　　（２）の関数、
　　　　（３）のサーブレット
　　　　（４）のDBアクセス
　　　のところの処理をかけ。

（６）あとは、（５）のコメントが成立するように、外側（javascript側）
　　　から、順に考えるが、AJAXの場合、WebAPIがしっかりしていたほうが
　　　楽というなら、サーブレットから考えろ
　　　　　→というか、すきなところからやれ。

（７）全部コメントに対するソースが埋まったら、できあがりのはず

　　・・だ（＾＾；）

AJAXでやると、アジャイルっぽい場合、便利な方法があるかも。。。

　ふと思うに・・

　いま、テスト的にプログラムをつくるとして、トランザクションは考えないものとする。

　そうすると、画面側でAJAXでプログラムを組もうと、サーバー側でプログラムを組もうと、自由だ（このとき、デモ用で、速度も考えないとする）。

　そうなれば、サーバー側は、DB操作、すなわち、INDERT,DELETE,UPDATE,SELECT機能を提供すればいい。

　これらのWebAPIを用意しておけば、あとは、クライアント側で、WebAPIを使って操作できる（富士通なひとへ、CBMをサーバー側におき、CBSをクライアント側において、CBMとCBS通信をネットワークを使って行っている。原理的にこれは出来るようになっているはず）。

---

　DB操作の、INDERT,DELETE,UPDATE,SELECT機能をWebAPIで提供することは、自動生成で対応可能であるので、すぐにつくれる（テーブル構造が決まれば）。

　そうすると、

・AJAXで、WebAPIを操作し、まずクライアント側で動作を確認しながら、
・これでよし！となったら、AJAXをサーバー側のサーブレットとして
　その機能を書き換え、サービスにして
　　　→この段階でトランザクションを考えて
・そのサービスを呼ぶように書き換える

とすると、アジャイルっぽく、すぐに開発して試しながらできるよね。

Cookieに大量データを入れるよりＡＪＡＸ？

画面が切り替わる際に、切り替わった画面にも、データを引き継がせたい場合、
Cookieに入れるという手もあるけど、
大量データで、構造がある場合なんか、結構めんどっちいい

・画面が切り替わる前に、ＡＪＡＸで、サーバー側に、保存したい値を渡して、
・サーバー側では、その値をセッションに保存して、
・画面が切り替わった後、ＡＪＡＸで、保存してあるセッションの値をＸＭＬの返り値
　として受け取ると


便利？？
ただし、これは、社内のＷｅｂＡＰＩ（イントラネット、古い言い方では）の話で、
２回サーバーアクセスが入るから、そっちを嫌うケースも多いかも。。

Hello World程度のデータベース（その２９：ＪＤＢＣ）

情報処理とは何から、データベースの基本的な話(情報処理試験のデータベーススペシャリスト程度の話まで）を書く、土日のシリーズ「Hello World程度のデータベース」です。

　いままで、三層スキーマ構造により、データベースを説明してきた後に、前回は、データベース側のデーモンについて説明し、データベースと、外部プログラムとのつなぎ部分について説明しました。

　今回は、プログラム側から呼び出され、そのデータベースのデーモンと通信する機能をもつものについてです。これには、ＯＤＢＣやＪＤＢＣなどありますが、ここでは、Ｊａｖａのクラスとして提供され、データベースのデーモンと通信する、ＪＤＢＣについて説明します。

---

■ＪＤＢＣとは、

　ＪＤＢＣは、Ｊａｖａのクラスとして提供され、データベースとアクセスしたい場合、このＪａｖａのクラスを決まった手順で呼び出すと、このＪＤＢＣが、前回説明したデータベースのデーモン(mysqldなど）とソケット間通信をして、処理を指示し、結果を受け取ります。デーモンから受け取った結果をＪＤＢＣは、プログラム側に返します。

　データベースのデーモンは、データベースごとに違うため、ＪＤＢＣも、そのデータベース用のものがあります。
　たとえば、ＭｙＳＱＬのＪＤＢＣドライバは、Connector/J、PostgresSQLのＪＤＢＣは、PostgreSQL JDBC Driverなどなどです。

---

■ＪＤＢＣの呼出し手順

　で、上記に書いた「決まった手順で呼び出すと」について。
　どのような手順で呼び出すと、接続できるかですが・・・

	// ドライバクラスをロード
      	Class.forName("org.gjt.mm.mysql.Driver");

	// データベースへ接続
	String url = "jdbc:mysql:///dbname?useUnicode=true";
	Connection con = DriverManager.getConnection(url);

	// ステートメントを作成して
	Statement stmt = con.createStatement();
	String sql = "SELECT * FROM TBL_A";

	// クエリーを実行して結果セットを取得
	ResultSet rs = stmt.executeQuery(sql);

のように指定します
DriverManager.getConnection(url);はＵＲＬしか指定してませんけど、ここにユーザー名、パスワードを指定する場合もあります（っていうか、そっちのほうが多いと思いますけど）

で、なんでこういう呼び出しになるのかなど、詳しいことは、以前、

JDBCのプログラムとその動作の関連、これで合ってるのかな？
http://blog.goo.ne.jp/xmldtp/e/ec7b03f6cc66d4b725a03ebb086e85b4

で、書いたので、そっちを参照してください。

---

　で、このとき、２つ以上の関連するテーブル、たとえば、受注明細と受注テーブルにデータを追加するとき、受注だけ追加して、受注明細を追加しないとかすると、おかしな話になってしまうので、両方のテーブルを同時に更新する、もし更新できないときは、同時に取りやめるというトランザクションという概念があります。

　次回は、そのトランザクションについて、ＪＤＢＣでの操作について書きます。

８０年代ゲームの変遷

で、さっき引用した
「アソコン　すうぱあスペシャル　８　パソコンゲーム８０年代記」

の目次に、「メモリアルコレクション８０～８９」ということで、その年にはやった、パソコンゲームがのっているので、以下引用してみます
（以下の斜体は、上記本より引用、ただし、目次なので、その記事が書いてあるページ数が入っているのだけど、それは省略、多少見やすいレイアウトにしてあります。「その他」は省略）



＜＜～８２年＞＞
・スタートレック
・スター・ブレイザー
・オリオン
・ミステリーハウス

＜＜８３年＞＞
・信長の野望
・ザ・ブラックオニキス
・ロードランナー

＜＜８４年＞＞
・ハイドライド
・ドラゴンスレイヤー
・デゼニランド
・サラダの国のトマト姫
・オホーツクに消ゆ
・ウィングマン

＜＜８５年＞＞
・大戦略
・三国志
・ザナドゥ
・テグザー
・ザ・キャッスル

＜＜８６年＞＞
・殺人倶楽部
・マンハッタン・レクイエム
・イース
・ロマンシア
・Ａ列車で行こう
・レリクス
・覇邪の封印

＜＜８７年＞＞
・ソーサリアン
・ディーヴァ
・ぎゅわんぶらあ自己中心派
・Ｆ１スピリット
・抜忍伝説

＜＜８８年＞＞
・シルバーゴースト
・ラスト・ハルマゲドン
・テトリス
・ディガンの魔石
・太平洋の嵐

＜＜８９年＞＞
・遥かなるオーガスタ
・Ｍｉｓｔｙ
・ＤＣコネクション
・水滸伝
・ＨＡＲＵＫＡ
・提督の決断



ってなかんじでした。その本では・・・

うーん、ウィリアムのいたずらは、余りゲームには詳しくないので、
半分（以上）も、わからない（＾＾；）

失われた２０年－ソフト業界は変わったのか？ その２：第三次オンが終わったころ（２）

２０年位前、１９８０年代終わりごろから、最近まで、ソフト業界とかその周辺の変遷について、特にソフト開発の立場を中心に見て行く、新しい土日シリーズ「失われた２０年－ソフト業界は変わったのか？」その第二回目。
　前回は、第三次オンが終わったころ（１９８０年代後半）の概要を書きました。
　今回は、そのころのハード面について書きたいと思います。

---

■汎用機とオフコン・ワークステーションとパソコン

　８０年代は、だいたい、

　・汎用機
　・オフコン・ワークステーション
　・パソコン

　の３つに分かれていたと思います。

　汎用機は、大きな事務処理、科学計算の中心であり、ＣＯＢＯＬ，ＦＯＲＴＲＡＮ，ＰＬ／Ｉでかいて、それを、フロッピーにかいて、汎用機に読み込ませて、ＪＣＬを実行し、プログラムを処理するという形。

　オンライン処理の場合は、ダム端（表示、入力だけする。Ｘ端末みたいなもん）っていうのがあって、そいつから入出力を行うという形でした。

　通信体系として、ＳＮＡ（ＩＢＭ）や、ＡＩＭ（富士通）などがあり、ＨＤＬＣ伝送制御手順などを使って通信していたと思います。
　ＨＤＬＣは、ＴＣＰ／ＩＰが入る前は、結構使われていて、印刷関係などだと、新聞社とかでつかわれてました（いまは、さすがにＴＣＰ／ＩＰかな。昔のＴＣＰ／ＩＰは優先制御とかができないので、記事送信の優先順位を求められる新聞社に向いているとはいえなかった）。

---

■オフコン

　そして、ちょっとした会社に入っていたのが、オフコン。
　オフィスコンピューターというもので、中堅企業（中小の一部も）なんかに導入された。
　ちょっとした受発注業務には十分な性能なのですが、お金のかけ方によって、ＯＳの使いやすさとかが、ぜんぜん違ってしまう。
　富士通のＫシリーズ（ＯＳはＣＳＰという独自ＯＳ）は、まあ、その中でも、使いやすかったんじゃないかな？

　オフコンは、事務用では良く使われたけど、科学計算用には、ワークステーション。
　とくに、ＰＤＰ－１１（Wikipediaでは、ミニコンになってるけど）が有名。
　たしか、歌手の杉真理（すぎまさみち：男）が、大学の試験で、「ＰＤＰ－１１の割り込みについて答えよ」という問題で、「割り込みは良くない！」と答えをかいたんじゃなかったっけ？？（記憶違いだったらごめんなさい　＾＾；）

　でも、ワークステーションで有名なのは、やっぱ、ＳＯＮＹのＮＥＷＳなわけで、印刷業関係の人だと、ＥＤＩＡＮやニューズキャスター（つづりをわすれた　＾＾；）が載っていたワークステーションとして有名ですよね。
　ＥＤＩＡＮから、写研文化とは、別ルートの編集文化がおき、それにはじめ、Ｔｏｏ（いづみや）は、載ってきたが、その後、Ｑｕａｒｋ、ＡｄｏｂｅＰｈｏｔｏＳｈｏｐに乗り代わり（この背景として、スピードライマーカーを納入して、広告代理店と関係の深かったＴｏｏが、（当時はいづみやか？）国際的な同時広告の入稿データとして、ＰｈｏｔｏＳｈｏｐデータを扱う広告代理店が増えだし、そのニーズに対応するためＰｈｏｔｏＳｈｏｐを扱うようになり。。。というのを、なにかで読んだ気がしたが、気のせいかもしれん。勘違いだったらごめん　＾＾；）。。。

　ってなわけで、今後のＭａｃ文化につながっていくのだが、その前の話として、ＮＥＷＳ文化があった。

　なお、Ｓｕｎであるが、当時はＳｕｎは、富士通、東芝が、売っていた。
　（Ｓｕｎ自体の直売より、富士通Ｓシリーズのほうが売れていた記憶がある。。これも、記憶違いだったらごめん。また、時代によって違う。あくまでも、８０年代ころの話）

---

■ＰＣ－９８０１とＦＭ－ＴＯＷＮＳ

　パソコンに関して言うと、

「アソコンすうぱあスペシャル　８
パソコンゲーム８０年代記」
という本をみると（１０～１３ページ）、

１９８２年　ＰＣ－９８０１発売
１９８３年　ファミコン発売
１９８５年　ＰＣ９８０１　ＶＦ，ＶＭ発売
　　　　　　ＰＣ－９８ＬＴ（ラップトップ）発売　
１９８６年　一太郎発売
１９８７年　ＰＣ９８０１ＸＬ発売＝＞対抗機富士通ＦＭ－Ｒ発売
　　　　　　エプソン９８０１互換機ＰＣ－２８６発売
　　　　　　東芝ラップトップＪ－３１００発売
１９８９年　富士通ＦＭ－ＴＯＷＮＳを発売

とこんなかんじ。。。

　８０年代、９０年代初めはＮＥＣのＰＣ９８０１シリーズの時代といえます。
　９８には、Ｎ８８Ｂａｓｉｃが載ってますけど、それをそのまま使ってＢＡＳＩＣをやるというよりかは、ＭＳ－ＤＯＳ，ＤＲ－ＤＯＳを使って、その上でコンパイラ（Ｆ７７ＦｏｒｔｒａｎやＣＯＢＯＬコンパイラがあった）を動かしていた。
　当時は、５インチＣＤの時代。
（１Ｓとかあったし。＝＞１Ｓ，２Ｄ，２ＤＤ，２ＨＤと容量が大きくなる）

　８０年代後半より、マルチメディアという言葉が流行り、それとともに、ＦＭ－ＴＯＷＮＳが出てきたわけだが（すごい宣伝したのだが）結果は・・・（＾＾；）

　ちなみに、上記には、一太郎しかないが、このころのワープロというと、管理工学の松も有名（というか、新松が有名）で、その管理工学がだした、パーソナルデータベースソフト？桐が、１９８８年ごろだと思う。有名になった。表計算ソフトとしては、Ｌｏｔｕｓ１２３ですね。

---

　ということで、次回は、ソフトや言語のほうの話です。

　

IEで、どうしても、ページがキャッシュされる・・マイクロソフトの回答は。。。

うーん、IEで、ページがキャッシュされるよお・・・
FireFoxでは、OKなのにい・・・

＜meta http-equiv="Cache-Control" content="no-cache" /＞
じゃ、いけないのかな（＜＞は、実際には半角）

＜META HTTP-EQUIV="PRAGMA" CONTENT="NO-CACHE"＞

でないと・・・

と思ってみてみたら、こんなページを発見！


"Pragma: No-cache" タグを使用してもページがキャッシュされることがある
http://support.microsoft.com/kb/222064/ja

によると（以下斜体は上記サイトより引用）


Web ページがキャッシュされないようにするには、HTML ドキュメントの最後に別のヘッダー セクションを挿入します。


で、下にも＜HEAD＞タグが書いてある例が載ってるんだけど・・

あのー、HEADって、上にあるからHEADのような気がするのは、ウィリアムのいたずらだけなのでしょうか・・・

それと、これで大丈夫なのかなあ・・６４Kの半分どころか、ファイル、２Kもないんですけど（＾＾；）