###############################################################################

      *****************        Hey! Welcome to the Kwoosh Workshop
     *******************       -----------------------------------
    *******  *****  *****
   ********  ****  *******     This is where we talk about the things
  *********  ***  *********    we're working on.
 **********  **  ***********
***********     *************  Most things start as messy ideas before
 **********  **  ***********   they get polished into finished features.
  *********  ***  *********
   ********  ****  *******     This is a place for messy ideas.
    *******  *****  *****
     *******************       For the completed product see kwoosh.com
      *****************

###############################################################################

Making solid software

With our recent rewrite toVueand a soft launch ofKwoosh, we’re finally able to use Kwoosh again. With any major rewrite or change you’re going to find bugs or other bits that didn’t quite work as intended. Often these bugs are just oversights in our implementation. We didn’t think about how to handle some detail.

In Kwoosh there are three basic types of users that will use the system: Anonymous Users, Users with a confirmed email address, and Users without a confirmed email address. Some pages in Kwoosh should only be visible to Unconfirmed users, for example the “please confirm your account” page.

To help us quickily and easily allow views to only be visible by unconfirmed users we made a simple view decorator in Python that’s used like below:

Once the code was in production we realzied we overlooked a user-class in our implementation: AnonymousUsers might hit these URLs too and we weren’t handling that case. My initial urge was to fix the bug and move on to more interesting features. Instead I ate my vegtables and decided to use our new testing setup and write some tests for our decorator.

It took me a bit longer to sit figure out how to minimally test our decorators than just fixing the bug itself. By iterating through possible solutions for the test I found some gaps in my initial fix.

The end result is better code, confidence that thie error won’t occur again, which allows me to rest easy knowing that if it crops up again, we’ll catch it before it gets to produdtion.

Getting into the habit of adding tests for every 500 that occurs in prodution is an excellent method to increase the quality and reliability of your software.

—jvd