If you've ever been interested in using Varnish as a caching layer for your application but weren't sure where to start, you're in luck. In a post to his site Thijs Feryn has announced the release of his book covering Varnish and helping you get started integrating it into your infrastructure.

I’m proud to announce that my Varnish book is out now. It’s called “Getting Started With Varnish Cache” and it’s available for download through Varnish Software. For the next 30 days, Varnish Software has the exclusive rights to distribute the book. After that, O’Reilly will also be distributing physical copies and the digital version of the book, while Varnish Software will continue to distribute the book on their website.

Varnish Software is currently offering the book for free (well, "free" after you give your personal info). Thijs gets into a bit of detail around the book, the process he followed creating it and what kinds of things Varnish can help with. He points out that it was "one hell of a ride" writing the book and getting it published but notes that it was a "fun experience" and probably won't be the last book he writes.

Joe Fallon has a post to his site talking about immutable objects in PHP, objects that once the property values are set they cannot change.

When I first learned to program, I made many objects that were mutable. I made lots of getters and lots of setters. I could create objects using a constructor and mutate and morph the heck out of that object in all kinds of ways. Unfortunately, this led to many problems. My code was harder to test, it was harder to reason about, and my classes became chock full of checks to ensure that it was in a consistent state anytime anything changed.

[...] Now, I favor creating immutable objects. The folks over in the functional camp are super excited about this concept. However, it’s been around for quite a while and it has so many benefits.

He talks about how immutable objects make it easier to not only test code but also allow for more rational reasoning about their contents. He points out that they also make it easier to understand the state of an application should an exception arise. He then gets into some examples of immutable objects, creating an ImmutableClass and a ImmutableClassBuilder to help create instances based on values provided.

On the Zend blog there's a new post that looks at one of the major steps when you start to think about automation in the deployment of your application - continuous delivery.

For many, the process of manually developing and deploying software to production is archaic at best. Even in highly automated software development environments, at least one developer (although often more) typically manages modifications to code and software products, and the ramifications of these modifications can be extensive or unknown. [...] The emerging process for developing and deploying applications of high quality is one that is highly automated, executing continuously, and covers the entire development process, from modifying code through testing to deployment. Automation provides analysis that flags code for improvement and executes full regression tests every time a modification is made.

[...] This process is called continuous delivery, and automation is a key component of a mature continuous delivery process, which includes: continuous integration, infrastructure automation, and release automation.

After the introduction, they get into some of the basic concepts of continuous delivery and what kinds of steps can make up the full process. From there they get into some of the benefits of its introduction including lower staffing costs and enhanced teamwork. They balance this out with two barriers that could prevent adoption - the initial cost and the organization culture considerations that would need to change.

Giorgio Sironi has a new post to DZone.com today about some of his experiences with Behat, a behavior-driven development testing tool written in PHP. It uses the Gherkin language syntax to define its tests.

I had the occasion to try out and adopt Behat for a particular need in our projects at Onebip. Here is my recount of the experience from a PHPUnit contributor and invested person.

He starts off with a list of situations where he doesn't think that Behat is a good fit for testing including testing of a single object and acceptance tests where comparing the response from more than one test is needed. He suggests that it's more useful for verifying high level business rules than anything. He talks some about the shift they made to using Behat and some of the benefits they found in its use. He finishes up the post by looking at the technical side and includes a warning about letting the size of the FeatureContext file get too large.

In this new post to his CodeDiesel site Sameer Borate looks at something that's been a controversial topic with developers (not just PHP) about storing binary data, like images, in a database instead of on the local file system.

There is much discussion and argument with no final say on the issue. In one of my recent project the same issue was raised; the client and myself discussing the benefits and drawback of storing the images into a database. The project needed storing around 50,000 images, so it was important to get the question resolved satisfactorily. After much deliberation we settled on using the file system. The major factor in the decision was that we needed the database and images decoupled as we would be having multiple databases using the same set of images.

He goes on to talk about some of the things you should consider when you're deciding if storing images in the database is the right thing for your application including:

• The bloat that can come with storing binary data (larger database size)
• Updating images requires two operations - updating the database and updating the cached image locally
• Images usually serve faster when they come from the filesystem through the web server
• BLOB (a common type for binary data storage) is variable-width and can degrade performance

You can read the rest of the reasons (and get more detail on the ones above) in the rest of the post.

On the JSLabs blog today, there's a new post talking about the combination of PHP and Resin (a high-performance application server).

The Resin high-performance, open source application server features load balancing for increased reliability. Caucho's Quercus(TM) is a fast, 100% Java implementation of the PHP language allowing developers to use PHP flexibility for the web interface and Java for stability.

He also talks about some key points surrounding this server as effects PHP developers:

• Performance
• Development
• Capability
• Security
• Scalability

On the JSLabs blog today, there's a new post talking about the combination of PHP and Resin (a high-performance application server).

The Resin high-performance, open source application server features load balancing for increased reliability. Caucho's Quercus(TM) is a fast, 100% Java implementation of the PHP language allowing developers to use PHP flexibility for the web interface and Java for stability.

He also talks about some key points surrounding this server as effects PHP developers:

• Performance
• Development
• Capability
• Security
• Scalability

php|architect's A/R/T article repository has a new tutorial posted today with a look at logging in your application (the entire application) with the help of the Zend Framework by Stefan Koopmanschap.

There are different reasons for logging information, different strategies for what and how to log, and of course different ways of implementing it. This article will look at why you would want to log, what you want to log and how to do it.

They introduce application-level logging, how it can help, what it can show you, and how it can make finding security issues even easier. They get into the code a bit later on, showing how to use the Zend file functionality to write out to a simple log file. They enhance it with a bit more information in the message, and show how to set a prefix/suffix to each line automatically (like a timestamp and a newline).

php|architect's A/R/T article repository has a new tutorial posted today with a look at logging in your application (the entire application) with the help of the Zend Framework by Stefan Koopmanschap.

There are different reasons for logging information, different strategies for what and how to log, and of course different ways of implementing it. This article will look at why you would want to log, what you want to log and how to do it.

They introduce application-level logging, how it can help, what it can show you, and how it can make finding security issues even easier. They get into the code a bit later on, showing how to use the Zend file functionality to write out to a simple log file. They enhance it with a bit more information in the message, and show how to set a prefix/suffix to each line automatically (like a timestamp and a newline).