techno.blog("Dion")

I love my TiVo. However, one item that I really wish I could see in a OS upgrade would be a better way to handle season passes.

At the moment, if I add a season pass to a show, TiVo dutifully goes off into its data and does a nice sort, to see what conflicts exist.

At the end of this piece of work, I get shown where the conflicts are, and get a choice of:

• Record the shows which don’t have conflicts
• Record all of them
• Cancel the season pass

This just isn’t enough. I want TiVo to be able to show me the conflicts individually, and let me make a choice “A or B”. Then, if I choose one, go out and try to find the show I *didn’t record* on another time (this is why I wish big shows would run at 4am and the like so TiVo can find them then).

It is particularly annoying when you have shows like the Daily Show, which doesn’t seem to offer metadata. This means that if you have a season pass, TiVo will be recording the daily show every other bloody hour.

I wish we could force networks to give up the metadata, or maybe TiVo could do a hash of the show stream, and then if the new one matches, don’t record it again!

Alex Vasseur (of AspectWerkz/AspectJ 5) has written a thorough piece on EJB 3 and AOP: the EJB interceptor dilemna.

He delves into issues with the EJB 3 specification of interceptors (wrt AOP), for example, having to specify interception via:

@javax.ejb.Interceptor(”test.ejb3.MyInterceptor”)

He also complains a little about current preview implementations:

After having a look at JBoss EJB 3 and OracleAS EJB 3 previews, I was even more disapointed. Both of them are using a reflective based approach to invoke the interceptors. This means that the performance of the interceptor will be bad, and that a Heisenberg effect will be inevitable and actually fairly big (no wonder that ones will use interceptor to gather performance metrics and thus as soon as you observe the bean, you are observing a different things than what actually happens).

Ones may say this is a microscopic view. It is. But when thinking about EJB 2 stories in the past a sound idea would be to make sure we don’t waste resources where we can avoid it. And thinking about JBoss history around AOP, that’s rather suprising that the EJB 3 interceptors are not cleanly integrated in their AOP framework. I personnaly consider that we have enough technology around to make it far better, and far more consistent with AOP. Given the impact that AOP will continue to have, ones would better figuring out how to do that now with EJB 3 – assuming that EJB 3 succeeds.

He then spent 1 hour IMPLEMENTING the spec itself using the AspectWerkz AOP container, which is pretty damn impressive IMO.

Alex is even kind enough to put in some thoughts on the spec:

There are some odd things in the 3.5 section of the JSR-220 that I have spot:

• (sect. 3.5.1) an interceptor class or EJB can only have one single @AroundInvoke method (advice) in it, and its signature is (sect. 3.5.4) “@AroundInvoke Object someNameOfYourChoice(InvocationContext ctx) throws Exception”. Why limitating that to having one single method in the interceptor class or EJB (sect. 3.5.1). My guess is that it is tied to the fact that precedence between advice would then be harder to define in the spec without new semantics. Then one might wonder why an interceptor is not defined as an interface with one single method “intercept(…)” that the EJB could implement as well. Having this interface would suppress the need for @AroundInvoke which sounds like an annotation overuse (unless it is a door open for vendor extension as I will do below..). I’ll be interested in EG feedback on that topic, especially in regards of the first limitation.
• interceptor components life cycle is unspecified but stateless. That sounds like a very important and powerfull concept of AOP (especially AspectJ) that has been left aside. It is probably an interesting door to provide vendor specific extension ie thread safe interceptor, per bean class interceptor, per bean instance interceptor, per application interceptor etc (but then interceptor component may not be stateless anymore.)
• (3.5) an interceptor intercepts all business method (or MessageListener methods for MDB). This means that every interceptor will be poluted with a code snip like “if (invocationContext.getMethod().getName().equals(”doSomething”)) …” ie ones will have to write sort of a pointcut in a very loosy way while AOP allow us to write that in a neat way (and further, a way that tools can easy understand to spot which method is intercepted by what).
• javax.ejb.InvocationContext is tied to EJB. What will happen when interceptors will end up somewhere else ?

Fortunately, the implementation exposed in this article addresses those issues nicely from a vendor specific extension perspective.

Awesome stuff Alex.

I recently got the new book, The World Is Flat: A Brief History of the Twenty-first Century.

It is definitely an interesting read, especially if you are in the tech sector.

One of the ideas that I liked was the phases that we have come through as a civilization:

• Phase One: Countries start working together
• Phase Two: Companies start working together
• Phase Three: Individuals from over the world start working together

I feel strongly about phase three. This happens every day for me. Someone helps me on a mailing list, I work with colleagues across the world, etc.

The book also talks about outsourcing, and how we (USA) isn’t prepared. I have been involved in projects that outsourced technology, some failed, and some succeeded, so I know both are possible.

I did like the fact that you can obviously use the time difference to your advantage (versus as a pain). I would love to have an assistent overseas, so when I go to bed I shoot off an email saying: “Can you take these ideas and give me a top class powerpoint presentation back?”, “Can you research X, Y, and Z wrt A, and have a summary in my inbox tomorrow morning?”.

Definitely worth thinking about.

The Ajax explosion has hit the Sun Blueprints team. They have released some early thoughts on new functionality for the blueprints catalog using Ajax with J2EE.

AJAX uses JavaScript in an HTML page to make asynchronous calls to the server from which the page loaded and fetch an XML document from a server-side component asynchronously. Upon completion of a request JavaScript may update or modify the Document Object Model (DOM) of the HTML page based on the resulting XML document. Only the affected portions of the HTML DOM are are re-rendered in the HTML page.

The term Asynchronous JavaScript and XML has emerged recently to describe this interaction model.

For a detailed explanation of AJAX, please see Using AJAX with the J2EE platform. If you are new to AJAX, we recommend that you read that document before reading the following solutions.

Note that AJAX is an emerging technology, and hence the solutions presented here are likely to change as best practices emerge.

This category presents some solutions for using AJAX when developing Web applications with the J2EE platform:

• Auto-Complete: Provide a simplifed means of data navigation as
  the user enters a request in an HTML form.
• Progress Bar: Track the progress on the client of a server-side
  operation without refreshing the HTML page.
• Realtime Form Validation: Perform server-side validation of form data in an HTML page without refreshes.
• Refreshing Data: Provide up to date data to the an HTML page.

Good ole Russ Miles has announced aUnit.

The big question, is how long will it take before we see aTest NG! :)

Hi everyone,

The first release of the source and binary distribution of aUnit is now available from www.aunit.org (via Sourceforge). This release contains a framework that piggybacks on the JUnit framework so it can take advantage of the existing JUnit integration with Eclipse. The aUnit framework executes a series of test steps that each present a representative context to the aspect being tested, executing the corresponding advice as required by the test developer.

This release relies on AspectJ 5M2 and Java 5 (due to the use of annotations) but in the next revision I’m hoping that we can put something together that works without the need for annotations (using something like the ASM to construct implicit contexts).

The important thing is that this is a working test framework now with a set of examples available in the source download to show you how to create aUnit tests. I’m now looking to put together some how-tos over the next week or so and then some more comprehensive tutorials as the feature set matures.

Thanks to everyone for their suggestions, especially that AspectJ team. Hopefully now aUnit can mature into something truly useful.

Have Fun and any support in the development of aUnit is greatly appreciated!

Cheers,

Russ Miles

As I get ready for a trip to London, I was listening to a nice bloke on NPR talking about the shift from the “American Dream” to the “European Dream”.

He defined the American version as he wild west, out for yourself, about the individual.

The european dream contrasts this with interdependence, being seperate but together. Mr. Covey has talked about this a long time in his 7 (now 8) Habits. In europe there is more thought of the environment, and social rights.

Now, this is all very black and white. There is a lot of room to aim for the european dream in America, and you can do vice versa.

I would love more of us here in the US to think a little differently. I am excited to hear about more and more communities that are modelled on real community, rather than having a big garage that you drive into, to hide for the night. Self-sufficient communities are very cool, and they are growing.

In many ways there is a chance to do the interdependent thing better than the europeans. For as much as they get together, they argue. They argue a lot. Remember how many years these nations were fighting each other :)

I don’t see as many fights between Wisconsin and Minnesota, compared to France and Germany :)

I have recently had some .NETers claiming that they do now know how we live on our side of the fence in Java-land, without value types. They laugh in our general direction as they add structs to the stack.

I do understand that value types can be useful. I do understand that it will take longer to dereference an object each time vs. not having to do that bypassing the heap entirely. There are lots of good things there.

However, I am actually quite glad that we don’t have value types. Simple put: Have you missed them? I haven’t! I haven’t run into a performance or scalability issue that was profiled, and the result was “man if we could just put this String on a stack we would be fine”. It just hasn’t been a problem.

On the other side, if you flip through Effective C#, you see items dedicated to value vs. reference types. Sneaky methods like EqualsReferences vs. EqualsValues. Subtle differences. Common mistakes.

So, give me partial classes, and true delegates, but keep your value types :)

Ramnivas is ready to take you to other dimensions in part two of his articles in the AOP@Work IBM developerWorks series: AOP and metadata: A perfect match, Part 2: Multidimensional interfaces with metadata.

In the first half of this article, I introduced the basics of the new Java

Apple keeps on trying to make it easy for developers to develop top quality applications. In Tiger they are introducing Core Data, which is a managed object model.

Basically it gives Cocoa a nice simple way to develop a model that doesn’t just map to some database.

Core Data lets you create an ERD with Interface Builder, which acts as a model.

Data Store Formats

In Tiger, Core Data support three different kinds of data store formats to save managed objects contexts to. These formats are:

• XML file format
• Binary archive file format
• SQLite database file format

Each of these formats has its strengths and weaknesses. The XML format is a good testing format as it is fairly human readable. The binary format is not human readable, but provides better performance than the XML format. Both of these formats are atomic

I thought this must have been an article on April 1st when a friend sent me the link: Wisconsin considers legalizing cat hunting.

Feline lovers holding pictures of cats, clutching stuffed animals and wearing whiskers faced-off against hundreds of hunters at meetings around Wisconsin to voice their opinion on whether to legalize cat hunting.

Residents in 72 counties were asked whether free-roaming cats — including any domestic cat that isn’t under the owner’s direct control or any cat without a collar — should be listed as an unprotected species. If listed as so, the cats could be hunted.

The proposal was one of several dozen included in a spring vote on hunting and fishing issues held by the Wisconsin Conservation Congress. The results, only advisory, get forwarded to the state Natural Resources Board.

Considering how people feel about animals that are designated as ‘pets’ vs. other animals, I would be amazed if this got through.