Richard's technical notes

I have a love/hate relationship with Groovy. I do find it wonderfully productive for hammering out a quick script to do something, but I feel uneasy attempting anything larger without my crutches of static analysis (strict shouty compilers and Find Bugs) and knowing there are great profilers if I need them. Yet, when returning to Java I'm left thinking "why do I have to write so much code?".

You'll understand, then, why I find Scala so appealing.

Still, I do use Groovy, and mostly I use Groovy in the context of Grails, where I enter small snippets of Groovy to get the job done. Even here, though, I rely on an IDE to help and the only really usable one is IntelliJ where they have done a great job on supporting Grails. Having said that, the Grails Podcast have mentioned that there's been some good Grails work in Netbeans 6.5. Don't get me wrong: Netbeans is a great tool, but in some respects it always seems to be "jam tomorrow"....

To keep up-to-date with the Grails world, I headed up to the Skillsmatter for the Groovy and Grails User Group Meeting. It was good to see who's using Grails and how people are using Grails, to chat with them at the pub, but also it was handy to hear Graeme Rocher give a "state of grails" talk. And there's some great stuff in the pipeline for 1.1:

• plugins are going to be installed once on your machine and only the meta data will be written to your project, and the plugin system will resolve dependencies for you;
• the plugin system is going to be faster at finding and listing plugins;
• plugins can be scoped (e.g., this plugin just for testing, not deployment);
• improved Maven support (the Grails POMs have been published already, I believe);
• decoupling of components out of Grails, including GORM and GSP;
• better Java integration, such as for JPA, JSP, portlets; and
• OSGi support after 1.1.

And I suspect there will be hundreds of smaller changes too. All this is schedule for Dec 08/ Jan 09, which is the same timeframe as the two new Grails books: Grails in Action and the 2nd edition of The Definitive Guide to Grails (I would not recommend buying the 1st edition now, as it was based on Grails 0.3). As I'm mentioning books I'll just say that I found Programming Groovy: Dynamic Productivity for the Java Developer to be pretty useful.

The event was recorded, and it looks like it will appear on the Skillsmatter Java podcast page.

Monday was the first Scala London User Group meeting that was held around a keyboard. Robert Rees arranged for a room, food, and drink at ThoughtWorks, Jamie Webb kindly gave an intro to Scala talk, and Aaron Roth provided print outs of a Scala for Java Programmers cheat sheet...and so we spent time working on the supermarket problem.

I counted 19 people (of which 3 were Brighton based), of mixed abilty (from functional people or Java people who had never touched Scala, all the way to expert Scala-heads), and we had working, unit tested, software by 10pm. Which—given that coding dojos sound a bit mad—is pretty good going.

Dojos are probably not going to be the way forward for this group, but I think it did a good job as an ice-breaker: an inclusive activity; a task that's not daunting, that anyone can have a crack at. I definitely learnt stuff: testing using Specs, and need to understand the Scala patterns, such as Cake for dependency injection, and I have to stop putting off looking at Lift. Perhaps the most important thing for me was to learn that the Eclipse Scala plugin is going to be able to do mixed compilation of Java and Scala source in a project.

There was video of Jamies talk. I'll add a link if it's posted any place. At the moment there's no web site for lsug but get in touch if you'd like the mailing list email address.

There are more photos on Flickr tagged with lsug.

On Paul's return from JavaOne this year, we spoke about Neal Gafter's Closures Cookbook talk. From what I understood, this was a look at the BGGA closures proposal, and contained an example that pushed hard on some of the tougher closure issues for Java. I thought it might be fun to look at the Java example from the talk, and covert it to Scala and Groovy.

Why those languages? Because they are the three JVM languages I'm most interested in. I suppose I could also have compared the closure support in Jython, JRuby or... well, there are a few to choose from, but this blog is going to be plenty long enough with just three.

Let's start with the Java example that was given, remembering that this is a proposed syntax, that may or may not make it to Java 7 or later. As I understood the example it was this: imagine you want to add the ability to time a block of code, and you wanted to do it in a way that would look almost like a new keyword has been added to the language; and you wanted to pass in a parameter to name what you were timing; and the block you're timing returns a result, or might throw an exception. So, quite an involved case.

Here's how the current Java proposal looks:


So we're timing a couple of operations, and we're doing this inside a method, f, that returns an integer. The implementation would be....


As you can see, time takes an arbitrary text label and a block of code, runs the block and tells you how long the block took to run and if it succeeded or not.

That's the example that was given at JavaOne. Now for the same thing in Groovy...

To make runnable code for Groovy (and for Scala), I had to decided to time something. So I'm timing a block of code that randomly throws an exception or returns something. And then timing a block of code that just returns a number. In Groovy that would be:


An example of running the code:


Note that the Java example is typed in that it uses a generic type, R, for the return value which gives you some compile-time checks. That is, when you run time and use the result, the compiler will enforce that your declaration of the result has the same type as the return type of the block you're timing.

Although Groovy does support generics, I've not used them here, and as a result the Groovy example doesn't have that type-safety. I think that's the way one would typically write Groovy code.

UPDATE: as was pointed out to me in the comments on the Java Lobby version of this blog post, this isn't the same as the Java version. In the Java version a return in the closure returns out of the enclosing block.

Now a look at the same code in Scala:


I'm still not using Scala day-to-day, so this might be a little awkward: thank you to the London Scala User Group for helping me clean up my syntax, but all the mistakes are mine.

This code has the same properties as the Java code (type safety via the R generic type), but seems a little shorter and neater. Additionally, the thing I like about the Scala code (and the Groovy code) is that the languages return the value of the last statement in a block, and that the syntax allows a clean time("thing") { ... } format.

One observation: I've used the Integer class, which is deprecated, in order to be able to print out the class of the return type in the function f(). Without the :Integer declaration I was getting weird compile errors. As I said, my understanding of Scala and type inference isn't there yet.

The output from running the code:



There's no conclusions here. It's just an exercise in comparing closures code in three different languages. I've probably missed some of the nuances of the Java example, but hey... it's a starting point.

Last night I was at Mobile Monday London to catch four presentations. The topic: advertising on mobile. The summary: there's a need for better measurement.

Claire Valoti from Mindshare was up first, giving the agency view of mobile advertising. She split the appeal of mobile in a media plan in to two parts: as a delivery mechanic (to extended reach, getting to a winder audience in a different mode); and as a platform (for couponing, or video uploads). She then went on to describe some issues and themes... and standardization and measurement were pretty much top of the list. That is, there's currently no good standard measure of reach, sessions, traffic or users for mobile advertising. And even if there was, it needs to be integrated into existing web buying systems, rather than via a mobile-specific system.

Claire had a good observation on social networking, and the importance for mobile. The m:metrics numbers quoted showed that the 18-24 and 25-34 age groups were more likely to be using social networking from the mobile, compared to 13-17 age group. It's not just about a youth market.

Another good point was made that events drive handset usage, as does "the right handset". An example given: at the end of the football (soccer) season, there's a drop in usage; during the season people are out and about and will use the mobile internet to look up news. As for "the right device", just look at the figures for internet usage on the iPhone compared to anything else....

Obviously mobile advertising has to be used in the context of the whole campaign, and it has to be relevant content: don't go taking an ad made for TV and slapping it on a mobile. Use the right techniques to get reach (banners, SMS, bluetooth), use location information to make it relevant, use coupons and free content to make it useful to the customer. And the user experience needs to be more streamlined: don't issue mobile coupons without telling your retail staff how to handle them.

Aside from measurement, another barrier to growing advertising budgets is the number of people involved in setting up a mobile campaign. The buying experience needs to be more streamlined.

Mobile advertising challenges were summarized as: speed, reach, cost, ROI, standards, and measurement. As examples of reach issues: Claire was interested in QR codes, but only 10% of mobile devices have a reader installed; buying from Blyk or similar to get an audience was described as having "limited reach" at the moment; mobile search needs to scale up as, right now, it's hard to spend the budget.


Shan Henderson from Vodafone kicked off his presentation by saying that it's the metrics that matter. Click rate is not the full story, but it's often the headline. Also audience demographic, behaviour, session length, frequency and reach are all important because "money follows measurement in media". He showed the "measurement gap" graph. I'm sure the slides will be available soon, but for now I've done a shaky recreation:



(I'm guessing Edward Tufte would not approve). So, we all agree it seems: we need better standards for measurement and more efficency in the buying and selling of advertising in order for the market to grow.

To address this, Shan went on to describe the GSMA Metrics Study which aims to make it easy to plan and measure mobile media. Later this year it's going to produce (one or more of): guidelines, best practices, definitions, technical standards, responsible ad practices, content standards. This will all be via an as yet unnamed ABC-like trusted independent organization.

Russell Buckley took the stage to talk about Admob, a self-serve and full-service ad network, shifting 2.bn ads a month, in 160 countries via 3000 mobile web sites. They select mobile sites, put ads on them, and share the revenue with the site. He described mobile advertising as good for: bands; to promote mobile websites; for operators to monetize their sites; and content owners to have access to a new marketing channel.

There was then a page of logos of who's advertising, and it showed that the US is generally ahead in terms of adopting mobile advertising. In fact, ad requests by country (to March) showed 47% of ads were for the USA. Other figures were: India (9.8%); UK (6.7%); South Africa (5.3%); Indonesia (4.7%); Romania (1.9%); Canada (1.3%); Philippines (1.3%); France (1%); Israel (1%); RoW (20.1%). By handset, Nokia were the top, although they are dropping: something that's not yet reflected in their market share.

Russell presented some case studies. MTV wanted to drive traffic to an awards site, and using text adverts they had a 300% traffic boost and 400% increase in downloads. Land Rover USA saw 23% of users interacting with an advertised landing page, with 3% going on to click the link to make a call to a dealer. Adidas saw a CTR of "well above 3%". Coca-Cola saw a CTR of 1.31%, but 130% watched a mobile video that was being promoted (some people watched it more than once).

Ray Anderson from Bango described the basic model for using advertising as: select a channel, measure response, look at user purchases, analyse ROI, then... repeat.

He made some great observations on the issues of search. Depending on the combinations of search provider and operator, you may find you get very different results from the advertising spend (especially if the content is transcoded). But he had a graph that compared the revenue Bango customers had received over time from Orange and Vodafone: the doubling (or more) in the graphs when the operators introduced a search page was impressive.

After the talks there was a brief panel session. All good stuff. And held in a great building.

Photos: from Route79, from appelquist, from Alex Craxton

Video and audio: usual appear on the Mobile Monday web site after a little while, so check there.

This post is going to be a bit niche. The scenario is that you've used JetS3t to backup data to Amazon S3 via the synchronize tool, and in particular you've used the -c option to encrypt the data. But you've downloaded the file with another tool, such as ForkLift or S3 Browser. How do you decrypt the downloaded file?

The default encryption is PBEWithMD5AndDES, and with that knowledge you may be able to find a tool that can decrypt it for you. I went a different way, and just hooked straight into the encryption utilities inside JetS3t:


So with a bit of fiddling you can copy, paste and compile that (you'll need the JetS3t library and supporting JARs, plus Commons IO). Or you can download jets3t-decrypt-dist.zip, which contains the source and the reqired libraries. Once inside the ZIP you can run:


The libraries and the Jets3tDecrypt.jar was packaged automatically by Netbeans 6.1, which is a lovely touch from an IDE.

A few months ago I was experimenting with QuickTime for Java. It's the binding between Apple's QuickTime "stuff" and the Java language, allowing a Java developer to invoke QuickTime on the Mac (and presumably also on Windows). The reason this appeals is that we do Java, and have accumulated a fair amount of Mac hardware.

To cut a long story short, my limited experienced shows that QuickTime, when compared to the standard Java image libraries, produced smaller images of higher quality, faster. It's unusual to get all three benefits together (smaller, faster, better). Too good to be true, even, which leads me to think I've screwed up someplace, but I've not spotted it yet.

The particular test that interested me was was taking a camera phone photo, resizing it and rotating it. Here's an example original:



Here's the rotation using tried-and-trusted AffineTransform plus ImageIO:



And here's the same transformation run through QuickTime for Java using the GraphicsImporter and Matrix objects:



Now, it's subtle but the QT4J image looks to have sharper colours, and seems to be a better representation of the original input. It's also 20k compared to the 76k using the Java 2D libraries, and the code runs 1.7 times faster. The downside: you need Apple hardware.

A few conclusions: it seems the Java 2D code doesn't just fall through to QuickTime on the Apple platform in any simple sense (which, I suppose I might have naively expected). Second, I suspect there's a lot of tuning that can be done in the Java 2D client usage to improve the quality, but QT4J seems to have good defaults.

(Before you ask, the dog's name is Jack.)

Friday night was the first London Scala User Group meet-up, so it seems like the right time to say what I've learned so far about the language.

I'm not a functional programming person. My background, pre-Java and C, was dominated by POP-11 so it's fair to say I'm more comfortable with imperative coding than anything else. But that's kind of why Scala's a serious consideration for me: it doesn't force the functional stuff down your throat, but rather it's all there, object and functional, so you can pick and choose.

Other compelling aspects of the language are: it runs on the JVM, which has had a huge engineering investment to make it as fast as it is today; has Java-like features, but looks like it lets you get your work done with less lines of code; and it's strongly typed. In other words, it's comfy for a Java person, while putting you in a position to use the funky actors and functional stuff, and maybe make even better use of those multi-core machines.

Here's an example of less-lines-of-code thing. In Java, the type-safe idiom for iterating over a map is:


The same code, just as strongly typed, in Scala is:


Or, if you wanted that last part could be: map.foreach( (pair) => ...do something with pair._1 and pair._2 here.. ).

If you're interested in getting into this stuff, I found it useful to start with A Scala Tutorial for Java programmers PDF, then listen to Episode 62 of Software Engineering Radio, an interview with Martin Odersky on Scala (thanks to Dom for pointing that out to me).

After that, I think the best place to go is into your wallet and buy a copy of Programming in Scala: A comprehensive step-by-step guide. It's a pre-print, with quite a few errors, but I'm pretty sure they'll get cleaned up soon and it'll be a great text.

Tags: scala

UPDATE: oops, I forgot to escape the < and > tags in the Java example above, which hid the generic types of the map. Fixed now.