Skills Allied to PHP

This post is mostly about a tutorial I will be delivering at PHPNW on October 5th in Manchester, UK, and why I think a tutorial that contains no PHP belongs at a PHP conference

phpnw12 logoIn October, I'll be delivering a tutorial at the mighty PHPNW Conference which contains very little PHP. Why? Because I think, as developers, it's our other professional skills that suffer. As a consultant, I work with lots of different teams, and it is very rare for code to be the problem (and the one time it was, it wasn't the only problem!).

In web development, our biggest challenges are not writing code, we can do that. But getting the code safely from one place to another, with many people's work preserved, having our platform(s) correctly configured and understanding how to use them, making use of the tools in the ecosystem which will help us improve the quality of our code; these are the big challenges we face, and that's why I proposed this workshop and why I think all these topics are important. Continue reading

Monday Git Tips

One project I'm working on at the moment involves finding my way around changes in a codebase that isn't mine - and it's quite large. I was doing pretty well with a combination of git log and git show and in particular two of my favourite existing tricks:
Continue reading

Pushing to Different Git Remotes

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:


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

Speaking at Leeds PHP

On Monday 19th March I'll be speaking at PHP Leeds. The topic is all things git and github; as an open source project lead I see lots of very capable programmers taking their first steps with github. In this session we'll talk about how you can use these tools to contribute to open source (or your own projects, of course), covering both "what to click in the web interface" and "what to type at the command line" for git and github respectively. Come along if you want to know more about git, open source, or github!

Do-it-Yourself Peer Review

When I get asked about tools for quality assurance, I will pretty much always mention that the technology is not the answer. In my experience, the best improvements in quality come from process, from letting as many people as possible have access to all aspects of the system as early and often as possible (this is exactly why evolving projects "release early, release often"). A great tactic is to have another developer review each change - but what do you do if, like me, you work alone? Continue reading

Git Tip: What Did I Just Merge?

As a lead on an open source project, I spend a lot of time merging awesome contributions from our community into our main repo on github. Sadly, some of them are slightly less awesome (rarely but it does happen) and I sometimes need to unpick what happened to understand the problem and give good feedback. Since the project is hosted on Github, this means having some git tricks up my sleeve, and I thought I'd share.

I have the main repo cloned onto my local machine. Before I do anything, I fetch and merge from the origin and then push back to it, so I know my repo is in sync with the github one. Then I fetch the branch I want to merge - usually one that we've got a pull request for. To see what's in the branch:

git log [branch] --not master

This is nice because it doesn't show what's in the master branch of this repo but missing from the incoming branch, it just shows me what's new on this branch.

I can diff and merge at this point, but more than once I've merged and then wondered what changes I have in my repo that aren't in the github one (this is where it is helpful to have fetched from the remote one first). I have the github repo mapped as "origin" as per the excellent documentation so I can just do:

git diff origin/master..HEAD

This shows me the differences that are in my current repo as compared to origin/master, which is the tip of the main repo shown at the version it was when I last fetched it. I particularly use this when I've merged someone's changes in for testing and am wondering quite what was supposed to happen - sometimes just reading the diff beforehand isn't enough, it's only when I get the code merged I realise something unexpected is happening!

Speaking at PHP London, October 2010

In October I will be speaking at the PHP London user group on Thursday 7th at the Theodore Bullfrog pub in London. I'm giving a new talk called "The Source Control Landscape", looking at the products currently available in the source control arena, how the distributed systems have changed the landscape, and how we can choose between them all today. I'm really looking forward to the event, it's always a good crowd and I love to meet new people as well as meet up with existing friends - see you there :)

Migrating Github Contributors to an Organization

Recently, a github project that I contribute to, joind.in, moved from an ordinary github user account over to an organization. Getting contributors moved over is pretty straight forward, I have a fork of the main repo on github at http://github.com/lornajane/joind.in and that updated to show itself as being a fork of the organisation's repo rather than the original user repo that it had been set up under.

In fact, all I had to do was update my upstream remote on my local repo - I set this up following the excellent github forking instructions when I first forked the repo. All I did then was to check my remotes:

git remote

This showed my remotes with the "upstream" pointing to the old repo. So I copied the URL of the organization repo, removed the old version and added a new upstream:

git remote rm upstream
git remote add upstream git://github.com/joindin/joind.in.git

Everything now behaves as before while handling the new central repo for the project - hopefully this helps others with projects moving from user accounts to organizations (or organisations, as I keep typing, British spellings as always!)