Using an Existing Vagrant Setup for PHP Development

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! Continue reading

We Don’t Know Deployment: A 4-Step Remedy

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?

I wrote him a reply with some suggestions (and my consulting rate) attached, and we had a little email exchange about some improvements that could fit in with the existing setup, both of the hardware and of the team skills. Then I started to think … he probably isn’t the only person who is wondering if there’s a better way. So here’s my advice, now with pictures! Continue reading

Apache Config: .htaccess or Virtual Hosts?

How to set apache configuration for your web projects? Some settings have to be in the main apache config or in a virtual host, but for many others you have two good choices; either use an .htaccess file, or place the setting in the vhost (virtual host) configuration. Which one you choose depends largely on your project setup, let’s look at each in turn:

The .htaccess File

The biggest item in favour of an .htaccess file is that it belongs in your webroot, and can be checked in to your version control tool as part of your project. Particularly if your project is going to be installed by multiple people on multiple platforms, this can be a very easy way to get development copies of code set up very quickly and for it to be easy for developers to see what should be in their .htaccess files.

With version control, you can also send new .htaccess configuration through by updating your copy of the file – but whether this is a strength or a weakness is up to you to judge! If everyone needs different path settings, for example, and is constantly overwriting your .htaccess file, that’s not a particularly excellent setup! Previously I’ve distributed a sample .htaccess file with a different file name, and added .htaccess itself to the ignore list of the version control tool.

The Virtual Host

Putting settings in the virtual host allows an easy way to configure the environment on a per-server basis, and not to accidentally deploy an incorrect setup. You could still distribute a sample vhost setup for people to use as their basis, exactly as you could for .htaccess.

The biggest reason for using the virtual host, especially on a production server, is that using .htaccess incurs a performance penalty. When you use .htaccess, apache looks in the current directory for an .htaccess file to use. It also searches in the parent directory … and that parent directory’s parent directory … and so on, up to the root of the file system. Imagine doing that on every request to a system under load!

Which To Choose?

It completely depends. At one end of the system, the open source project that will be set up on a relatively large number of systems by potentially inexperienced people – you’d probably choose .htaccess. For a large-scale, live platform deployment, use the apache settings themselves (a virtual host for a server which runs multiple sites – apache’s own settings for a server which only hosts a single site). Where are you on the scale and which will you choose?

Adding Custom Headers to Every Request with Chrome

I’m working on an API which uses OAuth2, but it also has an HTML output handler so I actually do quite a lot of my development in the browser for read-only stuff (I wrote an earlier article about output handlers including the HTML output handler). I fell across an extension for Chrome called ModHeader (WTF kind of URL is that, google?) which does this trick for me!

Once I have the access token, I add the Authorization header using ModHeader and it sends it on all requests to this API, so I can still use my HTML output handler and be logged in. It’s useful for sending custom headers of all kinds for different tools, so I thought I’d mention it!

Book Review: MongoDB and PHP

Despite having been toying with MongoDB and PHP for quite a while, I’ve only just picked up and read the “MongoDB and PHP” by Steve Francia, published by O’Reilly (disclaimer: I’ve collaborated with Steve on a few articles and he sent me a copy of the book to read)

Continue reading

Using OAuth2 for Google APIs with PHP

I’ve been working on something recently where I’m pulling information from lots of places onto a dashboard. Each API has its own little quirks so I’m trying to write up the ones that weren’t idiot-proof, mostly so I can refer back to them later when I need to maintain my system!

I’ve written about Google and OAuth before, but that was OAuth v1.0, and they are introducing OAuth2 for their newer APIs; in this example I was identifying myself in order to use the Google Plus API (which turns out not to do anything you’d expect it to do, but that’s a whole separate blog post!). Continue reading

Using JIRA’s REST API to Create a Dashboard

If you read this blog often, you’ll know that I am:

  • crazy about APIs
  • living with some accessibility issues

Put these two things together and what do you get? Actually don’t answer that! Today what you get is an example of integrating with JIRA’s REST API, because their recent “upgrade” locked me out of the issue listings pages completely and I really do need to be able to see a list of bugs! Their bug editing screen is quite usable, so it’s just the list that I need here, but you could easily call their other API methods as you need to. Continue reading