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).

Giorgio Sironi has started up a new series on DZone.com about some practical testing patterns you can use when writing up unit tests (and other types of testing in some cases) for your applications - the Test Strategy Patterns.

The list so far includes the patterns for:

• Recoded tests
• Scripted tests
• Data-driven tests
• Test automation frameworks

Keep an eye on this great series. There's more to come that can be quite helpful when you're trying to generate those tests and procedures around them.

On the Zend Developer Zone there's a new article from Keith Casey looking at some of the "best practices" when it comes to writing unit tests for your applications.

If we are starting from absolutely nothing, building tests as we go is a near-trivial process. [...] Unfortunately, most of us don't have this situation. We walk into a project with documentation ranging from non-existent to seemingly-useful-but-really-out-of-date, and hundreds of thousands of lines of code, and the coding standards and practices of every developer that has come before us. In this situations, the above Unit Test example is almost mocking us. We can't start that simply! Or can we?

He walks through some of the steps he and another project lead took to start their trip into testing - finding the most problematic bits of code first (based on bugs in the tracker) and testing them, figuring out how to test rapidly changing code, finding common code used in several places and testing that and

In this new post to his blog talks about authentication strategies in Zend Framework applications with the combination of Zend_Acl and Zend_Auth.

I'm going to talk more about ACLs than Auth. Auth is simple, it's the ACL that will trip you up. Since both concepts are coupled together when you're making a login system, I feel it's appropriate to at least touch on Auth. What I want to cover is the ways we can create the ACL object to suit needs based on the scale of the project. I'm going to assume that readers have a passing familiarity with using the Auth and Acl objects and may have even implemented them into projects.

He talks about two things you'd need to consider - scalability (how to define your ACLS: hardcoded, in the navigation object and defined in a database) and working with ACLs in multiple projects.

On NETTUTS.com today there's a new tutorial that introduces a bit more advanced concept in the development process - design patterns.

Design patterns are optimized, reusable solutions to the programming problems that we encounter every day. A design pattern is not a class or a library that we can simply plug into our system; it's much more than that. It is a template that has to be implemented in the correct situation. It's not language-specific either. A good design pattern should be implementable in most - if not all - languages, depending on the capabilities of the language.

They introduce a few of the more widely used patterns including the strategy pattern, adapter pattern, factory methods, decorator and singleton patterns. Each comes with a bit of code showing how it would work and a "where would I use this?" section with a better example.

In a new post to her blog today Lorna Mitchell has a few suggestions for handling database patching when your application starts to outgrow its simple roots.

One problem that seems to need solving too often is how to keep databases in sync across different platforms, different developers working on a project, and deploying database changes along with code changes. There are lots of ways of approaching this, none of them are really excellent however and personally I tend to err on the side of simple being better. Fewer dependencies means a solution more likely to work on every platform (and no additional complications for the live platform). Usually this means patch files of some kind.

She outlines her usual approach - creating a table with metadata and version information, export the structure of the database in push it into a row, creating numbered patch files and keeping it all stashed away in versioned source control for easy access. Check out the comments for some more interesting ideas.

On the Coders' View blog there's a recent post looking at using the strategy design pattern in your PHP application.

In the strategy pattern, algorithms are extracted from complex classes so they can be replaced easily. For example, the strategy pattern is an option if you want to change the way pages are ranked in a search engine. Think about a search engine in several parts - one that iterates through the pages, one that ranks each page, and another that orders the results based on the rank.

Their example shows a class that, based on a few different search "strategies", can locate user information in the user listing. Their example uses a random and a "find after" strategy and includes the results.

Federico Cargnelutti has been posting a series of articles to his blog recently about domain-driven design, a method for organizing your code for maximum reuse between domains. He focuses on the "M" (model) in the MVC structure (model/view/controller) and how it can be separated out into a layer all its own - the domain layer. Here's the parts of his series so far:

• Domain-Driven Design and MVC Architectures - an introduction to the domain-driven concept and some definition of terms that he'll be using.
• Domain-Driven Design: Data Access Strategies - a look at some of the different data access methods (like Active Record, Data Transfer Objects and generic Data Access Objects)
• Domain-Driven Design: The Repository - illustrating how the user-created code would interface with a DAO instead of directly working with the database itself. It provides another abstraction layer that is more specific to your current application instance.

Adam Jensen has submitted a new post he's written up about the idea he had for a spades game written in PHP. There's no fancy graphics or computer AI but there is a good example of using the Strategy Pattern between the players and interfaces in this CLI script.

Here's the project (and I deliberately didn't check to see if anyone's done this before): write a command-line PHP script that runs any number of automated spades games, involving a variety of players utilizing different play algorithms.

The Strategy Pattern comes in with the players - each influences how the player will bid and what cards it will choose to play. He gives the code for these two interfaces - Spades_Player_Interface and Spades_Strategy_Interface. He also sets up a randomizing class and several of the other "structure" classes (Spades_Play, Spades_Card, etc).

This post is just the start of the project. If there's enough interest, Adam will release the source for the project including some of the other strategies he's considering.