Category Archives: Links

Ralph Johnson: RDBMS as a pattern

Ralph Johnson discusses the use of Relational Database Management Systems (RDBMS)

If you don’t have good architects, big systems will end up as big balls of mud. A lot of companies live with it, but there are certainly big payoffs if you can avoid it. The main problem is that there aren’t enough good architects to go around. One of the advantage of a RDBMS is that it is fairly easy to understand so below average programmers can still get systems running. Below average programmers will not build the best architectures, though. So, the fact that RDBMs lead to big balls of mud is actually a sign of an advantage. You can use a RDBMS when you have good architects and when you don’t. You’ll end up with completely different systems, but that is because of the quality of your architects, not because of the technology you use.

He discusses RDBMS mostly in relationship with OODBMS and things like Prevaylor. I am looking forward to seeing more on this from Ralph, as it in many ways ties in to my own thoughts on use of databases.

Posted in Links, Software Development | Leave a comment

developerWork: Don’t Repeat the DAO

I am happy to see others express positive opinions about universal DAO interfaces in Java. Per Mellqvist writes in developerWorks: “Don’t Repeat the DAO” about creating a GenericDao interface:

With the exception that we’re not using generics (instead, we cast… sigh), we’ve been using the same approach successfully for two years. We use the concept of Specification objects for search methods. Per Mellqvist prefers an approach where he extends the interface with finders:

He then imprements a FinderIntroductionInterceptor to execute the query. This is an interesting approach (although I personally find it very XML-heavy. XML-heavy is bad)

I would like to see this approach extended with test classes to test the correctness of the GenericDAO implementation, similarly to my article on Unit testing Hibernate mappings. Roughly I’d like to:

  • create and read an object and check that the objects is equal to the retrieved object
  • create, update and read an object and check that the saved object is equal to the retrieved object
  • create, delete and read and check that retrive returns null (?)
  • create a set of objects, and check that find returns the correct subset

Most of this can be done easily, but there are two issues: 1. The first level cache. “reads” will not actuall hit the underlying datasource, so the tests will trivially pass. 2. Handling test datasets for find-tests can be pretty hard to do in an elegant way.

Posted in Java, Links | Leave a comment

Best of Jason Yip

One of the blogs I enjoy reading is that of Jason Yip: You’d think with all my vide game experience that I’d be more prepared for this (excellent title!). He usually writes short and sweet posts that gets a point across in just a few sentences. Here are a few of my favorites:

It’s a blog well worth subscribing to.

Posted in Links | Leave a comment

To autowire or not to autowire

Jason Zhicheng Li has written a blog article about Spring configuration. It is called the 12 Best Practices for Spring configuration. Best practice #1 was “don’t use autowiring*. That got me thinking:

I feel very ambivalent about autowiring. Initially, I thought it sounded like a great idea because it reduced clutter, but then people like Jason convinced me that it was not. The more I think about it, the more usure I am.

So, what are we afraid of when it comes to autowiring? Documenation is one thing, definately. In my experience, I don’t use the configuration much for documentation anyway. And we are used to automagic stuff happening anyway, so autowiring won’t be too different. Nothing stops us from explicit wiring in the cases where autowire would be too “undocumented”.

So what can go wrong? Either something gets shouldn’t be, or something doesn’t gets set which should. Autowire ensures nonambiguity, so if something gets set its always what should’ve been set.

As I can understand the issue, using autowire to, say, let all DAOs use the same DataSource seems much easier to manage than explicit wiring: If a class has setDataSource, it has the standard datasource. What could be easier?

I cannot see any realistic way where the first scenario would actually happen. If you have a setter on a bean, having it called can hardly be a surprise to you! Why else would you have it! If it wasn’t needed, it will not cause any harm, and if it was, it would be the right one.

Nor is there any great risk in a property being unset. If a property is critical, we already know how to deal with it: Dependency check or implementing InitializingBean.

So: We all have this fear of autowiring, but I have yet to understand a rational reason not to use it. (And yet, I don’t use autowiring either)

Can someone please explain WHY autowiring is bad without just waving their hands around? What bad things can happen if you autowire? Has anyone experienced any pains after autowiring?

This article has been posted as a comment to Jason’s blog

Posted in Links, Technology | Leave a comment

Architecture Astronauts

Joel Spolsky had a blog entry seems eerily familiar: The Architecture Astronauts (in outer space)

I’m starting to see a new round of pure architecture astronautics: meaningless stringing-together of new economy buzzwords in an attempt to sound erudite.

I’ve seen the type, and I’m glad to say that we haven’t got any of those around. A bad architect can cause enormous damage.

Posted in Links, SOA, Software Development | Leave a comment

welcome spammers

welcome spammers Dear Spam Robot: I don’t have much time to read emails, and I especially don’t have much time to read unsolicited commercial emails. But I have decided to make an exception. If you would like to send me unsolicited commercial emails, then I agree to read them on the condition that you promise to pay me $500, and subject to the additional conditions mentioned below. You can accept this offer by sending unsolicited commercial email to me at In accepting this offer, you also agree (1) to be subject to the laws of California for the purpose of enforcing our contract, (2) to pay any costs, including attorney fees, incurred in enforcing our contract, (3) to pay your obligation under this agreement within 10 days of sending the email, by mailing a check to me at the address referenced in the Contact section of this site, and (4) to accept service and costs associated with any bill collector that I hire to help collect obligations owed me under this contract. Good luck with your business.


Posted in Links, Technology | Comments Off