I was approached by a betting/gambling development company who potentially needed a middleware building that would pull from an existing gambling web service and basically transmit to connected iPhone clients the changes from the web service. At first, the obvious answer might be to create another REST web service that the iPhone clients could just ping for changes. However, one of the devs explained that this wouldn't be fast enough, or scale - they'd need changes to be transmitted as soon as possible, as the app would be a real-time betting app and there'd be thousands of connections to the server.

His solution involved hooking together Ratchet, Redis, Silex and Predis-async to create this sample tool for handling the websocket requests. it uses the "pubsub" mechanism of Redis to push the updates out to listening clients.

Do you want to spice up your web applications by making them real-time - but don't want to create new infrastructures for the sole purpose of getting web sockets to work? In this article, we'll explore how to use and implement Pusher, an HTML5 WebSocket-powered real-time messaging service for your applications.

Pusher uses HTML5 WebSockets to handle the messaging, so you'll need a browser that supports it to follow along with the tutorial. The Pusher API provides and endpoint for authorization and the push and pull of messages. In the tutorial, they create a simple chat application that gives a "Who's Online" and a window with the latest messages. You can download the full source (Javascript and PHP) here or view a demo here.

The inspection of the error logs is a common way to detect errors and bugs. We also can show errors on-screen within our developement server, or we even can use great tools like firePHP to show our PHP errors and warnings inside our firebug console. That's cool, but we only can see our session errors/warnings. If we want to see another's errors we need to inspect the error log. tail -f is our friend, but we need to surf against all the warnings of all sessions to see our desired ones. Because of that I want to build a tool to monitor my PHP applications in real-time.

The service will work similar to a chat server, sending messages one at a time to the remote server via a web client (HTML5-based) and some backend PHP. He includes all the code you'll need to create the HTTP and web socket server as well as the web client (with some Javascript) and some example server-side PHP. It throws an exception and catches it to send to the waiting Node.js server. A screencast is also included showing the full process. You can get the complete code for this example in this repository on Gonzalo's github account.

Real time communications are cool, isn't it? Something impossible to do five years ago now (or almost impossible) is already available. Nowadays we have two possible solutions. WebSockets and Comet. [...] I prefer to use comet (at least now). It's not as good as websockets but pretty straightforward ant it works (even on IE). Now I'm going to explain a little script that I've got to perform a comet communications, made with PHP.

His little sample application detects when a user has clicked on a link by subscribing to an event and using the javascript callback to send the message of a click event and wait for a response. You can find the complete code for the example over on github.

The classic example for websockets is a chat. This chat example has only 200 lines of code (excl. the Websocket class), is really easy to understand and customizable.

He creates a basic "WebsocketClass" class that (in his example) connects to an IP and port. It uses JSON as the messaging format and some basic javascript to handle the clicks of the "chat" and "login" buttons. You can see an example in action here and download the source for the server.php here.

Physical interfaces such as button panels or remote controls have many disadvantages. Panel controls require a dedicated display for feedback and physical access to a fixed location. IR remote controls offer only one-way communication with limited feedback and can become difficult to manage for multiple devices. [...] We propose a new type of solution to address these issues and bring simplified management and control to a broader market through embedded virtual interfaces.

He lays out the structure of the application, some of the issues that could come up in the connection (using COMET and Websockets). His proof of concept is a connection to a HDMI switch that can be talked to through an embedded controller via a simple interface.

We will create realtime chart data update that reflect to price fluctuation. There is a line type chart to visualize the price fluctuation. The data of price fluctuation will be fetched from database every 5 seconds using Ajax call and then display the latest 5 (five) data to the chart without any page refresh.

Using FusionCharts and Prototype, they show how to pull information out of a backend MySQL database into a basic graph (HTML and Javascript provided) with a periodic update that grabs the latest from the backend PHP script and pushes it to the graph. You can see an example of the graph here.

One big issue of the PHP error handling is that there's no built-in way to catch fatal errors with an user-defined error handler. So I thought a little bit about it and maybe you have better approaches or solutions...

With the goal of emailing the developers when such an error is thrown, he comes up with three different "storage methods" - using syslog, sapi, or a common logfile - and two different methods for watching them - file watching and syslogger. He works through these two options, trying to figure out which out be the simplest to implement.

He comes to the conclusion, though, that he might just be better off with one of the packages already out there to do something similar. Of the four he found, Swatch seemed to fit the best. He includes configuration and setup info to illustrate.

I have a lot more change's i'd like to make to webthumb so the last article (Adding AJAX to a website step by step) is now the start of the series. In this article will be taking front page of webthumb and making it live. The the stats and recent thumbnails will update in real time, making for a nice slick presentation.

I hope to release and article for each improvement I make to webthumb, giving everyone idea of whats involved in AJAXing a real website. But a series of articles won't cover everything you want to know about AJAX.

The focus in this new post is his method of grabbing the latest information from the server without a needless page reload. In this case, that means grabbing the latest thumbnails that have been created.

He includes the code for the different parts: exporting the PHP class to allow the Javascript to access it, a sample response from the HTML_AJAX server and the server code itself. From there, it's back to the client side for the Javascript code to make the request (and set a timer on it) and updating the page with the latest content. There's also a brief mention of how HTML_AJAX can push out other Javascript libraries, which he uses to push moo.fx for a transition effect on the thumbnails.