On the Yappa blog there's a new post about their "trip" towards a PHP and Docker based development environment and the steps they took along the way. The post even includes the full commands and configuration changes you'll need to replicate it.

During a regular work day we work on several PHP projects. Sometimes new projects, but also legacy code which still require earlier versions of PHP. We all work on Macbooks and want to switch quickly and easily between projects. The project requirements vary, the PHP version may be different, or additional services may be required (such as Redis, Elasticsearch, ..).

Unable to mimic the production environment without spending countless hours installing packages on a virtual box for each project.

They start with some of the initial steps they tried including a single local development server and remote servers but points out the issues with each. Ultimately they decided to give Docker a try and came up with their ("almost perfect") development environment. From there they get into the steps to reproduce, the more technical parts, and list the requirements you'll need and the steps in the setup process.

Marco Tabini has taken a different tack on error handling in his latest post. He suggests that developers need to spend a little less time trying to prevent so many errors and a little more time handling the ones that do happen.

When an error occurs, the vast majority of the web-based application code that I see during my reviews performs the software equivalent of running around with its head cut off: the developer spends an inordinate amount of time and resources trying to make the software look like what was essentially a catastrophic failure was nothing more than a small temporary hiccup.

[...] In reality, by the time an error has occurred, there are only two possible outcomes: either you expected the error to occur, in which case you have already written code to handle the failure, or you didn’t, in which case your main focus should be to use the error as a learning opportunity.

Marco suggests alternatives to this usual worry and hysteria - spend more time ensuring that (if something does fail) there won't be any more damage, let the IT team know as soon as you find the issue and testing before you fix (reproduce the error before you dig in to try to fix it).

Recently, the Springloops version control system made its debut on the web and was greeted with both skepticism and interest. One developer, Hasin Hayder decided to look at it from a different angle and worked to see how easy it would be to reproduce a similar service.

Springloops is a nice code management service recently came into focus. It helps you to manage the code base of your application, monitor the commit and deploy the final version easily to another server. So if you are wondering how to build such a system and how it actually works, this article is for you.

He breaks it down into the six main topics (as he sees it) that are the core parts of the system - things like payment gateways, setting up subversion and making it user friendly. He goes through each topic, explaining its place in the application and providing some links to resources to help you set it up (or at least learn more about it).