garbagetown

個人の日記です

Hadoop を 30 分で試す

ややチート気味ですが Hadoop を 30 分で試すことができたのでお知らせします。

経緯

先日のブログ に書いた通り、Cloudera QuickStart VM はとても便利なのですが、メモリをめちゃくちゃ喰うので一般的なご家庭にあるスペックのマシンではまともに動きません。

なんでそんなにメモリを喰うかと言うと、おそらく Hive やら何やらごっちゃり入っているからで、とりあえず MapReduce を動かしてみたいだけの人には、少々オーバースペックである感が否めません。

お仕着せの環境が肌に合わないからと言って自分で環境をこしらえようにも、初心者に疑似分散とか YARN とか言われてもどうしていいか分かりませんし、Oracle JDK のインストールが地味に面倒です。

このような実情を身に染みて感じたので、以下の内容を参考に Cent OS 上に疑似分散モードの YARN 環境を作る Ansible Playbook を書いて Ansible Galaxy にアップロードしてみました。

ご用意頂くもの

一般的なご家庭に Linux 物理マシンなどあるわけがないので、以下では仮想マシンを使用します。

また、VirtualBoxVagrant, Cent OS の box などを用意済みとしている点に若干キユーピー 3 分クッキング的な突っ込みどころを感じますが、意識の高いエンジニアであれば、これくらいの備えは常識の範囲内としても差し支えないでしょう。

手順

以下、実施する手順を掛かる時間の目安と併せて紹介します。

Mac OS で動かした際のログを紹介していますが、Windows でも動くと思います。プロキシの配慮は省略しているので、企業 LAN 内などで試す際はがんばってください。

仮想マシンの用意 (5 分)

適当なディレクトリを掘って Vagrant 仮想マシンを初期化します。box の名前は自身の環境に合わせて読み替えてください。

$ mkdir cdh5; cd cdh5
$ vagrant box list
CentOS-6.4-x86_64           (virtualbox, 0)
(snip)
$ vagrant init CentOS-6.4-x86_64

Vagarnt が仮想マシンに割り当てるメモリ容量はデフォルトで 480 MB で、さすがにこれでは MapReduce が動きません。Vagrantfile には 1024 MB を割り当てる設定例が記載されているので、コメントアウトを外して設定を有効にします。

$ vi Vagrantfile
$ grep -A 1 -B 9 modifyvm Vagrantfile
  # Provider-specific configuration so you can fine-tune various
  # backing providers for Vagrant. These expose provider-specific options.
  # Example for VirtualBox:
  #
  config.vm.provider "virtualbox" do |vb|
  #   # Don't boot with headless mode
  #   vb.gui = true
  #
    # Use VBoxManage to customize the VM. For example to change memory:
    vb.customize ["modifyvm", :id, "--memory", "1024"]
  end

設定が済んだら仮想マシンを起動します。2, 3 分あれば起動すると思います。

$ vagrant up
(snip)
==> default: Machine booted and ready!
==> default: Checking for guest additions in VM...
==> default: Configuring and enabling network interfaces...
==> default: Mounting shared folders...
    default: /vagrant => /Users/garbagetown/dev/vagrants/cdh5

仮想マシンが起動したらログインしましょう。以降の手順はすべて Cent OS 上で実施します。

$ vagrant ssh
Welcome to your Vagrant-built virtual machine.

Ansible のインストール (3 分)

残念なことに Ansible は Cent OS の標準リポジトリには含まれていないので、EPEL リポジトリを追加します。

[vagrant@localhost ~]$ sudo rpm -ivh http://ftp.riken.jp/Linux/fedora/epel/6/x86_64/epel-release-6-8.noarch.rpm
(snip)
   1:epel-release           ########################################### [100%]

詳細を理解していないのですが、このままだと Ansible のインストールに失敗するので baseurl と mirrorlist のコメントを入れ替えます。

[vagrant@localhost ~]$ sudo vi /etc/yum.repos.d/epel.repo 
[vagrant@localhost ~]$ sudo grep -n fedora /etc/yum.repos.d/epel.repo 
3:baseurl=http://download.fedoraproject.org/pub/epel/6/$basearch
4:#mirrorlist=https://mirrors.fedoraproject.org/metalink?repo=epel-6&arch=$basearch
12:baseurl=http://download.fedoraproject.org/pub/epel/6/$basearch/debug
13:#mirrorlist=https://mirrors.fedoraproject.org/metalink?repo=epel-debug-6&arch=$basearch
21:baseurl=http://download.fedoraproject.org/pub/epel/6/SRPMS
22:#mirrorlist=https://mirrors.fedoraproject.org/metalink?repo=epel-source-6&arch=$basearch

Ansible をインストールします。2, 3 分あればインストールできると思います。

[vagrant@localhost ~]$ sudo yum -y install ansible
(snip)
Installed:
  ansible.noarch 0:1.8.2-3.el6                                                                                                                                                                             

Dependency Installed:
  PyYAML.x86_64 0:3.10-3.1.el6             libyaml.x86_64 0:0.1.3-4.el6_6            python-babel.noarch 0:0.9.4-5.1.el6  python-crypto.x86_64 0:2.0.1-22.el6     python-crypto2.6.x86_64 0:2.6.1-1.el6 
  python-httplib2.noarch 0:0.7.7-1.el6     python-jinja2.x86_64 0:2.2.1-2.el6_5      python-keyczar.noarch 0:0.71c-1.el6  python-paramiko.noarch 0:1.7.5-2.1.el6  python-pyasn1.noarch 0:0.0.12a-1.el6  
  python-setuptools.noarch 0:0.6.10-3.el6  python-simplejson.x86_64 0:2.0.9-3.1.el6 

Complete!

CDH のインストール (20 分)

いよいよ CDH をインストールします。

と言っても、時間は掛かりますが手順は単純です。まず、ansible-galaxy コマンドを使って playbook をダウンロードします。2, 3 分かかると思います。

[vagrant@localhost ~]$ sudo ansible-galaxy install garbagetown.cdh5_yarn_pseudo
- downloading role 'cdh5_yarn_pseudo', owned by garbagetown
- downloading role from https://github.com/garbagetown/cdh5_yarn_pseudo/archive/master.tar.gz
- extracting garbagetown.cdh5_yarn_pseudo to /etc/ansible/roles/garbagetown.cdh5_yarn_pseudo
- garbagetown.cdh5_yarn_pseudo was installed successfully
- adding dependency: williamyeh.oracle-java
- downloading role 'oracle-java', owned by williamyeh
- downloading role from https://github.com/William-Yeh/ansible-oracle-java/archive/master.tar.gz
- extracting williamyeh.oracle-java to /etc/ansible/roles/williamyeh.oracle-java
- williamyeh.oracle-java was installed successfully

Ansible Galaxy の依存性解決の機能で Oracle JDK をインストールする playbook も落ちてきているのが分かると思います。便利ですね。

続いて localhost に対してプロビジョニングを行う playbook を書きます。CDH 5 は今のところ Oralce JDK 7 でないと動かないので、変数で指定します。

[vagrant@localhost ~]$ vi main.yml
[vagrant@localhost ~]$ cat main.yml
- hosts: 127.0.0.1
  connection: local

  roles:
    - garbagetown.cdh5_yarn_pseudo

  vars:
    - java_version: 7

あとはこの playbook を実行するだけです。pycrypto に関する警告が出ますが、ひとまず無視してください。

JDK と CDH5 のインストール、Hadoop 周りのディレクトリ作成に少し時間が掛かりますが、15 分くらいで完了すると思います。

[vagrant@localhost ~]$ ansible-playbook main.yml
[WARNING]: The version of gmp you have installed has a known issue regarding
timing vulnerabilities when used with pycrypto. If possible, you should update
it (i.e. yum update gmp).

PLAY [127.0.0.1] ************************************************************** 

GATHERING FACTS *************************************************************** 
ok: [127.0.0.1]
(snip)
TASK: [williamyeh.oracle-java | get JDK 1.7 tarball (as RPM file)] ************
changed: [127.0.0.1]
(snip)
TASK: [garbagetown.cdh5_yarn_pseudo | Install CDH 5 with YARN on a Single Linux Node in Pseudo-distributed mode] ***
changed: [127.0.0.1]
(snip)
TASK: [garbagetown.cdh5_yarn_pseudo | Create the directories needed for Hadoop processes] ***
changed: [127.0.0.1]

TASK: [garbagetown.cdh5_yarn_pseudo | Start YARN] ***************************** 
changed: [127.0.0.1] => (item=hadoop-yarn-resourcemanager)
changed: [127.0.0.1] => (item=hadoop-yarn-nodemanager)
changed: [127.0.0.1] => (item=hadoop-mapreduce-historyserver)

PLAY RECAP ******************************************************************** 
127.0.0.1                  : ok=17   changed=15   unreachable=0    failed=0

サンプルの実行 (5分)

以上で疑似分散モードの YARN 環境ができたので、Installing CDH 5 with YARN on a Single Linux Node in Pseudo-distributed mode の "Running an example application with YARN" に従ってサンプルアプリケーションを実行してみましょう。

まず、HDFS 上にログインユーザがジョブを実行するためのディレクトリを作って権限を与えます。

[vagrant@localhost ~]$ sudo -u hdfs hadoop fs -mkdir /user/$USER
[vagrant@localhost ~]$ sudo -u hdfs hadoop fs -chown $USER /user/$USER

続いて、サンプルアプリケーションで grep するために、ローカルファイルシステムから HDFS 上に適当なファイルをコピーします。ここでは Hadoop の設定ファイルを HDFS 上に put しています。

[vagrant@localhost ~]$ hadoop fs -mkdir input
[vagrant@localhost ~]$ hadoop fs -put /etc/hadoop/conf/*.xml input

最後に、環境変数を設定してサンプルアプリケーションを実行します。

[vagrant@localhost ~]$ export HADOOP_MAPRED_HOME=/usr/lib/hadoop-mapreduce
[vagrant@localhost ~]$ hadoop jar /usr/lib/hadoop-mapreduce/hadoop-mapreduce-examples.jar grep input output23 'dfs[a-z.]+'
(snip)
15/02/22 13:51:39 INFO mapreduce.Job:  map 0% reduce 0%
15/02/22 13:51:56 INFO mapreduce.Job:  map 100% reduce 0%
15/02/22 13:52:18 INFO mapreduce.Job:  map 100% reduce 100%
15/02/22 13:52:20 INFO mapreduce.Job: Job job_1424612668205_0002 completed successfully
15/02/22 13:52:20 INFO mapreduce.Job: Counters: 49
(snip)
    File Output Format Counters 
        Bytes Written=244

MapReduce ジョブが終わってログがずらっと出たら、出力結果を確認します。

[vagrant@localhost ~]$ hadoop fs -ls output23
Found 2 items
-rw-r--r--   1 vagrant supergroup          0 2015-02-22 13:52 output23/_SUCCESS
-rw-r--r--   1 vagrant supergroup        244 2015-02-22 13:52 output23/part-r-00000
[vagrant@localhost ~]$ hadoop fs -cat output23/part-r-00000
1   dfs.safemode.min.datanodes
1   dfs.safemode.extension
1   dfs.replication
1   dfs.namenode.name.dir
1   dfs.namenode.checkpoint.dir
1   dfs.domain.socket.path
1   dfs.datanode.hdfs
1   dfs.datanode.data.dir
1   dfs.client.read.shortcircuit
1   dfs.client.file

HDFS 上にコピーした Hadoop の設定ファイルから、サンプルアプリケーションに渡した正規表現に合致する文字列を grep できていることが分かります。

まとめ

  • Cloudera の QuickStart VM は、とても便利だが、一般的なご家庭にあるマシンでは動かすのは厳しい
  • Cloudera の Quick Start Guide は、とても丁寧に書かれているが、動作モードや OS ごとに読むべき箇所が異なり、初心者が目的のドキュメントに辿り着くことは困難
  • Hadoop を 30 分で試そうと思ったら Ansible にハマって三日くらい掛かったけど気にしない
  • Ansible Galaxy の依存性解決は便利

以上です。

Hadoop を 10 分で試そうとしたら 2 時間 49 分かかった話

みなさんビッグデータしてますか?本日は懺悔のブログです。

経緯

世間から遅れること五年、そろそろぼくもビッグデータしたいなと思って Hadoop 周りを調べてみたところ、エコシステムがもりもり成長中で Web 上の情報は新旧入り乱れているわ、書籍の情報はあっという間に古くなるわで、ビッグデータ界の Hello World 的な WordCount を試すのもひと苦労という有様でした。

そんな折、"2014年版 Hadoopを10分で試す(1) | Tech Blog" というブログを発見してキタコレ!と試してみたところ、いろいろあって 結果的に 10 分では試せなかったので、冗談半分で

などとツイートしたところ、なんとご本人様に補足され、

という窒息するほど土下座したい案件となりましたので、本日ここに「ビッグデータ素人がノーガードで突撃した場合、どこにどれくらい時間が掛かるのか」などを紹介することで、懺悔の言葉と代えさせて頂ければと思います。

試した手順と掛かった時間

以下の環境で試しました。

  • Windows7 64bit
  • メモリ 8GB
  • プロキシサーバ有り社内 LAN
  • 7-ZipVirtualBox はインストール済み

ダウンロード

Google Chrome で以下のサイトにアクセスして VirtualBox 版の VM をダウンロードしました。

"Download for VirtualBox" ボタンをクリックすると E メールアドレスやらを求められるので、素直に入力して Submit ボタンを押したところ、いきなり JavaScript エラーが発生。

f:id:garbagetown:20150211000553p:plain

"geoplugin_city が定義されていない" というエラーのようですが、自宅の Chrome で試してみると再現しないので、なんらかの拡張機能とプロキシサーバの組み合わせがまずいのかもしれません。

そもそも Chrome なんて気取ったブラウザを使っているのが良くないので、安定の Internet Explorer でアクセスしたら無事に VM をダウンロードすることができました。

f:id:garbagetown:20150211001613p:plain

スクリーンショットを撮り直してみたところ、残り時間 2 時間 52 分でした。他の仕事をしながら気長に待ちましょう。

展開

ダウンロードした VM7-Zip で圧縮されているので、展開して中身を取り出します。

f:id:garbagetown:20150211002416p:plain

7-Zip で開いたらデスクトップなどの適当な場所にコピーしましょう。マシンスペックにもよると思いますが、自分の環境では 15 分くらい掛かりました。

f:id:garbagetown:20150211002553p:plain

インポートと起動

仮想マシンイメージが取り出せたら、VirtualBox にインポートします。ここでは残り時間 1 分などと表示されますが、実際は 3 分くらい掛かります。

f:id:garbagetown:20150211012304p:plain

インポートが完了したら、いよいよ VM を起動します。5 分くらい掛かります。

f:id:garbagetown:20150211012512p:plain

プロキシの設定とサンプルアプリケーションの準備

VM が起動すると Firefox が立ち上がるのですが、なんだか画面が変です。

f:id:garbagetown:20150211012839p:plain

プロキシサーバが設定されていないので画像などが取得できていません。機能的な影響はありませんが、モチベーションに影響するのでプロキシサーバを設定しましょう。

なお、quickstart.cloudera は localhost を見るのでプロキシ対象外に指定する必要があります。

f:id:garbagetown:20150211013213p:plain

プロキシの設定が完了したら、ブックマークバーから Hue を選んで cloudera/cloudera でログインします。

f:id:garbagetown:20150211013939p:plain

Hue にログインしたら、"2014年版 Hadoopを10分で試す(1) | Tech Blog" を参考に Hue のインストールウィザードを進めてサンプルアプリケーションをインストールします。10 分くらいあればインストールできると思います。

f:id:garbagetown:20150211014247p:plain

サンプルアプリケーションの実行

いよいよ Hadoop を試します。Hive クエリを実行してみましょう。

f:id:garbagetown:20150211014800p:plain

Hive クエリが MapReduce ジョブに変換される様子がログに出力され、処理が完了すると自動的に結果画面が表示されます。

f:id:garbagetown:20150211015009p:plain

エンジニア的にはおおおスゲーと素直に喜べますが、ふだん見慣れている SQL に似た Hive クエリだけに、えらいひとには Hadoop の威力よりも MapReduce の遅さの方が目立ってしまうんじゃないかなあと余計なことも思いました。

Hive と比べると Impala はすごく速いです。他にも Sqoop や Pig などのサンプルもあって遊ぶには持ってこいですが、お仕事で使う場合はこれらツールの特色をきちんと理解して、冗長化などにも気を付けながら採用を検討する必要があり、それなりに敷居は高いと感じました。

その頃タスクマネージャは

いっぱいいっぱいでした。

f:id:garbagetown:20150211023038p:plain

まとめ

  • Hadoop 周辺は進化の速度が速く、Web や書籍の情報をもとに検証環境を構築することがむずかしい
    • 最初は Apache Hadoop, Cloudera, Hortonworks, MapR の違いも分からない
    • スタンドアロン、疑似分散、完全分散とか言われても困る
    • MRv1 と YARN は何が違うのか分からない
  • CDH QuickStart VM を使えば、仮想マシン起動開始から 10 分で CDH に含まれるいろいろなツールを試すことができる
    • ただし仮想マシンを起動するまでに 3 時間以上かかる
    • あとメモリめっちゃ食う

あれこれ悩みながらの手作業だと 3 時間どころか 3 日掛かっても環境を作れないので、取っ掛かりとして QuickStart VM を試すのは良いと思います。

ただし、仮想マシンの使用メモリが 4 GB に設定されているので、メモリを 8 GB 以上搭載しているマシンでないと厳しいです。

OS やメーラ、ブラウザ、IDE などを立ち上げて開発することを考えると 8 GB マシンでも際どいので、現在は VMHadoop 専用端末にインストールして VirtualBox のブリッジアダプタで社内 LAN に繋いでいます。この辺りの手順も気が向いたら書くかもしれません。

それではみなさん良いビッグデータを。

ドキュメント翻訳の裏側

この記事は Play framework Advent Calendar 2014 - Adventar の四日目です。空いているようなので埋めます。

五日目の立候補者がいないので誰か書いてください。

新規翻訳と差分翻訳

Play Framework のドキュメントは日々更新され続けています。いずれは原文の更新を検知して、すぐさま翻訳する仕組みを作れたらと思いますが、今のところ翻訳プロジェクトでは Play Framework の新しいバージョンがリリースされるたびに、手作業で地道に更新内容を確認しています。

更新内容には大きく分けて、ドキュメントの追加、更新、削除の三種類があり、削除されたドキュメントはもちろん翻訳対象外ですし、追加されたドキュメントは何も考えずに翻訳すればいいのですが、難しいのが更新されたドキュメントです。

原文に変更がない箇所まで再度翻訳するのは無駄なので、翻訳プロジェクトでは以下のように対策しています。

issues のラベルと diff 表示

前回の記事 で、しれっと「ファイル名などで issues を検索します」と書いたとおり、翻訳プロジェクトでは翻訳対象のドキュメントを issues に登録しています。

このとき、更新されたドキュメントの場合は、以下のように update ラベルを付けて、issues の本文に diff の結果を貼り付けています。

f:id:garbagetown:20141205005026p:plain

リリースごとに大体 120 個くらいの issues を登録するので、さすがに手作業では厳しく、issues を登録するツール を作って対応しています。

翻訳対象のドキュメントを issues 化するというアイディアは @masahito さんのもので、当時は Pyhton で書かれていたようです。diff を含める機能を追加したかったのですが、ぼくが Python を書けないので Java で作り直しました。

これにより、このドキュメントが更新されたものであることと、更新された内容がひと目で分かるようになりましたが、差分が多くて面倒くさそうな issues がいつまで経っても翻訳されないという副作用も産み出しています。

なお、GitHub API クライアントには Jenkins 作者でもある @kohsukekawa さんの kohsuke/github-api を使わせて頂きました。

翻訳文のコピー

続いて、変更がなかった箇所の対策です。

上記した通り、再度翻訳するのは無駄なので、以前は手作業でコピーしていたのですが、@seratch_ja さんに「これ苦行ですね」と言われたので、翻訳文をコピーするツール を作りました。

@seratch_ja さんには Scala で書くと言ったのですが、ぼくが Scalaツールを書けるようになるまでの間に Play Framework 5 くらいになってしまいそうだったので、Java で書いています。

それから、少しくらい間違っていてもすぐに直せばいいじゃない、という間違ったアジャイル開発信者のような大らかな気持ちで作ったので、ひとつのドキュメント内に同じ文章が複数回登場するとコメントアウトが壊れたりと、微笑ましい動作をします。直します。

まとめ

本家サイトで公開されている翻訳プロジェクトなどと聞くと敷居が高く感じられるかもしれませんが、実際は手作業による温もり感溢れるプロジェクトであることがお分かり頂けたのではないでしょうか。

本来は Google Translation Toolkit などを使うべきだったのですが、過去の経緯 (主に無知) などにより、上記した方法で何とか運用しています。

運用改善にご協力頂いた @masahito さん、@seratch_ja さん、それから紹介が遅れましたが 翻訳ガイドライン を書くように薦めてくださった @kawachi さん、そして GitHub API クライアントを OSS で公開してくださっている @kohsukekawa さんに、この場を借りて改めてお礼を申し上げます。

本当にありがとうございます。今後ともよろしくお願いいたします。以上です。

ドキュメント翻訳の手順

この記事は Play framework Advent Calendar 2014 - Adventar の三日目です。

四日目の立候補者がいないので誰か書いてください。

おまえ誰

2010 年 4 月から Play Framework のドキュメントを翻訳しています。

以前は http://www.playframework-ja.org/ に Play 1.2 で書いたアプリをデプロイして翻訳ドキュメントを公開していましたが、現在は https://www.playframework.com/documentation/ja/ で公開しています。

が、まったく手が足りていないので、この場を借りてドキュメント翻訳の具体的な手順を紹介することで、ひとりでも多くの人に手伝ってもらえたらいいなと思っています。

概要

Play Framework 2.x のドキュメントは Markdown 記法 で書かれており、 GitHub で管理されています。

翻訳版も GitHub で管理しており、こちらの例 のように、原文をコメントアウトして翻訳文を併記しています。

ちなみに Play Framework 1.x のドキュメントは textile 記法 で書かれていますが、こちらはコメントアウトができないので、こちらの例 のように翻訳文だけ書いていました。

playframework.com は翻訳版の GitHub リポジトリを定期的にポーリングしていて、翻訳版リポジトリに取り込まれた内容は、すぐに playframework.com に反映されます。

ドキュメント翻訳の手順

おおまかな手順は 翻訳ガイドライン に書いてあるので、まずはこちらを参照してください。

以下、もっとも簡単なパターンの手順を紹介します。

例えば 2.3.x/JavaActionsComposition に未翻訳箇所を発見したとします。 f:id:garbagetown:20141204010410p:plain

ページフッタにあるドキュメントソースへのリンクをクリックします。 f:id:garbagetown:20141204010449p:plain

GitHub のページが開くので、ログインします。 f:id:garbagetown:20141204010857p:plain

翻訳する前に他の誰かが作業着手していないことを確認してください。ファイル名などで issues を検索します。 f:id:garbagetown:20141204011139p:plain

コメント欄に作業着手する旨が書かれていなければ、自分が作業する旨をコメントしてください。内容はなんでも構いません。 f:id:garbagetown:20141204011412p:plain

いよいよ翻訳します。ここでは GitHub 上のエディタで作業します。ドキュメントソースのページに戻り、編集ボタンをクリックします。 f:id:garbagetown:20141204011532p:plain

編集が完了したら、コミットコメントに issues の番号を入力して Propose file change ボタンをクリックします。 f:id:garbagetown:20141204011733p:plain

自動的にリポジトリが fork され、Pull Request の作成画面が表示されるので、Create pull request ボタンをクリックします。基本的な作業はこれで終わりです。 f:id:garbagetown:20141204011852p:plain

最後に、playframwork-ja グループのメンバーが Pull Request の内容をレビューし、問題なければマージします。 f:id:garbagetown:20141204012025p:plain

マージが完了したら、10 分以内に playframework.com に変更が反映されます。 f:id:garbagetown:20141204012155p:plain

まとめ

ちょっとした翻訳や修正の場合、GitHub のアカウントさえあれば、どなたでも簡単にご協力頂けることがお分かり頂けましたでしょうか。

Play Framework 2.3.x の翻訳は、まだまだ issues が残って います。どうぞお気軽にご協力ください。

あと、四日目のアドベントカレンダーを誰か書いてください。以上です。

JJUG CCC 2014 Fallに行ってきた #jjug_ccc

去る 11/15(土) に開催された JJUG CCC 2014 Fall に参加してきましたので、遅くなりましたが感想文。

場所は前回と同じ西新宿ベルサーレでしたが、今回は来場者数 450 名以上とのことで、各セッションで立ち見が続出し、次回から会場を変えないといけないんじゃないかと心配になる盛況っぷりでした。

参加したセッションは以下の通り。

懇親会、二次会も参加してきました。

K-1 基調講演1

JJUG 副会長の橋本さんによる基調講演。

クラウド人工知能などの技術により変化していく社会において、Java エンジニアはどのように生きていくべきかというお話で、多くの資産があって堅牢な Java はこれからの時代に強いのでチャンスですよ、と。

本業のためか AI の説明が異常に充実している印象もありましたが、時代の変化と Java を絡めた話の展開、コミュニティを盛り上げる強いメッセージが圧巻の基調講演でした。

K-2 基調講演2

続いて Oracle の Simon Ritter による基調講演。スライドはまだ公開されていないようです。

個人的に印象に残ったのは、Java とは

  • プラットフォーム
  • コンピュータ言語
  • ライブラリセット
  • 仮想マシン
  • コミュニティ

であるというお話。

コンピュータ言語としては叩かれることの多い Java ですが、JVM の堅牢さと Oracle という超大企業によるサポート、そして JCP や JSR によるオープンな仕様策定プロセスの存在など、盤石な安定感を改めて感じました。

それと、通訳の方の声がイケメン過ぎでした。

H-1 Javaが見るニュータイプの夢 ~これからJavaはどう変わるか~

きしださん。スライドのインパクトすごい。

スライドのゆるふわ感とは裏腹に、内容はとてもハードボイルドな Project Valhalla と Project Panama のお話。

Valhalla と Panama の概要は下記きしださんのブログで把握していたつもりでしたが、より詳しく理解することができました。

なんだか地味だなと思っていた Valhalla と Panama が一気に興味深いものになった素晴らしいセッションでした。

そういえば Project Coin の Collection Literals を早く、と思って調べてみたら ValueTypes を出す前に試すべきじゃないと言うことになっているようですね。

Valhalla が Java 10 だとすると Collection Literals は Java 11 くらいでしょうか・・・

R1-2 Spring Boot + Doma + AngularJSで作るERP(統合基幹業務システム)

福岡から参戦の松崎さん。

Teeda + S2Dao で IE6 対応・・・ウッ、アタマが・・・。その後 Play Framework 1 も検討されたとのことで、共通の話題が多く、懇親会で話し掛ければ良かったです。

Doma は S2 時代の遺産と勝手に思い込んでいたのですが、GitHub で開発が続けられていました。

SQL ごりごり書きたい派にはおすすめとのこと。Domaググると S2 のページがトップに来てしまうのが勿体ないですね。

Angular は名前を聞く機会が増えてきましたが、どなたもベストプラクティスを模索している印象があります。まだ手を付けられていないので、しばらく成り行きを見守りたいと思います。

R5-3 Spring Bootハンズオン~Spring Bootで作るマイクロサービスアーキテクチャ

槙さんの上級者向けハンズオン。

縁あってチューターを担当させて頂いたのですが、

というわけで、ほとんど出番はありませんでした。ようやく「すみません」と声を掛けられて、出番だ!と振り返ったら @mike_neck さんだったり。

生き残るのに必死で何が起きているか掴み切れなかった方も多いと思いますが、当日はスキップされてしまった演習 2 も面白いので、完走できた方もできなかった方も、ご自宅でもう一度ゆっくり復習されるとよいと思います。

それから、はじめての Spring Boot を買うといいと思います。

R1-5 JavaでやってみるThe Twelve-Factor App

ビズリーチ渡辺さん。徹底的なタイムマネジメントとリクルーティングがすごい。

Twelve-Factor App は以前に目を通したことがありましたが、現場で実践されている方の具体的なお話は説得力が違いますね。標準出力ログ、OS 環境変数、ビルド/リリース/実行のあたりがとくに勉強になりました。

また、議論が分かれるところだと思いますが、Play Framework に育てられたステートレス派としては Sticky セッションには反対です。パフォーマンスが超重要なサービスでない限り、cookie に乗らないくらい大きな情報は memcached が無難かと。

番外編の .war, web.xml, JSP 禁止には全面的に賛成です!!1

R2-6 ElasticsearchとKibanaではじめる検索&アナリティクス

Elasticsearch 大谷さん。

あっという間に全席埋まって立ち見。

ELK Stack ばりばりのお話かと思いきや、前半は検索に関する基本的な技術のお話も多く、とても楽しかったです。日本における Fluentd の人気を所々でネタにされていました。

また、Elasticsearch クラスタモニタリングツール Marvel やクエリ実行コンソール Sense も紹介されていました。Kibana を作った Elasticesearch 製だけあってどちらも見た目がかっこいいです。開発目的の場合は無償とのこと。

Kibana 4 のデモも紹介されていました。残念ながら背景が白いですが、そのうち黒くなるはずです、とのこと。Kibana と IntelliJ IDEA はやっぱり黒背景ですね。

R5-7 JSR 371 MVC 1.0を通じてAdopt a JSRを知ろう!

最後はどのセッションを聴くか非常に迷ったのですが、Simon の基調講演絡みで Adopt a JSR へ。

いま使っている MVC フレームワークのアンケートがあったのですが、厳しい現実が浮き彫りになっていました。

前半は宮川さんがそもそも JSR や JCP とは何かを説明した後、Adopt a JSR を紹介。

後半は槙さんが MVC 1.0 の経緯と JJUG の貢献について紹介されていました。

その後のフリーディスカッションでは JSF と REST の相性の悪さが指摘され、やはり MVC は必要という論調が強かったように思います。

個人的に JSF が肌に合わないので MVC 自体は歓迎ですが、Jersey MVC でいいじゃんという気も・・・

懇親会

Oracle 寺田さんのご好意でボールペン、キーホルダー、ステッカーなどがもらえるじゃんけん大会が開催されました。狙いすましてデュークキーホルダーをゲット。

いつも通り、みなさんあともう一本がんばってください、余ったビールは必ず持ち帰ってください、などのアナウンスが飛び交う中、缶ビールを四本くらい飲んで、三本くらい持ち帰ってきました。これで会費が 1,000 円ってどうなっているんだろう。

二次会

終電のため一時間ほどしかいられませんでしたが、二次会も参加。

まとめ

いろいろな材料とタイミングが重なり、Java が再び勢いを取り戻していることがありありと感じられるカンファレンスでした。

Java 8 のリリースからまだ間もないにも関わらず、Lambda 式や Stream API は当たり前のものとして受け入れられており、改めてこれらを取り上げるセッションは多くなかったようです。

一方で、多くのセッションが Spring Boot について触れていました。長く積み上げてきた Spring Framework の周辺技術を魔法のようにまとめあげるだけでなく、2014 年 No.1 バズワードに輝きそうな Microservices architecture との相性の良さもあり、先進的な Java エンジニアたちに受け入れられているようでした。

まだしばらく Java の盛り上がりは続くと思われるので、勉強会やカンファレンスなどに積極的に参加して刺激を受けたいと思いました。

最後に、参加者が増え続ける JJUG CCC の運営各位、本業の合間を縫って発表資料を準備された登壇者各位、本当にありがとうございました。次回も参加します。

#怖くないScala勉強会 に行ってきた

2014 年 10 月 10 日にリクルートメディアテクノロジーラボさんで開催された #怖くないScala勉強会 に参加してきました。

きっかけはこちらの何気ないひと言で、ここからわずか一ヶ月で企画をまとめて、会場と飲食物の手配をしてくださった運営各位には圧倒的感謝の気持ちしかありません。本当にありがとうございました。

感想

本日の内容は、事前準備からカリキュラム、学習の要点まで、すべて GitHub 上に公開されています。入門的な内容がコンパクトにまとまっているので、参加できなかった方も目を通して、手を動かしてみると楽しいと思います。

Google スプレッドシートの座席表で進行を管理するという方法も面白いなと思いました。

時間の関係で最後まで辿り着けませんでしたが、何でも知っているのに何も知らない初心者の気持ちが分かる @gakuzzzz 先生の説明はとても分かり易く、チューター各位の対応も丁寧で、看板に偽り無しの怖くない Scala 勉強会でした。

また、えらく軽いノリで東京まで来たなあと思ったら、いつの間にか失職していた @daiksy さんの LT もありました。

最後にピザとビールでご歓談。

play_ja のステッカーをたくさんの人がもらってくれて、とてもうれしかったです。間もなく 2.2.0 の翻訳を完了して、2.2.4 と 2.3.5 の翻訳を同時に進めようと計画しています。翻訳も怖くないのでお気軽にお手伝い頂ければと思います。

まとめ

おまけ

ファミコンで対戦しているように見えますが、カリキュラム作成中の @mike_neck さんと @gakuzzzz 先生です。

#ScalaMatsuri に行ってきた

去る 2014 年 9 月 6 日と 7 日に、日本最大級の Scala カンファレンス ScalaMatsuri に参加してきました。

昨年の Scala Conference では Typesafe 社 CTO や Play リードプログラマなどを招待していましたが、今年の招待講演はなんと Scala の生みの親である Martin Odersky 先生ということもあってか、6,000 円の有料イベントにも関わらず、あっという間に完売したそうです。

一日目

当日の様子はニコ生タイムシフトで視聴することができます。両会場とも視聴回数が 130,000 回以上と、すごいことになっています。

私は当日、S-1, S-2, A-1, A-2, S-3, A-3, B-4, B-5, S-4, B-6, B-7, A-8, A-9 を拝聴しました。どの裏番組も気になっていたのでニコ生タイムシフトはとてもありがたいです。ドワンゴ様に感謝しつつ、少しずつ観ていこうと思います。

各セッションの間隔が短かったため、後半はかなり疲れましたが、懇親会のビールとピザで気合いを入れ直して LT に登壇してきました。

途中なぜかスクリーンが何度か映らなくなるトラブルに見舞われるも、すっかりできあがっている皆さんの応援のおかげで、そこそこうまく話せたのではないかと思います。

その後、この日のために作った日本 Play Framework ユーザー会のステッカーを小田好先生に誕生日プレゼントだと言って押し付けて、一緒に記念撮影。

f:id:garbagetown:20140911233828j:plain

ステッカー作成に協力してくれた大庭ちゃん、ありがとう!

二日目

二日目は参加者から意見を募ってテーマを決めるアンカンファレンス形式。以下の URL でタイムテーブルを見ることができます。

午前中はPlay Framework のドキュメント翻訳に協力してくださる方を募り、サイバーエージェント様のミーティングルームでもくもく翻訳会を開いてみました。

限られた時間の中だったので数は少ないですが、以下のドキュメント翻訳を新たに公開することができました。ご協力頂いた佐藤さん、小林さん、ありがとうございます!

また、ファシリテーターである自分の準備不足で、せっかく足を運んでくださったのに作業をお願いできなかった方々、申し訳ありませんでした。もっと気軽にお手伝い頂ける準備を整えてから、改めてご連絡差し上げますので、そのときはまたご協力よろしくお願いします。

その後、パネルディスカッションなどを聞いて閉会。運営スタッフの方々とビールを飲みに銀座ライオンへ。

まとめ

昨年時点では業務に Scala を使うこと自体にややチャレンジングな印象がありましたが、現在では単なる選択肢のひとつとして挙げられるようになったと感じました。特にアドテクやビッグデータなど、Web アプリケーション以外の分野における存在感がとても強いと感じました。

また、個人的には登壇された皆さんのスライドに Play Framework のロゴがばんばん貼られているのが印象的でした。四年前の社内勉強会で Play Framework のドキュメント翻訳を始めたと発表したときには、とても想像できない状況です。登壇された皆さんのうち、ほんの一部の方でも翻訳ドキュメントをご覧になり、業務に活かされているのだとすれば、こんなにうれしいことはありません。

とは言え、懇親会 LT のスライド後半にも書いたとおり、ドキュメント翻訳などと言ってはいるものの現時点の私の Play2 および Scala に関する知識は極めて限定的なものです。今後はこれまで翻訳に掛けてきたリソースをもう少し技術的な面に割り振りたいと考え、懇親会 LT に応募し、翻訳協力者を募り、アンカンファレンスで手を上げました。

これから少し時間を掛けて、もっと気軽に翻訳にご協力頂ける仕組みを用意する予定です。その仕組みがうまく回り始めたら、もっともっと Play2 と Scala を勉強して、来年の ScalaMatsuri では Scala プログラマとして及ばずながらも運営のお手伝いをさせて頂きたいと考えています。

最後になりましたが、この日のために多大な時間を削って準備されてきた運営スタッフの方々、会場を提供してくださったサイバーエージェント様、ニコ生を放送してくださったドワンゴ様、スポンサー企業様、登壇者各位、初めましての方々、お久しぶりの方々、楽しい時間をありがとうございました!今後もよろしくお願いします :-)