Best Practices

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.

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.

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

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

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

While much attention has been focused on high-level software architectural patterns, what is, in effect, the de-facto standard software architecture is seldom discussed. This paper examines this most frequently deployed of software architectures: the BIG BALL OF MUD. A BIG BALL OF MUD is a casually, even haphazardly, structured system. Its organization, if one can call it that, is dictated more by expediency than design. Yet, its enduring popularity cannot merely be indicative of a general disregard for architecture.

These patterns explore the forces that encourage the emergence of a BIG BALL OF MUD, and the undeniable effectiveness of this approach to software architecture. What are the people who build them doing right? If more high-minded architectural approaches are to compete, we must understand what the forces that lead to a BIG BALL OF MUD are, and examine alternative ways to resolve them.

A number of additional patterns emerge out of the BIG BALL OF MUD. We discuss them in turn. Two principal questions underlie these patterns: Why are so many existing systems architecturally undistinguished, and what can we do to improve them?