bar page
Zombie Not Waiting for Document to Load Fix
I was noticing that when I ran my zombie headless browser tests and dumped the state of the browser html, my dynamically inserted elements were not showing up. It turned out I had to register an ‘on done’ hook to wait for the document to fully load. This is a bit of an ant-pattern in my opinion because the visit function, being a callback, sematically feels like it should wait until the doc is ready. In any event, this seemed to work for now:
it('should have the correct title', function() {
browser.on('done', function(doc) {
console.log("DONE finally finito..");
console.log(browser.html());
expect(doc.document.title).toMatch('.*Login');
});
browser.visit(LOGIN, function(err, doc) {
asyncSpecDone();
});
asyncSpecWait();
});
I responded on Stackoverflow to a related question here: backbone.js – zombie.js visit() calling back too early (using browserify) – Stack Overflow
Filing Effective Bug Reports
Filing Bug Reports Quickly yet Effectively
I’ve worked on many teams that use some sort of internal bug tracking system to create tickets when defects are found. Usually, the reporter is either another developer or QA engineer though sometimes it may be a business development colleague like the PM. It surprises me how bad most of these tickets are when it is quite easy to file a decent ticket. The approaches vary, but at minimum there needs to be an indication of the following:
- » A clear description of the issue
- » Steps to reproduce
- » Result of said steps
- » Any user account or test data being used
- » Environment (if unique to this user; e.g. system information, etc.)
- » Screenshot(s) and logging
- » Optionally: Priority, Component, Milestone, Tags, etc.
- Assignee
Seems simple right? Yet folks don’t do it (even programmers who should really know better). I think it’s because folks are generally in a hurry and perhaps just get lazy. So what to do?
Create a bug report template
In systems like Pivotal Track, Trac, Jira, etc., there is generally a way to create a default template that a bug reporter will automatically see. This is extremely helpful and encourages better bug filing. Not only will the programmer get the information they need, they will see a generally consistent format which will allow them to quickly parse the ticket and get to work on what you really want…squashing the bug!
References
http://wiki.habariproject.org/en/File_a_Ticket
http://wiki.openmoko.org/wiki/Bug_Filing_Policy
jsfiddle in less than 3 minutes
jsfiddle in less than 3 minutes
So here’s my claim: this post will get you up and running on jsfiddle in < 3 minutes I promise! Stop posting ridiculously long and complicated snippets in to stackoverflow!
First 2 steps required:
Ok, so first hit Run to see what it does. Cool right? Now hit the Fork button on the top bar. You now have your own fiddle based on mine (which in turn, is just a fork of the jsfiddle twitter example)
Mocking HTML and JSON Requests
Here are some working html and jsonp examples. Again, just go ahead and fork these in to your account so you have a template to work from.
Um, where did all my fiddles go?
If you ever want to see all your fiddles just go to: your fiddles. Of course you need to have already logged in … duh!
Prosper and be wealthy
Now open up jsfiddle and start clicking around in the left sidebar. You must have noticed that you can select the framework you’d like included, etc. right? You noticed the links to the docs right? They’re really short; I read them in < 10 minutes (optional of course).
I hope this short tut was helpful and showed you just how low barrier jsfiddle is to start using!
References:
jsfiddle’s docs docs
tweets
css-tricks
Cool examples on Andrew Wooldridge’s blog
Deferred Objects
NOTE: This is my original article on jQuery Deferred Objects and I’m keeping it here in case folks have bookmarked. However, we have plans to continue this in to a series on: ColonelPanic
If you’re a web developer, you may be asking yourself, ‘what are these “deferred objects” I keep hearing about?’ Hopefully, this article will help explain that.
Given the asynchronous nature of the web, and specifically JavaScript, a general asynchronous callback pattern has proliferated. So you have something you need to defer a bit so you use a timeout or an interval and you’re good to go…what’s the issue you may be asking? Well…web applications have become more and more complex, and what was once a nested callback or two, is turning into a hairy beast of nested callbacks.
The Deferred pattern addresses this nested nightmare by using using an idiom much like publish/subscribe (Observer) or Notifications (if you come from the land of iOS development). However, notification is a bit different because the caller has access to the Deferred object itself and can determine whether to call success or fail callbacks. This is sort of a forward reference, but will hopefully be clearer further down in this article. That said, let’s dig in…
If you’re familiar with stacks and queues then the underlying concept should be pretty straight forward. Essentially, the Deferred object implementation keeps a stack of callback function objects (similar to subscribers) for success or failure. Conventionally, these are called done callbacks or fail callbacks. Specifically, these function objects get pushed on the Deferred object when you call .then(myfunc), .done(myfunc), or .fail(myfunc):
var deferred = new Deferred();
deferred.done(function(message) {
alert(message);
});
setTimeout(3000, function() {
deferred.resolve("Hey buddy!");
});
First we create a deferred object. Immediately, the deferred object goes in to the “Pending” state.
Next, and here’s the important part to “grok”, by calling .done(
Ok, so now we have 1..* functions queued (or stacked depending on implementation details) on the deferred object. Now one of two things will happen (at some point):
1. We call deferred.resolve (or one of it’s variants)
2. We call deferred.reject
If we do 1., this will “trigger” the deferred object to call all of the queued resolve category functions. These are the .done, .then, variant callbacks.
If we do 2., this will “trigger” the deferred object call all of the queued fail variant functions.
There are some semantic details to all of this, but that drives to the essence of the pattern. If you’re still not clear, I’ve drawn this extremely ugly diagram to help to visualize the essence of the deferred pattern (as described in both the jQuery API docs and CommonJS Promises page). Open your browser wide and start on the left and work to the right:
Cool! So how is this Deferred object doing it’s magic internally? Here’s a simplified example of how it may be implemented:
<html>
<head>
</head>
<body>
<h1>JavaScript Deferred Objects Example</h1>
<script type='text/javascript'>
function Deferred() {
var callbacks = [];
this.done = function(cb) {
callbacks.push(cb);
}
this.resolve = function(arg) {
for(var i =0; i< callbacks.length; i++) {
callbacks[i](arg);
}
}
}
// Now we use the deferred object
var deferred = new Deferred();
deferred.done(function(message) {
alert(message);
});
setTimeout(function() {
deferred.resolve("Hey buddy!");
}, 3000);
</script>
</body>
</html>
What’s interesting about this pattern is that the owner of the deferred object determines whether we go in to the resolved or rejected state not the deferred object itself. This is slightly different from how a traditional Pub/Sub pattern would work, where the Publishing object itself would likely determine who/when to callback it’s subscribers. Because of this, it’s common to see usage where an intermediary function that is supplying some service (e.g. fetchResource, hitDatabase, etc.), will negotiate the initialization of the deferred object, determine whether to call resolve or reject, etc., and simply return the deferred object. So it looks like:
The above diagram only shows part of the picture. Once the Broker object calls resolve or reject, the original caller’s respective .done, .fail, etc., will get called.
All of this is possible because of JavaScript’s ability to treat functions as first class citizens (a fancy way of saying you can pass functions around and call them later and treat them like good ol’ objects!).
I hope this posting was somewhat helpful and revealed the magic behind Deferred Objects.
EDIT
My good friend Richard Bateman offers a point of clarification. There is actually a difference between .then and .done; .then allows you to provide two callbacks, the first for done and the second for fail.
Subscribe via RSS
Subscribe by Email
