Code — HipChat Blog

Archive for the ‘Code’ Category

Capistrano notifications in HipChat

By Garret Heaton | 1 year ago | 9 Comments |

Our friends at Mojo Tech recently released a simple Ruby wrapper for the HipChat API which has special support for Capistrano, a popular deployment framework. After adding a few lines to your Capistrano scripts you’ll receive room messages during deployments, rollbacks, and migrations.

To install the gem, run:

$ gem install hipchat

Then add the following to your Capistrano script:

require 'hipchat/capistrano'

set :hipchat_token, "your token"
set :hipchat_room_name, "your room"
set :hipchat_announce, false # notify users?

Pretty easy! Check out the project page for more details.

By the way, we have integrations with other services such as GitHub, Heroku, and MailChimp as well as API libraries in other languages. Let us know if you’ve done something cool with our API that you’d like to share.

XCode tips for TextMate users

By Garret Heaton | 1 year ago | 0 Comments |

Switching from TextMate to XCode to work on the upcoming HipChat iPhone app has been a little painful. TextMate has some incredibly helpful features that I feel very unproductive without. Luckily some of them can be enabled or emulated. Here’s what we’ve found:

Go to File (Command-T)

TextMate's Go to File popup - so awesome!

The Go to File popup is probably TextMate’s most beloved feature. After using it for a while it seems amazing that its not part of every IDE out there. XCode’s “Open quickly” (Command-Shift-D) doesn’t cut it because it doesn’t do partial matching on the filename.

There are two options (both paid tools) for adding this functionality to XCode:

PeepOpen — $12, beta software, great potential but not actively maintained
Code Pilot — $30, more mature and full of other nice features

If you want to bind either tool to Command-T you’ll need to unbind XCode’s default key binding for the “Show Fonts” dialog first. To do that, open your XCode preferences and clear out option shown here.

Key Bindings

The “Delete line” (Control-K) and “Duplicate line” (Control-Shift-D) shortcuts can be added system wide by placing the following in ~/Library/KeyBindings/PBKeyBinding.dict:

{
    "^$K" = (
        "selectLine:",
        "cut:"
    );
    "^$D" = (
        "selectLine:",
        "copy:",
        "moveToEndOfLine:",
        "insertNewline:",
        "paste:"
    );
}

Full details and other options are available in this Stack Overflow post.

Themes

TextMate's Twilight theme in XCode

Using the same theme in all your IDEs can make it a lot easier to jump between them seamlessly. Here’s a tool you can use to convert your existing TextMate theme to work in XCode: XThemes.

There’s also a downloadable version of the Twilight theme for XCode here.

Tabs

Unfortunately there’s no way to get a tab-based display in XCode, so you’ll have to get good at switching between files using your Command-T replacement or via one of the suggestions here.

We hope these tips can make you a little more productive in XCode. If you’re looking for more make sure you check out this Stack Overflow thread. Oh and keep an eye out for the HipChat iPhone app.

GitHub is making me lazy but I like it

By Garret Heaton | 1 year ago | 1 Comment |

Open source projects depend on community cooperation. Successful projects have a healthy group of individuals and companies submitting code, writing documentation, and testing new features. Unfortunately it’s not always easy to contribute because different projects will use different bug trackers, version control systems, and approval processes. Package maintainers also have a hard time handling all the incoming patches in a timely manner which frustrates the contributors.

In 2005 Linus Torvalds created the Git version control system in order to solve problems he was having dealing with patches to the Linux kernel. A few years later GitHub came along with a nice web interface on top of Git, making it trivially easy to fork, patch, and contribute to projects hosted there. The standardized wiki and issue tracker features mean that many projects are setup in the same way. Once you learn how to contribute to one project on GitHub you know how to commit to all of them.

Unfortunately GitHub makes it so easy that I’ve found myself becoming lazy. It feels a lot harder to contribute to non-GitHub projects because it often requires signing up for their custom bug tracker, learning the patch process, and waiting longer before the patch is accepted. That extra friction is sometimes enough to prevent me from submitting a fix, and that’s not good for the project.

Ease of contribution is clearly an important factor for open source and other community-driven projects (just look at Wikipedia). As GitHub continues to grow, are more projects going to feel pressure to switch? I think they will, and I’m looking forward to it. Better software is good for everyone.

5 tips for running a company blog using WordPress

By Garret Heaton | 1 year ago | 7 Comments |

WordPress is an incredibly popular blogging platform for all types of blogs. It’s easy to setup and maintain, looks nice, and has thousands of well-maintained plugins to choose from (including ours). When we were setting up this blog choosing WordPress was a no-brainer. But we soon realized that running a company blog was a little different than a personal one. We wanted it to fit into our existing workflow, tools, and infrastructure and we weren’t sure if WordPress was going to get in the way. It turns out WordPress is very flexible and didn’t cause any trouble. But we still learned a lot and wanted to share some tips:

1. Store your WordPress install in a repository

You store your other code in source control, so why not your blog? Probably because the standard WordPress install instructions tells you to download a zip, install it on a standalone server, and manage everything through the web admin. This is fine for your personal site, but is not the best setup for a company blog. Storing it in a repository will make it easier to test changes locally (see #3), share the code between multiple people, have a record of changes, and manage deployments using a tool like Capistrano.

Luckily WordPress will happily live in a repository (a git repo on GitHub, in our case). Keep in mind that most of the config changes you make in the web admin will be stored in the database, not files you can check in to your repo. We maintain a WordPress database on our production systems as well as one in our dev environment. Any changes to plugin configuration, users, page content, etc need to be made in each environment independently.

Note: You’ll probably want to add wp-content/uploads/ to your .gitignore or svn:ignore since that content is environment-specific.

2. Run it on multiple servers

Hopefully your site is already running on multiple servers behind a load balancer so that it’s more redundant. Your blog should get the same treatment! It turns out there’s only one part of WordPress that doesn’t scale horizontally – file uploads. Since they get saved to the local disk, they’ll only appear on one of the servers in your cluster. If a visitor requests the image from one of the other servers they’ll see a broken image. Our solution was to use the Amazon S3 for WordPress plugin so that all our uploads are stored on S3 instead. The media gallery features of the web admin aren’t 100% compatible with this plugin (you’ll see some broken images), but we were OK with that. Another option would be to upload all your files to another part of your site or an external service like Flickr.

Note: The S3 plugin says it’s only compatible up to WordPress 2.7 but it’s working for us on 3.0.1. There’s also a new S3 plugin that looks promising, but we haven’t tested it.

3. Test upgrades in a dev environment first

We suggest installing your blog on a local server and using it to test all WordPress core, plugin, and theme upgrades before rolling them out to your live blog. Plugins and themes are easily upgraded using the links in the WordPress admin. Just verify that things are still working after the upgrade, check in the updated files, and release.

WordPress core upgrades are a little more complicated, or so we thought. We knew that these upgrades often modify the database during the upgrade process and we weren’t sure how we’d run those upgrades on our production systems. It turns out that WordPress is smart about not making breaking changes to the database so we’re able to follow the same process we do for plugins and themes. We just deploy newer versions of the code (like 3.0) to our production systems running an older version of the database (like 2.9) and everything works. The first person to go to the WordPress admin UI will be prompted with a ‘Database upgrade required’ page and WordPress will take care of updating things. Very cool!

4. Make the easy scalability improvements

If you’re not already running PHP on your production systems you may not have PHP’s APC module installed. Lucky you! Just install it, restart Apache, and your blog should be loading noticeably faster. If you’re interested in the reasons behind this, check out the Wikipedia article on PHP accelerators.

Second, install a cache plugin like wp-super-cache or batcache if you’re expecting serious bursts in traffic. You don’t want to have a popular post end up on the front page of Reddit generating unnecessary load on your servers.

5. Create your own theme

We got a little lazy making our HipChat theme originally and had just edited the ‘default’ theme. It turns out that WordPress will overwrite your changes as soon as you perform a core upgrade. Of course you’re using source control, so that’s not a big deal, right? Instead, just read the theme docs and learn how to make a theme for real. It’s almost as simple as copying another theme’s contents into a new directory and making your changes there.

Hopefully we’ve given you some ideas of how to make your company blog more reliable and easier to maintain. Please leave a comment if you have something to add or would like us elaborate.