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
My worker scripts have really basic logging (as in, they echo when something happens, and I can see those in the supervisord logs). Which is kind of okay, but I wanted to at least add timestamps in to them, and maybe send emails when something REALLY bad happened.
I'm a huge fan of Monolog so I grabbed that, but it wasn't immediately obvious which of the many and varied options I would need for this fairly simple addition. It turns out that the right thing to use is the
ErrorLogHandler, so now my code looks like this:
<?php require "vendor/autoload.php"; $logger = new \Monolog\Logger("log"); $logger->pushHandler(new \Monolog\Handler\ErrorLogHandler()); $logger->addInfo("Something happened");
And the output is neatly in lines like this:
[2014-06-05 17:00:47] log.INFO: Something happened  
You can do a lot of different things with Monolog, but since I had to look up this simplest of all options, I thought I'd share.
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.
A while ago I did some benchmarks on how different versions of PHP perform in comparison to one another. This isn't a performance measure in absolute terms, this was just benchmarking them all on the same laptop while it wasn't doing anything else, and averaging the time it took to run the benchmark script.
Recently I ran it again for versions PHP 5.3 through PHP 5.6 and I thought I'd share my results:
I've got an application that uses Beanstalkd to queue up messages, and some PHP worker scripts that grab messages from the queue and process them. Messages get added by the web application, but can also be added by cron - and when I add a bunch of messages via cron, I don't want to swamp what the web application is doing! Those cron-added jobs are mostly pretty low priority, generating reports, sending weekly update emails, that kind of thing. Beanstalkd has a concept of priority, so I can create lower priority jobs by using code like this:
<?php define("LOW_PRIORITY", 2048); // default is 1024 $queue = new Pheanstalk_Pheanstalk($config['beanstalkd']['host'] . ":" . $config['beanstalkd']['port']); $queue->useTube("scorem")->put(json_encode(array("action" => "my_important_task")), LOW_PRIORITY);
This will add the job to the queue, but anything with a higher priority value (where 1 is the highest priority!) will take precendence. This way I can add as many non-urgent jobs as I want to to the queue without impacting my website performance. My setup has multiple workers and also I tend to write a script that puts loads of tiny jobs on the queue rather than putting one monster task on there. I find this approach a bit more fault-tolerant and also means that incoming tasks can get a chance to get serviced rather than waiting for some crazy huge thing to finish.
I had real issues finding information about the priority settings for beanstalkd and PHP, so hopefully if anyone is looking for it, they will find this post :)
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