Tue, 24 Jan 2006

GNOME.conf.au

Blogging live from the GNOME mini-conf at Linux.Conf.Au 2006, Dunedin, New Zealand!

Good start to the day. Jeff Waugh gave the 10x10 talk he gave at GUADEC last year — but also incorporated a lot of the feedback and views he’s heard since then which made it interesting even a second time ‘round. [Not to mention it being new to most of the Aussies and Kiwis in the crowd]. It was quite refreshing to hear Jeff being candid as opposed to blindly enthusiastic (because that’s the current party line or whatever).

A good conversation about release cycles got going. One thing that puzzled me at GUADEC and that continues to puzzle me is the recognition (I’m paraphrasing here) that “while the time-based release cycle has led to quick availability of quality software, it’s meant that visionary innovations (an agenda) have perhaps been left behind” … but after discussing it for a while, the conclusion was again “we will therefore stick with the 6 month release cycle”. Huh? If you don’t change the system, why would you expect a different outcome?

The sys-admins in the crowd were fairly unified in expressing their frustration at releases being too frequent, with the result that by the time they got a chance to test a released version set, qualify it for their environment, work out a migration path, and deploy it on their site, GNOME would have moved on at least one release and the hackers themselves would by then be working on the release after that, meaning that bug fixes and polishing for the version our poor sys admin was trying to roll out on their site run would never really happen. (ie when was the last time any of us did a bug fix to GNOME 2.10 branch code, let alone 2.12?).

Lord knows I spend enough time in my professional life going around the world warning people to beware the seductive dangers of incremental change, so it’s difficult for me to be objective about this issue. It strikes me, though, that the core GNOME hackers who gained so much from switching to the 6 month cycle in the first place are having a hard time figuring out how to recapture the initiative without losing their productivity. My impression is that the religious adherence to the 6 month time-based release cycle is a structural issue which is holding GNOME back from making the visionary leaps it wants to make.

Later in the morning Glynn Foster did a live demo of dtrace on OpenSolaris. I’ve been hearing people go on about .d for ages, so it was great to see it in action [when we were chatting over beers in Bangalore at FOSS.IN, Rasmus mentioned that he maintains a Solaris box just so he can use dtrace to profile PHP. Great endorsement!]

Someone I hadn’t met before came up to me at lunchtime and said “hey, I use your bindings”. Cool! And while I quickly set him straight that the java-gnome project is certainly not mine, it’s great to listen to people describe their experiences using software I contribute to.

AfC

2006-GNOME-conf-au, posted by Andrew Cowie in /andrew/conferences/new-zealand at 05:25, 24 Jan 2006.

Sat, 21 Jan 2006

Understanding Cargo

One of my clients has me working on revamping the infrastructure they use to build their products and run functional tests across them. They’re a Java shop, and so it’s no surprise that their product, a rather large web application, is built in Java Servlets and JSP; since they target a wide range of enterprise customers they need to test their app in as many application server “containers” as possible.

Not terribly unusual, but when you’re trying to run automated tests, it gets tricky. Although in theory one should be able to interchangeably use different app-servers, the different vendors (be they open source or commercial) who have implemented the Servlet, JSP, and J2EE specs all have their quirks. Even assuming the thing you are testing doesn’t use vendor specific extensions, you still have to deal with the problem of setting up, starting, and stopping the app-server containers themselves. And as you’d expect, each different app-server has a rather significantly different way of being configured and run.

Enter Cargo. It’s pretty slick! They have figured out how to configure, start, stop a wide range of different containers and in some cases can control them during runtime. This is all important if you’re trying to do automated testing of a Servlet based web application, because you need to have the container running and your app deployed into it before you can start doing functional tests against it. Their API is primarily meant to be used from within Java but they’ve also made ant tasks and maven plugins.

There are a few examples on the Cargo website, but figuring it out took some doing. Cargo has about three different ways to do any given task — you can set something up using the fully derived strongly typed implementing classes, or you can use one of two factory methods. Presenting all of this at the same time is confusing to say the least. Cargo consists of several very steep class hierarchies with parallel naming conventions. The terms “Local”, “Remote”, “Existing”, “Standalone” are used in permutation with “Container”, “Configuration” and “Deployer”; for instance you have a WebLogic8xLocalContainer and a Resin3xStandaloneLocalConfiguration. Gets confusing when you’re trying to learn the API for the first time, and makes code assist completion really hard (typing “Tomcat” and hitting assist, you have the joy of selecting from Tomcat3xLocalContainer, Tomcat3xStandaloneLocalConfiguration, Tomcat4xLocalContainer, Tomcat4xRemoteContainer, Tomcat4xStandaloneLocalConfiguration, Tomcat5xExistingLocalConfiguration, Tomcat5xLocalContainer, Tomcat5xStandaloneLocalConfiguration, TomcatCopyingLocalDeplyoer, TomcatLocalDeployer, TomcatRemoteDeployer, … you get the idea. Pretty crazy).

The point of me looking through all this was to be able to help my client make a decision about whether to use Cargo in their build & test architecture. I battled my way through their documentation and javadoc trying to duplicate a simple example. Once I started drawing some simple diagrams of the class hierarchies, though, it began to come together. I did up my notes in OpenOffice Draw to make them presentable. Here’s the result:

First, cargo has the notion of a “configuration” being a particular setup for an instance of a running app-server container. This takes a brief moment to grok because normally one installs WAR/EAR files directly into the appropriate directory within (under) wherever the server is installed — only since one normally only ever has one instance of a server on a given box, you don’t tend to think about it. It turns out (always something to learn) that the Servlet and Enterprise Application Server specs state that the information and data to be used in a running instance can all be bundled together and put … wherever. Cargo calls it a Configuration. It’s a steep hierarchy, but the important bits seem to be as follows:

Once you’ve got a configuration, then you bring up the app-server container with it. Cargo’s Container hierarchy is like this:

As you can see, there are considerable variations on the core theme - did you set it up before you ran the app-server, or after; is the app-server Local where Cargo can get at it, or Remote where it can’t…

Once you get the sense of it, though, it’s a very powerful tool. To accomodate the wide range of containers that Cargo does is a remarkable achievement, and watching it Do The Right Thing (tm) in each different case is remarkable.

AfC

cargo-hierarchy, posted by Andrew Cowie in /andrew/software/build-systems at 08:52, 21 Jan 2006.

Sun, 01 Jan 2006

Happy New Year, apparently

14:00 local time in Sydney, 1 January 2006:

Adrian Cronauer: It’s time for the weather report, and we’re going out live to the field:

Roosevelt E. Roosevelt: It’s hot. Which is fine if you’re with a lady, but it’s no good if you’re in the jungle!

Adrian Cronauer: Well can you tell me what it’s like?

Roosevelt E. Roosevelt: Fool, were you born on the sun? It’s hot. Damn hot. So hot I could cook things in my shorts… I saw this little man, dressed in orange robes, burst into flames.

— Robin Williams, “Good Morning Vietnam”

AfC

fourty-four-degrees, posted by Andrew Cowie in /andrew/travel/australia at 03:35, 01 Jan 2006.

---

Category Specific Feeds. Use these links for an RSS or ATOM feed limited to this category and its descendants. Technorati Profile

---