BMW R100S - 'Peach'

After a fair amount of searching / thinking / indecision, I believe I've found the right bike (motorcycle) so took the plunge and I've handed over the money.

'Peach' is a 1978 BMW R100S who needs a little work and a bit of TLC to bring her back to prime condition. Here's a camera-phone picture:

The previous owner is moving back to the US and wanted her to go to a good home - so that's what I will try to provide.

The panniers (Siebenrock, you can see one in the foreground) are tardis-like: you really can get a lot of stuff in there.

There's almost a year's MoT but no tax (fair enough as the owner won't be here much longer) and I will need to attend to a few practical things before riding long distances, but most of the remaining work is cosmetic. The R100S should have a bikini-fairing - this link is to a picture showing what Peach should really look like, but I'm not too concerned about that. At some stage I'll probably find and fit one.

I've never owned a BMW but always been attracted to these bikes: there is something very appealing about the simplicity of the engine, the feeling that you really do stand a chance of being able to do most maintenance yourself, and of course the overall build quality.  The owner included the Clymer manual, toolset, complete set of spare bulbs and some other bits and pieces so I reckon this was a great find.

The owner is a great character and we spent quite a while just talking and drinking tea. The bike has a nice back-story, plus his parents owned BMWs too and there are tales of how they got on their 1965 R-50 (a wedding gift) after changing out of their marriage clothes into denim, and headed across America from NYC to California. Their children subsequently 'grew up' on the back of that one.

I really enjoyed meeting and talking to Walter - I'm sure we will stay in touch and he'll get to hear about my adventures with 'his' bike.

Test Post (gist)

This is simply a test to see whether github's gist facility works acceptably as a way to quote source-code fragments in a post.

The following is a snippet of Groovy code which should appear as a gist:


This text should appear immediately below the code snippet.  If this experiment works then I will very likely return to using Blogger - the alternatives are just too much fiddle (Posterous, Tumblr) or much more baroque and complex than I need (Wordpress.com).  I want to get back to writing and micro-blogging properly: the first job is to pick the right platform and commit to it.

NetBeans IDE 7 Cookbook

There's another NetBeans IDE book out from Packt Publishing. This one is called  the NetBeans IDE 7 Cookbook and they will be giving me a review copy, so I'll post my impressions of the complete book some time in the next couple of weeks.

Meantime, I have been sent one chapter in advance,  Chapter 7 -EJB Application, which I am permitted to share via the link. You can read and download this chapter for free, too.

First impressions are not good, if this chapter is representative of the quality of the whole book. First, the numerous typos are distracting: average proof-reading would have found most of these so I wonder whether there is enough quality assurance applied, pre-publication. I haven't the patience to list them all. The quality of the writing is also not particularly high, though I'm always prepared to make allowance for non-native English writers/speakers and I believe the author is Brazilian. Not all the clickable links in the PDF have been checked either: the first one I decided to click, at the top of page 160, leads to the 404 page on Oracle's site.

However, my main criticism of this chapter is to do with its content. This is supposed to be a 'cookbook' and in the context of computing books 'cookbook' usually means a compilation of 'recipes' (concise instructions) for solving real-world problems using a specific programming language or tool. Well... I suppose the sample chapter does tell you how to use the EJB functionality in NetBeans 7, so in a very shallow sense I suppose this could be regarded as a 'recipe', but the chapter text does little more than walk you through the IDE wizards. Cookbook recipes are usually focussed on something more substantial. The pasting-in of the source code generated by the NetBeans wizards isn't all that helpful either - if you're running the IDE, you'll have the code in front of you anyway. Lastly, as this is Chapter 7 of a book dedicated to NetBeans and Java EE, why does the text redundantly repeat instructions on downloading NetBeans and ensuring GlassFish is installed?

If you don't know anything about Java EE, this book won't help you much. If you do know EJB / Java EE then you probably won't have much trouble working out how to drive NetBeans to create (e.g.) a stateless bean, so I'm not sure who the target audience is.

But this is just one chapter: I will review the rest of the book when I receive it.

Cloud Storage and Security

Very disappointed to read about the latest DropBox security issue.  Disappointed in two quite distinct ways: first because their account of this issue suggests a somewhat careless attitude to both security and regression testing, and second, the fact that the first I heard of this was when I read this Register piece. Not good enough. The world is scrutinizing cloud applications quite closely and I fear DB hasn't been paying attention.

Leaving aside the insecure nature of the DropBox service itself and it's apparently relaxed attitude to regression testing, there is the issue of service management and customer relations. As many others have pointed out, directly informing all users, as soon as reasonably possible, is a pre-requisite for establishing trust. Just compare DB's behaviour with that of LastPass. As soon as LastPass detected a possible breach, they immediately informed their users and took sensible action. Impressive, and reassuring.

I've been a SpiderOak user for a while, but until now I hadn't considered using their Sync feature, as I've been using DB instead. This incident has been just the trigger necessary to make me move my stuff out of DB and into SpiderOak, and I will be trying their Sync service now. By the way, I have no affiliation with SpiderOak whatsoever. I use their service principally for these reasons:

1. Zero-knowledge privacy 
2. Their attitude to engineering
3. Their prices. (Better than DB)

Another comparison article can be found here.

Superficially, DropBox is a lovely product but as you start to rely more on cloud storage you begin to think of all the ways your content might be compromised or misused and SpiderOak's robust, credible approach completely trumps any pretty UI.

GMaven Archetype – minor fixes

I became so irritated by the bugs in the GMaven archetype that I decided to do something about it.  There is a link somewhere below to a BitBucket project containing my fixed-up version of 1.4.  The rest of this piece describes what got me so annoyed and what I did about it.

To see the problems, create a new Maven project using the archetype “GMaven Archetypes :: Basic”, the latest version being, as far as I can tell,1.3.  The Maven coordinates are:

GroupId: org.codehaus.gmaven.archetypes
ArtifactId: gmaven-archetype-basic
Version: 1.3

You can find it on this page in the mvnrepository site. The three big issues are:

1. Project coordinates entered by user are not used in the generated project.  The generated project’s coordinates are just copies of the archetype’s coordinates.
2. Generated stub source-files have syntax errors.  Once you have generated the project, look at the source files in GroovyTestPackages.  e.g. HelperTest.groovy. The package declaration appears after the import statements and the import statements need to qualify the classes fully.
3. GMaven depends on a rather old version of Groovy (1.6.9) and the GMaven runtime (1.6-1.3, which I think means v1.3 of the runtime built against Groovy 1.6).

These problems have been picked up by other folk – I eventually discovered that issues have already been raised in Codehaus JIRA for these. See:

• http://jira.codehaus.org/browse/GMAVEN-86
• http://jira.codehaus.org/browse/GMAVEN-81
• http://jira.codehaus.org/browse/GMAVEN-73

This project attempts to fix these, plus updates some dependencies to bring the generated project up to date, notably the Groovy runtime (to 1.7.10) and JUnit (to 4.7).  These are small changes, but make the archetype much more convenient to use.

Currently, the fixed version of 1.4-SNAPSHOT is distinguished only by the archetype description – look for “(fixed)” in the description text.  If I’ve made these changes correctly then I’ll contribute to the next official release.  (Not sure exactly how I submit them for approval).

If you’re using NetBeans (if you’re not, then I do recommend you give it a try), the first-class Maven support extends to creating new projects from Maven archetypes. Below is how the fixed archetype will appear, once imported into your local repository:

In the next stage of project creation, NetBeans will prompt you for the Maven coordinates for your new artifact, and also for a project name, which is an ‘additional property’ shown at the bottom of the dialog:

In the fixed archetype, all of these properties are correctly processed. The resulting NetBeans project will carry the name assigned in the additional property and use the coordinates you assign here. 

Update: there is another important change to the prototype POM (src\main\filtered-resources\archetype-resources\pom.xml) which I missed in the original posting.  In order to use a newer version of Groovy, it’s necessary to exclude the older version from the gmaven-runtime dependency in the gmaven-plugin, and include a dependency on the version of Groovy used in the rest of the POM.

The code is available from the gmaven-archetype-basic project in my BitBucket repository. You can download a zip from there or pull from the Mercurial repository:

hg clone https://rsearjeant@bitbucket.org/rsearjeant/gmaven-archetype-basic

I hope this is some help to others. I’m keen to hear whether the small changes I made are fully correct and consistent as I’m still relatively new to Maven. If the changes are OK then I’d be happy to push / checkin to Codehaus.

Technorati Tags: groovy,maven,gmaven,netbeans

HAPI v1.1 released

Just relaying this announcement from James Agnew:

HAPI 1.1 is now out!

This release features a few new features, and a number of bug fixes, including contributions from a number of people around the world.

This release is available on Sourceforge, and thanks to Francis De Brabandere it's available in the Maven Central Repo too, meaning that you no longer need to add the HAPI repo to your pom.xml file if you are a Maven user.

It's really good to see HAPI is such a healthy state, and good to see the release going straight into Maven Central.

Thanks to James and other contributors for making this happen.

JVM Language Futures - Groovy++, Mirah, Gosu ...

Interesting times, with so much happening in the JVM language space.  It's amusing, too, to see static typing making a comeback via some of the very same projects which helped to champion the cause of dynamic languages and duck-typing.

The three I've noticed all look promising and merit a bit of investigation.  In order of importance (IMO):

1. Mirah.  From Charles Nutter, who created JRuby, so this one has probably the best pedigree.  I don't much like Ruby syntax, but I absolutely agree with the guiding principles.
2. Groovy++.  I really like Groovy (and Grails). The Groovy++ project goals overlap to a degree with Mirah, mostly in terms of static typing and achieving native Java runtime performance.
3. Gosu. This one is interesting because it was created by a company team to meet their particular needs and not primarily to invent a new language.

These three languages have quite different starting points but appear to share broadly similar goals. Essentially, they are trying to obtain as many of the benefits of a dynamic language as possible (leaner code, less ceremony) while at the same time carrying as few of the disadvantages as possible (no types = poor tool support, dynamic method dispatch = relatively slow). That's a difficult sweet-spot to hit.

Although I ranked these three in terms of importance, I actually think Groovy++ may have the best chance of getting into production code first because it's more mature than Mirah and has the great benefit of being an extension to something which already exists and is successful and established.  I'd love to see Groovy++ adopted officially and absorbed into the main Groovy roadmap.  Being able to add static typing just where you want (and leaving it out where you don't), getting traits into the language and getting better runtime performance are surely strong arguments in favour.