Archive for November, 2004

Mysterious comments

I am baffled by the comments that this older weblog entry is receiving.  As you can see, I am simply announcing that I moved some of my projects over to  Since then, it appears that a group of Indian students have not only misunderstood the point of that post, but are also maintaining the delusion that I am offering to provide ideas for Java projects that they could do for their final year exam (on what major or studies?  I have no idea).

The phrasing of the request is also quite rude, and even though English is obviously not their native language, they are most likely able to express themselves fluently in this language.  At any rate, it doesn’t give a very good impression.

Also, none of them seem to have noticed that I haven’t offered a single idea, but the presence of the comments seems to maintain this illusion.  Maybe I should just delete the comments once and for all.

Or can a fellow Indian reader shed some light on what’s happening?

TiVo and the future of advertising

I’ve had a TiVo for almost three years now and like most TiVo users, I am an unconditional fan of the level of comfort it has brought to my TV watching experience. Actually, TiVo did such a great job in terms of functionality and UI that I hardly see any point in upgrading my Series 1 to the newer model.

Recently, TiVo has come under fire after their announcement of a new feature in their box that will display commercial banners during fast-forwards of commercials. The community went up in arms about this announcement and a Tivo employee recently intervened in the forums to clarify the upcoming feature.

This seems to have soothed TiVo’s fans, but I am still wondering why the announcement caused so much uproar in the first place. To me, the main threat to TV watcher comfort is not clever tricks to make commercial breaks more attractive but in-place advertising.

I have alrady seen this kind of advertising several times these past months, among which:

  • During the World Series, a car brand advertising regularly “unfolded” from the scoreboard, sat there for a few seconds and then “folded back in”. This was happening every four or five minutes.

  • Various TV channels have been showing animated previews of their upcoming shows in a banner at the bottom of the screen. Again, note that this animation is happening in the middle of the show you are currently watching (they seem to be coming up shortly after a commercial break ended).

This form is advertising is deadly effective for several reasons:

  • It is shown during your show, and you are not going to fast-forward through it.

  • It is not subjected to the air-time limit that commercial breaks have. I am not sure if this is regulated in the US but even if it’s not, networks need to be careful not to show too much ads during their shows or they will turn off their audience for good. These days, it seems that shows are typically interrupted by four commercial breaks that amount to no more than 15 minutes per hour. In-place advertising has theoretically no such limit…

  • It is animated. No matter how hard you try, your eyes are inescapably pulled in
    its direction

  • It appears to be almost impossible to circumvent, even by clever devices such as TiVo.

This last point is the most distressing, and actually, I don’t believe a DVR manufacturer would even try to circumvent those ads because they need to walk a fine line between pleasing their customers and not angering the advertisers. If you
wander too far on either side of this line, you will either lose your customers in drove or your company will get sued out of existence, a lesson that ReplayTV learned the hard way.

So far, Tivo has been very smart in the various compromises they have made, and I believe this new feature is overall good for everyone. But I confess being worried about the new form of TV advertising
that is discreetly creeping on our TV screens.  Well, that and advertising
in theaters, but that’s another story.

MIDP absurdity

In J2ME, MIDP is the library that allows you to build user interfaces (among
other things) and its functionalities obviously much simpler than even AWT. 
The two classes of interest are:

  • Form, which supports structured widgets called Items (TextField,
    ChoiceGroup, etc…)
  • Canvas, the lowest-level class, where you need to paint everything

Faced with the task of building a User Interface, a J2ME developer will typically
consider the following options, in increasing order of difficulty:

  1. Use a Form with the standard Items.
  2. Use a Form with custom Items.
  3. Use a Canvas.

For obvious reasons, the standard Items are pretty crude and offer only the
simplest functionality.  On the other hand, writing a Canvas from scratch is quite challenging
and requires a lot of geometric calculations and 2D drawing.  Therefore,
option 2 presents a strong appeal, striking a good balance between the other two

Taking a look at the Item class, we see that it has three abstract methods,
one of which is paint() and the other two return size-related information. 
So far, so good, it seems simple enough.

Except that…  Sun made it impossible for you to extend Item in MIDP


Because the Item class only has package-protected constructors:

public abstract class Item {
Item(String label) { ... }
Item(String label, int num) { ... }

And a closer look at the class reveals that even the abstract methods
mentioned above are package-protected as well…  I’m not sure what genius came up with this design but more distressing
is the fact that Sun actually shipped this class, which is installed on millions
of devices as we speak. 

Interestingly, they seem to have realized their mistake because MIDP 2.0
comes with a new class, CustomItem, which exposes the carefully hidden
constructors to the outside world:

public abstract class CustomItem extends Item {
protected Item(String label) { ... }

It’s too bad that MIDP 2.0 will not be widely available on phones before at
least a couple of years…

Until then, it’s back to good-ole Canvas programming.  It feels like
1996 all over again.


Entbloess: Expose on Windows XP


Circular dependencies are not always evil

Mike Spille’s article on Inversion of Control containers
was, as always,
thoroughly researched and quite illuminating.  It also brought up the old issue of cyclical dependencies, which are usually identified
as a very ugly practice.  Software fundamentalists are quick to point out
that if you see a cycle in your classes or your packages, you should immediately
remove it.

I wish it were that simple.

The sad truth is that sometimes, cyclical dependencies are not only
necessary, they are actually quite essential and contribute greatly to making
your code more readable and maintainable.

The dangers of cyclical dependencies are well-known (stronger coupling,
fragile build, etc…) as are the remedies (the introduction of an interface is
usually a good start).  For example, the following dependency:

public class Person {
public List<Account> getAccounts();
public class Account {
public Person getOwner();

can be refactored like this:

public interface IAccount {
public class Account implements IAccount {
public class Person {
public List<IAccount> getAccounts();

By introducing an interface, you have decoupled your two concrete classes,
which is usually a good thing.

The point of this post is not to offer a
critique of this method but to bring up two points:

  • Your code is more decoupled but it’s also more complex.
  • The concept of a "cyclical dependency" is highly dependent on the
    language you are using.

The second point is obvious:  the perception of a "cyclical dependency" is very different in
Java and, say, in C++, where you will usually declare and implement two coupled
classed in the same file, thereby reducing the physical dependency (but not the
logical one).

The first point is more subtle.

In the example code above, you now have three classes where you used to have
two.  And two of these three classes need to be kept in sync (IAccount must be modified whenever
you modify Account).  As I said earlier, it is usually a good thing, but
not always, as was the case with Mike’s JobDispatcher example.

I find that most of the time, cycles are created as a consequence of a
previous refactoring in which you have been breaking down one complex class into
two smaller ones.  There is clearly tension between two goals that are
sometimes at odds:  you can’t always decrease both the complexity and the "coupledness"
of your code (I know it’s not a word, sorry, couldn’t come up with a better
one).  If you improve one, you will probably make the other worse.

Overall, introducing an interface in your code is usually the right choice,
but there are some exceptions.  Keep them in mind the next time someone is
trying to convince you that your code is evil because two classes have a
circular dependency on each other.


A view from the sky

Keyhole is a pretty impressive piece of
software, I strongly suggest you take it for a spin.  It’s become my new
way to locate addresses.

Make sure you check out the forums as
well, they are very active and users share various links, placemarks, overlays
(they started mapping Mars and the Moon) and other locations of interest. 
Also, make sure you check the "tilt" feature (the arrow on the right at the
bottom of the screen):  it will tilt the landscape so you can do a fly-by
of the landscape.  Very impressive, although it won’t work for elevations
the size of buildings but it does wonder to explore ski runs.

Here are a few to get you started.  These are XML files that will
automatically take you to a location if you double click them after you saved
them on your computer.  Clicking on them in your browser will probably only
show you the XML content, but it’s a good way to make sure they are not
dangerous 🙂

I wish I had learned geography in high school this way, I would certainly
have paid more attention…


Why chaining constructors is bad

I personally find that this code snippet demonstrating constructor chaining is hard to read.

This code makes it very hard to identify which of the many constructors is the "real" one:  the constructor that does the real job and that I should call if I add a new overloaded constructor.

This is why I use the following two rules when I write overloaded constructors:

  • Have all your constructors converge toward one unique private method that you will name consistently throughout your code base (e.g. init) and that will contain the entirety of all the parameters that your constructors may receive.
  • Don’t add any logic to the constructors, all they should do is invoke init with the right parameters and null for default ones.

Here is an example, from worst:

public class Person {
  private String m_firstName = null;
  private String m_lastName = null;
  private long m_ssn = 0;
  public Person(String lastName) {
    m_firstName = null;
    m_lastName = lastName;
    m_ssn = getSsn();
  public Person(String firstName, String lastName) {
    m_firstName = firstName;
    m_lastName = lastName;

to better:

public Person(String lastName) {
  this(null, lastName);
  m_ssn = getSsn();
public Person(String firstName, String lastName) {
  m_firstName = firstName;
  m_lastName = lastName;

… to best:

public Person(String lastName) {
  init(null, lastName);
public Person(String firstName, String lastName) {
  init(firstName, lastName);
private void init(String firstName, String lastName) {
  m_firstName = null;
  m_lastName = lastName;
  if (null == m_firstName) {
    m_ssn = getSsn();

Here is why the latter form is preferable:

  • It doesn’t duplicate any code.
  • It makes the initialization rules clear : "if no firstName was given, then ssn gets initialized".
  • The signature of init gives a good indication of the various parameters this class needs to be initialized, while a multitude of overloaded constructors obscures this fact.


A victory against spam? Not really.

Cameron rejoices
over the fate of two spammers who were convicted, fined
and jailed in Virginia.  Unfortunately, this is a pyrrhic victory since
these spammers are actually being convicted for fraud:  the article they
sell simply does not exist.

I will start celebrating when even sellers of legitimate goods get fined for spamming.

The American voting system mess

I have been in this country for more than six years and I just learned
something really disturbing about the American voting process :  you don’t
need to show any id when you vote.  This is so baffling that I had to
confirm this information with several friends (I’m not a citizen yet so I’ve
never voted here).  And they all confirmed it.  All you need to do is
show up, give your name and address, sign, and you can cast your ballot.

This is mind-boggling.

I can understand that it’s hard to compile a nation-wide list of registered
voters (although this obviously needs to happen at some point, especially for
something as important as voting), but not even requiring voters to carry an id
when they vote is just beyond anything imaginable.

But it gets worse.

It appears that the Constitution allows the various parties in place to send
"challengers" to voting places:  people who sit there, watch voters go by
and who can arbitrarily challenge any person’s right to vote.

It’s not hard to imagine what these decisions will be based on:  skin
color, accent, mannerism, you name it.  And this is part of the

Recently, this section has been challenged by various civil right activists
and it appears that at least in Ohio, one of the major swing states, challengers
would not be allowed.  However, I just heard this morning that this
decision had been overturned and that challengers would indeed be let in at the
polling places.

What a mess.

So we have one wrong (you don’t need to show up id at the polling place) that
it tentatively fixed by another wrong (people can randomly challenge your right
to vote).  Add to this the recent fiasco of electronic voting machines and
the very questionable Electoral College system (which has arguably been shown as
very valid three centuries ago but a dangerous anachronism today) and it makes
you wonder how come the greatest democracy of all times reached such a point of
despair in its very roots.