Tag: Software Development (Page 16 of 20)

Design Patterns and WordPress (And Resources!)

November 11, 2016 / Tom / 0 Comments

For whatever reason, it doesn’t seem common that we talk much about design patterns and WordPress. And that’s odd to me.

Maybe I’m not talking to the right people, maybe I’ve got my head in the sand, maybe it’s just not something about which people share much information, or maybe people who work with WordPress don’t care that much about design patterns at all.

The architecture of WordPress is not the same as using design patterns iin WordPress.

But if you’re using WordPress and you’re building more than a theme or a simple plugin, the odds of you building something more advanced and not taking advantage of design patterns seems highly unlikely.

Whatever the case, if you’re someone who’s working on advanced solutions – perhaps web applications, perhaps having your components talk to third-party components, or whatever the case – then it wouldn’t hurt to have a reference of popular design patterns and antipatterns would it?

Sharing Code: A Good Opportunity To Exchange Ideas

November 8, 2016 / Tom / 0 Comments

In the previous post, I happened to share a screenshot of some source code that was from a 0.1.0 (or, perhaps more appropriately named, an MVP) of a project I’m writing (and it turned out to be a good opportunity to exchange ideas with someone else).

Exchange ideas based on your source code.

Not long after it had gone live, I received a tweet containing the following comment:

Interesting to see how differently people work. There at least four things in your screenshot that I wouldn’t do.

From experience and from being online long enough, I know there are certain segments of our industry who look at something like this and think “Burn – he’s got it down and he’s going to take him to school.”

Except not really.

I believe I’ve talked about this in previous posts, but what I’m getting at is when others make comments like this to you, approach it in two ways:

Understand they are coming from a place of [likely more] experience,
Ask what things they would do differently. Odds are they have good reasons and are likely in a position to help you get better at what you’re doing.

Later in the post, I’ll share the entire conversation that took place on Twitter but I think it’s important to mention that, at this point in time, I know the person in question well enough to have both respect and no problem in engaging them in further questions and conversations about things like this.

But it hasn’t always been that way. So for those of you who are getting into sharing your code and learning how to field feedback that comes regardless of the format, then this is primarily for you.

Intuition, Laziness, Discipline, and Experience

November 4, 2016 / Tom / 0 Comments

When I sat down to write this post, I didn’t have an idea as to convey what I wanted to say. (And that’s a ridiculous thing to feel when you’re writing. )

Honestly, I just had a single sentence that I’d jotted down a few days ago and was going to flesh out in more detail.

Developer Intuition

I wrote:

You begin to develop a sense of intuition for how something should be designed or implemented.

It’s not even really a fully developed thought. It’s just a statement (and I’m not even sure it’s a good one) that I was going to explain in more detail. But then I stumbled across this post and found this statement:

I’ve become a big fan of the “do less & be lazy” approach to building things.

And though the post is about the performance of pages using web fonts, it’s still related to what I want to convey.

All that to say I didn’t have a post, just a statement, and I needed an opener. In reading another post, I found it in the quote above.

Using Configuration Files for Class Properties

November 3, 2016 / Tom / 0 Comments

The idea of using some type of configuration files for a project isn’t anything new. Nor is the idea of using a format such as JSON.

Look in any directory for a number of major applications that you use, be it a source control manager, IDE, a build tool, et al., and you’re likely to find some type of configuration file. (And when it comes to build tools, many of us already write configuration files using JSON specifically to tell the build tool information about our project.)

Configuration Files as seen in VS Code.

Yesterday, I shared some of the challenges that can come with creatively solving problems and said that I was going to talk about something I’ve been working on:

With all of that said, it wouldn’t be particularly honest of me if I didn’t discuss and share my code, though, would it?

So that’s the purpose of this post: To talk about one way that I’ve been looking to solve a problem in a project on which I’m working.

The Intimidation of Creatively Solving Problems

November 2, 2016 / Tom

One of the things about programming in the same “environment” for an extended period is that you get comfortable with the way you tackle similar problems.

Case in point:

When you start writing a plugin, you likely have an idea as to how you will implement something before writing it.

I’d venture to say that this begins to happen while the client is describing their problem. I don’t think there’s anything inherently wrong about this. In fact, I believe that it’s probably a good thing as it’s a sign you’re learning your way around the API, how to structure files, assets, and so on.

But at what point do we start coasting on autopilot? Or, perhaps a better way to ask it, is when are we just going through the motions of solving different-but-similar problems?