Disillusion - Do you really want the red pill?

Yesterday I received a packet from Amazon with the book JBoss(R) Seam: Simplicity and Power Beyond Java from Michael Juntao Yuan and Thomas Heute. I immediately started reading.

Since Seam is a very interesting product, I was (and still am) very curious about the book. My first impression is quite positive. The book seems to contain a lot of interesting and advanced information. It is not a book for beginners, since it compares Seam a lot with traditional Java EE applications, and presumes that the reader has knoweledge about the latter.

So far so good. So before my mental eye I started to construct a picture of Michael Juntao Yuan. This process was influenced by my personal hipe for Seam combined with the coolness-factor of working for JBoss and now the awe for a book-author…

The result was my mental materialization of a smart ueberhacker:

Now I tripped over this:

Oh no no no! Abort transaction! Somebody give me the blue pill back, please!

 

OO-DB-Bashing from the Master

If you think my recent Post is OO-DB-Bashing, then read this Post from Gavin King (founder of Hibernate).

The article is very interesting and also really funny (it seems Gavin is not the greatest fan of Ruby, is he?).

Although it seems Gavin is a bit pissed off … could it be by db4o? And ‘their’ benchmark-site: polepos.org?

Some funny quotes, just to water your mouth:

And Java won't last forever. Really it won't. Heh, that's fine by me, just as long as it's not Ruby that replaces it (I feel safe to say stuff like this, since I am guarded around the clock by an elite team of five hundred crack female IDF commando ninjas armed with the big machine guns out of Alien II)

Well, it is nice for us, but it's not nice for the guy who comes along next! He's one of those shiny-eyed (and slightly scary) Ruby fanatics. Or maybe he's a VB guy (senior citizens matter too). Or maybe its 5000 years from now: Java and Ruby have both vanished (of course, VB is going strong) and a team of archeaologists from Ganymede are trying to piece together something about our forgotten civilization from what's left of your customer database, using the recently released Perl 6.0.

Larry must have some really fucking saucy photos of those CIOs, the sick freaks.

Anyone who knows anything about the software industry knows that benchmarks are the third kind of lie, right after "lies" and "damned lies".

Now, seriously again, the following two quotes concisely formulate the most important reasons for the ongoing dominance of relational databases:

At core, the reason we need mapping technology is that data and data models last longer than applications, longer even than programming languages. Data is shared between many applications in an enterprise…

If you think that relational technology is for persisting the state of your application, you've missed the point. The value of the relational model is that it's democratic. Anyone's favorite programming language can understand sets of tuples of primitive values. Relational databases are an integration technology, not just a persistence technology. And integration is important. That's why we are stuck with them.

Anyway, instead of reading my wannabe-important-quote-patchwork, you should read the original article!

Modern Source-Control

The latest DotNetRocks is about Source-Control and Continuous Integration with Martin Woodward and Eric Sink.

There are some funny statements :

Eric: … most modern source control systems …
Richard: …and the only thing you have got in the ‘non-modern’ is VisualSourceSafe? Anything else?
Eric: I cant think of any other off the top of my head.

… later on:

Martin: CruiseControl has a workaround for missing atomic commits.
Eric: The fact that I know that now diminishes me!

… some more:

Martin: You have forgotten how hard it is to work with SourceSafe, you have been working with Vault for too long!
Eric: That was an intentional forgetting! You are dredging it up!

The main point they are making (besides SourceSafe-bashing) is: A modern source-control system should support a true edit-merge-commit model and atomic commits.

Two Windows-Tools

I was watching the latest Show from DNR TV with Scott Hanselman about debugging ASP.NET applications.

Scott shows two useful tools I have never heard about:

• DebugView: an universal monitor for debug messages: I did not know that debug messages are a concept of the Win32–API. And .NET statemants like Debug.Writeline just wrap this API…
   
• BareTail: A free graphical tail with advanced features.
  

About Ethics

It should be noted that no ethically-trained software engineer would ever consent to write a DestroyBaghdad procedure. Basic professional ethics would instead require him to write a DestroyCity procedure, to which Baghdad could be given as a parameter.

Nathaniel S. Borenstein (quote from here)

Fun with Isolation Levels

Open two sessions (query-windows) to an sql-server.

In the first session execute the following:

drop table t
create table t
(a int primary key, b int ,c int unique)
insert into t values (1,1,1)
insert into t values (2,2,2)
insert into t values (3,3,3)

begin tran
update t set b=20 where a=2
-- switch to the other session

Remember the unique constraint on column c.

Now execute the following in the second session:

select * from t

(it should block…)

Switch back to the first session:

update t set a = 4 where a = 1
update t set a = 0 where a = 3
select * from t
commit tran

So far, so good… nothing unexpected here. But the query in the second session should now also have finished:

Hmm… well, not quite the same as above… and what happened to the unique constraint on column c?

News from the .NET OR-Mapping Front: NHibernate is not sleeping

NHibernate 1.2 has been released today. It can be downloaded here. An overview of the new features can be found here.

The developers are already busy implementing new features for the next relaese:

• NHibernate-Search is a port of Hibernate-Search
• Linq for NHibernate is especially interesting (1, 2, 3, 4, 5)
• Multi Table Entities

News from the .NET OR-Mapping-Front - OO-Database concerns

There is yet another player entering the game of OR-Mapping in the .NET-World: Persistor.NET. Like their competitor Genome they come from Austria.

The product looks like an implementation of an OO-Database that uses SQL-Server as backend.

I have not done a deep investigation of the product, but I am sceptical concerning the usefulness of the product for enterprise applications. The issues I have are the following:

• The goal of the product is to shield the developer completely from persistence-concerns:
• The developer can not define the DB-schema (resp. in their philosophy he does not have to care about the schema).
• The mapper does not work on an existing schema.
• The mapper generates (extends?) the schema on the fly.

The product basically implies, that when we are doing Object-Oriented development, all persistence-details are not a business-concern and therefore should be handled by the infrastructure. I don't agree with this opinion at least on two levels:

1. From an architectural standpoint the persistence details are very much a business concern for business applications:
• There is no logical separation of the Data-Storage-Layer and the Application Layer. There is no decoupling between those two layers: As soon as I have defined my object-structure, the DB-schema is also defined.
  But this logical separation is a crucial requirement for non-trivial business applications:
• The persistent data is almost always the real asset of a company, not the applications that handle the data. The data often lives a lot longer than the applications on top of them. So it is a critical concern how the data is stored, and the schema plays a very important role here. Data-migration is a keyword that comes to mind.
• The persistent data has often to be accessed in different ways and even different applications. Not all consumers of the data can or want to use the same logical (object) model to work with the data. Think about reporting, advanced queries, exports and imports…
2. From a development standpoint it rings my alarm bells, when all persistence details are hidden in a black-box:
• What if the application has to scale? Does the black-box scale as desired? What if not?
• What if there are performance problems?
• What if the black-box does not behave as I expect it?
• What if I want to use the black-box for an exotic use-case? (Example: What happens If I have an existing application with existing data and then I introduce some new subclasses for an existing class? There are several ways to map inheritance in a relational DB, each has pros and cons, a tool cannot make the decision for me! What happens with existing data, when the schema changes because of the new inheritance-hierarchy?

So, I think for the big picture of an enterprise application, persistence and how it is realized is a very important business concern. A lot of effort should be put into that topic, mostly in the early phases of a project (architecture, design). It is also important to fix the persistence-details as early as possible in a project, since a strong fundament is always a good thing.

What I think OR-Mapping as all about, is to shield the implementation of business logic from persistence details. The developer does not have to be concerned about persistence. He should not have to have any knowhow about the persistence-backend. He should be able to work on a higher level of abstraction, with an object-model, that was designed and optimized for the specific application he is developing

Also the implementation of the business logic should be decoupled from the persistence-backend, so that the backend can be changed with minimal effort.

My above concerns are more or less applicable for all OO-Databases. In my opinion OO-Databases are not suited for the core data-storage of business applications. I see the following scenarios for OO-Databases.

• Prototypes that need a data storage
• Systems that do need an embedded data storage, but where the raw data is no business concern. Clients/Users of those systems do not mainly interact with the data in the system, but with the functionality of the system. (Control platforms, embedded systems, standalone desktop applications …)
• Intermediate repositories of business-data for distributed business applications. For instance for disconnected smart-clients. The repositories hold a copy of a subset of the business-data and there is some kind of synchronization with the primary data-storage.

But back to Persistor.NET: I don't see how they place themselves on the market. Do they compete with full blown OR-Mappers like NHibernate, Genome or OpenAccess? I dont think so, according to my concerns above. On the other side there is competition from pure OO-Databases like db4o. All the features of Persistor.NET seem to be standard OO-Database features and the so called ‘Zero Configuration’, can be provided by db4o even better, because it does not rely on a SQL-Server as backend.

By the way: Ted Neward is writing some tutorials about db4o (Part 1, Part 2). In the tutorials he addresses also some general topics of object databases.

Compiling? - No thanks!

Compiling is a waste of time! Jeff Atwood from Coding Horror formulates it like this:

'Death by a thousand 10 second delays.' (DNR 232)

Jet Brains seems to have the same opinion. Their newest pre-relaese of Resharper 3.0 (EAP) has a new feature called 'Solution Wide Error Analysis'. With this feature you basically do not have to compile any more to check for compilation errors! Just forget about Ctrl-Shift-B!
This allows an even clearer separation between developing and building a solution:

• Develop with VisualStudio/ReSharper
• Build with your favorite automated build tools (NAnt, MSBuild, MyGeneration, CodeSmith etc...)

By the way, in the Java World eclipse provides the same comfort with background compiling.