早速Ubuntu 12.10 Touch Previewをインストールする

CanonicalからUbuntu Touchのプレビュー版（MWC2013でのデモ用イメージ）が公開されました。対象は、Nexusブランドの4機種、Galaxy Nexus, Nexus 4, Nexus 7, Nexux 10です。

このあたりも見越してGalaxy Nexusの中古を入手してあったので、早速入れよう... としたのですが、説明はあくあまでUbuntuを使っての作業が書かれているのみ。

しかし、カスタムROMやらGalaxy NexusならGoogle公式最新版イメージに置き換えたことのある人ならご存知の通り、adbとfastbootさえあれば、bootrom unlockしたNexus端末にどんなROMを入れることもできることはご承知の通り。

そんなわけで、Mac OS X（たぶんWindowsでも同じ）から、Ubuntu Touchをインストールする手順を以下に。

1. イメージ等、必要なファイルの入手

今回公開されたイメージファイルは、ここにあるものがすべてです。それぞれ、機種に対応するコードネームがついたものがあります。それぞれ、

• Galaxy Nexus - maguro
• Nexus 4 - mako
• Nexus 7 - grouper
• Nexus 10 - manta

です。今回はGalaxy Nexusなので、ファイル名にmaguroが入っているものすべてを適当な場所にまとめてダウンロードしておきます。慎重な人は、md5ファイルもとって、md5コマンドで正常にダウンロードできたかどうかをチェックしてもいいでしょう。今回は、以下の4つ

• quantal-preinstalled-armel+maguro.zip
• quantal-preinstalled-boot-armel+maguro.img
• quantal-preinstalled-recovery-armel+maguro.img
• quantal-preinstalled-system-armel+maguro.img

です。

2. adbとfastbootの準備

これは、Android SDKのなかに入っています。Mac版は、platform-toolsの下に入っているので、適当にイメージと同じ場所に移動してしまっていいでしょう。

3. bootrom unlock

すでにやってある人は気にしなくていいのですが、初めての人は、以下の作業をしてください。

1. いったん電源をオフにします
2. 電源ボタンと音量ボタン上下の3つのボタンを同時に押して起動します
3. 端末とMacやPCをUSB接続します
4. ./fastboot oem unlock  のコマンドをPC側から実行します

4. 稼働中のAndroidのバックアップ

もう戻らないよ、という人や、まっさらからAndroidイメージを書き戻しても惜しくない人はこれをやらなくてもかまわないですけれど、Androidに戻したくなったときのために、現状のすべてをバックアップしておきます。ただ、なにやらGoogle Playに怪しげなバックアップツールがいろいろありますが、どれもsecroid.comで調べてみると、「危険度HIGH」で、広告屋やらPayPalなどへ情報を送信しています。使わないのが無難ではないでしょうか。

ICS以後はadbコマンドでフルバックアップがとれるので、以下の通り、簡単に済ませましょう。

その前に、「USBデバッグ」を有効にしなくてはいけません。これは、設定アプリで情報を開いて、ビルド番号のところを7回連打すると隠されていた「開発者向けツール」の項目が現れ、そこのなかに設定があります。「USBデバッグを有効にする」にチェックを入れておきます。そして、そのあと、MacやPCにUSB接続をすると、Android画面に（4.2以後なら）USBデバッグの許可をするかの確認が出ます。コンピュータのハッシュも出ますが、まぁそういうことで、「許可」します。そのあとで、adbで以下のおまじないをしておくといいかもしれません。

$ ./adb kill-server; ./adb start-server

そのあとおもむろに、

$ ./adb backup -f android422.ab -apk -shared -all -system

とやって、android422.abなど、適当なファイル名でバックアップを取得します。これは、あとでリストアするときに使えます。

5. 各種ファイルの書き込み

まず、Androidが普通に起動している状態にしておきます。USBデバッグは有効にしておいてください。そこで、adbコマンドでzipファイルを/sdcardに書き込みます（内部のフラッシュメモリですが、データ保存場所としてそういう名前のフォルダがあると考えてください）。

./adb push quantal-preinstalled-armel+maguro.zip /sdcard/autodeploy.zip

後ろのファイル名は固定です。この名前でなければだめです。

そのあと、端末を再起動してイメージを一気に書き込み、最後に再起動する作業をします。

./adb reboot bootloader
./fastboot flash system quantal-preinstalled-system-armel+maguro.img
./fastboot flash boot quantal-preinstalled-boot-armel+maguro.img
./fastboot flash recovery quantal-preinstalled-recovery-armel+maguro.img
./fastboot reboot

これで、Googleロゴが出たまま固まっていると思います。失敗したかと焦ると思いますが、なにやらイメージのリサイズとやらで、10分以上待たされるのだそうです。Galaxy Nexusだと、もしかすると30分とか平気でかかるかと思います（と書いているのは、まだ起動待ち状態だから）。

 というわけで、こちらはまだGoogleロゴの画面のままなので、なにがどうなっているかさっぱりわかりません。当面寝かせておいて、起動したらまた追記します。

おまけ：Androidの復元

4.2.2のイメージは、Googleの開発者向けサイトに置かれています。Galaxy Nexsusなら、maguroの項目を見て、4.2.2の「Link」をクリックすればイメージをzipにしたものが落ちてきます。あとは、これを展開したなかにある./flash-all.sh を実行してやれば、イメージの書き込みが終わり、まっさらな状態で再起動します。その後、最初の言語の選択とGoogleアカウントでのログインを終えたあと、クラウドからの復元のチェックを外しておいて先に進んで、ホーム画面にたどり着いたら、再びUSBデバッグを有効にしたあと

./adb restore android422.ab

のようにファイル名を指定してバックアップから戻せば元通りです。

おまけその2：石化してしまった場合の対処

1日置いたけど先に進まない、もうだめ、というときには、落ち着いて裏蓋を外し、電池を抜きます。深呼吸しながら10数えて再び電池を入れ直し、裏蓋をします。その後、おもむろに電源ボタン＋ボリューム上下ボタンで起動してやれば、リカバリモードに入ることができます。ここで心配ならば、上のAndroidの復元をすれば元通りになります。

Windows 8でホームディレクトリを英数字のみのユーザ名にする方法

かなり過日のことでしたが、Windows 8が作成するホームディレクトリが漢字にならない方法を見つけたので、念のため紹介しておきます。

普通にWindows 8をインストールする際には、ユーザの登録場面で、Microsoftアカウントの作成もしくはMicrosoftアカウント（旧Live ID、旧旧Hotmailアカウント、旧旧旧...）でのログインを求められます。このとき、そのMicrosoftアカウントに関連付ける氏名に漢字を使っていると、下の名のほうを使った日本語フォルダが作成され、ホームディレクトリになります。僕の場合は、ユーザの下に「敏之」というフォルダができるという感じ。

いまどきの若い方々は下の名前で互いに呼び合うので違和感はないかもしれませんが、私のようないい年のおっさんには、「なんだよ、呼び捨てかよ」的な違和感が残ります。

またなにより、ホームディレクトリの下には、Windowsでユーザ固有の設定を置くユーザプロファイルという特殊なファイル（普通は見えない）や、アプリケーションの個人設定などを置くApplication Dataフォルダなどがあり（これも普通は見えない）、インストールしたアプリはすべからくこれらを読み書きします。

そこで、例えばネットからダウンロードしてきたソフトウェアとか、日本語版でないアプリケーションなどを動かすと、ユーザプロファイルやApplication Dataフォルダ以下が見つからずに、へんてこに文字化けた謎フォルダを作ったあげく、起動しないということがたびたび生じます。

世間ではこのようなとき、「英数字でないログイン名をつける奴が悪い」「その変な文字やめれ」的な回答をユーザーフォーラムのようなところで雨あられと頂戴することになっております。これは漢字圏に限らずヨーロッパでも同じで、母国の正しい表記の名前でユーザ名を作ったばかりに、上記のように屈辱的な回答を頂戴して「ごめん、出直してくるよ」と回答せざるを得なくなるケースを非常によく見ます。旧聞になりますが、Kobo騒動では三木谷がマヌケだったわけではなく、彼こそがグローバルスタンダードだったといってもよいぐらいなわけであります。

そんなわけで、Windows 8はLive IDもといMicrosoftアカウントとの統合が売りなので、Microsoftアカウントでないことに対して様々な不安を与える表示を出して、Microsoftアカウントへと誘導します。しかし、ここさえ乗り切れば、「つい、うっかり」非英数字のホームディレクトリを作成してしまうことを避けることができるのです。

いま、インストールの途中でMicrosoftアカウントの作成もしくはMicrosoftアカウントでのログインを求められている場面だとします。ここで、迷わず「ローカルアカウントを使う」を選ぶのです。すると、Microsoftアカウントを使うことの優位性を説かれ、「それでもいいですか」的な表示が出ます。ここでひるんではいけません。非情に「ローカルアカウントを作成する」を選択します。そして、英数字でローカルアカウント作成するのです。

これで、ホームディレクトリは英数字の範囲内で作成されました。でも、もちろんローカルアカウントなので、Windows Live（でいいんだっけ）による、ユーザ情報の共有やアプリの同期などはできません。どうせWindows 7まではそうだったし、この状態でもSkyDriveなどは個別にアプリからログインすれば使えますから、このままでもいいでしょう。でも、ありがたいことに、この状態から「Microsoftアカウントへ切り替える」しても、ホームディレクトリはそのままなのです。この変更は、個人設定でできます。スタート画面でチャーム（右からうにょって出てくるやつ）を出し、いちばん下のギアを選択して、切り替わった画面のいちばん下にある「PC環境の設定」を選べば、「PC設定」アプリが起動し、左の「ユーザー」メニューを選べば、「お使いのアカウント」として、Microsoftアカウントへ切り替えるのボタンが現れます。ここではじめてアカウントを作成するのもよし、すでにLive IDをお持ちならそれでログインすればいいというわけです。

ちなみにこれは一方向です。というか、最初に作成されたホームディレクトリが必ず維持されます。なので、先に非英数字のホームディレクトリを作成してしまったら最後、いくらMicrosoftアカウントの氏名をローマ字に変更しようとも、漢字なら漢字のままです。思い出してください。ここには、ユーザプロファイルという、Windows NT以後最重要な個人設定ファイルがあるのです。途中でこのファイルの場所を変更するのは危険です。できないように作りこむのがメーカーの良心というものでしょう。

Windowsの設定に詳しい方なら、プロファイルのパスを設定変更する方法をご存知かと思います。もちろん、その機能はあります。同じ画面でホームディレクトリを直接指定することもできるので、英数字の任意のフォルダをホームディレクトリに設定することも可能です。しかし、残念ながら、Application Dataフォルダは相変わらず漢字のフォルダ側に残ります。要するに、普通にユーザから見えるデータの置き場所だけが設定したディレクトリになるだけなのです。さらに悪いことに、ユーザプロファイルが分断されて、両方に書き込みが（一貫性なく？）あるようです。環境変数の書き換えも万能ではありません。アプリケーションによっては、こうした設定に従ったり、環境変数だけを参照してくれるケースもあるのでうまくいくこともありますが、それは運がよかったというべきかと思います。したがって、これらは「無駄な抵抗」と思っておいたほうが無難ではないかと僕は思っています。

最後に、もう一度だけおさらいしておきます。

「先にローカルアカウントを英数字の範囲だけで作成し、そのあとでMicrosoftアカウントへ移行すれば、日本語のフォルダが勝手に作られることから逃げられます。」

日本語のホームディレクトリができてしまった人は残念です。Windowsと心中できる覚悟のない方は、諦めて再インストールしましょう。事情があって再インストールは不可能な場合は、新たにローカルアカウントを英数字で作り、いったんサインアウトしてから新しいローカルアカウントでサインインして、なんとかすればいいでしょう。ただし、ホームディレクトリの削除は管理者権限でコマンドプロンプトを開いたぐらいでは消すことができません。もちろん、管理者権限でコマンドプロンプトを開いてそこでの作業をするのは前提なのですが、attrコマンドでファイルやフォルダに対してひとつひとつ権限を外したあとでなければ、どうやっても消せません。非常に面倒です。こういうときは、ダチョウアルゴリズムを採用して、「見なかったことにする」のが正しい対処法ではないかと思われます。

そういえば、マイクロソフトに忠実な方で、正式版以前からアップデートされてきた方は、Windows.oldというフォルダがCドライブのルートにあることでしょう。これも同じように、attrコマンドでちまちまと膨大な作業をしないと消えません。VBScriptやPowerShellを使いこなせる人が近くにいれば、スクリプトで作業するのも手かもしれませんが、ディスクにゆとりがあるなら、これも「見なかったことにする」のが最も手っ取り早いように思います。多少ディスクの残りが厳しいならば、管理者権限である程度までは消すことができるので、それをやってあとは諦めるのでもよいと思います。

自分のCalibreライブラリをOPDSで自分用に公開する

英文の本はほぼ確実に電子書籍を買う。待たなくていいから。特に、O'Reillyの本はDRM Freeで、DropBox連携もあるので、買えばその場で自分のDropBoxアカウントに落ちてくる。Kindleも、まぁ、すぐに落ちてくるが、DRMがついているのでこれはやや難がある（それをどうにかする話は検索すれば多数ひっかかるし、商売でやっている人も海外にいるから読者のご判断に任せる）。

自炊本も含めて、蔵書管理に便利なのがCalibreだ。多数の電子書籍デバイスにも対応していて、DRMの心配がない、例えばパブリックドメインの本などは全部これに入れておき、書誌情報をGoogleやAmazonで検索してくっつけておく、などということもできる。

一方で、出先で自分のCalibreライブラリにアクセスしたいということはあると思う。CalibreはWebサーバとして動作する機能があり、「サーバを起動」すれば、設定したポートでWebサーバとして動作し、設定したパスワードで以後蔵書にアクセスしてダウンロードすることもできる。サーバのページはわりとよくできていて、特に不満はないと思う。

ただ、電子書籍の書誌情報についての規格としてOPDSというのがあって、OPDSカタログを使ってInternet Archiveや青空文庫などと同じようにOPDSから本を選んでダウンロードしたいということもあるだろう。それをどうにかしてくれるのが、calibre2opdsというソフトウェアだ。これはCalibreとは別のプロジェクトで作られていて、作者個人がメンテナンスしている感じだ。当初はDropBoxにCalibreのライブラリごと置いてOPDSカタログもそこに作れば幸せだね、って感じでやっていたようだが、DropBox側の通信量制限にひっかかるケースが続出したようで、OPDSそのものにブロックがかかってしまったようなぼやきが作者のブログに書かれている。

なので以下の記述は、自分でWebサーバを公開できる人に限った話ということになる。

話は簡単で、Calibreのライブラリごと自分のWebサーバに置いて、そこにcalibre2opdsでOPDSカタログを作り、StanzaなどOPDSに対応した読書ソフトウェアに、生成されたindex.xmlへのURIを設定する、ということになる。

i文庫HDなどのように、最初からDropBoxに対応しているアプリで不便を感じていないならば、またGood Reader経由でアプリに渡せばいいじゃないかと思うなら、こんな面倒なことをする必要はない。

しかし、青空文庫やProject Gutenberg、O'Reillyなどと同じ並びで自分の本棚が選べてダウンロードできるというのは、やってみると一味ちがう。StanzaはEPUB2までの対応ということで、縦組みは期待できないが、O'ReillyのPDF版を読むぐらいなら、絶対にStanzaで読むEPUBに切り替えるべきだ。好みの問題といえばそれまでだが、僕は紙の書籍のときから、O'Reillyのへんてこなフォントが大嫌いだった。これで読むしかないから我慢していたのであって、読みにくくて脱落することがとても多かった。でも、Stanzaのデフォルトフォントは、少なくともiOS版に関する限り、十分にオーソドックスな書体が使われていて、たいへん読みやすい。文字のせいで脱落するようなことはなくなった。だから、Stanzaに直接ダウンロードするのを、Webサーバ上でCalibreを動かすことなく（普通はそうだろう）、生成されたインデックスと書籍本体のファイルだけ置けば可能になるというのはとてもよいものだ。日本語も問題なく処理してくれるので、自炊PDFも大丈夫だ。

StanzaはEPUB2とPDF以外にはWordとRTFとHTMLに対応しているんだそうだ。他にmajor ebooks formatsということなんだが、MOBIとかが対応しているのかどうかは試していないのでいまのところわからない。

それから、OPDSは、英文のWikipediaの項目を参照されたい。パブリックドメインの本を提供している複数のサイトのOPDSが掲載されているので、シャーロック・ホームズを原文で読みたいとか、そういった古典へのアクセスに、青空文庫が満足できると思う人なら無償のデジタル本やスキャンされて公開されている古書をこれらOPDSを通してアクセスするのはなかなか快適だ。インライン画像も入っているのでスキャンした本やEPUBで表紙が含まれているならそれが現れるし、書誌情報がついていればそれを確認してからダウンロードすることもできる。ぜひ試してみていただきたい。

そういえば、国会図書館がデジタル化資料（古い官報や古典籍―とはいっても著作権が切れていればいいので1949年、つまり戦後すぐまでの本は入っている）を公開しているのだが、OPDSないよー、とぼやいている人が検索したらたくさん出てきた。ついでなのでここでも「国会図書館のデジタル公開分もOPDS対応してほしい」と要望しておきたい。

iOS 6.1 OTAトラブル

Apple税を払っているので、iOS betaが入手できる。いまのところ特にこれといってアプリの開発を行っているわけではないが、少なくともiOS 6.0はWi-Fiまわりが特にひどかったので、iOS 6.1 betaを入れていた。先日までにbeta 4までOTAして動いていたのだが、しばらく触っていなかったところ、奇妙な現象が起きた。

いままでOTAは、「設定」アプリから「ソフトウェア・アップデート」を開かなければ開始されなかったはずなのだが、なぜか今朝、6.1正式版に上げてみるかと電源を入れてみたところ、いつのまにかOTAが終わっていて、Wi-Fiの選択をする画面が現れたのだ。

Wi-Fiの選択肢の下には、「iTunesでアクティベートする」の選択肢があり、どうやらAppleサーバへのiOS署名の認証を待っているようだった。

ここで、どうせ充電のためにMacに接続していたのだから、iTunesでアクティベートしてみればよかったのかもしれないが、なんとなく複数あるWi-Fi APのひとつを選択して先に進んでみた。すると、「アクティベートに失敗しました」画面となり、「iTunesでアクティベートするか、数分後にもう一度試してみてください」というのだった。下に「再試行」のボタンがあるので、再試行すると、再びWi-Fi APを選択する画面に戻る。しかし、今度は「iTunesでアクティベートする」が消えている。何度も試し、別のAPも試し、最後には携帯回線のルータへ接続してみたのだが、いずれも結果は同じ。

ただひとつ、Wi-FiのAPを別のものにした瞬間、一瞬だけ「iTunesでアクティベートする」の項目が現れるのだ。そこを狙ってタップを連打すると、選択を示す青になって先に進む。iTunesはMac上で起動している。だが、結果は同じだった。

どうにもならないので、Apple Careサポートチームに連絡をとり、状況を説明した。彼らが持っている障害データベースにも該当するものはないらしい。そこで、Xcodeから何かできるかもしれないと思い、Xcodeを起動しながらその旨説明をすると、シニアアドバイザーと交代するという。ちょうどXcodeのバージョンも上がっており、更新しろとXcodeが言うのでアップデートしている間にシニアアドバイザーと話をした。

だが、彼も現象が理解できないらしい。逆にこちらがXcodeでどうするのか期待されてしまった。とはいえ、できることはプロビジョニングの更新ぐらいであった。しかも、どうもそれさえ成功していない。「このバージョンのiOSはサポートしていない」とか、わけのわからない表示になっている。

こうなると、シニアアドバイザーとしても、「復元」を薦めるしかない。だがこちらは先日マルウェア駆除のためいったん大掃除して以来、一度もバックアップしていないのだ。残念ながら、30GB超のバックアップを置いておけるディスク領域を持ち合わせていないためだった。

電話口でぶつぶつ言いながら、諦めて「復元」ボタンを押すと、バックアップをするかときいてくる。dfしてみると、なんとか入りそうなぐらいの空きはあるので「OK」を押すのだが、バックアップすることなく復元の確認に入った。そして「復元する」を押すのだが、エラーとなる。なんだそれ。

というわけで、こりゃDFUに入って完全に新しいiPadとして復元する以外に手はなさそうだと思っているところに、電話の向こうも「復元モードで復元しましょう」と言う。いわゆる、「iTunesに接続する」画面のことだ。

それで、DFUに入る手順で復元モードに入り、iTunesから「復元」を押すと、当然のことだがiOSのダウンロードが始まった。そして、インストールが始まり、Appleの認証を通して購入時と同じ、「ようこそ」画面になった。順に選択を行い、アクティベートのところでは「Wi-Fiを使わずにアクティベートする」という形で進め、なんとか初期状態になったところで電話を切った。

シニアアドバイザーの意見では、iOS 6.1 beta 4から6.1正式版へのOTA固有の不具合ではないかというのだった。たしかに、そんなところかもしれないし、そのあたりで納得しないとやっていられない。なにしろこちらはアイコンの配置も、iCloudに依存しないアプリ固有のデータも、in-app Purchaseで購入したあれこれも全部失っているのだ。

これから、それらをちまちまと作業して、できるところまで戻してやることになる。いちばん困るのはin-app Purchaseしたもので、アプリによっては実際に購入手続きに進んでみないと、すでに購入したかどうかわからないものがある。すでに購入した場合は課金されないだけという、たいへんスリリングなものだ。いったん間違えて、記憶に従って、買っているはずだと思うものを選んで購入手続きを続けていたら、結構な金額を請求されたことがあった。

またそれを繰り返すと思うと気が重くなる。

シニアアドバイザーは電話口で「デベロッパーの方に申し上げるのもナンですが、できるだけこまめにバックアップはとられたほうが」と繰り返していた。ごもっとも。

Wiimote IRカメラとのたたかい

Wiimoteの赤外線カメラと格闘している。

Wiiリモコン先端の黒い窓、いわゆる赤外線リモコンを連想する部分なんだけれども、よく知られているように、このなかには、画像処理するマイコンを内蔵した赤外線カメラが存在している。

マイコンでは赤外線の光点を4つまで追跡して、それぞれのカメラ上の座標をI2Cで出力するような処理が行われるので、単にI2Cで出てくる数値をとるだけでアプリケーションが簡単に作れるという仕様。

いわゆるWiimote Hackでは、BluetoothでWiimoteとPCなどを接続してセンサのデータをとったりするのだが、過去に作成されてきたソフトウェアはどれもWindows 7またはMac OS Lion、あるいはLinuxに限られていて、Windows 8とMac OS Mountain Lionしかない状況ではどうにもならないのであった。

それで、世界中が感動した、このカメラの解析ページをもとに、中古で買ってきたWiimoteを分解して、このページと同じように2.54mmピッチの8pinヘッダをとりつけたのだった。これはもう、自分で自分をほめるしかないタフな作業。というのは、Wiimote IRカメラは2mmピッチの千鳥足なんである。つまり、前列4pinと後列4pinは1mmずれていて、ただでさえピッチが合わないのに、前と後ろがずれているので、合わせる場所が本当に8つのピンの中央にしかない。また、カメラの極細の足を曲げないといけないので、空中配線になる。さまざまな試行をしたが、結果として、ヘッダーピン側を水平になるよう、うまく固定して、その隣に、コピー用紙5枚（試行錯誤で、この枚数で上側の端子と高さが合った）に載せたカメラユニットを置いて、そっと中央を合わせ、その2本をはんだ付けし、それから左右を少し開いてはんだを流し、片側を完了させたあと、裏返して再び横からじっくり眺め、高さが揃うように今度は前後の間隔を開くよう、適当な定規で持ち上げ、中央2本をつけ、残りを開いてつけるという作業で完了した。老眼で細かいものが全く見えないうえ、電気スタンドで強い光をあてないと細かいものが見えなくなっているので、ルーペを片目で眺めながら、片目だから距離感がないのを時計職人のつもりで慎重に位置をはかりながらの作業であった。

続いて、カメラのCPUを動作させるためのクロック回路とリセット回路の製作に入った。回路図の定数通りに部品を揃えるのだが、リセット回路の30kΩというのは謎である。E24系列でも存在しない値だから。とはいえ、これは単にプルアップしているだけなので、適当でよいはず。22kΩにしておいたら、海外で商品化した人の回路図も22kΩであった。

ひとまず完成したように見えたので、簡単に導通テストだけをやって、少なくとも電源のショートという情けない状態ではないことを確認して、クロック発振を確認してみた。手軽なので使っている、Seed StudioのDSO Nano Duoで見ようと思ったのだが、ちっとも確認できない。いくら回路を調べても、テスターで電圧を調べてもわからないので、テクトロのちゃんとしたデジタルオシロで確認したら、25MHzのはずが75MHzで発振していた。3倍の異常発振だ。

実はクロック回路を自分で組み立てるのは初めてで、ネットに助けを求めたところ、水晶発振子の異常発振の現象と対策についての解説があり、まさに3倍のケースだったので、Rsを追加することで解決をはかった。幸い抵抗はE24系列すべて100本ずつ揃えてあるので、100Ωから順に10kΩまで試してみた。1kΩでようやく25MHzが出たものの、過電流のせいか、振幅が大きく、3.3Vの給電なのに5V近くまで上がり、逆にマイナスにも振れてしまっていた。10kΩでそれはおさまったけれどもまだ歪みがあるので22kΩにしたら、50MHzになってしまったので10kΩに戻した。ほかにも、CLを大きくするというアドバイスがあったので、15pFを4つ買ってあったのを幸いに、それぞれ2個並列にしてみたが、あまり効果はなかった。

そうしてようやく、デバイスを壊さないであろう程度のクロックが得られたのでカメラユニットをソケットに挿してみたのだが、I2Cのクロックさえ出てこないうえに、しばらく調べながらふとユニットを触ってみたら熱いこと。危ないので即座に取り外して、基板を調べてみると、よくわからないのだけれどVcc-GND間が19kΩしかない。はては、I2Cの端子に至っては34kΩとかで、電圧を測ってみると2V以上出ていた。配線ミスなんだろうけれど、やり直す時間も体力もないので、再び海外の商品の回路図を眺めてみたところ、クロックはオシレータユニットを使っているのであった。秋月ならこれで済ませられるところ。

クロックまわりを除けばあとは単に電源とI2Cの引き出しをするだけなので、せっかくがんばったクロック回路はとりやめることにした。それで、なんとなく検索をしていたら、ARMマイコンであるmbedに接続したよという例があって、クロックはCoretex-M3内蔵のPWMで生成してしまい、結局リセット端子のプルアップとI2C端子のプルアップをするだけの簡単回路になっていた。

当初はArduinoに接続するつもりで、Arduinoの5V端子に接続するため、手持ちのSparkfunのレベルコンバータ基板まで実装していたのだけれど、mbedで済むならこれさえいらない。また、mbedでシリアルに流してやれば、当初予定していたNode.jsとの連携もArduinoでやるのと変わらない。この人のように、シリアル（USBだが）に出力するように素直に書けば、Arduinoとやってることは同じだ。

なんだかすごく遠回りをしたような、まぁ勉強になったのではあるが、そんじゃあ、ということで、mbed+StarBoard Orangeを取り出してきたところである。StarBoard Orange使うならWebSocketで出力する例で、さらにUSB HostにもなるからWi-Fiドングルつければいいんじゃないかとか、そんな意見もあるかもしれないが、BluetoothがWi-Fiに置き換わっただけなんだがそれってうれしいのか、とか、それならBlueUSBで無改造のWiimoteと直接ペアリングしてWebSocketしゃべれよとか、いままでの努力はなんだったのかと悲しくなってくるので、シリアルでデータを流すところで勘弁して貰いたいと思っているところだ。

（2013年1月26日追記：昨日mbed接続用の基板を作ってカメラユニットを装着し、見事に4つずつのXY座標をシリアルポートで得ることに成功した。ちなみに、mbedのPWMが出していたクロックは20MHz前後だった。したがって、水晶発振子でクロック回路を自作する人も25MHzにこだわることなく、入手しやすいクリスタルなりオシレータを使っても大丈夫なようだ。また、mbedの出力は結構ジッターがあるので、クリスタルでなくセラロックでも大丈夫かもしれない。あと、Mac OSでシリアルポートと通信するのは、screenコマンドだというのが新鮮だった。古いUNIXユーザなので、POSIXならcuと頭から決め込んでいたのだけれど、cuの仕様も変わっているし、しばらく迷ってしまった。シリアルポートの速度設定はsttyで。だがめんどくさいのでmbed側のプログラムで9600bpsにして、デフォルトから変更しなくてもよいようにした。）

Zabbixでマシンの稼働状況監視をしてみる

ネットワーク屋さんやSI屋さんが設置する、導入システムの稼働状況監視（障害検知）には、いくつかのシステムがあるようだけれど、今回、職場の情報処理センターに導入予定のZabbixを手元で動かして試してみることにした。

Zabbixは1.x系と2.x系があるようだけれど、今回ははじめてなのでいま最新の2.0.4を使うことにした。

サーバが情報を集約し、PHPを使ったWebインタフェースでリアルタイムに情報を見るというしくみ。情報収集にはSNMPを使ったりサービスポートを叩いたりといった原始的なものから、システムの稼働状況を詳細に計測してサーバからの問合せに応える「agent」とよばれるプログラムをインストールしておくという方法もある。

今回は、手元のMac miniでサーバを動かし（グローバルアドレスが振られている）、職場のNAT内のWindowsマシンやプリンタ、WiFiルータなどと、個人的に契約しているさくらのVPSを一括でみることを考えた。

さくらのVPSは、ISOイメージさえあれば、それを一時的なアカウントでアップロードして、Java経由の仮想コンソールでインストール作業を完了することができるので、OSはたいていのものが使える。僕はLinuxに慣れていないので、以前からFreeBSDを使ってきた。いまは9.1が動いている。

zabbix2のagentは、もちろんFreeBSD用もあり、portsに入っている。PKGNGではそのまま入るところにまだなっていないので、/usr/ports/net-mgmt/zabbix2-agent以下でmake install distcleanすることになる。/usr/local/etc/zabbix2/zabbix_agentd.confに、サーバを動かすマシンのIPアドレスを設定し、/etc/rc.localからでも起動スクリプトを動かしてやればおしまい。

サーバを動かすMacでは、MacPortsを使っているので、port install zabbix2で入れることになった。

ところが、昨日現在での最新状態では、アカウントzabbix、グループzabbixが作成されないため、インストールスクリプトのなかでchownするところで落ちてしまう。しかたがないので、dsclコマンドでアカウントとグループを作り、再度インストールして切り抜けた。

ただ、インストール後のMySQL5の準備（データベースの作成、テーブルの作成、データの挿入）などはすべて手作業になるので、portコマンド実行後に表示される長い説明を読み飛ばさないように注意する必要がある。あと、PHPのモジュールもいろいろと必要なので、Webインタフェースで最初の設定作業をするときのPHPの診断表示に合わせて足りないモジュールや/opt/local/etc/php5/php.iniの書き換えと、カーネルパラメータの設定（共有メモリを大きくとるように設定変更する）は必要だ。カーネルパラメータの値はどの値が適切なのかよくわからなかったが、とりあえずFreeBSD用の値と同じで動いている。FreeBSDと違うのは、/etc/sysctl.confというファイルではなく、sysctl -wコマンドで直接データベースの値変更を行うところ。

なお、ZabbixのWebインタフェースで最初にZabbix Serverを追加するような説明が多いのでそのようにすると思うけれども、MacPortsの起動スクリプトではzabbix_agentdは起動されないので、障害として報告されてしまう。エージェント監視を無効にするか、エージェントも起動するように手を入れておくことが必要になるので注意。

最後に、Windowsについて。Windowsのエージェントをサービスとして登録し、起動するにはコマンドプロンプトを使うが、管理者権限でなければならないので、コマンドプロンプトを管理者権限で起動することを忘れずに。また、zabbix_agentd.confファイルもC:\に置くことになっているので、これも管理者権限がないとできない。設定ファイルの内容は、たった1行、「Server=サーバのIPアドレス」だけで十分なはず。

あともうひとつ罠は、Windows Firewallの設定で、zabbix_agentd.exeの通信許可を手動で行わなければならないということ。コントロールパネルから、Windowsファイアーウォールを開いて、設定をすれば、Zabbixサーバと通信ができて、通信障害が出ることはなくなる。

とりあえずいまのところはこんな感じ。WiFiルータの状態監視もしたいのだが、SNMPトラップをどうみるかは、まだ検討中というところ。

Exynos騒動に関連して一言

Exynos 4210と4412の設計ミスか？　と、ちょっとワクテカしたのだがいまひとつ残念だったというのが率直なところ。

とはいえ世の中に出ているAndroid機器の台数では相当なものだろうから、CPU依存コードの修正版が配布されるまでは利用者にしてみればドキドキもんだろう。

今回の騒動は要するに、Androidの下にいるLinuxのCPU依存コード（カーネルコードの共有ライブラリ）をミスってユーザランドからカーネルメモリも自由に読み書きできるようになってました、という間抜けな話。Linuxカーネルのなかみはよくわからないけれども、メモリセグメントのrwx権限をもつテーブルかなにかのフラグ管理を間違えたんだろう。この手のミスは、複数箇所でフラグをいじるようなコードを書くと生じやすいので、ぶっちゃけスキル不十分なプログラマを投入した上に、きちんとしたコードレビューができるチームでなかったというところではないだろうか。

仕事上、韓国のIT技術者や研究者と接する機会が多いのだけれども、こういうところの品質が担保できる人材は少ないんだろうなと思うことが多い。日本メーカーもソフトウェア開発は苦手だけれども、そしてそれが組織作りや運営の問題ということが多いのだけれども、韓国人は日本人より大陸的というか、現場で失敗しながらスキルを身に着けることをよしとする傾向が強いので、上司（儒教社会なので目上や上の立場の人は絶対）が無能だとろくでもないものがあっさりと世の中に出てしまう感じだったりする。

で、一部にはAppleのiOSデバイス用CPUもサムソンの設計だからと怖がっている人が一部にいるみたいだけれど、AppleのAシリーズ開発はカリフォルニアでがっちり管理しているし、あのうるさいジョブズがこういう基幹技術の流出をよしとしたはずがないので、関わるエンジニアは完全に隔離されているというAppleとサムソン両者の説明はあながち嘘ではないと思う。

とはいえ、A4にはLimera1n exploit、A5にはデュアルコアの間の一貫性管理のミスというCPUロジックの致命的欠陥が脱獄に利用されているので、AppleのCPUだから安心というのはあまりに楽観的にすぎるといえる。iOSデバイスの場合、脱獄への強い動機があるので妙にトガッたティーンエージャーやそれ上がりの大人が寝食惜しんで脆弱性探しをしていることで発見されやすいのだけれど、おそらくどのメーカーのCPUにもexploitにまで組み上げられる何らかの欠陥のひとつやふたつは抱えているのだろうと思う。

知人の論理検証専門家が自社のCPUを対象に自分の研究成果を適用したらぼろぼろエラーが見つかって、上司に報告したらその検証ツールはお蔵入りにされたという話もきいているから、納期やコストなどの都合で、仕様書通りの動きさえすれば品質管理部門はOKを出しているのが実際のところではないかと思う。

つまるところ、ITに限らず製品やサービスに絶対の安心はないということ。人がやることなので、想定外とか手抜かりを見逃すとかいうことは必ずあるということを前提に付き合わざるをえない。「面白いなー」「便利だなー」で無邪気にアプリ収集に邁進したり、どっかの紹介やランキング上位を真に受けて突進するのは危ういと心がけるべきだ。

特に、なにかの記事や本での紹介は実質広告に過ぎないケースは多いし、ランキングというのは噂を流したり人海戦術でダウンロードしたりすることで簡単に上位に上がってくるものだ。ランキング操作も広い意味では「ステマ」の一種といえるだろう。詐欺の片棒担いだ「ステマ」有名人をあげつらう前に、「それは本当に必要なのか」と自分に問う習慣をつけるほうが、人生のいろいろな場面で余計なトラブルを避ける上でも役に立つはずだと言っておきたい。