せてぃーずノート

Javaのイベント参加レポートとかを書いたりします。

JSUG勉強会 2018年その3 LT大会に行ってきたしん!

興味深かったところをメモ

Kotlin

  • IDEAのktファイルにJavaソースを貼り付けると変換してくれる?
  • Dataクラスが1行で書ける
  • NPEに遭遇しなくなる
  • 書籍はKotlin in Actionおすすめ

バナー

Spring Bootのバナーを生成するサイトがある

Spring Boot banner.txt generator

何でも貼れるけど、エラーメッセージはやめた方がいい(新人がみたらパニックになる)

2.0でアニメーションgif対応

Spring Bootの起動を早くする話

本番では使えないけど階層型コンパイルバイトコード検証オフで起動が早くなる IDEAで実行する場合は自動的に指定される

GraphQL

RESTに変わるAPI

github.com

でも辛いところもある

ペイロードのバリデーションでBeanValidationが使えない クライアントサイドでやれという思想らしい

エラー時に何でもかんでも500返してしまうので自前で実装

Spring MVCの外のライブラリ。 AOPとかは使えるけど、Spring MVCの機能は使えない

Spring Data JDBC

Spring Dataだけど、DBアクセスの実装は提供しない
CRUDRepositoryの実装をMyBatisとかから選択できる
デフォルトはSpringJDBC
ストラテジーを自分で定義すれば、好きなORMを使える

宣伝

SpringFest 10/31
会場は両国KFC

Spring Securitでハードウェアトーク

Web AuthorizationがW3Cで標準化
FIDOを利用して2FAとかできる

Web Authorizationはユーザーとクライアントプラットフォーム、クライアントプラットフォームとサーバーで認証が分かれるからセキュア

SpringSecurityで実装したのは↓

github.com

まとめ

ちょっとしたハックから普段の工夫まで色々な話が聞けてよかったです
来月もJSUG勉強会は開催予定なので楽しみ

JJUG ナイトセミナー 「Java SE 10 / JDK10リリース特集」に行ってきた

花粉症つらい・・・

お知らせ

JavaDayTokyo2018

5/17(木)に決定。
キーノートはMark Reinhold(初来日?)
登録サイトは近日オープン(多分、今週後半くらいとのこと)

JJUG CCC 2018 CfP募集中

JJUG CCC 2018 Spring

JDKリリースモデル変更について(おさらい) by 伊藤 敬さん(Oracle)

Java 10はおそらく初めて予定通りリリースされたJava
リリースノートには削除予定APIも記載されているので確認しておくこと。

JDK10の追加機能解説 - JEP286/ローカル変数の型省略(var記法)を中心に

ローカル変数の型推論

冗長な変数の型の宣言をvarに置き換えられる。
動的言語になるわけじゃない。
メソッドの引数・戻り値には使えない。
また、匿名クラスにも使えない。

varは予約語ではないキーワード。
そのかわり、クラスやインターフェースでは使えなくなった。
(非互換だけど、流石に使ってる人いないよね・・・)

変数やフィールド、メソッドでは使えるからこれはOK。(絶対やるなよ的な・・・)

var var = var();

varの使いどころは、読みやすさが向上する箇所。
Javaの書きやすさより読みやすさを重視している文化は破っちゃダメ。
型をタイプするのが面倒とかそんな理由で使ってはダメ。

IDEがなくても理解できる状態で使うべき。
マウスポインタを上に乗っければわかるはNG。

varのガイドラインも出ている。

orablogs-jp.blogspot.jp

GCの変更

G1のパラレルFullGCが追加された。
でも、G1GCを使っている時にFull GCを起こした時点で負けなので、恩恵を受けないような運用が理想。

Garbage-Collector Interfaceの追加で、GCをモジュールとして追加削除できるようになる。

ZGC

https://wiki.openjdk.java.net/display/zgc/Main

4TB(!)までのヒープに対応。
ヒープサイズに関わりなく、Stop The Worldを10ms以下に抑えるのがゴール。

Java 10でぼくたちの生活は どうかわるの?

今まではすぐにでも欲しい便利な機能でも、追加されるのが3年後だった。
それが比較的すぐに手に入る。
でも、アップデートに追従するコストが大変。

新しいバージョンへの対応方法
  1. とりあえず動かして見る
  2. コンパイルして動かして見る
  3. 非互換・非推奨APIを見つけ出す(jdeps、jdeprscan)
  4. 機能テストを行う

新しいバージョンの変更箇所は、以下の

  • JEPから新機能
  • 最新のJRSからAPIの変更点
  • リリースノートから非互換

STSで非推奨化・削除と続くと、LTSから次のLTSにいきなり移った時に、サイレント削除が発生する可能性がある

Java 8からJava 9への移行がとにかく大変。
そこを乗り切ること。

Class-Data Sharing

元々はコマーシャル機能。
クラスデータを複数のプロセスで共有する。
バッチとかのプロセスをたくさん起動するアプリで利用できる
読み込むクラスの量が多いほど効果的

APIの変更

OptionalにorElseThrowが追加。
getよりこちらを利用すべきと書かれている。

List、Set、MapにcopyOfメソッドが追加。
変更不可のコピーを返却する。
引数が変更不可の場合は引数をそのまま返す。

プロセスIDが取れるようになった。

Javadocにサマリーを出力するアノテーションと、ヘッダーとフッターの編集が追加。
会社で使うときとか便利そう。

感想

Java 9から半年だけど、機能追加が非常に多い印象。
Java 8からJava 11に移行すると死ねる未来が見えるので、それまでのどこかでは試しておかないといけないなぁ・・・。

あとはJavaとは関係ないですけど、神宮球場の桜がいい感じに綺麗でした

Spring Fest 2017に行って来た

Springの祭典! JJUG CCCの興奮冷めやらぬ中(?)のイベントに参加して来ました。 詳細はqiitaにまとめるとして、セッションの感想を中心に

詳細なまとめはすでに誰かがやってくれてるので・・・

セッションの感想

Introduction to Spring WebFlux

Spring WebFluxをSpring MVCとの違いを絡めつつわかりやすく説明したセッション
JDBC使うときはWebFluxにしない方がいい等の、移行する際のポイントもきちんと抑えて説明があった

Spring Security 5 解剖速報

Spring Security 5の変更ポイントに絞った解説

ドメイン駆動設計のためのSpringの上手な使い方

エンジニアならコードを書け!
Excelパワポ作るんじゃなくてコードを書け!

Quick start Spring Boot on OpenShift

Kubernetesを使うかOpenShiftを採用するかどうかプロジェクトで決めないといけないので聞く。
Spring要素はあまりなく、OpenShiftの紹介だった気がする。

The Road to Serverless

なんか、コレジャナイ感があった Fnのように、実行環境とファンクションが分かれてるのではなく同一のJarにパッケージング?
それサーバーレスなの?

Spring BootとSpring Cloudで始めるマイクロサービス

一通り通した解説や考え方が盛り込まれていてわかりやすかった
でも、セッションの中で初心者向け(?)と言っていたけど、初心者ついてこれないっしょと聴きながら思った
守破離の守を再確認させてくれるけど、守にすらたどり着いてない人orこれから入門する人には辛いかも?

全体通しての感想(というか気になったこと)

会場も広く、去年のようなすぐに会場がいっぱいということもないし、セッションはいずれも高品質だった。 個人としては不満はないし、むしろこんな素晴らしいイベントを開催してもらって感謝の念しかない。

個人じゃなくてもう少し広い観点で考えてみる。

Java EEの停滞や脱Struts、マイクロサービス等の理由でSpringは非常に注目を浴びているフレームワークである。
このイベントには、Springを知らない人や移行先の候補としてのSpringを知りたいという理由で参加してる人も多かったのではないか? でも、Springをある程度知っている開発者じゃないとついていけないセッションも多かった気がする。
例えばSpring Security 5の話もSpring Securityを理解してないとピンと来ない。

Springをこれから始める人向けに、Springの目指すとことか考え方的な説明をする本当にSpring知らない人向けセッションがあってもいいと思った。
(なら、お前やれよ?でも、僕もSpring3から入った新参なので許してクレメンス・・・)

最後に偉そうなこと言っちゃってますが、自分にとっては最高すぎるイベントでした。

JavaOne 2017 報告会へ行ってきた

ようやく風邪から治ったので初投稿です。

Javaの方向性

Javaのキーワードにnimbleが新しく追加。
nimbleは軽量、素早さ。
ITの変化の速さに対応していく。

Javaのリリースについて

まず、OracleJDKとOpenJDKの技術差を1年かけてなくす。
ソースコードは一本化。

OpenJDKは6ヶ月ごとのリリース。
LTSはなしで、6ヶ月ごとに最新版にアップデートして使う。
OracleJDKと技術的な差分がないバイナリ配布。

OracleJDKの無償版は18.3まで。
18.9以降は3年ごとに8年間のLTSがある有償版。

http://www.oracle.com/technetwork/jp/java/eol-135779-ja.html

次の機能リリースであるJava SE 18.3スケジュールや追加される機能は

http://openjdk.java.net/projects/jdk/18.3/

Java EE

間違えやすいけど、EE4Jは移管プロジェクト名。
ブランド名はこれから決める。
速度が落ちるのでJCPのような仕様策定の標準化はしないけど、JSRのような仕組みは取り入れる予定。

OracleJava EEサポートに関する既存のベンダー(日本だとNEC富士通とか)との契約は尊重。 ライセンスやJava EEの認定も引き続きサポート。
Java EE 8は2025年まではサポートするので、ベンダーはその間にEE4Jへの移行方針を決めてほしい。

その他

IntelがPM(Persistent Memory)に合わせてJavaに力を入れている。
PMはDRAMより大容量で価格が安い代わりに速度は遅い。
Javaでは揮発するヒープとしても、永続化先としても使える。
揮発するヒープとしての用途はビッグデータやインメモリDBのような大容量を使うアプリ。

マイクロサービス関連は細かい実装よりも取り組んだ事例や組織面のセッションが多かったらしい。
フレームワークやライブラリは自前で開発したりラッピングするものではなく、consumeするもの。
それよりも、「サービス」という部品をどう協調させていくかが重要。

コミュニティ関連やフォトセッション、LTは非常に面白かった。
ただ、写真で見るのと現地に行ってその場の空気を感じるのは大きく違うと思うので、機会があれば是非行きたい。

Mackerel / NewRelic / Elasticsearch Seminarに行ってきた

奇跡の二日連続更新なので初投稿です。 モニタリングをテーマに、3つのツールの違いがよくわかるセミナーでした。

ご挨拶

モニタリングをしていないとサービスが動作しているかもわからない.
十分な考慮の元で設計されたモニタリングインフラストラクチャが重要.
十分な考慮=ビジネスの特性等を把握.

Linux OSから見るMackerelのパフォーマンスモニタリング

何を見ればいいかわからない
グラフを見てもどこが悪いかわからない
そんな人向けのLinuxのモニタリング

  • Mackerelの特徴

    • もともとははてブはてなブログを監視するツール。10年前から使っている
    • 3年前からSaaSとして公開。はてな自身がエンドユーザーでもあるのでUIには凝ってる
  • 利用には、サーバーにMackerelエージェントをインストールだけ。エージェントからMackerelのSaaSHTTPSで送信。

    • Mackerelからエージェントを導入したサーバーにアクセスすることはないからセキュア

Linuxモニタリング

ロードアベレージ

  • 実行待ちのプロセス数とディスクIO待ちのプロセス数の合計
    • 高い場合はCPUやディスクIOが詰まってる状態
    • uptimeやtop等で確認できる
  • uptimeの数値は1分間、5分間、10分間の平均
  • Mackerelは標準で5分平均をサポート

CPUの使用率

100%の場合、どこが使っているかを知るのが重要

  • topコマンドのCPU使用率は全コアの合計。1を押すとコア別に見れる

モリーディスクioFSは省略.
Mackerel本を読んでね.

モニタリングしたものをどう活躍するか

根本原因をどうやって見つけるか

  • ロードアベレージのアラートは処理がさばききれてない可能性。ただ、即障害とは限らない
    • スパイクなら問題ない
    • 負荷がかかっているコアが1個なのか全部なのか
    • 継続的に見ないとダメ
  • 「実際にさばいている処理<捌くべき処理数」の状態が継続していないか?
    • 高まり続けているのは処理待ちがたまり続けてる
    • 高い場合でもコア数を確認するのが重要
  • CPUかディスクがボトルネック
    • CPUのメトリックから原因を読み取る
  • ディスクIOの場合はSSDに換装する 

  • userが高い場合はアプリケーションのループや処理が原因

    • 金の弾丸(コアを追加、コアのスペック向上)で解決できる場合も
    • 1個のCPUで止まっているなら、コアのスペック向上
  • CPUが常に低い場合はサーバーがオーバースペック。コストダウンのチャンス。

まとめ

  • パフォーマンスモニタリングは難しい
  • 見るべき値や条件はサービスやサーバーの役割でちがう(Webサーバー、DBサーバー)
  • 勉強しておけばアプリエンジニアとしての付加価値に
    • スパイクなのか少しずつ上昇しているかを知るためには時系列データが必要
    • 過去のデータは取れないからモニタリングツールは重要
    • 問題が起こる前兆もわかる

QA

  • Q:コマンドで監視できるけどMackerelを導入する理由は?

    • A:コマンドを打たなくてもよくなる。毎分実行、加工、失敗した時云々・・・。DB、グラフ、分析を自分でやらなくていい。
  • Q:HinemosとかZabbixとのちがい?

    • A:セルフマネージドは監視対象が増えた場合のチューニング等のメンテナンスを自分でしないと行けない。 また、Zabbixを監視するZabbixとかも必要になる。 MackerelはSaaSなので何もしなくていいし、他のツールやサービスと連携できる

New Relic によるアプリケーションパフォーマンス監視入門

New RelicはSaaS型のパフォーマンス分析ツール。
パフォーマンス、アラート、障害分析機能(切り分け)等様々

APM

  • APM=ApplicationPerfomanceMonitoring

    • エージェントをインストール
    • Java、Go等の7言語に対応
  • 遅いトランザクションや直近のアラートが観れる

    • アラートは集中管理。通知チャネルや設定条件が豊富
  • ダイナミックベースラインアラート

    • 普段の振る舞いと違った動作をしたらアラート。機械学習で過去の傾向を分析
  • トランザクションタイムからどのトランザクションが遅いかわかるので深掘りすることが可能

    • アプリのどの部分で時間がかかっているか
    • SQLの場合、発行されたSQLと時間
    • 外部サービスにかかった時間も観れる
  • 内部サービスの呼び出し階層が観れる

    • 一覧で赤いとアラートが発生している
  • インストール後にアラート設定とユーザー満足度(平均レスポンスタイム)の閾値を設定することを推奨

  • デプロイトラッキングで、トラブルが多いデプロイしたタイミングを監視できる

    • デプロイ前後のパフォーマンスが比較
    • デプロイした時刻が残るので調査に役立つ

応用編

ソースコードを修正することで、さらなる情報取得が可能

  • カスタム属性

    • 例えばECサイトのマルチテナントでショップIDをカスタム属性として追加
    • ショップごとにパフォーマンス追跡が可能
    • 入れない場合、アプリ全体でしか見れない
  • カスタム計測

まとめ

  • NewRelicはAdobe、Sansan、楽天

    • パフォーマンスに売り上げに繋がるサービスで多く採用
  • ブラウザの監視も可能。アプリケーションの監視と組み合わせ、1つのダッシュボードで観れる

  • 最新動向としては、AIに注力

    • 過去のデータから今後パフォーマンスで問題になりそうな情報と対策を提供
  • NewRelicを導入して開発とインフラのコミュニケーションが改善

    • インフラチームが最初に障害に気がついたとき、エビデンスを持ってコミュニケーションできる
    • 開発もパフォーマンスに対する意識が高くなった

Elastic Stackによるログの監視入門

ElasticStackは100%OSSで有償サポート
ELKにBeatsというOSSが追加された.
バージョンを5.0で全部統一

昔はバージョンが揃ってなかったので、間違った組み合わせで使って「動かない」というissueが乱立

Beat

  • Go言語エージェント。
    • データがあるところに仕込むと取り出してくれる
    • 送り先はSearchかLogstsh
    • File、メトリクス、ネットワーク、Windowsイベントログ、パケット、そのほかにも色々

Logstash

  • Rubyで書かれている
    • JRubyで実装されているため、Javaが必要だった
    • フィルタリングのようなパイプライン処理が可能

ElasticSearch

Kibana

  • nodejs
    • ElasticStackの窓口

導入とか

  • 大規模な場合はBeats→kafka→Logstashの構成でElasticsearchの負荷を下げる

  • nginxやApache2のログは、ファイルの場所とElasticsearchを指定するだけ

  • PacketBeatsはプロトコルを監視

  • パケットを指定するだけなので再起動は不要で後から差し込める。

    • オーバーヘッドがそこそこある。本番ではパケットをミラーリングして監視するといい
  • FilebeatやLogstashは1行1データではなく複数の行も観れる

    • パターンマッチを利用する(先頭がスペースだと複数行のデータとして扱う)
  • X-PackはClosedソース

    • 検索のクエリでアラートが可能(Kibanaにはアラートがない)
    • 例:10秒以内にエラーが5件
  • 機械学習でパフォーマンスを予測した曲線

    • NewRelicと被ってる
  • Elasticsearchは検索エンジンなので、パターンでログを検索して、それ以外のログが出たらアラートといった使い方のできる

感想

あまり情報を追いかけていない分野だったけど、サービスのクオリティが非常に高いと思った。

どのツールも得意な分野があるので組み合わせて使うのがいい感じ
先日のioドメイン障害といったリスクもあるけど、SaaSにお任せは楽だし機械学習で障害傾向の分析まで自分で構築するのは困難。機会があれば積極的に利用していきたい.

JSUG勉強会 2017年その7 俺たちのマイクロサービスへ行ってきた

週末風邪で倒れてたので初投稿です。
教科書の話ではなく、実プロジェクトの経験ベースの貴重な発表がきけました。

無理をしないマイクロサービス

資料は非公開。
実際にマイクロサービスを導入したときの話。

無理をしない

自分たちの体制や得意な技術に合うやり方で、これまでやりたくてもできなかったことをする。

実際にやったこと

  • 最初はBigMonolith。リリーススピードをあげたい

    • コンフリクトが発生すると解消に時間かかる
  • バックエンドをチーム毎に分割して、フロントエンドにUIサービスを置いてAPIで呼ぶ

    • フロントエンドのUIが全チームで共有するため、フロントエンドでコンフリクトが発生
  • コンポーネント指向のSPAやBFFは、サーバーサイドスキル中心のチームで採用するのは厳しい(無理をする)

  • 各サービスがUIまで持つ完結したアプリケーションの構成

    • 注文、カート、オーダーといったアプリケーションが画面遷移で繋がってる構成
  • ユーザー情報の連携はもともとあったSSOの仕組みを利用

    • cookieにJWTで暗号化したユーザー情報を保存してサブドメインで共有
    • PreAuthenticatedAuthenticationを利用して連携
  • リンクのURLはSpringCloudConfigで一括管理

    • 開発中とプロダクションで値の切替もできる
  • 他のサービスと連携する部分はAPI

  • API呼び出しで障害が発生すると、障害の連鎖で最悪LBがダウンする

    • 障害の連鎖を防ぐためのサーキットブレーカー(Hystrix)の導入
    • Fallbackが注目されがちだが、障害の発生したAPIにアクセスさせないことが重要な目的
  • APIにHystrixのアノテーションを書きたくないため、APIゲートウェイを導入しそこでサーキットブレーカーを設定

    • 各チームの作業コストは0
  • Zuul2の開発は停滞中。yamlで定義がかけるSpringCloudGatewayが開発進行中

  • サービスディスカバリーは使わず、Cloud FoundryのRouterを利用

    • Cloud FoundryではLB→ルーター→サービスという流れになるので、パフォーマンスを気にする場合はサービスディスカバリーを導入すべき
  • サービスディスカバリーの種類

    • 名前解決:DNS、REST
    • 提供方法:アプリ、プラットフォーム
    • EurekaはREST、アプリ
    • ConsulはDNS、アプリ
    • k8sはDNS、プラットフォーム
  • CloudFoundryもサービスディスカバリーをプラットフォームで提供する予定

    • アプリケーション側ではなく、プラットフォーム側でやるべき
  • 最近はEnvoyがホット

    • サービスメッシュを形成する
    • メッシュを管理するIstioもホット

envoyproxy.github.io

istio.io

  • APIでクラスを共有すると、サービス側の変更でクライアントも影響を受けるので、サービス側がクライアントを提供する

    • 破壊的変更がない限りは影響なし
  • k8sやCloudFoundryのようなXaaSを利用する

    • k8sはコンテナから先を実装するCaaS
    • CloudFoundryはコンテナやランタイム/ミドルウェアまでをプラットフォームが提供
  • Spring Bootはコンテナにする利点があまりないのでCloud Foundry

    • コンテナにしてもjava -jarをするだけ
  • CI/CDのパイプラインはconcourse

重要なこと

  • やりたいこと(これまでできなかったこと)が解決できているか
  • 技術を目的にしない

俺のマイクロサービス

  • マイクロサービスは目指すものではなく結果論
  • マイクロサービスには守破離の守がなく、こうやれば始められるというものがない

ECサイトの例

  • もともとはオフショアで作られたシステムで品質がひどい
  • HTML5+Java APIで作り直した

    • 既存システムに比べて安定したが問題も
  • APIが画面項目とひも付き、再利用できない

  • RDBの負荷が高い
  • Tomcatを再起動するとセッションが初期化されるため、誰もアクセスして来ないであろう深夜にしかリリースできない
  • 非同期処理がやっつけ

15のやったこと

1.SpringBootの導入

2.サービスディスカバリーとロードバランス

  • Eurekaを導入。サービスメッシュは検討中

3.キューイング

  • ファイルでやってたところを、オープンな仕様のAMQP(RabbitMQ)を導入
  • 今ならSpringCloudStreamとkafka使うかも

4.セッションレプリケーション

  • SpringSession+Hazelcastを利用。今の所は問題ないが、ヘビーに使い込んでないので、後ほど再評価したい

5.Versioned Platform

  • Sprong+Javaで統一し、親Pomを各サービスで共有

6.shared interface

  • 共通のインターフェースを提供し、コンパイルエラーで気付けるようにする
  • 便利だったけどMSAっぽくないと言われる

7.client library

  • 6はコンシューマーでインターフェースを実装しなければならず、同じコードがたくさんできて効率悪い
  • 実装したクライアントをサービス側で配布。コンシューマー側の実装が楽に。

8.service unit test

  • 各マイクロサービスは、Controllerに対してJunitテストを書く(必須)
    • 別サービスの呼び出しはモックにする。Mokitoとかつかわず、オーバーライド。
  • 複雑な計算等不安な部分は局所的に書く(任意)
  • Http通信の部分はSpringbootを利用
    • 正常系、異常系のJSONやバリデーションをテスト

9.Service integration test

  • サービス結合で期待したデータと違う等のインターフェース齟齬が発生し試験が進まなかった。
  • 複数のマイクロサービスを手動で立ち上げてテストする
    • 実行をjunitにしておけば残しておける
    • 数ケースだけでもかなり問題が検出できる(それくらいインターフェース齟齬が多かった)

10.CI/CD

  • AnsibleとJenkinsを利用して環境構築を自動化
  • APIのバージョニングをしていなかったので困っている。バージョニングはすごく重要

11.monitoring

  • 障害がユーザーからの問い合わせで発覚することが多く監視が必要
  • elasticsearchをつかって全サーバーのCPU、メモリ使用率、ディスク使用率やログを採取
  • ログは5分間でてないと異常と判断
    • 既存メッセージを取り除いて、未知のメッセージが出ているか調べる
  • 気づかれなければいいで片付けない。

12.Frontend service & backend service

  • 再利用できるバックエンド、再利用しない前提のフロント

13.serverless

  • AWS LambdaをPythonで利用
  • バッチや非同期処理で使っている。APIでは使ってない

14.separated data store

  • RDBMSだと1つのJSONを保存するのに8個のテーブルを更新しないと行けないばあいがある
  • 使いやすいKVSを探しているが見つからない

15.イベントソーシング

  • 買い物かごのAPIを、データベース視点のCRUDや追加・削除のようなビジネスロジック的なAPIではなくイベントを登録するAPIだけ提供

    • 商品を入れる、出すを全てイベントとして記録する。
  • データ不整合が発生しても、イベントなら何が原因かがトレースできる

  • 処理の追い越しや不正な遷移が発生したときの対応は検討が必要

これからやりたこと

  • サーキットブレーカー、リアクティブAPI、コンテナやプラットフォーム

感想とか

  • 手段を目的にしないことが大事

  • 自然と教科書の構成に近づいていく

    • 教科書的な構成に合わせなくてもいい
    • 自然と似てくる
  • サービスメッシュとか知らない言葉が増えてたので、常にトレースしていくのが重要

JSUGからのお知らせ

  • 11/24にSpringFest2017

    • 会場は両国KFCホール
    • 前回と同じく400〜500人の規模を想定
  • 来月の勉強会は10/27。会場は恵比寿のRedhat

JJUG CCC 2016 FALLに行ってきた

秋・・・というツッコミはさておき、2年ぶりにJJUG CCCに行ってきました。 感想は順不同で印象に残ったものから。

懇親会は出たかったけど、風邪がヤバイことになっていたのでパス・・・。

リンク

エンジニアの生き方的セッション感想

日本でも出来る!最先端のDevOpsを導入する方法

DevOpsというコール・アンド・レスポンスから始まったセッション。 DevOpsについての非常に熱くそして濃密なセッションでした。

  • 人・プロセス・プロダクトのどれかが欠けてもダメ。
    ものすごいオートメーションを実現しても、リリースに誰かの承認が必要という人の面が欠ければ1日10回デプロイは絶対無理。

  • 頑張って時間をかけて準備しても、本番にデプロイしたら誰も使ってくれないことだってある。
    本番はフィードバックを貰う場所。
    未来は予見できないから、フィードバックから学ぶ。

  • マイクロサービスに入社して上司に指示を受けたことがない。ただ「ハッピーか?」と聞かれるだけ。
    ハッピーでないのであれば、その問題を一緒に解決してくれる。
    上にお伺いを立てないからスピートが上がる。

  • 日本は106カ国で一番アジャイル導入が難しい国。
    でも、アジャイルの土台にはトヨタ方式や守破離という日本文化がある。
    その隙間を埋めているのは西洋文化。
    彼らの思考パターンを理解することが重要。

  • 日本の生産性が低いのはUSが優秀なわけじゃない。
    USは予定されたタスクのうち、大事なことしかやらない。
    タスクのうち、無駄なものは計画的に捨てる。 日本は全部やろうとする。
    差し迫ったものから、重要かどうかに関わらずをやる。
    結果として何もかも中途半端になりやすい。

  • 準備に対する考え方。
    知らなくてもやってみる。やってから考える。
    ソフトウェアの世界で、やってみる前にすべてに備えておくのは難しい。 とりあえずやってみて、やっている間にバリューを見つけ出す。

別に海外がみんなこうだとは思わないし、日本にだってすごいチームはある。
でも、ツールや外側だけを一生懸命取り込もうとしたり、自分たちの組織を変えずにアレンジとかいう体のいい言葉で逃げるのは意味が無い。 考え方を変えないといけないときに来ていると実感。

自分の場合、「とりあえずやってみて、やってる間にバリューを見つける」は欠けてると思う。
色々勉強してきたことからから来る変な思い込みというか見切り。
「やらなくても何となくわかった気になってしまう」というのは悪い癖だと思うので変えていかないと・・・。

JAX-RS REST Client で Cognitive Service や Excel を操作しよう

セッション最初に流れた、ITが目の見えない人をサポートしているビデオ。
ビデオが終わった後、寺田さんが言った「ITサービスが人の役に立つと本当に実感出来るようになった」
これが全てだと思う。

Be a great engineer!〜 フォローすべきトレンド、スルーすべきトレンドをどう見抜くのか

起こっていることを本当に理解しているか?
どのトレンドをフォローし、スルーすべきか。

午後のDevOpsのセッションと組み合わせて考えるとより素晴らしいかも。
いくら「とりあえずやってみる」でも時間は有限。
全部の技術を試すわけには行かない。

技術的なセッション

詳細はスライドにあるので感想をば・・・。

Selenideを試行錯誤しながら実践するブラウザ自動テスト

WebDriverを使いやすくラップしたフレームワーク
Codeboneというエストニアの会社が開発。

Jqueryの$ファンクションでエレメントを指定できたり、Ajaxアサーションを楽に書けたりと、テストが非常に書きやすくなっている。
テスト失敗時に自動でスクリーンショットとHTMLを保存してくれるのはいいと思う。

Payara Micro の設計と実装

Payara Microの仕組みに特化したセッション。 以前、一度試したことがあったのでスムーズに聞けた。

Java EEのマイクロプロファイルがどういう形式になるか分からないけど、Payara MicroはGlassfish使った事ある身としては入りやすい。

Java EE - What's Next?

Java EEの方向性の話。
今までのJava EEがやってきたように、マイクロサービスにおける標準規格を作っていきたい。

「そんなこと実現出来るのかー?」と言うのが今のところの感想。
Java EEと同じやり方であれば、規格に合わせて各ベンダーがミドルウェア出すわけだけど、マイクロサービスまで含めたミドルウェアなんて製品に出来るのか・・・?
クラウドベンダーの依存も何らか発生しそうだし。

あと、Java EE 9の参照実装についてGlassfishってハッキリ言わなかったのも気になる。 それでもマイクロプロファイルは期待。