White Box技術部

WEB開発のあれこれ(と何か)

BotkitでのSlackアプリ開発方法とデプロイ方法

現在、Slackアプリを開発中なのですが、初めてのこともあり色々と学ぶことが多かったです。

Botkitでの開発

Slackアプリを開発するにあたっては、公式フレームワークのBotkitを利用することにしました。

BotkitとBabelの導入

Botkitの導入はSlackアプリのプロジェクトで、npm i botkitをするだけでいいのですが、 ES201Xでコーディングするため、Babelも導入しました。

npm i botkit
npm i -D babel-cli babel-core babel-preset-env

SlackアプリはNode.jsで動くので、.babelrcは以下のようになります。

{
  "presets": [
    ["env", {
      "targets": {
        "node": "current"
      }
    }]
  ]
}

開発用のコードはsrc/main配下に、実行コードはdist/main配下とすることにしたので、 トランスパイルの実行用にpackage.jsonのscriptsに以下の記述を加えました(app.jsが起点のファイルです)。

    "build": "babel src -d dist",
    "start": "node dist/main/app.js",
    "clean": "rm -rf dist",

実行する際は以下のようにして使っています。

npm run clean; npm run build; npm start

開発時の注意点

あとはコーディングするだけなのですが、起動の段で幾つか注意するところがあります。

Botkitの注意点

  • createWebhookEndpointsにverificationの値を渡すと、ブラウザから/loginにアクセスができない
  • configureSlackAppに渡すパラメータにredirectUriが増えている(https://ホスト名:ポート/oauthを渡せばOK)
  • Slackにしているするパスは、Interactive Components、Slash CommandsどちらのRequest URLもhttps://ホスト名:ポート/slack/recieveになる

SlackアプリとBotsの違い

どちらもBotkitで開発できるのですが、以下の点が異なります。

  • Botsにする場合はtokenを、アプリにする場合はclient_idとclient_secretを利用する
  • アプリでは起動したタイミングで毎回/loginにアクセスし、認証しなければいけない
  • interactive_message_callbackを使う場合はアプリでなければいけない(サーバが必要)

今回Slackアプリとして開発したのは、interactive_message_callbackを利用したかったためです。

Slackへの設定

アプリ作成は、slack apiのページで『Create New App』ボタンを押すことで開始できます。

f:id:seri_wb:20180114014342p:plain

ここでアプリの名前とインストールするSlackのチームを入力しましょう。

その後の各項目での作業は以下になります。

Basic Information

  • App CredentialsのClient IDとClient Secretをメモ(アプリ起動に利用するため)
  • Display Informationにアプリの情報を入力する

Install App

  • アプリをSlackにインストールする(最後でもよい)

Interactive Components

  • Request URLにhttps://ホスト名:ポート番号/slack/receiveを設定する

Slash Commands

アプリ用のSlackコマンドを作る場合はここの設定を行います。

  • コマンドの情報を入力する
  • Request URLにhttps://ホスト名:ポート番号/slack/receiveを設定する

OAuth & Permissions

配布アプリを作成する場合は、ここでRedirect URLsにhttps://ホスト名:ポート番号/oauthを設定する必要がありますが、 内部利用だけの場合は設定不要です。

Bot User

利用するBotユーザの表示情報をここで設定します。
注意点として、Slack上に登録されるユーザはここで設定した名前ですが、スラッシュコマンドが応答するアプリの名称はBasic Informationで設定したものになります。

Slackアプリの起動

トランスパイルが終わっていればnpm startで起動するので、SSL対応のサーバでアプリを起動してください。

起動後にブラウザからhttps://ホスト名:ポート番号/loginにアクセスし、認証を行うとRMTがスタートします。

Herokuにデプロイする場合の注意点

最初は開発用サーバとしてHerokuを利用していたのですが、Herokuではできないこともあり、現在は利用していません(ngrokを使っています)。

ただ、利用する際にもいくつかハマリポイントが合ったので残しておきます。

  • ポートが動的に設定されるため、起動ポートにはprocess.env.PORTを利用する
    • 上記の理由で、SlackAppのURL設定項目にはポートを記載しない
  • Herokuではサーバに書き込みができないため、json_file_storeが利用できない(宣言していてもアプリ自体は起動する)
  • 書き込みできないため、babelを利用する場合、トランスパイル後のファイルもコミットする必要がある
  • Procfileを用意して、web: npm startのように起動コマンドを記載する

ngrokの利用

Slackのチュートリアルにもありますが、開発ではngrokでSlackからのリクエストを受けて、ローカルに転送することで、ローカル開発ができます。

Macの場合はHomebrewで導入するのが簡単だと思います。

brew cask install ngrok

起動は以下のようにアプリで利用するポート(ここでは3000)を指定して実行する感じです。

ngrok http 3000

ngrokは起動している間はドメインが変わらない&裏でアプリの再起動をしても問題なく転送してくれるので、開発中はngrokを起動しっぱなしにして利用することになると思います。

ただ、セキュリティリスクがあることをやっているので、会社などで立ち上げていると情シスに怒られる可能性があります。注意しましょう。

まとめ

コーディングに関してはざっくり省きましたが、このようにすることでSlackアプリを自分で作ることができます。

本番利用にはAWSを使おうと思っているので、その手順はまたの機会に。

コーディングのエッセンスはまた別途書きたいと思っています。

2017年に読んだ本と2018年の抱負

新年、あけましておめでとうございます。

2017年に読んだ本の振り返り

本当は去年のうちにやっておきたかったのですが、 読んだ本から去年の自分の興味を振り返り、今年の抱負を考えていました。

JavaScript

JavaScriptjQueryで知識が止まっていたので、最近のJavaScriptに対する苦手意識を払拭しようと、 ES2015以降の関連技術を中心に本を読んでいました。

初めてのJavaScript 第3版

古い文法から新しい文法まで一通りさらえてとても良かったです。これだけ読んでおけばESの仕様でも戦える・・・はず!

Electronではじめるアプリ開発

GUI制作の新たな選択肢として気になっていたのでElectron本も読んでました。
ReactとFirebaseに関しても学べてお得だったなと(サンプルコードがReactやWebpackのサンプルとしていつも重宝しています)。

Reactビギナーズガイド

Electron本でReactをかじったので、ついでに文法もしっかり学ぼうと思ってこれを読みました。 React関連技術のインデックス作成によかったです。

アイソモーフィックJavaScript

これだけJavaScriptを勉強していると、サーバサイドもJSでいけるのでは?という気になってきていたのでこの本を読んでました。 マイクロサービス化が進んだシステムのBackend For FrontendなAPIをJSで作ると、アイソモーフィックJavaScriptができるんじゃないかなーと思っています。

Angular アプリケーションプログラミング

Angularのバージョンが上がったこともあり、仕組みを一通りさらおうと思って読みました。 読んだ結果、Angularは自分にとっては直感的でない仕様が多く、採用しようという感じにはならなかったのですが、 実際に使ってみると別なのかもしれません。エコシステムが充実しているので、慣れればすごく便利そうではありました。

思想系

技術書と言っても、技術よりも考え方に寄った内容の本もあって、自分で思っていたよりもこのジャンルの本を読んでいたようです。

言語のしくみ

Rubyの設計思想などがちょいちょい書かれていて、とても興味深かったです。本自体も読みやすく、「言語書ける人は文章もうまいのかー」とか思いながら読んでました。

ピクサー流 創造するちから

ここ数年で読んだ本では一番感銘を受けました。 ブレイントラストを実施できる組織っていいですね・・・私も自分のいる組織はそういうところにしたいです。

見えないものを解き明かし、その本質を理解しようとしない人は、リーダーとして失格である

なるほどー!

新装版 達人プログラマー

薦めてくれた人曰く、「プログラマならみんな読んでる」だったので、まだ私はプログラマではなかったッ!!
エンジニアとして生きてきて、今までの経験により学んだり知っていたりしたことが、うまく文章にまとまっていてる本でした。確かに読んでおくべきですね。

聞き手を理解するための合言葉として提示されていたWISDOMが、確かにプログラマ脳には必要だと思いますし。

W 何(what) 聞き手に何を知ってほしいのか
I 興味(interest) 言いたいことの中にある彼らの興味とは何か
S 洗練(sophisticate) それらはどれくらい洗練されているか
D 詳細(detail) 彼らはどの程度詳細に知りたがっているか
O 誰の情報(own) 誰にその情報を知ってもらいたいのか
M 動機づけ(motivate) 話を聞いてもらえるには、どうするのか

トヨタ生産方式

これも本当に名著でした。(思えば去年は本当にいい本と出会えた年だったなと)

アジャイルの方法論とかスクラムの流儀だとか、そういうところから入るのではなく、とにかくこの本1冊読んでからアジャイルスクラムと向き合うと、プロダクトの成功に近づくのではないかと思います。原点恐るべし。

スクラム 仕事が4倍速くなる”世界標準”のチーム戦術

スクラムを採用することで、こんな困難にも対処できたんだ!という内容の本でした。ところどころに実践のポイントも書かれているので、自分たちの問題と照らし合わせて読むと希望を見つけられるかもしれません。

Eric Sink on the Business of Software 革新的ソフトウェア企業の作り方

1年以上積読になっていたので、転職タイミングで読み切りました。タイトル通り、ソフトウェア企業を作る際の注意すべきポイントがエンジニア視点で書かれているので、イメージしやすかったです。この本を読んで、営業の基本も知らないとなぁと思っているところです。

その他

もう分類が面倒なので、残りはここにまとめます。

IoTとは何か

前職で薦められたので特に調べず購入したのですが、著者がすごい人過ぎて、若干緊張しながら読んでました。 IoTに限定した話なわけではなく、これからのITへの洞察や日本における制約などITに関して包括的に書かれており、 これを読んだ人は何かを託されたかのように感じるのではないでしょうか。

頑張ります。

ノンデザイナーズ・デザインブック 第4版

ずっと気になっていた本で、ようやく去年読めました。

デザインコンプレックスのある人間にもわかりやすい、理論で学ぶデザインの本でした。演習問題をやっていると、自分にもデザインできる気がしてくるのがびっくりです。お薦めです。

これは電書よりも紙の方が読みやすいと思います。

達人に学ぶDB設計徹底指南書

積読消化の第二弾でした。毎度怪しくなる正規化のおさらいと、経験則でやっていたことの理由がわかってよかったです。

達人プログラマーもそうでしたが、こういう先達に学ぶ系の本は「もっと若い頃に読んでおけば・・・」と、どうしても思ってしまいますね。

Kotlin Webアプリケーション

リックテレコム 書籍情報

Kotlin Webアプリケーション 新しいサーバサイドプログラミング

Kotlin Webアプリケーション 新しいサーバサイドプログラミング

去年、SpringがKotlinをサポートしたことを知り、JavaからのリプレイスはKotlinがベストな解答になるのでは?と思っていたところに、本書が出たので購入しました。

Kotlinの特徴が要点よく書かれており、Web開発関連の技術についても解説が載っているので、Web開発者でKotlinが気になる人が取る最初の1冊としては本書が最適だと思います。

といってもWeb開発部分はSpringやGradle、Herokuを知っていれば、別に本書を読まなくても問題ない内容でした。逆に言えば、それほどJavaと同じ感覚でSpringが使えるということなので、Kotlinは有りだなと思ったのですが。

Kotlin自体をしっかり知りたい場合は、本書よりもKotlinスタートブックKotlin in Actionがいいと思いますが、本書を読んでいれば、あとは公式サイト(やその翻訳サイト)で概ね問題ないのではないでしょうか。

SQL 第2版 ゼロからはじめるデータベース操作

新人や後輩に「何かお薦め本ないですか?」と言われたときによく薦めてたのですが、流石に処分しようと思い、 処分する前にもう一度、と読み直していました。ポイントが詰まっていていい本だと思います。

結局、前職の同僚に押し付ける形であげてきました

WEB+DB PRESS

あとWEB+DB PRESSの去年出た分を読んでいました。いつもお世話になっています。

読みかけ

読みかけだとこんな感じです。デザインパターン本は暇な時のプログラミング練習で読んでいる感じなので、果たしていつ終わるのやら。

あと英語関連の本を読んでましたが、これはまた別の機会に。

振り返って

読んだ本の半分くらいがJavaScript関連だったこともあり、だいぶJSへの苦手意識はなくなりました。 ReviewetもES2015でリファクタリングできましたし、Webpack設定も書けるようになったのが大きいですかね。 やっぱり集中して取り組むのは大事なのかもしれません。

あと、ピクサー本やトヨタ生産方式などの名著に出会えたのも良かったです。やはり他人のお薦めは読むべきですね。

読書スピード

こうしてみると月1、2冊くらいしか読めてないようです。 遅いか早いかはなんともですが、もうちょっと読めてるとよかったかなぁと個人的には思います。

今年読む本と抱負

今年は英語学習や、ちょっと別のことに力を入れようと思っているので、読む本も減ってしまいそうですが、 月1冊くらいのペースでは消化していけるといいなぁと思っていたりはしています。

ちなみにここらへんが新しく読もうと思っている本です。

そして今年は、組織のメンバーが自分の仕事に注力でき、互いの状況をつかみやすい仕組みを、システムによって作ることを目標に頑張っていこうと思います。なので読む本もそっち側によっていくのではないのかな、と。言語だとGoとKotlinですかね。

Amazonリンク

各本の公式リンクはそれぞれに付けたので、Amazonへのリンクを以下にまとめます。

JOOQをGradleプロジェクトで使う

2017/12/15追記:gradle buildからJOOQのコード生成を除外

サーバサイドの開発をKotlinで行うために、ここのところ調査・検討を色々していました。

概ね問題なさそうという結論が出たので、それ以外の技術選定をしていたのですが、 O/R Mapperに採用することにしたJOOQをGradleと組み合わせたときに、悩むことが多かったので、 現時点でのやり方と考えを残しておこうと思います。

JOOQ

JOOQ(juke:ジュークと読むらしい)はJava用のO/R Mapperなのですが、KotlinのDSLもあり、Kotlinからでも(私としては)違和感なく使えるライブラリになっています。

JOOQ選定理由の大きなところは以下になります。

  • Kotlin対応が考慮されている
  • DSLSQLの文法とほぼ同じで、JOIN句が書きやすく、直感的になっている
  • ライブラリを利用するための事前準備が、ソースコードと独立している(アノテーション利用ではないこと)
  • 必要であればSQLがそのまま実行できる
  • 公式ドキュメントでそれなりに疑問が解消できる

利用よりも運用が悩ましい

使う分には違和感がなかったJOOQでも、運用方法についてはまだしっくりきていません。

今のところは「Gradleプロジェクトで利用するのであれば、Gradleで完結させよう」という方針で使っています。

Gradleとの組み合わせ

GradleでJOOQを利用するのには、gradle-jooq-pluginを使いました。

以下はkotlin-api-sampleで最初のあたりに書いていた、build.gradleのJOOQ設定部分です。

jooq {
    version = '3.10.1'
    edition = 'OSS'
    tables(sourceSets.main) {
        jdbc {
            driver = 'org.h2.Driver'
            url = 'jdbc:h2:./test;AUTO_SERVER=TRUE'
            user = 'sa'
            password = ''
        }
        generator {
            name = 'org.jooq.util.DefaultGenerator'
            database {
                name = 'org.jooq.util.h2.H2Database'
                includes = '.*'
                excludes = ''
            }
            target {
                packageName = 'box.white.seriwb.api.jooq'
                directory = 'src/main/java'
            }
        }
    }
}

ちなみにdependenciesに記載する、JOOQに関係するruntimeとjooqRuntimeには 以下のようにバージョン番号まで指定しないとgenerateコマンドがエラーとなり、動作しませんでした。

runtime('com.h2database:h2:1.4.196')
jooqRuntime('com.h2database:h2:1.4.196')

この設定を記載した際は以下のことを考えていました。

  • Spring starterで入るJOOQとコード生成に使うJOOQのバージョンを合わせるため、バージョンを指定しよう
  • テーブルに対しての処理だから、タスク名部分はtablesがいいだろう
  • 生成ファイルは直接src/main/javaに出力すれば、管理が楽だろう
  • 生成先のパッケージ名の最後はわかりやすくjooqにしよう
  • 本番環境でコード生成する必要はない(DBマイグレーション管理しているため、開発環境での生成でOKだろう)

実際、これで動作するようには作れるのですが、次第に以下が気になってきます。

  • 実装に利用しないDBスキーマも自動生成対象にしてしまっている
  • gradle cleanすると、src/main/java配下の生成したファイルが消えてしまう

自動生成対象の選定

対象のDBスキーマを一つに絞るのは、inputSchemaを指定することで簡単にできます。
例えば、target_db_nameというMySQLのDBスキーマを対象にした場合は、以下のようになります。

jooq {
    version = '3.10.1'
    edition = 'OSS'
    tables(sourceSets.main) {
        jdbc {
            driver = 'com.mysql.cj.jdbc.Driver'
            url = 'jdbc:mysql://localhost:3306'
            user = 'admin'
            password = 'admin'
        }
        generator {
            name = 'org.jooq.util.DefaultGenerator'
            database {
                name = 'org.jooq.util.mysql.MySQLDatabase'
                inputSchema = 'target_db_name'
                includes = '.*'
                excludes = ''
            }
            target {
                packageName = 'box.white.seriwb.api.jooq'
                directory = 'src/main/java'
            }
        }
    }
}

一つの場合はこれでいいのですが、複数ある場合はこれだと対応ができません。

なので複数の場合はinputSchemaを指定するのではなく、 以下のように不要なものを除く書き方をすることで、必要な分だけをコードにすることができます。

database {
    name = 'org.jooq.util.mysql.MySQLDatabase'
    includes = '.*'
    excludes = '(?i:(information_schema|sys|mysql|performance_schema)\\..*)'
}

試してはいませんが、反対に必要なものだけをincludesに記載するやり方でも同じ結果になるはずです。

gradle cleanから自動生成したコードをガード

これは自動生成コードの出力先をデフォルトに戻し、別タスクでsrc/main/java配下にコピーすることで対応しました。

import org.gradle.util.GFileUtils

中略

sourceSets {
    initJooq
}

jooq {
    version = '3.10.1'
    edition = 'OSS'
    tables(sourceSets.initJooq) {
        jdbc {
            driver = 'org.h2.Driver'
            url = 'jdbc:h2:./test;AUTO_SERVER=TRUE'
            user = 'sa'
            password = ''
        }
        generator {
            name = 'org.jooq.util.DefaultGenerator'
            database {
                name = 'org.jooq.util.h2.H2Database'
                inputSchema = ''
                includes = '.*'
                excludes = ''
            }
            target {
                packageName = 'box.white.seriwb.api.jooq'
            }
        }
    }
}

// cleanタスクで生成されたコードが削除されないようにするため、1つ段階を踏む
task copyJooq(dependsOn: [clean, generateTablesJooqSchemaSource]) {
    doLast {
        File targetDir = new File("src/main/java/box/white/seriwb/api/jooq")
        targetDir.deleteDir()

        File jooqDir = new File("build/generated-src/jooq/tables")
        GFileUtils.copyDirectory(jooqDir, new File("src/main/java"))
    }
}

コピーするタスクを追加するだけでは、自動生成のコードがsourceSets.mainになるため、 クラス重複エラーがコンパイル時に発生するようになるため、sourceSetsに新しくinitJooqを追加し、 生成したコードはこちらのsourceSetになるようにして、クラス重複を回避しています(裏技みたいですね・・・)。

こうして、src/main/javaへの反映をプラグインの仕組みから切り離すことで、 cleanで自動生成ファイルが削除されることと、不意のgenerateTablesJooqSchemaSourceタスク実行によるコード変更はなくなりますが、 コード反映する場合はgradle copyJooqを手動で実行しなければいけないという制約もできます。

ちなみに、この問題の解決策として、『Gradle実行時に生成されることを期待して、自動生成ファイルをコード管理に登録しない』という方法もあると思いますが、 通常はDBスキーマ情報が同一のリポジトリで管理されていないはずですので、1リポジトリ内でコンパイルを成功させるためにも、生成したコードもリポジトリに登録するのが良いと思います。

import文の記載やdoLastの記載は、gradle実行時の警告回避によるものです。 Gradle 5.0.0以降ではtasks定義時の<<演算子などは削除される予定という旨のメッセージが出力されます。

gradle buildからJOOQのコード生成を除外

copyJooqタスクでコード生成を行うため、buildタスクで実行されるgenerateTablesJooqSchemaSourceは意味がなくなりました。 なのでbuild時にgenerateTablesJooqSchemaSourceが実行されないようにしておきましょう。

タスクの除外は、buildコマンドを実行する際にxオプションでgenerateTablesJooqSchemaSourceを指定してもいいのですが、 以下のように『generateTablesJooqSchemaSourceはbuildタスク以外のときに実行する』とbuild.gradleに記載しておくのがいいでしょう。

jooq {
    省略
}
generateTablesJooqSchemaSource.onlyIf { name != 'build' }

以下にこれらの内容が反映されたプロジェクトがありますので、詳細な内容はこちらからご確認ください。

やっぱり

利用までに一手間が入るライブラリは、実際に利用するよりも、運用のほうが難しく感じます。

今回は前提に「Gradleから利用」を置いていたのでこのような結論になったのですが、 もしその前提を外すならば、DBマイグレーションと合わせてタスク化するなど、別の方法も取れると認識していますし、 そちらの方がいいこともあると思っています。

なのでこんな方法で運用しているよーとかあれば、コメントなどで頂けると嬉しいです。

【まとめ】Java SE 9/EE 8リリースイベント 兼 JavaOne 2017 報告会

Javaな仕事に戻ったのもあり、JJUGのイベントに行ってきました。

当日の発表内容や様子は、以下にまとめてくださった方がいるようです。

ちなみにこのイベントの内容は、動画で公開されています。

参加できなかった方もこちらを見ていただけると、Javaの今がわかって良いのではないでしょうか!

といったところで、あとは各発表の私のメモになります。


1. JavaOne 2017 Overview & Announcements

https://youtu.be/XT2tIh9r6Eo?t=0m4s

  • 7の時代はCoin, Lambda, Jigsawを企画していた
  • 9でようやくMilling CoinとJigsawが入った
  • 機能追加が9では91(8のときは55

今まで

  • OpenJDKはOracle JDKと技術的な差がある
  • 2年に1度のリリース目標
    • 細かい機能リリースも合わせてリリースが遅れてしまっていた
  • 長期サポートや更新リリースがあった

これから

  • OpenJDKとOracle JDKの技術的差分を2018年後半までになくす
  • 機能リリースを6ヶ月に1度に
    • バージョン表記は$YEAR.$MONTHになる(JDK 9、18.3、18.9
  • OpenJDKのバイナリは無償配布(OracleJDKは有償になる

スケジュール

  • この1年で移行期間が終わる
  • 後継バージョンのリリースまでがサポート期間になる

2. JDK9, Release Cadence & Future

https://youtu.be/XT2tIh9r6Eo?t=30m24s

資料

ローカル変数の型推論であるAmberが入ると、Javaもだいぶ省力化できるようになりそう

JShellとライブラリの話

発表者が途中で変わる(吉田真也さん @shinyafox @bitter_fox

  • REPLツールが有ると教育分野で人気(これがJShellをつくるモチベーション
  • 新しいコレクションファクトリのSet.of()とかで作ったSetはイミュータブルになる
  • StreamAPIでtakeWhileで途中中断とかできるようになった

3. Intel's Persistent Memory

https://youtu.be/XT2tIh9r6Eo?t=1h18m18s

  • 今までのメモリより容量がめっちゃ増えた(4倍
  • めっちゃ安い(2分の1
  • OracleDB 18cがこれをサポートする
    • 5倍くらい早くなる

Javaでも効果が出るように進めている

PMの使い方

  • メモリのスケールアップ(揮発するメモリ
    • Javaのヒープをのっけてつかう
      • 開発者としては楽ちん
      • ビックデータとかインメモリのアプリでこれを使うといいよ
      • 実行するときのオプションでできるようにしていきたいという話@インテル
        • 1,2年でJavaに入りそうな雰囲気
    • 一部をDRAMに、それ以外をPMに
      • ユーザが割当を指定 or プロファイリング結果をもとに自動割当とか
      • 低頻度アクセスとかサイズの大きいのとかをPMに載せるといい
      • -Xmpオプションとかで指定できるようにしたい
  • ストレージのスケールアップ

自分が定義したクラスをPMに保存するって言う処理も書ける

  • PersistentObjectを継承すると行ける
  • 実装方法はPanamaのクラス定義の仕方を参考にしている

リアルタイムに値を変更できるようになる

  • IntelがめっちゃJavaに力を入れているらしい
  • ストレージのAPIはPanama依存が多いのでPanama待ちかもしれない
  • 対応するOSS DBが出てくるのはまだ先になりそう

4. Java EE 8

https://youtu.be/XT2tIh9r6Eo?t=2h25s

現段階で話せることが今回の発表内容

  • Java EE 8
  • EE4J
  • Panel Discussions
  • Key Takeaway

Java EE 8のリリース

JavaEEの開発がGitHubに移管された!

Javaの目指すところ

Open Evolving Nimble Scalable

Java EEは?

Available Open Nimble

もっとOpenに、もっとNimbleにしていかないといけない
->だからEclipse Foundationに移管することに決めた

移管プロジェクトがEE4J(ブランド名はまだ未定

EE4J

https://projects.eclipse.org/projects/ee4j/charter

  • Open
    • プロセスを透明化する
    • 沢山の人に参加してもらって決めていくことを目的にしている
      • Oracleも1ベンダーとしてコミットしていく
  • Compatible
    • 互換性を持たせて、新しい機能を提供していきたい
    • ライセンスをEclipse側にリライセンスする
      • 資産自体はOracleが幇助する
      • 今まであったものはそのまま使えるようにする
      • 新規に作るものはEclipseの流儀に合わせて作っていく
  • Flexible
  • Nimble
    • 2018年の中旬までには移管したい

Java EEOracleはどうサポートしていくのか

  • 今までの契約は引き続きサポートしていく
  • ライセンス許諾したベンダには、2025年までにEE4Jに移行するようにしてくれとアナウンスしている
    • EE4Jの発表を待ってくれという状況

パネルディスカッションの話

MicroProfileが将来的にはJava EEにマージされようとしている

MicroProfileとはなんぞや

Q. 標準化団体どうすんの?(今はJCP

  • 今はできれば作りたくない。時間がかかってしまう懸念がある
  • JSRは?
    • やり方は真似したい(踏襲する流れになっている

MicroProfile 2.0でJava EE 8の機能が入ってくる(2018/3/31

Key takeaway

  • Java EE 8がようやくリリースされた
  • EE4Jは始まったばかり
  • みんな意見を言ってくれ(食い気味に

5. Microservices Topic & Approach

https://youtu.be/XT2tIh9r6Eo?t=2h39m

  • ホテルを早めに予約しないと辛い(10月のサンフランシスコはいろんなイベントがやっている
    • 近くて4万、車で10分15分で2万(1泊
  • 土曜日が40時間ぐらいになる(時差の影響
  • 10月は結構寒い(特に夜
    • 行き先や料金とかもアプリでその場で決定できてよかった(Uber
  • セッションの事前予約はしっかりね
  • パネルディスカッション系のセッションは辛い(英語力ぅ・・・ですかねぇ・・・

セッションの紹介

モノリスからMicroservicesへ

自社の事例を話していたセッションで共通している内容

  • まだ旅は続いている

技術よりも組織・文化についてかなり強調されている

  • コンウェイの法則
    • 組織のコミュニケーション構造がシステムに反映される
    • 逆法則もある
  • Autonomyを何より重視
    • 独立リリースを継続的に可能な状態にする
    • 破壊的な変更はちゃんと手続きを取る
      • エンドポイントの移行期間を設けるとか

今の議論の対象は、サービスという部品をどう協調動作させるかということになっている

Eventual Consistency

結果整合性、いつか一致していればいいというものであれば、マイクロサービスにあっている

Event sourcing

  • データストアをイベント記録に使う
    • データをどんどんインサートしていく(更新しない

CQRS

都合のいいデータストアにEventual Consistencyでデータを同期していくとイイね!

CQRSってなんぞ?

複数ServiceにまたがったTransaction

  • Long Running Action
    • MicroProfileの仕様
  • WildFlyが一部だが単独で利用できる

考察

  • 今、自分たちにマイクロサービスの必要性があるかを考えたほうがいい
  • ある程度は固まっていているほうがいい
  • 組織や文化とセットで考える必要がある
    • 継続的に分散されたサービスを扱っていけないのであれば、きつい
  • どこまでの複雑性や変化を受け入れられるかを考えながら分割するのがいい
    • Service間Transactionとかやりだすとつらそう

6. Fn Project

https://youtu.be/XT2tIh9r6Eo?t=3h31m55s

Functionとは? 入力を受けて何かして出力する小さいプログラム

Functionの問題点 - 各ベンダの独自実装 - Javaのサポートが甘い

理想的なFunctionのプラットフォームとは? - Open Sourceでベンダーロックインされていない - 場所を選ばず使える(クラウド - 簡単に使える - Dockerで動く - デプロイとかで既存のものが使える

Fn projectはApache 2.0 License

FDKというJava用の開発キットが用意されている

CIを利用していてもCIの結果が戻ってくるまで数分かかる Fnではここが数秒間になるようにしようとしている

Fn Flow

複数の処理をまとめられる(コンカレントAPIっぽく使える

ブログ

7. Community&総括

https://youtu.be/XT2tIh9r6Eo?t=3h43m30s

図を出すと反応が多い

JJUG CCC fallの申し込みよろしく

8. LT

懇親会は出てないのですが、見つけた資料の内容がよかったのでこちらも貼っておきます。

所感

  • Javaが生まれ変わろうとしている感じがある
  • Oracle依存が強いとライセンス費用がやばくなりそう
  • 自動生成系のライブラリはこれから辛そう
    • 実際、JOOQの自動生成処理がJava9だとエラーになって動作しない
    • JOOQはまだメンテナスされているからいいにしろ、メジャーバージョンアップデートのときになんとか対応できていた系のライブラリはそのうち使えなくなりそう
  • コンウェイの法則はありますあります
  • マイクロサービスが目的になっているところもありますあります
  • 去年ぐらいにCQRSなデータストア採用できないか考えてたけど、やっぱりまた考えないといけないかなぁ
  • Fn Projectは実際のコード見てみたらなんか期待を感じた