jamesladdcode.com

I have not written a post for a while as I have been very busy working, developing Redline Smalltalk and looking after my twin boys. Recently I did get some free time and I needed a break from Redline Smalltalk and I picked up a book by Kent Beck from the top of my pile of books to be read. Yes there is a pile and there are about six books in it right now, there is even another Kent Beck book, which should not be a surprise to anyone as Kent is a great mind and his writing is worth your time.

The Kent Beck book I read was “Smalltalk Best Practice Patterns” and while you may think “what the! Isn’t this posts title about Ruby?” what I want to get across is that this book transcends a specific language and is applicable to any Object Oriented language and to anyone wanting to get a good grounding in “Best” practice and patterns of development. Having done Smalltalk, Ruby, Java and C++ I can see how each and every nugget can be applied. So regardless of your language choice you should choose to get this book.

So what does “Smalltalk Best Practice Patterns” have in it?

SBPP is a quick and easy read and it took me about 16 hours to finish it, but of course I am still thinking about the material in the book and how best to apply it. There are 92 specific items covered and a very good real world example and discussion of why. The real world, every day nature of the book makes it a must have, each section has the following elements:

• Title
• Preceding Patterns
• Problem
• Forces
• Solution
• Discussion
• Following Patterns

The appendix having a reference to each point making it great to have near by.  The book contains the following sections and topics:

• Introduction
• Patterns
• Behavior
  Methods
  Message
• State
  Instance Variables
  Temporary Variables
• Collections
  Classes
  Collection Protocol
  Collection Idioms
• Classes
• Formatting
• Development Example
• Appendix A:  Quick Reference

Being a big fan of immutable Objects I especially enjoyed the section on “Getting Method”. If you only adopt one thing from this book I hope it is about private getting methods, sometimes called “getters” or “accessors”. It is hard to stress how much better a large amount of software would be if it adopted this practice. This is how Kent puts it:

“Here’s the real secret of writing good Getting Methods - make them private at first. I cannot stress this enough.” and goes on to say “There are cases where you will publish the existence of Getting Methods for use in the outside world. You should make a conscious decision to do this after considering all the alternatives. It is preferable to give an object more responsibility, rather than have it act like a data structure.”

One comment from a reader, Kyle Brown is “The patterns in this book are absolutely fundamental to good Smalltalk programming. No one who calls himself a Smalltalk programmer should be without the knowledge in this book” and I would go so far as to say that no one who calls themselves an Object Oriented developer should be without the knowledge in this book.

Over the holiday break I have been refactoring an application that deals with XML processing to use groovy and gpath and the experience has been fantastic. If you are not using groovy and gpath to process XML then you are probably working a lot harder than you need to. Trust me, I was doing the same processing in java and now I’m doing it in groovy and it takes me a lot less time.

Here is the approach in a nutshell:

XML
<classes>
<class subject="science" room="2B">
<students>
<student>fred nurk</student>
<student>sally socks</student>
</student>
</class>
<class subject="art" room="1C">
<students>
<student>billy elliot</student>
<student>wayne cooper</student>
</student>
</class>
</classes>

XmlSlurper

XmlSluper is a class that makes the parsing so easy, just create a slurper and parse the text.

def xml = new XmlSlurper().parseText(text);

To process the elements in the XML use the gpath notation with the slurper.

To access an element, use the elements name:

def element = xml.classes.class
def art = xml.classes.class[1]

To access element attributes, use the elements attribute name:

def artRoom = xml.classes.class[1].@room

You can then put these together to perform other operations, like printing all the data:

xml.classes.each { class ->
    println "${class.@subject} ${class.@room}"
    class.students.each { student ->"
        println ${student}"
    }
}

More information on gpath and XmlSlurper can be found here.

I’m lucky to get to work with Brent Snook (Aegeon), a very smart guy, great coder and someone who is also a good presenter.

Recently at the Melbourne Groovy User Group Brent presented ‘Mopping Up With Groovy’, a presentation about the Groovy Meta-Object Protocol which underlies Groovy. The presentation was insightful and the code examples unique and they contained a touch of humor. They are attached.

Groovy is a very powerful language and the ability to add functionality to it at runtime is a very useful thing to be able to do, as the presentation shows. Understanding the Meta-Object Protocol is crucial to fully explore the power available to you.

mopping-up-with-groovy-brent-snook

The Melbourne Groovy User Group is holding their first meeting on Monday 1st October at the Aegeon offices and it promises to be a corker !!

We have Paul King (co-Author of Groovy In Action) presenting and some words from other important influential groovers, like Guillaume Laforge
(Groovy Project Manager).

It is all happening from 6:30pm at the Aegeon office and your welcome to come along. However, if you would like some pizza then please let me know your coming.

Aegeon is on Level 5, 10 Queens Rd, Melbourne. The building with the big ‘G’ on it.

If your wondering what this groovy thing is, then read this.

I wrote some unit tests for my grails app that were in packages and therefore not in the root test/unit folder. These were not executed when I ran ‘grails test-app’. This was annoying so I looked further and found that this wasn’t supported just yet, so I made a fix.

In TestApp.groovy in the scripts folder, there is a routine called resolveTestResources(pattern resolver) which is called from two places within the file, one on line 193 and one on line 229. The call looks like this:

def testFiles = resolveTestResources { “test/unit/${it}.groovy” }

This call needs to be changed to:

def testFiles = resolveTestResources { “test/unit/**/${it}.groovy” }

This will include all the files in the root of the folder as well as sub-folders.

NOTE: If you have a file called MyTests in the unit folder and MyTests in the integration folder then there will be problems. I suggest you suffix your unit tests as UnitTests and your integration tests as IntTests or something so that duplicate test script names don’t cause problems. The tests also get treated a scripts so any package statements in your tests cause problems as well. I had to remove them.

I’m sure all of this will be fixed in the next grails release but this should get you moving. Im using grails 0.6 currently.

Cliff has a great description of BDD and groovy Gspec here:

http://codeforfun.wordpress.com/2007/04/09/gspec-for-java-bdd/

It is also worth going to the site to see Cliff’s banner which made me laugh.

Ramon has posted a nice quick start project here:
http://softwarecraft.org/blog/?cat=7

There are a lot of things to consider when choosing a new language or approach to application development. One thing to consider is just how productive you could be when compared to an existing approach or language.

The potential productivity gains from learning groovy are being discovered and compared to other approaches in this interesting blog.

For those who don’t want to click through, it appears Groovy / Grails is more productive than Ruby / Ruby On Rails. I’m sure this is subjective and I’m happy to hear from those who have done both. I have done both but I haven’t done enough to comment.

One thing I am hearing a lot is a new Ruby mantra, “It’s so fast to develop but it runs slow and I’m spending a lot of time performance tuning.”

I’m still keen on the groovy approach, as you may have guessed.

Hopefully one day everything will be as fast as Lint !

10 Common Misconceptions about Grails

This is well worth a read to dis-spell those fears you may have and to get to know more about Grails.

Recently I had to write a domain class, map it to the database and write some tests around it. Of course the tests came first but anyway this is how I did it in grails …

1. Create and edit a domain class.
   Eg: grails-app/domain/Job.groovy
   class Job {
   String title
   }
2. > grails generate-integration-test
3. Edit the test class and add some tests (ok the example test won’t win me any awards).
   Eg:
   def job = new Job(title: ‘test job’)
   job.save()
   assert Job.get(1) != null
4. > grails generate-all
   when asked, enter the name of your domain object, for example Job.
5. > grails test-app
   And watch all the magic happen as grails takes care of mapping your domain object to the database and running all your tests.

Notice that there was no XML file editing or SQL fiddling?

I have long been a big fan of Lisp and Smalltalk but the world has gone Java, which was disappointing until I discovered Groovy. Groovy is a small step back in time but a giant leap forward for Java kind !

It’s a small step back in time towards the languages that started it all, Lisp and Smalltalk but a giant leap forward by bringing some of the power of those languages to the Java Virtual Machine and Java. It’s such a great language that it feels like ‘home’ for me.

“What makes builders special is their descriptive nature while still being ordinary executable code. Together with Groovy’s feature of executing code dynamically, this combination comes close to the ambition of Lisp: working as an executable specification.”  - Chapter 8.7 Summary, Groovy In Action, Dierk Koenig with Andrew Glover, Paul King, Guillaume LaForge and Jon Skeet.

Now that’s power and that’s my kind of language !