Java Development Skill Defaults: Spring/Hibernate/jQuery

Not too long ago a local recruiter noted at a JUG meeting:

“I don’t care what else you have on your resume, but you have to have Spring and Hibernate. I know it was all EJB and SOA just a few years ago, but now if you don’t have Spring/Hibernate you’re not getting past the HR screen.”

As a development manager and even in my professional services role I tend to screen dozens of resumes. I have noticed the preponderance of Spring/Hibernate taking over the usual emphasis on EJB and Struts on the average mid-level java developer. It’s actually a pleasant change to know that the open source community ended up victorious in the marketing war over the official specifications.

Knowing Spring can mean all sorts of things since it’s a fairly large framework. At a minimum I expect a developer to have an idea of using it for dependency injection, but it’s nice to see some exposure to Spring’s AOP concepts, Spring Security, or even something like Spring Batch. It’s a bounus when they have exposure to something like Grails which has been added to the Spring family and wraps much of the low level Spring items in a nice DSL framework.

With Hibernate most developers have left behind either the old hand rolled JDBC DAO patterns or potentially entity beans. Generally, I expect they can handle any sort of mapping and understand things like named queries, lazy loading, and second level caches that can catch developers new to Hibernate by surprise.

I’ve also noted that jQuery in the last year or so has largely become the winner among Javascript libraries and is typically the most common experience I see on resumes. The days of getting by with largely full page reloads for any new request are gone and the Web 2.0 sites have increased UI expectations even for corporate users.

Looking back a few years it was still the rare corporate shop that cared about frameworks like Spring or Hibernate. The emphasis was on heavyweight solutions like classic EJB or closer to the metal approaches like rolling your own JDBC for every database request. The progress to Spring/Hibernate has been an impressive win for developers wanting something simpler.

I do have a few regrets that JUnit and unit testing are still not a default requirement with most development shops. Almost every java developer has the keyword somewhere on their resume, but I screen enough people to know usually that means they’ve written a handful of unit tests for perhaps one project in their career and really don’t understand the value of it.

I also regret that in Java land there are not a handful of default web frameworks. Instead we have dozens of options. .NET, Python, PHP, and Ruby have been more successful in this arena with a handful of web frameworks to choose from in each camp. Usually if you move to a new job you’re going to have to get up to speed on yet another web framework, because the options are so splintered. Maybe this will consolidate in the next few years. At least with the new languages on the JVM you’re seeing only one or two web frameworks like Groovy with Grails, Scala with Lift, or even JRuby with Rails. The example in Ruby with Rails merging with Merb for 3.0 is something the Java world needs to do more of.

So if you’re a java developer and you haven’t had any real exposure to Spring and Hibernate, I’d advise at least spending some time with some tutorials at home. The economy is bad enough that you never know when you’ll be dropped back onto a fairly hostile job market and you’ll at least need them as baseline skills.

Coding Katas

A few weeks ago at the local Ruby Users Group meeting there was a suggestion of actually writing some code at the meeting. The suggestion was to use a Ruby Quiz exercise. It was quiz #16, a Rock, Paper, Scissors simulation. We broke up into small groups of about three people, coded for maybe 45 minutes and turned in our solutions. My team came in last but it finally pushed me to actually take up a long neglected todo item to start doing coding katas on a regular basis.

I’ve done the classic Bob Martin TDD bowling kata for years as an intro to TDD. I’d also walked through a one day tutorial from a Dave Astels session on Rspec back in 2006 that was very much a game based kata. I’d read about Prag Dave’s coding kata ideas, but I’d never quite found the time to start the practice.

Last week I started utilizing two major resources:

I’m jumping back and forth between Java and Ruby in the katas to stretch my skills. I may even add in Groovy at some point, but Groovy and Ruby styles are pretty similar. I’m trying to take on one per day and when I wrap around I’ll try out different languages. As a committed TDD student I’ve started each kata with a test. I have to admit RSpec makes this a lot easier when using Ruby and autotest is a wonderful tool. At least I have annotations and JUnit 4+ when I’m doing the katas in Java. For IDE’s I’m bouncing between IntelliJ for Java and TextMate for Ruby. I’m even taking the opportunity to test out git and I setup a github account to store the katas so I can see how I evolve over time.

If you haven’t tried out the practice I might suggest giving it a go. One of the best things is I get to really focus on coding for about an hour a day and it blocks out the rest of the world. Mostly I’m doing them in the early morning to cut down on the interruptions. I’ll probably post again on my observations after a month or so.

First Impressions on Cucumber

Recently I’ve been catching up with the Ruby world again in my limited spare time. I had an idea for a fun little hobby project, but I wanted to actually do it BDD style and in Rails 2. I dug a bit into RSpec again and realized they had a new BDD tool called Cucumber. Seeing there was a beta book out from the prags I paid and downloaded the PDF copy of ‘The RSpec Book: Behavior Driven Development with RSpec, Cucumber, and Friends‘.

Cucumber takes plain text scenarios and runs defined steps to verify the scenarios are working. The idea is Cucumber describes the higher level behavior with more of an outside that application focus and RSpec is used to test the behavior of the individual components. There seems to be some overlap, but it modifies the traditional Red-Green-Refactor into:

  1. Cucumber: Focus on one scenario.
  2. Cucumber: Write failing step definition.
  3. RSpec: Write a failing spec.
  4. RSpec: Get the spec to pass.
  5. RSpec: Refactor.
  6. Cucumber: Refactor.

I worked through the tutorial that involves the classic 70s game MasterMind. (I suspect Dave Astels at work there.) I like the textual description similar to FIT/Fitnesse without so many tables. The feature descriptions are in plain English with a few grammatically important keywords:

Next you take the Given, When, Then, And syntax and build out the steps one at a time diving back and forth into RSpec when you get down to the lower level details.

I find the regular expressions a bit jarring, but just like FIT/Fitnesse this is the code that the business users never see. If your lucky you’re testers can read the code and even key off for ideas to use for exploratory testing ideas. The only other item is I always feel more comfortable just dropping back to an xUnit type testing tool and using good practices to give the tests meaningful names and organize scenario testing appropriately. In some ways you could use just RSpec as well for this purpose. Still I’m forcing myself to use it for a while as any new practice takes some getting used to. Next up is integrating it with Rails.

Head First Rails Testing

Automated testing is one of the most important parts of software development, and yet until now, we haven’t mentioned it. Testing a piece of software relies on a thorough understanding of the tools you are using, and designing tests can be far more difficult (and enjoyable) than writing the code itself.

Head First Rails pg 407

Despite Rails effort in making testing easy the Head First Rails book ignores testing altogether until a slight mention on one of the very last pages of the book. I perused the index hoping I was wrong, but the author spells out that it was a deliberate decision.

I have a lot of respect for the Head First books as a great way to jump in and learn something new. I’ve posted before about how impressed I was when Head First Software Development went into depth on Agile and testing. Here I’m just saddened by the decision. Even a short appendix with a few examples might have sufficed if not examples throughout or a dedicated chapter. All the other Rails books I’ve come across at least devote some time to the testing conversation.