SignalR & MVC5

SignalR & MVC5

SignalR is great!

Ok, you want a little more than that, well I have recently set out on a project to learn SignalR and get used to the new VS2013, also really like this. My first point of call was to upgrade my site to MVC5, some great new touches like standard use of bootstrap in the template. The big surprise was how easy it was to create a SignalR application, if you think its more complicated try this link.

http://www.asp.net/signalr/overview/signalr-20/getting-started-with-signalr-20/tutorial-getting-started-with-signalr-20

Canvas Chat

It takes all of about 20minutes to run through this tutorial and you have a fully working chat at the end. In the end I wanted more, I decided to make a canvas chat, try to use some of the MCP skills I learned, after some playing around I got it working.

Remote Console 

This then lead me to a problem with trying to get touch to work on my Windows 7.8 phone, still no luck message me if you have the key. Basically I cannot find the event for mouse move.

From that the SignalR console was born. It is still in it's early stages but I think it has some potential, I also am fully aware of tools such as  JSConsole, but this was so easy to set up I think it has potential.

Anyway check it out here: http://www.tomharris.net/MiniProjects/WhiteBoard

My servers a little slow so apologies for the speed performance.

JavaScript testing

JavaScript testing has got to be one of the most overlooked areas of testing since practices like TDD and Unit testing begun. It is often seen as a code to just add events and load data, these days with HTML5 bringing new functionality I have seen more and more people use client side coding. People are seeing the benefit of client side processing and with the introduction of JavaScript workers in new browsers this is only going to continue. This code clearly has a place and therefore we need to start thinking about how we test this.

I have been working on web applications for ten years and in the past 3 years I have really bought into testing be it TDD or just unit test developed after. I believe it’s the stable to any long lasting project. The question I had to ask myself about a year ago was how I can ensure that my client side code is as stable as my server side code. Firstly it was a case of replacing all old legacy code with standard libraries like JQuery, this then left the community to support these areas. Also worth pointing out JQuery is tested.

That alone wasn't enough to get me coverage. I work on a system with complex calculations that process for nutrition and recipe data on the client. This data is critical to business process so has to be correct. We needed to make sure these and calculations similar where covered to our server side code. So I took on the task of testing our Client side code.

Now the idea of testing JavaScript isn't hard. Many solutions are out there to help you on this path, below are some examples. But the concept of testing something like JavaScript is the hard one. Below are some of the issues and solutions and my conclusion so far to how you can start testing.

• QUnit : http://qunitjs.com/
• Jasmine: http://pivotal.github.io/jasmine/
• JSUnit: http://jsunit.berlios.de/

DOM Interaction

So we have all inherited someone's code or even written sloppy code when we where juniors. Well often one of the key mistakes when starting out is the crossing over of JavaScript and the DOM. Now this is perfectly fine when you are working with a DOM manipulating library but when you come across a solution that does calculations and each time it gets the value from the DOM input this is a big "no no". When it comes to JavaScript testing, and really any testing, this has to stop. What we should be trying to do is pass a model to our method or parameters and get the result. With the result you can then bind this to the input DOM. This way when you run you test it can run without the DOM in place.

Server Calls

Next on my list of changes was the methods which hit the server. In the test environment I don't have the data set-up to ensure that my test pass. If I do have the data I cannot be sure it's the same each time. So what I need is to be able to simulate the server being hit, I need to mock the server. This is common practice in .NET development but maybe not obvious in JavaScript. The article below explains in detail the different libaries that are available and

http://testdrivenwebsites.com/2010/05/06/java-script-mock-frameworks-comparison/

Integrated builds

With any testing framework what we want is for it to be automated. Ideally this should happen on each check-in.  The below blog explains some of the more popular frameworks and getting them running in a automated fashion.

http://blog.danmerino.com/continuos-integration-ci-for-javascript-jasmine-and-teamcity/


Conclusion So Far
Again to point out this is my feelings so far, 6 months in. I'm sure as I move forward and so does the concept of JavaScript testing the decisions and problems will changes. I will try to keep this post updated with the latest.

For me JavaScript testing although it is firmly out there is still not at the maturity that allows a clear decision. Many libraries are available and its a constantly changing environment. It also depends on the set-up you have and the requirements.

If you are learning about testing and how to structure your code. I would start with QUnit its simple to setup and get going. You will however outgrow QUnit fairly quickly if you are working with multiple developers.

If you want the full feature set then go for Jasmine today it's more of a framework for testing than QUnit. It also appears to be a favourite with many developers. And some large libraries like AngularJS are being tested with this today.

Making that decision about AngularJS or Knockout

This isn't the first post comparing these two libraries so I'm going to take a different take on this. I want to compare how viable each of these is to apply to a new or existing project.

Why this post title is wrong

 Firstly it’s not as clear cut as comparing one to the other. These two libraries are very different and Knockout is just a small part of what AngularJS does. If you want to compare an equivalent compare AngularJS to Durandal. This is a more complete solution for to compete with AngularJS.

http://www.johnpapa.net/compare-durandal-to-angular-not-knockout-to-angular/.

The history

I was working on one of our legacy projects which only support IE, god help me. The time had come for us to upgrade this solution, after all people use other browser now. The main route of the problem was our old legacy system used XML Data Islands. Most of you will not have used this; I had never used it to working on this solution. Basically the concept of these DataIslands was actually really good. First you define you object in XML and then you bind the XML to the HTML using inline attributes on the HTML, sound familiar.

If you are also in the position that you need to migrate away from DataIslands I suggest you also looking at XML2JSON. This library allows you to move to using something like Knockout without the need of rewriting your backend. It’s only an interim solution but a great way to move forward when the budget doesn't allow.

Comparing Data Binding

I'm only in my first 6 months of using these libraries so this is an early comparison. We started to use Knockout, being a Microsoft development team this come naturally. Problem happened when I head that Google had something similar. I had to know what they were doing; most of us can accept that Google lead web development.

I started to compare these two solutions, for binding only. In all honestly when it comes to binding it’s hard to find a failure in either of these libraries. However I did find a few things easier and this is likely just down to our project.

Structuring your code

It's often one of the hardest things to decide with a new project "how will I structure my files" is a common comment on new projects. With AngularJS this is somewhat removed from your decision making. AngularJS suggest/forces good practice for structure of objects and files. This in its self is a great thing. The problem comes when you have a 10 year old solution. Changing files here just isn't possible; the regression test alone would blow the budget. If working on a Greenfield project I can see the benefit of this as a starting point.

Syntax

Knockout syntax is great and simple if you are used to XML Data Binding you pretty much can find a like for like syntax. Although templating is altogether a different thing. If you again have a Greenfield or never used binding before project then why learn Knockout when you can learn AngularJS. Both these libraries have great and ever improving documentation so you don't need to worry about the learning side.

AngularJS also has some neat syntax that can help make life easier. Take for example the filter and sorting options when templating. These really can add great functionality to your code for little effort. I'm yet to see an ability to sort in Knockout, although I have seen attempts at this on various boards.

Conclusion

Knockout is a great tool but go for Angular unless you are migrating from some older form of data binding. For my project I have gone with Knockout but on our new projects we are using AngularJS. It’s a difficult choice.

I will keep you updated on how the project continues and our final result. As the project continues we will face more unforeseen challenges.

References:

http://angularjs.org/

http://knockoutjs.com/

http://blog.nebithi.com/knockoutjs-vs-angularjs/

Some simple angular examples to get you going:

http://tomharris.net/test/angularJS