On PHPMaster.com today there's a new tutorial showing you a different method for debugging your code than the usual print_r or var_dump - using FirePHP, a tool that uses messaging to relay information back to your browser.

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.

On PHPMaster.com today there's a new post for all the Zend Framework (v1) users out there. In it, Aurelio De Rosa shows you how to set custom error messages for elements in a Zend_Form.

In this article I'll show the solution to a common problem which arises when a developer has to create a non-English website or application that is based on the Zend Framework. How do we mark a field of a Zend_Form which is a Zend_Form_Element as invalid, showing one or more custom error messages? The problem is mainly caused by the native counter-intuitive methods of the Zend_Form_Element class which I'll explain in more details.

He's included a basic example showing the creation of a form and the setup of a text element and some validators to match. He makes a controller and view to handle the output and submission then shows how to use "setErrors" (and "setErrorMessages") of the Zend_Form elements to setup that custom error. This only lets you set one message, though, regardless of the point of failure. To stop things when there's an error, you have to set the "breakChainOnFailure" parameter on the validator to false - then the message will make more sense.

In this new tutorial on LearnComputer.com, they show you how to, using a simple call to PHP's mail function, you can send a text message to anyone.

Text messaging seems more convenient than making phone calls and creating your own PHP script to send these messages is a very easy thing to set up. Get on board with these other companies that have found how convenient text messages are for their customer and start integrating text messaging into your PHP applications. In this article, I will show you two ways to accomplish this and you will be surprised at how simple this is to do.

Once you've found the right email address for the provider, sending the message is pretty simple using mail. As an alternative, they recommend a service like TextMagic to send the messages. It's a bit more reliable and uses SMS instead of email to get your message out.

For the Symfony2 users out there, Dean Clatworthy has a handy tip to help you customize the output of your application a bit more - a method for styling the error messages coming from forms using a custom template.

I spent a large portion of my day today trying to customize the HTML produced by Symfony 2 for form errors. The documentation has a section on how to do this, but for the life of me, I could not make it work. Here is a working, re-usable solution.

His solution involves the creation of a template in your "/Resources/views/Form/" directory that contains a Twig template for the error set output. This is then applied in your view using an additional parameter on the error output tag, including this new template from the "Form" directory. This sort of styling could also be applied if you needed custom elements with their own layouts in your forms as well.

On PHPMaster.com today they've posted a new tutorial that helps you get started adding queuing to your application with PHP and RabbitMQ.

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.

On the Nerdery blog today there's a new post about the recent Minnesota PHP User Group's latest meeting where the topics were "When SQL Meets Developers" and "Message Queues & Distributed Job Processing".

In their May meeting, the Minnesota PHP User Group heard two talks on "When SQL Meets Documents" [above] and "Message Queues & Distributed Job Processing" [below]. MNPHP meets once a month at The Nerdery's office in Bloomington.

Both of the presentations were recorded - you can find the videos over on Vimeo: SQL Meets Developers and Message Queues.

Court Ewing has a new post to his blog describing some of the most common cryptic errors that you might come across in your day-to-day development.

If you've been programming for awhile, then you've probably experienced your fair share of cryptic error messages. It's understandable that building in detailed error messages that are clear to even novice developers is not always a high priority for programming languages when there are so many other features to create and issues to address. The PHP language has decent error messages, but it is by no means an exception to this rule.

The three errors he covers are probably familiar to anyone that's been working with PHP for any length of time:

• Fatal error: Parse error: syntax error, unexpected T_PAAMAYIM_NEKUDOTAYIM
• Fatal error: Can't use function return value in write context
• Fatal error: Exception thrown without a stack frame in Unknown on line 0

Artur Ejsmont has a new post sharing some benchmarks he put together about the "messages per second" and "time to execute" when using PHP to pull from various messaging backends.

I have looked at the state of different messaging backends recently and i ran a little benchmark to see what is the rough comparison of message publishing throughput. Results that i got are quite surprising. What i wanted to achieve is some sort of reassurance before choosing a messaging bus for my PHP project.

Running both the PHP and the messaging test scripts on the same server, he pulled from a few different backend systems - RabbitMQ, MySQL, MongoDb, Memcached and ActiveMQ. The results were interesting, showing an interesting result in the time it took to execute versus the number of messages per second pushed in.

Mfana Ronald Conco has posted the second part of his RabbitMQ and PHP series to his blog today. This time he looks at durable queues and persistent messages

You now have a queuing system that works and generates pdfs which are sent to users as per RabbitMQ and PHP Part 1 of this article. A week later after launching the queuing system you get one or two queries from users who claim to have made a request to get the pdf report but it never arrived. Okay, what could have happened ? well you go through the application log files and as suspected - An Exception was thrown by one your classes as the consumer was trying to create the pdf and that is why it was never sent. Now this compromises the queuing system Totally, But wait there is a way to help prevent such.

He shows how to make your queues "durable", meaning they'll survive a broker restart and they require a response from the consumer before being removed. He shows how (via the php-ampq functionality) to add the "AMPQ_DURABLE" flag to the queue definition. He also includes some code showing how to send back the acknowledgement so the entry can be removed from the queue. He also includes an update to the code that calls "publish" to make the messages persistent too.

On PHPMaster.com today there's a new article introducing you to the Command design pattern and looking to help you understand its use a bit better.

The majority of [cell phone] users have opted to receive an email, but a significant number are now opting to receive the notifications via SMS. Here's the problem: How do you send a message via two different channels to both groups of users? The logical approach would be to split the users into 2 groups, email recipients and SMS recipients, which would involve running 2 different queries and sending the codeword to each group separately. Using the Command Pattern, which I will introduce you to in this article, you can send the message to both groups of users in a single process.

He uses the message queue he mentioned as an example - showing how you can can queue up different kinds of objects (actions) based on a common interface into the same process. He creates a "DailyAlertEmail" and "DailyAlertSMS" classes, both with a "send" method. The settings for these are then pulled from a database and the "execute" method on the "MessageQueue" class is called to loop through them, calling "send" to do that work.