The latest episode of the /Dev/Hell Podcast has been released - Episode 19: Pull Requests Welcome:

This week on /dev/hell is “let’s talk about arguments Chris got into on Twitter” week. Most of the discussion revolves around how we interact with users, both developer-types and average joes.

You can listen to this latest episode either via their in-page player, by grabbing the mp3 directly or by subscribing to their RSS feed.

As Nicolas Grekas shows in this tutorial (posted as a gist), the functionality that PHP gives users to work with the raw HTTP requests is pretty limited. There's a few solutions he offers, but none of them allow for the full use of the HTTP options provided by the server.

HP offers comprehensive autoglobals to access external data sent with each request. These variables do not expose all the possibilities allowed by the HTTP protocol, but a controlled use can in practice minimize the impact of this limitation. Two problems are particularly troublesome: the lack of access to multi-valued keys without using a special syntax and complexity of the magic bracketed syntax. Until PHP natively provides another interface freed from these problems, a different interface in user space can circumvent them.

He gives some code examples of methods that can be used to parse strings like those found in cookies (or pulled in via php://stdin) including mentions of key normalization and accessing the values by literal keys. You can see a more full implementation here.

On the blog at HackersCenter.com, there's a new post looking a a few simple ways to help optimize your PHP code. Sure, most of the everyday scripts developers write don't benefit a whole lot from shaving off those extra milliseconds in execution time, but it's always a good practice to get into when you get into those larger scripts.

The author follows this up with a few more stats before getting on with the heart of the article - the tips and tricks. They demonstrate a sample function to help test the speed of the script before looking at different topics of optimization - outputting an array, regular expressions, using references, and file inclusion. For each, there's a "slow way" and a "fast way" - I wonder which is the better choice...

On the blog at HackersCenter.com, there's a new post looking a a few simple ways to help optimize your PHP code. Sure, most of the everyday scripts developers write don't benefit a whole lot from shaving off those extra milliseconds in execution time, but it's always a good practice to get into when you get into those larger scripts.

The author follows this up with a few more stats before getting on with the heart of the article - the tips and tricks. They demonstrate a sample function to help test the speed of the script before looking at different topics of optimization - outputting an array, regular expressions, using references, and file inclusion. For each, there's a "slow way" and a "fast way" - I wonder which is the better choice...

In a light-hearted new post on his blog today, Helgi shares a good response for some of those out there that have had to deal with stupid feature requests.

Who hasn't gotten a utterly stupid feature request before ? Or even a request that you constantly say no to. This is just bound to happen if you help maintain a open source project (probably even more so in a commerical entity)

Well I have found the perfect answer to such requests with the courtesy of the yum wiki: "No. Just no. If you don't like it, go have a conversation with yourself about it. Alone. At home. In your closet."

I've even been pondering about adding this as an answering option in pear/pecl/php bug system, I can just see Jani doing the happy dance if this kind of thing would ever be added.

Of course, we've all been there - even those new to the programming world. There will always be those people that come into the meetings and propose something that sounds like a good idea to them, but just doesn't add any value to the project. Of course now, you have something say...

In a light-hearted new post on his blog today, Helgi shares a good response for some of those out there that have had to deal with stupid feature requests.

Who hasn't gotten a utterly stupid feature request before ? Or even a request that you constantly say no to. This is just bound to happen if you help maintain a open source project (probably even more so in a commerical entity)

Well I have found the perfect answer to such requests with the courtesy of the yum wiki: "No. Just no. If you don't like it, go have a conversation with yourself about it. Alone. At home. In your closet."

I've even been pondering about adding this as an answering option in pear/pecl/php bug system, I can just see Jani doing the happy dance if this kind of thing would ever be added.

Of course, we've all been there - even those new to the programming world. There will always be those people that come into the meetings and propose something that sounds like a good idea to them, but just doesn't add any value to the project. Of course now, you have something say...