前回 の続きです。
私が聴講したセッションのみのレポートとなります。
全セッションのスライドはこちらにまとめられています。
ビデオも後日アップロードされる予定とのことです。
3日目
カンファレンス最終日。
この日はホテルで自転車をレンタルし、会場までサイクリングで移動しました。
ベルリンは自転車人口が多く、どんな通りにも自転車専用レーンが整備されています。
道中には歴史的な建造物や緑地が数多くあり、随所でドイツの文化を体感することができました。
- 国会議事堂
[09:00] キーノート: Chad Fowler – @chadfowler
スピーカーの Chad Fowler 氏は、Immutable Infrastructure という言葉を世に広めた1ことでも有名な方です。
印象的なスライドとBGMを駆使した素晴らしいプレゼンテーションに引き込まれました。
話題としては Scala に限った話ではありませんが、キーノートらしい内容だったと思います。
- レガシーとは何か
- 多くのエンジニアが持つ偏見: ひどい、嫌い、変化を恐れる頭の硬いマネージャー
- 一方で、動けばいい、枯れている方が安心、安定しているという意見も
- 音楽、文学、建築物、ファッション、絵画 ……
今日でも通用する『レガシー』は皆、素晴らしいもの - レガシーを悪い意味で捉えてはいけない
- 良いソフトウェアになるには 10年かかる
- にも関わらず、ほとんどのソフトウェアは 5年以内に死ぬ
- 20年以上生き延びているソフトウェア: TCP/IP, DNS, Linux, Emacs, grep, …
- Scala は今年で10年。良いソフトウェアの仲間入りができた (笑)
- 『レガシー』なソフトウェアを作るために
- 最初の一歩は作ること
- 価値を提供し続け、替えのきかない存在になる2
- 生き残るのは、小さな部品とシステム
- 人間こそがシステム
- 細胞のように常に殺し、入れ替えることで、部品は正しく機能する
- インタフェースは極力シンプルに
- イミュータブル・デプロイ
- 既存のノードでは一切のソフトウェア更新を行ってはいけない、という考え方
- 最初から異なる環境を想定する
- 例: 特定のプログラミング言語に依存した設計をしない
- 故障(失敗/障害)を前提とする
- 全てを監視し、自律的なサービスを
- Chaos Monkey を使って様々な障害シナリオをランダムに引き起こす
- 最悪のシナリオを知れば、何も恐れることはない
[10:00] Building a DBMS in Scala or how types can turn a SQL interpreter into a SQL compiler
- スピーカー: Tiark Rompf – @tiarkrompf
- スライド (coming soon)
Scala で高性能の DBMS を作れるか、という話。
スピーカーは、EPFL内のOracleの研究施設で働いているという方。
- 一般化(拡張性・汎用性の向上)と特殊化(応答性能向上)はトレードオフの関係
- それでも、コンパイル時に計算したり、特殊化のコードを生成することで汎用的な最適化を実現できる
- LegoBase という RDBMS を Scala で開発中
- LMS: Lightweight Modular Staging フレームワークの話
- ステージング: 順序や使用頻度によってプログラムを置いておくステージを変える
- クエリの処理順序の最適化: Filter 処理を再帰に実行するなど
- TPC-H のベンチマークでも良好な成績
- LMS: Lightweight Modular Staging フレームワークの話
- データベース以外のプロジェクトも、ローレベルなCコードに対抗すべく取り組んでいる
- Play 2.4 も Reactive Stream ベースの実装に書き換えて、レイテンシが改善しているとのこと
[11:00] Building a Reactive Application
- スピーカー: Duncan DeVore – @ironfish
- スライド
-
スピーカーは Viridity Energy という企業の方
- 電力の大口顧客に対して、プロファイルを受け取って分析・効率化を提案している
- VPower というクラウドベースのアプリケーションの話
- 旧来のバージョンは、デプロイ・レスポンス性能・スケーラビリティなどに問題があった
- ドメイン駆動 + Reactive な設計で作り直した
- Scala + Akka + Spray.io
- CQRS: Command/Query Responsibility Segregation
- コマンドとクエリの分離
- CRUD モデルは苦痛
- Append-only アーキテクチャは良い。簡単に分散できてロックを大幅に削減できる
- 整合性を保つ仕組みの説明
- ドメイン駆動: 1行のコンフィグで、ビジネスロジックを記述できるようにした
- 読み込み用と書き込み用のマイクロサービスを異なるJVM上で稼働
- それぞれ数十個のアクターが動いている
- Reactive なショッピングカートの実装例
- 今年の夏に、Manning から本を出版する予定
- Building Reactive Applications by Duncan DeVore and Sean Walsh
[12:00] ランチ
前日と同じビュッフェスタイルでしたが、メニューは若干変わっていました。
[13:00] Futures and Async: When to Use Which?
- スピーカー: Philipp Haller – @philippkhaller
- スライド
Future と Async の違いについて。きちんと理解しておきたいところです。
- Future について
- 指定した秒数待機してから結果を返すコードを例に具体的に説明
- 非同期でないAPIが必要になったら、scala.concurrent.blocking を使う
- Promise について
- Promise から future を作る
- 必要になった場合にのみ使えばよい
- Async について
- パイプラインとして使用する例
- ボクシングの回数が減り、性能が向上するケースもある
- Production-ready (実業務に耐えうる品質である)
- Async を使う動機
- Future ベースのコードをシンプルに書き直せる
- ただし現在のコードに十分満足しているなら、無理に書き直す必要はない
[14:00] specs2 2.3 whirlwind tour
- スピーカー: Eric Torreborre – @etorreborre
- スピーカー
スピーカーは Specs2 の作者。Specs2 の現状と将来像についてのセッションです。
- 設計思想の根底にあるのは、実世界とコードの橋渡し
- Specs2 の機能と使い方を一通り説明
- sbt, IntelliJ IDEA からテストを実行する例
- デフォルトでテストは並列処理
- テストコードの分離性をチェックする助けにもなる
- Isolation と Selection、タグを付ける
- コマンドライン引数の解釈
- ScalaCheck との統合
- データテーブル形式の記法
- その他の多種多様な機能
- Specs2 3.0 の予定
- 様々なバグ修正
- オンライン Specification
- よりライブラリらしく
- コントリビュートを期待
- Eclipse プラグイン
- HTMLレポーティング
- Selenium と連動した Web テスティング
- Q&A
- マッチャーなど、同じ意味のものに様々な書き方がある。
(===,must_==,must beEqualToなど)
なぜこのようにしているのか?- できるからできる! ルールは自分たちで決めてください (意訳)
- マッチャーなど、同じ意味のものに様々な書き方がある。
早めに終わったのでメイン会場に行くと、こちらのセッションがまだ続いていました。
Scala: The First Ten Years
- スピーカー
- Jon Pretty – @propensive
- Miles Sabin – @milessabin
- その他、Scala レジェンドの皆様
- スライド
- 特別ムービー
- コード
会場爆笑のムービーが流れた後は撮影会のような様相に。
[15:00] Effective APIs
- スピーカー: Josh Suereth – @jsuereth
- スライド (coming soon)
本カンファレンスの司会も務めていた Joshua Suereth氏。満を持しての登場です。
API開発のベストプラクティスを紹介してくれました。
- 良いAPIの基本
- 型・名前は重要
- ガイドなしでもユーザが学習できるように、それら自身が説明的であるとよい
- エラーハンドリング
- リカバリ可能か
- ユーザが気にする必要があるか
- ScalaDoc、チュートリアルを書く
- 型・名前は重要
- バイナリ互換を保つのは大変
- やってはいけないこと
- case class のコンストラクタの変更
- メソッドに引数を追加
- トレイトに具体メンバを追加
- クラス/メンバ/引数の削除
- テクニック
- 抽象クラスの利用
- パッケージレベルのプライベート化
- 独自の unapply 関数を定義して、case class を隠蔽
- やってはいけないこと
- 拡張性を持たせる
- 公開APIは最小限に留める
- 引数のデフォルトは避け、オーバーロードを
- トレイトは pure virtual に
- final class を適切に利用
- 既存のメソッドを変えるのではなく、新しいメソッドを追加する
- Q&A
- バイナリ互換性が保たれているかどうかを確認する方法はあるか
- ある。セマンティック・バージョニングによって付けられる番号の変化を確認すればよい。
- バイナリ互換性が保たれているかどうかを確認する方法はあるか
[16:00] Scala in Numbers – The Ecosystem Census
- スピーカー: Johannes Rudolph – @virtualvoid
- スライド
数字で見る Scala ライブラリ。
GitHub 内の Scala ライブラリを様々な観点でランキングしてみました、というコーナー。
終始和やかな雰囲気で進んでいきました。
- 識別子の名前
- ローカル val でよく使われている名前 =>
result - ローカル var でよく使われている名前 =>
i - var が多く使われているライブラリ => rapture-io
- 引数でよく使われている名前 =>
f - 変数名の長さ => scalaz は90% の変数名が 2文字以下 (会場爆笑)
- ローカル val でよく使われている名前 =>
- ライブラリの利用実態
- 最も多く使われているメソッド =>
Boolean.&& - 最も多く使われているコレクションのメソッド =>
TraversableLike.map- これを一番多く使っているライブラリは scalikejdbc-interpolation
- 最も多く使われている predef =>
augmentString - 最も多く定義されている predef 拡張 =>
any2ArrowAssoc ->
- 最も多く使われているメソッド =>
- 暗黙的な利用
- 最も多く使われている暗黙的パラメータ =>
_root_.scala.Function1 - 最も多く使われている暗黙的パラメータ(Scalaライブラリ) =>
ClassTag- Functor など同じものが複数回出ているのは、表示上 prefix を省いているから
- 最も多く使われている暗黙的パラメータ =>
- 検索ツールの紹介、デモ
- 構成要素とクローラー
- 会場からは、deprecated にすべきかどうかの判断材料として便利そう、という意見も
- さいごに
- 最も多く記号演算子を定義しているライブラリ => 圧巻の scalaz
- ユニコードの演算子を定義しているライブラリ => やっぱり scalaz
[17:00] Sparkle: Reactive streams to the browser with scala and d3
スピーカーは Nest、Google、Typesafe といった名だたる企業を渡り歩くエンジニア。
Scala と D3 を使ってデータ可視化のライブラリを作った、という話です。
- 動機
- ブラウザ上で大規模データを扱ってインタラクティブな操作(ズームなど)をしたい
- Scala, JavaScript でデータの変換処理をしたい
- Sparkle は様々な用途に、誰でも利用可能
- ビッグデータも素早く可視化
- Sparkle Data Protocol: WebSocket 対応プロトコルを独自で作成
- コンポーネントの説明
- Loaders
- Fast Storage: Casandra ベースのカラム志向 インメモリDB
- API
- Transform
- Stream
- Display
- デモ
- ダッシュボード
- repl の操作で正弦波を描画
スライドの方にはおまけとして、『Scala の良いところ』や『スタートアップ企業となぜ相性が良いのか』についても記述がありました。
[18:00] クロージング
最後のセッション。
メイン会場で、Typesafe社の方たちへのインタビューが行われました。
- Scala 2.12 の目玉機能は?
- Java8対応
- 邪悪にならないように、Scalaライクに。小さく、速くを目指している
- Scala 2.13, Scala 3 では、バイナリ互換用の移行ツールを作る予定
- Scala はオープンなコミュニティ。誰でもコントリビュートできます!
こうして熱狂冷めやらぬままカンファレンスは閉幕。
私自身も、非常に有意義な体験を得られました。
スピーカー・スタッフ・Scala Days 2014 に貢献してくださった全ての方に感謝します。
おわり