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
I did a very unscientific twtpoll recently regarding what brought each of us into open source. Plenty of people took the time to vote or retweet, so I thought I'd loop back around and let you know how it looked overall when the poll closed. Continue reading
I teach git and often have issues with bad projectors where you can't see the colours. Recently I had a setup where even white on black was more or less invisible, but using black text on a white background worked okay. There's lots of documentation on how to turn on colours in git but not so much about how to turn them off.
Try putting the following into
[color] branch = false diff = false interactive = false status = false
I had expected to be able to set
color.ui to false but that didn't seem to make much difference, so I now use the settings above. I thought I'd drop it here in case anyone else is looking for the same thing.
I'm a vim user and I somehow completely missed this excellent feature until much more recently than I care to admit! Usually vim has its own clipboard, but it doesn't share with the operating system. You will need a vim-gtk install, this isn't available in really basic vim (I'm a little unclear exactly on the dependencies).
To paste between vim and something else, use the + (plus) buffer in vim. It contains the contents of your system clipboard, and you can also write to it. If you're not already using buffers in vim, then you should probably read the excellent documentation but for a very quick start:
- To copy something into the buffer, select it in visual mode and type
- To paste from the buffer, type
I had no idea how I'd missed this really fundamental trick, so I thought I'd share!
Today's little-known git feature (or maybe everyone knows but me? I only found this a few months ago) is for quickly switching between branches. Usually I would switch branches with:
git checkout [branchname]
However if you switch from one branch to another and want to switch back again (this happens when I'm reviewing changes and wondering if a bug is present on master as well), then you can do so by just doing:
git checkout -
Just a little timesaver in case it's useful to anyone else - I know I've been using it quite a bit!
The joind.in project uses a really nice vagrant setup for its dev platform - which is much needed these days as we move away from a single LAMP stack install to a website plus another website, which talks to an API and caches in redis and deploys with .... you get the picture :) This is great but having everything on the VM can make it a bit trickier to debug what's going on - and with a website that talks to an API that talks to MySQL, that all lives on a VM with port forwards, you can see the problem :)
To get an insight into the traffic going around the place, I've been using Wireshark and it's ability to capture remotely, it's really simple so I thought I'd write down my "recipe" on how to do this in case it's useful. Continue reading
I get a lot of complaints about an API that I maintain (http://api.joind.in) which is "missing" the ID field. This ID field is the database's primary key; if the user doesn't have access to the database (they don't), then it seems to me that the primary key probably isn't all that useful.
Instead, the API publishes each record with a unique
uri field. If this record is referred to by another record, then this full identifier will be used in every case. If this record should be included in a collection, this exact same identifier will be used there, too. You can reach the resource directly by requesting its URI. In the same way that we might refer to a website by its URL, we refer to records in RESTful systems by their URI*. If you need to store these somewhere for your own use, you can use whatever key you like with the local storage, you may even choose to use the
uri field as it is unique.
* URI stands for Unique Resource Identifier
I had a good experience implementing beanstalkd for the first time last week, so I thought I'd write down how that went and what I learned.
My requirements were simply to add both asynchronous (for processing things like recalculating counts) and periodic (mostly for garbage collection) tasks to a PHP application. The application has a separate web application and backend API, both made of PHP's Slim framework, and the API talks to MySQL. It's all very lightweight and scalable, and I was looking for something to fit in with what we have, with good PHP support.
Enter beanstalkd, it's a super-simple job queue and has great PHP support in the shape of Pheanstalk (I'm saving my PHP + beanstalkd examples for another day because this post would get too long to read otherwise!). I've used gearman in the past but beanstalkd seemed lighter, and when I started looking at their documentation I discovered that I had a working installation in about the time it would take me to fall off a log - which is always a good indicator of a tool that will be fun to work with :) Continue reading
I can't be the only person who always seems to be switching between multiple development branches. Sometimes I get distracted for a few days (I'm also part time, which doesn't help!) and then I can't even remember what I was doing or what the branch was called.
The remedy for this situation? The
--all switch to
git log. Continue reading