Fallに行ってきました。自分の学び・メモと所感をまとめておきます。AWSをクラウドエンジニアがいじってみたインフラエンジニアの視点で語ってくれるのは新しい発見があるかも、と思って参加。メモできなかった部分も多く、資料が公開されていないのがちょっと残念。不正確なメモもあるかもしれません。認証情報はインスタンスプロファイルから自動的にとってきてくれるセッション情報を外部化する理由スティッキーセッションにすると、オートスケールしても負荷が分散されにくいEC2の可用性は99%なので、結構落ちる。そのため外部にセッション情報をもたせたいRDSプロパティを設定しておくと、@TransactionalのreadOnly=trueをリードレプリカに振り分けできるSQSBean定義をするだけで、メッセージの送信元を定義することができる@SqsListenerを付けるだけで簡単にメッセージを読み出すメソッドが定義可能ただしメッセージの複数受信と複数送信ができないため、頻繁な送受信が行われるシステムには不向きLambdaRDSと相性が悪い。ステートレスで、コネクションプールの実装が難しい内部でスケールアウトしてしまうと、最大同時接続数が制御できないRDSとの相性問題を緩和するには?DynamoDBを使用するなど所感やはりインフラエンジニアの視点だと関心事が異なるので、新しい発見が多く得られたので良かったです。AWSでも解決されないんだなぁと感じました。少なくとも、タイムリーにリクエストを捌くことが求められるAPIには向かないと思っています。@Transactional(readOnly=true)で自動的にリードレプリカに振り分けられるのは一見「便利そうだなー」と感じましたが、現実では使い所がかなり限定されそうだと感じました。@Transactionalを多層にしてreadOnlyがtrueとfalseのものが混在した場合、どんな動作をするのか気になります。AWSにロックインされるのはそれなりにリスクなので、プロダクションへの採用は結構ハードルが高いかも、と感じました。逆に、個人でちょっと遊んでみるにはかなりハードルが低そうです。開け!ドメイン駆動設計の扉DDDについてのステップアップセッション。GMOインターネットの成瀬さんの発表。残念ながら、発表資料は諸事情につき公開できないそうです。数年前にスピードが重視された。その結果、今苦労していませんか?DDDは最初のスピードを捨てて、長期的に変化に耐えられるようにしている。その効果が発揮・理解されてきているその他ドメイン駆動設計のゴールとは、ソフトウェアの利用者とコードが地続きになることドメインとコードを行ったり来たりすることが重要リファクタリングをする勇気を持つことも必要ドメイン駆動設計についての書籍を、来年2月に出版予定とのこと所感DDDの考え方について、改めて知ることができて良い機会でした。「当たり前のことを当たり前に実践する」という言葉がありましたが、これは普段心に留めている言葉なのでとても心に響きました。2019Pivotalジャパンの槙さんの発表。Initializationを有効にして、全部まとめて起動時間を短縮できるようになった。デフォルトがJUnit5になったHealth機能が改善されたGraalVMで動かすための設定が減っている。今後は設定が自動生成できるようになっていく予定。サードパーティライブラリは別途、要対応GraalVMは起動速度とメモリ消費量「だけ」に特化したマーケティングなので注意デモのビルドでは、3分くらい時間がかかっていた今後6ヶ月毎のマイナーバージョンアップを行うようになった。所感Springは、新しい技術についてもどんどん取り込んでいくことが強く実感できたセッションでした。内容的に結構ついていけなかった部分もあり、キャッチアップ不足かもと反省。あとはSpring開発コミュニティのバナーに対する愛は伝わってきました。バナーの機能は結構いろいろあるなーと思っていましたが、ここまで改良の歴史があるとは...。Java界隈では最近GraalVMが持て囃されている印象ですが、「起動速度やメモリ消費量以外はむしろJITに劣る」ということを知れたのは一番の収穫でした。Technologyの進藤さんの発表。学び、メモ重要なのは、ソースコードの読み方を知ることソースコードを読むときはIDEがオススメマウスオーバーでの変数・引数の確認や、型へのジャンプができるソースコードを取得して開いたりすることもできるソースコードを読むときのコツ適度に読み飛ばすことも必要。読み飛ばしていい所を理解できるようにする読み飛ばす所の区別を付けるためにも、読む目的・目標を設定するまずは広く浅く読む。個人的には以下のような場面でソースコードを読むことが多い気がします。OSSの公式リファレンスを読んでもよくわからないとき、疑問が浮かんだとき使い方が分からないとき(テストコードを中心に読む)バグっぽい動きをしたときみんな、どんなときにどのくらいソースコードを読むんだろう?と思いながら聞いていましたが、「目的を決めるのが重要」ということは人それぞれなのだろうと思いました。DBUtilsは存在自体を知らなかったので、意外な収穫でした。会場でも知っている人は少なかったようです。SourceTrailも知りませんでした。IDEAのクラスダイアグラム生成機能を使っていましたが、SourceTrailも一度試してみようと思います。Serverless時代のJavaについてAWSの方による発表。残念ながら、個人的にはあまり収穫がありませんでした。挙げるとすれば、LambdaでJavaを使べきでないという確信が強くなったことでしょうか...。AWSの人の発表なので、ポジショントーク感が強かったです。GraalVMを採用するにはリスクもコストも大きすぎるように感じられました。現時点ではGraalVMは容易に使えず、GraalVM⇔JITの互換性が低いように思いますが、これが今後どのくらい改善されるかに注目しています。最低でも3年はかかりそうな気がしますが、それまではJavaでLambdaを使うのは現実的ではないかなーという結論に至りました。3.0によるAPIサーバー開発ヤフーの方による発表。APIの方が開発が活発で、コントリビュータが多い開発規模(資料)3ヶ月でフルスクラッチ開発したマイクロサービス自動生成が21660行、自前での実装が17794行。Specからコードを自動生成する枠組みは知らなかったので、事例として良い勉強になりました。Gapパターンという名前を知ることができたのも良かったです。この考え方は自力で思いつくかもしれませんが、それを共通言語でやりとりできることも重要なので、大きな収穫でした。現時点ではまだ採用に見合わないかなーと思いましたが、うまく使いこなせば開発を大きく効率化できそうだと感じました。この辺りは継続して情報収集したいと思います。ご紹介モニタリングとか自動でやってくれそうな雰囲気。運用を支えるためのログを出すにはどうするか?メソッドの最後で出力するのがよい。AOPはノイズが増えたりするので、おすすめしないシステム間通信の結果は出力したほうがよい。JPAを採用してしまったのか...全体の所感あくまで個人的な主観をざっくりまとめると、以下のような感じ。コード自動生成、良さそう。試してみよう結構テーマが偏っていた気もするけど、いろいろと収穫があったのでよい一日になりました。