David R. Heffelfinger

  Ensode Technology, LLC


Things I would tell recruiters if I wasn't afraid to sound arrogant

I am fortunate enough to work in a field for which there is a lot of demand out there. I get multiple emails every day from companies asking for help with their server side Java projects. Java developers such as myself

1. Don't call your position "an opportunity"
Like I mentined in the intro, I get tons of "opportunities" every day via email or LinkedIn messages. Java projects are a dime a dozen, chances are your project is not a "great opportunity" for me. You know and I know that Java developers are hard to find, if anything, me agreeing to work on your project is an opportunity for you, and not for me.

2. Don't say you have an "urgent requirement"
You may urgently need a Java developer, and I'm here drowning in emails from recruiters that also need Java developers. It may be urgent for you to fill that position, but it is not urgent for me to accept it. While we are on the topic, don't say the requirement is urgent if you are not willing to be flexible. One perk that would certainly catch my attention would be the ability to work remotely, but very few customers are open to the possiblity. If your requirement is so urgent, shouldn't you be a bit more flexible? Oh, and by the way, no, I am not willing to relocate just so that I can work on a 6 month project.

3. I don't stay on the market too long.
I work as a consultant on a C2C basis, therefore I switch projects every few months. Every time I post my resume on one of the job boards, I get bombarded with calls and emails from recruiters (even more so than when I'm not actively looking).
If you are interested in my services, you have to move fast, chances are that in a week or less I won't be in the market anymore.

4. Don't make me jump through hoops
I've written several books on Java, taught Java classes and been a speaker at Java conferences, as well as having about 18 years of experience. I think my experience speaks for itself. Please don't make me go through several rounds of interviews or take a silly test just so that I can work on your project. Just by talking to one of your developers he or she will be able to tell that I know what I'm talking about.

5. If I accept/am about to accept another project, don't ask me to "wait a few days"
As much as I get contacted by recruiters for several different positions, it is mentally exhausting and draining to talk to several potential clients, send resumes, etc. I just want to get it over with, so as soon as I get an offer, I'm taking it.

Java EE Course Trip Report

I just came back from teaching a Java EE class in San Francisco.

The course lasted two days, and it covered the most commonly used Java EE technologies and API's such as JavaServer Faces (JSF), Contexts and Dependency Injection (CDI), Enterprise JavaBeans (EJB), the Java Persistence API and the Java Message Service(JMS). The course also touched on Bean Validation and the Java API for RESTful Web Services (JAX-RS).

The students were veteran Java developers and architects, ranging from around 5 to 18 years of experience. There were a few students that had use EJB's back in the J2EE era, some that had used earlier versions of JSF (1.x) and some that had been focusing on Spring for their server side Java development.

None of the students had use modern versions of EJB or JSF, they were very impressed on how much easier modern versions of these frameworks are compared to their Java EE counterparts.

Since we had only two days, we only covered the basics of each technology, such as Facelets markup for JSF. For CDI, we covered context (scope) annotations and dependency injection for CDI. We mentioned additional CDI features such as qualifiers, stereotypes and interceptor binding types.

The different Bean Validation annotations were covered, pointing out how simple it is to do validation using just a few simple annotations. As far as EJB's go, I covered the different type of session beans, such as Stateless, Stateful, and Singleton session beans; as well as Message driven beans. For EJB's we went a bit deeper, covering things such as transaction management, interceptors for Aspect Oriented Programming (AOP) and the EJB timer service.

When talking about JPA, the class covered basic JPA annotations such as @Table and @Column, as well as one-to-many, many-to-one, many-to-many and one-to-one entity relationships. We also covered eager vs lazy fetching, and the advantages and disadvantages of each approach. We ended the JPA topic with a discussion of the Java Persistence Query Language (JPQL) and the JPA Criteria API.

I overheard some comments from the students, for example, one mentioned "EJB's are cool", which I completely agree. Another student noted that there isn't anything in Java EE that he cannot accomplish with Spring, which, while it may be true that the end result is the same, fails to take into account that the amount of work to get this end result tends to be a lot less with Java EE.

There were hands-on labs for the students to practice the concepts taught in class. I chose NetBeans as the IDE for the exercises, since it comes bundled out of the box with everything needed to build complete applications, such as a Java EE compliant application server (GlassFish), and a fully functional RDBMS (JavaDB). Not many of the students had previous NetBeans experience, however most of them were able to finish the exercises (which were simple, but complete Java EE applications) in about 30 minutes or so.

While discussing the hands-on labs, I provided some NetBeans tips, such as the ability to generate boilerplate code (Alt-Ins), generate JPA entities from an existing database, and the NetBeans JPQL editor, which provides code completion when developing JPQL queries.

All in all, a great experience. I don't get to teach as often as I'd like, it is a nice change of pace from my day to day job developing real-life Java EE applications.


« June 2014 »

© David R. Heffelfinger