2010年12月27日月曜日

あると便利な自炊ツール

自炊の作業で、もしもこのようなツールがあれば便利だろうというアイデアをいくつか書いておく。
(1) 漂白ツール
昔の本は紙が黄ばんでいることが多い。黄色い紙のままでは読みにくい。これをデジタル的に漂白してくれるツールがあるとよい。
もちろんページ単位ではだめだ。全ページを一気に漂白できるくらいでないと使いにくい。
その際問題になるのは、カラーページを判別して、除外する機能だ。
また、カラーページも変色している場合には、全体の平均値や前後のページの平均値で色を補正する必要があるだろう。
(2) ページ番号チェック
ページ内に印刷されたページ番号を判別し、OCRを行い、現在の枚数と比較して、その直前のスキャン数と合致しているかどうか調べる。
文庫本のように、規則正しくページ番号が印刷されていれば問題は少ない。
しかし、マンガ本のように、ほとんどページ番号が絵柄に隠れてしまう場合には注意が必要だ。
(3) 書籍情報収集ツール
カバーのバーコード部分からISBNを求め、それを元に書籍情報を収集する。さらに、その情報を元にファイルを整理および検索する。
書籍が多数に増えてくるとほしくなる。
また、このバリエーションとして不正なコピーの検出などの応用も考えられる。その場合は、バーコードからでなくOCRと組み合わせて、その内容から検出する手法が有効だろう。
(4) OCRツール
文書内の情報を検索できるように各ページをOCRにかけて、そのテキストを各ページのテキストとする。
検索はそのテキストに対して行う。
(5) デバイス最適化ツール
iPad, iPhone, Kindleなど各デバイスに向けてPDFを最適化する。

スキャンページ数チェックのコツ

スキャンしたページが正しいかをチェックするのに手軽な方法がページ数を数えることだ。
多くの文庫は表紙を含めてページ数より2ページ多くなる。私の場合はカバーを含めるので4ページ多くなる。
白紙を無視せずスキャンすると最後のページ数でチェックできる。
スキャンするときには100ページ単位でスキャンし、その都度+4ページとなっているかどうかチェックする。
最後のページ数が印刷されたページまで数値があっていれば、まず正しく読み取れたと考えてよい。
こうすれば、後でPDFをチェックしなくても、ほぼ確実に正しくスキャンできているといえる。

2010年12月24日金曜日

小さくない電子ブックリーダ

さまざまな電子ブックリーダが発売されているが、いずれも携帯性を重視している。
これは、ある意味、当然であるが、しかし、必ずしも電子ブックリーダは小さくなければならないわけではない。
今の市場を見れば、early adopterは中年だろうが、活字の本を読まない若年層もマンガ本なら読むだろうし、もちろん老年も読む。若年層と中年層は携帯性が必然かもしれないが、老年層は自宅に入れことが多いので、必ずしも携帯する必要がない。むしろ、家庭内にある機器で電子ブックを読めた方が便利かもしれない。
今の電子ブックリーダは1ページ単位が標準である。しかし、マンガ本などは見開き2ページで1枚の絵を構成していることもある。携帯電子ブックリーダに2画面持たせるより、1枚の大画面リーダが必要とされるだろう。
さらに、家庭内で大画面の情報機器といえば大画面TVだ。こたつに入りながら大画面TVで読書するというのも悪くない。このような大型電子ブックリーダは日本の得意分野ではないだろうか?
しかし、本家のTVが斜陽なので、それどころではないかもしれない。しかし、だからこそ、このような新分野の開拓が必要だ。早くしないとSamsungが出してしまうかもしれない。

2010年12月21日火曜日

DR-2510C

自炊のスキャナをDR-2510Cに変えてみた。あいかわらずScanSnapは避けている。
DR-150に比べて格段に作業が楽になった。やはり価格の差はある。
スキャンスピードが速くなったのはもちろんだが、手間がかからなくなった。
他の人はどうしているかわからないが、私はカバーもいっしょにスキャンする。カバーをなくすのはおしいからだ。スキャンできずにカバーをあきらめたときは残念でならない。
カバーをA4スキャナでスキャンするにはA4サイズに折りたたむ必要がある。私はカバーを折ったまま見開きのようにしてスキャンする。この方法はスキャナによって適不適がある。
DR-150のときにはクリアシートに入れてスキャンした。いちいちクリアシートに入れる手間と、クリアシートの中でカバーがずれるのを調整する手間など、気を使うことが多かった。
DR-2510Cには非分離給紙モードがあり、折りたたんだカバーもそのままスキャンしてくれる。DR-150には、このモードがない。
おかげでだいぶ手間が省けるようになった。
まだ不満な点は、読み取って後に保存しなければならないことだ。ScanSnapは読み取りと同時に保存もしてくれる。スキャン終了後はPDFファイルもできている。しかし、CaptureOnTouch(DR-*のスキャンマネージャー)はスキャン後に保存しなければならないので、余分な時間がかかる。
ちなみにScanSnap S510(S1500ではない)では、クリアシートも、非分離給紙もできない(たぶん)。しかし、S1500は長尺読み取りができるようだ。カバーを伸ばしてスキャンすればよいだろう。

ステーキバーガー

ロッテリアのステーキバーガーを食べた。
ステーキはハンバーグより格上と考えられているので、明らかな高級路線だ。
実際、味は非常に良い。下手なファミレスのステーキよりうまい。
というのもファミレスのステーキはナイフで切るのもやっとだが、ステーキバーガーのステーキはナイフなしに歯で噛み切れるからだ。
パンもソースも文句がない。
しかし、唯一の問題点は食べにくさだ。
噛み切れるとはいったが、ハンバーグと比べればその差は大きい。やはり食べているうちにステーキがずれてくる。最後には、ステーキを食べつくした後にパンだけ残る。どうもバランスがよくない。
たとえば、切れ目を入れるなどして噛み切りやすくしてはどうだろう。また、サイコロステーキとラップの組み合わせの方が断然食べやすい。
味は良いが今一つの製品だったように思える。

2010年12月15日水曜日

Chrome OSと情報教育

学校のPCがシンクライアントに移行しつつある。管理を簡素化するためだ。
この延長線上には、究極のシンクライアントとしてChrome OSも想定される。
大半のアプリケーションがGoogle Apps for EducationなどのようなSaaSになれば、現実的な選択肢となるかもしれない。
しかし、そのための道のりはまだまだ遠いだろう。
今後注目していきたい。

読書

一冊の本、たとえば200ページがあるとする。この本をどれだけの時間で読むことができるだろうか?1日、1週間、1年?
たいていの人は1週間ぐらいだろう。しかし、早い人は1日で読める。読む気のない人は1年かかるかもしれない。
読書は知識の源泉だ。知能のバロメータだ。1日と1年では100倍以上の開きがある。およそ人間の活動で、これほど大きな差があるものはない。100メートルを10秒で走る人はほとんどいないが100秒でならだれでも走れる。健常者ならば。したがって、1年で一冊しか本を読まない人は一種の障害者であるといえる。
あえて厳しい言い方をしたが、逆説的に受け取ってほしい。つまり、障害者でないなら、1年に一冊しか本を読まないなどということではいけない。
読書の苦手な人は、本を表層的にしか読まないようだ。幼い子供が本を読むとき字を追うだけで精一杯な様子を見かける。そのような子も声を出すと頭に入りやすい。眼だけの読書ではなく頭全体あるいは体全体を使うからだろう。それだけ頭に吸収されやすいということだ。しかし、このような幼児レベルの読書をしている人が少なからずいる。
読書のコツは人によって異なるかもしれないので、必ずしも一般論とはならないかもしれないが、自分の読書術を紹介しよう。私の場合、読書をしていると頭の中にイメージが膨らむ。あたかも目から文字が入り、頭の中に小説の世界が生まれるようだ。その世界は、字を追うごとに進行し、時に勝手に動き出す。その動きをさらに字を追うことであらすじからはみでることを補正する。あたかもカーナビがGPSを地図で補正するようだ。
このような頭の中にモデル世界が構成されると、自然とストーリーがわかる。世界が分かればその抹消の出来事もわかる。想像しながらの読書は楽しい。同じ読書でも字を追うだけでは機械的な作業に過ぎないので楽しめない。両者の違いは大きい。この差が読書のスピードに反映される。
小説だけでなく論文も同じだ。むしろ論文の方が理路整然としていて話の流れが把握しやすい。ただし、論文の書き手はプロの作家ではないので、筋道の立て方が下手な場合もある。そのような場合はやはりわかりにくい。

2010年12月14日火曜日

スケールの変遷

クラウドはスケールアップではなく、スケールアウトが用いられる。スケールアップはサーバ1台あたりの性能を向上させること、スケールアウトはサーバの数を増やすことである。今はもっぱらスケールアウトが注目されているが、スケールアップが駄目だというわけではない。そこで、スケールアップが有効であること、また時にスケールダウン(ダウンサイジング?)も重要だということを述べておきたい。
すべての成長はどこかで限界に達する。システムの規模は飽和する。飽和するまではスケールアウトが有効だ。しかし、飽和したらスケールアウトは使えない。たとえば、地球の表面すべてをデータセンターにすることはできない。現実的でない。
そこからさらに成長するにはスケールアップするしかない。生物に似てシステムも新陳代謝を行う。壊れた部品は破棄され、劣化したサーバも新品に交換される。新しいサーバは当然古いサーバより性能がアップしている。すなわちスケールアップとなる。
スケールアップされたシステムは少ない台数でも以前と同じ性能を持つ。よって、台数を減らすことができる。全体の性能を下げることなくスケールを小さくすることができる。これはスケールアウトの逆だ。しかし、台数を減らしてもまだ成長段階である。
その成長も、やがて電力消費がボトルネックとなり、止まる。電力は共有資産であるから一企業がすべてを占有することはできない。もちろん自前の発電所は別だ。成長の余地がなくなれば、その余地を自ら作るしかない。すなわち性能を向上させるより電力消費を下げる。性能は同程度でも省エネのサーバに切り替える。そして再びスケールアウトし、スケールアップで空いた余地を埋めていく。
やがて再び新たな原因により成長が停止する。そしてその原因に対処した新たなサーバでスケールアップする。また、スケールアップで空いた余地をスケールアウトで埋めていく。この連鎖を続く限り繰り返す。
成長を最後に止める原因は「不必要となること」だろう。市場のニーズが飽和し、新たなサーバを必要としなくなった時、おのずと成長は止まる。

2010年12月8日水曜日

使えないHDDビデオ

我が家の値段の割に使えない家電の1位はHDDビデオレコーダだった。
製品は東芝VARDIA RD-X9だ。
決して人気のない商品ではないので、使い方によっては役立つのだろう。しかし、相当問題の多い商品でもある。
まず、ユーザインターフェースが貧弱だ。単純すぎるのではなく、複雑すぎるのだ。インターフェースに一貫したコンセプトが感じられないので、何かしようと思った時、どこから始めればよいのかわからない。この点はiPhoneのインターフェースと比較にならない。
そして肝心な機能に欠陥がある。R9は2TBものの容量があり、相当長時間記録できると期待していた。しかし、実際にはHDDの50%くらいしか使えない。これにはわけがある。
R9では容量だけでなくタイトル数にも制約があるのだ。約800タイトルしか記録できない。我が家では子供番組ばかり記録するので時間が短く、タイトル数が多くなる。結果、容量が余っても録画できなくなってしまう。そもそも800タイトルに限定しなければならない理由はなんだろう。単なるソフトウェア設計のミスではないだろうか?
やむを得ず800タイトルを超えないように録画を削除することにしたが、削除方法が面倒だ。まず、ゴミ箱へ移動する。しかし、PC初心者にはフォルダの概念が理解できないので、ゴミ箱に移動したままにされてしまう。当然、タイトル数は減らないので、録画ミスが起きる。ゴミ箱の内容を消去するために、同じような消去手段を繰り返す必要がある。ゴミ箱自体は消し間違いのために有効だが、ゴミ箱から必要に応じで消去してくれるとありがたい。
このようなHDDレコーダは、もう使いたくない。ARecX6のような楽なレコーダに乗り換えようかと考えている。まだ乗り換えをためらっているのは、PCなしに利用できるかどうかがはっきりしないからだ。PCなしといってもiPad/iPhoneを使うというのでは困る。ARecX6を便利に使おうとすると、iPodをリモコン代わりに常備する必要があるように思えるのだ。
世の中にましなHDDレコーダはないものだろうか?

McDonaldでSセット

マックのセットはMサイズが基本だが、Lへのアップグレードも可能だ。しかし、Sへのダウングレードも欲しい。
最近、ハンバーガーのボリュームが増えている。Mと組み合わせると多すぎて残してしまう。もったいないので、単品を組み合わせるが、どうせならセットの方がよい。

学問のすすめ(現代語訳)

このブログでも学問のすすめを推奨した。ここで現代語訳が出版されたのを受けて、もう一度推奨しておきたい。
学問のすすめは今日に通じる名調子だ。源氏物語のような文学作本でない、いうなれば実用本が時代を超えて通用することは極めて稀だ。今日出版されているビジネス本の大半は10年後に忘れ去られているだろう。1000年保つかどうかは定かでないが、少なく
とも100年保った意味は大きい。
学問のすすめを現代語訳で復活させる仕事は本来慶應義塾塾生の仕事だろう。その意味で遅れをとったことは否めない。
義塾唯一の先生に遠慮したのだとすれば、肝心の学問の精神が緩んでいると言える。あるいはわざわざ現代語に訳す必要がないと考えたのかもしれない。そうだとすれば、世間から乖離している。
実際は塾生でも原著を読んだ人は多くないと思う。私自身、青空文庫の無料版がなければ、わざわざ読もうとは思わなかった。啓蒙書は役立つが、それほど面白い訳ではない。お金を払って読む価値があるかどうかは人それぞれだろう。
現代語訳が出ても、それで啓蒙が終わる訳ではない。お金の壁を超えなければならない。つまり一層の啓蒙を目指すなら無料の電子版を出すべきだ。その時には義塾が前面に立って貢献して欲しいものだ。

2010年12月6日月曜日

競争を学ぶ

おおよそ人生において競争は不可欠である。生きがいであるとも言える。
そして、真の競争は自分自身との競争である。明日の自分が昨日の自分に勝つために、今日、競争するのだ。
しかし、競争を悪、あるいは必要悪と見なす風潮がある。弱者救済の名目で競争を否定し、共存を主張する。
そもそも競争と共存は二律背反ではなく、それこそ共存しなければならない概念だ。競争なき共存は悪平等を生む。結果として進歩が止まる。共存なき競争は弱肉強食であり著しい不公平を生む。これもまた自滅へ至る。誰も自分の体を食べて生きてはいけない。
共存は競争の足かせとなるべきで、常に共存を目指す必要はない。
競争する上で、自分と他人とどちらと競争するのが容易かといえば他人だ。自分との競争はモチベーションの維持が難しい。自分との競争を学ぶには、他人と競争してみることだ。他人と競争できないものは自分とも競争できない。よって、自分と競争する術を学ぶために他人との競争を経験した方がよい。

2010年11月28日日曜日

クイズ「る」

有居売得折
刈切来蹴凝
去知刷競剃
足散釣照取
成煮塗寝乗
貼干降経掘
放見蒸減盛
遣□揺□寄
□□□□□

2010年11月23日火曜日

オンラインストレージあれこれ

最近では大半の文書はオンラインストレージに保管するようにしている。このオンラインストレージという言葉は、かならずしも十分な意味を伝えない。まず、オンラインでしか使えない印象を与える。確かにそのようなものもある。しかし、オフラインで使えるものもある。ここではクラウド上にデータを保存できるサービスの総称としてオンラインストレージという言葉を使う。もう少しクラウドが身近になればクラウドストレージとか、単にクラウドでも通じるようになるだろう。
一番よく使っているのはDropBoxだ。これは正確にはフォルダ同期のシステムだ。ローカルには格納場所が必要なので、新たに要領を追加する目的では使えない。無料版は2GBだ。なぜ、このような少ない容量のサービスを使っているかというと便利かつ十分だからだ。便利というのは、すでに長く使っていてなじんでいるからという意味もあるが、さまざまな機種で使えるということも大きい。Windows, Macはもちろん、LinuxやiPhone, iPadでも使える。特に、iPhoneとWindowsの間でデータの送受信ができるところがあり難い。つまり、ストレージの中でもフロントエンドに該当するサービスとして重宝なのだ。2GBという容量は確かに小さく不満がないわけではない。しかし、ワーキングセットとしてならば2GBで十分だ。仕事に応じて2GBを切り替えればよい。
最近使い始めたのがSugarSyncだ。こちらはDropBoxに様々な機能と容量が追加されている。まず任意のフォルダを同期することができる。DropBoxはMy DropBoxしか同期してくれない。しかし、個人的にはフォルダは1つにまとめたいので、この機能は使っていない。もしかしたら、今後は役に立つかもしれない。容量は5GBだ。この容量もローカルに必要だ。2GBと5GBの差は大きい。なぜなら5GBだとDVDのイメージなども含めることができるからだ。容量の大きなファイルをゆっくりだが、空いた時間でコピーしてくれるのは効率がよい。
SugarSyncと類似のシステムにソラ箱がある。これを容量が5GBだ。3つ合わせると12GBになる。私のPCのSSDは64GBしかないので、ワーキングセットとしては十分すぎる。ただし、今のところソラ箱は使っていない。なぜかWindowsクライアントが動かないからだ。Javaをインストールしており、PATHも通しているのに、JavaのDLLがないと警告される。Eclipseをはじめ、その他のJavaプログラムは何の問題もなく動作しているのにだ。また、Windowsクライアントが常駐型でないので、いつの間にか同期するという使い方はできなそうだ。よって、ソラ箱はUSBメモリか、あるいはSDカードに入れておいた方がよいかもしれない。ちなみに私は常に16GBのSDメモリを指しっぱなしにしている。これがメインのワーキングセットだ。
最後にSkyDriveだ。これはローカルに保存しない純粋なオンラインだけのストレージだ。SDExplorerで普通のフォルダのように使っている。しかし、ファイルサイズが50MBしか対応していないので、どのようなファイルでも保存できるわけではない。かなり厳しい制約なのでバックアップ的な役割になっている。やはり少しでも制約があると、便利に使うというわけにはいかない。

スキャンミスのチェック

だいぶ自炊になれてしまった。
しかし、そうなると、作業時間の中で手間取るポイントが前とはかなり違ってくる。
前は裁断に手間取っていたが、これは道具を使うことで非常に簡単になった。実際、裁断時間よりスキャン時間の方がはるかに長くかかる。
しかし、単純な裁断だけでは不十分だ。実際には裁断した後、きちんと各ページが分離しているかどうかチェックする必要がある。これを怠ると読み取りエラーが起きるだけでなく、紙を破いてしまうこともある。そうなるととりかえしがつかない。
この裁断の確認が手間だ。
もう1つはスキャンミスのチェックだ。紙送り式では一度に二枚以上の紙を送ることがある。この機械的なエラーは決してなくならない。どれだけエラーが少ないかは機種に依存し、カタログスペックには現れない。個人的な経験ではScanSnapの方が、DR-150よりエラーが少ない。しかし、ScanSnapでもエラーが起きないわけではない。
そこで、ページ数でチェックを行う。目次とイメージ数との差が最初から最後まで一貫していれば一応全ページスキャンできたものと判断する。しかし、この方法とて完ぺきではない。ページ番号のない個所をチェックできていないからだ。目次前と解説の後だ。とくに後者には参考文献などの重要な情報も含まれるので、見逃さないようにしなければならない。また、コミックのたぐいはほとんどページ番号がつけられていない。あるいはページ番号を隠すように絵が描かれている。よって、ページ数のチェックは難しい。

これからのメール管理

すでに個人ではGmailを使っている人は多い。
会社の中にはGoogle Appsを使っている会社も増えている。
うちの学校ではGoogle Apps Educationを使っているが、これは個人版より機能が限定されていて使いにくい。
もしもGoogle AppsがEducation版程度の機能なら使う必要はない。むしろかえって使いにくくなる。
実際にはEducation版より高機能ではあるのだが、しかし無料版より多くの機能があるとは思えない。広告などが消え、管理が統制できるくらいだ。
それならば、メンバーに個人版としてアカウントを作成してもらい、そのアドレスを登録した方がよい。一切のメール機能を無料版に委託してしまう。このような方法もこれからの時代には検討していく必要がある。

2010年11月10日水曜日

白紙ページの挿入

ScanSnapなど高度なスキャナでは、白紙ページを認識して自動的に削除してくれる機能がある。
これは不要なページを削除してデータを圧縮する効果があり、重宝する。
しかし、これを使うとページ数が一定でなくなり、スキャンのページ抜けを簡単には検証できなくなる。
そこで、圧縮機能はそのままでページ数を一定にするために、直前のページと同一サイズの白紙ページを挿入してほしいと思う。
生成された博士ページは非常にコンパクトなので、ほとんど容量は増えない。しかし、それがあることの意味は大きい。

スキャン本の検索

電子書籍の流通が一般的になるまでは、しばらく自炊生活が続くだろう。
このようなときスキャン本の検索機能がほしくなる。
CDをリッピングしても、そのデータから曲名が検索できる。
これは元がデジタルデータなのでさほど困難ではない。音楽の場合、データでも文字がないため、それを補う必要があるため、このようなサービスが発展している。
電子書籍なら最初から検索出来て当たり前だ。
しかし、デジタルでもスキャンした本には文字情報がなく、検索のためには精度の低いOCRをしなければならない。この手間は大きい。
しかし、ソーシャルとして考えれば、誰かがすでにOCRしている可能性がある。それを検索するために、表示のイメージ同士でマッチングを行うことが考えられる。
これにはイメージ検索が使える。
このようなデータの共有には2つの意味がある。1つは無駄な手間と重複する情報量の削減だ。もう1つはコンテンツ保護だ。正当な所有者であることをイメージで示すわけだ。もちろん、これは抜本的な方法ではない。抜本的な保護のためには最初から電子化してなければならない。

クリアポケット

いわゆる自炊で役立つのがクリアポケットだ。
ポケットタイプのクリアファイルのことだ。
なるべく透明度の高いものがよい。
何に使うかといえば、カバーなどを折りたたんでスキャンするのに役立つ。
本、特に文庫はカバーがなければそっけない表紙しかない。
だから、ぜひともカバーも保存しておきたいのだが、カバーを伸ばしてスキャンすると用紙サイズの上限を超えてしまう。
素朴な疑問だが、シートフィーダ方式のスキャナになぜ縦幅の上限があるのか理解に苦しむ。任意サイズを許しても構わないと思うのだが、実際にはA4くらいで打ち切られる。読み取ったところまででもデータが残ればよいが、たいていはエラーとして全体が破棄される。つまり不定形の長すぎるカバーはスキャンできないのだ。
このようなとき折りたたんでA4以下のサイズにすればスキャンできる。しかし、ローラーが折りたたんだ個所を無理に伸ばしたりしてうまくスキャンできないことが非常に多い。
そこで、クリアポケットの出番となる。折りたたんだままクリアポケットに入れておけばうまく読み取ってくれる。
しかし、これが通用するスキャナとそうでないスキャナがある。
DR-150ではうまくいく。しかし、ScanSnapではうまくいかない。紙送り機構の差でポケットを送れないのだ。
ScanSnapの紙送りは、違っているかもしれないが、上下逆方向の摩擦を与えるようで、ポケットが上下で逆方向へ動こうとする。これは確実に1枚ずつ紙送りするにはよいしくみだ。実際、ScanSnapではDR-150より確実に紙送りのエラーが少ない。しかし、その結果、ポケットを紙送りすることができない。
ちなみに、クリアポケットは10枚入りが100円ショップで売られている。

2010年10月11日月曜日

原作の直接輸出

日本のアニメが世界に普及していくという構図が一般的かといえば、かならずしもそうではなさそうだ。むしろ、アメリカンコミックスの方が世界戦略に乗りやすい側面もある。日本のアニメは大人にも通用する半面、大人受けする子供向きでない内容を含んでいることが多いからだ。宮崎アニメもそうだ。
これを改める必要があるかどうかは議論の余地がある。大人にも通用するアニメが日本の特徴かもしれない。しかし、アメリカンコミックはその制限の中でうまく大人も取り込んでいるので、方法がないわけではないということだろう。まだ、日本のアニメは世界戦略への内容的なてがかりをつかめていないということだろう。
このような書き出しで始めたのは、アニメの原作自体を国際化することがそのきっかけになるのではないかと考えたからだ。アニメが国際化されるには、日本での成功を受けて、行われることが多い。しかし、そのときにはすでに内容的な変更が本質的なあらすじにまでおよぶくらいリメイクしなければならないほどに及ぶ可能性がある。よい原作をアニメ化の前に国際化することで、アニメ自身が最初から国際化できるかもしれない。
また、よい原作がアニメという間接的な手段でしか世界に評価されないのも残念だ。もっと作家が評価されてよい。iPadなど電子書籍が世界で広まる中で小説の方が容易に国際化できることに気づくべきだ。
原作を国際化するには英語化する必要がある。原作者自身が英語化するのは無理だろう。だから、原作者の作風を理解する翻訳が必要だ。日本の翻訳者は英語の作品を日本語に翻訳することが多く、逆は少ない。それでは、このような仕事に十分とはいえない。新しい時代の翻訳者が必要とされているのだと思う。
しかし、アニメやその原作の人材を生み出している専門学校は、あまり英語教育に力を入れているように見えない。また、専門学校生の中にも英語の勉強が嫌で大学を選ばなかった人もいる。よって、相性はかなり悪い。しかし、このような人材がいま必要とされていることは確かである。とすれば、大学からそのような人材が出てくるのを期待したい。しかし、大卒にとっては翻訳者レベルの技能があれば、あまり職に困ることはないだろう。そのような人材があえてアニメ原作に取り組むかどうかは、この市場の先駆者となる意思があるかどうかにかかってくる。信念が必要だ。

2010年10月5日火曜日

著作権と環境

この二つは一見別物に見える。しかし、論理の下で結びつくことがある。
我々は、ほぼ毎日のようにビデオ録画をしている。多くの録画装置が販売され、多くの家庭でほぼ24時間稼働している。特に最近のビデオレコーダーはHDDが搭載されているので、24時間動かすのが当たり前になっている。
このような状況を環境問題の側面から眺めるとゆゆしき事態だ。家庭での電力消費をなるべく減らしていかなければチャレンジ25は達成できない。チャレンジ25の方を反故にするという選択肢もあるが、その分日本以外の誰かが努力しなければならない。そのような無責任は恥ずべきだろう。
そのような背景で、先のビデオレコーダーについて考えると簡単な解決策がある。誰かが1回録画し、それをネットで共有することだ。しかも、1度ダウンロードすればキャッシュできるようにすればなおよい。このような解決策は誰でも思いつくが、決して実現されない。それは法律が許さないからだ。特に著作権が問題となる。
しかし、著作者の権利を守る著作権だが、著作者の権利と地球(すなわち人類全体の命)と比較すればどちらが優先されるべきかは明らかだ。環境問題の解決のために著作権が制限されることも考慮に値する。
もちろん著作権を厳守しながら地球が救われるならそれに越したことはない。しかし、ますますストリーミングメディアや放送が普及していく中で、それによって消費されるエネルギーも無視できない。
政策は、どのような社会にしたいかという方向性を示すものでもある。政策として著作権をとるか環境をとるか選ばなければならない時代が来るかもしれない。

2010年10月3日日曜日

最小不幸社会の合理性

菅直人首相が提唱する最小不幸社会論は何かと批判が多いものの全くの暴論という訳ではない。
最大多数の最大幸福という理念はよく知られているが、最小不幸はこれとは異なる。本来の中流の意味とは異なるが、日本の中流はあくまで上流と下流の中間的な立場である。最大多数は常に中流層であり、その幸福を目指すと、中流と上流の差が小さくなる。しかし、下流は取り残される。しかし、最小不幸論は不幸が最大化している下流に焦点を当てて、その解消をする。よって下流と中流の差が小さくなる。
これには様々な異論が考えられる。努力が報われる社会であるかどうかも一つの論点だ。下流の引き上げは安易なばらまきとなりやすい。その結果、下流が努力を怠り、中流の努力が報われない。
しかし、これはやり方の問題だ。上流の富が下流に分配されるだけなら問題ない。しかし、上流だけを資金源とすると救済できる人数も限られる。まさに最小限の最大不幸の最小化だ。この範囲の政策であれば有効であると言える。しかし、規模は小さいので、日本全体への発展には繋がらない。あくまでも傷口をふさぐ応急処置と言える。
そもそもこの程度のことは一般的な福祉政策の範疇である。それが合理的でないはずがない。
しかし、購買層としての中流が形成されなければ経済政策として成り立たない。福祉政策だけで下流から中流に引き上げることはできない。

2010年9月23日木曜日

デフレスパイラルからの脱出

東洋経済の記事にデフレスパイラルの構造が非常に簡単かつわかりやすく示されていた。あくまでも簡略図なので、これだけですべて理解したつもりになるのは間違いだろうが、本質的な事柄に集中するには有用だ。
同記事によると、
(1) 企業収益が悪化する、と
(2) 賃金が下落する、と
(3) 購買力が低下する、と
(4) 物価が下落する、と
再び(1)へ戻る。
この連鎖の中で(1)以外は強い因果関係がある。
収益が悪化している中で賃金を上昇させる企業はありえない。そのような企業は競争力を失う。もちろんそのような戦略が全くありえないわけではない。人材の能力に強く依存する分野では人材の労働意欲が企業の競争力に直結する。そのような分野では労働配分を大きくしても、かえって企業収益が高まることもある。しかし、そのような分野は限られるし、その分野でもそのような戦略をとりえる企業は例外だろう。たとえば、投資ファンドなどの金融業などが該当するだろう。
賃金が上昇しない中で支出を増やす人はいない。長期的な視野からライフプランで必要と思われる特殊な支出はありえる。しかし、これは支出を増やしたというより、たまたまそのタイミングで支出したにすぎない。よって、支出が増えたわけではない。たとえば、車の買い替えやマイホームの購入などだ。これらはむしろ不況の影響で実際には減る。もしも賃金が変わらないのに支出だけ増やす人がいれば無謀としかいいようがない。そのような人が多ければ日本は破滅するだろう。例外は退職者だ。退職者は基本的に収入より支出が大きい。しかし、現在の福祉の中では退職者さえ支出より収入が大きいかもしれない。少なくとも高齢者の方が若年者より経済的な余裕があることは確かだろう。それでも購買力は低下する。
買う気のない人々に売るためには価格を下げるか、ほしいと思わせる商品を作るしかない。後者の道を進むことができればよいが、難しい。多くは前者の道を進まざるを得ない。結果として物価は下落し、デフレとなる。
物価が下がれば商品の単価も下がり企業の収益は増えない。しかし、これは改善の余地がある。企業の収益は商品の単価でなく利益率に依存するからだ。1000円の商品から300円の利益を得るより、900円の商品から400円の利益を得る方がよい。円高で原材料の輸入が安くできるなら利益率を高めることもできる。また、国内はデフレでも海外はインフレなので輸出を増やせばよい。即効性のある栄養剤としては企業減税もある。これらの対策は口で言うほど容易でないことは理解しているが、全くの不可能、無策でもない。つまり、デフレスパイラルから脱出するは(1)を変えるしかない。
企業収益が改善されてもすぐには賃金に反映されないだろう。賃金に反映されるには人手不足の状況が生まれなければならない。しかし、有能な人材は国内に求めずとも海外で得られる。若者、特にゆとり世代の労働意欲の低迷は深刻だ。優秀な人材を育てるどころか、無能な人材を育ててしまった。正確には無能というより無欲だ。しかし、能力が発現しないことに関して両者は等しい。企業が国内で人材を得るとすればゆとり世代をスキップした次の世代だ。これは日本の福祉政策にも大きな禍根を残す。多すぎる年金者に加えて多くのニートをかかえることになるからだ。しかし、デフレスパイラルを食い止めるには改善された企業収益を広く分配する仕組みが必要だ。ある程度の時間差をおいて企業税を増やす必要があるだろう。
(2)の歯車まで回り始めたら、残りの歯車も回りだす。デフレスパイラルは自然と解消される。

EU進出はドイツから

ユーロは安くなったが、それでも市場としてのユーロ圏は魅力的だ。
現在のところEUではドイツの一人勝ちだそうだ。ユーロ圏ではドイツが経済の牽引車となっている。
ビジネスチャンスは牽引車の場所に多い。したがって、EUにこれから本格的に進出しようという企業はドイツに最初の支店を持つべきだろう。私的な印象からもフランスよりドイツの方が自由であり、ビジネスチャンスが多いように思える。
ドイツの一人勝ちが確定するとEUは困ったことになる。通貨が統一されているため為替レートで輸出入を制御することができない。ドイツ製品の流入を止めることはできない。しかがって、ドイツに工場があればEU全体に輸出することができる。
証券取引所もフランスよりドイツの方が大きい。資金の調達も容易だということだ。

鉄板焼きステーキ

出張で肉の有名地に連泊した。最初は飛騨牛の飛騨、次は神戸牛の神戸だ。飛騨牛の料理はほとんど和風だったが、神戸牛は洋風が似合う。今回は三宮駅近くのステーキランドという店で神戸牛のステーキを食べた。そこで、思ったことがある。鉄板約ステーキは利益率のよいビジネスだなと。
普通、飲み屋の客単価は3000円くらいだろう。ステーキハウスも同程度だろう。しかし、ステーキハウスは客の回転が速い。飲み屋では、2時間は居続ける。しかし、ステーキハウスではいいところ30分くらいだろう。長くても1時間は超えないはずだ。特に、ステーキハウスでもカウンターに座る鉄板焼きの形態では長く居座る客はほとんどいない。利益率が同程度であれば、回転率の差で2~4倍の収益が期待できる。
また、居酒屋に比べてメニューが少なく仕入れのコストもかからない。もちろん肉自体は高いが、利益率が変わらなければ種類が少ない分、楽だと言える。さらに全席カウンターなら店は狭くてもよく初期投資も小さい。ただし、満席で入れないことがあると機会損失は大きい。客の回転とマッチすれば理想的な店舗形態といえる。
このような優れたビジネスモデルは真似をしない手はない。特に同じブランド牛を売り物とする産地では有効だ。飛騨牛のステーキハウスがもっと増えると地域の活性化につながるだろう。高山駅前にステーキハウスがほしいところだ。

日本の水を輸出するには

日本は資源の乏しい国だ。しかし、それでも輸出に頼らざるを得ない。
水は日本が輸出できる可能性がある数少ない資源だ。いわゆる水ビジネスとは異なり、直接ミネラルウォーターを輸出する。
日本の周辺を見渡しても、安全な水が豊富にある国は少ない。工業用水すらない国もある。日本は自然の蒸留装置あるいはミネラルウォーター製造機ともいえる。
しかし、日本水はいわゆる軟水で物足りない。世界で競争するには、硬水やガス入りも必要だ。工業的に作るのでは割に合わない。なるべく自然なままを活かすべきだ。
もう一つ足りないのはブランド戦略だろう。日本人だけが分かる名前ではなく世界に通用する名前が必要だ。

2010年9月16日木曜日

これからの「道徳」の話

TV放送「白熱教室」で有名なマイケル・サンデル教授の著書「これからの『正義』の話をしよう」が出版され、教授の考えや主張がよりわかりやすく伝わるようになった。これとTVでの実現を見れば、おもしろい授業の在り方が見えてくる。
今まで、おもしろい授業というとおもしろいTVと同様に笑わせることだと考えている人も誤解に気がつくだろう。たぶん、多数派ではないと思うが、中には真剣に漫才師こそ最高の教育者だと信じている子供もいる。本当の面白さは自分で考えることの先にあるのだと気付いてほしい。
教授の授業法をすべての授業に応用することは容易ではない。さらに工夫すれば応用範囲は広がるかもしれないので研究する価値はある。しかし、どこまでも一般化すればよいというものではないし、それ以外の方法も検討に値するので、安易に適用すべきでもない。
しかし、いわゆる道徳の授業には素直に適用できるだろう。おそらく今まで道徳の授業は決して面白いものとはいえなかっただろう。しかし、おもしろい道徳の授業があるのだということが具体的に示された。しかも、多くの人が知った。今度は、教育現場がこの流れにどれだけ追随できるかだ。有効な方法ならオリジナルでなくてもよいので、どんどん真似すべきだ。しかし、やり方だけ真似してもだめだ。自分自身がその道徳問題について一度は真剣に考えたことがなければ多様な考えの本質的な差を適切に指摘することはできない。そのためには道徳専門の先生が必要かもしれない。あるいは存在してよい。近い将来、多数の和製サンデル先生が現れることを期待したい。

2010年9月10日金曜日

Unplugged Programming

Unplugged Computer Scienceという本がある。計算機科学をPCを使わず学ぶというものだ。PCの使用が不適切な子供にも計算機科学を教える教材だ。
そこまで低学年とはいかないが、PCなしにプログラミングの原理を学ぶ教材を考えてみた。
https://docs.google.com/fileview?id=0B-jRsgPew5h_NTM4NTQ0ODUtODNlNi00Y2U0LWI4ZTgtYThiMDM2Y2JiM2Zj&hl=ja

時間割から見た単位

最近では単位制の高校もあるようだが、基本的には小学校からずっと時間制だろう。
時間制では一定の時間を授業に参加すればよいことになっている。
成績は理解度を表すもので、理解できなくても、つまり成績が悪くても困りはしない。
このため質が不均一となり、習熟度別コースなどに分ける工夫が必要になる。
大学が単位制をとる理由は、それがおのずと習熟度別になるからでもある。うまく習熟度別に分類されるかどうかは定かでないが、少なくとも理解したというしるしにはなる。
単位制のために大学の時間割は虫食いだらけで、時間の利用効率が極めて悪い。
そこで、発想を逆転させ、時間割に合わせて単位を考えてみよう。
大学は124単位で卒業できる。年で平均すれば34単位だが、4年生は特殊な年だ。ここでは就職活動もあるし、124単位以上を目指してほしい。
そこで、3年間で120単位を目指すことにする。平均40単位/年だ。
1科目通年4単位とすれば、たかだか10科目にしかならない。
時間割が月曜から金曜まで各5時限ずつだとすると、週2日通学するだけでよい。本来は残りの時間を自習に充てるべきだが、そのようにしている人はほとんどいない。非現実的な仮定をしてもしかたない。
そこで、本来の自習にも単位を与えると同時に授業自身の単位を減らし、薄く広げる。
1科目通年2単位とし、週2回にすれば、週4日通学することになる。それでも1日余るのでクラブ活動をするには全く支障はないはずだ。
このように現在の大学の一般的な方式は単位を安く見積もりすぎている。そろそろ実際に合わせて1/2にする必要があるだろう。

英語6年、数学3年、プログラミングはわずか1年

であきらめてしまう。
学生は中学高校と6年間通じて英語を学ぶが、それでも英語は習得できない。
それにはいろいろな理由が挙げられているが、理由はともかくその認識は広く普及している。
英語で話す内容がないのであって、話せないわけではないという反論もあるが、実際話せない人は非常に多い。
むしろ話せる人の方が例外といえる。これは実態であり、現実だ。
英語が6年かけて出来ないことを、なぜ半年か1年のプログラミング言語ならすらすら書けるようになると思うのだろう。
もちろん授業を受けている学生にはプログラムを書くという夢があり、そのために授業を受ける。
しかも大学も書けるようにするために授業をする。しかし、実際にはなかなか上達しない。
プログラミング言語も英語と同じだ。上達するには訓練が必要だ。
しかし、今のプログラミング教育では文法を教えるだけに終始してしまう。
正確には基礎教育としてのプログラミングは文法の習得にとどまる。
本来、そこから次のステップとして専門教育としてのプログラミングが始まる。
しかし、その過程が抜け落ちている。いきなり座学になったり、他の専門科目の片手間になる。
応用問題は分野や科目ごとに異なるので片手間であっても、それぞれに任せる必要があるだろう。
しかし、一般的な手法まで抜け落ちているのが実情だ。
話が脱線したが、問題は期待と実際のギャップが大きいことだ。
英語だって最初は勉強すれば話せるようになると信じていただろう。
しかし、やってみるとかなり難しいことが分かり、6年続けてあきらめの境地に達したのだろう。
もっとも中学はともかく、少なくとも高校で行われているのは受験英語であり、話すための実用英語ではない。
これはある意味で免罪符となっている。それでは大学で実用英語に切り替わりすぐに話せるようになるかといえば、それはない。
実際、できる人はますますできるようになり、できない人はさらに忌避するようになる。
6年間の間に適性がはっきりしてきてしまったのだ。あるいはやる気がうせてしまったかだが、やる気が維持できることも適性の反中だろう。
6年かけて判断した適性を、プログラミング言語に関してはわずか半年で判断して、見切りをつけてしまうのはどうしたことだろう。
中学に入学して初めて英語を習った時、半年で何ができたか考えてみるとよい。
ここまでプログラミングと英語を比較してきたが、どちらかといえば数学のほうが近い。
数学に関しては中学の3年で見切りをつけ、高校では文系と理系に分かれる。しかし、これもあきらめがよすぎる。それを社会も助長させている傾向がある。あまり感心できない。
実際には、文系の経済学部で下手な工学部より高度な数学が使われることもある。数学の試験のない経済学部などありえないだろう。
文法主義の英語では、教わった文法に合わせて意味の通る文を構成する。このような方法ではリアルタイムに話すのは難しい。
このような構成法は英語よりむしろ数学でこそ使われる。
数式で問題の意味を表現する。この方法が実はプログラミングそのものといえるほど近い。特に関数型プログラミングではほとんど同じといってよい。そこにアルゴリズムを少し加えればプログラムになる。
表現された数式から答えを導くために中学・高校の6年間が費やされている。
特に受験数学では正確な導出が要求される。
この過程はプログラミングではアルゴリズムに該当する。問題の解き方がわからないとき、6年かけて解き方を習ってきた。
大学入学時にはある程度の解き方の技術が身に付いているはずだ。しかし、問題の解き方とプログラミングのアルゴリズムはなかなか一致しないようだ。
もちろん人間の思考法と機会に与える手順の差はある。
それでも簡単な問題に対しては自分で解き方を導く訓練は受けてきたはずだ。それが応用できていない。
つまり本質は応用できないことだ。
これは受験数学に明け暮れ、文章問題をおろそかにしてきた付けだろう。新学力基準で日本が国際的な水準から遅れてきているのはそのためだ。
これがプログラミングにも影響している。
つまり、プログラミングは実際に答を導出する過程ではなく、問題を表現する過程であるからだ。これは文章問題に他ならない。
そして実社会の問題はほとんど文章問題だ。
この根深い欠陥を1年で矯正できるはずがない。したがって、1年であきらめるのは早すぎる。
総合的なレベルアップが必要だ。

2010年8月16日月曜日

Perth

Perthはオーストラリアの西にある都市だ。西部ではおそらく最大の都市だろう。しかし、それでものんびりとしたところだ。
西部の人は東部の人が忙しすぎるという。西部のゆるやかな時の流れの方が人間的な生活にふさわしいと考えている。
Perthから少し離れたところにワイナリーや動物園がある。動物園ではコアラに触れることもできる。日本では考えられないほど距離が近い。
ときどきカンガルーの肉を試食できる機会がある。よほどうまく調理していない限り、それほどうまいとは思えない。何かの代用品には成りえるが、それ自体がメインの料理にはならないと思う。もちろん、それをメインにしているレストランがないわけではない。それらの店はプロだから調理がうまいのであり、家庭でカンガルーの肉を料理しようとするのは賢明ではないと思う。

ミラノ

大分前のことだがミラノに行ったことがある。
旅の途中によっただけだが、急いで観光しようと思えば、一日でもそれなりに見てまわることが出来る。多くのヨーローッパの街がそうだが、大聖堂や広場を中心に見てまわればよい。
ミラノの大聖堂の近くではつまらない紐を売りつけられそうになった。サッカーファンなら意味があるのかもしれないが、私にはただの紐にしか見えなかった。売りつける相手を間違えている。
また、大聖堂近くにショッピングアーケードがあり、そこで昼食としてパスタを食べたが、非常に高かった。うまいことはうまい。しかし、値段の価値があるかといえば、おそらくない。
文句ばかり書いたようだが、街自体は魅力的だ。観光する価値は十分にある。

Plustek OpticBookによる電子ブックの作り方(3)

OpticBookを使っていろいろな本をスキャンしてみた。
その結果、いろいろな問題点がみえてきたので報告する。
まず、500ページの本をスキャンしたところ、ImageFolioがメモリ不足で終了してしまった。ImageFolioはスキャンしたイメージを表示する際、メモリに読み込んだままにするようだ。これはある意味当然だ。そこで、連続スキャンする場合は、PCのメモリに応じて一旦終了し、複数回に分けてスキャンする必要がある。
また、500ページをconvertで変換しようとしたら、これもメモリ不足で動作しなかった。これは致命的なので、convertでは多くのページの本を作成できないことがわかった。逆に、PageManagerを使うとスムーズに変換できる。さすがに500ページをPageManagerで扱うとかなり重くなる。しかし、辛抱強く待てば、動作はしているので最終的な結果は得られる。
convertはPDF変換だけでなく、ページの回転も行うことができるが、DocActionで偶数ページのみ回転するように指定するだけでconvertを使う必要はなくなる。やはり、添付CDのツールだけで完結して操作を行うことができるようだ。
偶数ページ回転の場合の所要時間を測定してみた。393ページの書籍を偶数ページのみ回転させながらスキャンしたところ、99分かかった。前回は158ページに28分かかった(11s/page)が、今回は393ページで99分だった(15s/page)。よって、回転によって1ページあたり4秒ほど余計にかかるようだ。しかし、この差は純粋に回転処理のオーバーヘッドではない。ページ数が増えるとImageFolioを再起動する手間や、重い本をめくる手間など確実に様々なオーバーヘッドが増える。その総合的な影響である。特に、スキャンを中断したとき、偶数ページで中断しておかないと、次のページから反対にスキャンしてしまうことになる。このような場合、もう一度スキャンをやり直さなければならないし、余分なイメージを削除することも行う必要がある。
また、393ページでもPageManagerの処理はかなり重くなる。今回は、そのオーバーヘッドは測定しなかったが、確実に数分は余計にかかる。

2010年8月7日土曜日

誰がAndroid版iPadを作るか?

Androidは徐々に浸透しているようだ。iPhoneの閉塞性を追い風にして、徐々にかつ着実に勢力を伸ばしつつある。今回のアンテナ問題はiPhoneにとってマイナス要因だが、一時的なものに過ぎないだろう。アンテナのせいでAndroidが選択されているわけではないということだ。やはりAndroidは安く、しかも便利だということだ。
iPhoneに対してAndroidが対抗馬になるならば、iPadに対しても対抗できるだろう。実際、iPadにはiPhoneほどの優位性はない。よって、どの会社もAndroid版iPadの市場を支配しようと狙っている。最初の製品はASUS Eee Padだろうか。
この分野に日本メーカーが参入できるかで、世界市場における日本の存在感が試されるだろう。
SharpはUbuntuに傾倒しているが、Androidへの対応は進んでいるのだろうか?また、iPadサイズのマシンを開発できるのだろうか?
SonyはAndroidの十分なノウハウを持っているし、ネットワークウォークマンのノウハウもある。それをiPadサイズで実現できるかが問題だ。
しかし、これ以外のメーカーが開発できるのか疑問だ。国内のPCメーカーとして知られるNECや富士通、Panasonicなどはいずれも実現できないだろう。試作機は作れても製品化はできないだろう。日本の存在感は相変わらず小さいままかもしれない。

Plustek OpticBookによる電子ブックの作り方(2)

OpticBookにはScanSnapに比べてメリットがある。そこで、OpticBookでより効率的な作業の方法を考えた。
スキャン作業は、これ以上効率を上げることは難しい。スキャンを効率化するには、もっと特別なスキャナが必要だ。そこで、それ以降の処理に要する時間を短縮する。
ページの回転とPDFの作成はいずれもImageMagickを使って容易に自動化できる。具体的な手順を説明する。
まず、スキャン処理においてDocActionの設定を変更する。自動切り抜き、自動傾き補正はもちろんだが、保存設定で保存フォルダを指定し、スキャンと同時に保存するようにする。また、日付でなく連番にする。連番だとページ番号に対応するので、どのページを回転させればよいかがわかりやすい。このように設定した後、全頁をスキャンすると、ImageFolioでは何もせずに終了してよい。
ページを回転するには、大まかに偶数ページと奇数ページのどちらを回転させるべきか決める。各ページを回転させるには、ImageMagickのconvertコマンドを使う。
convert -rotate 180 image%05d.jpg image%05d.jpg
ここで、%05dの部分に回転すべきページ番号をあてはめる。簡単なプログラムを書いて、バッチファイルを生成すればよい。例えば、奇数ページのみ回転する場合には以下のようなバッチになる。
convert -rotate 180 image00001.jpg image00001.jpg
convert -rotate 180 image00003.jpg image00003.jpg
:
ここで、作業を楽にするために必ず回転すべきページが奇数か偶数かのどちらかになるようにあらかじめ調整しておくとよい。つまり、たとえ空白ページでもスキャンしておくか、きれいな空白ページを生成して挿入するかいずれかだ。小さな空白イメージを用意しておき、それをconvertで任意のサイズに変更すればよい。
convert -resize 1000x1000 white.ipg image0000X.jpg
サイズは他のページに合わせて決める。多少いい加減でもかまわない。表紙と同じでよいだろう。
最後に、convertで全頁を結合してPDFへ変換する。
convert *.jpg output.pdf
このような方法を用いると合計25分を要した作業(2),(3)は5分ほどに短縮される。手作業で回転していた分をほぼ0にできる。
少数のページを回転するときは、convertを使う方が面倒なので、いったんPDFに変換した後でPDFの回転ツールを利用した方がよい。
ScanSnapには自動でページの上下を判定し、回転してくれる機能がある。このような機能がDocActionにあれば、もっと楽になるはずだ。convertを使う必要は全くなくなる。早く改善してほしいものだ。

補足
と書いた後で、DocActionに画像の向きを設定するオプションがあるのに気付いた。当初は「自動回転(アジア言語には適用されません)」とあるので、使えないかと無視していたが、偶数か奇数かで180度回転するオプションがある。これでおおまかに回転させ、もしも偶数と奇数が違った場合はさらに全頁を回転させ、残りのページをPDFツールで回転させるとよいだろう。

2010年8月6日金曜日

Plustek OpticBookによる電子ブックの作り方

Plustek OpticBookはブックスキャナを名乗るフラットベッドスキャナだ。裁断できない本をスキャンするのに役立つ。今回は4600を用いた。ブックスキャナの特徴は筐体ギリギリまでフラットベッドが続き、本を押し付けても隙間が空かないため、きれいにスキャンできることである。
しかし、OpticBookでスキャンするには、裁断する必要はないものの、自分で1枚ずつめくりながらスキャンするしかない。
OpticBookで電子ブックを作成するには以下の手順で行う。
(1) スキャン
OpticBookで1ページずつスキャンする。スキャンしたページはJPEG形式で保存される。ここで、形式に拘る必要はない。しかし、マルチメージのTIFFやPDFは他のツールが対応していないのでやめたほうが良い。ちなみに、このとき本の最初のページからスキャンするとよい。スキャンの順番はイメージファイルの名前に関係するので、順番どおりにしたほうが良い。また、スキャンのしかたにもコツがある。99%までいけばヘッドがもどるだけなので、次のページをめくり始めることができる。そうしないと倍の時間がかかるだろう。なお、DocAction余白を切り取ってくれるので、自分で範囲指定する必要はない。
(2) ページの回転
OpticBook特有の処理である。1ページずつ本をスキャンしようとすると、偶数ページと奇数ページの向きが逆になる。奇数ページは順方向、偶数ページは逆方向だ。そこで、偶数ページだけ180度回転させる必要がある。OpticBookにはPresto ImageFolioが添付されており、インストール後はスキャンするとこのソフトが起動する。しかし、ImageFolioはブックスキャン専用ではないので、あまり気の利いた機能がない。例えば、180度回転させるには、90度回転を2回行う必要がある。また、スキャンしたイメージを一度に保存する機能もないので、何回も回転と保存を繰り返す必要がある。
(3) PDF作成
ImageFolioで読み取った複数ページを特定のフォルダに保存した後で、Presto PageManagerを起動する。保存したフォルダを選択するとページイメージの一覧が表示される。PageManagerには180度回転メニューがあるので、ImageFolioの代わりにPageManagerで回転させても良い。ただし、PageManagerではイメージが縮小表示されるので、上下が判別しにくい。回転すべきページを間違える可能性がある。ImageFolioは倍率1倍で表示するので確実だ。PageManagerですべてのイメージを選択した後、スタックメニューを選択すると、ひとつにまとめてくれる。ただし、この段階ではファイルはまだばらばらだ。デスクトップ上で重なって表示されるだけだ。次に、スタックをPDFで保存する。これで完成だ。PageManagerもあまり気が利かない。例えば、全部のページを選択するメニューがあれば簡単にできることが、それがないためにスクロールしながら全部のページを選択しなければならない。
以上の作業の所要時間は以下のとおりである。
(1) スキャン:28分
(2) ページの回転:20分
(3) PDF作成:5分
ちなみに、ページ数はPDFベースで158ページだった。サイズはB5版だ。前のA4,414ページに比べてかなり遅いことが分かる。

ScanSnapによる電子ブックの作り方

電子ブックリーダとなるマシンが増えてきているが、肝心の電子ブックが増えない。そこで、しばらくは手持ちの本を自分で電子化する以外に電子ブックリーダを利用する機会はなさそうだ。
電子ブックを作るには大きく分けて2つの方法がある。ScanSnapを使う方法とPlustek OpticBookを使う方法だ。これ以外の方法はコスト的に一般人が手を出せるものではない。もっとも最近では非常に安い価格で電子化してくれるサービスもあるので、一般人はむしろ自分でせずにそういったサービスを利用すべきだろう。ここでは、自分で電子化しようとする奇特な人のために基本的な方法を紹介する。
ScanSnapは、いわゆるフラットベッドスキャナではない。強いていればADFスキャナというべきだろうか。ADFはA4用紙を1枚ずつローラーで巻き取り、スキャン部へ送る。そのため、複数枚でも効率よくスキャンできる。しかも、PDFに変換してくれる。なお、ここではPDFに変換できた時点で電子ブックになったとみなす。その意味ではScanSnapはほぼ完璧な電子化ツールだ。
しかし、ScanSnapを使うためには書籍を裁断する必要がある。しかも、紙送りに失敗しないようにきれいに裁断しなければならない。一番安上がりな方法はカッターと定規を使う方法だ。たくさん電子化しようとするなら裁断機の導入も検討すると良い。それほど高くはないが、万は超える。
カッター、定規、ScanSnapで1冊の本を電子化するのに要する時間は約24分だ。その内訳は、以下のとおりである。
分断(背表紙を切り取り、数枚単位のまとまりに荒っぽく分ける):14分
細断(カッターできれいに1枚単位まで切り分ける):7分
スキャン:13分
一番面倒そうに思えた細断は、実は大して時間もかからない。むしろ荒っぽく本を破る分断が一番の重労働だ。スキャンはScanSnapに用紙を供給し続けるだけなので、お茶を飲みながらでもできる。
これでも分断は短いほうだと思う。というのは、今回電子化した本は論文集というもので簡易製本されたものだからだ。これがもっとしっかりした本なら、壊すだけでも時間がかかるだろう。
ちなみに、ページ数はPDFベースで414ページである。スキャン時間は単純にページ数に比例する。

2010年7月29日木曜日

デジタル教科書

ソフトバンクの孫社長は「2015年にはデジタル教科書を全小中学校に」(http://itpro.nikkeibp.co.jp/article/NEWS/20100729/350755/)導入するべきとの意見であるようだ。これは同社がiPadを販売しているからという理由もありそうだ。素直に賛成しかねる。
邪推なしに考えても、iPadを含めた電子ブックリーダはまだ紙の教科書と同じ使い勝手には達していないことが、Kindleの実験でも証明されている。KindleがだめでiPadならよいということはない。むしろ実績としては逆の方があり得る。
この議論をするには2つの点に注意する必要がある。
1つは、デジタル教科書と紙の教科書はどこまで同じであるべきか、また異なるべきかという点だ。マルチメディアが登場した際にもデジタルの優位性が主張された。実際、今の若者は本を調べるより先にWebを検索する。しかし、これはマルチメディアだからではなく、アクセスあるいは検索が容易だからだ。デジタル=マルチメディアだからといってすぐに教科書が分かりやすくなるわけではない。特にPCより非力な電子ブックリーダで再生するなら、たいしたことはできない。一方、重い教科書を持ち歩くことが少なくなったとも聞く。これにはデジタル教科書は効果があるだろう。しかし、電子ブックリーダが本だけでなくゲームもできるなら、はたして学校に持っていくことが許されるだろうか?一部地域では携帯も持ち込み禁止となっているとも聞く。ほとんどゲーム機といってよいiPhone/iPadならなおさらだろう。
2つ目は、どの年齢の子供にデジタル教科書が適しているかという問題だ。私見だが、小学校低学年はまだ体で字を覚える年齢なので、字が身に着くまではデジタル化すべきでない。早くても中学校、無難なのは高校からデジタル化することだ。多くの教科書を持ち歩く学年ほどデジタル教科書の効果は高い。本来は大学レベルの話だろう。
このまま終わりにするとデジタル化反対に聞こえてしまう。そこで補足すると、基本的には電子書籍には賛成だ。とにかく本を読むようにならないと文化も技術も衰退する。そのためには紙の書籍には限界がある。持ち歩くに困るほどの量になるからだ。しかし、それだけの読書をこなすには、読書のリテラシーが必要であり、それはある程度の年齢を経過しないと身に付かない。急がば回れともいう。子供に無理をさせる必要はないと思う。

食べるラー油

ここ数日外食が続いている。そしてそのすべてが食べるラー油のメニューだった。意図したものではなく、入った店で選んだら全部そうなったというだけだ。確かに今食べるラー油はブームのようだ。
中華のバーミヤンにラー油メニューがあるのは普通だろう。また、ハンバーグやハンバーガーもブームに合わせやすい。Ducky Duckに食べるラー油スパゲティがあるのには少々驚いた。これが結構合う。
おそらくラー油ブームも長くは続かないだろう。これらのメニューも今しか食べられないだろう。それとも以外と息の長い商品として定着するだろうか。とても賭ける気にはなれない。

2010年7月24日土曜日

Gmailの連絡先を統合するには

Gmailの連絡先には、同じ人の異なるアドレスが複数件登録されていることがある。これらの連絡先は統合できる。しかし、統合する際、困った問題が起きる。
それは、一旦統合すると、複数のアドレスの1つしか使えなくなることだ。メールを送る際に、仕事で送るのか、自宅で送るのか、状況に応じて選択する必要がある。しかし、統合された場合は、そのうちの1つしか使えない。
これは、かえって不便なので、統合しないことが多い。逆に、これを統合というのは誤りだろう。このあたりは修正してほしい点だ。

学問のすすめ

福沢諭吉の「学問のすすめ」は、名前こそ有名だが、実際に読んだ人は少ないのではないだろうか?
これは口語体以前の古典中の古典でもある。さすがに歴史的には源氏物語には遠く及ばないが、現代文と言えないことは確かだ。よって、これを読みとおすのはかなり根気がいる。
今回、学問のすすめを読んでみて、有名な1章だけでなく、続きがかなり長いことも知った。しかし、そのすべてが理路整然と書かれていることに驚かされた。未来から過去を振り返ることは易しい。しかし、その時代の中にあって将来を見通すことは難しい。この本が見事に将来を予想していることは驚くべきことといえる。
明治は激動の時代だ。それは現代にも通じる。実のところ、現代は不透明ではあるが、明治ほど激動ではない。むしろ、深く静かに変動するから余計に分かりにくい。
明治には西洋化という単純な答えがあった。今は単純な答えが見えない。しかし、西洋化という答えも未来から見通した解答例に過ぎない。福沢諭吉は、その時代の中で、自分の頭でその回答にたどりついた一人だ。したがって、今の不透明な時代でも正しく読み切れば、未来を十分に見通すことは決して不可能とは言えない。
やや問題なのは、多くの識者が独自の予測を公開するので、かえって情報が混乱していることだ。よって、受け取る側も正しく判断できる能力が要求される。

青空文庫で古典を読もう

青空文庫は無料の電子ブック書店だ。iPhone, iPadはもちろん携帯やPCでも青空文庫の電子ブックを読むことができる。
前の記事で若者はiPadで電子ブックは読まないだろうと推測した。しかし、読んでほしいと思っている。iPadでなくてもよい。携帯でも読めるのだから読んでほしい。少々大げさだが、それしか日本を立て直す方法はないと言ってもよい。読書が国力を決定する。
青空文庫の本はいずれも著作権が切れた古典だ。音楽でいえばクラシックだ。古典は時代を超えて残った秀逸なものばかりだ。ロックは人気があるが、音楽の世界ではクラシックが最高峰だろう。同様に、現代の人気作家の作品も悪くないが、古典は何度繰り返して読んでもいい。いつの時代にも影響を与えた。無料で古典の秀作が読めるのに、わざわざ高い金を払って駄作を読む必要はない。
しかし、現代のくだけた文体に比べて、古典はいささか古めかしい。とっつきにくい。違和感を感じる。しかし、それを乗り越えると、その表現力に感動を覚える。現代作家も華麗な表現は巧みだ。しかし、古典の表現は素朴でかつ力強い。もちろん作家による。

若者は電子ブックを読むか?

今現在の状況を考えると、おそらく答えはNoだろう。
2つの理由で判断できる。1つはそもそも大多数の若者には読書をしようという意思がないこと、もう1つは若者に読みたいと思わせるコンテンツがないことである。私に言わせれば、前者が主であり、後者が従だ。それだけ根深い問題だと言える。
iPadは若者にも人気だと思うが、実のところ実際に所有している若者は決して多くない。若者はいまだに携帯に依存している。iPhoneもiPadも、PCすら必要性を感じていない。よって、おしゃれなiPadで電子ブックを読書するようになる若者が増えるだろうという考えは甘い。
iPadはPCより安いが、Netbookほどには高い。これは小遣いで気軽に買える範囲ではない。しかも小遣いの大半を携帯電話代として支出してしまうものには、わずかな小遣いしか残らない。さらにiPadは携帯の代わりに使えるものではない。よって、若者がiPadを使いこなすシーンはしばらく見られないだろう。しばらくとは、親の景気が良くなるまでだ。それは日本の景気が回復するまでだといってもよい。
製造者にも責任がある。iPhone, iPad, PCのいずれも安くないが、そのすべてを購入しなければ快適なデジタルライフが完成しないのだ。iPhoneもiPadもPCを必要とする。しかし、iPhoneやiPadを購入するとその通信費も合わせればPCを買う余裕がない。All or Nothingだ。そしてNothingを選ぶものは多い。普通の携帯で十分だからだ。しかし、学生も就職すれば、やがてiPhoneを選択するだろう。
もう1つの理由も深刻だ。iPadの登場で電子ブック市場は活気づいている。しかし、市場の活気と正反対にコンテンツの充実は遅々として進まない。今は期待が先行している。
その期待がいつまで続くかが問題だ。日本のコンテンツのステークホルダーは既得権に固執し、世界の流れから孤立することを厭わないようだ。元々日本語という見えない関税障壁に保護されていた産業である。世界を見る気はないのだろう。しかし、一部のコンテンツは世界を相手にすることで成功を収めており、世界を無視することの愚かさを立証している。
よく日本の識者が著作権と絡めて電子化を議論するが、それはほとんど無意味だといってよい。日本が鎖国に戻るのでない限り、世界が電子化を選択している以上、それに従うしかない。むしろ、抵抗することによって、日本人が良質の電子ブックを読めないことの弊害が大きい。若者に読書しろと言いながら、読むべき本を作らないでいる。逆に、英語や中国語の電子ブックはどんどん出版されるだろう。読書量が科学力や技術力、そして文化力を決定するといってもよい。今の日本は自分で自分の首を絞めているといってもよい。

2010年7月23日金曜日

JVM内の仮想プロセス

JVMは1つのプロセスとしてOS上で実行される。
プロセスはメモリが独立しており、共有しない並行実行の単位だ。よって、ソフトウェアから見るとプロセスもPCも大差なく、いずれも分散環境を構成している。
しかし、Javaで分散システムのモデルを作成するとスレッドで表現することになり、共有してはいけないにもかかわらずデータを共有してしまう。それによって実際にはありえないバグが混入することがある。
そこで、JVMにもメモリを共有しないプロセスを導入してはどうだろう。実際のプロセスはOSに強く依存するので仮想プロセスが良いと思う。仮想プロセスが使えるとソフトウェアの信頼性を高めることができる。例えば、スレッドで構築しているFirefoxはよく落ちるが、プロセスで構築されたChromeはなかなか落ちない。原因はそれだけではないだろうが、そのような傾向はある。
一見、無駄なことをしているようだが、手軽にできる手法としては有効なものだろう。

2010年7月22日木曜日

JNode

JNodeはJava OSだ。昔からJava OSは様々あったが、満足に使えるものに出会ったことがなかった。
JNodeは開発中ではあるが、少なくとも動かすことができるので、いろいろ使えそうだ。
OpenJDKで動作するようで、Sun JDKよりは遅いらしい。
コマンドはJavaの特徴を生かしたユニークなものだ。これを覚える気は正直しない。むしろ一般的なUNIXのコマンドが移植されてから本格的に使うようにする方が良いだろう。しかし、あまりにUNIXに固執するとJavaの長所も失う可能性があるので、妥協は必要だ。
面白い特徴としてネットワークに拡張されたPATHがある。Javaではあたりまえだが、UNIXにはそのような考えはない。例えば、Webサーバで公開されたclassファイルへのURLをclasspathに追加すると、それをコマンドとして利用出来る。つまり、わざわざインストールする必要がないわけだ。このようなアプリケーションの配信方法は真面目に議論するに価するだろう。

2010年6月30日水曜日

シャーロック・ホームズはルパン三世

飛行機は映画館を兼ねている。
最近はアリスとシャーロック・ホームズを見た。
シャーロック・ホームズはBBCの作品が有名だが、新作はまるでルパン三世だ。
まずホームズに悪女の恋人がいる。まるで峰不二子だ。
助手のワトソンが拳銃を撃つわ、仕込み刀を振り回すは非常に活動的だ。まるで、次元と五右衛門を足して2で割ったかのようだ。
おまけにホームズは少々間抜けで倫理観が乏しい。
これをルパンと言わずしてなんと言おう。でも役者ははまり役だし、内容的にはとてもよい。

2010年6月23日水曜日

La Banchina

ジェノバの港に位置するレストランだ。こちらもレストランというよりカフェ・バーといった方が正しいだろう。
よいレストランの基準はいつも混んでいることだろう。その意味ではよいレストランといってよいだろう。
ここのオススメはfocacioだ。いわゆるフォッカチオだ。日本でもメジャーになっていると思う。ジェノバのフォッカチオは独特らしい。それをメインにしている店なのでハズレではないだろう。そもそも他の国に比べたらイタリアはどの店もうまい。その意味ではハズレを心配する必要はない。
人によって好き嫌いはあるだろうが、私は非常に好きだ。これをまずいという人はまずいないと思う。シャレではない。生地は日本のように厚くない。シカゴピザとイタリアピザの違いを思い浮かべてもらえばよいだろう。最初に皿を見た時はとても食べきれないと思ったが、生地が薄いので、それ程ではない。なお、ピザより生地が柔らかい。近い食感を探せばチジミだろう。値段は6-7ユーロで、 660-770円といったところだ。日本で同じようなピザを注文すれば倍になる。また明日も来てしまうかもしれない。
また、この店ではイタリアのビールをメインにしているようだ。ワインが続いているので、その点でもよい。

2010年6月22日火曜日

Covim

ジェノバの港にあるレストランだ。港を歩いているとかなり目立つ。立地が非常によい。だから料理もよいのかと思えば、まずくはないが物足りない。オーソドックスな料理しかないからだ。元々はレストランというよりカフェないしバーというべきなのだろう。バーの割には料理がレストラン並によいと考えるべきだろう。決して悪い店ではない。
個人的な希望を言えば、もっとシーフードを充実するべきだ。せっかく海の幸があるはずなのだから。
その後、街中でも見かけた。チェーン店のようだ。

ジェノバの海

港町という感覚がしない。町に十分な観光資源があるためだろう。あるいは観光自体に経済の軸足を置く必要がないのかもしれない。相対的に海の存在感が小さい。
その性か海が臭くない。日本の海辺の町はほとんど例外のないほど臭い。海にいろんなものが流れ込んでいるのだろう。これは海を活用していることの負の側面だ。よほど環境にこだわりがない限りうみは臭くなる。しかし、ジェノバの海は臭くない。これはジェノバが海から脱却していることの間接的な証であるように思える。

Munich airport

Luhthansaでミュンヘン経由でジェノバに行った。ミュンヘン空港で乗り換えの際に無料のコーヒーサービスがあることに気づいた。ファミレスのサーバより多くの種類がある。さすがだ。
日本のファミレスももう一工夫してはどうだろう。変わったメニューにはウィンナーコーヒーがある。

自動化ゲート

あまり知られていないようだが、成田空港には自動化ゲートがある。自動化ゲートを使うと入出国の長い行列に並ばずに済む。経験した人にはわかるが、入出国の行列で待たされるのはかなり苦痛だ。それがほとんど待たずに入出国できるのでとても便利だ。しかし、あまり使われていない。私も使っていない。なぜなのか、問題点を指摘しておこう。
自動化ゲートを利用する手続はあまり知られていないが、とても簡単だ。当日空港で手続できる。しかもその場でできる。ゲートの脇に係官がいて申込用紙に記入すれば手続きできる。基本的には住所と旅券番号だけなので、何も特別な情報は必要ない。それならいっそすべての窓口で勧誘してはどうかと思うのだが、混雑するので、それはしないようだ。しかし、呼びかけてもよいとは思う。パンフレットを配れば良いだけなのだ。
これだけなら使わない理由にはならない。使えない理由の一つは8:00-17:00しか手続きできないことにもある。手続きだけでなくゲートも使えないかもしれない。これはその時間帯が混雑していないからなのか、それとも御役所仕事の決まりなのかは定かでない。
しかし、これも使えない理由としては小さい。個人的には最大の問題点は、入出国スタンプを押してもらえないことだ。業務として出張するときは、証明が求められる。スタンプを証明とする会社は少なくない。それがないと出張では使えない。
これを解決するには2つの方法がある。1つは別の証明書を印刷するサービスだ。もう1つはスタンプ以外で証明する制度の変更だ。後者の方が抜本的で長期的には正しい対応だが、短期的には全く効果がない。やはり経費をかけても印刷するべきだろう。少なくとも印刷機を別途用意して出国後や入国後に有料で証明書を発行すれば、経費の問題は生じないはずだ。利用者は、その経費を会社に請求すればよい。

Google SVを用いたドライブシミュレータ

ドライブをするとき道に迷うと不安だ。それを助けるのがカーナビだが、その指示はあてにならないことが多い。対向車とすれ違えない細い道を通らされたり遠回りさせられたりすることがある。そのような場合に実際に自分で下見の運転ができると便利だ。Google SVを使えばドライブシミュレータを実現できるだろう。
現在のSVは歩行者目線であるように思える。運転者目線の視野が欲しい。そのデータは既に収集されているはずだ。さもなければ画像の更新の際に前方画像も加えて欲しい。交通標識もチェックしたい。車速に応じて所要時間も計算できるようにしたい。

組み込み機器の多言語化

日本が世界に通用する製品を作るには国際化が欠かせない。それにはユニバーサルな製品の製造が必須だ。なかでも組み込み機器の多言語化は重要だろう。
日本の製品は、少し気がきいたものでは日本語と英語のバイリンガルに過ぎない。中には英語メニューのないものもある。しかし、これからは二カ国語対応だけでは不十分である。多言語化が必要だ。

予約受付にクラウドを使おう

iPadに続きiPhone 4の予約が順調のようだ。サーバがダウンするほどのようだ。iPhone 4については2年縛りがあるので、それほど急ぐ必要がない私としては予約しようとは思わないが、落ちるシステムが蔓延している現状に憂いを感じる。
クラウドがもてはやされている今日で予想以上のトラフィックが集中したと言ってサービスを停止するようでは、クラウドを利用していないか、あるいはクラウドが不十分であるかのいずれかだろう。おそらく前者だと思うが、後者の可能性もある。1つはリアルタイム性、ないしレスポンスの素早さだ。緩やかにトラフィックが変化する場合には現状のクラウドでも十分対応可能だろう。しかし、素早いレスポンスは実現できない。新しいノードの起動に時間がかかるからだ。今のところ予測しながら制御するしかないだろう。しかし、開始時点では予測すら困難だ。これはクラウド側の重要な課題の一つだろう。
一方で、多くの場合は事前に予算を確保することも含めて準備がおろそかなせいだ。クラウドなら実際に利用された分しか支払う必要がないのだから、予想より多くサーバを用意してスケールを下げる方法も検討すべきだろう。

2010年6月10日木曜日

レガシーとなる圧縮ファイル

LZHの開発が終了するらしい。
世の中にはLZHで圧縮されたファイルがかなり多く出回っている。やがてLZHをサポートしたプログラムがなくなると、これらのファイルはただのゴミになる。
今のうちにもっとメジャーな圧縮形式に変換しておかなければならない。これからは圧縮ファイルがレガシーとなる時代になったようだ。
しかし、圧縮ファイルはめったに使わなくなったデータを保管するために使っているので、それをわざわざ整理しなおすのは非常にめんどうだ。
このような場合、クラウドに圧縮データを預け、引き出すときに別形式でダウンロードできるとよい。仕掛けとしては、アップロードの時にZipなどのもっとメジャーな形式に変換してしまう。
クラウドにデータを預ける方が長期間の信頼が得られるという時代が来るかもしれない。

2010年5月31日月曜日

iPad

iPadを購入した。
少しずつ使い始めているが、まだ使いこなせていない。しかし、早速いくつかの問題点が見えてきた。
画面が広いのはよいことだ。できればPCの代わりに使いたいと思っている。しかし、入力が非常に貧弱なので困る。
PCの代わりに使うという考えはビジネス用途に使うという考えと近い。必ずしも同じではないが、多用な用途に応えられなければならないという意味では同じだ。
ビジネスでは入力が重要だ。そこで別売りのキーボード付きドックも購入した。しかし、結果はがっかりだ。
まず、Keynoteだが、横置きでしか動作しない。しかし、キーボードドックを使うと縦にしか刺さらない。なぜ、回転式にしないのだろう?あるいはKeynoteが縦置きにも対応するべきだろう?このようにアプリケーション側の対応が不十分なので、キーボードドックは十分に使えない。
では、キーボードドックなしでkeynoteを使おうとするとTABをどう入力したら良いのかわからない。TABは箇条書きには欠かせないキーだ。今までiPhoneでしか使ってこなかったのでTABを入力するような利用法はしていなかった。しかし、普通に使おうとすると、これが大きな問題になる。
いきなり一番やりたかったことができないということになってしまった。
次に、同じくkeynoteだが、この種のオフィスソフトがどのようにファイルを他のアプリケーションと連携するのか疑問だった。iPhone/iPadの発想では、各アプリがそれぞれ独自にファイルを囲い込み、他のアプリから利用できないことが多い。また、それを推奨しているようにも見える。アプリによって専用機化する発想では当然かも知れない。しかし、PCでは単一アプリにできないことを他のアプリでまかなうことが当然のように行われている。アプリケーションの連携は常識だ。keynoteではiwork.comを経由して共有が可能となっている。これが次世代アプリの形態かもしれない。つまり、アプリ単独では完結せず、サービスと一体となる必要があるということだ。このような考え方は、このブログでもかねがね主張してきたので、やはりと思った。小さなソフト会社はiPhoneアプリに進出しようと考えているかもしれないが、あっという間に淘汰される時代が来そうだ。なぜなら、小さな会社にはこのような共有サイトの運営が困難だからだ。少なくとも開発者だけでは無理で、運用者を雇用する必要がある。

補足する。KeynoteのインデントはPowerPointと同じTABだと思っていたが、そうではなくインデント自体できないようだ。キーボードドックを使えばTABは入力できるが、少なくてもiPadのkeynoteではインデントしない。

花畑牧場のアイスクリーム

プレミアムバニラを食べてみた。
従来の日本メーカーのバニラともハーゲンダッツとも違う。
ちょっとジェラートに近い感じがする。
これは良い視点だと思う。ハーゲンダッツに勝つには、その差を明確にしないといけない。
ジェラートなら人気が高い上に明らかに違いがある。正しい戦略だと思う。
ただし、買ってから少し時間が立っていたので、ジェラートだと思ったのは気のせいだったという可能性もないわけではない。

2010年5月24日月曜日

iPod in iPad

iPodを仮想化できればiPadで複数のiPodを動かせるかもしれない。もちろんAppleが許せばの話だ。
CPUが制約になるかもしれないが、少なくとも画面は制約にならない。iPadには複数のiPod画面を表示する余裕がある。
iPhone OSはマルチタスクでないので、複数のアプリを動かすには仮想化するしか手がない。
今後iPodが普及すると、iPhoneを含めて複数のiPodを所有するようになるだろう。そのような時代にはiPod in iPadのような仕組みが必要になると思う。

2010年5月21日金曜日

プロキシー経由の自動更新

プロキシー経由で自動更新できないというトラブルが多い。
最近、プロキシーを使わなければならないセグメントにPCを移動したため、同様のトラブルに出会った。
そこで対策だが、「インターネットオプション」でプロキシーの設定をするだけでは十分ではない。しかし、まずはインターネットオプションで設定する必要がある。
これだけでは十分でない理由は、自動更新が本人でない設定でアクセスしに行くためらしい。そこで更新用のアカウントの設定をいじればよいらしいが、一番簡単な方法は以下のコマンドだ。
xp> proxycfg -u
vista> netsh winhttp import proxy soruce=ie (管理者権限にて)

Googleドキュメントが不安定

Googleドキュメントが最近使いにくくなっている。
改良と思われない変更や、画面の乱れなどがある。少々早まったリリースだったのではないだろうか?いうなればDocs Vistaといったところか。
1つはPDFの扱いだが、以前保管したPDFがスキャンできなくて表示もダウンロードも出来ない状態になってしまった。スキャナで読み取っただけのPDFなのでイメージのようなものなのだが、それを無理に文書に変換しようとしているのだろうか?OCRがあるわけでもないのに。
また、IEだけの問題かもしれないが、左のフォルダのメニューにスクロールバーが表示されない。そのため表示されないフォルダにファイルを移動するのが、難しくなってしまった。
さらに、アップロードボタンがuploadのままだし、メニューが一部英語のままだ。しばらくDocsはじめAppsはベータ版でなくなったと思ったが、実際にはベータ版と対して変わらないようだ。機能がベータなのではなく、運営がベータのつもりの運営をしているということだ。

2010年5月20日木曜日

自販機で通販

通販でコンビニどまりにする理由はクレジットを使えなかったり、留守にしていることが多かったりすることだろう。このような場合、コンビニで預かっていてもらえるのはありがたい。
コンビニは便利だが、しかしどこにでもあるというわけではない。もう少し小型の類似サービスが有っても良いと思う。店舗で言えば街中キオスクとか、店舗に限らなければ自動販売機だ。
自販機にはかなりの決済機能がある。電子マネーはもちろんクレジットカードだって不可能ではないだろう。また、液晶画面もあるので注文だってできるはずだ。そうなれば商品の受取も自販機でしたくなる。
コインロッカーと自販機を組み合わせたシステムを作ればよい。暗証番号を入力し、料金を支払えば、ロッカーが開き商品を入手できる。期日が過ぎたら、商品を回収しに来ればよい。
自販機メーカーは新しいビジネスモデルの可能性に気づいているだろうか。

2010年5月11日火曜日

coleto

coletoはパイロットのボールペンで、各色の芯を好きな組み合わせで選んで使える。パーソナライズされている。
一つの芯がなくなっても、それだけ取り替えればよい。エコロジーでもある。
いろいろ取り替えられる利点を活かしてスタイラスペンを使えるようになるとよい。
またシャーペンも使えるようになるとよい。そうすると使える色が少なくなるが、少し太めの5色にしてもペンの数を減らした方がよい。

カロリーフリーの蒟蒻畑

蒟蒻畑は誤飲などの問題も多いが、それ自体は魅力的な商品だ。とくにダイエットに有効だろう。しかし、実際にはかなりカロリーがあり、ダイエットにはあまり向かない。そこでカロリーフリーの蒟蒻畑を作ってはどうだろう。

2010年5月10日月曜日

Googleドキュメントが不便になった

いつの間にかGoogleドキュメントの機能が変更されて不便になった。
PDFをアップロードすると、Wordに変換されるかあるいはプレビューできないかのいずれかになった。
PDFをもっと便利に利用出来るようになると予想していたが、期待はずれだ。
プレビューできないなら、ただのストレージと同じだ。

2010年4月27日火曜日

Google Cloud Driveはいかが?

Google Cloud Printerができるなら、少し工夫すればGoogle Cloud Driveもできそうだ。
Googleがするかどうかは別として。
ここでいう、Cloud Driveとは、Cloud上にデータを保存するという意味ではない。Cloudを介してあらゆるドライブを結合するという意味だ。つまり、PCにUSB接続してPCだけからしか使えないのではなく、インターネットに接続してあるドライブをどこからでも使えるようにするというものだ。
アクセスなどセキュリティに関わる部分をCloudで処理する。
おそらくiSCSIなどを改良してCloudと接続できるようにすることになるだろう。
Cloudnoメリットである「手間なし」という利点はないが、少なくとも安くて便利なツールにはなるだろう。

2010年4月26日月曜日

Google Cloud Printer

Google Cloud Printer(GCP)は前々から欲しいと思っていた機能だ。詳細も見ないとまだ結論を出すには早いかもしれないが、大いに期待したい。
GCPが利用されるようになるとプリンタが便利に使える。ドライバが不要となるのはすばらしい。デバイスドライバはOSの機能の1つと考えられているが、長所というよりむしろ必要悪だった。いままでのOSの怠慢からユーザが不便を被っていたというべきだ。元々デバイスドライバはユニバーサルのもので十分で、かつオンデマンドであるべきだ。GCPになって、ようやくデバイスの悪夢から解放されるのかもしれない。
ここまでは現在の話だ。ここからが本番である。将来の話をしよう。
まず、GCPと類似のしくみがプリンタ以外にも広がるだろう。HDDなどはすでにユニバーサルであるが、加えてスキャナも統合されるだろう。これからはドライバレスがOSの標準機能になるだろう。
次に、プリンタに限って深く追求してみよう。プリンタを印刷機として捉えると、今回の改善の意義を過小評価してしまう。プリンタは広義の文書変換機能である。PDF作成やFAX送信などがすでにこのような使われ方をしている。この考え方を推し進めると、ほとんど何でもプリンタで処理できるようになる。例えば、単純なファイル単位の印刷だけでなく、複数ファイルをまとめた製本化も考えられる。宅配まで含めてサービスを構築できる。携帯からもPDFを介さず直接印刷できる。将来はGCPで雑誌や新聞が電子化して配信されるかもしれない。

飛行機の窓にソーラーパネル

長時間の飛行の間、iPhoneやPCを使うとバッテリーが不足する。交換バッテリーを用意してもなかなか足りない。そんなときソーラーパネルで充電できるとありがたい。AC電源のある飛行機はまだまだ少ない。特にエコノミーでは座席も限られる。そこで、窓にソーラーパネルをおいて使うことが考えられる。
携帯型のソーラーでは電力も限られるが、利用時間をわずかでも延長できるなら十分な意味がある。割り切ればよい。
機内では、通常は窓を閉めるように指示されるので、窓を閉めた状態でも使えるように工夫する必要がある。ソーラーとバッテリーが組み合わされた製品ならそのまま窓辺においておいてもよい。あるいは、充電しながら利用するなら、細い線で電気を取り出すようになる。今ある製品でもできない使い方ではない。

財布

財布はどこで買えばよいのだろう。
財布が壊れたとき、スーパーで探しても見つからない。100円ショップには、それなりにあるが、どれもあまり良いものではない。見た目が悪いというより、そもそもの機能が十分ではない。
財布の使い方は人によって異なるので、売られている財布が私のニーズに合わないだけのことではある。
私は財布に小銭、紙幣、カード、名刺などをかなりたくさん入れている。そのため、財布が膨れ上がりとうとう壊れてしまった。これらはどれひとつとして欠かすわけにはいかない。小銭と紙幣を分けると2つの財布を使い分けなくてはならない。なるべくカードで支払うようにしているが、やはり現金は必要だ。また、名刺入れを別にすると時々忘れることがある。特に日常と異なる服装をしているときに忘れがちになる。そのため、これらは1つにするべきだとだいぶ前から考えるようになっていた。
しかし、これだけ収納できる財布はめったにない。しかもコンパクトでポケットに収まるものとなると非常に少ない。

COMET仮想マシン

今風に言えば、COMETは非実在CPUだ。:-)
情報処理試験の中でしか使われない、テストのためだけの存在、実用性ゼロのCPUだ。それを覚えろという試験もどうかと思うが、覚えるのは難しくないので、そのくらいは覚えろということだろう。要はCPUを理解するためのおもちゃだ。
しかし、玩具として使うなら、実際に遊べなくては面白く無い。COMETは物理的には存在しないが、仮想的に実在させることはできる。実際、多くのエミュレータが作成されている。これらを使えば、ある程度のことができる。しかし、ある程度のことしかできない。
今のエミュレータはあくまでもCPU単体(+メモリだが)でしかない。周辺装置がない。そこで、これを1台のPCとして利用できるまで拡張すれば、もっと遊べるようになるだろう。もしかしたらCOMETチップができるかもしれない。あまり早くはないだろうから、期待はできないが。

PCのキーボードが故障したら

とても不便なのでPCを買い換えたくなった。おそらく近々買い換えるだろう。しかし、先立つものが必要だ。それと、もうひとつ重要なものは、買い換えたいと思うような製品があるかどうかだ。正直、今買いたいと思わせるPCがない。それでもなにか買うことになるだろう。
今のPCはどれも積極的に買いたいと思えるものではない。よいPCは少ないが、高い。かなり割高に感じる。日本製が多い。安いものは、機能的にどれも見劣りする。バッテリーか重量かどちらかが不満だ。CPUの性能には昔ほどこだわらなくなった。PCには、まだまだ工夫の余地がありそうだ。問題は、PCの開発にメーカーがかける経費がかなり少なくなっていることだろう。つまりは、魅力ある商品を作る意欲が無くなっているということだ。
話は戻るが、キーボードが故障してもPCは使うことができる。1うはUSBキーボードを外付けすること。もう1つは仮想キーボードを使うことだ。USBキーボードを持ち歩くのは面倒なので、最近は仮想キーボードに頼っている。仮想キーボードはIMEに最初から備わっている。しかし、iPhoneの仮想キーボードに比べるとWindowsの仮想キーボードは非常に使いにくい。これは今後絶対に改善しなければならない点だろう。

Googleカレンダーにスレッドを

カレンダーにもスレッドが欲しい。なぜなら、関連するスケジュールがどの程度進行しているのか、ならなか把握できないからだ。スケジュールはすべてGoogleカレンダーに書いてあるので、カレンダー上で確認できるようになるのが一番便利だ。
例えば、毎週の予定などは基本的に一連のイベントとして管理されている。それに例外的な予定を組み込むこともできる。しかし、すれに設定されているイベントを削除したり、日付を変更したりするぐらいで、新たな予定を別のスレッドに加えることはできない。(と思う。)しかし、このような機能は必要だろう。

GoogleでLifelog

書類をPDFにしてDocsにアップロードしている。今ではGoogleをLifelogのメインストレージとしている。そのような中で、DOcsがPDFの編集機能をサポートしていると非常に助かると思っている。これはおそらく遠くない将来叶えられると思っている。そこで、その先を考えてみる。
次のステップはPDFからOCRで文字を取り出す過程だろう。DocsのOCRサポートが次の一手になるだろう。これは検索を容易にするので、Googleにとっても都合がよい。ユーザ自身がPDFを検索しやすいように修正してくれるわけだ。機械的な自動処理が難しい時にはツールを無料で提供することでユーザの自発的な行動を促すのが賢いやり方だろう。

Temporal URL

今のURLは現在のアドレスを指すものだ。その内容が変化してもアドレスが変わるわけではない。
しかし、時に資源を内容でさしたいことがある。そのような場合、コンテンツベースあるはテンポラルなアドレスが必要になる。両者は微妙に異なる。前者はコンテンツが等しい期間を指し、後者は任意の時間を指す。キャッシュの制御なら前者で十分だが、アーカイブを考慮すると後者が必要になるだろう。

Google Money

Googleがまだ手をつけていない市場がマネーだろう。Adsenseなどで実際には金のやり取りを行っているが、個人の資産管理まで立ち入ったサービスはない。一方のマイクロソフトはすでにMoneyで市場を支配している。Moneyは言い換えれば家計簿のようなものだが、経済活動では相手の資産を知ることはカードゲームで相手の手の内を知ることに等しい。ごく限られた情報を活用するだけでも広告の精度が高まる。例えば、年収によって推奨させる商品の価格帯が変わってくる。
問題はプライバシーをクラウドに提供することだろう。これには本人の許可が必要なことはもちろんだが、それでも必要最小限でなければならない。そして、その見返りにそれ以上のサービスを提供することで納得して貰う必要がある。例えば、金融機関が提供しているオンラインバンクを統合して、複数の金融機関にシングルサインインできたり、利率などを比較できるようなサービスはがどうだろう。踏み込みすぎだろうか。

待たせるコールセンター

コールセンターは普通は待たせないことを目標とするものだ。しかし、逆説的かもしれないが、必ずしも待たせることが悪いこととは限らない。待たせなくても担当者が変わる度に同じことを説明する方が問題だ。交代する前に前任者とのやりとりを聞き直す時間をとることも時に必要なことだろう。

Google図形を使ってみた

Googleドキュメントに図形が加わった。かなりWordの図形描画に近いもので、ますます便利になった。
しかし、まだまだ頑張らなければいけない点も多い。
1つは線を図形と連結させることができないことだ。(出来る方法があるのだろうか?)この機能がないと図形を移動するのが非常に面倒だ。
もう1つは簡単な定型図形を手軽に作る機能だ。例えば、マインドマップなどが有力な候補になるだろう。マインドマップが作れるだけで、多くの生産的な活動をサポートできる。そして、マインドマップを作成するには第1の条件を満たす必要がある。

2010年4月8日木曜日

日本型携帯がiPhoneに勝つには

iPhoneを使っているが、もう普通の携帯には戻れない。もちろん、逆の人もいるだろう。iPhoneでは今まで通りの使い方ができないので、以降できないという人は少なくないはずだ。しかし、ガラパゴス問題を解消しない限り、日本の携帯に未来はない。そのうちiPhoneやAndroidがi-modeを駆逐するだろう。そうなる前に日本企業も手をうつべきだ。
iPhoneが世界的に成功し、日本型i-mode携帯が失敗したのは訳がある。i-modeはインフラの力で携帯にインターネットをアクセスさせる。WAPはもっとそうだったので、もっと普及が難しかった。しかし、iPhoneはインフラなしでもインターネットにアクセスできる。その違いは定額データ通信ではなく、WiFiをサポートしたかどうかにある。WiFiならば無料で高速にインターネットにアクセス出来るのだから、i-modeはいらないことになる。もちろんiPhoneがOSまでPCに近いものであることも重要だ。普通のSafariが動くのだから、この違いは決定的とも言える。しかし、SafariもWiFiなしでは宝の持ち腐れだったろう。つまりはWiFiサポートがポイントだと思う。
ならば日本の携帯もWiFiをサポートし、SafariのようにPC級ブラウザを使えばよい。これで欠点を減らすことができる。その他の欠点も克服できる。
例えば、インターフェースもiPhoneを真似すればよい。マルチタッチで、仮想キーボードにする。しかし、これだけではモノマネなので、もっと強みを活かす。例えば、ワイドスクリーンを採用する。これはiPhone HDで並ばれるかもしれない。
次に、アプリだが、iPhoneアプリは非常に豊富で太刀打ち出来ないように思えるかもしれないが、i-modeのアプリは数こそ少ないが採算の取れるビジネスになっている点でむしろ進んでいるとも言える。少数精鋭のiアプリを世界展開できるようにするべきだ。それにはi-modeで閉じたiアプリのままでいるのではなく、Iアプリ、つまりInternetアプリになる必要がある。携帯側がIアプリをサポートするのは簡単だ。アイコンにしてデスクトップ?に並べればよいだけだ。
次に、音楽プレイヤーとしての機能だ。残念ながら日本メーカーではiTunes Music Storeは作れない。よって、音楽配信のサービスは最初から諦めるか、Amazonと提携するべきだ。しかし、高品質の音楽を再生することならば負けない。着うたフルのようなサービスを世界展開すればよい。
これでようやく肩を並べることができる。次は反撃だ。
まず、WiFi+3Gは決して十分とは言えない。やはりWiMAXを追加するべきだ。これで携帯としても安価で高速なデータ通信が可能になる。キャリアとしても3種の組み合わせなら課金しやすい。3つの合計より低ければ納得して値上げに応じるユーザが多いだろうから。
次に、得意のデジカメで高画質の写真やビデオ撮影を可能にする。microSDHCをサポートして、長時間録画を可能にする。また、QRコードの認識も必須だ。高速度撮影機能なども取り入れればよい。
microSDHCはデータを扱う上でも必須だ。PCとのデータ連携がずっとスムーズになる。カーオーディオとも連携しやすい。車では携帯より音質の良いステレオに再生を任せればよい。
大切な点は、PCなしでほとんどのことができるようにしておくことだ。日本メーカーはPCも売りたいかもしれないが、そこは我慢しなければならない。なぜなら、PCではiPhone+Mac連携に及ばないからだ。むしろPCがなければ使いたいと思うユーザを取り込むことを考えるべきだ。
最後になったが、電子マネーも当然取り込む。
これだけの機能を世界標準からはずれないように安価に提供できれば、iPhoneに負けることはないだろう。

2010年4月6日火曜日

DropBoxの利点と欠点

前の投稿でDropBoxを導入したことを述べたが、その後しばらく使い続け、DropBoxの長所や短所がみえてきた。
DropBoxは普通のいわゆるオンラインストレージではない。例えば、SkyDriveと比較すると、SkyDriveにあるファイルを編集するにはダンロードとアップロードを行わなければならない。しかし、DropBoxのファイルはそのまま直接編集出来る。これはファイルの実体がローカルのドライブにあるという意味だ。同時にリモートのサーバにもある。つまり、ローカルとサーバの両方にコピーがあり、それを同期するサービスがDropBoxだということだ。
このため、ローカルドライブの容量を超えるようなファイルを収容することはできない。ローカルのノートPCの容量が4GBだとすれば、それ以上は増やせない。まだ試していないが、容量の異なるノートPCでDropBoxを使うと、最小サイズに合わせる必要がある。さもなくば同期できないというエラーになるだろう。初期のEee PCのようなディスク容量が4GBしかないようなマシンではまともに使えないだろう。
しかし、それ以外の点では非常に便利だ。ダウンロードとアップロードの手間もかからず、オフラインでも使える。Gmailへの添付もローカルディスクそのものの操作だ。
つまり、DropBoxとSkyDriveは使い分ける必要がある。SkyDriveのような大容量?のオンラインストレージに安全にファイルを保管して置いて、必要に応じて現在よく使うファイルだけを選んでDropBoxに入れる。これで、どこでも作業ができるようになる。
ちなみにDropBox Portableというものもあるので、USBだけでどこでも作業ができる。しかし、このDropBox Portableは曲者で、すでにDropBoxをインストールしたマシンでは動作しなかった。他のマシンでも果たしてまともに動くかどうか怪しい。

2010年4月1日木曜日

DropBox

DropBoxは便利だと聞いていたが、容量が少ないので使う価値がないと思っていた。
しかし、10GBに容量がアップされるという話を聞いて、使い始めた。
使ってみたら、便利さに驚いた。他のストレージサービスが使いにくく感じる。特にSkyDriveなど容量が大きだけしか取り柄が無いストレージは、今後使わなくなるかもしれない。Google Docsはタグで情報を整理するのに使い続けるだろう。
SkyDriveが生き返るにはMicrosoftがDropBoxを買収すればよい。容量+機能の最強コンビになるだろう。

2010年3月30日火曜日

情報とメディア

情報系学部にメディア系学科があることがある。日本でのメディア系の先駆者といえば東京工科大学だろう。しかし、世界を見れば前例はいくらでもある。中でももっとも有名で模範とされているのはMITのメディアラボだ。
メディアには様々な意味合いがあるが、社会科学系メディアとの違いが重要だろう。社会科学系メディアが主として対象としているのはマスコミである。言い換えれば多人数を対象とした人と人の対話である。ここで、より本質的な点は多人数よりむしろ人と人にある。情報科学系メディアの起原は人とマシンの対話、マン・マシン・インターフェースあるいはヒューマン・コンピュータ・インターフェースにあるからである。この違いにより社会科学系ではほとんど扱われない情報系独自のメディアがある。それはメディアとしての芸術である。メディアラボの最近の活動も工学分野だけでなく芸術分野に広がっている。
また、人とマシンが直接対話しているように見えても、マシンの向こう側にもう一人の人がいるような場合、例えばSNSのような場合は情報系と社会科学系の両方の意味合いを持つ。今後は両方のメディアが統合されていくと考えられるので、縦割り的な区分は排除していった方がよい。つまり学生にとっては選択肢が増えるわけだ。しかし、しばらくは得手不得手があり、志望に合わせて選択する必要がある。

2010年3月24日水曜日

iPhoneで万歩計

iPhoneはライフログのデバイスとして有望だ。ライフログには健康管理の応用も期待される。そして、健康管理には歩数が重要なデータとなる。
歩数を計測するには万歩計が良い。しかし、iPhoneは万歩計として使えない。本来は加速度センサーもあるので、決して使えないわけではないが、長時間万歩計として機能させ続けることができない。それは並行処理、マルチタスクができないためだ。
この問題を克服するには、別途iPhoneに接続可能な万歩計を開発してDocに接続すればよい。このような万歩計がいつかは販売されるだろう。
ちなみにDSに接続できる万歩計はすでに販売されている。赤外線でDSにデータを送信するようだ。iPhoneでもWiFiで通信することはできるかもしれない。WiFi機能付きの万歩計なら可能だ。しかし、それはかなり高いものになるだろう。

Googleカレンダーで年表を

Google Earthには過去の地図を表示する昨日がある。しかし、過去を表示するならカレンダーの方が適している。カレンダーに歴史的なイベントの起きた日時まで記録し、公開すれば便利な資料になるだろう。
総合学習の課題に良いかもしれない。

2010年3月23日火曜日

BloggerのFTPサポート停止

いくつかブログのページを作成し、1つをFTPで運営していた。しかし、BloggerのFTPサポートがなくなることで、そのブログを削除することにした。今はもう使っていなかったので、削除してもよかったのだが、今後は問題になりそうだ。
というのは、FTPには明確な利点があるからだ。サポートが大変だからFTPをやめたようだが、それに代わる新機能の提案はない。この問題を未解決にしておくことは、ビジネス層の取り込みも抜け穴ができることになる。
その機能とは、コンテンツのアクセス権の制限だ。Blogger自体では公開しかできないが、特定のグループに対してブログを公開したいことがある。このような機能がBloggerにはない。そのため、FTPで別のサイトに送り、そこで.htaccessで制限を加えていた。このようなことができなくなるのは痛い。
しかし、これは初心者向けの機能ではないので、代替機能があれば問題ない。Google Docsでも不可能ではないが、やはり目的がずれているように思える。ブログはブログとして、完結していてほしい。

Objective Cは第二のCobolとなるか

iPhoneアプリが増えている。iPhoneアプリの開発にはObjective Cというあまり一般的でない言語が使用されている。iPhone 自体はかなり長い期間生き続けると思われるが、Objective Cが足を引っ張る可能性がある。実をいえば今でも足を引っ張っていると言えなくもない。なぜなら、明らかに開発のハードルが高いからだ。
しかし、今はその高さもiPhoneの魅力のおかげで、乗り越えるべき試練とみなされている。開発者のモチベーションが高いので容易に克服できる。しかし、市場が円熟し、またiPhoneより高度なビジネスアプリが期待されるiPadを含めて考えると、ビジネスマンアプリの開発には大きな生涯となるだろう。大きなソフトは分業で開発され、熱意も責任感もずっと低い(と思う)。 Objective Cが書ける人を集めるのに苦労するだろうし、そもそもコード量が段違いだ。標準ライブラリがもっと充実しないと難しい。そこで、開発を容易にするため、C++に変更すると、Objective Cは負の遺産として残る。いつまでObjective Cを続けるかが、Appleの社命を握っているかもしれない。

2010年3月3日水曜日

World Wide Deduplication

ストレージの世界では重複排除によるコスト削減が話題になっている。これだけHDD/SSDが安くなっても、コスト削減圧力は決してなくならない。
重複排除の仕組みを簡単に述べれば、データをその内容を示す識別子に変えて、保存するというものだ。例えば、4KBのデータを160bitのSHA1に変換できれば、160/4096=4%に圧縮できる。同じデータが多ければ多いほど圧縮率は高まる。
このときデータとハッシュはほぼ1:1の関係になる。しかし、情報量の観点から原理的にはありえない話だ。必ずいつかは1つのハッシュに複数のデータが対応することになる。しかし、今のところかなり1:1が維持出来ている。それを検証するには非常に長い時間をかけて計算をする必要がある。
そこで仮に1:1がうまくいくとすれば、それは1つの組織の中だけで成立するものではなく、複数の組織で成立するはずだ。そこで、ハッシュとデータの対応が分かれば、それを世界中に分散して重複なく管理してもよいだろう。実際には、データを失うことは避けなければならないので複製を持つ必要があるが、少なくてもよい。このような重複排除をWWDと呼んでみた。
そのうち世界中のデータセンターにハッシュとの対応表だけを提供するサービスが始まるかもしれない。ゲノム解読のように大規模に行い、密に集約すれば、データそのものを保存する必要がなくなる。究極のインデックスサービスかもしれない。

2010年2月26日金曜日

Java RMIでAjaxを

Javaで分散計算をするときにはRMIを使うことが一般的だ。もっともRMIには様々な制約があり、使いにくいところもある。
一方で、Ajaxアプリケーションを開発するために様々なフレームワークが登場し、ますます便利になりながらもフレームワークの多すぎて混乱している。やがて淘汰されるだろうが、それには時間がかかる。また、リスクも大きい。
AjaxであるかどうかにかかわらずWebアプリの定番はJavaだ。PHPの方がもっと定番だが、あまりミッションクリティカルな用途には用いられていない。
そうなるとJavaの旧式な方法論でAjaxアプリケーションを作りたくなる。いろいろなフレームワークがあるが、Java RMIのプロトコルをそのままAjaxに変換できれば、とても都合がよい。オブジェクト指向開発論そのままにWebアプリを開発できるので、Webであることを意識する必要すらない。特に、GWSと組み合わせることができればさらによい。

2010年2月20日土曜日

MacのEclipse+Subversionでsourceforge.jpにアクセスするには

EclipseをMacで使おうとすると情報が少ないことに驚かされる。EclipseはJavaプログラミングが中心だとすれば、Java プログラマはWindowsユーザがほとんどだと言うことになる。Macのようにアプリケーション数で劣勢にあるOSがプラットホームに依存しないJavaを生かせないようではもったいない。しかし、実際にやってみるとMacには問題が多いことがわかった。しかし、その問題のほとんどは知識不足が原因だ。学べば改善できる。しかし、学ばなければならない時点でAppleの基本方針に反していると思うのだが。
Eclipseを導入すること自体は簡単だ。しかし、ダウンロードする時点でまよわせられる。バイナリにcarbonとcocoaがあり、どちらを選ぶかで知識が問われる。
次にEclipseを普通に使う分には問題ないが、subversionでsourceforge.jpにcommitしようとすると、エラーになることがある。まずほとんどの人がはまるだろう。
Eclipseでsubversionを使うには別途プラグインを導入する必要がある。Eclipse本体がSVNをサポートしていないこと自体が大きな問題だ。SVN用プラグインにはSubclupseとSubversiveが有る。Google で検索するとSubclipseの記事ばかり目立つので、ついついSubclipseを使ってしまいがちだが、Eclipseでは Subversiveの方が本命だ。
しかし、Subversiveでsourceforgeにアクセスすると、コミットができない。SVNを更新したり散々試行錯誤した結果、レポジトリのURLをhttpsにすればよいことが分かった。WindowsではSubclipseでhttpでも何の問題もない。OSの性ではないが、やはり整備の遅れと言わざるを得ないだろう。

自分でできる健康管理

高齢化社会の高齢者はなるべく自立する必要がある。高齢者にとって医療は重要な問題だが、なるべく病院に行かなくても済むようにする必要がある。そのためには自分で健康管理する必要がある。しかし、ダイエットのように強い意志が必要なやり方は続かないので、うまくいかない。なるべく楽に健康管理ができなければならない。
医者でなくても扱える健康器具は大きな市場だろう。昔はできなかった検査が今では自宅でできるようになってきた。それらはまだ間接的な指標に過ぎないが、それでも体調管理には役立つ。病気の早期発見には役立つ。まずはデータをとる機器を普及させ、習慣を作ることだ。次にそのデータをクラウドで診断することだ。クラウドの診断は医師ほど厳密ではないが、それでも見逃すよりよほどよい。

2010年2月12日金曜日

仮想化OSとしてのChrome OS

Chrome OSは小型Linuxだ。LinuxにできることはChrome OSでも基本的に可能だ。少し大きくなるだけのことだ。
Chrome OSを、その小ささを活かして仮想化OS、つまりドメイン0として動かすと相性が良いと思う。資源はほとんど使わないし、ゲストOSに自由を与える。
最初から、このような組み合わせで発売されるノートがないものか。

ハンバーガーの地方版

マクドナルドのテキサスバーガーやニューヨークバーガーは新機軸だ。アメリカには多くの地方版ハンバーガーがあり、食文化となっている。その多様性をそのまま商品開発に結びつけている。
すぐに思いつくのは日本でも同じような地方版を考えることだ。東京バーガー(思いつかない?)、大阪バーガー(お好み焼き入?)、名古屋バーガー(味噌カツ?)、九州バーガー(地鶏?)、北海道バーガー(チーズたっぷり?)、沖縄バーガー(黒糖味?)などができるだろう。

ScanSnapのWindowsドライバ

ScanSnapはお気に入りのスキャナーだった。過去形だ。
気に入らなくなったのは、Windows用ドライバソフトがダウンロード出来ないことがわかってからだ。
Mac用ドライバソフトはダウンロード出来るのに、Windows用ができないとはおかしな話だ。
そもそもWindows用ドライバは付属のCD-ROMに入っている。正規のユーザーならそれを使えば問題ない。私も正規ユーザだが、てっきりWindows用ドライバもMac用と同様にダウンロドできるものと思い、CD-ROMを処分してしまった。それが取り返しのつかないことだと知ったが、それこそ後の祭りというものだ。
このようなリスクのある商品は長く使う気になれない。それ以来、ScanSnapは敬遠するようにしている。

ブログからデジタルサイネージ

ブログを掲示板のように使うことがある。そのような場合、ネットで閲覧できるし、検索も容易だ。
しかし、実際には物理的な掲示板の方がよく使われる。やはり視認性がよい点がなによりだ。
ブログは検索しないと掲示の有無すらわからないという問題がある。
すべての掲示をブログでできるようにすると多くの利点がある。まず空間の利用効率がよくなる。また検索も可能となる。
しかし、同時に欠点もある。すべて電子化しなければならない。情報が多くなると視認性が悪くなる。
そこでブログをサイネージとして掲示する際、視認性のよい方法を考える。思いつくのは単純だが、Googleリーダーのようにタイトルと本文を分ける方法だ。ただし、リーダーは一過性だが、掲示の場合は何度も繰り返す必要がある。

カード払いの駐車場

駐車場を利用する際、料金が時間制になっているため、100円単位で細かくなる。大抵の駐車場では、1万円札など高額紙幣は使えないことが多い。そのような場合、支払いができなくなることがある。わざわざ両替のためにコンビニ(自販機でも高額紙幣が使えないため)までいって小物を買うようなことをしなければならない。とても面倒だ。
最初からクレジットカードで支払えるようにしてあればよい。もちろんSuicaでもよいが、クレジットの方が安心だろう。支払業務をセンターで一括して行えるようにしてあれば、面倒な手続きも必要ないだろう。企業規模によっては資金的な問題があるかもしれないが、利便性を向上させることで差別化にもつながる。

2010年2月9日火曜日

リコール問題

トヨタが大量のリコールを行っていることは国際的なニュースだ。いよいよ国内のプリウスにも飛び火している。
私自身はトヨタに乗っていないので、実際のところどの程度のトラブルなのか実感できない。しかし、プリウスのクレームは、ハイブリッド特有のものというよりABSそのものの味付けに由来しているように思える。ABSは、タイヤがロックすることによる摩擦の減少を意図的にロックを解除することで復元する技術だ。飛行機やモータースポーツでは当たり前だし、最近の車はほとんどすべてABSを導入している。
しかし、初心者にとってABSというのは油断のできないものだ。私自身はホンダに乗っているが、そのABSも時々ひやりとさせられる。同じように、凍った路面でブレーキを掛けてもなかなか止まらないからだ。ブレーキをいくら踏んでもずるずると滑っていく時には肝が冷える。ABSだから短く止まるかといえば、どうもそうではないらしいと思っている。低速の時はかえって止まらないような気がしている。
もしホンダのブレーキも同様であるなら、トヨタだけでなくホンダもリコールするだろう。逆に言えば、日本のほとんどの車はリコールしなければならないだろう。
それは大変なことだが、リコール隠しの三菱がどうなったか知らないものはいない。だから、リコールするなら、断固としてしなければならない。
今後は、逆にABSをはずすオプションが登場するかもしれない。

2010年2月3日水曜日

iTunes専用Mac

Appleの製品はiPod, iPhone, iPadのいずれもiTunesが必要になる。マシン自体はWindowsでもよいが、Macの方が親和性は当然高いだろう。
ならばiTunes専用機となるMacがあってもよいだろう。HDDを目いっぱい積んで、最低1TB、そしてフォーマットなしに容量を増やせる。そのようなデータ/メディア管理マシンがあれば、うれしい。
汎用的な操作をする必要はないので、それこそiPadに+αで実現できればよいのだが。

タグとキーワードによるファイリング

iPadもNetbookもクラウド時代の申し子と言ってよい。データはサーバに置き、必要に応じて(可能ならダウンロードせずに)使う。
しかし、一般的な作業をするとなれば、従来通りのファイル操作ができた方が汎用性が高い。CUIからGUIに移ったが、今再びCUI(Cloud UI)に移行すべきなのかもしれない。
Google Docsがファイル管理機能を強化したのは嬉しい。しかし、従来通りの(フォルダのように見える)タグによる管理だけでは不十分だ。人による分類の他に機械的な分類が欲しい。検索を使えばよいが、いうなれば「よく使う検索」だ。すなわちキーワードをそのままフォルダに見せればよい。
クラウド時代では、制限の多いUIで大量の文書から目的の文書を探す必要がある。肝心の仕事の前に、それだけでつかれてしまう。例えば、iPadのUIは優れているのかもしれないが、アプリケーションごとに画面が変わり、操作が変わると、そのたびにファイルを選択する必要が出てくる。これは仕事の効率を著しく低下させる。もっと素早く目的の文書にアクセスできる方法が必要だ。

iPad

iPadはよいと思う。少なくともiPhoneでは苦しいブラウジングも快適にできるだろう。
しかし、MacBookやNetbookに大きく劣る点はビジネス向けでないことだ。もっともiPhoneでビジネスが出来るという人には全く問題ない。
一般的にビジネスを行うには文書作成が欠かせない。ぜひMicrosoftのOffice for Macチームに期待したい。きっとOffice for iPadを出してくれるだろう。なぜなら、Microsoftには競合製品がないからだ。
次に、VGA出力が欲しい。しかし、これはI/Fに固執するAppleには期待できない。おそらくプロジェクターの方がWiFiに対応しなければならないだろう。ぜひiPadでプレゼンテーションをしたいものだ。

と書いてからiPadのキーノートを見たらどうやらプレゼンはできるらしい。iWorkを使うのは妥協できる。しかし、どうやってプロジェクタとつなげるのかよくわからなかった。みたところ、それらしいI/Fはなさそうなのだが。

2010年2月2日火曜日

携帯で受診時間連絡

病院では非常に長く待たされる。それが当たり前になっていて、誰も疑問を感じない。
待つのは仕方ないにしても待合い室で無意味に過ごすより、喫茶店でのんびり待っていた方がよい。重い症状の人はそれどころではないだろうが、全員が重病人という訳ではない。
そのような場合、受診間近に呼び出しをかける方法が必要になる。専用機を配布するとコストが高い。TVに移すだけでは見過ごすことがある。そこで携帯にメールしてくれるサービスが有望だ。携帯メールなら病院外へも届く。
自動受付機で、受診番号を発行する時に、パスワードも発行する。携帯でサイトにアクセスし、受診番号とパスワードで認証し、メールアドレスを入力する。必要のない人は何もしなくてよい。

2010年1月28日木曜日

Netwalker

SharpのNetwalkerはブラウジングに特化したモバイル端末だ。電子辞書と同サイズでありながら、一般的なOSがインストールされている。かつてのZaurusが蘇ったようだ。
iPhoneなどのスマートフォンと異なる点は、広い画面とフルキーボード、その代償としての重さと大きさ、そして汎用OSが動くことによる汎用性と拡張性だ。OSはUbuntuであり、そのアプリケーションを利用できる。例えばOpenOfficeがインストールされている。もちろん3Gで通話できない。
ネットブックとの違いは、CPU、OSだ。CPUはAtomでなくArmだ。OSもWindowsでなく、Ubuntu Linuxだ。そのため、Netwalkerにはネットブックほどの機能や便利さ、アプリケーションはない。
つまりはスマートフォンあるいはPDAとネットブックの中間に位置する製品だ。PDAより広い画面、つまりPCと同等の画面でPCと同じブラウザを使える。ただしOSの違いからできないことも多い。また、ネットブックより小さく軽いので、持ち運びが楽だ。
かつてのZaurusはOSこそ汎用であったが、ブラウザもOfficeもPCとは大きく異なっていた。画面も小さかった。ZaurusはPDAに分類されていた。今、Netwalkerが新たなカテゴリを提案している。
実際、このカテゴリはこれから有望だ。Google Chrome OSが狙うカテゴリとも一致する。ただしChrome OSの方がネットワークに対する依存度が高い。
Netwalkerは確かにiPhoneよりブラウジングに適している。不完全ながらFlashが使える点も大きい。NetwalkerのFlashはバージョン8だ。
しかし、少し使っただけだが、問題点も見えてきた。以降は長所と短所を織り交ぜながらコメントする。
マウス代わりのOptical Pointはスムーズに使える。トラックボールが機械式マウスを逆さにしたのと同様に、Optical Pointは光学式マウスを逆さにしたようなものだ。Netwalkerは画面が広ためポイントするには高い精度が必要になる。これにはぎりぎり合格といったところだ。ウィンドウを閉じる時に神経を使う。秀逸なのは、位置決めとスクロールの2つのモードがあることだ。しかも、このモードをボタン1つで切り替えることができる。
画面はタッチパネルになっているが、ほとんど使っていない。解像度が高くて指で押せないからだ。付属のスタイラスペンで指せばよいのだが、本体に収納できないので、持ち運ばない。
バッテリは折り曲げ部分に位置するので、重量配分もそこに集中している。両手で持って使う時にキーボードの両端をつかむと、バッテリの重みを意識する。ポインタはキーボード上部に位置し、両手の親指で操作する。その状態では人差し指がバッテリ下を支えるので、きちんと保持できる。問題はキーボードをタイプする時だ。広いピッチのキーボードといえば使いやすいように思えるかもしれないが、広すぎて親指だけではカバーできない。片手を離す度に、重量バランスがくずれる。要するに両手で持つには申し分ない重さだが、片手で持つには重い。さらにキーを両手で同時に押さなければならないこともある。そのような場合、液晶側から落ちそうになる。要はバッテリから手を離すとバランスが悪いのだ。
個人的には、キーボードは親指が届くところに集中していた方がよいと思う。無意味にキーが大きいと感じる。キーとキーの間隔をきちんと開けることで押し間違いをなくすようにしていればよい。本体のサイズにキーボードのサイズを合わせる必要はない。むしろ、キーの組み合わせを減らすためにキーの数を増やした方がよい。
例えば、ウィンドウを切り替えたり、アイコン化したり、閉じたりするキーが欲しい。これらをOptical Pointで行うのはいささか細やかな作業になるからだ。
アプリケーションの起動には若干時間がかかる。間違って2回起動してしまいそうだ。Chrome OSの起動時間にも匹敵する。これはCPUが非力なせいだろう。駆動時間との兼ね合いもあるが、もう少しパワーが欲しい。
実際Eclipseを動かそうと試みたが、うまくいかなかった。フリーズしたようなので再起動せざるを得なかった。完全なUbuntu PCにはならない。

2010年1月27日水曜日

Google SpreadsheetをODBC/JDBCから使いたい

ODBCを使ってAccess/Excelのデータをアクセスするというのは、Officeの基本的な使い方の1つといってもよいだろう。年賀状の印刷でも、このテクニックは必須だ。
Google DocsにはAccessに相当するデータベースはないが、Spreadsheetがあり、これで十分だ。しかし、Spreadsheetとしてオフラインのアプリケーションからも使えるようになって欲しい。別にGearsで動作して欲しいという意味ではなく(もちろんその方がよいが)、オンラインの状態で使えればよい。
ODBCからSpreadsheetを使えるなら、データをクラウドへ移すことができる。マクロを含むWordを、そのままDocsに保管し、必要に応じてダウンロードして使えばよい。
ODBCからSpreadsheetが使えるなら、JDBCでも使えるようにして欲しい。両方共ドライバを用意するだけでよい。

ニフティクラウド

ニフティがクラウドを始めたようだ。Amazon EC2タイプのクラウドだが、EC2の欠点を補う工夫がなされている。
仮想マシン自体はEC2より貧弱だ。メモリは512MB、ディスクは30GBしかない。EC2の1GB、160GBに比べるとかなり小さい。しかし、実用上の問題はないだろう。
料金は1時間あたり12.6円/hとのことだが、円高の今ではEC2より高い。なぜ10円にできなかったのか。しかし、月額料金や待機状態料金5.25円/hも容易されている。待機状態でも課金されるということは、待機状態のまま残しておけるということだ。EC2ではS3に保存するが、これには別途課金される。サービスが統合されているともいえる。
トラフィックには15.75円/GB課金される。価格が高いのはCPUよりネットワークがネックだということだろう。トラフィック課金がなければ、クラウドはホスティングサービスとしても最高のものになる。しかし、残念ながら現状ではコスト的にはホスティングサービスの方が有利だ。なお、通信性能に関しては、利用者が日本企業なら、欧米のデータセンターを使用するEC2より応答が早いかもしれない。
サーバOSは代表的なものを揃えているが、Windows Serverをサポートしているなら日本語版もあるとよいと思う。おそらく主な市場は日本だろうから、日本語版のサポートは当然だろう。もっともサーバOSで言語に依存することは少ないとは思う。特にShift JIS問題があるので、日本語版は鬼門かもしれない。
また支払い方法も請求書払いなのがよい。故人が支払うならクレジットでよいが、仕事で支払うなら請求書でないと都合が悪い。
次のステップは、さらなるサーバOSのサポートと、そのカスタマイズだろう。

2010年1月23日土曜日

Google Docsの保存形式

Google Docsでどんなファイルでも保存できるようになった。
これによって従来のファイル形式との非互換性が問題になる。
つまり、.docファイルは変換されるが、そうでないワープロファイルは変換されず保存される。閲覧はできないが倉庫としては役立つ。
逆にいえば、.docファイルは正確に保管することができない。
この矛盾を解消するようなオプションが欲しい。
一番簡単な解決方法は常にzipに圧縮して保管することだ。

後で気づいたが、ちゃんとオプションが存在した。最初からあったか?
気づかなかったので、よくわからないが、これで安心してストレージとして使用できる。
しかも、単にファイルが有るとわかるだけでなく、プレビューを見ることができる。これはPDFファイルに変換されて見えるようだ。PDFと同じように操作できる。

2010年1月21日木曜日

Modular Data Centerのコア数

Modular Data Center(MDC)は、コンテナ型データセンターともいわれる。現在モジュールとして最も注目されているのがコンテナだからだ。
このコンテナは一般的に20フィートの大きさがある。40Uのラックが15個格納できるらしい。これが平均的なMDCの仕様のようだ。
これからMDCの計算パワーを算出してみよう。本当の計算パワーはCPUに依存するが、ここではコア数を求めることにする。
古典的なサーバは1Uあたり1台なので、40Uなら40台になる。ここではUPSなど一切無視だ。
しかし、ブレードサーバを使えば、もう少し集積度を上げることができる。代表的なブレードサーバでは7Uあたり14ブレードだ。40Uの中35Uをブレードサーバにすれば、70ブレードまで実装できる。ここではブロードの発熱量など一切無視だ。
残りの5UはUPSや従来型サーバが入るだろう。これらは端数として無視する。
すると、70 blades/rack * 15 rack = 1050 bladesになる。
ブレードが将来Core i5/i7を採用すれば、ブレードあたり4コアになるので、4200 coresになる。2 CPU/bladeも珍しくはないので、8400 coresも可能かもしれない。
また、42Uラックを用いて、20 blades/3Uのブレードサーバを採用すれば、280 blades/rackになり、15ラックで4200 blades、Core i5/i7なら16800 coresだ。しかもCore i7なら並列度(スレッド数)で33600にも達する。これは20年くらい前のスパコンに匹敵する数だ。
しかし、実際にはこれほどたくさん実装することはできないだろう。最大の課題は熱交換だろう。

自治体クラウドは中途半端

霞ヶ関クラウドに対向してか、自治体クラウドの立ち上げが活発だ。しかし、自治体クラウドという発想自体が正解とは言えない。
クラウドにはパブリックとプライベートがある。個人情報を扱う自治体クラウドがパブリックとなる可能性は低い。それができるなら、住基ネットはもっとまともになっていただろう。
自治体クラウドをプライベートクラウドとして実現しても、サーバ数の削減など導入コストを削減する微々たる効果しか期待できない。もしパブリッククラウドで作ろうという思い切った決断ができていれば、もっとコストダウンできたろう。
そこで、他の自治体と経費を分担するためにシステムを提供する自治体が増えている。このような拡大は県境を超えることはまずないだろう。
しかし、県が主導で開発したクラウドを県内の市町村が利用すれば、市町村にとっては大きな節約になる。決して悪いことではない。単に中途半端なだけだ。
本来は国家レベルでクラウドを開発するのが理想だ。それに比べるとスケールメリットが小さい。しかし、このようなシステムの移行は段階的に行う方が無難でもある。その意味では方向性は間違っていない。
問題は、複数の異なるクラウドを統合する次のステップだ。かなり大掛かりなプロジェクトになりそうだ。

Google Docsの容量

Google Docsで任意のファイルを保存できるようになった。このタイミングでの、この変更は、個人的にとても嬉しい。というのは、GoogleとMicrosoftのどちらのサービスを導入するべきか、検討している最中だったからだ。実際には、Googleに決めていたのだが、MicrosoftのSkyDriveは捨てがたいサービスだった。しかし、この変更でGoogle Docsが遜色ないことが示された。しかも、ファイルシステムのモデルとしてはGoogle Docsの方が優れている。なぜなら、効率良く共有できるからだ。
同時にGoogle Docsの容量もわかるようになった。10GBらしい。私はすでに4GBを使っている。
SkyDriveの25GBに比べると見劣りするが、容量は将来的に増えるだろう。半分以下の容量だが、システムとしては優っていると思う。
今後はMicrosoftにもがんばってもらいたい。Microsoftの問題点は、不必要に装飾された画面デザインだろう。それが無駄になっているだけでなく、欠点にもなっている。ユーザ経験は大切だが、ネットブックには合わない。

2010年1月18日月曜日

デジタルフォトフレームでPowerPointを

デジタルフォトフレームは小さく完結したプレゼンテーションツールとなる。
この方向での進化を考えると、PowerPointの再生が必須となる。単にPowerPointをイメージに変換して表示するのではなく、アニメーションを再生できる必要がある。

キーバリュー型データストア

Webアプリは3階層モデルと言われるが、最後尾にはデータストア層がある。
データを保存するにはRDBMSを使うのが常識であった。実際、小規模なWikiなどを除くと例外なくRDBMSが使われている。しかし、RDBMSにはスケールの限界がある。
それを克服するため、近年キーバリュー型データストア(KVS)が注目されている。しかし、KVSへ移行するには、ある程度の開発ノウハウが必要だ。例えば、データモデリングが異なる。原則として主キーのみによる検索が主体となる。結合はプログラムで補う必要がある。直列化のオーバーヘッドもある。ただし、SQLでも直列化は必要なのでORMで隠蔽できるだろう。ORMでRDBMSとKVSを隠蔽するのは今後重要な方法論になるだろう。
移行をスムーズに行うには段階的に行うべきだ。つまり、本当に必要なところから進めるべきだ。
まず性能を向上するにはKVSベースのキャッシュを用いる。これによりRDBからKVSへの変換が促される。
次に永続的なKVSを保存する。しかし、一部に留める。トランザクションなどはRDBMSに任せる。それでも性能的に不十分であれば、いよいよすべてをKVSに移す。

2010年1月14日木曜日

クラウドでファイルはどこに

クラウドではファイルはオンラインストレージに保存される。
一方、クラウドではアプリケーションがWebアプリになる。
これらは、すべてをブラウザで処理するGoogleの戦略に沿っているように見えるが、少し問題がある。
Webアプリがオンラインストレージのファイルを認識するのは、かなり難しいということだ。
コピーなら簡単だが、その場合はダウンロードしてからアップロードしなければならない。
この問題を解決するには、Chrome OSにオンラインストレージをファイル参照できる機能が必要だと思う。

2010年1月13日水曜日

Google Docsがオンラインストレージに

ようやくなるらしい。
しかし、SkyDriveは25GBまで無料なのに、たった1GBとは何のためのストレージなのだろう。
Android携帯用microSDメモリの代わりでも2GBは欲しいところだ。
Googleは、検索できない情報に関してはかなりケチだ。ある意味では、きちんとビジネスをしているともいえる。もっとも、この1GBは検索もできるらしいし、ファイルサイズは250MBまでOKとのことなので、SkyDriveを超えている部分もある。
この1GBという容量はGAEと一致していることから、内部的にGAEを用いている可能性もある。

2010年1月12日火曜日

調査捕鯨への国家支援

調査捕鯨を続けるなら、民間レベルでは難しい時代になってきた。
反捕鯨団体の活動はエスカレートし、もはやテロあるいは海賊行為に近い。
しかも、提訴など法的活動も活発だ。
このような中で民間レベルで調査捕鯨を続けるのは極めて困難と言わざるを得ない。
続けるなら国レベルで支援を行う必要があるだろう。
個人的には反捕鯨団体の主張には理がないと思う。しかし、すでに理(科学)の問題ではなく、感情論ないし経済論の問題となっている。
これからは経済論として調査捕鯨の必要性を議論する段階だろう。

日本語Windowsの文字コード問題の解決法

WindowsがSJISを用いていることが、ガラパゴスを生んでいる。
日本語Windowsでは、APIレベルでSJISのファイル名を用いているが、内部的にはUTF-16である。しかし、日本語Windows意外ではAPIレベルでUTF-8のファイル名が使われており、日本だけが特殊なアプリケーションを開発する必要がある。
これを解決する手法として、UTF-8文字コードのファイルシステムを別途提供することが考えられる。特に、1つのファイルシステムをSJISとUTF-8の2つの異なるビューとして共有する仮想ファイルシステムが必要だ。
このような仕組みを用意した上で、新しいOSではUTF-8を基本としたファイルシステムへ変更すべきだ。過去の資産は仮想ファイルシステムを経由して取得できればよい。
Windows 7の次のOSでは、このような仮想ファイルシステムの提供が必須だろう。そして、次の次では、仮想ファイルシステムをレガシーとして排除する。これにより日本語Windowsも世界標準の仲間入りできる。その結果、日本独自部分がなくなり、開発コストも大幅に削減できるだろう。

2010年1月5日火曜日

箱根駅伝

東洋大V2おめでとう。
予定通りの勝利とはいえ、勝負の世界で予定通りにできたこと自体が努力と実力の証明だろう。
勝因は、5区の快走はもちろんだが、それだけではない。平均して早かったという点が非常に重要だ。聞けば全員10位以内だという。
1区5位、2区10位、3区10位、4区4位、5区1位
6区9位、7区1位、8区2位、9区10位、10区7位
この順位はそのまま来年の課題を示している。
往路では、花の2区で離されないことだ。しかし、柏原を起用するのはよくない。8区と3区を入れ替える方がよいだろう。ただし、そうすると遅い復路がなおさら遅くなる。
まず復路でも優勝を目指せる走りが必要だ。注目は6区だと思う。爪が割れても走り続けたのはさすがだが、爪を割らない準備が必要だ。下りの高速区間では差が出やすいので、差を詰められないこと、できれば広げることが重要だ。来年は下りも楽しみだ。
スカウトとしては、一番欲しいのは平地で速い人材だろう。
もう一つの不安材料は競技規則の変更だ。柏原の走りが目立つだけに、5区が短縮されるかもしれない。その場合往路の記録は落ちるだろう。

2010年1月4日月曜日

PCのリニューアルサービス

PCを買い換えるとデータや環境の移行が課題となる。
クラウドならデータもアプリも外にあるので移行は楽だが、オンラインでなければならない。日本のようなモバイル天国でも常にオンラインであることは難しい。少なくても飛行機の中では全く使えない。
やはりキャッシュのようにオフラインでも使える仕組みが必要だ。
そうなるとPCを買い換えるとき環境を移す作業から逃れることはできない。
PCの環境は、周辺機器、OS、アプリが重要だ。これらを簡単に移動させるための仮想化技術が必要となる。
周辺機器で重要なのはデバイスドライバだ。しかも、古いOSの古いドライバを使うのではなく、自動的に最新版と置き換える必要がある。この場合、必ずしも同じ仕様とは限らない。環境のコピーではなく、進歩でなければならない。
OSは、そのまま受け入れざるを得ない。ただし、OSのエディションと互換性を考慮する必要がある。サーバとして使うのにホームエディションは不適切だろう。また、今まで利用していたアプリが動作するかどうかのチェックも必要だ。動かないアプリを動かすには仮想化が必要だ。
アプリを簡単に移動させるには、常日頃からUSBで仕事をしておくことだ。USBで持ち運べるようにしてあれば、PCが変わっても仕事の仕方は変わらない。ただし、この方法は常に最善でない次善の手段を選択する方法であり、あまり効率よくない。PCをしょっちゅう変える場合に有効だ。
PCを販売するメーカーは、PCを下取りし、その環境を移行するところまでサービスとして行うべきだ。これにより安いネットブックでも高いサービス料金を課金できる

2010年1月1日金曜日

SkyDrive Explorer

このようなソフトが欲しかった。
SkyDrive ExplorerはSkyDriveをネットワークドライブとして利用できるようにしてくれる。これでSkyDriveの最大の欠点だった、複数ファイルのダウンロードが可能となった。
しかし、性能はかなり遅い。その原因はSkyDrive自身にあるので、やむを得ない。
このソフトによって、逆にSkyDriveをクラウドとして使う場合の便利さと不便さの両方が実感できた。今後は、Microsoft自身がSkyDriveを改善してくれる事を願いたい。

省エネ型天蓋付きベッド

すべて小さいほど省エネには有利となる。
一部屋全体を温めるエアコン暖房より、布団の中だけ温める電気毛布の方が省エネになる。しかし、完全に寝ているときなら電気毛布でもよいが、寝入りと寝起きの際には少々寒い。
そのような時はベッドの周りだけでも暖かいとうれしい。寝ながら読書をしたりするには最適だ。
ベッドの周りだけ温めるには、ベッドの周りを囲んでしまうのがよい。すなわち天蓋付きベッドだ。
ただし、この場合の天蓋はベッドとは別であり、ベッドに後から付け足す組み立て式の家具である。通常の天蓋は天井+カーテンだが、省エネ型では厚手の長めのカーテンでしっかりカバーする。
このような天蓋はもう少し見直されてもよいように思える。省エネを目的としなくてもプチセレブの雰囲気を味わえる。

インストールマニアックスの課題

インストールマニアックスは、Windows Server+IISにどれだけ多くのWebアプリをインストールできるかを競う大会だ。プログラミングコンテストのように特殊なプログラミング技能を必要としない分、多くの人が参加しやすい大会だ。しかし、プログラミング技能は必要ないが、計算機管理の知識は必要になる。情報処理技術者の技能としては、それぞれレベル2,1に分類されるため、やはり一般向けであることは確かだ。
今回のインストールマニアックスではHyper-Vが必須となった。ただし、これは無理やり課されたルールだ。なぜなら、Webアプリとは全く関係ないからだ。
しかし、Hyper-Vのインストールにはかなり問題がある。Hyper-Vを稼働させるには、サーバ本体の他に管理PCを必要とする。サーバ自身はインストールマニアックス事務局から配布されるので問題ないが、管理PCは自前で入手する必要がある。
どんなPCでも管理PCになるならよいが、Vista/7 Homeより上のエディションでなければならない。このようなPCの入手はすぐにはできない。Vistaはそもそも敬遠されているし、7にしてもネットブックならHomeだろう。よって、条件を満たせず、最初のハードルをクリアできない参加者が続出するように思える。
このレギュレーションには疑問を持たざるを得ない。

2009年総括

本当なら重大ニュースでも論じるところだが、ここではこのブログで兼ねてから課題にしていたことが確認できたので、そのことをまずまとめておきたい。
年々、ブログの記事が減っている。自分では、アイデアを思いつかなくなったわけでも、その量が減ったわけでもないと思っている。しかし、記事が減っている現実を見ると、思いついたアイデアをブログに公開することが少なくなったのは明らかだ。この問題を解決しておかないと、今年も減り続ける可能性がある。
元々は一日一アイデアを目安にしていたので、初年度のように500件近く書くのは多すぎではあった。しかし、アイデアマラソンではもっと多くアイデアを出すので、本来は初年度のペースが理想なのかもしれない。ただし、アイデアにはバリエーションを持たせることができるので、細かなバリエーションを考えれば、記事をバリエーションに分割して量を増やすことはできる。しかし、あまり意味のあることではない。異なる時間に思いついたバリエーションが別の記事になるのはやむを得ないとしても、なるべく1つの記事でまとめたほうがよい。
まず、アイデアを考える時間が減っていることは確かだ。今まで、自宅に帰ってから記事をまとめていたが、最近では子供の世話と自分の体力の衰えから自宅で仕事ができなくなっている。
さらに、仕事の量も増えている。ブログはあくまでも余暇なので、余暇に当てる時間が減っている。
つまり、今まで以上に限られた時間を有効に活用しなければならない段階へ入ってきているということだ。
新たな仕事の効率化方法を身につけないと、もはやこの問題は解決できなくなっているということを認めざるを得ない。残念ながら、まだその方法は見つかっていない。それを見つけることが今年の目標になるだろう。
しかし、効率は所詮100%が上限であり、それを超えることはできない。また、仕事は0時間で終わることもない。よって、効率だけでは解決しない。
したがって、収入に関係しない仕事を減らすことが次のステップになるだろう。仕事をしないのではなく、圧縮したり、任せたりする。

種の境界

これはあくまで素人の素朴な疑問に過ぎない。
来年は虎年だ。虎は大きな猫であり、同じ猫科のライオンとは子をなすこともできる。しかし、多分、一代限りであろう。よって虎とライオンが同じ種とはいえない訳だ。このように普通は遺伝的交配が可能かどうかによって種を定義する。
ここまでは素人にも納得できる。
しかし、遺伝的交配以前に体の大きさが余りにも違ってくると、物理的に交配できないだろう。もちろん地理的距離もある。生物学的に交配可能でもその他の条件で交配の機会がなくなると、もっと早い段階で種は別れ始める。
生物学の種の定義は医者の診断のように確実なものであるが故に種の境界のかなり内側を囲っているのだと思う。
人間が距離と時間を克服するまでの間、一つの種として維持できていたことは奇跡かもしれない。あるいは、技術の進化は生物学的進化と比べようもない程早いこと、またどんな時代でも歴史が示すように戦争や通商による交流が耐えなかったことなどの証かもしれない。
ちなみに、なぜ技術の進化の方が生物学的進化より早いかと言えば、戦略が異なるからである。前者はある種の偏った目的を持った最適化だが、後者は生存そのものを目的とする。また、前者ではエリート戦略などが活用される。
奇跡という大げさな表現をしたが、おそらく確率的には必然の結果だろう。進化の時間スケールはあまりにも大きいのでちょっとした文明の栄枯衰退は種の活動の一部に過ぎないのだから。

博士学生の就職

一般的に大学院には二つの課程がある。修士課程と博士課程だ。
修士課程と博士課程は大きく異なる。修士課程までは学部も含めて独自基準で評価される。しばしば、その評価はいい加減で甘くなる。それでも一定の成果は認められるために修士号を受ける資格はあるのだが、博士の基準に比べると大きな差がある。博士課程では学外の基準で評価される。その評価にばらつきがないとはいえないし、実際かなりあるが、それでも極めて公正かつ厳密に評価された結果であることは誇れるものである。大学は外部基準を時代に合わせて選択するだけだ。
多くの理系大学院では査読付き論文誌への採録を基準として採用している。この基準は厳しいと言えば厳しいが、甘いと言えば甘い。厳しい理由は、査読では非常に細かな点までチェックされ、少しでもおかしなことがあると落とされるからだ。決して間違ったことが書けないのはよいとして、思い切ったことも書けない。予測を書いてしまうと、証明が済むまで落とされるからだ。甘い理由は、そのような不自由さがあっても、ある程度コツを飲み込めば、論文を書くことはそれほど難しいことではなく、それ故論文を一つ書くだけなら余り手間ではないからだ。よって、最近では基準も二本以上しかも英文へと変化しつつある。
最近では博士課程を修了したポスドクの就職が問題となっている。ポスドクは、日本でもっとも優秀な人たちといってもよい。まだ、権威こそないが、実質的に研究を行っている人々であり、分野を限れば指導教員より深く理解している。このような人々の能力を十分に活用できず、また報いることができないようでは、日本の科学・技術が廃れてしまう。
ポスドクの就職がよくない原因は、大学や研究所を拡大できなくなっているからだ。大学は少子化のため、企業の研究所は企業本体の業績悪化のためだ。業績のよい企業の研究所は人を増やしているが、ここにもミスマッチがある。
博士号を取得するには、学部から数えて9年を要する。つまり、9年前の予想で進路を選択している人が多く、しかもその優秀さは専門性が強すぎる。よって、ワーキングプアを覚悟してテーマを貫徹するか、専門性を放棄して柔軟になるしかない。個人レベルで博士課程の学生ができることは、かなり限られる。どちらを選択すべきかは個人の自由だ。しかし、ポスドク問題を解決しようという方策の大半はワーキングプアを目指すものだ。
例えば、研究助手としての職を増やす方策では、雇用する大学には都合がよいが、将来の保障を確約できるものではない。社会的な成功者として認知されない。研究助手から教授へ昇格できるものは、ごく一部に過ぎない。これは国家公務員の競争より酷い。ポスドクは生きるために天下りしなければならない。
純粋な科学者を目指すものならそれでもよいかもしれないが、世の中の多くの研究者は経済的な成功も目指している。そのような人たちは、今のテーマを活かしながら次のテーマへ移っていくべきだ。そもそも長い一生に比べて、テーマを選択する時期は短い。一生かけるテーマを見つけたら、それを追求してもよいが、若手のうちに追求してもなかなか成果はでない。もう少し段階的に計画的に研究するべきだ。
よって、博士は優秀な能力を活用できる場所を自分で探すべきだ。博士課程の学生はあまり就職活動をしたことがないかもしれない。しかし、これからはそうはいかない。課程が変わるときに、今から5年後を予想し、人が不足する分野へ乗り替えるべきだ。これは専攻を変えるという意味でもよいが、テーマを変えるということでもよい。テーマを変えることは時間的な不利を招くが、将来就職できないよりずっとよい。具体的には、純粋科学から応用科学へ移ることだ。

苺のチョコレートケーキ

子供が幼稚園でクリスマスプレゼントに何が欲しいかと聞かれて、苺のチョコレートケーキと答えていた。他の子はおもちゃが多いのに、食べ物だとは、いかにも食いしん坊らしい。また、まだ金銭感覚のない子供らしい願いだとも思った。かわいい願いなので、叶えてやろうと詳しく聞くと、苺のチョコレートケーキとは、チョコレートケーキの上に苺が乗った一般的なものではなく、チョコレートが苺味のケーキなのだそうだ。さすがに、そのようなケーキは聞いたことがない。
探しても見つからなかったので、現物をいろいろ見せながら誘導していくと、最終的にはおいしいケーキなら何でもよいらしい。それで一安心していたところ、ちょうどクリスマスにインフルエンザになってしまった。子供には「いい子にしていればサンタさんが後でケーキを持ってきてくれるよ」といい、全員が回復するのを待つと大晦日になってしまった。
ところがいざケーキを買いにいくと、何と本物の苺のチョコレートケーキが売っていた。それは不二家の「苺ミルクのチョコレートケーキ」だ。これが子供のイメージにもっとも近い。前からあったのかもしれないが、クリスマスの時期にはなかった。ちょっとしたサンタからのプレゼントだったのかもしれない。

新型インフルエンザ

とうとう新型インフルエンザにかかってしまった。
感染源は子供の通う幼稚園らしい。実際、インフルエンザが原因の学級閉鎖が行われ、しかも我が家では子供が最初に発症した。学級閉鎖したにもかかわらず感染した理由はよくわからない。もしかしたら感染源は別にあるのかもしれない。しかし、その場合、考えられるのは私の職場くらいだ。発症の時間差も大きい。
インフルエンザの症状として特徴的だったのは発熱、頭痛や筋肉痛くらいで、タミフルを飲んで3日程安静にしていれば日常的な作業ができるくらいに回復する。新型インフルエンザは弱毒だと聞いたが、実際その通りだと実感した。
しかし、早い時期に医者にかかって薬をもらわなければ悪化する可能生が高い。似た症状があれば、すぐ病院にいくべきだ。今、私の地方、おそらく都会といってよいだろう、では検査薬が不足している。実際、私も検査なしに薬をもらった。家族全員発症していたので、必要はなかったが、最初の一人には検査が必要なので、不足は困る。タミフル自体の供給も重要だが、検査薬の供給も同じくらい重要だ。この原因は流通にある。なぜなら地方には結構余っているからだ。正確に言えば余っている地方もかなり多い。消費した分を宅急便で直ぐに補える体制ができていれば、国全体で一つの倉庫を持っておけばよい。地方自治とかで47分轄するのは間違っている。なお、実際には47分割しているわけではないと思うが、最終地点では不平等になっているのも事実だ。

仮想世界と現実世界の速度差

時間差でもなく時差でもない。あくまで速度差である。
仮想世界のコミュニケーションがあまりに円滑だと現実世界に戻った時には大きなギャップを感じる。これを速度差と表現した。まるで高速道路から一般道へ戻った時に、ついついスピードを出しすぎてしまうときのよに、2つの世界を行き来すると速度差を感じて、戸惑うことが多い。
仮想世界では、十分なコミュニケーション手段が提供されていれば、物理的な制約に依存せずに活動することができる。仮想世界での仕事の多くは文書作成である。プログラミングも一種の文書作成に違いない。これは考えを表現できればよいので、非常に速くできる。考えをまとめる時間こそが重要だ。よって、考えの訓練さえできていれば、一週間分のたまった仕事を1日でこなすのも無理がない。
それに対して、現実世界の仕事は、特定の場所に移動する必要があったり、特定の物理資源を必要としたり、仕事を行うための条件を整えるだけで時間がかかる。一日にできる打ち合わせには限りがあり、なかなか前進しない。そもそも会議は踊るものだとしてもだ。貴重な時間が浪費されることの方が多い。
よって、現実世界の仕事をどれだけ仮想世界に移行することができるかによって、仕事の効率が変わってくる。