コンピュータの日記です

目次

2020-05-21 Chromebook を買ったのだけど
2020-04-15 【訃報】ジョン・ホートン・コンウェイ氏
2020-02-27 BABA IS YOU
2020-02-22 node-tyrant のバグ修正
2020-02-16 MacBook Pro 購入
2020-01-16 mysql で varchar を int に alter table する。
2019-11-20 久しぶりのperl
2019-11-19 遊びプログラム
2019-11-17 イベント終わりました
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 その後
 …同じテーマのほかの記事
Chromebook を買ったのだけど  2020-05-21 10:57:05  コンピュータ

▲目次へ ⇒この記事のURL

4年前に購入したChromebookが、壊れかけている。


キーボード手前に配置されているタッチパッドのスイッチ部分がおかしく、接触しっぱなしになってしまうのだ。

マウスでいえば、左ボタンを押しっぱなしにした状態。


で、外付けマウスをつけていても、左ボタン押しっぱなしと判断されてしまうため、左クリックできない。

タッチパッドのスイッチのあたりをガチャガチャやると治るのだけど、また不意におかしくなったりする。



昨日も書いたが、子供たちの学校がネット授業も開始する予定だ。

現在、親の古いマシンも含め、子供たち一人に1台のPCはあるのだけど、1台はこの Chromebook なのだ。




ちょっと問題あるよなぁ、と、買い替えを検討したのはもう1か月ほど前。

しかし、このご時世で手ごろな値段の PC は軒並み売り切れだった。

Chromebook もご多分に漏れず。



それが、学校から「近々ネットでの授業を開始する」という連絡が来たので、再度調べたのが先週末。

性能的に申し分なく、値段も2万5千円ほどという悪くないマシンが Amazon にあったので、購入した。


しかし、僕の確認不足だったのだ。



今週前半に届いたマシンは、US キーボードだった。

見直したら、ちゃんとそう書いてあった。


うーん、残念だけど、返品。

手続きはして、まだ送付していない段階。


他にいいマシンはないか調べたけど、手ごろな値段のマシンは軒並み売り切れで、今入手できるのは高価なマシンになってしまう。



仕方がないので、もう少し待つか…



▲目次へ ⇒この記事のURL

別年同日の日記

03年 楽園を求めて…

05年 お掃除ロボ

12年 姪の結婚式

15年 68000はグラフィックに強かったのか

18年 フェスとフェスタと祭りと開放日

19年 あーすフェスタ


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

【訃報】ジョン・ホートン・コンウェイ氏  2020-04-15 18:22:50  コンピュータ 今日は何の日

▲目次へ ⇒この記事のURL

数学者の、ジョン・ホートン・コンウェイ氏が、11日に新型コロナウィルスによる合併症で亡くなったそうです。



…さて、僕は氏のことをほとんど知りません。

それでもここで取り上げるのは、「ライフゲイム」の考案者だからです。




あえてライフゲイムと書くのは、日本に最初に紹介した本が「ライフゲイムの宇宙」というタイトルだったため。


まぁ、一般的には「ライフゲーム」です。

ただ、英語で The Game of LIFE といえば、一般には「人生ゲーム」のこと。

そのため、「コンウェイのライフゲーム」とも呼ばれます。



で、そのライフゲームが何なのかといえば、「生物群をシミュレートする初期の方法」であり、「セルラーオートマトンの初期のもの」です。



非常に単純なルールで、生物群の存在をシミュレートします。

ここでグダグダルール書いたりしても面白くないので、興味持った人は自分で調べてください。


ルールは単純なのですが、非常に広い範囲…理想的には、無限の広さを持った盤面の、1マス1マスにそのルールを適用する必要があります。

1回適用すると「1世代」と呼ばれ、最低100世代くらい繰り返すと面白みが出てきます。


とすると、無限の広さは無理なので 100x100 の盤面だとして、同じ操作を 1000000 (百万)回くらい繰り返す必要があります。

人間が手動でやるのは、とてもじゃないが無理。



でも、ルールは単純なので、初期の… 1960~70年代くらいのコンピューターを使い、研究されました。


特に中心的に研究していたのが、ビル・ゴスパー。

当時 MIT の学生で、自由に使えた PDP-6 でライフゲイムの研究を行っていました。


ここらへん、時々僕が名著として挙げる「ハッカーズ」の中に、1節丸ごと使って様子が描かれています。


彼は、コンウェイ自身が「存在しそうだけど見つけられない」という、「永久に増え続けるパターン」を見つけ出そうと一生懸命になり…ついに見つけ出し、コンウェイの懸けた懸賞金 50ドルを勝ち取ります。



今でもライフゲームの研究者はいて、続々と新発見が報告されたりしています。


単純ですが、非常に奥深い世界です。




全然関係ない話題なのだけど、昔、私鉄の自動券売機の表示画面でライフゲームが動いているのを見たことがあります。


当時は今とは違い、細かな LED 表示のディスプレイだったのですが、長い間同じ表示を出し続けていると、点灯時間が長い LED から寿命が尽きてしまいます。


なので、誰もいないときは表示を消すと良いのですが、消してしまうと電源が入っていないようにも見えます。



そこで、「動いている」ことを示しつつ、常にランダムに動き続ける模様として、ライフゲームが使われたようなのです。


人感センサーがついていて、近づくと普通の表示に戻るようになっていました。




ライフゲームに類似なものを、セルラーオートマトンと呼びます。

「マス目に区切った世界に対し、一定のルールを適用し続ける」ものです。


「セルラー」の語源は、生物の細胞、セル。

実際、生物の細胞は同じような仕組みで動いているかもしれない…という研究報告もあります。


ヒョウ柄とか、トラ柄とか、キリンの柄とか、熱帯魚の柄とか。


あれ、遺伝子で柄が指定されているわけではないです。「偶然」で出来上がっている。

でも、この偶然の指定は、遺伝で決まっている。


その偶然の指定が、どうもセルラーオートマトンのルールみたいになっているようなのです。

ライフゲームのルールをちょっと変えて適用してやると、いろいろな動物の柄に似たものが浮かび上がってきたりします。


こうした研究も、コンウェイのライフゲームの研究の上に成り立っているものです。




セルラーオートマトン自体は、マス目に区切った世界にルールを適用し続けるものなのですが、ここから派生して「人工生命」という研究も生まれました。


コンウェイのライフゲームは、非常に単純なルールを適用するだけで、生物の「ようにみえる」状況を生み出すものでした。


でも、もう少しちゃんと「生命らしい」ものを作ってみたら?


マス目にルールを適用するのではなく、生命としてふるまうプログラムを作って、いろいろな研究をするのが「人工生命」の分野です。



遺伝的アルゴリズムとか、人工生命分野から生まれた発想で、今では別の分野でも使われます。


「少しづつ違ったランダムパラメーターを用意して、それらどうしを戦わせ、優れたものだけ残していく。

 残った者同士のパラメーターをかけ合わせたり、ランダムに突然変異を入れたりしながら、さらに強いものを残す。

 最終的には最強のパラメーターが出来上がる」


という考えかた。


例えば、2000年を過ぎたころから、急にチェスや将棋、囲碁の AI が強くなってきたのは、この考え方を取り入れたためです。





まぁ、僕はこうした世界は「好き」ではあるのですが、研究者ではないので薄っぺらな知識しか持っていません。


亡くなったコンウェイ氏の業績としては、ライフゲイムなんてのは「ほんの僅かな手遊び」みたいなもので、非常に偉大な数学者だったようです。


でも、そちらについても僕はちっとも理解していませんので、紹介できません。



しかし、ライフゲイムだけでも、上に書いたように後に続く様々な研究の礎となっているわけです。


▲目次へ ⇒この記事のURL

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

今日は何の日

別年同日の日記

02年 4/15

15年 PC-E500 発売日(1988)


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

BABA IS YOU  2020-02-27 12:58:33  コンピュータ

▲目次へ ⇒この記事のURL

中3の長男の受験は、先週中に終了した。


そこで、以前から僕が欲しかったゲームをやっと購入できた。

僕が遊んでいたら長男も気になるだろうし、受験終わるまで待ってたの。




BABA IS YOU。


1年くらい前に PC で発売されたゲームで、その時から興味を持っていた。

昨年末には Nintendo Switch で日本語版が出たので遊びたかったのだが、上に書いたような理由で我慢していた。



興味は持っていたのだが、基本ルール以外の情報があまり入ってこない。

というのも、これはパズルゲームであり、詳細を伝えるとネタバレになる恐れがあるためだ。



ここでも、読んでいる人が興味を持てるかどうかのぎりぎりの情報しか出さないようにしよう。

ネタバレすると困るから。




基本的には、倉庫番タイプのゲームだ。


主人公はマス目の中を動く。

障害物には、動くものと動かないものがある。

動くものは押せる。動くものの向こうに動かないものがあると、押せない。


倉庫番の場合、動くもの(荷物)が2つになっても押せなかった。

BABA IS YOU では、いくつでもいっぺんに押せる。



ところで、以前に僕はゲームに関する持論を書いたことがある。


ゲームのルールは、シンプルでなくてはならない。

しかし、状況は十分に複雑でなくてはならない。


ルールを複雑にすれば、当然状況も複雑になる。

しかし、それではルールに振り回されるだけで、楽しくないのだ。


すぐに把握できるほどシンプルで、それを駆使して複雑な状況を乗り切るのが楽しいのだ。


「倉庫番」は、過去に書いた日記でも、シンプルで複雑なゲームの代表として書いた。



しかし、BABA IS YOU は、シンプルといってよいのかどうかわからないんだ。


ルールはすぐに把握できる。上に書いたように、倉庫番と類似だ。

しかし、BABA IS YOU の特徴は、このルールの中で「追加ルール」を、ユーザーが自分で決められることなんだ。




最初の面はチュートリアルだ。


壁に区切られた、3マス分しかない細い通路と、主人公と思われる白い謎生物。

通路の途中には、道を塞ぐように岩が3つ並んでいる。

そして、岩の向こうには旗が立っていて、きらきらとしたアニメーションをしている。


倉庫番のように、通路を進んで岩を動かし、旗まで行くと「おめでとうございます」と画面に表示され、面クリアだ。



さて、面クリアしたら、もう一度同じ面を遊んでみよう。


通路の外には、単語が書かれたブロックが並んでいる。

4カ所にまとまっていて、それぞれは3つのブロックが組み合わさっている。

書かれているのは、次の通りだ。


BABA IS YOU

WALL IS STOP

ROCK IS PUSH

FLAG IS WIN


通路の外に主人公を動かして、これらの単語を押すと、動かせる。


例えば、 BABA IS YOU を動かして、並びを壊してしまうと…

あれ、主人公が操作できなくなる。しばらく待つと、画面上に「巻き戻す 最初から」と操作表示が出る。

つまりは、失敗してゲームオーバーのようだ。


BABA とは「主人公」だと思い込んでいた、白い謎生物のことのようだ。

それが「YOU」、つまり主人公である、と示している。


そして、この「追加ルール」を壊してしまうと、主人公がいなくなるためゲームオーバーとなる。


WALL IS STOP を壊せば、壁はすり抜け可能となる。もはや、ただの背景だ。

組み換えも可能で、ROCK IS WIN にすると、岩がきらきらし始め、そこに行くと「おめでとうございます」となる。


さらには、WALL IS ROCK とすれば、画面上の壁がすべて岩に変わる。



単語は、縦に並べてもいい。

ただし、左から右、または上から下に解釈される。逆順にはならない。


    ROCK
BABA IS YOU
    PUSH

と並べると、IS を共有して、2つのルールが完成する。

こうやって「単語を節約する」必要があることも多い。


ちなみに

WALL
 IS
BABA IS YOU


のようにすると、画面上の WALL が全部 BABA になって、キー操作で同時に動く。


        WALL
         IS
BABA IS YOU


だと、WALL がそのまま「主人公」に追加される。

BABA にはならないが、キーで同時に動く点は同じだ。


画面上のものがたくさん同時に動くのは、結構カオス。

見た目だけでなく、繊細な操作を必要とされるパズルゲームで、数の暴力を展開すると恐ろしいことになる。

(それが必要な面だってある)




DOOR IS SHUT AND STOP

KEY IS OPEN AND PUSH


とか書かれていたとする。(実際、これは多いルールだ)


ドアは閉まっていて、障害物。

鍵は開いて、押せる。


ここで、OPEN に対応するのが SHUT だ。

鍵を押してドアにもっていくと、開く。この時、ドアと鍵が同時に消滅する。


一方で、


WATER IS SINK


というのもある。「水は沈む」だ。

この場合、水に入ったものはなんでも消えてしまうが、同時に水も消える。

SHUT と OPEN は2つでセットだが、SINK は相手を選ばない。

しかし、「2つセットにすると消えてしまう」という現象は同じだ。



ここではさらっとルールを書いてしまったが、ゲームをしていて説明されることはない。

新しい単語を見かけたら、それがどういう意味か、実験しながら推察していくしかないんだ。



このゲームの面白さの多くの部分が、そうした「実験と推察」だ。

倉庫番のようなルールだけど、じっくり考えてわかるものでもない。

知らない仕掛けが次々登場して、その仕掛けの意味を調べつくし、それらをどう組み合わせれば目的を達成できるのか考える。




倉庫番なので、壁の角に押し付けられたブロックは動かせない。

ゲーム内では、これを利用して「変えられないルール」を作り出していることも多い。


もっと言えば、入り込めない壁の奥に書かれているルールは、不可侵だ。

変えられないだけでなく、その単語を利用することすらできない。


その一方で、壁に囲まれていて不可侵に見えるブロックを、「壁」自体の定義を作り変えて入り込んで利用する…というような面もある。


とにかく自由すぎる。

そして、自由かと思っていたら、どうしようもなく組み替えられないルールに悩まされ、不自由を感じたりする。


不思議極まりないゲームだ。




これは、一種の「プログラムゲーム」なのだと思う。

プログラムゲームとは、一定のアルゴリズムなどを記述することで遊ぶタイプのゲームだ。


戦闘アルゴリズムを書いて対戦する、なんてのが多いけど、ヒューマン・リソース・マシーンみたいな課題クリア型もある。


BABA IS YOU では、長いプログラムを組めるわけではない。

しかし、ゲーム内の文法に従って「記述」を行うことで問題を解決するし、その「記述」を複数組み合わせることで効果を持つ。


十分にプログラムだと言ってよいだろう。




購入前は、ルールを自分で変えられてしまうというので、比較的緩く遊べるパズルゲームを想像していた。


しかし、思っていた以上に難易度は高めだ。

その原因の一つは、新たな効果を持つ単語が出現した時に、その作用を十分に理解しないといけない、という点がある。


このゲームのルールが、シンプルといってよいのかどうか、最初に迷っていたのもその点だ。


基本ルールは非常にシンプルでありながら、単語の組み合わせ方は非常に幅広く、その効果も複雑だ。

この複雑さは、プログラムの複雑さと同じだろう。時にはバグも発生し、デバッグに悩まされる。


場合によっては、効果だけでなく、「効果による副作用」まで理解しないといけない。


そして、それらに対する説明は、どこにもない。

自分で実験しながら探し出さないといけない。


いわゆる「パズルゲーム」の難しさにとどまらず、「なにかを研究する」難しさに近いといってよいだろう。



先週末に購入し、長男が熱中して遊んでいるので僕はなかなか遊べず、まだあまり先の面を見ていない。

先の面を見るのが楽しみだ。


じっくりと考えることが好きな人には、自信をもってオススメできる作品。



▲目次へ ⇒この記事のURL

別年同日の日記

02年 2/27

12年 おゆうぎ会

15年 WING WAR


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

node-tyrant のバグ修正  2020-02-22 15:31:35  コンピュータ

▲目次へ ⇒この記事のURL

今日は、プログラマ向けのちょっとした推理小説。

まぁ、実際に今週体験したことなのだけど。




世の中には多くのデータベースソフトがあるが、SQL とそうでないものに大別される。

そして、「そうでないもの」の中に、key value store と呼ばれる種別のデータベースがある。


ざっくりと違いを書くと、SQL は多機能だが、高速ではない。

key value store は非常に貧弱な機能しかないが、無茶苦茶高速だ。



SQL ってのは多機能なので作るのが大変で、昔は高価なソフトしかなかった。

それが、PostgreSQL と MySQL の台頭で、無料でも使えるようになり、普及した。


ちょうど WEB の黎明と重なり、最初は重宝された。

しかし、WEB が当たり前の社会インフラになると、1秒で何千というページアクセスを支える必要があり、より高速な DB が求められ始めた。


そこに登場したのが key value store だ。


memcached というソフトが最初のきっかけとだったと考えていい。

現在人気があるのは、Redis だと思う。




Tokyo Cabinet は国産の key value store で、10 年くらい前に人気があった。


本当に機能が少なく、ネットワークにも対応していない。

これをネットワーク対応にする後付けのソフトが Tokyo Tyrant だ。


ちなみに「Cabinet」は、書棚などの意味。データを保管する場所だな。

しかし、英語では「内閣」などの意味もある。政治の中枢を担う組織。


そして、Tyrant は「暴君」の意味だ。

Cabinet を意のままに操るもの。面白い名前だと思う。




さて、現在お手伝いしている仕事のプログラムで、Tokyo Tyrant (以下 TT と表記)を使用していた。

以前は PHP で扱っていたらしいのだが、プログラムを完全に作り直していて、Javascript (node.js) ベースになっている。


移植は僕がやったわけではなく、他の方の作業によるもの。

ここで、完全に一から作るのは大変なので、フリーのライブラリを利用したらしい。




…というわけで探してみたら、これだな。

node-tyrant


開発開始から半年以上たつが、特に問題なく使っていた。




先週頭くらいに、僕が新機能を実装していたところ、なぜかサーバー (node.js) が停止する、というバグに見舞われた。


まぁ、自分がプログラムを作っていてバグが出るのだから、自分が悪いのだろうと思って調査を開始する。


プログラムは、とあるきっかけでデータベースのフラグを操作するものだった。

もともと「ボタンを押したとき」に処理をするプログラムが存在したのだ。


しかし、新たに「設定時刻が来たとき」に処理する機能を追加した。


ところが、ボタンを押したときは正常に動作するのに、設定時刻が来たときにエラー停止する。



設定時刻が来た、というのは、cron などの意味ではない。

それでは、せいぜい1分単位の処理で、ユーザー操作とかみ合わない場合があるからだ。


ユーザーが見たときに、設定時刻が来たのであれば、その瞬間に画面に反映されている必要があった。

なので、画面を作るときに、データに記録された時刻を見て、期限を過ぎていたらフラグを操作する。


同じ処理関数を呼んでいるだけなのに、この処理をするとサーバーが停止する。



cron だと、動作するときにユーザー権限が違っていて不具合を起こすようなことがあるが、今回の話はそうではない。ユーザー権限の問題ではない。

じゃぁ、何が問題なのか。問題の切り分け作業に入る。


調査は難航したが、最後に分かったのはこういうことだ。


ボタンを押したときは、ユーザーのアクションを伴うため、フラグが変わった後にページ全体のデータをリロードしていた。

しかし、時刻が来た場合は、サーバー側でフラグ操作するため、必要なデータを書き換えるだけでリロードは起こっていなかった。



そして、「リロードすれば問題ないが、リロードしないと停止する」のだった。




ここで、先に書いた node-tyrant のライブラリだが、さらに改造して使用していた、ということを書いておく。


改造は多岐にわたるが、そのうち一つに「TT からの反応がない場合は、サーバー異常と見なしてサーバーを再起動させる」というものがあった。


サーバー停止は、この機能が働くためだった。

(実際は、停止するとサーバー監視サーバーによって再起動される)


ここで、TT との通信についても触れる必要がある。


TT には、コマンドを送ると、返答が返ってくる。

データはバイナリストリームで、基本的にはデータ長とデータがセットになった chunk 構造だ。


ただし、内部構造はコマンド毎に多少異なる。


バイナリストリームなので、「改行で終了」とかではない。

データ長を信じて処理することになる。




もう一つ、Javascript としての処理の方法を書いておく必要がある。


データはバイナリなので、改行で終了ではないと書いた。

入ってくるデータを常に監視しておく必要があるが、 Javascript では「常に監視」というようなプログラムは書けない。


そこで、EventListenr を使う。何かあったら関数を呼び出して、とシステムに依頼する方法だ。

TT との通信では、「データを受信したら呼び出す」関数を指定しておく。



ところで、ネットワーク越しのシステムなので、リクエストコマンドと返信データの間にはタイムラグが発生する。

そこで、リクエスト時にコマンドをキューに入れておき、データが戻った時はキューを見て処理方法を判断する。

先に書いたがデータ構造はコマンド毎に異なるため、こうしないと処理方法がわからないのだ。



ここで、データが改行区切りなどではない、ということに気をつけないといけない。

Javascript は「何らかの方法で」データが一区切りした、と考えて関数に渡す。


しかし、この区切りが何であるかはよくわからない。

データが途中で切れる、ということはなさそうだが、複数のデータをまとめて受信することはあり得るようだ。




断片的な話が続いて申し訳ないが、必要なことなのでもう少し続ける。


先に「TTからの反応がない時はエラー終了」するようにしてあった、と書いたが、この「反応がない」の定義が重要だ。


上に書いたように、TTへのリクエスト時にキューが積まれ、データが来たときにキューが消費される。

そこで、「最後のリクエストから3秒立ってもキューが解消していないとき」は、TTの反応がなかったとみなされるようになっていた。


TTは高速を売りにするデータベースなので、3秒というのはあり得ないくらい長い時間だ。

そんなに時間が空いたら異常と見なす、というのは、別に悪くないだろう。




さて、「リロードしないとエラー停止」は、この「キューの積み残し」が原因だった。

何らかの原因で、TTが処理できていない、と見なされるのだ。


しかし、エラー停止した直後にDBを確認しても、正しく記録はされていた。

DBからの返事がないだけで、動作はしているのだ。


さらに調べると、返事があるにも関わらずに受け取れていない、と判明した。


この「受け取れていない」は、Javascript が受け取れていないのではなかった。

Javascript が受け取っているにもかかわらず、「プログラムが」取りこぼすのだ。


なぜ取りこぼすのか調べる必要があった。

どんなコマンドを発行して、どんな返事が返ってくるかを調査する。


put コマンド(データの保存を意味する)を送った時、返事が 5byte …「正常終了コード」 1byte と、4byte (32bit) の「0」だとわかった。

これをプログラムが取りこぼす。




プログラムの流れを追いかけると…

先に示したライブラリを、読める人は読んでみるといい。


最終的に、コマンドの結果は 232 行目からの responseMisc で扱っている。

この中で、


if (data.length<9) return [null, -1, null];


という行があった。これは「9バイト未満のデータは扱えないものとして保留させる」指示だ。


5バイトが返ってくるにも関わらず、9バイト未満を認めない。

バグの原因は、どうやらこれらしかった。



しかし、ここで修正を加えるのは早計だ。

こんな単純なバグであれば、「必ず」バグが出て、プログラムがまともに動かないはずなのだ。


にもかかわらず、プログラムは通常動いていて、むしろ停止することの方が少ない。

何かがあるはずだ。



「保留させる」処理の後を考えてみる。

保留は本当に保留で、データを処理しないし、キューも処理しない。

そして、次のデータが来たとき、残っていたデータに「追加」されて、データ処理を再開する。


すると、データが「追記」されたために、データのサイズが増えている。

今度は9バイト以上になっている場合、処理が続行されて、正常な処理になる。



なるほど。普段は問題が出なかった理由が分かった。

先に、「処理の後、データのリロードをしている場合は問題がない」と示したが、追加データがあると処理がうまくいくのだった。




ここまで分かったところで、僕は一旦発注元の会社に報告をした。

自分のプログラムのバグだと思って確認していたが、データベースを扱うプログラムにバグがある。


これは大問題なので、プログラムの作者(古い PHP プログラムを移植した担当者)に連絡が行く。

彼なら TT のハンドリングがわかると思ったからだ。


しかし、彼はライブラリを見つけてきて、目的に合わせて少し改造しただけだという。

すでにある程度ライブラリを調査している僕の方がよほど理解していそうだった。



この時点ですでに僕の仕事は遅れ気味だった。

どうしても取れないバグで悩んでいて、さんざん調査してここまでたどり着いたところだったのだから。



だから、上からの指示は「僕はこの問題を離れ、本来のプログラムの作成に戻ること」だった。

しかし、この問題が解決しないと、プログラムのバグは取れない。


まぁ、「バグは僕のせいではない」ことにして、溜まっている他の個所の作業に取り掛かった。


しかし、他の人の調査報告を横目で見ながら、気になることがあれば手早くできる範囲で調査を続けた。




そもそも9バイト未満のデータを認めない、という処理に妥当性があるのか。


Tokyo Tyrant のプロトコルを調査する。


…少し古いものしか見つからなかった。


ここに、put の返答は処理コード1バイトのみ、と書いてある。

0 なら成功、それ以外ならエラーだ。


しかし、確認するとどうも5バイト返ってきている。

何がどうなっているのか。


プロトコル表あったよー、という返事だけしておく。

TT の現在のバージョンでプロトコルが変化している可能性もある。


うん、きっとそうだ。




別の人が、直接 TT を操作するプログラムを書いてみた。


put コマンドでデータを送り込むと、結果は 1byte が返ってくる、ということだった。


プロトコルのバージョンが違うのでは、という予想は違うことになる。

むしろ、なんで Javascript だと5バイトを受け取るんだ?



再びプロトコル表を見て、気になる。

今まで「返事」のプロトコルばかり気にしていた。put の送信プロトコルは正しいのか?



プロトコル表には、put に対するバイナリコードが書かれている。

プログラム内からこのコードを探す。たしか、先頭付近でバイナリコードの定義が行われていたはず。



// List of Command hex codes for Tyrant var commandCode = { misc: String.fromCharCode(0x90), get: String.fromCharCode(0x30), out: String.fromCharCode(0x20), vsiz: String.fromCharCode(0x38), iterinit: String.fromCharCode(0x50), iternext: String.fromCharCode(0x51), status: String.fromCharCode(0x88), addint: String.fromCharCode(0x60), }


…愕然とした。「put」のコードは、書かれていなかった。



しかし、node-tyrant で put コマンドを呼び出したときに、処理しているプログラムはある。

この処理関数を読んで、やっと気づいた。


node-tyrant のプログラムでは、put コマンドを送るために、put コマンドを使っていない。


TT には misc (それ以外)というコマンドがあり、このコマンドを経由して「隠しコマンド」が呼び出せる


node-tyrant の put は、misc 経由で呼び出される、隠しコマンドとしての put だった。



こうなると、返答データも put と違って当然だ。

プロトコル表に、ちゃんと misc の返答プロトコルが書いてある。


[code:1][rnum:4][{[esiz:4][ebuf:*]}:*]



問題は、この表記方法は作者が定めただけのもので、特に意味は説明されていないことだな。

しかし、コマンド毎に返信データの形式が書かれているので、読んでいるとなんとなく意味が分かる。



[ ] はデータを意味していて、:n はバイト数のようだ。

ここには書かれていないが、省略可能な場合は ( ) で括られる。

複数回繰り返す場合は { } で括られる。



つまり、こういうことだ。


先頭に、処理コード1バイト(0 は成功、それ以外は失敗)

続いて、データ長が4バイト。


さらに、文字列長が4バイト。

文字列が不定バイト。


最後の2行は、セットになっていてデータ長の数だけ続く。



返事を処理する関数での制限、「9バイト」というのは、文字列長までは入っているだろう、という前提のものだったようだ。


後半が ( ) ではないので、省略されることはない、と考えたのだろう。


しかし、{ }:* という書き方が「0回以上の繰り返し」を意味しているようだ。

( ) で括っていないにもかかわらず、0回の場合は消滅する。


つまり、返答データが5バイトの場合がある。


(先に書いたように、間違っていてもなんとなく動くプログラムになっているので、作者が間違いに気づかなかったのだろう)




そういうわけで、最終的にプログラムは一カ所、1byte だけ書き換えられた。

「9」を「5」にしたのだ。これで動作して、安定している。



僕は、ここでの「長さ制限」自体が不要だ、と主張した。

データはバイナリ列のストリームで、「最後までの長さ」という概念がないはずだ。

にもかかわらず、長さで制限するのがおかしい。


実際、そんなおかしな前提だから、「次のデータがくっついたら動作する」などという、曖昧な処理になってしまうんだ。



しかし、データベースのインターフェイスは重要な根幹部分だ。

変更はできるだけ最小限が望ましい、というのが、発注元のプログラマの主張だった。



まぁ、その言い分もものすごくよくわかる。

1byte の変更で問題が解消する、というのは、最善の落としどころだろう。




▲目次へ ⇒この記事のURL

別年同日の日記

03年 美術と芸術

05年 確定申告

10年 八景島

12年 経験した中で最大のバグ

14年 雪・科学館・おゆうぎ会

16年 スティーブ・ブリストー 命日(2015)

19年 完全停止


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

MacBook Pro 購入  2020-02-16 10:49:41  コンピュータ

▲目次へ ⇒この記事のURL

仕事のために「しかたなく」MacBook Pro を購入しました。


あまり使う予定がないので、一番安いやつ。それでも、税込みで15万円ほど。

僕が今使っているメインマシンより高いんですけど…




以前は、携帯電話やスマホ向けの WEB ページを作る仕事が多かった。


特定機種で動作がおかしい、という報告があった時も、クライアント側で該当機種を貸してくれて、動作確認して修正、ということが多かった。

だって、機種が多すぎるから、報告があるたびにいちいち買ってられないもの。



しかし、今受けている仕事は、「通常の」WEB サービスだ。

動作保証は、 Windows の IE11 / Edge / FF / Chrome と Macintosh の FF / Chrome / Safari で行わないといけないことになっている。


機種でいえば「2機種」でよい。

そして、さすがに2機種だとクライアントが貸してくれることもなく、自分で買うことになった。



特に重要なのは、Windows で動作確認できない Safari なのだ。




で、さっそく以前から問題になっていた「Mac でのみ起こる表示崩れ」を調べた。

Mac だと Safari だけでなく FF でも起こる、と報告を受けていたので、フォントの問題なのだろうなぁ、とは予想していた。


思った通り、フォントの問題だった。


Safari の開発者機能を使い、CSS の font-family をリアルタイムに書き換えてみる。

そして、表示崩れを起こさないものを確認し、CSS ファイルを書き換える。


これで問題は解消した。


所要時間は 30分ほど。

とりあえず、今回購入した目的は果たした。


これだけのために15万円ですよ・・・

(まぁ、今後も必要だろうから買ったのだけど)



▲目次へ ⇒この記事のURL

別年同日の日記

05年 忙しい一週間・水曜日

15年 「ああ播磨灘」ゲームボーイ版

17年 パソコン通信が生まれた日(1978)

18年 Harley-Davidson & L.A. Riders


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

mysql で varchar を int に alter table する。  2020-01-16 20:00:56  コンピュータ

▲目次へ ⇒この記事のURL

興味ない人には、なんのこっちゃわからないタイトル。


仕事で複数人数、複数のマシンで開発を行っているので、それらのマシンを同期しないといけない。

プログラムなんかは github 使って管理しているのだけど、DB 構造なんかの問題もある。


で、mysql (実際には mariadb だけど)のテーブル構造を、ファイル化してある。

このファイルは github で管理し、新しいサーバーを建てるときには、ファイルを mysql コマンドで

流し込めば完了する。


そして、開発中に「変更」になったものについては、alter table を列記したファイルを作る。

github から最新のデータを得たときなどは、このファイルを mysql に流し込めば完了する。


…というつもりで作業していたら、そう単純じゃない問題があったよ、という話。




もともと技術者でないとわからない話なので、ついてこれる人だけ読み進めてほしい。


alter table でテーブル構造の変更はできるが、alter table には IF NOT EXISTS というオプションがある。

「もし、その構造が存在していないなら」新しく追加する、などという動作を行う。


だから、先に書いたように、プログラム更新のたびに、必ずこの「 DB 構造差分データ」を DB に流し込めば、構造がすでにあれば無視され、なければ正しく追加される。



でも、「varchar(4) を tinyint に変えたい」で詰まったんだ。


設計段階ではいろいろあって varchar(4) してあったけど、事実上小さな数値しか入らない、と分かったため。



直接 alter table で変換しようとすると、「文字列を数値に変えられない」とエラーが出て失敗する。

これは、何もデータがない時に、NULL 文字列が入っていたため。


数値になった際も、0 は使わないとわかっている。だから、NULL 文字列は 0 に変換してほしい。


というわけで、事前に



UPDATE [table] SET [col]='0' where [col]=''


という感じで、'' を 0 に変える。それから alter table すればうまくいく。



…というわけでもなかった。




上の UPDATE 文、[col] が varchar の時は動いた。

でも、tinyint になると、エラーになって止まる。


先に書いた通り、このファイルはプログラム更新のたびに読み込まれるのだ。

すでに tinyint の時には、何もせずにスルーしてほしい。


エラーの理由はわかっている。


[col]は数値なので、where 句に書かれた比較は数値で行おうとする。

しかし、NULL 文字列は数値ではないので、「文字列を数値に変えられない」とエラーが出て失敗する。


…最初の問題に戻ってきた。

んぎぎぎぎ…どうすればよいのだ。


仕方がない。IF 文を使ってみよう。

僕は mysql を「単に使っていた」歴は長いのだけど、php や javascript と組み合わせていたことが多いため、sql のみで記述するファイルとして、IF を使ったことがない。


やりたいのは、「[col] の型が varchar の時だけ、各種処理を行う」だ。


[col]の型を調べるには、



show columns [table] like '[col]'


とすればよい。これで、画面上に型が表示される。


…いやいや、それはダメだ。画面上に出ただけでは、IF 文で判断できないじゃないか。

しかし、どうすればこれを基に IF の判断につなげられるのかわからない。




ところで、mysql はデータベースだ。データの扱いに長けている。

どれくらい長けているかというと、「自ら作成するデータベースの構造も、データベースとして格納されている」のだ。


つまり、先ほど show columns で見た内容も、実はデータベースに入っている。

データベース名 INFORMAION_SCHEMA の中に、テーブル名を示すテーブルや、カラム名を示すテーブルがある。



SELECT data_type FROM INFORMATION_SCHEMA.COLUMNS WHERE table_name=[table]' AND column_name='[col]'


とすれば、目的のカラムのデータ型を得られる。


…が、これもまだ、表示されるだけだ。


また、サーバー内に複数のデータベースが入っており、同じテーブル・カラムがそれぞれにある場合、全てが表示されてしまう。

そのためさらに現在接続しているデータベース名で絞り込む必要がある。




「表示しかできない」という問題に対しては、show columns は名前の通り本当に表示だけだが、select は sql の中心的な構造なので、素敵なオプションがある。


先のコマンドの冒頭を



SELECT data_type INTO @type FROM ~


と変えてやる。 INTO @type が挟まっただけだ。

しかし、これで「表示」するのではなく、@type という変数に格納されるようになる。


もう一つ、目的外のデータベースも検索対象になることについては、WHERE の直後を変えてやる。



~ WHERE table_schema=database() AND tabel_name~


これで、データベースを絞り込める。




ここで、@type には varchar か、tinyint が入っているはずだ。

目的は、varchar の時だけ、tinyint に alter table することなので、



IF @type='varchar' THEN
  UPDATE [table] SET [col]='0' WHERE [col]='';
  ALTER TABLE [table] MODIFY [col] tinyint DEFAULT 0 NOT NULL;
END IF;


みたいな感じで処理してやればよい。


ただし、このまま mysql クライアントで流し込むとエラーになる。

; は「mysql サーバー的には」コマンドの区切りなのだが、「mysql クライアント的には」命令の終わりを兼ねるためだ。


DELIMITER で命令の終わりを変えられる。

なので、最初に DELIMITER で // を命令の終わりに変え、全てが終わった後で元の ; に戻してやるといい。


最初の SELECT から含めて全部を書くと、次のような感じになる。



SELECT data_type INTO @type FROM INFORMATION_SCHEMA.COLUMNS
  WHERE table_schema=database() AND table_name=[table]' AND column_name='[col]';
DELIMITER //
IF @type='varchar' THEN
  UPDATE [table] SET [col]='0' WHERE [col]='';
  ALTER TABLE [table] MODIFY [col] tinyint DEFAULT 0 NOT NULL;
END IF;
//
DELIMITER ;




同じことで悩んでいる人、結構多そうだと思うのだけど、探してもそういう記事を見かけなかった。

ただ、「show columns の結果を変数に入れたい」とか、「文字列から数値のキャストの癖が強すぎる」とか、悩んで解決できていない記事は多数見つけた。


それらがすべて、僕と同じ悩みで書かれたわけではないだろう。

でも、同じ悩みの人の解決の手立てになれれば、幸いである。



▲目次へ ⇒この記事のURL

別年同日の日記

04年 タワーリング・インフェルノ

15年 スーパーマリオとパックランドの関係性について


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

久しぶりのperl  2019-11-20 17:03:07  コンピュータ

▲目次へ ⇒この記事のURL

久しぶりに仕事で perl を使った。


現在仕事を受けている会社で、サーバートラブルがあった。

そこで、トラブルに遭遇したユーザーを特定したいという。


ここでのサーバートラブルは、「サーバーに接続できなかった」というトラブルだ。

そのため、サーバーには接続できなかった人を特定するログは残っていない。


しかし、リバースプロクシを入れてあったため、プロクシにはログが残っている。

ただ、このログは通常の WEB アクセスのログであり、ユーザーを特定できる情報が残っていない。



実は、問題のあったアクセスは POST アクセスなのだ。

そして、POST の body データとしてユーザーを特定できる情報が入っている。

body として送られるデータは一般的に大きいため、普通はログに残すような設定にしない。


つまりは、問題のある URL にアクセスした個人を特定したいのだが、その個人を特定する情報は記録されていない。



いや、まだ手はある。

知りたい URL アクセスには個人特定情報は入っていないが、その前に必ずアクセスする URL は GET アクセスで、この時は URL パラメータとして個人を特定できる情報があるのだ。


そして、これは「直前の URL」なので、おそらくは問題となる URL のアクセスの際にも、IPアドレスは変わっていないだろう。


ただ、IP アドレスは使いまわされる可能性がある。

IPアドレスだけで「同じユーザーのアクセス」と認定するのは危険で、user agent 情報も一緒に使うのが良いだろう。




まとめると、つまりこういうことだ。


・特定 URL にアクセスして、接続できなかった (status が 302だった)個人を特定したい。

・特定 URL アクセスには個人特定の情報はないので、直前の別 URL アクセスの際の情報を使用したい。

・2つの URL の間が「同じユーザー」であることは、IP アドレスと user agent の一致で確認。


さて、これを2万行ほどあるログに対して、処理したい。

トラブルの事後処理なので、できるだけ早急に。



あぁ、これは perl の出番だな、と瞬時に判断したが、perl 使うの久しぶり。

大丈夫だろうか、と思いながらスクリプトを書き始める。


結論から言えば、うっかりミスはあったが過去のノウハウは活きた。




WEB サーバーのログは、基本的にスペース区切りなので、情報を得たいときはスペースで分割する。

…という風に、処理慣れしていないプログラマなら思うだろう。


perl では、1行にスペース区切りで複数のデータが入っているときは、


split;


というたった一命令で分割処理が終了する。

以前、perl の命令は暗黙のデフォルトが多いという話を書いた。


本当は、split 命令は、「分割したいデータ」と「分割する文字」を与え、「分割した内容を受け取る変数」に代入を行う必要がある。


しかし、全部省略すると、$_ (通常は、現在注目している行)を連続したホワイトスペースで分割して、@_ (一時的な配列)に入れてくれる。とても便利。


なので、WEB サーバのログでも、split で分割したくなってしまうのだ。



でも、WEB サーバーのログの中には、「スペースが許容されている情報」が収められている。

サーバーにどのようなアクセスがあったか、という情報と、user agent は、内部にスペースが入るのだ。


そのため、スペースで区切ると、情報の途中で区切られてしまうし、分割後の「情報」の位置が安定しないしで、処理しづらいことこの上ない。



もちろん、ログ内で混乱が起きない工夫はあって、スペースを含む情報は " (ダブルクオート)で括られることになっている。

だから、ダブルクオートを見つけたらその内部をひと固まりとして処理するようなプログラムを書けば…



というのは、正攻法だけどひたすら面倒くさくて時間のかかる道。


発想を変えよう。最初に、" で区切ってしまえばいい。


アクセス情報と、user agent は " で括られているのだから、この段階で適切な位置にある情報が取得できる。


IP アドレスやアクセス時刻は、" で括られない情報なので、上記処理で手に入った断片を、さらにスペースで区切る。


これで、各種情報が手に入る。


過去に何度も WEB サーバーのログを処理していたので、こういう処理ノウハウはすぐに思い出した。




さて、まずは、「直前の GET アクセス」から個人を特定できる情報を拾い出そう。


これは、特定の URL を条件として、正規表現で拾い出してやれば終わりだ。

IP アドレス、user agent もすでに取得してあるので、この2つの組をキーとした連想配列に、個人特定情報を保存しておく。



つづいて、情報が欲しい「特定 URL にアクセスしたとき」の処理も作る。

この URL も、正規表現で拾い出せばよい。


ただ、この「特定 URL」は、一つではない。

末尾部分がサービスの違いを示す数値になっていて、一人のユーザーが複数の「数値の違う」URL にアクセスしている可能性もある。


そのため、URL の末尾に入る数値も一緒に記録してほしい、とのリクエストだった。

これは、正規表現の ( ) (グルーピング演算子)で取り出す。


ここでの正規表現は「データを得るためのもの」ではなく、if 文の実行条件を示す「比較」にすぎない。

しかし、「比較」でデータを取り出せてしまう、というのも perl の便利な部分だ。


条件はもう一つあった。この、特定 URL のアクセスが「302 エラーになった時」だ。

これも、ログにはステータスが入っているので、302 の時を条件に入れればよいだけ。



さて、無事条件に合うアクセスがあったら、時刻と URL 内部の数値と、個人特定できる情報を1行にまとめて出力してほしい、というリクエストだった。


個人特定情報は、先に書いたように、IP アドレスと user agent に紐づいた形で保存してある。

これを使えばいい。


時刻は、サーバーログに入っている形式と、求められている形式が少し違ったので、変換する。


ログに入っているのは [20/Nov/2019:15:30:28 +0900] という形式。

必要なのは、2019-11-20 15:30:28 という形式。


これも、正規表現でグルーピングを使えば必要な情報が得られるので、整形して出力するだけ。




出力は、2通り用意してほしいと頼まれていた。

まずは、エラーが出たすべてのアクセス。


もう一つは、エラーが出たことで繰り返しアクセスする人も多かったので、「同じ URL への同じ人のアクセスは、初回のみを記録して後は省略」したもの。


まずは、エラーが出たすべてのアクセスを出力し、ファイルに残す。

続いて、プログラムに少し追加。


URL と個人特定情報を組として、一度出力したら「1」を記録するようにした。

この記録があったら出力済み。事前に確認し、出力処理を飛ばすようにした。


これで出力した情報もファイル化する。




さて、ここまで整形した情報を得るまで、1時間程度。

久しぶりの perl としては、まずまずだろう。


しかし、データを送信してしばらくたって、先方から「おかしい可能性」を指摘される。


どうも、「同じ URL への同じ人のアクセス」を省略したほうのデータが、少なすぎるように思うというのだ。



しばらくプログラムを見てみるが、すぐに原因が特定できない。

「すべて」を出力したファイルに対し、unix コマンドの sort と uniq を駆使して「同じ URL への同じ人のアクセス」を省略したファイルを作ってみる。


明らかに数が違う。データ件数で、15 倍くらいの情報があった。



これ、連想配列のアクセス方法を間違えているためだった。


最近使っている、Javascript でも PHP でも、連想配列アクセスには [ ] を使う。

でも、perl は連想配列は { } だった。


完全に自分の頭から抜け落ちていた「常識」に気づくまで、1時間くらい。

これに気づいて修正したら、出力データ件数が増えた。


出力データを wc してみる。行数や語数を数える unix コマンドだ。


「すべてのデータ」出力は、改良前と後で同じ件数だが、出力データサイズが微妙に違う。


改良前と後のファイルを diff して違いを探す。

どうやら、件数は同じでも、個人特定情報の部分が違う。


改めてプログラムを見て、連想配列アクセスを間違えていたため、個人情報の紐づけが正しくなかった、と判明。

なので、先に作った全件データは誤り。新しい方が正しい。



この正しいデータをもとに、sort | uniq したデータと、プログラムで「同じ URL への同じ人のアクセス」を省略したファイルは、同じ件数・同じ出力サイズだった。


sort した関係で順番などが異なっているのだけど、別の方法で集計しても、プログラムの集計と同様になったことが確認されたので、このデータは正しいと判断。



ここまで、最初の依頼から2時間半ほど。

データを送って確認してもらい、おそらく正しいだろうという判断になった。



#そもそも、確実に正しいか確かめる方法はない。

 正しいデータがないから、こんなプログラムをしているのだもの。




…と、今日記を書いていて、ここで終わろうと思ったところ、ちょうどバグ報告が来た。

出力の中に、「個人特定情報」が入っていない行がある、とのことだった。


元になるアクセスログを開き、「報告すべきエラー行」を特定する。

それから、そのエラー報告に含めるための、「個人特定情報」を拾い出せる、事前の行を探し出す。



…ここで、ミスをした。

というのも、「個人情報」は当然ないので、バグ出力に含まれる情報で行を探したが、実は該当行が2行あったのだ。

しかし、僕は「時系列で上にあった行」だけを見つけて、その行を元に周囲を調べ始めてしまった。


どう考えてもデータはおかしくないので、自分のプログラムのミスだろうと探すこと30分以上。


いろいろ確認してもおかしくないので、データに戻り、再度おかしいところを探す。


この作業中、やっと自分の過ちに気づく。


そして、2行目の該当行を元に、同じ IP アドレスでアクセスしている「事前の」行を調べると、存在しなかった。

事前アクセスがないので、「事前のアクセスから」情報を引っ張ってくることはできない。

プログラムには問題はなく、データの問題だった。



ここまで確認して、報告。

ついでに、事前データはないものの、「事後の」アクセスから個人を特定できたので、その情報も報告。


ひとまず作業終了となった。




昨日日記に書いた「遊びの」プログラムもそうなのだけど、こうしたパズル的なプログラム作業は、やっていて楽しい。

保守性とか読みやすさとか考えないで、ただ動くプログラムを書けばいいからね。


仕事なので時間制限もあったりするのだけど、それも踏まえて「最短時間で解決するにはどうすればいいか」というような段取りから考えるのが楽しいのだ。





▲目次へ ⇒この記事のURL

別年同日の日記

01年 11/19

02年 80歳で歯を20本残そう

04年 最後の親不知

06年 絵本

13年 任天堂の会社設立日(1947)


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

遊びプログラム  2019-11-19 17:49:06  コンピュータ

▲目次へ ⇒この記事のURL

今日は一日仕事があいてしまったので、遊びプログラム。

まだ完成していないし、明日からは普通に仕事に戻るので、完成するかもわからない。




Twitter をエゴサーチしているが、ファミコンの画面についてのページを引用してくださった人がいた。


ファミコンでは 52色表示可能、という、表示できる色の一覧だな。


どうやら、その人は「ファミコンの表示」に興味があり、適当な画像をそれっぽくするフィルタを作っていたらしい。


Twitter のログを追って分かったことには、最初は「適当な54色」に減色してみたものの、どうも「それっぽい」画面にならないので、情報を探して僕のページを見つけたようだった。


どうも、当初は RGB 空間を適当に区切って 54色にしたようだ。

しかし、どこかで「RGB ではなく、NTSC の Y/C 空間で考えないといけないようだ」と、情報を探して僕のページに辿り着く。


そして、そこで


・既定の 52色

・16ドット以内で使えるのは、背景色含めて4色だけ

・その4色の組み合わせは、全画面内で4セットだけ


という厳しい条件を知り、「なんだかわからない」とツイートして終わっている。




さて、僕も以前から、ファミコン風画面フィルタは作ってみたかった。

ちょうどよい機会だから、「厳密にはしない」つもりで作ってみる。


とりあえず、52色減色から。

RGB を HSV に変換してからファミコンパレットに適用してみようと思ったのだけど、難しい。

H 信号を参考にして、「パレットの近いあたり」までは見つけられるとわかったので、その周辺を総当たりで「近い色」を探すようにしてみる。


とりあえず、ファミコン 52色への減色はこれでできた。

ディザをかけたりしないので、最適な画像変換ではないけれど。



つぎに、52色自由に使ってはならない、という制限をかけてみる。

使われる色を集計し、上位 12色しか使ってはならない、としてみたら、まだまだ綺麗な絵が出る。


では、6色まで落としてみよう。

というのも、グラディウス2のデモ画面で、ビッグバイパーの絵が6色で書かれているからだ。


…いい具合に「色合いが不自由」な感じが出て、ファミコンらしくなった。




つづいて、「16ドット以内に4色」という制限を作ってみる。

4色のうち1色は「背景色」なので、一番使われている色を背景色にすることにして、それ以外の色で 16ドット以内で使用頻度を集計する。

これで、上位3色+背景色で描けば、それらしくなる。


…案外、きれいな絵が出てしまう。

いろんな絵で試すと、多少不自然なところも現れるが、この条件だけではまだ「ファミコンらしさ」が出ないようだ。


やっぱり、「全画面で3色セットを4つまで」の制限も入れないといけないだろうか。




ファミコン画面は 256x224 (縦方向は VRAM は 240 ドット分あるが、表示は 224ドット程度とすることが多い)として、16x16 ドットのタイルで区切ると、16x14 タイルになる。


それぞれを、背景色を除いた3色に減色したうえで、同じ色の組み合わせになった数を集計する。

そして、使われた数が「少ない」パレットを、使われた数の「多い」パレットに吸収する。


吸収する際は、3色のうち少なくとも2色が同じパレットに吸収することにした。

この際、使用された数もちゃんと吸収させる。


できる限り吸収を繰り返したうえで、改めて集計された使用数の順に並べ治す。

最終的に、上から4つのパレットを採用する。



そして、このパレットを使って画面を描くと…うん。いい感じに四角く色が化ける。

ファミコン時代にはよくあったよね。無理やり感のある絵。




しかし、四角い不自然さはあっても、まだファミコンにしてはきれいすぎるのだ。

それは、画面全体で、色以外は自由に絵を描けてしまっているから。


ファミコンは、8x8 ドットのキャラクターを並べて絵を作る。

このキャラクターは 256種類しか定義できないのに、画面全体は 896マスある。


だから、自由に絵を描くことはできないのだ。

色だけをファミコン風に変換しても、キャラクターの不自由さで違和感がある。



本当は、「似た部品」を探し出して、無理やり共通化することで不自然さを出していけばよいのだけど、そこまでやるのは結構面倒だ。


そこで、せめて「四角い塗りつぶし」を増やすことにする。

8x8 ドットの範囲内、64ドットのうち、52ドット以上同じ色だった場合には、思い切って 8x8 を塗りつぶしてしまう。


52ドットに根拠はない。色々試して、それくらいがなんとなくいい感じだった、というだけだ。

塗りつぶし部分は、絵としては「使いまわし」になるので、絵が自由に描けない不自由な雰囲気が出る。



とはいっても、これでも絵がある部分が 256マスには収まらないのだけど…

かなり塗りつぶしが多い絵でも、256以上のキャラクタを定義したことになってしまう。




まぁ、遊びプログラムなので、本日はここまで。


あまり満足いく結果が得られていないので、公開するにはまだ早いかな…



▲目次へ ⇒この記事のURL

別年同日の日記

01年 11/18

02年 また風邪?

04年 地鎮祭

08年 エジソンロック

18年 なにもしてないのにこわれました


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

イベント終わりました  2019-11-17 15:45:02  コンピュータ

▲目次へ ⇒この記事のURL

イベント終わりました

先日書いた日記の続き。

しばらく日記書いてなかったもので、リハビリみたいなもので、どうでもいい身辺雑記書いてます。




現在一緒に仕事をしている会社、別に名前とか出してもよいとは言われているのだけど、この日記上では名前出していない。

その仕事先の名前(商品名でもある)で検索されて、中の人だとわかるのもなんとなく嫌なので。

(僕はその会社の手伝いをしているが、社員ではない。そんな人の話が会社の意見だと思われても困る)



でも、前回リンクした記事を読めば、何の仕事かはすぐわかる。

「このページを読んだ人が知っていてもいいが、商品情報を頼りにしてここに来ないで欲しい」ということだな。




で、土曜日の夜に、東京ビッグサイト…の「壁」に、映像作品を投影するコンテストが行われた。

いわゆるプロジェクションマッピングというやつです。


応募資格は学生だったのかな。

大学生や専門学校生。プロの映像作家はダメだけど、映像の専門校生はいい。



本番は土曜日だったのだけど、金曜日の通しリハーサルに立ち会った。

一応、本番終わるまではリハーサルの話とか書いちゃまずいだろ…と思っていたので、日記に書くのは本番が済んだ今日になった。




このコンテストでは、最終審査は審査員がやったのだけど、「一般審査」として、見た人は誰でも作品の点数をつけられた。

最終的に、平均点が高いところには「観客賞」が贈られる。


(結果、審査員が付けた「最優秀賞」と、「観客賞」は同じチームだったようだ。

 僕は本番ではなくリハーサルで見ただけだけど、このチームは群を抜いて出来が良かった。納得の結果だ。)



一般審査の投票システムとして、一緒に仕事をしている会社のシステムが使われた。

ビッグサイトの壁面に QR コードを表示し、そこから誘導される WEB ページで「投票」すると、リアルタイムに点数が集計されるのだ。


壁面は非常に大きいし、見た人は誰でも投票できる。会場の広場で見ている人は当然、数百メートル離れたところの人だって参加可能だ。

そういう「ゆるい」審査なのだけど、そうした集計ができるシステムは、案外少ないのだ。



そして、集計結果は…点数は、リアルタイムには表示しない。それは、最終結果の発表までのお楽しみ。

その代わり、映像について感じたことを「すごい」「楽しい」「かっこいい」の三択で選んでもらっているので、その割合を表示する。


円グラフがリアルタイムに動いているものが、ビッグサイトの壁に表示される、というだけなのだけど、この部分のシステムを僕が担当しました。


これがね…前日リハーサルまで、実際の映像が見えないので、想像で作るしかなかったの。

文字が大きくないとつぶれちゃうんじゃないか、コントラストが強くないと見えないんじゃないか…って、想像で作り上げるしかない。


直前の日記に「必要なら現地で最終調整」と書いていたのはそのため。



表示してみたら、十分にきれいで何も調整は必要ありませんでした。




一応、円グラフを動かす部分は普段から使っていたプログラム。

でも、普段は円グラフの横に「凡例表」があり、そこにアンケートの内容などが書いてあった。


(グラフの領域には、1 2 3 という数字だけがあり、横に対応表があるわけです)



でも、今回はビッグサイトの三角形の外壁に表示したので、凡例表を出すことはできなかった。

グラフ内に直接文字を入れてほしい、と言われていました。


最初の段階から、「グラフが細くなると、文字重なっちゃうと思うよ?」と言っていたのですが、実際作ってみたら予想以上に深刻でした。


先に書いたように、プロジェクションだと細かな部分がつぶれやすいので、文字をできるだけ大きくしないといけない。

当然大きい方が重なりやすいわけだけど、その状態でも「割合を示す % 部分は読めるようにしたい」という要望がありました。



もう、事前に試行錯誤の連続。幸いなのは、選択肢が3つしかなかったこと。


選択肢が3つだから、「細い領域の両隣のうち、少なくとも一方は表示面積に余裕がある」と確定しています。


そこで、表示面積が細い場合(具体的には、角度にして60度以下になった場合)は、両隣のうち、より広い方にはみ出して文字を表示してもよいことにしました。


(具体的なアルゴリズムとしては、文字は表示領域の中央に出すのだが、60度以下の場合は、広い方にはみ出して60度あるものとした中心に表示を行う)


ただ、両側とも十分に広いばあには、今度逆に「片側に文字が寄る」表示は不自然。

そこで、こうした場合は広い方に寄せる処理をしない、とか、いくつかの場合分けを行います。



これでもまだ、1つの領域が 80% とかとってしまうような極端な状況では、文字同士がぶつかることがありました。


そこで、20% 以下になった場合には、文字サイズが小さくなっていくようにします。

20% 以上なら 100% の文字サイズで、10% 以下なら 80% 。間は滑らかにつなぎます。



これで、問題のないグラフ表示になりました。




この表示、評判良かったので今後も使えるようにしたい…と、仕事先の社長から言われてます。

でも、それなら3つ以上の選択肢でも使えるようにしないと。


今は、文字の表示中心が、円グラフの中心から等距離のところにあるのだけど、本当はこれも可変にしたい。

グラフ中央から「近い」「遠い」をうまく組み合わせれば、もっと文字を表示しても読めるはず。


ただ、そうなってくると文字同士の当たり判定を入れたいのだよね。

今のグラフ表示基礎ルーチンは僕が作ったものではなく、そこまで複雑なことができる作りになっていない。


もっというと、データが決まっていて「うまく表示する」目的なら、内部的に試行錯誤して最適配置を求められるのだけど、リアルタイムに移り変わるのを違和感なく表示するのは至難の業。


まぁ、そこがゲーム的で面白そうなチャレンジだと思ってる。

(試行錯誤させてもらう時間があればね)


▲目次へ ⇒この記事のURL

別年同日の日記

02年 友人宅へ

11年 バックアップとデフラグ

13年 1週間の記録

15年 ハーマン・ホレリス 命日(1929)

15年 ハムスター死去


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

メールの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年 びわ


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


戻る
トップページへ

-- share --

16000

-- follow --




- Reverse Link -