コンピュータの日記です

目次

2019-05-14 パソコンは買ったのだが…
2019-05-08 続:Minit
2019-05-04 Minit
2019-05-03 ServiceWorker と indexedDB
2019-04-26 Amazon Fire HD 10 購入
2019-04-19 micro:bit 買った
2019-04-17 新サーバー設定中
2019-03-29 村井純 誕生日(1955)
2019-03-27 電気で計算する方法
2019-03-19 ジャングルウォーズ2 発売日(1993)
2019-03-13 デヴィッド・カトラー誕生日(1942)
2019-02-25 2D-APT II 発表 (1959)
2019-02-21 ファミリーベーシック V3(1985) ディスクシステム(1986)の発売日
2019-01-07 シュガーラッシュ:オンライン
2018-12-20 メインマシンに Win 再インストール
2018-12-16 新サーバー購入
2018-12-03 ノートパソコン修理
2018-11-19 なにもしてないのにこわれました
2018-11-09 7 Billion Humans
2018-10-06 WEBページの検索順位をあげる方法(2/2)
 …同じテーマのほかの記事
パソコンは買ったのだが…  2019-05-14 17:51:09  コンピュータ

▲目次へ ⇒この記事のURL

先日、パソコン壊れた、と書いた。

7年も使っていたマシンで、以前から時々調子が悪かった。



さすがに仕事のメインマシンが壊れるのは困る。完全に壊れる前に買っておこう、と早速注文。

今使っているマシンは DELL だが、7年前は DELL はダントツにコストパフォーマンスが良かった。


しかし、今調べると DELL も悪くないが、HP もいい感じ。

実は、半年前には妻がメインマシンを買い替えていて、調べた結果 HP にしている。



僕も HP に決定。

CPU 性能は低くてもいいが、メモリは多くほしい。

仕事柄、サーバーに接続して使う端末になりがちなので、CPU 性能はそれほどいらないのだ。

しかし、Chrome で同時に何ページも開いたりするので、メモリは食う。


あと、メインストレージは SSD がいいのだけど、SSD だけではさすがに足りない。

HDD と同時搭載がいい。


DELL の安いマシンは、SSD のみでメモリ増設もできない、というものが多かった。

少し高級機種になると、SSD+HDD でメモリも増設可能、というのがある。

しかし、それは高級機種なので CPU も i7 で、高い。


これに対し、HP は CPU が i5 のまま、SSD+HDD メモリ増設が選べた。

そんなわけでそちらを選ぶ。




「令和改元セール」を銘打って安かったのも後押しした。


ところが、だ。

さんざん比較してよいマシンというのは、他にも良いと感じる人が多いようで、注文殺到だそうだ。


5月7日に注文してすぐに「在庫がなくなってしまい、出荷時期のめどが立っていない。もう少し待ってほしい」というお詫びのメールが来た。


それから2日置いた5月9日、再び「納期に関するご案内」というメールが来た。

納期が決まったか、と思って開くと、「出荷のめどが立たない」というお詫びだった。


まぁ、仕方がない。

今のマシンは調子が悪いというだけでまだ使える。気長に待とう。



…とおもっていたら、スリープして再起動したときに、回復不可能なエラーが出て止まった。

再起動したらちゃんと動いたのだけど、やっぱりこのマシン不安だ。速く新しいマシン来ないかな。




で、先ほど、またメールが来ていた。

「納期に関するご案内」…やはり「出荷のめどが立たない」だった。


前のメールから5日、注文からは1週間たったので、現在の状況を報告ということだろう。

ただ、文面は少し変わっていて、「納期が決まり次第メール連絡、また、納期が決まらないまま4営業日立った場合もメール連絡」と確約している。


人気があって商品がない、というのは仕方がない。

その際の対応として、現在の状況を逐一知らせるというのは、対応としては及第点だろう。



一応、前のメールから、まだキャンセルは可能であること、急ぎの場合は即出荷モデルも提供できることも書かれている。


僕としては、また7年くらい使ってしまうだろうから、ここで妥協して別モデルにしようとも思っていない。

今のパソコンは調子悪いとはいえ十分使えているので、気長に待つことにしよう。


▲目次へ ⇒この記事のURL

関連ページ

洗濯機壊れた【日記 19/05/17】

別年同日の日記

02年 5/13

04年 ピクミン・訂正

07年 保育園の遠足

13年 ケミクエ改良ルール・策定中

15年 ジョージ・ルーカス 誕生日(1944)

15年 ルーカスの作ったもう一つの会社


申し訳ありませんが、現在意見投稿をできない状態にしています

続:Minit  2019-05-08 18:01:10  コンピュータ

▲目次へ ⇒この記事のURL


先日、Nintendo Switch 用ゲーム Minit の話題を書いた。

ゲーム的には「初代ゼルダの伝説のような」ゲームなのだけど、クリアしてみて、これはピクミンのように「ゲーム中での最短時間を目指すものだ」と思った。


ピクミンは、「1日」の概念があるゲームで、その日の終わりにはすべてを終了して撤収する必要があった。

その状況下で、できるだけ少ない日数でクリアを目指すゲームだった。


それに対し、Minit は「1分」で強制的に作業が中断され、スタート地点に戻されてしまう。

ゲーム終了時に、スタート地点から出発した「スタート回数」が表示されるので、この回数を減らすことを考える。




まずはヒントなしで…と頑張って、冒頭に書いたスクリーンショットを得た。

12回。もっと減らすことができるポイントはわかっているのだが、それをやるのはかなり難しそうに思う。

ひとまずはこんなところだろう。


じゃぁ、答え合わせをしよう。

すでに発売されて半年たつゲームだから、そういう攻略記事もあるだろう、とネットを探してみる。


…全然見当たらない。この遊び方、誰もしていないのか?


スクリーンショットにもわかるように、下に所要時間がかかれている。

こちらの時間を競う RTA (Real Time Attack)の方が盛り上がっているようだ。




現時点では、エンディングに表示されるゲーム内時間で 6分53秒43、というのが最高記録のようだ。


RTA では、時間短縮のために自殺するのはかまわないので、回数は 14回。

動画も見てみたが、これはこれですごいのだけど、回数短縮の参考にはなりにくい。


ただ、知らない時間短縮テクニックを知ったので、これを使えばもう少し時間短縮できそうだ。


#砂漠のオアシスって、ずっと遠くにあるのだと思っていた…

 砂漠での「画面切り替え回数」が重要で、距離ではないのね。



さらに探してみると、やはり回数記録に挑んでいる人はいるようで、「10回」でのクリア方法解説を見つけた。


この解説で見る限り、上に書いた時間短縮テクニックを使っているようだ。


#そのオアシスが遠いので、そこにいる敵を倒して戻る、は不可能だっと思っていた。

 それだけでスタート1回分を使っていたのだけど、それを減らせれば大きい。



そして、この解説では「最低9回でクリアできるけど、難しいので10回を目指そう」という形で書かれている。


なかなかこういう記事が見当たらないと思ったら、もう発売から1年近いゲームなので、みんなこの段階は通り過ぎて RTA に行っているのだな。



まずは10回を目指すか…。

難しそうではあるが、独力でも12回を達成できたのだから、無理ではない気がする。




しかし、疲れたのでいったんハードモードをのんびり遊んだ。


ハードモード難しい。でも、何度死んでもいいや、というつもりでやっていれば、何とかなる。

クリアできた。



そして、「マリーモード」が現れた。

マリーは、ゲーム中にヒントをくれる幽霊の名前。マリーモードでは、主人公がこの幽霊になっている。


そして、幽霊なので死なない。自殺はできるけど、1分の時間制限はない。

そこで「最短スタート回数」を目指してプレーした。当然、1回のスタートで最後までクリアできた。


#時間制限がないとはいえ、敵との戦闘はある。

 普通は死んだらダメージ回復になるので、マリーの1回クリアはミスが許されない、という意味でもある。



ハードモードのアイテムをまだコンプリートしていないので、それをやってから10回に挑戦…かな?


▲目次へ ⇒この記事のURL

別年同日の日記

13年 ケミストリークエストの問題点

13年 ケミストリークエスト改正案

15年 八景島シーパラダイス 開業日(1993)


申し訳ありませんが、現在意見投稿をできない状態にしています

Minit  2019-05-04 18:12:17  コンピュータ

▲目次へ ⇒この記事のURL

ゴールデンウィーク前の話なのだけど、ニンテンドーポイント(ゴールド)が4月末に失効するよ、というお知らせが来た。


何か買ったりすると付くポイントで、ゴールドは1ポイント=1円で任天堂商品の購入などに使うことができる。


ちなみに、プラチナポイントというのもあるのだけど、こちらはゲーム内でバンバン配布し、ゲーム内以外ではあまり使い道がないゴミみたいなものだ。


で、失効するゴールドポイントは 150ポイントだったのだけど、せっかくなので全保有ポイントを調べたら 937ポイントあった。

500円程度のダウンロード販売のゲームを買ってもよいかも。いや、少しお金出して 1000円くらいのものを買った方が楽しめるか。




というわけで、いろいろと悩みながら「Minit」というゲームを買った。


Switch 版は昨年夏に発売になっているし、それ以前に PC 版で販売されている。

だから「今更」感のあるゲームだろう。


しかし、なかなか面白かった。

というか、一通り解き終わった後で「これからが本番だ」と気づき、今一生懸命遊んでいる。



まずはゲームの説明だ。

ネットを探せば宣伝動画などもあるので、そちらを見たほうがわかりやすいけど。



まぁ、初代ゼルダの伝説タイプのアクション RPG だと思いねぇ。

ただし、主人公は呪われていて、60秒たつと死んでしまう。


死ぬとセーブポイントから再スタートになるが、死ぬ直前までに「世界に影響を及ぼす」行為をしていた場合は、その影響は残ったままになる。



以上。シンプルだが、それだけのゲームだ。

ゼルダと同じように、画面切り替え型で広い世界を探検する。

ゼルダと同じように、剣を前に突き出して敵を倒したり、障害物を壊したりできる。


ゲーム画面は白黒のドット絵だ。ゲームボーイみたい、というとほめすぎ。

ゲームボーイは白黒4階調だったから、このゲームの画面よりももっと美しい。


しかし、この白黒画面が、ゲームを面白くするためによく考えられているのだ。




60秒で死ぬまでに、世界に影響を及ぼせばいい。

だから、ひたすらいろいろなことを試してみて、何が起きるのか探す必要がある。


洞窟を見つけて入ってみるが、真っ暗で何もわからない。

どうやらライトが必要なようだが、どこにあるのかわからない。


灯台を見つけたが、鍵がなくて入れない。冒険していたら鍵を手に入れ、灯台に上ってみたらライトが置いてあった。


世界に影響があるのは、上の例でいえば「鍵を手に入れる」「ライトを手に入れる」など。

基本的に得たアイテムは死んでもなくならないし、切り開いた道などもそのままになる。


一方で、倒した敵などは死ぬと復活する。動かせるものも、死ぬと元の位置に戻ることが多い。


何よりも一番影響があるのは、「セーブポイントに入る」ことだ。

基本的には、ベッドが用意された家がセーブポイントになっていて、死んだときは「最後に入った」セーブポイントに復活する。


世界には何カ所かのセーブポイントがあり、そこを中継地点とすることで広い世界をくまなく冒険することができる。



このゲームの中にはパズルが多く、障害物の動かし方などに失敗すると詰んでしまうことがある。

また、袋小路の行き止まりもあり、そういう場所にはアイテムが置かれているのだけど、アイテムを取った後脱出することができない場合がる。


まぁ、時間切れになれば死んでセーブポイントに戻るのだけど、B ボタンを押せばいつでも自殺できる。

この「自殺」は、遊び方によっては非常に重要なポイントになる。…ようだ。




さて、先に「白黒画面がゲームを面白くする」と書いたのだけど、白黒でも古臭い感じはしない。

アニメーションがやたらと滑らかだからだ。ファミコンやゲームボーイの時代なら、こんな滑らかなアニメーションは作れなかった。


しかし、色がない、ドットも荒いというのは、情報が極端に少ない。

…ここが重要だ。世界を冒険するときに、初めて見たものの意味が分からないのだ。


もしくは、意味が分からないがゆえに、「そこにあるものが見えていない」ともいえる。

意味が分かるのは、それが重要アイテムだと認識されて以降だ。


つまり、このゲームは世界に影響を及ぼすためにアイテムを捜し歩くゲームなのに、そのアイテムは入手するまで「見えていても気づかない」ことが多い。


なんて巧妙な隠し方だろう。

ちゃんとヒントを見せているにも関わらず、それがヒントだったとわかるのは謎を解いた後なのだ。



「こんな隠し方、わかるわけないよ! 不条理だ!」と怒りたくなるのはクソゲーの条件だし、そう怒りたくなる場所が随所にある。

しかし、あとで見直してみると、明らかにわかるように置いてあるのだ。気づかなかった自分が悪い、と納得するより他にあるまい。


ちなみに、もし気づかなかったとしても、あまり問題はない。

必須アイテムは比較的楽に入手できるようになっていて、巧妙に隠されているのはコンプリートを楽しむオマケ要素だから。




ところで、このゲームのとあるところに、謎のメッセージが置かれている。


???

???

???


と、ハテナマークが並んでいるだけなのだ。


一度クリアした後、続きを遊び始めた。

アイテムのコンプリート要素があるので、ゲームをクリアした後でも、そのセーブデータで遊び続けることができる。


そこで気づいた。一番上の ??? に、「ノーマル:243」って入っている。


ん? これはなんだ? その時は気にせず遊んでいた。

そして、アイテムコンプリートが難しいので、気を取り直してもう一度最初から遊んでみた。



最初から遊びなおした理由は、設定画面の中に「スピードラン」という項目があるからだ。

初期設定では OFF になっているが、ON にしてゲームを始めると、ゲーム開始からの1/100秒単位の通算時間カウントが画面上に表示される。


つまり、これはやるべきことを効率よくやって、タイムアタックをするゲームなのだな、と認識したのだ。



2回目は、謎を全部知っているので35分ほどで終了することができた。

(ちなみに、最初のプレイは1日1~2時間で1週間程度、通算では5~6時間くらいかかっていると思う)


で、そのあと気づいた。??? に書かれていた 243 が、44 に減っている。

この 44 というのは、クリアまでに「死んだ回数」だ。



ここでやっと気づいた。

このゲーム、スピードランもできるけどそれはオマケ要素で、作者が一番やってほしいのは「少ない死に回数でクリア」なんだ。




現在死に回数を減らすべく、冒険の手順を組み立てている。

1分間にできるだけ多くのことを詰め込まなくてはならない。


最初の一分は何度もやったので、もう動きが確定している。

先ほど書いた例の「灯台に上ってライトを取る」ところまでは、最初の1分で可能だ。


ちなみに、初回プレイではそこまでに10回以上は死んでいたと思う。


それ以降は、大まかにやることは決まっているのだけど、まだ無駄のない動きというのがわかっていない。

現時点でのベストスコアは21回だけど、まだ無駄が多いので20回を切るのは余裕だろう。


最終的にどのくらいまで切り詰められるのかはまだ見えていない。



そして思った。

この作業、ピクミン1の楽しかった部分だ


やるべきことはわかっている。

でも、手順の一部には前後の入れ替えが可能な部分がある。


そうした部分を調整しながら、区切られた時間を最大限に使う方法を考える。

小さなパズルを解き、その答えを大きなパズルの一部としながら、大きなパズルを完成させていく。

状況次第では、小さなパズルの答えを一度壊し、再度組みなおすことで大きなパズルがより完成に近づく場合もある。


ピクミンと違い、途中までできたところでセーブデータをコピーして保存して次に挑む、ということができない。

最後まで通しでやらないといけない「一発勝負」なので、解き方は再現性が高い、偶発性を排除した方法であるのが望ましい。


一方で、ピクミンと違い、全部通してやっても30分以内だ。

気軽にチャレンジしやすい。何度も繰り返すことで見えてくる攻略もあるだろう。




実はこのゲーム、ハードモードもあるのだけど、まだハードモードはクリアしていない。

ハードモードは、名前の通りハードだ。難しい。

ノーマルモードの徹底攻略と、ハードモードのクリアのどちらを優先すべきかわからないのだけど、とりあえず「楽しい方」を遊んでいる。



▲目次へ ⇒この記事のURL

別年同日の日記

13年 記事の更新


申し訳ありませんが、現在意見投稿をできない状態にしています

ServiceWorker と indexedDB  2019-05-03 12:36:56  コンピュータ

▲目次へ ⇒この記事のURL

「ゴールデンウィーク明けにはリリースしたいので、その前までにお願いね」


と言われていたプログラム改良があった。

その改良は、ちゃんと四月半ばまでに仕上げた。


WEB ブラウザ側で動く Javascript のプログラムだったのだけど、同時にサーバー側も変更することになっていた。

サーバー変更は僕の仕事ではなかったのだけど、そちらが間に合っていない。


急遽、Javascript 側で何とかできないかと、ゴールデンウィーク直前に ねじ込まれた。




目的は、URL の一部隠蔽だ。

ブラウザ側プログラムの改良により、画面遷移が一段階へり、目的画面の URL が変わることになった。

この URL にはセッション情報が含まれており、見えているのが好ましくない。


そこで、セッション情報を URL に入れるのではなく、POST にするか、Cookie にするなどして、消すことになっていた。

つまり、これらはサーバー側の改良だ。


それができなくなったので、Javascript 側でどうにかならないか、というのが、追加の依頼だった。

セッション情報はややこしい文字列になっているので、長い時間表示されているのでなければ、一瞬なら出てもよいという。


つまり、セッション情報付きの URL でアクセスしてから、取得したページの Javascript の中ですぐに URL を変更し、消せればいいということだ。


ただし、該当ページは都合上、時々リロードする場合がある。

セッション情報なしではサーバーにアクセスできないので、リロードする際にはすぐに URL を元に戻したい。




URL を変更するのは簡単だ。history.replaceState 関数を使うと、現在アクセス中として表示されている URL を変更することができる。

いわゆる ajax …画面遷移を伴わないサーバーアクセスを行うようなプログラムで多用されているテクニックだ。


だから、セッション情報がない URL にすることはできる。

この時に、本来の URL を変数に保存しておいて、リロードの際に元に戻せればいいだろう。



しかし、javascript に「リロードイベント」というのは存在しない。


#イベントとは、「何かが起きた」とプログラムが知ることができる、概念上の存在。

 Javascript では、特定のイベントに対してプログラムを紐づけることができ、紐づいたプログラムは、イベントが起きると自動的に実行される。

 これにより、イベントが生じたらプログラムを動かす、ということが可能になっている。



リロードされたかどうかを知る方法はあるのだが、それはリロードされた「あと」のページで検知できるだけだ。


そして、リロードの際には表示している URL にアクセスが行くので、そのままではセッション情報がないためにサーバーから拒否される。

リロード「あと」のページの表示自体が行えない状態で、リロードに伴う不都合をこの方法で解消することはできない。



「ページが終了した」というイベントはある。unload イベントだ。

しかし、Javascript プログラムの寿命は、そのページが終了するまでだ。


そのため、unload イベントにプログラムをセットしておいても、実行されることはない。



実行されないんじゃ意味ないじゃん、ってことで、beforeunload というイベントもある。

「unload の直前」というイベントだ。


よく、「ページを離れてもいいですか?」というダイアログが表示されるのは、このイベントの時に動くプログラムによるものだ。



このイベントは、次にアクセスする URL が決定し、新しいページの取得準備が整うと呼び出される。

つまり、このイベントの中で URL を書き換えても、すでに URL は決定していて意味がない。


このイベントでできることは、新しいページへの移行を中断し、今のページに居続けるかどうかをユーザーに問いかける、ということのみだ。




そんなわけで、ブラウザ側の Javascript で解決するのは無理とわかった。


でも、まだ最後の望みがあった。

一般に「ブラウザ側の Javascript」というのは、WEB ページに付随するものだ。


しかし、最近のブラウザには、WEB ページではなく「ブラウザに」Javascript を登録し、動かす方法があるのだ。



ServiceWorker という。


Chrome/FireFox では早くから実装され、便利なので使いたいプログラマも多かったのだけど、Safari ではなかなか実装されなくて使いどころが限られていた。


昨年、やっと Safari も対応したので、使われる局面が増えてきている。


これを使うと、WEB ページがサーバーに問い合わせた瞬間に、そのリクエストを横取りして、Javascript がサーバーの「ふりをして」返事を返したりできる。


だから、オフラインなのにキャッシュしておいたデータを渡したり、逆にサーバーにデータを送ろうとしたときにキャッシュしておいて、あとでオンラインになった時にこっそり送信したりできる。


Google Docs がオフラインでも使えるのはこの仕組みを使っているからだ。


Android では、この仕組みを使って WEB ページを「アプリ化」することもできる。

WEB ページに行くと「このページをインストールしますか?」と促され、インストールを選ぶとホーム画面にアイコンが現れる。


このアイコンをタップすれば、いつでも WEB ページが提供する機能を使える。

Google Docs の例と同じように、適切に処理されていれば、オフラインでだって使える。



Service Worker の利用例は、多くは「WEB を オフラインでも使えるようにする」のと、それをさらに拡張した「アプリ化」だ。

だけど、先に書いたように、サーバーへのリクエストを横取りして、いろいろなことができる。

キャッシュデータを渡してオフラインでも動くようにする、というのは代表的な応用例にすぎない。



これなら、リロードの問題を解決できそうに思えた。

…一筋縄ではいかなかったのだけど、実際解決できた。




基本戦略はこうだ。


・WEB ページ側で、history.replaceState を使って URL を一部削除。

 同時に、削除前の URL を ServiceWorker に渡して、データ保持。


・サーバーへのアクセスが生じた際、それが URL を一部削除したものだと判明したら、

 保持していた本来の URL にアクセスし、そのデータを WEB ページ側に渡す。



実験過程を端折るが、実際にこの流れを作ったらうまく動かなかった。

WEB ページ側で動いている Javascript は、内部でセッションデータを使用していたのだ。

(僕は途中から参加して改良してきただけなので、そうした部分があるのを知らなかった)


だから、サーバーアクセスの際の流れを少し変えることにした。


・サーバーへのアクセスが生じた際、それが URL を一部削除したものだと判明したら、

 保持していた本来の URL にリダイレクトする指示を作り出し、WEB ページ側に渡す。


リダイレクトが挟まるので、WEB ページ側としては少し動作が遅くなってしまう。

しかし、一度本来の URL に戻ってからリロードすることになるので、内部で動作するプログラムでも

URL に入れたセッションデータを使えることになり、問題は出なくなる。



さて、実際に作る上では、いくつか問題があった。

一番重要なのが、Javascript の生存期間だ。


WEB ページでは、そのページが存在する間、Javascript が生存する。

変数などもこの間は保持されるので、データ保持も変数に入れればよい。


しかし、ServiceWorker では、生存期間の考え方が二つあるのだ。



先に書いたように、ServiceWorker はブラウザ側で動き、WEB ページが閉じられても残り続ける。

しかし、それは「残っている」だけで、生きているわけではない。


じつは、必要な時に動作し、動作を終わるとすぐに終了してしまうのだ。

「データを渡す」という動作があったとしたら、その動作が終わった瞬間に終了し、変数は消える。


その後、「サーバーアクセス」という動作があり、動き始めたときには変数は存在していない。


だから、変数ではない方法でデータを保持しないといけない。




ServiceWorker は非常に強力な仕組みなので、悪さができないように厳しい制限が課されている。


データ保持方法としては、indexedDB しか使えない。

古くから知られるデータ保持方法には、Cookie や webStorage があるが、それらよりも新しい仕組みだ。


まぁ、それしか使えないのであれば、それを使おう。


…これが、イベントで動作する仕組みになっていて使いにくい。

DB に接続する、という指示を出すと、少し後で「接続成功」というイベントが起きる。

だから、接続成功イベントに、接続後のプログラムを登録しておく。


接続後には、アクセスしたい対象を指定してから「データ取り出し」を指示する。

しかし、データはすぐ取り出されるわけではない。少し後で「取り出し成功」イベントが起きる。


だから、ここでもイベントに対してプログラムを登録しておく必要がある。

非常に面倒くさい。

しかし、他に方法はないのでその方法でプログラムを組む。



ところが、もう一つ問題があるのだ。

ServiceWorker 自体は、こうしたイベントによって動くモデルではないのだ。


いや、先に書いたように「サーバーへのアクセスが生じた」などのイベントはある。

でも、Javascript ってとにかく「何かしたら後で呼び出して」という書き方が多くて、ここ数年で新しい書き方が取り入れたのだ。


そして、ServiceWorker は、基本的にその書き方で書かれないといけないようになっている。




この書き方は Promise というやつで…


この概念の歴史から入ろうと思ったが、無駄に長いのでやめた。

同時に、概念だけ説明するのも同じくらい長くなるのでやめた。


ともかく、概念自体は古いとはいえ、10年たっていないのではないかな。

Javascript の言語仕様に取り入れられたのは、2015年なので、4年程度しかたっていない。


しかし、便利なので、これまでイベントモデルで作られていた Javascript が、最近は Promise モデルで機能追加されるようになってきている。

上に書いたが、ちゃんと理解していないと混ぜて使えない。



ちなみに、Promise の概念の前に Deferred があり、こちらのことは以前に書いたことがある

微妙に違うとはいえ、概念的に慣れていたのですぐに…でもないけど、1日程度で理解できた。





そんなわけで、同じことで悩んでいる人にとっての「答え」を示そう。


ServiceWorker では、fetch (URL アクセス)イベントに対して、最終的な「返事」を event.respondWith として返せばよい。

ここで、返す内容は Promise でなくてはならない。


Promise は、resolve を引数とする関数として定義される。

resolve はコールバック関数であり、Promise の処理終了時には、resolve を呼び出してやらなくてはならない。


この時、resolve には、「結果」を引数として渡す。

通常の関数における、return と同じような感じで、何が結果になるのかはその時の処理内容による。


respondWith は、URL アクセスに対する答えを返す関数なので、答えは http の Response となる。

これは Response クラスとして定義でき、リダイレクトしたいなら headers の Location に URL を渡せばよい。

(http と同じだ)



以上の「きまりごと」さえ守れば、あとはどんな書き方をしようとも自由だ。

関数内部で indexedDB のイベント呼び出しをたくさん定義しても構わない。


僕が仕事で必要だった関数の場合、次のようになった。


self.addEventListener('fetch',function(event){
  let url = event.request.url;

  let param = url.match(/targetDirectory\/([0-9]+)(\?session=)?/);
  if(!event.isReload || !param || param[2])return;

  event.respondWith(new Promise(function(resolve){
    let openReq = indexedDB.open('targetDB');
    openReq.onsuccess = function(event){
      let db = event.target.result;
      let trans = db.transaction('fullURL','readonly');
      let store = trans.objectStore('fullURL');
      let getReq = store.get(param[1]);
      db.close();
      getReq.onsuccess = function(event){
        let redirectResponse = new Response('',{
          status: 302,
          statusText: 'Found',
          headers: {
            Location: event.target.result.url
          }
        });
        resolve(redirectResponse);
      }
    }
  }));
});


説明しておくと、/targetDirectory/123?session=**** というような URL が隠蔽対象だ。


リロードにより fetch イベントが起きているときは、すでに隠蔽されて ?session= 以降はなくなっている。

しかし、初回アクセス時や、リダイレクト直後は ?session= 以降もついているので、判別して処理を変える必要がある。


そして、123 の部分の数値はページの分類を示していて、ブラウザの複数のタブで開かれる可能性がある。

それぞれでリロードしたときに混乱しないように、123 を DB のキーとして、元の URL を格納してある。


#格納部分のプログラムは別途必要。そちらは Promise と無関係に書けるので、それほど難しくない。



…というわけで、URL を検査して、隠蔽されていない場合はそのままアクセスを通す。

隠蔽されている場合は、123 にあたる部分をキーとして DB を検索し、得られた URL へのリダイレクトを生成する。



ちなみに、僕の要件ではリダイレクトが必要だったが、URL を差し替えてそのままサーバーにアクセスしたい、という場合もあるだろう。


実はそちらの方がプログラムは簡単で、redirectResponse を生成せずに、


resolve(fetch(event.target.result.url));


としてしまえばよい。




ここで重要なのは、


・fetch イベントに対する反応は、すぐに返さないといけない。

・event.respondWith が呼び出されれば、そこで帰ってくる反応を待つ。

・呼び出されなければ、本来の URL に対してアクセスを行う。


ということだろう。


respondWith は「結果を返す関数」ではなく、「結果を返すと約束する関数」だ。

結果を返すものだと思って、結果が出てから呼び出そうとすると、「fetch に対して respondWith が返されなかった」ことになり、本来のサーバーにアクセスが行ってしまう。


そして、結果を返すと約束するのだから、返すのは Promise (約束)だ。

Promise は、最終的に resolve として渡される関数を呼び出しさえすれば、その内部でどれほどの時間がかかっても構わない。


だから、時間がかかる indexedDB の処理は、この Promise 内部で行うようにする。




…ただこれだけのことだ。

プログラム例を示したら、なんてことのない、当たり前に見えるコードだろう。


けど、こういう例がネットを探してもなかなか見つからないんだ。

ServiceWorker というと、「キャッシュを使ってオフラインでも動作するようにしましょう」ってお決まりのパターンばかりで。


#ちょっと気が利いた例では、簡単な文字列を「WEB ページ」として生成して返したりする実験をしていた。

 しかし、indexedDB を使って何かのデータを返すような処理を見つけることはできなかった。


この日記が、同じような処理をしようとしている人の助けになれば幸いである。



▲目次へ ⇒この記事のURL

関連ページ

Programming Tips

別年同日の日記

02年 5/3

04年 しばらく日記を書いていませんでした

04年 知恵の輪

04年 天然温泉

04年 ハードディスクの温度

04年 ピクミン2

04年 携帯のことも書いとこう

05年 よきライバル?

06年 ゴールデンウィーク


申し訳ありませんが、現在意見投稿をできない状態にしています

Amazon Fire HD 10 購入  2019-04-26 18:29:13  コンピュータ 歯車

▲目次へ ⇒この記事のURL

Kindle Fire だと思っていたけど、いつのまにか Kindle は外れて、ただの Fire に名前変わっていたのね。



表題通り、Fire HD 10 を購入した。

少し前にセールで値下げしていて、1万980円だった。


実は、我が家では未だに Nexus7 (2012) が現役で稼働していた。


発売時点で、すでに2年前のハード、と言われていたマシン。

でも、当時としては悪くない性能で、何よりもとても安かった。


その後、ハードウェアが高速化すれば、そのうえで動作するアプリも、高速処理を前提としたものになる。

今となっては遅すぎてストレスのたまるマシンだったが、朝の Radiko 専用端末としては十分に使えていた。



我が家では、朝はテレビを見ない。子供たちがテレビを見入ってしまうと朝ごはん食べるの遅くなるから。

そこで以前からラジオを付けていたのだが、1年前にキッザニアに行ったときから、子供たちが J-wave に興味を持つようになった。


しかし、鎌倉では J-wave の電波は入りにくい。

自然と Radiko を使用するようになり、Nexus7 は Radiko 専用機となっていた。




しかし、その Radiko も、少し前にアプリがバージョンアップしたのだ。

…いや、この新アプリは、対応する OS バージョンの問題で、Nexus7 には入らない。

だから、アプリが重くなるようなことはない。


しかし、動作が重くなったのだ。

Radiko アプリは、多くの情報をネットワークから取得する。

どうも、アプリ更新と同時に、その元データの量が増えたのか、動作が遅くなってしまったのだ。



これはさすがに買い替え時だな、と思った。それなら、以前から興味あったから Fire HD 10 が欲しいな、と思っていた。

しかし、事実上 Radiko だけ聞ければいいマシンに1万5千円かぁ…と躊躇していたら、ちょうどセールが来た。


そんなわけで、買ってしまったのだ。




というわけで、前振りが長かったけど使用レポート。


断っておくが、Fire HD 10 は、2017 年に発売されたマシンだ。

それも、Nexus7 と同じように、「安いマシン」を目指して作られているので、発売時点で2年前の性能だった。


だから、1万円と激安ではあるが、その性能は 2015年の最新スペックくらいだと思っていい。

そして、2017年に発売されたものなので、今更使用レポートを書いたところで、誰かの参考になるとも思えない。


あと、Fire HD の「前世代機」は、2015年発売だった。購入したのは 2017年発売モデルで、今年は 2019年だ。

セールで安くなっているのも在庫処分の予感がするし、性能が良い機種が欲しい人は慌てて買わないことをお勧めする。


その一方で、新機種が出れば値段は上がるだろう。

Amazon では定期的にセールを行っているし、1万円で使い勝手の悪くない機械が欲しいのであれば、次のタイミングを狙うといいかもしれない。



なお、我が家にはすでに関連商品として Fire TV Stick がある。

ずっと第1世代を使っていたが、先日やはりセールで安かったタイミングで第2世代に乗り換えた。


数年来 Amazon prime 会員で、多くのビデオが見放題なので、子供とアニメを見たりしている。

僕は主夫を標榜しているので家事もほとんどやっているが、家事をしながらスマホでもアニメを見ている。


#別にアニメ好きなわけではない。むしろ、子供が生まれる前はアニメ嫌いだった。

 しかし、家事の合間に見るにはちょうど良い長さなのでいろいろなアニメを見るうち、すっかりそういう生活になってしまった。




購入する際には、カバーを一緒に注文した。

10インチタブレットは大きいので、家事の合間にビデオを見ようと思ったら、なにか「立てる」手段が必要だ。


スマホで観ていた時には、小さな台を使っていたが、10インチではとても使えないだろう。


純正カバーは、縦にも横にも立てられるスタンドとしての機能がついている。しかしおよそ5千円もする。

本体が1万円なのに、ちょっと高すぎる。


しかも、この「立てる」機能が微妙で、立てる面が滑りやすいとうまくたたない…というレビューも散見する。


サードパーティ製で、1500円のカバーがあって評判が良い。

横置きでしか立てられない代わりに、2通りの角度に使える。


こちらを購入。




商品が届いて驚いたのは、入っているのが「箱」ではなく、しっかりした素材の「紙袋」だったことだ。


もう一度しまって置いておく、というようなことは考慮されていない、破いて開ける紙袋。

使い捨て、と言うと語弊があるが、しばらく使い倒したら買い替える、そういう商品だということだろう。


元々、購入時にそういうつもりだった。だから、今回画面保護フィルムなどは買っていない。

カバーはあるので鞄に入れて持ち運んでも大丈夫だろうし、そもそもそれほど家から持ち出さないつもりだから。



そもそも、Fire HD 10 には、SIM が刺さらない。

モバイルでの電波は使用できず、WiFi があるところでしか使えない。


今まではスマホの Prime Video アプリを使っていたが、これも WiFi が前提だ。

一応モバイルの電波でも見られるが、WiFi のある場所でビデオをダウンロードして、外で観たいときはそのデータを見る、という作法になっている。


そうした性格のものなので、Fire HD 10 には GPS も、地磁気センサーもついていない。

持ち歩くようには考えていないのだ。



一方で、Amazon がこれから力を入れたい、Alexa が使用できる。

(英語版は以前から使えたそうだが、日本語版は最近対応したばかりだ)


こちらも WiFi を前提として、ほぼすべての処理をネットワーク越しに行うものだ。



タブレットだけど、モバイルではなく、家の中で使うもの。

Fire HD 10 は、そうした設計のマシンだ。

ここを見誤ると、1万円でも「高い買い物」となってしまうだろう。




さらに言えば、Amazon Prime などの会員になっていて、Amazon のサービスを使いたい、という人向けに作られている。


Amazon の各種サービスのアプリはインストール済みだが、それだけでなく、ホーム画面で直接「おすすめのビデオ」「おすすめの本」などが表示されるようになっている。


さっき見ていた続きもすぐに見始められるし、今までの視聴履歴からのおすすめも出る。

それらをタップすれば、適切なアプリが起動する。だから、アプリアイコンは並んでいるが、あまり使う機会はない。


逆に「安いタブレット」として購入したいだけで、Amazon のサービス会員になっていない人にとっては、無意味なオススメばかりされる使いにくい端末だろう。



「ホーム画面」と書いたが、一応 Android 端末だ。

Android 端末では、ホーム画面もアプリの1つにすぎないため、入れ替えれば普通の Android として使用できそうに思う。


…が、そうした夢は見ない方がいい。


Kindle Fire HD には、Google Play store アプリがインストールされていない。

だから、普通の Android アプリはインストールできない。


一応、Amazon App Store からのインストールはできるし、有名な Android アプリなどはこちらにも結構登録されている。

しかし、バージョンが古かったり、機能限定版だったりすることも多い。Android として使おうとは思わない方がいい。



それでも使いたいときは…実のところ、Google Play アプリをインストールすることは可能なのだ。

Amazon の WEB ブラウザである「Silk」が入っていて、探せば WEB からアプリをダウンロードし、インストールできる。



しかし、そこまでやっても、Android 5.1 相当で、しかもこれはカーネル(OS の中核部分)が入っている、というだけの話だ。

(現在、Android の最新バージョンは 9 だ。5.1 は、Nexus 7 の時代の OS だ)



Android なら当たり前に入っているはずの周辺サービスが入っていない。

そうしたサービスを前提とするソフトは、たとえインストールできたとしても、動かない。



Fire HD 10 は、あくまでも「Fire OS」のタブレットであって、Android ではない、と思っていた方がよいだろう。




とはいえ、購入して最初にやったのは、Google Play と Chrome を導入することだった。


最初に書いた通り、Radiko を使いたかったのだが、Amazon App Store で配布されている Radiko は、お話にならないほどバージョンが古く、機能が限定されるのだ。



これは、無事入った。Android 端末としての期待はしないとしても、「使えないことはない」というのは安心感をもたらす。



次にやってみたのは、Prime Video の視聴だったが…

これは、ちょっといただけない。


画面は大きくて非常にきれいだし、内蔵スピーカーの音もよい。この点文句は何もない。


しかし、僕は家事をしながら見たいのだ。家族が寝ている時間に見ることもあるため、Bluetooth イヤホンは必須なのだ。


その Bluetooth に、非常に雑音が乗る。


実は、これは古い Android には普通にあったバグで、どうも配信用に圧縮された音声を展開し、Bluetooth 通信のために再度別の形式に圧縮する過程でノイズが乗ってしまうのだ。

そのため、Bluetooth オーディオを使用しなければ問題はない。


これが、静かな時ほど大きなノイズが乗る。

「常に軽いノイズがあるが、静かだと目立つ」というようなヒスノイズとも違う。

明らかに、静かな時だけノイズが乗るのだ。


#静かな時と書いたけど、より厳密には「音の周波数成分が単純な時」。

 オルゴール曲が流れるようなシーンでもノイズは大きくなる。

 圧縮アルゴリズムを知っていると、バグの原因がなんとなくわかる感じ。



このノイズ、そういうものだと我慢できないこともないが、非常に残念なレベルだ。

Android のベースバージョンが古いことが、こんなところで足枷になっている。



次に、Prime で読める本を読んでみる。

そういうサービスがあるのは知っていたし、実は Kindle Paper White も持っているのだけど、あまり活用していなかった。


それが、Fire OS のホーム画面「おすすめ」機能で、無料で興味がありそうなものを勧めてくれるのがちょっとうれしい。



ここで、同時購入したカバーについて言及。

表紙を開いたときに、3つ折りで「三角柱」を作ってスタンドにできるものなのだけど、その柱を下に持ってくるか、上に持ってくるかで角度を2段階に調整できる。


(タブレット本体は、反転した形になる。ボリュームや電源などのボタン類は、縦置きの時に一番上の辺に集中しているので、横置きではどちら向きにおいても問題ない)


この2段階が、角度を「立てた」時にはビデオ視聴にちょうどいいし、「寝かせた」時には、本を読むのにちょうどいい。


三角柱を作った際には、カバー内に内蔵した磁石がうまくくっついて、それなりの力に耐えてくれるのもよくできている。


レビューでは純正カバーより評判が良い感じなのだけど、納得した。




漫画を読んだのだが、横画面にして、2ページ見開きでも十分に文字が読める。

もちろん、細かな部分などを見たければ拡大もできる。


普段スマホで漫画を読んでいるが、縦画面で1ページ表示でも、文字を読むためには拡大しないといけない感じ。

読書端末としてはかなり使いやすい。



気をよくして、「マンガ Park」アプリをインストールしてみた。

白泉社の漫画が1日に8話づつ無料で読めるアプリで、普段使わせてもらっている。


…残念ながら、このアプリは縦画面専用だった。見開き表示はできない。

しかし、拡大しないでも文字が読めるのはありがたい。




Alexa を試してみる。


google の音声認識である「OK google」は、スマホで使用する場合はまず何らかの方法でスリープ解除してからでないと使えない。

(場合が多い。スマホにもよるだろうが、実際この程度で解除できてしまうとセキュリティ問題があるだろう)



スマートスピーカーは当然音声だけで操作できるが、あれは「家庭内」に使用できる場所を限定していて、セキュリティ問題が出にくいからできるのだ。


そして、Fire HD 10 の Alexa は、スリープしている状態からでも使用できる。

こちらも、持ち歩かないことを前提にしているから、ということなのだと思う。


カバーを閉じていて画面が見えないときは、本当にスマートスピーカーと変わらない。




せっかく Radiko アプリを入れたのだけど、「アレクサ、J-wave 再生して」と言えば、J-wave を聞かせてくれた。


Alexa で機能追加するアプリのことを「スキル」と呼ぶのだけど、Radiko はスキルとしても提供されている。

初めて機能を使おうとしたときに、スキルを使ってもよいか聞かれるので承認すればいい。



この Radiko スキル、実はレビューではかなり評判が悪い。

「J-wave 再生して」と言っても、わざわざ「J-wave を再生しますか?」と聞き返してきて、「はい」と答えないと再生してくれない。

再生中にボリュームを変えようとすると終了してしまう、Radiko の機能のすべて(タイムフリーなど)を使うことはできない、などなど。


しかし、単に現在の放送を聞きたいだけ、というのであれば、使い勝手は悪くなかった。


特に、先に書いたように朝の食事の際に聞きたいので、配膳しながら指示を出せるのは便利だった。

しばらく使ってみて、不便な点があればアプリを使うようにしよう。

 



Alexa に何か頼む、というのはなかなか面白いようで、子供が「天気教えて」とか「今何時?」とか、いろいろやってみている。

しかし、今のところうまく認識されない、と笑っているレベルで、実用にはなっていない。


そもそも、家族がいる部屋の中で「アレクサ!」って急に言い出すのは恥ずかしい。

この機能は、1人暮らしの人には評判が良いようだが、我が家での使いどころを見つけるのはもう少し時間がかかりそうだ。



▲目次へ ⇒この記事のURL

同じテーマの日記(最近の一覧)

歯車

別年同日の日記

15年 ピューロランドで誕生日

18年 ST-V事業のテコ入れ


申し訳ありませんが、現在意見投稿をできない状態にしています

micro:bit 買った  2019-04-19 17:46:17  コンピュータ 歯車

▲目次へ ⇒この記事のURL

小6になった長女が、学校で蛍光ペンを使うらしい。


5色セットで色の指定まである。そこまで細かいと、店に行っても置てあるとは限らんぞ…

と思い、Amazon で買うことにした。


そうしたら、一番よさげなものが「あわせ買い対象商品」で、2000円分買わないといけない。

蛍光ペンは 300円なのに。



と、前振りが長いのだが、ちょうど 2000円で買える子供用コンピューター、「micro:bit」を買った。

以前から興味はあったけど、遊ぶ暇がないから買ってなかったやつ。




micro:bit に関しては、発売前に少し触れている

もっとも、発売前は BBC Micro Bit という名前だった。


イギリスでは、1981年に、国営放送である BBC が BBC Micro というコンピューターを発売している。

その「後継」というか「再来」というような位置づけだ。


子供全員が持てるように、安いけれど十分な機能を備え、単体で動くコンピューターとして作られている。




いろいろ説明しようと思ったのだけど、書いてみたら長くなったのでやめておこう…

先行する「小さなコンピューター」である、Arduino / Raspberry Pi / Ichigo JAM と比較して、それぞれの特徴を書こうと思ったのだ。


特に Raspberry Pi 。

micro:bit と同じ、イギリス生まれの子供向けコンピューターだ。


これとの衝突は、絶対避けなくてはならない。

1981年の BBC Micro では、商売が「衝突」したイギリス国内の企業から、「国が民間企業の邪魔をするのは違法行為だ」と訴えられたのだ。



しかし、使ってみてわかった。micro:bit は、Raspberry Pi とは違う市場を見つけ出し、見事にすみ分けている。

それどころか、「併用すれば楽しさが広がる」ような世界を作り出している。



Raspberry Pi は小さなデスクトップパソコンで、micro:bit は「プログラムが楽しい周辺機器」なのだ。

だから併用しても構わないし、守備範囲が違う。


残りの二つ、Arduino と Ichigo JAM については詳しく書かないが、ここら辺とも違う環境になっている。




話を micro:bit に戻すと、「思ったより楽しい」。

もっと早く買えばよかった。



単体でプログラムできる環境、というより、「スマホのセンサー部分だけ取り出した」という感じだ。

これは、先に書いた3機種にはない、micro:bit だけの特徴だ。



加速度センサー、地磁気センサー、明るさセンサー、接触センサーなどを備えている。

簡単だが、表示デバイスもあるし、2つのボタンもある。



ボタンが2つしかないので、ゲームを作るのにはちょっと辛い。

上下左右を加速度センサーによる傾き検知で行う、という作法で作られるものが多いようだ。

しかし、この方法は操作性悪い。


従来の方法論にとらわれない、新しい発想が必要なのだろうな…

スマホゲームとかでも、画面上のボタンを推させるような方法で既存ゲームを真似するのは使いにくいだけ、というのと同じ。




とりあえず、まだ暇がなくてあまりいじっていない。

5x5 しかない表示画面でもでもテトリスくらいは作れそうだ、と思ったら、すでにテトリスは作っている人がいた。


パックマンも。…作れそうなゲームは、すでに軒並み作られているのかな。


まぁ、人が作っているとしても、練習で自分でも作ってみればよいのだけど。



▲目次へ ⇒この記事のURL

同じテーマの日記(最近の一覧)

歯車

別年同日の日記

02年 4/19

05年 網戸ついた

06年 大玉

17年 地図の日


申し訳ありませんが、現在意見投稿をできない状態にしています

新サーバー設定中  2019-04-17 18:14:43  コンピュータ

▲目次へ ⇒この記事のURL

去年の9月に、社内実験用サーバーを新しくしたい、と書いた。


とっくにサポート期間を過ぎている、CentOS5 だったのだ。

さすがにサポートが切れているのはまずいので、新しくしたかった。


しかし、やっとサーバーを購入したのは、12月だった



物理マシンへの OS インストールに紆余曲折があった。

最近の流行は、サーバーでも Ubuntu のようなので、Ubuntu server を使ってみるつもりだった。


…しかしこれは、「デスクトップで Ubuntu に慣れた人が多いから」流行しているだけだ、と思った。

サーバー用途向けに作ってある、としているパッケージでも、サーバーとしては足りないものが多いのだ。


「使えなくはない」が、「満足して使える」ものではない。

結局 CentOS で行くことにした


#サーバー初心者であれば、Ubuntu は悪い選択ではない。

 できることが限られる、というのは、みんな横並びなので情報を得やすい、ということでもある。



…その後がなかなか進まなかった。

バーチャルマシンとしても CentOS をインストールして、古い環境と同じように整備する。


これが、古い環境が古すぎて、ただファイルを持ってくれば終わり、とはいかない。


旧マシンでは djbdns を使っていたが、nsd + unbound に変えることにする。


php のバージョンが上がり、この WEB サイトを表示していたプログラムが動かなくなった。


このサイトは、僕が設計した独自の CMS で動いている。

古いものなので mysql 関数群を使用していたが、今後の php ではこの関数群はサポートされない。


mysql と比較的動作をそろえたまま、オブジェクト対応になった mysqli 関数群がある。

動作が近い、とはいえ結構違うものなので、簡単には置き換えられない。


とはいえ、置き換えるのに一番早そうな設計指針をたて、ちまちまと改良した。

多くの個所は機械作業で修正でき、一部は大幅な見直しが必要になったが乗り切った。


ついでにこの時新機能も追加している。


公開用サーバーは比較的新しく、改良ソースでも動作する。

なので、完成したらさっさと公開用サーバーのプログラムも入れ替えた。


当初はおかしな部分もあったが、すでに安定動作している。




その後は、年度末進行もあってサーバーの移行も止まっていたが、古いファイルの整理などは進めていた。

旧サーバーには、古い仕事のファイルが多数ある。必要なものは tar+bzip2 して残し、不要なものは消去する。


新サーバーのディスクは、最小限のサイズにしたいのだ。

そうしたほうが、仮想サーバーを物理サーバー間で移動したりする際に、ファイル転送が速いから。



やっと年末・年始進行が終わって、今週は一息付けた。

そこで、ローカルでの移行作業を一気に済ませ、やっと社内実験用サーバーを更新することができた。



「サーバーを更新したい」と思ってから半年以上かかっている。

しかし、まだ作業は半分しか終わっていない。


新サーバーは仮想環境を kvm にしている。

しかし、もう一台の物理サーバーは xen だ。


これでは仮想サーバーの可搬性がない。もう一台も kvm にしなくてはならない。


xen 仮想サーバーを kvm 仮想サーバーに変える、という未知の作業があるが、調べた限りではそれほど難しくないようだ。


kvm にして新サーバーに退避すれば、あとは物理サーバーを再インストールし、kvm 対応にするだけだ。



しかし「難しくない」としても、時間はかかりそうだ。

計画開始から1年たつ前に終わらせたい。



▲目次へ ⇒この記事のURL

関連ページ

パソコン壊れた【日記 19/05/05】

別年同日の日記

02年 4/17

17年 アメリカが日本製のパソコンに100%関税をかけた日(1987)


申し訳ありませんが、現在意見投稿をできない状態にしています

村井純 誕生日(1955)  2019-03-29 17:21:54  コンピュータ 今日は何の日

▲目次へ ⇒この記事のURL

今日、3月29日は、村井純 氏の誕生日(1955)


すごい人だ、というのはずいぶん以前から知っていたのですが、いまだにその程度の認識から抜け出していません。

インタビュー記事拾い読みしたりとか、その程度の知識しかなくて、ご本人が書かれた書籍などはほとんど読んでません。


そんな状態で、あまり偉そうな紹介はできない。

ふんわりとした概要だけ示して、あとは各種記事にリンクして丸投げします。申し訳ありません。




村井純 氏は、日本のインターネットを黎明期から支え、今も第一線で活躍する方です。


「日本のインターネットの父」と呼ばれることも多いです。ご本人はこの呼び方嫌いだそうですが。

生み出したわけではなく、ただアメリカにあったものを紹介したわけでもなく、「世界と一緒に作り上げてきた」。


しかしまぁ、生みの父ではなくても、育ての父か…町ぐるみで子供を育てる、「近所の親父さん」くらいの役割は果たしていると思います。


まだ貧弱な技術でしかなかった時代から、正しい方向に長年かけて育て上げてきた。

ある程度育ったら、口を出しすぎずに見守り、おかしなことになりそうな時には強い意見を出してきました。



海外では、「インターネットサムライ」とも呼ばれています。

今年の2月には、フランスから、フランスの最高勲章であるレジオン・ドヌールを与えられています。


これは「日本の」だけでなく、世界のインターネットを育ててきた功績から。

IPv6 の実装には、日本の技術者が多くかかわっています。

実際の開発とは違いますが、全体を指揮したのは村井氏でした。




日本の最初の「インターネット接続」は、慶應義塾大学の大学院生であり、東京工業大学総合情報処理センター助手でもあった村井純氏が、2つの大学間を「勝手に」接続したことに始まります。


1984年9月のことだそうです。電話回線を使用して、300bps のモデムで接続し、uucp 運用したそうです。

接続理由は、個人的な都合で、データのやり取りができると便利だったから。



uucp って、メールとかのデータを、時々まとめてやり取りする形式ね。

インターネットといっても、今みたいな「常時接続」ではありません。

決まった時間になると自動的に電話をかけて、その時点で溜まっているデータを双方で交換して、終わったら電話を切るの。


ところで、1984年9月ということは、まだ「電電公社」の時代です。

1985年4月には NTT に組織変更し、通信自由化されるのですが、この時に「電話機」も自由に交換することが可能になります。

それまでは、電話機と電話線は電電公社が「貸し出している」もので、勝手な改造は許されませんでした。


…何が言いたいかというと、モデムを接続するのが違法な時代でした。

大学に相談せずに勝手にやった、とのことですが、相談しても認めるわけにいかないのがわかりきっています。



この「ネットワーク」について、いろいろなところで話したところ、東大の教授から「3地点はないとネットワークとは呼べない」との指摘を受けます。

そこで、1か月後の10月には東京大学が参加。


大学間を接続するネットワークなので、Japan University NETwork…JUNET と呼ばれました。


この後、さらに多くの大学・研究機関が参加していきます。

10年後の 1994年に「役割を終えた」として JUNET は解散しますが、最盛期には 600以上の組織が参加していたそうです。




JUNET は「日本最初のインターネット」なので、いろいろなものが生み出されています。

その一つが、日本語をコンピューターで扱うための文字コード体系。


JUNET 以前に、JIS 漢字自体は制定されています(1978)。

しかし、これは「文字の形(グリフ)と、それを示す数値(コードポイント)のセット」を示したものにすぎません。


JIS 漢字のコードポイントは巧妙で、「区」と「点」の2つから作られています。

そして、区・点ともに、1~94の数値になっています。


この「1~95」という数値は、ASCII コードで印刷可能な文字数、94文字に由来します。


印刷可能「ではない」部分は、コンピュータープログラムが、内部動作のために使用しているかもしれません。

しかし、印刷可能な文字部分であれば、その文字を別の文字に差し替えても、動作に支障はないでしょう。


つまり、JIS漢字は、ASCII との互換性を最大限に考えたうえで作られているのです。


とはいえ、ここまでは「互換性を考えています」というだけの話。

実際に、コンピューターで使えるようにする必要があります。


また、ASCII の文字と同じ場所を使う…ということは、ASCII とは同時に使えないことを意味します。

1つの文章内に日本語と英語を一緒に書けないのです。


それでは不便すぎますから、解決する必要があります。



これを定めたのが、当時 JUNET コードと呼ばれ、のちには国際標準の ISO-2022-JP として定められた文字コード体系です。


ASCII には、もともと「ASCII から脱出する方法」が用意されていました。

これを応用して、ASCII から「脱出」してJIS漢字にしたり、JIS 漢字からまた「脱出」して ASCII に戻ったりします。


今でも、メールなどでこの文字コード体系が使われることがあります。




1985年、JUNET で縁のあった慶應義塾・東京工業大学・東京大学間で、WIDE 研究会が発足します。

インターネット接続に関する研究会でした。


WIDE 研究会は、1988年には WIDE プロジェクトへと発展します。


WIDE は Widely Integrated Distributed Environment の略…ということになってますが、略称の頭に WIDE って入ってますね。


直訳すれば「広域統合分散環境」。統合されつつも、分散された環境…つまり、今のインターネットでできるようなことを研究する、というプロジェクトです。

このプロジェクトは現在も続いています。


JUNET は、大学間を接続して情報交換を行うためのネットワークでした。

それに対し、WIDE はそうした環境を研究し、必要であれば新たな提案をしていくためのプロジェクトです。


密接な関係にはありましたが、目的は明確に違っていました。




1985年には、JUNET と、アメリカの USENET が相互接続します。


USENET は、UNIX のユーザーグループである USENIX が主体となって開始された、インターネット上の情報交換ネットワークでした。

これをベースとして、のちに汎用化された netnews に発展しています。


#USENET は uucp 運用だったが、netnews は nntp 運用。内容については基本的に引き継がれた。


この時は、国際電電(現在の KDDI)を巻き込んだプロジェクトでした。

アメリカまで「電話線で」接続すると、国際電話料金がかかります。


しかし、国際電電を仲間に引き入れたことで、「接続実験」として無料で接続ができたのです。




ところで、このころまで日本のドメインは .junet でした。

しかし、アメリカと相互接続するようになると、ドメインを「公式に」定める必要が出てきます。


そこで、アメリカのドメイン管理団体である IANA から、村井氏個人が委任される形で、.jp が作成されます。


#IANA も、事実上は個人運営。Jon Postel氏が管理していました。


しかし、.junet から .jp への移行は 1989 年頃でした。





1989 年には、アメリカと専用線で接続しています。


このころには、国内でも専用線…電話線を使用した uucp ではなく、現在のような常時接続が始まっていました。

とはいえ、まだ専用線は高価で、大きな組織でないと使えませんでしたが。


国内でのネットワークは、実験的なものとして国も参加した一大プロジェクトでした。

これをアメリカともつなげよう…となった時、国内の各所から反対の声が上がりました。


インターネットも、まだ一般化しておらず、誤解の多い時代です。

もともとは国防総省の研究から始まったネットワークで、軍の機密情報などにもつながっているのに、日本から接続したら国際問題になるのではないか?

それが、反対の主な理由でした。


#国防総省は ARPA-NET の研究に資金は出していますが、軍事用には専用の回線 (MIL-NET)を作っていました。


これに関しても、村井氏が個人でアメリカ側の担当者から「日本の接続を歓迎する」という直筆メモをもらってきて、周囲を説得したのだそうです。




1992年、IIJ (インターネット・イニシアチブ・ジャパン)が設立されます。


JUNET / WIDE は、大学間のネットワークでした。

「大学の」費用で維持され、「研究目的」の使用しか認められません。


そのままでは、自由なインターネットの普及は望めません。

そこで、WIDE とは別のネットワーク網を作り出し、自由な目的で使用できるインターネットを作り出すことが目的でした。


もちろん、村井氏も創設メンバーに名を連ねています。


実際、IIJ 設立後、急速にインターネットは普及し始めます。




1997年、WIDE プロジェクトで、m.root-servers.net の運用が始まります。


これは、DNS ルートサーバーと呼ばれる、非常に重要なサーバ。


本当は日本には「J」が割り当てられる予定だったそうです。Japan だから。

しかし、J をアメリカの組織が運用することになり、じゃぁ別のサーバーを…となった時に「村井に任せるから M で」と M が割り当てられたのだとか。



DNSルートサーバーは、全世界で、A~M の13個しかありません。


DNSルートサーバーの情報もまた、DNS で配布されます。

DNS の技術的な話で、この情報は 512byte に収める必要があります。

そして、512byte では13個しか収まらないのです。


もっとも、非常に重要なものだから、1つのアドレスを複数のマシンで受け持っていて、「13台」ではないのですけど。


10個はアメリカ。ほかに、日本とスウェーデンとオランダに1個づつあります。


日本の M は、東京と大阪、ソウル、パリ、サンフランシスコに実際のサーバーがあるのだそうです。

それぞれの拠点でも複数台あるのですが、重要なものだからこそ、詳細は明かされていません。




1998 年には、WIDE の下位組織として、KAME Project が活動を開始します。

同時期に、USAGI Project も作られました。


現在、多くのインターネット接続は IPv4 と呼ばれる規格で行われています。

しかし、1991 年の時点で「このままでは近いうちに問題が起きる」ことがわかっていました。


そこで、次世代(Next Generation) の規格として IPng の策定が開始されます。

これはのちに IPv6 と名を変え…策定中の仕様案も、途中で大幅に変わったりしながら、1998年にやっと仕様が決定します。


しかし、仕様だけあっても意味がりません。

すぐに…というか、仕様がほぼ固まった時点で、前倒しで実際に動くプログラムの作成(実装)が開始されます。



BSD 系の UNIX に実装を行ったのが、KAME Project でした。

当時は、Linux 人気が出始めたところで、まだ BSD の方が「信頼性がある」と考えられていました。


これが「世界初の IPv6 実装」となり、Linux への移植が行われます。これが USAGI プロジェクトです。




2000年代にはいると、急速にインターネットが普及し、村井氏の仕事も「周辺環境整備」から、今後の在り方の研究に変わっていったようです。

しかし、今でも活動は続いています。


昨年の例でいえば、漫画の海賊版をダウンロード配布させるサイトが社会問題となりました。

政府がそうしたサイトの「ブロッキング」(DNS 等を細工し、到達できないようにする)を正当化する法律を作ろうとしました。



これに対し、WIDE プロジェクトが反対。

「インターネット上の海賊版対策に関する検討会議」が行われ、村井氏は座長も務めています

まだ、インターネットを正しい方向に導くために、精力的に活動中です。


#ここでは深入りはしませんが、当の「保護対象」である漫画家協会がこの法案に反対したこともあり、提出断念となっています。




インターネットの、本当に黎明期から現在に至るまで、多くの影響を与え続けていることがわかると思います。


そうした功績もあり、今年の頭には、冒頭に書いた通り、レジオン・ドヌールも受勲。


まだ存命の型ですので、近年の活動などについてはインタビュー記事などを読んでもらった方が良いかと思います。


NTT DATA 2017/7/21

CiP協議会 2017/9/20

INTERNET Watch 2017/11/30

Wired 2018/12/11

日経ビジネス 2019/1/14



▲目次へ ⇒この記事のURL

同じテーマの日記(最近の一覧)

今日は何の日

別年同日の日記

04年 親不知

11年 卒園式

13年 バードストライク

16年 アクティベートにハマる


申し訳ありませんが、現在意見投稿をできない状態にしています

電気で計算する方法  2019-03-27 17:32:29  コンピュータ

▲目次へ ⇒この記事のURL

たしか1月くらいの話だと思うのだが、小3の次女が、学校の理科で「電気」を習ってきた。


電池に豆電球を繋げると光る。

途中ににスイッチをつけ、回路を「切ってしまう」と光らなくなる。


他にも、回路の一部に10円玉をはさんでも電気が流れたり、消しゴムだったら流れなかったり。

「電気とはどういうものか」という、初歩の初歩だ。


で、こんな初歩的なことを学んだだけなのに、多くのことを知った気になって言うんだ。


「どうやって、コンピューターは電気で計算しているの?」と。




実はこのテーマ、以前に当 WEB サイトで書こうと思ったことがあるものだ。


古いコンピューターの話を調べるのが好きで、いろいろ紹介記事も書いている。

今のコンピューターと違い、初期のコンピューターというのはいろいろ単純でね。

思いっきり単純化した「動作原理」を説明したいと思ったことがあるんだ。



でも、その時は記事にしなかった。

ある程度「コンピューターの話」として書くと、どうしても難しくなるから。


思い切って、身近な別の話に置き換えて書くこともできる。

そうすると、ちょっとはわかりやすい話になるのだけど、コンピューターの歴史としては嘘になる。


で、自分で没にしたんだ。




没にする過程で、それなりの記事はまとめていたので、「思い切ってわかりやすくした説明」は頭の中にあった。


それこそ、小3で習う電気の知識で、十分に理解できる「コンピューターの基礎回路」だ。


現代の本当のコンピューターに使われている回路とは、いろいろと違う。

でも、「原理」を知りたいだけなら十分なものだ。



すでに頭の中に説明しやすい話があったため、次女にはすぐに説明してやることができた。



お風呂に入りながら概要を話して…でも、回路図があった方がわかりやすいため、風呂を上がってから回路図を描きながら説明しなおした。

それで、小3でもだいたい理解できる程度の話。




この話は、もう一度「書いておいてもいいかも」と思い直したのだけど、面倒くさくてほったらかしていた。


そして、数日前に小学校は春休みに入ってしまった。


「小3の次女に向けた話」として書こうと思っていたのに、あと数日で4年生に進級してしまう。



というわけで、一気に書き起こした。

面倒くさかった理由の一つは「回路図を描くのが面倒」だったのだけど、draw.ioという良いサイトを見つけた。



というわけで書いたのが、電気で計算する方法という記事。

技術記事のコーナーに入れておいたが、微妙に技術ではない気もしている。



2進数1桁の、掛け算と足し算を電気でやる方法を書いてある。


そして、それを拡張して、複数桁同士の足し算を行う方法の概要を示す。

さらには複数桁同士の引き算・掛け算をやる方法の「ヒント」までを示す。



複数桁同士の割り算は、知らない。そんな複雑な回路、僕がわからないから。

僕はソフト屋なので、回路は概要しかわからないんだ。




▲目次へ ⇒この記事のURL

別年同日の日記

03年 新型!

04年 新しいペット

06年 落し物

13年 ジュエルペットとプリキュアと

15年 ベーマガ投稿

15年 名刺


申し訳ありませんが、現在意見投稿をできない状態にしています

ジャングルウォーズ2 発売日(1993)  2019-03-19 13:52:45  コンピュータ 今日は何の日

▲目次へ ⇒この記事のURL

今日、3月19日は、スーパーファミコン用ゲーム、「ジャングルウォーズ2」の発売日(1993)


普段は個別のゲームの発売日なんて取り上げないのですが、今日はちょっと特別。

僕がアルバイトでお手伝いして、スタッフロールに名前を入れてもらったゲームなので。


市販の…広く一般流通したゲームに名前を入れてもらったのは、初めてでした。


#これより前に、個人作成した X68k 用ソフト、「コメット」を全国販売してもらっているのだけど。



もっとも、雑用レベルで「お手伝いした」だけなんですけど。

スタッフロールでは、サブプログラマ扱いで入れてもらっていたはず。


そして、当時(というか今でも)僕はスーパーファミコンを持っていないので、せっかく名前を入れてもらったのに遊んだことがありません。



大ヒットゲームではありませんが、遊んだ人が口をそろえて「いいゲームだった」という程度には、良作だったようです。




せっかくなので裏話。

伝聞ばかりで申し訳ないけど、当時アルバイトしていただけなので深いことはわかりません。



マップデータとか、とても ROM に入りきらない広いもので、圧縮して入れてあるそうですよ。

メインプログラマの人が、ハフマン符号使って圧縮している、と言っていました。


ハフマン符号を使うと、任意の位置のマップデータをすぐに取り出すのは難しいわけですが、マップ全体データを荒く区切って、「代表的な位置」を示すポインタを持っている、と言っていたと思います。


任意の位置のマップデータが欲しい場合、近い位置のポインタから展開を始めて、目的のデータを取得します。


…ポインタがかなりの数になって、データは圧縮したけどそれほどメモリ効率は良くない、と言っていた気がします。




このゲームの BGM 、ジャングルっぽい雰囲気で、打楽器を中心とした音楽になっています。


最初は、打楽器をサンプリングして、それで音楽を作ろうとした…のですが、打楽器ってホワイトノイズに近い周波数成分のものが多くて、音階を出そうとしても出ない。


そこで、低いベースの音と打楽器の音を重ねることで、打楽器っぽいまま音階が出るようにしたのではなかったかな。


メインプログラマーの人は、もともと音楽好きが転じてサウンドプログラマーもやっていた人で、この「音作り」もメインプログラマーの手によるものだったはずです。

その音を使って楽曲を作るのは、別の人に任せていましたけど。




▲目次へ ⇒この記事のURL

同じテーマの日記(最近の一覧)

今日は何の日

別年同日の日記

06年 定価より高い

12年 Windows8 と Wii と AtEase

16年 プログラム教育に対する誤解

16年 プログラム教育の目指すところ


申し訳ありませんが、現在意見投稿をできない状態にしています

デヴィッド・カトラー誕生日(1942)  2019-03-13 16:11:17  コンピュータ 今日は何の日

▲目次へ ⇒この記事のURL

今日3月13日は、デヴィッド・カトラーの誕生日(1942)。


伝説級の OS 開発者です。

かなりの変人らしいです。


彼のことを知るには「闘うプログラマー」を読むのが一番良いようなのですが、恥ずかしながら読んでおりません。

なので、彼自身については語れるほどの知識を持っておりません。


とはいえ、せっかくなので、ネット上で知りえる程度の話を、僕の得意な技術方面を中心として、まとめておきます。




まず、彼が手掛けた最初の OS から。

DEC で PDP-11 用の、RSX-11M というリアルタイム OS を開発したそうです。


…DEC PDP-11 から説明したほうがよさそうです。



DEC は PDP シリーズという「ミニコンピューター」を作っていました。


当時、コンピューターと言えば UNIVAC 。そして、IBM。

特に IBM は、プログラムや操作を行う「オペレーター」の派遣とセットで販売しており、コンピューターは自分で扱うものではありませんでした。


それを、あえて「自分でプログラムしてよいコンピューター」として販売したのが、PDP-1 に始まる PDP シリーズです。



ところが、PDP シリーズは、開発開始順に番号がつけられています。

それとは別に、大きく分けて3系統のシリーズがあります。


つまり、数字とシリーズに関連性がなく、非常にわかりにくいです。


PDP-1 は、18bit コンピューターでした。

18bit って、今見るとすごく中途半端に見えますが、当時は UNIVAC も IBM も 36bit で、安くするためにその半分サイズにしたものです。



PDP-7 は、最初の UNIX が作られたことで有名な機械ですが、18bit のシリーズでした。

そして、このシリーズの最後は PDP-15 。


他に、12bit と 36bit のシリーズがあるのですが、突然変異のように一台だけ、16bit の機械があります。

それが、PDP-11 。最終的に、PDP の中で一番売れた機種です。


PDP-11 は、それまでの開発経験をもとに、使いやすくなるように1から再設計を行ったマシンです。

このため、CPU の命令などが非常にわかりやすく、以降の多くの CPU のお手本となりました。


当初 PDP-7 で作られた UNIX も、のちに PDP-11 に移植され、大きく発展しています。




さて、PDP-15 で、RSX-15 というリアルタイム OS が作られます。

…リアルタイム OS 、というのも聞きなれない人も多いと思います。


普段使われている、Windows や Mac OS X 、Linux などは、複数のプログラムを同時に動かせます。

これは、1つのプログラムを少し実行したら、途中結果を保存して別のプログラムを少し動かして…という操作を、行っています。


CPU が十分に速ければ、同時に複数のプログラムが動いているように見えますが、基本的には、1つのプログラムから見れば「一定時間ごとに処理のタイミングが来る」ようになっています。



しかし、世の中には、わずかな遅れも許されないような処理内容もあります。


たとえば、コンピューターにセンサーをつなぎ、何かの状態を監視しているとしましょう。

この監視内容に基づき処理を行う必要があるのですが、「処理」に時間がかかったとしても、監視をおろそかにしてはなりません。


しかし、その「監視」よりも重要な作業もあり、非常停止キーが押された場合には、速やかに停止状態に移行しなくてはならない…など。


こうした場合には、Windows のような「一定時間ごとに順番に処理する」やり方では問題が出ます。


プログラムごとに、どの処理がより優先されるか、絶対に間に合わせないといけない「締め切り時間」などを指示する仕組みを作り、OS はこうした情報を基にプログラムに処理時間を割り当てます。

こうした OS を、リアルタイム OS と呼びます。




さて、その RSX-15 を、大ヒットマシンである PDP-11 に移植したものが、RSX-11 です。


RSX-11 は、派生バージョンが多数作られています。

まず、最初は紙テープからロードして使用される、RSX-11A。

シングルユーザーの OS でした。


これを拡張し、ディスクにアクセス可能とした B。


さらに、単にアクセス可能なだけでなく、ディスクから起動し、ディスクを前提とした D。

D は、マルチユーザーの OS に変化しています。複数人数が同時にコンピューターを使えるのです。


ところで、PDP-11 はアドレスも 16bit で、64Kbyte のメモリ空間しか持ちません。

当時としては複雑なディスク装置を扱う機能を持ちながら、複数人数が同時にアプリケーションを実行できる、という OS を、64Kbyte のメモリで実現していたことに驚きます。


#注:PDP-11 は大ヒットマシンで、改良版も多数作られました。

 このため、のちには 4Mbyte のメモリを搭載する機械もあります。



しかし、当時はメモリの値段が高く、実際に販売された PDP-11 には、搭載可能なメモリ量の半分しか搭載していない、32Kbyte しかないマシンが多数ありました。


RSX-11D を、32Kbyte でも動作させる…半ば無謀ともいえる派生バージョンが、RSX-11M です。

カトラーは、この RSX-11M の開発を指揮しています。


RSX-11M は開発に成功しました。1974 年に最初のバージョンがリリースされています。


D と同じ機能を持ち、より小さなメモリで動作するのですから、これ以降 D は使われなくなります。

M は、RSX-11 の中心バージョンとなり、1993年まで バージョンアップが続けられています。




僕は残念ながら PDP-11 を触ったことはなく、当然 RSX-11 のバージョンごとの違いも知らないのですが、Wikipedia によれば「洗練された半自動オーバーレイシステムを使用している」そうです。


オーバーレイというのは、プログラムを実行する際に、同時に実行される必要のない個別処理にプログラムを分割し、現在必要なプログラムだけをメモリに置く方法です。


こうすることで非常に小さなメモリでプログラムを動かせるのだけど、その処理の必要上、ディスクのようなランダムアクセスメディアが必要になります。

おそらくは RSX-11A から持っている機能ではなく、せいぜい D、おそらくはメモリが不足した M からつけられた機能なのでしょう。



普通は、オーバーレイするプログラムを作成する際には、プログラマがプログラムを分割し、小さなモジュール構成にして、複雑なメモリ管理をしながら作る必要があります。

しかし、「半自動」というのは、分割までやっておけば、メモリ管理などはシステムがやってくれた、ということのようです。

これは、プログラムコンパイル時に行われたようで、複雑なプログラムになると、オーバーレイの生成処理だけで数時間から数日かかったそうです。



…この「数日」も、おそらくは最大限に複雑なプログラム、OS そのものを生成するときなんじゃないかと思います。

OS そのものもオーバーレイしながら動作したのでしょう。



#注:頻繁にディスクアクセスするようでは、真のリアルタイムにはならない。

 本当にリアルタイム性が必要な時は、機能はサブセットだが完全にメモリに収まり、ディスクアクセスを行わない RSX-11S が使われた。




ところで、途中で書きましたが、PDP-11 には UNIX も作られていました。


この UNIX は AT&T ベル研究所によるもので、のちにカリフォルニア大学バークレー校によって拡張されています。

(いわゆる Syetem V と BSD)


これに対し、DEC が公式に「移植」した、Ultrix-11 という UNIX もあります。

さらに DEC 公式として、先に書いた RSX-11M もありますが、「世界初のマルチタスク OS」である、MIT の TSS に由来する、RSTS-11 もありました。


「マルチユーザーなんていらない」人向けに、RT-11 という、これも公式の OS があります。

さらに、MUMPS という OS をやはり公式に移植した、DSM-11 もあります。


公式 OS だけでも、5つあるのです。

これに加えて、PDP-11 は大ヒットマシンだったため、先に書いた UNIX をはじめとする多数の OS が作られていました。


もちろん、OS 毎に、その上で動かせるアプリケーションも異なります。

使いやすくするためには、統一した、決定版の OS が必要でした。




PDP-11 は、その後 VAX-11 という名称で 32bit 版が作られています。

初期のシリーズは、PDP-11 とも互換性を保っていました。


ここに、ふたたびカトラーが、RSX-11M を基とした OS を作っています。

VMS と名付けられています。Virtual Memory System の略で、仮想記憶を採用した OS であることを意味しています。


#仮想記憶の概念自体は、VMS 以前から存在している。

 UNIX もこの後 PDP-11 から VAX-11 に移植され、仮想記憶に対応した。


仮想記憶とは、単純にいえば、ソフトウェアで頑張ってメモリを節約していた「オーバーレイ」を、ハードウェアの支援で行おう、というものです。

ハードが面倒を見てくれるので、ソフトウェアを作る人は実際の搭載メモリを気にする必要はなくなります。


とはいえ、実際の搭載メモリを超えてしまうと、メモリをディスクにスワップし始め、速度が低下します。

VMS 自体は、ちゃんと RSX-11M の後継として、小さなメモリで動作するように工夫して作られていました。


「OS の決定版」として、UNIX よりも多くの機能を作り込んでありましたし、みんなが使うはずでした。


しかし、先に書いたように、VAX-11 にはすぐに UNIX が移植されています。

そして、UNIX の人気はより高まっていくのです。




先に、PDP-11 が多くの CPU のお手本となった、と書きました。


そのころの CPU は、今でいう CISC と呼ばれるものです。

プログラマーがアセンブラでプログラムを組みやすいように、豊富な命令がそろっています。


しかし、命令を大胆に減らす代わりに、高速な命令実行を可能とする新アーキテクチャ、RISC が台頭します。

DEC でも、RISC CPU を使った新マシンの開発に着手しました。


カトラーは、このプロジェクト全体を指揮しました。

RISC を使ったハードウェア開発と、そのマシンに合わせた新しい OS です。


RISC の高速性を活かし、UNIX とも VMS とも互換性のある、新しい OS となる予定でした。

当時パソコンでは Mac が GUI という概念を提示しており、GUI を中心とした操作にする…という考えもあったようです。


一説には、「VMS を進めたもの」という意味で、WNT という名称で呼ばれていた、とも言われています。

(VMS の文字を、それぞれアルファベット順で1つすすめると、WNT になる)


しかし、DEC は会社として「保険」をかけていました。

RISC マシンプロジェクトは、同時に3つが進められており、途中で判断して、一番よさそうなものだけを残したのです。


カトラーの率いたプロジェクトは、途中で中止となります。

失敗プロジェクトを率いた責任者に、その後の仕事は用意されていませんでした。




仕事を失ったカトラーに、マイクロソフトから引き抜きのオファーが来ました。

カトラーはマイクロソフトに移籍します。


この際、彼のチームメンバーの何名かは、彼を慕ってついていきました。


マイクロソフトは、彼に 32bit 版の Windows の作成を依頼しました。

当時広く使われていた Intel の 486 プロセッサではなく、MIPS,Alpha,PowerPC,i860 などの RISC CPU 向けに作ります。


しかし、のちに方針を転換し、従来の 16bit DOS、Windows と互換性を確保し、Intelの x86 にも対応させることになりました。



ここで、DEC で中止した OS の計画が再び動き出します。

UNIX 、VMS との互換性は不要ですが、DOS、Windows との互換性を持たせた、GUI OS です。




複数の OS と互換性を持った OS 、というのは、このころすでに実績がありました。

IBM は、DOS / Windows / UNIX / MacOS などのソフトをすべて動かせる「Workplace OS」の作成を表明し、実際に DOS / Windows だけに限定した形で完成させ、OS/2 という商品名で発売していました。


その仕組みは、マイクロカーネルという概念にあります。


従来の OS は、全体に必要な機能を考え、すべてを一体として設計されていました。

しかし、マイクロカーネルでは、OS は「各種機能の連絡方法」だけを用意し、あとはすべて別プログラムとしてしまうのです。


普通の OS なら絶対必要な、メモリ管理・プロセス管理・ディスク管理なども、OS 周辺の別プログラムとして用意されます。


このやり方だと、各種 OS との互換を取る際も、既存部分と違う部分だけを少しだけ作ればよいことになります。

流用できる部分は流用し、API (呼び出し方)の問題だけならそれを用意し、根本的に違う部分はそこだけ新たに作り…



当時の Windows は、ディスク管理を中心とした DOS の上に、プロセス管理やメモリ管理、グラフィックライブラリなどを積み重ねた形で作られていました。

もともと、DOS の機能が貧弱だったため、上に乗せた部分が肥大化しすぎ、非常に不安定になっていました。


それを、マイクロカーネルの手法を使うことで互換性は確保しつつ、安定性も高め、さらに先進的な機能まで準備したのです。


完成した OS は、Windows NT と名付けられました。NT は New Technology (先進機能)の略。

しかし、VMS を一歩進めた WNT でもあります。



互換機能はありますが、当初は十分な確認が行われていませんでした。

そこで、サーバー用途として NT を売りつつ、互換性を高めていきます。


2000 年発売の Windows 2000 で、デスクトップ用としても NT が導入されます。

とはいえ、この時は DOS ベースの Windows Me も発売されています。


そして、2001 年の Windows XP で、デスクトップも完全に NT 系列となります。

以降、今でも Windows は NT 系列です。




現在、Windows は 64bit 化され、16bit の DOS / Windows との互換性は失われています。


しかし、32bit Windows との互換性は相変わらず保たれていますし、新たに Linux との互換性が確保されています。

これも、当初からマイクロカーネルの設計が良かったからできたこと。



64bit 化の際には、デヴィッド・カトラーは、自分で 64bit のコードを書いていたそうです。

もう上に立って指揮するだけでいいような身分なのに、プログラムを書くことが楽しいのですね。


2008年ごろには、Windows Azure に参加していたようですし、2013年ごろには、Xbox One に参加していたようです。


現在かかわっているプロジェクト名などは明らかにされていませんが、77歳の今も現役で、マイクロソフトで働いているようです。



▲目次へ ⇒この記事のURL

同じテーマの日記(最近の一覧)

今日は何の日

別年同日の日記

03年 いるかのすまし

06年 確定申告終了

11年 遠足とキャンプ

15年 夢の中でデバッグする話

17年 江の島再発見


申し訳ありませんが、現在意見投稿をできない状態にしています

2D-APT II 発表 (1959)  2019-02-25 17:30:46  コンピュータ 今日は何の日

▲目次へ ⇒この記事のURL

今日、2月25日は、2D-APT II が発表された日です (1959)。


…まぁ、普通は「2D-APT II って何?」ってなりますよね。

知名度の高いものではない。でも、コンピューターの歴史の中では、大きな一歩なのです。



APT は Automatically Programmed Tool の略。

翻訳すれば「自動プログラム装置」です。


ごく初期のプログラム言語、それもいわゆる「高級言語」でしたが、プログラム対象はコンピューターではありませんでした。




コンピューターの歴史では、当初から「計算する機械」の仕組みは深く検討されてきました。

その一方で、計算する装置さえでき上れば、その装置に計算手順を教えるのは…まぁ、何とかなるだろう、程度に考えられていました。


この見通しが甘いものである、と認識されたのは、ENIAC が作られたときです。

諸説ありますが、「最初のコンピューター」ですね。


実際、理論上はどんな計算にでも対応できるように作ったはずなのですが、それを実際に「計算させる」ための手順がわからないのです。

その時は、数学が得意な女性が 6人集められ、彼女たちが必死になって計算手順を編み出しました。


この経験から、次に作られるコンピューターでは、もう少しプログラムのしやすさが考慮されます。

時代が過ぎるにしたがってプログラムしやすさは増していき…


といっても、「アセンブリ言語」でプログラムを作れば、「アセンブラ」が自動的に機械語に翻訳してくれる、というレベルには達しました。


そのころにはまだ、サブルーチンとか、スタックという概念がないんですけどね。

アセンブラがあっても、今のアセンブラよりも使いづらく、プログラムを組むのは大変な苦労でした。




計算機を販売しても、そのプログラムが作れないのでは話になりません。


計算機は高性能なのだから、計算機が自分自身をプログラムすればいい、というアイディアが出されたりもしました。

これは「自動プログラム」と呼ばれ、果たしてそんなことが可能なのか、議論となります。


議論に終止符を打ったのは、IBM が発表した FORTRAN 言語でした。

アセンブラではなく、「人間にわかりやすい、数式と、英語に近い言語」で計算の手順を示すと、自動的にコンピューターが実行可能なコードを作り出してくれる、というものでした。




さて、今日の話題、APT は、FORTRAN と似たような初期の言語です。

ただし、FORTRAN が「コンピューターの実行コード」を作り出すのに対し、APT は「工作機械の制御コード」を作り出します。


ここでの「工作機械」は NCMM と呼ばれる装置で、MIT で作成されたものでした。

制御コードデータを紙テープにパンチし、読み込ませることで形状を作り出します。


しかし、この形状データが人間には扱いにくいのです。機械を制御するための、数値の列ですから。


APT が作り出すのは、この制御コードデータの紙テープでした。

しかし、これがあれば金属を加工し、設計通りの形状を作り出すことが可能でした。




つまり、現在の 3Dプリンタの元祖です。


ただし、現在の3Dプリンタを使用する際は、普通はディスプレイ上で3Dモデルをモデリングします。

プログラムではありません。


当時は、コンピューターに接続されているのは「テレタイプ」が普通で、ディスプレイ上で…という概念が存在しませんでした。

プログラムで形状を示すのは、そのためです。



ただ、大きな問題が一つあり、2次元の図形は数式で表現することが可能なのですが、3次元形状を数式で表現することが、非常に難しいのです。


2D-APT II というのはそのための「暫定的な名前」で、まだ2D形状しか扱えないことを意味します。

工作機械は3D形状の削りだしも可能なので、なんとか3D形状をプログラムする方法を模索している途中段階でした。



この後、APT の研究は「コンピューター上で設計図を描くと、それがそのまま機械で加工される」というものに変わっていきます。


実は、「ディスプレイを使って絵を描く」というプログラム…サザーランドのスケッチパッド自体が、この研究の一環として生まれています。



以降は、とにかく示された方法論を、少しでも扱いやすくしようとする改良の歴史です。


NCMM は、さらに扱いやすい CNC になり、先に書いたように設計図から直接、加工が行えるようになっていきます。

現在では、素材を工夫することで、机の上に乗るような小さな機械でも出力が可能です。




APT の話は、過去に詳細を書いていますので興味のある方はそちらもお読みください。




▲目次へ ⇒この記事のURL

同じテーマの日記(最近の一覧)

今日は何の日

関連ページ

どんどん壊れる【日記 19/02/28】

別年同日の日記

09年 ばなな

13年 発表会


申し訳ありませんが、現在意見投稿をできない状態にしています

ファミリーベーシック V3(1985) ディスクシステム(1986)の発売日  2019-02-21 18:58:21  コンピュータ 今日は何の日

▲目次へ ⇒この記事のURL

今日、2月21日は、ファミリーコンピューター向け周辺機器、ファミリーベーシック V3 (1985) と、ディスクシステム (1986) の発売日。


ファミコンのソフトは山ほどあるので、いちいちその発売日を「今日は何の日」で扱おうとは思わないのですが、V3 は思い入れがあるので別格です。


もっとも、本来ならいきなり V3 ではなく、ファミリーベーシックの発売日 (1984/6/21) を取り上げるべきですね…。

いろいろ探したのですが、2月21日にいいネタが見当たらなかっただけでもあります。


ディスクは、たまたま同日だったので一緒に紹介。

まぁ、あとでファミベと絡めた話もしますが。




一応、取り上げたからには語りましょう。

この WEB サイトの、一番最初に作られたページが「ファミリーベーシック」の紹介だったのですが。


ファミリーコンピューター自体、1983年の発売なので、今となっては「生まれる前に流行したんでしょ?」という認識の人も多いでしょう。

任天堂は、今でも Switch でファミコンのゲームを配信していたり、ファミコンミニ作ったりしていますが、まぁ、昔遊んだ人の思い出補正がなければ、今更遊ぶほどのものでもありません。



当時は、「RAM」がまだ非常に高価だったんですよ…


ファミコンは、4Kbyte の SRAM を搭載しています。


SRAM と DRAM では、SRAM の方が高価なのですが、「安くしたい」はずのファミコンは、なぜか SRAM を使用している。

おそらく、ここで SRAM を使用することで、周辺回路を減らせるので、全体としてはむしろ安くなったんでしょうね。


DRAM は、安い代わりに「しばらくすると記憶した内容を忘れてしまう」 RAM で、時々読み出して書き込む、リフレッシュという動作が必要でした。


そして、この動作は、CPU のメモリアクセスとぶつからないように処理する必要がありました。

なので、リフレッシュ動作を行う周辺回路を作らないといけないことを考えると、高価な SRAM を使った方が安い場合もあったのです。



とはいえ、当時のライバルである、セガ SG-1000 とか、ソード M5 とか、MSX とかは、DRAM を使用していました。

これは、どういうことかというと、CPU に Z80 を使用していたから。


Z80 は、DRAM リフレッシュ回路を内蔵しているのです。

ファミコンの CPU は 6502 (のカスタム品)で、こちらはリフレッシュ回路を持ちません。




さて、4Kbyte の SRAM の内、半分の 2Kbyte は画面表示用の VRAM。


すると、残りは 2Kbyte ですが、CPU である 6502 の「決まりごと」により、256byte はスタック用。

そして、256byte は、計算の途中結果などを保持するワーク用。


先に、2Kbyte の VRAM と書きましたが、これは BG 用です。

スプライト用のメモリは、画面表示用の LSI 側に内蔵されていました。


とはいえ、これは「今表示している」分のメモリ。

ゲームを作るときというのは、今表示している画面用のメモリとは別に、「次に表示する」ためのメモリを用意するのが普通です。

そして、そのメモリは用意されていません。


なので、通常の RAM 上に、次画面スプライト配置用のメモリ確保が必須でした。

このために、256byte 必要です。



都合、2Kbyte のメモリの内、256byte * 3 は使用用途が決まっています。

自由に使えるメモリは、1280byte しかありません。


# 1Kbyte = 1024byte です。


たったこれだけのメモリの中で、あれだけ多彩なゲーム世界を作り上げていたのです。

称賛に値します。




…と、ファミコンの話ではなく、ファミリーベーシックの話でした。


この、たった 1280byte しか存在しないメモリの中で、BASIC のプログラムを記憶し、変数を記憶し、動作させることができるのか? といえば、当然できません。


そのため、ファミリーベーシックでは、カートリッジの中に 2Kbyte の SRAM を搭載していました。


でも、これが全然足りない。

…というか、微妙な線で、ゲームを作ろうと思うと「それらしい」形にはなるのですが、作るのが面白くなってきたころにメモリオーバー。


もっとも、そうなったら仕方なく次のゲームを作り始めるしかないので、必然的にたくさんのゲームを作ることになります。

(プログラムが得意な子であれば)


僕の場合、これでずいぶん作り散らかして、プログラムの基礎を学べたように思います。




さて、標準の BASIC カートリッジは、まず、発売時についていた V1 。バージョン1ですね。


ゲームのプログラムと別に、背景をデザインすることができました。


先に、ファミコン本体に 2Kbyte の VRAM を持っている、と書きましたが、画面は半分の 1Kbyte で構成できるようになっています。

もう一画面は、「裏画面」。


ベーシックでプログラム中、当たり前なのですが、プログラムリストの表示に画面を使います。

しかし、2画面あるので、その間も「デザインした背景」は置いてあるのです。


そして、命令一発で、あらかじめデザインした背景を画面に表示できます。

裏画面から表画面にコピーする命令なのですね。


プログラムは 2Kbyte しか作れなくても、1Kbyte 分の画面を瞬時に表示できる機能があるのです。

これで、ちょっと華やかな見た目のゲームを作れました。



でも、この背景、ただの背景なんですね。

迷路を作ってゲームの中に活かしたりはできません。



そこで、改良されたのが V2 。背景に何が書かれているか調べる、という、たった1命令が追加されています。

たった1命令ですが、作れるゲームの幅がずっと広がりました。


この後、V2.1A というのもあるのですが、これはバグを修正したバージョンだそうです。



僕は、ファミリーベーシックは発売してすぐに買ったので、V1 カートリッジを持っていたのですが、後で V2 の存在を知って任天堂に電話したところ、片道送料負担のみで交換してもらえました。

これで入手したカートリッジは、2.1A でした。




そして、「別売り」になった、V3 の登場です。


ファミリーベーシックには、親しんでもらうために、ベーシック以外にも音楽演奏やバイオリズム占いの機能がありました。


これらのプログラムをなくし、空いたメモリに SRAM を増設しています。

それまでの 2Kbyte から、一気に倍の 4Kbyte へ。


先にか聞いた通り、当時はまだ SRAM は高価でした。

V3 は、カートリッジだけで 9800円しました。


#ファミコン本体が 14800円、ファミリーベーシックも 14800円でした。


RAM が増えただけでなく、命令も増えています。

特に、プログラム「作成」を支援してくれる命令が増えたのはありがたいものでした。


(それまでは、デバッガも、まともなエディタもなしにプログラムを作っているようなものでした)



…でも、4Kbyte なんて、すぐに「少ない」と思うようになる程度のメモリなんですけどね。

当時でも、MSX は 32Kbyte 使えましたから。


#もっとも、セガのゲーム機用にも BASIC はあって、こちらは最低 512byte だった。

 4Kbyte を狭いなんて言うと、セガユーザーに怒られてしまう。




さて、「4Kbyte が狭い」と感じていたら、翌年にはディスクシステムが登場します。


ディスクシステムのカートリッジ内には、32+8Kbyte の RAM を持っています。

これをディスクのデータで書き換えながら動作する仕組み。


32Kbyte はプログラム用で、8Kbyte は画像用ですね。

ファミリーベーシックでは、キャラクタは ROM で、書き換えられませんでした。


しかし、ディスクでは当然のことながら、キャラクタも書き換えてゲームを作れます。



そして、ファミリーベーシックとディスクシステムを駆使して、「ディスクベーシック」を作ってしまった人がいるのですね。

当時の雑誌(バックアップ活用テクニック)に掲載されていました。


ファミリーベーシックで小さな簡単なプログラムを作ります。

このプログラムは、ベーシックのシステムプログラム(ROM)領域を、カセットテープに保存します。


#当時は、カセットテープにデータを保存するのは普通で、ファミリーベーシックにもその機能がありました。



次いで、ディスク用の「トンカチエディター」(非ライセンス商品ですが、市販品)を使います。

これは、ディスクシステムに読み込ませて「ディスク内容を好きなように書き換えられる」プログラム。


普通はゲーム改造して遊ぶのに使うのですが、16進数を延々と入力し、小さなプログラムを作ります。

これは、カセットテープからデータを読み込み、ディスクに書き込むためのプログラム。


つまり、先にカセットテープに保存したベーシックのシステムを、ディスクに書き込むわけです。

これで、「ディスクシステム上で動くファミリーベーシック」が出来上がります。


ここから、さらに改造を加えます。

メモリ内容は BASIC でも書き換えられるので、ここからはファミリーベーシックで改造できます。

(トンカチエディタは、ファミコンのジョイパッドで 16進入力を行うので、とにかく使いづらいものでした)



たしか、プログラムで使えるメモリを 16Kbyte 程度に増やしたうえで、最終的に、ディスクにセーブ・ロードできるベーシックになっていました。

(ただし、セーブ・ロードできるプログラムは1つだけ)


さらに、この BASIC ではキャラクタ ROM の書き換えも行えます。



これ、ハードウェア改造なしで、ソフトだけで全部できてしまう、というのがすごいところ。

あこがれたなぁ。欲しかった。


でも、トンカチエディターをこれだけのために買う気はしなかったし、やりませんでした。

改造ベーシックでゲーム作っても、ベーマガに投稿できないしね。




▲目次へ ⇒この記事のURL

同じテーマの日記(最近の一覧)

今日は何の日

別年同日の日記

16年 おゆうぎ会

17年 在庫処分


申し訳ありませんが、現在意見投稿をできない状態にしています

シュガーラッシュ:オンライン  2019-01-07 17:21:35  コンピュータ 家族

▲目次へ ⇒この記事のURL

家族で、約束していた「シュガーラッシュ:オンライン」を見てきました。


実は、長女はすでに友達と一度見ている。

年末に、長女の友達のお母さんが「みんなで見てらっしゃい」と焚きつけて下さったのだ。


小学校5年生で、友達と一緒とはいえ、子供だけでバス・電車を乗り継いで映画館に行き、映画を見たうえマクドナルドで食事までして帰ってきた。

もちろん初めての経験だ。


行く前の長女は、すごく緊張して気弱になっていて、戻ってきた後は「すっごく楽しかった!」と興奮気味に語り続けた。

初めての冒険って、こういうものだろう。




で、近所でやっている映画館はそこくらいだったので、同じところに見に行った。

(もう一軒あるのだが、そこはスクリーンがあきらかに小さい。同じ値段なら迫力のあるところで見たい)


前作、シュガーラッシュは見ていたのだけど、今作に関する前情報は一切なしでの鑑賞。



…ネタばれはしたくないので詳しくは書かない。


すごく面白い映画だった、というのは事実。

でも、前作のような「ゲームマニアが喜べる仕掛け」はほとんどない。

前作と同じようなものを期待するとがっかりする。



一応、映画の宣伝などで明かされている情報の範囲内で書いておけば、実在のインターネットサービスなどが実名で登場したりする。

だから、そうしたものに詳しい方が楽しめる。


でも…「アメリカで人気のあるサービス」が多数で、日本で人気のあるサービスとは、ちょっと違う。

僕はネットのサービスに係る仕事をしているので、使ったことがなくても「こういうサービスがアメリカでは人気」みたいなことを知っている。

でも、それを知らないとよくわからない部分もあるかもしれない。



全体としてはインターネットの「通信技術」をうまく視覚化している部分が面白い。

情報のカプセル化とか、回線により MTU/RWIN が異なることをうまく視覚化できている…とか。


もちろん、そんなややこしいことを考えないでも面白いのだけど。

回線に NETGEAR とか書いてあって笑いどころなのだけど…これも、アメリカではメジャーだけど、日本ではあまり知られていない。

(ネットーワーク機器を作っている会社名)



もう一つ、これも宣伝で明かされている範囲で、ディズニー映画の他のキャラクターなどがたくさん出てくるところがある。


ここらへんでは、ディズニー映画を多く知っている方が笑える。


…つまるところ、前作では「ゲーム」だけで話を組み立てられていたのだけど、今作は「ネットとディズニー映画」にネタが分散している。

そこらへんが、前作と同じではない、という部分。




やたらと細かなコンピューター技術に詳しい方が楽しめる映画、という意味では、トロンを思い出す。

というか、映画の序盤でトロンを意識しているとはっきりわかる演出がある。

(トロンもまた、ディズニー映画だ)



繰り返すが、お話は面白かった。見て損のない映画だと人に勧められる。

…でも、なんだろう。こう、もやもやが残るんだ。


作っている側も、人気があったから続編を、ということになったものの、どう作ってよいか迷ったのではないかな。

先に書いたように話が分散してしまって絞り込めていない感じがあるし、話のまとめ方も、どうもうまく着地できていない感じを受ける。




そういえば、前作は映画がすべて終わり、スタッフロールも終わった後の最後の5秒に「ゲームへの愛」を感じた。


今作では、スタッフロールの際の画面右端に注目。

…インターネットにありがちなものを、うまく表現できていると思う。



▲目次へ ⇒この記事のURL

同じテーマの日記(最近の一覧)

家族

別年同日の日記

03年 続々・C700レポート

05年 Quintuple header

07年 あけましておめでとうございます

09年 FALTIMA030 その後[レビュー・評価]

15年 スティーブン・ボーンの誕生日(1944)

16年 Serverman SIM LTE 解約


申し訳ありませんが、現在意見投稿をできない状態にしています

メインマシンに Win 再インストール  2018-12-20 13:50:45  コンピュータ

▲目次へ ⇒この記事のURL

メインマシンに、Windows を再インストールしてみた。


普段使っているメインマシン、もう7年前のものだ

そろそろ買い換えたい、と3か月前にも書いた


でも、3か月も放置していたのは、それほど不満がないからなんだ。

僕がこのマシンで普段何をしているかというと、WEB の閲覧とメール、テキスト書き、あとは ssh を使ったターミナル作業だけ。


この「ssh を使ったターミナル作業」が仕事のほとんどで、仕事で作るプログラムはほとんどサーバー上で vim を使って書いている。

以前は Emacs 使いだったはずなのだが、このところすっかり vim 使い。


で、作ったプログラムは PHP だったり javascript だったり、node.js だったりするのだけど、WEB ブラウザで見ることになる。


手元にあるのはほとんど「端末」に過ぎず、計算はサーバー上で行われているんだ。


そんなわけで、7年前の非力なマシンでも、特に不満がない。




とはいえ、そろそろ壊れてもおかしくないくらい使っているわけで、壊れる前に新マシンに移行したほうがよいだろうな…程度には思っている。


今のマシンは HDD で運用しているが、今から買うなら SSD だろう。

上に書いたように、作業ではほとんどデータを使わないし、家族写真などの大きなデータは NAS に入れている。


今のマシンは 500GB の HDD で、半分くらいしか使っていない。

じゃぁ、新マシンに SSD 搭載するとして…まぁ、今時 500GB の SSD なら高くはないよな。


と思ってマシンを探すと、案外そういうものは売っていない。

SSD 128GB もしくは 256GB に、HDD 1T のデュアルドライブ、というのがほとんどだ。


Windows って、UNIX みたいにディレクトリの接ぎ木できないし、別ドライブにデータ置くのって面倒くさくないの?




どうも躊躇していたところに、新サーバーを作ったので、それまで使っていた 128G SSD が余った。


これ、今のマシンに取り付けてみよう。

SSD + HDD の環境を試してみたら、案外買い替えの参考になるかもしれない。



先日ノートパソコンが壊れて Windows の再インストールをやったばかりなので、インストール USB はある。

昔… IDE のハードディスクを取り付けたりする時代は、それだけで大変な作業だったが、今時の SATA SSD は取り付けも簡単。


そんなわけで、昨日 SSD を取り付けてインストールし、起動させるまで 30分かからなかった。

仕事で使っているマシンをいじるのは怖かったので、万が一のために以前のディスクの Windows 環境もそのまま残してある。


2つのディスクにそれぞれ Windows が入っているので、起動時に「どちらを起動させるか」と聞かれる。ちょっと新鮮。

で、起動したらまっさらな Windows。


じつは、メインマシンは Windows 7 から 8 10 とバージョンを上げてきていて、ところどころに動作がおかしい箇所があった。


ログイン画面でも、なぜか Windows スポットライト表示されないし。あの綺麗な風景写真を僕も見たい。

(妻に、「あの画面、いちいち気にいったか聞いてきてむかつく」と言われているのだが)




あたりまえだけど、それまでインストールしてあったソフトは使えない。


Chrome と Becky!2 を入れる。


Becky!2 のメールデータディレクトリを、以前のディスクからコピーして…と思ったが、起動時の設定で以前のディレクトリを参照させればよい、と分かったのでそのままで。


Putty は、以前のディスクからコピーして持ってくる。

特にインストーラーがいらないソフトだったし、これで設定なども持ち越せたから。


普段テキスト書きには Sakura Editor を使っているので、これも入れる。


これで、だいたい仕事で使うソフトは整った。




たびたび使うソフトの中には、インストーラーがないものもある。

というか、むしろそういうソフトのほうが使うことが多い。


これらは、前のディスクの「ドキュメント」ディレクトリの中に、「プログラム」というディレクトリを掘って入れてある。

それをもってこよう。


で、コピーしようとして思いとどまった。

そもそも、「接ぎ木」を試してみようと思ったんじゃないか。

いつのころからか、Windows の「ドキュメント」ディレクトリは「ドキュメント」というディレクトリではなくなり、特殊なシンボリックリンクのような扱いになっている。


そして、「ドキュメント」が実際にどこのディレクトリを示すのかは、変更可能。

Exploler の「ドキュメント」とか「ピクチャ」とか書かれている場所で「プロパティ」を見て、「場所」タブでディレクトリ位置を指定してやればいい。


デスクトップを以前の場所に変更したら、見慣れたごちゃごちゃ感が戻ってきた。

調子に乗って、ドキュメントもピクチャもビデオもミュージックも、全部以前の場所にする。


うん、これでだいたい同じ使い勝手になってきた。




Quick Launch を使えるようにする。

Windows 10 ではすっかり「隠し」のような扱いだが、Windows 95 時代には便利だった機能だ。


(便利なものというのは、得てして「理解している人向け」の側面がある。

 Quick Launch もそうで、Win95 の時から「便利だけど例外的なルール」に従っていた。

 そのためか、Win 7 以降は、使えるのだけど隠し機能のような扱いになっている)


画面の隅にいつも時計を表示していたので、それがないと使い勝手が悪い。

この時計は何だっけ…前のディスクを見ていても思い出せない。


ネットで、Windows 用のデスクトップ時計を調べる。YTClock だった。入れる。


時計の下にカレンダーも表示。Chronus 。google calendar と同期できる便利な奴だ。


…なんだけど、google の認証が通らない。

google 側がずいぶん前に認証方式を変えたのに、ちゃんと追随できていないようだ。


古いディスクを探し、データディレクトリを見つけ出した。

コピーしたら、google 同期もできる状態のデータが復活した。


#夕方追記。

 Chronus が悪いのではなく、なぜか Google 2段階認証で、スマホから「はい」を送信したのが Windows に伝わらないようだ。

 再インストールした都合かもしれない。要確認。




これで、普段使う環境としては、ほぼ元通り。


速度が速くなったのか? …こちらは、まだ実感がない。速くなっているのだとは思う。


でも、普段使う Chrome も Becky!2 も Sakura Editor も、常駐するタイプのソフトなんだよね。

一度起動すると、その後はディスクアクセスしない。だから、使っていても SSD の恩恵はない。



しかし、これであまり快適になると、また買い替えが遅くなるかもしれない。



#これを書いた直後、再起動してみた。明らかに速かった。

 快適になってしまった。



▲目次へ ⇒この記事のURL

関連ページ

パソコン壊れた【日記 19/05/05】

別年同日の日記

02年 ムカツク店員

03年 日記エンジンバージョンアップ

13年 Robot Turtles

15年 honor6 plus 使い勝手レビュー

17年 無言電話(SIP SPAM)


申し訳ありませんが、現在意見投稿をできない状態にしています

新サーバー購入  2018-12-16 18:07:00  コンピュータ

▲目次へ ⇒この記事のURL

購入しただけで、まだ稼働してないけど。


3か月前にサーバー買い替えを計画中、と書いたのだけど、やっと買った。


まだインストール作業中。

入れてみても納得がいかなくて入れ直し、とか繰り返していて、いつ稼働を開始できるかはわからない。


買ったのは、ASRock J5005。


多分、省電力マシンとしては今一番バランスが取れているんじゃないかと思う。


あくまでも「省電力マシン」なので、非力。

でも、家庭内サーバーなんてその程度の性能でいい。


というか、今まで使っていた Atom D525 と比べると、Pentium Silver J5005 は、4倍ほどの性能を持っている。


今までだって困っていなかったので、この性能は十分すぎる。


そして、VT-x 対応だ。D525 は非対応だったので、Xen でしか仮想化できなかった。

これでやっと、現在の主流である KVM を使えるようになる。


#家にはもう一台サーバーがあって、そちらで使っている Pentium N3700 は VT-x 対応。

 だけど、互いに仮想化イメージをやり取りできるようにしていたので、N3700 でも Xen を使わざるを得なかった。




新しいマシンに、Ubuntu Server 18.04 を入れてみようと思った。

というか、インストール USB を作ってインストール開始した。


でも、インストール断念。今まで通りの CentOS で行くことにする。


世の中の流れは、サーバーも Ubuntu が流行している。

でも、致命的な問題に気付いたのだ。


Ubuntu のインストーラーは、HDMI で接続すると、1920x1080 のフルハイビジョンで、16x8 の文字ですべての表示を行ってくれる。

サーバー用に使っている小型の HDMI モニタは、フルハイビジョンに対応していないので、文字がつぶれて読めない。


なので、インストールしようにも、何が書いてあるのか読めないのだ。致命的。


Ubuntu Server が世の中の流行、と言っても、その理由の多くが、AWS (Amazon のクラウドサービス) で簡単に使えるから、という理由だと思う。


インストーラーを使ってベアメタル(クラウドではない PC)にインストールする人はほとんどいないので、インストーラーが十分にこなれていないのだ。




もう一つの理由。

Ubuntu Server では、LVM を使う時はさらに厄介な、設定項目が多い古いインストーラーを使わないとならないそうだ。


仮想化サーバーを使おうと思うなら、LVM が使えないと話にならない。

…というのは古い常識だと思って軽視していたのだけど、インストールを開始して、まだ LVM が必要だと知った。


LVM は、ディスクを仮想化する仕組みだ。

と言っても、仮想サーバーだから仮想的なディスクが必要とかではない。

そういう意味での「仮想ディスク」は、KVM などがちゃんと対応している。


LVM は、複数のディスクをまとめて1台に見せかけたり、ディスクのパーテションを仮想化しておいてあとで拡張可能にしたり、そういう仕組みを提供してくれる。


そして、この仕組みの一つに、「スナップショット」がある。

現在使用中のディスクを、他のプログラムなどを一切止めることなく、ある瞬間で停止して更新されないようにするのだ。


サーバーは、無停止運用が基本だ。

それと同時に、日々変化するデータをバックアップし、万が一の時にすぐに戻せるようにしないといけない。


ここで、変化するデータは、バックアップの開始時から終了時までの間にも変化してしまう、という問題が出る。

場合によっては、データ不整合で、万が一の時にデータをバックアップから戻してもエラーになって使い物にならない、ということになる。


スナップショット機能は、プログラムは稼働し、データ更新も行われている状態のままで、バックアップのために「ある瞬間で固定されたディスク」を作り出す。

スナップショット作成以降に更新されたデータは、ディスクの別の領域に一時的に書き込まれ、スナップショット終了時に正しくマージ(混合)される。


これ、サーバー運用するうえでは必須なのだ。

Ubuntu Server では、この技術が使えない…わけではないのだけど、使いづらい。




先に書いた、「古い常識だと思って軽視していた」というのは、実は KVM にもスナップショット機能がついているから。


厳密に言うと、KVM が使えるいくつかの「仮想ディスク」形式の中の、qcow2 形式はスナップショットが使える。

その代わりに、qcow2 は次のような問題があった。


・ディスクアクセスが遅い

・LVM のように「バックアップを取り終わったら元に戻す」形式のスナップショットを取るには、仮想マシンを一時停止する必要がある。

・仮想マシンを動かしたままスナップショットを取ることもできるが、その場合はマージできない。(どんどんファイル容量が増え続ける)

・スナップショット機能は全体に不安定。


…危なっかしくて使えたものじゃない。

スナップショットの必要性はわかっているが、まだまだ開発中、というところなのだろう。


Xen を使っているときは、仮想ディスクとしては「本物のディスクのパーテションを割り振る」のが一番パフォーマンスが出たので、その方法を使っていた。

そして、先に書いたように LVM でスナップショットを作っていた。


この方法はかなり複雑なので KVM では解放される! …と喜んでいたのだが、まだまだこれが最良の方法のようだ。




で、とりあえずベアメタルのマシンに CentOS7 をインストールし、その上に仮に仮想化サーバーを入れてみた。

うんうん、KVM でもちゃんと動く。


でも、実験的に CentOS を仮想化サーバーにしてみただけ。

実際に使うのは Ubuntu Server にしてみる予定。仮想化サーバーなら AWS で使うのと変わらないから、最近の主流に寄り添ってみるつもりだ。


いままでは tinyDNS や qmail など、DJB のサーバー群を使っていたのだけど、これも最近の主流の方法に切り替えていこうと思っている。


「今までの方法で困らない」のも事実なのだけど、技術者としては流行の方法も知っておきたいから。


まぁ、何度か仮想サーバーをインストールしたり消したりを繰り返し、ある程度勉強してから、実際に使うサーバーを作っていこうと思う。



▲目次へ ⇒この記事のURL

関連ページ

松の内にやったこと【日記 19/01/06】

新サーバー設定中【日記 19/04/17】

メインマシンに Win 再インストール【日記 18/12/20】

別年同日の日記

04年 PHPインストールでエラー


申し訳ありませんが、現在意見投稿をできない状態にしています

ノートパソコン修理  2018-12-03 15:09:34  コンピュータ 家族

▲目次へ ⇒この記事のURL

壊れたノートパソコン、注文していた SSD が到着したので交換した。


ノートは、8年前の DELL Inspiron 15 N5010 という機種。


HDD の交換記事は、この機種がまだ新機種だったころに書かれたページがありました。

他のページも多数見つかりますが、みんなこのページを参考にしている感じ。


キーボードを外すところが、どのような形に外れるのかわからずに苦労しましたが、それ以外は特に問題なし。



で、ついでにもう一つ。

同じ趣旨で、去年書かれて、2か月前にも更新されているこちらのページ


HDD の交換ついでに、WiFi モジュールも取り換えてしまうと良い、という内容。

有線 LAN でも 100Mbps しか出ない機種なのに、モジュール交換すると WiFi で 867Mbps 出るようになります。マジか。


こちらのページでは、別途ドライバインストールが必要、と書かれているのですが、最新の Windows 10 をインストールした場合はドライバ不要でした。


#参照したページでは、N5010 のリカバリーディスクを使い、Windows 7 をインストールしている。

 この場合別途ドライバが必要になるが、Win10 なら標準で入っている。




HDD 故障に気づかずにやっていた時は、全然インストールが進まずに悩んでいました。

しかし、新しい SSD に換装したら問題なく進みます。


しかも、SSD なので速い。

すぐにインストールが終わりました。


で、ライセンス認証。

Win10 では、以前に使っていた機種に新規インストールしても、インターネットで自動的にライセンスを見つけ出してくれます。


…「以前違うライセンスの Win10 を入れていたはずですが?」と怒られました。

あー、やっぱり。以前 Win10 Pro を入れていた気がしていたのですが、自信がないのでよりライセンスが安いほうの、Home をインストールしました。


やり直し。クリーンインストールしなおします。



で、今度は「お使いなのは、DELL N5010 NOTE ですか?」と聞かれます。

そうそう、それです。


…「ライセンスコード認証できません。お手持ちのコードを入れてください」という状態に。


#文言は覚えてないので適当。



ここまで特定できているのに、なぜ。

HDD と WiFi モジュールを一気に変えたのはまずかったか。



しかしまぁ、Win 8 pro からのバージョンアップだったので、Win 8 pro のコードを入れたら、それで OK でした。

以前に日記に書いたけど、再インストールしようとして Win8 のインストールディスクも出していたので、ライセンスコードのメモもあったのね。




SSD と高速 WiFi モジュールで、8年前のマシンだけど快適に使える状態になりました。

今となっては非力なマシンだけど、スマホで WEB ブラウズするよりはずっと快適な感じ。


WiFi は、簡単なテストで 260Mbps 出ていました。

理論値の 867Mbps まではいかないけど、それまで理論値でも 65Mbps だったのだから、ずっと高速。



SSD は 512Gbyte のもの。

メモリは、すでに以前に最大である 8Gbyte にしてあります。



そんなわけで、おそらくこのノートとしては現状で拡張できる最良の状態。

SSD と WiFi モジュール合わせて、1万円ちょっとでした。

修理のコストパフォーマンスとして結構よいように思います。


しかし、これはもう使わないマシンなので子供用です。

最近、子供3人ともパソコンを普通に使うようになってきて、1台のマシンを奪い合っていたからね。



▲目次へ ⇒この記事のURL

同じテーマの日記(最近の一覧)

家族

関連ページ

壊れたノート・その後【日記 18/11/29】

メインマシンに Win 再インストール【日記 18/12/20】

別年同日の日記

02年 イタメシヤ

02年 オムライスカレー

12年 ボーリング

14年 ジョン・バッカスの誕生日(1924)


申し訳ありませんが、現在意見投稿をできない状態にしています

なにもしてないのにこわれました  2018-11-19 15:40:37  コンピュータ 歯車

▲目次へ ⇒この記事のURL

2か月ほど前に、新しいPCを検討中という話を書いた。


デスクトップPCも古いし、サーバも古い。買い替えたい。

でも、結局まだ買ってない。UPSは買い替えて、つなぎなおしたけど。



妻のPCは買いなおした。

PC仕事はしているが、僕より要求がシンプルだから機種を決めやすい。


実は、妻はすごくたくさんのPCを使っていたのだが、分散しすぎて使いにくい。

「全部一本化できるマシン」という要求で、調査したら1機種だけ目的にかなうものを見つけ、それにした。




妻の、購入前のPC状況を書いておこう。


メインはデスクトップ。WACOM のタブレットをつなげて使っていた。

これとは別に、ノートマシン。妻には会社の会計もお願いしているが、会計ソフトを入れて使っていた。


そもそも、仕事用と会計用は使用目的が違うので分けたい、という用途でこうしていた。

ここまでは、まぁいいんだ。



最近、休日でも何となく作業をしたいときに、家族がいる居間で、ノートマシンで作業したりもしていた。


でも、やっぱりノートでは絵が描きづらいんだ。

絵に関係ない仕事を中心としていたけど、絵を描きたいときだってある。


そこで、半年ほど前に Raytrektab を買ってみたんだ。


Windows のタブレットなのだけど、CPU 性能を落として電池持続時間を延ばし、WACOM の液晶ペンタブ技術で直接絵を描けるようにしてある、というモデル。


これをノートマシンのサブとして使えば、好きな時に絵を描ける…というつもりだった。


でも、結局妻はあまり活用していない。

思った以上に CPU 性能が低いマシンで、絵を描くには最低限ギリギリラインではあるのだけど、アプリケーションの起動とかに時間がかかってしまって気軽ではなかったから。



ただ、画面はスマホより大きめなので、ニコニコ動画とか見たいときに使いやすい、とは言っていた。

(時々、作業の傍ら生中継とか見ている)




それで、新しいマシンを購入するのであれば、


・ノートマシンとして持ち歩ける

・現在メインのデスクトップ(7年前の機械)程度の CPU 性能は出る

・直接ペンタブとして絵も描ける

・必要なら、大画面の動画閲覧マシンにもできる


ようなマシンが欲しい、となった。



持ち歩ける、という時点で、ノースピンドルマシンがいい、という話にもなった。

スピンドル(回転軸)を持たない…つまり、ファンもなければハードディスクもないマシンだな。


でも、これはなかなか難しかった。

SSDのみのマシンでいいのだけど、上の要求を満たすマシンは高級機になってしまい、購入機だと必然的に、「安心の大容量」であるHDDが、SSDとは別についてきてしまうのだ。


そこで、HDDが「ついてきてしまう」のは許容することにした。


そして選んだマシンは、HP Envy 15 x360

キーボードを完全に裏側に回してタブレットにもなるマシンで、キーボードを画面の「スタンド」として使って動画を見てもいい。


画面はタッチパネル、かつ液晶ペンタブにもなっている。

標準付属のペンは傾き検知に対応していないが、別売りペンを買えば傾き検知もできる。


もちろん、ノートとはいえ、7年前のデスクトップより CPU 性能は上だ。


もう買ったのは2か月近く前で、徐々にこのマシンだけで作業が済むように、妻は移行作業を行っている。




で、今日の本題だ。


移行作業の多くは、デスクトップで使っていたアプリを新しいノートにも入れる、という作業だ。


でも、そろそろ前のノートで使っていた会計ソフトもこのマシンに入れようと思った。

そしたら、ライセンスの関係で、前のノートの会計ソフトを「ライセンス削除」してから出ないと認証できない、とわかった。


そこで、前のマシンを起動したら…起動しないんだ。

しばらく使っていなかった。以前、最後に起動したときはちゃんと起動できた。


その後いじっていないのだから、本当に何もしていない。


なにもしていないのにこわれました



妻が「起動できなくなった」というので、きっと Windows 回復環境で起動してスタートアップ修復すればいいだろう…と思ったのだけど、ダメだった。


一応、回復環境での起動はできる。

そこから、「トラブルシューティング」を選んで、システム回復を試みることができる。


「システムの復元」で回復ポイントまで戻そうとしたが、「失敗した」と言われて、もどらない。

「イメージでシステムを回復」…は、そもそもバックアップ取ってないとダメな奴だ。


「以前のビルドに戻す」も試してみたけど、もちろんダメ。



最後の手段だ…ユーザーのファイルは残したまま、Windows の再インストール、という項目があったので選んでみた。

しかし、「失敗した」と言われてできなかった。


ムムム…

これらの「回復環境」は、隠しパーティションに収められた Windows のインストールファイルを使っている、と認識している。

そちらのファイルが古くてだめなのか。


調べてみると、Windows 7 からアップデートしたマシンは、隠しパーティションのファイルが Windows 7 のまま、ということのようだ。

だから、Windows 10 を修復しようとしても、Windows 7 のファイルしかなくて失敗しているのだろう。


じゃぁ、Windows 10 のファイルを用意してやろう。




というわけで、回復ドライブを作る。

僕のメインPCもまた、Windows 7 からアップデートしたものだ。

そういう機種で回復ドライブを作ると、Windows 7 のインストールを始めてしまうらしい。


じゃぁ、買ったばかりの Envy から取ってみよう。USB を用意し、回復ドライブを作る。


一応、この回復ドライブは「そのマシンでしか使えない」ことになっている。

でも、ダメならダメでやってみるしかないだろう。


古いノートに USB を差し込み、そこから起動。

インストールメニューは開いた。しかし、「ユーザーデータを残したままインストール」はできず、クリーンインストールしかない。


これでは、古いマシンのデータは救えない。


まぁ、最悪クリーンインストールすることに問題はないのだけど、ある程度データが残ってしまっているのを拾い上げたい。




改めて、回復環境からコマンドプロンプトを起動する。


回復用の OS が、ドライブ X: として起動するのだけど、別のドライブを見てみる。

C: D: は、回復用の隠しパーティションのようだった。そして、 E: が普段の C: ドライブ。


どうやら、欲しいデータはちゃんと残っているし、アクセスできるようだ。



じゃぁ、Linux の LiveDisk 作ってサルベージするか。


手元に DVD-RW があったので、Ubuntu Remix を焼く。

DVD1枚にすべてを収めていて、そこから起動できる、日本語対応の Ubuntu 環境だ。



DVD は遅いので起動に時間がかかるが、無事起動できた。

そこから「ファイル」アプリで HDD を覗くと、ちゃんと目的のデータがあった。


じゃぁ、これをどこかにコピーしよう。

USB メモリはうまく認識できなかったが、ネットワークに接続できた。

家庭内の NAS にバックアップを取る。


データが大きかったので、6時間待ちだ。今コピーしている。



必要データが退避出来たら、Windows のインストールを試みるつもり。


その後は、あえて会計ソフトをインストールして認証したうえで、認証を削除してアンインストール、という無駄な手順を踏まないといけないだろう。




そのあとは…もう使わなくなるのだから、子供向けマシンかな。


古いマシンとはいえ、まだ十分使える性能を持っている。

少なくとも、今子供が使っている Chrome OS マシンよりは性能が高い。




▲目次へ ⇒この記事のURL

同じテーマの日記(最近の一覧)

歯車

関連ページ

壊れたノート・その後【日記 18/11/29】

別年同日の日記

01年 11/18

02年 また風邪?

04年 地鎮祭

08年 エジソンロック


申し訳ありませんが、現在意見投稿をできない状態にしています

7 Billion Humans  2018-11-09 14:10:30  コンピュータ 家族

▲目次へ ⇒この記事のURL

少し前に Nintendo Switch で発売になった「7 Billion Humans」を遊んでいる。


購入直後は「あれ? 思ってたのと違う…」という感じだったので特に日記ネタにしなかったのだが、ステージが進むにつれて期待通りの内容になってきた。


しかし、このゲーム、遊んでみるまで内容がわからない。

事前に紹介ムービーとか作成者インタビューを読んでいても、どんなゲームかさっぱりわからなかったのだ。


そんなわけで、僕と同じように迷っている人のために、どんなゲームか書いてみようと思う。




一応、Human Resource Machineの続編ではある。

どちらも「プログラムゲーム」だし、インターフェイスや画面構成もほぼ同じだ。


だから、同じようなゲームかというと、全く違う。

プログラム言語が違うのだ。


プログラムを中心とするゲームなので、「言語が違う」というのは、かなり違うものだと思っていい。



前作、Human Resource Machine では、「アセンブラ」を使ってフィルタを作るゲームだった、と考えていい。


部屋の入口・出口にベルトコンベアがある。

入口からは「データ」が次々入ってくる。


これを、アセンブラプログラムで「加工」して、出口のベルトコンベアに乗せる。

結果が課題通りであれば、ステージクリア。


こういう、次々と入ってくるデータを適切な形に加工し、出力するプログラムを「フィルタ」と呼ぶ。

だから、Human Resource Machine は「フィルタを作るゲーム」だったんだ。


たとえば、次々入ってくる数値データを、0 を区切りと考えてそれぞれの合計を出し、出力する、という課題があったとする。

そのプログラムを、非常に低機能なアセンブラで作成する。


できた、と思っても、結構入力データが意地悪だ。

0 が2連続する部分があったりする。


0 が区切りなのだから、2連続ということはデータが空っぽ。

この時、合計を出力するのだから「0」を出さないといけない。

でも、うっかりしているとおかしなデータを出力して、上司に怒られたりする。



そう、このゲームの主人公は「おじさん」で、上司が課題を出す。

おじさんは、アセンブラに従って、ちょこまかと移動して働き、正しければ上司に褒められるし、間違えていたら怒られる。


このおじさん、あくまでも CPU の動作を「面白く表現」しているだけで、ゲームの主体はプログラムのほうにある。

おじさんの動きはかわいいが、おじさんを動かすゲームではない。




さて、今作 7 Billion Humans の話に入ろう。

タイトルは「70億の人々」という意味だな。全世界人口。


このゲームは、人をプログラムして動かし、課題をクリアしていくゲームだ。

前作のように、おじさんの動きは飾りではなくなった。おじさんの動きのほうが主体で、それを動かすためのプログラムを組むのだ。


8方向のどちらに進むか、命令パネルを並べ、おじさんが行った先で pickup で置いてあるものを拾う。

そして、指示されたところに移動して、drop で持っているものを置く…



最初のほうの課題は、そんなのばかり。

あ、これ、ダメな奴かもしれない。プログラム教育の悪い例だ。


…そう思ったから、購入してもすぐに日記ネタにしなかったのだ。




Hour of Code という活動がある。

子供にプログラムを教えよう、と頑張っている組織だ。


子供に人気のキャラクターが、そのキャラクターに合わせた「課題」でプログラムを教えてくれる。


たとえば、「アナと雪の女王」を使ったチュートリアルがある。


ここで、「前に n ピクセル動く」とか「右に n 度曲がる」などを駆使して、スケートの跡で綺麗な模様を描いてみよう、という「プログラム学習」が行える。


たしかに、わかりやすい。そのわかりやすさは「与えられたとおりにすればいい」からだ。

結果として、課題はクリアしていくのだけど、プログラムを理解できないまま終わってしまう。


一応、順次実行や繰り返しなどの、プログラムの基礎は学べることになっているのだけど、プログラムってそういうことではない。

「どうすればいいんだろう」って悩んで、解決方法を自分で組み立てていくのがプログラムだ。


まぁ、Hour of Code のすべてがこういう課題だというわけではない。

(以前はすべてだったのだけど、今見に行ったら、現在は「上級課題」としてもっとまともなものが用意されているようだ)


悩むにしても、知識ベースがないと解決方法がわからない。

その知識ベースを与えるために、こういう学習方法もありだとは思うのだけど、これだけで終わってしまうのは面白くないというか、もったいない。




で、7 Billion Humans もそういうゲームなのか、がっかり…と思いながらも先に進めたら、途中からどんどん変わってきた。


今作では、「おじさん」が一人ではない。多数の人々が協力して課題を解かないといけないようになっている。


でも、ここで大切なのは「プログラムは1つだけ」ということなんだ。

多数の人がいて、協調動作を求められているにもかかわらず、その指示を行うプログラムは1つしか作れない。


だから、工夫しないといけない。


プリンタから出てくる書類を、人々が順次閲覧して、最終的にシュレッダーにかける問題がある。

このプログラムで真っ先にやらないといけないのは、「自分の位置を認識させる」ことなんだ。


プリンタの前にいる人は、プリンタからの書類を受け取らないといけない。

シュレッダー前の人は、書類を受け取ったらシュレッダーに入れないといけない。


でも、それ以外の人は、「隣の人から書類をもらう」という動作以外をやってはいけない。


自分が何をすべきか、周囲の環境から判断し、処理を振り分けるプログラムを作らないといけない。



UNIX などの OS では、fork を使って並列動作ができる。

その際、プログラムは同じものになるのだけど、自分が「親」か「子」かを判断して違う動作をさせる必要がある。


このゲームでは、そういう高度なプログラムと同じものを求められるんだ。



さらには、途中の課題から「メモリ」が使えたりもする。

前作では、「入力」されたデータを床に置いたりすることができ、それがメモリだった。

今作では、一人の人は、4つのことを覚えられる。これがメモリだ。


覚えられるのは、データの値だったり、その値を計算した結果だったり、部屋の中の「位置」だったり、文脈によって自由に変わる。

さらには、「最寄りの社員の位置」とかを瞬時に見つけ出して、その位置をメモリに入れたりもできるようになる。


位置は、「その位置まで移動」という形で使える。

8方向に1マスづつ異動ではなく、一気にその位置まで移動できる。


メモリが出てくると、ゲーム内容が一変する感じすらある。



ただし、メモリはあくまでも「個人の記憶」であって、共有メモリのようなものはない。

だから、協調動作の際に、共有メモリを使って指示、みたいなことはできない。

(これ、並列プログラミングでは結構やるのだけど)


だから、個々人はそれぞれ独立にプログラムを実行しているだけで、協調動作などのようなことはできない。

…この時点までは、まだ。




さらに後の課題で、listen と tell というコマンドが増える。

listen した人は、tell されるまで動作を止めてしまう。


これを使って、やっとタイミングを合わせて協調動作させることが可能になる。

tell するときは、「全員に」聞こえるように大声を出すこともできるし「隣の人に」話しかけることもできる。


これも、他の人の動きを待とうとして、全員一斉に listen したりしてはならない。

何らかの周辺環境を判断して、最初に動く人を決め、その人以外が listen するようにプログラムを組む。



たとえば、床一面に広げられた「数値データ」の平均を取る課題がある。

7×7にデータが並び、その下に7人の人がいる。


それぞれを上に進めながらデータを合計していくのだけど、これだと「各列の合計」しかわからない。

一番上まで行き、列の合計が出た後が問題だ。


人々のスタート位置は異なっていて、わざと一番端の人のスタート位置を下げてある。

逆に言えば、端の人は最後に上まで到達するように作ってある。


そこで、端の人以外は、上に到達したら listen して待つ。

端の人は、到達したらそこのパネルに合計値を書き込んで、隣の人に tell する。


tell された人は、隣のパネルの値を自分の覚えている合計値に足し、パネルに書き込み、隣の人に tell する。

以下繰り返し。


これで、最後の人は「全体合計」を知ることができる。

49 で割れば平均値になる。


課題としてはこの平均値を「答える」ための操作でまたいろいろあるのだけど、大体目標は達成できる。




一応、この後「周囲の8マスを順に」という、ループ命令が出てくる。


このゲーム、前作に比べて課題が多く、まだ最後まで終わらせていない。

まだまだ新しいコマンドが登場するのかもしれない。


しかし、全体としては4つの段階に分かれているので、これで最後かも。

1段階目で基本命令、2段階目でメモリ、3段階目で listen と tell 、4段階目でループだ。


一つ不満を書いておくと、課題ごとに、不要と思われる命令は使えないようになっている。

多分迷いなく答えにたどり着くための「やさしさ」なのだろうけど、それまでに出てきた命令は自由に使わせてくれたいいのに、と思う。



課題が多いと書いたが、1個づつの課題の難易度は低めだ。

そりゃそうだ。「アセンブラで書け」と、「Scratch で書け」っていうのくらいの違いがあるのだ。


Scratch は子供向け言語だけど、並列プログラムも可能だし、今回のゲームの言語と似ているように思う。


今回のほうが、明らかに高級言語。その時点で難易度が低くなるのは当然。

そして、その分課題を増やしてある。だから、ゲームとしてのボリュームは同じくらい。



どのくらい難易度が低いかというと、前作のアセンブラは子供には理解しづらかったようで、中学2年の長男も少しやって投げ出してしまった。

今作は、小学校3年生の次女が「面白い」と言って楽しんでいる。それくらい難易度が下がった。




あ、もう一つ不満点あった。


まずは課題をクリアすること。プログラムが汚くても、力業でも構わない。

クリアすれば、次の課題が遊べるようになる。


だけど、課題ごとに「短さ」「速さ」で基準値がある。

もし楽しみたければ、それらを目指してもいい。場合によっては、基準値を超えたものも作れる。



ここで、前作なら短さを目指すと、それなりに「美しい」プログラムになった。

美しいっていうのは個人のセンスによるものなのだけど、少なくとも短くするために無駄がそぎ落とされている、という意味合いだ。


これが、今作では短さを目指すと、エラー処理を無視することが多い。

たとえば、一歩歩くごとに、とにかく「ものを拾う」ように作る。


そこに何もなければ「なにもありません」とおじさんが立ち止まる。つまりは、エラーが出る。

でも、「何かあったら拾う」と条件判断をするより、1行少ない。


短いとしても、エラーが出まくるのは美しくないように思う。

でも、それをしないと課題をクリアできないこともある。


速さに関しては、前作はループ展開したりすることもあったが、今回はどれだけ並列度を上げられるかが勝負だ。


エラーが出ると「立ち止まった」分だけ遅くなるというペナルティがあるので、1ステップ増えてもエラー処理は必須。

こちらのほうが、むしろ「美しい」かもしれない。


その一方で、条件判断していると速度が落ちるので、大胆な「決め打ち」をすることもある。


データはランダムに変更され、速度は「何回か実行した平均値」で測られるので、データに依存した決め打ちはできない。

でも、条件判断が省略できるところを探して、汎用性がない「決め打ち」のプログラムを入れ込む。


これがまた、美しいプログラムではない。

今回のゲーム、短さを目指しても、速さを目指しても、美しくないプログラムになることが多いのだ。




しかし、最適化が難しくて、後回しにしている課題も多い。


後回しにしている、というのも、簡単に思いつかないほど奥が深いということではある。

まだしばらく楽しめそうなゲームだ。



▲目次へ ⇒この記事のURL

同じテーマの日記(最近の一覧)

家族

別年同日の日記

03年 公正取引委員会

06年 財布を買った

09年 風邪惹き

15年 太陽暦採用記念日

15年 歯医者


申し訳ありませんが、現在意見投稿をできない状態にしています

WEBページの検索順位をあげる方法(2/2)  2018-10-06 17:58:07  コンピュータ

▲目次へ ⇒この記事のURL

検索上位を目指すための WEB サイト作りの話、の後半。


前半記事では、そもそも検索とは何か、何をもって順位を決めているのか、などの話をした。

基礎知識としてはそれで十分なのだけど、概念だけではわかりにくいので、ここからケーススタディに入ろうと思う。



▼当サイトの場合


まず、実例としての当サイトだ。


はっきり言って、検索順位はそれほど高くないので、偉そうなことが言える実例ではない。

とはいえ、「個人が趣味を書きなぐっているだけのサイトとして」という但し書きをつければ、結構悪くないと自負している。


非常に古くから作っているページなので、サイトの作りそのものが、検索エンジンに最適化されていない。

だから、今から Wordpress などで同じようなページを作る人がいたら、もっと上の順位を狙えるだろう。



…と言い訳しながら書くが、現在の当サイトのページ数はおよそ 2000。

22年やっているので、平均して4日に1記事は入れ続けてきたわけか。

飽きずによく続けたな、自分。


そして、本来のメインコンテンツである「古いコンピューターの話題」は、全く人気がない。

いいんだよ。自分の趣味で書きたいだけなんだから。


比較的人気があるのは、料理ページ、旅行記ページ、日記。

日記は雑多な内容を詰め込んでいるのでさらに細かく書くと、人気があるのはやはり旅行記と料理。

それとコンピューター雑学。今書いている、検索エンジンの順位を向上させる方法というのも、コンピューター雑学だな。


見事なまでにバラバラのジャンルで、検索エンジン対策としては良くない。

まぁ、広告収入を目指して作ったページではないので、あまり気にしていない。




当サイト、記事がやたら長い。


長すぎるページは読者が飽きてしまう。

文章は 1000文字~2000文字程度でまとめよう、とされていた。


しかし、今では常識が変わっている。

2000文字は最低ラインで、長くしたほうが良いとされる。僕にとっては追い風だ。


でもね、実のところ、長さは問題ではない。

みんな、そもそも関係ない「長さ」を気にしているから迷走するのだ。


重要なのは、読んだ人が感心してリンクをくれるかどうかだ。

この基本に戻って考えよう。


短くても人の心を打つ文章は書けるし、長くても苦も無く最後まで読めて面白かった! と言える文章もある。



実際のところ、短い文章を書くというのは難しい。センスが必要とされる。


星 新一 をご存じだろうか。短い文章で楽しませる小説形式、ショートショートの名手だ。


2000文字というのは、その作品群の中でも短い部類に入る。

センスあふれる人でも、2000文字では厳しいのだ。


僕はそんな才能はないので、長い文章を書く。


文字数ではなくて行数で考えているのだけど、200行が目安。

これを超える文章はさすがに長い。調べると、大体 6000文字のようだな。


どうしても200行では書ききれない場合は、複数に記事を分割する。

ただ機械的に分けても意味がないよ。分割するときは、話題が変わる部分で記事を分けるようにするんだ。


この記事の場合も、2つに分割している。

前半が仕組みの話で、後半が具体論だ。


過去には4つくらいに分けた記事もあるのだけど、その記事は今でもよく読まれる人気記事だ。




乏しい経験則から、人気の出る記事のパターンをいくつか書き出してみよう。


まずは、個人の体験を書いた記事。

僕のサイトだと、


大人がヘルパンギーナにかかると

失敗しない焼きメレンゲ

スパリゾート・ハワイアンズに行きたい人へのまとめ


このあたり。


1番目は、ちょっと珍しい風邪をひいたので、病状変化をまとめてみたもの。

2番目は、ごく普通のお菓子のレシピなのだけど、失敗しやすいポイントを詳細に解説したもの。

3番目は、家族旅行記。ただし、旅行記とは別に、旅行先の施設の様子を細かくレポートしている。


お菓子のレシピが「体験」なのかと思われるかもしれないけど、作るのが難しくて何度も失敗したからね…

大抵、レシピっていうのは成功する前提で書かれているので、失敗体験をもとに書いてみた。



世の中、公式見解や客観的な記事はいくらでもある。

でも、そういう記事って、良い面は伝えても悪い面は隠していたり、失敗は隠して成功部分だけまとめていたりする。


情報としては半分欠けているわけだ。

本当に情報を求めている人は、悪い面も、失敗しやすいポイントも、包み隠さずすべてを知りたい、と思っていることが多い。


だから、個人の体験した、そういう悪い部分も含めて伝える記事は人気が出やすい。

これは僕のページでの経験則だけでなく、「クチコミマーケティング」と呼ばれて、重視されている現象だ。


◎主観的で、思い入れたっぷりな個人の感想のほうが人気が出やすい




次に、「自分が知りたかったのに、検索しても出てこなかった」情報。

実は、上に書いた3つとも、これにも当てはまる。


1番目は、風邪をひいて辛いから情報を探しても見当たらなかった。

2番目は、お菓子作ろうと思ってレシピを調べたが、いい加減なことを書いてあるページを多数見かけた。

(にもかかわらず、それがいい加減であることに気づかずに従い、失敗した)

3番目は、子連れ旅行で準備が大変なので調べたのだが、知りたいことを書いてあるページがなかった。


そのあとで自分が体験したり、正しい理解にたどり着いたりしたので、記事としてまとめたものだ。


どこにも情報がなければ、自分の書いた記事が唯一の情報源となり、重宝される。

自分が苦労して解決したことは、必ず誰かの助けになる。


まぁ、どの程度の人の助けになって、どの程度のリンクをもらえるかはわからないのだけど。


◎探しても見つからない情報は狙い目




自分が知りたかったのに、というのは、言い換えれば「疑問を持つ人がいた」ということだ。

誰かが疑問を持ったなら、同じ疑問を持つ人は他にもいると思っていい。


というわけで、「人が質問していたことに答える」というのも、人気が出る記事のパターン。


ボタンの左右位置

ファミコンの詳しい話

ファミコンの画面について


この辺りは、質問に答えたものが、その後も人気を維持しているページ。


ファミコンの話が2つあるけど、1つめの後半部分が質問に答えて後から追記したもの。

それが人気があったので、調子に乗って派生させたのが、2つ目の記事。どちらも今でも人気がある。


僕はコンピューターが専門なので、質問に答えるのは、多くがコンピューター記事の雑学記事になる。

コンピューター雑学だから人気がある、ということではない。


誰でも自分の得意分野はあると思う。

その得意分野の記事を書けば、人が持っていない情報となり、人気が出るだろう。


◎質問が出たら、同じことを考えている人が多数いると思おう




あと一つだけ書いておこう。

これも自分の体験を書く、ということなのだけど、非常に高価なものを買った時の「人柱レポート」はそれなりの人気がある。


ただ、これらの記事は読まれることは多いものの、リンクされることは少ない。

そういった意味では、検索順位の向上効果は低いかもしれない。


#ページランクは順位を決める上で重要な指標だが、実は「検索結果の中で、最近よく読まれる記事」というのも検索順位を向上させる。


高価なものを買うときって、だれしも慎重になると思う。

すでに買って使っている人のレポートを読んでみたくなるのだ。だから人気が出る。


でも、それは比較検討のためであり、わざわざほかの人に教えてあげるようなことではない。

だから、リンクするまでには至らない。


僕のページで言えば


注文住宅建築記

新車購入


あたりが人気記事。

少し前は、スマホ P10 plus を購入した記事なんかも人気あったけど、後継機種の P20 が発売されてからは人気なくなりました。


新車購入も、先日書いたばかりの記事で、検討した最近の車種名が並んでいるから読まれているだけでしょう。

この手の記事は、しばらくしたら人気なくなります。そういうもんです。


◎人柱レポートは人気記事



失敗談なんかは特に人気。他人の不幸は蜜の味。

高価な買い物で失敗したなら、せめてウケを狙って元を取ろう。




▼ケーススタディー


では、最初に書いていた通り、伊豆大島のレンタカー屋さんのページ検索順位を上げる方法を考えてみる。


あくまでも、「僕ならこうする」というだけで、レンタカー屋さんに強制できるものでもないし、やってもらった時の結果も保証できない。



すでに、商売のための WEB ページは持っている。

CMS である Wordpress で作られたもので、記事を増やすだけで検索上位に来やすい状況は整っている。


でも、Blog 部分には記事が全然投入されていない。数件の「お勧め飲食店」の情報だけ。

そのほかのページも、店舗の位置やレンタルしている車のタイプ、値段などがあるだけ。


商売上の必要な情報は書いたから、ページとしては完成。

…ということだと思うのだけど、これでは検索順位が上がらない。



レンタカー屋さんによれば、宣伝のために SNS に力を入れている…とのことだった。

WEB のトップページには、Twitter / Facebook / Instagram の最近の投稿が並ぶ。


今は、SNS で日々のレンタカーの空き状況などを紹介している。

しかし、これは使い方としてあまり良いと思えない。


SNS は基本的に、近況報告のメディアだ。

短期間しか滞在しない観光客が、「毎日のレンタカー状況」を知るためにフォローするとは考えられない。

情報の出し方として筋が悪い。


さらに、すでに書いたように、SNS でどんなに人気を得ても、WEB ページを検索上位に押し上げる力はない。

毎日更新、という労力を割いているが、このままでは後に何も残らないように思う。



労力を使うのであれば、まずは後に資産が残る WEB ページに力を入れるのがよいと思う。

その上で余力があるなら、 SNS で WEB ページの宣伝をするといいだろう。

WEB ページを更新しましたよ、こんな情報書いてますよ、という内容なら、フォローして情報を得る意味が出るからだ。

(もちろん、日々更新する情報が良い内容だというのが前提だ)



商売はレンタカーなのだが、そこは一番最後。

WEB で宣伝につなげることはあってもよいが、SNS では控えめにしたほうが良いだろう。


多くの人にとってレンタカーは日常には使わないもので、その話をされても面白くない。


それでも、サイトの検索順位が上位になれば、自然に商売ページの宣伝にもなる。




Instagram の記事は、島内の観光地などのきれいな写真が使われていて、見栄えが良い。

写真は、ご自身…もしくは、近い知り合いの撮られたものではないかと思う。

同じ写真を探しても、インターネットには見つからないオリジナルのようなので。


せっかく持っているこれらの美しい写真を使い、WEB ページの Blog 部分で記事を増やすと良いだろう。


Instagram の投稿では、写真は載せているのに、その写真に対する説明が、ほとんどない。

あるのは、レンタカー屋としての宣伝と、関連しそうな語句をハッシュタグにしたものだけだ。


挙句、フォロワーから「どこの写真ですか?」なんて質問が来ている。


質問が来るというのは、その情報を欲しがっている人がいる、ということだ。

本文中にその情報を書いておくのが望ましい。




全体に、読者が想定されているように思えないのが、一番の問題だ。

読んでくれる人を想定して、その人に届くような文章を書かないといけない。


商売に結び付きやすいのは、「伊豆大島の観光客」だろう。


だから、観光案内をするつもりで、先に挙げた伊豆大島の美しい写真を使って、その写真にまつわる情報を書いていく。

お店の情報なら、どういう料理が中心で、平均単価がいくらくらい、お勧めのメニューは何か、などが欲しい。


読者を想定しただけで、ずいぶんと良い内容になるはずだ。



想定読者は、サイト全体で一貫する必要はない。

記事ごとに想定読者が決まれば、それで構わない。


当たり前の話だけど、レンタカーの紹介ページは、車を借りる人が想定読者だ。

値段やタイプだけでなく、車種や装備がわかればうれしい。


情報はとにかくありがたいので、装備が「ない」のであっても、隠さず書いておいたほうが良い。




基本が守れていれば、どんな内容でも気軽に書いてもよいと思う。


先に書いたように、なにが検索に引っかかるかわからないから。

多くのテーマを書いておけば、どこかで誰かからリンクしてもらえるかもしれない。


自分の趣味があるなら、積極的に書こう。

それが商売と無関係でも、自分のよく知っていることなら記事も書きやすい。



もっとも、どのような文章を書くかは商売の姿勢にもかかわることなので、強要はできない。


商売とプライベートをキッチリ分けたい、という商売人もいる。

それができていないような商売人は信頼できない、というお客さんもいる。


そういう人たちにとっては、個人の日記のようなことが書かれている商売のページ、というのは許容できないかもしれない。


僕は正反対のタイプで、人柄が見えている、人間臭い人でないと、裏で何を考えているかわからない…と警戒してしまう。

そういう人は商売人として信用できない。


まぁ、どちらに転んでも、ちゃんとついてくる人はいるし、その人たち相手に商売もできる、ということだけど。

ここは、やりやすいほうで良いということだな。




話としては、以上。


いわゆる「SEO対策」としては、もっと細かな技術的なテクニックも多数ある。


でも、しつこく書くが、基本はリンクをもらうことだ。

そして、リンクをもらうためには、読んだ人が感心するような、いい情報を提示することだ。


「良い文章を書く」ではないことを忘れないように。

つたない文章だって、人に情報を伝えることはできる。


「特別な情報」ではないことも忘れないように。

個人の体験とかが「いい情報」であって、国家機密のような特別情報である必要はない。



こうした基本を忘れなければ、WEB サイトは誰でも作れるし、そこそこ人気が出る。

「そこそこ」よりも上を目指すには、もっと努力が必要なのだけど。



▲目次へ ⇒この記事のURL

関連ページ

WEBページの検索順位をあげる方法(2/2)【日記 18/10/06】

WEBページの検索順位をあげる方法(1/2)【日記 18/10/06】

別年同日の日記

03年 歩いてきました

10年 運動会

11年 ジュエルペット

13年 ジョン・ワーノックの誕生日(1940)

15年 特色印刷


申し訳ありませんが、現在意見投稿をできない状態にしています


戻る
トップページへ

-- share --

16000

-- follow --




- Reverse Link -