当時の自分のメモ書きそのまま。修正なし。
ScalaMatsuti 2014
場所：ameba さん
サイバーエージェントさん：CATechKids
OP
子供（小学生）位を対象に、プログラミングの基礎を３日くらいかけてやる。 TechKidsCamp というイベントがそれ。 TechKidsSchool (継続的)にきっちりプログラミングを教育するそうな。
小学生がアプリ作るねん。すげー アイディアを形にする力を教え込むんだとか。
会場アンケートで、Scaler のおよそ半分が Scala を業務で使ってるらしい。
基調講演
Evolution of Scala
Scala 10 歳に到達。 SML 的なものを考えていたけど、パターンマッチを導入したパターンマッチはXMLのためだ 他に Java の関数型への拡張、ラムダ式を巡ってかなり勉強した Java に Generics いれるのにも尽力した Generics 以外は、Pizza の機能は評判が悪かった 関数型のペトリネット join の実装です。 それを使った最小言語がFunnel サイトはまだ生きてる筈。 Funnel は汎用的であった。 最小言語はコアの計算レイヤの上に等位構文を乗せたもの エンコーディングは駄目だった。暗黙的な知識が必要になってしまった、 なので、もっと実用的な言語を作りたかった
OO と FP の組み合わせがいいのが分かったし、ライブラリでいろいろできる様にした 並列処理はライブラリに抽出した ライブラリにしてよかったよ コアの calculus と言語の依存性を緩めた
XMLリテラル？クレイジーだ！ Object やクラスモデルが加えられた Asterux って知ってる？ XMLリテラルもこのときに追加された
OO 主流はは可変的なデータをカプセルかするものだった Web はイミュータぶるかつ再起的な物だった Web はFPに向いてる、XMLリテラルはその為のものだ FP の目玉機能として XML リテラルを入れた建前として Web Service のための言語という為だ
本音はちょっと違う OOPとFPを組み合わせたら汎用的になると思った でも両陣営から怒りを買った まぁ、当時は冗談だったけど、今は大分実話になった
本来は Java に機能を付け加えるだけのつもりだったが、Pizza :Java に突っ込めなかった事から、 Scala を作って色々突っ込んだ Pizza は関数とOOがごちゃごちゃして分かりづらい この差をどうにかするために、Java からは持ち込まなかった物も多い いろんな演算子をメソッドに置き換えたりもした
1.0 本当は 0.1 と呼ぶべきだった。 結構バグがあったし、内部利用にとどまった 2/0 で ; の推論、implicit trait を入れて状況が一変した 皆セミコロンが嫌いだったんだ。 空の引数省略も突っ込んだ、引数要らないのになんて () なんて必要なんだ
def と val はそう変わらない。見た目も変わらないようにした。 統一アクセス理論の為だ
でも () の排除は大変だった。 下手すると、結果じゃなくて関数ポインタが返って来た 実装によって動的に () を突っ込む事にしたんだ
DSL は諸刃。 ユーザやコミュニティが増える一方で、独自社会になりすぎる。 変態的なものを書かれすぎると、却って言語の評価に悪影響が出る。 Scala は安全より柔軟をとる 静的型の高度な型システムは柔軟性の為にある FP とはここは考えが異なる null 死ね
言語機能を厳選する意図がある
A 会場：Sbt: past and future
project/build.properties に sbt.version=0.13.5 と叩いて sbt 起動
...てか普通にSBTの基礎講座？
「~」入れると、ソースの更新拾って勝手に動くとの事
key という概念がある task:keyname でキーで指定したオプション処理を実行できる、例は test:compile など
13.5 で AutoPlugins が入った。
13.6
- MavenCentralをHTTPSで取って来れる様にした
- Consolidated resolution ライブラリ依存性が同一の物がある場合、内部グラフを作って再ビルドー参照解決の速度問題を解決する
- Evicition warning 複数バージョンのライブラリを突っ込んだ時にバージョン依存を推論して警告を出す
- Unsolved 足りないJarを推論して提案してくる
- SNAPSHOT handling SNAPSHOT のバージョンが変わらなくても、更新があれば取り直す
数週間後位に 13.6 だしたいそうな Activator は新規ユーザに使いやすいようにする為のもの、sbt をいきなり使わせるとヤバい事になるからね…
B会場：Xitrum
- 機能が多い
- 簡単に作れる
- パフォーマンスがいい
- Scalable
static ファイルの速度が nginx 同等だったり、routing をアノテーションで書く、i18、CORS対応とか 公式ページでガイドがある
2014 でV3が出た
Netty がフロント Xirum に渡して Action/FutureAction/ActorAction に渡す。 FutureAction/ActorAction がAkka上で動く。 Xitrum レイヤーで AkkaCluster を使い、並列化できるとの事。
基本的には main 文で Xitrum のコードを１行読めば、後はライブラリ的に Action を読んで処理する 素敵な事に、アノテーションさえ入ってれば、class でも jar でもプロジェクトのクラスパスにあれば読み込む。
印象は簡潔に書ける Spring3 ?
API ドキュメントは Swagger で呼び出される。
メモ：sock.js
これ 1 アクション 1 テンプレを徹底してるけど…1 アクション複数テンプレは？ これルーティングパスが競合したらどう処理するんだろ？ コンテンツネゴシエーションはどう実装する？アノテ？それとも複数テンプレを自前実装？ヘルパあり？ -> 未実装
Xitrum のクラスパス上に class 突っ込むと勝手に拾って、ルーティングパスに突っ込む
LT
- http://scalikejdbc.org/ メモ、SQL の勉強を真面目にしたければ書けば？って感じ。Squeryl か ScalaActiveRecord でいいよ。
- InteliJ のライブテンプレに groovy 使える。帰りに買おう。
B: SparkSQL
Spark - Cataliyst でデータ解析とかやってる。
ApacheSpark
Hadoop に変わる分散コンピューティング処理。 Scala 製の Map-Reduce 実装。 物によってはワンライナーで処理できる。
QuickStart の公式サンプル
gist の ueshin で弄るとサンプルが出る
SparkSQL
以下を含む
「パース＞アナライズ＞ロジカルプラン＞最適化＞物理実行計画＞実行」 「パース＞アナライズ＞ロジカルプラン＞最適化」は Catalyst モジュールが仕上げる。
関係台数に乗せれる内容ならこれで最適化とかできる。
物がScalaなので、実行計画を直接構築して動かすとか、DSL っぽく書くとかできる。
Row DataType
Long, Int, Short, Byte, Float, Double, Decimal String, Bimary Boolean, Array, Map など大体使える
Tree Rule
ルールを分解して TreeNode に落として操作する transform 系の操作を使うことで、実行順序操作などをできる。
LogicalOperator
TableJoin => Filter => Project の実行操作
Expressions
処理の最小単位要素データ。.NET の ExpressionTree 系に近い
Optimazation
NULL プロパゲーション：NULL になりそうな物は初期のうちにNULLにしてしまう。 Constant フォールド：定数の計算は先に計算してしまう
Bool 式最適化、IF 式の簡略化 Filter の省略できる物は省略する フィルタが多重でかかるなら、AND に変換する フィルタ実行タイミングの最適化 JOIN する前にフィルタしてJOIN データ料を減らす 不要なカラムをロードしないなど
SQLコア
物理実行する部分。 inmemppry columun support
Interesting issues
ROLLUP/CUBE/GroupingSet Pluggable interface for shuffle
Solid and Sustainable Development in Scala
バージョンアップのときに困らない様にするにはどうするか？
Memo: SkinnyFramework
ScalikeJDBC がもっともシンプルである意味で分かりやすい、しかも相当安定性が高い。 Anorm みたいで単純だしね。
select.from(attendee as a).where.eq()
Skinny Framework
シンプルなクラスベースOOP
既にかなりポピュラー 破壊的メソッドの回避とかも含む
Java8
case class がジャゔぁよかマシ 高階関数 静的性 コンパニオンによる分離
Immutabillity
mutable の状態調整やばいとかそういう話
Trait CHAOS
Mixin 機能はいいんだけど、カオスになりがち override とか階蹴るが分かりづらかったりする。
MEMO: sbt-scalariform
SQL の他に DB にアクセスする DSL はいらない。 抽象化しすぎると、チームで理解しづらい。 SQLを隠し過ぎたDSLは何がどう動いてるのか分からなくなる。 Skinny ORM は ScalikeJDBC の上に乗ってる。Rails Active Record から影響。ボイラープレイトを避ける。Skinny じゃなくても使えるよ。
SBT をハックすんな。 メジャーバージョンアップしにくいんだ。Play なんぞいい例だ。 長期的なメンテができなくなるから止めるべきなんだ SBTを改造するとその後のバージョン追従が非常に大変になるためそれは避けるべき、と。実際Skinny TaskRunnerはSBT Pluginにせずに実現していると。
たとえば難しくするのを避ける。 ・オレオレプラグイン作りにハマりすぎてハマったり ・なんでも書いたり
Skinny TaskRunner そこで Skinny TaskRunner。Rake のようなシンプルなタスクランナー。書きやすいし、Scala や sbt のバージョンに影響されない。 SBT を用いない rake みたいなランナーだ。 タスクを Scala の普通の関数として書ける。メンテしやすい。
gems には糞な床があるが、Scala も似た様な状況にある Scala のエコシステムはまだ小さい。バイナリ互換性も問題。ライブラリ作者が燃え尽きるとメンテされない。フォークするのも大変。Java の資産を中で使うのも一案。
入門しやすいのか？ Scala プロジェクトに新人は入れづらく無い？難易度高いしね sbt がカスタムされてると余計にそうなる Rails っぽくできれば皆ついていけるよ 非同期なんて本当に今必要なのか？ いやいや要らねえだろ！
Scala プロジェクトを始めるのは簡単ですか？何でも sbt を使わず Grunt/Gulp を使ったり。Rails のような規約はチームワークに良い。非同期性は本当に必要ですか？DSL が混乱のもとになってませんか？
非同期版scalikejdbcは中で使ってるライブラリがまだ枯れてないし実績もあんまりないので、自分で直す気合がある人しか使うべきじゃない
B:Scala use cases at Hatena
Twitter: mechairoi
Perl
殆どPerlでサービスが書かれてる。
で、まぁ１０年してみたら色々複雑な世界になって来た。 そこで、問題になるのがコードの質問題。 で、静的型が欲しくなった。
なんでScala？
発端：新しいサービス Mackerel を作る事になった。 負荷状況、死活等色々できる。アラートメールとかね 初の B2B 開発！ その言語を選んだ背景
- 静的型であること[必須]
- case class とかある
- 型推論
- パターンマッチ
- 型インターフェース
あと
- ライブラリが多い
- 実績
メンバースキル的に Scala 使いたいとか触ったとかの人もいた。 Haskel とか名前が出たんだけど、他に書きたい人がいなかった。
開発
Playframework 2.2 で開発開始。 デザイナには Play がしんどいらしい。ので、AngulerJS テンプレ一本に変更中 2.3.1 まで乗り換えるのにそんなに苦労しなかったそうな
Perl と違って Immutable イイネ。 気をつけてる事
- 例外が出そうな物は避ける
- 型はきちんと書く。曖昧になるのは許さない
Routing にインジェクトして独自型変換を routes に埋め込んだ -> できるらしい
開発フロートか
- IDE は ASE とそんな変わらん。
- git もそんな変わらんね
- Task マネージメントは github の issues/pullrequest で運用
- 買いはる方法は Scrum の変則
- Jenkins/CI
MEMO: git-pr-release (auto-gen pull request)
自動配備がネックになってるっぽいね
まとめ
静的型の安心感が本当にいい。
- リファクタしやすい
- レビューも楽
欠点
質疑
GO はGenerics無いのが不便か？結構 GO のがシンプルで好きだという声も…
A6: Scalding, Storm & Summingbird
Twitter: Yoshimasa Niwa @Niw
Scaler じゃない。データ解析のプロでもない。 普段は iOS アプリを作ってる。
Swift <-> Scala って殆ど同じコードじゃね！？ まぁいいや
データインフラの話をする。
Twitter は Scala に入れ籠んでます。 Rails でパッチが凄い事になってた。もう grep が友達という状況。 しかも性能で良くクジラが死んで 2009/11/20 にバルス祭りで死んだw -> Rails では生き残れない
2013 年とうとうクジラが出なくなった。 2013/8/2 のバルスには今度こそ(18万/sec のバルス)耐えた。
2009 年 Hadoop + Pig でどうにか処理してた 巨大なUDF とパッチを宛てまくった。
Scalding に移行しようとしてる
Scalding ?
Map=Reduce を作る為のライブラリ。 ※あくまでライブラリです。環境ではありません Hadoop のAPIラッパーになってる。
https://github.com/twitter/scalding
Scalding is a Scala library that makes it easy to specify Hadoop MapReduce jobs. Scalding is built on top of Cascading, a Java library that abstracts away low-level Hadoop details. Scalding is comparable to Pig, but offers tight integration with Scala, bringing advantages of Scala to your MapReduce jobs.
Scalding API はかなり簡単に書ける。 しかも Typesafe API もあるねん。
で、結局バルスはいつ来る？->わかんねぇ
Storm
Hadoop に近いリアルタイム処理系のプラットフォーム。 Closure 製。Java Wrapper まではある。 Zookeeper が落ちると落ちるけど、基本的に信頼性が高い、障害耐性が強い。 で、データエラーがあったらそこで処理を止める。データの抜けとか処理漏れはない。
ただし、Scala から呼ぶ IF とか無いので、Scala で書くならラッパーが要る。
Summingbird
内部向けで作ってるので、使い勝手が微妙だけど
ライブラリ、データ処理系のプラットフォームを抽象化する。 Scalding や Storm どっちでも動く。 複数のプラットフォームで動いたのを aggregate して結果を出せる。
Producer(抽象化して書く) Platform(Scalding/Stormなど) Plan(実行計画)
にして流す処理になる。 どう動くか？
Hadoop と Storm を両方動かして、時間区切りに「Batch」という単位にする。 で、Batch 番号で Hadoop ではここまで処理したー ＋ Storm でここまで処理したー = 最新の結果だよね
ただまぁ、セットアップが大変ではある。
質疑
Twitter は凄くOSSあるけど Scala Version 中々あがらないよね。 -> 手が回らない
オダスキー先生：バージョンアップでネックになったとか、なってる所は共有公開して欲しいな。 -> ごめん、iOS がメインだから分からないんだ
SAT : Scalab
神戸大学：宋 剛秀
http://kix.istc.kobe-u.ac.jp/~soh/scarab/
This web page details Scarab system which is a prototyping tool for developing SAT-based systems. It provides a rich constraint modeling language on Scala and enables a programmer to rapidly specify problems and to experiment with different modelings.
やべ英語で、スライド理解するの諦めた。
http://kix.istc.kobe-u.ac.jp/~soh/scarab/talk-jp.pdf
スライドの日本語版見っけた 翻訳者泣かせの計算機科学セッション
SAT ソルバで数独を解く方法 http://d.hatena.ne.jp/ku-ma-me/20080108/p1
B: Silk の話
コンパイルしてから実行結果を得るのではなく、コードを書きながらどう結果を得ることができるか、これを解決するためにSilkが開発されたと。 SilkとはつまりDAGを記述するためのライブラリで、どう処理するかの実行部分はプラットフォームによる Sparkとは競合関係 http://db-event.jpn.org/deim2014/final/proceedings/D3-6.pdf http://wifo5-03.informatik.uni-mannheim.de/bizer/silk/
Scala の MACRO
BizReaxh Takeko Shimamoto
オダスキー先生からなくなるかも？って言われてる機能 ともかく作るのは難しい
Macro って？
コードを生成するコード。 IDE のマクロとも違う。 2.10+ の experimental で入った。 コンパイラが読み込んで実行する処理系。
それまでは
マクロはそうした物よりはシンプルに書ける。 より必要なときだけ動くとか、実行効率がいい。
Macro 使うとどーなるねん？
import scala.language.experimental.macros
を入れる必要があり、マクロを定義するコードと、マクロを利用するコードは別々に用意(コンパイル)しなければならない。
def macro, type, annotation がある。
def マクロは、コードを置き換える処理。 例えば
logger.debug(s"Hoge")
を
if(isDebugEnable) logger.debug(s"Hoge")
に置き換える等。
http://labs.enrapt.jp/2013/02/scala3.html http://tototoshi.hatenablog.com/entry/20121220/1356011884
http://eed3si9n.com/ja/scala-macros-getting-started
Specs2 でも使ってる
a matchA[Cat].name("Tom")
とか書くと、name プロパティが "Tom" であるという様な書き方をする事ができる。
scala.reflect.macro.Context
2.11 から Blackbox / Whitebox に分かれて、2.12 で Whitebox がなくなる http://blog.pab-tech.net/2013/12/16/blackwhitecontext.html
実装仕様がコンパイラを作る人向けの実装になってる。
今後
今後、2.12 では本体としてはバグの改善位しかしません。 そのかわり scala.meta パッケージとしてライブラリレベルでかなり改善される予定。
もうそろそろ public preview が出る！
今まで Terms/Types/Simbols/Modifiers/... 等色々あったのが、Trees という型に統合される。
Slick とか Play とかでかなり使われてる（コード生成） 静的型チェック等で使う等。
コミュニティレベルで結構使われてる。
- OOS でかなり使われてる
- より実用的、安全なプログラムに書き変わってる
- まだまだ進化中
From Ruby to scala
@todestink
MAVERICK で広告システム作ってる DSP 広告システム作ってる。
Scala で早く書く方法とか言わない。真面目に書けば早くなる。 コンパイル時間にも触れない。 どっちがいいとかも言わない。
Ruby -> Scala に４月に移行した。 どっちもClass/OOPで生産性高い。 関数型って事で、λとか色々書けるし、どっちも書いてて楽しい。
Ruby / Scala は目指す所は同じでも、アプローチがちゃうねん
Ruby の case class 作ろうとすると、Struct を new して継承する…new する！？ new というコマンドで型定義(Scala で言う所の Class)というオブジェクトを返す
