■山田祥平のRe:config.sys■
 |
ぼくらの暮らしにおいて、時刻というのはとても重要な要素だ。どんなものでも、時系列で並べて見れば、そこに含まれる意味が見えてくる。コンピュータのおかげで、電子化さえされているデータなら、並び替えは簡単なはずだが、あまり重要視されていないようにも感じる。
●各種デバイス用アプリの充実が待たれるSkyDrive各社のストレージサービスが始まったので、とりあえず、自分のドキュメントフォルダの内容をサービスに預けることにした。量を確認したところ、ドキュメントだけなら数十GBに過ぎなかったので、SkyDriveの容量を4,000円/年で100GB分契約し、これまでの無償ストレージとあわせて125GBまで増量した。
専用アプリをインストールし、設定したローカルのSkyDriveフォルダに文書をコピーすると、自動的に同期が始まった。最初の試みなので、念のために移動ではなくコピーにしておいた。
なんとか3日ほどかけて30GB分ほどのデータを同期できた。ビットレートにして2時間で1GBといったところだろうか。思ったよりは時間がかかった。
同期途中でエラーも出た。Windows Live Meshで同じフォルダを別領域に5GB分の同期をしていたのだが、それを止めるの忘れていて、5GBの制限にひっかかってしまったのだ。これは、Meshで同期を停止して対処した。
また、順調に同期ができているように見えて、ファイルのアイコンに赤い×印がつくものがある。どうやら、一部の記号が使われているファイル名やフォルダ名が同期できないようだ。ぼくがひっかかったのは、2バイトのスラッシュやコロンだ。
これらはローカルのファイルシステムでは何の問題もなく使える記号なので、今まで困ることはなかった。通常の文字入力ではこれらの文字は1バイトで入れるが、OSにとっての特殊記号であることがわかっているので、ファイル名やフォルダ名には、2バイトの文字を使っていたのだ。たとえば「DOS/V」とか、この連載のタイトルなんかがそうだ。
Windows PCとの「同期」を謳う限り、Windowsのファイルシステムで使える文字が使えないというのはどうかと思う。数的にはそれほど多くはなかったので、手動ですべてを修正して対処したが、数が多かったらちょっとたいへんだったかもしれない。また、登録したブックマークの多くは、ページタイトルがそのままファイル名になっているが、そこに2バイトの記号が頻繁に使われている。これらについても対処が必要だった。
全ファイルの同期が終わるころには、同じ設定をしていた各ノートPCでも同じように同期が終了し、これで常用している全PCで、同一のドキュメントフォルダが使えるようになった。
ここまでは、Windows標準のオフラインファイルの機能でもできていたことだが、クラウドストレージを使えばLAN内にいなくてもインターネット経由で同期ができるのに加え、自分のPCが手元になくてもWeb経由でファイルを参照できることや、AndroidやiOSなどからもアクセスできる点が便利になる。取材先でメモをとっても、そのとき使っているノートPCがインターネットに接続できていれば、自動的にそのメモ内容がSkyDriveに同期されるので、万が一、ノートPCが盗難や紛失にあったり、クラッシュするようなことがあっても、データの無事が保証されるというわけだ。
WebでSkyDriveを参照してみたところ、タイムスタンプも維持されている。ぼくは、よく使うフォルダについては、直近の作業対象がすぐにわかるように更新日付の新しいものから順に表示するようにしている。SkyDriveのサービスページにおけるファイル一覧では、フォルダが先頭にくるのにちょっと違和感があるが、まあそこには目をつぶることにする。
PCについてはそれでいいのだが、AndroidのSkyDriveアプリをいくつか試してみたところ、更新日付については全滅だった。得ている更新日付もアップロード日付になっている。しかも検索機能がないため、大量のファイルがあるフォルダではお手上げだ。というか、ファイル名はデータ保存のための手段に過ぎず、よく覚えていないことが多いので、やっぱり困ってしまうのだ。
●デジカメ写真の撮影日付自分で作ったファイルについてはタイムスタンプを使って直近の作業を思い出せるようにしたが、デジカメが自動的に生成したファイルについてはどうだろう。
ぼくは、日本国内を出て撮影する場合は、カメラの時計を現地の時間に修正してしまうのだが、GPSを使って位置情報を書き込むようになってからは、カメラ自体の時刻をUTC(協定世界時)に固定して運用することも考えた。
ただ、メタデータの位置情報と時刻を照らし合わせて、ローカルタイムを表示するといったアプリケーションが見つからず断念した覚えがある。そうでなければ、写真を撮ったタイムゾーンと、UTCとの時差、サマータイムの有無などを換算する必要があり、とても面倒なことになってしまう。
EXIF策定の際に、こうしたことが考慮されなかったことが、実に残念だ。とても今からでは変えることはできないだろう。ワールドタイム機構を持ったカメラもたくさんあるが、単に時差とサマータイムによって時刻を変えるだけで、UTCとの時差を考慮して記録するものはないようだ。
写真のデータに関しては、SkyDriveに同期されたものを見ると、他のファイル同様に更新日は維持されている。ただし撮影日と更新日が異なる場合はこれでは困る。撮影日の確認にはファイルの情報を見るしかないようだ。このあたりのサポートはもう少し何とかならないものかと思う。Windowsのローカルフォルダなら、メタデータに含まれる好きなフィールドデータを見出しにして並び替えができるので、WebのSkyDriveには、ちょっとした不便を感じてしまう。
●Twitterのタイムライン他人の作ったデータの時系列はどうだろう。例えば、Twitterのタイムラインは、その代表的なものだ。
他の人がどうしているのかわからないのだが、ぼくは基本的にタイムラインを過去から現在に向かって読みたいと思っている。自室で作業している間は、Twitterクライアントは、ずっとタイムラインを更新し続けるので、それをチラチラと見ていれば、結果としてタイムラインを過去から現在に向かって読み進められる。
これは、スマートフォンでも同様で、ぼくの使っているアプリは既読位置を記憶することができるので、上に向かってスクロールしていくことで、現在に向かうことができる。この既読位置を各種デバイスで共有できればどんなに便利かとも思うのだが、これはまだ一部の限られたアプリでしか実現されないようだ。
各種アプリがこうした機能をサポートしないのは、TwitterのWebサービスが、基本的に新しいものから古いものに向かうように作られているからかもしれない。つまり、多くの人は、新しいものから古いものにさかのぼってつぶやきを読むことに抵抗を感じていないということだ。
ある程度古いつぶやきは意味がないととらえ、全部読むことをあきらめるというのも考え方としてはありだ。本当に重要なメッセージは、いろいろな人がリツィートするので、きっと新しいタイムラインで目にとまるだろう。それを時間順に全部読みたいというのは古い考え方なのかもしれない。
●スタックとキューメールはどうかというと、こちらも新しいメッセージから古いメッセージに向かって順に並んでいる。新着メッセージは、その先頭に割り込む形で着信する。電話の着信履歴なども同様で、すでにあるものの先頭に最新のものが割り込むというのは考え方として結構おもしろい。
データは、先に入ったものが先に処理されるというのは、古き時代は当たり前なんじゃなかったか。
例えば病院での診察待ちで、先に診察券を出した人は、あとの人よりも先に診察してもらえる。未決書類が山積みという場合も、基本的には積み上げた山の下から処理するものだった。これがキュー(待ち行列)だ。
でも、コンピュータの世界には後に入ったものが最初に取り出されるスタックという考え方もある。
Twitter、Facebook、メール、伝言板メッセージ。どれもが新→旧の時系列が標準になりつつある。つまり、スタックだ。並び替えが瞬時にできるはずのコンピュータではあるが、他者とのコミュニケーションが主要な使われ方になって、時系列の位置付けが変化しているように思えてならない。このままだと、追えない過去は切り捨てということも当たり前になりそうだ。だからこそ検索があるのだと、どこかから声が聞こえてきそうではあるのだが。