JJUG CCC 2017 Spring に行ってきた

勉強 IT

はい。行ってきました。

www.java-users.jp

来場者数は1000人を超えており、いろんな人が参加ブログを書くとは思いますが、

各時間ごとに複数セッション、最大8セッションまで並行して行われていました。

その中で、自分と全て同じセッションに参加している人もいるかいないか、ましては自分のこれまでのコンテクストを前提としたうえでの感想と完全に一致するということはまずありえません。 ですので、自分なりの所感をまとめておくことは、無駄ではないと思います。

また、どこかで自社にフィードバックする際の覚書にもしておきたいという思惑もありますので……

非機能要件とSpring Boot

speakerdeck.com

一番の目玉はIPAが提供する「非機能要求グレード」の話が出たことです。

www.ipa.go.jp

このグレードで定義したレベルを、Spring Actuator、Spring Securityを利用して満たしていくという展開の内容でした。

所感

元々存在自体は知っていて、利用を検討したこともあるのですが、他にこれを利用しているところが身近にあるという安心感がありました。

加えて、Spring Actuator、Spring Securityの機能についても多く知ることができ、とても良い機会を得られたと思っています。

Java EE 8 and its latest topics

※資料公開なし

Java EE 8の新機能に関する話でした。

今回覚えておくことは、「Java EEはマイクロサービスに向かう。Java EE9が本番。Java EE8はその前哨戦。」とういことです。

さしあたり、Java EE8では次の機能が増える予定です。

これらを実現する中で次の仕様のトピックがありました。私もまだよく理解してないので名前だけ・・・

  • JSON-P 1.1
  • JSON-B 1.0
  • Servlet 4.0
  • JSF 2.3
  • CDI 1.0
  • BeanValidation 2.0
  • 新しい認証認可機能（なんだっけ？
  • Identity Store（これ重要そう

おいおい勉強していきます。

また、Java EE8のマイルストーンは次のようになっています。

  • 今年7月中に仕様確定
  • その後まずGlassFish5に着手

所感

WebLogicサーバ開発は並行して始まるのだろうか？要チェックです。

How to use MicroProfile

www.slideshare.net

プロデューサーGlassFishユーザグループの方のお話です。

MicroProfile、私は初めて名前を知りました。

Java EE7以降の開発速度にしびれを切らしたコミュニティの人たちがつくったマイクロサービスアーキテクチャを目指したAPI仕様。次の実装があります。

  • Wildfly Swarm
  • Payara MicroProfile
  • WebSphere Liberty
  • TomEE

Payara MicroProfileだけ知ってて、なんとなく「今後Java EEやるならこのへんかな？」とは思っていました。

この仕様が誕生したのは、Java EE 8が発表される前です。

所感

Java EE8（Java EE9まで含む）のロードマップが見えたことで、MicroProfileとは（Java EE自体とも？）どう向き合っていくか、考える必要がありそうですね。

Javaエンジニアに知ってほしいRDBアンチパターン

speakerdeck.com

DB設計のアンチパターン。重要なことは次の通り。

  • DBの寿命はAPより長い
  • DBはリファクタする機会がほとんどない（せいぜいDBMSのバージョンアップくらい）

つまりアンチパターンとは次のようなものになる。

  • のちの苦しみを生むような設計・作業実施
  • 過ちを繰り返さない

例えば・・・

  • SELECT delete_flg FROM foo GROUP BY delete_flg をたたくと次の結果が返ってくる

    0：初期値？

    1：存在

    2：削除

    9：抹消（削除とどう違うの！？

    99：システム権限でむりやり削除

    null：APバグにより登録

  • テーブルに memo memo2 memo3 という列名がある

    最初の memo が無印というのがポイント。 ここで抱いている感情の名前を「哀愁」といいます。

というお話をいくつかいただきました。（別の記事できるレベル。というかだれか記事にしてBuzzる。）

最後に、ありがたいお言葉。

DBの問題は忘れた頃にやってくる

サーバの問題は休みの間にやってくる

アプリの問題は納品前にやってくる

所感

全日本が泣いた。席は完全に埋まって、壁際は立ち見だらでだった。 俺もよくやる話。SQLアンチパターン読もう。そーだいさんの本じゃないけど。

Seasar2からSpringへ移行した俺たちのアプリケーションがマイクロサービスアーキテクチャへ歩み始めた

www.slideshare.net

SpringFrameworkでできたモノリシックアプリケーションを、SpringBoot化＋マイクロサービス化する（真っ只中にいる）という話。

直近で取り組んだマイクロサービス化について、次の紹介がありました。

  • マイクロサービス

    • Eureka：サービスディスカバリ
    • Ribbon：クライアントサイドのロードバランシング
    • Hystrix：サーキットブレーカー

  • ロギング

    • fluentd：SpringBootのログファイルを収集してElasticsearchに送る
    • Elasticsearch：言わずもがな
    • zabbix：Elasticsearchの内容をチェックし、結果をトリガーとしてslackにkibanaのURLを送る

また、マイクロサービス化における結合テストについて次のSpringファミリーの紹介がありました。

  • Spring Cloud Contract Stub Runner

自由にエンドポイント⇔ステータス・ペイロードの組み合わせを指定できる、スタブノードを簡単に立ち上げることができます。 これでステータス500が返ってくるときのテストもイミュータブルに実施できるわけですね。

所感

Spring Cloud Contract Stub Runnerという、すばらしいソリューションの存在を知った。 エンドポイントだから、JVM以外の開発のテストノードにも使えるんだよね。 俺もみんなも、関ジャバに参加してじゅくちょーさんと握手！

劇的！データベース・ビフォーアフター 時代はディスクからインメモリーへ――

※資料公開なし

証券関係のシステムをこなす、速度の匠コンビのセッション。

インメモリデータグリッドを活用する話。

インメモリデータグリッドは、キャッシュ技術（HazelCastとか）ではない。あくまでメモリがデータの主体となる仕組みなんだ。

稼働中のデータはすべてインメモリデータグリッドにより管理、無駄なレイテンシはとにかく省かれる。

社長「メモリだから、マシンが落ちたらデータが失われるんじゃないの？（迫真」

社員「大丈夫なんですよこれが（棒」

データグリッドを構成する別ノードにバックアップが自動的に行われるのだ！

さよなら磁気ディスク！・・・とはいかない。永続化データもあるからね。

あと、インメモリデータグリッドはMapデータをKey-Valueで記録するから、クエリ的な問い合わせはRDBより遅くなる。

設計命で、使い方次第で神にも悪魔にでもなる。気を付けてくれよな！

……

所感

インメモリデータグリッド初めて知りました。 いままで業務ではそこまで速度を求められるものを作ったことがないが、自分で試してみたい。 SpringBootとKotlin使ってできたらいいね？ いいね？

OSSで会社を興すには

※資料公開なし

Jenkinsの生みの親（前身であるHudsonを開発した）川口さんのセッション。

Jenkinsを使って開発コンサルティングしたり、Jenkins自体にコントリビュートする会社Cloudbeesを設立している。

OSSを使ってマネタイズするには大きく次の戦略がある。

  • プロサービス（使い方教育）
  • 商用版パッケージの開発
  • SaaS提供
  • サポート

マネタイズできるようになっても、そのまま安泰ではない。

これまでのコミュニティのモチベーションと、どう向き合っていくかが大切。

企業化することで、コードレビューなどが厳しくなり、コントリビュートのハードルが上がってしまう問題。

コミュニティの大半がいつのまにか同じ会社になっていて、OSSなのにぜんぜん参加者の平等感がないじゃん問題。

色々大変なことばかりだが、OSSで会社を興すというモチベ―ションは、OSSというソフトウェア開発パワーのすばらしさを感じているから。

Dockerのように2、3年前には名前も聞かなかったソフトウェアが、いま全世界で使われている。このパワーがOSSにはある。

ブランド・商標には気を付けよう（迫真

所感

OSSコミュニティのパワーの大きさはすごい。

ソフトウェアの本質はソリューションにある。それが中の人の発想の問題で実装されなかったり、しがらみで停滞したりすることは、もったいなさしか感じない。

私もOSSのパワーにより加わっていきたい。

参加したセッションは以上です。

懇親会のLT？ 酒飲んでてよく覚えてません（銅鑼で中断されてましたし笑

総括して

大きく２つのトレンド（というとすごく軽く聞こえてしまうので、問題提起と言いたいけど、じゃあ答えは・・・と問われるのもいやらしいのでトレンド）があると認識しています。

マイクロサービスアーキテクチャ

どうしようもなく、ハードウェアは壊れるんですよね。（ここでAS400は壊れない、という人は間違いです。AS400も壊れます。値段に比例した分だけに壊れない、というだけです）

単一のハードウェアの性能の限界も来ているのは既知の事実（ノイマン型コンピュータに代わる方式が出てくるか、新しい導体物質が見つからない限り……）。

その解決策として有力なものと認識されていて、ある程度の実績もあるマイクロサービスアーキテクチャに焦点が集まるのは、自然な流れだと思います。

そして私も、この解決策には同意します。ぜひ、マイクロサービスアーキテクチャについては追及していきたいですね。

OSS

というよりはコミュニティ、どれだけの人数がかかわっているかによって、そのパワーや安定性は比例してくると思います（安全性も、比例するかとは思われます）。

それは開発参加者の人数ではなく、利用者の人数です。

Jenkinsの川口さんも何度も名前を出してた「Docker」が典型例です。

対極にいるのは「自社製品をつくるぞ！」と名目だけで躍起になっている人や、SIでいえば業務画面を作ろうとしないアーキテクトのような感じです。

ソフトウェアは、使われてなんぼ、というのがよくわかる流れですね。

という考えを踏まえれば、別にオープンであることは必要条件ではありません。

そういう意味では、Java EEが新しい視点というか哲学への第一歩を踏み出したことは、とても期待できると思います。

最後に

L3セクションの @khasunuma さんもおっしゃっていましたが、「銀の弾丸はありません」。

名前として現れたマイクロサービスアーキテクチャやOSSについても、鵜呑みに取り組むだけでなく、その歴史・存在意義／哲学・有用性によってもたらされる効果をよく考えることが大切です。

として、まとめを終わりたいと思います。

一方そのころ・・・

私はhubotで宮森あおいちゃんと無能（まさに人口無能）な会話を楽しんでいます。

f:id:saikou9901:20170507200806p:plain