Easy Content Deployment for WordPress: RAMP.

By far the most hideous part of continuous development is database migration. While we have stellar tools for source code management, the database layer seems to be just abstracted enough to be painful.

I’ve just learned of RAMP through the stream of tweets from #wcsf and I’m impressed.

RAMP does what it can to tackle the problem we never want to deal with: keeping your staged WordPress content in community with your production WordPress content.

RAMP allows you to make all the changes you need in your staging environment, then selectively push these changes to your production site. You can set up a new section of your site, upload some images to fill out a nice carousel for it, and add a link to it on your home page. Once this content has been reviewed and approved, you can go to your RAMP page, select these content changes, and push them to your production site.

Do take the time to check out their video tour, the entire process seems extremely polished from start to finish.

Performance should be a concern of yours if you do front end work. Speed is of the essence, and it’s (rightfully) becoming a focus. A simple thing to do to boost page speed and performance is to reduce HTTP requests. There’s science behind it, but the generalist view is: the fewer HTTP requests the better. A stellar way to reduce requests is to use image sprites in your style layer.

A sprite is a conglomeration of all the (non-repeating) image assets of your design into a single image to be referenced and obscured and in doing so having a single HTTP request to retrieve any number of pseudo-’images’. The trouble with spriting is that it takes planning and can be tedious. Luckily, spriting can be automated to a certain extent, and tools like Spritemapper make that a bit easier.

Spritemapper seems very well put together, and I can not wait to find an automated solution that will help me not have to keep track of my sprites manually.

Sublime Text 2, also known as TextMate 2 in my office, is becoming increasingly useful to me. The only trouble thus far is the lack of community involvement to the extent of TextMate. That’s to be expected, it’s an alpha that went cross platform two seconds ago.

All that aside though, it’s an impressive alpha. I seriously love it’s potential and I’m really hoping to make it my own over the next few months. Naturally, the biggest hangup is the lack of tools I’ve become so accustomed to in TextMate. The great thing there is that the snippets and color schemes can be carbon copied into Sublime Text 2, the only outstanding items are Commands. Those aren’t directly portable from TextMate to Sublime Text 2.

I work in HTML, CSS, JavaScript, and PHP. In TextMate I make heavy use of the validators because it’s not an IDE and doesn’t have inline validation as you would find in an integrated environment. Sublime Text 2 doesn’t come with any such validators out of the box, but there are some forum posts. I found some resources on getting JavaScript validation working in Sublime Text 2:

Sublime Text 2 (Alpha) Google Closure JavaScript Linter Build package
(V2 only) JavaScript Google Closure Linter Build

I went through the process of getting Google Closure Linter installed and running fine via Terminal, but got [Errno 2] File not found errors in Sublime Text 2. Additional Googling to find out why got me nowhere so I went with JSLint for the time being and thought I’d share how.

Adding JSLint validation to Sublime Text 2
To implement JSLint we’re going to first need JSLint. There are a number of resources for this, but I went with an OS X executable provided courtesy of javascriptlint.com. I made a new folder in my Applications folder and called it a day. JSLint is prepped and ready to go.

The other half of this puzzle is integration with Sublime Text 2. To do that, you’ll need to create a new Build System:

Upon invoking that menu, Sublime will give you an empty file to work with, outlining the structure of Build Systems. Sweet, but what to do with that? We want to send the current file we’re working with to JSLint for validation. To do that, our Build System will look like this:

{
"cmd": ["/Applications/jsl/jsl", "-process", "$file"],
"selector": "source.js"
}
Note the path to Applications/jsl/jsl — that’s where I store my JSLint install, but you will need to modify that to the path on your system. The next parameter is the -process flag that JSLint uses to define the file to validate, and the final parameter is the $file flag that will be replaced with the file path to the file you’re currently working on.

The selector will help Sublime Text 2 automatically use this JSLint Build System when you’re working within a JavaScript file.

After modifying for your system, save the file to the default path Sublime Text 2 brings up in the save dialog and restart Sublime. Open up a .js file and hit CMD+B, or use Tools > Build. An inline prompt will appear giving you the JSLint results:

I’ll continue fiddling around with getting Closure Linter to work as I’d like to have the option, but if anyone’s got a tip regarding the error I was getting I’d love to hear some feedback.