To more illustrate what this session will cover, consider the this hypothetical: we need to display address components in a pre-defined section of a page.

The end result might look like this:

The following code drives the address display:

$.getJSON("data/data.json", function (data) {}).success(function (data) {
		  $("#target").empty();
		  var items = [];
		  $.each(data, function (key, val) {
		    items.push('</pre>
<ul>
	<li id="' + key + '">' + val + '</li>
</ul>
<pre>
');
		  });

$('', {
		    html: items.join('')
		  }).appendTo('#target');

		})

		.error(function (error) {
		  $("#target").empty().append("

An error was encountered...

");
		})

		.complete(function (data) {
		  $("#target").removeClass('ajaxLoad');
		});

Fairly straightforward code: Data is acquired via getJSON and displayed. jQuery I used to drive the process. The code works, but there are problems. Recalling what we have learned from SOLID, DRY, etc. – we quickly learn that the code not maintainable, re-useable and it’s marginally testable. About the only thing that can be tested here is the end result. As to the target, were the proper classes assigned and is there an un ordered list with data? In other words, all we can really test are the side-effects of the JavaScript code, not the code itself. Looking at the code, there are several distinct things happening. First, there is the application of the ajaxLoad class. Second, there is the data acquisition process itself. Third, there is the application of the data. There are also operations to handle error conditions and when the ajax process has completed. Geographically, this code is embedded in an html document. Ideally, this code would be re-factored into its own js file. Going back to the distinct operations, each of these operations should be testable, and more specifically, unit testable. Ideally, we would like to verify our code with a test like this:

function testfixture() {
    module("When retrieving address data");
	//Arrange
	var html = $('</pre>
<div id="target"></div>
<pre>')
   //Act
   ApplySomeOperation(html);

    test("Given that the data has \
	  been applied to a pre-defined div",
	   function () {
	   expect(1);

	   var ul = $(html).find("ul");

       //Assert
	   equal(ul.length, 1, "The ul tag is present.");
	});
}

The code, as written, does not support a unit test like this. The code is essentially a big ball of mud. Again, the code “works”, but in our business, working is not enough. With a little re-factoring, we can get where we need to be.

This is what we end up with:

function removeStartMsg(target) {
   $(target).removeClass('ajaxLoad');
}
function displayStartMsg(target) {
   $(target)
      .empty()
      .addClass('ajaxLoad')
      .append("

One moment while your data is \
	    being retrieved...

");
}
function createAddressHtml(data) {
   var items = [];
      $.each(data, function(key, val) {
	     items
		   .push('</pre>
<ul>
	<li id="' + key + '">'
 + val + '</li>
</ul>
<pre>
');
	  });

return $('', {
		html: items.join('')
	   })
}
function displayAddress(data,target) {
   target.empty().html(createAddressHtml(data));
}
function getAddress(id,target) {
	var complete =  function(data) {
	    removeStartMsg(target);
		$(target).removeClass('ajaxLoad');
	};

	var success = function(data) {
		displayAddress(data,target)
	};

	var error = function(error) {
	   $(target).empty().append("
An error was encountered...

");
	}
	displayStartMsg(target);
	getData(id,"data/data.json",success,error,complete);
}
function getData(id,source,successCallBack,errorCallBack,completeCallBack) {
   $.getJSON(source, {id: id},
       function (data) {}).success(function (data) {
	   successCallBack(data)
   })
   .error(function (error) {
       errorCallBack(error)
   })
   .complete(function (data) {
   	   completeCallBack(data)
	});
}

The idea is that each discrete operation has its own function. Thus – we adhere to the single responsibility principle. Also note that no function reaches into the DOM. Instead, the object it is to act on is handed to it. The code in the page reduces to this:

<script type="text/javascript">
   getAddress(0,$("#target"));
</script>

For testing purposes, the json source is a static file on IIS. With little effort however, the source could easily be any http endpoint. With the refactored code, we can write more granular tests.

For example:

function testfixture() {
    module("When retrieving address data");
	//Arrange
	var html = $('<div id="target"></div>')
   //Act

   getAddress(0,html);
   stop(2); // allow async processes to run

    test("Given that the data has \
	  been applied to a pre-defined div",
	   function () {
	   expect(1);

	   var ul = html.find("ul");

       //Assert
	   equal(ul.length, 1, "The ul tag is present.");
	});

    test("Given that the data has \
	  been applied to a pre-defined div",
	   function () {
	   expect(1);
	   var expectedHtml = "<ul><li id=\"company\">Microsoft Corporation</li>
                <li id=\"Address\">One Microsoft Way</li><li id=\"City\">Redmond</li>
                <li id=\"State\">WA</li><li id=\"Zip\">98052</li></ul>"
       //Assert
	   equal(html.html(), expectedHtml, "The html markup is correct.");
	});
}

The following is the QUnit output:

Again, with the refactored code, we can test everything, at a unitary level, that is needed to support the display.

I want to be clear here – I don’t agree with those that say that laws like SOPA and treaties like ACTA – subvert free speech. Stealing the intellectual property of others is not something that should be tolerated. That said, there were some troubling aspects in SOPA – mostly arising form the lack of due process. The major problem was that based on a mere allegation – a site could be shut down.  It remained to be seen how that law would have been enforced.

ACTA is another thing altogether in that it is a treaty. In my opinion, organizations like the Free Software Foundation (FSF) – completely mis-represent what ACTA is. If there is one thing about ACTA I think is worthy of criticism is the secrecy around the treaty negotiations.

In general, I’m a fan of the FSF. That said, the torch and pitchfork crowd goes a bit too far with their assertions. Here are the FSF’s points:

1. It makes it more difficult to distribute free software: Without file sharing and P2P technologies like BitTorrent, distributing large amounts of free software becomes much harder, and more expensive. BitTorrent is a grassroots protocol that allows everyone to contribute to legally distributing free software.
2. It will make it harder for users of free operating systems to play media: Consumers may no longer be able to buy media without DRM — and DRMed media cannot be played with free software.
3. It increases the chances of getting your devices taken away: Portable media players that support free formats are less common than devices which support DRM, such as the iPod. Will this make them suspicious to border guards?
4. It creates a culture of surveillance and suspicion, in which the freedom that is required to produce free software is seen as dangerous and threatening rather than creative, innovative, and exciting.

First off, folks need to read ACTA. It states pretty clearly that notions of due process and free speech must endure – that the manner of how ACTA is enforced must be consistient with those ideals. Put it this way, illegal activity occurs on cell phones and computers. Are we less likely to use those devices? Are those devices confiscated today? Of course not. File sharing technology supports legal activities. Indeed, it can support illegal activities as well. That however, does not mean those technologies will go away. This is where common sense and practicality have to kick in. For example – let’s say you in fact, have illegal copies of music on your iPod. How can you tell by looking at the device? More importantly, how could a customs tell? Do we really think this is going to be a priority? 

The fact is – pirated software, music and counterfeit goods are a problem – and it is well within the province of rights-holders to prosecute and protect their rights. That said, it cannot and should not happen at the expense of our rights and our rights to use technology that has legitimate purposes. I happen to think that the MPAA and RIAA, while they have some legitimate concerns, are also comprised of people that for the most part – are clueless on how to deal with these matters. If there is one point to take from the DNR episodes it is this – GET INVOLVED AND STAY INFORMED. If there is one suggestion I’d make to those who have to craft legislation and ratify treaties – it is this – G

How many times have you had to build that piece of furniture from Ikea, install window blinds, etc? In each case, you are solving a problem. You have to analyze and organize. It’s really not that different from development. It’s a project like anything else. It has a beginning, middle, end. Like development, if you misinterpret the requirements, you have to go back a few steps. That next thing you were going to do has to get pushed to a later time.

This past weekend, I had to install some Levolor Blinds into our spare bedroom. I also happened to be listening to the  This Developer’s Life Podcast. I was listening to Episode 1.0.6: Abstraction. A great episode (as they all are – and like really good things – you have to go through them a few times because you are likely to pick up something new and useful that you missed before.) The part that really struck me was the interview with Ward Cunningham. It was then that I decided to use my blind installation task as an analog of sorts for development. The interview with Ward was the inspiration. The end game is to then reverse the flow – to perhaps use development as an analog for the blind installation task – assuming of course the blind installation task is successful!

It begins with us…..

The one thing that really struck me about Ward was his motivation – that he builds things form himself. The same was true with John Ressig and Dan Bricklin. Then it struck me that this is really a craftsmanship issue. True craftsmen always reserve the best stuff for themselves. Indeed, much of that good stuff accrues to the benefit the things that are released for public consumption. Craftsmen work product also shares another characteristic – what they produce is pleasing to look at and use by the harshest critic of them all – the craftsmen themselves.

Turning back to my window blind example, I wanted to ensure they would function properly, be pleasing to look at – much like what we strive for in our software.  For a satisfactory end result however, there has to be some measure of planning. Since I had two blinds to install, I wanted to make sure the second one had the benefit of the first – as to process and as to a completed product. My benchmarks were simple:

Did I thoroughly understand the requirements?

Did I have a plan?

Was I organized?

As to tooling, did I have what I needed and were those tools readily available?

Was there improvement in the process?

The great thing about tangible projects – particularly those you have to do around the house or wherever you may be, those projects provide immediate feedback. You know whether they look right. You know immediately whether something was hacked together. You know whether the finished product is pleasing to look at.  You also know what is lurking beneath the surface. I’m in the middle of the Steve Jobs bio by Walter Isaacson. Jobs was obsessive about quality (perhaps to an unhealthy extreme!!). His [Jobs] obsession was centered around the fact that quality of thing not seen was at least as important as what is seen.   That consideration absolutely applies to the software world. When we see properly working software, we can take pride that the things people don’t see are well constructed. With home projects – we know that something is not going to break or fall apart because the things people don’t see (like screws into the wall being well anchored) are well done.

Food for thought as you contemplate ways to continuously improve.

To get started, create a Console Application and follow the steps in the ASP.NET MVC example to use Nuget to download the WebAPI references and to create the Contact Manager classes. Once you have those items in place, all you need to do is outfit the application to fire up the web host. To do that, use this code:

using System;
using ContactManagerSelfHost.APIs;
using Microsoft.ApplicationServer.Http;

namespace ContactManagerSelfHost
{
    class Program
    {
        static void Main(string[] args)
        {

            using (var host = new HttpServiceHost(typeof(ContactsApi), "http://localhost:9000/api/contacts"))
            {
                host.Open();
                Console.WriteLine("Press any key to stop host...");
                Console.ReadKey();
            }
        }
    }
}

Simply run the app and navigate to the URL. That’s it!

In a nutshell, to be patentable, the given subject matter must cross two thresholds:

1. The subject matter must be novel
2. It must be non-obvious to those who are skilled in the art.

Ideas and discoveries are not patentable. Inventions are patentable. i.e. things that do something. Great examples are the microprocessor, the internal combustion engine, the  machine that produces Slurpees, etc. The big question is whether software is patentable. It’s settled that software is copyrightable in that it can be expressed in document form. But as we know as professionals in this business, software, like it’s machine and hardware counterparts, actually does something – whether it is controlling hardware, carrying out a business process, etc. A software process can be described in a patent claim just as the processes for how a microprocessor works can be documented (in reality, multiple patents will cover complex things like a microprocessor, combustion engine, etc.)

A good example of a software patent was FoxPro’s Rushmore Technology which, simply stated, was a data access method that used indexes to optimize data retrieval. A bad example of a software patent was 1-Click Buying. Setting aside the obviousness problem here, let’s consider whether something like 1 Click Buying was novel. By novel, does something build on prior art? I think it is safe to say that 1 Click Buying most certainly built on prior art that Apple didn’t own. When you consider how big Apple has become, don’t just think of the iPod, iPhone, IPad, etc. In 2000, Amazon licensed 1-Click from Apple. How much in licensing and royalty fees do you reckon Apple has cashed in on?

I agree with the Google attorney, the system is broken and has been broken for quite some time.  That’s not to say that software cannot and should not be patentable. I contend that software is just as patentable as anything else that has the potential for being patentable subject matter. The notions of novelty and non-obviousness seem to have been discarded by the USPTO. Some claim that it is very difficult to discern whether something is actually building on prior art. Peraps if claims where drawn up in a more standardized way, it would be easier. But you see, this is where the lawyers come in. The goal is always to draw up claims that are broad and vague. The broder the claims, the more your patent covers – something that patent trolls strive for. The gate keeper to protect the system is supposed to be the USPTO. They have been totally asleep at the wheel. It’s also been the court system that has been asleep at the wheel. Often, the USPTO will actually get it right – only to be reversed by the federal courts.

Now…before you think this is something that is just limited to technology, think again. Do you remember those orange trashbags that you could fill with leaves? They had a picture of a pumpkin stamped on them. Was that novel? I don’t believe so as it most definitely built on prior art. Was it non-obvious?  I thnk it is safe to say that in reality, the bags were obvious. The USPTO rejected the patents. The Circuit Court however, in 1999, reversed the USPTO. The Dembiczak and Zinbarg case is a good one to read because it is instructive on the gap that existed between the law and common sense. The USPTO was reversed on technical grounds based on evidence that was not in the record – but nevertheless could have been. This was a case where there the narrow teaching/suggestion/motivation standard for obviousness under 35 U.S.C. §103 was applied. Fortunately, in 2007, in the KSR v. Teleflex decision, the SCOTUS finally brought in notions of common sense. IMO, had the KSR decision been around when 1 Click was applied for, the patent would have been rejected.

Things should get better, but it would appear they are not because of business reality. The fact is, companies with a lot of money have the threat of litigation on their side – and that causes many more other companies to cave in. The Google attorney interviewed commented, as I have in the past that the only way you get to a definitive word is to litigate and get a court decision as to what is novel and non-obvious. The difficulity is that these are mixed questions of law and fact.

Bottom line, it’s going to be a while before things actually get better in the patent landscape.

As to the .on method, the one are that requires special attention is the optional selector argument. To explain, let’s assume you have an element that has child elements and you wish to bind a click handler. I will use the example provided in the jquery documentation.

//in this example, a click handler will be attached to every table row.
$("#dataTable tbody tr").on("click", function(event){
 alert($(this).text());
});

The preceeding example could be quite expensive if you have a lot of rows. Note the following example which uses the optional selector argument:

//in this example, the bound element is the tbody, not the tr's under the tbody.
//the second argument in the .on call is used, in this case, we pass the "tr" selector.
$("#dataTable tbody").on("click","tr", function(event){
 alert($(this).text());
});

The difference between these two examples may seem semantic. The difference is anything but. In the second example, the handler is attached to one element – the tbody. The event is then delegated to the tr elements – which is directly beneath the tbody. Per the jQuery documentation, when you delegate events, be sure to define them as close in proximity to the child objects that will actually be used to fire the events. Otherwise, jQuery has to work harder to traverse through the object hierarchy.

Finally, if you want an event that runs one time only and then detaches itself, check out the new .one() method.  How many times have you defined an action the user can only do one time. All of that code that you wrote to manually unbind the event is no longer necessary thanks to the new .one() method!

Telerik is offering a prize to one of you, ASP.NET AJAX developers: a FREE developer license for RadControls for ASP.NET AJAX (worth $799)! To participate in the drawing for this prize, you need to help Telerik spread the news about this learning resource by simply:
1.       Tweeting this blog post (title and URL)
2.       Use the following hashtag in the tweet: #TelerikDemos

I’ve been proud to be associated with Telerik because of the high quality of their tools. Telerik has just released a new version of their ASP.NET AJAX controls. If you are an ASP.NET Webforms shop and have been looking for an easy way to add some pizazz to your applications, you really need to check out these tools. As with all things Telerik, it’s not just the tools that are solid, the demos are superb. One of th4e most common use cases we encounter is the need for management dashboards. Decision makers want quick access to the most important information with at a glance efficiencies. One of Telerik’s demo applications is just that – a sales dashboard. This is an integrated demo that ties multiple tools together: RadToolbar, Script Manager, Style Sheet Manager, and many more. Yes, this is a ASP.NET Web Forms app, but it also brings in modern  elements with Ajax and jQuery.

One of the cool features RadListView which provides a nice navigation tool to quickly access a specific employee’s sales data. You will find the code for that in the default.aspx page under the a comment that reads — Employees List –. What’s nice about the demo is that it shows you how easy it is to combine these user controls with JavaScript and CSS. The JavaScript that handles  the onmouseover and onmouseout events is encapsulated in a RadCodeBlock that is also contained in the default.aspx page.

While you can click on a particular employee, you can also use the Page Slider control to navigate to another page of employees. The code in the default.aspx page show how easy it is to bind that control the employee list view. You may be thinking “There must be a lot of messy code behind.” In any web forms app, there is some code behind. The Telerik Demos are architected quite nicely to minimize the code behind. As you will see, the various order categories and statistics have been encapsulated into their own classes.

Other demos include typical use cases such as event management and mail/Outlook integration. Other Telerik tools such as the OpenAccess ORM Reporting are highlighted and demonstrated.

Bottom line, if you are looking to add some cool features to your ASP.NET web forms applications and you want demos that have sound architectual guidance, you will definitely want to consider adding the Telerik’s RadControls for ASP.NET Ajax to your development toolkit.

To illustrate the point, let’s consider what Scrum is in a
nutshell (as codified by Ken Schwaber and Jeff Sutherland, the creators of
Scrum). Scrum Teams are created that are comprised of a Product Owner, Scrum
Master and a Development Team. A Product Owner manages a Product Backlog that
is prioritized in descending order by business value. The Development Team,
which is cross-functional and self-organizing, in conjunction with the Product
Owner and Scrum Master, based on a variety of factors (most often by a
combination of historic velocity + current capacity) in the Sprint Planning
Meeting, select a number of Product Backlog Items to work on during the Sprint
– which may last for at most, 4 weeks. The Development Team, in conjunction
with the Scrum Master and Product Owner (as needed), decides to how to
decompose the selected Product Backlog Items that now comprise the Sprint
Backlog into separate tasks. As the Development Team works during the Sprint,
it meets each day for a maximum of 15 minutes in the Daily Scrum Meeting. At
the end of each Sprint, during the Sprint Review (no more than 4 hours), the
entire Scrum Team meets to discuss/review the Product Increment (what was
completed during the Sprint). Subsequently, a Sprint Retrospective Meeting (no
more than 3 hours) is held to discuss what went well, what did not go so well
and what could be improved as to the Scrum Team. After that, the next Sprint
Planning Meeting is held and the process repeats.  All of this is codified in the Scrum Guide.

As for what Kanban is it first has to be stated that Kanban,  unlike Scrum, originated in a non-software environment. Kanban originated with  Toyota and devised the system as a means of supporting the production of cars.  Over time, Kanban and the Lean Manufacturing concepts have been applied to the  software development discipline. To the degree those concepts map cleanly to  software development remains very much in debate and it’s not a debate I’m going to undertake here. Rather, I’ll focus on the goals and objectives of Kanban and Lean. The origins of Kanban in the software context were codified by David  Anderson in his book Kanban – where he postulated the Kanban Method. There are  5 core principles: workflow visualization (Kanban Board), limited WIP (work in process), managed flow, defined explicit processes and improved collaboration.

For all of the rules codified in the Scrum Guide, in Kanban (in the traditional
manufacturing sense), there are two basic rules: the ability to see the work  flow and limit the WIP. These rules are meant to support the aims and goals of  Lean. The Kanban Method, as codified by David Anderson, there are three basic  principles: Start with what you know, Agree to pursue incremental and  evolutionary change and respect the current process, roles, and responsibilities. With regard to respecting the current process, this is where conflict between Scrum and Kanban can arise. Note that a team’s discipline or the degree to which a team is functional is not a factor in Kanban. Is any of this counter to Scrum? Not necessarily, but it might. For example, Scrum prescribes team makeup, title, roles, and responsibilities. If those roles (Product Owner, Scrum Master, etc.) and the responsibilities ascribed to those roles as promulgated by the Scrum Guide don’t exist, then yes, there will be conflict. Kanban says to respect what’s there. Scrum has a prescriptive mandate. Those are irreconcilable differences in my opinion and if your team is implementing Scrum, those efforts could be derailed if you bring Kanban principles into the mix.

A good way to view this is to look at the goals of each method. If you look at Kanban’s principles and if you already have a functioning Scrum Team, you will find that without implementing Kanban, you will already be achieving Kanban’s objectives. What about the Lean Goals? The main goal is minimizing WIP (i.e. waste). A Development Team does not take on more than what it can handle – which necessarily means that WIP is minimized. As for waste – the Product Owner sees to that by making sure the Product Backlog is well groomed (irrelevant items are removed, those items with the highest business value are
at the top, etc.). So then, if you have implemented Scrum, why would you also try implement Kanban? In my opinion, you wouldn’t for the aforementioned reasons. What about Kanban’s chief way of visualizing work, the Kanban Board? If you are working on a Scrum Team, you are already working with some visual representation of the Product and Sprint Backlog. Further, there is a visual representation of what is being worked on and what is done. Can a Kanban Board do that? Sure – but Kanban is more than just a board. The key is not to get caught up in the tools and devices. Rather, it is important to look at the underlying principles of a given methodology or framework. From that, you can ascertain where there are things in common and conflicts.

Some teams that use Kanban may be under the belief they are practicing Scrum. That may or may not be a valid belief. That practice would have to be assessed and gauged against the Scrum Guide. On the other hand, if you are practicing Scrum, then I would submit that an effort to bring Kanban into the Scrum practice would not present added value and perhaps, would be counterproductive. That’s not a knock against Kanban. Rather, it’s an assertion on my part the good things Kanban brings to the table are already accounted for with your Scrum practices.  Does that mean that Kanban has no value in your organization if you are using Scrum? Absolutely not! There may be other activities where Scrum does not apply or is a good fit for one reason or another.  In those cases, Kanban may be and could be a very productive alternative.  How about those cases where your team practices Scrum…but…<<insert your but here>>.  mplementing Kanban, by itself, is not going to remediate those “Scrum Buts.”

As always, when deciding to implement a new tool or process, have a solid understanding of why you would undertake such an implementation. Make sure the ills you are trying to remedy can be remedied with a combined approach.  Make sure your approaches are compatible such that one approach does not negate/dilute the other approach. When combining approach, you will want to make sure the net value add is at least equal to the sum of the parts.

Building your First jQuery Plugin

ReST and ASP.NET MVC