Communication is the only way you can tell if an application is feeling well or is about to fall apart. If your application can't talk to you, you have no way of helping it to feel better. The L in LUCID is for logging. Logs are how applications speak. They capture information that allows us to pick up on those little signs and act early enough to make sure the application doesn't come down with the flu. If you don't have good logging throughout your system, the best you can do is react to your application falling over. A silent application is an application destined to cause midnight surprises for you and your operations team.

He talks about the difference between "just logging" and "correct logging" as well as a recommendation for the different levels: trace, debug, info, warn and error.

Letting you know that something went wrong is really only half of a log messages job. The other responsibilities of a log message are to allow you to accurately reproduce the conditions under which the event occurred, and to allow you to fix any data inconsistencies.

Here are some bugfixing rules and tips I've learned working all these years with PHP. I emphasize mostly on fixing bugs than preventing them, which is another subject worth of its own article. I've moved to Rails, but I wanted to finish this post as a farewell and thanks to every article and documentation that was useful to me. Hope this is useful to you too.

Topics covered include:

• Assume nothing
• Turn Error Reporting to show all errors
• Read the error message
• Understand the bug
• "Scooby-Bug, where are you?"
• Get as much information as possible

As George put it in his email: "I am very excited to announce that Laura Thomson has been promoted to the position of Principal. " My role will include focusing on securing new business and improving the quality and effectiveness of service delivery.

Congratulations, Laura! Best of luck in this new position!