Back on Oct 18, I described how to submit map corrections to NAVTEQ. I suppose I’ll have to wait several more months to know if my “bug report” actually works its way through the system.

In the meantime, Google came up with their own solution. You can now edit map markers directly in Google Maps:

You just click Edit, and then drag the marker. This is way easier than the NAVTEQ system, with instant results.

While this is a great enhancement, I hope it isn’t just a Google Maps annotation. I hope they have a way to feed these edits back into the root data, so ultimately all mapping services start to see the corrections after some period of time.

According to the discipline and punish link blog entry:

Except putting schema code all over the place tends to be a recipe for spaghetti. The benefit of Repository classes is there’s only one place in the code that has to change when your database schema changes.

Yeah, right. Based on my experience, when the database changes, it is because you need to track some new piece of information, and that inevitably ripples through every layer, all the way to the GUI screen where you now need something like a new text field to enter the data.

Nice theory, but I don’t think you see that kind of utopia all that often.

Featuring anonymous code examples from a company like yours…

Snoop is versatile: PERL, Icon, MySQL, and PHP!

(for the record, very few programming languages start with “I”)

This last book gives “Search Inside” a whole new meaning…

Pictures link to the real books. Please, Wrox, don’t sue me.

I’d like to see an interface something like this:

public interface PropertyChangeSource {
  void addPropertyChangeListener(PropertyChangeListener l);
  void removePropertyChangeListener(PropertyChangeListener l);
}

I’m not sure if this would also have these additional methods, or if that requires another interface:

public interface NamedPropertyChangeSource extends PropertyChangeSource {
  void addPropertyChangeListener(String propertyName, PropertyChangeListener l);
  void removePropertyChangeListener(String propertyName, PropertyChangeListener l);
}

Of course PropertyChangeSupport would implement this interface, as would many other beans with these methods.

Why?

For example, here is some code from Glazed Lists‘ JavaBeanEventListConnector class:

public JavaBeanEventListConnector(Class<E> beanClass) {
  final Method[] methods = beanClass.getMethods();
  for (int m = 0; m < methods.length; m++) {
    if(methods[m].getParameterTypes().length != 1) continue;
    if(methods[m].getParameterTypes()[0] != PropertyChangeListener.class) continue;
    if(methods[m].getName().startsWith("add")) this.addListenerMethod = methods[m];
    if(methods[m].getName().startsWith("remove"))
        this.removeListenerMethod = methods[m];
  }
  if (this.addListenerMethod == null || this.removeListenerMethod == null)
    throw new IllegalArgumentException("Couldn't find listener methods for " +
        beanClass.getName());
  }

Admittedly, it would be difficult to change this particular class due to backwards compatibility concerns. But I know I’ve written very similar reflection code in some of my humble little projects where I work, and I’d rather just utilize an interface.

This is much like the Closeable interface added in Java 5.

Why would you want a map like this on your blog?

Everyone’s blog traffic looks like that. A bunch of dots blobs scattered across the globe with a void in Africa. Get rid of it.

How about this:

People do not visit your blog for the weather report.

And about that tag cloud…Jeffrey Zeldman called tag clouds the new mullet way back in 2005. (personally, I think goatees are the new mullet, but to each his own…)

Heat Maps

Every person with a blog should read Banner Blindness: Old and New Findings. That article contains some really awesome heat maps that show what people actually look at on a web page.

I wonder why we spend so much time agonizing over how to create 3-column CSS layouts when people rarely look at those other columns anyway?

Great Versus Typical

I think Russell Beattie’s Weblog has a fantastic style: clean, beautiful, and easy to read. I modeled my site after his, although I’m certainly no graphic designer.

Unfortunately many blogs look more like this:

Yuk.

Be the Steve Jobs of Your Blog

Apple hardware design kicks ass:

Largely because they have the balls to remove extraneous features.

Corporate committees are the enemy of simplicity. Committees rarely produce anything inspiring. Instead, we get watered down politically correct pandering slop that tries to please every faction, while delighting nobody.

Your blog belongs to YOU. You do not have to answer to a committee! Be an evil dictator! Delete, purge, CLEAN UP! You can be Steve Jobs in your own little corner of the Internet.

Removing the clutter will make your blog better.

Thanksgiving Challenge

Your challenge is to remove something from your blog theme. Drop a calendar, a tag cloud, a map, a badge…whatever. Just go for simplicity.

(The hypocrisy of the gigantic ad on my own blog is noted…)

Today is Saturday, at least here in the USA it is. (I think it’s Thursday south of the equator, right?) At any rate, here is your homework for Monday when you return to “work”:

Find the longest human-coded class in a Java application at your company. Also, find the longest human-coded method in a Java application. Post the results here.

This is Thanksgiving week here in the USA, so it’s not like any of you are actually working next week. This should be fun!

For “longest”, let’s just count the number of “\n” characters.

Bonus points to anyone who knows of a simple program that can produce these metrics by quickly scanning an entire directory tree. Counting lines of code in a class is easy with a bit of shell scripting mojo, I’m not so sure about counting lines of code in individual methods.

I suppose you might try to briefly explain the reason these classes and methods are so abnormally huge, without exposing anything proprietary. We wouldn’t want to embarrass anyone, after all.

After receiving 14 responses to final, final, final: Your Thoughts?, I have decided I am comfortable with my current coding style and will *not* start declaring method parameters and local variables final.

For Example

Some people were just plain confused by the question. I was talking about method parameters and local variables:

public class Dog {
  public void speak(final String command) {
    ...
    final int someLocalVar = 12;
    ...
  }
}

I was clearly not (well, I thought it was clear) talking about final fields or methods, which are not open for debate because they have very specific cases where they are needed:

public class Cat {
  private final String name;

  ...

  public final void doSomething() {
    ...
  }
}

I use final fields frequently, in particular for thread safety reasons. I use final methods to prevent overriding. These are not coding convention or style issues. They are simply features you sometimes need.

Back to the Original Question

Among people who understood the question, the general — although not unanimous — consensus is that final adds more noise than benefit. I tend to agree. I think this code is more readable:

public class Dog {
  public void speak(String command) {
    ...
    int someLocalVar = 12;
    ...
  }
}

That’s what I’ll keep on doing.

Why do people still offer both RSS and Atom links???

More choices do not improve usability — they diminish it.

Pick one and drop the other. Your blog does not need both. I chose to remove RSS, by the way.

Java gurus: Should we declare method parameters and local variables final?

Enlighten me…

Regrettably, I do not have enough green: