Deepak Mittal « Intelligrape Groovy & Grails Blogs
Subscribe via E-Mail:

Deepak Mittal

http://www.IntelliGrape.com

Posts by Deepak Mittal:

  • How to delete all contents/objects of Amazon S3 bucket

    12 Nov 2011 in System

    If you have an S3 bucket with a huge number of files, and you want to delete the bucket, you need to empty the bucket first. If the bucket has a handful of files, then it is easy enough from the AWS interface, but if the bucket has a large number of files, then AWS interface is not an option; and you must use s3cmd or may be some other tool which allows this.


    s3cmd is a command-line tool for manipulating S3 buckets and objects; and as you would expect, it does have a way to recursively delete all objects in a bucket.

    s3cmd del –recursive –force <bucket_url>


    What’s annoying is that S3 does not provide this capability natively. The above command probably simply lists all the objects first internally; and then makes a delete call on each object.


    It took me a while to figure this out, because it does not seem to be documented, I found this in one of the comments on S3cmd page.

    -Deepak


    • Share/Bookmark

  • Why use Grails?

    16 Jan 2011 in Grails& Groovy

    Last week, I was talking to a prospective client, who instead of asking me, why we should go with IntelliGrape, asked me, why should we go with Grails? Considering the fact that I have been working with Grails for over 3 years and we are a Groovy/Grails focussed shop, it should have been an easy question to answer; but there were so many things that didn’t strike me when talking to the prospect; and explaining to him, why Grails is a good choice.


    So, I decided to list-down the reasons why I think Grails is great!

    1. Based on battle tested and proven Java frameworks (Spring, Hibernate, SiteMesh, Quartz, etc) : Now, Grails itself has been used by a lot of big enterprises and products such as Sky, LinkedIn, WalMart, etc and Grails is no-longer new; but if you consider the underlying technologies, then they have been in existence for almost a decade (I think) and have a very huge user base.
    2. Based on Groovy language : Groovy code is much more concise, expressive and DRY than Java code, which means there are fewer lines of code, which translates to much higher developer productivity and less code to maintain.
    3. A very responsive and supporting community and mailing list : Grails is not only about technology, it has a very responsive and supporting community. There is hardly any question that doesn’t get answered on the mailing list.
    4. GORM : GORM  provides a very easy-to-use and flexible layer over Hibernate and few other non-relational Data Sources.  This makes it extremely easy to talk to any GORM supported Data Source. GORM supports all relational databases which are supported by Hibernate (JDBC); and it has recently added support for few other Data Sources such as Redis, MongoDb. Support for more Data Sources such as Google Big Table, JCR is expected to be available soon.
    5. Doesn’t stop you from using the power of underlying frameworks : GORM does a good job of shielding you from dealing with Hibernate directly. But at the same time, if you want to bypass GORM and directly use hibernate API, map POJO/POGO to existing tables, then it does not stop you from doing so. Similarly, you can use the underlying power of Spring if you were to do so. Similarly,  you are not forced to use Groovy, you can choose to use Java or stronger typing wherever you want/need.
    6. Easy to set-up and get started : It is very easy for a Java developer to get started with using Grails; and start experiencing the joy of web-application development with Grails.
    7. Domain Centric approach towards application development : Grails puts domain classes at the center of the application, which IMO is a very good thing.
    8. Minimal server restart required while development : While developing with Grails, you don’t need to restart your web-container after making every small change. It uses an intelligent mechanism to reload and apply your changes. (There are still some cases where Grails requires container restart, but such cases are reducing with every release).
    9. Standard Project template and artifacts : Grails projects are easier to maintain because of the naming conventions and standard project structure. Conventions and standards make it very easy for new developers to quickly get familiar with the code and get up to speed on any existing Grails project.
    10. Testing support baked-in : Testing is a priority and first-class citizen in Grails. Grails promotes testing; and provides utilities to make testing easier — from low level unit tests to high level functional tests. In addition, Grails is not married to a particular testing framework. You can use JUnit, Spock, EasyB, Geb, Selenium, Canoo etc. Any testing framework can be made to work with Grails (by writing a plugin that hooks testing framework with Grails testing infrastructure).
    11. DRY / Convention over Configuration / No painful XML configuration & XML Management : You don’t have to write all of the plumbing/boilerplate code yourself when using Grails. This allows the developer to spend more time on writing code for developing features rather than struggling & configuring the framework components. Grails uses convention over configuration, uses sensible defaults and auto-wires based on simple naming conventions.
    12. Scaffolding : Scaffolding utilities provided by Grails is a great advantage when building prototypes to validate the idea; or to build Admin interfaces. For a lot of new developers evaluating Grails, scaffolding is the first thing that brings the “wow” effect.
    13. Clear separation of “environments” : The concept of Environments is a first class citizen in Grails. Grails allows you to easily manage environment specific configuration as part of the code base. For cases where you don’t want to store (for example, production environment passwords) environment specific configuration in the code base, you have the option of externalizing the configuration as well.
    14. REST support built-in : Grails provides built-in support for REST via URL Mappings, Data binding and rendering of objects as JSON or XML.
    15. Tag Lib Authoring mechanism : Grails makes it quite easy to modularize and reuse view layer code; especially because of the ease with which tags can be created. It is as easy to write a tag in Grails as it is to write a Java or a Groovy class.
    16. Data binding using command objects: Grails makes it a breeze to consume and validate form data; thanks to data-binding feature, command objects and the support for validators in Command objects.
    17. Integrates easily with already written Java code : Grails/Groovy integrates easily with code already written in Java. You can even intermix Java and Groovy code in the same file and it will work just fine. On one hand, it allows a Java developer to start using Grails very quickly; on the other hand; it allows use of already written Java code. I have been part of 2 applications, which initially started as a pure Hibernate + Spring MVC application, but were later moved to Grails. In such cases, we didn’t really have to throw away the already written code; and could just build on-top of already developed functionality.
    18. Plugin based development approach for modularity and reuse: Grails promotes reuse of code between different Grails application by modularizing your application in the form of plugins. Taking a plugin-centric development approach promotes and forces clear separation of concern and easy reuse.
    19. Tons of available plugins : Grails has a huge number of plugins which have been contributed by the core development team and other Grails application developers. More often than not, if you want to integrate an existing framework or use an API, you will find a plugin to make the integration much easier.
    20. Hundreds of small things that make development fun with Groovy and Grails : Can’t explain this, in order to understand this, you need to develop with Grails for a week and you would know :)



    I am not suggesting that there are no pain-areas when working with Grails. There are few pain areas (plan to cover that in a future post); but they are very few and the advantages far overweight the pain-areas.


    Besides the advantages covered above and the pain areas (that I plan to cover later), few area about which I have mixed feelings are:

    1. Scaffolding : Grails scaffolding gives you a good start, but doesn’t take you very far. There really hasn’t been much progress in the Grails scaffolded code since Grails came-out. Grails does allow you to modify the templates based on which the scaffolded code is generated, but the default scaffolding templates could definitely be better.
    2. Plugins : The number of Grails plugins that are available is huge. They do provide a lot of functionality and components out of the box. However, not all plugins are “quality” plugins; and not all of them are bug-free & actively supported & maintained. Some of them are too bloated. There are different plugins available to do the same thing. Sometimes, I do get  a feeling that I was better-off building the functionality from scratch myself; rather than spending the time to evaluate plugins and then using a particular plugin & finally giving-up after finding bugs/limitations in the plugin. Grails Plugins Collective is a great step to address this.
    3. View Layer Code : Though view layer code (GSP) is much neater and modular, but still there is duplication and verbosity and it doesn’t seem very DRY.

    I have tried to cover some of the Grails gems (no pun intended!) that I value.  I am sure that there are many-many more that I would have missed.  I hope to make it more complete after getting some feedback & doing some more thinking.


    Cheers!

    -Deepak

    • Share/Bookmark

  • Get absolute URL of site Grails application is available at?

    14 Oct 2010 in Grails

    Many times, we need to get the absolute URL of the site/application. One such case is when we are sending out links to the application in emails.


    The default Config.groovy file provided by Grails has a property with the name grails.serverURL. I have typically used it to get absolute URL (environment specific)  of the site Grails application is available at.

    This approach breaks in case the application is available as different sites i.e. the same application is  used to render multiple sites.  Here we need to get the absolute URL of the site that is serving the request (instead of application wide URL).

    We could use inject a utility method to HttpServletRequest class (similar to isXhr method injected by Grails in the same class)

    javax.servlet.http.HttpServletRequest.metaClass.getSiteUrl = {
  return (delegate.scheme + "://" + delegate.serverName + ":" + delegate.serverPort + delegate.getContextPath())
}

    After we do this, we could simply say request.siteUrl to get the absolute URL of the site serving the request. You might want to get rid of serverPort in the above method if the server is running on standard HTTP ports (80/443).

    Hope you find it handy!

    -Deepak

    • Share/Bookmark

  • How to generate DDL script for domain classes in Grails using schema-export target

    15 Jul 2010 in Database& Grails

    On most of my grails projects, I am used to let grails handle database schema creation for me. However, there is a project where the database is shared between multiple applications. In that project, we have to check-in our table creation/modification script as a SQL file, which is later executed by a DBA.

    I use a not-so-commonly known Grails command/script schema-export to help me deal me with this situation without much fuss of writing the DDL script myself.

    To generate DDL script for all the domain classes

    > grails schema-export

    The DDL script in this case is created as {PROJECT_ROOT}/target/ddl.sql file.

    You can also specify the path of the file where you want the schema file to get generated.

    > grails schema-export sql/ddl.sql

    Hope this helps!

    -Deepak

    • Share/Bookmark

  • How to allow non-root user to start/stop Apache process on a *nix server

    13 May 2010 in Linux& System

    Recently, I had to write a script to deploy a Grails application on a cluster of 7 servers without prompting for any kind of passwords. The load balancer was configured so as NOT to direct any request to the node, if the Apache process is not running on the server.

    So, my script to do the deployment on all the servers one by one is very simple — (a) stop Apache (b) deploy new version of the app on Tomcat using deploy.sh script lying on the server (c)  start Apache

    SERVER_IPS="10.20.30.40 10.20.30.41 10.20.30.42"
for i in `echo $SERVER_IPS`
do
     echo "Deploying on Web Host $i"
     ssh applicationUser@$i "cd; apache2ctl stop; ./deploy.sh; sleep 30; apache2ctl start"
done

    The only hiccup is that the applicationUser does not have rights to start/stop Apache.  After looking around for a while, I came to know about setuid which allow users to run an executable with the permissions of the executable’s owner or group.

    So, all I had to do in order to allow  applicationUser to bounce apache process is :

    sudo u+s /usr/sbin/apache2
sudo u+s /usr/sbin/apache2ctl

    I also had to set the trusted relationship between the production servers and my machine in order to allow password-less SSH login.

    After I did the above steps, I could deploy my application to all nodes in the cluster with a single command.

    -Deepak

    • Share/Bookmark