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.
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.
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.
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:
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.
Although Automattic uses Subversion for source control both for its themes and plugins, I keep a number of my plugins in Git repositories during development.
Additionally, 8BIT uses GitHub to keep track of all of our source code, issues, milestones, and so on. When it’s time to make a commit, we usually sync the Git repository with its Subversion equivalent.
I’ve used a number of different source control systems during my career – some distributed, some not – and I’ve never been someone who fights a so-called religious war over which is better. Each source control system has its advantages, disadvantages, and each one fits differently within the context of how a person or a team operates.
Currently, I really like Git but a lot of that has to do with how GitHub, the site, fits into my workflow. Sure, there are things about Git that I like, but it’s GitHub’s organization that fits how I do work.
Anyway, overtime I figured I’d discuss my thoughts on WordPress source control. In this post: commit messages.