On PHPMaster.com today there's a new tutorial that can help you increase the performance of your application relatively painlessly with the help of the Varnish proxy tool. The article helps you get started.

Varnish is a reverse proxy server; it sits in front of your web server and serves content from your server and no one else's. Reverse proxy servers are tightly coupled to the web server and can act on messages received from it. [...] Simply put, Varnish does one thing: serve web content super fast.

You'll need command line access to the machine (as well as permissions to install the software) but getting it installed is a simple "apt-get" away. There's a bit of configuration to set up to get it up and working, but it's only a few lines...and examples are included in the tutorial. They get into some of the more advanced configuration options too, like the time-to-live and changing the port it listens on. Varnish isn't just for PHP applications either - it can be used effectively for any kind of web application as it's just a proxy layer that sits on top and waits for requests.

Shashikant Jagtap has Behat TDD testing tool and the BrowserMob-Proxy to make an automated system that collects performance data on your applications (including load time, recording headers and simulations of network traffic and latency).

BrowserMob Proxy is a utility which is used for capuring HTTP traffic and performance data from the browser. BrowserMob-Proxy adds in essential missing capabilities such as checking HTTP status codes and injecting headers for HTTP Basic Auth. Web Perfomance data can be manually captured by other tools like Firebug or Developers Tools. Using BrowserMob Proxy we can capture perfonace data in HAR format while running automated tests.

He includes the commands you'll need to set up the PHP interface for BrowserMob (PHPBrowserMob) the proxy itself and a sample test and context file that runs some checks against Facebook.

On DZone.com there's a new tutorial posted (by Jorge Ramon) about hooking together the models of Sencha's Touch 2 with a PHP backend to make saving data to them simpler via a proxy.

Sencha Touch models have the ability to work with a proxy. This feature allows you to save and retrieve model data from the server, memory or local storage, without depending on a Sencha Touch data store. Let's try it with a very simple scenario where the server side is a PHP page.

The article includes both the Javascript to create the models (along with its proxy and custom API methods defined) as well as the PHP that powers the backend. The PHP just reads from the "php://input" stream and echoes back out JSON, but it gives you an idea of what to expect to receive. For more information on Sencha Touch, check out their documentation.

In some of his work with Backbone.js recently, Gonzalo Ayuso has been frustrated by something that's a wall for many developers wanting to work with outside datasources - the browser restriction that prevents cross-domain requests. His solution? Create a REST proxy to live on his server and pass the requests through.

Nowadays there is a header to allow it: Access-Control-Allow-Origin. The problem is that the remote server must set up this header. For example I was playing with github's API and github doesn't have this header. If the server is my server, is pretty straightforward to put this header but obviously I'm not the sysadmin of github, so I cannot do it. What the solution? One possible solution is, for example, create a proxy server at localhost with PHP.

He shares the full code for his project - basically a handler that takes the incoming request and mirrors to out to the public, remote API - request method and all. It uses some of the packages from Symfony (like the http-foundation) and wraps around cURL to handle the requests. The project is available for Composer users as well.

On PHPMaster.com today there's a new tutorial from Alejandro Gervasio about using virtual proxies in your application - a method in development that provides a layer of abstraction on top of domain objects and makes it more efficient to work with (and lazy load) them.

Often referenced by a few other fancy names, the substitute is generically called a virtual proxy, a sort of stand-in that exploits the neatness of Polymorphism and interacts with the actual domain objects. Proxies aren't new to PHP. Doctrine and Zend Framework 2.x make use of them, although with different aims. On behalf of a didactic cause, however, it would be pretty instructive to implement some custom proxy classes and use them for lazy-loading a few basic aggregates from the database, this way illustrating how virtual proxies do their stuff under the hood.

He starts off by setting up a domain model for a "Post" and "Author" - a typical blog example.Based on the definition of these classes, he creates a mapper class to generate Author objects and an "AuthorProxy" class that uses a "loadAuthor" method to only load in the author's details when a property is requested. He gives a bit more code showing it in action and the difference between using the normal Author and AuthorProxy class.

Markus Pullmann has a new post to his blog about setting up XDebug in your PHP installation to help you narrow down those elusive issues more quickly.

Debugging locally is a nice improvement to have no debugger at all, but in many situations there is the need to debug on production server, where the application is running on the web. There are different reasons for that, but the most important one for me is, that my local environment / installation is different from the one i have on servers in data center and bugs can be related to the environment.

He walks you through the installation and server-side configuration of XDebug first then shows how to install the Komodo Remote Debugging Client to help with multi-user debugging setups. He mentions setting up the debugging on the client/IDE side, but there's no specific instructions for any particular IDE - just how it works overall.

On SitePoint.com today there's a new post from Craig Buckler showing you how to create a simple XML to JSON proxy server in PHP with a SimpleXML object at its heart.

Unless you're new to this web development lark, you'll know the 'X' in 'AJAX' stands for XML - eXtensible Markup Language. But you're probably not using XML. If you are, you'd probably prefer not to. All the cool kids are using JSON or JSON-P: it has a smaller payload, is easier to use and faster to process. [...] Fortunately, there are a couple of solutions which allow you to retain the benefits of XML data interchange but provide the ease of JSON in JavaScript. In this article, we're going to create an XML to JSON proxy server in PHP.

Of course, this will only work with well-formatted XML documents, but it's a quick little hack that pulls in the XML data with a curl request and parses it via SimpleXML and uses json_encode to push it back out as JSON.

On the Liip blog Bastian Feder has announced the first release of a tool that helps you proxy your objects (overlay them with a layer that exposes properties and methods) following the proxy object design pattern in PHP.

The outcome is this little library making it much easier to generate a proxy of your system under test (SUT). Another thought on this library was, that it should be very easy to use if you know the way to mock classes and methods in PHPUnit. Proxy-object has almost the same API, but does not change the behavior of the proxied class/method. The only purpose is to expose hidden methods and members.

The scripts, found on github, give you a simple way to define a proxy over a given class' functionality and define methods/member variables to be exposed. He includes two code examples, one of each type. There's also an example of making the proxy object without calling the constructor, useful in certain cases when the initialization of the object doesn't need to happen.

You can also find out more about the usage of this tool in this new post to Bastian's blog.

In a new blog post Matthew Weier O'Phinney has taken a look at proxy objects (the Proxy design pattern) and how it differs from some of the other popular patterns.

Of the other patterns mentioned, the one closest to the Proxy is the Decorator. In the case of a Decorator, the focus is on adding functionality to an existing object -- for instance, adding methods, processing input before delegating to the target object, or filtering the return of a method from a target object.

Proxies stand in for objects and have several benefits for your application that may or may not need all of the overhead a full object could cause. Matthew focuses on one benefit in particular - consuming and controlling access to another object. He sets up a problem of wanting to use properties/methods on objects that aren't exposed directly (like a protected method). His solution is a proxy layer class on top of the original object. He includes a few "gotchas" to look out for when using this technique including overwriting all necessary methods and copying over all of the needed properties.

Derick Rethans has a new post today with a bit of code showing how to combine Flickr and OpenStreetMap and make a mapping tool that plots out the location information for the Flickr images.

I like taking pictures, and I usually take a GPS so that I can place them on a map on my Flickr page. On my last excursion however, the battery of my GPS had died, so I did not have location information available to store in my pictures' EXIF headers. Flickr can use the EXIF headers to then show the images on the map. Because I did not have the location information to automatically place my pictures on the map, I wanted to do that by hand.

His script (as used by a local Squid proxy) supports two different versions of the mapping - one for Yahoo! Maps and the other for OpenStreetMaps'. You can see the end result here - a set of Flickr images with a map in the background.