読者です 読者をやめる 読者になる 読者になる

Scala関西Summit 2015 メモ #scala_ks

summit.scala-kansai.org

はてなブックマーク in Scala

  • Scalaとの関わり(まだ4ヶ月)
  • もともと型理論やってた => Ocamlやってた
  • はてなブックマーク10周年 => 10周年で作り直し!Scalaで!
    • コードベース肥大化、変更が困難
    • 開発中ベース
  • 構成 => 前段perl 後段 scala コアははてなブックマーク以外からも使う
  • なんで使いたいか
    • 変更の少ない重要部分は堅牢にしたい
    • 使用実績がある
    • Perlとの心中を避ける
    • 個人的には
      • 関数型でないとゆるさん
      • 強い静的型言語出ないと
      • 型推論ないと……
  • Perl
    • 頻繁に変更があっても楽
    • デザイナもHTMLテンプレート使うので
  • これまで
  • 新コア
    • 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
  • flyway
  • 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

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化プロジェクト開始
    • 最初のゴール
  • 0から設計実装
    • 4年間で追加された多くの機能、使用をみたす必要がある
    • 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 => 集合と2項演算の組み合わせ 引数と戻り値の型が同じ
      • 整数と足し算
      • 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
  • JavaサービスをScalaにリプレイス
    • やっていいよといってもらえるための用意
      • Scalaの本を騎乗でアピール
      • 日報で書く
    • 社内ツール、バッチや作りきり案件
    • なんかってもしらんで => 「責任とるんやったらやってええで」
    • 品質、メンバー教育
      • 実戦経験 BetterJava => エラー処理
    • リファクタリングが楽しい => モチベーション大事
    • パフォーマンス

パネルトーク

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

Scala逆引きレシピ (PROGRAMMER’S RECiPE)

Scala逆引きレシピ (PROGRAMMER’S RECiPE)

Scala逆引きレシピ

Scala逆引きレシピ

とりあえず面白かった。細かい話はまた後。

追記

書きました。