I had no idea could pull ddebug_backtrace() to get an instant stacktrace, or DARGS() to see the arguments being passing into a function at any point, or DD() to log directly to a text file (which you can tail in a terminal window to see stuff as it happens).

Now, if only Simpletest wasn't so depressingly slow...

It's pretty handy - it allows you to step your code when things break, giving you an idea of what exactly is happening, under the hood, or letting you understand the actual a request takes through your code.

I'm not using MAMP, because where possible, I'm trying to minimise duplication of software on the my computer, and previously I've confused myself something horrible with trying to keep track of multiple instances of MySQL and Apache before, so if you're not using MAMP, following these instructions should help get you set up with a decent debugging tool, on Snow Leopard, and along the way get a fairly maintainable lamp stack, if you're not enamoured with MAMP.

Get PHP 5.2

This isn't strictly necessary, but right now, I've found PHP 5.2 to be less hassle when developing than 5.3, and for time being, Drupal and WordPress to be standardising on it first before moving to the newer version, which means I am too.

The best instructions I've found to do this are here PHP 5.2 for compatibility with Drupal, and provide a good introduction to the amazing Homebrew, which you really should be using instead of Macports or Fink, if you're not already.

Lets get the hard commandline work out of the way first.

Setup PEAR to complement Homebrew's PHP 5.2

Just like how we have pip or easy_install with Python, CPAN for Perl, and Rubygems for Ruby, with PHP, we have PECL, and PEAR. PEAR is repository of PHP classes, like PHP Unit for unit testing, whereas PECL is a repository for C extensions like APC or Memcache, that help with performance, and caching, or link to other programs.

By default we do have PEAR and PECL installed, but in keeping with Homebrew's example of storing stuff in /usr/local/ to avoid needless sudo'ing we're going to use our own versions of PEAR, using this handy one liner. What's happening here is that we're using curl to fetch the data at http://pear.php.net/go-pear, and then streaming it into the php command:

    curl http://pear.php.net/go-pear | sudo php

We'll be presented with some text, once we've entered our admin password, along the lines of:

  Welcome to go-pear!
 
  Go-pear will install the 'pear' command and all the files needed by
  it.  This command is your tool for PEAR installation and maintenance.
 
  Go-pear also lets you download and install the following optional PEAR
  packages: PEAR_Frontend_Web-beta, PEAR_Frontend_Gtk2, MDB2.
 
  If you wish to abort, press Control-C now, or press Enter to continue: 
 
  HTTP proxy (http://user:password@proxy.myhost.com:port), or Enter for none::

We probably don't need a proxy, so you can just hit enter, at which point we'll be asked the following:

  Below is a suggested file layout for your new PEAR installation.  To
  change individual locations, type the number in front of the
  directory.  Type 'all' to change all of them or simply press Enter to
  accept these locations.
 
   1. Installation prefix ($prefix) : .
   2. Temporary files directory     : $prefix/temp
   3. Binaries directory            : $prefix/bin
   4. PHP code directory ($php_dir) : $prefix/PEAR
   5. Documentation base directory  : $php_dir/docs
   6. Data base directory           : $php_dir/data
   7. Tests base directory          : $php_dir/tests
 
  1-7, 'all' or Enter to continue:

We want to change the installation prefix, to make sure we're putting this stuff into /usr/local - I found that I had to do this explicitly, because the default value for $prefix, ended up with me getting build errors.

Once we've added this, we'll get a load of text flying past as PEAR is built, and end up with some text saying something like:

    WARNING!  The include_path defined in the currently used php.ini does not
    contain the PEAR PHP directory you just specified:
 
    If the specified directory is also not in the include_path used by
    your scripts, you will have problems getting any PEAR packages working.
 
    Would you like to alter php.ini ? [Y/n] :

Why yes, we would like this added. This will add this snippet to your php.ini file:

    ;***** Added by go-pear
    include_path=".:/usr/local/PEAR"
    ;*****

One important thing here - now that you have this, make sure your PEAR

Now, any thing you add to pear will be available in future, so installing PHP Unit for unit testing is as simple as calling this on the commandline (note):

  pear install phpunit/PHPUnit

In a similar fashion to Rubygems, these libraries of classes are available by calling require_once as if you were in the path /usr/local/PEAR, so to pull in PHP Unit, you just type:

  require_once 'PHPUnit/Framework.php';

Setup PECL with PHP 5.2

Now that we have PEAR setup, we should spend a it of time on making PECL simple to administer without sudo. All I needed to do here was check that everything in /usr/local/Cellar/php52/ belonged to my normal user account, by calling:

    sudo chown -R /usr/local/Cellar/php52/

This does away with the need to compile things as root, and makes installing extensions like Memcache, Mongodb, APC, as simple as:

    pecl install apc

If you find yourself having trouble here, you may want to check the permissions on any extra directories created during the PECL installation process - I had a couple of issues because some extensions had been installed as root earlier when following Hunter Ford's instructions at Cupcake with Sprinkles, which stopped my user account being able to install into the nested directory structure, because my account was trying to put files into directories owned by root.

Fetch Xdebug

If we didn't need xdebug, this would be all we needed, but sadly things aren't as simple as that. If we try calling something like pecl install xdebug, we DO get a version of debug installed, but it's not quite what we need, and doesn't seem to do anything useful. If we want this to work with MacGDBp, we need to install the version compiled by the chaps at Active state from their Remote Debugging page, that's designed to work with their own IDE, but also other tools. Once we've downloaded the tar file, we need to choose the correct version,

And then copy it to where the other extensions are:

    cp xdebug /usr/local/Cellar/php52/5.2.13/lib/php/extensions/xdebug.so

And make the relevant changes in our php.ini file for them, to point to the xdebug shared object (that's the .so suffix on extensions), and provide a few defaults as directed on the MacGDBp help page:

  ; Adding xdebug
  zend_extension=/usr/local/Cellar/php52/5.2.13/lib/php/extensions/xdebug.so
  xdebug.remote_enable=1
  xdebug.remote_autostart=1
  xdebug.remote_host=localhost
  xdebug.remote_port=9000

In short we're telling xdebug to switch on by default, and and listen on localhost:9000 for any clients that want to connect to it when we want to inspect what's happening with code.

Finally turning on MacGDBp

Still with me? Good. At long last, we can finally start looking through code in our debugger. Fire up MacGDBp, and when you run your next PHP script, you should get to see something like this pic pilfered from Particle Tree's own post on this subject:

There's far more to this, but in general the key to using the debugger is knowing how to set breakpoints, and remembering that your choices in the blue buttons are (from left to right)

• stepping into functions to see what's happening as a request is passed from function to function
• stepping out when you no longer need to see what's happening in a particular function
• ...and stepping past a particular function, without needing to look into its working at all

The green button is a fast-forward button, to take you to the next breakpoint you might have in the code, and the green power button is analogous to a power button, to refresh a connection to the debugger. You really, really should look into this post here by Tim Sabat at Particle Tree, and this one here by Matt Butcher, at TechnoSophos.

Debugging without MacGDBp

Of course, you don't need to use MacGDBp all the time, In most cases, just having a stack trace will help find the source of the error. Once you've got xdebug setup, you should get a handy track trace whenever you throw an error - if not, be sure to make sure you have the display errors setting set to 'on' in your php.ini setting (it should be around line 370 in your file, normally):

    display_errors = On

By the time you've followed these steps, you should have an easier to main installation of the LAMP stack, with a simple way to install extra PHP libraries and C extensions, a couple much more effective ways to debug than simply typing echo $variable everywhere, and an ideal environment to get on with hacking on Drupal, WordPress and any other PHP code in future.

Phew!

This guide is largely a synthesis of earlier blog posts about this subject by Justin Hileman, Matt Butcher, Tim Sabat, Hunter Ford, and Boris Gordon, I'd recommend subscribing to their blogs, as they definitely know more about PHP than I do, and they're a great source of handy info.

If there's anything that isn't clear, please let me know, so I can improve this guide - I don't want anyone else to have to blunder through working out all this themselves in future, as working all this out has taken, far, far longer than I'd like, and well, it seems churlish not to share now that I've got a setup that seems fairly stable.

Now, time to actually do something useful with it...

It does feel at first like an extremely cynical move from Apple, degrading the user experience of an existing handset this dramatically around the same time as launching a another shiny new expensive handset with four times the memory - but truth be told this is nothing new with Apple - if you own a mac, you'll be aware of their 6 month product cycle already, so seeing this happen with the iPhone is hardly earth shattering. Lame yes, but not shocking. The main saving grace is that there is still a downgrade path back to iOS 3 if Apple can't release a new update in the coming few weeks that sorts out the performance issues.

In the meantime, there's a few steps here you can take to minimise the ridiculous slowness, listed on lifehacker - there's no guarantee they'll work, but there seems to be at least some kind of placebo effect in place, since I switched off spotlight indexing when I tried a few of them just now.

If the slowness of the new OS hasn't put you off of staying with your existing iPhone

As I mentioned before, I took out a contract with 02 a little less than than two years ago now, and if like me you're looking for a sim only tariff, Orange and Vodafone both offer extremely similar deals, though it looks like Vodafone just about edge out Orange. Both offer tethering at a surprisingly reasonable rates.

You can pay a fiver for half a gig of tethered connectivity if need be, and 15 quid for 3Gb of data, which is the same as what they charge for internet access using their 3G dongles normally, but Vodafone's data cap is slightly higher at 1Gb per month instead of 750mb, and their network is generally seen as the most reliable in the UK .

If you want to lock yourself into a twelve month contract, you can get the sim only deal from Vodafone for a fiver less too, at £20 per month, which is about as reasonable as we're gonna see iPhone sim-only pricing get, while still providing some decent coverage.

Goodbye O2 - it's been a fun 4 or so years, but your network is just too flaky to see myself using in the near future. Lets talk again when you have reception again near Shad Thames.

_Update - I want with Vodafone in the end, and bought it through their website. I don't know why I waited so long until I did this to be honest...

Normally after a transplant operation, our bodies' immune systems would attack any new organ placed inside a body because they see it as a foreign body that must be destroyed before it can do any further damage to us, which is precisely what we don't want to happen when we've replaced a diseased malfunctioning one, with a new healthy one.

To avoid this, patients need to take immunosuppressant drugs, that, as you'd imagine form their name, inhibit these defence systems, allowing the new kidney to work without being rejected by the body.

The problem with immunosuppressants

Sadly these aren't without side effects, and as a rule, you really want to have your immune system at full strength to avoid infections or general illnesses. So transplant patients often end up spending the rest of their natural lives in a somewhat debilitated state as a result of these drugs.

Some people however, have immune systems can develop a tolerance to the newly transplanted organs, meaning they'd be free to live lives free of the side effects from the immunosuppressants, if it weren't for the fact that coming off medication runs carries the risk of killing them if it turns out that their bodies weren't as tolerant as they thought after all.

Coming off the drugs

However, one of the outcomes the research project I was in was the discovery of a chemical signature in patients who may carry this tolerant trait. As we get better at detecting this trait, more people may be able to live lives either free of these drugs, or with much lower dependencies on them.

Why am I writing any this?

To be honest, I had pretty much forgotten about being involved in this project, and the only memories I have are of almost passing out like a total pansy when giving the blood sample ( I needed to drink loads of sweet tea , and sit with my feet up until I felt well enough to stand...), but this month, I received a letter telling me that the study had been published in the Journal of Clinical Investigation, with a few snippets of the press coverage.

And, well... I do feel like a bit of a douche writing about this here, because it I can easily sound like that guy who reminds you about how much they give to charity they are, or how much they like to recycle and so on, and how wonderful a person they are.

But the pleasure and the feeling of pride from the letter far outweighs any potential embarrassment I might feel, especially if it helps persuade anyone else to volunteer for any similar medical research projects.

If you have the time, and you're a healthy person, I'd really recommend volunteering like this - it's incredibly fulfilling, and even including my comical fainting episode, we're talking a total time outlay of maybe two hours of my time, to help someone else live the rest of their life free from the side effects of drugs that they might not even need to to be taking.

So, in short - yay science!

This post outlines the approach we took when migrating content from one site to another on a recent project, as the documentation available currently this could be much clearer, and this is clearly a problem that others working on the web are likely to have in the near future, as people realise just how how much you can do with WordPress, and move more sites to it.

As mentioned before, we had to move a fairly large site across from one content management system based around ColdFusion a modified version of WordPress this month, making sure we didn't break any the links amassed over the last few years the site had been online.

If we were dealing with just a few urls, we could do this by hand using Apache's more well known [RewriteRule][] directives, but with than 5500 links to preserve, this approach just isn't realistic. We need a different tool for this.

Enter RewriteMaps

Fortunately, Apache RewriteMaps are designed specifically for these situations. As you'd expect from the name they allow you to map one url to another without needing to write the same ReWriteRule snippets thousands of times.

Anything that cuts repetition reduces the chances for typos to slip in, and makes it easier to maintain in the long run, so RewriteMaps are a handy tool to add to your reportoire.

How to use a ReWritemap

I find it helps to think of using a rewrite map as a 4 step process:

• create the rewritemap

• define the rewritemap inside an apache conf file

• define what conditions you want to test the map against

• define what you want to do with the return value of the rewritemap, and redirect accordingly

Now, in more detail....

Create the rewritemap

The mapping file cam be as simple a plain text file with pairs of values, separated by at least one space, like so:

 
/content/press		        22
/content/jobs		        23
/content/contact		    24
/content/accessibility		25

Whitespace isn't significant, so you can happily go for readability here.

Define the RewriteMap

Now that we have a mapping files we need to let Apache know that we'd like to us it:

 
    RewriteEngine on
 
    RewriteMap url_rewrite_map txt:/srv/html/domain.com/domain.migration.map

We've told Apache to switch on its url rewriting features (RewriteEngine On), and declared the urls the text file as the patterns to match against.

Define what conditions you to test the map against

Now it's time to actually use the rewritemap:

 
    RewriteCond ${url_rewrite_map:$1|NOT_FOUND} !NOT_FOUND

This condition definitely needs some unpacking.

RewriteConditions in Apache are designed as tests to see if a RewriteRule should be applied, depending on whether the expression they're testing returns true. RewriteMaps work by passing a value into them, like how we have with S1, but they also a fallback value in case an expression didn't match any of the patterns in the url map file declare earlier, which should explain that the NOT_FOUND is doing inside the curly braces.

So far, we're testing if we have a corresponding value for the captured pattern passed in (which would return true), and returning NOT_FOUND if there's nothing there.

However, we only want to apply the url rewrite if the we have a match in the map, and as it stands both values return will return 'true' here. This will create an infinite rewriting loop, so we need to add a ! operator to check if the value is NOTFOUND or not, and only rewrite the rules if the result is !NOTFOUND.

Yes, we really did just test for not NOTFOUND.

I'm sorry - I have a real problem with this; it's extremely confusing to read, and utterly unintuitive, as well as just being bad english.

Sadly, this seems to have become a fairly common Apache htaccess idiom, and right now, I can't think of another way to express this that works using Apache's syntax. Any other suggestions would be gratefully accepted.

Define what to do with the results

 
    RewriteRule ^(.*) http://domain.com/?p=${url_rewrite_map:$1} [R=301]

This rule uses a regular expression to match the request sent to us, (that's the ^(.*) part), and then passes that through the urlmap, so a path for a content item with a unique of id "34", but a previous path along the lines of "/press/importantpressrelease" would have its numeric id returned again, giving us a rewritten url like "http://domain.com/?p=34".
In our case, the unique numeric id was the only constant we could rely during migration from one system to another; thankfully WordPress has some handy built-in rules of it's own that can convert these numeric id requests into nice friendly urls, along the lines of "http://domain.com/press/2009/06/10/important-press-release".

We're using a permanent 301 redirect flag with this ReWriteRule (that's the [R=301]), so that search engine spiders know to follow the link, retaining any search engine mojo we may have had before..

Conclusion

So, using the url mapping here, we now have a sufficiently fast way to preserve the integrity of old urls, without locking us into this structure for the future, without diving too deep into the Apache directive rabbit whole.

Gehl believes urban public space is the lifeblood of democracy, the essence of humanism, and the sine qua non of green-minded livability. “Throughout history,” he told me, “public space had three functions: it’s been the meeting place and the marketplace and the connection space. And what has happened in most cities is that we forgot about the meeting place, we moved the market space to somewhere else, and then we filled all the streets with connection, as if connection was the number one goal in city planning, in public space.”

What he means is that we replaced public squares with parking lots, enclosed and privatized our marketplaces as shopping malls, and then turned over our streets almost exclusively to rapid transportation by private vehicle. In so doing, we enslaved ourselves to oil, choked ourselves on exhaust, and shattered into a million fragments the public realm where civil society once flourished.

Copenhagen’s great lesson for the New Grand Tourist is that the essential first step, maybe the only critical one, in reassembling these shards and building the urban foundation of the Green Enlightenment is to put people ahead of their cars and public spaces ahead of private ones in the planning priorities of the city — of any city.

In this shining upbeat, version of Europe, power comes from decentralised microgeneration in people's houses, or majestic power sources like the Grand Spires of Solùcar in Andalusia, that that use focussed sunlight on steam turbines to generate electricity:

Solùcar looks like a sci-fi movie set, but it also comes off as ageless and permanent, almost obvious after a while. I was reminded of a one-liner I once heard the sustainable design guru William McDonough deliver. Whenever he meets skepticism about how far we can go with this Green Enlightenment, he said, he likes to point out that it took us 5,000 years to put wheels on our luggage. It took us only a couple of hundred to employ heat-concentrating mirrors in industrial power generation. The trail ahead is thick with low-hanging fruit. And the reason all of this is happening on the plain of Andalusia is not strictly nor even primarily because it is a very hot and sunny place; rather, it is because Spain was one of the first countries to pass a conscious imitation of Germany’s feed-in tariff.

In all, it's about as attractive a version of our current society I can see that still revolves around economic growth as a way to fix the world's ills. I'm not convinced this is how things will pan out, and I'd like to know what the less upbeat scenarios are too, which is why I'll be heading to the Dark Mountain next weekend.

That said, I don't buy into a all of the apocalyptic narratives that are associated with the Dark Mountain camp; I think there's a middle ground between them and the Green Renaissance Utopia described above, and I think I might get a better idea of what that might be after the weekend.

Maybe I'll see you there.

Why do I like it?

I think it's about as attractive as a code type tattoo is going to get

The proportions are well balanced, and there's a nice visual rhythm in there - this is largely down to the choice Bitstream Sans Mono, the typeface used for this. This typeface is a well loved font in programmer circles, who spend hours staring at monospace fonts - a lovely touch.

It's actually executable code

This particular incantation has its own story too - this cryptic combination of symbols is a working example of a forkbomb, and was presented as a piece of open source art back in 2002, by Denis Jaromil Rojo, an Italian Rastafarian developer and media activist now residing in Amsterdam. A forkbomb is a piece of self replicating code that when called, start forking itself relentlessly, until it consumes all the resources on a computer system, rendering it unusable.

For the terminally curious, here's how it works:

 
:()      # define ':' -- whenever we say ':', do this:
{        # beginning of what to do when we say ':'
    :    # load another copy of the ':' function into memory...
    |    # ...and pipe its output to...
    :    # ...another copy of ':' function, which has to be loaded into memory
         # (therefore, ':|:' simply gets two copies of ':' loaded whenever ':' is called)
    &    # disown the functions -- if the first ':' is killed,
         #     all of the functions that it has started should NOT be auto-killed
}        # end of what to do when we say ':'
;        # Having defined ':', we should now...
:        # ...call ':', initiating a chain-reaction: each ':' will start two more.

More on Forkbombs here.

That doesn't happen in banking. The huge barriers to entry mean that the big guys can continue to screw you over, secure in the knowledge that no startup can compete for your business. And of course the government will bail them out if they get into trouble. Here at BankSimple, we are hoping to shake things up a little. While we sit atop existing banking systems, we've got some great technology that hides much of the underlying nastiness and lets us bank in a more real-time fashion.

Moreover, their blog is already chock-full of great content, and actual useful analysis of the business now, and how the system currently works.

I have the same feeling about them, as I do about Dropbox - but sadly, I can't see the UK getting any clever financial services companies like this launch just yet (the closest would be Smile, but while their customer service is exemplary, they have the same creaking infrastructure that forces me to use wesabe and a load of other tools to make sense of what my money.

Check them out - I really think when they launch properly, you'll see some proper disruption in the financial sector at last.

Now O2 (I've been with them for more than 5 years, easy) haven't been terrible, but I've had calls drop on me, and where I work in Tower Bridge, reception is atrocious, but the market has changed since I bought a phone now, and I think there's a gap in the market that mobile operators are either ignoring, or don't want to publicise too much.

I don't need a new handset (and when I say 'need' I'm using the first world definition of 'need' here) - nothing out now is better than the iPhone 3G to the extent that the iPhone was better than the rest of market when I bought my first phone, and I can't see that changing anytime soon.

Now I'm going to outline a plan that I think should exist, but I can't see anything that fits this description:

1. I don't use the phone too much to actual phone conversations (no more than say 300 minutes tops probably)
2. I don't need visual voicemail or anything like this (Hullomail gives me everything I'd need now, and Google Voice as another alternative)
3. I do use my phone for watching videos, using twitter, and reading my choice of content online.
4. I'd like to use any data on my plan as a data I can use on when my laptop is tethered to it; I paid for it after all, right?
5. I'm okay with data not being 'unlimited' here, because I understand the how geeks are basically subsidised by lighter users anyway, but if I pay for a couple of gigs of data, _I want to be able to use it. _

Generally, paying more than £40 per month feels like subsidised phone territory here; for £5 more, O2 were throwing in a whole iPhone on a previous contract 18 months ago for example, so paying that much for just bits leaves a terrible taste in my mouth.

The closest thing I see are Vodafone's sim only tariffs, but they're not clear about tethering with iPhones (point 4 above).

I can't be alone here in being a iPhone user who isn't slavishly devoted to the newest shiny from Apple, but doesn't want to pay over the odds for using my phone in a different way to how most operators expect me to, and would prefer to use what they have in smarter ways, rather than buying more gadgets and dongles that'll end up in landfill in about 18 months time.

Is there anything else like this hypothetical tariff around? I really think there should be, and I'd it did, I'd join it in heartbeat.

This meant I had to use the zip tool, which I can never remember how to use, hence this memory jogging post.

Now if someone's using a Mac or is on Linux, the normal command line approach to to tar up a directory to send to someone goes like this:

tar -cvzf my_tarfile.tar.gz a_directory_to_tar and_otherone_here

We're calling tar here, with the -create (c), file (f), compress (z) oh, and the verbose (f), flag. Think of that string like saying to the computer: "create the tarfile my_tarfile putting it into a file we just created, verbosely, while compressing it, from a_directory_to_tar and and_otherone_here".

As commands go, the order feels a bit weird at first, but you get the hang eventually.

Where zip is different

Using zip isn't too different really, but it you need to remember to tell it to zip recursively (why is this not default behaviour?). If we call command:

zip archive a_directory_to_tar and_otherone_here

We'll end up with an rather useless empty file called archive.zip. We need to pass in the recursive flag

zip -r archive a_directory_to_tar and_otherone_here

There's also no need to add the .zip file extension - this is added for you as a courtesy. Well, after that ridiculous non-recursive default shenanigans, frankly that's the least it could do...

Anyway, there you have it. The differences you between them if you don't want to dive into the manpages just to package up a folder for somebody, or look at this linux.about.com.