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との対比はやや有益かもしれない。

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

Android Wearを買ったけど、まだ今ひとつだった

買ったのはLGのG Watch。買って10日ほどしか経過したが、今のところ微妙だという感想。

普段使いのスマートフォンはNexus5とiPhone5sで、もちろん前者と組み合わせて使っている。割と何でもGoogleに預けてしまう生活をしているので、比較的いいユーザーだと思う。

現状において、この端末は結局何であるのかと言ったら「Google Cardの出先」

Google Cardを便利と感じるなら、それなりに使い物になると思う。しかし、個人的にはGoogle Card自体も情報量がやや不足していると思うし、スマートフォン本体であればそのままブラウザを起動して情報の本体が乗っているウェブにアクセスできたりするが、Wearではそれができない。あくまで提供されるのがとっかかりでしかないので単体で閉じないため不便である。

当初期待していたのは、自転車に乗っている時のナビや周辺地図を見るという用途。しかし、実際に使ってみるとナビは本体での表示よりも情報が不足しているし、連携もなんだかおかしい。音声コマンドでナビをリクエストすると本体で検索は始まるが、実際にWear側に表示されるまでにひどくタイムラグがある。通信帯域が狭いのか、消費電力を抑えるために間欠的にしか同期をしないようになっているのか、わざわざ音声コマンドで入力するぐらいなのですぐにほしい情報が表示されないというのはかなり不満。

現在のメニュー構造はGoogl CardをUIの中心にしようとしている意図が強くあるようで、アプリの起動はかなり深い場所にあって使いにくい。これはサードパーティのランチャーで代替できるのだけど、そもそもアプリがまだまだどういった作りにすればいいかというノウハウが不足している感じが強い。物理的に小さいので文字入力は基本的に無理で、上下左右のスワイプを主要な操作方法としているのだけど、これだけで操作を完結するには知見がもう少し溜まっていく必要を感じる。

今のところ、Androidの通知が飛んでくるだけのゴツイ時計として使っている。

ロブ・パイクによるプログラミングの5つのルール

出典 http://users.ece.utexas.edu/~adnan/pike.html

  • ルール1 プログラムのどこで時間を使うようになるかを事前に知ることはできない。 ボトルネックは意外な場所に発生するので、どこにボトルネックがあるかを証明するまで、とやかく言ったり速度にハックしないように

  • ルール2 測定せよ。 測定し終えるまで速度のチューニングをしないこと、さらにコードの一部が他の部分よりも圧倒的であるときを除いて。

  • ルール3 凝ったなアルゴリズムはnが小さいときは遅い、そして大抵の場合でnは小さい。凝ったアルゴリズムは大きな定数を持つ。頻繁にnが大きくなると分るまでは、凝ったことをしないこと。(そしてnが大きくなる場合でもルール2をまず適用すること)

  • ルール4 凝ったアルゴリズムは単純なものよりバグが入りがち、そして実装難易度が高い。 単純なアルゴリズムだけでなく単純なデータ構造を使うこと。

  • ルール5 データが最も重要である。 正しいデータ構造と編成を選択すれば、アルゴリズムは自明のものとなります。アルゴリズムではなく、データ構造こそがプログラミングの中心です。

パイクのルール1と2はトニー・ホーアの有名な格言「早まった最適化は諸悪の根源である」の言い換え。ケン・トンプソンの「疑わしい場合は力技でいけ」はパイクのルール3と4の言い換え。 ルール3、4はデザイン哲学KISSの例。ルール5は以前フレッド・ブルックスが「人月の神話」で述べた。 ルール5はよく「スマートオブジェクトを使う愚かなコードを書く」と略される。


ロブ・パイクって誰やねん、という人はWikipediaの彼のページをどうぞ。最近だとgolangを作った人です。

UNIXプログラミング環境 (海外ブックス)

UNIXプログラミング環境 (海外ブックス)

プログラミング作法

プログラミング作法