Hacking vs. Prototyping vs. Production Code

How my personal command-line tool grew up to become a professional product

Glynn Bird
Jul 17, 2017 · 4 min read
  • If you’re making demo code that others can use as guidance, then it may be written in a clear, but oversimplified, way. In this case, legibility is more important than performance or great architecture. The code is more than “disposable” — it exists as an educational aid, rather than an exemplar of best practice.
  • If you’re building an open-source library that you’re expecting others to use and adopt, then you should have automated tests that exercise each line of code, to catch unexpected failures over time. This approach is for code that lasts the long haul.
Rugrats: All Grown Up is property of Viacom International Media Networks. Image credit: FANDOM TV Communities

The story of couchbackup

I like building command-line tools. As I’m a developer advocate for IBM, and Cloudant (an as-a-service Apache CouchDB database) falls under my purview, the tools are often for CouchDB: couchimport to import and export CSV data, couchshell to interact with your database like a command-line shell, and several others on npm. The couchbackup project is one such tool. It allows databases to be backed-up to text files and for the backup files to be restored to databases.

# backup
couchbackup --db mydatabase > mybackup.txt
# restore
cat mybackup.txt | couchrestore --db myotherdatabase

Making code production-ready

Now that couchbackup v2 has been released, I can look back and see what code was changed and the work that the libraries team did. Here's a summary of how they took my demo code and made it production-ready:

  • The code now features an automated test suite. If folks are going to rely on your tool to back up their precious data, it better do what it says it’s going to do! The codebase is still open-source, but pull requests must pass the test-suite and be reviewed by a contributor prior to acceptance.
  • The API was tweaked: parameters were combined, naming is more consistent, and it is easier to invoke a programmatic backup.
  • Events and error-handling are improved. The code behaves more predictably in error conditions. It fails fatally for permanent errors (such as authentication failure) but retries temporal errors (such as timeouts).
  • Code style rules are in place. The entire codebase is “linted” to the same standards. Machine-readable comments are in place above each function, and a greater level of consistency is applied across source code files.
  • Performance improvements: allowing extra pairs of eyes to see how an algorithm performs can lead to optimisations. Connection pooling of HTTP requests and memory usage reduction by controlling volume of data consumed from a stream are just two examples.
  • A host of bugs were fixed and features added.
  • callbacks, or Promises
  • semicolons
  • indentation
  • function lengths
  • module size
  • build tools
  • testing frameworks

Using couchbackup

You can install couchbackup on your Node.js-enabled machine with:

npm install -g @cloudant/couchbackup
couchbackup --url http://localhost:5984/mydb > mydata.txt

Credits

Thanks to Mike Rhodes, Rich Ellis, Sam Smith, and Tom Blench from the Cloudant team for all the excellent work they have put it to make couchbackup workable.

IBM CODAIT

Things we made with data at IBM’s Center for Open Source Data and AI Technologies.

Glynn Bird

Written by

Developer @ IBM. https://glynnbird.com

IBM CODAIT

Things we made with data at IBM’s Center for Open Source Data and AI Technologies.