コンピュータの日記です

目次

2019-10-23 メールの1行が78文字の理由
2019-10-09 MVNOをMNP
2019-09-24 Google Asistant
2019-09-19 スパルタかます
2019-09-06 P30 買った
2019-08-29 Nintendo DSi
2019-08-22 SVG うねうね
2019-08-20 ひといき。
2019-08-13 プログラム合宿
2019-07-14 パスワードの管理方法(令和元年版)
2019-06-14 google photos その後
2019-06-12 Google drive バックアップと同期
2019-06-09 新マシンセットアップ中
2019-05-29 Alexa Wunderlist 連携
2019-05-20 Nexus7 (2012) 復活
2019-05-14 パソコンは買ったのだが…
2019-05-08 続:Minit
2019-05-04 Minit
2019-05-03 ServiceWorker と indexedDB
2019-04-26 Amazon Fire HD 10 購入
 …同じテーマのほかの記事
メールの1行が78文字の理由  2019-10-23 17:37:26  コンピュータ

▲目次へ ⇒この記事のURL

先日、Twitter で僕のページを引用してくださった人がいた。


#たびたび書くけど、エゴサーチしてますよ。



引用されていたのは、「OS の登場」のページ。


…書いたのずいぶん前で、内容が拙くて恥ずかしい。

しかしまぁ、大きく間違ったことも書いてないのでそのまま残してある。


で、引用してくださった方は、「1行が80文字」の理由を探していたようだ。


該当ページには、IBM パンチカードが1枚に 80 文字を収めることができたため、コンピューターにディスプレイが付けられた際にも、1行に 80 文字を表示できる必要があった、ということを書いてある。



この話、のちに別のところで詳細解説している。

ハーマン・ホレリス 命日の記事。


ホレリスは、IBM の前身の1つとなる「タビュレーティング・マシン」社を興した人物。

パンチカード集計機を発明し、80桁の数値を記述できるパンチカードを標準化した。


のちに、数値だけでなく文字も表現できるようになったが、80桁、という枠組みは変わらなかった。




さて、冒頭に書いた引用してくださった方は、これが1行 80 文字の理由、としたうえで、「メールの1行を 80文字に制限するマナーは迷信だった」と結論付けていた。


いや、それは論理が飛躍しすぎている。


おそらくは、「古くは」画面の横幅が 80 文字だったことを知り、「今は」その制限がないのだから迷信、という思考の流れだと思う。


しかし、残念ながら 80文字…より厳密にいえば、78文字というのはマナーなどではなくて、システム的な「要求」なのだ。


メールの1行は、78文字を超えるべきではない。


「べきではない」と書かれているように、超えても普通は大丈夫。

だから、緩い制限の「マナー」だと思われがちなのだけど、技術文章で規定された制限なのだ。




インターネットを流れるデータの規定といえば、RFC 。


インターネットメールは、RFC 822 から始まるが、紆余曲折あり、RFC 2822 になり、現在は RFC 5322 となっている。

(なんとなく、822 から連想されやすい番号を割り振っているところが素晴らしい)



で、現在の仕様である 5322 の 2.1.1 節に、こう書いてある。


2.1.1. Line Length Limits

There are two limits that this specification places on the number of characters in a line. Each line of characters MUST be no more than 998 characters, and SHOULD be no more than 78 characters, excluding the CRLF.

(以下略)


意訳:

2.1.1. 行の長さ制限

1行の文字数には、2つの制限がある。

CRLF を除く1行の文字数は、998文字を超えてはならず、78文字を超えるべきではない。


意訳の中の CRLF というのは、改行を意味する文字のこと。

画面上に表示はされないが、コンピューターのプログラム的には、「1行」の最後には、「行の終わり」を意味する文字が必要となる。


説明すると長いので省略するが、行の終わりは2つの見えない文字で成り立っていて、CR と LF だ。


1行は「改行を除いて」78文字を超えるべきではない。

言い換えれば、「改行を入れて」80文字までだ。



ここに、パンチカードは1枚 80文字という制限が復活している。


パンチカードが 80文字だったために、FORTRAN 言語では1行を 80文字以内と定義しており、ディスプレイは1行に 80文字を表示できるように作られ、初期のスクリーンエディタは1行を 80文字以内としていた。


エディタが1行を 80文字で扱うということは、テキストファイルも1行が 80文字を超えることはない、ということだ。

これを前提として、非常に古いメールシステムの中には、1行を 80文字としてプログラムされたものがあるらしいのだ。


今更そんなシステムが生き残っているとは思えないが、もしそうしたシステムがメールを受け取ってしまうと、80文字を超える部分は削除されたり、強制的に次の行に送られたりする。


RFC ではそうしたシステムを考慮して「78文字を超えるべきではない」としている。


場合によっては一部の情報が削除され、相手に届かなくなってしまう。

それを避けるための制限は、トラブルを未然に防ぐために使用者が心がけなくてはならないもので、マナーや迷信ではない。




ところで、RFC 5322 には、使用できる文字コードの制限もある。



2.3. Body

The body of a message is simply lines of US-ASCII characters.

(以下略)


意訳:

2.3. 本文

メッセージ本文は、単純に US-ASCII で作られた複数行となる。


そう、US-ASCII しか使ってはいけないのだ。

英語は許されるが、ドイツ語もフランス語もだめだし、日本語なんて論外だ。


しかし、実際にこれらの言語でもメールは送れる。


どうなっているかというと、US-ASCII 「以外」のメールは、計算によって US-ASCII の文字に「変換」されて送られるのだ。


この計算方法のひとつに、MIME がある。


US-ASCII に変換されるといっても、日本語が英語に翻訳されたりするわけではない。

単に、日本語の文字を示す「数値」を計算して、数文字の US-ASCII の組み合わせで表現されるだけだ。


変換の際、結果として得られる US-ASCII 文字列は、76文字ごとに改行を入れる、という決まりとなっている。

この結果、元文章の1行が 80文字以上になっていたとしても、通信経路上ではちゃんと 80文字以内に収まっている。


結果的に、「80文字を超えるべきではない」という技術的制限は守られているのだが、利用者がそれを気にする必要はない。




…と、これだけなら「80文字制限は迷信」という最初の話でも、まぁいいかな、ってことになるのだけど、話はもう少し続く。



RFC 5322 で書かれているのは、メールの内容の扱いであり、「MIME の扱いは別議論」としている。

つまり、いったん MIME に変換された際には 80 文字の制限が守られるとしても、それは「メールが」 80文字の制限を守っているのとは違う扱いになる。


通信経路上の問題が解消したとしても、メール自体の問題は残っているのだ。




また、上に、US-ASCII に変換する「計算方法の一つに MIME がある」と書いた。


別の方法もあって、その方法を使うと、MIME の「1行 76文字への変換」が行われない。

この場合、通信経路上の問題も解決していないことになる。



MIME は比較的新しい方法で、日本語の場合、古くは JIS コードでメールの通信が行われた。

これも、「日本語を US-ASCII に変換する計算方法」の一つだ。


そして、今でも互換性のためにこの方法を使えるメールソフトは、結構多い。



JIS コードが当たり前だった当時、よく言われたマナーとしては「1行は 36文字以内」だった。


JIS コードでは、日本語1文字は、英語2文字で表現される。

だとすれば、78文字の制限は、39文字以内となるはずだ。


残る3文字はどこに行ったのだろう?


実のところ、JIS では、ASCII と JIS を切り替えるために、ASCII に規定された「ESC」を使用した。

ESC とは、ASCII から「脱出」して、独自の文字コードを使うために設けられた規定だ。


そして、JIS コードは、ESC に続いて2文字を送ることで、日本語と ASCII を切り替える。


行の頭で日本語を開始し、行の終わりで日本語を終わるとしたら、これに 6文字が必要になる。

日本語に変換すると、3文字分だ。


つまり、これが日本語にした際に消えた3文字分だ。

JIS コードを使用する場合、日本語で RFC の規定を守ろうとすると、1行が36文字以内でないといけない。




ちなみに、行の中に ASCII を入れたりすると、そのたびに切り替えコードが入るため、書いてよい文字数はそれだけ減ることになる。


…JIS でメール書いていた時代でも、80文字を超えて問題出るような環境はまずなかったから、そこまで気にしなかったけどね。


#現在、JIS コードには iso-2022-jp という名前が与えられている。

 JIS コードは、日本国内のローカル規格、iso-2022-jp は国際規格だ。




メールに限らず、通信手段というのは、「相手」や「通信経路」など、多くの参加者があって成立するものだ。

そして、多く参加者があるということは、そのどこに問題が潜むかわからない。


RFC がいまだに1行を 80文字に制限しているのも、実際に過去に 80文字の制限を持つプログラムがあり、今でも残っている可能性があるからだ。


もっとも、RFC5322 の中には、80文字で情報を切り捨ててしまうような環境が本当にあるとすれば、それ自体が RFC5321 違反だ、と言及している部分もある。

(5322 は「メールの書き方」を規定していて、5321 は「メールの送信方法」を規定している)



MIME を使っている場合は、途中経路の問題は気にする必要はないだろう。

MIME によって行は 76文字に揃えられ、決して 80文字を超えることはない。


しかし、この場合も、相手が 80文字を超える行を扱えるとは限らない、ということに注意だ。


…まぁ、そんな古いメーラーを使っている場合、MIME で変換された本文を、元に戻すこともできないような気がする。

もし戻せたとしても、UTF-8 が表示できない、なんてことになりそう。


あまり気にしすぎる必要はないけど、ちょっと気に留めとけ、くらいの問題か。




RFC って、「自分には厳しく、他者には寛容に」という精神なんだよね。


超えるべきではない、と言われているのであれば、自分は超えないようにしないとならない。

でも、誰かが超えてしまったとしても、違反だと怒るのではなく、何の問題もなかったかのように扱えないといけない。


RFC の「規定」って、そういうものなの。


だから、80文字を「超えるべきではない」と規定されているのであれば、少なくとも自分は超えないようにした方がいい。

超えたとしても、「寛容」の精神で、おそらく何も問題は出ないのだけど。



ここで、問題が出ないからこそ、ただの「マナー」だと言われてしまいやすい。

でも、問題が出なくても違反行為で、「寛容さによって」助けられただけという意識は必要。



2019.10.29 追記


そもそも、なぜ「US-ASCIIしか送れない」なんてことになっているのか、という疑問をいただきました。


簡単に言うと、今のコンピューターは 8bit を情報の基本単位としているけど、古いコンピューターには 7bit のものがあるから。

US-ASCII は、7bit で文字を表現するようになっています。



この話、詳細はちょうど10年ほど前に書いてます。

少し内容が古い(最新 OS が Windows 7 だったり、メールの JIS 送信がまだ普通だったりする)けど、以下にリンクしておきます。


「その文字」はインターネットで使ってはいけないのか?




▲目次へ ⇒この記事のURL

別年同日の日記

03年 当たりました

15年 古くて非力なマシンをLinuxBeanで再生してみた

15年 マイケル・クライトン 誕生日(1942)

17年 P10 に乗り換え


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

MVNOをMNP  2019-10-09 10:53:17  コンピュータ 家族

▲目次へ ⇒この記事のURL

携帯電話会社を変えた。

電話番号は変わっていない。


今まで、僕は DMM Mobile を使っていた。

ちなみに、妻は BIGLOBE Mobile だった。


経緯は過去に書いているのだけど、もともと両方とも僕の名義で持っていた回線で、MVNO に MNP しようとしたら、「1人1社1回線」ルールに阻まれ、同じ会社にまとめられなかったのだ。



…念のため説明。

MVNO って、一般に「格安 SIM」と言われているやつね。


厳密にいえば、回線提供会社からまとめて安く「回線の使用権」を買い上げ、一般に小売りする業者が MVNO 。

回線自体はドコモや AU なので、品質は保証されている。


(Softbank は厳密な意味での MVNO には提供を行っていない。ただし、別ブランドの Y!mobile を持っており、そちらでは Softbank より安い料金で回線を提供している。)



そして、MNP とは、電話番号は維持したままで別の電話会社にサービスを移行する仕組み。

携帯電話会社間で共通の取り決めがあり、その手順に従えば、電話番号を変えずに会社を変えられる。


先日、ネットで調べものしていたら「データ専用 SIM に MNP した」というブログ記事を見つけてびっくりしたよ。

(データ専用 SIM は、音声用の電話番号とは全く異なる電話番号が付与されており、MNP できない。

 どうも、ブログ主は MNP を「電話会社を変えること」という認識で使っていたようだった)




さて、いつもの通りいきなり余談で話がそれている。


今の MVNO を契約したのは 4年ほど前で、その時には「1人1社1回線」ルールがあった。

しかし、今はこのルールが緩くなり、どこの MVNO 会社でも、複数回線を持てるようになっている。


DMM は合計で3回線、BIGLOBE は5回線まで持てる。

そして、当然ながら、会社をまとめると基本料部分が安くなる。


1か月ほど前に、スマホを買い替えた

これを機に、古いスマホは長男に渡すことにした。


玉突きで長男のスマホは長女に行く。

…が、まだ長女は小学生なので、必要な時に貸すことにして親の管理とする


とはいえ、1回線増やす必要がある。

我が家は5人家族なので、ゆくゆくは5回線必要になるだろう。


そこで、今僕が使っている DMM も解約して、BIGLOBE に寄せることにした。


DMM が楽天に買収され、新規ユーザーの募集をやめてしまった、という理由もある。

すでに回線を持っている人はサブ回線を増やすことはできるのだが、先行き不透明なら今見切りをつけてもよいだろう。


(ちなみに、今まで長男が使っていたスマホは、Sonet の 0-sim を使っている。月額 0円。

 塾などで単独行動で出かける際に、LINE で連絡を取れればよい、という用途なら、これで十分だったが、時々外出時に調べものをしようとして「遅くて使い物にならない」と言っていた。

 もうすぐ高校受験で塾も忙しくなり、外出機会も増えたので高速回線に変えてやろう、という親心)




妻は、BIGLOBE で一番安い、月 1Gbyte の通信量のプランを使っていた。


これを、通信量シェアで3回線に増やしたいのだが、一番安いプランではサブ回線は持てない決まりだった。

そこで、サブ回線が持てる中で一番安いプランである、月 3GByte にプラン変更する。



…SIM を申し込もうと思ったが、プラン変更は翌月を待たなくてはならず、プラン変更が終わらないと SIM を申し込めない。


そのため、スマホを買ったのは先月頭だったが、SIM を変えるのに1か月待たされたわけだ。



そして、月頭の「1日」は、DMM 側で各種集計が行われるために、プラン変更などの手続きができない。

いや、厳密にいえばできないのは午前中程度で、集計終了後はできるのだけど忘れていた。


2日になってから DMM で MNP 転出の申し込み。

転出予約番号が発行されるまで、2~4日ほどお待ちください、となっている。


…それほどは待たず、3日の夜中に発行されていた、ようだ。

気づいたのは4日の朝だったのだけど。


4日に、BIGLOBE 側に MNP 転入の申し込み。

あと、子供用にデータ SIM を申し込む。


音声用は4~6日、データ用は2~4日ほどで家に届くという。


…両方まとめて、6日、日曜日に届いた。全体に仕事が速いよね。




僕の端末の SIM を入れ替え、BIGLOBE の WEB ページから「MNP 切り替え」の指示を出す。

10分ほどかかったが、回線がつかるようになった。日曜日なのにお仕事ありがとうございます。


4年前は、BIGLOBE は切り替え時に、サービスセンターに電話をする必要があった。

といっても、会員番号を告げ、「MNP 切り替えお願いします」と伝えるだけのもの。


これが WEB から申し込めるようになったのはとても楽。



データ SIM は、僕が先日まで使っていた P10 端末に入れる。

こちらは、すぐ通信できる状態だった。


この日はこれで終わり。




月曜日は仕事が忙しく、昨日火曜日に、子供向けに端末を整えた。



P10 をリセットし、長男のアカウントでセットアップしなおす。

Google のバックアップから復帰、を選んだら、ほぼ必要な状態が復元された。


その後、長男が使っていた Honor6 を見ながら、ポチポチとほぼ同じ使い勝手になるように整える。

P10 には指紋認証があるので、使うことにした。長男に指紋押捺させる。


長男が今まで使っていた Honor6 は、ロックをかけていなかった。

当初は「子供みんなが使える端末」として用意したので、誰でもアクセスできるようにややこしい手続きを排除していたのだ。

また、家族との LINE 以外、ほぼ何もできない端末だったので、悪用される心配がないだろいうというのもあった。


しかし、今後は「長男の端末」だ。メールなどを使うこともあるだろう。

セキュリティはしっかりしたほうがいい。


まぁ、データ専用 SIM なので電話はできないのだけど。

(LINE での音声通話は可能)




さて、今までは BIGLOBE 1Gbyte/月 が 1400円。DMM 1Gbyte/月 が 1260円だった。両方音声 SIM。

合計で 2660円。


これを、BIGLOBE 3Gbyte/月に変えると、1500円。

通信容量シェアの SIM が、音声は月額 900円、データは 200円。

合計で、2600円。


月額料金が安くなったのに、データ SIM が一枚追加された形だ。

通信容量はシェアするようになったが、1枚当たり 1Gbyte 使ってもよい、というのは変わらない。


(今までも 1Gbyte 使い切ったことはないので、誰かが多少使いすぎても問題は出ない)




もっとも、MNP 転出、新規 SIM カード発行の手数料などはかかっている。

乗り換えで得をするのには、2年は使わないとならない計算。


(新規発行する子供の分は考えないとして、

 MNP 転出手数料 3000円、SIM カード追加手数料 3000円、準備料 394円。


 音声追加 SIM は月額 900円だけど、プラン変更で +100円かかるので、月額1000円上がる。

 これに対し、DMM は 1260円だったので、月額 260円しか得にならない。


 6394円を260円/月で割ると、24.6 月。2年間使わないと元が取れないことになる。

 まぁ、「子供回線の確保」という目的もあるので、単純に金額だけの問題ではないのだけど)



▲目次へ ⇒この記事のURL

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

家族

別年同日の日記

09年 テレビゲーム

11年 ピューロランド

14年 日本がメートル条約に加入した日(1885)

18年 イグニス納車

18年 イグニス練習


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

Google Asistant  2019-09-24 13:41:02  コンピュータ 歯車

▲目次へ ⇒この記事のURL

以前に「P30 で、アラーム後の Google Asistant Routine が動作しない」と書いた。


昨日、アラームをセットしようとしたら、Google Asistant の設定画面が表示された。

あら、急に使えるようになったみたい。


Huawei の OS アップデートは、最終更新が8月後半で、OS のバグが治った、ということではないようだ。

Google Asistant をアラーム後に呼び出す機能は、Google 製の時計アプリの機能なのだけど、こちらの最終更新は7月24日のようだ。


…つまり、本当になんで急に使えるようになったのか不明。


心当たりは、「P30 に最近乗り換えたけど、なぜか Google Asistant 設定画面が表示されないよ」って、バグ報告を先日送った、ということくらい。


Google Asistant は、ネットワークと連携して動作する機能で、一部の設定はネットワーク側にある。

もしかしたら、ネットワーク側の個人設定がおかしくなっていて、バグ報告を受けて設定を修正したのではないかな…と思っている。




まぁ、なぜ表示されなかったのか、なぜ表示されるようになったのか、本当の原因はわからないが、動くのはありがたい。


朝、アラームで目を覚ました後に、今日の予定を喋ってくれるのは、忘れっぽい僕にとっては非常にうれしい機能なんだ。



▲目次へ ⇒この記事のURL

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

歯車

関連ページ

P30 買った【日記 19/09/06】

別年同日の日記

03年 そういえば

13年 みどりの窓口開設日(1965)

15年 パラケルスス 命日(1541)

18年 運動会


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

スパルタかます  2019-09-19 09:45:32  コンピュータ

▲目次へ ⇒この記事のURL

スパルタかます、をご存じだろうか。

知らない? では、「スパルタカス」ならどうか。


…いや、知らなくても何も問題ない。



スパルタカスは、アップルが創立20周年記念で発売した、特別仕様の Macintosh だ。


当時は、ノートパソコンは「持ち運べる」ようにするために、かなり無理をしていた。

デスクトップマシンとの性能差は明らか…ノートパソコンは「貧弱」だった。


一方で、液晶ディスプレイはまだ高価なもので、小さな筐体にすべてを詰め込む技術も高価だった。

つまり、ノートパソコンは高価な割に性能が低かったのだ。

(とはいえ、持ち運べるという特別な機能は、必要とする者には十分お金を払うに値した)



スパルタカスは、そんな時代にノートパソコンをベースとして作成された、デスクトップマシンだった。


不格好なブラウン管ディスプレイと、そのディスプレイを置ける「台」として使える大きなコンピューター筐体が当たり前の時代に、スマートな液晶ディスプレイと、板のように薄い本体を一体成型した、デザイン性の高いマシンだった。


このデザイン性の高さは、付属するボーズ製のサウンドシステムや、キーボードに付属する本革製のパームレストも含んだものだ。


つまりは、記念品だからと金に糸目をつけずに高級な素材を使用し、しかし肝心のコンピューターの性能は「1世代前のノートパソコン」(市販のノートをベースに設計しているうちに、世代が変わってしまった)で、値段の割に性能が低すぎるという問題を持っていた。



…と、それがスパルタカスなのだが、長々と話しておいて、「スパルタかます」とはそれほど関係がない。


スパルタかます」は、主に Apple 製品向けの周辺機器を作成していたサードパーティから発売になった、PowerBook (ノート型 Mac)向けの、「ノートを開いて立てておく台」だ。


スパルタカスは、ベースになったノートマシンから見れば、「ディスプレイを最大に開いて立てた状態」だった。

じゃぁ、そういう形で立てられる台があれば、似た使い方ができるだろう。


キーボード部分が垂直に近くなってしまうので、外付けキーボードを付けて使うことが想定されていた。

そうすることで、ノートパソコンのための貧弱なキーボードではなく、使いやすいキーボードを使える。



これ以前、ある時期の PowerBook は、「Dock」と言われる仕組みが使える機種があった。


ノートパソコンを持ち歩き、家に着いたら「Dock」を装着する。

すると、電源に接続して充電が開始されるだけでなく、ブラウン管ディスプレイと、外付けキーボード、マウス、イーサネットへの接続も行われる。


家にいるときはデスクトップのように使い、そのまま外出もできる。それが Dock の仕組みだった。



「スパルタかます」が発売されたころには、Dock 接続できる PowerBook はなかったように思う。

しかし、持ち運べるノートパソコンを、家ではデスクトップのように使いやすくしたい、という需要はあった。


スパルタカス、という当時話題性があった商品名をパロディ化し、キーボードを垂直に立てるという「厳しさ」を「スパルタ」と呼び、Apple が辞めてしまった Dock のコンセプトを取り戻そうとする。

そうした意欲作が「スパルタかます」だった。




翻って現代。


液晶は十分に安いものになり、デスクトップでも使用される。

回路製造技術は十分に進化したため、小さなマシンでも十分な性能を持つ。


むしろ、ノートマシンが標準で、デスクトップは「それ以上の性能を欲するもの」向けになりつつある。



しかし、ノートパソコンの弱点の一つが、ディスプレイ位置が低いことだ。

どうしてもデスクトップ用よりも小さく、低くなってしまい、使う人の姿勢が悪くなりがち。


そこで、ノートパソコンの下に取り付け、ディスプレイ位置を高くする「ノートパソコン台」という製品がある。


ノートパソコンの下に空間を作れるため、冷却効果を謳う製品も多い。

ディスプレイ位置をわずかに持ち上げつつも、キーボードが使えるようにしている製品と、外付けキーボードを使うのを前提に思い切ってディスプレイ位置を上げてしまう製品とがある。




さて、数か月前に僕もノートパソコンを購入した。

今時デスクトップよりこちらの方が安い、という理由もあるし、最初は「家の中で持ち歩けたら便利そう」と思っていた。


しかし、案外持ち歩かない。

僕は仕事以外ではあまりPCを使わないし、仕事は集中しないとできないので、家族のいるリビングで…はとても無理だった。



じゃぁ、仕事場で使いやすいように環境を固めてしまおう。

WiFi を使わず、イーサケーブルを挿す。この方が通信が速い。


ディスプレイが低い、とは思っていたが、キーボードが斜めなのはどうなのだろう? と躊躇していた。


妻が「欲しい」とノートパソコン台を購入したので、少し使わせてもらった。

悪くない。しかし、妻の使っているものは持ち運びやすいよう軽量な分、剛性が低くて打鍵すると揺れる。



そこで、Amazon のレビューで「重いから揺れない」と評判の台を購入した。

いや、この台、メーカーの宣伝文句では「軽量で持ち運びに便利」となっているのだけど、皆「重さがいい」と評価している。


実際、打鍵しても揺れなかった。いい製品だ。




しばらく使っていたのだが、台の都合で奥行きが少し必要になる。


実は、前のマシンのディスプレイがまだ机の上に載っていて、奥行きが確保できない。

じゃぁ、少しディスプレイを横にずらして…


横にずらしたらディスプレイ全体が見えるようになったので、ついでに HDMI で接続し、デュアルディスプレイにしてみる。


お、便利便利。画面も広くなって悪くない。



…と思っていたら、前の画面の方がディスプレイサイズが大きくて文字が読みやすいので、ついそちらの画面ばかり使ってしまう。

これが「横」にあるものだから、首が横ばかり向いていて肩がこる。


うーん、じゃぁ、いっそのことこちらをメインディスプレイに…


そうすると、ノートパソコンのキーボードは使えないので、前のマシンのキーボードを持ってきて外付けしよう。




そんなわけで、現在その環境でこの日記を書いている。


前のマシンのディスプレイ、前のマシンのキーボード。

でも、横に新しいノートパソコンが置いてあり、デュアルディスプレイ環境になっている。


(ちなみに、「メインディスプレイ」には、外付け側を指定している。

 こうしておいても、ノートマシンだけ持ち出すと、自然にノートがメインになるから大丈夫)



こうなると、ノートを持ち出すたびに、外付けキーボードとマウスと HDMI とイーサネットを抜き差しする、というのも面倒だ。

PowerBook の Dock のようなアイディアが今でも復活してくれればと思う。


(いや、そういう製品を作っているメーカーはちゃんとあるのだけど、やはり特別な製品になってしまって高価なことが多い)





余談


書いていて思い出したのだが、昔はブラウン管ディスプレイは「位置が高い」という批判があった。


本を読むときに、目の前に高く掲げては読まない。

机の上に置き、視線を落として読むのが自然だ。その位置にディスプレイがなくてはいけない。


…そういう主張で、ブラウン管を机に対して斜めに「落として」見やすくするパソコン机、というものが市販されていた


この主張からすると、現在のノートパソコンの位置は、自然で読みやすい位置のはずだ。


しかし、位置が低いとそれに合わせて頭を下げようとしてしまい、姿勢が悪くなる、というのが、パソコン台メーカーの主張だ。



まぁ、実際は「人による」と思う。

昔の読書家は、本と同じように低い方が読みやすいだろうが、高い位置のディスプレイに慣れた、デスクトップからパソコンを使ってきた人にはノートは低い。


各自使いやすい位置を模索すればいいと思うけど、今のノートパソコン台の「逆」が、ディスプレイを斜めに収納できるパソコン机なのだな、と思った。




▲目次へ ⇒この記事のURL

別年同日の日記

13年 顔文字が誕生した日(1982)

15年 山内溥 命日(2013)

17年 母の誕生日


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

P30 買った  2019-09-06 10:55:03  コンピュータ 歯車

▲目次へ ⇒この記事のURL

スマホを買い替えた。

Huawei P30。今まで P10 plus を使っていたが、2世代後の後継機だ。


1世代が1年なので、2年目の買い替えになる。

結構高いので3年くらい使いたいところなのだけど、消費税増税前の駆け込み需要というやつだ。




P10 の前は Honor6 を使っていた。Huawei の別ブランド機種。廉価版だ。


乗り換えで Honor9 の購入を検討していたら、なぜか廉価版よりも、上位機種の P10 の方が安かった。

そこで P10 に乗り換えた。



が、その直後に妻も乗り換えることにした。

妻は以前は Zenfone2 Laser。これが持ちやすいサイズだったので同じくらいの大きさの機種を…

と思ったのだが、ちょうど画面が急速に大きくなった時期で、同じサイズがなかった。


調べると、どうも P10 は小さい部類に入ったので、妻が P10 を使いたいという。

そこで、僕はさらに上位機種の P10 plus を購入して乗り換えた。



その後2年使ったわけだが、妻が言うには、やはり P10 は大きくて持ちづらいそうだ。

小柄な女性の手ではしっかり掴めず、たびたび落とした。


致命的なのは今年の初夏で、落とした際にメインガラスが割れてしまった。



12月になれば2年になるので乗り換え時かなぁ…と思っていたが、消費税導入前に買ってしまえ、となった。




妻の乗り換えが主目的になったので、まず妻の使う機種から調べる。

それなりの性能があり、今一番小さい機種は…


SHARP の AQUOS R2 compact 一択だった。ほかの選択肢はない。

サイズは小さいが、最近流行の「狭縁」画面なので、画面サイズは今までとほぼ変わらない。

(いや、縦長になったので、表記上のディスプレイサイズ…対角は長くなっている)



僕の方は、P30 pro / P30 / Zenfone6 で悩んだのだが、P30 で。

この3機種の中では、一番軽かったから。


P10 plus でも、性能をおごった代わりに少し重かった。

これより重くなるのは、性能が良くても使い勝手が悪くなる。

P30 なら、十分な性能で軽い。




妻は「落とす」ことへの恐怖から、今回はストラップを付けられるケースを購入した。

以前はストラップを付けられるケースというと手帳型などになってしまい、「小さくて持ちやすいもの」という目的から逸れてしまっていた。


しかし、今は需要があるのか、ストラップ穴付きのケースが増えた。


僕もストラップ穴付きケースで。

Honor6 の時から、イヤホン穴に差し込んでストラップ付けられるようにする器具を使っていたのだけど、イヤホン使えないと不便なこともやっぱあるのよ。


(一応 Bluetooth イヤホンは持っているのだけど、有線が使いたいときもある)




周辺の話ばかりではなく、P30 の話もしよう。

すでに発売から半年たった機種だけど、まだ購入を検討している人もいるかもしれない。

何かの参考になれば幸い。


とはいえ、「何の違和感もなく乗り換えた」というのが正直なところ。

性能は上がっているのだけど、使用感は P10 plus と同じだ。



それは、P10 plus が十分に洗練されていたということでもあるし、購入後もアップデートで最新の Android バージョンを使えていたことにもよる。


加えて、Google のバックアップ機能により、初期起動時にすでに、P10 plus とほぼ同じ環境を自動構築してくれた。


「ほぼ」というのは、アプリによってはデータが回復できないから。

いくつかのアプリでは設定やデータも引き継げたが、例えば LINE などは、手動でも乗り換えが大変なアプリであり、自動ではやってくれない。



とはいえ、昔に比べて機種乗り換えの障壁は確実に下がっている。

乗り換えを気に全く新しい環境を構築してやろう…というようなことがなくて、拍子抜けでもある。




P30 は有機 EL ディスプレイで、ドットが光る。


念のため書いておくと、一般的な液晶ディスプレイでは、画面全体が光っており、そのうち暗くしたいドットを、液晶が遮って暗く見せている。


この際、液晶の透過率というのは「一番透過率が高いところ」でも結構低く、画面を十分に明るく保つために、バックライトはかなり電力を食う。


有機 EL は、ドット自体が光るので「透過率」のような影響はなく、光らせたい明るさに光らせる電力だけで足りる。

さらに、光らないところのために全体を明るくする必要もない。


そのため、有機 EL ディスプレイの方が、全体に消費電力が低い。



とはいえ、画面全体を明るくしていれば、やはり電力を消費する。

今までの Android のユーザーインターフェイスは、白地に黒文字を基本としてきたが、最近は「ダークモード」と呼ばれる、黒地に白文字を選べるようになっている。


そちらの方が明らかに消費電力が少ない、というので、そうしたモード設定を行う。

アプリごとに選べる場合もそちらに。


ホーム画面の背景も、落ち着いた暗い色合いにしておいた。

もっとも、僕は背景は暗めが好みなので、以前からそうした背景画像にしていたのだけど。




アラーム設定で、なぜか「Google アシスタントのルーチン指定」ができない。

P10 plus ではできたのに。


これは、アラームを止めると、Google アシスタントが起動する設定。

起動して、現在時刻、今日の天気予報、カレンダーに書かれた今日の予定…などを音声読み上げしてくれる。


これがとても便利で目覚ましに使っていたのだが、使えないのは残念。

もっとも、何か別の設定で有効になるのに、まだ気づいていないだけかもしれない。



#9/24 追記。

 この現象、その後なぜか唐突に修正されました





カメラ性能は非常に高いはずだが、P30 を入手してからまだ撮影するような機会がないので、十分に確認できてない。


とりあえず、ズームとマクロが利くようになったのは素晴らしい。

今までもズームはできたが、せいぜい2倍まで。

(撮影画素数にもよる。低解像度での撮影なら、ズーム倍率を上げられる。)


それ以降はデジタルズームなので、画質が荒れてしまう。


これを、ズーム専用のカメラを持つことで、5倍までズームできるようになった。


そして、マクロ専用のカメラも持っていて、すぐ近くのものを撮影できるようになった。

以前は、あまり近いとどうしてもピントが合わせられず、小さなものをとるときは「少し離れてズームする」のが一番良い方法だった。


近くでとるのと、遠くからズームするのでは、少し写真の雰囲気が異なってくる。

自由に撮影できるようになるのは楽しい。




指紋認証は、P10 plus に比べて遅くなった。


僕は P10 plus しか指紋認証を知らないのだけど、Huawei の指紋認証は他社よりも高速で、使い勝手が良かったそうだ。


しかし、それも良い指紋センサーを搭載していたため。

P30 では、画面に直接触れることで指紋認証をしている。


どうやって画面内で指紋を読み取っているのだろう…と思って調べた限りでは、有機 EL はバックライトがいらず、それなりの透過性(光を通す)もあるため、ディスプレイの「裏」からカメラで撮影しているようだ。


しかし、これが今までの接触型指紋センサーよりも遅いようだ。


P10 plus では「触れただけでロック解除された」のが、P30 では「指を乗せるとロック解除される」感じ。

触れると乗せる、の微妙な違い、お分かりいただけるだろうか?


さらに言えば、指紋認証がうまくいかない率が少し上がった気がする。

もっとも、これは指紋を登録しなおしたら認識率が上がったので、最初は新しい方式のセンサーに慣れないで、うまく登録できてなかっただけかもしれない。




指紋とは別に、P30 では顔認証も使えるようになった。こちらは非常に速い。

両方とも有効にしている場合、指紋センサーに手を置いた時点で、顔認証も同時に始めるそうだ。


そして、顔認証は指紋認証よりも早い。

スマホを机から持ち上げたときも(そういう加速度をセンシングした時も)、自動的に顔認証が働く。


そのため、使おうとして画面をのぞき込むと、もうロックは解除されている。


指紋認証の出番は、机に置いたままロック解除したいときだけだ。

そして、そういう場合は「指を乗せる」ような感じでの操作もしやすい。というか、すぐに慣れた。


そんなわけで、遅さはデメリットではあるのだけど、そのデメリットをカバーする仕組みは用意されていた。




思いつくままに書いたが、ファーストインプレッションとしてはこんな感じ。

そうそう、指紋認証を画面内で行うため、保護フィルムなどは貼らない方が良いのではないかと思い、購入していない。


Huawei は…全機種かは知らないけど、出荷時に画面に保護フィルムを貼ってくれている。

「出荷時の保護シート」ではなく、普通に使える保護フィルムだ。

(そして、その上から出荷時シートを張って箱に入っている)


ケースも付属するが、安い TPU (熱可塑性ポリウレタン)のものだ。

P10 / P10 plus はポリカーボネートのケースだったのだけど、TPU の方がクッション性があり、落下時の衝撃などから守れるからこちらにしたのだろう。


一方、TPU は黄変しやすい素材で、半年も使っていれば黄色くなってくる。

1年もたつと、硬化もしてくる。


まぁ、買い替え時の2年くらいまで使い続けても大丈夫なのだけど、かなり見た目は悪くなると覚悟した方がいい。


もう一つ問題があって、P30 はカメラ部分が出っ張っている。

おそらくは、カメラ性能を上げるため、光学部分に厚みが必要だったのだ。

(電子回路は小さくできるが、光学部品はある程度「光が移動する」空間が必要だ。)


付属のケースでは、カメラを保護するために、ケースのカメラ周辺部が盛り上がている。

そのため、机に置くとガタガタして安定しない。



先に書いた通り、僕はケースを別途購入した。

背面の広い部分はポリカーボネート、周辺部分は TPU のハイブリッドで、カメラ部分保護の盛り上がりはありつつ、ケース四隅にも同じ高さの「足」をつけて、机の上で安定する。

(同時に、この足はポリカーボネートが机に擦られて傷つくのを防ぐ)


TPU 部分は透明ではなく色付き。黄変してもそれほど悪い見た目にならない…と思いたいが、こればかりは時間がたたないとわからない。




▲目次へ ⇒この記事のURL

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

歯車

関連ページ

MVNOをMNP【日記 19/10/09】

別年同日の日記

04年 SWHインテリア打ち合わせ

12年 サーバー設定 2012夏

14年 続・6502は遅かったのか?

15年 X68k 復活


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

Nintendo DSi  2019-08-29 15:15:08  コンピュータ 家族

▲目次へ ⇒この記事のURL

我が家に(我が家的に)、最新のポータブルゲーム機がやってきた。


Nintendo DSi だ。


…まぁ、日記のタイトルでばれているが、長女が中古品を購入した。

ポータブル機としては、一番新しいものになる。




これまでは、PSP と DSLite あたりが最新だった。

PS Vita / 3DS 世代は買っていないから。



長男は、2012年の誕生日プレゼントとして「ポケットモンスター ブラック2」を入手している。

このころは、DS が最新機種だった。



1年くらい遊んでいたが、その後遊んでなかった。

難しくてやめてしまったのかな、と思って聞いたら「とっくにクリアして、その後も遊んでいたのだけど、さすがに飽きた」とのことだった。


(友達とポケモン交換とかしないの? と聞いたら、当時の友達は「家にあった古い機械で」遊んでいる子が多く、最新のポケモンで一緒に遊べる子がいなかったようだ)



その後…たしか、2016年頃だったと思うが、長女もポケモンをやりたい、と言い出して、中古の「ホワイト2」を購入。

家には僕と妻の分、2台のDSがあったので、一緒に遊べていた。




長女の希望で、Switch の「ピカチュー イーブイ」を購入したのが今年の頭ごろ。

(代金は長女と次女の折版。ちなみに、イーブイを買った)


で、遊んでいて思い出したのか、DS版も再び遊び始めたのが数か月前。



僕のDSは発売と同時に買ったもので、少し前から調子が悪かった。

液晶の下の方が、数ライン表示されない。


それが、先日ついに「急に電源が切れる」という症状に見舞われるようになった。

電池の寿命ではなく、何やら電源周りの回路がおかしい模様。

AC アダプターにつないで遊んでいても切れてしまうから。



で、話が長くなったが、長女が「自分で新しい DS 買う」と決断したのだ。

以前から、今なら中古で3千円も出せば買えるよ、と教えてあったので、お金をためていたらしい。


「手元にある程度残しておきたいので」、余裕を持った金額を目標にしていて、もう少し後に買おうと思っていたらしい。

でも、今すぐでも買えなくはないので、「今すぐ買いたい」という。




急遽、家の近所の HardOFF に行ってみることにした。

というのも、以前ジャンク扱いで、付属品一切なしのDSを千円程度で売っていたのだ。


ACアダプターなどは家にあるので、それを使えれば掘り出し物だ。


でも、 HardOFF なので、事前にどういう店か説明。


自分で動作確認できるコーナーがあって、納得すれば買えばいいが、保証はない。

しかし、お店側もそれによって人件費を節約できるので、非常に安い。


とはいえ、そこに何があるかは時の運なので、今日行っても、目当てのものがあるかはわからない。

などなど。



そして納得の上で HardOFF に行き、ジャンクコーナーへ。

…あれ、以前はある程度置いてあったジャンクの DS が、一切ない。

3DS ばかりになっていて、ジャンクでもさすがに高い。


DS は古くなりすぎてジャンクでも扱わなくなったのかな、残念…。

まぁ、今日すぐは無理でも、ネットで安いのを探して買おう、と長女と話し合って、納得してもらう。



さて、この日は次女も一緒に来ていた。

次女も「一緒にポケモン遊びたい」というので、ブラックかホワイトを買いたいのだそうだ。


中古ソフトコーナーに移動。ブラックもホワイトも置いてあった。

どちらにしようか悩む次女。


…で、僕はその横にあった周辺機器コーナーを見ていたら、DS LL が3千円で置いてあった。


あ、なんだ。こっちにDS置いてあるじゃん。


そう思って別のところを見ると、いくつかDSの「付属品ナシ」も置いてあった。

そちらは1200円ほど。これなら長女でも手が出そうだ、と思って状態の良いものを探してみる。



すると、DSi の、ACアダプタ・タッチペン2本付き(つまり、箱・取説はないが付属品はある状態)が、千円だった。


え? なんで? 安すぎる。




少し考える。

DSi は、DS にあったアドバンス用のスロットがない。

つまり、後方互換性が切られている。


代わりに、インターネットからダウンロード販売ができるようになったが、そのサービスはもう終了している。

つまり、新サービスは受けられず、旧ゲームは遊べない。


それで安い…のか?


1200円 DS は、付属品はないが「動作確認済み」と書いてある。DSi は書いてない。

もしかしたら、ジャンク扱いで安いのかもしれない。


長女を呼んで、考えられるメリット・デメリットを説明する。

うちにはアドバンスはあるので、アドバンスのゲームが遊びたければアドバンスで遊ぶ。


というわけで、DSi のデメリットは特にない。


あとはこれがジャンクでなければ欲しい、というので、カウンターに行って「動作確認してもいいですか?」と聞いてみる。


店の人は、快く「いいですよ」と言ってくれた。


で、安すぎることと、ジャンク扱いですか? と聞いてみたが、周辺機器コーナーに置いてあるものはジャンクではなく動作確認済みだという。


話をしながら動作確認したが、問題なく動く。

DSは開いてみないと内部がわからないが、液晶などもきれいでドット欠けもなく、使用感もあまりない。

美品と言ってよい状態だった。



で、お店の人曰く「おそらく、店の誰かが値段をつけ間違えたんでしょうね…」と。

通常なら、少なくとも3千円以上ですね、と言っていた。


その言葉を聞いて不安そうな長女に気づき「もちろん、この値段を付けたのですから、この値段でお売りします」と。



これで長女は購入を決めた。

良い掘り出し物だった。




次女もホワイトを購入。

本体より高い、1200円。


これが、前の人がやっていたデータが残っていたのだが、レアポケモンが多数残っていた。

とりあえず、長女が延々とポケモン交換して、長女のソフトの方にデータを救い上げてからリセットした。



長男は「DSもう一台買ってくれば3人で遊べたのにー」と言っているので、掘り出し物だったから2台はない、と言っておいた。


そうしたら、電源ケーブルなしで1200円なら買おうかな…と検討し始めたようだ。




最後になるが、HardOFF の店員さんとの話に戻る。


本体とソフトをそれぞれ動作確認してから購入していたので、やりながら話をしていた。

もう古いゲームだけど、兄弟3人で遊びたくて今から中古ソフト買ってます…という話をしたら、心底羨ましがっていた。


一人っ子なので、兄弟で同じゲーム遊んだ、とかの経験はないそうだ。

兄弟でポケモン交換とか、仲良くてうらやましいと。



本当に、仲の良い兄弟に育ってくれて、親としてもうれしく思っている。


▲目次へ ⇒この記事のURL

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

家族

別年同日の日記

13年 次女発熱

16年 マイケル・ジャクソン 誕生日(1958)


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

SVG うねうね  2019-08-22 18:26:55  コンピュータ

▲目次へ ⇒この記事のURL

前回日記に書いた、仕事で必要なリアルタイムの絵の生成の話。


Canvas で生成したり、CSS でアニメーションしたりするのは以前からよくやっているのだけど、SVG でアニメーションする必要があった。

これが僕にとっては未知の技術だったので、今回のデモでは「あらかじめ作った絵でごまかす」を選んだのだった。




SVG でアニメって、SMIL とかいう技術を使うんだよな…と思っていたら、今は SVG + CSS Animation もできるらしい。

僕の知識がすでに古かった。


で、やりたいことを CSS Animation でやってみたら、できなかった。

CSS だと、単純な移動とかはできても、path を動かしたりは融通が利かない。

(アニメ自体はできるけど、制御が利かずに思ったようには動かない)


じゃぁ、SMIL ならできるのか、と調べると、こちらも単純な移動程度。


結局、1コマづつ画像を生成して、連続表示するという泥臭い方法をとるしかないことを知った。



仕方なく泥臭い方法で作ったら、思い通りに動いた。

思ったよりは簡単だった。


作ったのは、データに応じてリアルタイムに動く円グラフと、棒グラフと、ベジェによる曲線グラフ。




SVG 、今までややこしそうで避けていたのだけど、理解してみたら便利だな。

回路図程度なら、画像を描くよりも SVG で入れてしまった方が楽かもしれない。



▲目次へ ⇒この記事のURL

別年同日の日記

04年 大忙しです

13年 国立科学博物館

17年 夏の家族旅行 2017

17年 下田海中水族館

17年 とうてんぽーる

17年 アニマルキングダム・動物園エリア

17年 アニマルキングダム・遊園地エリア

17年 アニマルキングダム・2周目~帰路


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

ひといき。  2019-08-20 10:53:14  コンピュータ

▲目次へ ⇒この記事のURL

前回の日記に書いたように、知人の会社の手伝いでプログラムを作っている。


前回の日記は、先々週の週末の話だった。

その後、先週いっぱいは激しくバグ報告、新機能追加、細かな調整が行われて忙しかった。



「とにかく間に合わせたいので見た目だけできていればいい」と言われて作った機能が、見た目だけ整えたら「中身がないんだけど」と言われたりとかね。


いや、見た目でいいって言ったじゃん、というと、「そういったんだけど、見た目ができたら欲が出てきた」とかって。


時間が許せば要望の機能は入れたし、時間がなくてもそれらしいものは作った。


「そのうち作りたいね」と言っていた大きな機能追加があって「やっぱデモに入れたい」とか急に言われたのを3時間くらいで作ったのが最大の山場。


いつか作りたいといっていたので、処理概要は考えてあったのだ。


その時点で画面仕様書もなかったので、「作ってみたいのがあるから、とりあえず任せろ」と、思うままに作らせてもらった。

結果、知人が想定していた以上のものを作ったらしい。一発OKとなった。





で、今週はバグ報告待ち。一息ついている。


昨日は夕方になってから「やっぱほしい」という機能追加の要望が来たが、数時間で終わる内容。


実のところ、今回作成している内容で、一番「作るのが大変そう」な部分は、作るのを諦めてしまった。

リアルタイムに絵を生成しないといけないのだけど、とりあえずあらかじめ用意した絵を表示するようにしたのだ。



デモに間に合わせるのはこのままでよいとして、リアルタイム生成のための研究など始める。

何とかなるだろう、という手ごたえは得る。




なんのシステムを作っているのか、書いてもよいのかな、とも思うのだけど、とりあえず書かない。

以前口頭で知人から「宣伝してもらって一向にかまわない」と言われていたと思うのだけど、一応企業秘密に属するものだと思うから。


そのうちお伝えできればと思う。


▲目次へ ⇒この記事のURL

別年同日の日記

06年 サーバー交換


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

プログラム合宿  2019-08-13 10:55:35  コンピュータ

▲目次へ ⇒この記事のURL

いや、全然合宿ではないのだけど、そんな雰囲気だったので。



現在、会社員時代の知人の興した会社の仕事を手伝っている。

近日中に、商談で開発中のシステムを見せる必要があり、現状の機能のままでよいので見た目の完成度を高めたかった。


そこで、知人の発案で、知人の会社(小さな部屋を借りているだけ)に関係者が集まり、集中的に作業をすることになった。




関係者、といっても、企画者である知人と、プログラマーの僕、グラフィックデザイナー、サウンドクリエイターの4人だけだ。


事前に、金曜日に「集まる」としていたのだが、木曜日の朝から変更したい要望リストが上がり始めた。


文字列の変更なんかは簡単だが、中には大きな機能追加もあった。

そんなもの、金曜日だけで急に作れるわけがない。


そんなわけで、木曜日はこの要望リストを片っ端から潰していく。

簡単なものから潰していき、ある程度片が付いたところで難しそうな課題に挑む。


こういう時は、あまり考えていてはだめだ。

最初に「こうすればよいのではないかな?」と直感で思ったものを作ってみる。

うん、見事に動かない。




動かないなら、なぜ動かないのかを探る。


現在僕が作っているシステムは、古いシステムを新しいフレームワークで「作り直した」ものをベースにしている。


古いフレームワークは、いろいろな諸事情があり捨てなくてはならないのだ。

わざわざ「作り直し」をしているのは、そのためだ。


そのうえで、新機能の追加や、わかりにくい部分のUI(ユーザーインターフェイス)改善など、様々な課題があった。

しかし、いっぺんにすべてを進めるとわけがわからなくなり、失敗する危険がある。


そこで、過去のしがらみを捨て、必要な機能だけのミニマムセットの移植をまず行い、その後拡張を行うことになっていた。



この、単純な移植作業は別の人がやってくれた。

ただ、その人はその移植作業までで契約が終わっており、僕が知人から拡張を頼まれた。


そんなわけで、僕はシステムを完全に把握してはいない。

しかし、どんな処理がどこに入っているか、程度の概要は把握できている。


そこで、ソースを見て、動くと思ったプログラムが動かない理由を考えるのだ。




なるほど、少し考え方に間違いがあったようだ。


僕はいま、新規データが追加されたときの処理を作ろうと思い、プログラムを見ていた。

すると「不要データが削除されたとき」や「データの書き換えが行われたとき」の処理があり、それらの際にシステムから一定の方法でイベントが渡されることを知った。


新規データの時も同じようなイベントが来るだろう、と思って作ってみたら見事に動かなかった。

そして、プログラムを見た結果、新規データだけは全然違う形でイベントが渡されると知ったのだった。


では、そのイベントを受け取るように変えよう。

少し試行錯誤してデータの型合わせをする必要があったが、プログラムは狙い通りに動いた。



こんな作業を繰り返しながら、知人が出してきた要望を片っ端からシステムに作り込んでいく。




さて、木曜日の夕方までに出された要望は、木曜日の深夜までに全部盛り込んだ。

UIの見た目の調整などはあるだろうが、それは些細な問題だ。



金曜日、朝から知人の会社に出向く。すでにデザイナーの人は来ていた。


そこからが合宿の開始だ。


すでにデザイナーさん向けへの要望も木曜日のうちに出ていた。主にUIで使用するアイコンの修正などだ。

的確な指示もあれば、「どうすればいいかわからないけど今のものは問題がある」というような指示まで、多岐にわたる。


デザイナーさんは、すでにいくつかの案を考えてきていた。

いくつかにはさらに要望が出され、すぐ使えそうなものは僕にデータが渡される。


僕はそれらを組み込み、UIとしての見た目を確認していくわけだが、ここで「思ったより良くない」などのダメ出しも出る。


デザイナーさんが直し、僕が入れる。

この作業をしている間にも、僕の方にも要望が出てくるのでプログラム修正も必要だ。




知人とは、ゲーム会社に勤めていた時代からの付き合いで、こういう作業を共に…1か月ほど繰り返したことがある。

ゲームって、普通は少なくとも3か月かけて作るのに、締め切りの都合で1か月で作ったことがあるんだよ。

その時は、毎日「アイディアが出たらすぐ実装、確認してブラッシュアップ」の繰り返しだった。


なんだか懐かしい雰囲気だ、というと、デザイナーの人も今は独立して一人でやっているが、会社員時代はこんな雰囲気だったと言い出した。


そして、全員が「こういう雰囲気は嫌いじゃない」と。勢いに乗って、製品の完成度が高まっていくのは楽しい。




午後からはサウンドの人も加わった。

実は、サウンドが一番要望を伝えにくいもので、顔を突き合わせながら出ないと良いものができない。


以前に、使用するサウンドをいくつか作ってもらっていたのだが、実際にシステムに組み込んだところは聞いてもらっていなかった。

そして、実際組み合わせて鳴らしてみると「思っていたのと違う」ことになりやすい。



通常、多くならされる音と、特別な時になる音の「音色のバランス」が問題だった。

音量の問題ではなく、音色の問題として、特別な音がほかの音に隠されて気づきにくい。


もっと特別感のある音を、という要望で、サウンドの人が音色を調整する。


実は、複数の音を入れておいて、キー操作で切り替えられる仕組みを、事前に作り込んでおいた。

これで、いろいろな音の組み合わせを試してみる。

その結果を受けて、さらに音が作り込まれる。



これを何度か繰り返す間に、急に「これだ」という瞬間が訪れた。

全ての音がきれいに はまった感じがしたのだ。



サウンドの件はこれで終わり。

この作業で2時間くらいかかっていて、この間もグラフィック調整も行っているし、プログラムの追加なども行っている。




夜八時半。

サウンドとデザインの調整はほぼ終わり。


プログラムはまだ積み残しがあるが、これは後日(今週だ!)やることにして終了する。


普段は一人で働いているので、こんなに激しくプログラムしない。

会社員時代はこれを当たり前にやっていたわけで…


毎日やっているとつらいんだけど、久しぶりにやる程度なら、充実感があって、なかなか楽しいものだった。



▲目次へ ⇒この記事のURL

別年同日の日記

02年 音楽な1日

14年 電子メールの誕生日(1982)

15年 人材交換

18年 夏祭り


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

パスワードの管理方法(令和元年版)  2019-07-14 11:47:37  コンピュータ 歯車

▲目次へ ⇒この記事のURL

5年も前に書いた記事に、ご意見をいただいた。

記事の間違いを指摘してくれたものだ。


以前からたびたび書いているが、僕は自分の知識が正しいとは思っていない

5年も前の記事なら状況も変わっているだろうからなおさらで、こうした指摘はありがたい。


しかし、今回に関してはどうもご指摘がおかしいように思えた。

最新の情報では変わっていたりするかも…と念のため調べたが、今でも僕の書いた記事は有効なようだ。


どうも、ご指摘が勘違いからくる誤りのようだが、一人ご指摘をくれたということは、それ以上に多くの人が同じような勘違いをしているように思う。

そのため、過去の記事の内容を解説し、指摘がどう誤っているのかを記しておく。




まず、過去記事の概要。


パスワードは紙に書いてはダメで、すべて記憶するのが正しい、と思っている人が多いことに対して、その間違いを指摘した記事だ。

(これも5年前の話なので、今でもこう思っている人は減っている、と思いたい)


パスワード管理する上で、重要なのは


・サイトごとにすべて変更する。

・ほぼランダムに見える文字列を使う。

・時間的にも時々変更する。


の3点で、これらの決まりを守ろうとすると、パスワードを記憶する、というのは難しくなる。



そのため、20世紀には、「パスワードは紙に書かず、記憶するのが正しい」とされた時代はあるが、現代においては紙に書くのは悪い手段ではない、と解説したものだった。



これに対して、いただいた意見は「時間的な変更」をやってはならない、とするものだった。

時間的に変更することを促すと、パスワード管理が雑になり、セキュリティが弱くなる、という指摘だった。




この指摘は、2017 年に NIST (米国国立標準技術研究所)が勧告したパスワード管理方法を踏まえたものだろう。

僕の記事は 2014 年に書かれたもので、情報が古くなり意味を失った、と捉えることもできる。


NIST は、米国政府関連で求められる認証方法について、時代に合わせて適切なセキュリティ強度を保つための勧告をまとめている。



2017 年の報告では、パスワードを設定する際のユーザーインターフェイスなどについてもまとめている

ここには「パスワードの変更を強要すべきではない」という趣旨が書かれている。



これを受けて、国内でも総務省が「安全なパスワード管理」という呼びかけページを作成した。



ここに、パスワードの「定期的な変更は不要」と書かれている。


これがちょっと問題ありで、見出しに大きな文字で「定期的な変更は不要」と書かれてしまった。

内容を読むと、変更が不要なのではなく、「パスワードの定期的な変更を要求すべきではない」と書かれている。


この内容自体、 NIST の勧告に基づくものだ、と書かれていて、趣旨も同じだ。

あくまでも「変更の要求」に問題があるとするものだ。


しかし、見出しに「定期的な変更は不要」と書いてしまったために、多くの人が勘違いしてしまった。

新聞報道などでも「パスワードは変更しない方が良い」として広まってしまった。




NIST の勧告はセキュリティのためだけではなく、ユーザーの利便性を考えて「システムによる行き過ぎた規制」を緩和しようとしているものだ。


パスワード変更を強要すべきではない、という文脈には、「異なる文字種の混合を要求したりしてはならない」というものも入っている。


異なる文字種…数字、大文字、小文字、などだ。

この3つを、それぞれ少なくとも1つ以上は使うように求めるシステムは結構多い。

それらを混ぜることで、セキュリティが高まると期待しているのだ。


しかし、NIST はこれを禁じている。

ここにあるのは「ユーザーに不便を強いるな」という意図であり、セキュリティ強度とは無関係の話だ。


(一応、文字を混ぜても期待するほどセキュリティ強度は上がらない、という解説が巻末についているけど)



以上のように、NIST 勧告の「時間的な変更をやってはならない」は、システムに組み込むべきではないという指針だ。

それに対し、僕が過去記事に書いたのは、各ユーザーが自発的にとるべき、パスワード管理の心得を書いたものだ。


これらは全く性質の異なるものだ。



しかし、今回いただいたご指摘は、これを混同したものだった。

異なるものを混同し、「パスワードを変更してはならない」と考えていると、セキュリティ上のリスクを生じてしまう。




なぜ時間的な変化が必要かを示そう。


単純な話、パスワードはいつか破られる。

もちろん、攻撃側にその気があれば、の話だけど。



攻撃者がパスワードを知る方法なんて、いくらでもある。


たとえば、パスワードハッシュファイルの入手。

詳細は5年前の記事を参照してほしいが、攻撃者がパスワードハッシュを入手した場合、比較的「覚えやすい」パスワードなら、解明されてしまうだろう。


覚えにくい…ランダム文字列は、解明を遅らせることができる。

だから、「ほぼランダムに見える文字列を使う」という指針が入ってくる。



その一方で、キーロガーと呼ばれるような手段を使い、あなたが入力するパスワードを「直接」記録する方法もある。

この方法で奪われた場合は、キー入力がそのまま漏れてしまうため、文字列がランダムに見えるかどうかは関係ない。


あとは、パスワードが「漏れた」前提の話となる。


被害を最小限に食い止めるためには、そのパスワードが使える場所を限定しておくことだ。


「サイトごとにすべて変更する」というのは、そのための指針となる。




では、最悪の状況、実際に被害が出たとしよう。

問題は、それがどのような被害だったか、ということだ。


「勝手に買い物」された場合は、身に覚えのない請求が届くので気づくだろう。

しかし、メールなどを覗き見られて生活を丸裸にされている場合には、パスワードが漏れたと気づくだろうか?


時間的に変化させる、というのは、こうした気づかない被害に対する防御策だ。


大規模なパスワード流出があった、というような状況では、世間的にもパスワードの変更が呼び掛けられる。

パスワードが「漏れたかもしれない」と思えば、変更しておくのが良いだろう。


が、ストーカー被害の場合は身近な人によるショルダーハッキング…あなたが会社の PC などを操作しているときに、後ろからパスワードを覗き見ただけ、などの可能性がある。


キーロガーすら使わない。パスワードは、漏れるときは本当に簡単に漏れる。

そうした状況では、自分のパスワードが漏洩した、と気づくのは難しい。



NIST では、「第三者のログインに気づくようなシステム」を構築することも推奨している。

そうしたシステムなら、パスワードが漏洩し、情報を覗き見られていることにも気づくかもしれない。


しかし、残念ながらそうではない WEB サービスが多い。


ここでの自衛策は、時々パスワードを変えることだ。

普段から時々パスワードを変える、という習慣を持っていれば、パスワードが第三者に知られたとしても、被害をある程度の範囲で食い止めることができる。


「時間的にも時々変更する」というのは、そのための指針だ。




ただ、ここでいう「変更すべき」なのは、ユーザー各自の裁量に任されていることに気を付けてほしい。


先に書いた通り、NIST は「変更を強制すべきではない」とするだけで、この件についてあまり触れていない。

しかし、「強制的にパスワード変更を促す」システムは弊害しかない、というのはセキュリティ専門家の多くの意見が一致するところだ。



定期的に変更すべき、と言われて自主的に変更するユーザーは、セキュリティ意識が高い。

当然、変更の際にも妥当なパスワードを設定するだろう。


しかし、特にセキュリティ意識がなく、パスワードを「面倒だけど設定しないといけないもの」程度にしか思っていない人の場合、頻繁に変更を繰り返すと、覚えやすい単純なパスワードに収束していく傾向がみられる。


変更しろ、と言われたから、最初は 1234 に。次は abcd に…という具合に。

最初の設定ではそれなりに強度のあるパスワードを使っていたとしても、より弱いものに変えさせる「強制」は、百害あって一利なしだ。


(ちなみに、NIST の勧告では、abcd や 1234 といった「連続文字」パスワードは設定できないようにしなくてはならない、と示されている。

 これらは、ユーザーの利便性を最大限に考慮したうえでも、設定されるべきではないパスワードだ)



過去の記事に指摘をくださった方が「時間的な変更を促すと、パスワード管理が雑になる」と言っているのは、このことだろう。


同じ「時間的な変更」であっても、システムが強制するのと、ユーザーの自発性に任せるのとでは意味が違う。

この二つを混同してはならない。



強制はしてはならないが、時間的な変更はされるのが望ましいのだ。




話はこれで終わりだ。


NIST 勧告の「変更を強制すべきではない」はずいぶんと勘違いされていて、パスワードを変更してはならないのだと思っている人が増えているようだ。


強制すると雑になるから、というのは、ご指摘の通りだと思っていい。

多くの専門家がそう指摘している。


また、NIST 勧告では書かれていないものの、「わざわざ書かないだけ」で、前提にしている気がする。



一方、今回指摘を受けてネットを調査していたら、「パスワード変更の際に、変更しようとしているパスワードがネットワークを流れることになるから危険」と言う主張も見た。



変更自体が危険なのだと思っている人は、こうした話を「裏付け」として信じてしまうかもしれない。


しかし、たいていパスワードは暗号化通信(SSL)を使って通信されるから、覗き見られることはない。


「暗号化も破られるかもしれない」という前提に立つのであれば、ログインするたびに通信されるパスワードのほうが、変更のために1度だけ入れられるパスワードよりも、ずっと危険性が高い。


この危険度を下げるためには、同じパスワードでログインされる回数を減らせばよい。

つまり、時々パスワードを変更すべきだ。


結局、「変更の危険性」を主張しようとして変な前提を持ち出しても、むしろ変更すべきだという話になる。




さて、以下は余談。


わずか2週間前に、セブンイレブンが新しい電子マネーである「7pay」を導入しようとして、大失敗をやらかして、炎上した。


最大の大失敗は、システム側でのパスワード認証が「ざる」だったことだ。


本人の生年月日を答えられれば、任意のメールアドレスに対してパスワードの再発行を要求できる、というシステムがあり、生年月日を設定していない場合の日付初期値が固定だった。


このため、アカウントの ID さえ割り出せれば、高確率でパスワードを奪い取ることができた。

そして、ID は特に秘密ではない情報だった。


記者会見に応じた 7pay 社(セブンイレブンの子会社として電子マネーの会社が作られた)の社長は、報道記者から「なぜ二段階認証を使っていないのか」と質問され、「二段階認証って何ですか?」と基礎知識がないことを衆目にさらした。



パスワード管理の話としてはどこから突っ込んだらよいのかわからないところだが、二段階認証の説明をしたい。

すでに使っている人は多そうだが、これが何を目的としているのかちゃんと認識している人は案外少ないように思う。




二段階認証は、「パスワードは第三者が簡単に盗めるものだ」という前提に立っている。

簡単に盗めるから、 ID とパスワードの組を知っているから本人、とは単純に認証できない。



一方で、現代では、多くの人が携帯電話を持っている。

そして、携帯電話には電話番号がある。この電話番号は、本人と強く結びついたものだ。


そこで、アカウントに対してあらかじめ「連絡手段」としての携帯電話番号を登録しておく。

連絡手段があればよいので、固定電話やメールアドレスが使われる場合もある。



ID とパスワードの組での認証に成功した際、これは「第一段階」を突破しただけで、ログインにはならない。

ここで、「二段階目」として、サーバーから連絡手段を通じて何らかの情報(通常は6桁程度の数字)が伝えられる。


携帯電話番号に対してショートメッセージを送信、というように、この情報は「本人だけが受け取れる」ことが期待される。

そして、受け取った本人が情報をサーバーに伝え、正しい場合にやっとログインが完了する。



この方法は、


・本人にだけ伝えられる情報を利用するため、正しく本人であると確かめられる。

・万が一パスワードが盗まれた場合、本人に通知が行くため、パスワードが盗まれたことを知ることができる。


という2つのメリットがある。


特に後者は重要だ。


先に書いたが、パスワードが漏れて明らかな被害にあえば、パスワードを再設定するなどの対策がとれる。

しかし、通常は「ただログインされて情報を見られただけ」では気づかない。


二段階認証では、認証中に本人に通知を行うことで、第三者によるパスワード盗用が明らかになる。

これにより「見えない被害」を事前に「見る」ことが可能となるだろう。



ただし、大体のシステムにおいて、二段階認証は「オプション」扱いにすぎない。

携帯電話などを持っておらず「設定のしようがない」ユーザーもいるためだ。


そして、オプションを使わなければ、従来どおり、 ID・パスワードの組だけで認証が行われる。

認証自体は問題なく行われるため、二段階認証を使えるシステムであっても、これが何のためにあるのか理解できずに設定していない、という人は多い。


Google や Amzon, Facebook 、Apple、Twitter …etc,etc. 多くの有名サイトが二段階認証に対応している。

認証していないシステムでも、「Google アカウントでログイン」などが使える場合は、Google の二段階認証を「借りる」ことができる。


設定していない人は導入を検討してみてほしい。




しかし、実はこの方法での二段階認証は、強度的に十分ではないことがすでに分かっている。

SMS の通信文は「他人に奪われる」可能性があるのだ。



SMS は、電話番号に対して発信され、スマートフォンなどのデバイスで受け取られる。

しかし、スマートフォンに電話番号が割り振られているわけではない。

割り振られているのは SIM に対してで、この SIM は付け替え可能だ。


そして、スマートフォンは PIN などでロックをかけられるが、SIM 自体がロックされるわけではない。

ほかのデバイスに差し込まれた SIM に対して送られたメッセージは、簡単にみられてしまう。


つまり、ちょっとスマホを置いて席を離れた間に、別の人が SIM を自分のスマホに差し替え、2段階認証を突破してしまう、ということも可能なのだ。


パスワードも知らないと二段階目まで進まないわけだが、ここまであなたの近くに潜り込める人であれば、ショルダーハッキングでパスワードはすでに知っている、と思ってよいだろう。



これは、物理的に近づかないといけない例だが、技術的には特に難しいことはない。

技術的な例でいえば、スマホアプリは、ユーザーの許可さえ受ければ SMS の内容を読みだすことができる。


悪意を持ったプログラムを内蔵した、ごく普通のゲームなどに見えるアプリが SMS の内容を盗み見て送信する…ということだってできるだろう。

もちろん、そういうアプリは操作の一部始終を見ていて、どこかにログインしようとしたときに ID/パスワードの組も送信しているわけだ。



また、国内の例ではないが、海外では携帯電話自体の通信プロトコルの脆弱性を突かれ、本来の電話番号の持ち主ではない端末に SMS を受け取らせてしまう、という攻撃も行われている。


SMS は決して安全ではない、ということがわかってもらえるだろうか?



メールアドレスに対する通知でも同じことがいえる。

むしろ、こちらの方が簡単に奪い取れるだろう。


固定電話は…本当の意味での「固定電話」なら、電話線に対して電話番号が割り振られている。

変更するには電話局内での設定が必要で、通信を盗むことは難しい。


しかし、今は「固定電話」といっても IP 電話であることが多く、これは後から機器に電話番号を割り振っている。

やはり過信は禁物だろう。



サーバーから本人に対して、「安全な通信経路が確保できる」というのが、この方式での二段階認証の前提だ。

安全な通信経路が確保できない場合、安全ではなくなる。




では、通信を行わないで、認証する瞬間にだけ使用可能な、本人だけが知れる情報で、サーバーに侵入されても情報が漏洩しない方法で、サーバーと秘密を共有すればいい。

そんなことできるの? と思われるかもしれないが、ちゃんとそうした方法は考案されていて、一部の二段階認証では選択できるようになっている。


ワンタイムパスワード、と呼ばれるもので、仕組み自体は結構古い。

2006年…いまから13年も前には、すでにジャパンネット銀行が導入している。


先に「パスワードは時間によって変更したほうが良い」と示したが、それを究極まで突き詰めたものだ。

30~90秒で、自動的にパスワードが変更されてしまう。これなら、万が一パスワードが盗まれても問題ない。


パスワードが変わってしまうと、本人すらログインできなくなりそうだ。

しかし、本人だけが持っているデバイスに、変更されたパスワードが示され続ける。


だから、本人だけはログイン可能だ。



ここで重要なのが、パスワードを示すのに通信などは不要だ、という点だ。

サーバーとデバイスは、お互いに示し合わせることなく、次々とパスワードを変えていく。


しかし、それらは時刻を基にした一定の計算方法で示されるもので、デバイスとサーバーで一致している。

計算で示される…ということはランダムではないのだが、たとえ計算方法を知っていたとしても、「鍵」がなくては同じ計算が行えない。


そしてここが一番肝心なのだけど、計算のための「鍵」は、デバイスの中にしかない。サーバーにもない。

だから、万が一サーバーに侵入され、情報を盗まれてもパスワードを知ることはできない。


この鍵は、公開鍵暗号を応用したものだ。

公開鍵暗号は、「公開鍵」と「秘密鍵」のセットを使い、秘密鍵で暗号化した内容は公開鍵でしか元に戻せない。


だから、デバイスが秘密鍵を持ち、サーバーに公開鍵を預けておくと、デバイスが作り出した暗号が「確かに正しい」ことをサーバーは確認できる。


公開鍵は、秘密鍵を基にして計算で求めることができる。

しかし、公開鍵を基にして秘密鍵を割り出すことは事実上できない。


だから、サーバーに預けた公開鍵を盗まれたとしても、それを基に秘密鍵を求めてワンタイムパスワードを生成する、ということができない。



13年も前に導入されたジャパンネット銀行では、6桁の数値を表示できる専用デバイスを配布してワンタイムパスワードを実現している。




最近は、この方法を一般化した「時間ベースのワンタイムパスワード認証」が使われ始めている。


RFC 6238 で規格化されており、複数の会社が同じ動作を行うハードウェアやアプリを作成しているので、自分の好みに合ったものを使いやすい。


ただ、上にあげた、公開鍵暗号の応用によるシステムほどにはセキュリティが強くない。

上のシステムは、RSA 社が発明した特許品だから、金を払わずに同じ方式を使うことはできないのだ。



公開鍵ではなく、共有秘密鍵を使う。

ということは、万が一サーバーに侵入されれば、鍵は漏れてしまい、他者でも同じパスワードが生成できるようになる。


もし「疑いがある」時には、共有秘密鍵を変更することもできる。

通常は、サーバーにログインして操作し、ランダムな数値で更新させた秘密鍵を、手元のデバイス(スマホなど)で受け取る。


一般的には、QR コードなどで画面に表示する方法をとるようだ。



Google のアプリの場合、秘密共有鍵は「受け取り専用」なので、スマホを買い替えたりした場合は、サーバーに入り、鍵を更新して受け取る必要がある。


これに対し、同じワンタイムパスワード生成機能を持つ IIJ のアプリの場合、秘密共有鍵を QR コードとして表示する機能がある。

ということは、スマホの買い替え時などには、鍵を再発行することなく移行が可能だ。


これはとりもなおさず、第三者が秘密鍵を盗むのも簡単だ、という意味になる。

スマホ自体にちゃんとロックをかけておけば盗むための操作もできないはずだけど、どちらを使うかはお好みで。




ワンタイムパスワードの共通規格が普及しつつあり、2段階認証で使用できるサイトも増えている。

こうしたサイトが増えれば、パスワードを盗まれたとしても、簡単にログインされることはなく、被害は受けづらい。


しかし、現在のところ、こうした「安全な本人確認方法」に対応していないサイトは、まだまだ多い。


そうしたサイトでは、5年前の記事のパスワード管理方法は、依然として有効だ。

逆に、十分に安全なサイトで迄パスワード変更の手間をかける必要はない、ともいえる。



そうした安全なサイトが十分に増えて、パスワードなんて不便なものはなくなってくれればありがたいのだけど。



▲目次へ ⇒この記事のURL

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

歯車

関連ページ

パスワードの管理方法【日記 14/05/22】

別年同日の日記

02年 お祝い

07年 最近のうちの子

10年 這えば立て 立てば歩めの…

13年 海水浴

15年 ジェイ・フォレスター 誕生日(1918)

15年 厄介なバグ

16年 監視ユーザーの問題回避


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

google photos その後  2019-06-14 12:27:41  コンピュータ

▲目次へ ⇒この記事のURL

2日前に「Google Photos にバックアップする方法、ノートパソコンだとつらいなー」ってことを書いた。


で、その後調査していて、普通に Linux で動く Google Photos アップローダーを発見した。

なんでも、2018年5月…およそ一年前に Google Photos の API が公開されて、サードパーティ製のソフトも作れるようになったようだ。


で、使ってみたのだけど、満足するものではなかった。

画像を圧縮しないで、元画像のまま送り込むソフトだったのね。


他にも、EXIF がついてない画像…つけようがない動画なんかも、撮影日がアップロード日付になってしまうそうだ。


圧縮はソフトの問題かもしれない。


一応、ある程度送り込んだところで、Google Photos 側で「圧縮」処理してもらい、Google Drive 容量を開ける、ということもできる。



でも、日付は API に指定方法がないためどうしようもない、とのこと。


類似ソフトはほかにも発表されているようなのだけど、API がないのであれば他のソフトでも同じ問題は出るのだろう。



そんなわけで、やっぱり本命は Windows の仮想化か。

1つのソフトのために仮想マシンを用意して Windows インストールするとか、なんか間違っている気がするので、ほかの解決方法があるとありがたいのだけど。





余談。

いつものことだけど、余談のほうが長い。



冒頭にあげたアップロードツール、コマンドラインで動くのだけど、普通は GUIというか、X Window 必須です。


というのも、Google の認証が必要で、その部分は WEB ブラウザでないとできないから。

WEB ブラウザは、普通に考えると GUI がないと動かない。


流れとしては、


1) アップロードツール起動

2) 初回のみ、Google の認証が必要。URL が表示され、ブラウザでアクセスするように指示される。

3) ブラウザでアクセスし、Google の認証を通すと、その結果をツールが受け取って動作できる。


という仕組み。

一度認証を通せば、その認証情報はツールが保持するので以降は認証する必要はない。



僕は家庭内サーバーを完全 CUI で使っていて、Windows 上の Putty …端末ソフトで扱っている。


そこで、まず w3m をインストールしてみた。

文字だけで動作する WEB ブラウザだ。とにかく WEB ブラウザが動けば大丈夫そうだから。



ここで、実は操作を誤った。

文字だけになったら普段見ている画面と違うので、勘違いして別のリンクを押したのだ。


そうしたら reCAPTCHA 入力画面になった。

画像の中にゆがんだ文字が書かれていて、入力を求められるやつだな。


…テキストブラウザでは、画像が見えない。


どうしよう、と考えて、cacaview というソフトの存在を知る。

テキスト端末でもアスキーアートとして画像を表示してくれるソフトで、reCAPCHA の文字が読める程度には再現性もよい。


w3m はテキストブラウザとは言え、画像部分は外部ソフトに渡してみられるようになっている。

X Windows 環境で画像だけ別ソフトで開くことを想定しているのだけど、cacaview で開いたってもちろん構わない。


cacaview は CentOS なら caca-utils というパッケージを入れれば入る。



…で、さんざん苦労して認証を通して(やっぱ reCAPCHA 文字は読みにくく、何度も間違えた)、そのあとで「あ、これ違う画面だ」と気づいた。

本当に進みたかったルートではない。


本来進みたいルートに進んだら、あっさりと「Javascript が動かないので別のブラウザでお試しください」という画面になった。


w3m は Javascript が動かない。ダメだ。




しばらく考えて、サーバーに入っている nginx を使うことにした。


GooglePhotos のアップロードツールでは、localhost に対してアクセスを求められる。

そこで、nginx で適当な名前でサーバー公開して(もちろん家庭内だけ)、バックプロクシとして動作させて localhost にアクセスすればよい。


これで認証は通った。

最後に、GooglePhotos のアップロードツールに情報を渡すため、もう一度 localhost にリダイレクトされるのだけど、この部分で「localhost」ってことで、Windows にアクセスが行ってしまう。


まぁ、URL はわかったので、w3m でアクセスする。

これで認証が通った。




先に書いた通り、GooglePhotos アップロードツールは僕の求めていたものではなかったのだけど、この手順を踏めば、一切 X Window 環境なしに使える、本当のコマンドラインツールになる。


必要な人はお試しあれ。


▲目次へ ⇒この記事のURL

別年同日の日記

02年 眠り姫

06年 CSS

13年 びわ


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

Google drive バックアップと同期  2019-06-12 14:49:47  コンピュータ

▲目次へ ⇒この記事のURL

新マシンに移行した。


旧マシンはしばらく使わないつもりで置いておく。

引き揚げ忘れたデータとかが眠っているかもしれないから。

でも、たぶん引き揚げ忘れたデータが本当にあったとしたら、それは忘れる程度のデータなので消えても構わないと思う。


実は、半年ほど前に旧マシンに Windows を再インストールしており、その際に「移行しやすいように」データ整理をしていたので、移行はスムーズにいった。




でも、若干の予想外もあった。


我が家では NAS に家族の写真・ビデオをたっぷりとため込んであって、この NAS は重要なので外付けハードディスクに定期バックアップもとっている。


しかし、それとは別に Google Photos にも写真を送ってバックアップしている。

「画質が落とされるのでバックアップにはならない」という人もいるのだけど、上に書いたように十分なバックアップは取った上の話だ。


Google のものは、万が一火事などで機材一切が滅失した際に、思い出写真として見られるのに十分なものがあればよい、という程度と考えている。


で、問題はこの Google に対するバックアップだ。

Google Drive を扱うツールは NAS のプラグインや Linux にもあるのだけど、Google Photos で「無制限」に写真を送るためのツールは Win / Mac 版しか用意されていない。




ここらへんで説明が必要な人も多いだろう。

Google Drive と Google Photos は、シームレスにつながるサービスだ。


Google Drive はネットワーク越しにデータを預かってくれるサービスで、Google Photos は写真を預かってくれるサービス。

でも、Photos の保存領域は、実は Drive のものだ。


ただし、Photos では「十分に小さな写真」は、Drive の容量として計上しないことになっている。

だから、今く使えば容量無制限で写真をバックアップできる。



ここで「十分に小さな」というのは、過去に何度か改定されてきている。

最初は、2048x2048画素以内、とされていた。実際にはバグがあって、ぎりぎりサイズはダメだったのだけど。


Google は、当時は Google Picasa というソフトを Windows 用に配布していて、このソフトからアップロードすると、自動的に 1600px まで縮小してアップロードしてくれた。

(当時は、Google Photos ではなく Picasa Web という名前だった


のちに、Picasa は開発終了し、写真のバックアップだけを行う Google Photo Uploader が作られた。

そしてさらに、Google Drive バックアップと同期、というソフトに変わった。



同時に、保存できるサイズも大きくなってきている。

現在は「1600万画素、かつ 75MByte」までとなっている。4000x4000 なら、ちょうど 16000万画素なのでそのままアップロードできる。(75MByte の制限はあるのだけど)


ただ、この制限に適合するようにアップロードしてくれるソフト、「バックアップと同期」が、Windows / Mac 版しか作られていないのだ。




今までは、Windows 版のソフトを動かし、NAS をバックアップ元に指定して Google にアップロードさせていた。

今回もそれをやったら…これ、ノートにさせるような作業じゃないね?


今まではデスクトップマシンでイーサネット接続だったので、NAS から写真を取得して、リサイズして再圧縮して Google に送信、というタスクを動かしていても気にならなかった。


でも、WiFi 接続だとイーサより遅いし、WiFi の電波帯域は家族で共有しているので迷惑になりそう。

いや、イーサだって共有なのだけど、WiFi を使う機材とイーサを使う機材で棲み分けていた、という感じ。


(その WiFi はイーサにつながっているのだけど、一番通信量の大きい、僕のマシンと NAS の間、というのと、WiFi ステーションとネットワークルータの間、というのは、スイッチングハブによって切り分けられている)




ひとまず、ノートマシンにイーサケーブルつないで凌いでいるのだけど、どうにかしたい。

Linux サーバーはあるので、Linux から Google Photos にアップロードできればいいのだけど…と調べたのだけど、相変わらずそのためのソフトはない。


じゃぁ、Windows を仮想化してサーバーに入れるか。

幸い、メインマシンの Windows はライセンスを購入したもので、PC 付属の OEM ではない。


#PC 付属の OEM 版は、別のマシンで使用することは禁じられている。

 今まで使っていたメインマシンは、もともと Windows 7 マシンだったのだけど、8 にバージョンアップする際にライセンスを購入し、このライセンスは Windows 10 に無償バージョンアップされた。


Windows には「Hyper-v」という仮想化技術があるのだけど、これは実は Xen が開発したもの。

Xen は Linux で生まれた仮想化技術で、現在は KVM に引き継がれている、と考えて間違いない。


#Xen 自体はまだあるのだけど、今から使うメリットはあまりない。


うちのサーバーは KVM が入れてあるので、この上に Windows を入れることは可能だ。


実は、Google Drive 同期とバックアップは、外部の NAS のデータを送信する際は、Windows がスリープして NAS との通信が切断するたびに一時停止する、という問題がある。

まぁ、問題というか仕様なのだけど、仮想化サーバーに入れておけばこの問題も解決する。




というわけで、Windows 仮想化が本命だなーと思いつつ、じつはまだサーバーの整備が終わっていないし、旧マシンもしばらく置いておきたいのでライセンスの関係もあってすぐには仮想化できない。


サーバー整備は、去年から少しづつやっているもの。

Xen サーバーの仮想マシンを KVM に移行したいのだけど、この意向を簡単に行うソフトが曲者で、一筋縄ではいかないとわかってきたところ。


「単純だけど本格運用には不満がある」仮想化マシンなら簡単に移行させてくれるのだけど、本格運用を目指した設定のマシンだと移行できないという…

まぁ、本格運用を目指した、というのは標準的でない設定をたくさん使っているという意味であり、仕方がないことでもあるのだけど。



▲目次へ ⇒この記事のURL

別年同日の日記

02年 OSアップデート!!

05年 夏至祭

15年 生卵と生豚と

17年 連乗機能

18年 ゲームの作り方


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

新マシンセットアップ中  2019-06-09 23:38:37  コンピュータ

▲目次へ ⇒この記事のURL

新マシン…HP Pavilion 15-cs0000 が届き、セットアップ中。


なかなか人気マシンのようだし、まだ「使い勝手」が書けるほど使い込んでもいないのだけど、セットアップ時点で気づいた点を書いておこう。


まず、僕にとっては最悪ともいえる欠点から。

このマシン、タッチパッドに問題がある。


ELAN Clickpad と呼ばれる種別のものらしい。

Windows 10マシンらしく、複数の指を使ったジェスチャにも対応した、それ自体の使い勝手は悪くないものだ。


以前は、タッチパッドの端をなぞるとスクロール、という操作が流行った。

でも、ジェスチャなら2本指で動かせばスクロール。ほかにも指の数や動かす方向で、いろいろな操作が可能。


このジェスチャは Windows 10 標準のものだ。



ただし、ELAN Ckickpad では、細かな設定が一切できない。

不意にズームジェスチャが入ってしまうからいやだとか、タップするとクリック扱いになるのが嫌だとか、普通のタッチパッドではそうした機能を細かく ON / OFF してカスタマイズできるのだが、そういうカスタマイズ性が一切ない。


Windows の設定画面、デバイスから「タッチパッド」を選んでも、設定項目が出てこない。

どうやらここの設定項目はデバイスドライバの責任のようで、使用マシンによって項目が違うらしいのだけど、その設定項目が「感度」以外に何もない。


まぁ、今はセットアップ中なのでタッチパッドを使っているのだけど、常用し始めたら今メインマシンで使っているマウスを奪って新マシンで使う予定。手になじんでいるので。


それまでの辛抱だ、ということで、実は大きな問題ではない。



#ここから、翌日追記


なんてことだ!


ネットでいろんなところ見ていても、「ELAN は設定できない」みたいな書かれ方がしていたのだけど、プリインストールアプリの中に「ELAN TouchPad Setting」というものがあった。


Windows 標準の設定画面ではなく、このアプリを使うことで細かなセッティングができた。


2本指ジェスチャによるスクロールだけではなく、タッチパッドの端をなぞることによるスクロールにも対応している。

これなら、過去の別のマシンから乗り換えた人でも違和感なく操作できる。


しかし、このソフトでも設定できる「感度」だけは、Windows の設定画面でも設定できるようになっている。

ということは、ほかの設定も同じように「設定」画面で可能にして置き、より細かな設定はソフトで…などもできたはずだ。



非常に分かりにくいが、まぁ気づけば問題ないレベルなので、良しとしておこう。


#追記ここまで




画面がノングレア処理されていない、というのは思った以上に見づらいものだった。


ノートパソコンなのに、画面がスマホみたいにツルツルなのね。

スマホなら小さいから気にならないのだけど、画面が大きいので自分の顔が映り込んでいるのがよく見える。


これは、あらかじめ気にしていて、公式オプション品のノングレアシートを一緒に買ってあった。

公式だからと言って高いことはなく、同等品をアマゾンなんかで探しても似たような値段。

ならば、画面サイズに適切に合わせて切られている公式品を買った方がよかろう。


そして…そう、このシートは非常によく、画面サイズピッタリに切られている。

画面の端に合わせて綺麗に張ったつもりでも、最後が画面の枠にあたって、シートが浮いてしまうほどにピッタリサイズだ。


多分、0.5mm 程度の誤差しか許されないんじゃないだろうか。

幸いなことに、静電気と空気圧で吸着するようなタイプで、何度でも貼りなおせる。

そこは心配しないでいい。


そして、3回も貼りなおしたらさすがにホコリが入り、シートがピッタリ貼りつかなくなる。

何度でもはがせるので、ホコリの近くをはがし、セロテープでホコリを取ってやれば大丈夫。


苦労したが、最終的には綺麗に貼れた。



このシート、実際には必須だと思うだけど、価格競争のために少しでも安くするためと、生産現場で貼っていると案外手間がかかるのでシートなしで売っているのではないか、と思ってしまうほど。


#まぁ、最近は画面タッチ可能な機種もあるし、その場合は画面が傷つきやすいので、保護シートを自己責任で貼ってもらう方がよいのだろうとは思う。




キーボード。

感触は悪くない。配置にまだ慣れていないから微妙に打ち間違える、というのは慣れの問題だ。


しかし、キーボード刻印の文字が素晴らしく読みづらい。


キーボードはカッコいいメタリックな仕上げで、バックライト付きだ。

バックライトを点灯すると文字部分が光るやつね。


カッコいいけど、ノートパソコンとして使うには電池を少しでも節約したい、と思ってしまう。

もちろんバックライトは消せるのだけど、消すと先に書いたように読みづらい。


光が透過する部分は、灰色で半透明。半透明ということは、見る状況によって微妙に色が変わるということだ。

ここに、メタリックなキーボード。メタリックということは、見る状況によって微妙に色が変わるということだ。


この、微妙に色が変わる下地に微妙に色が変わる文字、というのが、周囲の明るさによっては致命的に視認性が悪い。


まぁ、キーボード打っているときは手が配列覚えているから、視認性悪くてもそれほど問題ないのだけど。




キーボードついでにもう一つ。


せっかくテンキーがついているのに、num lock のインジケーターランプがない。

なので、数字を入れようとしたカーソルが動いてしまう、なんてこともしばしば。


まぁ、こちらもインジケーターがあったとしても、案外見ていないものなのだけど。


普通は、起動時に num lock を ON / OFF どちらの状態にするかは、BIOS (今時は UEFI か)で設定する。

しかし、Pavilion の BIOS には設定項目がなかった。


(ちなみに、BIOS 起動は昔ながらの F1 や F2 ではなかった。

 shift 押しながら Windows を起動して、Windows の起動オプションからトラブルシューティング→詳細オプションを選ぶと、UEFI の設定がある。)


しばらく使っていて分かったが、どうやら「前回使っていた設定」で起動するようだ。

ということは、これは Windows 10 が制御しているのかな?



BIOS を見ていたら、Function キーをどう扱うかの設定もできた。


出荷時設定では、F1~F12 を押そうと思ったら、Fn キーと一緒に押さないといけない。

通常は、音量変更や画面輝度変更キーとして働く。これはまぁ、ノートパソコンなのでそんなものかな、と思っていた。


でも、設定を変更すると、通常は F1~F12 として働き、Fn キー併用で音量変更、のようにできる。

僕としてはこちらの動作が好みなので、設定を変えた。



キーには、音量変更などの絵が大きく書いてあり、F1などの表記は小さめに書いてある。

これが、先に書いたキーの文字が視認しにくい問題と併さり、どれがどのキーかわからない。


基本的には、数字キーの 1 の上にあるのhが F1 、9 の上にあるのが F9 、という認識でよい。

慣れてしまえば何の問題もなさそうだ。




というわけで、細かな文句はあるのだけど、どれも些細な事。

全体的にはよく出ていると思います。色々調べてそう思ったから買ったのだけど。


一応、ここに書いた「些細な事」は、僕が気になって、でもまぁいいか、と思った程度のことなのだけど、人によっては致命的かもしれないので、これから買う人の参考になれば、と思う。



そして、この文章は、新マシンで書いてみた。

セットアップするだけでなく、ちゃんと使ってみた最初の例だ。


▲目次へ ⇒この記事のURL

別年同日の日記

02年 最終戦略

05年 spring has come

05年 3ヶ月点検

13年 WEB上でのドット絵の拡大

16年 8086 発表日(1978)

17年 計算機の同人誌


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

Alexa Wunderlist 連携  2019-05-29 18:15:08  コンピュータ

▲目次へ ⇒この記事のURL

先日買った Fire HD 10 、Alexa が使えるのが思った以上に便利だった。

声で操作するって、最初は恥ずかしくて抵抗があったけど、料理中などには便利なものだな。


Alexa には「お買い物リスト」という機能がある。Amazon の買い物リストとは別物。

料理中に、ソーセージ使い切っちゃったな、と思ったら「アレクサ、買い物リストにソーセージ入れといて」って頼むと、すぐに入れてくれる。


でも、この買い物リストを家族で共有できない。

Alexa のお買い物リストは、Amazon のアカウントに紐づいていて、本人しか見られないのだ。




Wunderlist は、スマホで作ったリストを家族などで共有できるサービス。

類似サービスはほかにもあるのだけど、我が家ではこれを使っている。


類似サービスには、Alexa に対応していて、そのまま声でリスト追加できるものもある。

でも、Wunderlist は対応していない。


しかし、Wunderlist はメールに対応していて、メールを送ることでリストに追加できる。



さて、IFTTT というサービスがある。

技術的なことはさておき、「いろんな WEB サービスをつなぎ合わせるサービス」だ。


これを使って、Alexa の買い物リストに追加があったら、Gmail を使って Wunderlist にメールを出し、Wunderlist の買い物リストに登録する、という方法があることを知った。


Alexaに買いたいものを伝えて共有の買い物リストに追加


この手法は結構古いらしいのだけど、上のページが丁寧に説明しており、そのまま設定すれば同じことができる。


…とおもったのだけど、やってみたがうまく動かない。


Gmail がエラーで送信できないよ、というエラーメッセージ。

このメッセージで検索すると、設定をこう変えればよい…などの情報が見つかるのだけど、どれを試してもうまくいかない。




IFTTT、3月31日からGmailのトリガーと下書き作成が利用不可に


それで見つけたのが、上のページ。


今はサービス終了した Google+ は、顧客情報が流出する可能性があるバグがあった、というのがサービス終了の決定打だった。

その後、Google はセキュリティを強化する取り組みを行う中で、Gmail を外部から操作できるようにしていたのを見直す、そのため IFTTT でも使えなくなる、という内容。



でも、ここでは「トリガー」が使えなくなるとしているだけ。

トリガーというのは、「メールが届いた」とか、状態変化を伝える機能のことで、「メールを送る」などの実際の動作を行う機能とは違う。


今回は、Gmail を使ってメールを送りたいだけなので、これとは関係ないはず。


さらに調べていたら、ちゃんと IFTTT のサイト内でこんなメッセージを発見。



Gmail actions may fail for some users.

Identified - The issue has been identified and a fix is being worked on. It will require a large rework in how Gmail is implemented, we appreciate your patience as we get Gmail up and running for everyone.

May 15, 16:51 PDT


意訳:

一部ユーザーで、Gmail でエラー

認識 - 問題は認識され、修正中です。Gmail の実装に大きな変更が必要なので、誰もが Gmail を使えるようになるまで、しばらくお待ちください。



つまり、僕のせいではなくて IFTTT 側の問題だったわけだな。

どんなに設定を見直しても無駄なわけだ。


「しばらくお待ちください」となっているが、もう2週間もこの状態のままのようだ。

いつ復帰するのかわからない。



上記調査中に、他にも気になることを見つけた。

IFTTT と Gmail と「日本語」の組み合わせを使うと、頻繁に文字化けするようなのだ。


IFTTT は基本的に英語サービスであり、日本語は「使える」が「保証されない」。

ここに、先に書いた Gmail 側の大変更なども加わり、日本語が化けるようになっては修正される、というのを時々繰り返している。


先に書いた、現在動かない件も含め、今後もこういうことがたびたびあるのかもしれない。




というわけで、不安定な Gmail に頼るのはやめよう。

幸い、Gmail 以外にも、普通の Email を使うこともできる。


ただ、Gmail では「誰にでも」送れるのに対し、Email は「自分にだけ」送れる。

Email の仕組み上、誰にでも送れてしまうと SPAM の発生源となるからだ。


自分にだけ送る、というのも、一度 Email でシステムがランダムな数値を送り、その数値を答えて認証を通さないといけない。

確実に自分向けの Email だと証明できた時だけ、自分宛の Email を自由に送れるようになる、ということだな。


そうなると、wunderlist 宛にメールすることはできないわけだが、幸い僕は自分のメールサーバを持っている。

届いたメールを、wunderlist 宛に転送しよう。



現在僕はサーバーで qmail を使っている。

qmail には、拡張メールアドレスと呼ばれる機能がある。


たとえば、ユーザー nobody のメールアドレスが nobody@example.com だったとしよう。

このとき、qmail では、nobody の後ろにハイフンと文字列を付けた nobody-ifttt@example.com もユーザー nobody に届くのだ。


しかも、この「届く」というのは、単にユーザーのメールボックスに届くのとは意味が違う。

同じメールボックスに入れる指示もできるけど、別のメールボックスに入れたり、片方だけプログラム処理したりもできる。

サーバーの時点で、ちゃんとメールを仕訳けてくれている。



自分のサーバーに qmail を入れている人には説明するまでもないのだけど、自分のホームディレクトリに


.qmail


というファイルを置くと、その内容によって自分宛のメールをどのように扱うか指定できる。


.qmail-ifttt


というファイルを置けば、自分のアカウントの後ろに -ifttt を付けたアドレス宛てのメールを処理できる。

ここに、次のように書く。


|sed 's/^From:.*$/From: nobody@example.com/' | /var/qmail/bin/qmail-inject me@wunderlist.com


メールボックスに入れるのではなく、このプログラムにメールを渡せ、という指示だ。

ここで、簡単なフィルタプログラムを書いている。


まず、From 行を書き換える。そしてそれを me@wunderlist.com に送る。



このままでは、実はヘッダに書かれた To: が自分のアドレスのままだ。

でも、wunderlist.com の方では、To: は気にしないようだ。


#メールは、「ヘッダ」と「封筒」に宛先を書ける。配信は封筒のアドレス宛てに行われるので、

 ヘッダのアドレスと配信アドレスが違うことはあり得る。


wunderlist.com の方には、僕のメールアドレスが確かに自分のものであることを事前に認証させてある。

このアドレスはヘッダの From: に書かれたものを認識するようなので、こちらは書き換える必要がある。



これで、IFTTT からのメールは、無事 wunderlist に転送され、リスト項目が追加された。




海外では、個人が作った alexa スキルで、wunder shopping というものがあるようだ。

IFTTT で Gmail が使えないのであれば、自分で Oauth 認証を通して連携させられないか…と方法を探す中で発見した。


これが日本語対応してくれれば、ややこしいことなしで wunderlist と連携できる。

でも、個人の制作物だから、対応は望めないだろう。


しかし、wunderlist との連携スキルを作ることは可能だ、と示されているわけでもある。

いっそのこと自分で作ってみるか…とまで考えた。


その時に、ふと「自分にメール送れるなら、転送すればいいんじゃん」と気づいて、上のような設定になった。

alexa スキル作成は、面倒くさいのでやらない。


でも、誰か作ったら使いたい(β版で人柱やってもいい)ので、教えてください。


▲目次へ ⇒この記事のURL

別年同日の日記

02年 PHS解約

04年 ピクミン2攻略終了…?

13年 水疱瘡

15年 8bit 時代のグラフィック

17年 チャナダル


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

Nexus7 (2012) 復活  2019-05-20 14:54:10  コンピュータ

▲目次へ ⇒この記事のURL

2度目の復活。不死鳥のように甦る。


Nexus7 (2012) は、2012年発売の 7inch Android 端末だ。

さすがに8年も前の端末なので、今時使い物にならない…


と思って、先日代替機として Amazon FireHD 10 を購入したのだ。

そして、代替機が手に入ったので、Nexus7 はお役御免、「捨てても構わない」機械になった。


じゃぁ、捨てる前にダメもとで遊んでみよう。

…そうしたら、使える端末に復活してしまった。





ちなみに、「2度目」と書いたが、1度目の復活は1年前だ


一度は、遅すぎて使い物にならない、と思ってほったらかしになっていた機械を、ダメもとで復活させたら案外使えていた。

しかし、1年使っていたら、やっぱり使い物にならなくて、代替機を購入した、という流れだ。



1度目までの経緯を説明しよう。


Android は現在広く使われている OS だが、最初は「スマホ用」の OS だった。

タブレット端末で使うことは想定されていなかったのだ。


当時、スマホ用には Android 2 系列が使われていた。

これに対し、Google はタブレット用の「別バージョン」として、Android 3 を作る。

3 は 2 の後継ではなく、違う機能を持つ別バージョンだった。


しかし、Android 4 では、2 と 3 の両方の機能を持つ形で統合される。

ここに、現在のように幅広く使われる Android の基礎が出来上がる。


そして、これを広く宣伝するように Google が販売した「戦略機種」が Nexus7 だった。

世界初の Android 4 搭載端末で、当時の一般的なタブレット価格から見ても、驚くような低価格設定だった。


Nexus7 は大ヒットとなり、翌年には改良機種が出る。

僕は初代を買ったので、Nexus7 (2012) と書くが、この書き方は (2013) もあるためだ。



さて、「世界初の Android 4」は、初物であるがゆえにバグが多かった。

頻繁にバージョンアップされ、最終バージョンの 4.4.4 まで進み、さらに 5 系列も提供された。


しかし、5系列も真っ先に投入されたため、またバグだらけだった。

これがひどいもので、まともに使えないほど動作が緩慢だった。


頻繁にバグ修正が行われ、5.1.1 まで行ったのだが、Nexus7 (2012)のバージョンアップはこれで終了。

使い物にならないほど緩慢なままだったので、我が家では使わなくなってしまった。



そして1年前。

5 系列が緩慢なら、4 系列に戻して使ってみよう、ということで 4.4.4 に入れなおした。


ちなみに、Android の宿命として、「バージョンアップ」を提供する仕組みはあるが、バージョンダウンは難しい。

Nexus は Google 製で、開発にも使われることを想定しているため、それなりの知識があれば好きなバージョンに戻すことができる。


4.4.4 にしたら、動作が軽快になった。

古い機械なのでパワー不足は感じるが、それなりに使える状況に戻ったので使ってきた。


ところが、1年使ったある日、急によく使っていた Radiko アプリの動作が遅くなった。

やはりパワー不足か、とあきらめて代替機を先日買ったのだ。



代替機購入の際の日記には、「Radiko のアプリ動作が緩慢になったのは、Radiko のシステム更新が原因ではないか」と書いた。

しかし、これは今はちょっと違ったかな、と思っている。後で詳細書く。




さて、今回やったこと。


僕が知らなかっただけで、1年前に「復活」させた時点では、今回の方法がすでにトレンドになっていたようだ。



使いものにならないほど遅かったNexus7改善計画

Nexus 7 (2012)をAOSP 7.1.2にアップグレード


今回は、上に書かれた2つのページを参考にして、ほぼ同じことをした。



1ページ目は、Nexus7 が Android 4.0 だったころのバグの影響が後まで残り、速度低下の原因になっている…

という指摘。ただ、あとで考えると事実誤認が含まれるように思う。これは後で説明する。


事実誤認があっても、1ページ目は2ページ目の作業を行うための「事前準備」のやり方を、懇切丁寧に教えてくれる。

目は通すべき。最終結論である「Trimmer アプリの実行」も、おまじないとしてやっておいて損はないと思う。

(多分、まったく無関係なのだけど、害はない。やって何か改善したら儲けもの)



2ページ目は、非公式ではあるが、Android 7.1.2 を入れてしまおう、というもの。

非公式とはいっても、もともと Android はオープンソース…プログラムが公開され、誰でも改造できるものだ。


そこで、正式な 7.1.2 を元にして、有志が Nexus7 (2012) に対応したバージョンを公開しているので、それを入れる。


7 は、5 よりも「最適化」が進んでいる。つまり、プログラムの無駄が省かれている。

そのため、5よりも軽快に動く。



これが非公式版で、Google が著作権を持つアプリは入っていない、ということも大きいと思う。


一般に、Android 端末を購入すると、Google 製のアプリがたくさん入っている。

場合によっては、それと同等の機能を持つ、端末メーカー製のアプリもたくさん入っている。


そして、それらは消すことができない。

場合によっては動作を止めることすらできず、CPU の速度とメモリを無駄食いする。



しかし、非公式な Android には、Google が著作権を持つアプリを同梱することが禁じられている。

…いや、Google アプリが入れられないわけではない。禁じられているのは「同梱」だけで、再配布は許可されているから。


逆に言えば、非公式 Android なら、公式なものと違って、必要最低限のアプリだけ入れるようにできる。

すると、不要な機能が動かないので動作が軽快になる。


もっとも、何が不要かは人によるだろう。

僕が軽快だと感じていても、他の人には「機能不足で使えない」と思う可能性もある。




2ページ目として紹介したページ、そのページが書かれた時点での「最新版」の 7.1.2 を使用している。

しかし、現在ではもっと新しいものがある。


紹介ページでは「2018/12/05 ~の掲示板」となっている箇所のリンク、実は掲示板の名前は、時々更新される。

現在は、日付部分が 2019/05/05 となっている。


そして、その掲示板の一番上に、最新バージョンのバイナリが置かれているので、それを取得しよう。


バージョンが違っても、どれも 7.1.2 だ。これは、「Google がつけた Android の」バージョン番号。

日付の違いは、それを Nexus 7 で動くように移植作業をした際のバージョン違いだ。


どうも、バグ取りも行われているが、セキュリティアップデートに追随するのが目的のようだ。




Nexus7 (2012) には、WiFi 版と 3G 対応版の2機種があり、名前は同じだがハードウェアが違う。

WiFi 版は Grouper 、3G 版は Tilapia というコード名がついている。どちらも魚の名前だ。


僕は Grouper の OTA-Package バイナリを選ぶ。WiFi 機種だからだ。

そして、Open GApps のバイナリも必要とする。


GApps とは Google Apps 、つまりは Gmail や Chrome などの Google 製アプリこのことだ。

Nexus7 は ARM なので、ARM - 7.1.2 - pico を選ぶ。


pico の部分は好みで変えてもいい。pico は最小セットだ。不要なものが一切入らないので動作が軽い。

その後、必要なものがあれば Google Play Store で入手すればいい。



これで、特に問題もなく、7.1.2 にすることができた。快適に動作する。

…いや、さすがに8年前のマシンなので、反応がちょっと遅い感じはあるよ?

インタラクティブに使うのは、ちょっと辛いかも。


でも、Youtube 見たり、Radiko 聞いたりといった「ストリーム再生」には問題がない。

Chrome 検索して、静的な(ゲームとかではない)ページを閲覧するのにも問題はない。




ところで、Radiko は最新版だと動かない。

旧バージョンがあるので、5.0.6 を入れると動く。

…なんか怪しげなサイトだけど、合法だと書いてあるのだから、大丈夫なのだろう。



Radiko はバージョン 6 以降でないと、タイムフリー(1週間以内ならいつでも聞ける)に対応していない。

と同時に、この機能が強力なので、放送データを録音したりできないように、動作する OS 環境がおかしなものでないかなど、厳しいチェックが入るようになったようだ。


Nexus7 (2012) で 7.1.2 なんて、「おかしい」以外の何物でもない。

最新の Radiko が動かないのは仕方がないところだろう。


#でも、先日買った Amazon Fire HD には Radiko 最新版入れられたな…

 Amazon Fire で Google Play Store アプリを入れるとか、おかしいのだけど。




さて、途中で書き逃していることを説明する。

まず、先に書いた「Trimmer には意味がなさそう」について。


SSD には TRIM という仕組みがある。

なぜ必要かは長くなるので自分で勉強してもらおう


ただ、この仕組みは最初からあったわけではないと知っておいてほしい。

当初、SSD は HDD の互換品として作られ、後に性能を上げるために TRIM という独自の仕組みが取り入れられた。



ところで、Linux という OS がある。

HDD で運用する前提で作成された OS で、いまは SSD でも使えるようになっている。


ここで、TRIM は OS そのものの仕組みとしては提供されていない。

OS 上で動作する別アプリケーションとして TRIM 動作を行うだけのものがあり、それを定期的に動かす仕組みだ。


このように機能を分離することで、OS 本体の方に HDD と SSD の違いなどを入れる必要がなくなり、プログラムが複雑になるのを避けられる。



そして、Android の中身は Linux だ。

Android は HDD を搭載しない… SSD 運用が普通なので、定期的に TRIM する必要がある。


しかし、Android 4.0 は、この「定期的な TRIM 」が動かないというバグがあったそうだ。


OS 本体が対応しないなら、アプリとして対応してやればよい。

Trimmer はそのためのアプリで、OS 内部にちゃんと持っている TRIM アプリ (fstrim という)を起動してくれる。


でも、4.0 でなければ fstrim はちゃんと起動される、らしい。

先のページがさらに参照しているページでは、「4.0 の時におかしくなったセクタが戻らない」と説明しているのだけど、fstrim の仕組みでは、そんなことにもならない。



だから、4.0 でなければ Trimmer はいらないと思う。





じゃぁ、なんで 4.4.4 を使っていても、1年の間にだんだん遅くなってきたのか、について。

Radiko のせいだと思っていたが、どうも冤罪だという件だな。


単純な話で、1年使う間にキャッシュがたまってしまったのではないか、と思っている。


前回も今回も、OS を入れなおしてすぐは、「快適動作」と感じている。

前回は、それから1年かけてだんだん遅くなっていった。


これは、入れ直しによって自然にキャッシュはクリアされてしまい、使うことで溜まっていったからではないか、という推論だ。



またしばらく使ってみて、また重くなることがあれば、まずはキャッシュクリアを試してみよう。

そうなった時には、またお知らせしたいと思う。



▲目次へ ⇒この記事のURL

別年同日の日記

02年 5/20

05年 美味しいケーキ屋さん・その後

07年 ぞうが かわに おっこちた

13年 桑の実


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

パソコンは買ったのだが…  2019-05-14 17:51:09  コンピュータ

▲目次へ ⇒この記事のURL

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

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



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

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


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

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



僕も HP に決定。

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

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

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


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

HDD と同時搭載がいい。


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

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

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


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

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




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


ところが、だ。

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


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


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

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


まぁ、仕方がない。

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



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

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




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

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


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

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


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

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



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


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

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


▲目次へ ⇒この記事のURL

関連ページ

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

別年同日の日記

02年 5/13

04年 ピクミン・訂正

07年 保育園の遠足

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

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

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


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

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

▲目次へ ⇒この記事のURL


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

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


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

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


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

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




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

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

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


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

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


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


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

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




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


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

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


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


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

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



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


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


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

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



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


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



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

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




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


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

クリアできた。



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

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


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

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


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

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



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


▲目次へ ⇒この記事のURL

別年同日の日記

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

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

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


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

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

▲目次へ ⇒この記事のURL

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


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


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


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

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




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


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

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


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

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



まずはゲームの説明だ。

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



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

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


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



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

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

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


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

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


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




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

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


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

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


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


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

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


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


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

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


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



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

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


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

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




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

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


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

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


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

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


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


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

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



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

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


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

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




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


???

???

???


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


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

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


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


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

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



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

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


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



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

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


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

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



ここでやっと気づいた。

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




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

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


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

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


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


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

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


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



そして思った。

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


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

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


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

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

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


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

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


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

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




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

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

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



▲目次へ ⇒この記事のURL

別年同日の日記

13年 記事の更新


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

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

▲目次へ ⇒この記事のURL

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


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

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


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

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


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




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

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

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


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

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


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

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


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


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

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




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

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


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

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



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


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

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

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



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


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

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



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

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


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



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

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


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



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

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


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




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


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

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


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



ServiceWorker という。


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


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


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


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


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


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

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


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

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



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

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

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



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

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




基本戦略はこうだ。


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

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


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

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



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

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

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


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


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

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


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

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

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



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

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


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

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


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



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

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


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

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


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


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




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


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

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


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


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

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

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


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

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


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

非常に面倒くさい。

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



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

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


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

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


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




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


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

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


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

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


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

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



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

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





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


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

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


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

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


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

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


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

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

(http と同じだ)



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

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


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


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

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

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


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


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

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


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

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


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



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

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



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


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


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


としてしまえばよい。




ここで重要なのは、


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

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

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


ということだろう。


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

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


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

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


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




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

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


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

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


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

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


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



▲目次へ ⇒この記事のURL

関連ページ

Programming Tips

別年同日の日記

02年 5/3

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

04年 知恵の輪

04年 天然温泉

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

04年 ピクミン2

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

05年 よきライバル?

06年 ゴールデンウィーク


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

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

▲目次へ ⇒この記事のURL

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



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

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


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


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

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


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

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



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

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


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

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




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

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

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


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

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

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



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

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


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




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


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

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


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

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


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

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


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

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



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

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


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

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


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

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




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

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


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


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

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


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


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

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


こちらを購入。




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


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

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


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

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



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

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


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

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


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

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



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

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


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



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

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

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




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


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


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

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


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



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

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


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


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

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


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

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



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

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



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

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



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

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



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




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


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



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



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

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


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


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


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


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

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


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

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

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


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

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

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



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

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



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

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


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



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

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


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


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


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


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




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

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


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

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



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

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


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

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




Alexa を試してみる。


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

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



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


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

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


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




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


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

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



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

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

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


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


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

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

 



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

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


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

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



▲目次へ ⇒この記事のURL

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

歯車

関連ページ

Nexus7 (2012) 復活【日記 19/05/20】

別年同日の日記

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

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


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


戻る
トップページへ

-- share --

16000

-- follow --




- Reverse Link -