In this recent post to his site, Anthony Ferrara takes an the phrase "reinventing the wheel" and wonders if, maybe, it's not such a bad thing sometimes.

"Don't Reinvent The Wheel" is a phrase that we hear used all the time in software development. Usually it's used in the context where a library exists to do what the user wants, but they are writing their own. While the sentiment is usually correct, I can't stand the implication of the phrase. Therefore, I can't stand it when people use that phrase without understanding what it really means. Let me explain...

He notes that, while there might be things out there that do something well, it doesn't mean that the "wheel is perfect" and you shouldn't venture out and try something new. He points out two places where it could be good - when a general solution doesn't work and for education/research.

Even as a senior developer, if you never try to reinvent the wheel from time to time, you'll never push your capabilities. You'll never expand your conceptual model of problems. And if you never do that, the world will blow past you.

In his most recent post Anthony Ferrara takes a look at autoloading - mostly asking the question of whether the problems it has really outweigh the benefits.

The real problem that autoloaders solve is to load dependencies. [...] The normal logic that's used to justify autoloading over manual dependency loading in production is that it only loads the classes you need. Therefore you save the parsing costs of classes that you don't need. But surely that additional run-time loading has costs. So I decided to setup a test to see how expensive that additional run-time loading costs us, and to prove whether or not autoloading is worth it in production.

He gives an example of the two methods - using the spl_autoload_register method to define a loader and loading them with a defined file path instead. He found the autoloading version slower than the hard-coded (by quite a bit) but how, when the number of files is reduced, the performance gets much closer. He also briefly looks at two other pieces of file-related functionality: file_exists and require_once.

Lukas Smith is looking for feedback about a question that's been in his mind a lot lately - can the handling of query parameters be made better for the Symfony2 framework (and even easier to use).

Obviously you can already access query parameters today already but it could be easier. Essentially what I want is a way for developers to easily configure what query parameters they expect and what values they expect. This is useful for several things like easier reading and validating of query parameters, self documenting API both for API docs for humans but also for machines.

He's asking for feedback and ideas from the community on a proposed solution that could make things more flexible. He also briefly mentions the route matching and how qurey parameters could cause them not to match:

For one I don't think that a mismatch on a route requirement of a query parameter cause the route to not match. However then it can quickly become confusing for the end user or it would require adding more and more syntax to handle all the different cases.

PHPClasses.org has posted the latest episode of their "Lately In PHP" podcast series, a look at the cloud hosting PHPFog now offers including an interview with Lucas Carlson, CEO of PHPFog.

On the Lately in PHP podcast episode 13, Manuel Lemos and Ernani Joppert interview Lucas Carlson, founder and CEO of PHPFog, to tell us about the advantages of using a Cloud Hosting service that is optimized to address needs that are specific to PHP Web sites and applications. They also comment on the PHP 5.3.6 forked version released by Robert Eisele and the PHP features being voted for inclusion in version 5.4.

You can listen to this latest episode in a few different ways - either via the in-page player, by downloading the mp3 or by subscribing to their feed.

Cal Evans has posted his third tip for clients wanting to have a better relationship with the developers on their project. This new tip talks about the balance between suggestions and "being sold" on technologies.

To balance Point 2, make sure your developer fully understands the problem and has put thought into it before actually proposing a solution. If, in the first meeting they propose a solution, especially a pre-packaged solution like WordPress, Joomla or Drupal, exit the building in a calm and orderly manner. In these cases they are selling you the solution they know, not the solution you need.

He suggests that you tread carefully when it comes to software choices and don't blindly follow the suggestions handed to you. A little research is all it takes to see if their proposal is actually a good fit. Ask a lot of questions and really think about the answers before moving on.

In a recent post to his blog Chris Hartjes has written about his (mis)adventures with Zend_Form, a powerful but sometimes difficult to use component of the Zend Framework.

Zend_Form is a super-powerful, force-of-nature tool. By force-of-nature I mean it does all this crazy stuff, and you can see it doing it, but I am not alone in admitting that taming it sometimes is very difficult. When building tools to make form programatically you either severely limit peoples options or make it so flexible that there are multiple ways to get something done.

Because the Zend Framework "treats you like an adult" it can be difficult to get just what you want from it (ease of use isn't quite top of the list). In this case, Chris wanted a relatively simple form that did some checking before it successfully submitted. Over and over the form passed without him being able to tell why - the solution was a pretty simple one, though - be sure to create all form elements before you do validation.

He includes some same code - a "before" and "after" for the solution.

Rob Allen had a problem - he needed to get the "pound" (as in the British monetary unit) into his MySQL database. His database didn't seem to want to comply:

Everyone else probably already knows this stuff, but I hit an issue today to that took a while to sort out. Fortunately, some kind folks on IRC helped me, but as it's embarrassing to ask for help on the same issue twice, I'm writing down what I've learned! The problem: Get a £ character stored to MySQL, retrieved and then displayed without any weird characters in front of it using UTF8.

His solution? Make sure you're using UTF-8 everywhere, not just when trying to insert into the database - in the broser's headers (both going in and coming out) and in the MySQL database insert. He gives code examples for each including database examples for PDO and the Zend_Db component of the Zend Framework.

Following up on a previous article, Stuart Herbert has posted some of the things that PHP can do to help solve the previously mentioned shared hosting problems.

The challenge is to secure the box not just from outside attack (something you have to do anyway, and which I'll cover later in this series), but also to make sure that code running on one website can't steal confidential data like MySQL passwords from any of the other websites.

It's not just a problem that PHP has, but it does, thankfully, have several settings and things that you can do to help. Among those on the list are things like: safe_mode, open_basedir and how PHP 6 will effect both of these. He's included settings for both of them to get you started.

One of the biggest problems facing PHP web hosting companies is the big move to PHP5 that that end-of-life announcement. Arnold Daniels has one idea for a solution to help ease the problems - providing customers with a testing environment they can try out their code in.

A few months ago I've posted an article about running multiple Apache instances with different PHP versions. In that article I showed how to make multiple configurations running Apache on different IP addresses. By using different ports instead of different IP addresses, we can give our customers a way to check their site before it goes live.

He modifies the settings in that tutorial with a few updates he includes to make two different apache configurations - one for PHP4 and the other for PHP5. When used together, they can run two different PHP versions on the same code, just on different ports.

With the introduction of the ViewRenderer component into the Zend Framework has come all sorts of troubles for all sorts of developers. Thankfully, there's posts like this one from Pádraic Brady that helps out with some of the more common issues people are seeing (a problem/solution approach).

The ViewRenderer "action helper" is the class Zend_Controller_Action_Helper_ViewRenderer. It's primary purpose is to facilitate the automated rendering of View scripts (templates) based on the generally accepted Zend Framework conventions. It's these conventions which will cause a lot of people grief, since the previous reliance on programmers defining the template to render has likely led to inconsistent template names.

Included in the post is a list of some of the common issues developers have including "ViewRenderer is enabled by default", "Inconsistent location of template files" and "Reusing template files across Controller actions". For each, he's included a "quick hit" solution to get you back on the straight and narrow road to having a nicely working Zend Framework application.