On the Laravel News site there's a tutorial posted that makes some suggestions about how to anticipate application failures by using effective unit testing.

When you start working on a new feature, it is wise to plan out not only how it is expected to work, but what happens if something fails. Taking the time up front to anticipate failure is a quality of a great developer.

[...] Since we don’t know when a dependency might fail, it’s best to plan for failure by having tests so we can be more confident in failed states. Laravel can help us write tests that plan for failure using real-time facades.

In their example, they create a simple "article" repository class that makes use of a HTTP client to fetch the information for each article (by ID). In this case the client is Guzzle. They then add a singleton to the configuration to fetch the API class and show how to implement it in a controller. With this structure, they then move on to testing for failure via real-time facades and mocking a Guzzle response using a "Client" facade instead of calling it directly.

In a new post to his site Brian Moon has shared a problem he had with sockets and timeouts and having them perform the same way every time. He walks through the symptoms he was seeing and provides his own solution in the end.

So, it seems that when you try and connect to an IP that is routable on the network, but not answering, the TCP stack has some built in timeouts that are not obvious. This differs from trying to connect to an IP address that is up, but not listening on a given port. [...] After a lot of messing around, a coworker pointed out that in production, the failures were happening for an IP that was routable on the network, but that had no host listening on the IP.

After some testing, Brian figured out that his problem was using localhost for testing and not an actual non-host server. He made the switch and figured out how to set the timeouts low and work with error state checking to make things more stable. He explains a bit more about how the code in his solution works. You can find his solution in this gist on GitHub.

The Qandidate.com blog has a new post today looking at fault tolerant programming in PHP applications. Essentially, this means writing your code so that error conditions are handled gracefully and with as little impact as possible.

In your application, every time you call an "external" service you are vulnerable to the failure in that service. That either might be a third party API being down, your database being unresponsive or unexpected errors from the 3rd party library you are using. With many developers and companies being interested in composing applications out of microservices at the moment, guarding for failures because of broken dependencies gets even more important.

They describe a situation where data is coming from an external source (an inventory service) and a timeout or connection failure occurs. They propose a sort of "circuit breaker" to be put in place to protect the application, fail fast on error and maybe even retry until the request is successful. They also point out a library from oDesk, Phystrix, that allows for fault tolerant execution through a wrapper that traps errors and deals with them instead of just breaking. This is the first part of a series, so in part two they'll show the library in use along with the React HTTP client.

On the PHP Manual Masterpieces site has a recent post looking at PBKDF and PHP (and, more specifically, the information that's presented about it in the manual).

So why are we here? Well, a faithful follower slipped me a tip to check out the documentation. It turned out I agreed: I don’t like it. [...] Let’s be clear: I have read the backing C code of this feature and I see nothing wrong with the actual functionality. My issues are strictly with the documentation and the API, both of which are very PHP-ish in the sorts of ways that drive me to hateblog about a programming language on a Friday night. It turns out there are people who are totally okay with these design decisions, and I can’t help that their subjective tastes are wrong, but that’s just how it is.

She mentions three different major issues with the documentation currently in the manual:

• Non-copypaste-safe cryptography
• The fact that PHP does not fail effectively when it comes to cryptographic handling
• The lack of units defined (like for the "length" parameter of hash_pbkdf2)

Paul Jones has an interesting post on his site today talking about how how your "framework of choice" will eventually fail even if there is long term support for it. He points to another article about trial and error and emphasizes that (as Richard Feynman has said) failures are just as important as successes.

When it comes to expanding a body of knowledge, the failures are just as important as the successes, perhaps more so in some cases. (Be careful here; they have to be “honest” failures, where you had some reason to believe in advance that it had a good chance of working.) So what is it about the “Pipe Dream” article [here] that impressed me? It is that the the author first signals his tribe membership by mentioning his “framework of choice”, then proceeds to try to do some work outside of that tribe.

Paul goes on to talk about the usefulness of stepping outside of your norm - your framework of choice - and getting a wider perspective on how others do things. He looks at some of the ways that current frameworks could fail in the future and figuring out how well it will deal with it when it does. He points out that several times the failure comes from "subsystem failures" and that systems that allow the swapping out of these components would handle things more gracefully. He gives the example of the Aura framework of this, being highly component-based.

Brandon Savage continues his look at using RabbitMQ and PHP together to queue up requests today in this latest post. In this new part of the series, he focuses on the last piece of the puzzle - consuming the requests in the queue. (Parts one and two)

Once you’ve created a RabbitMQ producer, it’s fairly easy to create a consumer. In fact, the only difference is in exactly what commands you’re using. The connection, envelope, channel and queue declarations are the same. While in RabbitMQ you publish to the exchange, you actually do consume a specific queue. As a result, the commands for consuming are part of the AMQPQueue class.

He shows you how to set up the code to sit in the background and wait for a queue request and how to fetch them in a non-blocking way. He finishes off the post with a look at handling success and error conditions (based on the status of message consumption, not the result of the processing).

Anthony Ferrara has a new post to his site today describing what he sees as a failure in our industry - letting security become an after-thought to the development process.

In the April issue of the PHPArch magazine (also published on her blog), Elizabeth Tucker Long wrote a really interesting editorial piece coining a concept she called Security-Driven-Development. She (quite correctly) identified a problem in the current development community where security has become an after-thought (if it's thought of at all). This isn't a new concept, in fact it's a concept that I and many others have been preaching for quite a while now. However I've been coming to realize that I've had it wrong the whole time. And I think the entire industry is getting it wrong today.

He talks some about the current state of web application development and how, even with more powerful technologies than ever, we still fall short in security testing. He suggests that the current way of doing things - treating security testing as a "throw it over the wall" or "someone else's job" problem - needs to stop. Security needs to be integrated with development and he suggests that managers and developers of open source projects should take the lead.

Anthony Ferrara has posted another video in his "Programming with Anthony" series, this time pointing out that failure is always an option.

A few days ago, I posted a video about how to become a better developer. There were a few interesting comments made, but one in particular from the Reddit threadpeaked my interest. So I decided to do a reply.

You can watch the video either in his blog or over on Youtube. He's also included the some of the contents of the Reddit post and a funny (relevant) comic about learning "C++ in 21 days".

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.