I am going to be spending the next weekend and the following week in the Netherlands.

So, if you know of a cool user group, geek get-together or whatnot, please let  me know. Everything that has to do with web development (in any FW out there), large-scale systems, distributed data stores, agile processes, team leadership and management, ALM tools.

This is also a good opportunity if you are looking into a short consultation gig (a few hours) in one of the aforementioned areas, especially with MVC frameworks for .NET, client side JS/CSS guidance, setting up CI environment, DVCS usage and more. Give me a shout on email or through a comment on the blog (that will be kept private if you wish to)

I will mostly be in the area of Utrecht and Amsterdam, however I’ll have a leased car so I guess that everywhere within a reasonable driving range is acceptable.

So you’ve got this boring old lock keyword, with its “only one at a time” semantics, and you think “hey, lets use the ReaderWriterLock, since its cooler, and it now has a Slim version so it MUST be great !”

That is wrong on many levels.

Lets start with exploring what the RWLS is about, in contrast to the lock keyword (which is a syntactic sugar for Monitor).

Both are used to synchronise access to a shared resource that might get read and written by different threads at the same time.

the general pattern is (pseudo-code, please do not Copy And Paste to your favourite IDE :) ):

variable aResource
lock aLock
 
// when reading from the shared resource
lock_for_read(aLock):
   foo = aResource.get_value
   do_something_with foo
 
// when writing to the shared resource
lock_for_write(aLock):
   aResource.set_value something

The Monitor construct only allow a single thread to access the synchronised block at a time, whether it is for reading or writing, so actually the isn’t a distinction between lock_for_read and lock_for_write, instead there is a single `lock` keyword.

The meaning is that if you have many threads coming in and trying to read from the shared resource, they would have to queue and enter the block one by one.

The ReaderWriterLock allow multiple threads to access a read block at the same time, so they will only need to wait once a thread is asking for a write lock. Then the writing thread will wait for all other threads within synchronised blocks to complete, then do its thing.

Sounds great, isn’t it?

Well, actually the benefit of a ReaderWriterLock will only be in place when these two conditions are in place:

1. There is a low write contention – i.e. most of the times when a thread asks for a lock, it is for a read access only
2. The synchronised read block is not very quick anyway

why? because if the block executes very fast, then the waiting read threads will not need to actually queue up.

And if writes are not very sparse, an exclusive lock (because of the writes) will be taken many times, causing reading threads to queue anyway.

Adhering to the “no free gifts” rule, the usage of a ReaderWriterLock has more overhead than that of a Monitor, thus it would not be advisable to consider using the ReaderWriterLock unless you know for sure that the two aforementioned conditions will take place in the scenario.

And even then, you one should beware of a problem that might happen since there isn’t a syntactic sugar for the ReaderWriterLock. Since you have to release the lock yourself, the common usage pattern is:

ReaderWriterLockSlim locker = new ReaderWriterLockSlim();
...
// read block
locker.EnterReadLock();
try
{     //readAction
}
finally
{     locker.ExitReadLock();
}

// write block
locker.EnterWriteLock();
try
{     //write Action
}
finally
{     locker.ExitWriteLock();
}

Since I know that the usage is not 100% trivial, and that I might forget to exit the lock in a finally block (I’ve seen code examples around the interweb that forget to do so), I am usually looking up previous code of mine, and then copy-and-paste it.

Since like many other developers I tend to be lazy and sloppy when copy-pasting boring pieces of code around, I end up doing some mistakes such as entering a read lock, however exiting a write lock. I then get weird runtime exceptions that it takes a good few minutes to figure out. annoying.

This is without taking UpgradeableReadLock into account, which (imo) does not have a trivial API.  I will put a separate post explaining UpgradeableReadLock btw.

Summary:

1. The good old simple lock construct is always more readable and maintainable, than ReaderWriterLock. Sometimes most of the times it even performs better.
2. When the two conditions are met (low write contention, non-trivial read block), it is wise to consider a ReaderWriterLock
3. When using ReaderWriterLock, one should beware (more than the usual) from blind copy-and-paste operations.

Now since I found myself needing to use a ReaderWriterLock more than once lately, and since I did repeat the stupid copy-and-paste mistakes more than once, I created a little helper for that, included in my old-ish D9.Commons project, which is where I through reusable pieces of code at. Which reminds me that I need to move it to github some when soon.

Meanwhile it is at http://code.google.com/p/d-9/source/browse/trunk/src/D9.Commons/D9.Commons/Locks/Lock.cs, and it contains shortcut methods for executing code within Read, Write and UpgradeableRead blocks.

I’ll run a different post with a couple of usage snippets later.

A bit late, but I was pre-occupied with a few things so it went under my radar.

This release brings some exciting features, such as automatic-sharding and replica-sets, which completes MangoDB's Horizontal Scalability and High Availability to a complete solution. A finer control over consistency is also available now, with the w option, with which you can assert update propagation to a certain amount of servers (so if you use replica sets of 3 machines, you might want to set w=2 or even 3, depending on your consistency needs).

These features, along with the fsync option, makes MongoDB a legitimate solution for both high-scale distributed data stores, as well as for small, single machine scenarios. Everyone can enjoy the simplicity of this DB engine.

As for using MongoDB from .NET, I’m still undecided between mongo-csharp or NoRM. I also successfully used IronRuby with MongoMapper and Mongoid, so at least we have plenty of options at our disposal.

The new thing in MS web development is Razor, which at its base a templating engine.

It would be really cool if:

1. It would expose programmatic API (with c#5 going to Compiler-As-Service it would be a real shame if Razor would not behave the same way)
2. It would not enforce an over bloated base-class (like, erm, System.Web.UI.Page). I wouldn’t go as far as an Interface (since looks like they do not believe in Design By Contract over there), but a super-simple abstract base class with minimal pre-set behaviour would be nice. It is doable with still supporting Webforms/MVC integration using wrappers (like the HttpContextBase approach)

These things would allow using it as a true templating engine, which then can be embedded as a view engine for other web frameworks (like Monorail and Fubu, and more), use it for off-line email templates processing, maybe even for emitting customised setting files for automated deployment scenarios.

I need to try and explore into there and sniff around.

It is not very uncommon to see pages that include a “returnUrl” parameter, usually within authentication flows. At times, the browser will run some script (like a call to an analytics service) and then another script issuing a redirect (through setting location.href etc.)

There are also other cases where UGC can find its way into JavaScript blocks. People might want to have their script do fancy stuff with the page’s data.

var url = '<%=viewData.returnUrl%>';

or

var commenterName = '<%=viewData.newComment.authorName%>';

for e.g.

Now for the “stating the obvious”:

Just like any other UGC, this type of content must be sanitized to prevent XSS attacks.

Not to long ago I was called to do a security inspection on a web application’s codebase. During which, some very few XSS holes were detected using JavaScript injection. This was quite surprising to me, as I knew that all content injected into JavaScript was being sanitized by the team.

Digging further I found out that they did call a sanitize function on UGC, just not the correct function. What they did was to run a JSON formatter over the UGC string, a thing that was solving JS errors occurring from string quoting problems, but it did not eliminate malicious scripts.

The weird thing was that the team was already using the AntiXss library (which is a very aggressive, white list based input sanitation library for .NET), for html fragments. The library also have a JavaScript Encode function. Switching the sanitation function of the team from calling the JSON library to calling the AntiXss library fixed the problem for good.

e.g. code to demonstrate the difference between the methods:

static void Main()
{
    var ugc = "';alert('xss');'";
    Render(JsonConvert.SerializeObject(ugc));
    Render(AntiXss.JavaScriptEncode(ugc));
}

static void Render(string encoded)
{
    Console.WriteLine("var returnUrl = '"+encoded+"';");
}

The output from the above snippet is:

var returnUrl = '"';alert('xss');'"';
var returnUrl = ''\x27\x3balert\x28\x27xss\x27\x29\x3b\x27'';

There are a couple of things to learn from that story:

1. When you encounter a problem, look around for common solutions. for e.g., every language that is being used for web development today has a library that takes care of XSS, so use it instead of coming up with a partial solution using the wrong library, or even worse –try to re-invent the way of doing that. You are probably not in the business of Anti XSS, so don’t spend time on solving the problem.
2. Know your toolbox. If you are using a tool, be aware of its capabilities (and shortages). Exploring the AntiXss library a little bit would have shown the team that there is a perfectly good solution for their problem.

From the method’s doc:

Modifies the current HashSet<T> object to contain all elements that are present in both itself and in the specified collection.

Now I know my way around (at least the basics of) set theory, and I *know* what union means. nonetheless I read the doc of the method and for some reason I thought that I’d get the intersection.

For those unsure about what Union means (or what it actually does), the following code:

var set = new HashSet<int>(new[] {1, 2});
var other = new[] {2, 3};
set.UnionWith(other);
Console.WriteLine(Serialize(set));

So, I ended up bumping my head on the wall keyboard for a couple of minutes trying to understand why a perfectly good test fail with no reason, until I figured it out. It is true that I wasn’t showing a huge amount of smartness here, and it could be that my English skills are poor, but I believe replacing “and” with “or” will serve the method’s doc better.

If the BCL was open source I would have sent a patch with the doc fix …

I’ve just completed moving my server from http://gogrid.com to http://softsyshosting.com/ (thx to Mike Nichols for the tip).

GoGrid were great. They have a very good customer service, the control panel is amazing and the options and flexibility are simply great. However the price was simply too much. I’m now getting twice as RAM for half the price, and since I do not plan to expand to multiple instances anytime soon, the flexibility and load-balancing options of GoGrid are simply shiny but pricy.

Now since I had very little time to spend on the move, and since it wasn’t a straight xcopy thing (as it’s now on IIS7.5 and I needed to do some tweaks to the blog engine), I stopped creating any content until the new server was up, and DNS was updated all across.

Expect new posts shortly.

If you ever have wondered how would a social shopping experience could look like, now you can get first taste of it.

http://www.delver.com is just that, and we are now on an invitation based closed-beta phase. If you want to be of the first ones in, and help shape the future of social shopping via early user feedback, drop me a line (in comments or email) and I’ll send you an invitation URL.

Please drop me a line through the comments, email, or whatever. The torrent thing does not work for me I’m afraid

And guess who is the craziest one.

scenario

Client side validation is good right? so you have this field of User Generated Content, which is exposed via a textarea element on your page. For e.g. – comment on blog post.

Now you have a limit of N characters on the field, maybe enforced within a DB constraint or whatever.

First attempt:

function validateMaxLength(elmId) {
	var element = document.getElementById(elmId);
	var elementContent = element.value;
	var elementContentLength = elementContent.length;
	
	return elementContentLength <= N;
}

or something like that.

BUT

think again.

Assuming the element’s content was something like

the element contains at least
one newline

how would you count newlines? would you count two characters per newline (for \r\n)? or only one?

When I faced that problem I checked how the browser is counting the newlines. I ran a quick test as saw that it counts newlines as a single character. Since the content was needed to be presented within a web element anyway, and newlines were to be changed to <br/> tags at render time anyway, I decided to have the server code make sure that incoming strings will use only \n for newlines, then validate the length, then store in the DB.

Now the client side JS matched the server criteria.

Case closed.

Or was it?

QA kicks in

After a little while I got a bug opened by the QA team about inconsistency between client and server validation regarding lengths of string.

Checked it, and was about to close the bug with a “works for me” message, but then it hit me.

You have to be so special

On IE, newlines are \r\n, so it reports too many characters, and the validation might fails wrongfully. Since I mostly use Chrome for day-to-day, and since I did not suspect *that* to be a cross-browser issue, I never tested it on IE during development.

Solution

Good old string.replace

elementContent = elementContent.replace('\r\n','\n');

Ken,

the cross-browserer