Skip navigation
Help

web services

warning: Creating default object from empty value in /var/www/vhosts/sayforward.com/subdomains/recorder/httpdocs/modules/taxonomy/taxonomy.pages.inc on line 33.
Original author: 
r_adams

Moving from physical servers to the "cloud" involves a paradigm shift in thinking. Generally in a physical environment you care about each invididual host; they each have their own static IP, you probably monitor them individually, and if one goes down you have to get it back up ASAP. You might think you can just move this infrastructure to AWS and start getting the benefits of the "cloud" straight away. Unfortunately, it's not quite that easy (believe me, I tried). You need think differently when it comes to AWS, and it's not always obvious what needs to be done.

So, inspired by Sehrope Sarkuni's recent post, here's a collection of AWS tips I wish someone had told me when I was starting out. These are based on things I've learned deploying various applications on AWS both personally and for my day job. Some are just "gotcha"'s to watch out for (and that I fell victim to), some are things I've heard from other people that I ended up implementing and finding useful, but mostly they're just things I've learned the hard way.

0
Your rating: None
Original author: 
Ben Cherian

software380

Image copyright isak55

In every emerging technology market, hype seems to wax and wane. One day a new technology is red hot, the next day it’s old hat. Sometimes the hype tends to pan out and concepts such as “e-commerce” become a normal way to shop. Other times the hype doesn’t meet expectations, and consumers don’t buy into paying for e-commerce using Beenz or Flooz. Apparently, Whoopi Goldberg and a slew of big name VCs ended up making a bad bet on the e-currency market in the late 1990s. Whoopi was paid in cash and shares of Flooz. At least, she wasn’t paid in Flooz alone! When investing, some bets are great and others are awful, but often, one only knows the awful ones in retrospect.

What Does “Software Defined” Mean?

In the infrastructure space, there is a growing trend of companies calling themselves “software defined (x).” Often, it’s a vendor that is re-positioning a decades-old product. On occasion, though, it’s smart, nimble startups and wise incumbents seeing a new way of delivering infrastructure. Either way, the term “software defined” is with us to stay, and there is real meaning and value behind it if you look past the hype.

There are three software defined terms that seem to be bandied around quite often: software defined networking, software defined storage, and the software defined data center. I suspect new terms will soon follow, like software defined security and software defined management. What all these “software-defined” concepts really boil down to is: Virtualization of the underlying component and accessibility through some documented API to provision, operate and manage the low-level component.

This trend started once Amazon Web Services came onto the scene and convinced the world that the data center could be abstracted into much smaller units and could be treated as disposable pieces of technology, which in turn could be priced as a utility. Vendors watched Amazon closely and saw how this could apply to the data center of the future.

Since compute was already virtualized by VMware and Xen, projects such as Eucalyptus were launched with the intention to be a “cloud controller” that would manage the virtualized servers and provision virtual machines (VMs). Virtualized storage (a.k.a. software defined storage) was a core part of the offering and projects like OpenStack Swift and Ceph showed the world that storage could be virtualized and accessed programmatically. Today, software defined networking is the new hotness and companies like Midokura, VMware/Nicira, Big Switch and Plexxi are changing the way networks are designed and automated.

The Software Defined Data Center

The software defined data center encompasses all the concepts of software defined networking, software defined storage, cloud computing, automation, management and security. Every low-level infrastructure component in a data center can be provisioned, operated, and managed through an API. Not only are there tenant-facing APIs, but operator-facing APIs which help the operator automate tasks which were previously manual.

An infrastructure superhero might think, “With great accessibility comes great power.” The data center of the future will be the software defined data center where every component can be accessed and manipulated through an API. The proliferation of APIs will change the way people work. Programmers who have never formatted a hard drive will now be able to provision terabytes of data. A web application developer will be able to set up complex load balancing rules without ever logging into a router. IT organizations will start automating the most mundane tasks. Eventually, beautiful applications will be created that mimic the organization’s process and workflow and will automate infrastructure management.

IT Organizations Will Respond and Adapt Accordingly

Of course, this means the IT organization will have to adapt. The new base level of knowledge in IT will eventually include some sort of programming knowledge. Scripted languages like Ruby and Python will soar even higher in popularity. The network administrators will become programmers. The system administrators will become programmers. During this time, DevOps (development + operations) will make serious inroads in the enterprise and silos will be refactored, restructured or flat-out broken down.

Configuration management tools like Chef and Puppet will be the glue for the software defined data center. If done properly, the costs around delivering IT services will be lowered. “Ghosts in the system” will watch all the components (compute, storage, networking, security, etc.) and adapt to changes in real-time to increase utilization, performance, security and quality of service. Monitoring and analytics will be key to realizing this software defined future.

Big Changes in Markets Happen With Very Simple Beginnings

All this amazing innovation comes from two very simple concepts — virtualizing the underlying components and making it accessible through an API.

The IT world might look at the software defined data center and say this is nothing new. We’ve been doing this since the 80s. I disagree. What’s changed is our universal thinking about accessibility. Ten years ago, we wouldn’t have blinked if a networking product came out without an API. Today, an API is part of what we consider a 1.0 release. This thinking is pervasive throughout the data center today with every component. It’s Web 2.0 thinking that shaped cloud computing and now cloud computing is bleeding into enterprise thinking. We’re no longer constrained by the need to have deep specialized knowledge in the low-level components to get basic access to this technology.

With well documented APIs, we have now turned the entire data center into many instruments that can be played by the IT staff (musicians). I imagine the software defined data center to be a Fantasia-like world where Mickey is the IT staff and the brooms are networking, storage, compute and security. The magic is in the coordination, cadence and rhythm of how all the pieces work together. Amazing symphonies of IT will occur in the near future and this is the reason the software defined data center is not a trend to overlook. Maybe Whoopi should take a look at this market instead.

Ben Cherian is a serial entrepreneur who loves playing in the intersection of business and technology. He’s currently the Chief Strategy Officer at Midokura, a network virtualization company. Prior to Midokura, he was the GM of Emerging Technologies at DreamHost, where he ran the cloud business unit. Prior to that, Ben ran a cloud-focused managed services company.

0
Your rating: None
Original author: 
(author unknown)

Jeremy Keith notes that what happens between the breakpoints is just as important as the breakpoints themselves—perhaps even more so. While I agree with this, we do have to start somewhere. In a way, this part of the process reminds me of storyboarding, or creating animation keyframes, with the in-between frames being developed later. We’re going to do that here.

Major breakpoints are conditions that, when met, trigger major changes in your design. A major breakpoint might be, for example, where your entire layout must change from two columns to four.

Let’s say you’ve chosen three basic design directions from your thumbnails. Think about what your major breakpoints will look like (Figure 7.6). And here’s the key: try to come up with as few major breakpoints as possible. That might sound crazy, since we’re talking about responsive design. After all, we have media queries, so let’s use about 12 of them, right? No! If a linear layout works for every screen and is appropriate for your particular concept, then there’s no need for different layouts. In that case, simply describe what will happen when the screen gets larger. Will everything generally stay the same, with changes only to font size, line height and margins? If so, sketch those. For these variations, make thumbnails first, explore some options, and then move on to larger, more detailed sketches. Use your breakpoint graph as a guide at first and make sketches according to the breakpoints you’ve estimated on your graph.

When thinking about major breakpoints, remember to think about device classes. If you’re thinking about smartphones, tablets, laptops/desktops, TVs, and game consoles, for example, you’re heading in the right direction. If you’re thinking in terms of brand names and specific operating systems, you’re on the wrong track. The idea is to think in terms of general device classifications and, sometimes, device capabilities. Capabilities are more important when designing web applications, since you should be thinking about what screens will look like both with and without any particular capability.

Rough sketches of major breakpoints can help you determine:

Rough sketches are more detailed than thumbnails, but they shouldn’t take a long time to create. In a short period, you should have a sketch of each major breakpoint for each of your chosen designs. This should be enough to decide on one of the designs.

  • Whether or not more major breakpoints are needed
  • Which design choice will be the most labor intensive; you might opt for a design that will better fit within time and budget constraints
  • Whether or not a particular device class has been neglected or needs further consideration
  • What technologies you’ll need to develop the design responsively


Figure 7.6: Most websites need very few major breakpoints.

Minor breakpoints are conditions that, when met, trigger small changes in your design. An example would be moving form labels from above text fields to the left of those fields, while the rest of the design remains the same.

So where and when will you sketch minor breakpoints? In the browser, when you do your web-based mockup. You’ll find out why and how in the next chapter. In the meantime, simply focus on making sketches of the state of your web pages or app screens at the major breakpoints of each design.

At this point, don’t worry too much if you notice that the initial breakpoints on your breakpoint graph simply won’t do. Those were just a starting point, and you’re free to revise your estimate based on your sketches. You might even decide that you need an extra breakpoint for a given design and record that in sketch form; you can add that breakpoint to your graph. This is a cycle of discovery, learning, and revision.

Think about your content while sketching

While sketching, you’ll certainly be thinking about the way things should look. My experience is that much UI sketching of this type revolves around the layout of elements on the screen. I’ve found it useful to keep thinking about the content while sketching, and to consider what will happen to the content in various situations. When designing responsively, it can be useful to consider how you’ll handle the following content in particular:

  • Text
  • Navigation
  • Tables

Oh, sure, there are many more things to consider, and you’ll end up creating your own list of “things to do some extra thinking about” as the project progresses. For now, let’s take a look at the items listed above.

Text

Before you say, “Hey, wait a minute, didn’t you just tell me that I didn’t have to draw text while sketching?” hear me out. While sketching, there are a couple of text-related issues you’ll need to tackle: column width and text size, both of which are relevant in proportion to the screen and the other elements on the page.

Column width is fairly obvious, but it can be difficult to estimate how wide a column will be with actual text. In this case, sketching on a device might give you a better idea of the actual space you have to work with. Another method I’ve used is just to make a simple HTML page that contains only text, and load that into a device’s browser (or even an emulator, which while not optimal still gives a more realistic impression than lines on paper). When the text seems too large or too small, you can adjust the font size accordingly. Once it seems right, you’ll be able to make your sketches a bit more realistic.

Note: Distinguish between touchability and clickability. Many designers, myself included, have made the mistake of refining links for people who click on them using a mouse, or even via the keyboard, without considering how touchable these links are for people on touch devices.

Think about the size of links—not only the text size, but also the amount of space around them. Both of these factors play a role in the touchability or clickability of links (and buttons): large links and buttons are easier targets, but slightly smaller links with plenty of space around them can work just as well. That said, there’s a decent chance that no matter what you choose to sketch, you’ll end up making changes again when you create your mockups.

This is the great thing about sketching that I can’t repeat often enough: you’re going to refine your design in the browser anyway, so the speed with which you can try things out when sketching means you won’t have to do detail work more than once (unless your client has changes, but we all know that never happens).

Navigation

Navigation is another poster child for sketching on actual devices. The size issues are the same as with links, but there’s a lot more thinking to do in terms of the design of navigation for various devices, which means navigation might change significantly at each major breakpoint.

Think back to Bryan Rieger’s practice of designing in text first, and ponder what you would do before the very first breakpoint if you had only plain HTML and CSS at your disposal—in other words, if you had no JavaScript. That means no, you can’t have your menu collapsed at the top of the screen and have it drop down when someone touches it. If you have your menu at the top, it’s in its expanded form and takes up all the vertical space it normally would.

This is a controversial enough subject, with even accessibility gurus in disagreement: JavaScript, after all, is currently considered an “accessibility supported” technology. But this isn’t necessarily about accessibility. It’s about thinking about what happens when a browser lacks JavaScript support, or if the JavaScript available on the device is different than what you’d expect. Your content will be presented in a certain way before JavaScript does its thing with it, no matter what the browser. So why not think about what that initial state will be?

In the chapter on wireframes, I talked about my preferred pattern for navigation on the smallest screens: keep it near the bottom of the screen and place a link to that navigation near the top of the screen. JavaScript, when available and working as expected, can move that navigation up to the top and create the drop-down menu on the fly.

But a pattern is not design law, so how you choose to handle the smallest screens will depend on your project. If I had only a few links in my navigation, I might very well put the menu at the top from the very start, and there it would stay at every breakpoint.

Remember that JavaScript and CSS let you do a lot of rearranging of stuff on the screen. That knowledge should empower you to safely design a great page with plain HTML and use JavaScript and CSS to spice it up any way you like. This is the essence of progressive enhancement.

Tables

Tables! Oh, the bane of the responsive designer (or wait, is that images? Or video? Or layout? Ahem). Tables are tough to deal with on small screens. I’d love to tell you I have all the answers, but instead I have more questions. Hopefully, these will lead you to a solution. It’s good to think about these while you’re sketching.

First of all, what types of tables will you be dealing with? Narrow? Wide? Numerical? Textual? Your content inventory should give you enough information to answer these simple questions. Once you’ve considered those, try to categorize the types of tables you have into something like the following classes (Figure 7.7):

  • Small-screen-friendly tables, which you’ll probably leave as they are, because they’re small enough and will work fine on most small screens.
  • Blockable tables, which you can alter with CSS so that each row in the table functions visually as a block item in a list (Figure 7.8).
  • Chartable tables, which contain numerical data that can be transformed into a chart, graph, or other visualization that will take up less space on a small screen.
  • Difficult tables, which are hard enough to deal with that you’ll need to come up with a different plan for them, sometimes even on a case-by-case basis. These are our enemies, but unfortunately, are the friends of our clients, who all love Microsoft Excel. Oh well.


Figure 7.7: There are several different types of tables, and different ways of dealing with them on small screens. (Sources: mobilism.nl and eu-verantwoording.nl)


Figure 7.8: One way of dealing with small screen tables is to treat each row as a block.

Thinking again in terms of progressive enhancement, the base design should probably just include the whole table, which means that the user will have to scroll horizontally to see the whole thing in many cases. On top of this, we can employ CSS and JavaScript, when they’re available, to do some magic for us. Blockable and chartable tables can be blocked with CSS and charted with JavaScript. Plenty of designers and developers have experimented with many different options for tables, from simply making the table itself scrollable to exchanging columns and rows.

The fun part is that what you do on small screens isn’t necessarily what you’ll do on larger screens. That’s why now—when all you have to do is sketch and it won’t take much time—is the time to think about the changes you’ll be making at each breakpoint.

What to do if you get stuck

Every designer gets stuck at some point. It’s no big deal unless you treat it like one. There are countless ways to deal with it, from asking yourself what if questions (“What if it weren’t a table, but a list?” is what I asked myself before “blockifying” the attendees table for the Mobilism site) to the cliché taking a shower, which you hopefully do on a regular basis anyway. The reason this chapter focuses so much on sketching is because the act of drawing itself can actually stimulate your brain to come up with more ideas, provided you push it hard enough by sketching past your comfort zone of first-come ideas.

If your problem is that you’re stuck creatively, there are many inspiring books and resources to get your creative engine started during the bitter cold of designer’s block. Although there are plenty of resources on design and creativity itself (try such classics as Edward de Bono’s Lateral Thinking), the greatest inspiration can come from sources outside the realm of design.1 Trying to combine things that normally aren’t combined can lead to surprising results. It’s a simple little trick, but I’ve often used Brian Eno and Peter Schmidt’s Oblique Strategies to force me to take a different approach.2 Worst case, it’s a lot of fun. Best case, you’ve got a great idea!

If your problem is that you’re not sure how to handle something in the context of responsive design, there’s no harm in researching how others have solved problems like yours. Just be sure to use your creativity and tailor any ideas you might find to your own situation; after all, you’re a designer. At the time of this writing I find Brad Frost’s This Is Responsive to be one of the most exhaustive collections of responsive design patterns and resources available.3 You can spend hours going through there and you’ll certainly come across something that will get you unstuck.

Excerpted from Responsive Design Workflow by Stephen Hay. Copyright © 2013.
Used with permission of Pearson Education, Inc. and New Riders.

0
Your rating: None
Original author: 
Jon Brodkin

Aurich Lawson / Thinkstock

It's time to ask yourself an uncomfortable question: how many of your passwords are so absurdly weak that they might as well provide no security at all? Those of you using "123456," "abc123," or even just "password" might already know it's time to make some changes. And using pets' names, birth dates, your favorite sports teams, or adding a number or capital letter to a weak password isn't going to be enough.

Don’t worry, we're here to help. We’re going to focus on how to use a password manager, software that can help you go from passwords like "111111" to "6WKBTSkQq8Zn4PtAjmz7" without making you want to pull out all your hair. For good measure, we'll talk about how creating fictitious answers to password reset questions (e.g. mother's maiden name) can make you even more resistant to hacking.

Why you can’t just wing it anymore

A password manager helps you create long, complicated passwords for websites and integrates into your browser, automatically filling in your usernames and passwords. Instead of typing a different password into each site you visit, you only have to remember one master password.

Read 83 remaining paragraphs | Comments

0
Your rating: None
Original author: 
Megan Geuss


List your passwords alphabetically, so it's easy for you and others to find them!

Give three password crackers a list of 16,000 cryptographically hashed passwords and ask them to come up with the plaintext phrases they correspond to. That's what Ars did this week in Dan Goodin's Anatomy of a hack: How crackers ransack passwords like “qeadzcwrsfxv1331.” Turns out, with just a little skill and some good hardware, three prominent password crackers were able to decode up to 90 percent of the list using common techniques.

The hashes the security experts used were converted using the MD5 cryptographic hash function, something that puzzled our readers a bit. MD5 is seen as a relatively weak hash function compared to hashing functions like bcrypt. flunk wrote, "These articles are interesting but this particular test isn't very relevant. MD5 wasn't considered a secure way to hash passwords 10 years ago, let alone now. Why wasn't this done with bcrypt and salting? That's much more realistic. Giving them a list of passwords that is encrypted in a way that would be considered massively incompetent in today's IT world isn't really a useful test."

To this, Goodin replied that plenty of Web services employ weak security practices: "This exercise was entirely relevant given the huge number of websites that use MD5, SHA1, and other fast functions to hash passwords. Only when MD5 is no longer used will exercises like this be irrelevant." Goodin later went on to cite the recent compromises of "LinkedIn, eHarmony, and LivingSocial," which were all using "fast hashing" techniques similar to MD5.

Read 14 remaining paragraphs | Comments

0
Your rating: None
Original author: 
(author unknown)

Three years ago in these pages, ALA technical editor Ethan Marcotte fired the shot heard ’round the web. ALA designer Mike Pick thought it might be fun to celebrate the third anniversary of “Responsive Web Design” (A List Apart Issue No. 306, May 25, 2010) by secreting an Easter Egg in the original article; our illustrator, Kevin Cornell, rose to the challenge.

To see it in action, visit alistapart.com/article/responsive-web-design, grab the edge of the browser window (device permitting), and perform the responsive resize mambo. (ALA’s Tim Murtaugh, who coded the Easter Egg, has provided a handy video demo of what you’ll see.)

0
Your rating: None
Original author: 
(author unknown)

We’ve all been there: that bit of JavaScript functionality that started out as just a handful of lines grows to a dozen, then two dozen, then more. Along the way, a function picks up a few more arguments; a conditional picks up a few more conditions. And then one day, the bug report comes in: something’s broken, and it’s up to us to untangle the mess.

As we ask our client-side code to take on more and more responsibilities—indeed, whole applications are living largely in the browser these days—two things are becoming clear. One, we can’t just point and click our way through testing that things are working as we expect; automated tests are key to having confidence in our code. Two, we’re probably going to have to change how we write our code in order to make it possible to write tests.

Really, we need to change how we code? Yes—because even if we know that automated tests are a good thing, most of us are probably only able to write integration tests right now. Integration tests are valuable because they focus on how the pieces of an application work together, but what they don’t do is tell us whether individual units of functionality are behaving as expected.

That’s where unit testing comes in. And we’ll have a very hard time writing unit tests until we start writing testable JavaScript.

Unit vs. integration: what’s the difference?

Writing integration tests is usually fairly straightforward: we simply write code that describes how a user interacts with our app, and what the user should expect to see as she does. Selenium is a popular tool for automating browsers. Capybara for Ruby makes it easy to talk to Selenium, and there are plenty of tools for other languages, too.

Here’s an integration test for a portion of a search app:

def test_search
  fill_in('q', :with => 'cat')
  find('.btn').click
  assert( find('#results li').has_content?('cat'), 'Search results are shown' )
  assert( page.has_no_selector?('#results li.no-results'), 'No results is not shown' )
end

Whereas an integration test is interested in a user’s interaction with an app, a unit test is narrowly focused on a small piece of code:

When I call a function with a certain input, do I receive the expected output?

Apps that are written in a traditional procedural style can be very difficult to unit test—and difficult to maintain, debug, and extend, too. But if we write our code with our future unit testing needs in mind, we will not only find that writing the tests becomes more straightforward than we might have expected, but also that we’ll simply write better code, too.

To see what I’m talking about, let’s take a look at a simple search app:

Srchr

When a user enters a search term, the app sends an XHR to the server for the corresponding data. When the server responds with the data, formatted as JSON, the app takes that data and displays it on the page, using client-side templating. A user can click on a search result to indicate that he “likes” it; when this happens, the name of the person he liked is added to the “Liked” list on the right-hand side.

A “traditional” JavaScript implementation of this app might look like this:

var tmplCache = {};

function loadTemplate (name) {
  if (!tmplCache[name]) {
    tmplCache[name] = $.get('/templates/' + name);
  }
  return tmplCache[name];
}

$(function () {

  var resultsList = $('#results');
  var liked = $('#liked');
  var pending = false;

  $('#searchForm').on('submit', function (e) {
    e.preventDefault();

    if (pending) { return; }

    var form = $(this);
    var query = $.trim( form.find('input[name="q"]').val() );

    if (!query) { return; }

    pending = true;

    $.ajax('/data/search.json', {
      data : { q: query },
      dataType : 'json',
      success : function (data) {
        loadTemplate('people-detailed.tmpl').then(function (t) {
          var tmpl = _.template(t);
          resultsList.html( tmpl({ people : data.results }) );
          pending = false;
        });
      }
    });

    $('<li>', {
      'class' : 'pending',
      html : 'Searching &hellip;'
    }).appendTo( resultsList.empty() );
  });

  resultsList.on('click', '.like', function (e) {
    e.preventDefault();
    var name = $(this).closest('li').find('h2').text();
    liked.find('.no-results').remove();
    $('<li>', { text: name }).appendTo(liked);
  });

});

My friend Adam Sontag calls this Choose Your Own Adventure code—on any given line, we might be dealing with presentation, or data, or user interaction, or application state. Who knows! It’s easy enough to write integration tests for this kind of code, but it’s hard to test individual units of functionality.

What makes it hard? Four things:

  • A general lack of structure; almost everything happens in a $(document).ready() callback, and then in anonymous functions that can’t be tested because they aren’t exposed.
  • Complex functions; if a function is more than 10 lines, like the submit handler, it’s highly likely that it’s doing too much.
  • Hidden or shared state; for example, since pending is in a closure, there’s no way to test whether the pending state is set correctly.
  • Tight coupling; for example, a $.ajax success handler shouldn’t need direct access to the DOM.

Organizing our code

The first step toward solving this is to take a less tangled approach to our code, breaking it up into a few different areas of responsibility:

  • Presentation and interaction
  • Data management and persistence
  • Overall application state
  • Setup and glue code to make the pieces work together

In the “traditional” implementation shown above, these four categories are intermingled—on one line we’re dealing with presentation, and two lines later we might be communicating with the server.

Code Lines

While we can absolutely write integration tests for this code—and we should!—writing unit tests for it is pretty difficult. In our functional tests, we can make assertions such as “when a user searches for something, she should see the appropriate results,” but we can’t get much more specific. If something goes wrong, we’ll have to track down exactly where it went wrong, and our functional tests won’t help much with that.

If we rethink how we write our code, though, we can write unit tests that will give us better insight into where things went wrong, and also help us end up with code that’s easier to reuse, maintain, and extend.

Our new code will follow a few guiding principles:

  • Represent each distinct piece of behavior as a separate object that falls into one of the four areas of responsibility and doesn’t need to know about other objects. This will help us avoid creating tangled code.
  • Support configurability, rather than hard-coding things. This will prevent us from replicating our entire HTML environment in order to write our tests.
  • Keep our objects’ methods simple and brief. This will help us keep our tests simple and our code easy to read.
  • Use constructor functions to create instances of objects. This will make it possible to create “clean” copies of each piece of code for the sake of testing.

To start with, we need to figure out how we’ll break our application into different pieces. We’ll have three pieces dedicated to presentation and interaction: the Search Form, the Search Results, and the Likes Box.

Application Views

We’ll also have a piece dedicated to fetching data from the server and a piece dedicated to gluing everything together.

Let’s start by looking at one of the simplest pieces of our application: the Likes Box. In the original version of the app, this code was responsible for updating the Likes Box:

var liked = $('#liked');

var resultsList = $('#results');


// ...


resultsList.on('click', '.like', function (e) {
  e.preventDefault();

  var name = $(this).closest('li').find('h2').text();

  liked.find( '.no-results' ).remove();

  $('<li>', { text: name }).appendTo(liked);

});

The Search Results piece is completely intertwined with the Likes Box piece and needs to know a lot about its markup. A much better and more testable approach would be to create a Likes Box object that’s responsible for manipulating the DOM related to the Likes Box:

var Likes = function (el) {
  this.el = $(el);
  return this;
};

Likes.prototype.add = function (name) {
  this.el.find('.no-results').remove();
  $('<li>', { text: name }).appendTo(this.el);
};

This code provides a constructor function that creates a new instance of a Likes Box. The instance that’s created has an .add() method, which we can use to add new results. We can write a couple of tests to prove that it works:

var ul;

setup(function(){
  ul = $('<ul><li class="no-results"></li></ul>');
});

test('constructor', function () {
  var l = new Likes(ul);
  assert(l);
});

test('adding a name', function () {
  var l = new Likes(ul);
  l.add('Brendan Eich');

  assert.equal(ul.find('li').length, 1);
  assert.equal(ul.find('li').first().html(), 'Brendan Eich');
  assert.equal(ul.find('li.no-results').length, 0);
});

Not so hard, is it? Here we’re using Mocha as the test framework, and Chai as the assertion library. Mocha provides the test and setup functions; Chai provides assert. There are plenty of other test frameworks and assertion libraries to choose from, but for the sake of an introduction, I find these two work well. You should find the one that works best for you and your project—aside from Mocha, QUnit is popular, and Intern is a new framework that shows a lot of promise.

Our test code starts out by creating an element that we’ll use as the container for our Likes Box. Then, it runs two tests: one is a sanity check to make sure we can make a Likes Box; the other is a test to ensure that our .add() method has the desired effect. With these tests in place, we can safely refactor the code for our Likes Box, and be confident that we’ll know if we break anything.

Our new application code can now look like this:

var liked = new Likes('#liked');
var resultsList = $('#results');



// ...



resultsList.on('click', '.like', function (e) {
  e.preventDefault();

  var name = $(this).closest('li').find('h2').text();

  liked.add(name);
});

The Search Results piece is more complex than the Likes Box, but let’s take a stab at refactoring that, too. Just as we created an .add() method on the Likes Box, we also want to create methods for interacting with the Search Results. We’ll want a way to add new results, as well as a way to “broadcast” to the rest of the app when things happen within the Search Results—for example, when someone likes a result.

var SearchResults = function (el) {
  this.el = $(el);
  this.el.on( 'click', '.btn.like', _.bind(this._handleClick, this) );
};

SearchResults.prototype.setResults = function (results) {
  var templateRequest = $.get('people-detailed.tmpl');
  templateRequest.then( _.bind(this._populate, this, results) );
};

SearchResults.prototype._handleClick = function (evt) {
  var name = $(evt.target).closest('li.result').attr('data-name');
  $(document).trigger('like', [ name ]);
};

SearchResults.prototype._populate = function (results, tmpl) {
  var html = _.template(tmpl, { people: results });
  this.el.html(html);
};

Now, our old app code for managing the interaction between Search Results and the Likes Box could look like this:

var liked = new Likes('#liked');
var resultsList = new SearchResults('#results');


// ...


$(document).on('like', function (evt, name) {
  liked.add(name);
})

It’s much simpler and less entangled, because we’re using the document as a global message bus, and passing messages through it so individual components don’t need to know about each other. (Note that in a real app, we’d use something like Backbone or the RSVP library to manage events. We’re just triggering on document to keep things simple here.) We’re also hiding all the dirty work—such as finding the name of the person who was liked—inside the Search Results object, rather than having it muddy up our application code. The best part: we can now write tests to prove that our Search Results object works as we expect:

var ul;
var data = [ /* fake data here */ ];

setup(function () {
  ul = $('<ul><li class="no-results"></li></ul>');
});

test('constructor', function () {
  var sr = new SearchResults(ul);
  assert(sr);
});

test('display received results', function () {
  var sr = new SearchResults(ul);
  sr.setResults(data);

  assert.equal(ul.find('.no-results').length, 0);
  assert.equal(ul.find('li.result').length, data.length);
  assert.equal(
    ul.find('li.result').first().attr('data-name'),
    data[0].name
  );
});

test('announce likes', function() {
  var sr = new SearchResults(ul);
  var flag;
  var spy = function () {
    flag = [].slice.call(arguments);
  };

  sr.setResults(data);
  $(document).on('like', spy);

  ul.find('li').first().find('.like.btn').click();

  assert(flag, 'event handler called');
  assert.equal(flag[1], data[0].name, 'event handler receives data' );
});

The interaction with the server is another interesting piece to consider. The original code included a direct $.ajax() request, and the callback interacted directly with the DOM:

$.ajax('/data/search.json', {
  data : { q: query },
  dataType : 'json',
  success : function( data ) {
    loadTemplate('people-detailed.tmpl').then(function(t) {
      var tmpl = _.template( t );
      resultsList.html( tmpl({ people : data.results }) );
      pending = false;
    });
  }
});

Again, this is difficult to write a unit test for, because so many different things are happening in just a few lines of code. We can restructure the data portion of our application as an object of its own:

var SearchData = function () { };

SearchData.prototype.fetch = function (query) {
  var dfd;

  if (!query) {
    dfd = $.Deferred();
    dfd.resolve([]);
    return dfd.promise();
  }

  return $.ajax( '/data/search.json', {
    data : { q: query },
    dataType : 'json'
  }).pipe(function( resp ) {
    return resp.results;
  });
};

Now, we can change our code for getting the results onto the page:

var resultsList = new SearchResults('#results');

var searchData = new SearchData();

// ...

searchData.fetch(query).then(resultsList.setResults);

Again, we’ve dramatically simplified our application code, and isolated the complexity within the Search Data object, rather than having it live in our main application code. We’ve also made our search interface testable, though there are a couple caveats to bear in mind when testing code that interacts with the server.

The first is that we don’t want to actually interact with the server—to do so would be to reenter the world of integration tests, and because we’re responsible developers, we already have tests that ensure the server does the right thing, right? Instead, we want to “mock” the interaction with the server, which we can do using the Sinon library. The second caveat is that we should also test non-ideal paths, such as an empty query.

test('constructor', function () {
  var sd = new SearchData();
  assert(sd);
});

suite('fetch', function () {
  var xhr, requests;

  setup(function () {
    requests = [];
    xhr = sinon.useFakeXMLHttpRequest();
    xhr.onCreate = function (req) {
      requests.push(req);
    };
  });

  teardown(function () {
    xhr.restore();
  });

  test('fetches from correct URL', function () {
    var sd = new SearchData();
    sd.fetch('cat');

    assert.equal(requests[0].url, '/data/search.json?q=cat');
  });

  test('returns a promise', function () {
    var sd = new SearchData();
    var req = sd.fetch('cat');

    assert.isFunction(req.then);
  });

  test('no request if no query', function () {
    var sd = new SearchData();
    var req = sd.fetch();
    assert.equal(requests.length, 0);
  });

  test('return a promise even if no query', function () {
    var sd = new SearchData();
    var req = sd.fetch();

    assert.isFunction( req.then );
  });

  test('no query promise resolves with empty array', function () {
    var sd = new SearchData();
    var req = sd.fetch();
    var spy = sinon.spy();

    req.then(spy);

    assert.deepEqual(spy.args[0][0], []);
  });

  test('returns contents of results property of the response', function () {
    var sd = new SearchData();
    var req = sd.fetch('cat');
    var spy = sinon.spy();

    requests[0].respond(
      200, { 'Content-type': 'text/json' },
      JSON.stringify({ results: [ 1, 2, 3 ] })
    );

    req.then(spy);

    assert.deepEqual(spy.args[0][0], [ 1, 2, 3 ]);
  });
});

For the sake of brevity, I’ve left out the refactoring of the Search Form, and also simplified some of the other refactorings and tests, but you can see a finished version of the app here if you’re interested.

When we’re done rewriting our application using testable JavaScript patterns, we end up with something much cleaner than what we started with:

$(function() {
  var pending = false;

  var searchForm = new SearchForm('#searchForm');
  var searchResults = new SearchResults('#results');
  var likes = new Likes('#liked');
  var searchData = new SearchData();

  $(document).on('search', function (event, query) {
    if (pending) { return; }

    pending = true;

    searchData.fetch(query).then(function (results) {
      searchResults.setResults(results);
      pending = false;
    });

    searchResults.pending();
  });

  $(document).on('like', function (evt, name) {
    likes.add(name);
  });
});

Even more important than our much cleaner application code, though, is the fact that we end up with a codebase that is thoroughly tested. That means we can safely refactor it and add to it without the fear of breaking things. We can even write new tests as we find new issues, and then write the code that makes those tests pass.

Testing makes life easier in the long run

It’s easy to look at all of this and say, “Wait, you want me to write more code to do the same job?”

The thing is, there are a few inescapable facts of life about Making Things On The Internet. You will spend time designing an approach to a problem. You will test your solution, whether by clicking around in a browser, writing automated tests, or—shudder—letting your users do your testing for you in production. You will make changes to your code, and other people will use your code. Finally: there will be bugs, no matter how many tests you write.

The thing about testing is that while it might require a bit more time at the outset, it really does save time in the long run. You’ll be patting yourself on the back the first time a test you wrote catches a bug before it finds its way into production. You’ll be grateful, too, when you have a system in place that can prove that your bug fix really does fix a bug that slips through.

Additional resources

This article just scratches the surface of JavaScript testing, but if you’d like to learn more, check out:

  • My presentation from the 2012 Full Frontal conference in Brighton, UK.
  • Grunt, a tool that helps automate the testing process and lots of other things.
  • Test-Driven JavaScript Development by Christian Johansen, the creator of the Sinon library. It is a dense but informative examination of the practice of testing JavaScript.
0
Your rating: None