The joind.in projects are set up so that the build process runs on pull requests when they are opened, which is great! It means that contributors don't have to wait for one of the maintainers to look at it, only to reject the contribution on something that could be picked up automatically. I've had a few questions about the setup so I thought I'd share how it works. Continue reading
My current project sees Celery (a python distributed task queue) added to my PHP application. There's a handy PHP interface to the RabbitMQ that Celery uses as a backend, which makes it easy for me to create jobs, called celery-php. This requires either the PECL AMQP extension or alternatively it has experimental support for the PHP library for AMQP - I would normally prefer the PECL version but ran into version compatibility problems, missing manual pages, and decided that a pure PHP solution might be more portable and perhaps I would just add the experimental branch to my
composer.json file for this project. Continue reading
My current project does periodic releases, we build a few things, then we work on getting a bunch of user feedback and changing/fixing things before we actually release. This means we need to be organised with tags and branches. We're using GitHub for collaboration, including our issue trackers, commits which contribute to an issue have the issue number in the commit message, and when a branch merges in to the main line, we use the "fixes #42" notation to simultaneously close off the issue that it relates to.
This has been working pretty well, and today I got the question "what's new since I last saw this project?" - so I created a changelog. It's rather rough-and-ready but I had fun so I thought I'd share. Continue reading
Three git courses are coming up in the next few weeks, and a few people have asked me which courses I'm running, so here's a quick roundup (feel free to drop me a line if you need any more detail):
- Dublin, 30th January: Git and GitHub Foundations
- Dublin, 31st January: Git and GitHub Advanced
- London, 6th February: Git for Teams
I have fantastic partners for these events: the Dublin ones are with Github and the London ones with FLOSSUK, and I look forward to both. Right now they all do still have places remaining, visit my courses page for the links you need to book. Training days are a great opportunity to boost your skills and discuss specific aspects of technology that you can't really get from a textbook - hope to see you at one of these sessions, I am standing by for difficult questions :)
I'm working on some demos for a tutorial I'm giving next month and since I'd like to show off Github's API, I needed an access token for it. They have the usual web flow but I'm cutting as many corners as I can to keep the demos nice and quick, so I looked into the support Github has for generating an API key programmatically. Continue reading
This article originally appeared in the May 2012 php|architect magazine.
Often I find absolutely competent programmers, who aren't involved in open source, either because they don't know how to approach a project, or because they just aren't sure how the process even works. In this article we'll look at one example, the conference feedback site joind.in, and how you can use GitHub to start contributing code to this project. Since so many projects are hosted on github, this will help you get started with other projects, too.
The tl;dr Version for the Impatient
- Fork the main repo so you have your own github repo for the project
- Clone your repo onto your development machine
- Create a branch
- Make changes, commit them
- Push your new branch to your github repository
- Open a pull request
This article goes through this process in more detail, so you will be able to work with git and github projects as you please.
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:
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!
Recently I mentioned the github API and retrieving issues from it. This is because the joind.in project agreed to move its issue tracking from github to JIRA, since the issue tracker on github is far from feature complete. I migrated only our open issues, and comments (and the comments ended up a bit weirdly formatted on the other end but this was the best they could do). It was nothing pretty or clever but in case it's useful to someone else, here's the script: