In a programmer’s mind

A small robot giving you a hand by woordenaar

The time has come to get out of the integrated development environment mindset. Software development should not be based on a monolithic piece of software like the IDE. In the beginning, I though it was great to have all those tools within a click away easy access but the more I think about it, the more I am repulsed by it. I want to be independent from that easy build button. It seems like it does not find with that mindset.

In my never ending quest for better software quality, I got interested by the continuous integration process. Before getting too deep with the matter, let’s try to define what is the integration process in a software development. Integration happens when you make a change to your software and you want to make sure everything works with the software you had before and that your change conforms to some quality standards. A change can be a lot of different things like adding a simple message, adding a module, changing the colour of a box or refactoring your whole application. It can be while starting up your project and developing it, it can be a change during the beta phase or it can be an emergency bug correction for a running application. Whatever is changed, however it is done and wherever it goes, you want to make sure it does work.

Integration can be quite easy for small projects with small changes while being quite hard for large projects with big changes. Continuous integration is about making that process an incremental, routinely done, automated and simple thing to do.

How do it works? You will often have one or many dedicated servers waiting for changes to be included in the source control management system. It can be with a hookup script or with a pull process. Often, you will also see some of those continuous integration servers setup to run some task at predetermined intervals like every midnight. Whether is it event based or scheduled, they will most likely run one or more of the following tasks:

• Building the source
• Running unit tests
• Running a code coverage analysis
• Running a code analysis for standards conformity
• Running a performance analysis
• Generating code from a model
• Building the documentation
• Deploying the results on a test server

For each task, the server will keep a report on what happened, how did it go and what are the results. For instance, for the unit tests task, you might want to have a report with how many tests succeeded, how many failed and which one failed. A concrete example would be the waterfall view for the Google Chrome continuous integration process.

There are many advantages to use a continuous integration process. The most important one is to find bugs early and correct them early.

Let’s say you configured your continuous integration server to build your source whenever you commit a change in your source control management system. If you commit a change that breaks the build process, you can be notified quickly that you did something wrong and correct it. The cost of correcting a bug is often proportional with the length of time from the moment it was introduced to the moment it was found.

There are many solutions both open source, free and commercial ones available to fill your needs. BuildBot, CruiseControl are some of the popular ones. A simple script might also be the best thing for you is not much is wanted.

With the quality goal in mind, a proper continuous integration process is a must.

The big dreaded spaghetti monster by St. Murse

Software quality is an interesting topic to me. It is what is often missing in many projects that transform them into bloated unmaintainable big spaghetti monsters. Every programmer with some kind of experience knows what it is to work on those software. If you do not, it is unpleasant to say the least.

I have been reading different articles and blogs about my new favorite language, Python. Many of them come to the conclusion that Python is a weaker language because it does not report compilation errors like many other languages do. Accordingly, it makes Python a less suitable candidate to build quality software.

First, let me say that it is possible to build high quality software with Python. This also applies to other similar programming languages supporting a fully dynamic type system. It is true that Python will not return type related errors when compiled. The reason is that Python code is mainly interpreted and does not enforce a static type system. It is possible to compile Python code, but you will likely end up with byte code that will have to be interpreted later on (with a possible speed gain). For instance, let’s take the following code:

if __name__ == "__main__":
    z = 2 + "22"
    z.addtwelve()
    print z

You can compile that code by placing it in a file called add.py with the following statements:

import py_compile
py_compile.compile("add.py")

With CPython, which is a common python implementation, you would get a file named add.pyc in the same directory that would contain a byte code representation of the add.py file. The compilation would not report any error. In any case, trying to run either add.py or add.pyc would result in the following error:

Traceback (most recent call last):
  File "add.py", line 4, in
    z = 2 + "22"
TypeError: unsupported operand type(s) for +: 'int' and 'str'

This example demonstrates that Python does enforce a strong type system but you have to actually execute your code to find out about type errors.

Type errors are one kind of error that are usually found at compile time in other languages like Java, C# or C++ that are not found by Python at compile time. There are also missing import errors, undefined classes, undefined methods, undefined functions, undefined operations, undefined variables and many others. In order to build a quality software, you should be able to find out about those errors before using it.

With Python, the solution to this problem seems too simple to be just that. You have to run your code and you have to run every statements. Not only will you find out about those errors, but you will also find many runtime errors.

Running your whole application before using it

A great deal of software quality is made possible by using different tools. I will try to present some of those tools that I wish would always be part of every new software projects.

A good way to run your code is to write unit tests for it. Running those tests will make you run your application without having to actually use it which does simplify the task of running your code. If you do not know about unit testing, I strongly suggest that you have a look around the web to find out what it is and how it can help you. You can also have a look at an introduction I wrote a few weeks ago.

Another question that will probably be raised in your mind is how it is possible to know that you have ran your whole application or every statements in it. This is made possible by code coverage tools.

Code coverage tools are able to analyze how much of your code and which parts has been executed by a defined execution. While is it possible to use a code coverage tool on a single execution or multiple ones of our application without using unit tests, it makes more sense to use it with your tests. As you are creating your unit tests, you will want to run 100% of your code with them. Knowing that 100% of your code can be executed without errors will give you a good foundation for quality assurance.

I will show you an example with Python using nose, a unittest extension and the coverage module. Let’s say that I have a module named mymodule.py which contains:

class Counter():
    def __init__(self):
        self.x = 1
    def add(self):
        self.x = self.x + 1
    def show(self):
        print self.x

Let’s say that I have a test file named tests.py which contains:

def test():
    import mymodule
    c = mymodule.Counter()
    c.add()

I could run the following line to get a coverage report of my module with my test function:

nosetests --with-coverage tests.py

The results would be:

.
Name       Stmts   Exec  Cover   Missing
----------------------------------------
mymodule       7      6    85%   9
----------------------------------------------------------------------
Ran 1 test in 0.010s

OK

If I change my tests.py file to this:

def test():
    import mymodule
    c = mymodule.Counter()
    c.add()
    c.show()

And I run again the same command line, I would get:

.
Name       Stmts   Exec  Cover   Missing
----------------------------------------
mymodule       7      7   100%
----------------------------------------------------------------------
Ran 1 test in 0.009s

OK

If I rename my show method in the mymodule.py module to display and run the test again, I would get the following:

E
======================================================================
ERROR: tests.test
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/usr/lib/python2.5/site-packages/nose-0.10.4-py2.5.egg/nose/case.py", line 182, in runTest
    self.test(*self.arg)
  File "/home/remy/projects/test-python/tests.py", line 7, in test
    c.show()
AttributeError: Counter instance has no attribute 'show'

Name       Stmts   Exec  Cover   Missing
----------------------------------------
mymodule       7      6    85%   9
----------------------------------------------------------------------
Ran 1 test in 0.014s

FAILED (errors=1)

Using unit tests and code coverage, you can build high quality software with Python too. To be fair, most commonly used languages have their own tools too to create, run unit tests and get a code coverage report. If they do not, you can probably craft your own tools for this purpose.

Quality often requires efforts but sometimes all you have to do is integrate a few tools to get a good start at the job.

I have started using more and more open source software recently and for many different reasons. I am cheap. Whenever I try something that is free and do the job, I just keep using it. As most open source software are also free, I tend to use them. There are also some gems in the open source world that are just better than any commercial offering. I also feel like open source software tend to be more secure since there are more eyes that can see the potential problems and propose a solution.

While using these software, I often encountered bugs, some problems or things I though were just wrong. My first reaction was to go on their website and check for a possible known issue and its solution. When I could not find the solution my second option was to drop by their IRC channel if they had one or to send a quick message on their mailing list.

Recently, I had a problem with Mercurial, a nice distributed version control system. I did what I usualy do but there were no solution for it. It was a problem regarding the use on Mercurial on Windows with paths that contain extended characters. Since I had some free time, I told myself: “I should be able to correct that bug on my own and help the project by submitting a patch.”. That is what I did.

First, I had to download the source, get it to build and get starting to test it. That task took me about 5 hours to complete because Mercurial does have some part that are written in C and the main sections in Python. Building a python module or extension in Windows does requires a bit of know-how. Anyway, I managed to find the problem and get started with a simple patch to correct it.

I went to Mercurial’s website to found out how I could contribute to their project. The first thing that struck me is their how-to contribute page. It is huge. I do understand the rational behind it, but I guess it can easily turn off any casual contributer. I wanted to go all the way so I went by their rules.

In the end, I submitted my patch and the reasoning behind it. It was not accepted but it is fine. The bug was corrected and hopefully, not other related bugs will come out of the correction.

Contributing to an open project can be fustrating sometimes. I still remember the story of Con Kolivas with the Linux kernel. He was trying to modify the scheduler to make it more fair, but his contribution was rejected. After reading his story, I doubt I will ever contribute to the linux kernel. I guess you must have a good feeling about it.

I think contributing is first and mostly about the passion. If you have a strong passion for a project and you will like it to grow and get better, go for it. Get yourself to contribute. There are many different ways you can serve a project. Testing, documenting, translating, designing, programming are only a fraction of what you can do. Get yourself known and you might gain some strong experience.