1. Riding the Wave

    I recently wrapped up a group project for my degree that consisted of working together as two groups. The task was to develop an application that consists of a service layer and the UI layer. The service layer team would handle the database and storage concerns and the user interface team would consume the service and allow the end user to interact with the data through a browser.

    Typically communication for a class project would consist of face-to-face meetings and email. Given that this was a large group (7 people total) and that most members were not on campus most of the time I suggest that we use google wave (http://wave.google.com/) as the communication platform. I had been eager to try this tool out for a while and this seemed like the perfect opportunity. 

    Overall I’d say that I was very impressed with the concept of the wave. Instead of the traditional email or instant message flow Google Wave allows you to inject a message and begin a new thread of discussion at any point in a posting. This proved especially useful as we were discussing the application design. Questions from the design document can be added right next to the point of concern making the whole discussion much easier to follow. 

    This functionality added to the idea that there is one place for a discussion that any team member can jump on and get up to date. Two features really help here: first, there is an inbox type function where a user can step through the newest posts that they haven’t seen yet. Second, there is a replay function that allows a user to see every comment as it was added so you can get a feel for how the conversation evolved over time.

    There were a couple of let downs. First the notification feature. I told Google wave to notify me of changes every few hours but I never seemed to get them as expected and this meant that I went several days and missed out on some conversations had a occurred. The second let down was the limited supported browsers. I’m guessing this is due to Wave being built on HTML5. it means that there is no support for IE, or more importantly for mobile platforms. Safari on the iPhone or the iPad is not supported even though it is support on Safari on the Mac. Google gives you a nice warning when using an unsupported platform but still, as I am finding myself increasing reliant on these mobile platforms, it seems slightly archaic to have not even read only access to the conversation when away from my desktop.

    In spite of the above issues I would still certainly recommend this tool to others (and use it again myself) when looking for a place to have a conversation as a dispersed group.

  2. Database denormalization and Digg →

    Interesting article on Digg and the “No-SQL” movement. My recent foray into CouchDB is my start at looking at alternatives to RDBMS.

  3. Writing a new MVC application: What to use for persistence?

    So I’m writing a new personal “for fun” application and I really can’t decide on what to use for the persistence layer. I on the one hand I love NHibernate (I can’t get enough of Oren Eini’s blog on the matter http://ayende.com/Blog/), personally I don’t mind the Entity Framework from MS, you have to give a little love but it does work. I’ve also been reading with much interest about CouchDB which I really want to take for a spin and would really fit with the nature of the application I’m writing.

    There are a couple of libraries that might help grease the wheels between CouchDB and .net, Företagsplatsen has a nice library called Divan which offers a pretty good .net wrapper around the CouchDB API. SineSignal has created a library called Ottoman which is in the way early stages (pre-alpha) but looks really promising.

    As a side note Ayende has created his own document database called DivanDB (not to be confused with the Divan CouchDB wrapper mentioned above) which would be a .net / LINQ-ified database comparable to CouchDB. I’m not sure where he’s going with it so I don’t think I would use it for this project

    As a result I am going to hold off on this decision until much later. For now I will write persistence using the Repository model and implement a HashTable to store my development data, I see it as a great opportunity to really separate the model / persistence concerns.

    I can see one impact that this indecision will have and that is the developing the Model. Should I choose to go with NHibernate then I need to make all properties virtual. The Entity Framework required specific classes for related entities. CouchDB seems like it would work best with a superclass that implements a guid ID (Primary Key equivalent) and string Revision number. To handle this I will create a common superclass that may have nothing declared for right now and make my properties virtual anyway. Should I choose to implement Entity Framework I will have to go back and redefine the related entities.

    Which persistence layer do you prefer?

  4. C# 3.0 inline class instantiation and MS Enterprise Library Validation issue

    This throws an error:

    var entity = new Entity() { Name = name, TokenValue = tokenValue };
    ValidationResults r = Validation.Validate(entity);

    This works:

    var entity = new Entity();
    entity.Name = name;
    entity.TokenValue = tokenValue;
    ValidationResults r = Validation.Validate(entity);

    My understanding of C# 3.0 is that the two above statements are doing the exact same thing, but I guess they are not. I wonder where the issues lies. Any ideas?