Abstract Method

Eclipse This!

2009-12-22T14:07:00.008-06:00

We've got a saying at work: Open-source is a ghetto.

As much as I love open-source software, as much as I love the idea of open-source software, so much of it is just, well, crap. One of our most frustrating day-to-day ordeals is to work with Eclipse, a Java IDE (and then some) that is often considered to be a pinnacle of what open-source software can be.

Now take a look at the following screenshot (package names redacted for corporate anonymity):

Click to expand

Notice the Problems tab at the bottom. This lists the current problems with my code; until all the little red x's go away, things are bad and I really can't move forward. There is exactly one problem in the above example, with the oh-so-helpful description: "Syntax error on tokens, delete these tokens."

Normally, I'd be frustrated by such an ambiguous error message, but that's...ahem...eclipsed...ahem...by a bigger issue. You see, our helpful Problems tab indicates that the problem occurs on line twelve of the currently opened source file. Go ahead and find line twelve. I'll wait.

...8, 9, 10, 11...14!

That's right, lines twelve and thirteen of this file somehow don't exist. But until I delete some mysterious "token" on line twelve, my project is fubar'd.

Grrr.

Eclipse Galileo Re-Reflection

2009-06-24T11:51:00.002-05:00

A few gentlemen stopped by and posted a few comments in regards to my first Galileo posting. I'm really not sure how they made it out here to my little island, but I'd like to say welcome.

I'd also like to clarify a few things.

First off, I hope that the Eclipse Rich Ajax Platform (RAP) guys don't feel like I'm picking on them. My RAP examples are just that: examples. To those of you who stopped by and replied: thanks for taking criticism in stride; it is a mark of a true professional. Kudos.

I hoped that by contrasting the documentation of RAP and the Google Web Toolkit (GWT), I could highlight exactly one thing. Good documentation is the single best investment that a development team can make in usability. In fact, when I propose that my team choose between competing technologies, the choice has oftentimes come down to discoverability rather than technical merits.

If we choose a sparsely-documented technology, senior developers first take a crack at it, taking a week or three to dissect the technology and learn everything they can about it. They then take it to junior developers, teaching them hands-on. After that, implementation still takes a great deal of handholding by our senior people - people that, all things considered, have much better things to do with their time. Eventually, the team splits up into gurus and neophytes and only certain developers are willing to touch certain parts of the code base. Ultimately, the result is rarely clean and often buggy, requiring an extra iteration to clean up before going live.

A well-documented technology, in contrast, puts developers on a much more even level. Junior and senior developers can learn simultaneously. Code develops an extra sense of mobility as everyone feels confident with the entire code base, and the end result is a more cohesive, more robust product.

In short: good documentation allows developers to focus on solving an actual business problem.

Unfortunately, most open source projects I've used have been badly, badly documented. I understand that documentation is difficult and extremely un-sexy. I still can't stress enough that for me, as a user, the next major step forward for open-source - to promote usability, gain legitimacy and increase productivity - is to focus on documentation.

And for the record: I am more than happy to help contribute. Unfortunately, there's a bit of a catch-22: I can't document what I don't know, and I won't know until there is documentation. That said: if anyone ever feels that there is something that I can do to help, this is an open invitation to get in touch with me.

As for the systemic problem of community-wide documentation, I do have some ideas. I've already started writing that post and will publish as soon as I can.

Eclipse Galileo Reflection

2009-06-22T13:22:00.002-05:00

There is no shortage of bloggers extoling the virtues of Galileo. While the new release builds on the strengths of Ganymede and adds some welcome functionality, it doesn't address the core deficiencies. Namely: documenation, documentation and documentation. (Also: documentation.)

I like Eclipse. My team and I have been building applications with it for over a year, most notably using the Eclipse Rich Client Platform (RCP). I hope that I can make this criticism and also express that I mean no disrespect to those that have put so much time and effort into the release.

That said, without better documentation, most Eclipse projects are not usable.

We've just finished the first iteration of a project using the Google Web Toolkit (GWT) to build a rich web application. After reading blogs and looking through new features of the Galileo release, the Eclipse Rich Ajax Platform (RAP) caught my eye and I decided to investigate it as a possible alternative.

I got nowhere.

There are several interesting demos and screen captures, but none that can even get me started down the road to building a practical product. The getting started page barely gets past installation and while the Wiki does a decent job of explaining the overall architecture, I'm still at a loss for practical information.

Compare this to the documentation for GWT. There is a clean walkthrough for new users. They do a great job of explaining not only what the API does, but why they made certain design decisions. Moreover, they provide more than just an introduction; they provide tutorials that walk users through advanced topics including debugging and deployment.

I can't even find JavaDocs from the RAP site.

Eclipse is a powerful tool. It is necessarily complex - and I've often defended its complexity. But without good roadmaps, the learning curve becomes prohibitive. It took no less than three books and hours upon hours of searching wikis, forums, newsgroups and blogs to get through our first RCP application. It is a scenario that replays itself every time we try to use an Eclipse technology, be it RAP for web applications, Buckminster for builds or GEF for diagramming. Most of the time, we abandon the effort.

We just don't have the time or energy to keep going through that.

If Eclipse wants to be taken seriously - and it deserves to be taken seriously - it needs to focus not on building powerful features, but empowering developers to leverage the platform.

Not Yet, Young Grasshopper

2009-06-02T19:48:00.007-05:00

If you haven't yet heard about Bing, Microsoft's new search engine, you soon will. The software giant plans to spend around $100 million dollars to make sure you do.

So...is it any good?

As I've said before, I view the search engine as a professional tool, not a plaything. I search dozens of times each day to help dissect the convoluted world of software engineering.

I needed to find out about integrating two software libraries I'm using, Google's GWT and Guice. I'll be honest: I went to Google first and got exactly the results I needed. As an added experiment, I went to Bing and tried the same query.

The result? When I typed in, "gwt guice," Bing decided that I really meant to search for "get guide." Not sure how that one works. I'm really not a fan of software that thinks it knows what I want better than myself.

Needless to say, I'm sticking with Google.

Search and the Art of Celebrity Gossip

2009-04-06T08:00:00.010-05:00

Internet search is a huge business and those fighting for the market are giants. Google dominates, with Microsoft, Yahoo and other legacy players fighting for its leftovers. Rather than delve into the business analyst's world to justify Google's share, let's just take a look at their websites from a user interface perspective.

First, there's MSN.com:

I was going to search for something serious, but I think I'll read about that serial shrimp shoplifter instead

Let's see, the eye is first drawn to the main headlines scrolling by. In this screenshot, that's the "Is It Them...Or You? Why you haven't met The One." Then there's "Hot or not? 100 women vote on spring's freshest trends." There's also some giant ads, like that one for Bank of America. And, of course, below that there's MSN autos with a Hyundai ad placed in such a way that it isn't immediately recognizable as an ad. Their "Today's Picks" include news of a "serial shrimp shoplifter." And let's not miss that little gem at the bottom, "Best pet for you by zodiac sign!"

Oh yeah, there's also a search bar up at the top.

On to Yahoo.com:

Yes, I use Google Chrome. It doesn't make me (too) biased.

It's a pretty similar layout. The biggest element on the page is the ETrade ad on the right. It's also animated, which makes it rather obnoxious. The featured headline news starts with the "Most extreme golf hole," and also includes, "Worst dating mistakes that women make." Below that, mixed in with some serious world news is the video titled, "Surgeons save man who accidentally swallowed scissors," which feels just one step up from the myriad YouTube videos of people getting hit in the nuts. To top it all off, look near the bottom right for "Popular Celebrity Photos."

And finally: Google.com:

Surprise! This screenshot is smaller.

Yep, there's the search bar.

Also notice that there are no news, no dating tips and, most stunningly for the leader in web-based advertising, absolutely no ads.

That's is a huge difference from MSN and Yahoo. Google is a serious site meant for serious people. I can pull it up at work twenty times a day - which I do - and I feel like I'm using a professional tool.

MSN and Yahoo, on the other hand, have some serious issues with inane clutter. Not only do all those extra headlines draw focus away from what I really want do, but take a look at the content itself. Celebrity photos? Horoscope-friendly pets? These aren't professional tools, they're supermarket tabloids!

Perfect World Syndrome

2009-03-18T14:52:00.003-05:00

Nothing works.

I've been spending the day trying to figure out how to set up a basic continuous integration environment here at work. I want to be able to use what I consider a fairly standard workflow:

1. Check code into a central version control repository
2. Use a CI server to detect and pull updates
3. CI server runs a build
4. CI server runs tests against the build
5. CI server published test results

There's nothing groundbreaking here. In fact, I've been doing this quite some time using Maven, Hudson and Subversion. But now I need to use the Eclipse Plugin Development Environment since I am building an Eclipse Rich Client product. Shouldn't be hard, right?

Wrong.

You see, PDE does not play nice with Maven. They want to manage their dependencies differently. Maven has a nice dependency management feature that automatically finds artifacts and, transitively, the dependencies of those artifacts. PDE, however, expects that you have imported your dependencies as projects into your workspace. Not nice at all.

With Maven, it was easy to create, organize and run unit tests - simply stick them in the tests folder of your project, and the Maven build will find and execute them for you and create reports. You could even run additional analysis tools pretty easily. PDE? Create a Plugin Fragment project - a whole extra project! - and put your tests in there. Running them? No problem! Just right click on the test project and select Run As -> JUnit Test, and the JUnit view will pop up with the results!

Well, no problem - as long as you are doing everything The Eclipse Way, from within the IDE. From outside of it...well, time to start writing Ant scripts. But wait! In the IDE, dependencies are resolved by examining projects in the workspace. Once you are outside of the IDE, the concept of a workspace no longer applies. I haven't a clue how one would go about finding, retrieving and building those dependencies aside from a lot of tedious, fragile manual scripting.

So we're already stuck, and we have barely touched our continuous integration workflow.

Well, look over here! It seems that the Eclipse people have been working on a solution: Buckminster. It knowns how to find and fetch things ("materialization"), it can run PDE builds. Hey, maybe it can even run tests somehow...

So I've spent over seventy hours and I finally found how to make a simple build from inside the IDE. It took that long not because it is hard, but because it is so damned poorly documented. (The trick, see, is to use a property file to set the value of buckminster.output.root, otherwise it will just create nothing and fail silently.) So I start looking into the fancy dependency resolution aspects and maybe - just maybe - the headless build environment. I start getting hopeful!

And then I realize that Buckminster can pull code from Subversion and CVS version control systems, but not Mercurial. I'm stuck again.

We finally get to the crux of this post: there are now so many projects try to do the same little things that it is nigh on impossible to create a cohesive system to accomplish something of serious consequence.

How to Get a Job, Part IV: No No's

2008-12-16T13:00:00.006-06:00

A week into holding interviews, here are a few things I've had happen that pretty much disqualify you for the job:

1. Fail to read the job posting. The posting said that you need to be a US citizen right up there at the top. You're not a US citizen? I don't feel sorry that you just drove an hour to get here.

2. Fail to understand what an interview is. Don't send me an email half an hour before the interview asking me if it is a real interview or a phone interview, and then asking to reschedule since I actually want to meet you. I'll still meet this guy, but he just dropped down to the bottom of the pile.

3. Be nervous. I know understand this little bit of performance anxiety, but get over it. I like confident applicants that act like they've done this before; they tend to do better under pressure when they get the job. If you're afraid of me, just wait until the owner of the company tells you that he needs a miracle five minutes ago.

4. Dress unprofessionally. Seriously: go put on that suit. You've lost me when you show up in jeans.

5. Ask me how to make a resume. I came across someone and mentioned that I was hiring. Just so happens he was looking, so I gave him my email address and told him to send me his resume. His response? "I've never made a resume, what should I put on it?" Sorry - a professional knows how to do this, and I'm not going to babysit.

6. Send me a resume that I can't read. That's right, I actually got a resume with no file extension or other type information. And you want a position at a software company?

7. Show up blind. We put a lot of effort into our website. Take five minutes to find out a little bit about our company.

How to Get a Job, Part III: The Setup

2008-12-12T13:25:00.003-06:00

I freely admit that I'm a bastard.

Once I comb through the pile of resumes, I choose a few candidates that look the best / least worst and send out emails inviting the potential employees in for an interview.

I see every part of the interview process as a chance to glean just a little more information about candidates. When it comes down to it, most candidates have the same answers to formal questions, so I like to use bits that don't seem like formal questions. In this case, I give them the company name, but not an address.

A smart candidate will Google the company, find our address and write me back, "Is this the correct address?" A less promising candidate: "Send me your address." I like candidates that can find their own answers; I hate babysitting.

So much of IT is being able to answer questions for oneself.

How to Get a Job, Part II: The Submission

2008-12-12T10:09:00.003-06:00

I know this sounds absurd, but choosing how and where to submit your resume can make a really big difference.

But first, read this public service announcement: only apply to jobs that might actually be a good fit for you. Yes, I'm talking to you, the COBOL architect that applied to a Java position, and you, the manufacturing specialist that applied for a network administrator job. I'm also talking to all those woefully under-qualified individuals, along with those extremely overqualified individuals with no relevant experience on their (nine page) resumes.

These types of submissions are, in no uncertain terms, spam. You know how you hate getting 582 spam emails a month? You know how you complain about getting telemarketing calls during dinner every day from inconsiderate jerks? Yeah - you just did that to me.

</rant>

There may be plenty of reasons to apply for a position for which you may not seem entirely right. That's fine - but explain in your cover letter. You live in Burbank? Acknowledge the fact and tell me that you're willing to relocate. You don't list the Microsoft Exchange experience I specifically wanted? Tell me how you can overcome the shortcoming. I read cover letters. Usually, they make a bigger impact than the resume.

And while we're on the subject: don't send your cover letter as an attachment! Your email IS the cover letter. Furthermore, while it is generally unnecessary to tailor a resume for a specific position, it is absolutely necessary to do so for a cover letter. Don't give me generic BS about wanting to find a position that will use your skills and abilities.

And finally: format. Microsoft Word is pretty common, but there are several problems with it. For starters, not everyone has the software. Opening it in different versions or alternative programs (I'm looking at you, Open Office and Google Docs) can royally screw up the formatting. Also, it's possible to wind up with viruses from it. Send me a nice PDF. How to do this is left as an exercise for the individual.

If you can't Google a solution, don't bother applying - at least not to a software company.

How to Get a Job, Part I: The Resume

2008-12-11T23:50:00.003-06:00

AGHHH!!!

I spent most of my day reading resumes. This should never be an issue.

A resume should be a good, solid - and single! - page that gives the hiring manager a way to narrow down potential candidates to those that really fit the job.

A resume is not a novella. A resume is not your personal, epic saga from fry cook at McDonald's to senior architect at a Fortune 500. A resume is not a nine-page document of every single task you've completed in 20 years.

I have 30 seconds for your resume. Don't rush me - and above all, don't bore me.

Interview Questions

2008-09-22T16:15:00.003-05:00

I've recently had the opportunity to partake in interviews of four candidates for programming positions. On the last several, I've been the one responsible for determining the technical proficiency of the candidates. And since having a degree or experience seems to mean absolutely nothing in the software world, this is not as easy as it seems. I'd love code samples or a few weeks with each applicant, but as it turns out, the other prime requirement is that I find a way to determine technical aptitude quickly.

So here are my new three questions for interviewees:

1. Explain the difference between an interface and an abstract class

Goal: Determine proficiency with object oriented development

Bad Answer: Uhh...
OK Answer: An abstract class has partial implementation.
Great Answer: Delve into the difference between implementation inheritance and polymorphism.

Evaluation: If they can't answer, the candidate does not have a good OO background. If they also claim experience with OO development, the interview is over. If they get philosophical about inheritance and polymorphism, they will almost certainly get an offer letter.

2. Are you familiar with Dependency Injection or Inversion of Control patterns?

Goal: See how people will react when they don't know. Also, they might just know the answer, in which case: wahoo! I usually ask this question as a, "by the way..." when the candidate is approaching the white board for a coding question or some such.

Bad Answer: Pretending to know when clueless.
OK Answer: "I don't know."
Great Answer: It's a technique for limiting coupling whereby objects are given everything they need, rather than having to go out and find it themselves. Think of it as the anti- Service Locator.

Evaluation: This question hopes to achieve two goals: first, someone with real serious experience will have a pretty good clue what this is. If they are claiming to be a rock star programmer with six figure salary requirements, they damn well better know how to answer it. All told, though, this isn't something that is taught in schools and most junior programmers will be clueless. Watch how they answer for some insight into their ego.

3. The programming question. There are two I like depending on how the situation is progressing.

Goal: Does the candidate have a good basic understanding of OOP, and can he or she explain an idea?

3.A. Could you pseudo-code for me a class to represent a time?

Bad Answer: Using Strings for hours, minutes and seconds, using a platform Date/Time class, anything that doesn't make sense.
OK Answer: A class with fields for hours, minutes and seconds, and methods for getTime(), etc.
Great Answer: Keeping a single field that is, say, milliseconds from a reference point. This is how most platform libraries do it. It avoids problems with time zones, etc.

Evaluation: When asking, keep prodding. Does this implementation take into consideration time zones? How would it handle a Daylight Savings switch? You are evaluating not only OOP fundamentals, but also how well the candidate approaches the problem. Can they explain their thinking? Do they respond to criticism? Do they attack the problem, or are they afraid of it?

3.B. Could you pseudo-code for me a class to represent an address?

Make sure to keep prodding the candidate. Would this address work in Canada, where there aren't states? Would this work in Xxx, where zip codes are not numeric? How are you parsing countries? Would that work for, say, the city of Lebanon, Missouri?

OK, this is a trick question.

This was the interview question I received when interviewing for my current position, and the person giving it to me received it when interviewing at Microsoft. When I left the interview, I went home and told my friends that I was definitely not getting the job. The purpose of this question, even more than the previous one, isn't to get a correct answer - the question is, quite literally, impossible to get correct in the span of an interview - but to judge how the candidate approaches tough problems.

H'okay, so I lied - there are several others I like, but those are the main ones. But what am I really getting at? What am I looking for in a potential new developer? I'll try and get to those next time...