In this new post to his blog Marco Tabini eloquently explains something that less and less seem to be able to understand - the tool is only a means to an end. It's more about the artist and the end result than the tool.

What is beautiful code? Ask ten people, and you will probably get ten different answers. Ask them what makes a programming language beautiful, and you've got yourself the beginnings of a holy war.

He compares code to art - the language is just a tool, the canvas an editor waiting to be filled with lines of artist-generated works. Because of PHP's wonderful flexibility, it can be molded to fit just about any need a coder might see fit and gives them the power they need to really dig into the code and about the "paint by numbers" sort fo things language like Ruby have to offer.

On his blog recently Felix De Vliegher has posted about work he's done to gather some stats and great some data about how his PHP scripts are working based on a little statistical analysis.

Lately I've been interested in applying static analysis to PHP projects. Static analysis is the process of analysing software code - in our case PHP source code -, without actually executing the (compiled) result of the source code you're analysing.

He mentions some types of analysis and some of the tools that can be used to measure it. He also talks about issues it can help with (like the potential for harm if a part of code is changed) and a pointer to the Pixy software he used to generate the statistics (and images like this).

On the ProDevTips blog, Henrik shows an example of the "perfect combination" of PHP's json functionality and a powerful javascript library, jQuery.

Today I looked for a replacement for my old jspanserializer.js script that I can't even remember where I found anymore. Turns out that I wont have to either, I can forget it. From now on I'll use jQuery JSON instead.

A code example is included to show the simplicity.

William Candillon passed along a note about a new PECL extension that's been released that adds the power of XQuery to the PHP world.

PHP developers beware: Zorba now has a language binding for PHP 5! Most PHP developments have to deal with XML and since PHP version 5, the support for XML has been greatly improved and developers can use various extensions that speak XML. We strongly believe that XQuery was the missing piece in this set of tools and therefore we are very excited by this release.

You can get the full details from this post to his blog including installation instructions and usage examples for everything from a simple query to a more complex XML insertion.

Rochak Chauhan has come up with a list of ten things, some security problems that could be lurking in your applications waiting to pop up at the worst time. Here's his list:

• Unvalidated Parameters
• Broken Access Control
• Broken Account and Session Management
• Cross-Site Scripting (XSS) Flaws
• Buffer Overflows
• Command Injection Flaws
• Error Handling Problems
• Insecure Use of Cryptography
• Remote Administration Flaws
• Web and Application Server Misconfiguration

Each item on the list has a bit of detail (and sometimes some code) to help point out the problem. Some of them even have references to external sources and packages to help you solve the problems.

Kae Verans has written up a handy snippet of code to try to mimic the innerHTML property that Javascript lets you have access to.

DOM does not officially have an innerHTML parameter, but it's incredibly useful. I found a need for something similar when working on some DOM stuff, so had to write a version.

Technically it's an "outerHTML" not inner, but it works about the same. The code and an example of its use is included.

Brian DeShong has posted some of his "food for thought" on the development process that's behind the scenes of different PHP applications.

Lately I've been doing a lot of thinking on development processes and quality, specifically for large-scale, professional PHP-based projects. [...] Generally speaking, my perception is that software development shops that really care about and emphasize quality have processes that consist of things such as writing use cases, unit testing and continuous integration.

He knows how he feels about all of this, be he wants to hear back from the community. How far does quality assurance go in your group? What kind of time/funding does this involve? Leave him a comment and let him know...

Rob Allen has posted a few notes about the Zend_Cache component of the Zend Framework to his blog today.

Recently I needed to speed up a legacy project that makes a lot of database calls to generate each page. After profiling, I discovered that 90% of the database calls returned data that rarely changed, so decided to cache these calls. One of the nice things about Zend_Framework is that its use-at-will philosophy means that you can use any given component with minimal dependencies on the rest of the framework code.

He shows how, using the Zend_Cache module (and friends Zend_Loader and Zend_Exception), he creates a caching class that can be called anywhere and is used to cache the results from the queries. His default lifetime is set to 7200 seconds - two hours - before the script needs to refresh the cache and get the latest updates.

On php|architect's C7Y community site Scott MacVicar has posted a new comparison of two of the main graphics platforms available to PHP - the GD and Imagick extensions.

If you want user interaction on your website then you probably accept the upload of some media, including images. Within PHP there are two different libraries available that provide functionality for handling images, GD and the Imagick extension. This article takes a brief look at each of these libraries.

Since GD comes bundled with PHP these days, he gives a brief installation tutorial for the Imagick extension. After that he compares the two with code for three different bits of functionality - identifying image types, working with EXIF data and modifying a current image (change format/resize).

According to Felix Geisendorfer's newest post on the Debuggable blog, he thinks that "private and protected methods and properties are one of the most stupid concepts of OOP."

This is a thought I first shared at CakeFest Orlando this year, but could not explain properly at the time.

He illustrates with an example of a protected "balance" variable in a BankAccount class. Sure, it's marked as private but less skilled programmers might not use it that way. He recommends a method without the getters/setters to help make the usage of the variable a bit simpler. He also suggests that using protected/private scoping helps to promote "crappy code" - using them to provide a sort of protection for code that you either don't want getting used or hiding it away so the API can't get at it.