MQTT Broker比較（2015/12版）

こんにちは、ishida(@kojiisd)です。

「IoT」という言葉も、IT／ICT関係者だけでなく、一般ニュースやビジネス雑誌にも登場するようになり、大分バズって広まってきていますね。

IoTといえば、やはりMQTTとの関係は切り離せず、商用のMQTT Brokerとしては、Sango だけでなく、 AWS IoT なども登場してきており、どれを利用するのが良いか、迷ってしまいますよね。

また、前回2015年6月にOSSの MQTT Broker 比較を行った際は、日本語の記事にも関わらず、VerneMQやeMQTTのコミッタの方からコメントも頂き、反響の大きさには驚きました。
ということで、OSSのBrokerも、バージョンアップがされてきているので、改めて比較レポートを作成しました！

※前回の比較内容は以下になります。

• MQTT Broker比較～機能比較編 - Taste of Tech Topics
• MQTT Broker比較～性能比較編 - Taste of Tech Topics

機能比較

各MQTT Brokerの機能比較に関しては、以下のようになります（○：対応あり、×：対応なし）。

Broker(version)	開発言語	対応しているMQTT version	対応OS	QoSレベル	Retain	Will	WebSocket	UI	冗長化
Mosquitto(1.4.5)	C	MQTT 3.1/3.1.1	Win/Mac/Linux	0,1,2	○	○	○	×	×
Apollo(1.7.1)	Java	MQTT 3.1	Win/Mac/Linux	0,1,2	○	○	○	○	×
RabbitMQ(3.5.6)	Erlang	MQTT 3.1	Win/Mac/Linux	0,1	×	○	×	○	○
Mosca(0.32.1)	Node.js	MQTT 3.1	Win/Mac/Linux	0,1	○	○	○	×	×
eMQTT(0.13.0)	Erlang	MQTT 3.1/3.1.1	Win/Mac/Linux	0,1,2	○	○	○	○	○
VerneMQ(0.12.2)	Erlang	MQTT 3.1/3.1.1	Mac/Linux	0,1,2	○	○	○	×	○

• Brokerのversionは調査時のものです。
• 今回、新たに「対応OS」の列を加えました。

性能比較

Publish性能(retain=false)

Publish性能(retain=true)

Subscribe性能

• グラフの縦軸は「スループット（処理したメッセージ数/秒）」です。
• 機能的に対応していない箇所はグラフを記載していません。

結果

• eMQTTには管理のためのWebUIが追加されて、使い勝手が良くなりました。
• eMQTTとVerneMQは、前回評価時は、retainをtrueにした際の性能が大幅に低下したのですが、今回はその点が改善され、retainをtrueにしても性能劣化は見られなくなりました。
• eMQTTが全体的に性能が向上し、VerneMQと同等の性能になっています。

前回評価時から、たった半年ですが、eMQTTやVerneMQなどはリリースの頻度も多く、性能も大幅に改善されていました。
個人的には、前回の結果からは「使うならVerneMQだろう」と思っていたのですが、今回の結果からはeMQTTもかなり魅力的になりました。

用途や目的に応じて、最適なBrokerを選択するのに役に立てて頂ければと思います。

計測内容

計測について、以下に処理内容を示します。

1. Publish（Retainなし）
   • MQTT Broker に対して、クライアントからメッセージを送信する処理になります。Retainなしの場合は、最後にPublishされたメッセージをBrokerが保持しません。
2. Publish（Retainあり）
   • MQTT Broker に対して、クライアントからメッセージを送信する処理になります。Retainありの場合は、最後にPublishされたメッセージをBrokerが保持します。
3. Subscribe
   • MQTT Broker から、クライアントがメッセージを受信する処理になります。MQTTの特性として、接続されているときのみメッセージを受信するため、Subscribeしている間、それとは別プロセスでPublish（Retainなし）の処理を行っています。

またベンチマークの条件は以下になります。

• 構成、メッセージ長
  • MQTT Broker に対して、500connections で同時処理
  • 1つのメッセージ長は 1024byte
• マシンスペック
  • OS: CentOS 6.5 (64bit)
  • CPU: Intel(R) Core(TM) i7-2700K CPU @ 3.50GHz (4コア HT有効)
  • メモリ: 32GB
  • NIC: 1Gbps

Acroquest Technologyでは、キャリア採用を行っています。

• 日頃勉強している成果を、AWS、Hadoop、Storm、NoSQL、SpringBoot、HTML5/CSS3/JavaScriptといった最新の技術を使ったプロジェクトで発揮したい。
• 社会貢献性の高いプロジェクトに提案からリリースまで携わりたい。
• 書籍・雑誌等の執筆や対外的な勉強会の開催を通した技術の発信や、社内勉強会での技術情報共有により、技術的に成長したい。
• OSSの開発に携わりたい。

　
少しでも上記に興味を持たれた方は、是非以下のページをご覧ください。
　キャリア採用ページ

ENdoSnipe Ver6.0機能紹介

こんにちは、fujiiです。

ENdoSnipe Ver6.0機能紹介の後編です。

前回、ENdoSnipe Ver6.0の変更点を簡単に紹介しましたが、
今回は、追加した機能の詳細を説明しますね♪

プロファイラ機能

Profilerビューは、ENdoSnipeで計測した結果の統計情報を、Dashboard上から参照する画面です。
表示される統計情報は、以下になります。

1. HTTPリクエスト
2. JDBC接続情報(JDBC監視をONにしている場合）
3. Javelinに設定したメソッド

「Profiler」タブを選択し、「reload」ボタンをクリックすると、
最新のプロファイル結果が取得できます。

プロファイラの結果は、CSV形式でダウンロードできます。
ダウンロードしたい場合には、「download」ボタンをクリックしてください。

オンラインでの設定変更機能

Controllerビューでは、ENdoSnipeの設定をオンラインで変更できます。
この機能を利用すると、アプリケーションの再起動なしに設定を変更できるようになります。

Controllerビューを表示するには、「Controller」タブを選択してください。
変更できるパラメータをいくつか紹介します。

1. javelin.leak.collection.monitor：Collectionオブジェクトのリークを監視するかどうか
2. javelin.jdbc.enable：JDBC監視を行うかどうか
3. javelin.jdbc.recordExecPlan：実行計画の取得を行うかどうか

パフォーマンス問題が出た時に一時的に監視対象を増やして情報を収集し、
また元の状態に戻す、ということができるようになりました。

メール通知機能

Ver5.2 で追加したシグナル機能を強化して、
シグナルで閾値を超えた場合や閾値超過状態から回復した場合に、
メールを送信できるようになりました。

この機能によって、

1) CPU使用率が上昇している場合
2) メモリ使用量が高くなっている場合
3) レスポンスが遅い場合

など、アプリケーションに問題が発生していた場合に、
自動的に通知することができます。

メールを送信するためには、以下の設定が必要です。

1. DataCollectorの設定

collector.propertiesを開き、以下の設定を行ってください。

1. collector.smtp.sendMail=true
2. collector.smtp.server=
3. collector.smtp.port=
4. collector.smtp.user=
5. collector.smtp.password=
6. collector.smtp.to=<メール送信先アドレス>

2. Dashboardの設定

「Signal Definition」画面を開き、「Send Mail」にチェックを入れると、
閾値を超えた場合や閾値超過状態から回復した場合に、メールが送信されます。

ENdoSnipeはここからダウンロードできますので、ぜひ感想などをお知らせください！

Acroquest Technologyでは、キャリア採用を行っています。

• 日頃勉強している成果を、AWS、Hadoop、Storm、NoSQL、SpringBoot、HTML5/CSS3/JavaScriptといった最新の技術を使ったプロジェクトで発揮したい。
• 社会貢献性の高いプロジェクトに提案からリリースまで携わりたい。
• 書籍・雑誌等の執筆や対外的な勉強会の開催を通した技術の発信や、社内勉強会での技術情報共有により、技術的に成長したい。
• OSSの開発に携わりたい。

　
少しでも上記に興味を持たれた方は、是非以下のページをご覧ください。
　キャリア採用ページ

Springfox+Swagger+Bootprintによる即席REST API仕様書作成

こんにちは。阪本です。

世の中、Swaggerが注目を浴びてきていますね。
開発のスピードアップが求められる中、「外部IF仕様書なんて書いてられねぇ！！」なんて言って実装をバリバリ進めてしまいそうですが（アカンアカン）、そうは言っても外部IF、他社との仕様調整も必要。

そんなときに有効な、実装しながら仕様書も作れるSpringfox+Swaggerに加え、ドキュメント生成ツールのBootprintを使って、簡易的な仕様書を作ってみました。

仕様書の動的生成

以下のようなシンプルなSpringBootアプリケーションから、REST APIを生成してみます。

@SpringBootApplication
public class SwaggerExampleMain {
    public static void main(String[] args) {
        SpringApplication.run(SwaggerExampleMain.class, args);
    }
}

@RestController
@RequestMapping("/employee")
public class EmployeeController {
	
    @RequestMapping(method = RequestMethod.GET)
    public List<Employee> list() {
        // Return employee list
        return new ArrayList<>();
    }

    @RequestMapping(method = RequestMethod.POST)
    public void create(@RequestBody Employee employee) {
        // Add employee
    }

    @RequestMapping(value = "/{id}", method = RequestMethod.PUT)
    public void update(@PathVariable Integer id,
            @RequestBody Employee employee) {
        // Update employee
    }

    @RequestMapping(value = "/{id}", method = RequestMethod.DELETE)
    public void delete(@PathVariable Integer id) {
        // Delete employee
    }
}

まずはpom.xml。Springfoxを追加します。

<springfox.version>2.2.2</springfox.version>

～～～

<dependency>
  <groupId>io.springfox</groupId>
  <artifactId>springfox-swagger2</artifactId>
  <version>${springfox.version}</version>
</dependency>
<dependency>
  <groupId>io.springfox</groupId>
  <artifactId>springfox-swagger-ui</artifactId>
  <version>${springfox.version}</version>
</dependency>

そして、Swaggerの設定を行うJavaConfigクラスを作成します。
@EnableSwagger2アノテーションを付けて、Docketでいろいろ指定するところがミソです。
今回は、「/error」以外のURIを持つREST APIのドキュメントを一覧化することにします。

import static springfox.documentation.builders.PathSelectors.regex;

import org.springframework.context.annotation.Bean;
import org.springframework.context.annotation.Configuration;

import springfox.documentation.builders.ApiInfoBuilder;
import springfox.documentation.builders.RequestHandlerSelectors;
import springfox.documentation.service.ApiInfo;
import springfox.documentation.spi.DocumentationType;
import springfox.documentation.spring.web.plugins.Docket;
import springfox.documentation.swagger.web.UiConfiguration;
import springfox.documentation.swagger2.annotations.EnableSwagger2;

@Configuration
@EnableSwagger2
public class SwaggerConfig {
    @Bean
    public Docket documentation() {
        return new Docket(DocumentationType.SWAGGER_2).select().apis(
                RequestHandlerSelectors.any()).paths(
                        regex("^/(?!error).*$")).build().pathMapping("/").apiInfo(metadata());
    }

    @Bean
    public UiConfiguration uiConfig() {
        return UiConfiguration.DEFAULT;
    }

    private ApiInfo metadata() {
        return new ApiInfoBuilder().title("Employee API").version("1.0").build();
    }
}

これらを書いて、Javaアプリを普通に起動するだけで、APIの一覧とパラメータが見えるようになります。
http://localhost:8080/swagger-ui.html

さらに、この画面でAPIに対してリクエストを送信することもできます。
簡易的な動作確認をするにも便利ですね。

オフライン仕様書生成

上記はアプリを起動しないとAPIの情報が見られませんでしたが、顧客や他チームと共有できる環境がなく恵まれない場合もあります。
そんなときは、オフラインの仕様書を生成しましょう。

オフラインの仕様書はSpringfoxでもMarkdown形式で生成できますが、ここはあえてMarkdownドキュメントが見られない（ツールなんて入れてない）人のことも想定し、HTML形式で出してみます。

Swagger2Markupという選択肢もありましたが、何となく使うのが大変そうだったので、今回はbootprint-swaggerを使ってみます。

node.jsをインストールした環境で以下のコマンドを実行し、bootprint-swaggerをインストールします。

npm install -g bootprint
npm install -g bootprint-swagger

Springfoxの設定を行ったJavaアプリを立ち上げ、bootprint-swaggerを実行します。

bootprint swagger http://localhost:8080/v2/api-docs target

これにより、targetフォルダ配下にHTMLファイルが生成されます。

なんとなく、それっぽいドキュメントができました＾＾；

おわりに

とりあえず、ソースコードからREST API仕様書を生成できましたが、パラメータの桁数やフォーマットなど、「仕様書」としてはまだまだ情報が不足しています。
次回は、そのあたりの詳細情報の出力について、確認してみたいと思います。

それではー。

Acroquest Technologyでは、キャリア採用を行っています。

• 日頃勉強している成果を、AWS、Hadoop、Storm、NoSQL、SpringBoot、HTML5/CSS3/JavaScriptといった最新の技術を使ったプロジェクトで発揮したい。
• 社会貢献性の高いプロジェクトに提案からリリースまで携わりたい。
• 書籍・雑誌等の執筆や対外的な勉強会の開催を通した技術の発信や、社内勉強会での技術情報共有により、技術的に成長したい。
• OSSの開発に携わりたい。

　
少しでも上記に興味を持たれた方は、是非以下のページをご覧ください。
　キャリア採用ページ

DockerとAnsibleの使い分けを手探りで考えてみた

皆さんこんにちは。
アキバです。
久しぶりにエントリ書きます。

突然ですが、今、システムをデプロイすると言ったら自動化しますよね。

そこで、皆さんは何を使っていますか？

私は、最近、DockerとAnsibleを仕事でガチに触る機会がありました。
※本番運用のサーバもDockerを使って動作させました。

　

今回は、そこで得たことについて書きます。
皆さんの参考になればと思います。

命題：Dockerを使うべきか、Ansibleを使うべきか。

作るべきシステムは、いわゆるWebシステムで、WEBサーバとAPサーバで構成しています。
WEBサーバとAPサーバはそれぞれN台のクラスタ構成です。

※以下の図は、本番運用で想定しているサーバ構成を今回の説明用に抽象化したものです。

N台のクラスタ構成ということで、Dockerを使おうとなりました。
コンテナでスケールアウト出来るから…ですね。

さてここで、実際にシステムを構築するのに、Dockerを使うべきか、Ansibleを使うべきか。
そこで色々と紆余曲折があったわけです。

結論から書くと

今回は、Dockerコンテナの部分はDockerだけで構築し、Dockerコンテナの外の部分にAnsibleを使うというやり方にしました。

※コンテナは、Docker Registryにpushしておくことで、複数の環境に同じコンテナイメージをデプロイできるようにもしてあります。

ただ、この方式に到達するまでには、いくつかのアンチパターンとも言うべき苦い経験をしています。
それらから、主なものを次に紹介していきますので、同じ失敗をしないように参考にしてもらえればと思います。

アンチパターン１：AnsibleでDockerコンテナの中身を操作しようとする

最初（まだ開発環境の段階でしたが）、この時はAnsibleを使って、Dockerコンテナの中身をコンテナの外から構築しようとしました。
さらに、１つのDockerコンテナを作って、その中にDBとアプリをすべて１コンテナに詰め込もうとしました。

しかし、この構成はうまく行きませんでした。
当初、Ansibleは1.5を使っていたのですが、
DockerコンテナをAnsibleを使って構築するのに、壁がありました。

Dockerコンテナは、その仕組み上、起動するたびにIPアドレスが変わる可能性があります。
Ansibleを使ってアプリ環境を構築する際に、コンテナの外からIPアドレスを調べたり、それを設定ファイルに反映したりといったことになってしまいました。

そもそも、DockerにはDockerfileというものがあって、そこで構築に必要な処理ができますが、
様々な構成変更を適用することを考えると、Ansibleでやったほうが柔軟性があると考えたのです。
＃開発中はファイルや設定内容に色々な変更があり、最初からデプロイ対象をFIXして進められるわけではない。
＃その度にDockerコンテナを再構築していたら時間がかかってしまう…と。

しかし、Dockerで行えることは、Dockerにやらせるべきでした。
それを、「デプロイ作業はAnsibleにやらせる」とした結果、考えることが多くなり、複雑な形になってしまいました。
この辺の話は、次のアンチパターンともつながっています。

アンチパターン２：Ansibleのスクリプト・ヘルに陥る

１つのシステムを作るのに、Tomcatで動くAPサーバ、PostgreSQL、Couchbase、Elasticsearchなど、色々なコンポーネントを組み合わせるアーキテクチャになっていたのですが、これらをAnsibleで全部やろうとした結果、スクリプトの量が増えました。

といっても、単に各ミドルをインストールするだけならそこまで大変なことにはならなかったでしょう。
ここに、以下の要素を加えた結果、面倒なことになりました。

・データ投入
・設定ファイルの配置

要するに、一回システム作った後、システムのアップデートも含めてAnsibleで対応しようとしました。

一般に、Ansibleを使うメリットを活かすには、やはり冪等性を意識して、何度実行しても同じ結果になるようにできることが１つのポイントになると思います。
しかし、定義ファイルを更新したり、動作中に変更されるデータを更新するといった処理を行おうとすると、冪等性を考慮したスクリプトを作ることが困難になります。
そのような更新のスクリプトを作ろうとした結果、設定の変更が入っていく中でスクリプトの粒度が細かくなり、スクリプト・ヘルに陥りました。

そもそも、システムを構築する際には、以下のようなレイヤを考えるべきです。

1. ミドルウェアのインストール、設定
2. アプリケーションのデプロイ
3. 設定ファイルの適用

Ansibleをなんとなく導入していくと、このあたりのレイヤ分けがうまく行かなくなります。
うまく行かないまま作っていくと、大小さまざまな処理を思いつくままにスクリプト化していくことになりがちです。
それで、収拾がつかなくなってしまう、、、というアンチパターンになります。

というわけで．．．

ここで、以下のことを理解するべきです。

Dockerと、Ansibleの関係は、いわゆる「Docker vs Ansible」ではないと。

1. Dockerは、アプリケーション／コンポーネントを組み立てる（ビルド／デプロイ）＋コンテナ実行
2. Ansibleは、システムを構築する（構成管理）

この２つは、似ているようで、似ていないのだと理解しました。
担当するレイヤが異なるので、お互いに補完し合うように使うべきでした。

なので、アプリケーションのデプロイを行う部分は、Dockerに任せ、コンテナ内に必要な環境を閉じ込めました。

コンテナの外

一方で、コンテナの外にあるものは、Ansibleを使うようにしています。

具体的に、以下のようなものは、Ansibleを使って構築するようにしました。

1. ファイアウォール設定
2. cronの設定（ログローテート、一時ファイルの削除などの維持タスク）
3. HAクラスタリング設定

ファイアウォールやcronは、Ansibleが命令を用意してくれているので、これを使えば冪等性も維持できます。

また、PostgreSQLや、サーバ間で相互通信を必要とするCouchbaseやElasticsearchはDockerコンテナを使わずに構築しています。
最近は、Dockerでもコンテナ間通信の仕組みが登場してきていますが、当時は複数サーバに分けた場合の相互通信の仕組みがほぼ用意されていなかったので、諦めました。

これらは、また、上に書いたレイヤを意識して、

1. ミドルウェアのインストールを行うロール
2. 定義ファイルを適用するロール
3. データ投入を行うロール

を分けて整理しました。

まとめ

当たり前ですが、DockerとAnsibleは、それぞれ得意・不得意とするところがあります。
そもそも、２つのツールが異なるレイヤを担当していることを理解して使用するべきだと感じました。

実運用で使い始めてから日が浅いこともあり、まだまだ、手探りで進めている部分があります。
コメントやアドバイスをいただけたら、幸いです。

では。

Acroquest Technologyでは、キャリア採用を行っています。

• 日頃勉強している成果を、AWS、Hadoop、Storm、NoSQL、SpringBoot、HTML5/CSS3/JavaScriptといった最新の技術を使ったプロジェクトで発揮したい。
• 社会貢献性の高いプロジェクトに提案からリリースまで携わりたい。
• 書籍・雑誌等の執筆や対外的な勉強会の開催を通した技術の発信や、社内勉強会での技術情報共有により、技術的に成長したい。
• OSSの開発に携わりたい。

　
少しでも上記に興味を持たれた方は、是非以下のページをご覧ください。
　キャリア採用ページ

日経ソフトウエア1月号の記事を執筆しました。

久しぶりです。ナカガワです。
最近はBackbone系から転向、Angular系での
開発にいそしんでいます。

自分はBackbone系の信者だと思っていたのですが、
Angularを使ってみたらやっぱり便利で。。
今ぐらぐら来ています。

と本題ですね。

日経ソフトウエア1月号記事が載りました。

11/24日発売の日経ソフトウエア1月号に、
私と当社吉田の2名で書いた記事が載りました。

題して
「セキュアコーディング入門」
～情報流出はこうして防ぐ～
です。

実際のコードを例に解説(^^)

攻撃者がどこを狙うのか？の観点から
どんな問題が起きるのか、どう防ぐのか、
各種セキュリティ問題を防ぐ方法を
解説しています！

例えば

• SQLインジェクション
• XSS
• CSRF
• クリックジャッキング

などを例に挙げて、
その仕組みから対策、実装コードまでを紹介しています。

セキュリティの基礎を振り返りながら書いた記事です。
みなさん、
見かけたらぜひ手に取ってみてください m(__)m

Acroquest Technologyでは、キャリア採用を行っています。

• 日頃勉強している成果を、AWS、Hadoop、Storm、NoSQL、SpringBoot、HTML5/CSS3/JavaScriptといった最新の技術を使ったプロジェクトで発揮したい。
• 社会貢献性の高いプロジェクトに提案からリリースまで携わりたい。
• 書籍・雑誌等の執筆や対外的な勉強会の開催を通した技術の発信や、社内勉強会での技術情報共有により、技術的に成長したい。
• OSSの開発に携わりたい。

　
少しでも上記に興味を持たれた方は、是非以下のページをご覧ください。
　キャリア採用ページ

JavaOne 2015 報告会に参加してきました＆LTもしてきました

久しぶりです。石田 @kojiisdです。
ミャンマーでの3年間の赴任を終えて
日本に戻ってきました。これからまたちょくちょく顔を出しますね。

11/14(土)のJavaOne 2015報告会に参加してきたので、
その報告をば！

ちなみに、私も当社の谷本 @cero_tとともに
JavaOneにてログの可視化、というタイトルで登壇してきまして、
今回のJavaOne報告会の中でその結果などを少しLTでお話しました。

www.acroquest.co.jp

全体

Oracle伊藤さんや、JJUG鈴木さんのフィードバックなどで、
今年のJavaOneで目立ったキーワードとして、以下の3つが紹介されていました

• キッズプログラム
• DevOps
• Microservices

JavaOne前日にはJavaOne4Kidsという子供向けイベントが開催されましたし、
最終日のコミュニティキーノートでも、Kids Are Futureというキーワードのもと
子供たちにスポットライトを当てた内容となっていました。
隅に追いやられていくオジサンたち、一緒に頑張りましょう＞＜

また、今年のJavaOneでは「Java」という言葉が出てこないセッションがあり、
Javaそのものより、DevOpsやMicroservicesなどの運用にフォーカスしたセッションもありました。

私としてはサービスを作り込むより、開始して運用する方に興味があるため、
いまのこの流れは大歓迎だったりします。
プログラムだけやっていても将来ないと思うんですYO！
（決してプログラムができないから言っているわけではない）

Javaに関して

Java9の新機能のうち、注目度が高いのは以下の2つ。

• Project Jigsaw
• JShell

Jigsawって前からモジュール化の流れでキーワードとしては聞いていました。

が、、、実際聞いてみるとまだあまり良さが実感ができない（ーー；
多くの人が資料アップしたりしてくれているので、
もっと手を動かさなきゃ、と焦りました。

JShellは実際少し使ってみましたが、
ちょっとした内容を書いてみて試してみるとか、
初心者がJShellから入ってJavaを学んでいくとか、可能性広がるように思います。

うちのJavaセミナーでも紹介してみたいと思った内容でした。www.acroquest.co.jp

パネルディスカッション

当社の谷本も参加して、
Microsoft寺田さん、ゴールドマンサックス伊藤さんと
JavaOne登壇者としてディスカッションがありました。

印象的だったのは「今の仕事を頑張って、その延長にある
痛みや経験の発表を参加者は聞きたがっている」という話。
趣味レベルでは到達できないのがJavaOneであり、
また到達するために現在の仕事を一生懸命やることが
必要、と実感させられる内容でした。

すでにいくつかの方のブログで紹介されていますね。

JavaOne 2015 報告会 @ 東京 - Yuji Blog

JavaOne 2015 報告会 @ 東京に行ってきました #j1jp #jjug - Javaプログラマーのはしくれダイアリー

懇親会、LT

さて、私も懇親会中のLTで発表しました。

今回私は谷本と同じセッションにセカンドスピーカーとして
参加したのですが、登壇者として華々しくパネルディスカッションしていた
谷本の舞台裏を赤裸々に発表させてもらいました。
みんな舞台裏とか好きですよね（＾＾
準備中（当日！）の写真とか進捗率とか見せたところで
どっと笑いが取れたのが何よりですｗ

総括

今回JavaOne初参加に始まり、この報告会でのLTまでさせてもらいましたが、
本当に良い経験をさせてもらったな、と思っています。

世界の頂点を見て回れたこと、
また自分たちがやっていること、日本でJJUGなどで
活動している人たちのレベルが本当に高かったこと
（JJUGで発表されている内容などはJavaOneでも十分に発表できるだろう）
を実感できたのが大きかったです。

また新しい刺激を得るために、
次回JavaOne参加（スピーカーとして）を
目指したいと思った石田でした。

それでは！

Acroquest Technologyでは、キャリア採用を行っています。

• 日頃勉強している成果を、AWS、Hadoop、Storm、NoSQL、SpringBoot、HTML5/CSS3/JavaScriptといった最新の技術を使ったプロジェクトで発揮したい。
• 社会貢献性の高いプロジェクトに提案からリリースまで携わりたい。
• 書籍・雑誌等の執筆や対外的な勉強会の開催を通した技術の発信や、社内勉強会での技術情報共有により、技術的に成長したい。
• OSSの開発に携わりたい。

　
少しでも上記に興味を持たれた方は、是非以下のページをご覧ください。
　キャリア採用ページ

Elastic社に訪問してきました。

JavaOne終わってからのelastic社訪問、余裕でした、@cero_t です！
Elasticsearchで有名な、elastic社のマウンテンビューオフィスに訪問してきました。

先月ニュースリリースをした通り、Acroquestはelastic社とパートナーシップを組みまして、
( http://www.acroquest.co.jp/company/press/2015/1021p1.html )
その縁でelastic社のマウンテンビューオフィスに訪問させていただき、ミーティングを行いました。

JavaOneが開催されたサンフランシスコから、elastic社のあるマウンテンビューは、電車で1時間ほど。

付近にはFacebook社のあるメンローパーク

Apple社のあるサニーベイル

Oracle社のあるベルモントなど

著名なIT企業が立ち並ぶエリアです。
マウンテンビューはGoogleがあることでも有名ですね。

というかその辺り、全部巡ってきたんです (^^)v

そして、elastic社。

広々としたオフィスに、フリードリンクのパントリー。

スタンディングディスプレイの人もいました。

[

モダンなIT企業な雰囲気全開です。

ミーティングでは、プロダクトマネージャーであるTanya Braginから直々に
elasticsearchをはじめとしたELKスタックの将来について説明していただき、
また、Acroquestの次期プラットフォーム構想も踏まえ、少し踏み込んだ議論を行いました。

ELKスタックの将来については、11/9(月)に行われる
elasticsearch勉強会でもフィードバックする予定です。
https://elasticsearch.doorkeeper.jp/events/33631
興味のある方は、ぜひエントリーして頂ければと思います。
（既にキャンセル待ちになっていますが、まだ入れる可能性もあるでしょう！）

リクルートテクノロジーズで、僕と握手！
@cero_t でした！！