Saturday, April 17, 2010

Putting the Groovy Foot in the Enterprise Door

Many of us would love to use Groovy in or day jobs, but are stuck in a large company that is slow to adapt. Lots of large companies (and some small ones) often have a painful bureaucracy in place that makes any major shift difficult.

I can't claim that I've converted anybody from a Java to Groovy shop, or even put Groovy into wide use, but I have found some reasonable ways to get approval of Groovy code in an "enterprise" environment.



1. Fix a particularly bad pain point.
Most people interested in Groovy are painfully aware of the places that Java breaks down. Much of the time, these same areas are simple and elegant in Groovy. However, you're not going to sell Groovy in a tough environment by changing for loops to each statements.

There are a lot of places that do provide a real incentive to architects and business owners. For example:

Similar, but different classes: If you use Axis to generate classes for similar but separate schemas, duck typing can save you tons of mapping code. Rather than copying and pasting your mapper to a new class and changing all of your imports, you can make your mapper a Groovy class and remove the strongly typed parameters when possible.
Validation code: If you have a large amount of validation code that checks for nulls and/or empty strings over and over you can save a ton of time by using both Groovy Truth and null safe operators
Java

if (person != null && person.getFirstName() != null &&
person.getFirstname().trim().length() > 0) {
}

Groovy

if (person?.firstName) {
}

Imagine these chunks of code replaced over and over again in your code. This is a very real time savings.

An important point here is that the Groovy code can be isolated from other layers of code. That allows skittish architects or tentative tech leads to feel safer about making the changes.



2. Testing
Testing is the most frequent suggestion I've heard for introducing Groovy to a new environment. It's a good idea. You're not touching production code so you aren't introducing new jars to your package or risking your product with a new technology. It also allows you to learn and showcase Groovy's advantages over Java.

Unfortunately for me, this has seldom proven to be feasible. Many times you can be in an environment where the build is not within your control and thus the execution of the unit tests is out of your control as well.

If that's the case then you are back to item #1, fixing a particularly bad pain point. This may fit very well as often times tests are repetitive and verbose. Groovy makes splitting out the common code easier with features such as closures and currying.

If you do have control over how your tests are executed, by all means start using Groovy for them. What are you waiting for?



3. Scripting
Groovy is often described as a scripting language. It is really very much more, but if you’re writing scripts anyway, why not use Groovy? With AntBuilder you can do anything that Ant can, but without all of the XML. You can also easily execute items in the shell and capture output. As a somewhat random example, here’s a simple script that goes through all log files in a directory, line by line and prints the faults.

def fileDir = "logs" as File
def xmlSlurper = new XmlSlurper()
fileDir.eachFileMatch(~/.*\.log/) { log ->
log.eachLine { xml ->
def rootNode = xmlSlurper.parseText(xml)
println rootNode.name
if (rootNode.Body.Fault) {
println rootNode.Body.Fault.Code.Value
}
}
}


Or one to grab SVN properties and put them into a map.

def props = [:]
"svn info".execute().text.splitEachLine(":"){props[it[0]] = it[1]}
println props
println props["Revision"]

There are certainly other tools that can do these things, but if you’re looking for a way to get Groovy started at your company, this may be it. You never know. If it becomes popular enough as a scripting alternative it may spark more interest in the language in general.



4. Gradle
The last item I have fits only certain scenarios, but it’s worth mentioning it since it’s something in which I’ve personally found value.

In my perfect world, I would be using Gradle to build all of my projects, but again we’re in an inflexible enterprise environment right now. For those stuck with unwieldy enterprise builds, Gradle can save you some pain even if you don’t use it for your build system.

I’m not going to get too in depth on Gradle in this post, so let’s just assume that you have the basic gist of what it is. Due to the fact that Gradle easily imports builds from Ant and Maven, you can use it to tweak your existing build.

For an Ant build, you can use

ant.importBuild 'build.xml'

That’s pretty much it. Now all of your Ant targets are available in Gradle. You can manipulate them in ways that are difficult or impossible in Ant. Plus, it won’t affect your enterprise build so you can experiment at your leisure. I’ll save some of the details of how I’ve used this for a future post. Depending on how much pain you save in your local environment, you may be able to make a strong case for using Gradle by explaining the saved time/effort.

I’m sure there are plenty of other ways you can get some Groovy into your environment. The main point is that once you find an area to do this, you have something to point to when bringing up Groovy as a solution to other problems. With that ammo, you may be able to convince those that were previously skeptical.

Friday, June 19, 2009

Caldav suppurt finally puts Google Calendar on iphone

Like a lot of people I have a Microsoft Exchange account at work and a Google account for personal use. Unfortunately the support for Google calendar on iphone has been hard to come by. There have been a few hacks to make it work. One involved setting up a dummy exchange account for your Google account on the iphone, but since iphone only allows one Exchange account per phone, this didn't solve the problem of the work and personal accounts.

Thankfully due to Google's support of CalDAV, and the addition of CalDAV to iphone 3.0 software, those of us who would like to use both Exchange and Google are able to do so.

I haven't seen much documentation out there for this, so I thought I'd post the instructions here. It's really pretty simple.

On your iphone, go to Settings->Mail, Contacts, Calendars->Add Account...
Select Other
Select Add CalDAV Account
For server put www.google.com
Enter your Google username and password
Click Next
Iphone appears to be aware of the proper CalDAV URL for Google accounts and fills this in for you.
If all is well you should see the "account verified" message.

With this set up you should now be able to see your Google calendar in the built in calendar app on iphone. You are also able to add events to your Google calendar within that app. When you add the event there is an option for Calendar that you can use to switch the desired target. I've also added my wife's Google calendar as well with no problems, so it's not subject to the one account limitation that Exchange has.

The big drawback I've run into is when you have multiple calendars in one Google account. I have a separate calendar for birthdays. When linking to the Google account through CalDAV though it only picks up your main calendar and leaves out the birthday calendar. I've gotten around this by using the iCal support and linking to this calendar separately. With iCal you can't add items to the calendar, but at least you can see it.

Another drawback could be performance. I've seen intermittent performance issues with iphone 3.0 so far and definitely some lag in the calendar. It hasn't been horrible so far, but I could see it getting annoying after a lot of use.