@QCon SF, I attended a presentation of Erik Meijer in which he talked about research projects he is involved in, including the Volta project. He talked about an interesting problem that is ignored when we talk about Ajax application and especially when we talk about solutions like GWT that make you feel home while programming for the web. In such an experience, and before splitting your application and deploying it on the web, you feel quite secured. Anyway, often, it is not so important to look for securing inner computer guts communication when there is no network involved. Evil shows up when it is time to go live, to the clouds. There you are not communicating through inner channels but rather through public Internet network.

Now, "evil" seems like exaggerating. But with rich ajaxified web applications, there is a part of the business logic that is done at the client side. If you are designing a "Web 2.0" application you have indeed to do some work at the client side to keep your application responsive. This gives even more chance and time for malware to play and mess around. The page is not anymore returned by the server but rather dynamically constructed using javascript after some asynchronous web calls to the server. User’s session got longer, giving more opportunities for evil (not thinking of invocation of some javascript that is supposed to be returned from the server!).

Erik, while talking about Volta project, seemed very concerned about this security hole that everyone ignored when talking about splitting an application into two parts or about RIA applications. During this interesting presentation, he suggested a solution to this problem: a low level channel that transmits user’s key interactions to the server in a secured way to be replayed to verify the request sent through http. This mechanism is introduced through a plugin or so. This suggestion triggered negative reaction in the audience, people seemed not to like the idea for several reasons. Some people thought that it is bad for confidentiality reasons. I guess the server anyway knows about what the user does through the http requests, so I guess there is no harm in this channel.

But what really drew my attention is that a lot of people thought it is a bad idea because it "breaks web rules", or "breaks the web’s architecture", or "introduces a whole new concept that people will certainly reject". Well here, I feel to clear out some points.

Firstly, this is Microsoft that is in act. Back when Microsoft introduced Xml request into their browser for outlook’s web interface, everyone felt it like a bad idea and that they are breaking the rules. Later on, that became a standard and an essential part of the Web 2.0 enabler that is called AJAX. Examples like this are numerous but this one is sufficient.

Secondly, as the title of this post says, innovations do not come often at our knowledge or expectation level. I mean, who could ever imagine that the Web will have the shape it has today, or that it will even exist.

Last but not least, Erik and his team are trying to find a solution to an ignored unsolved, yet very dangerous, problem. This solution, if it works, can save us from a lot of malware, spam and other kinds of evil on the web. With Microsoft behind it, I guess people will have no problem adopting the solution when it is integrated in the next browser, the most used browser for far. And, think about it, a lot of big companies solutions became standards. Maybe that is Microsoft’s way back to the WWWeb!

Having worked with several Object-Relational mapping frameworks in the last few years, I got to a point where I couldn’t justify their complexity in my project. We often talk about the mismatch between the database and the object worlds, and that is where ORMs are often stated and referenced for “bridging the gap”!

Well I prefer to call it lifting the gap, or highering the gap, to have it now between DAOs and the rest of the code than having it between database and code.But I wouldn’t call this in any way reducing the gap.

First thing to mention here, is that data structures are not evil. We often deal with XML data structure but we absolutely refuse to deal with relational data structures. The problem might be related to time, XML came with a whole arsenal of managed APIs that represent its model in a way that makes it more comfortable for you to manipulate these documents. All together with transformation APIs that made it a lot easier to fill your object model out of an XML. Relational data structure on the other hand did not have the luxury of standard APIs and representation models in mainstream languages, and that made dealing with a database request result so arbitrary (Datasets existed in .Net but they have been cursed heavily and has been forced out of the cool toolbox, do not know yet why!) . 

In some way, I guess that the “mismatch” between Relational data structures and objects exists much similarly between XML and objects, however we didn’t think for so long of a doing a mapping between XML and object OXM? (no we are starting to do so, writing some XML to map XML to objects!).

With the experience I had with mapping technologies, I can say that they do not solve the problem for me. They merely add yet another useless level of abstraction where your domain types look nothing like relational data structures, but yet nothing like your target domain model! They have gone a half way, and now its your turn to poison your application with a lot of absurd ORM code trying to stretch this bridge to reduce the gap…

Geeks love talking about intrusivty of an ORMs and compare level of intrusivty in different terms. Intrusivty is much more than the lack of an interface or methods to implement in your domain objects. I guess I am ok to deal with that kind of intrusivity. However all ORMs I tried do not give me the opportunity to express my domain model in the way I would like to. I have to deal with notions of Lazy Loading, Attached/Detached entities, Entity sets, ids, back fields and a lot of other things that I don’t want to appear in my model and that make the resulting code so ugly and complex that I don’t wish to visit soon.

As Bob Martin said before, we are missing the opportunity to do oop, I would enforce and say we are missing the opportunity to model at all. And I guess we have gone too far with ORMs and it is time to go back to the basics, in the same way we have done after the EJB great abstraction.

It is very contradictory, while we are so excited about DSLs and the goodness they can potentially bring to enterprise development that results in a declarative semanticful style of programming, we can’t help but to engage all of our means in trying to bury SQL (and effective, semanticful, declarative powerful domain specific language) behind a dumb API to “abstract database access”! I guess we got to chose one strategy, either we keep SQL and we  keep marketing DSLs or we hope for a new advanced GPL compiler that will hide all of this in the same way modern languages did with garbage collection, concurrency and synchronization.

Since I am not yet a compiler writer, and I aint got around an effective way of integrating database in mainstream languages (there is actually a very productive in memory database on Haskell that worth trying), I decide to keep the DSL, and to work with them without the need to hide them, but rather to get a better tooling to help converting between difference data structures.

I guess you’ve guessed it by now. For me LinQ is the mid-term solution for the data structure mismatch. No not LinQ to sql, nor Ado.Net entities (they are helpful and we might use them but lets focus on the solution). LinQ is a very productive tool that halps effectively transform anything to anything in few lines of code. I mean that I can still use powerful SQL to get data effeciently and then convert them with one line of LinQ into the destination data structure. No abstraction leak, less complexity: Use the right tool where it applies.

So what I would actually do is to use a framework that will execute my SQL or SQL like query on the database and get me the records in much the same way they are in the database,Much in the same way Active Record gets you records as they are in the database. No useless efforts from the framework to bend the data to make it look untruthfully like the destination model.  I guess I know better my domain model, and with this better tooling I can get it done with no problem.

In my trip through Haskell programming I keep discovering how clean and enjoyable the language is. By the end I am someone that loves doing abstractions and I guess I’ve found my world.

I discussed with some colleagues lately how a programming language creates a whole culture around it. This culture inherits from language properties and shapes the language programming style.

Take for example Java; there are a lot of different ways to program in java. The java syntax does not force you to program OOP. It is just more convenient to do so. Same thing goes with other programming languages. However it is not only about paradigm, it is really about a whole mindset.

While programming a web site with Haskell, I was searching for a function that parses a string to return me an int. As I’ve been for a long time a C#/Java programmer I expected to find a simple function like what I used to use in these language. A function that simply takes a string and produces and int. After a fair search I didn’t find such a “simple” function. I’ve rather found a function with slightly more complicated/richer signature (type). This function takes a string and returns a list of int-string pairs. This got me thinking, there should be a reason for not offering the simple function I was searching for…

I quickly started understanding why libraries implementers chose to offer this function with this signature and I did so simply by imagining its use. Imagine that I pass a string that is not the expected type (in our case int) to this reads (stands for read string) function, what would happen? Well in the simple version of C# and Java, the parsing function well throw an exception when passed a string that can not be parsed. In some way, the signature of the function promises me to get always the expected type (in our case an int) as a return of using it but it actually lies! Throwing an unexpected exception comes as a surprise as the signature (the function type) looked extremely kind but behaved irresponsibly unexpectedly when I trusted it. But what about the Haskell version?

Well the type of the Haskell function tells me “I will try to parse the string passed, and each time I find a fit with your expected type I will return a pair with the value in the expected type and a remaining string that represents what remains”. So here the function type tells me that it will try to parse and that it will might face several possibilities. There is no lie here, no magic, no false promise, parsing strings can produce several possibilities depending on the parsing method, and that what the function tells me.

I like the no surprise / safe  programming culture in Haskell. I guess there are a lot of lessons to be learnt from this style of programming.

PS: Some might call this safe style “defensive programming” to make it look rigid, I guess there is no point in calling it so, and I would rather call it communicative programming, no surprise programming, or intention revealing programming. I like DbC!