Expo-C

posted Sat, 04 Jun 2005 16:51:00 GMT by Jonas Bengtsson

This week I attended Expo-C, “a 3-day Software Architecture Conference” of which I went on two days. Software architecture is a dangerous word since it might imply so many things, from “oh so boring” to “a hoot” on the interest scale. Fortunately, this conference managed to place itself closer to “a hoot” than to “oh so boring”.

Rickard Öberg’s presentation of Aspect oriented programming, AOP, was truly interesting. I can only find one reference to AOP back in 2002 on this blog, so I think it’s safe to say that this was my basic opinion of AOP before the conference: nice ideas, but complex and will it work in larger projects? I have looked at AOP once in a while but never fully grokked it, and never used it for anything larger than testing that it works. And languages like Ruby and Python have made more impression on me.

Rickard’s presentation opened up my eyes for that AOP is really interesting. But then again, anyone who put this quote on the fourth slide has my full attention: “Inheritence sucks as a means of reuse”. That is a statement I can wholeheartedly agree with. The standard AOP example, the trace example, is nice and that kind of AOP (advice in AOP-lingo) is probably very useful (transaction management, caching, security and so forth are other similar functionality). But introductions, that is methods and data introduced to an object or class, is what really got me thinking. Rickard’s product, a slick CMS called SiteVision, used AOP (a home-brewn version) religiously, and it seemed to be a successful approach.

Another thing that Rickard stressed was tool support, and I do agree that tool support is crucial for the success of AOP. Back in 2002 AJDT was new, but now it seems to be a mature product, and it have some nice visualization features (I’ve just tried to create a simple aspect so far, due to lack of time).

The other main attraction of the conference for me was Rod Johnson who had one presentation during Tuesday, and a full-day tutorial of Spring during Wednesday. Web development frameworks is something that has interested me for quite a while, for some peculiar reason. I have only done two web projects, an e-learning system in PHP and a community in Java, and those were done during my university studies. Nowadays, my main interest, which I share with many in the blogosphere (at least the parts I follow), is in Ruby on Rails.

The conference was quite directed towards mainly Java/J2EE and somewhat towards .NET. I’ve been out of the Javaverse for a while so it was due time to get reintroduced. J2EE seems quite overcomplex and painful so I understand where the need for lightweight frameworks, such as Spring, spring from (bad pun intended). There is a lot of great ideas in Spring and it put a lot of emphasis on testability, to be non-invasive and to promote good design. The main tool to achieve this is, from my viewpoint, IoC/DI.

Inversion of Control (IoC), or Hollywood Principle (“Don’t call us we’ll call you”), is a pattern to loosen the coupling in a system. Instead of objects creating all the objects it needs, setters and constructor arguments are used to give an object the objects it needs. And (don’t know if it’s required or just recommended by the pattern) interfaces are used in preference of classes in order to further reduce the coupling. I think this is great in terms of testability: all external dependencies of an object is possible to configure/mock so you can test objects in isolation. Another great gain is that highly coupled designs become evident—classes with many external dependencies are easy to hide if the only way to notice the dependencies is to look at the source.

Dependency Injection (DI) is a technique to manage all the dependencies that IoC makes apparent. E.g. Spring figures out, aided by XML configuration and introspection, which objects that needs to be created for a certian class, create those objects and uses constructors and setters in order to inject the dependencies. Pretty neat to see Rod’s demonstrations of Spring and IoC/DI.

Singelton begone!

Spring also has its own support for AOP (working in a similar way as Rickard’s using dynamic proxies), and Rod pointed out that it’s a good idea to unit test classes without aspects since you want to test classes in isolation. Let’s say you have a security aspect, then it probably needs some setup in order to run, and that seems like a lot of work for a unit test and many thing that might go wrong and interfere with the tests, it’s more of integration test issue. That’s no problem in Spring since objects are just POJOs (plain old java objects), aspects are added by the Spring container so when you don’t use the Spring container you have no aspects. But how do you do that in e.g. AspectJ where the aspects become part of the bytecode? There is an infant project called aUnit, but that seems to just unit test aspects themselves in isolation. Or do you just use a different, non-AOP aware, compiler? Does anyone out there have any suggestions?

There were also a lot of other things in Spring that were very appealing. More metadata and code than Ruby on Rails, but if I’ll do anything server related in Java, I will certainly look at Spring.

One thing that I thought of while listening to all the interesting stuff about AOP, IoC/DI was how this would translate into the Ruby/Python world. The concepts apply even there, but the programming languages are more hackable than Java, thus it ought to be eaiser to achieve. There are probably many different approaches in the Ruby/Python world that I will have to look into.

Great conference! Would gladly come back if they manage to get as good, or even better, speakers!

Comments Zero comments

Now I kind of GET it

posted Tue, 24 May 2005 23:37:00 GMT by Jonas Bengtsson

Just an update to an entry I posted some days ago, where I ranted a bit and touched upon Ruby on Rails getting support for Javascript generated POSTs on links. I didn’t see the problem back then, but today I understand a tad more learning that Flickr had a serious defect with GETs.

Eric Costello provided this enlighting quote on the Flickr API mailing list from the HTTP/1.1 RFC:

In particular, the convention has been established that the GET and HEAD methods SHOULD NOT have the significance of taking an action other than retrieval. These methods ought to be considered “safe”. This allows user agents to represent other methods, such as POST, PUT and DELETE, in a special way, so that the user is made aware of the fact that a possibly unsafe action is being requested.

That makes sense, but it wasn’t something that I was actively aware of (I’m not a web developer, so I’m not too embarrassed). If this advice was followed, the hoopla about Google Web Accelerator “prefetched” naughty pages such as “delete this post” in WordPress would never have happened.

But I’m still not sure why you would like links that works as POSTs. Are FORMs too cumbersome? Perhaps it’s a brilliant idea but I don’t understand enough of the problem yet — still learning.

Note to self: use POST (or PUT/DELETE) when the state is changed on the server!

Comments Zero comments

Javascript and links

posted Fri, 13 May 2005 01:14:00 GMT by Jonas Bengtsson

Looking at today’s Daily WTF is amusing, where VBScript is used in a tad unnecessary way. Using VB/javascript for something as basic as links makes me cringe. A few years back I read a bit about ASP.NET because it was new and for some reason I have been interested in web development frameworks for quite a while. But I didn’t like it, mostly due to its usage of javascript for links (that’s at least how I remember it, although my memory might be failing me and ASP.NET might have changed since).

Nowadays, Ajax is all the rage, and javascript gains popularity. I think that Ajax, à la Gmail, is nice and might have the possibility to transform the web experience to some degree. But still, I don’t like relying on something fragile as javascript for something basic and fundamental as sending and receiving information. The simplicity of HTML and http is, if you ask me, one of the main reasons of the success of the web.

When Gmail first came into beeing, it didn’t work on browsers that didn’t support XMLHttpRequest. Nowadays there is also support for other browsers. Backpack is another Ajaxy web application that doesn’t support browsers such as Opera. That makes me little nervous since Backpack has been the driving force of the Ajax support in Ruby on Rails. I really like RoR so I hope it doesn’t take a wrong turn. Even though I don’t fully understand the problem, javascript generated POSTs on links seems wrong.

I’m all for experimenting with Ajax to enhance the user experience, but if the browser doesn’t support what you are trying to do, you should degrade gracefully. Everything else is soo 1998!

Comments Zero comments