Seeing is believing

いちエンジニアの日々の興味のあるところ、イベント参加記録、学びの共有を取止めなく※このblogは個人の見解であり所属する組織の見解ではありません

今年学びたいこと

元日ということで、今年やりたいこと、学びたいとを、メモ。

ブログする頻度あげる

社内での発信にさらに力を入れる

マイクロサービス関連のアンテナ高める

WEBAPI関連も同様

リアクティブを正しく人に伝えられるように理解する

外部講演(登壇)を2回以上

フロントエンドも追う

アジャイルスクラム)の良さを真に理解、これまでのコンテキスト異なる人にも分かりやすく伝える

 

頑張ります。

JSUGイベントSpringOne Platform 2018報告会メモ

SpringOne Platform 2018報告会

SpringOne Platform全体所感

  • NTT 岩塚卓弥さん、NTTデータ 岩本純佳さん
  • 前身カンファレンス(Groovyとかといっしょの時代とか)からくらべて10年目
  • スポーサーとして日本からはNTTDataと富士通
  • セッション150個のうち、一番多かったのはケーススタディ
  • Springのセッションがそこまで多くなかったのは前年にSpring5のメジャーバージョンアップがあったから
  • JDK11使う人はSpring5.1を使う
  • 5.2は6月リリース予定
  • 5.1は去年発表のリリース予定から数ヶ月遅くなったので、5.2も遅くなる可能性あり
  • 関数型スタイルVSアノテーションスタイル
    • これからも両建て
    • 関数型スタイルも選択できる
      • パッケージスキャン不要
      • KotrinDSLで簡潔にかける
  • フレームワーク内のリフレクション使用の最適化
    • Spring5.1(Boot2.1)にするだけでヒープサイズ、起動時間が少なく短く起動できる
    • 関数型Bean定義で明示的に定義するとさらに早く起動できる
  • GraalVMによるnative imageへのコンパイル
    • GraalVMとはOracleOSS公開している多言語対応VM
  • Spring5.2
    • JDK12のサポート
    • GraalVMへの完全対応
    • Kotorin1.3の完全サポート
    • HibernateORMの5.3
  • DBS銀行の事例
    • 外注と内製の割合を逆転(8:2)
    • 技術の社内展開:技術者とのペアでの活動
    • 新規人材採用
      • 採用プロセスにオンライン技術テストやハッカソンを取り入れた(hack2hire)
  • https://codezine.jp/article/detail/11180

Spring Cloud Stream および2.1での新機能

  • Jia Xiaozhouさん
  • メッセージドリブンマイクロサービスのためのフレームワーク
  • Spring Integration + Spring Boot => Spring Cloud Stream
  • コンセプトはBinderレイヤを設けることによってアプリとミドルを疎結合(RabbitMQやKafkaなどをアプリからメッセージキューの種類を意識せずに使える)
  • 2.1ではSpring Cloud Functionとの連携
  • FunctionをBean登録、プロパティ指定するとイベント契機で呼べる
  • Function Compositoin:アプリに閉じたワークフローの定義ができる
    • Spring Cloud Data Flowとの連携も現地で話されていた
  • Source -> メッセージの源
  • Sink -> メッセージが流される場所(受け取る側)
  • Processor -> Source兼Sink
  • Functionの引数でメッセージを受けとって、戻り値がメッセージ送信になる
  • ActuatorエンドポイントからBinderを停止したり出来る

High Performance Batch Processing

  • アスクル 寺山さん
  • Spring Batchの情報が古いので参加
  • 半年前からBatch使っている
  • SpringBatchはStepという概念で管理
  • stepの途中で失敗したら失敗したところからリラン可能
  • stepはtasklet(読み込み、加工、書き込みに別れる)とchunk(それ以外)にわかれる

Reactor NettyネタとKafkaネタ

  • Yahoo! JAPAN 水落さん
  • PCFを利用
  • reactor-netty最新は0.8
  • Nettyネットワークプログラミング向けのフレームワーク(HTTP以外のTCPUDPも選べる)
  • スループット、複雑な非同期処理が求められるミドルウェア等の実装に向いている
  • non-bloking IO
  • WebFluxのデフォルトバックエンド
  • Springからみるとメタフレームワークと言える
  • Reactor NettyはReactor利用時のネットワーク通信全般に用いる
  • イベントループ前提
  • wiretapメソッドを入れておくと通信ダンプがログに出る
  • KafkaはStreaming Platform
    • Producer/Consumer
      • Kafkaにデータを送受信する基本的な機能
      • Producer/Consumer APIにより実装する
    • Connectors
      • Kafkaとデータ連携するアプリケーション
      • データソース、シンクごとに実装が公開されている(MySQL,Elasticserch)
    • Sreaming Engine
      • トピック間同士でリアルタイムにデータを変換、統合するようなアプリケーション
      • Streams APIにより実装する
      • 後述のKafka Streamsライブラリより手軽実装できる
  • KafkaStrems
    • Kafkaを用いたストリーミング処理を書くためのライブラリ
  • Spring for Apache Kafka
    • KafkaTemplete
    • @KafkaListener

R2DBCネタとRSocketネタ

  • Pivotal 槙俊明さん
  • SpringOne 2018 Ben Haleで検索して出てくる動画を参照
  • リアクティブプログラミング
  • Springの人たちが言うにはback pressureが大事
    • Reactive Streamのrequest(n)が大事
    • Subsctiverがボリュームかわりに流れてくるデータ量を調整できる(back pressure)
  • WebClientはリアクティブでなくても使えるので、おすすめ。シンプルに書ける
  • JDBCがノンブロッキングなので、別のものをAPIを作ったもの
  • OracleのADBAによい影響を与えたいという思いでSpringチームが開発している
  • Driver SPI(サービスプロバイダインターフェース)
  • JDBCっぽくかけるが、MonoやFluxで戻り値をもらえる
  • トランザクショナルなインサートも実現。スレッドローカルは使わない(JDBCだとつかっている)
  • SPIではなく、r2dbc-clientでハイレベルなAPIが提供されている。テンプレートパターン的な。
  • spring-data-r2dbcというとなりの存在のプロジェウトも。リポジトリインターフェースの作成だけで実現できる。リポジトリパターン。
  • WebFluxを使えばReactiveになるわけではない。書き方に注意。currectAllとかすると待ってしまうので、リアクティブではない
  • リアクティブアプリケーション間のback pressureを制御できあかった課題に対してのプロトコルがRsocket。L7のプロトコル(HTTPと同じレイヤ)
  • NetflixでrScoketを使っていた人がFacebookにいって活用していた人がキーノートに
  • Netflixでは今はあまりrSocketを使わずにgRPCを使っている
  • プロトコル定義なので、プログラム言語非依存(今はJS、Java、Kotlin、C++)
  • TCP直接使えないようなプラウザ上ではWebSocketを使ってその上でRSocketを使う。プロトコルなので下は意識しない。
  • マイクロサービス的な構成になった場合にRsocketを使うとback pressureを伝播できる。Istioと競合?
  • battle-flux-ui.apps.pcfone.io
  • Rsocketでクライアントからback pressureを設定できるデモ

20181120Eclipse 最新事情セミナー に参加してきました

20181120Eclipse 最新事情セミナー

  • Mike Milinkovich 氏(13年ぶりの来日)
  • Eclipseは2001年にIBMによってローンチされた
  • Eclipse Foundationは2004にできた
  • Eclipseとして注目しているのは4つ
    • Cloud Native Java
      • Eclipse Glassfish5.2でJakartaEE8に対応。2019年予定。
      • Jakarta EE9から、コミュニティ駆動に。対応するGlassfishの対応版は未定5.X。来年末ぐらいを目標としている。
      • Eclipse Glassfish5.1 12/14にリリース予定。Java EE8ベース。
      • MicroProfileも継続している
    • Eclipse IoT
    • Tool
      • Eclipse Che
      • 3年ぐらい前からやっている活動
      • コンテナ化されたワークスペース for クラウドネィティブ開発
      • 開発におけるチャレンジ
        • コンフィグとセットアップに1週間に24%も時間、コストがかかっている(新チーム参画の場合)
        • 開発ツールの開発にも41%もコストがかかっている
        • 顧客からみると生産性がないため、その時間は全く嬉しくない
      • デスクトップで仕事をするとセキュリティの問題がある
      • Cheの考えは、ブラウザIDE+Project Files + Runtime
      • easy to share + easy to Manage + Secure.クラウド側で集中管理
      • ワークスペースはこれまでと考え方が異なる
      • クライアント側はいろいろな選択肢がある。EclipseやVSC、IntellJとかもクライアントとして使える
      • チーム内のコラボレーションにも使える。設定の共有、集中管理も楽。
      • ワークスペース、サンプルの共有や、Pre-commit feedbackなど。
      • Gracpical Modeling ツール
      • System and Software Engineering : Capella
        • Siriusを使って作られている
        • アルカディアという開発手法で使える
        • 大規模開発向き
  • Eclipseの純粋なスタッフは30名ぐらい。あとはコミュニティで運営されている。
  • Cheの背後にはRedhatがいて、OpenShiftでもCheが使われている
  • Eclipseプラグインアーキテクチャは取っていない?
  • 次のTHEIAというプロジェクトがあり、フロントエンド向けに機能拡張していく予定。TypeScriptで実装されている。ブラウザIDEや、スタンドアロンでも使える(Electronアプリ)次のバージョンではクライアント側をこちらにしてくことが決まっている。
  • 過去にあったOrion多言語対応は優秀だった。この機能は今後THEIAにマージされていく予定。
  • 直前には中国にいってきて、JakartaEE,Cloud Java、Cheに関心があった。Cheについては、開発者増、セキュリティの観点。Citrilxだと大変だった。移行を考えているとの声もあった。

20180911 Cloud Native Meetup Tokyo #4

20180911 Cloud Native Meetup Tokyo #4

所感

  • いろいろ追いつけていないところが多く、キャッチアップが必要

istioとEnvoy

  • Istio
    • オープンサービスをマネージドプラットフォーム
    • それぞれのK8S上のサービスをproxyをサイドカーでチェックしてやりとりする
  • Istio 1.0の機能
    • mTLSの実装:mutual TLS
    • パーミッシブモードの場合、通信の最初の数十バイトを見て、TLSか、mTLSかを判断してどちらでもやりとりできるようにする
    • gRPCでMixerのデフォルトアダプターでサポートされた
  • envoy
    • 高いパフォーマンスでL4/L7を理解できるネットワークプロキシ
    • ロードバランス
    • L7(アプリレベル)でログが履ける
    • 1.7.1リリース
    • 1.8が9月末にリリース予定
    • 1.7 の新機能 
      • RBACのフィルター
      • ルートURL単位のHTTPフィルター
      • 別フィルターを複数設定できるように
    • xDS APIがある
      • LDS - Listener Discovery Service
      • RDS - Route Discovery Service
      • CDS - Cluster Discovery Service
      • EDS - Endpoint Discovery Service
      • SDS - Secret Discovery Service
      • HDS ー Health Discovery Service
        • HDSは、Envoy ProxyEndpointがnmでヘルスチェックしないように、分担する
      • ADS - Aggregated Discovery Service
      • UDS - Unix Domain Socke
    1. Envoyで実装された新機能はどの程度遅れてIstioに入るのか?
    1. Envoy自体はMasterがRCとしてReleaseまで早いので利用できるようになるまでは早い。Istioのほうで抽象化して利用可能になるまでに若干時間がかかるかもしれない。

Open Policy Agent is 何?

20180907 第2回enPiT-Proスマートエスイーセミナー: アジャイル品質保証と組織変革に参加してきました

20180907 第2回enPiT-Proスマートエスイーセミナー: アジャイル品質保証と組織変革

所感

  • 結構人が多く、熱心に聞き入っていた。
  • XP祭りの前夜祭扱いということで、会場下見もかねて?
  • アジャイルが不確実性への対応ということで品質はケースバイケースしかないと考えていたが、色々な整理の方法があることを知れてよかった。

アジャイル品質保証パターン: Quality Assurance から Agile Quality へ

  • Joseph Yoder(The Refactory, Inc.)
  • @metayoda
  • MVPではなく、MAP(Minimum amwsome product)
  • 課題
    • どうやってスケールするか?
    • セキュリティどうする?
    • テストは??
  • 成長するシステムは、非常に複雑で、多くの依存関係を持つ
  • Big Ball of Mud : スパゲッティコード
    • なぜデファクトスタンダードと、我々が実践すしていることのギャップが大きいのか?
    • なぜ高品質システムを構築したいのに、こうなってしまうのか。。
  • Financial Times でも取り上げれている
  • どうやってリーンでアジャイルであり続けられるのか? 開発の継続がポイント
  • ビジネスのS曲線。成熟してくると開発はなだらかに。
  • システムの品質
    • パフォーマンス
    • セキュリティ
    • スケーラビリティ
    • 可用性
    • 信頼戦
    • 保守性
    • 進化性
    • テスト容易性
    • デプロイ容易性
  • 最後の四つが開発スピードに影響
  • バリューがプラクティスを工藤する(Values Drive Practices)
  • アジャイル・リーン
    • イデアービルドー(コード)ー測定(Measure)-(データ)ー学ぶ(Learn)ーアイデア の繰り返し
  • 設計の価値
    • デザインのシンプルさ
    • 迅速なフィードバック
    • 頻繁なリリース
    • 継続的改善
    • チームワーク・信頼
  • Agile Development Accelerate Delivery(Wikiに図がある)
  • 品質面でアジャイルになる
  • 障壁の解体(打破する)
    • 物理、文化的な障壁、言語、コミュニケーションなど
  • 品質保証チーム(QA)
  • プロダクト、プログラムマネジメント、品質保障、アーキテクトの相互作用
  • 最終責任地点(Last Responsible Moment:最大限遅れさせられる地点)を選択する
  • Responsible Momentを計画する
  • 品質検討するためのロードマップを定める
  • 視認性(可視化)が重要
  • バックログを色付けし、アーキテクチャ作業の可視化と明治を行う
  • CI(継続的インスペクション)でコードの匂いを検出。メトリクス(テストカバレッジ、サイクロマティック複雑度などを)自動で計測
  • 改善するためには余分な時間が必要(Slack Time)
  • 余分な時間を可視化する。
  • ジャーニーである
    • コミットする
    • 徹底的に従う
    • ラクティスを熟慮する
    • 改善する
  • 参考
  • https://qiita.com/kenjihiranabe/items/a0795dbdab4c58e746a1

    OODAと品質保証:アジャイル開発に置ける品質管理のアプローチ

    • WFの品質保証のアプローチをそのままアジャイルに適応できない、という課題からくる
    • OODAループ
    • 戦局を左右するのは、情報量と意思決定のスピードである
      • 相手を観察、状況判断し、意思決定し、行動する
      • 相手も同じことをした場合、早く行動したほうが勝つ
  • ソフトウェア開発モデル:Vモデルにフィードバックを加えたWモデルがある
  • アジャイルの場合は、テストをOODAする。テストと学びを短いサイクルで実施、享受する
  • QAのアジャイルとは?Steleth:ステレス。開発の人からは見えない存在になれ。開発の初めから入り込め
    • ステルスモード:まずは見守る:朝会
      • 朝会の目的:リスクセンサー
  • DevQAとして、品質保証部門の関係も

高生産性と信頼性におけるアジャイル形式工学手法

  • Agile-SOFL
  • アジャイル手法を好きになれるか?
    • プロジェクトが小さい、短い場合はYes。(5000LOC,5ヶ月内の場合は気にせず導入すれば良い)
    • 大きい、クリティカルなシステムはNo。深い理解が必要になるため。バグに繋がってしまう
  • SOFL:仕様を書くことによってユーザーのニーズをはっきりさせる
  • セーフティとセキュリティに関するところはフォーマルに、それ以外はセミフォーマルでよい
  • テストデータの自動生成、テストの自動実行まではできる
  • 結果の分析が時間かかる

ソフトウェア工学の観点から見たアジャイル(

JJUG ナイトセミナー 「Java: Today and Tomorrow by Simon Ritter!」に参加してきました

【東京】JJUG ナイトセミナー 「Java: Today and Tomorrow by Simon Ritter!

所感

  • 前半はJDK10の振り返り、11およびその先の予定で、知っていること、知らなかったことが多く、フォローが必要
    • Metopolisなどは昨年のJavaOneでもテーマとして挙げられていなかったと認識。
  • 後半はAzul Zing JVMの紹介で、かなり理解が及ばないことが多かった
    • 大きな1つのヒープ(8Tbなど)でも利用できるとスケールが大きかった

以下それぞれのセッション中にとっていたメモ

Java Platform Module System (JPMS)

  • APIを安全に公開する。適切な公開範囲
  • jlink : The Java Linker(JEP282)
  • jlink --addmods でモジュール追加。作成したものを java --list-modulesで確認できる

OpenJDK;New Release Model

  • 半年毎リリース
  • LTSリリースは3年ごと
  • JDK8はLTS扱い
  • 次のLTSはJDK11
  • OpenJDK binaryはGPLv2with CPE license
  • JDK11からFlight recorderがはいる
  • Mission controlも
  • JDK 11から、Oracle JDKは商用サポート版のみ本番環境で使える
  • JDKをフリーで使い続けるには、半年ごとにバージョンアップするしか無い
  • Adopt OpenJDKであれば、無償でもLTSがある

JDK10

  • JEP 286 : Local Variable Type :var
  • Style guidelineが公表されている
  • http://openjdk.java.net/projects/amber/LVTIstyle.html
  • var itemQueue = new PriorityQueue<>();
  • PriorityQueueに推論されてしまうので、使い方良くない
  • List,Set,Map.copyOf(Collection)
  • Collectors
  • Optional.orElseThrow
  • JDK11

    • 17個のJEPs(内、3つがOracle外からのJEP)
    • JEP 209: Dynamic Class-file constants
    • remove CORBA and JavaEE module - moduleシステムがあるので不要
    • JEP 321 : HTTP Client ,JDK9でIncubatingモジュールだったものの標準版
    • JEP 323 : var でラムダ。(var x , var y) -> x.append(y) ;
    • 新規クラスは無し。メソッドは追加あり。

    Futures

    • Amber
    • Valhalla
    • Loom
      • fibres
    • Metopolis
    • Panama
    • Zule Java
      • free binary distribution of OpenJDL

    Building A Better JVM

    • 実際のJVM Performanceのグラフは、一定のところで頭打ちになる?それまで時間がかかる?
    • GCではポーズがかかる
    • Azul Zing JVM
      • GCはC4のみ(Continuous Concurrenct Compacting Collector)
        • Genarational(young and old)
      • AzulのJVM
      • Zingは大きなヒープでも問題にはならない
        • 8Tbまでスケールできる
        • 小さなヒープがたくさんあるよりは大きなヒープ1つの方がよい(効率的)
        • ただし、大きなヒープを必要としているものではない
    • How to implove JIT Comparation
    • Azul Falcon JVM Complier
    • ready now! save JVM JIT profileing information.
    • 最初のグラフはC4によりストップザ・ワールドがほぼなくなり、Falconにより頭打ち部分が少し下がった

    JSUG勉強会 2018年その5 Spring IO 報告会 に参加しました

    JSUG勉強会 2018年その5 Spring IO 報告会

    jsug.doorkeeper.jp

    全体所管

    • Reactiveあまり触っていない分、キャッチアップする必要あり。進化が早い!
    • APIについては、ケースバイケース。見極め力が必要
    • Spring Cloud Gateway, Spring Cloud Pipelineについては触ってみる価値あり。やりたい!

    • 会場:Pivotal @六本木ヒルズ20F

    Reactor, Reactive Data Access, REST beyond the obvious

    Flight of the Flux: A look at Reactor execution model

    • 元ネタスライド
    • サーバサイドのReactiveの話 。イベント=通信
    • データが発生するごとにどのようにデータを処理していくかの工程をReadableにわける
    • マルチスレッド、ノンブロッキング、並行処理、並列処理
    • functional interface
    • Reactorを支える技術要素
    • Nothing happens until you subscribe
    • Assembly time:subscribeするまではpipeline(工程、ステップ)が書かれているだけ
    • Execute time:タイミングが異なる
    • Debugモードにする魔法;Hooks.onOperatorDebug();
    • Debugモードその2:checkpoint()メソッドをつかう
    • Hot publisher:流れている途中からもみれる
    • micro fusion : 異なるオペレータを1つのキューにまとめる

    Under the Hood of Reactive Data Access

    • 元ネタスライド
    • ReactiveDriverはデータがどこまで取得できているのかを把握できるので、データを全て待たなくても良い
    • SpringDataでReactiveでDBアクセスできるものは限られている
      • Mongo,Radis,cassandra,Couchbase
    • ReactiveでないDBとの違いは、Threadの構造、タイムアウトのハンドリング、ConnectTimeout、ReadTimeではなく、CommandTimeout(自分で完了シグナルを送るタイムアウト

    REST beyond the obvious

    Spring REST Docs RAML, Spring Cloud Contract

    • 岩塚 卓弥(NTT SIC)さん
    • Restful API開発にはツールがたくさん
    • 用途により異なる
      • Public API
        • 誰がどう使うのかわからない
        • API変更時に利用者側の合意は不要(できない)
      • Internal API
        • 使う人、使用方法がわかっている
        • 変更時に同意が必要
        • 内部の開発者が使えればよい
    • メンテナンスされたドキュメントは重要 vs ドキュメントのメンテナンスは面倒
    • Public API
    • API仕様からのソースを生成
    • ソースコードからの生成:Springfox:ソースコードだけでは情報が足りてないので補完が必要
      • 実装方法に依存。ソースコードが読みづらくなる。実装内容と保管情報法の乖離のチェックが必要
    • Spring REST Docs:APIのテストコードからドキュメントの一部を生成
      • API実装側の実装方法に依存しない
      • テストされた正確なものが出力。デフォルトはAsciiDocs
      • Spring REST Docs RAML Integrationがよいのでは?
      • RAML形式の出力を出す3rdパーティ性ライブラリ
        • そのRAMLからJsonSchemaやリクエストのJsonの例なども出してくれる
        • raml2htmlするとちょっとリッチな画面に
        • API Rest Console:リクエスタコードの例、実際にAPIを叩いて確認できる
    • InternalAPI用
    • お互いにAPI呼び合っている際にテストをどうするのか?
    • Consumer-driven Contracts(CdC)
      • 各利用者はAPIのレスポンスすべてを使いたいとは限らない
        • 利用者の必要な部分だけの取り決め=Consumer Contract
      • Contract:Groovy DSLまたはYAMLで記述
      • Polyglot対応もされている:Contract がYAMLになっている&テストランナーはDockerで起動できるので環境を汚さない

    Spring Cloud Gateway, Spring Cloud Pipeline

    • 堅田 淳也(NTT SIC)さん

    Spring Cloud Gateway

    • APIゲートウェイAPIのリバースプロキシとして振る舞い、横断的関心事を処理
    • Spring5,Spring boot2系で動作
    • シンプルだが十分なAPIルーティングを動作
    • リアクティブ対応
      • 従来のZuul1系と大きく異なる。2系はSpringCloudでのサポートはなし
    • 最新バージョンは2.0.0
    • デモ
      • Stage1:モノリシックなアプリを段階的にマイクロサービス化していく
        • Helloサービス、Fortuneサービス、UI(index.html)
      • Stage2:Stand up gateway
        • 依存性追加、JavaConfigでルーティング先の設定
      • Stage3:Move UI to separate app( path rewrite)
      • Stage4:Add service discoverydiscovery
      • Stage5:Move hello service.URIの形式が変わった場合の古い人への吸収をAPIゲートウェイ実装側で実施可能というデモ
      • Stage6:Add circut breaker to old fortune service with fallback:Hystrixのサービスブレーカを実現
      • Stage7:Fortuneサービスの切り出し
      • Stage8:流量制御を適応する。
        • Spring Cloud Gatewayに機能あり。Redisが必要。
        • 例:秒間最大1アクセスに制限

    Spring Cloud Pipeline

    • デプロイメントパイプライン
      • パイプラインを1から作るのは大変
    • Spring Cloud Pipelines :デプロイメントパイプラインのベストプラクティスを提供
    • Concourse,Jenkinsに対応
    • 最新バージョンは1.0.0M3
    • ライブラリではない。中身はほぼBashスクリプト
    • 4つの環境ごとにジョブが作られる
      • Build:ビルド、単体テスト、成果物の保存、API互換性チェック(Spring Cloud Contractを利用)
        • MavenかGradleに対応していれば活用可能
      • Test:テスト環境へのAPをデプロイ、スモークテスト、APをロールバックロールバックしたAPのスモークテスト(後者2つは戻しの可否確認)
      • Stage:ステージング環境へのデプロイ、E2Eテストの実施
      • Prod:新しいAPを本番環境へのデプロイ、新しいAPへの切り替え、ロールバック(これだけ手動)