Today I'd like to play with ZeroMQ. ZeroMQ is a great tool to work with sockets. I will show you the problem that I want to solve: One web application needs to execute background processes but I need to execute those processes in order. Two users cannot execute one process at the same time. OK, if we face to this problem we can use Gearman. I've written various posts about Gearman (here and here for example). But today I want to play with ZeroMQ.

He uses React and some ZeroMQ bindings and Symfony's Process component to make a simple client and server for working with the queue and processes. A screencast is included in the post showing them making the connection and adding the new process. The full code can be found on github (or installable via Composer)

The new SDK is built on top of the Guzzle HTTP client framework, which provides increased performance and enables event-driven customization. Each AWS service client extends the Guzzle client and describes operations on the service using a service description file. The SDK now manages persistent connections for both serial and parallel requests. It detects transient network failures, with automatic retries using truncated exponential backoff. Support for event hooks (via the Symfony2 EventDispatcher) allows you to implement custom, event-driven behavior.

In the AWS post about the update, they give you a few code snippets showing this updated version in use. This completely reworked version of the SDK is not compatible with the previous version, so you'll need to consult their migration guide to bring things up to date.

As the technical manager of a suite of software projects, one of my duties is doing code reviews. One of the things I see far more often than I'd like when doing reviews is debugging PHP code committed and pushed up the chain. [...] The safest method of debugging requires configuring your IDE to use a tool like Xdebug or Zend Debugger to trace currently executing code. This isn't always practical. In the absence of using a fully configured debug environment, I turn to FirePHP.

He shows how to set up and configure FirePHP to work with your debugging and some suggestions on browser extensions you can install to view the messages. Sample code is included showing you how to use the tool to send messages back to the browser including grouping messages, building tables and something that shows a conditional caching report message.

Over a year ago I sort of reverse-engineered the protocol, and published a first rudimental library to produce and consume messages with version 0.05. Since then, the Kafka project has evolved a lot, moving from the LinkedIN repositories to the Apache Incubator, gaining traction, committers, features. The protocol has changed slightly too, so the old library doesn't work anymore with the new version (0.6+).

The library has gotten lots of new features in this update including gzip compression support, custom exception handling and better connection handling. He includes some sample code in the post showing how to create both the Producer and Consumer for the messages (and one for working with Zookeeper).

RabbitMQ is open-source message brokering software written in Erlang. The MQ in its name refers to a standard known as Advanced Message Queuing Protocol. For our purposes, and most others, it acts as a middleman between producer (sending) and consumer (receiving) programs - it simply accepts and forwards messages. [...] Both producers and consumers can be written in any language that has an available RabbitMQ or AMQP client library. In this article, I'll demo a producer program written in PHP and a consuming program in Python.

He walks you through the installation for both RabbitMQ itself and the PHP (php-amqlib) and Python (pika) tools to use for the interfaces. There's some details on how the queuing system works and the code for the sample clients is included as well as commands to use the two clients to send/receive messages.

In this article we'll explore the Dropbox API by building a simple client for accessing files in a Dropbox account. The client will perform some basic operations, such as authentication, listing files, and uploading and downloading files.

You can grab the full code on github that provides you with some of the base you'll need to access the service (and help to make the tutorial a little shorter). They walk you through the process to create a new application on the DropBox Developer site and how to use the keys they give you to connect your app. The client included with the github download then lets you call things like "getFile", "putFile" and "accountInfo" to push/pull information from their RESTful API.

When writing about socket programming with PHP, nearly all articles are about the Socket Extension, despite it's the unfriendliest and most cumbersome way to work with Sockets in modern PHP. Let me introduce you to something, which apparently is pretty unknown among PHP programmers.

He starts off by introducing the concept of a socket (for those that are beginners on the topic) and talks about two of the major ways to work with them - the Socket extension and Streams. He shows how to use the stream_socket_client_* functions to connect to a remote server and make a HTTP request for the base page. He also shows the other side of things, making a simple "echo" server that binds to port 1337.

Since version 1.9.2, PAGI comes with a mock of a pagi client, suitable to be used in your own unit tests, so you can test your telephony applications, like IVRs. The idea behind the mocked client is to let you test the callflow side of your application, the user interaction and the exact sequence an ivr application should obey. Let's see how to use it.

He shows how to test a basic PAGI application by hooking in the PAGI client into his PHPUnit test for the app and the code coverage of the result. The MockedClientImpl client lets you test the application without having the external dependency of actually running it. He includes some examples of commands and how they'd be mocked out with this client as well as a handy list of the "on*" methods available (like "onDial" or "onSayAlpha").

You can find the complete source for everything in the article on his github account.

I was recently asked why we chose REST over SOAP for our re-write of the FoxyCart.com API, and the short answer that immediately came to mind was, "Because I don't hate myself". To expand on that answer, let me give you a little bit of the back story.

He talks about their goals for the product and its API, how they wanted to create something useful, built by developers for developers. They leaned towards REST mostly because of the problems and overhead introduced with SOAP (and the complex nature of its requests). He also gives a few reasons why he's "excited about REST": working with known data types, standard interface methods and the fact that it's still such a hot topic of discussion.

These questions [about HATEOS, hypermedia, vendor-specific content types] might seem overwhelming, but for us they are exciting! We believe the future of consistent, powerful API development is being defined right now, and we get to be a part of it.

Wikipedia is the ultimate online encyclopedia, containing millions of entries on different aspects of human knowledge. Web application developers are able to access and search these entries through the Wikipedia API. This article introduces the Wikipedia API and demonstrates it in the context of a PHP application, explaining how to search and retrieve different elements of Wikipedia content with PHP.

He starts with a general introduction to the API including example feed results and URL request formats. From there he moves into the code - a mostly Zend Framework-driven example that uses the REST client. He shows how to make requests for categories, full-text search, grabbing raw page content and adding/editing the content of pages.