Software Engineering in WordPress, PHP, and Backend Development

Author: Tom (Page 147 of 428)

Yet Another Blog (Gotta Go Your Own Way)

This blog has been discontinued and you can read more about it in this post.

The idea of starting another blog seems daunting especially when I try to write for this one on a daily basis. But to say that I enjoy writing is a bit of an understatement.

The other caveat is that I try to be pretty focused on the type of material that I write about on this site. I’ve made some mistakes with this blog, sure, and I’m working on rectifying that especially over this next month.

Several things have come from this blog, though. For example, I get tweets, emails, and other forms of [sometimes creepy but maybe just kidding] messages about how I run my business, how I manage my time, what applications, sites, services, and so on that I recommend.

All of those topics are fun to talk about, but they don’t fit in with the whole idea of “a perspective on professional WordPress development.”

So what am I supposed to do when there’s more that I’d like to write about but don’t have a place to do it?

Continue reading

Updating Atom and the WordPress Coding Standards

For those who have read my Atom and WordPress Coding Standards post, then you should have everything you need when it comes to setting up the editor to evaluate your code with the WordPress Coding Standards.

Recently, though, the 0.10.0 release of the coding standards were published on GitHub, and it brings a lot of changes.

Atom and the WordPress Coding Standards

If you’re looking to begin upgrading to this new change, there’re a few caveats that you may experience when working with Atom and the WordPress Coding Standards.

They’re easy to address, though.

Continue reading

Singleton Design Pattern and Dependency Injection, Part 3

In the previous two posts (available here and here), I talked a bit about the Singleton Design Pattern, dependency injection, and dependency injection containers.

Singleton Design Pattern as a Dependency Injection Container

Not that kind of container (but it’s still a cool shot).

These are all topics that I think are important for developers to know and to understand. If you’ve not read the previous posts, then I recommend it because the code that’s shown later in this post assumes you know a little bit about each of the topics mentioned above.

Furthermore, this is going to be a bit shorter as it relates to the previous two posts. The purpose is simply to show how to use a singleton as a simple dependency injection container.

Continue reading

Singleton Design Pattern and Dependency Injection, Part 2

In the previous post, I said that I was going to talk about how to use the Singleton Design Pattern as a simplistic way to introduce a dependency injection container into a project.

The Singleton Design Pattern and Dependency Injection Containers

One of the best comments I’ve seen about dependency injection containers comes from Stack Overflow (and Joel Spolsky, even):

IoC containers take a simple, elegant, and useful concept, and make it something you have to study for two days with a 200-page manual.

And there’s a time and a post for where I could digress, but that’s not this post. Instead, there are a few nuances about this idea that I want to clarify before I go any further:

  1. Dependency Injection Containers are more than just ways to store objects. They handle other additional logic. I’ll cover more about this later in the article.
  2. I don’t recommend sticking with an implementation of the Singleton Design Pattern for a container (or for very many things, for that matter).
  3. The purpose of showing this as a strategy is a way to show how you can take a project with a tight deadline, a desire to use software development best practices, and find some practical middle ground.

All of that to say is that what I’m going to show is not what I consider being a best practice for using dependency injection containers.

Instead, it’s a way to “meet in the middle” when it comes to working under pressure for building solutions for others all the while not wanting to sacrifice sound engineering principles.

Continue reading

Singleton Design Pattern and Dependency Injection, Part 1

The Singleton Design Pattern is something that I’ve talked about before in previous articles.

As Wikipedia so eloquently defines it:

In software engineering, the singleton pattern is a design pattern that restricts the instantiation of a class to one object. This is useful when exactly one object is needed to coordinate actions across the system.

If you’ve done any work with object-oriented programming and familiar design patterns, then it’s likely that you’ve come across it (if you haven’t used it).

Depending on who you ask, the singleton design pattern may be treated as an anti-pattern, like some weird use of a “poor man’s namespace,” or one of the many other negative views of it.

Though these perspectives aren’t necessarily wrong, there are times where it’s okay to use it.

Continue reading

« Older posts Newer posts »

© 2025 Tom McFarlin

Theme by Anders NorenUp ↑