Peter Van Dijck asks:

I’ve only worked twice with companies using .NET for web interfaces, and in both cases the UI was a disaster and the usability problems guaranteed lots of consulting hours.. Why is that? Or was that a fluke? (2 cases is hardly proof of anything) I know it’s possible to make usable and elegant web UI with any technology, but does .NET somehow encourage bad UI?

This is a great question and in my opinion – the answer is yes. (Assuming that Peter really means WebForms.)  

This is demonstrated in so many small ways by framework defaults which are totally brain dead (__doPostBack anyone?). Rather than lead dev’s into the pit of success – the framework leads devs to the spiky elephant trap of death. 

 
What’s that – an example? How about the <customErrors> defaults. When an error occurs during processing an ASP.NET request – the default behavior of a new web.config is to redirect the user to another URL. This is what a new web.config looks like in VS2k5. 

        <customErrors mode=”RemoteOnly” defaultRedirect=”GenericErrorPage.htm”>

            <error statusCode=”403″ redirect=”NoAccess.htm” />

            <error statusCode=”404″ redirect=”FileNotFound.htm” />

        </customErrors>

The URL in the browsers address bar is: 

http://devlicio.us/error.htm?aspxerrorpath=/themes/blogs/default/post.aspx

Another example? Linkbutton? Anyone who’s tried to open a link in a new tab/window and got a blank window with a URL like: javascript:__doPostBack(‘ctl00$Masthead1$LocaleManagement$ctl00$ctl05′,”) – knows the pain I’m talking about. 

Go on – right now – go try and open a MSDN library page in different language in a new tab. (It’s the little menu up the top right where it says (e.g.): United States – English). 

In my apps – I fix this by disabling customErrors and writing new error handling code which both maintains the url and returns the correct HTTP statuses – but this is code which I should not have to write. This is code which all web servers/apps need to implement correctly – it should be automatic. We shouldn’t have to write custom code to get a HTTP/404 returned when an app encounters a missing file!

(This is the third part in a series – you should probably read part one and two first.)

Today I’ll present a sanitised copy of my deployment script. I’ve based the design of deploy.cmd on Capistrano¹ . The script is nicknamed “Crappystrano”. Here’s the output (pretty htmlized source is here):

>deploy.cmd

Crappystrano – the shit script which (sort of) deploys stuff

deploy.cmd staging|live [branchpath]

Here’s breakdown of the steps² – skipping some error checking³. :

1. Do we have the required dependencies⁴ on the path? If we don’t copy them to the path if they’re just 1 exe – otherwise exit with an error.
2. Check the command line parameters. We must have the environment we’re releasing to? Are we releasing from the trunk or from a SVN branch?
3. Construct a release time stamp. This is YYYYMMDDHHMMSSMS.
4. Perform a “svn export” from the trunk/branch to %tmp%\staging|live%timestamp%. [E]
5. Use msbuild to build the solution. [E]
6. Rearrange the folder structure so we only get the artefacts we need in the release package.
7. Zip up the release package using the environment name + time stamp.
8. move the release package back to the root directory of the project and delete the export from %tmp%.
9. Make a SVN tag (svn copy trunk/branch /tags/environment-timestamp).

I’ve uploaded a zip file with the script and folder structure + a little readme. This is not the best way of doing things – it’s just a very lightweight way. Comments, questions, feedback etc… are gratefully received.

1. http://www.capify.org/ – I know some people are going to say – just use Capistrano. There are two reasons for me not to: 1. I’m the only person in my team familiar with Ruby. 2. Even if you argue that they don’t need to understand ruby to run a cap deployment recipe – they still have to have it installed. It’s just yet another dependency which I’m not willing to take currently.
2. This is all simplified as the actual script supports a SaaS product which has multiple instances – one per client
3. noted with [E]
4. gnu zip.exe, svn

For me – a successful deployment has a number of components:

• Build
  1. Code successfully builds 
  2. tests pass.
• Versioning
  1. I know exactly which revision was deployed from subversion.
  2. I know what environment it was deployed to.
• Deployment Safety

  1. On my server I have the ability to rollback a deployment.

• Support
  1. I can compare the current deployed version to previous releases when I need to do post-deployment production debugging.

To achieve this I use a number of conventions which I’ve borrowed and adapted from Capistrano.

My Subversion repository is structured so that every release get’s it’s own tag – including the environment which the release was made to¹ :

The tags are kind of self explanatory – the format is:

[environment]-YYYYMMDDHHMMSSMS 

This is much easier than trying to remember that version 2.54.33.2 was released on Tuesday to client X.

In a deployment environment (staging or live) – each release is unpacked into it’s own folder.²

After a deployment package has been unpacked on the server there will be a new folder for the release. Making a release active involves a couple of (currently) non-automated steps:

1. Updating the database connection details (this is a matter of copying a database.config into the release folder³ ). 
2. running a DB upgrade
3. changing the webroot in IIS

People who are paying attention will notice that this process is not necessarily atomic. Depending on the DB changes – it’s possible that the old/new code cannot run on the same database – in this case I drop a app_offline.htm – into the previous release folder before I run the DB upgrade.

1. The folders in /tags are client names. This is because our SaaS app is released per-client – not multi tenanted. i.e. Each client is running a different version at any given time – and is upgraded to the latest trunk as necessary.
2. The occluded bits are the client name – this is for convenience in managing release packages (zip files) as the server has a folder for each client
3. this is the only thing on the server which is not versioned in subversion. My web.config has the following: <connectionStrings configSource=”database.config”/> – this file just contains the connection details for the application.

I’m reluctant to get involved in this – but I feel like there’s another side to this story which is worth considering.

Since it was first presented at altnetconf – the decision to require users¹ to have to specify which methods on controllers are available to be routed to ([ControllerAction]) and which view (RenderView()) to render has come in for a lot of criticism.

Lots of the brightest and best minds in the .net world are screaming about this in various forums. Claiming that it violates:

• the DRY principle
• convention over configuration
• best practice in other frameworks
• commonly accepted laws of physics

Not one of the people complaining is going to use this framework vanilla. They are going to add their own layer of behavior over the top. It’s been designed to make it easy (trivial in this case) to extend and change the policy.

Sane defaults are really important for frameworks. Yes they get in the way of power users. Yes it normally takes a power user 10 minutes to work around them and add that piece of code to their toolbox from then on.

I don’t know how many people were following the emergent rails community back in 2005 when the Google Web Accelerator was released – but many of them (including the smartest² ) got a salient lesson in GET idempotence. (i.e. GET Order?id=23&action=delete – should never delete anything).

Here was a situation where the framework (rails) came with not so safe defaults and bad example code which encouraged doing the wrong thing. These days – rails has absorbed this lesson so completely that it could be described as a REST server and in some ways leads developers into following best practices for web apps by default.

I really don’t understand what the huge deal is here? This seems as clear cut to me as the built in RequestValidation in ASP.NET or automatically escaping SqlParameters for SQL injection. Sure – if your a power user it can be a pain – but it takes 10 seconds to turn off and then your responsible when your site get p0wn’d.

It’s not like ControllerBase is sealed.

1. by default – but easily modifiable
2. or is that loudest?

When it comes to web applications – most teams don’t bother automating their deployment processes. This is something that I think is in the process of changing² – but is not yet a generally accepted practice on a par with TDD, user stories or iterations.

At a minimum – it should be possible to:

1. Issue a single command which creates a release package for your project. (i.e. built, tested, tagged in subversion and zipped up). For me – this tool/command is called: deploy.cmd and is just a batch file.
2. Issue another command in your deployment environment which will configure the new release. (i.e. update IIS root, upgrade the database, update connection strings + any other configuration required).

In my current project I’ve built 1. For me 2 does not exist as a single command line (It’s currently a combination of several tools – this should be changed!).

In my next post I’ll outline my very simple solution for this. Just to get the conversation started.

1. Ten years ago – part of my job was building deployment packages for desktop applications (this is pre MSI). Identifying all the dependencies of an app and scripting them into an install package and testing the deployment was at times almost a full time job.
2. there have been a couple of good threads about this on the altnetconf mailing list

At the time – the best web architecture I knew of was the ArsDigita Community System (still available and maintained as OpenACS). What Oren is describing sounds similar in many ways.

The ACS architecture is based on the days when Oracle and TCL were good options for building web based systems…. but the underlying design is still very very good (e.g. it was the first place I every saw the Party pattern). They were focused on designing good data models and separating concerns.

They have the following available in their kernel:

• Parties, Users and (nestable) groups
• A permissions system which supports per “object” (think row) permissions.
• A package manager which allows you to install (and remove) modules of functionality into an existing system (including schema changes, new routes etc). e.g. adding a e-commerce, blogging or threaded discussion module is a matter of clicking in a web ui.
• Scheduled tasks

This thing was and is pretty scalable (it runs the photo.net community).

It’s over 10 years old still a source of good ideas. I recommend taking a poke around their documentation and seeing what you can learn.

(I remember reading once that Philip Greenspun – the original ACS designer was asked by Microsoft to build a new version while the .net framework 1.0 was in development as a showpiece. For some reason he didn’t but I always felt that it was a shame this never happened).

Here’s a couple of great quotes (It’s worth noting that he’s talking about large projects):

Not everything is going to be well designed.

You may have a part [of a system] which is not complex – or is just straight forward data collection. You’ve got a lot of screens , a lot of fields. You’ve got to put it into the data base and do a simple report on it.

Don’t spent a lot of effort modelling these things. Just find some simple technology that’s good at that stuff.

The idea that the entire system is going to be based on an object oriented model is I think is a highly questionable assumption.

It’s a really interesting perspective – and a great antidote to some of the discussion at the moment which almost treats DDD as a silver bullet.

Anyone who’s feeling guilty because they don’t have their solutions structured into Core, Model, Services, Presentation, UI layers – or even worse is using a SqlDataSource control in their app – should watch it. It’s an excellent dose of pragmatism.