Log into your Grails app using your Twitter credentials

I’ve got a new little hobby grails project that relies on a user’s tweets to power its data collection, so I’ve been exploring using Twitter’s oauth features to do away user accounts altogether. My little project is called “Twitter Until You’re Fitter” and the idea is that I can tweet my weight “@tuyf 93kg” each week, and the app will pick up the value and graph it over time toward my goal weight (85kg). Given my current gym workload, that shouldn’t be too far away :-)

For those of you who haven’t played with oauth, it’s one of those emerging “federated SSO” type protocols. You generate a signed request from your application and sent it off to twitter. Twitter asks the logged on user whether they wish to allow your application access their account. If they agree, twitter will send your application an oauth_verifier which you can use to logon as that user. Generating and processing all those tokens is easily handled by twitter4j

In order to get started, you first have to register your application with twitter, after which you’ll be issued with a “consumer key” and a “consumer secret”. You’ll want to squirrel those away in your /grails-app/conf/Config.groovy to get access to them later:

twitter {
    oauth.consumer_key = 'd8sfsv9s0afs89v0sdesvs0'
    oauth.consumer_secret = 'lfsdDKSFjepfskvespfseruDFESilsfesfiseLFS=='
}

Next up we’ll taked advantage of Grails 1.2’s new dependency management gear, by adding twitter4j to our /grails-app/conf/BuildConfig.groovy

dependencies {
    build 'net.homeip.yusuke:twitter4j:2.0.10'
}

With our dependency in place, and our keys all set aside in config, it’s time to generate a request to send the user off to twitter. I’ve setup a little TwitterService class to abstract some of the details:

class TwitterService {

    def generateRequestToken(twitter, callbackUrl) {
        def consumerKey = ConfigurationHolder.config.twitter.oauth.consumer_key
        def consumerSecret = ConfigurationHolder.config.twitter.oauth.consumer_secret
        twitter.setOAuthConsumer(consumerKey, consumerSecret)
        def requestToken = twitter.getOAuthRequestToken(callbackUrl)
        return requestToken
    }

}

I’m passing in the twitter4j object itself, since I’m planning on binding that object to the user’s session, and using it to access their timeline. Now we just need a controller to generate the “redirect to login” feature of my application. Something like this should do it:

def requestLogin = {
    def twitterClient = new twitter4j.Twitter()
    def returnUrl = g.createLink(controller: 'oauth', action: 'processLogin', absolute:true).toString()
    log.debug "Generating request with return url of [${returnUrl}]"
    def requestToken = twitterService.generateRequestToken(twitterClient, returnUrl)
    session.twitter = twitterClient
    session.requestToken = requestToken
    redirect(url:requestToken.getAuthorizationURL())
}
[Read More]

A Groovy day out as OSDC

I spent last Thursday with a bunch of the Queensland Groovy and Grails folk, hanging out at the Open Source Developers Conference. The day started with a super Groovy/Grails in the Enterprise talk from Bob Brown. After that was a great chance to meet Paul King from “Groovy in Action” fame:

Paul King

I sat down and interviewed Paul about Groovy, Agile, GPars and Chickens, which will appear as part of episode 101 of the Grails podcast. I went to Paul’s talk on Groovy Testing which we gave with Craig Smith. There’s already a copy on slideshare, so check it out.

I also had a great chance to hang out with Steve Dalton and Lee Butts from Refactor. These guys work on the Grails S3 plugin and the Portlets plugin. Lee is also a Grails committed. We had lots of good chats about putting together an .au Groovy/Grails conf next year. Stay tuned - it’s gonna be a very Groovy time in the Sun.

Steve Dalton and Lee Butts

Finally, I had a chance to sit down with Luke Daley. Luke is behind the Grails Fixtures plugin, the LDAP plugin and the Grails Textmate plugin. Luke had some really good insights on developments in the Grails testing space, and it was also cool to meet another Grails Guitar player and Maven fan.

Luke Daley

Big thanks to Steve Dalton at Refactor for talking me into coming and sorting out getting me in the door. It was a fantastic time and I can’t wait for a local GroovyConf next year! It’s gonna rock!

Interviews will be up on the Grails Podcast site later in the week. Stay tuned!

[Read More]

Converting GoogleCode projects over to Mercurial

Continuing my fascination with all things mercurial, I’ve converted over a few of my googlecode projects (including groovyblogs and gravl). Google code has supported mercurial for a while, but it was initially piloted on just a few projects. These days the floodgates are open :-)

Google provides you with a Step-by-step guide on converting your project from Subversion to Mercurial. In the best case scenario, just do a “hg convert http://projectname.googlecode.com/svn hg-version-of-my-projectname” and you’re in business. I tried this and the changesets took so long to pull from the remove svn repo, that I gave up after letting it run for a few hours.

Fortunately, some kind soul linked to this Antwerkz page which gives you a script for syncing your entire google svn repo to your local drive (just using standard svnsync, which isn’t something I’ve played with before, so this trick might be old news to you).

With my whole svn repo mirrored locally, I could run hgconvert file://data/gravl.svn gravl.hg and a few seconds later I was done! Follow that up with a hg push https://gravl.googlecode.com/hg/ and we’re up and running (with branches and full history!):

Gravl changeset history on google code

Great stuff. Really interested to see how I copy with a wholesale move to Hg. So far things are going great!

[Read More]

Netbeans {hearts} Mercurial -- With Screenshots

I’ve been learning Mercurial over the past two weeks and I’m really loving it. I’ve used git before, and had a bunch of issues with merges (my fault, not git’s - but troublesome none the less). I thought I’d have a good look at Mercurial to see what it offered.

I’ve got to say the learning curve with Mercurial has been awesome. I bought a copy of the book, which has helped with the headshift of working with distributed revision control. A side benefit is that I now understand git better as well :-).

One of my real interests in exploring Mercurial is the standard of tooling. I’ve been happy with TortoiseHg on Windows, and am comfortable with the commandline on OSX, but I was keen to see how the IDEs fare. These days I’m using Netbeans for Grails development, and the Mercurial support is just fantastic (and built in the basic install!).

First up, let’s have a look at the basic editor window.

The Netbeans Mercurial Editor window

Just like the normal Netbeans subversion support, the project explorer on the left marks modified files in blue, and new files in green. Any folder paths containing new/modified files have a small cylinder to let you know. All good visual cues. You can also see the Versions window active in the bottom right. This gives you a full list of your new/modified files for this project. You can right click to find out the deets.

The editor window itself contains markers for lines you’ve modified, which avoids a lot of the need to fire up a diff. When you’re ready to commit, you get a standard dialog:

The Netbeans Mercurial Commit window

With our commits all in place, all the colour scheme on our files revert to default black. But what if you need to do a more serious look at a file’s history? No problem, just the normal right click, / Mercurial / Show History, and you’ll have all the info you need. This dialog gives you the local repo revision number against each change, so it’s easy to get back to where you were later:

The Netbeans Mercurial History window

[Read More]

Bootcamp Assistant - How to overcome the files cannot be moved issue

You’re busy trying to use the Bootcamp Assistant to install a bootcamp partition on your shiny Macbook, when suddenly you’re greeted with the dreaded fragmentation dialog of death:

The disk cannot be partitioned because some files cannot be moved

So what does “The disk cannot be partitioned because some files cannot be moved” actually mean? I mean, I’ve got 25Gb free and I only want a 10Gb windows partition! The answer lies in fragmentation. OSX seems to want a contigious block of clean disk to write to, and fragments of your files are scattered across it.

I know what you’re thinking. “But it’s a Mac. I’ve got this fancy file system that isn’t prone to fragmentation”. Yeah, yeah. Well, dude, the crushing news is that you can fix the problem by defragmenting your hard disk then trying again, so I guess OSX isn’t as committed to defragmentation as you might suspect.

I’m sure there are many ways to defrag an OSX hard disk. I chose to fork out 20 Euro and make the problem go away using iDefrag. There may well be open source/free alternative out there (feel free to comment if you know of any – useful for other googlers who come on by). iDefrag does its best work when it’s not defragging the boot disk, so you’ll want to generate a bootable DVD to run it from. Fortunately it ships with the tool to generate that bootable DV for you.

iDefrag ships will a free product called “Coriolis CDMaker”. Stick your Snow Leopard disk in the drive, run the CDMaker app, and it will get busy generating a bootable DVD for you with iDefrag as the autorun. Stick your bootable DVD in the drive, restart OSX, and hold down the “C” key as the machine boots – and it will boot up your DVD and run iDefrag.

Defragging takes some time - mine took about 3 hours to run - but that’s a lot less hassle than reformatting and restoring my entire drive. After the defrag I could happily run the Bootcamp Assistant without any “some files cannot be moved” drama.

[Read More]

C# eye for the Java Guy

I’m sitting here sipping on a decaf and hacking on a large C# codebase. What has become of me?

Don’t worry, I’m not losing my religion, Java will always be my perfect dish (along with Groovy and Grails for the condiments). But often my consulting work takes me places where exotic dialects are spoken. Lately I’ve helped a client with a bunch of C++ and C# integration work on Win32. It doesn’t feel like home, but there’s some very interesting landscape here. I’ve enjoyed working the C# so much, it’s fast become my “learn a language” project - and I’m really getting into it.

So what’s to love?

Well first of all the language is remarkably similar to Java, but with all the features that should already be in there if they ever decide to actually modernise the JDK. Properties and Delegates (typesafe function pointers) dramatically and elegantly solve the whole event handling mess. Lambdas deal with a stack of the common use cases for closures in a format that groovy programmers will find very familiar. Ever operator overloading is employed cleverly. It hurts me to admit that Microsoft know what they’re doing here, but this is really a fantastic modern programming language! Enough faint praise.

So, you’re a Java guy who needs to get up to speed on C#/dotnet in a hurry? There’s a bunch of good resources that you need to get your hands on to get started. First go buy a good book:

Recommended to me by wmacgyver, this book has turned out to be a fantastic find. Wastes no time on “non programmer” content, but introduces the language, the libraries, and the frameworks in a deep dive manner (it’s a massive book at around 1300 pages – but it’s the only intro page that a Java guy is going to need to get started).

With a book to read and learn from, go grab a copy of Visual C# Express Edition - it’s a free download and runs fine inside of VirtualBox on OSX.

So where are all your familiar tools?

Anways, before I get too entrenched in all this Microsoft stuff, I need to retreat to some GPars for some Groovy parallel goodness. More here on that soon.

[Read More]

Maven Tip: Enforcing a JDK version in your build

You’ve just got to love the Maven Enforcer plugin. Anything with a byline of “The Loving Iron Fist of Maven” has got to endear you, no?

The Enforcer is a collection of configurable rules that will force your build to stop if certain preconditions are not met. One of the common ways I’ve been using it lately is to ensure that a certain JDK (1.4 in my case - don’t get me started on Websphere) is used when producing production artifacts.

I know what you’re thinking, just use the <target> config attribute to the compiler plugin? That would be true if the -target switches to the JDK compiler actually did what you think. But alas that is not the case unless you do funkiness with paths to the 1.4 runtime with a -bootclasspath option which sounds just too fragile and machine-specific. I’d prefer to just bomb out early if it’s not a real 1.4 JDK. I’m really dislike that java.lang.NoSuchMethodError stuff.

Anyways, here’s the build kungfu to ensure you enforce your preferred JDK:

<plugin>
    <groupId>org.apache.maven.plugins</groupId>
    <artifactId>maven-enforcer-plugin</artifactId>
    <version>1.0-beta-1</version>
    <executions>
        <execution>
            <id>enforce-versions</id>
            <phase>validate</phase>
            <goals>
                <goal>enforce</goal>
            </goals>
            <configuration>
                <rules>
                    <requireJavaVersion>
                        <version>[1.4,1.5)</version>
                    </requireJavaVersion>
                </rules>
            </configuration>
        </execution>
    </executions>
</plugin>

Putting the goal against the validate phase makes everything die early. However, you might want to bind to “install” or whatever if you’re happy to develop against a later JDK. Giving this bad boy a run on Snow Leopard will give you output like:

[INFO] [enforcer:enforce {execution: enforce-versions}]
[WARNING] Rule 0: org.apache.maven.plugins.enforcer.RequireJavaVersion
failed with message:
Detected JDK Version: 1.6.0-15 is not in the allowed range [1.4,1.5).
[INFO] ------------------------------------------------------------------------
[ERROR] BUILD ERROR
[INFO] ------------------------------------------------------------------------
[INFO] Some Enforcer rules have failed. Look above for specific messages
explaining why the rule failed.

Giddy up. Die early, die often.

I’m definitely making room for the Enforcer plugin in my Maven Quickstart Course running in Canberra next month. It’s gonna be a blast - and there’s still early bird pricing for the next week so if you’re interested in getting there, don’t forget to register early!

Enjoy the loving iron fist!

[Read More]

New and Noteworthy in groovyblogs 1.2

Well it’s finally happened! I’ve ported groovyblogs over to Grails 1.2 M2 - and it’s been a fantastic experience. The new Grails milestone has been totally awesome - I haven’t had to do any restarts during development! That has been sensational.

Firstly, and very importantly, I’ve been working with Matthew Porter’s team at Contegix to move groovyblogs over to the Contegix Zeus Cloud offering. All I can say is Wow! I never wait for than 5 minutes before I get a return email from someone on their team.

Previously groovyblogs has been running on an iMac in my office with 2Gb of RAM (along with a host of other Grails apps - including this blog). It worked great, but the machine would get swap-starved under load - since the move to Contegix, everything has been totally rock solid - I’m sure everyone will enjoy the increased uptime!

Now… On to the “New and Noteworthy” stuff… groovyblogs is now on twitter! It’s a little experimental and suffers from missing the odd post at the moment, but very usable. Just follow @groovyblogs to get the updates:

groovyblogs on twitter

And if the iphone is your thing, you might want to checkout the new iphone view which should be lots faster and more bandwidth-friendly than the main page:

groovyblogs on iphone - list view

groovyblogs on iphone - entry view

The most requested feature for groovyblogs was the ability to see an “English only” view. Well, it’s out there now! Check out the new prefs page on the right hand gutter:

[Read More]

opencsv 2.0 released and mavenized (Sonatype totally rock!)

People who follow opencsv will find this hard to believe – but it actually happened! Thanks to a whole lot of work from Scott Conway, a whole slew of patches have been applied to opencsv 2.0 is out in the wild! Scott has fixed heaps of the outstanding issues, so if you’ve opened something, make sure you check back to see if it made it in (it probably did!). We’ll have some formal release notes up there soon.

At the same time as Scott was patching, I took the chance to Mavenize the project as a good sample for my little Maven Quickstart course. Getting stuff into Maven Central has traditionally been a bit of a pain, but the good folk at Sonatype now have a fantastic Nexus setup that mirrors to central frequently (opencsv went from the Sonatype Nexus repo through to central in under 10 minutes - apparently the servers are in the same rack!).

Go and check out this Sonatype blog entry to get the skinny. Basically, you post a JIRA requesting access, they email you a username, password, and a set of repo address. Deploy your app, and they’ll sort out the sync to Central for you.

The only tricky part of the process was implementing the required GPG signing using the gpg plugin, but other than that life was grand! Have a look at the opencsv pom for sample usage. I could install the gpg binary via macports, and use a gpg quickstart to workout how to generate and export keys.

I’ve been a big fan of Nexus as a repository manager for ages. But what they’ve done with this central setup has been a huge boon for opensource projects wanting to sync up to central. Makes the process totally straightforward.

Awesome job Sonatype!

[Read More]

A first taste of Memcache

I’ve been wanting to have a look at memcached for a while. A lot of people swear by it for distributed caching, and it’s now part of Google App Engine’s infrastructure, so I figure it was worth taking a look what’s doable.

If you’re coming from a Java background, you’re probably familiar with ehcache or some similar caching library - basically a key/value store of elements which timeout after a certain period.

Memcache provides a similar capability, but out of process to your app server. You run memcached on your server (as a standalone process), and your clients communicate with it over sockets. This makes it way slower than an in-process solution, but it does give you some resilience to app server crashes and whatnot. Also means you can run central caching infrastructure that all of you clients talk to - or even take advantage of memcache’s distributed caching infrastructure.

memcache is available on all the major platforms. I just installed it via macports (port install memcached) then kicked it off in daemon mode with the defaults via memcached -d.

With the daemon up and running, it was time to explore some memcached java clients APIs. The one I settled on was the spymemcached approach. Super simple API, and some great samples to get you up and running.

Getting things into and out of the cache from groovy looks something like this:

import net.spy.memcached.*

// constructor takes the host and the port of your memcached server
// (or an array if you have a cluster for failover)
MemcachedClient c=new MemcachedClient(
    new InetSocketAddress("localhost", 11211))

// "add" only puts it in the store if the key doesn't exist
c.add("sample", 10, "test");

// "set" forces the value in regardless of the store
c.set("mapper", 20, [ a: 10, b: 20 ])

// Retrieve a simple value (synchronously).
println c.get("sample");

// But complex objects work great too
c.get("mapper").each { println it }; 

// You can delete stuff too
c.delete("mapper")

// And get some stats off the cache server
println c.getStats()

I’m using the cache to hold thumbnail data for groovyblogs.org - which saves sticking anything in a database (but is still safe for restarting the appserver on new version installs).

As for Grails integration, you probably want to create a simple Spring FactoryBean so you can easily inject the MemcachedClient wherever you need it. I put together something like this:

import org.springframework.beans.factory.config.AbstractFactoryBean
import net.spy.memcached.*
/**
 * A simple factory bean for Memcache Clients.
 *
 * @author Glen Smith
 */
public class MemcacheFactoryBean extends AbstractFactoryBean {

    String host
    int port

    public Object createInstance() {
        return new MemcachedClient(
             new InetSocketAddress(host, port))

    }

    public Class getObjectType() {
        return MemcachedClient.class
    }

}
[Read More]

Maven is the new black: Canberra JUG Presentation, Wed Aug 12

If you’re around Canberra on Wednesday, August 12, make sure you drop by the Canberra Java User Group (CJUG) from 6PM where I’ll be giving a talk title “Maven is the new black”. Maven has really been gaining popularity lately in the Java ecosystem, so it’s a good chance to come along and hear what all the fuss is about.

Maven is full of features, but often a little short on “getting your head around it” material, so I’ll be giving a short 30 minute talk which just takes you through the basics of the core stuff you need to explore and gives you some demos of the benefits. On the list is a thumbnail sketch of:

If you’re keen to go a bit deeper and actually learn how to apply all this stuff to real projects, I’ll also be offering a one day intensive title “Maven Quickstart“ which I’m offering on October 22 in Canberra. It promises to be a really fun day with heaps of challenging lab exercises while keeping things fun and practical. If there’s interest, I’m hoping to offer it in Sydney, Melbourne, and Brisbane, since there seems to be a real shortage of Maven training options here in Oz. Talk to me if you have people in your space that could benefit.

Anyways, If you’re in town, see you for Pizza and Maven next week!

[Read More]

Getting Groovy with Google Language Translation APIs

One of the most requested features for groovyblogs is the ability to filter posts by language. Well I’ve been working hard to get this implemented. I wrote ages ago how the first version used the Textcat classification library to do some of the heavy lifting, which worked fine, but only had a small set of languages.

I was mentioning this to my buddy Sven and he suggested I checkout the Google translation AJAX APIs that are now available - and even sent me a code snippet to get me going.

Turns out that accessing these services from Grails is a total snack. Here’s a complete worked example of how you can integrate both language detection and translation in a tiny amount of Groovy code (feel free to cut and paste into your local groovyConsole and take for a spin):


def text =  'das ist ein test'.encodeAsURL()

def detect = 'http://www.google.com/uds/GlangDetect?v=1.0&q=' + text
def response = grails.converters.JSON.parse(detect.toURL().text)

println "Lang is: ${response.responseData.language}"

def targetLang = "en"
def translate = "http://www.google.com/uds/Gtranslate?v=1.0&q=" + text +
    "&langpair=${response.responseData.language}%7C${targetLang}"
def response2 = grails.converters.JSON.parse(translate.toURL().text)

println "Translation is: ${response2.responseData.translatedText}"

Which gives you the expected output of:

Lang is: de
Translation is: This is a test

Cute stuff! Language detection and translation in just a few lines! Coming soon to a groovyblogs near you…

[Read More]

Skinning Confluence with your own look and feel

I’ve recently decided to move (my very simple) business site over to Confluence. Now Confluence is really a wiki, right? So treating it like a real CMS means you’re going to hit limitations. But Confluence is not “just a wiki”, it’s one awesome wiki! So I’m willing to endure a little pain for my public facing site so I can use the same wiki for my internal docs in all their wiki’d goodness.

The only real problem is the Confluence looks like a wiki. The default look and feel for Confluence look something like this:

The default Confluence look and feel

Certainly not shabby, but it don’t really convey a sense of business identity. Hacking custom themes and templates are certainly possible out of the box (if you don’t mind a little velocity work), but I’m really not keen on copying my custom templates into the actual Confluence WAR file for deployment.

Enter the Adaptavist Theme Builder. This awesome confluence plugin gives you a uber-configurable theme to make your Confluence space look like anything you want!

They’ve gone the extra mile too, giving you lots of stuff that only a geek could want - like custom favicons, custom metadata elements, custom Javascript and CSS imports, a bunch of new CSS classed container elements to style, and the ability to add or suppress tons of standard page elements (like the space name, site name, etc). Really first class effort - and completely free. Check out the Adaptavist site for an example of a Wiki that doesn’t look anything like a wiki!

Anyways, I’ve been working hard to try and make www.bytecode.com.au not look like a Confluence site. My mediocre design skills aren’t helping, but it’s already a long way there.

The Bytecode home page - hopefully not too Confluency

I reckon there’s a market for design people who know how to work with Confluence and can do a cradle-to-grave integration of art and design straight into your public facing site. Theme Builder is probably the bridging tool that could make that possible. Until then, I’ll keep plugin away on my daggy CSS skills and I’m sure I’ll end up with something at least half decent!

Great job, Adaptavist. Theme Builder is just awesome!

[Read More]

Grails Jabber plugin (finally) goes out the door

Well… I made a promise to myself that my theme for this year would be “the last 20%”… Finishing off all those half-finished jobs (both online and around the house). Now that Grails in Action is out the door, it’s time to ante up.

First on the list is my Grails Jabber plugin. This plugin gives you a quick way to both send and listen on a Jabber account (check out the online docs for details and samples). It’s used in Chapter 12 on messaging and scheduling, but never actually made it out the door and onto the Grails repo.

The source for the plugin lives on github, and every time I tried to do a grails release-plugin there was a world of stacktrace grief.

Importing project to
    https://svn.codehaus.org/grails-plugins/grails-jabber.
Please wait...
org.tmatesoft.svn.core.SVNAuthenticationException:
svn: Authentication required for '
  grails-plugins primary Subversion repository'

The only trouble was, nothing was prompting me for a username/password, so I was a bit hosed. Turns out that this thread gave me a bunch of insight into a workaround (though it seems like a pretty rare issue - I must just be lucky). So I thought I’d write up the solution for future google-ability.

You need to create a file in your home directory under ~/.grails/settings.groovy with the following magic entries (it’s really just setting up a custom grails repo, but pointing it to the existing plugins repo ):

grails.plugin.repos.discovery.grailsplugins=
   "https://svn.codehaus.org:443/grails-plugins"
grails.plugin.repos.distribution.grailsplugins=
    "https://svn.codehaus.org:443/grails-plugins"

With the magic entries in place, you can do a grails release-plugin -repository=grailsplugins and it will force grails to use the custom repo settings. Voila! Prompts for usernames and passwords return and things are happily deployed to the plugins repo!

Righto. With that one crossed off my list, it’s time to return to my experiments with GroovyBlogs2 and Gravl2 which are both badly in need of some “last 20%” love…

[Read More]

The Grails Podcast BOF (and other JavaOne G3 catchups)

Just a quick reminder that if you’ve coming to JavaOne 2009, make sure your drop by Grails Podcast BOF-3979. We’re going to be having a ball giving a Groovy/Grails/Griffon view of JavaOne, talking with a bunch of key players in the community, including Scott Davis, Dierk Koenig, Danno Ferrin, Andres Almiray, James Williams and others. We’ll be giving away books and other swag which is currently being printed..

During meal breaks, make sure you track down the “Groovy table”, where you’ll find me, Sven, Dave Klein, and others. You’ll know us by our terse-yet-expressive syntax and our perfect interoperability. :-)

For those of you staying at (or near) the Sir Francis Drake hotel, make sure you drop me a direct on twitter glen_a_smith or the email address on the right. Would be awesome to catch up for breakfast and talk groovy-related stuff.

Oh. Our BOF is running on Thursday from 19:30-20:20 at Esplanade 307-310, Moscone. Look forward to seeing you there.

[Read More]

Grails in Action: It is finished!

At 12 months of insane workload, Grails In Action (aka SanGria) is finally off to the printer! It’s awesome to finally have some time and headspace again after such a long slog of going over and over the manuscript with tons and tons of edits. But I’m so happy with the end result!

Glen feeling Groovy at the beach

Peter and I have always had a vision to write an “in the trenches” Grails book that would help people get up and running quickly, and cover a lot of the practical corner cases that developers face when transitioning to Grails. We couldn’t be more happy with the results.

Manning put an insane amount of effort into their books. Peter and I worked closely with a Manning Dev Editor (Cynthia Kane) would did an amazing job getting us focussed on the “Do people need to know this?” questions. There was a lot of stuff that hit the cutting room floor (you know what it’s like to throw code away, right? Imaging throwing away dozens of pages of stuff you’ve written? That hurts!).

Then there were the numerous fixes that turned up when Burt Beckwith reviewed the book for technical accuracy. Then the copy editor (Andy Carroll) starts his work - fixing nearly every sentence in the book. Finally the proof reader (Maureen Spencer) goes over it again (a few times) to make sure everything is accurate. It’s pretty exhausting just watching! I’ll blog up the process of writing a book in a future post. It’s an interesting exercise in personal discipline if you’re so inclined (I’m not the insanely disciplined type, so it was extra hard).

People who have pre-ordered the book through the MEAP (Manning Early Access Program) will get an updated copy of the manuscript (with all the correct formatting goodness) around May 20. The book will be available in hardcopy around May 30 and will debut at JavaOne on June 2! I’m see if I can rustle up a few to give away at the Grails Podcast BOF on Thursday night at JavaOne! Make sure you’re there!

It’s time to put my feet up and relax for a while!

[Read More]

Retrofitting JSecurity to your existing tables

I’m marching through a pretty large groovyblogs refactor, with the goal of tidying up the codebase considerably. I’ve made a move to the JSecurity plugin so I can add a “remember me” feature, which paves the way for more a more sophisticated “preferences” subsystem down the track.

The only problem was that I already has an Account table which contained passwords (base64 sha1) and a role column (string). I really wanted JSecurity to use my existing Account.password and Account.role fields when constructing it’s user subject since I didn’t want a massive migration job on my hands. There also wasn’t really a need for all those JSec* domain objects since I already had the data I needed in my Account table.

Fortunately JSecurity supports custom “Realms” - so I could plug in a new authentication substem that uses my existing table structure, but expose it all to JSecurity’s subject, principal, and role context. I just needed to supply the appropriate methods to my new Realm and I was in business. For example, since my roles were implemented as a simple String, implementing role integration with JSecurity was a matter of providing my realm with:

def hasRole(principal, roleName) {
        return Account.findByUseridAndRole(principal, roleName)
    }

As for the authentication portion, I also provided my own authenticate routine to look after the convension to base64 SHA1 since none of the standard JSecurity CredentialsMatcher implementations seemed to handle that (though in a future iteration I could probably simply extend and customise SimpleCredentialsMatcher to handle it pretty quickly). With my authenticate routine in place, there was nothing more to do but start using the JSecurity tags! First up was to a basic filter to catch the secured actions:

import org.codehaus.groovy.grails.commons.ApplicationHolder

class SecurityFilters {

    def filters = {

       accountOperations(controller: "account", action: "(index|edit|update|deleteFeed|addFeed|testFeed)") {
            before = {
                accessControl(auth: false) {
                    role("user") | role("admin")
                }
            }
        }

    }
}

All the role tags just work out of the box, since the Realm does all the heavy lifting of converting my role strings to JSecurity Role objects. The only thing that proved tricky is getting the “remember me” stuff happening for cookie authentication.

JSecurity treats users who authenticated “directly” as a different story to those who authenticated via a “remember me” cookie. If you want your filters to handle either, you’ll have to set that “auth: false” property on the accessControl check as shown above.

The last piece of the puzzle is implenting the tags for conditional display of the appropriate tab. In order for things to work for both remembered and directly authenticated user, I needed to user jsec:user and it’s mate jsec:notUser:

Alrightly, with security knocked over, it’s on to some “endless page” action for the home page ala DZone. I’m thinking of having a look at the jQuery endless page plugin to see if it fits the bill. Good chance to get up to speed on jQuery at the same time. Seems to be all the rage these days.

[Read More]

Adding iPhone support to groovyblogs

Since being given an ipod touch, I’ve been keen to explore the issues with designing for iphone web apps. With Grails In Action in final copy edits, I’ve finally got some free time to invest in a big refactor of groovyblogs.

I’ve already reworked the security system to use JSecurity, moved all the custom search logic over to Searchable, and fixed the dread “numerous repost” problems when people mess with their feedburner/blog software/etc. It’s now checks the hash of the post content to perform more reliable duplicate checking that is independent of whatever their blogs software assigns to their “permalink”.

If you’re keen to tinker with developing websites with iphone support, and you don’t have a device, you can still use emulators to get a feel for what’s possible. I’ve been working with iPhoney which gives you a pretty good sense of what the site will look like - including the ability to rotate the device. Here’s what my new groovyblogs iphone menu page looks like on the iPhoney emulator:

groovyblogs on an ipod emulator

Now, on to the meat of implementing this sort of stuff. Grails supports plugins for both iUI and iWebKit (two of the main iPhone development libraries). Given the wealth of documentation available for iWebKit, I thought I’d take that for a spin first. The iWebKit plugin has some docs online, but the best way to get familiar with it is to watch the great screencast on getting started.

After following the screencast, I was ready to go. I whipped up my page using the taglibs and I was up and running. You have to set the layout template name of your page to be “iphone” - after that you just use the tags and enjoy the styling. Here’s the body of the new ipod homepage shown above:

<iphone:topbar title="groovyblogs">
            <iphone:leftnavigation navtype="button">
                <iphone:navelement action="pc" content="PC Website"/>
            </iphone:leftnavigation>
        </iphone:topbar>
        <iphone:content>
            <iphone:section>
                <iphone:list action="show" descriptionField="title" list="${entries}"/>
            </iphone:section>
        </iphone:content>

My first gotcha was that you’ve got to copy the /layouts/iphone.gsp from the plugin installation into your Grails app. The plugin page notes this saying that this would be fixed in Grails 1.1. No such luck. That still applies.

The iphone:list tag iterates over each of the entries in ${entries} and creates a menu item name ${entry.title} which is linked to the “show” action of the current controller. The id is also passed in. Once you’ve done that you get a nicely rendered menu page complete with a swipey link, rollovers and right arrow link. Here’s the same page running on my device:

groovyblogs on an ipod

[Read More]

Grails In Action, Free Sample Chapter, Grails Podcast BOF at JavaOne... Phew!

It’s been a hundred years since I last blogged, but I’m now officially “back on the horse” for blogging in ‘09. The reason is that Grails In Action has gone into copy and technical edits, so I have most of my life back! If you’re keen to get a feel for what Grails can do, go grab the sample chapter to learn Grails in a hurry! We’re on track to have the final one available for a book signing at JavaOne, but you can sign up early and get the PDFs as they develop.

I’m also super excited that Sven and I will be hosting a Grails Podcast “Groovy and Grails BOF” at JavaOne 2009. It looks like it’s going to be on the Thursday night, so keep it free for a fun night of Groovy, Grails, and free stuff! I’m staying at the Sir Francis Drake hotel in SF, so if you’re a Groovy/Grails hacker in town for JavaOne we should catch up for Breakfast!

Writing a book sucks up an insane amount of time, so I’m looking forward to spending the rest of the year tidying up a slew of half finished projects. Full of ideas for groovyblogs v2, and have tons of ideas for an updated version of Gravl (the blogging software that powers this blog).

But first it’s time for some downtime… Off to feed my chickens….

[Read More]

A Cute TinyUrl Codec

I’ve been hard at work finishing the Controller chapter for San Gria and wanted to come up with fun and practical encoders example.

Our main example app for hubbub is a twitter clone, and as I was working on the UI, and I was thinking “I wonder if we could add a TinyUrl facility? Actually, how about a TinyUrlCodec? Could probably do it in a one-liner, right?”

class TinyUrlCodec {
    static encode = { fullUrl ->
        new URL("http://tinyurl.com/api-create.php?url=${fullUrl.encodeAsURL()}").text
    }
}

Which makes the controller implementation a snack!

def tinyurl = {
    def tiny =  params.fullUrl.encodeAsTinyUrl()
    log.debug "Encoded ${params.fullUrl} to ${tiny}"
    render tiny
}

But you’re keen to see it in action, right?

A TinyUrl codec in action

But I’m going to need a little AJAX sauce to integrate the remoteForm with the dynamic adding to the textarea…

<g:form style="padding:1em; border: 1px dotted black; ">
 TinyUrl:
 <g:textField name="fullUrl"/>
 <g:submitToRemote action="tinyurl" onSuccess="addTinyUrl(e)" value="Make Tiny"/>
</g:form>

With some matching Javascript goodness to catch the XmlHttpRequest…

[Read More]

Pausing and Resuming Quartz Jobs Programmatically

I’m working on the chapter on Messaging and Scheduling for San Gria (Chapter 14), and I’ve finally had a chance to explore some parts of the sensational Grails Quartz plugin that have been on my to-do list for ages. I’ve had a good explore of non-re-entrant jobs, passing state between jobs, programmatically dealing with jobs, and now I’m having a look at the db-persistent jobs.

One thing that I’ve wanted to explore for the longest time is the ability to pause and resume jobs programmatically via a UI. For example, before I converted groovyblogs.org to a messaging architecture, I was really keen to add an admin UI to pause and resume polling of jobs (for instance when I was doing deploying a new version of the browser snapshot service). Now I know how :-)

First off, if you’re going to be doing programmatic stuff with your jobs, you need to put them in a group (yes you can use a default group, but it makes things easier to follow). Here’s our sample:

class ControllableJob {

    def timeout = 5000 // execute job once in 5 seconds
    def concurrent = false

    **def group = "myServices"**

    def execute() {
        println "Controllable Job running..."
    }
}

Ok, With our job named, we can do all sort of pausing and resuming operations. Let’s whip together a quick UI to post our list of operations in a “operations” field:

A Quick and Dirty Job Admin UI

To take advantage of the quartz scheduler operations, you need to do a “def quartzScheduler” to get the injection happening. After that, you have a wealth of Scheduler interface methods to work with. Here’s our controller method:

    def show = {

        def status = ""

        switch(params.operation) {
            case 'pause':
                quartzScheduler.pauseJob("ControllableJob", "myServices")
                status = "Paused Single Job"
                break
            case 'resume':
                quartzScheduler.resumeJob("ControllableJob", "myServices")
                status = "Resumed Single Job"
                break
            case 'pauseGroup':
                quartzScheduler.pauseJobGroup("myServices")
                status = "Paused Job Group"
                break
            case 'resumeGroup':
                quartzScheduler.resumeJobGroup("myServices")
                status = "Resumed Job Group"
                break
            case 'pauseAll':
                quartzScheduler.pauseAll()
                status = "Paused All Jobs"
                break
            case 'resumeAll':
                quartzScheduler.resumeAll()
                status = "Resumed All Jobs"
                break
        }

        return [ status: status ]

    }

Notice that the pause() and resume() for individual jobs take the full name of the job (“ControllableJob”) as the argument. Notice also that the Groovy switch statement is insanely useful - you can even mix string and integers in the case statement if your switch var is dynamically typed - awesome! (more info).

Anyways… must get back to exploring the database persistent options for quartz jobs so I survive a restart if need be! The end of Chapter 14 is in sight, and those people who have pre-purchased the book via the Manning MEAP program should get it towards the end of the next week/early following week. And we’ll have another 4 chapters going out in time for Christmas!

[Read More]

San Gria Update: Mapping the Legacy Db from Hell

For those of you wondering how Grails in Action is progressing, the answer is… great! I’ve been sick for the last month with pneumonia which, as you can imagine, has slowed things down a little my end :-).

The good news is that we’re on track for a 2/3 review next month which should see a whole bunch of new chapters out in the wild. I’ve finished the one on messaging and scheduling, Peter has new work describing the overhauls Plugin mechanisms and Testing capabilities in Grails 1.1, and I’ll have Part II finished which we’re reworking as a “Scratch to Productive” section for the Java developer transitioning (but there’s lots of fun and interesting stuff planned in there for even the seasoned Grails dude).

One of the things that came out of our 1/3 review was better coverage of legacy db issues, so there’s a whole new section of the “Advanced GORM Kungfu” chapter (8) dedicated solely to this. Based on some work I’ve been doing in the real world, the section is called “Mapping the Legacy Db from Hell”. It looks something like this:

A legacy db model

This bad boy gets very deceiving under the covers. Some of those many-to-manys have attributes on the join table, there are tons of key styles (including assigned and increment), there are various primary key types (including shorts and even chars!), there’s even denormalised relations, and to top it all off the naming is style by DBA hungarian. It’s pure evil. Check out the mapping file for a glimpse inside the madness.

Anyways, in the new section we walk you through using your existing hbm.xml file with some standard POJO DTOs, then, if you haven’t run screaming from the building, we do the mapping over with GORM legacy DSL. It should certainly give you a pretty complete picture of what’s doable!

I’ve already completed the hibernate mapping section, which you can pull from the Ch08 San Gria code on github. I’m working the GORM DSL stuff over the coming week. It should be a ball!

Feels so good to be well and back on the blogosphere! Health is a beautiful thing…

[Read More]

A Grails Jabber Plugin

For the Messaging chapter in San Gria, I needed a good example for our Twitter clone, hubbub. The one I ended up with was a simple Jabber gateway.

You can send messages from your jabber client directly to your hubbub account, and they’ll become part of your Post history. Here’s the beast in action. Sent from a Spark jabber client in the foreground to the hubbub webapp running in the backend:

Jabbering into Hubbub

The Jabber gateway listens on the hubbub user’s jabber account (based on some good work on the feedlr blog), slurps off any incoming jabbers, and places them on a JMS queue. In due course, hubbub takes those incoming queue messages and puts them on the Post history of the user with that jabber id in their profile. Eventually hubbub will let you go both ways - jabbering you your friend’s posts as well.

But for all that to work, you need a Grails app to act as the Jabber gateway. Now with a Jabber plugin, that all becomes pretty straightforward. Here’s a 20 line Jabber gateway for your next social networking app which shuffles things between a JMS queue and a Jabber account:

class GatewayService {

    static expose = ['jabber', 'jms']

    static destination = "jabberOutQ"

    def onMessage = { msg ->

        log.info "JMS from: ${msg.userId} to: ${msg.to} content: ${msg.content}"

        def addrs = msg.content.split(",")
        addrs.each { addr ->
            log.debug "Sending to: ${addr}"
            sendJabberMessage(addr, msg.content)
        }

    }

    def onJabberMessage = { jabber ->

        log.info "Jabber from: ${jabber.from} with body ${jabber.body}"
    def jabberClientsDeets = jabber.from.split("/")
        def msg = [ jabberId: jabberClientsDeets[0],
                      content: jabber.body,
              jabberClient: jabberClientsDeets[1] ]
    log.debug "About to send: ${msg.dump()}"
        sendQueueJMSMessage("jabberInQ", msg)

    }

}

I know just about 0 about plugins. I’m going on what I’ve learned from Peter’s chapter on Plugin Development in Grails in Action (which is just a super chapter for you hardcore dudes, btw) - along with the sample code lifted from the uber-cool JMS plugin. The reason it’s not on grails.org yet is that I’m not up to the bit on how to publish plugins yet!

I’m in the process of getting the plugin published on grails.org, but the source is available now on github (along with a Wiki doc describing its use). So feel free to download and do a “grails package-plugin” to get the zip you need. Or just hang out until I learn how to do a publish. ;-)

Happy Jabbering!

[Read More]

groovyawards goes into the judging phase...

Thanks so much to everyone who participated in the first annual groovyawards. It was awesome to have so much positive feedback by and for so many of the Groovy and Grails community. For posterity, here’s the final nomation tagcloud:

The Final Groovyawards Nomination Tagcloud

Congratulations to everyone who was nominated for an award. For the next phase we have circulated the final names around a group of Groovy and Grails luminaries for their input. We are hoping to announce the winners on the next Grails Podcast.

Here’s the final click and nomination count:

name                     page_views  noms
-----------------------  ----------  ----
Graeme Rocher            327         18
Glen Smith               338         14
Scott Davis              173         9
Dierk Koenig             102         7
Dave Klein               202         7
Marcel Overdijk          119         6
Burt Beckwith            184         6
Sven Haiges              225         6
Andres Almiray           123         5
Peter Ledbrook           74          5
Danno Ferrin             57          4
Guillaume LaForge        61          4
Geertjan Wielenga        64          4
Marc Palmer              66          4
Jason Rudolph            65          4
Paul King                55          3
Jeff Brown               66          3
Venkat Subramaniam       74          3
JetBrains                76          3
Nacho Brito              53          3
Jay Zimmerman            62          3
Jochen Theodorou         101         3
Michael Kimsal           48          3
James Ervin              66          2
Ted Naleid               70          2
Dmitriy Kopylenko        77          2
Matt Taylor              83          2
James Williams           47          1
Les Hazlewood            47          1
Robert Fischer           38          1
Alex Tkachman            62          1
The Pragmatic Bookshelf  79          1
Marc Guillemot           34          1
Sergey Nebolsin          33          1
Ken Kousen               51          1
Russel Winder            61          1    

Now… we just need to work out how to get that pacman SVG onto a trophy…

[Read More]