ろじかるんるんものがたり

病人が特に何も書かない。無駄だからだ。

ScalaMatsuri 2017 に参加しました

しました。感想とかそういう感じの記事になります、遅くなりましたすいません。

色々あってそもそも CFP 応募してなかったんですが、結局二日目のアンカンファレンスで発表させてもらいました。

アンカンファレンスは、一日目にまず話したいことを適当に大きめの付箋紙に書いてホワイトボードにはり、聞きたい人たちが付箋にマーカーを付けて、マーカーが多いのを二日目にやる、という感じなのですが、たくさんマーカー頂けたのでこれは頑張らないといけないぞという感じで、大変でした。

タイトルは "What is Composability in Scala" で、発表スライドは以下に。兎に角時間がなかったので、口頭で補足しまくる感じの作りになってしまいました、スライドだけ見てもよくわからないと思います。

slides.com

Scala のオブジェクトシステム使えば ML 系のモジュールプログラミングができるよ、知らず知らずのうちにモジュールプログラミングをやっているんですよ、Haskell だけでなく ML からも学べるところはあるのでやっていきましょう、みたいな話でした。

実際 ML のモジュールを使ったプログラミングというのはプログラムの Modularity を向上させる上でとてもよく、なんで皆 OCaml じゃなくて Haskell から入門しちゃうのかなあといつも思う。

思えば self-type annotation について ScalaMatsuri で話すのは二度目な気がします。この言語機能はとても有用な割に、いまいち正しく使われていないというか、そもそもあんまり使われていない、と思う。

実装継承は is-a 関係でないし、実装詳細が外部に見えてしまう、ので所有(aggregation)を使いましょう、DI しましょう、みたいなことが古くから OOP 界隈では言われてきているわけですが、Scala の self-type annotation は、これに対する言語としての一つの回答になっていると思います。

あと、self-type annotation は最終的に具象化されるタイミングで、要求しているものが実装されていればよいのに対し、コンストラクタ DI とかだと、クラス A を要求するクラス B を要求するクラス C を要求するクラス D …みたいなので wiring が大変冗長になる。なので DI 「コンテナ」(DI と DI コンテナを混同する人が多いので強調しておきます)使おう、となるわけですが、DI コンテナは強力な反面、適切に使わないと、逆に依存関係スパゲッティができあがりがち。DI コンテナを使っていたつもりが DI コンテナに使われていた、みたいな…現在進行形で請けているお仕事のコードがそんな感じで、どうしたものかという心持ちなのですが。

abstract method(member) でいいじゃないか、という声もあるかと思います。それはそうです、自分だってなんでもかんでも self-type annotation にはしません。目安として、abstract member が 3 つを超えたら、基本的には別 trait に分けていいと思います。他の評価軸としては、自明に妥当な名前をつけられるなら別 trait に分けていいと思います。

self-type annotation のメリットは他にもあります。例えばメソッド定義 A、A のための抽象メソッド宣言 B、メソッド定義 C、C のための抽象メソッド宣言 D…みたいに、抽象メソッドが具象メソッドに埋もれてしまっていると、何を実装すればいいのかぱっと見でわからなくなってしまう。抽象メソッドをまとめてクラス定義の一番上や一番下にまとめるという手もありますが、self-type annotation なら要求されている型を見ればすぐにわかる。命名がしっかりしていれば要求されている型の定義を見なくてもコードが読める。適切なモジュールの切り分けと命名による可読性の向上ですね。

最近の IDE は賢いですから、定義がまだないものを列挙しといて、なんなら中身空っぽでメソッド定義書いといて、みたいなことがサクッとできるわけですが、IDE で常にコード読むわけではないので。

あとは実装「だけ」を継承する記法、というか言語機能があればなあと思うんですが…mixin して instantiation したオブジェクトは、そのままだと型推論で mixin の情報全部残るので(A with B with C みたいになっちゃう)、基本的には型注釈をちゃんとつけてあげるわけですが、object とかはそういうわけにもいかない。package object で val わざわざ使ってやるしかない。大変だるい。

発表内容にもありますが、(abstract) type member の存在も非常に大きいですね。話すと長くなるので略。

あとは first class module が自明に実現できているのが地味に大きいのではないかと思います。逆説的に、ScalaOOP で当たり前にできていることが、実は ML 系では難しいということになるので、なかなか面白いですね。first class module 実現するために必要な型チェッカの修正が大変らしいので、仕方ないけれど。

他には、自分の発表の一つ前の発表 "Poor man's type classes revisited" で色々と補足させて頂きました。Haskell の型クラスがどういう風にコンパイラに解釈されて翻訳されるか、みたいな話をしました。Haskell は thunk を使って評価していくので、型クラスの辞書のようなよく評価されるものはパラメタの頭にあるといいので、パラメタの頭に辞書を持ってくるわけですね…とか書いても、当日あの場にいた人間にしか伝わらないか。この話は終わり。

というわけで ScalaMatsuri お疲れ様でした。まずは今年も問題なくカンファレンスを実現、成功してくれた運営の皆さんに感謝。でも寿司バー瞬殺だったのは次回改善して欲しいですスシウオーウオースシ。次に、チケットを譲って頂いた、侍スポンサーの Dazzle 様にも感謝。今契約中のお客様です。



チケットを譲って頂いたということで、ここからは社の宣伝をしたいと思います。

Dazzle 様はウェッブサイトにもありますが、(自社製品としては)VR をやっていく感じの会社です。前述のウェッブサイト見てもらうのが早いので、詳細は略。

個人事業主の自分が何をやらせてもらっているかというと、ざっくりといえばコンサルに相当するようなことをやらせて頂いている、と思います。コードレベルで、ここはこうしたほうがいいんじゃないでしょうかと突っ込んだり、設計レベルで文句…もといアドバイスをしたり、自分でコードを書くこともあります。こういうの欲しいけど作るの難しいよね〜→ヨッシャ任せんしゃいみたいな。ただの便利屋な気もします。今はリリース前なので、進捗に影響出ても悪いし、レビューやツッコミはほどほどに、リリースに関係ない作業を細々とやっています…例えばこれ書いたり…仕事の範疇…だと思う…

うちのブログ見てる人は大体知ってそうですが、自分は結構面倒で重い症候群を患っている病人なので、一日に四時間程度が稼働時間の限界です。基本的に在宅じゃないと厳しく、出向なんてすれば着く頃には体力をかなり削られる、といった始末です。この前なんて社に出るだけ出て半分くらい寝てました。我ながら酷い…そんな感じで、色々融通を効かせてもらって、なんとか働けています。これは自分に限ったことでなく、社員さんにも基本在宅の方とか、たまに在宅作業する人とか、普通にいます。

所謂「自由な社風」が実現されていると思います。「自由な社風」を謳う会社の多くの、許容する働き方の狭きことといったら本当にもう…Dazzle 様はその点、働き方に関して融通がかなり利くと思います。自分だけでなく、社員さんも自由な感じです。勿論普通に働いている人もいます、というかそっちが多数派な気はする。一方で、コアタイムさえ出ればええねん〜みたいな感じでやっていく人もいますし、前述した通り今日は集中したいので在宅で〜みたいなこともあり。本当に自由です。あと、変わっていることというと、一日八時間じゃなくて七時間です、珍しい。といったような自由な社風を実現する一方で、無法地帯化したりということはなく、ちゃんと注意されるべきことはされますし、守られるべきことも守られるよう各位ちゃんとしています。良いことだと思います。

もう少し規模の小さいスタートアップとかなら、このくらい自由なところは他にもありますが、大きいところで実現されている所はあまり知らないです。

ファシリティは…紅茶党には厳しいです。コーヒーメーカーしかない。辛い。あと人が増えてきて机が足りなくなり、ついに基本的に在宅の自分の席はなくなってしまいました。かなしー。他にも色々書けるといいのですが、基本在宅なので正直あまり詳しくないです。

ScalaMatsuri の侍スポンサーになるくらいなので、Scala を業務で採用していますし、Scala が書ける人材を募集している、はず、です、多分。正直にいって、Scala native がいない状況なので、Scala native な社員さんが欲しくてたまらないんだろうなあ、という感じです。Scala を業務で書きたい人は是非。native くらいのレベルの人が入ったら、自分も多分楽になるし…!自分がお仕事させてもらうことになったのも、現場に Scala native がいないから、というのが一番だと思います。正直これは〜〜?と思うコードは、レビューしてるとそこそこ出てきます。腕の見せ所ですね、出来てるかは兎も角。Scala 関連のことから、プログラミング一般に言えることまで、色々です。あと C++ とか MSVC のビルド設定とかもやっている気がする。自分の業務がなんなのかわからなくなってきた。

Scala 以外だと Javascript(node.js) だとか色々。求人サイトなりを見てもらう方が早いと思うので省略。

ところで、書いていて思ったけれど、Scala native って何をもってして native といえるんだろう…言語機能 8 割知っていて 6 割使いこなせて有名どころのライブラリ一通り触ってれば native か…?まあ良いか、兎に角 Scala 書ける!Scala 書きたい!という人は是非ご一考を。今ならボクが業務でマサカリ投げます!(嬉しくない)

Wantedly にも求人出してるそうですが、Wantedly へのリンクは宗教上の理由で貼れません。ぐぐったら出てくると思うのでそれで。Wantedly 以外の求人サイトにも求人は出ていると思います。Facebook もあるはず…

追記:ファシリティについて、お茶が知らぬ間に増えたそうです。求人に関してはコーポレートサイトが最新とのこと