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.

Introduction

Posted on by Eric F. Savage

This is my blog. There are many like it but this one is mine.

Journal.My name’s Eric Savage, and I’ve debated whether or not to have a blog for a while, and decided to give it a shot. The decision wasn’t a matter of risking a blow to my ego if I didn’t get enough readers. It also was not a matter of someday becoming a self-sustaining “pajama blogger”, as I can think of few things less rewarding to me than offering nothing but commentary. There were three main questions involved:

1. Can I do it?

Can I really build the discipline to write something on a regular basis? My money is on “not likely”, but I’m an optimist, and I think it’s worth a shot.

2. What to write about?

“Write what you know” is probably some famous quote I’m failing to attribute. What I know is software development. Not all of it of course, it’s a pretty variegated profession, like law or medicine or engineering. I’ve staked my claim in the unsafe fringe territory of user-facing business software. This is a place where purists are disappointed, progress is slow and messy, and unsavory characters lurk in every corner. On the other hand, it’s the nexus of the industry. The brilliant minds at work tuning database indexing algorithms and packing and finding a way to pack an extra thousand transistors onto a chip ultimately get their paychecks from people that just want to check their email or put a picture of their dog on myspace. Blogging about software is inevitably going to be dry, but I’ll see what I can do.

I also know bits and pieces about other things, so I’m sure those will make their way in here, and of course there’s probably going to be some uninformed opinions and maybe even videos of bears bouncing of trampolines, if you’re lucky.

3. What not to write about?

Politics and religion, because even though I try to keep up on both, I really don’t have the willpower to discuss it with people I don’t know.

However, the real impetus for deciding to start a blog was that I noticed I was finding more and more answers to my technical questions on blogs. The old model was to post your problem to a forum and hope for an answer. A search for most tricky problems would return such an exchange between others. But lately I’ve been getting many more results for people that solved the problem themselves and figured that others might find it useful. I’ve always enjoyed helping people solve problems and mentoring, and this is a pretty good way to do both.