I work with a lot of APIs and I really appreciate good tools. Lately I've been really enjoying using Runscope for testing and monitoring my APIs so I thought I'd share how I work with this tool, which has a great one-person free tier *and* the ability to import/export tests so if you need to work with a team with just the free tier (the examples here are from an open source project which is an obvious use case where it's hard to fund tools), it's clunky but doable. The idea here is just to show you around how to create your own API tests with Runscope (and also to write down what I did so I can point both my future self and others at this!) Continue reading
One of my git repositories has developed a tendency to refuse to checkout a feature branch locally that exists on the remote repo. My git bash completion works, but then strange things happen! It turned out to be that I had two remotes with the same refspec, so I thought I'd write down the behaviour I saw and hopefully help someone else to fix this problem faster if they see it. Continue reading
I'm an open source project maintainer, working on the projects associated with joind.in, and recently we added a Code of Conduct to all our projects (we have quite a few as you can see from our github organisation page https://github.com/joindin).
I feel the same way about codes of conduct for open source projects as I do about codes of conduct for events. You can absolutely run a totally safe and effective event without one, but by having one you make very clear what your expectations are - and in turn this manages the expectations of the people attending that event. Continue reading
It's Ada Lovelace day, a day when we celebrate women in technology. This year I'd like to mention a group of people who make the biggest difference in the tech life of any minority: the allies. Continue reading
If you type
git pull and expect a fast-forward update, but get a merge instead, don't panic! This usually happens when we're collaborating on a branch with other people, and we've made changes on our local version of a branch, and someone else (or the other you, if you use git to sync between multiple dev platforms) has made changes to the remote version of a branch in the meantime. It also happens really frequently in teams where all commits are to the
master branch ... yet another reason to have a decent branching strategy.
All that's happened is something like this:
$ git log --oneline --all --graph --decorate * 054f163 (HEAD, branch1) Installation instructions for the application | * 0ce808c (origin/branch1) Fixing template layout |/ * 927aad9 A random change of 731 to ideas2.txt
Since the last common commit, there are commits on your local branch, and the remote one. You could just let the merge go ahead but there are other options. You could also check out a new branch at this point, reset your tracking branch to the right place and then reapply your changes using cherry-pick or by rebasing and then fast-forward merging your branch. Continue reading
I create my slide decks from ReStructuredText, which is a text markup format. Working this way makes it easy to add into source control, fast to work with, and also accessible since I don't use a mouse or other pointing device so traditional slide deck creation programs are kind of difficult. Text-based wins every time for me. While working on a new slide template, I ran into some difficulties and had to figure out how to inspect what was going on. I seem to struggle with this every time so I am writing my troubleshooting guide here for when I need it next. Continue reading
This post is an adaptation from an email I sent to a friend who is doing their first few conference talks. I was asked to share more widely so here it is
The microphone is your friend, honestly :) Even if you think you can be heard, there are some definite benefits to using a mic if it's available:
- you actually can be heard
- even people with less-than-excellent hearing can hear you
- the video recording can hear you as well
- you now have the option to employ some vocal variety: exclaiming, pausing, stage whisper ... it all adds interest and colour to what you are saying
There are a few different types of mic and each one has its own quirks! Continue reading
I've been a conference speaker for a lot of years now, which doesn't make me an expert but it does mean that people ask me for advice pretty regularly! With the Call for Papers open for PHP North West at the moment (awesome conference, first weekend in October, CfP at http://conference.phpnw.org.uk/phpnw15/call-papers/), I've taken this question a few times. Here's my advice in a nutshell:
- Think about what's interesting that you could share with other developers. The key here is that the people listening should go away with something useful, rather than just the impression that you're awesome
- Write it down. You don't need to write the talk before you submit - just a title and an abstract will do. The abstract should be one paragraph, maximum 200-250 words
- A great abstract says why this topic is vital, what cool things will be covered, who should come and what they will learn. I'm paraphrasing but those are the basics!
- Submit your abstract to http://helpmeabstract.com/ to get feedback from some lovely volunteers who will help you (bookmark the gist and keep revisiting it, the system doesn't notify you or anything ... yet. Pretty sure you can submit patches while procrastinating on a slide deck though)
- Did you get this far without submitting? That's normal :) Remember that your community needs new voices. Each of us is ahead of *someone* on the path, you absolutely don't need to be the expert to have something to offer to the rest of us. So please, submit :)
I'm a fan of Jenkins as a build server, and on one particular project we've also started using New Relic (I haven't figured out how to blog fun things about New Relic without sharing graphs of client applications which doesn't seem like a cool thing to do). New Relic has a feature where you can notify it when you do a deployment, and it shows on the graphs a line marking when that happened, which is super useful for correlating performance changes with code changes.
I do a lot of code reviewing, both in my day job as principal developer and also as an open source maintainer. Sometimes it seems like I read more code than I write! Is that a problem? I'm tempted to say that it isn't. To be a good writer, you must be well-read; I believe that to be a good developer, you need to be code-omnivorous and read as much of other people's code as possible. Code reviews are like little chapters of someone else's code to dip into.
Over time I've developed some particular processes that I find helpful when reviewing code. In particular, I often surprise people at how much review I do before I run the code. Sometimes I grab the branch so that I can use my local diff tools, but I don't actually execute code until I've established some basic facts. This post is a little insight into what's happening in this not-running-the-code-yet zone. Continue reading