市ヶ谷Geek★Nightで「Scalaによるタイプセーフなフロントエンド開発」という発表をしました

普段フロントエンド開発は若者に丸投げしているバックエンドおじさんですが、ここのところScala Warriorを開発するためにScala.jsを触っていたということもあり、お声がけいただいてScala.jsの紹介をさせていただきました。

ichigayageek.connpass.com

発表資料はこちらです。

www.slideshare.net

結論としてはありがちですが、フロントエンドまで全てをScala.jsで書くのではなく、APIサーバへのアクセスや複数APIのアグリゲーション、フロント用に加工する処理などをラップしたライブラリをサーバサイドのエンジニアが提供するために利用し、フロントからはそれを呼ぶだけにするという使い方がよいのではないかと思います。

ところで会場からの質問でScala.jsでコンパイルしたJavaScriptをインポート/エクスポートできるのか?といご質問があり、その場では「できない」と回答してしまったのですが、実は今年の10月にリリースされたばかりのScala.js 0.6.13からCommonJS形式でのインポート/エクスポートがサポートされていました。

www.scala-js.org

build.sbtに以下の設定を行っておくと@JSExportアノテーションでエクスポートしたクラスやオブジェクトが利用可能なCommonJSモジュールにパッケージングすることができます。

scalaJSModuleKind := ModuleKind.CommonJSModule

たとえばこんなクラスをScala.jsでコンパイルします。

import scala.scalajs.js
import js.annotation._

@ScalaJSDefined
@JSExport("HelloWorld")
class HelloWorld extends js.Object {
  def sayHello(name: String): String = s"Hello ${name}!"
}

するとJavaScriptからは以下のようにして使用することができます。

var test = require("./test-fastopt.js")

var helloWorld = new test.HelloWorld();
console.log(helloWorld.sayHello("Scala.js"));

逆に@JSImportアノテーションを使うとScala.jsでCommonJSモジュールを使うことができます。

import scala.scalajs.js
import js.annotation._

@js.native
@JSImport("./test-fastopt.js", "HelloWorld")
class HelloWorld extends js.Object {
  def sayHello(name: String): String = js.native
}

Scala.jsでコンパイルしたJavaScriptをCommonJSモジュールとしてエクスポートすることができるようになったことでScala.jsを既存のJavaScriptのエコシステムに組み込むことが可能になり、サーバサイドエンジニアが提供するライブラリをフロントから使用するという分担もスムーズに連携できるようになりますね。Scala.jsの活用の幅はより広がってきていると言えそうです!

Scala.js is awesome!!

GitBucket 4.6をリリースしました

Scalaで実装されたオープンソースのGitサーバ、GitBucket 4.6をリリースしました。

https://github.com/takezoe/gitbucket/releases/tag/4.6

リポジトリのフォークを禁止するオプション

リポジトリの設定でフォークを禁止できるようになりました。

f:id:takezoe:20161023025446p:plain

WikiページにHistoryボタンを追加

これまでHistoryボタンはWikiページの編集画面にしか表示されていませんでしたが、参照画面にも表示されるようになりました。

f:id:takezoe:20161023025551p:plain

Gitリポジトリのリダイレクト

JenkinsなどGitHub前提の外部ツールとの連携をやりやすくするためにGitHub風URLでのGitリポジトリへのHTTPアクセスをリダイレクトするようになりました。

http://localhost:8080/user1/gitbucket.git

上記のURLは以下にリダイレクトされます。

http://localhost:8080/git/user1/gitbucket.git

Get-Content APIの改善

Get-Content APIはこれまでディレクトリしかサポートされていませんでしたが、ファイルにも対応しました。

  • API呼び出し:
$ curl http://localhost:8080/api/v3/repos/user1/gitbucket/contents/project/build.properties
  • レスポンス
{
  "type":"file",
  "name":"build.properties",
  "content":"c2J0LnZlcnNpb249MC4xMy4xMgo=",
  "encoding":"base64"
}

また、カスタムメディアタイプもサポートしています。リクエスト時にAcceptヘッダを指定することでレスポンスのデータ型を選択することができます。Acceptヘッダが指定されていない場合はBase64エンコードされたコンテンツを含むJSONを返します。

  • 生データを要求する場合:
$ curl http://localhost:8080/api/v3/repos/user1/gitbucket/contents/project/build.properties \
-H "Accept: application/vnd.github.v3.raw"
  • HTMLを要求する場合:
$ curl http://localhost:8080/api/v3/repos/user1/gitbucket/contents/project/build.properties \
-H "Accept: application/vnd.github.v3.html"

グループのメンバー一覧で管理者を表示

グループのMembersタブのメンバー一覧で、誰がグループの管理者かわかるよう管理者にはマークを表示するようにしました。

f:id:takezoe:20161029151447p:plain

この他にも様々な改善やバグフィックスを行っています。詳細についてはIssueの一覧をご覧ください。

ScalaでタイプセーフにCSSを記述できるScalaCSSを使ってみる

Scala Warriorではユーザが入力したコードを実行する目的でScala.jsを使っているのですが、せっかくScala.jsを使っているのでフロントエンドもできるだけScalaで書いてみようと思い、ScalatagsやScalaCSSなどを試しています。今日はScalaCSSについて紹介してみたいと思います。サンプルコードはScalaCSSのドキュメントから持ってきています。

github.com

ScalaCSSはScalaのコードからCSSを生成するためのライブラリで、CSSをタイプセーフに記述・参照できたり、Scalaコードで動的にスタイルを定義できたりといった便利な機能があります。Scala.jsにも対応しており、大きく分けでスタンドアロンモードとインラインモードの2通りの使い方があります。

スタンドアロンモード

スタンドアロンモードはこんな感じで記述します。

import scalacss.Defaults._

object MyStyles extends StyleSheet.Standalone {
  import dsl._

  "div.std" - (
    margin(12 px, auto),
    textAlign.left,
    cursor.pointer,

    &.hover -
      cursor.zoomIn,

    media.not.handheld.landscape.maxWidth(640 px) -
      width(400 px),

    &("span") -
      color.red
  )

  "h1".firstChild -
    fontWeight.bold

  for (i <- 0 to 3)
    s".indent-$i" -
      paddingLeft(i * 2.ex)
}

通常の外部CSSファイルの代わりに使う感じですね。Scalaコードを記述できるので繰り返しや条件分岐などを使って動的にスタイルを定義することも可能です。定義したCSSは以下のようにして出力することができます。

println(MyStyles.render)

インラインモード

これに対してインラインモードの場合は以下のような感じで定義します。

import scalacss.Defaults._

object MyStyles extends StyleSheet.Inline {
  import dsl._

  val common = mixin(
    backgroundColor.green
  )

  val outer = style(
    common, // Applying our mixin
    margin(12 px, auto),
    textAlign.left,
    cursor.pointer,

    &.hover(
      cursor.zoomIn
    ),

    media.not.handheld.landscape.maxWidth(640 px)(
      width(400 px)
    )
  )

  /** Style requiring an Int when applied. */
  val indent =
    styleF.int(0 to 3)(i => styleS(
      paddingLeft(i * 2.ex)
    ))

  /** Style hooking into Bootstrap. */
  val button = style(
    addClassNames("btn", "btn-default")
  )
}

定義したCSSスタンドアロンモードと同じく以下のようにして出力できます。

println(MyStyles.render)

また、以下のようにしてHTMLタグのclass属性に指定する値を取得することができます。これを使ってclass属性を出力しておくことでクラス名の記述ミスを防いだり、リファクタリング時などに使用箇所を容易に特定することができます。

MyStyles.outer.htmlClass     // Returns "MyStyles-outer"
MyStyles.indent(1).htmlClass // Returns "MyStyles-indent-1"
MyStyles.indent(2).htmlClass // Returns "MyStyles-indent-2"
MyStyles.button.htmlClass    // Returns "btn btn-default"

ScalaCSSの便利機能

Scalaコードならではの便利機能がいろいろあります。たとえばSCSSのmixinのようなスタイルの使い回しは以下のように記述できます。

val button = style(margin(8 px, auto), ...)
val userTitle = style(marginLeft(4 ex), ...)

val userButton = style(button, userTitle, ...)

合成した場合にスタイルの定義が重複している場合は以下のように警告を出力することができるようです。

[CSS WARNING] .MyStyles-navbar -- {margin-left: 6px} conflicts with {margin: 12px}
[CSS WARNING] .MyStyles-button -- {cursor: zoom-in} conflicts with {cursor: pointer}

また、他のCSSフレームワークと組み合わせて使用する場合などは以下のようにしてScalaCSSのインラインモードで定義するスタイルにclass属性の値を追加しておくことができます。こうしておくとhtmlClassで出力する値に追加したクラス名も含まれるようになります。

val button = style(
  addClassNames("btn", "btn-default"), // Bootstrap classes
  textAlign.center                     // Optional customisation
)

個人的にはsbt-webで定義したスタイルを外部CSSファイルに出力してくれるようなsbtプラグインがあるといいかもと思いました。

まとめ

ScalaCSSはScalaCSSを記述するDSLとしてはそれなりに使いやすいライブラリです。

が、フロントエンドのツールチェーンに組み込めなかったり、そもそもフロントエンジニアがScalaを書くのか?といった問題があり、現実的には一般的な開発体制ではなかなか使いにくいのではないかと思います。Scala.jsにしても(そもそもScala.js自体使うのかという問題はさておき)、フロントエンドの開発に使うというよりは、サーバサイドのエンジニアがフロントエンジニアにインターフェースを提供するために使うのがベストプラクティスと言われるようになってきています。

そういうことも考えるとScalaCSSに限らずScalaのフロントエンドソリューションは(GitBucketやScala Warriorのように)少人数のScalaプログラマでサーバサイドからフロントエンドまで開発している特殊なプロジェクト以外では使うモチベーションを見出すのが難しいかもしれません。

ULTRA Beer Bashを開催しました

去る10月14日(金)弊社の主催でULTRA Beer Bashというイベントを開催しました。

f:id:takezoe:20161016023637p:plain

Web界隈のCTOさんたちがパネルディスカッションを行うトラックと、最新の技術動向のプレゼンテーションを行うテクニカルトラックの2トラック構成のイベントだったのですが、テクニカルトラックのアレンジを自分の方で担当させていただきました。準備時間も短かったのですがスピーカーの皆様にご協力いただきフロントエンドから機械学習、インフラ、DDDそしてエンジニアのキャリア論まで素晴らしいセッションを揃えることができました。

当日はイベント内容のSNSでの拡散はNGというアナウンスがされていたのですが、テクニカルトラックに関しては通常の技術イベントと同じくSNSでの拡散OKということにしておけばよかったかなと思います。せっかくの魅力的なセッションがご参加いただいた方以外に拡散しないのはもったいないのでこのエントリで各セッションの内容を簡単にまとめておきたいと思います。

普通のWeb開発者が押さえておきたいJavaScriptの現在と未来

まずはサイボウズ開発本部長 佐藤鉄平さん(@teppeis)によるJavaScriptの現在と未来についてのセッションです。

ECMAScript 2015はモダンブラウザでは90%以上サポートされているし、IEでもBabelを使うことでほぼ問題ないレベルで動作させることができるので積極的に使っていくべきとのことでした。

また、フロントエンドの動きが早すぎるという課題については、フロントエンド界隈は最新技術に飛びつくカウボーイが目立つものの、実際のパラダイムシフトは3〜4年ごとくらいに起きており、そんなに早いサイクルではないという話が印象的でした。

とはいえ多くのツールやフレームワークが乱立している状況ではあるので技術選定が難しいということは変わりなさそうです。対策として「信頼できる人に話を聞く」「心を落ち着ける」などをあげられていましたw

Forward Universal WebApps

続いてもNode.js日本ユーザ会会長古川さん(@yosuke_furukawa)によるフロントエンドのセッションで、Universal(Isomorphic)なWebアプリケーションのアーキテクチャに関するお話でした。こちらのセッションはスライドを公開していただいています。

クライアント側で行っているバックエンド的な処理をBackend For Frontend(BFF)というレイヤに分離する、そしてこの層にNode.jsを用いることでフロントエンドと一部の処理を共用できるなどのメリットあるのでいいよ!とのことでした。

ただ、以前@teppeisさんのFrontend Meetupでの「SPAには覚悟が必要」という発表が話題を呼びましたが、やはりフロントエンド界隈はまだ未知の部分が多く、こういった新しいアーキテクチャを採用するには覚悟が必要なのは間違いなさそうです。しかし、だからといって諦めるのではなく、よりよいアプリケーションを作るために覚悟を決めて取り組んでいくという決意を表明されていました。

会長の覚悟をしかと拝見させていただいたセッションでした。

なお、私は覚悟がないのでVanilla JSとjQueryで生きていこうとの思いを新たにしました。

Software Engineering in SRE @ Mercari

フロントエンドの話題から一転してメルカリのbokkoさん(@cubicdaiya)によるメルカリさんのインフラおよびSREチームの業務に関するセッションです。

世界展開を行っているメルカリさんのインフラ構成ももちろんですが、個人的に特に興味深かったのはSREチームの日常業務や制度に関する部分でした。

最近話題のSREとは、運用だけでなくミドルウェアの開発やインフラの自動化などのソフトウェア開発も担うポジションで、稼働時間の50%以上は開発に費やすべきとされているそうです。とはいえ、システムの障害対応などは最優先事項です。メルカリさんのSREチームでは約一週間交代で障害対応の当番制が義務付けられているそうです。

当番の方は行動が制限されたり、生活面でのストレスなども発生するため、代休がついたり、日当が出るなど制度面でフォローしているそうです。さらに障害対応の可用性を保つため朝は当番の方は時差出勤するといった工夫もされているそうです。

サービスのインフラを安定稼動させるために技術面だけでなく人間系の運用もしっかりされているのだなという点が印象的でした。

機械学習は何であって何でないのか 〜その基本からディープラーニングまでGunosyの最新事例を添えて〜

グノシー久保さん(@beatinaniwa)の機械学習に関するセッションです。

機械学習ディープラーニングについて初心者にもわかりやすいよう説明されていました。グノシーさんでの事例も交えつつ、ルールベースで十分な場合も多いので機械学習の前に検討するべき、機械学習を導入する際はコストパフォーマンスを考え用法・用量に注意しましょう、という現実的なお話をされていました。

グノシーさんでは年齢の推定にディープラーニングを使用することで既存の手法より20ptも精度が向上し、これによる事業貢献も大きく、ディープラーニングの成功事例としてご紹介いただきました。

ITエンジニアならば本を書いて稼ごう!

ガラッと視点を変えて技術評論社の池本さん(@XR230)によるエンジニアのキャリア論に関するセッションです。

池本さんは書籍や雑誌の編集者さんの立場から多くのエンジニアとのお付き合いがあり、中でも成功されている方のキャリアについてご紹介いただきました。「プロのためのLinuxシステム構築・運用技術」などの著書で有名な中井さんのキャリアは

  • 予備校講師時代に校内のWindows PCをすべてLinuxに置き換えてしまったのが目に止まってIBMに転職
  • Linuxの本を書いたら売れてRedHatに転職
  • 機械学習の本を書いたら売れてGoogleに転職

という常人にはまったく真似のできないものでしたがw 「勉強し続ける」「学んだことを自分のものにする」「時間の使い方が大事」といった言葉についてはどれも胸に突き刺さる思いでした。

少し時間が余ったので質問タイムも取っていただいたのですが、出版社さんに声をかけてもらうには?という質問に対して最近ではブログを書くよりも勉強会やイベントでの登壇とスライドの公開が効果的というTipsを教えていただきました。本や記事を書いてみたいと思っている方は試してみてはいかがでしょうか。

Scala/Akkaによるドメイン駆動設計とリアクティブシステムの統合について

最後はチャットワークの加藤さん(@j5ik2o)によるAkka、DDD、Reactiveについてのセッションでした。

リアクティブなシステムを作る上でのAkkaのアドバンテージを力説されていました。AkkaはJVM上でアクターモデルを利用できるという意味で独自性があり、様々な用途に応用できる汎用的なツールキットだと思います。海外では良い書籍も出ていますのでもっと興味を持ってくださる方が増えるといいなと思います。

例によってかなりアルコールを投入済みの状態での登壇で、スライドも80枚という大作の中から重要なトピックをピックアップしてお話しいただくという形でしたので、もっと時間を取ってじっくりお話しをお聞きできればと思いましたw

おわりに

自分はずっとテクニカルトラックにいたのでパネルトラックの様子はわかりませんでしたが、こちらも他ではなかなか聞けない話だったようです。平日の昼間からビールを飲むという不謹慎なイベントでしたし、テーマも雑多だったので参加しづらいところもあったかもしれませんが、多くの方にお越しいただきありがとうございました。

また、無理なお願いをさせていただいたにも関わらず快くお引き受けいただいたスピーカーの皆様にも感謝の気持ちでいっぱいです。本当にありがとうございました。

はてな × BizReach合同Scala勉強会を開催しました!

Scala関西 Summit2016の翌日、京都のはてなさんオフィスに伺わせていただき弊社とはてなさんの合同Scala勉強会を開催しました。

f:id:takezoe:20161012172624j:plain

今回はクローズドな勉強会ということで普段あまり外には出せないようなリアルな悩みなどもご相談させていただいたのですが、当日の内容を可能な範囲でまとめてみたいと思います。

Scalaの利用状況について

はてなさんでScalaを採用しているのは3プロジェクト、社内でScalaを書けるエンジニアは10人ほど、フレームワークはPlay + SlickもしくはScalatra + Slickとのことですが、最近のプロジェクトではSlickはDSLを使わず生SQLを書いているそうです。WebフレームワークはFinchも検討されたそうなのですが、生産性に問題があるという判断で採用には至らなかったとのことでした。

弊社でScalaを使っているのは2プロジェクトですが、それぞれのプロジェクトの規模ははてなさんより大きめで、社内でScalaを書けるエンジニアは30人ほどです。フレームワークは基本的にPlay + Slickを使っていますが一部ではScalikeJDBCも使い始めています。

また、はてなさんではPerlはもちろんのこと、小さなサブシステムであればGoで書くという選択肢もあり、ScalaはDDDがやりやすい抽象度の高い言語として採用されているとのことで、この点についてはJVM言語をコアコンピタンス(一部にはRailsを使っているプロジェクトもありますが)としている弊社のスタンスとは少し異なるものでした。

開発環境について

両社ともに開発環境はMacBook Proがメインのようです。IDEIntelliJメインであること、一部にEmacsvimで開発している人がいるのも同じでしたw

Scalaコンパイル速度について、はてなさんでは以下のように様々な工夫をされているそうです。

  • sbtのプロジェクトをマルチプロジェクト化
  • コンパイルが遅くなるライブラリは使わない
  • implicitの探索範囲を限定するためワイルドカードでのインポートはメソッド内に限定する

弊社ではマイクロサービス化によって1プロジェクトをコンパクトにしたり、一部のサービスではマルチプロジェクト化を進めていたりしますが、ライブラリやコーディングにおけるルールまでは定めていません。コンパイル速度を気にしてコードを書くとScalaの言語としてのパワーがスポイルされてしまう部分もあると思うのでなかなか悩ましいところです。

また、普段はインクリメンタルコンパイルコンパイル範囲を限定することでそれなりのテンポで作業できていても、ブランチ切り替えの際に依存関係の更新やフルビルドをしなくてはならないケースはかなりきついです。弊社では、大きなプロジェクトを触っているチームではブランチ毎にリポジトリをクローンすることでなるべくフルビルドをしなくても済む形で作業しているメンバーもいます。

なお、弊社はJavaからScalaという流れだったのであまり気になりませんでしたが、はてなさんではPerlからScalaという流れだったので「デプロイが気軽にできなくなった」という点も違いとしてあげられていました。

Scalaのコードスタイルについて

はてなさんではScalazなどの関数型ライブラリは使わないようにしているそうです。弊社でもScalazは使っているものの、頻繁に利用するのは一部の機能に限られているので必要なものだけ自作して使うほうがいいのかも、という気がしています。

また、弊社ではメンバー間のScala力の差などにより、コードレビューが特定の人に集中してしまったりということがあります。また、レビューも表層的なレビューになってしまったり、正直なところテストもあまり書けていなかったりするのですが、はてなさんはPerlのチームも含め昔からテストを書いたりレビューをしっかりやる文化が根付いているとのことでした。

もちろんいたずらに完璧を求めるのではなく、明らかに修正するべきコードでも他に優先すべきことがあったり、直す労力が見合わない場合はリファクタリングを後回しにしたり、より簡単な方法で逃げるという判断をされているそうなのですが、このあたりは人によって閾値が違うと軋轢を生んでしまう可能性もあるので会社なりチームなりで価値観が共有されていることが重要だと思います。弊社ははてなさんと比べると比較的新しいメンバーも多いので、こういった部分には課題感があります。

おわりに

はてなさん、休日にも関わらずありがとうございました。勉強会後の懇親会でお話しさせていただいた内容も含め、日常の業務はもちろんのこと今後のScalaの普及展開に関しても様々なヒントを得ることができました。Scalaが今後もお互いにより良いサービスを作っていく上での助けになればと思います!

Scala Warriorをリリースしました

f:id:takezoe:20161010175855p:plain

昨年から密かに作り続けていたScala WarriorというWebアプリケーションをScala関西 Summit2016にあわせてリリースしました。

github.com

これはRuby WarriorにインスパイアされたScala学習用のゲームで、Scalaコードを書いて侍を操作しステージをクリアしていくというものです。

実装にはScala.jsを活用しており、プレイヤーが入力したコードをScala.jsでJavaScriptコンパイルし、それをクライアントにサイドに返却してブラウザ上で実行しています。エディタではCTRL+SPACEでコード補完、CTRL+Sコンパイル結果の確認ができます。このあたりのコードはscala-js-fiddleを参考にさせていただきました。

とりあえず動くものをリリースしたというだけでステージ数も少ないのですが、今後少しずつ改善していければと思っています。Scala.jsの利点を活かしたWebアプリケーションになっていると思いますので是非試してみていただければと思います。

Scala関西 Summit2016に参加してきました

10月8日(土)大阪で開催されたScala関西 Summit2016にスポンサーとして参加させていただきました。

summit.scala-kansai.org

私自身は前職時代を含めここ4年ほどはScalaで仕事ができるようになっていますが、日本だけでなく世界的に見てもScalaの普及度というものはまだまだだなと感じることがよくあります。弊社は東京の会社ですが、今回スポンサーをさせていただいたのは関西にも「これからScalaを使いたい」というプログラマがいらっしゃるのであればそれをサポートすることでScalaの普及に貢献できるのではないかという思いがあってのことです。

当日はスポンサーブースを出していたり、自分自身もスポンサーセッションで登壇させていただいたりしたので他のセッションにはあまり参加できなかったのですが、その中でも参加したセッションについて紹介したいと思います。

はてなにおけるマイクロサービスとScala

はてなさんの新決済システムでのScalaの採用事例の紹介でした。

要件から落とし込んだScalaの選定理由がきちんと言語化されており、決め手としては「DDDを実践するための高い表現力を持っていること」「学習曲線は緩やかではないものの社内でこれまで積み重ねてきた事例や教育コンテンツが存在した」という2点だったようです。はてなさんとしてはScalaにコミットというよりは用途に応じて適切な言語を使いわけようというスタンスなのかなという印象を受けました。

ちなみにORMにはSlickを使っているものの、DSLは使わずにPlain SQLのみ使ってらっしゃるそうです。また独自拡張を入れてブロックして結果を取り出せるようにすることでプログラマがDBIOやFutureに触る必要がないようにしているそうです。妥当な判断だなと思う反面、それならもはやSlickではなく別のライブラリを使ったほうがいいのではという気もしましたw

Play2+SlickだけじゃないScalaのWeb/DBフレームワーク事情

私のスポンサーセッションではPlay2 / Slickの代替フレームワークの紹介をさせていただきました。

www.slideshare.net

20分のショートセッションだったのでWebフレームワークについてはほぼスキップ、DBアクセスフレームワークについてもかなり駆け足となってしまいましたが現時点での結論は以下の通りです。

  • WebフレームワークはいまのところPlay2でよさそう
  • DBアクセスはデファクト不在なのでしばらく様子見、今選ぶならScalikeJDBC

Scalaフレームワークはいまだに決定打に欠けるものが多く、消去法で選ばざるを得ない状況だと感じていますが今後のフレームワーク選定の参考になれば幸いです。

sbt再入門

@tototoshiさんのsbt入門セッション。

入門といってもsbtの使い方ではなく、sbtの設定を理解しようというもので、KeyとScopeについて分かりやすく説明されていました。私はsbtの設定ファイルに書いてある内容は理解しているつもりではあるものの、記述そのものはコピペしてるマンだったのでこのセッションで理解を深めることができました。

まとめ

スポンサーブースではscala-warriorの展示やGitBucketステッカーの配布などもさせていただき、多くの方とお話しさせていただきました。国外の方もいらしていて少しお話しをさせていただいたのですが、海外でのScalaの状況についてもいろいろと考えさせられるものがありました。今回の活動を通して得たヒントをもとに今後もScalaの普及のためにできることを模索していきたいと思います。

なお、参加者のツイートが以下でまとめられています。スライドの一覧リンクもありますので当日の様子を知りたいという方はこちらをご覧いただくとよいと思います。

togetter.com

今回のScala関西 Summit2016はセッションの配置やバランスもよく、Scala初心者の方から上級者の方まで楽しめる内容だったのではないでしょうか。今回は東京勢のセッションが多かったですが、関西のScalaユーザの事例などももっと増えてくるといいですね。

スタッフ、登壇者、そして参加者の皆さん、お疲れさまでした。来年のScalaMatsuriでまたお会いしましょう!