jamesladdcode.com

ah … she looks painfully friendly - John Sherwood.

On the weekend I went to the Pixar - 20 years of animation exhibition at the Australian Centre for the Moving Image, Federation Square Melbourne and I saw an amazing series of still images, paintings, slides, animations, sculpture and a zeotrope (worth going just to see this).

What stuck out was the use of story cards and mock ups to get ideas across before starting more involved processes and I think the same approach can be used in our software development work, particularly in prototyping the UI. I don’t mean drawing a single page of the UI on a piece of paper but the progression of the UI from one state to another in response to user interaction. After all, the UI tells a story and shapes the personality of the application and no one brings characters to life like Pixar, so we can learn a lot from them.

So what is so Agile about this?

The fact that you can and should use the story board, light weight prototypes and other models to get ideas down before moving on with more involved processes. A quote at the exhibition said it all:

Making any of our films requires getting all of the creative people together. We all hold hands and jump out of the aeroplane, and we make the parachute on the way down. - Oren Jacob (as quoted by Ralph Eggleston).

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

I was looking around the net for some examples of how to represent related data in a three dimensional way on a HTML page using just Javascript and came across this site http://www.dhteumeuleu.com.

The creative interface explorations along with clean simple code make Gerard Ferrandez  javascript legend in my book.

Please take some time to have a look at the examples and how you could possibly use the interface elements in your next web project.

Good programming involves remembering lots design principles and design patterns and that’s sometimes hard. Until now.

I can still recite the usual planets in our solar system from the cheesy rhyme taught to me long, long ago. “My Very Elegant Mother Just Sits Up Near Pop.” and now I can use a similar approach to remembering design principles and patterns thanks to this post on the Object Mentor blog.

So CCCCDPIPE all the way !

Aegeon are still looking for good developers and so I have been spending a bit of time reading up on how to find them. Note how I didn’t say retain? This is because Aegeon is a great place to work and I think this part of the story is well taken care of. Anyway … in my search for information I came across this article,
Guide to Hiring Programmers: The High Cost of Low Quality. It isn’t a definitive guide or statement but worth a read.

I did a lot of performance tests on some code I am working on to see what technology layers added what overhead and I learned some interesting things.

1. The area you think is going to be slow is never the area that ‘is’ slow.
2. A baseline is crucial to understanding the best and worst cases.
   For example, on my machine at home a html page returned by a servlet takes on average 7ms and therefore there is no way I can expect better than that for any page that has additional processing (on the same machine configuration). This helps me make a rule-of-thumb for the system like “no page request should take longer than 10ms to be returned to the browser.”. This rule might need adjustment after discussions. It’s probably worth while adding some AOP cross-cut to measure this and throw an Exception when the baseline is overshot.
3. Establish a “sweet spot” where the timings for runs averaged out don’t start to make everything so level that you can’t see differences.
   For example, in my tests if I run with 10,000 cycles I see a difference between the various approaches I am trying, whereas, with 100,000 cycles the results are so averaged that there is no difference to be seen in any one approach. Conversely, 1000 cycles are too short to see any difference at all.
4. The longer you run the tests the more you move from performance testing into stress and volume testing, so be sure to know what it is your trying to find out and adjust the cycles accordingly.
   For example, in my tests a cycle of 100,000 runs started to effect heap space and the system started to degrade in performance. I need to see and know this but the testing I was doing was not about “how many” runs I could do, but the speed of a single run given the different technical approaches. Keep this in mind so that you know what you are seeing in the results and why.

I’m continuing with my tests on technology layers and when I have done some more I’ll post the results.

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 !

(16:03:36) Takis Diakoumis: i like inside myself…..

Here is a pic of me (below), we simpsonized ourselves. For best results make the image 800×600 and save in PNG format.

From http://xkcd.com/

http://xkcd.com/297/