Best Practices

This article is part of a series on testing untestable code:

Testing private methods Testing code that uses singletons Stubbing static methods Stubbing hard-coded dependencies

I’ve finally made it to my first Zendcon. Its nice to see some familiar faces and also nice to put new faces to familiar names.

I gave my maintainable PHP talk this morning. I love doing this talk. Thanks to everyone who attended. I’ve put the slides (pdf) up on my talks page.

Much of the material is based on Test Pattern columns that I’ve written for php|architect. Here are some of the specific columns.

Organizing For Change This is where I developed the outline for the talk Dependency Injection This is a more in depth discussion of code reuse and dependency injection Modeling Dependencies This is where I talk about coupling, layered design and abstraction A Closer Look at Cohesion This is where I developed my explanations of cohesion and the single responsibility principle Searching the Code Good designs are searchable

The 7 corresponding wastes in software development as defined by Mary and Tom Poppendiek are:

Partially done work Extra Features Relearning Handoffs Task Switching Delays Bugs

Today I'd like to address the 1st waste - Partially done work

Almost all modern web applications need, in one way or another, to encrypt their users' passwords. We could say that, from the moment that an application has users, and users sign in using a password, these passwords have to be stored in an encrypted way.

There are some intuitive reasons for this: our data stores can be compromised, and so can our communications. But the most important reason is that we have to think of our users' passwords as sensitive personal data. Their passwords are their key to their privacy, so they are personal, they are sensitive, and no one (not even us) has the right to know them. And we must honor this if we want to gain our user's trust.

MySQL application developers have some problems with connection state. There is a lot of state which can be used associated with a single connection

* Transactions (autocommit, uncommitted work, when a transaction was started, isolation level)
* Temporary tables
* Session variables which affect behaviour
* Other session variables

If you can avoid all of these, then you can benefit from transparent auto-reconnection and transparent connection reuse / pooling etc.