More information here.

Related posts:

1. Bean-Fields plugin 0.6 released

You know, little things. My complaint was very much supportive of the banks ideals and its original market-leading position on online banking.

Anyway the response has finally come. To paraphrase:

• They say they have improved resourcing in the Foreign Services department (for business)
• They apologised for the mistake with my international payment and gave me £50. OK, but this doesn’t cover the time spent dealing with their antiquated systems.
• On the requirement for obsolete fax machines for international payments: “We currently action foreign transfers from written instructions to ensure there is no misinterpretation of the customer request”. This is laughably inconsistent! The whole problem with my international payment (which was faxed) was exactly this – a misinterpretation. Furthermore they go on to state that if you use their premium “Financial Director” online app, you can make international payments without a fax.
• They say the new business online banking, which is being very positively received they say (compared to existing, any site that worked every day would be well received) will be fully rolled out to all customers by August/Sept (I was griping they said Q2 2010 in response to Radio 4 Money Box).
• The security token for the new business banking is a PIN-driven code generator that “fits on a keyring” (i.e. easily stolen) and does not require a card, unlike the one used for personal banking. It will be used for logging in, and also for “some operations” like creating a new beneficiary.
• They rejected my criticism of the telephone banking as inherently insecure because “this is normal within the industry”. This was in reference to the false sense of security created by the need for pin generators etc. They seem confused here and have misunderstood the point that the full account number, sort code and full 4-digit PIN must be given over the phone to access their automated service. Add another handset to someone’s phone line, use your mobile to record the eavesdropped DTMF tones and you’re away.
• Finally, they assure me that they are investing in an “innovative new banking system” for personal banking. No specific timescales, but “the Bank is committed to this development”.

Let’s not hold our breath. New business banking has been in development for years, only just rolling out. Timescales given out for it last year, still not met revised dates.

Related posts:

1. Co-op Business Banking – new system looks bad already
2. Co-op Business Banking errors again

A quick summary after 2 days intermittent use.

• It is a little too heavy at first. I suspect my arms will get used to it, or I will learn to hold it the right way – we never thought people would write essays with their thumbs on mobile phones. This is no doubt related to battery weight. I’d rather have the battery life – but a few 100g less would stop this being something people mention. Hardback books are heavy.
• The photos app is an instant winner. All they need now is selection of which you want to order prints for and ordering prints direct from iPad using iTunes account. Oh, and they do need wireless smart syncing of photos from MobileMe, Flickr etc. So you can publish from your other Mac/PCs and the ipad syncs them over the wire in the background.
• Typing is much much better than I thought it would be. With practice I can be as fast or faster than on a regular Apple keyboard I’m sure. I just need to get used to the slightly differently layout and tactile differences. So much so I could consider writing code on it. There are already some HTML editors for iPad.
• It would be really nice to set an App to be used as the lock screen, not a wallpaper. Eg set Weather HD or Guardian Eyewitness, Calendar month view, or the built in picture frame app – to come up when you press the lock button.
• I actually like some of the iPhone apps at 2x zoom. Most iPad native apps seem to be taking the fonts a little too small, and losing the benefits of larger font clarity / greater distance from the eyes that iPad screen should be affording you.
• Some apps definitely need further optimisation. E.g. Omnigraffle is not a bad first stab but there is no justification I can see for the UI being so laggy when dragging a single rectangle around the screen on a trivial diagram. Calculating the guides cannot be that intensive! Art authority is nice but the image quality of the marble UI backgrounds is really nasty, and the UI is rather sluggish with no indication it is busy at times.
• A little gripping surface around the edges would make you less scared when carrying it without a case. The front surface is very slippery, the back isn’t.
• I find it hard to find apps in home screen – they are too far apart and with an image background, it is hard for icons to stand out visually – I often have to resort to using search to find apps! This is reason enough to not have the option to set custom wallpaper… or at least it should be default reduce the intensity of wallpapers by 50%
• I miss the magazine rack metaphor from NewsRack for iPad. Seems much better fit for iPad than iPhone, I hope it comes back
• The lameness of many apps is more obvious on iPad than on iPhone. You’re more happy to “make do” on iPhone but the bar is being set higher on iPad by very good UIs e.g. Penultimate, Elements, Weather HD, Virtuoso HD piano. Omnigraffle is a good first stab but feels too awkward still.
• iBooks better become like iPod app and allow third party PDFs/ePub files to install easily w/o buying from iBooks store. All other e-book readers I can find seem completely lacking the Apple polish – slow, unintuitive touch interactions etc.
• Smaller text sizes on webpages will be much more readable when they eventually upgrade the display to higher dpi. It might be a year or two though…

I can’t vouch for Pages, Numbers, Keynote or iBooks yet – they aren’t available in the UK app store (which you can only access from iTunes currently anyway).

Related posts:

1. Data sync on iPhone, iPod, iPad – the missing link?
2. My Apple tablet predictions – for what its worth
3. The future of computing UIs – TV and touch tablets and OS X

This raises an ugly prospect: a new resource dependency problem. Only unlike java dependency problems this is worse as you end up with multiple copies of resources in your app, even if they are the same version because plugins will typically bundle the resources themselves. Your app may add some of these too and your site becomes slow to load or experiences failures related to clashing library versions.

There is however a staggeringly simple solution to this: lightweight Grails plugins that contain the resources.

Thanks to Grails’ automatic dependency resolution we (the grails community) can just create plugins to wrap up each such library and then we just make any apps or plugins that require them depend on them by installing the library plugin or adding it to the dependsOn clause of other plugins.

An important caveat here is that the library plugins need to use version numbers matching the version of the library they encapsulate. Then if you want jQuery 1.4.2 you depend on/install grails-jquery version 1.4.2 or higher. The grails-jquery plugin authors have already done this.

These plugins should implement a simple tag called “resources” in an appropriate namespace e.g. or .

I strongly believe that such plugins should NOT include other tags or more heavyweight tags wrapping up library features – do that in another plugin e.g. “grails-jquery-tools”.

This approach does provide new challenges for optimizing static content – minifying JS and CSS and including only required modules from a larger library remains awkward as it is today with non-dependency solutions.

Ultimately I think we need smarter solutions than those currently in use to solve this. I have some ideas forming…

Related posts:

1. …and another Grails plugin
2. Weceem 0.8 Released – Highlights and background
3. I’ve released another Grails plugin

The co-op bank have published a short video screencast demoing their new system, presumably to make us believe they might actually come up with something usable any time soon. The new system is already overdue, pushed back to Q2 2010 which we are already into.

Why am I whining again about this? Well if you watch the video pay attention to some of the details.

First – you need a code generator device just to LOG IN. Yes that’s right. You need a CUSTOMER ID, and a USER ID (hey I’m a small business, there’s only me!), and a generated passcode from those crappy machines that need your card and PIN entry. This mechanisms is supposed to make you more secure – but the way Co-op use it on their personal banking is a complete nightmare. You can’t even transfer a few quid to one of your own accounts, pay a bill (already set up) or amend an existing standing order without having to grab a registered debit card AND the code generator device. It makes the entire process extremely slow and awkward. What about people who work on the move? This is not user friendly at all. Using it to log in is a nightmare.

Second – notice how the transaction display in the video is a complete usability cock up. It shows 3-4 lines of balances without scrolling, despite there being much more screen space. It has a horizontal scroll bar all the time, because there are too many columns shown. Even with this, there’s not enough space given to the name of the account and it wraps after only a few characters. All this can be fixed quite easily but the point is it betrays a complete lack of understanding of usability.

On the plus side, I do notice from the navigation menus shown that there appears to be an ability to search for transactions, although you’ll forgive me if I don’t hold out much hope for the actual implementation of this being any good.

There’s however no mention of an international payments option, which presumably – and rather insanely in 2010 – still requires a FAX sent to their offices, on “headed notepaper” to be acceptable. I know, I had to do this last week. It is so antiquated and so foolish. FAX is inherently insecure, and you could easily fax all your bank details to the wrong person if you get the number wrong. Add to that the hilarious false assumption that “headed notepaper” is of any valid use in judging authenticity at all. They don’t know what my headed notepaper looks like. In fact I don’t have any. I sent it with a default template from iWork. And yet if it doesn’t look like “headed notepaper” they won’t accept it.

Laughable. Wake up banks! We don’t user typewriters, telex or fax any more, even if you do in your antiquated businesses.

Related posts:

1. Co-op Bank responds to my letter of complaint
2. Co-op Business Banking errors again

Version 0.6 fixes a bunch of bugs related to rendering fields for nested property paths e.g. propertyName=”book.author.firstName” and introduces support for list / array properties eg “book.authors[3].firstName” (This was really quite painful to implement!). Radio groups are working properly now, and test coverage much improved – thanks to contribs from Antony Stubbs.

It also adds a user-definable threshold for whether a radio group or select list should be used for a field with an inList constraint.

Full list of resolved issues is here.

Related posts:

1. A new Grails plugin: Invitation-Only
2. Weceem 0.8 Released – Highlights and background

So I recorded myself doing the talk here at home and have uploaded a screencast of it all for those of you who are interested. Its not so good the second try – you had to be there for the best version

Click the thumbnail to download the MOV. Its about 47 minutes. Its probably going to cost me a fortune having it on Amazon S3!

Also available as a torrent.

People interested in making the case for Grails may be interested in an older post of mine that I’d completely forgotten about – “10 common misconceptions about Grails”.

Related posts:

1. Javascript and CSS frameworks in Grails plugins
2. …and another Grails plugin

Aside from all the basics, they allowed 3rd party applications on the device AND the desktop to talk to each other directly to sync custom data. I’ve bitched about this before.

As an avid Mac, iPhone, MobileMe and soon to be iPad user, I have to wonder what is happening with this at Apple. My real-world gripe is this:

I was just about to open OmniFocus on my iPhone specifically so that it would sync with the latest data on my MacBook Pro, which is set to sync via MobileMe (using a pretty ugly file based solution). Why am I even doing this? Why isn’t this data synced (a) when I dock my iPhone to sync all the other iTunes stuff, and (b) why can’t it automatically sync wirelessly

Well part (b) is easier to answer, although it is a three-fold answer. First, there’s no background app support to allow automatic sync of the OmniFocus app on the phone. That should be addressed by the Push API functionality except that OmniFocus doesn’t support Push API (server cost to them to do so) and even if they did support Push, iPhone SDK Push is not able to automatically pass the data to the application to force it to sync – the user must acknowledge the event and run the app on the phone manually. It’s a pile of suck, surprisingly, with a real feel of “disconnected device”.

Part (a) is more tricky to answer. It must be trivial for Apple to add this kind of support for direct-to-app syncing. They already have/had Sync APIs for OS X for a long time. Lack of support for this apparently makes no sense.

In conclusion I am very surprised that Apple has not updated the OS X Sync APIs so that:

• Third party apps can sync any data they like to/from the iPhone/iPod/iPad with iTunes as the conduit (that was the concept’s name in PalmOS if I recall)
• The transport for sync is completely hidden from the applications such that sync will happen transparently via Dock, Wifi (direct between devices on local Wifi network), and via MobileMe cloud if the device is not on the same Wifi network.

This is not rocket science after all. And yet we still have to know / think about what networks our devices are connected to, manually make sure we run them frequently etc. It is pretty lame, Mr. Jobs.

Related posts:

1. Apple iTunes and NAS usage – please fix it Steve!
2. My first few days with iPad
3. My Apple tablet predictions – for what its worth

Ironically, I think that there will not be that much hardware “frill” with the Apple tablet. I think that actually this is really all about software and the masses of computer users who are not “power users”.

Follow the logic:

Net books are very popular.

The iPhone and the new breed of beyond-smart phones is incredibly popular.

What is the common thread here? Both devices are very portable and offer most of the basic computing that people need day to day. What is it that most people – which I’m afraid guys means non-geeks, the truly massive market beyond geekdom – need?

1. Email
2. Web

That’s it. That’s what most people who are not raving geeks need. In fact some geeks may need only that. After all there isn’t much you can’t do with web apps now (e.g. bespin). Google OS/Chrome stuff has been geared to this from the get-go, its not a novel idea.

Functionally, most people also need to be able to write/edit documents that can be read by MS Word – not that they need MS Word, they just need to write out .doc files. This can be done via web apps or via lightweight local apps.

However Apple would not do something like this unless it also offered uniquely integrated stuff.

So on the back of this I reckon the tablet will:

• Not be that revolutionary hardware wise – eg physically this probably is like a giant iphone
• To include some web-hosted (with local offline usage) iWork for Pages (= docs & spreadsheets writing. maybe keynote too)
• Full access to all your iTunes audio and video media and photos (cloud or not) – I would be surprised if this is 100% cloud done at this stage, what with the awful 3G coverage and slow speeds to sync photos and videos. Access to this done “ipod style”, which is a killer recipe as the market has shown
• A first class large-form factor email app, geared to multitouch
• And as suspected the delivery of formerly-print media, possibly opening up iTunes marketplace to any author who wants to prepare and sell content. Who knows perhaps you will even be able to create new textual/mixed content on the iPad and sell it via iTunes. This content provision is probably the one really new thing that helps make such a pad a really attractive proposition.

In a nutshell, a beautiful portable computer that is most definitely NOT a laptop because a great deal of people will never see themselves as the laptop carrying kind. However they are likely to part with cash for something that is much smaller than that but a true lifestyle accessory that “just works”. Obviously it will support custom apps and app store too – which has already shown on iPhone that a lot of people just want little stuff that makes life easier.

Several programmers including myself have wondered “Why do I need something like that?”. The answer is if you have an iPhone and laptop, you don’t. The big market win here is not people like us, its everyone else in the real world! Laptops are complete overkill for a lot of people and the netbook market has sort of shown that. They’re not so much winning against laptops as a result of price, they’re winning on form factor and simplicity. If people really needed high-end laptop features, they’d still buy a laptop instead of a netbook.

I’m pretty sure netbooks aren’t aimed at programmers either – although I am confident some masochists code Perl on them and swear that its the best calculator computer they’ve ever had. The tablet on the other hand, is squarely aimed at attacking the netbook and light-use laptop market.

Let’s see what Wednesday brings!

Related posts:

1. The future of computing UIs – TV and touch tablets and OS X
2. Apple iTunes and NAS usage – please fix it Steve!
3. Data sync on iPhone, iPod, iPad – the missing link?

This is a pretty cool if slightly unglamourous release because it has focussed on some performance and security stuff – oh and compatibility with the latest and greatest Grails 1.2.0 release.

Let me first apologise for the ropey typography on weceem.org – we haven’t yet had the time/resources to fix up the CSS styles so things are a little ugly in places. We will fix it as soon as we get time!

Anyway, we added a security policy. This is a groovy script (currently only loaded once at startup) that lets you define what different users can do. This uses a DSL that lets you declare roles and then say what they can do in different spaces, including whether they can admin the space, edit/view/delete/create content, and even do this by URI requested. (see more info and example here)

Because we believe strongly that Weceem should not force you to use a particular authentication library, we had to decouple the policy mechanism from authentication. As a result these roles are completely uninterpreted by Weceem. To integrate and authentication system all you have to be able to do is provide the name, email, login and list of roles for the currently logged-in user. (an example here)

This has enabled some cool stuff in WeceemSecurityService which relies on the security policy. The service has utility methods for implementing our security logic, e.g. isUserAllowedToViewContent(Content c). For example in previous versions of Weceem you could not preview content if it was not in a publicContent status (eg not Published).

Thankfully from version 0.8, anybody who has the EDIT permission can view non-published content. the default security policy ensures that the default administrator account has EDIT permission, so you can preview away as much as you like. We plan future updates to this to allow the security policy to control who can manipulate different types of content, which will be really powerful for people using custom content types.

On the performance front, it became obvious that something needed to be done because the default “index” page installed by Weceem into new spaces was resulting in huge amounts of SQL queries for a single page.

This is because the page is made up like this:

• It pulls in a Template node for the styling
• It pulls in three Widgets for reusable HEAD section tags and header and footer
• The header widget iterates over all root content nodes and their children to render the menu with the wcm:menu tag
• The page itself links to various StyleSheet and JavaScript nodes to pull in styling and scripts – these are processed on separate requests but still add to the overall burden of the page

This can result in a lot of SQL chatter because we have (rightly so) made no effort to optimize this until now.

There are a couple of areas here that would make a big difference to the SQL traffic.

It is very important to realise that turning on the 2nd level cache in your Grails app’s GORM configuration does not magically give you major performance improvements. My understanding of this rather complex area (which frankly I found very disappointing) is:

• The 2nd level cache is only used for retrieval by object id. This is very important
• The query caches are used to cache the ids of objects returned for a given query
• Query caches are invalidated frequently by Hibernate if your model is not primarily read-only (and can cause some threading contention)

Luckily a CMS is pretty read-only in terms of number of requests that actually read vs update content, so the 2nd level cache is a good candidate for us here.

One of the major SQL hits for Weceem is resolving a URI to the ultimate content node to render. Due to the model we need to query for each part of the URI, so a request for /a/b/c results in three selects. So that’s an easy one – we added URI path -> content id caching (and some other smarts) into the ContentRepositoryService. So once content has been hit, it will always be retrieved by id in future, via the 2nd level cache.

Another issue is iterating over child nodes. This is less trivial. We are using some query caching but I have noticed that some of the criteria were not hitting the caches despite this – it needs further investigation. I think that due to the polymorphic nature of the content model and query cache invalidation issues, we may stop using these in future (think blog comments being submitted and invalidating ALL your caches).

Next up: Template and Widget nodes are GSP pages that we compile and evaluate. It turned out that due to issues in Grails GSP handling (that persist in 1.2 to my knowledge), there is no internal caching of compiled GSP classes built from non-Resource content e.g. strings. This results in a leak of PermGen space which ultimately results in VM collapse. So we now have a simple cache of compiled Template and Widget GSP pages, which is automatically invalidated as necessary when templates and widgets are edited, so it is transparent to the end user that there is a cache.

Finally with regard to performance, we introduced a nice simple wcm:cache tag. This lets you cache fragments of a Template/Widget and hence get major performance improvements. The cache is currently fixed at 1 hour, but its great for anything that pulls in remote content or for any expensive node iteration tags you might be using. More enhancements will come in future.

A couple of nice little things we squeezed in:

1. The Cancel button is back on the content editor screen, in the “right” place for Windows users (meh) and browsers (who made return always select the first button argh!)
2. The wcm:link tag now passes through any unused attributes eg class=”whatever”
3. We added a JS syntax highlighting script to the default space that you can use to render code snippets in your content easily

Anyway, please enjoy this release. Soon time to get started on 0.9 which should see the Blog functionality completed and other refinements.

Related posts:

1. Javascript and CSS frameworks in Grails plugins
2. Development is easy. Creating product is hard.
3. I’ve released another Grails plugin