As I’ve mentioned before, we here at Cantina are big fans of Groovy and Grails, and we are disappointed that the language is not used more widely. To do our part to spread joy that is Groovy, we’ve started a group on Meetup.com for Boston-based users (start local!). Check us out here: http://www.meetup.com/Grails-Boston. Our focus will be to get together with other fans of Groovy/Grails and share ideas, present work members have done, show-off some plugins (check out ours), and generally expand everyone’s knowledge of the language and framework. We’d love to have anyone who’s interested join us, even those new to Grails.

• Leave a comment...

The changing dynamics of the web has been something we’ve talked a lot about lately.   The shift toward real time services has impacted the way companies are thinking about the web.  Twitter is currently leading the charge in the real time information and many people think it’s going to become the real time search engine of the web, ousting Google when it comes to real time information and current events.

Techcrunch just wrote a great article on how we’re shifting away from pages and into streams.  I think the article raises a great point that this is a huge opportunity for start-ups to really change the status quo and start developing applications that work in real time.

So, the question I would raise is how can your company shift it’s products toward a real time web?  Think about the big internet brands and what would happen if they had to live in the real time web.  What if companies like Amazon, Ebay, and Google had real time services?  We also know that every time our economy has gone through a shift, new companies and ideas emerge that make us re-think our perception of the web.  In other words, if you’ve got an idea for the real time web, this is your chance to go out and build it.

• Leave a comment...

We’ve had a bit of time to jump back into Grails plugin development (or maintenance as it were) and couldn’t be happier to find the recent improvements in Grails 1.1. The biggest improvement (though perhaps not advertised as such) to me, was the inclusion of functionality that allows plugin developers to build test applications against the live, “unpacked” version of the plugin, which is to say, the Grails application that implements the plugin itself.

This may sound esoteric, but to someone doing plugin development in Grails, it’s a life saver, and here’s why.

When building a plugin for Grails, the plugin itself is built as a Grails application. This has many benefits, including in some cases being able to run the plugin and test controllers and domain classes directly in the running plugin. However, most, if not all plugins are intended to plug into another Grails application. Given that, the only real way to test the usability of your plugin API, and whether the plugin works in the context of larger Grails application, is to install the plugin into another Grails application. Here’s an example:

1. I’m developing Plugins A and B to be installed in a new Grails CMS application I’m building
2. Plugin A depends on Plugin B to function
3. Once Plugin B is in good enough shape, I’ll install it into Plugin A using the Grails install-plugin command
4. Once Plugin A is in good enough shape, I can install it and Plugin B into my Grails CMS application
5. After testing the CMS for a while, I discover a bug in Plugin B which also requires a small change in Plugin A to accommodate the bug fix (are you still with me?)
6. I fix the bug in Plugin B and repackage
7. I remove Plugin B from Plugin A and install the latest version of Plugin B into Plugin A to make the changes required in Plugin A and repackage
8. In the CMS application, I remove both of the plugins and reinstall both Plugins into the CMS
9. I become tired of installing and uninstalling plugins and go out for beers

With Grails 1.1, this development cycle is improved drastically. Now, during development you can provide explicit locations for Grails plugin projects, without needing to install the plugin, to develop against that plugin. Here’s an excerpt from the Grails 1.1 release notes:

An application can now load plugins from anywhere on the file system, even if they have not been installed. Simply add the location of the (unpacked) plugin to you BuildConfig.groovy file:

// Useful to test plugins you are developing.
grails.plugin.location.jsecurity = "/home/dilbert/dev/plugins/grails-jsecurity"

// Useful for modular applications where all plugins and
// applications are in the same directory.
grails.plugin.location.'grails-ui' = "../grails-grails-ui"

This is particularly useful in two cases:

1. You are developing a plugin and want to test it in a real application without packaging and installing it first.
2. You have split an application into a set of plugins and an application, all in the same “super-project” directory.

Now if you want to test your plugins in the context of a larger application, you can do so without the pain of constant reinstallation.

• Leave a comment...

One of the founders of Woofoo just wrote a terrific article on what it takes to build a web application called “Web App Autopsy“.  They were lucky enough to get some great information from three other firms, Blinksale, Feedburner and RegOnline.  I think the charts and information they put together are great, but if you dig into the numbers a little deeper you start to see what it really takes to build a web application.

From a time perspective (you have to exclude RegOnline because it was a nights a weekend project) it takes on average about 5 months to launch one of these applications and you need roughly 3 or 4 engineers to get it done.  My guess is that most of these companies boot strapped their development but current estimates say developing a web application costs anywhere from 50k to a few hundred based on complexity.  It’s also great to see these rapid development frameworks, such as Ruby on Rails, are accelerating development and time to market.

Lastly, I would also emphasize their focus on business processes. Many early stage companies completely neglect support needs, such as returns, customer compliants, etc.  It can end up costing you a lot of time and money if you don’t have systems on the back end to handle customer support issues.

• Leave a comment...