Minimum Viable Reports: A NodeJS Script And console.log

I’ve spent around 2 months building SignalLeaf, so far. It’s all after-hours and weekends, but I got the job done … well… I got a minimum viable product done. I at least solved some pain that I had been seeing in the land of podcasting. Along the way, I focused almost exclusively on the features that users would be working with to create podcasts, add episodes, setup RSS feeds and get a very basic amount of traffic information for an episode. This is all great from the user’s perspective. It’s things that podcasters need in order to get their job done. But along the way, I have purposely neglected the back-end system – the code and feature sets that *I* need in order to understand how my app is shaping up and manage it. But I realized something today: if I’m looking for the minimum deliverable and I’m looking at creating a service for the users first and for myself second, I really don’t need to spend a lot of time building a fancy set of pages that I can see from the web site directly. In fact, I don’t need much of any code to start with, for the back-end. After all, I have code that I can run from my machine and grab data from the production database, so why not do that? Why not create a minimum viable report to show me the information I need?

Minimum Viable Report

The first thing I want to know is how many customer accounts and podcasts I have in SignalLeaf. This will give me some idea of how well I’m doing w/ marketing effort, feature advertisement, pricing, etc. It’s not going to give me much, but it’s a start and it at least feeds my vanity metic of having customers. Rather than spend a lot of time building out an administrative back-end for my app, though, I decided to just hack together a quick script that gives me the information I need. I really just wanted to see without having to go through MongoDB’s command line tools directly. 

So I built this little script:

var epa = require("../web/epa");
var db = require("../web/db");
var Accounts = require("../web/accounts");

db.connect(epa.mongo, function(err){
  if (err){ throw err; }

  Accounts.Account.find(function(err, accounts){
    if (err) { throw err; }

    var podcastCount = accounts.reduce(function(sum, acc){
      return sum + acc.podcasts.length;
    }, 0);

    console.log("# Of Accounts:", accounts.length);
    console.log("# Of Podcasts:", podcastCount);

    done();
  });
});

function done(){
  process.exit();
}

And that’s it. It’s just an import of my system’s basic modules, a database connection, a query to get some information and then aggregating that information in to a simple console.log output. To run my report, I just run “node customers.js” and it will connect to my local database. If I want to run it against production, I only need to set “NODE_ENV=production” prior to running the script and BAM! I have a report of my production app:

Screen Shot 2013 10 18 at 8 24 11 PM

(Yes, I know this is a meagerly pathetic # of accounts and podcasts. But that’s not the point.)

Iterating, Scaling, Improving

One of the things that I like the most about this, is being able to hack together any script I want and get information I want, quickly. I don’t have to worry about designing a proper report format. I don’t have to worry about creating a bunch of HTML, route handlers, and other things involved in getting a real report setup on the site. I can hack a script, iterate, fix it, run it as needed and move on.

Of course, this type of reporting doesn’t scale to more than just administrative people with direct access to the code and database – which is really just me, anyways. But it does get me down the path of being able to see the information I need, when I need it, and moving on to the next feature that my customers need. 

From here, I’ll be able to tweak the core of the reports to get the information I really do need. Then once I have some of the basics done and ready to roll, I’ll be able to work on the UI side of things and already have the data available.


Post Footer automatically generated by Add Post Footer Plugin for wordpress.

About Derick Bailey

Derick Bailey is an entrepreneur, problem solver (and creator? :P ), software developer, screecaster, writer, blogger, speaker and technology leader in central Texas (north of Austin). He runs SignalLeaf.com - the amazingly awesome podcast audio hosting service that everyone should be using, and WatchMeCode.net where he throws down the JavaScript gauntlets to get you up to speed. He has been a professional software developer since the late 90's, and has been writing code since the late 80's. Find me on twitter: @derickbailey, @mutedsolutions, @backbonejsclass Find me on the web: SignalLeaf, WatchMeCode, Kendo UI blog, MarionetteJS, My Github profile, On Google+.
This entry was posted in Continuous Improvement, Javascript, Pragmatism, Productivity, SignalLeaf. Bookmark the permalink. Follow any comments here with the RSS feed for this post.
  • JanVanRyswyck

    Why the process.exit()? Isn’t the process destined to exit as soon as there are no more events in the event loop?

    • http://mutedsolutions.com Derick Bailey

      Normally yes, but the db.connect call makes it hang around pretty much forever, with an open database connection.

  • NathanGonzalez

    I wish i had a problem like this. i’ve been wanting an excuse to learn more about R, and this seems like a perfect fit.