Sometimes I’m glad I don’t make rash bets, it saves me from losing them as much as I lose out from not winning them. The recent release of WordPress 3.7 with its built-in auto-update functionality is one of those things I nearly offered a bet on not happening many years ago :).
Back in the summer 2009 at the second UK WordCamp in Cardiff I remember chatting with Matt and one of the things we talked about the potential for auto-upgrades to happen one day. I was pretty sceptical, at the time we hadn’t even had the manual upgrade feature for a year yet, 2.7 was released in December 2008, and getting that working across all the different hosting platforms had been a fun experience.
I’m pretty sure I might have used the word “impossible” that day.
I’m immensely proud of the improvements we have made in manual update process over the past few years and very happy to have been proved wrong.
Major props go out to Dion, Nacin and everyone else who has contributed to this release.
Ten years ago today the very first release of WordPress was released by Matt and Mike. My WordPress story starts almost a year later with me searching for something to use for my first personal blog, finding WordPress and I falling in love straight away. The simplicity of the 5 minute install and the freedom to do what I wanted had me hooked.
Over the past ~9 years I have grown with WordPress contributing back in a number of different ways. My addiction to contribution started with the codex which soon led me to trac and sharing patches which fixed bug I found or other people reported. A while later I had the privilege of being invited to join the core team as a lead developer. A few years later this addiction even helped land me my dream job.
Around 1300 commits in, today I’m still contributing and looking forward to the next ten years and what surprises and adventures will be in store for us.
You know that thing that happens when you love writing unit tests so much that you completely forget the argument order of all the
Yeah it does happen, I’m sure it is not just me 😉
You write everything in as
$this->assertEquals( function_call(), 'expected string' ); and then you get really confused when phpunit tells you it expects the wrong result from the function you haven’t implemented yet and received the expected result.
Good, I managed to write tests the wrong way round for two days before I realised and I wasn’t looking forward to going through and correcting them all, but then I remembered the power of
sed and started cooking a recipe up.
It turned out pretty simple:
sed -i "s/\(.*assert[^(]*\)( \([^,]*\), \([^)]*\) );/\1( \3, \2 );/" file_of_tests.php.
What it does:
- Capture the start of the line up to the call to the assert function in ‘\1′
- Capture the two function arguments in ‘\2′ and ‘\3′
- Rewrite the matched line with the arguments switched
That was fun!
Every now and then I find myself needing to quickly analyse a set of access_log files to see who the most common visitors are so that I can decide if there are any abusers I should be blocking or poorly configured services running somewhere that I can try to get fixed. I can never remember the quickest was to do this so I decided to write down the “one liner” that I cobbled together this time so I can hopefully find it next time and not have to reinvent the wheel again.
Here is the one-liner I used to find the top IPs this time:
sed -e 's/\([0-9]\+\.[0-9]\+\.[0-9]\+\.[0-9]\+\).*$/\1/' -e t -e d access.log | sort | uniq -c | egrep -v "\s([0-9]|[0-9][0-9]|[0-9][0-9][0-9]) "
Splitting this out we have:
- A call to <code>sed</code> to extract all the IP Addresses from the access_log file
- A call to <code>sort</code> to sort the list of IPs
- A call to <code>uniq</code> to create a list of unique IPs with counts
- A call to
egrep to filter the unique list down to IPs we at least 1000 appearances – this will need tuning depending on the volume of requests / time period the file covers.