Maven Resource-Filtering Escapes Backslashes

Having moved up to Maven Resources Plugin 2.3 in order to stop Maven from attempting to filter some binary files for us, and in so doing, destroying them, we've discovered that 2.3 has its own problem -- it escapes backslashes and colons in files where escaping is totally unwarranted, which does a surprisingly good job of destroying an XML file we need for Selenium and Java Web Start to play nicely together (a mimetypes.rdf that tells Firefox how to deal with a JNLP file).

Three cheers for Maven, an ecosystem of tiny plugins, each of which has its own set of bugs and idiosyncrasies, which collaborate to ensure that there's no valid way to build your project.  Whee.

Are We Ready for Bespin?

It's interesting to finally see what's going on in Mozilla Labs around Bespin.  It's an interesting idea, making a web-based development environment.  It's been tried before, but I'm curious to see it develop and see how far they can take it.  

What they have already seems promising, but it's a long way from replacing a desktop application for me at this stage.  Still, with enough persistence and enough time, there are undoubtedly some things a web-based application could do that would be difficult for a desktop application to mimic.  We'll see what happens.

I'm not sure developers are ready to move their development environment into a browser.  More specifically, I'm not sure that it will be possible to create a compelling, seamless enough web development environment.  But if it can be done, these are some of the people I'd like to see working on it, so I'll keep my fingers crossed and keep my eye on Bespin as it evolves.

Metro Toronto Fires All breast Writers

Well, last night I read (twitter, Globe and Mail) that Metro Toronto had fired all its staff writers and was going to be using unpaid interns.

This morning, reading a review of Friday the 13th, I found this paragraph, emphasis mine:

There's no mistaking Friday's intentions -- this is definitely for Jason Voorhees fans.  Not only does it overlap the thirteen killings (very clever!) that occur over the film's 97 minutes, but they're ultimately underwhelming.  breasts.  In fact, with very little suspense to speak of, Friday the 13th isn't scary at all ... unless of course, you're a film critic.

I'm wondering -- is this what happens when unpaid interns write your copy, or is an act of vengance in the last words penned by a departing writer?

Productivity and Pair Programming

I'm with Raganwald on the productivity issue. I don't feel like I can measure my own productivity or that of other developers, and I don't think anyone's made a really conclusive argument either direction about the productivity of pair programming, although I will say that there are times when I've found it very useful and times when I've found it a little irritating.

And, frankly, I think a good chunk of productivity studies are bunk anyway. The idea that we can measure and suggest that we're 36% more productive than people X years ago seems to be making claims about precision that aren't supported by any kind of useful data.

But what I will say is that despite the lack of a good productivity measure, I suspect that both a single developer and a developer-pair are more productive than any group of developers who are arguing about productivity instead of writing code.

On that note, I think I'll go write some code.

Bean Validation Public Draft

Sounds like Bean Validation has been voted through the public draft stage. I've just finally managed to get my voluminous feedback into the appropriate hibernate forum after wading through the spec.

Mostly, it looks reasonable, although I'd prefer to skip the bootstrapping entirely, or alter it pretty significantly so that it doesn't remind me of Why I Hate Frameworks.

I'm also not sold that we really NEED a JSR for this until there are multiple competing and incompatible implementations that take on validation seriously, which isn't currently true, IMO. Although I've used Hibernate Validator before, I'm not sure one implementation justifies a JSR.

But anyway.

Releasing Multi-Module Maven Projects

When you're doing a release using the Maven release plugin, Maven likes to ask you what version you'd like to release and what the version should be after the release.  For final releases, the defaults are often sensible, and you can accept them by turning on batch mode.  For interim releases, they usually aren't.

When you're doing this with a single project or a project with a very small number of modules, answering those questions for each module isn't such a big deal.  When you're working with a project with a larger number of modules, this gets very tedious very quickly.  The batch mode example  suggests that you can pre-specify the release version for each module, but it fails to highlight the property that a friend of mine just pointed out: autoVersionSubmodules.  That'll save me a lot of pain in the future.

Google App Engine Roadmap

The Google AppEngine roadmap shows a lot of promise; it'll significantly increase the sophistication of the applications that can be delivered using AppEngine. It's still true that it's hard to justify building a real application in an environment you don't control and can't easily duplicate, but it's nice to see solution gaining maturity.

If Google offered an open-source production environment -- not necessarily anything on Google's scale, but something that someone could deploy to at least a single server, or possibly a cluster of their own, of reasonable production quality, that would reduce the lock-in to the point that someone could conceive of building their own applications on AppEngine.

Eclipse 3.5 M4: Never Join Lines

As of Eclipse 3.5 M4, the formatter has an option to "Never Join Lines" or preserve user line breaks.

Finally.

I've gotta say, that's been one of my most consistent irritations with the Eclipse formatter ever since I started using the damn thing, something that IntelliJ IDEA did farther back than I can remember. I'm really looking forward to that.

While I'm on the subject:

• Eclipse 3.5 M5
• The ability to quickly paste a site in to install rather than having to manage your sites seems like a good addition, in keeping with how people actually want to use the system.
• SWT/Cocoa leaving experimental stage, that's good news for Apple fans.
  
• Eclipse 3.5 M4
• Preserving line breaks.
  
• Eclipse 3.5 M3
• The equals/hashcode compiler warning seems like a good idea.
• The extension point for clean-ups seems like something that could result in some useful additions given time.
  
• Eclipse 3.5.M2
• Eclipse 3.5.M1
• Support for ${inheritDoc} in the Javadoc view is great.
  
• Comparing word documents is the sort of feature I hope I don't need to use, but will probably end up using at some point anyway.
• A warning for comparing identical expressions seems valuable.

All in all, there's nothing here that seems critical, but lots of useful polish, and the formatter one alone is enough to warrant the ugprade. I'll have to take a look at the larger release train as well to see what else is coming.

That said, I have to say, I'm disappointed with 3.4 release -- I've had more problems with it than with previous versions, it feels like the quality's dropped off a little.

Apple should ...

Many people who try to give Apple advice seem to ignore that which has made Apple strong. For instance, when The Apple Blog suggests:

To make big strides in the mobile handset market, Apple should aim for the Pearl and Curve market space, either by introducing a simplified, lower-cost iPhone Nano, or by releasing a brand new iPhone model, but keeping the 3G around at a discounted price.

They should do nothing of the sort. RIM introduced the Pearl and the Curve basically because they'd failed to appeal sufficiently to the consumer market, because they had failed to put a great camera and good media support into the blackberries. In essence, they admitted that they were unable or unwilling to put together a single device to meet the needs of both markets.

Apple shouldn't do that, for more than one reason. First of all, model proliferation is where madness lies, particularly for application development. If you have to write an iPhone app and you're going to constantly ask yourself, "What's the resolution? Does this model have a camera?", the experience is significantly more complicated, and that comes out in your application design and choices.

Secondly, Apple is known for its design and its simplicity -- at this point, I don't think Apple needs to admit another model is necessary. At best, something like an iPhone nano, as suggested in the pre-macworld coverage: the same basic device in a smaller package. But, frankly, I think they should focus on building the best damn one model they can for several years to come yet.