JJUG CCC 2019 Fall Head toward Java 13 and Java 14 資料: https://www.slideshare.net/YujiKubota/head-toward-java-13-and-java-14-jjug
Java 13 5つの機能追加。1378個のバグ修正 * Dynamic CDS Archives * Class Data Sharing。共通的なクラスや文字列などを複数プロセスで共有する機能。起動時間を短縮できる。後出しできないので異常系を含めてロードする必要あり * ZGC: Uncommmit Unused Memory * ZGCが未使用のメモリをアンコミットしてOSに返すようになった。Xmsは下回らないようになっているので、XmxとXmsが等しければ自動的に機能が無効になる。 * Reimplement the Legacy Socket API * Socket API(java.netSocketやjava.net.ServerSocket) の内部実装が変わった * Switch Expressions (Preview) * Switchの戻り値を示すステートメントが break から yield に変わった。 * Text Blocks (Preview) * ヒアドキュメント。文字列を書いた通りに読み込むことができる。提供されるクラスは @Deprecated が付与されているため、今後変更されたり消される可能性あり。 * Unicode 12.1サポート。 * Java 5時代からていあんされていたBufferのAPIが追加された。 * -Xmsは正確には亜初期サイズであり最小サイズではない
Java 14 8 + 5個の新機能 »
基調講演 杉原博茂 Oracle Japan VISION 2020 日本を幸せにするクラウドカンパニーへ Javaが日本を幸せにする 日本には多大な課題がある。 働き方改革、人手不足… ITSにの人手不足が特に目立っている 2030年には約60万人の人手不足に Oracleが提唱するのは百人力。 生産性向上。 日本のIaaSと関連するITSに製品&サービスの実態 オンプレミスで使用している経費が高すぎる。 IaaSだと2100億円で済むのにオンプレミスだと12兆円かけている。 TIOBE プログラミングコミュニティインデックスで1位 Java 22年目 Bernard Traversat ｢Java is dead.｣は常に言われ続けてきた。 Oracleが買収してから言われなくなった OpenJDKのアクティブなコミッターは136%増えた。 No.1の開発環境としてJavaは存在する。 今はクラウド上でも。 世界中で使用されているJava。97%のエンタープライズデスクトップで使用されてきている。 Javaの哲学 クラウド上でのJava SE DockerとJavaとの親和性について Java 9 Features
Project Jigsaw 122の新しい機能。 19の機能はインテグレート、クローズした。 JEP 261 Module System JEP 200 The Moduler JDK JEP 222 JShell JEP 295 AOT JEP 282 jlink JEP 260 Encapsulate Internal APIs Beyond Java 9 »
Java Day Tokyo 資料集 http://www.oracle.com/technetwork/jp/ondemand/online2018-javaday-4489556-ja.html
Java in a World of Containers jdepsを用いれば特定のモジュールが使用している依存関係を明らかにできる。 jlink --compressを使えば20%以上JDKサイズを減らせるとのこと Alpine Linuxを使えば小さいサイズのOSとして使えるよ Class Data Sharingを使えば、コンテナ間のクラスファイルを共有してメモリを節約できる上に、起動時間とフットプリントを削減できる 実験的な機能だが、Ahead-of-Time Compilation(AOT)を使えばJITのように…
JDK10のコンテナにおける設定で以下が参考になるとのこと。 https://mjg123.github.io/2018/01/10/Java-in-containers-jdk10.html
-m でメモリの設定をでき、ヒープサイズ、GCのリージョンサイズなどに反映される。
Running Java applications on Docker: practical tips and valuable insights 資料 https://static.rainfocus.com/oracle/oraclecode18/sess/1518180594155001UEZ0/PF/2018-OracleCode-RunningJavaapplicationsonDocker_1524672830935001dCr8.pdf
サンプルコード https://github.com/babadopulos/docker-java-issues-demo
メモリ Maven内のjava -jar ${JAVA_OPTIONS}でオプションを設定し、dockerのオプションでJAVA_OPTIONSでヒープサイズの最大値を設定すること
デフォルトだと、コンテナは可能な限りメモリを使おうとするため、-memory, -memory-reservation, -memory-swapを設定すること。
CPU モンテカルロ法を用いてCPUを大量に使うサンプルで実験した。 コンテナのCPU数を2つに設定したにも関わらず、8つのコアを使おうとしていた。 --cpu を設定することを忘れずに。 8コアのCPUを全て使うアプリケーションを2つ同時に動かすと、CPUの取り合いでアプリケーションの実行時間が長くなるが、2コアに絞ったアプリケーションを2つ動かした場合は実行時間はほぼ変わらなかった。取り合いが起こらないため。
セキュリティ /dev/random → /dev/
haveged - simple entropy daemon デバッグ dockerにオプション(JAVA_OPTIONS=ーXdebug etc…)を与えてあげれば、Java Agent経由でリモートデバッグができるとのこと。
統合試験 複数同時の実行をする場合は、docker-compose -p {app-1 or app-2} . »
https://techsio.connpass.com/event/59789/
あたりまえのことをあたりまえにやる難しさ @voluntas https://gist.github.com/voluntas/08671d717290a6f63cddd95052a33a86
文化の明文化の重要性 変化を受け入れられる文化を作ることが非常に重要 各組織によって自動化の手法は違うから他組織の事例は参考にならない。 自身で作るしかない。 レビューはモラル 結局個人のモラルが重要になってくる。 レビュー時によくわからない箇所を指摘して、その反応を見ること。 指摘箇所が分からないとか問題外。 READMEとCHANGESをきちんと書くことで更新差分が分かるようになる LT: AWS ECS （EC2 Container Service）を用いた AWS へのDocker コンテナデプロイ @legoboku https://www.slideshare.net/legoboku/aws-ecsdocker
自動化におけるコード管理 高橋さん 各メンバの役割を決めて、ルールに則っているかどうかという観点でレビューを実施した。 新人が先輩をレビューする。
LT: 送信メールサービスをユニットテストしてみた @zinrai メール送信テスト ネットワーク環境やSMTP認証の有無によるテスト LT: DevOpsとドキュメントデザインパターン @yuzutas0 https://speakerdeck.com/yuzutas0/20170703
DevOps、本当のところ - ファーストリテイリング @shot6 @voluntas さんの話とかなりかぶっていたため、直前で資料を修正した、とのこと 100%内製は非現実的。 内製化によって効果が高いものを選定する。 オンプレミスをやめて100%クラウド化 DevOpsという言葉自体が怪しい https://ja.wikipedia.org/wiki/DevOps 開発 (Development) と運用 (Operations) を組み合わせたかばん語であり、開発担当者と運用担当者が連携して協力する開発手法をさす。[1]ソフトウェアのビルド、テスト、そしてリリースの文化と環境を以前よりも迅速に、頻繁に、確実に発生する確立を目指している。 ↑ 分かる また、DevOpsにビジネス部門を追加したBizDevOpsというワードも広がりつつある。ただし2013年現時点では厳密な定義は存在しておらず、抽象的な概念に留まっている。 ↑ 怪しい 大きな粒度での自動化は難易度が高い。 エンジニアにあてた成果を上げるのではなく、大きな単位での成果を上げるには厳しい。 DevOpsの文化を根付けるのが非常にきつい 理想のゴールを設けるより、具体性のある変化、実施を優先する 自動化そのものはゴールであって、組織体制、チームの分担などの変化が大事。 評価制度をきちんと設けないとDevOpsが進まない チーム組成･技術ﾏﾈｼﾞﾒﾝﾄを含めて費用対効果を考えること »
講演 Vue.js、機械学習系の同人誌がよくはけた 下調べをしないで来る人が多いのでアピール大事。 今回も会場は狭いとのこと。机が狭い。 運営ブースが外に出る可能性あり。 サークル申し込み数は前回の1.5倍 価格によって販売実績が大きく変わるということはないらしい。 ページ数*10円が相場。 一人あたり1500Wの電源を申告すれば使えるらしい。 家庭用電源。 見本誌にはシールが必要なので忘れずに。 サークルカットはWebならいつでも変えられる。 印刷物の締め日はまだ決まっていない。 これまでの支援と取り組み オンライン入稿サポート、ビルドサーバーの提供が魅力的 »
おおまかな流れについて 当選してから会議までは調整をして、執筆は一ヶ月程度。 需要を考えて書くのも大事だが、それよりも自分の興味に関する題材で執筆をした方がよい。 事前広報、ウケるように頒布会場用の準備に割いた方が良いとのこと。
計画、企画 大体イベント単位で行う。 今回の場合であればターゲットは技術書典4。 Techboosterは、基本は最新技術に関する題材を扱っている。執筆者が楽しく書きたいことだけを書く。 テーマも一緒にまとめるが、会議では知りたい技術的なあれこれが飛び交う。
執筆、編集 執筆 Markdownでは書籍執筆の範囲をカバーできないのでRe:VIEW ビルド CircleCI 編集 校正 レビュー 印刷、マーケ、頒布 紙と電子の販売比率は8対2。 意外と紙も売れる。 HowTo執筆 最近の書籍は初心者向けの読者層向けのものが多い。 Amazon、ComicZin、booth.pmを見てみること 同人印刷 日光企画 PP張りのフルセット価格表 基本的には10日前に入稿した方が20%引きで安いとのこと。 データ不備で返される場合もあるので、早めに入稿しておくにこしたことはない。 フォント(Noto)をPDFに組みこめるDockerイメージもある。 https://hub.docker.com/r/vvakame/review/ フォントに関して 本に印刷する分にはMacデフォルトのフォントを使用しても問題ないらしい 電子(ePub等)に同梱するとNGの場合があるらしい。 ノド 表１（表紙）、表２（表紙の裏）、表３（裏表紙の裏）、表４（裏表紙） 目次案は早めに作成しておいたほうがよい。 深さ2, 3程度まで書いておくほうが後が楽。 複数人で書くと表記ゆらぎが発生するが、それを改善するためにprhというツールをTechboosterは使っているらしい。 https://github.com/prh/prh その他 ビルドサーバーの提供について、2月末頃を予定しているらしいが忙しくてなかなか進んでいないとのこと。 本日使用した資料を公開してくれるかどうか、わかめさんがひだかさんに確認してくれるとのこと。 公開予定はなしとのこと。 TODO: 技術書典用の名刺 »