Software Engineering in WordPress, PHP, and Backend Development

Author: Tom (Page 134 of 428)

Reasons For Not Writing Unit Tests

When I had my first internship, I was tasked with maintaining a legacy ASP application. This included everything on the front-end, through the application layer, using Visual Basic and VBScript, as well as the database that was primarily used as a datastore for XML.

What are interns for, though, right?

I’m kidding: I actually like the idea of having junior programmers work on maintenance tasks or bugs at first to get a feel for where things are (or were) before jumping into where they are headed.

At the same time, I was also learning and reading a good bit about unit testing. It was past the time when it was “the hot new thing,” but it had hit a point where a lot of people were talking about it.

It was finding its way into day-to-day conversations. It was becoming part of the curriculum of any software engineering course or material that any software engineer should know. It was coming up in interviews, conversations, blog posts, books, and so on.

In short:

It was becoming impossible to escape.

Either you knew how to unit test, you knew TDD, or you didn’t.

  • if you didn’t, then you might get an SMH from a potential employer,
  • you might get a condescending comment from a peer,
  • or you might get roped into a conversation covered in sheer excitement from that guy over in the cube over who’s been aiming for 100% code coverage since the company rolled out the testing infrastructure.

I’m not bashing testing (because I think it has its place and I think we need to know how to write them) and I’m not downplaying having a significant level of code coverage in a given application (because it is important).

But the amount of testing can be done is also related to a handful of others things that programmers don’t often seem to discuss: time, budget, and [optionally] pragmatism.

This post is already getting longer than what some of us like to read (are you reading this sentence, even?), so I don’t wax poetic about this for too long but if you have the time, entertain me.

If not:

The point that I’m ultimately working towards is that I don’t think it’s always as simple as basically “just write the damn unit tests.”

There are other things at work beyond just that each of which influences what we’re doing.

Continue reading

Promoting WordPress Products Easily

When it comes to promoting WordPress products, or products in general, is not my strong suit. You can ask any number of friends I’ve talked to about branding, marketing, and other things that go into it.

That’s okay, though.

I mean, that’s why we have these kinds of people in our lives right? We treat them as mentors, leverage their experience. And we opt to do the same for others when we’re approached, too.

Although I don’t know much about the above I do know about writing and sharing your content via Twitter to help it reach your followers (and hopefully their followers and their followers followers).

Continue reading

Talking WordPress as a Web Application Foundation

I’ve been interested in using WordPress as a web application foundation for some time now (to the point where I’m almost annoying myself when talking about it).

But with features like the REST API being made available – via plugin or inclusion in core – and with WordPress continuing to grow market share, I think that it’s viability as such continues to make sense.

Maybe it makes more sense now than it did years ago.

Regardless, I had the opportunity to talk with Cloudways earlier this year in a relatively in-depth interview and the topic of WordPress as a web application foundation was part of the interview.

Web Application Foundation

Since it’s something I’ve been talking about, I thought why not include some of that content here?

Continue reading

Using Namespacing and Autoloading in WordPress

It’s not hard to find criticism about namespacing and autoloading in WordPress, and lack thereof. As much as I’d like to see it, I think it’s important to take a practical look at the software as a whole, the requirements, and realize that implementing such organization would require a lot.

Specifically, it would require applying object-oriented programming throughout the entire codebase (which would last longer than a release cycle in and of itself).

It would also require that all hosts who support WordPress on any level (yes, even those supporting legacy versions) can handle the new features.

In short, it’s not an easy task and it’s important to recognize the practical challenges that come with doing so in 13 year old software powering approximately 25% of the web.

It’s not that it can’t be done, that it won’t be done, that people don’t want it done. But it’s requires exceptional planning, execution, testing, and support from a wide array of situations that I don’t know if I can even fully grasp.

With all of that said, though, this doesn’t mean that we can’t use namespaces and autoloading in our WordPress projects.

Continue reading

Get Things Done: An Interview with iThemes

Now and then, I’m asked how I get things done or what are the preferred methods I use.

It’s not as if I’m some authority on the subject – I’m not (and even those who tend to miss a few things, in my opinion). Admittedly, I like to talk about this kind of stuff, but that’s just it:

It’s about being able to manage responsibilities effectively.

Frankly, I think that a lot of the prescriptive strategies aren’t tailored for specific personalities. But that’s for another post.

But this whole “responsibility management” and ideas for how to get things done is not something that’ relegated to one person. There are people who I’ve met in and out of this industry who I try to talk with on a regular basis about the same type of things.

I want to be able to learn from them so I can shortcut making the same mistakes in my life and career.

Continue reading

« Older posts Newer posts »

© 2025 Tom McFarlin

Theme by Anders NorenUp ↑