jutopia

Adrian Colyer, project lead of AspectJ has written the best motivation for AOP I’ve ever read.

http://jroller.com/page/colyer/20040531#the_ted_neward_challenge_aop

Adrian, can you explain the constructs of AOP (joinpoints, pointcuts, advice, etc) in the same way?

This latest gosspi on fake posters is funny. Just check out how many alter egos I have. Can anyone beat me?

Ok, first of all. I actually think EJB3 will be a massive improvement compared to previous version. They really seem to be on the right track.

But I’m going to prefer not to do EJB anyway.

Jason Carreira touched upon in it in this blog entry. The reason is simply that the choice of app-server (and thus EJB container) is usually not a technical decision. It is a political/strategic/whatever decision. When I come into a project at a customer all those decisions have already been made and a simple consultant will rarely (never?) be involved in those decisions. Here’s your app-server, here’s your database. Now, build me this bad-ass system.

This means that if there’s a bug somewhere in the app-server you’re looking at a 3+ months cycle of nagging on IBM support until they assume responsibility, waiting for them to actually figure out a way to fix the problem and finally persuading the customers production department to apply the fix. And that’s assuming you don’t hit a brick wall somewhere and it’s just not going to happen.

In a situation like that you got one choice: rely as little as possible on the app-server/container, and always expect the worst. We’re talking basic servlets here, you’d be lucky if you get a jsp running and don’t even dare thinking about servlet-filters, EJBs or anything fancy like that.

With Spring/Hibernate (or whatever is the current vibe) I bring my own lunch. I can build the entire solution as simple servlets. I can run it standalone with Jetty inside my IDE. If there’s a bug somewhere I’ll just go in and fix it. If there’s a nasty deadlock under heavy load in production (or whatever) I can figure it out. In a put-your-trust-in-the-holy-container-provider-situation my ass is grass.

So thank god for lightweight enterprise Java (as it’s currently seem to be called)! You’ve saved my ass so many times.

This is a great new innovation for TCP/IP:
http://www.x-cp.org/index.html

James, maybe it was too early to repent Jelly. Imagine if you combined Jelly and XCP, your TCP packages would not only be in XML, you would also be able to execute them!!

We are definitely making progress.

This blog is starting to look like an advertisment for Atlassian, but I just have to tell you about some stuff I wrote over the weekend (with some help with the finishing touches from Aslak and Carlos, the latter being in town all the way from Brazil).

You know when you are trying to write that long anticipated documentation for your latest open-source library and you want to include some code samples in your tutorials? Only problem is, the project is coming close to a release but you’re still refactoring like crazy. So how do you keep all those code-snippets up-to-date?

Confluence to the rescue! Your open-source library is the latest and coolest cutting-edge stuff you can think of so of course you are using the latest and coolest cutting-edge tool to write the documentation in. For those who don’t know about it: Confluence is basically a wiki with some really nice features like for example an awesome look-and-feel that makes me all warm and fuzzy inside.

So, one of the features in Confluence is that you can easily extend it with new macros. This is actually a result of that they are basing their wiki rendering on Radeox the same rendering engine used by SnipSnap.

So I basically just wrote a macro that extracts code snippets from any url (hint, think viewcvs) and renders them into a Confluence page.

You basically puts this into your code (easily done with an IntelliJ surround live template):

// START SNIPPET: boy
public class Boy {
    public void kiss(Object kisser) {
        System.out.println("I was kissed by " + kisser);
    }
}
// END SNIPPET: boy

Then you add the following to your wiki page (I’ve snipped the long viewcvs url that points to my java code in cvs, because it wrecks the formatting of this page completely):

{snippet:lang=java|id=boy|url=[long viewcvs url deliberately left out]}

Don’t get fooled by the “lang=java” thing, the only thing that does is to render the content as a code block with java syntax highlighting. This actually works for any language, xml, text, html, whatever. Thanks to Martin Fowler who explained the idea of putting the snippet demarcators into the code, which avoids any crazy ideas of having to parse the Java code and makes the same thing work for virtually any text file. Simple, elegant and powerful, almost Wardish.

Have a look at the following page, there is not one single line of java code in that page (except for that snippet that for some reason doesn’t work properly, I’ll look into that later):

http://docs.codehaus.org/display/PICO/Two+minute+tutorial

By the way, I haven’t tested this but the macro probably works just as well in SnipSnap or any other Radeox based applications. It does not depend on any features in Confluence whatsoever.

The code temporarily lives in the NanoContainer CVS:
http://cvs.codehaus.org/viewcvs.cgi/snippet/?root=nanocontainer

So, one year huh? It’s been great fun and we’ve accomplished a lot. Projects like AspectWerkz, Drools, Groovy, PicoContainer, JMock, QDox, XDoclet 2, Nanning, Plexus, XStream shows that Codehaus in a short time has attracted a lot of innovative projects. One reason is probably all the great and fun Hausmates and another reason is probably the amazing infrastructure. People that get sick of Sourceforge’s low quality service has all the reason in the world to move. We have to thank Bob The Uberdespot for that, but I should also mention Atlassian whom never thinks twice about giving away an open-source license or two of their excellent products. I wish more companies worked like that (and there is, but I just wish everone worked like that ).

A birthday is a time for review. What can we be better at? I think something we have to start thinking more about is how we face our users. Codehaus used to be alot about technology but there has been a movement lately to try and clean up our public face. We should definitely think more about our documentation.

That said: Hipp, hipp, hooray!

Wow! I’ve been looking forward to this for a long time. Subversion 1.0 is finally released. It’s been stable for quite some time now, but having a 1.0 out means we can probably start moving some of our projects over. For example we’ve been discussion moving PicoContainer to Subversion after the 1.0 release of Pico which is due soon. Dealing with some of the idiosyncrasies of CVS is finally starting to wear me down. CVS is still a lot better than many other version control systems but things like moving files, renaming stuff, absurdly slow tagging and so on is getting tiresome.

http://subversion.tigris.org/

Weee! The JetBrains Resharper EAP is open! This could be the turn-around for .NET development!

http://www.jetbrains.net/resharper

I can’t wait to give it a whirl! They seem to have kept all the key bindings exactly like in IDEA. The joy!

Cool, Prevayler is finalist in the Jolt Awards: http://www.sdmagazine.com/pressroom/jolt_finalists_2004.pdf.

Boy, I’ve been using Prevayler for around two years now and it’s certainly a very powerful alternative to the relational-mapping dance. Of course, the toughest competitor in the category is Hibernate.

Sorry, Dan North but I have to disagree. I’ve always been a bit sceptical about TDD not being about testing but Martin Fowler latest blog entry got me thinking. So I might be a bit old-fashioned here but let’s approach the subject from a pragmatic view-point.

I see two fundamentally different types of testing in an XP/TDD/Agile project. Acceptance testing and Unit testing. There’s no point in describing acceptance tests as driving the design but unit testing is commonly viewed as doing just that. What you are saying Dan, is that to a very large extent TDD is about driving the design and very little about producing a high-quality unit-test harness. Let’s see what I prioritize when it comes to acceptance and unit-tests (both can be used to drive development) and why these two testing approaches complement each other so nicely.

Acceptance tests are about (in order of priority):

1. Capturing, documenting and proving customer requirements This is sort of the holy grail of XP, but we actually have a couple of projects were customer requirements are primarily captured as acceptance tests (never actually written solely by the customer of course, that is (j)utopia, but definitely written in a form that can easily be read and verified by the customer, more on this some other time).
2. Ensuring that all components in the system play along nicely Acceptance tests should therefor as much as possible be integration tests, that is as little part as is practically possible should be stubbed out. If you rely on some systems that are in internal control, run directly against them, if you rely on external systems consider stubbing them out if they are volatile. This also implies that acceptance tests are quite slow, many suites can keep on going for many, many hours (I’ve seen suites that take as long as 20 hours).
3. Insuring against regressions Many agile projects try to release often, the acceptance tests can be used to insure the customer from broken business-critical behaviour.
4. Provide a way for the customer to monitor progress Reports on what stories (or use-cases) have been succesfully tested is the surest and most truthful way for a customer to understand what progress a project is making.

The point of unit-tests are (in level of priority):

1. Run fast Agile projects are all about enhancing and shortening feedback loops, if something goes wrong you should know about it as soon as possible so that you can correct your behaviour. The acceptance tests are usually sloooow (unless you’re really lucky) so they are virtually useless for providing feedback to a developer when he’s checked in some bad code. A unit test suite should run with everything stubbed out and run in minutes. My rule of thumb is: unit tests < 1 min => you’re at top productivity, unit tests ~ 5 mins => you’re still agile, unit tests > 10 mins => you’re no longer an agile project, unit tests > 30 mins => you’re project is screwed, look for a new job. Okay, don’t take this to literally, but you get my point. (This is also the reason why I keep bitching about not starting web servers in your unit tests.)
2. Show what is broken Acceptance tests show that something is broken, unit tests should show what is broken. Ideally for each failing acceptance tests there should be a couple of failing unit tests. To be more precise, a failing acceptance test is symptom of an incomplete unit-test suite (thanks for that one Martin) and before the fix is introduced a new failing unit-test should be added to the unit-test suite.
3. Give you courage to refactor Refactoring without unit tests is like the circus without a safety net. You can do it, but you it’s really dangerous (and you have to be really good). Most people don’t have that sort of courage (I sure know I don’t!) so important refactorings never ends up being done leading to faster software rot.
4. Ease communication with your peer while pair programming In my opinion you can’t do pair programming if you’re not doing TDD. The unit-test is a natural discussion point and the rule about just implementing enough for the test to pass makes discussions more to the point. This makes the pair less likely to disagree about subjective matters where communication usually start breaking down.
5. Drive the design on unit level Here’s what you are talking about Dan. This is actually essential for creating a high-quality test-suite that fulfills all of the above, but when I actually judge a test-suite this comes quite long down on my list. The unit-test acts as “yet another client” to the unit (eg class) you are trying to develop helping you think about the interfaces, collaborators and other types of structure before you actually start writing the actual code.

To be quite honest, the main reason why I write my tests before I actually write the code is because it’s sooo boring writing tests afterwards. I mean, I usually know it works (via for example manual tests) so why should I spend all that time writing tests for it again?