The coming of the asp.net MVC framework had me thinking about the nature of markup and specifically the difference between the way ASP.NET Webforms handles this and the new ASP.NET MVC framework. I have not really used it yet, but when you come across MVC examples there is no doubt that the feel and look reminds you of the classic ASP style of writing markup: a lot of intermixing between markup and code and logic handling inside templates.  Values are inserted with asp.net tags instead of in the code behind. Compared to the use of webform controls this might seem like more cumbersome work. But when I look at the efforts I actually spent at writing the HTML markup it turns out to be only a small part in the total project. For the interface functionality, a lot of my efforts go into making sure the layout and functionality of the website comes across multiple browsers in a uniform manner. I sketched a diagram which will make it more clear:

So actually I like it that the MVC gives you more control over the  generated markup, since it will hopefully decrease my efforts to develop cross-browser compatibility (sigh) and create more lean-and-mean pages. There are already many helper functions available that can conveniently generate often-used html markup, such as internal links (action links) and textboxes. I am sure that we will see more 3rd party controls and utilities that allow you to generate more complex HTML (such as a treeview), but with more fine-grained control over the generated output and still hiding/covering the hard parts such as ensuring cross-browser compatibility.

In your search for achieving excellence in creating software you might have come across one of these statements that 'code is an art' or something in that fashion. Although these statements are very appealing, I believe it not to be true. I will explain why. First let's start with the reasons why a computer programmer (or coder) is considered an artist and it's product (code) art. Writing code is labour intensive and various attempts have been made to automise the coding process through the use of high-level visual languages or application-generator tools. They all fail. Why is this? Because writing code is a complex and, most importantly, creative process. The same reasoning explains why there are still no good pop-song-generating software or fancy automatic movie generating applications. Maybe this will come one day, but this area is still in its very early infancy. Still, the coder can be considered an artist because he or she is creating a product through an undeterministic and creative process where the exact outcome is not clear upfront. Just like musicians or novelists. So, if writing code can be compared to creating music, writing a novel or painting ... then why can the code not be considered an art? Music certainly is art, and so is a well-written novel. The important, but subtle, difference is this:

The value of art is determined by the art itself. Whereas the value of code is not determined by the code itself.

To restate: a painting is perceived beautiful based on the painting itself. Music is valued via the music itself. In contrast, a software product is not valued on the code itself, but on what it does. No user really cares whether you have an elegent recursive call, or a three-tier architecture. Software should work. We should never forget this. Surely, your colleagues may be impressed by the sheer elegance of your code, but your users certainly won't be! The goal of a musician and its audience are aligned: to create beautiful music. The goal of a coder and its audience is not, there is a clear mismatch and that makes it more difficult to create good software. Most programmers out there, if not all, enjoy writing beautiful and elegant code. Which is a good thing because elegant code tends to have other convenient properties such as easy maintenance, reusability, self-documenting, etc. But let's not forget that this is not the primary goal our users have; just create software that works.

One of the most overlooked aspects in any software project is the end-user (e.u.) documentation. Can you recall how many (web)applications you have encountered that had proper e.u. documentation in it? I for one cannot, even though the (web)applications are getting more sophisticated and more complex every day. And to be honest, the software projects I create often lack proper documentation as well. So why is this the case? There are a number of reasons that I can think of:

• Typically developers don't like writing end-user documentation. It is just way cooler to create new functionality than write about functionality you have already written.
• Developers are not the right people to do it anyway, you need a customer-perspective. That is where the role of a technical writer comes in.
• E.u. documentation is often written when a product is already finished. When the development of a software product is already over-time and over-budget it is extra hard to convince the customer or projectmanager to put even more time and money in it to create proper documentation.
• The available tooling is not sufficient or well-known enough

Just some pitfalls here. But most people do agree that end-user documentation is important. For the acceptance of any new system it is a vital part.

How can we adress these problems? On my quest for the right tooling I have not found many good products. There are soms tools that let you generate documentation help files, or even create tutorial videos. But they are by their nature very loosely coupled with the actual software product and development process.

As part of my education I have enrolled into a course where I will be able to explore this problem more in depth, and provide a solution for it. My idea is to create a usable tool that can be pragmatic used in an (agile) development process and establish the link between the developer and technical writer. Furthermore, I want to be able to make e.u. documentation part of the build process and also be able to break a build if the documentation is not correct. In the coming weeks I will think hard about how to create this philosophy into a concrete product. I will keep you updated!

Ah, so finally Microsoft has also taken the road towards the Model-View-Controller pattern. Scott Guthrie talks about it in his weblog. It was a matter of time ofcourse after the self-proclaimed success of Ruby-On-Rails and the popularity of unit testing. One of the most important motivations that Scott mentions in his articles are 'seperation of concerns' and 'designed for testability'. Let's take a look at these two:

Seperation of concerns. The tradition ASP.NET model, using WebForms, had already a form of seperation. Namely between the HTML template (.aspx) and the code-behind (.vb or .cs or which language you have chosen). However, often you still end up inserting a lot of UI logic and business logic in the code-behind. Mainly because it is just so much more convenient to have all your UI logic in one place, instead in both the .aspx and code-behind file. So it boils down to this; no, the .aspx and .cs are not really seperated. In fact, I often just see the .aspx as a more convenient way of declaring controls, instead of programmatically adding them in the code-behind. In the last couple of years I have barely done anything more in the .aspx except for writing the HTML controls. That is right, I never use the designer. It is a huge frustration to me and I feel I have no control, whatsoever. The development time you win by using build-in grid wizards and such is often minimal compared to the time you lose to get the html output correct in the end.

Seperation of concerns is a good thing. Because most importantly, it eases your mind since you only have to focus on one aspect at the time. The code tends to be more cohesive, more readible and better understandable. Besides that, you automatically gets a better reusability of the components you write.

Designed for testability. This is still a big thing not well done in development nowadays. It is just very hard to test the UI. That is exactly where the user comes in and where things get fuzzy. Difficult to automate and therefore difficult and time-extensive to test. The basic idea to improve testability is to make your UI as dumb as possible. Also known as a passive view. The layer that renders your HTML should be thin-sliced over and over again, untill it does nothing more than just rendering some tags around provided text. The idea is that you might have errors in this thin layer, but you minimize the change of this because most of your code will be in another testable layer. UI testing is difficult, but this might just be another step towards software of better quality.

When I read about the MVC framework in ASP.NET I did not see a lot of really cutting-edge features. Actually, I have already built most of these features into ASP.NET right now. I build my .aspx as passive views. I design my controller classes in another library. Which makes use of the object-oriented model, which is generated by an O/R mapper. I have been working with this design for the last year and it has been very satisfactory. I notice that I get less erors in my applications, not only because of the increased testability, but also because of a more seperated approach in the design which provides me a good overview and makes me feel in control.

The only thing thas been bothering me lately is the asp.net WebForms model. It is just a pain in the ass to create a lean and mean performant application with this model. Especially the viewstates put a huge burden on this. I think a lot of asp.net developers experience this, because it just is too easy to drop some controls, enable viewstate and do continuously postbacks. But it just adds too much overhead. That is why I am looking forward to the release of this lightweight framework. Not because it is very revolutionary, or that you can do things with it which are not possible today, but to get rid of all this extra drag you get with the WebForms model. The time has come to take back control!

A small wave has hit the developer community this weekend about a clash between two lead developers: Chris Wilson of Microsoft's IE team and and Brendan Eich of the Mozilla foundation. The dispute is about the acceptance of ECMAScript 4; the proposed successor of Javascript. Wilson wrote public doubts about this standard, which let Eich to write a public letter in which Microsoft is being blamed for being reluctant and passive in the development of ECMA4. The debate is interesting, but we have to keep in mind that these are two individuals fighting over this dispute; there are no official positions here. However, I want to leave this aside (I know too little about the dispute as well to make sound arguments), and focus on how I perceive the future of client-side scripting.

As a programmer, I have always been a little bit relucant in learning Javascript. I get the same feeling when I work with Visual Basic. There is something... uneasy about it. The last couple of years I have mainly been programming in modern OO languages such as C++, Java and C#. A procedural language such as Javascript forces me to make such a leap in my approach and thinking that I feel being held back by the language. But I have the same with C. So, clearly it is not the fault of Javascript. In fact, I think Javascript is a good language in that it is easy to read because of a nice syntax, it has good scripting properties such as dynamic typing and it offers a lot of expression.

The question raises.. why is there the need for a 'new' javascript? The main force behind it, is to make the language more 'professional'. Make it more object-oriented, advanced exception handling, templates, etc. Indeed, these are things that are very important for any application of reasonable size. But is it important for Javascript? I have never used Javascript outside the webbrowser. In fact, I think most of the Javascript I use is either developed by a 3rd party or generated on-the-fly. Ajax? I use convenient libraries that abstract me away from the low-level javascript.

An article bij Joel Spolsky on the newSDK made me think about the role of Javascript nowadays. It is a great thing that almost all browsers support Javascript. Could you imagine all browsers supporting a language like, say, C++? Most C++ compilers don't even support the langague the full 100%. I am sure that the software engineers at Mozilla do not want to spend their time supporting a huge and complex language like that. The reason Javascript is so widely supported and popular is for the same reason the C language is still widespread today. It is the biggest denominator across languages, OS-es and browsers. If you write something in Javascript, there is a very good change it will be supported by the platform a client uses. The same is true for the C language, it is extremely powerfull because of the universal support. Even if the C language in itself can be considered obsolete by modern standards.

I believe that we should keep an easy, intuitive, flexible and powerfull language that can be executed for all browsers on all platforms, including new technologies such as PDA's and small mobile browsers. If you want higher-level constructs, you can use high-lever languages and 'compile' them down to javascript. For example, I could specify application logic in C#, which would then be outputted as Javascript in the final output. We can see the same in many smaller domain specific languages which transform a higher-level program into a c-program, which can then be compiled almost everywhere.

I do not believe that adding higher-level constructs into a language such as Javascript will make developers leave their current language and switch to Javascript. Surely, it would be more convenient if you were actually creating client-side javascript by hand. But in my experience, that doesn't happen a lot. But it would make it much harder for current browsers and future browsers to provide a (correct) implementation. You do not want a browser to implement a virtual machine just to be able to run an advanced javascript.

I recently wrote an article about the concept and implementation of something which I call Role-Based Security in a Hierarchical Environment . It is a form of RBAC (Role-based access control). However, it also takes in account a context object (on which item is my function performing). And role permissions cascade down the context-tree. So having a permission on a certain context object means you also have permission for all underlying context objects (or not, depending on the role parameters). A typical use of this kind of security framework is in a traditional filesystem like NTFS.

In the article I outline the basic concepts behind it and an implementation in SQL Server 2005. The basis for this article is an implementation done in a recent production-ready webapplication. And it turned out to be a very effective way to deal with both partition issues, such as multiple clients in a single database. And security issues: making sure the users do not perform actions they are not allowed to do.

My intention is to write more articles like these in the future, thereby giving a little bit back to the development community of which I have taken so much already.

Links:

PDF article

Article on CodeProject