Fringeneer's Tech blog

Fringe81の開発者ブログ

Scala関西で発表&スポンサーします! #scala_ks

こんにちは、サーバサイドエンジニアの小紫(@petitviolet)です。
サマーインターンの季節となり、Scalaと設計でアツい夏を過ごしています。

Scalaといえば、来る2017/9/9(土)に大阪でScala関西が開催されます。

まだ参加枠には余裕があるようですので、お早めに!。

このScala関西には、弊社から2名が発表する予定となっています。
タイムテーブルには非常に魅力的なセッションが並んでおりますが、ご興味を持っていただけたら私たちのセッションもぜひ聞きに来て下さい!

発表内容

メタプログラミングScala

Cサブ会場2にて16:00-16:45で小紫が発表します。

Scalaにはマクロなどのメタプログラミング技法がたくさんあり、普段のプロダクト開発でお世話になっているライブラリやフレームワークの裏側では色々なところで使われています。
メタプログラミングを使ってどうやって機能を実現しているかが分かるようになれば、何かが起きた時にも迅速に対応できるようになるはずです。
そう思い、Scalametaを触ってみたら意外と簡単な面も発見できたので、その感覚をぜひ共有したいです。
セッションを通して、食わず嫌いしていた方でも触ってみようかなと思っていただけると嬉しいです。

発表概要は以下。

Scalaには強力な言語機能がありますが、それをより強力にするメタプログラミング。 それでも何となく難しそうなマクロを使うことに抵抗がある人も多いと思います。 scalametaが新しいメタプログラミングの主流となりそうな今、入門するのにいいチャンスです。 scalametaで出来ること、使い方を紹介します。

Ladder of CQRS+ES

Cサブ会場2にて17:00-17:45で豊島が発表します。

CQRS+ESは比較的まだ新しい概念かと思います。 断片的な情報は増えてきつつありますが、まとまった情報はまだまだ少なくあったとしてもとてもボリューミーだったりと、ついつい先送りしている、という人も多いのではないでしょうか(かくいう私もその一人です)。 登壇をきっかけに(自分を追い込み^^;)、そのエッセンス的な部分を共有したいと思っています。 Scalaというよりはアーキテクチャの話が中心なためScala初心者の方でも楽しんでもらえるかと思います。

公式の発表概要は以下。

CQRSおよびEvent Sourcingについて耳にする機会が増えてきましたが、まだまだ実践事例が豊富という状況ではないように感じています。 このセッションでは私が自社サービスを構築する上で実践した事例の紹介と一口にCQRS+ESと言っても実際はいくつかのレベル感があり比較的カジュアルなレベルから始めることも可能であることなどについて述べたいと思います。

スポンサーもします!

Fringe81として、Scala関西のSilverスポンサーとなっています。

東京以外の地域で開催されるイベントにスポンサーするのは弊社としては初めての取り組みとなります。

ちなみにScalaMatsuri2017では大名スポンサーとしてイベント運営に微力ながら応援しておりました。

少しずつScalaを使っている会社だと認知していただけると嬉しいです。

新サービスUniposに新言語elmを導入しました!

Fringe81エンジニアの関(@jshosomichi)です。主にフロントエンドの開発を担当しています。

先日、Fringe81は新規事業、Unipos(ユニポス)の正式版をリリースしまして、このサービスは我々が持つ発見/賞賛する文化をWebサービスとして実現し、強い組織を作っていくという、開発背景として思い入れの強いものになっています。

更に、正式版リリースまでの道のりの中で約一年間のプロト・α版・β版というリリースがあり、その過程で様々な技術的チャレンジを行ってきたという、別の視点での強い思い入れもあるということで、今後何度かに分けてその取組みを紹介できればなぁと思ったりしています。

さて、今回はそんなサービスのWebフロントエンド開発の大きな取り組みとして、タイトルにもありますelm導入について、紹介させていただければと。

f:id:fringeneer:20170725230600p:plain

チームの発展をめざして

導入を決定したのは2016年の9月の事、当時は別のサービスの開発を(React, Flux, TypeScript, immutable.js)といった構成でやっておりまして。Uniposについてはα版の開発が始まるか否かというタイミングでワタクシの参画も決まっていたので、β版あたりで新しい取り組みへのチャレンジができないかなーなどと考えていました。

上記構成でのWebアプリケーション開発でも一定の成果は出ており、開発チーム内での知見の共有もある程度進んでいたため、そのまま踏襲することも可能ではあったんですが、より生産性を高め、技術者のレベルを高めるためのチャレンジをして、チームとしての大きなジャンプアップを果たしたいという思いが強くありまして。

「どう作るか」に関しては自分で責任を負うことにして、デメリットがあったとしても、それを覆すことのできるメリットが出せそうであればチームの皆に強力を仰いでブッ込んでしまおう、といった観点でビッグなメリット探しをポイントに、
現状構成から見て、ざっくり①言語の発展、②アーキテクチャの発展という2面での考察を始めました。

elmの美点

当時導入していたTypeScriptについては、JSと比較すると、コンパイラによって、誤りの早期発見や、エディタ上でのコード補完が強力になる、といった恩恵を享受出来ていました。

一方で、型の設定が上手く行っていないと、エラーを検出できなかったり、言語仕様の早いアップデートのキャッチアップ等、メンテナンスのためのコストもそこそこに支払うという課題感を感じたりしていました。

elmを魅力的に感じた点は

  • 純粋関数型言語であり、常に式が値を返し、不変であり、参照透過性を確保出来る点
  • コンパクトな言語設計により、学習コストは記憶よりも思考に多くを払うことになる
  • elmアーキテクチャという優れた枠組みが実装されていることにより、アプリケーション基盤の構築コスト(ライブラリの組合せ・依存解決・バージョン管理)がグッと下がる。

などがあります。

なにより、いかにもアカデミックな方向性に向かいそうな出自の言語でありながら、目指している方向はもっとカジュアルなところで、楽しく学ぶことができ、子どもへのプログラミング教育にも使ってもらえるような言語にしていくという言語創設者のEvan氏のメッセージもとても刺さりました。

色々な言語やフレームワークの利用を模索しましたが、将来的に大きな広がりを見せる可能性と、言語自体の面白さ、選民思想ではなく大きな広がりに向かっていく方向性、どれもがビビッと来て、チームを強くし・共に成長していける技術はコレが最高だ!と感じました。

個人的にelmの今後に期待!なポイント

クリティカルな問題というのは正直ありませんでしたね。

主に表現力の部分が高まると良いなーと思う部分はありますが。下記のような事ができると個人的にはうれしいですね。

  • 型を抽象化したり、モジュールに関数の定義を義務化させるような制約をかける、といった機能の実装(いわゆるHaskellの型クラスというやつですね。話し合われてはいるようですが)
  • Range型のような、Int型ではあるのだけれども1〜10までしか受け付けないという型

導入意思決定から現在

始まってから5年(当時は4年)という若い言語であるという点や、プロダクト導入に踏み切っている企業は殆ど無いと思われる点が懸念ではありましたが、僕はそれを逆に面白いと思っていました。

幸いなことに、技術選定段階や、チームへの紹介での評判も良く、大きな問題があれば引き返すという意思決定も自分が担うことにして、導入を決定しました。

慎重に入れながら、少しずつ前進しては反省を繰り返し、アーキテクチャの細部や開発ポリシーをつめていき、現在ではUniposプロジェクトにおけるelmの稼働コード記述量は3万行近くになっています。

社内にelmを書くメンバーも5人ほどおり、みんなも沢山の新しい発見を得ることができ、徐々に生産性の高い開発技術として社内でも大きな存在感を見せるような認知になってきております。

ちなみに、メンバーへの教育コストはそれほどかけておりません。この手のシンタックスに慣れていない人には、これこれこうでね、とメカニズムを教えてあげればよく、 コードレビューも「イベントを表す『メッセージ』」と「状態を表す『モデル』」のレビューに矛盾や重複が無いことをチェックすれば拡張機能開発くらいであれば、根っこが腐るような事はほぼありません。

未来に向けて

9月には会社からの全面協力のもと、アメリカはセントルイスで行われるelm-conf USというカンファレンスに、オーディエンスとしてですが行くことになりました。

今後、何か会社としてelmという言語の発展に寄与するような活動もしていくことができればなー、というかやらねばなるまいと思っています。 その一環としてFringe81はElm Tokyo Meetup vol.4の会場として場の提供をさせていただき、私もトークセッションでお話させていただきます。

elm-tokyo.connpass.com

上記のイベントに是非ご参加いただければと思いますし、

なんかFringe81面白そうだなーと感じられたら採用・一緒に働いてみたーいの等のお話なども全力でお聞きします。

ElmもFringe81も盛り上げていきたいなー、 と切に願い、やるぞーと思う今日この頃でございます。

Typelevel Summitに参加してきました

こんにちは、@petitvioletです。
遅くなりましたが、ScalaDaysの翌日に開催されたTypelevel Summitにも参加したので、そちらについてのレポートです。

ScalaDaysの参加レポートはこち
fringeneer.hatenablog.com

typelevel.org

Typelevel summit

Typelevel.scalaにまつわるカンファレンスです。
ScalaDaysよりも技術的に難しい話が多かった印象で、そのせいか人数もかなり少なくなっていて70-80人くらい?の比較的小じんまりしたイベントでした。

f:id:fringeneer:20170608230013j:plain

Inviting everyone to the party

基調講演
資料
プログラミングパラダイムはたくさんある。
コミュニティや考え方など、人には色々なコンテキストがあり、それを尊重しよう、という話。

途中、Type Tetrisという単語が出てきてちょっと笑いが起きてました。
やっぱり型合わせでみんな苦労しているんだな、と。

Refined types for validated configurations

資料:Refined Types for Validated Configurations

Configurationはボイラープレートが多い上にバリデーションが難しく、RuntimeExceptionになってしまいがち。
それなのに何かミスがあると致命的な結果に繋がってしまうことが多いため、
ボイラープレートを削除しつつ安全にしたいという欲求が生まれ、
ライブラリを組み合わせて楽に安全にconfigurationする方法について話していました。

pureconfigで設定をちゃんとクラスで表現しつつ、refinedで値に対する制限を表現する、というイメージになりますね。

発表者のViktor氏が開発しているCirisも型安全にconfigurationが出来て便利そうでした。

Herding types with Scala macros

資料:Typelevel summit

AerospikeのScalaクライアントをmacroを使って実装した話でした。
TinkoffCreditSystems/aerospike-scala

shapelessのHListに対して適切な型のBinWrapperをmacroで生成するようになっており、型安全にデータを保存できるようになったそうです。

Monad Stacks

資料:MonadStacks.pdf

PlayでJsonを受け取ってユーザーを作成・保存してユーザー情報をJsonとして返す、という流れを実装するにあたって、
普通に実装するとFutureOptionの扱いもあり、そこそこのコード量になってしまう。

単にFuture[A]だけならfor式を使って簡潔に書けるが、Future[Option[A]]になってしまうと単純にfor式ではうまく書けなくなる。 Error情報を持つクラスをErratumとして定義しつつ、Future[Either[Erratum, A]]をどうやって扱うか、という話。

選択肢は以下を上げていました。

後半はこれらに対応するライブラリの紹介だったので、詳細は資料をご参照下さい。

Freestyle: A framework for purely functional FP Apps & Libs

47degreesのCTO。
frees-io/freestyleについて。

@freeをつけるだけでfree monadになるというイメージなもの。すごい…。 @freeをつけたalgebraと、それのinterpreterを実装するだけで良いというのは非常に楽で良いですね。

PlayやSlickとのintegrationも開発されてました。

stack safeになっており、大量にannotationを付けてもパフォーマンスの劣化も無いとのことです。

Lenses for the masses introducing Goggles

kenbot/goggles: Pleasant, yet principled Scala optics DSL

Monocleを強化してstring interpolatorとして利用できるようにしたものについて。

公式のサンプルから例を拝借すると、以下のようにgetter/setterを実行できる。
なかなか変態チックですね。

get"$myBakery.cakes*.toppings[0].cherries"
set"$myBakery.cakes*.toppings[0].cherries" := 7

setは内部的にはcase classのcopyを呼んでいるが、ネストしたcase classのcopyを意識せずに済む上に、*[0]でループ処理やindex指定できる、さらに?Optionなオペレータを提供していたりと非常に便利。

Mastering Typeclass Induction

資料: Mastering Typeclass Induction

Listを再帰的に型レベルで処理していく手法について。

val x: Named[(Int, (String, (Char, EOL)))] = ???
f(x)
// "int, string, char,"

簡単に言うとこの例のfをどのように実装するか、という話。 数学的な帰納法と型クラスを使って実現していました。

値について再帰的に処理するのではなくて、型そのものに対して再帰的に処理するインタプリター的なものを実装するという観点がなく、非常に新鮮でした。

Do it with (free?) arrows!

資料: Do it with (free?) arrows! (1))

WhatとHowを分離させる宣言的プログラミングの話から始まり、Applicative Functor, Monad, Arrowだとどう実現できるかという話でした。

Monadだと失敗ケースで畳み込んでしまって蓄積できないデメリットがあるが、Applicative Functorだと表現力が足りない。
そこでArrow、さらにChoiceを使うとそのようなニーズを完全に満たすことが出来るそうです。

やや難しいですが、使ってみるだけならそこまで難しくはないかもしれないですね。

感想

ScalaDaysが幅広いScala開発者を対象とした大規模なイベントだったのに対して、Typelevel Summitは関数型プログラミングな開発者に絞ったイベントだったので、人数が少ない分内容も濃くて非常に楽しかったです。
初心者お断りなトークを英語で聞いて理解が非常に怪しいので復習します…。

ちなみにランチタイムはビュッフェ形式で豪華な食事もあり、着席するスタイルでした。
テーブルはこんな感じ。 f:id:fringeneer:20170629105558j:plain

いつか海外カンファレンスでトーク出来るように頑張ります。

ScalaDays@コペンハーゲンに参加してきました!

Fringe81株式会社でエンジニアをやっている小紫(@petitviolet)です。
このたびFrigeneer(Fringe81のエンジニア)で技術ブログを開設しました。

記念すべき第一回目として、5/30 ~ 6/4で海外出張としてデンマークコペンハーゲンまではるばる行ってきた話をします。

f:id:fringeneer:20170608230008j:plain

  • 5/31~6/2がScalaDays

http://event.scaladays.org/scaladays-cph-2017/

  • 6/3がTypelevel Summit

まずはScalaDaysで聴いた発表についてのメモ、コメントです。 英語の理解が追いついていないところも多々あり、誤っている可能性もあります。

ScalaDays

f:id:fringeneer:20170608230009j:plain

Odersky先生のkeynoteから始まる3日間のイベントとなります。

What’s Different In Dotty

Odersky先生によるDotty講座。
今回の発表で初めて知ったのがtype lambdaとenumサポートでした。

type lambdaについてはこちらの論文に詳しく書いてあります。
Implementing Higher-Kinded Types in Dotty - dotty-hk.pdf

type Pair[A, B] = (A, B)

↑が↓のように書けるということっぽい。

type Pair = A => B => (A, B)

type projection(Hoge#Foo)が廃止されることによる影響でしょうか。

enumは今までsealed traitcase classcase objectでADTで表現してきたやつが言語としてサポートされるようになるということで嬉しいですね。
このenumを使うと、例えばOptionは以下のように表現できるらしいです。

enum Option[+T] {
  case Some[+T](value: T) // case classになる
  case None // case objectになる(パラメータを取らないため)
}

implicit functionとか型推論の強化とかもあってDottyに対する期待がどんどん上がっています。
早くproduction readyになって業務で使いたいところですね。

8 Akka Anti Pattern

資料: Scala Days Copenhagen - 8 Akka anti-patterns you’d better be aware of

Akkaを使う際の8つのアンチパターンについて。

  • Global mutable state
  • flat actor hierarchies
  • too many actor systems
  • Logging(the wrong way)
  • being out of touch with ther hardware
  • blocking
  • re-inventing akka tools
  • using java serialization

Akka使ったことあれば納得感はあるかなと思います。
Q&AでAkka-Agent使うのどう?っていう質問に対して聴衆の一人がdeprecatedだよ、って返してたのが驚きです。
知らなかった…。 便利そうだしどこかで使えるかなとか思ってましたが、deprecatedと明記してあるので使わないまま終わってしまいました。
Agents • Akka Documentation

Building code analysis tools at Twitter

シカゴでの発表資料:2017-04-21-SemanticToolingAtTwitter.pdf
Twitter社におけるコード解析ツールの話。

全体構成として、mono-repoにしてあってCIをやりやすくしているし、噂は間違っていて今もバリバリScala書いてるよ!という前提から始まりました。

scalametaのsemantic-api, semantic-dbやgoogle/kytheを使った例を紹介していました。

チェックできていませんでしたが、scala.metaの最新版でsemantic-apiが入っていたらしいです。
scalameta/1.8.0.md

Compiling like a boss

Triplequoteのお二人。 hydraというScala Compilerを使えばScalaコンパイルが速くなって最高!という内容。
マルチコアをフル活用してコンパイル速度を上げているようです。

とりあえず憶えておけば良いのはこの2つかと。

  • scala2.12は2.11より20%ほどcompile速くなっているよ
  • implicitの解決に時間かかるからワイルドカードimportやめよう

裏側はともあれコンパイル早くなるならチーム全体の生産性にも直結するので嬉しい話ですね。
sbt integrationとかcommand lineサポートとかもあって、とりあえずローカルで試せるようになったらもう少し追いかけます。

Adventures in Meta-Programming Macros vs Shapeless

Underscoreの人。
発表資料

ボイラープレートの削減やDSLの実装にはMacroとShapelessが使える。 davegurnell/macros-vs-shapeless: Slides and code samples on meta-programming techniques in Scala.

例としてインスタンスの自動生成やvalidationロジックにおけるフィールド名へのアクセスなどを通して、
それぞれのメリット・デメリットをまとめて紹介していました。

最後のまとめはこちら。

  • macros are good for syntactic stuff
  • shapeless is good for structural stuff

ボイラープレートの削減に対するアプローチの違いによって、どちらを採用するかを決められるようになりそうです。
どちらも便利だけど銀の弾丸ではないので注意しましょう。

ADTs for the win

47degreesの人。
資料: ADTs For The Win!
Algebraic Data Typeの話でした。

ドメインモデルもtupleで型として表現出来なくはないが、
case classとして実装することによって、その型のtupleに対して命名出来て網羅性も担保出来て型は便利。

Optionとかはfoldメソッドがあり、Someなら…とNoneなら…を簡潔に表現できるようになっています。
じゃあドメインモデルに対してもfoldを実装してみよう、という話で確かに便利そう。
パターンマッチよりもAPIとして実装の網羅性を強制出来るのが利点ですね。

以下のような実装イメージになりそうです。

sealed trait DatabaseResponse {
  def fold[A](fi: (Boolean, Int) => A, fe: String => A): A = ???
}
case class Invoice(paid: Boolean, price: Int) extends DatabaseResponse
case class ErrorMessage(description: String) extends DatabaseResponse

The best is yet to come State of Akka 2017

konrad氏。
資料: State of Akka 2017 - The best is yet to come

Akkaプロジェクトの総復習っぽいイメージの発表でした。
Scalaカンファレンスではありますが、Scala APIだけでなくてJava APIもしっかり作ってるよ、とのこと。

ざっくりまとめるとこうでしょうか。

あとはマルチデータセンターでAkkaを使うところがあるらしいが、それに対するサポートは今のところお手上げ?
どうしていいかわからないので、もっとユースケースを聞きたいらしいです。

懇親会

食事もアルコールも沢山出て、IntelliJやSAPなどが企業ブースを出してました。

f:id:fringeneer:20170608234150j:plain

Managing Consistency, State and Identity in Distributed Microservices

LightBendの人。

Microservicesは、独立したチームで独立したサイクルで開発できるものであり、自律的に協調する分散サービスと定義していました。

Microservicesにしておけば、各コンポーネントにおいて必要なデータのことだけ考えればよくなります。
そうなるとbounded context(境界付けられたコンテキスト), consistent boundaries(整合性境界)を考えなければいけないですが…

  • 世の中のシステムは意外と結果整合で問題ないようになっている。
  • さらに、Databaseのデータはlogのサブセットでしかない

という理由から、EventSourcingが解決策になるのでは、とつながっていきます。

たとえばショッピングカートを作るにあたって、途中で削除された商品のデータが欲しい、となった場合に
CRUDで現在の状態を保存するように実装していたらそのデータを抽出するのは不可能だが、ESなら簡単に実現できるなど、ESの利点を説明していました。

Reification and type-safety in a CQRS world

CQRS界隈だとフレームワークを作るなと言われているが、Scala開発者向けに作ってしまった人だそうです。
Fun.CQRS

CommandとEventを扱うDSLを型安全に作るためのフレームワーク
ブログに詳しく書いてあります。
Building a CQRS / ES Framework (part 1)

使い方としては、
domainモデルのもつメソッドをCommandとして切り出し、その振る舞いの結果をEventとして定義する、というのが基本になるようです。

type parameterとtype projectionとpath dependent typesの3パターンで実装してみて、それぞれのメリットデメリットについて説明していました。
型合わせで大変そう…。

Uniting Church & State OO vs FP

underscoreの人。
noelwelsh/church-and-state: Unifying Church and State

  • Classical OO
    • operatorの追加は容易
      • メソッドを追加するだけ
    • actionの追加が難しい
      • BigDecimalで計算するように変更する、とか?
  • Classic FP
    • Data型で振る舞いを定義して、interpreterで実装する
    • actionの追加は容易
    • oepratorの追加が難しい

whatとhowを分離したい。
そのためにはFPの力が必要だが、FPだと中間データ型が必要になる分、OOよりもパフォーマンス観点でコストが高い、という問題があります。

その解決のために、ChurchEncodingとtype classを使って実現する!というストーリーでした。
(church-encodingがわからず、この辺から置いて行かれた)

Beyond the Build Tool

Tapadの人。

sbtを再評価する内容。
sbtは、ただのツールじゃなくて、ツールの土台になる可能性があるものとのこと。

sbtに対するレベル感は以下のように段階があるそうです。

初期段階はscalaを書いていれば誰しもクリアしているとは思いますが、プラグインを使ってみたりタスク書いてみるところから、
少しずつやれる範囲を広げていきましょう。

公開されているsbt pluginはたくさんあって、ここで見れます。
sbt Reference Manual — Community Plugins

よく使うやつ(?)はこの辺りだそう。

  • sbt-dependency-graph
  • sbt-assembly
  • sbt-release
  • sbt-docker
  • sbt-twirl
  • sbt-buildinfo, sbt-doge

使うのに慣れてきたら作る側に回り、そのときにはBestPracticeを読みましょう。
sbt Reference Manual — Plugins Best Practices

所感

発表とか懇親会を通して世界のScala状況みたいなのを何となく感じることが出来ました。
Odersky先生からDottyの話やLightbendからのAkkaの話など、海外カンファレンスだと作者にあたる人がばんばん出てきて良いですね。

大雑把にはMicroservicesやCQRSなどのシステムアーキテクチャのような話、Akkaやsbtなどのツール・ライブラリの使い方、FPな話が主流でしたが、 日本で盛り上がっているDDDについては恐らく発表が無かったのが意外でした。

コペンハーゲンの人もカンファレンスの参加者も皆とても優しく、楽しく過ごすことが出来ましたが、英語力が足りずに思うようなコミュニケーションを取れないこともあったので、Scalaだけでなくて英語も頑張りたいなと思います。