A few months ago, I reluctantly started to try out using the dark theme that comes with macOS and iOS. I’d already been using a similar theme in my IDE and my terminal, so why not take the plunge for the whole experience across the OS?
Like anything new, it took some getting used to but it’s definitely grown on me up to the point where I spent time looking for something that would allow me to really tweak the tools I used the most to make sure that I’m actually enjoying the day-to-day work that I do.
And that’s where Dracula, hat tip to my colleague Mike England, really got the ball rolling for me.
If you’ve installed Node via Homebrew and, at any point, are trying to execute a shell script to start up a containerized environment (or maybe something else – I’m speaking solely from my experience) and you’re presented with this message or something like it:
dyld: Library not loaded: /usr/local/opt/icu4c/lib/libicui18n.64.dylib
Referenced from: /usr/local/bin/node
Reason: image not found
For as long as I’ve been writing on this site, I’ve used a combination of syntax highlighting, GitHub gists, or
pre tags to help share code relevant to a given post.
But the more technical articles I read and the more that I see we, as an entire industry, start to rely versus utilize tools of Stack Overflow and other sites, the more I wonder how much we really understand what we’re writing (or even care) so long as the end results just works.
This isn’t a commentary on how quickly we should ship something. Instead, it’s about how we solve a given problem while also truly learning what it is that we’re incorporating into our codebase.
If, at some point, you’re working on some front-end code using NPM and when you attempt to install a package, you get a message that resembles something like this (you’re mileage obviously may vary):
TypeError: Cannot read property 'properties' of undefined
at Object.<anonymous> ([...]/node_modules/webpack/bin/webpack.js:156:2)
That is, the primary problem being: TypeError: Cannot read property ‘properties’ of undefined
The best solution I’ve found to the problem is to remove
webpack and the
webpack-cli and reinstall it using the
Remember that WordPress uses the event-driven design pattern and although we often refer to actions and filters, the concept comes down to hooks. The flow of control through the program goes something like this:
- Execute the program,
- Whenever the program comes upon a hook (in WordPress, we’ll see
apply_filters), iterate through all of the registered hooks,
- Return control back to the program,
- Execute until the end.
This isn’t completely different from the Publisher/Subscriber Pattern (or PubSub, for short) but there’s a key difference: The Event-Driven Pattern simply signals that something has happened and if there are hooks, they will fire. The PubSub Pattern will tell a registered subscriber to do something.
Anyway, back to hooks in WordPress. Keeping the two concepts of hooks that we have may be most easily done by thinking of them like this:
- Actions are for doing something,
- Filters are for processing data.
If you’re looking to approach WordPress development in an object-oriented fashion, tightly coupling your code to WordPress core by registering your classes via hooks to the core application is not a good idea.
In other words, don’t register your business logic with WordPress. Keep them separate. Here’s a litmus test for if your work is tightly coupled with WordPress: If you can’t run a unit test against your class without loading WordPress, it’s tightly coupled.
So what’s the solution? Delegation.