ScalaMatsuri2018に参加するので参加したセッションについて自分用にまとめておきます。
後ほど整理して別途どこかで公開します。（おそらく会社のブログ）

Scalaに関する神話と真実株式会社ドワンゴ水島宏太さん

Scalaって使われてるの？

世界中で使われています。
Twitter, Strabucks, Goldman Sucks, Foursquare, MorganStanleyなど

はい、少し難しいかもしれない。
が、適切な資料と講師がいれば育成は可能。

はてなやドワンゴの研修用テキストがGithubで公開中。
普通に学んでもらえば大丈夫。

高度な知識までは必要ありません。

そういうライブラリもあります。
昔よりは減少傾向にあります。

いいえ。ただし、プログラミングスタイルによります。
Javaと同じスタイルで書けばほぼ同じ速度。
関数型プログラミングのスタイルで書いた場合、遅くなる傾向がある。

はい。ただし、大幅に和らげることができます。

利用する上での規約を定めれば問題ない

いいえ
マイナーバージョンが変化しても互換性は維持（2.11.x -> 2.11.y）
メジャーバージョンが変わると互換性は維持されない（2.a -> 2.b）
クロスビルディングにより複数バージョンバイナリ生成可能

いいえ。怖くないよ！

Gitter: scalajp/public
Slack: scala-jp

* 複数のプロセスがネットワークを介して通信しながら強調して何かを遂行するシステム
* 部分的な故障を許容するシステム（故障に注目した定義）

* スケーラビリティ
* 耐障害性

Akka Cluster
- AmazonDynamo, Riakに影響を受けている
- 非中央集権的なクラスタメンバーシップ管理
  - ゴシッププロトコルによるメンバーシップ管理
  - メンバーリスト情報を知っているメンバーと交換し続ける
  - Accrual Failure Detector
    - 心拍数（ハートビート）の履歴をずっと取っておく　
  - Split Brain Resolverによる解決法
    - お互いにDownし合わないようにする
    - 分断/障害前の情報はそれぞれ持っているのでそれを元に自分が残るべきかというルールを作って、結果として高々１クラスだけが残るようにする
  - 再起動時のsedd node誤指定によるSplitBrain
Akka Cluster Singleton
- クラスターの中でSingletonActorをつくってくれる
- 用途としては下記
  - クラスタ全体での集中管理
  - 外部システムへの連携ポイント
- 簡単にボトルネックになってしまうので注意
Akka Cluster Sharding
- Actorをいい感じに分散してくれる
- ShardCordinatorがどのノードにシャードがあるかを管理
- DDDととても相性が良い
- Akka Persistenceによって、ノードの状態をDBに保存・復元が可能
Akka Distributed Data = CRDT
- バラバラに更新されても全部操作をマージすれば結果的にはOKなデータ構造
- 足し算の交換法則のようなイメージ

もし卓球部部長がビッグデータ解析を始めたら

ビッグデータを使って卓球部を強くできないか？
スポーツの世界でもリアルタイムのデータ解析が進んでいる（Data Studium）
ラズパイ、赤外線センサー、加速度センサーでボールのトラッキングができるシステムを構築（fluentd -> 分散メッセージングシステム -> ストリームデータ処理エンジン）
ビッグデータの処理プロセス
- 収集
- 変換
- 統合＆蓄積
- 分析
- 活用
分散メッセージングシステムとは
- Apache Kafka
- Amazon Kinesis
- Cloud Pub/Sub
ストリームデータ処理エンジン
- Apache Spark
- Apache Flink
- Apache Beam
- Heron
- Apache Kafka Streams
なぜ大量データ処理にScalaがよく使われるのか
- 参照透過なコードを書きやすいから
- Javaの資産を利用しやすいから
分析
- 定常分析
  - デイリー、アワリーでのレポーティング等
  - GoogleDataStudio、AmazonQuickSightなど
- アドホック分析
  - 随時思いついた疑問を分析する等
  - Apache Zeppelinなど

implicit parameter の目的
- 拡張性の高い多態を実現するため
普通のtraitの問題点
- ライブラリが提供しているクラスなど定義を変更できない場合に自前のtraitをmixinすることができない
なぜ明示的ではなく、暗黙的に渡すのか
- コンパイラに任せることで以下のメリットが生まれる
  - ある種の証明として使うことができる
    - implicitな値を定義する際にdefを使うとimplicit parameterを使うことができる
  - 複雑な合成が必要な時にコードの本筋が埋もれない

implicit parameterのおまけ
目的
- 変更できないクラスにメンバを追加したい
- C#の拡張メソッドと同じモチベーション
- Rubyのモンキーパッチとの違いはimplicit val が存在しているスコープのみ有効な点
しかし今ではEnrich my libraryパターンが推奨されており、implicit conversionは積極的には使うべきではない