Logging Like it’s 2002

I’ve been going through my old code, looking for stuff that might be worth sharing. At the same time, I’ve been maven-izing my builds, and decided I should revisit each dependency, as some of this code is so old the dependencies are very out of date and/or included in the JDK now. Which brings me to log4j.

I’ve literally used log4j on everything I can ever remember doing in Java, but not anymore. Don’t get me wrong, I have no problem with it, and may continue to use it in my applications (if I don’t like logback), but I won’t be including it in any libraries anymore. After 8 years, I’ve finally adopted JUL. Here’s the options and why I chose JUL:

JUL (java.util.logging)

Pros

I’ll start with the victor, because the reason is the simplest. No dependency or version issues, one less thing to download, guaranteed to be there. There is also plenty of code out there to use one of the other frameworks to do your actual logging, so the config isn’t really a burden on the developers using the library.

Cons

Not sure yet. It’s not widely used, but I think that’s because there are far more Java frameworks/applications out there than libraries. There is also a performance issue with SLF4J when you have JUL logging set to a low level, but you shouldn’t need to run (presumably stable) libraries in debug or trace when performance is an issue (e.g. in production), only when you’re trying to debug something. The JUL’s actually logging isn’t really relevant here, as I think most applications will just be running it’s output through their own logging framework.

log4j

Pros

Works great, very stable, hasn’t changed in long enough that you only have version issues when you’re dealing with REALLY old code.

Cons

Less people are using it, more projects are going to SLF4J/Logback. These new frameworks do add some nice features, and log4j is basically abandoned, so I think it’s time to stop doing anything new with it.

commons logging

Pros

None?

Cons

I’ve always been against commons logging, because 99% of the time, it was just used to wrap log4j. The logic was that you could plug custom logging into it, but you can do that with log4j already, so it’s basically an abstraction of an extensible framework, with zero added value. Actually you have less value because you lose things like MDC. At this point it’s like a virus that just won’t go away, and always seems to end up in the classpath somehow. As far as I’m concerned, I consider this a completely superseded library.

logback

Pros

From what I can gather, logback really is (as claimed on their website) the continuation of log4j. Not having used it, I can only assume this is a good thing, and it just adds new features like parameterization. I’m going to try logback in my next application, and since logback includes slf4j, I will access my library logging that way.

Cons

It’s not really in wide usage yet, which means that a library requiring it is going to add an extra dependency.

slf4j

Pros

If logback is the modern version of log4j, slf4j is the supposedly useful version of commons logging, and supposedly improved version of JUL. It’s not a logger per se, it’s just an API/facade. It has the ability to combine multiple logging APIs and legacy frameworks into one stream, which is why it seems to be getting traction on complex applications.

Cons

I’ve had some serious versioning issues with slf4j, due to some methods being removed or changed, so you end up with older code throwing errors when you use a newer version, thus requiring that you only use the old version and introduce the chance for strange errors in code expecting the newer version. For this reason, I don’t feel very comfortable specifying any version of slf4j, and I will leave it to the user to add it if they wish.

Conclusion

So JUL seems like the best choice for a stable, single-purpose library to use, as it’s the least imposing on whatever uses it. It should be noted that I haven’t actually used JUL yet in a real app, so perhaps I will find out that there’s an actual reason for its lack of popularity. If that’s the case, I will likely use slf4j, and try and find out which methods cause issues so I can avoid them, and not be the person someone else curses for requiring it.

Scripting Language

On a mailing list I’m on, a few very smart, very experienced programmers were discussing the term “scripting language”. I had nothing of non-semantic value to add to the conversation, but I’ve heard this debate enough times that I figured I’d put my stock response here.

To the question “is X a scripting language?” the answer is “yes”. If the person is unhappy with this answer, the answer is “no”. At this point I ask “What will the correct answer to this question get you?”, and things unravel from there.

All rules someone can come up with to determine if something is a “scripting language” will be violated by at least one language they consider to be one. I assume there’s some fancy logician term for this, I’ll call it a paradoxical assignment until someone corrects me.

The term is vague, and the assignment of the term is typically in place of a more meaningful assessment such as “it’s not compiled”, or “it’s short”, so when someone asks this question, just dig a little deeper, and if someone says “just use a scripting language”, use Perl.

The 3 Ingredients Necessary to Make a Really Good Developer

I’ve been doing development long enough that I can now look back and have some perspective on the art/craft/profession. I’ve been asked many times “how do you become a developer?” and I now have a decent partial answer. They are not being “super smart” or “good with computers” or things like that. I think those are artifacts of these other attributes. I’d also guess that these apply to engineering in general, but I’ll limit myself to my own turf.

Curiosity

Good developers have a compulsion to understand how things work. they open files with text editors to see if its just xml or a zip file with a different extension. They run benchmarks against things that don’t seem to matter. They add query parameters like debug=true to websites. They try to break stuff. And not just software, they probably know how an internal combustion engine or an air conditioner works. They probably can tell you a bit about how the minimum wage affects inflation. My grandmother used to give me old radios and gadgets strictly so I could disassemble them.

This attribute is probably the one that separates the wheat from the chaff the most. There are lots of people who can code, or manage a system, but the ones that excel will need to understand how things work, and know that every juicy answer yields even more delicious questions.

Focus

The ability/requirement to focus is the subject of many other blog posts, but I view focus in a slightly different way. Focus is not eliminating distractions or even maintaining “flow”, focus is the ability to keep a problem in your head until you’ve solved it. Distractions can hamper this, so can multitasking or other external factors, but good developers can work on something, go to lunch, or go home for the evening, and pick up right where they left off.

Hard Work/Genuine Interest

I think there is a certain amount of innate aptitude, but I don’t think development is an exception to the 10,000 hour rule Malcolm Gladwell popularized. Luckily, its a trade where we can log those thousands of hours at an early age and make it look like we’re goofing off. I started with LOGO in the second or third grade, moving onto translating my piano music into BASIC, learning that a coda is just like a GOTO. On to writing databases to track fantasy baseball status with MS Works, and so on. Sure, we spent many college nights taking over IRC channels with bots, and crashing MUDs with scripts and floods, and that may have looked like simple nerd mayhem, but those experiences have tremendous value in the “real world”.

You can know all the buzzwords and put on a good show, but you can’t really fake the level of interest that side projects demonstrate. There are plenty of good-enough developers out there who punch in and out, and there are even jobs where you do cool enough stuff that you don’t feel compelled to break out of the rut (we try to be this way), but if you still need to hack on your own, you’ve got potential.

Contrary Opinion: Code coverage by checked exceptions

This is the first in what will hopefully be a series of statements that I may not entirely believe, but to put out there to see if they are viable…

Conventional Wisdom: Unit tests are great, you should have lots of them. More code coverage is better.

Conventional Sentiment: Checked exceptions are a hassle, more trouble than thier worse, promote sloppy coding, etc.

Contrary Opinion: Checked exceptions are a better way to address code coverage than unit tests.

On a scale of 1-10 of using and advocating for checked exceptions, I’m probably an 11. I completely disagree with pretty much all of the conventional complaints against them. They do not promote spaghetti code, they actually clean up your normal logic and neatly compartmentalize your error handling. They do not promote sloppy behaviors like exception swallowing, that’s entirely the programmer’s fault. Adding or removing exceptions breaks client code. Yes, it does, why is this a problem? You added additional error conditions, meaning you changed your contract with the clients, and they should be revisited. If you didn’t have this obvious way to signal a change, chances are that the client would handle things incorrectly. Even some of the major voices in computer science have fallen out of love with them, but usually the reasoning is based on people using them wrong (or being too hard to use right).

On a scale of 1-10 of using and advocating for unit tests, I’m probably a 2. They absolutely have their uses. A straight-up algorithm, especially things like math and parsing, should be unit tested for various input values to assure they’re returning the proper value. However in most modern business/consumer software these represent a very small portion of your code. There are far more lines of code dealing with things like authentication, user inputs, file loading, database and network operations, etc. These are complex activities. Even simple CRUD applications can end up invoking hundreds of functions across dozens of libraries for every operation.

The crux of my argument is that if you use exceptions properly, you don’t need to test if an operation completed properly. If the operation completes, it did so properly, all other conditions would fail to complete. Since you want to be using exceptions properly anyways for cleaner code, unit testing this code is redundant but a waste of time and energy to write and maintain. Not only that but exceptions give you code coverage at compile time AND error handling at run time, which unit tests cannot do.

If you disagree, please tell me why!

Fire the user experience designer

This post makes a case for having a specialized “user experience designer”. The author makes the case that usability and interaction design is too complicated to be handled by someone responsible for other tasks. This is false.

If you are on a team responsible for a website or something similar, EVERYONE on your team should understand usability and interaction design. It’s not a special skill, it’s core competency, like communication skills and ethics. The real experts out are rare, and I mean “you’ll probably never even meet one” rare. Most people who specialize in it are just washed-up designers or coders.

You need your designers thinking about how people will interact with your program, or you’re going to end up with brochureware. You need you programmers thinking about it or you’re going to end up with a clumsy UI. You need your QA people to think about it or you’re going to end up with spotty test plans. You need your managers thinking about it to understand what’s important. You need your salespeople thinking about it to compare against your hapless competition.

Having someone responsible for it is a bad idea because not only are they probably going to suck at it, it’s just going to make everyone else lazy.

Palm Pre

Palm PreI was impressed with the iPhone when it came out, but not enough to warrant the expense of the device and the overpriced service plan and dealing with switching carriers (especially to AT&T). I had the Spring PPC-6700 at the time, which was decent and got me hooked on having a mobile calendar and contact database without carrying a PDA. When Palm announced the Pre, I decided I would wait for it, and if it wasn’t up to snuff, I’d cave and buy an iPhone.

Luckily, the Pre is a fantastic device. I haven’t spent enough time with the iPhone to compare it honestly, but it seems like a much more polished experience. It automatically syncs my Google calendar, my girlfriend’s calendar, my work calendar, the Red Sox schedule. It easily unifies contacts from Facebook, Google, AIM, etc. I can send someone an IM, they can respond by SMS, it all goes into a common stream. It comes with both Sprint GPS and Google Maps.

Hardware-wise, it’s a little thicker, and a little shorter than an iPhone, more along the lines of a conventional phone. The screen is fantastic, it works in the sun and is crystal clear. The touch screen is well designed even for my round fingers, it seems to intuitively know what I meant to click on. The keyboard is small, but effective.

Minor issues so far: A bug in the instant messaging client that chews through an entire battery in 6-8 hours. I disabled it and it now goes 2-3 days with light internet usage. Supposedly this will be fixed via software update. Charging uses a tiny USB connector and a cover that doesn’t feel very durable once opened (but very durable when closed). I didn’t get a touchstone (the new induction charger) yet, but I probably will, which should remedy that. The fact that it doesn’t do video is not really an issue for me, my other phone did it and I think I used it once in 2.5 years.

My major problem with now is that for some reason, Palm has not released the SDK to the public yet, and has not accepted my application. This means they missing really useful features like an RSS reader or the hundreds of other standard apps out there. There are only 30 applications to download right now, the iPhone has 50,000. Even if 99% of those are total crap, that’s still alot more than Palm is offering. They really need to open this up soon, while they’ve got some shininess.

Neil Poulton is a Jackass

I recently bought a 1TB Lacie Hard Drive that was “designed” by Neil Poulton. I imagine that the design session went something like this:

Lacie: “Neil, we need you to design a hard drive for us”
Neil: “Excellent! I’ve got a brilliant idea!”
Lacie: “Tell us!”
Neil: “Well, I will tell you but you have to put my name all over the box, and not put anyone else’s name on it. Especially the people that are actually going to work late nights and weekends to do the engineering required to make this piece of commodity hardware fit into my stunningly brilliant design”
Lacie: “Sold!”
Neil: “OK, here it is, picture in your mind a shiny black rectangle”
Lacie: “I love where this is going!”
Neil: “Now picture in your mind a blue light”
Lacie: “Ooooh, sexy”
Neil: “Excellent, I’ll send over the invoice”
Lacie: “…”

Vista: Day 600

So, I had meant to do this sooner, but here’s the follow-up to my 1-day update after 18 months of using Vista.

  • I haven’t downgraded to XP, nor felt any need to. On the flip side I’m still running XP at home, and haven’t felt the need to upgrade.
  • It hasn’t crashed. Nope, not once.
  • The one vista feature I’ve grown to use is the “Start Search” box, which is basically a slower/simpler version of Quicksilver, but provides most of the functionality you need (i.e. finding programs and files you don’t use all day).

Well, that’s about it.

Oh, the Macbook I gave to Phil when I got the PC? He used it for a while, but after too many problems with it, he eventually had to go and buy a replacement (his 4th Macbook in 2 years).

Java Goofs: Enhanced For Loop

One of the “big deals” in Java 5 was the enhanced for-loop. Basically you could trim this:

for(int i=0;i<collection.size();i++) {
Object object = collection.get(i);
doSomething(object);
}

down to this:
for(Object object:collection) {
doSomething(object);
}

I don’t think such an improvement was really necessary, but combine this with generics and I have to admit your code does look a little cleaner, so I use them when possible. However, the for-loop is basically a half-implemented hack with two major goofs.

1. It works with anything implementing Iterable, and arrays. Despite working with anything Iterable, it does not work actual iterators, which seems just silly to me.
2. If the collection is null, it throws a NullPointerException. The only defense I’ve seen for this is that “a null collection is not the same as an empty collection”. Agreed, and those people clearly missed the point. The point was to clean up the code and now we have to add the same silly if(collection==null) around the loop. If your code really did need to know if the collection was null (e.g. lazy-loading), it’s going to check anyways, but this would save at least one more repetitive line if the loop just treated null as empty and did nothing.

Missing Java Annotations

@SelfExplanatory – I’d love to be able to turn on JavaDoc warnings in Eclipse, but I can’t. Why? Because 90% + of the code is self explanatory. Do I really need to see that getName() “Returns the name”, or that setName(String name) has the utter audacity to “Set the name”? No, I don’t. Put a @SelfExplanatory and JavaDoc can create these braindead comments without cluttering up my code, while Eclipse can reserve its warnings for the more interesting methods.

@NotNull – Other languages may have solved or avoided this problem, but I’d like to be able to dictate that a variable can be set to anything except null, and also that a method will never return null. It would just save so many headaches (of the onerous Runtime variety, no less), as well as lots of “if (foo == null)”…

The ulterior purpose of this post is to test the upgrade to WordPress 2.6.