Category: Articles (Page 214 of 258)

Personal opinions and how-to’s that I’ve written both here and as contributions to other blogs.

Magic Quotes and PHP: Parsing Automagically Escaped Data

November 13, 2013 / Tom / 0 Comments

As far as building projects on or for WordPress is concerned, one of the things that we have to keep in mind is the minimum version of PHP required to run WordPress itself. And at the time of this writing, the minimum required version of 5.2.4.

Of course, if you know your project is going to run on a newer version of PHP, and you have control over that environment, then obviously you have the freedom to write code against that version; however, if you’re building something that’s going to be used across the board for any of the many hosting environments, then you’ve got to take that into consideration.

I mention this, because there have been a number of times when I’ve been working on a particular feature of a project, and I’ve had to reference the PHP manual to see if the given feature of the language is supported by the minimum current version.

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

November 12, 2013 / Tom / 0 Comments

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.

Parsing CSV Files in PHP: Checking The File Type

November 11, 2013 / Tom / 0 Comments

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?):

Read the file
Break each line into an entry into a collection
Iterate through the collection
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.

Overcoming Developer’s Block

November 8, 2013 / Tom / 0 Comments

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.

From Pair Programming To Peer Discussions, Debates, or Whatever

November 7, 2013 / Tom / 0 Comments

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.