Brandon Savage has posted a quick overview of working with PHP and RabbitMQ for queuing. This is the first part of a three-part series about using these two technologies together effectively.

There are many times that you want to write background processes and queue up the tasks so that they can be handled in sequential order. There are any number of queues available for software developers, and one that I've really taken a liking to is RabbitMQ. Besides the fact that the queue is designed to requeue messages that are unsuccessfully delivered, RabbitMQ is fast and efficient.

He introduces some of the basic concepts behind working with RabbitMQ (like connections and channels) and an "exchange" - the method by which messages are routed. He talks about pushing messages to the exchange to be handled and how you consume the queue for updates. He also links to the various things you'll need to install to start combining these two tools including the AMPQ PECL extension.

On PHPMaster.com they've posted a new tutorial by Sean Hudgston that helps you understand HTTP digest authentication, a simple way to authenticate a user or script against your application.

Digest Access Authentication is one method that a client and server can use to exchange credentials over HTTP. This method uses a combination of the password and other bits of information to create an MD5 hash which is then sent to the server to authenticate. Sending a hash avoids the problems with sending a password in clear text, a shortfall of Basic Access Authentication.

He starts out by looking at the "basic authentication" mechanism that's built into most web servers and points out that it has a major flaw - sending the username/password in (pretty much) plain text. Digest, on the other hand, uses a MD5 hash created from a few pieces of information including username, realm and request method. The result is sent as a header back to the server that can then be parsed by PHP. He also talks about improving on the basic version of the digest method using the qop, nc, and cnonce optional parameters.

In the latest to his site Matthew Setter takes a look at easy routing with RouteMatch in Zend Framework 2 applications. The RouteMatch component gives you better control over your routing and lets you define "match paths" for URL to Controller mappings.

Today using Zend Framework 2 RouteMatch, Router and Request objects, I show you an easy way to dynamically update the current route. It's almost painlessly simple. [...] Well, like most things in web application development, what starts out simply in the beginner often grows more complex over time. So too is my once simple route.

His "simple" route started getting a bit out of control when he added in some pagination to the page (and query for the path match). He wanted to figure out how to re-render data with the same filters but show the next page of data. He shows how to use the RouteMatch component to achieve just this. He creates a custom module with a "listViewToolbar" helper that lets you read the router, request and handle the parameters sent via the URL. The "invoke" method is called to render the toolbar in the page, complete with the new settings.

NetTus.com has followed up their previous article covering some of the basics of the HTTP protocol with this new post, part 2 of the series. They suggest that HTTP, the messaging format of the web, is the one protocol that every web developer should know.

In my previous article, we covered some of HTTP's basics, such as the URL scheme, status codes and request/response headers. With that as our foundation, we will look at the finer aspects of HTTP, like connection handling, authentication and HTTP caching. These topics are fairly extensive, but we'll cover the most important bits.

In this article, they talk about things like the HTTPS secure version of HTTP, server-side connection handling, identification/authorization and working with caching and cache control headers.

On NetTuts.com there's a new tutorial about what they think is the one thing every web developer should understand - the HTTP protocol and how its used in web-based communications.

HTTP stands for Hypertext Transfer Protocol. It's a stateless, application-layer protocol for communicating between distributed systems, and is the foundation of the modern web. As a web developer, we all must have a strong understanding of this protocol. Let's review this powerful protocol through the lens of a web developer. We'll tackle the topic in two parts. In this first entry, we'll cover the basics and outline the various request and response headers.

They cover some of the basics of the protocol first including its statelessness, the concept of URLs and the HTTP "verbs" (like GET, POST and DELETE). They also briefly cover the HTTP response codes (ex. 200, 304) and the flow of the request and response to and from the web server. They also look at some of the basic HTTP headers and the actual low-level text formats of the requests/responses.

There's a section at the end of the post that links you to a few tools that you can use to view the HTTP messaging happening in your requests, some of which you might already have. They also briefly cover the use of HTTP in a few libraries - ExpressJS, Ruby on Rails and jQuery's Ajax handling.

Chris Jones has a new post to his Oracle blog today talking about the new "opcode" opcode caching that's going to be built into future PHP versions This is the implementation of the Zend Optimizer+ opcode caching in a native language interface. The latest PHP 5.5 snapshots have it included.

The new "opcache" can be seen as substitute for the venerable APC cache, the maintenance of which had become an issue. Note: although opcache is now readily available, there is currently nothing preventing you from using any available (working!) opcode cache in PHP 5.5.

He gives you a quick guide to getting this new opcode caching enabled and compiled into a shiny new download of the PHP 5.5.x branch. You'll need a special command line flag on the compile and to update your php.ini to load the needed shares module. You can also use it if you're on PHP 5.2 or higher either by compiling this source or using this PECL extension.

On the "System Architect" site there's a recent post showing you how to integrate PHP and Solr, the searching tool from the Apache project.

So why do you need a search engine, is database not enough? If you create a small website it might not matter. With medium or big size applications it's often wiser to go for a search engine. Saying that, even a small websites can benefit from Solr if you desire a high level of relevance in search results.

Their example involves an ecommerce website and a search for a term (iPhones) and how difficult it could be to match against the possible multiple variations on the models. Solr makes this kind of searching easier. He shows you how to get a Solr instance all set up and configured as well as the PHP PECL extension from here. A sample PHP script is also included showing connecting to Solr, inserting a new document and searching for a simple query of "hello".

The latest issue of the Web and PHP Magazine has been published - issue #12, "Don't get in a PECL". This latest issue includes articles like:

• "The Power of PECL" by Simon Holywell
• "Be 'ready' if you want to be done!" by Steffan Surdek
• "All Data is Relational" by Cory Isaacson
• "Fixing PHP Production Problems with APM" by Dan Delany and Chris Kelly
• "Trust" by Sebastian Bergmann

You can download your copy for free from their site and catch up on back issues.

Lorna Mitchell has a new post today showing you how to install XHGui to help with profiling your application for performance and processing issues.

If you're not familiar with XHGui it's a fabulously easy and friendly way to profile your application; to understand which method calls in a page take the time and how many times they are made, so you can improve the performance of your application. All these instructions are for my 32-bit Ubuntu 12.10 system, hopefully they will work for you or you'll be able to adapt them as appropriate.

She lists the dependencies you'll need to have installed before you can get XHGui working correctly including a MongoDB instance and the PECL xhprof extension. With those all set to go, you can go grab the latest XHGui from github and drop it into place.

Lukas Smith has a new post today about what he sees as an important part of PHP (or really most open source projects) - a predictable release cycle. It centers around the recent proposal to introduce the Zend Optimizer+ into the core and how it seems to be causing a delay with 5.5 (maybe up to 2 months).

What troubles me though is that its being proposed very late in the game for PHP 5.5, therefore causing a likely delay of 5.5 of at least about 2 months in the best case scenario if it were included. The other option of including it in 5.6 does not seem to be as popular at this point. This saddens me quite a bit since I believe that predictable release cycles would carry several advantages

He points out some things that come along with having predicability around the software releases like developers knowing when/if their changes will make it into the next release. It also makes it easier for end users to plan their releases of their own software, knowing when they'll be getting a feature. In this particular case, though, he doesn't quite understand the delay as the Zend Optimizer+ isn't a change to core, it's an addition:

What is even stranger for this case is that we are just talking about an extension here. Its not a language feature, there is no engine level integration. So even if its not added to core, people can easily get Optimizer+ via PECL. So in this case we are not talking about people having to wait another 10-11 months. Don't get me wrong I think getting an opcode cache into core is awesome, but the reality is that shared host users will probably still not have access to it [...] and the rest can still get it, albeit with a bit more effort.