読者です 読者をやめる 読者になる 読者になる

えんじにゃーず・ハイ

主にエンジニアや技術情報についてつらつら書き連ねるブログです

JJUG CCC 2016 Springに参加しました

JJUG CCC 2016 Spring

東京で行われたJJUG CCC 2016 Springに参加しました! 東京での大規模なイベントは初めての参加だと思います。せっかくの機会だったので、開演から終演まで全てを堪能しようと早朝から東京へ向かいました。

セッションのタイムテーブルがありますが複数のセッションが同時に開催されており、どのセッションに参加しようかうんうん悩んでいました。

あまりにも雑多なメモでお目を汚しになりますが、参加したセッションのメモを書いておきます。

TypeAnnotation for Static Program Analysis さくらばさん

TypeAnnotationとはいままでのAnnotationとはどう違うのか。

アノテーションを使う例として3つある。

  • Annotaion Processor - コードを生成する
  • Condition Description - Reflection(JUnit @Test)
  • Syntax Check - Doclet(Override,Deprecated)

Static Program Analysis(静的プログラム解析)

有名なのはFindBugs,PMD

が、実は標準で用意されている

javac -Xlint

実はIDEアノテーションが拡張されており、

でビルド時にNullチェックができる。同じ開発環境であれば上記コードを埋め込んで対策することが可能。

@NonNullを引数や戻り値に全て定義すればコンパイル時にnullが設定されていれば警告をしてくれる。 しかしそれだと冗長になってしまうので、例えば型に対して@NonNullが定義できればあちこちに書かなくてよい。 それを実現するのがTypeAnnotation。

SE7まではアノテーションが定義できる箇所が限られていたが、SE8でTypeAnnotationで定義できるようになった。

Annotationは宣言時にのみ使用できる。

  • TypeAnnotationが導入された理由はコードチェックをしたいため。
  • 型宣言でなく、型を使用する際に定義できる。
  • ほとんどの場所で定義することができる。※一部除く(import,class,Annotation)

Checker Framework

  • コードの振る舞いをチェックしてくれる
  • 色々なツールをサポートしている
  • 例ではNullチェック。return nullしてたらコンパイルエラー、nullを引数に渡したらコンパイルエラーなど
  • 使い勝手は良さそうだが、万能ではない
  • nullチェックが不要となりそう
  • Checker Frameworkは便利なので、Nullチェックだけでも採用しよう

Geb実践入門 @PoohSunny さん

Geb、もうすぐ1.0が出そう

なぜブラウザオートメーションをしたいのか考える どこにテストしたいのか考える。全てテストしようと思うと非常に脆いテストとなる システムテスト自動化標準ガイドを参考

どうやってテストするか考える

はまったところ * なんで動かないのか * どのツールと組み合わせるか * Gebを選定するとGroovyなのでSpockやGradleを採用しがちだが、知らないツールを組み合わせるとどこで何が起きているかわかりづらい * 現状にGebだけを採用するのが望ましい

質疑応答のお時間を頂いたので、その場を借りて質問をさせて頂きました。

Gebではテスト中や実施後にスクリーンショットを自動取得することが可能ですが、javaScriptのalertがどうしても取得できず悩んでいたのでつい。 結論はブラウザドライバーでalertのスクリーンショットを取得するAPIが無いため、基本的にWrapしているGebでは解決できないとのことでした。 そもそもJavaScriptのalertを使わないように実装できるのがいいのですが…。

今振り返ってみるとあのタイミングでする質問じゃ無かったと激しく後悔して忘れました。私は何もしていない。

Elasticsearchハンズオン

様々なデータをフィルタを通してデータを加工し、kibanaで可視化するハンズオン。

あるお方がkibanaでデータを可視化したLTをしていて気になっていたkibana。 そのkibanaへ流し込むデータの作成/加工から一通りを1.5hほどでハンズオンする経験を得られました。 ハンズオン自体は以前からしているが普段は3時間ペースとのことで、駆け足で駆け抜けていきました。

いろいろ取得した生データは当然ながら、Twitterのデータも簡単に流し込めそうなのでちょっと試してみたいと思いました。

休憩中のショートセッション

Eclipse Collections

OSSEclipse Collectionsの紹介。JavaSE8から導入されたストリーミングAPIと比較してみると良さそう Eclipse Collections Kataという、テストコードを通しながらEclipse Collections APIの使い方を覚えるプロジェクトもあるみたい

Docker On A.*

マルチクラウドについて(AzureとAWSを組み合わせるなど) GoogleAWSなどでも障害が発生してダウンしてしまうリスクがある。

JavaはWrite Once Run Anywhareが有名だが、クラウドの環境によって動作しないことがある。 環境単位でのポータビリティとして解決できるのがDocker。

動作環境として作成したDockerイメージを各クラウドに配備する。

課題としては下記

アプリの構成

Tomcatなどの設定ファイルを簡単に変更できない。コンテナイメージの再作成が必要となる。 サーブレットコンテナをコンテナで使わないようにして解決する。

WARが不要のフレームワーク

  • Play!Framework
  • Spark Framework

コンテナ同梱のフレームワーク

  • Spring Boot

イメージサイズ

Alpineイメージ(組み込み向けLinux)5MB

開発のテンポ

  • JARをビルドするとコンテナのリビルドが必要->開発のテンポが悪くなる
  • ボリュームマウント+自動コンテナ再起動
  • ボリュームマウントとはコンテナ内部と外部の共有ができるようになる
  • Vagrantの共有フォルダをコンテナにマウントすると、ホスト側で変更するとコンテナ側へ変更がされる
  • 本番環境では自動デプロイされない設定で運用しているはずなので、ビルドツールを使ってコンテナを再起動する

クラウドへのイメージ共有

  • 開発チームでイメージ共有したい
  • Docker HubはPublicなので使えない
  • Private Docker Registryを使って共有する
  • クラウドストレージを使うので容量が不安材料とならない
  • ローカルで動作させるのでサーバーが不要

CIサーバ上にPrivate Docker Registryを導入すると、CIサーバ上からクラウドへアップロードできるようになる

  • 環境に左右されない開発を実現しよう
  • 常に本番と同じ環境で開発する(ステージングを使わない)

話し方の間がすごく上手かった。落ち着いていて、参加者が置いて行かれないぐらいの絶妙の間だった気がする。見習いたいです。

Beats

OSS Golangで作られているのでWindowsとかでも安心

Beatsは用途により下記のツールが提供されている。

PacketBeat

パケットをキャプチャして中から情報を抜き出しElasticsearchに投げる。DBのポートを監視してSQLをデータ化するなど。 取得できる情報がだいたい決まっているので、kibanaと相性が良い。kibanaにはPacketBeatsのテンプレートがあり、簡単にダッシュボードで可視化できる。

TopBeats

CPU使用率などをデータとするBeats。

FileBeats

FileをLogstashへ流し込むBeats。自分でLogstashへ流し込むより簡単?

Winlogbeat

WindowsのイベントログをデータとするBeats。

カスタマイズBeats

  • Beatsをカスタマイズして作成することが可能
  • テンプレートエンジンを利用して取得したいデータを使用したいデータを実装すれば開発できる
  • ただしGolang

Play Framework

Play使ったことないのはScalaをほとんど使ったことが無いからかな。JavaでPlayを採用している案件もあったので、そこまでマイナーではないと思います。

Java Puzzlers

5問のJavaの問題が問われるセッション。寺田さんとさくらばさんのセッションなので観に来ましたが中々カオスで終始笑いが絶えない感じでした。

ちなみに私は5問中3問正解…とはいえ、知らない言語仕様も多く、ハマる時はとことんハマりそうな印象を受けました。

懇親会

ビアハッシュ形式で好きに飲んで好きに食べて好きに話せる場。私はこういう場はなぜか話を切り出せなくてだいたいぼっちなので苦手だったんですが、飛び込みLT大会が観たかったので一番前で陣取って座り込んでいました。 懇親会LTだけあって内容はほとんどカオスなLTがメインでしたがとても面白かったです。

JJUG CCCを終えて

初めてのJJUG CCC、めちゃくちゃ楽しかったです。観たいセッションが被っていると観れないのが辛い…。可能であれば全てのセッションが観たかった。

ところどころ休憩も多く、移動時間もしっかり設けられているので割とゆっくりと参加できた印象でした。今まで参加したことがないので比較はできないですが、特に不満とかは無かったですね。

お水やコーヒーなども支給して頂けましたし、至れり尽くせりでした。

JJUG運営の方々、ボランティア有志の方々、そして登壇者の方々、本当にお疲れさまでした。ありがとうございました!

次も是非参加したいです。東京に住めればボランティアスタッフも経験したいですね。