I navigate the web using the Keyboard Navigation extension in Google Chrome, which is what is adding all the little labels you see in the screenshot above. Install the extension, and press comma. The labels will pop up, then you type whichever character(s) show next to the thing you want to "click" on, and off you go.

It's super-simple, and easier to use than I expected. Why don't you try it out on your own sites? You'll get a sense of how the web looks from where I'm standing :)

Lorna is an independent web development consultant, writer and trainer, open source project lead and community evangelist. This post was originally published at LornaJane

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 have two talks, both of them brand new, and I'm excited about them both!

PHP 5.4 Features You'll Actually Use

When I told one of my local user groups (how excellent to have more than one local user group!) about this talk they said "that'll be a short talk" and I am a little worried they are right! Cool new array syntax, traits, and a web server ... am I missing anything important? To make this even easier and more fun, Rasmus has the slot immediately before mine and his abstract includes "a detailed review of new PHP 5.4 features". I feel like a spare part and I haven't even written the talk yet!

Get Some Rest: Best RESTful API Practices

This one will be lots of fun, because I firmly believe in writing services that make users, rather than textbooks, very happy. Which means that I do break the rules and I think there are times when that's acceptable. I suspect that there will be heckling, flaming, and foaming at the mouth involved but hey, I'm not there to be popular! Honestly, I love REST, I think it's possible to take it too far, and I'm only a little bit scared to say that in public :)

OSCON Conversations

OSCON does a cool thing where it opens the comments on a talk page immediately - which means that you can already go and ask questions, make requests, or leave comments on either my PHP 5.4 talk or the RESTful one and let me know what you do (and perhaps do NOT) want to hear. If you're going to OSCON or are just interested in the topics, I'm interested to hear your thoughts, either over here in the comments or over on the talks themselves!

Lorna is an independent web development consultant, writer and trainer, open source project lead and community evangelist. This post was originally published at LornaJane

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!

Starting the VM

The goal is that a user can simply grab the code base and type a single command:

vagrant up

When you do this the first time, then a "base box" is downloaded and puppet installs the various packages that will be used to run your platform. Once you have the base box, you can use it again with a different configuration; very handy for anyone working with similar-but-not-quite-identical projects. The setup process goes beyond the platform and also sets up the application with appropriate configuration files, databases created and so on. This is fabulous because if you break something, change platforms, or otherwise get into a tangle of any kind - you can just recreate your platform!

If you've run the virtual machine before, this command just starts the VM again so that you can use it.

Puasing Between Sessions

You probably don't want to leave the VM running all the time (I have a shiny new machine with enough RAM that I can if I want to, which is nice!), and just like any other virtual machine you can shut it off and restart it at the same point later on, using:

vagrant suspend

What I like about this is that it's so simple :)

Throw it All Away

If for any reason, either you broke something, or you have new puppet config perhaps, you want to throw away your VM and start again, that's easy to do:

vagrant destroy

We keep the base box, but throw away the actual VM instance when we do the above. This means that you get an entirely clean installation when you run vagrant up the next time, with everything reset to the way that it was. All the settings are very configurable so if you do end up making any changes on the VM, you can also make them in the configuration so that the next time you create the VM anew, those changes will be included.

Network Topology

Something I really liked about this setup, in comparison to the way that I usually do virtual machines, is that the VM shares files with the host machine. Joind.in is hosted on github, so I grab a copy of the repo, type vagrant up, and then just edit the files in the current directory as I normally would. I'm a vim user, so editing files on virtual machines has never really bothered me, but if you use a desktop IDE then this feature will make a big difference to the way that you work with it - and even for vim users, this eliminates the need for copying of .vimrc files and swearing at distros that install one leg of vi and call it good!

The vagrant box also knows how to connect to itself, so to get shell access you simply need to ask for it:

vagrant ssh

I think especially if you have a bunch of machines running, or potentially running, because all your development uses these platforms, this approach becomes increasingly valuable as you don't have to keep tabs on hostnames or IP addresses. When you are in the directory for this project, the command gives you access to this VM ... simple!

Shiny New Tools

It's always easiest to learn something new by looking over someone's shoulder (which is why I teach a tools course) and while I'm sure I'll be diving into configuring the virtual machines in detail over time, just having this setup to try has been a great way to get started and see how it could work, tweak a few things on my own copy and so on. Personally I'm delighted to have come across vagrant in such an approachable way - if you want to have a play yourself, then feel free to clone the joind.in repo on github to take a look at what we have there. Thanks again to all the fabulous contributors who make this project what it is and continue to educate me every day!

* I haven't figured out if it makes more sense to link to twitter or github when citing people who have done cool code-related things

Lorna is an independent web development consultant, writer and trainer, open source project lead and community evangelist. This post was originally published at LornaJane

bunoire14

(Olly Warren)

@lornajane @nabeels tips on starting to write an API to interact with Smartphone App?? :-s

On 2-5-2012 12:48:53 from Twitter for Mac in reply to Lorna Mitchell

I have lots of advice for Olly (whom I know personally) but there's no way it will fit into a tweet! So here it is, in rather longer form :)

Be Consistent

Whatever data format you pick, whatever app you are building, whichever approach you choose, be consistent. Your whole API should call things by the same name, use the same validation rules for everything, and accept parameters in the same order. Every time. Look out in particular for things like singular/plural names, mixing case and parameters which are sometimes optional.

Fail Really Really Excellently

Things will go wrong. This is the way the world works in general, and on the web in particular. Requests sometimes don't arrive, or the responses don't. Disks fill up, databases fall offline, all kinds of weird stuff does happen. All that matters is how you deal with it.

Make all your errors arrive in the same format as the successful response would have. This means that the client can parse it and understand what is there. If you feed HTML into something that wasn't expecting it, something unexpected will happen (actually PHP's json_decode() will cause PHP to segfault if you try hard enough).

Give meaningful error messages. This allows users to help themselves, continue to use your API, hopefully learn to love it - and all without having to bother you in the process. This is the holy grail of API creation!

Keep It Tidy

A Small API is easy to maintain and support, so try to keep your APIs as minimal as possible. Only write functionality that is really needed. Make things flexible so that clients can ask for more or fewer records than the default (especially if the data sets can get large!), and get the result set sorted sensibly - it's very expensive to do those kinds of operations on any kind of large data set on a small device.

Keeping this small is also keeping things simple, and the KISS principle is good advice for all areas of software design.

The Actual Advice

For a non-novice programmer, an API is a project that is absolutely approachable. For sending data to a smart phone, I'd recommend the following:

• JSON format - it's lightweight, easy to parse, and also relatively easy to debug if you need to
• RPC style - REST is much cooler, but it's hard to get started with if you haven't used it before, and bad REST just gets everyone upset. You already know how to declare and call a function - so make your API along those lines. Look at wikipedia's JSON-RPC page for some ideas
• Make sure you understand HTTP headers and status codes, and use them! Use Accept and Content-Type for sorting out data formats, status codes to say if things went well or not.
• I feel like there should be more advice here ... please add a comment if you know what else I should be telling Olly!

Tools to Help You

You'll be doing a lot of debugging, print_r($_SERVER) is a good place to start with understanding what requests came in. Use wireshark to make sure that you are sending and receiving what you think you are send and receiving. If you need to debug output but doing so breaks your client because it sends nonsense in the data format, use error_log instead.

Most of all, know this: if you can already build a website, you can build an API. Good luck :)

Lorna is an independent web development consultant, writer and trainer, open source project lead and community evangelist. This post was originally published at LornaJane

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

• There is no silver bullet
• Rigid process is required

If you're still reading, then I assume I haven't scared you off with the above, so let's get into the more practical side of things and look at the steps to follow for coherent database versioning ...

Hands Off The Database

If you are serious about keeping track of the changes to your database, then you will never make another change to it manually. Never. Not even the test or development databases, nor "to just quickly try" something.

When you want to make a change, make a patch script. Then when you run it against your development database and it works, you know exactly how to replicate the same excellent manoeuvre against any other platform that needs it - including sharing it with other developers in your team. The patches are included in your source control, but ideally not inside your web root (you don't want to serve these to the outside world!).

Identifying Patches

I wrote a while ago about how to work with database patches, and I'm using basically the same approach on most of my projects today. Each patch file contains: a comment on what this file does, the change(s) to make, and another SQL statement that records that this patch has been run for this database, and when that happened (I had a phase of recording only "latest patch" information but I now prefer a log of what was run and when).

What you name your patch files is up to you - I like sequential numbers but of course they do sometimes collide when branches are merged together so human intervention will be needed in that situation. We are smart and can handle this :)

Some changes can take more than one deploy to enforce - for example I recently deployed a major change to one of my own sites, which changed the database schema enormously and needed me to move data from one table to another. I wrote a patch to do that, and a separate one to drop the old copies of the data. The first patch was deployed with the relevant code changes, but the other patch is currently called "patch-future.sql" - it will be deployed once I'm certain the change is live and I won't need to roll it back (more on rollbacks in a moment).

Make It Painless

This is really a general piece of advice for deployment and other development process: make your preferred path the easiest choice. This does mean a bit of time automating the processes, but I have yet to regret spending time on these tasks. For database patching we'll write a script which will look at the database and the patch files, and run any that haven't already run. Anyone pulling in these changes only needs to run one script, and you can automate that step in your deployment stages.

Do observe this one golden rule: never edit a patch file after it has been pushed!

Tools for Database Patching

There are lots of tools that wrap up what you've seen here; but the basics are the same:

1. Do not touch the database directly
2. Write patch files
3. Record what patches are applied
4. Automate patching

I've used or heard good things about DbDeploy which integrates with Phing very nicely, Rob Allen's Akrabat_Db_Schema_Manager for ZF, so either of those is worth a look and if you have more recommendations, then please share them in the comments!

Rolling Back

As a final note, I will mention rolling back of database changes; this is a really tricky one and I haven't got any solutions that I think have been worth the hassle. Personally I like to do lots and lots of incremental changes, deploying as often as humanly possible (often several times each day) so large breakages are less likely. Academic theory says that for every forward patch, you should have an undo one, but practical experience tells me that this makes it harder to finish features and the rollbacks are almost never used. For my own projects (none of them especially high traffic or commercially critical) I have undertaken to run without any rollback scripts required. If the unthinkable happens (and it will, one day!), I will write the script to mend the damage as a new patch and deploy it. How you choose to approach this issue will vary hugely for different scenarios - what do you do?

Lorna is an independent web development consultant, writer and trainer, open source project lead and community evangelist. This post was originally published at LornaJane

Almost half of people recommended attending a user group, which makes me very happy. Organising user groups can be a bit of a drag, you need to be available on the same dates every month, book venues, round up speakers, and so on. It's something I've always enjoyed and I tend to "tourist" around and visit any UK groups that I can get to (or indeed any further afield if my schedule permits it), so I was delighted to see so many people suggesting this as a good way to advance. It's also a good night out usually, when I saw someone tweet about my next talk being in Manchester rather than Leeds, I had no hesitation in telling him:

lornajane

(Lorna Mitchell)

@TomWade just come and get the train over with us! I can promise you a good night out :)

On 26-4-2012 11:52:13 from TTYtter in reply to Tom Wade

Lots of other people were in favour of using free resources, and given just how excellent the free resources are in my area of expertise, PHP, that's absolutely sound advice. I do own a few books, but mostly I just ask google for whatever it was that I needed to know next - and I'll find it, on a blog, or stackoverflow, or something.

Paying for your own conferences/training was recognised as important by quite a few people, and I must say that this is certainly where I came from. The visibility let me get a job where I could attend more of these things, but at the start, I was just an attendee, tagging along to events and finding out more about the world.

Most interesting, perhaps, were the people who answered "other" and gave advice of their own:

• Speak at a conference
• leave the company for one which takes you seriously
• Work on a challenging personal project

I think I've done all of the above, and all of them have definitely brought rewards in ways that I couldn't even imagine. Thanks to all of you for the advice (I can't figure out how to see who recommended what, so we'll call it community wisdom) and for voting - definitely food for thought.

Lorna is an independent web development consultant, writer and trainer, open source project lead and community evangelist. This post was originally published at LornaJane

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!

Starting Point

This is basically the place we begin from:

The code lives on this staging server, when you need to make a change, you copy it onto your own machine, make the change, and put it back on the staging server. From here, it can be checked over before it is put onto the live machine over FTP.

The first thing to say is: this does work, as long as you follow the process exactly. But I was asked if I thought there was a better way, and I think there is. When I work with a setup like this, there is always a moment where I have no idea if I just copied over something, or forgot to copy over something, or ... you get the picture.

Step 1: Source Control

Use source control. That's the best advice I can give anyone. Use a hosted solution, install your own, pick Subversion or Git or Mercurial, I really don't care. But use source control.

Here's the diagram with the source control in place, using SVN as an example (but it makes little difference what kind of source control you pick)

Hardly anything has moved, but we've added a piece to the middle of the puzzle. At this point, there's a central repository where things are always kept, and always backed up. We have a history of changes, and can see who changed what. The developers can collaborate on larger changesets, and those changes can be committed to the repository even before they are ready to be placed onto the staging server, so you are much less likely to lose code when a hard drive dies.

To get the code from the repository to the staging and live servers, we can export a clean copy of code each time and upload that using FTP (or go one step further, SFTP). If you really must check out from source control repositories onto public servers, then make absolutely sure you are not serving the metadata that the source control product uses - since this is only step 1, that would be OK (but keep reading).

Step 2: Branches

Now we've gone to all the trouble of implementing a source control solution, we may as well make the most of the features that are now available to us. This means it is time to learn to branch. A branch is just another copy of the code, but isolated from the first one. Using branches means you can:

• always have an exact copy of the current live code available
• work on more than one feature (or bug fix) at once

You would use the same setup as above, but branching means you are able to do a great many more things without any fear of who changed what or whether you can commit without hurting things.

I could write another thousand words about branching, but I won't (well, unless you ask very nicely, and even then it will be written another time). Instead, look around for some resources for whichever platform you chose: the Red Bean Book is a great place to start.

Step 3: Automated Deployment

This is the jewel in the crown, especially if you run multiple sites. If you only run one site, no matter how complicated it is, you will eventually learn to get the deployment mostly right, most of the time. With multiple sites, they will all have differences and they will take turns to bite you when you least expect it (or, more likely, on Friday afternoon when you are trying to do three other things before pub o'clock). Automated deployment means fast, repeatable, painless deployment every single time.

To deploy, you probably need some kind of build process. I've got it here as a separate piece of the system as it's conceptually separate, but it could easily be as simple as a few scripts running on a spare box in the office (which might also run your SVN, for example), you don't need anything fancy.

There's the build server, right in the middle. When changes are available in the version control system, the build server will know about them. When you are ready, you ask the build server to deploy the relevant code to either live or staging, and it does that. Nobody else touches live. For any reason. If they do, their changes get lost on the next deploy - and anyway, automated deployment is so easy that there's no reason not to use the process!

Exactly how the code gets deployed is up to you; personally though I like phing, which comes with lots of tasks for dealing with source control and PHP-specific tools built in. It's relatively easy to get started with and you will set it up to follow the process which is currently documented on your company wiki (it is documented, right??). Mine goes something along the lines of:

1. export files from source control
2. compress files
3. transfer files to server
4. log into server, uncompress files
5. deal with database changes, upload files, and anything else which needs special attention
6. make the new code live by changing the symlink that your docroot points to

Yours may be a bit different, but this is all pretty straightforward to set up with phing, or you can write your own scripts if you prefer.

Step 4: For Bonus Points

By the time you've got source control and a build step set up, you have the basis for all of the cool tools - so try them out! Your "build server" can run other scripts as well, which makes it really a continuous integration server. You can get it to respond to changes in your version control and perhaps run some tests or generate the API documentation. You can add all kinds of preparation into the deployment steps, minifying JavaScript or CSS, stopping and starting worker processes; anything you can imagine!

Better than FTP

I'm not advocating using cool tools just for the hype; the recommendations here are the ones I use to protect myself from my own mistakes, hardware failure, projects with changing requirements, bosses with short memory spans, and all the other things that are part of everyday work. With branches in version control and some automated deployment, I can create and publish multiple changes in little more time than it takes me to write the actual code - which is really what I'm interested in!

Does this resemble your setup? Would you have given the same advice if you received this email? Let me know in the comments! (I'm sending a link to my original enquirer so it would be useful for him to hear your thoughts!)

Lorna is an independent web development consultant, writer and trainer, open source project lead and community evangelist. This post was originally published at LornaJane

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?

Lorna is an independent web development consultant, writer and trainer, open source project lead and community evangelist. This post was originally published at LornaJane