skizz.biz

So I’m doing some work to double check the arithmetic of our app, and I’m using the gnome calculator. And I notice a bug - what do you think it gives if you type in: 2 * 2 + 2 * 2? So assuming we’ve all done basic primary school maths, the answer is 8 right?

Wrong

According to gnome calculator, its 12!

And not only is it wrong, they have known about it since at least the middle of 2004 and it still has not been fixed. And even then it appears that the broken behaviour is “still an alternate mode with this latest version”. Even if that version exists, it is not a part of Fedora core 3.

So here’s a nice friendly note to the gnome developers: YOU DON’T GET A VOTE ON THE LAWS OF MATHEMATICS. FIX IT. IT IS WRONG.”’

And just to reinfrce it, it does indeed work on the KDE calculator, windows, MacOsX….

Update OK, so it appears that the latest version fixes this problem (2004-11-03). So my question is replaced with “Why did it take them so long” and “Why hasn’t Fedora fixed this yet?”. I have left the main text intact, because it conveys some of the disbelief and frustration at the implementation, and they deserve it for leaving it there so long - and definitely for keeping it as an “alternate mode”. Hi guys - I’ll say it again: There is no alternate mode.

I guess the lesson to take from this is that there are some places where we, as developers, just don’t get a choice. It doesn’t matter if we don’t understand the laws of precedence, they are fixed, and have been in place for at least 400 years. In this case the mathematicians are right. Literally “by definition”.

Update: See also More on Calculators…

The New York Times today reports on Google’s foray into indexing the world’s major reference libraries. In the smaller print below is the belated release of some other search thing by some other company…

At XP2004 a couple of weeks ago Andy Pols and I presented our whitepaper, An Agile Approach to a Legacy System.

Basically it describes how we approached an intractable legacy app. By writing a new system that extracted its data from the old system, we were able to quickly develop new features to the customers, without comprimising the legacy system.

Over time, this strategy could be used to replace the legacy system with a brand new almost ‘greenfield’ application.

Abstract: We describe how a small, successful, self-selected XP team approached a seemingly intractable problem with panache, flair and immodesty. We rewrote a legacy application by delivering new features, a radically different approach to those previously applied. This proved to be a low cost, low risk proposition with a very high payoff for success. Most importantly it provided users with new functionality quickly that could never have been retrofitted into the legacy system. In the longer term it may give a migration strategy for replacing the legacy system.

Download (PDF)

When we presented this at the conference, we used an approach that we had used on the project to facilitate pairing. I hog the steering wheel when pairing, so I wrote a small java app that behaved like a chess clock. It has 2 dials, and counts down a specified amount of time one each. You click once to start it, and then when the time runs out you click it again and it swaps to the other clock and counts down that one.

When pairing we had it set at about 10 minutes. At the conference we had it set at 1 minute, and we took turns in speaking to the slides. We only had 20 minutes but we hit it spot on and managed to say everything we meant to. (Andy also blogged this here)

Here’s a screenshot of the clock:

I was reading Mike’s response to Michael’s “Groovy killed the XML file?”

Its actually not a very good example. You could of course do the same thing in java code, and just as unreadably.

But in Groovy you can write a builder that gives you much more readable code. For example, using a builder Michael’s example would look more like this:

b = new SpringBuilder() {
    bean (id:”messageSource”, class:”org.springframework.context.support.ResourceBundleMessageSource”) {
        property(name:”basenames”) {
            list {
                value(“org/springframework/web/context/WEB-INF/${message-file}”)
                value(“org/springframework/web/context/WEB-INF/more-context-messages”)
           }
        }
    }
}

and that is just as readable as the XML.

You can see more examples on GroovyMarkuo and in the AntBuilder unit tests.

In some very important ways it is more readable than XML. In particular, our brains read by picking up the start and end of a word, and groovy style syntax, by doing away with those pesky braces, does make it more easy to read. compare The readability of

The quick brown fox jumped over the lazy dogs

and

<The><quick><brown><fox><jumped><over><the><lazy><dogs>

The following is a
description of a system I have recently worked on. It describes the
thought processes we followed as we moved a large part of the code into
a declarative workflow engine. Its here because I think it shows some
of the thoughts that do into the continual design/refactoring of a
system like this. I warn you though - it is quite long :-)

The system was driven by a document workflow. The commands that a
user could perform would depend on the kind of document they were
viewing and also the state of that document.

We had recently moved to a declarative definition of workflow that
defined the Commands that could be performed on a document. When the
user viewed a document the client would call GetCcommandsForDocument
that would return a set of Command objects. Each Command returned would
generate a button on the view. When the button was clicked it would
instantiate that Command and send it back to the server via the
DoCommand method on an ICommandProcessor. On the asp client this would
delegate the call via remoting to the server.

For security reasons we separated Command and CommandProcessor, so
for example an AcknowledgeCommand would cause a CommandProcessorFactory
on the backend to reflectively lookup an AcknowledgeCommandProcessor,
inject its dependencies using pico-style DI (of
course :-) and call DoCommand on the processor. This meant that the
assembly that contained the Commands contained no domain logic code -
that was all in the CommandProcessors assembly.

Nice, but not nice enough.

Our users started asking for particular fields to be populated for
each action. For example, when the Acknowledging an invoice, the user
must correct any ambiguous dates (the invoices came from a document
recognition system and could come from many locales and languages).

At first we started writing and specialising custom Commands for
each action - previously they had been completely generic. As we went
along this path we found that we were dupicating these requirements
across Commands, since different Commands might have the same
requirement (eg. you must enter a comment).

So we abstracted a Requirement object, which encapsulated a single
such requirement. Then when the client called GetCommandsForDocument,
instead of getting a class which it would use to instantiate the
Command, it would get a set of Command instances populated with
Requirements. These were almost like Prototypes but we used them more like Flyweights. The view had a RequirementView corresponding to each Requirement, and we would use the Requirement as a model for the View.

Now when the user clicked on a command button, we would display a
new page (it would be a dialog in a gui) which would show the
RequirementViews backed by their models, Which were in turn populated
from the invoice data (which was in a DataSet. (There’s a lot of
different models here and it can get a bit confusing).

The user would enter data in the fields (RequirementViews) and click on the OK button, which would:
* Ask the RequirementViews to update their models (the Requirements in our flyweight Command)
* Ask the Command to validate itself
* If the Command is not valid, refresh the screen and indicate the fields (RequirementViews) in error
* Fire the command back to the server

* If the Command failed, refresh the screen and show the error (the
server could perform extra validation and would throw an Exception.We
could have returned an annotated Command object in the same way as the
client side validation above and had Requirement level server
validation but we never really needed it)
* go back to the previous screen and refresh it

Now we could declaratively build fine grained gui components from the back end. Our gui views were defined in an XML file that looked something like this:

<workflow type=”foo”>
<state name=”Unassigned”>
<action name=”Acknowledge” permission=”Acknowledge”
requirements=”ValidStartDate,Comment” destinationState=”InProgress”
destinationUser=”CurrentUser”/>

</state>
</workflow>

Here destinationUser is a Strategy - we had things like CurrentGroup, CurrentUser, TeamLeader, AccountsGroup etc.

We could have defined specialised Requirements like :
<validDateRequirement field=”startDate”/>
<validDateRequirement field=”endDate”/>

<commentRequirement field=”comments” required=”true”/>
but we didn’t feel the need so we used the simple attribute based approach above

Requirements became a very powerful abstraction in our system.

Having a declarative workflow also meant that we were able to
generate nice dot graphs for our BAs automatically each build, and
since we reloaded our workflow at each request (inefficient? who cares
- compared to remoting it didn’t slow the system down) we were able to
sit with the BAs, change the workflow xml file, reload the page and see
the changes immediately. It was great to see their faces light up when
two day stories became 5 minute changes to the XML
file - “Sit with me and we’ll do it now. Oh you want the fields in a
different order - hang on, how’s that? Cool? Ok I’ll commit it”.

One question this raises of course is that of how do you (or even do
you need to) test declarative systems like this. Do you need to write a
set of tests for every possible state transition? This seems a lot like
overkill - all you’re really doing is testing the contents of your XML file. But changing a part of the XML file can break the system from the users point of view. But fixing it again is really simple, so do you just give the BA’s
a tool to edit the declarative stuff and let them rework the system
themselves? If they then break the system from the users point of view
then that’s not a bug, its a misconfiguration - but the user still
can’t do their work.

Perrhaps we whould have a set of tests that act like invariants -
“In this state the date must be valid” and build them into the system?
That way the system will still function even if the details of the
Requirements are not necessarily as the user desires, or particular
actions fail due to invariant exceptions. Actually I quite like this
idea because it seems to cut across the declarative part of the system
at right angles. It defines invariants that guarantee thet the system never fails even if particular actions and commands throw errors - its also quite fail-fast.

So in the above example the system would never throw an “InvalidDateException - ‘23 Janvier S004’
is not a valid date” later in the workflow when the date was used for
some piece of domain logic, rather it would fail at the Acknowledge
step with some kind of “InvariantException - The date must be valid in
the state InProgress - This is probably due to a mis-configuration. A
message has been sent to the system support staff.”.