kmizuの日記

プログラミングや形式言語に関係のあることを書いたり書かなかったり。

Scala, Scala 2, Scala 3, Dotty, DOTの違い：処理系と言語を区別する

はじめに

昨日、 ScalaMatsuri 参加者の一人から、タイトルの用語について、どういう使い分けをされているのかがわからない、といった質問があったので、処理系と言語の区別という観点も踏まえてちょっと整理しておきます。Eugene Yokotaさんから聞いた話としては、Scala 3という用語についてちょっと違う意味合いもあるようなのですが、その辺はツッコミ入れてくださるのではないかと期待しています。

Scala

2019年6月30日現在、普通にScalaといったらプロダクションで普通に使われているScalaの処理系（scalacなど）を指す場合と、その処理系が対象とする言語そのものを指す場合の用法の大まかに二通りがあります。この辺の使い分けは話の文脈に多分に依存していて、たとえば、「Scalaはコンパイルが遅い」「Scala 2.12でコンパイル速度が15%（詳細な数値は忘れました）向上」といったとき、意識していなくても、処理系の方を指していることになります。なぜなら、このとき、Scala「言語」の変化について言っているわけではないですから。一方、「Scala 2.12でSAM type conversionが入った」という話をするとき、主に、言語そのものを指していることになります。標準ライブラリの変化については扱いが難しいですが、どちらかというと言語自体に近いコンテキストになるのではないかと。

Scala 2

これは、1～2年後にリリース予定（要出展）のScala 3と区別する文脈で用いられることが多いです。このときも、「Scala 3ではコンパイルがかなり早くなる」といったときは処理系の話をしていますし、「Scala 3でenumが」とか「implicitについて書き方が変わった（改善された）」というとき、Scala 3（予定）の言語（仕様）について言及しています。

Dotty

これについては若干扱いに困るのですが、基本的には、

github.com

で開発されている、Scala 3（予定）の処理系の現在の実装であるものを指すことがほとんどです（Dottyでコンパイルが大幅に早くなった、Dottyでは将来的にTASTYが入る、など）。ただ、「Dottyでenumが入った」「Dottyでimplicit function typeが入った」「Dottyでhogehoge機能が削られた」という話をしているときは、主に言語の話をしているわけです。ちょっとややこしいのは、DottyはScala 3の処理系になることが既に確定していて、おそらくリポジトリ名なども変更されるかと思います。DottyはまだScala 3になっていないので、「Scala 3でenumが入った」というと未来の仕様の話について過去形で話すというおかしなことになってしまいます。「enumが入った」という過去形で言うならDottyというキーワードを使う方が伝わりやすいのかな、という気がします。

DOT calculus

これについては、上記のよりもだいぶわかりやすいです。元々、Odersky先生（および共同研究をしている人たち、あるいは、研究室の大学院生、そこ出身の研究者）は設計の初期段階から、core calculusの研究を同時に進めていました。発表で話したのですが、

  • vObj calculus: 2003
  • Featherweight Scala: 2006
  • DOT calculus 2012-

といった感じです。そして、DOT calculusについては、各論文において、という形ではありますが、明確に定義されているので、それほどややこしいことはありません。ただ、DOTというcore calculusが開発されはじめて、もう10年近くになるわけですが、その間に、望ましい性質を証明できるように細かい部分に手を加えたり、ということがあり、DOTには複数のバージョンがあります（OOPSLA'16におけるDOT、ECOOP'17におけるDOTみたいな表現が妥当かなと思います）。ただ、基本的にはDOTそのものでプロダクションコード開発するわけではないので、最新のDOTに関する論文を追っかけておけばいいです。私は、説明するときには、どの時点でのDOTの話をするのか明記しましたが。

さらに脇道にそれると、本来のDOTより強い性質を証明したいとか色々な動機によって、μDOTとか、kDOTとか。興味があったら調べてみてください。ところで、全然関係ないのですが、ECOOP'17の論文では、Strong Normalizationについて証明されていたのですね（やはりCoqで証明が書かれている模様）。ただ、これはDOTのvariantであるD<:>についてであって、再帰関数や再帰型（など？）を取り除いたもののようです。

さらにさらに脇道にそれると、Scalaのcore calculusについては変遷があったものの、ようやくDOTが決定版になって（性質を証明するための基盤になったというか）、それのvariantで色々証明するということが行われているようです（この辺はもう全然追えていないですが、DOT関連の論文、プログラミング言語系の国際会議に査読通ってるものも少なからずあるので（OOPSLA、ECOOP、POPL、その他？）、その辺によく出席する研究者の方々の方が詳しいのではないかと思ったり）。

https://2017.ecoop.org/details/ecoop-2017-papers/11/Strong-Normalization-for-Dependent-Object-Types-DOT-

というわけで、ざっくりとその辺について説明してみましたが、参考になれば幸いです。

ScalaMatsuri 2019に参加しました

もう日をまたいでしまいましたが、6/27～6/29にかけて行われた、ScalaMatsuri 2019に参加してきました。まず、総評というかざくっとした感想ですが、とても楽しかったです。特に、アンカンファレンスDayは完全に学生気分に戻っていました。日本のScalaコミュニティに関する活動に関わり始めて、もう10年超になりますが、ここまで規模の大きなコミュニティになるとは思っていなかったなあと感慨深いです（もちろん、比較的初期には、私が貢献した部分があるとはいえ、ある程度成長した後は、その他の方の活動による部分が大きいと思います）。記憶が薄れないうちに、とりあえず備忘録として簡単な記録を残しておきます。

0日目 - ワークショップ DAY

この日は、OSS ハッカソン@ScalaMatsuri 2019に参加しました。この、OSS ハッカソンは、

scalaconfjp.doorkeeper.jp

に説明があるように、Scalaに関係のあるOSSについて、pull requestを送ることを目指すという趣旨のものです。メンテナの方ともうちょっとコミュニケーション取ればよかったかなという思いもあるのですが、scala/scalaのコードを読んだことがないわけでもないし、まあもくもくとやろうという感じで作業をしていました。今回、時間内にpull request送るにあたって、確実にできる単純作業として、標準ライブラリのpublicなclassのpublicなメソッド、可能な限り全てに返り値の型を明記して回るということをやっていたのですが、それに没頭するあまり、買ったばかりのThinkPad A485のEnterキーのキートップが外れるというアクシデントもありました（正確には、Enterキーの調子が途中でおかしくなったのに気づいて、外してもどせば直るんじゃね？という、今おもえばなんでそんなことをした、という暴挙によって壊れたのですが、似たようなものです）。

で、とりあえず pull reqを作ることができました。

github.com

実のところ、この作業、InttelliJ IDEAの、型アノテーションを付けるquick fixにある程度頼りました。その結果、一部コンパイルが通らないというミスがあったりして、修正しました。まだ、修正リクエストがありますが、コメントを見る限り、指摘された点を修正すれば受け入れてもらえそうな気がします。しかし、意外にまだ型を明記してない箇所が多かったことにはちょっと驚きました。中には、結構推論結果が微妙なものになっているケースも見られたので、やはり、少なくともScalaではpublicなメソッドの返り値の型を明記すべきだなと再認識しました。

1日目 - カンファレンスDay

この日は、私が午後一でセッションがあったため、午前中に準備してから家を出たのですが、行く途中に、修正したくなった箇所がでて急遽修正を入れたせいで、同時通訳の方との打ち合わせが長引き、結果セッションに遅刻するという失態を犯してしまいました。大変申し訳ないです。

さて、肝心の私の発表ですが、Scalaの形式化の最新の成果であるDOT計算を説明するというものだったのですが、40分で納めるというのはあまりにも無謀であるということに早めに気づくべきでした。もちろん、操作的意味論とはとか、型付け規則とはとか、抽象構文とは、とか、そのあたりの解説すっとばせばいけた気がするのですが、いきなりDOT計算の説明に入るのもアレですし。

結果として、DOT計算を説明するにあたって必要な前提知識の説明で時間の大半を消費してしまい、DOT計算についてはかなり駆け足になるという結果に終わりました。

ただ、その後、参加者の一人から、アンカファレンスで、説明しきれなかった部分を説明して欲しいという要望があり、私としても中途半端に終わるのは不本意だったので、アンカンファレンスボードに書くことにしました。その結果、翌日のアンカンファレンスDayで本当に続きを発表することになったのですが、それは後にして。

私の発表が終わった後は、他の参加者と技術談義や雑談などをしているうちに時間がどんどん過ぎていき、気が付いたら懇親会の時間になっていました。しかし、なんで、転職する情報がこんなにすぐ伝わっているのか…（もちろん、publicに書いたので知られることがまずいわけじゃないのですが）。

懇親会は例年通りに立食形式で、色々雑談をしながら楽しんで過ごしました。しかし、私は人の顔を覚えるのが相変わらず苦手なため、一方的に私のことを覚えてくださっている方が多数いてなんだか申し訳ない気持ちでいっぱいになりました。なお、翌日に聞いた話によると、有志による二次会、三次会があったらしく、最長で26:00まで残っていた人もいたのだとか。

2日目 アンカンファレンスDay

私にとって、今年のScalaMatsuriはある意味この日が本番だったのではないか、と思います。アンカンファレンスDayでは、朝会というものがあり、10:00に参加者が集まって、アンカンファレンスボードの中から、人気があるものを司会者が選び、スケジューリングをするのですが、DOT計算については大変要望が多く、割と早めに決まりました（前日の投票数見た時点で、おそらくやることになるだろうなと思ったので、絶対に朝寝坊しないぞという強い決意がありました）。そして、ここでなにかが吹っ切れたのか、他の方が書いたネタのセッションについても私の方から、「その話なら俺も乗った！」というノリでどんどん挙手した結果、最終的には計4セッションしゃべるという羽目になりました。今思えば無茶をしたものです。

新卒の参加者に皆でScalaを教える

確か、ボードに書かれていたネタは「新卒ScalaエンジニアなんだけどScala教えてくれ」みたいな話だったと記憶していますが、朝会で「じゃあ、私が教えます」とかノリで言った結果、私もしゃべることになりました。ちょっと私が進行役がうまくなかったせいで「具体的にここがわからない」という話にもっていけなかったのは、ちょっと反省するところです。ただ、初学者がsbtでつまづくポイントとかの一部を伝えられたのはよかったのかなと思います。

DOT計算の話の続き

ある意味前日のリベンジみたいなものですが、完全にとはいえないものの、伝えたいものはなんとか伝えられたかなと思います。ただ、DOT計算の型付け規則で構成される型システムのややこしさについては、私はちょっと甘くみていたというか、細かく説明する段になって、自分の理解が深くなかった（特に、型メンバ関連のサブタイプ関係の定義）のでつまづいたのは反省ポイントですね。あと、DOTの操作的意味論の部分に話がうつった段階で、「まあ、（DOTの）操作的意味論はみればわかるように簡単ですねー」とか軽く言っちゃったったんですが、その「簡単さ」の感じは伝わっていなかったような気がします。

Go VS. Scala

ボードでは「From Go to Scala」だったかなんだかで、Simple VS. Easyという話が主題でした。このセッションは、パネル形式でしたが、たぶんアンカンファレンスの中でもかなり盛り上がったのではないかと思います。当初、GoとScalaの比較だったはずだったのが、KotlinとかSwiftとかC++とか話が広がっていくあたりの（良い意味での）ぐだぐだ感は、アンカンファレンスらしく、非常に楽しいものでした（アンカンファレンスは、盛り上がりをコントロールできないところがひとつの醍醐味だと思っています）。どういう話だったのかは、 #ScalaMatsuri とかでTwitterを検索するとなんとなくわかるかもしれません。

面白論文を紹介するよ

空いた枠があったので、急遽スポット参戦した感じなのですが、とりあえず久しぶりに論文解説でもしてみよー、というノリでやってみました（すでにScalaが関係なくなっている辺り、アレですね）。ちょっと反応が薄かったのが気になったのですが、Twitterの反響を見る限り、つまらないとかいうわけではなく、話の内容を噛み砕くのに精いっぱいだったのかな、という気もしました（これは、私があんまりうまく説明できなかったなと思うところですが）。

そんなこんなで、この日はほとんど発表で埋まっていたので、あまり合間に雑談する余裕はなかったのですが、テンションで乗り切った感じです（笑）。

最後に

今年のScalaMatsuriも「祭り」にふさわしい盛り上がりがあって良かったです（スタッフの方、特に座長は大変だったと思いますが）。来年は久しぶりにスタッフとして復帰できたら、と思っています。ではでは。

株式会社ドワンゴを退職します

はじめに

当初、ScalaMatsuri 2019が終わった次の日の、6月30日に書く予定だったのですが、最終出社日も終わっていることだしよいかということで、エントリを書くことにします。 2019年6月30日をもって、5年と3か月勤めた株式会社ドワンゴを退職します。最終出社日は6月26日でした。

これまで2回転職してきましたが、ドワンゴに居た期間が最長です（なお、5年で最長でというのに違和感感じる人もいるかもですが、博士卒で就職したので、まあそんなもんかと思っています）。

何やってたの

1年目こそプロダクト開発に携わっていたものの、2年目以降は、

  • Scala研修テキストの執筆やメンテナンス
  • 新入社員研修の中のScala研修講師
  • ドワンゴ社員として各種イベントやカンファレンスで発表
  • 論文の査読や情報処理学会関連のイベント（主にPRO（プログラミング研究会））への参加
  • 自分主催の勉強会（テーマは気分によってころころ変わっていましたが）
  • 国内Scalaコミュニティへの貢献（できていたかは自信がありませんが）
  • その他色々

という感じで、あまりプロダクトコードを書いていると胸を張って言えるものではなかったです。

おそらく、当時の自分では、他の会社でこういった雑多な行為が業務として認められることはおそらく稀だと思うので、これはとても幸運でした。理由としては、当初から、ある程度そういった採用につなげる（広報や宣伝）役割を期待されていた、というのが大きかったというのがあります。一方で、しばしば体調を崩すことのある私への配慮という面もあったのではないか、と感じています。副業で（ドワンゴでは申請すれば副業（兼業）が許可されています）なにがしかを書いていることはありましたが。実際のところ、この役割（採用につなげる）についてはあまり定量化できてはいなかったのですが、私がいるということが入社の動機の一つになった人は思ったより居たようだ、というのを最近になって実感しています。

最近はかなりよくなったとはいえ、体調を崩すことがしばしばあった私が勤務できたのは、ひとえにドワンゴの環境と、特に所属部署の上長の柔軟な対応があってこそだと思います。とても感謝しています。

退職理由

人間関係が悪かったわけでもなく、問題行動を起こしたわけでもなく、評価が下がったわけでもなく、モチベーションが下がったわけでもなく、上司と折り合いが悪かったわけでもなく、体調が悪くなったわけでもなく、…と書けば、想像はつくかと思いますが、ドワンゴ「自体」を取り巻く環境の変化によるものです（その辺はなんとなく察していただければ）。

ただ、これは副要因というか後付けなのですが、一人のエンジニアとして、ドワンゴに入社して2年目以降、プロダクト開発から多少距離ができていたことに後ろめたさがついてまわっていました。簡単にいうと、「俺はなんだかんだ勉強会でたいそうなことをいっているけど、自分はどれだけプロダクトコードを書いているのだい？」という自分の中での葛藤です（ドワンゴの前は普通以上にはプロダクト開発に関わっていましたが）。もちろん、途中のどこかで、開発メインのチームに復帰するという道はあったかと思いますが、私がすでにそれなりに対外的な知名度が上がってしまった（らしい）のと、体調を崩して迷惑をかけたら、という懸念があり、動きづらく感じていた、ということはあります。。これは、上長が悪い、とかいう話ではなくて、基本的には自分の問題だと認識しています。むしろ、上長はとても配慮してくれていました。

主要因に加えて、そういった副要因もあり、転職を決意することにしました。

転職先

次の職場は既に決まっており、7月1日から、株式会社オプトさんでエンジニアとして働くことになっております。

https://opt-technologies.jp/

引き続き、Scalaコミュニティへの貢献は続けていきますし、所属会社のアピールという、これまでドワンゴで担っていた役割も担うと思いますが、Scalaにとらわれず、教育やこれまで避けてきた技術の習得、マネジメントについても積極的に挑戦してみたいと考えています。エンジニアでありたいという願望は強いので、再び普通にプロダクト開発にも携わると思います。ただ、同時に、私は研究への思い入れがとても強く（そのため、博士号を取った後は査読付き論文を一本も執筆していないにも関わらず、ICFPに参加したり、PROに参加したり、論文査読を引き受けたり、学会の運営委員を引き受けたりしていました）、そろそろ色々温めていたアイデアを論文としてアウトプットすることを考えているところです。この両立がどこまでうまくいくかどうかは入社してみないとわかりませんが、基本的には楽観視しています。

最後に

5年と3か月、ドワンゴには大変お世話になりました。ありがとうございます。ドワンゴにまだ残っているエンジニアの友人たちとも交流を続けたいと思っています。

おまけ

いい機会なので、主にこれから学んでみたいことやあまり学んでこなかった事に関する本をウィッシュリストにしてみました。もしよければお祝いください。

https://www.amazon.jp/hz/wishlist/ls/2W4BD3FUNVD4H?ref_=wl_share

これから、また会う機会の会う人も多いかと思いますが、これからもよろしくお願いします。

自作パーザコンビネータライブラリを集めたリポジトリ mlcombinators を公開しました

私がプログラミング言語を学ぶときには、パーザコンビネータライブラリを作る、ということはScala福岡2019の講演とかでも他のところでもよく言っていることなのですが、せっかくなので、これまで私が作ってきたミニパーザコンビネータライブラリ集をひとつのリポジトリにまとめて公開することにしてみました。もちろん、これだけでは到底実用に耐えないことは言うまでもないです。

github.com

なお、mlはプログラミング言語のMLとはあまり関係なくて、multi-languagesくらいの意味です。それはともかく、このリポジトリには、私がそれらのプログラミング言語を学びたての頃（一部例外あり）にどのようにしてパーザコンビネータライブラリを組み立てたのか試行錯誤の跡が残っており、ひょっとしたらどなたかの参考になるかもしれません。

実は、これ以外にもC#とかCとかもっと色々なものについてパーザコンビネータライブラリを作った気がするのですが、その辺はGitHub以前（？）だったせいか、残っていないようです。

ではでは。

（追記）その言語のプロからみると、ここがいけてないとか色々言いたいことはあると思いますが、その辺はIssue立てるなりPull Requestしていただけたらベストエフォートで対応します。

実践Scala入門（共著）が発売されます

https://www.amazon.co.jp/dp/4297101416

企画自体は2015年くらいから始まっていたんですが、紆余曲折あって、約3年経ってしまいました。ともあれ、ようやく出版までこぎつけられてほっと一息です。 実際には多少遅れる可能性がありますが、10月27日から技術評論社さんから発売予定なので、この機会にScalaを勉強してみたい方は、是非予約していただければと思います。 さて、書いてる間の紆余曲折書いても意味がないので、このエントリでは、この書籍のウリを簡単に書きたいと思います。

現状の日本語のScala書籍は、大半が新しいバージョンのScalaに追随できてなくて、新しくScalaに入門する人に勧められるいい書籍が ほとんどないという問題意識がありました。いわゆるコップ本はScala書籍の中でもかなり売れていることもあってか、2.12対応の第三版まで出版されているものの、 重厚長大であるために敬遠する人が多いという課題があります。というわけで、もうちょっと「コンパクトなコップ本」があるといいなということで、それが今回の 実践Scala入門のコンセプトになっています。

「コンパクトなコップ本」というのが何を指しているのかですが、コップ本の中で特に重要だと私たち（共著者）が考えたものをピックアップして、もうちょっと 手軽に読めるものを作ろうといったところです。ページ数もコップ本に比べてだいぶ少なめなので、コップ本に挫折した人にも比較的気軽に手に取ってもらえる とうれしいと思っています。ちなみに、Scalaのバージョンは2.12.7対応です。

もう一つのウリは、入門本でありながら、単に言語の解説に終始するのではなく、sbtの使い方やテストの書き方、コレクションライブラリの使い方など、ある程度 実践寄りの内容も盛り込んだところです。この書籍だけで実践のための知識が十分に身につくとは、もちろんいいがたいですが、「おわりに」で今後のための参考文献 も示してあるので、リストアップした参考文献を元によりステップアップしていってもらえればと思います。

ただ、実践寄りの内容「も」あるとはいえ、あくまで入門書であるので、Scalaでプロダクションコードを書くためのノウハウががっつり詰まった本を期待されると ミスマッチが発生するかもしれません。

ちなみに、目次はこんな感じです。

  • はじめに
  • 第1章「Scalaひとめぐり」
  • 第2章「Scalaの基礎」
  • 第3章「Option/Either/Tryによるエラー処理」
  • 第4章「コレクション」
  • 第5章「並行プログラミング」
  • 第6章「Scalaプロジェクトのビルド」
  • 第7章「ユニットテスト」
  • 第8章「知っておきたい応用的な構文」
  • 第9章「よりよいコーディングを目指して」
  • おわりに

なお、実践Scala入門はScala入門書ではあっても、プログラミング入門書ではない（最低1つのプログラミング言語を習得していることを前提とする）のでその点は注意していただければと思います。

そのあたりを踏まえた上で、購入を検討していただければ幸いです。

ScalaMatsuri 1日目の雑感

ScalaMatsuri Training Dayは、別チケットであることからもわかるように、ScalaMatsuriとは若干独立していました。というわけで、この日から本番でした。この日、私が一番楽しみにしていたのはMartin Thompsonさん（Javaで高パフォーマンスのメッセージングライブラリLMAX Disruptorの作者でもある）の発表でした。彼はScalaにはあまり縁がない人物ではありますが、Javaでカリカリに性能をチューニングをする専門家であり、そのノウハウの一端でも聞ければという思いでした。

「関数型プログラミングによるパフォーマンス」

寝坊したので間に合わないかと思いましたが、タクシーに乗って、なんとかMartinさんの発表には間に合うことができました。しょっぱなからHaswellのアーキテクチャ図を示して、低レベルな部分での動きを把握することの重要さを語っていたのが印象てきでした。また、関数型データ構造について、一般的には木構造が多いが、それはポインタをたぐる操作を多用するために、現代のCPUアーキテクチャでは遅くなりがちであるというのはなるほどと思いました。後半、CRDTというデータ構造を中心に説明が進んでいくのですが、私は恥ずかしながらCRDTについてほとんど知らなかったので、後半ついていけなくなったのが少々悔しかったです。まとめとしては、関数型データ構造を使うときでもハードウェアを意識すべきだ、ということでしょうか？

「Haskell対Scala」

これは私の発表ですが、HaskellとScalaについて、言語戦争に陥らないように、それぞれの利点を比較しようという趣旨のものでした。聴衆の方にうまく伝わったか自信がないのですが、私は、最近のScalaコミュニティがHaskellから学ぶことはあっても、ML系言語からあまり学んでいないことにもったいなさを感じていて、ScalaでMLスタイルのモジュールがエミュレートできることを示すことで、MLから学ぶこともあるのだということを主張したかったのでした。なお、発表中は、Scalaの型推論は雑魚ですという言い方をしたのが結構うけたようですが、これ自体はまぎれもない事実です。しかし、型システムの表現力と型推論の強力さは一般的にトレードオフの関係にあるものであり、両立させるのが難しいので、どちらを取るかは好みの問題かもしれません。

なお、発表の後、元、筑波大学のM先生と鉢合わせした（M先生が非学術系のこういうイベントに参加されるとは思っていなかったので）のは印象深かったです。Scalaの型推論をディスったことについても、もうちょっとScalaの型推論を評価してもいいんじゃないかなあということを言われましたw（M先生は型システムの専門家です）。

「Haskell + Scala ハイブリッド開発大作戦」

HaskellのJVM用の実装Eta、というか、処理系としてはGHCをベースにしてクラスファイルを出力するもの、ととらえればいよいのでしょうか、についての発表でした。正直なところ、Etaの実装については興味深かったのですが、現在のJavaのジェネリックスととても相性が悪そうなところが気になりました。また、ただでさえコンパイルが遅いScalaなのに、それにさらにコンパイルが遅いであろうEta（GHCベース）と組み合わせて大丈夫なのかとか、Javaとの連携がScalaほどうまく行かなそうなのが気になりました。用途としては、Java側のfacadeを用意して、それをHaskellを呼び出すようにするのが一番良いのでしょうか。

その他

昨日に引き続き、不眠気味で体力がかなりぎりぎりだったので、自分の発表といくつかの発表を聴いた他は休憩用のソファーで休んでいました。せっかくのMatsuriなのでもったいないとも思うのですが、体調の問題はどうしようもなく。

この日は、懇親会があったのですが、私はオプテピピック会場で色々な方とお話しました。中にはカンボジアからはるばる来られた方や、自分に関係のある方（詳細は伏せますが）との思いがけない出会いもあって楽しく過ごすことができました。

私は、体力的には懇親会が終わったあたりで限界が来ていたので、翌日のアンカンファレンスにも出られませんでいたし、楽しみ切れたかわからないのですが、とりあえず私の発表に穴を空けずに済んだことはほっとしています。

後日、公開されるであろう動画を見て、今回視聴できなかったお話を見てみようかと思います。

以上、短い感想でしたが、読んでくださった方ありがとうございました。

ScalaMatsuri 2018 Training Dayの雑感

今は金曜の夜（土曜日の朝とも言う）で、眠れないので、せっかくなので感想でも書いてみるかーってな具合に書いてみることにしました。

さて、ご存じの方も多いかもしれませんが、2016に実質運営を譲って、2017には名目上も座長の権限を譲ったため、今年は私は 特に運営に関して大きな働きをしていません（というのも控えめな言い方で、ほとんど何もしてない気がする）。

というわけで、今回は、一参加者としてのイベントの所感を書いてみようかと思います。

Training Day

今年からの試みであるTraining Day、Scalaにあまりなじみのない人にも参加してもらえるようにと、別チケットが用意されましたが、無事、完売に近いようになったようです。

「Scalaに関する神話と真実」

私の発表は、「Scalaに関する神話と真実」というタイトルで、Scalaになじみのない人の、Scalaに関する誤解を解こうというのが主眼でした。Scala福岡に来られていた方はご存知かもしれませんが、そのときの発表をベースに、細かいところを調整したものになります。いくつか質問があったのですが、印象に残っていたのは、「Scalaに移行しているのですが、nullなどを使われてなかなかうまく行かないが、どうすればいいのか」というものでした。そのときの答えとしては、私は「nullダメ絶対」ということで、nullを使うコードはレビューではじくという方針を提案したのですが、質問者の方は、レビュー体制が整っていないので、これから頑張ってみます、という回答でした。正直なところ、コードを（初期に一人でがりがりと書くときはともかく）レビューがないというのはあまり想定していなかったので、意外でした。他にもそういう現場は結構あるのでしょうか。Scalaに限らずコードレビューを行える体制がないと色々しんどいので、少人数だとしても、なんとかコードレビューができる体制を作るのが重要ではないかと思いました。

その他

実は不眠気味で、体力をかなり消耗していたので、自分の発表で手一杯で、あまり他の方のセッションを見に行く余裕がなかったのですが、まあScalaになじみのない人向けのセッションだからいいかと開き直っていました。Training Dayではスピーカーディナーがあったのですが、体力的に余裕がなかったために行けなかったので残念でした。とにかく、自分の発表に穴を空けなかっただけでもほっとしました。