As a developer, one of the things that I love to do is read how others created their work. Sure, we’re all a different type of programmer but that doesn’t mean that I’m not interested in the work that others are doing.
In fact, I find that I often learn new things from seeing how other people face the technical challenges of their particular platform.
So, to that end, I thought I’d share the work that went into and that tools that I used to create Single Post Message.
Why Single Post Message?
Simply put, I needed an easy way to add a decent looking post message above some of my posts. It needed to support HTML tags and it needed to render the same in both browsers and RSS readers.
Starting With The User
The longer that I’ve worked in software, the more I despise software that’s written specifically by developers for users. I think this is why we’ve seen a surge in the user exerience and usability fields.
We suck at making things look good.
Often times, we developers are more concerned with getting something to work rather than getting something to look and perform just as good as the underlying architecture. I don’t want to be in that class of developers.
And though I’m not great at it, but I’m trying to get better – each project is an opportunity for exactly that so I started with a simple sketch (using Paper By Fiftythree) of how I wanted to plugin to look for both administrators and users:
Namely, I wanted the administrator or post author to see exactly what the readers would see. The ultimate goal was to narrow that gap as much as I possibly could.
From there, I then backed into the code that would make this happen.
I try to treat each project as an opportunity to employ something that I’ve wanted to learn for sometime. Some projects afford this, others don’t.
In this case, I had the opportunity to use my standard set of tools as well as try out a few new things.
The Usual Suspects
All of my WordPress plugins and widgets start with their respective boilerplates – in this case, my WordPress Plugin Boilerplate. This includes the usual components:
- Specific file and directory organization
- The README template for WordPress plugins
Naturally, this was all done in the context of my local development environment.
CodeKit is an application that I’ve been wanting to use for several months and finally got the opportunity to do so with Single Post Message.
Simply put, CodeKit makes it incredibly easy to introduce a number of preprocessors, minification tools, compressors, and linters into your development environment.
Specifically, these are the changes that were introduced into my local plugin structure:
- In the ‘css’ directory, I added a ‘less’ directory and an admin.less file. CodeKit then compiled and minified the less file into admin.css in the root of the ‘css’ directory.
- In the ‘js’ directory, I added a ‘dev’ directory and moved the admin.js file here. CodeKit then compiled, minified, and linted the source file into admin.min.js in the root of the ‘js’ directory.
For those that are interested, this is the CodeKit configuration that I used:
- LESS files are minified, processed with Bless after saving, and have strict import rules enforced
- I disabled automatic browser refreshing on file save (I’m a bit compulsive with CMD+S)
- Because CodeKit notifies you when there’s an error in saving a file, I opted not to have it bring the log window to the front
I’m extremely happy with CodeKit and highly recommend it. It’s going to become a staple in my development toolbox.
As I started working on the plugin, I was deploying it and using it here on this site with each build leading up to 1.0. This gave me a chance to shake out any bugs in an actual use case prior to releasing it for others to use.
Yes, I’m a fan of having other people test your work and think that it’s one of the best ways for developers to get feedback, but I don’t think that has to exclude us from using our own work especially when we’re creating it to solve a problem that we’re personally experiencing.
After going through the usual process of registering the plugin with WordPress, I then used the WordPress Plugin README Validator to make sure that the README file looked exactly as I expected prior to publishing the plugin.
Though I’m a big fan of GitHub, WordPress uses Subversion to manage all of its projects and Cornerstone is my client of choice.
And that’s it – the setup and tools that I used for building the plugin. Feel free to leave any questions or comments in the comment thread below. Perhaps I’ll continue to do this for future work, as well.