2010
01.10

To quote Eddie Izzard “Look, you’re British, so scale it down a bit, all right?”, well perhaps i should say “Look, you’re a validation framework, so scale it down a bit, all right?”. Recently i’ve been working on ALOT of javascript and experiences (reassuringly) from the past have come back to haunt me yet again. What am i talking about? Well it would seem that every framework starts out with the good intention trying to avoid repetition, but over time, someone adds a little here, and a little there and before you know it you have a behemoth of a framework which does things well out side the scope of what it should do.

How does this relate to javascript validation? Well after using quite a popular JQuery validation framework i noticed the size of the library minified as 29KB. This doesn’t sound a great deal but when you include a few frameworks like this, plus JQuery the page weights seem to get pretty big. Yes caching, gziping and content delivery networks will help but the first hit on these pages over mobile networks or on mobile phones and they can take quite a while to load. What i would like to see more of is smaller more directed frameworks/utilities that i can customise into what i want and keep page sizes to a minimum.

To this end i flippantly stated “It can’t be that hard” and embarked on writing a validation framework that will allow me to do most of what i need without the overhead. This is only a first stab that works for what i need, any comments on other validation types that i should support would be good.

Currently it supports… required (and ability to define a default value to ignore), patterns, less than, greater than, equal to, equal to other field and the ability to add custom rules. On top of this you can all specify rules that enable and disabled validation of a field. Currently the minified size stands at about 2k even tripling the number of rules would only take that up to about 4k.

I got the size down by only putting into the framework what really needed to be there. So what won’t it do? well it wont manage form click events for you, thats for you to decided how you want the validation to fire. It won’t do anything clever with the error messages, if you want something fancy write what you want.

Take a look at the code on git hub http://github.com/chrisabird/validate

2009
12.13

Last week I spent some time trying out the message based concurrency library Retlang in and effort speed up a portion of an application I’ve been working on. When picking up Retlang I found very few examples/explanations that were relevant to the current release (0.4.3.0).

In the beginning

Retlang is constructed of various channels that can have messages published to them. A channel also has fibers subscribed to them with a delegate to a function that accept a message as a parameter. So create a channel, subscribe a fiber to it and publish your messages to the channel and the fiber will process them one after another leaving your program free to do other things, Simple yeah? not one thread, mutex, monitor or lock in sight, don’t believe me how about an example?

using(var fiber = new ThreadFiber())
{
  fiber.Start();
  var channel = new Channel<string>();
  channel.Subscribe(fiber,
    value => {
      new WebServiceClient.SendString(value);
    }
   );
  channel.Publish("hello");
  channel.Publish("world");
}

Talk to me!

Ok so you might have noticed these published messages are asynchronous, you get nothing back. There are two solutions use the RequestReplyChannel instead of Channel which will process your message and wait for a response with each call. That’s gonna slow things down though, so instead we’ll publish the result on to another channel and pick them up after. Here goes…

using(var requestFiber = new ThreadFiber())
using(var responseFiber = new ThreadFiber())
{
  requestFiber.Start();
  responseFiber.Start();
  var requestChannel = new Channel<KeyValuePair<int, string>>();
  var responseChannel = new Channel<KeyValuePair<int, bool>>();
  requestChannel.Subscribe(
    requestFiber,
    value => {
      responseChannel.Publish(
        new KeyValuePair<int, bool>(
          value.Key, value.Value.Contains("world")
        )
      );
    }
  );
  var results = new List<KeyValuePair<int, string>>();
  responseChannel.Subscribe(
    responseFiber,
    value => {
      results.Add(value);
    }
  );
  requestChannel.Publish(new KeyValuePair<int, string>(1, "hello london"));
  requestChannel.Publish(new KeyValuePair<int, string>(2, "hello world"));
}

You said concurrent

Ok so the previous example used one fiber to find strings that contained the word “world” and another to collate them after. It’s hardly concurrent, still feels a bit sequential. In the example we can’t really add any concurrency to the collation of those responses, well not without locking that results list, plus that’s a very simple/fast operation anyway. What we can do is speed up the finding of the word “world” in strings because there is no shared state, that’s simple to do. The channel will allow you to subscribe as many fibers to it as you wish, only problem is every fiber will be called for each message. This doesn’t really do what we want, we’ll end up with many results for each message, what we really want is the first free fiber to process the next published message. Step in the QueueChannel which does just that, so same example but with more “fiber”!

using(var requestFiber1 = new ThreadFiber())
using(var requestFiber2 = new ThreadFiber())
using(var responseFiber = new ThreadFiber())
{
  requestFiber1.Start();
  requestFiber2.Start();
  responseFiber.Start();
  var requestChannel = new Channel<KeyValuePair<int, string>>();
  var responseChannel = new Channel<KeyValuePair<int, bool>>();
  requestChannel.Subscribe(
    requestFiber1,
    value => {
      responseChannel.Publish(
        new KeyValuePair<int, bool>(
          value.Key, value.Value.Contains("world")
        )
      );
    }
  );
  requestChannel.Subscribe(
    requestFiber2,
    value => {
      responseChannel.Publish(
        new KeyValuePair<int, bool>(
          value.Key, value.Value.Contains("world")
        )
      );
    }
  );
  var results = new List<KeyValuePair<int, string>>();
  responseChannel.Subscribe(
    responseFiber,
    value => {
      results.Add(value);
    }
  );
  requestChannel.Publish(new KeyValuePair<int, string>(1, "hello london"));
  requestChannel.Publish(new KeyValuePair<int, string>(2, "hello world"));
}

Those threads are a bit heavy

At the moment i’m using the ThreadFiber which maps down to a Thread. So for every ThreadFiber we’re creating new threads which is expensive so instead we might want to use the PoolFiber which uses the .Net ThreadPool to manage creation and reuse. It’s a very simple change to use the PoolFiber, just replace the ThreadFibers. The only difference between ThreadFiber and PoolFiber is that it will batch up a few messages to be processed in a single thread.

Pause for breath

This seems like a good place to stop for now. There are a few more things to cover in more detail like batch execution and some other things like customising execution but those can wait till another day.

2009
12.09

After writing my last post i’ve been thinking more about the question of “How should i organise my tests?”. The answer i gave last time seemed to work for fixing existing tests but didn’t seem to fix the cause of the problem that all the tests were still too much like unit tests. Oh yeah, at this point i’d like to point out i reserve the right to contradict myself.

While working on a separate RoR project I’ve used Cucumber to drive acceptance tests. If you’ve not tried it already, it’s great give it a go! Also on a side note i also discovered the guys who wrote selenium-client put a great deal more thought into the API than the .NET counterpart. Lots of extensions for waits and JQuery/Prototype integration are included by default. Anyway back to the problem at had, Cucumber forces you to write plain text stories (or features) and one or more scenarios for that story. Scenarios are written with each line start with “Given”, “When” and “Then” (and optionally And). Each line of the scenario corresponds to an executable “Step” that in my case performed a selenium action (or it could also quite easily perform an action against an API).

Feature: Manage blog posts
  In order to manage my blog posts
  As a writer of poor blog posts
  I want to be able to create blog posts

  Scenario: Create a blog post
    Given i have clicked add blog post
    And i have written "My first post" with content "My first post"
    When i click publish
    Then i should see the post "My first entry" in the list of posts

Anyway this method of writing test with the emphasis on the behaviour of the user (not surprising for a BDD tool) meant i ended up with less focus on one bit of functionality on a single page and more on the overall journey of the users actions through the application. Each scenario taking a different path or journey through that story.

Overall cucumber forced me to stay true to testing behaviour, avoiding the pitfalls of the test written in a plain unit testing framework. So, try cucumber, even if you don’t use it in your project i hope it makes you think differently about how you write the same tests in your native language.