Craig Pardey

Recruiting is difficult. Most of the top talent already have jobs and are rarely in the job market. As a recruiter (or a headhunter, or a talent scout) these are precisely the people that you should be trying to attract.

There are a few simple guidelines that might help you generate genuine interest in the role you’re trying to fill.

1. Try to build relationships with candidates, not just a contact database. I need to know that you are someone I can work with and can be trusted to be discrete. Let’s have lunch together.
2. Proof-read your email.
3. Give me a detailed description of the role including the actual company name and location. Leave out the technology buzzwords - truly great developers can operate effectively in any landscape
4. Do not ask me to send you “an updated copy of your resume in MS Word format”. I don’t know who you are or what you’re going to do with it; what happens if you unknowingly send my resume to my current employer?
5. Be discrete. Don’t call me on my work phone. When you call my cell phone always ask first if it is OK to talk and listen to my answer. If I say no then just say, “OK, let’s talk later” and hang up.

Following these simple rules will dramatically increase the quality of your candidates and get a higher response rate to your communications. Who knows, you might even make more money because you’ll be able to consistently deliver the candidates that nobody else can find.

After a decade of abuse I’ve decided to ditch my Bell landline in favour of VOIP.

My last Bell bill was $60.26 for a basic phone with 2 features.

I did a lot of research into the various providers in Canada. My short list of potentials was

• Vonage - the biggest player
• voip.ms - the cheapest player
• AcroVoice
• Cogeco

In the end I went for AcroVoice because they seem to have the best mix of service, simplicity and professionalism. Their basic service is only $10.95/month and they provide pre-configured hardware at a reasonable cost.

When I first started working at Intelliware I was amazed at how efficient the developers were while working in Eclipse. Most of this efficiency and speed came from a deep knowledge of Eclipse’s keyboard shortcuts.

Here is my list of Eclipse keyboard shortcuts that every developer should know.

1. Ctrl-Shift-L: Show list of shortcuts
2. Ctrl-K: Find next
3. Ctrl-Shift-R: Open a file in your workspace. It supports CamelCase shorthand too, so “SBFil” will find “SomeBigFile.java” and “SBFile.java”
4. Ctrl-Shift-G: Find references for a class or method. Want to find who calls MyClass.getName()? Put your cursor on the getName() definition and hit Ctrl-Shift-G
5. F3: Drill into a method. This will jump from the code that calls the method into the method definition. Similar to holding Ctrl and clicking on the method call.
6. Ctrl-T: Open implementors of an interface. Very useful when using F3 to follow the flow of method calls.
7. Ctrl-O: Open a list of method declarations in the current class. Allows you to jump directly to the method using the arrow keys and enter. Bonus points: typing Ctrl-O again while the list is showing will also list method declarations from all superclasses
8. Ctrl-E: Shows a list that allows you to switch between open files
9. Alt-Shift-W: Locates the current file in the Navigation or Package Explorer tree.
10. Ctrl-L: Go to line number. You might want to show line numbers by default by changing the preference General>Editors>Text Editors
11. Ctrl-H: Find a string in all files. You can customize this to only show the File search by clicking the Customize button and unchecking the other options
12. Ctrl-Shift-O: Organize import statements. This also removes any unused imports.
13. Ctrl-Shift-F: Reformat the file

You should also familiarize yourself with the following debugging shortcuts

I was recently tasked with setting up some load tests for our Tapestry (4.1.6) web application. I chose to use Apache JMeter because it is open-source and is flexible enough to do what we needed, and doesn’t cost $12,000/month like some load testing tools.

I set up an HTTP Proxy Manager to record a simple navigation through the site and reconfigured my browser to use the proxy. The proxy recorded the requests without a hitch.

There has been a lot of talk lately that Java is on its way out, mostly fueled by Apple deprecatingJava, and by Apache threateningto quit Java.

I’m not crying Chicken Little just yet, but perhaps it’s time to start looking for the Next Big Thing.  There are certainly a lot of contenders out there: Ruby (and Rails), Scala, Groovy (and Grails).  My guess is there’ll be a couple of false starts before a clear winner is declared.

A few months ago I bought an HTC Desire from Telus. While I loved the phone, it had problems from the beginning. The keyboard would regularly freeze mid- email/sms and the only way to revive the device was to pull out the battery and restart the phone.

It would often reboot when an incoming call was ringing. This is a major failure for a phone - at the very least it should be able to accept phone calls.

I recently started working on a personal project - a web application - and faced a difficult decision. What technology stack do I use?

I like my personal projects to both fulfil a requirement and to teach me something in the process. Java is my native language, so I initially thought I’d build it in wicket-spring-hibernate.

The problem is that I can only work on the project for a few hours a week, and I find that developing in Java just takes too long. It’s a big hammer.

I wanted to learn how to build mobile apps, so last weekend I bought Building iPhone Apps with HTML, CSS, and JavaScript: Making App Store Apps Without Objective-C or Cocoa. I don’t have any problem learning a new language, in fact I really enjoy it, but I was reluctant to to pay serious dollars for a Mac just to learn the skill.

The book covers how to build a website that is tailored for the iPhone. It looks and behaves like an iPhone app, but is actually a website. After a few chapters I started to feel dirty. It documented hack after workaround after hack.

This week I encountered an interesting issue in Tapestry when I tried to dynamically load a component using Tapestry’s built-in EventListener functionality. The component in question had a .script file associated with it, which Tapestry loaded dynamically, but the JavaScript functions in the .script file were “not found” when I tried to execute them.

After a bit of digging around, a colleague of mine noticed that Tapestry was loading the .script file using an eval() statement instead of inserting the script into the DOM.

I had a problem recently where Eclipse couldn’t find my source files when remote debugging a particular application. It would stop and the breakpoint and show the class file with a “attach source” button, but pointing it to the source directory didn’t do anything.

It turns out that the solution was to add the project to the remote debug configuration.

This is done by “Run -> Debug configurations…”
Choose the remote config from the tree on the left
Click on the “Source” tab
Click on the “Add…” button
Follow the wizard.