Like most web developers, I managed a bunch of domains, applications, and services. Some of these are projects for myself, some are for family and friends, some are for clients. And it's a mess, stuff on one shared hosting, stuff on some other shared hosting, stuff on the VPS I use to muck around. This makes it all difficult and time consuming to manage, not to mention fraught with risk.

I've decided it's time to get my house in order, bring everything I can together onto a quality VPS and manage things properly.

Whenever I've managed servers, I've quickly forgotten how I've installed stuff and how the thing is configured, and everything gets messy and out of control, so the idea of managed and versioned configurations is very attractive. There are two main options around, puppet and chef. A very much surface assessment suggests that puppet seems to be more popular and have more documentation, and I had more luck getting it up and running than I did with chef, so that's what I'm going to explore.

In the end, I want a VPS with:

• SSH with SSH keys set up
• a web server, probably Apache at this stage
• several virtual hosts
• PHP and Ruby
• MySQL and Sqlite
• git and subversion
• vim
• zsh
• utilities such as ack, find, and curl
• projects cloned from github
• monitoring and alerting (I don't know anything about this stuff yet, but I'm guessing that's Nagios)
• appropriate backup
• and of course, versioned configuration

I'd also like to be able to:

• easily spin up local VMs with the same base configuration as the VPS

Unfortunately, I haven't been able to find much to support such a small endeavour, most information seems to be about large teams and large projects. If you know of good resources, please let me know. I'll update this post as I work out more of what I want to achieve and how to do it (I may even split this into multiple posts).

Replacing parts of a string is something we want to do quite often, but unfortunately MongoDB doesn't currently have a simple way to do it. There's a bug that I hope will be accepted and make this post out of date by the time you're reading.

db.coll.update(
  {'entry' : /hate/},
  {$replace : {'entry' : ['hate', 'love']}}
);

This would replace the string hate with love in the value of the field entry, where the string to find could also be a regex.

So, that doesn't work yet. Instead, we can do this.

db.coll.find({'entry' : /hate/}).forEach(function(e) {
    var parts = e.stem.split('hate');
    e.stem = parts.join('love');
    db.coll.save(e);
});

This will find all the entry fields and loop through them. For each field, the value is split on the string hate, and we then join the split parts back together around the replacement string, love.

Not quite as elegant, but it works.

I just bought A Book Apart's Designing for Emotion and Mobile First as a bundle. In fact, I've been buying all the titles from A Book Apart as they become available.

I buy them because they're about things that interest me, they're well written and readable, they're concise and fluff-free.

But most of all, I buy them because the authors all just seem like such nice people.

I'm teaching again for the first time in a long time, a course with the romantic and evocative name of Web Page Construction. This means that instead of my thoughts being a swirling morass of bits and pieces, of jquery, user testing, code quality, and responsive design, I need to try to organise things up there. You can probably see from the design of my blog that I'm not a designer, I'm a geek who wants to get better at the non-geek stuff.

The first thing I'm trying to answer for myself is, what does it take to make a web site? The common answer when teaching this in a computer science context is that you throw some HTML, CSS, and Javascript together, with varying degrees of care. And at a very high level, that might be a reasonable technical answer, but it definitely shouldn't be the whole story.

My answer is that there are three broad steps to making a web site:

• Work out what you need to do and how to do it well.
• Implement things based on your planning.
• Work out how to do things better.

The final important thing about this process is that it's cyclical, so the "make it better" step feeds back into "work out what it's about". There should definitely be at least a full iteration before a site goes live, and after the site is live you have access to much more data in the final step. You might also choose to have a staged "go live" step, opening up to a few real users before you throw the doors open to all your target audience, so that you can take advantage of the extra data for another iteration or two.

Work out what it's about

You can't build anything until you know what it's for, so the first step is to work out what you're trying to achieve. Who are the target audience, what are their needs, and how will you meet them? A useful technique is to develop personas, fictional people that represent the major users of the site. If this is a site you're creating for someone else, talk to them about what they want and get their help to develop the personas and their goals.

In the context of the personas and their goals, consider the functional requirements of the site, what it should do, and the data required to make that happen. Think about how the users will interact with elements of the user interface.

I can't stress how important it is to talk to people. The least effective development process is "tada development"¹ where you turn up to a client with a "finished" system and hope that it will magically meet their needs.

As I said, this isn't just something that happens at the start of the project, you need to make sure you carefully plan what you're doing each iteration. It also doesn't just have to be about user interfaces, it could be about planning what technologies are most appropriate for the particular needs of the site, or how to solve a performance issue you've discovered in the "make better" step below.

Build stuff

The actual stuff that gets built depends on where you are in your iterations. At the start, this step should include sketches or prototypes of the planned user interface, then you might mock up some HTML and CSS, maybe add some interactivity with Javascript. It could even be implementing database replication and sharding to solve that performance issue.

Make it better

Each step of the way, you should be gathering data to see if what you've built so far is meeting the goals you set out to meet, and to identify where you're going wrong. Those prototypes you built? Show them to people and get feedback. Perform some user testing to see how real people actually use the interfaces you've built. If you're not sure that your new and improved interface actually makes things better for people, do some A/B testing and get some hard data.

You can get all sorts of data freely through services such as Google Analytics or what elements of your user interface people click on with services like the not-free CrazyEgg. Or work out what's slowing down your users' experience with Google Page Speed or YSlow.

There are hundreds of things you can analyse and measure, which can in turn feed back into the next iteration and help you meet the goals of your users. And if you're anything like me, the data itself is a source of fascination.

My explanation of these steps is not supposed to be exhaustive. In fact, many, many text books have been written about each one and it wouldn't even be fair to say I'd scratched the surface.

The Web Page Construction course I've inherited definitely focusses on the middle step, and that's fine. My job when teaching the course is to make sure that it's clear that the technical detail should be taken in the context of all three steps. We'll see how I go with that.

1. Thanks to Donal for this phrase. ↩

It's been an exciting couple of weeks in research land. I finally got my "You may adopt the title 'Doctor'" letter (yes, I was actually a little premature last time but it was at least inevitable at that point) and my thesis is now online.

So have a look if you want to know about Effective Retrieval to Support Learning.

I've had a casual interest in usability and user experience for a while now, but up until now the interest has been passive: reading widely and observing friends and family use web sites.

Yesterday, however, I was involved in my first user testing session. I've been reading Steve Krug's Rocket Surgery Made Easy, which I highly recommend for getting started with user testing, so I had a reasonable idea what to expect. But I was still shocked at how glaringly obvious important usability issues seemed after less than half an hour with someone who hadn't used the software before.

Wow, the top navigation menu is completely invisible!

Now to work out how to get more user testing happening for open source projects.

PHP quality background.

Laura is the co-author of the hugely successful PHP and MySQL Web Development, and a Senior Software Engineer at Mozilla Corporation. Thanks for being the first respondent, Laura.

In terms of PHP, what does quality mean to you?

This is a great question, and one I often ask in interviews.

Quality PHP is free of the usual set of code smells. It's been
through code review and has a set of meaningful tests with a
reasonable level of code coverage. It has minimal but sufficient
documentation. You can detect good quality PHP by looking for:

• happy developers
• new developers becoming productive quickly
• other users forking or contributing to your projects
• your application being robust and not failing in odd and intermittent ways
• devs are able to modify the code and add features quickly, without forensic spelunking to understand how it works
• your code lacking that fragile library that nobody wants to maintain or modify in case they break it

What tools and processes do you use in your development to ensure quality?

The main things we do are:

• Patch review. (This is common among open source projects.) Writing code that you know will be read by others ups the quality in general.
• Security review for new projects or features.
• Continuous integration and automated test-on-build.
• Mozilla's awesome WebQA team run a set of automated tests using Selenium, fuzzers, and also do a lot of manual testing.

Are there tools or processes that you'd like to include in your toolbox that you haven't used yet?

We're looking at moving towards continuous deployment during the next few months and are currently exploring the requirements for that.

The great thing about PHP is that it lets people put together web sites easily and quickly. Along with the vibrant community, it's one of the main reasons for the language's popularity. A side effect of this ease of production is that PHP hasn't developed a culture of quality, in the business sense.

What do I mean by quality? That software does what it's supposed to do, reliably and repeatably. It's maintainable and it's not fragile, so isn't prone to breaking when changes are made. Despite the lack of a culture of quality, some of the biggest web sites on the Web use PHP, and internally they must have processes to ensure quality.

I'd love the quality tools and processes to become more widely used in PHP, and so I've asked three questions of a bunch of Important People in the PHP community, people I respect and admire. In terms of PHP, what does quality mean to you? What tools and processes do you use in your development to ensure quality? Are there tools or processes that you'd like to include in your toolbox that you haven't used yet?

I'll post responses as I get them.

Laura Thomson

If you have a suggestion of someone I should ask, please let me know; identica, twitter, email

Vic was a superb boss — his response time on email was under 5 minutes …

Exit interview: Jaiku's Jyri Engeström - (37signals)

Five minutes! That's definitely impressive, if your job is to be responsive to email.

Vic may very well be a superb boss, but responding to email quickly is an incredibly poor way to gauge your boss's performance. The boss should be providing a vision, communicating strategy to the team, making sure that everyone is working towards shared goals. Sure, they might also be dealing with discontent or malcontents, putting out fires, or keeping an eye on the stock price, but if they're sitting around waiting for your email to come in so they can respond to it quickly, they're probably not doing the important stuff.

Tweaking CSS on sites developed by other people seems to be something that comes up at least weekly in web development. Why isn't my footer displaying properly? Why is this div wrapping? Often it's me asking those questions, but every now and then I can solve someone else's problem with a CSS tweak or two. CSS Pivot, which I discovered via a post from Chris Coyier, is a site that lets you share those tweaks with other people.

I thought it looked useful, so I make a bookmarklet to send the current page to CSS Pivot. Drag it to your bookmarks.

Open with CSS Pivot