Subscribed unsubscribe Subscribe Subscribe

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

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

Scala Advent Calendar 2017 について & sbt console を -Xfatal-warnings & -Ywarn-unused-import で使う

ポエム Scala

この記事は Scala Advent Calendar 2016、25 日目の記事です。

今年は Scala Advent Calendar が二か所、Adventar と Qiita の二つのサービスで開催されました。今年も、という方が文脈的には正しいかもしれません。

http://www.adventar.org/calendars/1492

http://qiita.com/advent-calendar/2016/scala

文脈としては、毎年どっちにしようか、と gitter の scalajp/public 等の Scala のコミュニティの一部で悩んでいるうちに、両方で作られちゃって、さあどうしよう、まあいいんじゃない?みたいになる、という流れです。

とりあえず 2016 年分について、2016/12/31 現在の様子を画像で残しておこうと思います。

Adventar

f:id:lyrical_logical:20161231161100p:plain

Qiita

f:id:lyrical_logical:20161231161013p:plain

Scala は本当にここ数年で知名度が上がりました。とはいえ、当然二か所で開催すれば 50 日分を埋めるのは大変です。

Adventar は登録者が全く足りていません。まだ書かれていない日付もありますね。

Qiita はサービスが SEO 頑張ってることもあってか(ご苦労様です)、登録者は埋まっています。が、まあこれから乗っ取るんですが、最終日である 25 日他、数日分が書かれていません。
ちなみに最終日を乗っ取るのは、単純に、来年カレンダーを(特に Qiita 側で)作る人の目に留まりやすいかな、というだけです。他の日でも、Adventar の空いてる日でも、なんなら Advent Calendar として書かなくてもいんですが、一応。

年が変わるまで(あと 7 時間…)、もしくは年が変わってから記事を遅れて書かれる方もいるかもしれませんが、矢張り年内には埋めたいですし、今の状況はとても悲しいものがあります。他の言語や何らかの Advent Calendar が穴あきだったり記事が書かれていなかったりして残念だなと思ったことはありませんか?Scala もそうなっているのが現状です。

サービスの機能を使って Advent Calendar を作ることなんてユーザの自由だ、という主張もあると思いますが、Scala という名前を冠している以上は、コミュニティの一員である、そうであると見做されることを意識してもらう必要はあると思います。

ということで、来年こそはしっかりカレンダーを埋められるように、本来の Advent Clanedra のように毎日ワクワクできるように、カレンダーを作る人はカレンダーを作る前にコミュニティに相談をするなり、コミュニティはコミュニティで先手を取って両方作っておいて片方のサービスからもう片方のサービスへ「今年はこちらのサービスで開催しています」とフォワーディングして対応をとるなり(案の一つです)、何らかの手を打つべきだと思います。

(これは余談ですが、Scala という言語は知名度が上がった割に形の定まったコミュニティというのがないので、このようなことになりやすいのかなという気がします。そういうコミュニティのほうがいいのかどうかは別の話なので、この話はここで終わりです)

Scala 2.12 のリリースは当初の予定より本当に本当に大幅に遅れましたが、それでもちゃんとリリースされました。2017 年はライブラリの 2.12 対応も進み、本格的に Scala 2.12 が使われていく年になるのではないかと思っています。躍進の年にしたいですね。
実務での採用例も一気に増えて…るんじゃないかなあ。自分の話になってしまいますが、今年夏から冬にかけて、色々な会社へお仕事の相談をさせて貰いに行ったりしたのですが、割とどこへ行っても ScalaScala でした。別に自分は Scala で営業してるわけでもないので、行く先々で ScalaScala 言われているといった感じでした。皆 Functinal だとか Resilience だとか reactive だとかに騙さ…なんでもないです。FP は fun & functional だし Resilience は大事だし reactive はサイコー、いいね?

技術的な話がないけれど、Qiita 外の記事だから大丈夫かな?良いお年を!



…やっぱり何かちょっとした Tips 位は書こう。

Scala の警告は、基本的には probably bug です(設定で警告増やしたりできますが)。ので、"-Xfatal-warnings" コンパイルオプションを付けている人は多いと思います。
この時に困るのが、sbt のプロジェクトでそのような設定をしている場合、特によくあるのが "-Ywarn-unused-import" コンパイルオプション等と組み合わさって、sbt の console タスクが使い物にならなくなることです。
これを回避するには、sbt の scalacOption キーに以下のような変更を加えることです。

scalacOption in (Compile, console) -= "-Ywarn-unused-import"

これで、Compile スコープの console タスクにおける scalacOption からは "-Ywarn-unused-import" が取り除かれ、sbt console も無事使えるようになります。万歳。
この話は一応 stackoverflow 等で昔から広まっている知見なのですが、stackoverflow と違う点としては、シーケンシャルな値を扱う SettingKey に対して "-=" メソッドが使えるように sbt が改善されたのを受けて、記述がスマートになっている、という点でしょうか。逆にいうと、この設定(コードですが)が通らなかったら、それなりに古いバージョンの sbt を使ってるということなので、バージョンアップを考えましょう。
これで技術記事としての体裁も保てられるかな?では今度こそ、良いお年を!