目次
前のページ
2015-06-19 トーマス・Ｊ・ワトソンの命日(1956)
2015-06-22 IBM 産業スパイ事件(1982)
2015-06-22 node.js の雑感
2015-06-26 バーコードが初めて使われた日(1974)
2015-07-01 A Dark Room , Candy box! , Cookie Clicker.
2015-07-15 ファミコン・SG-1000の発売日(1983)
2015-07-16 原爆実験の日(1945)
2015-07-17 ＮＥＣの創業日(1899)
2015-08-12 旅行中のナビについて
2015-08-14 Windows10へのアップグレード
2015-08-14 Windows10 へのアップグレードで POPfile が動かなくなったら
2015-08-15 Windows10 へのアップグレードで Chrome が動かなくなったが
2015-08-15 Windows10のスタート画面
2015-08-25 ntsysv の名前の由来
2015-08-31 夏の終わりの素数
2015-08-31 DOSBoxで日本語表示・JP106キーボード・UBASIC
2015-09-06 X68k 復活
2015-09-07 ruby で数値演算
2015-09-12 レイ・ドルビー博士 命日(2013)
2015-09-14 引っ越し荷物の整理
次のページ
今日は、トーマス・Ｊ・ワトソンの命日(1956)。
IBM の初代社長です。起業した人かというとちょっと違うのだけど。
ちなみに、２代目社長となるトーマス・Ｊ・ワトソンはこの人の子供。
わー、なんだそれ。子供に自分と同じ名前付けるな。
ややこしいので、一般に父親は「シニア」または「ワトソン」、子供は「ジュニア」または「トム」（トーマスの愛称）と呼ばれます。
＃日本では名前はややこしくないようにするものだけど、欧米では親の名前を「受け継がせる」のもごく普通。
先日から、ハーバード・マーク１と IBM SSEC の話を書いてきました。
どちらも、IBM 公式には「自動計算機」ですが、それらはシニアの時代に作られています。
一方、IBM 701以降の「コンピューター」は、ジュニアに社長交代してから。
公式にどう呼ぶか、というだけの問題で、SSEC が事実上コンピューターと呼んでも差支えが無い機械であることは、SSEC の話題として書いています。
シニアの生涯…を語ったところで、Wikipedia と似たような記述になってしまうので、詳細を知りたい人はそっちを見てください。
英語記事の忠実な翻訳のようなので、それなりの信頼性はありそうですが、検証したわけではないので保証はしません。
ざっくりとだけまとめておきます。
田舎者だったシニアは、成人しても良い職に就けずに転職を繰り返します。
でも、やっと得たミシンのセールスマン（当時はミシンは高価で実入りの良い商品だった）の職を、酒の失敗でクビに。
さらに、この失敗が知れ渡り、どこも雇ってくれなくなります。
仕方なく自営の肉屋を始めますが、これも失敗。
商店を始めるために分割で購入したレジスター…当時としては最新の「計算機」…を処分するために販売元の NCR を訪れ、とにかく職も金もなく支払いが続けられないことを相談したことから、NCR に入社します。
ここで…ライバル社の機械を使っている店に行って、こっそり「破壊する」という汚い方法を使い、売り上げを伸ばします。
これでシニアの地位は上がり、中古レジスターの販売会社を任されると、そこでも「ダンピング販売してライバル店を潰す」という汚い方法を使い、トップシェアを奪います。
ただ、行き過ぎた販売行為に 1912年に独占禁止法で起訴され、一度は有罪判決に。
（これは、アメリカで初めての、独占禁止法による企業起訴でした）
シニアは上告し、様々な主張を行います。
政府は、控訴審の手間を惜しみ諦めます。これで無罪に。
NCR をトップシェア企業にし、訴えられたとはいっても結果は「無罪」となったシニアは、CTR 社に好待遇で迎え入れられます。
CTR は「コンピューティング・タビュレーティング・レコーディング」の意味で、パンチカード集計機の始祖である、タビュレーティング・マシーンズ社を元とした企業です。
さらに CTR 社で社長となったシニアは、社名を「インターナショナル・ビジネス・マシーン」社に改名。
これが IBM の名前の由来となります。
大会社のトップとなったシニアは、もう以前のような荒くれ者ではありませんでした。
汚い方法を使うようなことはありません。
IBM は、CTR の頃と同じようにパンチカード集計機を商売の中心としています。
ただし、ただ「販売」して終わるのではなく、その機械を商売の中でどのように使用し、どのように利益を出していくか、コンサルタントのような業務も行いました。
機械を販売するのではなく、機械を使って業務を改善する「サービス」を販売する。
そのサービスを買って良かった、と思えるほどの利益を出して見せる。損したとは言わせない。
そのためには、サービスを行う従業員を大切にしなくてはならないし、従業員はお客様の利益を第一に考えなくてはならない。
この頃に彼が掲げた IBM の標語「Think」は、お客様のために従業員の一人一人が何を出来るか考えよ、という意味です。
とにかく、シニアは従業員を家族のように大切にしたようです。
自身が若いころに酒で大失敗していたため、社員にも細かな飲酒規則を定めたようです。
これも、彼なりに社員を思っていたのでしょう。ジュニアはこれに懐疑的だったようですが。
多くの社員が協力した IBM ASCC が…勝手に「ハーバード・マーク１」と名前を変えられ、IBM の協力があったことを一切語られなかったことに激高した、というのも理解できます。
ASCC の雪辱を晴らすべく SSEC を作った時に、これを「コンピューター」と呼ばなかったのも、当時「コンピューター」は IBM の社員の肩書だったためでしょう。
社員が誇りをもって行っている仕事を、決して機械なんかに奪わせたりはしない。社員を大切にする、という意思の表れのように思います。
こちらも、想いは立派でも当時の世相としては、IBM を時代遅れにしかねない考えだったため、ジュニアに代替わりしたらすぐに IBM 701 「コンピューター」を発表しています。
同じテーマの日記(最近の一覧)
関連ページ
トーマス・Ｊ・ワトソン 誕生日(1914)【日記 16/01/14】
トーマス・Ｊ・ワトソン 誕生日(1874)【日記 16/02/17】
別年同日の日記
申し訳ありませんが、現在意見投稿をできない状態にしています。 |
今日は IBM 産業スパイ事件の発覚した日(1982)。
日本のコンピューター業界を震撼させた事件でした。
今となっては日立と三菱がスパイをやった、という程度の、企業が行き過ぎただけの話だと思われているけど、これ「国策」の一環が暴走したのです。
日本のコンピューター開発は…どこまででも遡れますが、FACOM 100 の話から始めましょう。
富士通の池田敏雄が設計し、1954年に完成したコンピューターで、リレー式でした。
名前は似ていますが別会社の富士写真フィルムは、1956年に FUJIC を完成します。
これが、日本で最初の真空管式コンピューターでした。
技術者であった岡崎文次が、レンズの設計のために独自で開発したもので、会社としての関与はありません。
IBM の SSEC の影響を受けています。
1959年には、東京大学が中心となり、東芝・日立が協力し、TAC が完成します。
実は、FUJIC よりも先に開発が開始された、国の予算をつぎ込んだ国家プロジェクトでしたが、目標が野心的過ぎ難航、何度も設計変更を繰り返しています。
その影響もあり、完成した時にはすでに時代遅れでした。
こちらは EDSAC の影響を受けています。
1964年には、通産省の予算で富士通・沖電気・日本電気が共同で FONTAC を作成。
この頃から、各社が「コンピューターの作り方」を理解し、独自開発を開始します。
日立の HITAC、富士通の FACOM、日本電気の NEAC、東芝の TOSBAC 、三菱の MELCOM、沖電気の OKIMINTAC…
通産省は、この状況に危機感を持ちます。
コンピューターは、これから確実に産業の中心となる、というのは誰の目にも明らかでした。
1970年代初頭、ＩＢＭが巨大メーカーに成長しつつありました。
日本国内だけで６社も互換性のないコンピューターが乱立していては、これらの大企業に潰されてしまいます。
そこで、通産省では、「国内で、ＩＢＭに対抗できるコンピューターを育てる」ための対策を行います。
方法は３つ。
1) ＩＢＭと技術提携を行わない、ＩＢＭ互換機路線
2) ＩＢＭに対抗できる大企業の互換機路線
3) 日本独自路線
2 の大企業とは、事実上ハネウェル社です。
1960年代、アメリカには８つのコンピューターメーカーがあり、「IBM と７人の小人」と呼ばれていました。
ハネウェルはその一つでありながら、1970年に MULTICS の技術を持つＧＥ社と合併し、力を伸ばしていました。
通産省の指導の元、国内の各社は上のいずれかの道を選び、提携することが求められました。
まず、富士通と日立はすでにＩＢＭ互換機を作成していたため、互換路線を選びました。
日本電気はすでにハネウェルと提携していました。
東芝も、すでにＧＥと提携していましたが、ＧＥがハネウェルに吸収合併されました。
そこで、日本電気と東芝も提携し、ハネウェル互換路線を選びます。
三菱・沖電気は「取り残された」形で提携し、独自路線を歩むことになりました。
さて、時間を一気に進め、産業スパイ事件の話へ。
富士通と日立は提携し、技術的な交流は図りつつもお互い独自に、IBM System/370 の互換機を作成していました。
これ、互換性を持つ機械を独自技術で作成している、という形で、IBM との技術提携はありません。
ただし、IBM で System/360 （370の旧世代機）を設計した技術者で、後に独立したジーン・アムダールの会社と富士通は提携し、技術的ノウハウを得ていました。
1981年、IBM はこうした「互換機」が世界中で増えていたため、設計を一部変更して、性能を上げるとともに互換機を作りにくくした、System/370-XA を発表します。
日立はこの「設計変更」の詳細を入手しようとして、IBM のおとり捜査に引っかかり、1982年の今日、社員５名が逮捕されます。
＃この時、日立社員５人と共に、三菱社員１名も逮捕されています。
三菱は当初は「独自路線」グループでしたが、この頃には余りに強くなった IBM の互換機を作ろうとしていました。
この刑事事件は、司法取引により決着。しかし、IBM から、民事損害賠償訴訟を起こされます。
System/370-XA は、各種回路が特許で守られていたうえ、それまでは後から読み込まれるソフトウェアであった「OS」の一部を、ハードウェア内に持つようになっていました。
（現在でいう、BIOS に相当するもの）
System/360 や 370 の頃は、同等の機能の回路で置き換えも可能でしたが、370-XA の特許は強力で、簡単には回避できません。
また、BIOS に関しては単純な回路ではなく、プログラム…著作物です。
著作権の場合「類似したもの」を作ったとしても、盗作としてアウトです。
＃少なくとも、この時点では IBM はそのような認識で動いていた。
ずっと後に、IBM・コンパックが BIOS の著作権を争い、現在は違う認識となっている。
結局、日立は IBM の許可を得ずに機械を販売しないこと、訴訟費用は全部日立が負担すること、ソフトウェアやインターフェイスなどに関して、使用する対価を払うこと…などを条件に和解します。
日立からすれば、IBM 互換路線に「お墨付き」を貰った格好で、この後も互換路線を進みます。
富士通も日立の訴訟に危機感を持ち、同様の取引を結びますが、徐々に IBM 互換路線から非互換路線にシフト。
いずれにしても、通産省の狙った「独自技術による互換」という路線は無くなってしまったことになります。
この頃は、IBM が強くなりすぎてハネウェル社もコンピューターから事実上の撤退。
特に、吸収合併したＧＥの互換機は消滅し、ＧＥ互換だった東芝も撤退、同じグループだった日本電気にコンピューター部門を売却しています。
独自路線だった三菱・沖も、先に書いたように三菱がＩＢＭ互換路線に進もうとして、スパイ事件に発展。
沖電気は、コンピューター本体は断念して、周辺機器製造に特化しています。
国策だった３グループ化は大失敗。日本のコンピューター産業は死んでしまう…。
「ＩＢＭ産業スパイ事件」とは、そうした危機的な状況を意味する事件だったのです。
翌1983年、日本電気がスーパーコンピューターの新シリーズ、SX-2 を発表します。
（シリーズ最初の機種が 2 で、後に廉価版の 1 を発売）
この SX-2 は、世界で初めて GFLOPS を超えたコンピューターで、同時に初めてアメリカ以外のコンピューターが速度で世界一になった機械でした。
日本のコンピューター産業復活の狼煙、でした。
…この後、急に力を付ける日本のコンピューター業界にアメリカが危機感を感じ、1980年代後半から90年代前半の貿易摩擦につながっていきます。
同じテーマの日記(最近の一覧)
別年同日の日記
申し訳ありませんが、現在意見投稿をできない状態にしています。 |
ここ１年くらい、仕事で node.js をいじっているのだけど、ちょっと愚痴を書いてみる。
node.js が流行したのはもう何年も前のこと。
Apache よりずっと速く処理できる、ということだったけど、仕事でそこまで処理速度が必要なことはやっていなかったし、その時は、ふぅん、そんな技術もあるんだ、という程度。
１年ほど前に、WEB socket 使いたい仕事があって調べたら、node.js を使うのが一番やりやすいとわかった。
最初はよくわからない技術だったけど、その後それなりに実績もあるようだし、使ってみようと思った。
と書いたところで、相変わらず node.js がマイナー技術だという認識なので、コイツが何者であるかを最初に説明しよう。
今これを読んでくれている人は、おそらくPCかスマホの WEB ブラウザで読んでいるだろう。
多分、そのブラウザには Javascript というプログラム言語の実行環境が備わっている。
プログラムなんてどんな言語でもそれほど大きくは変わらないものだけど、それぞれ特徴はある。
Javascript の最大の特徴は、WEB ブラウザという「利用者が直接使う部分」に密着する様に作られている、ということだ。
人が使う部分…フロントエンドとか、ユーザーインターフェイスとか言われるけど、その部分はとにかく人を待たせてはいけない。
Javascript も、「人を待たせない」ことを理念として作られている。
具体的に言うと、「１秒待つ」とか、「ユーザーの入力を待つ」とか、「ファイルを開いて内容を得る」なんて考え方が無い。
これらは、パソコンの計算速度に比べると、途方もなく遅いからだ。
代わりに存在しているのが、「１秒後に関数呼び出し」「ユーザー入力が終わったら関数呼び出し」「ファイルの内容を引数に関数呼び出し」というように、とにかく待つ代わりに「あとで呼び出して」と依頼しておく方法。
このプログラム方法、初心者にはとてもわかりづらい。
まぁ、初心者にわかりづらい、なんていうのは些細な話。
ブラウザだから、ユーザーを待たせないことが第一で、そのためにはプログラマーが苦労するのは当然なのだから。
でも、ブラウザに限らず、プログラムが「待たせたくない」場所は多い。
サーバーは人が使わないから多少遅くてもいい…と言われたのは昔の話で、今は多数のサーバーアクセスを高速にこなすことが求められている。
だって、クラウド時代だもの。昔とはサーバーの接続量がケタ違い。
で、Apache …というか、その上でよく使われる PHP は「ファイルを開いて内容を得る」とか「SQL にクエリを投げて、返事を待つ」とか、とにかく遅い動作が多い。
これ、Javascript みたいに「終わったら関数呼び出し」にしたらいいんじゃない？ というのが、node.js の基本的な発想。
google が作成し、chrome に搭載されている Javascirpt のエンジンを使って、サーバーで動作できるようにしてしまった。
書ける人が多い Javascript がサーバーでも使える～というような説明も見るのだけど、これはミスリードだと思う。
主眼は Javascript を使うことではなくて、「待たせない」プログラム手法がすでに確立されている言語を使うこと。
先に WEB socket を使うなら node.js と書いたけど、これは実のところ node.js である必要はない。
WEB socket というのは、TCP/IP ソケット上で実現されている HTTP 接続の上で、TCP/IP のような「ソケット」を実現しよう…という、回りくどい技術。
でも、HTTP というのは、TCP/IP の機能の、ほんの一部を利用して作っているんだ。
それを拡張し、再度 TCP/IP のような汎用性を持たせれば、メリットは計り知れない。
じゃぁ TCP/IP 使えばいいじゃん、となりそうだけど、WEB socket だと、HTTP の延長上にあるので WEB ブラウザから使いやすい。
Apache + PHP だと、Apache が完全に HTTP を前提に作られているので、WEB socket は扱いにくい。
そこで、node.js の出番となる。
実のところ、WEB socket はまだブラウザごとに実装が一部食い違ったり、実装していないブラウザもある。
そういう場合でも、node.js 上のライブラリ、socket.io が、ブラウザごとの差異を隠してくれる。
さて、前提条件の話だけでずいぶん長くなったな…
node.js + socket.io の勉強を始めた時は、右も左もわからなかったので、分かりやすいチュートリアルに従って使い始めた。
そのチュートリアル自体が多少古いものだったので、Express ver.2.x を前提としていた。
この Express は、node.js 上で動く WEB サーバー。
当時の socket.io では、WEB サーバーが前提として必要だった。
でも、実はこの時点で Express の最新版は 3.x だった。
判っていたけど、3.x 対応の使い方説明で良いものがなかったので、「後でバージョンあげられるでしょ？」と思って、古いバージョンを使った。
…で、話は一気に最近へ。
Express は v2 と v3 と v4 で、全然互換性が無い。
いや、全然というのは間違いか。でも、ずいぶん書き変えないと動かない。
socket.io も、v0.9 が長い間使われていたけど、v1.x 系列となった。
こちらも、かなり書き換えないと動かない。
メールを扱おうと思って nodemailer というライブラリを使った。
これも、v0.7 から最近 ver1.0 になり、かなり書き換えないと動かない。
互換性を保てない設計変更が悪い、とは言わない。
最初から完璧な設計なんてできないし、作り進めるうえで変更しないといけないことも多いだろう。
でも、node.js の界隈は、互換性を気にしている人なんて誰もいない、というように思える。
理由は二つあって、node.js を使う最大の理由が「速度」だというのが一つ。
過去との互換性を気にして速度を落とすなんて馬鹿馬鹿しい。効率のためには互換性を切ったっていいだろう。
もう一つ、おそらくは「後から関数を呼んでもらう」というスタイルのプログラムは、速度効率は良いかもしれないけど、互換性を保ったまま拡張することが困難になりやすい。
多分、多くの原因はこちらだろう。
これは自分がプログラムしていて困った部分だけど、ループ処理している部分があった。
その中で、扱う値を「SQL DB に入っている値を参照して」扱いを変えなくてはならない、ということになった。
これ、絶望的なプログラム書き換えを伴う。
PHP なら、SQL に問い合わせて、答えを見るだけだ。
でも、node.js では、SQL 問い合わせは関数を呼び出してもらう必要がある。関数が増える。
この関数は、「後で」呼び出されるものだ。すぐに答えを得られるわけではない。
でも、ループしているのは「全部を処理する」ためのループではなく「順次処理する」ためのループだった。
１つの処理が終わってから次の処理に入らないといけない。
処理の中の DB 問い合わせが、すぐに結果を得られないため、ループそのものを解体する必要が出てきた。
ループの中身を関数として書き出し、関数の中で DB 問い合わせをし、結果を貰うための関数を呼び出す。
結果で呼び出される関数の中でループ変数にあたるものを操作し、必要であればループの中身にあたる関数を呼び出すことで「ループ」を構成する。
再帰プログラムのようで、再帰ではない。
だって、呼び出しは遅延して行われるのだもの。DB 問い合わせした後に関数は終了し、スタックは解放されるので、再帰階層が深くなってもメモリを馬鹿食いしたりはしない。
逆に言えば、スタック解放されるからローカル変数は使えない。
グローバルをやたら増やしたくはないから、クロージャのように関数内で変数と関数を定義して、「解放されないローカル変数」を作り出す必要がある。
複雑怪奇なプログラムになった。
こういう大幅な書き換えがあると、呼び出し方法も変わることが多い。
そう、つまり、ライブラリ作者たちも同じような理由で呼び出し方法を「変えざるを得ない」ことがあるのではないかな、と思う。
Apache + PHP だと、ロードバランサ―を使って多重化できる。
万が一サーバーが死んでも大丈夫。
PHP は、アクセスの度に呼び出される。エラーが起きても、次のユーザーの接続で再起動される。
でも、node.js はそうではない。Apache にあたる、サーバー自体を書いている。
正しくエラーハンドリングすれば止まることはないのだけど、止まったら致命的。
でも、多くの人が同じ悩みがあるから、cluster を作ることができる。
複数のプロセスを同時に起動しておいて、どれかが止まっても大丈夫なようにするのね。
この cluster 化の方法が、多くの人が考えたため、たくさんある。
プログラムを大幅に書き変える必要がある物から、簡単に cluster 化できるものまで。
最近の流行は pm2 のようだ。
クラスタ化するだけでなく、接続を出来るだけ保ったまま、順次プログラムの再起動も出来る。
＃socket.io は「ずっと通信路を保つ」ため、この通信路はどうしても切れてしまう。
socket.io 自体に、通信が切れたらすぐ再接続する仕組みはあるが、再接続後に先ほどと同じ状況を整えるのはプログラムが責任を持つ必要がある。
もっとも、これは pm2 と関係なく、いつ通信が不安定になるかわからないので、作らないといけない処理だ。
で、この pm2 を使おうとしたら、socket.io はおかしくなる。
socket.io はそのままではクラスタ対応できていないのだ。
まぁ、PHP だって、ロードバランサを使う時には守らないといけない決まりがある。
これは当然だろう。そして、socket.io も、いくつかの決まりを守ればクラスタ化できる。
…うまいくいかない。
この作業、半年くらい前に一度やって、どうしてもうまくいかないので一度断念した。
最近再チャレンジして、理由がわかった。
socket.io の v0.9 までは、クラスタ化に対応いしていたのだけど、v1.0 になった時に対応を「外部に任せた」のだった。
いや、そのことは知っていたよ。
多くのページがその方法を書いているから、その通りにしたのだけどダメだった。
で、知識が増えて再チャレンジして、多くのページが勘違い記述していることを知った。
世の中の半数以上のページが v0.9 前提で書かれていて、残る半数のうち、８割以上が 0.9 から 1.0 になって、新たな記述方法となったことを伝えている。
でも、そうじゃない。v1.0 になって、概念が変わった。細分化された。
クラスタ対応は「通信」と「ハンドシェイク」の２段階に分割され、多くのページに書かれているのは「通信」の対応だけだったのだ。
通信はできるが、ハンドシェイクにすごく時間がかかるようになる。
＃socket.io は、ハンドシェイクのために２回アクセスを行う。
この２回が同じサーバーなら成功して通信に入るが、違うサーバーだとリトライする。
確率問題で成功するまで、延々リトライを繰り返すため、接続に時間がかかるようになる。
socket.io の公式ページの奥底に、ハンドシェイクは外部の別プログラムに任せる、ということと、推奨するライブラリが書いてあった。
でも、このライブラリは、pm2 とは違う cluster 化ライブラリを前提としていた。
そのライブラリは、確かにクラスタ化してくれるが、低機能で役に立たない。
探し回って、やっとわずかな情報で socket.io のハンドシェイクをクラスタ対応にする方法がわかった…ように思えた。
方法は二つあった。
１つは、大幅に socket.io の接続部分を書き変える方法。
もう一つは、それをライブラリ化したもの。
ライブラリの方を使ってみたら、うまく動かない。
どうやら、socket.io やその他もろもろのライブラリに依存してしまうようだ。
バージョンが変わるごとに非互換になるので、こういうことになる。
大幅に書き換えが必要な方は、まだ試していない。
その書き換え方法が、どのバージョンでつかえるのか明記されていないため。
でも、node.js の歴史自体が浅く、まだバージョンによって互換性が致命的に失われることを理解している人が少ないため、バージョンを明記した記事はあまり見かけない。
自分が求めている方法を見つけては、試しに自分のプログラムに組み込んでみて（場合によっては非常に大きな書き換えを伴う！）、ダメだったら自分の勘違いなのかバージョンが違っているのかを理解して、多くの場合は「諦め」て別の情報を探す、という決断が必要となる。
と、以上は node.js に対する愚痴でした。
node.js を使いこなしている人から見たら、入り口付近で悩んでいるだけかもしれない。
ライブラリも全部 javascript で書かれているから、自分で解析して書き変えてしまう、という方法もなくはない。
でも、今後のバージョンアップ（と、そのたびの非互換性）を考えると、手を加えるのは得策でないように思う。
別年同日の日記
申し訳ありませんが、現在意見投稿をできない状態にしています。 |
今日はバーコードが初めて使われた日(1974)。
バーコードが作られるまでの長い歴史と、その仕組みは過去に書いています。
ちなみに、基本アイディアの発明者は学生だったけど後に IBM に入社し、特許を IBM に売却しています。
IBM はさらに RCA 社に特許転売。特許の中で、読み取り装置にどうしても RCA 社の部品が必要だったためです。
RCA 社は特許活用を狙いますが、特許で出されていたアイディアそのままではうまく使えませんでした。
ふたたび、特許出願者も参加して（つまり、IBM も参加して）実用にすべく改良がおこなわれます。
結果として、現在の「バーコード」を考案したのは IBM です。
もちろん、最初の読み取り機付レジスター…POS 端末、と後に呼ばれることになるものも、IBM 製。
で、今日はその「バーコードシステム」が初めて市場で使用されるようになった日。
バーコードを使用する第１号店は、オハイオ州のスーパーマーケットでした。
最初に購入されたのは、「10パック入りフルーツガム」。購入時刻は朝８時１分でした。
このガムは、購入時のレシートと共にスミソニアン博物館で保管展示されています。
この少し前から、食品業界は「バーコード」を正式採用し、いくつかのメーカーではバーコードを商品パッケージに直接印刷していました。
10パック入りフルーツガムも、そうしたバーコード印刷済み商品の一つ。
でも、まだ印刷されたない商品も数多くあります。
そんな商品には、１枚づつシールにコードを印刷して店員が貼っておく必要があります。
バーコードは、元々こうした「簡易印刷機」で扱いやすいように工夫されたコードでした。
元々線で構成されていますから、用紙が「引っ張られる」方向に線を引いておけば、多少滲んだとしても線の幅は変わらないのです。
同じテーマの日記(最近の一覧)
関連ページ
別年同日の日記
申し訳ありませんが、現在意見投稿をできない状態にしています。 |
日記でゲームのことを書くことはめっきり減りました。
子供が生まれる前は良く書いていたのだけど。
で、今日書きたいのは A Dark Room 。
無料で遊べる、Javascript のゲームです。
海外では 2013年後半ごろに話題になったようで、作られたのは５月ごろみたい。
でも、当時は英語版しかなかった。
このゲーム、文章がかなり重要なので、日本人にはハードル高くて、それほど話題にならなかったようです。
今は日本語対応しています。
でも、もう旬を過ぎたのであまり遊んでいる人いないみたい。
やっぱり、日本では話題になっていない。
ゲームを始めると、ブラウザの左上にそっけない文字が書かれています。
|
火は消えている. 部屋は凍える寒さだ. |
暗い部屋
火をつける |
これだけ。
火をつける、は枠が描かれていてボタンなのかな、と思えるので、押してみましょう。
左側に新たな文章で状況説明が出ます。
|
火は燃えている. 火の光は窓から暗闇にこぼれだしている. |
「火をつける」は、色が薄くなり、「薪を燃やす」に変わります。
背景に縮む帯が出て、ボタンが押せなくなる。
…これ、行動制限を示しているようです。帯が縮み切れば次の行動を出来る。
非常に簡単なゲームなので、多くは説明しません。
ちょっと驚く仕掛けが次々と現れるので、自分で体験してみてください。
どんどんできることが増えて、仲間が増えて、村を作り、冒険に乗り出すことになる。
でも、自分が出来ることは基本的に「押すとその後しばらく押せなくなるボタンを押す」ことだけ。
いや、後半は別の操作が中心になるかな。
でも、やっぱりボタンを押すことは大切。
すべての状況は、短い文章で表示されます。
これが非常に良い雰囲気。文章と文章の「行間」を感じさせて、足りないところは自然に想像がはたらき、自分が物語世界を感じていくのがわかる。
このゲームは全て、「感じ取る」ことが重要なようです。
最初に「火をつける」のボタンを押す際も、何の説明もありません。ボタンに見えるから押したくなるだけ。
どんどん新しい状況になり、表示が追加されても、それが何を意味するのか、一切説明はありません。
自分で想像し、ルールを把握して行くことが中心のゲーム。
最初はなにも明かされていませんが、だんだんこの世界が何であるかわかってきて、最終目的が見えてきます。
最終目的を達成できればゲーム終了。
でも、ゲームはそれで終わりではありません。２周目が始まる。
先に書いたように、「ルールを把握する」ことが大切なゲームなので、２周目はつまらない…
なんてことはない！
２周目になって初めて起きるイベントもあります。
何度も遊んでみないとわからない仕掛けが沢山。
これは、話題になった理由もわかります。
日本語化された今、是非遊ぶべきゲームです。
さて、ネタバレするとつまらないのでこのゲームについてはこれ以上書かない。
ゲーム名で調べると攻略ページなんかもあるけど、このゲームは「ルールを自分で把握する」のが楽しみの８割なので、ネタバレはゲームをつまらなくするだけ。
…と書いておきながら、別のゲームの話題を書きます。
別のゲームと言っても類似点があるので書くわけで、それ自体がネタバレになるかもしれないのだけど。
同時期に、Cookie Clicker というゲームが流行しました。こちらは８月発表、らしい。A Dark Room が話題になった後だね。
こちらは文章はさして重要ではないゲームだったので、日本でも異常な盛り上がりを見せました。
パロディもあったくらい。
僕も Cookie Clicker は遊んでみて、衝撃を受けました。
テレビゲームを作っていた人間として、あんなゲームの作り方があるなんて思いもしなかったから。
元ネタともいえる A Dark Room や、後で書く別のゲームを知らなかったから、余計に衝撃が強かった。
でも、最近 A Dark Room を知ったので、Cookie Clicker はいきなり現れたわけではないと理解できました。
一応、当時の騒ぎを知らない、もしくは知っていても遊んだことは無い人のために、簡単な解説をしておきましょう。
Cookie Clicker は、クッキーをクリックするだけのゲーム。
表示されているクッキーをクリックすると、クッキーが１個生産されます。
生産枚数は数字で表示されていて、押すたびにカウントが上がっていく。
このクッキーを増やしてどうするのかというと、クッキーを自動生産するアイテムなどが買える。
生産してアイテムを買い、それで増えたクッキーでさらに高価なアイテムを買う…というゲーム。
特定条件で開示される「実績システム」とか、最近のゲームによくありがちな仕掛けがちゃんと入っている。
やることは「クッキーを作る」だけなのに。
そして、このゲームがすごいのは、「リセット」が重要な事。
ゲームをリセットすると、もちろん最初からやり直しなのだけど、先に書いた「実績」は残っている。
さらにリセットするともらえるボーナスもある。
これらの「実績」や、ボーナスは、クッキー生産時に「倍率」としてかかってくるので、リセットするたびに自分が強くなる。
このゲーム、かなり時間を使うから、リセットすると「それまでの時間が無駄になる」気がして最初は怖いのだけど、リセットしてからが本当の意味でのゲームスタートだと思います。
何回もリセットしていると、１クリックで１京（10の16乗）のクッキーが生産できるようになります。
これ、リセット無しだと絶対たどり着けない。リセットしてからが本番、というのもそのためです。
「クッキーを作るだけ」という根幹システムの単純さに比して、周辺の仕掛けが大がかりです。
アイテムなどのグラフィックも併せ、このトチ狂った世界観がウケて大ヒットしましたが、ゲームとしてもよく出来ています。
ゲーム制作側にいた人間としては、「おまけ」だったはずの実績システムなんかをゲームのメインに持ってきたところや、恐ろしいほどの点数のインフレに衝撃を受けたのね。
さて、A Dark Room と Cookie Clicker は、どうも共通の「祖先」を持つようです。
話題になったベースを元に、別々の人間が、別の方向で洗練させたのが２つのゲーム、という意味ね。
元になったのは Candy box! というゲーム。
１秒に１個、勝手に Candy が増えて行って（数字表示のみ）、「食べる」「投げ捨てる」というボタンだけが表示されているゲーム。
これも、ある程度キャンディを溜めると、別のアクションができるようになっていきます。
遊んでみると、なるほど、共通の祖先だ、ということがよくわかる。
Candy box! は、基本的に文字だけです。でも、アスキーアートは結構使っている。
文字と簡単なアスキーアートだけ、というのは、おそらくは UNIX 初期のアドベンチャーゲームみたいなのを作ろうとしたのではないのかな、と想像します。
というのも、このゲームは「アドベンチャーゲーム」だから。
キャンディを集めるところから始まるのだけど、最終的には順番にフラグを立てていく、その過程を楽しむゲーム。
（僕はアドベンチャーゲームが好きではないので、残念ながらあまり面白いと思えなかった）
ただ、普通のアドベンチャーゲームと違ったのは、「増えていくキャンディ」を通貨としていること。
その過程で、キャンディを使ってキャンディを生産する、錬金術のようなシチュエーションが登場します。
A Dark Room は、アスキーアートも排して極力文字だけで表現しています。
この文字だけの世界が、ゲームというより「物語」を感じさせる。
体裁としては Candy box! と似た始まり方なのだけど、こちらはアドベンチャーゲームではないです。
刻々と変わる状況を乗り切る、シミュレーションに近い感じ。Candy box!のような「生産活動」もあるのだけど、錬金術ではなくてもっと経済的。
アドベンチャーゲームではないのだけど、状況が言葉で説明されるし、言葉の選び方が巧みなので物語を感じさせてしまう。
ちょうどこの頃、「ナラティブ」って言葉がゲーム業界で流行したんだよね。
物語を「語る」のではなく、「感じさせる」ゲーム。A Dark Room もそういう流行と無縁でないように思います。
Coockie Clicker は A Dark Room とは逆方向の進化。全てを美しいグラフィックにしました。
世界観は先に書いた通り、狂っている。不条理とかのレベルではない。
Cookie を使って Cookie を作り出す、という錬金術こそがこのゲームのすべて。
実のところ、 Cookie Clicker は Cow Clicker というゲームに対する皮肉として生まれたのだそうです。
Cow Clicker というのは、ネットサービスでユーザーをつなぎとめるための「ポイントを貰える」だけの存在。
１日１回だけクリックできて、ポイントが溜まります。
この、面白くもなんともないものを、提供会社が「ゲーム」と呼んでいたので、クリックするだけで本当に面白いゲームを作ろうとしたのが Cookie Clicker なのだとか。
でも、Candy box! の影響は強いように思います。
お菓子を農場に投入して（種として植えて）、結果お菓子がすごい勢いで増える…なんて、まったくそのまま。
A Dark Room の影響もうけているのではないかな。Candy box! 程の影響は感じないけど。
Cookie Clicker は、β版も公開されていて、「実験中」のプログラムなどが入っていました。
結局公開版に統合されなかったけど長い間実験されていたものに、「ダンジョン」がありました。
Rogue みたいに自動生成されるダンジョンがあって、その中で自動的にキャラクターが冒険し、クッキーを持ち帰るの。
実は、candy box! にも自動的に行われる「冒険」があって、それを取り入れたかったみたい。
ネタバレになりますが、A Dark Room にも類似のものがある。
日本では Candy box! も A Dark Room もあまり知られていないので、この手のゲームは「Cookie Clicker 系」と呼ばれています。
でも、アメリカでは「Candy box! like game」らしい。
なるほど、３つとも遊んでみたら進化の過程がわかりました。
結果として全然違うものになっているのだけど。
というわけで、３本のゲームを紹介してみました。
関係性があるし、ゲーム的にも似ているのだけど、面白さのポイントは全く別。
遊んでみたい方は、以下へどうぞ。
別年同日の日記
申し訳ありませんが、現在意見投稿をできない状態にしています。 |
今日は、任天堂のファミリーコンピューター、およびセガのSG-1000・SC-3000（上位互換期）の発売日(1983)。
32周年です。0x20周年です。区切りの年です、と無理やり言っておきます。
ちなみに、SC-3000はSG-1000にキーボードが付いた「パソコン」ね。
中学の時に友達が持っていて、しばらく借りてプログラム作ったことがあります。
ほんの数年前まで、ファミコンもSG-1000も、発売が「1983年７月」というだけで、正確な日付まではわかっていませんでした。
でも、３０周年を前にして日付を特定しようと一部の方々ががんばって、共に15日の新聞に「本日発売」と広告が出ているのを見つけ出しました。
素晴らしい成果です。
僕もコンピューター関係の歴史調査を趣味にしているので、そういう素晴らしい成果を出したいとは思うのですが、なかなか難しい (^^;;
２年前に、30周年を祝う話は書いていますし、その関連でいろいろな話題を書きました。
なので、過去の記事へのリンクをまとめておくだけにします。忙しいので手抜きです（笑）
＃結構語りつくしたので、もう書きたいことが無い、というのが実情なのですが。
→さらにその後掘り下げて書いた、世界初のテレビゲーム
80年代の画面表示技術
→基礎知識
→MSX編（SG-1000は、MSXと同じ画面表示回路を使っています）
ファミコンとMSXはどちらが速いの？ という内容で書いた一連の記事。
MSXとSG-1000のCPU・クロックは同じですので、ゲーム機のライバル対決と読み替えていただいても。
ファミコンって、生産終了から14年間も修理サポートしてました。
山内さんの誕生日にかこつけて、僕のファミコンの思い出話を書いただけ。
同じテーマの日記(最近の一覧)
別年同日の日記
申し訳ありませんが、現在意見投稿をできない状態にしています。 |
今日はアメリカ軍がアラゴモード砂漠で、プルトニウム原爆の爆発実験を行った日です。
トリニティ実験、と呼ばれています。
この日以降、世界は「核の時代」に入った、とされます。
…気の重い話題だ。日本人として、特に気が重い。
でも、主にコンピューターの歴史で「今日は何の日」を書いている以上、触れないわけにはいかない話題だと思うのです。
原爆の開発プロジェクトが「マンハッタン計画」と呼ばれているのは有名です。
当時、核物質が強いエネルギーを持っていることはわかっていましたが、爆弾に応用可能かどうか、は未知でした。
そのため、爆弾を作成するのであればどんな核物質が適切か、というところから研究が始まっています。
主な対象となったのは、すでに知られていた核物質である「ウラン」と、見つかったばかりの核物質である「プルトニウム」。
ウラン型の爆弾は、論理計算のみで製造がおこなわれました。
一方、プルトニウム型の爆弾は、爆発実験が行われました。
1945年の今日行われたのは、このプルトニウム型の爆発実験。
実験は成功し、後に長崎に投下されています。
（広島に投下されたのは、ウラン型でした）
当時はまだ、電子計算機は作られていません。ENIAC は開発が進んでいましたが、完成は大戦終結後です。
でも、Harvard mark I (ASCC) はありました。
原爆の理論を完成させるには膨大な計算が必要で、ASCC ではその計算の一部が行われています。
（ASCC で計算されたのが、ウラン型・プルトニウム型のどちらのものだったのかはわかりません。）
良く言われる、コンピューターが「戦争の道具として開発された」というのは適切ではありません。
どちらも、学者が「面倒な計算を行ってくれる道具」として着想したものです。
しかし、それが戦争の道具として「利用」されたのは事実です。
日本が「精神論」で戦争に勝とうとしていたことは、たびたび批判されます。
しかしそれは実は日本だけではなく、アメリカも第１次世界大戦中は同じで、非常に多くの死者を出したのです。
そこに目をつけ、ヴァネバー・ブッシュが戦争に「知見」をもたらします。
実は、体よく予算をぶんどって大学・学者にばら撒くのが目的だった節はあるのですが、ともかくアメリカは知力を結集して戦争に望みました。
原爆等という想像を超えた兵器を着想したのも学者ですし、そのために計算力が必要となれば、ASCC のような計算機も利用されています。
間に合わなかったとはいえ、ENIAC のような新型計算機の開発にも予算が配分されました。
Whirlwind I だって戦時中に軍が予算を付けて開発を開始したものです。
戦争ですから、まさに「殺るか殺られるか」の世界。
わずかでも計算速度が遅ければ、敵の攻撃を受けて終わり、かもしれません。
とにかく、速度の速い計算機が求められました。ENIAC などは、その延長上にあるアイディアだったから予算が付いた、とも言えます。
今でも、計算機は速度が最重視されているように思います。
1980年代のパソコンなど、速度以外にも多様な評価軸があったように思うのですが。
話を核爆弾の実験に戻しましょう。
ウラン型とプルトニウム型は並行して作成されていましたが、プルトニウム型だけが爆発実験を行っています。
実験に先立ち、１通の報告書が大統領に提出されました。
報告書の作成者は、マンハッタン計画に参加したジェイムス・フランクを中心とした７人の学者。
このことから、報告書は「フランクレポート」と呼ばれます。
既に、核爆弾を日本に対して使用することは決定されていました。
＃これに関してはいろいろあります。
開発開始時にはドイツを標的にしていたようですが、チャーチル英首相とルーズヴェルト米大統領の会談で、ドイツ降伏前・原爆完成前から日本を標的とするようになっています。
陸続きのヨーロッパで強力な兵器が使われてはかなわないので、島国で…という意図もあったかもしれません。
しかし、フランクレポートでは、その前にデモンストレーションとして実験を行い、それを使用することを日本に通告するほうが良い、としていました。
このレポートでは、各国が核兵器を持ち、互いに疑心暗鬼になる「冷戦」状態が戦後に生じる危険性を示唆しています。
技術はやがて普及するものですから、各国が核兵器を持つのは時間の問題。
冷戦を避けるためには国際協力が不可欠で、アメリカが率先して国際的な信頼を得なくてはならない、としています。
そこで、日本に対して核兵器使用を通告し、降伏を促す、という紳士的な態度が重視されるのです。
この報告書を受け、実験は行われました。
ただし、その実験成果をどのように世界に公表するかは、あらかじめいくつものシナリオが考慮され、実験結果を見てから決定されることになりました。
シナリオには、その破壊力を日本に見せつけて降伏を促すためのものから、「不慮の事故によって多数の科学者が死亡した」と伝えるものまで、複数あったようです。
実験結果は十分な破壊力であったものの、一部の科学者の予想ほどの破壊力はありませんでした。
結果として、成功はしたものの「火薬庫の事故で爆発があったが、死傷者は無い」と公表するにとどまりました。
日本に対して降伏を促さなかったのは、核爆弾を作るには高い技術が必要で、フランクレポートが危惧する様に、「すぐに他国が持つ」ようにはならないだろう、という考えもあったようです。
7月16日に実験が成功して、8月6日には広島に未実験のウラン型を、8月9日には長崎に実験と同様のプルトニウム型を使用します。
これに関しては、アメリカは公式に「戦争の終結を早め、無駄な死者を避けるためだった」としており、多くの人が…アメリカ人に限らず、日本人もその公式見解を信じています。
ただ、先に書いたフランクレポートの関係もあり、事はそれほど単純ではないようです。
戦争の終結を早めるなら、実験を公表するだけでも十分だったのですから。
日本では、1944年11月以降、首都東京に対する度重なる空襲…特に、３月～５月にかけての空襲と、５月に同盟国であるナチスドイツが降伏してしまったことで、敗戦ムードが濃くなっていました。
しかし、負けを認めるにしても、どこまで良い条件を引き出せるか…なかなか、すぐに降伏、とはいきません。
実のところ、当時アメリカと同盟国ではあるが、日本とは戦争していなかったソ連を通じ、アメリカとの和平工作を働きかけています。
こうしたこともあり、アメリカは日本が夏まで持たずに降伏するかもしれない、という情報を入手していたようです。
「既に降伏が近いと知っていた」ことは、「原爆が戦争の終結を早めた」とする公式見解と異なります。
アメリカにとっては、むしろ「降伏される」ことの方が困る状況でした。
やっと完成した新兵器の威力を見せ付けるには、実験だけでは不十分で、実戦での使用の方が衝撃が大きいのです。
また、砂漠での実験だけでは、実際の市街地への投下でどの程度の破壊力かを知ることができません。
是非、実戦で使用したい、というのがアメリカ側の思惑だった様子。
このため、アメリカは慌てて新兵器を投入した、というのが近年の歴史学者の見方。
もちろん、学者によって見解は異なりますが、アメリカの学者でもこの見解を支持する人が多いようです。
＃念のため書いておきますが、僕は広島・長崎の補償を今からアメリカに求める…というような考えは持っていません。
被害にあわれた方としては、「実験」目的で何万人も殺した、というのは許しがたいことだと思いますが、元々国のエゴがぶつかり合うのが戦争。
ただ、過去にあった事実を、個々人が記憶しておくことは大切だと思います。二度と同じ過ちを繰り返さないためにも。
以下余談。
実のところ、日本は原爆を落とされてもなお、無条件降伏ではなくソ連を通じた和平に期待をかけていたようです。
ところが、 8月 9日にソ連が日本に対して宣戦布告。
これに慌てた日本は、 翌日 8月10日に、ポツダム宣言受諾の準備があることをアメリカに伝えます。
そして、8月 14日に正式に受諾通告。8月 15日に無条件降伏することを国民に周知。
ただし、これは「国民に対して周知した」というだけで、戦争は終わっていません。
局所的な戦闘は 8月下旬まで続き、 9月 2日に昭和天皇が正式な文章としての降伏文書に調印。
これによって戦争が終結します。
戦争終結からわずか４年後…1949年 8月 29日には、ソ連が核兵器の開発に成功します。
これは、アメリカの思惑とは違うものでした。フランクレポートにあるように「すぐに他国が核兵器を持つ」ということは考えられない、と思っていたようですから。
実際、核兵器の開発は非常に高いノウハウと、技術力が必要でした。ソ連も、普通なら短期間で開発することはできません。
しかし、軍事スパイが情報をもたらしたために、短期間での開発が可能となったのです。
このスパイ事件は後に映画になり、映画の中で SSEC が使用されています。
また、戦時中にフライトシミュレータを作るために開発されていた Whirlwind I は、ソ連軍の核攻撃からアメリカを守るための SAGE システムへと変貌します。
この後、フランクレポートが危惧したように、世界は冷戦へと進んでいきます。
この頃のコンピューターには、戦争や血なまぐさい話が付きまといます。
しかし、戦争だからこそ命がけで開発が行われ、急速に性能が上がっていったのも事実。
いま、平和にコンピューターを利用できる我々も、そういう歴史を知っている必要はあると思うのです。
同じテーマの日記(最近の一覧)
別年同日の日記
申し訳ありませんが、現在意見投稿をできない状態にしています。 |
今日は、ＮＥＣの創業日(1899)。
創業したの、１９世紀ですよ。ギリギリだけど。
コンピューター企業として有名だけど、もちろん当時はコンピューターなんてありません。
IBMだって20世紀になってから創業した会社(1911)。
まぁ、日本にはテレビゲーム会社なのに 1889年創業、という任天堂もいるのですが。
＃アメリカにだって、エジソン電気照明会社(1878)を母体とするＧＥ（ゼネラルエレクトリック社）があるけど。
日本は1856年に日米修好通商条約を締結し、1859年に横浜・長崎を開港します。
鎖国政策の事実上の終了でした。
とはいえ、まだ外国人の行動は制約され、居留地から外に出るには特別な許可を必要としました。
歴史の授業でよく出てくる話ですが、この頃の日本と外国の立場は「不平等条約」です。
外国と「条約」を結ぶのに慣れていない日本が、一方的に騙されて不利な条約を結んでしまった。
1894年には、イギリスとの間に日英通商航海条約が締結されます。
不平等条約の中心であった領事裁判権（外国人が事件を起こした際、その国の領事が裁く。当然、外国人に有利な判決が出た）を撤廃するのと引き換えに、居留地以外に居住し、自由に活動することが認められます。
但し、この条約は、締結から発効までに５年の猶予期間がありました。
イギリスとの条約締結を皮切りに、他の諸外国とも同様の条約が締結されます。
米国のウェスタン・エレクトリック（多数の合併を経て、現在、フランスのアルカテル・ルーセンス社）は、日本で外国人の活動が自由化されるのを見越して、日本に会社を設立しようとしていました。
支社ではなく、日本の会社との合弁会社が希望でした。
まだ当時日本で電気事業を行っている会社は少なく、沖電気工場（現在の沖電気工業）が有力な合弁先でした。
岩垂邦彦が代理人となって交渉を行いますが、結局条件が折り合いません。
そこで、岩垂邦彦自身が会社を興し、その会社を提携先としてウェスタン・エレクトリックの合弁企業を設立します。日本初の、合弁会社の設立でした。
会社名は、「日本電気」。Nippon Electric Company (NEC) です。
設立は、外国人の自由な活動を認める条約が発効した、1899年の、7月17日でした。
当初は、電話交換機などの通信機器の製造を行います。
日本電気はやがて住友財閥に経営委託され、第二次世界大戦でウェスタン・エレクトリックとの関係が続けられなくなると、「住友通信工業」となります（1943～1945の期間のみ）。
＃NEC の歴史もコンピューター企業としては古いほうなのだけど、住友も非常に古い。
1590年に銅の精錬技術を開発したことから住友財閥（戦後は財閥解体され、現在は住友グループ）が興っている。
400年以上というのは、財閥として世界最古だそうだ。
＃ちなみに、話に関係ないけど世界最古の会社は、大阪にある、寺社仏閣建築の「金剛組」。
578年創業で、創業から 1400年以上になる。
戦後再び「日本電気」として活動を開始すると、NEAC コンピューターの開発を始めます。
（これ以前にもアナログコンピューターを開発していたらしい。詳細不明）
NEC は、元々電話交換機を主軸とした会社でした。
電話交換機は、多数の回線を、自由自在に、「電話番号」という信号に従って瞬時に接続する必要があります。
これは、多数の計算回路を、自由自在に、「命令」という信号によって接続するコンピューター技術と、ほぼ同じものなのです。
電話交換機というのは、「多数の電気回路を、自由自在につなぎ変える」必要があり、コンピューター技術と非常に近い位置にある技術です。
1977年には「コンピューターと通信の融合」という、Ｃ＆Ｃを会社のスローガンとします。
これまでは、「電話交換機の会社」のイメージが強かったのですが、ここからＮＥＣはコンピューター会社として成長していきます。
この頃の主力機種は、ACOS シリーズ。
ＧＥのコンピューター部門（後にハネウェルと合併し、現在は Bull）の作った GCOS シリーズを元に作成したものです。
NEC は「オフィスコンピューター」（オフコン）も販売していました。
ACOS は汎用機にもオフコンにも使用されていますが、やがてオフコン用はより知識がなくても使用できる独自 OS になっていきます。
私事で恐縮ですが、1978年発売のシステム100/80 をうちの父の会社で導入していました。
NEC が初めて「８インチ標準フロッピーディスク」を採用した機種の一つで、「大容量固定磁気ディスク」もついていました。たしか８メガバイトではなかったかな。
リース終了後に買い取ったのを自宅に持って帰ってきたので、1990年ごろに使ってみた記憶があります。
お世辞にも使いやすいとは言えなかった…（12年前の技術なのだから、少し割り引いてあげないといけないとは思いますが）
さて、コンピューターでＮＥＣの話なら、当然出さなくてはならない話。
1976年に、半導体事業部が TK-80 を発売します。
半導体事業部、ですからね。パソコンとして作ったつもりじゃない。
それまであまり知られていなかった「CPU」という新しい LSI を、どのように使うか技術者に知ってもらうための、トレーニングキットでした。
でも、これが大ヒット。
コンピューターに興味を持っていた人たちにまで広く普及しました。
しかし、あくまでも半導体のトレーニング用です。自分で半田付けをする必要がありましたし、完成したってプログラムを機械語で直接入力しなくてはならない。
普通の人が使えるようなものではありません。
そこで、別売り拡張キットとして、TK-80 BS が作られます。
このキットを追加すると、キーボードがついてベーシックが使えるようになりました。
しかし、元々パソコンとして使う予定ではなかった製品では、対応に限界があります。
ちゃんとしたパソコンを作ろう、と、半導体事業部が頑張って作ったのが PC-8001(1979)。
しかし、ＮＥＣには先に書いたように、オフコンや汎用機を扱うコンピューター事業部があります。
半導体事業部からコンピューターを出すことには問題がありました。
そこで、PC-8001 は、子会社の新日本電気が生産し、ＮＥＣが販売することになりました。
新日本電気は、主に家電の製造販売を行っている会社でした。
形の上では、ＮＥＣは「販売だけ」で、コンピューター事業部以外ではコンピューターを扱いません。玉虫色の解決策でした。
驚いたのは子会社の新日本電気。
実は、TK-80 のヒットを見て、自社製品として安価で TK-80 よりも性能の良い機械を設計していたのです。
PC-8001 とほぼ同じ構成でした。
当初は搭載する BASIC を互換品にし、PC-8001 互換として売り出すつもりでした。
しかし、PC-8001 互換でより安いのであれば、PC-8001 の存在意義が無くなります。
親会社のＮＥＣとも何度も交渉が行われ、性能を落とし、家庭用としてテレビ出力などを備え、プログラムの交換をしやすくするため ROM カートリッジなどを備えた、PC-6001(1981) として販売されます。
こちらは、新日本電気の製造・販売で、家電品ルートに乗せられました。
半導体部門は相変わらずコンピューターの設計を続けていて、PC-8001 はやがて PC-8801(1981) に進化します。
そして、当初危惧した通り、コンピューター事業部の市場に食い込み始めました。
そこで、コンピューター事業部でも PC-8801 の互換機が作成されました。
ただし、PC-6001 が「設計変更を命じられ、非互換になった」のを見ていたので、極秘裏にプロジェクトが進みます。
コンピューター事業部の威信をかけたものだったので、16bit になりました。
当初はベーシックをマイクロソフトに頼んだのですが、マイクロソフトは 16bit のベーシックは「統一ベーシックにする」構想を持っていたため、断られます。
そこで、オリジナルの互換ベーシックを開発しました。
これが、PC-9801(1982)です。
シリーズは、後に「国民機」と呼ばれるほどに普及しました。
増えすぎたパソコン事業に対し、ＮＥＣは「8bit は家電品として、新日本電気が扱い、16bit はビジネス用としてコンピューター事業部が扱う」という切り分けを行います。
これにより、ブームを作り出した半導体部門は作るものを失ってしまいます。
でも…もう一つの道が残っていました。
8bit でも、ビジネス用でもない「16bit の個人用コンピューター」を作るのです。
こうして生み出されたのが PC-100(1983)。
当初計画では、マウスでグラフィックを操ることで操作するＯＳを搭載する予定でした。
…が、依頼されたマイクロソフトで開発が難航し、納期に間に合いません。
本来は Windows 1.0 が搭載される予定でしたが、急遽普通の MS-DOS マシンとして発売されます。
PC-100 は、グラフィック高速化の仕組みなどが搭載されていて、非常に高価なマシンでした。
しかし、できることは PC-9801 と同じ、MS-DOS マシンとして発売されたのです。
シリーズは続かず、すぐに終わった不遇の機種でもあります。
他に、PC-6001 の上位互換期である、PC-6601 シリーズもあります。
PC-8001 もそうですが、上位互換期が登場しても、廉価機種としてシリーズが続く、というのが悩ましい。
PC-6001、PC-6601、PC-8001、PC-8801、PC-9801 。
NEC では、主にこの５つのシリーズが展開され、1980年代中期には「月刊ＮＥＣ」とすら言われるようになります。
大体、半年ごとにマイナーチェンジした新モデルを出すんですね。
５機種あるから、それだけでも本当に、ほぼ月刊ペースになる。
そこに加えて、PC-100 とか、PC-8201 とかの「非互換機」もでる。
選択肢が多いのは良いことなのですが、いつ買ってもすぐ新機種が出て自分の愛機が古く見えてしまう、というのは悩ましいものでもありました。
＃1990 年代に入ると、PC-6001などが無くなる代わりに、PC-H98 や PC-9821 など、別のシリーズが増える。
PC-8001 は、マイクロソフトのBASICを採用しました。
これ、国内では最初の MS-BASIC 。
以降、MS-BASIC が大きなシェアを持ちます。
PC-9801 では独自 BASIC を使ったけど、あまりにも互換性が高かったために著作権違反の可能性が指摘され、MS にライセンス料を払っている。
PC-8801 の時代、ＯＳというのは特に存在しませんでした。
ディスクがあっても、フォーマットはアプリごとにバラバラ。
PC-9801 になっても、その時代に倣ってＯＳなんて存在しない、という状態がしばらく続く。
実はアメリカでも似たような状況でした。
IBM PC は PC-DOS(MS-DOSのOEM)が標準 OS でしたが、独自ＯＳを使うようなソフトも多数。
だって、独自フォーマットにしないと簡単にプログラムをコピーされちゃうじゃん。
西和彦が思い切って「MS-DOS のＯＳ部分だけなら無料で配布してよい」とソフト会社に持ちかけたことから、MS-DOS が急に標準ＯＳとなっていきます。
実は PC-9801 がきっかけ。
すでに書いた通り、Windows も元々は PC-100 のために予定されたものでした。
マイクロソフトが躍進した裏には、たびたびＮＥＣとの関係があります。
だから、ビル・ゲイツはＮＥＣに特別の親近感を持ってくれていた。
1998 年の「Windows 98」の発売の際は、NEC の PC98-NX で Windows 98 を動かそう、というキャンペーン、「98で98」をやってくれた。
もっとも、PC98-NX は PC-9801 の互換機ではなく、名前だけを引き継いだ PC/AT 互換機。
（実は、PC/AT 互換機としても完全互換ではない）
今ではパソコン事業はすっかり縮小してしまった感じですが、汎用機・スーパーコンピューターではまだすごいです。
地球シミュレータとか、ＮＥＣ製だからね。
そもそも、アメリカ以外の国が作ったスーパーコンピューターが世界最速になったのは、ＮＥＣのＳＸ－２が最初。
SX-2の設計者の一人が、後にＶ６０設計の一人で…という話題は、過去に書いたので、興味ある方はそちらを読んでください。
同じテーマの日記(最近の一覧)
関連ページ
別年同日の日記
20年 phpSpreadsheet で小数点付き数値と見なせる文字列を入力するとおかしくなる
申し訳ありませんが、現在意見投稿をできない状態にしています。 |
ここ数年、スマホの Google Maps をナビとして使っています。
結構使っている人も多いと思うので取り立てて書くこともないのだけど、メモ程度に記録。
回線は安い SIM です。490円。非常に遅いけど、ナビを使う上で問題は無い。
ちなみに、スマホ自体も非常に古くて非力だけど、これも問題ない。
Google Maps の経路検索自体は、かなり信頼できると思っています。
Google Maps を利用している他の車の走行情報を元に、ノード間の平均移動時間を得ていて、時間が速い経路を案内してくれる。
多分、地元利用者が「知る人ぞ知る抜け道」みたいのを使うと、それも学習してしまう。
時々とんでもない道を案内されます。
しかし問題は、Google Maps が経路を「案内する」のが下手な事。
目の前の道を右か左か、みたいな案内だけで、手近な目標としてどこを目指すのか、がわからない。
道路標識と照らし合わせて判断することが難しく、道がわからなくなることがあります。
それでも町中のナビゲーションは比較的まともなのですが、高速道路のナビは、困るくらいにド下手。
指示が出るたびに、何をさせたいのかわからずにドキドキします。
「直進です」と言っておきながら、どうやら曲がって欲しかったらしい、なんてこともしばしば。
（コース表示から現在地がそれてしまい、慌てて「経路再検索」になる）
それでも、Google Maps だから助かったことも幾度もあります。
旅行中も、どうやら行く先で事故渋滞が始まったようなのです。
先に書いたように、Google Maps では、ナビを使っている人の情報を共有します。
同じエリアで急に速度が落ちた車が続出すれば、渋滞していると自動認識します。
予定経路上に渋滞があると、Google Maps では到着予定時刻の表示が赤くなります。
そして、場合によっては「早く到着する経路が見つかりました。使用しますか？」と聞いてきます。
これを使うと、大抵はとんでもない道に案内される（笑）
でも、渋滞している部分を見事にショートカットして、当初の予定時間通りに到着させてくれたりするのです。
行きも帰りも、事故渋滞が発生したのですが、巻き込まれることなく進むことができました。
普段は僕が車を運転するのですが、旅行の帰りは妻と途中で交代しました。
常磐道なら空いているので妻でも運転できる、というのもありました。
妻は普段の運転は問題ないのですが、高速道路はあまり乗ったことが無い。
でも、結局首都高速を通って家まで妻の運転で帰ってしまった。
この時に気付いたのですが、Google Maps を使う場合、運転手が直接見るよりも、助手席の人間が状況を把握しながら運転手に伝えたほうが良いようです。
Google Maps の情報は、地図では得られないような渋滞情報もあるし、現在地もよくわかる。
でも、先に書いたように、どうも案内が下手。
場合によっては、行こうとする先の地図を見て案内の意図を汲み取る必要がありますが、これは危険なので運転中にはできない。
そうした操作を適切に行い、運転手が今何をすべきか、的確に伝える人が必要です。
まぁ、助手席というのは本来ナビをする人が座る席。
そのナビの強力な助っ人としての Google Maps 、という位置づけが一番良いのかもしれません。
いつかもっとバージョンアップして、ここに書いたような「使い勝手の悪さ」が無くなるかもしれません。
ここ数年でも、どんどん使いやすくはなっているからね。
でも、こんな時代もあったな、という記録をここに残しておくものです。
同じテーマの日記(最近の一覧)
関連ページ
別年同日の日記
申し訳ありませんが、現在意見投稿をできない状態にしています。 |
７月２９日から、Windows10への無料アップグレードが始まっている。
でも、予約しといたのになかなかうちには来ない。
基本的に、マイクロソフトに開発者登録したようなアーリーアダプターから配布を始め、ある程度落ち着いてから一般ユーザーに少しづつ送り、遅い人でも今年中には通知が来る、ということらしい。
Google が Nexus のアップグレードで同じような方法を取っている。
この方法だと、バグが出たらとりあえず配布を中止したりして、影響を最小限に抑えられるのね。
昨日夕方に、やっと通知が来た。
早速今朝入れてみた。
…Win8.1 からのアップグレードならあまり問題は出ない、と聞いていたのだけど、致命的な問題が２つ起きた。
POPfile が起動しない。Chrome が不安定で、特定ページを表示できない。
「特定ページ」の条件が十分わからないが、どうも webSocket を使っているページが表示できないように思える。
また、Flash を使ったページでも、FlashPlugin が停止した、というエラーになる。
POPfile はメーラーと組み合わせて使うための、ベイジアン SPAM フィルタ。
つまり、メールと WEB が動かない。これは困った。
POPfile に関しては解決方法がわかったので後で書く。すごく簡単に解決する。
それほど多くの人が使っているとは思えないツールだけど、今のところ正しい日本語の情報が無いようなので。
（間違った情報はあるし、英語なら正しい情報が見つかる）
＃翌日追記：chrome も解決。
せっかくなので、ちょっと使ってみたところでの、Win10 の使い勝手を。
今まで 8.1 を使っていたので、それほど変わらないのだけど、一部の機能が変わったから、変わった部分を中心に。
スタートボタンが復活した。これはよく言われること。
でも、8.0 でなくなったと言われるスタートボタンは、8.1 ですでに復活していた。
これがわざわざ「復活した」と言われるのは、誰も 8.1 のスタートボタンを、スタートボタンと認めていなかった、ということだろう。
8.0 では、「見た目の上で」ボタンが無くなった。
でも、実は機能としては存在していて、本来スタートボタンがあった位置（角）にマウスカーソルを持っていけば、スタート画面の表示に移動できることが示された。
8.1 では、その位置に Windows アイコンが表示された。出来ることは 8.0 と同じく、スタート画面への移行だった。
多分、この「スタート画面」を、スタートボタンではない、と誰もが認めていなかったのだろう。
スタート画面は、スタートボタンをもっと使いやすくした機能だった。
スタートボタンと違い、アイコンを２次元に整理できた。
Windows 3.1 の頃に使われていた「プログラムマネージャ」を思い出すと良い。
win95 になって「プログラムマネージャ」が無くなり、スタートボタンになった時に「使いにくくなった」とすごい批判だった。
主な批判の理由は、２次元で整理していたものが、１次元になってしまったからだった。
スタート画面は、これを２次元整理に戻したものだが、受け入れられなかった。
受け入れられない大きな理由の一つには、「シャットダウン」が違う場所になったことも大きいだろう。
それまで、スタートから電源を切っていた人には、電源を切ることができなくて非常に戸惑ったのだと思う。
でも、やはり 95 でスタートが導入されたときに、「スタートから終了するとは分かりにくい」と散々批判されたのだった。
話を元に戻して、Win10 のスタートボタンは、電源を切る機能が復活した。
これが「復活」と言われる最大の理由だと思う。
全画面を覆わないで、ポップアップウィンドウである、というのもスタートボタンらしさではあるだろう。
でも、実は２次元管理が基本になった。
Win7 の頃までの１次元管理だと、１次元とはいいつつ、ディレクトリを含めることができるツリー構造だった。
そのため、「最初は小さなポップアップだが、ディレクトリを辿るごとに次々ポップアップが出る」ようになっていた。
Win10 では、２次元管理なので次々ポップアップ、にはならない。
最初からウィンドウサイズが決め打ちになっている。（自分の好きなサイズにリサイズできる）
広いほうが使いやすいので、大きくした方が良いように思うのだけど、スタート「画面」が嫌だ、と言っていた人たちは、あまり大きくないようにするのではないかと思う。
僕は、スタート画面を気に入っていたので、「設定」画面から、「全画面表示のスタート画面を使う」をオンにした。
先に、Win8 では電源を切る機能がスタートボタン内ではなくなった、と書いたけど、じゃぁどこに行ったかと言えば「チャーム」という部分に入れられていた。
チャームはハードウェアの様々な設定機能をまとめたもので、画面の右端からスライドして出てくるようになっていた。
ネットワーク設定、画面設定、パソコン内のファイルの検索、コントロールパネルの呼び出し、個人設定、などの機能と一緒に「電源」も入れられていた。
これ、結構わかりやすかったと評価していたのだけど、Win10 になってなくなった。
Vista で入ったガジェットは、Win7 で進化して、Win8 で消えたのだけど、「チャーム」は Win8 だけで無くなった。早すぎる。
じゃぁチャームに入っていた機能はどこに行ったかというと、いろんな個所に分散して入れられた。わかりにくい。
救いは、よく使う機能はアクセスしやすいところに入れられ、あまり使わない機能は奥底にしまわれる、というように、使用頻度で分けて、決して使い勝手を落とさないように再配置されたことか。
なんでチャームを無くしたかと言えば、「画面右端からのスライド」を、別の、もっと重要な機能に使いたかったから、のようだ。
Win10 では、「通知」がここに入った。
Win8 でも、スマホによくある「通知」の機能が追加された。
裏で動いているアプリなどからのお知らせが、画面の上にちょっとだけ表示される。
でも、見てないとそのまま消えて、どこにも残らなかった。
Win10 の新機能である「通知」は、見てなかった通知がまとめて表示されている。
そして、これがまたちょっとわかりにくいところなのだけど、チャームの一部機能は「通知」の一番下で生き残っている。
ネットワーク接続などは、通知画面の一番下で確認・変更できる。
「タブレットモード」なんていうモード切替もあって、モードを切り替えるとちょっと面白いことになる。
タブレットモードでは、ウィンドウがオーバーラップしなくなる。
Win8 は「デスクトップモード」と「ModernUI」の２重人格だったが、Win10 では ModernUI のアプリでも問題なくデスクトップにオーバーラップして置けるようになった。
そして、デスクトップアプリでも、タブレットモードでは全画面表示になる。
デスクトップアプリと ModernUI アプリは、API が違うはずなのだけど、実質的に等価に扱われるようになったようだ。
（ModernUI は、オーバーラップしないことを前提にウィンドウの重ね合わせ処理などを考慮しなくてよいAPI であり、非力な機械でも高速に動作するようにしてあった。
ここら辺、どのように折り合いをつけたのかは知らない。２つの API が、タブレットモードかどうかで２つの処理を持ち、都合４つの描画ルーチンがあるのかもしれない）
地味に便利なのが、タスクビュー機能。
いままでも、Win+Tab キーでウィンドウの切り替えを行えた。
あそこに、タスクビューという機能が入った。これは実質的に今までと変わらない。
便利になった、というのは、ここで「新たなデスクトップ」を作れるようになったこと。
いわゆる仮想デスクトップで、実現するソフトは沢山あったのだけど、標準機能であることに意味がある。
そして、デスクトップに置かれたファイルなどは、どのデスクトップからでも同じように表示される。
つまり、多数ウィンドウが重なってその奥にあるアイコンがアクセスできない場合、迷わず「新たなデスクトップ」を生成してしまえば、すぐにアクセスできるようになった。
いままで、まとめてウィンドウを最小化してデスクトップを表示する機能はあったのだけど、後でウィンドウを開きなおすのが面倒だったのだよね。
ウィンドウを開いたままでデスクトップにアクセスできるし、仕事に合わせて複数のデスクトップを持てるようになったわけで、一挙両得の解決方法だと思う。
まだ今日使い始めたばかりなので、判って無い部分も多数あるけど、とりあえずはこんな感じです。
関連ページ
Windows10へのアップグレード【日記 15/08/14】
別年同日の日記
申し訳ありませんが、現在意見投稿をできない状態にしています。 |
先に書いた通り、Windows10 にアップグレードしたら、POPfile が動かなくなりました。
POPfile って、メールを分類してくれるベイジアンフィルタね。
SPAM を取り除く、というのが主な仕事だけど、趣味のメールと仕事のメールをざっくり分類してくれる、なんてこともできる。
僕はこれを便利に使っていたので、使えなくなると困る。
ある程度学習が必要なもので、できることなら学習した内容もそのまま使えてほしい。
日本語では情報が見当たらず、英語で調べていたら、わずかではありますが対処法が書かれたページがありました。
まず、前提。
POPfile は、インストールすると Run POPfile というショートカットを作り、これで起動されるようになっています。
起動後は常駐し、メールをサーバーに読みに行く際に間に入って、メールを分類します。
ところが、Windows10 アップグレード後は、起動してもすぐに終了してしまい常駐しなくなりました。
すると、メールが読みに行けません。
＃メーラーの設定を少し書き換え、POPfile に接続する様にしてあるため。
POPfile の方に、それまでのメーラーの設定を記述し、POPfile がメールを取りに行きます。
Run POPfile ショートカットのプロパティを表示し、「ファイルの場所を開く」ボタンを押せば、本来の実行ファイルが見られます。
runpopfile.exe というファイルです。
実は、同じディレクトリにある popfile.exe が本体。runpopfile.exe は、この本体を起動するのですが、起動後も別の役割を担います。
popfile.exe が何かの拍子に停止してしまうとメールが読みに行けなくなるので、runpopfile.exe は、起動した popfile.exe を監視し、トラブル時には再起動を行うのです。
同じディレクトリに、msgcapture.exe というのがあります。
これも popfile.exe を起動するのですが、普段は表示されない「現在の状態を示すメッセージ」を受け取り、表示してくれます。
（ファイル名は、msgcapture は、メッセージを受け取るもの、の意味です）
POPfile がうまく動かない時は、msgcapture.exe を使って原因を調べる…というのが普通の手順の模様。
ところが、runpopfile.exe では起動できないのに、msgcapture.exe では起動できてしまうのです。
なぜかはわからないのだけど、これでは原因が特定できない、お手上げの状態。
ここで解決法。
さらに同じディレクトリに、adduser.exe というファイルがあります。
これを起動してください。
これは、POPfile インストール直後に自動で実行される、ユーザー設定ユーティリティ。
Windows を複数ユーザーで使っている場合は、ユーザーごとに adduser.exe だけを起動すればよいようになっています。
実は、Windows 10 のアップグレードインストール時に、何らかの都合で設定が壊れてしまうようです。
でも、大事な学習データなどは残っているので、データを残したままユーザー設定だけやり直せば動くようになる。
adduser.exe を起動すると、すぐに以前のファイルを見つけ出して「アップグレードするか」と聞いてきます。
アップグレードなら、学習したデータなどはそのまま使われます。
後は待つだけ。
これだけで設定は終了。
Run POPfile を起動すれば、問題なく常駐する様になります。
関連ページ
Windows10へのアップグレード【日記 15/08/14】
別年同日の日記
申し訳ありませんが、現在意見投稿をできない状態にしています。 【カンニャボ】 長いアップロードの後に動かなくなってこれで解決しました。 (2016-10-13 16:51:42)【zak】 大変参考になりました。ありがとうございます！ (2016-09-07 23:00:05) 【Hide】 参考になりました。的確な「まとめ」感謝です。 (2016-07-25 22:20:11) 【通り５】 「本当に感謝です」 「感謝」「感謝」「感謝」「感謝」・・・ (2016-07-25 10:03:19) 【でぶじい】 Win10で動かなくなったPOPfile直りました。有難うございました。 (2016-07-22 12:50:05) 【とおりすがり４】 私も同様です。ありがとうございました。 (2016-06-18 16:12:47) 【通りすがり３】 ほかの方と同様です。貴重な情報に感謝です。 (2016-03-04 17:57:52) 【感謝！】 windows10にアップグレードしたら同じ現象になり、途方に暮れていたところですが、こちらの記事を見て手順どおりにアップグレードしたら、再び使えるようになりました。ありがとうございます。 (2016-01-22 07:26:37) 【通りすがり2】 私も同じ状態で、この記事にたどり着きました。再設定・・・の手間がかからず助かりました。ありがとうございます。 (2016-01-08 22:00:33) 【通りすがり】 win10にアップグレード後、popfileが動かなくなり困っており、検索からこの記事にたどり着きました。おかげで助かりました。ありがとうございました。 (2015-10-04 23:31:14) |
昨日書いた、Chromeが動かない問題は解消した。
と言っても、解決法を期待されても困る。
なんだかわからないが、一晩たったら治っていた、という状態なので。
Chrome が動かなかったのは、先に書いたが主に webSocket を使っていると思われるページと、Flash を使っているページだった。
Flash は「プラグインが応答していません」というエラーが出て全く動かない。
困るのは、Flash が使われているページでは、このエラーによって動作が止まることがあったという点。
広告などが Flash を使っていると、ページ自体が使っていなくても止まる。
webSocket を使っていると思われる、というのは、代表例は TweetDeck と chatWorks。
もしかしたら、XMLHttpRequest でも止まっていたかもしれない。
これらのページは、通信を試みたところから完全に停止するようだった。
一応、Win10 の新標準ブラウザである Edge を使えば、それらのページも見られる。
Edge は非常によく出来ていて、Chrome のブックマークをインポートできるし、動作も非常に軽快、Chrome と操作法も似たタブブラウザだ。
「最近人気のブラウザ」をよく研究して作られた意欲作だと思う。
でも、僕は仕事柄 Chrome をどうしても使わないとならないことがあるのだ。
Edge を常用したとしても、Chrome が動かないのは困る。
様々な設定が消えると困るので、データは残したまま Chrome をアンインストールして、再インストールする。
しかし、症状は改善しない。
Win8 では 64bit 版 Chrome を使っていたが、気づくと再インストールしたのは 32bit 版だった。
改めて削除し、 64bit 版を入れてみる。それでも改善しない。
ユーザーごとに保存されるファイルを全消去すると動作不良が改善する場合がある、という記事を読み、試みる。
しかし、改善しない。
ちなみに、Chrome ではブックマークなどは自動的にオンラインに保存されているので、ファイルを消去しても環境はすぐに取り戻せる。
昨日はここで時間切れ。
後出来そうなのは、データも含めた完全消去と再インストール。
これをやるのはさすがに気が重い…というのも、クッキーなどはさすがにオンラインに保存されないから。
しかし、試さないといけないだろうなぁ、と思っていた。
今朝になって、気は重いが完全消去を試してみよう、とパソコンを起動。
完全消去の前に、ダメもとで Flash が使われているページにアクセスしてみる。
…あれ、なぜか動いた。
TweetDeck にアクセスすると、こちらも動いた。
何が起こったのか、全くわからない。一度電源を落として再起動したのが良かったのか。
TweetDeck は僕のユーザーアカウントでログインされた状態で始まったので、クッキーは残っているようだ。
しかし、Local Shared Object （いわゆる Flash のクッキー）は消えてしまったらしい。
実は Flash のゲームで遊んでいたデータが消えたりしたが、これはそれほど問題ではない。
この程度の問題で済んで良かった。
今過去の日記を見直していたら、Win 8.1 を入れた際にも、Chrome が動かなくなったと騒いでいる。
僕も進歩が無いのだけど、アップデートの度に問題が起きる Chrome にも問題がありそうで、こちらも進歩が無い。
別年同日の日記
申し訳ありませんが、現在意見投稿をできない状態にしています。 |
１日使ってみて、Windows10 の「スタート画面」の設計には多少問題があるな、と感じてきたので書いておこう。
Win95 以降の「スタートメニュー」と、Win8 の「スタート画面」には両方とも批判があり、その折衷案として作られたのが Win10 の「スタート画面」なのだけど、折衷案であるがゆえにどっちつかずの問題が起きている。
話は、Win8 のスタート画面から始めたほうが良いだろう。
Win8 では、スタート画面は「横スクロール」だった。表示される際の起点は、長い画面の左端。
なので、右に向かってスクロールしていける。
だから、僕はよく使う機能を、左下に沢山配置していた。
スタート画面に移行するには、デスクトップ左下のスタートボタンを押すことになる。
つまり、スタート画面開始時にはカーソルは左下にある。
この周辺によく使う機能をまとめておけば、マウス移動距離が短くて済む。
Win8 以降の ModernUI ソフトには、ライブタイルという機能がある。
わざわざアクセスしないでも、最新の情報などを表示してくれるのだ。
これらは、右の方に配置しておく。
左下から配置したい機能が増えると画面外に追い出されてしまうが、元々「表示されていればありがたい」程度の機能なので、見えなくても問題は無い。
Win10 では、Win95 の「スタートメニュー」に倣って作り直された。
Win95では、リストは縦に並ぶ。なので、スクロール方向も縦に改められた。
最初に表示される際の起点は、リストの一番上だ。下に向かってスクロールする。
これが、「マウスカーソルは左下にある」というのと相性が悪い。
上が起点となるので、左下によく使う機能を集めるのが難しい。
もちろん、その位置に集めることは、不可能ではない。
Win95以降では、スタートメニューは、状況によって縦幅も横幅も変わる。
しかし、Win10では、あらかじめ指定した固定幅になっている。
固定幅なのだから、左下を特定するのはたやすいともいえる。
でも、使い勝手を挙げようとしてサイズ変更すると、アイコンが自動で再配置されて、並び順はそのままでも表示位置が変わってしまう。
この時、起点となる「右上」は一切変わらない、というのが悩ましい。
重要なものを右上に置いておけば良いのだけど、そうするとマウスカーソルの起点位置である左下から遠く、使い勝手が落ちる。
ちなみに、あらかじめスタート画面に配置しておいたアイコン「ではない」ソフトを起動したい場合のために、インストールされている全ソフトを、アルファベット順に並べて表示する機能がある。
この機能は、スタート画面左下のボタンからアクセスできる。
また、電源を切る機能も左下に置かれている。
こういう機能を左下に配置している、という時点で、スタートボタンは左下に置かれていることを前提にしているのだろう。
右上が起点なのだから、スタートボタンを右上に置くのが正解、ということではない。
恐らく、Win8 で横スクロールだったのは、左下に重要なアプリを置けるようにするためによく考えた末の機能だったのだ。
左端から横スクロールであれば、左下に置かれたアイコンが、何かの拍子に移動してしまうことは無い。
Win95 でスタートメニューのユーザーインターフェイスを設計したダニー・オラン女史は、 Win10 でスタートメニューが「復活した」ことに、落胆しているそうです。
当時としては悪くないアイディアだったけど、いまとなってはもっと良いアイディアがある。
彼女は Win8 のスタート画面は、スタートメニューを捨ててもっと良いアイディアを試していた、と良い評価をしています。
Win10 だって、全画面表示にすれば Win8 のスタート画面と同じになるのではないの？ と僕は思っていたのですが、実際に使ってみると使い勝手が落ちていることに落胆しました。
上に書いたように、サイズ変更をしなければ「左下」にアイコンを集めることは可能です。
さらに言えば、１画面に納められる量だけにアイコンを限定すれば、スクロールも発生しません。
ユーザーの工夫で使いやすい運用は可能…ということですが、これは可能性を犠牲にした運用でもあります。
ちょっと残念な部分です。
別年同日の日記
申し訳ありませんが、現在意見投稿をできない状態にしています。 |
久しぶりにサーバー設定していて、ntsysv を起動してから、あぁ、そうじゃなくて何だっけ、普通にコマンドラインで設定するやつ、と思った。
正解は chkconfig なのだけど、まぁ、そこはどうでも良い話。
わけわからん、という人のために書いておくと、サーバー起動と同時にデーモン（サービスプログラム）を起動したい、ということは多い。
というか、いちいち必要なデーモンを手動で起動なんてしてられない。
コマンドラインでその設定をするソフトが chkconfig 。
chkconfig をわかりやすく、カーソルキーだけで設定させてくれるソフトが ntsysv 。
まぁ、ともかくその時は chkconfig が思い出せなかった。
ntsysv って、検索してみたら、こんな質問があった。
New Technologies System Virtualisation だ、という唯一の答えがベストアンサーだ。
いや、明らかに違うから。それ、単に VMware 好きな技術者が書いている、ブログのタイトルだから。
以前書いた通り、こうしたＱ＆Ａコミュニティはまともな答えが出ないと思っているけど、その答えがベストアンサーとして残るのはどうもいただけない。
でも、じゃぁ ntsysv が何の略か、というと僕も答えを持ち合わせていない。
答えを知らないのであれば、上のベストアンサーが間違っている、と言い切る根拠だってないことになる。
推測に過ぎない、と断った上だけど、後半部分はわかる。sysv の部分だ。
System V というのは、AT&T が作った UNIX ディストリビューションの名前だ。
というか、UNIX は AT&T が生み出したものだから、本家だな。
V というのは、ローマ数字で 5 のこと。バージョン5だから System V 。「しすてむふぁいぶ」と読むこと。
Linux は、基本的に System V 互換を目指して作り出されたフリーの UNIX 環境だ。
カーネル以外は BSD 由来の部分が多いので BSD っぽい操作をするところも多いのだけど、System V を目指した。ここが重要。
そして、多くの Linux ディストリビューションが、サーバ起動時のデーモン起動方法として、System V 互換の手法を取っている。
/etc/rc.d/ ディレクトリ下に、起動のためのスクリプトを置いておく、というやつだ。
実際には、/etc/rc.d/init.d/ にスクリプトが置かれ、/etc/rc.d/rc3.d/ なんかの下に、起動順位に従ったファイル名でリンクされる。
起動時には、このリンクをファイル名順に実行することで、デーモンが起動される。
つまり、chkconfig の正体は、init.d のスクリプトを他のディレクトリの下にリンクしたり、リンクを削除したりするプログラムだ。
ntsysv は、init.d の中のファイル一覧を表示して、カーソルキーとスペースキーで、起動するか再起動するかを変更できるプログラムだ。
…というわけで、ntsysv は、System V のデーモン起動方法と深く結びついている。
だから、sysv の部分は System V の略だと考えて、まず間違いないと思われる。
まずやって見たのは、man ntsysv だ。
マニュアルが読める。
特に名前に関する情報は無かった。
次に、ntsysv と System V を並べてググってみる。
ntsysv は、ほにゃらら System V の略だよ、って書いたページがあることを期待したのだ。
期待したのだけど…なかった。少なくとも、僕は見つけられなかった。
でも、「ntsysv は ncurses ベースで作られた、System V 起動ファイルの設定ソフトだよ」ってページは多数見つかった。
なるほど、これで n に関してはわかった。ncurses の n のようだ。
ちなみに、ncurses は new curses の略だ。「新しい呪い」ではなくて、curses は cursor を操作するためのライブラリプログラム。
その昔、UNIX にはテレタイプが付けられていた。コンピューターにはテレタイプ、が当たり前だった時代だ。
でも、そのうち「ビデオテレタイプ」と呼ばれる、CRT 端末が登場した。
そうした端末では、カーソル位置を自由に設定するコマンドが存在していることがあって、文字を自由な位置に配置できた。
でも、端末ごとに互換性が無くて非常に面倒くさい。
これをうまく吸収してしまい、プログラマは「カーソルを指定位置へ」と命令するだけでよきに計らってくれるライブラリが作られた。
端末ごとに全く異なる、カーソル(cursor)を巡る呪い(curses)のような状況から解放してくれる呪文(curses)だ。
…でも、あるころに、何らかの事故によりソースファイルが失われたらしい。
非常に便利なソフトで、無くなってしまうのは困るので、同じ機能のものが作り直された。
これが new curses 。ncurses だ。
余談だけど、1文字の大きさが変わったりする日本語では、curses はまともに動かなかった。新たな呪いだ。
日本語対応にした curses を、ペリカン curses という。
文字データが端末に「流れ込んでいく」と考えると、文字化けをするのは、何かが通せんぼしているからだ。
curses が日本語だけを通せんぼしているのであれば、日本語が通るようにしてやらなくてはならない。
「日本語が通る」なので、最初は「日通」と呼ばれたらしい。
でも、日通といえばペリカン便。そこで、日本語対応の curses を「ペリカン curses」と呼ぶようになったのだ。
嘘みたいな本当の話。
UNIX のソフトには、こんな名前の由来が沢山ある。
話がそれた。
ntsysv の t の部分だけど、考えられそうなのが2つ。
一つは、text 。ncurses を使った text 画面ベースだ、という主張。
というのも、このソフトが作られたのは 1997 年ごろのようで、世の中がコマンドラインインターフェイスからグラフィカルインターフェイスへ変わっていく頃なのだ。
「ビジュアルに」設定したいのであれば、X Window という手だってある。
でも、X Window は「手軽」に見えるけど「気軽」ではない。
ビジュアルに表現していても、テキスト画面で使えることを重視したのではないかと思う。
もう一つは、toggle 。
ntsysv を使ったことある人はわかると思うけど、各種デーモンを「起動するかしないか」だけを選ぶため、カーソルでリストの中を動いて、スペースキーを押すと起動するかどうかを切り替えられる。
起動設定を簡単に toggle 出来る、という意味で、この t でもおかしくない気はする。
このプログラム作った人、man ntsysv で連絡先まで書いてあるから、聞いてみればわかるんだろうけどね。
後日追記 2015.8.30
コメント欄で「nt は newt の略」という説を頂いた。
不勉強で newt を知らなかったのだけど、教えてもらってから調べてみたらすごく信憑性高い。多分それ。
ncurses は、画面の好きな位置にカーソルを移動したり、文字に色を付けたりするための仕組み。
BASIC 時代を知っている人には、color と locate が使えるようになる「だけ」だと思ってもらっていい。
＃パソコン通信時代を知る人なら、エスケープシーケンスを適切に選ぶだけのライブラリ、と言えばさらに理解してもらえるか。
newt は、ncurses を利用して、テキスト画面でウィンドウシステムを実現してしまおう、というライブラリだ。
X-Window では画面描画を行う方法を提供するけど、ウィンドウシステムは提供しない。
ウィンドウシステムとして使いたければ、好きなウィンドウマネージャを組み合わせる必要がある、というのと似ている。
ntsysv の説明では「ncurses based」であることを書いてあることが多いのだけど、実は newt based でもあった。
そして、この newt は、 RedHat 社が開発したものだ。
RedHat のテキストベースのインストーラが作り出す画面は newt によるもの。
名前も詳細も知らなかったのだけど、統一された操作感だから、なんかライブラリがあるんだろうな、程度には感じていた。
＃最近は X-Window ベースでインストールできるので、この画面はあまり見なくなった。
そして、newt の開発者と ntsysv の開発者は、同一人物だった。Erik Troan さん。
そんなわけで、ntsysv の「nt」は newt の略ではないか、という説には非常に信憑性がある。
ところで、newt は「イモリ」の意味だ。公式には Not Erik's Windowing Toolkit の略となっている。
Erik さんが作ったのに、なんで Not Erik's なのかは知らない。
でも、curses（呪文）と一緒に使う、って時点で「イモリ」の名前が先にあったんじゃないかという気がする。
なかなか良いネーミングセンスだ。
別年同日の日記
申し訳ありませんが、現在意見投稿をできない状態にしています。 【あきよし】 情報ありがとうございます！ なるほど、ntsysv と newt 、作者さんが同じなのですね。恥ずかしながら newt の存在を知りませんでした。本文に追記します。 (2015-08-30 12:03:46)【m.ukai】 newt ベースで作られているようなので、NewT SYStem V の略という説を唱えてみます。（で newt が何の略かという泥沼） (2015-08-26 10:16:38) |
今年の春ごろ…長男が5年生に進級したころだったと思うが、こんな質問をされた。
１～100までのすべての自然数で綺麗に割り切れる数って、どんな数だろう？
一応彼なりに答えは持っているのだけど、その答えが大きすぎて算出できない、という。
長男の考え方はこうだ。
まず、100 までの素数を探し出す。
100以下の数は、これらの素数を適切な回数掛け合わせることで作り出せるはずだ。
だけど、これらの素数を全て掛け合わせても、問題の答えにはならない。
素数をかけるだけでは、素数である「２」で割れることは保証されても、４で割れることを保証できない。
２を適切な回数掛け合わせることで、この保証を作り出さないといけない。
この「適切な回数」は、掛け合わせた数が 100を超えない最大の値になるようにする。
２であれば、６回掛け合わせて 64 にする。64 で割れる数字は、32、16、8、4、2でも割れることが保障される。
同じように、３ならば４回掛け合わせて 81とする。
全ての素数に対し、この操作を行う。
そして、最後にこれら掛け合わせて出来た数を、すべて掛け合わせる。
その答えが冒頭の質問の答えとなる。
説明を受けて、なるほど、と思った。考え方はあっている。つまり、それが答えだ。
でも、その数を実際に算出できない。
長男の疑問には条件に入っていなかったが、この数は、条件を満たすうちの「最小の数」でもある。
（素数を使った考え方は、最小公倍数の求め方と同じだ。
つまり、この数は１～１００の最小公倍数である）
この時点で、長男はためしに 10 までの数値で試算を行っていた。
1～10 の自然数で割り切れる数は、2520 だった。
その疑問は、大きすぎて解決できない数としてそのままになっていた。
夏休みも終わりに近づき、長男は宿題を全部終わらせ、急に「Scratch って、どのくらい大きな数を扱えるの？」と聞いてきた。
なかなか難しい質問だ。
宇宙物理学などで大きな数を使う時には浮動小数点を使う、という話は長男は知っているので、コンピューターも浮動小数点を使えることを教える。
その上で、Scratch 内部では 64bit 倍精度演算を行っていて、正確に出せるのは 52bit 分だけど、大きな数の表現としては、さらに 11bit 分の指数が付けられることを教えた。
ややこしい話に最初は混乱していたけど、次に「指数を使うと、大きな数は表現できるけど、その場合は細かな数は出ない？」と聞かれる。
うん、その認識で正しい。正確な数を求めたければ、52bit の範囲に収めないといけない。
じゃぁ、52bit ってどのくらい？ と聞かれたのだけど、即答できない。
32bit で40 億、さらに 20bit 余るけど、10bit で 1024 だから、40億の千倍の千倍くらい、と答える。
ここで、「じゃぁ、１～100までの全ての数で割り切れる数、計算できるかな」と言われる。
先に書いたように、冒頭の話は春のこと。僕はすっかり忘れていたけど、長男はまだ疑問に思っていた。
面白い、やってごらん、とノートパソコンの使用許可を出す。
＃長男が Scratch をやりたいときは、僕か妻に許可をもらってノートパソコンを借りている。
1～100までの素数は知っているのだけど、うまくいったらもっと大きな数も計算してみたいので、と、エラストテネスの篩から作りはじめる。
素数を求めるアルゴリズムね。プログラムの初心者向けの課題として良く出されます。
普通は配列で作るのだけど、Scratch には配列が無い。でも、リストがある。
最初にリストに 2～100の数字を入れて、「倍数」はリストから削除していく、というプログラムにした。
リストの先頭を取り出すと、それは常に素数。
素数を取りだしたら、リストの数値を順次確認し、取り出した素数で割った余りが 0 なら、削除する。
最後に、取り出した素数は、素数を入れるもう一つのリストに追加される。
元となるリストがどんどん削除されていくので、終わりに向かって加速していくプログラムが出来上がった。
見ていてなかなか楽しい。
これで素数が得られたら、次にそれらの素数を掛け合わせ、100を超えない最大の数にした数値を、また別のリストに入れていく。
最後に、リストに入った数値を全て掛け合わせれば答えが出る。
結果は… 6.9720375229..e+40 !
…残念！ Scratch では正確に求められないほど大きな数値だった。
＃最後が e+40 となっているのは、52bit の範囲を超えてしまい、指数表現になったことを意味する。
プログラムを作って、答えは出たけど、正確な数じゃなかったーーー と、残念がりながらも面白がる長男。
せっかくなので、ここは父の威厳の見せどころ。
自分のマシンに向かって、UBASIC を起動する。
というか、以前にちょっと使ってみようとしたけど、使い物にならなくてほったらかしてあったのね。
UBASIC は、DOS 時代のフリー BASIC 。
実効桁数なんと 8640bit (540word) という恐ろしい演算性能を持つ。
DOS では動いたけど、残念ながら今の Windows では動かない。
でも、フリーの DOS エミュレータである DOSBox 上では動く。
…のだけど、DOSBox は英語版 DOS だし、キーボードも US 101 キーボードが前提。
これが「使い物にならない」としていた理由。
とりあえず、数値演算だけだから日本語は使えなくてもいい。
エラーメッセージが文字化けして読めないけど気にしない。
長男の考え方を、どんどんプログラムしていく。
…のだけど、流石に US 101 キーボード用は使いづらい。
いちいち記号を探すことになって効率が悪い。
ちょっと調べると、改造品で 106 キーボード対応があったので、DOSBox を入れ替える。
後で書くけど、その後さらに環境整えたら日本語も出るようになった。
（この時は、BASIC プログラムを作ることが優先で、そこまでやってない）
久しぶりの UBASIC で無駄に手間取った部分もあるのだけど、2時間ほどで完成。
100 Max=100
110 dim F%(Max)
120 for I=2 to Max
130 if F%(I)=1 then 160
140 F%(P)=I:P=P+1
150 for J=I to Max step I:F%(J)=1:next
160 next
170 B=1
180 for I=0 to P-1:A=F%(I)
190 if A<Max/F%(I) then A=A*F%(I):goto 190
200 B=B*A
210 next
220 print B
BASIC ではリストは使えないので、素数を求める部分は普通の配列。
1だと「既にチェックされた」、つまり倍数であることを意味している。
＃ F% というのは、UBASIC 独特の書き方。1word 数値であることを示す。
0 か 1 かを保存するだけなので十分。
こうしないと、540word の変数を配列にしようとして、すぐにメモリ不足となる。
120～160 で素数を求める。
130 で倍数か素数か調べ、素数なら 140 で記録、150 で倍数をチェックしている。
170 からは素数が求まった後で、190 で「100を超えない最大の倍数」にして、200 行でそれを掛け合わせている。
長男が求めていた答えは 69720375229712477164533808935312303556800 だった。
後日追記 2015.9.7
こういう計算なら、UBASIC より Ruby がいいと思うよ、という重要な示唆をいただきました。
恥ずかしながら、Ruby に多倍長型があるのを知りませんでした。
Ruby で書き直してみたプログラムを含め、ここら辺の話、別の日記に書いています。
同じテーマの日記(最近の一覧)
関連ページ
別年同日の日記
申し訳ありませんが、現在意見投稿をできない状態にしています。 |
さて、先の記事に書いた UBASIC の話。
興味を持った人のために環境構築方法を書いておこう。
追記:2015.9.3
DOSBox の最近のバージョンを日本語キーボード対応したものがあったので、そのバージョンを使用するように書き換えました。
まず、DOSBox という、DOS エミュレータが必要になる。
DOS っていうのは、Windows が登場する前の OS ね。
Windows 95 までは、DOS の上に構築されていたけど、XP 以降は NT ベースになったため、DOS は無くなってしまった。
…はずなのだけど、Windows 7 でも 32bit OS なら UBASIC はコマンドラインで動かせた。
マイクロソフトの互換性確保の努力は驚異的だ。
64bit OS を使っていると、さすがに動かない。エミュレータが必要になる。
普通の PC エミュレータに DOS をインストールしてもいいのだけど、DOS エミュレータは最初から DOS を動かす前提で作られているので、手っ取り早いし扱いが楽。
でも、公式には英語版しかない。
DOS 自体が英語環境だし、キーボードも US 101 キーボードが前提。
配布されているバージョンも、もう長いこと 0.74 のままだ。
ただし、「ソースコード配布の公式バージョン」というものがあって、こちらはどんどんバージョンアップしているらしい。
いわゆるベータ版扱いで、使うには自分でコンパイルする必要がある。
これを、日本語キーボードに対応させた人がいる。
ありがたく使わせてもらおう。
展開すると、dosbox-r3850-jp が出来上がる。
インストーラーとか無いから、適当なところに置く。
これで DOS エミュレータの準備は完了。ちょろいもんだ。
dosbox.exe を起動すれば DOS 画面が開くけど、DOS を使ったことがある人でも意味がわからないだろうと思う。
独自のコマンドとか入っていて、Windows との親和性を非常に高めてあるから。
DOSbox が他のエミュレータと違うのは、Windows のディレクトリを「そのまま」ディスクとしてマウント出来ることだ。
Windows の C: ドライブに \DOSBOX というディレクトリを作って、
mount c c:\DOSBOX
とすれば、DOSBox の中で \DOSBOX ディレクトリが C: に割り当てられる。
（もちろんディレクトリは別の名前でも構わない。僕は自分の documents ディレクトリの下に DOSBOX を作っている）
dosbox.exe と同じディレクトリに、dosbox.conf というファイルがある。
中身はあまり気にしないことにして、一番下を見ると [autoexec] というセクションがあって、当初は何も書かれていない。
ここにコマンドを書くと、起動時に自動的に実行される。
だから、ここに
mount c c:\DOSBOX
c:
と書いておくと、起動直後に c: ドライブのルートにいる形になる。
おぉ、DOS っぽい。
さて、これだけでは日本語は表示できない。
その昔、DOS/V パソコン、という言い回しがあったのを覚えている方はどれくらいいるだろう？
IBM-PC 互換機を日本ではこう呼んだのだけど、それは DOS/V と呼ばれる日本語 OS を使っていたからだ。
この DOS/V 、DOS に日本語表示のためのソフトを追加した、ただそれだけのものだ。
そして、当初は IBM が開発し、販売していた日本語表示ソフトは、ユーザーの手で互換品が作られ、配布されるに至った。
これらのフリーソフトを使えば、問題なく日本語が表示できる。
最初に概念を説明しておこう。DOS/V を知っている人なんて、あまり多くないからね。
DOS/V の日本語表示は「フォントドライバ」と「ディスプレイドライバ」に大別される。
フォントドライバは、フォントファイルを読み込んでフォントを提供する。
フォントが無いと何もできない。
ディスプレイドライバは、このフォントを使って画面を表示するのだけど、「英語モード」と「日本語モード」がある。
これを切り替えるための信号を送るためのソフトが無いと、日本語モードに出来ない。
というわけで、フリーのフォントドライバ、ディスプレイドライバ、フォント、モード切替ソフトが必要となる。
ここで一つ注意が必要だ。
dosbox には、デバイスドライバを組み込む方法が用意されていない。
デバイスドライバは基本的に「外部デバイス」を動作させるためのものであって、ソフト的なエミュレータでは必要ないでしょ、ということらしい。
幸い、日本語表示のための「デバイスドライバ」は、デバイスドライバと呼んでいるのが言葉の綾で、OS を拡張するアプリケーションに過ぎない。
昔の DOS を知らないとわかりにくい話なのだけど、デバイスドライバとアプリケーションは、ほぼ同じ構造なのだけど、ほんの少しだけ作り方が違った。
これを、巧妙な方法で「デバイスドライバとしても、アプリケーションとしても動作できる」ソフトとして作っている人もいる。
そこで、フォントドライバとディスプレイドライバは、デバイスドライバ専用として書かれたものではなく、アプリケーションとして動作できるものを使う必要がある。
このページ、非常に古くて、なぜか文字が読めなくなっている。
CTRL+A とかして選択反転すると読めるのだけど、「ダウンロード」リンクだけは読めるので、とっととダウンロードさせてもらおう。
展開すると、WEB に書かれたのと同じ内容のテキストファイルが入っている。
これらの中身を、先に書いた c:\DOSBOX\ の下にディレクトリを作って置こう。
c:\DOSBOX\DISPV に置くことになる。
このディスプレイドライバは、IBM 公式の日本語ドライバの互換品を作る、という試みを始めた人の作ったドライバだ。
敬意を払ってフォントドライバもこの方のプログラムでそろえたかったのだけど、残念ながらデバイスドライバとしてしか、動作しない。
右側のペインから、fontn10.lzh を探してダウンロードしてほしい。
こちらがフォントドライバになる。アプリケーションとして動作できるので DOSBox でも組み込める。
先の DISPV と同じように、展開しておいておこう。
c:\DOSBOX\FONTN になる。
X68k 用に作られたフリーフォントを、DOS/V 用にコンバートして配布している。
小伝馬町16が使いやすいと思うけど、16dot フォントであればある程度お好みで。
中身を、c:\DOSBOX\FONT に置こう。
＃上記ページ、現在リンク切れ (2016.12.28)
もっとも、waybackmachine には残っています。
FONTX2 形式の 16dot フォントであれば、ネット上で配布されている他のものでも構いません。
・CHEJ
日本語と英語を切り替えるのに使うソフト。
最初は英語環境で始まるので、このソフトが無いと日本語を表示できない。
中身を、c:\DOSBOX\CHEJ に置こう。
さて、ファイルが揃ったところで、設定ファイルを書く。
フォントドライバに読み込ませるフォントを設定しないといけないのだけど、設定サンプルも何もない。
何も考えず、c:\DOSBOX\FONT\ の下（小伝馬町を置いたところ）に、FONTN.INI を作ってほしい。内容は以下の通り。
[CODE] ; Define code area.
F040 F0FC ; user font area
[FONT] ; Install font file.
GONHN16X.TLF
GONHN19X.TLF
GONZN16X.TLF
[CODE] 以下は、外字領域を指定している。
[FONT] 以下の内容は、先ほど展開した小伝馬16 のファイル名３つを書く。
HN16 は、縦16ドットの半角アスキーフォント。
HN19 は、縦19ドットの半角アスキーフォント。
ZN16 は、縦16ドットの全角日本語フォント。
半角フォントに 16dot と 19dot があるのが謎に見えるだろうけど、19dot は基本的に、下に３ドットの空白を入れただけ。
DOS/V では 25行モードと 30行モードがあるのだけど、縦方向が 480dot なので、１行の大きさは 19dot と 16dot になる。
英語のフォントで「罫線」があるため、縦方向に繋げるためには「25行モードでは３ドットの余白を入れる」というわけにいかず、19dot のフォントが必要となる。
これで、日本語を表示する準備が整った。
さて、いま入れたソフト群を使えるように、dosbox.conf の autoexec を追記する。
(さっき書いた、mount して c: する下に続ける）
\fontn\fontnx /P=c:\font\
\dispv\dispvb
\chej\chej jp
\dispv\vmx 70
フォントを組み込んで、ディスプレイドライバを組み込んで、日本語モードにし、縦 30行モードにしている。
ちなみに、\chej\chej us とすれば英語に戻る。
\dispv\vmx 3 とすると、縦 25行モードになる。
これで DOSbox を起動すると、自動的に日本語モードに切り替わるはずだ。
やっと下地ならしが終わった。
これで UBASIC を導入できる。
ありゃ？ しばらく前にダウンロードして自分のマシンに入れたはずなのだけど、今見たら繋がらない。
一時的な障害だと良いのだけど、Internet Archive に保存されたページをリンクしておこう。
配布ファイルも保存されていて、ちゃんとダウンロードできる。DOS/V 32bit 版だ。
ついでと言っては何だけど、その下にある「ヘルプファイル」もダウンロードすると良い。
これらを C:\DOSBOX\UBASIC\ の下に展開する。
DOSBox から、C:\UBASIC\UBV32.EXE を起動すれば、UBASIC が使える。
8640bit (540word) という驚異的な演算精度を持つ BASIC 。
その精度を活かし、複素数演算もできる。
当時は非常に標準的だった、Microsoft Basic に近い文法を持つ。知っている人ならなんとなくで使える。
詳細なリファレンスは、ヘルプファイルの中の UBHELP.XXX がテキストファイルなので読んでみよう。
実は、UBHELPV.COM を実行してから UBV32.EXE を実行すると「HELP」コマンドで UBHELP.XXX を項目別に分けたオンラインマニュアルを読める。
CTRL + \ で、カーソルが載っている命令の詳細がわかる。
…はずなのだけど、DOSBox 上ではなぜか不安定で、CTRL + \ は効かないし、ハングアップすることもあった。
DOS 環境上では同時に２つの作業は出来なかったので、このオンラインマニュアルは重宝したのだけど、Windows なのだから UBHELP.XXX をテキストエディタで開いて読むのでも良いと思う。
chej 、vmx 、ubv32 など、よく使うコマンドはパスを通しておくと使いやすい。
c:\chej\chej と入れる代わりに、chej だけで実行できるようになる。
dosbox.conf の autoexec に以下の行を追記する。
set path=c:\chej;c:\dispv\;c:\ubasic;
Windows でもコマンドラインを使う人は path 環境変数を知っているかもしれない。
セミコロン区切りで上の書式のようにディレクトリを列記すると、入力されたコマンドをそれらのディレクトリから探し出してくれる。
最終的に、ディレクトリ構成などはこうなる。
C:\DOSBOX\CHEJ\（CHEJを展開したもの）
\DISPV\（DISPVを展開したもの）
\FONT\（小伝馬16を展開したもの）
\FONTN.INI
\FONTN\（FONTNを展開したもの）
\UBASIC\（UBASIC、およびヘルプファイルを展開したもの）
上記の C:\DOSBOX\FONT\FONTN.INI は自分で作る必要がある。内容は以下の通り。
[CODE] ; Define code area.
F040 F0FC ; user font area
[FONT] ; Install font file.
GONHN16X.TLF
GONHN19X.TLF
GONZN16X.TLF
適当なところに展開された、DOSBox に入っている dosbox.conf の最後の部分に以下を追記
mount c c:\dosbox\
c:
\fontn\fontnx /P=c:\font\
set path=c:\chej;\dispv;c:\ubasic;
dispvb
chej jp
vmx 70
cd \ubasic
ubv32
もし余裕があれば、dosbox.conf の中から「cycles=auto」と書かれている部分を探し出し「cycles=max」に書き換えよう。
昔のパソコンの CPU 速度のエミュレートをなくし、最高速で動作するようになる。
よくわからない人は書き換えないほうが無難。
遊ぶ分には、遅くてもそれほど問題ないから。
これで、DOSBox 上で問題なく UBASIC が使えるようになったと思う。
DOSBox を起動して、UBV32 コマンドを入力すれば BASIC 画面になる。
先に書いたプログラムを実行してみよう。
c:\DOSBOX\SAMPLE.UB の拡張子で上記プログラムをテキストファイルとして保存すれば、load "SAMPLE.UB" で読み込むことができる。（コマンドの最後はEnterを押すこと）
その後、RUN （これもEnterを押す）すると、実行される。
１～100の全ての自然数の最小公倍数が算出できる。
数が大きすぎて、UBASIC 以外の言語で処理しようとすると、いろいろと面倒なプログラムを作らないといけないのだけど、UBASIC なら問題なく扱える。
ちなみに、冒頭の Max を 100 ではなく、1000 にすると「1～1000の最小公倍数」になる。
EDIT コマンドを使うと、プログラムが表示できる。
PAGE UP / DOWN で画面を送り、カーソルを書き変えたいところに移動して、書き変えた後は Enter 。
＃複数行を書き変えるときは、1行ごとに Enter する。
BASIC では、カーソルは自由に動かせるが、基本的にコマンドを「1行単位」で受け付ける。
冒頭が数字で始まる場合はプログラムの格納を指示した命令と認識されるため、各行で Enter が必要になる。
さて、UBASIC ではいくつまで計算できるだろう？
5000 は大丈夫だけど、10000 は桁あふれでエラーとなった。
どこまで可能かは確かめたのだけど、あえて書かない。
興味がある人は自分でプログラムを改造して確かめてみてほしい。
え？ 日本語入力したい？
…残念ながら、ここに書いたのは「表示する」ための方法。
とりあえずは、UBASIC で数値計算したい、日本語で表示されるエラーメッセージも読みたい、という目的だったので、「入力する」必要が感じられなかった。
asave コマンドを使うと、BASIC のプログラムをテキストとして保存できる。
テキストファイルで日本語を書き入れ（シフトJISでセーブすること）、load で読み込みなおせばプログラム中で日本語を使うことも一応できる。
DOS 用のフリーの FEP が存在しないわけではないので、入れてみれば動くとは思う。
ただ、フリーで作られた FEP って、大抵実験的で癖が強いんだよね…
関連ページ
別年同日の日記
申し訳ありませんが、現在意見投稿をできない状態にしています。 【ざっちゃ】 最初は日本語が表示されず真っ黒画面でしたが、FONTN.INIをFONTN下に作っていたためでした。FONT下に移したらうまく表示されるようになりました。 FONTとFONTNという紛らわしいサブフォルダ名に注意ですね。 (2017-12-31 20:52:40)【さとり】 FONTX付属の吸いだしツール、DOS窓でも使えるからフォント難民の人は試してみて。（64bit未確認） (2017-10-31 16:35:15) 【みっくん】 Windows10でdosbox-0.74-svn日本語動作、turboC-BGI動作確認OKです。安心しました。 (2017-02-21 13:56:50) 【あきよし】 ZN16、正しく設定されてますでしょうか？ 空白になるならおそらく日本語モードにはなっているので、フォントが読み込めていないように思います。 (2017-02-05 17:31:37) 【さむい】 こんにちは。有意義な記事ありがとうございます。日本語DOSVのソフトを動かしたく試させていただきましたが、日本語が表示されません。ただの空白になる。アルファベットは表示されます。すみませんが、ご助言いただけないでようか？ (2017-02-03 20:57:08) 【ななーし】 早急な対応ありがとうございます。チャレンジしてみます (2016-12-28 12:23:58) 【あきよし】 リンク切れ報告ありがとうございます。ネットアーカイブへのリンクと、そのほかの代替方法を追記しました。 (2016-12-28 10:52:57) 【ななーし】 こんにちは。平木敬太郎フォントがリンクが切れており、どのフォントを入れてよいか悩んでいます。よろしければご教授下さい。 (2016-12-26 13:04:30) |
僕が大学生の頃に、シャープの X68000 というパソコンを使っていた。
通称 X68k 。k はキロの意味で、数字の後ろにつけると「000」を意味する。
X68k は当時としては非常に先進的なホビーパソコンだったのだけど、ここら辺の話題は18年前に記している。
その記述の一番最後に、「私のX68kは、この記事を書いた直後に故障し、電源が入らない状態になりました。」と書いている。
これ、当時は知らなかったのだけど、X68k の持病。
四級塩電解コンデンサ、という電子部品があり、当時は新製品で、高性能な高級品だった。
X68k ではこの部品を多用したのだけど、何年もたってから「耐久性が悪く、経年劣化する」ことが分かった。
何年もたたないと発覚しない問題で、当時としては仕方のない事例。
今ではこのタイプのコンデンサはあまり使用されない。使用された場合も、もちろん改良され、問題は解消している。
でも、とにかく X68k は経年劣化し、主に電源部分が故障する。
電解コンデンサ内の電解液と呼ばれるものが漏れ出し、場合によっては基盤を腐食する。
ほかの部分に問題がなくとも、電源が入らなければ当然のことながらコンピューターは動かない。
後に問題と対処法を知った。
コンデンサを全部等価品に付け替えればよい…のだけど、電子部品知識がなくて、どれが等価品かわからないし、はんだ付けに自信がない。
（はんだ付けの手際が悪くて部品を壊した経験は何度もある）
ATX …昔の PC 互換機の電源を流用して修理する、という方法も一時期流行したけど、これも時代とともに ATX 電源が入手困難になった。
そして、X68k は「いつか修理できる」と信じたまま、荷物の奥に埋もれっぱなしになった。
５月の連休に「マイコンインフィニット PRO 68k」に遊びに行った。
X68k を中心とした、古いパソコン好きが集まる展示即売会。
正直なところ、自分が古いパソコン好きなのかどうか、よくわからない。
特にこういう場では浮いている気がする。
だって、皆さん本当に今でも昔のパソコンが好きで、精力的に活動している。
僕は、「当時の思い出」を大切にしているだけで、今更昔の機械を使ったり、当時のゲームで遊ぼうというほどの情熱がないのだ。
とはいえ、会は非常に楽しかった。
情熱に当たり、もう一度 X68k で遊んでみたいな、という気にはなった。
でも、X68k 壊れてるし…と Twitter で書いたところ、マイコンインフィニットにも出展していて、同様の会である「レトロエクスプレス」の主催もしている田辺敦司さんに、「よかったら修理しましょうか？」と声をかけていただいた。
もちろん実費＋アルファ程度はかかるわけだけど、趣味でやっているそうで、技術者に働いてもらう金額としては非常に安い。
ただし、趣味だし、常に修理待ちがあるのでいつ完成するかはわからない。
すぐにお願いすることにした。
それから３か月、２週間前の日曜日に、修理が終わって戻ってきた。
しかし、この日は予定があって外出。動作確認できず。
平日は忙しくて、次の休日（先週末）に動作確認を試みる。
…あれ、ＲＧＢケーブルがない。
えーと、昔の日本のパソコンって、今の PC の RGB ケーブルとは違うものを使っていた。
15ピン、というピン数も、その信号の意味も同じなのだけど、今はピンが３列、昔は２列。物理的に繋げられない。
家中探したら、３列→２列変換アダプタが見つかった。
古いパソコンの液晶モニタにつないでみる。しかし、 OUT OF RANGE 表示。
今のパソコンは、画面表示に 48KHz～100KHz くらいの水平走査周波数を使っている。
簡単に言えば、周波数が高いほどドットが細かく、画面に表示できる情報が多くなる。
今のディスプレイも、当然この周波数に対応している。
でも、X68k は 15KHz～31KHz を出力する。今のディスプレイでは周波数の範囲を超えてしまう。
これがつまり「OUT OF RANGE」表示の意味。画面を出力できない。
すっごく古い、ブラウン管ディスプレイを引っ張り出してつないだら動いた。
グラディウスを読み込ませて、起動することに成功。
でも、どうも周波数がぎりぎり下限のようで、映像が不安定だし、時々ディスプレイからパチパチ音がする。負荷がかかっている。
ディスプレイに負荷をかけるのは怖いので、起動成功から１分ほどで慌てて電源を切る。
ＲＧＢケーブルを探しても見当たらないので、アマゾンで購入。
今更こんな古いケーブルを売っていることに感謝。まさにロングテール。
ケーブルはすぐに届いたが、やはり平日は忙しく、今日やっと動作確認。
純正モニタに接続し、グラディウスを起動。…できない。おかしいな、こないだはできたのに。
どうも、フロッピーディスクドライブ 0 が不調のようだ。全くダメなのではなく、不安定。
先日はたまたま起動できただけみたい。経年劣化だろう。仕方ない。
ハードディスクからの起動は、途中まではいくのに、なぜか止まってしまい、起動できない。
ＦＤＤ１からグラディウスを起動すると、動作はする。
久しぶりに遊んだら、モアイステージで終わった。昔は軽々一周してたのにな。
ところで、家にあった純正マウスは、マウスのボールを覆うゴムが劣化し、ひび割れていた。
固くなってひび割れる一方で、部分的にはべたついている。
別売りの純正トラックボールも持っているのだけど、こちらは壊れているようで反応しない。
これまた純正（？）の、X1 用ゲームパッドは問題なく動いた。
ハードディスクから起動できない問題を追う。
フロッピーから起動し、ハードディスクの CONFIG.SYS を眺める。
起動時に使われる設定ファイルね。
標準エディタである、ED.X を使って編集。
…もう使い方忘れたよ。HELP ボタンを押したらキー操作が出てきて助かった。
何が悪いかわからず、不要そうなドライバを外してみては、再起動。
うまくいかないともう一度フロッピー起動して眺める。
…なんか、C:\COMMAND.X が読み込めないようだ、とわかってくる。
COMMAND.X 単体で動かせば動くし、ファイルが壊れているわけではないようだ。なんで？
しばらくやっていて、わかった。
そういえば、X68k では「起動ディスクが A: になる」のだっけ。
PC互換機では、起動ディスクにかかわらず、ハードディスクは C: から始まる。
これが気持ち悪いので、X68k のデバイスドライバで「フロッピーを常に A: B: にして、ハードディスクを C: にする」ドライバを組み込んでいた。
ところが、なぜか（いろいろいじる前から）このドライバがコメントアウトされていて、そのせいで C:\COMMAND.X なんてものは存在しなくなっていた。
気づいたので、ドライバをちゃんと組み込んで解決。
＃当時のパソコンは MS-DOS が標準的な OS だけど、X68k は CPU が違うため DOS は使えなかった。
しかし、X68k の OS は操作方法はほぼ DOS 互換。もちろんソフトの互換性はないけど。
＃先に COMMAND.X と書いたのは、DOS でいえば COMMAND.COM に当たるもの。
また、起動ドライブが A: というのは、DOS を使っていた PC-98 でもそうだったため、それを真似たもの。
ところが、今度は AUTOEXEC.BAT がうまく働かない。
起動直後に実行するプログラムを記述したファイルね。
どうも、いくつかのプログラムで「メモリが足りない」と怒られてしまう。
あー、これはあれだな…。コマンド名なんだっけ。
ディレクトリの中を探し回り、SWITCH.X を見つける。そうそう、こいつだ。
しかし、「OS バージョンが違う」と怒られ起動できない。
気づくと、OS がバージョン３だ。最終バージョンだけど、一番普及したバージョン２との互換性が微妙に悪かったもの。
うーん、きっと「とりあえず最新版に」とアップデートしていたのだろうなぁ。
フロッピーから起動して、SWITCH.X を動かす。
これ、X68k の様々なハードウェア設定を行うプログラム。
設定は SRAM に書き込まれるのだけど、長年通電していないので、SRAM も消えていて当然だ。
やはり、メモリ設定が 1M になっていた。初代機の設定がデフォルトなんだな。
僕のマシンは標準で 2M 搭載しているので、2M に設定する。
これで、ハードディスクから起動できるようになった。
ハードディスクの中を少し覗いてみると、TF があった。
TF! なんと懐かしい。
当時のパソコンは、すべてをコマンドで操作する。
大抵の操作は「ファイル」に対して行われるのだけど、最初はどんなファイルがあるかすらもわからない。
なので、まずファイル一覧を表示するコマンドを使い、次にファイルの中身を見るコマンドを入れる。
そのコマンドで、今見たファイル名をタイプする。正確に同じ名前になるように。
間違えるとエラーになる。
でも、「ファイラー」と呼ばれるソフトを使うと、操作を簡単にしてくれた。
ファイル一覧を表示して、ファイルを選んで、簡単なキー操作で処理が行える。
拡張子によって最適な動作を行う、というような指定も可能。
記憶の限りでは、DOS では「エコロジー」が最初のもので、フリーウェアで FD が大人気だった。
でも、これらのソフトは、常に「現在のディレクトリ」が操作対象だった。
ファイルをコピーしようとすると、どこにコピーするのか聞かれ、パスをタイプする必要がある。
TF は、X68k で結構人気のあったファイラー。画面上に２つのディレクトリを同時に表示する機能があった。
コピーも、片方からもう片方に、簡単に行える。
すごく便利だった。X68k ユーザーが DOS ユーザーに自慢できる、数少ないソフトの一つだった。
Windows で Exploler 使っているのとほぼ同じ感覚、といってもよいと思うよ。
というわけで、良いものを見つけたので TF を起動して、ディスクの中を探検してみる。
…大学時代に書いた小説とか、詩とか、日記とか出てきましたよ。
こっぱずかしいけど、これも自分の歴史。そのうちなんとかして、今の PC にファイルを持ってきて保存しておくことにしよう。
ほんのわずかだけど、なんかエロ絵が出てきた。
これは削除。子供が X68k に興味を持っていじり始めるかもしれないので。
当時は今と違ってインターネットは普及していないし、エロ絵なんて入手困難だった。
＃コミケとか行っていたらあったかもしれないけど、僕は行ってなかった。
ちなみに、今見るとたいしてエロくないよ。でも、入手困難だからそんなものでもありがたく保管してたのだろう。
というわけで、ひとまず X68k が普通に操作できる状況にはなった。
しかし…若気の至りでいろいろと変な環境を構築していて、素直に使いづらい。
UNIX 風のシェルとコマンド入れてあって、DOS とも UNIX とも違う微妙な操作感。
先に書いた通り、OS をバージョン３にしていたようだが、バージョン２用に作られていた便利なドライバなどが動かない。
特に history ドライバが動かないのは困る。
history ドライバは、X68k のコマンドライン入力を過去数百件分覚えておいて、キー操作ですぐに呼び出せるようにするドライバ。
UNIX ユーザーなら、bash で history-serch-backward / forward が使える状態、といえば理解してもらえるでしょう。
MS-DOS にはこうしたドライバはなかったので、非常に便利だったのだけど…
たぶん、X68k 使っていた末期には UNIX 的な環境にするのがうれしかったので、使えない状況になっていても気にしてなかったんだろうな。
いちおう、RS-232C クロスケーブルも購入してある。
ある程度使える環境が整ったら、別のマシンと接続して、古いファイルを吸い出してみよう。
関連ページ
別年同日の日記
申し訳ありませんが、現在意見投稿をできない状態にしています。 |
先日 UBASIC で 100 までの自然数の最小公倍数を求めた、という話を書いた。
そしたら、「ruby使えばいいのに」という重要な示唆をいただいた。
なるほど。調べてみると、ruby は UBASIC 以上の有効桁数で整数演算ができた。
僕は ruby 使いではないので知らなかった。教えてくださった方に感謝。
ruby は一度手を出したことがあったけど、勉強途中で頓挫したままになっていた。
手を出したのは、1999年。僕が会社勤めを辞めて独立した時だ。
当時は perl で WEB プログラムできる人材が求められていて、独立して perl プログラムで稼いでいた。
当時はネットが「新しいメディア」で、相場というものが存在していなかった。
学生がバイト気分で気軽に「プログラム書きます」なんて仕事を請け負っていたのだけど、生活が懸かっていないバイト気分なので、めっぽう安い。
でも、バイト気分なので責任感もない。金を払ったのに納期通りに上がってこず、催促しても「定期試験なんで」と仕事をしようとしない…なんて話も実際に聞いた。
で、そういう痛い目にあった人は、会社も設立して真剣に仕事を請け負っている、といえばそれなりの金額を出してくれた。
＃当時は今みたいに１円起業はできず、会社組織にしている、ということが本気度を示す指標だった。
でも、痛い目にあった人でないと、学生バイトと金額を比較され、同じとまでは言わないが安くやってくれないか、と値切り交渉をされる。
割に合わない仕事も何度かやった。
そして、じゃぁほかの人がなかなか手を出していない言語をやってみよう、と ruby に手を出した。
perl を勉強していたころから、perl をさらに使いやすくした言語として、ruby の噂は聞いていたから。
しかし、当時 ruby はそれほど有名ではない言語。上に書いたように、perl 使いの一部が気にしていた程度。
そんなわけで、ruby を勉強し始めてすぐに、ruby ができたところで仕事はない、と気づいた。
ちょうど仕事で知り合った人に「PHP を覚えてほしい」と頼まれ、PHP の勉強に切り替えた。
その人は日本PHPユーザー会の創設メンバーの一人だった。
当時は PHP だって知られておらず、覚えても仕事がありそうにはなかったのだけど、ありがたいことに PHP はその後有名になり、PHP ができるのであればそれなりに仕事があった。
さて、上に書いた話で ruby で勉強したのは、perl の延長として使えそうか、という程度の調査だけ。
プログラムを組むために、条件分岐や繰り返しなどの文法構造は理解したけど、データ構造を勉強する前に頓挫した形。
なので、bignum なんて存在を知らなかった。
＃1999年当時のバージョンでも bignum は存在したのかな…とネットで調査したところ、当時からちゃんとあったようだ。
だから、単に僕が勉強してなかっただけ。
この bignum 、なかなか優秀で、存在を全く意識する必要がない。
意識しないでよいからこそ、当時気づいていなかったのかもしれない。
下に、先日のプログラムと同等の計算を行うプログラムを示しておこう。
アルゴリズムなどは、ruby 向けに多少異なる。
Max = 100
F = Array.new(Max/2-2) {|i| i*2+3}
P = [2]
while a = F.shift
P.push(a)
F.reject! {|i| i%a==0 }
end
b=1
P.each do |num|
a=num
a*=num while a<=Max/num
b*=a
end
p b
大きく３つのブロックに分かれている。
最初のブロックは、準備を行っている。
最初の行で 100 と定義している。これで、100 までの自然数の最小公倍数を求める。
２行目では、3～100 までの奇数のリストを生成している。素数の候補だ。
３行目は、素数のリストの準備。唯一の偶数である２は、最初から入れてある。
中央のブロックで、エラストテネスのふるいを実行している。
奇数リストの先頭を取り出して、素数リストに入れる。
と同時に、reject を使って、奇数リストから、今取り出した素数の倍数を削除する。
最後のブロックでは、素数リストから順次値を取り出し、適切な倍率をかけ、b に掛け合わせていく。
最終的に b が最小公倍数だ。最後の行で表示している。
UBASIC では 6006 までしか計算できなかった。
6007 は素数で、それを掛け合わせると桁あふれしてしまうのだ。
しかし、ruby では 100000 でも計算できた。さすがに時間はかかるけど。
答えは、69528383... で始まる、 43452 桁の数値になった。
それはさておき、UBASIC インストール方法まで含めて書いたのは、実はそれなりの意図もあった。
まず一つ目は個人的な理由。
もともと計算は小学生の長男の興味で始まったので、長男に BASIC を教えようと思ったの。
特に書いてないけど、長男がエラストテネスのふるいを作る部分で悩んでいた時に、家にある初心者向けのテキストから、エラストテネスのふるいのサンプルプログラムを見せたのです。
でも、BASIC を理解していないと全く分からない。目の前にアルゴリズムの答えがあるのに、それが理解できない。
日本語環境まで整えたのは、長男に使わせたときに、エラーメッセージが文字化けするようでは扱えないためです。
でも、これだけなら家の中でやればよいことで、インストール方法まで明示する必要はない。
最近の言語は、グラフィックを扱うのにややこしい仕組みが必要なものが多い。
でも、BASIC 時代はグラフィックの扱いは簡単で、UBASIC も例外ではない。
そして、UBASIC では複素数演算ができる。
５年も前に「いつか書きたい」と宣言したまま一切書いていない、マンデルブロ集合の魅力について書くのに良いのではないか、と考えていた。
マンデルブロ集合って、非常に複雑で興味深い図形ね。
非常に複雑なのに、その図形を描くための方法は非常に単純。
Z = Z2 + C
という、たった一つの式を延々と計算し続けて、結果をグラフにすればよい。
ただし、Z も C も複素数、というのがみそ。たった一つの式ではあるけど、その式の意味が非常にややこしい。
当然のことながら、複素数の理解が必要。グラフとして示すので、複素数平面も知らなくてはならない。
さらに、一般の計算機言語では複素数を計算することができないため、実数部と虚数部を分離して計算するテクニックが必要になる。
画像の生成は非常に厄介だし、計算している座標系と、パソコン画面の座標系を変換するマッピングテクニックも必要となる。
UBASIC なら、複素数を計算できるし、グラフィックを簡単に扱える。座標系だって自由に変えられる。
なぜなら、UBASIC は高校生が数学に親しむために作られた言語だから。
「テクニック」が必要となる部分を、できるだけ言語側で吸収し、アルゴリズムの理解だけを求めるようになっている。
…と、熱い思いで語ったけど、実は先日以降実際にマンデルブロ集合を描くプログラムを作ったところ、あまりの遅さにどうしようか迷っている。
UBASIC でアルゴリズムの概要だけ示すけど、実行はお勧めしない、というような書き方になるかも。
ruby でも複素数演算パッケージは存在するようだし、これも ruby でやってもよいかもしれない。
こちらは、BASIC 程気軽にグラフィックを扱うことはできないようだけど、やはり描画パッケージ自体は存在する。
どちらにせよ、記事を書くとしたらだけどねー。
複素平面を理解してもらうためには、まず虚数の面白さから入らないといけなくて、そこで悩んでしまって書くのが止まっている。
一応、目標は「小学生でも理解できるようにしたい」ということなのだけど、虚数の必要性を伝えるのはなかなか難しい。
同じテーマの日記(最近の一覧)
関連ページ
別年同日の日記
申し訳ありませんが、現在意見投稿をできない状態にしています。 |
今日は、レイ・ドルビー博士の命日(2013)
ドルビー…っていうと、カセットテープを知っている世代には、なんかカセットテープの音質をよくするあれね、という記憶があると思います。
その後多くの音響技術を作り上げるのですが、あの「カセットテープのシステム」がドルビーが世界的に有名となったきっかけ。
今更覚えている人がどれくらいいるかわかりませんが、その昔、テープレコーダーの時代には、独特の「高音域のノイズ」が入りました。
高い音で、サー…っていう雑音が入るのね。
原因は、テープを動かしているため。
テープには磁性体が塗られていて、この磁性体の磁場を変化させることで記録を行います。
磁性体は、小さな磁石です。
テープが動けば磁場が動く。これを読み取って再生するのですが、「何も録音されていない」ときでも、磁場はかすかに動くのです。
これにより、高音域のノイズが生まれます。
＃この、テープ由来のノイズを「ヒスノイズ」と呼びます。
テープ由来でなくても、同じような音はヒスノイズと呼ばれるけど。
もう一つテープ時代特有の技術話を。
テープレコーダーは、全周波数を均一に記録できるわけではありません。
テープを動かすことによる「磁場の変化」で記録を行うので、低周波数になるとこの変化がゆっくりになりすぎて、記録が弱くなります。
また、テープの動く速度に比較して、早すぎる動き…高周波数の音も、うまく記録できず、記録が弱くなります。
もともと、テープレコーダーは人の声を記録することを前提に開発されました。
そのため、人の声の周波数はきれいに録音できますが、それよりも低かったり、高かったりすると記録が弱くなる性質があるのです。
そのため、テープに音を記録し、再生すると、音が歪みました。
これは先に書いた高周波ノイズとは別の問題ですが、テープレコーダーの難点でした。
どちらも、テープレコーダーの原理上「仕方のないこと」でした。
でも、ドルビー博士はこれをどうにかしたかった。1966年に、ドルビー・ノイズリダクションシステムを完成します。
両方の問題を一挙に解決する、素晴らしいアイディアでした。
高音域は、記録が弱くなってしまうので、あらかじめ高音域の音だけ大きくしたうえで録音します。
再生する際には、読み取ってから音を小さくして、再生します。
これによって、記録の弱さを補えます。同時に、高音域で勝手に発生してしまうノイズも、「小さくして再生」するので軽減できます。
基本アイディアはこれだけ。
低音域も音を大きくして記録したり、いろいろな微調整があり、音質が明らかに向上しました。
当初は、映画などに使用される音響技術として使われ始め、のちには民生用のコンパクトカセット（いわゆる、カセットテープ）でも使われています。
＃映画用と民生用では、多少技術内容は異なります。
ノイズリダクションシステムを皮切りに、ドルビーサラウンド、ドルビーデジタルなど、ドルビー博士は時代の求める音響技術を次々と開発していきます。
パソコン用にドルビーデジタルが出てきたころ、僕は「ドルビーといえばヒスノイズ軽減」と思っていたので、テープの存在しないパソコン音源になぜドルビーが？ と思いました。
これ、音声圧縮システムなのね。mp3 などと同じ。
ac3 がドルビーデジタルを意味していて、5.1 チャンネルサラウンド。
左右だけでなく、センター、後ろ左右、低音用サブウーファーの音声を同時に記録できます。
ドルビーサラウンドは、ステレオ 2ch で、後ろスピーカーから出す 3ch 目の音も記録する技術。
ステレオスピーカーでも問題なく再生でき、スピーカーを増やすと迫力が増すため、広く使われました。
のちに改良され、ステレオ音声記録で、5.1ch 再生まで可能になっています。
テープ時代のドルビーは、ノイズを低減する代償として、音が少し歪む、という問題もありました。
パソコンのプログラムを記録する際は、ドルビー機能を使わないことが推奨されたものです。
＃パソコンのプログラムを、1200Hz / 2400Hz の「音」で 0/1 を表現して、カセットテープに記録していた時代があったのですよ。
ドルビーサラウンドも、ステレオと互換性を持つ記録で 5.1ch 再生できる、というメリットはありますが、もちろん最初から 5.1ch を記録するのに比べると音は悪いです。
ドルビーデジタルも、圧縮形式としては初期のもので、今となっては後発の dts のほうが音質が良い、と言われます。
ドルビーの技術は、音質を良くしようと作られているものが多いのに、「音が悪い」といわれやすい。
ドルビー技術は、最初の制約の中で、工夫によって音質を上げようとするものが多いです。
制約自体をなくして、後から作られた技術に劣るのは当然。
そこと比べて悪口を言うのは簡単だけど、現実問題として存在する制約をクリアできるドルビーの技術は、広く使われていることが多いのです。
ドルビー博士はすでに亡くなりましたが、研究所とスタッフは活動を続けています。
これからも、音響の新技術を開発し続けるのでしょう。
同じテーマの日記(最近の一覧)
関連ページ
森公一郎 命日(2015) レイ・ドルビー誕生日(1933)【日記 16/01/18】
別年同日の日記
申し訳ありませんが、現在意見投稿をできない状態にしています。 |
子供たちが別の部屋に引っ越した…という話ではあるが、これで出てきた荷物は１０年前の引っ越しの荷物。
ずっと片付かなかった理由は、「ほぼ不要なものばかり」だから整理する必然性がなかったため。
もう一つ、小さな子供がいるといちいち興味を持たれてしまって、うっとうしいので整理できない、というのもあった。
今回も、古いものを引っ張り出しているといちいち「これ何？」とか聞かれて面倒だたのだけど。
なんでこんなの置いてあったのか、というゴミも多い。
１０年の間にロストテクノロジーになってしまったものもあって、久しぶりに見ると面白い。
非常に古いヒューレット・パッカードのプリンタと、ネットワーク対応にするための機械が出てきた。
この機械、普通のプリンタをネットワーク対応にできるんだぜーっっ！ って、今の人には理解してもらえない当時のハイテク技術。
プリンタを問わないのだけど、相性が確認されている HP のプリンタと一緒に使っていた。
そもそも、「プリンタがネットワーク対応ではないかった時代」を知らない人もいそうだ。
その昔、プリンタは専用の（USBみたいな汎用ではない）出力専用ポートを使い、パソコンに直接繋げられていた。
ネットワーク対応によって「複数のパソコンから使える」プリンタも存在したけど、すごく高価だった。
もしくは、プリンタのオプション危機で高価なカードを購入すると、ネットワーク対応になった。
そんな時代に、HP は、メーカーを問わずに普通のプリンタをネットワーク対応にしてしまう、魔法の機器を作っていた。
仕組みとしては、Windows NT サーバーに接続されたプリンタが「ネットワーク対応」になるのと同じだった。
機器がサーバーになっていて、Windows / Mac / Unix それぞれのネットワークプリントプロトコルを解釈できる。
僕は当時、 Linux と Win と Mac を同時に使っていたし、妻のパソコンもあったので、プリンタをネットワーク対応にしていたんだ。
＃Linux 使っているなら netatalk と samba 入れれば…という話もあるが、当時はまだ「可能だけど不安定で、設定も面倒」だった。
これ、引っ越し前にはすでに不要になっていて、捨てようと思っていたけど、間に合わなくてとりあえず持ってきたものだ。
そのまま荷物のそこに埋もれて保管されていた。
今書いたように、プリンタポートは「出力専用ポート」だ。
にもかかわらず、ここに接続する CD-ROM ドライブ、なんてものも出てきた。
プリンタは 8bit パラレル出力なのだけど、実は紙切れなどの信号を受け取るために、4bit の入力があるのね。
さらに、セントロニクス社の独自規格だったプリンタポートが IEEE1248 で標準化された際、8bit 出力を「入出力」にもできる拡張機能が盛り込まれた。
でも、これはあくまでも拡張機能。普通のプリンタポートでは使えない。
そこで、先に書いた 4bit 入力を使い、4bit 入力 / 8bit 出力で使用できる、というモードも作られた。
これなら、従来のプリンタポートと互換のまま、ドライバの工夫だけで使える。
8bit 入力を使う場合は、4bit 入力の互換モードを使い、機器側から PC 側に、8bit 入力に対応しているかどうかを尋ねる。
そもそもこの「尋ねる」信号に対応してこなければ何も帰ってこないし、対応していれば 8bit 出力を 8bit 入出力に切り替えたうえで、「対応してるよー」と返す。
僕の持っているドライブは、4bit 入力のまま動作する。CD ROM としては等倍速の非常に遅いものだけど、当時の CD-ROM が接続できないノートパソコンに Windows 3.1 をインストールするのに便利だった。
＃Windows 3.1 は、DOS をインストールしてあることが前提となっている。
なので、DOS の時点で CD ROM ドライバを組み込み、CD-ROM から Win 3.1 をインストールする。
Win 95 も、インストールディスクは DOS だったので、ちょっと細工すればいけた。
ずっと昔に使っていた Linux サーバーが出てきた。
初めて Linux サーバーにする目的で購入した機械だな。まだ Slackware の時代だった。
これも、プリンタと同じく、捨てそびれて持ってきたまま保管されていたものだ。
近いうちに捨てようと思っている。
古い SCSI ケーブルとか、ADB 延長ケーブルとか、PhoneTalk で使っていた電話線ケーブルなどは、少し残して捨ててもよいだろう。
USB2.0 接続の MPEG2 取り込み機器とか出てきたけど…とりあえず置いとく。
USB1.0 の MPEG1 取り込み機器も持っていたはずだけど、それは多分すでに捨てた。
IDE CD ROM ドライブばかり４台、3.5inch フロッピードライブ１台が出てきた。
…使う日が来るとは思えないけど、今すぐ捨てるほど邪魔でもないので置いておく。
CodeWarrior とか WebBoy とか Laser5 Linux+JE とか出てきた。これは完全なネタだ。置いとく。
…本当に必要なのか？ 置いといたらまた１０年放置されるんじゃないのか？ とも思うけど、とりあえず、ね。
カセットテープの消磁機とか、クリーニングテープとか、カーオーディオのカセットテープデッキに突っ込んでステレオピンジャック入力にする機械とか、カセットテープ関連も結構発掘した。
カセットテープって、「テープヘッド」で磁気を読み取ったり書き込んだりするのだけど、ずっと使っているとこのヘッドが磁化してしまうことがあるのね。
そうすると、音が歪んで正常に再生できなくなる。
消磁機はこれを解消する機械で、ヘッドの磁化を調べたうえで逆方向の磁場をかけ、強制的に磁化を消去する。
カセットテープと同じ形なのだけど、中に基盤が入っていて、デッキに入れて使う。
クリーニングテープは、文字どおりクリーニングに使うもの。
直接的にヘッドを拭きます。クリーニング液（フロン）で水拭きした後、乾拭きする。
カーオーディオの…と書いたのは、これも消磁機のように、カセットテープの形のパッケージに基盤を収めたもの。
テープヘッドに当たる部分には、基盤側にやはりテープヘッドと同じものが入っていて、磁場を変化させられる。
つまり、テープによる磁場変化とご認識させて、カーオーディオに自由な音データを渡すことができる。
パッケージの端から、ステレオピンジャックケーブルが伸びている。
普通のカセットデッキでは、カセットを完全に機械の中に閉じ込めて蓋を閉じてしまうのだけど、カーオーディオでは運転中に入れ替えしやすいように、「押し込む」形が普通だった。
イジェクトすれば外に出てくるけど、押し込んだ時でも閉じ込められるわけではない。
機種によっては、カセットの一部が飛び出したままで、「現在カセットが入っている」と視認できるようにしてあった。
閉まっていない「穴」からステレオピンジャックケーブルを伸ばして、ポータブル CD プレイヤーなどに接続すると…
ラジカセの機能しかないカーオーディオで、CD も聞けてしまうわけだ。
高級品になると、カセット部分の「テープ送り機構」の動きを感知して、早送り・巻き戻しなどの信号をステレオピンジャックから出力できた。
ポータブル CD プレイヤー側がその信号に対応していれば、ポータブル CD プレイヤーの細かなボタンを運転中に触ることなく、操作しやすいインターフェイスで制御できてしまうわけだ。
今時カセットデッキがついたカーオーディオも少ないので、完全にロストテクノロジー。
…と思いきや、いまでも「iPhone対応」などの製品が出ているのね。
もちろん、先に書いた「早送り・巻き戻し」などの信号が、iPhone / iPod 用になっている。
一方で、カセットテープを知らない世代は直接 iPhone を突っ込んでしまうなんて話題もありました。
これ、いつか使う日が…来るとは思えないけど、置いとく。
すっごい汚いファミリーベーシックと、当時のものなのにすごい美品のファミコン本体も出てきた。
ファミベは僕が使っていたもので、変色している。ファミコンは妻のもので、ブーム当時のものだというのが信じられないほどの美品。
妻はゲーム好きなのだけど、親に許してもらえないのでこっそり遊んでいたんだって。
遊ぶ時以外は箱に密閉しておいといたから、今でも美しい。
これはもちろん置いておく。
以前に探していて見つからなかった Oh!X とかベーマガとか、こんなところに入っていたのか、というものも出てきた。
まだ全部の整理は終わってない。妻の未整理品も多いし。
しかし、引っ越し１０年目にして、やっと荷物の整理が終わりそう。
同じテーマの日記(最近の一覧)
関連ページ
別年同日の日記
申し訳ありませんが、現在意見投稿をできない状態にしています。 |