Having gained some measure of working experience with, and become an advocate of, the Grails framework of late, I thought I’d post some occasional tips that may help others along the way.
To help maintain a clean separation of concerns within your Grails application, you might find it desirable to maintain complex business logic outside of the context of Grails service and controller objects. Grails service objects can support transactions at a per-instance level and are maintained by the Grails application context in a way that make them great for a DAO-style pattern implementation. In fact, I prefer to keep all of my GORM-related interactions isolated to service objects rather than sprinkling them between controllers and services. Still, I believe you should avoid weighting service objects down with with complex business logic and calculations. Instead, traditional Spring Beans can be leveraged to aid comprehension and maintenance.
I’ve been having some interesting conversations with a colleague concerning the Groovy/Grails stack as a solution for web-based applications. Although I’ve become a Groovy believer, it doesn’t necessarily mean I’ve embraced Grails as a strategy for rapid application development. I certainly understand the attraction, but using one doesn’t necessarily mean you have to use both.
As far as Grails, there are many positives. In addition to being great for quick prototypes, it’s also great for situations where plug ins already afford a great degree of desired functionality, or super fast development in scenarios without a lot of disparity in functionality between different facets of the application.
I returned from SpringOne 2GX in DC last week. Lots of good exciting stuff being talked about.
Adrian Colyer, CTO of VMWare, did the intro. There was a great deal of emphasis being placed on the next generation of applications. Mobile applications (big surprise) and the increase of sophistication around clients (impact of tech like HTML5, web sockets (push notification), device agnostic applications, the cloud, high performance infrastructure, big data, and more) where hot topics. Had a couple of speakers get up next and talk about Spring and Groovy/Grails. Interesting to see a little thinly-veiled (but good natured) rivalry between the two camps.
I spent a lot of time talking to people and listening to presentations in the Groovy/Grails space. I admit that over the course of the last few weeks, I’ve gone from a Groovy language semi-skeptic (dynamic typing? Egads!) to a convert. AST transformations are way cool mysterious magic and deliver A LOT of power to POGOs at no or very low cost. Groovy is also great for ad-hoc scripting. Groovy and Java can be intermixed easily. Creation of new DSLs (Domain Specific Languages) is manageable although it seems like there’s a little bit of a learning curve associated with doing it “the right way”. Oh, did I mention closures!?! And I haven’t even mentioned the syntactic sugar Groovy provides yet.
I decided to take the plunge and turn in my windows desktop for a Macbook Air as my primary development machine. After reading some pros and cons, I figured I’d give it a try and so far so good. Mostly for development work, I run Eclipse (the STS variant) but also have been running XCode on a Macmini at work, so it seemed like a natural progression. I’m going to post some of my impressions here as I get more experience with it. So far, I’ve been pretty impressed. Mine has the sandy-bridge 2.0 GHz processor and 8 gigs of RAM. With the blue tooth keyboard, mouse and external monitor, it’s hard to tell I’m not working on the desktop. We’ll see if it can keep up as I start adding more projects to Eclipse and install some additional supporting tools.
I have been recently developing mobile applications using a combination of HTML5, CSS3, Phonegap, and jQuery mobile. This is an amazing stack for developing portable mobile apps without the need to write native applications for each platform. The HTML5 spec, although not finalized is gaining wider and wider adoption and looks to transform mobile application development as well as the traditional web experience.
One of the great features of HTML5 is the ability to store data in the local browswer cache that’s much more robust then that previously afforded by HTTP cookies. There used to be a couple of ways to accomplish this. One was by using the WebSQL concept allowing data storage accessible thorough an SQL type syntax and hierarchal data structures. This method has been deprecated by the W3C (at least for now).
I use subversion for source control. There may well be better options out there (git anyone?) but it works fine for me 99% of the time. Someone I know was recently wondering how to retrieve a directory he’d deleted from his subversion repository, so thought I’d post this.
Since there is not a general “undo” in subversion, you have to copy the directory (or files, which this also applies to) from the revision before the commit which removed the directory or file to the “head”. This allows you to retain the original history. You can actually do this all in one step, however doing it as a multi-stop process using a local working copy allows you to review and validate that you’re doing the right thing in between steps.
The basic process is that you first copy the revision with your deleted directory or file down to a local working copy, then copy the directory or file up to the original location in the remote repository.