A recruiter from Tek Systems attends our local Sacramento Java Users Group (SacJUG) told a humorous and depressing story. It went a little like this:

HR Rep: Well, it doesn’t say here they developed any J2EE systems.

External Recruiter: It says designed and implemented two large J2EE ecommerce systems.

HR Rep: But that doesn’t mean they developed it.

External Recruiter: Implementing it means they developed it.

HR Rep: No, they might have only designed it and then deployed the final program, other people could have developed it.

External Recruiter: So if it said “designed, developed, and implemented” you’d be willing to interview them?

HR Rep: Yes.

The recruiter then explained that despite this frustrating conversation, developers would still be happy there because it’s just an HR hurdle and the development managers know what they’re doing. His advice was just to tailor the resume to mention all possible technologies and add words like developed. This way you don’t add extra hassle for the manager to get your resume out of HR.

For me this seriously flips the bozo bit. Even if I worked at a large Fortune 500 company I wouldn’t let HR own my hiring process. The minute you’re letting HR do screening for all but the most basic requirements you’re in danger of losing some of your best candidates. A rock star developer who has to deal with ridiculous HR flak will very often simply walk away from even a high paying opportunity.

To avoid this you write your own job descriptions for postings and don’t get to hung up on must haves especially around technology. You’re looking for the best developers even if they don’t have 2 years experience with JSF or SOA experience. You explain to HR that you want to see all the resumes. I can rip through a lot of bad resumes in a few minutes and I have to live with the eventual hire for years so there’s plenty of self-interest at work. Getting the best candidates is partially a sales job on your working environment, you as a manager, and their potential fellow developers.

Letting HR do a lot of pre-screening is just a bad idea for high end technical hires.

Writing some initial code for a JSF TDD seminar I’m putting together for our developers I had an early test method:

public void testUserCanLogin() throws Exception {
  User fred = new User();
  fred.setName("fred");
  fred.setPassword("password");

  UserBean userBean = new UserBean();
  userBean.setUser(fred);

  assertTrue(userBean.login());
}

After realizing the JSF backing bean, UserBean, is actually just a page controller and all I want it to do at this point is allow a user to login I refactored the name:

public void testUserCanLogin() throws Exception {
  User fred = new User();
  fred.setName("fred");
  fred.setPassword("password");

  LoginController controller = new LoginController();
  controller.setUser(fred);

  assertTrue(controller.login());
}

Part of this may be inspired by Ruby on Rails, but I get tired of using Bean in so many java classes, and really this bean was not just a traditional DTO style bean with no behavior. So Controller just feels a lot more explanatory. As an extra bit of semantic cleanup I renamed the default package for the backing bean. By default when you use RAD 6.0 to setup a new JSF page it dumps your backing beans into a

package which bugs the crap out of me. So since I’m starting from scratch and working in IDEA I just put it in a

package which describes its function better.

Last week, I finally got around to checking out Geoffrey Grosenbach’s PeepCode screencasts. Not much risk at nine bucks, I went ahead and sampled the Test First Development episode, because I’m a test first convert.

I learned a lot of small points:

• How to easily run Rails edge for a single Rails project.
• Other people, or at least Geoffery Grosenbach deal with BDD utilizing well named test methods including things like <div class="codecolorer-container text vibrant overflow-off" style="overflow:auto;white-space:nowrap;">

  1	test_should_guess_date

  </div>

  , so I’m not alone.</li>

  • Learned about the nice natural language date/time parser, chronic.
  • Move to <div class="codecolorer-container text vibrant overflow-off" style="overflow:auto;white-space:nowrap;">

    1	assert_select

    </div>

    replacing the

    1	assert_tag

    in Rails 1.2.</li> </ul>

    The format works really well for tutorials as you can follow along by simple pausing every 30 seconds or so and typing in the examples as you can go. Many technical trainers will tell you group demos are really great, but difficult to pull off. The problem is people don’t keep up at the same pace or they miss something typed in and start seeing exceptions instead of moving forward with the rest of the class. This really lets you follow along at your own pace. The other nice thing was that all of the code typed in actually worked.

    I’ll probably try out the TextMate screencast next since I don’t feel like I’ve yet scratched the full power of the editor.

About two months ago we caught a nasty issue with getting some

when comparing two

. The code that failed the unit tests looked something like:

if (startDate.compareTo(endDate) < 0) {

The strange part was the developers running IBM’s RAD 6.0 never had failing tests and

. The tests failed on the build box. When I tried the tests in IntelliJ they failed as well. After some investigation it was apparent it some of the

were coming from a Hibernate mapping class and so they were dates, but in actuality they were

. Since

extends

this wouldn’t appear to be much of an issue. The fix was simple enough:

startDate is actually a java.sql.Timestamp
endDate is actually just a java.util.Date

So just switching the order and utilizing

makes the problem go away.

if (endDate.compareTo(startDate) > 0) {

Seemed like a crappy overriding of the

method by

, but it did fix the problem. Some more digging turned up the real story. A bug, #6304469, was actually introduced in Java 1.5 and has now been fixed in 1.6. Since RAD 6.0 was running in 1.4 and it only supports 1.4 this explained why we didn’t see the bug in RAD.

The explanation in the Java 1.6 release notes is:

A regression introduced in J2SE 5.0 created a binary compatibility problem with java.sql.Timestamp.compareTo which was only detectable at run-time.

This bug is fixed in Java SE 6, Beta2 and in J2SE 5.0, Update 7 (5.0u7).

Learned a new term today going through 19 Deadly Sins of Software Security. They give an example of a URL containing a strange looking id parameter:

Turns out a simple run through a base64 decoder for gives you:

The authors then refer to this as an “encrapted” password.