Alexis's Blog on TReCX

The most generic / implementation neutral site related to aspect-oriented programmming is probably this. However, a quote on the front page of the AspectJ site (which is an implementation of aspect-oriented programming for Java) regarding what it enables, as this ...


"...clean modularization of crosscutting concerns, such as error checking and handling, synchronization, context-sensitive behavior, performance optimizations, monitoring and logging, debugging support, and multi-object protocols..."


As you can see, two of the things it mentions are monitoring and logging. I think that it is fair to say that tracking is analogous to these two concepts; they all involve recording events as they occur. How does aspect-oriented programming help achieve this? - well, first one needs to know about features of the language, AspectJ in particular, and it is a language with it's own syntax (although it is now possible to do some of this using Java 5 annotations).

Two fundamental concepts are pointcuts and advice. A pointcut defines when you want a bit of code to execute, advice is the bit of code itself. Another thing the language gives you are implicit variables to the runtime context; for example at runtime you can query what the name of the method is that is currently executing. As a very crude example of tracing or logging, you can define a pointcut which says that everytime a set*() method is entered, log the name of the method that has been invoked with a timestamp (without having to explicitly define what the name of that method is at compile-time).

Using AspectJ means that you can add a behaviour such as logging, to an application that previously didn't have it. Logging is something that often has the quality of tangle and scatter, i.e. it affects a lot of little bits in a lot of different places. Instead of adding lots of code tweaks to an application that does not do logging, you can use aspects instead. In fact in practice this byte-code weaving between the non-aspect and aspect elements of the binaries can now be left as late as load-time. In our case we can encapsulate the code that provides the glue between events in the application to the tracking interfaces in the aspects. This means that other developers can look to see what we did in order to add tracking behaviour to other applications. In fact, in a wider sense, it may be possible to add other e-Learning pedagogical requirements to applications that do not currently that kind of behaviour already :-).

A few days ago, sourceforge announced that after running a 6 week beta programme, they intend to offer Subversion as an alternative version control system to CVS. You can see the full announcement here.

Seeing as we have yet to commit any coding artefacts to any kind of repository, it being desirable to host one's artefacts at sourceforge and regarding Subversion as inherently a "good thing", it seemed like a no-brainer to opt to use this; we didn't even have a CVS tree to import!
It's a while since I originally read about Subversion, but there were a number of things that appealed to me about it such as being able to rename files without losing the history (a real boon when refactoring and removal of a disincentive to do this!). Branching and tagging is supposed to be much cheaper (computationally speaking) so again disuaders from doing this are removed. As Eclipse is our IDE of choice, we'll probably turn this into our Subversion client via the Subclipse plugin.