The Ordered Jobs Kata

As you may well know, a kata is a training exercise that is performed over and over to build muscle memory and generally improve at whatever it is that we’re practising. The term kata comes from martial arts, but us software guys/gals have started using the term to describe the solving of small problems repeatedly to get better at things like TDD and pairing.

Katas also have the added benefit of making non-geeks think we’re healthy individuals that don’t just sit in dark basements all day. In fact, we’ve started using the word dojo to make absolutely sure our new image sticks.

Anyway, I had an interesting kata-like problem at work and I figured it’d be cool to describe it here for the masses of programmers out there having cold sweats and shaking in need of their next kata fix.

Feel free to have a go, and if you do, please leave a comment linking to your solution so I can collect them all at the bottom of this post. Then we can all mock each other (no pun intended). It’ll also be interesting to see if the choice of programming language affects the solution.

The Kata

Imagine we have a list of jobs, each represented by a character. Because certain jobs must be done before others, a job may have a dependency on another job. For example, a may depend on b, meaning the final sequence of jobs should place b before a. If a has no dependency, the position of a in the final sequence does not matter.

The goal of the kata is to parse the job dependency structure and produce a sequence of jobs in the order that observes their dependency chain.

Start with a method that accepts a single string argument and returns a string which represents the ordered sequence of jobs (since each job is a single character). We’ll refine the algorithm by evolving the requirements with each step, just like the string calculator kata.

Step 1 – Empty String

Given you’re passed an empty string (no jobs), the result should be an empty sequence.

Step 2 – Single Job

Given the following job structure:

a =>

The result should be a sequence consisting of a single job a.

Step 3 – Multiple Jobs

Given the following job structure:

a =>
b =>
c =>

The result should be a sequence containing all three jobs abc in no significant order.

Step 4 – Multiple Jobs, Single Dependency

Given the following job structure:

a =>
b => c
c =>

The result should be a sequence that positions c before b, containing all three jobs abc.

Step 5 – Multiple Jobs, Multiple Dependencies

Given the following job structure:

a =>
b => c
c => f
d => a
e => b
f =>

The result should be a sequence that positions f before c, c before b, b before e and a before d containing all six jobs abcdef.

Step 6 – Multiple Jobs, Self Referencing Dependency

Given the following job structure:

a =>
b =>
c => c

The result should be an error stating that jobs can’t depend on themselves.

Step 7 – Multiple Jobs, Circular Dependency Chain

Given the following job structure:

a =>
b => c
c => f
d => a
e =>
f => b

The result should be an error stating that jobs can’t have circular dependencies.

Completed Solutions

In Ruby

Ash solves the kata using RGL and RSpec

Caius solves the kata using black magic and testrocket

Sam solves the kata using RSpec

Kevin solves the kata in the style of TDD as if you meant it using RSpec

Matt solves the kata using RSpec

In C++

Thomas solves the kata using C++11

In C#

Martin solves the kata using MSpec

Thomas solves the kata using MSTest

Gemma solves the kata using NUnit

In Python

Mark solves the kata using unittest

In SQL (yes, SQL)

Sherwin solves the kata using manual tests

Johnno solves the kata using EYEUnit

Kev solves the kata using manual tests

In CoffeeScript

Tom solves the kata using nodeunit and documents his solution

In Scala

David solves the kata using specs

In JavaScript

Sam solves the kata again using Jasmine

C# News From The Future: What If?

It’s a fresh September morning and I can’t quite believe it’s actually available – we’ve got a preview release of C# 6. Ever since the announcement at PDC2012 last month, I’ve been waiting to play around with a particular new feature. I remember it being a fairly average PDC until Anders shocked everyone with it – method group assignment.

Monkey patching! It surprised me because, until now, I saw the future of C# as an increasing story of ceremony. In recent months F# has been gaining an unbelievable amount of attention because of its awesome inference and perceived simplicity due to lack of ceremony. And let’s not even mention Ruby.

Lots of the dynamic languages, in fact, seem to involve much less work these days when it comes to bending the language into a shape that fits the problem well. And really, that’s what we do as programmers. The question is: how can the language be so flexible that it lets us solve any problem?

Without Monkey Patching

I’ve been writing a really simple app that lets users register for an account and store notes. Until today, I had been jumping through hoops trying to aim for the right amount of SRP and DI that makes this thing testable. What I ended up doing was extracting an interface for each dependency of the unit that I needed to test, so that I could test it in complete isolation.

We know that interfaces weren’t intended solely for producing seams for testing, but that’s pretty much how we all use them anyway. We end up with two, three, maybe four additional interfaces and associated classes, and a dependency chain, when all we really wanted was to test the damn thing.

It’s true that we potentially get a better design in terms of looser coupling and separation of concerns, but get this: I don’t want that in this case. This is a single controller app with a small and perfectly understandable behaviour. I should be able to bend C# (and not have to work around it) into testing my app.

Ultimately we end up trading complexity for testability. Incidentally, isn’t complexity proportional to number of bugs? In reality, testability should be easy and should be part of the pit of success.

C# Just Took Up Yoga

Well, things just changed. From what I understand, the CLR guys managed to implement new functionality that allows the assignment of a delegate to a method group. It does some kind of smart matching with the delegate parameters. I don’t know all the technical details, but I do know that it freaking rocks.

Consider my simple app:

public class UserService
{
    public void Register(string username)
    {
        using (var context = new DataContext())
        {
            context.Users.Add(new User
            {
                Username = username,
                Created = DateTime.Now
            });

            context.SaveChanges();
        }

        Notifications.Send("New user: " + username);
    }
}

Normally I’d be coupled to DataContext, DateTime.Now and my static Notifications.Send method, making unit testing this method particularly difficult. But since C# 6 supports monkey patching, this thing is now perfectly testable and without the otherwise unnecessary interfaces and complexity.

We can patch DataContext (stubbing it, in test parlance) and make it do nothing. We can patch DateTime.Now to give us a more predictable value. And we can certainly patch Notifications.Send so that it doesn’t send anything and just allows us to inspect the message.

Here’s the test:

[Test]
public void Register_WithValidUsername_RegisterUserAndNotifies()
{
    User user;
    string notification;

    // Patch

    DateTime.Now = () => new DateTime(1, 1, 1);
    
    DataContext.SaveChanges = (context) => 
    {
        user = context.Users.FirstOrDefault();
    };

    Notifications.Send = (msg) =>
    {
        notification = msg;
    };

    // Act

    new UserService.Register("bob");

    // Asset

    Assert.That(user.Username, Is.EqualTo("bob"));
    Assert.That(user.Created.Year, Is.EqualTo(1));
    Assert.That(user.Created.Month, Is.EqualTo(1));
    Assert.That(user.Created.Day, Is.EqualTo(1));
    Assert.That(notification, Is.EqualTo("New user: bob"));
}

Not Limited To Testing

Monkey patching (also know as duck punching, if you prefer) is not only useful for testing. This new ability to patch stuff means we can replace behaviour in classes that we don’t necessarily own.

Some HTTP library you’re using have a broken URL encoding method? Just patch it. Want to redirect a method to somewhere else without introducing a subclass? Just patch it.

What Does This Mean?

Today was a big day for C# – it just became easier to fall into the pit of success:

  • Testing code is now much easier out of the box since all we have to do is stub it via a good old duck punch to the gut.
  • We don’t have to introduce 5 interfaces purely for the sake of testability when the design doesn’t require such decoupling.
  • All that legacy (otherwise untestable) code is now testable – just patch it.
  • Bugs in code we don’t own just became fixable.

But most importantly, C# gave us back some control and let us decide what’s dangerous and what’s not. C# just became more flexible and gave us a chance to be more awesome with it. C# just trusted us.

Tinyweb Series: 5 To-do Demo

In the previous post in this series we saw how to render Spark views from handlers, looking at the use of view models and master page layouts. Finally, we took a more in-depth look at model binding support in Tinyweb.

In the final post, we’ll work through a to-do list demo which will pull together a number of the features already covered in the series into a complete application.

What We’re Building

We’re going to build a simple web application with a JSON/XML API that allows the creation, deletion and completion of simple to-do items. We’ll have a view that displays the current list, a method for removing and completing individual items and a form for creating new ones.

The Resources

Let’s consider which resources we’ll need to create in order to support the requirements.

/login

The LoginHandler will allow a user to authenticate by providing a login view.

/todo/list

The TodoListHandler will display the current list of to-do items.

/todo/add

The TodoAddHandler will create a new item and redirect back to the list.

/todo/complete

The TodoCompleteHandler will complete an item and redirect back to the list.

/todo/uncomplete

The TodoUncompleteHandler will undo the completed status and redirect back to the list.

/todo/remove

The TodoRemoveHandler will delete an item and redirect back to the list.

The API

As it’s a demo, we’ll keep the API simple. Our imaginary requirement here is that the current to-do list should be available outside of the application for things like external widgets or mobile phone applications to consume.

We’ll achieve this with a single handler at /api/todo/list that returns the current to-do list in either JSON or XML format.

Authentication

For the sake of keeping the demo easy to understand, our security requirements are simply going to be that a user must log in using a hard-coded username and password before they can use the application. We’ll use an authentication filter to implement this.

Logging

Finally, to catch any errors with our to-do list, we’ll also implement error logging so that we can periodically check any exceptions that have been thrown by the handlers.

Here’s One I Prepared Earlier

To use the demo, the first thing we need to do is authenticate at /login using the hard-coded username and password admin and password respectively:

We’re then presented with the to-do list at /todo/list:

Now that we have a feel for what this thing looks like, let’s go through the implementation details and discuss how it’s built with Tinyweb. If you’d like to follow along beyond the snippets used in the rest of this post, you can do so by looking at the demo code on github.

Project Layout

Although Tinyweb does not enforce a particular convention in terms of where you put files within the project, I tend to follow my own to be consistent between projects. Handlers go in a Handlers folder, filters in Filters and so on. Here’s the project layout for the to-do demo app.

It should be fairly easy to figure out what’s going on. Don’t worry too much about the files inside the Database directory since data access isn’t especially relevant to the demo app. Similarly, the Content directory isn’t too interesting either, it just contains CSS and JavaScript.

The core of the app is contained within the directories you see expanded. We have the aforementioned handlers right there in Handlers. Note how I’ve separated the API and the web app handlers to make it more explicit (again, just my own convention here).

There aren’t many views, so I’ve just bunched them together under Views. We also have a partial view named Add.spark which just creates a <form> that enables new to-do items to be posted to /todo/add.

From The Beginning

As we’ve covered in the previous posts, the first step in creating a Tinyweb app is to initialise the framework in Global.asax:

protected void Application_Start(object sender, EventArgs e)
{
    Tinyweb.AllowFormatExtensions = true;

    Tinyweb.Init(new DatabaseRegistry());

    Tinyweb.OnError = (exception, request, handler) =>
    {
        var error = String.Format("Error at {0} from {1}:\r\n{2}", 
                                  handler.Uri, 
                                  handler.Type.Name, 
                                  exception.ToString());

        var log = request.HttpContext.Server.MapPath("/errors.txt");
        File.AppendAllLines(log, new[] { error });
    };
}

The first thing we do is turn on format extensions, allowing the Accept header to be specified on the URL (i.e. /api/todo/list.xml and /api/todo/list.json).

Next we initialise the framework and pass in a StructureMap registry. The DatabaseRegistry configures how the IDatabase dependency (used by handlers to persist the to-do list to a text file database) can be resolved at runtime.

Finally, we set up error logging using the Tinyweb.OnError delegate. In this instance, we just want to append to a log file every time an error occurs, storing the handler, the URL and the exception.

OK – Initialisation – check, let’s look at the root request handler.

RootHandler

I hope you didn’t get too excited, as the RootHandler is pretty dull. The only reason we have a RootHandler is so people new to Tinyweb running the demo actually reach the login page without having to find and enter the URL themselves. As such, RootHandler simply redirects to the LoginHandler:

public class RootHandler
{
    public IResult Get()
    {
        return Result.Redirect<LoginHandler>();
    }
}

LoginHandler

Moving right along, the next leg of the request takes us to the LoginHandler:

public class LoginHandler
{
    public IResult Get()
    {
        return View.Spark("Views/Login.spark", "Master.spark");
    }

    public IResult Post(RequestContext request, string username, 
                                                string password)
    {
        if (username == "admin" && password == "password")
        {
            issueCookie(username);
            return Result.Redirect<TodoListHandler>();
        }

        return Result.Redirect<LoginHandler>();
    }

    private void issueCookie(string username)
    {
        var ticket = new FormsAuthenticationTicket(username, true, 60);

        HttpContext.Current.Response.Cookies.Add(
          new HttpCookie(FormsAuthentication.FormsCookieName, 
                         FormsAuthentication.Encrypt(ticket))
        );
    }
}

When a GET request is made to the LoginHandler, the login view that we saw in the screenshot is rendered. When the login form is posted back, the username and password are checked against our hard-coded values. If they don’t match, we redirect to the LoginHandler so the user can try again.

If the username and password are correct, we use ASP.NET Forms Authentication to issue a ticket and log the user in. We can then redirect the user to the to-do list, safe in the knowledge that the authentication filter will let them through.

AuthenticationFilter

Our AuthenticationFilter runs before every request and makes sure that only authenticated users can access the to-do list.

public class AuthenticationFilter
{
    IList<Type> allowedHandlers = new List<Type> 
    { 
        typeof(LoginHandler), typeof(ApiTodoListHandler) 
    };

    public IResult Before(RequestContext context, 
                          HandlerData handler)
    {
        if (!context.HttpContext.User.Identity.IsAuthenticated)
        {
            if (!allowedHandlers.Contains(handler.Type))
            {
                return Result.Redirect<LoginHandler>();
            }
        }

        return Result.None();
    }
}

This is achieved by maintaining a list of allowedHandlers and checking each request against the list. If the request handler is not in the list, a check if made to see if the user has authenticated to determine if they’re allowed access to the resource. If the user isn’t authenticated, a redirect result is returned which bypasses the rest of the execution pipeline and asks the user to log in.

TodoListHandler

When authenticated, we hit the TodoListHandler:

public class TodoListHandler
{
    IDatabase _database;

    public TodoListHandler(IDatabase database)
    {
        _database = database;
    }

    public IResult Get()
    {
        var model = _database.GetAll();

        return View.Spark(model, "Views/List.spark", "Master.spark");
    }
}

The TodoListHandler is a fairly standard handler which uses its IDatabase dependency to retrieve the current to-do list.

The DatabaseRegistry that was registered during initialisation will allow Tinyweb to supply a concrete Database at runtime. The IDatabase dependency is a file-based database for storing and retrieving the to-do items. In a real application, we might depend on some service class instead of directly depending on a data access class like this, but it’s a demo – it’s allowed to suck.

The TodoListHandler retrieves the current to-do list and renders the Views/List.spark view, passing the to-do list as the model. Let’s take a look at the view:

<viewdata model="TodoList" />

<content name="header">

    Todo List
       
</content>

<content name="body">

    <div if="!Model.Items.Any()" class="notification">
        Woohoo - nothing to do!
    </div>

    <div each="var todo in Model.Items" class="${todo.Complete ? 'complete' : 'todo'}">
        
        <div class="text">
            ${todo.Text}
        </div>
        
        <div class="date">
            ${todo.Date.ToString("dddd dd MMM yy")}
        </div>
        
        <div class="menu">
            <a href="${Url.For<TodoRemoveHandler>(new { todo.ID })}">Remove</a> | 
            <a href="${Url.For<TodoUncompleteHandler>(new { todo.ID })}" if="todo.Complete">Undo</a>
            <a href="${Url.For<TodoCompleteHandler>(new { todo.ID })}" if="!todo.Complete">Complete</a>
        </div>

        <div class="clear"></div>

    </div>

    <render partial="partials/add" />
    
</content>

The first thing to note is line 1 where the expected view model type is declared. The view is then broken into two sections – the header and the body.

The first thing the view does is conditionally show the Woohoo – nothing to do message depending on whether the model contains any to-do items. Notice the very clean if=”” Spark syntax for performing this check.

Next, the view repeats a <div> for each of the to-do items that exist within the model. For each item, the class of the <div> is set depending on the state of the to-do item (complete or not) and the content of the <div> is built up to reflect the data about the particular item, such as the text and date.

Lastly, we render the Partials/Add.spark view which provides the <form> for creating new to-do items:

<form id="add" method="post" action="${Url.For<TodoAddHandler>()}">

    <input type="text" name="todo" />
    
</form>

<script type="text/coffeescript">
    
    $ ->
      $('#add input').focus()
      $('#add').submit ->
        false if $('#add input').val() is ""

</script>

The partial exists mainly as a demonstration of how this is done using Spark, but also to show how the application might be broken up at the view level to reuse separate elements of the system (we may want to add a to-do item in some other area of the application).

Also notice the use of the Url.For helper. The use of Url.For is encouraged as it keeps the details of the actual URL in one place and makes refactoring safer and easier.

TodoAddHandler

When a new to-do item is posted, a request will be made to /todo/add with a single value named todo in the request. The TodoAddHandler will then come to the rescue:

public class TodoAddHandler
{
    IDatabase _database;

    public TodoAddHandler(IDatabase database)
    {
        _database = database;
    }

    public IResult Post(string todo)
    {
        _database.Add(new TodoItem {Text = todo, Date = DateTime.Now});
        _database.Save();

        return Result.Redirect<TodoListHandler>();
    }
}

Much like the TodoListHandler, the TodoAddHandler takes a dependency on IDatabase and simply delegates the work of adding the new to-do item to it. After adding the item, the user is redirected back to the TodoListHandler.

The TodoRemoveHandler, TodoCompleteHandler and TodoUncompleteHandler are all alike, delegating to an IDatabase dependency to perform their single task and redirecting back to the main to-do list afterwards.

The API

The API in this example is just a single end point that gives us back the current to-do list in either JSON or XML format. As you may have noticed before, the ApiTodoListHandler is exempt (as it’s contained within the allowedHandlers list) from authentication, allowing unauthenticated users to request data from the API.

public class ApiTodoListHandler
{
    IDatabase _database;

    public ApiTodoListHandler(IDatabase database)
    {
        _database = database;
    }

    public IResult Get()
    {
        return Result.JsonOrXml(_database.GetAll());
    }
}

Nothing should be too surprising here – we have a simple handler that supports GET requests at /api/todo/list and gives us back the representation we requested via the Accept header or via an extension override.

Recap

And that’s a wrap! We’ve now built the 7 web app handlers that collaborate to form the to-do list and we’ve also created a single API handler which allows the to-do list data to be consumed outside of the core application.

We’ve implemented error logging inside Tinyweb.OnError by appending log messages to a text file, allowing us to easily diagnose any errors resulting from handlers at runtime.

Finally, we saw how a global before filter could be used in conjunction with Forms Authentication to ensure that only authenticated users could access particular resources of the system.

The full to-do demo app can be found at https://github.com/martinrue/Todo-Demo if you’d like to play around with it.

That’s All Folks

So, this was the final post in the Tinyweb series and I hope by now it has touched on enough aspects of the framework to give you a good idea of where it sits and what it’s good at. Hopefully, at least one takeaway from this series of posts will be how simple Tinyweb makes building close-to-the-metal web applications – after all, that is Tinyweb’s primary goal.

I’d love to hear from anyone using the framework and please let me know if you come across any issues or have any suggestions. And remember, Tinyweb is open source and can be forked and contributed to from the github repository.

All of the content in this series is also detailed in the official documentation, so please check there for any clarifications or give me a nudge on Twitter.

Tinyweb Series: 4 Views & Model Binding

In the previous post in this series, we looked at Tinyweb’s support for dependency injection and saw how to use both handler and global filters to add processing steps to the execution pipeline.

In this post we’re going to see how to render views using the Spark view engine and take a closer look at how model binding works.

Views

We’ve already looked at the various result types that you can return from a handler, but we skipped over arguably the most important one, a view. A view is just HTML, but usually rendered through the use of a templating engine that makes it easier to combine HTML and data.

You may have played around with different view engines in MSMVC and come across the Spark view engine. If not, don’t worry – it’s fairly easy. Tinyweb ships with support for Spark, so that’s what we’ll use for the examples here.

Let’s see a simple example:

public class RootHandler
{
    public IResult Get()
    {
        return View.Spark("Views/Index.spark");
    }
}

We have a pretty typical handler which accepts GET requests at / (the root request) and outputs the Spark view at Views/Index.spark.

The notable difference from the other result types is that views come from the static class View, whereas other results come from Result i.e. Result.String. The only reason for this is that simple types and views are considered different and therefore kept separate.

You’ll notice that the view path starts with a directory named Views. Unlike MSMVC, this is not a convention – it’s just a pattern I tend to follow. If the view file was placed at the root of the application, we could simply return View.Spark(“Index.spark”).

There’s little point regurgitating the Spark documentation in this post, but in case you have never come across Spark before, here’s what a typical view might look like:

<viewdata model="QuestionAnswerJokes" />

<ul>
  <li each="var joke in Model.Jokes">
    Q: ${joke.Question}
    A: ${joke.Answer}
  </li>  
</ul>

Our contrived view tells Spark that it’s expecting an instance of QuestionAnswerJokes to be passed to it. It then produces an <li> element for each joke contained within the QuestionAnswerJokes.Jokes collection, outputting the question and answer part of each joke into the <li>.

So, how does it get the model object?

View Models

In the handler above, the astute will have noticed that there’s no model being passed to the view. Fear not, I wasn’t trying to hide hideous complexity:

public class RootHandler
{
    public IResult Get()
    {
        var jokes = JokeService.GetQAJokes();
        return View.Spark(jokes, "Views/JokeList.spark");
    }
}

The view model is simply passed as the first argument to View.Spark, and as long as the model type matches the <viewdata model=”…”/> declaration, we’re good to go.

Master Pages

If we want a view to be part of a master layout, we must specify the master’s name (relative to the location of the view) in the call to View.Spark. This may become cleaner in the future, but for now, it looks like this:

public class RootHandler
{
    public IResult Get()
    {
        return View.Spark("Views/Index.spark", "Master.spark");
    }
}

Rendering views from Tinyweb doesn’t get much more difficult than that, so let’s continue on and take a look at model binding in Tinyweb.

Model Binding

Model binding is the process of automatically taking data from the request (such as the query string or form post data) and mapping that data to the parameters (or properties where a class is used as a parameter) of the handler method. Model binding is useful because it means you write less code and let the framework deal with boring jobs like digging into the request data and populating objects.

There are three locations that Tinyweb will search for data. It’ll look in the query string, followed by the form post data and finally the route data (which only applies if you are using custom routes with route parameters, see Routing).

Three types of model binding are currently supported:

  • Simple parameters such as int and string
  • Custom class parameters such as LoginModel and UserSignupModel
  • Array parameters such as int[] and bool[]

Let’s go through each one and see an example of where it might be helpful.

Simple Parameters

public class CalculatorAddHandler
{
    public IResult Get(int first, int second)
    {
        return Result.String((first + second).ToString());
    }
}

If we now make a GET request to /calculator/add?first=4&second=2, we should be seeing 6 in the response. In the event no value is sent for first or second, we’ll get an error telling us that required parameters are missing. If you need optional parameters, see the Optional URL Parameters section of the docs (you could also use a custom class, where non-matched properties are just ignored).

Custom Class Parameters

We may also want to use our own classes as parameters to handlers for composing lots of separate fields. For example, If we were implementing a search handler we may want to use a SearchData class to hold the various search options:

public class SearchData
{
    public string Query { get; set; }
    public bool NewestFirst { get; set; }
}

Our handler can now accept an instance of this class, which the model binder will create and populate from the data in the request:

public class SearchHandler
{
    public IResult Get(SearchData searchData)
    {
        var results = SearchService.Search(searchData);
        return View.Spark(results, "Views/Results.spark");
    }
}

A request to /search?query=help&newestFirst=true will result in the creation of the SearchData object with the relevant properties populated. If the model binder can’t find data for a property, it will simply ignore it without throwing an exception.

Array Parameters

Binding to array parameters can be useful for situations where a collection of values is posted to a handler (via AJAX for example). Let’s assume we have a list of ToDo items in a view and when an item is clicked we toggle an attribute that marks it as complete. Clicking the Save button might run something like the following:

var completed = new Array();

$('#todos').each(function() {
    if ($(this).attr('complete') == 'true') {
        completed.push($(this).attr('todoId'));
    }
});

$.post('/todo/delete', { Completed: completed }, function() {
    alert('Saved');
});

The script builds up an array of numbers and posts them to /todo/delete. A handler can receive the collection like this:

public class TodoDeleteHandler
{
    public IResult Post(int[] completed)
    {
        var deleted = TodoService.DeleteMany(completed);
        return Result.JsonOrXml(deleted);
    }
}

Special Binding Cases

Tinyweb’s model binder has two special cases where the handler or filter can get access to either the RequestContext or the HandlerData for the current request.

The RequestContext gives you access to the underlying ASP.NET infrastructure (the HttpContext – please, don’t run away, come back) and means you can do anything that you’d do from within a raw HttpHandler, such as access the Request, Response, Cache and Session collections.

HandlerData is a class from tinyweb.framework that holds the handler’s System.Type and its URL, in addition to any default route values it has defined. Accessing HandlerData is useful more so in filters where the handler for the current request needs to be identified for things like logging.

The model binder will supply RequestContext and HandlerData to any handler or filter that declares a parameter of either type.

Model Binding Limitations

As of version 2.1.0 of Tinyweb, the model binder provides no way to exclude individual properties from model binding. The recommended practice is to use a type specifically crafted for receiving only the data you care about from model binding. The next release will add support for binding exclusions, addressing those situations where you wish to bind to existing objects but restrict the binding scope.

EDIT As of version 2.1.2, binding exclusions are supported via use of the [Ignore] attribute on class members that should be excluded from model binding. See model binding for more information.

In This Post

We looked at rendering Spark views and touched on how to use view models and master layouts. We then focused on model binding in a little more depth, looking at each of the three (simple, complex & array) types of binding supported and – as is tradition at this point – built a couple of contrived examples to demonstrate the point. Finally, we saw the two special binding cases for getting access to RequestContext and HandlerData.

Keep in mind that everything we’ve covered so far is also covered in the documentation, which is the best place to go if you require clarification. Failing that, I’ve been known to tweet once or twice.

In The Final Post

We’ll put together a few of the things talked about so far and build a ToDo application, dealing with things like API access, authentication and logging. We may even get time to do some benchmarking.

Tinyweb Series: 3 Dependency Injection & Filters

In the previous post in this series, we looked at how Tinyweb can be used to build HTTP APIs and examined each of the result types a handler may return.

The examples in the last post used made-up dependencies and you may have wondered how does the handler get these dependencies? In this post, we’ll look at how easy it is to have dependencies injected into handlers. We’ll also take a look at the use of filters to facilitate things like logging and error handling.

Dependency Injection

We probably all know what dependency injection is, but let’s just clarify. Assume we have a UserService which implements IUserService, allowing us to invert the dependency (SOLID). In a handler (or filter), we need access to an instance of UserService, but we can’t create one directly as we’d violate DIP. Instead we need a container to create the dependency chain for us. We simply depend on the interface and leave the dependency construction to the container.

Let’s see how we can do this in Tinyweb.

In line with its goal of keeping things as simple as possible, Tinyweb takes a dependency on StructureMap in order to support dependency injection out of the box. This means that all you need to do is create StructureMap registries and tell Tinyweb about them – the rest will be handled by the framework.

Using the UserService example from above, let’s assume we have the following:

public interface IUserService
{
    User GetById(int id);
}

public class UserService : IUserService
{
    public User GetById(int id)
    {
        // find the user and return it
    }
}

The next thing we need to do is create a StructureMap registry which associates these two, like so:

public class ServiceRegistry : Registry
{
    public ServiceRegistry()
    {
        Scan(x =>
        {
            x.TheCallingAssembly();
            x.WithDefaultConventions();
        });
    }
}

The ServiceRegistry tells StructureMap that interfaces IFoo and IBar in the current assembly should have concrete types called Foo and Bar respectively.

We need to tell Tinyweb about this registry for it to be  able to construct handlers that have constructor dependencies. Registering them is as easy as passing them to Tinyweb.Init, like so:

protected void Application_Start(object sender, EventArgs e)
{
    Tinyweb.Init(new ServiceRegistry());
}

Internally Tinyweb associates any registries with StructureMap, which it then uses to create handlers when requests come in. This allows us to create handlers with abstract dependencies and have the framework deal with it for us:

public class UsersAddHandler
{
    IUserService _userService;

    public UsersAddHandler(IUserService userService)
    {
        _userService = userService;
    }

    public IResult Post(User user)
    {
        var added = _userService.Add(user);
        return Result.JsonOrXml(added);
    }
}

When a POST request is made to /users/add, the framework will create an instance of the UsersAddHandler using StructureMap, and because we have registered the ServiceRegistry the IUserService dependency will be supplied as a concrete UserService.

Filters

Moving on, let’s take a look at filters and see how they let us plug into the execution pipeline of a request. Tinyweb supports both handler filters and global filters. A handler filter is a Before or After method on the handler which is run before or after the intended HTTP method is run, like so:

public class RootHandler
{
    public IResult Before()
    {
        return Result.String("Before the request...");
    }

    public IResult Get()
    {
        return Result.String("Root request");
    }

    public IResult After()
    {
        return Result.String("After the request...");
    }
}

Notice how the two filters also return IResult, allowing them to affect the response. Filters can have void return types if they don’t wish to add anything to the response. The example above, predictably, outputs the following:

Before the request...
Root request
After the request...

Filters also have the same model binding support that handler methods have, allowing a filter to log events using data from the request, for example:

public class UsersDeleteHandler
{
    public IResult Post(int id)
    {
        var deleted = UserService.Delete(id);
        return Result.JsonOrXml(deleted);
    }

    public void After(int id)
    {
        Logger.Log("Deleted user " + id);
    }
}

Since we’re simply logging that a user has been deleted, we don’t use the IResult return type on the After filter.

To recap, handler filters are just well defined ways of running code just prior or just after a handler method is executed. Let’s move on and have a look at global filters.

Tinyweb also supports global filters that apply to all handlers, which is useful for system-level logging or performance monitoring. Use a global filter when something needs to happen before or after every request.

Like handler filters, global filters also support model binding – though it may not be very useful for situations where you’re logging every request (as you wouldn’t know which request and hence what required data has been sent).

Global filters are just like handler filters except they must exist in a separate class which ends with the word Filter. MyLoggingFilter would be discovered as a valid filter (as long as it had a Before or After method), whereas MyLoggerFilterClass would not be found because it doesn’t end with the word Filter.

Let’s see an example:

public class TimingFilter
{
    Stopwatch timer;

    public void Before()
    {
        timer = Stopwatch.StartNew();
    }

    public IResult After()
    {
        timer.Stop();
        return Result.String("Time: " + timer.ElapsedMilliseconds);
    }
}

This filter adds the Time: xxxx message to the bottom of every request, allowing us to see how quickly each request executes.

Global filters can also get access to the underlying RequestContext (from ASP.NET) and the HandlerData – Tinyweb’s internal structure used to identify the intended handler. If we wanted to create a list of every handler that was requested, we could use a global filter with HandlerData to do it:

public class RequestLoggingFilter
{
    public void After(HandlerData handler)
    {
        Logger.Log("Request completed to " + handler.Type);
    }
}

Finally, in terms of logging errors, this can be dealt with by supplying a delegate to Tinyweb.OnError which will receive the exception, the RequestContext and the HandlerData for the offending handler, like so:

protected void Application_Start(object sender, EventArgs e)
{
    Tinyweb.Init();

    Tinyweb.OnError = (exception, request, handler) =>
    {
        Logger.Log(exception + " error for " + handler.Type);
    }
}

See the documentation for more details about error logging with the OnError delegate.

In This Post

We saw how Tinyweb makes injecting dependencies into handlers (and filters) easy through its internal use of StructureMap. We then moved onto filters and saw how Tinyweb supports filtering at both the handler level and globally.

We then walked through a couple of demos showing how we can use global filters for logging and timing requests. Finally we saw a brief example of how error logging can be achieved using Tinyweb.OnError.

In The Next Post

We’ll see how to use the Spark view engine and take a closer look at model binding.

Tinyweb Series: 2 Building APIs

In the previous post in this series, I gave an introduction to the Tinyweb project and walked through a demonstration of how to get started.

We took a brief look at how handlers return content to the client, but in today’s post we’ll take a more in-depth look at how this works.

Returning Data From Handlers

In case you can’t remember, here’s a typical Tinyweb handler which processes HTTP GET requests at the URL /users/create and returns an HTML view:

public class UsersCreateHandler
{
    public IResult Get()
    {
        return View.Spark("Views/Signup.spark");
    }
}

The UsersCreateHandler is simply rendering a Spark view when a request is made to /users/create, providing the client with an HTML form to sign up. Let’s take a look at what else we can return from handlers.

The Result Class

To make handler result types more discoverable, you can use the static Result class to create them. This also serves the purpose of making any generic uses of the result types cleaner. Currently we have the following members in Result:

Result.None
Result.String
Result.Html
Result.File
Result.Json
Result.Xml
Result.JsonOrXml
Result.Redirect<T>

Let’s look at each one and see what it can be used for.

Result.None

No result? It may initially throw you, but the purpose of Result.None is to process a request without affecting the response body. Result.None exists to support two situations:

  • Filters that don’t wish to affect the response in any way.
  • Handlers that are to be treated in a fire-and-forget manner, where the response doesn’t matter.

We haven’t looked at filters yet, but here’s a contrived example for the fire-and-forget usage of Result.None:

public class ServerRebootHandler
{
    public IResult Get()
    {
        TheServer.Reboot();
        return Result.None();
    }
}

A caller just wants to signal that the server should be rebooted (don’t ask me why we’d want this, it’s contrived people) and not care about any result, so the handler returns Result.None so that it won’t waste time adding anything to the response body.

Result.String

We’ve seen this in some of the demos, and it’s fairly self explanatory. Result.String returns a raw string with an HTML content type, causing the browser to render any content as normal. It’s not something you’d use in an API or a web application necessarily, but it’s useful for diagnostics and situations where you just need to output simple things.

Result.Html

Result.Html is essentially the same as Result.String but it takes the data from a disk file instead of a raw string. Not especially exciting.

Result.File

Admittedly, this is becoming quite predictable now. Yes, Result.File allows you to send a file back in the response, causing a browser to show the familiar Save File dialog.

Result.Json and Result.Xml

Keeping with the theme of blatantly obvious, both these types do exactly what you might expect. Let’s see some more code:

public class UserDetailsHandler
{
    public IResult Get(int userId)
    {
        return Result.Json(UserService.GetById(userId));
    }
}

A request to /users/details/42 might return a JSON representation of the user object, like so:

{
  "ID":42,
  "Username":"Igor",
  "Age":62
}

Replacing Result.Json with Result.Xml would have the expected effect, and we’d be seeing beautiful XML in place of that horrible JSON. Erm, I think I got that right.

As a side note, you may be wondering about the parameter in the handler method. Tinyweb supports model binding of simple, complex and array types and will supply values to the handler that were found in the request or route data. We’ll look into this more in a future post.

Result.Redirect<T>

Stop – you missed one.

I’ll come to Result.JsonOrXml in a second, which will take us nicely into the discussion about building APIs with Tinyweb.

As I was saying – Result.Redirect<T> allows us to redirect from one handler to another. It kind of goes without saying that this is important, since otherwise there’d be no way for us to pass control between handlers to form more complex behaviours.

Result.Redirect<T> takes the handler type as the generic parameter, giving us some safety for future changes to handler names and such refactorings. There’s also a version that you can pass a raw URL to, if you so wish.

Quick example:

public class CuteKittensHandler
{
    public IResult Get()
    {
        GullibilityCount++;
        return Result.Redirect<RickHandler>();
    }
}

public class RickHandler
{
    public IResult Get()
    {
        return Result.Redirect("http://bit.ly/4kb77v");
    }
}

Don’t blame me, the signs were there all along.

Result.JsonOrXml

And finally we come to Result.JsonOrXml. The point of this type is to return the resource in a format that is preferred by the client. Clients typically specify this using the Accept header, but Tinyweb also allows Extension Overrides to make it easier.

Let’s look at the role Result.JsonOrXml plays in building JSON and XML APIs using Tinyweb.

Building APIs

Because Tinyweb enforces a development model where each handler can only support the basic HTTP methods for a single URL, we get lots of small, well defined handlers forming a system. This decoupling and focus on single responsibility works well for building web applications, but especially well for building HTTP APIs.

Let’s improvise another contrived example and build an HTTP API. We’ll assume the API is going to support a rich client in the browser, but also some legacy systems which require XML representations. In other words, we’ll be supporting both JSON and XML responses.

The API will allow us to manage a set of users via three resources, /users/add, /users/delete and /users/view for adding, deleting and viewing users respectively.

public class UsersAddHandler
{
    public IResult Post(User user)
    {
        UserService.Add(user);
        return Result.JsonOrXml(user);
    }
}

public class UsersDeleteHandler
{
    public IResult Post(int id)
    {
        var deleted = UserService.Delete(id);
        return Result.JsonOrXml(deleted);
    }
}

public class UsersViewHandler
{
    public IResult Get(int id)
    {
        var user = UserService.Get(id);
        return Result.JsonOrXml(user);
    }
}

Let’s have a look at each handler and see what’s going on.

First we have the UsersAddHandler which supports POST requests at /users/add. Any POST data that matches properties on the User object will be model bound automatically by Tinyweb.

The UsersAddHandler is pretty simple, it just creates a user by delegating to UserService.Add and then returns a representation of the new user back to the client.

Next we have the UsersDeleteHandler which is very much the same, supporting POST requests at /users/delete to remove users. This handler returns a representation of the true/false return value from UserService.Delete, indicating whether the user was deleted.

Finally, the UsersViewHandler returns a representation of the requested user at /users/view.

The Accept Header

As mentioned earlier, a handler that returns Result.JsonOrXml is specifying that the actual representation can be JSON or XML, depending on which is requested by the client via the Accept header. For example, if the UsersViewHandler is requested like this:

GET /users/view?id=42 HTTP/1.1
Accept: application/xml;q=0.8,application/json;q=0.7

Because the Accept header is preferring application/xml over application/json, Tinyweb will return an XML representation of the user. If it was requested with a preference for JSON over XML, the reverse would happen. Tinyweb defaults to JSON if no preference can be determined.

Extension Overrides

In addition to the Accept header, Tinyweb can be configured to use Extension Overrides which allow a URL extension to be used to control the preferred response type. For this to work, you’ll need to set AllowFormatExtensions to true during initialisation, like so:

protected void Application_Start(object sender, EventArgs e)
{
    Tinyweb.AllowFormatExtensions = true;
    Tinyweb.Init();
}

Now the same resource can be requested without the Accept header by appending either a .xml or .json extension to the URL, i.e. /users/view.json?id=42 or /users/view.xml?id=42. This makes debugging easier and some people prefer the more discoverable method of specifying response types in the URL.

In This Post

We looked at Tinyweb’s various response types and considered what they are useful for. In particular we saw how Result.Redirect<T> allows us to pass control between handlers in order to compose groups of handlers into more complex behaviours – albeit in a somewhat contrived example.

We then looked at how Tinyweb is suited to building HTTP APIs and looked at how Result.JsonOrXml allows us to defer specification of the response type to the client through the Accept header or through URL extensions.

In The Next Post

We’ll take a look at how Tinyweb tackles dependency injection with StructureMap and how we can use handler and global filters to extend the execution pipeline for things like logging and error handling.

Tinyweb Series: 1 Getting Started

Tinyweb is an open source project I started last November with the goal of creating a minimal, service-oriented web application framework. I’ve been committing to the project ever since and it has now reached a level of maturity I’m happy with.

Full documentation for the project was completed recently and I figure it’s time to write a how to series of posts that cover the most interesting aspects of the framework.

So here we are with the first instalment. My goal for part 1 is to explain the thinking behind the project and show you how easy it is to file –> new project.

What’s Tinyweb?

From the docs:

Tinyweb is a lightweight web framework for ASP.NET that embraces HTTP and aims to be ridiculously simple.

Approaching the project with a background in using the MVC pattern, my goal was to move away from the issue of fat controllers and provide less abstraction over the core functionality of HTTP.

In Tinyweb, the URL, or more precisely the resource is the starting concept. By resource, I mean a single entity addressable by its URL and able to respond to any of the standard HTTP methods.

The resource is just a simple class with methods for each HTTP method it wishes to respond to, for example:

public class SignupHandler
{
    IUserService _userService;

    public SignupHandler(IUserService userService)
    {
        _userService = userService;
    }

    public IResult Get()
    {
        return View.Spark("Views/Signup.spark");
    }

    public IResult Post(UserModel user)
    {
        _userService.CreateUser(user);
        return Result.Redirect<WelcomeHandler>();
    }
}

Because the SignupHandler has a single URL and can only respond to the core HTTP methods, a certain level of SRP is enforced by this model. Tinyweb encourages an application to be broken into separate resources that collectively form a coherent system.

Tinyweb leans more toward a service-oriented approach to building web applications, where every endpoint within the system has a well defined purpose and collaboration between endpoints is used to form more complex behaviours. This is particularly fitting for pure JSON or XML APIs and I’ll be covering some related features of Tinyweb later in the series.

Another underlying goal of Tinyweb is simplicity. The framework itself is small, with a tiny pipeline and simple conventions to save you having lots of configuration. Conventions aren’t concrete and can be overridden, but using Tinyweb should to be fun, easy and consistent.

File –> New Project

So, let’s see how we create a new project using Tinyweb.

We’ll need an empty project to start with, so go ahead and create a new ASP.NET Empty Web Application project in Visual Studio. Done it?

OK, next we need to install the latest version of Tinyweb using the wonderful NuGet. Open the Package Manager Console and cast this spell:

Install-Package Tinyweb

NuGet will go and grab the relevant assemblies and add them to your exciting new empty project. Once done, Tinyweb is installed and ready for us to start writing some code.

Fortunately Tinyweb doesn’t require you to add anything to the web.config. Instead, Tinyweb is initialised from within Global.asax. You won’t have one yet, so you’ll need to add a new Global.asax file to your project. After you’ve added it, initialise Tinyweb like so:

protected void Application_Start(object sender, EventArgs e)
{
    Tinyweb.Init();
}

That wasn’t too painful, was it? Tinyweb is now loaded and routes have been configured to the various handlers that were discovered. There are other things you can do at this point, but we’ll cover them later in the series. For now, this is all you need.

The Handler

All the required setup and initialisation is done, and we’re now ready to build our actual application. Since this is Tinyweb land, we need to think about the first resource our system will need. Given this is the introduction post, and I’m creatively numb, let’s be traditional. The first handler will respond to HTTP GET requests at /hello/world and respond with the message Hello World. Exciting huh? Just me then?

public class HelloWorldHandler
{
    public IResult Get()
    {
        return Result.String("Hello World");
    }
}

Pretty simple, but let’s break it down and understand what’s going on here.

The Handler Name

Firstly, notice how the class doesn’t implement any base or interface. A handler is a handler if it ends in Handler. Say that fast 10 times. When Tinyweb.Initis called, handlers are discovered by scanning for classes that end with the word Handler. There’s the first convention.

The first part of the handler name is significant too. Breaking it up into its constituent Pascal-cased words, the handler name is used to build the URL of the resource. Because our handler is named HelloWorldHandler, Tinyweb produces the URL /hello/world.

Had the handler been called HomeHandler, we’d have the URL /home, or YabaDabaDooHandler would be addressable at /yaba/daba/doo. There’s the second convention.

The Handler Method

Next we have the method itself. Tinyweb recognises four potential methods which mirror the underlying HTTP methods, i.e. Get, Post, Put and Delete. You can also have Before and After methods, but we’ll talk about those later in the series.

Notice how the method returns IResult. This is the interface used to represent a handler response. Handlers must have a return type of IResult to be properly discovered. Tinyweb supports a number of result types including Result.String, Result.Json and View.Spark and we’ll look at these in the next post.

Finally, the handler returns a value to the client by using the static Result class. Result provides access to the supported result types while View provides access to the supported set of view engine results. Tinyweb currently ships with support for the Spark view engine.

In This Post

I introduced Tinyweb – the minimal web framework that encourages the use of concepts from HTTP to build service-style applications using ASP.NET. I talked about Tinyweb’s core goal of simplicity and explained how Tinyweb makes use of conventions and discovery to keep your code as simple as possible.

We built an example application, demonstrating how to install, initialise and write our first handler. We then dug a bit deeper into the method used for generating handler URLs and looked at what a handler can do.

Until Next Time

If you want to dive in and have a play around, simply install Tinyweb from NuGet, check out the documentation and if you have any questions, I’d be happy to help.

Next time we’ll look at the different types of content that can be returned by a handler, and look specifically at some features which are aimed at building JSON/XML APIs.

The Zone

As programmers, the zone is something we are all aware of but something that we rarely explore. Yet we’ve all been there – totally focused and producing the best work we could have hoped for.

To some, the zone is seen as some kind of rare Zen state. Some think it’s a myth that doesn’t actually exist. Either way, it’s understandable that there are so many different opinions; it’s not an easy thing to objectively discuss.

But, what the hell – here’s what I think.

In actual fact, the zone is nothing to do with programming – though it is a term that’s used much more often in this context. Being in the zone is just a condensed version of:

  • Having a good understanding of the task
  • Feeling as though you have the dedication and skill to complete the task
  • Being able to concentrate
  • Feeling happy in yourself and your environment

These are not simple states; being able to concentrate might be a combination of a quiet atmosphere and a good music playlist, or perhaps a tidy desk and no interruptions. There are lots of subjective elements of each of these states, but none of them are inherently difficult to achieve.

If you understand exactly what you need to do, know how to do it, know that you actually want to do it and can remain focused, the zone comes quite naturally.

But I think we can simplify this into something more fundamental.

Back in college, I did not like mathematics at all. I enjoyed the application of concepts rooted in mathematics, but the study of abstract things on their own totally disengaged me. But don’t worry, I wasn’t a total failure – I did well in other subjects, and it’s no coincidence I enjoyed them more.

Enjoyment has wonderful side effects. It’s much easier to focus on something you enjoy. It also requires much less effort to develop skills in subjects you enjoy; they sometimes even appear to develop transparently. And fairly obviously, it’s easier to achieve happiness through doing things you enjoy.

This is nothing new:

Success in highest and noblest form calls for peace of mind and enjoyment and happiness which comes only to the man who has found the work he likes best.

– Napoleon Hill

If we are lucky enough to be working on something we enjoy, the points above all become side effects of the fact that we’re enjoying ourselves. If we’re struggling to find the zone, we should look for opportunities to make what we’re doing more interesting. This will improve the chances of being able to focus and finding the required inspiration.

If we don’t enjoy what we’re doing, it’s unlikely we’ll find the zone without a good amount of self discipline. Maintaining focus and dedication, and building understanding without the catalyst of enjoyment is the reason people tend to do worse at things they hate and better at things they love.

There isn’t just one zone, there are many zones each competing for our attention. It’s not a coincidence that those who can’t get into the zone are telling us about it on Twitter. In fact, they have found the zone. They’re in the zone of socialising, which is a pretty easy zone to get into since it’s very enjoyable, but is it the zone you want to be in?

The zone is not some unachievable state of Zen, reserved only for the enlightened ones. You don’t need to sit with your legs crossed, humming, waiting for it to bless you with the ability to do awesome things – you already have that ability.

The zone is just a fancy-ass way of describing the required focus and dedication you need to do something to the best of your ability. When you enjoy what you’re doing, these things happen much more naturally. When you don’t, you need to compensate with discipline, and your mileage certainly may vary.

The zone isn’t random and it isn’t a myth – you can create it as often as you like.

Sentiment Analysis Talk

Today I gave a talk about textual sentiment analysis at BarCamp Sheffield. Here’s a summary of the talk and links to the slides, demo and code.

Sentiment analysis is the process of analysing data to determine its sentiment, or mood. It’s an important area of research as it relates to improving things like customer satisfaction and making advertising more effective.

Sentiment analysis can add certain meaning to data and move us away from the simple keyword matching that we currently use. However, it’s a difficult problem to solve with around a 70% agreement rate between human analysers.

The simplest implementations tend to be things like bag of words where a collection of known positive and negative words are manually maintained and a subject is classified by calculating which collection has the most matches.

These word lists don’t scale well however. Much effort is needed to keep them up to date and deal with things such as misspellings and grammar errors. When you factor in context, which can often change the meaning, you’re left writing rules around the bag of words to capture those situations.

When you’re aiming to analyse data from a wide set of possible sources, the rules approach starts to fall short as the total number of possible words grows too large and problems such as including foreign languages cost you the entire effort all over again.

Instead we look to statistical solutions that help us deal with such large amounts of data. One such approach is naive Bayesian classification, which works by maintaining known classes of data (such as positive & negative) and calculating the combined probability that an input falls into each one.

The statistical approach also means that the problems mentioned above start to matter much less. Spelling errors and grammatical mistakes become part of the set and have a weighting like any other word – and the same applies for foreign language words.

Of course, seeding the classes with quality data then becomes the problem, and the effectiveness of the statistical approach does very much depend on the quality of the data used to seed it.

Some studies have been done that used data from sources such a movie reviews, which was known to be good or bad through the star rating. Unfortunately, such sources are too specific to a particular domain and tend not to perform well enough for more general analysis.

One possible source for mass amounts of data is Twitter, but the problem then becomes a matter of categorising a set of tweets into positive or negative in order to seed the algorithm. A fairly simple way to produce the two sets of data is to assume that all tweets containing a :) are positive and that all tweets containing a :( are negative.

Though there would be countless exceptions in a large set of data, it doesn’t matter too much as it would only be a problem if there were enough exceptions to affect the probability significantly.

The approach described is in production currently and producing good results. The set of seed data is fairly good with around 1 million tweets, but could be significantly bigger and consequently produce better results.

There are a number of real world applications of Bayesian classification that you’re probably already using, such as the spam filter. In addition, there are more sophisticated models that have been built on top of Bayesian classification and extend its application to fields like medicine. For further details, I recommend watching the 2010 Turing Lecture which goes into great detail about this subject.

If you feel like extending the algorithm, or you’re just curious to see how it works at a code level, you can find the code for the demo at https://github.com/martinrue/Sentan.

And finally, here’s a link to the slides (which are mostly condensed versions of what has already been said here).

http://portal.sliderocket.com/AQJJH/Sentiment-Analysis

ASP.NET - Thinking In Resources

A few months ago I wrote Tinyweb, an ASP.NET web framework which dictates an SRP approach to building web applications. Since then I’ve used Tinyweb for a few internal things and I’ve been happy with the direction it leads you in.

So, we’ve all heard enough times by now the benefits of the SOLID principles. In particular, we know that we should minimise the responsibility of a class, with the aim of having just one responsibility per class and consequently only one reason for that class to change.

That’s an interesting word – change. We often refer to new work on an existing system as change, but unless the new work involves modifying the way something worked before, it shouldn’t be change, it should be extension.

As you know, another SOLID principle tells us that code should be open for extension, but closed for modification. Usually this refers to being able to extend behaviour by subclassing and using polymorphism to effectively replace the old behaviour – but can’t OCP be more generally applied?

What about our architecture, project layout, working conventions? Have these been arranged to support extension or will a change require that we have to rethink these things in order to accommodate future changes?

How Tinyweb Helps

Tinyweb takes a rest-style approach to building web applications by enforcing that a handler can only handle the standard HTTP methods for a single URL. For example, if we have a UsersHandler (liken this to a controller in MSMVC parlance) we will have a /Users URL and will only be able to respond to the HTTP GET, POST, PUT and DELETE methods for this resource.

Where in MSMVC you might have an AccountController with all kinds of actions, Tinyweb dictates that every URL is a separate resource independent of all others and requires its own handler.

I think this helps in enforcing a certain level of granularity and responsibility. While you can’t really argue that a handler has single responsibility (since it might handle both GET and POST), it more broadly has the single responsibility of controlling interactions with that resource.

This is why the web has evolved so successfully – everything is ultimately just an addressable resource that can send you to other resources in some coherent way to achieve a goal. Adding new functionality simply involves deciding which new resource to introduce and deciding how it will integrate with the existing system.

User Signup Example

Let’s see this workflow in action by using a simple example. Let’s pretend we’re building some web based system that requires users to sign up for accounts. We’ll start with a generic user registration system.

public class UserRegisterHandler 
{ 
    public IResult Get() 
    { 
        return View.Spark("Signup.spark"); 
    } 
}

By creating a handler named UserRegisterHandler, I’m in effect creating a resource addressable at /User/Register which can support any of the standard HTTP methods. In this particular case, I’ve implemented the HTTP GET method to allow the resource to display a view for a potential user to submit their account details.

Still thinking in terms of resources, we should now consider which resource will handle receiving a user’s details and creating the account. For the purposes of this example, we’ll use the same resource. So, a GET request to /User/Register will get the user registration view and a POST request to /User/Register will create the user.

public class UserRegisterHandler 
{ 
    IAccountService _accountService;

    public UserRegisterHandler(IAccountService accountService) 
    { 
        _accountService = accountService; 
    } 
    
    public IResult Get() 
    { 
        return View.Spark("Signup.spark"); 
    } 
    
    public IResult Post(User user) 
    { 
        _accountService.Create(user); 
        return Result.String("Done"); 
    } 
}

I’ve made a couple of changes to the handler here. I’ve introduced a dependency on an IAccountService which will handle the user registration. I’ve also implemented the HTTP POST method which binds the POST data to a User object and passes that down to the account service to do its magic.

Let’s continue this pretentious silliness and imagine that we’ve just been informed of our next requirement. Apparently, our current handling of new users leaves a lot to be desired. We’ve been told that when new users sign up, they should be taken to a page that welcomes them and confirms their details.

Because we’re thinking exclusively in terms of the resources our system is composed of, the next question becomes: which resource do we need to introduce to support this extension?

We’ll create a UserWelcomeHandler, giving us a new resource addressable at /User/Welcome. Let’s assume that a client will pass us the ID of the user we’re welcoming when issuing a GET request to this resource.

public class UserWelcomeHandler
{
    IAccountService _accountService;

    public UserWelcomeHandler(IAccountService accountService)
    {
        _accountService = accountService;
    }

    public IResult Get(int id)
    {
        var model = _accountService.GetWelcomeDetails(id);
        return View.Spark(model, "Welcome.spark");
    }
}

The user ID is now being taken from the GET request and being passed to the account service to fetch a model that represents the welcome details for that user. The model can then be rendered to a view as normal.

The new requirement has been implemented by introducing a new resource and extending the original system. But there’s still a missing link between the two resources, and we’ll have to return to the UserRegisterHandler and modify it. Instead of just displaying “done”, we want it to delegate responsibility to our new /User/Welcome resource.

public class UserRegisterHandler 
{ 
    IAccountService _accountService;

    public UserRegisterHandler(IAccountService accountService) 
    { 
        _accountService = accountService; 
    } 
    
    public IResult Get() 
    { 
        return View.Spark("Signup.spark"); 
    } 
    
    public IResult Post(User user) 
    { 
        var userID = _accountService.Create(user);

        var url = Url.For<UserWelcomeHandler>(new { UserID = userID });
        return Result.Redirect(url);
    } 
}

With this change, the responsibility of UserRegisterHandler has been contained to dealing with the new account creation only. Satisfying our new requirement of welcoming the user has been implemented by introducing a new resource. We now simply move between the separate resources as required.

The Point

Although you could easily work this way with any framework, Tinyweb makes it more explicit with its opinionated approach to what a handler can do. You’re forced to think about separate resources and how they should collaborate to form a coherent system – and ultimately, this feels like a very natural and intentional way to build applications.