techno.blog("Dion")

Air America Radio launched today.

It is a radio station that discusses views from the left.

I love how Al Franken’s show is called “The O’Franken Factor”. As well as Al, you can listen to Janeane Garofalo, Randi Rhodes, and more.

It is nice to hear radio that goes against Rush, Newt, and all the other right-wing crap.

Cameron has a lovely post showing WebSphere 5 classpath hell.

Doesn’t this make you cringe?

When I was at the AOSD conference last week IBM announced their support for AOP. In the announcement they discuss how WebSphere was a test-bed for this new technology. Some of the AspectJ guys were able to do some impressive things with WebSphere…. which I found quite amazing since I guessed that it had to be one of the biggest hogs out there.

I keep hearing “No, WebSphere is better in version “. Then a few months later I hear the same thing again, with a new version. It amazes me that some analysts claim that it has the market share that it does. Is it really just because they give away for free * with their hardware? Are people really getting it working? Is 5.0 really “OK now”? I hope I don’t have to find out!

Kathy Sierra has come out with an interesting opinion on Pair Programming: Pair Programming is NOT always a choice.

Everyone has a personality. Pair Programmers are people too :)

It would be very interesting to see some studies on the trends in pairing.

For example, I am 100% comfortable with a co-developer. It is fun to work with him, time flies, we are very productive, and as time goes on we just know eachother so well. When I pair with someone else who I may not like as much… the dynamic changes. With every pair there is a new dynamic.

So, does it make sense to pair with the ones you love, or should your team have measures to make sure that EVERYONE pairs with EVERYONE (e.g. putting up a matrix showing who has paired with who). What is more important: Spreading the knowledge perfectly …. or “cheating” a little :)

I somehow missed the developerWorks article: Use AOP to maintain legacy Java applications.

What is more interesting to me than the tech in the article itself, is that fact that these articles are coming out.

Developers are starting to read about AOP and its various uses. This article discusses a use case which is simple to get your feet wet. You can play with aspects in development to mine your code, and it never touches the more dangerous grounds of production.

Every time I hear an AOP expert discuss the ramp-up of AOP they show “the curve”. The curve talks about how you can start dinking around in development (tracing and such) and slowly move up the stack as you become more familiar with AOP. Learning to think in AOP isn’t trivial so this approach is very much needed…. to ramp up your brain. You will make mistakes at first (as with any new tech) and you don’t want your first mistakes to cross-cut on every piece of code in your running production system.

Congrats to James, Richard Monson-Haefel, and everyone involved with Groovy.

It was great to see that the JCP Approves Groovy Language JSR: Sun endorses language.

This really is a great precedent for the Java platform. There was a time where the JVM had a bunch of languages, yet Sun didn’t want anyone to know / help / etc. Sun had the “one language, many platforms” approach versus Microsoft’s “many languages, one platform” take.

Now we can move to “right language for the job, many platforms” which will be good for everyone. The funny part of it all is that in real projects we have always used many languages: Java, perl scripts, bash, cmd.exe, SQL, velocity, JSP, XML, etc.

It would be great if some of the JVM developers did some work on optimising for dynamic languages too.

It’s a Groovy day.

I am really excited about the marriage of AOP with the new JSR 175 annotations. As I have mentioned before, I am a little worried that they will be taken too far, and we will run into @ hell.

Having annotations in classes are cross-cutting concerns themselves, and so we have a chance to deal with them in some cases via AOP.

This will naturally happen anyway. Tools that have up until now said “A method that is set*() is a setter” will probably start to use:

“A method that is set*() AND doesn’t have a @nowrite annotation
OR
A method that has a @write attribute

This is just due to some legacy rules that we have lying around.

Some scenarios will be ripe for us to just slap on some annotations manually. These will be for the types of metadata that don’t tend to be slapped on a huge amount of methods all over the shop.

The other side of the house has cross-cutting concerns that can applied to a heap of methods. The exteme would be something like having to put @log on every method that you wanted to log!

For this scenario we can mix AOP with annotations. AOP will be responsible for weaving annotations into our code.

Right now we use AOP to put marker interfaces on certain classes… e.g:

declare parents: org.atrack.ui..controller..Edit* && Action+ implements StartsApplicationTransactions;

With metadata we will be able to do something like:

declare annotation: org.atrack.ui..controller..Edit* && Action+ annotates @Transaction(type=”Requres”)

James talked about some cool new things from the Groovy world in: Using Groovy XmlRpc to talk to Confluence, NanoWeb, Groovy-Ant (Gravy!) and more.

If you are on the groovy list you start to see interesting thoughts popup on a daily basis. With this little JVM based dynamic language, people are able to re-visit their views on a number of things, and are coming up with new ideas.

Of course not ALL of the ideas will be great, but there are a few interesting ones. Jon and I had some fun talking about what AOP-like things could make sense with a dynamic language, and have to play around with those.

I also really like the Gravy (Groovy+Ant) idea. Ant works very well in small projects when you just have to do the usual: javac, copy, jar.

However, it is very frustrating when you start to play cames with setting properties and having if=”…” in targets to get certain behaviour. I used to use a Perl build tool in a past life, and although you may laugh (oh god. Perl) it was very flexible, straightforward, and let you do the right thing. Sometimes you need to do things in your build that are totally suited to a scripting language…. and Groovy will take care of this for you.

I wonder what good ideas people will come up with next week….

Kudos to James for apologising for Jelly. It is OK to try new tech and see where it takes you! :)

I had a nice chat with Jon Tirs

People were bubbling at AOSD after the IBM keynote. It has been quite widely known that quite a few large companies are using AOP, but keep it hush hush. Now the time is coming where it is actually “cool” to differentiate yourself by aligning with the technology, and many companies are seeing how it is helping their lives.

I think it says quite a lot when a company as large as IBM can get a new technology as different as AOP into their large bureacratic departments. They do have the most to gain, but it still a big effort. Adrian’s life is going to get even more crazy in the coming year (Adrian is the lead on AspectJ, and great guy).

Getting developers to think in aspects is no mean task, but we will get there. Gregor uses an interesting story when introducing AOP:

In AspectJ there is an example used which is a GUI figure editor. If you ask today’s developers to think about how they would solve this problem they will probably come up with:

We will need a Point class, a Line, an abstract Shape, etc etc. Basically they are trained to think in objects now.

However if we asked this same question 20 years ago what would those programmers have said? They would have talked about creating a table of X, Y co-ordinates and drawing functions. The idea of thinking in objects would be foreign for them.

This is where we are at now. One of the beautiful aspects of AOP (pun intended) is that a team can use it incrementally…. and in fact this is what the leaders in this space PREACH. Don’t go out and start building a full AOP production project. Start small. Use it to do some analysis (such as IBM doing this to find a bunch of policy breakages in their products). Use it to enforce certain policies. Then strap it into development to enable tracing and exploration of code. By the time that you are here…. you will be familiar with AOP and will be ready to keep moving up the stack slowly. It is very easy to do the wrong thing with AOP, and this incremental approach minimizes this risk as you cut your teeth on non-mission critical areas.

Let’s continue the slow but steady march of AOP!

IBM endorses AOP: “It is vital for our survival”

While in a session at AOSD there was talk of a Diagnostic Exception Handler. In my experience, developers are (in general) pretty crap about dealing with exceptions. If you don’t have a process to follow it is bloody hard to do the right thing all the time (and isn’t always easy when you do have a plan to follow).

I wonder if a Diagnostic Exception Handling engine would help. In the AOP world is would be cross-cutting advice, so in your code you wouldn’t have to do anything differently (just try/catch/throw). A handler would apply advice at the right time and could put it through an engine that could work out what to do with it.

Depending on how advanced you got this could involve:

• Simple: Just taking care of your logging needs
• Do certain retries
• Simple logic: e.g. commit() if app exception, rollback() if system exception
• Run the exception through workflow logic that could try to really do The Right Thing

We will always have to think (god forbid!) about what to do wrt exceptions in our code, but it would be interesting to see if a nice system could help us out….. or it could just be total overkill ;)