目次
前のページ
2014-01-15 zepto で clone
2014-01-22 ボタンの左右位置
2014-01-26 iOS の position:fixed バグ回避方法
2014-03-21 iOS の hoverバグ回避方法
2014-04-01 おかしな言語仕様
2014-04-04 ジョン・ネイピアの命日
2014-04-06 ジョン・スカリーの誕生日
2014-04-09 ジョン・エッカートの誕生日(1919)
2014-04-20 フェルディナント・ブラウンの命日(1918)
2014-04-21 ゲームボーイの発売日
2014-05-11 エドガー・ダイクストラの誕生日(1930)
2014-05-16 アイバン・サザーランドの誕生日(1938)
2014-05-19 ジェームズ・ゴスリングの誕生日
2014-05-22 パスワードの管理方法
2014-05-27 ドラゴンクエストの発売日(1986)
2014-05-28 世界初のMML
2014-06-01 シャープのパソコン発売日
2014-06-06 フェルディナント・ブラウンの誕生日
2014-06-08 ティム・バーナーズ・リーの誕生日(1955)
2014-06-15 ジョン・アタナソフ命日(1955)
次のページ
最近忙しくて日記書いてません。
昨年末に、ちょっと新しい仕事を頼まれました。
個人で仕事をしていると、新しく頼んでいただけると言うことは非常にありがたいです。
詳細は秘密保持契約があるので書けませんが、スマホ向けのソーシャルゲームのクライアント側の作りこみの手伝いです。
要は、Javascript でいろいろ動かせばよい、ということ。
zepto というライブラリがありまして、jQuery のスマホ専用版です。
jQuery は便利なのですが、各種ブラウザの差異解消とか、ちょっと便利なセレクタとか、ちょっと便利な関数とかが多くて非常に巨大になりつつあります。
過去には jQuery のプラグイン構造を利用して、各種機能を全部プラグインに別ける…なんて話も出ていましたが、互換性の面から結局全部入りになっている様子。
（内部的には分離されていて、使う人が不要な機能を削ったりは出来るようですが）
で、zepto は jQuery セミ互換で書きなおされたもので、iPhone と Android の標準ブラウザ…つまりは、webkit だけ動けばよい、という考えになっています。非常に小さいです。
と言っても、zepto も開発が進み、徐々に大きくなりつつあります。
とはいっても jQuery よりはるかに小さいのですが、少しでも小さいのが好きな人は、最初のバージョンの zepto を使っています。
先に書いた仕事、スマホ用なので jQuery は使わず最初のバージョンの zepto で、となっていたのですが、納期をすでに過ぎているために細かなことを言っていられなくなり、必要なら jQuery でもなんでも使って良いことになっています。
僕は基本的に zepto で…とやっていたのですが、ほかの人が jQuery を読み込んでいたソースをいじっていたときに、ついうっかり clone を使ってしまいました。
clone 、非常に便利な機能ですが、zepto にはありません。というか無いことを知らずに使ってしまいました。
僕の作った部分を別のファイルでも使うことになり、コピーしたら…うごかない。
clone のためだけに非常に巨大な jQuery を呼び出すのは気が引ける。
というか、最近の zepto には clone あるんですけどね。
当初の zepto にはない。WEB の掲示板でも情報を探すと「欲しければ最近の zepto 使え」というだけで、あまり良い答えがない。
というわけで、作りました。
$.fn.clone = function(){
var ar = [];
for(var i=0;i<this.length;i++){
ar[i] = this[i].cloneNode(true);
}
return $(ar);
}
前ふり長かったけど、これが書きたかっただけだよ…
zepto 読み込んでから、clone を使うまでの間にこれを定義すれば、clone が使えるようになります。
あくまで簡易 clone です。zepto の最近のバージョンでも簡易版しかない。
jQuery の clone はオプションでいろいろあるけど、それはナシです。
関連ページ
iOS の position:fixed バグ回避方法【日記 14/01/26】
別年同日の日記
申し訳ありませんが、現在意見投稿をできない状態にしています。 |
現在お手伝いさせてもらっている仕事で話題になったので、メモ書き程度に。
そのお仕事では、スマホ向けのアプリを作っている。iOS / Android 共用。
なぜか、「OK/ Cancel 位置の入れ替え」という指示があった。
それまでは、OK/Yes/進む などが右に、Cancel/No/やめる などが左にあった。
これを逆にしたいのだという。
なんでそんな指示が出たのかは知らない。
お仕事を手伝っている立場なので、上が決定したのであれば従って作業をする。
でも、その指示がどんなにおかしいものであるかは、ひとこと口を挟んでおいた。
Windows を使っていると、OK は左に、Cancel は右にくる。
恐らくは、指示はこれを踏まえてのことだ。普及している Windows にあわせよう、となったのだろう。
でも、作っているアプリはスマホ向けだ。
iOS では OK は右に来ることになっている。
ややこしいのは Android で、2.x までは OK は左に、だった。
でも、4.0 以降は OK は右に、と推奨されている。このため、アプリの作られた時期により OK ボタンの位置が変わり、使いにくいことこの上ない。
ともかく、スマホでは今後は OK は右だ。
今から OK を左にしたい、と言っている意味がわからない。
（ちなみに、今は締切1週間前だ。こんなことに時間を割いている余裕はないはず。
もっとも、締め切りはもう何度も延長されているため、だれも1週間後が本当の締切だとは思っていない様子）
iOS で OK を右にする理由は簡単で、MacOS がそうだからだ。
じゃぁ、MacOS はなぜ OK が右なのか、といえば、初代 Mac （白黒のやつだ）が作られた際に、熟考の末そう決められたからだ。
Mac の元になった Lisa には、従うべきガイドラインは無かった。
Lisa のアイディアの元となった Smalltalk でも、特にガイドラインは無い。
（そもそも、Smalltalk はそれほど GUI ではない）
このため、操作が混乱することがあり、使いやすさを求めた Mac では、多数のモニタリングテストの末に、使いやすいガイドラインがまとめられたのだ。
（メモリ容量が小さく、同じ部品を使いまわさねばならなかったという事情もある）
文章は左から右に読む。（ここでは、アラビア語圏などのことは考えられていない）
これを前提にすれば、ボタンを2つ並べた時、左側のボタンが先に目に入ることになる。
先に目にしたボタンを押したくなったとしよう。
この時、2つボタンがあるにもかかわらず、最初に目についたボタンを押したのだとすれば、内容をよく理解していない。
そんな状態で先に進んでしまい、戻れない状態になってはいけない。
左側にあるのは、やり直しが利くボタンであるべきだ。
つまり、左はキャンセルにするのが良い。
ボタンは通常一番下に置かれる。
その中でも、一番右に置かれるものは、一番最後に目に入ることになる。
つまり、右側は「次の動作に移る一番最後のもの」だ。
ここに、次の動作を開始するためのものが来るのは、非常に自然なことだ。
そのため、OK ボタンは右側に置かれるのが自然だ、と言うことになる。
主にこれらの理由で、Apple は Mac の作成時に Cancel を左に、OK を右に置くことにした。
このガイドラインは非常に優れた論文でもあり、多くのことを考慮に入れて作り上げられた、素晴らしいものだった。
Apple もその後、このガイドラインを超えるような設計指針は示せていないし、後の GUI デザインの規範となった。
じゃぁなんで Windows は逆なのさ、と言う話。
Mac に対抗して逆にしたんじゃないか、という推測や、訴訟になった際に「似せていない」と主張するためだったという説、単にプログラマが何もわからずに間違えたんじゃないかという説もある。
でも、これは案外根が深い。
DOS 時代をご存知な人は、DOS でもテキストグラフィックでボタンを模倣することがあったのを覚えているだろうか？
なにも、ボタンデザインは GUI だけの特権ではない。テキストだってボタンを表示することくらいできる。
模倣だけでなく、テキスト画面でマウスが使える環境だってあったのだ。
マウスを動かすと、カーソルが文字単位で動く。慣れれば案外使いやすいものだ。
もっとも、これらは Mac 発表以降に作られたものだ。
Mac は 1985 年発表。マイクロソフトは、ワープロや表計算など、よく使われるソフトをまとめた「MS-Works」を発売。
その後、MS-Works は MS-DOS 用に移植されるが、この時に MS-DOS でも GUI を模倣している。
注目すべきはボタンの位置で、OK が左に来る。
なぜか？ この時点では Mac のソフトを移植しただけで、Mac を模倣した OS を作ったわけではない。
対抗して逆にする理由もないし、もちろん裁判対策などではない。
プログラマが何も考えていなかったのであれば、Mac をそのまま真似して OK が右に来ただろう。
当時のこの手のソフトを使っていた人なら、もったいぶらずとも答えはもうわかっていると思う。
当時はマウスがないのが当たり前。
ボタンを押すのだって、キーボードでボタンを「選んで」リターンキーで「押した」のだ。
部品の移動は TAB で行われる。
多数ある部品を TAB で順次選び、「一番最後付近の」 OK ボタンまで進む…だけで一苦労だ。
ここで、ついうっかりよく読まずにボタンを押してしまう、と言う危険性は、まずないと考えてよい。
うっかりミスを防ぐ、という名目で Cancel が左側にある理由などないのだ。
もっとも、わざわざ TAB キーを押して部品間を移動しないでも、大抵はキーボードで動作を選択できた。
Cancel は、ESC キーに割り振られているのが普通だった。
間違えた画面に進んだな、とおもったら、いつでも ESC キーを押せばよい。キーの名前の通り脱出（エスケープ）してくれる。
問題は OK / 保存 / 次へ…などのキーだ。
大抵は、キーの機能の頭文字のキーを押せばよいようになっている。 OK の O 、Save の S 、Next の N など。
そこで、どのキーを押せばよいのかを、素早く探せる必要があった。
…つまり、目につきやすい左側にあるのが操作しやすい。
以上の理由により、MS-Works では左に OK を、右に Cancel ボタンを配置してあるのが使いやすいことになる。
実は、この操作系は Windows 1.0 でも踏襲される。
当時はまだマウスは普及しておらず、Windows はキーボードのみでも操作できるように作られていたのだ。
いや、今だってそうだ。
基本的に、Windows はいまでもキーボードのみで操作できる。
そして、キーボードで操作する前提においては、左側に OK が来ている方が使いやすい。
今ではマウスで操作するほうが多数派だろうし、そう考えると Apple のガイドラインに従う方が理に適っているように思える。
とはいえ、DOS 時代から続く伝統はすでに変えられないだろうし、キーボードでも操作することを考えるとこちらのほうが適切なのだろう。
初代 Mac 発売に当たり、Jobs はキーボードを別売りにしたがった、と言うエピソードがある。
Mac はマウスだけで操作できるようにまとめ上げた環境で、キーボードなどいらない、というのだ。
結局これは見送られたが、Mac がマウスだけで操作できたのは事実だし（文字を入力したいときは、ソフトウェアキーボードがあった）、キーボードで操作させてくれない部分もあって、面倒でもある。
Windows は、DOS から乗り換えることを想定していたため、マウスなどなくても操作できなくてはならなかった。
そのため、キーボードだけでも操作しやすいようにチューンされている。
マウス操作を前提とすると疑問に思うような（今回の話のような）ことも、キーボードで操作しやすいように作ってある、ということがある。
この違いをもっと端的に言うならば、Mac は当初何も持っていなかったが、Windows は DOS 資産の引き継ぎが義務だった。
Mac では理想を追い求めて設計できたが、Windows はそういうわけにはいかなかったのだ。
Windows がおかしい、と責め立てるのは、そもそもの出自を理解していないのだ。
マウス操作なら OK は右にあったほうが良いだろうし、キーボード操作なら OK は左にあったほうがよい。
それが、当時のユーザーが望んだスタイルだったことになる。
どちらも、ユーザーの要望に応えようと頑張った結果、正反対の結論が導かれている。
Mac に対抗したとか、訴訟対策だったとか、そんなちっぽけな理由で逆になっているのではないのだ。
関連ページ
WEBページの検索順位をあげる方法(2/2)【日記 18/10/06】
Windowを閉じるボタンの左右位置【日記 20/08/17】
別年同日の日記
申し訳ありませんが、現在意見投稿をできない状態にしています。 【あきよし】 指摘ありがとうございます。書き間違えていました。記事は修正済みです。 (2014-12-17 10:38:29)【まのん】 ＞そして、キーボードで操作する前提においては、右側に OK が来ている方が使いやすい →文脈から見て、これって「左」ではないですかね？ (2014-12-07 20:37:53) 【nix】 AndroidのOKボタンが左右どっちにあるべきか調べてただけなんですが思わぬ勉強になりましたｗ 記事の事実と右利きの人が多い＋OKのほうが押す機会が多い⇒指に近いほうがいいこともあるので右にOKを配置しようと思います。 (2014-09-16 14:32:07) |
お手伝いしている仕事で、バッドノウハウばかりが溜まっていく気がする…
デザイン上の都合で、CSS で position:fixed が使われていた。
テキスト入力を促す箇所で、画面の真ん中に入力窓が出てくる。
まぁ、ネットではよく見るインターフェイスです。
ところが、これは iOS では「使ってはならない」技だった。
バグ報告があり、たまたまバグが出た個所が僕の担当箇所だったので僕が調べることに。
でも、プログラムのバグではなく、iOS のバグだと判明。
position:fixed では、ページをスクロールさせても、ウィンドウに対して常に同じ位置に要素を表示できる。
常に同じ、というとスクロールさせるのをサボるだけで難しくないように思われるが、話は逆だ。
画面に収まらない大きな板があって、その一部を表示しているのがスクロールだ。
通常の WEB ページは、この方法で作られている。
それを、「常に画面に対して同じ位置」に表示しようとすると、スクロールのたびに位置を計算し続けなくてはならなくなる。
これは結構大変な作業で、iOS では 5 から搭載された。それ以前は使えなかったのだ。
でも、7 になった現在でも、バグが残っている。
バグと言うのはこういうことだ。
先に書いた通り、「スクロールのたびに位置を計算する」のが、position:fixed による表示だ。
ところで、iOS にはソフトウェアキーボードと言うものがある。
キーボードを出すと、画面は上の方に寄せられ、狭くなる。
逆にキーボードを消すと、出ていたときに比べて広くなる。
でも、キーボードが出るのはスクロールではない。要素の位置は再計算されない。
まぁそれでも、キーボードが出て、消えるだけなら元に戻るだけなので心配はいらない。
問題は、キーボードを出している間にスクロールが行われ、その後キーボードが消える場合だ。
狭い画面でスクロールが行われ、その画面に対して要素の位置が計算される。
その後画面を広げても、要素の位置は再計算されず、結果的に本来指定したものとは違うものとなっている。
うん。何も問題はない。キーボードは「表示」されるだけで、スクロールが起きるわけではない。
画面が狭くなるのだからリサイズイベントは起こしてほしい気がするが、これも起きない。
こちらはバグっぽい気もするが、iOS ではリサイズ＝画面の向き（縦・横）変更、というルールがあるので仕様と言うべきなのだろう。
でも、結果的に意図しない画面になっているのであれば、バグだと考える人もいる。
そして、今回がそのケースだった。
試行錯誤の末、次の方法で回避。
問題はキーボードが消えるときだ。
iOS でキーボードが出る条件は、文字入力が行われる時だ。
WEB 的には、INPUT TYPE=TEXT の要素にフォーカスした際にキーボードが出る。
そして、フォーカスが失われるとキーボードが消える。
フォーカスが失われることを、Javascript では blur と呼ぶ。
そこで、INPUT TYPE=TEXT の blur イベントを拾い、画面表示を更新してやれば良い。
画面表示の更新は、しつこく書いたようにスクロールによって起こる。
だから、スクロールしてやれば良いだけ。
この際、blur してからキーボードがアニメーションしながら消え、完全に消えるまでに 0.1 秒ほどかかることを考慮する必要がある。
スクロールすると言っても、blur のたびに画面が動いていくのは困るので、blur の時に下に 1px、キーボードの消え失せた 0.2秒後に上に 1px 動かし、結果としてスクロールは起こらないことにした。
今回の仕事は iOS 用だった。このため、jQuery は「重いから使わない」との判断で、ある程度互換性を持ちながら、機能を削減して軽くした zepto が使われている。
そこで、zepto 用のプログラムは次のようになる。
$(function(){
$("input").each(function(){
if(this.type!="text")return;
$(this).bind("blur",function(e){
window.scrollBy(0,1);
setTimeout(function(){window.scrollBy(0,-1)},200);
});
});
});
window に仕掛けてバブリングしてきたものをキャプチャ出来るといいのだが、残念ながら blur イベントはバブリングしない。
そのため、input を取り出し、type=text のときだけ blur を付ける、という泥臭い方法になっている。
（zepto のセレクタでは input[type=text] のような属性フィルタは使えない）
もちろん、DOM 構築以降に動的生成された input が position:fixed だったりすると困ったことになる。
今回の仕事ではそのようなことは無さそうなので、そこは割り切った。
textarea にも対応させてやるとよさそうだが、そこも仕事では無さそうなので割り切り。
とりあえずこれでバグ回避できた。
関連ページ
別年同日の日記
申し訳ありませんが、現在意見投稿をできない状態にしています。 |
先日、iOS の position:fixed バグについて書いた。
最初は面白がって iOS バグの回避とか、zepto の小技とか書いていたのだけど、実は書いたのは氷山の一角。
iOS はバグだらけで、回避技ばかり作っていたら面白くもなくなり、特に書こうとも思わなくなった。
しかし、iOS の position:fixed の話は参照してくださる方もいたようだ。
じゃぁ、もう少しなんか書いとくか…と思ったけど、いろいろやったはずなのに思い出せない(笑)
回避しちゃうと、バグってのは忘れちゃうもんだから、その場で書いとかないとだめだね。
で思い出したので、hover バグについて。
css で a:hover とかすると、普通はマウスカーソルが乗ったことを感知して絵を変えたりできる。
でも、iOS にはマウスがない。マウスがないけど、タップすると一応 hover は動いてくれる。
しかしこれが、いろいろと厄介な代物なのだ。
まず、お手伝いしているゲームが、「ボタンを押した」ことをユーザーがわかるように、
hover でボタンを光らせようとしたことが発端なのだ。
まぁ、いろいろ CSS を駆使すること前提で、a:hover になると光るようになっていた。
でも、iOS では思ったように動かない。動かない理由はいくつかある。
まず、iOS のバグ。
おそらく Retina ディスプレイと通常のディスプレイのドット数の違いを吸収するプログラムにバグがある。
a:hover が反応するのは、a がタップされたときではない。
a の座標の、ちょうど X Y とも半分の位置をタップされたときにも反応するのだ。
タップした位置を元にすれば、画面左上からの距離が２倍の点に a があれば、hover が反応してしまう。
ただし、反応するのは hover だけで、a がクリックされるわけではない。
また、本来の a の位置にクリックが発生する（iOS の内部処理の関係で 0.3秒後になる）と、そちらにも hover が発生する。
hover で光るボタンがいっぱい並べてあると、タップしたところと違うところが光り、その一瞬後に正しいボタンが光る感じだ。
こうして発生した hover は、指を離しても消えない。
次にどこかに触れ、別の個所に hover が発生すると消える。hover が付いているところは常に一つだけど、その一つは指が離れても付きっぱなしなのだ。
これは、バグではなくて仕様だ。
実は、iOS の hover 動作は、マウスを載せるとメニューが出る、というような、ありがちな操作法のページでも閲覧できるようにするための物なのだ。
だから、１回目のタップでメニューが開き、そのまま開きっぱなしになって欲しい。
２回目のタップでメニューを選ぶと、hover が消えてメニューも消えてよい。
しかし、指を押したときだけ光って欲しい、と言う用途では使えない。
元々 a:hover でボタンを光らせようとした人は、指を押している間だけ光ると考えていたため、先の「押してない個所が光る」問題と併せて、「動きがおかしい。どうにかならないか」と僕に相談してきた。
実は、他にも問題がある。
a タグのように、タップして画面遷移が生じる要素に「表示が変わる」ような仕掛けを付けた場合、タップと同時に hover が発生して、画像が切り替わったまま次の画面に行ってしまうのだ。
他の画面に行くのだから、どんな風になっていようといいじゃない、なんて思ってはいけない。
戻るボタンで戻ってくると、先ほどの「光った」画面のままになっているのだ。
しかも、この際 hover は外れている。
画面遷移している間に hover 状態は変わっているのに、「hover を失った」瞬間に画像を切り替えるタイミングを失ったために、ボタンが光ったままになっている。
これは、画面上に hover は１つだけ、というルールとも関係ない表示上のバグなので、他の個所をタップしても元に戻らない。
光っているボタンを押したうえで、さらに別の個所を押すと消える。
と、いろいろ厄介な問題が hover には多い。
これを回避するのは難しくなく :hover を使わなければよいだけのことだ。
代わりに、hover 相当の動作を javascript で作り出して、class に hover を与える。
すると、:hover の代わりに .hover と書ける。
すでに :hover で書いてしまったところも一括置換で幸せになれる。
具体的には、こういうことだ。
・body や window など、上位の要素に click イベントリスナーを付ける。
たとえ window にリスナーを付けていても、event.target で click が発生した要素がわかる。
・click した要素から parentNode で親をたどり、target.tagName で a タグを見つけたら hover クラスをつけてやる。
僕の例のように a タグではない、別の要素に必要なら、必要な要素につける。
・hover クラスを付ける際には setTimeout で、 hover クラスを一定時間後に消すようにする。
・window の pageshow イベント発生時に、hover class のついているタグを探し出し、すべて hover を消すようにする。（戻るボタンで戻ってきた時の対策）
これでいい。
ついでに、PC で確認できるように、mouseover で同じように hover を与え、mouseout で hover を奪うようなプログラムも作っておくと便利。
class の追加/削除は、jQuery の addClass、removeClass が便利。
target.tagName は大文字なので、 a ではなく A を確認するように。
サンプルコードを見せろ、と言われそうだけど、残念ながらない。
なぜなら、hover の問題と同時に、iOS の click 遅延問題も一緒に解消するようにした巨大なバグ回避ライブラリを作ってしまったから。
大きすぎて簡単に見せられないのだ。
でも、真のプログラマなら上の説明で回避プログラムを組めるはず。
言っていることの意味が全く分からないなら、プログラムだけ示されても適切な改造ができないと思うので、あきらめたほうがよい。
（上の例は a タグにだけ hover が付けばよい、と言う前提で、環境によって改造が必要）
関連ページ
別年同日の日記
申し訳ありませんが、現在意見投稿をできない状態にしています。 |
エイプリルフールなので、と断ったうえで。
プログラム言語は厳密であいまいなところがない、と思われがちだけど、そんなことは無い。
人間が作ったのだから、非常に曖昧で、おかしな規則を含んでいることがある。
そんな例をいくつか書き出してみよう。
C言語と、その影響をうけた数多くの言語（現代のほとんどの言語！）では、10 進数で 0 を書くことができない。
0 なんて、非常に当たり前に使うものだ。そして、C言語は10進数で数字を表記できる。
でも、0 を10進数で書くことはできない。
言語なので、まず語句を識別する。
そして、この語句の先頭が数字で始まっていると、何らかの数値と見なす。
ここで、1-9 の数字で始まっている場合は、10進数と見なされる。
0 から始まっている場合は複雑で、続く文字を見る。
この文字が x なら 16進数。
C言語では使えないが、一部言語では bで2進数も扱える。
これらの規則に合わない場合は、８進数だ。
そう、0 から始まって、他の規則に合わない場合… 単に 0 と書いた場合は、それは10進数の 0 ではなく、8進数の 0 なのだ。
混乱するから数値はすべて 10進数で表記、とか考えている人は要注意。
知らず知らずのうちに、８進数が混ざっている。
そういう言語仕様なのだから仕方がない。
混乱してバグが出ないように祈っておこう。
同じく C 言語では、改行が意味を持たない。
古いタイプの言語…FORTRAN や BASIC では、文の区切りは改行で、非常に重要だ。
C 言語では改行はただのスペースと同じで、区切りは ; を使う。
この考え方はその後の多くの言語（HTML なども）に受け継がれている。
でも、C と一緒に使う「プリプロセッサ」は、改行を認識する。
命令の有効範囲は改行まで、と言うものがほとんどだ。
どうしても長く書きたくて改行が邪魔になるときは、行の最後に \ を入れることになっている。
\ は、その次の文字に特別な意味を与える、という C 言語での表記方法で、行の最後にこれを書くことによって、続く改行の意味を打ち消している。
ところで、C が進化して C++ になった時、改行を活用する命令が追加された。
// で始まる「行コメント」で、このコメントは、改行によって終了する。
じゃぁ、// で始まる行の最後に \ を書くとどうなるのか。
// はコメントなので、その内部の \ を認識してはならない。その一方、\ に続く改行は無視されなくてはならない。
改行は意味を持たないはずの C 言語に、便利だろうと思って改行を区切りとする命令を追加してしまったがゆえに、非常に困ったことになった。
でも、// でコメント、というのは今でも多くの言語に受け継がれている。
大昔、Apple が Mac (68k) 用に発売していた C++ では、マニュアルのかなり最初の方のページで「既知のバグ」として、わざわざこの件に言及していた。
C++ の仕様の穴であり、Apple のあずかり知ったことではない、と言わずにはいられなかったのだろう。
この機能を使ってはならない。何が起こるかはわからない。
どんな言語でも、「0文字の文字列」は表現できると思う。いわゆるヌル文字列だ。
正規表現もまた、文字列で表現される。そして、ヌル正規表現と言うのも存在し得る。
perl だと、ヌル正規表現によって文字列を分割すると、文字を１文字単位でバラバラにできることが知られている。
ヌル正規表現は、活用すると便利なものなのだ。
でも、Javascript では、この便利な正規表現がつかえない。
Javascript では /～/ で正規表現を書くが、 ヌル正規表現のつもりで // とすると C++ 由来の行コメントとなってしまい、以降の命令を無視してしまうのだ。
sed 由来の書き方と C++ 由来の書き方を混ぜてしまったがゆえにこうなった。
混ぜるな危険！ である。
同じような問題は SQL でも発生する。
SQL は、大抵は別の言語の中から呼び出され、ユーザーからは見えない部分でデータを保持するのに使用される。
この時、言語によって SQL の命令の中に数値が埋め込まれたりする。
ところで、「ある数の符号を逆にしたい」ことはよくある。
当たり前の話だけど、変数の前に - をつければ、符号は逆になる。
ところが、すでにマイナスの数だと -- となってしまうことがある。そして、これは SQL ではコメントを意味する。
このため、符号を逆にしようと思ったらコメントが発生してエラーになる、と言うことが起こりうる。
注意しなくてはならない。
その昔、FORTRAN の時代にはパンチカードでプログラムを作った。
パンチカードは80文字しか文字を記録できず、文は必ず80文字以内に書かなくてはならない。
何より、パンチカードは高価だった。
そこで、文字を詰め込んで書いても良い言語仕様だった。
スペース区切りなどいらない。単語を連続して書いても、単語として認識できる綴りであれば問題はない。
それどころか、語句の途中にスペースを入れても構わない。スペースは単に無視して処理されるのだ。
（ただし、文字列定数内のスペースは正しく保持される）
DO 100 I=1,10
WRITE (*,*) I
100 CONTINUE
では、上のプログラムと、次のプログラムは同じものか。
DO 100 I=1.10
WRITE (*,*) I
100 CONTINUE
…残念ながら違う。
何が違うかと言うと、１行目の , (カンマ)が . (ピリオド)に変わっている。
でも、文法エラーにはならず、実行できる。
上のプログラムは、1 ～ 10 の数字を印字するものだ。
下のプログラムは 0 と表示して終わってしまう。
DO 100 I=1,10 は、100行目までの間を繰り返す、その際に I を 1 から 10 まで変化させる、と言う命令だ。
でも、DO 100 I=1.10 は、 DO100I という名前の変数に、 1.10 という実数を代入している。
古い FORTRAN では、変数は１文字目によって「型」が決まり、宣言なしに使用できた。
Integer の I から、Number の N まで… I J K L M N で始まる名前は整数、それ以外は実数。
変数名は６文字までの長さで、初期値は 0、または 0.0 だった。
何とも運の悪いことに、DO100I は６文字の名前の変数であり、実数を代入できた。
だから、1.10 を入れてもエラーにはならない。
そして、I を使用しても、単に初期値の 0 が使われるだけで、こちらもエラーにならない。
これは、計算機言語の設計の話になると、必ず出てくる例だ。
FORTRAN は、その言語仕様上、文法ミスの検出が難しかった。
もちろん、今の FORTRAN では言語仕様も拡張されていて、このような書き方は推奨されない。
でも、互換性のために今でもこの書き方はできるらしい。
lisp では、t nil で真偽を示す。
lisp にどっぷりはまった lisp プログラマは、日常会話でも YES / NO の意味で t nil を使うという。
そして、lisp プログラマはコーヒーを飲めない、という状態が発生する。
アメリカでは、何か飲み物、と言えば普通はコーヒーなので、飲み物がいるかと尋ねられるときは、「Would you like a coffee?」だ。
ここで「t」と答えると、相手はなんと紅茶を持ってきてくれてしまう。
このネタ、いくらでも続けられそう (^^;
でも、すぐに思い出せたのはこのくらい。
あとで追記するかも。
関連ページ
別年同日の日記
申し訳ありませんが、現在意見投稿をできない状態にしています。 |
今日はジョン・ネイピアの命日（1617）。
生まれは1550年なのだけど、誕生日は不明。
ずっと以前に、歯車のページで「ネイピアの計算棒」として取り上げている道具を作った人です。
該当ページを書いたのは、今からもう１７年も前。
当時はこの道具のこともネイピアのことも知らず、科学館でやっていたイベントで見かけて面白かったので記事を書いた、と言う程度でした。
ネイピアは１６世紀の数学者…と過去には書いたのですが、当時の学者が皆そうであったように、貴族で領主でもありました。
そして、これも当時の学者としては当たり前なことに、占星術師で天文学者で物理学者でした。
そんなにたくさんの知識を持っていてすごい、と言うのではなく、当時はこれらの学問は切り分けられてなかったのですね。
占星術を行うには毎日の惑星の運行を記録してあることが大切だったので、天文の観察は必須でした。
たくさんの観察記録を元に、天体の動きを数式で解き明かす…やはり数学者で物理学者で占星術師のケプラーによって、天体の動きが解明されたのは1619年。ネイピアの死後のことです。
さらに、ケプラーの友人で、同じように占星術師で錬金術師でもあったアイザック・ニュートンが、天体の動きだけでなく万物に働く力としてまとめ上げ、後にニュートン力学と呼ばれる物理学の基礎を作り上げていきます。
…話が少し横道にそれましたが、当時は占星術や錬金術は重要な学問の一分野だったし、それを研究するのは決しておかしなことではなかったのです。
さて、話をネイピアに戻しましょう。
彼はなかなか良い領主だったようです。
肥料の改良などを研究し、彼の領土に住む農民に対し伝えたりしています。
また、外敵から領土を守るための軍事兵器の研究などもしています。
まぁ、領土を守るのは当然のことですし、税収を上げるためにも農業の改良は必要です。
そう考えると、領民のことを考えていたというよりは、彼の利益になるからそうしただけなのですが、ただ税率をあげて利益を搾り取るよりもずっと良いやり方です。
彼は、物事を単純化し、誰でも扱えるようにし、普遍化することに深い興味があったようです。
農業の改良も、一部の「頭の良い農民」「ベテランの農民」だけが多くの収穫を得られるだけではなく、その技術の普遍化を狙っていたのでしょう。
そして、これは彼の中心的な研究分野であった数学でも発揮されます。
難しい掛け算を、ただの足し算に変えてしまう魔法の道具。それが「ネイピアの計算棒」（ネイピアの骨、とも呼ばれます）でした。
彼の業績はこれにとどまりません。
彼の生きていた時代は、大航海時代でもあります。
そして、彼は占星術師でした。
この二つのことは無縁ではありません。
占星術師は星の観察が仕事ですし、船乗りたちは星を観測して現在位置を知ります。
星の観察で現在位置を求めるには、多くの桁数の数値を扱う必要がありました。
そして、計算を間違うことは遭難、死を意味します。
＃当時は小数点の考案前で、精度を上げる＝桁数を増やす、と言うことでした。
大きな桁数で計算したのちに、適当な母数で割ることで最終的な値を求めます。
ネイピア自身、天文学者で数学者ですから、大きな数との格闘の苦労は知っていました。
そこで、この大きな数を小さくしてしまう、という方法を考案します。
これが、対数の発見でした。
先に書いたようにまだ小数点は発見されていませんから、対数は整数の比（分数）で表されます。
現在の対数とはずいぶん異なりますが、大きな数を小さくするだけでなく、掛け算を足し算に変えてしまう（計算棒と同じように！）という、魔法のような方法でした。
先に、天文学者のケプラーの話を出しました。
ケプラーの師匠はティコ・ブラーエという人で、彼は膨大な惑星の位置の観察記録を残しています。
ケプラーは、この記録を元に運動法則を解き明かしました。
ネイピアは、対数があれば天体観測が簡単になる、というアイディアを、ティコに対して披露しています。
これが 1594年の話で、その時にはすでに対数のアイディアを持っていたことになります。
しかし、対数を扱いやすくするためには、あらかじめ対数を計算した「対数表」が必要でした。
この表を作るのが難事業で、対数の発表は20年後、1614年となっています。一般には、この年が「対数が発見された年」とされています。
その後、イギリスの数学者、ヘンリー・ブリッグスがネイピアと共に対数の研究を行い、改良がおこなわれます。
ネイピアの対数は独特の式によって分数で計算されたもので、今の対数のような「底」の概念などはありませんでした。
そして、表は分数で表現されていました。
これを、10 を底とした「常用対数」に改めます。10進法を使っている場合、この方が使いやすいためです。
ところが、これでは表を分数で表現しにくくなり、対数表の記述が難しくなります。
そこで…ここで初めて「小数点」と言う概念が考案されます。
先に、当時は小数点の考案前、と書きましたが、小数点はネイピア晩年の考案なのです。
ブリッグスは、老いたネイピアに変わり、常用対数表を完成させます。
しかし、完成はネイピアの死後でした。
ネイピアの計算棒は、掛け算を足し算に変えるものでしたが、足し算の計算は人間が行う必要がありました。
後にシッカルトが、足し算部分を自動化する機械を考案しますが、これは現存していません。
難しい技術を単純化し、普遍化するという意味では、シッカルトはネイピアの意思を継いだのでしょう。
そして、「計算を自動化する機械」は、現在ではコンピューターとして我々の手元にあります。
これもまた、ネイピアがいなくては作り出されなかった機械かもしれません。
対数分野では、常用対数より後に、非常に扱いやすい「自然対数」が考案されます。
自然対数は、常用対数以前にネイピアが考えていたオリジナルの対数の概念をさらに推し進めたものでした。
この自然対数の底 e = 2.71828.... は、現在ではネイピア数と呼ばれています。
計算尺はネイピアが考案したものではありませんが、対数の性質を利用して、掛け算を簡易に行うための道具です。
ネイピアの死の直後、1620年には原型となる「対数尺」が発明され、1632年にその後普及する物と同じ「計算尺」が作られています。
歯車計算機が作られた後も、計算尺には利点も多かったために1970年代まで使い続けられていました。
電子計算機の普及まで、350年も使われ続けた「計算機」だと言っていいでしょう。
そして、分数に変わる「小さな数を表現する方法」として考案された小数点は、現代では我々は何も意識せずに使っています。
10進数の延長上にあるためわかりやすく、小学校入学前の子供でも理解できます。
これもまた、ネイピアの考案によるものなのです。
同じテーマの日記(最近の一覧)
関連ページ
ジョン・ネイピア 命日(1617)【日記 15/04/04】
別年同日の日記
申し訳ありませんが、現在意見投稿をできない状態にしています。 |
今日はジョン・スカリーの誕生日(1939)
アップル・コンピューターの元社長です。
ジョン・スカリーは、ペプシ・コーラの社長でした。
アイディア豊富な人で、コカ・コーラに対して敵意丸出しの比較 TV-CM を次々と作ります。
コカ・コーラのルートトラック（配送車）を、ペプシのマークの入った大型コンボイが追い抜く、というイメージ CM が有名。
当時大人気だったマイケル・ジャクソンを CM に起用したのもスカリーの時代。
また、「ペプシ・チャレンジ」という、コカ・コーラとペプシをブラインドテストで飲み比べ、おいしいほうを教えてもらう、というテストを街角で行い、その様子をそのまま CM として使用しました。
これは日本でも同じ手法の CM が放映され、話題になりましたね。
これらの CM が話題を呼び、結果的にペプシはコカ・コーラを抜いて、No.1 コーラ企業となります。
全米一の大企業の社長となったスカリーは、そのまま悠々自適の人生を送れる…はずでした。
彼の手腕に期待する企業から、社長をお願いしたい、という依頼が数多く彼の元に寄せられていました。
しかし、彼は全てを断っていました。
そんなある日、スカリーも信頼している超一流のヘッドハンターから、「シリコンバレーにあるコンピューター企業が、最高経営責任者を探している」という情報が寄せられます。
友人でもあり、超一流と認める彼が薦めるのであれば、とスカリーは「ちょっと話をするだけ」の約束で、その企業を訪れます。それがアップル・コンピューターでした。
１度だけの約束が何度か訪問を行い、３日ごとに電話で会談をし、新製品の開発チームの紹介まで受け…
スカリーは、アップルに心惹かれるようになっていました。
しかし、ペプシの社長の座は、捨ててしまうには惜しすぎます。
これを棄てる見返りとして、十分なものがもらえるのであれば…と、彼はほとんど無理難題ともいえる要求を出します。
前渡し契約金１００万ドル、年棒に１００万ドル、うまくいかなくても退職金１００万ドル、アップルのオプションストック（株式）を３５万株、それと、アップル本社近く、北カリフォルニアの半島部に、現在住んでいるのと同程度の自宅を用意しろ、と言うものでした。
この条件を全て呑む、と言う返事と共に、ジョブズは挑戦的な言葉を彼につきつけます。
「残りの余生を砂糖水を売って暮らしたいですか？ それとも、世界を変えるチャンスに賭けますか？」
そして、スカリーはペプシを辞任し、アップルの社長に就任します。
スカリー以前のアップルは、成長の一途をたどる企業で、非常に自由な社風でした。
しかし、スカリー就任時のアップルは、Apple// の売り上げを IBM-PC に奪われ、続く AppleIII の開発には失敗し、社運をかけた新商品「Lisa」も全然売れない、と言う状況でした。
スカリーは次々と経営陣を解雇し、経営体制を完全に入れ替えます。
さらに、パートタイマーを400人解雇します。
しかし、これは「支出を抑える」ための策です。
どんなに支出を抑えても、収入が上がらなくては仕方がありません。
ちょうど、完成を控えた新商品…これは、スカリーが説得されているときから紹介されていました…がありました。
ジョブズとスカリーは、この新商品に社運をかけることにし、膨大な予算で TV-CM を作成、全米のテレビ番組の中で視聴率が一番高い（そのため CM 放映料も一番高い）スーパーボールの中で放映を行います。
これが有名な「1984年は、"1984年"にはならない」という、Macintosh の発表予告 CM でした。
１回だけ放映した CM のために、160万ドルがつぎ込まれたと言います。
＃Mac 発表は 1984年。1948年に書かれた「1984年」というディストピア小説が話題となった年でもありました。
小説の 1984年、当時話題だったから読んだけど、題名で話題になっただけで面白くはないです…
スカリーの社長としての対外的なデビューは、この Mac の発表会。
コンピューターが音声合成で自己紹介を行い、グラフィックを使って操作可能…という、それまでのコンピューターとは全く違う「ユーザーフレンドリー」な演出は非常に注目されます。
アップル・コンピューター社長、ジョン・スカリーの華々しいデビューでした。
しかし Mac は売れませんでした。発表会こそ華々しかったものの、現実に入手し、使ってみようとすると非常に使いにくい…使い物にならないマシンだったのです。
にもかかわらず、ジョブズ率いる Mac 開発チームは社内で偉そうにし、優遇されていました。
「古い製品」をまだ改良し続けている Apple// 開発チームは、いわれもなく「無能のごくつぶし」呼ばわりされていました。
しかしこの当時、現実には Apple の売り上げの７割が Apple// によるものでした。
Apple の創業メンバーであり、Apple// の責任者だったスティーブン・ウォズニアクは、この状況に反発して退社します。
＃Apple I と Apple// の設計はウォズによるもの。大失敗だった AppleIII は別人の設計。
Apple//はウォズの退社により、今後の展開は無くなりました。
Mac は、消費者からそっぽを向かれました。
その前に発売していた Lisa は、開発責任者だったジョブズの陰謀で「失敗は無かったことに」されて、いつの間にか生産が停止していました。
…問題を起こしているすべての原因は、ジョブズにありました。
ここでスカリーは、社内の混乱の原因がジョブズにあることを指摘します。
この時点では、ジョブズはスカリーを招いた人間であり、スカリーにも遠慮があったようです。
しかし、ジョブズはこれに反発。自分が招いたスカリーを失脚させようと裏工作を開始します。
…が、発覚。お家騒動ともいえるアップル社内の内紛劇に発展します。
最終的に、スカリーは自分とジョブズ以外の役員に「どちらかを残して、もう片方を追放せよ」と決断を迫ります。
結果、追放されたのはジョブズでした。
ジョブズは、Mac は完全な商品で、変更する必要は一切ない、と言い張っていました。
しかし、スカリーはジョブズ追放の直後に改良を始めます。
まずは、単純にメモリを４倍に増やしました。次に、拡張性をもたせ、最後に CPU をパワーアップします。
これで「使い物にならない」原因が解消され、Mac は人気商品になります。
しかし、この改良は「コンピューターが使えない人へ」と作られた Mac を、ただのコンピューターにしてしまう行為でした。
スカリーには、ジョブズのような強烈なビジョン…コンピューターがどうあるべきか、と言う考えはありませんでした。
しかし、それでは今後ブレなくアップル社を牽引できません。スカリーは「ナレッジナビゲーター」という…夢物語ともいえるコンピューター像を示し、未来社会をイメージする短編映画を作ります。
そして、その頃開発が始まっていた新商品、Newton に「ナレッジナビゲーター」のイメージを重ね合わせます。
まだ新製品で１円ももうけを出していない Newton には、莫大な予算がつぎ込まれました。
その一方で、売れている Mac 開発チームの予算は削減されます。
これに対し、Mac 開発の責任者であった（そして、Newton の開発許可を与えた重役でもあった）ジャン＝ルイ・ガセーが反発。
スカリーはガセーを追放し、その後 Mac の開発は混乱をきたすことになります。
…Mac に、Apple//と同じ道を歩ませてしまったのです。
Newton はアイディアは悪くないのですが、発売時点で大きすぎる夢を詰め込んだ機械でした。
現実的には、使い物になりませんでした。
しかし、「デスクトップコンピューターを小型化したもの」ではなく、「持ち歩く情報端末」として、後の多くの機械に指針を与えています。
スカリーはこの後、売れている Mac に注力せず、売れもしない Newton に予算をつぎ込むことで業績を悪化した、という責任を問われ、退任に追い込まれます。
最終的に彼は、Apple// にとどめを刺し、アップルに残っていた創業メンバーを追い出し、Mac を混乱させ、Newton を失敗作とし、「ナレッジナビゲーター」という夢物語で業界をミスリードしただけでした。
しかし、彼がいなければアップルはもっと早く倒産していた、とも思います。
彼の経営手腕があったから、もうほとんど死にかけていた企業を延命させ、低空飛行ながらも生きながらえる会社に出来たのでしょう。
アップルの復活は、この数年後にジョブズが呼び戻されるまで待たねばなりません。
同じテーマの日記(最近の一覧)
別年同日の日記
申し訳ありませんが、現在意見投稿をできない状態にしています。 |
今日はジョン・エッカートの誕生日(1919)。
世界最初のコンピューター、ENIACを作った人です。
モークリーのアイディアに対し、回路を設計したのがエッカートでした。
その後、２人はエッカート・モークリー社を作って、２進法コンピューター BINAC を作ります。
でも、商業的には失敗。
技術的には 10進数で計算を行った ENIAC よりも、２進数の BINAC の方が優れています。
しかし、普通の人々は 10進数で計算をしたい、という当たり前のことにこれで気づきます。
商業的な失敗で資金難となったエッカート・モークリー社は、事務機器メーカーに資金援助を頼みます。
最初に頼みに行った IBM には断られ、次に訪問したレミントンランドがこれを快諾。レミントンランドに買収され、コンピューターの開発が続けられます。
ここで作った、二進化十進(BCD:10進数１桁ごとに区切って、２進数で計算する方式)コンピューター、UNIVAC I は 1951年に発売。１号機はアメリカ国勢調査局に納入されました。
翌1952年のアメリカ大統領選挙では、レミントンランドがテレビ番組の CBS NEWS に働きかけ、開票待ち時間の「余興」として、どちらが勝利するかを予想しました。
事前の専門家予想では、勝負は五分五分、どちらの候補が勝ってもおかしくない、というものでした。
UNIVAC I には、あらかじめ過去の大統領選のデータにより傾向を予測し、わずかなデータがあれば最終結果を予想できる、というプログラムが読み込まれていました。
そして、開票１％時点で、その開票結果が入力されます。
すると… UNIVAC I は 531人の投票人の内、438人がアイゼンハワーに投票する、という予測をはじき出します。
これはあまりにも専門家の意見とかけ離れていました。
プログラムの予測式を立てた学者ですら、結果を信じられませんでした。
予測式のミスが疑われ、プログラムが調べなおされます。
その結果、１桁間違った数値データが見つかりました。そのデータを修正した新たなプログラムで新たに予測を行うも…やはり、438人がアイゼンハワーに投票する、と言う同じ結果。
結局、CBS NEWS のキャスターは、「UNIVAC I は８対７でアイゼンハワーの勝利と予測」と伝えます。
その数時間後、すべての開票が終わると、アイゼンハワーの得票は 442票でした。
予測と、たった４票しか違いません。
あまりの衝撃的な結果に、CBS NEWS のキャスターは、当初の予測があまりに衝撃的だったため詳細を隠していた、と言う事実と共に詳細を公表、謝罪します。
これは人々に、どんな宣伝よりも強烈な印象を残しました。
コンピューターを適切に使えば、わずかなデータから、人間の予想よりもはるかに正確な予測を可能とする！
これにより、UNIVAC I の売れ行きに弾みが付きます。
事務機器として普及した最初の機械となり、最終的には、47台が販売されました。
＃当時、コンピューターと言うのは「１台限り」で作られるのがほとんどで、大量生産品ではありませんでした。
軍事用だったコンピューターが民生品となり、世の中を変え始める。
…その最初の一歩でした。
同じテーマの日記(最近の一覧)
関連ページ
クリストファー・レイサム・ショールズ 命日(1890)【日記 15/02/17】
クリストファー・レイサム・ショールズ 命日(1890)【日記 15/02/17】
スティーブ・ファーバー 誕生日(1953)【日記 15/03/21】
ポール・バラン 誕生日(1926)【日記 15/04/29】
別年同日の日記
申し訳ありませんが、現在意見投稿をできない状態にしています。 |
今日はフェルディナント・ブラウンの命日(1918年)。（→誕生日は1850年6月6日）
ブラウン管を発明した人です。
…あ、もしかしてブラウン管をご存じない方もいる？
現在のテレビなどでは主に液晶ディスプレイが使われていますが、こうしたディスプレイの元祖。
ほんの20年前まではディスプレイと言えばブラウン管でした。
パソコンの CRT、って言い方も聞いたことある人いるんじゃないかな。
CRT = cathode ray tube、日本語では「陰極線管」と呼びますが、ブラウン管を原理に従って命名するとこうなります。
日本では発明者の名前を取って「ブラウン管」と呼ぶのが普通でした。
さて、ブラウン管以前から、陰極線管と言うものは存在しました。
陰極とは、電池のマイナス極のこと。マイナス極から出ている、光線のようなものが「陰極線」です。
今では、正体が電子だとわかったために「電子線」とも呼ばれます。
陰極線管としては、クルックス管が有名です。
1875年ごろに、クルックスによって発明されたものです。クルックスはこの管を使って実験を行い、陰極線が磁場によって曲げられることを発見しました。
これを改良し、蛍光物質を塗って陰極線の到達点をわかりやすいようにして、電磁石によって磁場を変化させられるようにしたのが、ブラウン管です。
回路中にオシロスコープを接続すると、見えない電気の変化が磁場の変化となり、それが陰極線を曲げることで、目で見えるようになります。
これが、世界最初のオシロスコープです。1897年の発明でした。
後に、アナログコンピューター（回路と電流により、物理現象をシミュレートする）が作られた際には、動作を確認するためにオシロスコープが接続される場合が多くありました。
アナログコンピューターの多くは弾道を計算する…つまりは「放物線を描く」ものでしたが、これを応用して世界最初のテレビゲーム（ミサイルでターゲットを狙うゲームやTennis for Two）が作られています。
世界初のデジタルコンピューターと呼ばれる ENIAC は、アナログコンピューターと原理が違うため、オシロスコープは接続されませんでした。
その後、２進法を採用した EDSAC では、動作状態の確認のために３本のオシロスコープが接続されます。
このうち１本はメモリ内容を表示していたため、これを使って図形を描く遊びや、マルバツゲームなどが作られています。
さらに Whirlwind I では、最初から「高速に図形を描画する」ことを目的としてオシロスコープが接続されます。
図形描画が目的だったので、図形描画用の命令もあります。命令と言っても、座標を決めて点を打つだけですけど。
（後に専用の命令ではなく一般的な I/O の一部とされ、線を描く、文字を描くなどの方法も用意されました）
オシロスコープはいわゆる「ベクタースキャン」でしたが、NLS ではオシロスコープ出力をビデオカメラで撮影することで、普通のテレビのような「ラスタースキャン」に変換する方法を取ります。
多数の端末で画面を共有する前提であれば、普通に市販されているテレビの方が安価なためです。
これ以降、ラスタースキャンのディスプレイが増えます。
現在あなたが使用しているコンピューターも、おそらくブラウン管から液晶や有機ELに変わってはいるでしょうが、ラスタースキャンで画面を描画しています。
さて、話を少し巻き戻します。
ブラウン管を表示機器だけでなく、メモリに利用しようとした時代もありました。
それがウィリアムス管メモリ。
ブラウン管に図形が描画されているのは、蛍光物質に電子が当たるからです。
これを言い換えれば、蛍光物質が、静電気を「帯電している」ことになります。
この静電気を検出できれば、メモリとして使用できます。
検出は簡単で、同じ個所にもう一度、少しだけ電子を当てるだけ。
以前に帯電していなければ、その個所は新たに帯電するだけで何も起きません。
すでに帯電していると、容量を超えた電子が外に追い出されるため、外側に用意した電極に電流が流れます。
真空管で記憶装置を作ると、１ビットの記憶に大きな回路が必要でした。
（１ビット覚えるのに、真空管が最低２本は必要です。実際は技術的な都合でもっと増えます）
しかし、ウィリアムス管では、１つの装置でで何ビットも記憶できます。
画面上の「１ドット」が、１ビットに相当しますからね。
この方法の問題点は静電気がやがて自然放電してしまうことでした。
そのため、放電する前に読み取り、再度書き込む（リフレッシュする）必要があります。
このために CPU のパワーを浪費するのは無駄ですし、「放電する前に」と言う制限があるため、リフレッシュ速度の問題であまり容量を上げられません。
CPU パワーの浪費問題は専用の回路を作ることで解消できましたが、そうすると今度は「専用回路が動いていない時しか CPU がアクセスできない」ために、動作速度が落ちました。
そんなわけで、実用化される前にコアメモリが登場し、ウィリアムス管は実験段階で消えて行ってしまったのです。
さて、ブラウンには、ブラウン管以外にも非常に大きな功績があります。
まず、ブラウン管以前の発明。「半導体」は、彼の発見により電気回路に利用されることになりました。
電気を流すものを導体、流さないものを不導体と言います。
「半導体」は、定義的にはこの中間のもの。…なのですが、わざわざ「半導体」と言うときにはもっと有用な、特別な性質を持ったものを言います。
彼の発見した、世界で最初の半導体は、鉱石によるダイオード。電気のプラスとマイナスの向きによって、電流を通したり通さなかったりする、不思議な性質を持っていました。
この発見が 1874年のこと。
これを利用して、無線電信を検波（チューニング）する方法発明するのが 1898年。ブラウン管の翌年です。
後にこの検波器を利用して、マルコーニが無線通信を発展させます。
＃わかる人のために書いておけば、いわゆる鉱石ラジオなどに使われる、鉱石検波器ですね。
ブラウンは、無線電信の開発に寄与した功績を認められ、1909年にマルコーニと共にノーベル物理学賞を受賞しています。
今でもラジオやテレビの受信機、WiFi や携帯電波に至るまで、基本的に同じ仕組みの回路が使用されています。
彼の死後ですが、このダイオードに追加の針を立てると、電流で電流を制御できることが発見されます。
（1947年、トランジスタの発明）
電流で電流を制御できれば、論理回路が作れます。
発見前は物理的な動作の伴うリレー回路か、サイズも消費電力も大きな真空管が使われていましたが、トランジスタはサイズも電力も小さく、完全に電気的に動くものでした。
この発見により、コンピューターの小型化が始まります。
今でも、半導体回路で作られるコンピューターの基本構造は変わっていません。
半導体とブラウン管、そして無線通信。
コンピューターの発展は彼の死後の話ですが、いずれも現代のコンピューターにとって非常に重要な技術でした。
同じテーマの日記(最近の一覧)
関連ページ
別年同日の日記
申し訳ありませんが、現在意見投稿をできない状態にしています。 |
今日はゲームボーイの発売日(1989)。
ちょうど２５周年です。
今でこそ携帯ゲーム機は普通のものですが、当初は「なにも家の外でテレビゲームしなくてもいいじゃん」的な雰囲気がありました。
当時僕はボーイスカウトやっていましたが、キャンプに持ってきた後輩がいて、一人で黙々と遊んでるんですね。
せっかく大勢いるのだから、多人数で遊べることやればいいのに。
当初は家庭用ゲーム機に発売しているタイトルの類似が多かった、というのも、「わざわざ外でやらないでも」という雰囲気を出していた理由に思います。
キラータイトルだったテトリスだって、当初は「パズルゲーム」で、じっくり遊ぶゲームでした。
（大ブームを起こしたセガの業務用のテトリスは、これを「アクションゲーム」に大胆に作り変えていたのがすごかったのですが、PC/ファミコン/ゲームボーイとも、パズルゲームでした）
電車移動中にわずかな時間で遊べるゲーム…倉庫番とか、ひらめけば３分でクリアできるタイプのゲームが増えたのは、ずっと後の話。
それだって、まだ「わざわざ外で遊ばないでも」と言う雰囲気で、本当にゲームボーイが真価を発揮したのは、ポケモン以降のように思います。
僕自身は、テレビ業界に就職していた兄から古いものを貰って、「家で」遊んでいました。
テレビ業界は１～２時間の待ち時間が多く、そのくらいまとまった時間があるとちょうどよい暇つぶしになる、というので業界で流行ったのだとか。
兄も周囲が買ったので買ったようなのですが、待ち時間が暇なのは出演者側の話。
演出側の兄は忙しくて遊ぶ暇もなく、僕が貰い受けたのです。
でも…やっぱ、あまり遊んだ覚えないのですね。
ゲーム屋でも、売れなかったソフトが投げ売りになっていることがあり、そうしたものを数本買いましたが。
ポケモンに関しては、当時僕自身がゲーム業界に就職しており、仲の良かった同僚から「変なゲームがあって面白そうなのだが、一人で遊んでも面白くないらしいから」と勧められて遊び始めました。
ポケモンは発売後たいしてうれず、ブームになるのは半年くらいたってから。
でも、この半年くらい、１０位には入らないけど２０位以内にはいる、というような売れ方を続けていたのですね。「変なゲーム」と評していたのは、この売れ方のことでした。
そんなわけで、ポケモンをブーム前に目を付けて遊んでいた、と言うのは自慢の一つですが、僕に進めた友達が「飽きた」といってすぐ投げ出したため、交換などの面白さをちゃんと楽しめないまま途中で投げ出しました。
＃関係ないけど、原案者の田尻さんには仕事の関係で１度だけお会いしたことがある。わずか数分話をしただけだけど。
大学時代にバイトしていた会社でゲームボーイのソフト制作にちょっとだけ関係しました。
もっとも、ゲーム作成の周辺ツールを作成しただけ。プログラムはやっていません。
…だから、発売されたそのゲームに僕の名前が出ていても、あのバグだらけのプログラムは僕のせいじゃありません。
だいたい、スタッフロールに名前が入っていたのだって、発売して（バグだらけだから）値崩れして、投げ売りになっているゲームを買ってから知ったのだから。
で、そのころの記憶を元に過去に書いた日記、いまだに人気があるのでリンクしときます。
あと、ゲームボーイの生みの親の話。
同じテーマの日記(最近の一覧)
別年同日の日記
申し訳ありませんが、現在意見投稿をできない状態にしています。 |
今日はダイクストラの誕生日(1930)。
goto 不要論で有名な人。
…すいません。goto 不要論に関しては過去に書きたいこと書きましたし、ダイクストラの業績も実のところそれほど知らないのです。
余り書けることがなさそう。
通り一遍の説明になりますが、ダイクストラは電子計算機最初期の計算機数学者です。
初期のコンピューターには「スタック」構造がなく、つまりはサブルーチンコールもなく、そもそもプログラム言語もなく、アセンブラでプログラムを組んでいました。
これでもサブルーチンは作れました。
呼び出し元で、サブルーチンの最後にある「ジャンプ」のアドレスを書き変え、戻ってくるようにしてからサブルーチンにジャンプすればよいのです。
ただ、この方法は複雑極まりなく、プログラムは職人芸の世界でした。
あまりにも複雑で人間の手に負えない「プログラム」を、人間にできないのであればコンピューターにやらせたらどうか、というアイディアが出ます。
このアイディアは「自動プログラミング」と呼ばれますが、プログラムはそもそも創造的な行為だからコンピューターにできるわけがない、という懐疑派と、ある程度人間がわかるようにかかれた「詳細仕様」を、コンピューターが翻訳するのであれば可能ではないか、という推進派に別れます。
FORTRAN の登場(1957)により「翻訳は可能」とわかり、論争には終止符が打たれましたが、今度はより良い言語仕様とは何か、が議論に上ります。
また、PDP-6(1963)でCPUがスタック構造をサポートし、ルーチン呼び出しなど、基本的なプログラムの枠組みが整います。
ダイクストラはこの時代の人。ALGOL(1958)言語にほれ込んだ、強烈な支持者でした。
ただ、当初の ALGOL は言語仕様だけがあって処理系はありませんでした。
まさに絵に描いた餅。
＃実際には処理系はあったのだけど、とても実用にならなかった。
ALGOL は 1960 年に言語仕様を改定し、 ALGOL 60 となります。
最初の ALGOL (以下 ALGOL 58 と表記)に処理系がなかったのは、処理系が作りにくい仕様があったせいでもあります。
それを改め、実際に使える言語にしようと言うのがこの改定。
この際にダイクストラも参加し、ALGOL 60 の処理系を作成しています。
そして…ALGOL 60 の素晴らしさを広めようと、他の言語を攻撃し始めます。
自分の好きな言語だけがよくて他はダメ、という、いわゆる「言語厨」の状態。
BASIC を批判した、ということもよく言われるのですが、BASIC だけじゃなくて「ALGOL 以外全部認めない」だけですので、お間違えの無いよう。
あと、この批判は…どう見ても批判と言うより、冗談だよね。
言語の特徴を乱暴だけど短い（でも的確な）言い回しでとらえて、笑い飛ばしているだけ。
「FORTRAN は 20歳になるのに子供じみてる」とか、「COBOL は精神障害だ」とか、「BASIC を学んだものは、プログラマとして再起不能」とか。
多分、現在活躍する多くのプログラマが、最初は BASIC で学んだんじゃないかと思うんですけどね。
困るのは、ただの言語厨ではなく、高名な学者だと言うこと。
「言語厨乙」の一言で片づけるわけにいきません。
そして、有名な goto 不要論争。
以前に書いた通り、ダイクストラは goto が不要だとは思っていません。
話題になりすぎちゃって、本人の意図と違うことになってる。
ただし、当時の言語では goto が多すぎたのも事実です。
多くの goto は、処理を「開始」し、「終了」するために使われていました。
サブルーチンを呼び出し、復帰するとか、IF で実行されるべき流れにジャンプし、終わったから元の流れに戻るとか、そういう使われ方です。
ALGOL では、「開始」と「終了」に goto を使うのではなく、BEGIN と END という擬似命令を使うようにしています。
この方法では、人間にとってもプログラムがわかりやすくなりますし、ほとんどの goto を無くすことができました。
でも、「処理の打ち切り」などに goto が必要と言う認識はダイクストラも持っていたようです、というのも以前に書いた通り。
そして、今では ALGOL の影響を受けていないプログラム言語は無い、と言って過言ではありません。
FORTRAN や COBOL 、BASIC だって、その後「構造化」を取り入れているからね。
ダイクストラ自身は計算機科学の数学者であり、言語だけをやっていたわけではありません。
（さらに言えば、元々は理論物理学者です）
グラフ理論にも、ダイクストラ法と呼ばれる重要アルゴリズムを残しています。
これは、乗換案内やカーナビなどで使用される、「最短経路を求める」ためのアルゴリズムです。
わかる人にはわかると思うけど、カーナビとかって、「巡回サラリーマン問題」と類似だからね。
何の戦略もなく最短経路を求めようと思うと、組み合わせが爆発して計算できなくなってしまう。
でも、ダイクストラ法では、近傍探索を繰り返し、重複するルートを見つけた場合はより良い道のみを残す…ということを繰り返すことで、比較的短い時間に最適解を見つけ出してしまう。
今ではもっと改良されたアルゴリズムもあるけど、基本的には「改良」で、ダイクストラの考案した方法が元になっています。
逆ポーランド記法(RPN:Reverse Polish Notation)と、通常の数学記法を逆ポーランドに翻訳するためのアルゴリズムもダイクストラの考案だそうです。
…これ、大学の時に演習でプログラム作ったな。
説明すれば、普通の記法で
1 * (2 + 3)
と言う数式を、逆ポーランド記法で書くと
1 2 3 + *
となります。
逆ポーランドでは、演算記号が出てきた時点で「データの最後から２つ取り出して計算し、その結果を新たなデータとして残す」ように計算を進めます。
利点として、
・括弧がいらない
・数値データと、計算手順（記号）を分離できる
というものがあり…
…いや、あまり細かな話はいいや。これがどんなに便利か、興味ある人は自分で調べてください。
（このページから３ページ分を読むとよくわかるかと）
セマフォもダイクストラの考案らしいのだけど、これに至っては…
セマフォなしでプログラム書くなんてできないだろ、というくらい大切な概念。
いや、小さなプログラム書いている程度なら全然いらないのだけど、実用になる、ある程度のサイズのプログラムになると必須ですよ。
同じテーマの日記(最近の一覧)
別年同日の日記
15年 コンピューターが、チェスの世界チャンピオンに勝った日(1997)
申し訳ありませんが、現在意見投稿をできない状態にしています。 |
今日はアイバン・サザーランドの誕生日(1938)。
サザーランドのスケッチパッド、で有名な人です。
…あれ？ ご存じない？
まぁ、そりゃそうかも。スケッチパッドが有名と言っても、コンピューターの歴史が好きな人なら聞いたことはあるだろう、程度だし。
そのスケッチパッドも、勘違いされた説明をよく見かけるので、どうも正しく認識されていない。
＃僕だって、以前は正しく認識できていなかったので人のことは言えないのだけど。
これから、この人がどんなにすごい人か、熱く語っていきましょう。
サザーランドが 12歳の時、技術者だった父親がコンピューターを購入しました。
Simon …コンピュータ技術者の教育目的で作られたリレー計算機です。
面白いのでいろいろ書きたいのですが、長くなるので割愛。
簡単に言えば、紙テープに書かれたプログラムを読み取り、動作を変えられる計算機です。
紙テープを巻き戻したり早送りしたり、という「ジャンプ」に相当する動作は無いため、プログラムはあまり自由に書けません。難しく言えばチューリング完全（現代のコンピューターの定義）ではないのです。
計算機能は基本的に足し算だけで、キャリー付 2bit 加算が行えます。
入出力は 5bit なので、多倍長演算プログラムを作ることで、31 までの足し算ができます。
ところが、サザーランドは２歳上の兄と共に、Simon を改造して「条件停止」命令を追加し（これでチューリング完全になる）、紙テープを 2.4m も使って除算を行うプログラムを作り上げたのです。
Simon の開発者は、ハーバードマークII の開発に携わった、エドモンド・バークレーでした。
バークレーは兄弟が Simon で見事にプログラムを作ったことに驚き、彼らを雇って仕事を手伝わせます。
そして、彼らがコンピューターの天才だと感じ、クロード・シャノンに会わせます。
シャノンは、情報理論の父、と呼ばれる人物です。
電気回路で論理演算が可能なことを示し、デジタル回路の設計理論を確立しました。
（これ以前からデジタル回路の概念はあったが、職人の経験則によって作られていた）
真偽を電流の有り無しで表現することで電気回路化できることを示し、デジタルコンピューターの実現に道筋をつけています。
詳細は省きますが、CD(コンパクトディスク)やMP3などのデジタルオーディオの原理、解読されない暗号方式の考案、通信容量の限界の指摘、データ圧縮の原理など、現代生活を支える多くの理論を残しています。
…ともかく、シャノンはサザーランド兄弟に出会い、非常に喜んで、各種研究を見学させました。
さて、シャノンは MIT に在籍していました。
その MIT では、当時のコンピューター設計を根底から見直した Whirlwind I (WWI)が作られています。
驚くほど高速な上、当時標準的だったテレタイプ（電気式タイプライタ）による入出力だけでなく、ディスプレイとタッチペンによる操作が可能です。
さらに、これをトランジスタ化した試作機 TX-0 が作られ、規模を大きくした TX-2 が作られます。
（TX-1 は高機能にしようとしすぎて失敗）
また、WWI を作り出した MIT サーボ機構研究室では、これとは別の研究として、数式として記述した立体物を実際に削り出す装置…後の NC工作機や、現在の 3D プリンタと呼ばれるような装置の研究が行われていました。
（Auto Programinng Tool 、略称で APT と呼ばれていました）
しかし、平面的な物体は数式として記述可能ですが、立体物を数式で記述する良い方法が見つからないのが悩みでした。
サザーランドは TX-2 完成後の 1960年、MIT の大学院に入ります。
ここでまず、TX-0 と出会います。TX-0 は、サザーランドが知っていた「コンピューター」とは一線を画すものでした。
TX-0 には、ライトペンを使って自由に「お絵かき」ができるプログラムがありました。
でも、これはデモとしての色合いの強いもの。あまりたいしたことはできません。
しかし、サザーランドはペンとディスプレイで操作できるコンピューターに強い興味を覚えます。
目の前にあるのは簡単なデモでも、プログラム次第でもっといろいろなことができるかもしれないのです。
そしてサザーランドは、TX-2 の存在を知ります。
TX-2 なら、お絵かきをもっと「役に立つ」レベルに引き上げられるかもしれません。
実は、TX-2 には既にお絵かきプログラムが試作されていました。
これは、プロッタプリンタを接続して製図することを目的としていましたが、試作レベルで止まっていました。
＃プロッタプリンタは、ペンを動かして紙に絵を描く方式のプリンタです。
仕組みとしては、電気部分が機械に変わっただけでオシロスコープなどと変わらないため、アナログコンピューター時代から使われていました。
当面の目的はプロッタプリンタでの製図でしたが、サーボ研究所で作られていた APT （立体物の削り出し装置）などでの使用も視野に入っていたようです。
サザーランドはこれを引き継ぎ、独自のアイディアを盛り込みます。
博士論文の研究として開始したため、作成期間は１年間しかありませんでした。
作成時の話も面白いのですが、長くなるので割愛します。
作成過程で、MIT に在籍していたシャノンに助言を求めます。
シャノンは「天才少年」との再会を喜び、指導教官になってくれました。
＃この後、サザーランドの兄も MIT に入学し、やはりシャノンが指導教官となります。
後にこのお兄さんも計算機科学の研究者になっています。
兄弟は、シャノンの「最後の教え子」でした。
TX-2 は、TX-0 と同じように運用されていました。
…つまり、時間を決めて、ほかの人が使っていない時に使えます。
偉い人が優先で、学生が使うには「誰も使わない時間」を狙うしかありませんでした。
（ただし、TX-0 と違って誰でも使えるわけではありませんでした。）
サザーランドは毎日深夜３時～明け方の５時までを使ってプログラムを行い、１年かけて「スケッチパッド」を完成します。
そして、スケッチパッドの論文によって博士号を取得しました。
先に書いた通り、当時のコンピューターには通常ディスプレイが接続されていません。
なので、スケッチパッドは名実ともに、世界初のグラフィカル操作環境でした。
Photoshop のようなペイントツールではなく、Illustrator のようなドローツールだと考えてください。
もっとも、TX-2 のディスプレイはベクタースキャンで VRAM を持たないため、これは当然のことなのですが。
スケッチパッドは、「オブジェクト」を設計し、そのオブジェクトをコピーした「インスタンス」を組み合わせることで図形を作っていきます。
同じオブジェクトのインスタンスを複数作ることもできます。
元オブジェクトの設計を変えると、そのオブジェクトのインスタンスを使用しているすべての個所が変わります。
…ややこしい？ 明日に備えて、わざとややこしく書いてます。ごめんなさい。
この用語、明日の話題で重要になるのです。
論文を見ると、TX-2 の少ないメモリで複雑な図形を描くために苦心したことがうかがわれます。
この「同じ形の部品を使いまわせる」と言う仕組みも、メモリ節約のためだったのでしょう。
最終的な目標は、プロッタプリンタを使って設計図を描くことでした。
「お絵かきツール」ではなく、CAD なのですね。
当然、基本部品など同じ形が出てくることが多いため、オブジェクトしてまとめることで再利用性も高まりますし、メモリも節約できたのです。
オブジェクトを作る際には、多角形（複数ポイントによる折れ線）や、円、円弧が使えます。
また、すでに描かれた図形に「点」を重ねたり、多角形の各辺が同じ長さになるように調整できます。
論文では、これを利用し、蜂の巣のような図形を描く方法が例示されています。
蜂の巣を描くには、まず、６つの頂点がある図形（ぐにゃぐにゃで良い）を描きます。
それとは別に、円を書きます。
続いて、６つの頂点を円に「重ねる」操作をし、さらに「各辺を同じ長さ」にします。
このように、「頂点が別の図形を離れないように」とか、「各辺の長さを同じにするように」とか、制約を示すことで形を整えて行けるのがスケッチパッドの大きな特徴です。
各頂点が円周上にあり、各辺の長さが同じ…これで正六角形のオブジェクトが出来上がります。
つづいて、その六角形のインスタンスを多数表示し、「近い頂点を重ねる」ように指示すると、全部がくっつきます。
これで蜂の巣の出来上がり。
さらに、蜂の巣ができた後で六角形を「上半分」だけにして（多数の六角形が密集していると、これでも見た目は変わらない）、さらに多角形から「円弧」に変えてしまう例も載っています。
先に書いたように、オブジェクトを変えると、そのインスタンスを使ったすべての部分の表示が変わります。
全体が上半分の円弧で作られた模様になる、ということです。
これは、青海波のような模様に見えます。
…世界最初のお絵かきツール、とは思えない洗練された操作です。
現代の Illustrator テクニック、と言われても信じてしまうくらいに。
先に書いたように、スケッチパッドの最終出力は「プロッタプリンタ」でした。
そして、使用されていた EAI plotter には、図形の座標などを紙テープで指示して作図する機能がありました。
…つまり、EAI Plotter はプログラムによるページ記述ができるのです。
そして、スケッチパッドはそのプログラムを紙テープとして出力する機能がありました。
スケッチパッドは、世界初の「グラフィックによるプログラム環境」でもあるのです。
現在では、Illustrator が同じような仕組みを持っています。
あれは、ただのグラフィック環境ではなく、最終的に Postscript というページ記述言語を出力する、プログラム環境でもあります。
ベクターによってグラフィックを描き、最終的にページ記述言語によるプログラムを出力する。
スケッチパッドと Illustrator はそっくりです。
もっとも、Illustrator を作ったのはサザーランドの後の教え子なので、類似性は偶然ではないのでしょう。
蛇足になりますが、よくある間違いを正しておきます。
当時のコンピューターは対話的ではなく、ディスプレイもなかった、と言う知識から、サザーランドが（当時高価だったはずの）コンピューターを改造し、後に元に戻した、と書かれた記事がありました。
そんなことは無いです。TX-2 は最初から対話的に設計されていましたし、ディスプレイも備わっていました。
逆に、スケッチパッドが初期の対話型インターフェイスの例とされることから「キーボードより先に GUI が存在していた」と書いている記事もありました。
当時のコンピューターには通常テレタイプが接続されていて、TX-2 も例外ではありません。GUI はキーボードよりずっと後、と言う事実は変わりません。
スケッチパッドは MEMEX の影響を受けている、という記事も見たことがあります。
これはサザーランド本人に聞かねばわからないところですが、少なくとも論文では MEMEX には全く触れていません。
目指すところも違いますし、開発動機も違います。多分全然関係ないでしょう。
恐らくは、次にあげる NLS との混同かと思います。
（NLS は MEMEX の影響を受けている）
サザーランドのスケッチパッドから着想して、エンゲルバートが NLS を作った、という記事も見たことがあります。
エンゲルバートは元レーダー技師で、WWI の軍事版である SAGE の運用に従事しています。
NLS は、スケッチパッドではなく SAGE から着想したものです。
（だいたい、NLS は 1957年に開発を開始していて、スケッチパッドは 1963年完成です。影響を受けられるわけがない。）
同じく、エンゲルバートはペンよりも高精度に操作できるものとしてマウスを着想した、という記事を見たこともあります。
当時のタッチペンは、ベクタースキャンディスプレイでなくては使えませんでした。
エンゲルバートは安い家庭用テレビ（ラスタースキャン）を活用しようとしたためにペンは使えず、別の装置が必要になっただけです。
さて、その後のサザーランド。
コンピューターグラフィックの研究を進めたサザーランドは、1968年に「バーチャルリアリティ」を開発します。
両目にそれぞれ違う画像を見せる、3Dヘッドマウントディスプレイ（当時は非常に重く、天井からつりさげていた）を使い、ワイヤーフレームで描かれた空間内を移動できるものでした。
多くの人がバーチャルリアリティ、と言う言葉を知るのは、この20～30年後です。
最近話題のOculus Riftの始祖ですね。
その後、ユタ大学に教授の職を得たサザーランドは、多くの研究者を育てます。
GUI やオブジェクト指向プログラムを発明するアラン・ケイ、ピクサーの創業者の一人エド・エキャットムル、陰面処理（3D グラフィックで、奥の面を隠すこと）を研究し、グーローシェーディングに名を残すアンリ・グーロー、アンチエイリアス処理を開発したフランク・クロウなどがいます。
また、同時期に友人と共にエバンス・サザーランド社を設立し、職場でも多くの後進を育てています。
アドビシステムズの創業者、ジョン・ワーノックや、シリコングラフィックスの創業者、ジム・クラークなどがいます。
2D、3Dのコンピューターグラフィックを「発明」し、後進を育てたことも評価すれば、コンピューターグラフィックのすべてを創始した、と言って良い状態で、当然のように数多くの賞を受賞しています。
CG に貢献した人を称えるクーンズ賞の第１回受賞(1983)をはじめとして、チューリング賞(1988)、ACMソフトウェアシステム賞(1993)、フォンノイマンメダル(1998)、京都賞先端技術部門(2012)など。
現在は、非同期実行型のコンピューターを研究しているそうです。
クロック周波数を上げれば高速になるけど、上げるのは難しいし、実はこのやり方にも無駄がある。
この無駄を見直せば、高速で低消費電力のコンピューターが作れる、というものです。
…さらっと流すけど、クロックを必要としないコンピューターを作ろう、ということです。
これもすごい研究。部分的にはすでに実用化されています。
すでに多くのことを成し遂げたのに、まだまだ現役で新しいことに挑戦し続ける 76歳。
すごいお爺さんです。
同じテーマの日記(最近の一覧)
関連ページ
クロード・シャノン 誕生日(1916)【日記 15/04/30】
世界初の「プログラム可能な機械」発表(1941)【日記 15/05/12】
ノーラン・ブッシュネル 誕生日(1943)【日記 16/02/05】
ケン・オルセン 誕生日(1926)【日記 17/02/20】
別年同日の日記
申し訳ありませんが、現在意見投稿をできない状態にしています。 |
今日はジェームズ・ゴスリングの誕生日(1955)。
…僕、この人余り好きではない。でも、有名人なのは確かだし、すごいプログラマなのも事実。
凄腕は事実なのだけど、実際以上に自分を大きく、偉く見せようと虚勢を張る癖がある、ように思える。
ここが好きでない部分。
彼の最初の業績として知られているのは、Emacs を作ったことだ。
彼は、自分で「世界的に知られるエディタ、Emacs を作った」と言っている。
彼の言葉に嘘は無い。世界的に知られるエディタ、Emacs のクローンを作ったことがある。
これは「ゴスリングEmacs」としてそれなりに有名だが、数あるクローンの一種であり、ゴスリングEmacsが世界的に有名なわけではない。
…これだけだと大嘘つきみたいだ。
公平を期すためにも、もう少し詳細を書こう。
Emacs とは、Editing Macros の略で、エディタ用のマクロ集だった。
PDP-6 には TECO というラインエディタがあったのだけど、これがえらく使いにくいものだった。
ただし、TECO には独自の簡易言語が搭載されていて、マクロ・プログラムを組むことができた。
そこで、TECO をマクロによって「改造」して、使いやすいエディタを作るのが流行した。
その決定版ともいえるものが、後に GNU を創始する、リチャード・ストールマンが作った Emacs だった。
Emacs はマクロ集に過ぎなかったため、Emacs をベースにして、より便利な機能を組み込むものも多かった。
ここで、ストールマンは Emacs の配布に際して、「改良は、皆に共有されるために、公開されなくてはならない」という配布条件を付けた。
この配布条件が後の GNU に育つのだが、それはまた別の話。
ところで、TECO は PDP の OS 上でしか動かず、Emacs はその TECO の上でしか動かない。
Emacs を使い慣れたものは、同じ操作で使えるエディタを、別の OS 上でも欲しがった。
そこで、ゴスリングが UNIX 上でゴスリング Emacs を作った。
TECO の独自簡易言語は使いにくかったので、Lisp 風の…似ているだけで Lispではない…言語でマクロを組めた。
そして、そのマクロを使って、オリジナル Emacs とほぼ同じ動作ができた。
ゴスリングは、このソフトを独占した。
Emacs を「改良した」にもかかわらず、バイナリの配布のみで、プログラムのソースを公開しなかったのだ。
たしかに、マクロ集の元となる言語も違うし、すでに全く違うものなのだろう。公開義務はない、ともいえる。
しかし、それなら Emacs を名乗らなければよい。すくなくとも、ストールマンはそう思ったはずだ。
そして、ストールマンは、UNIX 上に GNU Emacs を作った。
ゴスリングの Emacs とは違い、本物の Lisp を搭載し、その Lisp でマクロを組めるようにした。
実は、ベースはどうにか入手したゴスリングの Emacs なのだが、すべてのソースを書き変え、完全に違うものにして、「公開」した。
これによって、Emacs の改良は公開されなくてはならない、という原則は守られ、PDP 以外でも動く Emacs が誕生した。
…あぁ、いかん。Emacs の話ではなくて、ゴスリングの話だ。彼の話に戻ろう。
ゴスリングは後に Sun に入社し、Java を作っている。
彼は Java を作ったので「Java の神様」と言われているのだが、プログラムをしただけだ。
プログラムをしながらより良い仕様を詰めていく、という当たり前の開発プロセスを辿っているし、その最中に彼もアイディアを出していると思われる。
だからただのコーダー（仕様通りにプログラムを作る人）と言うわけではない。
でも、Java の基本的なアイディアはパトリック・ノートンが生み出したものだ。
彼は Sun が「大企業病で死にかかっている」と感じて、それを理由に退社しようとした。
しかし、同じことを感じていた上司に、辞めるなら思い切って Sun の悪いところを書きだしてくれないかと頼まれる。
ノートンは思い切り悪口を書くが、そこまで Sun の悪い部分を知っているのであれば、Sun を変えるためにもう一頑張りしてもらえないか、と慰留される。
慰留条件として、ノートンは Sun の他の部署や重役から干渉されない、独立部署を任された。
ここで、従来の Sun では作り出せない、新しい製品を作り出せれば、Sun は生まれ変われるかもしれない。
この頃の Sun は、企業向けのサーバーシステムなどを売っていた。
しかし、コンピューターの利用はもっと広まる、家庭用などにまだまだ売り込める、とノートンは思っていたので、家庭でも使えるコンピューターを作る。
ターゲットは、テレビに接続できて、コンピューターだと意識せずに使える機械…いわゆるセットトップボックスだった。
この頃、セットトップボックス、という概念が流行し、多くの会社が開発を行っていた。
ところで、ノートンは「大企業病となった Sun を壊す」つもりでプロジェクトに取り組んでいた。
当面は、使いやすい Sun の技術を使うが、Sun の技術に依存するつもりはなかった。
技術はいつか普遍化する。
当時の Sun は UNIX の世界で絶対的な信頼を持っていたが、すでに「無料の UNIX」が世に出始めていた。
これらが普及した時、Sun の技術は陳腐化し、誰も見向きもしなくなるだろう、とノートンは思っていた。
彼は、セットトップボックスの「標準仕様」を作ろうとした。これは Sun の技術とは無関係で、仕様に基づいていれば、どの会社がハードウェアを作ってもよい、とするつもりだった。
各社が技術を凝らし、独創的なハードを作れるようにする必要がある。
競争の中で勝敗はあるだろうが、その標準に参加する企業は、Sun にライセンス料を払う必要がある。
これならば、技術が陳腐化することは無く、安定した収入を得ることができる。
独創的なハードを作れるようにする、というのは、CPU 選定すら自由であることを意味する。
でも、標準仕様としては、CPU が変わっても同じプログラムが動くことを保証しなくてはならなかった。
ここで、CPU を問わずに使える言語が必要となった。
ゴスリングは、過去に Pascal の処理系を作ったことがあった。
Pascal は教育用の言語で、特定のマシンに依存しない。どんな CPU でも動くように、仮想的な CPU の仕様が定められていて、言語はその CPU 用のコードを生成する。
各 CPU に、仮想 CPU のコードを実行できる小さな環境（仮想機械）を作ってやる必要はあるが、仮想機械さえあれば、どこでコンパイルされたプログラムでも、他の CPU で動かすことができた。
しかし、Pascal は教育目的であったため、実用には少し使いにくい点もあったし、何よりもすでに古い言語だった。
そこで、C++ をベースとして言語設計をすることになったが、C++ もまた、オブジェクト指向の「実験」として拡張されてきた歴史があるため、わかりやすい言語ではない。
もっとすっきりとした、わかりやすい言語が必要だった。
また、「コンピューター」ではなく、家電として扱うためには、使用するメモリを出来るだけ小さくする必要があった。
これらの要件を満たすべく設計されたのが oak 言語で、この仕様策定にゴスリングは関わっている。
…でも、oak なんて言語聞いたことがない、という人が多いだろう。
このプロジェクトは、事実上失敗に終わったのだ。
しかし、それで終わりではなかった。
新たに Sun に入社したマネージャー、キム・ポレーゼは、すでに失敗に終わったこのプロジェクトを再発見した。
すでに他の会社もセットトップボックスは発売しており、全然売れなかった。
業界全体で、この道は失敗だった、という認識が広がっていた。
そこで、ポレーゼは「セットトップボックスの標準」という商売は捨てるが、ソフトウェア部分である oak 言語にはまだ道がある、と感じた。
ライセンスで商売をしよう、という考えの中では、セットトップボックスは実は重要ではなく、この言語こそが重要であると考えたのだ。
丁度、WEB が流行し始めたところだった。
「違う CPU でも動く」という特徴を活かし、インターネット時代の言語として再デビューさせることになった。
ここで oak は Java と名前を変える。そして、キラーアプリとして「HotJava」というWEB ブラウザが作られた。
HotJava は Java で作られており、Java のプログラムをネットからダウンロードして動かせる。
それだけでなく、Java で書かれたプラグインによってブラウザの機能を拡張することもでき、変化の速いコンピューター業界でも常に最新のブラウザでいられる、と言うものだった。
＃当時、ブラウザは Mosaic か Netscape くらいしかなかった。
そして、ブラウザのプラグインの概念は HotJava が初めて作り出したものだった。
キム・ポレーゼは宣伝の才能があり、Java は注目の言語となった。
しかし、良い状況のままずっと続いてきたわけではない。
Java は最初のライブラリセットの設計がよくなくて、後からライブラリの仕様が変わったりした。
すると、それまでのプログラムが動かなくなる。CPU が変わっても大丈夫、と宣伝していたのが、ライブラリバージョンが変わっただけで動かなくなるのだ。
ここら辺、明らかに設計がまずかった。
いろいろと問題が多く、「どこでも動く」と言われた Java のプログラムは、現実的には苦労して保守し続けないと、すぐに動かなくなる。
でも死んでしまったわけではなく、いまでも Android では使われ続けているし、結構成功した方だろうと思う。
＃Android で使われる、と書くと「あれは Java ではない」といわれそうだけど、その話は今は関係ないので割愛。
言語と CPUアーキテクチャは無関係なので、僕は「Android は Java で書く」と言っている。
また話が横道に入ってしまったが、ジェームズ・ゴスリングは、ゴスリングEmacs を作り、Java の元となった oak の仕様策定に参加し、その処理系を作り上げた。
でも、Emacs を有名にしたのは GNU Emacs だし、oak は失敗だったが Java として生まれ変わった。
GNU Emacs はゴスリングの「汚いやり方」に反発して作られている。
oak だって目標を設定したのはパトリック・ノートンで、その目標設定が上手だったからキム・ポレーゼが再発見し、Java と名前を変えて宣伝したから流行したのだ。
どちらも、ゴスリングの力ではない。
でも、ゴスリングはこれらを自分の手柄のように話をする。
実際、やり方が汚かろうと Emacs を最初に C に移植したし、全く新たな Java 処理系をプログラムして作り上げた。
実力は相当なものだろう。
…でも、僕としては、どうも好きになれないんだな。
同じテーマの日記(最近の一覧)
関連ページ
タネンバウム教授(1944) ストールマン(1953) 誕生日【日記 17/03/16】
キム・ポレーゼの誕生日(1961)【日記 14/11/13】
キム・ポレーゼの誕生日(1961)【日記 14/11/13】
別年同日の日記
申し訳ありませんが、現在意見投稿をできない状態にしています。 |
Twitter 見ていたら、パスワード手帳に対して批判が集まっていた。
文具屋で見つけた人が写真付きでリツイートして、頭おかしい、情薄、作った会社潰れろ、などとリプライが付いていただけだけど、見た時点で 2500RT を超えていたので同じように思っている人が多いのではないか、と想像する。
でも、これ批判する人って、パスワードを正しく扱えているのかな？
状況は時代とともに変わる。
「パスワードを紙に書いてはならない」は、20年前なら確かにその通りだった。
しかし今は「暗記できる程度のパスワードを使ってはならない」と言うのが鉄則になっている。
それを知らずに「紙に書くなんて情薄」、と言っている人は、最新情報に追随できていない情薄である。
セキュリティ上、一番弱いのは、実は「パスワードは暗記しています」と言うやつ。
その昔、パスワードは紙に書くな、暗記せよ、と言われました。
だからその通りにしています。…そうだね、昔ならその方法が一番良かった。
ネットの普及以前であれば、パスワードを使うのなんて、社内の情報システムにログインするとか、unix 使いがアカウント使ってログインするとか、その程度だった。
多くてもせいぜい3～5個程度のパスワードなら暗記も出来たし、紙に書くなんて「やってはならないこと」だった。
でも、今はそうではない。
ネット上に、パスワードを使うサイトは沢山ある。
「これらを全部暗記している」という人がいたら、同じパスワードを複数のサイトで使いまわしているのではないかい？
もし思い当たるふしがあるなら、それがセキュリティ上「紙に書くよりもやってはならないこと」だと知らなくてはならない。
利用したサイトは、おそらく悪意はないだろう。悪意のあるサイトなんて、それほど多いわけではない。
でも、悪意はなくとも、技術が低くてセキュリティ管理が十分ではない、と言う可能性はある。
小さなサイトであれば、セキュリティが甘々で簡単にクラックされる、と言う可能性は高い。
じゃぁ、逆に大手は安心かと言えば、大手は利用者が多いために、クラッカーにとっては宝の山で、難しくてもクラックする甲斐がある。
つまり、どこのサイトも安全ではない、と言う前提でセキュリティを考えなくてはならない。
クラッカーは、どこか1か所のサイトでパスワードを入手したら、「ユーザーは同じパスワードを使いまわしている可能性が高い」と考え、多くの人が利用してそうなサービスで、そのパスワードが使えるのではないかと試してみる。
もし、あなたが「パスワードを紙に書いてはならない」という言葉を信じ、暗記できるだけの何パターンかのパスワードを多くのサイトで使いまわしていたとすれば、この時点で次々と、別サイトのアカウントを乗っ取られることになる。
実は、「パスワードは紙に書いてはならない」というのは古い情報であって、現在一番重要なのは「すべてのサイトでパスワードを変えておく」ということだ。
パスワードを変えてあれば、それだけで大丈夫？
…いや、実はそうでもない。
パスワードが流出する、と言う事件はたびたびあるが、ここで流出したパスワードと言うものを、3段階に分けて考えなくてはならない。
1) パスワードそのもの
2) 暗号化されたパスワード
3) ハッシュ化されたパスワード
セキュリティ意識の低いプログラマは、パスワードの管理に気を使わず、パスワードそのものを記録してあることが多い。
プログラマのセキュリティ意識ではなく、「システム発注者の」意識が低いのかもしれないが、利用者にとっては同じこと。
セキュリティ意識が多少ある人は、暗号化する。
しかし、実はこの行為には、ほとんど意味がない。
「暗号化してある」と言うことは「復号できる」と言う意味に他ならないからだ。
もし、サイトで「パスワードを忘れた」と申請したら、あなたが設定したパスワードそのものをメールで送ってきてくれる、と言うようなサービスをやっている場合は、間違いなく 1 か 2 の方法でパスワードを管理している。
万が一、クラッカーがデータを入手したら、パスワードは確実に漏れると考えたほうがよい。
真にセキュリティを知っているプログラマは、3 の方法を使う。
ハッシュ化って何？ と言うことになるが、この方法ではパスワードは一切記録されないのに、ちゃんと「正しいパスワード」を認識できる。
＃余談になるが、ハッシュ化は専門用語なので、一般にはこれも「暗号化」と言われてしまう。
報道から 2 か 3 かを見分けるのは、読み手の自己責任。
ある決まった値を、決まった鍵で暗号化すると、その答えは常に決まっている。
しかし、同じ値を、違う鍵で暗号化すると、その答えは先ほどの結果とは必ず異なる。
…このような暗号方法があったとしよう。
この「鍵」としてパスワードを使う。
ユーザーがパスワードを入力すると、それを「鍵」として「決まった値」の暗号化を行い、結果を記録されているものと照合する。
万が一記録が漏れ、復号に成功したとしても、得られるのはパスワードではなく、一定の値だけだ。
この方法ならパスワードが漏れることは無い。
ただし、暗号の計算方法は大抵わかっているので、複号を試みることはもちろん可能だ。
そして、復号できたとき、その時の「鍵」がパスワードだ。
じゃぁ、パスワード暗号化と何が違うのさ、というと、手間が全然異なってくる。
パスワードを暗号化する、というのであれば、鍵を別に用意しなくてはならない。
何千何万ものパスワードごとに鍵を変えるのは難しいので、全部同じ鍵だろう。
そしてその「鍵」は、機械的にいつでも復号できるようにしてあるのだから、パスワードが記録してあるマシンのプログラムのどこかで参照しているはずだ。
こうして、パスワードを記録したデータが漏れた時には、事実上全パスワードが漏れてしまう。
ところが、ハッシュ化であれば、「鍵」はユーザーが持っていることになる。
手当たり次第に復号化を試みることは可能だけど、時間をかけて1つづつパスワードを解き明かしていく…と言う作業が必要になってしまう。
しかも、ここでいう「時間をかけて」というのは、途方もない時間になるのだ。
…組み合わせを制限する、と言うテクニックを使わなければ。
たとえば、8文字のパスワードを、アルファベット26文字の大文字小文字、それに数字10種類を自由に組み合わせて作りだしたとしよう。
62種類を8文字連続するので、62の8乗…218兆通りほどの組み合わせができる。
いくらコンピューターが速くても、これを全部試してはいられない。
そこで、クラッカーは組み合わせを制限する。
完全ランダムな文字列は覚えにくいから、たぶん英単語を使っているだろう、と決めつけるのだ。
あらかじめ「単語辞書」を作っておき、その辞書に載っている単語を試す。
通常、パスワードシステムは8文字以上でないと受け付けないようになっているので、7文字以下の長さの単語は、別の単語と組み合わせて8文字になるようにする。
9文字以上のパスワードは、受け付けるシステムと受け付けないシステムがある。
…逆に言えば、「同じパスワードを使いまわしている人」は、8文字に揃えているはずだ。
だから、単語の組み合わせの際は、8文字になるものだけを試せばよい。
＃使いまわしていない人のパスワードを知っても、うま味は少ない。
これで組み合わせはずいぶんと制限され、現実的な時間でパスワードを見つけ出せるようになる。
もちろん、この例に当てはまらないパスワードは見つけ出せないが、流出データに何万件ものパスワードハッシュがあるのであれば、そのうち1割を解読するだけでも十分な宝の山だ。
余談になるが古典的なクラッカー追跡ドキュメンタリー、「カッコウはコンピューターに卵を産む」の中では、8文字になるように英単語を組み合わせてパスワードを作る、と言う方法が推奨されている。
この時代、上に書いたような「単語を試してパスワードを解読する方法」は使われ始めたばかりで、コンピューターの速度も遅かったために、「8文字の英単語」を試すのがせいぜいだったのだ。
たとえば、3文字と5文字を組み合わせればこの方法では見つけ出されない、というので、書籍では「robotcat」というパスワードが例に出されている。
この時点では良い方法だったが、今は時代が変わった。
しかし、この方法が有名になりすぎ、今でもこの方法を使う人がいる。
クラッカーはそこにつけ込んでいるのだ。
万が一パスワードが漏れたらどうなるだろう？
たとえば、Amazon のパスワードが漏れ、登録してあったクレジットカードで買い物された…
なんていうのは、実はわかりやすい被害だ。
きっとクレジットカード会社が補償してくれるから大丈夫。
でも、Gmail のパスワードが漏れ、メールを覗かれ続けたとしたら…これはなかなか気づけない。
いつパスワードが漏れているかわからない、と言うことを考えると、対策は「時々パスワードを変える」と言うことになる。
クラッカーが、次にログインした時に「パスワードが変わった」ことに気が付けば、もう手の出しようがないのだ。
暗号と言うのは、時々鍵を変えるから意味を持つ。
鍵を変えずに運用し続けて、暗号が漏れたまま気づかないでいた…なんていうのは、歴史上よくある運用ミスだ。
歴史に学ばなくてはならない。
・サイトごとにすべて変更する。
・ほぼランダムに見える文字列を使う。
・時間的にも時々変更する。
これが、現代における「正しい」パスワードの運用方法。
全部暗記しておく？ …いや、それは現実的ではないだろう。
これでもまだ「紙に書いてはならない」だろうか？
紙に書いてはならないから、クラウドの、Evernote や Dropbox で管理している、という人もいる。
これは論外。それらのサイトがクラックされたら、すべて漏れると考えてよいだろう。
＃現実に、Evernote はクラックされてパスワードが流出したことがある。
クラウドはさすがに怖いから、ローカルの PC にファイルとしてパスワードを記録して、そのファイル自体を暗号化している、という人もいる。
でも、ネットに繋がっていればローカルからの流出だってあり得る。
暗号化してあると言うことは、鍵が知れれば「全部の」パスワードが漏れてしまう、と言うことでもある。
また、クラウドと違ってどこからでも参照するのが難しいから、各所にコピーをばら撒いておく…なんていうのは、流出の可能性を増やしているだけだ。
実は、それよりもネットに接続されていない、接続しようもない、でもどこにでも持ち運べる「紙」に書いた方が良い、というのも、セキュリティの専門家が指摘するところだ。
ただし、紙に書くならその取扱いは厳重にすること。
冒頭にあげた手帳、パスワード手帳だが、外見は「パスワード」など一言も書いていない。
普通の手帳に見えるようにしてある。
ただ、url と id とパスワードの組を書けるようになっているのは…少しいただけないように思う。
その3つ組を一緒に記録するのは、いくらなんでも危険だろう。
url や固有名詞は避けて、「いつも使っている銀行」くらいにとどめるのが良いのではないかな。
いや、銀行とすら書かず、GK (GinKou) とか BK (BanK) とか、軽く暗号化（符丁化）するといいだろう。
ID に関しても、多分名前をローマ字にしていたり、メールアドレスが使えたり、いくつかのパターンに収まるだろうから、そのヒント（こちらも符丁で）だけで。
で、パスワードは書いておけばよい。
ちゃんとすべてのサイトでパスワードをかえてあれば、パスワードだけわかっても何もできないはずだ。
ちなみに、第三の方法もあって、パスワードの一部を、そのサイトから得られる何かを使って、一定の手順で「計算」できる方法にしておく、というのもある。
一部は暗記して使いまわすが、一部は「計算」で導出する。
計算式が簡単すぎると推察されるかもしれないけど、ひと工夫すれば、自分以外にはわからなくなる。
この方法の欠点は、「全部のサイトで」違う、と言うほどのパスワードを作り出せていない可能性と、時間的に変化させることができないこと。
それでも、本当に重要なサイトだけ「正しく」管理を行い、それ以外はこちらの方法を使う、とかで使い分ければよいだろう、と思う。
2019.7.14 追記
この記事でのパスワード管理の結論の一つ、「時間的にも時々変更する」はやってはならない、とするご指摘をいただきました。
ご指摘は、2017年に米国政府機関である NIST が勧告し、これを受けて総務省も日本国内向けに勧告を行った、「パスワードの定期変更を強制すべきではない」に基づくものだと思います。
この記事の冒頭に書いたように、状況は時代とともに変わります。
記事を書いてから５年たち、日進月歩のコンピューターセキュリティの話としては、いささか古くなっているとは思います。
しかし、残念ながらご指摘をくださった方は、NIST ・総務省の勧告を勘違いしているようです。
この記事の内容は、2019 年時点では、まだ有効なままです。
何をどう勘違いしているのかなど、詳細を示すと長くなりますので新たな記事として書き起こしています。
このページの内容をここまで読まれた方は、５年後の状況に合わせて書かれた、新たな記事もお読みくださると幸いです。
同じテーマの日記(最近の一覧)
関連ページ
パスワードの管理方法（令和元年版）【日記 19/07/14】
別年同日の日記
申し訳ありませんが、現在意見投稿をできない状態にしています。 |
今日はドラゴンクエストの発売日(1986)。
これ以前、家庭用ゲームの王道はアドベンチャーゲームにありました。
ファミコンがまだ「目新しい製品」だったころ、家でテレビゲームをやろうと思ったら、パソコンしかありません。
（まぁ、カセットビジョンとかあったけど）
当時のパソコンの性能では、アクションゲームは業務用の基板にかなうわけもなく、ゲームセンター「っぽい」ゲームが遊べる、と言うことに満足するか、ゲームセンターでは遊べないゲームを遊ぶか、どちらかでした。
で、ゲームセンターでは遊べないものの代表が、アドベンチャーゲーム。
アクションゲームでは表現できなかった「物語」を作り出すこともでき、多くのユーザーに愛されていました。
当時のアドベンチャーゲームは、「コマンド」をキーボードから入力することでストーリーを進めました。
ところどころで、そんなの思いつくか！ というコマンドを入力させるのですが（もちろんノーヒントで）、そのキーワードを探し出すことも含めてゲームの楽しみでした。
だから、任天堂がアドベンチャーゲームを作れるようにキーボードのハードウェアを用意した、と言うのも理解できる話。
堀井雄二が「コマンド探しはアドベンチャーゲームの本質にあらず」と、コマンド選択式と言う新しい概念を発明して「ポートピア連続殺人事件」を移植したことで、キーボードは不要になってしまいましたが。
＃キーボードは、後にファミリーベーシックで日の目を見ます。
で、パソコンではアドベンチャーゲームに変わる新たなブームとして、RPG が流行しつつありました。
とはいえ、日本ではまだほとんど知られていなかったジャンル。
これを、先に書いた「ポートピア」の堀井雄二がシナリオを手掛けることで、ファミコンで作り出したのが「ドラゴンクエスト」。
一部のマニアはパソコンですでに RPG を経験していましたが、各種 RPG のエッセンスを組み合わせ、難易度も子供でも遊べるように調整し、しかし大人の鑑賞に堪える物語性は残しつつ、作り上げたのがドラゴンクエストでした。
実のところ、RPG は非常に計算を多用する…そのため、メモリも多く必要になるゲームジャンルで、ファミコンでは作るのが難しいと考えられていたジャンルでした。
ドラゴンクエストのプログラムは、パソコンゲームの作成で「天才」と呼ばれていた中村光一を起用。
非常に少ないメモリを見事に使いこなします。
この後、時代は一気に RPG へと傾き、アドベンチャーゲームは「古いもの」になってしまいました。
日本の RPG の、ほぼすべてがドラクエの影響を何らかの形でうけています。
海外では、こうしたジャンルが「J-RPG」（本来の RPG とは異なる、日本的 RPG）と呼ばれるほどに、日本の RPG の形を規定したと言って良いでしょう。
＃J-RPG には「古臭いイメージの RPG」という侮蔑の意味も含まれる。
J-RPG で海外でも人気があるのはポケモンだけ、らしい。
僕はと言えば、ドラクエは３までしかやってません。
１は友達に借りたのですが結構やり込み、２は所有してやり込み、３は友達から借りてさっと遊んだだけ。
もちろん、２が一番好きです。その後のシリーズは知らない。
というか、実は RPG はそれほど好きではないジャンルだったりします。
ウィザードリーや ROGUE は好きなんだけどね。
でも、ドラクエが日本ゲーム界の変えた、革命的作品であったことは認めるところです。
同じテーマの日記(最近の一覧)
別年同日の日記
申し訳ありませんが、現在意見投稿をできない状態にしています。 |
今日は、世界で最初の MML ドライバが完成した日！(1960)
…というのは、ごめん。ちょっと話盛ってます。
ある程度根拠はあるのだけど、言い切ってよいかどうかちょっとわからない。
でも、「それなりの根拠」の提示も含め、話を始めましょう。
その後調査したところ、どうも「最初」というには問題があるみたい。
確かに現行の MML に類似したものとして最古ではあるけど、現代に繋がっておらず、別の場所で再発明されている。
詳しくは、その後の調査をまとめた世界初のMMLもご覧ください。
最初に書いておけば、MML というのは Music Macro Language の略。
音楽を表現するための言語、ということですね。
音の高さとして「ドレミファソラシ」があるのは多くの方がわかっているとおもいます。
でも、「ド」がどの周波数の音か、というのは変動します。
言い換えると、「ドレミ～」というのは、相対的な音階。
周波数に対して音を決めた「絶対音階」というものがあって、日本語では
「ハニホヘトイロ」となります。
これも、小学校の音楽で習うので、覚えている人が多いと思います。
そして、英語では「C D E F G A B」です。
MML では、一般にこのアルファベットを使って音楽を記述します。
cdefgab
と書けば、ハ長調で「ドレミファソラシ」と鳴らす命令になります。
ちなみに、休符は「r」です。rest （休み）の意味。
cdefedcr
efgagfer
これだと、「カエルのうた」の冒頭になります。
音の長さを指示したい場合、「４分音符」なら、後ろに 4 と書きます。
４分、というのは「４つに分けた」と言う意味ね。
一番長い音を「全音符」として、それをいくつに分けるかで音の長さを示すのです。
4分音符の２倍の長さ、「２分音符」なら、MML では後ろに 2 と書く。
４分音符に点を付けた「付点４分音符」は、4. と書きます。
付点が付くと、本来の音の長さの半分を追加する（1.5倍の長さにする）意味です。
c4.d8e4.c8e4c4e2
これだと、「ドレミの歌」の冒頭。
細かな部分では方言も多いし、これ以上の詳しい説明は避けるけど、これが「MML」です。
1980年代には、パソコンというと「自分でプログラムするもの」で、大抵は MML も使えました。
でも、今のパソコンはプログラムするものではないですし、MML を使うのもいろいろ大変です。
遊んでみたい人は、数年前に一部で流行したTSS Clipboard Playerがおすすめです。
解凍して実行するだけでインストールなしに音楽演奏が楽しめますし、テキストエディタさえあれば、特別なプログラム環境も不要です。
TSSCP を入手したら、こことかここに行って、演奏してみるだけで結構楽しめます。
さて、MML 入門講座ではないので、話を戻しましょう。
コンピューターに音楽を演奏させる、と言う試みは、1951年に遡ります。
ENIAC の公開が 1946年ですから、わずか５年で、ただの「計算機」ではない試みが行われていたことになります。
（もっとも、紀元前500年のピタゴラスの頃から、音楽と数学が近い関係にあることはわかっていました。
コンピューターで音楽を演奏しよう、というのも、それほど突拍子もない話でもないのです。）
1951年のシステムはCSIR MK1（後に CSIRAC と改名）というコンピューター上で動いていました。
CSIR MK1 は、当時の多くのコンピューターと同じく、水銀遅延管メモリを採用していました。
ただ違うのは…デバッグのために、水銀遅延管の内容（本来は超音波パルス）を、人間の可聴域でもスピーカーから出力する機能が付いていたことです。
こうすることで、メモリの内容が変化するさまを、音として聞くことができます。
…しかし、音が出ればこれを使って遊びたい、と思う人がいるものです。
やがて、「音楽を演奏する」実験的なプログラムが作られました。
この時に演奏された曲の１つが「ボギー大佐」でした。
後に映画「戦場をかける橋」のテーマ曲として編曲され、「クワイ河マーチ」として知られるようになった曲です。
こちらのページの一番下のリンクから、当時の演奏の録音を聴くことができます。
（QuickTime Player が必要です）
CSIR の演奏は、データを音階・音程とも数値として表現し、パンチカードに打ち込んだ数値をメモリ内に読み込んで、プログラムを実行する方式でした。
「演奏」はできるのですが、MML のような言語はありません。
CSIR の次に音楽を演奏した、とされるのは、AT&T ベル研究所で 1957年に開発された、「MUSIC」というプログラム。
このプログラムは、音楽演奏にとどまらずどんな音でも作り出してやろう、という野心的なもので…非常に汎用性が高い反面、音楽演奏に限って言えば、非常に面倒でした。
音を出す時には「周波数」と「秒数」を指定します。
指定方法には独特の表記方法を持ったプログラム言語が使用されますが、いわゆる MML ではありません。
ところで、この時代のコンピューターはまだ非常に高価なものです。
コンピューターを利用するのだって、１分１秒でも「無駄」を生じさせないようにする、と言う時代。
音楽演奏なんていうのんびりしたことができるのは、かなり贅沢な事でした、
僕が知る限り、３番目に音楽演奏を行ったのは TX-0。
コンピューター利用には無駄が許されない時代、と書きましたが、TX-0 はおそらく世界初の「無駄が許される」コンピューターでした。
だから、世界最初のテレビゲームなんかも作られました。
そして、当然のように音楽演奏プログラムも作られています。
TX-0 では、CSIR と同じように、動作中に音で動作状況がわかるようになっていたそうです。
ジャック・デニスが「うまくやったら音楽が演奏できるのではないか」と示唆し、ピーター・サムソンがそのハックをやってのけました。
このプログラムのソース（アセンブラで書かれている）は今でも残っています。
その冒頭に日付（おそらく完成した日）が入っていて、1960年の5月28日なのです。
これが、冒頭に書いた「世界初の MML ドライバ完成の日」の根拠。
もちろん、数値として楽譜を入れるのでも、周波数として入れるのでもなく、MML が使われています。
MML で書かれた楽譜データもちゃんとあります。
今の MML とは少し表現が違います。
先頭から数行を見てみましょう。
BOURRE= b-o-u-r-r-e-acute, Hill.
p| 3600
220|
4e t8
4f t8
4g t4
4c t8
3b t8
4c t4
冒頭の部分はコメントです。BOURRE と言う曲名。
次の２行は、アセンブラに対する指令。
実は、この楽譜データはアセンブルしてから使用します。
4e t8 というのは、「４番目のオクターブの e の音を、８分音符の長さで」と言う指定。
音の名前だけでなく、オクターブも一緒に示すのですね。
＃現代の MML では、オクターブが切り替わるところでのみ、オクターブの指定を行うのが普通です。
t8 は tempo 8 の意味でしょう。
ちなみに、d8 と言うような表記もあります。dot 8 …つまり付点８分音符の意味。
こんな表記もあります。
4g t8
4fs t8
4b t8
4fs は、オクターブ4 の f の音の「シャープ」です。半音上げる。
4gf のように、f を付けると「半音下げる」でした。4fs と 4gf は同じ音になります。
ちなみに、オクターブは 1 から 9 まで使えます。
ただし、オクターブ 9 で使えるのは c のみ。事実上は 8 まで、ということですね。
１行が１音符で、必ずオクターブを同時指定するなど若干の表記方法の違いもあるために現代の MML とは異なりますが、方言の範囲内ではないかな、と思います。
ちなみに、音階は必ずオクターブの数値から、音長は t か d から始まるため、１行の中に両方が書いてあれば、順番はどちらが先でも構いません。
僕は TX-0 のエミュレータを作っているので、是非今日までに音楽演奏プログラムが動くようにしたかった…のですが、残念ながら間に合いませんでした。
TX-0 の動作については多くの文献が残っていますが、音がどのように出ていたかは文献にないのです。
どうも、動作確認用のおまけだったので、この機能は説明されていない模様。
TX-0 で「遊んだ」ハッカーたちについてまとめられている書籍「ハッカーズ」の中には、「アキュムレータに持つ18ビット・ワードのうち、14番目のビットの状態にしたがって発声される」という記述があります。
でも、エミュレートを試みている現段階では、この記述は事実とは異なるみたい。
＃僕がなにか勘違いしている可能性もありますが。
TX-0 の音楽演奏プログラムを作ったピーター・サムソンは、翌年には仲間と一緒に、PDP-1 を使って４声の和音も出せる音楽演奏プログラムを作っています。
このプログラムは Harmony Compiler と名付けられていました。
ただ、Harmony Compiler は、いわゆる「MML」の表記からは離れてしまっているのですよね。
音程は cdefgab ではなく、数字で示します。
＃多分、「オクターブ指定」の概念を無くして、言語解析を単純にするため。
これで単純になった分、演奏のための機能が非常に多彩になっている。
音楽演奏としては TX-0 よりも Harmony Compiler の方が有名です。
しかし、これが現代の MML 的でないとなると、TX-0 の MML は「後世に影響を与えていない」可能性が高いようにおもいます。
最初に「世界最初の MML」と書いたことについて「話盛っている」と書いたのはこのため。
TX-0 の MML を紹介した時点で「違いはあるけど方言の範囲内」と強弁したけど、たぶんこの違いは現代とつながっていないためです。
繋がってないのだから、歴史的に最初だとしても、現代の「始祖」ではない。
じゃぁ現代の始祖はどれか、っていうのは最初のMMLについて、調査した方のページがあったりしますが、諸説入り乱れているようです。
PDP-1 の演奏に関しては、ダニエル・スミスのページに当時の録音が MP3 で公開されています。
ダニエル・スミスは、Harmony Compiler を作った「仲間」の一人で、HAX の代表の１つであるマンチング・スクエアの作者でもあります。
Harmony Compiler はさらに後に、PDP-6 にも移植されたようで、その際の説明書が残されています。
後日、TX-0 以降、現代にいたるまでの MML の進化の歴史調査を行いました。
興味のある方は世界初のMMLもご覧ください。
同じテーマの日記(最近の一覧)
関連ページ
別年同日の日記
申し訳ありませんが、現在意見投稿をできない状態にしています。 【keim_at_si】 修正ありがとうございます！ (2014-05-29 10:30:39)【あきよし】 大変失礼いたしました。古いURLを示しているページが多く、ページ閉鎖してしまったのかと勘違いしてしまいました。 本文から「配布終了している」の節を削除します。 (2014-05-29 05:57:56) 【keim_at_si】 配布終了してないですよー。開発は終了してますが。http://soundimpulse.sakura.ne.jp/tss-clipboard-player/ (2014-05-28 19:06:13) |
シャープのパソコン、ってなんてアバウトな。
僕もさっきまで知りませんでした。
Twitter で、SHARP GALAPAGOS 公式氏が気を吐いておりました。
1984年 MZ-1500 発売
1984年 X1Cs および X1Ck 発売
1990年 X68k SUPER-HD 発売
1990年 All in Note (ノートパソコン)発売
…だそうです。
個人的に X68k が好きですが、SUPER-HD はバリエーションの一機種に過ぎないので、
MZ-1500 の話題行きましょうか。
MZ-1500 って、あまり歴史に名を残していない機種に思います。
でも、当時のパソコン少年で憧れた人は多かったはず。
だって、この機種すごい性能なのに、結構安いんですよ。
MZ-700 の完全上位互換でした。
ある程度資産のある、MZ-700 のソフトは完全に動作する、ということです。
ちなみに、MZ-700 は、黎明期のパソコンである MZ-80K の上位互換です。
…MZ-80 には、K 系列と B 系列の２つがあり、MZ-80B の互換ではない、と言うのがややこしいところ。
（B系列の後継機は MZ-2500 ）
さて、MZ-1500 ですが、PCG を搭載していました。
当時のパソコンは遅く、ゲームを作るためにグラフィックを使おうものならさらに遅くなります。
ところが、PCG というのは、「文字の形を自由に変えられる」機能で、グラフィックではなく文字として、
ゲームの画面を作ることができます。
これだと非常に速いのですね。
当時のコンピューターでは PCG を持たないものが多く、持っていた場合もアスキー文字と同じく、256文字程度で白黒、と言うのが普通でした。
ところが、MZ-1500 では画面全てを違うキャラクターで覆えるほどの PCG が使えます。
さらに、ドット単位で好きな色（デジタル8色）が使えます。
さらに、PSG を２つも搭載していました。
当時、音楽と言えば３重和音が最大、と言うのが普通でした。
ところが、そのチップを2つ搭載することで、６重和音を可能としていたのです。
さらに驚くことに、まったく新規開発の「クイックディスク」を搭載していました。
ディスクドライブがまだ高嶺の花でとても手が出なかった時代に、特殊な機構で非常に安いディスク装置を搭載したのです。
こんなに機能を盛り込んでいて、その割には値段は高くない。
専用モニタ不要で、家庭用テレビに接続できる、というのもセット価格を安くする要因でした。
…いつかこれを購入して、面白いゲームを自作してやるんだ。
僕はそう思っていました。
でも、先に書いたように、MZ-1500はあまり歴史に名を残していません。
たいして売れなかったのです。
非常に優れた性能を持っていましたが、「他機種よりちょっといい」程度で、とびぬけた部分がなかったのです。
PCG は、「画面を違うキャラで覆えるほど」と書きましたが、実はその画面の解像度は低めでした。
家庭用モニタに接続できるように、と言う配慮もあり、40x25 …つまり、画面上に1000文字しか出ないのです。
（PCG の定義数は 1024キャラクタ）
この文字数は、ゲームをやるには十分。でも、他の機種と比べると見劣りがする感じです。
PSG による６重和音も、すぐ後には FM音源の時代がやってきます。
FM３重 + PSG３重の６重和音。同じ発声数なら、音がずっと良い FM音源の方が見栄えがしました。
クイックディスクは…後にファミコンのディスクとして流用されるものなのですが、渦巻き状にシーケンシャル記録する仕組みでした。
ディスクの良さは、ランダムアクセス可能なところにあります。
しかし、シーケンシャル記憶ではランダムアクセスは出来ず、ただ速度の速いカセットテープと同じなのです。
MZ-1500 は、PCG や ６重和音など、エンターテイメント性…はっきりいえば、ゲームターゲットでした。
しかし、ゲームを作るには「スプライトが存在しない」ことが足枷でした。
MZ-1500 の前年には、MSX とファミコンが発売されています。
MSX はスプライトもありましたし、PCG も持っていました。
ファミコンなら、画面に表示できる色数もずっとありました。
しかも、どちらとも MZ-1500 よりずっと安いのです。
高級機ほどの性能を持たない、しかし廉価機種ほど割り切れていない、中途半端な存在。
それが MZ-1500 でした。
結局、発売されたゲームもそれほど多くありませんでしたし、商業的に失敗だったようです。
当時シャープは全く異なる２つの部署がそれぞれパソコンを作っていました。
パソコン事業部の MZ と、テレビ事業部の X1 です。
一番古い、MZ-80K の互換路線は MZ-1500 で終わりとなり、パソコン事業部は高級路線である MZ-80B の互換機として後に MZ-2500 、さらには 16bit 化した MZ-2861 に続きます。
X1 シリーズはより新しい設計で、テレビ事業部らしく画像に力を入れていました。
PCG も豊富に持っていたため、MZ-1500 の直接のライバルは、X1 だったかもしれません。
X1 は後に互換性のない X68000 へと進化しますが、こちらも「美しすぎる」設計が足を引っ張って時代の変化に合わせられなくなり、性能があまり変えられないままシリーズ終了しています。
同じテーマの日記(最近の一覧)
別年同日の日記
申し訳ありませんが、現在意見投稿をできない状態にしています。 【とおりすがり】 80カラムモードが無いことと、癖が強すぎることが問題だったかもしれませんね。PCGの書き換えタイミングに制限があったので、予め定義したPCGを積極的に使わないとグラフィックの遅い低解像度機になってしまうので、高性能とも言いがたい。個性的で面白い実装ではあるのですが。 (2017-05-13 21:28:00) |
今日はフェルディナント・ブラウンの誕生日(1850)。
ブラウン管を発明した、と言う業績が有名ですが、半導体を発見した人でもあります。
また、発見した半導体で検波器（電波のチューナー）を発明してもいますから、ラジオやテレビをはじめとした、ありとあらゆる無線通信システムは彼の業績なしには存在しなかったことになります。
詳細は命日(4/20)に書いたのでそちらで。
同じテーマの日記(最近の一覧)
関連ページ
フェルディナント・ブラウンの命日(1918)【日記 14/04/20】
別年同日の日記
申し訳ありませんが、現在意見投稿をできない状態にしています。 |
今日はティム・バーナーズ・リーの誕生日(1955)。
World Wide Web (WWW) を作り出した人です。
昨今では、インターネット= WWW だと考えている人も多いですし、実際 WWW がなければこれほどインターネットが普及したとも思えません。
WWW が「発明」されたのは、1989年の3月。
この時、WWW に必須の３つの技術仕様… URL、HTTP、HTML が一緒に発明されています。
この３つの発明により、インターネットが大きく変わったため、「ルネサンス期三大発明」になぞらえて「ティム・バーナーズ・リーの三大発明」と呼ばれています。
話はティムの生まれる前まで遡ります。
僕のページでも紹介している、Baby MarkI というコンピューターがあります。
非常に小さな実験機で実用ではありませんでしたが、ただの電子計算機ではなく、世界初のプログラム内蔵型でした。
…つまり、現代的な定義でいえば「世界初のコンピューター」でした。
この Baby MarkI を元に作られた実用機が Manchester MarkI(1949)でした。
イギリスのマンチェスター大学が作成しています。
この計算機プロジェクトに参加した二人の数学者がいました。
一人は数学者としては珍しい女性。
二人はやがて結婚し、1955年の今日、子供が生まれます。それが今日の話の主役、ティム・バーナーズ・リーでした。
父母ともに計算機数学者で、当然のようにティムも子供のころから計算機に興味を持ちます。
6800を使用したコンピューターを完全自作したこともありますし、大学のコンピューターをハックして使用禁止令を受けたこともあります。
いわゆる「コンピューターの天才」、それも飛び切りのサラブレッドでした。
当然大学卒業後もコンピューター関連の職業につきますが、やがて独立します。
そして、個人でコンピューターコンサルタント業を始めますが、1980年に６か月間、CERN に滞在します。
スイスにある CERN…欧州原子核研究機構では、世界中の科学者たちが集まり、１国では建造できないほどの莫大な資金をつぎ込んだ大型加速器を使った研究をしています。
その設立は、ティムの生まれる１年前の 1954年。
単に１国では資金難だから、と言う理由だけでなく、その研究内容が高度すぎ、世界中の天才を集めないと研究が進まない、と言う事情もあります。
ですから、ここでは研究者同士を隔てる国の壁はありません。
…というのが建前なのですが、実際にはそれぞれの研究者はそれぞれの国の予算で研究に参加しており、コンピューターやソフトウェアを導入するのにも、それぞれの国の行政方針の影響がありました。
このため、使用するマシンも、OSも、ソフトウェアもバラバラでした。
現在では8000人の科学者が集まる大所帯ですが、1980年当時でもかなりの人数が集まっていたようです。
もはや、「直接会って話をする」なんてレベルでは、情報の交換ができません。
大勢の科学者が持っている情報を、迅速に交換できるシステムの構築が急務でした。
しかも、その構築に使えるコンピューターは、各国ごとにバラバラ、という難題が待ち構えていました。
1980年にコンサルタントして CERN を訪れたティムの仕事は、この難題を解決することでした。
ティムが意識していたかは不明ですが、おそらくはXanaduのようなものが必要とされていたのでしょう。
これは、パワフルでグラフィカルなコンピューターと、コンピューターを何百台も接続できる大規模ホストコンピューターによって作り出されるシステムです。
…1980年当時、インターネットはすでに生まれていましたがアメリカの一部で細々と使われているだけでした。
電話回線によるパソコン通信、と言う手段もありましたが、効率的ではありません。
結局、この時はコミュニケーション問題は解決できていません。
しかし、ティムの心の隅に問題意識を植え付けたようです。
６か月後、ティムはイギリスに戻り、別の仕事を始めます。
1984年、ティムは再び CERN に戻ります。
この頃には、コンピューターを相互接続してネットワークを形成して使用する、と言う考え方は、一般的になり始めています。
ただし、実際のネットワーク環境が整うのはもうすこしあと。1985年ごろからです。
当時主力と目されていたのは、IBM が技術開発をすすめる Tokenring 。
世界最大のコンピューター企業が推進しているのですから、将来はこれに決まるだろう、と多くの人が思っていました。
対抗馬は Apple の AppleTalk 。
…これ、ネット調べると「Mac の発売当時から搭載していた」とするページが多いのですが、ちょっと違う。
まぁ、その話は今回は関係ないので割愛しますが、Apple はパソコンの元祖を作った有名企業。
IBM の Tokenring への対抗になりうるかも、と期待されていました。
インターネットに使われる「イーサネット接続」は、じつはすでに稼働実績がありました。
初稼働は1973年ごろ。
もっとも、1970年代は、研究などの目的で存在していただけ。
1979年にイーサネット通信機器を手掛ける 3com 社が設立されてから本格的な普及が始まりましたが、1984年ごろはすでに「古臭い技術」でした。
通信仕様自体も小さなコンピューター会社各社の合議によって作られていましたので、今後改良するのは難しそうでした。
そのため、IBM や Apple のような大企業が出てくれば先は無いだろうと考えられたのです。
だから、ティムが CERN に戻っても、すぐに問題解決、とはなりませんでした。
最初に書いたように、問題が解決するのは 1989年でした。
特定企業の物ではなかったイーサネットが、ライセンス料などがないために安く使え、大学などの研究機関を中心に利用が広まっていました。
当然、CERN でも、ほとんどのコンピューターがイーサネット接続されていました。
でも、接続されたから解決、ではありません。
最初に書いた通り、コンピューターも OS もバラバラで、お互い使用できるソフトが違うのです。
イーサネットで使用できるプロトコルとして、メールも、ファイル交換(FTP)プロトコルも定められていました。
しかし、当時のメールは文字のみ。ファイル添付などできません。
ファイルの交換を行うための仕組みである FTP では、特定のサーバーに接続し、ファイル一覧を表示し、目的のディレクトリを見つけて潜り…これを繰り返し、ファイルを発見したら取得する、と言う操作をコマンドラインから入力する必要がありました。
この混乱を収拾する必要がありました。
ここでティムが考えたのが、３つの仕組み。最初に書いた「三大発明」です。
FTP では、たとえファイルのある場所を人から教えてもらっても、サーバーに接続して、その場所までディレクトリをもぐって…と言う操作を人間が行う必要がありました。
これを、ダイレクトに行える「記述方法」を作ります。
FTP 以外にも情報をやり取りするプロトコルはありましたから、プロトコルも指定できるようにします。
それまでバラバラだった、プロトコル、サーバー、サーバー内の位置を１つにまとめる記述方法。
これは「Uniform Resource Locator」（資源の場所の統一記法）と名付けられました。
略して URL と呼ばれます。
情報のある場所がわかっても、それが特定のソフトでしか読めない形式では困ります。
一般化された、誰でも読める情報の記述方法が必要でした。
ここで記述したいのは、研究者が作成する論文です。
論理構造はしっかりしていますし、できることなら画面で読むだけでなく、必要に応じて綺麗に印刷できる方法が望まれました。
また、研究論文は他の論文の引用・参照をよく行います。
これらの参照を示されたとき、わざわざ改めて人間が「参照先」を入力しなくても、簡単に参照先の情報を入手する方法を作る必要もありました。
以上の問題を解決できる方法として、ティムは SGML (Standard Generalized Markup Language) を応用します。
SGML は 1986年に ISO で定められたばかりの国際規格でしたが、その元となったのは 1960年代に IBM が策定した「文章のタグづけ言語」(GML)でした。
SGML では、文章の中で「タイトル部分」「著者名」「章見出し」…などをタグで示すことができます。
SGML で大切なのは、タグを付けるのに特別なプログラムは不要で、すべてがテキストファイルとして作成できることです。
ワープロを使って見出しやタイトルを大きく表示すると、同じワープロ以外でデータを読むことはできませんでした。
しかし、SGML なら最悪の場合でも、テキストファイルとして読むことができるのです。
SGML は論理構造を示すことで、その後の機械処理を簡単にする目的がありました。
文章の部分ごとの意味がわかっていますから、見出し部分だけを抽出して目次を作るのも簡単ですし、著者名を元に検索を行うこともできます。
その応用の一つとして、SGML で書かれたタグを LaTeX に変換し、綺麗に組版して印刷する、と言うようなソフトウェアもありました。
これで、必要があれば印刷したい、という要求も満たせます。
他の論文への参照を簡単に示す方法としては、SGML を拡張する必要がありました。
そこで、独自の拡張を加えて、参照先として URL を記述できるようにします。
拡張した SGML は、HTML (Hyper Text Markup Language) と呼ばれました。
URL でデータの場所を簡単に示せるようになり、HTML でその URL によってハイパーリンクできる文章を作れるようになりました。
しかし、もう一つ仕事がありました。これらのデータを置いておき、自由に取り出せるサーバーを作らなくてはなりません。
FTP はファイルのやり取りを行うサーバーのプロトコルなので、FTP をそのまま流用することも可能でしょう。
しかし、FTP は非常に設計が古く、プロトコルは扱いにくいものですし、実は FTP では利用にアカウント認証が必要なのです。
アカウント認証など無しに、誰でもデータを取り出せるサーバーとの通信方法が必要とされていました。
これは、メール配信方法である SMTP (Simple Mail Transfer Protocol) が参考になりました。
名前の通り非常にシンプルですが、シンプルであるがゆえに、十分な拡張可能性を持っていました。
SMTP はメールを送り届けるためのプロトコルでしたが、これを拡張して、リクエストしたデータを送り返すプロトコルが作られます。
これは HTTP (Hyper Text Transfer Protocol) と名付けられます。
これで、必要なものが揃いました。
URL でプロトコルに HTTP を指定し、HTML データを入手して表示する。
テキストではないファイルが必要な際には、URL で FTP を指定し、ファイルを入手する。
HTML データの実態はテキストファイルなので、記述するのに特別なソフトは不要です。
HTTP の仕組みもメールとほぼ同じなので、メールが使えるコンピューターなら簡単にアクセスするソフトを作れるでしょう。
これなら、どんなマシン、どんな OS 上でも、簡単なソフトを作るだけで情報を交換できます。
1989年に概要を公表し、ティムは必要なソフトウェアの開発を始めます。
SGML の処理を行い、LaTeX のように整形して、Xanadu のように閲覧環境を整える。
…プログラムをするのは非常に大変そうです。
しかし、1988年に発売されたばかりの NeXT cube がありました。
NeXT は、グラフィカルなソフトウェアを簡単に作り出せる仕組みを備えたコンピューターでした。
NeXT で動作する世界初の WEB ブラウザが公開されたのは翌 1990年のことでした。
すぐに、グラフィック画面を持たないテキスト端末用のブラウザも開発されます。
これで、名実ともに「誰でも情報を閲覧できる」システムが完成したのは、1991年に入ってから。
このようなシステムの必要性を最初に認識したのは 1980年でした。
しかし、それが実際に作れる環境が整うまでに、10年以上の時間を必要としたのです。
時代が追いつき、やっと考えていたものが形に出来たのでした。
この時点でのブラウザは、テキストを閲覧する機能しかありませんでした。
図版が必要なら、別途ファイルとして FTP に置けばよい、という考え方です。
論文を交換するには十分でした。
なによりも、先に書いた通り、この頃のメールはテキストしか扱えませんでした。
SMTP をベースに作られた HTTP もまた、テキストしか扱えなかったのです。
そして、この時はまだ CERN と、CERN と密接な関係にある各国の研究機関の間で使用されるシステムに過ぎませんでした。
このあと、1993 年にマーク・アンドリーセンが NeXT用のブラウザとWEBサーバーを発見し、改造をして画像表示を可能にします。
1992年にメールに画像などのファイルを添付するための MIME と言う標準形式が定められており、SMTP が拡張されていました。
マークも、これに従って HTTP を拡張したのでした。
これもまた、時代によって環境が整えられたから付いた機能でした。
画像の表示をきっかけに WEB が急速に普及し、インターネットが拡大するのですが、それはまた別の話。
同じテーマの日記(最近の一覧)
関連ページ
日本最初のホームページ開設日(1992)【日記 13/09/30】
NCSA Mosaic 発表日(1993)【日記 15/04/21】
FireFox 初公開日(2002)【日記 13/09/23】
ダグラス・エンゲルバート 誕生日(1925)【日記 16/01/30】
別年同日の日記
申し訳ありませんが、現在意見投稿をできない状態にしています。 【あきよし】 １か月もたって書き込みに気付きました (^^; マーク、が正しいですね。指摘ありがとうございます。本文修正しました。 (2014-07-12 18:22:02)【lamspa】 久しぶりにXanaduが出てきて嬉しいです。マイク・アンドリーセンはマーク・アンドリーセンだと思います。 (2014-06-08 18:34:42) |
今日は ABCマシンの設計者として知られる、ジョン・アタナソフの命日(1955)。
誕生日の際に紹介記事を書いているので、詳細はそちらを。
同じテーマの日記(最近の一覧)
別年同日の日記
申し訳ありませんが、現在意見投稿をできない状態にしています。 |