技術をかじる猫

適当に気になった技術や言語、思ったこと考えた事など。

今更ScalaMatsuri2014でとったメモをさらす

当時の自分のメモ書きそのまま。修正なし。

ScalaMatsuti 2014

場所:ameba さん

サイバーエージェントさん:CATechKids

OP

子供(小学生)位を対象に、プログラミングの基礎を3日くらいかけてやる。 TechKidsCamp というイベントがそれ。 TechKidsSchool (継続的)にきっちりプログラミングを教育するそうな。

小学生がアプリ作るねん。すげー アイディアを形にする力を教え込むんだとか。

会場アンケートで、Scaler のおよそ半分が Scala を業務で使ってるらしい。

基調講演

Evolution of Scala

Scala 10 歳に到達。 SML 的なものを考えていたけど、パターンマッチを導入したパターンマッチはXMLのためだ 他に Java の関数型への拡張、ラムダ式を巡ってかなり勉強した JavaGenerics いれるのにも尽力した 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

クラスタリングを想定した Web フレームワーク

  • 機能が多い
  • 簡単に作れる
  • パフォーマンスがいい
  • Scalable

static ファイルの速度が nginx 同等だったり、routing をアノテーションで書く、i18、CORS対応とか 公式ページでガイドがある

2014 でV3が出た

Netty がフロント Xirum に渡して Action/FutureAction/ActorAction に渡す。 FutureAction/ActorAction がAkka上で動く。 Xitrum レイヤーで AkkaCluster を使い、並列化できるとの事。

基本的には main 文で Xitrum のコードを1行読めば、後はライブラリ的に 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

  • Spark 上で実行する SQL
  • LINQ っぽく書ける
  • 実行最適化ができる

以下を含む

「パース>アナライズ>ロジカルプラン>最適化>物理実行計画>実行」 「パース>アナライズ>ロジカルプラン>最適化」は 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

コンセプトは Scala On Rails

シンプルなクラスベース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 じゃなくても使えるよ。

MEMO: SCCT Scalaカバレッジ

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 での Web 開発問題
  • なんでScala
  • 開発フロー
  • まとめ

Perl

殆どPerlでサービスが書かれてる。

  • 「Hacker と画家」とかいう本で静的型をdisってた。
  • CPAN が当時便利だった
  • 当時シンタックスが少ないとか、ダックタイプできるとかあった

で、まぁ10年してみたら色々複雑な世界になって来た。 そこで、問題になるのがコードの質問題。 で、静的型が欲しくなった。

なんで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 って殆ど同じコードじゃね!? まぁいいや

データインフラの話をする。

TwitterScala に入れ籠んでます。 Rails でパッチが凄い事になってた。もう grep が友達という状況。 しかも性能で良くクジラが死んで 2009/11/20 にバルス祭りで死んだw -> Rails では生き残れない

2013 年とうとうクジラが出なくなった。 2013/8/2 のバルスには今度こそ(18万/sec のバルス)耐えた。

2009 年 Hadoop + Pig でどうにか処理してた 巨大なUDF とパッチを宛てまくった。

Scalding に移行しようとしてる

Scalding ?

Map=Reduce を作る為のライブラリ。 ※あくまでライブラリです。環境ではありません HadoopAPIラッパーになってる。

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 の話

http://shigemk2.hatenablog.com/entry/2014/09/06/Silk%E3%81%A7%E7%B7%A8%E3%82%80%E3%83%87%E3%83%BC%E3%82%BF%E3%83%95%E3%83%AD%E3%83%BC_%23ScalaMatsuri

コンパイルしてから実行結果を得るのではなく、コードを書きながらどう結果を得ることができるか、これを解決するために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 に4月に移行した。 どっちもClass/OOPで生産性高い。 関数型って事で、λとか色々書けるし、どっちも書いてて楽しい。

Ruby / Scala は目指す所は同じでも、アプローチがちゃうねん

Ruby の case class 作ろうとすると、Struct を new して継承する…new する!? new というコマンドで型定義(Scala で言う所の Class)というオブジェクトを返す