Otaku, Cedric's weblog: December 2005 Archives

December 31, 2005

Java2Html

I just discovered Java2Html.

There are many code highlighters that let you take code snippets and include them in HTML pages while preserving their colors, but they all suffer from two problems:

They are Web-based (you need to copy/paste your code to the form, submit, get the result back and paste it in your HTML file).
They are CSS-based, which forces your HTML page to include that CSS file as well.

Interestingly, this is one of the rare cases where separating style and content, as enabled by CSS, is an annoyance.

Java2Html solves these two problems by:

Providing an Eclipse plug-in (and also a standalone Swing application if you prefer), therefore allowing you to do everything from Eclipse.
Embedding font information directly in the HTML generated (no CSS), so that it's really a matter of copy/pasting the code as it is into your HTML pages (and Java2Html lets you either put the generated code in the clipboard or in a file).

Simple and effective.

Posted by cedric at 06:17 PM | Comments (7)

December 26, 2005

Mysterious operator

Did you know that Java has three "and" operators?

First, there is the very common logical and: &&:

if (x >= min && x <= max) { ... }

Then, there is the bitwise and operator, which very few programmers will probably ever use:

if (x & 1 != 0) { ... }

And finally, there is...

public static boolean isBetween(int x, int min, int max) {
boolean result = (x >= min) & (x <= max);
return result;
}

Take a close look at this code. The expression calculated for result uses what looks like the bitwise and operator, and yet it seems to operate on boolean values (respectively x >= min and x <= max) and not scalar ones.

There are actually two startling things in this code:

& operating on booleans.
The result of & being a boolean, and not a scalar.

The solution to the puzzle is given in the Java Language Specification, chapter 15.22.2:

15.22.2 Boolean Logical Operators &, ^, and |
When both operands of a &, ^, or | operator are of type boolean, then the type of the bitwise operator expression is boolean.
For &, the result value is true if both operand values are true; otherwise, the result is false.
For ^, the result value is true if the operand values are different; otherwise, the result is false.
For |, the result value is false if both operand values are false; otherwise, the result is true.

For all intents and purposes, it looks like the boolean logical & operator is exactly similar to the logical && operator. Is that so? Not really. If you run the following program:

public static boolean f() {
System.out.println("false");
return false;
}

public static void main(String[] args) {
System.out.println("&&");
boolean a = f() && f();
System.out.println("&");
boolean b = f() & f();
}

You will get the following result:

&&
false
&
false
false

As you can see, && will skip the second expression if the first expression is false (because at this point, it knows that the overall result will be false, so there is no point in evaluating the remainder of the expression) while & will always evaluate all its operands. Similarly, || will stop evaluating its operands as soon as one is found to be true while | will always evaluate all of them.

Not surprisingly, logical operators are the most useful because not only do they typically run faster than their boolean counterparts, they also allow to write convenient expressions:

if (p != null && p.hasChildren()) { ... }

With that in mind, when would you want to use a boolean logical & or | operator?

The theoretical answer is: whenever your code depends on side effects performed by the operators involved in the expression and you want to make sure that all of them are invoked, regardless of the final result of the expression.

Why do I say "theoretical"? Such code would probably qualify as a design smell because having methods that return a value and perform side effects are usually frowned upon. Having said that, it is not an absolute rule and I have found myself having to do this a few times, so I would rather discourage the use of boolean logical operators for a totally different reason: don't use them because they will confuse readers of your code.

Can someone come up with a convincing use for a boolean logical operator?

Posted by cedric at 07:02 AM | Comments (11)

December 19, 2005

Bluetooth marketing: it's happening

I was walking in a mall this past weekend when my phone started vibrating. I checked out my SMS inbox to find a message from "EB WGPortal" with a .sis (a Nokia native application attached to it. I retraced my steps and found out that I had just walked past an EB Games store, which I strongly suspected was the sender. So I stood in line for... well, a while, as you can imagine, and finally showed my phone to the attendant and asked him:

"Can you explain this?"

He was dumbfounded, turned to his colleague who knew about it.

"Yes, we have an upload pad in the store. You can run the application attached to the message and it will install on your phone".

"Okay, but what is it?"

"Previews for games, screen savers, etc..."

"How do I know the application is safe to install on my phone?"

"Er..."

I am wondering if Bluetooth marketing is going to work.

First of all, I wonder if the fact that they sent me a .sis is a coincidence or if they were able to determine that I owned a Nokia (is this even possible via Bluetooth?). Will people willfully install applications sent by random stores without knowing exactly what they are? Text messages, sure, that's harmless and it doesn't add to your bill, but applications... now that is bold.

Anyway, I have been waiting for such a moment for a while, it looks like it's finally happening.

Have you had similar experiences?

Posted by cedric at 09:00 AM | Comments (32)

December 15, 2005

The fan syndrome

Imagine that you are a reporter sent to the gates of a stadium shortly before a very important baseball game between the Giants and the Athletics (sorry, Bay Area resident speaking here. For my non-American readers, please replace these with names of famous soccer teams). Your mission is simple: ask people entering the stadium who they think is going to win.

If you ask Giants fans, the answer is guaranteed to be "The Giants, of course!". Well, that's fine, but that was not the question. You didn't ask them who they wanted to win, but who they thought was going to win.

The only problem is that in most people's minds, these questions are completely equivalent.

But they shouldn't.

After all, no matter how much of a Giants fan you are, you might know that their star player is currently injured, another one is not playing today and that the other team has been winning a lot of games recently and on top of that, they are playing in their own stadium. With this in mind, reason should clearly tell you that no matter how much you want the Giants to win, the odds are against them for this particular game. It seems to be common sense, but yet, you will probably not find a single fan reasoning this way.

I call this the "fan syndrome", and this phenomenon is so widespread that I am sure it has a scientific name, which I confess not knowing (if you do, please leave a comment).

Here is another example.

Some time ago, I was following the results of an election and as the day was going by, it was clear that candidate A was going to win over candidate B. Yet, candidate B and his representatives could be seen and heard regularly on the TV saying that they were confident that they were going to win.

I found that attitude puzzling, so I asked a friend why they didn't simply tell the truth. My friend summarized this attitude with a simple sentence: "Nobody likes to pick a loser".

And then it hit me: what these politicians are doing is simply catering to the "fan syndrome" of their voters. They want to make sure they don't regret their vote.

What's troubling with this attitude is that it can actually cause this candidate to really lose the election, whereas they might have turned the tables if they had been forthcoming with the voters. Very often, I have been on the fence about voting. One candidate has my preference but for various reasons, I find myself too busy or not motivated enough on election day. If, during that day, my preferred candidate had come out saying something like "The polls are not looking good for us, so if you haven't voted yet, please do so, we need all the help we can get", I would probably have overcome my apathy and gone out to vote. And it could very possibly have made a difference.

But because of the "fan syndrome", that's not how things work and consequently, elections sometimes take a very different path from what common sense would have dictated.

So why am I telling you this?

Because my recent posts questioning whether Ruby and/or Ruby on Rails will ever become mainstream have caused me to receive a lot of emails asking me "Why don't you like Ruby on Rails?".

Uh?

And then I understood. Everybody assumes that I suffer from the fan syndrome, or to be more precise, of the "reverse fan syndrome": if I say negative things about something, it means that I don't like it.

Here is the deal: I have no problem picking a loser. It doesn't bother me at all. I like underdogs and I actually have a strong track record of liking marginal things in domains as varied as computer technologies, movies, music or even food. But I make a point of never ignoring the realities.

Here is another fact: I love Ruby and I love Ruby on Rails even more. I use both on a regular basis and it's a constantly pleasant experience. But just because I love these technologies doesn't mean that you will hear me say that they are going to take over the world. In fact, I'm pretty sure that they won't and that Ruby on Rails will, sadly, follow the same path as AOP: a great idea that will remain the privilege of a few expert developers. But let's not get into this debate right now because this is not the point of this article.

My point is this: don't fall in love with the technologies you like. Just because you made a choice doesn't mean that it's the right choice for everybody. Accept this, respect people who disagree with you and consider, just for a moment, that maybe -- just maybe -- they might actually have a point.

Be a fan, but don't give in to the fan syndrome.

Posted by cedric at 07:57 AM | Comments (22)

December 12, 2005

Dynamic refactoring? Seriously?

I can't believe that some people actually consider the dynamic refactoring approach used by the Smalltalk IDE as more than just a passing amusement.

Case in point, Werner Schuster has done a very good job at dissecting how it works and how it could be applied to Java with Eclipse here and here. I have to give him credit for actually reflecting on the idea more than anyone has so far. Having said that, I still scratch my head over his conclusion:

So as I see it… no one really wins. Both [Cedric: Java and Smalltalk refactoring] have benefits, both have weaknesses.

Well, let's see: renaming a method with this approach entails:

Being able to run your code and make sure that this particular run covers 100% of your code (just to make sure that the method you want to rename has been invoked by all the call sites. *All* of them). Oh and you need to run it with Eclipse.
Once you have identified these call sites, leave some sort of marker (annotation, wrapper, whatever) so they call the new method name instead.

Surely, this is a joke, right?

Both have benefits, both have weaknesses?

Uh?

Sorry, I just stand firmly by what I said: there are some refactorings in dynamic languages that, while not theoretically impossible, are so impractical that they are not worth doing, so we won't see them in an IDE any day soon. And this is one of the main reasons why no matter how great languages such as Ruby or Groovy are, they will never gain wide acceptance.

Posted by cedric at 08:36 AM | Comments (14)

December 07, 2005

Humane or spartan?

I am not a big fan of YAGNI, and I have stated it in many occasions. In so doing, I am in disagreement with most of the XP crowd, including Martin Fowler, who says:

You don't want to spend effort adding new capability that won't be needed until a future iteration. And even if the cost is zero, you still don't want to it because it increases the cost of modification even if it costs nothing to put in.

Interestingly, in a recent entry, Martin is now praising what is called a "humane interface":

The obvious contrast to a minimal interface is that humane interfaces tend to be much larger, and indeed humane interface designers don't worry too much about the interface being big.

Humane Interfaces clearly violate both YAGNI and the "do the simplest thing that could possibly work" principle, so I'm quite happy to see them gaining traction. For these same reasons, you can expect XP advocates to come out strongly against the idea of Humane Interfaces (and Elliote is leading the charge), which probably guarantees that they will become mainstream in no time :-)

By the way, Elliote, nobody writes list.get(list.size() - 1) any more: we all have a method in a helper class somewhere and we invoke it everywhere we need it. Wouldn't it be nice if that method were included in the List class?

Now, can we please have java.io.File#readFile() that reads an entire file in a String so we don't have to rewrite it over and over, like I just did this morning?

Posted by cedric at 01:22 PM | Comments (23)

December 06, 2005

Ruby on Rails and validation

Ruby on Rails is radically changing the way developers look at Web applications, and it's great to see all the excitement that surrounds the many innovative features it offers. One of these features is in-model validation, which is understandably seen as an improvement over validation tied to the presentation framework.

In this entry, Todd Huss shows a convincing example of this approach:

class Entry < ActiveRecord::Base

# Relationships
belongs_to :bliki

# Validation
validates_length_of :name, :within => 6..100
validates_uniqueness_of :name
validates_format_of :name, :with => /^\w+$/,
:message => "cannot contain whitespace"
validates_length_of :content, :minimum => 10
validates_associated :bliki
end

This kind of code is fairly usual to any regular Ruby on Rails developer to the point where it's actually easy to overlook that there is something very wrong with it: there is no easy way to capture this validation logic for reuse elsewhere.

I could move this validation to a common class but it's not good enough, for two reasons:

I still might want to fine tune a few parameters here and there (sometimes, the length of the name can be 6..100, other times 5..10 but the other constraints need to stay in place).

Not all my ActiveRecord objects extend the same class.

Has anyone tried to use a mix-in to achieve this? Any other idea?

Posted by cedric at 10:59 AM | Comments (24)

December 04, 2005

Silly links

The destruction of the Zip Feed Mill. Or is it? (link)
Nanaca Crash (Flash game). Get hurled in the air, bounce off girls but avoid guys (link)
Another Bush impersonation by Will Ferrell. (link)

Posted by cedric at 10:25 AM | Comments (2)

December 01, 2005

FireTitle

One of my favorite extensions for FireFox is FireTitle.

FireTitle was written by Jon Nowitz, a Google colleague, and it lets you name your FireFox windows in very flexible ways. If you do a lot of tab browsing, it's nice to be able to keep a consistent title for one window regardless of which tab it is currently displaying (e.g. "weblogs", "email"). Press Ctrl-; and you can name the current window (which will be preserved for future FireFox invocations). The version on mozilla.org is still for pre-1.5 FireFox but Jon already has updated it to 1.5 (I'm running it as we speak) and it will be uploaded there very soon.

I also just found a pretty neat extension: foXpose. Just press Ctrl-Shift-x (or click on the icon in the lower left corner) and it will show you an "Exposé-like" view of your tabs. I don't know yet if I will find that more useful than just the titles of my tabs, but the idea is very cool.

How about you? What are the first extensions you install one after installing a brand new FireFox?

Posted by cedric at 09:13 AM | Comments (12)