Usage

waitFor uses jQuery’s Deferred API, so its usage is clean and consistent with the rest of jQuery’s event-handling functions. To use it, call jQuery.waitFor() with a selector, and then call done(function() {...}) on the result. As soon as an element appears in the DOM that matches the given selector, your function will be called, with a jQuery object containing the matched element (or elements) as the argument. If the DOM already contains matching elements, the function will be called immediately.

You can also call fail(function() {...}) on waitFor‘s return value to trigger a callback if the element has not appeared by the time the full DOM is loaded.

Example

$.waitFor("header")
    .done(function(elements) { elements.addClass("fancy"); })
    .fail(function() { $("body").append("<p>Huh?</p>"); })

This will add the class “fancy” to the HTML5 header element as soon as it is loaded. If it hasn’t appeared by the time the document is ready, it adds a new element to the end of the document instead.

Download

Download waitFor from the jQuery plugin page.

You can also fork waitFor at Github. Please test it and send me your pull requests.

Usage notes

The function works by polling the DOM at short intervals. By default it polls every 23 milliseconds, but you can change this by setting $.waitFor.defaultIntervalMs before calling $.waitFor(). Alternatively you can pass something like {intervalMs: 100} as the third argument the first time you call $.waitFor(). But don’t bother changing this unless you really know what you’re doing.

waitFor returns a jQuery Promise object, so apart from done() and fail(), you can also call other methods on it like always() and then(). See the documentation for full details.

In order for waitFor to be useful, you will probably want to include the plugin code in your document head. Therefore you will also need to include jQuery in the head.

waitFor works by polling the DOM to see if anything matches the selector. Therefore if the selector is particularly slow to evaluate, there may be performance problems. So don’t do that!

History

More than 5 years ago(!) I wrote a plugin called elementReady that does the same thing as waitFor. It worked well but had some restrictions (for performance) and its usage syntax was not beautiful. After jQuery’s Deferred API came out, I tinkered with rewriting elementReady to use it, since it seemed a natural fit. As part of this, I renamed it so code using it would read better: $.waitFor(something).done(callback). And finally, last month I realised that the jQuery folks had upgraded their plugin site, so I thought I would finally release waitFor to the world.

Scott Berkun offers a great excerpt from his book Making Things Happen. He views project management as basically managing priorities:

• Everything can be represented in an ordered list. Most of the work of project management is correctly prioritizing things and leading the team in carrying them out.
• The three most basic ordered lists are: project goals (vision), list of features, and list of work items. They should always be in sync with each other. Each work item contributes to a feature, and each feature contributes to a goal.

And he has some excellent nuggets on management too:

• There is a bright yellow line between priority 1 work and everything else.
• Things happen when you say no. If you can’t say no, you effectively have no priorities.
• The PM has to keep the team honest and keep them close to reality.
• Knowing the critical path in engineering and team processes enables efficiency.
• You must be both relentless and savvy to make things happen.

Go and read it now and then send the link to the pointy-haired boss in your life.

Refresh 2012 in Auckland was held at the gracious Rialto Cinema in Newmarket. I’ve seen a few great films there, so it was fun to see a software presentation instead. But probably not as much fun as Slumdog Millionaire.

DreamWeaver

The first part was a demo of new DreamWeaver features, particularly its integration with Adobe’s Creative Cloud. DreamWeaver hung a few times, and the demonstrator had to change his script to work around this. A few audience interjections suggested that DreamWeaver hanging is a common occurrence.

The presenter later decided that the problem was due to the flaky network connection in the venue. (This is no excuse! I really wish vendors would not insist on assuming that everybody has a perfect network connection. Windows has always been terrible in this regard — just yesterday our network printing services went down, and Microsoft Word hung for about 5 minutes when I tried to print.)

DreamWeaver now supports media queries for responsive design. It also works with jQuery Mobile, and allows easy editing of jQuery Mobile themes. Speaking of that, he also demonstrated jQuery Mobile Themeroller’s nice integration with Adobe’s Kuler colour management tool.

Typekit

They showed Typekit, the webfont embedding service recently acquired by Adobe. It looks quite easy to use and also pretty inexpensive. But recently at Webstock, Jessica Hische was lukewarm about it, recommending Webtype instead. And she should know: check out her URL.

Proto

Proto is a quick prototype editor for Andriod and (soon) iOS. It enables you to quickly create a screen mockup, and it actually generates the HTML, CSS and JavaScript to implement it as you create it. Some features were a bit gimmicky. They claim that the generated code is good enough to actually serve as the starting point of development. If this is true then this is the first tool in the history of the Web that can actually generate good front-end code.

Muse

Muse allows you to create static websites in a similar way to creating print layouts with tools like InDesign. Great for designers who are already familiar with Adobe’s toolset, as you can also include interactivity, slideshows, Google Maps integration, etc., all without writing any code. This appeals to many people, but I dread being the sucker who has to tweak the machine-generated code later.

Well, I’m sure the generated code has improved in the ten years since I last had to wrestle with DreamWeaver’s output. And Muse is still in beta, so they still have time to remove some of the suck from it.

Edge

Edge is like the old Flash tools for creating animations and interactive content, except it produces HTML and JavaScript instead of Flash code. You can also add animations to existing HTML. This is evidence of Adobe’s plans for Flash: keep pushing it for high-performance games and video applications, but deprecate it for simpler stuff in favour of HTML. The world just became a slightly better place. And it may become even better when Edge makes it out of beta.

PhoneGap

PhoneGap is becoming more popular. It lets you develop cross-platform native mobile apps using Web technologies like HTML and JavaScript. It’s used by Wikipedia amongst many others. (Also the fun Untappd app.)

The core of PhoneGap is now under incubation at the Apache Software Foundation as Apache Cordova. PhoneGap is built on top of that and will eventually include stuff like Adobe product integration, while still remaining open source.

Support for PhoneGap is built in to DreamWeaver. PhoneGap actually supports mobile device APIs, so you can for example access location service, contacts, and the camera from your HTML/JS PhoneGap app. There are also plugins for specific application APIS such as Facebook.

Around this point, the presenter was going to give a demo of something or other in his iPhone. But during the break he unwisely decided to upgrade his iPhone’s OS. Version mismatch hilarity ensued, so we took an early lunch break so they could try to sort out the problem with help from some of the many experts in the audience. Sadly, even all that brainpower couldn’t solve the problem, so no demo for us. Even worse, the venue staff weren’t expecting the early lunch break, so the coffee wasn’t ready. I had to wait over 5 minutes for my latte. I think this is what they call a “first-world problem”.

PhoneGap Build is an online PhoneGap cross-compiler. It will produce iOS, Android, Windows Mobile, etc. versions of your PhoneGap app.

debug.phonegap.org is an online remote debugger for PhoneGap apps. You can use the Chrome’s dev tools on your desktop to inspect and edit the DOM while your app is running on your mobile device. This is very cool! This tool is based on weinre, which has been folded into the Apache Cordova project and shoehorned into PhoneGap. But it does seem to work.

Reflections for iPad

For the iOS demos, they used Reflections. It’s not an Adobe product — it’s just very neat. This app mirrors your iPad or iPhone screen onto a Mac. Presenting iOS apps is much, much easier this way. The only thing missing is that you can’t see the finger. Actually, that’s a good thing in most cases.

Photoshop Touch

The demo of Photoshop Touch was very compelling. US$10 gets you an iPhone version of Photoshop, with lots of easy-to-use photo-retouch tools. And they haven’t just shoehorned a cut-down PS into the iPad — they have taken advantage of the hardware with a nice touch interface and clever camera integration for quickly pulling photos and textures into your edits. There was a lot of buzz after the session about Photoshop Touch. I reckon they probably sold an extra hundred copies that day.

In 1988 Harold Thimbleby published a paper in IEEE Software titled “Delaying Commitment.” He notes that when faced with a new situation, experts will delay firm decisions while they investigate the situation, because they know that delaying commitments often leads to new insights. Amateurs, on the other hand, want to get everything completely right, so they tend to make early decisions, quite often the wrong ones. Once these early decisions are made, other decisions are built on them, making them devilishly difficult to change. Thimbleby notes that premature design commitment is a design failure mode that restricts learning, exacerbates the impact of defects, limits the usefulness of the product, and increases the cost of change.

So the basic workflow is to work in Git branches. To make sure the Git master and the Subversion trunk are in sync, I follow two basic rules. First, the only ways the Git master changes are:

• an update from SVN trunk
• a merge from another Git branch

Second, the only time I ever use SVN to commit or update is when I am on a clean Git master.

Here are the detailed steps I use.

Starting off

> git checkout master
> svn update
Updated to revision 435
> git commit -a
> git tag svn-435

Now master is up to date with the SVN trunk.

Working on code

> git checkout -B niftyFeature

Create a branch to work on a feature. This overwrites any existing niftyFeature branch.

(hack)
> git commit .
(hack)
> git commit .
(hack)
> git commit .

Getting ready to commit to SVN

> git checkout master
> svn update
Updated to revision 439

There will be no conflicts since Git’s master branch just tracks the SVN trunk.

> git add --all
> git commit -m"Update to SVN revision 439"
> git tag svn-439

The tag can be useful for diffing later on.

Now comes the scary part.

> git rebase master niftyFeature

That rebase essentially merges your work into the latest from the SVN trunk. Git rebase seems to work better than svn merge, but even so, you might have to resolve conflicts in the normal Git way.

The rebase also switches to the niftyFeature branch.

(test)

If there are problems:

(hack)
> git commit .

Committing to SVN

> git checkout master
> git merge niftyFeature

This is a no-fail fast-forward merge thanks to the previous rebase.

> svn commit
Committed revision 440

The SVN commit may update SVN keywords if you’re using them. To avoid confusing Git, commit these changes too:

> git commit -a -m"Update SVN keywords"
> git tag svn-440

I suppose this workflow is nothing but an ad hoc, informally-specified, bug-ridden, slow implementation of half of git-svn. I already know Subversion and am learning Git, and my goal was to practise my Git rather than learn a third set of commands (git-svn). I plan to use SVN a lot less in the future, so this way I will only have to forget one set of commands, not two.

Bonus tip: Backups

You can clone your repository to another location on your file system. A good choice might be your Dropbox folder or similar. This makes it trivial to keep your entire repository backed up.

> git clone --bare . /dropbox/projectName.git
> git remote add backup /dropbox/projectName.git
> git push backup

Making it a bare repository avoids problems with pushing. Then whenever you feel like backing up (i.e. all the time), just do this again:

> git push backup

At a high level, the most interesting part of the design is the navigation: no hierarchy, just tags. Opinions were divided, but I like the purity and elegance of the idea, and the implementation gives a lot of structure to the tags.

At a low level, they described the initial URL scheme they came up with. The site is implemented as a single-page site, with all content updates done with Ajax. For modern browsers, they use the history API to seamlessly change the URLs. For example, if a user clicks a “Travel” link, the browser address bar will switch from http://nz.com/ to http://nz.com/travel without refreshing the whole page. (Opera offer a good history API introduction.)

Browsers that don’t support the history API instead use Google’s Hash fragments specification: browsers would see the URL http://nz.com/#!travel, while web crawlers would see http://nz.com/?_escaped_fragment_=travel . (See the spec for the reasoning behind this.)

Eventually they realised they didn’t need to use hashbangs at all. HTML5 browsers, with their fancy history API, end up being able to use plain URLs like http://nz.com/travel without ever refreshing the whole page. But crawlers can use the same URLs to fetch whole pages — the backend can easily tell whether a request is coming from a crawler or a browser. And less capable browsers can just use a plain hashy URL like http://nz.com/#travel.

This is quite a nice solution, except that if a web crawler does get hold of an URL like http://nz.com/#travel, it will only ever see the site homepage. That’s an SEO fail. But they point out that this probably won’t have much of an impact because the proportion of such links floating around won’t be high.

They talked about various libraries they used to do this: jQuery plugins Pjax and History.js and the JavaScript MVC framework Backbone. (Poking around the Pjax page I discovered a very useful online Closure compiler service that actually hosts compiled code!)

I really enjoyed seeing this lively presentation from a team who are pushing a large public website into the HTML5 world. I’m feeling inspired for my next project!

But there were some particular highlights for me. Git, of course; everybody loves Git. In fact, 5 years ago I started a project in my day job. I strongly advocated using Subversion, and though there was some resistance (“What’s wrong with CVS?”) we did go with SVN. Now all our projects use Subversion. And now, working on an updated project for the same client, I’m keen to move to Git and it looks as if we’ll be doing that. Maybe 5 years from now we’ll be moving on to the next big version control paradigm. Nah, that’ll never happen, because Git is already version control Nirvana. Mmm, this Kool-Aid is delicious.

Mal recommended MacVim. I have installed it now. I spend a lot of time using Vim on various OSes, and I only know about 5 commands. Maybe if I switch to MacVim I will actually become a proper Vim user instead of a perpetual newbie.

He also spoke very highly of Sass, an “extension of CSS3, adding nested rules, variables, mixins, selector inheritance, and more”.I’ve always been intrigued by Sass and Less and their ilk, but I worry that it’ll be too easy to write logical and clear Sass code that expands to CSS code with complicated selectors, leading to cascade problems, debugging nightmares and general unhappiness. (Coincidentally, a few days later Stephen Tudor pointed out a few of these issues in Responsible Sass Authoring.) But Mal pointed out that you don’t have to go all-in: just a few key features (like mixins and variables) will make a big difference.

I’m convinced it’s worth a try.

Fire Eagle, from Yahoo!, is a framework for building location-awareness into an application in a way that offers users fine-grained control over the privacy of their location information.

Ideo’s free Human-Centered Design Toolkit is intended to help international staff and volunteers “understand a community’s needs in new ways, find innovative solutions to meet those needs, and deliver solutions with financial sustainability in mind.” It’s designed specifically for social enterprises operating in impoverished communities in Africa, Asia, and Latin America, but I’m sure there’s a lot in it for social enterprises in general. And it’s free, which is nice.

Vikram and Robert also handed round a copy of Business Model Generation (“A handbook for visionaries, game changers and challengers.”), a rather nice coffee-table book about building and maintaining modern business models. It looked well worth reading as far as I could tell. There’s an iPad app too.

Later, Peter Mangin (@peteinakl) facilitated a nicely nuanced discussion on the evolution of social networks. He pointed out that they’re not evil — not even Facebook! — they’re just businesses trying to make money. He singled out two Google initiatives as being forces for good in the space. Obviously, the Circles feature in Google+ aims to clarify the privacy ambiguities that Facebook has struggled with (and it may well eat Facebook and Twitter’s lunches in the process.) Meanwhile, their Data Liberation Front aims to give Google’s users as much control as possible over their data. As people become more concerned about privacy, this will become a Google feature that Facebook will simply have to copy.

This year, for the first time Barcamp hosted a panel discussion. There were three members of parliament, representing the three main parties, and four others representing various organisations and views. The discussion was worthwhile, though with the Barcamp crowd the views expressed were pretty much what you’d expect: More Power to the Internet! Of the politicians, Clare Curran the Labour MP and Gareth Hughes the Green MP both seemed to have a good grip on the issues. National MP Sam Lotu-Liga mostly just parroted the party line. At least he was obviously not pandering to the partisan audience.

It was great to see a lot of discussion on wider social issues relating to technology at the Barcamp, rather than just coding and designing the latest web app. There was a bit of that though: I’ll write up my notes for that sometime soon.

I was already aware of the basic technique: work in uninterrupted 25-minute bursts, followed by a 5-minute break. This 30-minute cycle is called a Pomodoro. If a Pomodoro is interrupted, you have to start the timer again. After four Pomodoros, have a longer break of 15-30 minutes.

Carol and Noemi fleshed out these rules with descriptions of how you should plan your day’s work beforehand, and evaluate it at the end. This is important for efficiency, but also for motivation — it’s easier to stick with the technique if you can see the progress you’re making. The final rule is to remember that “The Next Pomodoro Will Go Better”.

I have downloaded the Pomodoro Technique Book and will try the technique for myself in the coming weeks.

There was good variety in the various sessions I attended. One was on 1Password, a cross-platform password and information management tool. It looked useful, but quite heavyweight — there’s no easy way to use it on a computer unless you can run or install the 1Password program on it. Still, maybe a good solution to the problems of juggling dozens of website usernames and passwords.

I also attended a live recording of The Discourse Weekly Show. Ben & Morgan were pretty amusing, but the rough and ready setup and the general lack of microphone technique in the audience might not translate that well to the recorded result. Listen to the show if you don’t believe me.

Other sessions I attended roughly covered the areas of productivity, society and development. I’ll write up my notes on them in the next few days.