Phil Leggetter - Real-Time Web Software and Technology Evangelist

Realtime Commenting blog post on Smashing Magazine

Phil Leggetter — Wed, 09 May 2012 13:51:50 +0000

Really pleased to see my realtime commenting system blog post appearing on Smashing Magazine. The post took a reasonable amount of time to write but I really like the way that the application is built from near-scratch and is progressively enhanced, first with AJAX and then realtime web functionality.

Big thanks to Bryce Wilson of zendit.com for putting the HTML5, WebSockets (connectivity) and Pusher image together.

You can read the "How To Build A Real-Time Commenting System" post on Smashing Magazine now. And here’s the tweet from @smashingmag:

New on Smashing Coding: How To Build A Real-Time Commenting System – coding.smashingmagazine.com/2012/05/09/bui…

— Smashing Magazine (@smashingmag) May 9, 2012

WebSockets realise Comet. They’re not an alternative.

Phil Leggetter — Sun, 22 Apr 2012 18:58:14 +0000

“WebSockets or Comet”

I’ve been thinking about writing about this frequently used statement for a while, and I’ve seen a few comments and discussions previously about this e.g. from Martin Tyler of Caplin Systems and Peter Lubbers of Kaazing in a post on InfoQ).

Martin’s point of view is:

One thing I don’t understand is your stance on Comet. You seem to want to distance Kaazing from Comet, despite the fact that your WebSocket emulation is surely Comet. More than this though, WebSocket itself is also Comet since Comet is just a paradigm, not a any specific transport mechanism.

Peter’s opinion is:

Comet is a programming model that allows a web server to push data to a browser. This is often achieved through a long-held HTTP request, but there really is no standard or specification for Comet; it is just an umbrella term for all the different ways that can be used to achieve this.

WebSocket, on the other hand, is a well-defined API and protocol that allows for full-duplex, bidirectional communication (not just server push).

Can you really say WebSockets is an alternative to Comet when Comet servers use WebSockets?

My current thinking is the same as Martin’s (I did used to work with Martin). It is that:

Comet is a paradigm, not only for server push but also for bi-directional communication.

The need to do this with a web browser resulted in WebSockets – something which natively supported this in a way that HTTP did not. So, we have Comet to thank for WebSockets.

The Wikipedia Comet entry states:

Comet is a web application model in which a long-held HTTP request allows a web server to push data to a browser, without the browser explicitly requesting it. Comet is an umbrella term, encompassing multiple techniques for achieving this interaction.

Alex Russell’s original Comet blog post states:

Fundamentally, they all use long-lived HTTP connections to reduce the latency with which messages are passed to the server.

The architecture relies on a view of data which is event driven on both sides of the HTTP connection.

All very HTTP related. But the second quote interestingly says “event driven on both sides”. This bi-directional communication, backed up by the diagram from the web post (see below), seems to have been lost in the wikipedia entry.

Original Comet diagram by Alex Russell. source

What I’m suggesting is that Comet is a paradigm for realtime bi-directional communication between a server and a client. Initially it used long-lived HTTP connections in addition to a second short-lived connection for command requests (e.g. subscribe) because it was the only solution. Comet servers now use WebSockets because they are now available, are better than the HTTP-based alternatives and help Comet (the paradigm) be achieved and finally truly realised in a standardised way.

I’m suggesting that HTTP Long-Polling or HTTP-Streaming (all using XMLHttpRequest, Script tag polling, IFRAMES, ActiveX objects) and WebSockets are transfer technologies (Martin used the term “transfer mechanism”) that make the Comet paradigm possible.

I’m suggesting that saying “Comet or WebSockets” is an invalid statement and that the Wikipedia article is incorrect and that this diagram better reflects the relationship between WebSockets and Comet:

Realtime web technology stack hierarchy

I’m prepared to be wrong by being convinced otherwise. But I don’t think I am or will. Interested in hearing your opinions.

Note: I originally posted the core text to this as a comment on a blog post “Websockets or Comet or Both? What’s supported in the Java EE land”

Code Africa & the Impact of Realtime

Phil Leggetter — Mon, 19 Mar 2012 11:28:10 +0000

Over the weekend I attended the Code Africa hack weekend which was organised and hosted by The Times. The event saw developers, designers, journalists and entrepreneurs come together to try and form ideas and build prototypes over one weekend. My main takeaways from the event were a much better understanding of the state of technology in Africa, how technology can be used to help the people living within the continent and how realtime technologies can be used not only to improve application functionality, but also provide real impact in demonstrations and presentations.

Ideas & Prototypes

Simple SMS Education

Using SMS and mobile to help deliver interactive, remote and continuous teaching – Daniel Probert.

See the code in github

TransAfrik

A number of ideas around crowd sourcing all sorts of information with an initial focus on travel; traffic, route planning and more.

Chircle

A way of making a single charity payment and being able to distribute parts of that payment to multiple chosen charities – Stef Lewandowski

Visit Chircle.com and signup

De-code Africa

Build a fun way of discovering interesting facts and stats about Africa, and the countries within the content, and compare the information against other non-African countries.

See the app in action

The Pitch

At the end of the second day each idea was given three minutes to pitch, and if possible demo. And today (Monday, March 19) they will be pitching to a group of 100 people including numerous company CEOs, at least two country presidents and a former Prime Minister at The Times CEO Summit Africa (RSS news feed) – a real opportunity to potentially get funding and affect change.

The Impact of Realtime

Public speaking is quite new to me. In the past couple of years I’ve spoken at just a handful of events. However, over the past few weeks I’ve give more talks than ever about Realtime web technologies, including a lightening talk yesterday at CodeAfrica.

The more talks and workshops I give the more I realise that no amount of speaking will beat actually demonstrating a realtime web technology. But not only demonstrating, also using the technology to make the audience part of the presentation, and make it an interactive presentation which encourages discussion and stimulates ideas.

I saw this again yesterday when Daniel Probert, who lead the Simple SMS Education team which I was part of, demoed the prototype. As part of his three minute pitch Daniel used the prototype web app to send a question via SMS (thanks to Twilio to a number of people in the room. They then reply to that SMS with the answer to the question. These answers are instantly displayed within the prototype application (thanks to Twilio WebHooks and Pusher). This was described by one of the feedback panel as “A killer demonstration”.

The ability to instantly demonstrate interaction between multiple people using SMS and realtime web technologies has a real WOW-factor. I’ve used this sort of technology for over 10 years and I’m still excited and wowed by it!

Final Thoughts & Thanks

CodeAfrica was organised and ran by Federica Cocco, Peter MacRobert and Tom Whitwell and Xen Lategan so they deserve a lot of credit for a great event and bringing so many interesting and creative people together.

It was also great to work with Anibe Agamah, Daniel Probert, Jianfeng Tian, Ilias Bartolini, Andrei Simion and Simona Ciocoiu.

With my core interest in technologies being realtime technologies I thought that the lack of Internet infrastructure (mobile data networks) in some areas of Africa was going to mean that I wouldn’t be able to use this technology over the weekend. However, it was used (and will be used today in Daniel’s pitch) to add real impact when demonstrating how technology can really make a difference.

jQuery UK 2012 Event – don’t always use jQuery

Phil Leggetter — Sun, 19 Feb 2012 07:27:48 +0000

I started writing this right after the jQuery UK event but have only just found time to finish it off sitting in Stansted airport at 7am.

jQuery is a funny thing; it’s made JavaScript coding easy for advanced developers and accessible to web designers, and you could even say that the web designer role has very much changed because of it. It’s made web interfaces much richer and interactive. But, it’s also made us lazy because it’s so easy to use. It’s time to take a step back and start thinking about best practices. And sometimes that might mean not using jQuery.

I was really pleased to hear Christian Heilmann‘s talk on moving back to using native methods, rather than always using jQuery (you can read Christian’s write-up and get see his slides here). His reasons for this were:

To encourage education about native browser functionality
Native browser methods can perform better

This latter point is of particular interest to me. Whilst at Caplin Systems I was part of a development team where performance was critical. We were (they still are) building realtime web libraries and UIs which need to deal with both high frequency of data updates and large data sets displayed within the UI. I met up with Rich Chamberlain, Caplin’s dev manager, about a month ago and he reminded me of this. So, I set about comparing document.getElementById('someId') with $('#someId') and unsurprisingly the native method was by far superior.

For the results of this, and to test for yourself, see Considerations when updating the DOM to display realtime data.

What was surprising was just how much better document.getElementById is. You would assume (I haven’t looked at the source) that within the $ function that the selector would simply be checked:

$ = function(selector) {
  if( isIdSelector(selector) ) {
    var el = document.getElementById(selector);
    return warpInJQueryStuff(el); // el could be null
  }
  // else …
};

Ok, it’s probably nothing like this. But you get the idea. So, what is it that makes using jQuery comparatively so expensive? My guess is that it’s the warpInJQueryStuff. One of the parts of jQuery that makes it so powerful (all those functions you can call after selecting elements, and the chaining functionality e.g.

$('.something')
.doSomething()
.doSomethingElse()
.soOn();

The same goes when the selector isn’t just an id attribute selector i.e. a more advance CSS query.

$ = function(selector) {
  if( isIdSelector(selector) ) {
    //...
  }
  else if( isQuerySelector(selector) ) {
    var els = document.querySelector(selector); //**TODO: check**
    return wrapInjQueryStuff(els);
  }
  // else …
};

The jQuery library shoots itself in the foot a little bit here because they’ve added non-CSS selectors (I can’t find an example right now but a google suggests this is correct). However, this isn’t anything that a RegExp couldn’t test for and if the jQuery-specific selectors aren’t found then the native function can be used. Again, maybe it’s the wrapInjQueryStuff that’s the problem?

Anyway, the point is: don’t always use jQuery. As with anything, consider what you are trying to achieve and if performance matters, or you just want to learn, use the native methods instead. But remember to check for browser support.

If performance matters and you find this type of thing interesting then Doug Neiner’s talk on Contextual jQuery will probably interest you too.

Ideas for #APIHackathon

Phil Leggetter — Sat, 18 Feb 2012 11:33:40 +0000

Realtime location tracking Poll (I’m sure they’ll introduce WebHooks soon) the Vodafone API and push realtime updates to a map.

A better Betfair Ok, you probably won’t be able to build an app that’s better than betfair. But using our API in conjunction with Betfair you’ll be able to build a realtime betting system. The questions is: can you get realtime data from Betfair? Things like realtime odds?

Multiplayer Hangman A simple turn-based game. Take the ideas that Dan from Pearson spoke about and use Pusher to push those results to multiple users.

Realtime context sensitive advertising Advertising tends to be pretty static once an application loads. Why not analyse how a user is using an application and dynamically push different adverts to their app… using Pusher

Any questions please give me a shout. I’m @leggetter on Twitter.

No related posts.

Considerations when updating the DOM to display realtime data

Phil Leggetter — Sun, 12 Feb 2012 15:18:26 +0000

When data is being delivered to web applications the chances are that you’ll be displaying that data within the user interface (UI). In order to do this you need to find the element in the Document Object Model (DOM) and then update it. Whilst the performance of web browsers is improving all the time DOM manipulation can still be costly (use up time and resources) if you are pushing through a lot of data so it’s worth keeping the interaction with the DOM to a minimum. You should also consider how you access the DOM. Should you use a utility/library function or should you use native browser methods?

To demonstrate this, and show the considerations I’ve written a few small helper functions which can be called a number of times from tests and for each test I’ll time how long it takes to update the DOM a certain number of times.

For many web developers a script tag referencing in the jQuery library is one of the first elements to be added to any web page – it’s even in some web framework templates by default. So, a good first test is to time how long it takes for jQuery to update an element a number of times.

Now that we’ve defined one way of updating the DOM let’s add a way of caching a reference to the jQuery object that we create with the jQuery(selector) call. So, instead of having to make that call each time we can just access the object from a cache. This means that a new jQuery object doesn’t need to be created for every update.

jQuery uses CSS selectors to find elements so rather than going directly to single elements using id attributes let’s also define a test that uses a nested selector: div.top div.middle div.bottom p.update-me.

Finally, as a comparison let’s define functions which update the DOM by directly using the native document.getElementById and document.querySelector native browser functions, and both of these again using the caching technique we used earlier.

If we execute each of these methods so that they are called 500 times to update the DOM and repeat that 10 times we see results as shown in the following graph.

Time in milliseconds (y-axis) it takes to update an element within the DOM (+1) times. The test is ran a number of times (x-axis)

And if we take each of the results and average them out we see the following:

The chart above shows the average time it takes to find the element and update the DOM using different techniques

Conclusion

The graphs are dynamically generated based on the browser viewing this blog post so the results will differ but even so the graphs suggest to following to me:

If you are sending a reasonable number of updates, and you are going to be updated the UI a lot, that you should be using document.getElementById to access and update the DOM.
If you want to use jQuery and the DOM structure isn’t going to update all that often then the caching references to jQuery objects is an efficient mechanism.
If you are are using CSS queries then the native document.querySelector performs better than jQuery. In both cases the complexity of the query is undoubtedly going to impact the performance.
Caching lookups of document.querySelector is a good idea since it improves performance.
Unsurprisingly direct id attributes lookups are fastest of all.
document.getElementById is the fastest way of accessing the DOM and caching lookups doesn’t make a big difference.

The important thing is that you will know better than anybody else the sort of data that is going to be pushed into your app and it does with it. Balance performance and maintainability within your application and make decisions about how you are going to deal with updating the DOM based on that. If your application gets infrequent updates then you’ll be fine using jQuery all the time. If your app gets a lot of realtime data streamed to it, maybe it’s a trading application, then you’ll need to fine-tune your app.

Edinburgh Techmeetup, Web Browsers & the Realtime Web

Phil Leggetter — Thu, 09 Feb 2012 10:48:33 +0000

I gave a presentation yesterday at Edinburgh techmeetup. A big thanks to Dale Harvey for inviting me to talk and to all the attendees for taking the time to attend, listen and interact. Aaron Bassett also gave a good talk on Avoiding Integration Hell so I’d recommend you follow him for more info.

Here’s a direct link to the “Web Browsers & the Realtime Web the past, present & future” slides.

And here’s the recording of my talk (thanks to Marius Ciocanel): TechMeetup Talks – Phil @Leggetter on the past present and future of the Realtime web from TechMeetup on Vimeo. After the presentation there were a number of good questions asked here they are, and my answers. If you’ve any other questions please drop me an email or leave a comment.

Does WebSockets provide support for common use cases? Does it natively support Pub/Sub?

As with most standardised technology WebSockets offer the very basics of what is required to enable realtime bi-directional communication between a server and a client;

var ws = new WebSocket(url) – connect
ws.onopen = function() {}; – connected
ws.onmessage = function(ev) {}; – some data has arrived
ws.send({"some":"data"}); – send some data to the server
ws.onclose = function() {}; – the connection has closed
ws.close(); – close the connection

If you want functionality like auto reconnection, connection stability checking (ping/pong is hopefully coming), the ability to subscribe to channels/topics/subjects in order to filter and partition data then you need to build this functionality yourself or user a client/server combination that already offers this. We’ve built this functionality into our Pusher JavaScript library and service.

How do people on shared hosting use this technology?

If you are on a shared hosting then the hosting provide doesn’t tend to like this sort of technology because it requires you to maintain persistent connections between the hosting server and the client. I don’t know for sure but I think PHP hosting services may do something to stop this sort of thing from working. However, I’m pretty sure that hosting services like Joyent will provide support since socket.io is quite possibly one of the most popular packages available. I could be wrong, but I’d be surprised if I am. If you know, please get in touch. A great option here is to use Pusher since it remove the need to maintain the persistent connections – it’s technology agnostic.

Do WebSockets have problems with proxies and firewalls?

Yes, but connecting over a secure connection (WSS:// over port 443) will work in the majority of cases. For those cases it doesn’t work I’ve seen HTTP Long-Polling and HTTP Streaming also having problems where proxies and firewalls don’t like the long-held requests. It’s really a battle between realtime technologies and older Internet infrastructure.

Where does SPDY fit into the Realtime Web?

“SPDY is an experimental protocol for a faster web“. It’s actually used by Google Chrome and a number of Google web apps already (a quick Google suggestions Firefox 11 will support SPDY). The main problem is that in order for this protocol to be used we need the Internet Infrastructure to upgrade. This isn’t going to happen to quickly. So, SPDY sounds very promising but it’ll be a while until we see it widely adopted/used. It’s easier to move client technology forward (we need IE to auto update), but server technology looks like it’ll be slower to move forward. I recommend keeping an eye on Ilya Grigorik’s blog for related tech info. Please let me know if I’ve missed any questions (I’m sure I have) or if you have any further questions by [dropping me an email](mailto:phil@leggetter.co.uk?subject=Web Browsers & the Realtime Web Qs) or leaving a comment

Hosted realtime services – making the realtime web more accessible

Phil Leggetter — Tue, 24 Jan 2012 09:05:11 +0000

The real-time web started off by just being “cool”; a quirky and fun space to be in with lots of “cool” technology. People weren’t sure whether it was just a fad, stimulated by hype. The value it delivers in the form of customer engagement, interaction, collaboration and the opportunities it can provide by being real-time is now much clearer, and consequently the benefits of using real-time technologies are beginning to be understood.

Realtime Web Technology Accessibility

One of the problems with real-time technologies over the past 10+ years has been the accessibility. Comet servers were difficult to install, a pain to maintain and upgrade and generally difficult to use due to numerous configuration options and technology quirks, mainly exposed by different web browsers. There have been a number of very important changes have happened over the past few years that now make real-time technologies much more accessible.

Web Browser Wars

For such a long time Internet Explorer 6 was by far the best web browser available. It’s the reason that Microsoft “dropped the ball” and why Firefox and Chrome are where they are today. But now we are in a great position of having a number of actively developed web browsers being driven by real competition to offer the best browsing experience. This has lead to a general improvements in browser speed (JavaScript and rendering engines) but also improvements in web technology available to web browsers and, possibly most important of all, web standardisation. HTML5 does indeed rock!

Cloud Hosted Services

Cloud hosted services, frequently referred to as Infrastructure as a Service (IaaS). These hosted solutions take away the pain of installation, maintenance and scaling, and frequently deliver them at a fraction of the cost possible if you were self-hosting.

Better self hosted solutions

Cloud hosted services are awesome (I would say that, but they are!) but the self hosted realtime web solutions that are available and the ease of installation has massively improved. As an example, you can have a socket.io example page up and running on node.js within minutes. These improvements have been driven by an increased demand for

WebSockets

WebSockets is a standard for continuous bi-directional single-connection communication between client and server. Real-time technologies, and in particular real-time messaging within a web browser, has been possible before but not until WebSockets has there been a standard that is so likely to succeed. Unfortunately WebSockets don’t mean that the pain has completely gone away. The technology, whilst more accessible, still isn’t as easy as it could be for developers to use. On some platforms WebSocket server installation can still take too long, maintenance is just something developers don’t really want to do, and scaling takes time, effort and lots of configuration. So, we turn to the first important change as a solution to this problem – hosted realtime services.

Hosted realtime services

Hosted realtime services, like Pusher who I work for, make it much faster and easier for developers to start adding real-time functionality (push notifications, activity streams, realtime chat, collaboration, realtime data visualisations, multiplayer games, 2nd screen/Social TV experiences etc.) to their applications within minutes. For bigger organisations, the same solution also means that you know your developers are busy adding value, not installing, configuring and maintaining. This means they are happy and productive. The web is only around 20 years old and the real-time web is younger still. We don’t know exactly where the next few years will take the web but I’m sure that HTML5, WebSockets and real-time messaging will be a key component, and services like Pusher in a great position to help provide the infrastructure that developers need to easily use these technologies.

Where next?

If you found this interesting you might find my Realtime Web Technology Guide/List of interest. If you know of any technologies that I’ve missed, please get in touch.
Why not take a look at Pusher and the Pusher Blog

The Right Place At The Right Time: How The Real-Time Web Influences The “local” World

Phil Leggetter — Wed, 09 Nov 2011 17:09:37 +0000

A couple of hours ago I was on a on the ‘The Right Place At The Right Time: How The Real-Time Web Influences The “local” World’ panel at the Local Social Summit. The panel was organised and chaired by Sebastien Provencher and also included RyanMacJones, Dave Ambrose and Stefano Diemmi. Here’s the information about the panel and my thoughts on the questions that were asked.

Description

The rise of the real-time Web is well documented. Propelled by both the social networking revolution and mobile device ubiquitousness, we’re seeing the birth of new user services and business opportunities. In this panel, we will explore the time element in the local/social Web and will try to discover what kind of content works well in real-time, what are the benefits for consumers and what kind of business models can be deployed to leverage the “time” dimension.

Questions

Introduce yourself, describe your business

Phil Leggetter Developer Evangelist at Pusher Pusher is a cloud hosted service and API that makes it really easy to add cool realtime user engaging functionality, like push notifications, activity streams and chat, to any Web, Mobile, Tablet or Desktop application.

How do you define the real-time Web? What is the importance of the time dimension on the Web today?

Firstly I think we need to define ‘realtime’. Realtime means that when information is generated following an event of some kind, that information must be available and received in a timely manner so that the context of that information is not lost; so that the information is still relevant and usable. The realtime web, made popular by Twitter and the instant availability of information, takes this concept of timely information to the web. To me ‘the realtime web’ means that instant availability of information but also the instant distribution of that information. It means that those that have registered an interest in a pieces of information will have it pushed to them. It also means we now have the technology available for realtime (timely) bi-directional communication making realtime chat and collaboration using the Internet as the network something that is truly achievable.

How does the time dimension expresses itself in your business? or in the local/social universe, social media, daily deals, etc. (feel free to comment/provide examples outside of your business as well)

At a fundamental level Pusher is an Internet realtime messaging service. We aim to keep latency, the time between a message being sent and it being received, as low as possible so it’s a core part of our service. The value in realtime is the opportunity that receiving information as quickly as possible presents. The technology behind this comes from a trading background where milliseconds can mean getting the best price and can make the difference between getting a great price for a commodity/stock/share or a bad one. This results in potentially millions of pounds. Realtime in local and social also results in opportunity. The first to hear about and respond to a deal benefits. Those who are aware of the unexpected U2 concert on a near-by roof top have the opportunity to get there in time to see this one-off event. People aware of a terror threat or some other kind of emergency can act accordingly – either get the hell out of the area or head to it to cover the event or help out. It’s all about the opportunity that getting timely data presents.

What kind of content works well in real-time Web? Are there business categories that work better?

Traditionally realtime web technologies have been used in finance because that’s where the benefits have been greatest. This means that the content has been pricing information about stocks and shares along with news related to finance. But with both realtime technology and realtime data much more accessible we are seeing other businesses using and benefiting from it. Sports and betting data is the most obvious second step for this technology. Auctions are a good use and again this is really money driven. Then there’s business categories where people just want to get the information as soon as possible. News, sport scores, disaster warning systems, disaster relief and short lived deals are examples. Then there’s information around systems that allow for realtime collaboration; where people are working together to discuss and solve problems. Chat is the first obvious example but synchronised document editing is another more complex, yet highly beneficial one. Twitter demonstrates a form of chat but it’s only really good for broadcasting information and for one-to-one chat. If you want a multi-user experience you need to take the conversation away from Twitter. Google hangouts or apps such as !blether and Nurph are great for that.

What is the role of “mobile” in this evolution?

We’re seeing a lot of notification platforms for mobile, but that means the data is going just one way. In some cases this is all that’s needed e.g. “Daily Deal X available at Y”. But for collaborative applications you need more than just a notification infrastructure. For that we needs better mobile data infrastructure. In London it’s fine but where I live in Scotland it’s nearly non-existent. So, mobile and local is going to benefit a lot of people but not everybody. Also, mobile data plans need to be revamped to take into account we are becoming more data, and less voice focused.

What are the benefits for consumers? emergency/Short-term need vs. long term need. Real-time local news (Japan tsunami, London riots, hashtags, etc.)

I think we’ve already covered this. It’s about the opportunity that getting realtime information brings. To know something is going on and get to or away from somewhere as quickly as possible.

What are the business models (new or not) that emerge when we add the time dimension? Yield management /last-minute: real or hype? Is this real? Groupon Now disappointing?

There’s an excitement generated by having a time constraint. So I think in general we’ll see some fun ideas come out of this. I’m particularly excited to see some 2nd Screen applications that synchronise with live events or scheduled TV programmes. There’s an opportunity to add a lot more context and fun to TV beyond what we are watching and I’ve yet to see a really great example. I’m not a betting guy so I’ve not tried out PickLive but for this interested in Football and Fantasy Football I’m sure it’s a great experience. I want to see more in this space. What’s the business model? Probably synchronised contextual advertising and also increased user engagement in a programme, and TV figures mean more advertising revenue.

Are there technologies/technology stacks that are core to real-time? How do we implement real-time technologies?

Adding realtime functionality to an application is now easier than it’s ever been. In the past few years the technologies allowing realtime communication have improved and are much more accessible. Scaling and maintain such technology stacks can still be a problem which is one of the features that Pusher offers. For a true realtime experience the best technology in my opinion is WebSockets. They allow for low latency true bi-directional communication over the Internet. There are other HTTP-based techniques but they suffer from the overhead inherent in HTTP such as the additional load of HTTP Headers sent with each HTTP request. Browser techniques which do work have to be implemented in different ways in different web browsers. The standardised approach being taken with WebSockets means that it will become the best way of implementing realtime server to client bi-directional communication. Technologies worth a mention include:

Pusher: a hosted realtime service with APIs that make it really easy to add realtime user engaging functionality to a web, mobile, tablet or desktop app. Have I already said that?
PubSubHubbub: provides a way to subscribe to RSS feeds so that new content is instantly pushed to you as soon as it’s available. It’s a server to server technology and has been used more recently to let you subscribe to any arbitrary data, not just RSS. Node.js is big in the tech community because JavaScript is generally big on the Web and Node let’s you code in JavaScript on the server and client.
Socket.io is frequently used to add realtime functionality to Node apps.
SocketStream: WebSocket-powered web framework dedicated to creating single-page real time websites.

What are the benefits of the real-time Web to local shops/local commerce of real-time Web? location-based, customers on the go.

The ability to let people know of short term deals or the ability to sell perishable goods at the end of the day that would otherwise be wasted. I’ve heard of a product called Foodini that might be doing something in this space. FourSquare check-in can still provide more value to encourage meetups in areas where groups of friends hang out.

Typically real time does not allow for a lot of context beyond short bits of info. How does context play a deeper role as we move forward in a real time world?

As I mentioned earlier, context is absolutely key to getting real value from realtime information. Without context the data can be worthless. When something has a time constraint then context has to be present. Applications such as FourSquare add the context which gives it real value. Who has checked-in, where have they checked-in, what type of place have they checked-in to. All this key information let’s anybody viewing the check-in decide what to do. Tweets normally rely on you knowing a user. If you’ve missed the start of a conversation thread between two users you follow then, depending on the time constraints, the opportunity could be lost. Context is essential and as realtime web applications move forward this is most definitely the area where we need to, and will, see improvement.

The Zoom! book got me thinking about Kwwika

Phil Leggetter — Wed, 21 Sep 2011 15:50:48 +0000

I’ve just finished reading chapter 2 of Zoom! The faster way to make your business idea happen and to use one of Ian Sanders favourite words it really “resonated” with me and my experiences with Kwwika.

Chapter 2 is entitled “The trouble with too much planning. How to unplan your business”. I’ve been following Ian for probably around three years now and for around the last two he’s been talking, tweeting, blogging and vlogging about unplanning your business. I had tried to unplan Kwwika. The fact that it was a great idea, I had real passion for it and had a lot of potential to be used in many different ways unfortunately wasn’t enough for everybody involved. There had to be more of a business plan. This meant documents and spreadsheets. These documents and spreadsheets alone didn’t clearly show a massive turnover. But the spreadsheets were full of best guess estimates and didn’t take into account all the various possibilities and things that hadn’t even been thought of yet – how could they? Kwwika didn’t need a plan beyond the basics we already had in place. We had enough information to see that it was a great idea and had lots potential. What it needed was more faith, commitment* and belief in the idea. *It would probably be better to say that the commitment needed re-focused since there was plenty of time, effort and money spent on the project. Chapter 2 in Zoom! talks about a business idea needing a ‘why’ and a ‘who’. Why a business is needed and Who will make it happen. The Why for Kwwika has now been justified by services like Pusher, of which I’m now part, and the competitors PubNub and Beacon Push. There is absolutely no reason why Kwwika couldn’t still be running and competing too. The problem lies in the belief in the ‘why’ and the restrictive nature of the ‘who’, where a big part of the ‘who’ was me. One of the things that Gary Vaynerchuk talks about quite a bit is the importance of concentrating on what you are good at. If you’re not good at something, or if you know it could be done better by somebody else, then find that somebody else and get them to do it. This means you can focus on the things you are good at. We didn’t do this with Kwwika and it was partly my fault. It was my fault because I was on a good salary, knew the project was constantly under review and knew that at the start of 2012 I wanted to buy a home for my family. These all conflicted with how I should have approached Kwwika. My salary shouldn’t have been a salary at all. It should have been a budget to spend as required in order to give Kwwika a better chance of being successful. Knowing, or admitting, you are not good at something can be a difficult thing. I’m actually reasonably open and honest about this. I think I know what my strengths and weaknesses are although I do try to put myself in situations which I’d say are outside of my comfort zone. One example of this is that I actually really enjoy working with others although I work from home so quite frequently have to work alone. Another is giving talks. Since a kid, and a particularly bad experience trying to give a talk about the football team I was captain of, I’ve never been too keen on giving talks or presentations. But I’m now trying to put myself in situations where I have to do this to get over this worry, increase my confidence and to try and improve as a person. All this feeds in very well to chapter 3 of Zoom!, “Getting to grips with your mission. Why you need to understand what’s driving you”. More to come as I read on.