Combining phing and Closure Compiler

Posted: May 23rd, 2010 | Author: Jan Gorman | Filed under: Code, Hint | Tags: , , , , , , , , | No Comments »

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?


Zend Framework Classloading Performance

Posted: August 25th, 2009 | Author: Jan Gorman | Filed under: Code, Hint | Tags: , , , , , , , , , , , , , , , , | No Comments »

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.