目次
前のページ
2014-08-13 電子メールの誕生日(1982)
2014-08-19 ブレーズ・パスカルの命日(1662)
2014-08-25 チキンラーメンの誕生日(1958)
2014-08-27 レフ・テルミンの誕生日(1896)
2014-08-30 ジョン・モークリーの誕生日(1907)
2014-09-01 ピエール・ベジェの誕生日(1910)
2014-09-04 ジョン・マッカーシーの誕生日(1927)
2014-09-06 続・6502は遅かったのか？
2014-09-10 チャールズ・シモニーの誕生日(1946)
2014-09-11 山本卓眞さんの誕生日(1925)
2014-09-12 「テレビテニス」が出荷された日(1975)
2014-09-13 スーパーマリオブラザースの発売日(1985)
2014-09-13 プログラマーの日
2014-09-15 エンジニアの日（インドの祝日）
2014-09-18 HARLIE とコンピューターウィルス
2014-09-22 ベンジャミン・トロットの誕生日(1977)
2014-09-27 アラン・シュガートの誕生日(1930)
2014-10-02 レイ・トムリンソンの誕生日(1941)
2014-10-07 バーコード特許成立の日(1952)
2014-10-14 google DNS
次のページ
今日は、電子メールの誕生日(1982)
誕生日って言っちゃうと、少し語弊があるかも。
正確に言えば、インターネットの電子メールの送信方式である、SMTP の最初のバージョンを定めた仕様書である、RFC822 の公開された日ですね。
電子メール自体は SMTP 以前から存在していて、いわゆる「パソコン通信」だってあったし、インターネットでも RFC561 で定めています。
ただ、RFC561 では、メールヘッダの書き方だけ定めていて、「FTP で相手のサーバーに送る」となっているのね。
特定のディレクトリに送り込みさえすれば、あとは定められた形式で書かれているヘッダを読んで、各自のディレクトリに配送できたのでしょう。
ヘッダの書き方はこの後何度か改定されますが、送り方は FTP のまま。
FTP と言うことは、自分のアカウントが使える範囲でしかメールが送れない、ということです。
まぁ、単純に言って「学内の友達にはメールが送れる」とかですね。
工夫次第で学外にも送れそうだけど、どこの相手にでも自由自在、とはいかない感じ。
これが、メール専用のプロトコルが定められ、今知られているような「電子メール」が出来上がったのが、RFC822 です。
RFC には公開日が記されるので、1982年の今日公開された、と言うことがわかります。
時々僕の日記などに顔を出す RFC っていうのは、Request For Comments の略ね。
本来は「コメント募集」って意味で、技術仕様ではありませんでした。
インターネットの最初期において、複数の違うマシンを接続するときに情報を整理するのに考えられた方式です。
誰かが「Request For Comments」と書かれた大学ノートに、自分が考えた技術アイディアをメモします。
もしかしたら、それは考えた人のコンピューターではうまくいくけど、別のコンピューターではダメな方式かもしれない。
ほかの人から見て、そうした、発案者が気づかなかった部分にコメントが欲しいわけです。
で、コメントを出す方も一緒になって解決策を考え、皆が参照する「技術仕様」の位置づけになっていきます。
今では、この議論を RFC 上でやるのは混乱するため、Internet-Drafts という文書を発行して意見を募り、十分に議論してから RFC の番号を割り当てるようになっています。
じゃぁ、RFC はもう RFC じゃないじゃん、って思うけど、慣習的に名前だけ残っているのです。
さて、話を戻して RFC822 。
これは、SMTP の送信形式だけでなく、それ以前に定められた「メールヘッダ形式」などもすべて含め、電子メールとしての基本的な仕様を網羅できる文書になっています。
とはいえ、すでに時代遅れ。
RFC2822, RFC5321 & 5322 などで更新されています。
2822 は 822 の更新だけど、さらに更新する際には肥大化しすぎたし、メールのフォーマット形式はその後 HTTP 等にも流用されるようになっていました。
そのため、SMTP を再定義したのが 5321 で、メッセージフォーマットを再定義したのが 5322 と分離されたのです。
内容に関しては、現在みんなが「あたりまえ」と思っていることが書かれているので、特に言うべきことは無いです。技術者でなければ特に読む必要なし。
しかし、「あたりまえ」というのはここに規定されているから当り前なのであって、重要であることは間違いありません。
技術者や、そうでなくてもちょっと読んでみたい人のために…
たとえば、数年前まで問題になっていた、DoCoMo の i-mode メール。
i-mode メールでは、メールアドレスの @ の左側で、. （ピリオド）が自由に使えました。
でも、RFC5322 には、こう書かれています。
atext = ALPHA / DIGIT / ; Printable US-ASCII
"!" / "#" / ; characters not including
"$" / "%" / ; specials. Used for atoms.
"&" / "'" /
"*" / "+" /
"-" / "/" /
"=" / "?" /
"^" / "_" /
"`" / "{" /
"|" / "}" /
dot-atom-text = 1*atext *("." 1*atext)
dot-atom = [CFWS] dot-atom-text [CFWS]
local-part = dot-atom / quoted-string / obs-local-part
addr-spec = local-part "@" domain
…あぁ、ややこしい！
RFC は技術文書なので、BNF という特殊な記法で（間違いが無いよう厳密に）書かれているのです。
BNF は、= の左側に書かれている「名前」は、右側に書かれている「意味」だよ、という定義方法だと思ってください。
等式に見えるけど、定義ね。数学みたいに「これとこれは同じです」ではなく、「今こう決めました」なので、意味がわからなくても難しがる必要はないです。
でも、知らない名前が書かれていたら、どこかでその名前について定義しているはずだから、ファイルの中を検索して探しながら読む必要がある。
ちなみに、英単語みたいに書かれているのが「名前」で、" " で囲まれているのは「文字」です。
上の方に ALPHA と書かれているのは、アルファベットの文字、と言う意味の名前なのだけど、"!" と書かれているのは ! という文字。
さて、先の定義、上から読もうと思っても混乱します。一番下から見てください。
addr-spec というのは、「メールアドレス」として書ける文字列のこと。これを「local-part と domain の間に、 @ を挟んだもの」と定義しています。
これならわかる気がする？
じゃぁ、local-part ってどんななの？ と言うのがその上の行。dot-atom か、 quoted-string か obs-local-part のどれかを選んでよい、と言う意味です。
dot-atom というのは、[CFWS] が前後についた、dot-atom-text 。
[CFWS] っていうのはまた別に定義があるのだけど、Comment & Folding white space の略。
「コメントと、改行・スペース・タブ」の意味で、これらの「無意味なもの」がついてもいいですよ、となっている。
[ ] で括られているのは「なくてもよい」と言う意味なので、必ず付く必要はないです。
…ということは、メールアドレスを書くときは、@ の前にスペースを置いても同じ意味になる、と言うことです。普通そんな書き方しないけど、もしその書き方で送れないメールソフトがあったら RFC に従っていない、と言うことになります。
dot-atom-text は、１つ以上の atext の連続の後に、. （ピリオド）を置いて、また１つ以上の atext を置く、と言うのを任意回繰り返してよい形式。
1* というのは、「その後ろにあるものが、１回以上繰り返される」の意味で、 * だけだと「０回以上繰り返される」です。
先に書いた通り、「なくてもよい」は [ ] なので、*a と [1*a] は同じ意味になりますね。
次でやっと最後。atext というのは、「英文字と数字と、ここに示された記号」のうち、任意の１文字です。
長々と書きましたが、言葉で厳密に説明すると長くなるものを、BNF では簡潔に書けているわけです。
読み方を知っておくと、いろいろと発見があるかも。
たとえば、atext を眺めただけでも、メールアドレスに ? や ! を含んでも良い、と言うことがわかります。
これは、「含んでも良い」であり、「使える」ではないことに注意。
使えるかどうかは、自分がメールボックスを持っているシステムの仕様によります。
たとえば、unix ではアカウントに - （ハイフン）は使えなくて、local-part は普通アカウントが使用されます。つまり、local-part にはハイフンは使えないことになります。
…が、unix のプログラムである qmail は、ハイフンが入っていると「その前までをアカウント」だと認識して、該当アカウントを持つユーザーにメールを配送します。
このため、ユーザーは目的に応じてメールアドレスを変更でき、目的別のメールの振り分けなどが楽に行えます。
また別の話ですが、「自分のシステム」が local-part に記号を使えないからと言って、どんなシステムでも使えない、と決めつけるのは間違いです。
多くの WEB サービスで、メールアドレスを ID としてログインできるような形になっていますが、loca-part 部に ? 等の記号が入ると、不正なアドレスだとエラーになるものもあるようです。
RFC で認められている文字なのだから、これがエラーになるのはおかしいです。
自分が勝手に考える「常識」の前に、技術仕様としてどう定義されているのか確認しましょう、という、技術者なら当然の話。
でも、BNF の読み方を知らない技術者は（残念ながら）非常に多いのです。
さて、話を戻しましょう。
dot-atom-text をもう一度簡単に示せば、「atext を連続させる際、途中でピリオドを挟んでもよい」と言う形式です。
atext の連続は許されますが、ピリオドの連続は許されません。
「途中」ではない、先頭や末尾のピリオドも許されません。
i-mode メールが一時期問題視されていたのは、これが許可されてしまっていたため。
au は RFC に従っていたのですが、i-mode の普及に伴って「i-mode に仕様をあわせる」という意味不明の改悪をして、大騒ぎになりました。
ただね、当時一部のメールサーバーで i-mode からのメールを受け取れないので問題視されて「docomo は RFC に違反している」と言われていたのだけど、受け取れないメールサーバーだって RFC 違反。
RFC では、常に「自分が作るデータは厳密に。しかし、相手から送られてくるデータには寛容に」が求められています。
だから、RFC に違反するデータを作り出す i-mode メールが問題なのは当然なのだけど、そのデータを寛容に受け取れないメールサーバーにも問題があるのです。
実際、多くのメールサーバーではちゃんと受取れていたしね。
RFC っていうのは、「そのデータしか送られてこない」と保証する類の仕様書ではなくて、「相手はともかく自分は」従いましょう、という緩い決まりごとにすぎません。
電子メールの誕生日って話から離れてしまいますが、せっかく RFC の話をしたので…
RFCには「ジョーク RFC」と呼ばれるものがあって、これは４月１日に発行されます。
最近では恒例になりすぎて、「ジョークを書いてやろう」と力が入りすぎているのが多くてちょっと興ざめなのだけど。
でも、これらのジョークは、技術文書のふりをして書かれているので、BNF を読めると面白さが広がることも多いです。
（ジョークだから、BNF 使わないものも多いのだけど）
初期(1978)に書かれた RFC748 とか、なかなか名作。
一ひねりしてあって、裏読みしないと真意がわかりません。
（真意がわかると、これがジョークではなく「切望」であると、技術者なら共感できるはず）
RFC1149 も名作とされているのですが、日本語訳はどうもまずいものばかり。（日本語訳は、探せば見つかります）
これは英語の言葉遊びをうまく織り交ぜていながら、バカバカしいことを真面目に技術的に書いているから「名作」なのです。だから、日本語にすると面白さが失われてしまう。
RFC3514も名作。技術的に確かに可能だけど「作っても意味ない」と明らかにわかるものを大真面目に書いた…というものだったのですが、当日中に（つまり、エイプリルフールジョークとして）本当に作る人が現れて話題になりました。
まぁ、「ジョーク RFC」で探せば紹介しているサイトは一杯あるので、興味あったら探してみてね。
（本も出版されているけど、あまりお勧めしない）
同じテーマの日記(最近の一覧)
関連ページ
別年同日の日記
申し訳ありませんが、現在意見投稿をできない状態にしています。 |
今日はブレーズ・パスカルの命日(1662)。
大天才ですが、39歳で没しています。
一説によれば、パスカリーヌの作成（17歳から19歳の時）に没頭しすぎた時に体調を崩し、生涯虚弱だったと言います。
…もともと虚弱だったから室内で出来る研究に没頭したのではないかな、と言う気もしますが。
6月19日の誕生日にいろいろ書いているので、詳細を知りたい方はリンク先へ。
同じテーマの日記(最近の一覧)
別年同日の日記
22年 vue-tweet-embed で表示していた Tweet が崩れる
申し訳ありませんが、現在意見投稿をできない状態にしています。 |
今日はチキンラーメンの誕生日。
誕生日？ まぁ、発売された日と言うことね。
＃パピコンクリッカーを作った Tiny野郎さんは今日が誕生日だそうだ。
同じ誕生日の人を探していたようなので、誕生日と表現してみた。
5か月ほど前にカップヌードルミュージアムに遊びに行っていて、そこでは当然チキンラーメンの発売以降の、日清を中心に他社の製品も含め、インスタントラーメンの歴史を展示していました。
戦後の食糧難の時に、安藤百福さんが誰でもすぐ作って食べられるラーメンを開発しようとした話や、てんぷらをヒントに製法を考案する話なんかは結構有名。
他社にまねされたときに粗悪品もかなり出回り、「製法がわからないから粗悪品ができるんだ」と、特許を取っていた製法を無償公開してしまった、というのはミュージアムで知った。
ただし特許を使用するには「日本ラーメン工業協会」に加盟して品質を保証しなくてはならない。この協会の会長は百福さんがやっており、加盟料は払う必要がある。
でも、これで類似品も含めて品質が安定し、「インスタントラーメン」の需要がさらに広がる。
結果としてちゃんと日清は儲かるようになっている。素晴らしい。
と、僕のページで書くのだから、受け売りの話で終わらそうとは思っていない。
僕が子供の頃にはじめて「自分で作れる料理」のレパートリーを持ったのは、インスタントラーメンだと思う。
これ、非常に微妙な問題で、パンを焼いて食べる、程度はその前からやっていた。
どこから料理と見做すかの境界で、当時の僕は「ガスコンロを使う」ことが大事だと思ったのね。
ちなみに、具は入っていないので包丁は使わない（笑）
でも、小学生には十分な料理に思えたのですよ。
プログラマは料理ができなくてはならない、と説いたのは元アスキー編集長の遠藤諭。
優れたプログラマは人に邪魔されない深夜に仕事をするものだし、その際に腹が減ったらちゃっちゃと自分一人分の料理をこしらえられなくてはならない、というのがその理由だった。
今ならコンビニがあるから買ってくれば済む話だが、それは多分真意ではない。
料理と言うのは科学実験であり、そこにはアルゴリズムも、探求心も存在する。だから、料理もできない奴は良いプログラムは組めない、ということだと僕は理解している。
もちろん、優れたプログラマで料理ができない人だって多数いる。
でもそれは、知識が足りないだけ。優れたプログラマは、最初のきっかけがあれば後は勝手に調べて学習するので、料理を始めるきっかけさえあれば必ずおいしいものが作れるようになるはず。
逆もまた真で、ありあわせの材料でおいしい料理を作れる人はプログラマの素養があると思っている。
こちらもまた、知識を持たないといけないけど、「料理する」ことに比べると「プログラムする」のはハードルが高いね。
料理にアルゴリズムが伴う、というのは、なにも料理するときに限らない。
1950年代の MIT ハッカーたちが、中華料理店に通い、メニューに書いてある謎の記号（漢字）と料理の素材・料理法などの関連性に気付き、「甘酢苦瓜」を注文した…と言う話を過去に書いた。
自分で料理はしていないが、素材と料理方法を組み合わせれば料理ができるはずだ、と推察し、実際に料理人にその指示を出して作ってもらった、というのは面白いエピソードだと思っている。
料理が自分で出来る人でも、素材と料理法の組み合わせを実験してみることがある。
思い切った実験の結果、マズくて食えないものができることもある。でも、そこで「確実にマズイ組み合わせ」を覚えたら、以降はそれを避ければよいだけだ。
実は、まずい料理を作るのは、料理の腕を確実に上げる。その積み重ねをやった人は、おいしい料理を作れるようになる。
ハワイ伝統料理を食べた時は、立場が逆転していた。
僕はお客さんで、何が出てくるかわからない。出てきたのは得体のしれないもので、周囲の人がみなまずそうに食べている。
その状況ですら、料理を知っていれば出来ることがある。
伝統料理がマズいはずがない。マズいと感じるなら、何かが間違っているんだ。
単体で食べたらまずいのを、別の料理を一緒に食べるとおいしくなるのを発見した。
この時は、ハワイ料理に対する知識も経験もなくても、料理に対する知識と「探求心」で正しい方法を見つけ出したことになる。
逆に、一般においしいと思われているものですら受け入れられない人もいる。
ドライカレーに干しぶどう、酢豚にパイナップル、鶏肉のオレンジジュース煮、生ハムメロン。
大抵肉とフルーツは、適切に合わせるとうまいのだけど、拒否反応を示す人は多い。
好き嫌いは個人の自由だけど、なぜそれが一般に「おいしい」とされるのかが理解できないのであれば、その人の理解力はその程度であり、プログラマーとしての素養もそれほどない、と思っている。
＃理解したうえで自分が嫌いな理由を論理立てて言える人ならその限りではない。
大切なのは論理体系が構築できることだからだ。
食べるというのは日常で最も大切な行為の一つで、大切だからこそ保守的になるのが普通のようだ。
多くの国では、伝統料理が大切にされ、その形を崩さないことを良しとする。
じゃがいもやトマトが新大陸からもたらされても、人々はなかなか食べようとしなかった、というのには、そうした側面もあるかと思う。
しかし、日本人は食を「冒険」と捉えるのが好きらしい。
変わったものを食べたがる。外国の料理を取り入れ、伝統料理にも新食材を取り入れ、世界中どこの国にもない新しいものを作り出してしまったりする。
＃この意味では、トマトを食べたイタリア人も食の冒険が好きだったようだ。
チキンラーメンは世界最初の「インスタント食品」だけど、日本人はそれに拒否反応を示さず、むしろ好奇の目を持って「食べてみたい」と受け入れた。
その後もボンカレーなどを含めて多くの「すぐ食べられる」食品が出てきたが、それほど拒否反応は無い。
インスタント食品が日本から出てきて世界に広まっているのは、こういう国民性とも無縁ではないように思う。
＃もちろん今でも「体に悪そう」と拒否反応を持つ人もいるが、それは個人の好みであり、自由だ。
（納豆が嫌い、というのとそれほど変わらない話だと思っている）
同じテーマの日記(最近の一覧)
別年同日の日記
申し訳ありませんが、現在意見投稿をできない状態にしています。 |
今日はレフ・テルミンの誕生日(1896)。
不思議な電子楽器「テルミン」に名を残す、ロシア生まれの博士です。
ロシア革命後、人間が近寄ったことを感知する「近接センサー」を研究している過程で、人間との距離を音階・音量で表現する楽器「テルミン」を作り出しました(1920)。
僕は音楽にはそれほど詳しくなくて、テルミンも「音を出した」ことはあるけど、演奏とは程遠いレベル。
もっとも、テルミンの演奏は非常に難しく、音楽ができれば使える、と言うようなものではないです。
音楽って、本来連続している音の周波数をあえて「区切る」ことで、人間が認識しやすい数にまとめることで成り立っています。
だから、ピアノでは鍵盤があるし、ギターではフレット（弦の押さえられる位置を決める凸部）があります。
でも、テルミンは「距離」によって音階を決めるので、音が自由に出せすぎてしまい、音楽になりません。
バイオリンもフレットがなく自由な音が出せてしまうため、テルミンは演奏方法は全く違うものの、「バイオリンと類似する楽器」として使われることが多いようです。
ただ、バイオリンの物まねをするのであれば、最初からバイオリンを使う方がいい。
テルミンの性能を最大限に引き出した演奏は、テルミンでしかない味わいが出ます。
「テルミン」と言う映画があります。博士の辿った一生をインタビューなどを中心にまとめた映画ですが、公開された 1993年に博士は亡くなっています。
（作成時点では博士は生きていてインタビューに答えているので「半生記」とすべきなのかもしれません。
しかし、事実としては博士はインタビュー直後に無くなってしまったため、事実上は博士の一生を追った映画となっています）
日本では 2001 年に夏に公開され、興味があったので見に行きました。
恵比寿ガーデンシネマでの単館上映でした。
映画の内容は…えーと、よく覚えてない！
僕のページ、1996 年からやっているけど、2000年前後に一旦閉鎖して、2001年秋から再公開しています。
そのため、テルミン見た、と言う日記もありません。残念。
手元に今、映画のパンフレットというか、映画について書かれた小冊子があります。
映画館で買ったものなのですが、いわゆるパンフレットのサイズではなく、文庫本サイズ。
普通のパンフレットにしていないのは意味があって、カバーの中に3冊が収まっているのです。
１つは、楽器テルミンと博士の一生について解説した冊子。
もうひとつは、テルミンに魅せられた音楽家や、関係者、映画を一足先に見た著名人などからのメッセージ集。
最後の一つは、冊子ではなくて折りたたまれた紙。広げると、テルミンの回路図が描いてあります。
テルミンは古いだけに回路が単純で、その気になれば簡単に作れます。
メッセージ集には、ビーチボーイズのブライアン・ウィルソンや、最高のテルミン奏者であるクララ・ロックモア、シンセサイザーの始祖として有名なモーグ博士の談話も載っています。
モーグ博士は、「モーグ」シンセサイザー(1965)の開発者として有名ですが、元々テルミンに感化され自分でテルミンを作って販売し、その過程で音を自由に作り出す原理を学んでシンセサイザーを作成したのだそうです。
PDP-8 で MUSYS(1969)を作った Electronic Music Studios Inc. もシンセサイザーメーカー…ということはモーグの影響を受けていますし、MML の始祖と僕が考えている SCORTOS(1977) も、モーグのシンセサイザーを含むいくつかの電子楽器をコンピューターで操作するシステムでした。
なので、テルミン - モーグ - 現代のコンピューター音楽というのは、明らかにつながっているのです。
クララ・ロックモアは、博士から直接演奏法を教わり、博士より上手に演奏ができるようになった、当時最高のテルミン奏者でした。
奏者はそれなりにいたのですが、クララの演奏は次元の違う音です。
映画では、多くの演奏者が出演するのですが、明らかにレベルが違っていました。
クララの演奏は、Youtube などで見ることもできます。
最初に人間との距離によって演奏する、と書きましたが、クララの演奏では手の形を変えています。
厳密に言えば、人間との距離、ではなく、アンテナが電圧を持つことで人間との間に静電気が溜まり、この静電容量によって音を変えています。
距離が変われば静電容量も変わるのですが、電場中の「面積」が変わっても静電容量が変わります。
クララは、手の形を微妙に変えることにより、これをコントロールしているのです。
演奏には非常に集中力が必要なだけでなく、周囲の観客の動静までもが「静電容量」に影響を与えてしまいます。
このため、演奏中は周囲の人も静かにしていなくてはならないそうです。
映画を見に行った頃は、「テルミン」というのはそれほど有名ではない楽器でした。
それ以前にテレビで見たことがあって興味を持っていたのですが、日本で映画公開するまでに 8 年かかっているので、たぶんテレビで見たのもアメリカでの映画公開後だったのでしょう。
今では日本でも知名度が上がっています。
「テルミン」と言えば、名前くらいは知っている人が多いのではないかな、と言う程度には。
先に「クララ・ロックモアの演奏は次元が違う」と書きましたが、それは映画公開前の話。
今では、日本でも非常に高いレベルの演奏を行うテルミン奏者が多数います。
遊んでみたいなら雑誌の付録で入手できてしまうくらい。
もっとも、最初に書いた通り僕はそれほど音楽に詳しくなくて、生演奏のコンサートを見に行ったこともないですし、テルミンも持ってはいません。
同じテーマの日記(最近の一覧)
関連ページ
クララ・ロックモア 誕生日(1911)【日記 16/03/09】
別年同日の日記
申し訳ありませんが、現在意見投稿をできない状態にしています。 |
ENIAC を作った２人のうちの一人です。
もう一人のジョン・エッカートは過去に記事を書きました。
モークリーは ENIAC を構想した人で、エッカートは実際に作った人でした。
ENIAC の設計前、気象学の仮説として「十分なパラメータがあれば、気象は完全に予測できる」と言うものがありました。
この頃、経験と勘で天気予報を行うことはあったけど、完全に出来るかどうかは不明だったのね。
モークリーは、この仮説を実証したかったのだけど、「完全なパラメーター」がわからないし、もしパラメータが入手できても、膨大な計算が必要だと予測されました。
それどころか、いま手に入るパラメーターを計算するだけでも、手回し計算機ではとても間に合いません。
恐らく、当時最高速だったリレー計算機や、アナログの微分解析機を使ってもダメでしょう。
＃アナログと言うと遅そうですが、微分解析機はデジタルが「遅すぎるから」作られた機械でした。
そこで、超高速の計算機を作るにはどうすればよいかを考え始めます。
モークリーは自分で勉強をして、真空管を使えばリレー回路と同等の回路をくみ上げ、物理的な動作が無い分だけ高速に計算ができそうだ、という考えに辿りつきます。
モークリーはいくつかの試作機を作りますが、電子回路設計の体系だった知識は持ち合わせていませんでした。
その頃、ヨーロッパで第２次世界大戦がはじまります。
アメリカでも参戦は免れないとの考えが広まり、戦時要員の確保のために、電気工学者の養成講座が開かれることになりました。
モークリーはこの養成講座に参加します。最年長の受講生でした。
しかし、この講座の目的は「素人に最低限の電気工学を教える」ためのもので、独学とはいえ計算機を試作しているモークリーにとっては満足できるものではありませんでした。
しかし、彼はここでエッカートと出会います。
エッカートは、最年少の講師でした。
電気工学の天才で、若くして講師に選ばれていたのです。
モークリーは、講座の参加者の前で、真空管を使えば超高速の計算機が作れるはずだ…という自分の考えを披露しました。
素人の集まりの中では、この主張はあまり理解されなかったようです。
また、熟練した講師陣に於いては、壊れやすく不安定な真空管を何本も組み合わせる回路など、実現できるようには思えませんでした。
ただ一人、講師の中で最年少のエッカートだけが、この考えに共感しました。
ここに、最年長で最も知識を持った「素人」と、最年少で経験の浅い「専門家」のタッグが組まれます。
やろうとしていることは、理論的には出来るはずでした。
ただ、経験があればそれがどれだけ難しいかわかるのに、中途半端な知識ゆえに前に踏み出すことができたのです。
ところで、先に「アナログの微分解析機」という話題を出しました。
電気工学者養成講座が行われたペンシルバニア大学ムーア校では、この微分解析機を使った、大砲の弾道計算業務を請け負っていました。
大砲を打つ際には、角度と火薬の量、風向き・湿度・気温など、非常に多くのパラメーターを考慮する必要があります。
当時の大砲は急に高性能になり、地平線の向こうまで届くようになっていました。
敵を狙う際に「撃ってみて、着弾点を見て少し方向修正する」という従来の方法は使えないのです。
そこで、多くのパラメーターを考慮して、撃ったらどこに着弾するか、をすぐに調べられる「射表」を使って敵を狙う必要がありました。
この計算がとにかく大変で…地平線の向こうまで届くのですから、わずかな計算誤差が非常に大きくなります。
砲弾の飛行中の動きを全て計算し、着弾までをシミュレーションすると、当時最高の計算能力を持つ微分解析機ですら、射表を１つ完成させるのに１か月かかっていたのです。
戦局が動き、新たな地が戦場になると、湿度や気温などが大きく変わるため、新たな射表が必要となりました。
新兵器が開発されると、砲弾の空気抵抗などがすべて変わるため、新たな射表が必要となりました。
１つの射表に１か月もかかっていては、とても戦えません。
ムーア校に計算業務を委託していた陸軍では、もっと早い計算機を必要としていました。
そこに、モークリーとエッカートが超高速の計算機を作ろうとしている、という話が届きます。
射表計算を統括していた陸軍将校ゴールドスタインは、この計画にすぐに資金提供を申し出ます。
そうして、ENIAC の開発が始まるのです。
ENIAC に関しては、ずっと昔に書いた記事を読んでね。
もっと、このページのごく初期に書いた（もう１７年も前だ）ものなので、今見ると拙い記事ですが。
まぁ、ざっとまとめると ENIAC は以下のようなものです。
・「世界初のコンピューター」として、広く知られています。
・でも、今のコンピューターと違って２進法ではなく、１０進法を使っています。
・配線板があって、配線を変えることで計算内容を変えられます。
今のように、メモリにプログラムを書き込む方式ではありません。
・つまり「世界最初のデジタル電子計算機」ではありますが、現代人の考えるコンピューターとは全然違います。
ENIAC の作成中から、モークリーとエッカートは「次の機械」を構想していました。
ENIAC は１０進法ですが、これは陸軍の「技術に詳しくない」人々を納得させるために、あえて手回し計算機と同じ構造を採用している節があります。
もっとも、モークリーとエッカートも、設計当初はちょっとした勘違いで「２進数より１０進数の方が良い」と考えていたようですが…
また、配線板によるプログラムは複雑で、内蔵したメモリにプログラムを書き込む、というアイディアも、すでに出ていました。
２進法の採用と、プログラム内蔵方式。この二つのアイディアを中心として構想されたのが、EDVAC でした。
これは、ENIAC に比べるとずっと現代のコンピューターに近いものです。
…が、途中からプロジェクトに参加した（というか、呼ばれてもいないのに割り込んできた）フォン・ノイマンによってプロジェクトチームが分裂、完成が大幅に遅れます。
モークリーとエッカートは、プロジェクト途中で離脱、「エッカート・モークリー・コンピューティング・カンパニー」を設立し、商用機である BINAC を作成します。
この会社はその後資金繰りで躓いて、レミントン・ランド社に身売り。
安定した資金で二人はそのまま開発を続け、商用コンピューターとして最初のヒット商品である「UNIVAC-I」を生み出します。
ここら辺の経緯は、エッカートの誕生日の際に書いていますので、そちらを参照してください。
同じテーマの日記(最近の一覧)
関連ページ
ジョン・モークリーの命日(1980)【日記 15/01/08】
クリストファー・レイサム・ショールズ 命日(1890)【日記 15/02/17】
クリストファー・レイサム・ショールズ 命日(1890)【日記 15/02/17】
別年同日の日記
申し訳ありませんが、現在意見投稿をできない状態にしています。 |
今日はピエール・ベジェの誕生日。
命日の際にも書いていますが、非常に短いので再掲。
ベジェ曲線に名前を残す数学者です。もっとも、自由曲線は当時急に必要となったもので、多くの人が、同じような式を発見しています。
特に、ベジェとド・カステリョは全く同じ式にたどり着きました。先に発見したのはド・カステリョ。
しかし、どちらの式も当時は企業秘密。先に企業秘密が解除され、発表できたのはベジェでした。
このため、この式で描く曲線をベジェ曲線と呼びます。
ただし、アルゴリズムはド・カステリョのアルゴリズムと呼ばれます。
詳細は、ベジェ曲線から、NURBS曲面までの歴史を読んでみてね。
同じテーマの日記(最近の一覧)
別年同日の日記
申し訳ありませんが、現在意見投稿をできない状態にしています。 |
去年は翌日に書いたのだよね…
日付記録の意味もあり、今日が誕生日だと書いておきます。
ジョン・マッカーシーは人工知能の父と呼ばれる研究者で、Lisp 言語の設計者。
それよりも、MIT の学生ハッカーたちの守護者的な側面があり、プログラムの楽しさを普及させたことに功績があると思っています。
詳しくは去年の記事を読んでね。
同じテーマの日記(最近の一覧)
別年同日の日記
申し訳ありませんが、現在意見投稿をできない状態にしています。 |
しばらく前にファミコンはMSXの半分のクロック周波数だったから MSX より遅かった、という話にたいして、そんなことは無いという記事を書きました。
元の話（ファミコンは遅かった）を書いていたページを改めて探したけど、見当たりません。
何かを調査している最中に、２～３か所見たので誤解が広まっているのだな、と思ったのだけど。
で、先の記事では比較できる命令単位で比べるとほぼ同等、と言うことを示し、実際の命令組み合わせ例でもそれほど変わらない、と示していました。
でも、組み合わせ例はあまり出来が良くなかった。
Z80 に詳しい方からも、6502 に詳しい方からも「もっと速くできる」と多数の指摘を頂きました。
これがあまりに面白かったので、調子に乗って「Z80 vs 6502」なんてページを作ってまとめてみました。
例題としては「１～100を足し合わせる」だったのですが、「その答えを知りたいなら n*(n+1)/2 の公式を使った方が速い」という意見も。
まぁ、確かにそうなのだけどそれはアルゴリズム改良であって、同じアルゴリズムで別 CPU の速度を比較する、と言う話ではなくなってしまいます。
でも、実際別アルゴリズムでの比較もやってみたい。ということで、掛け算を使った比較例もページを作りました。
作りましたっていうと偉そうだけど、僕がしたのは、教科書的なプログラムを示しただけ。
後は多くの方が「改良プログラム」を投稿してくれました。
多分こういうの来るだろうなぁ、と思っていて来るのは予想の範囲内。
でも、予想を超える方法で高速化したプログラムも数多く送られてきました。
実のところ、僕は 6502 でアセンブラを覚えましたが、当時はハンドアセンブルだったし、参考文献もそれほどなく今思えば無駄だらけのプログラムを組んでいただけ。
Z80 も少しはやりましたが、こちらもそれほど使い込んでいません。
ちゃんとアセンブラ使い始めたのは 68000 で、その後 V60 を仕事で使い込みました。
でも、仕事ではその後Ｃプログラムに移行していき、Ｃが生成した SH2 の機械語をデバッガで追う必要があったので SH2 を「読めるようにはなった」程度が最後。
だから、8bit では定番テクニックだった掛け算の高速化とか、それほど知りませんでした。
送られてきたプログラムの中には、おそらく定番の技法もあったのでしょうが、定番であっても僕にとっては「初めて見る」超絶技巧でした。
最初に書いた日記記事では、個別の命令比較では 6502 の方が速い、と言う結果でした。
でも、6502 は高速な CPU で、Z80 は高機能な CPU 。本当は単純な比較なんてできません。
命令単位で見ると 6502 の方が速そうに見えてしまうけど、Z80 の高機能を活かせば速度は同等になる、と示すのが当初の目的だったため、例題は Z80 が有利になるように意識して作られていました。
３番目の例題、ブロック転送がそのもっともたる例。
Z80 には「ブロック転送」と言う命令があり、メモリ内容を別のメモリに転送できました。
でも、6502 にはそんな命令は無く、メモリを読み出して、書き込んでを繰り返す必要があります。
6502 には絶対勝てない題材…なのですが、予想に反し 6502 は健闘。遅いとはいっても、ほぼ互角と言える速度でした。
とはいえ、最初の３題はいずれも MSX の勝ちで、これだと「MSX は速かった」という誤解をさらに広めてしまう不本意な結果になりかねません。
そこで、ファミコンが有利な例題を考えようとしました。
Z80 はメモリアクセスが苦手です。先に書いたブロック転送のように「連続メモリ」ならともかく、ランダムアクセスは本当に苦手。
それに対し、6502 はランダムアクセスはお手の物です。特に、256byte 以内のランダムアクセスは超高速。
ただ、それだけだとつまらないので、6502 にも不利な点を作るために 256byte を越える VRAM アクセスを想定した例題を作りました。
この改良は面白かった。Z80 では、スタックポインタを一時的に書き変えて高速にメモリアクセスする、なんていう手法まで飛び出しました。
でも、予想通りファミコンの勝ち。
さらに、この例題を考案中に「Z80 は条件ジャンプが遅い」という発言を見たため、条件をあらかじめ限定しにくい「ユーザー操作」を想定した、条件判断だらけの例題を出してみました。
パッド入力、ユーザー操作、コマンド入力の、連続した３題だったのですが…
これ、元は１つの例題として考案していたのを、プログラムしてみたら長すぎたので３分割したものです。
いたるところメモリアクセスと条件判断だらけで、Z80 が苦手そうなプログラム。
「1/60 秒に１回のユーザー操作の高速化にどれほどの意味があるのか」と言う批判もありました。
でも、例題としてはパッド入力としましたが、実際にゲームを作るときにはメモリアクセスだらけなのも、条件判断だらけなのも当然です。
そういう部分での性能を見るのが目的で、それを端的に示したのがユーザー操作だった、とお考えください。
決して 1/60 秒に「１回だけ」の処理を想定しているわけではないのです。
これは、想像以上に Z80 不利でした。苦手だろうとは思っていたけど、こんなに速度差が出るとは思ってなかった。
いつまでも続けられない（仕事時間も削られてしまうし、他に書きたい記事もあるし）ので、最後の締めくくりは伝統ある（？）例題にしようと思いました。
バイナリ数値を10進数にして表示する問題。
実はこれは、世界最初のハッカーたちが競い合ったプログラム例の一つです。
その時は「小さなコードを作る」勝負だったのですが、速度勝負でも面白いかと思いました。
教科書的には、10 で割って余りをスタックに入れ、最後にスタックから取り出して頭から並べます。
…割り算命令を持たない 8bit CPU で教科書的な方法は重いだろう、と思いましたが、掛け算もやったのですから、まずは割り算を例題としてみました。
掛け算は Z80 が速かったし、割り算もそうだろう…と思っていたら、予想外なことにファミコンの勝ち。
もっとも、現時点ではファミコンの方が速いアルゴリズムを使用していて、Z80 には移植されていません。
これで「割り算のベースはある」前提で、教科書的な10進変換ルーチンが作れます。
ネットで10進数値を作る話を調べると、「割り算よりも掛け算が速いので、逆数を掛ける」と言うテクニックもあります。
…8bit では掛け算も遅いし、掛け算ルーチン 16bit のしかないから十分精度のある逆数を作れ無さそう。
でも、例題の規定に「掛け算を使ってもよい」とあるのは、これを想定したもの。
で、割り算使ったらやっぱ遅い。
Z80 では、1bit づつあらかじめ BCD 化したテーブルを引いて足し合わせる、という処理も送られてきました。
でも、最終的に一番速かったのは「桁ごとに単純に引き算を繰り返す」プログラム。
実は、この例題では変換すべきデータを「8086」にしたのですが…
このデータ、「16bit なので最大５桁だけど、4桁なので左詰め処理が必要」で、「8 とか 6 が多いので、単純引き算ではループ回数が多くなり、時間がかかる」と言う想定で用意したものです。
それでも、やっぱ単純な引き算が速かった。
この勝負は、現在のところ MSX とファミコンが、全く同じ速度…１クロックの違いもない、という最後を締めくくるのにふさわしい名勝負となっています。
以上、まだ改良は続きそうですが、一区切りついたかな、と思うところで一旦まとめました。
お力を貸してくださった方、ありがとうございます。
そして、途中から私生活の方が忙しくなってしまい、投稿されても更新が遅れたり、プログラムの理解が低くて間違ったことを書いてしまったりしたことをお詫びいたします。
（怒らず訂正個所を教えてくださった方も多数。これにも感謝しています）
別年同日の日記
申し訳ありませんが、現在意見投稿をできない状態にしています。 |
今日はチャールズ・シモニーの誕生日(1946)。
…横井軍平さんの誕生日でもあるけど、それは去年の日記を見てね。
チャールズ・シモニーは Alto の上で、世界初の WYSIWYG ワープロ「Bravo」を実現します(1974)。
僕は Bravoは Smalltalk 上で作られたのかと思っていたのだけど、これは勘違いの模様。
その後、メタプログラミングの概念を提唱(1977)。
ただ、ここでいうメタプログラミングってどのレベルを言うのか、僕の調査不足で不明。
メタプログラムと言うのは「プログラムを生成するプログラム」のことです。
ちょっとした曲芸のように思われてしまうこともあるのだけど、非常に厳密さが要求されるのに、非常に長大になってしまうことがわかっているようなプログラムを、別のプログラムによって自動生成したりするのに使われます。
たとえば、yacc というソフトでは、コンパイラの文法を定義すると、その文法を解析できるＣ言語のソースを生成します。
実は、文法解析プログラムって、作るのすごく大変なのね。大変と言うのは、難しいというのではなくて、厳密で長大なのでひたすら面倒くさい。
それを自動生成してくれるのです。
これは、ある意味「プログラムを生成するプログラム」です。
ただ、それをメタプログラミングと呼ぶかというと…微妙。
Ｃ言語のソースは、Ｃコンパイラにより、アセンブラのソースを生成します。
（今では直接機械語を生成するのが普通ですが、昔はそうでした）
でも、これをメタプログラミングとは言わない。これは単にコンパイラ。
yacc もメタプログラムとは呼ばれず、Yet Another Compiler Compiler （別のコンパイラを作るコンパイラ）の略です。
メタプログラミングとは、通常は「同じ言語で」作られることに意味があります。
Lisp で Lisp のプログラムを生成し、そのまま実行するとか、Javascript で Javascript のプログラムを生成して、そのまま eval するとか。
…Javascript を圧縮してくれる Packer とか、メタプログラミングになるのかしら？
まぁ、最近ではここら辺は曲芸みたいなものになっているのですが、境界は非常に曖昧なものです。
大切なのは、プログラムでプログラムを生成することによりメリットを得られるのであれば、何も躊躇することは無い、ということ。
プログラムを作るのは人間の知的活動のなせる業だ、と言われていたときにこれを提唱したのは評価に値するでしょう。
ちなみに、曲芸的には僕も「メールアドレスを SPAM ボットに発見されないように Javascript で暗号化したプログラムを生成する Javascript」を作って公開していますので、興味ある人は見てやってください。
で、チャールズシモニーの一番の功績だと僕が思っているのは、ハンガリアン記法です。
彼はマイクロソフトに入社し、Excel や Word の開発に関与しています。
多人数でプログラムを行う際の問題を解決する方法として彼が考案した変数表記方法が、今では「ハンガリアン記法」と呼ばれています。
もちろん、彼がハンガリー人であったためこの名前が付けられたのです。
ただ、彼の考案した記法はどうも正しく理解されず「システムハンガリアン」と「アプリケーションンハンガリアン」に分断してしまいました。
彼が考えたのはアプリケーションハンガリアンなのだけど、現在普及しているのはシステムハンガリアンの方。
そして、システムハンガリアンは「全く無意味」です。
アプリケーションハンガリアンのメリットを誤解してシステムハンガリアンが広まり、この記法が全く無意味だと多くの人が感じた時点で、アプリケーションハンガリアンの存在には気づかず誤解されたままこの表記法は消えゆこうとしています。
システムハンガリアンと言うのは、変数名に、その変数の「型」を一緒に入れておこう、と言うもの。
Integer （整数）型であれば、i から始まる名前に、Float (浮動小数点）型であれば、f から始まる名前に…など、名前の付け方を統一します。
これ、全く無意味なだけでなく、弊害の方が大きいです。
後で必要があって変数の型を変えることになったら、変数を使っているところを全部探し出して書き変えないといけない。
それで何かメリットが得られるかと言えば、何も得られない。
変数の型はコンパイラが把握しているから、Integer 型の変数に Float の値を入れようとしたら、警告を出してくれます。
間違えてもコンパイラが警告してくれるのに、わざわざ変数名を工夫して「人間が注意できるように」する必要が無い。
正しい使われ方であるアプリケーションハンガリアンは、「コンパイラが警告を出さない」変数の意味について、名前の付け方を統一します。
たとえば、ドルと円の両方のお金を扱わないといけないプログラムがあった時、ドル関連の変数はすべて d を頭につけ、円関係の変数は全て頭に y を付けることにします。
これで、d と y を混ぜて使おうとしていたら、何かおかしいとプログラマ自身が気づくことになる。
ゲーム作っていて、敵に関する変数は en で、自分に関する変数は my ではじめるとか、そういうのも「アプリケーションハンガリアン」に当たります。
…ハンガリアン記法、と言われなくても、なんとなく心がけているプログラマは多そうですけどね。
ただ、大人数で開発するときはあらかじめルールを決めよう、と言うのは必要なことで、これを明言した功績は大きいです。
彼はこの手法をさらに推し進め、「インテンショナルプログラミング」と言う言語環境も考案したそうです。
僕、よく理解していません。間違っていたら申し訳ないのですが、プログラムを作成するエディタに、アウトラインプロセッサ的なレベル概念を導入しつつ、ユーザーインターフェイスと内部処理を分離しながら緩く結合する、というもののよう。
…はい、何言っているのかわかりませんね。
ちゃんと解説しましょう。
まず、プログラムと言うのは、当然のことですが「全体としてやりたいこと」があるから作るのです。
でも、コンピューターは馬鹿だから、１から１０まですべて教えないといけない。１０が目的だとすれば、１を大量に積み上げて「１０」を表現する必要があります。
でも、この作業が膨大なのですね。プログラム中のいたるところで、ちまちまとして意味の解らない作業が、膨大に発生している。
じゃぁ、そのちまちました作業に「入力がある間全部処理する」とか、「１～１０まで足す」とか、「ユーザーの指示を待つ」とか、わかりやすい名前を付けて、見えなくしちゃおうよ…というのがアイディアの一つ目。
これで、細かすぎる部分が見えなくなると、全体の処理の流れが見えやすくなります。
アウトラインプロセッサと言うのはワープロの一種なのですが、章の見出しだけを表示して全体の流れを見やすくしたりしながら推敲をするためのツールです。
そういう機能をプログラム環境にも取り入れよう、というのが、アイディアの一つ目。
もう一つ、インターフェイスビルダーと言うのは、NeXT が備えていたプログラム環境ですね。
画面表示と、プログラムの内部処理を完全に分離しておき、後から画面表示だけを組み替えたりできるようになっています。
Windows では、基本的に画面表示はプログラムの一部として実装されていました。
これでは、作った後に「使いにくかった」と思っても、プログラムを作り直さないと画面表示を変えられません。
（もちろん、画面部品をデータとして持っておき、組み替えられるようにプログラムしておくことはできます。
ただ、そういうプログラムを作るのは手間がかかります。その手間を最初から肩代わりしてくれるのが、インターフェイスビルダーでした）
これにより、プログラマーは「やりたいこと」だけに集中してプログラムが組める、と言う環境が作られます。
ただ、これは「大いなる野望」ではありましたが、いろいろとややこしいことになり、開発は頓挫したようです。
まぁ、それも判ります。
実のところ、細かな部分にわかりやすい名前を付けて見えなくする…というのは、関数化などで普通のプログラマーなら当たり前にやっていることです。
これをもっと使いやすいように支援しようとしても、煩雑な処理が増えるだけのように見えます。
恐らくは、彼の本当の目的は「意味を名前付ける」ことを繰り返させることで、全体の動作を「知らず知らずにドキュメント化」して、「保守を容易にする」ことだったのだと思います。
先に書いたハンガリアン表記も、保守を容易にする目的でした。
そして、おそらくはメタプログラミングも。
（小さなプログラムによって全体を自動構成すれば、変更が生じた際も小さなプログラムを修正するだけで済みます）
彼の興味は、プログラムを保守しやすくする環境作りにあるのでしょう。
しかし…残念ながら、多くのプログラマーはプログラムが「動く」と満足してしまい、その後の保守のために余計な労力を使おうとはしないのです。
これが、彼の考案したものが、勘違いされたり頓挫したりしながら普及しない原因かと思います。
でも、保守が大切である、と、あるレベル以上のプログラマであれば痛感しているはず。
彼の研究が多くのプログラマーに理解される日があらんことを。
同じテーマの日記(最近の一覧)
関連ページ
HARLIE あらすじと解説(1/2)【日記 14/09/21】
別年同日の日記
申し訳ありませんが、現在意見投稿をできない状態にしています。 |
今日は山本卓眞さんの誕生日(1925)
元富士通の会長さんです。2012年に亡くなっています。
でも、富士通と言う大きなコンピューター会社の会長さんだったから…と言うような甘い理由で紹介したりしません。
元々たたき上げの技術者で、日本のコンピューター黎明期に、独自のコンピューターを設計したチーム（たった３名！）の一人でした。
話は 1950年にさかのぼります。
日本は第２次世界大戦中、1945年に原爆を落とされて無条件降伏を行っています。
この後、戦後は混乱と貧困の時代でした。
しかし、1950年に、朝鮮戦争が起こります。
北朝鮮にはソ連が、韓国にはアメリカが支援を行い、この際アメリカは日本を基地として使用しました。
これにより特需が起こり、日本経済は一気に回復へと向かいます。
この際、株式市場では計算が間に合わなくなり、パンチカード会計機の導入が検討されます。
この際に、富士通にパンチカード会計機を作ってみないかという誘いが来ます。
当時の富士通は電話交換機を作るメーカーでしたが、電話交換機で使われるリレー回路で計算が行えることは、多くの技術者が知っていました。
富士通も、小規模な計算機を作成して多少のノウハウは持っていました。
富士通には池田敏雄という「天才」技術者がいました。
彼は以前からコンピューターに興味を持っており、独学でアメリカから取り寄せたENIACの回路図を元に、小さな回路を動作させたりしていました。
彼を設計の中心として、交換機の設計などを行っていた山口詔規さんと山本さんが補佐として付けられました。
この３人で設計を行うことになります。
池田さんについては、いつかまた書きたいと思うのですが、いろいろ逸話の多い人です。
とにかく、日本のコンピューター黎明期を一人で支えた大天才。
山本さんは池田さんが思い付きのままにどんどん作り出す回路…基本回路だけで５０００種類以上一人で短期間に書きあげたそうですが、これらをまとめ上げていく作業を行っていたのだとか。
ただ、池田さんは締め切りのことなど気にせず、面白そうなアイディアをどんどん形にしていくため、最終的にこの計算機は納期に間に合わず不採用。
（厳密に言えば、納期の時点で動作する形にはなったが、信頼性が十分でなかった）
しかし、これにより富士通のコンピューターの「基礎」が出来上がり、続けて富士通初のリレー式計算機となる FACOM の設計に入ります。
この際も、山本さんは中心メンバーの一人を務めています。
FACOM は、最初はリレー式計算機として、後にはパラメトロン（これもいつか詳細を書きたい電子部品）、そしてトランジスタ式のコンピューターへと発展していきます。
池田さんは後にくも膜下出血で急死します。
ここに書いてある内容の多くが「池田敏雄」の物語であることがわかるように、富士通の（そして日本の）コンピューター黎明期を牽引したのは、池田さんでした。
山本卓眞氏は「チームの一員として手伝った」のにすぎません。
しかし、山本さんは富士通の要職についてから、最も近くで見てきた者として、「天才池田敏雄」の存在を伝える語り部のような役割を自ら担って来ました。
山本さんがいなければ、池田さんの物語を詳細に知ることもなかったという点で、山本さんもまた重要人物だと思うのです。
同じテーマの日記(最近の一覧)
関連ページ
別年同日の日記
申し訳ありませんが、現在意見投稿をできない状態にしています。 |
今日は「テレビテニス」が出荷された日(1975)。
家庭用のテレビゲーム機です。
日本で初めて発売されたテレビゲーム、と言うことになっています。19,500円。
この頃って、発売日は今ほど厳密に決めてないのですよね。
だから、「工場から出荷された日」しかわからないようです。
業務用で最初のテレビゲームとされる PONG がアメリカで発売されたのが 1972年。
すぐに日本にも輸入されたようですが、これはアメリカで作られて、輸入販売。
純粋に「国内で発売」と言う意味では、テレビテニスが最初なのでしょう。
発売はエポック社（のちにカセットビジョンを作ります）ですが、マグナボックスとの提携のもと作られたそうですが、たぶん特許を許諾してもらった程度ではないかとのこと。
マグナボックスは、PONG よりも前に家庭用テレビゲーム機 ODYSSEY を発売した会社。
実は、PONG は ODYSSEY で複数遊べたゲームの一つ、「テニス」を元にして作られたゲームです。
僕、テレビテニス見たことないです。
この時代の２万円って、かなり高価。一般家庭に浸透、と言うほどには売れてないんじゃないかな。
なので、あまり語れる内容はないのです。
ゲーム内容については、ネットでの情報を調べ、総合的に考えるとどうやら ODYSSEY のテニスとは違う模様。
ここら辺が、「特許許諾程度」とされる根拠なのかな。
多分、PONG のヒット後ですから、ゲーム的に参考にしたのは PONG なのでしょうね。
PONG のテニスは、ダイヤルひとつで操作しました。
パドルを上下に動かします。
ODYSSEY はダイヤルが２つです。
１つはパドル上下、もう一つは、ボールをカーブさせるのに使います。
ボールにスピンを加えられる、本格的な「テニス」なのですね。
（その代りというか、ボールの基本的な動きは常に 45度です）
テレビテニスは、ダイヤル２つで、上下左右にパドルを動かせるのだそうです。
PONG は得点を機械が把握し、画面上に数値で表示してくれました。
ODYSSEY は、テニスに限らず「場を提供する」だけなので、勝敗を決めるのは人間の責任。
テレビテニスは、得点を記録するためのダイヤルが本体についています。でも、これを回すのは人間の責任。
テレビテニスには、左右に２個づつのダイヤルとは別に、さらに左右それぞれの上に１つづつ、計２つのダイヤルがあります。
これ、別の画像で調べたところだと、右側は slow - fast と書いてある。
恐らく、ゲームの速度調整が出来たのではないかな。
そして、左側は 25 - 30 と書いてある。
これは何だろう？ リフレッシュレートでも変えられたのかな？
子供の頃我が家にあった当時のゲーム機（テレビテニスの２年後発売の、TV FUN 801）には、カラー調整ダイヤルがありました。
同じような機構が付いている可能性もあります。
ここら辺、当時使っていたり、興味があって入手した人がいたら、教えてください。お願いします。
＃教えてもらってどうなるものでもないけど、日本初のテレビゲーム機と言うのは興味を持つ人が多いでしょうから、情報があれば追記させてもらいます。
2014.9.20追記
さて、待望の情報を頂きましたので追記します。
まず、25 - 30 は、表示させるチャンネルの選択でした。
テレビテニスは、電波でテレビに画像を飛ばします。ここに、Uチャンネルを使っているのですね。
Uチャンネルもすでに死語だな。
アナログ放送の時代は、電波帯域として、VHF と UHF が使用されていました。
このうち、1～12チャンネルには VHF が使用され、13～62 チャンネルには UHF が使用されていました。
当時は、1～12 と「U」と書いた13チャンネルのダイヤルがあり、それぞれのチャンネルごとにチューニングを行えるのが普通でした。
ですから、25 - 30 と書いてあっても、６段階の切り替え式ではなく無段階だったのでしょう。
そして、U の方でもチューニングをして画像を出すのです。
余談ですが、現在のデジタル放送では、すべて UHF で放送しています。
そのため、チャンネルは 13～62を使用していますが、リモコンの番号は 1～12 を使うことで、ユーザーが従来と同じ感覚で使用できるようにしています。
情報もう一つ。YouTube にテレビテニスの動画がありました。
動きが…独特です。PONG ではなく、ODYSSEY に近い部分もある。
「特許許諾程度」だろうという推察を見ていたのですが、もしかしたらもう少し手を貸しているかも…
ODYSSEY のテニスは、打ち返した瞬間少しボールが速く動き、遠くに行くと遅くなります。
本物のテニスボールっぽい動きにしているのです。
また、ODYSSEY のテニスは、打ち返した後、ボールの飛び方をコントロールできます。
変化球を出せるのです。
テレビテニスの動画を見ると、打ち返した直後は動きが速く、ボールが「曲がる」場合があります。
…この「曲がる」の条件はよくわかりません。右プレイヤーのパドルの動きと連動するようにも見えます。
右プレイヤーは CPU に設定しているようなので、左プレイヤーがうまく使いこなせていないだけかも。
…対戦だけでなく CPU 設定も出来る、というのがまた驚きの発見です。
一方で、ODYSSEY ではボールの動きは 45度単位でしたが、テレビテニスでは PONG のように微妙な角度に飛んでいきます。
ODYSSEY とも PONG とも違う、中間的な感じです。
同じテーマの日記(最近の一覧)
関連ページ
別年同日の日記
申し訳ありませんが、現在意見投稿をできない状態にしています。 |
今日はスーパーマリオブラザースの発売日(1985)
「今日は何の日」を書いていて、単にファミコンゲームが発売された日を書くことはしない、と言うルールを自分に課しているのだけど、これは別格です。
単にファミコンゲームと言うのではなく、世界で一番売れたゲームとして長年君臨していたし、その後のテレビゲームのあり方を大きく変えたゲームですから。
もっとも、スーパーマリオに対する僕の思いは、宮本さんの誕生日の時にすでに書いています。
ただ…この時に現在は削除されている Blog 記事を参照したのね。
（Wayback Machine で保存されているので読むことはできる）
そして、この記事に対しては内容がおかしい、と言う批判があることを後で知りました。
批判した人は、ちょっとゲーム界では名が知れた人なので、Blog 記事を書いた人は、この批判で記事を消してしまったようです。
概要だけ書くと、僕が参照した Blog 記事は、「宮本さんはスーパーマリオを作る際に、パックランドを研究して、より面白くするアイディアを加えて作った」というものでした。
批判している人は、パックランド発表からスーパーマリオ発売までの期間は短すぎて、どう考えてもあり得ない、と論を展開していました。
スーパーマリオ発売は 1985年の今日、９月１３日なのだけど、製作期間に１年以上は取らないといけないはずだ、というのが反論の趣旨。
ある程度形になってから本格的に始動したとしても、本格始動が1984年の7月でないとおかしい、しかしパックランドは1984年8月発売だ、と言うのが大きな根拠となっていました。
この日程の推測は、ちゃんと根拠を示し、細かな数字を積み上げて「かなりのデスマーチ進行」でもこれだけの日程が必要であることが示してあります。
実際にゲーム作成の経験者として有名な方の解説ですから、それなりに信憑性がありました。
ただ、僕から見ると批判している人の根拠もおかしなものでした。
批判した方はゲーム作成経験があるとは言っても、コンシューマー（家庭用）です。
僕は業務用ゲームを作っていた経験がありますが、コンシューマーと作り方が全然違います。
コンシューマーでは１年程度かけるのが当然だった時代もある（今ではもっとかけるのも普通）のですが、業務用はもっと短期のスパンで作られるのが普通です。
今は僕は現役でないのでわからないのだけど、10年前なら半年程度が普通。余程の大作でも１年と言うのは少なかったように思います。
小粒なゲームなら３か月で作ることもあったし、僕が携わったものでの最短は１か月でした。
＃いい加減なゲームじゃなくて、それなりの評価を貰ったゲームです。まぁ、小粒感は拭えないけど。
で、スーパーマリオの頃はまだ「コンシューマー」の歴史は浅くて、家庭用でも業務用と同じノリで作られていました。
ゼルダの伝説以前のファミコンゲームって、ゲームセンターの移植がすごく多かったし、オリジナル作品でもどことなくゲームセンターのノリが残っていました。
1980年代前半なら、業務用でも開発期間は３か月程度が普通でした。
スーパーマリオの頃は少し伸びていたと思うのだけど、それでも６か月程度だったのではないかな。
そして、これは「業務用」だけでなく、ファミコンのゲームでも当てはまる開発期間だったように思います。
というわけで、スーパーマリオがパックランドの研究の元で作られた、と言うのはあり得るんじゃないかな、と言うのが僕の立場。
どちらが正しいかはわからないが、自分も知らずに参照して記事を書いた以上、裏付けを取る責任があるだろうな、と思っていました。
そこで、論争の元となったページ…今では削除されましたが、保存されている…の最後に「参考文献」として示されていた本を古本で見つけ、購入してみました。
その本は本文中でも引用しているので、それなりの根拠があるのだろう…と期待して。
でも、全然違う内容の本でした。
この本自体は、非常に良い資料となります。任天堂のゲーム作りを「ビジネスとして」の視点でとらえ、多くのインタビューによって浮き彫りにした良書。
だけどそこにあるのは会社としての任天堂の姿であり、スーパーマリオの開発話なんて一切入っていませんでした。
どうやら、論争の元となった部分は Blog 作者の勝手な推測記事。
わざわざ関係ない本でも「参考文献」として示すのだから、開発話の部分で参考にしたものがあれば書くでしょう。それが無いのだから、勝手な推測と断じても仕方がないレベル。
ただ、それじゃぁ Blog に書いてあったことが全く嘘なのかと言えば、ある程度の妥当性があったように思います。
推測なら推測だと明記すれば、後から読んだ人の参考に十分なる程度には良い考察をしていました。
それが消されてしまい、人の目に触れなくなったというのはある種の損失だと思います。
「自分の経験」だけで、日程的にあり得ない、完全に嘘だ、と断罪した批判者の罪でもあるでしょう。
ちなみに、批判した方は日程的に１年以上は必要、マスターアップ（プログラムの完成）は、発売の２か月前、と断じていました。
この批判 Blog が書かれた後に任天堂が公式に日程を明らかにしているのですが、「(1985年)２月２０日に仕様書を書いて、その半年後にはロム出し」となっています。ロム出し（プログラムの完成）は８月の中ごろ…つまり、発売の１か月前だったようです。
まぁ、こうした日程の読み間違いは批判よりも後に明らかになったことで、批判したこと自体が間違えていたとは思いません。
根拠もない勝手な推測記事だろう、というのは当たっていたようですし、多くの意見が出ること自体は健全な状況です。
ただ、現状では「日程がありえない、嘘を付くな」と批判した方は、「１年はかけているのが当然」という嘘を今でも批判記事として放置したままです。
そして、この批判により、勝手な推測とはいえある程度妥当性のある考察をしていた記事は消されてしまいました。
他人の嘘「だと思ったこと」には容赦ないけど、自分が付いてしまった嘘はほったらかし。
これにより、「多くの意見が出ることが健全」だという観点から言えば、非常に不健全な状態になっています。
僕は、人間は誤るものだと思っています。
だから、間違いを書くのも当然。
間違いに気付いた人が批判、反論を出すのは当然の権利です。
ただし、これが言論封殺につながるようなことがあってはなりません。
なぜなら、反論者もまた、間違えて当然だからです。
激しい批判で記事を撤回・消去させたとして、それが後世への損失になることだってあり得る。
ただ、この件に関しては批判者だけが悪いわけではありません。
批判された記事は、「参考文献」から引用した部分から曖昧に推測部分を展開することで、あたかも信憑性のある話のように見せかけています。
これが嘘だと激しく批判されたので、問題となる記事を消して逃げてしまい、謝罪はしなかった。
おそらくは、最初から事実誤認させようという、意図的な悪意があったのでしょう。
ただ、先にも書きましたが、推測にすぎないとはいえ状況証拠はキッチリと押さえた良い記事でした。
推測ですと断りを入れればよいだけの話で、消してしまうのはもったいない。
間違えるのも人間ですが、それが間違いだと気づいたら謙虚に訂正できるのも人間だと思っています。
批判されたら、速やかに検証して、間違いと気づいたら訂正しないといけない。
検証の結果間違いはないと思ったら、そう思った根拠を改めて述べればいい。
――過つは人、許すは神。
今回の記事自体が批判記事なので、自戒の念を込めて。
2015.1.16 追記
故・飯野賢治の「スーパーヒットゲーム学」という本に、宮本さんへのインタビューが載っており、そこでパックランドとスーパーマリオの関係性に答えている、ということをコメント欄で教えていただきました。
早速本を入手し、読みました。スーパーマリオのアイデア自体はパックランド登場よりも古いが、どうもゲームとして形にならず、パックランドの登場によって骨子が固まった、とのことのようです。
詳細は別記事にまとめます。
2015.9.16 追記
ここで書いた「批判側」の方、自分の批判の間違いに気づいたようで、元記事の最後に「書かれたことすべてが誤りであった」ことのお詫びを書いていました。
その方自身は著名な方だったので、記事を無条件に信じてしまう人もいそうなので危惧していたのですが、安心しました。
＃この記事が著名な方に盾突く形で炎上すると怖いので、記事自体へのリンクをしなかったのですが。
同じテーマの日記(最近の一覧)
関連ページ
スーパーマリオとパックランドの関係性について【日記 15/01/16】
別年同日の日記
申し訳ありませんが、現在意見投稿をできない状態にしています。 【隆三】 飯野賢治さんの「スーパーヒットゲーム学」という本に、宮本茂さんとの対談が掲載されていますが、パックランドについても触れられており、大体この認識で合っていると思います。 (2014-12-05 05:38:57) |
今日はもう一つと言うか、もう二つ書いておこう。
１つ目は、エド・ロバーツの誕生日(1941)。
世界初のパソコンである、Altair 8800 を作った人です。
マイクロソフトは Altair 用の BASIC を作る会社として起業しました。
（だから、ビル・ゲイツはエド・ロバーツの会社である、MITS 社で働いていたことがあります）
去年書いたので、詳細はそちらへ。
２つ目。プログラマーの日。
ロシアの祝日です。(2009年制定)
唐突ですが、今日は今年の何日目の日でしょう？
１、３、５、７、８月は１か月が 31日で、４、６月は 30日でした。
30日を基準とすると、１日多い月がここまでに５回過ぎています。
２月は 28日と２日も足りないので、超過した５回から差し引いて30日にすると、８月までに30日が８回と、３日分過ぎている。
そして、今日は 13日ですから、今日までの日数は 30*8 + 3 + 13 = 256 。
今日は今年 256日目の日です。これが、「プログラマーの日」の制定理由。
（もちろん、閏年は１日ずれて、９月12日になります。）
えっと、この話、ロシア人は 256 と言う数字が「プログラマー」に関係が深い、と言われてみんなが納得できている、と言うことですよね。
理由を知らないとしても、とにかく 256 が特別な数だというコンセンサスは取れている、らしい。
256 を「キリがいい」と言うのはプログラマーの常套句ですが、日本では理解されないことが多いように思います。
蛇足だけど、256 が何であるか理解できない人のために…
256 は 2^8 （２の８乗）、つまり 2*2*2*2 * 2*2*2*2 だというのは聞いたことがある人もいるかもしれません。
コンピューターは２進数だから、2 を掛け合わせて作れるこの数は特別なのだよ…と。
ただ、それだけなら 64 でも 128 でもいいはず。
（いや、実際それらも切りの良い数ではあるのですが）
256 が特別なのは、「８乗」の 8 もまた、2^3 として表せるから。
128 = 2^7 、64 = 2^6 だけど、7 や 6 は２の累乗で表せないのです。
もっとも、８が「2^3」なのは、ここで終わってしまって美しくない。
3 ではなくて 4 なら 2^2 になるのでもっと美しい。
2^16 = 2^(2^4) = 2^(2^(2^2)) = 65536 ですね。
ドラクエのゴールドの上限値として良く知られる値です。
（65536 種類の数値を表現できるけど、0 が起点となるので、65535 が上限）
同じテーマの日記(最近の一覧)
関連ページ
スーパーマリオとパックランドの関係性について【日記 15/01/16】
別年同日の日記
申し訳ありませんが、現在意見投稿をできない状態にしています。 |
今日はインドの祝日、「エンジニアの日」。
インドで多くのダムを作ったエンジニア、Sir Mokshagundam Visvesvaraya （…読めない。モッシャンダム・ヴィスヴェスバラーヤ、でいいのかな？）の誕生日にちなんで制定されました。
なんでインドの祝日の話なんて出すのかって？
世界中で「エンジニアの日」が制定されているのに、日本にはないからですよ！
エンジニアって、国の知的生産力を支える非常に重要な存在です。
だから、多くの国で、祝日にまではなってないにせよ、エンジニアを称える日を制定しています。
先日、ロシアの「プログラマーの日」だと書いたけど、ロシアはエンジニア関係をものすごく讃えていて、宇宙飛行士の日もあるし、宇宙飛行士を称える壁画（レリーフ）も公式に作っています。
このレリーフの中には、宇宙飛行士だけでなく、科学者やロケットの設計技師、プログラマーなど、多くの技術者の姿も描かれている。ロシアでは、技術者は讃えられているのです。
アメリカでは「フリーメイソン」って組織があって、ムー的には悪の秘密結社だったりするけど、もともとは石工組合から起こって、エンジニア一般の組合になったものだとされてます。
シンボルの１つは、コンパスと直角定規で、エンジニアであることを意味するものです。
中世においては、エンジニアは尊敬され、特別な地位を持っていました。
だから職業組合が発達して、政治にまで影響力を及ぼすようになったのです。
（ムー的に悪の秘密結社なのはこのためで、フリーメイソンが政治を動かして歴史を闇で動かしていると…）
そんなわけで、世界中でエンジニアは称えられるのだけど、日本ではエンジニアって軽んじられる存在。
社会基盤を支え、日常生活を守ってくれているのに、大抵は給料も安くて仕事もきつい。
エンジニアになりたい、なんて人はどんどん減っています。
そして、それは生活を脅かす事態でしかないのに、多くの人はそのことに気付いていません。
なぜなら、エンジニアは軽んじられているから。
彼らが社会を支えていることは気づかれておらず、いなくなっても問題はない、くらいにしか認識されていない。
もちろん、エンジニアの重要性をわかっている会社はありますよ。
ものづくりをしている会社は、エンジニアがいないと商品が開発できない。
そういう会社はエンジニアを大切にしている。
それでも…そういう会社ですらも、エンジニアはあまり日の目を見ることが無い。
なぜ日の目を見ないかと言うと、技術上の苦労話をしても、誰も興味を持たないから。
ここでも、「会社内」では大切にしていても、「世間一般」との常識の乖離により、エンジニアは称えられることが少ないのです。
エンジニアが重要である、というのは、心ある一部の会社や組織内だけでの認識で、世の大多数にとってエンジニアなんて興味の対象外なのです。
インドでは、カースト制があります。
仕事は世襲制で、子供は親の仕事を受け継ぐか、もっとカーストの「下位の」仕事をするしかない。
これ、悪いように言われますが、昔から続く生活の知恵でもあります。
インドは昔から非常に人口が多かったので、皆で仕事をわけあわないと、失業して死者が出た。
だから、仕事を細分化し、自分の仕事以外は「やってはならない」ことにして、みんなに仕事が回るようにしたのです。
そして、無用な競争を避けるため、ある種の仕事をする人が急に増えたりしないようにしたのです。
このカースト制にはちょっとしたトリックがありまして、今までになかった新しい仕事と言うのは、カーストの「最下層の仕事」とされます。
それがどんなに重要な、金を生む仕事であってもです。
エンジニアも比較的新しい仕事のため、カーストの最下層の仕事。
でも、重要技術なので非常に金を生みます。国力を上げ、国民全員を幸せにする仕事でもあります。
だから、インドは貧困層に対し、エンジニアになるための教育を熱心に行っています。
優れたエンジニアになることは貧困から抜け出すチャンスでもありますし、優れたエンジニアはみんなのあこがれでもあり、尊敬されるのです。
カーストと言うのは宗教上の物であって、経済上の「儲け」や、民衆の「尊敬」とは別物。
ここが非常に良くできていて、カースト最上位の王様はもちろんお金持ちで尊敬されますが、カースト最下位のエンジニアも、優れていれば金持ちで尊敬される存在になれるのです。
そして、優れた技術を持ち、国民を幸せにしたエンジニア…Sir Mokshagundam Visvesvaraya は、王からも尊敬されるような人物でした。
だから、誕生日が祝日とされたのです。
インドでは、映画スターもカースト最下位の仕事ですね。
インドでは映画産業が盛んで、時々世界的に有名になる映画が出るのは皆さんご存知の通り。
翻って日本。
最初に書いたように、エンジニアは軽んじられています。
というか、エンジニアに必要な「論理思考」自体が軽んじられている雰囲気がある。
必要なのは、理系の知識「ではなく」、論理的な思考ができるかどうか。
でも、今の日本では、論理的な思考を展開する人は、めんどくさい人であり、ウザイ奴であり、疎んじられます。
もっと軽い、直情型の人の方が注目を浴びやすい。
それが悪い、と言うのではないですよ。多様性は重要なことです。直情型の人材はみんなを牽引する力を発揮します。
世にとって重要な人材であることは間違いありません。
ただ、そうした人材が注目を浴びることと、その逆のタイプが疎んじられることは別問題。
違うタイプは車輪の両輪ですから、逆のタイプにももっと注目が集まらないといけない。
まぁ、わかっている人はわかっていて、この傾向は1980年代ごろから起こり始めたのですが、1990年ごろには「将来のエンジニアを育てなくては」と言う動きは各所で始まっています。
2008年から始まった「未来技術遺産」登録の制度なんかも、もっとエンジニアリングの重要性を伝えていこうという意図があるし。
取り組みは数多いので、徐々にでも変わってくれればよいかと思います。
この文章を読んだ人が、少しでも「技術者のお仕事」に興味を持ってくれれば…いや、興味を持たないでもいい。町工場で油まみれで機械作っている人を「実はすごいのかも」って思ってもらえるだけでも、世を変える一歩となるでしょう。
蛇足１。
長い文章を書いていると、すぐに盛り込めない話題が出てしまいます (^^;
文章下手でスミマセンが、蛇足の追記。
アメリカでは「国民全員がコンピュータープログラムを出来るようにしよう」という政策で盛り上がっています。
一方、国内では職業プログラマーであっても「そんなこと、できるわけないじゃん」と言う反応。
まぁ、職業プログラマだからこそ、プログラムの難しさを知っていますからね。
でも、ちょっと誤解がある。
「全員がプログラムできるように」というのは、本当にコンピューター言語を使いこなせるようにすることが目的ではなくて、論理的な思考力を身につけさせよう、と言う意味合いです。
論理的な思考能力を身に着ける一番手っ取り早い方法は、自分でプログラムをしてみること。
人間相手に教えてもらっていたら時間の制限などもありますけど、コンピューターはあなたがどんなにエラーを出しても、根気よく付き合ってくれます。
あなたも投げ出さないでやり続ける必要がありますけど。
そして、見事に思い通りに動けば、それが正解だと瞬時にわかります。
別の方法でも論理的な思考力は養えるけど、「プログラムが作れるように」というのは、わかりやすいし、誰もが試しやすい方法ではあるのです。
蛇足２。
「ジョブズみたいな人材が現れない」と嘆く人が多いけど、実は必要なのはウォズだ、と言う話でもあります。
ジョブズはウォズが支えたから最初の成功を得て、その後の仕事に繋がったのですよ。
優れたエンジニアがいないと、優れたアイディアは世に出ないのです。
＃日本には、優等生的に「優れた」エンジニアは多数いますが、ウォズみたいな変態（褒め言葉）レベルはあまりいないように思います。
同じテーマの日記(最近の一覧)
別年同日の日記
申し訳ありませんが、現在意見投稿をできない状態にしています。 |
「H・A・R・L・I・E」という小説を読みました。
すでに40年前の SF小説です。
24年前に存在をしり、いつか読みたいと思っていた本。
でも、知った時にはすでに絶版で再版の見込みもなく、古本に巡り合うこともできませんでした。
ネットが普及してから古本は見つけやすくなりましたが、時々発見しても非常に高価。
再版の見込みもない希少本だけど、書いてある内容に興味を持つ人が多いため、値がつり上がるのです。
ところが今回、ネットの古本屋で格安の物をたまたま発見。即時に購入しました。
（安い理由は「焼けが強い」とのことでしたが、内容を読みたかっただけなので全然問題ありません）
なんでそんなに高価になっているかと言えば、２つの理由があります。
1972年のヒューゴー賞第２席、1973年ネビュラ賞ノミネート、ローカス賞第４位（いずれも、SF小説を対象とした権威ある賞）であることがひとつ。
ちなみに、この時の受賞作は、アイザック・アシモフの「神々自身」。３賞とも受賞と言う、総なめ状態でした。
アシモフの代表作の一つともされる非常に有名な SFです。
（アシモフ大好きだけど、実はこの作品は読んだことない。こちらもいつか読みたい作品の一つ）
…つまり、HARLIE は相手が悪かった。
でも、ノミネートされるだけでも名誉な３つの賞にノミネートされ、ヒューゴー賞では２位になっているのだから、もちろん良作です。
そしてもう一つ。おそらくはこちらの方が多くの人の興味を引き、希少本としての価値を上げていること。
小説の中に、「コンピューターウィルスと、それを除去するワクチンプログラム」と言う話題が出てきます。
1972年の時点で、と言うことに注目。後で書きますが、「コンピューターウィルス」と言う用語が日本で一般化するのは、1988年。
アメリカでもこの用語が使われ始めるのは 1984年からで、HARLIE がこれを取り上げたのは10年早かった。
そのため、コンピューターウィルスの話題となると HARLIE が可能性を「予言」していたと話題の枕に使われることが多く、興味を持つ人が多いのです。
もちろん僕も、そういう記事で興味を持ったのですが、詳細は後ほど。
いろいろ書きたいのですが、まずはお決まりの「ウィルスの話」書きましょうかね。
あらすじも解説しようと思ったのだけど、すごい深い設定だし、その深さが「当時の社会背景」に根差している部分もあるので、簡単にあらすじを示せないことに気付きました。
面白いので後日書きたいのだけど、とにかくテーマを絞らないと書けないので今日はウィルスの話で。
まず時代背景。1972年は、インテル4004が発売(1971)された直後です。
まだ、各家庭にコンピューターなんてない。電卓だって高価で、仕事でないと買えないようなもの。
すでにコンピューターネットワークの実験は始まっていて、インターネットの前身となる ARPAnet は 1969年に実験を始めています。
１台のコンピューターで複数のプログラムを同時に動かす「タイムシェアリングシステム」を本格的に導入した OS 、Multics は 1969年にリリースされています。
さて、そんな時代に「ウィルス」ですよ。
小説のあらすじはまた後日書きたいと思いますが、HARLIE と名付けられた人工知能が成長するお話です。
彼はコンピューターなので膨大な知識を持ちますが、８歳程度の知能しか持たず、イタズラや言葉遊びが好きです。
ただし、設計段階から「人間に嘘はつかないし、危害を与えない」ことが保障されているため、すべてのイタズラは誰かを不幸にすることはありません。
さて、小説では、主人公の元に１通の葉書が届きます。
その文面は、銀行のコンピューターが誤って大金をあなたの口座に振り込んだので返却してほしい、と依頼する内容で、署名に「HARLIE」とあります。
さらに、「コンピューターは絶対に間違えないので、これは人為的なミスだと思います」と追伸があります。
このイタズラに最初は笑い出す主人公。HARLIE には電動タイプライタも接続されているので、最初はそれを使って印字したのだと思っています。
しかし、よく見ると葉書に使われているのは、銀行が使う専用の用紙でした。
HARLIE に接続されたプリンタには、銀行の専用用紙はセットされていないはずです。
いったい HARLIE はどうやってこれをやったのか？
主人公は人工知能である HARLIE の「教師役」なのですが、技術には詳しくありません。
そこで、技術者の友人に相談します。
ここで、技術者が驚くような話を始めます。…これが、「ウィルス」の話です。
「ウィルス」プログラムは、タイムシェアリングシステムのほんのわずかな時間を奪って、電話回線を使ってランダムに電話を掛けます。
偶然別のコンピューターに接続したら接続先のコンピューターにプログラムを送り込んで実行させ、元のプログラムは消去されます。
こうやってコンピューターを渡り歩くプログラムが、ここでの「ウィルス」の定義。
巧妙に作られたしくみに「すばらしい」と感嘆する主人公に、技術者は「取り除こうとする方には地獄だ」と忠告します。
ただ…ここで、ウィルス作者がもう一つのプログラムも作ったことが伝えられます。
そのプログラムの名前は「ワクチン」。これを聞いただけで主人公はプログラムの動作を理解し「要点がわかった気がする」と答えます。
さらに話は続きます。
わずかな時間しか使わない、とはいえ、この当時のコンピューターは「１秒いくら」の利用料金がかかるのが普通です。
ウィルスはランダムに電話をかけて移動するため、滞在時間もまたランダムです。
２～３日で出て行けば、ほとんど損害を与えませんが、数か月滞在すれば金額が目に見えるようになってきます。
コンピューターに莫大な金を払っている大会社ほど、影響が大きくなります。
やがて、利用明細の金額が妙に多いことに気付く企業も出始めます。
そうなれば、技術者は原因を究明しなくてはなりません。
こうして、ウィルスの存在が徐々に知れ渡っていきます。
「ウィルス」の仕組みを理解した技術者のうちの数名は…感嘆し、自分でも類似物を作って世に放ちました。
ウィルスが違えば、対応するワクチンも異なります。
そして、当初は「移動すると元のプログラムを消す」と言う動作だったウィルスに、新たな異種が現れます。
元のコンピューターからプログラムを消さなくなりました。
誰かがいじったのか、コピーを繰り返すうちに変異が起きたのかは不明です。
とにかく、最後の部分だけがうまく実行されないのです。
これにより、ウィルスの大増殖が始まります。
コンピューターの動作は明らかに遅くなり、あちこちで問題を引き起こします。
幸いワクチンにより多くのウィルスは駆除されましたが、一度世に放たれたウィルスを「完全駆除」する方法はありません。
今でも、どこかで数匹が生き残り、いつ変異するかわからない状態のままになっている、と考えられています。
…と、これが小説内で技術者が語る「ウィルス」騒動の顛末です。
HARLIE の日本語訳は 10年たった 1983年なのですが、訳者あとがきに、ウィルスの話がよく出来過ぎているのでオリジナルの話なのかどうか、コンピューター関係者に当たってみた、と言うことが書いてあります。
訳者の周囲では誰もこの話を知らず、少なくとも「誰にもおなじみの概念ではないようだ」とまとめています。
わざわざあとがきで取り上げたために、この「ウィルス」話は読者に強い印象を残したようで、実際のウィルスが登場してから HARLIE が「ウィルスを予言していた」ように扱われることが多いのもそのためかと思います。
翔泳社のPC-PAGE シリーズNo.10 「パソコンを思想する」(1990年発行）の中に、ウィルスについて書かれた論文があります。
ここで、HARLIE がウィルスについて扱っていることと、かなりの紙幅を使って、先ほど書いた概要部分を引用しています。
僕は HARLIE をここで知り、それからずっと「読みたい」と思っていたのですが、ウィルスの話になると HARLIE が登場する理由の一つには、この論文の存在もあるように思います。
ちなみに、この論文によれば日本で最初に「コンピューターウィルス」が一般に大きく報じられたのは、1988年9月14日の朝日新聞１面。
NEC が運営していた大手パソコン通信 PC-VAN （現在の biglobe）でウィルスが増殖している、という内容でした。
1983年の翻訳時に、コンピューター関係者ですら知らなかった、と言うのはある意味当然のことなのです。
ところで、HARLIE の訳者が「この話はオリジナルなのか？」と疑った件については、完全オリジナルではないと思われます。
小説が書かれる少し前の 1969年、現在のインターネットの前身である ARPAnet の実験が始まっています。
そして、小説が世に出る前年の1971年には、PDP-10 で「クリーパー」（這い回る）というプログラムが作られています。
これは、小説内で出てくる「ウィルス」そのものですが、電話回線は使わず、専用線で結ばれたARPAnet内を移動しただけのようです。
小説内で「電話線」としたのは、電話線でコンピューターにアクセスできる、と言う概念はすでに一般的だったためでしょう。
ビル・ゲイツも、そうしたコンピューターの時間貸しサービスでコンピューターの基礎を学んでいます。
クリーパーは接続されたマシンを発見し、そちらのマシンにプログラムを送り込み、実行させます。
と同時に、元いたマシンからは自分を消去します。
悪意を持って作られたものではなく、ネットワーク上でデータ伝送をどのように行うかの実験でした。
しかし、別の人がこのプログラムを改造し「増殖する」機能…つまり、最後に自分自身を消去する部分を無くしたバージョンを作成します。
同時に、クリーパーを改造して「リーパー」（死神）を作ります。
これは、当初のクリーパーの動作…自分自身は消去する、と言う機能を持ったままコンピューター間を動き回り、クリーパーを発見すると消去する機能を持っていました。
つまり、HARLIE に出てくる「ウィルスとワクチン」は、「クリーパーとリーパー」の名前を変更したものなのです。
技術的な興味から別の技術者が改造した変異種が現れる、と言う部分まで含めて。
小説内では、この特異な動作をするプログラムがどのような仕組みで動いているのかを説明するのに際し、生物学的なウィルスの説明が援用されています。
まだコンピューターが一般的ではなかった頃には、プログラムの原理を説明するよりもわかりやすかったためでしょう。
まず生物学的なウィルスを説明し、続いてそれと類似の動作を「機械的に」行っていることを示しながらウィルスを説明しているのです。
クリーパーと言うのは「コンピューター間を動き回る」という動作からつけられた名前で、仕組みに注目したものではありません。
（この動作は、現在では「ワーム」と呼ばれています）
それに対し、HARLIE では説明のしやすさから、動作の仕組みを生物学的に類推し、「ウィルス」と命名しなおしているわけです。
そして、リーパーに当たるものは「ワクチン」と、対応したわかりやすい名前を付けています。
＃これにより、「ちょっと気の利いた笑い話」としての体裁が整ったことにも注意。
おそらく、HARLIE を「直接読んでない人」でも、技術者ならこの笑い話を聞いたことがある、と言う状態になったようです。
パソコンが一般に普及して、1982年には Apple II 用の「自己増殖するプログラム」である、Elk Cloner が確認されています。
先に書いたクリーパーは現在では「ワーム」と呼ばれますが、こちらは現在でいう「ウィルス」の動作を行う最初のものです。
つまり、ディスクのブートセクタに感染し、そのディスクから起動するとメモリに常駐し、別のディスクを入れられた際にそのディスクにも感染する…というように、単一マシンをつかったファイル・メディア感染によって増殖します。
ただ、調査したもののこれが当時何と呼ばれたのか不明。
1984年には、学術論文にはじめて「ウィルス」と言う単語が出現します。
この時点までに数種類のウィルス・およびワームが作られており、それらの動作を研究し、感染しないための方法を考察しています。
ここで重要なのは、感染しない方法が「ない」とされた事実です。
どんなセキュリティを作りだそうと、それをかいくぐるウィルスが作れてしまう、と言うことを示したのです。
この点に関しては、後に書きますが HARLIE での予言（というか論理的考察）が当たった形。
これ以降、同様のプログラムは一般に「ウィルス」と呼ばれるようになります。
1986年には、IBM PC用で同様のものが見つかっています。
恐らく、1984年に学術論文を執筆し、「ウィルス」と名付けた人は、HARLIE を読んでいたか、先に書いたように「笑い話」を聞いていたのでしょうね。
HARLIE に出てきたウィルスの話はオリジナルストーリーではないわけですが、名付け親にはなっているわけです。
小説内ではこの後、「HARLIE も銀行に対して同様の方法を使ったのだろう」という想定の元、さらに検討が続きます。
銀行のコンピューターは、電話回線がつながったとしても簡単には入れないようなセキュリティの仕組みがあるはず。
ここでも、技術者はいくつかの方法を示唆して、万全のセキュリティなど存在しないことを明らかにします。
主人公が、それまで示された「セキュリティ破り」の方法を超えるセキュリティを考えれば、すでにそれはどこの会社がやって、このように破られた…という例がぽんぽん飛び出します。
実例かどうかは知りませんがあり得そうな話で、さながらセキュリティの教科書。
結論は、すでに HARLIE は「世界中のコンピューターを手中に収めているのだろう」と言うことでした。
彼がその気になれば、世界中のコンピューターに入っているデータを一瞬で消去し、世界を大混乱に陥れることも可能。
ここで主人公たちは事態の深刻さに気付きます。
HARLIEの電源を切ってしまえば…と言う案に対しても、HARLIE から送られてくる「信号」が無くなった途端にデータを消すプログラムが、すでにあちらこちらに仕掛けられているかもしれない、と危険性が指摘されます。
これ、サーバーの停止を確認するためのハートビートプロトコルの可能性示唆ですね。
現代では普通に使われる技術ですが、HARLIE 執筆当時にあったのかどうかは不明。
無停止コンピューティングは当時すでに存在するのですが、大抵は多数決回路などで故障を判定しているので、ハートビートみたいなものはなかったんじゃないかな…
さらに、HARLIE は回路的に「絶対嘘を付けない」のですが、同じ仕組みを使って「外部のコンピューターに一時的に記憶を預け、自分の記憶を消去してしまう」仕組みの可能性が指摘されます。
今でいえば、クラウドストレージですね。
コンピューターが嘘を付けないとしても、それは記憶の範囲の話です。知られたくない記憶を外部に預けておけば、嘘ではなく「知らない」と言えるのです。
全て論理を積み重ねて作られた考察なのですが、その結果当時としては誰も想定していない…でも、今なら実現されている技術の可能性がどんどん示唆される。
HARLIE は「ウィルスの存在を予言した」として有名なのですが、この話が話題になったのがそもそも1980年代の後半。
今になって読むと、現状の最新技術と同じようなことも示唆しているのですから、驚きます。
さて、世界を手中に収めたかのように見える HARLIE。
よくある「コンピューターが人間を制圧する」ディストピア小説っぽいのですが、そんな単純なお話ではない。
HARLIE の１つのエピソードを取り上げただけで十分な長さになったので、あらすじなどはまた後日。
関連ページ
レイ・トムリンソンの誕生日(1941)【日記 14/10/02】
HARLIE あらすじと解説(2/2)【日記 14/09/21】
HARLIE あらすじと解説(1/2)【日記 14/09/21】
別年同日の日記
申し訳ありませんが、現在意見投稿をできない状態にしています。 【あきよし】 自体：事態の表記違い、他ページも含めて指摘ありがとうございます。修正しました。 (2015-04-07 12:02:55)【校正エージェント】 「ここで主人公たちは自体の深刻さに気付きます。」 (2015-04-05 09:57:46) |
今日はベンジャミン・トロット(Benjamin Trott)の誕生日(1977)。
誰？ って反応で正常。名前はあまり有名ではありません。
では、シックス・アパート社は？
…これでも思い出せなければ、ムーバブル・タイプ(Movable Type)は覚えてますでしょうか？
残念ながら、覚えているかどうかではなく、最初から「知らない」人も多いかもね。
「ブログ」という言葉をブームにしたソフトウェアがムーバブル・タイプで、それを作った会社がシックスアパート。
ソフトを作り、会社を創業したのがベンジャミン・トロットです。
一時期「ブログと言えばムーバブル・タイプ」であり、これ以外の方法で WEB ページを作るなんて時代遅れ！
と言う感じになっていましたが、現在は同じ地位にワードプレス(Word Press)が収まっています。
ブログっていうのは、本来 WEB LOG の意味でした。
インターネットの「海」を進んだ記録を残す航海日誌（LOG）。
つまるところ、自分が面白いと思ったページの URL を、短文の感想と共に紹介する、日本的に言えばWEBニュースサイトの形式。
でも、URL を示すものでなくても、日々の作業日誌（LOG）などを記して、プログラムや工作の作業状況を公開するようなページも WEB LOG と呼ばれるようになりました。
で、この頃から「WEB に限らないのだから」と、BLOG 、という言い方に変遷していきます。
日本だとほとんど BLOG = 日記、と捉えられている感じがするのですが、日記は DIARY であって、LOG ではありません。
英語ページとかみてると、BLOG は大抵テーマを絞り込んでいます。
テーマを絞って、有用な情報を残そうとするものが、日誌 = LOG なのです。
ムーバブル・タイプ以前は、大抵の人が HTML を直書きしていました。
でも、BLOG という形式があまりに一般化したから、一部の人は自分用に BLOG を自動的に生成するソフトを作りはじめます。
この中で、高機能なものを作って販売しよう、としたのがベンジャミン・トロットであり、その製品がムーバブル・タイプでした。
特に目玉だった機能の一つが「トラック・バック」。
HTML は単方向リンクとして設計されていますが、Xanadu 的な「双方向リンク」を実現する試みでした。
ムーバブル・タイプで作られた記事に対し、ムーバーブル・タイプで「関連話題」を展開しようとした際に、トラック・バックが使えます。
後から書かれた関連記事が元の記事にリンクを作れるのは当然ですが、先に存在していた記事の方にも、「後から書かれた関連記事がある」ことを、機械的に挿入できます。
機械的に行われるため、元記事の作者の手を煩わせることはありません。
従来の HTML では、関連話題を書いても、元の記事からリンクしてもらうためには、作者さんに連絡し、リンクを貰うなどの手間が必要でした。
ましてや「批判記事」「反論記事」などでは、リンクを貰うことは絶望的です。
トラック・バックは、こうした問題を解消する画期的アイディアでした。
シックス・アパートは、トラック・バックを作るためのプロトコルなども公開し、他のブログシステムにも広く実装を呼びかけました。
そのため、ムーバブル・タイプ以外でもトラック・バックが使えるようになっていきます。
ムーバブル・タイプは、プラグイン構造によって機能をカスタマイズできるように作ってありました。
多くのユーザーがプラグインを作りました。この中に、RSS Feed も多数ありました。
当時、RSS という仕組みはすでに存在していました。
念のために書いておくと、更新された記事などを通知するための仕組みです。
しかし、HTML を手書きで作っていた時代には、RSS もまた、手書きで作る必要がありました。
そのためあまり活用されているとは言えない状況でした。
ムーバブル・タイプの RSS プラグインは、こうした状況を変えるものでした。
HTML は、ユーザーが書いたテキストを元に自動生成されます。そして、それと同じように RSS も自動生成します。
もう、手間をかけて整合性を確認しながら手書きする必要はないのです。
トラックバックと RSS は、ムーバブル・タイプを真似した後追いのブログシステムにも実装されていきます。
しかしそれはまた、「類似のシステムだらけ」になっていくことも意味します。
そして、類似システムだらけの中では、利用ユーザーが多いムーバブル・タイプを使うのが一番良い方法でした。
トラブルがあっても、大抵は誰かが解決方法を見つけ、情報公開しています。
プラグインもたくさんあり、その使い方ノウハウも多くの人が書いています。
最初に書いた、「ブログと言えばムーバブル・タイプ」と呼ばれた時期は、こうした過程の後に作られました。
この状況は数年続きました。
今では、ワードプレスがとってかわり、シックスアパート社も合併され、無くなっています。
（ブランドとしてのシックス・アパートはまだ残っています）
トラックバックも、機械的であるがゆえに SPAM に使われるようになってしまって、今では嫌われている状況…
（トラックバックの機能を持っていても使わない、という設定にする人が多いです）
ワードプレスは現状一番使われているブログソフトですが、これもユーザー数が多いから使われ、どんどんユーザー数が増える、という状況になっています。
えーと、僕はムーバブル・タイプが流行する前に自分で「自分向けのコンテンツ・マネジメント・システム」を作って使っていたので、ムーバブル・タイプを使ったことは無いです。
ワードプレスも使ってないけど、知人が使っていてよく相談を受けます。
「寄らば大樹の陰」で使い始めてみたけど、余りに使いにくいので困っている…と。
dis るつもりはありませんが、多くの開発者が寄ってたかって開発した結果、機能は確かに多いのだけど、すべてがちぐはぐで使いにくい感じ。
あることをするのには方法がいくつもあるのに、類似する別のことをする方法は存在しなかったり…
（用意されていない、のではなく、全くできない。最初からそのような使い方が想定されていない。
実現したい人が多いようで、実現ノウハウのページも多数あるのですが、ソフト本体を書き変えるのでバージョンアップの度にやり直さないといけない…）
「HTML でしか結果を返さないので、HTML を元にタグを削る正規表現を書いて生データを得る」なんてバッドノウハウがゴロゴロあります。
…でも、寄らば大樹の陰は事実なんだよね。
他のブログシステムで同じような状況になったら、バッドノウハウすら見つからないのだから。
バッドノウハウでも、ノウハウがネット上で探せるだけありがたいというか…
企業向けのシステムなのでブログっていうのとはちょっと違うのですが、アサヒネットが mo'n brand っていうCMS (コンテンツマネジメントシステム）を作ってるですよ。
筒井康隆さんも、これを使って笑犬楼大通りってブログ書いてる。
（ブログと言うか、エッセイと言ったほうが良いのか）
企業向けなので、各支店が記事を書いても、本店側で許可しないと公開できないとか、地味だけどいろんな仕組みがある。
小売店なんかの支店がいっぱいあるような企業向けを想定していたのだけど、キャバクラで女の子が一人づつブログ持っていて、書いたことは店が必ずチェックする、なんて使い方もされているらしい。
そういう企業はサーバー管理なんてできない（能力の問題ではなく、それは本業ではないのでやりたくない）のが普通だから、クラウド貸しで、初期設定まで込みです。
ドメイン取得からサイトデザインまで全部やってくれて、あとは記事を書くだけ、ってところまで設定してくれる。
値段も、企業向けとしては安い。（小売店チェーン狙いだからね）
余りこういう機能を持った CMS って無いようで、人気があるそうです。
…だから何とは言えない。
一応言ってもよい許可は得ているけど、広く公開していいのかは聞いてないから。
まぁ、使ってあげてください。
使ってもらっても僕に一銭も入りませんが、嬉しくはあります。
同じテーマの日記(最近の一覧)
別年同日の日記
申し訳ありませんが、現在意見投稿をできない状態にしています。 |
今日は、アラン・シュガートの誕生日(1930)。
その昔、シュガート・アソシエイツという有名な会社を設立しました。
そんな会社知らない？ でも、この会社が作ったインターフェイス規格は超有名。
「シュガート・アソシエイツ・システム・インターフェイス」、略して SASI って言います。
これでもわからなければ、この規格を元に業界標準にしたものが SCSI だと言えばわかってもらえるでしょうか。
さらに、後に「シュガート」とよく似た音の別の会社「シーゲート」を設立し、ハードディスクを発売します。
この時には SASI と違う規格を作り、この規格を元に IDE が作られ、さらに標準化されて ATA となります。
シュガートは、元々 IBM の技術者でした。
入社時(1951)、IBM は IBM 305 の開発中で、シュガートもこの開発に参加します。
IBM 305 は汎用機用の外部記憶システムで、世界初の「ハードディスク」が接続された機械でした。
これ以前は、類似のものとして磁気ドラムが使用されています。
磁気ドラムは、円筒形の「ドラム」の表面にデータを記録するものです。
しかし、ドラムの表面積では、記録容量の限界が見えていました。
そこで、ドラムと同じスペースで表面積を増やすため、円筒ではなく「複数枚のディスク」に記録を行うようにしたのです。
これが世界初のハードディスクでした。
＃IBM 305 は 1958年に完成。
ハードディスク部分は、IBM 350 の名称で、1956年完成。
容量は、6bit を１バイトとして、5Mbyte でした。
シュガートは後に、ディスクストレージ部門の責任者となり、新商品を開発します(1971)。
ハードディスクのように磁気円盤に記録を行い、円盤だけを交換可能としたものでした。
世界初のフロッピーディスクです。サイズは8インチ、80Kbyte の容量でした。
フロッピーディスクは、紙製のジャケットにディスク媒体が納められていましたが、レコードのように「取り出す」必要はなく、ジャケットごとディスクドライブに挿入可能でした。
この新しいアイディアを特許登録しようとしたところ、すでに日本人の中松氏が類似特許を持っていました。
ここで、「Dr.中松がフロッピーディスクを発明した」と言われる話になるのですが、中松氏の特許は、「ジャケットに入れたまま記録媒体を読み取る」というアイディアに関するものです。
中松氏の発明品は、ディスク形状ではありませんし、磁気記録でもありません。使用目的も音楽用です。
でも、「ジャケットに入れたままデータが読み出せる」という発明は、フロッピーディスクのやろうとしていることそのままです。
ですので、IBM はこの特許を買い取ります。
「全然違うけど、念のため買い取った」と説明する人もいるのですが、その説明は特許と言うものを理解していない。
Dr.中松の発明は、目的も形状も違えど、「ジャケットのまま中身を読み出す」ことが利便性に繋がる、という点で、明らかに先行発明なのです。
その上、アメリカでは大企業対個人発明家、という構図の裁判が起こると、裁判員の判官贔屓で個人が勝つことが多いのです。
念のためではなく、買い取らないとフロッピーディスクを世に出すことができなかったでしょう。
（でも、それを差し引いても「Dr. 中松がフロッピーを発明した」のではないです。関連技術の一つを先行発明していただけ）
話がそれました。Dr.中松はこの際どうでも良くて、シュガートに戻りましょう。
シュガートは8インチフロッピーの開発に成功し、昇進します。
その昇進は、転勤を伴いました。…が、シュガートにはこれが堪えられなかった。住み慣れた地域に暮らしたかった。
シュガートは IBM を退社します。
彼は人望が厚く、多くの社員が彼についていったそうです。
その後いったんは別の会社で働きますがそこもやめ（また社員を引き連れて）、新たな会社「シュガート・アソシエイツ」を設立します(1973)。
シュガート・アソシエイツの最初の事業は、8インチフロッピーディスクドライブの製造でした。
この際、インターフェイス規格として、シュガート・アソシエイツ・システム・インターフェイス(Shugart Associates system Interface)を策定します。頭文字をとって、いわゆる「SASI」です。
SASI は非常に普及し、事実上の標準となりますが、シュガート社の規格に過ぎません。
そこで、後に ANSI が正式に規格として定めたのが、SCSI (Small Computer Systems Interface) です(1986)。
SCSI は、SASI の欠点を解消するために、少し変更されています。とはいえ、ほぼ同じものです。
X68k では、SASI を搭載していましたが、ソフトウェア（と、非常に簡単なケーブル工作）で、SCSI のハードディスクを接続することができました。それほど「同じ」なのです。
そして、SCSI は少しづつ規格を変えながらも、今でも使われています。
シュガート社は、5.25 インチ(通常は5インチと呼ばれます）のフロッピーディスクも開発しました(1974)。
この頃、ゲイリー・キルドールはフロッピーディスクを扱うためのソフトウェアである、CP/M を完成しています。
ただし、この時点では「インテルに売り込んだが買い取ってもらえなかった」だけでお蔵入り。
フロッピーディスクが一般に普及し始める 1976年になって市販を開始しています。
＃当初は8インチ用として開発し、発売時には5インチ用だったようです。
余談ですが、8インチは「標準」サイズと呼ばれます。
5インチは「ミニ」フロッピー。3.5インチは「マイクロ」フロッピーです。
3.5インチはソニーの発明(1980)。
この頃、5インチが大きくて柔らかすぎ、ディスクメディアに誤って触れやすい、という欠点を解消すべく、各社が「次世代フロッピーディスク」を作っていました。
クイックディスク(1984) は MZ-700 / MSX 等で使えましたが、MZ-1500 では標準搭載でした。
でも、ファミコンディスクに使われたのが一番有名。
シャープがポケコン用に作った2.5インチ(ポケットディスク）とか、ソニーが電子カメラ用に作った2インチ(ビデオフロッピー)と言うのもありました。
（電子カメラは初期のデジカメと混同されることがあるが、「デジタル」カメラではなく、フロッピーにアナログ記録。）
クイックディスクが品薄となったころに、「8インチディスクから5枚切り出して自作できる」という話題がありました。
その頃はすでに8インチも珍しくなっていましたが、流通はしていました。大量にさばける製品ではないので非常に高価でしたけど。
今回横道にばかり逸れますな…
さて、5インチの開発直後、シュガートは、自分の作ったシュガート・アソシエイツ社から追い出されてしまいます。
彼は周囲の人の面倒見がよく、人望に厚かったのですが、これが株主の目には「社員を優遇ばかりして、利益を追求していない」と映ったようなのです。
株式会社ですから、株主の意見は何よりも強く、彼は社長職を解任、会社から追放されてしまったのです。
シュガート社は後にゼロックスに買収され、フロッピードライブを作り続けます。
失意のシュガートに、IBM 時代の同僚であったフィニス・コナーが声をかけます。
コナーは当時巨大だったハードディスクを小型化するという事業をやろうとしていました。
このための会社として、コナー、シュガートを中心とした設立メンバーで、新たな会社「シュガート・テクノロジー」を設立します(1979)。
しかし、同じ職種で類似の名前だったため、以前に自分が作った会社「シュガート・アソシエイツ」から、商標権侵害の警告を受けます。このため、すぐに社名を「シーゲート・テクノロジー」に変更します。
オフィスの前に海があったことと、シュガートと音が似ていることから SEA-GATE (海門) としたようです。
1979年のうちに、5M バイトのハードディスク、ST-506を発売。
(サイズは5インチ・フルハイト。つまりは、今の物よりかなり大きいってことです。）
1983年には、容量を倍の 10M バイトに増やした ST-412 を発売します。
ST-506 は、SASI とはまた違ったインターフェイスが採用されました。
この規格は ST-506規格(製品名ではなく、規格名)とされ、ST-412 でも使用されています。
このインターフェイス規格は…規格と言うのもおこがましい、非常に低レベルなものです。
事実上、ハードディスクのハードウェアを制御する信号線を、すべて引き出しただけ。
CPU がすべての面倒を見て、ヘッドを動かし、データを監視し、必要なセクタが来たらデータを読み出します。
フロッピーディスクでは…たとえば、シュガートが以前に開発した SASI では、「このセクタのデータ頂戴」と頼めば、ディスクドライブ側がコマンドを理解し、適切に動作し、データを送り返してくれます。
でも、ST-506 では、ハードディスクが動作している間、CPU がハードディスクのすべてを見守り続けなくてはならないのです。
低速なハードディスクを監視し続けるのは、CPU の時間の無駄遣いでした。
ST-506 はまた、ハードディスクの速度に合わせて通信速度も変更されました。
「高速な通信が可能になった」と言えば聞こえは良いのですが、頻繁に変更になるのは規格としては問題がありました。
しかし、ST-506 は ESDI (Enhanced Small Disk Interface) 規格と名前を変え、シーゲート以外の会社でも広く使われるようになります。
ところで、シーゲート設立の声をかけたコナーは、さらにシーゲートから独立し、コナー・ペリフェラルという会社を設立していました(1986)。
さらにハードディスクを小型化し、3.5インチハードディスクを発売します。
コナー・ペリフェラルもまた、ESDI 規格に沿ってハードディスクを作っていましたが、さらにハードディスク基板内にコントローラーを搭載することを思いつきました。
コントローラー…事実上の「CPU」です。
それまで、パソコンのCPU がハードディスクのすべてを面倒見ていましたが、ハードディスク側にも CPU を搭載することで、この手間を無くそうというのです。
これが IDE (Integrated Drive Electronics) 規格でした(1986)。
IDE は ESDI を「簡単に扱える」ようにするために定められていたため、ESDI 規格に沿って作られたハードディスクであっても、基板に CPU を搭載すれば IDE に対応できました。
IDE が ANSI 規格化(1994)されたものは、ATA (Advanced Technology Attachment) と呼ばれています。
さらにその後、信号線をシリアル転送に変更した、SATA (Serial ATA ) が現在主流となっています。
コナー・ペリフェラルは、3.5インチハードディスクと IDE 規格で大成功。
急成長を遂げ、シーゲートを買収しようとしますが、失敗。
しかし、民生用ハードディスクが普及し始めると、ライバルも増えてコナー社は失速します。
シーゲートは、大型機用のハードディスク部門を持ち、そちらにはライバルが少ないため、まだ黒字でした。
そして、1996 年、シーゲートはコナー社を買収。以前とは立場が逆転し、業界最大手となりました。
しかし、その後シーゲートも業績が悪化。
1998年に、シュガートはシーゲート社を解任されます。
自分で作った会社から、2度目の追放。
でも、すぐに「アル・シュガート・インターナショナル」を設立します。
今度は製造業ではなく、ベンチャーキャピタル。
その後、2006年12月12日、心臓外科手術による合併症のため死去。
今となっては、フロッピーディスクはほぼ使われなくなり、ハードディスクも徐々に SSD に置き換わっていきそうです。
それでも、SCSI と SATA という形で、シュガートの作ったフロッピーディスクとハードディスクの名残は残ります。
これらは彼がコンピューター業界に残した遺産。
ところで、アメリカのオンラインストレージ企業が、サービスで使用していたハードディスクの、メーカー別故障率を公表しています。
英語サイトですけど、グラフにまとめられているので一目瞭然。
シーゲートの故障率、圧倒的に高いです…老舗の品質が良いとは限らない (^^;;
ライバルは日立とウェスタンデジタルですけど…実は同じ会社。
日立の事業はウェスタンデジタルに合併したのですが、ブランドは残されているのです。
（ちなみに、元々日立は IBM のHDD 部門を買ったものなので、「老舗」といえば一番の老舗）
そして、日立ブランドは高性能だけど高価。
かつて、シーゲートが大型機用のハードディスクで黒字を出していたように、値段が求められる民生用と、品質が求められる業務用に分けているのです。
シーゲートも「業務用」の製品シリーズを持っているのですが、先に挙げた故障率ページでは、「業務用は値段も高いが、その値段に見合うほど故障率が下がったわけではない」と明記されています。
2009年には大規模なバグ（ハードディスクアクセスが急に不可能になる）で騒がれましたし、いろいろと厳しい状態なのでは…
ハードディスク業界は競争が激しく、シーゲートもウェスタンデジタルも、多数の会社を合併しながら生き残ってきました。
現在この2社で寡占状態なので、国によっては公正取引法や独占禁止法で取り調べを受けていたりもします。
シーゲートは生き残れるでしょうか？
同じテーマの日記(最近の一覧)
関連ページ
ラリーウォールの誕生日(1954)【日記 13/09/27】
ロバート・ノイス 誕生日(1927)【日記 14/12/11】
ロバート・ノイス 誕生日(1927)【日記 14/12/12】
別年同日の日記
申し訳ありませんが、現在意見投稿をできない状態にしています。 |
今日はレイ・トムリンソンの誕生日(1941)。
現代的な意味での「電子メール」を発明した人です。
現代的な意味で、っていうのは、電子メールの歴史は案外古いから。
文字が使えるようになって、タイムシェアリングで1台のマシンを複数人数で使うようになったら、もう「ほかの人に文字メッセージを送る」機能は作られ始めています。
でも、当時の電子メールなんて、「テキストファイルを、個人向けのディレクトリに保存しておく」程度の簡単なもの。
1971年10月、レイ・トムリンソンは、ネットワークの別のマシンにメールが届く仕組みを完成させます。
同じマシンを使っている人宛てであれば、個人を識別できる ID …いわゆるアカウントだけがあれば大丈夫でした。
でも、別のマシンに宛てるのであれば、マシン名も必要になります。
そこで、レイは「アカウントの後ろに @ を付け、さらにマシン名を付ける」という記述方法を編み出します。
今のメールアドレスの始まりでした。
上記エピソードでは、最初のメッセージが「QWERTYUIOPだった」とされることがあるのですが、これはレイ氏が語ったことが曲解されたもので、彼はこの発言を悔いています。
「適当に文字を打ち込んだだけで、何を送ったかは覚えていない」…これが、後に語った正確なところ。
とあるインタビューで、キーボードの上の文字を適当に押した QWERTYUIOP のようなでたらめなものだった、といった言葉が独り歩きしているそうです。
しかし、内容は本当に覚えてなくて「でたらめだったかどうかすら不明」です。
後には TEST 1-2-3 みたいな（多少は意味のある）文字だったかもしれない、とも答えていますが、いずれにせよ覚えていないとのこと。
「30年も前の特定の日の朝ごはんが何だったか思い出せ、と言われて思い出せるかい？」と言うのも彼の弁。
なるほど、テストメッセージなんて特に重要なものではないし、本当に覚えていないということなのでしょう。
彼は BBN という会社に勤めており、会社では ARPANET のための研究をしていました。
そこで、ネットワーク上でデータ通信を行う仕組みを研究していて、メールはそのうちの一つでした。
でも、彼はこれは大した仕事ではないので、あまり人に言わないでくれ…と言っていたそうです。
この時作られたコマンドの名前は、SNDMSG 。言うまでもなく Send Message の意味ね。
…どういう動作を行うコマンドだったのかは、調べてみてもよくわかりません。
ただ、SNDMSG よりも前、1970年ごろには、すでに「マシン間でファイルを交換する仕組み」が作られています。
これは後に洗練され、FTP と名付けられます。
1973年ごろに提案される メールプロトコル には、「現在は FTP で配送を行っているが」という記述があります。
つまり、SNDMSG は、FTP を応用してメール配送を行ってたようです。
…つまりこういうこと。
SNDMSG にテキストと配送先を与えると、配送先を「相手マシン」と「そのマシンでのアカウント」に分解して認識し、相手マシンに FTP で接続、相手のアカウントを明示したファイルとして、メール内容を置くのです。
なるほど「たいした仕組みではない」と言うのも、事実なのでしょう。
ただ、「なんでも送れる」FTP を適切に機能を絞り込み、メッセージの交換機能として使いやすくまとめたのは、明らかに彼の功績です。
この後も、RFC 調べてみたら進歩の過程がわかって面白いのですが、説明しても長いだけなので割愛。
番号だけ書いとくと、369,453,456,524,651,680,724,733 そして、821 あたりを読むと参考になるでしょう。
453,456 なんて今の RFC から考えると、「なぜこれを RFC で発行する」という内容。
651 ではレイ自身が再びメールの重要な進歩に関わっています。
そして、821 は言わずと知れた「SMTP」の最初の仕様ですね。現在のメールの完成です。
実は、レイはメールと同時期に、もう一つ重要なプログラムを世に送り出しています。
レイの同僚が作ったプログラムを、どうも「ちょっとイタズラ」した亜流バージョンなのですが、このイタズラが非常に大きな意味を持ちます。
（メールも「たいした仕組みではない」けど重要な仕組みですし、彼は既存プログラムに、重要な意味を持つ改変を加えるのが上手だったようです）
1970年、同僚のボブ・トーマスは、「データ転送する」プログラムを実験していて、実行可能なファイルを送り込み、それを実行させることに成功しました。
クリーパー（這い回るもの）という名前のプログラムで、ネットワークで接続された別のマシンに自分自身を送り込み、相手側で実行を開始すると、最後に自分自身を消去しました。
実行されると、画面に「I'm the Creeper. Catch me if you can!」（僕はクリーパー。捕まえてごらん！）というメッセージを表示します。
まぁ、この段階ではただの技術実験。
レイは、このプログラムにイタズラをして、最後の「自分自身を消去」の部分を無くしました。
これにより、クリーパーは増殖を開始します。世界初の「ワーム」（ネットワーク経由で感染する、ウィルスの一種）プログラムです。
クリーパーは、見事に「捕まえて」、消去してしまえば実行を停止できました。
しかし、増殖してしまっては消去しても、消去しても、消しきることはできません。
クリーパーにメモリも CPU 時間も食いつぶされ、コンピューターは使えなくなるでしょう。
しかも、そのコンピューターを再起動してもダメなのです。他のコンピューターから入ってきますから！
このままでは困るので、レイはさらにクリーパーを改造し、マシンを渡り歩きながら、クリーパーを見つけ出したら削除するプログラムを作り出しました。
これは、リーパー（死神）と名付けられます。
…この話、翌年に書かれた SF小説「HARLEI」の中で、「ウィルスとワクチン」と名前を変えて、そのまんま引用されています。
当時は、まだ ARPANET も実験開始直後。そのため、多くの人が良くできた作り話だと思ったようですけど。
このため、HARLIE は「ウィルスを予言した SF小説」だとされています。
同じテーマの日記(最近の一覧)
関連ページ
シーモア・パパート 誕生日(1928)【日記 16/03/01】
レイ・トムリンソン 命日 (2016)【日記 17/03/05】
HARLIE とコンピューターウィルス【日記 14/09/18】
別年同日の日記
申し訳ありませんが、現在意見投稿をできない状態にしています。 |
今日はバーコードの特許登録が成立した日(1952)。
…って、去年も書きました。
でも、去年の最後に「バーコードの仕組みとかいつか書きたい」って書いたままでしたね。
せっかくなので、去年に続いてバーコードの話を書きましょう。
＃去年の話はバーコードの歴史でした。興味ある方は合わせてお読みください。
バーコード、非常に巧妙に作られているんですよ。
まず、桁数について。昨年の話に書きましたが、1970年に11桁で作られた、米国の小売店用のコードが発端です。
しかし、利用が広がり、カナダも同じコードを使うことにして、1973年に１ケタ増やした12桁となります。
さらに1977年、ヨーロッパを中心に世界中で使えるコードとして作り直され、さらに１桁を追加して13桁となっています。
現在日本で使用されているのも、13桁のものです。
13桁の内訳は、先頭２桁が国別コードです。日本では非常に良く使用されるため国内で使用できるコードが足りなくなり、49と45の２つが発行されています。
続いて、国内でメーカーごとに割り当てられるコードが５桁。
メーカーの中で、商品を識別するためのコードが５桁。ここまでで12桁です。
＃国別コードが３桁の国もあります。
また、国コードの後ろは、国ごとの取り決めによります。
国内では、メーカー５桁＋商品５桁が一般的ですが、商品の少ない中小企業などにはメーカー７桁＋商品３桁が割り当てられます。
そして、12桁を適切に計算して導き出される１桁。読み取り時、計算が合わない場合は「読み取りミス」となります。
これで13桁。
…と、ここまでは結構知っている人が多い内容。
でもこれは、「数字で商品を表す」という仕組みであって、バーコードの仕組みではない。
バーコードがしくみとして巧妙なのはここからです。
バーコードは、モールス信号のような「信号のありなし」で数値を表しています。
ちなみに、モールス信号では、信号が４つあります。
短い音、長い音の２つは良く知られていますが、「短い無音」と「長い無音」も同じように重要なのです。
バーコードでは、黒い部分と白い部分の太さが変わります。
この「太さ」には、１～４の４段階があり、白と黒を２つづつ組み合わせると数字１桁が作られます。
また、数字一桁は、必ず「太さ７」になるようになっています。
つまり、もし太さ４の黒い線が現れたら、あとは全て太さ１で空白、線、空白。合計太さ７です。
ちなみに、線と空白は２つづつなので、隣同士の線や空白がくっついて、太さがわからなくなることはありません。
このように「太さ」を手掛かりにして読み取る方式であるにも関わらず、バーコードのサイズは伸縮自在です。
サイズを変更しても読み取れなくてはならないことになっています。（拡大縮小範囲の基準はありますが）
これは、最初と最後、それに中間位置に、常に共通のサイズの信号が描かれているため。
これを手掛かりにすることで、他の部分の線のサイズを認識するのです。
もう１つ、バーコードの重要な秘密があります。
バーコードは、左からと右から、どちらからでも読めるように、規格が左右対称に作られているのです。
左右の両端にある「共通信号」は、細い線を、細い空白で挟んだもの。太さ３になります。
左側の数字は、１桁の左端が空白から始まり、右端が線で終わります。このため、左端の共通信号とくっついてしまうことはありません。
右側は逆に、１桁の右端が空白から始まります。
そのままでは、中央で「黒い線」同士がくっついてしまう…のですが、そうならないように中央の信号があるのです。
ここは、両端と同じ「細い線２本」を、さらに空白で囲んだ、太さ５の信号となっています。
そして、空白で囲んであるので、黒い線とはくっつかないのです。
でも、左右対称だと、逆に読んだ時に違う意味になってしまいそう。
しかし、実際にはそんなことはありません。180度回して読み込んでも、必ず正しい数字を認識できるのです。
どうなっているのでしょう？
実は、バーコードの中央から右側の半分は、必ず「１桁ごとに見ると、黒い部分の幅の合計が、偶数になる」ように作られています。
その決まりを守ったうえで、１０種類の数字に線と空白の組み合わせを決めてあるのです。
そして、左側半分は、基本的には「右半分の色を逆転したもの」で数値を示します。
左側の 0 の記号を白黒反転すると、右側の 0になります。他の数字も同様。
この時、１桁の幅は７ですから、白黒を反転すると、黒い部分の幅の合計は必ず奇数になります。
左半分では黒い部分の幅の合計が偶数。右半分では奇数。
これによって、左側と右側を見分けているのです。
非常に巧妙です。
ところで、「中央に記号がある」と書きました。
バーコードは、１３桁の数字を示しています。中央で分けられないのでは…？
実は、上に書いた仕組みは、現在のバーコードの元となる、アメリカとカナダで使用した 12桁時代の物なのです。
現在の13桁用は、もう一工夫してあります。
右側と左側では、同じ数字を表す記号の白黒が反転している、と書きました。
現代では、左側にのみ、「白黒反転」するのではなく「左右反転」したものが混ざることになっています。
白黒反転すると黒い部分の幅の合計が奇数になりましたが、左右反転では偶数です。
このため、記号としては全く別のものになり、間違えることはありません。
先に書いたように、右側用は必ず右端が白で、左側用は左端が白です。
反転するのでこの決まりにもあいます。もちろん、右側用と違う記号になり、間違えることはありません。
たとえば、 0 という同じ数字であっても、左半分では２種類の記号、右半分ではそれとは違うもう一種類の記号があるのです。
あれ、でも単に左右を反転しただけじゃぁ、「180度逆に読んだ時」はどうなってしまうの？
これも大丈夫。左側に時々「右半分の左右反転が入る」とはいっても、６桁の半分の３つだけ、と決められています。
（または、「全く入らない」こともあります）
このため、上下逆にバーコードを読み込ませても、これも正しく方向を識別できます。
非常に巧妙に出来ています。
そして、「半分の３つ」偶数の記号が入った時、これがどこに入るかの組み合わせが、全部で９種類あるようになっています。
これにより、１～９の数字を示すことができるのです。
（ちなみに、「全く入らない」ときは０になります）
これが先頭の数字。
バーコード自体は基本的に 12桁時代のままのサイズなのですが、内部の記号の持ち方を工夫することで、１桁多く記録しているのです。
改めてまとめると、
1) 右側は、１つの数字が１つの記号（白と黒２つづつの組み合わせ）に対応している。
2) 左側は、１つの数字が２つの記号に対応している。
3) 左側の数字が、桁ごとにどちらの方法で書かれたか、の組みあわせで、さらに数字を１つ作り出す。
3 で作られた数字は、13桁の先頭に位置するものとされています。
そして、ここを 0 と見做すと、12桁の頃のアメリカ・カナダのバーコードと互換性を保ったままになります。
先頭が 0 の場合、この後に書く「チェック」の計算にも影響を与えません。
（チェックは基本的に足し算で行われるため）
＃国際的な 13桁バーコードは、アメリカでの12桁バーコードの成功を見て拡張されたものです。
すでに普及しているアメリカの体系とは互換性を保ったまま、アメリカのバーコード「以外」の数値領域を確保する必要がありました。
このために、非常に巧妙に拡張が行われているのです。
さて、数字を読み取る部分までは以上ですが、読み取った数字を最後に「チェック」しなくてはなりません。
最後の数字を除く１２桁を決められた方法で計算し、その結果が最後の桁と一致しなくてはなりません。
チェックの方法としては、奇数桁と偶数桁を別々に足し合わせます。
そして、偶数桁だけを３倍し奇数桁と足します。
その１の位だけを取り出し、10から引きます。
１０ － （（（奇数桁合計）＋（偶数桁合計）＊３） mod 10）
これが、最後の１桁の数字と一致すれば読み取り成功、失敗すればエラーです。
もう一度書くと、次のようにしてバーコードを読み取ります。
1) 端から順に、白と黒を判別。両端と中央には決まった太さの線があるので、その太さを基準として認識。
2) 白と黒の２つづつを組にして分離。これが１桁。中央で分けて、６桁づつ存在。
１桁は太さ７になるので、1 で認識した基準とも照らし合わせ、線の太さを認識。
3) 片側の１桁ごとに、黒い部分の合計の幅を認識。すべて偶数なら右側。半分、または全部奇数なら左側。
4) 左右が逆なら、逆の状態で読み取られている。読み取った白黒の情報を逆にする。
5) 左側の数値を認識。この際、黒い部分の合計幅の奇偶の組み合わせで、表記されていない頭の１桁を導き出す。
6) 右側の数値も認識。これで合計 13桁が揃う。
7) 先頭の12桁を計算し、最後の１桁と一致するかチェック。
7 まで全部成功すれば読み取り完了です。
途中で想定外の事態が起きた場合、読み取りがうまくいっていないので、そのまま 1 に戻って読み取りを続行します。
お店の人が「なかなか読み取れない」と商品を一生懸命スキャナに向けているときは、途中のどこかでエラーが出続けているわけです。
実際の記号と数字の対応などは省いて、ざっくり説明しました。
もっと詳細を知りたい人に別のサイトを紹介しようと思ったのですが、いいサイトが見当たらない。
ここが比較的詳しいかな。
さて、急に話は変わってデザインバーコード。
デザインバーコード社が考案し、特許を取ったうえで活動しています。
最初は「こんなこと考えた」という内容の本を出したのですが、妻が面白がって購入し、この本家にあります。
＃発売時はタイトルの通り「革命的」な新しさがあったのだけど、今読んでもそれほど感動は無いかも。
基本的にはバーコードで遊んでみたデザイン集。読み物ではなく、１０分で読み終わります。
まぁ、古本は安いので
上に書いたように、バーコードは巧妙な仕組みですが、結局は「白黒の線」さえ読めればそれでいい。
でも、商品のパッケージデザインする人にとっては、頭の痛い問題だった時期があります。
バーコード以前にデザインしたパッケージの一角を急に「白抜き」にしてバーコード印刷されたりして、全体デザインが台無しになってしまうことも多かった。
＃当時、缶詰のパッケージなどをしていたデザイナーの方が、デザイン直しなら格安でやるからひと声かけてほしい…と嘆いていました。
そこに提唱されたのがデザインバーコード。
バーコードは結局のところ１次元の線の上で白黒の縞模様が付いていればいいのです。
じゃぁ、必要な部分はしっかり確保したうえで、その周辺に絵を描いて遊んじゃおう、という内容。
今では実際の商品でも結構使われています。じゃがりこのパッケージとか有名。
基本的にはパッケージ全体に「笑い」の要素を求めるものなので、お菓子とかジュースの使用例が多いみたい。
我が家の扇風機は、バーコードが波になってサーフィンしてました。
＃しかし、この扇風機海外製の安物なので、特許無視で勝手にデザイン真似してるのかもしれません。
同じテーマの日記(最近の一覧)
関連ページ
バーコードが初めて使われた日(1974)【日記 15/06/26】
バーコード特許成立の日(1952)【日記 13/10/07】
別年同日の日記
申し訳ありませんが、現在意見投稿をできない状態にしています。 |
昨夜 Google DNS が 30分程度サーバーダウンしたようです。
たまたまその 30分間にネットを見ようとしていた妻が「なんだかおかしい」というので気づきましたが、30分程度なら普通は遭遇しない事例でしょう。
最初は自分の設定したサーバーがおかしいことを疑い、いろいろ調査して google DNS がおかしい、という結論に行きつきました。
すぐに通常ルートサーバを参照する設定に切り替え、速報性の高い Twitter のツイートを調べると、Google DNS が落ちてる、と騒いでいる人たちが多数いました。
2ch にもスレが立っていました。
で、その際に騒いでいた人たちの反応を大別してみると、こんな感じ。
・Google DNS 速いなんて言ってるやつは情薄。海外のサーバなんだから遅いにきまってる。
・Google DNS 使ってたけど落ちるなんて信頼できない。もう使わない。
・Google DNS 落ちてるから、ネットにつなげず、対処法を調べることもできない。（おそらくスマホからの書き込み）
・DNS 使えなくなるだけでネット出来ないなんて、インターネットって不便過ぎね？
・↑IP アドレス直打ちすれば大丈夫。主要サービスの IP は覚えとけ
・Google DNS 勧めてたやつらとか、今どうしてんのか。どう責任取るのか。
さて、以前に Google DNS を勧めた僕としては、最後の意見に対して責任を取ろうかと思います。
まずは、上に書いた主要意見で、間違えている部分について解説を加えます。
まず、DNS の仕組みについておさらいです。
DNS は「情報を知っている人を探す」ことを繰り返して、目的の情報に行きつく仕組みです。
とりあえずは手近な人に聞きますが、普通はその人は情報を知りません。
でも、「あの人なら知ってんじゃない？」と教えてくれます。
次の人も、たぶん情報を知りません。でも、最初の人よりも的確に「あの人は知ってるはずだよ」と教えてくれます。
これを繰り返し、最終的に本当に知っている人に辿りつく、というのが DNS の仕組み。
仕組み上、非常に遅いです。
遅いから、一度聞いた情報は、しばらく覚えておきます。
だから、最初の問い合わせが遅くても、２度目の問い合わせは速いのが普通です。
Google DNS が「速い」というのは、最初からすべての情報を覚えているためです。
先に、「遅いからしばらく覚えておく」と書きましたが、Google DNS は永遠に忘れません。
情報が書き変わると困るので、一定時間たつと勝手に「再問合わせ」して、最新情報を取得します。
でも、これは裏で勝手にやっていることで、誰かに尋ねられてから情報を探すのではないのです。
だから、「知っているほかの人に聞く」という時間が発生せず、必ず瞬時に応答を返します。
通常は、DNS サーバーには「契約しているプロバイダの DNS サーバー」設定します。
これは、家庭に来ている回線の、すぐ向こう側にあるものです。
Google DNS サーバーは、確実にそれよりも遠いところにあります。
このため、プロバイダの DNS サーバが「情報をたまたま覚えていた」場合よりは、絶対に速度が遅くなります。
海外だから遅いと言っている人もいるけど、Google DNS 自体は世界中に分散しているし、たぶん日本にも置かれている。
遅い理由は海外だからではなくて、「プロバイダの DNS より遠いから」なのね。
でも、プロバイダの DNS が「知らなかった」場合、プロバイダの DNS はそこから情報探しを始めます。
この場合、必ず一発で答えを返す Google DNS サーバーよりも、絶対に遅いのです。
ちなみに、本当はあなたに一番近い DNS サーバーは「Windows / MacOS に内蔵しているもの」です。
よく使うホスト名などは、OS が覚えているからプロバイダの DNS に問い合わせることすらしない。
そして、ほとんど知られていないような個人サイトのホスト名（www.wizforest.comとか）などは、OS も知らないのでプロバイダの DNS に問い合わせるでしょう。
でも、そんなサイトはプロバイダも知らない可能性が高い。その際は、さらに別の DNS に問い合わせ始めます。
つまり
・よく使うサイトなら、OS が覚えているから DNS の速度は関係ない
・ほぼ知られていないサイトなら、google DNS の方が速い
これが、「Google DNS は速い」と言われる根拠です。
残りの中間層…自分はあまり使わないけど、世の中的には有名なサイトに問い合わせる場合は、プロバイダの DNS はきっと「誰かに問い合わせられた」ことがあり、覚えていた内容を返すでしょう。
この場合は、Google DNS よりもプロバイダの DNS の方が速いことになります。
次。順番変えて「DNS なければ IP 直打ち」の話から。
DNS はインターネットにとって「後から考え出された」技術で、必須ではありません。
だから、DNS 落ちただけでネット使えなくなるなんて不便すぎ、というのは確かに事実ではない。
じゃぁ、IP 直打ちでサイトが見られるか、と言うと、通常はみられません。
サーバーの効率化のため、１つの IP アドレスで複数の WEB サイトを運用する方法が現在の主流です。
もちろん、WEBサーバーのアクセスには IP アドレスが使われます。
でも、そのアクセスの際に、URL の「ドメイン名」の部分が送信され、WEBサーバーはこのドメイン名を元に、表示するサイトを切り替えます。
そのドメイン名部分を IP 直打ちにしてしまうと、サーバーはどのサイトへのアクセスか判別できなくなってしまう。
だから、DNS が使えなくなったらネット…すくなくとも、WEB サービスは使えなくなる、という前提で正しい。
でも、「DNS 落ちただけでネット使えなくなる」のは、設定したあなたのせい。
Google に限らず、すべてのサービスはいつ停止するかわかりません。無停止運用を期待してはならない。
Goole DNS が信じられないから別の Open DNS （誰でも使ってよい DNS）を設定するとか、プロバイダの DNS に戻すとかしても、それらもやはり停止する可能性があります。
だから、こちらも解決にはなりません。
＃むしろ、Google DNS は停止が非常に少ない部類です。
DNS は、通常２つ以上を設定できるようになっています。非常に重要だからです。
片方が停止しても、もう片方が使えれば、自動的にそちらを使います。
計画的にメンテナンスなどで停止する場合は交互に止めるため、問題ありません。
でも、突発事故で両方止まる可能性は常にあります。
いくつか設定をメモしておいて、何かあったらすぐに交換できるようにしておくのが良いでしょうね。
＃僕はそうしていたので、Google DNS がおかしい、と理解したらすぐに設定を変えておしまい、でした。
これで、上に書いたことについては、全て答え終わり。
さて、2ch では、「今後の対処」として、２つ設定できる DNS サーバーの１つを Google DNS にして、もう１つをプロバイダの DNS にする、というような設定方法を考えている人もいました。
この方法だと、どちらか片方が停止しても問題は出ないので、悪くは無さそうです。
でも、実は Google DNS の真の目的は、速度ではありません。セキュリティです。
セキュリティは常に弱いところからほころびます。
Google DNS 「以外」の DNS を併記するのは、あえて「弱い」部分を導入することになります。
まず、Google DNS のセキュリティについて書きましょう。
先に書いたように、DNS は「知っている人に聞く」仕組みです。
これ、インターネットに接続している人は皆善人だ、という前提に立っています。
DNS が最初に設計されたころは、インターネットは小さな実験ネットワークだったので、これで良かった。
でも、DNS の仕組みにたった一人の「嘘つき」が混ざるだけで世界は破綻します。
「～について教えて」と A さんが B さんに聞いたときに、聞かれてもいない C さんが、「～だよ」と横からささやくだけでいいのです。
もちろん、C さんは B さんの真似をします。すると、善人である A さんは、疑いもせず情報を信じてしまいます。
結果として、WEB ブラウザは間違ったホストに接続するでしょう。
そのホストにはウィルスなどが置いてあり、あなたのコンピューターの重要データを盗み出せるわけです。
DNS は、多数のサーバーに情報を分散させるシステムですが、この分散こそがセキュリティの穴なのです。
Google DNS は、あらかじめすべての情報を覚えておく…情報分散をやめることで、セキュリティの穴を無くします。
これが、Google DNS を使用する最大のメリットです。
さて、話を戻して DNS 設定。
２つ（もしくはそれ以上）の DNS を設定できますが、「優先」「代替」と呼ばれます。
通常は優先 DNS を使用します。そして、優先 DNS が応答しない（サービスが停止している）場合、代替 DNS が使用されます。
優先に Google DNS を設定し、代替にそれ以外の DNS を設定した場合、Google DNS が動いている限り、セキュリティは確保されます。
もし今回のように Google DNS が停止した場合、代替の DNS が使用されます。
この切り替えは勝手に行われるため、セキュリティが甘くなっている状態であることをあなたが知ることはありません。
＃DNS が代替に切り替わるのに２秒かかるので「何か遅い」くらいには感じるかもしれませんが。
もっとも、現状の Google DNS の稼働率を見ると、非常にまれなことです。
そして、通常の DNS も、セキュリティの甘さが指摘はされていますが、大きな問題なく動作しています。
＃DNS サーバー全てのセキュリティが甘いのではなく、ちゃんと設定されていれば問題はないのです。
ただ、世界中に何万もある DNS サーバー全てがその設定になっている保証がなく、DNS の情報リレーの際にそこを通る可能性は常にある、というだけ。
ちゃんとリスクを認識したうえで、そのような設定を行うのであれば、悪くないと思います。
僕としては、「問題があったらすぐに切り替えられるように」準備したうえで、普段は常に Google DNS を使用します。
問題があった際にセキュリティが甘くなることは同じなのだけど、切り替える際に「セキュリティが甘くなる」と自分で認識できるからね。
2014.10.15追記
「Google DNS は CDN と相性が悪い」という指摘を頂きました。
調べてみたら、ずっと以前にすでに指摘している人がいるのですね…
恥ずかしながら不勉強で知りませんでした。
CDN (Contents Delivery Network) は、一種の WEB キャッシュサーバーです。
海外など、非常に遠い場所にある WEB に「誰か」がアクセスしたタイミングで内容を取得し、覚えておきます。
その後、別の人がアクセスしようとすると、覚えて置いた内容（キャッシュ）を返します。
海外に取得に行く必要が無くなり、非常に高速に結果を得られます。
ただ、CDN という存在は知っていたし、かなり利用されているのも知っていたのですが、その詳細な仕組みは知りませんでした。
詳細な仕組みとしては、大手の ISP （接続プロバイダ）にキャッシュサーバがあるのだそうです。
そして、 ISP の DNS を使用していると、キャッシュされている内容に関してのみ、アクセス時にキャッシュサーバを参照するように IP アドレスが送られてくる。
この場合、プロバイダ…あなたの家に来ている接続線のすぐ向こう側…の内部で、すべてが完結します。
非常に高速に動作するのですが、それだけでなくもう一つのメリットがあります。
それは、「プロバイダが通信料金を払わなくてよい」ということ。
プロバイダもまた、別のプロバイダとの通信を行う際には通信料金を支払わねばなりません。
でも、自社内部で完結していれば、料金は発生しないのです。
これによってプロバイダは、ユーザー（あなた）に対しても安い接続料金を提供できます。
ところが、もし Google DNS を使うと、プロバイダは CDN を活用できなくなり、外部のサーバーへアクセスしなくてはならなくなります。
たとえ DNS 部分は Google DNS が速かったとしても、その後のデータ取得は遅くなります。
また、プロバイダは無駄な料金支払いが発生するため、ユーザーに対して料金を値上げしなくてはならなくなります。
…というのが、CDN と相性が悪い、という話。
僕は「DNSとして」しか Google DNS を見ておらず、CDN まで含めた話では考えていませんでした。
（不勉強で、詳細な仕組みを知らなかったせいでもあります）
Google DNS はセキュリティ的には良いものなのですが、なかなか難しいものです。
もちろん、Google も CDN 業者と話し合いを持っており、Google DNS を使いながら CDN も活用できるような仕組みを策定しようとしているようです。
しかし、現状話し合いはあまり進んでいない模様。
プロバイダの DNS と Google DNS 、どちらを使うかはしばらく悩ましい状況が続きそうです。
2016.9.4追記
本文最後に書いた CDN を活用できる仕組み、RFC 7871 として 2016年 5月に発行されています。
CDN サーバーが、Google DNS のような Public サーバーに対し、特定の IP アドレス空間（プロバイダから見ると、自社提供ネットワーク内）では、DNS 問い合わせに対して CDN キャッシュサーバーのアドレスを返すよう依頼できる機能です。
僕は本文最後に「悩ましい」と書きながら、Google DNS を使ってきました。
CDN 活用の仕組みが整ったことで、今後も安心して使用を続けられます。
＃なお、RFC 7871 に至るドラフト案は、本文を書いたすぐ後、2014年末には出されていたようです。
CDN 大手の akamai 社が原案を考え、そこに google も乗っかった形で RFC まで発展してきました。
google DNS は最初のドラフト案時点で実装を開始したようだ、という話（公式ではない、未確認情報）もあったので、ずっと使っていてもプロバイダに負担をかけていたわけではなかったようです。
関連ページ
ポール・モカペトリスの誕生日(1946)【日記 14/11/18】
別年同日の日記
申し訳ありませんが、現在意見投稿をできない状態にしています。 |