ひだまりソケットは壊れない

id:nobuoka が情報系の話を書いたり日常の話を書いたりします

まじめなことを書くつもりでやっています。 適当なことは 「えっちなのはいけないと思います」 に書いています。

google-http-java-client 入門

Java で HTTP 通信するときのクライアントライブラリを何にするかいつも悩むのですが、最近 google-http-java-client が気になってたのでちょっと使ってみました。 汎用的に HTTP 通信ができればよい、というような用途にはちょうど良さそうです。

数年前からベータ版や RC 版としては存在していましたが、正式にリリースされたのは今年のようです。

google-http-java-client について

Google によって書かれた Java の HTTP クライアントライブラリです。

HTTP トランスポートの抽象化がされており、実際の HTTP 通信を行う低層のライブラリを選択できるのが特徴です。 例えば java.net.HttpURLConnection を使ったり、Apache HTTP Client を使ったりできます。

また、リクエストやレスポンスのコンテンツボディの XMLJSON のパースやシリアライズを行う機能も含まれており、便利です。

使用できる環境は、Java 5 以降の Java SE 環境や Java EE 環境、Android 1.5 以降などです。

ざっくりとした使い方

準備

使用するためには JAR ファイルをライブラリパスに追加するとか、Maven の依存関係管理に追加するとかする必要があります。 2014 年 11 月 8 日現在の最新バージョンは 1.19.0 で、Maven Central Repository に置かれています。

Gradle を使っているならば次のように依存関係を記述すればよいです。

repositories {
    mavenCentral()
}

dependencies {
    compile 'com.google.http-client:google-http-client:1.19.0'
}

HTTP リクエストを行う処理の全体の流れ

  1. HttpTransport オブジェクトを用意する。
    • これはアプリケーション全体で 1 つだけ存在すればよい。
  2. HttpTransportcreateRequestFactory メソッドを呼んで HttpRequestFactory オブジェクトを生成する。
  3. HttpRequestFactory から HttpRequest を生成する。
  4. HttpRequestexecute メソッドを呼び出してリクエスト実行、レスポンスとして HttpResponse を取得。
  5. レスポンスを処理したあと、終了処理。

サンプルコード

GET リクエストを投げてレスポンスボディを表示する例を Gist に置いてあります。 バージョン 1.19.0 を使用しています。

レスポンスのパース

HttpRequest#setParser メソッド を使って ObjectParser インターフェイスを実装したインスタンスをパーサーとして登録しておくと、レスポンスのパースを任せることができます。

ライブラリに含まれている ObjectParser の実装としては、JsonObjectParser クラスUrlEncodedParser クラス があります。

サンプルコード

/* 必要な import 文
import com.google.api.client.http.GenericUrl;
import com.google.api.client.http.HttpResponse;
import com.google.api.client.http.UrlEncodedParser;
import com.google.api.client.util.GenericData;
*/

// HttpRequest オブジェクトにパーサーを設定しておく。
// (req は HttpRequest オブジェクト)
req.setParser(new UrlEncodedParser());
// リクエスト実行。
HttpResponse res = req.execute();
try {
    // レスポンスのパースを行う。 (上で設定した UrlEncodedParser が使われる。)
    GenericData d = res.parseAs(GenericData.class);
} finally {
    // (以下略)

レスポンスのパース後のクラスを作る

上の例ではパース後のクラスとして GenericData を使用しましたが、どういうパラメータが渡ってくるかわかっている場合、それを受け取るためのクラスを用意しておいて、フィールドに値を設定させることもできます。

例えば、OAuth 1.0 Protocol の Temporary Credentials を取得するためのリクエストのレスポンスをパースする場合を考えてみましょう。 レスポンスの形式は 「oauth_token=xxxxx&oauth_token_secret=xxxxx&oauth_callback_confirmed=true」 というものであることはわかっているので、次のようなクラスでレスポンスを受け取ることができます。 @Key アノテーション をフィールドに付けることで、パースした結果を受け取るフィールドであることを示しています。

/* 必要な import 文
import com.google.api.client.util.GenericData;
import com.google.api.client.util.Key;
*/

// 必ずしも GenericData を継承する必要はないが、継承しておけばフィールドで定義されていないパラメータも受け取ることができる。
public class OAuthTemporaryCredentialResponse extends GenericData {
    @Key("oauth_token")
    public String identifier;
    @Key("oauth_token_secret")
    public String sharedSecret;
    @Key("oauth_callback_confirmed")
    public String callbackConfirmed;
}

そして、パース時にこのクラスを指定することでパース結果を OAuthTemporaryCredentialResponse オブジェクトとして受け取ることができます。

    OAuthTemporaryCredentialResponse d = res.parseAs(OAuthTemporaryCredentialResponse.class);
    System.out.println("identifier: " + d.identifier); // フィールドアクセスによりレスポンスの値にアクセスできる。

関連

RecyclerView と view type について (Android アプリ開発)

このエントリでは、ListView の進化版とも言われる *1 RecyclerView の view type について簡単に紹介します。 RecyclerView 自体については次のページを参照してください。

View type とは

View type が何であるかの公式的な説明は見当たらなかったのですが、要は 1 つの RecyclerView の要素として複数種類の View を使い分けるための仕組みです。

例えば、RecyclerView の中でコンテンツと見出しの表示要素 *2 を混在させたい場合、コンテンツと見出しを別の view type として扱うことで出し分けが容易になります。

他にも、リストの最後の項目として 「続きを読む」 というような項目を表示したい場合も通常の view type とは別の view type の項目として扱えば良いですね。

各項目の view type の指定方法

各項目の view type を指定するには、RecyclerView.Adapter#getItemViewType(int) メソッドをサブクラスでオーバーライドします。 デフォルト実装は常に 0 を返すというものですので、RecyclerView の中で単一種類の表示項目しか扱わない場合はオーバーライドする必要はありません。

View type の値は int 型です。 ドキュメントには、衝突することを避けるために id リソースを使うことを検討するように、と書かれています。

View type ごとの View の生成

RecyclerView.Adapter#onCreateViewHolder(ViewGroup, int) メソッド の第 2 引数として view type の値が渡されてきます。 なので、このメソッドの中で生成する view を view type ごとに変化させ、ViewHolder にセットすることになります。

ViewHolder が保持している view の view type を知る方法

RecyclerView.ViewHolder#getItemViewType() メソッド が、ViewHolder が保持している view の view type を返してくれます。 なので、RecyclerView.Adapter#onBindViewHolder(VH, int) メソッドの中などで view type を知りたいときはこのメソッドを使いましょう。

サンプルコード

複数 view type を使う Adapter のサンプルコードです。 (とりあえず動くという程度の簡単な実装です。)

package info.vividcode.android.example;

import android.support.v7.widget.RecyclerView;
import android.view.View;
import android.view.ViewGroup;
import android.widget.TextView;

public class MyRecyclerViewAdapter extends RecyclerView.Adapter<MyRecyclerViewAdapter.ViewHolder> {

    public static class ViewHolder extends RecyclerView.ViewHolder {
        public ViewHolder(View itemView) {
            super(itemView);
        }
    }

    @Override
    public ViewHolder onCreateViewHolder(ViewGroup parent, int viewType) {
        // view type に応じて生成する view を変える。
        // 今回はサンプルコードなので手軽に両方とも TextView にしている。
        // 実際にはここで生成する View を違うものにする。
        View v;
        if (viewType == 0) {
            v = new TextView(parent.getContext());
        } else {
            v = new TextView(parent.getContext());
        }
        return new ViewHolder(v);
    }

    @Override
    public void onBindViewHolder(ViewHolder holder, int position) {
        // view type に応じて処理を分ける。
        // 今回はどちらも TextView なので単にセットする文字列を変えている。
        if (holder.getItemViewType() == 0) {
            ((TextView) holder.itemView).setText("Even: " + position);
        } else {
            ((TextView) holder.itemView).setText("Odd: " + position);
        }
    }

    @Override
    public int getItemViewType(int position) {
        // サンプルコードなので手軽に position が偶数の項目と奇数の項目で view type を分ける。
        return position % 2;
    }

    @Override
    public int getItemCount() {
        return 10;
    }

}

これを Activityメソッド内で以下のようにして使えばとりあえず動きます。

    // recyclerView はどこかで既に定義されているとする。
    LayoutManager layoutManager = new LinearLayoutManager(this);
    recyclerView.setLayoutManager(layoutManager);
    recyclerView.setAdapter(new MyRecyclerViewAdapter());

*1:「ListView2」 とか呼ばれてるのをたまに目にします。 実際には ListView の代わりとして以外にも使えます

*2:当然ながら View の構造は別物になるはずですね

Cookpad と Zaim のオフィスにお邪魔してきました

東京に行く機会があったので Cookpad と Zaim のオフィスにお邪魔してきました。

場所は恵比寿ガーデンプレイスです。 (最近オフィスの移転がありました。) Google Maps で調べたら恵比寿駅から徒歩 8 分ぐらいでちょっと遠いかと思っていたのですが、実際に行ってみると駅からガーデンプレイスまで歩く歩道の設置された通路 (恵比寿スカイウォーク) があって、さほど距離は感じません。

f:id:nobuoka:20141008134437j:plain

おしゃれなレンガ造りの建物がある公園という感じで恵比寿ガーデンプレイスはなかなかいい場所でした!

f:id:nobuoka:20141008102404j:plain

Cookpad のオフィスは @rejaspotaro さんに案内してもらいました。 Cookpad のオフィスといえばキッチンがあることで有名ですが、話には聞いていても本物を見ると 「オフィスにこんなキッチンがあるのすごいなー」 と思わざるを得ませんでした。 開放的な広々した空間に大きな冷蔵庫やキッチンがどーんとあるのを見ると羨ましい限り! 家にもああいうキッチンが欲しいですねー。

オフィス内にはシャワールームやトレーニング器具もあって、あとは洗濯さえできればオフィスに住めるやん、って感じです。 開発者のいる部屋は間仕切りなしの広々した空間になっていて、そこにデスクがばーっと並んでいて人の多さを実感しました。 他に気になった場所は本棚のあるライブラリで、そこで勉強会などができるようになっていました。 本棚が結構小さかったので本は全部入るのかなーと心配したり。

Cookpad の見学の後は @rejaspotaro さんと一緒に Zaim のオフィスにお邪魔して閑歳さんやスタッフの方とお話させて頂きました。 働きだした年に閑歳さんのインタビュー記事を読んで、「働きながら個人プロジェクトを成功させている人もいるんだ!」 と思ったのが印象に残っているので、今回お会いできてうれしかったです。

Cookpad の会社内にオフィスがあるとは聞いていたのですが、思った以上に Cookpad との行き来が容易で驚きました。 人によるとのことでしたが、Cookpad の方との交流も多いようです。

その後は Cookpad と Zaim の Android アプリエンジニアの方々と技術交流。 私が Android アプリ開発からちょっと遠ざかっているのでこちらからあまり面白い話ができなかったのは申し訳ないところですが、トラッキング周りの課題の話やら、オーケストレーション層を設けて複数の HTTP リクエストをまとめたいというような話ができて参考になりました。 あと 「いやー、新しくやりたいことはあるんですけど人が足りなくてねー」、「奇遇ですねー、うちもですよー」 みたいな話をしたり。 「ソフトウェアエンジニアの転職は人づてになりがちだからそういう方向が良さそう?」、「とはいえソーシャル活動してない人で優秀な人もいるし、そういう人に興味を持ってもらうためには Wantedly なども効果があるかもしれない?」 とかとか。 難しいところです。

最後にお昼ご飯をご一緒させて頂きました。 ガーデンプレイスには食べるところがいろいろあっていいですね。 今回は 「関西から来てお好み焼きなんw」 と突っ込まれつつタワー最上階近くの千房でお好み焼き。 美味しゅうございました。

お世話になった皆様ありがとうございました。

ソフトウェアエンジニアを募集しています!

文中にも書きましたが、ソフトウェアエンジニア募集中とのことです! お世話になったので紹介します! 恵比寿ガーデンプレイスはなかなか働きやすそうな場所でしたよー。

もちろんはてなもソフトウェアエンジニアを募集しています! 京都だけでなく東京開発センターもあります! 興味のある方は是非お気軽に私にご連絡ください!!

発表資料: Android アプリ開発における Gradle ビルドシステム (京都 Android 勉強会 2014.08)

去る 8 月 23 日に株式会社はてな主催で行われた Android アプリ開発の勉強会 「京都 Android 勉強会 2014.08」 にて、Android アプリ開発と Gradle について喋ってきました。

Android Studio ではビルドシステムとして Gradle が採用されていますので、今後 Gradle を使う人は増えていくと思います。 Android Studio でビルドをするだけであればそれほど Gradle に詳しくなくても問題ないわけですが、せっかくなのでいろいろ便利に使っていきましょう、という主旨の発表でした。

発表内容は下のような感じで、Gradle を使ったことがない人にも 「Gradle でこういうことができる」 というのが伝わるように喋ったつもりです。 また、後半の方は Gradle を使って Android アプリのビルドをした人でも触ったことがない人もいると思いますので、Gradle を使っている人にも参考になったかもしれません。

  • Gradle と Android アプリのビルド
  • Gradle や Android Gradle plugin の機能の一部を紹介
    • ここら辺は知らなくても問題なく開発できるはずではあります
  • AAR パッケージについて
  • Gradle プラグインについて

勉強会では、Cookpad の @rejaspotaro さんが 「debug ビルドの時だけデバッグに便利なメニューを表示するようにしている」 とか、「社内でいくつか Gradle プラグインを作って便利に使っている」 という話を先にされていたので、そこら辺とからめて Gradle の話ができたのも良かったところです。

質疑内容

会場で 2 つほど (確か 2 つ) 質問がありましたので、ここにも書いておきます。

Gradle wrapper の更新

Gradle wrapper を使う場合、Gradle のバージョン更新はした方がよいのか、という質問でした。

Android Studio のバージョンアップにともなって必要な Gradle のバージョンも変わってきますので、Android Studio のバージョンアップに合わせてプロジェクト内の Gradle (Gradle wrapper) のバージョンも更新する必要があります。 最近の Android Studio では、Gradle のバージョンが古い場合に警告を出してくれて、GUI 上でぽちぽち操作すると自動的にバージョンが更新されるはずです。

Gradle の欠点

発表資料の中で 「Groovy のことを理解するまでデバッグ等が大変」 と書いていますが、それ以外に不便な点などはあるか、という質問でした。

Gradle 自身の欠点というわけではないですが、Eclipse での Android アプリのビルドと比べて、一部を変更してビルドし直すというのが Android Studio でのビルド (あるいは直接コマンドライン上で Gradle を使った場合のビルド) では時間がかかってしまうというのがあります。 私は今のところあまり細かい変更でビルドし直すということをしないようにすることでなんとかしていますが、UI の変更などでは細かく調整したいということもあってなかなか不便ということでした。

Gradle をオフラインモードにすると速くなるという話もあります。 (ちゃんと試してません。)


Docker 入門 #1 — Windows に Boot2Docker をインストールして既存イメージを扱ってみる

Docker 使えるようにならないとなー、ということで、まずは Docker を使える環境を準備して、ユーザーガイドをちょっと読んでみた。 既存イメージを使ってコンテナの生成をするなどの操作をするところまで。 完全なる入門者向け (あるいは自分用) だけどメモしておく。

Docker のバージョンは 1.1.2 を使用した。

Docker についての参考文献

そもそもの Docker についての説明はこのエントリでは行わない。 次の記事が参考になる。

Windows での Docker 環境の構築

Windows ユーザーでない場合はそれぞれの環境用のインストールガイドを参照のこと。

Docker Engine は Linux カーネルの機能を使用しているので、Windows の上に直接 Docker 環境を構築することはできない。 VirtualBox なりなんなりで仮想マシンとして Linux マシンを Windows 上に起動する必要がある。

Boot2Docker というアプリケーションが Docker より提供されているので、(Docker Engine 用の仮想マシンを立てるつもりなら) これを使うのが便利である。 Boot2Docker を使うことで、VirtualBox 上に Docker 環境用の仮想マシンをインストールし、Docker デーモンを走らせることができる。

Boot2Docker のインストールで VirtualBox もインストールできるようなので、まだ VirtualBox をインストールしていない人でもいきなり Boot2Docker をインストールして良い。 次のエントリも参考になる。

使い方

「Boot2Docker Start」 というのがスタート画面のアプリケーション一覧に追加されているはずなので、これをクリックする。 すると、VirtualBox に Docker 用の仮想マシンが登録されて、Linux のインストールなどが実行される。 そして仮想マシンが起動して、そこに SSH 接続される。

この仮想マシン上で docker コマンドを使い、Docker コンテナを作ったりする。

また、インストール時にパスを通すかどうかのオプションを選択できるが、パスを通しておけば boot2docker コマンドが使えるようになる。「Boot2Docker Start」 を使わなくても、PowerShell を開いて boot2docker コマンドを使うことで、仮想マシンの操作ができる。

他のコマンドは boot2docker --help で調べられる。

Docker を使ってみる

ユーザーガイドに従って Docker を使ってみる。 これ以降は、基本的に boot2docker ssh して、仮想マシン上でコマンドを実行するものとする。

ユーザーガイドとは別にオンラインチュートリアルもあって、こっちの方が最初は良いかもしれない。

アプリケーションの Docker 化 (?)

docker run コマンド
$ sudo docker run ubuntu:14.04 /bin/echo 'Hello world'
Hello world

上のようなコマンドを実行すると、何やらダウンロードしてきて、最終的に 「Hello world」 が出力される。 何をしているかというと、「ubuntu:14.04」 というイメージからコンテナを新たに生成し、そのコンテナ上で 「/bin/echo 'Hello world'」 というコマンドを実行している。

指定されたイメージは、まず Docker ホスト上で探される。 そこで見つからなければ、Docker Hub 上で探される。 今回の場合、「ubuntu:14.04」 というイメージは Docker Hub からダウンロードされる。

新たに生成されたコンテナは、指定のコマンドを実行し終えると停止 (?) するようである。 (コンテナ自体は残っている。 後で出てくるが、docker ps コマンドに -a オプションを渡すと、停止しているコンテナも表示される。)

-t オプション *1-i オプション *2 を渡すことで、対話型コンテナを立ち上げることもできる。

-d オプションでコンテナのデーモン化ができる。 docker run -d ... コマンドを実行すると、長い文字列が表示される。 これはコンテナ ID である。 コンテナの名前は (明示的に指定しなければ) 自動的につけられる。

docker ps コマンド

docker ps コマンドで、実行中のコンテナの情報が表示される。 コンテナ ID やコンテナ名などが確認できる。

上で書いたように、-a オプションを付ければ停止中のコンテナも表示される。

docker logs コマンド

docker logs {container} コマンドを使えば、コンテナ内部の標準出力を表示できる。 {container} としては、コンテナ ID とコンテナ名のどちらかを指定できるっぽい。

docker stop コマンド

docker stop {container} コマンドを使えば、動いているコンテナを止めることができる。

コンテナの扱い方

バージョン確認

docker version コマンドで、Docker クライアントと Docker サーバーのバージョン情報が表示される。 Go のバージョンや Git コミットのリビジョンも表示される。

Docker クライアントのコマンド一覧

オプションなしの docker コマンドで、docker コマンドが受け付けるアクション一覧が表示される。 各アクションについては、docker {action} --help コマンドでヘルプを表示できる。

コマンド一覧については Web 上のヘルプを参照してもよい。

Web アプリケーションを Docker 内で動かす
$ sudo docker run -d -P training/webapp python app.py

上記コマンドで、トレーニング用の web アプリケーションを Docker 内で動かすことができる。 「training/webapp」 というイメージは Docker Hub からダウンロードされる。

-P オプションは、コンテナ内部で必要なネットワークポート (exposed port) をホストのそれにマップするように Docker に伝えるためのものである。 上のコマンドを実行した後、docker ps -l コマンド *3 を実行すると、PORTS の項に以下のような表示が出るはずである。

PORTS
0.0.0.0:49155->5000/tcp

ローカル Docker ホストの 49155 ポートが、コンテナの 5000 ポートにマップされていることがわかる。 コンテナ側のどのポートを露出させるかを指定する方法は、後で (イメージ作成方法のところ) で説明される。 ホスト側のポートは 49000 から 49900 の間 (high port と表現されている) から自動的に選ばれる。

-P オプションの代わりに、docker run コマンドに -p {container_port} オプションを渡すことで、コンテナの指定のポートをホスト側の high port にマップすることもできる。 -P オプションは、コンテナの exposed port をホストの high port にマップするものであるが、-p オプションはコンテナ側の指定のポートが exposed port かどうかは関係ないようである。

また、-p {host_port}:{container_port} という形式で、コンテナの指定のポートを、ホストの指定のポートにマップすることもできる。

ちなみに、Windows 上で Boot2Docker を使っている場合は、WindowsPowerShell 上で boot2docker ip コマンドを実行することで、Docker ホストの IP アドレスを取得できる。

docker port コマンド

docker port {container} {private_port} コマンドで、指定のコンテナの指定のポートがどのポートにマッピングされているかを知ることができる。

Web アプリケーションのログ表示

docker logs コマンドの -f オプションは、tail コマンドの -f オプションのようなものである。

コンテナのプロセス

docker top {container} コマンドで、指定のコンテナのプロセス一覧を見ることができる。

コンテナの詳細

docker inspect {container} コマンドで、指定のコンテナの詳細情報を JSON 形式で得ることができる。

さらに、-f オプションを使うことで、特定の情報のみを取りだすこともできる。

$ sudo docker inspect -f '{{ .NetworkSettings.IPAddress }}' nostalgic_morse
172.17.0.5
コンテナの再起動

停止されたコンテナは、docker start {container} コマンドで再度起動できる。 実行中のコンテナの再起動は docker restart {container} コマンド。

そういえばコンテナが停止される際に、コンテナ内のプロセスがどうなるのか、とか、再起動時にはどうなるのか、とかわかってない。

コンテナの削除

停止されたコンテナは docker rm {container} コマンドで削除できる。

そういえば同僚が 「要らなくなったコンテナのごみ掃除が大変だ!」 とか言ってたけど、これのことなのかなー。

今回はここまで

既存のイメージを使うところまではこんな感じ。 さらにイメージをビルドしたりする話が続くけど、それはまた別のエントリに。

*1:新しいコンテナ内に pseudo-tty または terminal を割り当てる。

*2:コンテナの標準入力に引っ掛けることで対話型のコネクションを張る。

*3:「-l」 オプションは、最後に開始されたコンテナの情報を表示するためのオプション。