Nick Zhu on Craftsmanship

Since Grails 1.1 the unit test capability has been greatly improved for pretty much anything you can imagine in Grails from domain class to controller even taglibs can be easily tested in plain old junit with the help of GrailsUnitTestCase and many of it's cousins such as ControllerUnitTestCase specialized in different aspects of the framework.

However the fantastic mocking framework is not without its boundary. The mockDomain method provided by GrailsUnitTestCase has its limit, it does not provide the capability to fully mock GORM dynamic finders as well as criteria and executeQuery methods. Luckily the test framework also provide the ability to mock any method regular or static using mockFor() method (details) however it comes short when you have static query method created on domain class. Imagine the following example:

class Foo{
        ...

        static def listAllAwesomeFoo(keyword, params) {
                Foo.executeQuery('''select f from Foo as f
                            inner join f.tags as t
                            where f.awesome = true and t.keyword = ?''',
                        [keyword],
                        params)
        }
}

class FooService {
        def doSomethingUseful(){
                def awesomeFoos = Foo.listAllAwesomeFoo('something', [max:10])
                ....
        }
}

Now to test the FooService you need the ability to stub or mock the Foo.listAllAwesomeFoo() method and since its a static method there is really no easy way to do it even with Grails test framework; or is there? This is where Groovy MOP can save you a lot of grief and time. To stub this kind of static method all you need to do in Groovy is add the following code before your test code:

Foo.metaClass.static.listAllAwesomeFoo = {keyword, params -> [foo1, foo2] }

Thats it. Now you can happily test all your service logic without worrying about stubbing the whole database to run the HQL. Later on you can always isolate and use integration test with in-memory database to test the HQL separately.

Labels: daylog, grails, groovy, mock, mop, stub, unit test

If you are like me tired of outdated Grails plugins and verbose API in Java for Open Flash Chart 2, here is a short demonstration of generating OFC2 using just naked Grooviness. OFC2 charts are driven by JSON data feed, and with Grails' built in JSON converter and support you really don't need another API or plugin to use OFC2. Just download the flash binary and javascript from http://teethgrinder.co.uk/open-flash-chart-2/ and create a controller in your Grails application. Now you have two choices, you can either use the JSON builder in your controller or just plain maps to generate JSON data. I chose plain maps since its easier to manipulate and examine in unit tests, but the JSON builder will work just as well with even more expressive DSL. Here is an example of a simple chart:

def chartData = [
    "elements": [ ["type": "line", "values": [ 1, 2, 1] ] ],  
    "title": [ "text": "Wed Feb 03 2010" ]
]
render chartData as JSON

Now you are free to use the latest OFC binary without worrying about upgrading the plugin or mocking the complex API in your test. The syntax is extremely similar to the JSON output so you can basically learn from checking out the examples on OFC site. Here is a more complicated example with tooltips, on-load animation and custom look-and-feel.

[
    'elements': [
        ["font-size": 10, "text": "Daily Info", 
         "tip": '$#val# 
 on #x_label#', "type": "line", "width": 4,
         "dot-style": ["type": "dot", "dot-size": 5, "colour": "#DFC329", "tip": '$#val# 
 on #x_label#'],
         'values': values, 'colour': '#8F9CFF', "on-show": ["type": "drop", "delay": 0.5]
        ]
    ],
    "is_decimal_separator_comma": 0,
    "is_fixed_num_decimals_forced": 0,
    "is_thousand_separator_disabled": 0,
    "num_decimals": 2,
    'title': ['text': "Sample Chart"],
    'x_axis': ['steps': 10, labels: ['steps':10, 'visible-steps': 5, 'labels': labels], "colour": "#0067A6", "grid-colour": "#FFCAA8"],
    'y_axis': ['min': 0, 'max': yMax, 'steps': calculateYAxisSteps(yMax), "colour": "#0067A6", "grid-colour": "#DEFFA8"],
    'bg_colour': '#FFFFFF',
    "tooltip": [
        "colour": "#5CC0FF", "background": "#FFFFFF", "title": "{font-size: 14px; color: #5C6FFF; font-weight: bold}", 
        "body": "{font-size: 11px; font-weight: bold; color: #000000;}"
    ]
]

Labels: daylog, grails, groovy, ofc2, open flash chart

Haven't blogged for a while. The arrival of my baby daughter has kept my life quite busy and full of joy, also my sleep deprivation level at a level hasn't been seen since university time.

First day after my paternity leave, back at office upgraded a current Grails project to the fantastic Grails 1.2 and getting ready to release for the iteration. However as soon as I start running the application in WAR mode, I was getting strange exceptions:

org.springframework.beans.factory.BeanCreationException: Error creating bean with name 'JQueryTagLib': Initialization of bean failed; nested exception is org.springframework.beans.ConversionNotSupportedException: Failed to convert property value

After a bit of digging I realize its caused by the JQuery plugin after I upgraded to 1.4 version. Apparently in JQueryTagLib a typed non-private field "GroovyClassLoader classLoader" was the source of the problem. Because its not private Groovy compiler automatically generates getter and setter for this field, and when Spring tries to inject dependency for this field a class conversion problem happens since the field is typed as strictly GroovyClassLoader, since the native class loader in a WAR environment usually will not be a GroovyClassLoader.

I have contributed my finding to the JQuery plugin project, and the fix is incorporated in the 1.4.1 release, but for whatever reason if your project suffers from the same issue and can not upgrade for the moment the easiest fix would be just simply change the classLoader field to private in JQueryTagLib class under your plugin directory.

Labels: daylog, grails, groovy, jquery, plugin

By this time everyone can probably guess that GoEyeball did not win the pitch competition at Impact National 2009 conference. Otherwise you probably would have seen me flashing the giant check of 10K ;-) (although not in cash but in service with KPMG). Today I am writing this blog to share some of the experience and lessons learned from this competition, so I guess we can score a few wins from this loss.

#1 Pitch an idea especially a new one that involves innovation in technology in 5 mins elevator pitch is not a easy task

We actually received feedbacks in conversations after the pitch that a lot of the audience, including the judge, did not understand or realize that we have invented a new technology to provide a service that is not available from our competitors

#2 You need to be clear on what you are asking for

After the competition, my business partner and I regrouped and did some retrospective on the performance and realized we were not clear on the message. Here is what we believe a better format for our pitch could be:

• Who we are?
• What problem do we solve?
• Why will we be successful?
• What do we need? Funding? Mentor?
• What is in there for you? Exit strategy for investors.
  

We did not win the top prize, but we still had a great time at Impact. This is only our first appearance for public pitching; we will continue working on it, but most importantly we will continue to have fun after all that was why I quite my full time job in the first place - to have FUN. So far it has been a journey of every bit of fun I could have ever imagined :-D

Labels: goeyeball.com, impact 2009, pitch, startup

I am very proud to announce that GoEyeball.com is one of the 4 finalists at Impact National Conference 2009 pitch competition hosted from 3:30-5:00pm on Saturday Nov 21 at:

Westin Harbour Castle

We are also an Exhibition Sponsor for the conference with a booth in exhibition hall on Friday afternoon to showcase our technology and answer any question from users, potential investors, and any one who is interested in our idea. If you are attending the conference or know some one attending please come check out our booth and show your support at the competition.

Will keep everyone updated with the result on this blog.

Labels: business, goeyeball.com, pitch, startup

We are now open for business in our new office near Yonge and Eglinton (3 mins walk from the subway station). Our new address:

120 Eglinton Ave East, Suite 1000
Toronto, ON Canada M4P1E2

Phone: 416.322.2931 Fax: 416.322.2877

Email: nzhu@jointsource.com
Website: www.jointsource.com

View Larger Map

Labels: business, jointsource

Last week after a long talk with my wife and with her blessing I made one of the most important decisions I have ever made, other than marrying the woman I love :-), to quit my individual consulting career and start working full-time to develop my own software business specializes in what I call “UnSourcing”. I have been doing independent consulting on and off for the last 6-7 years, the outsource experience I had in Siemens, Rogers, and many other firms convinced me something I have always suspected

“With a highly capable team equipped with a proper Agile process, it should be able to build high quality custom software with much less TCO comparing to a typical off-shore outsourcing vendor“

The reasons are simple. The outsource model works great in manufacturing because of the revolutionary work done by Federick Winslow Taylor (Scientific Management) and Henry Ford (Assembly Line) and many others like them throughout the 20th century. The manufacturing process is virtually optimized to the limit; the only way left to reduce cost is by simply reduce the cost of labor. Furthermore because the process is so streamlined and well defined outsourcing it to a different country literally has no major impact to neither the quality nor productivity of the process at all. In software industry despite how much we have been trying to fit the manufacturing model, we are not manufacturing software and coding is not an act of manufacture or construction but rather an on-going design process.

“Source code itself is a major part of the design. The construction of the software is done by the compiler and machines cheaply and flawlessly, but not by the developers.”

Since coding is more a design activity than manufacturing, more of a craft than engineering, that’s why a master programmer can be up to 28 times more productive than a not-so-experienced counterpart. With that in mind, its not difficult to understand before we go for off-shore outsourcing there are actually huge amount of optimization we can do in other parts of the system to lower the cost. The recent Agile movement in the industry is a perfect example of how much waste we can cut out before we resort to the labor cost.

I am starting my business with my business partner in the hope of being able to help companies who have suffered from outsource mess to actually deliver high quality software and solutions with true business value and most importantly with much less TCO. In the next a few months I will record our journey here in my blog, and of course we appreciate anyone who would like to share their experience, advices, and leads with us if you would like to see this somewhat quality obsessed software shop to survive this largely manufacture minded industry out there :)

Labels: business, jointsource, outsource