Too Difficult – Warning user about removing Python 2.6 in Kubuntu 9.04

It seemed like a good idea to remove Python 2.6 to get over the Python 2.5 installation error messages – except so many packages in Kubuntu 9.04 depend on Python 2.6 that removing it automatically removes what feels like half the operating system. Almost as good as rm -Rf /. After removal I couldn’t connect to the box anymore. So I’ll apply the Windows strategy of reinstalling the complete OS now to fix this horrible mess. Thanks guys. Next time give me a warning about what you donuts consider removing a “core” package, idiots. :-/

Too Difficult – Java GUI Programming

This shows how to get a spreadsheet like component which can add a row once you tab beyond the end of the current data in the component.

While it is very nice that it is possible to add this at all, I wonder if any of the SWT, JFaces, Nebula developers ever stop to think whether it really should take ~200 lines of code to get such a feature. Personally I would have expected this feature to be included already, ready to be enabled with a single line of code.

In Python they’d call such a case “no batteries included”, I guess.

And it’s far from the (alleged?) Java promise “make simple things easy and the complicated possible”, because here the simple things are complicated.

Too difficult: Providing examples/documentation for your vast and complex API/framework

I am sure Paul Webster of Eclipse fame is a good lad, but I doubt that he realizes that his tireless help for all questions surrounding Eclipse falls shorter than he would believe or prefer:

Pointing someone asking for how to rename a project programmatically to MoveResourcesOperation would be useful, if…

1) …the API documentation for the Eclipse RCP framework would pick the original poster up at that point (documented uses of the class inside the Eclipse RCP: 0; and it throws things like “IPath” at the humble reader)

2) … or if the internet would spill over with examples for using MoveResourcesOperation (10 hits for “new MoveResourcesOperation”).

What can be done to improve the current situation? Maybe every new API, method, class, extension point, etc. in the Eclipse RCP framework must be accompanied by a tiny and self-contained example before a release build of Eclipse is allowed to be shipped as “stable” or “final”.

As it is now, the Eclipse RCP is horribly frustrating to develop for, not because it is a vast and over-engineered framework (which it is in my opinion), but because of lack of examples and documentation for a vast number of very common use cases.

Windows Vista: Abysmal moving folders performance

In Windows Vista’s Windows Explorer moving the folder MyFolder (containing 40,000 files, and roughly 3.5 GB) at C:\Users\MyUser to C:\Users\MyUser\Desktop takes roughly 2 to 4 seconds.

Moving the folder back via Windows Explorer takes about 23 to 25 seconds (!).

Moving the folder back and forth via “move” command in cmd.exe takes roughly 1 second.

Given that moving a directory on the same partition is a very cheap operation on NTFS, the last figure seems acceptable, the second one leaves me unsatisfied and the first figure – plus the fact that it is 4+ times as slow to move in the other direction – leaves me with the feeling that some Microsoft developers suck just as much as everybody else at programming.

Throw in the complaints about perceived performance issues in Windows Vista and I am at wits end as to what the heck the product managers and developers at Microsoft are thinking when they decide not to fix these issues.

The system specs:

Windows Vista Ultimate, SP1
AMD Dual Core 4450e
4 GB RAM

Documenting algorithms in Python (using pydoc)

Python’s pydoc allows to include documentation for a method in the source code, in the first lines of a method’s body for example:

def test():
    """Documentation for method test."""

    # If file exists:
    ...
        # Delete file
        ...
    # Do this
    ...
    # Do that
    ...

But what if you want to document the algorithm used in the body of that method so that it shows up in the pydoc output as well? You could just add it to the pydoc comment explicitly:

def test():
    """Documentation for method test.

    It uses the following steps:
        If file exists
            Delete file
        Do this
        Do that"""

    # If file exists:
    ...
        # Delete file
        ...
    # Do this
    ...
    # Do that
    ...

Because the code already contains the documentation of each step adding each to the pydoc comment is uncomfortable, a duplication of effort.

By “extending” pydoc the duplication effort can be removed, so that documenting the algorithm could look like this:

def test():
    """Documentation for method test."""

    #ALGO: If file exists:
    ...
        #ALGO: Delete file
        ...
    #ALGO: Do this
    ...
    #ALGO: Do that
    ...

Note how the prefix “ALGO” in the comments is used to mark a comment as a comment for the algorithm.

Here is how to “extend” pydoc to support this functionality (contents of a file “pydoc_algo.py” created by you):

import pydoc
import inspect

def test():
    """This is an example of algorithm documentation entries.

    Note using capitalized keyword "ALGO" to see
    algorithm pydoc entries more quickly in the
    code.

    Also note the use of "pass" in the example: If
    a comment is not followed by at least one line
    of actual code it does not end up in
    inspect.getsource() and inspect.getsourcelines."""

    #ALGO: If file exists:
    if True:
        #ALGO: Delete file
        pass

    #ALGO: Create the file
    pass

    #ALGO: Open file
    pass

    #ALGO: Write data to file
    pass

    #ALGO: Close file
    pass

def getdoc(object):
    algoComments = []
    sourceLines = inspect.getsourcelines(object)[0]
    for line in sourceLines:
        lineLower = line.lower()

        while True:
            s = "# algo "
            if lineLower.find(s) != -1:
                break
            s = "# algo: "
            if lineLower.find(s) != -1:
                break
            s = "#algo "
            if lineLower.find(s) != -1:
                break
            s = "#algo: "
            if lineLower.find(s) != -1:
                break

            s = None
            break

        if s is not None:
            start       = lineLower.find(s)
            end         = start + len(s)
            indent      = line[:start - 1]
            algoComment = line[end:]
            algoComments.append(indent + algoComment)

    s = inspect_getdoc(object)

    if len(algoComments) > 0:
        s += "\n\nAlgorithm:\n"
        for c in algoComments:
            s += c

    return s

# "Install" the extension by replacing inspect.getdoc().
# Keep the reference to the previous inspect.getdoc()
# to call it ourselves.
inspect_getdoc = inspect.getdoc
inspect.getdoc = getdoc

if __name__ == "__main__":
    pydoc.help(test)

Here is an example call:

>>> import pydoc
>>> pydoc.help(pydoc_algo.test)
Help on function test in module pydoc_algo:

test()
    This is an example of algo documentation entries.

    Note using capitalized keyword "ALGO" to see
    algorithm pydoc entries more quickly in the
    code.

    Also note the use of "pass" in the example: If
    a comment is not followed by at least one line
    of actual code it does not end up in
    inspect.getsource() and inspect.getsourcelines.

    Algorithm:
       If file exists:
           Delete file
       Create the file
       Open file
       Write data to file
       Close file

>>>

This approach could be useful for “To do” entries too (“#ToDo: Do this and that here in the code!”).

One Assert vs. Multiple Asserts

There is a (ongoing?) discussion about having one assert or multiple asserts in a test method of a test case.

One Assertion Per Test

Write Maintainable Unit Tests That Will Save You Time and Tears

My Unit Testing Idea : Facilitating Multiple Assertions

Avoid multiple asserts in a single unit test: revisited

What is one assert?

The proponents of multiple asserts claim that (among others):

• multiple asserts make their test code shorter and thus,
• more readable,
• and faster to execute because the test setup is being re-used (which for time consuming test setups really is a matter).

The opponents claim that:

• one assert makes their test code more readable,
• only a little longer,
• and more reliable, because side effects of asserts are not an issue, because the individual test setup – the so called “fixture” if I am not mistaken – is recreated for every call to every test method.

The discussion is obscured by the fact that some are silently assuming a pragmatic point of view, meaning they accept unit test frameworks the way they are (without a realistic option to change and improve them).

(Note: Many test frameworks seem to implement failed asserts by throwing  exceptions, thus leaving the test method, without a chance to proceed with the following assert. This is a limiting design of these frameworks, and they can be altered to be more flexible.)

The other group silently assumes the theoretical point of view, not accepting the state of unit testing frameworks, and implying that they should be altered if new insight, knowledge and wisdom demand it.

Limits of current frameworks

The current state of frameworks should not dictate whether multiple asserts are being used or not.

Reusing test setups (despite possible side effects)

If you accept that test setups must be reused in some cases to make the tests finish faster (despite the fact that side effects might make the wrong test fail), you have to run your test setup once for the group of asserts that you want to perform on the test setup.

How you achieve this differs:

• With one assert per test method you perform the setup at the top of the test method, for example.
• Similarly, with multiple asserts you perform the setup once by means offered by the programming language and the test framework (if the framework instantiates the individual test case class for every test method call (like CppUnit does)  you use a static block (Java) or so).

The difference in code is negligible, in my opinion. This leaves the question whether other aspects can help determine whether one approach is better than the other. (If you know any, please speak up.)

Ignoring traditional unit testing structure

The proponents of multiple asserts per test method ignore some traditional unit testing structure: they ignore that the test setup is not to be done in the test method call itself, but this by itself is not of much importance. and can be ignored when considering theoretical aspects.

When it comes to practice however, one should probably use the supported (as said before, multiple asserts per test method call are not “supported” by many unit testing frameworks, in the sense that they do not execute asserts following a failed assert) and expected way, be it one assert or multiple asserts per test method call.

Test setup and asserts in one place – less indirection

What might make one assert per test method call code harder to read is the separation of test setup and asserts to be performed on them, because afterall the test setup is not being done in the same method, but elsewhere (and thus simply paging upwards won’t necessarily take you to the test setup, at least not very directly), which adds a level of indirection. (Because the human brain can only cope with a limited number of indirections any additional level of indirection should be considered with much caution).

Differences smaller than initially assumed?

Having said all this in so many words, maybe it helps to realize that one assert and multiple assert aren’t so terribly far apart as one would initially think, and that it is acceptable for oneself to follow one of both “styles” when it is required. Sure, with one assert per test method you have to add more methods, which means more lines of code. But they are pretty “empty” lines and easy to sort out for the eyes and brain.

Apress Inc. – Broken Support

I contacted Apress several months ago about their broken support section (I wanted to download the source code of one of the books that we purchased). Their reply was “sorry, it’s broken, try again later.” I asked for them to fetch me the source package manually, but got the same reply.

Now I checked again, and the support section is still broken.

In light of this their slogan “Books for Professionals by Professionals” seems like a slap in the face of their customers.

Too difficult (for Microsoft): Windows SpecialFolders/Shell Folders consistency & documentation

In WSH you can retrieve the path of special folders via the WScript.Shell.SpecialFolders Property. Similar APIs exist for .NET based languages.

Unfortunately neither is the documentation of the existing special folders complete, nor is the list of special folders available via the SpecialFolders property complete.

Some of the special folders are available as environment variables. Unfortunately only few though.

And also, still unfortunately, the names for the special folders differ in WScript.Shell.SpecialFolders and the .NET API.

Also, unfortunately the Enumerator in WSH JScript does not offer a way to retrieve the name/key of the value. So while 16 names are documented, the enumerator/the SpecialFolders property gives access to 18 values at the moment. But you have to guess the names of the undocumented two names.

Is this Microsoft’s way to say “Gee, forget about these APIs, go use the native Windows API dude, this other stuff is nothing we care about much, isn’t it obvious?”. This would fit into the “keep pushing C++ for any solution that tries to do something creative” school of thought that Microsoft so happily sticks to (shell extensions in .NET? Definitely not a good idea nor supported…)

Sad that MS still expects us to write software which handles the difference between local and roaming application data while on the other hand being so lax about documentation and consistency and availability of required information.

Pestizidbelastete Lebensmittel – und nun?

Bericht auf NDR3: Pestizidbelastung sei bei soundsoviel Prozent der getesteten Äpfel über den zulässigen Grenzwerten.

Schön und gut, aber…passiert da noch mehr als das nur irgendwer diese Lebensmittel testet?

Muß irgendwer eine Strafe bezahlen? Wenn nicht, wieso nicht?

Warum passiert so etwas?

Warum kümmert es scheinbar niemanden über die gelegentliche Berichterstattung hinaus?

Gibt es in Deutschland so etwas wie ernstzunehmenden Verbraucherschutz?

Regular Expressions and nothing else, basta.

I suggested to someone who wrote a “regular expression search tool” to consider the ability to feed it wildcard/file globs too, instead of only regular expressions. The answer was basically “learn enough regular expressions to deal with it or use the broken tool in your OS, this is a regular expression search tool afterall”.

In my experience converting a wildcard to a regular expression is a matter of one, two pages of code, so it wouldn’t be an excessive amount of work, and the tool would be immediately useful to people who have a hard time with regular expressions.

And what happened to taking pride in how useful your tool is for wide range of people?

I have seen other tools which only support either plain searches or regular expressions, like EditPlus 2.

I guess the authors of such tools speak regular expressions fluently and/or hardly have any contact with people who don’t (but who need a search tool anyway).

To EditPlus 2’s defense I have to add that it supports another useful mechanism: Entering multi-line text for texts to be searched for and replaced. (On the other hand it doesn’t support free text word completion, only word completion based on a predefined dictionary. Sad, given how simple the task is to search through a text string in just about any programming language.)