Tom McFarlin

Software Engineering in WordPress, PHP, and Backend Development

Page 300 of 428

Productize Your Service (or “Charge For The Work You’ve Already Done, Again.”)

One of the things that I often hear people talking about is whether or not they want to work on products or if they want to work on services.

Or, more specifically, they’ll ask:

Do I want to be a product company, or do I want to be a service company?

The truth is, I’ve done this myself.

I’ve had the pleasure of working with a team of other guys at 8BIT where we built Standard – a product by a product company – as well as for myself under the freshly re-branded Pressware – which is a service company.

And to be honest, I teeter back and forth between both: I enjoy working on products, and I enjoy working on services.

Each comes with their own advantages and disadvantages, and there’s a lot to be said about both, but the purpose of this post isn’t really about that.

Continue reading

Parsing CSV Files in PHP: Checking The File Type

When it comes to parsing CSV files, the way you go about doing it is relatively the same (hence the need for the standard format, right?):

  1. Read the file
  2. Break each line into an entry into a collection
  3. Iterate through the collection
  4. Create an object or element with attributes based on the data in the current given line

Sure, this is a high-level view of how it’s done, and your specific implementation may have finer nuances, but – as I mentioned – I think its safe to say that the way we go about parsing a file is the same regarding of what we do with the data once we start reading it.

When you’re working on an implementation of CSV parser and you’re accepting data from an upload, then there are several things that need to be checked such as the validity of the file type.

For example: If a person uploads an image, you don’t want to proceed with parsing it; however, if they upload an actual CSV, you obviously want to process the file.

But this can be tricky depending on the operating system.

Continue reading

Overcoming Developer’s Block

Every so often, I’ll receive an email or a comment asking how one fights “Developer’s Block.”

Of course, not everyone phrases it or labels it that way, but that’s what it is. In short, people will generally say that they want to work on something or build something, but when they sit down to try to do so, they aren’t sure where to start or what to build.

This isn’t to say that they aren’t capable, but that they’ve simply hit a wall as it relates to figuring out what to build.

No idea.

Stuck.

And I think any developer who has attempted to work on something outside of their 9-to-5 knows this feeling all too well.

Continue reading

From Pair Programming To Peer Discussions, Debates, or Whatever

I think most anyone who has been in some sort of development community for a fair amount of time has least heard of the idea of pair programming.

If not, Wikipedia defines it as:

Pair programming is an agile software development technique in which two programmers work together at one workstation. One, the driver, writes code while the other, the observer or navigator, reviews each line of code as it is typed in. The two programmers switch roles frequently.

The advantage to this is that you’ve got two people working on a single component of an application which should ideally result in more robust code because you’re actively having your code reviewed, you have a person able to think about the code being written within the larger context of the application in order to foresee problems, and you have a person that’s actively developing the solution for the given task (be it a bug, feature request, or something else).

And sure, we’ve all been told that it’s a good idea to find a person or a community that has more experience than us so that we may learn from them; however, I don’t think we hear – at least not often enough – that it’s also beneficial to find people of equivalent levels of experience who also think differently about problem solving.

Continue reading

Updating The The WordPress JavaScript Coding Standards

Comments are closed on this post. Let's keep the discussion on the Make WordPress blog.

Earlier this year, I drafted the first version of the WordPress JavaScript Coding Standards (and I discuss it more in-depth in this post).

When I contributed the first version of the standard, the conventions were based largely on writing vanilla JavaScript, and on the existing WordPress PHP Coding Standards; however, there has recently been a surge of interest in continuing to develop the JavaScript Coding Standards.

Because I obviously have a strong interest in this, because I believe that more and more sites and applications are doing more work on the client-side, and because I want there to continue to improve the existing WordPress codebase, I wanted to make sure that there is about to be a major update to the JavaScript coding standards.

Continue reading

« Older posts Newer posts »

© 2026 Tom McFarlin

Theme by Anders NorenUp ↑