Paul Reinheimer has a recent post to his blog talking about the danger of "hooks" in your development - the functionality several frameworks and other tools come with to allow you to add functionality to the core without having to change the main source.

I ran into hooks rather simultaneously with two very different frameworks: Code Igniter and Lithium. In both cases I was using a rather nifty hook to handle ensuring that users were properly authenticated and authorized before accessing a page. [...] One day, while messing around, I accidentally turned off the hook configuration within Code Igniter (actually I clobbered a file, and restored the wrong one). Then, things came crashing down in a horrible cacophony of... actually they didn't. Everything kept working: that was the problem.

He shows two solutions he came up with to be sure that his hooks were executed - one for Lithium and the other for CodeIgniter. The Lithium one uses a "_remap" method and the CodeIgniter example uses the magic "__invoke" method to check for an "AUTH_CHECKED" constant that's only defined as a part of his hooks.

I'm no longer entirely dependent on one configuration option or file for my security to function. Should it fail, I've got a secondary check in place; this example of defence in depth allows me to be comfortable with the hooks security system once more.

On the php|architect site today there's an opinion piece from Marco Tabini with his thoughts on why software fails - not why the project itself fails, but why the software fails to be useful.

This is a much more common problem than engineers and architects are willing to admit. Far too often I see someone in charge of writing a piece software worry about how a product works without paying so much as a passing thought to whether it actually works the way people expect it to. The truth is that we are, by and large, stuck in a reality where software somehow equates with automation.

He goes on to talk about how easy it is for us, as developers, to forge head with features and software that may not be useful to the masses. We worry more about solving a problem that may or may not actually be there. He illustrates with the example of a to-do list, providing the automation to make list tracking easier, but no guidance of how the user can make use of it effectively.

Håvard Eide has a new post sharing a tool he's created (based on some ideas presented in this netflix blog post) for testing a web service. Specifically, his tool helps you test a web service developed with the Slim framework.

I just pushed a example on how to create a Slim framework to github. The idea is that whenever you create a webservice with the Slim framework (which is really simple) you rarely test for failure, the ChaosMonkey class will help you to do just that. When initialized with the AbsoluteChaos plugin it will randomly kill the webservice with exceptions, garbage to the output, or just run the service for you without failure at all.

His plugin does a lot of things right now, but it's easy to extend with your own failure types - like his suggested "networkSleep" or something that could kill the connection to MySQL. He includes a code snippet in the post of how to hook Slim and ChaosMonkey together for some testing fun.

On IT World there's an interesting article about the programming skills that seem to be lost in today's coders and how what they may not know might hurt them in the end.

Some of these skills aren't likely to be needed again, any more than most of us need to know how to ride a horse or (sigh) drive a manual-transmission vehicle. But other skills and "lessons learned" may still or again prove relevant, whether developers are banging their heads against legacy systems, coding for new mobile and embedded devices... or other devices and applications we haven't yet thought of. [...] Here's what some industry veterans and seasoned coders think the younger generation doesn't know ... but should.

He's broken it up into a few different sections - one dealing with the lack of general hardware knowledge by a good section of the today's developers, another noting that programming is not the same as software engineering (yes, really). He also touches on the lacking idea of "thinking before coding" and how planning for errors has become less and less of an importance.

Slawek Lukasiewicz has a helpful hint posted to his blog today about handling type hinting failures in a what he sees as a "more correct" way than just throwing an error - throwing an exception when the hinting criteria's not met.

One of the most annoying behavior of PHP type hinting feature is triggering error instead of throwing exception when instance type is invalid.

By default, a failure generates a "catchable error" that, thanks to the custom error handling methods PHP includes, can be correctly handled. He includes a snippet of code that defines the errorHandler method that checks the error type for E_RECOVERABLE_ERROR and throws the exception (an ErrorException) if found.

Andrew Johnstone came across an interesting problem when he tried to use memcached multigets with a large number of keys - it was throwing failures, but only when he tried it on Ubuntu.

I Spent a little while yesterday investigating why memcached causes problems with multigets returning results and ended up comparing debian vs ubuntu. [...] A larger number of keys than 200 causes memcached to fail to return valid responses, additionally the key length greatly varies the number items you can pull back within a single multiget on Ubuntu, Debian implementation of memcached is able to handle all requests regardless of key length size.

He includes the code for his brief test and the output of the test runs on both Ubuntu and Debian systems. They clearly show the failures on the Ubunut side, with it throwing errors about "memcached_oi_read" and a zero length value returned to recv().

Cal Evans has a reminder to all of the businesses out there that have sites and use web site hosting services - only you can prevent web failures and potentially alienate customers.

Last night I wrote the info@ email address on a website and asked a questions about their product. They politely responded with two links to their website. This morning however, when I went to visit them, I was greeted with the message above. It's now three hours later and the site is still "experiencing difficulties". [...] This problem can be prevented by business owners insisting on - and paying for - "Best Practices" in their software vendors.

He offers a few suggestions to businesses to help prevent this sort of (catastrophic?) failure for their businesses including having a rollout and rollback plan and having a good set of tests to make doubly sure things work before the code even meets the public.

In this new post to his blog Keith Casey looks at a metric he considers a true failure at measuring the success of a piece of software - lines of code.

While the obvious implication of the article is that organizations are not properly equipped/trained/prepared to tackle these large software development projects and therefore eventually fail. Especially early in my career, I tried to tackle problems and ideas that simply weren't reasonable or were considered ridiculously complex and far beyond my skills. This is a common problem on software development teams with little real-world experience or hubris in their own skills or both...

He doesn't see the Lines of Code (LOC) metric as particularly useful and backs it up with a few reasons including the overwhelming complexity of large codebases, duplication in functionality from place to place and the amount of "cruft" code that can accumulate in older, less used parts of the code.

On the DevBots blog recently Darby Felton posted a few suggestions of things that could be done to help improve IT organizations from the inside and promote a more healthy environment for everyone involved.

Lately I have been thinking about a few aspects of the information technology industry. Particularly, regarding software development, I am concerned that the following characteristics remain pervasive and detrimental to our industry: far too many software development projects ultimately fail, we tend to lack clear, rigorous standards and credentials that other industries typically employ, and our [lack of] adherence to ethics and professional conduct leaves much to be desired.

He addresses each of these, pointing out that a good number of IT environments have fallen into these issues and steps need to be taken to: reduce the failure rate of projects, hone down the staff to those that will turn out the best possible product and will uphold a good set of standards/ethics while they do.

DevShed continues their look at custom exception handling in PHP5 application with this third part of their series, a look at handling exceptions from MySQL calls.

Having already introduced you to the main subject of this article series, it's time to summarize the topics that were discussed in the last article, in case you haven't read it yet. In that particular tutorial I explained how to implement a fully-functional customized exception system with PHP 5, which came in handy for handling a number of specific exceptions thrown by a basic MySQL abstraction class.

They create a custom MySQL exception class that sits on top of their MySQL abstraction layer (and Result handling class) and catches exceptions thrown from sample queries.