On name & address madness
A long time ago, in a university far far away, I had a crazy Relational Database professor. This man was under the impression that data should be normalized at any and all cost, to infinity and beyond. In some cases, he had a point. When he started talking about normalizing names and addresses, I had to suppress murderous tendencies. You see, he seemed to be under the impression that it's always a Good Idea to split an address into different chunks. You know the drill: street, post code, city, country. Or worse, add a house number. Or worse, states, counties & provinces. Maybe regions, too. And before you know it you end up with a monstrosity of a data model that's broken beyond repair. There are many different addressing systems out there. To the point that Wikipedia has a page devoted to them, some of which are too complex to explain on that single page. The Japanese one is particularly interesting. I'm sure someone out there is nuts enough to create a model that encompassess all of these many & varied possibilities, but not I.
Generally speaking, addresses are used to send snail mail. If that's the only reason you need them in your application, then a simple text string will do. I'm sure users from Country X are quite capable of entering their address in a sensible format. When people want stuff delivered, they'll make sure the address is properly formatted. If you need to do silly things like calculate shipping costs, then there's no harm in asking the user for their country seperately, or even their locality within that country. Instead of having a dozen fields, you'll have 2 or 3, which is much simpler to work with for users, and it won't drive developers insane.
And then there's names. They're even worse. "First name", "last name". If I had a penny for every time I came across a form asking me for two parts of my name, I'd be bleedin' rich. Let's start with the obvious: not everyone has two names. In fact, until relatively recent in history, most western people only had one name. Only when Napoleon decreed in 1811 (!) that everyone under his rule ought to have a last name did people take on "actual" last names. Before then, John was simply John. If you didn't know which John exactly, then "John son of the butchers by the church". Not every culture uses the same sort order for first name & last name. In Japan, the family name comes before the given name. If you want to use the first name to send informal communications along the lines of "Jack, we have a wonderful new offer", then you're out of luck in China. They use the full name for those types of things.
Just like with the addresses, the only sensible thing to do is stop trying to fit everyone in the same box, in a manner of speaking. Because what you actually need is *one* box for a name. Your users are perfectly well aware of their own name, so they can enter it in whatever order or format they're used to. If you really insist on being the cool kid by sending messages with personalized greetings, then I suggest you ask the user "how should we address you?". And for goodness' sake, DO NOT try and validate the length of a name. 2 characters is perfectly common in Asian languages, whereas the longest official name is -- according to Guinness World Records -- 799 characters long.
KISS is the golden rule, as always. If you don't need need the "standard" granularity for names and addresses, then don't bother with it. It's a waste of everyone's time and it will only frustrate users who don't fit in any of your boxes.
On naming Interfaces
Just about every programming book or OOP example I look at has the annoying habit of prefixing interface names with an I. Yes, IInterface, ICar, IWallet, IMoney, IIAmStupid. It's one of my pet peeves, I admit, but every time I come across code like this I find myself suppressing murderous tendencies.
Why oh why would you do this? "To clearly indicate that it's an interface". Why the hell do I need to know that it's an interface in the first place? If I want to use your library, I really don't give a toss whether I'm talking to an interface or a concrete class. If I do want to know (because I'm extending or initialising it) then I'm quite capable of figuring out for myself whether I'm dealing with an interface, abstract class or concrete class. The only thing this random I does is make it harder to look for suitable classes. I want to search for Car, or Wallet, or Money. Not to mention that I don't want to type that extra letter every single time I'm assigning an instance to a variable.
Seriously, how ugly is this
IFoo foo = IFooFactory.createIFoo();
The irony here is that I used "I" 32 times in this post. But for crying out loud, pick a meaningful name, not some silly prefixed monstrosity.
OutOfMemoryError while running Maven Surefire tests
Imagine you have a project which works perfectly fine and well. All tests pass, each and every time. Then one day you commit a couple of new classes with related tests. Of course you ran all tests before committing, and everything worked just fine. Then, a minute or so later, you get a mail from Hudson (or whatever you're using for CI) saying that there are test failures. "Maybe I forgot a file", I thought. Checked the test results on Hudson. About a dozen tests were failing, unrelated to anything I touched. Odd. OutOfMemoryErrors all over the place. Most odd. Hudson's tomcat has 1G, which should be plenty. Same with each build's MAVEN_OPTS.
Apparently, someone who wrote the Maven Surefire Plugin thought that it would be a GREAT idea to ignore things like MAVEN_OPTS and other memory settings. The plugin seems to start a new JVM instance to run the tests. Without any of the arguments you so carefully selected. No. Apparently you have to explicitly tell the Surefire plugin that maybe, just maybe, it would be a good idea to use the memory settings you already provided elsewhere.
Anyhoo, this fixed it:
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-surefire-plugin</artifactId>
<version>2.6</version>
<configuration>
<argLine>-Xmx512m</argLine>
</configuration>
</plugin>
DRY, you say? Not so much, eh.
Maven 3 resource filtering weirdness
Maven 3 is all nice and fast(er) and shiny, so I decided to upgrade a Maven 2 project to Maven 3. It (cl)aims to be backwards-compatible, so my consternation was pretty great when my build failed straight away. That's to say, my tests failed. For some reason, my resources were no longer being filtered. Yup, ${property.keys} weren't being replaced by values.
This struck me as being somewhat odd, because it worked fine with 2.2.1. A bit of debugging led me to the cause of the problem:
<!-- @Transactional can now be used as well -->
... apparently, the @ symbol is an escape character of sorts.
Considering that blurb on their website doesn't even qualify as English, I'm not sure if this is a feature or a bug. But whatever. Removing that comment fixed the problem. Whoever came up with that bright idea (especially in an age where @annotations are as rampant as the black plague in the 14th century) probably deserves a spanking.
The Real World sucks
Being of a reasonably calm disposition, I rarely reach boiling point, but there are a couple of things that really do grind my gears. Inefficiency is one of them, but let's not go there right now. What's really grinding my gears right now, is how much the so-called Real World (as opposed to the academic world) sucks.
Every once in a while, I will stumble upon a piece of code that I really wish wasn't there. It's the kind of code that screams "please refactor me!". It's the exploding septic tank of code smells. When I look at it, the words "well that's going to come back to bite us in the arse" pop into my head. In an ideal world, I'd be able to just sit down for a day and refactor the damned thing. This Real World thing, unfortunately, has something that's called management. Or was it manglement? They're part of Layer 8 either way. That's right, the political layer.
These politics seem to revolve solely around short term benefits. And so refactoring a piece of code that could cause problems eventually in such-and-such a situation isn't deemed important. This is fair enough in some cases, but sometimes you really do know that this decision will come back to haunt you. Sometimes I wonder whether managers really don't care about long-term implications, or whether they like having a couple of big bugs lurking in the code in the hope that some of these will be discovered much later so that we can get paid to fix them. Must be my cynical mind talking.
Is there a good way of dealing with this sort of nonsense? It's always possible to pull overtime and refactor the code then, but what if you introduce a bug? Good luck explaining a bug in new-and-improved code that you weren't supposed to write in the first place.
Yup, the Real World sucks. But if anyone has a way of making it better, I'd be glad to hear it!