Always The Critic

Three, is the magic number

I recently switched from O2 to Three (whilst picking up a new iPhone 4S) and frankly it’s great. It must be great if I'm blogging about it! Key wins are as follows.

• All you can eat data with Three. O2 have recently abandoned unlimited data and charge based on fixed price data packages for paltry amounts – e.g. 500MB for £6 per month. To be fair I should point out that their systems told me I was only using about 200MB per month previously. But read on…
• Tethering! I can turn on Personal Hotspot on my iPhone and connect to it via Bluetooth, USB or WiFi from another computer and get all the wonders of the internet. This has revolutionised my train ride to work with my laptop. Phone stays in pocket and via Bluetooth I’m fully connected to the world. This is technically possible on some other networks but often only at a price, either to turn it on at all, or because you’ll be charged oodles for the data you use up.
• Raw speed. Over 3G I now regularly get 8MBit downstream, 1.5MBit upstream. That’s better than many people’s home broadband and a lot better than I ever got with O2.

It's not all fun and sunshine though. I found a couple of major downsides, which I will just have to live with.

• Visual voicemail doesn’t exist on Three. Frankly I was dumb-founded when I noticed this. I literally couldn't believe it, but apparently it's true. Instead you get a text message telling you that you have a voicemail and then have to phone a voicemail number and painfully navigate through things with the numeric keypad. It’s positively medieval and if I wasn't so smitten with their data service it would definitely be a reason to avoid Three entirely.
  
  Of course you only find this out after you've signed up because it's not something they point out to you. I have had conflicting messages from different Three employees in shops and on the customer service line about whether they ever intend to get with the program here. Alas I fear they won't.
• Customer service can be dodgy. It was a struggle to get my phone up and running in the first place due to some miscommunication and dodgy information from Three. Their customer service line is like a choose your own adventure book - consisting of endless numeric options designed to avoid having to actually talk to you. Once I actually got to speak to somebody it was alright, though I had to fight my way through the number-maze each time - they wouldn't give me a direct number.
  
  Before my phone was activated (which is ironically what I was trying to phone up to arrange) it was literally impossible to talk to someone because the first auto-question asked for your mobile number and then complained that it wasn't activated! Apparently you have to type hash to defeat this particular monster but they didn't tell me that and the prompt doesn't mention it. Apparently it's a secret.

Blocks!

You might have noticed I've been a bit quiet on this blog for most of this year, though I've been doing rather better on my other blog: UK Nature Blog. That's the problem with having kids - suddenly you don't seem to have a lot of time spare. But there are upsides, and just enough time spare to revel in them! I am of course referring to the opportunity for pushing the limits with small childrens' toys! It was necessary to build this on carpet otherwise the two 'feet' would just slide apart.

Chris Packham interview

I recently had the privilege of interviewing TV presenter Chris Packham for my other site: uknatureblog.com. He was a very straightforward and knowledgeable chap who's clearly passionate about what he does. It was interesting to get an insight into his own garden full of birds, his photography kit and activities, and the deeper topics of the cut and thrust of modern conservation.

It's in three instalments: one, two, three. Personally I think the third is the best!

Grails custom exception mapping

Updated 17/3/2011 with a solution to Spring Security redirecting.

I had a bit of a fight against Grails to get security exceptions handled the way I wanted, but having figured it out I thought I'd write it up. It's really very simple - I had just had the wrong end of the stick.

I want to be able to throw an org.springframework.security.access.AccessDeniedException from anywhere in my code and have that appear to the user as a custom error page of my design, but with a 403 response code (that's 403 Forbidden, rather than 500 Internal Server Error) and maintaining the originally requested URL rather than redirecting to an error URL as Spring Security sometimes prefers to do (because then you can't refresh to retry).

My main confusion arose from the way Grails' UrlMappings.groovy handles custom exception mapping. It turns out that you need to do it like this:

// Handling specific exceptions requires a 500 code on the left for the
// mapping to pick them up, but we can send back another code in the
// controller that sends back the response.
"500"(controller:"error", action:"error403", exception:AccessDeniedException)

The only surprising thing is that you need a "500" code at the left rather than "403". The reasoning seems to be that this is the incoming error code to the mapping function, and all exceptions are deemed to represent a 500 error code at this point, i.e. they represent an internal server error, which on reflection isn't entirely unreasonable. To then send the error back to the user I have an ErrorController and an associated view in /views/error/error403.gsp.

@Secured(['permitAll'])
class ErrorController {
    def error403 = {
        // Ensure that the correct response code gets sent. If we don't do
        // this, it may send a 500 (internal server error) response because
        // of the way we had to configure the UrlMappings for handling specific
        // exception types with 500.
        return response.sendError(javax.servlet.http.HttpServletResponse.SC_FORBIDDEN)
    }
}

I also figured out how to stop Spring redirecting to a new URL when it decided to deny access. I'd rather the originally requested URL remain in the address bar. The trick is to put the following in Config.groovy.

grails.plugins.springsecurity.adh.errorPage = null

The major remaining annoyance is that these exceptions get reported in the logs whereas I'd rather they weren't (they represent the system working correctly) but I imagine I have to reconfigure logging to resolve that.

Dark train by iPhone

Waiting on a dark platform for a train. I wonder if my iPhone (3GS) can take a picture with any merit? Apparently so, assuming you like a grainy, dark blur, which frankly I do! The colour, the grain and the blur really make this picture. I even kind of like the white post in the top-left, as a jarring bit of realism creeping into the otherwise abstract shot.

Grails dependency hell

I just upgraded to latest Spock and Geb releases (0.5 and 0.5.1 respectively) but have had to undergo a strange sort of hell of odd errors before getting back on track. Turned out none of these were due to any actual code incompatibilities and eventually (after a couple of hours of fruitless head scratching) I got past them by running "grails clean" (which got me to some new errors) and finally by deleting ~/ivy2/cache. The latter step sadly seems to be required quite often when adding or upgrading plugins.

Personally I'm bitterly disappointed that Ivy (or Maven, if that's your poison), the so-called solutions to dependency hell, seems to introduce its own dependency nightmare more often than not. Of course every time you delete that Ivy cache folder you have to wait fifteen minutes the next time you run the app, whilst it downloads hundreds of jars. If you're on the train and not connected to t'Internet, you're really stuck.

I'm sure one day I'll grok what's really going on with this stuff, but for now I feel it ought to just work, but it really doesn't, and many people must waste a lot of time (or give up entirely) as a result.

Terrible Siemens fridge controls

The problem with a lot of industrial design is that it's cynically conducted to sell the device in the first place, rather than to actually be any good in the long run. That is to say, the device is designed to appeal to the shop-floor browser who's making a snap judgement between competing products, rather than to actually be a brilliant product for them to use year after year. Once they've bought it the game is over as far as the manufacturer is concerned, as long as it doesn't actually break down, because poor usability does not invoke the warranty! I came across a great example of this recently in the control panel of a Siemens fridge. Behold:

There is one button on here that you will use several times a day. The rest you may use either never or once every year or two. Care to hazard a guess which one is the magic button of actual usefulness? It's the one marked "dispenser". Or to be precise it's the one marked "dis-penser" split over two lines, such is their lack of grace. This button switches the ice/water dispenser between water, ice and crushed ice. To get a glass of iced water, you have to press it a few times to cycle round the options as you fill your glass with ice, then water.

This should be the only button on the front of the fridge immediately above the dispenser, and it should be very clearly labelled. In fact arguably there should be three buttons, for water, ice and crushed ice, with LEDs to show which one is selected. They should be labelled "Cold water", "Ice" and "Crushed Ice". Imagine a visitor to your house approaching your Siemens fridge for a cool drink. They will probably accidentally defrost your freezer then child-lock the fridge before giving up and having tap water. Maybe it's an eco feature?

The controls that are not related to the water/ice dispenser should be far away from it, possibly inside the fridge door or behind a panel, so as not to pointlessly engender confusion and accidental fridge reconfiguration when trying to get a refreshing beverage.

So why have Siemens chosen to take this insane path? I don't believe they could be so obviously dumb, so I assume it's a cynical ploy to sell more fridges. Imagine Joe Shopper, strolling through the aisles of Currys, looking at endless gleaming monoliths of cool technology. Joe wants a high-end fridge, the sort of fridge that says "Joe is a classy guy who won't let anything stand between him and a glass of brain-freezingly cold water." Given two stainless steel slabs of Germanic engineering with largely identical specs he's going to go for the one with the most 'impressive' control panel. So actually Joe, it's your fault, but the nice guys in the Siemens design department must cry themselves to sleep at night.

STS 2.5 RC1 "Refreshing external folders" error

I feverishly installed the latest Springsource Tool Suite release today - 2.5 RC1. Unfortunately it fairly swiftly started giving me the error shown below as I worked on my Grails project. It was popping up really frequently and would be a show-stopper if I couldn't fix it.

It became apparent that it does this every time I saved a Groovy file that required my running Grails app to reload. It seems that STS didn't like the files in the 'target' folder changing as it recompiled, especially since I have  auto-refresh turned on in STS. I worked around this by setting up a rule for my project to exclude the target folder.

Right-click on the project, selected "Properties..." then Resource > Resource Filters. Add a filter to exclude the folder "target".

Groovy and Grails thoughts

I've been slowly banging away at a small Grails app on the train to and from work, to teach myself Groovy the language and Grails the web framework. I already had a good familiarity with Java, Spring and Hibernate so it is mostly a case of learning what Groovy and Grails add on top of those. I've still got a long way to go, but I thought it worth jotting down some thoughts in case they help somebody else work their way into this particular world.

Overall, it's been fairly pleasant and I'm optimistic that it's probably as good a way to go about your average web app as any I've found before, and I've tried plenty over the past decade, including a few fairly obscure ones. I should point out that I don't believe in silver bullets any more. There are always going to be frustrations along the way when using any technology for a non-trivial project involving real-world customer requirements, but it's instructive to see just how many of those frustrations there are, and how hard they are to get past. I'm pleased to say that each time I've got a bit stuck with Grails I've been able to dig myself out fairly swiftly with the help of the existing documentation, other web resources, the #grails channel on freenode IRC and the grails-user mailing list. Furthermore, the principle of least surprise (POLS) is alive and well, meaning that when I hope that I'd find a particular feature to solve my problem du jour, it's usually there for me to find.

It's not all sunshine and roses though. For instance when I upgraded to Grails 1.3.3 my unit tests started failing with a strange and unhelpful stack trace emanating deep from within the guts of the plugin framework. Turns out this is a bug introduced in 1.3.3 that plenty of people have been caught out by. I've had to go back to 1.3.2 for now. It's a shade surprising and disappointing that a release could contain a bug like this, and that it's not been fixed and re-released yet. I worry that people trying Grails out for the first time with 1.3.3 will have a bad experience and give up early because of issues like this.

I had a struggle to find half decent tools. I've been a huge fan of Netbeans over the past several years and it claims to have great Groovy and Grails support, but I found it to be woeful I'm afraid. Common GSP tags completely confused the GSP editor (it claims the syntax is wrong) so I struggle to believe that those claiming it has this great support have actually tried developing a non-toy Grails app with it. I've settled on SpringSource Tool Suite (a bastardised Eclipse) which isn't bad - though as of this writing you definitely want to get the 2.3.3 M2 version for the latest Groovy and Grails support that's not yet in the stable release.

Grails GSP HTML escaping confusion

I'm currently getting to grips with Groovy and Grails. One major frustration that took a while to figure out was HTML escaping in GSP pages. Here's the simple lowdown, including at the end the important bit that I had struggled to realise, which is how to not escape specific strings when global HTML escaping is turned on.

Manual escaping

Out of the box (i.e. with a vanilla Grails app with default config) you need to explicitly escape any dangerous strings with the encodeAsHTML() function that Grails makes available on all Strings: ${dangerString.encodeAsHTML()}. This is a bit verbose, but at least it's very clear, and because it's just a method on String it's available everywhere in your app, not just in GSPs.

Auto-escaping with default codec

If you modify Config.groovy to contain grails.views.default.codec = "html" (which is there by default and set to "none") then it automatically calls encodeAsHTML() for you whenever you use ${} in GSPs. This is clearly quite a handy option and a much safer way of configuring things as it lessens the likelihood of slipping up and leaving a hole in your app.

Overriding auto-escaping per item

So far this is all exactly as per the Grails docs (which go into much more detail on codecs and what's really going on, including creating your own) but the crucial bit they fail to mention is what to do if you've turned on the global html codec, but have situations where you don't want escaping. The answer is to simply use the alternative JSP style interpolation syntax <%=mySafeHTMLString%> since the codec is only applied to ${}.

Overriding auto-escaping per page

You can also set the codec on a per-page basis, overriding that set in Config.groovy, with <%@page defaultCodec="html" %> or <%@page defaultCodec="none" %> as appropriate.