Author: Tom (Page 81 of 427)

Let the Code Review Process Stand on Its Own

May 10, 2018 / Tom

The more projects I work on with people who I hold in high-esteem, especially as it relates to programming, the more I find myself wanting to pre-justify the reasons I’ve made a decision about how I’ve solved a problem.

This isn’t to say that I try to be defensive about what I’ve done from the start. Instead, it’s more of an attempt to try to justify or rationalize the reason I did something so the person reviewing my code understands it and doesn’t think ill of it. The thing is, I’ve never really had an experience – at least not in the last, say, half a decade or more – completely obliterate my confidence.

Code Review, Part 1 via xkcd

Instead, they’ve done one of three things:

The person reviewing the code has made a recommendation as to how the code can be improved,
The person reviewing the code has asked why I did what I did (either to better their understanding or to see if there’s not a better way the problem could be solved),
The person has provided insight on how to rearchitect the solution simply.

And regardless of which of the above is used, I’m generally grateful.

Thus, one of the things I’ve been trying to get better at doing is merely deciding on how to implement a solution, commit the code, and let the code review process do its thing.

Writing Unit Tests with PHPUnit, Part 3: XML Configuration

May 9, 2018 / Tom

In the past posts in this series, I’ve covered the following two topics:

Writing Unit Tests with PHPUnit, Part 1: The Set-Up. A guide to getting started with writing PHPUnit tests through the use of a basic cache and using the setUp method of the framework.
Writing Unit Tests with PHPUnit, Part 2: The Tear Down. A tutorial on how to write unit tests that properly leverage the setUp and tearDown methods of PHPUnit.

Each of the above is meant to provide a primer for how to get started with writing very basic unit tests. Things can get more complex especially as an application or project grows (but that’s always true, right?).

But to make sure one is prepared for that, there’s one final component to unit testing that I believe we should focus on and that’s understanding the PHPUnit XML Configuration File (which you may have seen in other projects as phpunit.xml).

Developer Fitness in 2018: Quarter 1

May 8, 2018 / Tom

For the last few years, I’ve been writing a bit about developer fitness, why I think it’s important, and my goals and progress.

You can read a bit about what I’ve shared in the previous posts:

The purpose of this post is to go a bit further into what my goals have been first the first quarter of the year, what I’m aiming to do in the second phase of the year, and some additional thoughts on the devices I’ve been using.

Running Multiple Versions of PHP with Homebrew

May 2, 2018 / Tom

One of the challenges with building solutions on WordPress is working with the various environments each host provides.

That is, some are still running very old versions of PHP; others are running newer versions, but even then there are variations among them.

Case in point: I’ve been running PHP 7.2 on my local machine for development for some time; however, I’m currently on a project where a few of the dependencies on the continuous integration tool offers support only for PHP 7.1.

And because I like my development environment to mirror the staging and production environments, I think it’s important to make sure there’s parity.

If you’re using a package manager, it’s pretty easy to get going with multiple of versions of PHP with Homebrew, but you may run into a couple of snags as it relates to running it alongside Valet.

A Quick Guide to Shells in macOS

May 1, 2018 / Tom

If you’ve read any instructions on the web for how to install something, you’ve likely read a statement about adding something to your $PATH. More specifically, it probably included an export statement, a directory, and then a file into which to pipe the command, right?

In fact, you may see a directive like this:

Make sure the ~/.composer/vendor/bin directory is in your system’s “PATH”.

Which means that you should do something like the following:

export PATH="$PATH:$HOME/.composer/vendor/bin"

But if you’re new to working in the terminal, let alone environmental variables, how are you supposed to know how to translate the statement into the above command?