Categories
Experiences

Taking on new (old) challenges

Life is a funny old thing. When I left working for an employer back at the end of 2015, I never dreamed I would, in the short space of 5 years time, come back to being employed full time again.

Back in June of 2019, I shared the news that I had accepted an increased role at Castos, that of lead developer. Accepting this position meant that I could dedicate more of my time to working with Craig and the rest of the Castos team, and would be spending less time working with various freelance clients at Codeable. The agreement between Craig and I was that of a 75/25 split, I would spend 75% of my time on Castos tasks, and the other 25% working with freelance clients through Codeable.

Now, just over a year (and 8000 plus new sign ups) later, the requirements for that role have grown to a point where it needs someone who can focus 100% of their time to it. So, from 1 October 2020, I am happy to announce that I will be dedicating all of my resources to Castos as Development Lead, overseeing the development efforts for our web application and our suite of WordPress podcasting plugins.

The title itself is arbitrary, it’s the journey ahead that excites me. In the past three years we’ve grown from Craig and myself to an 8 person team working on the Castos Hosting and Analytics platform (with a new developer to be added shortly), as well as being joined by folks from Craig’s other business, PodcastMotor, who manage our new Castos Productions service (About page images pending).

So while I will still be working on building new features for our web application and the WordPress plugins, I’ll also be more involved in finding ways to improve our development processes, scaling our platform to meet the demands of our customers requirements, while helping to make sure our software makes our customers more successful, and also supports each member of our team do to their best work.

In line with this change, I’m also looking forward to spending more time on our WordPress plugins, streamlining them for our WordPress users, and making it simpler to build and manage a successful, self hosted WordPress podcast.

Going forward, the content of this blog is also going to undergo some changes. There will be a shift away from freelance developer focused content, and will be more in line with whatever I am working on, or learning, as I navigate this new path. I’ll probably be overhauling my about page, and a few of the general content pages.

Most importantly, I won’t be taking on any new freelance clients. This means if you are looking for someone to work on your development project, I’ll rather redirect you straight to the Codeable developers page, where you can search for your perfect WordPress expert, and start a project with them.

I consider myself very fortunate to be working with such an amazing team of people, building a product that we all believe in, while supporting open source software at the same time. It’s been an amazing 3 years growing into this position, and I am looking forward to the next 5 years (and beyond).

Categories
Development Experiences Freelancing

ASUS Zenbook 15 UX533FD review – an Ubuntu friendly developer laptop

I’ve always been a fan of Dell laptops. While often a little more pricey than their counterparts, their laptops are usually well built, typically run Ubuntu without any hassles, and Dell have great after sales service. My last two laptops where Dell.

I’d been eyeing the Dell XPS 15 for about a year, and I had planned to purchase one when I was due for an upgrade. However, sometime back in 2017, someone I follow on Twitter suggested something I had not thought of, the Asus Zenbook range.

Now as a PC gamer, Asus is a well known brand. The produce some of the best PC gaming hardware around. In recent years they’ve switched to more integrated hardware, from tablets (my first Android tablet was an Asus) and more recently to laptops. So I was curious to see how the Zenbook range compared to the Dell XPS range.

The first thing that struck me was the wide range of ZenBook Series laptops available. After some extensive research, I eventually settled on the Asus Zenbook 15 UX533FD.

General impressions

I’ve been using this laptop for almost a year now, and I’m very happy with it. It boots fast, runs all my applications without any problems, and is super light and easy to carry around. Whenever I’m working in it, it never gets hot, and I hardly hear the cooling fans spinning up, so it’s super quiet as well. It has a average of 10 hours battery life if I’m using it for development all day, and an added bonus is that it looks really good, with the Royal Blue finish. You can read more about the tech specs here, but it has everything I need in terms of connections. Finally, the charging cable is also small and light, so when it’s in my laptop backpack I hardly even notice it’s there.

Cost Effective

I always prefer to limit myself to a specific budget, this time around, no more then ZAR25 000. I also tend to have specific minimum hardware requirements when it comes to a work laptop, preferring a decent Intel Core i7 CPU, at least 16GB of RAM and a 512 GB SSD hard drive. I’m not too worried about getting the latest and greatest of the Intel chips, nor do I need a 4k or touch enabled screen. I’m also not concerned about super powerful graphics or the number of additional ports it has, I just need at least one or two USB ports and an HDMI port.

Based on these specifics the Asus Zenbook was the clear winner, being available within my budget at ZAR7000 less than a Dell XPS, configured with almost exactly the same hardware.

Ubuntu friendly

Whether it comes pre-installed with Windows Home or Pro does not really matter to me, as long as I can install Ubuntu on it without any problems. At first I had some issues with getting Ubuntu installed, but after a bit of research online I discovered that updating the laptop firmware to the latest version would resolve any issues. I also decided to install the most recent Ubuntu version, which usually contains the most recent kernel updates and therefore less hardware compatibility issues. The base OS install was a breeze and I didn’t need to jump through any hacky workarounds to get certain things working. I’ve since successfully upgraded the OS to the recent LTS release (20.04), again with very few issues.

Performance

I’ll be the first to admit that I know nothing about performance benchmarks, so all I did was find a benchmarking tool on Ubuntu that would give me some scores to compare. Hardinfo seemed to be a solid option, so I ran the benchmark suite on the laptop and compared it to my AMD Ryzen powered workstation.

I was pleased to discover that not only were many of the benchmarks pretty close, but a few of them were better on the laptop, mostly in CPU related tests. I honestly can’t say I can tell the difference when I’m working on my laptop vs the workstation, except when it comes to graphics intensive applications, like games.

BenchmarkWorkstationLaptop
CPU Blowfish (lower is better)0.971.05
CPU CryptoHash (higher is better)1284.821058.34
CPU Fibonacci (lower is better)0.550.39
CPU N-Queens (lower is better)5.124.80
CPU Zlib (higher is better)2.351.46
FPU FFT (lower is better)0.800.65
FPU Raytracing (lower is better)2.561.13
GPU Drawing (higher is better)16462.808428.99

I’ve since had quite a few online interactions with other developers who’ve also discovered the joy of the Zenbook range.

So if you’re looking for a small, powerful, good looking, well priced, Ubuntu friendly laptop, you won’t go wrong with an Asus Zenbook.

Categories
Development WordPress

Submitting a patch to WordPress core, using Git

Development Station

I initially encountered version control in my 4th year of programming, when the lead developer of the company I worked at had implemented Subversion as a code backup solution on our local testing server. As we were all required to use Windows at the time, we mostly just installed TortioseSVN, so my command line Subversion knowledge is limited.

A few years later, at another company, I was introduced to Git. At the time GitHub was in it’s infancy, but we used it internally for revision control and production deployments. This was also around the time I switched to using Ubuntu as my main OS, and learning the joys of the terminal. Since then, every team I worked with has used Git and either Bitbucket, GitHub, or GitLab. This means that I can use Git on the command line with reasonable success, and can work with branching, code reviews, and submitting/merging pull requests using the web interfaces of these platforms, with GitHub probably being the one I am most used to.

Back to the point, this meant then when I got into developing for WordPress at the end of 2015, and found they all used Subversion to manage both core and plugin/theme repositories, I was a little out of my depth. Managing plugins was easier, I could keep the my version control using Git, and then just memorise a couple of commands to push the latest updates to the plugin repository. Getting into core development was a little trickier, as it was all managed using Subversion. To be honest, it’s been one of the reasons I’ve struggled to get into WordPress core development.

All this changed in March of this year, when it become possible to associate GitHub accounts with WordPress.org profiles and documentation was added to WordPress core developer handbook on how to use GitHub pull requests for code reviews related to trac tickets in WordPress.

I had the code, and the comfort in using Git, and the documentation was very clear as to the steps to follow. All I had to do was make it happen.

Setting up the development environment

I’ve blogged about this before, but I use a very simplified LAMP stack for my local development. I know, I’m old, but it’s easy to understand, fast, and it just works. It does help that my base OS is Ubuntu, and the actual LAMP set-up is really easy, especially if you have the amazing tutorials over at Digital Ocean.

What did concern me was how much work I might have to do to get the wordpress-develop GitHub repository installed and set up on my local environment, to be able to test anything I added. To my surprise, it was a breeze. Using the same setup script I use for my client projects, I created a wordpress-develop local site and cloned the wordpress-develop repository into the local wordpress-develop site directory.

The WordPress source code resides in the /src directory, so I browsed to the local .test domain which my setup script creates (https://wordpress-develop.test/src) and was surprised to see a little ‘reminder’ screen, telling me I needed to install the npm dependencies.

Fortunately I already had npm installed locally (having recently needed it for the Seriously Simple Podcasting player block) so I just needed to install and build the required assets with npm install and npm run dev.

After that, it was the good old famous 5 minute install I’m always used to, and within a few minutes I had the wordpress-develop code up and running on my local environment.

The actual Git process.

This is all documented in the core handbook entry on Git, but once you have the GitHub repo cloned, creating a patch to submit to a ticket is pretty straightforward.

Firstly, it’s a good idea to create a working branch for your code. The handbook recommends using the ticket number as part of your branch name

git checkout -b 30000-add-new-feature

Once you have your working branch, you can make your changes to the code, and use the git add and git commit commands you’re used to if you’re comfortable using Git. You’re able to view the status of your changes, using the diff tool. This outputs all the changes between the main branch, and your working branch.

git diff master 30000-add-new-feature

When you are ready to submit the patch, you can use the diff tool again, and simply pipe the changes to a .diff patch file.

git diff master 30000-add-new-features > 30000.diff

If there are already patches attached to the trac ticket, you can use this tool to create updated patches.

git diff master 30000-add-new-features > 30000.2.diff

To be honest, this is probably very similar to how it works in Subversion, but being able to use Git commands and Git branches, when you’re more comfortable with Git, makes it much easier to get started.

You can also use GitHub pull request for code reviews on patches, but that’s a topic for another day.

This is all pretty exciting for me, because it lowers the barrier for me to contribute directly to WordPress. I’ve already got two new tickets in trac that I’ve submitted patches to, and I’m looking forward to being able to contribute back to WordPress core in the coming years.

Categories
Experiences

Nobody likes you when you’re 43

When I met my wife in 2000, I had just turned 23. The previous year, Blink182 had released “What’s my age again?”, and she took great delight playing it for me.

I’d never streaked anywhere, but I’d done some pretty weird shit up till that point.

Today, I turn 43, meaning it has been 20 years since that event. Amazingly, my 23rd year was probably my own personal “rock bottom”, as I’d spent 5 years after leaving high school wandering aimlessly from job to job, living from party to party, with no idea of what I wanted to do with my life.

Meeting the woman who would become my wife, and the mother of my boys, changed all that. She saw something in me that I didn’t, and together we’ve shared an eventful 20 years together, 12 as a married couple. I am extremely grateful for her presence in my life.

So this year, on my day of birth, I am thankful not only for her, but for all the wonderful people who have helped shape the life I have made for myself today. If you are reading this, it means you are probably one of those people, so thank you for being a part of the journey that is my life.

Here’s to the next one!

Categories
Freelancing

Show me your WFH set up

Since we’re all currently in the middle of probably the biggest global crisis since World War 2, many folks in my social timeline are posting/sharing their work from home (WFH) pictures. Whenever I share mine, I always feel like I need to explain the tidiness of it all, because my workspace is one area in my life where I do try to keep things in place.

This picture was literally taken at the end of my morning session of work, during my first coffee break. I left the plate and the coffee cup in the picture to prove it.

Besides a few extra items on the desk (that are only here because I’m currently working from home, my battery powered screwdriver, two remotes needed for this office, my running headphones, a few charging adapters, and some extra batteries) this is how I prefer to keep my area of work at all times. I can’t abide an untidy work area, as any clutter that gathers up gets in my way and makes me less productive.

While the space around me not be as tidy (either my office, or currently the garage) I try to keep my desk as a bastion of clarity, almost like it’s a safe haven amongst the madness that is every day life.

What about you, are you a fellow ‘desk neat freak’ or do you feel your workspace should be as comfortable and/or chaotic as your life is. Hit me up in the comments, ideally with pictures, if you’d like to share.

Categories
Development Experiences Freelancing

An experiment in dark vs light themes

DarkVsLight

It all started, effectively 2 years ago, with this tweet.

I’m not sure when I started following Brent on Twitter, but he posts interesting stuff about Laravel and PHP, and I’ve learned a bunch from his blog. Sometime last year he tweeted this and as I dug deeper into the conversation, I realised something. I had, up until a few years ago, been a strong proponent of light themes.

But somewhere along the line, I was tempted by the dark side.

via GIPHY

I can’t remember exactly when it happened, but it was recent, since about 2016 or so, that I switched my PHPStorm IDE from a light to a dark theme. I think it was when I first installed the Material Theme, and it defaulted to a dark theme. I’m not sure if I kept it because it was better, or because I was lead to believe it was better, but I’d been using it ever since.

Over the past weekend, I upgraded my workstation to the latest Ubuntu release and one of the new features of the OS is a built in dark theme, so I tried it, and hated it.

On Sunday (exactly 2 years on from the original tweet!) I was thinking about this, and I realised that there are only two places that have a dark theme; my terminal, and my IDE. Everything else I use daily has a light theme. My text editor, my Slack instance, even my browser, is using a light theme. And I got to thinking that every time I’ve tried a new dark theme (in Ubuntu, Slack, Twitter) I’ve hated it. So why am I keeping to a dark theme in the two applications I probably use the most, after Slack and my browser.

So I decided to try an experiment. I switched PHPStorm back to the IntelliJ light theme, I switched my terminal to a light theme (Tango light), and I gave it a day to see if it made a difference.

It’s now been two days like this, and I’m surprised to find that I have not noticed any negative differences. In fact, I’ve found the text in PHPStorm and my terminal more easy to read, and therefore it feels like I comprehend what’s happening quicker. As I’ve always kept my monitor brightness and contrast settings low, it appears I’ve actually been working in a sub optimal way now, for at least 3 years!

Light themes FTW (again).

Categories
Development Freelancing WordPress

Things I’ve been working on lately – part 1

Random_Stuff

Managesite scripts

Over the course of the past 4 years I’ve experimented with a bunch of different local development environments for my freelance client work. I started with Scotch Box, transitioned to Boss Box, and finally back to bare bones LAMP, mostly because I develop on Ubuntu and I find Apache2 to be an easier web server to configure than nginx. The final addition of mkcert (generating locally trusted SSL certificates) rounded up my local development environment requirements.

The only thing missing was an automated way to provision a new site. As I explain the mkcert article, spinning up a new site requires a few steps I have to follow each time.

  • create new Apache VirtualHost config files
  • create a new database
  • create a client directory in my local sites directory
  • add a record to my /etc/hosts file
  • create the SSL certs
  • restart the Apache2 webserver

And then I have to do the reverse when I want to delete a site.

So I decided to put these commands together in two sitesetup and sitedrop bash scripts.

To install these scripts to your local workstation, download the separate files, edit the HOME_USER, SSL_CERTS_DIRECTORY, and SITES_DIRECTORY variables at the top to match your local setup, make them executable, and copy them to your /usr/local/bin/ directory. 

wget https://gist.githubusercontent.com/jonathanbossenger/2dc5d5a00e20d63bd84844af89b1bbb4/raw/889ec6da4e1727b63a383256172c65afb9da107e/sitesetup.sh
// edit the variables
sudo chmod +x sitesetup.sh
sudo cp sitesetup.sh /usr/local/bin/sitesetup
wget https://gist.githubusercontent.com/jonathanbossenger/4950e107b0004a8ee82aae8b123cce58/raw/8b1ceb8ca7bf17d04a15f274f1fccdd665e89dd0/sitedrop.sh
// edit the variables
sudo chmod +x sitedrop.sh
sudo cp sitesetup.sh /usr/local/bin/sitedrop

Once installed you can run either

sudo sitesetup sitename

to provision a new site or 

sudo sitedrop sitename

to drop an existing site.

Next step will be to turn these into something that you can install quickly with one command, but that’s still a work in progress.

Categories
Freelancing

Beginners guide to testing your Laravel application

Last night I presented my talk on getting started with testing in Laravel at the Developer User Group in Cape Town. These are the slides for this talk.

Categories
Development Freelancing

How much should I charge as a freelancer/freelance developer?

This question, along with “How do I find clients/work?”, is probably the question I get asked the most from folks starting their freelance journey. And then when I tell them what I charge (or used to charge before I started working full-time at Castos), they respond with shock, as it’s usually triple what they were expecting. So this post is a short summary of links which explain my response to that question.

The definitive guide to calculating your billable rate.

Why I charge the rate that I do.

You are too cheap! (slightly NSFW – language)

Categories
Development Plugin Course WordPress

WP Plugin Tests: planning the course

For personal reasons I don’t tend to publish my year in review or new year goals posts any more. As I start the year, something that I’ve had on my mind since forever was the idea of recording a development related course of some kind.

Here are some of the reasons I want to put some time into building some courses in 2020.

  • I like sharing knowledge with others.
  • I enjoy the process of building content around specific topics.
  • I like to look at areas that are niche/not popular, but necessary, and build content around them.
  • I’d like to find a way to monetize that somehow, to cover the time spent.
  • I find I also learn more about the thing I’m presenting.

At the end of last year I asked some folks online which subjects they felt were missing from the world of WordPress plugin development courses. After gathering the ideas, I started this year by asking my Twitter timeline to vote on what the first course should be.

The winner was Automated testing for your WordPress plugin, which to be honest was a) the course I wanted to create first any way and b) the one I think the world of WordPress plugin development needs the most right now. So here we are.

Planning

I’ve started sketching out the basic outline of what I think the course should contain, and I’m posting it here to gather some feedback. As I think about it some more, and start putting the course-ware together, I’m sure I’ll add to this list, but I want to get some community feedback, in case I miss anything.

If you’re interested in learning about writing tests for your WordPress plugin, please feel free to comment on what I’ve already included, what you would like to see, or anything else you feel should be included.

If you’d like to keep updated about the course and it’s development, or when it launches, please enter your email and hit subscribe below.

WordPress Plugin Automated Testing course notes:

The project – the example plugin we’ll be using to write tests for

  • MailChimp sign up form
  • Posts to MailChimp API
  • Form shortcode

Tools – the tools we’ll be learning about

  • PHUnit
    • WordPress recommended version vs latest stable version
  • WP CLI
  • WordPress Plugin scaffolding

Setup

  • Installing the tools
  • Phpunit.xml config file
  • Command line vs IDE setup

Writing your first test

  • The “adding tests to a legacy codebase” conundrum

Testing

  • Action and filter hooks
  • Testing your methods/functions
  • Testing against the database

Mocking

  • Does the built in WordPress unit tests allow for mocks?
  • Mocking sending an email
  • Mocking an API request 

CodeCeption

  • Setup
  • Unit Tests with CodeCeption
  • Writing your first feature test