eric - Eric Feminella

Interconnectivity in JavaScript with Peerbind

The ability to facilitate interconnectivity between multiple clients has always presented some rather interesting possibilities for both simple and complex Web Applications alike. More often than not, such interconnected applications would require complex server-side configurations (often proprietary in nature) in addition to numerous infrastructure considerations.

Peerbind, a new JavaScript API, remedies many of these complications by providing a very simple client-side API built on jQuery.

Peerbind is quite unique in that it provides an event binding API (on top of jQuery) that is shared amongst all connected clients of the same interest. Essentially this allows for binding something as common as a “click” event (or any event for that matter, including custom events) such that each active instance of the same application across the web will be notified of the event. As one might imagine, this allows for some rather compelling possibilities.

To demonstrate just how quickly and easily interconnectivity can be plugged into a web application using Peerbind (and the Peerbind public server), below is a simple example which displays a new item each time a new “peer” views the example page since loaded (hint: try opening a few instances, either in tabs or separate browsers).

<!doctype html>

<html>

<head>

<title>Simple Peerbind Example</title>

var Peers = (function() {

var added = function(e) {

var timestamp = new Date(e.timeStamp);

var visitor = e.srcPeer ? "New Visitor" : "You";

var item = "<li>" + visitor + " arrived on " +

timestamp + "</li>";

$("#visitors").preppend(item);

}

var init = function() {

var body = $(document.body);

body.peerbind("peer", added);

body.peertrigger("peer");

}

return {

init: init

}

}());

$(document).ready(Peers.init);

</script>

</head>

<body>

</body>

</html>

Example (run)

Simple enough!

Of course, for most applications there are obvious security concerns which would need to be addressed as well as issues of scale and availability to take into consideration. That being said, if you haven’t checked out Peerbind yet and would like to quickly and easily add interconnectivity to your application or leverage it’s simplicity to prototype such features, it is certainly worth taking for a test drive.

Comments Off

Test Driven Javascript with QUnit

For the past year I have been using jQuery Mobile for developing web based mobile applications leveraging HTML5, CSS3 and JavaScript. Like all UI implementations, meaningful test coverage is essential to ensuring requirements have been met and refactoring can be achieved with confidence. Building applications for the Mobile Web is no different in this respect. And so, a high quality Unit Testing framework is as essential to the success of Mobile Web Applications as it is to their Desktop counterparts.

Why QUnit?

While there are quite a few good JavaScript Unit Testing Frameworks available, Jasmine in particular, I have found QUnit to best suit my particular needs for implementing Test Driven Development in JavaScript based on it’s clean design and practical implementation.

A Simple, Powerful API

The power of QUnit lies in it’s simple and a rather unique approach to Test Driven Development in JavaScript. The QUnit API introduces a few slightly different test implementation concepts when compared to the more traditional xUnit style of TDD. In doing so, QUnit succeeds in simplifying some of the tedium of writing tests by leveraging the language features of JavaScript as opposed to strictly adhering to the more traditional xUnit conventions, the design of which is based on an fundamentally different language idiom – that is, Java.

For example, consider the follow which tests for a custom data namespace attribute in jQuery Mobile:

test("Test expected namespace override", function() {

var expected = "someNamespace-";

var actual = $.mobile.ns;

equal(actual, expected, "expecting namespace to have been set.");

});

Figure 1 (run) (source)

The above test may appear quite straightforward, yet it serves as a good example by illustrating how each test in QUnit is implemented by the QUnit test fixture. The first argument is simply a String which describes the test case. This is quite convenient in that the intent of a particular test case can be expressed more naturally in textual form as opposed to using a long, descriptive test method name. The Second argument contains the actual test implementation itself, which is defined as an anonymous function and passed as an argument to QUnit.test.

As you may have also noticed from the above example, there are some, perhaps subtle, differences between the QUnit style of testing and the traditional xUnit style. Specifically, whereas in xUnit assertions expected values are specified first and preceded by actuals, in QUnit actuals are specified first followed by expected values. This may feel a bit odd at first however, after a few tests it’s easy to get used to. Additionally, where an assertion message is specified before any arguments in xUnit, in QUnit assertion messages are specified after all arguments. With regard to test descriptions, this is a difference I prefer as, a test message is always optional so passing this value last make sense. While somewhat subtle differences, these are worth noting.

A Complete Example

As code can typically convey much more information than any lengthy article could ever hope to achieve, I have provided a simple, yet complete, example which demonstrates a basic qUnit test implementation. (run) (source).

September 19, 2011 CSS3 / HTML5 / JavaScript / Refactoring / Software Engineering / TDD / BDD / UX Design

1 Comment

Tracking HTML5 Support in Chrome

Google has now made it easy to track the current implementation status of HTML5 in Chrome via The Chromium Projects’ new Web Platform Status page.

Many of the sections have links to their html5rocks site, which provide further details and more in-depth tutorials of implemented specifications.

The current sections include:

This is certainly something to keep an eye on as, Chrome is setting the standard in terms of HTML5 support by desktop browser vendors.

September 18, 2011 APIs / Browsers / CSS3 / HTML5 / JavaScript

Comments Off

HTML5 Elements: The <base> Tag

The HTML5 Specification introduces many new semantic elements, as well as specifications for existing elements; one of which is the <base> Tag, which allows for specifying a root URL from which all linkable elements in a document (hyperlinks, images etc.) are based, as well as a default target for all linkable elements.

Overview

The <base> Tag provides two attributes; href (Hyper-text Reference) and target, respectively, which have the same semantic meaning as that of a hyperlink.
Only a single <base> Tag is to be defined per page and, must be defined before any elements which except a URL are defined (other than the html element).

Note: While the <base> Tag is not new to HTML5, the changes to the a Tag implies a difference (albeit, marginal) as, a Tags are always hyperlinks, or placeholders for hyperlinks.

Example

Like all HTML markup, usage of the <base> Tag is easy and straightforward: Simply add a single <base> Tag in the <head> element of the document and define either a base URL and / or default target attribute.

Defining a default base URL and target:

<!DOCTYPE html>

<html>

<head>

</head>

<body>

<nav>

<a href="aboutus.php">About Us</a>

<a href="contactus.php">Contact Us</a>

</nav>

</body>

</html>

The above links will all default to a blank target (new page), with each link’s base URL defaulting to “http://somedomain/app”. Individual links can override the base URL as well as the default target.

Support

The <base> Tag is currently supported by all major browsers.

September 1, 2011 HTML5

Comments Off

Map Remote in Charles

Of the many Network Debuggers available, for years I have, and continue to find, Charles to be a choice Web Debugging Proxy by all standards. This is largely due to its capabilities and many useful features, some of which are a bit less obvious than others.

One such example is the Map Remote feature which allows for the mapping of local URLs to remote URLs. This can be extremely useful as it allows for testing against many different environments without the need to change URLs or Endpoints in code.

Map Remote

As the name implies, Map Remote allows for mapping requests made to a local resource to be forwarded (transparently) to a Remote resource. So, for example, a local service at http://localhost:8080/some-app/some-service could be mapped to a remote service at http://dev.somedomain/some-app/some-service via a simple configuration using Map Remote. Moreover, Map Remote can be configured to map an individual resource (such as the previous example), all resources within a sub directory, all resources in a domain, all resources in a local subdirectory to a completely different remote subdirectory or all resources for a given suffix.

To configure the mapping of a local resource to a remote resource, in Charles, from the Main Menu select:

Tools
Map Remote
Click “Enable Map Remote” from the Map Remote Dialog
Paste the Local resource URL in the top “Map From” section (Charles will parse and auto-fill the protocol, port etc. from the host value provided)
Paste the Remote resource URL in the bottom “Map To” section

Once completed you will see the mapping in the resulting dialog and the mappings will be made when using Charles until they are removed or the “Enable Map Remote” setting is turned off. Additional Mappings can be added following the same steps and existing mappings can be removed or edited by double clicking on them. The only improvement I would like to see added is the ability to “clone” an existing mapping so as to quickly configure a slightly different mapping without the need to start from scratch.

There is also a Map Local Feature in Charles which is essentially the inverse operation of Map Remote and can be quite useful as well.

If you regularly test against different environments and use Charles then I highly suggest trying Map Remote. For more information, check out the Charles Documentation.

August 22, 2011 News

Comments Off

The convergence of Mobile and Desktop UI Design

Successful User Experience and User Interface Designs are inherently intuitive and simple. Not necessarily simple in the “less is more” aspect alone; but rather in that the designs focus on essential tasks – and provide an experience which allows for completing those tasks easily and efficiently.

With this in mind it is not surprising that many modern Desktop UI Designs are being influenced by Smartphone UIs; for they, by necessity of constraint, address many design challenges which can be easily overlooked in Desktop UI Designs.

Both Apple and Microsoft have borrowed from their respective Mobile designs in their latest Desktop OS offerings; Lion and Windows 8.

Ultimately, I believe this convergence of the Mobile and Desktop paradigms will lead to better User Experiences. In fact, I have been leveraging many mobile concepts in Desktop UIs for some time now to much success.

July 4, 2011 Software Engineering / UX Design

4 Comments