Getting my feet wet with Scala

01. April 2012 · Write a comment · Categories: Groovy / Grails, Play 2, Programming, Scala, Web/Tech

The hype around the Scala programming language just got too much recently and I decided to give it a go. I'm two thirds of the way through Programming in Scala, a massive but very good tome and I've been experimenting with the language and tools, though only a little bit so far. I have also just received the newly published Scala for the Impatient (a deliberately much more compact book) and will be working through that as well.

To put it mildly, Scala is not for the faint hearted, or anyone who just wants to get some stuff done ASAP. There is a big, steep learning curve and the relative immaturity of the language and the small community means you'd better be used to the pains of the bleeding edge. I thought Ruby was hard work, but Scala is frankly more so in my experience so far.

However the language is somewhat addictive – or perhaps I just like the challenge of learning stuff that takes a bit of grokking. It's a big language, with many very clever facilities and features. It's mind-boggling to start with but I think it's starting to sink in. Of course there's the functional paradigm to understand and master, but I did plenty of that at university so it doesn't frighten me.

Enough people have written about the frustrations and wonders of writing code with Scala, so I think I will reflect on a few miscellaneous findings, mostly of a practical bent.

Compiler speed

The Scala compiler is surprisingly slow and it seems to be one of the main bitching points amongst people trying to get up to speed with the language. But seriously, when you're used to instantaneous results with Grails, or even plain old Java (especially with JRebel) then waiting several seconds even for a trivial app is most upsetting. But I'm trying to be Zen about it.

The mailing lists tend to be full of griping about the compiler's speed, usually met with promises that it's getting faster, but the Scala compiler is so much more complicated than the Java compiler that it seems unlikely to do its work in the blink of an eye anytime soon. See Martin Odersky's explanation of why it's slow on Stack Overflow.

Eclipse support

Eclipse supposedly has good Scala support via the Scala-IDE plugin, but I found the out of box experience so terrible that I have given up. Having created a "new Scala project" I still had to manually add the Scala libraries to the project and manually create run configurations, which would very often still not appear in the lists of ways to run the project. I just want to hit "Go" and for my app to run – it should be trivially easy to make this happen. In my experience the best open source projects are the ones that deliver a delightful out-of-box experience and this has disappointed me on that front.

IntelliJ IDEA support

Luckily the Community (i.e. free) edition of IDEA supports Scala. Even though I hadn't used IntelliJ previously, I figured out how to download their Scala plugin and create a Scala app within just a couple of minutes and it was a very smooth experience compared to installing the Scala support into Eclipse (don't get me started).

However compilation of a Hello World app took 7 seconds every time I modified the single file! A bit of Googling led me to discover FSC – the Fast Scala Compiler – which is part of the standard Scala toolset. Support for FSC is built-in to IDEA but that support is turned off by default. Once I turned it on for my project things hotted up and compilation took just 2 seconds. That's still lamentable compared to most other languages, but just about tolerable for now. I have no idea how things go for a big project, though I get the impression from mailing lists that waiting tens of seconds or even minutes for a compile is fairly commonplace. We shall see.

Play 2.0

One of the reasons I decided to try Scala in the first place was the fuss over the Play 2.0 framework, which has just recently been released in its first 'complete' form. I have only messed with a couple of tutorials so far and frankly it's bewildering and strange coming from frameworks like Spring MVC, Grails, and Ramaze (a small Ruby framework).

There is much wailing and gnashing of teeth on the Play mailing list from people upset about its radical new direction, and its emphasis on Scala compared to Play 1. Maybe it's just the pain of change, but there's no doubt Play 2 is hard work to get to grips with.

I get the impression that a lot of people are missing the point though – it's a case of horses for courses. Play 2 is rather exotically architected using cunning non-blocking approaches that require it to abandon the classic Java Servlet container entirely. It also requires you to write obtuse and sometimes verbose code (compared to Grails say – though it's usually less verbose than Java) and partly because of that non-blocking architecture. Reading and understanding the Play 2 docs on Action Composition may very well require a PhD, but Action Composition is a technique that must be used to achieve relatively common ends. It's all a bit overwhelming for newbies.

This clever shenanigans enables it to handle 40,000 requests per second (albeit very very simple requests) using less than 20MB RAM. I saw Guillame Bort demonstrate this at QCon and it's certainly impressive. The point though is that it's all architected for the sort of new-breed web app that's dealing with connected rich-clients rapidly pushing and pulling data. If you want to create a few CRUD pages for a small admin team to look after a database then I very much doubt that Play 2 is for you.

Grails custom exception mapping

07. March 2011 · 4 comments · Categories: Groovy / Grails, Programming, Web/Tech

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.

Grails dependency hell

24. December 2010 · Write a comment · Categories: Groovy / Grails, Programming, Web/Tech

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.