Android Wearを使って1年ちょっと経過して

2014年の7月ごろに購入したようなので、ほぼ1年が経過していた。この1年はほぼ毎日着けていたのでその感想など

更新されるOS

無法地帯のAndroid端末とは異なり、今のところAndroid WearはOSの更新がGoogle主導でコントロールされている。このため、最初期モデルであるLG G Watchについても、最新のOSが随時降ってくる。ありがたいことである。

差分は地味な変更が多いが、細々とした変更が蓄積してきてかなり良いものになってきている印象。最初はアプリのランチャーすらなかったのだ。

画面を常時点灯していたらバッテリーが持たないが、画面にタッチをしないと表示されないとなると時計として不便だ。あるときから腕の捻りのモーションを検出して画面を自動点灯する機能が入った。発想は分かるが、実際にはモーションの認識精度があまりよろしくなく結局、右手で触って起こしていた。最新のバージョンになってこの辺りの挙動がかわって、表示をモノクロにした上で画面が最低輝度で常時点灯するようになったようだ。表示デバイスは液晶なので、黒の表示にすると電池消費の面ではむしろ不利だと思うのだが、結局この方式に落ち着くのかもしれない。この状態でも24時間ほどはバッテリーがもつようだ

5.1から入った機能の一つに腕の捻りだけでカードのスクロールをするというものがある。素早く外へ捻り、ゆっくり内側に戻すと次のカードへ移るというもの。ゆっくり外側へ捻ってから素早く戻すと前のカードに戻る。画面をタッチするとどうしても両腕が塞がれるので、片手だけで操作出来るようにするという発想は理解できるが、個人的にはあまり実用的とは思わなかった。捻りの速さの高低という情報量の小さいもので操作するのが非常に迂遠だった。

Watch Face

最初は色々なWatch Faceをダウンロードしては試していたが、表示内容などの点で不満があったりデザインがイマイチだったりして、デフォルトのWatch Faceの一つを使い続けていた。あるときBehance Watch Facesという Watch Faceを試しところ、シンプルなデザインと写真家が撮った写真が日替わりで使われるコンセプトが気に入ったためこれを常用することにした。

Behance Watch Faces - Google Play の Android アプリ

通知受け取りデバイスとして

当初はGmailのクライアントしか対応しておらず、既読フラグを立てることすらできなかったがInboxのアプリがWear対応になり、Wear上での操作で内容の確認と既読フラグを立てられるようになって実用になった。

Androidの通知を受け取るだけなら、SonyのSmartBand Talkというデバイスもある。こちらは電子ペーパーを使っていることもあり、薄くて電池の寿命が長い。同僚が使っていたが、通知を受け取るだけならこちらの方が良さそうである。

ソニー Bluetooth3.0 リストバンド型活動量計　ブラックSONY　SmartBand Tal k SWR30-B

ソニー Bluetooth3.0 リストバンド型活動量計　ブラックSONY　SmartBand Tal k SWR30-B

ハードウェアの問題

今更LG G Watchを新規で買おうという酔狂な人はいないと思うが、このモデルは充電用の接点で問題を起こしがちなのが非常に不満。

発売直後に汗によって腐食するという問題があり、それはOSのアップデートで対応されたとしているが、夜に充電台に置いたが朝になってみると上手く充電できないという状態が何度も有った。接点を軽く濡らしたり黒鉛の粉を付けると充電できたので、恐らく接触抵抗が高すぎたのだろう。しきい値付近をフラフラしていたのか、断続的に充電されるようなことも有った。

時計は耐水性を求められるので、独自の非接触充電方式のApple WatchやQiによる非接触充電のMoto 360などが良いのではないかと思った。有線ならばほかと共用できるmicroUSBで充電できるのが便利だと思う。旅行などに持って行くき、充電台を荷物から減らせるため。

実用アプリ

通知を受けたいだけならPebbleや先のSmartBand Talkのようなデバイスがあるわけで、Wearならではのアプリケーションが欲しい。

唯一実用的だと思ったのは、Google Keepによるチェックリスト。買い物などのリストを作っておいて、チェックして行くというもの。リストを見るだけのためにスマートフォンを取り出す必要がないので便利。買い物リスト程度の情報量ならあの画面サイズでも十分に読めるし、チェックを入れるという操作も無理がない。先日の夏コミでは役に立った。

まだ実際に使う場面はないが、録音アプリがあったので入れておいた。やや隠し録音っぽいが、スマートフォンを取り出さずに録音できるのは有用な局面がありそう。

まとめ

発売から1年を経過して、Android Wearは買いであるかという問いに対する答えとしては「まだ微妙」と言わざるをえない。ただ、実売が2万円前後になってきているので、この価格ならばそろそろ買っても良いかもと思える。

これに対してApple Watchは一番下のモデルでも4万円ほどするので、現在の用途に対しては高過ぎると思う。

YAPC::Asia 2015に参加してた

参加したセッションについての簡単な感想だけ

MatzさんによるTBD

Rubyの話はあまりなく、Streemの話を中心に。 個人的に残った発言は最後の質問時間でのRubyが型宣言をどうしていくかという話で「ユーザープログラムは最終的に数十行程度であるべき(なので型宣言を必須とすることはない)」というもの。言語開発者というのはコンピューティングがどうなっていくか、あるいはどう有るべきかという長期的なビジョンを持って設計しているのだなというのが垣間見えて興味深かった

Yet Another Perl Cooking

真空調理法の話。Perlはほとんど関係がない 面白かったのは、質問時間で真空調理法以外の方法についても再現性があるような調理法について質問。3Dプリンタとか画像認識(Kinectなど)を組み合わせていけたら夢が広がる。 その後、ヨーグルティアとCooking for Geeksの本を買いました。

Google Cloud Platformの謎テクノロジーを掘り下げる

あまりディープな話はなかった。GCPのセッションを何度か聞いているので、ほぼ既知の内容

我々はどのように冗長化を失敗したのか

失敗した話って貴重ですよね。だいたいプレゼンの題材にする話って綺麗にまとめて今後の課題とか言って誤魔化しがちなので

Perlでゼロから作るコンテナ

コンテナ技術の構成要素についての根本的な仕組みについて、Perlを使って解説するセッション。 LXCやDockerを使っていると良きに計らってくれるその下回りの話。コンテナを二重に起動することでコンテナ内での仮想的なroot権限とユーザー権限を入れ子にしているのかー、とか勉強になった。

MySQLで2億件のシリアルデータと格闘したチューニングの話

大量のデータをわりと貧弱なスペックで扱った話。 INSERT時にBuffer poolから溢れる話の原理面は松信さんの本に詳しい。

Linux-DB システム構築/運用入門 (DB Magazine SELECTION)

Linux-DB システム構築/運用入門 (DB Magazine SELECTION)

現場あるあるではあったけど、ちゃんと定量的なデータを残していたのはありがたい。

ソーシャルゲームにおける AWS 移行事例

オンプレからAWSへの実際の移行を紹介してくれたセッション スケーリングとかそういう話はあまりなかったけど、少人数と短期間での移行だなー

Profiling & Optimizing in Go

Goのパフォーマンスチューニングの実践解説 ライブデモが中心だったけど、Emacsを中心にした手際が流石だ。CPUプロファイルは使ったことがあって便利なのは知っているけど、メモリプロファイルも便利そう。

FFXIのメディア発表の結果

大外れでした。

あたったのは、PS2が終了するというぐらいか。これは誰の予想でも確実に出る内容だったのであたったとはいえないレベル。

Game Watchの記事にはクラウドゲーミング化も選択肢だったのではという記述が有ったので、全くない線ではなかったのだろうけどサービスレベルで提供するための仕組みとかいろいろ問題が有ったのだろうと想像している。ランニングコストは小さく見積もっても今の月額料金にプラスで1000円ほどは必要だろうし、それにしたって先細りだろうから大規模なインフラ投資判断は出来ない。今まで残っているユーザーだから恐らく利用率も高いので、設備集約率も上げられないだろうし。

発表にあったスマートフォン版は個人的には興味がないし、既存や元ユーザーから強い拒否反応が出るのは理解できる。しかし、スマートフォンという今一番旬なプラットフォームで販売したらどれ位反響があるのかはちょっと経過を見守りたい。シナリオや世界観がいいと言われていたFF11がそこを引き継ぐ後継タイトルでちゃんとヒットするかを

完全に後出しだけど、結局スクウェア・エニックスとしてはサーバーサイドの運用コストが馬鹿にならないのでわりと早期にインフラを畳みたいのかなと思った。PS2/Xbox360の終了予告と同時に大規模VUをしないという明言までしているので、現行サーバからは早期に人を追い出したいのだろう。数年前のDB MagazineにFF11の内部システムが掲載されていたが、ワールド毎にOracleとNetAppを使ったかなり高コストな作りだった。サービス開始時点を考えると悪くない選択肢だったと思うが、今となってはもっと集約率を高めたり、ライセンス料の安価なDBMSを使う方法も有っただろう。DQXやFF14がまさにそのようになっている。

もちろん作り直す決断をする機会は幾度も有ったはずで、やって来なかった結果ではある。しかしFF14という明確に後継と位置づけられるタイトルの開発が走っている中で作り直しは出来る判断ではないというのは、理解できる。

結局何をやっても先細りを回避出来ないという判断だったのだろう。

FFXIのメディア発表会

FFXIが3月19日にメディア発表をするというのが気になる

game.watch.impress.co.jp

個人的な予想としては

  • PS2のサポート終了
  • 代替としてクラウドゲーミング対応
  • 「まだもうちょっとだけ続くんじゃ」

あたりが可能性として考えられる。さすがに色々と開発ロードマップが見えている最中にクローズ予告はないだろう。F2Pへの転換という可能性も考えられるが、それにてもサポートプラットフォームはどうにかしないと今のままでは難しいのではないか。F2Pとクラウドゲーミングへの両立はリソース的に厳しいだろうし、やるとしたらどちらかだろう。

クラウドゲーミング対応になったら、価格にもよるけど、Windowsタブレットで無理矢理動かすメリットが薄くなる。個人的にはAndroidをクライアントにしてプレイできると非常に嬉しい。Nexus PlayerやSHIELD Consoleを買う理由にもなるし。クラウドゲーミングへの伏線は一応あって、 シンラ・テクノロジーという100％子会社を作る前の技術デモの段階で動作させていたアプリケーションの一つがFFXIのクライアントなのだ。ただ、クラウドで動かすにしてもFFXIは色々と作りが古過ぎるという気がしないでもない。使っているDirectXが古いし、十分なスケーラビリティが確保できないのでないかなと。

ちなみに元おすすめプレーヤであって現役ではないです。

ODROID-C1を買った

ODROIDという韓国のワンボードコンピュータやタブレットなんかのシリーズの新作であるC1というモデルを買った。

f:id:futsu-9:20141223004636j:plain

Raspberry Piよりざっと7倍ぐらいCPUが速くて、メモリの容量が2倍、USBのポートも2倍、NICも1Gbpsまで対応という代物。何故か赤外線の受信もできたりする。CPUの性能も良くなっているので、XBMCを入れてメディアプレーヤとして使うことを想定しているからだろうか。 GPIOなどの汎用的なインターフェースも基本的なところは揃っている。しかし、ここまで速いと組込みとして使うとちょっともったいない気もしてくる。

ここ2年ぐらいで、この種のワンボードコンピュータが増えているが、最新のモデルだけあって最新のスペックということである。これでお値段たったの、$35

ストレージはMicroSDか専用のeMMCモジュール。後者の方がパフォーマンスは良好なようだ。 届いてから半日ほど色々と触ったが、どうもブートのプロセスが不安定なようでリブートから帰ってこないことがときどき有った。サポートフォーラムでも初期に用意されたスクリプトの不具合が報告されたりその修正がされたりと、出荷直後のドタバタは若干あるようだ。私は元から持っていたMicroSDにUbuntuを入れて使っていたので、専用のeMMCモジュールを使えば安定した動作となっていた可能性もある。

Cortex-A5自体はスマートフォンではローエンド向けのプロセッサだけど、ワンボードコンピュータとしてはかなり速い部類になる。実際リモートからログインして使っている分にはかなり実用になると感じた。RPiではセルフコンパイル環境を作っても遅くて作業する気にならなかったが、これならばこの上で全ての作業をしても不満はない。

muninまわりの話

もう動かし始めて1年ぐらい経つのだけど、最近また構成を変えたのでリソース監視システムmuninの話を備忘録代わりに記録しておく。 muninはperlで書かれた監視システム debianではmuninという中央の集計システムと、監視対象側で動くmunin-nodeというパッケージに別れている。この2者はtcp/4949ポートで独自のテキストプロトコルで通信する。

munin

muninはcronから5分に一回起動し、データ収集とrrdへの反映(munin-update)、監視閾値の適用(munin-limit)、htmlの生成(munin-html)、グラフの生成(munin-graph)をやる。私の設定では後半2つはcronからは実行しない。 設定ファイルは /etc/munin/munin.conf にまとまっている。各種ファイルのあるディレクトリやrrdの出力先などはそのままで、以下の3行のみ追記した。

graph_strategy cgi
cgiurl_graph /cgi-bin/munin-cgi-graph
html_strategy cgi

意味としては、htmlとグラフの生成をcronからの実行時には行なわないという事と、htmlに表示するグラフのパスを変更するもの。

nginx

htmlの表示にはnginxを使った。標準のvhostの設定に以下を追記する。

        location /munin/static/ {
                alias /etc/munin/static/;
        }

        location /munin/ {
                fastcgi_split_path_info ^(/munin)(.*);
                fastcgi_param PATH_INFO $fastcgi_path_info;
                fastcgi_pass unix:/var/run/munin/fcgi-html.sock;
                include fastcgi_params;
        }
        location ^~ /cgi-bin/munin-cgi-graph/ {
                fastcgi_split_path_info ^(/cgi-bin/munin-cgi-graph)(.*);
                fastcgi_param PATH_INFO $fastcgi_path_info;
                fastcgi_pass unix:/var/run/munin/fcgi-graph.sock;
                include fastcgi_params;
        }

それぞれ、htmlから参照する静的なcssやロゴなどを/etc/munin/static以下を参照させるもの。2つめのブロックは/munin/以下のパスについてmunin-cgi-htmlへと渡すための設定。cgiとの間はunix domain socket経由のfcgi プロトコルで行なう。最後のブロックがグラフの画像生成をmunin-cgi-graphへ行なわせるためのもの。/cgi-bin/munin-cgi-graph以下へのアクセスをfcgiに投げる。 この設定ではもちろん、cgi自体はnginxとは独立して上げる必要があるので以下のような内容をシェルスクリプトなどに記述して実行する。

sudo spawn-fcgi -s /var/run/munin/fcgi-graph.sock -U www-data -u www-data -g www-data -F 1 /usr/lib/munin/cgi/munin-cgi-graph
sudo spawn-fcgi -s /var/run/munin/fcgi-html.sock -U www-data -u www-data -g munin -F 1 /usr/lib/munin/cgi/munin-cgi-html
start-fcgi

いずれもプロセスはひとつだけしか上げていないが、マルチプロセッサなどで余裕がある場合は複数上げることも可能です。

munin-node

主な設定は /etc/munin/muni-node.conf だが、これ自体はアクセス制限やタイムアウト、プラグインのパターンぐらいしか書くことはない。 デーモンとして動作するので、設定変更は都度上げ直す必要があります。

munin-plugins

パッケージ名としてはmunin-plugins-coreやmunin-plugins-extra、munin-plugins-cなど どのpluginを使うかは/etc/munin/plugins/以下にシンボリックリンクを張ることで、有効にできる。pluginの中身はシェルスクリプトだったりするので見ればわかるが、configという引数で実行されたらどのようなグラフとして描画されたいかを答えたり、通常の結果は

user.value 558034
nice.value 394002
system.value 162008
idle.value 6494120
iowait.value 33914
irq.value 2
softirq.value 7757
steal.value 0
guest.value 0

みたいなラベルと数値のスペース区切りを行指向で返すだけでよい。 パッケージを入れるだけで多くのプラグインが自動的に配置されているが、追加でシンボリックリンクを張ることで項目を増やすこともできる。 シンボリックリンクの名前で監視対象を表現することもできる。例えばif_というプラグインをif_eth0とするとeth0についての監視項目となる。 シンボリックリンクの名前だけでは与えられない設定については/etc/munin/plugin-conf.d/munin-node.confに記述する。例えば監視対象がデータベースであったとき接続ユーザとパスワードが必要になるがそういう情報はここに記載する。[]をラベルとして実行ユーザやプラグインに渡す環境変数を書く。パスワードなどを書く関係上、rootとmuninグループでしか読めないようになっている。

munin-node-c

pluginがシェルスクリプトやperlで書けのは楽だけど、単純な処理一つでも結構なCPU時間を食う。これは非力なnodeは辛い。 perlのlwpで書かれていたのをfurlに書き変えたりgolangにしたりチマチマ直していたのだが、munin-nodeと主要なpluginをCで再実装された方が居た。 もちろん完全互換ではないが、munin-nodeが何をやっているかはこちらの実装を読んだ方が速いかもしれない。

Google Compute Engine本読んだ

Google Compute Engine入門 (アスキー書籍)

Google Compute Engine入門 (アスキー書籍)

現時点では恐らく唯一のGCPに関する日本語書籍。 内容の多くの部分がgcloudのコマンドの説明に費やされていたりするが、AWSとの対比はやや有益かもしれない。

しかし本を買ってまで読むほどかと言われたら、かなり疑問な内容だった。