Thursday, April 28, 2011

The kind of idiot short-sighted developer in Microsoft, who came up with the idea of smart USB/SD cards reading has probably never owned a digital camera. Or never thought of getting one. Or never thought period.
Nothing ever has come out good after using this functionality – I have already had to reformat two SD cards (including one right in the middle of Florence which spoiled otherwise jolly supper) and just screwed up third one. Thank god, the Microsoft oversmarts haven’t decided to “help” me with auto-reformatting – it’s only logical.

Sunday, April 24, 2011

RavenDb is a relatively new (maybe subjective - I’ve heard of it just few month ago) document database built on .NET and for .NET.

It is an extraordinary little (course from user’s point of view) thing which allows to start writing application without extensive database preparation and schema manipulations. It clicks perfectly with MVC, although I am still to discover a similarly elegant technique for Workflow Foundation. Raven Db recognizes property named “Id” (exactly capital “i” and lowercase “d”) as an entity identifier and has some optimization around it, so it is wise to make this field the entity’s identity field. It is even more wise to make it string and assign the value manually while inserting, e.g. using Guid, otherwise you will end up with engine-generated keys like “movies/323” which are deadly for MVC or REST services.
The only problem I’ve noticed so far (and the documentation is scarce on this) – decorating Raven-served documents as a WCF service contracts. I found that some of my workflow variables, which I store in DB, often require to be service contracts.

It worked perfectly fine in the code until all the sudden I’ve started receiving errors when trying to retrieve the entity from the DB: Newtonsoft.Json.JsonSerializationException: Newtonsoft.Json.JsonSerializationException: Required property 'Id' not found in JSON. With decoration removed, the entity retrieval worked perfectly well. What was strange is that in both cases the document stored looked exactly the same (Raven Db installation includes very helpful Management Studio executed in Silverlight):
The error seemed to only affect “Id” property, which is “invisible”. Obviously something was interfering with JSON deserialization of the object. The Raven API provides great deal of serialization customization but I decided to find laziest easier way to fix the problem.
As it turned out the DataMember attribute was the one to blame. I believe that it is more likely to do with Microsoft’s oversight in DataMember implementation (despite being a member of Serialization namespace it is not being recognized as Serializable) while RavenDb proved to have a perfect reason behind most peculiar decisions. The solution is to add an additional JsonProperty attribute to the troubled field:

Monday, April 18, 2011

I believe that learning is only effective when it is forced on you by a real need. So far the most efficient learning experience I remember was stimulated by a lunch-and-learn session, where I was supposed to deliver a topic I had no previous knowledge on. The session was scheduled to happen a week after I was notified about it, so since then I am expert in aware of existence of Design Patterns.
Armed with that experience I decided to use technologies, new to me, in my next project (thankfully, relatively small). I am Web Form/SQL Server/Subversion junky so the following was brought in to widen my horizons: Workflow Foundation 4.0 as a back-end engine, MVC 3 Razor as a front-end and Raven DB as a database storage. To cap it up the project will be stored in Mercurial SCR. The only treat I’ve allowed myself is the usage of the excellent (as usual) Windows shell extension – TortoiseHg.
A couple of days into the project it works as expected – deadline is approaching, I am panicking. Hopefully, the sweet fruits of knowledge will follow…