In a quick new post to his blog today Brian Swan shows you how to find a drive letter in Azure through PHP (for a Windows Azure Drive).
Today, I’ll start by taking a look at Windows Azure Drives. Specifically, I’ll explain how to programmatically determine the driver letter for a Windows Azure Drive. (I’ll assume you’ve read the getting started post I wrote a couple of weeks ago.) Simply put, a Windows Azure drive acts as a local NTFS volume that is mounted on the server’s file system and that is accessible to code running in a role. The data written to a Windows Azure drive is stored in a page blob defined within the Windows Azure Blob service, and cached on the local file system.
He shows how he’s set up his instance with two drives and how, with a bit of PHP code, he could grab the value from the “X_DRIVES” environment variable, split it out and loop to find the drive you’re looking for. His example code puts a simple text file on the drive and then reads it back out.
On the Re-Cycled Air blog Jack Slingerland has posted another in his “Dark Arts” series looking at some of the lesser used PHP features. This time he focuses in on daemonizing a process by forking it off into the background.
One of the many things you don’t often do with PHP (actually, I’m not sure you do this much with any language) is daemonize a process. A daemon is program that runs in the background (read more here). On Unix systems, processes are usually created by forking the init process and then manipulating the process to your liking. To create a daemon though, you need to get the init process to adopt your process. To do that, as soon as you fork the parent process, you kill the parent. Since you child process is parent-less, the init process generally adopts it. Once that happens, your process has been daemonized.
He uses the pcntl_fork function to spawn off the child process, detach it from a terminal window, create a “.pid” file so the system knows about it and then, of course, have the child script do something.
On the NETTUTS.com site today there’s a new tutorial about using the LESS CSS tool to get the most out of the styling of your website. The tutorial uses the PHP implementation by Leaf Corcoran to accomplish the same things as the Ruby library offers.
During a sick day a few weeks ago, I got around to something I’ve been meaning to look at for about a year: LESS. If anything web technology is worth a look, I promise LESS is. In this article, we’ll look at the amazing power of LESS and its ability to streamline and improve your development process. We’ll cover rapid prototyping, building a lightweight grid system, and using CSS3 with LESS.
They use an output buffering trick to handle parsing and executing the “.less” CSS-based files through the library and spit the parsed version back out the other side. There’s plenty of examples of how to use the LESS syntax ending up in their previously mentioned grid system using mixins, some cross-browser CSS3 and the CSS3 Pie tool.
On the Zend Developer Zone today there’s a new tutorial by Olek Janiszewski with a suggestion to help make the execution of your application’s PHPUnit tests around three times faster. There’s two problems that he sees as the slowdowns – truncating tables after the test runs and declaring tables in controller tests.
As I’ve mentioned before, Zend Framework isn’t really encouraging developers to do TDD (on the other hand, this shouldn’t be a surprise in the PHP community). The application architecture is based on singletons all around (front controller, session, layout, helper broker, registry, etc.), the bootstrap doesn’t “separate the cacheable from the non-cacheable”, there’s no built-in support for dependency injection, the ORM is cumbersome to stub out.
So, as a solution to these problems, he suggests a simpler way to handle the test by wrapping the entire thing in a transaction and then rolling it back after the case is done. There are a few issues with doing it this way, though. There’s four of them – that the database connection isn’t really shared, MyISAM tables, issues with expected primary key values and a performance boost but only on certain systems.
In the comments, there’s a note about two things that could help this situation and are already included in some of the Zend Framework functionality – Zend_Test_PHPUnit_DatabaseTestCase and ControllerTestCase.
New from the SitePoint blog, there’s an article from Craig Buckler about using buffer flushing to increase the load times of your applications and websites.
Output buffering makes this process quicker and more efficient. The buffer is essentially a big memory-resident string. When text is output, it’s appended to the buffer rather than returned to the browser immediately. The buffer is then “flushed”, i.e. its contents are transmitted and the string is reset pending further output.
He notes the instances where the buffer would be flushed – end of page, exceeds number of bytes allowed or a manual flush is called – and code snippet example of a simple flushing setup. He also asks for some feedback on this method, so be sure to look at the comments for more thoughts from the community.
On PHPBuilder.com there’s a new tutorial from Octavia Anghel about using the DOM extension to parse XML in a PHP5 application. The DOM functionality makes it simpler than even the older PHP4 DOM functionality to work with XML messaging and documents.
DOM (Document Object Model) is a W3C standard based on a set of interfaces, which can be used to represent an XML or HTML document as a tree of objects. A DOM tree defines the logical structure of documents and the way a document is accessed and manipulated. Using DOM, developers create and build XML or HTML documents, navigate their structures, and add, modify, or delete elements and content. The DOM can be used with any programming language, but in this article we will use the DOM extension for PHP 5. This extension is part of the PHP core and doesn’t need any installation.
They include both a sample XML file to parse and the code you’ll need to pull it in and make a basic DOM object out of it. Also included is some code showing how to pull out certain pieces of information, recurse through a set of XML values, add new nodes to the structure, remove a node and more.
On the ServerGrove blog there’s a new post showing you how to customize those default error pages that show up in a Symfony2 application when an exception is thrown.
The framework produces a very detailed report when in the development environment. However, when you put the application in the production server, you will need to display a user friendly page. Creating a custom page is actually simple. All you need to do is define a controller/action pair that will generate the response. You can either use an existing controller or create one specifically to handle errors.
They include a sample “lean” controller to just handle the output for the exceptions as well as a template to go with it that just has a basic customized message and a status code for the exception. Using it is simple – just add an “exception_listener” setting to your configuration file to point at the new controller.
Lukas Smith has a new post to his blog looking at some of his experiences with working with JSON in the upcoming version of the Symfony framework (Symfony2), specifically in using the DoctrineUserBundle and load views via JSON.
Unfortunately right now there are quite a few issues with taking a 3rd party Bundle which wasn’t specifically build to be accessible via JSON. So in the end I build a MultiplexController that can JSON-ify any controller. The name derives from the fact that it also supports calling multiple routes at once and returning all the data from all these routes in one request. But being good OSS citizens here at Liip, we decided to use this opportunity to try and come up with a more sustainable solution. The goal would be to make it essentially possible to have a 3rd party controller return JSON without having to do anything on the controller level.
He talks about the “magic” that lets you define the output format you’d like and how it works on the backend with the templating system to use templates based on the requested file. He points out a few issues with the method – a form request problem and that there’s no good way to call json_encode from inside a twig template (as well as redirecting after submission).
Paul Jones has come back around and revisited the benchmarking setup he’s created and has rerun some of the baselines on a new, clean EC2 instance and posted the results to his blog. These benchmarks were run using Apache’s ab, Acme’s http_load and joedog’s siege.
I thought it might be interesting to see what each of them reports for the baseline “index.html” and “index.php” cases on the new Amazon EC2 setup (using a 64-bit OS on an m1.large instance). The results follow (all are at 10 concurrent users, averaged over 5 one-minute runs).
In his results, he shows quite different numbers for the “absolute” requests per second that each of the tools registered. There were some differences from the previous benchmark runs that could have been caused by the update in Ubuntu version and using a 64-bit instance over a 32-bit instance on the EC2 setup.
