Furthermore, do not use setters to wire up required attributes. I often see code like this:

Foo foo = new Foo();
foo.setAttribute1(a1);
foo.setAttribute2(a2);
foo.setAttribute3(a3);

This is bad because until the last line has executed, foo lives in some sort of twilight zone, where it exists but may not be used yet. Your class should not allow to create an object with invalid state. Better use the constructor to wire up attributes:

Foo foo = new Foo(a1, a2, a3);

Some people will argue that this will become hard to read if you have a lot of attributes. In such cases you should use a Builder separate factory class that collects all attributes with setters and can create the object once all required attributes are present (otherwise throw an exception). This shifts the enforcement of valid object creation from compile time to runtime, but still fails fast if necessary.

A related point I would like to make is that immutable objects (objects that cannot change their state after instantiation) also make for good code karma. Mutable objects can be a pain to work with and force their clients to make defensive copies. Immutable objects are also thread-safe by default (you might still screw it up though).

But let's talk about something nice today: Method type parameters. Few people know that type parameters in Java are not limited to types, but that every method and constructor can declare their own type parameters. And if this alone wasn't cool enough, it can actually be useful!

To illustrate, I need a couple of interfaces from Java kindergarden:

interface CanWalk {
    void walk(int steps);
}

interface CanSwim {
    void swim(int strokes);
}

interface CanSleep {
    void sleep(int minutes);
    boolean isSleeping();
}

interface Animal implements CanSleep { }

interface Cat implements Animal, CanWalk { }

interface Dog implements Animal, CanWalk, CanSwim { }

Say we want to write a method that simply takes an Animal and returns it. This is the way we used to roll:

Animal returnMe(Animal animal) {
    return animal;
}

What's bad about this method is, that it returns its value as Animal, even if we gave it a Cat. So if we wanted our cat back, we need to cast it manually:

Cat cat = (Cat)returnMe(new Cat());

We can improve on this by binding a type variable to the returnMe method like this:

<A extends Animal> A returnMe(A a) {
    return a;
}

This way we don't need the cast:

Cat cat = returnMe(new Cat());

To give an actually useful example, let's write a method getAwake that is given a list of objects implementing CanSleep, and returns those objects that return false from isSleeping():

<A extends CanSleep> List<A> getAwake(List<A> potentialSleepers) {
    return Lists.select(potentialSleepers, new Filter<A>() {
        public boolean passes(A element) {
            return !element.isSleeping();
        }
    });
}

... with Lists.select working like select in Ruby lists, but you cool kids already figured that out by yourself. Again we can give getAwake a list of cats, and get a list of cats back, rather than a list of animals. You can see how method type parameters allow us to be more expressive about our method signatures.

This might be stretching the attention span of the YouTube generation, but here's one more cool thing: Method type parameters with composite upper bounds:

<Duckish extends CanWalk & CanSwim & CanSleep> void rockTheBeach(Duckish duckish) {
    duckish.walk(100); // check out the chicks
    duckish.swim(20);  // cool down in the water
    duckish.sleep(60); // take a nap
}

This is about as much fun as you'll ever be able to have writing Java. Enjoy!

One of the things I still love about Perl is that, by convention, it is considered rude to invade other people's namespace. So we put all our public methods and constants into the @EXPORT_OK array and let the client decide which part of that he wants to use in their code. I should be able to do the same with code extending existing classes: Let me decide which extensions I want patched in on a per-class basis. I believe extension methods in C# 3.0 work this way. Do copy this.

Another name issue few languages get right are namespaces. Namespaces are important, because sooner or later you will have two different Node classes in your project and you need to tell your code which one to use. Let's look how some popular languages are dealing with this:

PHP

Bashing PHP is a bit like beating up an old man, but here we go anyway: PHP has no notion of namespaces at all. To work around this, people are using Really_Long_Classnames_With_Packagish_Names_Prefixed to lessen the chance of namespace clashes. LOL.

Java

Has a wonderful culture of putting classes in packages named after some domain you own. So my Node class would be packaged as org.netalive.swsu.Node and people could import this name and just write Node. Bad: When you need to use two different Node classes in the same piece of code. As you can only import one Node without name clashes your code will look like Map<Node, incredibly.long.package.name.of.other.Node>. Horrible when it happens, and it happens frequently. For instance, both the most basic GUI widget in Swing and the most basic data structure in Java are called List.

Perl and Ruby

Uses Package::Subpackage::Classname syntax for improved looks, but since you cannot import or alias these long names, this is more about organizing files and not really better than PHP's Package_Subpackage_Classname workaround. At least you can switch into a namespace and add and replace methods without using fully qualified names. It's kind of OK for untyped languages because you only need to reference types when calling a constructor or another static method. Still the possibility of another Tree::Node class in a second library is always there and sometimes urges you to use more unique package names than you would like.

Python

I don't speak Python, but from what I've seen this is a language that got namespaces right. You can import a namespace as in Java, you can selectively import symbols as in Perl, and here's the goodness: You can import reallylongmodulename as shortcut to alias reallylongmodulename into shortcut. Nice.

I think what Python does (importing and importing into aliases) should be the minimum requirement for any language that wants to take names seriously. The package naming convention from Java is cool, because the DNS is the only naming scheme humanity ever reached something like an agreement over, and unique names are good. Imagine blowing up the planet because some piece of code felt ambivalent about the semantics of System.Nuke. We would look all kinds of stupid if this sort of thing ever happened.

Surprisingly, open classes have one serious problem: People are using them!

Right now the two most popular uses for reopening classes are (1) adding methods to core classes like objects or lists and (2) patching totally not public code with your own funky version. Both are terrifyingly bad ideas which will probably break with the next update of the code you're patching, or as soon as another clever library attempts to do the same. But let's enjoy some examples together:

1. It is impossible to use prototype.js and json.js at the same time because prototype.js does something nasty to Object.prototype. But never mind since these are only the two most commonly Javascript libraries on the planet.

2. What Rails is doing to the Ruby core, and what some plugins are doing to Rails, is downright scary in some places. Thankfully Rails is heavily maintained and bugs are patched quickly.

3. While developing a World of Warcraft addon in Lua, we discovered that the preferred way to intercept chat messages was to replace the existing message handler, intercept the messages you need and hand over the rest to a copy of the old handler. Unfortunately, since our addon name was lexically smaller than the name of another addon that used the same trick, and World of Warcraft loads addons in alphabetical order, our new message handler was replaced by a third addon handler by that other, lesser addon and everything went to hell.

I'm not even sure if the last example is valid in this context, but it's also about bad scope and globals, and I really needed to stress the fact that I'm writing kick-ass World of Warcraft addons this very minute.

Anyway, don't you think it's funny how twenty years after people realized that "globals are teh suck" we're falling into the same bad habits all over again? Yes, open classes are fun toys to play with, but you can also fuck up royally if you don't pay attention. So, please, do think about what happens when other libraries attempt to pull the same hackery as you. Do consider the chance that a second library also wants to decorate the draw method, and do assume it will also save the existing method using alias :original_draw :draw. And OH MY GOD do not patch up private methods that have clearly not been cleared for public consumption by the original author!

Patching private methods. I mean, what the hell. Think of the children!

Although there are some instructions (scroll down to "Part 2") how to remove those gaps from your sound file, the amount of hackery involved is not for the faint of heart. The same guy also wrote a tool to automate the process but it's restricted to a maximum of 8 seconds of sound, and you can totally not buy a full version.

You're lucky if you're working in Flash however. The MP3 encoder inside the Flash IDE knows about the problem and will make sure any MP3 it compresses will loop without gaps. So:

1. Have an uncompressed sound loop as WAV oder AIFF. If your loop is already an MP3, remove the silent padding at the beginning and end of the track and save it as WAV.
2. Import the uncompressed sound into the library of your clip.
3. In the sound properties, set the desired MP3 compression.
4. Loop away.

What do you think the following code will print to the console?

public class NoVisibility {

    private static boolean ready;
    private static int number;

    private static class ReaderThread extends Thread {
        public void run() {
            while (!ready) Thread.yield();
            System.out.println(number);
        }
    }

    public static void main(String[] args) {
        new ReaderThread().start();
        number = 42;
        ready = true;
    }
}

Unless your answer is "either zero, 42 or nothing at all" you really need to read the book before someone notices.

First off, you really don't have to apologize for not having updated your weblog in a while. I'll just assume you had something better to do. Also your guides on overcoming writer's block and getting your daily blogging rythm going make me cry. It's not a freaking competition, mmkay? The whole beauty of this syndication thing is that I will still hear you after three years of blogging absence. I actually prefer reading occasional burts of goodness over the stream of consciousness shit that is clogging up the internet.

Second, if you ever forego a night with your friends in order to be able to update your weblog and I catch you, it's not going to be a pretty sight. Understand that our time on this planet is very limited and there are only so many bars you can hit before nature collects its toll. You must choose how to spend the time that is given you, and if the majority of it is spent blogging, you really need to reconsider that choice.

Also your weblog is probably not going to get you laid, ever. That implies that you should not see blogging as a popularity contest. You probably don't want to be among the "A-List" bloggers and if you ever find yourself aspiring that goal, please see the previous paragraph about bars and friends. Enjoy what weblogs have to offer, but don't use weblogs as your sole source of knowledge and self-affirmation. Always remember that the "blogosphere" is an echo chamber that can give you a very distorted image of reality if consumed without enough perspective. The vast majority of the online world does not read or write weblogs, and in no way are we smarter or hipper or more interesting or better informed than they are.

The most important people in your life will probably not have a weblog. They also won't turn up on a Google search.

Finally, stay away from World of Warcraft. That is all.

Best project ever.

Where was the meat? I read and reread the definition, examined the flimsy code snippets carefully, stared at the nearly tautologic diagrams for roughly 10 minutes, trying to grasp the deeply profound idea but failing.

Aside from having snorted coke through my nose over "nearly tautologic diagrams" I feel the need to defend Martin Fowler's article because it had such a profound effect on me when it was published. Although I had been playing with "objects" and "classes" before, this article finally made me understand what OOP was all about. This is not true for many other articles and yes, I'm looking at you, shitty Car extends Vehicle OOP tutorial.

Aristotle is right when he says that the concept of dependency injection should be so ubiquitously understood that it shouldn't get its own brand name. But at the same time it represents the very essence of object-orientation and most people are not using it. How many times have you hacked around a library because it won't let you inject behavior? Once you've swallowed the pill, the world's ignorance of dependency injection is almost too much to bear.

I also think the more important of Fowler's postulations is not to understand dependency injection, but to use it with a persistence that borders on the religious. Consequently employing DI everywhere is actually a new methodology. Anyone who ever tried dependency injection as their default way of doing business knows that it is plain impossible with vanilla language constructs. Without assistance from a DI container you're just going to die the death of the million parameter constructor.

Meanwhile, my number one newsreader request remains an unfulfilled dream.

• Pretty much all software licenses have the user waive any claims in case the software eats their data or blows up their machine. When the shit hits the fan, does the inclusion or absence of this clause really matter?
• My application is installed by downloading and unzipping an archive and thus has no installation screen. Where do I need to put the license? Mention it above the download links? Display it on the about-screen? Just include it to the documentation? Or must I require my users to click an "Agree" button somewhere?
• If I just expressed my intents in simple words, like "Don't sue me. Don't use for commercial purposes. Yo." What's the downside to that?

About the actual application for which I need a license:

• The core part of the application will remain closed-source for now, but ships with a large number of public API classes for plugin development (these classes also ship in compiled form). I'd like to allow any non-commercial use of the application and the API classes. Which license would do that? I used to think Creative Commons, but Creative Commons licenses are not intended to apply to software.
• The application also ships with a large number of plugins, including the sources of the plugin classes. Again I'd like to allow use for any non-commercial purpose. Do I need to treat the sources different from the binary part of the application?

Any comment that detracts from my state of total cluelessness will be greatly appreciated!

• Open classes! Extend any existing class with additional methods!
• Lambda expressions (OMG!)
• Construct objects with named parameters!
• Query collections with SQL-ish closure thingies!

Want!

When I try to sell The Right Thing™ to a client in need of a website, the feeling of fighting the uphill battle is so overwhelming it's not funny. Whenever some not particularely web-savvy business owner thinks of his dream website, he thinks Flash, PERIOD. Of course there are a million reasons why your client is better off without Flash, but all of them pale compared to the 450KB rotating logo splash page.

This is the point where it gets nasty: Because "better user experience" makes for such a fuzzy and unsexy argument, we start throwing more easily digestable bullshit in order to sell The Right Thing™. Here are some of my favourites:

Bullshit: Clean markup looks good on mobile devices

I just finished a new site with clean, beautiful and semantic markup. It looks like shit on my very popular Nokia phone.

The vision was that there is a style sheet for computer screens, and handhelds could show unstyled HTML and optimally use styles for media="handheld". This would be a terrific idea if a single hardware manufacturer went along with it. What browsers on PDAs and cellphone do instead is interpret the CSS intended for media="screen", which is lingo for "looks like crap on 128×128 pixels".

Bullshit: Google loves semantic markup

Is that so? I doubt you could even test that. From Google's point of view it doesn't make a lot of sense to trust the importance of <h1>, given half their index is search engine spam. I'd rather say Google loves text. It looks if, where and how often a word appears on a page, but probably doesn't give a flying fuck if it's marked up with <font size="+9" color="#f31242">, buried in ten nested tables or anything else.

By the way: Search engine spam totally works. Even if semantic markup got you a tiny bit of Google juice, paying $100 to a search engine optimizer spammer buys you ten times that. Sucks to hear, but that's how it is.

Bullshit: Accessibility = Usability = Semantic markup = Validation

Mark Pilgrim said it so well:

Anyone who tells you that validation buys you semantics is selling you snake oil. You can have an entire page full of DIV and SPAN tags and be perfectly valid, and it may look perfectly good to the human eye, but it doesn't mean anything, and any tool that relies on semantic markup won't be able to make heads or tails of it.

Anyone who tells you that CSS guarantees you accessibility is selling you snake oil. Most accessibility techniques have nothing to do with CSS (...). And where accessibility and CSS do overlap, it's still easy to screw up if you don't know what you're doing, or simply go through a lot of pain for no real-world gain.

Bullshit: Tutorials can teach you accessibility

Earlier this year I wrote about the cargo cult that is web accessibility. Basically every web designer on the planet thinks they can offer accessible sites because they read a tutorial and dig semantic markup (see above), but few have profound knowledge of the matter, not to mention having worked with disabled people.

So after you read "Accessible websites in five minutes" and added Accessible web design to your resumé, head over to Observing Users Who Listen to Web Sites and cry:

Some ranted to us about the problem of having to listen to the same "stuff" on each page. Some jumped to the bottom and scanned the pages backwards to avoid the navigation at the top. But only half knew what "Skip Navigation" means.

Think about it. "Navigation" is web jargon. It's not common language. Some developers have used the phrase "Skip to Content" instead of "Skip Navigation." Good idea. But it does not work because "content" in English can be a noun or an adjective. JAWS reads it here as an adjective with the accent on the second syllable. So it does not make sense to users.

Bullshit aside, what does semanticesque markup and CSS really get you?

1. Consistent design without a CMS
2. Easy design changes
3. Pretty printing
4. Very basic screen reader support

That's it. I'm afraid these points alone won't always beat the 450KB rotating logo splash page in the heads of my clients, but I can't continue to sling bullshit and still watch myself in the mirror every morning. I also wished the discussion would move away from "how to sell web standards" over to "how to make 'publishing lots of text' look sexy", but I'll save that for another rant.