The SitePoint PHP blog has a new post looking at using message queues in PHP. More specifically it compares a few of the different solutions out there and their advantages/disadvantages - Beanstalkd, IronMQ and the Amazon SQS.

This article introduces the concept of message queues and discusses the strengths and weaknesses of three specific message queue services: Beanstalkd, IronMQ and Amazon SQS. [...] Queues allow you to store metadata for processing jobs at a later date. They can aid in the development of SOA (service-oriented architecture) by providing the flexibility to defer tasks to separate processes. When applied correctly, queues can dramatically increase the user experience of a web site by reducing load times.

He starts with some of the overall benefits and downfalls of using a queueing system in your application, including some common use cases. From their he breaks it up into sections, in each talking about the option and how it differs from the others:

• Services
• Server setup
• Service Level Agreements (SLAs)
• Architecture
• Client libraries
• Management interface
• Redundancy
• Security
• Speed
• Fidelity
• One-time pickup

...and many, many more. If you're looking for a good, complete overview of how these three options compare on a wide range of features and configurations, definitely check out this post. It even includes some PHP close to the end to make the connections to each and send/receive messages.

On SitePoint.com there's an interesting opinion piece on one of the bigger debates in the web development world - should designers know how to write code, even if it's just a little?

This debate has been raging on SitePoint for some time. The issue was raised by Elliot Jay Stocks following a simple tweet: "Honestly, I’m shocked that in 2010 I’m still coming across ‘web designers’ who can’t code their own designs. No excuse."

This, of course, sparked a whole host of other opinions from the SitePoint readers and they've gathered them together and summarized the "for" and "against" topics from there. Those on the pro-coding side suggest that not only does it give them some appreciation for what the developers do for the designers but it also can make them a better, more flexible asset down the line. The those on the con-coding side suggest that designer time is precious and should be devoted to the usability of the site. They also note that you don't "need to be a plumber" to know how to get a working site together - each member needs to do their job.

Be sure to check out the comments for some other great thoughts from the community.

In a new post Juozas Kaziukenas takes a look at reasons he thinks you should (or shouldn't?) use the Zend Framework for your next application.

This is not a comparison of frameworks though, because I don’t feel like having enough experiences with other frameworks to make a fare comparison, that’s why this is going to be only a Zend Framework analysis.

He starts with some of his history with the Zend Framework so you'll know where he's coming from. He also lists out some of the advantages of the framework - it's customizable nature, the quality of the code, the large user community - and some of the disadvantages like it being hard to learn, that it's too loosely coupled and the fact that some components have fallen by the wayside and aren't really being maintained.

In this new post to his blog Mike Willbanks talks about some of the reasons he's found (including a few bad ones) to use or not use the Zend Server (Community Edition) for your application.

At work, we were looking to see where we were going as far as future PHP versions and maintaining our production environments it was appealing to see the Zend Server offering. After receiving the email about the public beta, I decided to give this a test spin and the results of which was taken with high regard.

Mike looks at some of the advantages the software offers - including the Zend Control Panel and extensions offered - and a few disadvantages - like the location of the Apache configuration files and the age of some of the extensions included. He also briefly looks at the Zend Control Panel and the features it offers.

Richard Heyes has shared an epiphany he's come up with - a method for running scripts in a web-based environment using lynx.

OK maybe not to you, but it has just occurred to me, and things don't come to me all that fast these days. Cron jobs. [...] You can have a directory inside your webroot called "cron" (imaginative eh?) with scripts in there that are run via cron.

His method uses the cron daemon on the machine to invoke lynx and call the web page through its url. Of course, there are advantages and disadvantages of the method (including having the script open to the world - scary). Be sure to check out the comments for other suggestions from fellow developers.

Richard Heyes has shared an epiphany he's come up with - a method for running scripts in a web-based environment using lynx.

OK maybe not to you, but it has just occurred to me, and things don't come to me all that fast these days. Cron jobs. [...] You can have a directory inside your webroot called "cron" (imaginative eh?) with scripts in there that are run via cron.

His method uses the cron daemon on the machine to invoke lynx and call the web page through its url. Of course, there are advantages and disadvantages of the method (including having the script open to the world - scary). Be sure to check out the comments for other suggestions from fellow developers.

In a post from Nick Halstead on the Programming and Management Blog, he discusses something just about every developer is familiar with - pseudo code.

Writing pseudo code and program code separately simplifies the overall task by splitting it into two simpler tasks. While writing the algorithm the developer can focus on solving the problem, not how it is written in a a particular language. Once the pseudo code is written and has been checked; writing the real code becomes much simpler, the programmer is only concerned with converting the pseudo code into the appropriate program code.

Nick looks at both sides of its use and includes the good (doesn't take language-specific understanding) and the bad (could hide logic flaws that could be tragic later). He also includes a quick overview of how to write it, making sure to keep things high level and all about the structure.

In a post from Nick Halstead on the Programming and Management Blog, he discusses something just about every developer is familiar with - pseudo code.

Writing pseudo code and program code separately simplifies the overall task by splitting it into two simpler tasks. While writing the algorithm the developer can focus on solving the problem, not how it is written in a a particular language. Once the pseudo code is written and has been checked; writing the real code becomes much simpler, the programmer is only concerned with converting the pseudo code into the appropriate program code.

Nick looks at both sides of its use and includes the good (doesn't take language-specific understanding) and the bad (could hide logic flaws that could be tragic later). He also includes a quick overview of how to write it, making sure to keep things high level and all about the structure.

In a new post to his "Quaint Tech" blog, Paul van Iterson talks about why you want (to use) object-oriented programming in your PHP applications versus the more procedural methods.

Most modern programming languages are based on an OO approach and don't even allow for procedural coding anymore (for instance in languages as Java, C++, C#, Python, and Ruby). Explaining OOP goes beyond the scope of this article, so for understanding OOP in PHP I'd like to point you in this direction. For now let's just say that OOP is about creating relatively small objects with specific functions that interact with each other to form a complete application.

Right off, he lists two advantages to using OOP methods (reusability and better structure) and a disadvantage (can be more time consuming to write). He does still recommend it though to any "serious PHP developer taking on serious projects". He illustrates the point with some of his own experience - an application for a real estate firm.

In a new post to his "Quaint Tech" blog, Paul van Iterson talks about why you want (to use) object-oriented programming in your PHP applications versus the more procedural methods.

Most modern programming languages are based on an OO approach and don't even allow for procedural coding anymore (for instance in languages as Java, C++, C#, Python, and Ruby). Explaining OOP goes beyond the scope of this article, so for understanding OOP in PHP I'd like to point you in this direction. For now let's just say that OOP is about creating relatively small objects with specific functions that interact with each other to form a complete application.

Right off, he lists two advantages to using OOP methods (reusability and better structure) and a disadvantage (can be more time consuming to write). He does still recommend it though to any "serious PHP developer taking on serious projects". He illustrates the point with some of his own experience - an application for a real estate firm.