Author: Eric F. Savage

Logging Like it’s 2002

Posted on by Eric F. Savage

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

Posted on by Eric F. Savage

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 Where and When of Music

Posted on by Eric F. Savage

The idea that music can bring you back to a time and place is not a novel idea. There are songs you hear that make you remember the first time you heard them, or a specific event like a wedding, but I think there’s an even more powerful level. When I’m addicted to a song, it can get tied to a place as well as date, and when I’ve moved on from that place, I basically put that song back in its box, and file it away. It will come up in shuffle again someday, but it loses its primacy. Here are some of mine:

  • I Love a Rainy Night – Eddit Rabbit: Listening to the 45 in the playroom at my house when I was 5 or 6 years old.
  • Now That We Found Love – Heavy D and the Boyz: Involuntarily being subjected to this song every day on the bus to school. I think my blood pressure jumps 20 points just from hearing this.
  • Dig Your Own Hole – Chemical Brothers: Playing Starcraft in the basement of our hell-hole apartment on Tremont Street, wondering if I’d ever be able to find a programming job with no experience
  • Aenima – Tool: My friend/roommate at that same apartment Andy had a fancy stereo and a huge CD changer, but I think he only had 1 disc, so he pretty much played this album 24/7. I still can’t bring myself to buy a Tool album despite otherwise liking the band
  • Remixes – Ratatat: The second StyleFeeder office in it’s vacant, magenta glory.
  • A Thousand Suns – Linkin Park: The fourth (and current) StyleFeeder office. I seem to have no interest in listening to this album at home or in the car, but put it in a few times a week here

Earlier to Bed, Earlier to Rise

Posted on by Eric F. Savage

About 6 months ago I shifted my schedule by 4 hours, literally overnight. Whatever I was up against, whether it was insomnia, sleep addiction, Delayed Sleep Phase Syndrome, or just being a night-owl, it was getting worse. Also, the summer was coming, I had a shiny new grill, and I wanted to get home early enough that I wasn’t using it in the dark. Much to my surprise, it actually wasn’t very difficult. Here’s how I did it:

  • Consistency – Probably the most important part. Go to bed at the same time every night, no matter how tired or wired you are. Lay there for hours if need be, in a few days you’ll be asleep earlier. Get up at the same time, no matter what, even on weekends. I had a few nights where I got 3 or 4 hours of sleep and needed energy drinks to get me through the day, but that changed fairly quickly. I was able to ease up on the schedule after a while, but I try not to deviate by more than an hour or two.
  • Don’t do it alone – I’m not sure I could have pulled this off by myself. Reeny didn’t even really have to do much, other than some encouragement and being an early-riser herself.
  • Get up first – I try to get out of bed first. Some mornings this aspect is what gets me moving. If she can get up, why can’t I?
  • Measure success daily – The point of this is to get up early, not to become an early riser. Even after 6 solid months, I know that I’d slip back to my old schedule within a matter of days on my own if I allowed it. But that’s OK.

Also, I changed my schedule a month or so before I changed my work schedule. I think this helped alot, because I didn’t have that additional stress.

Today I Learned: Wood Finishing

Posted on by Eric F. Savage

I took a beginner wood finishing class at Woodcraft last night, and was very happy with it. It was taught by Gary Wood, and I’d highly recommend it to anyone that is intimidated by the craft of finishing, as I was. Some highlights:

  1. Put simply, dye is a color liquid, while stain is a suspension of pigment particles. This means that dye will get into your wood, while stain will sit on top. This means dye will preserve the beauty/grain of the wood better, while stain is easier to work with.
  2. You can add color at any step of the process (stain/dye, seal, fill/glaze, finish, polish) so you can get the color just right. Doing colors at different steps will also increase the “depth” of the finish.
  3. Don’t oversand when you’re applying a finish – I learned this the hard way on my own, sanding some maple down to 320 and subsequently seeing the wood fail to pick up any finish. Most of the time you don’t need to go past 180, and never go past 220.

The 3 Ingredients Necessary to Make a Really Good Developer

Posted on by Eric F. Savage

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.

Fortune smiles on those who smile back

Posted on by Eric F. Savage

I’ve always considered myself a pretty lucky person, whether it’s spotting opportunities, avoiding bad ones, getting good jobs, etc. This article claims that you actually do make your own luck, and the way that happens jives with how I go about things. Some snippets:

  • Lucky people tend to respect hunches
  • Lucky people try to introduce variety into their lives
  • Lucky people tend to see the positive side of their ill fortune

So, if you’re feeling unlucky, take a deep breath and try something new.