When it comes to writing software, two of the most popular schools of thought are:
- YAGNI (or “you aren’t gonna need it”),
- and Generalization (or maybe “premature generalization”).
They aren’t necessarily exact opposites, but for where I’m going with this, it’s worth treating them as such.
In my experience, projects boil down to projects for customers or products that you’re building to sell. This isn’t to say we don’t build products for customers, so maybe it’s just easier to say:
- “Hey, I’m building this for someone else,”
- or, “Yeah, I’m building this for me [for profit].”
Here’s the thing: I often find that when it comes to building things for other people, it’s easier to want to go about Generalization for their code and YAGNI for our code.
So which one is right? Or is there even a right one?
Since I’ve written about CodeKit and Composer (more about the latter in recent posts, really), I’ll occasionally get emails asking which do I really prefer using whenever it comes to working on projects for others.
And the short answer is that they aren’t mutually exclusive. If anything, they can complement each other. They aren’t substitutes for each other.
As I’ve moved from less and less frontend-oriented projects, the less I use CodeKit. And the more I’ve moved more towards backend-oriented development, the more I use Composer.
Furthermore, front-end development is different than back-end development, right? So, again, why would we ask:
Should I use CodeKit or Composer?
That’s where the longer answer comes into play.
In a previous post, I’ve talked about Homebrew (and why it’s part of my setup).
I’ve also talked about Node, Gulp, and a few starter packages that I recommend for getting started with using them in WordPress development.
But one of the things I’ve not talked about is how to install Node using Homebrew.
Software like Gulp and other utilities aren’t new. For those who haven’t used them before, it can be a little daunting to get started (but it really shouldn’t be).
In comparison to tools like CodeKit (which I still like and recommend, depending on the project), they have a little more overhead regarding getting them set up, configured, and ready to go.
But once you’ve got it all set it up, it can be really useful with a distributed team regardless of operating system, and it can help it make your build process a bit more robust.
That’s not the purpose of the post, though. Instead, here’s a list of a few packages for starters.
In the last post, I said we couldn’t afford some of the same luxuries that statically typed, compiled languages have. Specifically, I was talking about the idea of not having to deal with autoloaders.
Instead, compiled languages can take all of the files that make up the program, process them, and bundle them up into a single binary.
But to do that, it needs a specific type of a program to do that.