Scala関西Summit2018に参加してきた話
blogに書くまでが勉強会らしいので書きます
参加したセッションと感想
どっちも聴きたいというのが結構あったけど、迷ったときは後述する動機に基づいて選択しました。
長期的なメンテナンスの必要なScala製システムにおいて気をつけるべきこと
Scalaに限らず直面する問題。
個人的に印象的だったのは
- 技術選定は慎重にする
- Javaで書いても複雑にならないようなものはJavaで書いてしまう
- 可能な限りライブラリに依存しなくて良いようにする
- Scalaは言語として、変化を恐れないという部分があるため、その哲学を受け入れましょう
前者3つはトレードオフの話。盲目的にならず「何故その選択をするのか」を明確にするということ。
最後の1つは心構えみたいな話ですけど、「変化を恐れない」というマインドと余裕を、自分でもチームでも持ち続けたいなと、改めて思った。
明日から使える実践エラーハンドリング
アプリケーションコードにおけるエラーハンドリングの話は純粋に興味のあるところでもあるし、最近社内の勉強会でほとんど同じモチベーションのLTをやったというのもあって聴講。
Try/Eitherの使い分けは、自分では「Javaが投げる検査例外を扱うときだけTry、それ以外はEither」くらいの感覚だったけど、明確に言語化されたものを聞くと改めて学びがあって非常にありがたかった。
発展編として挙げられていた「継続渡しスタイル」がすごく気になるので勉強しようと思う。
ZOZOSUITはScalaで動いてるよ！
一番目からウロコだったのはScalaの話でも何でもないんですけど
- チームリーダーがプロダクト要件として正しいかどうか担保する
- テックリードが言語として正しいかどうかを担保する
という、コードレビューにおける「ダブルレビュー」という体制の話。
もともとScala書ける人が多かったんですよね、というお話は純粋に羨ましくもあり。
Akka HTTPで構築するシンプルなAPIサーバ
プロダクト環境で利用したことがあるのはSkinnyFrameworkだけだったということと、Sprayのときにちょっとだけ調査したこともあって気になっていたライブラリ。個人的に軽量フレームワークが好きっていうのもある。
後方互換性に結構気を使ってくれるライブラリというお話をされていて、プロダクト環境で利用する際には、選択の材料としてかなり大きなアドバンテージだと感じた。
out-of-boxなwebフレームワークは確かに便利なんだけど、使わない機能があったりとか、あとから要件と合わなくなってきたときがしんどい、みたいな話には完全に同意。
次に何かイチから構築する、となったときはAkka HTTP + ScalikeJDBCでシンプルにやりたいなーという思い。
エンタープライズScala
Scalaを導入する際の勘所としてこういうのがありますよ、という感じの発表。
「Scalaのここすき」をちゃんと伝えられるようになりたい。
PHPエンジニアによるScalaエンジニアへの転身とその手引き
- 関数型プログラミングというパラダイム
- JVMのエコシステム
- ストリーミングや並行処理プログラミングに関する知見
という、多くの「分からないこと」に対して
- 一度に多くのことを学ばない
- 社内教材や習作による段階的な学び
によって対処したよ、というお話。
自分がどうやってScalaを学んできたか、どうやって後輩（に限らないけど）に教えたか、と振り返る機会になったし、段階的な手引きを提供できていなかったな、と反省。知識を整理するためにも、復習の必要があるなという感じ。
変位指定についてわかりやすく解説させてください
最近この本で変位指定を完全に理解したので何もわからなくなりたかった*1
- 作者: 瀬良和弘,水島宏太,河内崇,麻植泰輔,青山直紀
- 出版社/メーカー: 技術評論社
- 発売日: 2018/10/27
- メディア: 単行本（ソフトカバー）
- この商品を含むブログを見る
型パラメータの変位指定、定義したことはなかったけどなんとなく知ってる、くらいだったので、聴きたかった。
発表中に「mutableなクラスに共変な型パラメータを指定すると型安全性を壊す可能性がある（だからscala.Arrayは非変）」というお話があって、ずっと疑問だった「Javaのジェネリクスでは変位指定に相当することを定義できないのは何故か」、に対して「javaのクラスはデフォルトがmutableだから」という理解を得た気がしたので、その旨を質問してみたが「Javaのジェネリクスでは変位指定に相当することを定義できないのは事実だが、理由については分からない」ということだった。
懇親会の際に何人か交えて改めてお話する機会があって「歴史的経緯含めて何故そうなっているのかを知るというのは本質ではなかったりするよね」という話になった。確かにそうですね。真摯にお応えいただいてありがとうございました。
実践GraphQL on Scala
GraphQL気になっていたから、というのと、最近感銘を受けたこの記事
を書いた人の発表だということで聴講。
I/Fを型定義できるメリットや、Scalaの型システムとの相性の良さについて、また「主観」とはおっしゃっていたけど、どういう場面だと有効かという考察もあり、「使えそう、使ってみたい」と思える内容だった。
動機の話
今日のモチベーションは、帰ってから「チームに説明できるようになる」です #scala_ks
— zerosum (@zerosum_) 2018年11月10日
まあ何かっていうと、この1年位でScalaのチームからJavaのチームへ異動したっていうのと
みたいなお気持ちがあった、というのと、かといって「Scala触ったこともあるけど、別にJavaで困らないなと思ったよ」というチームに対して「どうしてJavaでもKotlinでもなくScalaなのか」を明確に説明できるかというとそうでもないな、というのがあり、自分で明確に言語化できるようにしたかった、というモチベーションで臨みました、という話。
だから6年放置してたらしいblogも書いた。
