Pusher Blog

Spotlight: Moviepilot's realtime build status board

lina@pusher.com (lina) — Wed, 22 Feb 2012 00:00:00 +0000

Moviepilot is a network for film fans interested in upcoming movies around the globe. Moviepilot Labs recently released Shoutbox, a free, centralized system status dashboard service which requires pretty much zero configuration.

What was the problem you were trying to solve?

We wanted a real-time dashboard where we could visualize the current status of our project build. Initially we started using another WebSockets server, but it was acting oddly, requiring us to manually refresh our browser to see if there were changes in the status of our project.

What benefits does a realtime dashboard give your team?

A dashboard gives you an abstract view on your system without the need of actively collecting information snippets from various sources. As a dashboard screen on a wall can be seen by a lot of people it saves time regarding looking after systems and reducing the risk of overlooking a failure.

How can other development teams benefit from the dashboard/Shoutbox?

We know of other development teams having a dashboard screen in their development room. As the borders between server administration and development are rather blurry nowadays, an easy dashboard solution fills the niche between manual checking and complicated monitoring.

How did Pusher allow you to solve it?

Once we replaced the other server with Pusher, Shoutbox started to behave as we were expecting, now we can say that it gets updated as soon as we send messages to Pusher :D

I would totally recommend going with Pusher over having your own WebSockets server. With Pusher things just work, with another server you might need to think about it.

Are there any benefits of using a hosted solution over a self hosted one?

The main advantages of a hosted solution are of course: You can focus on usage instead of also having to take care of the solution itself.

Thanks to Caspar, Adolfo and the rest of the Moviepilotlabs team for a great service and an interesting case study. If you've built something useful and/or weird and wonderful we'd love to hear from you.

Epic Pusher Hacks at the Guardian, London

phil@pusher.com (phil) — Tue, 21 Feb 2012 00:00:00 +0000

On Saturday I attended a hack day organised by Apigee and hosted in The Guardien offices in London. It's great to go to hack events and see the innovative ways that developers can use Pusher. At my last count at least 6 teams used Pusher but we had to choose a winner...

Our winner: Wormr

Built by the guys from Assanka (who, as you can tell from the sneaky screenshot they sent me, are hiring).

Wormr is targeted at two types of user:

Speakers

"If you're giving a talk, and want to know how people are feeling through the duration of your talk, add the wormr JavaScript code to your slides and get realtime feedback."

Audiences

"Delighted? Disagree? Love it? Frustrated? Amazed? Bored? With wormr, you can now give your feedback direct to the speaker. If you're in a talk right now, then enter the talk id and start voting."

The reason I like this is that it's something I've actually built a little widget for myself that does something similar, but not as well. Realtime feedback within a presentation is a really cool idea, if nothing else it shows off the realtime technology really well. Great work guys. You deserved your Arduino kit. I hope to see the same innovation in using it.

I also found out that the guys built Meteor in 2006. Great to meet some realtime web tech pioneers. I hope to drag them over to using Pusher soon :)

Noteworthy mentions

Nobody Expects

The Nobody Expects team (yes, they were all Spanish) built a realtime hangman game. But, instead of saving a man from being hung you had to save a cat from being burnt (they do like cats, it was just a game). It was multiplayer and used Pearson and Pusher.

Realtime Switchboard

Our friend from Twilio, Stevie Graham, built a switchboard web app where users could phone a Twilio number and the number of the caller would then instantly be pushed to a web dashboard using Pusher. Then the call could be answered and conversation would ensue using Twilio. Very cool and very useful.

I hope to write another blog post about this in the future

Who else was there?

Along with us the APIs represented at the event covered a range of functionalit and potential:

Vodafone, who are looking to push out a bunch of new APIS, but made sendMessage, trackPhone and makePayment methods available for the event
Pearson offering access to a Longman Dictionary API (with useful audio samples), FT Press and Eyewitness Guides
Betfair with a massive range of functionality, with an obvious focus on betting
inmobi focusing on mobile advertising

We want to be at your hack day

If you are running a hack day and need API representatives please give us a shout. We'd love to get involved.

Tweek: Using Pusher to improve our dev process

phil@pusher.com (phil) — Wed, 08 Feb 2012 00:00:00 +0000

We’re always on the lookout for cool and innovative ways of using Pusher so when Klaus Hartl of Tweek told us about how they’d been using Pusher we thought "that's cool! Let's put that in a blog post".

What was the problem you were trying to solve?

In the past I had been using Livereload sucessfully for desktop targeted frontend-development. It makes continuous testing much easier and faster, especially the CSS part of it; no more hitting cmd-R. At Tweek though we’re developing an iPad only web application but we didn’t want to go back to tapping the reload icon while developing. It only adds up when developing for different OS versions and devices. We needed a solution that met the following requirements:

a. has to work in any browser (i.e. won’t require browser extension), in our case mainly iOS (that’s just the start). Browser here may also mean a web view within a native application.
b. hassle-free (portable, no need to download and install any applications + browser extensions): git clone, little bit of configuration and done.

We decided to use Pusher, which we were using for other parts of our app already anyway. Our first implementation doesn't work exactly like Livereload in that it does not inject only the new CSS but always reloads the entire page. This is good enough for our needs.

How did Pusher allow you to solve it?

Pusher's ruby gem allowed us to easily build a Guard, which is a command line tool to easily handle file system modification events, to monitor files for changes and let any listener know in realtime of such a change. It's like autotest on steroids! So whenever the Pusher Guard detects a file change it instantly publishes a Pusher event to let any listeners know.

Once the guard-pusher gem was in place and running, our homegrown Livereload was a simple matter of adding a few lines of JS code to our application view in development environment of our Rails backed application:

     var pusher = new Pusher('...');
     pusher.subscribe('guard-pusher').bind('guard', function() {
         location.reload();
     });

The guard-pusher gem isn't restricted to CSS or JavaScript at all. The developer decides which files to watch for modifications, that’s simply configuration in the Guardfile. Also, obviously, it doesn't have to be Livereload at all, it's just that I chose to use it like that (the location.reload() part in the listener function).

How can other developers benefit from your solution?

By automating the "how to get updates in client-side code to any number of browsers" it makes cross-browser development more efficient and fun. No more manual browser reloading!

It may also help with continuously running JS unit tests across a variety of browsers at the same time.

A big thanks to Klaus and the team at Tweek for coming up with this cool use of Pusher that could come in really handy during development. It's great to see that our free Sandbox plan can add real value to the development process. If you've build something useful and/or weird and wonderful we'd love to hear from you.

Build realtime web apps together

phil@pusher.com (phil) — Fri, 03 Feb 2012 00:00:00 +0000

Wouldn't it be handy if you could give access to your Pusher apps to friends and colleagues so that you can easily work together on building an awesome realtime web app? Well, now it's possible. We've made it easy for you to share access to your:

Debug console
Usage stats
API keys
WebHook settings
Event creator

Sharing access to an application is simple:

Log into the Pusher dashboard
Select the app you'd like to share
Select the 'Collaborate' tab
Enter the emails of the people that you'd like to share with and click 'invite'
An email will be sent to the person you've invited telling them the good news

It's as easy as that. Have fun collaborating!

We want to know if this is useful, so please let us know what your experience is, and whether you have any feedback.

Introducing Pusher WebHooks

martyn@new-bamboo.co.uk (martyn) — Thu, 26 Jan 2012 00:00:00 +0000

One of our primary goals when building Pusher has always been simplicity. Part of this is about hiding complexity, and providing clear and simple APIs for developers to use.

However, under the covers there is a complex distributed system handling all the messages and events which occur inside Pusher.

Exposing complexity via simple mechanisms

As well as distributing messages, we'd like to make it simple for you to consume some of our internal events so that you can build more powerful apps with Pusher. Our initial implementation uses WebHooks, which are a fantastically simple and elegant way for servers to send each other notifications.

The first class of events which we're exposing allows your servers to be notified when any channel becomes occupied or vacant. There are a number of ways that this can be useful:

Reducing the number of messages you send us
Performing tasks when users subscribe to channels
Building custom presence solutions on your server

As an example of the former, Panda is a video encoding service that displays the realtime encoding status of a user's videos via a lovely dashboard. They were making huge numbers of API calls to Pusher, notifying users who weren't online of status updates to their encodings. By using WebHooks, they've cut down massively on their API traffic by only sending events when someone is subscribed.

Check out our example application

We've built a demo application, filtrand to further demonstrate how Webhooks can be used. This app starts searching the twitter streaming API for one or more terms whenever a user subscribes to the appropriate channel. We've published a blog post that goes into more detail.

Getting started

Full details on the format of WebHooks and how to integrate them are available in our WebHook docs. We've aimed to make this feature incredibly easy to get up and running with, but get in touch if you run into any problems.

Please note that we're not charging for Webhooks initially, but it's likely that they will count towards your message quota in future.

Taking things further

We have many plans for extending the list of events we expose in future. As usual with new features, we're keen to hear how people are using them, so please let us know what you think, and show us the cool things you build.

Filtrand: a demo of Webhooks

maryrosecook@pusher.com (maryrosecook) — Thu, 26 Jan 2012 00:00:00 +0000

With webhooks, Pusher can repost interesting events that occur in your app to a URL of your choice.

We've built a demo, Filtrand, to show you how it works. If you go to the Filtrand home page and enter a subject you are interested in, you will see a stream of tweets that mention this subject.

"How does it work?"

When a user specifies a subject - let us say, "baseball" - the Pusher JavaScript library subscribes them to a channel with that name. They - and all the other users subscribed to that subject - will receive all events emitted on that channel.

Filtrand includes a Node.js server hosted on Heroku. This server uses a module called Twitter Node to stream in tweets that contain one of the subjects specified by a user. Each tweet streamed in is emitted on all the channels to which it pertains. That is, on all the channels with names that appear in the tweet.

So, how does the Node.js server know when a user becomes interested in a subject? Well, Filtrand could have gone old school and posted requests from the subject form to an action on its Node.js server. That would have worked.

But, what if the user loses interest in the subject and closes their browser? The Node.js server would still be dutifully pumping out tweets about Scarlett Johansson, but no one would be listening.

Luckily, we built Filtrand with magic as our base metal: we built it with webhooks.

"What are these Pusher Webhooks?"

Webhooks exposes an internal event called channel existence. Each time the first person joins a channel, a channel_occupied event is emitted, and each time the last person leaves a channel, a channel_vacated event is emitted.

To enable this functionality in your app, go to your account dashboard, find your app, click on the webhooks link, click the enable webhooks check box, click the enable channel existence events check box and enter the URL to which you want to post channel existence events.

We did this for Filtrand, so when someone expresses an interest in anarcho-primivitism, our Node.js server gets informed of this via a webhook from Pusher and starts requesting tweets on the subject from Twitter. When the last person on the anarcho-primivitism channel closes their browser or leaves the Filtrand subject page, another webhook is sent to the Node.js server and it stops requesting tweets on that subject.

"How do I get started?"

Read the documentation, or just head straight to your dashboard to set things up.

New Pusher-JS version released - 1.11.0

max@new-bamboo.co.uk (max) — Thu, 05 Jan 2012 00:00:00 +0000

We are excited to announce a new JS version that includes a number of changes. These are outlined in a bit more detail below.

Please note that this version of our JS is hosted under the domain js.pusher.com rather than js.pusherapp.com. All subsequent versions will use this domain too. While we will continue to support the old domain for previous versions, it is considered deprecated from this point onwards. If you are fetching the files over SSL, you will need to use the domain https://d3dy5gmtp8yhk7.cloudfront.net/ (previously https://d3ds63zw57jt09.cloudfront.net/).

All previous versions of the JS are also available from js.pusher.com, so even if you are not yet ready to update to the latest version, please consider at least changing your URL to the new domain in readiness.

Connection reliability

This version of our JS is coupled with some new connection management code on our servers. This should greatly increase the reliability for a subset of our users who have experienced issues relating to zombie connections hanging around, and for people who have experienced issues when waking their computers from sleep (eg https://github.com/pusher/pusher-js/issues/11).

We are particularly interested in feedback about this feature, so let us know if you how you get on with it.

Directing warnings to your console

We now have a warn method that directs issues such as invalid or missing credentials to console.error (if available) regardless of whether you have enabled debugging. This aims to avoid situations where problems are hidden from developers, and is only used for unexpected errors. For example, the lack of an internet connection, leading to Pusher failing to connect, will be logged using Pusher.log as previously.

If you'd like to avoid any possibility of warnings appearing for your users you can easily over-ride the function, e.g. Pusher.warn = function() {}.

Unbinding from events

As requested (https://github.com/pusher/pusher-js/issues/12), it is now possible to remove callbacks you have previously added to events from the WebSocket connection. This is especially useful in single page apps where a change of state means binding to a different set of callbacks.

Cleaning up

In this release, we have removed or made unavailable a number of variables and bindings that were essentially private, such as Pusher.Channel.is_private and Pusher.Channel.is_presence. In addition, it is no longer possible for developers to bind to pusher_internal events. These events were marked as internal to allow us to change them without affecting the public interface of our library. If you have used these, you will need to change your code accordingly.

We hope you like this version of our Javascript, and that it makes your usage of Pusher more productive. As usual, if you have any problems or suggestions, please contact support@pusher.com.

Pusher JS 1.10 released

phil@pusher.com (phil) — Tue, 06 Dec 2011 00:00:00 +0000

We update the Pusher JavaScript client library fairly frequently, but in this update we're making a few public API changes. These include: a change to the subscription error event name, the addition of a subscription succeeded event and a return value for the pusher.trigger method. So we though it warranted a blog post.

Subscription errors

If an event is triggered by either Pusher or a Pusher client library we follow the convention of prefixing the event name with pusher:. A while ago, we added an event to the Pusher JavaScript library which is triggered if an error occurs when subscribing to a channel. (More specifically, it is triggered when authenticating the subscription.) However, we forgot to prefix the event name. So, we've fixed this in 1.10 and updated our docs and the blog post about this.

var pusher = new Pusher('APP_KEY');
var channel = pusher.subscribe('private-channel');
channel.bind('pusher:subscription_error', function(status) {
  //  handle error
});

Subscription success

Since you're notified when a subscription fails it makes sense to know when a subscription succeeds. So, we've added an event of for that.

This is a very important update if you use client events, because this event gives you a way of knowing that you are safe to trigger client events. In earlier versions of the library, if you attempted to trigger an event on a channel before the channel subscription had registered with Pusher the event would not be published. It's now possible to avoid this scenario by waiting for subscription confirmation before triggering the client event:

var pusher = new Pusher('APP_KEY');
var channel = pusher.subscribe('private-channel');
channel.bind('pusher:subscription_succeeded', function() {
  var triggered = channel.trigger('client-my_event', {some:'data'});
});

There's more information about this in the pusher:subscription_succeeded docs.

Triggering client events

We're seeing an increasing number of requests for client events (especially useful within fast-paced HTML5 multiplayer games) and, as we've seen above, it's good to know the result of any action, so we've updated the channel.trigger function to return a Boolean value that indicates whether or not the event was triggered successfully.

var pusher = new Pusher('APP_KEY');
var channel = pusher.subscribe('private-channel');
channel.bind('pusher:subscription_succeeded', function() {
  var triggered = channel.trigger('client-my_event', {some:'data'});
  if(triggered) {
    console.log("Awesome! I've sent a client event");
  }
});

There's more information about this in the triggering client events docs.

Final notes

The changes to the public API hopefully maintain consistency and provide a bit more functionality which will make building realtime HTML5 apps even easier.

The new version of the Pusher JavaScript library can be found in the following locations:

http://js.pusherapp.com/1.10/pusher.min.js (just pusher.js for non-minified version)
https://d3ds63zw57jt09.cloudfront.net/1.10/pusher.min.js

We recommend you include the minor version (1.10) and not the patch (1.10.1) so that you benefit from automatically receiving bug fixes. We'll won't update a minor version with a change that affects the public API.

As always, we've pushed a change log and the source for the Pusher JavaScript library to github.

Ways to use Pusher at the Mozilla Festival

phil@pusher.com (phil) — Thu, 03 Nov 2011 00:00:00 +0000

We're excited about attending the Mozilla Festival from Friday 4th to Sunday 6th of November and I thought it was worth writing something which might give attendees a better idea about how Pusher could be used in a few of the design challenges. Pusher can be used for realtime multiplayer HTML5 Games, notifications, collaboration, social media integration, realtime data display and visualisation; all of which add an extra level of engagement to the user experience. But solid examples tend to really help. So, here are a few ideas that I could come up with and hopefully they'll plant a few seeds for greater ideas.

But first...

Human APIs

Both Mary and I will be attending the festival as Human APIs so please keep an eye our for us, say "hi" and grab hold of us to help you add cool realtime, multi-user, collaborative engaging experiences to the apps and games that you are building. It's exactly what we are there for!

Here are some mugshots so you know who to look out for:

Mary Rose Cook	Phil Leggetter
@maryrosecook	@leggetter

Balancing the Newsflow: Real-time reporting vs. the big picture

Challenge: Workflow and user experience that seamlessly integrates real time reporting into the big picture

Although the focus here is on creating a workflow the application that makes this possible is a very exciting concept. Firstly there is a requirement to ensure news is captured and curated from a number of sources. News is frequently broken on Twitter then augmented by blogs, pictures, video and audio. The first step in this process might be to gather and curate realtime data. DataSift, with it's Firehose access to Twitter along with a host of other sources, is a great starting point for gathering that data. Not only can it be used to gather the data but also to curate it using their augmentation targets.

Once we have one, or a number of, reliable realtime streams of information set up within DataSift (or we've found existing ones) we then need to distribute this information to an application. Pusher is an ideal service for this last mile delivery of data from your own application server which is consuming data from DataSift and then pushing that information to web, mobile, tablet and desktop applications.

Once the data reaches the application that data needs to be visualised for a manual curation step, to allow human being to verify sources, to check information and to take that data and start building up a story. Storify have a fantastic platform for doing this with historical data but would it be possible to add an intuitive realtime layer to their user interface? How can those realtime updates be pushed into a live-updated published story?

So, we have the infrastructure to build an application which can certainly deliver a realtime centralised workflow what will they need the app to do? Will they want to be able to collaborative edit the document and manage the synchronisation between mobile and web apps? Will they want activity streams of realtime tweets or blog posts to be pushed into the application and easily dragged and dropped into the news story? Will they want to be able to chat to other reporters attending the news event?

I'm looking forward to fully understanding the requirements, seeing how these apps might be used and what the final stages of curating, augmenting and publishing will be.

Games that rock the browser

Challenge: Port a classic game to run directly in the browser

We're seeing a number of fantastic HTML5 games hit our browsers. We're particularly interested in the multiplayer games. From augmented classics like WordSquared to Rawkets and the Isogenic Engine powered Iso City we've seen some great HTML5 games but what classics would benefit from a realtime multiplayer aspect? I'd love to see any of the following ported:

Team 17's Worms (check out Tanked)
A multi-player Chase H.Q where you can be the chaser, Tony Gibson, or one of multiple villains
A massively multiplayer Bomberman. WordSquared has demonstrated that it's great when a game has no boundaries. How about a never ending maze around the Bomber Planet.
Gauntlet - this one might be quite tricky but I remember is was great fun to play with friends.
Super Off Road. Well, just because it was awesome!

Passing Notes in Class: Making educational video a social experience

Challenge: Synchronize and super-charge online discussions around educational video

It's worth providing a bit more information from the Mozilla Festival Challenges page for this one:

But there are still big gaps in how learners can track and participate in online discussions while viewing these videos. How do we “talk back” to online video in ways that captures the social and interactive flavour of the best classroom experiences?

This one perfectly suits realtime collaboration. Time-based Q&A about something in the video. Realtime commenting and chat. Potentially with a moderation feature to ensure there isn't too much "classroom atmosphere" introduced. And why not add the ability to throw pieces of chewed up rubber or paper at other classmates!

Popcorn Bounties: Improve interactive video on the web

Challenge: Drive open video by fixing and extending the Popcorn.js JavaScript library

Popcorn.js is crying out for a collaborative editing plugin so that geographically distributed people can work together on building video that not only interacts with your web page but with other editors, and why not others that are watching the video a the same time.

Verifying Breaking News Sources: How can we know who to trust?

Challenge: A social approach to verifying sources in real-time crisis reporting

We've already got some good curation tools, I've already mentioned DataSift and their Augmentation targets, an alternative might be some of which offer APIs like Cadmus. So, why not create an application that crowd sources the curation of news? The users can login to the system and they can potentially be identified by geographic location, using the geolocation API. Then as the news is received it could be distributed to users who should be able to verify it and curate it - maybe with voting buttons.

Remember, we're there to help

Hopefully that gives you a few ideas of how you could use Pusher. If you have any questions, thoughts or need some help please grab hold of us or tweet at us Mary: @maryrosecook and I @leggetter.

Meet the Pushers: Getting Evented

phil@pusher.com (phil) — Fri, 28 Oct 2011 00:00:00 +0000

We've been busy over the past month attending events like Reject.js, JSConf.eu, Nodejsconf.it, GiveCamp UK, FailConf and the Business of APIs conference and things aren't going to calm down any time soon. We're going to be attending a whole bunch of conferences and events over the coming weeks and we'd love it if you came along and said "hi".

Ru3y Manor, October 29th, London

Lookout for Mary Rose Cook at Ru3y Manor. Check out the schedule for this event, it really looks great! "Jruby on elephants", now that sounds interesting.

Silicon Milkroundabout, November 30, London

If you are looking for an awesome job at a startup then the Silicon Milkroundabout is the place to go. We'll be there represented by Mary, Micheil and Lina who joined us just this week.

New Game Conference, November 1 - 2, San Francisco

Max Williams, our CEO, will be attending New Game Conference in San Francisco early next week. There's a fantastic line-up of speakers at this event and I can't wait to hear how it goes.

RubyConf Brazil, 3 - 4 November, São Paulo, Brazil

Our CTO Martyn Loughran is lucky enough to be heading over to Brazil to attend RubyConf. We're also one of the sponsors of this awesome event.

Mozilla Festival, 4 - 6 November, London

I'll are attending one of sponsors of the Mozilla Festival along with Mary where we'll be Human APIs. This means that if you are there we want you to grab us, ask us questions and even get us to write code for you.

Keeping it Realtime Conference, 7 - 8 November, Portland OR

There was no way we were missing the Keeping it Realtime Conference. We'll be represented by Max, Damien, Martyn and Micheil Smith.

We're pleased to be a sponsor of the event and we'll be giving a couple of talks so take a look at the schedule for more info.

Local Social Summit, 9 - 10 November, London

The Local Social Summit isn't as dev-focused as normal but most definitely a realtime theme. I'll be on a panel discussing "How The Real-Rime Web Influences The 'local' World" and I'm looking forward to hearing Tim Plyming, who is Project Executive of Digital & Editor Live Sites at the BBC, talk about BBC London 2012: The First Digital Olympics.