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
I have a thinkpad laptop with a touchscreen and a swivel so it can fold up and pretend to be an oversized tablet. I like it a lot, but the touch screen interface hasn't been all that useful since I normally use this machine docked and then it maps the whole of one screen as a touch interface across my multiple monitors as a desktop space!
I recently sorted this out, so I thought I'd share the scripts that worked for me on Saucy Salamander Ubuntu 13.10 with Unity.
First, work out which device you actually want:
$ xsetwacom --list
Wacom Bamboo stylus id: 11 type: STYLUS
Wacom ISDv4 E6 Pen stylus id: 13 type: STYLUS
Wacom ISDv4 E6 Finger touch id: 14 type: TOUCH
Wacom Bamboo eraser id: 19 type: ERASER
Wacom Bamboo cursor id: 20 type: CURSOR
Wacom Bamboo pad id: 21 type: PAD
Wacom ISDv4 E6 Pen eraser id: 22 type: ERASER
xsetwacom to get the right touch input relating to the correct screen, even with multiple monitors:
$ xsetwacom set "Wacom ISDv4 E6 Finger touch" MapToOutput LVDS1
At this point I should point out that my touch screen is incorrectly configured and therefore needs the script above running every time I plug or unplug an external display. Since I dock my machine, move it almost daily, and regularly present ... that's kinda irritating. Any solutions on improving that are welcome.
I'm working on a fun printable project at the moment, but part way through I realised I would need to process odd and even pages of the document separately. So separately, that I split the doc into two separate ones, with odd pages in one and event pages in another - and then had to recombine them. Here's the commands that I used, with an excellent tool called pdftk. 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 :)