Archive for October, 2004

Today is Googleween

Big Halloween party later today at Google, and this morning, I rode the
shuttle with a Nascar driver, a bee, a mechanic, various angels and kitties and
Frankenstein.

Happy Halloween everyone!

 

Far Cry, Myst and other geeky pleasures

A quick overview of the games I have played recently…

Far Cry

Pure bliss.  This game is absolutely gorgeous in 1600×1200 with all
details turned on and it offers a tremendous amount of variety.  It is also
surprisingly long and I thought I had finished it a couple of times until I
realized that the plot was unfolding further.  I also liked the scenario,
which starts with a simple plot and slowly turns into a full-scale Doom-like
adventure.  But what keeps you going and going is just the constant hunger
to discover where the next level will take you… Dune buggy?  Glider? 
Patrol boat?  Jeep?  Carrier?  Helicopter?

Interestingly, the show "Lost" that is currently airing reminds me a lot of
Far Cry…

Doom 3

Undoubtedly a fantastic technical achievement but after Far Cry, Doom 3 bored
me pretty quickly.  I gave Doom 3 a fair chance to get me hooked and I
played about one third of it until I simply got tired of wandering in dark
corridors, waiting for the next alien to jump me from behind a closet.  I
didn’t install the "duct tape" mod, which allows you to have your flashlight on
at all times, since I wanted to play the game the way it was designed, and I
honestly didn’t find it to be as frustrating as some other players have. 
Having said that, while the constant darkness is guaranteed to make you jump on
your seat on more than one occasion, the sad truth is that it probably hides
most of the game’s technical brilliance.

Experts will probably argue that Doom 3 is one generation ahead of Far Cry
(which is at least chronologically true) but I’ll take fun and variety over
technical brilliance any day.  Especially since I think Far Cry certainly
holds its grounds visually.

Exit Doom 3 then…

More recently, I have had a renewed craving for a good old Real Time Strategy
(RTS) game that would match Rise of Nations, so I looked in the direction
of Rome: Total War (RTW) and Warhammer 40,000: Dawn of War (DOW).

Rome:  Total War

I spent a few hours on RTW, playing a battle and trying to get a feel
for the campaign map but I can’t say the game took me in.  Maybe I need to
spend more time on it but my initial impression is that mixing battlefield and
campaign doesn’t work very well, especially since you can automatically resolve
the battlefield campaign.  I am curious to hear from veterans RTW
players:  do you still play the battlefields at all after many hours?

I also had a hard time getting a good grasp of how certain key concepts of
the games are connected and how they play out together.  Maybe I am missing
out and I should spend more time on it, but I distinctly remember feeling very
much connected to Civilization right away, and its manual weighed a hefty 120
pages…

So I switched my focus to Dawn of War.

Warhammer 40,000:  Dawn of War

It’s pretty easy to be seduced by the sheer beauty of the game.  It’s
fun.  Pure, unedited, mindless, childish fun.  A lot of colored units,
great voice-overs, detailed animations that even now I find myself zooming into
(especially when a mech eviscerates a whole platoon).  And the combat
scenes…  oh my.  Lasers, missiles, grenades, and this is just in the
very beginning, I bet more sophisticated units will be coming up for even more
eye candy.

But is it the real-time strategy game I am looking for?

Certainly not.

First of all, the missions are very directed.  It’s not an all-out
battle with one team in each corner of the map and letting them duke it out. 
There is a story line and the levels follow it.  A frustrating aspect of
this is that some technology that is available at a certain level might be
grayed out at the next level.  This goes against my intuition, and against
simple common sense.  The best RTS games will not only provide you a gentle
tutorial but the missions themselves will slowly bring you up to speed with the
units you can use, and this progressive learning is the only way you can truly
master even an RTS game as complex as Civilization or Rise of Nations.

But overall, I just find that a simple way of winning at DOW is to rush. 
Plain and simple rush.  If it doesn’t work the first time, fall back,
regroup, reconstitute your army and try again.  Watch over your resources
and your energy, and you will inch your way into the computer’s field, who
doesn’t seem to be smart enough to reconstruct while you are rebuilding your
army of minions.  That’s disappointing.  Or maybe I should play at a
more difficult level.

Until then, I find myself going back to DOW once in a while because it’s
mindless, doesn’t need to much thinking or too much context and you can dive
right back into a game that you left several days ago. 

If you liked Warcraft 3, you will love Dawn of War.  If
you are more the Rise of Nations type, the title of best RTS to date is
still up for grabs.

Myst 4 : Revelation

And finally, I have found myself being suckered into Myst for the
fourth time (well, a bit more than that if you count Uru and its
extension packs).

Myst 4:  Revelation is a pure gem.  It’s by far the Myst
episode that strikes the best balance between jaw-dropping sceneries,
mesmerizing ambiance and reasonably hard puzzles.

Contrary to Uru (which would deserve an entry of its own), Myst 4
is not in full 3D.  It uses the same navigation technique as the previous
three episodes (discrete moves) but each location can be fully viewed in 360
degrees and above you (in other words, you can look around).  While I was
quite disappointed by this apparently step back from Uru, I got used to
it pretty quickly and since the familiar Zip locations are present, it’s fairly
easy to move around (with a notable exception, see below).

As I said above, what I like most about Myst 4 is this impression that
the puzzles are actually solvable by a non-lateral human thinker (that is: me). 
Uru was disappointing in this, as I found that I could never have solved
some puzzles in my lifetime other than by reading the walkthrough. 

Myst 4 is the opposite, and the very first puzzle you will face
(restoring the power of your base of operations) will give you a good idea of
what lies ahead.

But you need to have a very good eye for details.  And in doubt, not
hesitate to take a picture, because most of the time, it will come in handy
later.

Myst 4 takes you through several ages, each more beautiful than the
previous one (I am almost done with the third one right now) and while the size
of each world is daunting at first, it’s only a matter of time before you get
familiar with the various areas you can explore and you figure out how they
relate to each other.

Unfortunately, this also happens to be the only bad thing about Myst 4
it’s easy to get lost.

And I don’t mean losing yourself, I mean:  overlooking certain locations
because finding your way is everything but easy.  If there is one thing
missing from this otherwise-perfect adventure game, it’s a way to tell what the
possible paths are every time you reach a new location.

Barring this, the puzzles are quite enthralling and always logical.  If
you didn’t miss any location, an idea of how each age level will slowly form in
your mind as you discover new pieces of the puzzle and nothing is more thrilling
than when you can finally put your theory to the test and see it work (I even
found myself writing down a finite-state automaton once, although obviously, you
can certainly solve this problem differently and the only thing you really need
is simple common sense).

Overall, Myst 4: Revelation is one of the most immersive games I have
played in a long time, and I recommend it to not only Myst lovers but you
anyone curious to try something new.

Debuggers should be used even on new code

In
this TheServerSide thread
, Amin Mansuri has this to say about debuggers:

I dunno.. maybe I’m a bit old school, but I’m influenced by Steve McConnell
author of Writing Solid Code and Debugging the Software Development process who
suggests that you should step through all your code in the debugger before
checking it in.

Yes!

I actually got this habit from reading "Writing Solid Code" myself. 
Single-stepping through all your new code might be a bit
overkill, though, but I am a firm believer in the idea that debuggers should be
used on new code, and I find myself doing that very often as the result of
reading this book more than ten years ago.

Frankly, I don’t understand the argument "unit tests are good enough, I
don’t need a debugger" put forth by so many anti-debugger people.

First of all, even unit tests break and have bugs, so you have to debug at
some point.

But more importantly, unit tests only give you a superficial view of the
quality of your code.  Okay, the bar is green, but are you really sure your
code is behaving the way you designed it, and not by accident?  Or that two
bugs are not canceling each other out, yielding a good result by accident?

What better way is there to really make sure of this than by putting a breakpoint in
your fresh new code, single-stepping through it and verifying that all the
variables are what you expect?

Testing a testing framework

The best way to test a testing framework is, of course, to use it on itself. 
There are plenty of benefits to this approach:

  • I like to "drink my own champagne" (I prefer this analogy to "eating my
    own dog food", being French and all).  If I don’t use my own code
    in-house, I am missing an opportunity to receive important feedback.
     
  • It’s a great way to refine the listening API and make sure it covers all
    possible cases (this is the API that
    allows clients to be informed of when a test is being called, is succeeding,
    failing, etc…).
     
  • It also allows me to make sure that TestNG is reentrant, since it is
    basically calling itself.  This is important since TestNG supports
    parallel execution of tests, so no deadlocks are permitted.

With this in mind, the requirements for testing TestNG are as follows:

  • I need to be able to specify testng.xml programatically.  I don’t want
    to create sub XML files for each test.  Instead, I want to set up my
    testing environment completely in Java.
     
  • When I run the tests, I want to make sure that the right methods are
    called and that their status (pass, fail, skip) matches what I expect.

The design I have achieved so far allows me to write tests like this:

@Test
public void partialGroupsClass() {
addClass("test.sample.PartialGroupTest");
addIncludedGroup("classGroup");
run();
String[] passed = {
"testMethodGroup", "testClassGroup"
};
String[] failed = {
};
verifyTests("Passed", passed, getPassedTests());
verifyTests("Failed", failed, getFailedTests());
}

In this test, I specify the test class to be invoked and the group to be
included for this run.  Then I run the tests and compare the methods
actually run against the ones I expect to be run.

As you can expect, the class PartialGroupTest contains several methods, of
which only testMethodGroup() and testClassGroup() belong to the group "classGroup",
so I only expect these methods to be invoked and to pass.

Now, how does this work exactly?  It’s quite simple:  the
inner TestNG instance is configured in a "beforeTestMethod" method, so that
it gets invoked before each test method.  This way, I am guaranteed to
start with a clean inner TestNG instance for each test method:

@Configuration(beforeTestMethod = true)
public void methodSetUp() {
setPassedTests(new HashMap());
setFailedTests(new HashMap());
setSkippedTests(new HashMap());
// ...
}

This method is defined in a base class that all my tests inherit, so I don’t
need to worry about this when I write my tests.  It is also responsible for
setting itself as a listener to the inner TestNG instance so that it gets
notified each time a test passes, fails or skips.  Later, the method
verifyTests() can be invoked by each test method to compare the methods run
against the ones they expect.

This infrastructure makes it trivial for me to add new tests and new
functionalities and be test-happy.  For example, as I was writing this
entry, I realized I could also test failures of partial groups, so I added a
couple of methods that belong to the same group, made them fail with an "assert
false", verified that the test failed, then I added the names of these two
methods in the failed array and the test passed.

I cannot over-emphasize how important it is to have a testing framework that
is flexible and yet, easy to use.  No matter how you look at it, if you
don’t understand how your tests work and you are not clear on how to add tests
yourself, your work as a developer is sub-optimal and you are probably not as
productive and not as aggressive as you could be.

This applies to "real life" as well, where you are working with an entire QA
department that came up with its own testing framework and is responsible for
writing most of the tests.  If this testing framework is too complex for
you and your developers, you need to get together with your QA department and
come up with a way that both units can exchange tests easily.

 

Debugger tips

Debuggers are back in the spotlight with a recent post from Kasia.  She likes debuggers, so do I.

I have already expressed my views here and here on the importance of debuggers and my philosophy is quite simple:

No matter how productive you are with your current tools, I guarantee you will be more productive with an IDE and with a debugger.

I am pretty good with emacs and vi, with pinpointing potential bug areas by just reading code or quickly reading reams of output on a console, but at the end of the day, I just get things done faster if I add my IDE and a debugger to my arsenal of tools.  Ignoring this simple common sense is like being a caveman saying that he’s okay without fire.

The point of this entry is not to revive this debate (let’s leave cavemen into their caves) but to ponder the following question:  why is there almost no information on how to use a debugger wisely?  I don’t mean the user manual telling you how to set a breakpoint and how to single-step through code.  I mean a "good practice" guide.

As far as I know, this is not taught in school and hardly broached in books and I wonder why.  Is it because debuggers vary widely in scope and functionalities?

 I don’t believe this statement is true any more:  these days, debuggers have converged toward a very similar set of functionalities and except for a few innovations such as back-in-time debugging, you can reasonably expect your debugger to offer the same functions, regardless of the language or the operating system you are debugging in.

I would love to see a central place where all debugger tips and practices can be found, I’m sure there is a wealth of information waiting to be uncovered out there.

I’ll start with a few tips of my own.

Run method till it exits

Sometimes, you accidentally step into a method you didn’t mean to investigate, typically a library method.  You want to "get out" of this method so you can resume the debugging of the method you are really interested in.  You do this in Eclipse with the Step return button:

Press it and the current method will be run until it exits and the current frame is popped, taking you back to where the call was made.

Using conditional breakpoints.

I cannot overstate how important conditional breakpoints are.  Unless you are working on a very simple piece of code, the bug you are trying to find or the code you are trying to test will probably not be exercised right away, or it will be run several times without the parameters you are expecting.  The only way to get there faster is to type in entire expressions in your conditional breakpoint text box.

Using break conditions for println

As I stated in the link above, I’m not a big fan of "println debugging", which is antiquated and actually quite dangerous at times.  That being said, a bug sometimes happens after a certain number of iterations which cannot be easily captured by a conditional breakpoint (see below).  Or maybe, you just want to have some information about the state of the program displayed on stdout so that when you hit your breakpoint, the console contains some context information.

How could you do this without inserting println’s in your code?

Simple :  use a breakpoint expression that will do this println for you.

For example, the expression above could simple be replaced with "System.out.println(methodName)".  Since this expression will never return true, the program will never stop, but it will display the value of methodName throughout the entire execution.

Now, that’s what I call an efficient use of println and since the logic is contained in the debugger and not your code, no risk of shipping with it.

Of course, you don’t have to limit this to just println, you could just as easily modify existing variables or do some other crazy stuff…

How about you?  Any hot tips to share about your relationship with your debugger?

Type-ahead find in FireFox

I wondered for a while why FireFox’s "type-ahead find link" feature was not
working for me (type ‘ and then the link you are looking for).  I finally
figured out why:  this functionality looks for the text of the link, not
the href.

Which is a bummer because looking for an href without having to open the
source window would be quite convenient.

Does such a feature exist in FireFox?

 

Testing JMS and asynchronous code

I recently added a couple of features to TestNG that make testing
asynchronous code (such as JMS) very easy:  parallelism and time-outs.

Parallelism instructs TestNG to run your test
methods in different threads. 
The trick here is that some of these test methods depend on each other, so these
methods
will obviously be invoked sequentially in the same thread.  But all the
other test methods that do not depend on anything else will be run in a separate
thread, picked from a pool (which size is configurable).  Here is an example
configuration:

<suite name="Main Suite" parallel="true" thread-count="10">
<test name="First Test">
<classes>
<class name="test.Test1" />
<class name="test.Test2" />
</classes>
</test>
</suite>

After the run, you can use the
chronological view to see which methods were
invoked and in what threads they ran.

Another interesting feature is time-outs, where you can indicate that a
specific test method is expected to return within a certain number of
milliseconds.  If it fails to do so, it will be interrupted and marked as a
FAIL with a TimeOutException.

With that in mind, testing JMS (or asynchronous code) becomes trivial. 
For example, imagine that our application posts a message on a JMS topic
whenever an error condition arises.  Here is how you could test it:

public class ErrorMessageTest implements MessageListener {
// Used to block
private Object m_done = new Object();
@Test(timeout = 5000 /* 5 seconds */)
public verifyErrorMessageGetsPosted() {
// register this class as a listener on the error topic
// create the error condition
// wait for completion
m_done.wait();
}
// implements MessageListener
public void onMessage(Message msg) {
if ( /* msg contains what we expect */) {
m_done.notify();
}
// else, do nothing, wait for another message
// or for the time-out to kick-in
}
}

This code is fairly self-explanatory and it leaves the dirty part (handling the
time-out and multi-threading issues to the testing framework).

 

Google Desktop Search

I apologize for the plug but I wouldn’t mention it if I didn’t find this tool
incredibly cool…

Google Desktop Search radically
changed the way I search on my computer.  Check it out!

Guantanamo? Excuse me?!?

It was so obvious to me that

Guantanamo
(this name is very poor taste, by the way) was a joke that I
found the entire idea amusing, but now, I’m not so sure.  Aslak seems to be
awfully serious about it, but seriously… 

A tool that deletes lines of code that are not tested?  Surely,
even the most hardcore XP proponent wouldn’t be that radical and would just read
the reports of a coverage tool and use his judgment to decide whether the
untested code should be tested or not…

If anything is missing from Clover and other coverage tools, it’s a way to
tell "I know this part is not tested and/or exercised, but it’s okay".  But
a tool that will delete my code?

Come on…

The secret to writing books

Bruce Snyder is feeling some

distress about Word
:

Unfortunately I am required to use Microsoft Word to write this book. Anyone
who knows me knows that my choice would be VIM
but I haven’t figured out how to author XML documents that make use of
DocBook and keep some type of styles intact
upon conversion to Word.

Bruce, here is the secret: don’t mix the task of writing with the tax of
formatting.

First, write the text. Word, emacs, vi, notepad, it doesn’t matter. Just write
the text, the code, the remarks, maybe you can use a few newlines to help you
visually, but perform *no* formatting whatsoever. I call that "Typing kilometer
text" (yeah, I am still a metric system person).

Then when you’re done with a decent chunk (I usually do that after a chapter),
proofread yourself and start using the mouse to format your text.

I wrote my PhD dissertation and a book using this technique and the amount of
productivity I gained was just astounding. Plus, it allowed me to leverage the
strengths of all the tools (emacs and Word) while not being hampered by their
weaknesses.  It’s also a great way to "stay in the zone" when you are on a
good writing roll, and you don’t get distracted by stupid formatting issues.

And as a matter of fact, I just noticed I use this very technique for my
weblog entries as well…  You learn something every day.