[参加レポート] Scala関西Summit 2018 に参加してきました
西田@大阪です。
Scala関西SummitはScalaをテーマとした勉強会では関西最大級のイベントです
今年は1日目セッションと2日目アンカンファレンス(1日目で参加者から内容を募集する)で構成されていて、どっぷりScala漬けになれる素敵なイベントでした!
AkkaTyped:Akkaで型安全にメッセージパッシングする!
- Akkaやアクターモデルについて簡単におさらい
- メニーコア時代における並行分散処理をおこなうツールキット
- アクターモデル!
- 並行処理の計算モデル
- 全てはアクターである
- 本質的に並行性を備えてる
- Akka Actors
- 根底のモジュール
- JVMの並行処理の大変な部分を隠蔽
- tell(!)メソッド型安全じゃない問題
- AkkaTyped
- メッセージパッシングを型安全に行うためのモジュール
- Behaviorsは入れ子構造になっている
- 状態は再帰を使って表現する
- Akka Actorsと比べて大きくコーディングスタイルが変わる
- パターン比較
- アクター生成とAsk
- スーパービジョン
- ライフサイクル
明日から使える実践エラーハンドリング
- C言語では成功失敗を表すことが一般的
- エラーチェックが強制できない
- 成功失敗以外返すと複雑になる
- エラー処理で本筋の処理が埋もれる
- 例外機構の導入
- エラーチェックが強制できない
- 成功失敗以外返すと複雑になる(goでは多値を返せることで解決)
- エラー処理で本筋の処理が埋もれる
- Javaの例外機構
- 検査例外でエラー処理を強制
- 成功失敗以外の値は
- 合成可能性が低い
- 検査例外か否かは呼び出し側が決めたいことが多いが、メソッド定義時に一緒に定義する必要があるのでミスマッチを生むことが多い。その結果例外を握りつぶしが発生する
- scalaの例外機構
- 検査例外をなくした!
- scalaもtry-catch。catchがパターマッチが使えるのでより柔軟にエラー処理を統合/分岐させれる
- NonFatalという致命的なエラーをキャッチさせないためのExtractorが用意されいている
- エラーのチェックを強制できない
- 成功失敗を値として表現
scala.util.Try
- 型引数を一つ。本来の戻り値の型
- Success => 本来の値を保持
- Fialure => 例外を保持
- 呼び出し元は値を取り出すためにパターンマッチで分岐を行う必要があるためエラーチェックを強制できる
- for式で合成が可能なためtryみたいなことを実現できる
- 失敗が全てThrowableに丸め込まれてしまう
- 業務例外の網羅性検査などが行えない
- 型を見ても何の例外になるかわからない
- Either
- 成功失敗ではなくAかBかどちらかを表す
- 文化的な背景からLeftに失敗、Rightに成功を表す
- 失敗の方を指定することができる
- 使い分け
- 必ずエラーチェックをする場合 Either
- TryはAPIに現れないようにするのがおすすめ
- 補足してもしょうがないエラーはTry-catch
ZOZOSUITはScalaで動いてるよ!
- プロジェクト紹介
- グローバルECは全部Scala + Playでできている
- フロントエンドSPA、APIのみ
- Scalaにした理由
- ZOZOはScala歴が長い
- ZOZOフリマはScalaで動いてた
- 静的強い型付け言語かわいい
- 計測API
- 機械学習の要件がうすくなっった
- Scalaがかわいい
- 現在はPython半分、Scala半分
- http4s/cats affect
- 社内でひろめるためにやってること
- 週一で勉強会
- 使い方
- ダブルレビュー制度
- ビジネスロジックの正しさは各チームのリーダーがレビュー
- テックリードがScalaとしての正しさをレビュー
Readable Code in Scala
- 読みやすいコードとはなんだろう
- 読みにくいコードから考える
- パターンマッチ編
- match式のおさらい
- collectを使う
- 無名関数とパターンマッチを合わせたPartialFunctionがある
- Try#RecoverWithなど標準ライブラリで使われている
- for式編
- withFilter flatMap map forEachのシンタックスシュガー
- Scala REPLでシュガーする方法
Akkaを分散トレーシングで見てみよう
- OpenCensus, JaegerでAPI分散トレーシング
- 日時、月次の集計バッチにScala使ってる
- Tracing
- Span全体のStartからFinishまでを含む Spanの集合体
- 有向グラフで関係が表せる
- OpenTracingは仕様でCNCF管理下のプロジェクト
- CNCF Trail Map
- Jaeger
- CNCFのプロジェクト
- ロゴが可愛い
- 使うだけなら all in one なdocker imageが利用可能
- OpenCensus
- OpenTracingとは別物
- Observabilityのためのライブラリ
- metricsとtrace
- Google製
- MetrisとTracingどちらもほしい
- TracingだけだとOSの情報がとれない
- TracingID
- amazon trace id
- cloud trace context
- Uber-trace-id
- ロードバランサーやWEB Proxyがつける
- ESの起動が遅い
- OpenCensusは増えていく
- OpenMetricsといったプロジェクトもCNCFで立ち上がっている
DatabricksとSparkではじめる [データ分析/機械学習] 実践入門
- アプリケーションとは別のVPCでDatabrics VPCを用意している
- CI/CD
- オートスケールをHadoopつかって使ってると増えて使ってないと減る
- シームレスにSparkをいったりきたりできるのがよいところ
- 強調フィルタリング
- Spark String Indexerで文字列を数値に変換する
Scalaでのドメインモデリングのやり方
- ユースケースからドメインモデルを考える
- 責務駆動設計
- CRUDより判断・加工・計算を表すコントロールに注目する
- ロバストネス分析
- レイヤーを必ず分割してほしい
- SBTのプロジェクトとして分割してほしい
- 循環参照になってからはおそい
- ドメイン知識の正体はCRUD以外の判断・加工・計算の振る舞い
- 集約毎にリポジトリを実装する
- 更新タイミングも集約を考える際に重要
- 閉じた操作の導入で凝縮度を高める
- プリミティブ型のGetterはドメイン知識が外に流出する
- 代わりにGetして操作(判断/加工/計算)をドメインオブジェクトに集約する
- わざと長い名前にして増えてきたらリファクタリングする
感想
初心者向けからガチの人の向けのものまで、幅広い方が楽しめセッションがありとても楽しかったです。
東京からの参加されている方も多くとても注目されているイベントだと感じました。
とても刺激を受けたので "Scalaかわいい" と思えるまで本格的にScalaを勉強してみようと思います!