I recently came across two bookmarklets that let you view any webpage in multiple screen-sizes and simulate viewing on multiple devices, all inside your browser.

The first I came across was a script by Victor Coulon.  He wrote Responsive Design Bookmarklet which places a toolbar at the top of the page.  The toolbar includes buttons that let you select between landscape and portraiture mode for a table and phone.

Upon picking each, the UI automatically updates to the selected size and orientation.  For example, I visited this site’s homepage and then selected the phone/portrait mode:

You can grab the bookmarklet from his site.

The other bookmarklet I came across was Benjamin Keen‘s Responsive Design bookmarklet.  Although similar in nature,  his uses iFrames to show multiple resolutions at the same time.  Be sure to scroll right to view all the resolutions.  Since he uses iFrames, all the links and functionality still works.

Check out both and let me know what you think.  Have you found other good Responsive Design bookmarklets I should know about?

Tonight Aaron Greenlee and I gave a presentation titled “JavaScript Series – Patterns and Techniques of Modern Web Applications” for the Central Florida Web Developers User Group. There was a great turnout, both in-person and online and we appreciate the feedback and discussion from both. Below, you can find the actual presentation and a link to the Github repository. The repository contains both the presentation and the example code that was used. The presentation was recorded and I will update this post as soon as it is available.

Presentation : http://ibjhb.github.com/JavaScript_Patterns_Techniques/

Github : https://github.com/ibjhb/JavaScript_Patterns_Techniques

If you have any questions about the presentation, code or anything else related, feel free to ask in the comments below.

If you are developing web applications that utilize Ajax (and most do today) and are using jQuery and/or Backbone.js, you should be building with mock Ajax JSON responses.

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.

Read more →

I recently came across a Backbone.js plugin called Backbone.Mutators. It’s an awesome but simple design pattern to utilize in your applications and the minified library is pretty small. By including this library in your application, you can adhere to a standard method of retrieving properties out of Backbone models. For instructions or examples on how include the library in your project, either view the README.md or clone my repo. Below are some examples exploring Backbone.Mutators.

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')   // Tampa Bay Rays

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.