Frameworks provide a tool for rapid application development, but often accrue technical debt as rapidly as they allow you to create functionality. Technical debt is created when maintainability isn't a purposeful focus of the developer. Future changes and debugging become costly, due to a lack of unit testing and structure. Here's how to begin structuring your code to achieve testability and maintainability - and save you time.

There's a few concepts they cover in the tutorial including DRY (don't repeat yourself), working with dependency injection and actually writing the tests with PHPUnit. They start with a bit of code that needs some work and use the tests to help refactor it into something that can be easily mocked (using Mockery).

So I was handed an ancient project which was up to me to fix / improve. About a week later I am about done but there is 1 thing I left...Login security. As it is now, it's just md5(password) that's saved in the database. Better then nothing, but far from good enough. My plan was to have a constant pepper in the class which handles the logins, then do something like crypt(pepper . $password) to store it, since that should generate a random salt and is slower then sha1 / md5 / etc. I feel this should be save enough, do any of you have any ideas on how to improve it (without non-standard extensions)?

There's lots of comments so far and a lot of them are following along the same lines - use a better method of encryption, something like crypt with Blowfish or something similar as well as some hashing (like HMAC).

The unfortunate truth of the matter is there's no excuse for [the LinkedIn, Yahoo!, eHarmony and Last.fm] leaks; they would not have been possible if simple, well-known security precautions were taken. Are you protecting yourself and your applications by guarding against SQL-injection attacks? Are you filtering and validating user input? Are you properly hashing user passwords? I hope so! If not, read some of the security-focused articles PHPMaster has published throughout the past year and apply these best practices to your code today!

Articles in their list include:

• Why You Should Use Bcrypt to Hash Stored Passwords
• Input Validation Using Filter Functions
• Multi-Factor Authentication with PHP and Twilio
• Monitoring File Integrity

Check out the rest of the post for links to other great articles.

If writing awesome code is using all the best practices I can find, writing interfaces, unit tests and using top notch IoC containers to control my repositories and services all over my application's different layers - Then I'm not writing awesome code at all! I've been that guy, the one writing the awesome code, but I stopped. I'm not awesome any more. Instead, I'm productive, I'm so damn productive!

He talks about how not writing unit tests (which "customers don't care about") gave him extra time to work on other code and how not using things like interfaces, ORMs and how he follows DRY, but only so far.

My personal result of doing all of this is productivity and better products. I can't tell if I did it all wrong, and that's why I'm writing better code now, but I truly believe that I'm not alone. In fact I think that most of us regular web developers, tend to do the same "mistakes" as I did.

The post has turned into flame bait and has pulled in lots of comments discussing his decisions and other sympathetic souls that feel the same way he does about some of the complexity of the "best practices" promoted in development today.

Filter functions in PHP might not be sexy, but they can improve the stability, security, and even maintainability of your code if you learn how to use them correctly. In this article I'll explain why input validation is important, why using PHPs built-in functions for performing input validation is important, and then throw together some examples (namely using filter_input() and filter_var()), discuss some potential pitfalls, and finish with a nice, juicy call to action.

He talks about why validation is important to protect your application (and users) from malicious things like cross-site scripting. He emphasizes the use of PHP's own filter methods because they are established and, well, included in the language - no additional libraries needed. Example code is included showing how to use them to filter email addresses and check that something is an integer.

You can find out more about these functions on their manual pages: filter_input, filter_var.

As web developers, the applications you write are complex data processing engines. They try and convince your users to enter good, meaningful data and to respond in solid, predictable ways based on what was entered. Robust data validation will allow the rest of you application to work effectively. [...] Data is scrutinized in various ways to make sure that it adheres to basic restrictions and to fundamental properties. It's no good receiving a sandwich when you expect a car.

The questions he answers are:

• Why is Data Validation Important?
• Where Should I be Validating Data?
• When Should My Data Be Validated?
• Who is Responsible for Validation?
• How Do I Validate My Data? (yes, there's a "w" in there!)

In the real world data is ugly, crazy, and untrustworthy. Your only hope to taming the data beast is to diligently, methodically validate your data.

The three posts in the series include tips like:

• Maintain debugging environment in your application
• Collect all output at one place , and output at one shot to the browser
• Set the correct character encoding for a mysql connection
• Do not gzip output in your application , make apache do that
• Don't check submit button value to check form submission
• Process arrays quickly with array_map
• Avoid direct SQL query , abstract it
• Never set error_reporting to 0
• Make a portable function for executing shell commands

Obviously, not all of these will apply in all situations, but they're an interesting list. Most will come with good explanations and code samples when appropriate.

The plan was to try and write as many tests as we could for the Constraint classes PHPUnit uses to implement its assertions. [...] Well, our plan didn't work out that way, we didn't really succeed in writing a considerable amount of unit tests. However, it still was a valuable experience, as it turned out the unit tests of the Constraints are a good example of how not to unit test.

He includes three of the major points they came across in their practice development:

• Don't use one single test case class to test several different classes
• Name your tests well
• Avoid to test more than one behaviour in one single test

For each, there's a summary answering the "why" question behind them including an example test (testConstraintIsType) that shows a bad, multiple assertion practice that should be avoided if possible.

I'm just curious what the best practices are for translating your website into another language, to present foreign readers with text in their home lingua -- well, particularly if there are PHP-specific methods to do so. I've stumbled across the pages for GNU gettext and that seems interesting, but I'm curious what people think of it.

Suggestions include manual translation via a human, use a text substitution method two swap out content versions based on language, using language files (and some opinions from others on which of these approaches might work best).

I really enjoyed giving this talk, since I work so much with APIs and enjoy sharing my ideas. The audio is now online so if you missed the talk, feel free to have a listen. You can also see the slides (on slideshare) and also read the series of blog posts I wrote on this topic which originally inspired the talk.

Lorna has also posted slides for several other of her web services talks including Working with Web Services, PHP and Web Services and Archtecting Web Service Applications.