The last couple of weeks have been very hectic as I’ve been working full-speed on making Rulette Server ready for its first big release. A lot of code has been written, but it turns out that code is easy (relatively speaking). I want to offer a top-notch user-experience for Rulette server from day-1 (something I didn’t do well with Rulette SDK). So I’ve built a pre-launch checklist focussing on developer and first-time user experience that I’m going through now. I thought I’ll share some of these things with you today, and share some early bird views.

Fixing Rulette

Turns out that although Rulette has been out there for over 5 years now, it still had a bunch of bugs, which had to be fixed first. Finding and fixing these was great because Rulette is a much better product now, but I’m also thinking testing-someting-something.

Enhancing Rulette

The big gap between Rulette and Rulette server turned out to be that the Rulette works well as an SDK (which it is-makes sense), but does not expose a lot of functionality that is super-cool to have in an API server/admin UI. You couldn’t add/delete rules systems or rule inputs because it was assumed that the user of the SDK sets up the rule system separately behind the data provider implementation and then uses Rulette to simply access the data. But admin actions in the Rulette API/UI demand that all of this stuff be exposed via API. So I spent a lot of time adding these capabilities to Rulette itself.

Then I exposed these properties over the REST API and built them into the UI, ended up redoing a whole bunch of stuff because I realized a little too late that providers had to be a first-class, public construct for namespacing purposes. Without this, two rule system created under different provider but with the same name would overwrite each other.

Building the homepage

I want a single place where Rulette SDK, server, documentation, articles, and news can find a common home. So I’m creating spaces for all these on my personal website and will get rulette.org to point to it. This has all the complexity of setting up a small website (figure out layout, customize pages, prepare and arrange content, optimize for mobile etc etc).

Extensive documentation

The documentation on Rulette SDK and server is kind-of slim so far. So I started writing detailed documentation which explains the concepts, the usage, and the internal design of Rulette. I started out writing these docs on the website, but this thing grew and grew and currently stands at ~50 pages of detailed documentation, UI walkthrough and case studies (one down, one more to go).

Turns out writing good documentation is insanely hard – I come back after a break and realize that what I had written is not as clear as I thought it was. Re-phrase, re-organize, repeat. Checkout the current draft here – I’m planning to re-do it in Apple Pages and make it available for download as a PDF.

Docker and Public API

I really like how Zipkin (and others) offer a docker image right on their website for people to get started quickly. I wanted the same experience for Rulette server users – so I learnt a little bit about Docker and published the docker image for Rulette server on DockerHub. Figuring out Docker took a while, publishing the image itself was super easy. Similarly, Swagger API is available on SwaggerHub.

Live instance

Documentation is great, but nothing beats the real thing. I’m going to set up a live instance of rulette server with some dummy data so that users can play around with it and get a feel for its awesomeness.

Support

Making Rulette a saleable product has been top of mind for me for some time now. So I’m going to try several different ways of doing this with Rulette server release. Soliciting support on Patreon, self-publishing the user’s manual on Kindle (coming soon), and taking direct donation on the website are some early ideas. If you have seen/used and liked Rulette, I’d love to hear more ideas around this.

A whole lot is going, and the goal is to finish everything in one more week.

Stay Tuned!