In the Spotlight - Joe Walker

I just had one of those times when I thought I totally lost the ability to do simple logic. Take a look at this screenshot:

I'll break it down: req.readyState = 4, and batch.async = false.

Last time I checked 4 = 4. So blatantly (4 != 4) is false. And false && false is blatantly uber false, as true as Alice Cooper covering Barbie Girl.

So seeing firebug step through if (false) and onto the return statement made about as much sense as trying to raise Schrodinger's cat in a séance.

I think it's another quirk in Firebug. This time it's simply something funky going on with "step over".

The moral is: Firebug sometimes lies to you about where the current line is.

This is all part of me adapting DWR so that it can be used as a connector between Jaxer and some Java server. More on that in a bit.

It was about 5 years between Netscape 4 and Mozilla 1.0. In that time, they lost about 80% market share.

It was about 5 years between IE6 and IE7. In that time, they lost about 10% market share.

Just in case there was any doubt about the argument that Netscape killed themselves, clearly there were other forces at work. It wasn't just down to a much criticized rewrite decision. Perhaps a better remedy than trying to get Microsoft broken up, would have been to insist on the default installation of an alternate browser.

Frank Zammetti, wrote this, and as I'd written bits of this, he asked me to write a forward, which goes something like this:

The funny thing about getting heavily involved in an open source project is the roller coaster ride you embark on. There's the buzz from seeing the hits to the web server and reading what people think of your project. There's the gnawing feeling of responsibility when you discover very large websites using your code, and you're worried about bugs you might have created. There's the total flat feeling when a friend tells you they're taking your code out of a project because they prefer an alternative; and there's the burnout when you just can't keep up with the volume of work, and realize that a huge percentage of what you do is not directly development related.

My experiences with open source have opened a huge number of doors. I've met people that I wouldn't have met otherwise and had job offers that I wouldn't have dreamed of before. There really is a magic buzz to open source.

Marc Andreeson, one of the minds behind Netscape and Ning, wrote recently about how to hire good developers. To paraphrase Marc: "Hire someone that has worked on open source software".

Some companies rate candidates using trick questions: they get the developers that are good at typing "interview questions" into Google.

Some companies rate candidates using industry certifications (MCSD, SCJD, etc): they get people that work at rich companies that depend on training not talent.

Some companies rate candidates using CVs/resumes: they end up hiring ?talent embroiderers?.

Some companies rate candidates using interviews: they get the people that sound good and look good.

Unsurprisingly, these selection techniques don?t get you the best candidates. So how do you find the developers that love writing good code, that get a buzz from solving the problem in a neat way, and that do take pride in their work?

The answer according to Marc, and according to my experience, is to hire people who love their work enough to get involved with a project that was optional.

So here's your invitation to get a leg up on getting a job with people that hire great developers?get into open source development. It doesn't have to be DWR, although we've love to have the extra help. Just pick something that excites you and get involved.

The problem with getting started is a typical crossing-the-chasm problem. The first few minutes are easy. You?ve used a project, liked it, and maybe joined the mailing list. You might even have found something you would like to work on. When you are involved in a project, you know what you are doing and can contribute. But there is a chasm between these places where you are learning the code, learning how the project does things, learning the process, and so on. While you are crossing the chasm, you are unproductive because you are in unfamiliar territory.

So here are a few hints about how to cross the chasm. First, find somewhere that the chasm isn?t too wide ? start by fixing something small. The chance of any IT project failing is inversely proportional to the size of the project. Start with a simple feature that makes something better. Almost all IT projects have these in abundance.

Second, don?t think that because it?s tricky, you must be stupid, or the project must be misguided. There are always reasons why things are tricky. The answer could be historic: when the code was written, people didn?t expect the code to be used in this way. Or maybe there is some refactoring that needs doing that hasn?t been completed. DWR?s code is fairly good because the code is young and we?re fanatical about re-factoring, but some projects have more history to them.

The difference between those that can cross the chasm and those that can?t is - drive. You don?t need to be a genius, to have a brilliant CV, or to look good at an interview. Even the ability to type ?interview questions? into Google is optional. The people that can cross the chasm are those with the drive to succeed.

Getting involved can come in many forms, and sometimes it's even sort of tangential to the project itself, such as writing a book about the project. Sometimes the tangential help is some of the most valuable. The things developers leave out are often things they are bad at. For years I?ve wanted there to be a DWR book, but known I?m the wrong person to write it, so I?m particularly pleased to see Frank step forward to write the first DWR book. Thanks for having the drive to get involved, Frank.

Practical DWR 2 Projects by Frank Zammetti is out today - officially on the 30 Jan. You can order it from Amazon and many other good bookstores.

So DWR is now part of the Dojo Foundation. I thought it would be good to quickly summarize where we are, and what I'm working on, and to give everyone a chance to comment.

DWR 2.0 has been out for 6 months or so. At the time, I swore that the next release would be a small one, called 2.1. However it appears that I?m not good at swearing because there is lots in the next release - I think we?re going to have to call it 3.0.

Just as a quick recap, here?s what changed with 2.0:

• Reverse Ajax which I define as Comet or Polling or Piggyback, whichever works best.
• Spring Namespace support, Guice support, Annotations etc.
• etc. Every release needs some etc. See the release notes for more.

Since 2.0, we've been working on the following adding support for JSON, Bayeux, images/binary file upload/download, a Hub with JMS/OAA support and more reverse ajax APIs. I also want to get some Gears integration going.

There are also a whole set of non-functional things to consider:

• Moving the website to directwebremoting.org
• Restart chasing CLAs, using a foundation CLA rather than a Getahead CLA
• Get some lawyer to create a CLA so Getahead can grant rights to the Foundation (or something similar)
• Get someone to pony up and let us move to SVN
• Unit tests

DWR Hub and integration with JMS and OpenAjax Hub: We have a hub, along with one way integration with JMS. The OpenAjax portion will be simple except for the getting the OpenAjax Hub to work smoothly with JMS part.

Reverse Ajax Proxy API Generator: The goal with this is a program that will take JavaScript as input, and output a Java API which, when called, generates JavaScript to send to a browser. Some of this work has been tricky, but then meta-meta-programming was always bound to be hard. This currently mostly works with TIBCO GI, but more work will be needed to allow it to extract type information from other APIs. You can see an example of how this is beginning to evolve in yesterday's article at The Server Side. I hope we will be able to create some Dojo integration for 3.0 too.

JSON support: One goal is a RESTian API so you can do something like this: http://example.com/dwr/json/ClassName/methodName/param1/param2 and DWR will reply with a JSON structure containing the result of calling className.methodName("param1", "param2"); It would be good to support JSONP along with this. We might also allow POSTing of JSON structures, although I?m less convinced about this because it quickly gets DWR specific, and then what?s the point of a standard. Status - DWR has always used a superset of JSON that I like to call JavaScript. We do this to cope with recursive data, XML objects, and such like. I?ve done most of the work so that DWR can use the JSON subset, but not created the ?handler? to interface between the web and a JSON data structure.

Bayeux Support: Greg Wilkins (Jetty) committed some changes to DWR, which need some tweaks to get working properly. Greg still intends to complete this.

File/Image Upload and Download: This allows a Java method to return an AWT BufferedImage and have that image turn up in the page, or to take or return an InputStream and have that populated from a file upload or offered as a file download. I?ve had some bug reports that it doesn?t work with some browsers, also we need to find a way to report progress to a web page simply. See this post on Ajaxian for more.

DOM Manipulation Library: Currently this is limited to window.alert, mostly because I?m not sure how far to take it. There are a set of things like history, location, close, confirm that could be useful from a server, and that are not typically abstracted by libraries.

Gears Integration: I?ve not started this, but it needs to take higher priority than it currently does. It would be very cool if DWR would transparently detect Gears, and then allow some form of guaranteed delivery including resending of messages if the network disappears for a while.

Website: We need to get the DWR website moved away from the Getahead server, and onto Foundation servers. There will be some URLs to alter as part of this, and I don?t want to lose Google juice by doing it badly. The documentation for DWR 2 was not up to the standards of 1.x, and while it has been getting better, we could still do more. One thing that has held this back has been lack of a DWR wiki. I hope we can fix this with the server move.

Source Repo: We are currently using CVS hosted by java.net. They support SVN, but want to charge us a few hundred dollars to upgrade. I expect to move away from collab.net/java.net CVS some time early next year.

Unit Tests: I've been trying for ages to find a way to automatically test with multiple browsers and servers. WebDriver looked good for a while, but it doesn't look like the project is going anywhere particularly quickly, so I'm back trying to get Selenium to act in a sane way.

Etc: There's always 'other stuff'. I've particularly not gone into things like Grizzly support. There's plenty of etc in this release too.

Alex:

To get a better future, not only do we need a return to ?the browser wars?, we need to applaud and use the hell out of ?non-standard? features until such time as there?s a standard to cover equivalent functionality. Non-standard features are the future, and suggesting that they are somehow ?bad? is to work against your own self-interest.

Ten years ago, in 1997, some people spent ages getting DHTML pages working across IE and Netscape, and when we were done we felt dirty and bruised. Some of us crawled back into our caves resolving that stabbing ones-self repeatedly with a sharp object was more preferable.

However, some people saw it as an opportunity.

In 2007, the people that saw it as an opportunity have created Dojo, YUI, JQuery etc. So this time around we're ready for them, and it doesn't have to hurt. This time around it's a matter of waiting for Alex, John etc to have taken all the pain and revved the frameworks.