Scala関西Summit 2015 メモ #scala_ks

<a href="http://summit.scala-kansai.org/">Scala関西 Summit 2015 - 関西初のScala大規模イベント8/1(土)開催</a>summit.scala-kansai.org

はてなブックマーク in Scala

Scalaとの関わり（まだ4ヶ月）
もともと型理論やってた => Ocamlやってた
はてなブックマーク10周年 => 10周年で作り直し！Scalaで！
- コードベース肥大化、変更が困難
- 開発中ベース
構成 => 前段perl 後段 scala コアははてなブックマーク以外からも使う
なんで使いたいか
- 変更の少ない重要部分は堅牢にしたい
- 使用実績がある
- Perlとの心中を避ける
- 個人的には
  - 関数型でないとゆるさん
  - 強い静的型言語出ないと
  - 型推論ないと……
Perlは
- 頻繁に変更があっても楽
- デザイナもHTMLテンプレート使うので
これまで
- 第２世代 => Perl版RoR => 学習コスト高い自由がきかない
- 第３世代 => 薄いフレームワーク
新コア
- Scalaで薄いフレームワーク
- Web : Scalatra => 簡素で良い、
- APISchema: 簡単なDSLで定義（まだ使ってない）
- DB: Slick => 非同期DBアクセスしたい
  - Slick-jdbcextension
- 独自: DBインスタンス管理
DDD
- 旧ブックマークでもやってた
- アプリケーションサービス
- ドメインサービス
- ドメインモデル
- 今失敗してる
  - ユビキタス言語がない
  - 方針が徹底されていない
- 内政のAR的ORマッパ
- perlの限界
- 実践ドメイン駆動設計でやってる
- Scalaでのポイントもある
- リポジトリはインタフェース
- ドメインに実装上の都合を持ち込まない
- 悩んだ点
  - 依存性注入をどうするか => CaKe Pattern
  - has-a関係 N+1問題 => 関係モナド
  - トランザクションどこで貼る？ => いったん極小な範囲で（インフラ層）、結果整合性
- Cake Pattern
  - taritを入れ子にしておくなど（あとで調べる）
- N+1問題
  - JOINはしたくないときもある
  - 関係先を引いてくる => 元の要素と対応付けたい場合に面倒（
  - 関係モナド

flyway-play

Playのマイグレーションをもっと便利にする
scala-csv
Database migration は難しい
DBでなんでこまるか
- Mutable
- Like global variable/state
- 手動で管理されてたり、本番が正だったり（なんとかしたい）
開発者がいろいろ困る
- コードの変更とスキーマの変更が一緒のはずなのに、やりかたわからない
- スキーマ変わってたり
- テストと本番で違う！
- 明文化されてなかったりして難しい
Gaol
- 開発者とDB管理者で作業できる
- マイグレーションの変更履歴がおえる
flyway
- マイグレーションツール, Java製、依存するライブラリが特に無い
- SQLかJavaベースのマイグレーションができる
- いろいろなDBのサポートあり
- Command => migrate, clean, repair, info, validate, baseline
SQL base migration
Java based migration
- データの移行とかをする場合の奥の手
WEB+DB press 84 に記事がある
flyway-play
- flyway module for play 2.4
- play-flyway is available for <= 2.3
play-evolutions => いろいろあってflyway-play
アプリへの組み込み方
- Java APIがある
- すでにあるデータを設定したい場合、baselineを使う
slick-codegenと相性良くない => play appが動くときflyway-playが動く、コード生成はコンパイル時
DEMO
- SQLベースのマイグレーションとJavaベースのマイグレーションを混在できる
- Webインタフェースがあって、SQLが見られる
- 複数のデータベースに対して実行できる？

FitureとServlet

スレッドローカルが存在する世界
- スレッドモデル => reqを受けてres返すスレッド
- JavaEE7はSJR-236でコンポーネント管理と非同期処理を規定
- Scala Dynamic Barria
Future
- Futureを産んだ元スレッドの値をFuture側のスレッドから簡単にアクセスできる
- mutability
Scalatraのreq/resスレッドローカル、Futureからさわれない
Sknnyでのアプローチ
- skinny-engine
- stable request
- no more dynamic scope
  - Contextをimplicit parameterとして渡す
  - コンパイルエラーで確実に潰す
  - new async trait

チャットワーク scala化プロジェクトの一年

ビジネスが加速するほうがチャットワーク
Scalaで刷新する理由
- もともと社内向けツール
- 大規模なサービスになる予定はなかった
- ユーザの急増に対応しないといけない => 現状辛い
- 新機能追加のすピードアップ、刷新したい！
- 言語選定の合宿 => ブログ参照
- どうしてScala?
  - 静的型付言語
  - 簡潔な記述ができる
  - AWS使える
Scala化プロジェクト開始
- 最初のゴール
  - メンテナンス＆パフォーマンスの解決
  - 新iPhoneアプリのAPI
0から設計実装
- ４年間で追加された多くの機能、使用をみたす必要がある
- DDD
  - 複雑な仕様と立ち向かうための道具
  - 日々のコミュニケーションの効率化
  - コミュニケーションで使う言葉とコードを結び付ける
どのようにプロジェクトを進めたか
- ペアプロ => 知識共有、業務知識共有、IDE機能、デバッグコツ
- 今のScala化プロジェクト　=> 全員別々の場所にいる
- チームとコードが成長していく
  - 設計に関する議論も活発化
- 個人としては
  - ペアプロのあと振り返り
  - コップ本にかじりつく
  - Scala関数型デザイン＆プログラミングの読書会
Scalaエンジニアを集める
- Scala専業：二人 => もっと開発ペースあげたい
- エンジニアを集める => 社内から集める、社外から集める
- Scala初心者詐欺がいる
- Scalaに興味ある人（経験不問）を採用する
進捗どうですか？
- リリースのめどがようやく立ってきた……かな？
Scala採用してよかったか？
- Chatworkとしてはどうか => 会社アピールする機会が増えた、ブログがバズる
- 個人：関数型プログラミングの考え方、Scalaエンジニアは食えそう、PHPを捨てたと言われる
- 超えなければいけない壁
  - JVMの運用小さくリリースしながらトラブルを経験しながら覚える
  - プロジェクトの規模やスキル面によるフレームワークの選定
  - scala採用するきっかけ
  - sbtと上手にお付き合いする必要がある

Refactoring with Functional Programming Style

Scalaコードレビューサービス
- GitHub（クローン）上でのOnlineコードレビューサービス
- Slackなどでリアルタイムに質問できる
- 典型パターンがあるので、それからFPStyleをどう適用するか
Listのコード
- でかいリスト
- mapとかを使うとmutableがなくなる => 2回全件ループしてる => FPstyleはだめなんじゃ……
- Monoid => 集合と２項演算の組み合わせ引数と戻り値の型が同じ
  - 整数と足し算
  - Listと連結
- Monoidではない
  - 整数と割り算
  - 整数と引き算
- Foldable 畳み込みができる型クラス(Javaのインタフェースみたいなもの、後付ができる)
- もしListの要素がMonoidであれば畳み込みができる
- foldMapメソッド
- Monoidは合成ができる
- 要素の順序さえ同じであれば、どこからでも畳み込みができる
- 平衡畳み込みができる
- 巨大な集合に対する状態をもった複雑なループもMonoid+foldMapで簡潔に書ける
今のところ20万（月額）

LT大会

Scala.js
- 社内でScala.jsの話 => 聞きたい人は入社して
- AltJs
- 使えるのか？
  - Scalaでかいて、ブラウザで動く
  - JS使える人にはちょっと微妙
    - JSのエコシステムが使えない
    - sbtに寄せる必要がある
    - npm + sbt => 現実解だけど、理想ではない
    - Scala.js standalone
突然のScalaプロジェクト
- 楽しい！
- Scalaわからん人のコードではないと言われる
- Rubyの感覚で書ける
- Scala難しいところある　型パラメータの境界とかいろいろ
- おすすめの本を確認しよう
- モナドはよくわからない
- 逆引きレシピを読む
- 方に守らた作業が勉強になる
  - フィールドの方を変える
現場で使えるSkinny Framework + Gradle
- Why skinny => Skinny Frameworkに入れるだけ
- Servletコンテナ上で動く
- 導入コストが小さい
- Why Gradle? => sbtつらい
- Gradleのscala プラグイン、warプラグインを適用
JavaサービスをScalaにリプレイス
- やっていいよといってもらえるための用意
  - Scalaの本を騎乗でアピール
  - 日報で書く
- 社内ツール、バッチや作りきり案件
- なんかってもしらんで => 「責任とるんやったらやってええで」
- 品質、メンバー教育
  - 実戦経験 BetterJava => エラー処理
- リファクタリングが楽しい => モチベーション大事
- パフォーマンス

パネルトーク

Scalaのか同案件
- はてな:はてなブックマーク、Mackrel
- ヌーラボ:backlog APIサーバ、チャットサービス、redamineのデータをbacklogに取り込むインポータ
- Chatwork: Chatworkのリプレイス中
- シナジーマーケティング: 自然言語処理をバックグラウンドにしたサービス
なぜScalaを採用したのか
- 規模が大きくなってきて、型に守られた安心感をえたい
- スピード感とメンテナンスのバランス
- Javaよりももう少しモダンにできるScalaを採用
- Javaの重厚さを嫌った結果。JVMで動く言語がよかった。
- 実行速度
- Javaのコミュニティは結構しっかりしてる
- 型はドキュメント
Scalaを使っていて最高に気持ちいい瞬間
- 型がぴったりあてはまったとき
- 型合わせゲームはたのしい
- 継続的にアドレナリンが出ている
Scalaを使うときに障害になったこと（ブレイクスルーになったこと）
- Javaのエコシステムが使えるのは結構メリット => すんなり入った
- そもそも大きな壁だと思わなかった
- 会社的にはJavaでやっていたので、Play Frameworkが出てたのが大きかった
- 社内の信頼関係（あいつにはまかせて大丈夫）
- 覚悟が必要
- やり始めたときは先行者メリットがあると判断した
Scalaを業務で使うのは難しくない？
- 人のバックグラウンドにもよる
- 役に立つ部分から導入すれば問題ないのではないか
- これを読めば！というのがあればとは思う
- 新しい概念はそりゃ難しいが、それほど心配するものでもないと思う
これからもScalaを使い続けるか？
- これからも使う
- 80%ぐらいの可能性で使う（PHPも好きなので）
- 使い続けるかな、ちっさいコードでもScalaで書いていきたい
- 使い続ける