jQuery.fn.jquery

or use the shortcut

$.fn.jquery

Also, if you are loading multiple versions of jQuery on your page and need to verify, you can also use the property:

<script type="text/javascript" src="http://ajax.googleapis.com/ajax/libs/jquery/1.4.4/jquery.min.js"></script>

<script language='JavaScript'>
	var $_144 = jQuery.noConflict(true);
</script>

<script type="text/javascript" src="http://ajax.googleapis.com/ajax/libs/jquery/1.7.1/jquery.min.js"></script>

<script language='JavaScript'>
	var $_171 = jQuery.noConflict(true);

	console.log($_144.fn.jquery);   //   "1.4.4"
	console.log($_171.fn.jquery);   //   "1.7.1"
</script>

ColdFusion 10 Features and Benefits

If you want to find out what’s new, watch this video:

You can view the code on Github: https://github.com/ibjhb/mockjaxExample  or the examples: http://ibjhb.github.com/mockjaxExample/

Reasons to Mock Ajax

Servers are slow / Rapid Iteration

When developing against a local server, the ajax response will typically 100-300 milliseconds, but could even be longer. If you are developing against a remote end-point, you could see varying response times that could even be 500 milliseconds to over a second. If you are trying to quickly develop an application that takes one second per response, it is going to take a while and you are going to get frustrated and/or bored. The faster the response time, the faster you can develop.

Endpoints Unavailable or Developing on an Airplane

There are a number of reasons that an API endpoint could be unavailable and inevitably, it will be when you want to work on your application. This can be very frustrating and could even cause you to miss a deadline. Additionally, if you are at a location or on an airplane that doesn’t supply WiFi, mocking Ajax responses would allow you to continue working.

Undeveloped Endpoints

If you are working in a team, or even on your own project, and the server-side code isn’t completed yet, Ajax mocking would allow you to complete the front-end code before the back-end is complete. Additionally, it allows you and whoever is developing the API to agree upon JSON response structures to ensure they don’t change unexpectedly during development.

Unit Testing

After rapid iteration, unit testing is probably the number one reason for mocking. The same mocks you use to develop your application become the ‘stone copies’ of your responses and objects in your unit tests. If you try to unit test against a live server, or even a unit test server, it is very possible that the data you expect isn’t the data that is returned. This could cause your unit test assertions to fail, even though the code is technically working properly. Mocking prevents this problem.

Slow or Unavailable Server Simulation

How does your application handle a slow or unavailable remote server? Without mocking, this would be difficult to handle consistently, especially if you don’t control the end-point. When mocking, you can control the response delay and intentionally simulate a slow or unavailable server reliably.

Introducing Mockjax

AppendTo’s Mockjax is a simple but powerful interface for simulating ajax responses. Below, we will explore different uses cases of the library.

Simple Example

In this example, we’re going to setup the most basic mock. If you run the code in example one, you’ll notice it outputs ‘Your beer today is Sam Adams’. If you open Firebug or the console. you’ll notice that Mockjax has logged: ‘MOCK GET: /api/beer/random’. This lets us know we’re mocking, so we don’t forget if we’re debugging in the future.

$.mockjax({
	url: '/api/beer/random',
	responseTime: 150,
	responseText: {
		success        : true
		,beerName       : 'Sam Adams'
	}
});

$.getJSON('/api/beer/random', function(resp){
	var html = (resp.success) ? 'Your random beer is ' + resp.beerName : 'No beer today';
	$('#content').html(html);
});

URL Matching

Mockjax allows for three ways to define the URL:

• Direct matching (seen above in the Simple Example)
• Wildcards (notice the “*” in the URL)

  $.mockjax({
  	url: '/api/beer/*',
  });
  

• Regular Expressions (this would match ‘/api/beer’ and ‘/api/wine’ but not ‘/api/cheese’)

  $.mockjax({
  	url: /^\/api\/(beer|wine)$/i
  });
  

Advanced Callback Responses

Mockjax also allows you to specify a callback response instead of a specific responseText. This allows us to define the response programmatically. To view the functional example, view the Callback Response Example.

$.mockjax(function(settings){
	// Try to match our API URL string
	var service = settings.url.match(/\/api\/beer\/get\/(.*)$/i);

	// If we find a match, handle the response
	if (service) {

		// Convert the string to a number
		var beer_id = Number(service[1]);

		// JavaScript counts from 0
		var response = ibjhb.mock.beer[beer_id - 1];

		// If the response doesn't exist, defer to making an ajax,
		// otherwise create our return JSON packet to be returned
		return (typeof response === 'undefined')
			? undefined
			: 	{
					responseText : {
						 success 	: true
						,beer		: response
					}
				}
	}
	return;
});

If you read through the JavaScript comments, you’ll get an idea of this more complex example.

Latency Simulations

With Mockjax, we can also simulate slow servers. You can add a ‘responseTime’ property to the function call:

$.mockjax({
	url: '/api/beer/random'
	,responseTime: 5000  // 5 seconds
	,responseText: 'Text from a slow server'
});

This example would wait five seconds before returning a response. Be sure to specify the value in milliseconds.

HTTP Response Status Simulations

We can also simulate an error from the server:

$.mockjax({
       url: '/api/beer/random',
       responseTime: 750
       ,status: 500   // Simulate 500 error
       ,responseText: 'Text from a slow server'
});

We can also simulate a server timeout:

$.mockjax({
	url: '/api/beer/random',
	isTimeout: true
});

Conclusion

As you can see, Mockjax is a powerful library that can speed up your development. Be sure to check out the full feature set on Github.

Day 2′s presentations are only 15 minutes. I’ll be talking quickly but I”ll be presenting on the following:

We will explore different techniques and methods to speed up your mobile and desktop web applications. Consumers and end-users have come to expect pages to load quickly and be responsive. Research shows that our brains can perceive time around 100 millisecond intervals and those intervals can add up if you have bottlenecks in your page load times or the responsiveness of the pages is poor once they are loaded. We are going to look at techniques you will be able to implement immediately to speed up both the actual and perceived experience of your site. This session will cover some server techniques but primarily focus on client-side technologies. We will explore real-world mobile use-cases and demonstrate various tools you can use today.

Are you attending the Front End Design Conference? Leave me a comment below!

If you clone the Exploring-Backbone.Mutators repository, you can view and run unit tests for each the below examples.

For our examples, we’ll model our data on Major League Baseball (MLB) and their teams/players.

We’ll start with a real basic example:

ibjhb.mvc.model.Team = Backbone.Model.extend({
	initialize                        : function(model) {
		return this;
	}
	,mutators                        : {
		teamName                : function(){
			return this.city + ' ' + this.nickname;
		}
	}
});

var team =  new window.ibjhb.mvc.model.Team({
	 city                : 'Tampa Bay'
	,nickname            : 'Rays'
});

team.get('teamName')   // New York Yankees

This example is very basic but it demonstrates the use of get() instead of creating functions like team.getTeamName();. This may not seem like a big change, but when using in an application or unit testing, it’s a huge difference.

In our next example, we’ll calculate and return the batting average of a player:

ibjhb.mvc.model.Player = Backbone.Model.extend({
	initialize                        : function(model) {
		return this;
	}
	,mutators                        : {
		battingAverage        : function(){
			var multiple = Math.pow(10, 3);
			return (Math.round((this.hits / this.at_bats) * multiple) / multiple);
		}
	}
});

var player = new window.ibjhb.mvc.model.Player({
	 name                : 'Evan Longoria'
	,at_bats             : 55
	,hits                : 14
});

player.get('battingAverage');     // .255

This value corresponds to the Evan’s statistics.

In our final example, we’re going to convert the player object to JSON using the Backbone.js toJSON() function:

ibjhb.mvc.model.Player = Backbone.Model.extend({
	initialize                        : function(model) {
		return this;
	}
	,mutators                        : {
		battingAverage        : function(){
			var multiple = Math.pow(10, 3);
			return (Math.round((this.hits / this.at_bats) * multiple) / multiple);
		}
	}
});

var player = new window.ibjhb.mvc.model.Player({
	 name                : 'Evan Longoria'
	,at_bats             : 55
	,hits                : 14
});
console.log(player.toJSON());

When you view your console log, you’ll see the ‘battingAverage’ property is included:

{
	 name                           : 'Evan Longoria'
	,at_bats                        : 55
	,hits                           : 14
	,battingAverage                 : 0.255
}

This is very cool! This is where some of the power of the library is apparent. When you put this returned value under unit test, you can test a large number of values very quickly.

If you’ve been using Backbone.js at all, these examples are relatively simple but if you use this library, they illustrate a shift in how you design your models. I’m going to start using it in all my projects.

NOTE: You must use Underscore.js > 1.3.1 with this Backbone.js update

I just dropped the new library into my favorite video website and ran our client-side unit tests. It did not go well. It looks like there will be some work done before implementing this release. Around half of the tests failed.

This new version looks like a great update and it is exciting that Backbone.js is nearing a 1.0 release. However, this isn’t a minor upgrade and it is not backwards compatible.

Though the slides are in the video, if you don’t have Silverlight installed, I’m including the slides in a PDF. Also, the presentation description is:

In this session we are going to explore different techniques and methods to speed up your mobile and desktop web applications and websites. Consumers and end-users have come to expect pages to load quickly and be responsive. Research shows that our brains can perceive time around 100 millisecond intervals and those intervals can add up if you have bottlenecks in your page load times or the responsiveness of the pages is poor once they are loaded. We are going to look at techniques you will be able to implement immediately to speed up both the actual and perceived experience of your site. This session will cover both server and client-side technologies. We will explore desktop and mobile use-cases and demonstrate various tools you can use today. This session will utilize ColdFusion and Backbone.js but concepts will apply to all web applications.

If there is anything specific you’d like me to address or specifically speak on, either related to ‘lightning fast mobile & desktop web applications” or Backbone.js specifically, let me know in the comments below.

See you in Raleigh, NC on September 17 – 18, 2011!