As the year comes to a close, and I sit here in the small town of Wilderness, drinking my last beer of 2019, and watching the last fire of 2019 burn down, I contemplate the past 20 years of my life. 20 years ago (at around this time) I was a lost 22 year old, with little to no direction or career to speak of, recovering from an extremely toxic relationship/break up, wishing, as I often had done in the past, for it all to just end.
How such a small period of time as 20 years has changed all of that.
In the 20 years since that night, I met the love of my life, obtained my national diploma in programming, stumbled into the world of web development, got married, purchased a house, had two children, ran (and sold) a family business, opened a jiu jitsu club, travelled to Europe twice and lost and gained more friends along the way than I can count. If you had stopped by 20 years ago and told me all this was possible, I would have swore you were crazy.
So here’s to 2020 and the next 20 years being as action packed as the last 20 were.
It’s been just over two years since I moved into my current office space, and just over a year since I last wrote about it. As my two major hobbies outside of my work as a developer are jiu-jitsu (which not many folks can relate to), and computer hardware and peripheral upgrades (which most can at least understand) I thought it might be interesting to look back at what changes I’ve made in the tools I use every day, over the last year.
The Workstation
Last year I posted a review of how my workspace had changed over the 2 years since I left employment and become a freelance developer. It included this image of what my desk looks like, with a short run down of everything you see (and don’t see) in the picture.
My November 2018 workspace
Today, just over a year later, there have been some small but important changes.
My November 2019 workspace
So besides the less bright lighting (more on that later), the more keen of eye among you will have noticed some subtle differences.
Firstly, my peripheral monitors have changed. I was able to pick up a newer Samsung and Dell 24 inch monitor, so now all three screens are LED powered, and the two side monitors are more uniform. I’ve definitely noticed the difference in the visual quality improvement in making sure all three monitors are LED, I no longer feel like I’m having to adjust my eyes when I switch between the different screens.
The other major changes are in peripherals, I’ve replaced the Logitech headseat with a Sennheiser HD 280 Pro studio set, and replaced the short mic stand with a proper desk mounted arm. This allows me better use of my screens and keyboard when I’m in online meetings or recording podcasts (which I’ve not done as much as I’d like to in 2019)
I also treated myself to a Sparkfox Atlas Wireless Bluetooth Controller. This is a great little gaming controller, which I can use connected via a USB cable or via Bluetooth, works on both Windows and Ubuntu and has a very similar layout to an XBox controller.
Finally, as I noted earlier, I’ve switched from using the oppressing overhead florescent lights to a smaller lamp which sits behind the left screen. It gives off just enough light for me to see the things I need, without making my eyes water during the day.
The Laptop
While my workstation has only undergone a few external changes over the course of the last year, I eventually decided it was time for a new laptop this year.
I usually try and use a laptop for at least 4-5 years before replacing it. I’d been mostly happy with the performance of the Dell Inspiron gaming laptop I’d purchased at the end of 2017, but I ended up doing more conferences and therefore travel in 2019 than I had done previously, and two things became clear. First, the laptop and bulky, ungainly charger became heavy when carrying them around a lot, and second, the battery only held around a 4 hour charge.
I’ve always been partial to Dells, and the Dell XPS 15 seemed the logical choice. However, an online friend had recently purchased an Asus Zenbook, and was raving about it.
so i've been using this asus zenbook for 1 day of work and 1 day of non-work and i think it might be the best laptop i've ever owned
After researching the differences in price and hardware between the two, and reading a bunch of online reviews, I ended up purchasing the Asus Zenbook UX533FD, and I couldn’t be happier.
It’s super light, has a 10 hour battery life, runs the latest Ubuntu (after a bios update), and is powerful enough that I feel as productive using the laptop as I do on the desktop. At the same time, I also upgraded my laptop mouse to the Logitech M720 Triathlon, the big brother of the Marathon mouse I use on my workstation, and it’s a great wireless addition to the laptop.
The bleeding edge of operating systems.
The other big change I made at the tail end of this year was upgrading both my laptop and workstation OS to the latest version of Ubuntu, 19.10, codenamed Eoan Ermine. I typically only run the latest LTS version on my workstation, and whatever is the latest release on my laptop, but the 19.10 release is so slick, stable and fast that I had to install it on the workstation. I was actually feeling left behind whenever I switched from laptop to PC.
The future
Looking ahead, I don’t think there will be much I will change in 2020, as I’ve pretty much got my perfect set up. But who knows, upgrading computers is the one hobby I do tend to like to spend money on, so I can’t make any promises.
Last night I gave a talk at the Cape Town PHP Meetup introducing the concepts of testing an existing Laravel application. As I did not have time to prepare slides, here are the links to the relevant items I discussed in the talk.
It’s a funny old world. Over the course of the past few years I’ve seen a lot of people take a step back from contributing to WordPress, and I never thought I would get there. But here I am, writing about taking exactly such a break.
When I joined the WordPress community back in early 2016, it was the first global tech community I’d ever actively joined. Like the first time you learn to ride a bike, all I wanted to do was be part of this amazing thing and do as much of it as I could. Now, just 3 years later, I feel burned out and disillusioned as to what my purpose in this community really is.
Don’t get me wrong, the community is not the problem, just like riding a bike up and down your street is not the problem. But all it takes is one or two potholes, or an inconsiderate driver, and things soon take a turn for the worse.
Organising local events
I attended my first WordCamp in Cape Town in 2015, spoke at WordCamp Cape Town in 2016, lead the team for 2017 and 2018, and was part of the team again in 2019, and I need a break. I’d like to be able to attend my home town WordCamp as an attendee next year, without needing to rush from an interesting conversation to whatever next issue might need to be dealt with. I wish the 202o team all of the very best, and I’ll happily assist wherever I can, but not in an official organising capacity.
I will also be taking a step back in organising our local meetup. Fortunately one of our members has joined the meetup organising team, and if she’s as good at organising meetups as she was running Logistics for WCCT 2019, we’re in good hands. I’ll still happily help the team plan events, liase with sponsors and find speakers, but it will be great to share the load of hosting with the three currently active meetup organisers.
WP Notify
I’ve been a community team deputy for about 2 years now, and it’s been an amazing journey. For 2020 I will be taking a big step back from that team, to focus on the future of WP Notify, the notifications feature project I’ve been working on with other WordPress contributors, for the past few months. I think WP Notify is something that WordPress is desperately lacking, and I see it as an important part of moving WordPress into the future, so I want to spend all my core contribution time focused on that.
Speaker diversity training.
Besides WP Notify, my other big goal for 2020 is to do what I can to support the Speaker Diversity Training programme grow and flourish within our local community. Deb Butler has already dedicated herself to launching this training programme, and I want to do whatever I can to assist her.
I am hoping that this break from all of the many volunteer things I, knowingly, get myself into, and a focus on only one or two, will help me redefine my purpose and feel some of that joy I first had back in 2016.
The general recommendation to becoming a better writer, is to write every day.
Besides high school creative writing, I am mostly a self taught writer. I’ve never completed any official copy-writing courses, even though I have three purchased on Udemy from about 2 years ago. I generally don’t understand the finer details that would take me from being a blogger or writing contributor to the ranks of editing someone else’s writing work.
That being said, since I was accepted as a freelance contributor on the Skyword platform early last year, I’ve probably completed at least two written assignments per month. I’m definitely writing more than I ever have, and it’s definitely paying off. I’m seeing the benefits not only in my paid writing work, but also in the general content of my blog.
I thought that it might be useful to share the process I follow, when I am writing content for money. If nothing else, it allows me to write something else today 😉
Brain vomit
While the image above my not be pleasant, this is always my first step. When working on a specific assignment, I will have certain guidelines I need to follow, in terms of article content.
I’ll create a new blank Google Doc, paste any relevant information from the assignment at the top of the page, and then just type out whatever comes to mind. This is usually just a few words or phrases, maybe a title, or a sentence or two.
Research
Once I’ve put down the thoughts I have in my head about the topic in question, I’ll start doing some research. Often this is to clarify some points of (mis)understanding, or to fill in some gaps in my knowledge. The assignment topic will define how much research I do. If it’s in an area I know little about, I can spend up to an hour researching. As I am researching the topic, I’m starting to put together a plan of how the article will look and what the story is I want to tell.
First draft
I then start writing my first draft. This is just everything as it enters my head. I might make minor edits here or there, but mostly I just write as the thoughts come to me.
Break
This is a pretty important step, but I then take some time away from writing. I find this allows me to think about what I’ve written, if there’s anything else I want to add or take away, and allows me to come back to review what I’ve put down with ‘fresh’ eyes.
First edit
This is the most edit heavy process. I read through the content and do my best to self edit my work, taking out repetitive words, looking for other words or phrases that will convey what I’m trying to say. This is usually where I will also start adding links to relevant content, including images, and generally trimming down the content to fit specific criteria. I may also take out sentences, and sometimes whole paragraphs, that don’t fit into the edited article any more.
Second edit
Immediately once the first edit is complete I’ll start the second, and final, edit. This is where I try to just read the article from top to bottom, as a reader would. Usually this is also where I look for complex sentences and try to uncomplicated them, as well as a more detailed focus on spelling and grammar errors. I will also look at the flow of the sentences and prune them where necessary.
I’m sure my process is nothing new or unique, but it’s evolved over time and I find it works for me.
I’ve been freelancing full time for just over three years now, having spent 10 years developing for either digital agencies or small to medium sized businesses, in various roles.
In the 3+ years since I switched to freelance development, the two sentences that I’ve heard/read the most from clients, and the ones that illicit the most negative responses in me, are:
“This will only take x minutes”
“This will be easy for an experienced developer”
If you are a freelancer, and you’ve been on the receiving end of these phrases, you’ll know what I’m talking about. This post however is not for you, it’s for anyone who has ever said one of these phrases to a developer, or who might not understand why they are so negative.
“This will only take x minutes”
x is usually a variable number, ranging anywhere from ‘a few’ to 30. Sometimes minutes is replaced by hours. Either way, the reason this phrase is so despised by freelancers is that it indicates to that you think you know more about what we do, than we do.
If you know something will take 5 minutes, that means you understand the problem fully, as well as the possible solutions required to solve it and also which one to apply to solve it within 5 minutes. This means you can do it yourself. And it is therefore a lie, because if you could do something in 5 minutes yourself, you would not be hiring someone to do it for you.
“This will be easy for an experienced developer”
Personally, this one is worse than the previous phrase, and here’s why.
This phrase tells me you understand that I am experienced in my field, that I am knowledgeable, and you recognise that I can fix your problem. What it also tells me is that while you recognise my ability to fix your problem, you don’t value my knowledge enough to pay what it’s going to cost.
What is happening in both instances is that you’re trying to get me to keep my price down, because you think it will be a simple solution and you assume therefore it will be quick to fix. Unfortunately, in most cases, you’re making the same mistakes as the folks who thought that Titanic was unsinkable.
If the problem was a 5 minute solution, you wouldn’t need to hire me to fix it. And my experience, comes with a price. You either value the fact that I am capable of solving your problem, or you are looking for a cheap solution, which usually means taking shortcuts, something that I am not prepared to do.
Successful solutions take time, planning and thorough testing. By making assumptions up front, you are setting the project up for failure, and nobody wants that.
I’ll be the first to admit that I am fairly inexperienced in the practical application of unit testing, or any kind of automated testing. That’s not to say I don’t understand what these things are. I was first exposed to the concept of unit tests back in 2008 and automated browser testing in around 2012. I know the theory of how they work and what the benefits are. It’s just that I’ve never been in a situation where I had the time to learn how to implement these things, so I’ve never really been able to. It was the classic “running alongside your bike” scenario.
That being said, there is something that a very skilled developer I used to work with said to me back in 2012, which I’ve implemented ever since, that I only realised today not only applied to writing better code, but also to writing testable code:
“Every function, or class method, should only do one thing”
Let’s say you need to write a string parser. The parser needs to take a string, convert it to lower case, strip out specific punctuation (full stop, comma and space) and return the string with the first character as upper case.
Now, the perceptive amongst you might notice the bug. If you don’t see it right away, that’s OK, because that’s the point of this article.
So lets say I now decide to write a unit test to test this function (we’re not digging into TDD just yet). With PHPUnit installed, I might write a test class method that looks something like this:
Granted, it’s a lot more code, but now I can write individual tests for each smaller ‘my_string’ function, and the failing test(s) will point to where the bugs are. I can then fix those bugs, function by function, until my individual tests pass, and then the ‘test_my_string_parser’ test will also pass.
I’m pretty sure this isn’t rocket science, or anything new, but if you’re starting your unit journey, it’s a good place to start.
Using WP-CLI, you can quickly scaffold some unit tests files for your WordPress plugin.
Inside the WordPress directory of the site you’re building/testing on, run the following command to scaffold the unit test code for your plugin, located at /wp-content/plugins/plugin-name
wp scaffold plugin-tests plugin-name
If you don’t already have a plugin directory, because you’re building the plugin from scratch, you can just run the following command to scaffold some initial plugin code, which includes the unit test code.
wp scaffold plugin-name
Either way, you’ll end up with a ‘tests’ directory inside your plugin directory, which includes the test bootstrap file, and a sample test file.
The next step is to set up the ‘wordpress_test’ database, which the test suite will use when creating mock posts etc. Switch to the plugin directory and run the following comand, replacing ‘root’ and ‘password’ with your local MySQL servers username and password.
At WordCamp Europe 2019 in Berlin, I was accepted to present a workshop, which was on the WordPress HTTP API.
Unfortunately we had some WiFi issues, and not all the attendees were able to complete the workshop. Also, there were some folks who were not able to attend at all, due to the workshop being booked out!
This post attempts to solve both problems, by including a link to the GitHub repository, the slides, and 3 videos of me live coding (more or less) the workshop content.
Fair warning, this is the first time I’ve done something like this, so bear with me.
Hopefully using the slides, the GitHub repository and the videos, you’ll be able to complete the workshop and learn a little more about working with web based APIs and WordPress.
