elblogg

… is greater than zero.

Python is a dynamically, strong typed programming language. In my opinion that makes it more important to have good tools than for statically typed languages. Sadly, it also makes it more difficult to create great code analysis tools and IDEs. Meanwhile, I find more people in the Python community that is happy coding with Vi(m) even for quite large projects, than in the Java community. My guess is that that is because the tool support for Python has been poor.

When your IDE shouts at you with red lines under your function calls because it’s not able to look up in your custom libraries, of course you’ll refuse to accept it, and go back to your simpler editor.

Torbjørn Nordbye implemented the awesome Ruby support for Netbeans, and has now started on the work to give us Python awesomeness in Netbeans as well.

As mentioned in the comments of a previous blog post I have a good example of simple, obvious bugs that could stay in your application for years, without anyone noticing them, because that piece of code run almost never. Bugs that good tools, and/or compilation of staticly typed languages would find for you, but that unittesting and manual testing of your application probably wouldn’t find.

This is a bug that Tor found while testing his Python support for Netbeans, when he pulled in the datetime module that ships with Jython. There, in some exception handling the code references the non-existent class ValuError, which probably should be ValueError. A simple typo that has been undiscovered for a long time.

We all make errors. Good tools make us do less of them, and find them faster.

Okay. It’s kind of stupid to put static typing up against Unit tests. Even so, lots of people does so a lot of times in the discussion between dynamic and static programming languages.

Static typing provides you with a security net when it comes to typos. Alhough, it doesn’t give you any security against logical errors.

Read the rest of this entry »

Currently I’m developing a webservice interface for queue handling in Asterisk towards another company, that is developing a CRM solution which will utilize my webservice for Computer Telephony Integration (CTI).

So, today the developer in the other company got such an understanding of the service that he started suggesting changes. A lot of changes in the DTD etc. These changes would imply some changes in the architecture downwards in the system. It is quite scary to start tearing things apart, when you already got something working. That is, if you don’t have a large amount of unittests.

Luckily I had good unittest coverage. So changing stuff was really just a matter of changing the tests, do fit the proposed changes. Test to see where I needed to change something. Do the changes and run the tests again.

It feels very good to have proper knowledge that everything actually works properly after a refactoring like this.

Unit testing is like love. It’ll keep you going when everything else fails. (citation)

Tydeligvis så viktig at red book tester testversjonen, og dermed lanserer en testversjon av testversjonen av red book. I allefall i følge computerworld.