It’s the starting of December so that means devs from all over the world gather to solve Christmas-based programming problems for the Advent of Code. Some come to sharpen skills in their main programming language, others use it to learn a new language, or as I did in years past, as preparation for tech interviews. Over the month the difficulty ramps up to thin out the herd, not unlike visiting the gym on Jan 1 vs Jan 30. Even if you don’t rush to complete the problems as fast as you can, it’s a useful exercise to look at other folks' solutions. You will probably learn about a new API or two.

I decided to use this year’s AOC as a premise to test out Project IDX. It’s a browser based development environment that comes with a bunch of pre-configured workspaces supporting common web frameworks, Flutter projects, and can create a workspace from an arbitrary GitHub repository. There is also experimental support for Android projects. IDX was announced with a waitlist in 2023 but opened up to general availability in May 2024.

The environment is VSCode based so most of your workflows will work with some caveats here and there.

My repo is mostly Kotlin code and uses Gradle, the build system for most Java, Kotlin, and Android project. This would end up being the cause of my first hiccup in running code. One way I’ll run a gradle-based project on a new machine is to install Java and use the gradle wrapper that’s bundled with a project, which will bootstrap Gradle and all its dependences. That was a bit of a nonstarter because the workspaces are spun up and down as needed and I wasn’t quite sure how to make persistent changes.

On a whim, I decided to try gradle run and see what would happen. IDX tells you gradle is not installed, advises you that can add it the the packages of your dev.nix file, and gives you a choice of which version to run. I thought I’d be able to add it at that moment by clicking OK or that gradle would be temporarily in the workspace until shutdown. It unfortunately wasn’t.

With less than sixty minutes until the first problem would unlock, I was on a frantic search to get the packages built into my workspace to avoid getting the same problems and delays on every run. GitHub projects don’t seem to have a dev.nix file created on import and my repo a bunch of difference programming challenges separated by directory so I didn’t know where exactly to put the file or the proper format. Turns out dev.nix belongs in a top-level .idx directory. With that figured out, it was pretty straight forward to add support for new languages and enable extensions from OpenVSX registry. It’s important to note that IDX deviates from a local VS Code installation. Extensions will install dutifully via the IDE flow and DO NOTHING.

My dev.nix file ended up looking like this:

In the dev environment, a clickable "Add Packages" region appears just above the packages that integrates with the command palette to allow you to search for and add packages.

With a few more edits to the dev.nix file, I was able to get the workspace close to a local VS Code but not quite. Dart code-complete works as expected without much fuss. Kotlin code-complete, usually provided by the kotlin-language-server package, seems to fail somewhat silently because it can’t find JAVA_HOME. Even after adding the openjdp package, there’s no visible error but code complete does nothing after the language server seems to start. Perhaps the needed port is being blocked by defaul. Not a deal breaker for something that sits in the realm of experimental.

Adding Java related packages to the workspace created a substantial delay in workspace initialization. Dart packages didn’t.

After spinning for a while, I would get a scare message asking if I want to switch to recovery mode. Wait a bit longer and it’s fine. I’ve been starting it up and then getting up to get water/coffee or hit the head.

I’m sure this will be addressed as Android support is worked on.

Having a remote box for dev is something I use in my day job from time to time for some large builds. You can spin up an instance, start a build, and disconnect and it’s still there. Having that remote interface has already helped me during AOC. Working from multiple computers always runs the risk that one side isn’t synced so you get weird merge conflict or have to stash things. I was working on the code on my aging and rather unstable desktop computer. It locked up and crashed during an environment rebuild. I was able to pick up my laptop and continue without having to lose or check-in partially complete work.

It’s quite there for Kotlin and could be helped a bit by creating the config dirs/files when you import a GitHub repo but the caveats haven’t chased me away…​yet.