techno.blog("Dion")

I was always told that sex before sport was a bad thing.

It appears that this may not be the cases, and even if it is it doesn’t matter according to a recent article on sex and the olympics:

Let the games begin

If this was an advertised fact, they may be a bunch more olympians!

Rickard has spoken up to the concern that Gosling had on AOP:

Rickard Oberg

We have been using AOP (note the “P”) since July 2002, when we started building our CMS product SiteVision. Many on our team used to work on another similar product for another company before, and it’s interesting to look at some of the metrics. In half the time, with roughly half the code, we have twice as many features implemented as the other product. We’re 5 developers, but since we also do installation, training, support, and sales, I’d say we have had about 6 man years of effective development time. To go from scratch to top-five CMS’s in Sweden in such a short time, and with such a small number of developers, is a pretty decent thing to accomplish methinks.

Our typical time from idea-to-implementation is roughly between two days and one month, because typically we can reuse 30-80% of a new feature by using already built aspects (both advice and introductions).

We have, among many other things, implemented replication, client-side undo management, transactions, transparent partial object state versioning, security, locking, etc. as aspects, which we can reuse on any component or object model. Whenever we start on a new feature all such things are already there and “just works”.

I do know that we are probably an anomaly when it comes to using AOP, both in what we use (=homegrown) and how (=throughout product), but I still think it’s a good sign that AOP as such is not only viable, but can be a *key factor* in developing competitive software. I can safely say that *without it* our company would be dead by now.

Oh, and it’s both performant *and* maintainable. How ’bout that!

James Gosling

AOP is kind of a complicated one for me, because AOP is one of these things where the theory sounds really good. I actually mostly like the theory. The way it turns out in practice tends to be pretty dangerous. It’s fraught with all kinds of problems. You know when the AOP folks talk about AOP they list you like three or four use cases for AOP and they actually mostly make sense, although they have problems in the details. But there actually aren’t very many use cases outside of that. And when you find people who are using AOP, the average ones that I’ve talked to have been using it for things that are just like incredibly inappropriate. It’s like a really, really, really bad idea to be doing what they’re doing. And so I feel very conflicted because on the one hand I basically like the concept, but I don’t think that the research community has really figured out how to encapsulate those in a mechanism that really works for people. It’s like giving them a chainsaw without any safety instructions.

People have replied to Rickard saying “well. your opinion isn’t valid for the Real World, as you are smarter than the average bear”.

This has been said many times over the years hasn’t it. We could look at this point in a few ways:

• Yeah it is different and dangerous. Let’s never touch it, even though it can give us benefits
• I will use it cautiously. No need to jump on AOP for everything today, but I can incrementally use it (policy, testing, debuging, etc before going to production)
• It is very powerful. I see this as a GOOD thing. This will be my secret sauce, and will enable me to deliver faster than the cautious ones.

Rickard has gone with #3, and is able to do just that. Would a junior guy be able to jump into the codebase? Maybe so, maybe not. Who cares… his company is thriving.

NOTE: Just because AOP is being used, some junior guys wouldn’t have to be in those modular concerns, and their code would be SIMPLER because of it!

Darryl Taft has a nice chat with James Gosling.

He talks about many topics, including Groovy. In general he likes it, but wishes it was a bit more daring. He even had a list of questions / thoughts for the Groovy team, and hopefully James will ask him for the list. I bet there are some interesting items!

I think Groovy is pretty interesting. I think they’re being fairly conservative. I think they could be a little more outlandish and get a little more interesting.

remember sort of reading through their syntax list and saying, “Oh, why didn’t you do this and why didn’t you do that?” There were some things about the way that they did sort of the equivalence of declarations and some things about the way they did case switch statements

The Jini camp is trying to be heard again. This time, Sean Landis is talking about Service Oriented Architectures – Separating Hype From Reality.

Using Jini for SOA’s is an after thought, yet has been successful (e.g. Orbitz). Now there is a fight for the world of “grid computing” which Jini has been known for in the past.

Having a wife who has a masters in education, I am used to hearing about Pedagogical means too ;)

Here are Seans conclusions:

Web services has begun to slide down into the trough of disillusionment. For reference, Jini appears to have passed through the trough of disillusionment and is climbing up the slope of enlightenment. (These are my estimates. You can see exactly how the Gartner Group evaluates them for only $495). How deep will the web services trough be? Will it find a niche after enlightenment? I think so.

Web Services is a great integration technology (like a modern EDI). It provides a “common backplane” for weaving together disparate functions and allowing them to work together. For the IT department, web services is a Godsend. In that universe, the endpoints can be managed to ensure true interoperability. Whether web services is better at this than something else, say Jini, is a arguable. For example, if there’s a degree of dynamic behavior, if services may come and go, then Jini would be better. If the environment is static, then web services is great.

Web services is a good tool for exporting non-web services to a web environment. In the IT world, a web-based SOA has the advantage of utilizing a browser as the client. This can ease development, but there are still problems. For example, one must standardize on a set of browser primitives or require a baseline browser. Furthermore, the client is fairly limited in what it can do computationally. With Jini, the proxy and the UI are actually written by the service provider and dynamically downloaded to the client as needed. There is a base JVM requirement, but in practice, this tends to be easier to manage than the browser problem. Furthermore, the proxy can contain significant sophistication that goes beyond what a web service application can provide.

Web services are not good for complex systems including service ecologies (SOA). For very simple service interactions, web services may be sufficient, but they may not be justified due to the cost of implementation and deployment. The bottom line is that there are too many important characteristics lost due to the design assumptions of hiding remoteness and providing language-independence. If you are considering employing SOA, then consider what’s been written here, and consider a pure Java and Jini approach over Web Services for building your Service Oriented Architecture.

I often grab the code of an open source project and dink around (especially if I am finding a bug appearing somewhere).

Most open source projects have a build.xml, with some living in the Maven world (which can generate a build.xml itself).

Wouldn’t it be totally cool if I could point IntelliJ IDEA to the build.xml, and it could work out all of the classpath needs automatically.

This would mean that you could get going RIGHT AWAY, without having to go into the project properties, and setting up all of the libs that you need.

When I saw that Jonathan Schwartz was talking about Commodities, Railroads and How Sun Monetizes Java I thought I was looking at the blog of Pat Helland.

Pat enjoys using analogies in his MetroPolis series of articles, talks, blogs, etc. Now Jon is stealing his puns? ;)

I think I agree with James’ thoughts on displaying cardinality in a language

(from a comment on Generic type parameter naming A.K.A Line Noise)

James

Agreed! I do find generics a little jarring on the eye – I’m not convinced of their value in Java other than as introspect-able metadata/reflection.

I prefer the X# or Comega approach of using type cardinalities in the language, which solves elegantly most peoples use of generics – type safe collections.

class Customer {
String! name
EmailAddress+ emails
PhoneNumber* telNumbers
String? comments
}

which uses DTD-like type modifier postfixes. They’re a little wierd at first but they soon feel quite natural, after all we’re used to adding [] as a type modifier postfix

This is a lot nicer on the eye. With Generics we are seeing different information (a List that contains type X, a Map with keys of Y and values of Z, deciding the implementation of List that you want, etc etc).

When whipping together designs (either on a piece of paper, or in a UML tool) we often use this cardinality and do the mental leap to code. Why not use the same form?

Going to add this to Groovy, James? :)

Jason Bell states “I was wondering how long it would take before the Groovy bashing would start“.

Elliotte Rusty Harold also had some thoughts, and James responded to them too.

Whenever a new language comes a long a group of people come out and say “it sucks. I hate [insert feature here] about it!”.

Groovy may not be your bag baybee. That’s all cool :)

You like Python? Great… it is a very nice language. Ruby? Perl? Java? ditto.

Noone is coming to take away your toy, or force you into using something :)

I personally think that there is value to Groovy. I like the way that I can use it as Glue technology. I don’t think that the rigid static typing way is for me on all projects (or part of projects) and I like how I can switch between a .java and a .groovy.

I prefer looking at my ant scripts in Groovy syntax (if they get complicated and I need to do iteration, or anything in the slightest programming-ish, then I want to get away from build.xml). I like Groovy Swing/SWT for putting together GUIs easily. I like unit testing with Groovy. I like using WebWork Actions with Groovy. I like writing scripts that reuse my core Java business logic with Groovy. Etc. Etc. Etc.

It doesn’t save the world. There are other great languages. Use what you feel most connected with!

I want to get Bush out of office.

I have been seeing lots of people (all over the US) in the streets talking about getting Bush out of office.

Part of me was getting a little worried about the fact that this is pessimistic, and if they are Kerry campaigners they should be spending time using the more possitive “Get Kerry In”. I really hope Kerry comes out from under his strategists, and shows people what he is made of, what he believes in, etc.

However, then a friend told me that

If your pants are on fire, the first thing you do is get them off. THEN you worry about what new pants to wear.

Some would say that this is a bad thing. Others would say “but the other pair are on fire too”. In this case, I really hope we get this guy out. Kerry *has* to be better (no matter what Cam says :) )

It looks like John Kerry uses a Powerbook

Hopefully this isn’t just a prop