猫番: 17日目を書いた。始対象と終対象、積、双対性、余積など抽象構造を見ていきつつ、Either を coproduct として使う方法を紹介します。

sbt server 統合シリーズ・パート3 は Neovim だ。これまでに VS Code とSublime Text 3 をカバーした。

本稿では古くて新しい問題であるファイルパスの Uniform Resource Identifier (URI) へのエンコード方法について議論する。

2017年現在、権威ある情報の元は RFC 8089 - The "file" URI Scheme だ。未来の読者の人は "file URI scheme RFC" で検索して最新版を探してほしい。プログラマの人は RFC を読んで下さい。この覚え書きは URI エンコーディングに関連した問題の認識を高めるためのものだが、RFC の代替とはならない。

最近 file:/foo/bar がパースできないというプラットフォーム間の相互乗り入れ問題に出くわした。ファイルパスを URI として表現するのに関連した問題に悩まされるのはこれが最初でもない。ファイルシステムという概念は 1960年代に遡り、1990年代から URL があることを考えると、このコンセンサスが取れていないというのは意外なことだ。しかし、十進法小数のように、深く掘り下げたり、データを交換しはじめると、Matrix　のほころびが見えてくるのかもしれない。

Tech Hub blog にて sbt server を VS Code と併用して実行中の sbt セッションからコンパイラエラーを表示できることをデモした。本稿では Sublime Text 3 でそれをやってみる。

週末にほったらかしていた Ergodox を組み立てた。

• Infinity ErgoDox Ergonomic Keyboard Kit via massdrop
• Cherry MX Brown スイッチ
• Datamancer Infinity Ergodox Hardwood Case (Black Walnut / Original) via massdrop
• Plum Blossom PBT Dye-Subbed Keycap Set (OEM, Blank) via massdrop

Lightbend の技術系ブログ Tech Hub blog に sbt 1.1.0-RC1 with sbt server and slash syntax という記事を書いたので、訳しました。

@eed3si9n 著

皆さんこんにちは。Lightbend Tooling team にかわって sbt 1.1.0-RC1 をアナウンスします。これは、sbt 1 初のフィーチャーリリースで、バイナリ互換性は維持しつつ新機能にフォーカスを当てたリリースとなっている。
sbt 1 は Semantic Versioning にもとづいてリリースされるので、プラグインは sbt 1.x シリーズ中機能することが期待されている。2017年12月14日までに大きな問題が見つからなければ、1.1.0-RC1 は 1.0.0 final 版となる予定だ。

sbt 1.1 の主な新機能は統一スラッシュ構文 (unified slash syntax) と sbt server だ。これらは両方とも僕が個人的にしばらく関わってきた機能だが、sbt 1.0 には入れずに延期させたものだ。そのため、やっとこれらを世に出せるのがひとしお嬉しい。

Lightbend の技術系ブログ Tech Hub blog に sbt 1.0.4 hotfix and the performance fixes という記事を書いたので、訳しました。

@eed3si9n) 著

皆さんこんにちは。アメリカに住んでいる人たちは、良い感謝祭 (Thanksgiving) の連休すごせたでしょうか。
遠くからの親戚や友達が集まって食事を作ったり、小咄を交わす年中行事という意味では、日本の正月休みに近いものがあると思う。

あと、sbt 1.0.4 をリリースしたこともアナウンスします。これは sbt 1.0.x シリーズの hotfix で、バグ修正にフォーカスを当てたバイナリ互換リリースだ。
sbt 1 は Semantic Versioning にもとづいてリリースされるので、プラグインは sbt 1.x シリーズ中機能することが期待されている。

パフォーマンスデグレの修正

Lightbend の技術系ブログ Tech Hub blog に sbt 1 migration status and 1.0.2 hotfix という記事書いたので、訳しました。

@eed3si9n 著

こんにちは。sbt 1.0.0 リリース後に何があったかのレポートだ。

僕たちの sbt 1 へのマイグレーションのプランは以下のようになっている:

• sbt 1.0.0 をリリースする。
• コミュニティーの皆さんと一緒にプラグインを全部移行させる。
• バグを修正する。
• ライブラリのビルドを移行させる。

プラグインの移行

sbt 1.0 がリリースされてからもう一ヶ月になり、やっと少し落ち着いて sbt server のことを考えれるようになった。週末の時間をさいて最近 Scala language server (言語サーバー) を sbt server 上にハックしている。

本稿では、僕が Persistent Versioning と呼んでるバージョン方法を紹介する。本稿中に出てくるアイディアの多くは新しくもなければ僕が考案したものでもない。既に名前があるならば是非教えてほしい。

2015年に Jake Wharton (@JakeWharton) さんが メジャーバージョンアップデートのための Java 相互互換方針 (Java Interoperability Policy for Major Version Updates) というブログ記事を書いた:

A new policy from @jessewilson and I for the libraries we work on to ensure major version updates are interoperable: https://t.co/zKqYRwrXmq

— Jake Wharton (@JakeWharton) December 11, 2015

1. Java パッケージ名にバージョン番号を含むように名前を変える。

   これによって、間接的依存ライブラリが複数のバージョンを持つ場合の API 互換性の問題が即時に解決する。同じクラスパスから各々のクラスを相互干渉することなく読み込むことができる。(中略)
   (メジャーバージョンが 0 か 1 のライブラリはこの方針を飛ばして、メジャーバージョンが 2 に上がってから始めてもいい。)

2. Maven 座標の group ID の一部としてライブラリ名を含ませること。

   たとえ単一のアーティファクトしか持たないプロジェクトでも、group ID にプロジェクト名を入れておくと将来的に複数のアーティファクトを持ったときにルートの名前空間を散らかさなくてもいい。最初から複数のアーティファクトを持つ場合は、Maven Central などにおいてアーティファクトをまとめる方法となる。 ....

3. Maven 座標中の group ID にバージョン番号を含むように名前を変える。

   独立した group ID を持たせることで依存性解決のセマンティクスが古いバージョンを新しい非互換なものにアップグレードさせることを予防する。メジャーバージョンはそれぞれ独立して解決され、間接的依存性が互換性を保ちながらアップグレードされるようになる。(中略)

   (メジャーバージョンが 0 か 1 のライブラリはこの方針を飛ばして、メジャーバージョンが 2 に上がってから始めてもいい。)

上記の tweet のスレッドでは Jake さんは RxJava の 2つの GitHub イッシュー Version 2.x Maven Central Identification ReactiveX/RxJava#3170 と 2.0 Package Name ReactiveX/RxJava#3173 に言及していて、それらは Ben Christensen (@benjchristensen) さんにより開かれている。