Saturday, 30 July 2011
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.
Saturday, 2 July 2011
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:
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.
Monday, 11 April 2011
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:
You can find it on this page in the mvnrepository site. The three big issues are:
- 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.
- 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.
- 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:
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.
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.
Sunday, 3 April 2011
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.
Monday, 28 March 2011
The three I've noticed all look promising and merit a bit of investigation. In order of importance (IMO):
- 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.
- 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.
- 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.
Saturday, 1 January 2011
With Xubuntu 10.10 I'm daring to believe that I might have a stable enough platform to be able to make a bigger commitment to Linux, certainly as a development desktop. I've been running it alongside Windows 7, using the Wubi installer. This is by far the best way to experiment with Linux: you get very close to the experience of a 'proper' installation (I don't think I have been able to detect the virtual disc performance hit) and you don't disturb Windows or the drive partitioning in any way.
I have two reasons for wanting to move on from a Wubi install:
1) Virtual drive size. I went with the default (17GB or so) and eventually this will probably be an issue.
2) You cannot use Remastersys on a Wubi installation. To use this handy utility, you need a real installation. I know this, because I trashed my first Wubi installation when I tried.
Apart from creating a complete backup of your installation, Remastersys can also do something else: generate a new master ISO image of your installed OS, containing all the configuration changes you have made, so you can walk up to another machine and just deploy it. That's worth having, because I don't want to have to go through the process of installing my stuff all over again (and waiting for the upgrades) and I will want to standardise the development desktop we use via a deployment image.
Happily, there is a way to move your Wubi Ubuntu to a separate partition, turning it into a full installation. This thread on the forum provides a really good step-by-step guide, complete with downloadable script. I plan to try this but only after I have made a drive image of my current Windows installation (because if I don't, then I know it will go badly wrong).
So what's left? What are the things I still cannot do on Linux? The final barriers to a complete switch? There aren't many:
- Some digital devices, notably my Sony Walkman, just don't have drivers or companion software. With the Walkman, the problem is Sony's truly dreadful SonicStage software. Much as I hate it, it's the only way to convert and sync stuff to the device. When I last looked, there were a few poor-quality tools which claim to work with the Walkman but when I tried them they messed-up the device's track database and filesystem. Not going that way again.
- My Vodafone USB wireless broadband device. There's a Windows driver for this, but no Linux software, as far as I know.
- VISIO. I do need a decent 2D drawing / diagramming tool. I have tried Dia, but I just don't like it and development appears to be stalled. In the past I have almost ignored OpenOffice Draw (because I have Visio), but I think Draw may be just good enough, if I make a bit of effort with it.
There are a few other minor things, but these are the three I would pick as most irritating. To fix (1), some might suggest I buy a different media player! Maybe, but this is really just an example of a more general issue which only the passing of time will solve: manufacturers and software publishers supporting deployment to non-Microsoft environments. And there's WINE of course: this does solve some problems, but unsurprisingly not everything runs under WINE (SonicStage, for example) and even the things which do run, look pretty awful.
Xubuntu (and I think the plain Ubuntu distro) also appears to have removed another barrier to adoption which I just could not work around before: poor font rendering. When you spend so much time reading, editing and writing on-screen text, fonts (and rendering) really matter. In the past, Linux font rendering was truly dreadful: inconsistent across applications, and never very good in any of them. That seems to be over. Java applications still leave something to be desired, but that's down to Java, not Linux.
Cautious optimism, then.