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.

Tom Schlick has a new post to his blog talking about a tool he's written for FuelPHP-based applications called Wrench. It's a command-line tool to make taking your site "offline" simpler.

If you have been following what I've been up to lately you would see that many of my recent projects are based on FuelPHP. Since Fuel is so awesome and allows you to create "packages" that can be dropped into your application, I have created a few that help me quickly piece together apps. The first package I'm "releasing" is called Wrench.

The tool works with the oil command-line tool already included in the framework to swap out the default action with a "Down for Maintenance" message. It will look at the current state of the app and switch it to the opposite when run, but you can also define "start" and "finish" manually if you'd like. You can find the source for the package on Tom's github account.

On ZendCasts.com today, the next part of their series looking at using the Slim microframework has been posted. This is part one of a tutorial building a JSON endpoint for a web service.

You'll need some of the base that he created in this previous screencast to follow along (the basic structure, really). His takes his basic "hello world" application and builds on it to add a "model" to pull name data from and has the "/names" action respond with a JSON-formatted message (and an "application/json" content-type). His "model" pulls the data out with findAll() and find() methods.

You can grab the source to follow along.

James Fuller has a new post to his blog today showing how to use flash messaging in the Lithium PHP framework.

In my case, I needed to display to the user a "flash message" after redirecting them to another page. CakePHP has this as part of the framework by default but Lithium will ask you to do a bit more work. Luckily, Lithium framework lead developer Nate Abele has created a handy extension to the Lithium session helper will will give us exactly what we need.

For those not familiar with what a "flash message" is, he defines it as a message available to the next page load with relevant information about the previous page. He includes the instructions on how to get the extension for this working in Lithium - downloading, configuring and adding the output variable for the flash messaging to your layout. He also includes an example of how to set the message so it'll be saved into the current session.

Continuing on in his Flex and PHP series Kevin Schroeder has a new post to his blog today looking at how to send typed ActionScript objects to Flex so he could pass PHP objects and their structure directly back to the waiting frontend.

What I wanted to do was use the sales notification mechanism to pass PHP objects to Flex using the message queue. But I could not get the unserialization mechanism to work and so I had to settle for passing a simple message that a sale had been made. However, because you can pass typed objects back and forth between PHP and ActionScript over HTTP using Zend_Amf_Server I figured that there MUST be a way of doing it automatically.

He walks you through the steps to discovery that eventually got him to his end goal - making a simple valueObject class to use for the connection, a basic PHP script (using Zend_Amf) to parse the object's data and a bit of code to send it back to the waiting MQ queue via a Zend_Queue adapter.

On NetTuts.com today there's a new tutorial showing you how to send text messages via SMS directly from your script to the user's cell phone.

Text messaging has become extremely widespread throughout the world - to the point where an increasing number of web applications have integrated SMS to notify users of events, sales or coupons directly through their mobile devices. In this tutorial, we will cover the fundamentals of sending text messages with PHP.

Their method "cheats" a little bit and uses an interface many of the cell phone providers offer to their subscribers - a link from an email address to SMS. Most providers have their domains you can send the email to and have it automatically forwarded to the user's cell as a text. Thankfully, this requires nothing more than the mail function to accomplish. They include the sample code and HTML+CSS to make a basic form as well as mention PHPMailer as a more powerful mailing alternative.