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

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