目次
前のページ
2020-11-18 経年劣化２
2020-11-23 サーバーダウン
2020-12-07 HTMLで多数のデータを表示する。
2020-12-13 ピクミン３デラックス
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 暮らしの中の微分積分
2021-06-04 ヘッドクリーニング
2021-06-25 イヤホン
2021-07-04 QNAP TS-251D 購入
2021-07-04 251D 使用レビュー
2021-07-17 FFMPEG
2021-07-18 続・FFMPEG
2021-07-24 IOCCC
2021-08-29 SSL 証明書
2021-10-08 コンピューターと気象予測
次のページ
先日、電源というのは経年劣化する消耗品だよ…という話を書いたら、そのすぐ後に大きな「電源」が経年劣化で壊れた。
先日書いた意味での「電源」は、交流・直流を変換する機器の意味で書いたのだけど、今回壊れたのは、UPS。
UPSというのは「無停電電源装置」と呼ばれる。
コンセントから常に充電し続け、ふたたび交流 100V を出力する機械。
停電が起こっても、しばらく 100V 出力を続けられる。
まぁ、実際停電になってもサーバーを止めないでよい、というほどの効果はない。
時々起こる瞬停に対応できるというのが最大のメリットか。
ちなみに、瞬停とは、0.1 秒程度の短い停電。
電力会社が、何らかの都合により送電経路を入れ替えるときなどに発生する。
最近の機械は、0.1秒程度の停電には耐えられるような電源を使用しているけど、動作は保証されない。
我が家の UPS は、２年前に「買い替え」ていたのだけど、古いものも残っていた。
これは全くズボラな話で、新しい装置にサーバーなどの停電が致命的なものは繋ぎ変えたのに、ルーターやハブなどの「致命的ではないが、なんとなく止めづらい」ものを繋ぎ変えてなかったため。
で、壊れたのは古い UPS 。
夜、寝ようとしていたら急にサーバールームから「ピーーーーー」という連続 Beep 音が聞こえてきて、慌てて原因を探ったら UPS だった。
すぐ電源切って、ルーターなどを新しい UPS につなぎなおした。
勘違いでつなぎなおしていないネットワーク機器があり、うまくネットがつながらなくて焦ったけど、実際のところつなぎなおしたら済む程度のトラブルだった。
この UPS 、いつかったっけかな…
少なくとも、2011 年の東日本震災の時には使っていた。
普通は２～３年で寿命、と言われるので、使い過ぎ。
まぁ、だからこそ２年前に買い替えていたのだけど。
電源は劣化するよ、なんて話を書いていたのに、自分がお粗末でした。
別年同日の日記
申し訳ありませんが、現在意見投稿をできない状態にしています。 |
三連休の初日から、サーバーがダウンしていたようだ。
悪いタイミングで落ちたもので、連休中は家族と過ごす時間が多く、気づかなかった。
ツイッターで教えてくださった方に感謝。
原因は DB の一部破損で、テンポラリデータで特になくなって困るものではなかったので、テーブルを作り直した。
これで安定動作するか、しばらく様子見。
４時間後に追記
…やっぱだめだった。
「しばらく様子見」と書いた５分後には、落ちた。
仕方ないので、一旦「トラブルにつき復旧中」の旨を静的ファイルで表示するように設定変更。
どうも、mysqld が落ちてしまうようだ。原因究明。
えーと、紆余曲折あって、たぶん解消。
途中、何度かサイト再始動しては、落ちるを繰り返している。
原因が何かわからないため、たぶん原因ではない「問題になりそうな点」も、順次解消して回った。
innodb の設定を変更してみたり、通信バッファを広げたり。
DB の全データをバックアップして、設定を変えた状態でリストアしたり…
つまりは、DB のファイル構造を作り直したりもした。
でも、たぶん真の問題はメモリ不足。
仮想サーバーなので、メモリ割り当てを増やしたら安定した。
こういう時の作業は、たいていは素直にはいかず、些細なトラブルが頻発する。
そして、些細なトラブルを乗り越えるのに時間がかかる。
そのため、思った以上に時間がかかってしまった。
（こういう時の作業は、普段起こらない「極端な負荷」をシステムにかけるもので、普段出ないエラーに遭遇する。
たいていは、設定を少し見直せば済むだけの些細なものだが、普段見ないエラーだから意味と対処法を調べるのに時間がかかるのだ。）
また様子見だが、今度は大丈夫だと思う。…思いたい。
別年同日の日記
申し訳ありませんが、現在意見投稿をできない状態にしています。 |
作成している WEB サービスで、データを１万件ほど表示する必要があった。
それまで作っていたスペックでは、せいぜい 100件程度だった。
HTML で小さなウィンドウを作り、その中を CSS 設定で縦スクロールするようにして、内部に 100件のデータを入れる。
まぁ、よく見るインターフェイスだ。
そのプログラムのまま、中身を１万件にしたら、いろいろと問題が出た。
まず、表示を指示してから実際に表示されるまでが遅い。
そして、表示されてから、スクロールしようとすると非常に重い。
１万件ものデータ処理だから遅いのかな、と思って、Javascript の速度を調べると、
データ処理には 100ms 程度しかかかっていなかった。
表示までは５秒程度かかったのだが、これらはほとんど、挿入された HTML の解釈時間だということになる。
いろいろ実験するも、1000件程度までは実用になるのだが、１万件になると実用的な速度ではない、と分かるばかりだった。
初期表示の遅さについては、まず 100件程度を表示してから、徐々に追加していったらどうだろう、とか試してみた。
確かに、すぐに表示はされるのだが、その後スクロール処理がどんどん重くなる。
1/10 秒ごとに 100件づつ追加、とかしていると、この追加のたびにかかる処理速度も、どんどん重くなっていく感じがする。
…うん、たぶんすでに表示しているデータ件数 n に対して、新たなデータを入れるときの処理速度が n*log n に比例しているのだ。
これ、プログラムしているとよく見る構造だ。つまりは、内部的に DB を構築していて、データ件数が多くなると挿入速度が遅くなっていく。
実際、HTML は内部で DOM ツリーというものを構築する。これはツリー構造の DB に他ならない。
何か操作を行うたびに、このツリーをたどり、どの部分を操作対象とすべきか、画面表示の対象とすべきか、などをチェックしていく。
ここら辺は、ブラウザ内部での処理の問題なので、Javascript で高速化できる問題ではない。
問題を棚上げして別の仕事をしていて、ふと気づいた。
そもそも、HTML の量が多いのが問題なのだ。Javascript 側は、１万件くらいなんてことない。
じゃぁ、HTML のコード量は最小にしよう。
先に書いたように、データの表示は小さなウィンドウ内で、スクロール表示になっていた。
１万件あっても、実際に表示されているのは 10件程度だった。
div のスクロールイベントにフックをかけて、現在のスクロール位置を取得する。
データは、１行１データのようにきれいに並んでおり、１行の高さも決まっていた。
なので、スクロール位置から、現在表示されるデータが何行目かも判断できる。
何行目を表示するかわかれば、それより「上」に何行あるかもわかる。これらは画面外のデータだ。
だから、HTML としては最小限に、全部をまとめて「高さだけ」をブラウザに伝えることにした。
div を作り、style で height を指定すればよい。
下方向も同じように、画面外は div １つで済ませる。
そして、表示したい部分の１０行ちょっとだけ、その場で生成してブラウザに渡す。
１０行程度なので、ブラウザは瞬時に解釈を終え、遅延なく表示される。
上下に div を作っているのは、スクロールバーを「あたかも１万件のデータがあるように」表示するためだ。
でも、HTML には１０件程度のデータしか入っておらず、スクロールするたびに書き換える。
実際には、そのプログラムでのデータ表示はこれほど単純ではなく、一部だけ行の高さが変わったりもしていた。
でも、規則性があるので div の「高さ」をそれに合わせて調整するような計算式を作った。
上端と下端の部分も、破綻しないようにプログラムする必要がある。
しかし、それらは些細なことだ。
大量のデータで HTML が遅い時の処理方法をネットで探していたが、あまり見当たらなかった。
DOM の遅さ、という話になると、単純なハンドリングの速度の話だけで、極端に多いデータの際にスクロールすら遅いのをどうにかできないか…というような話題にはならないのだ。
まぁ、個別論だから一般的に論じにくい、というのもあるとは思うが。
今回の例では、スクロールのたびに DOM を大きく入れ替える、という「DOM が遅い」という話題ではやるべきでないことをしている。
でも、それによって HTML 量を極端に減らすと、DOM の処理速度は劇的に改善する。
…やっていて「時期尚早な最適化は害悪」という言葉を実感していた。
当初は、今までのやり方で何とかならないか、と最適化を試みていたんだ。
でも、どうにもならないと思って大きく作り変えたら、問題は簡単に解消した。
しかも、このプログラムは速くなるようになんて書いてない。
DOM 操作に jQuery とか使ってるし。
（古いプログラム部分が多いので、過去に作った部分はそのままなのです）
最適化を考える前に、根本原因が何かをちゃんと見極めよう、って話です。
関連ページ
別年同日の日記
申し訳ありませんが、現在意見投稿をできない状態にしています。 |
一応遊んだので感想を書いておこうと思ったのだが…
世の中的には絶賛されているゲームなのですが、僕としては残念な出来、と最初に書いておきます。
そういう感想記事です。
基本的に人に勧められるようなゲームでないと感想は書かないので、「感想を書く程度には面白かった」と捉えてください。
悪いゲームではないです。
ピクミン１、２に関しては、かなりやり込みました。
当時は子供もいなかったのでね。
Wii U で発売された３は遊んでいません。Wii U 持ってなかったし、その頃は子育てが忙しすぎて、ゲームどころではなかった。
Switch 購入以前も、子供は多少テレビゲームを遊んでいましたが、それほどやっていません。
だから、Switch 購入時には、すでに旧型であった Wii U を買ってピクミン３を遊びたい、と子供に言われました。
僕は今更 WiiU を買うつもりはなかったので、「多分 Switch には移植されるので、出たら買う」と子供に約束しました。
これはなだめるための適当な約束のつもりではなく、ゲームキューブのピクミンはその後 Wii に移植されているためです。
Nintendo 64 のゼルダもゲームキューブに移植されていたり…
「あまり売れないゲーム機で発売されたが、名作と呼ばれるものは、任天堂は次のゲーム機に移植する」と考えていました。
発売までにずいぶん時間がかかりましたが、実際移植されたので購入しました。
遊んでみて、最初から多くの違和感に襲われました。
これは、ピクミンの名を冠してはいるが、別物のゲームだ、というのが正直な感想です。
なぜこんなことになったのか、いろいろと原因を考えながら遊んでいたのですが、やっと一つの推論に辿り着きました。
おそらく、ピクミン３は外製のゲームエンジンを使用して作られているのではないか、と。
ゲームエンジンとは、ゲームを作るのに必要なプログラムをまとめたライブラリです。
どんなゲームにも共通で使われるような処理、というものは存在しており、それらをまとめて販売しているものです。
こうしたエンジンを使用することで、ゲームを作る工程は大幅に削減され、開発期間が短縮でき、コストも抑えられます。
また、通常はゲームエンジンは、様々な環境に移植されています。
グラフィックスやコントローラー周りの「機種ごとの差」が大きい部分は全部ゲームエンジンが対応し、ゲーム本体のプログラムは純粋にゲームだけを作成すればよいのです。
結果として、大きな移植の手間もなしに、複数の環境への対応が完了します。
ゲームエンジンを使用するメリットは大きいのです。
ピクミン１のころは、こうした「ゲームエンジン」という概念は普及前でした。
もちろん、各社が独自にライブラリを作ったり、概念的に近いものはあったのですが、専門にゲームエンジンを作成するような企業があったわけではないのです。
ピクミン２も、おそらくはピクミン１の改造として作られているので、ゲームエンジンは使用されていないでしょう。
でも、おそらくピクミン３では、任天堂外の会社が作成したゲームエンジンを使用しています。
…これは推論にすぎませんが、この違いがゲーム性に大きな違いを生み出してしまっています。
現代的なゲームエンジンには、物理演算の機能が含まれるのが普通です。
キャラクターごとに重さや弾力性などを設定し、他のものに「ぶつかる」かどうかを設定し…
各種設定を行っていけば、プログラムを１行も書かなくとも、一般的な物理現象に従った動きは行ってくれます。
ピクミンは、まるで本当に存在しそうな「小さな生物」たちが冒険するゲームです。
１の時から、存在しえないファンタジーであることは理解したうえで、非常にリアルな世界観で人気を呼びました。
おそらくは、その「リアル」を上乗せするために、物理演算も使用したゲームエンジンを組み込んだのではないかと想像します。
しかし、ゲームはファンタジーの世界に遊ぶから楽しい、という場合があります。
リアルは制限されなくてはなりません。
ピクミンの場合、１・２では、ピクミン自体は「個々には存在するが、互いに干渉しない」存在でした。
１００匹の集団がいるのではなく、１匹のピクミンが１００体いるのです。
ですから、操作次第では、非常に小さなスペースに１００匹のピクミンを押し込めることができました。
作業をするときも、狭いスペースに多人数を投入し、すぐに終わらせることができました。
多くの部下を効率的に使う、というピクミンのゲーム性は、こうして作られたものでした。
しかし、３のピクミンは「１００匹の集団」です。お互い干渉するため、連れ歩くには広いスペースが必要になります。
限られた作業スペースに多人数を配置すると、「押し出されて」作業しないものが生じます。
壁を壊そうとしても、働かないピクミンが出るため、投入人数に比例した作業速度は得られません。
荷物を運ぼうとしても、上限人数にはまだ達していないのに、なかなかピクミンが作業しようとはしません。
こうした「リアル」のために、ピクミンの楽しみの一つである「やり込み」が大きな制限を受けます。
一番重要な要素…人数を割り振ることによる、時間短縮が行えないのです。
ピクミンの楽しさの一つは、人数配置を考えることでした。
その要素は残されているのですが、「思ったように動かない」のは、非常に残念なことです。
（注：厳密にいえば、１でも多少の干渉はありました。
狭いスペースにピクミンを多数投げ込むと、押されて落ちてしまう、など。
しかし、基本的には「プレイヤーの意思を妨げない」ように作られていたのです。
３では、プレイヤーの意思に反する動きをすることが非常に多いです。）
先に書いたように、ピクミン１・２では、非常に狭い空間にピクミンを押し込めることができました。
これを使って、獰猛な敵からとにかく逃げ回ることも多いゲームでした。
しかし、ピクミン３では、ピクミンの集団はある程度の広がりを持ちます。
敵が獰猛なままでは難しくなってしまうためか…よほどのろのろしていない限り、敵が襲ってこなくなりました。
なので、集団で襲い掛かれば、安全に敵を倒せます。敵が襲ってくる前に倒してしまえるので。
１・２では敵に対して慎重に対処しなくてはなりませんでしたが、３は力押しのゲームです。
結果的に、敵はピクミンの餌にすぎません。
弱肉強食の食物連鎖を描いたことで文化庁メディア芸術祭優秀賞をとったピクミンですが、３ではそうした食物連鎖を感じさせないのです。
「力押しのゲーム」になってしまった原因は、他にもあります。
ピクミン自体が死ににくくなったためです。
水に落ちてもおぼれません。しばらく泳いでいるので、呼べば上陸します。
火がついても死にません。しばらく走り回っているので、呼べば火が消えます。
電撃を受けても死にません。気絶して倒れているので、呼べば起き上がります。
一応、赤は火に強い、青は水に強い、黄色は電撃に強い…などの特性はあるのですが、あまり気にせず力押しで何とかなります。
１・２のころはすぐに死んだので、死なないように考えるパズルゲームでした。
しかし、３は「死にそうになったらすぐ呼べばよい」という、忙しいアクションゲームです。
物理演算の話に戻るのですが、敵にくっついていたピクミンが「ふりはらわれる」ことがあります。
この時、ピクミンは１・２のころよりもはるかに遠くまで飛ばされます。
これもおそらくは、物理エンジンの挙動のためではないかと思いますが、詳細はわかりません。
ともかく、遠くまで飛ばされて、時として「本来は入れない」エリアに入ってしまうことがあります。
そして、入れないエリアからでも戻ってこられれば良いのですが、戻ってこれないことも多いのです。
そもそも入れない場所だから、歩き回れるような設計になってないのでしょうね。
こうした、意図しない箇所にピクミンが入ってしまう、という挙動には、作成スタッフも悩んだのではないかと思います。
ゲーム中いたるところに、「通り抜けられない見えない壁」が設置されています。
そして、場合によっては…というか、ごく普通になんですけど、「特定のことをして道を作る」部分にも設置されています。
たとえピクミンやプレイヤーが進めたとしても、その「特定のこと」をしていない限り、見えない壁に阻まれて前に進めないのです。
初見プレイで仕掛けを知らず、「どうやって進むのだろう？」と考えたとします。
いくつか仮説を立ててやってみます。そういうことができる楽しさがピクミンなので。
でも、たとえうまく進むことができても、制作側の考えと違う場合は「見えない壁」が立ちはだかるのです。
制作側の考えがなんであるかは、見た目からはわかりません。超能力者のように相手の考えを読まなくては先に進めないゲームになるのです。
…本来なら、「正解以外の方法で目的を達成できない」ような作りになっていればよいのですが、別解がいくつも作れてしまうことが問題だと思います。
でも、別解は許されないのです。
まぁ、実はこれは些細な問題で、初回プレイが楽しくないだけです。
何度かプレイして正解がわかれば、後は正解以外のプレイをしなくなるだけなので、楽しく遊べるようになります。
…初回プレイのイライラで嫌にならなければ、ですけど。
さて、上に書いた「見えない壁」ですが、ピクミンのサポートのためにも存在します。
先に書いたように、ピクミンの大集団は広がりを持ちますが、そのままでは狭い橋を渡るときなどに困るのです。
そうした場合、見えない壁がそっとピクミンをサポートし、落ちないようにしてくれます。
なんて親切設計。
…でも、この壁、万全ではないのですね。ピクミンが多数で押し合いになると、壁が乗り越えられてしまうことがあります。
初心者プレイヤーのイライラの対象となる「見えない壁」が、サポートとしても不十分で、上級者プレイヤーのイライラのもとにもなるのです。
ところで、今作ではピクミンが単独行動をとることもあります。
１・２では、基本的にプレイヤーキャラについて歩き、「獲物を持ち帰る」時だけ単独行動でしたが、その行先はロケット前という「安全地帯」でした。
３では、往復作業が設定されています。作業が終わったらもとの地点に戻り、まだ仕事があれば続けて作業するのです。
この場合、すべての作業が終わった後は、「元の地点」に戻ったところで待機します。
ピクミンでは、日没…時間切れの際に、ロケット前か、隊列にいないものは死んでしまうことになっています。
なので、待機場所があるならそこで待機、というのは重要なことです。
しかし、先ほどから書いている「ピクミン同士が押し合う」問題で、全く予期しない地点で待機するピクミンが出ます。
往復作業中にほかのピクミンに押され道を外れると、時として「戻り方がわからなくなり」そこで待機するのです。
これは突発的におきます。
往復作業の時間が乱れますし、日没時の死亡にもつながります。
さて、ゲームエンジンが原因になっているのではないかな、という問題点はこんなところ。
でも、ピクミン３の問題点はこれだけにとどまりません。
キーワードは「高低差」ですね。
１・２では、地形は基本的に平面に近い構成でした。
高低差はありましたが、なだらかなものでした。
しかし、３には激しい高低差があります。
それだけなら、起伏にとんだ地形で３Ｄのゲームらしさを出している…と言ってもよいのですが、これが問題を起こします。
まず、カメラが自由に動かせなくなりました。
「カメラを動かしても目的物が見えない」場合も含みます。
ピクミン１でも、突発的に高さが変わる部分はありました。
しかし、そういう部分はマップ構成が工夫されていて、カメラアングルをあまり変える必要はありませんでした。
それに対し、３では、普段歩き回っているフィールド内で、結構な高低差があります。
この高低差により、カメラの動きが制限されます。
見やすい位置にもっていこうと思ってもカメラが動かせなかったり、動かせても別のものに見たいものが隠されてしまったり。
敵との戦いで緊迫しているときに「見えない」というのはかなり致命的ですが、頻繁に起こります。
（慣れれば、最初から戦いやすいアングルに固定できますが）
そして、一番の問題は「上からのアングルが無くなった」ことでしょう。
ピクミン１・２では正確な操作を要求されるところが多々あり、真上から見た視点が非常に役立ちました。
例えば、最も基本的な雑魚敵「コチャッピー」は、背中にピクミンを乗せると一撃で倒せます。
この位置はかなり正確に狙う必要があり、ピクミンを投げたときの着地点である「カーソル」の微調整が重要でした。
ピクミン３でも、コチャッピーは同じ方法で一撃で倒せます。
しかし、上から見られないので、正確な位置が把握できません。
一応、「ロックオン」という操作が追加されていて、カーソルを近くの対象物に固定できるのですが…
適当にロックオンされるだけで、コチャッピーを一撃で倒せる正確な位置にはカーソルを合わせてくれないのです。
（ピクミンの種類ごとに投げられた時の曲線が変わるため、一撃で倒すには、投げるピクミンごとに微調整が必要です。
しかし、ロックオンではそこまで考慮してくれません。）
結果として、真上から見ることの代わりになっていません。
高低差に話を戻します。
ピクミンを呼ぶ「笛」の有効範囲に、高低差の概念が加わっています。
１・２では、笛は呼び続けることで範囲が広がりました。
この時、「高さ」方向に関しては最初から全範囲でした。
３では、笛の呼べる範囲は、最初は高さ方向がほぼ０、平面です。
呼び続けると平面の範囲が広がり、最大まで広がったところで、やっと高さ方向にも広がります。
おそらく、ピクミン３の様々な「仕掛け」で、高低差が使われるものが多いためなのでしょう。
上と下で違う作業をしているときに、どちらかだけ呼ぶ、という操作をするためだと思われます。
でも、そういう操作は実はあまり使いません。
もっと使うのは、「敵との戦いの時に、振り払われて飛び散ったピクミンを呼ぶ」時です。
戦っている最中ですから、すぐに呼ばないと死んでしまいます、
でも、地形に高低差があると、「笛の範囲が十分に広がり、さらに高さ方向に広がる」まで、呼ばれないピクミンがいるのです。
高低差でもう一つ。
高いところに集める荷物が置かれている、というシーンが時々あります。
ピクミンは荷物を集めるゲームで、ターゲットにピクミンが到達すると「運ぶのに必要な人数」が表示されます。
ところが、高いところの荷物には、この人数が表示されません。
実際には表示されるのでしょうが、画面の上で見えなくなってしまい、表示が読めないのです。
まぁ、持ちうる限りの最大人数を投入すれば運んではくれるし、運んで落としてしまえば人数は見られます。
そして、一度人数を見たら「あそこは何人で運べる」と覚えておけばよいので、攻略には困りません。
これも、先に書いた「初プレイの時にイライラする」だけで、慣れれば問題のないものです。
…しかし、初プレイの時に嫌になる仕様が多いのは、問題だと思っています。
高低差のダメ押し。
とある地点でのパズルは、非常に高低差を活かしたものになっています。
そのため、斜め上から見下ろす視点では操作しづらい…と思ったのでしょう。
カメラがいきなり横からの視点に固定され、横スクロールゲームのような画面になります。
これが、普段とは操作感が違いすぎて、非常に操作しづらいのです。
急に今までと違う向きのカメラになって、結果としてジョイスティック操作も違う感覚になって、そこでパズルを解くための正確な操作を要求されます。
これ、やってみるとわかるのですが、急にルールの違う、別ゲームが始まったような感じです。
ものすごく違和感あります。
基本的に、ユーザーに断りなくルールを変えるのは、もっともやってはならないことだと思っています。
（メイドインワリオのように、次々ルールが切り替わることが楽しいゲームは、そのことも含めてルールになっているのでかまいません）
なんか悪口書いているみたいで生産的ではないのだけど、もう一つ大きなことを書かないといけません。
マップ構成のことです。
ピクミン１・２では、マップは基本的に、継ぎ目がありませんでした。
２では「地下」がありますが、１フロアごとに１枚のマップで、フロア間を自由に行き来するようなことはありません。
半面、ピクミンのマップは非常に「狭い」ものでした。
おそらく、３ではこれを解消すべく「広い」マップを作ろうとしたのでしょう…
断片的なマップがいくつもあり、その間を行き来して目的を達成する構成になっています。
この「マップの継ぎ目」が非常に不思議な、ねじれた空間になっているようです。
というのも、ピクミンが物を運ぶのについて継ぎ目に入ると、出口ではピクミンを追い抜いて出てくるのです。
ピクミンは継ぎ目の中を歩いているが、プレイヤーは継ぎ目の「入口」と「出口」の間をワープしている感じです。
そして、継ぎ目の中にいるピクミンは、異空間に入り込んでいます。
呼ぶことはできないし、日没近くの「このままでは死んでしまうピクミン」の人数カウントにも入っていません。
特に困るのが、荷物を持とうと頑張ったピクミンが、結局荷物が持てずに「諦めた」場合です。
最初の方で書いた通り、ピクミンは「互いの作業を邪魔」します。
荷物を運ぶ際も、運べる最大人数に達する前に「邪魔」によって諦める場合があります。
こうした、作業に着けなかったピクミンは、しばらく作業をしようと頑張った挙句、あきらめてその場で待機状態になります。
荷物を運ぶ場合「しばらく荷物について行った挙句、途中で待機状態となる」のです。
待機状態になったら、呼べばプレイヤーについてきます。
しかし、先に書いたように、継ぎ目の中で「待機」されると、呼ぶことができません。
「このままでは死んでしまう」というカウントにも入らないので安心していると、日没で死亡します。
これは明らかにゲームシステムの欠陥ですが、これも慣れてくれば「継ぎ目近くで荷物を運ぶピクミンを増やさない」という対処ができるようになります。
荷物を運ぶときは、人数によって速度が変わるので、攻略時には重要なのですが…
ここまでに書いたように、ピクミン３のシステムは、なんとなく遊ぶには悪くないのですが、攻略には向いていません。
自分の操作が悪いのであれば納得もするのですが、「運が悪い」としか言いようがない状況で失敗することが多すぎるので。
さて、以上が「システムに不備がある」という問題。
ここまで長々書いていますが、これでやっと言いたいことの半分くらいです。
ただ、ここから先は、個人的な このみ の問題で、ゲームシステムがおかしいとか、そういうことではありません。
ピクミン３は、攻略を「させない」方向に向けて舵を切っているように見受けられます。
というのも、ピクミン１・２に比べて、すべての荷物が少人数で運べるから。
１の時は、重くて大人数、かつ距離が遠くて時間がかかる…なんて荷物がいくつもありました。
これを運んでいる間、残りの少人数で効率よく敵を倒して回る、なんて攻略が普通でした。
これ、少人数でボスに挑むの、結構大変なんですよ。
攻略としては面白いのだけど、一部のマニアに向けての構造で、誰もが楽しめるものではない。
だから、今回は荷物は少人数で運べる。
先に書いたように、大人数の力押しで敵を殲滅して、その後分散して荷物を運んでおしまい、というような構成が多い。
何よりも、マップが広くなりました。
先に書いた継ぎ目問題はあるけど、広いマップを冒険することが目的のゲームで、小さなマップを緻密に攻略するゲームではなくなっている。
１・２のころに比べて、しっかりとしたストーリーらしい展開も多くなっていますし。
だから、ある程度効率を上げる「攻略」は楽しんでもいいけど、人数配分を１人単位で考えるような、緻密な攻略をする感じにはなっていない。
まぁ、それでもやりたい人はやればいいのだと思いますけど、先に書いた「バグ」が多発する問題で、攻略しようとすると非常に遊びづらいです。
ピクミン１は、今でこそ名作だと言われていますが、発売当時の評価は非常に低いものでした。
もう２０年も前のゲームなので、当時の状況覚えている人少ないかもしれないけど。
テレビＣＭは話題になりましたが、ゲームキューブが売れなかったこともあり、遊んだことある人は少ないんじゃないかな…
今回、ピクミン３デラックスを絶賛する記事を書いている人の中に、「ピクミンは初めて遊んだが、さすが人気シリーズだけはある」という論調が多いのが気になりました。
で、反論含みでこの日記を書いているわけですが。
「さすが」と捉えている方々にとっては、遊んだことがないけど人気のピクミンは、いつか遊びたい憧れのシリーズだったのでしょう。
でも、先に書いたように、３は１・２とは別物のゲームになっていると感じます。
その一方で、この方向転換は、商売としては当然だとも思います。
１の発売直後の評価は、「すぐに終わってしまう小粒なゲーム」でした。
終わった人が中古ソフト屋に売ったため、値崩れを起こして安く買えました。
つまりは、「クソゲー」扱いですね。
実際、すぐにエンディングを見られるゲームでした。
そして、すぐにエンディングまで行けるからこそ、「繰り返し遊んで欲しい」というメッセージが、エンディング後に隠されていました。
＃言葉として入っているわけではなく、「ハイスコア」の表記が出るのです。
これはつまり、繰り返し遊んでハイスコアを目指せ、という意味です。
マニアはこのメッセージを理解できましたが、マニアでない人には伝わりませんでした。
中古ソフト屋に売られたというのは「伝わらなかった人」が売ったのでしょうし、のちの評価が凄い高いのは、「伝わった人」がやり込んだためです。
これ、ゲームのとしての評価は高いのですが、商売としてはダメです。
中古で出回ったら、任天堂としての収入である「新品のソフト」が売れなくなっちゃいますから。
２では、ゲーム終了までのボリュームを増やしました。
半面、繰り返して遊ぶのは難しくなったため、やり込み要素は減った感じです。
そして、今回の３では、さらに本編のボリュームを増やしてやり込みを減らした、と思っています。
ピクミンの個性が希薄になったのも、食物連鎖を感じないほど敵が弱くなったのも、「マニアでない人向け」だと思えば、すべてが納得できる変更です。
しかし、ゲームとしていろいろおかしいのはすでに書いた通り。
根底部分のルールから変わってしまった３は、「ピクミンを真似して作られた、よくできたゲーム」にすぎないように思います。
関連ページ
別年同日の日記
申し訳ありませんが、現在意見投稿をできない状態にしています。 |
お仕事の話。ほぼ愚痴。
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 がマルチコアだったとしても、１コアしか使わないという意味でもある。
CPU のコアの数だけプロセスを増やせば、理論上はもっと多くの接続を処理できる。
もちろん、そのための制約はいろいろとあるのだが、最初から「マルチプロセスで動かすことができるように」という設計をしていた。
そして、pm2 という node.js 対応のプロセス管理ツールを使うと、プログラムは無改造のまま、マルチプロセス化できる。
（通常、プロセスが増えると、それぞれが別の通信ポートなどを用意しないといけなくなる。
通信ポートが増えれば、アクセスするクライアント側もそれに対応しなくてはならなくなる。
しかし、pm2 は代表して１つの通信ポートを作り、配下のプロセスのポートに適切にデータを流してくれるので、外部から見るとそれまでのプログラムと何ら変わらないように見える）
というわけで、処理性能は何倍かに跳ね上がった。
…でももちろん、話はそんなに単純ではなかった。
接続が増えたら、当たり前だがそれらの接続ごとに、データを収めた DB へのアクセスが発生する。
１プロセスで 1000 人程度をさばいているときには問題にならなかったが、１万人規模になると接続ができなくなった。
DB の接続数の上限設定があるのだ。これは、 DB の設定を書き換えて解消する。
これに伴い、適切なワークメモリの割り当てなども変える必要があるが、とにかく設定した。
DB が接続を受け付けられるようになっても、その接続のための通信ポートが十分作れない。
OS 側に、通信ポートをいくつ作れるか、という設定があるのだ。
それらも設定する必要がある。
UNIX では、すべてのリソースがファイルとして扱われる。
通信ポートも１種のファイルだ。そして、UNIX には、プロセスごとに開けるファイル数の制限がある。
この制限も増やす必要がある。
100 人程度なら問題なし、1000人でも大丈夫だったとしても、１万人規模になるとそれまで気にしていなかった設定が問題になるので、問題発生のたびに何が悪いのか調べ、設定をチューニングする必要が出る。
それまでは問題にならなかった DB の Query が、突如として slow query になる、というのもあった。
DB へのアクセスが激しすぎると、特に問題がなかった部分がボトルネックになりだすのだ。
…これらは、上に書いたような順序で、理路整然と起こったわけではない。
とにかく不具合が続出し、原因を切り分け、考えられる要素をひとつづつ潰していく必要があった。
上に書いたのは、「結果としてそういうことだった」というだけで、原因がわからないので見当違いの設定に手を出して、何も変わらないので元に戻す、というようなこともやっている。
問題はサーバー側だけではなかった。
１万人規模、と書いたが、その規模の人たちがサーバーに接続し、操作した結果を集計して表示する画面がある。
普通の WEB ページとして作られているので、PC さえあればインストール作業などなしで表示できる。
この画面自体は、サーバーと接続しているだけだ。接続が増えるようなことは無い。
だから特に問題は出ないだろうと思っていたら、１万人分…１人についてのデータが複数あるため、数万件のデータになると通信に支障が出た。
特に、何らかの不具合が起こって画面のリロード…と考えたとき、数万件のデータ再送信はそれだけで１分程度の時間がかかる。
通信したデータを、ローカルにキャッシュして持つように改良した。
再起動が行われた際は、まずキャッシュからデータを読み込み、続きのデータの送信をサーバーに依頼する。
５秒程度で表示が行えるようになった。
この表示も１万件あると遅くなった。
全部を表示したいのだが、ただ１万行の HTML というだけで、重くてスクロールもままならないのだ。
これはプログラムテクニックで乗り切った。
どこかに詳細なテクニック紹介をしたいのだけど、忙しくて概要説明だけ行ったままだ。
100人を想定して作ったものを、１万人向けに提供する…となると、思わぬことがいろいろと発生する。
別年同日の日記
16年 iOSでtextのコピー・ペーストができないバグの回避
申し訳ありませんが、現在意見投稿をできない状態にしています。 |
昨年８月に購入したノートパソコンが壊れた。
壊れたといっても、起動はできるし普通に使える。
ペンコンピューティング可能なマシンだが、ペンも使える。
でも、指で直接ディスプレイにタッチした際の操作が効かなくなった。
それ以外の症状はない。
最初は、ペンは使えるがタッチは使えない、というので、タッチパネル自体は壊れてないんだよね？
と思ってドライバ不具合などを疑った。
調べると、Windows アップデートなどでドライバが不具合を起こすことがある、という情報があったし、うまく動かなくなった直前に Windows のアップデートを行っていた。
じゃぁこれかな、と思って、メーカーのページに書かれていたトラブルシューティングの方法に従ってドライバを入れなおす。でも治らず。
さらにネットの情報を探す。
我が家の機種とは違うが、同じシリーズの以前の機種で、同様の問題を発見。
タッチディスプレイのケーブルが内部基板から外れやすくて、ペンは使えるのにタッチのみ使えなくなりやすい、という。
後継機で前の機種のトラブルが対応されていないことは無いと思うのだけど、症状的に似通っている。
ケーブルが外れているだけなら自分で治せるかもしれないけど、保証期間内だったので素直に修理に出すことにした。
まず、メーカーのページで修理申込する。
不具合のある機種を使って申し込みをすると、自動的に機種を判別し、保証期間内であることが示される。
そして、自己診断プログラムのダウンロードを促される。
このプログラムを入れると、自動的に自己診断が始まり、その情報とともに修理申込ができる。
その際、マシンのシリアルナンバーなども自動判別される。
我が家の機械の場合、故障個所はない、という診断だったが、申し込みはできた。
自己診断の限界もあるのだろう。
住所氏名や電話番号などの連絡情報を入れたのち、不具合について記入。
タッチパネルが反応しないがペンは動くこと、公式の方法でドライバの入れ直しも試みたことなど書く。
で、翌日にはメールで返事が来た。ハードウェア故障の可能性が高いので引き取り修理をするという。
引き取り日の希望などを返信するが、最短で翌日。で、翌日には佐川急便が引き取りに来たので本体を渡す。
梱包などは佐川の方でやってくれる。
当日のうちに到着連絡が来たが、この日が金曜日だったため、週末の間は修理は進まなかった。
そして、昨日月曜日に修理完了の連絡があり、今日には手元に戻ってきた。
一応、メーカーのページには「到着から１週間から１０日で修理完了します」とあったし、さらに「コロナ禍で修理依頼が増えており、少し時間がかかるかもしれません」とお詫びがあった。
しかし、メーカー到着の次の営業日には修理を行い、翌日こちらに届くというスピード修理。
まぁ、本当にハードウェア的な故障で、部品交換で済んだからすぐ終わったのだろうけど。
ソフトウェアのコンフリクトなどを「不具合」として修理に出す人もいるみたいだし、そういう問題はすぐには解決できない。
別年同日の日記
14年 iOS の position:fixed バグ回避方法
申し訳ありませんが、現在意見投稿をできない状態にしています。 |
このタイトル、すでに分からない人の方が多そうだな。
急に思い出話。
まだ僕が大学１年生だったころのこと。
PCルームがあって、放課後は入り浸っていた。
その場にいる人の多くは、僕も所属していたコンピューターサークルのメンバー。
でも、そうではない常連の人もいて、学科もサークルも違うのに知人、という人もいた。
そのうちの一人…同じく１年生で、簡単なプログラムは組めるが本格的なゲームなどは作れない、というくらいの知人が、ゲームによくある、ジャンプの動きを作ろうと頑張っていた。
その知人は「ジャンプは放物線なのだから」と、何かの二乗を使って書こうとしてたんだ。
（二乗のグラフとして描かれる線を、放物線と呼ぶ）
でも、そうじゃない。ゲームならジャンプは次のように書く。
（当時は 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 | 9 | 16 | 25 | 36 | 49 | 64 | 81 |
| 1 | 3 | 5 | 7 | 9 | 11 | 13 | 15 | 17 | 19 |
この表のルールはこうだ。
・上に書かれた数値は、その左側の列の上下の数値を足したもの。
・下に書かれた数値は、その左側の列の下の数値に、2を足したもの。
足し算しか使っていない、非常に単純なルールだ。
おかしいところがないか検算してもらってもよい。
ここで、上の数値は、もう一つの意味を持つ。
0,1,2…と続く数値の「二乗」になっているのだ。
日本人なら 9*9=81 まではわかるだろうから、上の表は 81 で止めてある。
でも、もっと長く続けても大丈夫。これも試してもらってよい。
「ずる」と言われたのが悔しくて、根拠を考えていたら、数日後にはこの答えに行きついた。
でも、サークルも違うし学科も違ったので会う機会はそれほどなく、言い返すタイミングは永久に失われた。
それを思い出して急にここに書いたのは、ネットで「微分積分なんて実生活でどう役に立つのか」なんていう…まぁ、よくありがちな学生の愚痴を見たから。
微分積分、生活で超役立つ。
上に書いたように、テレビゲームは微分積分の世界の中にある。
そもそもテレビが微分積分の世界だし、デジタルテレビなんかフーリエ変換（微分積分の親玉みたいなやつ）を駆使して作られている。
ただし、役立てられるかどうかは、自分次第。
ゲームやテレビの中に微分積分が駆使されている、なんていうのは知らない人は全く気付かない世界だ。
それでも生活はできるのだから、知らずに生活している限りは、高校で習った微分積分は「役立てられていない」。
役に立たないのではなく、役立てられないのだ。
なんでかといえば、勉強が浅かったから。「どうせ役立たない」なんて思ってるから。
世界最初のコンピューター、と呼ばれる ENIAC は、実のところ「ひたすら足し算する機械」にすぎない。
それでも、数学的に正しい…どころか、空気抵抗なども考慮した「弾道計算」ができた。
先に書いたように、足し算だけで数学的に正しい放物線は求まる。
しかし、それは空気抵抗や風などがない理想状態での弾道にすぎない。
ENIAC では時間で「微分」した方程式を使い、繰り返し計算して「積分」することで、弾の速度の関数となる空気抵抗や、風の影響なども考慮に入れ、物理現象としての「弾道」を描き出すことができた。
空気抵抗が弾の速度の関数になる、なんていうのは、瞬間ごとの速度を見ながら抵抗を導き、それによって速度を調整する、というのを繰り返しながら積分する方法でないと計算できない。
そうした計算が複雑すぎて人の手に負えないから、ENIAC を建造したわけだけど。
ともかく、ここで重要なのは、どんなに複雑な数式であっても、微分を繰り返せばただの足し算になるということだ。
そして、足し算をひたすら繰り返せば、元の複雑な数式の答えを導き出せる。
（ここでいう答えとは数値演算であり、式の変形ではない）
ENIAC は弾道計算よりももっと複雑な、水爆の内部圧力の計算なども行っている。
使われた計算は全部足し算のみだ。それが微分積分の威力だ。
今回、この話を書こうと思ってネットを調べていたら、以下のようなことを書いている人がいた。
（一連のツイートだが、特定人物を批判したいわけではないため、検索されないよう文面は変えている。）
・ファミコンで三角関数を使うと遅くなるので、スーパーマリオのジャンプは掛け算だけで作られている。
・掛け算だけなので本当は放物線ではないのだが、ゲームを作るうえでのうまいごまかし方だと言える
…まぁ、プログラマーでない人がうろ覚えの知識を披露しただけだと思う。
しかし、どこから突っ込んでよいかわからないほど違っている。
まず、ジャンプを表現する放物線に、三角関数は必要ない。掛け算だけでよい。
そして、ファミコンは掛け算すら遅いので、足し算だけで作られている。
さらにいえば、先に書いたように足し算だけで書いてもごまかしではなく、数学的に正しい放物線が描ける。
ただ、スーパーマリオのジャンプは、放物線ですらない。
放物線にすると、操作が難しくてゲームにならないから。
それでも放物線っぽく感じられるようにしている。
これが「うまいごまかし方」だというのは同意だが、計算できなかったからではなく、ゲームを面白くするためだ。
背景が全く違う。
同じテーマの日記(最近の一覧)
関連ページ
別年同日の日記
申し訳ありませんが、現在意見投稿をできない状態にしています。 |
昨年８月に、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 追記
１週間ほど使ったところで使用記書きました。
素晴らしい機械でした。
関連ページ
IdeaPad Duet の使い勝手(1/2)【日記 21/03/01】
別年同日の日記
申し訳ありませんが、現在意見投稿をできない状態にしています。 |
Lenovo Ideapad Duet を購入して１週間ほどたつ。
まだ１週間しか使っていない、というべきかもしれないが、ここらへんで一度評価をまとめておこう。
冒頭でいきなり評価を書いてしまえば、非常に素晴らしい端末だ。
購入前は、普通と少し違うこの端末を買うことに不安があった。
しかし、予想を遥かに超えた素晴らしさだった。不安は杞憂だった。
どう素晴らしいかといえば、これが見事に既存の機械の「隙間」を埋めるものだったのだ。
でも、隙間を埋める充填剤だ。広い面積をカバーできるパネルではない。
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 というのは、ハイビジョンの動画を視聴するのに必要なドット数だ。
画面の物理的な大きさはほぼ変わらないまま、およそ３倍のドット数を表示できるようになった。
じゃぁ、表示できる情報が増えたのかというと、なっていない。
Android や iOS が、表示できる文字数が大きく変わらないように制御しているためだ。
タブレットになると画面が大きくなるため、表示できる文字数は増える。
でも、文字を大きめに表示する、という基本は変わっていない。
これに対し、パソコンはより多くの情報を表示できるように発展してきた。
画面が広くなると表示できる文字の量が増える。解像度が上がると表示できる文字の量が増える。
ノートパソコンで画面が小さい、などの理由であえて文字を大きくすることはあるのだけど、その場合も拡大率の決定はユーザーに委ねられている。
パソコンとスマホでは、情報表示に対する考えが根底から違うのだ。
そして、Chrome OS はパソコン用のOSだ。拡大率は自分で変えられる。
この拡大率は、Chrome OS 上で動く Android アプリでもそのまま適用される。
だから、Android アプリをフルハイビジョンで表示できたりする。
まぁ、スマホの小さな画面で使うように設計されたソフトをフルハイビジョンで使う意味はない。
でも、一度見てみると非常にインパクトがある。Chrome OS なら、Android タブレットでは見られない世界を見られるのだ。
もっとも、Duet を使っている限りでは、字が小さすぎて実用にならないので、フルハイビジョンで使うのはお勧めしない。
オススメしないのは「Duetの場合」であって、「Android アプリに広い画面が不要」だと言っているのではない。
Chrome OS では、Android アプリもウィンドウ内で動くようにできる。
ウィンドウをいくつも並べることもできるし、ウィンドウをリサイズすればそれに合わせた表示になる。
（Android アプリは、様々な画面サイズの端末に対応しているし、使用中の画面リサイズである「画面の回転」などにも対応している。）
だから、広い画面で情報がたくさん表示できることには意味がある。
Duet は画面が小さいのでこの機能を活かしきれないかもしれないが、Chrome OS 上で Android アプリが動く、ということは、今までになかった新しい世界を開くのだ。
わかりやすい例を２つ挙げたが、他にも細かな違いは色々ある。
多くは、スマホと PC という、違う目的で発展してきた OS の違いに起因するものだ。
もちろん、Android にしかできない、ということも多い。
実際、Chrome OS のほうが機能的には貧弱だとも言える。
だからこそ、最初に「隙間を埋める充填剤」だと書いたのだ。
Windows でしかできないことがあり、Android でしかできないことがある。
そして、その隙間の、どちらにもできないことを、Chrome OS が埋める。
同じ 10inch タブレットであっても、Android タブレットでは隙間を埋められない。
Android タブレットでは、Android にできないことはできないのだ。
Duet が素晴らしい、ということをざっくりと書いたが、細かな話はまだある。
ただ、細かな話になりすぎて、本当に興味がある人でないと面白くないと思う。
なので、ここでいったん記事を区切ろう。
関連ページ
Lenovo Ideapad Duet 購入【日記 21/02/23】
IdeaPad Duet の使い勝手(2/2)【日記 21/03/01】
IdeaPad Duet の使い勝手(1/2)【日記 21/03/01】
別年同日の日記
申し訳ありませんが、現在意見投稿をできない状態にしています。 |
さて、前の記事では 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 版にはない、拡大表示操作が可能になる。
これ、表示倍率を変える「ズーム」機能とは違うものだ。２本指によるピンチ操作で自由な倍率で拡大できる。
拡大しているときでも、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 と同じように全画面表示が基本となる。
実は、画面分割して２つのアプリを同時に表示することはできる。
これは、Android 7 相当の機能だね。
また、アプリが対応しているならば、ピクチャー・イン・ピクチャー表示にもできる。
これは Android 8 相当の機能だ。
しかしまぁ、全画面表示が基本だ。ここらへん、Android のスマホやタブレットと変わらない。
しかし、一つ困ったことがある。
Android アプリの操作に、Android の OS が用意する、画面下部の３つボタン…「戻る」「ホーム」「タスク」は必須だ。
しかし、Chrome OS にはこの３つボタンがないのだ。
もちろん、操作方法は用意されている。しかし、使い慣れた方法ではない、というだけで、最初は戸惑うことになる。
まず、「戻る」の操作は、画面左端から右に向かってスワイプだ。
すると、左矢印のアイコンが現れる。引っ張るとだんだん色が付き、十分引っ張ったところで色が反転する。
この状態で指を離すと「戻る」動作が行われる。
ちなみに、この操作は Chrome でも使える。Chrome は URL バーの左側に戻るボタンがあるけど、Android と同じ操作も使えるので、わざわざ操作を使い分ける必要はない。
次に、「ホーム」と「タスク」だけど、途中まで操作が共通している。
画面下から上に向かってスワイプすると、中央あたりで画面が全体に縮小される。
このまま上に向かって指をはらうと、画面は飛んでいってホーム画面が現れる。
中央あたりで指を止めて一瞬待つと、現在動いている他のアプリも縮小画面で現れ、タスクリストが表示される。
ちなみに、どちらも「中央辺りまでスワイプ」が必要で、それより短い距離だと別の動作になる。
後で書くが、アプリ起動を行うためのシェルフの表示だ。
初期の頃から、Chrome OS では画面下部にシェルフを表示していたので、これは仕方のない操作だと思う。
でも、距離によって違う意味になるというのは、慣れればともかく初心者には非常に分かりづらい。
画面下から短いスワイプというのは、Android では「隠れている３つボタンを表示」だ。
慣れる前は、ついこの操作を多用して、シェルフが表示されてがっかりした。
「シェルフと一緒に、Android で慣れた３つボタンを表示」なんて機能が将来のアップデートで付けばよいのに、と思う。
▼アプリの起動方法
上に書いた「シェルフ」について説明しようと思うのだが、便宜的に一緒に４つの概念を紹介する。
デスクトップ、ランチャー、ホーム画面、そしてシェルフだ。
まず、デスクトップ。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 が１つしかない。イヤホンジャックすらついていない。
ただ、標準で 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 速度は上がっているにもかかわらず。
といっても、８秒程度。Android や Windows に比べると、ずっと起動が速い。
まぁ、実際に使っていると起動することはほとんどない。
普段はスリープしておく。これだと、復帰までは１秒かからない。
ここからは少し内部の話になるが、「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 と違って待受がないことで、僕の使い方では１つだけ不便になったことがある。
先に書いたように、僕は家事の際に 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 で仕上げた。
そういう使い分けがやりやすい、というのもポイントの一つだ）
関連ページ
Lenovo Ideapad Duet 購入【日記 21/02/23】
IdeaPad Duet の使い勝手(2/2)【日記 21/03/01】
IdeaPad Duet の使い勝手(1/2)【日記 21/03/01】
別年同日の日記
申し訳ありませんが、現在意見投稿をできない状態にしています。 |
少し前の日記で、微分積分は役立つよー と書いたのだけど、話の腰を折るのであまり具体例に踏み込まなかった。
これ、自分の中で気になっていて、もう少し説明したいと思っていた。
僕はプログラマーなので、これから書くのはコンピュータープログラムとしての微分積分の話だ。
そして、プログラムとしての微分積分というのは、高校で習ったアレは何だったのかと気が抜けるほど簡単だ。
まぁ、高校で習ったことはちゃんと意味があるので、そのフォローは最後にやる。
▼積分の概念
というわけで、微分積分の「考え方」から説明しよう。
微分積分、と言っているとややこしいので、まずは積分に話を絞る。
前提知識として、足し算は理解しているものとする。
足し算がわからない人には、さすがに説明ができない。
では、[ 3, 3, 3, 3 ] …3 が４つあるのだけど、全部足してみて欲しい。
答えは 12 だ。3 + 3 + 3 + 3 でいいのだけど、3 × 4 と考えるとすぐに答えが出る。
次に、[ 3, 4, 5, 6 ] を全部足してみて欲しい。
今度は掛け算は使えないので、地道に足し算をするしかない。
3 + 4 + 5 + 6 で、答えは 18だ。
概念的には、後者が積分にあたる。
たくさんの数をまとめて足す方法が積分。
そのうち、数が「たまたま全部同じだった」という特殊な場合が掛け算だ。
ここに書いた例では、４つの数を足しただけだった。
これが、数万という数があると考えて欲しい。とても手計算で足し合わせることはできない。
でも、それらの数に何らかの法則があって、数式で表せたとしよう。
こうなると話が変わってくる。足したい数の概要を数式として示せたので、これをもとに「全部足した結果」の数式を作り出す。
すると、数万件の足し算をする必要がなくなり、すぐに答えが出る。
これが、高校で習う積分だ。
ただ、数式で表すとなると、整数だけが相手というわけにはいかない。
式を変形するための前提条件などもいろいろと付き、話が複雑になっていく。
結果として「難しい」と思われてしまうのだけど、やりたいことは「全部足す」なのだ。
さて、そこでコンピューターが開発された。
最初は、「ひたすら足し算」しかできない機械だった。
でも、足し算さえできれば積分計算ができる。それで十分だ。
今のコンピューターもその延長上にあるので、プログラムのいたる所に積分が顔を出す。
多分、多くのプログラマーが、積分だとも思わないまま使っているのだけど。
▼積分の具体例
具体例をあげよう。
最近の家庭用テレビゲーム機では、コントローラーを振って操作することができる。
３Ｄのゲームで、コントローラーを左右にふることで、左右を見ることができたりね。
これ、コントローラーには「向き」を知るための仕組みは入っていない。
入っているのは、加速度センサーだ。
加速度、というのが馴染みが薄いかもしれないのだけど、単純に力のことだ。
加速度センサーは、コントローラーにかかる力を知ることができる。
そして、速度に加える、という名前の通り、足し算を続けると…つまり、ここまでに説明したように「積分」すると、現在の速度が得られる。
さらに、速度を積分すると、今度は現在の位置が得られる。
自分の体を中心としたコントローラーの位置と考えると、「向き」と近似のものだ。
こうして、加速度センサーから得られる値を、2回積分することで、コントローラーからは直接得られない「向き」を算出しているんだ。
積分を行うと、値のもつ「意味」を変えることができる。
ここでは、加速度を速度に、速度を位置に、変えることができた。
長さを面積に、更に体積に変えることもできる。
掛け算でも同じだけど、先に書いたように、掛け算は積分の特殊な場合だから。
プログラムしていて、欲しい値が手に入らない、ということはよくある。
そうした場合でも、手元にある値を積分することで、欲しい値を作り出す事ができる。
プログラマーなら、こうしたプログラムの経験はいくらでもあるだろう。
積分というのは特別なことではなく、ごく当たり前に使われるものなのだ。
また別の例を上げる。
積分を使うと、複雑なものを単純化できる。
物を投げたときの位置は、それほど難しくない数式で示すことができる。
いわゆる放物線だ。
まぁ、人がボールを投げるくらいなら放物線の式で問題ない。
でも、高速で動く場合は空気抵抗が問題になり始める。
そこまで考慮して位置を示す式を作ろうとしても、複雑すぎて作ることができない。
そこで積分を使う。
いきなり位置を表す式を作るのではなく、まず速度の式を作るのだ。
空気抵抗は速度によって変わるので、速度をもとに空気抵抗を求め、その空気抵抗で速度が変わるようにする。
そして、その速度を積分して位置を求める。
ここで言う積分は、もちろんコンピューターの計算力で足し算を繰り返すことだ。
このように、複数の段階に分けることで、複雑すぎて手に負えない計算も行うことができる。
こちらも、プログラマーにとってはそれほど特別なことではないね。
ゲームを作る人なら、いろいろな条件で途中から動きが変わったりする、つまり「加速度」を持つプログラムは当たり前に組むだろう。
▼微分
積分の話を2つほど挙げたが、続いて微分のことを書こう。
微分は積分の逆の操作だ、と思ってだいたい間違いはない。
微分して積分したらもとに戻る。
積分がすべて足すのに対して、微分は直近の値を引く。
これによって、直近から値がどのように変わったのか、その「差」を調べることができる。
積分例として、ゲームコントローラーの話を書いた。
コントローラーには加速度センサーしか入っていないが、積分すれば位置がわかる。
逆の話として、スマホのタッチパネルのことを書こう。
タッチパネルに指を触れると、その位置がわかる。でも、位置以外はわからない。
しかし、タッチパネル操作でスクロールを行うとき、「フリック」すると、その時の速度でスクロールが続く。
ここでは、指の位置情報を微分することで、速度を求めているんだ。
フリックとは、指を動かしている最中に、急にタッチパネルから離す動作。
指が離れた直前の速度がある程度あった場合、そのままスクロールを続けるようにする。
そして、徐々にスクロールが止まるのは、速度を変化させる、逆向きの加速度を設定している。
これらの動作は、積分を行っている。
微分すると、変化がわかる。
これを多用しているのが、写真などの加工アプリだ。
ある点に注目したときに、すぐ隣の点との差を出す。
これを画像のすべての点について行い、その結果を新たな画像とする。
これが「画像を微分する」ということなのだけど、この結果得られるのは、色の変化するところを拾い出したような画像だ。
いわゆる「輪郭抽出フィルタ」だと思っていい。表示の方法によっては、レリーフ化フィルタになる。
この輪郭に対してもう一度微分すると、輪郭のすぐ隣の点を際立たせるデータが得られる。
これを元の画像に重ねると、輪郭がくっきりとする。
「シャープフィルタ」とか「ピンぼけ補正フィルタ」と呼ばれるものだ。
ここに書いたのは単純な原理だけで、実際の画像処理ではもっと工夫された処理が使われている。
しかし、微分の応用範囲の広さはわかってもらえると思う。
▼微分積分とは
これ以上書いても同じような話ばかりになりそうなので、少し話を変えよう。
微分積分というのは難しいものだ、と思っている人は多そうだ。
でも、コンピューターで計算するときは、ただの足し算引き算だ。
特に難しい処理ではない。
じゃぁ、なんで高校ではあんなにややこしい教え方するのさ、という話。
これにはもちろん意味がある。
微分積分学は19世紀に大きく発展したのだけど、コンピューターの登場は 20世紀なのだ。
だから、学問としてはコンピューターのほうが新しく、難しい。
高校でやるのは積分の「基礎」で、コンピューターを使うのは「応用」なのだ。
今回書いた話も、概念としては「微分積分」なのだけど、数学的な妥当性はちょっと怪しい。
わざと簡単な話だけやっていて、ややこしい話は避けたからね。
真面目に書こうとすると、高校レベルの数学では収まらない話になる。
でも、今回僕が示したかったのは、数学的な妥当性ではない。
難しいと思って避けている人が多い「微分積分」が、案外身近に使われているし、考え方自体は簡単なものだと知ってほしかったのだ。
▼最後に
微分積分の話、もっと書きたいことはたくさんある。
でも、何でもかんでも盛り込むと話が横道にそれ過ぎて、わかりづらくなる。
今回も、これでも泣く泣く削った話が多数あるのだ。
諦めきれないネタを２つ、概要だけ示す。
説明は長くなるからしない。書きたいから書きっぱなしにする、というだけ。
・太陽の位置と季節の話
12月の冬至と6月の夏至が「昼と夜の長さ」のピークなのに、寒さと暑さのピークは2月と8月だ。
なんでピークがずれるのか気になったことはないだろうか？
太陽の運動を正弦波、太陽エネルギーを気温に変えるのに積分が必要だと考えると、大体理解できる。
・フーリエ変換
異世界転移の魔法。
ネイピア数を虚数乗することで複素空間に円形の魔法陣を描き、そこに波動をぶつけて積分すると「周波数空間」という異世界に転移できる。
もちろん、異世界に行ったら無双できるのがお約束。
…と、与太話を書いてから真面目に解説したかったのだけど、そもそもこの与太話がフーリエ変換を理解していないとわからないし、解説もすげー長くなるからやめた。
同じテーマの日記(最近の一覧)
関連ページ
別年同日の日記
17年 タネンバウム教授(1944) ストールマン(1953) 誕生日
申し訳ありませんが、現在意見投稿をできない状態にしています。 |
長男が「遊びたい」と急に言い出してから、居間のテレビに Wii がつながっている。
で、長男はゲームキューブのゲームをいろいろと遊んでいる。
Wii が「家族で遊べるゲーム機」という方向を打ち出して以降、ゲーム人口は増えた。
また、スマホで遊べるゲームが増えたこともゲーム人口増加の一因ではあるだろう。
そして、結果として昨今のゲームは「誰でも遊べる」難易度にされていることが多い。
長男としてはこれが面白くないようで、「昔のゲームの方が面白い」と、GC のゲームばかり遊んでいるのだ。
（Switch も、リングフィットアドベンチャーは熱心に遊んでいたりする）
さて、久しぶりに出した機械なのにヘビーユースしていたら、数日前から調子が悪くなった。
時々、ディスクが読み込みエラーを起こすのだ。
もう古い機械だからね、といいつつ、Switch を買ってしまいこむ直前には、スマブラ X も遊べない状態になっていたのを思い出す。
家にあるゲームの中では、スマブラ X だけが２層ディスクで、まだ Wii が（我が家的に）現役稼働していた時から読み込めなくなっていた。
中古屋に行けば、Wii 本体は 500円もあれば買える。
しかし、ディスク駆動部分は最も経年劣化しやすい部分でもあり、中古で買っても問題の解決にならない気がする。
たしか、Wii ってもう修理終わってるよな、と思って調べると、１年ちょっと前に終わっていた。
となると、どうせ壊れかかっているのだし、ダメ元で自力修理か…
と、ネットで修理方法を探してみる。
その結果、修理というほど大げさなものではないことが分かった。
ディスクが読めない、特に２層ディスクだけ読めない、という症状は、ピックアップレンズが汚れているだけらしい。
Wii の規格は少し特殊ではあるが、CD や DVD といった光学ディスクは、レーザー光線を表面に当て、その反射光をレンズで集めて情報を読み取っている。
そのため、このレンズが汚れると十分な情報読み取りができなくなる。
じゃぁ、拭いてやればよい。
初代プレステなんかは、ディスクを自分でセットした。
このセットするすぐ下に、ピックアップレンズが見えていたので、綿棒で拭くことができた。
しかし、Wii はフロントローディング…ディスクを細い隙間から入れると、あとは機械が正しい位置にセットしてくれる方式だ。レンズは見えない位置にある。
そのため、拭くには専用のツールが必要となる。
任天堂純正で、Wii のレンズクリーニングキットが売られていたらしい。
しかし、これも当然現在は廃盤。Amazon でプレミア価格になっているのを見つけたが、買うのは現実的でない。
普通の CD 用クリーニングディスクじゃダメなのかな、と思って調べたが、多くの人が「純正品以外は保証されていないから、本体を壊したくなければ純正品を使え」と言っている。
でも、こうした情報の多くは、純正品が手に入ったころに書かれたテキストだ。
Amazon で代わりになるものはないか探していたら、CD 用のレンズクリーニングキットで Wii が治った、と報告している人がいた。
あ、やっぱ治るんだ。
Wii は CD を入れると「ゲームディスクではない」とすぐに輩出してしまうらしいのだけど、根気よく何度も入れていると時々読み込もうとするので、その時をまて、とのこと。
この「治せた」報告のあるクリーニングキット、1600円だった。うん、買うか。ポチるか。
…というところで思い出した。
そういえば、うちに CD のレンズクリーナーなかったっけ。
自分の持ち物ではないので忘れていたが、妻が持っていたはず。
知り合う前に購入していたもので、もう 30年以上前のものだ。しかし、ちゃんと置いてあった。
付属していたはずのクリーニングリキッドはなかったのだけど、FDD 用のリキッドがあった。
まぁ、基本同じものだ。それを使う。
妻、物持ちいいな。（僕も人のこと言えないのだけど）
CD のレンズクリーニングディスクというのは、普通の CD の最内周に、ふき取りのための不織布をつけたものだ。
その不織布に、リキッド（当時のものは液化フロン。すぐに蒸発するため、機械内部を濡らしたりしない）を染み込ませて、読み込ませる。
CD の場合、最内周には音楽がどこから始まるか、などの情報などがあり、最初に読み込もうとする。
ここに不織布があるので、レンズが拭かれるわけだ。
不織布の部分を避けるように、ちゃんとデータは書き込まれている。
そこで、CD プレイヤーはそのデータに従って、１曲目の再生にかかる。
これは不織布のない部分に音楽データがあるように示されており、そこを再生する。
で、音楽データが流れる。「クリーニングが終わりました」という音声だけど。
レンズクリーナーというのは、そういう仕組みだ。
Wii に入れてみる。CD プレイヤーではないので、当然音楽データは流れない。
というか、入れると読み込もうともせずに、すぐに排出される。
データも読み込まずに、いったい何で「ゲームディスクではない」と判断しているのかわからない。
しかし、根気よく入れ続けろ、とアドバイスにあったのでやってみる。
たしかに、何回かに１回読み込む。
がんばって２～３回読み込ませ、クリーニングできたものだと考える。
さて、次はこれでレンズがきれいになったことを確認しなくてはならない。
子供が遊んでいた GC のゲームでは、「時々読み込みエラーが起きる」だったのだが、そんな時々を待っていたら検証にならない。
そこで、スマブラ X を探してきて、入れてみる。以前は読み込んでもくれなかったものだ。
緊張して少し待つ…と、スマブラ X のタイトルが表示された。
これで、クリーニングできて修理完了、と判断。
長男は「面白そう。遊んでいい？」とそのままスマブラ X を遊び始めた。
Wii で読み込めなくなった時、当時小学生だった長男は残念がっていたんだよね。
スマブラ X 、下手だったけど好きでよく遊んでいたから。
最近は、Switch 版のスマブラが学校で流行していたそうで、家でも練習していた。
だから、久しぶりに遊んだら十分の上手い。まぁ、夜遅かったので少し遊んで終わりにしていたけど。
同じテーマの日記(最近の一覧)
別年同日の日記
申し訳ありませんが、現在意見投稿をできない状態にしています。 |
先日、Amazon が Primeday sale をやっていた。
何か面白いものあるかな、と思って探したが、特に欲しいものはない。
安けりゃ何でも買う、という行動には走らない。
でも、そういえばイヤホン欲しいのだった、と思って探す。
セールの対象商品ではなかったのだが、購入した。
たびたび書いているが、台所仕事…皿洗ったり、料理作ったりしているときは結構孤独なので、Amazon Primevide でなんか見てる。
この時、Bluetooth イヤホンを使っているのだが、ずっと使っていたものが、先日調子が悪くなってしまったのだ。
左右繋がった旧型の（？）イヤホン。
この左側だけ、ノイズが載るようになってしまった。まぁ、内部でなんか接触不良になったようなのだ。
これが２か月くらい前の話だったかな。
実は、半年くらい前にもらって使っていなかった Bluetooth イヤホンがあった。
長女が塾通いを始めたので、連絡用に安いスマホを購入したのだが、スマホと同じメーカーの、左右分離型イヤホンとセットで安かったのだ。
セットで安い、というのが「別々に買うより安い」ではなく、「スマホ単体より安い」だった。
なんでそんなことになっているのか知らないが、それを購入した。
ただし、イヤホンは「試供品」であり、補償対象外だよ、と明記されていた。
以前使っていたイヤホンが調子悪くなったので、思い出してこの左右分離型イヤホンを使い始めた。
まぁ、使い勝手は悪くない。ケースに置いただけで充電される、というもの気軽でいいね。
…でも、これが２か月も使わないうちに片側故障して電源が入らなくなったのだ。
このイヤホンの評判を調べると、「すぐ壊れる」と非常に評判が悪かった。
なるほど。試供品で保証対象外、と書いてばらまいているわけだ。
多分。これを仕入れて販売していた業者は、クレームの多さに嫌気がさして損切りしたのだろう。
どこのメーカーかは特に書かない。
商品の悪口を書きたいわけではないから。
購入した新しいイヤホンのことを書こう。
こちらも安物で、あえて以前使っていたものに近いものを探した。
左右がワイヤーでつながっているものだ。
首の後ろにワイヤーをかける形で使う。
このタイプは、ワイヤーが音声信号を伝えるのは当然だが、アンテナを兼ねている。
なので、左右分離型のワイヤレスよりも電波を拾いやすいようだ。
といっても、ワイヤレスでも普通に使っていれば問題は出ないと思う。
僕の場合、台所で料理をしながら使っているため、電子レンズのノイズが載るという、劣悪な環境で聞くことになる。
これが、ワイヤレスだと全然ダメだった。
すぐに音飛びしてしまう上に、片耳だけしか聞こえないことも多い。
（Bluetooth 規格では、同じ信号を複数のデバイスで同時受信することは、今のところ考えていない。
左右のイヤホンが分離しているときに、片側が Bluetooth でデータを受け取ったら、もう片側に別途通信する必要があるのだ。
このため、電波ノイズが激しい状態では、片耳しか聞こえない、というようなことになる）
現在の流行はワイヤレスのようで、あえてワイヤーでつながったタイプは数が少ない。
でも、そんな中で安いものを適当に見繕って購入。
昨日届いて、まだ数回しか使っていないが、今のところ調子は良い。
使わないときは左右のイヤホン部分が磁石でくっつく仕組みになっていて、ビデオを見ている最中でも、くっつけると一時停止になる。
タブレットの電源を切ってから磁石をつけると、電源 OFF になる。
そして、磁石を離すと、電源が ON になったり、一時停止が解除されたりする。
以前のものは、操作部分がワイヤーの右側途中にあった。
僕は気にならなかったのだが、この形だと片側だけ重いため、ランニング中に音楽を聴いていたりすると、右側イヤホンだけ引っ張られてバランスを崩し、耳から外れやすいそうだ。
そこで、ワイヤーの中央付近が太くなっていて、首の後ろに回したときにしっかり肩に載るようになっている。
さらに、左側にも操作部分と同じあたりに同程度の重さの「なにか」がついていて、左右バランスが悪くならないようになっている。
…なにか、と書いたのは、特にボタンなどはないため。
内部にはバッテリーが入っていて、操作部分に入ったバッテリーと合わせて、長時間使用できるようになっているようだけど。
とりあえず、使い勝手は悪くない。
後は簡単に壊れないことを祈るのみ。
Primeday sale 中には、もう一つ思い出して（セール対象品でもないのに）買ったものがあるのだけど、こちらはまだ届いていない。
後日書こうと思う。
別年同日の日記
申し訳ありませんが、現在意見投稿をできない状態にしています。 |
しばらく前に「もう一つ買ったものがあるので、後日書こうと思う」なんて予告しておいて、なかなか書けなかった。
購入したのは、新しい NAS 。QNAP TS-251D。
ある程度設定が終わったらレポートを兼ねて書こう、と思っていたが、この設定に手間取ったのだ。
今までは、同じ QNAP の TS-220 を使用していた。
６年半ほど前に購入したものだ。
その前の NAS は、６年半使ったところで壊れた。
だから、TS-220 もそろそろ買い替え時だと思うのだ。
後継機への乗り換えだから簡単にできる…つもりでいたら、思った以上にハマリポイントが多かった。なかなか日記を書けなかったのもそのためだ。
購入を検討している人のために最初に結論を書いておくと、標準のメモリ（2Gbyte）は足りなすぎる。
特に複雑なことをしない、普通の状態でも足りていない。
なぜそんな状態で売っているのか、と思うのだが、一応動作はしているので、最低限のセットで販売しているのだろう。
4Gbyte モデルも販売しているようなのでそちらを買うか、交換用の増設メモリを最初から買うのが良いと思う。
もうひとつ、乗り換えの際には、新しい NAS と一緒に新しい HDD も購入しよう。
古い機種の HDD を新しい機種に入れよう、とは考えないこと。
公式には、古い NAS から HDD を取り出して入れ替えると、今までの設定もそのまま引き継がれて簡単…ということになっているのだけど、残念な結果にしかならない。
つまり、251D を購入するなら
・本体
・HDD ２台
・増設用メモリ
を同時購入するのがいい。
僕はトラブルに見舞われながらこれらを順番に買うことになり、無駄な時間を費やしてしまった。
なんでそういう結論に至ったのか、順を追って説明しよう。
まず NAS について知らない人のためにざっくりとした説明を。
狭義には、LAN に接続できるハードディスクドライブ (HDD) 装置を NAS という。
PC に USB で HDD を接続することはできるが、これを LAN 接続で行おう、というものだ。
LAN 接続なので、多くの PC から同時アクセスできる。
（もともと SAN の逆、というパロディでもある。SANもネットワーク HDD 装置だけど、いろいろと逆なのだ）
NAS は最近はもっと多くの機能を提供していることが多いのだけど、いちばん重要なのは「大切なデータが壊れないようにする」機能だ。
そして、この最も基本的な部分に、RAID 技術がある。
RAID を単純に書くと「２台の HDD に同じ内容を書いておけば、片方が壊れてもデータは守られる」というものだ。代償として HDD の導入コストは２倍になる。
現在販売されている NAS 装置は、大きく分けて２系統ある。
買ってきてそのまますぐ使えるように、HDD などをすべて内蔵した製品と、HDD は別売りで自分で購入する製品だ。
一般に前者は初心者向けで、HDD を取り出したり交換したりすることは想定していない。
ここで問題になるのが、HDD が故障する前に本体が故障したらどうなるか、ということだ。
実は以前にその状態になったことがある。僕は技術を知っていたので HDD からデータを取り出すことに成功したが、普通はデータが失われると思っていい。
これでは、なんのための RAID なのかわからない。
HDD 別売りの機種は、当然のことながら HDD の取り出しや交換も想定している。
容量が足りなくなったらデータを残したまま増設する方法も提供しているし、本体が故障したら新しい（後継機の）本体に移し替えてデータを取り出せる、という保証もある。
ここまでの説明で、やっと冒頭の話につながる。
本体の故障だけでなく、後継機への乗り換えの際にも、以前の機種の HDD を移し替えるだけでいい、と公式には説明していた。
でもこの説明はかなり嘘だった、という話だ。
まず、設定は一部しか持ち越されない。
LAN 接続のための一番重要な「ネットワーク設定」は持ち越されず、デフォルトである DHCP 参照にされてしまう。
データ保全に必要な、バックアップの設定なども残ってはいたが使い物にならなかった。
バックアップ先となる「外部 HDD」の認識名が変更になったためだ。
僕の場合、後継機とはいっても、CPU の違う上位機種に乗り換えた。
そこで、NAS 上で使用できる機能なども細かく変更になったのだが、当然ながらそれらに関する設定も動かなくなった。
そしていちばん重要なことだ。
新しい機種で使えると期待していた「ファイルを保護する機能」が、旧機種から持ってきた HDD では使えなかった。
公式ページの説明では、今回の機種間の HDD の移行でもこうした機能制限は無いはずだった。
でも、公式ページの説明と違って機能は制限される。
HDD の載せ替えは、新機種への移行というよりは、本体故障時の緊急措置と考えたほうが良いのだろう。
仕方がないので、新しい HDD を購入することにした。
ちなみに、購入したのは IronWolf の 4T 。
NAS に入れる前に、表面に書いてあるシリアルナンバー (SN と書いてあるアルファベット混ざりの文字列）を２つとも控えておくといい。
（あとで NAS の設定画面から登録を行うと、３年以内に HDD が故障した際には無料でデータ復旧サポートを受けられる）
問題はその後だ。
新機種に古い HDD を入れると、自動的に認識されて新機種用の OS が書き込まれる。
だから、もうこの HDD を旧機種に戻すことは出来ないだろう。データが壊れるのが怖いので試してないけど。
旧機種はすでに使えず、新機種に新しい HDD を入れれば、古い HDD にアクセスする方法は失われる。じゃぁデータはどこから取り出せばよいのか。詰みだ。
これが、冒頭で旧 NAS を稼働したまま新 NAS を導入したほうが良い、と書いた理由だ。
そうすれば、旧 NAS から新 NAS に簡単・確実にコピーを行える。
僕は、幸いバックアップ用の外付け USB HDD があった。
NAS のデータはすでにバックアップされているが、念の為もう一度バックアップした。
（すでに書いたとおり、バックアップ用設定は動かなくなっているので新しく作り直した）
新しい HDD で新機種をもう一度設定した後、このバックアップを書き戻すことで無事復旧することができた。
さらっと「もう一度設定した後」と書いたが、ここにもハマリポイントがあるので書いておこう。
まず、設定をするには、新しい HDD を入れて NAS を起動したあと、WEB ブラウザで NAS にアクセスする必要がある。
この際、NAS には DHCP で IP アドレスが割り振られる。
（家庭内 LAN には DHCP サーバがあるだろう、という前提。DHCP とは、LAN に接続した機械に自動的にネットワーク設定を行う技術）
自動で割り振られた IP アドレスがどこになっているかは人間には分からないので、QNAP が提供する Qfinder というソフトを WIndows などにインストールする必要がある。
これを使えば IP アドレスを見つけ出し、その IP アドレスで WEB ブラウザを開いて NAS にアクセスしてくれる。
最初に HDD のフォーマットが始まる。これには数分程度かかる。
フォーマットが終われば、すぐに NAS として使い始められる。
実は裏で「RAID構築」と呼ばれる作業をやっているのだけど、それは１日も放置すれば勝手に終わるし、構築中でも別の作業は可能だ。
でも、ここがハマりポイントだ。まだ旧 NAS からのデータ移行をしてはならない。
この後の作業で全データを消すことになるから。
最初にやることは、「ストレージ＆スナップショット」の設定に入ることだ。
ここから、Linux の技術の中でも難解な部類に入る LVM の設定を行う。
…いや、簡単に扱えるのが売りの NAS で、なんでこんな難しい設定を包み隠さずみせてるんだよ、と思う。
デフォルトにしろ、とまではいわないが、おすすめ設定とかで勝手にやってくれればいいのに。
HDD をストレージプールに登録し、ストレージプールから改めて「ボリューム」を作り出す。
ボリュームというのは従来の考え方で言うパーティションのことだ。
ボリュームは幾つかの方法で作り出せるが、シックボリュームで全体容量の６割程度にしておくといい。
また、「保護されたスナップショット領域」も確保する。こちらは２割程度で。
残りはシステムで使用する領域と「余り」になるわけだが、この余りはいつでも他の部分に追加できる。容量が足りなくなったときの予備だ。
従来のパーティションだとこうした動的な割当は出来なかったのだが、ボリュームなら可能だ。
これで、以降は「スナップショット」という、最新の便利機能が使えるようになる。
せっかく最新の NAS を買ったのだから、最新機能を使わないのはもったいない。
バックアップを書き戻しながら、RAID 構築を行いながら、NAS の設定もしていると、画面の左下のマスコット（謎のロボット。カイル君みたい）が、頻繁に目をバッテンにしながら「メモリ容量低下」と言っている。
なんだこれ、同時並行作業数が多すぎるのかな…と思いながら、このときは様子見にした。
翌日、RAID 構築もバックアップ書き戻しも終わった状態で、改めて各種設定などを行う。
まだ「メモリ容量低下」と言い続けている。
ここで気づくが、標準搭載の 2G のメモリでは、単純なファイルサーバーの状態でもメモリが足りないようだ。
頻繁に SWAP をおこし、プログラムが HDD の上で動いているような状態。
その HDD は NAS だからもともと頻繁に動かしているわけで、全体的に速度が低下する。
SWAP しても動いてはいるし、2G でも足りるだろうと考えて売っているのかもしれないけど…
いや、これむしろ「メモリは交換されるのが前提」だと考えて、一番安いメモリ搭載して売っているだろ。
増設用メモリを注文。
251D には SODIMM のメモリスロットが２つあり、最初は片方に 2Gbyte のメモリが入っている。
公式には、片方に 4Gbyte まで搭載可能。両方に搭載する場合は、同じメモリを搭載しなくてはならない。
ネットで探すと、今どき SODIMM は 8G が主流のようだ。
251D でも、公式にはサポートしないが 8G を認識するという報告がネットに散見される。
僕としては複雑なことをしたいわけではないので、倍の 4G あればいいかな…
とおもったが、後から気が変わったときに、もう一本全く同じメモリを買うのは多分無理だ。
4G ２本を購入。届いてから交換して 8G になった。
ネットによれば、相性問題が激しいらしくて、「動作確認できた」というメモリは人気商品になっている。
…Amazon ではすでに売り切れだったり、妙に高値だったりする。
あえて別の製品を選んでみる。
TIMETEC 社製のメモリ。4G SODIMM として最安値ではないが、それに近い価格だった。
アメリカの会社で、日本法人からの直販なので、問題が出たときのサポートもしっかりしていそうだ。
でも、問題なく動いた。すでに数日稼働を続けているが、相性による不具合は出ていない。
（もっとも、相性って個体差もあるので、他人が「相性問題出てない」と言ったとしても、あまり意味はない）
これでやっとまともに運用できるようなった。
251D は「後からパーツを購入して機能拡張できる」と人気の NAS なのだが、「後から」ではなく、最初にやらないとまともに動かないという話でした。
NAS の話、長いので一旦ここで区切る。
関連ページ
別年同日の日記
申し訳ありませんが、現在意見投稿をできない状態にしています。 |
QNAP の NAS TS-251D の導入だけで大変だった、という話を書いたが、ここからはやっと「本来やりたかったこと」を試した話だ。
旧機種 220 は、ARM CPU だった。これは家庭用 NAS としてはエントリーモデルだ。
この頃の「上位機種」は 251 だった。Intel CPU だ。
さて、220 の後継機種は 230 になる。そして、251 の後継機種は 251D だ。
今回、単純な後継機への乗り換えではなく、上位機種の乗り換えにもなっている。
220 と 251 は、当初同じ機能が提供されていた。ただ、251 のほうが動作が高速だった。
その後、新機能は 251 にのみ提供されたり、機能差が出来ていく。
僕が 220 を購入した最大の要因は、家族写真・ビデオの整理だった。
220 には「トランスコード」という機能があり、各種フォーマットのビデオファイルを、スマホや WEB でも見やすい mp4 に変換してくれた。
ところが、ある時の OS バージョンアップに伴い、このトランスコード機能が 251 だけの提供となった。
それまで使えていた機能が、ある日から急に使えなくなったのだ。
現時点で、230 と 251D には同じ機能が提供されている。
ただ、251D の方が「処理性能が高い」というだけだ。
（あと、251D は拡張可能だが、230 はそうではない）
しかし、以前の経験があるから、上位機種を買っておこうと思ったのだ。
ではそのトランスコード機能について書こう。
トランスコード機能は確かに使えるのだが、期待していた機能が入っていなかった。
かなり残念な結果だ。
我が家の家族ビデオの多くは AVCHD フォーマット（拡張子 MTS）で撮影されている。
220 にトランスコードが提供されていたときは、AVCHD は対応していた。
しかし、現在の 251D のトランスコードは、AVCHD は対応していない。
AVCHD は家庭用ビデオカメラでは広く普及している規格だ。
内容的にもそれほど特殊なものではなく、mp4 の一種に過ぎない。
ただ、mp4 というのは細かなパラメータが多い規格であり、ファイルの名付け規則やディレクトリの配置規則もない。
家電品としてはそこら辺が定まっていないと使いにくかろう、というので定めた程度の規格だ。
だから、それほど対応が難しい規格ではないはずだし、先に書いたように以前は対応できていた。
それなのに対応していないというのは…
じつは、220 が対応していた頃は「QNAPが」この対応プログラムを作っていた。
しかし、数多のビデオフォーマットに対応するのは大変だったようで、現在はサードパーティのプログラムを使って対応している。
（QNAP ユーザーは無料でインストールできるようになっている）
そして、このプログラムは AVCHD に対応していない。
QNAP が独自対応していた時は AVCHD に対応していたのだけど、数ではもっと多くの形式に対応できるサードパーティのライブラリは、完全な包含関係にはなかった、ということなのだろう。
とりあえず、対応してくれと QNAP に要望は出しておいたが、望み薄だと思っている。
多分そんな要望はすでに山ほど来ているだろうから。
このライブラリ、変換部分は ffmpeg にすぎないようなので、パラメータがいじれれば自分でも対応できるようなレベルの話なのだけど…
ちなみに、ファイルサーバーとして Windows からアクセスして、ファイルを直接見れば Windows のビデオ機能で再生できる。
ただ、一括管理ができず、不便というだけだ。
仕方がないのでビデオは諦める。
写真整理についてはどうか。
これについては、悪くない。
以前の 220 では、PhotoStation という WEB アプリが提供されていて、これで NAS に入っている写真を閲覧できた。
でも、この使い勝手はちょっと微妙なもの。悪くはないのだけど、Google photos に比べると使い勝手が悪い。
251D にも PhotoStation が入っていて、新機能なども追加されていたのだけど使い勝手は余り変わらなかった。
ちょっとがっかり…と思ったら、新しい写真閲覧ソフトとして、QuMagie というものが入っていた。
これが、Googe photos を強く意識した…いや、正直パクリのインターフェイス。
それがなかなか使いやすい。
AI による顔認識とか、写真に写っているものの認識とか、EXIF 情報の GPS 位置による場所の認識とかがあって、写真を自動分類してくれる。
顔認識の精度は、ちょっと微妙かもしれない。
というのは、うちの三人兄弟の幼児期の写真を区別できない場合も多かったから。
もっとも、顔だけ見ると親でも識別できないような写真ばかりだけど。
親は周りのシチュエーションで誰か区別できるのだけど、AI はそこまで出来ないので区別できないのは仕方がない。
まぁ、Google photos も有料化したとはいっても、当面の無料使用可能な容量があるので、当面は使い続けるのだけどね。
導入部分で書いていた、スナップショット機能について。
これ、すごく期待していた機能だ。
「大切なデータを守る」というのは簡単なのだけど、どうすればそれができるのか、という方法論は実は奥深い。
RAID は、ディスクの故障からファイルを守ってくれる。
でも、人間のうっかりミスで消してしまった、上書きしてしまった、などの事故からは守ってくれない。
Windows には、「シャドウコピー」という機能がある。
ある瞬間のディスクの状態を記録しておいて、いつでもそこに戻れるようにする機能だ。
ファイル１個単位でも戻せるのだけど、よく使われているのは「システムの復元ポイント」だろう。
こちらは、システムフォルダを丸ごとシャドウコピーしている。
Update などの前に自動的に作られ、その直後の再起動で失敗すると、自動的に以前の復元ポイントに戻ったりする。
同様の機能が、MacOS X でも提供されているし、Linux でも LVM の一部として提供されている。
そして、NAS のスナップショット機能も、この LVM を使用したものだ。
先に書いたように、Windows にも類似機能があり、NAS をファイル共有で見ると、Windows 上の通常のファイル操作で「以前のバージョン」に戻すことができる。
Windows の復元ポイントは 64個しか作れないが、QNAP の NAS は、256 作れる。
また、その残し方もかなり柔軟で、直近のものは１時間ごとのスナップショットを残すが、やがては１か月ごとにまとめたものを１年間残す…なんて設定もできる。
その仕組み上、こんな残し方をしていても HDD の容量はそれほど使わない、はずだ。
（まだ１週間程度しか運用していないので、１年続けたときの容量はわからない）
これは、ファイルの保全というより、うっかりミスに備える機能だと思っている。
なので、これとは別にバックアップを取る必要はあるだろう。
NAS は万全のバックアップ体制をとれるとして、個人使用のマシンのデータを NAS に効率的に送るにはどうしたらよいか。
以前は BunBackup を使っていた。Windows 用のフリーソフトだ。
でも、251D なら QNAP 公式の２つの方法が取れる。
１つは Qsync 。もう１つは NetBak Replicator 。
Qsync の方が後から作られ、高機能だというので試してみたのだが…これはなんか違うな。
僕が求めているのは NetBak Replicator の方だった。
まず Qsync の説明をしよう。
これは、MicroSoft の OneDrive とか、Google の GoogleDrive とかの、Windows 向けドライバと同様の動作を行う、QNAP の NAS 向けアプリケーションだ。
デバイスと NAS の間で、常にファイルの同期を行う。
複数台で同じ場所を同期していると、データの共有が簡単にできる。
でも、そのために保持しているパラメータは非常に多いようだ。
「同期をとる」って、案外厄介な作業だからね。
そのため、NAS のデータ置き場は、Qsync 経由でしか見られない。
勝手にファイルをいじられると、それだけで同期が破綻するためだ。
結果として、せっかく NAS にデータを集約しているのに、Windows のファイル共有などからでは、このデータにアクセスできないようになっている。
僕としては、NAS にデータを集約して、バックアップなどで万全の体制を保ちたい、というのが一番の要求だ。
複数 PC で同期をとりたいわけではないし、NAS で見られないのは魅力半減だ。
そこで、NetBak Replicator 。これは Windows の特定のディレクトリ以下のファイルを、変更があれば即座に NAS にバックアップするためのソフトだ。
一方的なバックアップであり、同期ではない。
そして、バックアップしたファイルは、ファイル共有から見ることができる。
先に書いたが、NAS にはスナップショットで過去のファイルでも取り出せるような仕組みがある。
これは、Windows からは、該当ファイルに対して「プロパティ」の「以前のバージョン」を見ることで簡単に取り出せる。
これで、個人所有の PC から NAS にデータを送り続け、バックアップする体制ができあがる。
ちなみに、スマホからは Qfile を使ってバックアップの設定ができる。
撮った写真を自動的に NAS に入れるように設定した。
まだ購入から１週間、まともに動くように（メモリを増設して）からは３日くらいしかたっていない。
なので、今のところレポートできるのはこれくらい。
でも、大体やりたい設定は終わった感じなので、後はこれらの設定がどれだけ「普段の動作を邪魔せず、スマートに」動いてくれるか、という程度だ。
ちなみに導入コストだが、当初予定していなかったメモリ増設なども含め、６万８千円ほどだ。
また６年半くらい使うとして、年間１万円程度のコストで、家族で使える 4T のストレージが入手できたことになる。
Google One ドライブなら、2T で年額１万３千円。
NAS の方がいろいろと便利な部分もあるし、悪くない買い物かな。
関連ページ
別年同日の日記
申し訳ありませんが、現在意見投稿をできない状態にしています。 |
QNAP 251Dのその後。
前回書いたが、AVCHD で撮影したビデオを見ることが出来ない。
QNAP に「どうにかして」とお便りを送ったところ、数度のやり取りの後「現在のところ、仕様」という予想通りの答えとなった。
でも、サポート担当してくださった方はこの問題を知らなかったようで、色々と調べてくださった。
その中で、以前は（僕が前の NAS である 220 を購入した頃には）フリーウェアを使って変換していたが、その後フリーウェアの開発終了にともない、サポートできなくなった、という情報を得た。
QNAP は、アプリをダウンロードすることで機能を拡張できる。
機種によって提供されているアプリが多少違うのだが、少し前の機種では CodexPack というものがあったらしい。
これは FFmpeg の拡張コーデックで、入れると対応できるビデオ形式が増えたそうだ。
（アプリを増やせばメモリを食うようになるため、必要な人だけ入れれば良い、という配慮）
つまり、内部的にはフリーウェアである FFmpeg を使用していた、ということ。
FFmpeg は、非常に多くのビデオ・音声形式を相互変換したり、編集したりできるフリーソフトだ。
つまり AVCHD が見られた、「以前の」フリーウェアは使わなくなったが、その後は FFmpeg を使っていた、ということになる。
はて。FFmpeg なら、AVCHD にも対応できるはずなのだが。
しかし、今は CodexPack は提供されていない。
各種情報を総合して考えると、いまでも FFmpeg は使っているのだが、CAYIN MediaSignPlayer というサードパーティアプリの一部として提供されている。
そして、拡張コーデックは無償提供ではなく、別売りになっている。
ただ、この拡張コーデックを買ったとしても、AVCHD には対応できない。
CAYIN の WEB ページを見ると、ページ下部に FAQ があり、そこに「現在のところ AC3 には対応していない」と書かれていた。
QNAP でAVCHD が見られない最大の理由は、AVCHD で使用されている音声フォーマットである AC3 に対応しないためだ。
FFmpeg が対応しているのに、なぜ対応しないのだろう。
QNAP には ssh ログインの機能もある。
NAS の OS の基幹部分である Linux を見せてしまう、ということだ。
NAS は安定性が第一なので余りいじりたくはないのだけど、入ってみた。
ffmpeg コマンドを実行すると、たしかに入っている。
そして、usage メッセージには、ffmpegのコンパイルオプションが示される。
ここに、 --disable-decoder=ac3 と書かれていた。「ac3 は使えないようにする」という指示だ。
つまり、CAYIN が対応していないというだけでなく、その内部で使われている FFmpeg も、わざわざ AC-3 を使えない状態にしてある。
バージョンは、3.3.6 、結構古い。どうやら 2017 年のバージョンらしい。
Debian の一部としてコンパイルされたもの、らしい。
…他にも色々調べ物をしたが、見えてきたのはこういうことだ。
2011 年頃、FFmpeg プロジェクト内で管理方針をめぐる対立があり、分裂があった。
FFmpeg と機能的には同じだが、管理方針の違う libav というプロジェクトが興ったのだ。
当初は両者活発に活動していた。管理方針で対立はあったが、機能面では同じものを志している。
お互いに成果を取り入れつつ、それぞれ活動していたようだ。
これを応援するように、いくつかの Linux ディストリビューションでは、libav を採用する。
Debian も libav 派だった。
しかし、やがて libav は失速する。一部が飛び出して新プロジェクトを作ったとはいえ、多くの開発者は FFmepg に残っているのだ。
新機能は主に FFmepg で実装され、libav はバグ修正すらなかなか行われない状態になる。
2015 年頃、FFmpeg のプロジェクトリーダーが辞任し、交代となった。
トップが交代するということは、管理方針にも影響を与える。
このとき、引退するリーダーは「プロジェクトが分裂しているのは望まない。戻ってきてほしい」とlibav の開発者にメッセージを出した。
これがきっかけで、libav は2016年にはその活動を事実上停止した。
（一応、その後も 2018年まではリリースを続けているのだけど）
どうも、QNAP が古い機種で使っていて、開発終了になったライブラリというのは libav のようだ。
Debian なども、このときに libav から FFmepg に再変更している。
QNAP の内部の Linux が、どのディストリビューションをベースとしているかはよくわからない。
しかし、やはり同じように libav から FFmpeg に戻したのだろう。
ただ、これだけでは AC-3 非対応の理由にはならない。
AC-3 は、ドルビー研究所が考案した音声コーデックだ。
そのため、ドルビー研究所が特許を持っていて、使用するには特許料を払う必要があった。
「あった」という過去形で、2017 年には特許が失効している。
先に書いたが、CAYIN が内部に抱えている FFmpeg は 2017 年のものだ。
推察するに、CAYIN の開発を行っていた頃はまだ特許が継続していて、特許料の関係で AC-3 はサポートしないことにしたのだろう。
その後特許は失効したわけだが、「サポートしない」つもりで作成したソフトを、今からサポートするように変更するのもリスクが伴う。
そもそも、内部の FFmepg のバージョンがずいぶん古いのだ。これも、バージョンを変えたら、その上で動く CAYIN が正しく動作するのか、全チェックを行うのが大変だからだろう。
QNAP が CAYIN と提携したのは、2020 年…去年のことなので、今後どうなるのかはよくわからない。
翌日追記
CAYIN の内部 FFmpeg が 2017 年のもの、と書きましたが、勘違いでした。
QNAP は標準で内部に FFmpeg を２つ持っていて、QNAP が入れた（使っていない？）FFmpeg が 2017年のもの、CAYIN は 2020 年のバージョンでした。
しかし、AC-3 をサポートしていないのは同じです。
どうも「AC-3 自体の特許は失効したが、関連特許が残っているため念のためサポートを見合わせている」ということのようです。
追記終わり。
ということは、だ。
おそらく、内部の FFmpeg を、しれっと AC-3 対応に変えてしまえば、ビデオが見れるようになるのかもしれない。
AC-3 対応が目的ではないが、同様のことを試みている人がいる。
機種が違うし、このパッケージは「CodexPack」が入っていることを前提としているので、251D で動くかは不明だ。
変なことをして NAS の動作を不安定にするのも嫌なのだけど、どこかで試して見る価値はあるかもしれない。
→ 翌日試しました。AVCHD 動画も見られるようになりました。
関連ページ
別年同日の日記
20年 phpSpreadsheet で小数点付き数値と見なせる文字列を入力するとおかしくなる
申し訳ありませんが、現在意見投稿をできない状態にしています。 |
最近 NAS の話ばかりで恐縮だが、また昨日の続きだ。
文章を書くというのは現状の整理に役立つ。
昨日の日記を書いているときは、QNAP サポートとのやり取りを公開・記録して「仕様ということで、AVCHD を見るのは諦めるしかありません」というまとめにする予定だった。
でも、それまでに集めたデータを、人に伝えるために整理しているうちに「あれ？ これ、なんとかなるんじゃないの？」と思うようになった。
それが最後に書いた部分で、含みをもたせた終わり方になった。
この時点では自分では試しておらず、可能も不可能も言い切れる段階にないと思ったためだ。
現時点で続きを書いているというのは、もちろん進展があったためだ。
完全ではないが、QNAP から AVCHD の動画を見られるようになった。
ただし、Web アプリの QuMagie からの再生だけ、うまくいっていない。
写真閲覧の機能が充実しているだけに、この点が残念だ。
具体的に言えば、AVCHD から mp4 へのトランスコードは可能になるのだが、QuMagie だけは元ファイルを参照しようとしてしまう。
FileStation や VideoStation では、トランスコード済みのファイルを参照するように設定する項目があるのだが、QuMagie にそのような設定が見当たらないのだ。
（Android アプリ版の QuMagie では設定が行えるため、動画の再生に支障はない）
そんなわけで、完全ではないがかなりの状況改善だと思う。
では、設定方法を記そう。
前提条件として、NAS に ssh ログインして管理者権限で作業を行う必要がある。
管理者権限での ssh 作業というのは、「NAS を壊すかもしれない行為」だ。
意味が理解できない人はやるべきではない。
ただ、Linux などに慣れている人であればさして難しい作業ではない。
251D の、日記執筆時点での環境を前提に話を書くが、多少違っても対応できるように、作業の「意味」も記しておく。
まず、NAS を ssh ログイン可能な状態にしよう。
コントロールパネル → ネットワークとファイルサービス → Telnet / SSH で、SSH 接続を許可する。
このとき、「アクセス許可の編集」で、接続できるユーザーも設定しておこう。
ssh クライアントは自由に選んでくれ。…この言葉の意味がわからない人は、NAS を壊す危険があるので諦めよう。
ssh ログイン可能なことを確認したら、ひとまずこの作業は終わり。
つづいて、AppCenter から FFmpeg をインストールする。
普通、AppCenter には QNAP 純正のアプリしか表示されないが、AppCenter には「サードパーティのアプリ」をインストールさせるための機能もある。
海外には QNAP Club という大きな QNAP ユーザーのコミュニティがあり、そこでは、AppCenter に設定することで直接インストールできる形式のアプリをたくさん公開している。
これを AppCenter に設定しよう。
AppCenter を開き、右上の歯車アイコンをクリックし、「設定」パネルを開く。
「アプリリポジトリ」のタブを開き、「追加」ボタンを押す。
すると、リポジトリ（アプリ置き場）の URL などを尋ねられる。
名前は QNAP Club 、URL は https://www.qnapclub.eu/en/repo.xml を登録しよう。
ユーザー名などは不要だ。
これで、AppCenter の左端に「QNAP Club」というアイコンが表示されるようになる。
そのアイコンを選ぶと、QNAP Club の「マイアプリ」を表示した状態になる。
過去にインストールしたアプリの一覧だが、当然なにもない。
左端から２番めの縦の帯（言い方が難しいな）の中に「マイアプリ」と「すべてのアプリ」の切り替えがあるので、全てのアプリを表示する。
大量のアプリが表示されるので、上にある虫眼鏡アイコンをクリックし、 ffmpeg を検索しよう。
日記執筆時点では、バージョン 4.4.0 だった。
後はインストールするだけだ。
この ffmpeg は ac3 にも H.265 にも対応しているので、AVCHD だけでなく、最近のスマホの動画形式も見ることができるようになる。
（公式には CAYIN の有料コーデックを買わなくては H.265 対応にならない、ということになっているのだが）
さて、ffmpeg が入っても、QNAP の OS はこれを使ってくれない。
現在入っている ffmpeg ではなくこちらを使うように…OS を騙す設定をしよう。
ここからは、ssh での作業だ。
まず、AppCenter でインストールされたパッケージは、各種共有ディレクトリと同じ階層の隠しディレクトリに入る。
ただ、この共有ディレクトリの実態は、環境により異なるらしい。
環境によりディレクトリが違うというのは、面倒な手間になる。
そこで、QNAP では、ソフトリンクによってこの違いを隠蔽する。
/share/Public がソフトリンクになっていて、ここにアクセスすれば共有ディレクトリにアクセスできる。
まずは、このディレクトリのソフトリンクがどうなっているか確認しよう。
（ls -l で確認できる）
251D の場合、
ls -l /share/Public
lrwxrwxrwx 1 admin administrators 21 2021-07-11 10:46 /share/Public -> CACHEDEV1_DATA/Public/
という結果が得られた。/share/CACHEDEV1_DATA/Public が共有ディレクトリの実態だ。
このディレクトリと同じ階層の隠しディレクトリ、.qpkg の下が、パッケージからインストールされたアプリが入るディレクトリだ。
つまりは
/share/CACHEDEV1_DATA/.qpkg
の下で作業を行う必要がある。
ディレクトリ内には、少なくとも、先ほど入れた ffmpeg と、トランスコードなどを行うプログラムである MultimediaConsole が入っていると思う。
251D ユーザーでトランスコードを使いたいなら必須とされる、MediaSignPlayer も入っているだろう。
（少し以前の機種のユーザーであれば MediaSignPlayer ではなく、CodexPack が必須となるようだ）
さて、MultimediaConsole と MediaSignPlayer の下には、それぞれ別の ffmpeg が入っている。
どちらも、ac3 や H.265 のサポートを外してあるものだ。
（昨日も書いたが、ライセンスの問題があったのだろう）
具体的なファイル位置は、以下の通りだ。
ffmpeg/ffmpeg
MultimediaConsole/medialiblary/bin/ffmpeg
MediaSignPlayer/CodexPackExt/static/bin/ffmpeg
ffmpeg/ffmpeg で、それ以外の ffmpeg を上書きする。
まぁ、上書きと言っても実際には、古いものは ffmpeg.bak のような名前にリネームしておき、新しいものをソフトリンクしておくのが良いと思う。
なお、普通に ffmpeg を起動するときは /usr/bin/ffmpeg が動作するのだが、これは MultimediaConsole の ffmpeg へのソフトリンクだ。
まとめると、251D の場合は、ssh 上で行うべきは次の作業。
（ここまでに書いた意味を理解したうえで実行すること。最初に警告した通り、意味が分かっていないと NAS を壊す可能性がある）
cd /share/CACHEDEV1_DATA/.qpkg/
mv MultimediaConsole/medialiblary/bin/ffmpeg MultimediaConsole/medialiblary/bin/ffmpeg.bak
mv MediaSignPlayer/CodexPackExt/static/bin/ffmpeg MediaSignPlayer/CodexPackExt/static/bin/ffmpeg.bak
ln -s ffmpeg/ffmpeg MultimediaConsole/medialiblary/bin/ffmpeg
ln -s ffmpeg/ffmpeg MediaSignPlayer/CodexPackExt/static/bin/ffmpeg
なぜ２つの ffmpeg を持っているのかは不明だが、現在は MediaSignPlayer をインストールしないとトランスコードができないので、MultimediaConsole のものは「歴史的経緯」で残っているだけかもしれない。
以上の作業で、AVCHD ファイル (拡張子 MTS）のトランスコードが可能になる。
一応オンザフライ（再生するその場で変換を行う）のトランスコードも可能なのだけど、処理速度が遅くて実用にならない。
あらかじめトランスコードを行う設定をしよう。
なお、「あらかじめ」のトランスコードの場合、ファイルが生成されるので保存容量を使う。
元の品質と処理後の品質にもよると思うが、僕は「内容が確認できれば良い」と割り切って、360p のデータを生成することにした。
（デフォルトもこの値なので、お勧めなのだろう）
我が家の場合、元はハイビジョンの 1920 x 1080i。
これを 640 x 360p に変換するので、この時点でデータ量は 2/9 になる。
実際には圧縮の効きやすさとか、動画ごとの特性もあるのだろうと思うが、データは 1/5 ～ 1/10 程度のファイルサイズになるようだ。
このくらいなら利便性の代償として、使っても良い程度の容量に思える。
MultimediaConsole アプリの「トランスコーディング」設定を行うだけで、特に難しいことは無い。
これは標準の機能なので詳しくは解説しない。
最後に、動画を再生する際に、トランスコード済みのファイルを参照するように設定する必要がある。
ある程度トランスコードが終わってから、ファイルが生成された動画を使って確認するといいだろう。
・アプリの場合、動画再生しようとした時点で、品質を聞いてくると思う。
360p を選べばよい。「この設定を記憶する」をチェックしておけば、今後は常にその品質を使ってくれる。
・QTS 上の FileStation (つまり Web アプリ）の場合、MediaViewer というウィンドウが開く。
再生できないと言われるが、これは元ファイルを参照しているため。
右下の、フィルムと歯車を組み合わせたアイコン（ビデオ設定）を開き、「オンラインストリーム再生」の項目を「360p」にすると再生される。
設定は記憶されるので、以降はどのファイルを開いてもすぐに再生されるようになる。
・VideoStation の場合も同様に設定する。というか、FileStation で開く「MediaViewer」の実態は VideoStation の再生ウィンドウのようで、上の設定はこちらでも活きているはず。
・PhotoStation では、動画を見ようとすると再生品質を聞いてくる。
360p を選べばよいのだけど、記憶させる設定はなく、毎回聞かれる。
・CAYIN MediaSignPlayer では、元のファイルとトランスコード済みファイルが並んで表示される。
トランスコード済みを指定すれば見ることができる。
（しかし、CAYIN はトランスコードに必要だから入れているだけで、全体に使いやすくはない。
わざわざ使う必要はないだろう）
そして、最後だ。
Web アプリ版の QuMagie 。最初に書いた通り、設定の方法がわからず、動画が見られない。
AVCHD ではない、普通にみられる動画で実験してみると、QuMagie で動画を見た場合にも、右下に歯車アイコンが表示され、品質を設定できる。
ただ、この時設定した品質を記憶してくれないのだ。
そのため、必ず「元のファイル」を表示した後で「トランスコード済みのファイル」を再生するように指定する必要がある。
この時点で、AVCHD は元ファイル表示ができずに終わりなのだ。
非常に残念だが、ビデオを気軽に見たい理由は「家族に見せるため」だ。
僕が見たいのであれば、Windows 上でファイルを開けばよい。
なので、目的はほぼ達成されたと言ってよいだろう。
FFmpeg を公開している、QNAP Club に感謝。
翌日追記
Amazon Fire TV Stick 用の Qmedia も試したが、動画は見られなかった。
トランスコード済み動画を使用する機能がなく、360p を指定してもオンザフライになってしまう。
このため、使い物にならないくらい遅い。
Fire TV Stick だからテレビが前提で、圧縮しない元データで見るという前提のようだ。
もっとも、この Qmedia というソフト、Fire TV 専用であまり使いやすくなかった。
（家族の想い出ベースで…写真と動画を一緒に見たいのだが、Qmedia では写真と動画は全く違うもの、という扱いだった）
関連ページ
別年同日の日記
申し訳ありませんが、現在意見投稿をできない状態にしています。 |
オリンピックが始まったが、IOC ではなくて、IOCCC の話。
IOC は International Orimpic Comittiee （国際オリンピック委員会）の意味だけど、
IOCCC は the International Obfuscated C Code Contest（国際難読Ｃコードコンテスト）だ。
IOCCC の話は、昔の日記でちょろっと出したことがある。
「難読」ということになっているけど、この意味は多様だ。
ソースを見ても動作が想像できない、程度に考えておくとよいと思う。
だから、数学的に高度なことを行っていて想像つかないようなものもあれば、Ｃ言語の仕様を悪用しているものや、単に読む人に対する「いたずら」をしているものもある。
そしてもちろん、読めなければいいというだけではない。近年は「驚くような動作」が求められるようになっている。
昔、興味を持って入選作のプログラムを読もうとしたことがあったのだけど… いや、全く歯が立たなかった。
特に古いプログラムは、現代の環境では動かないものも多く、動作させながら理解することも難しい。
ところが数日前に、過去に入賞した全作品の解説を、日本語で行っているページが今年に入ってから作られているのを知った。
現代の環境で動かすためのパッチなども示されている。
これがまた、面白い。
解説を読んで感心したり、面白そうなプログラムは自分でも動作させてみたりしながら、何日もかけてゆっくり楽しんでいる。
いったい誰がこんなページを、と思って確認したら、近年の IOCCC で常連の日本人だった。
しかも、その受賞作のいくつかは、IOCCC とは無関係に、その動作のすごさがネットで話題になっていたりしていて、見たことがあった。
ところで、第１回大会は 1984年に開かれている
この時の大賞作品について少し話をしよう。
Ｃ言語では、プログラムの制作者は必ず「main」と名付けられたプログラムを作り、それが最初に呼びだされることになっている。
しかし、対象作品には main がない。それどころか、プログラムが１行も書かれていない。
代わりに、main という名前のデータを定義している。このデータも、意味不明の数値が並んでいるだけだ。
じつは、Ｃ言語では「名前」にプログラムとデータの区別はない。
だから、main という名前のデータがあれば、言語のシステムはそれがプログラムだと思って最初に呼びだしてしまう。
ところが、内容は数値データだ。実はこの数値データは、当時 UNIX の世界では一般的だったコンピューター、PDP-11 の機械語命令コードなのだ。
そんなわけで、このプログラムは大賞をとってはいるが、PDP-11 がないと動かない。
先に僕が「現代の環境は動かない作品も多い」と書いたが、要求されるマシン環境すら限定されるのだ。
さて、話を戻して、この解説記事を書いてくださっている人の話。
IOCCC の常連と書いたが、2015 年の作品で「1984 年の作品を動かすための PDP-11 エミュレータ」を作っている。
これにより、PDP-11 がないと動かないはずの作品ですら、動作させることに成功している。
とにかくこのコンテストが好きで、過去の作品の動作も見てみたい、という愛にあふれている。
愛のある人が解説をしているのだから、その面白さは保証されていると言ってよいだろう。
最後に自分の想い出語り。
このコンテストの「存在」を知ったのはずいぶん昔…年齢がばれるが、大学生の時に友人から聞いたもので、1992年ごろだったと思う。
その時はまだ WEB も普及していなかったし、話に聞いただけで作品を直接見たわけではない。
でも、 2["abc"] と書くことで c を取り出せるとか、配列に機械語を入れて呼び出すことができるとか、Ｃ言語の「低レベルな」仕様の話を聞いて、すごく面白いと思ったものだ。
（僕は当時、PDP-11 を参考に作ったという MC68000 CPU のアセンブラは理解できていて、Ｃ言語も初心者ではあったが理解していた。そのため、 [ ] が配列を意味するのではなくアドレス演算にすぎない、という話は素直に理解できたのだ）
当時の理解としては、とにかく仕様の穴を突くようなプログラムテクニックを競う、というようなものだと思っていた。
いや、実際初期の作品はそういうものも多い。
でも、制約の中で複雑な動作をつくる、という側面も大きい。
今だと、Ｃ言語以外でも文字数の制約の中でプログラムを作るようなコンテストは行われているのだけど、そういうコンテストのさきがけの一つともいえる。
となると、そこには単に「難読」というのを超えた、素晴らしい工夫がたくさん入っているのだ。
日本語解説ページで取り上げられている作品は非常に多く、まだ全部は読めていないが、そうした工夫を見るのは非常に楽しい。
とりあえず、コンテストの比較的初期の中から気に入った作品を１つ上げておこう。
この作品は、プログラムが「往復書簡」のように読めるように作られている。
もちろん、Ｃ言語のプログラムとしての制約があるため、英語そのものではない。でも、「英語っぽく」読めるように工夫されているのだ。
往復書簡の登場人物は、 char*lie と char lotte 。チャーリーとシャルロット、なのだけど、Ｃ言語の char 型の変数定義になっている。
英語そのものではないが、英語っぽく読める、というのはそういうこと。
で、この二人がラブレターを送りあっているのだけど、途中から仲たがいして、破局に至るまでがつづられている。
これはプログラムなので、コンパイルして実行できるのだけど、花占いのプログラムになっている。
「好き」「嫌い」って交互に表示するプログラムなのね。
で、これを作った作者のコメントによれば「char*lie と char lotte は非互換」とのこと。
（Ｃ言語わかる人ならわかるね）
つまり、英語のラブレターとして読めて、Ｃ言語のプログラムとしても読めて、実行すると恋愛占いで、その登場人物の相性が悪いのは最初からわかってるだろ、と、４つも意味を重ね合わせている。
超絶技巧。
これは、ソースコードが英語だ、というわかりやすさがあったので紹介したけど、他にも舌を巻くような作品ばかり。
行単位でランダムにソートしても、必ず動くプログラムになる作品、なんていうのもあったな。
プログラマーなら読んでみると楽しめると思う。
別年同日の日記
申し訳ありませんが、現在意見投稿をできない状態にしています。 |
恥ずかしながら、今朝未明の３時ごろから先ほど、９時40分ごろまで、このWEBサイトにアクセスできなくなっていた。
原因は、SSL証明書の失効。
Let's Encrypt で取得し、自動更新する設定にしていたのだが、今年の上半期の終了、５月末日を持って古いプロトコルが廃止されたらしい。
３年前には、新プロトコルも、対応するツールも公開されていたのに、気づいていなかった。
６月１日の直前にも、メールで「旧 API廃止」と警告されていたのに、気づいていなかった。
さらにその後も「証明書更新してないよ」という警告が来ていたのに、気づいていなかった。
どんだけボンクラなんだ、って話だけど、仕事ならともかく、趣味でやっているサイトなのでそこらへんはいい加減だ。
申し訳ない。
（SSL は基本技術過ぎて空気のようなもので、無くなって初めてその存在に気付くのだ）
で、最後に更新していたのが５月２９日。
Let's Encrypt で発行される証明書は期限が３ヵ月なので、今朝失効したというわけ。
失効すると１から取得しなおさないといけないのだけど、もう何年も取得なんてしていなかったので、やり方忘れていた…
９時前に失効に気づき、慌てて作業しようとするも、作業手順すら忘れていた。
というか、どのマシンで証明書の自動取得を行っていたかすら忘れていて、違うマシンの中でコマンドを探し始める始末。
（WEB サーバー証明書だから、WEB サーバーで処理しているに決まっているのに）
ネットで情報探しながら作業して、およそ１時間。やっと再取得できた。
いろいろとエラーを出しながら、そのエラーを解消していく、ということの連続で、最後のエラーが「API v1 にアクセスできないよ」というメッセージだった。
ここでやっと根本原因に気づいたのだった。
３時間後の追記
ついで（？）なので、古くなっていた SSL 関連の設定を見直してみた。
もう５年も前にチェックしていたSSL LABSでチェックを行ってみた。
一応、その後も時々はチェックしていたのよ。ずっと A+ だった。
でも、久しぶりにやったら B だった。
TLSv1.0 と v1.1 のプロトコルは、「脆弱性がある」ということで、昨年頭に各ブラウザ一斉に使用しない設定に替わったらしい。
それをうけて、これらのプロトコルを許可しているサイトは、B ランク以下にするようにした、という説明があった。
なるほど、そうなのか。気づいていなかったということは、最後にチェックしたのは１年半以上前だということだ。
早速、これらのプロトコルを使えないように設定する。
ついでに、TLSv1.3 をサポートするように、新しい openssl と nginx を導入する。
これで評価が A+ に戻った。
古いプロトコルのサポートをやめた影響で、IE11 以外の「古いIE」を使っている人は、アクセスできなくなった。
あと、Android 4.3 以前（Chrome ではなく、Android Browserを使用する機種）や、Mac Safari の 6.0 (８年前のバージョン）以前もアクセスできなくなっている。
ここを見られなくなった方、ごめんなさい。（と、ここで謝っても読めないわけだが）
というか、IE11 は結構古い（リリースは８年前）のに、ちゃんと TLSv1.2 には対応しているのだな。
そのつもりでレポートを読むと、以前苦労して対応した、Chrome 49 と Firefox 47 （どちらも５年前のバージョン）でも、まだアクセスできるようだ。
IE11 はまだ使っている人いそうだな…
（僕も仕事上使うことがある。動作チェックだけど）
Chrome や Firefox は自動更新なので、こんな古いバージョンを使っている人はいないと思うのだけど、ちゃんと見られますよ、ということで。
別年同日の日記
申し訳ありませんが、現在意見投稿をできない状態にしています。 |
ここのところ仕事が忙しくて、日記を書く暇もネタもなかった。
ネタも、というのは時間があれば仕事してたからね。インプット無くしてアウトプット無し。
自営業にとって仕事が忙しいというのはありがたい話なのだけど、忙しい理由の８割くらいは、先月コロナ罹患で３週間ほど休んだからだろう。
スケジュールに無理が生じて、急いでプログラムを作らなくてはならなかったのだ。
あと、仕事を手伝っている会社では、コロナ禍の状況の中でも業績が伸びている。
ありがたいことだが、ベンチャー企業で少人数なのでプログラマーの手が足りない。
求職中の腕の立つ人がいたら、こちらのページの右上の「採用情報」から詳細が見られるので、是非。
（僕はお手伝いしている外部の人、という位置づけなので、採用に関して口を出す権利はないが、一緒に働くことになったら仲良くしてください。）
ネタもない、と書いたが、日記に書こうと思って時期を逃したネタを…
数日前に、真鍋さんのノーベル賞受賞、という話がニュースをにぎわした。
日本人が受賞、と報じられたのだが、日本生まれだが、60年以上前に渡米し、現在米国籍なのだからアメリカ人だろう。
まぁ、そこはどうでもいい話で、興味を持ったのはその授賞理由。
コンピューターによる数値演算で気象を再現する手法を編み出したことだ。
今では当たり前の技法だし、真鍋氏が最初に考案した方法よりももっと精度が高まっている。
でも、最初に考案した、というのはすごいことだ。
で、ここからは日記ネタにしようとした理由。
真鍋さんは渡米してから師事した方に言われて気象予測モデルの構築を始めたようなのだけど、これが僕が過去に書いた ENIAC の記事の話とつながるのだ。
ENIAC は弾道計算のために作られた、とされる。
実際、作成の際には陸軍が予算を出していて、その理由は弾道計算ができるからだ。
でも、予算がつく前に計算機が欲しい人がいて、設計が行われて、作成する段階でスポンサーを探したのだ。
その設計の理由は「気象予測には膨大な計算が必要だから」だった。
専門ではないので正確な時期を知らないのだけど、20世紀の前半のどこかで、「完全なパラメーターがわかれば、気象は完全に計算できる」という仮説が生まれたそうなのだ。
20世紀に入っても、自然は人智の及ばざるもので、天気もその一部だと考えられていた。
それを、完全に計算できるというのだ。それまでの価値観を打ち壊すような仮説だった。
これは当時の学者にとってなかなか興味をそそる話題だったようで、多くの人が研究に乗り出している。
（こういう研究って、時代の流行もあるのだ）
ENIAC はその過程で必要とされ、設計されたものだった。
その設計者の仮説では、ENIAC くらいの能力があれば気象予測ができるはずだったのだ。
でも、ENIAC ができて気象予測ができるようになった、とは聞かない。
その時の仮説が間違っていたのだろう。
または、ENIAC では能力が足りなかったのかもしれない。
しかし、ENIAC は電子計算機の時代の扉を開けた。
その後、計算機が強力になり、その計算力を武器に気象予測のモデルづくりに挑む学者はたくさんいて、真鍋さんはその中でも見事に「実用的になる」モデルを組み立てた、ということなのだろう。
真鍋さん最初のモデルは、単純化しすぎて正しくないと分かっていながら、当時のコンピューター性能で計算できる妥当なモデルだったようだ。
その後、計算機の高速化とともに改良されたし、こうしたモデルを動かすための「地球シミュレータ」なんてものまで設計された。
（地球シミュレータは、その後も代変わりしているが、単純な計算能力ではすでにそれほどすごいコンピューターではない。
しかし、気象予測のようなものに必要な複雑系を扱えるような独自設計になっており、気象予測や数値風洞と呼ばれるようなプログラムの実行では、まだ高い性能を誇る）
というわけで、今年のノーベル物理学賞は、自分のページで取り上げても良いネタだな…
と思いつつ、すっかり時期を逸してしまったので、この程度の簡単な説明にとどめておく。
別年同日の日記
申し訳ありませんが、現在意見投稿をできない状態にしています。 |