On his CodeUptopia blog Jani Hartikainen has posted a great article with some of his thoughts about why fixing bugs is so slow and includes a few suggestions on how to make it happen faster and streamline the process for the future.

Have you ever wondered why sometimes fixing bugs seems to take much longer than it should? When you finally find the problem, it turns out all you need is one small change. Yet, it took a lot of time to find what’s going on. This happens to me more often than I’d like.

[...] Why is it that sometimes fixing bugs takes a lot of work even when the problem is simple, and other times, it’s really quick to fix the problem – maybe even when it isn’t so trivial? Is there something we can learn from the bugs that are easy to fix, so that we could spend less time fixing bugs in general?

He starts off by describing a typical bug fixing process after the initial discovery and reporting of the issue down to the actual fix being deployed. He then breaks down each of these six steps and provides more context around them:

• Understanding the problem
• Reproducing the bug
• Finding the problematic piece of code
• Identifying the root cause
• Fixing the bug
• Ensuring the bug is fixed

He then goes back and talks about the pain points in this typical process citing things like a lack of good information around the bug and the time constraints that often come with the "time to fix" allowance. He makes some suggestions about how to gather better information around the issue before the fix begins and points to effective logging as one possible source. He also talks about how unit testing can help verify the bug is actually fixed and help to prevent and locate future issues.

As a follow-up to his previous article about the (minimal) overhead from logging, Kevin Schroeder has this new post focusing on the common belief that writing to the file system is the slowest method.

I had a conversation the other day by a person I respect (I respect any PHP developer who knows how to use strace) about the cost of file IO. My assertion has been, and has been for a long time, that file IO is not the boogeyman that it is claimed to be. So I decided to test a cross between those two posts.

His test was to write one million log records to two different sources - the normal physical file system, a RAM drive - one run with a file handle that's left open and the other with a new handle each time. He shows how he made the RAM drive and the PHP he used for the test (running in a VM). He graphs out the results with some interesting results...but you'll have to read the post for that.

In this new post Joseph Scott takes a look at hashing in PHP, specifically around md5 hashes, and a better alternative (that's also more secure.

The majority of the Coding Horror: Speed Hashing post talks about speed based on MD5. [...] If you are still using MD5 to hash passwords (or worse, aren’t hashing passwords at all) then please stop and go use bcrypt. For those using PHP phpass is a great option.

He talks about the crypt method, how its encryption method and "cost" value effects the speed and how difficult it would be to generate all possible hashes for a password (hint: crypt with a cost of 13 is worlds better than md5).

Derick Rethans has posted just a few of the reasons why the "shut-up operator" (the @ symbol) should be avoided at all costs in your PHP applications.

The @-operator is often used to silence errors in noisy PHP functions—functions that generate warnings that can not be easily prevented. [...] In those cases, there is no way how to check up-front whether the function call will not issue a warning when being called.

There are side effects to using the operator, however, including hiding legitimate errors and making debugging that much more difficult. To back up his point, he includes four other reasons to avoid the operator's use (besides the debugging issues):

• It's slow (part 1)
• It's slow (part 2)
• It's slow (part 3: It generates crappier code)
• Apfelstrudels were harmed (related to the strudel_token in the C code for the operator)

Tobias Schlitt has, for a personal project, put together a comparison of caching with two different web servers he's building applications with - Apache and Lighttpd.

For a little private project, which makes extensive use of caching, I recently checked, where I could get gather some more performance from.

He had been pointed towards Lighttpd by Kore (who recommended it based on his experience with it). So, Tobias tested the application on both of the two servers with somewhat predictable results (see image). Apache was slower in most cases and quite a bit slower when it came to working with larger files.

Tobias Schlitt has, for a personal project, put together a comparison of caching with two different web servers he's building applications with - Apache and Lighttpd.

For a little private project, which makes extensive use of caching, I recently checked, where I could get gather some more performance from.

He had been pointed towards Lighttpd by Kore (who recommended it based on his experience with it). So, Tobias tested the application on both of the two servers with somewhat predictable results (see image). Apache was slower in most cases and quite a bit slower when it came to working with larger files.

Everyone that knows of the social news site Digg.com knows the problems that being linked on it can cause. Smaller servers get overloaded and pages can either be very slow loading or completely offline within minutes of being "digged". There's a few out there that have come up with different solutions, but several of them involve mirroring the content somewhere else. In this proposal, however, they combine the power of Lightttpd and PHP to handle the loads.

We host a wide variety of sites, covering everything from converting your garage into a living space to video game addictions. Because we are such a small operation, being hit by a link from a big site such as Digg would be both a blessing and a curse.

In order to place our ads on each page, we use PHP's auto_append_file feature to run our advertisement code. By using PHP's other neato function, auto_prepend_file, I can create a small piece of PHP code to detect when the site is being hit by Digg. In this situation, I have chosen to use Lighttpd to handle the increased loads, because of its proven high performance with large numbers of concurrent connections.

In his example code, he shows how you can detect when a user is coming from a digg.com page and take them to a cached version of the page they've requested (with the .cache extension).

Everyone that knows of the social news site Digg.com knows the problems that being linked on it can cause. Smaller servers get overloaded and pages can either be very slow loading or completely offline within minutes of being "digged". There's a few out there that have come up with different solutions, but several of them involve mirroring the content somewhere else. In this proposal, however, they combine the power of Lightttpd and PHP to handle the loads.

We host a wide variety of sites, covering everything from converting your garage into a living space to video game addictions. Because we are such a small operation, being hit by a link from a big site such as Digg would be both a blessing and a curse.

In order to place our ads on each page, we use PHP's auto_append_file feature to run our advertisement code. By using PHP's other neato function, auto_prepend_file, I can create a small piece of PHP code to detect when the site is being hit by Digg. In this situation, I have chosen to use Lighttpd to handle the increased loads, because of its proven high performance with large numbers of concurrent connections.

In his example code, he shows how you can detect when a user is coming from a digg.com page and take them to a cached version of the page they've requested (with the .cache extension).

We all have software that we love, and we all have software that we hate. Sometimes, there's even a few times in there that there's software that we love to hate. Jim Plush has this kind of love-hate relationship with Zend Studio as expressed in this letter.

We've all been there and know this pain. It's good to see he's taking it in stride and is expressing it with such fine sarcasm too...

We all have software that we love, and we all have software that we hate. Sometimes, there's even a few times in there that there's software that we love to hate. Jim Plush has this kind of love-hate relationship with Zend Studio as expressed in this letter.

We've all been there and know this pain. It's good to see he's taking it in stride and is expressing it with such fine sarcasm too...