コンピュータ37ページ目の日記です

目次

前のページ
2020-11-18 経年劣化2
2020-11-23 サーバーダウン
2020-12-07 HTMLで多数のデータを表示する。
2020-12-13 ピクミン3デラックス
2021-01-23 100倍規模
2021-01-26 ノートパソコン修理
2021-01-29 微分積分いい気分
2021-02-23 Lenovo Ideapad Duet 購入
2021-03-01 IdeaPad Duet の使い勝手(1/2)
2021-03-01 IdeaPad Duet の使い勝手(2/2)
2021-03-16 暮らしの中の微分積分
経年劣化2  2020-11-18 18:20:12  コンピュータ

▲目次へ ⇒この記事のURL

先日、電源というのは経年劣化する消耗品だよ…という話を書いたら、そのすぐ後に大きな「電源」が経年劣化で壊れた。


先日書いた意味での「電源」は、交流・直流を変換する機器の意味で書いたのだけど、今回壊れたのは、UPS。


UPSというのは「無停電電源装置」と呼ばれる。

コンセントから常に充電し続け、ふたたび交流 100V を出力する機械。

停電が起こっても、しばらく 100V 出力を続けられる。


まぁ、実際停電になってもサーバーを止めないでよい、というほどの効果はない。

時々起こる瞬停に対応できるというのが最大のメリットか。


ちなみに、瞬停とは、0.1 秒程度の短い停電。

電力会社が、何らかの都合により送電経路を入れ替えるときなどに発生する。


最近の機械は、0.1秒程度の停電には耐えられるような電源を使用しているけど、動作は保証されない。




我が家の UPS は、2年前に「買い替え」ていたのだけど、古いものも残っていた。


これは全くズボラな話で、新しい装置にサーバーなどの停電が致命的なものは繋ぎ変えたのに、ルーターやハブなどの「致命的ではないが、なんとなく止めづらい」ものを繋ぎ変えてなかったため。


で、壊れたのは古い UPS 。

夜、寝ようとしていたら急にサーバールームから「ピーーーーー」という連続 Beep 音が聞こえてきて、慌てて原因を探ったら UPS だった。


すぐ電源切って、ルーターなどを新しい UPS につなぎなおした。


勘違いでつなぎなおしていないネットワーク機器があり、うまくネットがつながらなくて焦ったけど、実際のところつなぎなおしたら済む程度のトラブルだった。




この UPS 、いつかったっけかな…


少なくとも、2011 年の東日本震災の時には使っていた


普通は2~3年で寿命、と言われるので、使い過ぎ。

まぁ、だからこそ2年前に買い替えていたのだけど。


電源は劣化するよ、なんて話を書いていたのに、自分がお粗末でした。



▲目次へ ⇒この記事のURL

別年同日の日記

01年 11/17

02年 予約特典

04年 CSV-S57改造

13年 ミッキーマウス&ポール・モカペトリス 誕生日

14年 ポール・モカペトリスの誕生日(1946)

16年 ら抜き言葉

19年 自宅電話回線その後


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

サーバーダウン  2020-11-23 12:17:12  コンピュータ

▲目次へ ⇒この記事のURL

三連休の初日から、サーバーがダウンしていたようだ。


悪いタイミングで落ちたもので、連休中は家族と過ごす時間が多く、気づかなかった。

ツイッターで教えてくださった方に感謝。


原因は DB の一部破損で、テンポラリデータで特になくなって困るものではなかったので、テーブルを作り直した。

これで安定動作するか、しばらく様子見。



4時間後に追記


…やっぱだめだった。

「しばらく様子見」と書いた5分後には、落ちた。


仕方ないので、一旦「トラブルにつき復旧中」の旨を静的ファイルで表示するように設定変更。


どうも、mysqld が落ちてしまうようだ。原因究明。



えーと、紆余曲折あって、たぶん解消。

途中、何度かサイト再始動しては、落ちるを繰り返している。


原因が何かわからないため、たぶん原因ではない「問題になりそうな点」も、順次解消して回った。


innodb の設定を変更してみたり、通信バッファを広げたり。


DB の全データをバックアップして、設定を変えた状態でリストアしたり…

つまりは、DB のファイル構造を作り直したりもした。


でも、たぶん真の問題はメモリ不足。

仮想サーバーなので、メモリ割り当てを増やしたら安定した。




こういう時の作業は、たいていは素直にはいかず、些細なトラブルが頻発する。

そして、些細なトラブルを乗り越えるのに時間がかかる。


そのため、思った以上に時間がかかってしまった。


(こういう時の作業は、普段起こらない「極端な負荷」をシステムにかけるもので、普段出ないエラーに遭遇する。

 たいていは、設定を少し見直せば済むだけの些細なものだが、普段見ないエラーだから意味と対処法を調べるのに時間がかかるのだ。)


また様子見だが、今度は大丈夫だと思う。…思いたい。


▲目次へ ⇒この記事のURL

別年同日の日記

01年 11/22

04年 不動産取得税

09年 Netwalker いじってみた。

15年 「ちきゅう」一般公開

15年 三菱みなとみらい技術館

16年 畳替え


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

HTMLで多数のデータを表示する。  2020-12-07 18:32:02  コンピュータ

▲目次へ ⇒この記事のURL

作成している WEB サービスで、データを1万件ほど表示する必要があった。


それまで作っていたスペックでは、せいぜい 100件程度だった。

HTML で小さなウィンドウを作り、その中を CSS 設定で縦スクロールするようにして、内部に 100件のデータを入れる。

まぁ、よく見るインターフェイスだ。


そのプログラムのまま、中身を1万件にしたら、いろいろと問題が出た。




まず、表示を指示してから実際に表示されるまでが遅い。

そして、表示されてから、スクロールしようとすると非常に重い。


1万件ものデータ処理だから遅いのかな、と思って、Javascript の速度を調べると、

データ処理には 100ms 程度しかかかっていなかった。


表示までは5秒程度かかったのだが、これらはほとんど、挿入された HTML の解釈時間だということになる。


いろいろ実験するも、1000件程度までは実用になるのだが、1万件になると実用的な速度ではない、と分かるばかりだった。




初期表示の遅さについては、まず 100件程度を表示してから、徐々に追加していったらどうだろう、とか試してみた。


確かに、すぐに表示はされるのだが、その後スクロール処理がどんどん重くなる。

1/10 秒ごとに 100件づつ追加、とかしていると、この追加のたびにかかる処理速度も、どんどん重くなっていく感じがする。


…うん、たぶんすでに表示しているデータ件数 n に対して、新たなデータを入れるときの処理速度が n*log n に比例しているのだ。


これ、プログラムしているとよく見る構造だ。つまりは、内部的に DB を構築していて、データ件数が多くなると挿入速度が遅くなっていく。


実際、HTML は内部で DOM ツリーというものを構築する。これはツリー構造の DB に他ならない。

何か操作を行うたびに、このツリーをたどり、どの部分を操作対象とすべきか、画面表示の対象とすべきか、などをチェックしていく。


ここら辺は、ブラウザ内部での処理の問題なので、Javascript で高速化できる問題ではない。




問題を棚上げして別の仕事をしていて、ふと気づいた。


そもそも、HTML の量が多いのが問題なのだ。Javascript 側は、1万件くらいなんてことない。

じゃぁ、HTML のコード量は最小にしよう。


先に書いたように、データの表示は小さなウィンドウ内で、スクロール表示になっていた。

1万件あっても、実際に表示されているのは 10件程度だった。



div のスクロールイベントにフックをかけて、現在のスクロール位置を取得する。

データは、1行1データのようにきれいに並んでおり、1行の高さも決まっていた。

なので、スクロール位置から、現在表示されるデータが何行目かも判断できる。


何行目を表示するかわかれば、それより「上」に何行あるかもわかる。これらは画面外のデータだ。

だから、HTML としては最小限に、全部をまとめて「高さだけ」をブラウザに伝えることにした。


div を作り、style で height を指定すればよい。

下方向も同じように、画面外は div 1つで済ませる。


そして、表示したい部分の10行ちょっとだけ、その場で生成してブラウザに渡す。

10行程度なので、ブラウザは瞬時に解釈を終え、遅延なく表示される。


上下に div を作っているのは、スクロールバーを「あたかも1万件のデータがあるように」表示するためだ。

でも、HTML には10件程度のデータしか入っておらず、スクロールするたびに書き換える。



実際には、そのプログラムでのデータ表示はこれほど単純ではなく、一部だけ行の高さが変わったりもしていた。

でも、規則性があるので div の「高さ」をそれに合わせて調整するような計算式を作った。


上端と下端の部分も、破綻しないようにプログラムする必要がある。


しかし、それらは些細なことだ。




大量のデータで HTML が遅い時の処理方法をネットで探していたが、あまり見当たらなかった。


DOM の遅さ、という話になると、単純なハンドリングの速度の話だけで、極端に多いデータの際にスクロールすら遅いのをどうにかできないか…というような話題にはならないのだ。


まぁ、個別論だから一般的に論じにくい、というのもあるとは思うが。


今回の例では、スクロールのたびに DOM を大きく入れ替える、という「DOM が遅い」という話題ではやるべきでないことをしている。


でも、それによって HTML 量を極端に減らすと、DOM の処理速度は劇的に改善する。



…やっていて「時期尚早な最適化は害悪」という言葉を実感していた。


当初は、今までのやり方で何とかならないか、と最適化を試みていたんだ。

でも、どうにもならないと思って大きく作り変えたら、問題は簡単に解消した。


しかも、このプログラムは速くなるようになんて書いてない。

DOM 操作に jQuery とか使ってるし。

(古いプログラム部分が多いので、過去に作った部分はそのままなのです)



最適化を考える前に、根本原因が何かをちゃんと見極めよう、って話です。



▲目次へ ⇒この記事のURL

関連ページ

100倍規模【日記 21/01/23】

別年同日の日記

01年 12/6

02年 中間決算

05年 同時接続数規制

14年 ハイキング

15年 2つの格安SIM

15年 2つのSIMフリー スマートフォン


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

ピクミン3デラックス  2020-12-13 18:03:45  コンピュータ

▲目次へ ⇒この記事のURL

一応遊んだので感想を書いておこうと思ったのだが…

世の中的には絶賛されているゲームなのですが、僕としては残念な出来、と最初に書いておきます。

そういう感想記事です。




基本的に人に勧められるようなゲームでないと感想は書かないので、「感想を書く程度には面白かった」と捉えてください。

悪いゲームではないです。


ピクミン1、2に関しては、かなりやり込みました。

当時は子供もいなかったのでね。


Wii U で発売された3は遊んでいません。Wii U 持ってなかったし、その頃は子育てが忙しすぎて、ゲームどころではなかった。

Switch 購入以前も、子供は多少テレビゲームを遊んでいましたが、それほどやっていません。


だから、Switch 購入時には、すでに旧型であった Wii U を買ってピクミン3を遊びたい、と子供に言われました。

僕は今更 WiiU を買うつもりはなかったので、「多分 Switch には移植されるので、出たら買う」と子供に約束しました。


これはなだめるための適当な約束のつもりではなく、ゲームキューブのピクミンはその後 Wii に移植されているためです。

Nintendo 64 のゼルダもゲームキューブに移植されていたり…

「あまり売れないゲーム機で発売されたが、名作と呼ばれるものは、任天堂は次のゲーム機に移植する」と考えていました。


発売までにずいぶん時間がかかりましたが、実際移植されたので購入しました。




遊んでみて、最初から多くの違和感に襲われました。

これは、ピクミンの名を冠してはいるが、別物のゲームだ、というのが正直な感想です。


なぜこんなことになったのか、いろいろと原因を考えながら遊んでいたのですが、やっと一つの推論に辿り着きました。


おそらく、ピクミン3は外製のゲームエンジンを使用して作られているのではないか、と。


ゲームエンジンとは、ゲームを作るのに必要なプログラムをまとめたライブラリです。

どんなゲームにも共通で使われるような処理、というものは存在しており、それらをまとめて販売しているものです。


こうしたエンジンを使用することで、ゲームを作る工程は大幅に削減され、開発期間が短縮でき、コストも抑えられます。


また、通常はゲームエンジンは、様々な環境に移植されています。

グラフィックスやコントローラー周りの「機種ごとの差」が大きい部分は全部ゲームエンジンが対応し、ゲーム本体のプログラムは純粋にゲームだけを作成すればよいのです。


結果として、大きな移植の手間もなしに、複数の環境への対応が完了します。

ゲームエンジンを使用するメリットは大きいのです。



ピクミン1のころは、こうした「ゲームエンジン」という概念は普及前でした。

もちろん、各社が独自にライブラリを作ったり、概念的に近いものはあったのですが、専門にゲームエンジンを作成するような企業があったわけではないのです。


ピクミン2も、おそらくはピクミン1の改造として作られているので、ゲームエンジンは使用されていないでしょう。


でも、おそらくピクミン3では、任天堂外の会社が作成したゲームエンジンを使用しています。

…これは推論にすぎませんが、この違いがゲーム性に大きな違いを生み出してしまっています。




現代的なゲームエンジンには、物理演算の機能が含まれるのが普通です。

キャラクターごとに重さや弾力性などを設定し、他のものに「ぶつかる」かどうかを設定し…

各種設定を行っていけば、プログラムを1行も書かなくとも、一般的な物理現象に従った動きは行ってくれます。


ピクミンは、まるで本当に存在しそうな「小さな生物」たちが冒険するゲームです。

1の時から、存在しえないファンタジーであることは理解したうえで、非常にリアルな世界観で人気を呼びました。


おそらくは、その「リアル」を上乗せするために、物理演算も使用したゲームエンジンを組み込んだのではないかと想像します。


しかし、ゲームはファンタジーの世界に遊ぶから楽しい、という場合があります。

リアルは制限されなくてはなりません。


ピクミンの場合、1・2では、ピクミン自体は「個々には存在するが、互いに干渉しない」存在でした。

100匹の集団がいるのではなく、1匹のピクミンが100体いるのです。




ですから、操作次第では、非常に小さなスペースに100匹のピクミンを押し込めることができました。

作業をするときも、狭いスペースに多人数を投入し、すぐに終わらせることができました。


多くの部下を効率的に使う、というピクミンのゲーム性は、こうして作られたものでした。


しかし、3のピクミンは「100匹の集団」です。お互い干渉するため、連れ歩くには広いスペースが必要になります。

限られた作業スペースに多人数を配置すると、「押し出されて」作業しないものが生じます。


壁を壊そうとしても、働かないピクミンが出るため、投入人数に比例した作業速度は得られません。

荷物を運ぼうとしても、上限人数にはまだ達していないのに、なかなかピクミンが作業しようとはしません。


こうした「リアル」のために、ピクミンの楽しみの一つである「やり込み」が大きな制限を受けます。

一番重要な要素…人数を割り振ることによる、時間短縮が行えないのです。


ピクミンの楽しさの一つは、人数配置を考えることでした。

その要素は残されているのですが、「思ったように動かない」のは、非常に残念なことです。


(注:厳密にいえば、1でも多少の干渉はありました。

 狭いスペースにピクミンを多数投げ込むと、押されて落ちてしまう、など。

 しかし、基本的には「プレイヤーの意思を妨げない」ように作られていたのです。

 3では、プレイヤーの意思に反する動きをすることが非常に多いです。)




先に書いたように、ピクミン1・2では、非常に狭い空間にピクミンを押し込めることができました。

これを使って、獰猛な敵からとにかく逃げ回ることも多いゲームでした。


しかし、ピクミン3では、ピクミンの集団はある程度の広がりを持ちます。

敵が獰猛なままでは難しくなってしまうためか…よほどのろのろしていない限り、敵が襲ってこなくなりました。


なので、集団で襲い掛かれば、安全に敵を倒せます。敵が襲ってくる前に倒してしまえるので。

1・2では敵に対して慎重に対処しなくてはなりませんでしたが、3は力押しのゲームです。


結果的に、敵はピクミンの餌にすぎません。

弱肉強食の食物連鎖を描いたことで文化庁メディア芸術祭優秀賞をとったピクミンですが、3ではそうした食物連鎖を感じさせないのです。



「力押しのゲーム」になってしまった原因は、他にもあります。

ピクミン自体が死ににくくなったためです。


水に落ちてもおぼれません。しばらく泳いでいるので、呼べば上陸します。

火がついても死にません。しばらく走り回っているので、呼べば火が消えます。

電撃を受けても死にません。気絶して倒れているので、呼べば起き上がります。


一応、赤は火に強い、青は水に強い、黄色は電撃に強い…などの特性はあるのですが、あまり気にせず力押しで何とかなります。


1・2のころはすぐに死んだので、死なないように考えるパズルゲームでした。

しかし、3は「死にそうになったらすぐ呼べばよい」という、忙しいアクションゲームです。




物理演算の話に戻るのですが、敵にくっついていたピクミンが「ふりはらわれる」ことがあります。

この時、ピクミンは1・2のころよりもはるかに遠くまで飛ばされます。


これもおそらくは、物理エンジンの挙動のためではないかと思いますが、詳細はわかりません。

ともかく、遠くまで飛ばされて、時として「本来は入れない」エリアに入ってしまうことがあります。


そして、入れないエリアからでも戻ってこられれば良いのですが、戻ってこれないことも多いのです。

そもそも入れない場所だから、歩き回れるような設計になってないのでしょうね。



こうした、意図しない箇所にピクミンが入ってしまう、という挙動には、作成スタッフも悩んだのではないかと思います。

ゲーム中いたるところに、「通り抜けられない見えない壁」が設置されています。


そして、場合によっては…というか、ごく普通になんですけど、「特定のことをして道を作る」部分にも設置されています。

たとえピクミンやプレイヤーが進めたとしても、その「特定のこと」をしていない限り、見えない壁に阻まれて前に進めないのです。


初見プレイで仕掛けを知らず、「どうやって進むのだろう?」と考えたとします。

いくつか仮説を立ててやってみます。そういうことができる楽しさがピクミンなので。


でも、たとえうまく進むことができても、制作側の考えと違う場合は「見えない壁」が立ちはだかるのです。

制作側の考えがなんであるかは、見た目からはわかりません。超能力者のように相手の考えを読まなくては先に進めないゲームになるのです。


…本来なら、「正解以外の方法で目的を達成できない」ような作りになっていればよいのですが、別解がいくつも作れてしまうことが問題だと思います。

でも、別解は許されないのです。


まぁ、実はこれは些細な問題で、初回プレイが楽しくないだけです。

何度かプレイして正解がわかれば、後は正解以外のプレイをしなくなるだけなので、楽しく遊べるようになります。


…初回プレイのイライラで嫌にならなければ、ですけど。




さて、上に書いた「見えない壁」ですが、ピクミンのサポートのためにも存在します。

先に書いたように、ピクミンの大集団は広がりを持ちますが、そのままでは狭い橋を渡るときなどに困るのです。


そうした場合、見えない壁がそっとピクミンをサポートし、落ちないようにしてくれます。

なんて親切設計。


…でも、この壁、万全ではないのですね。ピクミンが多数で押し合いになると、壁が乗り越えられてしまうことがあります。


初心者プレイヤーのイライラの対象となる「見えない壁」が、サポートとしても不十分で、上級者プレイヤーのイライラのもとにもなるのです。



ところで、今作ではピクミンが単独行動をとることもあります。

1・2では、基本的にプレイヤーキャラについて歩き、「獲物を持ち帰る」時だけ単独行動でしたが、その行先はロケット前という「安全地帯」でした。


3では、往復作業が設定されています。作業が終わったらもとの地点に戻り、まだ仕事があれば続けて作業するのです。

この場合、すべての作業が終わった後は、「元の地点」に戻ったところで待機します。



ピクミンでは、日没…時間切れの際に、ロケット前か、隊列にいないものは死んでしまうことになっています。

なので、待機場所があるならそこで待機、というのは重要なことです。


しかし、先ほどから書いている「ピクミン同士が押し合う」問題で、全く予期しない地点で待機するピクミンが出ます。

往復作業中にほかのピクミンに押され道を外れると、時として「戻り方がわからなくなり」そこで待機するのです。


これは突発的におきます。

往復作業の時間が乱れますし、日没時の死亡にもつながります。




さて、ゲームエンジンが原因になっているのではないかな、という問題点はこんなところ。

でも、ピクミン3の問題点はこれだけにとどまりません。


キーワードは「高低差」ですね。


1・2では、地形は基本的に平面に近い構成でした。

高低差はありましたが、なだらかなものでした。


しかし、3には激しい高低差があります。

それだけなら、起伏にとんだ地形で3Dのゲームらしさを出している…と言ってもよいのですが、これが問題を起こします。




まず、カメラが自由に動かせなくなりました。

「カメラを動かしても目的物が見えない」場合も含みます。


ピクミン1でも、突発的に高さが変わる部分はありました。

しかし、そういう部分はマップ構成が工夫されていて、カメラアングルをあまり変える必要はありませんでした。


それに対し、3では、普段歩き回っているフィールド内で、結構な高低差があります。


この高低差により、カメラの動きが制限されます。

見やすい位置にもっていこうと思ってもカメラが動かせなかったり、動かせても別のものに見たいものが隠されてしまったり。


敵との戦いで緊迫しているときに「見えない」というのはかなり致命的ですが、頻繁に起こります。

(慣れれば、最初から戦いやすいアングルに固定できますが)



そして、一番の問題は「上からのアングルが無くなった」ことでしょう。

ピクミン1・2では正確な操作を要求されるところが多々あり、真上から見た視点が非常に役立ちました。



例えば、最も基本的な雑魚敵「コチャッピー」は、背中にピクミンを乗せると一撃で倒せます。

この位置はかなり正確に狙う必要があり、ピクミンを投げたときの着地点である「カーソル」の微調整が重要でした。


ピクミン3でも、コチャッピーは同じ方法で一撃で倒せます。

しかし、上から見られないので、正確な位置が把握できません。


一応、「ロックオン」という操作が追加されていて、カーソルを近くの対象物に固定できるのですが…

適当にロックオンされるだけで、コチャッピーを一撃で倒せる正確な位置にはカーソルを合わせてくれないのです。


(ピクミンの種類ごとに投げられた時の曲線が変わるため、一撃で倒すには、投げるピクミンごとに微調整が必要です。

 しかし、ロックオンではそこまで考慮してくれません。)


結果として、真上から見ることの代わりになっていません。




高低差に話を戻します。


ピクミンを呼ぶ「笛」の有効範囲に、高低差の概念が加わっています。


1・2では、笛は呼び続けることで範囲が広がりました。

この時、「高さ」方向に関しては最初から全範囲でした。


3では、笛の呼べる範囲は、最初は高さ方向がほぼ0、平面です。

呼び続けると平面の範囲が広がり、最大まで広がったところで、やっと高さ方向にも広がります。



おそらく、ピクミン3の様々な「仕掛け」で、高低差が使われるものが多いためなのでしょう。

上と下で違う作業をしているときに、どちらかだけ呼ぶ、という操作をするためだと思われます。


でも、そういう操作は実はあまり使いません。

もっと使うのは、「敵との戦いの時に、振り払われて飛び散ったピクミンを呼ぶ」時です。


戦っている最中ですから、すぐに呼ばないと死んでしまいます、

でも、地形に高低差があると、「笛の範囲が十分に広がり、さらに高さ方向に広がる」まで、呼ばれないピクミンがいるのです。




高低差でもう一つ。


高いところに集める荷物が置かれている、というシーンが時々あります。

ピクミンは荷物を集めるゲームで、ターゲットにピクミンが到達すると「運ぶのに必要な人数」が表示されます。


ところが、高いところの荷物には、この人数が表示されません。

実際には表示されるのでしょうが、画面の上で見えなくなってしまい、表示が読めないのです。


まぁ、持ちうる限りの最大人数を投入すれば運んではくれるし、運んで落としてしまえば人数は見られます。

そして、一度人数を見たら「あそこは何人で運べる」と覚えておけばよいので、攻略には困りません。



これも、先に書いた「初プレイの時にイライラする」だけで、慣れれば問題のないものです。


…しかし、初プレイの時に嫌になる仕様が多いのは、問題だと思っています。




高低差のダメ押し。


とある地点でのパズルは、非常に高低差を活かしたものになっています。


そのため、斜め上から見下ろす視点では操作しづらい…と思ったのでしょう。

カメラがいきなり横からの視点に固定され、横スクロールゲームのような画面になります。


これが、普段とは操作感が違いすぎて、非常に操作しづらいのです。

急に今までと違う向きのカメラになって、結果としてジョイスティック操作も違う感覚になって、そこでパズルを解くための正確な操作を要求されます。


これ、やってみるとわかるのですが、急にルールの違う、別ゲームが始まったような感じです。

ものすごく違和感あります。


基本的に、ユーザーに断りなくルールを変えるのは、もっともやってはならないことだと思っています。

(メイドインワリオのように、次々ルールが切り替わることが楽しいゲームは、そのことも含めてルールになっているのでかまいません)




なんか悪口書いているみたいで生産的ではないのだけど、もう一つ大きなことを書かないといけません。

マップ構成のことです。


ピクミン1・2では、マップは基本的に、継ぎ目がありませんでした。

2では「地下」がありますが、1フロアごとに1枚のマップで、フロア間を自由に行き来するようなことはありません。


半面、ピクミンのマップは非常に「狭い」ものでした。

おそらく、3ではこれを解消すべく「広い」マップを作ろうとしたのでしょう…


断片的なマップがいくつもあり、その間を行き来して目的を達成する構成になっています。


この「マップの継ぎ目」が非常に不思議な、ねじれた空間になっているようです。


というのも、ピクミンが物を運ぶのについて継ぎ目に入ると、出口ではピクミンを追い抜いて出てくるのです。

ピクミンは継ぎ目の中を歩いているが、プレイヤーは継ぎ目の「入口」と「出口」の間をワープしている感じです。



そして、継ぎ目の中にいるピクミンは、異空間に入り込んでいます。

呼ぶことはできないし、日没近くの「このままでは死んでしまうピクミン」の人数カウントにも入っていません。


特に困るのが、荷物を持とうと頑張ったピクミンが、結局荷物が持てずに「諦めた」場合です。


最初の方で書いた通り、ピクミンは「互いの作業を邪魔」します。

荷物を運ぶ際も、運べる最大人数に達する前に「邪魔」によって諦める場合があります。


こうした、作業に着けなかったピクミンは、しばらく作業をしようと頑張った挙句、あきらめてその場で待機状態になります。

荷物を運ぶ場合「しばらく荷物について行った挙句、途中で待機状態となる」のです。


待機状態になったら、呼べばプレイヤーについてきます。

しかし、先に書いたように、継ぎ目の中で「待機」されると、呼ぶことができません。

「このままでは死んでしまう」というカウントにも入らないので安心していると、日没で死亡します。


これは明らかにゲームシステムの欠陥ですが、これも慣れてくれば「継ぎ目近くで荷物を運ぶピクミンを増やさない」という対処ができるようになります。


荷物を運ぶときは、人数によって速度が変わるので、攻略時には重要なのですが…

ここまでに書いたように、ピクミン3のシステムは、なんとなく遊ぶには悪くないのですが、攻略には向いていません。


自分の操作が悪いのであれば納得もするのですが、「運が悪い」としか言いようがない状況で失敗することが多すぎるので。




さて、以上が「システムに不備がある」という問題。

ここまで長々書いていますが、これでやっと言いたいことの半分くらいです。


ただ、ここから先は、個人的な このみ の問題で、ゲームシステムがおかしいとか、そういうことではありません。



ピクミン3は、攻略を「させない」方向に向けて舵を切っているように見受けられます。


というのも、ピクミン1・2に比べて、すべての荷物が少人数で運べるから。


1の時は、重くて大人数、かつ距離が遠くて時間がかかる…なんて荷物がいくつもありました。

これを運んでいる間、残りの少人数で効率よく敵を倒して回る、なんて攻略が普通でした。


これ、少人数でボスに挑むの、結構大変なんですよ。

攻略としては面白いのだけど、一部のマニアに向けての構造で、誰もが楽しめるものではない。


だから、今回は荷物は少人数で運べる。

先に書いたように、大人数の力押しで敵を殲滅して、その後分散して荷物を運んでおしまい、というような構成が多い。


何よりも、マップが広くなりました。

先に書いた継ぎ目問題はあるけど、広いマップを冒険することが目的のゲームで、小さなマップを緻密に攻略するゲームではなくなっている。

1・2のころに比べて、しっかりとしたストーリーらしい展開も多くなっていますし。


だから、ある程度効率を上げる「攻略」は楽しんでもいいけど、人数配分を1人単位で考えるような、緻密な攻略をする感じにはなっていない。


まぁ、それでもやりたい人はやればいいのだと思いますけど、先に書いた「バグ」が多発する問題で、攻略しようとすると非常に遊びづらいです。




ピクミン1は、今でこそ名作だと言われていますが、発売当時の評価は非常に低いものでした。

もう20年も前のゲームなので、当時の状況覚えている人少ないかもしれないけど。


テレビCMは話題になりましたが、ゲームキューブが売れなかったこともあり、遊んだことある人は少ないんじゃないかな…

今回、ピクミン3デラックスを絶賛する記事を書いている人の中に、「ピクミンは初めて遊んだが、さすが人気シリーズだけはある」という論調が多いのが気になりました。


で、反論含みでこの日記を書いているわけですが。


「さすが」と捉えている方々にとっては、遊んだことがないけど人気のピクミンは、いつか遊びたい憧れのシリーズだったのでしょう。

でも、先に書いたように、3は1・2とは別物のゲームになっていると感じます。



その一方で、この方向転換は、商売としては当然だとも思います。


1の発売直後の評価は、「すぐに終わってしまう小粒なゲーム」でした。

終わった人が中古ソフト屋に売ったため、値崩れを起こして安く買えました

つまりは、「クソゲー」扱いですね。


実際、すぐにエンディングを見られるゲームでした。

そして、すぐにエンディングまで行けるからこそ、「繰り返し遊んで欲しい」というメッセージが、エンディング後に隠されていました。


#言葉として入っているわけではなく、「ハイスコア」の表記が出るのです。

 これはつまり、繰り返し遊んでハイスコアを目指せ、という意味です。


マニアはこのメッセージを理解できましたが、マニアでない人には伝わりませんでした。

中古ソフト屋に売られたというのは「伝わらなかった人」が売ったのでしょうし、のちの評価が凄い高いのは、「伝わった人」がやり込んだためです。


これ、ゲームのとしての評価は高いのですが、商売としてはダメです。

中古で出回ったら、任天堂としての収入である「新品のソフト」が売れなくなっちゃいますから。



2では、ゲーム終了までのボリュームを増やしました。

半面、繰り返して遊ぶのは難しくなったため、やり込み要素は減った感じです。


そして、今回の3では、さらに本編のボリュームを増やしてやり込みを減らした、と思っています。

ピクミンの個性が希薄になったのも、食物連鎖を感じないほど敵が弱くなったのも、「マニアでない人向け」だと思えば、すべてが納得できる変更です。


しかし、ゲームとしていろいろおかしいのはすでに書いた通り。

根底部分のルールから変わってしまった3は、「ピクミンを真似して作られた、よくできたゲーム」にすぎないように思います。


▲目次へ ⇒この記事のURL

関連ページ

レトロゲームの日【日記 21/03/20】

別年同日の日記

02年 ページ更新

03年 東海道旅行終了

04年 忘年会

09年 風邪その後

10年 盛りだくさんの週末

12年 答えは重要ではない

17年 0sim

19年 やっちまいました。


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

100倍規模  2021-01-23 12:02:32  コンピュータ

▲目次へ ⇒この記事のURL

お仕事の話。ほぼ愚痴。


100名程度の使用を想定して作ったシステムがあり、開発をお手伝いしている。

ありがたいことに人気が出て、人気が出ると想定外の使われ方をし始める。


特に、多人数で使いたいという要望が多く、1000人規模でも使えるように1年ほど前に大規模改修を行っている。

僕はこの改修の途中から参加させていただいた形だが、システムのスループットは上がり、1000名でも使えるようにはなった。


この際に、さらに人数を増やすこともできるような設計にはしていたが、それは「設計」だけで、実際には対応できていなかった。



それが、今回1万人で使いたいという依頼が来て…

いや、依頼はしばらく前から来ていたのだ。というか、依頼は1万人とも限定していなかった。

最大5万人くらいということだったが、それはさすがに難しそうなので、1万人に制限してもらったのだ。




システムはいくつかのパーツに分かれているが、サーバー部分は改修の際に、node.js で作り替えられていた。

node.js はサーバー側で動作する javascript 環境だ。


細かな話を書くと長くなるが、もともと javascript はブラウザ向けの技術だった。

そのため、非常に癖の強い特徴を持つ。


一番重要なのが「ノンブロッキング」であるということだ。

ブラウザはユーザーが操作するものなので、その操作を阻害…「ブロック」してはならない。

これがノンブロッキングという思想。


言語が動いているときは、ユーザーの操作を受け付けられない。

そう仮定すると、ユーザーの操作を阻害しないため、言語は無駄な実行時間をかけてはならない。


とはいえ、普通のプログラム言語にはたいてい「何かを待つ」処理が入るものだ。

ファイルを読んだり、ネットで通信をすると、CPU よりもはるかに遅いディスク装置やネットワークのデータを待つ。

プログラムをしていると、ごく当たり前のことだ。


javascript では、これらのことは「行えない」。

待たせてはならない、という設計思想だからだ。


とはいえ、ディスクを読んだり通信をしたり、というのは当たり前のことで、もちろんできる。

どうやるかというと、待つのではなく、いったん終了してしまうのだ。


「通信してね」って頼んだら、終了する。

そして、通信が終わると、「通信終わったよ」ともう一度処理を起動してもらう。


javascript では、一事が万事この調子。プログラムを組んでいると、非常に組みづらい。

まぁ、最近では昔より環境が整えられ、かなりマシになったのだけど。



そして、あえてこの使いにくい環境をサーバーで使うと、「待ち時間のない」プログラム環境を実現できる。

待ち時間がないということは、常にプログラムが動いているし、リクエストに応えられるということだ。


従来…というとちょっと古いのだが、Wordpress などに使われる PHP では、1秒間にせいぜい 10リクエスト

くらいしか答えられない。


でも、同じことを node.js で実装すると、1000リクエストくらいは答えられるのだ。


#PHP はインタプリタだが、node.js は即時コンパイルだ、とか、PHP はプロセスフォークで動く Apache 上で動作するが、node.js はシングルプロセスなのでタスクスイッチのオーバーヘッドがないとか、他の要因も多分にあるのだけど。




それでも期待できるのは 1000人レベルだ。

大規模改修で node.js を使って 1000人規模に対応した、というのがこの段階。


今回1万人規模のリクエストなので、node.js をクラスタ化して対応することにした。


node.js は、シングルプロセスで動作する。

たった一つのプログラムで、1000以上の接続に対応するのだ。


しかし、これは CPU がマルチコアだったとしても、1コアしか使わないという意味でもある。

CPU のコアの数だけプロセスを増やせば、理論上はもっと多くの接続を処理できる。


もちろん、そのための制約はいろいろとあるのだが、最初から「マルチプロセスで動かすことができるように」という設計をしていた。


そして、pm2 という node.js 対応のプロセス管理ツールを使うと、プログラムは無改造のまま、マルチプロセス化できる。


(通常、プロセスが増えると、それぞれが別の通信ポートなどを用意しないといけなくなる。

 通信ポートが増えれば、アクセスするクライアント側もそれに対応しなくてはならなくなる。

 しかし、pm2 は代表して1つの通信ポートを作り、配下のプロセスのポートに適切にデータを流してくれるので、外部から見るとそれまでのプログラムと何ら変わらないように見える)


というわけで、処理性能は何倍かに跳ね上がった。



…でももちろん、話はそんなに単純ではなかった。




接続が増えたら、当たり前だがそれらの接続ごとに、データを収めた DB へのアクセスが発生する。

1プロセスで 1000 人程度をさばいているときには問題にならなかったが、1万人規模になると接続ができなくなった。


DB の接続数の上限設定があるのだ。これは、 DB の設定を書き換えて解消する。

これに伴い、適切なワークメモリの割り当てなども変える必要があるが、とにかく設定した。


DB が接続を受け付けられるようになっても、その接続のための通信ポートが十分作れない。

OS 側に、通信ポートをいくつ作れるか、という設定があるのだ。

それらも設定する必要がある。


UNIX では、すべてのリソースがファイルとして扱われる。

通信ポートも1種のファイルだ。そして、UNIX には、プロセスごとに開けるファイル数の制限がある。

この制限も増やす必要がある。


100 人程度なら問題なし、1000人でも大丈夫だったとしても、1万人規模になるとそれまで気にしていなかった設定が問題になるので、問題発生のたびに何が悪いのか調べ、設定をチューニングする必要が出る。


それまでは問題にならなかった DB の Query が、突如として slow query になる、というのもあった。

DB へのアクセスが激しすぎると、特に問題がなかった部分がボトルネックになりだすのだ。


…これらは、上に書いたような順序で、理路整然と起こったわけではない。

とにかく不具合が続出し、原因を切り分け、考えられる要素をひとつづつ潰していく必要があった。


上に書いたのは、「結果としてそういうことだった」というだけで、原因がわからないので見当違いの設定に手を出して、何も変わらないので元に戻す、というようなこともやっている。




問題はサーバー側だけではなかった。


1万人規模、と書いたが、その規模の人たちがサーバーに接続し、操作した結果を集計して表示する画面がある。

普通の WEB ページとして作られているので、PC さえあればインストール作業などなしで表示できる。


この画面自体は、サーバーと接続しているだけだ。接続が増えるようなことは無い。

だから特に問題は出ないだろうと思っていたら、1万人分…1人についてのデータが複数あるため、数万件のデータになると通信に支障が出た。


特に、何らかの不具合が起こって画面のリロード…と考えたとき、数万件のデータ再送信はそれだけで1分程度の時間がかかる。


通信したデータを、ローカルにキャッシュして持つように改良した。

再起動が行われた際は、まずキャッシュからデータを読み込み、続きのデータの送信をサーバーに依頼する。

5秒程度で表示が行えるようになった。



この表示も1万件あると遅くなった。

全部を表示したいのだが、ただ1万行の HTML というだけで、重くてスクロールもままならないのだ。


これはプログラムテクニックで乗り切った

どこかに詳細なテクニック紹介をしたいのだけど、忙しくて概要説明だけ行ったままだ。



100人を想定して作ったものを、1万人向けに提供する…となると、思わぬことがいろいろと発生する。



▲目次へ ⇒この記事のURL

別年同日の日記

12年 ゲームボーイの CPU

15年 アプリケーションサーバとしてのQNAP

15年 宮永好道 命日(1993)

16年 iOSでtextのコピー・ペーストができないバグの回避

18年 サターンポリゴンのゆがみ


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

ノートパソコン修理  2021-01-26 13:33:16  コンピュータ

▲目次へ ⇒この記事のURL

昨年8月に購入したノートパソコンが壊れた。


壊れたといっても、起動はできるし普通に使える。

ペンコンピューティング可能なマシンだが、ペンも使える。


でも、指で直接ディスプレイにタッチした際の操作が効かなくなった。

それ以外の症状はない。


最初は、ペンは使えるがタッチは使えない、というので、タッチパネル自体は壊れてないんだよね?

と思ってドライバ不具合などを疑った。

調べると、Windows アップデートなどでドライバが不具合を起こすことがある、という情報があったし、うまく動かなくなった直前に Windows のアップデートを行っていた。


じゃぁこれかな、と思って、メーカーのページに書かれていたトラブルシューティングの方法に従ってドライバを入れなおす。でも治らず。


さらにネットの情報を探す。

我が家の機種とは違うが、同じシリーズの以前の機種で、同様の問題を発見。

タッチディスプレイのケーブルが内部基板から外れやすくて、ペンは使えるのにタッチのみ使えなくなりやすい、という。


後継機で前の機種のトラブルが対応されていないことは無いと思うのだけど、症状的に似通っている。

ケーブルが外れているだけなら自分で治せるかもしれないけど、保証期間内だったので素直に修理に出すことにした。




まず、メーカーのページで修理申込する。

不具合のある機種を使って申し込みをすると、自動的に機種を判別し、保証期間内であることが示される。

そして、自己診断プログラムのダウンロードを促される。


このプログラムを入れると、自動的に自己診断が始まり、その情報とともに修理申込ができる。

その際、マシンのシリアルナンバーなども自動判別される。


我が家の機械の場合、故障個所はない、という診断だったが、申し込みはできた。

自己診断の限界もあるのだろう。


住所氏名や電話番号などの連絡情報を入れたのち、不具合について記入。

タッチパネルが反応しないがペンは動くこと、公式の方法でドライバの入れ直しも試みたことなど書く。


で、翌日にはメールで返事が来た。ハードウェア故障の可能性が高いので引き取り修理をするという。

引き取り日の希望などを返信するが、最短で翌日。で、翌日には佐川急便が引き取りに来たので本体を渡す。

梱包などは佐川の方でやってくれる。



当日のうちに到着連絡が来たが、この日が金曜日だったため、週末の間は修理は進まなかった。

そして、昨日月曜日に修理完了の連絡があり、今日には手元に戻ってきた。


一応、メーカーのページには「到着から1週間から10日で修理完了します」とあったし、さらに「コロナ禍で修理依頼が増えており、少し時間がかかるかもしれません」とお詫びがあった。

しかし、メーカー到着の次の営業日には修理を行い、翌日こちらに届くというスピード修理。


まぁ、本当にハードウェア的な故障で、部品交換で済んだからすぐ終わったのだろうけど。

ソフトウェアのコンフリクトなどを「不具合」として修理に出す人もいるみたいだし、そういう問題はすぐには解決できない。




▲目次へ ⇒この記事のURL

別年同日の日記

14年 iOS の position:fixed バグ回避方法

17年 後藤英一 誕生日(1931)


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

微分積分いい気分  2021-01-29 17:56:48  コンピュータ 数学

▲目次へ ⇒この記事のURL

このタイトル、すでに分からない人の方が多そうだな




急に思い出話。

まだ僕が大学1年生だったころのこと。


PCルームがあって、放課後は入り浸っていた。

その場にいる人の多くは、僕も所属していたコンピューターサークルのメンバー。


でも、そうではない常連の人もいて、学科もサークルも違うのに知人、という人もいた。


そのうちの一人…同じく1年生で、簡単なプログラムは組めるが本格的なゲームなどは作れない、というくらいの知人が、ゲームによくある、ジャンプの動きを作ろうと頑張っていた。




その知人は「ジャンプは放物線なのだから」と、何かの二乗を使って書こうとしてたんだ。

(二乗のグラフとして描かれる線を、放物線と呼ぶ)


でも、そうじゃない。ゲームならジャンプは次のように書く。

(当時は BASIC を使っていたので、BASIC 風に)

10 X=X+1
20 IF INKEY$=" " THEN JUMP=1:Y1=-5
30 IF JUMP=1 THEN Y=Y+Y1:Y1=Y1+1
40 IF Y1>5 THEN JUMP=0
50 PUT SPRITE 0,(X,Y),8,0
60 GOTO 10


このプログラムはサンプルなので、初期設定を省いているので、雰囲気で読んで欲しい。

ともかく、こんな感じのプログラムを作って、こうやるんだよ、と見せてあげた。


そうしたら、返ってきた反応は、「なんかずるい」だったんだ。

動きを見ると放物線っぽく見えるけど、プログラム中には二乗どころか、掛け算もない。

それは放物線ではない、というのだ。


いや、別にずるくないよ、と言い返したが、その時の自分には「ずる」ではないという明確な根拠を示せなかった。




今なら明確に示せる。


これは、放物線の式に対し、一階微分した導関数を導き出し、その導関数を再び積分することで放物線を再構築しているんだ。


なぜ微分するかというと、ゲームは時間によって微分された世界で動いているから。

テレビ画面は、連続した「時間」を、1/60 秒ごとに区切って表示する。

このわずかな時間の動きは、時間で微分されている、ということになる。


そして、その微分したものを積み重ねていく。

テレビで言えば、一連の「コマ」を連続させて動かすことが、積分にあたる。


…厳密にいえば、微分ではなく差分だし、積分ではなく積算なのだけど。

これを言い出すと離散数学というややこしい数学の話になるので、今は微分積分という呼び名で話を進める。



僕のプログラムを見た知人は、「プログラム中に二乗がないので、放物線ではない」と言った。


しかし、プログラム上は微分したことで二乗が消えている。

そして、プログラムを動かすと時間変化によって積分され、正しい放物線が描かれる。


これを「ずる」だというのは、微分積分を理解していない残念な人間だというのを、自ら明かしたに過ぎない。

(もっとも、すぐに言い返せなかった自分も、その時には十分理解できていなかったわけだけど)




本当に足し算だけで二乗になるのか、まだ疑う人がいるかもしれないので、わかりやすい例を挙げよう。


まずは、単純なルールで作りだせる、次の数値の表を示そう。


 0 1 4 9162536496481
135791113151719

この表のルールはこうだ。

・上に書かれた数値は、その左側の列の上下の数値を足したもの。

・下に書かれた数値は、その左側の列の下の数値に、2を足したもの。


足し算しか使っていない、非常に単純なルールだ。

おかしいところがないか検算してもらってもよい。


ここで、上の数値は、もう一つの意味を持つ。

0,1,2…と続く数値の「二乗」になっているのだ。


日本人なら 9*9=81 まではわかるだろうから、上の表は 81 で止めてある。

でも、もっと長く続けても大丈夫。これも試してもらってよい。




「ずる」と言われたのが悔しくて、根拠を考えていたら、数日後にはこの答えに行きついた。

でも、サークルも違うし学科も違ったので会う機会はそれほどなく、言い返すタイミングは永久に失われた。


それを思い出して急にここに書いたのは、ネットで「微分積分なんて実生活でどう役に立つのか」なんていう…まぁ、よくありがちな学生の愚痴を見たから。


微分積分、生活で超役立つ。

上に書いたように、テレビゲームは微分積分の世界の中にある。

そもそもテレビが微分積分の世界だし、デジタルテレビなんかフーリエ変換(微分積分の親玉みたいなやつ)を駆使して作られている。


ただし、役立てられるかどうかは、自分次第。

ゲームやテレビの中に微分積分が駆使されている、なんていうのは知らない人は全く気付かない世界だ。

それでも生活はできるのだから、知らずに生活している限りは、高校で習った微分積分は「役立てられていない」。


役に立たないのではなく、役立てられないのだ。

なんでかといえば、勉強が浅かったから。「どうせ役立たない」なんて思ってるから。




世界最初のコンピューター、と呼ばれる ENIAC は、実のところ「ひたすら足し算する機械」にすぎない。

それでも、数学的に正しい…どころか、空気抵抗なども考慮した「弾道計算」ができた。


先に書いたように、足し算だけで数学的に正しい放物線は求まる。

しかし、それは空気抵抗や風などがない理想状態での弾道にすぎない。


ENIAC では時間で「微分」した方程式を使い、繰り返し計算して「積分」することで、弾の速度の関数となる空気抵抗や、風の影響なども考慮に入れ、物理現象としての「弾道」を描き出すことができた。


空気抵抗が弾の速度の関数になる、なんていうのは、瞬間ごとの速度を見ながら抵抗を導き、それによって速度を調整する、というのを繰り返しながら積分する方法でないと計算できない。


そうした計算が複雑すぎて人の手に負えないから、ENIAC を建造したわけだけど。



ともかく、ここで重要なのは、どんなに複雑な数式であっても、微分を繰り返せばただの足し算になるということだ。

そして、足し算をひたすら繰り返せば、元の複雑な数式の答えを導き出せる。

(ここでいう答えとは数値演算であり、式の変形ではない)


ENIAC は弾道計算よりももっと複雑な、水爆の内部圧力の計算なども行っている。

使われた計算は全部足し算のみだ。それが微分積分の威力だ。




今回、この話を書こうと思ってネットを調べていたら、以下のようなことを書いている人がいた。

(一連のツイートだが、特定人物を批判したいわけではないため、検索されないよう文面は変えている。)


・ファミコンで三角関数を使うと遅くなるので、スーパーマリオのジャンプは掛け算だけで作られている。

・掛け算だけなので本当は放物線ではないのだが、ゲームを作るうえでのうまいごまかし方だと言える


…まぁ、プログラマーでない人がうろ覚えの知識を披露しただけだと思う。

しかし、どこから突っ込んでよいかわからないほど違っている。



まず、ジャンプを表現する放物線に、三角関数は必要ない。掛け算だけでよい。

そして、ファミコンは掛け算すら遅いので、足し算だけで作られている。


さらにいえば、先に書いたように足し算だけで書いてもごまかしではなく、数学的に正しい放物線が描ける。


ただ、スーパーマリオのジャンプは、放物線ですらない。

放物線にすると、操作が難しくてゲームにならないから。


それでも放物線っぽく感じられるようにしている。

これが「うまいごまかし方」だというのは同意だが、計算できなかったからではなく、ゲームを面白くするためだ。

背景が全く違う。




▲目次へ ⇒この記事のURL

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

数学

関連ページ

暮らしの中の微分積分【日記 21/03/16】

別年同日の日記

05年 外構チラシ

09年 ジョウビタキ

10年 加湿器

15年 「デフォルト」という言葉の意味

15年 プログラム言語における「デフォルト動作」

16年 【追悼】マービン・ミンスキー

16年 AI囲碁

18年 テクニカルサポート


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

Lenovo Ideapad Duet 購入  2021-02-23 17:40:22  コンピュータ

▲目次へ ⇒この記事のURL

昨年8月に、Ideapad C340 を購入している。

今度は Ideapad Duet を購入。


C340 は 14inch の普通の Windows ノートパソコンだ。

で、Duet は 10inch タブレットの Chromebook 。


いままで Android 10inch タブレットを使っていて、その買い替え。

といっても、今までのマシンも性能上の不満はない。

妻が性能が良いタブレットがほしいといったので、僕が買い替えて今まで僕が使っていたものを渡すことにしたのだ。




今まで使っていたのは Huawei Mediapad T5。

その前には旧 Amazon kindle Fire HD 10 を使っていた。Kindle は安いからね。


でも、旧Kindle は性能も低くて、本来の使用用途である Prime Video の閲覧ですら、重いことがあった。

そこで Mediapad を購入した。

(注:今の Kindle は性能が上がっているので、重くないと思う)


で、動作が軽くなったら便利なので、時々キーボードをつなげてドキュメント作成などもする。

あと、Web ブラウジング。


便利に使っていたら、先に書いたように妻がうらやましがるので、もう一台買うことにした。

そこで、今度は Chromebook を選んでみたわけだ。


Chromebook を使っていたことはあるのだけど、その頃は本当に Chrome が使えるだけだった。

今は、一部制限はあるが、Android のアプリや Linux が動く。


一方、普段は当然のように Windows を使っているし、仕事で Web アプリ開発をしているのだけど、Android の Chrome だと、PC のものとは若干動作が違っていて、やりたいことができないこともあった。


僕は仕事柄 Linux 端末はよく使うし、先に書いたように Android アプリは Amazon 関係が動けば、まぁいい。

Chromebook は、Android 版ではなく、PC 版の Chrome と同じものが動作している。

そんなわけで、Chromebook でもいいんじゃないかな、という興味で購入してみたわけだ。




Duet にはタブレットと言いつつ、キーボードが付属する。取り外し可能だし、10inch に合わせた狭いキー配置なので、使い勝手はそれなり。

じつは、この日記もそのキーボードで書いてみている。

HP200LXとか、Linux Zaurus、Netwalker を使っていたことを考えると、ずっとまともなキーボードだ。

(比較対象がひどすぎる気はするが)


まだ届いてから数時間しか立っておらず、使い勝手は十分確認できていない。

でも、とりあえず普段づかいにできそうなことは確認済み。


またしばらく使ってみてからレポート書くかもしれないけど、何も書かなかった場合は「書くことがないほど普通に使えている」ということだと思ってほしい。


2021.3.1 追記


1週間ほど使ったところで使用記書きました

素晴らしい機械でした。




▲目次へ ⇒この記事のURL

関連ページ

IdeaPad Duet の使い勝手(1/2)【日記 21/03/01】

別年同日の日記

05年 Quoカード

10年 SH-03B

15年 ゲームセンターの努力

15年 理科ハウス

17年 早口言葉


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

IdeaPad Duet の使い勝手(1/2)  2021-03-01 11:00:55  コンピュータ

▲目次へ ⇒この記事のURL

Lenovo Ideapad Duet を購入して1週間ほどたつ。

まだ1週間しか使っていない、というべきかもしれないが、ここらへんで一度評価をまとめておこう。



冒頭でいきなり評価を書いてしまえば、非常に素晴らしい端末だ。


購入前は、普通と少し違うこの端末を買うことに不安があった。

しかし、予想を遥かに超えた素晴らしさだった。不安は杞憂だった。


どう素晴らしいかといえば、これが見事に既存の機械の「隙間」を埋めるものだったのだ。


でも、隙間を埋める充填剤だ。広い面積をカバーできるパネルではない。

Duet は現在大人気で品薄なのだけど、この隙間を持たない人にとっては魅力のあるものではないと思う。

つまり、Duet が素晴らしいというのは、僕にとっての話であって、万人に勧められる製品ではない。


以下、このことについて説明していこうと思う。




これが隙間を見事に埋める充填剤だ、というのだから、最初に僕が持っている「隙間」について書いたほうが良いだろう。


僕は、普段は Windows を使って仕事をしている。

ノートパソコンを買ったのだけど、外付けディスプレイとキーボードをつないでしまったため、事実上は動かせないデスクトップマシンになっている。


仕事柄 Linux サーバーも持っていて、Windows からログインしたり、ファイル共有サーバーにしたりして使っている。

ファイル共有としては、NAS も併用している。


スマホとしては普段 Android を使用している。

そして、Duet を購入する直前まで、Android の 10inch タブレットを併用していた。


初期の頃の Chromebook (Chrome OS を採用した PC ) を使っていたこともある。

初期の頃と今では、随分と Chrome OS の方向性は変わった。でも、基本は理解している前提だ。


あと、仕事用に Macintosh と iPhone も持っているが、あまり使っていない。あくまでも仕事で必要だから持っているだけ。

なので、これは今回の話にはあまり関係ない。




さて、僕は主夫なので家事をする。食事を作ったり、皿を洗ったり。

これが結構生活の中では時間が長くて、しかも孤独だったりする。

その時間にも娯楽を欲した。


最初は、スマホで Amazon Prime Video を見ていた。

見ていたというか、家事をしながら Bluetooth イヤホンで「音声を楽しんでいた」感じかな。

スマホなので、画面が小さくて家事をしながらだとあまり映像を見られない。


他にも、家族団らんのときにもちょっとパソコンを使いたい時があった。

じゃぁ、ノートパソコンを買えばビデオも大画面で見られるし、団らんのときにも使えるかな、と思った。


でも、これは失敗だった。ちょっと気軽に使いたいという要求と、仕事で使うのでしっかりしたものが欲しいという要求は相容れなかったのだ。

仕事で使うにはディスプレイが狭いが、持ち運ぶには大きくて不便なノートパソコンは、先に書いたとおり拡張されて半ばデスクトップになっている。


替わりに、10inch Android タブレットを購入した。

最初は Amazon Kindle HD (旧型)だったが、その後 Huawei MediaPad T5 に乗り換えた。


10inch タブレットは素晴らしかった。だからその路線で買い替えまでしたのだ。

Prime Video を見るには問題ないし、時々居間で家族が集っている傍らで文章を書いていた。


外出時に持ち歩いたこともある。

T5 にはスマホのようなモバイル通信機能はついていない。

しかし、Android スマホと Buetooth 接続することで、スマホのモバイル通信網を借りることができた。

設定が少し面倒くさいのだけどね。それでも通信できるので十分だった。


そんなわけで、Android 10inch タブレットで特に問題はなかったんだ。

IdeaPad Duet を買ってみようというのは、ほとんど気まぐれだった。




さて、やっと僕の利用実態を説明できたので、Duet の素晴らしさを伝えられる。


Duet は MediaPad T5 と同じ、10inch サイズのタブレットだ。

タブレットだけどタッチパッド付きのキーボードが付属していて、着脱できる。


そして、Android 端末ではなく、Chrome OS 採用の機械(Chromebook と呼ぶ)だ。

もっとも、詳しくは後で説明するが、Chrome OS は Android のソフトを動かすことができる。

だから、ほとんど同じ使い勝手になると思っていた。


でも、Android は「スマホの OS」で、Chrome OS は「パソコンの OS」だ。

同じソフトが動いたとしても、OS がスマホ用かパソコン用か、というのが、思った以上に使い勝手に違いを与えていた。




わかりやすい違いから書こう。


Android は、スマホ用の OS なので、外部からの通信を待ち受ける必要がある。

そのため、CPU を停止させる「スリープ」状態はない。

画面表示を消し、動作周波数を落として省電力にしていたとしても、常に電力を消費し続ける。


もちろん、スマホはそれでいいだろう。

でも、モバイル通信機能を持たず、待ち受ける必要がないタブレット端末でも、着信を待って電力を消費し続けるのだ。


Androidタブレットを使っていたときには、そういうものだと思って気にしていなかった。

しかし、使っていないときに電力を消費続けるというのは、無駄以外の何物でもない。


Chrome OS は、PC 用の OS なので、通信を待ち受けるという概念がない。

画面を消すときには CPU も停止して、電力消費を抑える。


このため、電池のもちが良い。


というか、これがあるべき状態だった。

スマホ用の OS を、スマホではないものに使っているというのが、無駄な状態だったのだ。




もう一つわかりやすい違いを。


スマホ用の OS は、低い解像度の、小さい画面を前提として作られ始めた。

最初期の頃は、画面横幅は 320ドットだった。


しかし、今は 1080 ドットはある。1080 というのは、ハイビジョンの動画を視聴するのに必要なドット数だ。

画面の物理的な大きさはほぼ変わらないまま、およそ3倍のドット数を表示できるようになった。


じゃぁ、表示できる情報が増えたのかというと、なっていない。

Android や iOS が、表示できる文字数が大きく変わらないように制御しているためだ。


タブレットになると画面が大きくなるため、表示できる文字数は増える。

でも、文字を大きめに表示する、という基本は変わっていない。


これに対し、パソコンはより多くの情報を表示できるように発展してきた。

画面が広くなると表示できる文字の量が増える。解像度が上がると表示できる文字の量が増える。

ノートパソコンで画面が小さい、などの理由であえて文字を大きくすることはあるのだけど、その場合も拡大率の決定はユーザーに委ねられている。


パソコンとスマホでは、情報表示に対する考えが根底から違うのだ。

そして、Chrome OS はパソコン用のOSだ。拡大率は自分で変えられる。


この拡大率は、Chrome OS 上で動く Android アプリでもそのまま適用される。

だから、Android アプリをフルハイビジョンで表示できたりする。


まぁ、スマホの小さな画面で使うように設計されたソフトをフルハイビジョンで使う意味はない。

でも、一度見てみると非常にインパクトがある。Chrome OS なら、Android タブレットでは見られない世界を見られるのだ。

もっとも、Duet を使っている限りでは、字が小さすぎて実用にならないので、フルハイビジョンで使うのはお勧めしない。


オススメしないのは「Duetの場合」であって、「Android アプリに広い画面が不要」だと言っているのではない。

Chrome OS では、Android アプリもウィンドウ内で動くようにできる。

ウィンドウをいくつも並べることもできるし、ウィンドウをリサイズすればそれに合わせた表示になる。

(Android アプリは、様々な画面サイズの端末に対応しているし、使用中の画面リサイズである「画面の回転」などにも対応している。)


だから、広い画面で情報がたくさん表示できることには意味がある。

Duet は画面が小さいのでこの機能を活かしきれないかもしれないが、Chrome OS 上で Android アプリが動く、ということは、今までになかった新しい世界を開くのだ。




わかりやすい例を2つ挙げたが、他にも細かな違いは色々ある。

多くは、スマホと PC という、違う目的で発展してきた OS の違いに起因するものだ。


もちろん、Android にしかできない、ということも多い。

実際、Chrome OS のほうが機能的には貧弱だとも言える。


だからこそ、最初に「隙間を埋める充填剤」だと書いたのだ。

Windows でしかできないことがあり、Android でしかできないことがある。

そして、その隙間の、どちらにもできないことを、Chrome OS が埋める。


同じ 10inch タブレットであっても、Android タブレットでは隙間を埋められない。

Android タブレットでは、Android にできないことはできないのだ。




Duet が素晴らしい、ということをざっくりと書いたが、細かな話はまだある。

ただ、細かな話になりすぎて、本当に興味がある人でないと面白くないと思う。


なので、ここでいったん記事を区切ろう。

次の記事では、実際の使用感を細かく伝えていこうと思う




▲目次へ ⇒この記事のURL

関連ページ

Lenovo Ideapad Duet 購入【日記 21/02/23】

IdeaPad Duet の使い勝手(2/2)【日記 21/03/01】

IdeaPad Duet の使い勝手(1/2)【日記 21/03/01】

別年同日の日記

09年 おゆうぎかい

14年 冒険遊び場

15年 イチダントアール

16年 シーモア・パパート 誕生日(1928)

17年 エドウィン・ハーバード・ランド 命日(1991)

20年 長男、高校合格


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

IdeaPad Duet の使い勝手(2/2)  2021-03-01 11:24:01  コンピュータ

▲目次へ ⇒この記事のURL

さて、前の記事では Duet が素晴らしい、ということをざっくりと書いた。


ここから先は、細かな使い勝手について書いていこうと思う。

あくまでも個別論だし、実際に使ってみないと分かりにくい部分も多いと思う。

それでも、今注目されている機械なので、購入を検討している人のお役に立てればと思う。




最初に、言葉を見直しておこう。ここまでにもすでに使ってしまっているのだけど。


Chrome は、Google が開発した Web ブラウザのことだ。

PC 用と Android 用がある。


Android 用は、PC 版から多くの機能が削除されているサブセット版だ。

別のものだと思っていいほど違う。



Chrome OS は、PC 版の Chrome だけが動けば良い、という前提で作られた OS だ。


Web サービスだけ見られれば十分、ということは案外多い。それなら Chrome だけが動けばよい。

現在では、当初の目的から少し方向が変わり、Android のアプリも動かすことができる。



Chromebook は、Chrome OS を採用した PC 製品群に付けられたブランド名だ。

今回僕が購入した IdeaPad Duet も、Lenovo 社から発売されている Chromebook だ。


Lenovo の製品としては、Windows でも IdeaPad シリーズとなっているものがある。

なので、この記事中では Duet と呼ぶことにする。



▼Chrome の使い勝手


Chromebook の話をするのだから、まず Chrome の使い勝手について書こう。

PC 版なのだから Windows などと同じ…と書ければ楽なのだが、そうではない。


まず、フルセット版だ。

機能拡張が使えるし、Android 版にはない「全画面表示」機能もある。

デベロッパーツールだって使える。


でも、PC 版と同じではなく、独自拡張もある。


まず、全画面モードの際の UI が少し違う。


Windows 版を使っている人は、F11 キーを押してみよう。

Web コンテンツが、全画面で表示される。これが全画面表示だ。


ウィンドウの最大化と違って、Chrome の UI であるURL バーやタブも消える。


UI が消えるということは、タブ切り替えなどもできないということだ。

(キーボードショートカットは効くのだけど)



Chrome OS の Chrome では、この状態でも画面上端にマウスカーソルを持っていくと、URL バーやタブが表示される。

この機能がすごく便利。PC 版にも付けてほしい。


まぁ、Chromebook は低価格を狙った機種が多く、PC ほど画面が広くないので、「全画面表示を使うことが多い」ことに考慮したのだろう。

PC では全画面表示はプレゼンなど特別なときにしか使わず、その際には余計なインターフェイスは表示されないほうが良い。



もう一つ、PC 版にはない、拡大表示操作が可能になる。

これ、表示倍率を変える「ズーム」機能とは違うものだ。2本指によるピンチ操作で自由な倍率で拡大できる。

拡大しているときでも、Chrome の「ズーム」は 100% のままなので、別の機能だとわかる。


Android では自由な拡大はあたり前のことだし、便利なので取り入れられた機能だろう。


なお、常に自由に拡大できるわけではない。表示サイズが重要で CSS で指定してあったりすると、拡大できないようだ。



まだある。

Chrome OS をタブレットモードにすると、Chrome もタブレットモードになる。

この時、タブ部分は隠され、URL バーは Android 版のように、スクロールに合わせて出たり消えたりする。


ただ、Android 版と違って、この状態でも明示的に「全画面」を指定すると、URL バーは消えっぱなしになる。

この場合でも、画面上部から下向きにフリックすると URL バーが出てくる。


これがまた、非常に便利。

Android 版の場合、ページめくり式の漫画とかを読もうと思う、下に向かってスクロールできず、URL バーが消えないんだよね。



URL バーが出ているときにもう一度、上部から下方向にフリックすると、タブ切り替えの UI が出てくる。

ただし、この UI はタブではなくて、サイトイメージを並べたリストになっている。


これは、指で選択しやすいように大きく表示することが目的のようだ。

大きくなったため、量が多いときは横スクロールして表示する。


これは便利機能というより、操作のために必要だから付けた機能だろう。


他に気づいていないところもあるかもしれないが、主な違いはこの程度だ。

便利にするために追加された機能はあるが、PC 版の機能は、おそらく全部使える。


だから、サブセットの Android 版では見られなかったようなサイトでも、全て見られる。

Web サービスも全て受けられる。



もっとも、それができなくなったら、Chrome OS としての意味がないと思う。




Chrome OS は、もともと Chrome 上で動作する Web サービスをアプリとして使用するものだった。

なので、よく使うページがあれば、積極的にアプリとして登録しよう。


これには、「ショートカットを作成」機能を使う。

作られたショートカットは他のアプリと同列に並べられ、アプリとして実行できるようになる。

まぁ、Chrome のショートカットだから、新しいタブで Web ページにアクセスするだけなのだけど。


じゃぁ、ショートカットではなく、ブックマークに登録しても良いのではないか、と思う人も多そうだ。


でも、そうではない。

後で書くけど、アプリは実行しやすいような工夫がある。

だから、Chrome のブックマークに登録して呼び出す、というのより、ずっと使い勝手がいいんだ。

ショートカットを多用することをおすすめする。



▼Android アプリの使い勝手


つづいて Chrome OS のもう一つの顔、Android アプリの実行環境を見ていこう。


Duet 購入前は、Android アプリが、スマホのエミュレート環境の中で動くような感じかな、と思っていた。

縦に長い固定サイズのウィンドウが開いて、その中でスマホのアプリが動く、みたいなイメージ。


しかしそうではなかった。もっと高いレベルで実行環境が OS に統合されており、Chrome と同じレベルで使うことができる。


まず、PC モードの場合、Android アプリはウィンドウ内で実行される。

ウィンドウのタイトルバーの左端には「戻る」ボタンがあり、右上にはウィンドウを操作するボタンが並ぶ。「閉じる」ボタンを押せばアプリが終了する。


ウィンドウをリサイズすればそれに合わせて適切に表示されるし、マウスカーソルでテキストを選択して、コピーすることもできる。


つまり、Android アプリだからといって何も特別なことはなく、ごく普通のアプリケーションとして使用できるのだ。


Duet の場合、初期インストールアプリとして入っている Gmail は、Android 版だ。

Chrome しか使えなかった初期の Chromebook では、Web 版 Gmail へのショートカットがアプリとして入っていた。


つまり、「Android アプリも実行できる」などという選択肢の一つではなく、Chrome OS にとっては Android アプリは必要なものだという認識なのだろう。


…でも、Gmail は Web 版のほうが便利。

アプリ版だと、未読を全選択して既読扱いにする、とかできないから。


先に書いたように、Chrome からアプリとして登録しておくと良いだろう。

(個人的な好みの問題もあるが)




Android アプリは、タブレットモードのときに操作が大きく変わる。

まず、Chrome と同じように全画面表示が基本となる。


実は、画面分割して2つのアプリを同時に表示することはできる。

これは、Android 7 相当の機能だね。


また、アプリが対応しているならば、ピクチャー・イン・ピクチャー表示にもできる。

これは Android 8 相当の機能だ。


しかしまぁ、全画面表示が基本だ。ここらへん、Android のスマホやタブレットと変わらない。


しかし、一つ困ったことがある。

Android アプリの操作に、Android の OS が用意する、画面下部の3つボタン…「戻る」「ホーム」「タスク」は必須だ。

しかし、Chrome OS にはこの3つボタンがないのだ。


もちろん、操作方法は用意されている。しかし、使い慣れた方法ではない、というだけで、最初は戸惑うことになる。


まず、「戻る」の操作は、画面左端から右に向かってスワイプだ。

すると、左矢印のアイコンが現れる。引っ張るとだんだん色が付き、十分引っ張ったところで色が反転する。


この状態で指を離すと「戻る」動作が行われる。

ちなみに、この操作は Chrome でも使える。Chrome は URL バーの左側に戻るボタンがあるけど、Android と同じ操作も使えるので、わざわざ操作を使い分ける必要はない。


次に、「ホーム」と「タスク」だけど、途中まで操作が共通している。


画面下から上に向かってスワイプすると、中央あたりで画面が全体に縮小される。


このまま上に向かって指をはらうと、画面は飛んでいってホーム画面が現れる。

中央あたりで指を止めて一瞬待つと、現在動いている他のアプリも縮小画面で現れ、タスクリストが表示される。


ちなみに、どちらも「中央辺りまでスワイプ」が必要で、それより短い距離だと別の動作になる。

後で書くが、アプリ起動を行うためのシェルフの表示だ。


初期の頃から、Chrome OS では画面下部にシェルフを表示していたので、これは仕方のない操作だと思う。

でも、距離によって違う意味になるというのは、慣れればともかく初心者には非常に分かりづらい。


画面下から短いスワイプというのは、Android では「隠れている3つボタンを表示」だ。

慣れる前は、ついこの操作を多用して、シェルフが表示されてがっかりした。


「シェルフと一緒に、Android で慣れた3つボタンを表示」なんて機能が将来のアップデートで付けばよいのに、と思う。


▼アプリの起動方法


上に書いた「シェルフ」について説明しようと思うのだが、便宜的に一緒に4つの概念を紹介する。


デスクトップ、ランチャー、ホーム画面、そしてシェルフだ。


まず、デスクトップ。Windows のデスクトップと同じで、いくつかのウィンドウを重ねて表示したときに、「なにもないところ」に表示されるものだ。


表示するものとして「壁紙」の絵を設定できる。

でもそれだけ。Windows のようにアイコンを置いたりはできない。


次にランチャーだ。

キーボードに呼び出すための専用キーがついていて、いつでも呼び出せる。

画面上のマウスカーソル操作でも呼び出せる。


ランチャーは画面全体を覆い、アプリのアイコンが並んでいる。アプリ以外のファイルなどは入らない。

アイコンはある程度整理可能だが、必ず左上に詰めて表示されので、自由に置けるわけではない。


Windows ではデスクトップによく使うものを置く人も多いと思うが、実際にはデスクトップは実行中のウィンドウに隠されてしまっていてアクセスしづらい。

だから、デスクトップにはなにも置けないようにして、現在実行中のウィンドウの上に重ねて表示できるランチャーを用意したのだろう。


Chrome OS の標準状態では、画面下部には Windows のタスクバーのようなものが表示されている。

そして、左端にランチャーを呼び出すボタンがある。


Windows なら、Windows アイコンがある場所だね。

そして、Windows ではこれを押すと、登録されたアプリのリストが表示される。


つまり、ランチャーはそれと同じことだ。


つづいては、ホーム画面。


上に書いた、デスクトップとランチャーは、PC モードでだけ現れる概念だ。

タブレットモードではなくなってしまう。


デスクトップはウィンドウの隙間に見えるものであり、全画面表示のタブレットモードでは不要だ、ということだろう。

でもランチャーが消えてしまうのは何故?


デスクトップモードでは、代わりにホーム画面という概念が現れる。

実際には、ランチャーの背景に壁紙の絵が貼られただけなのだけど。


ランチャーはいつでも呼び出せて、画面を一時的に覆うものだった。

使わないなら、先程までの画面にすぐ戻せる。


しかし、ホーム画面は画面が切り替わるもので、一時的ではない。

単にホーム画面を「消して」直前の画面に戻ることはできない。


でも、概念の違いはその程度だ。

つまりは、Android で慣れ親しんだホーム画面と同じようなものだ。



最後にシェルフ。

さきほど「タスクバーのようなもの」があると書いたが、実はこれがシェルフだ。

よく使うアプリのアイコンを固定しておくことができるし、現在実行中のアプリも表示され、タスクスイッチできる。

固定したアプリに関しては、いちいちシェルフを表示しないでも、キーボードショートカットで呼び出せるようになる。


Chrome OS での、アプリ起動の要となるものだ。



先程、タスクリストを表示する方法がわかりにくいという話を書いたが、そこで「Android のように操作するとシェルフが表示される」と書いた。


シェルフはタスクリストの機能を兼ねるので、実はこれでも操作することは可能だ。

(ホーム画面にもどる機能はないけど)



▼文字入力


Chrome OS を使っていると、標準では google 製の日本語変換エンジンを使うことになる。

多分、google 日本語入力なのだけど、正確なところはわからない。


変換効率などはとりあえず置いておこう。キーボードで使っている限りでは、それほど問題はない。

問題は、タブレットに切り替えたときなのだ。


タブレットモードだと、ソフトウェアキーボードが出てくる。

英語を想定した Qwerty キーボードだ。


日本語入力時も、Qwerty キーボードでローマ字入力になる。使いづらい。

タブレットなのだから、Android のようにテンキーフリック入力したい。



実は、この「文字入力」にも、Android のアプリが使える。

Android では、ソフトウェアキーボードは独立したアプリになっており、ユーザーが好きなものを使えるのだ。


そして、Chrome OS では Android アプリが動くだけでなく、ソフトウェアキーボードにも Android のものが使える。非常に互換性が高い。頑張っている。


ただ、ちょっとバグ含み。

Duet の場合、キーボードを接続すると物理キーボードを使うように自動的に設定が変わる。

そして、キーボードを外すと、標準のソフトウェアキーボードになってしまう。


つまりは、タブレットモードにするたびに、Android のソフトウェアキーボードを使うように再設定する必要がある。面倒くさい。


将来の Chrome OS のバージョンアップで修正されることを期待。


▼キーボード


これは、Chrome OS ではなく、完全に Duet の話だ。

Duet は 10inch タブレットで、そのサイズに合わせた物理キーボードが付属している。


Bluetooth 接続などではなく、専用の接続端子を使っている。そのため、キーボードを充電したりする必要はない。


このキーボード、10inch ディスプレイに合わせてあるのでキーが小さい。

人によっては、こんなものでタイプするのは無理だと言う。


でも、僕はそれほど苦にならない。

元々小さなマシンが好きで、小さなキーボード色々使ってきたからね。


小さなマシンの変態キーボードを色々使っていた人間としては、Duet のキーボードは悪くない。

キーの感触もしっかりしているし、打鍵しやすい部類だろう。


ただ、打鍵のしやすさと、指になじむかは別問題だ。

個人の好みなので、これ以上は何も言えない。



▼インターフェイス


キーボードのついでに、インターフェイスがらみの話を。これも Duet の話だ。


Chromebook は PC の扱いなのだけど、Duet はタブレットで、どう見ても Android タブレットに違う OS を入れただけ、と考えてよいと思う。

そのため、PC としてのインターフェイスは貧弱だ。


USB-C が1つしかない。イヤホンジャックすらついていない。

ただ、標準で USB-C からイヤホンジャックに変換するアダプタが付いてくる。


USB-C という企画は、いろいろな信号を引き出せるように設計されている。

だから、変換アダプタさえ購入すれば、十分な拡張性がある。


HDMI を使って外部モニタにつなげる事もできるし、普通の USB コネクタ(USB-A)で周辺機器をつなぐこともできる。


まぁ、つないでもドライバがないものも多いけど。

USB メモリとか、USB HDD は使えるようだけど、僕は実際試していない。


軽量タブレットに、外付けの拡張アダプタまで使っていろいろ拡張する必要があるのかは疑わしい。

でも、ちゃんと PC らしい拡張性は確保されているようだ。


▼OSの軽量さ


さて、ここで Chrome OS の形容詞のように言われる、「軽量」について書いておきたい。


そもそも論だが、Chrome 自体が「軽量なブラウザ」を目指して開発された。

しかし、軽量さで人気が出ると、ユーザーの多くは「高機能」を要望し、高機能には代償が必要だった。

結果として、現在のところ「メモリをバカ食いする困りもの」とする人が多い。


Chrome OS の開発がスタートしたころは、まだ Chrome 自体が軽量だった。

そして、OS 自体も Chrome だけを動かすことに目的を絞り、機能を削ぎ落せば軽量な環境になる、という計画だった。


しかし、現在では Chrome 自体が軽量でなくなり、Chrome OS 自体も Chrome 以外に Android アプリや Linux 環境も動かせる、互換機能を持つようになった。


Chrome OS は起動が速い、とされるが、昔使っていた Chromebook に比べ、Duet は起動が遅いように感じる。CPU 速度は上がっているにもかかわらず。

といっても、8秒程度。Android や Windows に比べると、ずっと起動が速い。


まぁ、実際に使っていると起動することはほとんどない。

普段はスリープしておく。これだと、復帰までは1秒かからない。




ここからは少し内部の話になるが、「Chrome OS」というのはある程度言葉のあやで、実際には Linux OS の上に、Chrome のユーザーインターフェイスをかぶせたものにすぎない。

もともと、Chrome さえ動けば良いので、CPU 種別を問わないという設計だった。


同じように、Android は Linux の上に Android の実行環境をかぶせたものだ。

この Android 環境というのはよくできていて、CPU を問わずに同じアプリを使える、という仕組みになっている。

その分、OS には余計な仕組みが増えており、起動は結構遅い。

しかし、Chrome OS はこの環境を取り込んでいるにも関わらず、非常に高速に起動する。


現在の Chrome OS は、Android も内部は Linux なのだからと、Android の実行環境を取り込んだ格好だ。

といっても、これは簡単なことではない。Linux が中心にあるといっても、周辺のソフト環境は全く異なるものだからだ。


そこで、Docker という仮想環境をつかうことで、異なる Liinux 環境を共存させている。

ユーザーが自由に使える Linux 環境も提供されているが、これも内部の Linux を見せているわけではなく、仮想マシンだ。


軽量と言われているが、結構複雑な仕組みだ。


これほど複雑ではない、初期の Chromebook は、面白い環境ではあったが僕としては「遊べるおもちゃ」程度の評価だった。

Chrome さえ動けばできることは多い、というのを見事に実証してみせたけど、それだけ。

実用にするにはなにかが足りなかった。


しかし、Android 環境を統合したことで、その足りなかった何かが満たされたように思う。

Chrome さえあれば、という初期の理想とは異なっているのだけど、名を捨てて実を取ったのだろう。


▼Bluetooth


Android と違って待受がないことで、僕の使い方では1つだけ不便になったことがある。


先に書いたように、僕は家事の際に Prime Video を楽しんでいる。

このとき、まず Bluetooth イヤホンの電源を入れる。


Android タブレットであれば、すぐに本体に接続して、画面が点灯した。

しかし、Chrome OS では接続できない。スリープ中で CPU が動いていないからだ。


そこで、本体の電源に手をのばす一手間が増える。

たいしたことではないのだけど、これも Chrome OS が PC だから起きる現象だ。


さて、料理をしながらビデオを見ていると、電子レンジを使うときに困ったことになる。

電子レンジの電波周波数は、Bluetooth と同じ帯域であり、通信障害を起こすのだ。


通信障害を起こすと、音声が途切れる。まぁ仕方がない。


Android では、途切れた音声は再送され、少し途切れて続きが聞こえる。

でも、この間も動画は止まらない。結果的に動画と音声がずれる。

あまりずれすぎると、音声を送るのを諦めて間が飛ばされる。


しかし、Chrome OS では、音声が途切れて再送されるときに、動画も一瞬停止する。

このため音ズレは起きないが、動画再生がカクカクになる。


どちらが良いという話ではなく、Android アプリの実行環境はあるが、完全エミュレートなどではなく Chrome OS の機能を使ったものだ、という話なのだ。

動画再生などの機能は OS が提供しているが、その部分の違いで動作に差が出る。


これは、Android アプリの実行環境が、無理やり後付したような不格好なものではなく、ちゃんと OS の深い部分に組み込まれているという証拠でもある。


最初の方で書いたが、ディスプレイ解像度を変えてもちゃんと動作することとか、Windows のリサイズでもちゃんと動作することとかと併せ、非常に良くできている。


▼Android 端末との連携


Chrome OS には、Android 端末を Bluetooth 接続に登録することで、色々と便利にできる機能がある。


まずはログイン時。ロック解除されたスマホが近くにあれば、正当な持ち主によるログインだとみとめられ、パスワード入力などを省略できる。


ただし、電源を入れて最初のログインは、正しいパスワードを必要とするようだ。

また、スリープからの復帰時にパスワードを必要とするかどうかは設定で変更できる。


なので、僕はこのログイン機能を使っていない。

あまり外出しないからそれで良いのだけど、Chromebook を持ち歩く人は、紛失に備えてスリープ復帰時にもパスワードを求めたほうが良いだろうね。


次に、ネットワークのテザリング。

ChromeOSが WiFiネットワークに接続できないとき、スマホのネットワークを利用してよいか訊ねてくる。使うことを許可すると、スマホ経由で WiFi なりモバイル通信なりを使ってネットワーク接続する。


実のところ、Android には Bluetooth テザリングという機能があり、Bluetooth 接続を経由して他の端末のネットワークを利用できる。

でも、その機能を使うのは結構面倒だ。利用するたびに、両方の端末で操作が必要になる。周囲のマシンに勝手に通信を行われるって、色々と問題あるからね。


Chrome OS では、このテザリング機能を使っているわけではなく、連携の一環としてのテザリングを行う。

だから、Android 側のテザリング機能が OFF になっていても使える。

最初に登録しておけば、以降は Android 側で操作する必要はない。


これは素晴らしい機能だ。



もうひとつ、SMS を Chrome OS に受け取ったり、送信したりする機能がある。

ただ、僕は普段 SMS を使わないので、この機能はまだ使っておらず、詳細がわからない。


スマホのメッセージ機能はスマホメーカーが独自に作ったものが入れられていることが多いが、Chrome OS と連携できるのは Google 製 SMS を使っているときだけ、という問題もある。

僕は SMS を使わないので、わざわざ Google 製を入れてまで動作確認してみようという気が起きない。



▼その他


Chrome OS は、ローカルにファイルを置かない前提で設計されていた。

ファイル置き場としては Google Drive を使う。


しかし、フルセットの Chrome なので、ファイルをダウンロードすることができる。

これは当然のことながらローカルに置かれる。


このファイルを見るためのアプリは、初期の Chrome OS から用意されていた。


このアプリは結構できが良くて、ローカルファイルと Google Drive のファイルを見ることができた。

さらに、機能拡張を入れることで、Dropbox や マイクロソフトの OneDrive 、家庭内の NAS や Windows マシンでの共有ファイルも見られた。


Duet のファイルアプリを見たら、家庭内の NAS や Windows に関しては、機能拡張無しで見られるようになっていた。

地味な改良だがありがたい。


僕は家庭内で持ち運んで気軽に使えるマシンを求めているので、家庭内のファイルに自由にアクセスできるというのは大切なことなんだ。


▼まとめ


IdeaPad Duet は現在大人気機種で、使用記を書いている人も多い。

僕も、そうした使用記を見て、よく検討してから購入したのだが、やはり自分で使ってみないと実感できない事は多かった。


おそらくは、使う人を非常に選ぶマシンだ。


最初に書いたとおり、PC とスマホの隙間を埋めることができる。

だから、すでに PC とスマホを持っていることは前提だ。できれば、Windows と Android がいいだろう。

Chrome OS の操作系は Windows を参考にしたものだし、動作するアプリは Android だからだ。ついでに言えば、Android と連携して通信を行う機能もある。


MS Word は動くか、というのは愚問だ。

上に書いたように、それは Windows の仕事だから。でも、下書き原稿を作ることはできるし、すでにできた原稿を、ある程度互換性のある Google Docs で見ることはできる。


Web 版 Office や Android 版 Office が使える、と書いてあるページも多いのだが、あまりおすすめしない。それらは結局 Word 互換の、Word ではないソフトだ。


ならば Word は使えない、と割り切ったほうが良いし、Word が使えないとだめなら Windows サブノートを探すべきだろう。


しかし、できないこともあると十分理解して使うのであれば、非常に軽くて小回りが利き、それでいてちゃんとパソコンとしての性能を発揮できる機械、というのはいい相棒になるだろうと思う。



(この記事は、Duet で Google Docs を使って大まかに下書きした後、Windows で仕上げた。

 そういう使い分けがやりやすい、というのもポイントの一つだ)



▲目次へ ⇒この記事のURL

関連ページ

Lenovo Ideapad Duet 購入【日記 21/02/23】

IdeaPad Duet の使い勝手(2/2)【日記 21/03/01】

IdeaPad Duet の使い勝手(1/2)【日記 21/03/01】

別年同日の日記

09年 おゆうぎかい

14年 冒険遊び場

15年 イチダントアール

16年 シーモア・パパート 誕生日(1928)

17年 エドウィン・ハーバード・ランド 命日(1991)

20年 長男、高校合格


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

暮らしの中の微分積分  2021-03-16 20:34:53  コンピュータ 数学

▲目次へ ⇒この記事のURL

少し前の日記で、微分積分は役立つよー と書いたのだけど、話の腰を折るのであまり具体例に踏み込まなかった。


これ、自分の中で気になっていて、もう少し説明したいと思っていた。


僕はプログラマーなので、これから書くのはコンピュータープログラムとしての微分積分の話だ。

そして、プログラムとしての微分積分というのは、高校で習ったアレは何だったのかと気が抜けるほど簡単だ。


まぁ、高校で習ったことはちゃんと意味があるので、そのフォローは最後にやる。


▼積分の概念


というわけで、微分積分の「考え方」から説明しよう。

微分積分、と言っているとややこしいので、まずは積分に話を絞る。


前提知識として、足し算は理解しているものとする。

足し算がわからない人には、さすがに説明ができない。


では、[ 3, 3, 3, 3 ] …3 が4つあるのだけど、全部足してみて欲しい。


答えは 12 だ。3 + 3 + 3 + 3 でいいのだけど、3 × 4 と考えるとすぐに答えが出る。


次に、[ 3, 4, 5, 6 ] を全部足してみて欲しい。


今度は掛け算は使えないので、地道に足し算をするしかない。

3 + 4 + 5 + 6 で、答えは 18だ。


概念的には、後者が積分にあたる。


たくさんの数をまとめて足す方法が積分。

そのうち、数が「たまたま全部同じだった」という特殊な場合が掛け算だ。




ここに書いた例では、4つの数を足しただけだった。

これが、数万という数があると考えて欲しい。とても手計算で足し合わせることはできない。


でも、それらの数に何らかの法則があって、数式で表せたとしよう。


こうなると話が変わってくる。足したい数の概要を数式として示せたので、これをもとに「全部足した結果」の数式を作り出す。

すると、数万件の足し算をする必要がなくなり、すぐに答えが出る。


これが、高校で習う積分だ。


ただ、数式で表すとなると、整数だけが相手というわけにはいかない。

式を変形するための前提条件などもいろいろと付き、話が複雑になっていく。


結果として「難しい」と思われてしまうのだけど、やりたいことは「全部足す」なのだ。


さて、そこでコンピューターが開発された。

最初は、「ひたすら足し算」しかできない機械だった。

でも、足し算さえできれば積分計算ができる。それで十分だ。


今のコンピューターもその延長上にあるので、プログラムのいたる所に積分が顔を出す。

多分、多くのプログラマーが、積分だとも思わないまま使っているのだけど。



▼積分の具体例


具体例をあげよう。


最近の家庭用テレビゲーム機では、コントローラーを振って操作することができる。

3Dのゲームで、コントローラーを左右にふることで、左右を見ることができたりね。


これ、コントローラーには「向き」を知るための仕組みは入っていない。

入っているのは、加速度センサーだ。


加速度、というのが馴染みが薄いかもしれないのだけど、単純に力のことだ。

加速度センサーは、コントローラーにかかる力を知ることができる。


そして、速度に加える、という名前の通り、足し算を続けると…つまり、ここまでに説明したように「積分」すると、現在の速度が得られる。


さらに、速度を積分すると、今度は現在の位置が得られる。

自分の体を中心としたコントローラーの位置と考えると、「向き」と近似のものだ。


こうして、加速度センサーから得られる値を、2回積分することで、コントローラーからは直接得られない「向き」を算出しているんだ。



積分を行うと、値のもつ「意味」を変えることができる。

ここでは、加速度を速度に、速度を位置に、変えることができた。


長さを面積に、更に体積に変えることもできる。

掛け算でも同じだけど、先に書いたように、掛け算は積分の特殊な場合だから。


プログラムしていて、欲しい値が手に入らない、ということはよくある。

そうした場合でも、手元にある値を積分することで、欲しい値を作り出す事ができる。


プログラマーなら、こうしたプログラムの経験はいくらでもあるだろう。

積分というのは特別なことではなく、ごく当たり前に使われるものなのだ。




また別の例を上げる。


積分を使うと、複雑なものを単純化できる。


物を投げたときの位置は、それほど難しくない数式で示すことができる。

いわゆる放物線だ。


まぁ、人がボールを投げるくらいなら放物線の式で問題ない。

でも、高速で動く場合は空気抵抗が問題になり始める。

そこまで考慮して位置を示す式を作ろうとしても、複雑すぎて作ることができない。



そこで積分を使う。

いきなり位置を表す式を作るのではなく、まず速度の式を作るのだ。

空気抵抗は速度によって変わるので、速度をもとに空気抵抗を求め、その空気抵抗で速度が変わるようにする。


そして、その速度を積分して位置を求める。

ここで言う積分は、もちろんコンピューターの計算力で足し算を繰り返すことだ。


このように、複数の段階に分けることで、複雑すぎて手に負えない計算も行うことができる。


こちらも、プログラマーにとってはそれほど特別なことではないね。

ゲームを作る人なら、いろいろな条件で途中から動きが変わったりする、つまり「加速度」を持つプログラムは当たり前に組むだろう。


▼微分


積分の話を2つほど挙げたが、続いて微分のことを書こう。


微分は積分の逆の操作だ、と思ってだいたい間違いはない。

微分して積分したらもとに戻る。


積分がすべて足すのに対して、微分は直近の値を引く。

これによって、直近から値がどのように変わったのか、その「差」を調べることができる。




積分例として、ゲームコントローラーの話を書いた。

コントローラーには加速度センサーしか入っていないが、積分すれば位置がわかる。


逆の話として、スマホのタッチパネルのことを書こう。

タッチパネルに指を触れると、その位置がわかる。でも、位置以外はわからない。


しかし、タッチパネル操作でスクロールを行うとき、「フリック」すると、その時の速度でスクロールが続く。


ここでは、指の位置情報を微分することで、速度を求めているんだ。


フリックとは、指を動かしている最中に、急にタッチパネルから離す動作。

指が離れた直前の速度がある程度あった場合、そのままスクロールを続けるようにする。


そして、徐々にスクロールが止まるのは、速度を変化させる、逆向きの加速度を設定している。

これらの動作は、積分を行っている。




微分すると、変化がわかる。

これを多用しているのが、写真などの加工アプリだ。


ある点に注目したときに、すぐ隣の点との差を出す。

これを画像のすべての点について行い、その結果を新たな画像とする。


これが「画像を微分する」ということなのだけど、この結果得られるのは、色の変化するところを拾い出したような画像だ。

いわゆる「輪郭抽出フィルタ」だと思っていい。表示の方法によっては、レリーフ化フィルタになる。


この輪郭に対してもう一度微分すると、輪郭のすぐ隣の点を際立たせるデータが得られる。

これを元の画像に重ねると、輪郭がくっきりとする。

「シャープフィルタ」とか「ピンぼけ補正フィルタ」と呼ばれるものだ。


ここに書いたのは単純な原理だけで、実際の画像処理ではもっと工夫された処理が使われている。

しかし、微分の応用範囲の広さはわかってもらえると思う。



▼微分積分とは


これ以上書いても同じような話ばかりになりそうなので、少し話を変えよう。


微分積分というのは難しいものだ、と思っている人は多そうだ。


でも、コンピューターで計算するときは、ただの足し算引き算だ。

特に難しい処理ではない。


じゃぁ、なんで高校ではあんなにややこしい教え方するのさ、という話。


これにはもちろん意味がある。

微分積分学は19世紀に大きく発展したのだけど、コンピューターの登場は 20世紀なのだ。


だから、学問としてはコンピューターのほうが新しく、難しい。

高校でやるのは積分の「基礎」で、コンピューターを使うのは「応用」なのだ。


今回書いた話も、概念としては「微分積分」なのだけど、数学的な妥当性はちょっと怪しい。

わざと簡単な話だけやっていて、ややこしい話は避けたからね。

真面目に書こうとすると、高校レベルの数学では収まらない話になる。


でも、今回僕が示したかったのは、数学的な妥当性ではない。

難しいと思って避けている人が多い「微分積分」が、案外身近に使われているし、考え方自体は簡単なものだと知ってほしかったのだ。


▼最後に


微分積分の話、もっと書きたいことはたくさんある。

でも、何でもかんでも盛り込むと話が横道にそれ過ぎて、わかりづらくなる。


今回も、これでも泣く泣く削った話が多数あるのだ。


諦めきれないネタを2つ、概要だけ示す。

説明は長くなるからしない。書きたいから書きっぱなしにする、というだけ。


・太陽の位置と季節の話


12月の冬至と6月の夏至が「昼と夜の長さ」のピークなのに、寒さと暑さのピークは2月と8月だ。

なんでピークがずれるのか気になったことはないだろうか?


太陽の運動を正弦波、太陽エネルギーを気温に変えるのに積分が必要だと考えると、大体理解できる。


・フーリエ変換


異世界転移の魔法。

ネイピア数を虚数乗することで複素空間に円形の魔法陣を描き、そこに波動をぶつけて積分すると「周波数空間」という異世界に転移できる。

もちろん、異世界に行ったら無双できるのがお約束。


…と、与太話を書いてから真面目に解説したかったのだけど、そもそもこの与太話がフーリエ変換を理解していないとわからないし、解説もすげー長くなるからやめた。



▲目次へ ⇒この記事のURL

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

数学

関連ページ

異世界転移の方法【日記 21/04/01】

別年同日の日記

05年 大忙し

09年 辻堂海浜公園

15年 ドットリ君

17年 タネンバウム教授(1944) ストールマン(1953) 誕生日

20年 ソフトウェアリリース


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


戻る
トップページへ

-- share --

0000

-- follow --




- Reverse Link -