Xperia Z1 と PS4 予約した

先週、Xperia Z1PS4 を立て続けに予約した。

Xperia Z1

予約したのはキャリアが au なんで au 版。まだ未発表な docomo 版には Xperia Z1f なんていう、Z1 のコンパクト版が用意されるらしい。正直、docomo うらやましい。でも、au だと iPhone と競合しそうなサイズの機種は出ないという噂。「あーなるほど」とか思った。

この噂を見たのはグローバル版が発表され、まだ au 版が未発表だった9月頭。この瞬間から Xperia Z1 の購入を検討することにした。でかいとは思うんだけれども、もう au で Android な人は5インチ液晶行くしかないじゃん、と。

で、店頭で同じ 5 インチ液晶の Xperia UL をいろいろ触ってみる。うん、でかい。片手でキーボード打つの大変。でも、確かにでかい画面は説得力がある。4.3インチ液晶の Xperia acro HD と比べ、これはいって(操作性)こい(画面サイズ)でチャラになるレベルかも知れない。そして何よりも、もう Xperia acro HD には飽きたし動作の重さにも耐えられない。

最後に「自作アプリの FULLHD(xxhdpi)機での動作チェックにもなるじゃん!」という理由付けもした。もう Xperia Z1 を購入しない理由がない。au からの発表を待って 10月2日に即 au ショップで予約したという形。発売は 10月下旬らしい。正直、かなり楽しみです。

PS4

PS1 には飛びついた。PS2 世代は飛びついたハードはなかったけど DC、PS2、GC、Xbox1、この順番で結局全部買った。PS3 世代は Xbox360 のが発売早かったからそれに飛びついた。PS4 世代は... PS4 に飛びついて間違いないよね!

ってことで PS4 予約した。先行予約には決済が必要で「約5カ月先の4万円もするゲーム機の決済今からするとかどうなの?」って若干思ったけど、発売日に欲しい衝動を前にすると、それはほんの小さな問題でしかなかった。超楽しみ。Xperia Z1 とどっちが楽しみか?と言われると PS4 のが楽しみ。早く DS4 触ってみたい。

ただし、問題点がひとつ。ローンチに買うソフトを何にするか? とりあえず初回限定版を予約したから KNACK とかいうアクションゲームのダウンロード権は付いてくる。「本体だけ買っても遊ぶゲームないじゃん!」とはならない。

だからと言ってこれ1本でいいかというと... そもそも発売日当日はダウンロード遅そうじゃない? 買って初期設定したらすぐにゲーム開始したい。それにはディスク版のゲームが必要になる。

候補はこんな感じ?

  1. バトルフィールド 4 (BF4)
  2. コール オブ デューティ ゴースト (CoD:G)
  3. KILLZONE SHADOW FALL (KZSF)
  4. アサシン クリード4 ブラック フラッグ (AC4)
  5. ウォッチドッグス (WD)

このなかでいちばん可能性が低いのは AC4。アサクリは3作くらいやったけど、結構好きなシリーズ。が、もういいかなと思う自分もいる。

同じUBIの WD は動画を見ても何がなんだかよくわからないゲーム。現代版アサクリ?新規IPってところに引かれもするし、不安も感じる。どうなのこれ。

BF4 と CoD:G は人気 FPS の続編。両シリーズとも経験済みだけに安心感はある。弱点は AC4 もそうなんだけど、これらのゲームは年内に PS3 版が発売されるということ。PS3 で2013年に発売済みのゲームのグラフィック良くなった版を2014年2月下旬に買うってのはどうなの... という気がどうしてもしてしまう。

この問題がなくて PC ゲームをやらない人にとって次世代感をいちばん感じさせてくれるタイトルが KZSF ってことになるかと思う。静止画を見ても動画を見てもこのゲームがいちばんきれいに見える。問題は KZ シリーズはゲーム的に普通ってこと。悪くないんだけど... 普通。同じ FPS なら BF か CoD シリーズのが好き。

ってことで、候補のどれもが決め手に欠ける。今のところ... KZSF か WD かな... あーまよう。

ConoHa VPS での CentOS 6.4 + nginx + php-fpm + Zend Framework 1系

さて、ConoHa VPS で CentOS 6.4 + nginx + php-fpm という環境を構築してみよう。ちなみに、動かすシステムは Zend Framework 1系で作ってあって、アクセスを /index.php に rewrite してあげる必要がある。このへんのことも書く。

nginx のインストール

ConoHa VPS で標準インストールされてる CentOS 6.4 には EPEL リポジトリが最初から追加してあった(/etc/yum.repos.d/epel.repo)。なので yum list | grep nginx とすると nginx 1.0 系のパッケージが見つかる。でもこれは古い。

最新の nginx を yum でインストールするには yum に nginx のリポジトリを追加してあげるといいらしい。/etc/yum.repos.d に nginx.repo という名前で以下のテキストファイルと作ってあげる。


# vi /etc/yum.repos.d/nginx.repo

($brush:plain)
[nginx]
name=nginx repo
baseurl=http://nginx.org/packages/centos/$releasever/$basearch/
gpgcheck=0
enabled=1

nginx.repo を保存したら yum で nginx の最新版がインストールできる。


# yum list | grep nginx
nginx.x86_64                            1.4.2-1.el6.ngx                 @nginx

1.4.2 というのが当時の最新版だった。さて、インストール。


# yum install nginx

php-fpm のインストール

php-fpm は yum で簡単にインストールできる。


# yum install php-fpm

ちなみに、php-fpm の他にインストールした php 関連のパッケージは以下


# yum list installed | grep php
php.x86_64                           5.3.3-23.el6_4                     @updates
php-cli.x86_64                       5.3.3-23.el6_4                     @updates
php-common.x86_64                    5.3.3-23.el6_4                     @updates
php-devel.x86_64                     5.3.3-23.el6_4                     @updates
php-fpm.x86_64                       5.3.3-23.el6_4                     @updates
php-gd.x86_64                        5.3.3-23.el6_4                     @updates
php-mbstring.x86_64                  5.3.3-23.el6_4                     @updates
php-mysql.x86_64                     5.3.3-23.el6_4                     @updates
php-pdo.x86_64                       5.3.3-23.el6_4                     @updates
php-pear.noarch                      1:1.9.4-4.el6                      @base
php-pecl-apc.x86_64                  3.1.9-2.el6                        @base
php-xml.x86_64                       5.3.3-23.el6_4                     @updates

apc もインストールしてる。

さて、nginx と php-fpm を構成しよう。

/etc/php-fpm.conf はデフォルトのまま。

/etc/php-fpm.d/www.conf


; user/group を nginx に変更
user = nginx
group = nginx

; ConoHa の 1GB プランなので以下の設定で様子を見る
pm = dynamic
pm.max_children = 15
pm.start_servers = 5
pm.min_spare_servers = 5
pm.max_spare_servers = 10
pm.max_requests = 500

/etc/nginx/nginx.conf


http {
    ~略~

    # localhost (127.0.0.1) からのアクセスを識別する
    geo $lh {
        default       0;
        127.0.0.1/32  1;
    }

    # サーバーの詳細を出力しない
    server_tokens off;
}

/etc/nginx/conf.d/default.conf


server {
    listen       80;
    server_name  localhost;

    # バッファサイズを変更 8k → 16k
    proxy_buffering    on;
    proxy_buffer_size  16k;
    proxy_buffers      8 16k;

    # ドキュメントルートを /data/www/html にする
    root   /data/www/html;

    # インデックス設定
    index  index.php index.html;

    # ドキュメントルートの構成
    location / {
        # localhost (127.0.0.1) からのアクセスをログに残さない
        if ($lh) {
            access_log  off;
        }
        # ファイルがなかったら /index.php にリライトする
        if (!-e $request_filename) {
            rewrite ^.*$ /index.php last;
        }
    }

    # php スクリプトの構成
    location ~ \\.php$ {
        # localhost (127.0.0.1) からのアクセスをログに残さない
        if ($lh) {
            access_log  off;
        }
        # /etc/php-fpm.d/www.conf の listen の値を指定
        fastcgi_pass   127.0.0.1:9000;
        # インデックス設定
        fastcgi_index  index.php;
        # パスをドキュメントルートと同じにする
        fastcgi_param  SCRIPT_FILENAME  /data/www/html$fastcgi_script_name;
        # これはテンプレートと思う
        include        fastcgi_params;
    }
}

上記設定ファイルで、Zend Framework 1系用の rewrite がうまくいってる。ただし、運用したてなのでパフォーマンスのチューニングはまだ途中... という感じ。php-apc の設定とあわせて、うまいところを見つけてあげないとなーと。

何かの参考になれば。

ConoHa を使うことにした

たまに重いことがあるロリポップで運用していた Web サーバーを移管したいなと思うようになった。ちなみに www.koji27.com ではなく別のサーバー。www.koji27.com は長らくホスティングしていたサーバーからロリポップに移管させたばかりだし、アクセスも少ないし特別なことしてないしこのままでいい。

そのサーバーは php でバリバリサービスを提供しているので... もうちょっとなんか別のサーバーにしたいなと思った。アクセスもどんどん増えてるし。

もっと値段の高いレンタルサーバーにするとか、いっそ PaaS にしちゃえば?とか、いや、そもそも VPS で自分で環境構築するとかどうよ?とか、いろいろ考えた。

基本、ssh で接続できて apache + mod_php が動けばいい。メールもしてなければ MySQL も使っていない。これだったら VPS で自分で環境構築しても負担は少ないんじゃ? って思うようになってきた。VPS はサーバーとしての環境の構築と維持を自分でする必要があるけど、個人向けに安くなっている物もある。

で、新しい VPS に飛びついてみようかなと思った。GMO の ConoHa ってやつ。

紹介ページになんかアニメキャラが出てくるけど、中身はいたって普通(?)の VPS じゃないかと。コンパネにまでキャラは入りこんでいない。Microsoft のクラウドガールみたいな感じにしたいのかなとか思った。まあ、そこはどうでもいい。意味不明なキャラがでてくる Web 系サービスはロリポップで慣れた。

個人用としては金額的にも中身的にも新しいとい点でもなかなかの魅力的なサービスだと思った。さて、とりあえずは15日の無料期間を使って環境構築してみよう。

課金のタイミングは VPS を作成して、無料期間(15日)が終了した時らしい。アカウントを登録しただけでは課金されない。そして、作成した VPS も無料期間中に削除すれば課金されない。同時に 5 台の VPS という制限はあるみたいだけど、何度でも無料体験できるっぽい。

さて、VPSを作ってみよう。OS は標準で使い慣れた CentOS 6.4 の 64bit 版が入る。初期設定は ここ とか ここ を参考にした。とりあえず、リモートからの root ログインは禁止した方がいいと思う。ちなみに、SELinux は無効化されていた。まあ、これはこれでいいかな...

VPS には最初から apache(httpd) が入っていた。自動起動にはなっていなかったけど。そして、postfix がなぜか自動起動されていた。postfix は使わないので停止。アンインストールは... まあ、今はしなくてもいいか。

※追記2014/02/27
postfix は停止しない方がいいようだ。今は動かしてる。

基本、パッケージのインストールは全部 yum でしている。ソースからインストールとかは維持していくのが面倒。yum update でいいじゃないかと思う。

CentOS で apache + mod_php の環境は簡単に構築できる。ConoHa の VPS 最小プランだと、/ は 18GB しか容量がなく、/data に 80GB くらいがマウントしてある。80GB は /var にマウントしてくれればいいのに... とか思わなくもないが、マウントポイントはそのままに、httpd の DocumentRoot を /data 以下に作ることにした(たとえば /data/www/html にするとか)。

さて、httpd の起動も確認できたし自前のシステムをインストールして動かしてみよう。どんな感じかな... お、ロリポップより動作がきびきびしている。これ、いいんじゃない?

まあ、約1000円/月のサービスだし、約600円/半年のロリポップより遅かったらこまるんだけどね...

その他いろいろ実験してみた結果。VPS だとリソースが許す限り cron を自由に設定できるし、自前システムの構成的に cron を使って定期的にキャッシュを作ってあげるとユーザーの快適度も上がるし、1000円/月くらいだったら広告費で十分稼げるし、仮想であってもサーバー1台自由にできるってのはやっぱり魅力的だし... ConoHa への移行を決定することにした。

さて、移行が決定したのでテストで作った仮想サーバーはいったん削除。新しい仮想サーバーを作って、それを移行先サーバーとして構築すべく、15日の無料期間をフルに活用してやろう。そして... どうせ VPS で自前で環境構築するなら apache + mod\_php じゃなくて、最近流行り(?)の nginx + php-fpm にしてやろう。とか考えた。

で、今は nginx + php-fpm で環境作ってロリポップから移行して数日... という感じ。チューニングもいろいろしたし、システムの体感速度は良くなっている。リソース的にも今のアクセス数だったら全然余裕。増えてくアクセスにもこれなら十分対応できそう。

だからと言って「apache + mod\php より nginx + php-fpm のが全然いい!」 ってワケでもないとは思う。だってこれを機会にシステム側のチューニングもしたし。cron でキャッシュもしてるし。なんといっても apache + modphp は情報もノウハウもいっぱいあるし。nginx + php-fpm はまだ日本語の情報少ない。ただ、構築してみての満足感は高い!

ってことで、ConoHa VPS での CentOS 6.4 + nginx + php-fpm + Zend Framework 1系 という組み合わせでの構成例次回書く。

Volley で画像キャッシュ

Android 用の Volley なるライブラリの存在を知った。

調べてみるといろいろと便利そうだ。特に、画像を HTTP でダウンロードしてくるところなんて超簡単になりそう。早速フォーミュラニュースまとめ読みのフォトギャラリーに使ってみることにした。その時のメモ。

(1) ディスクキャッシュのサイズを指定して RequestQueue を作成

「Android Volley」でググって出てくるサンプルは大体以下のように RequestQueue を作成している。


mRequestQueue = Volley.newRequestQueue(getApplicationContext());

Volley.java と DiskBasedCache.java を見ればわかるが... これだと 5MB しかディスクキャッシュを使わない。画像キャッシュの場合どうなの?もう少し多くてもいいんじゃない?

と、なるとまず Volley.java の newRequestQueue() メソッドは使わない。newRequestQueue() メソッドのソースを参考に、以下のようなメソッドを作成すればいい。


public static RequestQueue newRequestQueue(Context context, int cacheSize, HttpStack stack) {
    File cacheDir = new File(context.getCacheDir(), DEFAULT_CACHE_DIR);

    String userAgent = \"volley/0\";
    try {
        String packageName = context.getPackageName();
        PackageInfo info = context.getPackageManager().getPackageInfo(packageName, 0);
        userAgent = packageName + \"/\" + info.versionCode;
    } catch (NameNotFoundException e) {}

    if (stack == null) {
        if (Build.VERSION.SDK_INT >= 9) {
            stack = new HurlStack();
        } else {
            // Prior to Gingerbread, HttpUrlConnection was unreliable.
            // See: http://android-developers.blogspot.com/2011/09/androids-http-clients.html
            stack = new HttpClientStack(AndroidHttpClient.newInstance(userAgent));
        }
    }

    Network network = new BasicNetwork(stack);

    RequestQueue queue = new RequestQueue(new DiskBasedCache(cacheDir, cacheSize), network);
    queue.start();

    return queue;
}

public static RequestQueue newRequestQueue(Context context, int cacheSize) {
    return HttpUtils.newRequestQueue(context, cacheSize, null);
}

ポイントは new DiskBasedCache(cacheDir, cacheSize)。DiskBasedCache のインスタンスを作成するとき、元のソースは new DiskBasedCache(cacheDir) となっている。DiskBasedCache のソースを見ればわかるが、このコンストラクタはディスクキャッシュサイズにデフォルトの値を使用する。ディスクキャッシュサイズを指定可能なコンストラクタを使って DiskBasedCache クラスのインスタンスを作ってあげればいいだけ。

ってことで、今回作った newRequestQueue を使って RequestQueue のインスタンスを生成すれば、ディスクキャッシュサイズなんて思いのまま。


// キャッシュサイズに 32MB を指定
mRequestQueue = newRequestQueue(getApplicationContext(), 32 * 1024 * 1024);

(2) 画像の取得に成功/失敗したときに独自のコードを実行したい

さて、実際に Volley で画像を取得してみるとする。ググると出てくるサンプルには NetworkImageView を使う例と ImageLoader を使う例がある。

GridView なんかに小さいサムネイル画像を読み込む... なんて場合は NetworkImageView をそのまま使ってもいいかも知れない。GridView の ArrayAdapter で convertView が使いまわされたときの対処もこれだと簡単だ。内部でちゃんと cancelRequest() を呼んでくれている。

だがしかし、NetworkImageView は ImageView の拡張だ。TouchImageView とか、独自の ImageView に画像をロードしたい場合は素直に ImageLoader を使おう。これでも AsyncTask 使うよりずっと楽だ。


ImageListener listener = ImageLoader.getImageListener(
    touchImageView, 
    android.R.drawable.ic_menu_rotate, 
    android.R.drawable.ic_delete);
mImageLoader.get(\"http://hogehoge/image.jpg\", listener);

こんなサンプルをググると発見することができる。ImageListener を ImageLoader の getImageListener() メソッドで作成している。当たり前だが、これだと画像のロード後に自前のコードを実行するとかできない。具体的にはロード後に ProgressBar を非表示にしたい... とか。

そんなときは ImageListener を自前で実装すればよい。ImageLoader.getImageListener() のソースを見てみればいい。実に簡単なコードだということが分かる。これくらいなら処理ごとに getImageListener() を自前で作ったってそんなコストにはならない。


public static ImageLoader.ImageListener getImageListener(final ImageView view, 
    final ProgressBar progress, final int defaultImageResId) {
    return new ImageListener() {
        @Override
        public void onErrorResponse(VolleyError error) {
            if (defaultImageResId != 0) {
                view.setImageResource(defaultImageResId);
            }
            view.setVisibility(View.VISIBLE);
            progress.setVisibility(View.GONE);
        }

        @Override
        public void onResponse(ImageContainer response, boolean isImmediate) {
            if (response.getBitmap() != null) {
                view.setImageBitmap(response.getBitmap());
                view.setVisibility(View.VISIBLE);
                progress.setVisibility(View.GONE);
            }
        }
    };
}

とかね。ポイントは onResponse() だと思う。この onResponse() は、キューの実行中に何度か呼ばれる。なので、response.getBitmap() が != null だったときだけ、ProgressBar を非表示にしてあげればいい。

「response.getBitmap() がずっと null だったら ProgressBar が表示されたままになるじゃん!」 ってことに関しては問題にしなくてもいい。以下の場合は onErrorResponse() が呼ばれるのを確認している。

  • requestUrl のホストが見つからない。
  • requestUrl が 404 not found.
  • requestUrl が画像じゃない。

...こんな感じで。

Yahoo! 天気 アイコン一覧

晴れ 晴れ 晴れ 晴れ 晴れ
晴時々曇 晴時々曇 晴時々曇 晴時々曇 晴時々曇
晴時々雨 晴時々雨 晴時々雨 晴時々雨 晴時々雨
晴時々雪 晴時々雪 晴時々雪 晴時々雪 晴時々雪
晴後曇 晴後曇 晴後曇 晴後曇 晴後曇
晴後雨 晴後雨 晴後雨 晴後雨 晴後雨
晴後雪 晴後雪 晴後雪 晴後雪 晴後雪

曇り 曇り 曇り 曇り 曇り
曇時々晴 曇時々晴 曇時々晴 曇時々晴 曇時々晴
曇時々雨 曇時々雨 曇時々雨 曇時々雨 曇時々雨
曇時々雪 曇時々雪 曇時々雪 曇時々雪 曇時々雪
曇後晴 曇後晴 曇後晴 曇後晴 曇後晴
曇後雨 曇後雨 曇後雨 曇後雨 曇後雨
曇後雪 曇後雪 曇後雪 曇後雪 曇後雪

雨 雨 雨 雨
雨時々晴 雨時々晴 雨時々晴 雨時々晴 雨時々晴
雨時々曇 雨時々曇 雨時々曇 雨時々曇 雨時々曇
雨時々雪 雨時々雪 雨時々雪 雨時々雪 雨時々雪
暴風雨 暴風雨 暴風雨 暴風雨 暴風雨
雨後晴 雨後晴 雨後晴 雨後晴 雨後晴
雨後曇 雨後曇 雨後曇 雨後曇 雨後曇
雨後雪 雨後雪 雨後雪 雨後雪 雨後雪

雪 雪 雪 雪
雪時々晴 雪時々晴 雪時々晴 雪時々晴 雪時々晴
雪時々曇 雪時々曇 雪時々曇 雪時々曇 雪時々曇
雪時々雨 雪時々雨 雪時々雨 雪時々雨 雪時々雨
暴風雪 暴風雪 暴風雪 暴風雪 暴風雪
雪後晴 雪後晴 雪後晴 雪後晴 雪後晴
雪後曇 雪後曇 雪後曇 雪後曇 雪後曇
雪後雨 雪後雨 雪後雨 雪後雨 雪後雨

Recent articles

Categories

Monthly archive