Christian Maioli Mackeprang has a new post to his site sharing some of his recommendations of how you can deal with poor code in limited time when making changes (or adding new features) to an older codebase.

You’ve been given the task of implementing a new feature on an old codebase, but the code looks awful. How can you understand it as quickly as possible? Here are several shortcuts to help learn the important parts of new code without getting lost in the irrelevant details.

His list includes both technical and "people" related suggestions including:

• Ask for help
• Make it easy to reproduce bugs
• Prepare for automated testing
• Get on familiar ground before tackling critical code

For each item in the list he includes a summary of what's involved along with "dos" as well as "donts".

On the Resonant Core blog there's a new post from Scott Arciszewski looking at some strategies for secure long-term authentication (usually in the form of "Remember Me" functionality).

Let's say you have a web application with a user authentication system, wherein users must provide a username (or email address) and password to access certain resources. Let's also say that it's properly designed (it uses password_hash() and password_verify() and rate-limiting; it doesn't have any SQli or XSS flaws). Everything is going well for a while, but eventually your users would like the convenience of a "Remember me on this computer" button. What do you do?

He proposes a few different solutions including:

• the storage of credentials from the database in a cookie (a bad idea),
• generating a unique token when the uses requests the "remember me" to store in a cookie
• using two pieces of information, a random token and an "authenticator" for validation

He points out why the first two solutions aren't the best approaches and then gets into the details of how to handle the last recommendation. He includes both the SQL and the PHP code to make the token creation and verification work, performing an auto-login when the two values provided match up.

For those that might be new to development, the concept of "design patterns" could be one you're just approaching. These common practices define some "patterns" of development that have been proven to provide good structure and maintainability to applications...when applied correctly. PHPBuilder.com has an introductory article showing you how to use five of the most common patterns: Factory, Singleton, Observer, Chain of Command and Strategy.

Design patterns provide a generic reusable solution to common problems. A design pattern is not a concrete solution that can be converted in to source code or a machine code rather it is a template which can be used to solve a problem in different situations. Design patterns help in faster development as the templates are proven and from the developer's point, only implementation is required. Design patterns not only make software development faster but also encapsulate big ideas in a simpler way.

For each of the patterns represented a brief description is included and some sample code is given showing it in use. There's not too much depth in this post, so if you're looking for more "meat" on these patterns, I'd suggest checking out some more advanced articles on SitePoint.com.

Luis Atencio has posted the latest article in his "Continuous Delivery" series today, this time with a focus on implementing a testing strategy. This is the fourth post in the series (part 1, part 2 and part 3).

There are three things in life that are always held to be true: we will die someday; we will pay taxes; and software will have bugs.... LOL [...] A testing strategy is often overlooked in software projects. This should not be too surprising, we want to build applications quickly and release them quickly. However, leaving quality out of the picture or towards the end are terrible mistakes.

He talks some about the different types of testing that revolve around software development - "business facing" and "technology facing." These are each split down even further into things like acceptance, integration and unit testing.

On PHPMaster.com there's a new tutorial posted talking about the Template Method Pattern to help make some sense (and make easier to use) your implementation of the Strategy pattern.

This bring us back to the question whether it’s feasible to eliminate duplicated strategy logic via Inheritance rather than switching over to plain Composition. Indeed it is, and the clean up process can be conducted through an ubiquitous pattern known as Template Method. [...] Simply put, there’s a base class (usually an abstract one), which declares a concrete method (a.k.a. the template) responsible for outlining the steps or hooks of a certain algorithm. Most of the time the base type provides boilerplate implementation for some of those steps and the remaining ones are delegated to subclasses.

The subtypes then override the base's functionality and extend it with their own. They show an example of this by making a jQuery image slider (using this plugin) , an "AbstractCycleSlider" class and two subclasses for two other types - "FadeSlider" and "ScrollSlider", each outputting their own HTML. It also shows how to implement a slider using a different plugin and output both in the same script.

In this latest post to his site Stefan Koopmanschap shares a solution he's found to migrating data with Doctrine2 from an existing structure.

A project that I'm working on right now required me to migrate data from the existing database to the new database and database structure. Since the application is built on top of Symfony2, I decided to write a Command that would take care of the migration. I ran into an issue though: Doctrine2 insisted on creating new IDs where I wanted to keep the old one. The solution turned out to be really simple.

The actual code for the Command is only a few lines long - it just turns off the "AUTO" strategy for each of your entities, making it ignore any IDs you have set on the entity already.

In response to this suggestion from Alessandro Nadalin about using the "Strategy" design pattern to replace a switchChris Hartjes has this new post sharing his opinion of "the right way" do it it.

Once I realized what he was doing, I realized that the Strategy pattern was applicable in this case…but his chosen example was dumb and one that I wouldn’t have used to demonstrate things. As expected, he told me to supply a sample of a better way. I did, telling him that the sample would be better if he didn’t mash the logging level together with the message.

Included in the post is sample code, first showing the initial version of the logging class, complete with accompanying tests. Following that, he shows how to refactor it into something using the Strategy pattern, replacing the logging type switch statement with protected methods for each logging message type (critical, notice, etc).

Anthony Ferrara has a new post today looking at plugin handling and a few of the more common design patterns that can be used to implement them in your applications.

A common problem that developers face when building applications is how to allow the application to be "plug-able" at runtime. Meaning, to allow non-core code to modify the way an application is processed at runtime. There are a lot of different ways that this can be done, and lots of examples of it in real life. Over a year ago, I wrote a StackOverflow Answer on this topic. However, I think it deserves another look. So let's look at some patterns and common implementations.

The patterns he covers are:

• Observer
• Mediator
• Strategy
• Decorator
• Chain of Responsibility

For each there's both a bit of sample code showing it in use and links to some examples from various frameworks and other projects.

Michael Nitschinger has a new post for the Lithium framework users out there - a quick tutorial about encrypting your session information with the new built in "Encrypt" strategy feature.

If you check out the master branch, you can use the new Encrypt strategy to encrypt your session data automatically. This means that you can read and write session data in cleartext and they will be encrypted on the fly before getting stored (in a cookie, for example).

You'll need the mcrypt extension installed for it to work correctly, but it makes storing the encrypted version of your data more or less automatic. Just set up your Session configuration to use it as a strategy and any time you call a "read" or "write" the hard work is handled for you. For those more interests in what's "under the hood" he goes on to talk about how the strategy works, what cipher it uses by default, how to change it and the default string to use in hashing.

On the Label Media blog today Tom Rawcliffe continues his series looking at design patterns (see here for his look at the Factory pattern) with this new post focusing in on the Strategy pattern.

The Strategy Pattern is used to decouple an algorithm from the context in which it is used. I'm going to equate this example to a real world scenario starring a man, I'll call him Bob.

In his example Bob heads to work and takes whatever way he wants to get there. His boss only cares that he makes it there, not the path he takes. Bob can take many different ways ("strategies") to get there, but how is up to him. Tom illustrates this with a bit of sample code with a "bob.php" that can use any number of other classes/methods to get to work (like commute, the train or a car).