Thursday, December 2, 2010

Rails vs. Grails

I was recently asked the question: Rails or Grails? I needed to summarize the key differences and industry sentiment. This was my response.

Before I make any subjective comments, let me start with some objective metrics I found:

Now for my sentiments, I believe there are three key-dimensions: momentum, cloud-support, and people.


Rails has the momentum as evidenced by the number of committers and plugins available. Many of the rockstar developers I know are all now developing in Rails, supporting that community, etc. The underlying Ruby language is incredibly expressive and allows dramatic productivity improvements. (write less code that can do more)

Only a handful of rockstars I know are developing on Grails. Typically, those developing on Grails are in enterprises or markets that are comfortable with Java and they want to continue leveraging that investment. (infrastructure, app servers, production support, etc.) Grails/Groovy does have the advantage that It can continue to leverage the output of the Java community (e.g. Spring). The better projects within the Java community are quickly integrated into Grails. For example, Grails uses Hibernate and Spring Security under the hood. As those projects improve, so will Grails.

Cloud Support

Rails and the cloud go hand in hand. Again, of the rockstar Rails developers I know, nearly all of them are running on virtual hardware owned and managed by others. Some of those let others manage the entire application server / platform (e.g. EngineYard). In contrast, all of the Grails development I know of is running on hardware (virtualized) owned and managed by the company itself in their own data centers (or rented space). As mentioned before, this may actually have been the motivating factor to select Grails. That is not to say that there isn’t cloud support for Grails. And now that VMWare owns SpringSource, this may change rapidly now that enterprises will have a trusted name (in VMWare) to host their Grails applications.


Rails has the momentum, more committers and potentially a more active community, but lets not fool ourselves -- there is an army of labor out there to sling Java code. Offshore resources are readily available. The market for Rails is developing, but demand isn’t yet high enough to drive consulting companies to substantially increase their supply. As one of my good friends put it, “I’d love to develop in Ruby, but Java pays the bills.”. It is that sentiment, that has may limit the availability of resources.

However, even with readily available Java resources, that doesn’t guarantee the availability of Groovy resources. Both Grails and Rails require a slightly different mindset. If you take a Java developer and tell them to code in Groovy or Ruby, you’ll end up with Java code using Ruby/Groovy syntax. (not good) But at least the tooling, debugging practices, and libraries will all be familiar.

And just to stoke the fire...

Here are my entirely subjective scores:
Momentum: Rails (9) vs. Groovy (4)
Cloud Support: Rails (8) vs. Groovy( 5)
People: Rails (6) vs. Groovy (8)
Rails (23) vs. Groovy (17)

Tuesday, August 3, 2010

XML Validation with Eclipse

When I'm doing serious schema work, I typically use XMLSpy, but for simple schema validation it isn't worth leaving the IDE. As of late, I've been using the SpringSource IDE, which comes with XML plugins pre-installed. With the plugins, XML validation is simple enough. You just need to make sure you have the schemaLocation defined in your XML.

Let's say I have a simple document:

If you open the document, you can right click and Validate the document. If there is no associated schema, you'll receive a warning that says:
No grammar constraints (DTD or XML schema) detected for the document.

To rectify that, you'll need to specify the schema location in the XML. That will require namespaces. Let's assume we have the following simple schema with namespaces:
<xsd:schema xmlns:xsd=""
xmlns:philly="" >
<xsd:complexType name="zoo">
<xsd:element name="animal" type="xsd:string"/>

<xsd:element name="zoo" type="philly:zoo"/>

Now, lets revisit the simple XML to add namespaces and a schemaLocation element that references the above xsd. (zoo.xsd)

<philly:zoo xmlns:philly=""
xsi:schemaLocation=" zoo.xsd">

Note: To get the schemaLocation attribute you'll need the XMLSchema-instance namespace.

Now, you can right-click on the XML and it will validate. Also, you'll get the fancy element completion while you type. Rock on, even less reason to leave the IDE. =)

Saturday, March 27, 2010

SSH Port Forwarding Example

Like everyone, it takes me a few tries before I get a port forwarding command line right. Here is yet another example for everyone, just in case you happen to have this specific example.

Lets say you want to get to your database, but it isn't exposed:

You want to forward some port on DMZ to the DB. Lets say it is Oracle running on 1521. Then, from the DMZ host you should issue the following command:

ssh -g -L 5000:DB_HOST:1521 boneill@DB_HOST

At this point, you should be able to connect to DMZ:5000 as if it were DB:1521.

REALLY REALLY IMPORTANT is the "-g", that allows remote connections to 5000. Otherwise, it will just bind to the local interface and you won't be able to connect from CLIENT.