This is part 3 of sbt server integration series. I've covered VS Code and Sublime Text 3 thus far.

In this post I am going to discuss an old new problem of encoding file path as Uniform Resource Identifier (URI) reference.

As of 2017, the authoritative source of information is RFC 8089 - The "file" URI Scheme written by Matthew Kerwin.

RFC 8089 The "file" URI Scheme https://tools.ietf.org/html/rfc8089 Wow, it actually happened.

— Matthew Kerwin (@phluid61) February 18, 2017

Future readers might also want to search for "file URI scheme RFC", and find the latest version. If you're a programmer, read the RFC. This post is to raise the awareness of the some of the issues around file to URI encoding, but it's not a substitution.

Recently I've been running into interop problems as some platforms are unable to parse file:/foo/bar. But this is not the first time I'm having trouble with file path represented as URI. Considering that the notion of filesystem goes back to 1960s, and URL has been around since 1990s, it's surprising that we haven't come to a concensus on this. But then again, like decimal numbers, once you start digging deeper, or start exchanging data, we find some glitches in the Matrix.

On Tech Hub blog I demonstrated how to use sbt server from VS Code to display compiler errors from a running sbt session. In this post, I'll show how to do that for Sublime Text 3.

Over the weekend I assembled an Ergodox.

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

Wrote sbt 1.1.0-RC1 with sbt server and slash syntax on Lightbend Tech Hub blog.

It's been a month since sbt 1.0 shipped, and I can finally sit back and think about sbt server again. Using my weekends time, I started hacking on an implementation of Scala language server on top of sbt server.

In this post, I'd like to introduce a version scheme that I call Persistent Versioning. Most of the ideas presented in this post are not new or my own. Let me know if there's already a name for it.

In 2015, Jake Wharton (@JakeWharton) wrote a blog post titled 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. Rename the Java package to include the version number.

   This immediately solves the API compatibility problem from transitive dependencies on multiple versions. Classes from each can be loaded on the same classpath without interacting negatively.
   ....

   (Libraries with a major version of 0 or 1 can skip this, and only start with major version 2 and above.)

2. Include the library name as part the group ID in the Maven coordinates.

   Even for projects that have only a single artifact, including the project name in the group ID allows future updates that may introduce additional artifacts to not pollute the root namespace. In projects that have multiple artifacts from inception, it provides a means of grouping them together on artifact hosts like Maven central. ....

3. Rename the group ID in the Maven coordinates to include the version number.

   Individual group IDs prevent dependency resolution semantics to upgrade older versions to newer, incompatible ones. Each major version is resolved independently allowing transitive dependencies to be upgraded compatibly.
   ....

   (Libraries with a major version of 0 or 1 can skip this, and only start with major version 2 and above.)

In the tweet thread Jake cites RxJava's two GitHub issues Version 2.x Maven Central Identification ReactiveX/RxJava#3170 and 2.0 Package Name ReactiveX/RxJava#3173, both opened by Ben Christensen (@benjchristensen).

Wrote sbt 1.0.0 is now available on Tech Hub blog.

GitHub Pages is a convenient place to host OSS project docs.
This post explains how to use Travis CI to deploy your docs automatically on a pull request merge.

1. Generate a fresh RSA key in some directory

Make a directory outside of your project first.
Pick a key name deploy_yourproject_rsa, so you can distinguish it from other keys.

$ mkdir keys
$ cd keys
$ ssh-keygen -t rsa -b 4096 -C "yours@example.com"
Generating public/private rsa key pair.
Enter file in which to save the key (/Users/xxx/.ssh/id_rsa): deploy_website_rsa

In the last post that I wrote about Atreus build, I noted that there's an issue of keyboard positioning:

Even if I can overcome the layout and memorize the various symbol locations, there's the issue of the placement. If I place the keyboard in between me and the laptop the screen becomes too far.

I solved this issue by making a tray for Atreus that I can position it on top of the MacBook Pro keyboard.