全Scalaエンジニアの生産性向上に貢献できるOSS

はじめに

Scala Advent Calendar 2018 の3日目への寄稿です。

2017年から Scala を仕事で使い始めて、1年強になります。
今年2018年は、仕事で使っている Scala を中心に、様々な OSS にちょこちょこ貢献してみました。
バグ修正や機能追加で仕事も捗りましたし、OSS でやっていたことが仕事でも活きたり、普段と違う技術分野の勉強になったりと、良いことづくめでした。
ぜひ他の Scala エンジニアにもオススメしたいと思い、筆を執りました。

全Scalaエンジニアがお世話になるOSSとは

みなさんは、どのような分野で Scala を使われているでしょうか。

• Play Framework、Scalatra、Lift などを使ったWebアプリのバックエンド開発
• Scala.js を使ったWebアプリのフロントエンド開発やバックエンド開発
• Spark、NiFi、PredictionIO などを使ったビッグデータ処理、機械学習
• Scala Native を使ったネイティブアプリ開発
• 日々の業務でのスクリプト処理

どのような分野にせよ、ほぼすべてのScalaエンジニアの生産性に直結するOSSがあります。

1. Scala
2. sbt

この2つは、Scalaを使う上でまず間違いなく日常使いする偉大なOSSです！¹

ところで、ソフトウェアエンジニアなら、多かれ少なかれ以下の願望があると思います。

• 普段使いの道具を洗練させて、生産性を高めたい。²
• たくさんの人に使われるソフトウェアを開発してみたい。
• 流行りの GitHub で草を生やしたい。

全世界のScalaエンジニア³が日々使う Scala や sbt の開発に貢献することは、なんと、これら3つの願望を同時に満たせてしまいます。

Scala経験の浅い自分でもできた Scala & sbt への貢献

ということで、Scala や sbt の開発に参加し、生産性を高めていきましょう。

ちょっとしたライブラリならともかく、Scala や sbtだと、なんとなく抵抗感がありますか？

• コンパイラなんて勉強したことないので手も足も出なそう
• 標準ライブラリって高速・省メモリなアルゴリズム知らないと厳しそうだし、implicitとか型パラメータとか駆使したりでしんどそう
• sbtってヘンてこなDSLだし何かヤバそう

私はそう思ってました。というか、今でもそんな苦手意識があります。

ですが、心配はいりません。
Scala や sbt への貢献する方法は、難しいものばかりではありません。

1. 課題の報告

ユーザーとしてバグ報告や機能要望、分かりにくいところなどを Issue として伝えることも、立派な貢献になると思います。

例えば私は、「コンパイラオプション -Ywarn-value-discard で有効になる警告が this.type のときだけは例外的に警告にならないのは分かりにくい」と課題を上げました。⁴

2. 課題の解決

ユーザーから寄せられた Scala や sbtの課題は、GitHub上で管理されています。

• Scalaの課題管理 https://github.com/scala/bug/issues
• sbtの課題管理 https://github.com/sbt/sbt/issues

これらを見てみると、自分のようにScala経験が浅くも取り組めそうなものが、ちょこちょこあります。
今年自分がScalaやsbtに送って解決につながったちょっとしたPull Requestを例として、3つだけ紹介します。

Scala: deprecatedメソッド使用時の警告の改善

まだ正式版はリリースされていませんが、Scala 2.13.0 では、数値クラスに定義された def +(x: String): String メソッドがdeprecatedになります。
もともとは、x.toString + str と書き直すように警告していたのですが、文字列補間 s"$x$str" の使用をうながす警告へ変更しました。
この変更は、Scala 2.12.5 で文字列補間が最適化されたんだからそっちを使ったほうがいいよね、というものです。

文言のちょっとした修正でしたが、最近のScalaコンパイラが文字列補間をどう効率化しているかが分かり、JVMバイトコードがちょっとだけ読めるようになりました。

sbt: 新しい警告がうるさすぎたので抑制オプションを追加

sbtのあるバージョンから、eviction warning（プロジェクトで使っているライブラリのマイナーバージョンの不一致の警告）が盛大に出るようになりました。
これは非常にわずらわしいという意見があり、自分も同感だったので、フルに警告せず、要約だけ出力するオプションを追加しました。このオプションは、sbt 1.2.0でデフォルトになりました。

正直なところ、sbtの概念や仕組みを十分に理解せず雰囲気で使っていました。
この貢献を通じて、sbtの内部をちょっとだけ理解することができました。

Scaladoc: スタイルシートでの視認性向上

Scaladocのある部分の色がブラウザによっては見づらいので、見やすくするなんていうものもありました。
これは、コンパイラやアルゴリズムは全然詳しくないですが、Webアプリ開発歴はそこそこあってCSSを書けるからこそできた貢献でした。

Scalaエンジニアと一言にいっても、さまざまなバックグラウンドがあると思います。きっと、あなたにも貢献できる課題があるはずです！

むすび

この記事をきっかけに「よし、自分も Scala の OSS に貢献してみよう」という方が１人でも増えてくれたら幸いです。
Scalaコンパイラやsbtをより速く、安全に、便利にしたり、ライブラリを速く便利にしたり、ドキュメントを読みやすく充実させたりして、楽しくScalaを使えるようにしていきましょう。
もちろん、Scala と sbt 以外にも、様々な Scala ユーザー向け OSS があなたの貢献を待っていることでしょう。
アドベントカレンダーが終えたころの冬休みに、何か取り組んでみてはいかがでしょうか。

私は、コードネーム Dotty こと Scala 3 が速く世の中に出れば、仕事で使ってる Scala.js がより書きやすくなりそうなので貢献してみようと思っています。

---

1. Scalaもsbtも、オープンソースソフトウェアとして開発されています。代替コンパイラとして Typelevel.scala や rsc がありますし、ビルドツールでは bloop や mill も登場しています。ですが本流は、やはり Scala と sbt でしょう。 ↩

2. 椅子や机、エディタやIDE、ターミナルやCLIツール、OSのディストリビューション、PCはもとよりモニタやキーボード…。これらを改善するのが好きなら、どうして普段使うプログラミング言語やそのライブラリ、ビルドツールなどを改善しないのでしょうか。ぜひともしてみるべきです。 ↩

3. 全世界のScalaエンジニアは StackOverflow や JetBrains などの統計から88万人～100万人くらいと推計されています ↩

4. この課題は最初はほんの軽い気持ちで投稿しましたが、最終的にScalaコンパイラ全オプションのドキュメントを作ることで解決しました。簡単な貢献の例ではないので本文からは外しましたが、Scala/sbt開発を率いる人たちやユーザーに喜んでもらい、やったかいがありました。また、コンパイラオプションに詳しくなり、業務コードの改善にも役立っています。 ↩