Blog

Just a quick tip because I'm working on a different git workflow at the moment with one of my clients, and it struck me that this usage pattern is something I don't usually write or speak about at all. Most git setups have one "main" repository, and either:

• there is a gatekeeper that manages merging to here

• all developers have write access

In this case, I'm working with the second option, so I'm pushing to the upstream repo. I'm also pushing to a live repository as well, so I thought I'd outline the commands I'm using. The setup here is the main github repo, and I have my own fork of that, which is cloned onto my laptop. I can push to both that main repo, which I'll call "upstream" (because the github documentation does and it makes sense!) and another repo that I'll call "live". All in all it looks something like this:

I am a huge fan of bit.ly and use their tools for a wide variety of different things. They recently did a big relaunch with some lovely new features, which are for the most part pretty good, but which are inaccessible in places. In particular, it seems that there aren't any short URLs for the bundles - which is annoying for me as I use that feature a lot!

To get around this, I used their API to make a page which lists my bit.ly bundles, and creates shortlinks for each of them (once you've created a shortlink for a given URL once, bit.ly just re-uses the same ones the next time you ask to shorten the same URL, so this is less silly than it sounds).

In case the code is helpful, I thought I'd share.

Just wanted to share news of an event that I'll be at in a couple of weeks: LAMP and Beyond. This event is organised by PHPNW and held at Madlab in Manchester on June 30th (it's a Saturday).

The idea is that we bring together a bunch of interested developers …

So recently I was working on some benchmarks for different versions of PHP, because I heard that PHP 5.4 is "faster" and since I'm a data geek I want to know how much faster! Now, PHP 5.4 is, in general, faster than PHP 5.3 but not twice as fast* unless you pick a use case which has been particularly optimised.

My first attempt at benchmarking the two versions produced this:

I'm a regular speaker at a variety of (okay, mostly technical, so not really that varied!) events, and I submit talks to many CfPs (calls for papers). Whenever this happens, I tend to look back at whether I have any existing talks that I gave and liked and which would be a good fit. I use my joind.in speaker page for this: http://joind.in/user/view/110 as it's simpler than dredging through my directory of talks/articles on my hard drive (this is now rather large and unmanageable!).

I've recently been thinking that I should also do a better job of linking through to the various talks I'm giving/have given - and at around the same time I was contacted by the good folk at mojoLive about integrating against joind.in. To cut a long story short, the joind.in API now has the functionality for users to retrieve their list of talks!

This week, someone sent me a very large file using something called faspex. To begin with, it sent me a link to click on to download my file, but then started telling me "for best results, install a plugin". And apparently "for best results" means "to download this file in any way".

I spun up the simplest example I could think of to illustrate a recursive function to a PHP beginner the other day, and I thought I'd share. I often don't post really basic content but I should - people are beginning to be beginners all the time, after all!

It feels like I've tried to field the question about how I can use the web without using a mouse (or trackpad or equivalent), without "pointing", multiple times in the last couple of weeks. The answer is quite visual so I thought I'd share. This is how the web looks …

In July, I'm speaking at OSCON. Actually I have a few interesting speaking engagements coming up, and I haven't got around to adding upcoming dates to my blog yet but I'll be at phpDay in Verona next week with a talk on API Design and DPC in Amsterdam in June with a tutorial on Web Services and a talk on what OAuth is actually for.

OSCON is special because I have always wanted to go and never imagined it would actually happen. Every year I read the list of sessions from the year before, and decide that I absolutely must submit to the call for papers, regardless of how small I think my chances of being accepted are! I've submitted a couple of times in the past, excluding last year because I was newly freelance (OSCON does not cover any speaker expenses at all, they just give you a conference pass. That's kind of hard going for those of us self-funding halfway across the world, and last year, I just couldn't do it. This year I still can't really justify it but I'm going anyway!)

I've been hearing great things about puppet, chef, vagrant, and friends for a while now, but since I work on my own I tend to either develop straight onto my ubuntu machine or grab an appropriate existing VM and use that. So I read about this brave new world of virtualisation but (as with most tools) they can be hard to introduce on your own, and I didn't.

Then I went to WhiskyWeb, which had a hackathon. I'm unclear on exactly what happened because my attention was elsewhere but it seems like @JayTaph showed off puppet and vagrant to @deizel*, who immediately built a vagrant setup for joind.in, which is an open source project that I'm currently leading. With the shiny new technology all packaged for me, I decided it was time to take a look!

I wrote recently about deployment and I got some followup questions about managing database changes when you've got multiple versions of code hanging around.

There are two things you need to come to terms with:

• There is no silver bullet

• Rigid process is required

Someone emailed me recently, having read my book and wanting some advice. Here's a snippet of his email:

So here's my problem.

We dont know deployment. We work from same copy on one test server through ftp and then upload live on FTP.

We have some small projects and some big collaborative projects.

We host all these projects on our local shared computer which we call test server.

All guys take code from it and return it there. We show our work to clients on that machine and then upload that work to live ftp.

Do you think this is a good scenario or do we make this machine a dev server and introduce a staging server for some projects as well?