On an MVP

Last night I stood up nomad, which is an experiment in MMS microblogging. It took a few days of thinking about, deciding on an MVP target, and getting it working. I called it Nomad because I wanted to be able to post while wandering with a minimum of overhead. It's kind of a realisation of something I've subconsciously wanted for a while...

The first step was figuring what I wanted. I've an old functional spec template from a previous EM, and I started with that. The first section of that spec is


TODO: fill this in

Describe the project in one line.

What is this project? Why are you doing it? Is it really worth the effort and time?

What related projects have been done in this space? Which ones have you tried? Why can't you use them?

The one-liner is probably one of the best tools I've found for coalescing an idea into something buildable. A huge pet peeve of mine is when I go visit a page, say a repo on Github, and it takes more than about 30 seconds to figure out what it is I'm looking at. I'm willing to give leeway for domain-specific phrasing, with the litmus test being "if I'm the intended target audience, would I understand this?" The next most useful thing is the next section of the spec, "usage sketches." Writing down the ways I expect to integrate with the thing is remarkably clarifying.

As an example of this, I was looking at Google Cloud's offerings to do some price comparisons of infrastructure, and half the time I couldn't figure out what I needed or what something was. Look at Anthos:

Improve the entire application lifecycle with fully integrated cloud services that work across on-premises and public clouds.

What does that even mean?

Anyways, I came up with my oneliner. As I started filling out some stuff, I decided I'd make this spec for the MVP. What does it look like to have the most basic thing? How could I tell if this was something that was actually useful in practice? So I did. There's a lot I'm punting on. But... there's this. It works, I was able to do what I wanted - post an image on the bus this morning, no fuss.

Here's a list of things I punted on:

  1. Developing an actual schema. I used sqlalchemy to generate a schema for the whole two tables I'm using right now.
  2. Image storage: they're in the database. Yes, I know this is a bad idea. It's a bad idea when you have a bunch of photos and a lot of traffic. I don't. Here's what I didn't have to figure out: how to upload and store photos, how to provide an HTTPS link to those photos. It also means I can scp the database to back it up and have all the images. Images are embedded directly into the page as base64'd data. This isn't tenable for long, but it works for now.
  3. Automated deployments. I push to git, and on the remote host, I git pull and service restart nomad && tail -f nomad.log. Brute force, but I decided to get something running before figuring out the ops side. I read just enough to get uWSGI working, wrote a systemd service unit, and there ya go.
  4. User management. You can't log in. You can't register. Adding users is done with INSERT INTO users (short, full, tel) values ( 'kyle', 'Kyle', '+12125554202');. There's also only two of us right now.
  5. Paginating. The front page just shows the 10 most recent posts.
  6. Doing a ton of testing. I used pickle to store a few snapshots of data at critical times to test message parsing and I test image resizing. This kind of hurt because I ended up just having to send a ton of texts to Twilio to test it out.
  7. Styling. I stole the stylesheet from here. There's a bunch of stuff I'm not using. The stylesheet could use a lot of trimming, and really I should just do my own.

It was really just a night of hacking this together, so there's that.

Tags: ,