G'day! I'm Glen

Peter and I have been working hard on Grails in Action, and we’re tracking pretty well. We’re nearly 200 pages in, and for a couple of amateur authors (and in my case, amateur Grails developer!), we’re doing ok!

But I think you’re probably more interested in what’s out there so far. Here’s the short summary:

• Chapter 1. Grails Quickstart. In our intro chapter, you get a very fast-paced intro into all of the core parts of Grails. You build an Ajax-powered QOTD application and along the way learn develop a model, view, controller, layout, taglib, service & testcase. It’s fast and furious, but experienced developers will appreciate the pace.
• Chapter 2. Groovy Quickstart. Everything a Java developer needs to know to transition to Groovy/Grails. Peter wrote this and I learnt a ton of things along the way. We originally debated about moving this to an appendix, but I’m so glad it made it to the book proper. Even if you’ve already developed a bunch of Grails apps, there stuff to learn here.
• Chapter 3. Life after SQL. A Domain-centric deep dive into Grails “core stuff”. We introduce the sample application (hubbub, a twitter clone), and we set to work developing a signup feature for it. I didn’t want this to just be a “domain models” chapter, because you should learn Grails naturally - with model, views and controllers interacting - so we make quite a few detours along the way into related areas. You’ll learn all the common relationship types, play with custom validators, dynamic finders and QBE.* Chapter 7. Extending Grails with Plugins. Peter knows more about plugin development internals than just about anyone, and this chapter shines with that. Lots of good info around interacting with Spring, and tons of stuff that you just won’t find anywhere else.
• Chapter 8. Advanced GORM Kungfu. This is the “less common” GORM features that I didn’t want to clutter chapter 3 with, but did want to spend time explaining. You’ll be playing with domain class inheritance and polymorphic queries. There’s also quite a bit of discussion around performance profiling (p6spy & Hibernate JMX stats) and then how to improve it via custom cache configuration (uses ehcache as the basis since it’s what I know). We then explore Criteria Queries (including hibernate projections and query caching) and HQL. Finally we tackle some legacy issues (Multiple data sources, Hibernate mappings and GORM DSL). There will eventually be stuff on transactions, locking and data migration in this chapter, but that can wait till the 2/3 review.

It’s going out for review today, so I look forward to ego-destroying feedback (my discouragement threshold is insanely high, so feel free to be candid. Some of the original proposal reviewers told me “there’s no way Glen will pull this off”. I think I’ll send them a free copy at the end :-)

How has the writing process been so far? Harder than I thought. The most difficult part has been thinking like a new reader. I started writing in the same style as my blog, but that doesn’t work for a book. After the early reviews I realised that each chapter was full of “separate” blogs rather than flowing as one cohesive whole. I’m still working that through (and the reviewers will probably find that frustrating, but it’s a journey for us wanna-be authors too!)

There’s still a lot of work to do turing our first chapters, but both Peter and I are so happy to have something out in the wild! Next up are the controllers and advance view technique chapters. I’m already having fun working on some funky image resizing/caching for hubbub:

Those on the MEAP programme should get early access by the end of the week. If you subscribe, make sure you leave candid feedback on the author forum since we really want to improve the final book for you guys.

Anyway, time to take a few days off to decompress and play with Griffon :-)

Just a quick note to say the source code for groovy awards is now on github under an Apache2 license. Go forth and clone! It’s a tiny app - sans plugins - so you should be able to get your head around it by a quick browse of the NominateController.

When I get a bit more downtime I’ll write up some of the trickier bits. I’m particularly happy about is how the browse page highlights only those letters that have matching entries. It’s implemented pretty inefficiently at the moment… but it does work.

Today I also added a tagcloud of comment numbers for each nominee. Turns out that I could do this with a single Criteria query taking advantage of Hibernate Projections. Here’s the final query from the “home” action:

        // build data for tagcloud using a projection
        def resList = FanBoy.withCriteria {
            createAlias("nomination", "n")
            projections {
                groupProperty('n.name')
                count('id')
            }
        }

        // projection returns a list of name,count -- but tagcloud needs a map. Convert it here.
        def commentMap = resList.inject([ : ]) { map, res -> map[ res[0] ] = res[1]; map }

Hibernate projections are uber-powerful for grouping and reporting operations. I’m only just getting a feel for them, but they will feature in the “Advanced GORM Kungfu” chapter of Grails In Action. (I really hope they let me call it that in the final book… :-)

I’m glad so many of you are contributing to the site. It’s been great to hear so much positive feedback for so many in the community. You guys rock!

Sven and I have been keen for a while to run a small community-driven awards programme to honor those guys who’ve been working hard on the lists, on the blogosphere, writing plugins, committing, twittering and generally evangelising the platform, and we’ve taken the first step. Announcing the official launch of:

If you head over to groovyawards.org, you can signup, nominate people, and add comments to existing nominations. We’re running it for a month to get a good vibe of the community. We’ll be getting together with a few luminaries at 2GX to finalise the choices, and then we’ll arrange some small way of acknowledging the final list.

It’s my birthday today - so I’m kicking back with family! But I’ll be getting the source up on github later in the week as soon as I get some downtime.

What are you waiting for? Go nominate someone!

A while back, I started talking about this idea for the Grails Podcast to run a “Groovy Awards” to recognise those people in our community that do an awesome job on the mailing lists, blogosphere, releasing plugins, and all that jazz. No big prizes - just some cheezy TShirts with a lot of love from the community.

Well I’ve had a few nights off this week, so I finally got around to putting together a super simple site to handle the process. Also gave me a chance to play with JSecurity Plugin (for admin tasks) and the P6Spy plugin (for database profiling). Both totally awesome. Will blog those up separately.

I’m 90% there on the skeleton. Just need to workout a moderation strategy (maybe don’t even need one? Really just to stop bot spam). Anyways the CSS still needs some work, but…

Anyways, I’ll post the progress up on github RSN if you’re keen to follow along. It’s just over 300 lines, so it’s pretty bare bones. More info once it goes live and you can have a play… Give me a week…

Well… it had to happen. After a week of people signing up twitter feeds and feedburner feeds from groovyblogs itself, I took some good advice from James, and implemented feed moderation. When you sign up your feed to groovyblogs, you now get a message saying

Behind the scenes groovyblogs will now send me an email with your feed url and an opportunity to approve/deny your feed signup with a single click (so it’s pretty low impact for me, given that we only get a couple of signups a week):

Next on the list is to work out how we can filter out the numerous duplicates we get from downstream aggregators. I could do some sort of title-based algo, but it might result in false positives - filtering out the original author’s post and leaving the aggregator’s copy. Or worse, skipping original unrelated posts with the same title.

Or perhaps I could do content matching. If the first para of this post appears in any other recent post, just keep the oldest one? Sounds more expensive… but may be doable…

If people have any good ideas here, let me know.

When we last left this story, I was talking about integrating Grails and JMS so that groovyblogs can put all of its feed and thumbnail fetch requests on a JMS queue. Now it’s time to look at the second half of the story. How my standalone groovy feed/thumbnail fetcher can pick requests off the queue, and put a response back on a different queue.

First a little background. Spring makes writing message driven POJOs really tidy. Groovy makes it even tidier. To implement a POGO (Plain Old Groovy Object) that listens on given Queue, I just have to implement the MessageListener interface, and provide an onMessage routine. Spring will setup the necessary background thread poller that will invoke my bean when a new message arrives on the queue. It will also look after the connection pooling to my JMS server so I’m not creating/dissolving connections every time. Nice.

But if I want to put something on the queue? Then it’s time to use Spring’s JmsTemplate class which provides the necessary convertAndSend that I’ll need to put my Map object back on the queue with my thumbnail result. The rest is just Spring wiring. Let’s take a look at the code for my ThumbnailListener first:

package org.groovyblogs.queue

import javax.jms.MapMessage
import javax.jms.Message
import javax.jms.MessageListener
import org.apache.log4j.Logger

import org.springframework.jms.core.JmsTemplate

/**
 * Listener for Map messages containing a URL to fetch.
 *
 * @author Glen Smith
 */
class ThumbnailListener implements MessageListener {

    private static final Logger log = Logger.getLogger(ThumbnailListener.class)

    JmsTemplate jmsTemplate
    ImageGrabber imageGrabber

    public void onMessage(Message message) {

        MapMessage map = (MapMessage) message
        String url = map.getString("url")
        String blogEntryId = map.getString("id")

        println "Got Thumbnail Request for: ${url} for ${blogEntryId}"

        def thumbs = imageGrabber.getImages(url)

        sendReply( [ id : blogEntryId, url : url,
            bigImage: thumbs[0].encodeBase64().toString(),
            smallImage: thumbs[1].encodeBase64().toString() ] )

    }

    public void sendReply(Map map) {
        try {
          jmsTemplate.convertAndSend(map)
        } catch (Exception e) {
           log.error("Error sending reply to thumbnail queue", e)
        }

    }

}

Wow. The whole receive, gather, and send takes about 20ish lines. Of course, we’re going to need a few things injected, right? We’ll need our JmsTemplate injected, and it will need to be wired up to our JMS endpoint (in my case, an OpenMQ queue). We’ll also need to inject whatever class implements our ImageGrabber interface (but that’s for another day).

Finally, we need to tell Spring that our class is message listener, and we’ll need invoking if messages arrive on a specified queue. So far we’ve implementation agnostic, but it’s time to get some religion at the config level…

<?xml version="1.0" encoding="UTF-8"?>
<beans xmlns="http://www.springframework.org/schema/beans"
       xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
       xsi:schemaLocation="http://www.springframework.org/schema/beans
                           http://www.springframework.org/schema/beans/spring-beans.xsd">

    <bean id="connectionFactory" class="com.sun.messaging.ConnectionFactory">
        <!-- wrap with a custom factory bean to call setProperty("imqAddressList", "yourhost:7676")
                with your host/port if not using default of localhost:7676 -->
    </bean>

    <bean id="jmsTemplateUrl" class="org.springframework.jms.core.JmsTemplate">
        <property name="connectionFactory" ref="connectionFactory"/>
        <property name="defaultDestination" ref="replyQueueUrl"/>
    </bean>

    <bean id="requestQueueThumbnail" class="com.sun.messaging.Queue">
        <constructor-arg value="thumbnailRequest"/>
    </bean>

    <bean id="replyQueueThumbnail" class="com.sun.messaging.Queue">
        <constructor-arg value="thumbnailResponse"/>
    </bean>

    <bean id="jmsTemplateThumbnail" class="org.springframework.jms.core.JmsTemplate">
        <property name="connectionFactory" ref="connectionFactory"/>
        <property name="defaultDestination" ref="replyQueueThumbnail"/>
    </bean>

    <bean id="swtImageGrabber" class="org.groovyblogs.queue.SWTImageGrabber"/>

    <bean id="myThumbnailListener" class="org.groovyblogs.queue.ThumbnailListener">
        <property name="jmsTemplate" ref="jmsTemplateThumbnail"/>
        <property name="imageGrabber" ref="swtImageGrabber"/>
    </bean>

    <bean id="jmsContainerThumbnail" class="org.springframework.jms.listener.DefaultMessageListenerContainer">
        <property name="connectionFactory" ref="connectionFactory"/>
        <property name="destination" ref="requestQueueThumbnail"/>
        <property name="messageListener" ref="myThumbnailListener" />
    </bean>

</beans>

A few pieces of magic here. We construct the com.sun.messaging.Queue with a constructor argument that is the name of the queue. The connection factory uses localhost:7676 by default, and there are not convenience spring-friendly setters for changing it. You’ll need to wrap it in a custom FactoryBean if you need to use a different host/port (since you’ll need to make special a setProperty() call).

The work of listening on the queue and invoking our onMessage routine is handled by Spring’s DefaultMessageListenerContainer class. By default that class only creates a single listener on the queue. But if you need to scale out with more listeners, you can increase its concurrentConsumers property from the default of 1.

So there you have it. A couple of dozen lines of Groovy and a couple of dozen lines of XML and we’re in business with some serious Queue listening and responding. Add some GMaven to the mix (must blog about that at some stage), and you’ve got very few lines of code to handle you whole build process and jar bundling! I think my next step is to add some JMX instrumentation to my POGO so I can use JConsole to see some stats on recent messages processed…

I’ve just finished converting groovyblogs over to a (largely) message driven architecture. I’m a bit of an JMS noob, but the adventure has been fantastic, and it’s time to write some stuff down. The reason I’m even interested in a messaging is for the acquisition of feed xml and thumbnails. I presently do the former in-process in the app server, and the later via Groovy XML-RPC to a Thumbnail Server running locally.

My re-design involves creating four queues: urlRequest, urlResponse, thumbnailRequest, thumbnailResponse. The webapp will put the requests on the request queues, then an external process will deliver source the the thumbnails and feed data (external to the app server) and deliver them on the response queues. All the db action remains in the webapp, so all my hibernate/GORM goodness can continue as usual.

First off was choosing an MQ provider. ActiveMQ seems to have all the mindshare, and was easy to install, but I had quite a bit of trouble actually getting it working correctly. My clients would frequently drop their connections, messages were undelivered since I terminate JmsTemplate connections incorrectly, messages were not delivered on reconnect, and it was generally unforgiving to my JMS noob-ness. I’m sure it’s not ActiveMQ’s fault. But it wasn’t a great experience for me. YMMV.

Then I found out that OpenMQ ships embedded right into Glassfish, so I made the switch and have been happy every since. When I’m running outside of the container (“grails run-app”), I just run a standalone copy of OpenMQ to test against, and when I deploy to Glassfish, I just use the embedded one. Sensational! OpenMQ ships with a funky Swing admin tool (pictured above), but the only thing it didn’t have was a funky Queue content browser (like the Web one that ships with ActiveMQ, but I setup Hermes-JMS and now I can happily browse the contents of both local and remote queue.).

Ok. I had my JMS platform, now it was just a matter of getting the data into and out of those queues. Enter the JMS Plugin. This plugin rocks so hard! Define a service that has an expose = ['jms'] and life will be good for you. To listen on the queue, just define an onMessage closure. You can use naming conventions to map to existing queue names, but in my case I had specific ideas on what I wanted the queue to be called, so I set an explicit ‘destination’:

class ThumbnailQueueService {

    static expose = ['jms']

    static destination = "thumbnailResponse"

    def onMessage = {msg ->
        println "Got Thumbnail Response: ${msg.url}"
    }
}

All the messages I pass around are normal java.util.Map objects, which makes it easy to ship a bunch of payload at once. Once that’s done, anything that ends up on the thumbnailResponse queue will get automatically passed to my onMessage routine. Awesome! But what about putting the thumbnail request on the queue? It’s a snack:

def sendRequest(BlogEntry be, String smallFilename, String bigFilename) {

        try {
            sendJMSMessage("thumbnailRequest",
              [ id: be.id,
                url : be.link ])
        } catch (Exception e) {
             log.error("Failed to send MQ request for ${be?.link}", e)
        }

    }

All services get a “sendJMSMessage” routine injected for free. Just need to pass the name of the queue as the first arg, and your payload for the Queue as your second, and you’re in business!

Today I’ve moved a bunch of my Grails apps over to JNDI Data Sources, and while it’s fresh in my mind, I thought I’d document a few of the tips and tricks involved.

First of all, why would you even want to use JNDI data sources? A few good reasons:

So what changes have I had to make? Just a few tiny ones to DataSource.groovy. Here’s the new one for groovyblogs:

dataSource {
    pooled = false // JNDI, baby. All the way...
}

// environment specific settings
environments {
    development {
        dataSource {
            // check out /web-app/WEB-INF/jetty-env.xml for the details
            dbCreate = "update"
            jndiName = "java:comp/env/jdbc/groovyblogs"
        }
    }
    test {
        dataSource {
            dbCreate = "update"
            url = "jdbc:hsqldb:mem:testDb"
            driverClassName = "org.hsqldb.jdbcDriver"
            username = "sa"
            password = ""
        }
    }
    production {
        dataSource {
            dbCreate = "update"
            jndiName = "jdbc/groovyblogs"
        }
    }
}

First of all, I need to turn pooling off, since the container will now handle all of that for me. But how come the settings are different for DEV and PROD? The answer lies in how containers handle JNDI referencing.

In the DEV example above, I’m running Jetty to do all of my local PC dev work (ie. the standard container that ships with Grails). Embedded Jetty needs to have JNDI references specified using ENC naming (java:comp/env/jdbc/blah), which is resolves against a container specific file to find out the “real” underlying database settings. Enter our friend /web-app/WEB-INF/jetty-env.xml. For groovyblogs, that looks something like:

<?xml version="1.0"?>
<!DOCTYPE Configure PUBLIC "-//Mort Bay Consulting//DTD Configure//EN"
     "http://jetty.mortbay.org/configure.dtd">

<Configure class="org.mortbay.jetty.webapp.WebAppContext">

  <New id="domainDb" class="org.mortbay.jetty.plus.naming.Resource">
    <Arg>jdbc/groovyblogs</Arg>
    <Arg>
     <New class="org.postgresql.ds.PGSimpleDataSource">
        <Set name="user">username</Set>
        <Set name="password">password</Set>
        <Set name="databaseName">groovyblogs</Set></New>
    </Arg>
   </New>

</Configure>

As you can see, because of the way the JNDI resource gets resolved in Jetty, I still need to bundle my postgresql driver in /lib. Alas, but I can at least still test things out locally. Notice that in my DataSource I specify things as java:comp/env/jdbc/groovyblogs, but in jetty-env.xml it needs to be jdbc/groovyblogs. You’ve been warned.

But what about production settings? In my case, I’m deploying to glassfish, so I just need to setup my jdbc connection pool and connection under the “Resources” section of the Glassfish Web Admin tool and I’m in business. Gives me a wealth of options for pool sizes, polling of connections and all that good gear - I can even “ping” the database from the admin tool to make sure it’s configured correctly. Most importantly for me, it gives me a single place for my database name, username and password. I can also do away with the ENC indirection, and just reference the JNDI name directly (jdbc/groovyblogs).

I’m in the midst of a little refactor of groovyblogs to move to a message based architecture. Should make things a lot more reliable. Along the way I’m coming across a few common things that need to be written down. One of the first to sort out is the “circular dependencies” issue.

Here’s the classic scenario. I have a feed service that needs to talk to the queue service to make requests. And when new items come into from the queue service, I need to call the feed service and let it know. So you end up with something like:

class FeedService {

    QueueService queueService

    ...
}

class QueueService {

    FeedService feedService

    ...
}

Which looks all good to you and me. But if you tried to run this app you’d be greeted with:

 Error creating bean with name '(inner bean)': Initialization of bean failed;
nested exception is org.springframework.beans.factory.BeanCurrentlyInCreationException:
Error creating bean with name 'queueService':
org.springframework.beans.factory.FactoryBeanNotInitializedException:
FactoryBean is not fully initialized yet
        at java.security.AccessController.doPrivileged(Native Method)
        at RunApp_groovy$_run_closure2_closure7.doCall(RunApp_groovy:69)

or something like that. The problem? Spring can’t initialise either bean since they reference each other - and each relies on the other already existing. Hmm.. Chicken and egg scenario…

So how to work around it? The easiest way is to initialise one of the references lazily, rather than letting Spring do the work for you. But to do the “lazy” deal, you’ll need a handle to the Spring “ApplicationContext” which holds all the bean definitions. This turns out to be pretty trivial. Here’s a refactored queueService…

import org.springframework.context.*

class QueueService implements ApplicationContextAware {

    ApplicationContext applicationContext

    def feedServiceBean  // note the change of name to stop injection

    def slurpOffQueue() {

        feedServiceBean = applicationContext.getBean("feedService")
        feedServiceBean.doStuff()
    }
}

Not you’ll need a few things:

I’m putting the final touches on the “Chapter 1 Quickstart” for Grails in Action, and I think the trickiest part of a Chapter 1 is the pedagogy. Exactly how much should you cover? I’ve given this a bit of thought, and I’m convinced that most development books I read start too slow.

I’m just guessing, but the average readership of Grails in Action is probably (1) Java developers keen to explore what all the fuss is about; and (2) Groovy and Grails enthusiasts wanting an “in the trenches” book diving deep into the practical roadblocks they might face. I’m assuming (2) will be skipping the first few chapters, so we can probably skip them for Chapter 1. Which leaves us with all those Java developers. How fast is too fast?

Most Java developers that I know that buy books are pretty sharp. They’re keen to hone their craft, learn new skills, explore. So I figure that Chapter 1 should be a sip from a fire hose. Here’s a taste of the Chapter 1 QOTD application (still in need of some CSS tweaks):

So, what do you learn in chapter 1:

And it’s not a long chapter :-). You basically get a taste of all the core features of Grails over 25 pages. Along the way you build a simple, deployable Quote Of The Day application. Not rocket science stuff, but a good taste to whet your appetite. I hope it’s not too much to take in for a “Chapter 1”, but this whole book is about hitting the ground running, so I hope developers appreciate the pragmatic “Leeroy Jenkins“ approach.

But given this is my first book, this might all be just crazy talk… If you have a favourite “Chapter 1” style, let me know. We’ll see what survives editorial…

This blog has been appallingly quiet over the last few weeks, and there’s a simple reason for that: I’m hard at work on “Grails In Action” for Manning. This is my first book project, and I’m working with Peter Ledbrook from G2One (Grails Core committer, GWT Plugin, JSecurity plugin, Profiling plugin) on producing a real “in the trenches” guide to developing Grails applications from scratch.

So What’s in?

Quite a lot. Section One gives you the standard tour: a quickstart primer on Grails, a brushup on Groovy, and we throw together a quick and dirty sample so that Java programmers new to Grails can get a taste of some of the joys that await them.

Section Two we develop some rock solid basics on all the core sections of the technology (but even seasoned guys will probably want to dip into this section from time to time - for example to get up to speed on content negotiation practicalities, the legacy mapping DSL stuff, controller scoping and some other corner cases that you need to know when you need to know). Of course there is complete covering of testing and mocking and all that other agile-y stuff you’ll want to know about.

Section Three we roll into Web2.0 goodness. All the standards are in there: full text search, feeds, charting, reporting, and javascript hocus pocus. We also get into a good coverage of plugin development from the trenches with all the common scenarios you’re likely to run into. You’ll also learn the ins and outs of the Security plugins (Peter wrote the JSecurity plugin!), and get ideas on doing a Web2.0 makeover on your current apps. And you want your app to be a platform, right? So we’ll be giving first class coverage to REST architectures, and you’ll learn enough JSON to get yourself into trouble.

Section Four we get down and dirty with enterprise concerns. In here we fine a complete practitioners guide to deployment lifecycle issues (including per-environment strategies, monitoring and profiling), and probably the most complete coverage of enterprise stuff with Grails that you’re likely to come across (JMX, EJB3, JMS, JNDI and probably a little portlets by then). First class treatment of re-using Spring and Hibernate legacy mappings (along with re-using your current Java code) also should get a Guernsey.

And the demo app?

During the course of the book we’ll work through developing a basic Twitter clone with tons of bells and whistles. We’ll be handling all the basics you’d expect - from the Ajax gear, to the image handling, workflows, feeds, email integration and all that jazz. And then in the enterprise section, we’ll get our hands dirty with MoM (Messaging Oriented Middleware) via JMS, learn a little JMX, a pinch of EJB3, a taste of clustering, have some remoting discussions and have a whole lot of fun doing it.

And when?

Trickier to say, but schedule says sometime just after Christmas. We’re only just getting toward our first milestones (1/3 milestone), so it’s a long way home - and a lot is going to happen in the Grails world between now and then. Stay tuned for updates.

If you’ve been listening to the Grails Podcast, you’ll know that Sven and I have been cooking up a plan to get some kind of Groovy and Grails “community awards” contest up and running over the next little while. And what better way than via a Grails app!

The plan is inspired by some cool stuff the Ruby community is doing with Ruby Heroes - but we’re giving it a groovy and grails makeover.

Basically, the groovy awards is a place where you can nominate people who are contributing greatly to the community via blogs, mailing list support, articles, plugins, wiki entries, and all that Jazz. This one’s not for the big guns (though Graeme, I am nominating you for the “Grails Programmer most likely to do a James Bond voiceover” award), but rather for the not-so-well-known guys that do awesome stuff in the community.

You can nominate anyone you like, and the names will get passed through a panel of Groovy and Grails luminaries for the final tick. For the winners we’d like to come up with some very cool Groovy and Grails award t-shirts (ideas to follow soon), which we’ll ship out to you with all our love!

Anyways, the app is a work in progress (when lunchtimes permit) but should turn up on google code in the coming weeks… in the meantime let me bamboozle you with my newly acquired InkScape skills.. (Thanks David for the pointer on InkScape - it really is awesome!)

The neato character is based on a very cool Inkscape tutorial site and is all done in SVG. I’ve never played with SVG before, but I’m loving it. The whole logo is 16k of XML goodness and I’ll stick the SVG in the repo when I commit it. InkScape let’s you do an export as a transparent png, and you’re off and web-apping…

Stay tuned, we still have some details to work out… and if you have any cool tshirt ideas, feel free to add a comment…

So you’d think there’d be a million Rich Text solutions for editing Wiki markup, right? Hmm… Not so lucky. Google was not my friend.

But if you’re aware of textile-j cool library for rendering textile markup… and your pretty motivated (say, cause the project your working on needs one for client facing wiki content editing), you can probably leverage of the totally sensational YUI Rich Editor along with some funky Grails backend Ajax tom-foolery to come up with a screencast to show off… (1.1mb - sorry for the dodgy sound, next time I’ll use my real mic)

I’ve been using the using the uber cool Grails YUI Plugin to handle the imports of all the necessary YUI files, and getting myself lost in a fairly foreign world of Javascript.

Turns out the recipe for making all this work is pretty straighforward:

• When switching from Wiki markup to HTML, do an Ajax call to a backend Grails controller that uses [textile-j](https://textile-j.dev.java.net/) to convert from textile markup to html. Feed the result of the AJAX call to the YUI Rich Editor and you're in business.
• To support switching from RichText to Textile, again do an Ajax call back to the Grails controller to the do the conversion. This time you're on your own in regexp land, but you can trim the amount of work you've got to do by what you expose in the Rich editor. Return the results and inject into the Wiki textarea.
• To get the underlying html from the editor just use `myEditor.getEditorHTML()`. Awesome!

And how does textile-j do it’s thing? Well my MarkupService is pretty tight (a service is probably overkill, I could probably wrap this up in a Grails encoder):

def textileToHtml = { textile ->

        StringWriter sw = new StringWriter();

        HtmlDocumentBuilder builder = new HtmlDocumentBuilder(sw)
        builder.emitAsDocument = false
        MarkupParser parser = new MarkupParser(new ConfluenceDialect())
        parser.setBuilder(builder)

        parser.parse(textile)
        return sw.toString()

    }

Very tidy. Going back the other way requires a little bit of Regexp Ninja antics… but given that the basic markup I’m supporting is lists, headings, bold, italics, images and links, the search scope is narrowed down significantly from “anything goes” html.

It’s not a perfect solution. Regular expressions are really terrible for this sort of thing since the nested cases get impossible to express. A real grammar is the only way to handle it properly. But for the 90% case (and until I read the Antlr book sitting on my shelf), the above should get me home for v1. Whilst this work if for another project, you can bet the source will end up in Gravl for editing once the feature set is done..

YUI is just awesome… (and props to Marcel for packaging it up in a sweet Grails plugin)…

It’s been ages since I’ve blogged, but it’s not because I’m sitting around nothing… actually I have been doing that too… but it makes me feel better if I try and cover my tracks with activity…

• I’ve got an interview over at DZone’s groovy portal
• Sven and I have been working hard on building up the Grails Podcast (600 downloads in the last 5 days, a good sign of health). We’ve got a few interviews happening over the next couple of weeks, and then a few more at JavaOne (I can’t make it but Sven has a press pass for the Grails Podcast! How cool!). Stay tuned.
• groovyblogs has had massive performance improvements in the last couple of weeks (you’ll recall how painfully slow things were a couple of weeks ago?). Turns out the fix didn’t required a single line of code change. And didn’t even required the app server to be restarted! What was it? Clue: create index on table (field). Which explains why it’s been getting slower and slower for no apparent reason (it’s you guys generating content!)
• And another super secret project involving dead trees that you won’t hear a word from me about for a month or two…

But enough excuses, that’s not the point of this post. I was having coffee the other day with one of the guys who works in my little recruitment company. One question that I love to ask developers is “What’s on your kungfu list?” - in other words, what areas are you weak in that you’re actively working on making sharper? And he asked me the same. The first thing for me is testing-related stuff. Good coverage, all that. You’ve read heaps about this in my MockFor(March) series, so you know things are happening there. The other big kungfu item for me is design.

I don’t mean technical design stuff of architecture, loose coupling, clean interfaces and all that. I mean visual design. CSS. Fonts. Gradients. Colour schemes. All that softer stuff. I’ve long been king of the Franken UI, and the current blog theme for Gravl irritates me no end. It just looks cluncky. groovyblogs looks a little better, and is helped by your thumbnails, but it’s not really visually compelling either.

The Rails community knocks this one out of the park. They have done some really stunning stuff with visuals and even their hardcore developer guys still seem to still cross-skill pretty nicely to the web design space. So it’s time to catch up. I’m totally convinced that design stuff is learnable for all of us (even those of us who aren’t naturally endowed with good design skills), and I’m going to start doing something about it.

[

](http://flickr.com/photos/stabilo-boss/101793494/in/set-72057594060779001/)

So for the next little while I’m off for a little journey into very-much-softer the world of graphic design. If you’re a Franken UI guy, feel free to tag along. If you’ve already got some snazzy design skills, would love your input as I beef up my puny design muscles.

The latest snapshot of the Grails Searchable Plugin now has hit highlighting. I’ve been waiting on this feature, and it’s good to go. With some help from the list, I’ve now got it up and running on Gravl. Here’s the results so far:

So, how much work is it to implement? Coupla lines…inside my seach method, I just need to add a withHighlighter closure into the mix and I was off:

params.withHighlighter = { highlighter, index, sr ->
            // lazy-init the storage
            if (!sr.highlights) {
                sr.highlights = []
            }

            // store highlighted text; "body" is a searchable-property of the BlogEntry domain class
            def matchedFragment = highlighter.fragment("body")
            sr.highlights[index] = "..." + (matchedFragment ?: "") + "..."
        }

// limit query to current blog published entries...
def results = BlogEntry.search(query, params)

Then, in the view, spit out the fragment and I’m done…

  <p class='hitBody'>
    ${ results.highlights[i]  }
  </p>

There still a bit of work to do, for bonus marks:

• I really need to implement highlighting on the title too, if it search term matches in there.* It would also be good to store the blog content stripped of html in the index so that markup of hit terms doesn’t include any of the original markup
• Finally, it would be nice to include multiple highlights of terms for each hit (eg “..entry about gravl… and later in the para about gravl or … and later still about gravl…”). Lucene lets you configure this, so there’s probably a way to do it for Compass, too.

Props to Maurice for a great new feature! Searchable highlighting rocks!

Ok. We’ve had a look at Taglibs and Controllers, it’s time to take a looks at Services. Let’s start with a simple one… My NotificationService gets called when people post new comments. But before we send a notification, we check to see whether notifications are turned on for the blog in question. This requires a little navigation of the object graph…

    boolean isEmailNotifyActive(Comment comment) {

        BlogProperty bp = comment.blogEntry.blog.blogProperties?.find { prop ->
            prop.name == "emailNotify"
        }
        return bp ? Boolean.valueOf(bp.value) : false
    }

So the only mockery required is making sure that object graph navigation works. I have to pass in a real comment since the arg is strongly typed… and I have to return a BlogProperty from the final find… but other than that, you can mock till it’s 1999…

    void testIsEmailActive() {

        def bp = [name: 'emailNotify', value: 'true']
        Comment.metaClass.getBlogEntry = { -> [ blog: [ blogProperties: [
                bp
        ] ] ] }
        def comment = new Comment()
        assertTrue ns.isEmailNotifyActive(comment)
        bp.value = 'false'
        assertFalse ns.isEmailNotifyActive(comment)

    }

So we can mock our way through all the object graph navigation using nested maps, but just make sure that we return a BlogProperty object at the end. We’ll go for the gold and check for both the positive and affirmative. Test coverage markers now work in IntelliJ Groovy Test cases (since 7.0.3), so let’s do a “Run with Coverage”…

Ok. Not quite 100%, but we’re underway… What’s the IDE source telling us…

Well those markers are pretty hard to see… but nothing’s red. Not sure why some things are off-pink :-)… that code certainly seems to be being covered.. Need to circle back later and check that out.

Let’s try something a little more meaty…sendMailNotification() invokes the actual MailService which is injected into NotificationService by Grails. It should be trickier to mock…

Alrighty team, it’s time for a grab-bag of Grails Controller unit testing fragments to get you started. Most of these have been shamelessly stolen from the Graeme’s Grails.org wiki sample code, and spiced up to suit.

On the testing board today is our LoginController, since it’s pretty low hanging fruit for simple test cases that showcase the common stuff you’re likely to want to do.

Let’s start with the index method, that’s gotta be a snack right?

    def index = {redirect(action: 'form')}

Not much to do. Need to handle the redirect() call, so let’s add some setup/teardown code to tackle that one:

    def redirectParams

    /** Setup metaclass fixtures for mocking. */
    void setUp() {
        redirectParams = [ : ]
        LoginController.metaClass.redirect = { Map args -> redirectParams = args  }
    } 

    /** Remove metaclass fixtures for mocking. */
    void tearDown() {
        def remove = GroovySystem.metaClassRegistry.&removeMetaClass
        remove LoginController
    }

Now that we’ve mocked out the redirect stuff, testing becomes pretty straightforward.

    void testIndexRedirect() {
        LoginController lc = new LoginController()
        lc.index()
        assertEquals "form" , redirectParams.action
    }

Piece of cake. But what about something a little trickier? Something that involves request params, sessions, flash, loggers, all that other stuff? Well let’s enhance our setup routine to cater for the common stuff:

def session
    def params
    def redirectParams
    def flash

    /** Setup metaclass fixtures for mocking. */
    void setUp() {

        session = [ : ]
        LoginController.metaClass.getSession = { -> session }

        params = [ : ]
        LoginController.metaClass.getParams = { -> params }

        redirectParams = [ : ]
        LoginController.metaClass.redirect = { Map args -> redirectParams = args  }

        flash = [ : ]
        LoginController.metaClass.getFlash = { -> flash }

        def logger = new Expando( debug: { println it }, info: { println it },
                                  warn: { println it }, error: { println it } )
        LoginController.metaClass.getLog = { -> logger }

    }

Alrighty, I’m starting a little series this month exploring Grails unit tests. Some of you guys are already further along this road than me, so if you have smarter ways of doing things, don’t hesitate to add comments. My Grails testing kungfu is pretty white belt.

We’re starting the journey with taglibs, since they typically front pretty minimal logic, and often don’t need too much mocking. Probably the only things you have to mock out is the “out” attribute, since that’s where your taglib is dumping data. When using grails integration tests, you get the mocked “out” for free, but for now we’re on our own in Unit Testing land.

So what’s the plan? I’m getting my ideas from the grails.org tests which Graeme has put together to give us some good examples of how to mock things out.

So here’s our little taglib routine that’s under test…

    def dateFromNow = { attrs ->

        def date = attrs.date

        out << getNiceDate(date)   // eg "1 minute ago" or "1 hour ago" or "right now"

    }

I use this guy on the groovyblogs home page where you want a nice way of expressing how recent a post was (“right now”, 1 hour ago”, etc). We’ll need to deal with that “out” param through some ExpandoMetaClass magic. I’m doing this mocking process in the setUp() routing of my test. I’m just using a standard StringWriter to represent the out stream. When I’m done, I remove the mocked out lest it live on to side-effect future tests.

    // mocked "out" for taglib
    StringWriter out

    /** Setup metaclass fixtures for mocking. */
    void setUp() {
        out = new StringWriter()
        EntriesTagLib.metaClass.out = out
    }

    /** Remove metaclass fixtures for mocking. */
    void tearDown() {
        def remove = GroovySystem.metaClassRegistry.&removeMetaClass
        remove EntriesTagLib
    }

So now we’ve mocked out the “out”, it’s time to run some real tests:

    void testDateFromNow() {

        EntriesTagLib btl = new EntriesTagLib()

        Calendar cal = Calendar.getInstance()

        btl.dateFromNow(date: cal.time)

        assertEquals "Right now", out.toString()

        // reset "out" buffer
        out.getBuffer().setLength(0)

        cal.add(Calendar.HOUR, -1)
        btl.dateFromNow(date: cal.time)

        assertEquals "1 hour ago", out.toString()

    }

So my selection of a StringWriter meant I had to do some reseting of the buffer between runs, which is not so clean (and totally not threadsafe), but I am up and running - and Gravl now has its first Unit test.

In a very cool set of circumstances I had the chance to hang out with James Gosling this afternoon at a Canberra Q&A session. There were only six of us there, and we had an hour with an open agenda: ask whatever you like! So I did…

JAG is one very loveable character. The hardcore software engineer who made it big, changed the world, and still remains a nice guy.

I asked him a bunch of questions around Dynamic Languages, the Closure proposal, the status of Swing, his feeling about the growth of OSX (and why doesn’t he use a macbook any more :-), and how he felt around the perceived growing complexity of the platform. It was awesome. Boy he gave some candid answers - he certainly has some strong feelings in the language design space (which I guess can be expected!).

One thing question that was asked (weirdly enough, not by me), was about with the recent hires around JRuby & Jython, is Sun sidelining Groovy? James had some nice things to say about Groovy, actually, and reiterated that really it’s a numbers game for Sun. Big numbers of Ruby and Python developers to lure to the platform, fewer (but growing) numbers of Groovy developers already productive there.

This finally made sense to me. If you’re a Sun bean counter, you’re not looking at Groovy’s beautiful platform interoperability, pragmatic syntax, or easy transition for Java developers. You’re just looking at trying to drag numbers to the platform. So there’s plenty of Groovy love at Sun, and don’t look too hard into those recent hires around other languages.

Huge thank you to Danny from Sun for the invite. I had an incredible time!

A Java guy, Rails guy, and Grails guy walk into a bar… Or so the gag begins… but whatever they talk about, one things for sure, at the end of the day, the Grails guy probably ends up with a bunch of stubs in their tests folder. Well as least I do.

It’s weird. I’m mostly an enterprise guy, working at the big end of town. Looking at my test metrics onsite yesterday, I’m pretty much 80%+ coverage on all my Java code… It’s a bit tricky to mock out UnknownHostException, but I can live it. So what strange maniacal thing overcomes me when I start working on Grails apps that I think myself immune from testing?

Grails Productivity. It’s like a drug.You barely ever need to restart the Grails test harness these days, so you keep on adding feature after feature to your app, clicking refresh, testing it out, getting excited. “Yup. That’s done. Next feature. Oh, must get back to those test cases. Dierk would kill me.” But in the haze of seeing your app coming together so quickly, your tests folder grows with more and more empty stubs.

So I have several inspiring friends who are hardcore but pragmatic testing folk. Jason is even a 100% coverage guy - no exceptions (!?). And it’s really starting to bug me that I’m so casual about the after hours stuff I do on Grails.

So here’s the deal. I’m coming clean and declaring this month is “MockFor(March)” for Glen. I’m going to be posting only on Grails Unit testing for the whole month. Not even Grails integration tests. Just unit tests.

Why just unit tests? Two reasons: (1) Because I want to be able to run these bad boys straight from Intellij and have them run in under a second each. Intellij 7.0.3 will have in-IDE coverage markers for Groovy test cases, so I can easily tell what’s covered and what isn’t…

And (2) I really want to learn more about the dynamic side of Groovy - in particular ExpandoMetaClass. Focussing on unit testing means I’ll need to mock out some tricky stuff to ensure I’m just testing the Class Under Test (CUT). So a doubly good learning exercise.

If you’d like to follow along, I’m going to be using Gravl (the software that powers this blog) as my test app. The source code is all on googlecode, so you can always find the nitty gritty up there, but I’ll blog up the highlights here.

It’s gonna be a fun month. Hopefully along the way we’ll all increase our Grails testing kung-fu.

Well it’s been a year today since Groovyblogs went pens down and a lot of things have happened. In the last year it’s seen:

• Browser Thumbnails
• Language Translations
• Ajax Feed Preview
• Keyword Filtering
• and tons more since then…

It’s also seem more than the odd outage through either (1) the little one’s affinity with the flashing light on the UPS, or (2) lightening strike (really!), (3) catastrophic server failure of the original whitebox hardware and migration to the iMac, (4) Glen’s dodgy hacks to get that thumbnail service stable.

Back then, we deployed on Grails 0.4 - and boy a lot of things have changed over the year. The framework has grown, our practitioner knowledge has grown, and the community is gaining incredible momentum. We used to get a few posts a week, now we getting 5-10 a day! We now have a daily readership of 500 avid Groovy/Grails fans. Here’s the feedburner stats…

And how much fun are we having? We’re having a ball. To celebrate, I’ve updated groovyblogs to Grails 1.0.1 and I’ve now moved it to google code, so you can always stay in sync to whatever you are seeing live on the site.

Thanks so much for the awesome content that you guys provide every day. It’s a great time to be a groovy programmer!

G2X was one sensational event and Jay/Bob/Scott and the boys sure know how to put on a NFJS show. Jay is just one infectious guy who really “gets it” when it comes to what developers are looking for. The food was just sensational, the speaker line-up meant you has “clashing” sessions all the time (where you wanted to go to more than one session in a timeslot, but you don’t implement clone()), and the Grails community is full of rocking people who are just fun to hang out with.

Some random stuff that I took away form the show:

• I could sit with any random group of folk at that conference and come away getting inspired. The passion level among the group community is obviously very high - people genuinely love writing in Groovy & Grails and it shows.
• Scott Davis is on some other planet of speaker showmanship. His keynote on “Groovy by the Numbers” was just sensational had some serious Presentation Zen going on. I was blown away.Really captivating.
• Try to avoid having your session at the same time as Jason Rudolph. Any session that Jason was involved with was packed to the rafters. I missed the end of his talk on Refactotum, but still came away heavily impacted by his dedication to testing and software craftsmanship. Some software quality guys make you feel ashamed when you drop the ball on code quality, but guys like Jason just make you feel inspired to take things to the next level.* Venkat Subramanium is one sensational programmer. I leant heaps of stuff from his talk on Groovy DSLs and metaclasses. It was phenomenal. Looks like an older copy of the slides are here* It’s always great to have a chance to hang out with the G2One guys: Graeme, Alex, Jeff. They’re hiring at the moment! You could be one of the lucky ones!
• Great to catch up with Alexandru, who is the founder of InfoQ!
• Made some great new friends at the conference. Met up with [Ken Kousen](http://kousenit.wordpress.com/), [Dave Klein](http://www.capjug.org), [Andres & Ix-chel Almiray](ttp://www.jroller.com/aalmiray),[James Williams](http://www.jameswilliams.be) and too many others to name. It was awesome.
• None of the sessions were recorded, so if you didn’t make it, you’re out of luck. There is, however, a west coast version of the conference coming in October in San Jose, and Grails Exchange will be on in London sometime iin the later half of the year for the European folks. For those Aussies out there, everything is 30 hours travel until I can convince someone to run a Groovy.Au conference. (with delays in airports it took me around 28 hours to get home. Geez we live a long way from North America!)* As always, talking with Dierk König always leaves me with tons of ideas for new projects, and inspired by his real world experiences using Groovy in the enterprise - look out Australian Govt!
• Thanks to all those who came to my sessions . The rooms were full and the crowd was very enthusiastic. Congrats to all those who won clip-on koalas!

Hope to see you all again soon!

PS. I have to learn TextMate before my next presentation. The stuff people were doing with it was unbelievable!

I’ve been meaning to have a look at both Gant and easyb for a while, so I headed off to Andy Glover’s sessions where he had one on each.

Gant looks pretty cool. Gives you all the power of Ant, but using Groovy imperatives rather than xml. Very cool for branching and doing other funkyness during the build. You also get Ivy bundled in the mix, so you get Maven-like dependency goodness out of the box.

Andy demoed defining closures for common operations (such as compilation) and then doing some cool currying operations to reuse the closure for all sorts of directories and classpaths. (He recommended a good developerworks article on closure currying).

I really need to download Gant and have a closer look, especially for doing build funkyness in Grails apps.

Next talk. easyb is a Groovy implementation of Behaviour Driven Development (which has been getting popular through RSpec support in Ruby-land). The idea is that you are given a Domain Specific Language (DSL) for expressing tests through a very fluent programming model of stories and scenarios.

given "a modified String class", {
    String.metaClass.caps = {
        delegate[0].toUpperCase() + delegate[1..-1]
    }
}

when "caps is invoked" {
   "andy".caps()
}

then "the value should be Andy", {
    value.shouldBe "Andy"
}

You can run easyb tests via an Ant task, Maven2 plugin, or from the commandline.

Andy’s a great speaker and we were a tough crowd. Really engaging.

Ok. Gotta blog up some of this stuff before it gets stale. Last night Graeme took us through what’s on the planning on the horizon for Grails 1.1.

• JPA support. Lot of people asking about this (really?). So there is likely to be a JPA plugin down the track but since JPA doesn’t support Criteria, it’s gonna be a fair bit of work for the team to implement.
• JSP Taglib in GSPs. You’ll be able to use your Java taglibs in a GSP (not just a JSP). Good stuff for reusing old custom tags.
• Portlet support. The biggest ticket JIRA item is portlet support, and the Grails team are investigating what’s involved.
• JCR support. Graeme has been tinkering with a plugin for this. Means you’ll be able to version domain classes, and do diffs and rollbacks and other goodness
• DB Migrations. You’ll be able to move your schema forward and backward.

Graeme then demoed a version of grails.org running on Grails! He’d whipped up a confluence style wiki that supports basic Textile markup, versioning and rollback.

He found XmlSlurper died (OutOfMemory) on the 75Mb XML Confluence file. He had to whip up a SaxParser impl (in Groovy, of course!). The import to his Macbook (read and parse XML and import to a domain model in MySql) took around 90 seconds. Cool!

Took him a day and a half to pull together! Look for it soon!