コンピュータの日記です

目次

2018-11-09 7 Billion Humans
2018-10-06 WEBページの検索順位をあげる方法(2/2)
2018-10-06 WEBページの検索順位をあげる方法(1/2)
2018-10-01 台風24号
2018-08-06 C言語で会話
2018-07-12 メモリアドレス
2018-07-04 続・Unity
2018-06-25 Unity
2018-06-12 ゲームの作り方
2018-06-11 スプラトゥーン2のフェス勝敗の確率
2018-04-24 Nexus 7 復活
2018-04-12 ロードランナー レガシー
2018-01-23 サターンポリゴンのゆがみ
2018-01-10 原初のプログラム
2017-12-20 無言電話(SIP SPAM)
2017-12-18 P10 plus に乗り換え
2017-12-13 0sim
2017-12-12 IP電話
2017-11-27 リロケータブル
2017-10-27 Android Chromeでスクロールがおかしくなるバグの原因と修正
 …同じテーマのほかの記事
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年 特色印刷


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

WEBページの検索順位をあげる方法(1/2)  2018-10-06 17:55:37  コンピュータ

▲目次へ ⇒この記事のURL

さて、先日夏の旅行記をまとめたのだが、この中に JS オートレンタカーという章がある。

伊豆大島で車を借りた、レンタカー屋さんだな。


このレンタカー屋さん、3か月前にオープンしたばかりで、まだあまり知られていない。

知ってもらう手段として WEB ページを作っているのだが、そもそも検索されない。

Twitter とフェイスブックで、何かしらの情報を毎日書くようにしているのだが、人が来ないという。


で、ページを検索上位に持っていくコツを話したのだけど…


旅行記には会話内容を書かなかった。旅行と関係ないから。

それどころか、その時実際話した内容も、時間がなくて全然詳細を教えられてない。



そこで、ちょうどいいケーススタディーとして、検索上位を目指すための方法を書いてみようと思う。


ただし、僕はSEO専門家ではない、と最初に断っておく。

SEOって、「検索エンジン最適化」の略語ね。検索サイトで、自分のページを上位に持ってくるテクニック。


僕はある程度 WEB 関連の仕事もしているし、SEO関連の知識も人よりあるとは思うが、素人にすぎない。

もしかしたら細かな話は間違えているかもしれない、と覚悟しておいてほしい。




まずは一般論から。


ここで言う検索エンジンとは、現状ではほぼ Google だ。

実際には他にもいろいろあるのだけど、使用頻度のシェアで Google が 3/4 を占めている。


そして、残りの 1/4 は、Google の「発明」した方法を真似たものだ。

各社工夫を凝らし、少しづつ違う特徴を持ってはいるものの、基本的な概念は変わらない。


ここでは、各社ごとに少しづつ違う特徴の部分まで踏み込むつもりはない。

また、Google ですら、時々細かな部分の計算方法を変える。これにも踏み込むつもりはない。


なぜなら、それらの部分に踏み込むのは、手間のわりに効果が少ないからだ。

目指すのは「今よりも検索されやすくする」ことであり、「世界でトップクラスを狙う」ことではない。



また、検索されるにしても、「どのような目的で検索されたいのか」という問題がある。

単に検索されやすくするのではなく、検索してきた人に対して何をやりたいのかによって、手法が細かく異なるのだ。


商品を売りたいECサイトなのか、記事で人を集めて広告収入を狙うサイトなのか、WEB 自体を広告媒体としたいのか。

商売っ気抜きにして、趣味で作ったサイトを見てほしい、という需要だってあるだろう。


最初にケーススタディーと書いたのはそのためで、目的を決めないと話が発散してしまい、無意味になるのだ。

ここでは伊豆大島のレンタカー屋さんとして、伊豆大島への観光を考えている人にお店の存在を知ってほしい、というのを最終ゴールと考えてみる。




▼検索され、読んでもらう


検索上位に来るためには、まず検索されなくてはならない。当たり前の話。

まずは、ここから考えていこう。


そもそも、検索エンジンは何をやっているのだろう?


「伊豆大島 レンタカー」と検索した時、検索エンジンは、伊豆大島のレンタカー屋さんを探しているわけではない。

単に、検索に使われた単語を含んでいるページを探しているだけだ。


逆に考えれば、検索に使用された単語を含んでいないページは、検索しても表示されない。

検索されるためには、多くの単語を含んでいるページを作る必要があるんだ。



文章を書くというのは大変な作業で、苦手としている人も多い。

だから、そもそも短い文章しか書けない Twitter とか、写真だけでいい Instagram とか、「文章を書かずに」交流できるサイトが流行する。


でも、多くの人に検索してもらうための武器は、文章なのだ。

文章をほとんど含まないページは、検索してもらえない。

文章が長ければ、そこに含まれる単語の種類も増え、より多くの検索に引っかかる。


◎長い文章を書こう



検索エンジンのプログラム的にはともかく、長すぎる記事は読みにくいのでは…という考えもある。

ほんの数年前は、だから記事は短いほうが良い、とされていた。


しかし、今はこの考え方は間違っているとされる。

検索エンジンは、やっぱり文章を相手にしている。長い文章のほうが検索されやすい。




とはいえ、どんなに長い文章を書こうとも、ありとあらゆる単語を含むことなんてできない。


そこは、文章の数でカバーしよう。ここでは、文章の数を「記事数」と表現することにする。


たくさんの記事を書けば、WEB サイト全体として使われる単語の数は増える。

多くの記事があることは、もっと重要な別の効果をもたらせてくれるのだけど、これはまた後で書こう。


◎たくさんの記事を書こう




もう一つ、大切なポイント。


検索エンジン最適化、なんて言っても、最終的に文章を読むのは人だ。機械ではない。


順位を上げるために、なんて小細工した文章は読みづらい。

誠実で読みやすい文章を心掛けるべきだ。



文章を読む人を想定して、その相手に伝わるように、情報を整理して書くこと。


読む人の想定って、結構大切。

伊豆大島に観光旅行に来る人、という想定をしただけでも、「観光客だから、大島のことに詳しくない」という前提が出来上がる。


じゃぁ、観光地の場所を教えても、土地勘がないからわかりにくい。

バスなら待ち時間含めてどれくらい、車なら街から何分くらい、ということも書くと、観光地に行ってみるかどうかの判断基準になる。


(ついでに、レンタカー借りたほうがいいよ、ってアピールもできるかもしれない)


情報を整理するというのは、こうした「対象読者に向けての」情報整理だ。

観光客だから必要な情報もあれば、観光客には不要な細かすぎる情報もある。

何が必要で、何が不要かを吟味しないといけない。


とはいえ、考えていても始まらない。一度文章を書いてみることだ。

そして、一回書き上げたらその文章を破棄して、もう一度書く、くらいの心構えだと良い文章が出来上がる。



文章を書きあげるって、自分の中で情報を整理しているということなのね。

でも、そこで書きあがった文章って、情報を整理しながら、同時に伝え方も考えていたものなので、実は出来が悪い。


もう一度書くと、頭の中で整理できている情報を、今度は「どう伝えよう」ということだけに集中できる。

こちらのほうが良い文章になる。


実は、さらにもう一度書くと、伝え方も決まった後なので、テンポよく読める文章にしようとか、また別の部分を改良できる。

書くたびに良い文章になる。


◎想定読者を決めて、その人に伝わるように情報を整理しよう




▼ページランク


では、検索に引っかかったとして、どうすれば上位に表示されるのだろう?

ここからいよいよ、上位表示のための話になる。


Google では、すべての WEB ページに、「ページランク」と呼ばれる点数をつけている。

これは順位を出すうえでの指標の一つに過ぎないのだが、とても重要な指標だ。

ページランクを上げることが上位表示の方法の一つになる。


ちなみに、ページランクは内部的な情報であり、現在非公開だ。

ページランクを上げるといっても、どのように上がっているかを確認する方法は、ない。



では、どうすればページランクが上がるのか。

これは、ある種の人気投票になっている。


投票権を持つのは、Blog などの WEB ページを作成している人。つまりは「情報発信」する能力のある人。


情報を受けるだけの人と、自分でも発信する人は、観点が違う。

発信する側の人は、情報をまとめることの難しさを知っている。


そして、それらの人が「良く情報がまとまっている」と思ったページに投票する。

投票方法は、自分が作っているページから、ほかのページをリンクすることだ。


リンクされる、というのが「投票された」ということで、ページランクが上がる。


ちなみに、リンクは1つ1票ではない。

ページランクが高いページからのリンクは得点が高く、低いページからのリンクは得点が低い。


ページランクが高いということは、多くの人が「良く情報がまとまっている」と感じているページだ。

作っている人の審美眼が高い、ともいえる。


そして、審美眼の高い人が選んだページというのは、それだけ良いページだと考えられるのだ。




リンクは HTML の基本的な機能だ。

HTML とただのワープロ文章の、決定的な違いだといってもよい。


だから、WEB ページにはリンクがたくさん使われている。

これを「投票」と考え、良質な文章を探す手掛かりにしよう、という発想。



実際の検索結果の表示位置は、ページランクだけでなく多くの要因によってきめられている。

しかし、ページランクは最も重要なものだ。



▼リンクを得る


ページランクを上げるのにリンクが必要だということはわかった。

では、運よくリンクされるのを待つ以外にないのだろうか?


まずは、自分のページから、自分のページをリンクしよう。

WEB サイトには、複数のページがある。そのページ間でリンクを作るのは自分でできることだ。


特にリンクを作らなくても、Wordpres などの CMS を使っていれば、トップページや各コーナーへのリンク、時系列で前後の記事へのリンクなどが作られるだろう。

しかし、それだけでなく、記事中でも関連記事などへのリンクを作るように心がける。


先に「たくさんの記事を書こう」と書いたが、それらの記事それぞれが投票権を持ち、サイト全体のページランクを上げることができる。

機械的に作られたリンクは票を均等に配分してしまうが、記事中のリンクにより濃淡を作ることができる。


多少なりともページランクが高くなった記事は、検索などで上位に表示されやすくなる。

そこが足掛かりになって、サイトに人が来てくれれば、外部からのリンクをもらうチャンスも増える。


◎自サイト内でのリンクを活用しよう




Google はちゃんと「サイト」を認識していて、同一サイト内でのリンクではそれほどページランクが上がらない。

これを「内部リンク」と呼ぶことにする。


他のサイトからリンクをもらった場合は、「外部リンク」だ。こちらのほうがページランクを上げる効果が高い。


サイト内のどこかのページが、外部リンクをもらったとする。

そのページはページランクが上昇するだろう。


すると、そのページからのリンクの価値は高くなり、内部リンクによりサイト内の他のページもページランクが上がる。

つまり、外部リンクをもらうと、もらったページだけでなく、周囲のページにまで波及効果が及ぶんだ。



ところで、SNS では自分のプロフィールを書くことができ、WEB ページの URL にリンクすることもできる。

こういう、自分で作り出せる「外部リンク」も活用すれば…と思うかもしれない。


実は、これはできない。

SNS や掲示板を提供している各社と、検索エンジンを作成している各社は、協議して「ユーザーが作ったリンク」を明示する方法を決めた。

こうしたリンクは、検索エンジンにはリンクとして認識されない。


そうしないと、気軽に自分に向けて外部リンクを作れてしまい、不正な順位操作が行われるからだ。

SNS への投稿に URL を入れた場合も同様だ。見た目の上ではリンクが出来上がるが、検索エンジンとしては外部リンクとみなさない。


SNS を使って宣伝…というのはよく聞く文句だし、間違っているとも言い難いのだが、検索上位を狙う、という点においては効果は低い。


◎ SNS には検索順位を上げる力はない




一般には、サイト内部でのテーマを絞り込むことが大切、ともされている。


記事を読んでくれた人がいたときに、同じテーマの記事がたくさんあれば、そちらも読んでくれるかもしれないから。

それで情報の宝庫だと感じれば、リンクしてくれるかもしれない。



…とはいえ、Wordpress とか使っていれば、適切なタグ・カテゴリづけで関連話題は簡単に探せる。

テーマは絞ったほうが良いかもしれないが、あまり窮屈に考えないで、書きたいことを書いてもよいと思う。


◎テーマは絞ったほうが良いが、窮屈に考える必要はない



ちなみに、広告収入目的で WEB ページを作ろうと考えている人は、テーマをちゃんと絞り込むこと。

窮屈に考える必要がない、というのは、広告収入目的ではない前提だ。


SEOとは違うので詳細は書かないけど、広告システムはサイトの内容に合わせた広告を出す。

テーマがしっかり絞れていないと、場違いな広告が出て、当然読者の興味を引くことができず、収入に繋がらない。



話が結構長くなってきたので、いったんここで区切ろう。


つづき



▲目次へ ⇒この記事のURL

関連ページ

WEBページの検索順位をあげる方法(2/2)【日記 18/10/06】

WEBページの検索順位をあげる方法(1/2)【日記 18/10/06】

別年同日の日記

03年 歩いてきました

10年 運動会

11年 ジュエルペット

13年 ジョン・ワーノックの誕生日(1940)

15年 特色印刷


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

台風24号  2018-10-01 11:26:21  コンピュータ 住まい 家族

▲目次へ ⇒この記事のURL

まずお詫び。


今朝未明、深夜1時40分ごろから、今朝7時20分ごろまで、当ページのサーバーが死んでました。



で、原因。

台風 24号は昨夜深夜に神奈川県に最接近し、大規模停電を引き起こしました。

我が家も停電しました。


停電は、深夜 0時半ごろに2分程度、その後復旧しても、再度2分程度の停電。

たしかもう一回くらい短い停電があった気もしますが、ともかく最終的には長期停電に入りました。


おそらくそこらじゅうで架線が切れ、そのたびに経路が切り替わって復旧、を繰り返したのだと思います。

ついにうちに通電する経路がなくなったのだろう…と想像しましたが、だからと言ってどうしようもない。


念のためにサーバーシャットダウンするか考えましたが、主に閲覧用のサーバーです。

書き込みが多くないなら、急に電源が落ちても被害は少ないはず。ジャーナルファイルシステムだし。


というわけで、ほっときました。



短い停電は、UPS (無停電電源装置)の働きで影響が出なかったのですが、さすがに長期停電は無理。

けっこな時間アラート音を響かせ、さすがにもうだめだ、と音が変わり、最後に電源断を知らせる音(断末魔)になって、静かになりました。


で、やっと静かになったので寝ました。



サーバーのログを見ると、1時40分ごろの動作を知らせるメッセージが最後でした。

なので、停止もそのころです。




朝5時半に起き、枕もとのスマホの充電状態を見て、まだ停電が続いていることを確認します。


停電の情報を調べよう…と思い、「神奈川」まで入れたら、Google さんが「神奈川 停電」とサジェスト。

サジェストされるくらい、大変なことになっている?


神奈川県全域で、17万戸が停電中だそうです。

あまりにも停電戸数が多いので、復旧にどれくらいかかるかは不明、とのこと。


起きてまずとった行動は、水を汲むことでした。

我が家は災害に備えて、30本くらいのペットボトルに水を汲み置きしていますが、普段から使うローリングストックです。

この時は、この数日で使った10本くらいが空でしたので、これに水を汲みました。


水道は、ポンプで水圧をかけていないと水が出ません。

このポンプは、通常は送電される電気で動いていますが、緊急時にも水の供給ができるように、水道局には非常用電源も備わっています。


でも、停電が長引いた場合はどうなるかわかりません。それが水を汲んだ理由です。




今日は中学生の長男は休みですが(理由は後述)、小学校はあります。

電気がないと料理はできませんが、幸い、食パンの買い置きがありました。


最悪の場合、これで朝ごはんにできます。

しかし、そもそもそんな大変な状況だと、休校になる可能性もあります。



庭に出ます。

自転車が全部倒れているのは、想像通りで問題ありません。


昨夜は想像を超える暴風雨だったので、わずかに開けてある車の窓から雨が入っていないか心配でした。

(日差しで車内が蒸れないように、ほんの少しだけ窓を開けているのです)


しかし、さすがにそれはありませんでした。


どの程度の雨か、実験してみようと思って置いといたバケツは、風で転がっていました。

雨は降るが風が当たりにくいような場所に置いていたのですが…


一晩立ったら雨水が満杯に…って予想していて、昨晩暴風になる前に、ある程度溜まっているのを確認していました。

水が入っているバケツを、風当たりが強くないところでひっくり返すのだから、暴風の強さがわかります。



で、庭にはさしたる被害なし。

朝刊が来ていたので取って室内に戻ります。


明け方なので室内は暗いです。当たり前ですが電灯はつきません。

窓から入る光で新聞を読んでいたら…


ピピッ て電子音がして、いろいろな家電が動作を開始します。

時計を見ると、6時25分ごろ。どうやら停電から復旧したようです。




そこからすぐに、サーバーの電源を入れに行きました。

普段サーバーにはディスプレイを接続していないので、十分な時間を待ってからアクセスしてみます。


…アクセスできません。


なにかトラブルが起きているようだ。ディスプレイとキーボードを接続してみます。

なんか、起動中に止まっているようだな。


リセットしてみます。

しばらくして、再起動に成功しました。


これは、家庭内用のサーバー。

仕事の実験などで使っているほか、家庭内の DNS などを受け持っています。

DNS が動き始めたので、家庭内の LAN が使えるようになりました。


でも、もう一台の公開用サーバーがリセットを繰り返しても起動しない。

なぜか、ディスプレイを接続しても画面が出ない。壊れたか?




仕方ないので一端リビングに戻ります。

7時15分。小学校あるから、子供に朝ご飯作らなくちゃ。


そしたら妻が「私朝ご飯作るから、サーバー復旧しておいでよ」と言ってくれました。


サーバーの前に戻ると、LAN のアクセスランプがちかちかしていました。

さっきは点いてなかったのに。


アクセスしてみると、問題なくアクセスできました。

ただ起動に長い時間がかかっていただけらしい。

fsck でも走っていたのかもしれません。



というわけで、サーバーは朝7時20分ごろには復旧しました。





さて、時系列がおかしいけど、昨日昼の話。

最初のほうに書いた、長男の中学校が休みの理由です。


長男の中学では、この週末文化祭でした。

金曜日は、文化祭行事の1つである、合唱祭。

小さいとはいえコンサートホールを借りて行うものです。


金曜日は、小学校はお休みでした。前週の土曜に運動会をやった、代休です。

そこで、この合唱は家族で見に行きました。(長男のクラスの部分だけですが)



土曜日は、文化祭の準備。そして日曜日は文化祭。

こちらも一般開放されるので、やはり家族で見に行きました。



で、この日曜日が問題なのですね。

台風が来る、とわかっているので、延期する場合と、延期はしないが時間短縮する場合の2通りの「特別スケジュール」が予定され、詳細は当日朝の判断まで引っ張ることになりました。


で、当日は「15時までの予定を13時までに繰り上げるが、決行」という判断に。


ところが、朝方降っていた雨はやみ、文化祭が始まる9時ごろには空は晴れます。

そのまま良い天気は続き、むしろ暑いくらいで…



内容は去年と同じく中二病で楽しかったです。


ちなみに、長男は自然科学部で、調べたものをポスター展示。

昨年は何かキノコ調べてたのだけど、今年は珍しい鳥を調べてました。


去年のキノコは、猛毒を持つものだったらしい。そして今年の鳥も猛毒を持つ鳥。

そうか、長男の興味を持つキーワードは、「猛毒」か。


…普通に調べものしてるな、と思ってたけど、長男もちゃんと中二病でした。



いい天気は、終了する13時まで続きました。


これなら普通にやっても大丈夫だったのでは、と思いますが、それは後知恵。

大型の台風が来ているのは事実ですし、早く切り上げた判断は正しいと思います。




この穏やかな天候は、18時ごろまで続きます。

台風だから、と冷凍コロッケを買ってきてあったのに、全然台風らしい気候ではない。

コロッケは揚げておいしく食べましたけど。


#いや、そもそも台風コロッケってそういうことではないだろう。



で、案外大丈夫だなー、って思っていたら、22時ごろから急に暴風雨になり、最初に書いた事態となるわけです。


ちなみに、雨雲レーダー画像をしょっちゅう見てましたけど、我が家のある鎌倉市付近がたまたま大丈夫だっただけで、神奈川県でも平塚のほうなどは凄い雨降ってました。



#当日 21時ごろ追記。

 神奈川県内はいまだ6万件以上の停電が続き、特に鎌倉の隣、藤沢ではいまだ 9200軒が復旧していないようです。

 鎌倉市でもいまだ 600軒が停電中。

 我が家は早朝に通電して助かりましたが、大変な台風でした。


▲目次へ ⇒この記事のURL

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

住まい

家族

関連ページ

停電【日記 18/10/11】

別年同日の日記

04年 挨拶

09年 爪

13年 KDDI発足日(2000)

15年 デイブ・アーンソン 誕生日(1947)


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

C言語で会話  2018-08-06 12:17:29  コンピュータ 業界記

▲目次へ ⇒この記事のURL

1998年の夏の暑い時期だったと思います。

韓国から、セガの下請けになった、というプログラマーが研修に来ました。



で、「教えてやって」と、僕に仕事が丸投げされました。

韓国語なんてわからない。英語すらできない。

そもそも、教えてやってと言われても、何を教えればいいのかも聞いてない。




当時の韓国の世相を説明しといた方がよさそうだな…


韓国は、1961年にクーデーターがおこり、軍事政権になっています。

軍事政権下では、国民の権利などは抑圧されていた一方で、強引な(一部の人を泣かせるような)政策によって経済成長も遂げています。


が、1979年に民主化デモがおこります。そして大統領暗殺。

これにより民主化が行われるか…と思われたのですが、1980年にふたたびクーデターがおこり、軍事政権は続きます。


それでも、経済的に急成長を遂げた韓国は、1988年のソウルオリンピック誘致に成功します。

しかし、1987年、再び民主化運動がおこり、IOC は「治安が維持できない場合は、オリンピックをロサンゼルスで行う」と決定。


軍事政権は、経済成長した韓国を、オリンピックで世界に誇示するつもりでした。

これは、軍事政権を続けるより重要なことでした。


そこで、民主化宣言を行います。

これにより軍事政権は終わりました。


1988年、ソウルオリンピックの年には海外の渡航も自由化されました。


これ以前は、日本と韓国の関係は冷たい物でした。

しかし、徐々に民間レベルでの交流は増えていきます。

韓国でも、同じアジアの発展した国として、日本にあこがれる若者が増え始めます。




軍事政権の時代には、娯楽は「不要なもの」という扱いでした。

テレビゲームも発売されていません。

(パソコンである MSX は発売されていましたし、そのゲームも売られていましたが)


1989年、「ファミコン」と「セガマスターシステム」のライセンス品が登場

ちなみに、スーファミは日本で 1990年登場。メガドライブは 1988年登場です。



「あこがれ」でもある日本のゲーム機は、家電各社が日本の会社からライセンスを取得し、製造・販売します。


直接日本のメーカーが輸出販売しないのは、日本企業が直接活動するのが許可されていなかったため。

民間レベルでの交流は増えていましたが、韓国と日本の関係はまだ冷たい物でした。



僕がセガに入社後も、いくつかのゲームの「韓国版」を作るのを見ています。

1996年くらいだと、テレビゲームはすっかり人気の商品で、業務用も売れていたのです。


ただし、厳しい決まりがあって、どこか一カ所でも日本語が入っていると、韓国での販売は許可されませんでした。

当時は、日本にあこがれる若者も多い一方で、反日の動きも強かったのです。


文字テキストなどを変えるだけでなく、画像なども細かくチェックして、とにかく日本語を完全になくさないといけません。

実は、こんな苦労をしてゲームを作っても、それほど売り上げがよかったわけでもないのです。


それでも韓国版を作ったのは、これから韓国が伸びそうな国だと考えられていたからでした。




そして、1997年。アジア通貨危機が起こります。


アジアの小さな国の経済は、欧米の強大な資本の前では簡単に翻弄されてしまいます。

欧米の投資家が、アジアの通貨を空売りし、売りが多いので値が下がったところで買戻す、というテクニックを使い、儲け始めたのです。


投資家が儲かるということは、「誰かが」損をしているということ。

その誰かが、この場合はアジアの小国でした。


具体的には、タイ、インドネシア、韓国。

マレーシア、フィリピン、香港もターゲットにされています。


さらに、直接のターゲットにされなかったものの、これらの国の不景気の影響で、中国、台湾、日本なども影響を受けています。



韓国では、経済が完全に破綻し、国際通貨基金(IMF)の管理下に入りました。

IMFにより、次々と、韓国内の巨大企業が解体されていきます。




…と、これが 1998年当時の韓国の様子。


この状態の韓国から、プログラマーが研修にやってきたのです。


ちなみに、上に書いた「当時の状況」ですが、当時の僕は認識してませんでした。

今調べて知ったの。


ただ、韓国ではゲームは結構人気ある、ということと、経済的に今なんかやばいらしいよ、程度には知っていたかな。


ちなみに、完全な余談だけど、日本と韓国の関係が急に改善するのは、2002年のワールドカップサッカー共同開催がきっかけ。

今でも日本を嫌っている韓国人、韓国を嫌っている日本人は多いのですが、総体としてはおおむね良好な関係だと思います。




さて、話を戻して韓国からの研修生のこと。

彼らは、韓国版のプリクラを作るために、フレームなどのデータを差し替える方法を学びに来たのでした。



プリクラは当時の大人気ゲーム。顔写真シール自販機ですね。

さまざまな「フレーム」がありました。プログラム内容は同じでも、画像などの差し替えでいくらでもバリエーションが増やせる、ということですね。


特に ST-V になったプリクラ2からは、このフレームにフルカラー画像を使えるようになったため、観光地の綺麗な風景をフレームにして写真を撮れるとか、大人気アイドルと並んでいるかのような写真が撮れるとか、多様な展開を始めていました。


#と書いていて思い出した。たしか当時大人気だった SMAP 版を作ったら、とんでもないインカムを叩き出したはず。

 5人それぞれが別バージョンで、並べられた5台それぞれが「朝から晩まで、途切れなく稼働」しないと出ない収入となった。



で、プリクラはアトラスの開発したゲームでしたが、販売はセガ。

例によって、業務用外注作品はAM1研を通しています。


そして、フレーム変更などのバージョン変更も、AM1研でもやっていました。


こうしたデータ差し替えはセガ…AM1研のほうでもやっていました。

このやり方を学びに来た、ということね。




えーと、僕はプリクラチームではないので、実際の作業内容は知りません。

でも、それ以前の「ST-V 開発機材の扱いに慣れる」部分から話を始めなくてはならず、そこなら確かに僕が教えられます。


プログラマの人は韓国語しか話せなかったのですが、一緒に来ていた営業の人が日本語が出来ました。

そこで、機材の説明、セッティング方法などは通訳してもらう形で、お二人に説明します。

たしか、セッティングは1日。


プリクラのソース一式を展開し、コンパイルし、開発機材で動かし、デバッガでメモリなどを覗く…

というのが翌日の作業じゃなかったかな。ここまでは順調。


さて、問題はここから後です。

「この後は技術的な話だから」と、営業の人は別の仕事でどこかに行ってしまいました。

韓国語しかわからないプログラマに、日本語しかわからない僕が、「フレーム画像の変更方法」を教えなくてはなりません。


そもそも、僕がやり方を判っていないので、プリクラチームの人に聞きます。

画像データをディレクトリにいれて、それをデータファイル化するツールを起動。

その後、データへのポインタをこの構造体に入れて、いくつのデータがあるかをこちらのメモリに入れて…という感じ。


で、いよいよ教えるのです。




韓国プログラマの隣に座って、UNIX のコマンドラインを操作します。


「あー…、ふれーむぴくちゃー、せっと、ぢす、でぃれくとり」


そういいながら僕が cd コマンドでディレクトリに入ると、プログラマがパス名をメモします。


「あんど、らん、ぢす、こまんど」


そういいながらデータファイル化するコマンドを実行すると、やはりそれをメモします。


「ちぇんじ、ぢす、ふぁいる」


構造体が書かれたファイルをテキストエディタで開くと、ファイル名をメモします。


「ちぇんじ、ぢす、でーた」


構造体にファイル名を書き込むと、構造体の名前をメモします。



一部始終こんな感じ。ブロークンイングリッシュと、C言語のファイルを見ながらの「ちぇんじ、ぢす」の連続。

向こうから質問が来るときも似た感じ。


でも、「プリクラのフレームを変更する方法を学びたい」という目的ははっきりしていますし、C言語はどちらも使える共通言語。

多少もどかしい部分はありましたが、実際にCのソースを書き換えて「ぢす」と言えば通じる。


ブロークンイングリッシュで、というよりは、C言語で会話していました。

set LANG=C です。




書き換え方法を学んだあと、実際に適当なデータを使って一通り作業をしてみて、その間にもわからないことがあれば質問を受け付けました。

結局、AM1研での研修は1週間程度ではなかったかな。


その後、「仕事のために借りたアパートで以降の作業を行う」というので、機材を貸し出す手続きをし、機材を持ってアパートを訪れました。


…驚きました。8畳程度のワンルームではなかったかな。

そこに、4人で生活していました。研修に来ていたプログラマーは「チーフ」で、部下が2人いたのね。


狭い中に4人分のパソコンがすでに置いてあり、さらに開発用の大きな機材を持ち込みます。

ここは「仕事場」ではなく、滞在中の住居でもあるそうです。夜になると機材の隙間に潜り込むように眠る。


夏で暑いのにクーラーもなく、扇風機が1台回っていました。



びっくりしていると、日本語のできる営業の人が


「日本物価高いですからネー、これでも出せる額ギリギリデス。

 彼らは本国ではエリートだから期待されてマス。

 日本で暮らすため、たくさんお金もらってマス」

とのこと。


期待されて、精いっぱい出してもらっても、冷房もないワンルームで4人暮らしがやっとなのです。

それでも、期待を背負ってきているので、一生懸命ゲーム作成のノウハウを吸収しようとしているのです。


このハングリー精神、今の日本では、とても真似できない、と思いました。


#ここでの「今」は、1998年当時のこと。




その後も、何度か、電話で質問に答えたりしていました。

日本語のできる営業の人経由だったと思います。あのプログラマーと電話越しに話せたとは思えないから。


しばらくして「一度韓国に戻ります」という連絡が来ました。

当時の韓国では就労ビザを取るのが厳しくて、観光ビザで日本に来ていたのだそうです。


で、さらに後に「また戻ってきました」という連絡。

それからしばらくして「ゲームが完成しましたので、韓国に帰ります」という連絡。


帰る前にお別れ会をやろう、ということになり、セガ近くの居酒屋で一緒に飲みました。


久しぶりに会ったプログラマーの人と、たどたどしい英語でゆっくり話をしました。

難しい話は出来ないのだけど…


日本の文化が大好きで、漫画とかも好きだけどゲームが特に好き、と言っていました。

でも、韓国では日本の文化は規制されていて、なかなか触れることができない。

今回の日本滞在では、色々見られてよかった、とも。


そして、ゲームが好きだから、いつかヒットゲームを作りたい、と言っていたと思います。

当時の韓国では、まだゲーム制作者という職業は珍しくて、大きな夢だったようですが。



今では、韓国はゲームの輸出大国です。もちろん、世界的なヒット作も出ています。

彼は夢をかなえられたのでしょうか?


▲目次へ ⇒この記事のURL

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

業界記

別年同日の日記

02年 富士山

05年 病名判明

13年 新記事投入と、「ニコ動」話のつづき

14年 Copyright 表記について


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

メモリアドレス  2018-07-12 18:07:43  コンピュータ

▲目次へ ⇒この記事のURL

先日、僕のページを参照しながらツイッターで話をしている人がいました。


#時々エゴサーチしてますよ


話の内容は、「コンピューターのメモリアドレスはいつから使われ始めたか」。

この話のきっかけが、僕が書いた「バベジの解析機関」の話だったのです。


実際はパンチカードは2組有り、1つはプログラムを、もう一つはデータを格納した変数を示します。これは、現在のコンピューターと違い、メモリに番地を割り振ると言うアイデアがなかったために、常に変数を指示する必要性があった事に由来します。


上は僕の書いた記事の抜粋。

もう20年も前に書いた記事なので、いま読むと恥ずかしい、説明不足な部分があります。


実際には、メモリは番号で区別されてはいます。

ただ、現代的な「アドレス」とはちょっと違うものなのです。


数学のアルゴリズムには、計算対象を変えながら、同じ計算を繰り返す、という操作は頻繁に現れます。


例えば、行列の掛け算とか。

「掛け算」なんて基本的なものなのに、計算対象を変えながら繰り返すという複雑な操作が必要なのです。




今のコンピューターは、プログラム内蔵式です。


プログラムはメモリに保存されていて、いま注目しているアドレスの命令を実行したら、注目している部分を次のアドレスにずらし、順次実行していきます。


しかし、バベジの解析機関は、プログラムはパンチカードで供給され、読み込みながら順次実行されました。

カード送り機構があり、次々と新しいカードが読み込まれるために、順次プログラムが実行されていきます。


そこに「アドレス」という概念はありません。

プログラム実行に、アドレスは必ずしも必要ないのです。



バベジの解析機関は、データ保持用のメモリ(バベジの用語では「ストア」)を多数持ち、プログラムで命令でデータの取り出し・保持が指定された際には、もう一組のカードから「使うべきメモリ」を読み込みました。


つまりは、使用するメモリは、プログラムとは独立していて変更可能です。

プログラムを「ループさせる」ことは可能だったので、適切に2組のカードを設定すれば、計算対象を変えながら行列計算を行うようなことも可能です。



しかし、このカードは変数が必要になるごとに読み込まれ、変数自体を計算によって求めるようなことはできません。


C言語風の書き方になりますが、


A1 + A2



A[1] + A[2]


の違い、と言えばわかってもらえるでしょうか。


前者の 1 2 は、区別するための記号にすぎません。連続した数値ではないのです。

しかし、後者の 1 2 は、記号ではなく数値です。連続したメモリの中の位置を示す「アドレス」です。



それぞれのやり方で、10個のデータの合計を求めようとすると、こうなります。


SUM = A1 + A2 + A3 + A4 + A5 + A6 + A7 + A8 + A9 + A10;


for(i=0;i<10;i++)SUM += A[i];



前者のやり方で、データが 100 個に増えたら大変です。

しかし後者なら、わずかな変更で対応できます。



もう少し根源的な言い方をすると、「アドレスが計算対象か否か」です。

コンピューターは計算のための道具ですが、その計算に使用するメモリのアドレスすら、計算の対象とできるかどうか。



メモリに区別のための番号が割り振られていたとしても、計算対象でない場合には、「アドレス」とは呼べないように思います。




ではいつからメモリにアドレスが割り振られたか、というと、実は話は簡単で、プログラムがメモリ内蔵型になった時だと思われます。


ENIAC(1946) は、配線によってプログラムを行いました。

そもそも、現代的な「プログラム」のイメージですらありません。


それ以前のハーバードマーク1(1944) では紙テープでプログラムを行いますが、まだアドレスの概念はありません。

データを保持できる場所…メモリと言っても差し支えない場所は 72個あるのですが、実はすべてが「カウンタ」で、それぞれがタイガー計算機だと思ってください。


タイガー計算機ですから、足し算・引き算だけ出来ます。

72個のカウンタの、どこからどこに足し合わせるか、というデータの流れをひたすら記述することがプログラムになります。


この 72 個は、番号で区別されていますが、ただの区別の記号です。

この番号を計算対象として、配列を実現するようなことはできません。




最初にメモリ内蔵型を提唱したのは EDVAC(1951) です。

この際に、「メモリには、プログラムとデータを一緒に入れてしまう」という決断をしています。


しかし、さすがにこの二つは別物だろう…ということで、1bit の区別フラグがつけられています。

プログラムからは、データを読み書きすることはできるのですが、プログラムを読み書きすることはできません。


EDVAC は命令を「5つ組」で示します。命令と、アドレス4つです。


アドレスは、演算対象となるデータが入っているアドレス2つ、結果格納アドレス、次の命令のアドレスです。



現代のコンピューターから見ると、「次の命令アドレス」が随分と奇異に見えます。

自動的に次のアドレスの命令を読み込むのではなく、いちいち次の命令のアドレスを指定する必要があるのです。


これは、「メモリに割り振られたアドレスは、識別用の記号であり、連続した数値ではない」という設計思想のためです。


もちろん、演算対象・結果格納用のアドレスも、連続した数値ではありえません。

ここには直接数値を入れてあり、アドレスと見なされるため、配列アクセスのように「アドレスを計算する」ことはできないのです。




EDVAC の設計論文を見て、先に完成させてしまったのは EDSAC(1949) です。

この際、回路を簡略化し、素早い完成を目指す中で、データとプログラムを区別するビットが省略されています。


これは、うっかり間違えてプログラムを破壊しないための、保護機構でした。

逆にいえば「うっかりミス」が無いように人間が注意すれば、機械として作りこむ必要はないと判断したのでしょう。


用意された命令は、EDSAC のものとそれほど変わりません。

ただし、「次の命令アドレス」は不要で、連続したメモリの命令を順次実行していきます。


おそらくは、「次の命令アドレス」を無くせばその分のメモリが不要になる、という簡略化のための判断です。

しかし、これにより「メモリアドレスは連続している」という設計思想が生まれています。


とはいえ、データアクセスの際には、固定値でアドレスを示します。計算できません。

これが当時としては標準的なやり方だったためです。



ところが、ここにうれしい誤算が生じます。

プログラムの保護機構を省略したことが、非常に柔軟なプログラムを可能にしていました。

保護機構が無いということは、プログラムもまた、同じメモリに置かれたデータに過ぎないということです。


プログラムの置かれた特定のアドレスを演算対象として、書き換えてしまえば…

アドレス部分を書き換え、「順次アクセスする」ようなプログラムが可能になるのです。



当初の設計に織り込まれたものではないとはいえ、手法に気づいたら積極的に利用した節があります。

プログラム自身を演算対象とできる…これはコンパイラなどが作れるということですし、実際簡易なアセンブラ兼ローダー兼 BIOS である「ブートローダー」が作られています。



EDSAC では、メモリアドレスを計算対象とし、配列演算ができるようになったのです。




蛇足ながら、EDSAC よりも完成の早かった、The Baby(1948) でもプログラムの自己書き換えは可能だったように思います。

しかし、これは実験機のため、極端にメモリが少ないマシンでした。


小さなプログラムを書いたらメモリいっぱいで、自己書き換えなどのテクニックを駆使して配列操作するような余裕はありません。


現代の CPU では、「レジスタに入っている数値をアドレスとしてメモリにアクセスする」というような機能があります。


レジスタは計算のための特殊メモリですから、この数値をアドレスとする、というのは、アドレスを計算対象とすることにほかなりません。

EDSAC では「自己書き換え」で実現されていた方法が、今では CPU の命令で普通に用意されているのです。



冒頭の話題に戻りましょう。

コンピューターのメモリアドレスはいつから使われ始めたか。


この質問の裏には「今のように」という観点があるでしょう。

その元祖は、EDSAC だと思います。



先に書いた通り、EDSAC とほぼ同時期のコンピューターでは、メモリアドレスを計算対象とは「しない」のが普通でした。

その中で異質だった EDSAC のやり方が現代に残っているのは、このやり方が非常に強力だと皆が認めたからでしょう。




2018.7.17 追記

ツイッターで、こちらの掲示板で同じ質問が出ていた、と教えていただきました。


話の冒頭で「先日」と書きましたが、6月下旬の話だったと思います。

その掲示板の日付は6月23日。


僕の該当ページも参照されていますし、1) ツイッターで話題にしていた人たちが質問した 2) この質問を読んだ人がツイッターで話題にしていた のどちらかではないかと思います。




掲示板でも、「ノイマン型あたりだろう」と正しい認識なのですが、「チューリングマシンから」と言っている人があまりにも的外れなので、ちょっと突っ込み入れたくなった次第。


チューリングマシンは、紙テープが最新のメディアだった時代の発想なので、基本的には「無限に長い紙テープに、検索キーとデータを書き込んでおく」という発想で考えられています。

いわば、キーバリューストア。アドレスはないです。


そもそも、今ではコンピューターの元祖のように言われていますが、もともとは「ゲーデルの不完全性定理」という、数学上の大問題を証明するための道具にすぎません。


ここら辺、詳しくは過去に書いたことがあるので、興味がある方はそちらをお読みください




▲目次へ ⇒この記事のURL

関連ページ

階差機関&解析機関

別年同日の日記

02年 納得?

15年 実装の苦労

16年 Chromebook購入

16年 Chromebook で子供ができること

17年 ジョージ・イーストマン 誕生日(1854)


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

続・Unity  2018-07-04 18:26:09  コンピュータ

▲目次へ ⇒この記事のURL

少し前に「Unityの勉強始めた」って話を書いた。


仕事とは無関係に、全くの趣味として。

でも、趣味なので週に2時間程度しか時間を割けず、遅々として進んでいなかった。




今日、時々仕事でプログラム保守をしている会社の人と、打ち合わせ会議があった。


保守しているプログラム、見ず知らずの前任者が作ったものから、求めに応じて僕が随分と拡張している。

WEB 上で動作する Javascript のシステムなのだけど、前任者は「その時の仕様」でうまく動くように、非常に美しいプログラムを組み上げていた。


…美しい、というのは良いことばかりではない。

当時の仕様での動作としては問題ないのだけど、後から手を加えようとした時に改造しにくかったのだ。


ネットワークからデータを受けて表示するプログラムだったのだけど、無駄が排除されていて、受け取ったデータを集計し、表示した後はデータを残していなかった。


これが、後から「操作によってデータの絞り込み表示とかできると良い」という話になった時に、データが残っていないのだ。

仕方なく、根幹部分での「データ集計」は残したまま、送られてきたデータを溜めておく別部分を作り、絞り込みの際には別途集計を行って、それまで表示していたデータを「リセット」して、集計したデータを今送られてきたように流し込んで…


という、複雑怪奇なプログラムになっていた。


#根本部分から作り直せばいいのだけど、それができない理由があった。


このプログラム、どこかで根本的に手を入れないと、今後の拡張難しくなっていきますねー、なんて話を以前にしていた。




実は、僕は「WEB 表示部分」を作っていたのだけど、システム全体としては、別の人が作った Android アプリと iOS アプリもあった。

さらに、別用途で使われる Windows アプリもあった。


目的が違うものなので画面なども違うのだけど、表示される内容は同じ…にしたいのだけど、少しづつ違って同じになっていない。



で、今回、「すべて Unity で作り直せないか」という相談。


各種表示プログラムがあるわけだけど、今一番使われているのは僕が作っていた WEB 画面なのだそうで、これをベースにして Unity で作り直したいらしい。


Unity なら、iOS / Android / Windows / MacOS / WEB など、各種環境向けにコンパイルできる。

それぞれに必要な UI などは微妙に異なるが、共通化できる部分は出来るだけ共通化していきたい、という意向らしい。



で、「Unity 使えますか?」と聞かれたわけだ。


ごめんなさい。使えません。

でも、ちょうどいま勉強中で、勉強のためにゲーム一本作ってみている最中でした。




そんなわけで、趣味でやっていただけだったのだけど、ちょっと勉強を急がなくてはならない状態。

今日は会議後、5時間ほど作業していた。


まだ「上から3つ並んだ宝石が落ちてくるだけ」だったプログラムが、「フィールドの配列を持ち、落ちてきた宝石が積み上がり、それらの宝石に落ちてくる宝石がぶつかると通り抜けられないような判定」までは出来た。


これを作ることが目的ではないのだけど、ゲーム一本仕上げるのって、ある程度システムを理解していないとできないからね。

実践的な勉強、というつもり。


実際に作り直すとしても、おそらくは秋から作業開始になるようだ。

その時に備えて「API マニュアルと首っ引き」でないとプログラムできない今の状態から脱出したいところ。



▲目次へ ⇒この記事のURL

別年同日の日記

04年 コンサート

13年 Mouse In Maze


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

Unity  2018-06-25 17:50:23  コンピュータ

▲目次へ ⇒この記事のURL

最近 Unity を触ってみている。


「使ってみた」的な記事が流行したのはもう何年も前の話で、そろそろ Unity を使うのは「ゲームプログラマなら当たり前」になりつつある。


でも、僕は仕事柄、興味は持っていても Unity に触る機会が無かった。

ゲームプログラマじゃなくて、WEB プログラマだったから。




セガ時代に一緒にゲームを作った友人と会うと、「Unity やらないの?」的なことをたびたび言われた。

そいつも今はゲーム以外の仕事をしているのだけど、時々無性にゲームが作りたくなるので、なんか一緒に作ろうよ、って。


僕もゲームを作りたいと思うことはあるのだけど、なかなか暇がないのだな。

それで Unity に興味はあっても、手を出せずにいた。


でも、先日書いたように、仕事にしていた柱の一つを辞めることにしたので、少し時間に余裕ができた。

元々時間比率は少なくなっていたので、それほど暇になるわけでもないのだけど、ちょっと気になっていた Unity をインストールし、触り始めてみたというところだ。




ファーストインプレッションとしては、「売り物品質のゲームを作れる Scratch」というものだ。


Scratch は「あんなの本物のプログラム言語じゃない」と強烈な拒否層がいる環境なのだけど、Unity を使ってみた第一印象は Scratch と凄く似ている、というものだった。


これは、Unity を低く見ているのではないよ。

僕は Scratch を非常に高く評価している。

それが、結構多くのプログラマに支持されている Unity と類似だということに感心したのだ。


Unity は絶賛している人も多いのに。

Scratch は拒否感を持つ人も多いのに。


でも、両方使ってみると、非常によく似ていることがわかる。

どちらかといえば、Scratch で批判されている部分…データ調整だけでそれらしい形が作れてしまうので、「あんなのプログラムじゃない」と言われる部分を、さらに推し進めたのが Unity 、という言う印象だ。



とはいえ、どちらかが真似をしたというようなものではなく、自然な流れだと思う。

あえて言うなら、NeXT の Interface Builder とか、Win3.1 のころの VisualBasic が源流にあるだろう。


VB などは、GUI 時代の「アプリケーション」を作りやすいようにした環境だったのだけど、それをゲームに特化し、用途を限定することで扱いやすくしたのが Scratch と Unity 、という感じ。


どちらも、時間管理の概念をシステムで持っていて、個々の要素について、独立して「時間による変化」をプログラムしていけば、全体を構成できるようになっている。



もちろん、ゲームを「作りやすいように」特化したというだけで、ゲーム専用ではない。

画像表示を伴うインタラクティブなものなら守備範囲。

これって、結構応用範囲が広い。




とはいえ、まだ本当に「触ってみている」程度の段階。


せっかくなので、3Dでいくつか試作して、動作と「プログラミング作法」に慣れてみた。


最初はピンボール的なものを作ろうとして、3Dのモデラが無いと曲線などが作れないことに気付いて辞め、ビリヤードに変更した。


ビリヤードも、ちゃんとしたものを作るのは難しいので、適当に玉ががんがんはじかれているのを見て「気持ちいい」って感じただけ。


普通の言語で、物理エンジンを利用した3Dプログラムをしようと思うと、たとえライブラリを使っていてもそれなりに面倒くさい。

Unity なら画面を見ながらパラメーター設定するだけで、大体の枠組みが出来上がってしまう。

後は、どうしても必要なプログラムをちょっと作るだけ。


で、適当にゲームにもならないものを作り散らかした後で、やっぱり僕は2Dゲームのほうが好きなので、コラムスなど作り始めてみている。


本当はこれが完成してから「Unity いじってみた」って記事を書こうと思っていたのだけど、本格的に作り始めたら、やっぱりすぐには完成しない。


Scratch よりも若干生産性が落ちる感じだ。

もっとも、Scratch は不得意な処理を書く際にはとことん面倒くさいが、Unity 環境のほうが不得意部分が少ない。

生産性が落ちるのは、単に「あれもこれもできてしまうので、あきらめどころがわからなくて頑張ってしまう」結果による。



なお、コラムスが完成するかどうかは不明。途中で飽きるかもしれない。

まぁ、僕にとってはコラムス作るのは Hello World みたいなもんなので。



▲目次へ ⇒この記事のURL

関連ページ

続・Unity【日記 18/07/04】

別年同日の日記

02年 細胞が覚える味

04年 またですか

08年 やっと見つけた

09年 ペットロス

12年 土用に鰻を食べる理由


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

ゲームの作り方  2018-06-12 15:39:31  コンピュータ 家族

▲目次へ ⇒この記事のURL

最近は次女(小3)が熱心に Scratch をやっている。


長男(中2)も相変わらずやっているのだけど、学校に塾にと忙しくなかなか時間が取れないし、わずかな時間でスプラ2も遊びたい。

でも、時々急に「プログラム作りたい!」ってなって、短時間でそれなりに面白いものを作り、満足している。


長女(小5)は、長男も次女も Scratch をやっているのでやりたいと思っているようだが、二人にパソコンを取られてしまう形であまりやらない。

というか、どちらかというと時間があるならスプラ2か、DS の「どうぶつの森」をやってしまう。

パソコンを開くときもあるが、他の人がスプラ2を遊んでいて、ぶつ森でもすでにやることがない、というような場合だけだ。




いきなり話がわき道にそれているが、次女の話なのだ。

まだ論理性が怪しいながらも、プログラムの技術は覚えつつあり、どういうときにはどういう命令の組み合わせ、というのはすぐに出てくるようになっている。


そして、次のステップでつまづいた。

プログラムは作れる。じゃぁ、いったい何を作ればいいのだろう?

ある程度プログラムを覚えた初級者が、必ずぶつかる壁だ。



先日、新聞に Scratch の記事が出ていた。

そこには、取材したワークショップで、子供が簡単なゲームを作ったということと、そのゲーム画面、プログラムの一部が出ていた。


「これ作ってみる」と言って次女は作る。

プログラムが載っていない部分に関しては、画面を見ながら想像で。


ネズミを操作して、ネコから逃げながらチーズを目指す、というゲームが完成した。

ネコの動きルーチンを作れるほどの技術はないので、二人対戦だ。ちゃんと動くようになって喜んでいる。


でも、ネコを動かす人が本気を出すと、絶対にネズミが負けてしまう。

そこでネズミの速度を上げたが、今度は絶対にネコが追い付けない。


一応勝ち負けがあってゲームのプログラムにはなっているのだけど、「面白くない」という致命的な問題があるのだ。




「どうすればいい?」と聞いてくる次女。

ゲームを面白くする方法だったら、いくらでも思いつく。

しかし、そのアイディアを僕が出すわけにはいかない。


僕がアイディアを出して、それをプログラムするのであれば「技術は」上がるだろう。

でも、プログラム学習っていうのは技術訓練ではないのだ。



ここで考えないといけないのは「ゲームを面白くする方法」なんかじゃない。

そんな漠然としたものを考えていても、何も思いつかない。


そこで「何がつまらないのだと思う?」と聞いてみる。

自分の作ったものを「つまらない」と認めるのは勇気がいることだ。


最初のうちは、次女は「ちゃんとゲームになっているから、つまらないところはない」とか言い訳していた。

でも、ついには「絶対ネズミが勝っちゃう」と認めた。


何でそうなるのだろう? と聞くと、チーズに向かって一直線に進むと、ネコが追い付けない、との答え。

じゃぁ、その部分をどうにかしてみれば? と言ってみる。


しばらく考えて、「チーズは最初ランダムな位置に置かれるが、見えない。近づくと見えるようになる」というプログラムを作ってきた。

ネズミはチーズを探すためにうろうろする必要があり、探している間にネコが勝つチャンスもあるかもしれない、という考え。

なるほど、悪くない改良だ。


…でも、面白くなかった。

画面の広さは有限で、近づきさえすればチーズは表示されるのだから、ネコから逃げつつも画面をじぐざぐに進むと効率よく発見できてしまう。



今度も、何が面白くないのか考え、「自由に動けるのがよくない」という結論にたどり着く。


壁を設置して、ぶつかったらスタート地点に戻される、というプログラムを追加した。

壁はある程度ランダム位置に置かれるが、ネコもネズミも影響を受ける。



この「ぶつかったら」の判定は、ちょっと納得のいかないものだった。

Scratch で単純にあたり判定を行うと、絵の透明ではない部分がわずかでも重なると「ぶつかった」判定になり、厳しすぎるのだ。


でも、ゲームとしてはどちらが勝つか予測のつかないものになった。

これ以上掘り下げるのは本人の技術力を超えそうなので、改良点が見つからなかったら完成でいいんじゃない? ってことにする。




ひとつゲームが完成したので、今度は「風船が出てきて、クリックして割るゲーム」を作り始めた。


実は、先のゲームを作る際に参考した画面に、風船が出ていたのね。

元々なんで風船を出していたのかは知らないけど、次女は「ゴールすると風船が下から上にたくさん飛んでいく」という演出として取り入れていた。


今度は、この風船をクリックするゲームにしたい、というわけだ。



まずは、ランダムな位置に、ランダムな大きさの風船が出るようにした。


最初は1秒ごとに追加されたけど、早すぎて画面が埋まってしまう、と5秒ごとにした。

でも、それでは遅すぎるからと、「最初は5秒で、以降 0.5秒づつ早く」表示されるようにした。


お約束の、最終的に 0秒ですごい勢いで表示されてしまう、というのを経験して、最高速度を1秒に制限。


「なんかゲームっぽくなった」とご満悦なのだけど、何か物足りないらしい。

クリックするごとに1点追加で点数表示つける、とかやり始めたのだけど、風呂入る時間になったのでひとまず終了。



長女、次女、妻がお風呂入りながら話をしている。僕はその間食器洗ってたのだけど、少し話声が聞こえる。

どうやったら面白いゲームになるか、という話。詳しくは後でお父さんに聞いてごらん、とか言っている。




で、風呂上がりに妻から質問。

ゲームを面白くする4要素、物真似と競争とめまいと…後何だっけ?


後の一つは「運」だね。

面白くする、というより、すべての遊びはその4要素に分解できる、という話。

面白いゲームを分解して考えるのは勉強になるけど、4要素を知っているから面白いゲームが作れるわけではない。


子供の知っているゲームで解説する。


ぶつ森は生活を楽しむごっこ遊びで、物真似。

スプラ2は勝ちを目指すゲームで、競争。

テトリスやぷよぷよは、ランダムなブロックをどう組み合わせていくか考える、運。

メイド・イン・ワリオは、次々と目まぐるしく変わるゲームのルールを楽しむ、めまい。


もちろん、ゲームのすべてが1つの要素で作られているわけではなくて、いろんな要素が組み合わさっている。

そう解説したら、すぐに長女から「ぶつ森では、住民にすぐに『魚釣りで勝負だ』とか言われる」と具体例が出た。

そうだね、それは競争が入ることでゲームらしくしている。


ゲームらしく、というのが大切で、この4要素はあくまでも「あそびの」要素に過ぎない。

ゲームは勝敗がつくことが必須条件なので、競争が必ず入る。


トランプの一人遊びの場合、運との勝負で「成功・失敗」になるけど、これだって勝敗のある競争だ。

競争がないものをゲームとは呼ばない。



ぶつ森は突発的に競争が起きることがあるけど、全体としてはゲームの要素を満たしていない、と知り、軽い衝撃を受ける長女。




僕は、ゲームを考える時に「目的」と「目的を邪魔するもの」で考える。

目的があるけど、簡単には達成できないとなれば、これだけでゲームが成立する


先ほどまで次女が作っていた、風船をクリックして割るゲーム。

「風船を割る」という目的はあるが、それを邪魔するものがない。


どうしたらいいだろう? というと、次女は風船が上に上がっていくようにしたいらしい。

最初に書いたけど、もともとそういうゲームを考えていたからね。


そして、単に風船を割った数ではなく、点数をつけたいのだそうだ。

クリックしづらい、小さくて動きの速い風船は高得点。


考えていたのはここまでだったみたいなのだけど、邪魔が必要と言われて「時間切れまでに何点取れるか」というアイディアを出した。


なるほど、ここでは「高得点」が目的となり、「時間」が邪魔するものとなる。



長女は、触ったらダメなものを出したらどうかという。

風船をクリックしていくのだけど、時々マウスカーソルが触れただけでゲームオーバーになるものを出す。


なるほど、その場合は「触ったらダメなもの」が邪魔するものになる。




最後にまとめ。


ゲームを作る時に決まった方法はない。

思うがままに、目的と、その目的を邪魔するものを設置すればいい。

それでとりあえずゲームになる。


でも、面白いかどうかは別問題。


どうすれば面白くなるだろう…なんて考えてもうまくいかない。

「つまらないところ」を見つけて、なんでつまらないのかを考える。


なんでつまらないのか、がわかれば、それを解消する方法も思いつく。

これを繰り返せば、ゲームは面白くなっていく。


途中で「あそびの4要素」の話を挙げたけど、入れたからと言って面白くなんてならない。

でも、面白くするためのアイディアの引き出し、くらいには役立つ。

いろんなゲームを遊んでみて、面白いと思う部分の要素を分解してみよう。




作っているゲームがある程度形になったら、「完成」ってことにして、次のゲームを作り始めるもの大切。

同じものを作り続けていると飽きるし、だんだん改良の「成果」よりも、「手間」のほうが大きくなっていく。


それよりも、どんどん新しいものにチャレンジしてみる。

たくさん作りちらかしていれば、時々とても面白いアイディアが出てくる。


初心者の内は、思いつくままに、たくさん作ってみるのがいい。

そうすれば技術も上がるし、どうすれば面白いかもわかってくる。




▲目次へ ⇒この記事のURL

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

家族

別年同日の日記

02年 OSアップデート!!

05年 夏至祭

15年 生卵と生豚と

17年 連乗機能


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

スプラトゥーン2のフェス勝敗の確率  2018-06-11 11:57:46  コンピュータ

▲目次へ ⇒この記事のURL

時々スプラ2のフェスの話を書いているのだけど、今回は勝敗結果の話。

ありていに言えば「結果がおかしい。対戦が正しく行われていないのでは?」という内容。




話を始める前に、スプラ2のフェスを詳しく知らない人のためにざっくりと解説。


スプラトゥーン2は、オンラインの対戦バトルゲームです。

4対4で、水鉄砲を持って戦います。


この手のゲームは「殺し合い」で勝負するものが多いのですが、スプラトゥーンシリーズは「陣取り合戦」です。

水鉄砲(「インク」を撃つことになっています)で相手を撃ち倒してもいいけど、最終的な勝敗は、自分のチームの色に塗った面積で競われます。


だから、必ずしも相手を殺すことが勝敗に結びつかず、逃げ回っていてもチームに貢献できます。

対戦ゲームが苦手な、僕ような人でも楽しめるゲームです。



で、時々「フェス」と呼ばれるイベントが開催されます。

あらかじめ、2択の質問で2グループに分けられ、そのグループ同士で対戦するのです。


この対戦も、1人で参加した人をランダムに組み合わせる「ソロ」と、2人、または4人であらかじめチームを組んで参加する「チーム」の2つの参加枠があります。


さて、フェスの「勝敗結果」ですが、24時間続けられるフェスの後に、得票率、ソロ戦の勝敗率、チーム戦の勝敗率、の3つで評価され、2つ以上の率が高かった方が勝者となります。


2018.9.21 追記


9月23日開催の第16回フェスから、ルールが大幅変更となりました。

ソロ・チームという区分はなくなり、レギュラー・チャレンジとなります。

また、勝率で勝負するのではなく、対戦によって獲得されるポイント合計で勝負するようになりました。


以下のこの日記の趣旨は、日記執筆時点でのフェスルールは破綻していて、多少の調整でどうにかなるものでもなく、任天堂も困っているのだろう、というものでした。

それに対する回答がルール大幅改定なのだと思います。


この日記は情報としての意味を失ったわけですが、日記ですので書いた時点での事実として残しておきます。



過去の戦績をここで書こうかと思ったけど、このページの趣旨ではないし、まとめている人もいるので他のサイトに譲ります




今日の話は、この「結果」に、おかしいくらいの偏りがある、ということ。


ゲーム中では、ナビゲート役として、ゲーム内の「アイドルバンド」である2人組、ヒメとイイダが登場します。

フェスの時には、それぞれが各チームを代表する形になります。


それぞれの過去の勝敗結果は公表されています。

昨日の第13回までで、ヒメ5勝、イイダ8勝です。


ネットでは「イイダの勝率が高い」ことに着目し、常にイイダに投票する、と宣言する人も出ています。


勝率…高いと言えば高い。でも、この程度なら誤差範囲のようにも思います。



実は、ヒメかイイダかというより、冷静に成績を見ると「得票率の少数派の勝率がやたらと高い」です。


少数派9勝、多数派4勝です。



フェス前のアンケートでは、2択を選択するためのカーソルが、最初は「ヒメ」側についています。

どっちでもいいや、という人はヒメに入れやすいのかな、と思います。

だから、ヒメが多数派になり、負けてしまうことが多い。


「イイダ派が強い」ではなく、「少数派が強い」のですね。



でも、これでも先ほどと1勝しか変わっていない。

2倍の差となると誤差と言いづらくなりますが、サンプル数も少ないですし、まだ決定的ではないように思います。




では、多数派が勝った4回を詳細に見ましょう。


そのうち3回は、ソロ戦を多数派が勝ち、チーム戦は少数派が勝っています。

得票率での勝ちと合わせて「多数派の勝ち」となりました。


残る1回は、ソロ戦もチーム戦も、多数派が勝利した「完全勝利」です。


実は、「多数派がチーム戦で勝利した」のは、この1回のみです。



少数派が勝った9回の内容は、すべて「ソロ戦・チーム戦とも少数派の勝ち」です。

得票率で負けているのですから、これ以外では少数派の勝ちになりません。



というわけで、ソロ戦・チーム戦の通算では、少数派が21勝、多数派は5勝です。


少数派は、多数派の4倍も対戦で勝っている。

ここまで違うと「誤差」で済ませられるものではなく、有意な差があると考えてよいかと思います。




先に書いた通り、マッチングは基本的に「同じくらいの強さの人」を集めて行われます。

そのため、勝負は五分五分。片方が4倍も勝つ、なんてことが起こるはずはありません。


結果発表の勝率を見ると、戦績は僅差です。

具体的に…7回終了時点までで、一番の勝率が 51.34% です。

多くは、勝っている側でも 50.xx% という小数点以下の勝負で、一番の僅差の時は 50.04% での「勝ち」でした。



これが、8回目で少し崩れます。

7回までの戦績が偏ってしまっていて、イイダが連勝していること自体を、フェス前の予告のネタにしていました。

そして、ヒメが ソロ 51.50% 、チーム 51.51% で勝利するのです。


それまで決して出ることのなかった、半数(50%)を 1.5% 超える差での勝利。

それを、あらかじめ予告したタイミングで、ソロ・チームとも叩き出す。


おそらくは、ここは運営側で調整が入り、マッチングが少し変わったのだと思っています。



このあと、9回目ではゆり戻しが来たように僅差の勝負となり、10回目でたった1度の「多数派の完全勝利」。

この時は、チーム戦で 52.25% という高い勝率が出ています。



そのあとの11回目、大騒ぎとなった「マッチングバグのあるフェス」となりました。

本来、同じくらいの実力の人がマッチングされるはずなのに、大きく実力差のある人が組み合わせられます。


阿鼻叫喚、としか言いようのない一方的な試合が繰り返されました。

このような試合では、負けた側はもちろん、勝った側もあまり楽しめません。


後に任天堂公式に「バグがあった」ことの謝罪が出るのですが、この時も少数派が勝ち、 54.39% という高い勝率が出ています。

その後、現在のところフェスは2回行われていますが、元に戻す努力があったようで、あまり大きな勝率の差は出ていません。



#書いてから気づいたけど、ゲーム中は勝率を小数点以下まで出してなかった。

 先にリンクしたページを見ても、細かなことはわからない。

 連動したスマホアプリを使うと、小数点以下まで確認できる。




さて、この話は「任天堂が手ごころを加えている」とか、そういう話ではありません。

ゲームとしては同じ実力の人が真剣に戦うから面白いのですし、任天堂もマッチングシステムで、できるだけそうなるように努力しているように見えます。


にもかかわらず、差が出ている。

おそらく一番困っているのは任天堂の人で、修整のための努力を続けているのに「なぜか」治らない…というように見えます。



スプラ1は遊んでいないのでよく知らないのですが、勝率もソロとチームを特に分けておらず、別の集計方法で勝敗を決めていたようです。

つまり、今のフェスのシステムは、純粋に13回しか遊ばれていません。調整をするにしても、十分な機会がまだ得られていない、とも言えます。




マッチングで使用される「同じ強さ」の指標としては、過去何戦かでの、チームの勝敗、その時のチームの平均強さの格差(格上に勝つようならかなり強いと考えられる)、殺した数、殺された数、塗り面積…などなど、ありとあらゆる、計測できる要素が使用されているように見えます。


また、スプラトゥーンは非常に「ブキ」の種類が多いゲームで、ブキ同士の相性もあります。

同じ強さをマッチングしたとしても、相性が悪ければ勝負になりません。


ですから、マッチングの際には同じタイプのブキがチームに偏らないように、かつ、対戦チームも同じようなブキ構成になるように…というようなことをインタビューで答えていたように思います。


とはいえ、マッチングの際にあまり万全を期して、ユーザーを待たせるようではいけません。

来るかどうかわからないユーザーを待つ「完璧な解」よりも、今いるユーザーで妥協して早くゲームを始める方が良いのです。



フェスの際には、「所属するグループ」も考慮する必要があります。

ただでさえ、難しい条件をできるだけ満たすような組み合わせを見つけないといけないのに、2グループに分かれることで組み合わせに「使える」素材が、半分になってしまうのです。




こうした複雑な事情をすべて潜り抜け、なんとかフェスを成立させた先にあるのが、「なぜか少数派が強い」という現象なのかな…と思っています。

システムが複雑すぎるので、何が起きているのか、当の任天堂運営チームにもわからない。


それを何とか修正しようと実験するうちに、バランスを大きく崩してしまったり、「マッチングバグ」を引き起こしてしまったりしているのではないかと。



マッチングバグは、多数解決しないといけない制限の中の「同じくらいの強さの人を組み合わせる」という部分を緩くした結果ではないかな…

と思っています。

同じくらい、というのが難しくて、少し緩くすれば組み合わせやすくなる、と考えてやってみたら、ひどい結果になった。


で、今は「同じタイプのブキがチームに偏らないように」という部分を緩くしているように思います。

昨日のフェスは、ローラー多数対チャージャー多数、みたいなひどい組み合わせがあって、あまり楽しめなかった。


(ローラーはチャージャーのカモです。ただし、誰かがチャージャーを倒してくれれば、ローラーが一気に塗りつぶして勝利できます。

 ローラー多数対チャージャー多数では、一方的なゲームになってしまい楽しめません)




先に、少数派が勝ちやすいのは任天堂も理由がわからないのでは…と書きましたが、「わかっていて、故意にそうしている」可能性もあります。


というのも、投票が偏りすぎて多数派と少数派の人数が偏りすぎると、そもそも対戦のマッチングがしにくくなり、試合不成立が増えてしまうためです。


#一応、同じグループ同士の対戦が発生するので、ゲームは遊べる。

 でも、結果はそのグループの「一勝一敗」になるので、最終戦績には関係がない。


これが、「少数派に所属すれば勝てる」と噂されれば、アンケート時点で「どちらが少数派になるか」を予想して投票してくる人が現れ始めます。

読みが当たるかどうかはともかく、この結果少数派の人数が増えれば、少数派と多数派の人数差は少なくなり、試合が成立するようになります。



だとすれば、すでにこの効果は出ているように思います。

ここまで「読んで」遊ぶのは、勝ちにこだわるガチ勢だけなので、少数派側にガチ勢が大量に流れ込んで強さを底上げしている…という可能性もあるのです。



昨日のフェスでは、僕は少数派に属していました。

昼間遊んでいて、グループ内の対戦にはなりませんでした。

(少数派は、多数派とのマッチングが成立しやすい)


しかし、夜中に遊んでいた妻によれば、夜中は少数派にもかかわらずグループ内対戦が多かったそうなのです。

夜中でも寝ずに遊んでいる人はガチ勢が多いと仮定すると、夜中はむしろ少数派と多数派の人数比率が逆転している可能性があります。



また、バグありだった11回目、少数派は非常に高い勝率で勝ちました。


マッチングが単に「バグ」だったのなら、少数派だけが高い勝率に…とはならないはず。

でも、少数派に強い人が多く、その分多数派に弱い人が多くなったとしましょう。


ここでバグが出て、強さと関係なくランダムに組み合わされたとしたら…

当然、少数派が勝つ試合が増えるはずです。


これも、すでに少数派にガチ勢が流れ込んでいると考える根拠です。



マッチングは、本来「同じくらいの強さの人」で行われます。

でも、全く同じということは難しいですし、少数派に強い人が多いのであれば、常に少数派が「ちょっと強い」試合が多くなってしまうかもしれません。


システム的には、なんの手ごころも加えずに五分五分の勝負になるようにしていたとしても、実はガチ勢によって前提が崩れていたら…


任天堂が調整を繰り返しても、なかなか理想通りにならずに苦労しているように思います。




なんか話がいろんな方向に発散してきました。


最後に、全然違うのだけど経験話を。


過去に、仕事で携帯電話向けのチャットサイトを構築したことがあります。

気軽におしゃべりを楽しんでもらうために、さまざまな指標でユーザー同士の「マッチング」を行うのですが、このプログラムの混乱ぶりがすごかった。


一応 NG ワードとかも持っていて、あまりに酷い言葉は入力させないのですが、そうでなくても緩くペナルティポイントを加算していました。

で、あまりひどい話になっていそうな部屋は、新たなユーザーが入るのを禁止します。


ユーザーごとにも「話の傾向」フラグを持たせていて、同じような傾向のユーザー同士をマッチング。

一方で、フレンド登録とかブロックとかあって、フレンドはできるだけマッチングしたいし、ブロックした人がいる部屋には入れるわけにいかない。


いい会話がないなー、と思ったら、一人で新しい部屋に入ることもできるのだけど、そのユーザーさんを延々と待たせるわけにもいかない。

そういう部屋は、他の人にできるだけお薦めしていかなくては。


新しいユーザーが来るたびに、「今お薦めの部屋」をいくつかピックアップし、その中で選んでもらうのですが、その舞台裏は細かな調整の連続でした。

考慮すべきことが多すぎて、どんなに調整しても満足いく状態にならないのね。



で、スプラ2のマッチングって、これと同じことを…もっと高度なレベルでやっているのだな、と思うのですよ。



勝率がおかしいのは、おそらく「気がする」ではなく、事実です。なにかシステムがおかしい。


でも、多少うまく行っていないからと言って、怒る気にはなれない。

多分、現在のマッチング自体がギリギリのバランスで成り立っているから。



願わくば、勝っても負けても楽しめるフェスにしてほしい、と思います。

マッチングにバグがあるとか、ブキが偏りすぎるとかは、あまり楽しめなかったよ。




以降、2018.9.21追記


最初のほうに追記した通り、第16回フェスからルールが改定になりました。


上の日記では、第13回終了時点まででの結果で論じていたのですが、せっかくなのでその後の2回分について記録しておきます。


第14回も第15回も、少数派の勝ちでした。


最終的なソロ戦・チーム戦の通算では、少数派が25勝、多数派は5勝だったことになります。




おそらくは、何らかの都合で少数派のほうが「強い」状態でマッチングされることが多かったのかと思います。

そこで、新ルールでは、単純な勝敗を競うのではなくなっています。


1) チーム戦。塗った面積の合計を指標とし、勝つとさらにボーナスポイントをもらえる


2) 個人戦。同程度の強さ指標を持つ人が集められ、勝つと相手の強さの平均値をポイントとしてもらえる。このポイントの合計で競う。



チーム戦では、負けた側もポイントはもらえるため、勝負で差がつきにくくなります。

個人戦では、強い側が勝ってももらえるポイントは少なく、弱い側が勝てばポイントが多くなります。

これにより、マッチングした「強さ」のばらつきによる差がつきにくくなります。


さらに、ランダムに「10倍マッチ、100倍マッチ」という、獲得ポイントに倍率がかかる勝負が行われることもあるようです。


…全体として負けている側を「ちょっと」強い人たちでマッチングすれば勝つことが多いだろうし、その際に大量ポイント与えると、常に互角の勝負を演出しやすくなるよね。



勝負を拮抗させる力を介入させすぎると、「努力が報われない」ことにもなってしまいますが、お祭りなんだから勝負の行方が分からないほうが楽しいと思います。


よい改定なのではないかな。


…まだ新ルールで遊んでいないのですが、期待できそうです。



▲目次へ ⇒この記事のURL

別年同日の日記

02年 結婚指輪

06年 パンク

13年 虫歯予防週間


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

Nexus 7 復活  2018-04-24 10:42:21  コンピュータ

▲目次へ ⇒この記事のURL

急に Bluetooth キーボードを使いたい状況になったのだが、我が家には1つしかない。

過去に Nexus 7 で使っていたものだ。


出したら、裏面のエラストマー樹脂が経年劣化でべたべたしていた。


キーボードを使いたかったのは妻で、使用用途はちょっとした「試し」だったので、とりあえず目的は完遂。

それでキーボードは用済みになったのだけど、べたべただからとエタノールで拭き始めた。


#これでとりあえず「問題が軽減する」


で、ついでにずっと使っていなかった Nexus 7 も、べたべたしていたので拭き、充電した。


これ、なんで使わなくなったんだっけ?


…と言いながら起動して、Chrome をつかおうとする。

ただ Chrome を起動するだけで、5秒くらいかかる。そのあとも動作がもっさり。


こんなに遅いマシンだったっけ?




もちろん、購入当時便利に使っていたのでそんなに遅い覚えはない。


ずっと使っていなかったので、中に必要なデータなんてない。Factory reset してみる。

…多少動作が早くなった気がするが、まだ根本的に遅い。


そもそも、自分の Nexus 7 がいつのバージョンかも覚えていない。



Nexus は、Google 純正のアンドロイド端末のブランドだ。


7 は 7inch のタブレットであることを意味する。

普及を目指して作られた純正品で、儲けを考えていなかったので非常に安く、性能と比べてもコストパフォーマンスが良かったので話題になった。


その後、翌年には後継機が発売されたが、同じサイズなので名前も同じ Nexus 7。

Google は、元祖を Nexus 7 、後継機を Nexus 7 (2013) と呼ぶ。一般には、元祖を Nexus 7 (2012) と呼ぶこともある。


で、自分の持っているのは 2012 の方だった。




Nexus 端末はまた、純正品として「3年間のバージョンアップ保障」を行っていた。


2010 年ころは、多くの Android 端末は、バージョンアップの保証がなかった。

発売1年以内のメジャーアップデートに対応してくれれば良心的だが、場合によっては発売後すぐの「セキュリティバグ」にすら対応してもらえない。

セキュリティバグが放置なんて、安心して使えるものではない。


そこで、2011 年に Googleが中心となり、いくつかの Android 製造メーカーが共同で「18ヶ月保障」という枠組みを作り出した

発売から 18か月…1年半の間は、OSのバージョンアップに迅速に対応する。


しかし、Google 純正である Nexus は、この倍である36カ月…3年間のバージョンアップを保証した



その結果、2012 年発売の Nexus 7 は、2015 年リリースの Android 5.1 … Lolipop と呼ばれるバージョンに対応した。

Nexus 7 発売時には、Android 4.1 Jellybeen だった。


Android 端末の OS 世代は、お菓子の名前になっている開発コードネーム頭のアルファベットで示される。

3年間で、 J K L と3世代を超えたわけだ。(ちなみに、K は 4.4 Kitkat)


ちゃんと保証通りに OS を提供して素晴らしい…というわけではない。むしろ、マズい対応だった。

Nexus 7 は、普及を狙って安く作った端末だ。


メインメモリは 1GB だった。4.4 Kitkat なら十分に動作するが、5.1 Lolipop だと、OS を動かすだけで精いっぱい。

アプリを起動しようとすると、足りないメモリをやりくりし始めて「もっさりと」起動することになる。


#ちなみに、5.0 の時点ではメモリリークのバグがあった。

 メモリが足りないのはこのせいだ、と当時言われていて、バグ修正版となる 5.1 が出た時は歓迎された。

 が、そんなことは些細な問題だった。Nexus 7 (2012) に Lolipop は重過ぎるのだ。




…と、このマシンを使わなくなった理由を思い出した。

当時はそれでも、これはあまりにもひどいので Google が対策バージョンを出してくれるだろう…と期待して待っていたのだった。


もう、今更待つ理由はない。内容のリセットもしたことだし、ついでに OS をダウングレードしよう。


PC に接続し、4.4 系列の最終版、4.4.4 のファクトリーイメージ(工場出荷イメージ。ネットで公開されている)を書き込む。


PC に Android 開発環境を入れている人なら難しくない作業だけど、入れていない人は Java の導入から始めないといけない。

Android は一応 Java で開発することになっていて(当時)、開発環境も Java で作られている。

だから、Java を入れて開発環境を入れて、端末側も開発モードにして PC と接続し、開発用コマンドラインツールを使ってファクトリーイメージを書き込む、という作業が必要になる。



作業が終わったら軽快に動く。


妻に見せたら喜んで…というか、事実上とられた。

気になっていたけど見ていなかった動画類を消化するための小型端末が欲しかったそうだ。

まぁ、もともとこれは妻のマシンなのだけど。


実際、動画を見る程度なら問題なく動作する。


Chrome などもちゃんと実用速度で動くが、6年前のマシンなので「軽快な動作」とはいかない。

ただ動画を流しっぱなし、というような、インタラクティブ動作を伴わないものなら十分使えるようだ。



▲目次へ ⇒この記事のURL

関連ページ

北海道地震【日記 18/09/07】

別年同日の日記

02年 4/24

15年 PRINT 略記

16年 GAME ON展

16年 未来科学館リニューアル


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

ロードランナー レガシー  2018-04-12 14:30:59  コンピュータ

▲目次へ ⇒この記事のURL

ロードランナー レガシー

Switch のダウンロード販売ゲーム、ロードランナー レガシーを購入した。



最初に書いておくけど、僕は初期のロードランナーが好きです。

作者であるダグ・スミスが亡くなった際に、思いのたけを書いています


これから購入したゲームの感想というかレビューを書くのですが、あくまでも「初代好き」が書いたものだと考えてください。


ロードランナーは歴史が長いから、どのバージョンが好きかは人それぞれ。

僕が良いと思う部分も、人によっては気に食わないかもしれません。




では本題。


ロードランナー レガシーは先に steam 版(PC用のゲーム配信サービス)があったのだけど、その時から少し興味はありました。


でも、僕は基本的に PC は仕事の道具で、本格的にはゲームをしないことにしている。

…気晴らし程度のミニゲームはやるのだけど、それ以上やり始めると仕事に支障が出るから。


そして、今回の Switch 版。興味あり、と思ったら、無料体験版が公開されていた。

早速遊んでみる。


体験版では、各種モード最初の数面が遊べるようになっていた。


「アドベンチャーモード」と、「パズルモード」、「二人協力」ね。


遊んでみると悪くない。初期の、シンプルなロードランナーを今の技術で作り直した、というだけのもの。


一番興味を持っていた「クラシックモード」は、購入しないと遊ばなかった。

でも、遊べる分だけで品質については充分に安心できた。購入する。




ここで「初期」について説明すると、業務用の IREM 版が一番近いと思う。


元祖である Apple II 版には、制限時間などはなかった。

でも、業務用では延々と遊ばれては困るので、制限時間があり、残り時間は「ボーナス点」となった。


いや、むしろ制限時間は「ボーナス点」のためにあると言っても良いかもしれない。

ロードランナーはパズルゲームだが、パズルだと一回解くと終わりになってしまう。


IREM 版は、業務用らしく得点を競わせた。

速く解ければボーナスが入るし、より難しい課題…敵を殺さない、隠れキャラを探し出す、などでも得点が上がった。


本質である「パズルのようになっている面をクリアする」という点では、これらの得点を取る必要はない。

でも、業務用だから得点というわかりやすい目標を掲げることで、繰り返し遊んでもらえるようにしたんだ。



また、IREM 版は遊びやすさに最大限に気を使っている。


ロードランナーには「落とし穴」という、見た目は普通のブロックと同じなのに、実は何もない空間、というものがある。


IREM 版はいくつか続編が作られたが、一番最初のバージョンでは、落とし穴が存在しない。

パズルなのに「見た目でわからない」というのは、遊びやすくはないと考えたようだ。


しかし、この落とし穴もロードランナーの魅力の一つ。2作目からは取り入れられたが、その場合でも「一度落ちると見た目が変わる」ようになった。

落とし穴があることはわかったが…どこだっけ? ということがない。



また、ロードランナーでは、回収すべきターゲットである「金塊」を、敵が隠し持ってしまうこともある。

隠し持っている敵を罠にはめ、回収しないといけないのだが、Apple II 版では、どの敵が持っているかはわからない。


IREM 版では、金塊を持っている敵が見た目でわかるようになった。



「レガシー」は、この IREM 版をベースにし、さらに遊びやすくしている。


例えば、主人公が掘った穴はしばらくすると埋まる。

この「埋まるタイミング」が重要で、遊ぶうちにタイミングになれる必要があった。

これは、IREM 版でも変わらなかった。


でも、「レガシー」では、掘った後に色がつく。だんだん赤くなり、最後に埋まる。

埋まるタイミングが非常にわかりやすい。



でも、そうした細かな改良だけだ。Apple II 版と基本的には「なにも」変わらない。

ロードランナーの良さを何も失わず、最新の技術を、遊びやすさを追求するために使っている。


ルールがシンプルでいながら、ゲーム内容が十分に複雑、という、理想的なゲームのお手本のようだ。




IREM 版が、得点を競い合うようにした、と書いた。


「レガシー」でもその方向性は守られていて、ネット上でランキング集計されている。


ただ、購入している人がそれほどいないのかもしれない…

アドベンチャーモードの前半程度しかやっていないが、一度クリアしただけで極めていないような面でも、30位くらいに入ってしまったりするので。


まぁ、面によっては 150位くらい。それでも、全然最適化していないプレイでこれだ。

購入者は少ないと思う。



一応書いておくと、ハイスコアランキング「以前」の問題として、最近のゲームにありがちな、クリア時の評価がある。


クリアしただけの面には、星1個。

ノーミスクリアできた面には星2個。

ノーミスクリアで規定の点数を超えた場合には、星3個が与えられる。


「一度クリアしただけ」と先に書いたが、最初から星3個を目指したプレイをしているので、クリア時点でそれなりの点数にはなっている。



ロードランナーを好きで遊んだ世代には、いきなり星3個でもそれほど難しくない。

でも、興味を持って始めた子供には、クリアだけでも…つまりは、星1個でも難しいようだ。

一応「パズル」だからね。解き方の手順が思いつくかどうかは慣れによる。



ついでだから書こう。


2人用モードは、長女が遊んでみたいと言ったので一緒にやってみた。


このモード、二人ともロードランナーに習熟しているのが前提。

協力して面クリアを目指すのだけど、パズルを解く手順を二人ともわかっていないと、協力した動きなんてできないから。


ただ、協力して解くというのは面白いとは思った。

子供が慣れたらまたやろう。




その他、「新しい要素」を1つだけ書いておきたい。


「アドベンチャーモード」がメインモードなのだけど、面が進むと出てくる敵が変わる。

IREM 版も敵が変わったけど、基本的にはグラフィックが違うだけだった。


「レガシー」では、動きのアルゴリズムから違ったりする。

重力無視で、壁伝いに動いたりするからね。


これが、新しいのだけど原作の良さを無くさない変更で、なかなか面白い。




さて、それでは新要素の紹介は終わりにして、あえて「Apple II 版を再現した」という、クラシックモードを紹介。

画面が地味だから、あまり紹介している記事を見かけない。


この日記冒頭につけた画面写真がそれだ。

Apple II 版は 150面あったのだけど、全部収録している、らしい。


らしいというのは、Apple II 版は僕は遊んでいないし、その移植であるパソコン版も、友達の家で少しやっただけだから。

でも、だからこそ、あこがれだった「最初の 150面」を遊べるのがうれしい。



「レガシー」では、エディットで面データだけでなく、キャラクターデータも作れる。

全部ポリゴンなので、四角いブロックを使う形で3Dで作らないといけない。


そして、クラシックモードでは、面データだけでなくキャラクターも、Apple II 版に似せたものが使われている。

でも、やっぱり3Dだし、先に書いた「遊びやすさ」などはこのモードでも活きたまま。不思議な感じ。



AppleII 版では、敵を倒すと画面最上部のランダム位置から出現することを使い、主人公が行けないところにある金塊を取ってきてもらう、という面があった。

こうした面では、当然「敵を倒さないボーナス」は望めないし、ランダムが絡むのでタイムボーナスも狙いにくい。


そうした意味では、Apple II の面データの忠実な移植ではあっても、同じ気分で遊べるわけではないかもしれない。

それでも、今改めて初期の 150面を遊べるということがうれしいと思う。




Apple II 版ロードランナーの大ヒット後に販売された、ユーザーが作った特に難しい面を集めた「チャンピオンシップロードランナー」の面データも、別売りでよいから追加配信してくれないだろうか?


もっとも、面エディタはあるのだから、自分で作ればよいのかもしれない。



チャンピオンシップでは、敵の動作アルゴリズムがわずかに違うだけで解けないような面もある。

当時、他機種への移植で問題が続出したと聞いている。


もしかしたら、「レガシー」でも、完全には敵のアルゴリズムが同じわけではなく、チャンピオンシップのデータは移植困難、ということかもしれない。


なにせ、あの敵のアルゴリズムは、もともとバグだったものだからね。

「予測がつきにくい動きのほうが面白い」という理由で残されただけで。


▲目次へ ⇒この記事のURL

別年同日の日記

03年 探し物

10年 最近のうちのこ

16年 タタコット

16年 電話番号のしくみ


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

サターンポリゴンのゆがみ  2018-01-23 17:57:30  コンピュータ 業界記

▲目次へ ⇒この記事のURL

4年ほど前に、サターンのハードウェアに関して…いや、ハードに限らず周辺の噂話まで含めて、長大な記事を書いた。

嬉しいことに、今でも時々反響がある。


で、先日 Twitter で、「たしかに、プレステは大きく歪むが、サターンは歪まなかった」と言っている方がいた。

その言葉を読んで、ハッとしたのだ。


しまった。

サターンの大バグで、わざわざ「歪めて表示しないといけない」場合があったことを書いていない。




セガラリーチャンピオンシップは、サターンのプログラムがこなれてきたころに発表されたビッグタイトルだ。

非常によくできている。僕も当時、レーシングコントローラーまで購入してやり込んだ。


このゲームを遊んだことがある人なら、ゆっくりと走った際に、コースを表現するポリゴンの、一番「手前」…

説明しずらいが、画面の一番こちら側に来る部分が、妙に歪んで表示されていたことを覚えているかもしれない。


あの歪み、ソフトウェアでわざわざ歪めて表示している。

そうしないと、ハードウェアの別のバグにぶつかり、表示がおかしくなってしまうためだ。


サターンのテクスチャは方式上歪みが少なく、プレステのようには歪まない。

しかし別の部分のバグを回避するために、状況によってわざわざ歪ませるように表示しないといけない場合があった。




サターンのスプライト表示 LSI …VDP1 には、クリッピングウィンドウ機能というものがあった。

画面内の「上下左右」の辺の座標を指定することによって得られる四角形の中でだけスプライトを描画し、その外側には描かない、という機能だ。


通常は、この四角は画面の最大サイズになっている。

その外側にはメモリが無いから書き込んではいけないためだ。


でも、例えば画面を分割して対戦できるようなゲームでは、ウィンドウサイズを変えることで、それぞれのプレイヤーの画面の中だけを描くことができる。

車のバックミラーの中だけ別描画、というようなこともできるし、ゲーム内の背景にテレビ画面があってその中に別のものが表示されているような効果も出せる。


工夫次第でいろいろ使える便利な機能だ。




スプライトは「四角」で定義されていて、4つの頂点を自由な位置に指定することで変形表示できた。

これがいわゆる「ポリゴン」だ。


変形表示の際には、元の画像定義の「横1ライン」ごとに画像が転送され、このラインを重ねていくことで面が作られる。

南京玉すだれみたいなものを想像してもらえるといいだろう。


実際には、この「ライン」が送られる直前に、クリッピングウィンドウの処理が入る。

ラインの始点と終点がウィンドウの外にあるかどうかがチェックされ、外にある場合は、ウィンドウの辺とラインの交点を算出する。

交点はつまり「ウィンドウ内に表示される端の点」なので、ここからウィンドウ内だけを描けばよいわけだ。


始点側がウィンドウ外なら、交点を求めるとともに、テクスチャの読み出し開始アドレスをずらす。

終点側がウィンドウ外なら、交点を求めるが、テクスチャ読み出しアドレスは変えない。

(いずれも、テクスチャの読み出しスピードは、クリッピングしない際のラインの長さに依存する)


始点も終点もウィンドウ外なら?

その線は、全部がウィンドウ外だろう。描画の必要はなく、捨てられる。



…ここにバグがある。


おそらく、この処理は System32 の家庭用を作っていた際の名残で、スプライトは四角いまま拡大縮小する程度の前提だったのだろう。

変形しない、四角いスプライトを前提にすれば、始点も終点も描画外なら全体が描画外、は正しい。


しかし、サターンの変形スプライトでは、ラインの一部だけがウィンドウ内に入る、ということがあり得る。

ウィンドウの「角」の部分にかかるように、始点と終点が違う辺(例えば下辺と左辺)をはみ出して描画される場合だ。


この場合、先に書いたクリッピングアルゴリズムだと、ラインの描画全体が捨てられてしまうため、本来必要な描画が行われなくなる。

結果として、サターンで作ったポリゴンゲームの、画面の角の部分は描画が行われないことが多くなり、「穴が開く」状態となる。



レースゲームでは、コースを構成するポリゴンが画面の下左右角にはみ出る、という状況は当たり前に発生する。

そこで、セガラリーチャンピオンシップでは、2次元変換させた後のポリゴンの座標をさらに加工する。


具体的には、「左右」からはみ出さないようにプログラム内でクリッピングしてしまえばよい。


厳密に言えば、クリッピングによって表示が6角形になる場合があるのだけど、セガラリーではおそらくそのような状況にはならない。

クリッピングで5角形になる場合に限定すれば、外側の2頂点を適切に移動してやれば、見た目の上でポリゴンの「辺」の形状を変えないようにできる。


ただし、内部のテクスチャは大きく歪む。

これをどう誤魔化すかは、作る側のテクニックだ。


セガラリーの場合、路面のテクスチャは工夫されていて、多少歪んでもわからなかった。

また、極端に斜め線を作らなければ問題の状況は起きないので、ガードレールなどはポリゴン面が縦に分割されるようになっていたのだと思う。


そもそも、歪んでも十分に高速で動いていれば、一瞬で通り過ぎるためにあまり気にならない。


しかし、崖の斜面などの形状が歪んだ部分にぶつかり、ゆっくり動いたりすると、歪むのがわかった。

このゲーム、そんな下手なプレイしているようじゃダメなので、慣れるにしたがってそういうことは起きなくなるのだけど。




他のゲームでも、よく見ると画面端は歪んでいる場合が結構あった。

描画が破綻するというのは最悪の状況なので、回避のために工夫したのだろう。


初期の SGL には、自動的にゆがめることで破綻しないようにする機能、というのはなかったように思う。

でも、もしかしたらバージョンアップの過程でつけられていたかもしれない。

申し訳ないが、この辺りはちゃんと覚えていない。



この記事、書き上げてからネットで SS のセガラリーの動画探してみたのだけど、思ったような歪みが見つけられない。

記憶で書いているので多少違っている部分もあるかもしれない、と断っておく。


本当は、自分で実機でセガラリー動かして検証すればいいのだけど、そこまでやっていない。



この話はサターン記事の中に追記するのが適切なのだけど、個別論に入った長い話を追記すると話の腰を折ってしまう。

なので、日記に書いたうえで、記事内からリンクしておくことにする。




▲目次へ ⇒この記事のURL

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

業界記

関連ページ

細かな話題

別年同日の日記

12年 ゲームボーイの CPU

15年 アプリケーションサーバとしてのQNAP

15年 宮永好道 命日(1993)

16年 iOSでtextのコピー・ペーストができないバグの回避


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

【獣】 歪まないけど汚いっていう印象でしたね~デイトナなんかでは一番手前側にくる道路が、下に落ちていくような感じになっていましたが、あれも表示がおかしくならなくするための対策だったのでしょうか (2018-01-24 13:01:05)

原初のプログラム  2018-01-10 12:02:44  コンピュータ 家族

▲目次へ ⇒この記事のURL

長男が熱心だった Scratch プログラムだけど、この冬休み期間に、長女・次女も再チャレンジし始めた。


以前は難しくてやめてしまったのだけど、今の年齢なら楽しめるようだ。



で、長女(小4)から質問が出た。


Scratch は Flash という言語で作られていて、その Flash はC言語という別のプログラム言語で作られている。

…ここまでは、プログラム言語の多様性を知ってほしくて以前に教えている。


#厳密に言えば、Scratch ver.2 が Flash の ActionScript 言語で作られていて、ActionScript は C言語の拡張である、C++ 言語で作られている。


ここからが長女の質問。


「では、このパソコンで動く一番最初のプログラムはどうやって作られたの?」



あぁ、なるほど。そこに疑問を持ったか。

同じようなことに興味を持っている人もいるかもしれないので、長女に答えたことを記して置こうと思う。




まず、目の前の疑問の答えは、クロスコンパイルだ。

すでに動いているコンピューターの上で、別のコンピューターのプログラムを開発する。


僕はテレビゲームの開発をやっていたけど、テレビゲーム機の上では、普通は「プログラム」を作れない。


長女も Nintendo Switch で遊んでいるけど、そこでプログラムは作れない。

プログラムを楽しみたいときは、パソコンで Scratch をやっている。


Switch でゲームを作っている人も、Switch を使って作っているわけではない。

パソコンの上でプログラムを作って、それを特殊機材で Switch に送って動かしているんだ。



新しいパソコンが作られる時も、同じように別のパソコンでプログラムを作ることになる。


今広く使われているパソコン…IBM PC 互換機、と呼ばれるものが出てきたときも、基本プログラムはすでにあったコンピューターで作られた。


#それ以前の 8bit マシン…CP/M マシン上で開発されていたようだ。




長女はこの答えには納得できないようだった。


「このパソコンの」と言ったのは言葉のアヤで、真意は「最初のプログラム」にあったのだ。


そのプログラムはそれ以前のプログラムで作られたという。

じゃぁ、「それ以前」はどうやって作ったのか。もっともな疑問だ。


そのため、ここで話を切り替える。




コンピューターの中では、すべてを数値として扱っている。

計算をするときには、例えば「1番は足し算、2番は引き算」というように、命令も数値になる。


1 2 3


という3つの数値があったとしよう。

ここで、1 は足し算の命令で、2 3 が足すべきデータになる。結果は 5 だ。



一番最初のコンピューターでは、人間が直接この「数値」の列を作り出した。


もっとも、プログラムを作るときに 1 2 3 と直接書いていると、頭がこんがらがってしまう。

1 は足し算(英語で ADD)なのだから


ADD 2 3


のように紙に書いておき、プログラムが全部出来上がったら、命令を手作業で数値に直していけばよい。




そして、この数値を入力するには、ON / OFF できるスイッチを使う。

コンピューターの中では、数値は全部、電気信号の ON / OFF に置き換えて覚えられている。


ON なら 1 、OFF なら 0 として、寄せ集めるともっと大きな数値も表せるようになる。


#いわゆる2進数だけど、この話では詳しく知る必要はない。

 ちなみに、長女は以前教えて2進数を知っているので、この部分に疑問は持たなかった。


スイッチをぱちぱちやって数値を作り、「書き込み」スイッチを押すと、メモリに書き込まれる。

どんどん連続してメモリに書き込まれていく回路を作ると、これでプログラムを準備できる。


そして、CPU に対して「実行」を指示すれば、「最初のプログラム」が無事動き出す。

最初はこんな風にしてプログラムが作られた。




じゃぁ、最初にどんなプログラムを作ったか。


スイッチをぱちぱちやるのは、プログラム方法としてはかなり面倒くさい。

だから、最初に作るのは「タイプライターのキーを押すと、それが文字だと識別されるプログラム」だ。


これがあれば、もう「ぱちぱち」とはおさらば。タイプライターで効率よくプログラムが作れる。


次に作るのは、ADD なら 1 、SUB なら 2 …という、命令から数値への変換を、自動的にやってくれるプログラムだ。

先ほど「人間が手作業で命令を数値に直す」としていたけど、自動的にやってくれるプログラムがあれば効率が上がる。


#一般には、数値化する作業を「アセンブル」(組み立て、の意味)と呼び、これを自動的に行うプログラムは「アセンブラ」と呼ばれる。




もし、この時点で新しいコンピューターが設計されたとしよう。


新しコンピューターでは、命令の数値なども変わるのが普通だ。

今まで使っていたコンピューターでは、ADD は 1 だったけど、新しいコンピューターでは 10 かもしれない。


そうしたら、アセンブラのプログラムを修正する。

ADD は 1、だったところを ADD は 10 、にするだけでいい。


これで、新しいコンピューター用のプログラムを作り出すことができる。

最初に書いた「クロスコンパイル」というのは、ただこれだけの話だ。




ここで話はひと段落。

スマホで情報を検索して、Altair 8800 の画像を長女に見せてみた。


Altair 8800 は、最初のコンピューターではないが、最初のパソコンとされる。


前面パネルには、ON / OFF のスイッチがたくさんついていて、結果出力のためのランプもある。

入力も、出力も、ON / OFF しかないんだ。



でも、タイプライター(厳密にはテレタイプ)を接続して使うのが普通だった。


電源を入れたら、RAM の中には何もない。

だから、まずはタイプライターからの入力を読み取るためのプログラムを、 ON / OFF スイッチで入れる必要があった。

このパソコンを使っている人は、それが毎日の作業なので、短いプログラムを暗記していた。


タイプライターの入力が読めるようになったら、タイプライターについている紙テープ読み取り機から、紙テープを読み込ませる。


テレタイプでは、入力内容を紙テープ化できた。そうすることで、同じ原稿を何度でも打ち出すことができる。

でも、ここでは紙テープに記録されているのは「文字」ではなく、プログラムそのものだ。


たとえば、テレタイプを入出力として、BASIC 言語を解釈するプログラム。

このプログラムが動き始めれば、タイプライターを使ってプログラムを作れるようになる。


時には、さらに「BASIC で作られたプログラム」を紙テープから読み込み、何らかの実作業に使ったかもしれない。



ここでは、タイプライターだから出力が紙なのだけど、キーボードで文字を入力して、人間にわかる文字で結果を返す、という、誰にでもわかりやすいプログラム環境が出来上がったことになる。




このときは、手っ取り早く Altair 8800 の画像を見せた。


でも、それ以前からコンピューターは存在する。

それらも、構造的にはほぼ同じだった。


うちのページでいえば、TX-0あたりを見ていただきたい。

Altair 8800 よりずっと古い機械だけど、トグルスイッチを使って2進数を入力するあたりも、ほぼ同じ構造だ。


もっとも、TX-0 は紙テープを読み込んでメモリにデータを配置する機能を、ハードウェアで持っていた。

そのため、毎回紙テープを読み込むプログラムを入れる必要はない。



さらに古く、電子計算機の元祖に近い EDSAC では、完成後の改造で「イニシャルオーダー」が備えつけられた。


抵抗とワイヤーで ON / OFF を表現することで、紙テープを読み込むプログラムを固定化したものだ。

必要に応じて取り外せるようになっていて、取り外すとその部分は普通のメモリとして扱われる。


ROM に準備され、コンピューターが起動するときに最初に読み込むプログラム…今でいえば、BIOS や UEFI に相当するものだった。




ともかく「手作業で」最初の小さなプログラムを作り上げ、そこからプログラム環境が整えられていく。

あとは、Scratch の話と一緒だ。



Scratch は Flash で作られ、Flash は C で作られていた。


Altair 8800 では、Scratch に相当するものが BASIC だった。

BASIC はアセンブラで作られ、そのアセンブラは、ON / OFF スイッチを駆使して入力されるものだった。



BASIC から C までの間は長女には説明しなかったけど、想像は付いたようだ。

より便利な環境を作るために、誰かが「その時使える」環境で、新しいプログラムを書いてきた。


その積み重ねの果てに、子供でも使える良く練り込まれた環境、Scratch が存在している。


Scratch も、そろそろ Javascript で書かれた Ver.3 に移行する予定だ。



▲目次へ ⇒この記事のURL

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

家族

別年同日の日記

05年 Switch!

13年 続々・Windows8

16年 国立科学博物館

16年 国立科学博物館(続き)

16年 上野公園


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

無言電話(SIP SPAM)  2017-12-20 18:39:52  コンピュータ 歯車

▲目次へ ⇒この記事のURL

先日 IP 電話を導入したら、すぐに無言電話がかかってきた。


無言なので電話を切ると、すぐにまた掛かってくる。

もしかして、機器の設定を間違えて音声がうまく通じていないのか、と思ったが、自分で確認したら大丈夫。


そもそも、新しい会社電話番号は税理士さんにしか伝えていない。

(この年末調整で、税務署に伝えてもらうためだ)


税理士さんが確認のために電話をくれたのかな、と思ったが、それにしてもしつこい。

10回もかけ続ける、なんて人間が相手ではありえないだろう。


とりあえず、IP電話の機器から電話機のケーブルを引き抜く。

どうせまだほとんど誰も電話番号を知らないのだ。電話がつながってなくても構わない。




忙しくてそのまま数日。

やっと設定を見直す。


ネットで情報を探すと、SIP SPAM とか、 SPIT (SPAM over Internet Telephony)とかいうらしい。

IP 電話に対して、だれかれ構わず電話をかける、SPAM。


もっとも「SPAM」というのは語弊のある部分で、実際には宣伝などの通話をしたいわけではない。

電話機のポートが開いていないかを確認していて、ポートが開いているなら攻撃を試みるのだ。


ネットで対策方法を調査し、機器設定で、一か所ボタンを Yes にするだけで、簡単に対処できるとわかった。

でも、その設定の「意味」を知っておかないと気持ち悪い。


そんなに簡単な対処なら、なぜわざわざ変更可能にしてあり、初期状態が No なのか。

何か副作用があるのではないか。




そんなわけで、VoIP 電話機がどうやって動作しているのか、改めて確認したので、まとめておこう。


ちなみに、同じような「無言電話」に困っている人のために、先に対処を書いておこう。


僕は Grandstream の HT701 を使っている。


設定の FXS PORT というタブに、Authenticate incoming INVITE という項目がある。

初期状態は No なので、 Yes にすればよい。これだけで SIP SPAM による無言電話が無くなる。


他の機器でも、INVITE 、Authenticate あたりをキーワードに設定を探すと見つかると思う。

(日本語では INVITE 認証、と訳されることが多いようだ)




設定の意味を理解するためには、VoIP の概要を知る必要がある。


VoIP は、単純に言えば、アナログ音声をデジタルサンプリングして、パケット化して相手と相互通信する技術だ。

これ自体はそれほど難しいことではない。


問題は「相手」ってなぁに? ってことだ。

インターネットを使うのだから相手は IP アドレスで指定しないといけないが、電話なので電話番号で指定したい。


そこで、VoIP 電話を提供する会社が SIP サーバーというものを用意する。

契約したユーザーには、ID とパスワードを発行する。

電話番号は、この ID と紐づいている。



通信機器は、まず SIP サーバーに接続し、パスワードで認証を行う。

これが成功すれば、ID に対して、接続してきた IP アドレスを記録できる。


先に書いたように ID と電話番号は紐づいているので、IPアドレスと電話番号も紐づけられることになる。



電話をかけたい人は、SIP サーバーに接続して、電話番号を伝える。

すると、SIP サーバーはその電話番号相手の IP アドレスに接続し、「INVITE」(呼び出し)と伝える。


VoIP 通信機器は、INVITE を受信すると、電話を鳴らす。

電話を取った場合、サーバーは発信者の IP アドレスを教え、以降はサーバーを仲介しない直接通信となる。




SIP SPAM は、SIP サーバーでない第三者が、ランダムな IP アドレスに対して INVITE メッセージを送ることで起きている。

INVITE が受け付けられれば、そこに VoIP 通信機器があることがわかる。


PC やサーバーの存在を確認しても、そうした機器は注意を払ってセキュリティを固めてあることが多い。

それに対し、VoIP 通信機器のようなものは、セキュリティに注意を払われにくい。


悪意のある人間としては、乗っ取りやすいありがたい機器だ。

これを知りたいから、SIP SPAM が行われる。



余談になるが、外部ネットワークから参照可能で、設置したらそのままほったらかしの機器は同様の問題を抱える。

Webカメラやルーター、NAS や HDDレコーダーなど。


対策は、常に最新のファームウェアを入れるように気をつけること。

また、脆弱性が見つかったらすぐにファームウェアを更新してくれる、信頼ある会社の製品を使うこと。


VoIP 機器の場合、SIP SPAM で「無言電話」にならない対策をしても、上記問題は解決しない。

やはりファームウェアの更新に気を付けること。




さて、当初の SIP はこのような「悪意」を想定しないで設計されてしまった (RFC 2543)。

しかし、このような攻撃方法が認識された時点で、追加の RFC で対策が立てられた (RFC 4474)。



サーバーは、ユーザー認証のためのパスワードを知っている。

ユーザーも当然自分のパスワードを知っている。


でも、攻撃者はこのパスワードを知らない。


そこで、INVITE メッセージを送る際に、パスワードやそのほかの情報を使って計算した値を一緒に伝える。

両者で計算が合えば「正当な」INVITE メッセージ、それ以外は SPAM だ。



ここで、SPAM かどうかを判断するのは、受け付ける VoIP 機器側だ。

SIP サーバーが数値を伝えてきたとしても、受け取る VoIP 機器側で無視しても何ら問題はない。

(SPAM は無言電話となる)


また、後から追加された RFC なので、SIP サーバーが対応していない場合もあり得る。

この場合は、VoIP 機器側では比較すべき数値が渡されないため、正当な INVITE も、 SPAM と判断せざるを得なくなる。

(一切着信しなくなる)



前者はイライラするだけだが、後者は電話として致命的だ。

そのため、機器の初期設定としては、この機能を使用しない状態になっている。


SPAM に困って「使用する」に設定した場合は、自分で電話をかけて、着信できることを確かめたほうが良いだろう。

正常に着信すれば、SIP サーバーもこの機能に対応しており、他の副作用は生じない。




というわけで、設定変更一つで問題は解決した。

これで、着信待ちだけなら無料の電話回線が一つ用意できた。


以前書いたけど、僕に用事がある人は僕の携帯やメールに連絡をよこすため、多分使わない。

「会社電話番号」を知りたがるお役所のために用意しているだけだ。

その役所も電話をかけてくることは、まずない。


使わないからこそ、無料になるのはありがたい。


▲目次へ ⇒この記事のURL

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

歯車

関連ページ

IP電話【日記 17/12/12】

別年同日の日記

02年 ムカツク店員

03年 日記エンジンバージョンアップ

13年 Robot Turtles

15年 honor6 plus 使い勝手レビュー


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

P10 plus に乗り換え  2017-12-18 11:56:25  コンピュータ 歯車 家族

▲目次へ ⇒この記事のURL

Huawei のスマートホン、P10 plus を購入した。


…いやいや、2ヵ月前に、その下位機種の P10 を購入したばかりだろ。

もう買い替えたのか、って思われるかもしれない。


元々、P10 を欲しかったのは妻なのだ。

購入したのだけど、思ったのと違った。それで僕が使うことになった。



「思ったのと違った」のは、主にユーザーインターフェイス部分。

Android で、ランチャとかホームとか言われる、システム標準で付属している、一番操作の中心となる部分だ。


それまで ASUS の ZenFone2 Laser を使っていた。

ASUS では ZenUI というランチャを使用している。


Android には、iOS の通知機能である「バッヂ表示」は存在しない。

でも、ZenUI では謎テクノロジーによって、バッヂ表示を行う。



これに対し、Huawei では HuaweiHome というランチャを使っている。

バッヂ表示は「一部ソフトのみ」対応していて、「一部ソフト」の多くが、Huawei 製のアプリだった。


これが、バッヂ表示はするけれど、アプリとしての出来はそれほど良くない。

いや、出来が悪いわけではないけど、可もなく不可もなく。

探せば無料でもっといいのがあるよ、という感じの出来栄え。




一度は P10 は肌に合わない、と僕に譲り、代わりに僕がそれまで使っていた Huawei Honor6 plus を使い始めた。

でも、その後 HuaweiHome の癖にも多少慣れてきた。


何よりも、Android はランチャを好きなものに交換できる。

無料の「Atom Launcher」が結構望みの操作感を実現してくれる、ということも分かった。



#先にバッヂ表示を「謎テクノロジー」と書いたが、iPhone にあるものを Android で実現すべく、いくつかのホームアプリが「独自の」バッヂ表示 API を作り出していた。

 独自規格が乱立したわけだが、今はそのすべてに対応したホームアプリなどが作られている。

 HuaweiHomeが「一部ソフトのみ対応」だったのも、一部 APIにのみ対応していただけの話。



じゃぁ、ユーザーインターフェイスの問題が無くなったところで、再び新機種を選定しよう。


妻は小柄なので 5.5inch の Honor6 Plus は持ちにくい。

5.0inch の Zenfone2 Laser は持ちやすい。

ちなみに、5.1inch の P10 も、問題なく持てる。


Zenfone2 Laser の不満点は、カメラ性能が悪いこと。カメラ性能は欲しい。

Pokemon GO とかポケ森とか、結構ゲームも好きなので、それなりの処理能力も欲しい。


…というわけで探すと、やっぱり P10 になってしまう。

P10 、コストパフォーマンス高いんだよね。だから以前も選んだのだけど。



じゃぁ、やっぱり P10 は妻が使うことにして、僕は新しい機械を買おう、ということになった。

Honor6 plus に不満はなかったのだけど、SIM サイズが違うので、今更戻れない。


それに今は、Honor6 plus を「空き」の状態にしたいんだ。




じゃぁ、P10 の廉価版であり、Honor6 plus の後継機である、Honor9 にしようかな…と思って調べる。



えーと、一応書いておけば、Honor9 と P10 は、処理性能などはほぼ同じだ。

違うのはカメラとディスプレイで、P10はカメラにいいレンズを使っているため、集光しやすい。つまりは暗い時に強い。

また、レンズ部分に光学手振れ補正が入っているので、揺れに強い。



でも、Honor9 のカメラが貧弱なわけではない。

もともと、レンズなんて気にしないでも十分高性能なのだ。


今では iPhone もダブルレンズだけど、もともとは Honor6 plus が導入した技術だ。

それをさらに進化させたものが、Honor9 と P10 に搭載されていて、レンズ以外は同じもの。


Honor9 だって、スマホとしてはかなり高いレベルのカメラで、P10 はそれをさらに良くしたもの。



ディスプレイは、Honor9 のほうがわずかに大きい。P10 が 5.1inch で、Honor9 は 5.15inch だ。

ちなみに、大きくなったがドット数は同じ。つまり、ここは「大きい方が微細加工が楽になるから安い」部分と思われる。


とにかく、技術的には P10 と一緒だけど、「多少安い部品つかってもいいんじゃないかな」って部分で安くしたのが、Honor9。

海外では、P10 の半額くらいで Honor9 を販売しているようなのだけど…




買うつもりで調べてみると、妙に高い。


honor9 は販売ルートが限られている。あまり Huawei 名を出さない「OEM」に近い販売ルートを取るためだ。

そして、値段は税抜き 53,800円で横並び。税込みだと 58,104円。


もちろん、SIM 契約付き1年縛り、とかで値引きしているところは多いけど、今欲しいのはそういうものではない。



これに対し、「上記機種」にあたる P10 は、販売ルートが自由なので値引き競争がある。

価格.com で安い店を調査すると、税込みで 54,400円の店が並んでいる。


…廉価機種のほうが高い、という逆転現象が起きているんだ。



#…と、購入検討時には思っていた。

 今日記にするために再度調べたら、OCN 販売の SIM 付き Honor9 は、税込み 49,464円なのだけど、この SIM は契約する必要はないそうだ。

 とはいえ、「上位機種」である P10 との差額は5千円程度。わざわざ選ぶかは微妙な値段だ。




P10 をもう一台買って、妻には新しい方を渡そうか…とも思った。

そうすれば、僕は「引っ越し」の必要がなくなるので楽だ。


でも、思い立って P10 の上位機種である「P10 plus」の値段を調べてみる。

58,782円。上位機種と言っても、P10 と5千円も違わない。というか、廉価機種であるはずの Honor9 と600円しか違わない。

何よりも、P10 plus の最安値を Amazon が付けているので、頼めばすぐ届く安心感がある。



P10 plus は、P10 よりもさらに良いレンズを使っている。


また、ディスプレイは 5.5inch になり、表示ドット数も増えている。

その分本体は大きくなるが、大きくなった分バッテリー容量も増えている。


もっとも、画面が大きくなって画素数が増えたのは、デメリットの可能性もある。

処理能力は変わらないのだから、画素数が増えた分だけ描画速度が遅くなるだろうし、電力食いにもなるだろう。

ディスプレイが大きくなった分バックライトも電力食いだろうし、バッテリー容量増加は相殺されるかもしれない。



でも、僕としては Honor6 plus で 5.5inch を使っていたので、このディスプレイが魅力的に見える。

というわけで、P10 plus を購入することに決めた。




前回、13日の日記で「妻のスマホ買い替え待ち」という話を書いたのだけど、それから新機種の選定を始め、注文したのが14日。


15日には P10 plus が届いたので乗り換え作業。

Huawei 機種は、Android / iOS からの「乗り換えツール」が準備されている。

これを使うと、できるだけ同じアプリを入れてくれ、可能ならデータや設定も引っ越してくれる。


そんなわけで、開封して1時間後には乗り換えが完了。

実際には使っていて多少のトラブルはあったのだけど、見た目の上では画面が広くなっただけの上位機種に、ほぼそのまま環境移行できた。

「気づいたら成長して画面が大きくなってました」というくらい、乗り換えの違和感がない。



多少のトラブルというのは、Amazon Prime Video がデータ不整合でもあったのか使えなかったことくらい。

データ消去して、再ログインしたら何も問題なく使えるようになった。


15日の夜には妻にファクトリーリセットした P10 を渡し、16日中に妻も移行作業。

こちらはいろいろ実験していたこともあり、移行ツールを使わずいくつかのアプリを再インストールしただけ。


SIM サイズが変わるのだけど、その申し込みは後にして、とりあえず2台持ちしていた Zenfone2 Laser に電話機能を戻す。



16日の夜には Honor6 plus が空いたので、ファクトリーリセット。

先日契約したゼロSIM を入れ、新規に子供用アカウントを作り、子供の連絡用に仕立て上げる。




なぜこんな突貫作業をしたかというと、17日に家族で出かける用事があったから。

また、18日から長男が塾に体験入学してみることになっていたから。


どちらかというと、大事なのは塾。

僕や妻が中学の頃は、塾は夜9時には終わっていたものなのだけど、今の塾は10時近くまであるのね。

その時間に子供を一人で帰らせるのは危険なので、車で迎えに行くことにしても、連絡手段が欲しい。



で、その前日に家族で出かけるのだから、そこで練習できるといいだろう、というつもりで突貫で仕上げたのだ。

そのお出かけの話は、この後の日記に…



▲目次へ ⇒この記事のURL

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

歯車

家族

関連ページ

ピューロランドで誕生日【日記 18/04/04】

ピューロランドで誕生日【日記 18/04/04】

WEBページの検索順位をあげる方法(2/2)【日記 18/10/06】

旅行の記録

ピューロランドのクリスマス【日記 17/12/18】

別年同日の日記

09年 名機の条件

12年 ふたござ流星群

14年 コンラッド・ツーゼ 命日(1995)

15年 CentOS5+Xen3 から CentOS6+Xen4 への引っ越し


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

0sim  2017-12-13 12:06:04  コンピュータ 歯車

▲目次へ ⇒この記事のURL

昨日に続き電話関連の話。


中学1年の長男に、先日塾の模試を勧めてみた。


近所の学習塾が、無料で模試を行っていたのね。

チェーン店なので、県下の1万人以上が同じ試験を受け、学力がわかる。


結果はまだ出てないのでそのことは良いのだけど、このときに「子供との連絡手段欲しいな」と、ちょっと思った。

初めて、子供だけで夜外出させて、車で迎えに行ったので。




まずは、0sim を申し込んでみる。


ゼロシム。月額料金無料、500MByte までは利用料無料の、データ専用 SIM だ。

500M を超えると、100Mごとに100円かかる。時々子供と連絡するだけなら、500Mに収まるだろう。


データ専用だけど、IP電話を使えば通話もできる。

そして、LINE を使えば、相手が限定されるが音声通話でも無料だ。


ちなみに、昔は LINE は SMS が使えないと ID 作れない、と言われた。

今は Facebook アカウントがあれば ID を作れる。データ専用 SIM でも大丈夫。



問題は、これを入れるスマホだな…

昔使っていたLumix Phoneをガラクタ箱の奥深くから発掘。


古いけど、通話するくらいなら問題ないだろう。




ところが…だ。

LumixPhone 、ずっとほったらかしだったので、過放電でバッテリーがダメになっているっぽい。


最初は、1日充電しても5分動作するのがやっとだった。

ただ、過放電で悪くなったバッテリーは、しばらく使っているうちに「ある程度」回復する、と聞いたことがある。


繰り返してみても、30分くらいが限度。


ネットで調べると「冷凍庫に一晩入れ、半日かけてゆっくり解凍するとよくなる」という情報が。

一体何がどういう原理で。オカルトだと思いながら試す。


なんと、4時間くらい動くようになった。

これは、機内モードにして無駄な電力を消費させない状態の話。




ゼロシム自体は、入れて動作させてみたら問題なく動く。


ただし、セルスタンバイ問題が出る。

データ専用 SIM を入れられたスマホが「音声通話回線が見つからない」と思って、一生懸命探し続けて電力を無駄に消費する現象。


ただ、「セルスタンバイ状態」と表示はされているのだけど、この状態でもやっぱり稼働時間が4時間くらい。

「音声が見つからないよー」とは言っているが、それで無駄あがきはしない、ということか。





試しに LINE アカウントも作り、通信できるようになった。

あとは、動作時間さえどうにかなればなぁ。



…まぁ、本命は妻のスマホの買い替え待ちか


現在、僕が以前使っていたスマホと併せ、妻は2台持ちで生活している。


新しい機種を買ってみたのだけど、


「スマホ初心者だったので、Android スマホがメーカーごとにかなり使い勝手が違うのを知らなかった」


のが主な原因で、使わずに僕に譲ったのだ。

でも、そろそろ機種差に慣れてきて、本当に欲しい機能が何かまとまってきているようだ。



譲れない機能、諦められる機能などが見えてくれば、適切な1台を買える。

そしたら、少し古い機種が2台余るので、そこにゼロシムを入れればいいだろう。


▲目次へ ⇒この記事のURL

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

歯車

関連ページ

3度目のキッザニア【日記 18/04/22】

3度目のキッザニア【日記 18/04/22】

P10 plus に乗り換え【日記 17/12/18】

P10 plus に乗り換え【日記 17/12/18】

別年同日の日記

02年 ページ更新

03年 東海道旅行終了

04年 忘年会

09年 風邪その後

10年 盛りだくさんの週末

12年 答えは重要ではない


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

IP電話  2017-12-12 17:16:02  コンピュータ 住まい

▲目次へ ⇒この記事のURL

ルーターを入れ替えてから、IP電話が使えなくなった。


…早くどうにかしなくちゃなぁ、って思いながら、元々ほとんど使ってなかった電話なのでほったらかしになっていた。


会社の電話番号なのだけど、関係者はみんなメールとか僕の個人携帯電話にかけてくるので、もし掛かってくるとしてもお役所か、セールス電話だけ。

で、お役所からかかってきたことなんて、ない。


でも、ずっとそのままにはしておけない。

重い腰を上げて、やっと「どうにか」した。


電話番号変わってしまったので、お役所には新たな番号を届けないといけないのだけど。

セールス電話は、来なくなるだろうからかえって良いだろう。




元はといえば、NTTコミュニケーションズの運用する IP 電話を、NTT 純正のルーターで使っていたのだった。


ところが、今年の春にルーターが壊れた。

IP 電話設定できるルーターはかなり古いバージョンが「最新の現役」であり、事実上開発が止まっていた。


というのも、NTTコミュニケーションズは現在スマホで使用できる 050plus という IP 電話を展開していて、家庭用の「固定 IP電話」は縮小傾向だから。

過去に契約した人たちへのサービスは維持しているが、新規獲得する気はないのだろう。



対応したルーターが無いと、使い続けることはできない。

でも、NTT コミュニケーションズ系の IP 電話を、VoIP アダプタで使用している、という人のブログ記事などを見つけた。


なるほど、それで行こう。

というわけで、ルーターと一緒に VoIP アダプタを購入してあった。




NTT コミュニケーションズ「系」という書き方をしたが、過去において展開された家庭用の IP 電話は、NTT コミュニケーションズが直接運用しているものではない。


インターネットサービスプロバイダ…各家庭からインターネットに接続する業者が、サービスを「再販」する形で展開したものだ。


僕はアサヒネットを使用しているので、アサヒネットの「IP電話C」というサービスに当たる。


#朝日ネットでは、他に「IP電話F」も展開している。

 C はコミュニケーションズで、F は富士通のサービスを再販した形。



僕は、アサヒネットから振り出された、NTTコミュニケーションズ系の IP 電話のサービス ID などを VoIP アダプタに設定すればそのまま使える、と思っていた。

でも、話はそんなに簡単ではなかった。




VoIP というのは、Voice Over Internet Protocol の略。

「インターネットで音声通話」って意味合いだな。IP 電話の技術の総称だ。


問題はこれが「総称」であることで、少しづつ違ったいろんな技術がある。

そして、VoIP アダプタでは、ものすごくたくさんの設定項目を用意することで、どの技術にも対応できるようにしてある。


NTT 純正ルーターでは、この「膨大な設定項目」をすべて隠し、ユーザーごとに与えられる値だけを設定すればいいようにしてあった。

というか、VoIP を独自拡張し、設定すべき項目を自動的にサーバーから取得するようにすらしてあったようだ。



この項目を正しく設定する必要があるわけだが、問題は「サーバーから自動取得する」ような値。

NTTコミュニケーションズ系の IP 電話でも、サービスプロバイダによっては公開されていて、公開されていなくても解析されていて、場合によっては一切の情報がない。


アサヒネットは、比較的情報がない方だった。一切ないわけではないが、僕は VoIP の専門知識が乏しいため、正しい設定方法を見いだせなかった。



VoIP を扱う無料ソフトウェア… Asteriskというものがある。

これを使うと電話構内交換機を作れるのだけど、まぁややこしいことはいいや。つまりは、VoIP アダプタの内部ソフトと同じようなことをしているはずだ。


これにアサヒネットの IP電話C を登録している例は、いくつか見かけた。

でも、一般的な VoIP アダプタの設定方法とは、大きく異なる。

そこを解決するだけの知識が、僕にはなかったのだ。




一応書いておけば、春から設定を始めて、夏くらいまではいろいろ粘ったのだ。

アサヒネットの知り合いのつてを頼って、技術の偉い人に「IP電話Cの設定パラメータわかりませんか」なんて直接聞いたりもした。


でも、ダメだった。

NTTコミュニケーションズのサービスを再販しているだけで、詳しいことは知らないんだそうだ。


#偉い人だから末端の細かなパラメーターまで知っているわけがない、という側面もあるとは思う。


得られた答えは「解約して別のサービス使ったほうがいいです」っていう答え。


サービスしている会社の人に解約して、って頼まれるのもすごい話だ。

でも、それだと電話番号変わっちゃうからなぁー、って思ったまま半年が過ぎた。




先ほど、妻に「あの電話結局どうなってるの?」と聞かれて、再挑戦することにした。

もう、電話番号は変わってもいいので使えるようにしよう。


そう腹が決まれば展開は速い。以前から考えていたことはある。


smartalkの電話番号をすぐに取得する。

月額無料の IP 電話だ。その代わり、通話料が少し高い。


でも、元々家の電話は別にあり、仕事用の待ち受け専用だ。

通話料っていうのはこちらから掛けたときに発生するものだから、高くても関係ない。



smartalkはスマホアプリで使うことを前提としているのだけど、普通の VoIP だ。

IP電話Cのような、特殊なことはやっていない。


だから、VoIP アダプタに設定すれば、固定電話でも使用できる。

サポート対象外だから、設定は自己責任で、というだけ。


設定は主にこの辺とか、この辺を参考にさせてもらった。


最初はつながらず、いろいろいじる。

NAT 越えができてないのかな、と思ってルーターにサーバー設定を行い、VoIP ルーターは NAT 越えがいらないようにする。


でもなかなかつながらないなぁ、と思っていたら、パスワードの設定個所を間違えていた。

正しく設定したらあっさりつながった。




調べると、うまく NAT を越えないと「発信は出来るが待ち受けできない」状態になるようだ。

まぁ、仕組みから考えるとそうなるだろうな。


NAT というのはルーターの機能。家庭内の複数のマシンをまとめ、1台に見せかける。


サービスプロバイダは「1台」の接続しか提供しないのだけど、NAT によって複数台を繋げるのだ。

電話をかけるときはこれでいい。


でも「呼び出し」の時は、家の外から接続が行われれる。

機械が1台に見えるからアクセスするのだけど、それはルーターで電話じゃないから通話できない。


これを解決するのが NAT越え、という技術。

これもいろんな方法があるけど、ともかくルーターに「電話にアクセスがあったら VoIPアダプタにデータを渡してね」って教えておく。



今回僕が使ったのは、あらかじめ手動で設定して教えておく、という方法で、NAT 越えは使わない。


設定方法としては難しいので、参考にしたページはみんな「NAT 越え」の一番原始的で適用範囲の広い(でもトラブルも起きやすい)方法で設定するようになっていた。


原理を理解して、一番シンプルな方法を使えば、トラブルは少ない。

うちの設定としてはこれで行こう。




そんなわけで、今まで使っていた(半年ほどは使えないのにお金を払っていた)IP電話C は解約。

解約してください、って偉い人にも言われちゃってたし。


まだ電話番号を誰にも教えていないので、当面どこからもかかってこないはず。




追記 2017.12.20


どこからもかかってこないはず…と思ったら、無言電話が沢山きました。

SIP SPAM と呼ばれるものです。


対策方法書きました。



▲目次へ ⇒この記事のURL

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

住まい

関連ページ

電話機購入【日記 18/08/03】

無言電話(SIP SPAM)【日記 17/12/20】

別年同日の日記

01年 12/11

02年 粗大ゴミ

11年 カレンダー

12年 nexus 7 と US キーボード

14年 ロバート・ノイス 誕生日(1927)


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

リロケータブル  2017-11-27 14:09:53  コンピュータ

▲目次へ ⇒この記事のURL

2年ほど前に、LSI-Cの作者さんの訃報に触れ、追悼文を日記に書いた


LSI-C というのは、コンピュータープログラムに使われる「C」という言語の亜種。(実装の一つ)

作者さんに面識はなかったが、昔お世話になったので追悼文を書いたものだった。


で、そちらの日記を見た方が、Twitter に感想を書いてくださっていた。


#時々エゴサーチしてますよ


MS-DOS には、COM と EXE と呼ばれる、二つの実行形式ファイルがあった。

プログラム言語の話なので実行ファイルとも関連が深く、Cでもこの二つのファイルが作れたことを書いたところ、「初めて知った」と素直に感想をくださったのだ。



あー、…ごめん。

知識を得て喜んでくれたところ申し訳ないのだけど、あちらのページに書いたのは正確ではない。


以前書いたことの概要を示そう。


MS-DOS のC言語には「メモリモデル」という概念があり、プログラムを作るときにはメモリモデルを選ぶ必要があった。


このうち、プログラムとデータをすべてひっくるめて 64Kbyte 以内で作れるものは、COM ファイルになる。

それ以外は EXE ファイルだ。



…でも、これは「C言語で、64Kbyte 以内のメモリモデルを選ぶと COM ファイルを作れた」というだけで、COM ファイルの要件ではない。

COM ファイルで 64Kbyte を超えるデータを扱うことも可能だったし、COM と EXE の違いは、プログラムやデータのサイズよりも大切なことがある。


嘘を書いてしまったみたいで申し訳ないので、もう少しちゃんと書いておこう。




メモリの話なので、簡単な基礎知識から。


メモリは「アドレス」を使って参照される。

アドレス=住所、の名前の通り、1つのメモリ(記憶)には、1つのアドレスが対応している。


1000番地に 123という数値を入れておけば、1000番地を読みだしたときには、必ず123が入っている。

1001番地に 45 という数値を入れても、1000番地の内容には影響がない。

あいかわらず 1000番地は 123 だし、1001番地は 45 だ。


当たり前の話なのだけど、この当たり前が成立するから、安心してプログラムも作れるし、計算もできるんだ。

基本はしっかり抑えておきたい。


コンピューターの中では、文字も、プログラムも、すべて数値で表現される。

だから、メモリの中に文章データも、プログラムも、もちろん計算結果も、すべて置いておける。



もう一つ、以下の説明で使うので「レジスタ」というものを覚えてほしい。

これは、CPU の中にある、特別なメモリ。

アドレスは割り振られておらず、CPU が特別な意味を持って利用する。




さて、MS-DOS に COM ファイルの実行を指示すると、OS は空きメモリを見つけ出して、ファイルの中身をそのままメモリに読み込む。

その後、OS は CPU の中にある「データの場所」と「プログラムの場所」を示すレジスタを、読み込んだ場所にセットする。


そして、読み込んだデータを実行する。

これが、COM ファイル実行の仕組みだ。



「データの場所」と「プログラムの場所」のレジスタとは何だろうか?


MS-DOS が使えるパソコンは、8086 という 16bit CPU を使っていた。

この CPU は、8bit CPU の 8080 の後継機種で、8080 のプログラムを「簡単に移植」できるように作ってあった。


8bit CPU では、メモリアドレスは 16bit (8bit 2個分)あった。これで、64Kbyte のメモリを扱える。

プログラムの中でアドレスを扱うレジスタも、当然 16bit だった。


これが 8086 になると、16bit なのだからメモリアドレスが 32bit になったか…というと、そうでもない。

中途半端に見えるかもしれないけど、20bit になった。

そして、アドレスを扱うレジスタは、あいかわらず 16bit だった。


これは、8bit CPU 8080 のプログラムを移植しやすいようにするためだ。



でも、メモリアドレスは 20bit なのに、レジスタが 16bit では全部を扱えない。

そこで、プログラムの中では「メモリの開始位置」をずらせるようになっていた。


たとえば、「データの場所」として、1000番地を指定したとしよう。

すると、プログラムの中では「234 番地」を指定した場合に、自動的に 1000 + 234 で 1234 番地が使われる。


データの場所と、プログラムの場所は、別々に指定ができた。

だから、最大で 128Kbyte のメモリが扱える。


もしそれ以上のメモリを扱いたいときには、プログラムの中で「データの場所」「プログラムの場所」を示すレジスタを書き替えればいい。



しかし、MS-DOS の COM ファイルは、データもプログラムも同じ場所にあり、さらに場所の書き替えは行わない、という前提で作られる。

最初に書いたように、場所をセットするのは OS の役目で、プログラムはその「場所」で動くことになる。




ここで一つ説明が必要になると思う。


なんで、プログラムやデータを示す「場所」のレジスタをセットする、という必要があるのか。

1234 番地を使いたいのなら、プログラムの中で 1234番地、って書いとけばいいのに。



この答えは単純で、プログラムが同時に複数読み込まれるからだ。


あるプログラムが 1234 番地を使う、と指定していたとしたら、別のプログラムで 1234番地を使ってはならない。

でも、プログラムを作るときに、他の「知り得ない」プログラムが、どこのメモリを使っているかなんてわからないのだ。


プログラムの中では 234番地、とだけ指定して置けば、この問題を解決できる。


2つのプログラムが、それぞれ 234番地をつかおうとしていても、OS が片方は「1000番地から」、もう片方は「2000番地から」使うように指示する。

そうすれば、片方は実際には 1234番地、もう片方は 2234 番地を使うことになり、同時に使って問題ない。



そもそも、8086 が 20bit のアドレスを 16bit のレジスタとの組み合わせで示す、という変なアドレス指定方式を採用しているのは、このような使用方法を想定していたためだ。

MS-DOS の COM ファイルは、素直にそのやり方を実現したプログラム形式なのだ。




でも、これでは大きなプログラムを作れない。COM ファイルの限界を無くしたいときには、EXE ファイルを使う。



COM ファイルは、単純にプログラムを入れてあるだけのファイルだった。

でも、EXE ファイルの中は構造になっていて、少なくとも次の3つのものが入っている。


・プログラム

・データ

・再配置情報


COM ファイルでは、プログラムとデータは混然一体となっていた。

でも、EXE では分離してある。


…まぁ、もちろん混然一体にしてもかまわない。

でも、先に書いたように 8086 は「プログラムの場所」と「データの場所」を別々に指定できる仕組みを持っている。


だから、分離しておけば、読み込み時点で OS が適切にメモリに配置してくれる。



最後に残る「再配置情報」っていうのは何かというと、プログラムを実行する間に OS が書き替えるためのヒントだ。


しつこく繰り返すことになるが、8086 には「データの場所」「プログラムの場所」を、それぞれ 64Kbyte 確保する仕組みがある。

それ以上のメモリアクセスが必要なら、これらの「場所」を示すレジスタを書き替えないといけない。


でも、ここで先に書いた問題が再燃する。

OS が「1000番地から」使うように指示をくれていたのに、勝手に「2000番地から」使うように書き替えることは許されないのだ。

そんなことをしたら、他のプログラムとぶつかってしまう。


そこで、プログラムを作る際には、仮に「0番地から」メモリアドレスを始めて、場所を示すレジスタも、自由に書き替えてよいことにする。

ただし、プログラム中でレジスタを変更する場所は、すべて「再配置情報」に記しておく。


OS は、ファイルからプログラムを読み込み、メモリに配置する際に「再配置情報」を参照する。

そして、書かれた数値に、適切な数値を足していくのだ。


1000番地から使用するのであれば「0番地から」になっている部分に 1000を足し「1000番地から」に変える。

アドレスを指定している個所をすべて変更すれば、そのプログラムはメモリのどこに置かれても、正しく動作する。




プログラムをメモリのどこにおいても大丈夫なように作る…このようなプログラムを「リロケータブル」という。

英語で書けば relocatable。re(再び)locate(配置)able(可能)で、日本語訳は「再配置可能」。


COM ファイルは、そのままでリロケータブルだ。「場所」を示すレジスタさえ正しく整えれば、どこにおいてもそのまま動く。


EXE ファイルのプログラムは、読み込むアドレスを「仮に固定して」作られている。リロケータブルではない。

でも、再配置情報を使って、OS が書き替えを行うことで、リロケータブルになっている。

利用者にとっては気にする必要はないだろう。どちらもリロケータブルだ。



さて、ここでやっと、最初の問題に戻れる。


僕は、COM ファイルの要件を「プログラム、データ含めて 64Kbyte 以内のもの」というように書いたのだけど、実はこれは嘘だ。

COM ファイルはサイズが問題なのではなく、「そのままでリロケータブル」なプログラムを意味している。


メモリのどこに読み込んでも実行できる。

MS-DOS の仕組みでは、「読み込み時点」では、64Kbyte 以内に収まることが大切だ。

これは、ファイルサイズが 64Kbyte 以内であること、と同じ意味になる。


実行された後に、空きメモリを探して確保して、外部データファイルを読み込むのは構わない。

こうすれば、COM ファイルでも 64Kbyte を超えるデータを扱える。




歴史的には、MS-DOS の元になった CP/M という 8bit OS があり、その OS の実行ファイルが COM だった。

8bit なので、同時にいくつものプログラムを読み込むことはできない。


MS-DOS では、8086 の仕組みを利用して、COM を複数同時に読み込めるようにした。

CP/M にはできない芸当で、便利だった。


でも、16bit らしい大きなプログラムは作れなかった。

そこで、MS-DOS の Ver 2 になってから、EXE ファイルの仕組みが拡張された。



先に書いたように、仕組みは違うがどちらも「リロケータブル」なファイルで、ユーザーから見たら特に違いはない。


形式が古く、制限の厳しい COM ファイルを好きこのんで作る理由なんて、どこにもなかった。

DOS 標準プログラムも、ver1 から使われている command.com 以外には、非常に小さなプログラムでもほぼ EXE で作られていたと思う。


しかしまぁ、ファイル構造を示すヘッダがない、構造を解析してパッチを当てる時間が不要、などの理由で COM ファイルは「実行が速い」とされた。

ディスクアクセス時間に比べれば、そんなものは誤差範囲レベルなのだけど。


制限が厳しいからこその腕試し、というような側面も相まって、それなりに COM ファイルは作られていたと思う。




さて、ここからは余談。



EXE ファイルのような、「OS がアドレスを変えることで」どこにでも読み込めるようにする…という形式が、いつ頃考案されたのか僕は知らない。


マルチタスクなら、複数のプログラムがメモリに読み込まれるので、当然「プログラムをどこにおいても良い」、つまりはリロケータブルである必要がある。


マルチタスクの元祖は、Multics か、その前身となる実験だった TSS あたりになるのだけど、今調べたら TSS では当たり前に「リロケータブル」となる仕組みが作られていたようだ。


おそらくは、シングルタスクでも複数のライブラリを組み合わせて使用する場合などで、アドレス調整の必要からリロケータブルの仕組みが作られたように思う。



以前調べた中では、WhirlWind I のライブラリプログラムは、リロケータブルにできるように作られていた。

もっとも、これは OS が仕組みを作っているとかではなくて、ソースコードレベルで「別のアドレスに置くときは、ここの部分を改造する」など、適切なコメントを人間に残す形なのだけど。


ともかく、プログラムを置くアドレスが変わっても、正しく動作するプログラムを作ろう、という意識はあったことになる。

となれば、後はどこかの段階で、機械的なサポート方法が考案されたのだろう。



MS-DOS は、Ver 1 では COM ファイルしか使えない。

CPU がサポートする機能を使ってリロケータブルを実現してはいるが、「OS の機能」として、制限の少ないリロケータブルをサポートするのは Ver 2 以降だ。


大型機で使われていた技術を取り入れたものだろう。




X68000 という 16bit パソコンがあった。

CPU に 68000 という、昔の Apple Macintosh や、セガの「メガドライブ」に使われたものと同じ LSI を使用していた。


この CPU では、MS-DOS は動かない。

だけど、MS-DOS を参考にしたと思われる、Human68k という OS を標準搭載していた。



実行ファイルも、MS-DOS のように2種類あった。x 形式と r 形式だ。

x 形式は、EXE と同じように、実行前にプログラムが OS によって書き替えられる。


r 形式は書き替えずにそのまま実行する。この点は COM ファイルと同じだ。

でも、68000 には MS-DOS のような「メモリの始まる場所」を示すような数値はなかった。


それでも、リロケータブルなプログラムを作ることができた。




8086 では、アドレスを表すのに3つの方法があった。


・今実行中のアドレスに、1byte 分、-128~127 の数値を加える。

・今セットされている「場所を示すレジスタ」を先頭として、2byte 分、0~65535 の数値を加える。

・場所を示すレジスタも書き替えて、全メモリ(20bit)を指定する。



これに対して、68000 では、大きく分類して2つのアドレス指定方法があった。


・今実行中のアドレスに、2byte 分 -32768~32767 の数値を加える。

・全メモリ (24bit) を指定する。



8086 の COM ファイルは、「場所を示すレジスタ」を OS がセットしてくれるのを前提として、リロケータブルになっている。


それに対し、68000 では、レジスタの助けを無しにリロケータブルにできる。

アドレスの範囲は同じ 2byte に見えるが、常に「実行中のアドレス」を中心とするため、作り方次第で 64Kbyte を超えるプログラムも作れる。


68000 の「リロケータブル」は、8086 の「リロケータブル」よりも、もっと制限が少ないのだ。



でも、X68k では、「 r 形式」としてリロケータブルなプログラムを実行できるようになっていたにも関わらず、開発のためのサポートはなかった。


MS-DOS なら、C言語でメモリモデルを選択すれば作れた。

だけど、X68k のC言語は x 形式しか作ることができず、r 形式を作るには、アセンブラですべてを書くしかなかった。



先に、MS-DOS でも COM を作るのは腕試しの側面があった…というようなことを書いた。

とはいえ、C言語でも簡単に作れる。


でも、X68k の r 形式はすべてをアセンブラで書く必要がある。

「適切に書かれれば」という前提付きだけど、C言語の生成するコードよりも効率が良く、高速動作する…ことも考えられる。


だから、r 形式のプログラムは「速い」という神話が生まれた。

いや、ただの神話で、r だから速いなんてことは全然ないのだけど。


僕もあこがれて、いくつかの小さなプログラムを r 形式になるようにアセンブラで書いていた。

まぁ、習作だよね。特に発表はしてなかったと思う。


#特に、シングルタスクの OS 上でマルチタスクな動作を実現する「常駐プログラム」はアセンブラで書く必然性があったので、そういうものを試作していたはず。


大学2年生の時に作った、BANDITS も r 形式ではなかったかな。

ただ、このゲームは未完成。習作何本か作っていい気になって大作に挑み、失敗した。


技術が伴わないのに大きな目標を立ててはいけませんね。



▲目次へ ⇒この記事のURL

関連ページ

【追悼】森公一郎さん (LSI-C の作者)【日記 15/01/20】

別年同日の日記

03年 ピザ

06年 クリスマス飾り

15年 エイダ・ラブレイス 命日(1852)

15年 NTT工事延期

16年 セガ・サターン復活


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

Android Chromeでスクロールがおかしくなるバグの原因と修正  2017-10-27 11:30:48  コンピュータ

▲目次へ ⇒この記事のURL

フリーのプログラマーとしてやっているので、仕事内容はどんどん変わる。

ここ数カ月は、ある企業の WEB サイトデザインの大規模変更を手伝っている。


すでに長年運用されているサイトで、Wordpress で構築されている。

プログラムは拡張を繰り返してスパゲッティ状態だが、今回は「デザイン改修」が趣旨なので、プログラムは出来るだけそのまま活かして…

という指示。


ほぼ完成していたのだが、今月の中ごろに、一部の Android 端末でスクロールがおかしい、というバグが報告された。




Chrome のアップデートで、スクロールがおかしくなるバグが混入したらしい


…と報じているサイトがあった。9月28日の記事で、アップデートは9月25日…ということになっているが、実際には19日。


#Android アプリを配布する Google Play ストアでは、バグやウィルス入りのアプリが一気に広まるのを防止するため、複数のサーバーで徐々に配信が開始される。

 アプリの登録・公開は19日だったが、実際にアップデートが入るのは端末ごとに接続するサーバーにより異なり、25日が嘘だということではない。



あぁ、Chrome のバグならしょうがない。そのうちアップデートされるだろうから、この件は一時保留…となったのだが、大きなバグに思える割になかなか修正されない。


クライアントからの強い修正依頼もあり、たとえ Chrome に原因があろうとも、多少別の機能に影響が出ても回避・修正せよ、となったのが昨日。

徹底的に原因の解明が始まった。




改めて確認すると、自分の端末でもバグが出た。


先日新しい端末にしたばかりで、以前の端末では問題が出なかった…と思う。

普段は PC の Chrome で、スマホエミュレートして確認をしているが、やはり問題は出ていない。


ともかく、手元でバグを再現できるようになった。こんなに心強いことはない。

しばらくいじって、バグの出る状況を確認。



スマホのブラウザの場合、スクロールによってアドレスバー…URL を表示したり、入力したりするところが、現れたり消えたりする。

この状態が切り替わった後、最初の Idle 状態にブラウザがなった時に、スクロール位置がトップに戻ってしまう、というバグが出現した。


Idle 状態って表現は説明がいるだろう。

アドレスバーはスクロールに合わせて出入りするが、スクロールが「止まって」も、指が放されるまではスクロールが続いている、と考える。

また、指を放す際にフリックすると、慣性スクロールが始まる。この慣性スクロールが終わるまでは、スクロールが続いている。


そして、スクロールが終わった時が「Idle 状態になった時」だ。

この瞬間にバグが出る。



多少の心当たりはあった。

作製しているサイトでは、画面上にある「ナビゲーションボタン」を、スクロールに合わせて表示を切り替えていた。


ページ表示時には、ページのヘッダ部分があり、その下にナビゲーションがついている。

文章を読み進め、下に向かってスクロールすると、当然ヘッダとナビゲーションは上に消えていく。


…はずなのだが、ナビゲーションがちょうど画面の上に貼りついたタイミングから、ナビゲーションだけがその位置に固定される。

CSS を position:fixed に変えているわけだが、これは画面スクロールに合わせて行っている。


スクロールのタイミングに合わせてバグが出る、というのは、この一連のプログラムと関係があるのかもしれない。

そこで、Javascript の該当プログラムを動かないようにしてみる。


…それでもバグは出た。




サイトはすでに古いものだし、Wordpress で構築されている。

他にも無数の Javascript プログラムが動いている。


このどこかでおかしくなっているのかもしれないし、全く違うバグかもしれない。


いろいろとプログラムや CSS など、外部から読み込むプログラムを外しては、リロードしてみる。

この最中、不思議なことに気が付いた。


ある程度スクロールを進めた状態でリロードを行うと、まず画面のトップ位置が表示され、続いてリロード前の位置にジャンプし、さらにまたトップ位置に戻される。


…普通は、直前まで読み進めた位置にジャンプして終わりのはずだ。最後の「トップ位置に戻る」が余計だ。


何度かリロードして観察して、このタイミングは、画面上の全要素を配置し終わったタイミング、いわゆる「window.load」だ、と見きわめた。

Javascript で何か処理が行われている可能性が高い。



無数の Javascript ファイルのどこで処理が行われているのかわからないが、ステップ実行を延々と…10分以上も繰り返して、やっと最後の「おかしな動作」をするタイミングを見極めた。


ウィンドウのロード、リサイズ時に、document.body.scrollTop を調べ 0 ならば window.scrollTo(0,1) する、というプログラムがあった。




このプログラム、5年くらい WEB サイト構築をしている人なら何かわかるだろう。


5年ほど前に、「ページを開いた瞬間から、アドレスバーが消えて画面が広く読みやすい」という WEB デザインが流行したことがある。


アドレスバーは、下にスクロールすれば消える。これを Javascript で実現するのが、上のプログラムだ。

ロード・リサイズ時に画面の一番上を表示していたら…つまり、ページ読み込み直後なら、1ドットだけ下にずらしてやる。

すると、アドレスバーが消えた。


しかし、アドレスバーが消えると表示中のサイトの URL もわからなくなるわけで、フィッシング詐欺には好都合だった。

他のサイトと同じような動作なら疑問に思う人もいない。そういう詐欺サイトが横行した。


これをうけて、スマホのブラウザでは、人が操作しない、Javascript でのスクロールはアドレスバーに影響を与えないようになった。



つまり、先のプログラムは今となっては無意味だ。

無意味だけど、やっぱり読み込み直後には1ドットスクロールする。

それ以外は何もせず、無害なプログラム、のはずだった。




スクロール位置は、古くは document.body.scrollTop で調べられた。

しかし、body 要素は「ドキュメントの表示部分」を意味する。それに対し、スクロール位置というのは、表示ウィンドウの問題とか、もっと別の次元のものだ。


この論理的なおかしさをただすため、document.documentElement.scrollTop でスクロール位置を調べる、という方法が標準化された。


Chrome の元となっていた webkit にもこの変更は反映された。

だけど、コンパイル時のオプション設定により、新しい「標準モード」と、古い「互換モード」を、切り替えられるようになっていた。


Chrome では過去との互換性のため、body.scrollTop が使い続けられていた。

しかし、9月頭にアップデートされた Chrome で、body.scrollTop から documentElement.scrollTop に切り替えられたらしい


こちらにgitログがある。

 …が、超巨大なページの上、技術者でないと意味が分からないので、特に興味が無ければ読まないのがお勧め。

 で、このログで scrollTopLeftInterop を検索すると、default が Enable され、WebView が Disable されているのがわかる)



これは、「いつか行う、と予定されていた変更」が実行されたに過ぎない。


すでに documentElement を使用していたブラウザもあるし、「ブラウザを調べて」ではなく、「環境を調べて」動作を変えるプログラムを作っておかなくてはならなかった。


そのための期間も十分に与えられていたにもかかわらず、動作がおかしくなったサイトがあったとすれば、そのサイトに潜在バグがあったと言わざるを得ないだろう。


これは Chrome のバグなどではなく、もちろん今後のアップデートで修正されるものでもない。




上に書いたのはデスクトップ版の話で、同じ変更が9月下旬に Android 版 Chrome に入った。


今後、body.scrollTop は、実際のスクロール位置を反映せず、常に 0 となる。



これが、2012 年ごろに流行った「アドレスバーを消す」ための Javascript と、非常に相性が悪い。


画面ロード時・リサイズ時には、本来「現在のスクロール位置が 0 なら」、scrollTo(0,1) でアドレスバーを消していた。

これが、現在のスクロール位置に関わらず、いつでも scrollTo(0,1) で、ページトップに戻ることになる。


いや、これでもまだ、PC 版で同じプログラムが動いていたとしてもあまり害をなさない。

ロード時に動くのは問題ないし、ページ中でのウィンドウリサイズも、それほど行わないからだ。



スマホだと、スクロールしただけで、アドレスバーが表示・消去される。

アドレスバーを消す理由は、コンテンツの表示領域を広げるためだ。


このため、Chrome ではスクロールしただけでリサイズイベントが発行されることがある。

どうも、このイベントの発行は、Scroll イベントが置き続けている時は避けて、Idle 状態になった時に行われるようだ。



これで、最初に書いたバグの条件がすべて整った。


スクロールに伴い、アドレスバーの表示・非表示が切り替わると、その後最初に Idle 状態になったタイミングで、現在のスクロール位置に関わらず、画面トップに戻される。




原因が理解できれば、修正も簡単。

幸いなことに、「1ドットスクロールさせる」というプログラムは、2012年頃には意味のあるものだったが、今では全く意味をなさない。

このプログラム自体を消してしまおう。


これで正常な動作に戻った。



今回の仕事ではこれで終わりだったが、「スクロール位置を変更したい」場合の動作も変わっているらしい。


jquery 的表現だと、今まで Chrome は $('body').scrollTop(y) などでスクロール位置を指定できた。

これを、$('html').scrollTop(y) にする必要がある。


…FireFox では、html に指定しなくてはならなかったので、$('html,body').scrollTop(y) としているサイトも多いかもしれない。

この場合、特に問題は出ず、今まで通り動き続ける。


機種判別して使い分けていた場合は、修正が必要だ。


▲目次へ ⇒この記事のURL

別年同日の日記

01年 10/27

02年 妹主演の劇を見る

04年 枝豆

11年 太陽電池

16年 ダイナマイト刑事


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


戻る
トップページへ

-- share --

16000

-- follow --




- Reverse Link -