In the latest post to the Dutch Web Alliance blog Bas de Nooijer looks at a handy use of ESI in Varnish as a part of the output for a REST API. ESI (Edge Side Includes) let you handle the caching and reuse of fragments of the output from your application and define different caching rules/techniques for each.

For a project I’m currently working on we are implementing a REST API. Performance for this API is critical, so amongst some other solutions Varnish is used. This was done with minimal effort, as the API already had the correct caching headers. There was a noticeable improvement, however I had the feeling this could be improved much more. I realised I can basically compare our REST API to any website, it uses HTTP in the same way. The main diffence is the content being JSON instead of HTML. Just like most websites, our API composes content in many different ways, for instance ‘standalone’ resources, collections of resources or embedded resources. In a website this would be a clear use case for ESI, so why not use it in our API?

He starts off by asking the question "why use ESI in an API" and compares the ESI method to the more traditional caching rules and handling. He includes two diagrams showing the flow of each handling type along with a brief description of how it would extract and combine the data. With the background out of the way, he gets into the code. He shows how to enable JSON caching in Varnish and the JSON tag information you'll need to include to tell Varnish to do its job.

Gary Hockin has a new post to his site talking about how he's found that less is more when it comes to what to include in your "composer.json". He works through some of his own opinions on the matter and suggests a bit more thought before just including another library.

I have absolutely no doubt this post will be largely disagreed upon by many in the PHP community, but I’ve had a terrible day and I’m hoping that the process of just getting this off my chest will be therapeutic in some way. [...] So, today I sat down and started writing the tests for our new lightweight SDK that offsets much of the work needed in the delivery of the adverts to workers via a Beanstalk queue. It should have been so easy. Things went well for the early part until I realised that I wanted to be able to extract and serialise our Device object to put it into the queue, and then hydrate it back into a Device object inside the worker

He assumed that since he'd used Zend Framework 2 a good bit and there were no (declared) dependencies, he could directly use an individual component. Unfortunately, there was a dependency (ZendFilterChain), requiring another package to be added via Composer and pulled down. He points out that Composer has made this almost too easy and developers maybe aren't as thoughtful about the libraries they pull in because of it.

He makes a call out to developers to remember the idea behind the MicroPHP Manifesto and really think about the code they're puling in, how large it is and if it's what they really need. He's not suggesting that Composer is the problem, rather the blind usage of it without thinking through the implications.

PHPMaster.com has posted a new article with some high level security tips and reminders for PHP developers when wanting to help prevent issues with their applications. The article provides eight tips, each with a brief description.

When it comes to application security, in addition to securing your hardware and platform, you also need to write your code securely. This article will explain how to keep your application secure and less vulnerable to hacking.

The good practices they recommend include input data validation, protecting against XSS attacks, preventing SQL injections, protecting session data, proper error handling and protecting included files. There's some good reminders here, but it barely scratches the surface of effectively protecting your application. These tips are the "low hanging fruit" for securing your app, so be aware that there's more things to worry about than just these eight.

On the DeveloperDrive.com site today there's a new post with five easy steps you can take to help increase the security of your PHP-based applications.

For many years, PHP has been a stable, inexpensive platform on which to operate web-based applications. Like most web-based platforms, PHP is vulnerable to external attacks. Developers, database architects and system administrators should take precautions before deploying PHP applications to a live server. Most of these techniques can be accomplished with a few lines of code or a slight adjustment to the application settings.

The five tips they list range from general "best practice" kinds of things to a bit more specific:

• Manage Setup Scripts
• Include Files (using ".php" not ".inc")
• MD5 vs. SHA
• Automatic Global Variables (no longer an issue in recent releases, 5.4.x)
• Initialize Variables and Values

Sean Coates has posted a reminder for PHP developers (and really anyone executing command-line scripts) to use "env" instead of hard-coding the path to the PHP interpreter.

These [support] scripts often run PHP in Gimme Bar land, and we make extensive use of the shebang syntax that uses common Unix practice of putting #!/path/to/interpreter at the beginning of our command-line code. Clearly, this is nothing special -lots of people do exactly this same thing with PHP scripts. One thing I have noticed, though, is that many developers of PHP scripts are not aware of the common Unix(y) environment helper, env.

The "env" alias makes use of your currently defined include path to track down a PHP binary to use to execute the script. Since there's only a "best practices" approach to places to put PHP on a server, the "env" usage makes your script more portable and it's one less thing to remember to change.

If you distribute a PHP application that has command-line scripts and shebang lines, I encourage you to adopt the practice of making your shebang line "#!/usr/bin/env php". Note that this doesn't just apply to PHP of course, but I've seen a definite lack of env in the PHP world.

On DZone.com there's a new post from Giorgio Sironi about using Composer to install packages/libraries:

The main package source used by Composer seems more similar to the usage of git submodules at a first glance: a list of dependencies on other projects is specified and stored under version control, and upon a checkout these projects are grabbed directly from their repositories.

He talks about what problem the project solves, what issues he's found with it so far (the amount of stuff downloaded for each dependency, the single point of failure of the one Packagist repository) and shows how to get it installed and creating a sample "composer.json" file for an example project.

In this new post Gonzalo Ayuso talks about "using eval without using eval" in PHP applications - executing PHP code without having to use the eval function to do it.

Yes I know. Eval() is evil. If our answer is to use eval() function, we are probably asking the wrong question. When we see an eval() function all our coding smell’s red lights start flashing inside our mind. Definitely it’s a bad practice. But last week I was thinking about it. How can I eval raw PHP code without using the eval function, and I will show you my outcomes.

He includes some sample code showing a basic script with a class and a loop executing normally, then an "eval version" that puts it all in a string and executes it. He offers a different method - not an ideal one since it requires being able to write to the local file system, but prevents the need for eval - writing the PHP code to a temporary file and using a "fake eval" to pull it in.

Stuart Herbert has his latest post in his "PHP Components" series on his blog today - a recommendation to include unit tests along with the release of you component.

I’m now going under the bonnet of our components, and looking at the different file roles that the PEAR installer expects to find when we distribute our component as a PEAR-compatible package. One of the most important file roles allows you to ship your tests with your package – and it’s vital that this is something that you get in the habit of doing routinely.

He recommends "testing your code and shipping your tests" along with the component(s) you're releasing. Not only does it help you create a better quality end result but also makes it simpler for other developers to make changes and know they're not breaking things. He describes unit tests for those not familiar and includes a specific example of the CommandLineLibrary and its related tests.

On the PHP on Windows blog from DZone.com Krzysztof Kotowicz has a new post - part one in a series on securing your PHP application - a look at securely including remote code from a source outside of your application.

First post of the series discussing various methods of including remote PHP code in your application - from security standpoint. In this post we discuss the history of remote code execution vulnerabilities in PHP apps and ways to prevent them. We finish off by presenting an unsecure method of including a remote code and describe what is the problem with that method.

He looks at the insecurity of a standard include/require, the allow_url_include php.ini setting and the issues with using hardcoded locations (like incorrect DNS records pointing to the wrong host).

Paul Jones has a new post to his blog looking at two approaches to building applications in PHP - either using an include-based of class-based architecture, briefly looking at the advantages and disadvantages of each.

This is a topic I describe at length in my Organizing [Your PHP Projects] talk, but I would like to give the idea a home on my blog for easy reference.

He talks about the typical structure of a PHP application - at least where most start out - being the "include" method. He talks about the progression it usually makes into functions and classes and then, eventually, a jump in concept to the "class" method similar to what several popular frameworks have gone with.

The difference is that no program logic is executed at loading time with a class file. Loading the class file makes it available for use, but the programmer has to instantiate it and then call methods on it for anything else to happen.