Category: Tips (Page 3 of 10)

Various articles covering anything from how to programmatically achieve a certain task to useful ways that I’ve found to manage my time.

HTML Code Styles: What Are Your Strategies? – Part 2

September 10, 2013 / Tom / 0 Comments

This is a follow-up post to one that I originally wrote in December 2012. Be sure to read it, as well!

Months ago, I wrote a post on some of my preferred HTML Code Styles during which I shared two specific things that I do whenever I am writing markup.

Specifically, I do the following things:

Comment Terminating Tags
Underscore Class Names

When it comes to writing code, there are always going to be standards – well, at least there should be – that depend on the proverbial sandbox in which we’re playing.

These standards will outline certain things that we should do, but there are always bound to be gray areas. Case in point: I know people have often commented (no pun intended) that they aren’t a fan of the way that I terminate certain closing blocks with comments such as `// end if` or `// end while` or `// end class`.

Which is completely fine – to me, that’s an example of a gray area that gives us, as developers, room for implementing our own unique styles. But then there are others that really should be reconsidered.

And that’s what I’ve had to do with some of my markup styles.

Properly Instantiating WordPress Plugins

February 20, 2013 / Tom / 0 Comments

One of the things that Pippin, Norcross, and I have been talking about during the course of building Comments Not Replied to is the best practices for instantiating WordPress Plugins.

Specifically, we’ve gone from simply creating an instance of the plugin, to storing it within the PHP $GLOBALS variable, as well and then debating whether or not to implement the plugin as a singleton.

There’s more to this that I’ll cover in a follow-up post, but the most significant thing worth sharing in this post is why we’re discussing how to instantiate our plugin.

Using Kaleidoscope For a Git Diff Tool

February 18, 2013 / Tom / 0 Comments

In a previous post, I’ve mentioned that GitBox is my git client of choice. In short, I think it’s UI is simple and it’s extremely easy to manage all of the standard git tasks.

And, of course, if you find yourself needing to issue some commands from the command line, it’s really easy to install git for the command line.

But for anyone that’s done an any amount of work with source control, you know that a portion of your time is resolving merge conflicts and sifting through code using a diff tool to help manage the merging.

Though there’s a lot of good options available, the latest version of Kaleidoscope has become my favorite application for managing code diffs. After installing it, here’s how you can configure it for your environment.

How To Use Sequel Pro with MAMP For Local Development

February 7, 2013 / Tom / 0 Comments

For those of you who have read my previous blog posts, you know that my local development environment consistents of using MAMP for Apache, PHP, and MySQL.

Though I’m not particularly hardcore about any given IDE, I’ve been using Coda 2 since it was released and have enjoyed it especially because of its integrated database environment.

But with the need to work with several other remote databases outside the context of an IDE, and the recent release of Sequel Pro 1.0, I thought it may be useful to share how I’ve also been using Sequel Pro with MAMP.

Why I Terminate Blocks with Code Comments

January 17, 2013 / Tom / 0 Comments

Thanks to a number of open source contributors, I released WP Audio Player 1.3 to the WordPress plugin repository. For one of the pull requests, I mentioned the following:

I always terminate my blocks with a closing comment. Please keep this in the file.

Travis Northcutt also asked me about it via Twitter:

@tommcfarlin curious about always terminating blocks with a closing comment – what's the rationale there?

— Travis Northcutt (@tnorthcutt) January 14, 2013

When it comes to writing code, I try hard to make sure that anything I do that’s outside of the normal coding conventions for a given platform has a rationale behind it.

Case in point: Ending my terminating braces with code comments.