On the Codacy blog there's a recent post that looks at some of the biggest threats to code quality (six of them) and some brief advice on how you can prevent them. Code quality goes beyond just style guides and common coding practices too.

In the process of building Codacy, I’ve learned that software companies in different life stages have different needs in terms of code quality. Early startups have, for example, very different needs in comparison to digital agencies and freelancers. There is however a common ground that links them all together: code quality is not being taken seriously enough, regardless of the stage. If this resonates with you, take action today. Continuous improvement is the central piece of software engineering craft.

Among the six things in their list are suggestions like:

• Using continuous integration
• Living with broken windows
• Heterogeneity (code styles)
• Not using static code analysis

They also link to some tools that can help fix some of these suggestions including JSHint, some PHP static analysis tools and CSSLint for CSS.

In his latest post, Pádraic Brady suggests that you take PHP security seriously and start really thinking about the security of your applications, not just talking about them.

Most programmers treat security as an afterthought and engage in zero self-directed education about security in general. The most common response is actually shock, followed by denial, followed by excited elation at the idea of fixing stuff, followed by the sobering realisation that someone somewhere is an evil fucker for making their lives harder by not telling them all this sooner. Some graduate further into taking security seriously, seriously. This is actually PHP’s current failing: Knowledge.

He talks about some of the mislead beliefs that many PHP developers share about the "One True Way" to secure their applications from common things like XSS and CSRF. He also shares his thoughts on how to solve this knowledge problem...and it's not by reading the same things we have been for years now. New knowledge needs to be shared, new questions need to be asked and new methods need to be shared for effective security precautions.

Knowledge is the essential ingredient to improving PHP Security. What you don’t know can bite you; what you do know can be hunted down and shot.

In this recent post to his blog Johannes Schlüter he talks about a way that he's come up with to test functionality that uses persistent connections (and an module he created to help).

In a few rare cases this is not what people like, for that PHP introduced "persistent connections" of different kinds. Testing those is a bit annoying as you have to configure a webserver and ensure to hit the same instance over the course of a test and then use a load generator, probably one which can detect a failure. Additionally by having a webserver in the game there is more code being executed, which might mean an additional source for trouble while debugging. An alternative might be using FastCGI, while that adds it's own issues for such a test. To solve this for myself I, some time ago, wrote a PHP SAPI module called pconn and pushed it to github.

The extension provides a way to emulate requests by executing a script multiple times automatically, making it easier to test things that require checking against multiple things simultaneously. While the built-in webserver (PHP 5.4) can be used to test some of these things too, Johannes' extension can also be compiled to help with testing of threading in applications as well.

In case you missed it (though I'm not sure how you would) there was a scare for WordPress users out there that have been using an older version of the popular blogging engine about a worm going around an exploiting a hole to create a user, become an admin and quietly put spam links and malware into your posts without you knowing. The solution? Simple! Update right away!.

If you're currently running an older version of the WordPress software and want to be sure that you haven't fallen prey to the worm's threat, you can use the query Dougal Campbell has posted to check your wp_users table for administrators. Check the results of this to make sure there's no extra admin accounts found.

Keeping your software up to date is always a good first line of defense, so be sure that you've downloaded the latest to keep you and your blog protected.