Wednesday, December 29, 2004

quote of the week

Whatever works is good enough. If you can understand what the customer wants, you win. Of course, if your customer doesn't know what they want, then it is like arguing with your wife: no matter how right you are, you are still sleeping on the couch.

Source

Tuesday, December 28, 2004

Optional Static Typing in Python

Guido van Rossum talks about Adding Optional Static Typing to Python. Here is my take on it.

about "Compile Time vs. Run Time".

I 'd be completely happy if the type check would be performed at run-time, not on compile time or import time. After all, that's how a Python developer expects the things to be.

You may argue that's this doesnt buy you much but I disagree. ;-)

Firstly, it's a first and logical evolution from the current state of affairs. Secondly, it does provide some tangible benefits.

Currently, many developers are used to write something like this:


def foo(g,a):
assert isinstance(a, str), a
assert callable(g)
...


Strictly speaking, these assertions are not required, but they do help to detect errors as early as possible which is a sound engineering practice.

With the help of type interferencing or manifest typing we could free programmer from this tedious work, if he wants to.

Duck typing

What I really wanted to see in Python is an explicit support of DuckTyping, which is an integral part of type system anyway. The problem is IMO with a reasonable and helpfule implementation.

For some, a type interferencing (a sketch from the Haskell type system) may help. For instance if the foo() takes parameter a and then invokes method bar() on that parameter, compiler (or VM) could check (at least, at run-time) that the argument passed to foo() does have a callable bar attribute.

This also can be extended on operator overloading, such as __add__ or __lshift__.

And my point is, even with such a limited form (run-time checking of automatically derived type information), it could be a big step forward.

Optional type annotation (embedded in the source code) could be a next step.

Saturday, December 18, 2004

simple and extensible blogging tool in Python

I wonder, can anyone recommend some simple and extensible blogging tool, written in Python? The idea is to retrofit site News section to use a some kind of [primitive] blogging system, instead of hand-written RSS 2.0 feed and hand-made modification to the site's front page.

To realize this idea I'm looking for some, preferably python-based tool, which could be easily plugged-in into my custom presentation, authentication and persistance modules (ideally) or at least I should be able to provide my own presentation. The API is minimalistic: add post (item), add comment, get item as XML, get RSS/Atom feed and that's basically all.

Any recommendations?

Thursday, December 16, 2004

Palm may be not dead after all

In the course of the recent events in the Palm world (like infamous T5 release or Sony decision to exit PDA market), many, myself included, start seeing the PalmOS platform as an obvious loser. It will surely take a lot of hardwork and luck for Palm to break this negative trend, but these insiders' comments on PalmOS for Linux project give me some hope. Not that I care a lot, but still.

It'd interesting to watch whether PalmSource succeed to repeat Apple's indisputable victory with it's Mac OS X. And I wonder what's happened with BeOS kernel that's already in the disposition of PalmSource's engineers? Has it been abandoned in preference with Linux?

Monday, December 06, 2004

strategy for acceptance tests

With the version 1.0 of my project out there, I have a planning session to decided what to do next. Of course, I'm going to start working on release 1.1 now but in parallel with that, I intend to work on the acceptance (functional) test suite which currently drags behind due to the 1.0 release schedule pressure.

Recent Robert Martin's post in the FIT mailing list summarises my strategy for these kind of tests nicely:
...[I] INSISTED that the majority of automated acceptance tests be run JUST BELOW the GUI. (i.e. not THROUGH the GUI).

Some acceptance tests, those that test GUI functionality only, MUST be run through the GUI. But I don't want any business rules tested through the GUI.

Of course QA must also get their fingers and eyes on the system. I don't want them doing this with any scripts. Anything that can be scripted should be automated. Rather, I want the QA folks using their ingenuity and creativity to manually operate the GUI and figure out devious ways to break the system.

Friday, December 03, 2004

Blog of the week

Found a remarkable blogger this week - Phillip J. Eby, a primary author of the ambitious python framework for enterprise applications. I doubt I would use his framework anytime soon, but his general thoughts on python and software development in general are much appreciated.