1. cd into your PEAR installation directory
2. Make backup of phpunit file in bin folder
3. Edit the original file, replace #!/usr/bin/php with #!/Applications/MAMP/bin/php5/bin/php
4. 3. Also remove this:

   
   if (strpos('/usr/bin/php', '@php_bin') === 0) {
       set_include_path(dirname(__FILE__) . PATH_SEPARATOR . get_include_path());
   }
   

5. And finally, something that Mark didn't mention, add PEAR include path into /Applications/MAMP/conf/php5/pear.conf

• exporting the project locally,
• zipping it up,
• moving it to the server,
• unpacking and symlinking it, to finally
• run a small script that would set the correct production config, chmod log and cache folders etc.

In the following article, I'm going to describe how I went from there to deploying my Zend Framework-driven PHP apps with Vlad. To save yourself some time, feel free to skip the back story, the pre-requisite of installing ruby, gem and rake, or go straight to the deployment recipes.

I did the above method for a while, and realized quickly how much time is wasted by this process. Remembering my efforts of deploying PHP apps with Capistrano, I felt it was time to set up an automated deployment routine. While re-reading the article, thoughts returned of how unwieldy and badly documented Capistrano came across, and I started looking for something more lean, that wouldn't scare of my non-ruby colleagues who might have to do my job when I'm away.

Very quickly I was lead to Vlad the Deployer, replacing one deployment app where the person in charge of the name had one tipsy field day with, well, another.

Taking it for its first spin, I felt that while there's a lot of confidence behind Vlad, the word "simple" crops up lots of times, but again, the documentation is a bit of a thinking man's manual; As soon as you go beyond the initial example it skips a few steps here and there, which can leave someone who is unfamiliar with the concept struggling. Maybe it's a case of "it's advanced stuff, just live with it".

Luckily I have my Capistrano experience, so I got started fairly quickly using Vlad for my own purposes. What I liked immediately about Vlad was that it declares as one of the project goals to "use the right tool for the job (ssh, rsync, etc)."

My initial goal was to use Vlad

• to have a deployment one-liner,
• to roll back if needed, and
• to be able to share logs and other assets between releases

For the example below I created a demo Zend Framework application with Zend_Tool, but what I'm describing should work for any PHP app out of the box, actually for any app, if you add any potential server tasks yourself. This example is using Subversion, but there is other examples out there that'll tell you how to use it with Git and other SCM software.

Setup

To be able to deploy with Vlad you need to have the following 4 things set up:

1. unix/linux development platform with SVN

not much to add, Vlad works on Mac OS X and various linux flavours, but not under Windows. For this setup I'm assuming you're working with SVN.

2. server with SVN client

Your webserver should be able to work with SVN, and it should be able to reach your SVN repository.

3. install vlad dependencies

on OS X 10.5 you already have a rails installation coming with the developer tools; just do

% gem update rails

Alternatively and on earlier OS X, you can use MacPorts, to install Ruby with

% port install ruby

You might also be able to use fink, and on debian/ubuntu you can install via aptitude

% sudo apt-get install ruby
% sudo apt-get install rubygems

For other platforms and compiling from source see here:
http://www.ruby-lang.org/en/downloads

Next you need to install Rake. For all systems, to update gem and install Rake, do the following. You don't need to gem update if you started from scratch:

% gem update --system
% gem update

Gem may fail initially - if so this is due to a bug in the gem command and requires you to edit the gem script (found with the command which gem on the command line, it's probably in /usr/bin/gem) by adding to the require statements (under require 'rubygems'):

require 'rubygems/gem_runner'

And finally, to install Rake itself:

% gem install rake

There are 3 more dependencies,

• Hoe
• Rubyforge
• open4

but they're installed automatically with the next step.

4. install vlad as a gem

To install vlad as a gem, all you need to do is

% sudo gem install vlad

while allowing for dependencies to be installed, which is set by default. Congratulations, you're ready to configure Vlad.

Pre-Configure

As Vlad is working closely with your system tools, you should set up your SSH for it first. You need to make sure the remote user is set up correctly, and you'll want some way of not having to enter your password a million times. Luckily I wrote about this recently. For the server I'd like to deploy to I added this. You might not need the ControlMaster/ControlPath, the important line is to set the remote user:

Host myserver.pretendco.com
    ControlMaster auto
    ControlPath ~/.ssh/master-%r@%h:%p
    User remoteuser

Now let's have a look at the server itself. There is a possibility that the web directory isn't writable by your remote user and you need to have root permissions. As you should use the root user for all this, and sudo croaks on remote commands, it's best to set your future releases directory to be owned by your remote user.

on the remote machine

% sudo chown remoteuser:remotegroup /path/to/releases/directory
% chmod 775 /path/to/releases/directory

Configure and Deploy

Next you need to create 2 files for Vlad: A Rakefile in your root directory, and a deploy.rb config file in application/configs. Your project should look a little something like this (yes, this is slightly abbreviated):

 |-application
 |---configs
 |-----config.ini
 |-----deploy.rb  <-- just created
 |---controllers
 |---models
 |---views
 |-library
 |-public
 |-Rakefile     <-- just created

At its core, the Rakefile is very straight forward; I've lifted the initial loading step more or less from the Vlad documentation, with the exception of setting the path for deploy.rb manually. Should your application have a root folder /config, you're following default convention and won't need the instructions in the curly braces. Further down I'm resetting the :update_symlinks task to link to shared logs and media folders, as well as linking the Zend library into my library. By default Vlad would set 3 shared folders: /log, /system and /pids, which I am all omitting here.

require 'rake'
require 'rake/testtask'
require 'rake/rdoctask'

begin
  require 'vlad'
  Vlad.load {:config => 'application/configs/deploy.rb'} # set path for deploy.rb
rescue LoadError
  # do nothing
end

namespace :vlad do
  # Clear existing symlink task so that we can redefine.
  Rake.clear_tasks('vlad:update_symlinks')

  # we've only got log to share
  remote_task :update_symlinks, :roles => :app do
    run "rm -Rf #{latest_release}/log && ln -s #{shared_path}/log #{latest_release}/log && chmod -f 666 #{latest_release}/log/*"
    run "rm -Rf #{latest_release}/public/media && ln -s #{shared_path}/cache #{latest_release}/public/media"
    run "rm -Rf #{latest_release}/library/Zend && ln -s #{shared_path}/Zend #{latest_release}/library/Zend"
  end
end

Next up is deploy.rb, the config file for the to-be-deployed app. The only 3 mandatory lines in all cases are :domain, :deploy_to, and :repository.

set :application, "Example application"
set :domain, "pretendco.com"
set :deploy_to, "/project/example_releases"
set :repository, 'http://svn.pretendco.com/example/trunk'
set :svn_cmd, 'svn --username svnuser --password svnpwd'

The default SVN command is svn, but in my case the SVN user is different to local and remote user, and for some reason the SVN password prompt from within the deployment step kept failing on me, so I added it right here. Not the safest thing in the world, but I'm using a limited read-only SVN user for these purposes, so that's good enough for me. Any suggestions of improvement are welcome.

For your convenience I have zipped up both files, or if you like, the whole demo project.

The first time you run vlad, you do

% rake vlad:setup vlad:update

You can skip the additional vlad:migrate vlad:start mentioned in the vlad documentation, as we're neither migrating DBs (this time), nor does Apache need to be restarted.

vlad:setup has now created a folder structure on your server that looks like this (abbreviated again):

 |-project
 |---example_releases
 |-----current           <-- link to your web application
 |-----releases
 |-------yyyymmddhhiiss  <-- your web application
 |---------application
 |---------library
 |-----------Zend        <-- link to Zend Framework
 |---------log           <-- link to shared logs
 |---------public
 |-----------media       <-- link to shared media
 |-----revisions.log
 |-----scm               <-- folder used to checkout release
 |-----shared
 |-------log
 |-------media
 |-------Zend

vlad:update has exported your application from the HEAD of your SVN repository, pushed it into a release folder, and pointed /current to this release. This means once you've verified this initial deployment step you can set your Apache webroot to point to /project/example_releases/current. You can also see that the folders /log, /public/media and /library/Zend have been symlinked, so you'll want to move all your dynamically created files into the shared folder now.

As a side note, I've had two major criticisms about this, out of which I have fixed one in this example: The first one was that initially I didn't include Zend Framework in my release, but rather added it to the global include_path on the server. "Your applications should be self-contained!", Pascal was shouting from his desk, including some expletives. The other thing he flagged up was that the version of my application config checked into SVN was set up for the live environment, so that I didn't have to change a thing when deploying. I have fixed this in the meantime as well, with a set of other convenient changes, but you'll have to be patient for me to write my next post about it and stick with this solution for now.

The good news are that you're ready to go now! To release a new version:

• check in your changes into SVN
• make sure that the repository URL in deploy.rb points to the same as yours
• run % rake vlad:update to deploy your app
• put your feet up, and enjoy the rest of your day.

If your release is broken, roll back with

% rake vlad:rollback

This will remove the last release and symlink to the previous version.

As a final word of warning: Using any means of deployment that rely on your code versioning software mean that you have to keep it clean. Only check in code you've tested locally, don't use the branch you deploy from as a backup mechanism. If you and any other people working with your code follow this advice, Vlad will save you lots of time, and turn the pain of updating a site into the joy of releasing something new.

Gavin Sinai put up a code snippet in the PHP.net reference, which shows how to set the error handler to get rid of it:

<?php
function HandleXmlError($errno, $errstr, $errfile, $errline)
{
   if ($errno==E_WARNING && (substr_count($errstr,"DOMDocument::loadXML()")>0))
   {
       throw new DOMException($errstr);
   }
   else
       return false;
}

function XmlLoader($strXml)
{
   set_error_handler('HandleXmlError');
   $dom = new DOMDocument();
   $dom->loadXml($strXml);   
   restore_error_handler();
   return $dom;
 }

?>

What is the problem?

Unit tests for database driven models are relatively straight forward. Usually we connect to a separate database, containing a known set of data. Since we know the data we can run assertions against it.

However, unit testing models that talk to web services presents us with a different set of problem. Usually our application runs requests against something that is not in our control. Unless the service provider gives us some kind of test mode, we're operating with dynamic live data which shouldn't be used for testing, since it's harder to test in the first place, but also could be harmful to be manipulated.

Let's have a look at two strategies to test out models.

Mock objects for Services

If we are using an object to represent the API calls to the service from within our model, i.e. Zend_Service_Delicious, we can swap this object for a mock object. A simple accessor allows us to overwrite private properties of the object:

class DeliciousModel {
  private $delicious;

  public function __construct() {
    $this->delicious = new Zend_Service_Delicious('username', 'password');
  }

  public function getPosts() {
    return $this->delicious->getAllPosts();
  }

  public function setProperty($name, $value) {
    if(UNITTEST_CONTEXT) {
      $this->$name = $value;
    }
  }
}

Now it's easy swap out private properties from within a unit test:

public function testDeliciousModel {
  $mockPosts = array('foo', 'bar');    

  $deliciousMock = $this->getMock('Zend_Service_Delicious', array('getAllPosts'));
  $deliciousMock->expects($this->once())
          ->method('getAllPosts')
          ->will($this->returnValue($mockPosts));
  
  $model = new DeliciousModel();
  $model->setProperty('delicious', $deliciousMock);

  $posts = $model->getPosts();
  $this->assertEquals($posts, $mockPosts);
}

Of course this would mean that we're not launching any requests to our services at all, but instead check that models are doing the right method calls to the service API object, and get the right data back.

Validate service requests

Generally speaking, models that are using web services will transform method calls into HTTP requests against web service end points. Those might come in a variety of flavours, but all together we can say that, if we can intercept the request, we can make sure the model serializes method calls correctly into known request data.

Test adapter for Zend_HTTP calls

If our model uses Zend_Http to launch the API calls, we might provide a hook in the model so that we can swap the HTTP adapter for the test adapter that ships with Zend Framework. We then have access to the entire request that the model launched, which we can use for assertions:

public function testJsonCall() {
  $adapter = new Zend_Http_Client_Adapter_Test();

  $response = "";
  $response .= "HTTP/1.1 200 OK" . "\r\n";
  $response .= "Content-type: application/json" . "\r\n";
  $response .= "\r\n";
  $response .= '{}';

  $adapter->setResponse($response);

  $model = new JsonModel();
  $model->setAdapter($this->adapter);

  $request_raw = $model->http_client->getLastRequest();
  // do your assertions here
}

Swap the endpoint

Instead of changing the adapter to intercept the call, we could swap the endpoint of the web service against a mock service. This endpoint then can respond with known data which we can use for our assertions.

Depending on what kind of web services we have to mock, we might use the servers provided by Zend, e.g. Zend_Rest_Server or Zend_Soap_Server.

A better understanding

Looking at the two strategies above, it still might seem to be a hassle to do, what is essentially a replication of the web service functionality with test data, whether that happens as mock object, on the request/response level, or as test endpoint.

But instead, this exercise is a very valuable documentation of ones understanding of the service functionality at a particular point in time. Given that service APIs are often in a constant state of change, things might break in the future, but the tests we've written can help us understand whether it's down to our own code or the web service instead. If things fail at the web service level, we can now refer to our tests to compare what we expect the service to do with what it actually does.

Related Links

• Unit Testing Code which Consumes SOAP Services
• Mocking with SoapUI
• Unit Testing with Stubs or Mocks

So, for myself as much as everyone out there, here is my collected useful knowledge that has helped me ease the pain of remote work.

1. Execute commands remotely as one-liners

This is what some deployment tools such as vlad use, but for a quick look at something, it cuts out valuable seconds you could look at web comics instead.

Let's try a simple example:

matthias:~ matthias$ ssh remoteuser@myserver.pretendco.com ls -l
remoteuser@myserver.pretendco.com's password: 
total 804
lrwxrwxrwx   1 remoteuser remoteuser      31 Nov 10  2007 access-logs -> /links/to/my/access-logs
drwxr-xr-x   2 remoteuser remoteuser    2048 Apr  6  2008 cgi-bin
-rw-r--r--   1 remoteuser remoteuser  808417 Jul 17  2007 error_log_dump
drwxr-x---   3 remoteuser mail     2048 Oct  1  2007 etc
drwxrwx---   7 remoteuser remoteuser    2048 Apr  4 02:33 mail
drwxr-x---   3 remoteuser remoteuser    2048 May 23  2008 public_ftp
drwxr-x---  30 remoteuser nobody   2048 Dec  4 06:33 public_html
drwxr-xr-x   7 remoteuser remoteuser    2048 Sep 24  2008 tmp
lrwxrwxrwx   1 remoteuser remoteuser      11 Apr  1  2006 www -> public_html
matthias:~ matthias$
		

You can even pipe through to a remote command. Here's an example taken from Look Here First, where the content of a local file is concatenated to a remote file.

matthias:~ matthias$ cat localfile.txt | ssh remoteuser@myserver.pretendco.com "cat - >> remotefile.txt"
		

2. Add your public key to your remote server

Next let's see how we can get around typing our password all the time. One way of doing this is to add your public key to your remote server.

# first, upload public key from client to server
client$ scp ~/.ssh/id_rsa.pub remoteuser@myserver.pretendco.com:~

# next, setup the public key on server
server$ mkdir ~/.ssh
server$ chmod 700 ~/.ssh
server$ cat ~/id_rsa.pub >> ~/.ssh/authorized_keys
server$ chmod 600 ~/.ssh/authorized_keys
server$ rm ~/id_rsa.pub
		

Of course, we can combine with the previous example and run it like this:

matthias:~ matthias$ cat ~/.ssh/id_dsa.pub | ssh remoteuser@myserver.pretendco.com "cat - >> ~/.ssh/authorized_keys2"
		

Windows users fear not, you can do this too, with PuTTY and PuTTYgen.

3. Let the ControlMaster handle your sessions

Sadly this might not always possible, maybe your key management on your server is different, or you don't have permissions to the file.

Luckily you can get around this by letting your first ssh connection act as ControlMaster. By adding the following to ~/.ssh/config, you only need to enter your password once, and all parallel sessions won't ask for a password

Host *
    ControlMaster auto
    ControlPath ~/.ssh/master-%r@%h:%p
		

4. Set your user and hostname for your host

Finally, more often than not your username won't be the same on your local machine and on whatever server you'd like to connect to, or your server might not use the default ssh port. Or maybe you're just tired of typing that superlong domain name, and look for a less challenging typing task. ~/.ssh/config to the rescue.

As final example:

Host myserver
    User remoteuser
    Port 22022
    HostName myserver.pretendco.com
		

Most likely you won't need the Port instruction in there, because your server runs ssh on the default port 22, so just drop the line.

All this allows us something as compact as:

matthias:~ matthias$ ssh myserver mycommand

Have fun, and let's hope this got you into your weekend early!

The Basic Idea

The initial thought behind this is that a model should be able to return calls either uncached or cached, without initializing some cache object every time. It should be easy to switch between the two calls, and the cache should be coming with the model object already.

The old way

Before introducing the cache pattern, I would create an object that then would use Zend_Cache_Frontend_Class, then initialize a new instance of my model in there, then redefine a method that acts as somewhat like a proxy, but uses the cache. And if that wasn't enough, I'd have to initialize them both, like in this example:

$model = MyModel();
$model_cached = MyModelCached();

$values_direct = $model->doStuff();
$values_cached = $model_cached->doStuff();

The new way

So Matthias asked me: Would it not be nicer if the cache was already available in the model, and you could do something like this:

$model = MyModel();
$values_direct = $model->doStuff();
$values_cached = $model->cache->doStuff();

A great idea. As you can see this proposed way saves a bit of code, it's intuitive and easy to change, if you ever need to switch between cached and non-cached calls.

The Code

First we need to create an object that initializes the cache. We'll initialize a cache with Zend_Cache and then utilize the __call function to check whether a call exists in the cached object or not. This enables us to only do valid calls.

class BaseModelCache {
  private $object;
  private $cache;
  
  public function __construct($object) {
    $backendName = 'File';
    $frontendName = 'Class';

    $frontendOptions = array(
      'lifetime' => 1800,
    );

    $backendOptions = array(
      'cache_dir' => '/my/cache/dir/',
    );

    $this->object = $object;
    $frontendOptions['cached_entity'] = $object;

    try {
      Zend_Loader::loadClass('Zend_Cache');
      $this->cache = Zend_Cache::factory($frontendName, $backendName, $frontendOptions, $backendOptions);     
    } catch(Exception $e) {
      throw($e);
    }
  }
  
  public function __call($method, $args) {
    $class = get_class($this->object);
    $class_methods = get_class_methods($class);

    if(in_array($method , $class_methods)) {
        $caller = Array($this->cache, $method);
        return call_user_func_array($caller, $args);
    }

    throw new Exception( " Method " . $method . " does not exist in this class " . get_class($class ) . "." );
  }
}

The second step is to create a base model class, that we'll use for all our models. It will initialize the cache object using the BaseModelCache and make it available as public property:

abstract class BaseModel {
  public $cache;

  public function __construct() {
    $this->cache = new BaseModelCache($this);
  }
}

Et Voilà! Now we can create models by extending the BaseModel. The cache will be available as described above.

Install PHPUnit

Zend Framework integrates with PHPUnit. PHPUnit is a PEAR module, and the usual way is to install PEAR that first and then use the pear installer to install PHPUnit for you.

Create an application bootstrap include

If you're using the front controller pattern and have all your variables set up in the index.php of your web folder, now is the time to move things into an include file, before you create the controller and dispatcher. We'll use this very file when doing unit tests with Zend_Test

Start Testing Controllers

With the help of Zend_Test we're now able to create tests that dispatch our controllers. We're then able to do assertions against the response, using the provided methods of the ControllerTestCase.

class IndexTest extends Zend_Test_PHPUnit_ControllerTestCase
{
  public function setUp() {
    $this->bootstrap = array($this, 'appBootstrap');
    parent::setUp();
  }

  public tearDown() {
    $this->resetRequest();
    $this->resetResponse();
    parent::tearDown();
  }

  public function appBootstrap() {
    require_once('/my/bootstrap.php');
  }

  public function testHomepage() {
    $this->dispatch('/');
    $this->assertController('index');
    $this->assertAction('index');
    $this->assertXpath("//form[@action = '/foo']");
  }
}

Manipulate the request, evaluate the response

Now that we've dispatched our controller, we can manipulate the request and access the response, to see what the dispatched action does. For example an action that requires post data, and then redirects us to another page:

public testPostAction() {
  $request = $this->getRequest();

  $request->setMethod('POST');
  $request->setPost(array(
    'foo' => 'bar',
    'baz' => 'x',
  ));

  $this->dispatch('/my/post/action');
  $this->assertRedirectTo('/my/expected/redirect');
}

Checking data manipulation

If we're working with data manipulations in our tests, we could use models to create the data we manipulate, and then to evaluate it after the controller has been dispatched. Finally we'll clean up after the test. Of course you'd want to have stable models at that point.

public function testSave() {
  $my_id = $model->create();

  $request = $this->getRequest();
  
  $request->setMethod('POST');
  $request->setPost(array(
    'name' => 'unittest modified',
    'id' => $my_id,
  ));

  $this->dispatch("/save/object/");
  $this->assertRedirectRegex('#/edit/object/id/[\d]+$#');

  $data = $model->get($my_id);
  $this->assertEquals($data['name'], 'unittest modified');
  
  $my_id = $model->delete($my_id);  
}

Related links

• Zend_Test Reference Guide
• An Introduction to the Art of Unit Testing in PHP
• PHPUnit: Testing Zend Framework Controllers
• Zend_Test: how to set up?

<?php
class Translate extends Zend_Translate {
  public function _() {
    $args = func_get_args();
    $num = func_num_args();
    
    $adapter = $this->getAdapter();
    $args[0] = $adapter->_($args[0]);
        
    if($num <= 1) {
      return $args[0];
    }
        
    return call_user_func_array('sprintf', $args);  
  }
}

Usage would be something like the following:

$t = new Translate('array', $array_translation, $lang);
echo $t->_('My name is %s', 'Pascal');
echo $t->_('I have a %s and a %s', 'Cat', 'Horse');

I started out with pie charts, and essentially did a mashup between Jon Combes approach and Advanced Canvas Based Pie Chart by Matthew Knott, then wrapped a JQuery plugin around it.

Later I added some sidebar charts, which were much simpler to do and don't require to understand the fact that javascript does trigonometric functions in radians rather than degrees, a fact that made my brain boil when I tried to add in the labels, because I was expecting different numbers to come back from my calculations ...

I was keen on passing the chart values in as array, so I could gather data from an HTML table with a couple of lines of JS, for example. I left this out in the little demo that I mocked up, which I uploaded as a zip file as well, but I am sure you guys figure what I mean.

The whole thing is nothing new, and Plotkit or Bluff are way more advanced, but I think it's a nice little demo to read and understand, without being overwhelmed by large files of code. So I hope you enjoy it.

public function validationErrorPerl($content) {
  $hash = md5(microtime() . $content);
  $infile = CACHE_DIR . '/validation_' . $hash . '.pl';
  $outfile = CACHE_DIR . $this->config->cache->dir . '/validation_' . $hash . '.txt';
  file_put_contents($infile, $content);
  $cmd = "/usr/bin/perl -c $infile 2> /dev/null &> $outfile";
  exec($cmd);
  $result = file_get_contents($outfile);
  unlink($infile);
  unlink($outfile);
  $result = str_replace($infile, 'perl script', $result);
  
  if(strpos($result,'syntax OK') !== false) {
    return false;
  }
  
  return $result;
}

While I was able to build a quick interface for a python script to do essentially the same, using the PyObjC bridge and the Interface Builder, I couldn't figure out how the hell I am supposed to get the authentication going to execute the script as superuser ... and a look into the documentation does give no clue on how to use Authorization with PyObjC, but only shows a C function ...?

Apart from that I found the Interface Builder pretty intriguing, and I'm starting to like XCode as well. Of course I haven't got much of a clue of how Python is done properly, and especially the underscore convention for actions threw me off at first. Also, what do people mean when they say Pythonic? What makes an app/script/library exactly that?

Of course I am way out of my comfort zone here. Would appreciate some hints and guidance.

To avoid the latter, I've never stopped learning, reading up on how it's supposed to be done, and trying to see the benefit in generalizations others have suggested.

Web Standards and the people that actively try shaping them is such a subject. Over the years I've followed a number of blogs and web publications, and looked at how they do it, taking on suggestions when they seemed to make sense, trying to work out the benefits when the don't. Lucky me, living in London, even had a chance to see, and at times even chat to some of them, the people who seem to have so many good ideas.

One of them is Dean Edwards, who I've met several times at the Pub Standards, when his and my occasional attendance overlapped.

Now, he's forgotten to renew his domain, and the reminder didn't reach its intended target. That's kinda stupid, but I can confirm that although it has so far not happened to me, I'm uncomfortable about this subject every 2 years, because my registrar has such a bad user interface that I'm never sure if it updated credit card details, if a changed status means that everything is (going to be) ok, etc. (feel free to suggest a registrar that tells me in simple words where I'm at)

Maybe I'm just too forgiving, but imagine: Somebody who has been publicly, on the web and elsewhere, trying to standardize and improve his work universe, forgets something important. That's crazy, and clearly deserves a telling-off, throwing everything in except the kitchen sink.

Oh, it's so funny, I have to quote it here (who knows, maybe it'll be taken down). So, on the erroneously titled subject of a lost-and-snatched domain with unlicensed content replication, someone called "gmn17" had this to say:

man oh man what happens to you guys?, you and the quirksmode guy and the stu nicholls guy, you guys get burned out and then whore yourselves out and can't handle what you created and started, putting down people for using tables and innerhtml like the guy who explains how different the internet and the world wide web are so different, trying to create an atmosphere of holier than thou web design and make people feel like crap for using tables and document.write, it's hard to feel sorry for you, you yourself said many times on that site that you only use it sparingly or can not update it as frequently, and that stu nicholls guy, man what a sellout, someone needs to tell him his javascript is horrible, you just have to be patient, I always liked your site too, lots of nice stuff, can't believe you can write code like that and get into a situation like this, what a world,

Amazing! I mean, it's hilarious, it looks so menacing! I wanted to only quote one sentence, but, there is no full stop. I'm interpreting a lot of pent-up anger in there, and the chance of a lifetime. Ironically, his comment wouldn't have been too out of place at Ajaxian, where a discussion about CSS (or tables)for layout was reheated and served.

I'm sure you'll find a lot of flak in the comments, too, maybe even some condescending advice. But as far as I read, they only get as personal as "you're probably a backend dev" or the general denial of professionalism on the part of the original author. A great week for making the web a better place, that's for sure.

Prerequisites

Open the Terminal and execute the following commands:

sudo sed -i -e s@^#Include\ /private/etc/apache2/extra/httpd-vhosts.conf@Include\ /private/etc/apache2/extra/httpd-vhosts.conf@ /private/etc/apache2/httpd.conf

This will enable the vhost include file to be read from the httpd conf.

sudo sed -i -e s/^\</#\</ /private/etc/apache2/extra/httpd-vhosts.conf
sudo sed -i -e s/^\ /#\ / /private/etc/apache2/extra/httpd-vhosts.conf
sudo sed -i -e s/^#NameVirtualHost/NameVirtualHost/ /private/etc/apache2/extra/httpd-vhosts.conf

This will enable the Virtualhosts in apache.
Now let's enable PHP as well:

sudo sed -i -e s@^#LoadModule\ php5_module@LoadModule\ php5_module@ /private/etc/apache2/httpd.conf

All we need to do is restart apache:

sudo apachectl restart

Adding a vhost

Now we're all set, and can create the shell script in some location of your choice. In the example below it's assumed that it is called add.sh.

The shell script itself:

#!/bin/sh
#
# Script to validate files in directory
#
add_host_entry() {
	echo "127.0.0.1	$1" >> /etc/hosts
}

add_vhost_conf() {
	cat localvhost.tpl | sed "s/{VHOSTNAME}/$1/" | sed "s@{VHOSTDIRECTORY}@$2@" >> /private/etc/apache2/extra/httpd-vhosts.conf
}

if [ $# -lt 2 ]; then
	echo "syntax: sh add.sh vhostname vhostdir"
	exit
fi

add_host_entry $1
add_vhost_conf $1 $2 

The template file 'localvhost.tpl' needs to sit in the same folder like 'add.sh':

#VHOSTSTART {VHOSTNAME}
<VirtualHost *:80 > 
	DocumentRoot "{VHOSTDIRECTORY}"
	ServerName {VHOSTNAME}
	ErrorLog /private/var/log/apache2/{VHOSTNAME}-error_log
	CustomLog /private/var/log/apache2/{VHOSTNAME}-access_log common
</VirtualHost>

<Directory {VHOSTDIRECTORY}>
	Options Indexes Includes FollowSymLinks SymLinksifOwnerMatch ExecCGI MultiViews
	AllowOverride All
	Order allow,deny
	Allow from all
</Directory>
#VHOSTEND {VHOSTNAME}

You should now be able to add vhosts by typing:

cd /path/to/shellscript/folder
sudo add.sh vhostname /path/to/vhost/webroot

Once you're done do an apache restart again:

sudo apachectl restart

• First, download the appropriate version of the APC package
• Unpack it (doesn't matter where)
• Now start Terminal and cd to the unpacked directory from the above step
• Run 'phpize'
• Now it needs to be configured. Copy the following configuration (note: it must be entered into the Terminal prompt as a single line)

MACOSX_DEPLOYMENT_TARGET=10.5 CFLAGS="-arch ppc -arch ppc64 -arch i386 -arch x86_64 -g -Os -pipe -no-cpp-precomp" CCFLAGS="-arch ppc -arch ppc64 -arch i386 -arch x86_64 -g -Os -pipe" CXXFLAGS="-arch ppc -arch ppc64 -arch i386 -arch x86_64 -g -Os -pipe" LDFLAGS="-arch ppc -arch ppc64 -arch i386 -arch x86_64 -bind_at_load" ./configure

• Nearly there: now type 'make'
• sudo make install (you will need to enter your root password)
• Finally, add 'extension=apc.so' into your php.ini

And that's it!

To me this doesn't come as such a big surprise, since I have been raving about it ever since I got myself a cheeky login without invitation code, something that a google search will reveal If you can't get the latter.

It's no often that I do big up an application, but spotify seems to do everything right that other music players didn't quite achieve. For example, I really liked last.fm, but I always wanted to be able to search for a track and then play the album.

Even more amazing that it does get things right that I didn't even ask for. Already my listening behaviour has changed, because I started to use Spotify's direct URLs and collaborative play lists. Let's just wait an see what else is coming in terms of nifty integration.

Also let's hope that they don't screw it up big time. Already they had to remove some tracks, and the potential to bomb the application with adverts until everyone tunes out is huge. If they get it right it might be as much of an important app like the iplayer or hulu.