Wednesday, July 3, 2013

JavaScript, Backbone.js, node.js, MongoDB

I've been spending a lot of my personal development time looking into JavaScript frameworks.

It's amazing how much the language has grown up.  I still remember doing Web Development in college (back in 1998) for University websites and using JavaScript for client-side form validation.

You know, the tacky alert pop-ups that you hit the user with, one after another, when he/she has not filled in all the fields of an HTML form.  Ugh.

Well, given the long and sordid history of JavaScript, I have been amazed at how it has grown and evolved (AJAX, Prototype, jQuery, Backbone), and recently learned that people are doing server-side development in JavaScript on Node.js.

I will admit, I was a bit skeptical about Node.js when I first heard about it.  My first thought was "that cannot be performant", thinking again back to client-side scripting.

However, as I read more and more about Node.js, I began to think "This isn't your father's JavaScript."  What I did not realize initially was that Node.js runs on Chrome's V8 JavaScript engine, which is written in C++.

I'm digging into it and thinking about building a Web Application using a combination of:

Bootstrap + Backbone (front end) -> Node.js -> Mongoose (OR/M) -> MongoDB (Database).

Wednesday, September 26, 2012

Grails, GORM, lazy loading one-to-one

I spent all yesterday evening trying to figure out a way to lazy load a one-to-one relationship. At first glace, this probably looks like an academic exercise. However, I have a very pragmatic reason for needing to lazy load a one-to-one relationship.

I have Property and PropertyDetail Domain Classes. 

For now, I am storing images in the database.

Long-term, I am going to look at using Amazon S3 for storing images, but for a personal project where I am still learning, it seems like a decent compromise.

class PropertyDetail {

    static constraints = {
        description type: 'text'

    static belongsTo = [property : Property]

    String description
    byte[] imageMain
    byte[] image1
    byte[] image2
    byte[] image3
    byte[] image4
    byte[] image5

I am going to have a list page for Property domain class.

I definitely do not want to take the hit of pulling the PropertyDetail class, not with the images stored in the database.

I hit a wall late evening, when I discovered the following Jira Issue: GRAILS-5077 hasOne mapping is by default eager and cannot be changed to lazy.

However, this is an older JIRA issue, and I did see on the recent Grails 2.1.1 documentation information on doing lazy one-to-one.

My new plan is to:

  1. Try the approach documented for Grails 2.1.1.
  2. Turn on SQL logging
        datasource { 
            logSql = true 

  3. If that does not work, drop back and remap this relationship as a many-to-one.

Saturday, September 15, 2012

Adventures with Grails and Spring Security

Well, I had initially started down the path of creating my own User/Role security model for a Grails App I am building at home in the evenings/weekends.

However, I gave it a little more thought and going back to the "why re-invent the wheel" philosophy of development and just started looking into leveraging Grails Spring Security Plugin.

Found this great article on quick start with Spring Security:

Here's what I've done thus far:

1. Modify my BuildConfig.groovy to include Spring Security:

    plugins {
        build ":tomcat:$grailsVersion"
        compile ":spring-security-core:"
        compile ":twitter-bootstrap:2.1.1"
        compile ":resources:1.1.6"
        runtime ":hibernate:$grailsVersion"

2.Run s2-quickstart:

    s2-quickstart User Role Requestmap

3. Refactored the generated Controllers LoginController and LogoutController so that they are in the package. 

4. Customized Password algorithm to SHA-512:


I feel like this is just scratching the surface. I ended up running into questions and needed to post on StackOverflow: Grails Spring Security Custom UserDetailsService (goal of email in place of username).

Monday, September 10, 2012

Technology Stack

It's late Monday evening, and I'm working on a new personal development project. 

I think I've selected my technology stack:
  • Twitter Bootstrap 2.1.1
  • Grails 2.1.0
  • MySQL 5.5
I find Grails to be rather amazing because it is, for all intents and purposes, a complete stack.  It even has a Twitter Bootstrap plug-in, as well as MySQL Connector/J plug-in, so I guess I could technically say that my technology stack is "Grails".

When working on Java / Java EE projects, I've grown so accustomed to saying "My technology stack is jQuery/JSP/Taglib/Struts/EJB3/Spring/Hibernate/Oracle". 

It feels pretty neat to say "My technology stack is Grails". 

Since I am looking at eventually hosting in a PaaS environment, I am not really concerned about details like OS and Application Server.

However, for my own development environment I am using the following:
  • Windows 7 (thought about switching to Fedora 17 KDE, decided not to take hit on installing a whole new OS).
  • Tomcat 7.0.30
I've made the mistake in working on past personal projects during nights/weekends and getting too caught up in technical details and not focused enough on building a product. 

Grails BuildConfig.groovy: dependencies vs plugins

I am configuring BuildConfig.groovy for a test/sample project.

One item I have always found a bit confusing is the question of the dependencies closure block vs the plugins closure block.

There are times where I have seen that a library could be specified in either.  Also, the version of library would be different.  

For example, the following dependencies closure is provided out of the box with Grails 2.1.0:

    dependencies {
        // specify dependencies here under either 'build', 'compile', 'runtime', 'test' or 'provided' scopes eg.

        // runtime 'mysql:mysql-connector-java:5.1.20'

Obviously, this leads me to conclude that if I need MySQL Connector/J support, all I have to do is uncomment that line.

However, I have also successfully gotten MySQL Connector/J support by doing the following (I have verified this works):

    plugins {
        compile ":mysql-connectorj:5.1.12"
        compile ":searchable:0.6.3"
        build ":tomcat:$grailsVersion"
        build ":hibernate:$grailsVersion"
        runtime ":database-migration:1.1"


I found the following Nabble post from Graeme Rocher explaining the difference of plugins {} vs dependencies {} blocks

Graeme states:

plugins { } block is used declare dependencies on grails plugins found
in the portal ( and built locally.

dependencies { } block is used to declare dependencies on JAR files
and third party java libraries typically found in Maven central (see

This made sense to me.  What it did not answer is when I am able to obtain a library via either, which is preferable, if there is a "best practices" or "recommended" approach. 

Knowing that I can get my MySQL Connector/J library from either one (I am certain I would not want to do both), I would just be curious as to which approach is better.

Wednesday, August 22, 2012

Grails, Scaffolding, GSPs

I've spent the last few evenings reading up on Grails Domain Classes and Controllers, the 'M' and 'C' portions of MVC, respectively.

I have been working through Getting Started with Grails, Second Edition by Scott Davis and Jason Rudolph

Throughout the process of working through their Racetrack sample application, I have been switching between MongoDB 2.0.6 and MySQL 5.5.25. 

In the process, I have hit some bumps in the road regarding MongoDB Issues with Grails Scaffolding that do not occur in MySQL

I posted these on StackOverflow and mentioned in LinkedIn discussions.  This has led me down the path of going so far as to trying to download a tag from GitHub for newer builds of the MongoDB Plugin for Grails (as of today 2012-08-22, 1.0.0.GA is the latest official release for this plug-in).

I've also learned a lot about MySQL in the process of setting it up, securing it on Fedora 17. 

Neat things I've learned:

Now, I'm starting to learn about the 'V' aspect of MVC in Grails.  I am digging into GSPs. 

Wednesday, August 15, 2012

MySQL on Fedora 17 and Grails

I was running into some strange behavior when writing a test Grails Application that uses MongoDB (MongoDB 2.0.6-2.fc17 installed via YUM) for storage.

Specifically, when I use scaffolding, I am unable to reorder the fields using the static constraints block.

I saw this mentioned on a post in the Nabble forum for Grails, alluding to this possibly being a problem with MongoDB.  However, I was not able to find any more information on scaffold field ordering via static constraints not working for MongoDB.

In order to run this down further, I decided to take my same test application and run it using MySQL for storage.  I haven't used MySQL for years, so it took a little to get re-acclimated.

  1. Quick check for MySQL on the Fedora 17 server:
    # yum list mysql
    Loaded plugins: langpacks, presto, refresh-packagekit
    Installed Packages
    mysql.x86_64                       5.5.25a-1.fc17                       @updates
    Available Packages
    mysql.i686                         5.5.25a-1.fc17                       updates

    Yay, it's already installed. Looks like it shipped with 5.5.25a-1, a specific build for FC17.

  2. Enable the Service upon startup:
    # systemctl enable mysqld.service

  3. Secure it:
    # mysqladmin -u root password ********

  4. Enable remote connections from development machine for administration.
    # mysql -u root -p mysql
    Also, I opened up port 3306 through the firewall on the FC17 server.

  5. Next, I logged in via MySQL Client and ran Create Database, Create User,  and Grant All to create a new Database for my Grails Application, create a User for this Database, and Grant all privileges to that User for the newly-created database.
  6. Finally, I changed my Grails App Plugins (removed mongodb, installed mysql-connectorj-5.1.12 and hibernate-2.1.0) and updated DataSource.groovy:
    dataSource {
        pooled = true
        driverClassName = "com.mysql.jdbc.Driver"
        dialect = "org.hibernate.dialect.MySQL5InnoDBDialect"
        username = "racetrack"
        password = "********"
    hibernate {
        cache.use_second_level_cache = true
        cache.use_query_cache = true
        cache.provider_class = "net.sf.ehcache.hibernate.EhCacheProvider"
    // environment specific settings
    environments {
        development {
          dataSource {
             dbCreate = "create-drop" // one of 'create', 'create-drop','update'
             url = "jdbc:mysql://ptenn:3306/racetrack"
       test {
          dataSource {
             dbCreate = "create"
             url = "jdbc:mysql://ptenn:3306/racetrack"
       production {
          dataSource {
             dbCreate = "update"
             url = "jdbc:mysql://ptenn:3306/racetrack"