Monday, October 22, 2012

Post Web.NET Europe

I attended and spoke at Web.NET Europe in Milan over the weekend. This was only my fourth full day- or more conference (Techdays Belgium, TechEd Berlin and HTML5 WebCamps), but it was undoubtedly the best one so far.

The quality of the sessions was definitely not inferior to those of bigger conferences. I especially enjoyed the talks on SignalR, OAuth and scaling data (I included some of my notes below). The strength of this conference doesn't lie in the exceptional speakers or sessions though, but in its cozy size and the type of attendees it attracts. Being hosted on a Saturday, you already preclude all the developers who merely think of technology as a job. And when you put together those who care about what they do, and want to get better at it, good things happen. This was the first conference where I was able to talk to such a wide range of people - I guess I even spoke to more than six different nationalities - and where it didn't feel awkward one bit. What helps in attracting such a variety of people, is that the conference is practically free and survives on donations from sponsors and attendees, making it very affordable even if you fly in from outside of Italy. Freelancers also seemed to appreciate that it was on a non-billable day.

In short, I really enjoyed the experience, and it might be just so that weekend conferences make for better conferences. Congratulazioni a Simone Chiaretta and Ugo Lattanzi for making this happen. I'm already looking forward to the next edition.




"Real Time" Web Applications with SignalR in ASP.NET (@A_Giorgetti)

Last year I did a talk on WebSockets at HTML5 WebCamps and although I built a few things that worked, the real-time web in the wild was still very much a mess. SignalR now abstracts all that clutter for you, and provides you with a seemingly clean infrastructure and simple API. Too bad the use for real-time web applications is rather limited in my world - stock ticker or chat application anyone?

OAuth-as-a-service using ASP.NET Web API and Windows Azure Access Control (@maartenballiauw)

I had my first serious look at OAuth in this session, and while it's probably indispensable for public API's, it doesn't seem that trivial to implement. Azure ACS could make this easier though.

Slides

Scaling without going crazy (@Ayende)

This was one of the talks I really looked forward to, and it didn't disappoint one bit. I never got to do anything with big data (data that can't fit on one machine), but there are really interesting problems and trade-offs in that space - CAP theorem etc.

Some quotes worth giving more thought:
  • Caching often just hides a problem.
  • How is Facebook consistent? It's personally consistent.

Sunday, October 21, 2012

Slides and code from my Web.NET Europe REST and ASP.NET Web API session

I just returned to the hotel after attending and speaking at Web.NET Europe 2012. There were multiple sessions on ASP.NET Web API today, and I was responsible for delivering the first one of the day. Being first, and to avoid overlap with others, I tried to lay a solid foundation by focusing on the REST and ASP.NET Web API basics: resources, identifiers, representations, verbs and hypermedia.

More people than I expected showed up for my talk; somewhere around 50 to 70 attendees, I guess. I think it was fairly well received; after 25 votes, the session rating stands at 90%. It's great to see your preparations have such a fruitful outcome.

I still have a few thoughts on the conference to materialize, but for now, I uploaded the slides (they're also embedded below) and hosted the source code on GitHub.


Monday, October 15, 2012

Commands with dependencies

Also read: Separating command data from logic and sending it on a bus

Yesterday I wrote about an architecture which limits abstractions by solely introducing commands and queries. I shared a dead simple variation of this pattern, the advantages I experienced, and how I could still unit test the controller if I wanted to.
At the end of that post I wondered how I would be able to test commands in isolation; suppose the implementation doesn't use a database this time, but a hairy, too low-level, third party webservice.

Right now, the input arguments are inserted via the constructor, but this leaves no room to inject dependencies. That is, if we don't want to do awkward stuff with our Dependency Injection framework, and don't want to resort to property- or method injection.
public class WithdrawAmountCommand : Command
{
    public WithdrawAmountCommand(string user, int amount)
    {
        if (string.IsNullOrEmpty(user))
            throw new NullReferenceException("user");

        User = user;
        Amount = amount;
    }

    public string User { get; private set; }

    public int Amount { get; private set; }

    public override void Execute()
    {
        // Implementation
    }
}
One way to enable injecting dependencies could be to separate the command in two parts; the handler, and the data.
public interface ICommandHandler<in TCommandData> 
{
    void Execute(TCommandData commandData);
}
Now we could rewrite the WithdrawAmountCommand. One class contains and verifies the input data...
public class WithdrawAmountCommandData
{
    public WithdrawAmountCommandData(string username, int amount)
    {
        if (string.IsNullOrEmpty(username))
            throw new NullReferenceException("username");

        Username = username;
        Amount = amount;
    }

    public string Username { get; private set; }

    public int Amount { get; private set; }
}
...while the second class actually acts on the data.
public class WithdrawAmountCommandHandler : ICommandHandler<WithdrawAmountCommandData>
{
    private readonly IAccountWebservice _accountWebservice;

    public WithdrawAmountCommandHandler(
        IAccountWebservice accountWebservice)
    {
        _accountWebservice = accountWebservice;
    }

    public void Execute(WithdrawAmountCommandData data)
    {
        _accountWebservice.Invoke(data.Username, data.Amount);
    }
}
Testing commands in isolation is now straight-forward.
[TestMethod()]
public void Execute_should_invoke_webservice_with_correct_arguments()
{
    var accountWebService = new Mock<IAccountWebservice>();

    var command = new WithdrawAmountCommandHandler(accountWebService.Object); 
    command.Execute(new WithdrawAmountCommandData("JefClaes", 25));

    accountWebService.Verify(aws => aws.Invoke("JefClaes", 25));
}
Don't forget that the controller also needs to accommodate this change.
public class HomeController : Controller
{
    private readonly IQueryHandler _qryHandler;
    private readonly ICommandHandler<WithdrawAmountCommandData> _withdrawAmountCommandHandler; 

    public HomeController()
    {
        _qryHandler = new QueryHandler();
        _withdrawAmountCommandHandler = new WithdrawAmountCommandHandler(new AccountWebservice());
    }

    public HomeController(
        IQueryHandler qryHandler,
        ICommandHandler<WithdrawAmountCommandData> withdrawAmountCommandHandler)
    {
        _qryHandler = qryHandler;
        _withdrawAmountCommandHandler = withdrawAmountCommandHandler;
    }

    [HttpPost]
    public ActionResult Foo(string user)
    {
        _withdrawAmountCommandHandler.Execute(new WithdrawAmountCommandData(user, 25));

        var totalAmount = _qryHandler.Execute<int>(new TotalAmountQuery(user));

        if (totalAmount < 0)
            return RedirectToAction("Warning");

        return RedirectToAction("Index");
    }
}
I'm not all that happy with how this approach will bloat my controller in the future to be honest. To smooth out this friction, I could - like in the previous post - introduce a dispatcher, which serves as an intermediary for the commandhandlers.

Integration testing wasn't an option in this scenario, so I had to introduce some extra abstractions just to facilitate unit testing. Although this particular variation still holds lots of advantages I talked about in my previous post, there's already a lot more boilerplate and some more complexity.

I'm going to give this topic some more thought. Care to share yours?

Sunday, October 14, 2012

Commands, queries and testing

Also read:
  1. Self-contained commands with dependencies
  2. Separating command data from logic and sending it on a bus
We need abstraction, but the amount of abstraction we really need depends, and should be assessed on a case-by-case basis. It seems advisable to grow abstractions, and to introduce them gradually.

That being said, in this post I want to talk about an architecture that tries to limit abstractions to solely commands and queries.

It all starts with two small pieces of infrastructure: a command and a query. A command performs an action, and can change state, while a query should only return data, and not alter any state; basic command and query separation.
public abstract class Command
{
    public abstract void Execute();
}

public abstract class Query<T>
{
    public abstract T Execute();
}
Now imagine, we are doing something with accounts, and we want to have a command that can withdraw money from an account, and a query that returns the total amount available on an account. The assumption is that we're only talking with a database.
public class WithdrawAmountCommand : Command
{
    public WithdrawAmountCommand(string user, int amount)
    {
        if (string.IsNullOrEmpty(user))
            throw new NullReferenceException("user");                
    
        User = user;
        Amount = amount;
    }

    public string User { get; private set; }

    public int Amount { get; private set; }

    public override void Execute()
    {
        // Implementation
    }
}
We inherit from the Command class, and pass in its input arguments via the constructor. We put our actual implementation in the Execute method override. For the query, we do something very similar.
public class TotalAmountQuery : Query<int>
{
    public TotalAmountQuery(string user)
    {
        if (string.IsNullOrEmpty(user))
            throw new NullReferenceException("user");
    
        User = user;
    }

    public string User { get; private set; }

    public override int Execute()
    {
        return 100; // Should be an actual implementation
    }
}
Now, if we would use this in ASP.NET MVC, we would end up with clean and compact controllers. Have a look at the action Foo, which first withdraws 25 euros, to then redirect to a warning action if the balance is negative, or to redirect back to the index action when it's positive. Very readable, right?
[HttpPost]
public ActionResult Foo(string user)
{
    new WithdrawAmountCommand(user, 25).Execute();

    var totalAmount = new TotalAmountQuery(user).Execute();

    if (totalAmount < 0)
        return RedirectToAction("Warning");

    return RedirectToAction("Index");
} 
There are several advantages I experienced while applying this pattern. First, there are less layers of abstraction, while not neglecting readability nor maintainability. In a more conservative approach, I would end up with an account repository, abstracting my data access, and probably also an account service, abstracting my business logic. This repository, and service, would have multiple methods, which probably solve related, yet different problems. I would have to wade through all the methods in these classes to find the operation that is relevant for me.

When you model each operation as a class on its own, you define it more explicitly. And you're able to adhere to the Single Responsibility principle even more. Practically, it's now also easier to locate an operation in the codebase by just looking at the solution explorer.

One last, but not unimportant, advantage I see, is that it gets easier to group queries and commands per functionality and context.

We could test the example above against the actual implementation, and I don't see anything wrong with that per se, but it isn't always that practical; the setup of your queries can be heavy and complex, performance of your tests might be suffering etc.. One technique would be to create an interface per query and command and inject them, but that seems cumbersome, and ceremony heavy, and that isn't something I'm willing to do.

Something in between could be introducing a Command- and QueryHandler.
public interface ICommandHandler
{
    void Execute(Command command);
}

public class CommandHandler : ICommandHandler
{
    public void Execute(Command command)
    {
        command.Execute();
    }
}

public interface IQueryHandler 
{
    T Execute<T>(Query<T> query);
}

public class QueryHandler : IQueryHandler
{
    public T Execute<T>(Query<T> query)
    {
        return query.Execute();
    }
}
These could be injected into the controller, and be used as an intermediary to execute queries and commands for us.
public class HomeController : Controller
{
    private readonly IQueryHandler _qryHandler;
    private readonly ICommandHandler _cmdHandler;

    public HomeController()
    {
        _qryHandler = new QueryHandler();
        _cmdHandler = new CommandHandler();
    }

    public HomeController(
        ICommandHandler cmdHandler, IQueryHandler qryHandler)
    {
        _cmdHandler = cmdHandler;
        _qryHandler = qryHandler;
    }

    [HttpPost]
    public ActionResult Foo(string user)
    {
        _cmdHandler.Execute(new WithdrawAmountCommand(user, 25));

        var totalAmount = _qryHandler.Execute<int>(new TotalAmountQuery(user));

        if (totalAmount < 0)
            return RedirectToAction("Warning");

        return RedirectToAction("Index");
    }
}
This technique would make it possible, and easy, to use stubs or mocks for queries and commands.
[TestMethod()]
public void Foo_should_withdraw_25_euros_from_the_account_of_jef_claes()
{
    var cmdHandler = new Mock<ICommandHandler>();
    var qryHandler = new Mock<IQueryHandler>();

    var controller = new HomeController(
        cmdHandler.Object, qryHandler.Object);

    controller.Foo("JefClaes");

    cmdHandler.Verify(
        h => h.Execute(It.Is<WithdrawAmountCommand>(
            c => c.Amount == 25 && c.User == "JefClaes")));
}

[TestMethod()]
public void Foo_should_redirect_to_a_warning_page_when_amount_negative()
{
    var cmdHandler = new Mock<ICommandHandler>();
    var qryHandler = new Mock<IQueryHandler>();

    qryHandler
        .Setup(h => h.Execute<int>(It.IsAny<TotalAmountQuery>()))
        .Returns(-1);

    var controller = new HomeController(cmdHandler.Object, qryHandler.Object);
    var result = (RedirectToRouteResult)controller.Foo("JefClaes");

    Assert.AreEqual("Warning", result.RouteValues["action"]);
}
I don't think this should be introduced as an application-wide thing necessarily, but it could only be used when testing the actual implementation becomes hard or awkward.

But what if I need to inject dependencies into my commands or queries for testing - there is more to it than a database? I gave that some thought as well, and it seems inevitable to introduce extra abstractions, and make changes to the concepts discussed above; I'll publish these tomorrow.

I've been entertaining lots of ideas on this topic lately, and I'm curious to hear yours.

Wednesday, October 10, 2012

Out with YSLOW, in with PageSpeed Insights

My alarm clock goes of at 6:20; my fingers are able to locate the snooze button without me having to open my eyes. To my annoyance, the aggravating noise of the alarm returns ten minutes later. I need to get up this time. With nearly opened eyes, I glance at the time, and press the dismiss button to silence the alarm for good.
I open my eyes; light is already coming through the curtains; this shouldn't be. My heart skips a beat; I'm wide awake, and look at the clock in awe: 7:55. I overslept.

I unplug my phone from the charger next to the bedside table, open the browser, and navigate to the national railway's website. The site seems to be slow today, it took seconds to download the first page, and now the screen stays blank, waiting for the rendering to finish. When the page is finally drawn, I notice they deployed a new version overnight. On each subsequent page visit, I'm annoyed. This shouldn't take this long; I don't have time for this right now.

Arriving at work, later than usual, I visited the site again using my desktop. I'm always intrigued by slow websites, especially when built by a big public company for a large audience. I see them as a cheap opportunity to learn from their mistakes, so I don't have to make them myself.

By having a shallow look at the source and opening the network tab, I can already spot a few things amiss: the browser needs to download 2,11MB from 80 different resources, ASP.NET Webforms, viewstate, ridiculous id's, misplaced script tags, and non-bundled and non-minified resources.

To get an in-depth analysis, I always turned to YSLOW, but I had been a bit dissappointed by the amount of innovation there over the last few years. An extra tool I used sporadically was Google PageSpeed online, which I found to report more granular results, and to also test for more recent findings in web performance research. To my surprise, I discovered that this tool is now also available as a Chrome plug-in, meaning I can also use it for local sites.



I'm not sure when this became available though. When I look at the trend, it seems that PageSpeed Insights is rapidly becoming the new favorite.



Even the Chrome webstore reports 177k users for the PageSpeed Insights plug-in, while the YSLOW plug-in only has 159k.



Maybe I'm preaching to the choir, but I hope to have introduced at least one person to, what was for me, a new tool.

Monday, October 8, 2012

Côte d'Opale

The girlfriend, me and another couple, returned from a short weekend at the French Opal Coast yesterday evening. Although we only planned this trip a  week in advance, we still failed to anticipate how erratic the weather can be in October; setting up camp in the dark, on a sloughy underground, with a soft drizzle on your back, isn't my idea of fun after a long day at work. The next morning, with destination Cape Blanc Nez, we drove over coastal routes between vast green fields, towards clearer skies. Passing white cliffs of clay and untouched beaches, we eventually halted at the obelisk commemorating the Dover Patrol for a while. Here you can clearly see the English coast on the other side of the canal; no wonder this spot was strategically ideal to safeguard the canal during World War I. Differing from the main route, we discovered the ramshackle remainder of a bunker. I think it's fascinating how quickly something what once played an important role in our history, can lose its prestige, and be seen for what it is: a massive block of concrete.

I honestly was taken aback by the beauty of the Northern French coast. I had always unjustifiably ignored this area, and now I will definitely have to revisit.

Sunday, before leaving, we visited a local bric-à-brac. Just before returning to the car, my girlfriend spotted an antique camera satchel, which she thought would make a unique accessory - you know how girls are, right? The woman behind the stand wouldn't let it go without the camera though, and asked too much for both, so we strolled on. Passing the same spot a few minutes later, she inquired how much we wanted to give her for it. Mistakenly, my girlfriend said dix-cinq (ten five) instead of using the more correct quinze (fifteen). The woman understood this as dis cinq (how about five), and doubled it to ten. Sold! And that's how my girlfriend saved herself five euros without even having to haggle.




Thanks to our companion Lars Oliviers for letting me put his pictures in this post.

Sunday, October 7, 2012

On job titles

It didn't take long before I noticed how little job titles mean. In my first job, you were assured to be granted a fancy title after only having acquired a minimum seniority, if you knew how to play the game. A more important sounding job title was HR's default bribe that often kept people from leaving for greener pastures, for a short while. But even after being upgraded from a stable cleaner to a Senior Barn Hygiene Technician, you're still cleaning shit though.

It goes without saying that I grew a healthy aversion from the hypocrisy of job titles pretty early on. They are nothing but easy incentives to provide volatile satisfaction, and are mostly worth just as much as it costs your company to grant them.

I always believed that the title you carry is rather meaningless. Everybody knows of a senior developer, technical lead, or architect, you wouldn't go to with any remotely technical question. Then again, I also know of people who can't be bothered to bargain another title, but have an extensive skill set, and can carry a project to the finish line. Without them, projects would have crashed and burned before lift off.
How people perceive you isn't something that can be enforced by a title, it's the result of your everyday actions. When you display mastery in what you love doing, people will take notice, and the word will spread like a wildfire. Eventually, work that you love doing will come to you, regardless of your job title. People want you to be on their team, because they care about what you bring to the table, not about what your job title is.

While I still stand by this view, it might be a bit too naive. Job title dynamics differ from company to company, and need to be examined carefully on a case-by-case basis. For example, in the classic enterprise, a title can influence your job substantially. There, when assembling a team, management often doesn't see an individual, but they see a resource playing a role. There, your reputation doesn't always have the chance to precede itself, but your title does. It would be a damn shame if such a small detail, a few words on a piece of paper, would regularly put you off to a bad start. Each organization also has a distinct opinion on what a certain title entails. It's worth studying these subtleties to be able to pick one that comes closest to what you want to do.

It's what you do that defines you, not your title. Yet, it's often indivertible to play along; titles can serve as a means to an end.

I'm interested in hearing your opinion. Do you think they are important, or do you just play along? Have you ever regretted not caring?

Bonus: relevant Futurama scene.