I recently attended the Gateway Java Software Symposium in St. Louis, MO. One of the more interesting sessions at this conference, in my opinion, was Dave Thomas’ talk on Naked Objects. Naked Objects represents a radical shift in developing GUI applications. In its simplest form, programmers write business model objects, exposing the functionality of that object and its relationships to the end users. The users of the application interact directly with the business model object, therefore anything the object can do the user can do.

Why?

Dave points out the obvious: user interfaces are too hard to write and they typically do not provide all the functionality we need. Have you ever walked into a fast-food restaurant and the person taking your order says, “My computer will not let me do that.” If so, then you might appreciate what naked objects are trying to accomplish:
unfettered access to all of the object’s functionality.

Huh?

So how does Naked Objects work? Naked Objects is a framework that uses reflection to determine the data and behavior of business model objects. Since reflection is being used you may have guessed that we must follow certain naming conventions. For example, if you define the method public TextString getFirstName(), then the user interface shows a label and text field representing the first name. The TextString class represents a Naked Object string, and informs the framework to create a text field that allows the user to manipulate the first name.

User Interface

Another cool thing is that Naked Objects are manipulated through drag-n-drop and right-click menus. The Naked Objects framework automatically supplies this functionality. Once again, this means that you focus on writing the business model objects and the user interface is automatically generated. Be aware, the generated user interface is very different to what typical users are used to. For example, each object is represented in its own non-modal window. This means if you have a Customer object and you are working with three instances, “Bob”, “Chuck”, and “Joe”, then you will have three open windows. Of course, this may change if the Naked Object framework grows.

Testing

How do I test Naked Objects? You do write tests, right? The Naked Objects framework provides support for unit testing and acceptance testing. Unit testing is performed with good-ole JUnit. Acceptance testing is based on user stories in terms of user interactions, and the full story is generated in nicely formatted HTML pages. The acceptance tests are written as code, too.

Persistence

What about persistence? Ah, another great question. The Naked Objects framework supports JDBC and EJB, as well as writing out to XML files. When unit testing you can use a transient persistence mechansim.

Should You Care?

Is Naked Objects the wave of the future? Probably not. It is a cool idea, though, that may work well for certain types of applications. I have tried to think of how naked objects would fit into my current project. To be honest I don’t think it’s a good fit because we have a very structured system, where naked objects, as they are today, appear to work well with loose and interactive systems.

Here’s a quote from Dave’s presentation: “Even if you never use the Naked Objects Framework, think about how the approach might affect your future designs.”

Perhaps one day I’ll get around to writing a full-blown article. Until then the Naked Objects website provides some good example applications to play with. Enjoy!

I had originally intended to write this post about “acing the phone interview.” But that’ll have to wait for a while. Based on feedback to an earlier blog, though, a lot of people have questions about resumes and cover letters. In this article, I’ll
say a few more things about resumes.

But first, bear in mind that this is an idiosyncratic point of view, based on my experience in interviewing and hiring people over the last three years. I’m not claiming
deep wisdom or scientific truth here, just a few helpful pointers.

In general, you should have more than one resume, depending on what position you’re applying for. I’m not saying you should write a resume for each application, but the resume you send in, for example, for a “research programmer” position should look a little different from the resume you send in for a “team lead” position.

Resumes should also reflect your goals. This might sound obvious, but far too many resumes out there are lists of facts. They state what people have done, in a fairly unorganized (or, organized solely by time) way. And, frequently, at least for technical positions, they focus on technologies.

For any job, there are at least 6 important facts: why you were there, what you did, what role you played, what skills you used, what skills you acquired, and why you left. Not all of these belong on your resume. But, think about the job you’re hoping for, and think about what you want to include. Very often, the role you played is important, and barely mentioned.

There’s a subtext to the things you mention. Anything you mention on your resume should satisfy at least one of the following criteria (and usually more):

Related link: http://conferences.oreilly.com/oscon

Here is a preview of this year’s unofficial O’Reilly Open Source Convention (OSCON) Java Conference. This year’s Java Conference focuses on the practical, giving you the tools you need to get the job done with this important, platform-independent language. The program features such topics as using Ant to build software; using Struts to build your websites; searching text with Lucene; and help in selecting an Open Source J2EE implementation.

Java Tutorials

What Works In Software Development

Michael G. Schwern

Norman Nunley

Day: Monday, July 7
Time: 8:45am - 12:15pm
Location: Salon F
Track: Apache, Apps, Emerging Topics, Java, MySQL, Perl, PHP, PostgreSQL, Python, Ruby, XML

Enterprise Java Development on a Budget

Christopher Judd, Judd Solutions, LLC

Brian Sam-Bodden

Day: Tuesday, July 8
Time: 8:45am - 12:15pm
Location: Salon A
Track: Java

Building Web Applications With The Struts Framework

Craig McClanahan, Sun Microsystems, Inc,.

Amy Roh, Sun Microsystems, Inc.

Day: Tuesday, July 8
Time: 1:45pm - 5:15pm
Location: Salon A
Track: Java

Java Keynotes

An Open Source Tool Framework for the Enterprise

Paul Buck, Director of Eclipse Development, IBM

Day: Wednesday, July 9
Time: 9:30am - 10:15am
Location: Oregon Ballroom
Track: Keynote

The Business and Economics of Open Source in the Enterprise

Stormy Peters, Hewlett-Packard Company

Day: Thursday, July 10
Time: 8:45am - 9:30am
Location: Oregon Ballroom
Track: Keynote

Java Sessions

Applied Ant

Erik Hatcher, eHatcher Solutions, Inc

Day: Wednesday, July 9
Time: 10:45am - 12:15pm
Location: Eugene
Track: Java

Introduction to Lucene

Erik Hatcher, eHatcher Solutions, Inc

Day: Wednesday, July 9
Time: 1:45pm - 2:30pm
Location: Eugene
Track: Java

Looking Beyond JDBC

Satya Komatineni, Active Intellect, Inc.

Day: Wednesday, July 9
Time: 2:30pm - 3:15pm
Location: Eugene
Track: Java

Java Data Objects (JDO): What It Is and Why It Matters

Ron Hitchens, Ronsoft Technologies

Day: Wednesday, July 9
Time: 4:30pm - 5:15pm
Location: Eugene
Track: Java

Deciding on an Open Source J2EE Platform

Ed Lyons, NetNumina Solutions

Day: Wednesday, July 9
Time: 5:15pm - 6:00pm
Location: Eugene
Track: Java

Beyond Struts

Michael Rimov, Centerline Computers

Craig McClanahan, Sun Microsystems, Inc,.

Day: Friday, July 11
Time: 10:30am - 11:15am
Location: Columbia
Track: Java

Up until a few days ago, I routinely received 100-200 spams per day in my Yahoo Email account. A few days ago, the number seems to have dropped to around 10-15 per day. I thought it was a fluke, but so far their filters seem to be dramatically better.

Have any other Yahoo mail users seen this improvement?

Were the Yahoo mail spam filters upgraded last week?

The company I work for recently had a position open; we needed to replace someone who left in our deployment group. I wrote a fairly targeted and reasonable advertisement (e.g. it wasn’t a laundry list of random acronyms;
it really did describe the position and list the qualifications) and posted it to a local bulletin board. About 100 responses came in (side-note: I was expecting more; the job market really is getting better). And it was my job to find the suitable resumes, and do the phone screening.

I realize it’s a tough economic climate. But people could manage the initial stage of the process a lot better. Here’s the most important things that I noticed repeatedly, that people could do to improve their chances:

• Only apply if you have a chance. The number of people who sent me their resumes when they didn’t meet most of the listed criteria, and only met some of the criteria by coincidence, was staggering. If I list 10 criteria, and you only meet 3, you’re not going to get the job. Sending your resume is just wasting both of our time.
  

• Write a cover letter. You should always include one. Please. Especially if the position is customer-facing and emphasizes communication skills. A well-written and concise paragraph explaining why you’re interested in the position and what makes you qualified is invaluable.
  

  Note that I said paragraph– we’re talking a short note that positions you well. More than that is overkill.
  

• Get the name of the position right. Lots of people invent position names. If the advertisement says the job is ” Technical Support Specialist,” don’t apply for “QA Engineer.”
  

• Use a specific subject heading in your e-mail. “Re: [job name]” works perfectly. “Hello?” or “Job Application” does not.
  

• Use spellchecking. Use grammar checking as well. I know that most grammar checkers reject perfectly valid sentences. But they also catch some howlers.
  

• Don’t send word documents. In this age of viruses, why would you deliberately send me a Word document? Why assume that I have the right version and can read it? And why assume I’d take the risk? If you feel the formatting is that important, send the word document *and* a text version and let me choose. Or send me an HTML or PDF document (and if you have Word, you can send me HTML). I wound up running all the e-mail through a virus scanner and then opening the Word documents anyway. But … people who sent me text or PDF or HTML (and especially the people who sent both a Word
  document and an HTML document) got a leg up. It makes a good impression when the cover letter says “I’ve included both a Word version and a text version of my resume.”
  

  
  Slight modification to this, based on feedback. This should really be don’t send unsolicited word documents. If the people doing the screening want word documents then, by all means send them one.
  

• If you send your resume as a separate document, name it correctly. Resumes named “Resume” have a higher chance of getting lost somewhere. Resumes named “Resume_BobSmith_QAEngineer_Feb2003″ are much easier to find.
  

• Don’t make assumptions about the person reading your e-mail. Sometimes it’s an HR manager. Sometimes it’s the person who will be supervising you. Sometimes, it’s someone else who got dragged in to help process the applications.
  

• Don’t negotiate price in the cover letter. In the first stage of screening, the company is mostly interested in figuring out whether you’re a fit for the job. Anything else is a distraction and, worse, will lead to the “Hmmm. Why is she mentioning that?” question (once the screener starts wondering that, your chances have gone down). Similarly, mentioning availability isn’t a particularly good idea, unless you’re not going to be available for a while (the default screening assumption is that you’re available in a reasonable time frame. Otherwise, why would you have applied).
  

These aren’t rocket science. But, when you total up the statistics, over half the people who applied broke two or more of these guidelines (the single most common submission was a word document without a cover letter. In more than one case, the subject line of the e-mail was empty too).

Thoughts? If you’ve screened resumes, what do you look for?

Cameron and Cedric have been talking about beautiful code.
Cedric talked about how people don’t tend to say “wow” a lot with Java code, due to the syntax. If someone pulls of an amazing line of Perl, fellows can see how cool it is that they did that. Other people think “why” and “i am glad I am not maintaining that!”.

Regarding some of the code they talk about:

Cedrics:

List users = dao.getUsers();
for (int i=0; i < users.size(); i++) {
User user = (User) users.get(i);
  // do something with user
}

Camerons:

List listUsers = dao.getUsers();
for (int i = 0, c = listUsers.size(); i < c; ++i)
    {
    User user = (User) users.get(i);
    // do something with user
    }

Neither of those look that cool do they. I personally would much prefer to see:

foreach (user in dao.getUsers()) {
	// do something with user
}

I am looking forward to the foreach statement joining the Java language. Casting and futzing around all the time can be such a pain… sometime you just want something simple that works :) But, at the end of the day, it’s the same stuff, just a different day.

Now, on large projects, the “wow” factor comes from great elegant DESIGNS (like Cedric mentioned), not a great few lines of code. I will use your interface… as long as it does what is stated, I don’t care what you did :) [within reason]

Don’t even get my started on the code indentation that Cameron uses ;) Each to their own.

Related link: http://www.waferproject.org

Jeff Dill, who is a VP at Isomorphic, gave a talk at the Emerging Technology SIG.

One of the interesting references he gave was to the wafer project. Their goal, in their own words:

Wafer is a research project which compares the many open source web application frameworks which are available using a common example application. This research project is designed to compare the application frameworks on a level field by specifying an example application so that the application features become irrelevent and the merits of each framework becomes the focus.

The art of writing simple, concise code has been on my mind lately. Actually, I’m more concerned with overly complex code. When I see huge blocks of overly complex code with lots of duplication, horrible variable names, and obvious bugs, I do everything in my power to fix the problems. I just cannot stand to leave garbage code in place if I can help it. Bad code bothers me.

What troubles me is the observation that we have legions of programmers who don’t seem to “get it” when it comes to writing maintainable code. They are happy to produce reams of code that seems to solve the immediate problem at hand, and are perfectly content to move on to the next problem, leaving all of this horrible code behind.

The million dollar question is…how can we train programmers to be passionate about crafting quality code?

Sometimes the problem comes down to experience, which is perfectly understandable. As a programmer matures and gains more experience, I would expect him to write better code. The best programmers solve problems with fewer lines of code than beginners. Over time, most people get better.

The true challenge occurs when you have people who have been programming for years but don’t seem to have an appreciation for simplicity. They seem to produce “Rube Goldberg” code for any given problem, always finding new ways to bypass standard frameworks and reusable solutions in favor of complex, convoluted code that is unique to each situation.

So what can be done?

First, I recommend that all programmers read “The Pragmatic Programmer: from journeyman to master”, by Andrew Hunt and David Thomas. This is a GREAT book, and should be required reading for all programmers.

Second, I think that projects need some sort of technical oversight. In the traditional model, you would need a strong technical leader who stays abreast of changes in the code and constantly suggests better solutions. Code reviews are also invaluable, and should not be deferred until the end of a project.

In an XP environment, pair programming helps. Whenever I pair program I find that two people almost always come up with simpler solutions to any given problem. Just the fact that you are sitting down and explaining your code as you go forces you to slow down and think about problems more carefully. Having someone look over your shoulder also makes you feel guilty when you write really bad code…

I have definitely seen scenarios where lack of communication results in hugely complex, buggy code. The problem is that programmers who write bad code probably don’t have any sense for how important ideas like refactoring are. Unless you expose them to these ideas through code reviews, pair programming, or other forms of team communication, they may never improve.

Writing great code is a mysterious blend of technical skill, experience, and art. I am not convinced that all people can be taught to be passionate about writing great code. I am, however, convinced that the best strategy for success is good communication among team members and an environment where people get to see and review each other’s code on a continual basis.

Why are some people clueless about database design? I have seen time and time again database designs that are completely wrong, especially when assigning primary key columns.

I have seen database models where the primary key is a mutable field. Most of us know, or we should know, that once a primary key is set that key should NEVER change. For some reason, some people do not see a big deal with this strategy. They say, “Well just erase the old record and insert a copy with the new key value.” This is wrong. If you know that a field is mutable then do not make that field a primary key. Instead use an auto-generated number (if your database supports it, which most should), or come up with some other bogus key.

But you may say, “Well the legacy database forces this design.” My response, “No it does not!”. Typically the only time a legacy application matters is during the data conversion process, which is a one-time deal. Spending a little extra effort on the conversion scripts can ensure that the new model is clean and maintainable.

Why does it matter… I am just a programmer? A clean database design is critical for software development. The cleaner the database design, the easier your server side logic is to implement, and the faster your server side code executes.

Here’s an example:

You need to change the value of an account number on the account table. Here’s a possible solution if the account number is the primary key:

1. Retrieve the original data from the database (store this data in memory)
2. Delete the original data from the database
3. Update the data in memory with the new account number
4. Add the new account record to the database

NOTE: this takes a minimum of three database calls.

Here’s how to do this if the account number is not the primary key:

1. Update the account number on the account table

NOTE: this takes one database call and hardly any code.

I don’t think it takes a genius to design good database models. A little common sense and a big white board leads to a clean and agile database model, which in turn, leads to a clean and agile code base.

Related link: http://www.eweek.com/article2/0,3959,1053275,00.asp

As reported this week by eWeek, Borland releases Janeva, a J2EE and .NET interoperability and connectivity tool. According to Boz Elloy, Borland’s vice president and general manager of enterprise solutions: “Janeva enables .NET clients and servers to connect with J2EE and CORBA back ends using [Internet Inter-ORB Protocol] as the transport mechanism.”

Janeva (sounds like Geneva with J for Java) aims to be the neutral bridge between Java and .NET, and will be bundled and shipped with Borland’s new C#Builder, an IDE for the .NET framework. This kind of interoperability is crucial for developers these days given the consolidation of companies further increasing the number of heterogeneous development environments. Of course, Web services naturally lend itself to interoperability; however, the level of interoperability provided is limited. There is a need for more powerful, server-side logic-tier interoperability using EJB, COM, and CCM, for example. Janeva is one tool that should accomplish this.

Janeva is one example why Borland has, and will survive. Analysts, editors, and the public wonder if Borland can compete with Microsoft in the Windows developer tools market. Borland isn’t competing. They are in their own market. They have the market leading Java IDE in JBuilder. Now, with Janeva and C#Builder, they have provided an interoperable .NET solution for its large base of Java developers who need to work in .NET environments. Long-term, they will grab a larger share of Windows and .NET developers from Microsoft who need to work in a Java environment. Java is still the server-side programming language in the server-side market.
Given this, Borland is taking the lead in the programming language interoperability market.

Given the importance on this kind of interoperability, why isn’t there more programming solutions, tools, books, and more on the subject? Of course, Microsoft and Sun have not really provided much on the subject in the form of standard specifications, either.

What do you think of this kind of interoperability; and how important is it to your enterprise development needs?