Thinking Inside a Bigger Box

Inspired by the “Hi, I’m a Mac” ads of Apple, Gregg Pollack and Jason Seifer has made these cute Ruby-on-Rails ads (featuring Ruby-on-Rails versus Java and Ruby-on-Rails versus PHP):

Click here to view on YouTube

I have been watching videos from the Technology, Education and Design conference (TED) all afternoon. One particularly fascinating talk was Barry Schwartz talking about The Paradox of Choice. I find an almost Buddhist-like understanding of the problem of humanity in the modern world in his talk. But it was the closing words that fascinated me the most: “If you shatter the fishbowl, so that everything is possible, you don’t have freedom, you have paralysis.”

CIO JP Rangaswami at investment bank Dresder Kleinwort Wasserstein talks about why he considers open source a corporate IT asset. In this talk, Rangaswami describes how DrKW wanted to create an internal incubator environment in order to combat skill attrition in the late 90s. In the course of doing this, they acquired OpenAdaptor and discovered almost accidentally benefits of the open source development model.

Read the rest of this entry »

Sverre Huseby examines some security issues with Spring-MVC. As it turns out, the Spring JSP form-taglib provide no HTML-escaping by default, making it very easy to get Cross-Site Scripting vulnerabilities included in the code. The article comes complete with a standalone application that illustrates the problem.

Ron Jeffries reminds us: “… hours aren’t burndown. Accomplishments are. A team that focuses on hours isn’t focusing on getting things done.[…] The point […] is getting backlog items done, not getting tasks done” This really cannot be said too often!

Via Jason Yip

This phase has been stuck in my head lately: Colorless green ideas sleep furiously. It was first used by the linguist Noam Chomsky as an example of a sentence that is grammatically correct, yet has no meaning.

Interestingly, in 1985 this was taken up as a challenge. The result was a literary competition to write a short text that gives the sentence meaning. Before you continue reading, think for a while about how the sentence could have meaning.

Read the rest of this entry »

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.

The Device Patented Process Indicating Apparatus. Available soon. We hope.

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:

public interface GenericDao <T, PK extends Serializable> {

    /** Persist the newInstance object into database */
    PK create(T newInstance);

    /** Retrieve an object that was previously persisted to the database using
     *   the indicated id as primary key
     */
    T read(PK id);

    /** Save changes made to a persistent object.  */
    void update(T transientObject);

    /** Remove an object from persistent storage in the database */
    void delete(T persistentObject);
}

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:

public interface PersonDao extends GenericDao {
    List<Person> findByName(String name);
}

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.

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:

• The method where people talk to each other and trust each other and build things incrementally and… (I’ll probably blog about this at some later time)
• The Goals, Questions, and Metrics of User Stories
• One adopted improvement per person per week
• What’s the matter with that person: On reacting sensibly to stressful situations (much longer than average)

It’s a blog well worth subscribing to.