GPars For Beginners Presentation

I'll be giving a presentation titled GPars For Beginners to the Boston Grails Users' Group on Wednesday, May 25 at 7 P.M.  Here's my description of the talk:

The GPars (Groovy Parallel Systems) project provides multiple abstractions for concurrent, parallel programming in Groovy and Java. Rather than dealing directly with threads, synchronization, and locks, or even the java.util.concurrent classes added in Java 5, the project allows you to think in terms of actors, data flows, or composable asynchronous functions (to name a few).
In this talk, I'm planning to cover the basics of GPars, including what it's like to learn to use it. Although I've done a fair amount of concurrent programming, I've just started using GPars. As such, this talk should be suitable for Groovy beginners.

If you're a fan of Groovy and will be in the Boston-area, I hope you'll attend.  If you can't, I'll be posting a link to the slides here when they're ready.

In the presentation, I'll be referring to several resources I found helpful.  Here are links to each of them:

• Groovy in Action 2nd Edition (aka ReGinA) Chapter 17 - http://manning.com/koenig2/
• GPars User Guide - http://gpars.org/guide/
• GPars User Mailing List - http://xircles.codehaus.org/lists/user@gpars.codehaus.org
• Dierk König's presentation (Concurrent programming for you and me) - http://skillsmatter.com/podcast/groovy-grails/concurrent-programming-for-you-and-me
• Alex Miller's DevWorks article - http://www.ibm.com/developerworks/java/library/j-gpars/index.html
• Václav Pech's blog - http://www.jroller.com/vaclav/

(Sorry if this shows up as an entirely new post.  Blogger seems once again to be acting funky.)

Update: Here are the slides from my talk.  Sadly, I forgot to record the audio to go along with it.

GPars For Beginners

View more presentations from Matt Passell

Looking For Part-Time Groovy/Grails Work

As you can see from my LinkedIn profile, I'm an experienced Java developer (starting with 1.0 and 1.1 in the Fall of 1997), who's done some work with Groovy and Grails.  Although I love Java the Platform, I've decided (like many others I know) to gradually shift my emphasis away from Java the Language.  I've decided to focus on Groovy for now, but I can easily imagine adding Scala to my portfolio as well.
So, here's my challenge: I have the good fortune to have long-term Java work for a client that takes up most, but not all of my time.  That means that if I were to take on new Grails (or straight Groovy) work, it would have to be part-time.  That really limits my options.  If I can't find paid part-time work, I'll probably try to contribute to an existing Grails plug-in.  I already author an open source Groovy project, but it's so small that it doesn't really push me to improve my skills.
Any other suggestions?

Update: I found just what I was looking for with Wingu, a startup in stealth mode creating next generation science applications on the web.  Last week, I started working for them a day a week.  I'm looking forward to some Groovy/Grails/Gradle goodness. :)  (reference to mrhaki only slightly intentional)
By the way, if you're looking for something similar and you live in the L.A. area, I just saw a post show up on LinkedIn.  If you're not a member of LinkedIn, here are the details (PDF) on the Extremely Heavy Industries website.  I'm not familiar at all with the company, so make sure to perform your standard due diligence.

Update (Mar. 2, 2010): Things with Wingu didn't work out. :(  I'm back to looking.  This time around I'll try to do a better job of figuring out whether I can perform useful work for the client with the limited number of hours I have available.

Update (Sept. 1, 2015): I took a full-time job with CarGurus.com back in June of 2013 and I've been very happy here. If you're in the Boston area, I highly recommend it as a place to work.

Curious Concept's Excellent JSON Pretty Formatter and Validator

I just wrote a bit of code using Groovy HTTPBuilder to fetch and parse some JSON content to help answer someone's question on StackOverflow.  When trying to pull some interesting data out of the JSON to display, I realized that it would be much easier for me to understand the structure of the JSON if it were pretty-printed (or pretty-formatted).  When I googled for "JSON pretty format", I found a helpful blog entry pointing me to Curious Concept's JSON Formatter (& Validator).  It's a simple online tool that allows you to paste in either a URL pointing to JSON content or the content itself and display it in either compressed or readable form.  It might not have been very hard to code, but it's extremely useful.  Thanks Curious Concept!

Update: I'm trying out the JSONView Firefox plug-in.  So far it seems to work pretty well.  Even so, I expect I'll continue to use Curious Concept's tool for a while, since I spend a fair amount of time in Chrome.

Merger Madness & One Sample App To Rule Them All

VMware ---	SpringSource ---	/---G2One
		\---CloudFoundry
Terracotta ---	Ehcache
Oracle ---	Sun

With all the mergers and acquisitions happening in the Java world, I thought I'd suggest a sample app someone could build to bring them all together.

Here it is: a Grails app using an Oracle DB with distributed caching provided by Terracotta and Ehcache, all running in a VMware cloud, with deployment and management handled by CloudFoundry.  I think that covers all the bases.  I have no idea what it will do yet, but let me know if I've missed anything. :)

Note: I actually have a lot of respect for all the technologies and people involved, I'm just feeling a bit overwhelmed with all of the recent consolidation!

Attending SpringOne 2GX in October!

After much thought, I finally decided last night to register for the SpringOne 2GX conference running from October 19 through 22 in New Orleans.  The deadline for the super-early bird pricing is this Friday (July 31), so I thought I should make my decision.  I've been to talks on Groovy and Grails at NFJS and JavaOne, but I'm really looking forward to an entire conference devoted to those topics.  I hope to see you there!

FogBugzReporter: NetBeans + Ivy = IvyBeans

(This is my second post in a series about FogBugzReporter, a small open source app that I originally wrote in Java and later ported to Groovy.  See the first post for more information and for links to other posts in the series as I write them.)

When I first ported FogBugzReporter to Groovy, I was able to take advantage of a free 1 year license for JetBrains IntelliJ IDEA (version 7) and its nice Groovy support.  I had good experiences with it, but when the year ran out, I was both reluctant to pay for a new license and curious to explore the Groovy and Grails support in NetBeans.  At the same time, I was interested in trying out Apache Ivy for dependency management.  As it turns out, Laurent Forêt wrote a plug-in for NetBeans called IvyBeans which integrates Ivy with the NetBeans internal build infrastructure.  So, if you reference a library in your ivy.xml, not only is it downloaded into your local repository (located in %USERPROFILE%/.netbeans/<netbeans_version>/modules/ext/cache on Windows) but it's also added as a NetBeans project dependency.  This post describes what it was like to move to NetBeans and start using Ivy.

Although I'd previously used NetBeans 6.1 and 6.5 for some small Grails apps, by the time I got around to moving FogBugzReporter into NetBeans, the 6.7 release process had already reached Milestone 2 or 3 (it has since been released!).  Since the Groovy/Grails plug-in for 6.7 provided better, more up-to-date support, I decided to jump directly to it.  After installing the base version and adding the Groovy/Grails plug-in, I looked over the options for opening the project in NetBeans.  I couldn't see any easy way to either import the project based on the existing IntelliJ files or create a new project pointing to the existing sources (any suggestions?), so I ended up doing something weird along the lines of creating a new project and checking out the files from Subversion on top of it.  I don't remember the exact steps, but even if I did I might not repeat them here, since I'm sure there's a better way to do it.  Once that was done, I was a bit disappointed to discover that I was unable to designate my Groovy script (MainFrame.groovy) as the project's main class.  This was even true after I converted the script into a class and gave it a main method.  Fortunately, it's still possible to run the app inside NetBeans by selecting that file and choosing Run File (Shift+F6) from the Run menu.

Next, it was time to try out Ivy and IvyBeans.  At the time, there was no up-to-date build available, so I built from HEAD, but at this point you can just download 1.1 Milestone 3.  Installation is as simple as extracting the zip you just downloaded and then following the basic plug-in install steps.  I searched on MVNRepository.com to find the appropriate org (a.k.a. group) and name for each of the two libraries my project uses.  I then removed the libraries from the NetBeans project, temporarily making the IDE unhappy.  After I added lines of the following form to ivy.xml and then executed a Clean and Build on the project, Ivy downloaded the libraries, IvyBeans made them available to the project, and the build completed successfully.  Pretty cool!

<dependency org="com.something" name="library_name" rev="1.2.3" conf="compile->*" />

My transition to NetBeans isn't totally finished, but it's almost there.  One thing I still need to figure out is what changes are needed to allow me to run an external build using the ant build.xml file generated by NetBeans – I think it involves specifying a few properties that are currently absent when ant is run standalone.

As I've said in most of my posts, please tell if you know of a better way to do any of what I've described above.  I'm definitely not an expert in NetBeans or Ivy.

Embedded Groovy as an Application Extension Language

I recently worked with my client to add an extension mechanism (in this case, a very simple plug-in system) to their intranet Java web application.  It's initially meant for use by professional services staff and possibly other advanced users in the future.  Our first thought was to go with JavaScript via the Java Scripting API, since that pair of technologies was already in use elsewhere in the system for simple filtering expressions (e.g., "value > 10 && value < 100").  I wrote a few examples and discovered that the code quickly became a weird hybrid of Java and JavaScript that was very hard to read. ("Is that a Java String or a JavaScript String?…")  After a brief conversation with my client, we decided to instead go with Groovy for several reasons.  We can keep the code around as Strings for now, but easily compile it to class files later if our needs change.  Groovy's integration with Java is excellent and easy to understand.  If the user knows Java, but isn't comfortable with Groovy's many cool features, he or she can write normal Java (except for inner classes) and have it interpreted/compiled as Groovy.  What follows is a description of how I set it up.  Please let me know what you think of this approach, especially if you can suggest a way to improve it.

Each extension is a Groovy class extending a Java abstract adapter class that provides default implementations of all but one of the methods in a Java interface (ScriptingInterface).  The Java code used to load the extension gets a GroovyClassLoader using the following code:

GroovyClassLoader loader = new GroovyClassLoader(getClass().getClassLoader());

I use the following code to get the relevant class and instantiate it via its no-arg constructor, catching the (entertainingly-named) MultipleCompilationErrorsException along with several other exceptions:

String code = "<Groovy>"; 
Class<? extends ScriptingInterface> clazz = loader.parseClass(code); 
ScriptingInterface script = clazz.newInstance();

Does that sound like a reasonable way to do it?  It definitely works, but I'm not sure it's the best way.

Update: Ack!  For some reason, my Blogger settings changed from "New Posts Have Comments" to "New Posts Do Not Have Comments" through no action of my own!  While I try to figure out how to fix it (now that this post is no longer new), you can add any comments to this post's listing on DZone.

Update2: Problem fixed.  It turned out to be possible to turn on comments for a single post via the Blogger post editor.

Boston Grails Users' Group!

Last night, I watched an interview with Dave Klein done by Scott Davis of ThirstyHead at JavaOne 2009, in which they discussed Dave's upcoming book, Grails: A Quick-Start Guide. At the end of the interview, Dave mentioned that one of his kids had put together a site called g2groups.net, which helps people find and start Groovy/Grails user groups. I visited the site and was very excited to see that Boston has a newly formed group and that their first meeting is on Thursday! I have a conflict, but this is important enough that I plan to drop my original commitment to attend. See you there!

FogBugzReporter: Introduction

This is the first post in what I plan to be a series about a small application named FogBugzReporter that I began writing in October of 2007.  I'd recently started using the on demand edition of FogBugz from Fog Creek Software to track my time spent consulting and was disappointed to discover that it had no direct way for me to generate time reports.  Fortunately, I discovered that along with the web UI, FogBugz also had a pseudo-REST API for interacting with the application (I say "pseudo-REST" because almost all operations can be performed with HTTP GETs, including ones that change state on the server).  I read the API docs, quickly wrote a simple Swing application in Java, and made it available to the rest of the FogBugz community.  Soon after, I started experimenting with Groovy and realized that porting the app would be a nice way to get some experience with the language, including SwingBuilder and the great APIs for processing XML.  I did that and eventually moved the code from a private Subversion repository to one on Google Code under an Apache license.  Until a few days ago, it sat for the most part unchanged.  In the meantime, my Groovy skills have improved a bit (I'm still no expert), the language has evolved, and the technologies around it have grown.  In this series, I plan to gradually bring the application up-to-date and polish up the code.  I'll update this posting with links to the other posts in the series as I write them.

Posts:

• NetBeans + Ivy = IvyBeans

Planned Posts:

• FogBugzReporter and Griffon
• Suggestions?

Groovy versus Scala (Update)

Back in March of last year, I wrote a post comparing Groovy and Scala.  Enough time has passed that I thought it was worth revisiting the topic.

In my original post, I reached the conclusion that at least for me, it made sense to first focus on Groovy and then later learn more Scala.  I still feel that way, but my thoughts on the matter have evolved.  How about combining Groovy and Scala in the same program or architecture?  That thought had vaguely occurred to me already, but it was solidified by the discussion of Twitter’s use of Ruby and Scala.  They started off using Ruby (Ruby on Rails, in particular) to run their whole site.  When they ran into performance and scalability issues, they determined what was causing the most trouble (back-end tasks) and gradually converted the relevant parts of the system into Scala.  This kind of polyglot programming makes sense to me.  It follows the principle of “using the best tool for the job.”  I think the combination of Groovy and Scala makes even better sense: they’re designed to run and interoperate with other languages on the same VM.  Not surprisingly, I’m not the first person to think of this.  I found two posts from Andres Almiray (“Griffon: Groovy & Scala working together” and the follow up “Follow up on Griffon/Groovy/Scala”) showing some practical examples and another on a different blog discussing the ability jointly compile “Groovy+Scala+Java”.  I’m excited to watch and perhaps participate in these exciting developments.

Side Note: On the subject of Groovy, when my one-year IntelliJ license was close to expiring, I decided to check out NetBeans.  I was pleased to discover it had quite good Groovy and Grails support.  I’ve been using the 6.7 milestone builds and now the beta, in order to get support for Grails 1.1.  If you haven’t tried Groovy/Grails development in NetBeans yet, you should.

Update: Here are links to the items Andres mentioned in the comments

• Groovy Transforms
• Scalify
• ”Groovy and Scala sitting in a tree...”

Update (Jan 12, 2010): Andres recently posted the highly relevant Groovy & Scala: a tale of two JVM languages

Blogger Causing Problems for SyntaxHighlighter

I kept noticing blog entries with beautifully rendered source code snippets and finally clicked the blue question mark in the upper left of one and discovered that they were using Alex Gorbatchev's SyntaxHighlighter JavaScript library. For my last post, I followed the instructions in the Usage Guide, using the hosted version since I can't upload JS files to Blogger, at least as far as I know. If you look at my post, you'll notice that I have two 1 line Groovy snippets and one 5 line Java snippet. The 1 liners were no problem, but when I first tried to display the 5 lines of Java it showed up as just one line with visible <br> tags where the line breaks should have been. It turns out that when I pasted the code into Blogger's post editor, even though it was in HTML source mode, it inserted <br> tags for the line breaks even though they were showing up inside of a <pre> tag. It turns out that there are two solutions to the problem. I'll explain the better one first, although I didn't find out about it until trying the other one.

When I asked Google for help, it led me to a page talking about how to use SyntaxHighlighter with Blogger. The post itself didn't contain any new information for me, but the comments were useful. "Robje" had apparently experienced exactly the same problem as me. "Debiprasad" then asked, "What is your settings for 'Convert line breaks' set to? In my case, if I set it to 'Yes', it's inserting <br/> into codes defined under <pre> tag." Ah ha! I looked on the "Formatting" subtab under the "Settings" tab in the Blogger control panel and discovered that mine was set to "Yes". Ack! What an annoying default! With it set to "No", it seems to fix the problem.

In case that doesn't work for you, Google also brought me to a page on what must been the old home for SyntaxHighlighter. Once again, the gold was in the comments. "fahd.shariff" mentioned that if you use the post editor in Blogger in Draft, this isn't a problem. As I said earlier, I gave this a try before finding the preferable solution and it worked for me so it's a reasonable solution to fall back on.

Succinctly Groovy

I was reading a post on displaying Google Visualization charts in Grails on mrhaki's blog and noticed something interesting. In his code, mrhaki wanted to get a handle on the newest (most recently modified) file in a directory. His approach was to list the files in the directory, sort them (in ascending order), reverse that, and then get the zeroth item:

def xmlFile = dir.listFiles().sort{ file -> file.lastModified() }.reverse()[0]

It's a nice example of how you can express a somewhat complex flow in a single line of Groovy. Still, it seemed like overkill to me and another reader who failed to identify him or herself. That reader linked to the Groovy Collections page and suggested using a Comparator that sorted the list in descending order to start with, but didn't include a code snippet. I liked the fact that this approach avoids the extra work to reverse the sorted list, but I wasn't sure it would be possible to express it so compactly and it still seemed more complicated than necessary. I looked over the Collections page and was reminded of the min(Closure) and max(Closure) methods available on Groovy's enhanced collections. So, rather than sorting the list of files, you can just ask for the max as determined by last modified date:

def xmlFile = dir.listFiles().max{ it.lastModified() }

Nice and simple, eh? Ignoring the overhead of imports and class/method declaration, neither of which are necessary with the Groovy snippet, here's the most compact way I know of expressing this using the Java standard libraries:

File xmlFile = Collections.max(Arrays.asList(dir.listFiles()), new Comparator<File>() {
  public int compare(File file1, File file2) {
    return (int)(file1.lastModified() - file2.lastModified());
  }
});

I'm glad Groovy's out there!

Grails Demo Webinar

I just found out yesterday that Graeme Rocher, SpringSource's Head of Grails Development, will be giving a Grails demo webinar on Thursday, March 19. It will consist of building a Twitter clone using Grails. I've seen similar demos at SpringOne 2008 and JavaOne and I'd highly recommend "attending" if you're interested in seeing what Grails can do.

JetBrains Seeder Program

JetBrains has recently started the JetBrains Seeder Program, an attempt to build a volunteer evangelism network for their products. I'm not sure I'd make a great evangelist, since my use of IntelliJ IDEA has mostly been limited to my experimentation with Groovy. I might join the program anyway, since IntelliJ is a great IDE (especially for Groovy) and I'm curious to see how the seeder program works.

Update: I decided that I'd already signed up for enough programs like this without taking full advantage of them. As a side note, I've been trying out NetBeans 6.5 for my Groovy and Grails projects and have been pleasantly surprised. I'll have a dilemma on my hands when it comes time to either renew or drop my IntelliJ license in April.

Groovy versus Scala

After looking at Groovy and Scala for a bit, I've come to a decision about how I plan to learn and work with them in the near future. I'm going to learn and use Groovy first and then move on to Scala. In this post, I'll explain why.

First, I'll cover the areas in which I see the two languages as similar. They are both script-friendly, object-oriented, can integrate easily with Java libraries and run on a JVM, and make heavy use of closures. Once you're familiar with either of the languages, it's obvious that they'd be great for dashing off a quick script. At the same time, their fundamental OO natures helps you produce (but does not guarantee!) maintainable code. Being able to use and interact with Java code means that you can take advantage of investments in existing technologies and that you can gradually transition a code base from Java to Groovy or Scala. Closures are a very succinct, clear way of expressing solutions to a lot of common problems. Whether or not Java gets them as a language feature, they're unlike to work as well in Java as in these two languages, where they haven't been shoehorned in.

Of course, there are also ways that the languages and developing in them are different. Scala has a greater emphasis on functional programming, has implicit static typing, and (having looked at a decompiled bytecode generated by scalac and groovyc using Jad) appears to translate into tighter code. On the other hand, Groovy looks much more like Java (making the transition easier), Sun has endorsed Groovy, the development tools for Groovy are currently in better shape (and that's without trying what they've got in NetBeans), and Grails seems like a very promising application framework.

So, when I put all of those considerations together, blended them a bit, and took a drink, I decided that Groovy should come first. It helped me make the decision to realize that whatever time and energy I put into Groovy should pay off when it comes time to move on to Scala. I think the languages require a similar mindset and follow similar enough philosophies that once I've got one down, the other should be substantially easier.

Groovy and Grails

Since I'm interested in increasing my RAD repertoire, I've decided to spend some of my research time on Groovy and the associated Grails web app framework, in addition to Scala. One nice thing about Groovy for an experienced Java developer is that its syntax is closer to Java than Scala's, while still running on the JVM and integrating nicely with Java. While familiar syntax isn't everything, it definitely can make your first steps into a new language a little easier. Grails follows a similar philosophy to that of Ruby on Rails, a well-known "coding by convention" web app framework, but integrates with established Java technologies like Spring and Hibernate. I wish they hadn't chosen a knock-off name like that, but it still looks pretty interesting. In order to learn Groovy, I decided to buy the book Groovy in Action, after seeing a lot of positive reviews for it on Amazon. I'm also checking out various articles I can find online, including the following:

• Jeff Brown on Groovy for Java Developers
• Mastering Grails: Build your first Grails application
• Grails Framework Reference Documentation
• Graeme Rocher on the Grails Plugin Architecture
• IBM DeveloperWorks Series: Practically Groovy
• Groovy Zone (at Developer Zone)
• About Groovy

Any other suggestions for me?