Meet the Noops で遊んでみる

Meet the Noops は、1ヶ月ほど前に GitHub が公開したイベントで、Noop と呼ばれるシンプルな API を使って楽しくコードを書こうという趣旨のようです。

github.blog

すでにいくつかの Noop が提供されており、毎週新しい Noop が公開される模様。

noopschallenge.com

Meet the Noops

というわけで Noop で遊んでみました。今回は、Wordbot と呼ばれる17万以上の英単語をランダムに返す API を試してみます。

Meet the Noops: wordbot

で、?set=fruits を3回リクエストしてフルーツの英単語を揃えるスロットのようなものを作ってみました。片手間で雑に作ったので、3つ揃ったときのエフェクトなどはありません。(どうせ揃わないし)

ここで試せます。

wordbot slot

あと、コミュニティフォーラムに投下してみたけど、Wordbot が公開されてから日が浅いためか、現時点ではまだ他に誰も書き込んでない模様...。

github.community

JSUG勉強会 2019その6 Spring IO 報告会 に行ってきた #jsug

JSUG勉強会 2019その6 Spring IO 報告会に行ってきました。簡単に所感をまとめます。

jsug.doorkeeper.jp

所感

最近はレガシーなシステムのお守りに追われて新しい情報を追えてなかったので、いろいろと新鮮な情報がいっぱいでした。

とはいえ、なかなか Reactive なシステムを開発する機会がなく、RSocket や R2DBC などは未だに試せていない状態です...。GraalVM とかかなりホットな話題なので素振りしておきたいところ。以前、ちょっと触ってみた Micronaut あたりで GraalVM を試してみようか。もしくは Quarkus あたり?

あと、Moduliths はなかなか面白そう。アーキテクチャをテストできるという意味では、JJUG CCC 2019 Spring で紹介されていた ArchUnit と近いものがあるんだろうか。

JJUG CCC 2019 Spring に行ってきた #jjug_ccc - kntmr-blog

以下、メモから抜粋。(2019/07/02: 資料のリンクを追記しました)

Spring Framework のロードマップと 5.2 の新機能

www.slideshare.net

  • Spring 5.2 は 9/4 GA に延期
  • 5.x で取り入れた機能のアップデートがメイン
  • Reactive API
    • RSocket (マイクロサービス間の通信)
    • R2DBC (RDBMSへのリアクティブアクセス)
  • R2Socket
    • L7のバイナリプロトコル (HTTPと同じレイヤ)
    • Reactive Streams (Backpressure)
    • 4つのインタラクションモデル (片方向/双方向、Mono/Flux)
    • spring-boot-starter-rsocket
    • @MessageMapping
  • R2DBC
  • Reactor のデバッグ出力を改善
    • トレース生成のコストは高い
  • 関数型 API の整備
    • Router Function が MVC で使える
  • Spring 5.3
    • JDKアップデートに追従 (13-15)
    • Code Analysis Annotations
      • @Nullable
    • GraalVM
  • Spring 5.x で対応されないもの
    • Java 11 ベース
    • モジュールシステム
    • Jakarta EE (javax パッケージ?)
    • Project Loom

Spring 5.2 の Kotlin 対応

www.slideshare.net

  • Coroutine 対応
    • WebFlux 向けの機能をサポート
    • ReactiveX に替わるものではない
    • Reactive と Coroutine は同じように使える
  • Spring Kofu
    • Experimental
    • Functional Configuration
    • アプリ起動の高速化、省メモリ

GraalVMの概要と、Native-Image化によるSpring Boot爆速化の夢

www.slideshare.net

  • Graal コンパイラ
  • Truffle
  • Native Image
  • 現時点ではそのまま Spring Boot アプリを Native Image にはできない (制限が多い)
    • リフレクションや Dynamic Proxy で動的なクラス生成を多用しているため
  • Spring 5.3 で Native Image に正式対応予定
  • 今のところ Native Image のビルド時間は非常に長い

Spring Cloud Netflix

www.slideshare.net

  • ほとんどがメンテナンスモードに
    • 脆弱性やバグfixは Pull Request で対応
  • Ribbon ⇒ Spring Cloud Load Balancer
  • Eureka ⇒ Spring Cloud Zookeeper
    • メンテナンスモード対象ではない
    • 移行パスを検討中
  • Zuul ⇒ Spring Cloud Gateway
  • Hystrix ⇒ Spring Cloud Circuit Breaker + Resilience4j
    • アノテーションが不要に
    • Circuit Breaker は様々なサーキットプレイカーを使えるように抽象化したもの
  • Hystrix Stream, Turbine, Hystrix Dashboard ⇒ Micrometer + Prometheus
    • メトリクス情報を収集して監視ツールにエンドポイントを提供する
  • Archaius ⇒ Spring Cloud Config Server
    • そもそもアーキテクチャが違う
    • Archaius は各サービスがプロパティを取得するためのエンドポイントを提供する
    • Config Server は各サービスにプロパティを配布して起動時にロードさせる
  • マイクロサービス開発を担うプロダクトは多い
    • 今後、統廃合があったりするかもしれない

Spring Boot で作るいまどきなモノリス

www.slideshare.net

  • Modular Monoliths
  • Moduliths
  • パッケージをモジュールで分割する (ドメイン)
  • main がある階層のパッケージがモジュールになる
  • モジュール間のDIを避ける
    • EventListener で依存モジュールに Event を送る
    • @DomainEvent
  • Bootstrap Modes
    • Standalone, Direct dependencies, All dependencies
  • モジュールのパッケージ直下に配置したクラスは他モジュールに公開される
    • サブパッケージ配下のクラスは他モジュールには非公開
  • 相互依存をチェックしてエラーにしてくれる
  • Documenter
    • モジュールの関連グラフを作ってくれる (PlantUML)
  • Java のモジュールシステムと関係があるものではない
    • Moduliths はテストをサポートするもの

Postman の GraphQL を試してみる

気が付いたら Postman が v7.2 で GraphQL に対応してました。

blog.getpostman.com

まだ Beta 機能のようですが、手元の v7.2.2 で試してみます。とりあえず、GitHub の GraphQL API で。

事前に、GitHub 側で Settings > Developer settings > Personal access tokens > Generate new token からトークンを生成します。とりあえず、スコープは repo あたりをチェック。

で、Headers タブで Authorization: bearer <token> を追加。Body タブで GraphQL をチェックして、https://api.github.com/graphql に POST するとレスポンスが返ります。

f:id:knt_mr:20190624124851p:plain

あと、左ペインの APIs でスキーマを設定できます。

f:id:knt_mr:20190624125250p:plain

ここでは、GitHub の graphql-schema を設定してみます。

github.com

GraphQL の右隣りにあるプルダウンでスキーマを選択すると、GraphiQL のように自動補完ができるようになります。

f:id:knt_mr:20190624130752p:plain

なかなかいい感じ。

「ふりかえり」をどのようにやるか

システム開発の現場において設計レビューやコードレビューをすることはよくあるかと思いますが、チームや自分自身の仕事を 継続的に改善する ために取り入れたいことのひとつとして「ふりかえり」があります。

で、ふりかえりのツールとしてよく取り上げられるのが「KPT」です。以前から実践しようと思いつつなかなかできてないのですが、実際に取り組んでみることを想定して方針などをまとめてみようかと。

前提

  • 「今回は○○を試す」など、事前に目標を決める
  • 前回の Try があるなら、それを目標に含める

Keep

  • 試してみてよかったこと
  • これから続けたいこと

単純に「○○がよかった」だけではなく、なにがよかったのか、どのような効果があったのかを併せて書く。現在形で書くとよさそう。

Problem

  • 試してみてだめだったこと
  • 不満点や問題点
  • これからリスクになりそうなこと

単純に「○○しなかった」だけではなく、なにがだめだったのか、どんな問題があったのかを併せて書く。あと、あたりまえだけどメンバーを否定するようなことは書かない。

Try

  • Keep を強化すること
  • Problem を解決すること

具体的 (定量的) なアクションを書く。次回の KPT で Keep のふりかえりをするために期待する効果を書くとよさそう。

参考記事

kuranuki.sonicgarden.jp

boxil.jp

BPStudy#141〜DDD(Domain Driven Design)実践の現場に行ってきた #bpstudy

BPStudy#141〜DDD(Domain Driven Design)実践の現場に行ってきました。簡単に所感をまとめます。

bpstudy.connpass.com

所感

最近、価格計算のロジックを実装する機会があり、個人的にはなかなかホットな内容でした。とはいえ、自分の場合は特にドメイン駆動設計という感じではなかったのですが、価格計算のロジックはアプリケーションのレイヤから分離するようにしました。で、今回の話を聴く限りではこのアプローチ自体はあまり間違いではなかったのかなとなんとなく実感を得られました。

あと、モジュールやメソッドの切り方を考えるときに個人的に意識していることはテストがやりやすいかどうかということ。特に、モックを多用せず、シンプルにテストコードが書けるかどうかは重要かなと思っています。なので、今回の事例として挙げられていた「料金計算ロジックをどうやってコードで表現するか」ということに関して、テストがやりやすいかどうかという観点で考えるのは割とありなのかなと思っている今日この頃です。

そういえば、増田さんの本は読んだことがあるけど、エヴァンスの本は手が出しづらくてまだ読んでない...。そろそろ読んでみるか。

現場で役立つシステム設計の原則 ~変更を楽で安全にするオブジェクト指向の実践技法

以下、メモから抜粋。

ドメイン駆動設計の正しい歩き方~どこに焦点をあわせ、どう実践するか

www.slideshare.net

  • ドメイン駆動設計はアーキテクチャや設計に限った話ではない
  • ソフトウェアの核心にある複雑さに立ち向かう
  • 複雑さはビジネスの複雑さに起因する
    • 複雑になる要因はたくさんある
  • ビジネスルール
    • 制約や約束事 (システムやITは関係ない)
  • ドメインロジック
    • ビジネスルールをシステムやソフトウェアとして実現するもの
  • 核心にある複雑さを適切に扱う
    • 周辺の複雑さが整理される
    • 条件分岐を外に抜き出すと入出力は単純になるはず
      • 分岐が散在するから複雑になる
    • 全体の構造が改善する
  • ドメイン層を独立させる (アーキテクチャの話)
  • ビジネスの活動を継続的に学ぶ☆
  • コアドメインに集中することにどれくらい時間を費やせるかがポイント☆
  • 個人ではなくチームの基本方針としてやっているか☆
  • 全体を均質にやるのではなくポイントを絞って深掘りする
    • 複雑なものを整理して単純なIFで使えるようにする
  • ドメイン層に入出力の関心事(画面やテーブル)を持ち込まない
  • モデルと実装は切り離さない
    • 実装のためにモデリングする
    • コードをうまく書くにはどのようにモデルを整理すればよいかを意識する
  • 例) 複雑な料金計算ルール
    • ドメインロジックを独立させる
    • 画面やDBのことを一緒に考えない
  • モデルで整理してモデルと実装を密に結合する
    • ルールを整理する
    • モデルで仮説を立ててコードで実現してみる
    • コードのリファクタリングとモデルへのフィードバックを繰り返して改善する☆
  • コアドメインに集中する
    • ある軸を選んで簡単なコードを書く、別の軸で簡単なコードを書く☆
    • 実験することでモデルの妥当性を検証する
    • 中核のルール、周辺のルール、除外すべきルール
  • ビジネスを深く洞察する
  • システム間の秩序の改善を続ける
    • 連携するシステムや人間を意識する
    • どのようにデータを持つべきかがわかってくるはず
  • ドメイン駆動設計を現場に導入する
  • ドメインエキスパートがちゃんと説明してくれるとは限らない
    • 具体例を提示して質問する
    • あえて間違っていることを質問して語ってもらうのもあり
    • バックオフィスの人の方がルールを知ってるかも (経理のベテランや営業支援スタッフとか)

教材セット

www.slideshare.net

モデル駆動型開発によるビジネスをソフトウェアに落し込む1つのやり方

  • モデリング
    • モデルを作ることで分かりやすくする
  • ビジネスとソフトウェアは乖離する
    • モデルを中間成果物としてビジネスとソフトウェアを繋げる
  • モデル駆動型開発(MDA)
    • CIM, PIM, PSM, CODE ☆
  • 言語の抽象度は上がっている
    • プラットフォームの複雑さから分離する
  • モデル駆動開発のいいところ☆
  • 言葉を共有
  • 言葉の乖離
    • ドメインエキスパート⇔開発者
    • 開発者による抽象化は設計の支えにはなるがドメインエキスパートには理解されないかも
  • ユビキタス言語
    • モデルを言語の骨格とする
    • コミュニケーションとコードではその言語を用いる
    • 用語集とは違う
    • 形式知として全体に浸透するもの☆
  • わからない言葉を整理してビジネスの外観を捉える
  • 言葉を整理する中で気をつけるポイント☆
  • トランザクションスクリプトになりがち
    • 関心事が入出力に寄ることでドメイン層がただの入れ物になる
    • テーブル設計から入るとドメインがデータの器になりがち
    • ビジネスルールが書かれていない
  • どこにビジネスルールを書くか
    • 育てる

JJUG CCC 2019 Spring に行ってきた #jjug_ccc

JJUG CCC 2019 Spring に行ってきました。簡単に所感をまとめます。

www.java-users.jp

セッション資料は以下で公開されると思います。

GitHub - jjug-ccc/slides-articles-2019Spring: JJUG CCC 2019 Spring 登壇資料まとめ

所感

今回、会場に WiFi が設置されてました。快適。

Java そのものやフレームワークの話ではなく、事例や設計手法の話が以前より増えた気がする。CfPでそういうのを選んでるんだろうか。あと、アンカファレンスがおもしろそうだった。次回はそっちを聴いてみよう。

以下、メモから抜粋。

初めてのgRPC

寝坊して朝イチのこれが聴けなかった。あとで資料を読む。

What's new in Jakarta EE and Eclipse GlassFish (May 2019)

www.slideshare.net

  • JavaOracle の商標
  • javax.* の copyright は Oracle
    • javax.*jakarta.* に変わる予定?
  • Jakarta EE 8
    • Java EE 8 とほとんど変わらない
  • Jakarta EE 9
    • APIのテコ入れ
    • JSFメジャーバージョンアップ
    • CDIとの結び付きが強くなる?
    • APIに手が入るところはパッケージが変わるはず
    • javax パッケージは互換性のために残る
  • Java EE に比べて開発スピードはかなり早くなるはず
  • Java EE 8 に対応したベンダーは Jakarta EE にも追従するはず
  • https://jakartablogs.ee/

ちょうどGWあたりにパッケージの話が流れてきた気がする。誰がわるいということではないし、開発スピードが上がるので Jakarta EE はまだまだこれからとのこと。

ArchUnit で Java / Kotlin アプリケーションのアーキテクチャを CI する

確かにアーキテクチャ暗黙知になりがちで時間がたつにつれてブレる気がする。今回、初めて ArchUnit を知ったけどなかなかよさそう。ちょっと調べてみよう。

Catch up Java 12 and Java 13

www.slideshare.net

  • Java 12 の変更点はそれほど多くない
  • APIの削除はなかった
  • Javaが持っているGCは全部で7個に
  • 新しくGCは入ったがツールはこれから対応される見込み
  • OSから借りたメモリは基本的にはOSに返さない
    • Java 12 で未使用のメモリを返すように
  • Switch が文から式に (プレビュー)
    • break ⇒ break-with?
  • JMHはマイクロベンチマークの選択肢として便利

個人的には Switch 式と String#transform が気になる。要復習。

Java クライアント実装におけるAPIスタイル頂上決戦! 野良REST vs GraphQL vs OData vs OpenAPI (Swagger)

CData JJUG 2019 Spring 参考資料 · GitHub

  • APIをもっと楽に使えるように
  • API開発でなぜ苦労するのか
  • RESTはソフトウェアアーキテクチャのスタイル (原則であって規約ではない)
    • ドキュメントを読み解かないとわからない
  • OData
  • GraphQL
    • ネストした情報を一発で取得できる
    • RESTではそれぞれ取得するか、専用のエンドポイントを用意するか
    • Javaで使うのはまだつらい...?
  • CData JDBC Driver
    • Web APISQL で実行できる

以前、GraphQL を少し試してみたけど、確かに Java ではまだまだ使いやすいとは言えない感じだったかな。今後に期待ですが。OData はあまり聞いたことがなかったけど、エンタープライズ向けには割と使いやすいみたいなので、ちょっと押さえておこうかな。どうでもいいけど、タイトルがずっと "クライント" になってるのが気になった。

LINEのBOT Platformの裏側の話

  • LINEではJava利用が圧倒的に多い
  • Kotlinも増えてきている
  • Streaming API
    • リアルタイム性が重要
    • Server-Sent Event by Spring WebFlux
    • 双方向通信の必要はなかったので WebSocket は採用しなかった
  • Redis の Pub/Sub と Kafka の組み合わせ
  • SSE は長時間イベントを送らないと接続が切れる
    • ping 送信用の Flux を merge (10秒間隔で ping 送信)
  • SSE の再接続
    • Last Event ID
  • Data Hub として Kafka を使っている
    • Consumer Group で複数サービスに配信?
  • logback + MDC
    • ThreadLocal ベースで実装されている機能
    • ログに reqeust 情報を追加する
    • WebFlux で使う場合はひと工夫が必要?
  • モニタリング

もしかしたら普通なのかもしれないけど、LINE では Kafka をいろいろ活用されてるんですね。そこらへんのノウハウがいっぱいありそう。

ストラングラーパターンによるマイクロサービスマイグレーションの勘所

ストラングラーパターン。モノリスなアプリケーションを段階に置き換えるという話。機能やアーキテクチャより、ログ管理やインフラ周りの運用がキモに思えた。

マイクロサービス:4つの分割アプローチの比較

www.slideshare.net

  • マイクロサービスを実現する技術においてコンテナの存在は大きい
  • 4つの動機のうち今日のメインは機能分散
  • 最初にモノリスで作って、抜き出せる機能/移行を検討する
  • モノリスで有効な設計はマイクロサービスでも同様のはず☆
  • クラウドによって非同期はやりやすくなった/当たり前になってきた
  • 論理的なモジュール分割は積極的に大胆に
  • 物理的な配置と運用単位は慎重に
  • マイクロサービスではモノリスにはない考慮ポイントが多い
    • ノウハウがあればいいが最初のうちは慎重にやる
  • マイクロサービス間の通信の勘違いと真実☆
    • ネットワーク全体は等質ではない
  • 4つのアプローチ☆
    • 実際には択一ではなく組み合わせ
  • 部門の構造とシステム構造が一致させるのがよいとは限らない?
  • ユースケースで分割するとトランザクション単位のマイクロサービスになる
    • ユースケースサービスを薄くして、後ろに各サービスを置く リソースで分割
    • リソースをまたがった参照が複雑になりがち
      • 外部キー制約が使えない、JOINが使えない
    • モノリスでは識別単位の情報にいろいろ持たせ過ぎていた?
    • リソース管理単位を分割する
  • ビジネスルールの分割パターン
    • 入出力はシンプルになる
  • トランザクション分解パターン☆
  • モノリストランザクションはマイクロサービスでは適用できないかも

要復習。モノリスで有効な設計スキルはマイクロサービスでは同じとのこと。ただ、マイクロサービスに分割する際にはマイクロサービス特有の考慮ポイントがあることに注意する必要がありそう。