scala

warning: Creating default object from empty value in /opt/bitnami/apps/portal/htdocs/modules/taxonomy/taxonomy.pages.inc on line 33.

ScalaMatsuri 2020 におけるハッカソンの仮想化

in

本稿は ScalaMatsuri Day 2 アンカンファレンスで OSS ハッカソンを仮想化したことのレポートだ。誰かがアンカンファレンスのトピックとして提案したらしく、僕は朝会でファシリテーターとして申し出ただけなので事前準備は特に無し。元々は 4時間 (JST 正午 - 4pm、EDT 11pm - 3am) で枠をもらったが、うまく回ったのでコーヒーブレイクの後も数時間続いた。

アンカンファレンスをやるときにいつも強調してるのは「二本足の法則」で:

いつでも自分にとってその場からの「学び」や自分から場への「貢献」が無いなと感じた場合: 自分の二本足を使って別の場へ移動すること

オンラインのアンカンファレンスで、複数のセッションが行われているので別のトークを見るために抜けたり途中から参加することは自由であることを事前に伝えた。

自由、平等、ボックス化されたプリミティブ型

in

ScalaMatsuri 2020 で '自由、平等、ボックス化されたプリミティブ型' というトークで登壇しました。

Jar Jar Abrams

in

Jar Jar Abrams は、Java ライブラリをシェーディングするユーティリティである Jar Jar Links の実験的 Scala 拡張だ。

ライブラリ作者にとって他のライブラリは諸刃の剣だ。他のライブラリを使うことは作業の二重化を避け、他のライブラリを使いたくないというのはダブルスタンダードと言われかねない。しかし、その一方で、ライブラリを追加する度にそれはユーザ側にすると間接的依存性が追加されたことになり、衝突が起こる可能性も上がることになる。これは単一のプログラム内において 1つのバージョンのライブラリしか持てないことにもよる。

このような衝突はプログラムがランタイムやフレームワーク上で実行される場合によく起こる。sbt プラグインがその例だ。Spark もそう。1つの緩和策として間接的ライブラリを自分のパッケージの中にシェーディングするという方法がある。2004年に herbyderby (Chris Nokleberg) さんは Jar Jar Links というライブラリを再パッケージ化するツールを作った。

Scala におけるユーザランドでのコンパイラ警告

in

一ライブラリ作者として、Scala でメソッドをタグ付けしてカスタムのコンパイラ警告やエラーを発動できるといいなと前から思っている。先週末 #8820 を scala/scala に送って @apiStatus というユーザーランドでコンパイラ警告やエラーを出せる仕組みを再提案した。

依存性解決のセマンティクス

in

依存性解決のセマンティクスは、ユーザーが指定した依存性の制約から具象クラスパスを決定する。詳細の違いはバージョン衝突の解決のされ方の違いとして表れる。

  • Maven は nearest-wins 戦略を取り、これは間接依存性をダウングレードすることがある。
  • Ivy は latest-wins 戦略を取る。
  • Cousier は一般的には latest-wins 戦略を取るが、バージョン範囲の計算は厳しい。
  • Ivy のバージョン範囲の処理は Internet へ出てしまうため、ビルドの再現性が落ちる。
  • Coursier のバージョン順序は Ivy と全く異なるものなので注意。

Expecty 0.12.0 and 0.13.0

in

君達の JDK は全て SDKMAN! がいただいた

in

これは Travis CI に自分で JDK をインストールする解説の第2弾だ。以前は、jabba を紹介した。

今日は SDKMAN!, という、Marco Vermeulen (@marc0der) さんが作った元気な名前のツールを見ていく。これは、JDK の他にも Groovy、Spark、sbt など JVM 上の様々なツールを対象とする環境マネージャーだ。

AdoptOpenJDK 11 と 8

2020-09-23 更新: バージョン番号の正規表現を更新した。
2019-11-06 更新: SDKMAN の更新プロンプトが CI をブロックするのを回避するために sdkman_auto_selfupdate を追加した。また、sdk install の行に || true を追加した。

scopt 4

in

scopt 4 における関数型 DSL は以下のようになる:

import scopt.OParser
val builder = OParser.builder[Config]
val parser1 = {
  import builder._
  OParser.sequence(
    programName("scopt"),
    head("scopt", "4.x"),
    // option -f, --foo
    opt[Int]('f', "foo")
      .action((x, c) => c.copy(foo = x))
      .text("foo is an integer property"),
    // more options here...
  )
}
 
// OParser.parse returns Option[Config]
OParser.parse(parser1, args, Config()) match {
  case Some(config) =>
    // do something
  case _ =>
    // arguments are bad, error message will have been displayed
}

OptionParser 内でメソッドを呼ぶのではなく、関数型 DSL はまず特定の Config データ型に対するビルダーを作って、opt[A](...) など Oparser[A, Config] を返す関数を呼ぶ。

これらの OParser[A, Config] パーサーは OParser.sequence(...) を用いて合成できる。

最初は for 内包表記を使ってこの合成を表すことも考えていたが、その見た目に慣れて人にとっては分かりづらいと思ったので sequence 関数を作った。

scala.Seq のマスキング

in

現行の Scala 2.13.0-M5 のままで行くと、scala.Seqscala.collection.Seq から scala.collection.immutable.Seq に変更される予定だ。Scala 2.13 collections rework に何故今まで不変じゃなかったのかの解説が少し書かれている。行間から推し量ると、scala.Seq がデフォルトで不変になることを喜ぶべきだと言っているんだと思う。

デフォルトで列が不変になることはアプリや新しく書かれるコードには良いことだと思う。ライブラリ作者にとってはもう少しこみいっているかもしれない。

  • あなたがクロスビルドされたライブラリを持っていて
  • ライブラリのユーザも複数の Scala バージョンを使っていて
  • ライブラリのユーザが Array(...) を使っていた場合

この不変 Seq への変更は、breaking change つまり非互換な API 変更となりうる。

-Xlint, -Xfatal-warnings, そして Scalafix を用いた Scala の厳格化

in

コンパイルする、さもなければコンパイルしない。警告などいらない。最近気に入っている Scala コンパイラのフラグは "-Xlint""-Xfatal-warnings" の 2つだ。

以下は、サブプロジェクトと共に使えるセッティングの例だ:

ThisBuild / scalaVersion := "2.12.6"
 
lazy val commonSettings = List(
  scalacOptions ++= Seq(
    "-encoding", "utf8",
    "-deprecation",
    "-unchecked",
    "-Xlint",
    "-feature",
    "-language:existentials",
    "-language:experimental.macros",
    "-language:higherKinds",
    "-language:implicitConversions"
  ),
  scalacOptions ++= (scalaVersion.value match {
Syndicate content