Right now I'm working on an application which is experiencing lots of interest - and therefore lots of load! We needed to look at ways of trying to bring down the pressure on the servers, and decided to use a CDN (Content Delivery Network) for our image files. It was surprisingly painless to implement once I got into it so here it is in case it's helpful. Continue reading
When working with curl, it can give lots of excellent and detailed information, but sometimes it is too much! Today I'm fiddling with the caching headers on a client's application, so I'm only interested in seeing the headers and not the body of the response. Making a
HEAD request changes the output I get, so I really do want to
GET and then only see the headers.
Handily, when you use the
-v verbose flag with curl, it sends the output to stdout as usual, but the extra information including the headers goes to stderr. This means that I can therefore view the headers only throwing away stdout completely:
curl -v -s http://awesome-site.com 1> /dev/null
(you need the
-s to stop curl from "helpfully" printing progress bars as well)
Here's a little demo video that I put together to explain pushing/pulling with multiple remotes and how tracking branches make this easier. It's one of the chapters from my "Git Adventures" talk, but it didn't make it in to the talk in Amsterdam last week since we chose a different adventure that time - sharing it here in case it's helpful to anyone else, and so I can find it later!
I also blogged about the tracking branches in a bit more detail if you're interested.
Here's a topic that took me a while to understand in git, and now (I think!) I do, I thought I'd write it all down while I can remember!
Some branches in git (such as your origin/master branch) will usually track the remote branch that they are related to. But what if you want to create a relationship between local and remote branches? Or stop them from tracking? Here's some pointers Continue reading
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: