無人店舗 open vs close

 労働者人口の減少に伴い。様々な対策が必要になっている。中でもコンビニの省力化は重要である。コンビニでの雇用が減少することで不利益を被る人もいるが、コンビニ経営自体が足り立たなくなると本末転倒である。コンビニは社会インフラとなっている。

無人店舗には様々な方式がある。ここでは視点を変えてopen、closeと分類してみる。

open型とは、店舗が人に対して解放されている形態であり、人が店舗に入る。いわゆるウォークスルー型だ。Amazon Go, TOUCH TO GOなどの事例がある。入口ではスマホで客を認証し、店内ではカメラやセンサーで客がどの商品を手に取ったかなどの行動を認識し、出口では決済する。この方式は、実店舗に近く、馴染みやすい。状況によっては、入口での認証を省ける場合もある。

close型とは、店舗が人に対して解放されていない形態であり、人が店舗に入らない。いわゆる自動販売機型だ。auミニッツストアなどがある。アプリで注文し、店舗で受け取る。この方式は、ロボットなどを必要とするため、設備投資が大きくなる。しかし、防犯対策や在庫管理などに有意性がある。

私は、かねてよりコンビニで予約購入をしたいと考えていた。店舗に行くと欲しいものが売り切れていることがあるからだ。予約時に決済まで済ませておけば、確実に購入できるはずだ。もっとも配送スケジュールにもよる。Amazonなどの配送を参考にすれば、前日に予約すれば翌日には確実に入手できるはずだ。このような予約購入に適しているのはclose型である。

理系プログラミングと文系プログラミング

受験生はやむなく理系か文系かを選択しているが、理系と文系の区分は本来あいまいなもので、あまり決めつけは良くないと思っている。プログラミングを理系と文系に分類するのも不本意ではあるが、他に適切な呼び名を思いつかなかった。

プログラミングに２つの流れを感じる。理系プログラミングと文系プログラミングだ。いずれも、ここで名付けたものなので一般的な概念ではない。

理系プログラミングは、競技プログラミングに代表される問題解決のためのプログラミングだ。ここでの問題解決は、社会的な問題の解決ではなく、出題された問題を解くことだ。しかし、正しい答えを出すだけでなく、計算時間等様々な制約を満たす必要がある。そのためにはプログラミングの技法を極める必要がある。

文系プログラミングは、実際に役立つアプリケーションを開発するためのプログラミングだ。アルゴリズムよりライブラリやAPIなどの知識が重要である。

どちらも重要であるが、１つの科目で両方を目指すのは難しい。理系プログラミングはアルゴリズムなどのCS系科目で学ぶことができる。しかし文系プログラミングは応用分野により異なる。それぞれの専門科目（必ずしも文系科目ではない。むしろ理系科目）で学ぶ必要がある。

理系・文系の命名は不適切かとも思う。理系は深さ、基礎などを意味し、文系は広さ、応用などを意味する。適切な語を思いついたら、紹介したい。

マドラー付きスティックコーヒー

 スティックコーヒーはインスタントコーヒーを飲みやすくした。わざわざ軽量する必要もなく、最初からミルクや砂糖を混ぜておくこともできる。

お湯だけ準備していざ飲もうというときに、スプーンもマドラーないことを思い出す。そこでスティックごとに簡単なマドラーを入れておいてはどうだろう。箱の容器に入れてもよいのだが、いっそのことスティックの中に入れてしまう。攪拌さえできればよいので、飴の棒のようなもので十分だろう。

IT的政党

民主主義の原理は集合知だろう。

であるなら、それを突き詰めてはどうか。

つまり、私心を排除し、民衆の声だけで政策を定める政党を作ったらどうだろう。例えば、政策を提案し、一般から投票してもらい、多数決で決める。議員本人の意向は一切関係ない。決まったことは党の政策として実現を目指す。

ある意味、N党と同じくシングルイシューであるが、汎用性が異なる。

間接民主主義を否定する試みかもしれないが、中道の意見を集約できるかもしれない。

飛行機が飛ばなければ

地上で格安ホテルにしてはどうだろう。
もともと機内宿泊できる設備がある。
燃料も使わないし、係留費が賄えればよい。
有料機内サービスも可能だ。
映画も見放題。
羽田は普通に国内線の需要があるので無理する必要はない。
成田は遠すぎるかな？

産業革命の本質

人類の歴史において、産業革命ほど画期的な変換点はない。
人口推移のグラフを見ると産業革命を契機に爆発的に人口が増加していることがわかる。
いわゆる指数関数的な増加である。
その他の革命、例えば農業革命などは微々たる影響しか及ぼしていない。
つまり、産業革命は革命の質が他の革命とは本質的に異なる。
しかし、産業革命が単なる蒸気機関の発明に過ぎないなら、それほど大きな影響を及ぼしたことを説明できない。
私見であるが、産業革命とは、科学が（当時はまだ富裕層の）庶民にまで普及した結果、継続的なイノベーションが起こるようになったことを意味するのだと思う。
蒸気機関に続いて、紡績機械なども発明された。さらに幾多の発明が今日まで続いている。
産業革命によって始まったイノベーションの連鎖は今日まで継続しており、それゆえ指数的に発展するのだろう。

その意味では、今日もなお産業革命のただ中にあると言える。

よって、産業革命を第２次以降に分類することは無意味である。

ただし、これまた私見であるが、コンピュータやインターネット、マスコミュニケーションに代表される情報革命は非物質的な発展を目指す意味において新たな革命と言えるだろう。

WorldEye

WorldEyeは学研のデジタル地球儀だ。
正確には半球形ディスプレイだ。
様々な応用が考えられる面白いデバイスだ。

表示できる動画および画像のサイズは480 x 480である。
例えば、以下のような画像を表示させてみる。

付属USBメモリのFREEフォルダに入れ、本体のメニューで選択すればよい。
ちなみにmini HDMI端子が付いているので、PCの映像も表示できる。ケーブルが手元にないので、まだ試していない。

上の図は円を等間隔で描いたものだ。しかし、残念ながらWorldEyeでは等間隔で表示できない。見た目には気にならない程度だが、中心は短く、周辺は長くなる。もっとも内側の円の半径は約4.6mmだが、順に4.7mm、4.95mm、5.3mmと間隔が長くなる。微妙に比例でないのが困る。中心と周辺で約1cmの差ができるので、無視するわけにもいかない。

この辺は座標変換の問題なのか、デバイスの問題なのかよくわからない。
ちなみに、WorldEyeの地球儀データはきちんと補正されている。

おそらく魚眼カメラの映像を表示したり、Ricoh Thetaのパノラマ映像を表示することを考える人がいるだろう。
しかし、魚眼カメラの比率とはかなり違うし、Thetaの映像とは向きが違う。単純にはいかない。
魚眼カメラではないが、Google Earthを表示してみたので、比べるとよい。経度の長さがかなり違う。

Leap Motion + Smartphone

マルチタッチが革新的なスマホを生んだ。（単にスマホがマルチタッチを選んだだけかもしれないが、マルチタッチがなければスマホの成功はなかったろう。今まで失敗し続けたPDAが証明している。）
さらに、もう一段進化すると、今度はノータッチになるかもしれない。Leap Motionとスマホの組み合わせだ。スマホ画面から離れたところでアクションし、操作するようになるかもしれない。
Leap MotionはKinect同様の赤外線3Dスキャナ、モーションセンサといってよい。
現在のところ、かなりのCPUパワーを必要とするが、スマホがそれだけのパワーを手に入れるのは時間の問題だ。
ただし、片手がスマホで埋まってしまうことがおしい。どのように使うとよいか考えることが楽しい。

ヒトを知るプロジェクトからヒトを創るプロジェクトへ

少し前はヒトゲノムが話題になった。実に実りあるプロジェクトだったと思う。
今度はヒューマンブレインが話題となっている。同様に多くの成果が期待できる。

しかし、ゲノムに比べると成果は限定的となる。
機械による知性は楽観的にできるだろうと予測する。
しかし、より欲しいのは知識のコピーである。
ヒトが考えるしくみがわかったとしても、生きている人の脳に干渉できなければ、コピーはできない。
よって、ナノマシンの研究が不可欠である。むしろ、ナノマシンの成果に依存している。

ヒトの脳にチャレンジすることは意義深い。
しかし、人工知能を作るだけなら、必ずしもヒトである必要はない。知性が最低でもあるとされる生物であれば、何でもよい。
しかし、ねずみの脳が大きくなればヒトの脳になるかどうかは断言できない。

人は脳だけで生きている訳ではない。
生命の定義は有機であるがゆえに、人工知能は機械である。
人工知能の進化には、五感が重要である。
少なくとも視覚、聴覚は脳と直結して学習する必要があるだろう。
これらのインターフェースもヒューマンブレインの成功には不可欠であろう。
あるいは、これらがあれば、もっと豊かな成果が期待できる。

よって、ブレインの次は人体の創生が課題となるだろう。
再生医療の発達も時期を同じくしている。
個別に作成した臓器を組み合わせる方法がもっとも初期に選択されるだろう。
この場合、新たな生命を生み出すのではなく、医療の一環として考えられる。

次は、人工細胞が課題となるだろう。
細胞から分化し、発達する過程を調べる。
さらに発達の過程を制御し、不具合を除去する必要がある。
また、事前に遺伝疾患を除去しておく必要がある。
これにより発達障害の多くが克服されるだろう。

フォグレットの課題

フォグレットは、現実世界に仮想空間を実現できるだろうか？
将来的な問いの意味により答えは変わる。

仮想世界を物体として実現したいなら、多くの課題があり、困難である。
１つは、当然だが、ナノテクの進歩によりフォグレットが実現できることが前提である。
１つは、フォグレットの結合方式が問題となる。機械的な結合でなければ加えられる力に耐えられない。極端な話、自重で瓦解する。
１つは、エネルギーの供給である。無線による電力供給を仮定しているのでは、永続的な仮想空間は実現できない。同様にエネルギーが必要となる磁気的な結合も困難である。

現実的な可能性としては、3Dプリンタなしに3D造形を実現するクレイとしての応用であろう。
単に形を作るだけなら、エネルギーの問題も発生しない。結合方式も機械的でよい。ただし、用途によっては強度が足りない可能性もある。

仮想世界をフォグレットのみで仮想的に実現したいなら、可能かもしれない。
フォグレットは人体の内部から視覚と聴覚を操作する。
どうやってというのはよくわからない。これも当然課題の一つだ。しかし、できるという人はいる。
この方法は理性を保ったまま幻覚を見ているようなものだ。
物理的制約はずっと少ないが、倫理的制約はずっと高くなる。
文化は技術ほど簡単には変わらない。しかし、技術がある世代の大半に普及したとき、文化は一気に変わる可能性がある。それでも、その他の世代との競争により淘汰される可能性がある。

Kindle

Kindleを買った。
今までは、iPhoneにもKindleアプリを入れているので、わざわざ買う理由がなかったのだが、iPhoneでは画面が小さすぎるのでKindle購入に踏み切った。
今回の購入は自分のためではなく、スマホが使えない人向けだ。
紙に比べて便利な点が多くある。
1. 字を拡大できる
2. その場で辞書を引くことができる
スマホに比べても利点がある。
3. 画面が大きい。
4. 消費電力が小さい。
5. 価格が安い。
もちろん欠点も多々ある。しかし、価格や消費電力とのバランスの問題だ。

Kindleを家族で使い分けるには、アカウントで接続した後、コンテンツをダウンロードし、使わせる前にアカウントの接続を削除すればよい。

ここで、電子書籍について改めて考えてみたい。
もしも、すべての書籍が電子化されたらどうなるだろう。
90%は問題がないどころか、便利になるだろう。
しかし、残り10%が解決できない限り十分とはいえない。

例えば、絵本は難しい。
PC並みの大画面のデバイスを使えば、従来以上の絵本ができるのはわかりきっている。しかし、絵本を見る子どものためにそのような高価なデバイスを買う親がどれだけいるだろう。絵本だけでは、デバイスの価格に対して十分な価値があるとはいえないだろう。
むしろ、スマートTVのアプリとして位置づけた方がよいかもしれない。
メディアに応じて出版部門の再編が必要かもしれない。

次は付録付き雑誌だ。
付録というリアルなモノが主役なので、電子書籍にはなりえない。

低学年向き学習教材も電子化が難しい。
ユーザの年齢が、デバイス自体を使えないほど低いからだ。
とはいえ、小学校１年生でもタブレットは十分に使える。
学校でタブレットを使わないのは、単に導入コストが大きいからだ。
タブレットがあれば、問題なく使える。
実際、ベネッセは教材としてタブレットを提供している。個人的にはアプリで十分だと思うが。
教科書会社が教科書に沿った学習教材をアプリとして販売すればよいだろう。
このように家庭では教材の電子化が進むだろう。しかし、学校では電子化はあまり進まないかもしれない。主に経済的な理由により。
低学年向き学習教材は、すぐには電子化されないが、徐々に電子化されるだろう。それでも年齢的な限界はある。

絵本や雑誌だけでは本屋の商売は成り立たないだろう。
Amazonだけがあればよいという未来が垣間見える。

Firebaseで認証付きアプリを作るには

Firebaseはバックエンドサービスです。BaaS(Backend as a Service)と言われますが、Firebaseのサイトには直接BaaSという言葉はなさそうです。
一言で言うと、ドキュメント型データベースとそのライブラリからなるシステムです。ドキュメント型データベースはMongoDBが有名です。Firebaseはデータ全体がJSONです。Firebaseのデータをビジュアルに編集できるWebページを提供しています。
これだけなら単にMongoDBをWebサービスにしても同じことです。しかし、Firebaseが面白いのはAngularJSなどのクライアントサイドフレームワークとの相性が抜群だということです。AngularJS用にAngularFireというライブラリを提供しています。AngularFireでは、MVCをクライアントサイドで実現します。AngularFireのModelは、DOM、Firebaseと３方向に同期されます。その結果、クライアント単体でアプリケーションを実現します。つまり、アプリケーショサーバがいらないのです。

Firebaseにはホスティングの機能があり、Webサーバとしても働きます。しかし、それはWebページを配信するためのものであり、サーバ側で処理するアプリケーションサーバを意味しません。
Webアプリケーションは3層モデルを採用してきました。3層からアプリケーションサーバが除かれると2層のクライアントサーバに戻ります。しかし、アプリケーション配信が不要などWebアプリのメリットは維持しています。
なお、その他のJavaScriptでも同じく2層モデルを構成できます。しかし、JavaScript以外の言語では従来通り3層モデルとなります。
2層化にはセキュリティの問題があります。クライアントに自由にデータベースを操作することを許すので、不正アクセスも簡単です。よって、読み取り専用データを除けば、必ず認証(Authentication)・承認(Authorization)と組み合わせる必要があります。

FirebaseではOAuthのライブラリも提供しています。GoogleでログインするWebアプリも簡単に作れます。OAuthのクライアントIDおよび秘密鍵はFirebase側に登録され、リダイレクトページも用意されます。承認はFirebase側でセキュリティルールを設定することで実現します。一般的には、ログインしたユーザだけがアクセスできるように設定します。
問題となるのは、クライアントコードが不正に改変された場合です。特にOAuthを使うと、例えばGogoleのユーザなら誰でも不正アクセスすることができます。そのため、OAuthに加えて独自の絞り込みが必要になります。なお、OAuthには送信元が登録されるので、クライアントコードをコピーしてもOAuth認証を回避できるわけではありません。

実際に、AugularFireで認証付きアプリを作成しようとすると、情報が少ないことに驚きます。そこで、具体的な方法を紹介します。ただし、この方法は試行錯誤の結果なので、必ずしもベストあるいは公式に推奨される方法とは限りません。

ポイントは$firebaseと$firebaseAuthの２つを使う点です。
$firebaseAuthからFirebaseデータにアクセスできるかと思って試したのですが、どうやら認証専門のようです。二重の参照は美しくありませんが、やむをえません。$firebaseAuthが$firebaseを継承してくれればよいのですが。
Googleのメールアドレスの中で@toyo.jpを持つユーザだけに限定しています。auth.uidは意味不明の数字なので、{scope: "email"}がかかせません。該当しないユーザは$unauthしてしまえばログインを拒否したことになります。ちなみにメールアドレスはFirebaseのnameにできません。メールアドレスに含まれる特殊記号がはじかれます。

var app = angular.module("sampleApp", ["firebase"]);
app.controller("SampleCtrl", ["$scope", "$firebase", "$firebaseAuth", function($scope, $firebase, $firebaseAuth) {
  var ref = new Firebase("https://minoru-uehara.firebaseio.com/");
  var auth = $firebaseAuth(ref);
  $scope.logout = function() {
    auth.$unauth();
  };
  $scope.login = function() {
    auth.$authWithOAuthPopup('google', {scope: 'email'});
  };
  auth.$onAuth(function(authData) {
    $scope.authData = authData;
    if (authData) {
      var mail = authData.google.email;
      if (! (/@toyo.jp$/i).test(mail)) {
        auth.$unauth();
      } else {
        var denys = [
          /^[A-Za-z]{2}[0-9]{2}[A-Za-z0-9]+@toyo.jp$/i,
          /^[A-Za-z][0-9][A-Za-z0-9]+@toyo.jp$/i
        ];
        for(var i = 0; i < denys.length; i++) {
          if (denys[i].test(mail)) {
            auth.$unauth();
          }
        }
      }
      // unauthさせずに到達すればOK
      // 共有データ
      $scope.data = $firebase(ref.child('data')).$asObject();
      // プライベートデータ
      $scope.users = $firebase(ref.child('users').child(authData.uid)).$set({email: authData.google.email});
    }
  });
}]);

7-11のコーヒー

いまさら感があるかもしれないが、7-11のコーヒーが美味しい。
以前にスターバックスとマクドナルドを比べたことがある。あくまで個人の嗜好によるが、私だったら値段が高くてもスターバックスを選ぶ。
マクドナルドのコーヒーは、やはりアメリカンだとしか思えない。
私は、エスプレッソをがぶ飲みしたい人なので一般的な嗜好でないのは承知している。それを考慮しても、やや薄い、ものたりないと感じる。その当時は値段相当なので、それもよいかと思った。
しかし、7-11コーヒーが同じ値段で登場したとなると、マクドナルドのコーヒーは全く意味がなくなる。
7-11コーヒーの最大のポイントは香りだろう。香りだけならスターバックスを凌駕しているのではないかと思う。コーヒーにとって香りは大事だとは思っていたが、これほど実感させてくれたものはない。
味としては、濃すぎることもなく、薄すぎることもない。私の嗜好からは薄い方に入るが、それでも決して薄すぎない。それでいて香るのだから、うまいとしかいいようがない。
最近、スターバックに行かなくなった。理由の一つはもちろん7-11コーヒーであるが、それだけではない。スターバックスは、行っても座れないことが多い。7-11は最初から座らないので気にならないが、座らないと飲めないのに座れないのだから行っても無駄という気になる。人気なのもよいが、かなり損をしているように思う。
7-11には駐車スペースがあるので、その一部を使って晴れた日にはオープンカフェを催してもよいのではないかと思う。まあ、たまり場にならないように注意する必要があるかもしれないが。

人工知能のブレークスルー

ここ数年、人工知能関係のトピックが多く話題になった。
チェスの名人に勝ったり、クイズを解いたり、将棋も強くなった。
モンテカルロ法の登場とそれを実現するシステム技術のおかげだ。
モンテカルロ法は経験的に決め打ちされていた評価関数を動的に最適化した。
しかし、モンテカルロ法を実現するには多くの資源を必要とした。
それが解決できたために急速に賢くなった。
計算資源はプロセッサとメモリに大別できる。
プロセッサの能力は確かに高くなったが、それ以上にメモリ（特にストレージ）が大きくなった。
後者の発達によって計算結果を保持することが可能となり、乱暴な全解探索も現実味を帯びてきた。
プロセッサやメモリなどの製造技術は人工知能研究者の都合で変わるものではない。
適切な時代でなければ実現しないアイデアがある。時代によってアイデアの価値が変わることがある。

コンピュータに音読させるには

文字を音声に変える機能（ナレーション）は多くの人が望んでいる。
しかし、平板な音声は聞き取りにくく、決して十分とはいえない。
文字を音声に変えるには、文字列を形態素解析（簡単にいえば単語に分けること）し、音素に変換し、連結して再生する。この結果、いかにもロボット的な音声が再生される。
人間とロボットの違いは、感情表現の豊かさにある。
単に音素を求めただけでは感情要素が足りない。
具体的には、速さ、大きさ、高さであるが、同じ文を読み上げても心の動きで変わってくる。
この現状を改善するには、まず速さ、大きさ、高さ等をユーザが設定できる音声エディタが必要になる。機械的な音読データを人間が編集し聴きやすくする。
このままでは人手による解であり、決して十分とはいえない。
次に、作成した感情付き音声データを、単なる音声データだけでなく、その感情情報を含めて流通させる必要がある。
それらの感情データを多数集積して、文脈を機械学習させると、ある程度文脈に応じて感情移入した音声を再生できるようになるだろう。
これはビッグデータによる解決法だ。
感情付き音声編集ソフトとその再生ソフトをクラウドで提供すれば、感情データを収集することができる。利用者と提供者の利害が一致し、両者に有益なビジネスモデルとなる。
方法論的によくある誤りは、データを収集する前に、感情を付加するアルゴリズムを作成しようとする（できると思う）ことだ。それは典型的な根拠なき主張である。

DR-C125の自炊における課題

DR-C125はCanonの普及版スキャナーだ。
いうなれば最も売れ筋だと言える。
前々回の記事でDR-C125で自炊する際の注意点を述べた。
ここでは、問題点を述べる。
文庫本を上向き廃紙すると、静電気で紙が密着し、紙詰まりを起こしやすい。
下向き廃紙すると、ページ順が1/2, 3/4, ...から2/1, 4/3, ...のように裏返る。それだけならよいが、廃止済みの紙をそのままにしておくと挿入されて順序が変わることがある。後でスキャンミスがあったとき、該当ページを探すの結構な手間がかかる。
これは致命的ではないものの、かなり大きな問題点だ。実際、かなり面倒なので古いDR-2150Cに戻ってしまった。
ちなみに、A4サイズや紙質によっては問題ない。自炊用というよりビジネス用というべきだろう。
下向き廃紙を正しい順序で確実に保持してくれるアダプターを別売りすればよいと思う。面積を広げるのではなく、高さでカバーするような方向で設計すれば、あまりメリットを最大限に生かせるだろう。

自炊からKindleへ

Kindle版書籍が充実してきた。
（宅配不要で）読みたい本がすぐに読め、自炊の手間も減り、Amazonで保存もしてくれる。
とても便利だ。
昔の本がKindle版として復刻されているのもよい。
角川文庫の横溝正史が、あのおどろおどろしい表紙で復刻されているので、おもわず大人買いをしてしまった。老後の楽しみにとっておく。
しかし、まだ課題はある。
まず、すべての書籍がKindle化されているわけではない。これは時代の流れとともに解消されるだろう。紙の本はなくならないが、減っていくだろう。
Kindle書籍は基本的に共有が難しい。個人の複数端末ではクラウドで共有できるが、別人がアクセスするのは著作権的にNGだろう。しかし、一般的に家庭内共用は多くの場合認められている。電子化により厳密化されると家族内家庭内共用も難しくなる。端末自体の共用で補う必要がある。特定の端末にだけ閲覧可能なリストの作成などといった機能をクラウド側で提供する必要があるだろう。

最後に、Kindle書籍を図書館はどう扱うのだろう。端末貸し出しが現実的だろうが、あまりにコストが高い。

DR-C125

書籍の整理のために、いわゆる自炊（スキャン）をしている。
お気に入りのスキャナーはCanon DR-2510Cだった。
しかし、もはや生産終了して入手できない。
代わりとなる製品がDR-C125だ。
機能的にはDR-2510Cの上位互換ともいえるが、同じように使うには少しコツがいるようだったので、紹介しておく。
個人的に、自炊モードは24ビットフルカラー、300dpi、両面を選択している。これが様々なビューワで閲覧するのにちょうどよい。
DR-C125の標準設定はかなり画質が悪い。おそらく白黒のビジネス文書を対象としているのだろう。
そこで、手動設定を行うのだが、上記のようにスキャナを設定しても常に画質がDR-2510Cに劣る。
この原因は出力時の高圧縮モードにあった。出力時設定で標準圧縮に変更するとDR-2510Cと同等の画質となった。
確かに高圧縮モードの圧縮率は高い。しかし、不可逆圧縮のようで、画質まで低下してしまう。そのような圧縮はあまり望まれないのではないだろうか。画質低下を許容するなら、最初から低解像度でスキャンすればよいのだから。
ちょっと腑に落ちないことだったので、メモしておいた。

不完全なクラウド

ビジネスがクラウド化していく流れは必然だと思うが、クラウド（データセンター）運用技術はまだまだ成熟していないようだ。
どの部品が壊れても正常に動作する耐故障性が実現できていない。
富士通の館林センターの障害や、特にファーストサーバの障害とそれに伴うデータ損失は大きい。
一方で、運用を自律化するシステムも登場している。ますます人手では信頼できなくなるだろう。

長期保存なら新潮文庫

昔の文庫本を電子化している。
そのほとんどが茶色く変色しているが、同じ年代に購入した新潮文庫だけ新品のように白い。
カバーさえくっついてしまうくらいの劣悪な環境にも耐えた。
紙で長期保存するなら新潮文庫がよい。
古典の名作が新潮文庫に多いのもうなずける。