In a nutshell, my year so far has consisted of:

• Traveling for 10 months around the world through 17 countries covering Africa, South East Asia, Australasia and North, Central and South America. The trip was centered around surfing and photography

• Presenting in Hong Kong, Japan, the US and London

• Writing a book for O'Reilly as I went, titled JavaScript Web Applications

• Writing another book on CoffeeScript, soon to be published by O'Reilly.

• Doing a ton of open source libraries, such as Spine, Spine.Mobile, GFX, and Juggernaut.

• Building a startup prototype

• Presenting at FOWA

• And finally, landing a job at Twitter

So, let me start a year ago, in September 2010. I had just left a startup I’d co-founded, and whilst the experience was useful, I was feeling bit burnt out from the incredibly long working hours involved. I was back in England and needed to make some decisions. A long held dream of mine was to move (if only for a few years) to the US, so I wrote the following in Google Notebook:

Choices in life:
      Do a bachelors at Columbia in NYC
        Downside - v expensive, not much to learn practically, boring?
        Upside - it's a uni in NYC!
      Write a book and apply for an O1 visa
        Downsides - very time consuming, risky
        Upsides - good for career, interesting
      Wait. Just go to NYC for a holiday (3 months). Wait for startup visa.
        Easy option - not very interesting
    
    Maybe do 2, falling back to 3?
    

In the end I decided to do option 2, to write-up a book idea I’d been mulling over on JavaScript web applications, and what better way to write a book than traveling round the world, another dream of mine. I bought a round the world plane ticket through oneworld (cheaper than you’d expect) and set off the next week to my first destination, South Africa.

If you’ve never been to Africa, you should. Its scenery is raw and beautiful, hard to describe eloquently to those who haven’t experienced it. I had fallen in love with South Africa the previous year, doing a surfing tour up the East coast for three months. This time I only had time for one month, traveling through the Transkei up from Cape Town to Durban. As I travelled North, I started writing, fleshing out some of the chapter ideas I’d proposed to O'Reilly earlier.

The Transkei is an extremely rural part of South Africa, consisting of rolling hills, small villages and mud huts. They still have a chieftain hierarchy and a king, and most locals survive off the land and by fishing. It takes about two days driving on a heavily potholed road to reach my favourite spot, a beautiful cove called Coffee Bay. From there I would charge up batteries and save some articles offline in preparation for further expeditions up the coast.

I vividly remember walking miles down the untouched beaches, traveling from village to village, alone apart for the sand and the waves. At one stage I came across a swollen river, and rucksack held aloft managed to swim across it without drenching my Nikon and iPod. Africa is a place to lose yourself, to free up your mind, and to work out what’s really important in life.

The next stop was Hong Kong, where I had my 21st birthday, and then I traveled by land from Singapore to Hanoi. What most people don’t realize is that Hong Kong is 70% national park, and I had a great time hiking some of the spectacular routes, such as the Dragon’s Back. Some days I’d hang out at boot.hk, a co-working space, and teach a fellow traveler Ruby. Then, at night, I’d party with some couchsurfers in Soho till the early hours.

Traveling through Thailand, Cambodia and Vietnam was probably my favorite part of the trip, and if you have never been through Asia, you really should. The countries are beautiful, the weather fair, the food delicious and the people friendly. Angkor Wat is one of the wonders of the world, and should be on everyone’s bucket list. It was Trey Ratcliff’s photographs that inspired me to go there, and indeed many of my other destinations. That man was a catalyst for the trip in the first place.

On some obscure blog, I’d heard tell of a remote and beautiful island off the coast of Cambodia. It spoke of a bar in Sihanoukville, where I could organize a fishing boat out to the place. I, along with some really good friends, took the night bus to the town, and started looking for this legendary bar. The search lasted most of the day, each bar I’d inquire at sending me to another. Finally, I found the place, and organized a shuttle to take us the next morning.

The photo above is of the beach outside our $10 a night shack. Apart from the local inhabitants, our group was alone on the island, free to rein as we pleased. During the day we’d laze on the beach, eating incredible fruit salads the island’s chef had prepared, then at night we’d swim in the sea amongst all the glowing plankton.

Next stop was Vietnam, and we traveled along the Mei Kong’s tributes to reach a border town. There, we were the only westerners, and communicating was definitely an issue. Luckily we found what must have been the only English speaker in town, and he gave us a tour on his bicycle. His help was especially useful when my credit card got gobbled up by an ATM!

Our group parted ways, and by the time I’d reached Vietnam the book was well underway and coming along nicely. I stayed a few extra weeks in Saigon to really make some progress on the chapters, and was around for the Chinese New Year’s celebrations, which were truly spectacular.

Next was Japan, Australia, New Zealand and Hawaii. I can’t possibly cram into this post all the experiences I had, but suffice to say it was the time of my life. It’s incredible that so much beauty can be packed into one country, but that’s New Zealand for you. Some of my fondest memories are running at sunset around the lake at Wanaka, or hiking for days through the mountains along the Routeburn, carrying all my food and supplies. I made some lifelong friends traveling around that country; it’s truly a piece of paradise.

By the time I’d circumnavigated New Zealand’s South Island, the book was practically finished and submitted to the technical reviewers.

Next up were New York and San Francisco, two incredible cities containing some brilliant developers, some of whom I’m lucky enough to call my friends. Techcrunch Disrupt was awesome (I can highly recommend the hackathon), as was ‘adopt a coder’.

During my stop-over in New York and San Francisco, I did a ton of interviewing at various companies and landed a job at Twitter where I’ll be working on the front-end. I’m absolutely stoked to be working there with such an awesome team, and also by the move to San Francisco, a lifelong dream of mine.

Whilst the visa was being assembled, I traveled through Central and South America, hacking on my pet project as I went: a JavaScript MVC library called Spine. I traveled down Costa Rica, Panama, Peru, Bolvia and Argentina. Peru was easily my favourite, and although I had some trouble with the altitude, I had an incredible time exploring. The picture below is of one of the Colca Canyon’s fabled Condors, taken whilst I was climbing down the canyon, the world’s deepest.

When I was in Costa Rica, I got a tweet from a guy called Roberto, saying he’d read the book and was I interested in doing a surfing tour. Of course I readily agreed and took the bus to San Jose, meeting him a few days later. During the day we’d hack on Spine and Ruby projects at his beach-side condo, using the mobile dongle and car batteries to power our laptops. Then, when the power was low, we’d go out surfing as the solar panels did their work.

I can highly recommend writing a book, especially combining it with traveling. Indeed, if I didn’t have my sights set on San Francisco, I have a feeling I’d still be traveling, consulting and making startups. Being an author won’t make you much money directly, but it will definitely raise your profile and provide you with many more opportunities indirectly. In fact, what I most enjoyed about the process was being able to research and know a subject matter really deeply.

The last year has been the best year of my life, and I have a feeling the next will be better still. While I’ve settled down for the time being, I don’t think I’ll ever shake the lure of traveling; I still carry my passport in one pocket, and my wallet the other, ready to leave at a moments notice.

However, this post is not just about my travels, there’s a message to it:

The peculiar thing about programmers is that they’re the one profession that can easily work remotely and travel, and yet they’re the one profession that doesn’t. Of course there are exceptions, but on my travels I didn’t meet another programmer doing anything similar; a sad state of affairs. My message to fellow programmers is stop making excuses, man up and do it. You only live once, and I guarantee that you will have the time of your life.

As for me, I feel incredibly fortunate to be in the position I’m in, to have found my passion and to be doing what I love every day. That said, much of my current situation is no accident or fluke, but rather the result of planning, goals and work.

The harder you work, the luckier you get

The point of this post isn’t some self-aggrandizing narcissistic pontification, but rather to demonstrate that setting goals works, and to inspire people to do likewise. Work out where you are now, where you want to be in a year, and set-down a series of concrete steps that will get you there. Follow your dreams.

This is a repost of an article first posted in November 2011

Please find below an announcement for an Ethnographic Study with the National Park Service. Be advised that there is a brief window for application – responses are due June 28^th – and the opportunity would be most appropriate for students who will not require travel funding to the Antietam National Battlefield in Maryland.

All inquiries should be directed to Jennifer Talken-Spaulding (202 619-7205) or Walter H. Zachritz (301 689-7108,walter_zachritz@nps.gov).

IE10 in Windows 8 Consumer Preview includes support for Error.stack , which enables Web developers to diagnose and correct bugs faster, especially those that are difficult to reproduce. Developers can build amazing apps with the capabilities of Web platforms that power today’s modern browsers. In Windows 8, we expose that power through both Internet Explorer 10 and Metro style apps in JavaScript .

It’s an interesting time to be working on the frontend now. We have new technologies such as HTML5, CSS3, Canvas and WebGL; all of which greatly increase the possibilities for web application development. The world is our oyster!

However, there’s also another trend I’ve noticed. Web developers are still stuck in the request/response mindset. I call it the ‘click and wait’ approach - where every UI interaction results in a delay before another interaction can be performed. That’s the process they’ve used their entire careers so it’s no wonder most developers are blinkered to the alternatives.

Speed matters; a lot. Or to be precise, perceived speed matters a lot. Speed is a critical and often neglected part of UI design, but it can make a huge difference to user experience, engagement and revenue.

• Amazon: 100 ms of extra load time caused a 1% drop in sales (source: Greg Linden, Amazon).
• Google: 500 ms of extra load time caused 20% fewer searches (source: Marrissa Mayer, Google).
• Yahoo!: 400 ms of extra load time caused a 5–9% increase in the number of people who clicked “back” before the page even loaded (source: Nicole Sullivan, Yahoo!).

Yet, despite all this evidence, developers still insist on using the request/response model. Even the introduction of Ajax hasn’t improved the scene much, replacing blank loading states with spinners. There’s no technical reason why we’re still in this state of affairs, it’s purely conceptual.

A good example of the problem is Gmail’s ‘sending’ notification; how is this useful to people? What’s the point of blocking? 99% of the time the email will be sent just fine.

As developers, we should optimize for the most likely scenario. Behavior like this reminds me of Window’s balloon notifications, which were awesome for telling you about something you just did:

The solution

I’ve been working on this problem, specifically with a MVC JavaScript framework called Spine, and implementing what I’ve dubbed asynchronous user interfaces, or AUIs. The key to this is that interfaces should be completely non-blocking. Interactions should be resolved instantly; there should be no loading messages or spinners. Requests to the server should be decoupled from the interface.

The key thing to remember is that users don’t care about Ajax. They don’t give a damn if a request to the server is still pending. They don’t want loading messages. Users would just like to use your application without any interruptions.

The result

AUIs result in a significantly better user experience, more akin to what people are used to on the desktop than the web. Here’s an example of an AUI Spine application with a Rails backend.

Notice that any action you take, such as updating a page, is completely asynchronous and instant. Ajax REST calls are sent off to Rails in the background after the UI has updated. It’s a much better user experience.

Compare it to the static version of the same application, which blocks and navigates to a new page on every interaction. The AUI experience is a big improvement, that will get even more noticeable in larger (and slower) applications.

Have a browse round the source to see what’s going on, especially the main controller.

Not a silver bullet

It’s worth mentioning here that I don’t think this approach is a silver bullet for all web applications, and it won’t be appropriate for all use cases. One example that springs to mind is credit-card transactions, something you’ll always want to be synchronous and blocking. However, I do believe that AUIs are applicable the vast majority of the time.

The other point I’d like to make is that not all feedback is bad. Unobtrusive feedback that’s actually useful to your users is completely fine; like a spinner indicating when files have synced, or network connections have finished. The key thing is that feedback is useful and doesn’t block further interaction.

The implementation

So how do you achieve these AUIs? There are a number of key principles:

• Move state & view rendering to the client side
• Intelligently preload data
• Asynchronous server communication

Now, these concepts turn the existing server-driven model on its head. It’s often not possible to convert a conventional web application into a client side app; you need to set out from the get go with these concepts in mind as they involve a significantly different architecture.

Moving state to the client side is a huge subject and beyond the scope of this article. For more information on that, you might want to read my book: JavaScript Web Applications. Instead in this post I want to focus in on a specific part of AUIs; asynchronous server communication, or in other words: server interaction that’s decoupled from the user interface.

The idea is that you update the client before you send an Ajax request to the server. For example, say a user updated a page name in a CMS. With an asynchronous UI, the name change would be immediately reflected in the application, without any loading or pending messages. The UI is available for further interaction instantly. The Ajax request specifying the name change would then be sent off separately in the background. At no point does the application depend on the Ajax request for further interaction.

For example, let’s take a Spine Model called Page. Say we update it in a controller, changing its name:

page = Page.find(1)
    page.name = "Hello World"
    page.save()
    

As soon as you call save(), Spine will perform the following actions:

1. Run validation callbacks and persist the changes to memory
2. Fire the change event and update the user interface
3. Send an Ajax PUT to the server indicating the change

Notice that the Ajax request to the server has been sent after the UI has been updated, in other words what we’ve got here is an asynchronous interface.

Synchronizing state

Now this is all very well in principle, but I’m sure you’re already thinking of scenarios where this breaks down. Since I’ve been working with these types of applications for a while, I can hopefully address some of these concerns. Feel free to skip the next few sections if you’re not interested in the finer details.

Validation

What if server validation fails? The client thinks the action has already succeeded, so they’ll be pretty surprised if subsequently told that the validation had failed.

There’s a pretty simple solution to this: client-side validation. Replicate server-side validation on the client side, performing the same checks. You’ll always ultimately need server-side validation, since you can’t trust clients. But, by also validating on the client you can be confident a request will be successful. Server-side validation should only fail if there’s a flaw in your client-side validation.

That said, not all validation is possible on the client-side, especially validating the uniqueness of an attribute (an operation which requires DB access). There’s no easy solution to this, but there is a discussion covering various options in Spine’s documentation.

Network failures & server errors

What happens if the user closes their browser before a request has completed? This is fairly simple to resolve, just listen to the window.onbeforeunload event, check to see if Ajax requests are still pending, and if appropriate notify the user. Spine’s Ajax documentation contains a discussion about this.

window.onbeforeunload = ->
      if Spine.Ajax.pending
        '''Data is still being sent to the server; 
           you may lose unsaved changes if you close the page.'''
    

Alternatively, if the server returns an unsuccessful response code, say a 500, or the network request fails, we can catch that in a global error handler and notify the user. Again, this is an exceptional event, so it’s not worth investing too much developer time into. We can just log the event, inform the user and perhaps refresh the page to re-sync state.

ID generation

IDs are useful to refer to client-side records, and are used extensively throughout JavaScript frameworks like Backbone and Spine. However, this throws up a bit of a dilemma - where are the IDs generated, the server or the client?

Generating IDs on the server has the advantage that IDs are guaranteed to be unique, but generating them on the client side has the advantage that they’re available instantly. How do we resolve this situation?

Well, a solution that Backbone uses is generating an internal cid (or client id). You can use this cid temporarily before the server responds with the real identifier. Backbone has a separate record retrieval API, depending on whether you’re using a cid, or a real id.

Users.getByCid(internalID)
    Users.get(serverID)
    

I’m not such a fan of that solution, so I’ve taken a different tack with Spine. Spine generates pseudo GUIDs internally when creating records (unless you specify an ID yourself). It’ll use that ID to identify records from then on. However, if the response from an Ajax create request to the server returns a new ID, Spine will switch to using the server specified ID. Both the new and old ID will still work, and the API to find records is still the same.

Synchronous requests

The last issue is with Ajax requests that get sent out in parallel. If a user creates a record, and then immediately updates the same record, two Ajax requests will be sent out at the same time, a POST and a PUT. However, if the server processes the ‘update’ request before the ‘create’ one, it’ll freak out. It has no idea what record needs updating, as the record hasn’t been created yet.

The solution to this is to pipeline Ajax requests, transmitting them serially. Spine does this by default, queuing up POST, PUT and DELETE Ajax requests so they’re sent one at a time. The next request sent only after the previous one has returned successfully.

Next steps

So that’s a pretty thorough introduction into asynchronous interfaces, and even if you glossed over the finer details, I hope you’ve been left with the impression that AUIs are a huge improvement over the status quo, and a valid option when building web applications.

If you’re interested in building AUIs, you should definitely check out Spine, and Spine’s Ajax guide.

This is a repost of an article first posted in November 2011

The SVG Working Group has published a Working Draft of Scalable Vector Graphics (SVG) 2. This specification defines the features and syntax for Scalable Vector Graphics (SVG) Version 2, a language for describing two-dimensional vector and mixed vector/raster graphics. Changes in this working draft include introduction of a new ‘hatch’ element as a refinement on patterns, improved accessibility and integration with HTML through the addition of the ‘tabindex’ attribute and changes to the ‘foreignObject’ element, addition of a new 'auto-start-reverse' attribute value for markers, clarification of CSS transforms on SVG content, and various updates to bring SVG closer in line with CSS best practices. See the full list of modifications in the SVG changes appendix. Learn more about the Graphics Activity.

The XML Security Working Group has published a Group Note of Test cases for Canonical XML 2.0. This document outlines test cases for Canonical XML 2.0. Learn more about the Security Activity.