Fresh and Crispy

Refcards.com is a site where you can get handy reference cards for numerous open source tools and technologies. They can be printed double sided onto card (or paper) and fold into a three-column, easy-to-carry quick reference. Brilliant! The site had apparently disappeared for a while but is now back. Its author Andrew Ford has produced a new refcard for Template Toolkit. He has included some cards on Web technologies (very useful as handouts for my students!) from Benjamin Jung. Thanks to Chris Winters for the heads up.

Added this tech talk to my to watch list. Tech Talk: Scott Ambler on Agile Modeling and Development It’ll be interesting to hear the man!

New addition to my to read list ONJava.com: Template-Based Code Generation with Apache Velocity, Part 2 [Jun. 02, 2004] published yesterday. Here is Part 1.

Version 1.0.0 jMock – A Lightweight Mock Object Library for Java has been released. jMock is a framework that uses refelection (I assume) to programmatically define mock objects for unit testing. Tutorials and source code ready for downloading.

Adrian Colyer has tried to describe AOP without using the buzzwords. An attempt to answer a challenge thrown down at the last TSS symposium in The Aspects Blog. It boils down to DRY (don’t repeat yourself).

So what we’ve really got in any non-trivial software application is not the ideal 1-to-1 mapping between concept and implementation, but an n:m mapping. No wonder software gets so hard to maintain, and so hard to understand, and so complex. And it’s not your fault. The tools that object-oriented languages give us don’t enable the clean mapping of every design concept into a single implementation construct … and consequently neither do they allow each implementation construct to map cleanly onto a single design concept. This is the problem that aspect-oriented programming attempts to help us solve. It’s about getting as close to a 1-to-1 mapping as we can. AOP addresses the problem by introducing a new construct known as an aspect that is able to capture in one place the implementation of design requirements, such as the view-notification requirement [all views have to be notified if the model changes] in MVC, which OOP cannot.

Daily trawl through the java.blogs feeds picked up a reference to ONJava.com: SSS (Small, Simple, Safe) [May. 26, 2004]. SSS is apparently a simple tool that allows you to instantiate and play with Java objects. It is apparently used and useful in teaching. I simply had to make a comment to the effect that BlueJ has had this feature for ever! Here’s my reponse in full:

BlueJ is a simple Java IDE (avalable from www.bluej.org) which also has this sort of behaviour. You can instantiate an object of any class on the classpath by providing the fully qualified name and then selecting any of the class’s constructors. Once the object has been instantiated and a small icon (sort of like a UML object diagram) appears. You can then right-click on the “object” to call any of the object’s methods. Because BlueJ is an IDE and debugger it has privileged access to the JVM, which allows you to also inspect the object to see all its private state.

BlueJ has built up quite a following in the educational arena just lately and there are several “CS101″ text books using it (but none from O’Reilly). See the web site quoted above for more info and access to the lively discussion lists.

It’ll be interesting to see if there is any feedback!

Lot of traffic on the blogosphere about the new Milestone 9 release of Eclipse. Here’s a memo to self to check this out later.

Andy Hunt and Dave Thomas The Pragmatic Programmers have published a brilliant article with the above title in Andy Hunt and Dave Thomas, “OO in one sentence: Keep it DRY, Shy and Tell the Other guy”, IEEE Software, Vol.21 No. 3, pp 101–103, May/June 2004. In outline their main points are:

• DRY (don’t repeat yourself) states:> Every piece of knowledge must have a single, unambiguous, and authoritative representation representation within a system. (Hunt and Thomas, The Pragmatic Programmer, Addison Wesley, 2000.)

  Non-authoritative information (e.g. for EJB all the various interfaces and configuration files) should ideally be generated from the authoritative sources. The DRY principle also applies to build process, code reviews, and documentation.

• Shy means code should not reveal information about itself unless really necessary. There are four axes of undesirable coupling that violate the Shy principle:

• static coupling occurs when a program module needs another to compile. Some coupling is often necessary, but it should be minimised. Inheritence is a particularly nasty source of unanticipated coupling and delegation (uses a, has a) is often preferable to is a.

• dynamic coupling occurs when a class needs the services of another class. A good example of what can go wrong is code like auction.getLot().getHighestBid().getBidder().getPerson() (called a train wreck that appears in one of my lab exercises. The client (auction) needs to know too much about its collaborating classes and is therefore fragile.

• Domain coupling occurs when too much information about business logic appears in code. It can often be reduced by the judicious use of meta data that is kept in properties or databases.

• Temporal coupling occurs when code execution is dependent on a particular execution order. Code that may one day be expected to run concurrently should be designed to be concurent.

A corollary of shy code is that code should not be nosy (could be paraphrased as mind your own business!

• Tell the Other Guy [or Tell, Don’t Ask (IEEE Software, Jan/Feb 2003)]. Don’t think of methods as function calls rather as sending a message. Make the other class responsible for providing a service, don’t expect a data return!

Great stuff as usual and well worth quoting in all my software engineering courses!

<

p>While on this note it’s probably worth noting that the Pragmatic Programmers are also bloggers: Andy Hunt blogs in /ndy’s Weblog and Dave Thomas as PragDave. Both are on my Blog role at Bloglines.com.

My colleague Tim Davies and I assessed the web sites that form a key part of the UWS Micromouse project that is part of EG-252 Group Design Project. Some really good sites but my favourites were Group B which scored highest for style and Group E which scored highest for content and UML designs. Some bad apples too: Group D doesn’t have a site and Group F doesn’t have much content!

Committed myself to contributing to Headstart and EESW (two summer schools that we run in the School of Engineering) … again! Subject of my bit this year will be Blogging (or more formally Using the Internet as a Research and Collaboration Tool. The idea is that I’ll give the students a potted introduction to the Internet, www, semantic web, rss, blogging etc and then get them to create group blogs focussed on high-performance ballooning (our Summer School topic). The beauty is that Blogger’s new features (including email submission of articles) provide a great way for the students to keep in touch with each other (and UWS of course) when they all disperse to their homes.

Also, as a side issue, I’m hoping that it’ll do a little bit to promote Blogging as a useful school activity.