This article from Sun (found here) has proved itself useful in solving a wierd problem that bugged me for over an hour earlier this week, whereby everytime I tried to hide some text that a third party component was printing (by making it the same colour as the background – per the vendors docs) it caused a totally unrelated section of the display to vanish as well. I finally fixed it by passing the component a font with zero size, but it turns out that the Graphics object has a handy ‘create’ method for making copies which can be used to isolate components from each other. It would appear that the supplied component made some changes to the Graphics object which were infecting other parts of the display. I love it when a mystery is solved.

One caveat: the ‘destroy’ method mentioned in the article is actually called ‘dispose’. Always write code samples inside an IDE!

Some thoughts on testing while I’m waiting for my commit email from CruiseControl…

Inversion of Control: Pass stuff as parameters, don’t instantiate objects inside methods just to make queries on them. It makes it much easier to use mock objects or stubs if the things you need are passed as parameters. If I had to come up with a pithy catchphrase for this it would be something like: “Methods should only create objects that will be returned from the method.”

This leads me neatly onto my other thought for the day – “Tell don’t ask”. Code should look like a sequence of commands, not a bunch of questions. If all you are doing is querying an object about its state, shouldn’t that code be inside the object? I think the anti-pattern is called something like Feature Envy, or Data Envy or something. Code that follows the ‘tell don’t ask’ principle is generally more polymorphic, more modular and easier to refactor.

I’m not talking about putting up a couple of wonky shelves here. Oh no. As you may recall, I had been without heating or hot water for three weeks. The repairs were covered by British Gas, who eventually (after several ‘robust’ telephone conversations) sorted someone out to fix it last monday. This involved moving the lounge radiator to a different wall and running a new section of pipe to it. As a result I was left with two pretty deep holes in my floor (which is concrete, despite being on the second floor). My cover didn’t include making good, so this weekend it was off to B&Q and a spot of repair work. It was not a good day. And my choice of career was once again vindicated – I would be a truly awful builder.

Most of the day was spent either (a) panicking, or (b) waiting. I now know far more than I ever wanted to about how to prepare a concrete floor for filling, including the exact ratio of water to PVA needed to seal it (3:1) or form a bonding coat (1:1). I also know that self-leveling floor filler requires a hole deeper than 6mm to be filled with pea gravel to a depth of 5mm below the surface. Fascinating. Hah.

Of course no DIY story would be complete without a humorous cock-up, so I went the extra mile and had two. Firstly, about halfway through the day I locked myself out of my bedroom when the door first swung open, hitting the door stop (which is at the exact height to activate the push-button lock thingy on the inside handle), then swung closed. With my keys inside. That was the low point of the day. I took a screwdriver to it. It didn’t last long.

The second error was failing to realise just how much filler it would take (despite buying a huge tub of it, which I thought would be about 50% too large), leaving the second hole with about a centimetre to go. Naturally by this time it was too late to do anything about it. Luckily I was too drained to care. But on the bright side, it does mean I get to have almost as much fun tomorrow evening as I did yesterday. Can’t wait…

Why Nerds are Unpopular

Remember Zork, Hitchhikers Guide and other text-based classics?
Now you can play Infocom games on your palm pilot or in a java applet!

http://www.latz.org/infocom/index.shtml

How cool is this:

Controlling windows 95 from a remote machine
This shows how to set up a two node distributed system. One node runs windows95 Erlang, the other runs linux Erlang. There are two example programs. A program which allows the linux Erlang to manipulate the windows 95 registry and a bouncing ball that bounces back and forth between the windows and the linux machine – the latter example illustrates platform independent graphics, and various distributed programming techniques.

And the winner of the language to learn this year prize is… Erlang.

(Added later: JInterface – an erlang/java interface module. Groovy.)

Lots of good comments were made about my last post. Just wanted to add my own thoughts (its my blog after all!). The example is inane and trivial, and yes it could be refactored in many other ways. The point is, if you have something that must always occur just before the execution thread leaves a block of code, a finally block is the way to go. Its also interesting that while the try/catch/finally form is well known, try/finally is much less frequently seen.

Finally blocks are underrated. They’re really very useful for removing duplication in code with multiple exit points. Consider the following:

public int foo(boolean condition1, boolean condition2) {
setMouseBusy();
if (condition1) {
doOne();
setMouseNormal();
return 1;
}
if (condition2) {
doTwo();
setMouseNormal();
return 2;
}
setMouseNormal();
return 0;
}

Compare with this:

public int foo(boolean condition1, boolean condition2) {
try {
setMouseBusy();
if (condition1) {
doOne();
return 1;
}
if (condition2) {
doTwo();
return 2;
}
return 0;
} finally {
setMouseNormal();
}
}

Why is the second form better? Because no matter how the method exits (including throwing exceptions), the finally block will be executed. In the first form, if either of the ‘do’ calls throw an exception the call to setMouseNormal will be skipped, possibly leaving the application with a misleading hourglass cursor.

This is just horrible! How many characters needed? I can feel my wrists ache just reading it (which is also strenuous due to all the XML taggage). XML is designed to be easily parsed by machines, not people! What is the point of a language where ‘XML is the underlying construct, not ASCII’? Call me a luddite, but I mean really, what does it offer over good old fashioned text?

Cool Programming Language Concept: SuperX++.

Cool Programming Language Concept: SuperX++

This is neat: Super X++.  It is a language where XML is the underlying programming construct as opposed to ASCII.  And, yes Virginia, it is Open Source.[_Go_]

Here is a simple example from the FAQ:

How do I code “Hello World!” in Superx++?
The following code will be a full Superx++ program that returns the string “Hello World!” to the Superx++ client (whatever process calls a Superx++ program):

<xpp>
   <xout>Hello World!</xout>
</xpp>

And here is a complex example:

How do I define a class?
A class in Superx++ is defined using the <class> statement. An example follows:
<class name=”XTree” inherit=”XPlant”>
   <construct>
      <scope type=”public”>
         <Chlorophylic>yes</Chlorophylic>
      </scope>
   </construct>
   <scope type=”public”>
      <func type=”string” name=”GetChlorophylic”>
         <body>
            <return>
               <eval object=”Chlorophylic” />
            </return>
         </body>
      </func>
      <func type=”void” name=”SetChlorophylic”>
         <parm type=”string” name=”sVal” pass=”val” />
         <body>
            <eval object=”Chlorophylic”>
               <eval object=”sVal” />
            </eval>
         </body>
      </func>
      <func type=”int” name=”GetAge”>
         <body>
            <return>
               <eval object=”this” member=”Age” />
            </return>
         </body>
      </func>
      <func type=”void” name=”SetAge”>
         <parm type=”int” name=”sVal” pass=”val” />
         <body>
            <eval object=”this” member=”Age”>
               <eval object=”sVal” />
            </eval>
         </body>
      </func>
   </scope>
   <scope type=”protected”>
      <var type=”int” name=”Age”>0</var>
   </scope>
</class>

The statement above declares a class called XTree which inherits from the class XPlant which contains an object called Chlorophylic. Every time an object of class XTree is instantiated it will be instantiated along with a contained object called Chlorophylic. The class XTree also defines four methods and one member variable. For more details on classes click here.

Thanks to Dr. Dobbs Journal for turning me on to this.

[The FuzzyBlog!]

This site has lots of fun tools for collecting code metrics. The LOCC tool is particularly fun. Remember, code metrics are for interest only! Never, ever use LOC as a measure of project progress. That way lies madness.