Head On

Chiara wants to work where Jon works, which is where I work too.

I wanna work where that boy works.

Just so you know, we're an XP shop :-).

What time did Mr.Tirsen arrive?

Our morning meetings are at ten. I believe he was in by then.

As for the rest, sticking to architectural guidelines etc … too bad. “Do the simplest thing that can possibly work” and “You Ain't Gonna Need It” are our mottos. Works wonders with architecture too, but it requires them “best and brightest” to come down from their ivory towers and start contributing to the code. I know a few people who feel that coding is below their skill level and dignity, so they won't. Whatever, they will be the first to go when the revolution comes :-).

Long time, no blog. Too much holiday and managemental duties to keep me away from the development trenches. But I keep up with what others are writing and it has mostly been discussions about code standards and how stupid people think George W. Bush is. Oh, and that really weird C# vs Java thingy.

But hey presto! Things are living up again! And let's start of with that good girl Chiara who I enjoy immensely but not necessarily agree with.

I don't think Kent Beck has neither the expertise nor the talent to make decisions about how programmers should work.

Uhhm … how shall I put it … how can I express how much I disagree? When I first was introduced to XP I hated it, since it was shoved down my throat, much the way french geese are fed. Turning point #1 was when I went to, the most excellent, JAOO conference where Kent held a keynote speech. That sort of took my blind hatred away. Then at next years JAOO Martin Fowler had a half-day tutorial in the planning game. My world has not been the same since. We now run our home-grown version of it, pair-programming and all. We twist the idea of the customer on site since we're a product company, we use JIRA instead of the orthodox way of the cards and a few other things. Oh yeah, we sit down at our morning meetings too.

The point I'm trying too make is that there in my mind are few people in the world better suited to speak out on developer practices than Kent Beck. He, Martin Fowler and Alistair Cockburn my top three sources of wisdom.

I think Rickard is an alien!!

From what I've read I wouldn't be surprised if he thought you were one too

Why “Head On”? Because it's a really awesome song by never-as-famous-as-they-deserved The Jesus and Mary Chain. And a good attitude when tackling problems.

Bernard replies to my reply:

[Me]My thoughts were that it is easier to transform bare data as it is less to transform. You take the old data and insert it into the new code, which is all you need because you don't want the old implementation anyway.

[Bernard]I guess you are somehow comparing apples and oranges. If you want to compare data storage then instead of storing Java objects with data and business logic, just store some objects having data only.

Sure, if you store objects with only data you are quite close to the tabular data model. But remember, I only want to be able to “offer” it for OLAP purposes and for upgrades, if then.

I don't want to degrade my business objects, I want them to carry as much info as possible. This to ensure that the state is all set and verified before the Command executes, as discussed on the Prevayler site.

To sum up the upgrade story: when moving an application between version, the persistent state needs to be transformed. The less info in the persistent model, the less to transform. That is why I, initially, believe that the tabular data model is good for upgrades. But as mentioned, I'm intrigued by the XSL approach, and we will most certainly try it out.

[Me]However, we may have to provide a tabular data model for analysis purposes outside the scope of our application. The standard way to access this is using SQL. This is the only reason I want it.

[Bernard]At least if your external application could use JCA you could think of a JCA implementation for Prevayler.

Very nice thought. We want to provide as a broad support for data extraction as possible which probably would make a connector a good choice.

[me]This morning Jon had a good way of formulating what I wrote on the two persistence needs: “RDBMS do two things: OnLine Transaction Processing and OnLine Analysis Processing. After Prevayler we only need OLAP.”

Agree. This is an empty room for Prevayler. We might have a look at some integration with Mondrian which is rougly a Java OLAP implementation working in-memory.

Mondrian looks way cool. Will look into it more.

By the way I realized that my name is not mentioned here, and Jon keeps on calling me “boss”. This is corrected now.

Bernard commented on my thoughts on schema evolution.

I do not see why schema evolution is harder to handle in Prevayler than it is with a relational database. Changing relations is always a problem whatever the storage strategy you use.

Hmm, let's see. Maybe I was very using traditional thinking. My thoughts were that it is easier to transform bare data as it is less to transform. You take the old data and insert it into the new code, which is all you need because you don't want the old implementation anyway.


But you're saying that with Skaringa I transform the Java object graph to XML, transform that XML data using XSL to a new XML format matching the new code and deserialize it. Whoomp, there it is? Sounds very nice.

Next, do you truly believe SQL is the best way to query your object model?

No, not my object model, not at all. However, we may have to provide a tabular data model for analysis purposes outside the scope of our application. The standard way to access this is using SQL. This is the only reason I want it

I also have this nagging feeling that many customers will want their data in a RDBMS because just because it has always been there. What would we do there? Delete and insert for every snapshot?

This morning Jon had a good way of formulating what I wrote on the two persistence needs: “RDBMS do two things: OnLine Transaction Processing and OnLine Analysis Processing. After Prevayler we only need OLAP.”

Well, stay tuned, or better help the people working on the XML export for Prevayler. As said before, SQL is in my opinion not the best thing because it requires mappings between your objects and your relation database. And >>ODMG API would probably be better. >>Carlos Villela wrote a >>XPath query demo

We will definitely work with Prevayler to enhance this functionality. As for JXPath, already there :-).

Jon and I had a pretty heated discussion today over serialized objects. The background is as follows:

Using Prevayler, you will have a file on your disk with your serialized object graph. This stores the state of your application, but, very important, also the implementation of that state. When deserializing the object graph, you do not retrieve properties that are set on “new” objects, you are retrieving the object itself. Like, duh.

This introduces a problem when changing the object schema. If you update your application and the new runtime has a different set of classes, you're screwed. Sure, changing the name of a property or class can easily be done, but what if relations are changed?

Now to my thoughts: The problem is that the serialized object holds too much info in the upgrade scenario. We don't want to know the implementation then, we only want the state. We thus need to transfer our snapshot from a serialized form to a form with less info. If we can do this we get away from what Joshua Bloch in “Effective Java” describes as making our private code be a part of the API. Using this, we can insert this data into a upgrade program and setup the new object graph. This is not ideal but it works. (Agree so far Jon?

One good thing about a relational database is that it stores a bare minimum of information regarding system state. This means that the dynamic implementation, your runtime, can change and the static, stored, state is changed with a minimal effort. This is truly Good.

But that is not really what is good with a relational database. What is good is the tabular data model. It could as well be described in another format such as any homegrown xml-format. So what is good about relational databases?

I can't believe I'm writing this, but the good part about relational databases is, argh!, SQL. It is the standard way of retrieving information that is the catch. It is Crystal Reports and Excel. People want this. Not me. Other people. I wish we could just do a XML-serialization, which is all we need for updates, but I know customers will want the SQL support so that they can use their tools. Anyone know of any XML tools with SQL support? (Probably very common, I haven't looked yet)

A long time ago somebody suggested that Java should provide a versioning system, so that a class is not only defined by its name but also by it's version. I suddenly realize that this is new no 1 of my “Things I want included in Java” list. This would solve the schema evolution problem since every new version of a class could have a constructor that took the old version of the class as an argument.

As I see it, persistence is needed in two different ways.

1. In the running application where the data is strongly coupled with the code and performance is very important.
2. Snapshots for data analysis and updates. This data needs to be “flexible” but performance is generally not an issue

To me, RDBMS solves number 2 very well. I used to think it was half decent at no 1 as well.

Ok, to sum it up, I want to be able to convert the Prevayler snapshot to an XML equivalent. I want that to be readable through SQL. I want a Java to handle versions. I want World Peace and free ice cream.

We're right now trying out Prevayler as a persistence layer for our products. It is basically the coolest think I've seen since I became an OO-afficionado. I did start out with Smalltalk, and it sort of set the tone for what I believe in.

I need to check out if Jon has mentioned this on his blog. Nope, he hasn't so I'll be first then.

Here we go: What Prevayler basically does is store your object graph in memory, recording every transaction as a serialized Command. Every 24 hrs a snapshot of the full object graph is written to disk and the log is cleared. Crash recovery is performed by taking the latest snapshot and redo all the commands that is deserialized from the log.

This basically means complete transparency, wow-whiz-bang performance, database independance and a call to your local RAM-dealer for more memory. It is also very reliable, the full package is something like ten classes, meaning very few dark corners for bugs to hide. We've tried it in development and yes, it rocks. I could dance the funky AOP-chicken here and tell you how fast it was done since we only removed the OJB interceptor and added a Prevayler interceptor, but I won't. Seriously, sure, that rocks too, but haven't we sort of agreed on that by now?

So what's the backside? Schema evolution. I'll save that for a separate post.

I've always been a fan of Netscape, but at the same time I never liked the Communicator idea - everything in one package. I don't have a one piece stereo either, I'm just not that kind of guy. The Phoenix webbrowser is just right for me, it's fast and lightweight and does not bring anything else down with it if something goes wrong. If Mozilla blows up it takes the mail session with it. If, using Windows, IE blows up everything is gone, reboot and grab a coffee.

It was therefore a pleasure to see the announcement of Thunderbird which is the mail client version of Phoenix. I have always preferred the Netscape mail client so this is truly good news. Now, if somebody could fix a Palm address book integration to go with it, I'm would be incredibly happy.

I looked at the logs for freeroller and realized that 75% of client OS's accessing it was Windows. This is of course a lower percentage than would be expected from a more generic set of computer users (I assume we're all geeks here, right :-), but still, 75%.

I most certainly don't want to start another Windozesuckslinuxisugly debate, but I was thinking that most sites accessed on freeroller have a strong connection to Java, and often business system Java - as opposed to embedded etc.

The main competitor to Java as business systems go is of course .NET. How come that 75% of the programmers who have made the Java their choice of programming language use Windows as their operating system? Why are they not preferring .NET?

Is it that they consider Windows a superior client os, but want the freedom of choice on the server? That they love the Java syntax? Someone else made the choice? Is this a small indication that .NET is a failure? Just curious.

Up until two years ago I also used Windows as my client os for programming. But then Sun started releasing the JDK's for Linux at the same time as for Windows and Solaris. I made the switch and never looked back.

For the sake of it, I'm writing this using Phoenix on Windows on my home machine, which dual boots Win XP and Red Hat 8. I strongly prefer RH8, my wife Windows.

There has been a lot of talk about news aggregators. Personally I'm using Amphetadesk which does the trick and more. One must know the little secret to using it though. The basic setup works just fine, but the fun starts when you go for this addon which adds expand/collapse of news feeds, time since posting etc.

Rickard is using mozilla 1.2b. I used it until I stumbled into the Phoenix world, where everything is lighter and oh so fast.

Seeing is believing, try it out.