yasuo hirose: 2011年4月 アーカイブ

　かねてより、"ＨＤＤクローン・コピィ" の作成をお勧めしてきた。
　余程、思い入れがあるのか、以下のように何度も書いて来た。(一括で表示させるには、右側のサイドバーの "検索" で「ＨＤＤクローン・コピィ」と入力するか、"カテゴリ別アーカイブ" の＜ハードウェア → ＨＤＤクローン・コピィ＞をクリックしてください。)

◆ 参照(1) ＜"HDDクローン・コピィ"の有難さは忘れた頃に訪れる？／"IDE→SATA変換アダプタ"（当日誌 2011.02.06）＞
◆ 参照(2) ＜"セレンディピティ"？／PC"起動"直後の"予定イベントキャンセル"の原因が判明！（当日誌 2010.10.19）＞
◆ 参照(3) ＜久々の"HDDクローン・コピィ"/VersionUpされたFreeの"EASEUS Partition Master"（当日誌 2010.10.04）＞
◆ 参照(4) ＜"ＨＤＤクローン・コピィ" と "変換アダプタ"（ＩＤＥ→ＳＡＴＡ変換）（当日誌 2010.03.26）＞
◆ 参照(5) ＜"ＨＤＤクローン・コピィ" 作成手順をラクにしてくれる "アダプタ"（当日誌 2010.03.10）＞
◆ 参照(6) ＜"ＨＤＤクローン・コピィ" フリーソフトに関する "体験的情報"（当日誌 2010.03.09）＞
◆ 参照(7) ＜"ＨＤＤクローン・コピィ" も "パーティション編集" もできるフリーソフト！（当日誌 2010.02.11）＞

　米アップルは何かと世間の関心を惹く。今日は、二つの報道が衆目を集めた。
　一つは、しばし延期となっていた日本での "iPad2" の発売。(参照　＜"iPad２"は薄型,軽量,カメラ付／処理速度2倍,画像表示性能9倍の新型半導体搭載（当日誌 2011.03.04）＞)
　もはや恒例(?)ともなった感がある長い待ち行列もできていたとか......。

　このところ、当ブログの "携帯向けサイト／SmartPhon向けサイト" の立ち上げやそれ向け "QRcode" の掲載......と、"携帯/SmartPhone" といった通信モバイル分野に関心が向いているかのようである。
　しかし、これは今に始まったことではない。以前から "携帯(i-mode)／SmartPhone" による便利な "ネットブラウジング＆メール機能" は、もっと徹底的に活用されて良いと考えて来た。
　ただ、ここに来て "再" 注目する理由があるとすれば、"携帯(i-mode)" の実用的機能性に加えて、"SmartPhone" には魅力的な "表示性／操作性" が加味されたからなのかもしれない。
　たとえ便利な機能であっても、その使い勝手が良いのとそうでないのとでは大きな開きがありそうだ。その点、"SmartPhone" での "表示性／操作性" は、小さな面積の通信モバイルとしての窮屈さをさほど意識させない。
　そうなると、 "いつでも／どこでも" という通信モバイルとしてのメリットが最大限活かされることとなるわけで、そこに着眼しつつ "実用的活用法" を大いに追及して良いのではないかと思う。
　しかも、ここでも、"電子書籍" 分野がそうであるように、受け身から転じて、"インディ・スピリッツ" に則って、この "実用的活用法" を "提供する側！" に回ってみてもいいのではないか......、と思うのだ。
　つまり、その "実用的活用法" を "マイ・ビジネス" などにおいて活用してみるということだ。

　システムの構築や改修で役に立つのが、いわゆる "コンポーネント" 方式だ。優れた全体システムになると、それぞれの機能が、"着脱" 可能なかたちで部品化されているものだ。そして、その部品は "コンポーネント" と呼ばれている。
　ユーザーが、使いたい機能を付け足したり、不要となった機能を取り除いたりしたい場合には、この "コンポーネント" を簡単に "着脱" するだけで済む。

　昨今では、ＰＣジャンルでも "ウィジェット／widget" と呼ばれる、まさにこの "コンポーネント" 方式が重宝がられている。

＜ウィジェット 【widget】
　パソコンのデスクトップ画面やWebブラウザのスタートページなどの中の好きな場所に表示できる単機能の小さなアプリケーションソフトのこと。「ガジェット」(gadget)と呼ばれる場合もある。
　カレンダーやメモ帳、地図、最新ニュース表示など様々なアプリケーションが開発され、公開されている。個々のウィジェットは、XMLやJavaScriptなどの簡単なソースコードで開発されており、表示するには動作環境であるウィジェットエンジンが必要となる。......＞（＜「IT用語辞典 e-Words」＞）

　昨日も書いたが、ブログのレイアウト改変のような、ちょっとした技術的手順などに関しては、しばらくその作業から離れていると、「ええーっと、どうやったっけかな......」と戸惑うことになったりする。情けないことである......。
　そして、勘が戻らぬままに作業を続けたりしていると、"お目当ての箇所" が意に沿うかたちになったかと思えば、潜んでいた "バグ" が表面化してのことなのか、「えっ？　何でこうなるの？」というような現象に遭遇したりする。
　まあ、"潜在的バグ" が陽の目を見るのだから必ずしも不幸とばかりは言えないが、それでもそのためのデバッグ作業を苦々(にがにが)しく感じることになる。

　ウェブ・スクリプトでの "潜在的バグ" と言えば、 "古いＩＥ" がブラウザ自体に抱えている不具合や未対応が原因となって "好ましくない表示" を結果するという現象もあり得る。本来は、スクリプトの "バグ" とは呼びたくないものだが、閲覧者のことを考慮すれば、"バグ" 同様に是正しなければならない。
　これらは、他のブラウザの "Firefox" や "Safari" では何ら問題とはならないスクリプトに対して、固有に "異常反応(?)" をするから厄介なのである。念のためと思って "ＩＥ" を起こしてみてはじめて判明するのであって、常用する "Firefox" での表示を鵜呑みにしていると、「知らぬが仏」ということになりかねないから要注意である。

　このブログサイト/ "AdhocBlog" は、立ち上げる際には名前のとおり "アドホック" に立ち上げ、その後は、日々のエントリーにだけ関心を集中させて来た。欲張って(?)ほかにも複数のサイトを運営しているもだから、手が回らなかったという事情も加わる。そんなものだから、ほとんど特別の "手入れ" をしないままに今日に至ってしまった。
　レイアウトやデザインはともかくとしても、ブログとしてのミニマムな機能にも無頓着であったかもしれないとやや反省している。

　別に "やましい事" がなくても、自分が保持する "携帯電話" が勝手に自分の "位置情報" を外部に発信するという事態には、注目かつ警戒すべきことなのかもしれない。"個人情報の漏えい" 問題の新たなケースとも見なせるからだ。
　下記のような、ちょっと気になるニュース報道があった。

＜携帯利用者の位置情報を収集か　グーグルとアップル
　【ニューヨーク共同】米紙ウォールストリート・ジャーナル（電子版）は２１日、米アップルの携帯電話ｉＰｈｏｎｅ（アイフォーン）と米グーグルの基本ソフト（ＯＳ）を搭載した携帯電話が、定期的に利用者の位置情報をそれぞれ両社に送っていると報じた。日本でも同様の情報が集められているかどうかは不明。
　集積したデータベースによるサービス向上が狙いとされるが、個人情報の漏えいに懸念が出そうだ。
　同紙によると、グーグルのＯＳアンドロイドを使った台湾ＨＴＣ製の携帯電話では、利用者の位置情報を１時間に数回、グーグルに送っている。＞（＜携帯利用者の位置情報を収集か　グーグルとアップル／【共同通信】／2011/04/22 12:48＞）

　とりあえず、"携帯/SmartPhone" 向け自サイトの最適化改造とでも言うべき作業が一段落した。
　あとは、しばらくこの状態の仕組みを使い続けながら様子を見てみようかと思っている。そんな中で、細かな改善点の洗い出しやら、とりあえずの表示デザインの見直しなどを順次進めて行こうかと......。
　これまでは、このブログを "iPod touch" 、"Safari" で「フルブラウザ」ベースで閲覧していても "字の細かさ" にさほど "辛い" 思いをするわけではなかった。が、今回の「iPhone テンプレート for MT」の表示を試すようになると、やはり "この位の文字サイズ" でなければスムーズな閲覧とは行かないな......、と再認識させられている。

　また、これまでは専ら「フルブラウザ」ベースしか念頭になかったため、画像サイズについてはことさら気にしてこなかった。しかし、"iPhone/iPod touch" 向け最適化システムとなると、サイズ自動調整という手もあるにはあるが、とりあえず "横幅サイズ" は "320 px" までとしなければレイアウト崩れの生じることも了解できた。こうしたことも、実際に体験してみるとにわかに実感させられるものである。

　この間、当ブログサイトの "自然な閲覧" が、各種モバイル・デバイス（携帯/iPhone/iPod touch/Android系デバイス）からも行えるよう、いわゆる "最適化" の試みを進めてきた。新規システムの作成というよりも、当ブログサイトのこれまでの累積エントリー(データ)がそのまま活用できるような "部分改造" だと言ってもよい。
　改善点その他の積み残しは多々あるとは認識しているが、その枠組み水準のかたちが取りあえずカバーできたかと安堵している。

　"スマートフォン対応" に向けの現行の "Movable Type"ブログシステムを "改造(?)" しようとしたが、先ず、第一弾は失敗に終わった。昨日の紹介で言うと、◆(2) ＜Smart Phone テンプレート for MT＞サイトの方の "テンプレート" の話である。
　失敗の原因は、当初から懸念していた "Movable Type" ブログシステムの "Version" 差異の問題だと推定している。
　前述の公開サイトには、＜MT 5＞限定対応とは明記されていなかった点が災いした。自サイトの現行 MT "Version" は＜4.1＞であり、これを立ち上げ時からそのまま継続して愛用しているからだ。
　が、ひょっとしたらという期待を抱いた。また、当テンプレート稼動の必須前提とされる＜プラグイン＞ソフトには、指定されていた＜MT 5＞向けのほかに＜MT 4＞向けの "Version" もあったものだから、これで行けたら......、と勝手な期待をしたのであった。

　昨日は、"MovableType" で構成している当ブログサイトの "携帯Version" の立ち上げについて書いた。
　その "携帯Version" のメリットは、これまでのエントリーがそのままデータベースとして活用できる点や、ＰＣでの「フルブラウザ」向け構成画面に比べればスマートフォンでもいくらかは読み易くなる点であろう。
　そんなことから、"携帯Version" はそれはそれで有効だとは思えるが、やはり関心と興味は "スマートフォン対応サイト" に向いてしまう。"表示や操作の最適化" という観点が捨てがたい、と......。

　かと言って、新規に "スマートフォン対応サイト" を構築するのも今一つ気が重いと感じたりしている。
　現行のサイト、それもブログサイト("MovableType" のブログ......)であることが望ましいわけだが、これをベースにしつつ "スマートフォン対応サイト" 化が図れないか、と虫の良いことを考えたりしているわけなのである。
　そんな動機で、ネット検索をしていたら、興味深いサイトに遭遇することになった。
　近日中に試してみようと考えているが、とりあえず、以下二つのサイトを記載。紹介しておきたい。

　"MovableType" で構成している当ブログサイトの "携帯Version" を立ち上げることにした。当ブログ画面のサイドバーに置いた "QRcode" (携帯バージョン版のURL)を携帯の "バーコード読み取り" で読み取ってもらえれば、簡単に携帯で閲覧できるはずだ。

　ＰＣ向けのサイトを "iPhone＆Android/スマートフォン対応サイト" へと最適化しようというのが当面の関心の焦点ではある。"iPhone＆Androidなどのスマートフォン" は "ePub リーダー" でありながら "ネットブラウジング" が可能なデバイスであり、"ePub 電子書籍" のダウンロード配布デバイスとしては最適である。
　しかし、"ネットブラウジング" に関しては、サイト自体がＰＣでの「フルブラウザ」向けに構成されているため、文字が小さくて読み辛い点その他で決して快適とは言えない。そのため、"iPhone＆Androidなどのスマートフォン" 向けに "最適化" される必要が生まれるわけなのである。

　"余震" が途絶えず、また頻繁に "緊急地震速報" が発せられる状況では、"緊急事態" がまさに日常化しているとさえ言えそうだ。
　そんな中で、"緊急時" に家族・友人との "連絡方法" への関心が否応なく高まっているようである。
　が、心配の種は、いざという場合に、"ケータイ" が役に立たないケースなのかもしれない。今回の東日本大震災時においても、現地の被災者をはじめとして、いわば日本中の人々が "ケータイ" の "不通" でヤキモキさせられた。

　こうした状況下で、次のような報道記事が目に留まった。

　昨日は、"自作ePub電子書籍" のダウンロード配布という観点から、"Web/Blogサイト" の整備充実が望まれるといった点について書いた。
　自分が、"自作ePub電子書籍" に対してはそこそこマメに対処しているのに対して、"Web/Blogサイト" の "お手入れ" については結構 "放ったらかし" 状態である後ろめたさが災いしたからなのか、やや焦点の合わない記述で終わった感がある。
　ところで、もし "ePub 電子書籍" と個々の "Web / Blogサイト" との "コラボレイト"／"シナジー効果" という点を強調するのであれば、もっと単刀直入な "切り口" があったことに気づいたりした。
　"iPhone＆Android／スマートフォン対応サイト" を構築してみるという試みのことである。

　"電子書籍(eBook)" は、"自作" と "自由な配布・流通" とが本命なのだろうから、やはり個人ベースの "Web / Blogサイト" から配布されたり、ダウンロードされたりすることがもっと関心を持たれていいように思う。
　現状の "eBook リーダー" の大半は、インターネットサイトへのアクセスが可能なのだから、"Store" や "マーケット" を介さずとも、直接個々の "Web / Blogサイト" からダウンロードするルートをもっと見直してもいいと思う。

　確かに、 "iTunes Store" や "Android マーケット" は品揃えも良いし、一定の "規格" での選別済みだという点から "便利かつ安全" だと言う向きもあろう。
　しかし、今一度、"紙の書籍" の過去と現状とを俯瞰するならば、その "流通機構" の存在が "重過ぎる" がゆえにさまざまな弊害が生まれたのではなかったか......。
　とすれば、"紙の書籍" からの "解放(?)" と目される "電子書籍(eBook)" が、"直接生産者(?)" の手によって配布/販売されるのではない "機構" に雪崩込むという傾向は、あまり褒められたものではないのかもしれない。
　"便利かつ安全" という "アンビエント" 環境が、"電子書籍(eBook)" の普及に当たって大いに貢献したことは否めない。が、それでいいのかなぁ、という懸念も否めない。

　"縦書き" 仕様で "青空文庫形式" を読ませる "i文庫HD"(for iPad)／"SkyBook"(for iPhone)などが、実に快適な "eBook" 読書を味わわせてくれるものだから、長らく "ePub 電子書籍" の "縦書き" 仕様にこだわったものだった。
　"青空文庫形式" は "ePub" 仕様ではないので、何とか "ePub" 仕様で "縦書き" 表示ができないものかと......。
　このブログをざっと振り返っても、"縦書き" 云々については、以下のように幾度となく書いていたのに我ながら驚く。

　Ｗｅｂページ上に置いた "ePub 電子書籍" は、その前提作業としての＜.htaccess＞ファイル設定（ 参照　◆＜Android SDK エミュレータで"自作ePub電子書籍"をダウンロード配布する試み成功（当日誌 2011.04.10）＞ ）さえしておけば、"iPhone/iPod touch" のみならず、"Android" 系スマートフォンからでも、各々のインターネットブラウザを通じて "ePub" ファイルとしてダウンロードさせることが可能である。
　その点を "実感" していただくために、以下のようなサイト環境を設えてみた。
　二つのサイトの "末尾" で、"自作ePub電子書籍" （量的比率がほぼ60％程度の "Sample" 版。）のダウンロード配布をご案内している。
　"iPhone/iPodtouch/Android" といった各種端末でダウンロードしていただくことが可能となっている。興味のある方は試してみてはどうでしょう......(ＰＣのブラウザからのダウンロードも可。)

　"Android SDK エミュレータ" の環境をわざわざ作って試したかったのは、"iPod touch/iPhone" 向けに制作した "ePub 電子書籍" が、"Android" 系のスマートフォンでも問題なく表示されて通用するのかどうかという点であった。その思惑についてはこの間も何度も書いてきた。
　先ず、"表示のされ方" 自体に変わりがないかという点がひとつであり、もうひとつは、 "画面サイズ" の点から "レイアウト" が併用し得るのかどうかという点である。

　既に、自作 "ePub 電子書籍" で "iPod touch 向け" レイアウトで制作したもの（下記の図◆３、◆４の自作 "ePub 電子書籍：『海念と保兵衛』for iPod ）に関しては、一昨日のブログで紹介したとおり、"Android SDK エミュレータ" で問題なく表示された。
　それによって、一応 "検証" できたと思われるのだが、念のためにということで、もうひとつ別の作品についても例証することにした。
　下記の図◆１、◆２の自作 "ePub 電子書籍：『かもめたちの行方』for iPod がそれである。

　自分の場合、ある事情からこの "日誌＝ブログ" は、通常の "Webページ"と"Blog システム" との双方に掲載している。
　"Webページ" とは "HTML" スクリプトで構成されたいわゆるホームページのことであり、その一角に "CGI" での "掲示板" システムを改造した、随時、コンテンツが簡略に追加できる自家製 "日誌システム" を組み込んで活用している。
　これに対して、"Blog システム" の方は、"Movable Type version 4.1" というオーソドックスな "Blog 構築システム" を活用させてもらっている。
　この "システム" は、"Blog" としての機能をかなり豊富に備えており、習熟した上で活用するならば、思いのほか充実した "Blog ライフ" をエンジョイすることも可能だ。

　これまで、"Blog システム" に着眼して来たのは、とにかくその都度 "エントリー(投稿)" したコンテンツが "所定の手続き" をしておきさえすれば、"検索され得る" ステイタスとなり、もし関心のある人がいれば目にも留まる、という点であった。
　通常の "Webページ" であると、掲載記事をいくら小まめに更新しようが、それらが "検索エンジン" で掌握されるに至るまでには多大な時間が掛かり、当該の記事が "検索され得る" ステイタスに立つことすらままならなかったりする......。
　人の目にも留まる、という点を過剰に意識することもないのだが、かと言って、公開している以上その点に無頓着でいるのも虚しい。

　果たして、"ePub 電子書籍" は "ePub" リーダーの差異を超えて適切に表示されるものであろうか？　その疑問が、"Android SDK エミュレータ" で "自作 ePub電子書籍" を表示させてみようと考えた理由であった。
　"iPod/iPhone" と "iPad" との間にある歴然とした "画面サイズ" の差異なども大いに気になるところであったため、このブログでも過去幾度となくレポートしてきた。
　しかし、"差異" を言うならば、サイズについてよりも "ＯＳ" が異なるデバイス間の
"差異" についてこそ検証する必要があった。
　ということで、アップルの "iOS" とグーグルの "Android OS" という差異を背負った "iPod / iPhone / iPad" 系と "Android" 系デバイスとの間の差異が、"ePub ファイル・電子書籍" にどう異なった対応をするのかを調べようとしたのである。

　そこで、スマートフォンサイズの "iPod touch/iPhone" 向けに制作した "自作 ePub電子書籍" を、"Android" 系スマートフォンのエミュレータである "Android SDK エミュレータ" にダウンロードして表示させた上で、その結果を吟味してみようとしたのだ。
　この間も書いてきたように、"Android" 系実機デバイスではないことによる制約（ "Android Market" からのダウンロードは不可！）があったり、ダウンロード元サイトのサーバ設定（ "ePub" を "MIME" 設定でオーソライズする！）を行う必要が生まれるなどといった伏兵も潜んでいた。
　が、とにかく下記のサンプル画像で示すとおり、予めインストールしておいた "ePub リーダー" アプリの "Copper Reader" によって、今後詳細に検証してみるに耐える高画質の表示を得ることができたのである。
　詳細はおくとして、先ず確認できる点は、"iPod touch/iPhone" 向けレイアウトで制作した "自作 ePub電子書籍" は、ほとんど再調整することもなく "Android" 系スマートフォンで適切に表示されそうだという点である。（"Android" 系実機デバイスが手元にないため、現時点、実機では未確認である）

　"Android SDK エミュレータ" を使って、自サイトに置いた "ePub電子書籍" をダウンロード配布しようという試みを、漸く "成功させる！" ことができた。
　要するに、サーバサイドのファイル・システムの一角に、 "MIME" に関する「.htaccess」ファイルといういわば「御触書(おふれがき)」のような特殊ファイルをかませること。それによって、自サイト内に置いた ".ePub" という拡張子のファイルを取り扱う際には、何はともかく "ePub ファイル" なんだ！　と心得なさい、と周知徹底させるのである。くれぐれも、怪しい者と見間違ったり、勝手に "text ファイル" や "zip ファイル" と取り違えてはなりませんぞ、と。

　おかげで、"ePub ファイル一行" としてのお墨付きがあったためか、"Android SDK エミュレータ" 側も、
「"ePub ファイル" 様のご到着ですぞ、くれぐれも粗相がないように "ダウンロード屋敷" にご案内しなさい」
とばかりの丁重な対応を返すのであった。
　この点では、昨日まで、"ePub ファイル" を "zip ファイル" としてダウンロードしていたブラウザの "InternetExplorer7" までもが、
「これはこれは、"ePub ファイル御一行" 様でございましたね。どうぞどうぞこちらへ......」
と手のひらを返すように、"ePub ファイル" と再認識しての出迎えに転じたのである。

　この間、"Android SDK エミュレータ" でトライして来た案件は、結局、「自分のWebサイトから "ePub電子書籍の配布" を可能とする"サーバ設定"の方法」という問題に収斂(しゅうれん)しそうである。
　"Mozilla Firefox" を常用ブラウザとして使って来たところから、"ePub ファイル" をダウンロード配布するということを、若干イージーに受け止めていたようだ。
　確かに、"ePub リーダー" の役割まで果たす "Mozilla Firefox" は、"ePub ファイル" に対して的確な対応をしてくれる。アドオンソフトの "ePub リーダー" ではブラウザ上で "ePub電子書籍" をほぼ問題なく閲覧させるし、また、ダウンロード保存に関しても小気味良くウィザード画面を出して "開く or 保存" のお伺いをしてくれたりもする。
　そんなものだから、自分のWebサイトにリンク形式で "ePub ファイル" を並べておきさえすれば、ユーザは直ちにダウンロードできるものと思い込んでいたわけだ。

　しかし、今回、"Android SDK エミュレータ" をダウンロードのデバイスとして試用してみたことで、"ePub ファイル" をそれとして扱い、ダウンロードさせるという手順が、これはこれとして一つの "ジョブ" なのだということに気づかされた。
　ちなみに、"Android SDK エミュレータ" でのこの点の途中経過としては、"Mozilla Firefox" のブラウザでは、しっかりと "ePub ファイル" としてダウンロードされるものが、"エミュレータ" ではダウンロードはなされるものの、何と "text ファイル" として扱われてしまうという珍事に見舞われたりしている......。

　"ePub 電子書籍" が読める "Copper Reader" をインストールした昨日の作業の流れからすれば、今日は、いよいよ "自作 ePub電子書籍" を "Android SDK エミュレータ" に転送して、フムフムとその表示具合を確認するはずであった。
　"エミュレータ" へのアプリなりコンテンツなりの転送は、昨日も書いたとおり、ブラウザを通じてのダウンロードという "隘路" しか存在しない。
　そこで、自サイトに "自作 ePub電子書籍" がダウンロードできる "仕掛け" を作り、"Android SDK エミュレータ" からアクセスしてダウンロードしようとしたのであった。
　ところが、その "自作 ePub電子書籍" を "Android SDK エミュレータ" はスンナリとはダウンロードしないのである。馬鹿げたことに、 "文字化け" だらけの "テキストとして開く" という "無作法" をやってしまうのであった。

　"Android SDK エミュレータ" で "ePub 電子書籍" を読むとどんな感触であるのかを確認する "お膳立て" をようやく達成することができた。
　昨日も書いたように、今自分が試みていることは、"Android" のデバイスが、スマートフォンや電子端末ではなくて、とりあえず立ち上げた "Android SDK エミュレータ" という特殊環境での試行錯誤なのである。
　"iPod / iPhone / iPad" での作業では、"iTunes" を通じてホイホイ、スイスイとコンテンツを同期(転送)させていたのに対して、この環境では何とも "転送インターフェイス" がぎこちないのである。問題点はひとえに次の点にあった。

＜ただ、残念なことにエミュレーター用の実行イメージには、Android Marketへのアイコンが含まれていない。このため、Android Marketで配布されているアプリケーションをダウンロードしてインストールすることはできない。＞（＜ASCII.jp：端末は無くとも、Androidのエミュレーターは動かせる！＞）

　いわゆる "アプリ" やコンテンツの転送のルートは、"Android Marketで配布されているアプリケーション" 以外の、在野のサイトから "apk ファイル" を探し出し、これらをインターネットからダウンロードする以外にないのである。
　当初、"ePub" に対応しているとされる "Android向け電子書籍リーダー Copper Reader" に目を付けていた。これを何らかの形でダウンロード & インストールができるならば、かなりの "前進" となるに違いない......、と。
　しかし、この " Copper Reader" というアプリは、公式の "Android Market" に登録されていて、たとえＰＣからそのサイトに入ってダウンロードを試みても "Android デバイスが見つかりません" と警告を受けて不可なのであった。
　もはやお手上げ状態かとあきらめかけたものだった。で、しかたなく、 "Copper Reader" のベンダーサイトを覗くことにした。以下のような解説がなされている。

　昨日立ち上げた "Android SDK エミュレータ" を早速使いこなそうとあれこれ試行錯誤をしてみた。
　関心を向けている点は、"iPod / iPhone / iPad" 向けでこの間行って来た "ePub 電子書籍" 制作に関する種々の経験ノウハウが、"Android" 系の "携帯・端末" 向けの場合には、何が共通していてどこがどう異なるのか、またどんな伏兵が潜んでいるのか、そうした点を調べることである。"ePub" 仕様は、"汎用性" が目指されているため、共通する面が少なくないはずだとの読みはしているものの、やはり実体験的な確認が欠かせない。

　それはそうと、先ずは "Android" 系の "携帯・端末" に馴染んでみなければ何も始まらない。しかも、その "実機" が手元にあるわけではないために、ＰＣ上での "Android SDK エミュレータ" を代用しようと事を始めたわけなのである。
　それにしても、この "エミュレータ" はその動作がかなり "重く" て扱い辛い......。まさか、スマートフォンに適用されている "Android" システム自体がそうした性格なのだとは思えないが、それにしても "重い" ......。
　日頃常用しているノートＰＣは、"CPU 1.79 GHz、 2.62 GB RAM" であり、ちょっとした開発作業であってもさほど苦にしていない。だが、この "エミュレータ" を動かしてみると、たっぷりとストレスを感じさせられたのだ。"メモリ" の "割り当て" 設定がどこかにあるのかもしれないが、今のところ了解していないので、その動きのたどたどしさ、纏わり付くような動きには閉口させられた。
　そこで、思い切って、やや性能の良いＰＣ（ "CPU 3.00 GHz 1.99 GB RAM" ）環境へとこの "エミュレータ" を移動させなければならなかった。幸い、こちらの環境では、サクサクとまでは行かないまでも、ようやく順当な操作が可能となったのである。

　と言っても、未だ正体が分からないにもかかわらず、"アンドロイド携帯" を "買っちゃえ！" というほどせっかちな人は先ずいないだろう。

　そこで、ちょいと気の利いたユーザーならば携帯などには "エミュレータ" というＰＣ上で "疑似デバイス" として動くシミュレータなるものがあることに目を向ける。

　現に、"アンドロイド携帯" には "Android SDK エミュレータ" というものが用意されている。
　そこで、"アンドロイド携帯" への好奇心が向かった先は、この "Android SDK エミュレータ" をＰＣ上で実行してみるということであった。

　＜鈴木貴博の「舞台裏から分析！流行のメカニズム」 アンドロイド普及ツールになりかけている「iPod touch」/NIKKEI TRENDY NET/2011年03月28日＞という記事は、"携帯端末" 市場動向の状況における "微妙な皮肉(?)" を、興味深く紹介するものとしておもしろく読ませてくれた。

　個人的に言っても、かねてより "iPod touch" には人一倍関心を寄せ興味津々で愛用して来た。それでいて "携帯電話" の方は相変わらず "ドコモのユーザー" に旧態依然として留まっていた自分としては、「フーン、ナルホドねぇ......」という "微妙な心境" にもなっているのである。

　"iPod touch" が気に入っているのなら、 "携帯電話" の方も速やかに "iPhone" のユーザーに移行すればいいじゃないか......。それが、"iPod touch" を "iPhoneの補助輪" つまり、 "iPhone" ユーザーへの "橋渡し役" と豪語したスティーブ・ジョブズによる「補助輪」論の "教え(?)" のはずであっただろう。

＜外見はiPhoneとよく似ていて、最新の第4世代は（1）電話がない、（2）GPSがないということ以外はほぼiPhoneと同じことができる。つまり、音楽やビデオクリップ、写真や動画撮影を楽しめるだけでなく、iPhoneアプリをダウンロードしたり、ゲームしたり、電子書籍を読んだり、無線 LAN経由でインターネットにつながったり、メールをチェックしたりと、およそスマートフォンユーザーがやりたいことは、iPod touchでも大体できるのだ。iPadと違って、iPod touchなら産経新聞も無料で購読できる。価格も8GBで2万900円からと、iPhoneよりも手ごろである。＞(前述サイトより)
＜図式にすれば、（1）スマートフォンのアプリが増えて利便性が向上→（2）まずiPod touchを購入して、アプリを試す→（3）便利だとわかる→（4）スマートフォン購入を検討する、という手順になる。＞(前述サイトより)
という流れで......。

　今、"東日本大震災" への "国民的振舞い(?)" として、「自粛」とそのムードが蔓延していると言われる。下記の記事、＜「自粛ムード」国内蔓延（１）　続出する「中止」「延期＞が、その微妙な事情を手際よく伝えている。
　ここで注目したいのは、情感的には「自粛ムード」に傾きつつも、＜異論を唱える声＞が "気になる" という点なのかもしれない。
　つまり、＜日本人の「絆」の強さを示すと指摘される一方、「このままでは日本を停滞させる」との声も上がる。＞という面についても、冷静に見つめるべきなのかもしれないと思うのだ。

　＜むしろ応援ムードで行きたい＞、＜過度な自粛は避ける考え＞、＜「権力で自由な行動や社会活動を制限するのは最低限にとどめるべきだ」としたうえで、「経済に影響があるのかも冷静に考えるべきだ」との見解＞、＜長期化すると、被災者が『自分たちが迷惑をかけている』と思うようになる......。合理的判断に基づくもの以外、感情的な自粛はむしろ必要ないのではないか＞などの立場が含んでいる懸念は、ただ単に "考え過ぎ"、"冷酷" だと切り捨てて良いものとは思えない......。

　去る３月１１日に発生した"東日本大震災" は、事実が判明するごとにその "傷口" の広さと深さとが自覚されて行くようである。そして、"テロ事件" と "自然災害" という歴然とした差異はあるものの、そのダメージの甚大さにおいてはあの "9.11" 事件に匹敵、あるいは凌駕する巨大危機であったことが益々思い知らされる。
　今後も、さまざまな困難な局面を迎えることを余儀なくされるに違いないが、その時点その時点での最大限を追及して行く以外はない。

　現時点では、＜原子炉の水 地下を通し漏出か＞(下記記事[1])という問題が、恐らく "緊急課題" ではないかと思われる。＜高濃度の放射性物質を除去しないと復旧作業が進まないうえ、汚染が周辺地域や海に拡散していくのを抑える必要もある。＞と見られるからだ。
　ただし、想像以上の困難さを伴っているようで、＜福島原発、収拾に数カ月も　放射性物質拡散で作業難航＞(下記記事[2])とあるのが口惜しい。
　そんな状況の中、原子力分野でノウハウを持った各国から頼もしい援軍が駆けつけてくれているというニュースには、大いに勇気づけられる。
　＜汚染水処理、米独仏から機材やノウハウ　福島第１＞(下記記事[3])や＜米海兵隊、放射線専門部隊が来日へ　緊急事態に備え＞(下記記事[4])という動向がそれらである。

　相変わらず、余震も絶えないし、福島第一原発原子炉の深刻な状況推移からも目が離せない。放射能汚染問題は、こじれにこじれて "スリーマイル島原発事故" を凌(しの)ぐ水準ではないかとささやかれてもいる......。
　にもかかわらず、今一つ眉をひそめなければならないのが、今後 "ほぼ確実に" 訪れようとしている "更なる景気悪化" 状況なのかもしれない。
　いずれの問題も、その規模とメカニズムとからいって "個人的努力範囲の防衛策" を大きく上回る性格を持つだけに、厄介この上ないと言わざるを得ない。
　とは言っても、自然災害に対してそうであるように、何の備えもなく無防備で自暴自棄となっていては救われるものも救われないに違いなかろう。
　とにかく、これから何が起こるのかについての "想定" についてだけは的外れとなっていてはまずいように思う。