I’ve recently been playing around with some cloud development tooling by a startup named Pulumi, and I thought I’d write up my first impressions.

Pulumi can be summed up as “Infrastructure as Code – but really, we mean it this time.” Instead of mucking around with YAML files and proprietary syntax, you define the infrastructure you need in actual code (JavaScript or Python, with more languages coming later). Is your production environment slightly different from your test environment? No problem, that’s just an if statement (or a more complex abstraction) away.

It’s still very early days (as of this writing, Pulumi is on version 0.14.3), but the general approach shows a ton of promise.

In my spare time I have been mucking around with 2 big Functions-as-a-Service (FaaS) offerings, AWS Lambda and Azure Functions. I’ve been meaning to write up a “The state of serverless development” post, but today Mike Roberts updated his overview of the market for serverless computing and it’s far more thorough than I could ever be.

The whole thing is well worth a read if you’re interested in the area, but these parts (emphasis mine) really resonated with me:

Serverless is not the correct approach for every problem, so be wary of anyone who says it will replace all of your existing architectures. Be careful if you take the plunge into Serverless systems now, especially in the FaaS realm. While there are riches — of scaling and saved deployment effort — to be plundered, there also be dragons — of debugging and monitoring — lurking right around the next corner.

Serverless services, and our understanding of how to use them, are today (May 2018) in the “slightly awkward teenage years” of maturity. There will be many advances in the field over the coming years, and it will be fascinating to see how Serverless fits into our architectural toolkit.

This is exactly right in my experience.

Lambda and Azure Functions let you write+deploy code quickly without an infrastructure team and an execution platform. However, the developer experience is often a big step backwards – Lambda doesn’t offer any remote debugging support, and just running+debugging functions locally is a big pain. Azure is further ahead in debugging, but things are still more complicated and less reliable than when debugging traditional apps. Integration testing is difficult on both platforms.

I recently built a web tool to solve a simple question that comes up often in urban planning: after taking setback requirements into account, how much of lot can be built on? The answer is often surprising: for example, Vancouver’s most common residential zone only allows houses to cover about 28% of the land.

It was a fun weekend project, and a few weeks later I decided to upgrade it on a long plane ride. It’s now a neighbourhood-level simulator with many more parameters:

These are mobile and desktop-friendly, and the visualization is entirely done in the browser. Here’s how it all works.

I’m a member of a nonprofit called Abundant Housing Vancouver, and as you can probably tell, I happen to do some programming too. In 2017 I was able to spend a lot of time combining these interests which was pretty great!

Over a few blog posts I’ll briefly outline the projects I worked on – they’re all open source and who knows, they might even be useful for other housing advocacy groups someday. First up: the Abundant Housing Vancouver Letter Builder.

I’m building an interactive online map of all properties in Vancouver, and along the way there have been a few pleasant surprises. Most recently: the .MBTiles tileset format is surprisingly cool.

Background

Mapbox is one of the biggest players in the open source mapping space (especially now that Mapzen and Carto have thrown in the towel – Mapzen is closing and Carto is now using Mapbox tech). One of the many nice things about Mapbox is that they developed an efficient open standard for vector map tiles, appropriately named Mapbox Vector Tiles (read this if you’re not sure why vector tiles are great).

Map tiles are often pre-computed for each zoom level, and once you’ve done that you need to store them somewhere. Enter the .MBTiles tileset format.

Poking around under the hood

My first encounter with this file format occurred when I used Eric Fischer’s excellent tippecanoe tool to simplify my data set at lower zoom levels. Tippecanoe generates .mbtiles files, which are easy to serve to clients either by uploading to Mapbox, using a third party tile server, or even by rolling your own server with something like the mbtiles Node.js package.

All great… but after setting up a server my Mapbox GL JS client refused to render the tiles. I tried a few things without much luck, and then as a last resort I decided to poke around in the .mbtiles file. I was expecting to need a hex editor or similar, but then I saw this beauty in the spec:

MBTiles is a specification for storing tiled map data in SQLite databases

The files themselves are just relational databases in a known schema – how cool is that? Emboldened, I grabbed a SQLite client and opened up my .mbtiles file: