Tag: Software Development (Page 9 of 20)

Using Homebrew to Install Node (To Install Gulp)

November 1, 2017 / Tom

In a previous post, I’ve talked about Homebrew (and why it’s part of my setup).

Using Homebrew to Install Node (To Install Gulp)

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.

A Few Gulp Packages for Starters

October 20, 2017 / Tom

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).

A Few Gulp Packages for Starters

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.

Think of them this way: If you’re looking for ways to work with Sass, JavaScript, and image optimization, these are good libraries.

Why Bother With Autoloading in WordPress, Part 3

October 18, 2017 / Tom

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.

Why Bother With Autoloading in WordPress, Part 2

October 17, 2017 / Tom

In the previous post, I covered a few points as to why I think that include_once, require_once, and other similar statements result in poor development practices (at least when it comes to the work we’re doing with our WordPress projects).

If you haven’t read it, no big deal. The gist of the post is that these statements make:

debugging more difficult,
tracing code harder to do.

Ultimately, they are things we can avoid. I ended the post with the following:

This still leaves the question of why autoloading (or any inclusion of third-party files) is needed at all.

And though I’d love to cover all the details in this post, it’s going to take this and one more post as its important to understand some foundational topics on languages, interpreters, and compilers before getting too far ahead.

Why Bother With Autoloading in WordPress, Part 1

October 16, 2017 / Tom

One of the easiest things that we can do when working on WordPress plugins is to drop require_once or include_once statements throughout our code.

And why not? It’s an easy way to bring in all of the necessary files or dependencies for a given class, have it easily readable, and not have to worry about creating huge files of code. That is, it helps us simplify what we’re writing so that we’re able to have our classes [mostly or ideally] do what they are doing well.

If you’ve read this site for the past year or so, though, you know that I’m a fan of autoloading and it’s something that I think anyone working with PHP – regardless of if you’re using WordPress or another platform – should use.

But it raises two questions especially if you’re just starting out:

Why bother with autoloading when there are other ways to handle loading dependencies?
How does autoloading stack up against compiled languages?

So I thought it would be worth answering this in the next couple of posts.