Archive for January, 2008

I is direct …

Wednesday, January 30th, 2008

Good written and oral communication is much harder than writing software, at least for me it is. I learned a good lesson recently about writing in a confrontational and non-confrontational way. I hope this post helps you.

The building where I live has had some problems with lax security resulting in damage and theft and so I wrote a letter to the Body Corporate asking for more attention to security. I sent the email to a friend to proof before sending it onto the Body Corporate manager.

My friend responded saying that my “tone” was confrontational but I didn’t see why, all I did was state my case something like this:

Dear Manager,

I would like to meet and discuss the recent security problems with the apartment block.
Please tell me a time that we can meet?

Regards, James

So what is confrontational about this I wondered and I asked my friend to explain. He said that using words like “I” and “me” make the dialog direct and this directness can be confronting depending on the individual receiving the message. He suggested that I make the message indirect and therefore less confrontational. This is what I wrote:

Dear Manager,

Could we meet to discuss the recent security problems with the apartment block.
Please suggest a time we can meet?

Regards, James

Personally I would not have a problem with the first version if it were sent to me, it is clear and factual. However, I do want my communication to be effective and confrontation is not effective. From now on I will be trying to look for and adapt my writing to remove direct speech and incorporate more collaborative words like “we” and “us”.

This is probably not the best or most thorough explanation on direct and indirect speech, so if you see a better one elsewhere then please send me a link.

IntelliJ: I liked the product so much, I bought the company !

Thursday, January 24th, 2008

IntelliJ IDEA by JetBrains is such a great IDE that if I did had the money I would buy the company. The tool is so good and and it makes my job easier. Almost every day there is a feature or something that the IDE does that leaves me with a smile, be it smart code completion, effective refactoring or very smart defaults. Who would have thought you could achieve so much with Alt-Enter?  I use a lot of programming languages both professionally and personally and IntelliJ supports all of them equally. It’s amazing. So amazing I bought a personal license.

The single suggestion I have for JetBrains about IntelliJ is to have a set of syntax coloring schemes that people can select that are transitioning from another IDE to make the transition smoother. For example, selecting an Eclipse scheme would change the syntax coloring to be the default in Eclipse.

If you haven’t tried IntelliJ then your really missing out, try it, you will buy it, it’s that good !

Two New Quotes …

Thursday, January 17th, 2008

“let go of opinion” - Morihei Ueshiba

“There is nothing as dangerous as a programmer who has just read a patterns book.”  - unknown.

Come on closures …

Wednesday, January 16th, 2008

I’m a big fan of closures, which comes from my usage of similar “functional” techniques used in Lisp, Smalltalk and JavaScript and I simply can’t wait to see them introduced into Java. I think they will usher in a new era of cleaner and simpler code and more extensible and utilitarian frameworks.

The proposed syntax is not as clean as groovy or other languages that support closures, but at least closures are on their way. For more examples on the syntax and further discussion and tutorials check out these links.
Neal Gafter’s blog ->Closures for Organizing Your Code

Pattern Centric Blog -> Comparing Inner Class/Closure Proposals

Danny’s Blog ->Java Closure Examples

GORM: a silent failure …

Saturday, January 5th, 2008

I was pulling my hair out yesterday trying to determine why my application wasn’t saving all of it’s data to the database. There were no exception and only some of the data was getting written. I tested things again and again and I couldn’t see why the data wasn’t being saved.

I posted to the Nabble grails forum where I knew I would get a response quickly and it was suggested by Mike Brevoort that I try checking for errors from the save method. Of course this suggestion hit me like a brick since I should have known better than to ignore the return codes etc. I thought I was safe not worrying about this as I expected and exception to be thrown by someone if the data or relationships were invalid.

This is the approach suggested by Mike and I suggest you use it too, since a silent failure will take up a lot of your time:

if (!record.save(flush: true)) {
    println "GORM problems saving record $record"
    record.errors.each {
        println "$it"
    }
}

I could have saved myself a lot of time by checking the return codes / method result, but I’m also a little annoyed at the silent failure by GORM and Hibernate !

I hope this tip saves you a lot of stress and time.

Thanks Mike !

groovy + gpath + xml = heaven !

Friday, January 4th, 2008

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.

Thank you and have a great 08!

Tuesday, January 1st, 2008

Thank you for reading my blog. I hope that 08 is a great year for you and that there are more blog entries here that interest you. I’m also open to suggestions on topics.

Keep well.