Although it might be pretty eye-candy, I do not find the Top Sites feature in Safari4 to be terribly useful for anything. You open a new tab or window, and Safari sits there spinning while loading a bunch of web sites you may or may not be interested in going to. I find Safari to be a whole lot faster with the feature turned off.

It’s simple.  Open Preferences, and tweak the settings for “New windows open with” and “New tabs open with” to be either an Empty Page, or whatever Home Page you prefer.

Many languages support the notion of  ”here documents”.  This is a handy way of embedded string literals that would normally have to be escaped right into your program text.  

1
2
3
4
5
6
7
8

#!/bin/sh
cat << "EOF"
Here is some text, embedded

   "right in the middle"

of my Bourne shell script.
EOF

Having been a standard feature in the Unix shells for decades, this language structure is supported in many newer languages, such as Ruby. Python, PHP and Perl.  But not Java.  In Java, this program would look like:

1

System.out.println("Here is some text, embedded\n" +" \"right in the middle\"\n" +"of my Java program.\n");

As you can see, the quoting and escaping required to reproduce this text is pretty ugly.

Wouldn’t it be nice if we could do this kind of thing in Java too?  It would be great for things like XML and Unit Tests.   How did we get to 2010 without having this as a standard language feature?  Has it ever come up in a JSR?   I haven’t had much luck in digging up any information (the term “here document” is remarkably hard to search on.) If you know something about this, please leave a comment.

Detractors of Java are correct to point out a rather unfortunate trend in the Java world- there is a common tendency for developers to turn every non-trivial class into an Interface, and then create an “Impl” that actually does the work.  As a result, your codebase becomes littered with lots of superfluous interfaces that have only a single implementation.

Why do we do this?

Part of it is simple architecture astronautics, but there is actually a very legitimate use case for creating interfaces even when there is only a single implementation- it allows you to mock out your objects so that other classes can be unit tested easily. This is really important in TDD, and so I’ve come to accept the fact that there will always be some extra “interface noise” in the codebase in order to support a good test infrastructure.  C’est la vie, right?

Along comes JMock 2.5, with its ClassImposterizer, backed by cglib.

“The _ClassImposteriser_ creates mock instances without calling the constructor of the mocked class. So classes with constructors that have arguments or call overideable methods of the object can be safely mocked.”

I should point out that this isn’t exactly new- JMock 2.5 came out in 2008, so I’m a little late to the game here.  But I haven’t seen much written about this.  It’s a really huge change.  It means that you can do things like:

1
2

final java.awt.Graphics2D graphics = mockery.mock(java.awt.Graphics2D.class);
mockery.checking(new Expectations() );

Of course this is great for testing code that uses libraries that weren’t designed with mocking in mind, but even better than that- you can use it against your own code, and save yourself from having to create interfaces.

This means you can go ahead and create your concrete MyComplicatedDAO, without having to create MyComplicatedDAOIFace, MyComplicatedDAOImpl, MyComplicatedDAODummy, etc.  When you need to test code that uses it, you just do:

1
2

final MyComplicatedDAO dao = mockery.mock(MyComplicatedDAO.class);
mockery.checking(new Expectations() );

It’s really hard to overstate the significance of this.   It’s changed the way I write and test code. It’s very refreshing to be able to start out with a concrete class and write code that does stuff, rather than code that merely talks about doing stuff.

Of course there are still very legitimate reasons for using interfaces. If you’re designing a library, using interfaces makes life easier on your users. Interfaces are also a great way to decouple code, to remove circular dependencies, and to support callbacks.  All of these are legitimate and appropriate uses, and you shouldn’t abandon them.

But use interfaces with reason, and not by reflex.