AOP Jargon

Aspect Oriented Programming (AOP) introduced a lot of new jargon (as if there wasn't enough already). And the problem with AOP jargon is that it's not very intuitive, and I think this scares away some people. Because, in fact, AOP is not that complicated. I've been exploring Spring AOP, and I'll try to explain some of the AOP jargon used in Spring (most of the concepts are the same in others AOP implementations).
The most common example associated with AOP is logging. Logging is something that we have to do across a lot of classes (if not all). And most of the times the code is the same, across all those classes. Wouldn't be nice if we could just say: "let there be logging in all these classes". Well, we can. That's AOP.

Let's assume we want to log everytime the foo() method is called.

public class AOPTest {

 public void foo(){

   ...interesting stuff...
 }
}

The normal solution would be to add something like System.out.println("Entering method foo"); at the start of the foo method (or something a little better than System.out.println). With AOP we can tell that a given piece of code is executed before any call to foo(). That piece of code is called an Advice. There are different kinds of advices for several situations:

• before advice - executed before the method

• after advice - executed after the method

• throws advice - executed if a specific exception is thrown

• around advice - intercepts the method, and can be used to change arguments or even preventing the method from being called
  

• introduction - adds methods to the class, allowing it to implement another java interface

The type of advice already specifies when it should occur, at least in part. We still need to tell what classes and/or methods are intercepted by the Advice. This is done with a Pointcut. A Pointcut simple defines when an Advice (generically speaking, not a specific advice) should occur. For example: you can specify regular expressions to match class and/or method names (you can match only the class name to apply an Advice to all the methods in the class). So, now that you have an Advice and a Pointcut you may join the two in an encapsulating class called Advisor (basically, simplifies configuration).
This should be enough, but Spring implements AOP trough proxies. Every method call is intercepted by a proxy class, before getting to the real method. This is how Advices are executed transparently before or after some method. Fortunately, you don't' have to create proxies manually for every target class (although you can, if additional flexibility is required).

I think this is all the jargon one needs to know to get started on Spring AOP...or any other AOP implementation. I used Spring AOP mainly because I was already exploring Spring Framework, but there are others more powerful that Spring AOP, like AspectJ or AspectWerkz.

3D collaborative environment

For a long time many projects have tried to create a functional 3D desktop. Every project that I've seen fails at one point: performance. However, some interesting ideas appear now and then. Recently I've discovered OpenCroquet. It's not a simple 3D desktop. It's more like a 3D world. Croquet is a collaborative 3D environment that allows applications to be shared between several users. And almost any application can run inside Croquet (no need to program it specifically to work in Croquet). Croquet's architecture allows those applications to be shared in a multi-user environment. You can see the application another user is using, and you can even work with him in the same application (see the screenshots). That allows teams far apart to work together in a project.
OpenCroquet is still in early development, although there's already a version for download.

XML shorthands

XML has become one of the most well established standards in computer technology. It's being used in almost all kinds of applications. I won't talk about its great features and advantages...much has been said about that.
However, not everyone is fully satisfied with XML, specially with its verbose syntax. This can make the document hard to read and create. I don't usually have to create large XML documents by hand, but if I'd have to, I probably would have the same feeling :)
Some people got tired of this and created alternatives to XML. The objective is not to substitute XML, but to provide a way to write XML documents more easily. So, all of them offer an easy way to convert the document to full XML. You can have a look a some of those XML shorthands in this comparison. As you can see, their syntax is similar and most of the times inspired by Python: nested elements are identified by identation (at least SLiP and SOX). I personally never liked this (seems a very dangerous world). But I have to admit that a few of them really are simpler than XML, and thus can make it less painful to create large documents by hand. Others (PYX and SXML), however, seem a lot harder and confusing than XML itself.
So, are these XML shorthands really helpful ? In my opinion, if you create/edit large XML documents by hand regularly and liked one of those alternative languages, it can be an good solution.