Categories
Development Experiences Freelancing

An experiment in dark vs light themes

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

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
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
Categories
Development Freelancing

A beginners guide to testing your existing Laravel application

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.

Confident Laravel (course, highly recommended)

Grumpy Learning (course and books, also recommended)

Laravel HTTP tests documentation

Laravel Dusk tests documentation

Snipe Migrations

DuskDatabaseMigrations Trait

Categories
Development Freelancing

WordPress Plugin Development Best Practices

This morning I presented a workshop at WordCamp Johannesburg.

Here are the slides for that workshop

Here is the GitHub repository

If you want to see the updated plugin code, with the security fixes, you’ll need to switch to the feature/more-secure-plugin branch.

Categories
Development Experiences Freelancing

The two worst things you can say to your freelancer.

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 us 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.

Categories
Development Freelancing Laravel WordPress

A Quick Hack to Writing Testable Code

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”

Shaine Gordon, CTO at Realm Digital

Let me explain that by means of an example.

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.

In PHP, that could look something like this:

function my_string_parser( $string ) {
	$string = strtolower( $string );
	$string = str_replace( array( ' ', '.', ',' ), '', $string );
	$string = ucfirst( $string );

	return $string;
}

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:

function test_my_string_parser() {
	$string        = 'My test, string.';
	$parsed_string = my_string_parser( $string );
	$this->assertEquals( 'Myteststring', $parsed_string );
}

Based on the code above, this test would fail. My problem is, at what point in manipulating the string, does my function fail?

However, if I refactor my initial code a little:

function my_string_parser( $string ) {
	$string = my_string_to_lower( $string );
	$string = my_string_remove_punctuation( $string );
	$string = my_string_ucfirst( $string );

	return $string;
}

function my_string_to_lower( $string ) {
	$string = strtolower( $string );

	return $string;
}

function my_string_remove_punctuation( $string ) {
	$string = str_replace( array( ' ', '.', ',' ), '', $string );

	return $string;
}

function my_string_ucfirst( $string ) {
	$string = ucfirst( $string );

	return $string;
}

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.

Categories
Development WordPress

Unit Tests for your WordPress plugin using WP CLI and PHPUnit

Often when I write a blog post, part of the reason I write it is to document things that I tend to forget. This is one of those times.

Requirements:

PHPUnit: At the time of this writing, WordPress only supports the latest stable 7.x version of PHPUnit, and recommends installing it globally.

wget https://phar.phpunit.de/phpunit-7.5.9.phar
chmod +x phpunit-7.5.9.phar
sudo mv phpunit-7.5.9.phar /usr/local/bin/phpunit
phpunit --version

WP-CLI: If you’re developing on WordPress and you’re not using WP-CLI, you are missing out on some amazing tools.

curl -O https://raw.githubusercontent.com/wp-cli/builds/gh-pages/phar/wp-cli.phar
chmod +x wp-cli.phar 
sudo mv wp-cli.phar /usr/local/bin/wp

Set up

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.

bash bin/install-wp-tests.sh wordpress_test root password localhost latest

And you’re done, go forth and write some unit tests for your WordPress plugin.

Categories
Development Freelancing WordPress

Travelling the web on the WordPress HTTP API

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.

You can find the slides here

You can find the GitHub repository here

Below are the videos I’ve recorded of me completing the workshop content.

Part 1
Part 2
Part 3