Tuesday, July 17, 2007

Code reviews, automated testing, static analysis

There was an interview on The Java Posse podcast where Brian Goetz (whose book is great BTW) said something about software QA which made me nod heavily in agreement. (It probably looked strange standing alone in the bus stop). I liked it so much, that I'll transcribe it here:

"If you ask most developers on the street 'why do we test code' you'll get an answer something like: 'to find bugs!' Finding bugs is good, but I think finding bugs is a happy side effect of writing tests. [...]

Writing tests is one of those necessary things but it exhibits diminishing returns. The first 100 hours you spend writing tests are probably going to be more effective in terms of improving your confidence in the code than the 100 hours from 1000-1100. [...]

A better way to think about the kind of testing that we do is not that we're looking for bugs it's that we're looking to buy confidence. [...]

Writing tests is a form of buying confidence that exhibits diminishing returns.
Code review does the same thing. [...]

And if you try to apply portfolio theory to optimizing the QA budget [and] you observe that both of these buy you confidence with diminishing returns and they're uncorrelated then the optimal portfolio is to have some mix of testing and code review rather than putting all your eggs in one basket or the other.

Static analysis yet a third thing we can do [...] that tends to find different kinds of bugs than either testing or code review. So it's something that should be part of everybody's development lifecycle, ererybody's arsenal, everybody's toolkit."


I'm a huge fan of FindBugs and other static analysis tools I wish there were more ways (ie. a richer set of annotations) to make things in Python (and even in Java) more explicit, so that these tools could catch stupid mistakes for almost free and immediately rather than letting them slip through and manifest as hard to find bugs further down the road.

Sunday, July 08, 2007

A nice podcast on Python VMs

I don't have much time and patience for podcasts and I'm really happy when I find one that doesn't make me feel like I'm wasting my time. Here's probably the most informative podcast on Python that I've listened to in a long time:
It's a nice high level overview of CPython, Jython, IronPython, Psyco and PyPy. How they came about, what's the idea behind each of them and how they relate to each other.

The podcast is from April and in my opinion paints a somewhat rosy picture of these technologies but it's still highly recommended.

Tuesday, June 26, 2007

Yet another Python web development framework comparison

If you're still sitting on the fence about the right web framework here's another comparison post describing Django, Pylons and TurboGears.

Python web development and frameworks in 2007

I don't understand why the poster thinks that the TurboGears community is in 'decline'. All I see is that there are more subscribers on the mailing list than ever (3 times as many as for Pylons).

Monday, June 25, 2007

Google Developer Podcast

The only podcast that I regurarly listen to nowadays is The Java Posse. Recently Google launched a developer oriented podcast called the Google Developer Podcast. Since Dick Wall and Carl Quinn from the Posse are participating in the GDP it's almost like listening to a special edition of the Java Posse. For me this is a very good thing.

When I started going to the gym more I subscribed to tons of different podcasts: Python411, Drunk and Retired (Java), Digg Nation, Floss Weekly, etc. In the long run however I found that most of them are too unprofessional for my taste or don't have the right topics and especially signal to noise ratio. So I ended up listening to them only occasionally and stuck with the Posse in the last few months.

Are there any good developer podcasts you recommend?

Thursday, June 21, 2007

Django, TurboGears, Pylons comparison

It doesn't even try to be "scientific" but I still found this comparison of the currently popular Python web frameworks very informative:

Unscientific and biased comparison of Django, Pylons, and TurboGears

Tuesday, May 01, 2007

Guido's Python 3000 Talk

I somehow missed this talk Guido gave at Google about Python 3000. I found it through StumbleUpon now.

Saturday, February 24, 2007

Python web frameworks quote

Reading through the PyCon 2007 notes:

There are more Python frameworks than reserved Python keywords.


Funny because it's true. :)

Saturday, February 03, 2007

Open Office and regular expressions

For the first time in my life, I tried to use Open Office for more than 15 minutes. While converting data from an HTML page into a chart I noticed that regular expressions don't seem to work in the Replace part of the Find/Replace dialog.

This must be a joke. My problem is trivial: Convert "8.1 k" into "8100" and "9k into 9000". I can't do it the straightforward way with 2 regular expressions. On an ideological level I'm a big supporter of Open Office, but today all I see is that it's wasting my time. (The corresponding online help for the dialog is not very useful either.)

Monday, January 08, 2007

Periodic Table of Visualization Methods



An extremely cool collection of visualization methods. You can mouse over to get an example of each.

Friday, January 05, 2007

PEP 8 checker

PEP 8 checker for the anal retentive in all of us. :)


/Users/gergely/twp/twp/bot.py:32:16: W291 trailing whitespace
sys.exit(1)
^
JCR: Trailing whitespace is superfluous.

/Users/gergely/twp/twp/bot.py:34:1: E302 expected 2 blank lines, found 1
def refresh_images(limit=dbbot._default_limit):
^
Separate top-level function and class definitions with two blank lines.

Method definitions inside a class are separated by a single blank line.

Extra blank lines may be used (sparingly) to separate groups of related
functions. Blank lines may be omitted between a bunch of related
one-liners (e.g. a set of dummy implementations).

Use blank lines in functions, sparingly, to indicate logical sections.


I'm the kind of masochistic guy who actually enjoys this kind of thing, but I need to figure out a better way to integrate it with PyDev. I wonder what's the easiest way to make Eclipse jump to the line where the error happened. Hmm...