Archive for 12月 2009

rsync の –exclude オプション指定方法

サーバのデータは rsync でバックアップしている。最近、一部のディレクトリをバックアップの対象から外すため、–exclude オプションを追加した。ところが思ったように動作せず、除外するよう指定したディレクトリが、以前と同様にバックアップされてしまっていた。調べたところ –exclude オプションの指定が間違っていたことに気付く。rsync コマンドにおけるコピー元、コピー先の指定方法にちょっとクセがあることはよく知られているようだが、–exclude オプションにおけるディレクトリ方法もわかりにくいと思う。

仮に次のようなディレクトリ構成があると仮定する。

/foo/bar/
/foo/baz/
/backup/foo/

ここで /foo/ 以下をすべて /backup/foo/ に同期させたい場合、rsync コマンドのオプション指定は次のようになる。

rsync –archive –delete /foo/ /backup/foo/

さらに /foo/baz/ を同期対象から除外する場合は、–exclude オプションを次のように指定する。

rsync –archive –delete –exclude /baz/ /foo/ /backup/foo/

このとき –exclude オプションは同期元(コピー元)のディレクトリを基点とするため、/foo/baz/ を指定すると /foo/foo/baz/ ディレクトリが除外対象となってしまう。そのため対象ディレクトリを同期処理から除外できないばかりか、ディレクトリ構成によっては予想外のディレクトリが除外されてしまう可能性もある。

OSS ソースコードサーチツール

ちょっと日が経ってしまったが、今週の月曜日に OSSAJ 主催のミニセミナー「OSS ソースコードサーチツールの効能、有効活用方法」を聴いてきた。ソースコードサーチツールというのは、大量の OSS のソースコードを事前にパース処理して登録しておき、ソースコードに対するインテリジェントな検索機能を提供しようというもので、(株)SRA の葉雲文(Yunwen Ye Ph.D)氏により開発された。また、当日の講演とデモも葉氏によって行われた。

このツールを使って、例えばワンタイムパスワードの生成プログラムを OSS のソースコード群から探し出すことが出来るという。あるいは特定の標準ライブラリの正しい利用手順を調べる、といったことも可能になる。つまり OSS という宝の山から自分に必要なものを効率的に探し出すためのツールのようだ。

過去何十年にも渡る数多くの挑戦にも関わらず、いまだに完全な成功を得られていないソフトウェアの再利用という命題に対して、現場目線からの新しい切り口になるかもしれない。なお、このツール自体は現時点で OSS として公開されていない。

当日のプレゼン資料が slideshare で閲覧できる。

スマートフォンによるライブ配信

Android 端末で qikustream というアプリケーションを使うと、スマートフォンだけであっという間にライブ配信が出来てしまう。先日、某技術セミナーを Docomo の HT-03Aqik でライブ配信する実験をしてみた。携帯電話を三脚に取り付けるための器具(上海問屋で購入)を使えば固定も簡単である。講演は約2時間の長丁場だったので、充電用の電源パックを接続したまま配信を行った。

結果はまずまずだったと思う。画像は必ずしも鮮明ではないが、その場の雰囲気は十分に伝わってくる。部屋の照明を消してプロジェクターの明かりだけ、という低照度の環境であることを考えると、十分すぎるかもしれない。ただ、音声を鮮明に拾えていないという問題もある。Andoroid 端末の設置場所と講師の距離はせいぜい 3 – 4 m 程度だったが、配信先の再生環境で音声をクリアに聞くことは出来なかった。ボリュームを最大限に上げて、やっと聞き取れる程度である。携帯電話の内蔵マイクではこれが限界なのだろう。

このことは実験前から分かっていたので、Bluetooth 対応のヘッドセットを使って音声を拾おうと考えたのだが、qikustream のどちらの配信ソフトもヘッドセットのマイクをリンク出来なかった。通常の電話としての通話では、このヘッドセットは問題なく利用できるので、Bluetooth のプロファイルなどが関係しているのかもしれない。この点は今後も調査を継続する予定だ。

HT-03A には本体の USB 端子に接続する有線のマイク(+イヤフォンジャック)が付属しているので、これを延長する方法も考えられるのだが、その場合は USB 端子を共用している外部電源の接続が不可能になってしまう。1時間程度であれば内蔵バッテリでも大丈夫と思うが悩ましいところではある。

今回の実験では、Android 端末からの配信は 3G 回線を経由した。当初は、端末 → 無線 LAN → インターネットという経路を考えていたのだが、事前の調べでは利用可能だったはずの無線 LAN 設備が現場に無いことが判明したため、急遽 3G を使うことにした。都心とはいえ鉄筋コンクリート構造の屋内だったので接続状況を心配したが、2時間連続の配信は途中で途切れることはなかった。

あとで知ったのだが、Docomo は「直近3日間のパケット通信量が 300万パケット以上になるユーザの通信速度を制限」しているらしい。実験を行った当日のみのパケット通信量を調べることは出来ないが、今月分の今日までの全パケット通信量を見てみると約 160万パケットになっていた。配信実験以外に大量のパケット通信は無いはずなので、この数値がおよそ 2時間の配信での目安になると思う。なお、この通信速度制限の真偽を確認したかったのだが、Docomo の Web サイトでは情報を見つけることができなかった。

今回はセミナーという状況での実験だったが、スマートフォンによるライブ配信は屋外フィールドでの利用で、より真価を発揮するように思う。今ではビデオカメラも手軽に扱えるような状況ではあるが、ライブ配信を携帯端末だけで実現できるという点は重要ではないだろうか。このようなパワーを本当に必要としている人たちにとっては、iPhone や Android 端末は強力なツールとなるはずだ。

スマートフォン向けのレイアウトを実現する WPtouch

最近は Android 端末が日常で欠かせないツールとなっていて、Web サイトの閲覧にも Android 端末を使う時間が増えてきた。一応フルブラウザ搭載なので大抵のページを読めるのだが、サイトによって読みやすさの違いがかなり大きいように感じる。やはり端末のバリエーションに考慮していると思われるところのものは読みやすい。

ここで改めて自分の仕事用 Web サイトや Blog サイトを Android 端末経由で見直してみると、それほど悪くはないのもの快適というほどでもないことに気付く。仕事用のサイトについては静的な XHTML と CSS だけで単純に作ってあるので、各種端末への対応は自力でも何とかできそうな気もするが、WordPress による Blog のほうはちょっと難しそうだ。そこで公開プラグインを探してみたところ、まさにそのものの機能を提供してくれるものが見つかった。

http://wordpress.org/extend/plugins/wptouch/
http://www.bravenewcode.com/wptouch/

インストールは WordPress のダッシュボードにあるプラグイン管理機能を使って、他のプラグイン同様にオンラインで操作できる。インストールしてからさっそくこの Blog を Android 端末で見てみると、記事の一覧や本文が表示されるレイアウトが非常に読みやすくて良好である。あたかも Android 端末専用のクライアントソフトを使っているような感触だ。もちろん画面の縦横切り替えにも対応している。このレイアウトによる表示を見ていると、スマートフォンでは横スクロールをしないデザインが重要だと感じる。

WPtouch はもともと iPhone 向けにリリースされたようで、そっちのほうではよく知られているようだ。一般的な携帯電話でどのように表示されるのかは確認していない。

ちなみに wordpress.comWordPress による Blog ホスティングサービスを提供している。自前で運用する WordPress とは違って、wordpress.com の利用者は自分でプラグインを追加することは一切出来ないのだが、どうも WPtouch はデフォルトで設定されているようだ。そのため wordpress.com で Blog を作成すれば最初から Android 端末などに対応したレイアウトが可能になっている。

Android 端末で表示した WordPress の投稿記事画面

Android 端末で表示した WordPress の投稿記事画面

Android 端末で表示した WordPress の投稿記事画面2

Android 端末で表示した WordPress の投稿記事画面2

Android AVD の作成時に気を付けること

Android 用アプリケーションを作るため CentOS と WinXP に Eclipse ベースの環境を構築した。このとき WinXP 環境でちょっとしたつまづきがあったので、そのことを記録しておく。

Android SDK や Eclipse plug-in の ADT インストールはほぼ問題なく完了したが、AVD (Android Virtual Device) を作成したところ、PC の C: ドライブがパンク寸前になっていることに気づいた。AVD を作成するとかなりの容量を消費するようで、バージョン 1.6 用で 1.0GB、2.0.1 用だと 2.0GB も使ってしまう。いまどき 2.0GB 程度で騒ぐほどのことではないのだが、SDK を入れたノート PC の二分割された HDD パーティションは、C: ドライブが D: ドライブよりも容量がかなり小さくなっている。そのため色々とインストールしているうち窮屈になっていたところに AVD を二つ作成したため、一気に満杯となってしまった。

こういった事態を避けるため、AVD 作成時にその場所を任意に指定できればいいのだが、Eclipse のインタフェース経由で AVD を作成するときは、作成場所が C: ドライブに固定されていて変更出来ないようだ。実は Eclipse を介さずにコマンドで直接 AVD を作成することも可能で、この場合は AVD の作成場所を指定できる。しかし、せっかく作成した AVD(生成には時間が掛かる)なので、これをそのまま引っ越せないか試行してみた。

AVD を新規作成すると設定ファイルとデータディレクトリが作られる。例えば Android_1.6 という名前で AVD を作ると、次のようなファイルとディレクトリが出来上がる。

C:\Documents and Settings\<YOUR_ACCOUNT_NAME>\.android\avd\Android_1.6\
C:\Documents and Settings\<YOUR_ACCOUNT_NAME>\.android\avd\Android_1.6.ini

この Android_1.6 ディレクトリをそのまま別の HDD 領域に移動するとともに、Android_1.6.ini ファイル内に記述されているディレクトリを移動先のものに書き換える。この Andoroid_1.6.ini については上記の場所から移動していはいけない。

この方法で 3.0GB もあった AVD を容量に余裕のある HDD に移行しても、問題なく Android エミュレータを起動することができた。

(2009-12-09 訂正)
本文中 Android のバージョンにより AVD が必要とする HDD 容量が異なっていると記述したが、これは誤っていることが分かった。今回の作業でバージョン 1.6 が 1.0GB、2.0 では 2.0GB となっていたのは、AVD 作成時に指定した仮想 SD カード(sdcard.img)の容量が異なっていることによる。SD カードを除くと、AVD の初期状態(userdata.img, userdata-qemu.img, cache.img, etc)で 50MB にも満たない程度であり、この大きさはバージョン 1.6、2.0 のいずれでもほとんど同じであった。