DonationWare!

I am opening up old courseware to the world on a "pay if you like it" or have it free basis.

My third offering is Developing with JavaScript Technologies.
(You will find other offerings in this site's DonationWare Category.)

This course was created in mid-2002.

It was created for ASERT but never actually saw the light of day…isn't that sad!

This was after the dot-com bubble had burst and the ultimately commissioning organisation probably went bust or lost interest or something…I can't remember now!

The course was pitched at people who wanted a very quick overview of what was then a 'warm', upcoming topic. I tried to show JavaScript in a good light, not just as an adjunct to a browser. This was before Jesse James Garrett thought of the term AJAX (reputedly while in the shower)!

There was plenty of hands-on time. There are quite a few small and simple exercises.

Here's the 'blurb':

The course is now well and truly at End of Life.

I figure that it would be such a pity for it to end as a set of bits decaying away on my hard disk so I am opening it up to the world on as "as-is" basis:

Developing-with-JavaScript-Technologies-Courseware-DonationWare.3.July.2009.zip
(MD5: 3922b66caca1dfda0a0b23c532a68b4d; size: 4,523,559 bytes)

Some (unfortunately necessary) legalese:

• This content is provided "as-is", with no guarantees.
• Feel free to use it, but not to abuse it (to give a couple of examples: don't make hundreds of copies for friends; don't claim it as your own work).
• I retain copyright, so "all rights reserved."

Enjoy!

If you like it, or have any questions/comments, send me an email ( ).

If you find this material useful, please consider paying me a small amount: via PayPal.

DonationWare!

I am opening up old courseware to the world on a "pay if you like it" or have it free basis.

This is a new thing for transentia!

My second offering is XML Overview for Developers.
(You will find other offerings in this site's DonationWare Category.)

This course was presented all around Australia and Macau between about 2000 and 2002.

It was often run under the ASERT banner (http://www.asert.com.au) and sometimes under the Software Engineering Australia (SEA, now defunct) banner.

The course was pitched at people who wanted a very quick (2-3 day) overview of what was then a new, 'hot', upcoming topic.

A cut-down one-day version was also offered as a public 'informational' course a few times.

There was plenty of hands-on time. There are quite a few small and simple exercises.

Eventually, the XML world exploded to such an extent that I couldn't keep tracking the changes (think about the changes the XML Schema language went through, for instance) and there was so much other material around that it was no longer cost-effective for me to give the material the care and feeding it needed and I eventually stopped promoting and maintaining it.

Here's the 'blurb':

The course is now well and truly at End of Life.

I figure that it would be such a pity for it to end as a set of bits decaying away on my hard disk so I am opening it up to the world on as "as-is" basis:

XML-Courseware-DonationWare-3.July.2009.zip
(MD5: 20fbe339e28c952292ca270eedb2f389; size: 8,434,050 bytes)

Some (unfortunately necessary) legalese:

• This content is provided "as-is", with no guarantees.
• Feel free to use it, but not to abuse it (to give a couple of examples: don't make hundreds of copies for friends; don't claim it as your own work).
• I retain copyright, so "all rights reserved."

Enjoy!

If you like it, or have any questions/comments, send me an email ( ).

If you find this material useful, please consider paying me a small amount: via PayPal.

Last night, I attended James Couzens' "fireside chat" on how Suncorp does Agile.

A few take-aways (I'm paraphrasing, forgive me if this isn't exact but you'll get the gist):

• Agile doesn't stop you making mistakes, but it does let you identify the mistakes earlier…then then (hopefully) you can take appropriate and effective action
• Your Product Owner needs to be able to make real decisions (otherwise you'll suffer looong delays, which warps planning and results in low velocity)
• The relationship between Product Owner and ScrumMaster is very important
• Analysts should run only one sprint ahead or the developers, otherwise everyone's heads are in different 'spaces'
• Work with your Product Owner (and stakeholders) early and often
• When interfacing with other (waterfall/non-Agile) groups, treat their needs as high priority
• Poor information radiation can lead to problems
• Planning Poker works. Nicely.
• Don't focus on showcases…this is a sure way to build up technical debt!

The key takeway:

• Your "Definition of Done" has a far-reaching effect, so spend time on formulating and reviewing it

Thanks, James!

The ever-vigilant Dr. Paul King has put me straight on my Quick Play With Groovy Templating from a short while back.

To quote: "Noticed your template blog. Thought this might interest you:"

class Thing { int id; String comment }
final template = new groovy.text.XmlTemplateEngine().createTemplate('''
  <things xmlns:gsp='http://groovy.codehaus.org/2005/gsp'>
    <gsp:scriptlet>things.each{</gsp:scriptlet>
      <thing id='$it.id'>$it.comment</thing>
    <gsp:scriptlet>}</gsp:scriptlet>
  </things>
''')
println template.make(things:[
  new Thing(id: 0, comment: 'Hello, XML Template!'),
  new Thing(id: 1, comment: 'This is another Thing')
])

This isn't documented anywhere as far as I can see (although there is a test). The proof is in the pudding, however:

I somehow feel as if I have been initiated into some secret society: "The Knights Who Know About <gsp:scriptlet>"!

Thank you, Oh Grand Pooh-Bah Paul.

Just listened to a couple of Al Gore's presentations on climate change (from TED 2009):

SCARY

And

Inspiring!

I admire Al Gore's (relatively) new-found sense of purpose and his continuing determination.

Feeling a bit depressed?

You'll need some entertainment.

Or a diversion from Cliff Stoll.

Cue some tasty blues: ##Well, I woke up this morning…Had a question I wanted to know…Is a closure def as efficient to call as a method def?##

(OK…I won't give up my day job to become a famous bluesman…or I wouldn't give up my day job if I had one…which I don't…which makes me feel blue…cue a tasty blues riff…)

I set out to find out the answer to the burning question stated above.

I fired up GroovyConsole and wrote exhibit A:

def f = { x ->
}

def start = System.currentTimeMillis()

(1..10000000).each { x-> f x }

println "Finished; ${System.currentTimeMillis() - start}"

Not rocket science!

This runs in about 2590ms.

On to exhibit B:

def f(x) {
}

def start = System.currentTimeMillis()

(1..10000000).each { x-> f x }

println "Finished; ${System.currentTimeMillis() - start}"

ONLY the first line of the script has changed, note.

This takes about 4539ms.

Nearly double the time!

With Groovy 1.6.3/Java 1.6.0_14. In a newly-started instance of GroovyConsole. After the other had been shut down.

I admit to being surprised. I had expected a plain old method call to be much faster than a closure invocation (which I had assumed would involve all sorts of 'meta' munging).

The converse is true.

Just goes to show, eh!

I'll have to get hold of Groovy 1.7 and (try to) use it's AST viewer to see what is going on (didn't really help me: the AST tree for the closure version seems simpler, but I don't know whether than translates to real code…)

As always: don't read too much into this, it isn't the end of the world, YMMV, etc., etc.

[edit]
This just in from the always-knowledgeable Dr. Paul King:

The over-simplified…answer: Closures probably have more to do but have been highly optimised in the call site code to match what the JVM JITs/caches really well.

Now I know! Thanks, Paul!

Just purchased and read 97 Things Every Software Architect Should Know:

"In this truly unique technical book…" you will get a collection of homilies and platitudes about life as a software architect. Some will be useful and thought-provoking, some…not so much. It is an interesting read, regardless. It's just the sort of book to have at hand while waiting for a bus, or to keep the eyes/brain engaged during a 10-minute lull before the next storm rolls into your life.

As for the price…now that I have read it, and understand more clearly that the production costs were essentially zero, I feel ripped off! After all:

…This book is probably completely different from any other book you've read. It is the combined work of more than four dozen authors, all of whom donated their thoughts and advice about software architecture without compensation.

Don't get me wrong: I enjoyed the book well enough, but the sticker shock…hmmm :-(

Gotta admire Richard Monson-Haefel for finding a new, painless way to get into print!

There's a follow-up website; wish I'd found it before shelling out hard-earned (and increasingly rare) $ on the book!

Over on Code To Joy there is a nice discussion of JFugue, the Java API for Music Programming and Groovy.

The comment was made:

… I wonder what a stack trace sounds like ;-)

I wondered too!

The answer was…boring!

A bit of munging made it just a bit less boring:

import org.jfugue.*

def munge(s) {
  (s.findAll { it ==~ /[A-Ga-g]/ } as Set).join(' ')
}

Exception.metaClass.play = { new Player().play(new Pattern(munge(delegate.toString()))) }

new IllegalArgumentException(/Don't give me that!/).play()
new ArrayIndexOutOfBoundsException(/Don't give me that!/).play()

There's also Ode to Build Scripts!

As my dear departed mother always said: little things please little minds…

I just had the occasion to play with Groovy Templates to produce XML.

First I played with the actual groovy.text.XmlTemplateEngine, thusly:

import groovy.text.XmlTemplateEngine

class Thing {
  int id
  String comment
  }

final engine = new XmlTemplateEngine()
final thingTemplateEngine = engine.createTemplate('''<thing id='$id'>$comment</thing>''')

def sb = new StringBuilder()
sb << '<things>' << 'n'
[new Thing(id: 0, comment: 'Hello, XML Template!'), 
 new Thing(id: 1, comment: 'This is another Thing')].each {
  sb << thingTemplateEngine.make([id: it.id, comment: "${it.comment}"]).toString()
}
sb << '</things>'

println sb

This produces:

<things>
<thing id='0'>
  Hello, XML Template!
</thing>
<thing id='1'>
  This is another Thing
</thing>
</things>

Note that XmlTemplateEngine can actually do validation during construction, so if (unlike with this example) you have a schema/DTD defined, you can ensure that what you generate is valid XML. For some applications, this can be quite important.

This is not too shabby, but still a bit messy and 'bitty': creating a <thing> is simple, but creating the <things> root element and adding the <thing> children feels like a hack to me (there seems little benefit over plain string concatenation, IMHO) and seems to prevent the possibility of checking against a schema/DTD for the resulting document as a whole.

Groovy offers a second template engine, the groovy.text.SimpleTemplateEngine, viz:

import groovy.text.SimpleTemplateEngine

class Thing {
  int id
  String comment
  }

final thingsTemplate = '''<things>
<% things.each{ thing ->
  out << """  <thing id='$thing.id'>$thing.comment</thing>
"""
}%></things>'''

final engine = new SimpleTemplateEngine()
final thingsTemplateEngine = engine.createTemplate(thingsTemplate)

println thingsTemplateEngine.make(things: [new Thing(id: 0, comment: 'Hello, XML Template!'),
                                           new Thing(id: 1, comment: 'This is another Thing')]).toString()

This is a much more general-purpose tool and supports an embedded GSP-style expression syntax that can help make the task at hand cleaner.

The result is essentially the same:

<things>
  <thing id='0'>Hello, XML Template!</thing>
  <thing id='1'>This is another Thing</thing>
</things>

Note that SimpleTemplateEngine knows nothing about XML so (as far as the generation of valid XML goes) caveat emptor applies.

There is a third template engine, but I'm not going to talk about GStringTemplateEngine here.

Be sure to keep in mind that these engines are text-processing tools: I am hacking XML here, but they have much wider applicability.

I just got a piece of spam with the subject line: "Open this, damn you" :-)

I didn't open it, though!