Professional Advice: Speakerphones

Posted on by Eric F. Savage

Speakerphones seem to be increasing in popularity in the workplace, and in case it’s not obvious, this is a bad thing. For the sake of sanity, let’s review the narrow set of conditions under which speakerphones are allowed. Note that both conditions must be met.

  • You are in a fully-enclosed office or conference room.
  • Two or more people need to speak on your end.

There are some rogue conditions floating around that are invalid. These include.

  • I’m typing. – Stop and listen, or hang up.
  • I’m very busy and/or important. – No, you’re not.

Simple huh? There is a small set of exceptions. (This list is exhaustive)

  • You are juggling and on the verge of breaking a personal/world record.
  • You are performing surgery.
  • Your handset is broken and you are ordering a new one.
  • Your ears are under some sort of medical duress and you are calling the doctor.

Baseball HOF 2007

Posted on by Eric F. Savage

This years Baseball Hall of Fame election results have been announced. Here’s what would have been my votes. Those who were elected are in bold.

Harold Baines – No
Albert Belle – Almost
Dante Bichette – No
Bert Blyleven – Almost
Bobby Bonilla – No
Scott Brosius – No
Jay Buhner – No
Ken Caminiti – No
Jose Canseco – Almost
Dave Concepcion – No
Eric Davis – No
Andre Dawson – No
Tony Fernandez – No
Steve Garvey – Almost
Rich Gossage – Almost
Tony Gwynn – Yes
Orel Hershiser – No
Tommy John – No
Wally Joyner – No
Don Mattingly – No
Mark McGwire – Yes
Jack Morris – No
Dale Murphy – No
Paul O’Neill – No
Dave Parker – No
Jim Rice – Yes
Cal Ripken Jr.- Yes
Bret Saberhagen – No
Lee Smith – Almost
Alan Trammell – No
Devon White – No
Bobby Witt – No

Notes:

HOF votes should not be secret. Why? Because we need to see who didn’t vote for players like Gwynn and Ripken and fire them. The supposed logic here is that since nobody was ever elected unanimously, nobody ever should be, but that’s bunk. The point of the HOF is so we can take our kids there someday and show them the revolutionary players like Ripken (which outweighs the fairly inconsequential Streak), and players like Gwynn who make something so hard look so easy. If you want to impose your own twisted house rules, go vote somewhere else.

I’m not really surprised that McGwire didn’t get in, but I am surprised how few votes he got (23.5%). The topic of steroids in baseball is annoying, and the consequences are inconsistent. Steroids have been around for over 50 years, and clearly players have used them in all sports. To say that McGwire is the one of the first to abuse them is simply false, especially when people hold up the hitters of the 60s and 70s as examples of people who didn’t. We have no idea if Hank Aaron or Jim Rice or Tom Seaver used drugs or supplements, and even to suggest the possibility as I’m doing here is blasphemy. Despite longstanding media hype to the contrary, there isn’t even any credible evidence that steroids have adverse effects on grown men. McGwire is 6’5″, Canseco is 6’4″, both are well over 200lbs and took advantage of modern nutrition and training. Mantle was 5’11”, Aaron is 6′, and both were relatively lean. They also grew up in an era where people didn’t even know what effects basic vitamins really had. To say that modern sluggers were “obviously” using steroids and other hormone supplements is silly, and even if they were, can someone prove that they shouldn’t? We’ve proven the dangers of weight training as well as alcohol and red meat and sodium and pretty much everything else athletes put into their bodies, why aren’t they banned as well?

Jim Rice isn’t a legend like Ruth or Cobb, but he was a dominant force for a long time. There are many opinions why he can’t seem to get enough votes, from his mediocre fielding to his frosty relationship with the press and fans, but he should be in.

Albert Belle got 3.5% of the votes, not even enough to stay on the ballot. He was a troubled personality whose career ended on a very sour note, but the voters apparently forgot that he was a terrifying hitter who competed for MVP status, had 9 consecutive seasons of 100 RBIs, and a career .295 average. Perhaps not HOF numbers, but clearly a brighter talent than some who finished ahead of him.

Macintosh Gripes: Poor Usability

Posted on by Eric F. Savage

I’ve had many computers over the years, and many of those have been Apple Macintoshes. I’ve had an SE, PowerMac 7200/75, iBook, Mini, and currently a MacBook Pro. Up through about 1997 I considered myself to primarily be a Mac user, but I switched because I was using and developing for the web more and more, and Mac web browsers were slow and poor, to put it kindly. I was also developing on Microsoft Access quite a bit, and there was no Mac version (and there still isn’t). When I started at StyleFeeder I had a choice and opted for Mac because that’s what the other developers were using, and I have to admit I regret that decision.

Macintosh OSes, especially OS X, is often praised for it’s quality and usability. Back in the old days, I’d agree. System 7 was hands-down better than Windows 3.1 in pretty much every way I can think of. These days, I’d say the tables have turned and can’t think of any way that OS X is better than Windows XP. They both crash infrequently, but I’d give a slight advantage to XP as it only crashes for me once or twice per year, while the Mac has done so at least twice since August. The Mac came with some decent software for dealing with movies and making music, but I don’t do much of that stuff and if I did, I’m sure I could find similar Windows software.

My main cause for regret is the overall usability of the OS. There are three main issues here. The lack of keyboard access to commands, the antiquated menu bar and the MDI.

As a full-time developer, I’m in the power user caste. I am constantly trying to find the shortest and easiest way to get things done. Nobody with half-a-clue about usability would argue that the mouse is an efficient command tool. It’s obviously the ideal way to select things and navigate spatially, but once you’ve gotten where you need to go, you are ready to start issuing commands. On Windows, every command is accessible via the keyboard. Common operations have simple key-combinations, more obscure ones will have more complex combinations. Control-P prints, Control-S saves, and so on. For tasks that are more specialized or used rarely you will likely have to use things like Alt-F-W-F (makes a new folder in explorer) or Shift-Control-F (formats code in Eclipse). These don’t need to be easy, but they are there and every user will find themselves learning a few of them depending on what they do often.

On a mac, no such luck. Some things like printing and saving are common, but after that it’s seemingly random and left to the application developer to implement commands, and most don’t. So I have to stop what I’m doing and reach for the mouse all the time. In usability terms, this is a fairly significant hurdle and has a high cost which I find unacceptable. Apple reluctantly introduced “universal keyboard access”, but it’s really bad and clearly a begrudged afterthought that makes you use the arrow keys to navigate menus.

The second gripe is the way OS X sticks the menu/command bar at the top of the screen. The logic here is that it’s easier to target something thats at the top of the screen because the mouse won’t go past it, and also that it’s always in the same place. That makes sense in theory, but fails in practice. As mentioned above, the mouse is a last resort for issuing commands, so by the time you’ve reached for it you’ve already incurred significant expense. Spending the extra 50ms target it is a minor addition to this.

Where the fixed menu bar really fails is when you use more than one monitor, because it sticks it to the top of the primary monitor. If you’re working in the second monitor you now need to grab the mouse, and drag it all the way to the second screen, then drag it back.

Also, when working in more than one program, which most people do, you can’t select commands from an inactive program. You need to find a safe place to click to activate it, which is expensive and varies widely, then you can access the menu bar. In windows you can click on an inactive menu bar and it will open with that same click.

Thirdly, almost all Mac programs use what is called an MDI, or Multiple Document Interface. This means that all the windows for a program are linked together as opposed to a Single Document Interface (SDI). Microsoft realized that MDI was a poor design in many cases, and fixed this in XP. MDI makes sense for some things, such as dialog boxes and the many windows that Photoshop uses to show things like layers and pallettes. This does not make sense for things email and word processing. Just because I have two documents open in the same word processor doesn’t mean there is any relation between the two. I should be able to alt-tab to a specific document and keep the other one minimized. A minor annoyance related to this is that you can have programs running with no windows at all, which ties up resources and is just plain confusing.

Perhaps the worst part of these problems is that they could be built into the OS and be optional behaviors, but they aren’t. Apple’s stance has always been that they know best, and that options are confusing. Unfortunately they compound this defect with the fact that they are extremely slow to change things even when they are clearly wrong. For proof of this you need only to see that they still put one-button trackpads on their frighteningly hot, overpriced laptops.

Cracked Foundation: Trac

Posted on by Eric F. Savage

We’ve been using Trac on a project lately, and it’s a good example of an otherwise decent product being rendered almost completely useless by a simple problem. To be clear, we’re using Trac for defect/issue tracking, so if you aren’t using that part of it, this wouldn’t affect you. The rest of the system seems OK, though I’m not sure why integrating SVN commits into tickets requires some hack via Perl script (that won’t work for us). However, that’s just a lack of convenience, the real problem is the way it handles the chain of custody for tickets. Here is Trac’s state diagram for tickets:

Track Ticket State Chart

I’ve worked with many different issue tracking systems, and if you have too, you’ve probably already noticed what’s missing. I call it the “full circle” concept for lack of a better term. The crux of the idea is that the person who opened the bug should be the only one to close it in most cases. Trac does not have this. The reporter can reopen the ticket, but a closed ticket basically falls off everyone’s radar, so no validation or verification would take place. Here is the state chart with the step I’m referring to:

Minimal Defect Tracking State Chart

Even on a small team, without this step we’re running into people with clogged-up queues because it’s pretty common for developers (ticket resolvers) to also create tickets from time to time and assign to another developer. We’ve take the safe route of reassigning to the reporter rather than closing, so things should be validated before closure, but this makes the ticket queues much larger and more difficult to manage, and sometimes tickets don’t get closed until after the fix has been published.

Voting Obsecurity

Posted on by Eric F. Savage

December 26, 2006

The Honorable George W. Bush
President of the United States
The White House
1600 Pennsylvania Avenue NW
Washington, DC 20500

Dear Mr. President,

I hope the holidays find you well, and wish you happy and productive new year.

I am not an expert on the topic of voting, nor am I a professional security expert, but I do try and follow the news with regards to the intersection of the two. I watched the HBO documentary “Hacking Democracy” this weekend while wrapping presents, and was flat-out disgusted. It was not especially well-made, made no attempt at being objective, nor was most of its information news to me, but I was moved when I watched a mock election be rigged using actual voting systems and saw a real, respected election official be speechless and dumbfounded that his job was completely undermined.

There is no simple solution to secure voting, nor is it remotely probable that any election will ever be 100.0% honest, but there are some monumentally obvious flaws in the way we currently count votes. The largest is the issue of the lack of openness of the software, systems, and processes that are involved.

I am a software developer and most non-programmers I’ve talked to have a difficult time understanding the idea that public access to the “secret codes” of software, AKA the source code, is more secure than private or closed source code. The general opinion is that if you can see the inner workings of something, it’s easier to break it, which is valid and true. The next step in this thought process, however, is more critical and is one that most people don’t take. That is that if you cannot see the inner workings of something that is broken, it’s more difficult to fix it.

The idea of “security by obscurity”, sometimes referred to as “obsecurity”, is valid and necessary when it comes to information such as private financial data, personal information like medical histories, and intelligence gathered by our military and other government agencies. However, regarding mechanisms and processes, such as software, obscurity lessens security. This is doubly true when those mechanisms are designed to collect and analyze public data, such as votes.

Here’s a dirty secret of the programming craft: 99.9999% of software is broken. By broken I mean there is some bug somewhere in it. In new or rarely used software these bugs can be serious and misleading. In most mature software, it’s nothing serious; something doesn’t display right, some obscure error condition is handled poorly, etc. This applies to video games, email programs, ATM software, Windows, Linux, etc. as well as voting software.

So how do you weed out these bugs? You test, over and over and over again. When you find a bug, you test again, even things that you didn’t fix (AKA regression testing). Eventually, you’ve fixed all or most of the bugs that were found, satisfied your unit tests and requirements, and you ship it. Then your customer does something you never planned on, maybe because they are being silly or stupid, or you aren’t the programming god you thought you were, or your QA staff is overworked, or it just wasn’t possible for you to test in the lab. This is why you get Windows updates every week, and why there are dozens of bug fixes for every Linux kernel, patches for every video game, it’s simply unavoidable. The more something is used, the more bugs are found, and the better it becomes.

Voting software isn’t used very much. Most machines are used one day every year or two. Excel has been used by millions of people every day for nearly 20 years, and there are still bugs in it. If I’m making an inventory of my baseball cards and have a problem with Excel I can report it to Microsoft and hopefully a ticket will be opened and hopefully they will fix it. The difference between a spreadsheet package and a voting system is that my grandfathers didn’t risk their lives overseas to make sure “=SUM(D3:D13)” was accurate, they did it so that I would grow up in a better world than they did, and just as importantly, have the power to make it better for my grandkids.

It is absolutely imperative that we apply the highest possible standards of scrutiny, security, and integrity to the systems that facilitate our most sacred public right. Voting software, hardware, and system should not only be open, they should be the zenith of openness. The public should be able to download complete specifications for every piece of hardware on every type of voting machine out there, from the device I vote on to the system that tabulates it to the printers that make the reports. We should have access to every line of code used in the entire process. I should be able to test it myself and find flaws or solicit advice from those I trust. The public should have as much access to the hardware as is feasible. Regular citizens, universities and vendors should be encouraged with bounties to find and report flaws they find. Defect reports on voting systems should be legal documents, also open to review by all. There should be digitally signed video publicly viewable via live broadcast or within hours of all access to every machine with the sole exception of the person casting a ballot. There is room for only ONE secret in this entire process, and that is who an individual voted for.

I would be exceptionally pleased if you would propose or support legislation to help protect our votes by virtue of an open and honest process. It would not only validate the sacrifices millions of Americans have already made, but it would set an example that other democracies and future generations will aspire to.

Sincerely,

Eric F. Savage

Also sent to my Senators Kennedy and Kerry, Representative Frank, Governor-Elect Patrick, State Senators Brown and Creem and Secretary of the Commonwealth Galvin. If you feel similarly I encourage you do write to your officials and feel free to borrow or copy from my letter.

For more, better information on this topic I recommend checking out Ben Adida’s Blog and Black Box Voting. A web search for ‘secure voting’ or similar topics will also turn up piles of other opinions and (often scary) facts.

Glossary: Kilby Shortcut

Posted on by Eric F. Savage

Every group of friends develops a very localized parlance, usually drawn from movies they’ve all enjoyed or memorable events. My group of college friends was lucky enough to include someone who had inherited a dominant curator gene, Keith Tyler. This is well-evidenced by his contributions to Wikipedia, but also by his entering into the historical record a fairly exhaustive list of rubbonics, complete with phonetics, that would be useful in deciphering our conversations of the day.

This way's faster!Sometimes, a term or phrase has the potential to break out of the group and escape to the community and beyond, and I’m going to nominate one to do just that, or at least get it into Google. This term was apparently born after the rubbonics were codified, and I can’t remember the date, but I do remember the circumstances.

We went to the Cheri Theater (now the site of the Summer Shack and King’s bowling), one chilly Boston night. On the way back, Kilby proclaimed “this way’s faster” and promptly crossed the street. We declined to follow and proceed on our way as Kilby marched down the other side of the street. At the next intersection, he crossed back to our side of the street, but was there before us. “How?,” you ask. The answer is simple, he walked faster. This was not the first time he had performed such a feat, but it was then that the phrase “Kilby shortcut” was coined.

Kil·by short·cut

noun (kÄ­l’bÄ“ shôrt’kÅ­t’)

A path between two points which is longer than other obvious choices, but the extended length is mitigated by travelling faster.

An ironic footnote is that Kilby doesn’t drive, and never has, yet somehow is the best navigator I’ve seen when it comes to exploring cities or unfamiliary territory. Except, of course, when he says “this way’s faster”…

Naming Conventions: Java Packages

Posted on by Eric F. Savage

When developing, conventions can mean the difference between producing something clear and concise and producing something confusing and arcane. They exist at all levels, from the industry and the language down to specific modules of applications. I’m going to attempt to codify some conventions for aspects I use heavily, and I’ll start with one of the easier ones, Java package names. Sun has some basic ones, but I think some more specific guidelines are warranted.

  1. Names should be all lowercase. Uppercase and mixed case denote other concepts in Java and there’s no need to muddy the waters further.
  2. Names should be alphanumeric, preferably just alphabetical.
  3. Do not use version numbers or dates (see below for a possible exception).
  4. Use tld.domain-you-own.project/library.* for distributed or published code. This follows with Sun’s convention, and is the only way to know a name is globally unique, or at least that you are the one that’s allowed to use it.
  5. Do not use tld.domain-you-own.* for internal code that should not be distributed. I typically just use the project or library’s name as the first segment. This convention can be useful in signaling other developers that code is for internal use only, and if something is converted from internal to external usage, this will help identify which version an application was built against.
  6. Package names that are nouns should be singular (mycompany.myproject.account). This maintains consistency with packages that are named for actions (mycompany.myproject.search) and adjectives (mycompany.myproject.common).
  7. Store DAOs in a “data” subpackage. This helps the tree-views in IDEs and also allows for easier control of logging. If you’re being formal and encapsulate DAO operations in a manager class, the manager class should not be in the data package because it’s grammar is business-based, not persistence-based.
  8. Classes that are heavily dependent on third-party packages should be in a subpackage named for the primary dependency. A Hibernate implementation of your DAO should live in mycompany.myproject.data.hibernate. This helps greatly with logging configuration. This is one place where version numbers are permissible, such as mycompany.myproject.data.hibernate3. Use this exception very sparingly, as it can be confusing with regards to forward compatibility.
  9. Classes that are extensions of third-party code should be named for the dependency and be outside of the project’s or product’s context. For example, if you are creating a new type of controller for Spring MVC that does not depend on project-specific code, put it in mycompany.spring.controller. If it is integrated with the application, see the previous point.
  10. Don’t expose organizational details in the package structure (mycompany.mydepartment.myproject). Naming packages by department, office, or region will surely be confusing soon due to management’s penchant to reorganize and reassign.

I consider the above a work in-progress, and welcome comments.

An Open Letter to Recruiters

Posted on by Eric F. Savage

Dear Recruiter/ Staffing Specialist/ Hiring Manager/ Headhunter/ HR Ninja,

Nobody's calling :(As you likely know all too well, the job market is red hot for developers right now. Getting a good senior developer to even return your calls is a challenge. You offer competitive salaries, have a nice benefits package, flexible schedules and relaxed dress codes. You’re doing everything you can, and the only responses you’re getting to your job listings are dummies and spammers. So what are you doing wrong? Well, I don’t have the complete answer, as I too am having trouble finding people, but I’d like to offer advice on one area, your job listing.

99% of developer job listings seem to look like this (this is a slightly edited actual job listing):

Description:
Super Recruiter Staffers has partnered with a progressive e-business and marketing company in Smallville, KS, and is seeking a motivated and experienced Java Software Engineer.

The successful candidate will bring a solid understanding of J2EE to an experienced development team with a strong technology background.
Responsibilities:

  • Analyze, design, and implement Java and Java EE based software applications
  • Participate in all parts of the development life cycle
  • Responsible for the complete life cycle development of major components and sub-systems
  • Leverage past development experience

Requirements:

  • Required Skills/Background:
  • BS degree in Computer Science
  • 2 years hands-on Java EE design and development experience in a professional capacity.
  • Experience with the following Java EE technologies; EJB, servlets, JMS, and JDBC
  • Proven experience with JSP, Struts, JDO, JPA, and Spring.
  • Proven experience using application server environments to build enterprise level multi-tiered applications
  • Proven experience architecting n-tier applications (Oracle 10gas preferred)
  • Excellent object-oriented analysis and development skills
  • Working knowledge of UML, XML, Ant
  • Self-starter with the ability to work both independently and as part of a team.
  • Ability to manage multiple priorities effectively
  • Excellent verbal and written communication skills

Other desired skills include:

  • Experience in performance tuning, load testing, deployments, and QA
  • Experience with full software development life cycle including functional & technical specification, documentation, QA processes, source control (CVS), maintenance, and deployments
  • Experience with Oracle 10g
  • Experience developing software for manufacturing industry

If you feel that you have the above qualifications and are interested in discussing this opportunity further, please apply today!

What’s wrong what that?, you ask. A lot, I say. Here’s what you’ve told me:

It’s a poorly defined position.

You listed a bunch of Java technologies, some of which I’ve used, some which I haven’t. It’s unlikely that all of these are needed, because you’ve listed typically opposing approaches like EJB & Spring, Struts & Servlets, etc. These can co-exist for sure, and maybe it’s part of a migration, but your shotgun approach isn’t tell me much. Also, you want “proven experience” in a technology that is brand new (JPA). I remember seeing job listings back in 2000 for people with “10+ years of Java development” (it had only been out for 5 years).

You aren’t being very honest.

You say that a BS in computer science is required. Of course it isn’t. Very few of the best developers I know have CS degrees. I’ve worked with people who had degrees in everything from Library Sciences to French to Math. If it’s not required, don’t say it is. What you really mean is “preferred”, but even that’s questionable. What this really tells me is that you just copy-and-pasted a boilerplate description and you’re not trying very hard, so why should I?

You want a Super Genius.

You want 2 years minimum experience. You also want someone who has “proven experience” in a wide array of technologies and can architect “enterprise level multi-tiered applications”. If you’re interviewing people with 2 years experience to architect enterprise software, you’re in trouble. And if you’re interviewing architects for a job that someone with 2 years of experience can do, you’re wasting everyone’s time.

I’d be part of a team of indeterminate size.

So I’d be part of a team, that’s valuable information, but it’s not nearly enough for me to gain specific interest. A small, agile, team? A large, influential team? What’s the purpose of the team? What department are they in? How many projects do they work on? Will I be a senior member or a rookie?

I’d be working for a company that does something, somewhere.

I’m either working for a manufacturing company, or for a company who has a manufacturing company for a client. That’s a fairly large distinction right there, and even if you answered that there’s other questions. What kind of manufacturing? Do they make DVD players or cinder blocks? If it’s a consulting firm, what else do they do? How big is this company? How long have they been around? Are they public?

How to fix it

Tell me exactly what you need done.

There are generally three types of hires:

  • You need to staff an existing or upcoming project.If this is the case, describe the project. This includes the team, the client, the goals, the timeline. “A new team building an e-commerce site for a Fortune 500 client” or “A small team developing a new medical billing product line for small practices”. I’ve worked on many types of projects for many types of clients, and I know what I like. If you hit some of my favorable notes, you’re much more likely to hear from me.
  • You want to grow your technology staff.For this one, tell me what I might be working on long-term. “We want to grow our retail software practice” or “We want someone to evangelize semantic web technology internally and to our clients” are good starts.
  • You need someone right now for a project, and you want a long term growth.This one is probably the most common, and is simply a combination of the previous two. Be as specific as you can, and if you can’t because it’s wide-open after the current project, say so.

Talk to the people this new hire will be working with.

You probably got your job description from a VP or director, with some input from a middle manager or two. Ask these people who they currently have that they want more of. Then go and interview these people. Developers generally abhor meetings and organizational details, but if they see their input having a direct effect on who they have to work with or for, I would bet they will be more helpful than you suspect.

Tell me about the company.

With so many choices out there, people can be very selective about who they want to sell a few years of their life to. The more companies that are hiring, the more info you should be giving. Is the company growing? How fast? Are there multiple offices? Do you keep pace with the market or exceed it? Do you invest in R&D? Is your organizational structure flat or deep? How long do people stay with the company? You don’t need to point out the flaws, but every strength you highlight is more bait on your hook.

This is just the beginning. The market is very competitive and the competition is very weak. Improving your ability to get people to answer your calls is not only valuable, but it’s really not that hard.

Sincerely,

A Developer

Alexa

Posted on by Eric F. Savage

Tikkataulu, a finnish (nordic) game that is similiar to darts.I’ve spent most of my career working with and for large companies and clients. I watched the 90’s .com boom mostly from the outside, and only recently got involved with the startup ecosystem. So far, I’m finding it exciting and appealing, but there’s one aspect that flat-out confuses me.

Alexa is, in brief, spyware. It’s not sketchy like Gator or any of the other horrible things nerds have been cleaning off their mom’s computers for years, but it basically tells a server which websites you visit. In return for this, you can view some meta-information about the site you’re on, find related sites, etc. It’s been around for a while, and is now part of Amazon’s otherwise benevolent kingdom.

I have never, ever seen anyone use it. Anyone who is tech-savvy with a modicum of concern for privacy wouldn’t even think about installing it. I’ve even experimentally explained it to some non-techy people in neutral terms, and gotten negative responses.

The thing that confuses me is that it seems to be practically gospel in the startup/VC community, especially those who sit in the bleachers and offer commentary about the sector. This is largely due to the fact that it’s the only way to compare traffic between two sites, but its results are more than inaccurate, they are misleading, and dangerous.

I have available to me (not shareable, sorry) the traffic information for two sites. Site A has a mainstream audience and no revenue. Site B has a somewhat more technically-oriented audience, and is barely profitable. Site B gets twice as many visitors (and far more traffic) as Site A. Site A’s metrics on Alexa are twice that of Site B. I don’t even think a margin of error this vast has a name in statistics.

So I guess what I’m trying to say here is don’t use Alexa “until something better comes along” or “just for another viewpoint”. Just don’t use it at all.

The Toolbox: Introduction & Log4J

Posted on by Eric F. Savage

In my own semantics, software development is a blend between a conventional profession and a craft. As a craftsman, I have a preferred set of tools with which I build and create. Of course, as a contract developer, I don’t always get to use what I want, but these days I more often find myself in a position to do so. I figure it might be useful to others, especially those just getting into the game, to see what an experienced developer actually uses, and why. So let’s start with an easy one, Log4J.


Log4J.There are essentially 3 major choices when it comes to logging in Java. Log4J, Commons Logging, and Java Logging. My current preference is Log4J. Why?

Commons Logging is an abstraction layer, and defaults to using Log4J for its actual logging. The main idea behind CL is that you aren’t tied to a specific logger. I think CL is flawed in two ways:

1. Log4J is itself extensible. Writing a custom appender (the piece that actually writes the log message) is a fairly trivial task, and if your project makes such a fundamental shift as to change its logging API, writing a bridge appender is a negligible amount of effort. So if you’re going to be using Log4J anyways, as most projects do, why add unnecessary complexity?
2. Commons Logging is always more difficult to configure. I honestly can’t figure out why, but almost every project I’ve worked on that uses CL has had issues, especially when you have a mix of libraries which do or do not use it.

Java Logging, added several years ago in Java 1.4, was supposed to eliminate the need for third party logging APIs. It was, and remains, a good idea, but it does not make a compelling case to switch from the vastly more popular Log4J. Last time I checked, the standard logging API was missing a rolling file appender, which is essential for any production environment. It is also slightly less flexible to configure, but the main reason it has largely been irrelevant is that it doesn’t offer anything that Log4J does not.

What would make me switch?

I’m a very heavy logger. I will often write code with as many log statements as regular lines of code, and of course most of these statements are debug/trace level. The problem this introduces is performance. Let’s look at this example:

Person person = PersonFactory.getPerson(name);
log.debug("Found " + person.getName());
precinct.register(person);

The problem is that even if logging is at a level above debug, getName() will be invoked. In practice these statements rarely do anything expensive, but it can be the proverbial death by a thousand cuts. The Log4J way to avoid this is to do the following:

Person person = PersonFactory.getPerson(name);
if(log.isDebugEnabled()) {
log.debug("Found " + person.getName());
}
precinct.register(person);

Messy huh? What I would like to see is the ability for the java compiler to skip these statements entirely, without the cruft currently required. If this ended up being some special case that required the use of the standard logging API, I would switch. The slick way to do this would be to have the ability to annotate methods for lazy reads of parameters being passed to them, but that, as Alton Brown would say, is another show.