November 29, 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 java.net. 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?
November 21, 2004
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).
- 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.
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.
November 19, 2004
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 yourself.
Faced with the task of building a User Interface, a J2ME developer will typically consider the following options, in increasing order of difficulty:
- Use a Form with the standard Items.
- Use a Form with custom Items.
- 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 options.
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 1.0.
Why?
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.
November 18, 2004
Entbloess: Expose on Windows XP
Exposé is a cool application switcher that runs on MacOS. When invoked, it displays all your windows tiled neatly so you can pick the one you want to switch to. I recently heard about a similar application for Windows XP called Entbloess 2. I am not a MacOS fan but I'm curious, so I tried it and it does exactly what Exposé does, including the smooth transition. Users of both MacOS and Windows XP will be pleased.
Having said that...
- It crashed when I tried to move my cursor to my second screen.
- It disrupts the stacking order of your windows.
- What the hell where they thinking when they came up with that name? Even though I installed it, I couldn't remember its name in order to write this entry and I had to look on my hard drive to refresh my memory. The irony is that their main Web site doesn't even come first on a Google search. (Update: Andre Weynand pointed out to me that Entbloess means Exposé in German... Doh. I speak a little bit of German but obviously not enough. Thanks Andre!).
The second point is a deal breaker for me. I am fairly familiar with the way Windows arranges my windows so that I can pretty much ALT-TAB and ALT-SHIFT-TAB without even looking. I do that all the time and since I usually cycle between three or four applications maximum, I am able to switch windows very fast. But if you change the stacking order from under me, you force me to look for my windows visually, which is exactly what I wanted to avoid in the first place.
Another reason why Entbloess is not for me, but maybe it is for you. Despite these limitations, it's still a cool-looking little application.
November 17, 2004
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.
November 11, 2004
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...
November 05, 2004
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.
November 03, 2004
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.
November 02, 2004
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 Constitution...
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.