Archive for 2007

“Next Generation Testing” book now available for preorder

Our book is now available for preorder on Amazon. The working title is “Next Generation Java Testing”.

It’s approximately five hundred pages of dense Java-related testing information illustrated by a lot of (mostly small) listings and code snippets. The Rough Cut version is also available on Safari.

It should be publicly available in November.

Opening your source doesn’t make your software more secure

In an article comparing Windows to Red Hat, Microsoft recently used the following quote from former chair of the Apache security team Ben Laurie:

Although it

A fond farewell to Harry Potter

Note: this post contains absolutely no spoilers on any of the seven Harry Potter books.

I just turned the last page of “Harry Potter and the Deathly Hallows” and I have to say that this was probably one of the most enjoyable books I’ve read in years.

It’s not a compliment I give lightly, and unfortunately, most of the books that I read are very easily forgettable, but the Harry Potter series has managed to keep my interest up ever since the first one came out.

I remember noticing a friend reading it shortly after it came out. I had never heard of Harry Potter before and a quick glance at the back cover prompted me to ask the question that tens of thousands of people have asked these past years about Harry Potter: “Isn’t this a child’s book?”.

Not that there is anything wrong with reading child’s books. As a matter of fact, just a few years ago, I made a point of reading up on some classical children stories (such as the Chronicles of Narnia) in order to catch up on this aspect of the American culture I didn’t grow up with. My interest was therefore piqued about Harry Potter, and when my friend observed casually that “Yes, but there’s something about the way this is written that makes it really gripping”, I quickly bought the book and started a long journey in the depths of the wizarding world.

In hindsight, there are two points that I absolutely adored about the series, and particularly that last book:

  • It’s a complex plot even though it’s written from Harry’s perspective pretty much all the time.

    I tend to like books with elaborate plots, twists and big arcs that form a complex story. These books usually unfold their plot by switching points of views, places, people and sometimes even points in time. These artefacts are necessary to set up the background for your readers and, to some extent, to confuse them a bit. It’s a bit like prestidigitation and sleight of hand: you want to set up your readers so that you can surprise them with A when they expect B.

    This kind of magic trick is much harder to achieve when you’re writing your story completely linearly and following your hero from page one until the end. Except for a few flashbacks, you don’t have a lot of freedom to set up your twists and revelations, which must all occur through the eyes of your hero.

    I think J.K. Rowling’s mastery in this art will be studied in literary schools for years to come.

  • It’s pretty obvious that J.K. Rowling knew where she was going with her story from the first book on.

    This last book contains revelations and explanations that are absolutely startling and yet perfectly consistent with the previous books. Maintaining coherence and vision throughout seven books written over several years is no small feat, and while similar books and TV shows are frantically trying to keep up with their own contradictions and cheap cliffhangers to try and maintain the illusion of a vision (I’m looking at you, “Lost”), J.K. Rowling’s reigns supreme in the art of building up an epic yet entertaining world (as opposed to… “The Lord of the Rings”, which is complex but dull).

    Harry Potter is one of the most sophisticated and best written plot ever created, along with Babylon 5 and Perry Rhodan.

I have felt sad every single time I have turned the last page of a Harry Potter book, and this one is no exception, except that the melancholy is increased by the realization that it’s now time to say goodbye to our spell casting friends for good.

Here’s to hoping that J.K. Rowling’s next creation won’t take too long and that it will be as enthralling as the Harry Potter saga.

Half Dome

We’re just back from a fantastic weekend in Yosemite, where we hiked Half Dome (Google Search, Google Earth link). If you haven’t already, I strongly suggest installing Google Earth and clicking on this link: the 3D view of the Dome is absolutely gorgeous (and remember you can tilt the view with Shift-Arrow Up/Down).

Unless you live in California, you have probably never heard of Half Dome. It’s not the highest peak in Yosemite Valley, but it’s famous for the hike that leads to its top, which is also said to be the most difficult in the entire park.

Here is the outline of our hike:

  • Total distance: 17 miles.
  • Vertical gain: 4800 feet.
  • Total time on the hike: 13 hours.
  • Quantity of water consumed: about a gallon.
  • View from the Spring Board on top of Half Dome: jaw-dropping.

Fortunately, there are several stages along the way that make the experience quite rewarding, even if you decide to turn around before you reach the top:

  • After the first 1.5 mile, you reach Vernal falls, which towers above the Happy Isles while giving you a good idea of what a vertical drop of gushing water can look like.

  • 2 miles later, you arrive at Nevada Falls, which is just a bit higher than Vernal Falls but offers an equally stunning view of the valley and a vertical drop that will make you dizzy if you lean forward too much.
  • The next 4 miles meander through Little Yosemite Valley and are fairly flat. This section allows you to walk around Half Dome in order to orient you toward the side that can actually be hiked (the side that is facing the valley is a vertical drop that attracts rock climbers from around the world).
  • The mile that follows starts going up more severely, but the beautiful pine trees and occasional view of the valley below give you a good reason for stopping and catching your breath.
  • Then you arrive at the bottom of Half Dome and you are facing your next challenge, sometimes referred to as “Quarter Dome”. It’s a series of very vertical steps carved inside the granite that allow you to climb over the first hilly part of the Dome. This section in itself would be enough for a casual hike, and it certainly got all of us out of breath by the time we reached its top.
  • And finally, you’re at the bottom of the Dome. By then, you only have about nine hundred vertical feet to overcome to reach the top, but the incline there is above fifty degrees, so a pair of metal cables have been drilled into the rock to allow climbers to get through this last section. It’s imperative to bring gloves with you or depend on the kindness of strangers who would be willing to part with theirs (it’s actually quite common). This part of the hike is not the hardest per se, but it will certainly put your vertigo sense to the test, especially when you climb it down (hint: do it in rappel. It’s not just that it hides the scary sight of the void beneath, it just makes the climb down much easier).

The hike is certainly strenuous, but nobody in our little group can even be remotely called a hiker. Yet, we pulled it off, and with us, dozens of other courageous hikers of all ages and fits that we saw along the way. Don’t let this description intimidate you, this is something that everyone should do at least once in their life.

An unforgettable day.

Dynamic and static languages are fighting again

There is quite an interesting discussion going on at Artima about the age old subject of static and dynamic languages. I found the following quote particularly interesting:

Maybe we should look more closely at the kind of programs being written in Ruby and Python and Javascript, and the way good programmers use those languages, to understand if there are reasons that refactoring might seem less obviously helpful in those languages.

I’ve read and written a lot of reasonably long (> 10,000 lines of code) programs in various dynamic languages (Python, Ruby, PHP and more obscure ones as well) and I haven’t seen any evidence that refactoring is less needed in these languages.

Granted, these listings sometimes have constructs that would take more code to write in Java, but here is the catch: if you are using a more expressive language, you don’t write shorter programs, you write programs with more functionalities in them. And at the end of the day, you face the exact same problem that Java and other statically typed languages face: you need to refactor if you want your code to evolve.

I feel much more comfortable refactoring Java code than I do Ruby or Python. It doesn’t even matter whether I authored that code and how confident I am about the test coverage. I just know that I can’t rely on the compiler and the type system to catch my mistakes, and this impacts my productivity immensely. Suddenly, I’m more hesitant and I’m afraid to break something with my changes.

Here are a few select quotes from this discussion that match my own experience very closely:

What I find in Python is that I can barely reuse my old code, much less modify it without a lot of pain. (James Watson)

I, at least, find that my Ruby or Javascript code degrades over time more than my Java code does, mainly because I get lazy and avoid refactorings that I would be more likely to do if they were safer and more automatic. (Alan Keefer)

Ultimately, I have found that big programs written in dynamic languages don’t age as well as those written in a statically typed language because developers are more afraid to refactor them. And rightfully so, since certain refactorings are just plain impossible to achieve automatically in these languages (another reason why duck typing is too dangerous to use in large scale projects).

The bottom line is actually fairly simple: nothing beats a dynamic language to write a prototype, but if you know that the code will have to be maintained and that it will be in use for several years, the initial cost of using a statically typed language is an investment that is very quickly amortized…

In defense of Design Patterns

It’s interesting to see that the Design Patterns book has been coming under mild fire lately. I say “mild” because what I have seen so far is more of a criticism than an all-out attack.

Over the past year, I have been giving a presentation called “Designing for Testability” in which I offer a few recommendations and observations on what a developer needs to do to make their code more testable.

When I started thinking about this topic, I was surprised to realize that some of the guidelines that one needs to follow in order to make one’s code more testable are directly at odds with some principles that we have taken for granted for such a long time. The principles under attack come from various areas, such as object-oriented programming and, not surprisingly, Design Patterns such as those described in the book. I’ll list two of these ideas below just to give you an idea, but I’ll save a deeper discussion of what I mean for a future post, since I’d like to make a different point in this article.

Here are some of the principles you need to question if you want to make your code more testable:

  • Extreme encapsulation. It’s a good OO principle, but it can make testability challenging.
  • The Singleton pattern. While Singletons themselves are not necessarily harmful, their recommended implementation so far — using static methods and variables — usually leads to code that’s hard to test.

Having said that, I think the characterization that “Design Patterns aren’t”, from a presentation given by M. Dominus in 2002, is wrong on many points, as is the more recent follow-up by Jeff Atwood on the same topic.

In this article, I find that the author is doing two questionable things:

  • Criticizing Design Patterns without offering an alternative.
  • Making a parallel between Alexander’s construction Design Patterns and software ones.

The first point is probable more of a personal one: I highly respect the practice of criticism, but if is not followed by concrete proposals to remedy the problem, I find the attitude very questionable. Like we say, “La critique est facile, l’art est difficile”.

The second point deserves a more lengthy response.

Alexander’s book leaves a lot of room for art and personal creation, which shouldn’t come as a surprise: building is indeed an art, and the final work needs to be both safe and functional and pleasant to the eyes of onlookers, residents and occasional visitors alike.

The part of art in software engineering is, in my opinion, much more restricted. There is only so much beautiful code or harmonious class hierarchies that you can create. Conversely, the foundation of a software architecture must obey a lot of fairly strict rules in order to be solid, maintainable and evolvable.

Criticizing Design Patterns is like saying that the nuts and bolts that keep a bridge together shouldn’t be designed with templates and cookie cutters found in factories, but instead, be more open to the creative thoughts of engineers.

There is a reason why it’s important to establish a clear separation between Alexander’s Design Patterns and the GOF’s Design Patterns: software engineering is nowhere near as advanced as building engineering is. We are still working on these nuts and bolts, and whenever a new software project starts, we still can’t be sure it won’t collapse under its own weight after just a year. To make a parallel: imagine a world where every time a new construction takes place (say, a bridge), the future of that bridge depends on the team of engineers and workers you choose to build it…

Scary thought. It’s a relief to think that while we might still be building ugly buildings and towers, we can be reasonably sure that the engineering principles that underlie these constructions are scientifically sound and empirically proven, and that these building won’t collapse into a pile of twisted metal for no reason.

The reality is that we are still struggling in software to reach this kind of certainty. We haven’t quite invented software nuts and bolts yet, but the GOF’s Design Patterns book is a very good start that no software engineer should ignore. Yes, there is a good amount of cookie cutter recipes in this book, but I see this as a good thing. The more templates we come up with to lay out software foundations, the more software developers will be allowed to focus on aesthetic considerations.

Our software needs to be solid before it can be beautiful.

iPhone tour

Here are a few thoughts that popped into my mind as I was watching the iPhone tour video:

  • Can’t start typing a number or a few letters to place a call (either you select from the address book or you remember the full phone number).

  • Visual voice mail rocks.

  • Touch screen is good for many more activities than I thought (but I suspect, still terrible to type text).

  • Overall, it’s quite striking to see how the UI (and the entire demo) downplays typing. Quite a contrast compared to how much typing is used in iTunes or search on Mac OS. For example, if I want to add the picture of Sarah Young to her contact info, I would start typing “y o”. With the iPhone, you have to scroll through your address book (lucky him, there is only one entry in the “y” category, what a coincidence!).

  • Is it possible to buy something from the iTunes store from the phone? (not shown in the demo, so I’m guessing not).

  • Good handling of the headphone/music/incoming call activity.

  • Safari: “renders just like on your computer”. Honest.

  • Web page zooming is cool.

  • Google button!

  • The typist doesn’t seem to make any mistakes with the keyboard. I’m still a bit skeptical about that, but we’ll see. Good to see they have spelling correction (and nice demo with the thumbs).

  • Claims Gmail access… Probably through POP… lame.

  • Can check email automatically.

  • Maps looks awesome. With traffic! (network access too fast to be true, though). The turn by turn instructions don’t seem to do text to speech, unfortunately.

  • “There are many ways you can customize your iPhone”… as long as you choose black.

Announcing TestNG 5.6

I’m happy to announce the release of TestNG 5.6. The Eclipse and IDEA plug-ins have also been updated to this new version.

Here is the change log.


  • Added: SkipException/TimeBombedSkipException for manual skipping
  • Added: <tests> can now be disabled at xml level using <test enabled=”false”>
  • Added: Suite files that only contain other suites do not get reported
  • Fixed: @BeforeClass methods would incorrectly report cyclic graphs
  • Added: get/setAttribute to ITestContext
  • Added: plugging in factory objects to handle the actual instantiation of tests
  • Added: dataProvider to @Factory
  • Added: ISuite now gives access to the current XmlSuite
  • Fixed: TESTNG-139 dependsOnMethods gets confused when dependency is “protected”
  • Fixed: TESTNG-141 junit attribute set to false in testng-failed.xml when it should be true
  • Fixed: TESTNG-142 Exceptions in DataProvider are not reported as failed test
  • Added: Improved behavior for @Before/@AfterClass when using @Factory
  • Added: Support for concurrent execution for invocationCount=1 threadPoolSize>1 and @DataProvider
  • Added: New TestNG specific XML report, generated by default in ‘xml’ subdirectory of test-output
  • Added: support in strprotocol for passing the ITest.getTestName() information
  • Fixed: TESTNG-152 If DataProvider is not found, the exception message should tell exactly what happened

Eclipse plug-in

  • Fixed: Bug that made group launch configurations unusable
  • Fixed: The plugin doesn’t create the correct launch configuration for @Factory
  • Fixed: Method based launchers cannot be editted
  • Fixed: Plugin hangs while executing test with dataprovider that sends \n, \r messages
  • Added: display ITest.getTestName()

IDEA plug-in

  • Fixed: IDEA 7.0 compatibility
  • Fixed: occasional ‘illegal arguments exception’
  • Fixed: TESTNG-151 Final passing test result is not properly hidden
  • Added: Auto-completion for dependsOnMethods
  • Added: Highlighting of invalid groups/methods in dependsOn*

I, for one, welcome our new offline AJAX overlords

Werner Schuster is making a few interesting remarks about Google Gears and how concurrency is implemented in Javascript. However, I’m quite puzzled by his following statement:

I still hope that AJAX will die a quick death, like Java Applets, just for being so damn ugly and horrible to implement.

Mmmh… AJAX ugly? Are we talking about the same thing?

AJAX is just the underlying medium. It’s a loosely defined set of language and design constructs that make it possible to fetch data asynchronously while displaying an HTML page. It’s like oil in your engine: it’s dirty and smelly, but you couldn’t get anywhere without it and if you’re not a mechanic, there is very little reason why you should ever have to manipulate it.

Werner is probably referring to the pages themselves that are using AJAX behind the scenes, and there is obviously not much that can be done about this UI problem except wait for the market (and the UI designers) to mature and get comfortable with this new paradigm.

As for AJAX being horrible to implement… well, not any more.

Yes, the low-level details are ugly, but you can’t expect any less from a foundation API. The early days were tough for programmers, but nowadays, there is really no excuse to reimplement another browser-neutral XmlHttpRequest layer. Whatever you want to do with AJAX, you can now do it in the language of your choice, and for each language, you easily have a handful of different toolkits at your disposal.

The way I look at it, AJAX is a liberating technology. I can’t wait to see what kinds of products await us in the next few years, and I certainly hope they will be built upon AJAX while allowing me to get work done while off-line.

“One laptop per child”, as long as they buy it from me

I’ve been a big fan of the “$100 laptop project” ever since Nicholas Negroponte made it public. The idea that tens of thousands of kids and adults located in remote and poor areas of the world will get a chance of being exposed to computers and the Internet for such a cheap price struck me as one of the best charity ideas I heard in a long time.

Negroponte has had to face numerous challenges along the way, and even until very recently, there were still a lot of people claiming that the project would never succeed.

They were wrong.

The laptop finally happened, and even though the price ended up being more expensive than initially announced (in the $160 range), the computer is real (I played with one) and is now beginning to ship to countries interested in buying them in batches. And of course, its price will decrease in the coming years.

Intel recently announced their own laptop initiative which, of course, will run on an Intel processor, as opposed to Negroponte’s computer, which uses an AMD. Initially a very strong opponent of Negroponte’s project, Craig Barrett, Intel’s CEO, made an about face and decided to put his company behind a similar effort.

It all sounded great to me. The more computers for the kids, the better, right?

Negroponte doesn’t seem to agree and he’s now accusing Intel of trying to drive him out of business:

Intel should be ashamed of itself.

What’s even more shocking about Negroponte’s stance is that “One Laptop Per Child”, the foundation he created for this project, is purely non-humanitarian and non-profit. How can he then justify his hostility toward a project that would make computers available to even more children than he had ever dreamed of? Is this a case where personal pride is taking over charity goals? Does he prefer to go down in history as a disgruntled first mover instead of the inventor of the $100 laptop?

I can understand that he might be angry at Intel for trying to derail the project in its early phases, but isn’t there a picture that’s greater than these two men?

What’s the worst that can happen? More computers at a more affordable price?

Come on, now. Just think of the children.