Archive for July, 2005

No more Java project ideas!

I gave up.  I finally closed the comments on this Java Projects entry that kept receiving comments from Indian students who don’t bother reading what they are commenting on.  I think there are more than two hundred (200!) comments from students asking me for project ideas by now.  I didn’t close the comments initially because I wanted to see how far the insanity could go…  Well, very far it seems, and no end in sight.

Updating the entry to point visitors to a clarification didn’t change anything:  the requests for project ideas kept coming at the pace of about one per day, so I decided to put an end to it.

Except that…  my Movable Type installation is using Berkeley DB, and there is no way to close comments or trackbacks for past entries (or do any kind of batch operation for that matter).  The only way was to move it over to MySQL, which ended up being surprisingly easy.

The first thing to do is to download Movable Type 3, which contains a very handy mt-db2sql.cgi script.  That’s all you need from Movable Type 3 and this script works on Movable Type 2 (the one I’m using).  All you need to do is put this script in your installation directory and follow the instructions.  The script took a few minutes to run (I have over three hundred entries by now, several thousand comments and the script transfers everything, including the logs, which I couldn’t care less for) but it completed successfully and after that, I was migrated.  As simple as that.

My MT-BlackList installation was disabled during the process, but reactivating it was a simple matter of going to the main page and checking a box.

I connected manually to the MySQL database to double check and everything worked like a charm.  The schemas are very intuitive and a few SELECT, UPDATE and WHERE later, I had closed the comments for the offending entry and also the trackbacks for all my past entries (the latest trend used by spammers, which shows at least that CAPTCHA’s are working fine).

Sorry, India, you’ll have to look somewhere else for Java projects.

Weeee I got a jeep!

This

transcript
had me laughing out loud at my keyboard (and I mean that
literally).

Some background in irc / World of Warcraft / MMORPG will help, but I’m sure
you’ll be able to appreciate it anyway.

My favorite part:

T0J0: wtf is nukes?
T0J0: holy ****holy****hoyl****!
*T0J0 has been eliminated.*

Announcing the TestNG IntelliJ plug-in

The
first version of the TestNG
IntelliJ plug-in
is now ready for testing. 

This is a joint work by Mark and Hani, who’ve been pulling all the
stops these past days to get the plug-in ready.  There is more work going
into the plug-in as we speak, but it’s ready for a first round of testing,
so try it and post your feedback on the
TestNG user
mailing-list
or here.

Thanks
a lot to Mark and Hani, and also to Alexandru whose original Eclipse plug-in
code was instrumental to getting this plug-in finished (and which also paves
the way for future plug-ins).

Great
job guys!

 

You can use the debugger if you bring me a shrubbery

The following quote recently came up on the TDD mailing-list:

I have worked in places where we would tell junior developers that
they were not allowed to use the debugger without asking permission first.
Only if they could justify the debugger’s use were they allowed to use it.

This is a fairly radical position, so I can’t possibly agree with it :-)

There are several disturbing points about this quote:

  • How do you justify the use of a debugger?  It’s a red
    herring to give some grounds to this arbitrary decision but in short, I’m
    pretty sure it’s an impossible task.  And if you are talking to an
    extreme TDD advocate, you can be sure they will always find a good reason to
    convince you that writing tests is the only way to locate a problem.
     
  • The only way to learn when not to use a debugger is to use a
    debugger a lot
    .  Practice will teach you the strengths and
    weaknesses of a debugger, what its limitations are, what you can achieve
    with it and what should better be approached differently.  As you use
    it, you will accumulate knowledge on which categories of bugs a debugger is
    good at solving and when you tend to come back empty-handed.  In short,
    you are building up this intangible set of diffuse knowledge referred to as
    "experience".
     
  • It’s better to teach someone how to use a tool properly rather than
    forbidding them from using it completely.

     
  • By the time the problem shows up, you probably don’t have tests to catch
    it yet, so whatever you will end up doing is not test-driven development
    anyway.

My dirty little secret is that I love both test-driven development and
debuggers.  I use both all the time without any particular pattern. 
Sometimes I spend most of my time writing tests, other times I’m knee-deep in
Eclipse’s debugger, juggling with conditional breakpoints, stack frames and
multiple expressions that I keep reevaluating.

Is it the most productive use of my time?  I don’t know, I’m still
working it out and it’s impossible to answer such a question anyway.  But
by using all the tools I have at my disposal, I have definitely increased my
knowledge in the general area of "finding and solving problems".  And I
don’t think anybody should be denied that right.

Again, what concerns me in the quote above is the dogmatic attitude and the
total lack of regards for the skills of the person making the request. 
They might be less experienced than you, but it doesn’t mean they are stupid and
that they should be treated as children.  And who knows, maybe one day they
will be teaching you something about debuggers…

Testing private methods? You bet.

My answer to the question “Should you test private methods” is a resounding YES!

Let me start by giving you two examples.

Imagine that you are writing a Swing table widget that lets you order your columns in several different ways. Your sorting algorithm is private and one day, you introduce a bug in it. If all you do is test the public methods, the widget will simply start showing wrong results and your tests won’t tell you anything more. For all you know, there might be a bug in your Swing code. If you unit test your (private) sorting algorithm, you will catch the error right away instead of wasting time “higher up the stack”.

While this first example is fictitious, this second one is from TestNG itself.

TestNG uses a partial ordering algorithm to determine in what order methods should be invoked. Methods that have no dependent can be invoked at any time but methods that depend on others (or that are depended upon) need to be invoked in a certain order. This requirement creates a “partially ordered set” of methods, which means that some of its elements are ordered but not all.

This algorithm is completely private, but if it goes wrong, TestNG will start failing in very mysterious ways, indicating dependency failures and other strange error messages. It was pretty obvious to me that I needed a separate test for this section of the code.

I am sure that anyone can relate to a similar situation where their code was so dependent on a private section of code that it was vital to make sure that you would know right away if this part should break.

When it comes down to testing, I follow a very simple rule: “if it can break, test it”.

Now that we have determined that there are actually two kinds of testing (private and public), I would actually go one step further and argue the following points:

  • Private tests should run before public tests.I don’t think there is much point in running your public tests if some of your private tests are failing. When private tests fail, the entirety of your code might be jeopardized and will probably fail in random places or maybe even pass in places where it should fail. This situation is a little bit like using a compiler that generates invalid code: wouldn’t you try to fix the compiler before you try to compile any program with it?
  • Private tests should prevent public tests from running if they fail. This is a consequence of the first point. If your private tests fail, you might as well save yourself the trouble of spending time running your public tests since they will be meaningless.
  • Private tests should be listed first in the reports. If some of your private tests fail, they should be the first thing you investigate since fixing them might actually fix the potential failures in your public tests.

Since TestNG supports dependent testing (“don’t bother running test method b() if test method a() didn’t succeed”), it might actually be interesting to add a way to specify that a certain test is testing your private API. This way, TestNG would run it first and make all other non-private tests depend on it…

What do you think?

Eclipse tip: context-dependent launches

This feature has probably been in Eclipse for a while but I only recently
discovered it, and I’ve found it quite useful already:  Eclipse lets you
define launch configurations that depend on the current selection.

Consider the simple following program that prints out the parameter passed on
the command line:

public class Echo {
  public static void main(String[] args) {
    System.out.println(args[0]);
  }
}

Then create a launch configuration and press the Variables button:

Choose the variable "selected-text":

And close the launch dialog.  Next select some text in a buffer, say the
first line of the class:

Launch, and you get:

public class Echo {

I have used this feature quite a few times already to launch groups of tests
with TestNG by simply selecting them from my Java source or the XML file, but I’m sure there are many other uses.

There are plenty of other interesting variables to choose from, by the way,
try them out and report here!

 

A computer should feel the user's angst

I was just reading an interview of Chris Taylor, the creator of the mythic
game
Total Annihilation
, which is still considered as one of the best real-time
strategy games of all time despite being released in 1998.  Taylor is
working on a sequel to Total Annihilation and he is introducing a set of
innovative user-interface features.  The article I read only disclosed one: 
watching the frequency of your clicks.

In short, the game will monitor how fast you are clicking your mouse in order
to detect the urgency of your commands.  If you want a certain unit
destroyed as soon as possible, you are therefore encouraged to click on it
multiple times, which will signal to the game engine that it should activate
additional firepower and units to follow your command.  This is what Taylor
means when he says "A game should understand the player’s angst".

It is a very little known fact that games have pioneered a lot of innovations
in the user interface area.  For some reason, their contribution has always
been very much downplayed but I am a firm believer that a lot of the widgets we
use on our desktops today (most of them being incremental improvements of the
WIMP paradigm -
Windows Icon Menu Pointer) appeared in games first.  You might not have
realized it, but there are plenty of subtle improvements available to you on a
daily basis, such as:

  • Flat toolbars.  There was a time when we were convinced that a
    button had to be 3D in order to express its
    affordance
    Nowadays, such interfaces look clunky and antiquated.
     
  • Scrollbar thumbs giving hints as to where the document will reposition
    itself if you release it.
     
  • Shortcut tree views.  Tree views have become a central part of any
    sophisticated user interface and they tend to become quite crowded. 
    Applications such as Outlook or Eclipse now let you specify shortcut views
    that only contain the nodes you are the most interested in.
     
  • Goal-oriented interfaces ("I want to create a new document" as opposed
    to "Open / New document").
     
  • etc…

Indeed, we are still using the old WIMP paradigm that was invented in Xerox
PARC two decades ago, but all these incremental improvements have contributed
greatly to making our desktops much easier to use.

Another example of a feature that was first implemented in games
is mouse gestures
keep your right button pressed, draw a "C" with the mouse and the current window
will close.  What’s fascinating with gestures is that not only can you
recognize the geometry of the symbol the user is drawing, you can also analyze
their motion to make a decision:  if they drag the mouse in a line from
right to left, it means "Back", while dragging from left to right means
"Forward".  Mozilla-based and other non-mainstream browsers support
gestures, but overall, they are not being used very much.

Taylor’s multi-click idea is new to me.  In general, modern user
interfaces tend to move away from double clicks because it is difficult to
explain to novices, and the confusion is even greater now that so many clicks
happen on hyperlinks in HTML documents, which create an immediate response after
one click (I set up all my desktops to respond to single clicks everywhere as
soon as Windows 95 came out).

Another unfruitful attempt at using multi-clicks dates back as far as Windows
3 (and still supported to a certain extent in today’s Windows) where a single
click on the upper-left corner of the window shows up the Options menu but a
double click closes the said window.

Overall, it appears that basing an interface on double clicks is a bad idea.

Interestingly, I believe that Taylor’s idea has better odds of working,
precisely because the specification is vague.  You don’t need to "click
twice within a few tenths of a second", all you need to do is "click several
times", and the program will react accordingly.  The human parameter is
what makes the difference.

Can you think of any other ways to improve the WIMP interface, either coming
from games or other areas?

 

Announcing TestNG 2.4

The TestNG team is happy to announce the release of
TestNG 2.4.

A lot of fixes and improvements have gone into this release (see the

complete list
) but the most important feature is the new Web site (http://testng.org)
and the new packaging (org.testng.*).

There are also a couple of items I want to mention briefly:

Big thanks go to Alexandru Popescu, Andrew Glover, Thierry Janaudy and Russel
Winder for their participation to this new release!

You can download TestNG 2.4
here
.  The Eclipse plug-in has also been updated to this new version
and can be obtained from the update site (http://beust.com/eclipse).