BuriKaigi2018 に参加してきた
今年もBuriKaigiに参加してきました。
天気はぎりぎりでしたが、富山県のそれも氷見市に豪華なスピーカーがたくさんでした。
今年も、私は Java+α の部屋にずっといて、Javaやら、その他もろもろやらの話を聞きました。
JavaOne 2017フィードバック - JDKリリースモデル変更とJava EEのEclipse Foundationへの移行
Oracleの伊藤さんによる、2017年10月にあった、JavaOneの振り返り。
ここ最近のキーワードはNimbleだそうで、軽量だったり俊敏だったりという意味。
これもあって、JDKのリリースサイクルの話になったのか？
Java EEの策定は、OracleからEclipse Foundationに移動したらしい。
直接EEを使うことはあんまり無いけど、Oracleから距離を置くのは、良いことなのやら、悪いことなのやら。。。
で、JDKのリリースモデルの話。
時系列に沿った、各バージョンのライフサイクル。
結構衝撃的な内容かと。
JDK8は、従来よりちょっと延命されて、それでも2019年1月になってしまうと、バグ・セキュリティホールの修正といったものが配布されない模様。（要確認？
そして、今後は、
- 基本的にはOpenJDKの最新版に追従。ただし、次のバージョンが出たら、可能な限り早急にバージョンアップを行う。（その時点から修正が入らなくなってしまうため）
- Oracleにお金を払い、OracleJDKのLTSバージョンを利用する。ただし、JDK11の次はJDK17を利用することになる。
になるっぽい？
で、次のJigsawのときにも話してたけど、コンサバに行くのであれば、今のところはJDK8を使い続けつつ、Jigsawの影響はでかいのでそれの対応準備だけしておいて、JDK11を待つ。（順次、10, 11の準備も必要）
で、JDK11が出たら、Oracleにお金を払いつつ、OracleJDKを利用する形にバージョンアップ。
それ以降は、3年間隔ぐらいで、新しいLTSに乗り換えていく。みたいな風になりそう？
上記に関連して、今までは各バージョンにいろいろ入れようとしすぎて？リリースが2年超えて4年とか空いていたけど、次からは6ヶ月単位でリリースするらしい。間に合わない機能などは、次のリリースに持ち越し。
（Rubyも毎年クリスマスにバージョンアップしてますしね）
いちおう、JDK8の個人利用は2020年12月まで可能とのこと。
ただ、企業での開発・運用には使えないので、本当にホビー要素か、官公庁？などの公共サービスでは使えるらしい。
モジュール移行の課題と対策
上記でもちらっと出てきた、JDK9にする時の難所、Jigsawに関する話。
Java in the Box の櫻庭さんの話。
スライドはこちら。 モジュール移行の課題と対策
JigsawをJavaの機能として導入した動機としては、
-classpathの問題。ライブラリが並列に大量に並んだり、publicがpublic過ぎ（パッケージ間では公開したいが、モジュール外部には公開しない、といったことができない）- rt.jarのサイズの問題。640MByteぐらいあったので、小さなアプリケーションでも、動かすときは大きなバイナリになってしまっていた。
moduleを作るのは、jdepsとかのツールを使えば比較的かんたんに行えるが、運用していくのはつらいらしい。
-add-exportsや-add-modulesといったオプションを駆使していくことで、JDK9でも動作するように出来る。らしい。
Running Kubernetes on Azure
ほとんどのMicrosoft MVPが.NET側の会場にいる中、+αとしてKubernetesをAzureで動かす話。 仙台から、JAZUG 東北から来ていただいた、 山本 誠樹さん。（今回のスピーカーには、「山本」さんが多い。。）
スライドはこちら。 Running Kubernetes on Azure
実は2013年には登場しており、VISAカードのインフラにもなっているDockerは、そろそろ手をつけないと。。。
また、コンテナ管理・運用ツールとしては、Kubernetes(k8s)が事実上の標準に。
Azure上で動かす場合は、Azure Container Service (AKS)を使うのが最新で、おすすめということでしたが、日本リージョンはまだ無いらしい。また、GAになってないらしい。
ただ、そのうちGAにもなるし、日本にも来るはず。たぶん。
従来のPaaSは、簡単に始めて運用できるが、複雑なことが出来ない。 これからはPaaS上でDockerを動かし、複雑なこともコード化して管理できる。Infrastructure as a Code的な。になるだろう。とのこと。
日本語入力の落とし穴
休憩挟んで、mzpさんによる「日本語入力」の話。
名古屋から来て、ちゃんとMisocaの宣伝もしてました。
スライドとか、詳しい内容はこちら。 🐟日本語入力の落とし穴 #burikaigi - みずぴー日記
日本語入力とか、パスワードとかクレジットカード情報とか全部通過させてて怖くない？私は自分が作ってるからいいけど。とのこと。
たしかにーｗ
SKKについて話が出てたけど、「「Lを押したらLが入力された」問題」って、何を言っているかわからないｗ
とりあえず、変わったことをやろうと思ったら、本気で取り組まないと行けないんだな、、、と思いました。まる。
16枚目のスライドで、ハングルの入力例が出てたけど、初めて知った。
英語的に直接入力してるか、日本語的に変換してると思ってたから、それ以外にもあることに驚き。
「確定する前の文字列」や「入力メソッド用のキー」という概念が英語圏などには無く、日中韓が連携して入力メソッド周りを良くしていく必要があるそうな。
JetBrainsでもっと楽しくコーディング、ワークフロー
株式会社サムライズムの山本ゆうすけさん。 個人的にはTwitter4Jを作ったすごい人、最近はIka4Jというのも作ってるそうな。
まずはJetBrainsの、IDE以外の製品について。
YouTrackは課題トラッキングツールでRedmineとかJIRAみたいなもの。
keyboardでの操作が強く、Agile Boardもついてる。
Upsourceはコードレビューツール。GitHubにもついてるもの。
ただ、こちらはJetBrains製品だけあって、サーバ側で参照を解決しており、宣言に飛んだりをWEB上で出来る。
TeamCityはJenkinsやCircleCIみたいなCIツール。
ただ、IDEに引きこもってる人にとっては、IDE上で通知が出てきたりして便利。
Excel芸2018
名古屋から来られた、 bleis さん。
Excelはプレゼンソフト、ということで、発表資料自体がExcelで作られてました。
ただ、Excelを直接編集して作成したわけではなく、プログラマらしく？Markdown風に書いて、それを変換して出力してるらしい。
Excel方眼紙が仕方なく必要になる場面はあるけど、プログラマらしく技術の力でそれに立ち向かうべき。
他の形式で資料を作成しつつ、最終出力としてExcelを出せば良い。
（ただし、"最終"と言っているように、出力結果のExcelを触ることは想定しない）
Excel出力といえば、JavaならPOI。
ただ、APIが低レベルすぎ、Excel自体が多機能なのでPOIも多機能。
ここも、ラッパーライブラリを作ることで対応できる。
POIとの接続部分は副作用の塊になってしまうので、影響範囲を抑えつつ、
それ以外の場所ではScalaらしい関数型の副作用の無い世界で実装されてた。
Asciidocの紹介
個人的には うさぎ組 のテスト系ですごく刺激をもらっている kyon_mm さん。 今回は、Asciidocの紹介。
設計書などの仕様の共有にはExcelがよく使われてたりしますが、Gitでの管理がやりづらい。
Wikiとかで書いてもいいが、Gitのコードの変更とつなげるのは面倒。（Atlassianの製品で揃えたりしたら出来なくはないけど）
というわけで、プレーンテキストでコードと同じように管理しつつ、見やすい形に変換できればいい。
さらに、エンジニア以外（マネージャとか経営陣？）とかでも、簡単にインストール出来るものが良い。
というわけで、Asciidocの紹介。
- オライリーの書籍などでも使われている＝本が作れるぐらいの表現力がある。
- プレーンテキストで記述して、RubyかJREがあればHTMLに変換可能。
- テーブルなどもデフォルトで定義されている。（Markdownのテーブルは拡張機能。）
- テーブルの記述方法が人間にやさしい。（Markdownは各セルが横に並んでいくので、追加などはしづらい。）
- HTML変換でき、動画埋め込みなども柔軟に出来る。
- 画像のサイズ指定が出来る。
- PlantUMLで図が書ける。（graphvizと拡張のgemは必要）
kyonさんの会社でもすでに、受託案件のユーザガイドをAsciiDocで納品してたり、
お客さんがいつの間にか使い始めてたりしているそう。
PDFにするのであれば、HTML変換してからChromeでPDF保存がおすすめとのこと。
便利そうなので使ってみたいが、このあたりは関係者全員の理解が無いと難しいので、先は長そう。。。
とりあえず、個人的に使って見るところから始めようと思います。
まとめ
今年も、内容の濃い・バライティに富んだセッションでした。
また、人数が多すぎない（良いのか？）ので、スピーカーとも比較的距離が近く、良かったです。
個人的な反省としては、この記事を書き上げるまでに一週間かかってしまい、記憶が薄れてしまったので、
今度からはもっと新鮮なうちに記事を書かねば。。。と思いました。ブリだけに。
あとは、聞きながら取ったメモをそのまま貼り付けておきます
## JavaOne 2017フィードバック - JDKリリースモデル変更とJava EEのEclipse Foundationへの移行 JavaOneは2017年の10月に開催。 キーワード：Open, Evolving, Nimble, Scalable Nimbleが追加。軽量化・俊敏性などの意味。 Java EE 8 Available, Open, Nimble EEはEclipse Foundationから発表される。 Java SE 9 Available, OpenJDK, Cadence ### JDK 新しいリリースモデル 2018/1/30現在 JDK7の段階で、Coin, Lambda, Jigsawが計画されていた。 7: Coinの一部 8: Coinの一部、Lambda 9: Milling Coin, Jigsaw JDK9は、過去最多の機能追加。 7, 8, 9と倍々ぐらいに増えてる。 リリースの間は、機能追加はほぼ無かった。（リリース間隔が長い） 他の言語は、リリース間隔がもっと短い。 #### 従来のリリースモデル メジャーバージョンは、2年に一度を目標。 Oracle JDKの後継バージョンのリリース後、1年の無償サポート 更新リリースは3ヶ月後。基本的にはメンテナンス用のアップデート。（limited updateもあった） 有償で長期サポートもあった。 #### 新しいリリースモデル 機能リリースが6ヶ月に一度（固定） 3, 9月 無償で使うものは、基本的にOpenJDK。後継バージョンのリリースまでの6ヶ月間の無償サポート。 JDK9, 10は試用期間的な感じ。 完成した機能からリリース。予定されていたものが間に合わなくても、リリースはする。 リリースの重複期間がなくなる。 OpenJDKとOracleJDKの技術的な差分をなくす（2018年後半） 更新リリースは今まで通り。ただし、limited updateは入らない。 長期サポート(LTS) 2018年9月から開始。（JDK11に該当） OracleJDのバイナリ（有償） 8年の長期サポートの提供。 JDK8の無償期間が伸びた。2019年1月まで、無償期間。 個人利用は2020年12月まで。企業での開発・運用には使えない。個人・公共サービスで使う場合は、使える。 リリース情報の提供 OpenJDKから提供 http://openjdk.java.net/ Deprecatedの運用ルールはそのまま。最短1年で機能が削除される可能性。 本番運用するのであれば、JDK8 -> JDK11にしたほうが良いかもしれない。 リリースモデルまとめ Java Plug-in, Java Web StartのサポートはJava SE 8まで。 9には残っているが、10からは削除される。 Java SE 8から後継バージョンへの自動更新は行われない。 9の32ビット版のバイナリ提供の予定は現状ない。移行もしくは現状維持。 Server JREも、同じリリースモデル。 ### Java EE 8 Eclipse FoundationへJava EEを移管する。 MicroProfile.ioとの統合を模索する。 まだいろいろ検討中。 ## モジュール移行の課題と対策 Jigsawの話。 ### 動機 #### -classpath問題。 ライブラリ多すぎ。publicがpublicすぎ。 Module導入。依存性、公開範囲を明記。 #### rt.jar問題。 640MBぐらいあった。 機能ごとにModuleに分割。 ### Module module-info.javaに依存性、公開範囲を記述する。
module モジュール名 { requires 依存するパッケージ; exports 公開するパッケージ; }
module作るのはかんたん。運用するのは難しいけど。 javac --module-path or -p （昔は、-mpだった） ### ツールの対応 IDE NetBeansがいまいちの対応状況。 ビルドツールは、MavenもGradleも、いちおう使える、という状況。optionの記述が必要。 議論が続いていて、どうなって行くかはまだわからない。 ### jdeps 依存性調査ツール "-s"をすると、依存性が出てくる。 "--generate-module-info"で全部出てくる。必要に応じて編集が必要。 ### 非モジュールシステムでの課題 #### 非公開API com.sunとか、sunとか、java.awt.peerとかがexportされてないパッケージ。 sun.misc.Unsafe, sun.reflect.Reflectionは今後削除予定。 対策：exportを追加する。--add-exportsオプションを利用する。 非モジュールシステムでは、target=ALL-UNNAMED これで動くようになるが、いつ消えるかわからない。 reflectionでアクセスしていると、jdepsでは見つからない。 コンパイルは通り、実行時もwarning。 --illegal-access=deny をつけると、 InaccessibleObjectExceptionが起こる。 setAccessible(true)を利用したreflectionは、--add-opensを付ける。 →そもそも、使うべきではない。 #### 非標準Module javax.xml.bindが、標準のModulepathに含まれていない。 java.xml.ws, java.corbaも。 対策：Moduleを追加する。 --add-modulesオプション。 ### モジュールシステムでの課題 modulepathとclasspathを併用しなければならない。 直接アクセス：Automatic Module 間接アクセス：Unnamed Module として扱う。 Automaticはmodulepath、Unnamedはclasspath jar -d --file XXX.jar とすると、Module名がわかる。それを、module-info.javaに書く。 MANIFEST.MFに書いてあればそれが、無ければファイル名が出てくる。 Automatic Moduleは依存性を記述できないので、自分で実行時に--add-moduleを書く。 依存性がわからなければ、 ALL-MODULE-PATH を指定する。 将来的には、modulepathだけで済むはず。いつになるのか。 ## Running Kubernetes on Azure 仙台からJAZUG 東北から。 Docker自体は、2013年に登場してた。 2017年、Kubernetesが事実上の標準に。 VISAカードのインフラにDockerが使われてる。 そろそろ手を付けないと。 ### なぜKubernetesを使うか。 コンテナ管理が必要になってくる。 ### Azure上で動かす ACS, ACS Engine, JKS ACS GA済み。SLAが適用される。 日本リージョン。 マスターの課金が発生。 k8sのバージョンアップが出来ない。 公式ドキュメントにたどり着きづらい。 100Nodeまで。 ACS Engine ACSのOSS版。GitHubに公開されている。 任意のVNETに配置できる 1200Nodeのクラスタ構築できる。 展開方法が複雑。 SLAナシ。 AKS マスターノードの課金はない。 k8sのバージョンアップが可能。 Managed Disk対応。 プレビュー段階。SLAナシ。 日本リージョンに展開されていない。 コマンド3つで作れる。 「PaaSは滅ぶだろう」 今までのPaaS：簡単ゆえに、複雑なことができない。 これからのPaaS：複雑だが簡単に使うことは可能。Infra as a Code Dockerをベースに、それをいかに動かすか。 helm install stable/wordpressでWordPressが立ち上がる。 Docker Edgeバージョンで、k8sも一緒にインストールされる。 ## 日本語入力の落とし穴 すべてのキー入力を受け取る。（パスワードとかも） ウィンドウを持たない 日本国内では、全員が使ってる ロシア語など、そのまま出てくる ハングルなど、入力したところから出てくる 中国語など、音を入れると出てくる ### 「確定する前の文字列」という概念 下線が引かている状態 勝手に確定されたり、削除されたり。 SKKだと入力できない場合があったり。 ### 「入力メソッド用のキー」という概念 かなキーとか。 ## JetBrainsでもっと楽しくコーディング、ワークフロー https://github.com/yusuke/ika4j とか作ってる。 Upsource, YouTrack, TeamCity などもある。 YouTrackは課題トラッキングツール RedmineとかJIRAみたいなもの。 keyboardでの操作が強い。 Agile Boardがついてる。 ".if"とか".return" "psvm"で、mainメソッドを作れる。 ".var"で編集にしてくれる。 Upsourceであれば、シンボルの参照関係に飛べる。 Intellij IDEAのエンジンが、サーバサイドで動いているイメージ。 Intellij IDEA内で、PRのコメントが見れる。コードにJUMPできる。 TeamCityは、IDE上でビルド結果が通知される。 失敗したログが見れて、テストコードにJUMP出来る。 ## Excel芸2018 Excel is プレゼンソフト Excel方眼紙も、プログラムで解決したら良い。 バージョン管理、差分が見れない、編集が面倒 Escを押すと、入力した内容が消える 人の手によって、想定していたフォーマットが破壊される。 Excel方眼紙を出力結果にする。触らせない。 VBAは、Excel内部の話。 COMは遅いとか、ライセンスの問題。 POI Officeファイルを読み書きするJavaライブラリ。 Excelに強い。 APIが低レベルすぎる。 超多機能。ただ、未実装機能も多い。（Excelが多機能すぎる） POIのラッパーライブラリを作ればいい。 dihyd: markdown風 -> プレゼン資料モデルに変換 mono-oxy dhmo: Excel出力 flexmark: Markdownを解析 xls を使いたければ、 https://github.com/tonyqus/npoi の方がいいかも。 ただし、書き込みは壊れやすい。 ## Asciidocの紹介 簡単に構造化して、共有できるものが便利。 Gitで管理できると楽なことが多い。 Wikiに書くと、それとGit（コード）がつながらない。 Gitで管理するためには、プレーンテキストがよい。マージとか。 チームで共通に出来るフォーマットがよい。 Emacsであれば、org-modeとかもある。 必要なツールが少ないほうがよい。マネージャとか、経営陣とかでも。 AsciiDoc オライリーが作った。 テーブルなどもデフォルトである。（Markdownのテーブルは拡張） HTML変換でき、動画埋め込みなども出来る。 OTR社実績 受託開発でユーザガイドをAsciiDocで納品 お客さんが使い始める。 プレーンテキスト。 RubyかJREがあればHTMLに変換可能。 Atom, VSCodeでプレビュー付きのプラグインがある。 画像のサイズ指定が出来る。 テーブルは、ヘッダ以外は1セル1行で書ける。追加とかもしやすい。 graphvizと拡張のgemがあれば、plantumlで書ける。 asciidoctor-pdfがあるけど、うまく動かないことが多い。 HTML変換してから、chromeでPDFに保存したほうがよい。 pandocもうまく動かない。
