So I have been working for NREL for about 4 months now. It has been a great place to work, and I have been given quite a bit of freedom regarding my methods for programming. Previously I had been working for Pratt and Whitney in East Hartford, CT. I had an excellent mentor by the name of John Camara there. He showed me many great things, and I wish that I had taken more time to develop my agile programming skills in East Hartford, but sometimes you need to step out on your own to realize the value in such things.

Much of my time at NREL has been spent refactoring the code which was up until this point prototype software placed in a production setting. There was little to no testing of the code, and it was hard to understand, modify and most of all, trust. Through the process of refactoring, I have determined a set of best practices which I am going to share over the course of a few blog entries. This is what I call “The Way. ” Everything from design methodologies to how code is commented will be covered. Most importantly, the use of modern testing tools will be discussed, with an emphasis on Unit Testing. Let’s begin.

First off, any good engineer knows you design something first and then start to work on it later. I’m not going to go into detail on that, but it is definitely important. I usually create a rough UML diagram for what I am working on, showing the relationship between the objects I am going to be creating. I find Omnigraffle and incredibly intuitive way to create these diagrams. The result is professional enough to show to a client or use in a presentation. What I don’t do is muddle up the design with a bunch of attributes and method definitions. I find that these things change frequently in the implementation stage, and are for the most part just details.

Here is an example from my most recent open source project:

For the python programmer, setuptools and paster have changed our lives. We now have a consistent way to develop distributable software packages, create templates for application of our libraries, and even publish our products in a general repository. Installing packages and creating dependencies on those packages which we choose to utilize is now as simple as typing one command into a prompt.

While not all of my products are open source, I use paster to create a package to develop in. Once you have easy_install installed, simply easy_install paste.

Creating a new package is as easy as:

paster create MyPackage

Paste will then prompt you with a series of questions about your new package and then set up a directory complete with an egg folder and a place for you to develop (mypackage). Once this is done you want to “install” your package so it is ready for you devlop using:

python setup.py develop

What this does is give python the correct set of links to your package. This way pathing issues are solved, and any module in your package that includes items from within itself can start with “myproject.xxx” when doing imports. This is especially valuable when you put all of your tests in a separate folder because you can run all your tests from a parent directory without worrying about running certain tests from the correct directories, it all just works.

Which brings me to the final topic about setting up my project to work. Once the project is created using paste, and installed using setup.py (a derivative of setuptools) I create a “test” folder within “myproject” which contains my tests. It is at this point, after a rough design and a project setup and install that I begin my code development.