Tuesday, 31 May 2011

Grails Image Crop Using Jcrop

A user in an X-Events hosted site should be able to upload his picture and use it as a profile picture. Also, the uploaded picture has to be cropped to a certain resolution before it is used.

You might have seen many websites nowadays have a profile picture. And when you upload a profile picture, you are usually prompted to crop the picture (sometimes with certain forced resolution), and it is this cropped picture that is used from then onwards. I was required to implement a similar functionality here. I decided to use Jcrop for the JavaScript side of the cropping mechanism as it was based on jQuery and we were already using a bit of jQuery in our application. Here I illustrate how I did the job.

Multi-Tenant Architecture

As SaaS (Software as a service) takes big steps in these days, lots of new methods or rather less used methods are getting more attention. Making an application truly Multi-tenant is one of the key feature in SaaS. In xEvents, we made the application multi-tenant capable in the initial phase of the project to reduce incremental time and cost factor if we converting into multi-tenant based application in the later stage. We had lots of discussions going back and forth to make right design decision for implementing the multi-tenant enabled platform which is more suitable for xEvents application. We thought it is worth to post here on this topic.

Possible Design solution: One of the Key factor while designing the multi-tenant design is the database design. As we will be intent to store all the tenant data in our server and mostly same set of application code will be accessing different tenant data, designing suitable database structure turned out to be a tricky call. In a broad category, we can implement in 3 different ways:

1. Isolated database for each tenant
2. Isolated schema for each tenant
3. Shared schema for all tenants

Though i have stated three different individual type, it is a continuum spectrum. Most of the time we need to choose a mixed approach (for e.g. sharing few tables/schemes across the tenant and also few separate table per tenant). Meaning, choosing the correct type is fully depends on type of application.

(source: http://i.msdn.microsoft.com/dynimg/IC150005.gif )

Few worth noting factors while making the design decision : No. of Tenants, customization required per tenant, Scalability, database size / maintenance cost, No. of users per tenant, data privacy/isolation issues. This[1] article clearly listed the pros and cons with a detailed analysis.

Multi-tenant grails plugin: Once we are clear with the design in our mind and having grails powered by plugins, now we have to pick-up the right plugin and fine-tune the configuration as per the our requirement. Multi-tenant plugin[2] provides out of box implementation for multi tenant based applications. Though, this is not clearly (rather fully) documented, this page[2] will give you a very good idea to start with and about how this plugin works. Here is our few cents:

1. Although, this plugin suppose single database per tenant, it is little immature as of now[June,2011].
2. There is another version of this plugin[3] (using Hawk Eventing and Hibernate Hijacker) to support single db per tenant. But this is still in the experiment mode.
3. This plugin have incompatibility issue with searchable plugin. we tried few suggestions given in forums to fix this issue, but in vain. (Though, i am not sure of the fact, but this might be because both the plugins modify the datasouce in the beginning or because of the subscription to the hibernate events).
4. Need to be careful about having common pages like admin page which will access data across the tenant. It is not available out of box from this plugin.

[1] http://msdn.microsoft.com/en-us/library/aa479086.aspx
[2] http://multi-tenant.github.com/grails-multi-tenant-core/guide/index.html
[3] http://multi-tenant.github.com/grails-multi-tenant-single-db/docs/v0.7.2/guide/

Custom Password Encoder for Grails Spring-Security Plugin

The spring-security (core and others) plugin is very handy for incorporating user (and role) based functionalities for a grails application. The plugin comes with a lot of features out-of-the-box. And more often than not, some of the basic features can be used as is. However, there are occasions when a little bit of customization might be required.

In this project, I was required to use a custom password encryption algorithm. The spring-security plugin uses the 'SHA-256' algorithm by default. This can be changed to use other standard algorithms (MD2, MD5 etc.) by adding the following lines (if, for example, MD5 encoding is required) in /grails-app/conf/Config.groovy:
But what I wanted was to use a custom algorithm of our own, not the standard ones. Fortunately, this is again, very easy. Because of Spring's dependency injection, we can easily create our own password encoder and inject it. The steps to do the same are explained here.

Multiple 'MailSender's in grails-mail Plugin

In the project, there was a use-case where we have to use different SMTP configurations for sending mails from different user accounts. To elaborate, each user in the system can create a 'site' which sends notification mails using custom mailing configuration provided by the user. I had a look at the grails-mail plugin, but found out that it currently did not support multiple MailSenders.

So I modified the plugin and added a new method in which we could specify a custom MailSender. This blog post contains information on how I did it.

Perl, Ruby, Java, Groovy, Python?

xEvents is now well on its way, with major components being added to the system at each iteration. Vithun and Prabhu will soon be posting about interesting technical challenges we've encountered so far and are grappling with now. For my part I'd like to say something about our choice of Groovy and Grails as platform.

PhilPapers, our flagship product at the Institute, is mostly written in Perl. It's made up of kilometres of Perl code which I know inside out. At this stage I'm constantly reusing tools from this code base, and I feel I know every little quirk of the stack PhilPapers is built on --MySQL, Apache, HTML::Mason, FastCGI. These are compelling reasons to stick with a platform, yet I decided to jump ships. There are two main reasons for this:

1. Labour shortage. Perl's title as 'glue of the web' is long lost and the population of Perl mongers appears to be dwindling. Sure, there are still large systems running on Perl (I gather it's in widespread use at Amazon and BBC), but it's not a platform new entrants to the profession choose, and, realistically, junior programmers are often all that I can afford, so Perl is not a good choice for me. Last time I had to hire a Perl programmer, I very nearly failed.

2. Archaic tooling. My love relationship with Vi goes back about 15 years, and I hate lifting my hands from the keyboard to click, so I'm not referring to those colourful IDEs with eye-busting white backgrounds. I'm talking about things like HtmlUnit, a Java headless browser (that's right, a headless browser which runs Javascript et al, not a mere HTTP client + HTML parser). I'm also thinking about Hibernate, an ORM that's so far ahead of the Perl equivalents (DBIx, Rose::DB::Object) I feel like I've wasted years of my life working around the latter's flaws.

Another factor that entered my decision is that one day we'll need to rewrite PhilPapers yet again (hopefully not before 2020) to make it Web 5.0 and incorporate all the latest conveniences of modern life. When that day comes it will be great to be at ease with the state-of-the-art platform. This is also part of why I've chosen Groovy+Grails as my next platform.

Groovy is a language that compiles into Java bytecode. From .groovy files you generate .class files which can be used exactly like .class files compiled from .java files. You can even mix Groovy and Java classes in your programs (using either Java from Groovy or Groovy from Java). In fact when you code in Groovy you use Java libraries all the time because that's a big part of the attraction of the platform: the API is a superset of Java's vast API ecosystem. Grails is an application framework similar to Rails for Ruby. It provides all the main benefits of Rails, plus this: it's an extension of Spring, arguably the most battle-tested and slickest application framework there is.

Many of the virtues of the Groovy+Grails combination are obvious from the above. I won't say much more on this because the Grails web site already has a good sales pitch. The only thing I'd like to add is that Groovy as a programming language is perfect (for me). Its C-style curvy brackets make it feel homely to someone who's spent most of his waking adult life starring at Perl, C, or Java code. Its syntax feels maximally clean and concise, but not obscure like Perl's. It's incredibly predictable. It has all the things that Java misses, closures and scripts in particular. It also has the things that Perl misses, for example, proper OO, without missing any of the cool Perl features which make it so well suited to Web development and text processing (e.g. string interpolation, compact regular expression handling). Its dynamic typing system is right on the sweet spot between paranoia and helpfulness.

Barring any major social or economic obstacles (I'm a little worried about Oracle trying too hard to monetize the JVM), I predict that Groovy+Grails is going to steadily gain in popularity over the coming years, because it's a winner on all counts from a technical point of view. As for finding Groovy+Grails developers, any Java programmer can be converted into a Groovy+Grails programmer within a few weeks, because the syntax is incredibly easy to learn and the APIs are basically Java's. I predict a stream of would-be converts for the foreseeable future.
Copyright David Bourget and University of London, 2011. This blog's content is license under the Attribution-ShareAlike license.