The team I was in consisted of me, Tomek Augustyn, Patrik Spathon and Pebbles Lim. Tother we came up with the idea to build a multiplayer version of the classic game pong, but using motion detection to control the game. We named the game Spong:

Each player runs the game from his web browser, which will access his web cam using WebRTC. The motion detector analyzes the video stream and detects where the most amount of movement is, this gives us a coordinate on the screen. The Y part of this coordinate is used to control the position of the players’ paddle. You can see this in the image above where the cross points out where i just moved my hand. Each players’ movements is sent to the other player via a Node.js/Socket.IO relay server.

To summarize Protothon #2 I must say that I was really impressed with all the applications presented by the different teams. It was one intense day, but a lot of fun! I am looking forward to attending again in the future.

First, we need a configuration file for the nginx site. If you haven’t already got nginx installed, install it (sudo apt-get install nginx).

/etc/nginx/sites-enabled/mvc:

server {
    listen   80;
    server_name mvctest.sourcecodebean.com;
    root  /home/peter/MonoMvcDeploy/;

    location / {
      root /home/peter/MonoMvcDeploy/;
      index index.html index.htm default.aspx Default.aspx;
      fastcgi_index /Home;
      fastcgi_pass 127.0.0.1:8000;
      include /etc/nginx/fastcgi_params;
    }
}

Type “sudo service nginx reload” to reload the configuration. Browsing to the site should give you a fastcgi error since there is no fastcgi server listening on 127.0.0.1:8000 yet. So far this is a good thing and shows that your configuration is correct.

Next we create a start script for our fastcgi server.

/home/peter/startmvc:

#!/bin/bash
source ./monoenv.sh
fastcgi-mono-server4 /applications=/:/home/peter/MonoMvcDeploy/ /socket=tcp:127.0.0.1:8000

This is pretty straigt forward, the only thing that might be a bit confusing is this part “/:/home/peter/MonoMvcDeploy/”. This means that we want to map the URL / to the application in /home/peter/MonoMvcDeploy/. This allows us to run several applications in the same fastcgi server on different URLs.

Now try running the script and browse to your site, our sample MVC site should appear!

The last step is to create a upstart script to have our application start automatically at system boot

/etc/init/mvc.conf:

#!upstart
description "sionmailer web"
author      "peter"

start on startup
stop on shutdown

respawn

script
    echo $$ > /var/run/mvc.pid
    exec sudo -H -u peter /home/peter/startmvc 2>&1
end script

pre-start script
    echo "[`date`] (sys) Starting" >> /var/log/mvc.sys.log
end script

pre-stop script
    rm /var/run/mvc.pid
    echo "[`date -u +%Y-%m-%dT%T.%3NZ`] (sys) Stopping" >> /var/log/mvc.sys.log
end script

Save the config file and start the site: service mvc start.

All done, your site is being served by nginx/fastcgi-mono-server4!

I wanted to add a live notification function to the chat, as soon as someone is typing, three dots should appear next to the user’s name. This means that as soon as the user starts we need to send a message to the server, this message is then broadcasted to all the connected clients. To not flood the server and the users, maximum one message per second should be sent.

Keydown – time since last message >= 1 second, or this is the first keydown in the sequence => send message
Keydown – time since last message < 1 second => do nothing

There is a built in method called Throttle that does almost this, we could use it, but then the first keystroke would get delayed and I did not want this. So being a beginner at RX I struggled for a while trying to get to where I wanted. I came up with a solution that did what it I wanted, but it was not so elegant. Then I found this post on StackOverflow, with a solution by Sergey Aldoukhov that solved the problem in a very elegant way, so I just decided to use it instead. Sergey had created an extension method called OneInTime, this is the code:

1. Rx.Observable.prototype.OneInTime = function (delay) {
2.     return this
3.         .Take(1)
4.         .Merge(Rx.Observable.Empty().Delay(delay))
5.         .Repeat();
6. };

So what does this mean? Take(1) is the simple part, we take 1 event from the stream. The merge expression is used to merge multiple IObservable streams into single IObservable stream. Each value on the source streams is projected into the result stream until all source streams complete. The Repeat method with no argument will repeatedly sub­scribe to the same observable collection indefinitely. So by taking one, merging with the delayed empty stream and then calling Repeat(), we take one event from the stream, and then skips all the events during the next second. After one second we repeat. Exactly what we wanted to achieve!

And this is how I would use it in the chat (#msg is the text input):

1.  
2. $("#msg").toObservable("keypress") // Create an observable from the keypress event
3.   .OneInTime(1000)
4.   .Subscribe(function () { chat.userTyping(); });
5.  

Pretty neat right?

The code is live at http://signalrchat.apphb.com/ and you can find the source on GitHub.

You find it here: http://signalrchat.apphb.com/

And you can find the source on GitHub: http://github.com/moberg/SignalRChat

• SignalR.Server – .NET code running on IIS
• SignalR.Js – A SignalR client in javascript
• SignalR.Client – A SignalR client in .NET. Useful for communicating with a SignalR server from, for example, a Windows Phone application.

SignalR is using long polling as a method to keep its http connections open. In the future support for WebSockets is going to be added as well (a guess would be when .NET 4.5/IIS8 is released, it will have support for WebSockets).

Let me show you how simple it is to create a chat server. First start Visual Studio and create a ASP.NET MVC3 application. When you have created your project you want to add SignalR from NuGet, so open up the NuGet manager and search for SignalR. You need the SignalR.Server and SignalR.Js packages.

When SignalR has installed we need to create the actual server, so lets add a new class, MyConnection. This class will handle the asynchronous communication with the clients:

To route the traffic to MyConnection we need to modify Global.asax slightly:

And the last part, the UI. Put this into your Home/Index.cshtml view:

Alright, that should be all. Compile and run it! You can test out my chat live over at AppHarbor:

http://signalrchat.apphb.com/

https://chrome.google.com/webstore/detail/lffoakndkbfaoglgbnaagjglhhlapdnk?hl=sv&hc=search&hcp=main

Comet – using browser connections

Comet is a web application model in which a long-held HTTP request allows a web server to push data to client browsers, without the browser explicitly requesting it. It works the way that the web browser requests an url from the server, and the server deliberately keeps it open, allowing it to work as a stream of data between the server and the client web browser. In this stream the web server can push content to the client.

Keeping connections open for such a long time is not how HTTP requests was intended to be used, so a lot of people have been describing this as a hack. The biggest problem with Comet has been that the HTTP 1.1 specification states that a web browser should not have more than two simultaneous connections to a web server. By using Comet, one of these connections would always be held open for push notifications. Only having one available connection could limit the browser. An example could be that the browser may be blocked from sending a new request while waiting for the results of a previous request while loading a series of images. Most sites solved this by creating a separate sub domain for the real time communication. Also, getting Comet to work properly in all web browsers isn’t at all trivial. So what other options are there?

Comet – using Flash sockets

Flash sockets is based on the same idea as Comet. On the server side it is very similar to the regular use of Comet, but on the client side the connection to the server is kept open by using a Flash Socket running in a flash application. Since the HTTP connection is opened by Flash it will work the same way in all web browsers, but the downside is of course that it requires Flash, so many mobile browsers will not be able to use it. The Flash socket implementation is considered as more stable and not as much as a hack as the browser Comet implementation. However, it is considered a temporary solution until most web browsers have implemented support for WebSockets.

WebSockets – The replacement for Comet

WebSockets is a technology for providing bi-directional, full-duplex communications channels, over a single TCP socket and is supposed to be able to replace the different Comet solutions that exists today. The API is being standardized by the W3C and is currently implemented in Chrome 4+ and Safari 5+. It is also implemented in Firefox and Opera, but disabled by default. As usual, Internet Explorer is lagging behind and no support for WebSockets exists as of today. Maybe in Internet Explorer 10, who knows… So it will be a while until WebSockets are so widely accepted that we can only rely on WebSockets.

On the server side

To allow for Comet connections the web server needs to support long lived HTTP connections. Most web servers were not built for this, so implementing Comet on a web server such as IIS can be a bit of a challenge, especially when scaling to lots of concurrent users.

Holding lots of concurrent connections open is something that Node.js is very good at (I blogged about Node.js a few weeks ago), and not supprisingly there are many Comet notification servers built on it. The two most popular implementations seems to be Juggernaut and Faye. Lets get into a crash course in how to start using Juggernaut.

Juggernaut

Juggernaut is a push notification server for WebSockets with a easy fallback to Flash sockets if the clients web browser does not support it. Getting started with Juggernaut is very easy, I got my server up running in just a few minutes. Let me show you how to do it on OSX.

First, if you don’t already have Homebrew (a Unix package manager for OSX) installed, go ahead and install it:

$ curl -LsSf https://github.com/mxcl/homebrew/tarball/master | sudo /usr/bin/tar xvz -C/usr/local --strip 1


Now install Node.js, Redis (key/value data strore server, the Juggernaut server and the Juggernaut gem (if you want the Ruby support). Follow the instructions for each package.

$ brew install node
$ brew install redis
$ npm install juggernaut
$ gem install juggernaut


Now start Redis and Juggernaut:

$ redis-server &
$ node ~/node_modules/juggernau/server.js &


Juggernaut is by default hosted on port 8080 and it should now be possible to browse to http://localhost:8080/application.js. This is the javascript that Juggernaut clients should load in order to communicate with the server.

Now lets create an HTML file, jugtest.html, and host it on a local web server:

Also, let’s create a simple Ruby script, test.rb, to send notifications:

Everything should be setup now, let’s browse jugtest.html, my webserver runs on port 3000, so for me that is http://localhost:3000/jugtest.html. Nothing shows up in the web browser, but in the terminal running Juggernaut we should be able to see that one client has connected. Lets run the ruby script:

$ ruby test.rb


The message shows up in the web browser, it works!

As you can see getting started with push notifications using Juggernaut is very easy. If you have any experience with other push notification servers, please leave a comment, it would be interesting to hear your experiences!

The fact is that Javascript is a very powerful language, unfortunately it has had a bad reputation for many years. I admit, for a long time I also looked at JavaScript as a second-class citizen in the programming world. A programming language used only to glue together HTML pages, while the heavy lifting was done on the server side in C#, Java, Ruby or in any other “real” language. However, my view of Javascript has drastically changed during the last few years. The language have “grown up”, and by that I don’t really mean the language itself, instead I am thinking about the libraries and tools available for Javascript, such as jQuery, JSON, Node.js, and HTML5. jQuery was a major game changer on the client side and now we have Node on the server side.

Node is a low level framework for building high performance web applications. It contains of an interpreter based on Google’s V8 and a framework library. HTTP is a first class protocol in Node and it is very easy to get a web server up running. The main difference from traditional frameworks is that Node is event driven (asynchronous). While most webservers use synchronous thread pool based request handling, Node server will only run one event loop which will handle all incoming requests using callbacks. Asynchronus web servers are proved to be very fast, for example the Nginx and Lighthttpd web servers, and Node is not an exception.

Let me show you what the simplest web server in Node looks like:

Running the program will start a web server listening on port 1234 and visiting http://localhost:1234 will show a “Hellow World!” message to the visitor.

The main difference when writing code for Node is that you have to understand is that blocking IO should be avoided. Everything runs in parallell except your code, writing blocking code will prevent Node from serving other requests. This is an example of writing blocking code:

The above example listens to two urls http://localhost:1234 and http://localhost:1234/longrun. When first visiting / it loads fast. Loading the /longrun takes 10 seconds as expected (think of this as database query or some other IO operation that takes long time), but it also causes Node to block and not serve new requests until /longrun has completed. To avoid this you should use non blocking IO at all times. By doing this, Node will be able to process other requests while waiting for the request to complete.

For a more in depth introduction to Node I can recommend the short book “The Node Beginner Book” and also the blog post “Understanding the node.js event loop”

To get started with Node I suggest you head over to Github and follow the intallation instructions to install Node and npm (the package manager for Node) https://github.com/joyent/node/wiki/Installation.

To install it on ubuntu type:

sudo apt-get install apache2-utils

Once installed we can use it to create an htaccess file.

htpasswd -c -b /path/to/htpasswd NewUser NewPassword

Now we need to add one block to the nginx config. Bellow is the config for this site, the part in bold is what needs to be added.

server {
    listen   80;
    server_name sourcecodebean.com;

    index index.php index.html;
    root /path/to/web/root;

    location ^~ /secret-dir/ {
        auth_basic            "Restricted";
        auth_basic_user_file  /path/to/htpasswd;
    }

    location / {
        try_files $uri $uri/ /index.php?q=$uri&$args;
    }

    location ~ \.php$ {
        fastcgi_split_path_info ^(.+\.php)(/.+)$;
        include /etc/nginx/fastcgi_params;
        fastcgi_pass  127.0.0.1:9200;
        fastcgi_index index.php;
        fastcgi_param  SCRIPT_FILENAME  /path/to/web/root$fastcgi_script_name;
    }
}

Woho! All done!

When I first read about AppHarbor I got the impression that is was running ontop of Microsoft Azure, which turned out to be all wrong. AppHarbor is running in the Amazon Cloud on EC2 instances. When it comes to databases AppHarbor provides access to MySQL and MSSQL. Interestingly they recommend users to use MySQL:

“we expect to be able to offer MySQL on faster hardware and with more redundancy than SQL Server at the same price point. If you are planning to build an app on top of AppHarbor and have the option, we recommend you go with MySQL.”

Another interesting choice is that they have chosen Nginx as their proxy/load balancer.

Ok, let me show you how easy it is to create a simple ASP.NET MVC 3 application and deploy it on AppHarbour The first step is to go to appharbor.com and register an account. Once created you will be able to create your first app:

Give your application and press create. You have done all the configuring you need to do at AppHarbor.

Lets create a MVC 3 project with unit tests:

Make sure your project builds and that the tests passes. Also make sure you have Git installed, if not you can fetch it from here. Now open a shell and cd into the folder where you created your application.

First we need to configure git with your name, the email you used to register at AppHarbor and last the git postBuffer size:

PS C:\dev\appharbor\MyCoolApp> git config --global user.name SourceCodeBean
PS C:\dev\appharbor\MyCoolApp> git config --global user.email mail@sourcecodebean.com
PS C:\dev\appharbor\MyCoolApp> git config --global http.postBuffer 52428800

After this we initiate the git repository:

PS C:\dev\appharbor\MyCoolApp> git init
PS C:\dev\appharbor\MyCoolApp> git add .
PS C:\dev\appharbor\MyCoolApp> git commit -m "initial commit"

And when this is done we add AppHarbor as a remote repository:

PS C:\dev\appharbor\MyCoolApp> git remote add appharbor https://moberg@appharbor.com/mycoolapp-1.git

We are now set to push our code onto AppHarbor. To push it just type:

PS C:\dev\appharbor\MyCoolApp> git push appharbor master

We should now be able to see the project building:

Hopefully it built successfully. A problem I ran into was that I had ASP.NET MVC 3 RC installed and AppHarbor had the RTM version installed, this caused my first attempt to build my project to fail. After upgrading my local version and fixing the project I pushed a new version that built without problems.

We can now browse to the site (yay! that was way easier than setting up IIS manually):

Failing tests

Ok, lets change something in our application that will make a test fail:

Now we are going to be bad and not run our unit tests before commiting and pushing the code

PS C:\dev\appharbor\MyCoolApp> git commit -a -m "a failing test"
PS C:\dev\appharbor\MyCoolApp> git push appharbor master

.. and we are building again

Woot! The build has failed!

We can easily see that it is the test that verifies the text on the start page that has failed

Ok, lets fix it!

Commit and push it again. And wait for the build to complete.

Yay! Our new version built successfully!

Lets check it out:

Rolling back to a previous version

Being able to rollback an update is sometimes necessary and AppHarbor makes it ridiculously simple, all you need to do is to press the “Deploy” link next to an old version. Clicking it will build and deploy the selected version.

We can now see that it is the first version that is active

I love the idea behind AppHarbor, this is really how sites should be deployed! However, using AppHarbor also means giving up some control over your environment. It will be interesting to see how they handle, for example, upgrades between different versions of IIS, installation of service packs, etc. Two features i miss is the ability to run background jobs and a distributed cache to use, but hopefully it will be coming to AppHarbor. AppHarbor still a very young startup, and so far what I have seen is really impressive!