Topic: Groovy

Griffon Tutorials: Adding Useful Logging

Dietrich Kappe, Friday, November 13, 2009 @ 5:04 am

I'm gathering as much as I can on Griffon and how people are using it. Some things you can translated from Grails, but not everything. So here, as a public service, is the first of many Griffon tutorial pointers.

Dabble->Scribble has a nice blog entry on including log4j logging in Griffon. My favorite part? One of his goals for logging is to "Filter out the cruft from Groovy's massive stacktraces." Amen.

• Digg
• Reddit
• del.icio.us

Comments (0)

Software Development

Grails and Google App Engine: Birthing Pains

Dietrich Kappe, Wednesday, November 4, 2009 @ 4:45 pm

Whenever you can get a free, publicly available place to deploy your applications, your first instinct is to grab it with both hands. Google App Engine is one of those places. Each developer can deploy up to 10 different apps in development mode.

I've been working on a grails app recently that uses the grails App Engine Plugin. Along with the GORM-JPA Plugin, which gives you some  of the usual grails GORM goodness, you can write some reasonably interesting grails apps.
Continue reading »

• Digg
• Reddit
• del.icio.us

Comments (2)

Software Development

Griffon Plugin Development: Some Nitty Gritty

Dietrich Kappe, Friday, October 23, 2009 @ 12:29 pm

Installing plugins in Griffon is pretty easy. You just type something like

% griffon install-plugin [plugin-name]
 

in your application's base directory and it does all the rest. The actual plugin stuff gets put in ~/.griffon/<version>/projects/<appname>/plugins. But what if you want to develop a plugin and don't want to have to reinstall with every little code and test change?

Well, Josh Reed has a nice blog post on exactly how to do that. I won't recap it here, just say that essentially you nuke the installed stuff under the .griffon directory and make a symbolic link to your plugin development directory.

There are just two things that are a little confusing about it.

1. How do you install a plugin in the first place so you can do the nuke and symbolic link thing in the first place?
2. Why doesn't your plugin show up as installed when you run griffon list-plugins?

Well, the answer to the first question is simple. Simply package your plugin by going going to it's base directory and typing

% griffon package-plugin
 

to generate a zip file. You can then navigate to your application's base directory and type

% griffon install-plugin [path to plugin]/plugin-name-0.1.zip
 

all assuming that your plugin is version 0.1. After that you are good to go with Josh's original instructions.

As for the second question, I'm still spelunking through the gant scripts to figure that one out.

• Digg
• Reddit
• del.icio.us

Comments (0)

Software Development

Questions About Griffon

Dietrich Kappe, Friday, October 9, 2009 @ 1:03 pm

Time to answer some questions about Griffon:

1. What is the size of the jar that gets generated for a Griffon jar?
   If you package it all up ('griffon package'), then a vanilla Griffon jar weighs in at 4.7M. That's mostly the Groovy runtime (4.4M) and the Griffon runtime (204k). If you're concerned about download size for Java Web Start, then you won't want to bundle it as a single jar, but rather let your users download the Groovy and Griffon runtimes once, then your app specific jar as it is updated.
2. Can Griffon apps be distributed via Java Web Start?
   Yes. When you run 'griffon package', you get an executable jar, an applet, a JWS app and a 'zip' that is structured as a directory with bin and lib subdirs and batch and shell files to run the application. In short, most ways that you may want to deploy the application.

There is even an installer plugin that allows you to package your app as an izPack (platform independent), RPM (Linux) or DMG (Mac) distribution. It will also create app (Mac) or exe (via JSmooth) launchers for Mac and Windows. Pretty sweet.

• Digg
• Reddit
• del.icio.us

Comments (0)

Software Development

Griffon: Convention over Configuration for the Desktop

Dietrich Kappe, Thursday, October 1, 2009 @ 1:24 pm

In the past, one of the nice things about web application development versus desktop development has been the proliferation of application development frameworks. Where desktop development pretty much gave you a set of GUI components and a few concepts like event driven programming and MVC, web frameworks, in particular the more recent ones such as Rails and Grails, gave you an application architecture into which you could implement your domain specific logic.

Lots of benefits accrued from this predefined structure, not the least of which was the ability to quickly understand the application based on a shared understanding of how applications using this framework were put together. In my experience of looking at desktop and web applications over the years, the web applications were better and more consistently designed than their desktop counterparts. Similar tries at desktop frameworks just never seemed to gain any traction (recall Scope, an app framework based on the HMVC pattern that died of neglect).

Now along comes Griffon, a desktop application framework modeled on (and sharing an architecture) with Grails. Griffon has a very similar controller, view and model breakdown as Grails, and support for plugins. I'd like to see similar frameworks for .NET and Cocoa (yes, yes, Cocoa has some of it's own framework goodness, but could use some higher level application abstractions to make application development more consistent).

Continue reading »

• Digg
• Reddit
• del.icio.us

Comments (2)

Software Development

Asterisk-Java Testing with Groovy

Ivan Moscoso, Thursday, July 2, 2009 @ 8:03 am

Recently I have taken a bit of a detour into the world of telephony, working with Asterisk-Java, which by itself is a very valuable tool, and worth knowing a bit about if you are integrating a system with Asterisk. While it is a Java-based library, I am integrating it into a Grails application.

We have a fairly comprehensive suite of unit tests asserting that desired behaviors are triggered upon certain events initiated through the Event API. This is made even easier, as usual, with Groovy-- specifically on the testing front. Here I show two hypothetical test cases, followed by supporting code that works specifically with the Asterisk-Java classes...

Continue reading »

• Digg
• Reddit
• del.icio.us

Comments (1)

software development best practices

How to learn a new programming language or framework

Sharad Jain, Wednesday, June 17, 2009 @ 10:03 am

While never untrue, it is more of a necessity now, that a programmer should know more than just one language or framework. After being a focussed Java/J2EE developer for a long time since college, in the last couple of years, I plunged into .NET, Ruby/Rails and then Javascript/prototype/jQuery etc and now onto groovy/grails. With name like Erlang, Scala, Compass, git, blueprint, flex flying around us everywhere, it can be overwhelming and we need a plan to pick, peruse, acquire them. Here is a list of things I do when learning a new skill.

Continue reading »

• Digg
• Reddit
• del.icio.us

Comments (3)

Software Development

Groovy 1.6 and Per-Instance Metaclass

Ivan Moscoso, Wednesday, February 25, 2009 @ 3:30 pm

One of the new features of Groovy 1.6 includes support for per-instance metaclasses. This is a nice addition to the language, since it allows to change the behavior of objects without affecting all instances of the class as a whole.

For testing, it is often useful to mock out specific behavior of an object without affecting the class as a whole. While some mocking frameworks already allow this, they usually run through a few hoops (i.e. "partial mocks"). Allowing support directly in the language can simplify this kind of approach.

Another case where per-instance metaprogramming can be useful is in employing template patterns on a per-instance basis. Picture the case where the domain decides that one of its children is no longer in a valid state. Most domain models handle this by embedding some sort of state object within the children, so that any object holding a reference to the children know what the child can or can not do. With a per-instance metaclass, however, the aggregate root can simply add or replace behavior of that instance of the object alone.
Continue reading »

• Digg
• Reddit
• del.icio.us

Comments (5)

software development best practices

Grails: Delegating to GORM Persistence in Java

Anthony Caliendo, Wednesday, February 11, 2009 @ 11:43 pm

For a recent project, I needed to plug some Java code into a Grails app. I wanted to use GORM for persistence, but couldn't introduce the interfaces, proxies, and factories into the java code which is required for existing solutions to this problem.

Basically, my constraint was that the java code itself couldn't be altered to work inside the grails app. The solution I came up with is pretty simple, but works well.

Continue reading »

• Digg
• Reddit
• del.icio.us

Comments (1)

Software Development

Grails and JSONP: How Easy is That?

Dietrich Kappe, Friday, February 29, 2008 @ 4:15 pm

For all of those Java developers casting longing glances at their buddies doing Rails development, there is hope. Grails, which has just celebrated its 1.0 release, is a Rails-like "convention over configuration" framework that aims to do for the Java world what Rails has done for Ruby. Instead of Ruby, the dynamic programming language of choice is Groovy, which compiles to bytecode (no Groovy to Java translation) and integrates smoothly with just about any Java code you may be using.

I'll stop hyping Groovy and Grails in general here; there's plenty of good informational stuff on the Grails and Groovy home pages. I will note that if you run off the tracks a little bit, you can find yourself reading through 500-odd line stack traces of Groovy, Spring and Hibernate -- there's room for some improvement there.

One of the many nice things about Grails is it's support for JSON and XML. Let me put together a simple example that shows off some of Grails' power.

Continue reading »

• Digg
• Reddit
• del.icio.us

Comments (2)

Software Development

Markdown, GWT & Regular Expressions in Groovy

Ivan Moscoso, Friday, December 28, 2007 @ 8:41 am

If you haven't been able to tell yet, I like Groovy.

I was playing around with enabling some Markdown support in GWT (attempting to use Markdown-J from inside a TextArea instance widget).  Because Markdown-J relies on java.util.regex classes, it can not be invoked directly by GWT. I decided to take two approaches-- the first being to invoke the Markdown-J processor via an RPC call, and secondly to do it all on the client-side (which I will address later).

The first approach meant I could do some interesting things along the way in Groovy.  First off, I wanted to extend the Markdown processor to support table markup similar to, say, a FitNesse test (i.e turning markup like this):

|com.some.fixture.DummyTestFixturePlusOne|| input | expectedOutput? || 10    | 11              || 44    | 45              |

Into HTML output like this..

Or other alternate (possibly interactive) representations of tabular data using GWT, if you get my drift (but that's another show).

The implementation of Markdown-J is relatively straightforward.  It makes heavy use of regular expressions (java.util.regex can not be referenced by GWT), and thereby serves as a good illustration of the paradox of regular expression support in Java:  You can get the job done, but it's rarely nice to look at.  Groovy makes it so much better.  Here's my first attempt to extend Markdown-J's "MarkdownProcessor" class from a Groovy class.  Nothing special up my sleeve here.

class MarkdownProcessorWithTableSupport extends MarkdownProcessor {
    private static final tableRegex = /\|([\d \w\.]+)\|[\n\r](.*\|)(?:[\n\r]?[^\|])/

    public TextEditor runBlockGamut(TextEditor text) {
        TextEditor editor = super.runBlockGamut(text)
        String content = editor.toString()

        content.eachMatch (tableRegex) { match ->
            String headerRow = match[1]
            String tableContent = match[2]
            // do something with this match..
        }
        return new TextEditor(content)
    }
}

This is enough code to extract the first two match groups in the regex and start doing something with them.  The only real item of value in this class is the regular expression.  That regex took me a bit of time to nail down, so obviously it's rewarding to have it represented as closely as possible without any of the double-backslash marks you find with Java strings.  Notice that Groovy avoids the '\\' hell when describing regular expressions with it's "slashy" style strings.  'tableRegex' is still a String, you see.  But unlike the double-quote delimiter, the '/' delimiter allows things like unescaped backslashes.

Other than the regex, everything else in the code is rather boilerplate (iterate over each match, generate some HTML markup, yadda yadda... you get the idea).  Take note of the 'eachMatch' invocation on my String content though.  There's more going on than you might imagine-- Groovy actually takes the regular expression and compiles it down to a java.util.regex.Pattern instance before evaluating the closure.  Isn't that nice?  After all, it's what I would have done in Java anyway.

What's next?  I think it makes sense to try something like Showdown and bake it into a GWT component.  This will be my first attempt to integrate some existing JS library and see how nicely it will play with GWT.  Stay tuned.

• Digg
• Reddit
• del.icio.us

Comments (0)

Software Development

GWT Testing With Groovy? (Heck yeah!)

Ivan Moscoso, Wednesday, December 19, 2007 @ 2:01 am

Speaking of GroovyTestCase, I experimented a bit with using both it and JMockit as an alternative to GWTTestCase.  This may sound strange at first-- after all, the point of GWTTestCase is to exercise your code in the way it will eventually execute as JS at runtime.  What I've effectively done is to run my tests from within Groovy against GWT classes compiled-as-Java.  First I will go through an example of what I'm talking about, then I will summarize some of the thoughts I had as a result of going through this exercise.

Below I have an implementation of KeyboardListener which modifies the contents of a TextArea based on keypress.  I want to test the behavior of this listener.  Here's what I did:

1) Write a test.  I did this using Groovy, but you could just as easily write it in Java using JUnitTestCase if you prefer.  This particular test verifies that my listener will append an equal amount of whitespace to the next line when the <enter> key is pressed, and position the cursor at the end of that new line.  Very simple stuff, but worth testing even outside of GWTTestCase.  I find that the Groovy style keeps this test case a lot shorter than it would otherwise be in Java.

class SampleTest extends GroovyTestCase {
    private static final char KEY_ENTER = (char) KeyboardListener.KEY_ENTER
    private static final int NO_MODIFIERS = 0;

    protected void setUp() throws Exception {
        Mockit.redefineMethods(GWT, MockGWT)
    }

    public void testEnterKey() {
        def keyListener = new MyKeyListener()
        def textArea = new TextAreaFixture(text: "    abcd", cursorPos: 8 )

        keyListener.onKeyPress(textArea, KEY_ENTER, NO_MODIFIERS)

        assertEquals "Content is incorrect", "    abcd\r    ", textArea.text
        assertEquals "Cursor position is incorrect", 13, textArea.cursorPos
    }
}

class TextAreaFixture extends TextArea {
    String text;
    int cursorPos;
}

2) Mock out com.google.gwt.core.client.GWT.  This ultimately comes down to mocking out the 'create' method.  Notice below that we make a special case for 'DOMImpl.class'.  The reason for this is that the actual DOMImpl is decided at runtime.  It is also referenced in the constructors of the widget we are testing (i.e. 'TextArea()').  Note that this class needs to be a Java class (i.e. non-Groovy) due to the way in which JMockit redefines methods on existing Java classes.  As for why I return 'null' for everything else, I do this to fail fast in any cases I'm not testing.  As it turns out, this is all I need for the testcase above.

public class MockGWT {
    public static Object create(Class classLiteral) {
        try {
            if (classLiteral.equals(DOMImpl.class)) {
                return new MockDOMImpl();
            }
            return null;
        } catch (Exception e) {
            throw new RuntimeException(e);
        }
    }
}

3) Subclass com.google.gwt.user.client.impl.DOMImpl.  Ah-hah!  Here's the catch... This step provides us just enough code to satisfy construction of our Widgets.  For my purposes, I let my IDE generate this subclass for me, and stuck with the default implementations it generated.  I return an instance of it above.

public class MockDOMImpl extends DOMImpl {
    public Element createElement(String tag) {
        return null;
    }
    [...]
}

The approach to this style of testing intercepts any calls on the Widgets themselves before anything is allowed to hit the underlying DOM implementation.  What I provide above is just an example of how this could be done, specifically when testing behavior of custom classes that happen to inherit or reference GWT classes.  Testing things like layout or UI concerns is another matter, but one which I would not consider 'interesting' enough for unit testing, since most of the behavior on the UI can be easily inspected by viewing Widgets as simple beans.

So why would you want to attempt this anyway?  First, I happen to like working in Groovy, so I crave more reasons to do exactly that.  Second (and more pertinent), much of behavior I find interesting in GWT apps revolves around simple message passing.  I trust GWT enough to do its job once I leave the Java space.  Beyond this are some philosophical differences I have with GWTTestCase, particularly since GWTTestCase makes it hard to maintain a larger body of unit tests, requires additional configuration in your module file (or as I've done before, constructed a different "test-only" module file that inherited from two module files), did not let me set up tests the way I would like to, etc.  I could go on.  When unit testing, very little of the logic I write is made less interesting or less relevant outside of a JS runtime environment, so where possible I would like to gain some benefits from treating everything as Java.

There are other benefits.  There's the noticeable speedup in execution time when running entirely within the JVM.  There's also less restrictions on the test class itself with regards to instance variables, language (i.e. Groovy), dependencies in outside packages, etc.  Why wouldn't I want such flexibility in my test code?  I really want my test code to be as concise and expressive as possible, particularly as my apps get larger and more complex.  I think having alternative ways of approaching this kind of testing brings a lot of these types of benefits.

• Digg
• Reddit
• del.icio.us

Comments (1)

Software Development