Combining phing and Closure Compiler

I have been relatively late to the exciting world of build automation. This has mainly to do with the sys-admin at my old job who insisted on deploying everything himself. By hand. Which left us developers with the task of writing job descriptions for each deploy. And they would typically consist of a list similar to this:

• Move the packed tar.gz to the server
• Unpack the tar.gz
• Copy the contents to the web root
• Chmod files xyz to 777
• …

Oh the madness. Seeing this it should of course be immediately clear that doing this by hand is extremely error prone and slow and plain stupid. Time to automate!

What can my build-file do for me?

There are plenty of flavours to choose from. After some evaluation I settled on phing since the project I’m currently using this for is PHP based, the build files are easy to read (based on Apache Ant) and it’s extensible. phing comes shipped with plenty of tasks for you to choose from and if there’s ever anything missing you want to get done quick and dirty you can run an Exec Task and have PHP run something on the console for you – neat!

Closure

Phing also comes with a JSMin task but this being 2010 I wanted to use Closure compiler because it’s a much sweeter deal and because I wanted to write this blog post. The files produced are smaller and you can do all kinds of cool things like merging files into one (fewer requests!) or removing dead code. It’s pretty cool. I put the whole thing up on Github so feel free to download it from there and fork me. I’ve included a sample task as well so that should get you up and running pretty quickly.  And did I mention Github?

Some Updates

Looks like I didn’t manage to stick to my own goal of taking better care of the blog starting december. But as per default I’ve kept myself quite busy these last few month. I switched jobs in January moving to Rocket Internet as senior web developer. New challenges, new projects and interesting new colleagues. So now that I’ve settled in the new office and after taking some well deserved time off I’ll now be able to take better care of this blog. More updates coming soon!

Google Chrome for Mac

It has arrived, the official Google Chrome Beta for Mac is here. I’ve been regularly compiling the Chromium project for Mac for a while now and it soon replaced Safari as my default browser. I can honestly recommend it to anyone. Lightning fast with beautiful Webkit font rendering; give it a try, you won’t be disappointed!

WP_Registry

Just to let everyone know: I just released my first public WordPress plugin into the wild. Hope it comes in handy to someone.

Quiet

It’s been very quiet on this blog recently, I’ve been swamped with work the last couple of months and have unfortunately found very little spare time to do anything aside from working. The only real bright spot was attending ZendCon in San Jose last week which I enjoyed a lot. I hadn’t been to California in like 16 or 17 years so it was great finally returning after such a long time. I plan putting some of the things I learnt into action in a new project which officially kicked off today (one that I’m very excited about due to the high amount of traffic the site generates which will mean some new challenges in terms of scaling the application..).

Anyways, I’m also planning a relaunch of the site sometime this year so that it better fits the needs of a programmer’s blog (more room for code!) and of course start posting some more soon. I should find time to properly take care of the blog again in late november december.

Zend Framework Classloading Performance

As outlined in the Zend Framework Documentation it’s possible to speed things up a little by removing (almost) all require_once calls from the Framework and relying solely on the autoloading mechanism. I haven’t benchmarked this and I’m fairly certain that it’s a case of micro-optimization but I thought I’d give it a try anyway. The snipped posted there has some minor problems on OS X however. For one the -wholename parameter for find isn’t implemented (can be replaced with -path) and although sed does work, you need to use gsed if you want to pass the arguments as described in the documentation. So here’s the OS X version of the snippet:

find . -name '*.php' -not -path '*/Loader/Autoloader.php' \
  -not -path '*/Application.php' -print0 | \
  xargs -0 gsed --regexp-extended --in-place 's/(require_once)/\/\/ \1/g'

Update: As part of my new job we’re currently working on a merchandise management system which is hosted somewhere in the Amazon S3 Cloud. The performance impact of removing all the require_once calls was very dramatic on that system. So looks like this hint can come in handy after all in certain situations. What I now did is add the snippet to the phing deployment task that takes care of updating Zend Framework. Since it’s hardly any effort at all there really isn’t any reason not to do this.

Let’s make the web faster

This is interesting, Google ist putting together a site about best practices on how to speed up websites. I’ve long been a fan of Yslow and using Steve Souders’ 14 rules for faster-loading websites so this is will be a very welcome addition. Evangelize, spread the message to your colleagues at work. From my experience there’s still a lot to be done!

Typing The Letters A-E-S Into Your Code? You’re Doing It Wrong!

Really interesting article about encryption by Matasano Chargen, well worth a read.

Zend_Form_Element_Exception

After upgrading to Zend Framework 1.8 earlier this week we’ve had a few more minor glitches that have surfaced since. The one which took me some time to figure out was 'Zend_Form_Element_Exception' with message 'No file decorator found... unable to render file element' To ease the generation of forms and get them all to look the same we use a class named Form_Static_Render that the Zend_Form gets pushed into and which takes care of styling, decorators, preview pages and display of form errors. It’s quite a clever little thing. To achieve the proper styling our extension to Zend_Form calls

$element->clearDecorators();

and then either adds the default ViewHelper or whatever gets passed to the method and that was the root of the problem. When clearing the decorators, Zend_Form_Element_File now explicitly requires you to add the File Decorator again before rendering. After discovering that, it turned out being a quick fix…

Replacing Zend_Loader with Zend_Loader_Autoloader

It’s been a while since my last post but I’ve been very busy the last couple of weeks. That’s what also kept me from updating to Zend Framework 1.8 (or 1.8.1 by now already) in our production environment. It has been very smooth so far, the only change that required some work was the deprecation of the old

Zend_Loader::registerAutoload( '...' );

However, upgrading everything to the new Zend_Loader_Autoloader_Interface actually worked quite a lot easier than expected:

class Webwerk_Autoloader implements Zend_Loader_Autoloader_Interface
{
  /**
   * Autoloader
   */
  public function autoload ( $class )
  {
    // Custom autoloading of different classes
    // Each one has a return value
 
    // Fallback
    try {
      Zend_Loader::loadClass( $class );
      return $class;
    } catch ( Exception $e ) {
      return false; // Nothing there
    }
 
  }
}

And in the bootstrapper we have:

$autoloader = Zend_Loader_Autoloader::getInstance();
$autoloader->setFallbackAutoloader( true );
$autoloader->pushAutoloader( new Webwerk_Autoloader( ) );

So the only change was making Webwerk_Autoloader match the Zend_Loader_Autoloader_Interface as well as changing the bootstrap to use the default autoloader as fallback and registering the custom autoloader.