The content of this post is essentially the text version of the talk that I recently gave at WordCamp Atlanta 2019. Sure, some parts are left out, and some parts are modified but I do that since this is a different medium and certain statements or examples don’t translate as well. 🙃
The purpose of the talk, as you can tell from the title, is presenting a case for building web applications with WordPress.
I believe it can be done – because I’ve seen it done and worked with teams who do it – but before actually looking into the reasons why I think it’s a good foundation for certain applications, I also want to clarify terminology that we toss around a bit.
Ultimately, I want to define my terms so there isn’t any confusion, and then I want to use said terms to move forward.
But enough of the setup, right? Here’s the content of the talk.
Continue reading “A Case for Building Web Applications on WordPress A high-level overview of how it’s possible to go about building web applications on WordPress.“
How many times have you looked at someone’s code and stated:
I’m not using this because it doesn’t look well-written.
And in this case, “look well-written” might either be a substitute for:
- “look like how I would write it,”
- “seem to make sense to me.”
Sure – there are times where using open source code is risky. We know this from the various software and services that show up with vulnerabilities. But, at least for this post, treat those as the exception – not the rule.
This means we’re left with looking at something we may use but opt not to use because it doesn’t seem to be written in a way that we think it should be written.
Continue reading “A Misaligned View: Prioritizing Peers Over Users When working on a project, make sure that you’re not constantly prioritizing peers over users.“
In my experience, the way we first interact with the repository design pattern often influences how we think about the pattern. (The whole first impressions are lasting impressions, right?)
The purpose of this post is to show how it can be implemented in WordPress specifically when writing object-oriented plugins to read data (writing data may be covered in another post), but before doing that I tried to think of a few consistencies among the variations of the pattern that I’ve seen.
Generally speaking, this is what I think a repository pattern should do:
- provide a single place to read data,
- abstract the details of how the data is accessed,
- and have a consistent interface for doing so.
This means that whatever it is you need to retrieve from the application can be retrieved from the database. But how its retrieved can be considered a black box. That’s up to the developer implementing the pattern.
And in the case for those who read this post, that’s most likely us.
Continue reading “A General Example of the Repository Pattern in WordPress The repository pattern provides a consistent way for how data can be retrieved. Here’s how it can be implemented in a WordPress plugin.“
Back in 2011, I was doing a lot of reading on working with legacy code, code quality, and refactoring.
There’s a quote by Martin Fowler (who literally wrote the book on refactoring) attributed to Uncle Bob that’s stuck with me – and I’m sure many, many programmers – ever since:
always leave the code behind in a better state than you found it
The thing about this particular idea is that I think it might sound a bit more idealistic until you really start to try to practice it in everything that you do.
That is, if you take it at face value it sounds like anytime you need to work on a codebase, then you need to leave the entire codebase better than when you found it. But the more I’ve tried to apply this rule in my day-to-day work, the more practical, the cleaner, and the more maintainable WordPress-specific code has become.
So when it comes to refactoring WordPress-based code, what does that look like?
Continue reading “Simply Refactoring WordPress-Based Code When it comes to refactoring WordPress-based code, what does that look like?“
I am not a fan of the “move fast and break things” mantra that Facebook used to hold and I don’t think there’s a reason to have to justify my opinion on that. I’m glad they’ve sense moved away from it (or appear to have – I don’t know what they do internally).
I am, however, a fan of the “Release Early” idea. Sometimes this is also coupled with “Release Often” so we get the near-infamous “Release Early, Release Often” phrase in the software development nomenclature.
I don’t necessarily think they have to go together.
But when it comes to the idea of “Release Early,” it seems that no matter what you release, if it’s not up to a customer’s expectation, then it’s no good.
And I get it. At least from that perspective.
But what if you’re a fellow software developer and have some insight on to how this kind of stuff works?
Continue reading “Release Early: A Case for a Strong 1.0 When it comes to the idea of “Release Early,” it seems that no matter what you release, if it’s not up to a customer’s expectation, then it’s no good.“