Heroku: Depriving Your Free Dyno of Sleep

I’ve been using Heroku more and more, but not for anything really valuable to me. I mostly use it for hosting one-off projects that are low traffic. A lot of times, it’ll take 30 seconds or so for the site hosted on Heroku to respond, while the Heroku dyno is woken up. If your site goes without any traffic for a certain period of time, it will go to sleep.

Heroku does this to save server resources, which is a logical thing for them to do. Sometimes though, I don’t want to wait to see my site, even if I only have a free account.

I’ve seen a lot of tutorials on how to do this with Ruby, but no language-agnostic way of doing it. I also haven’t seen any way of doing this with PHP. There’s 2 methods you can use to keep your site from going to sleep.

1. UptimeRobot

This is the easiest and quickest way to keep your app awake, and is language-agnostic. UptimeRobot is a free service that monitors your sites. When you’re adding a new site to monitor in UptimeRobot, make sure to set the monitor type to “HTTP(s)”. UptimeRobot will check to make sure your site is up every 5 minutes, which will prevent your site from sleeping.

2. Heroku Scheduler

This method is a little more involved, but is probably the Heroku-preferred method.

This topic has been covered many times, but always seems to focus on Ruby apps. So here’s something that will work for everyone.

While you’re viewing your app resources on the Heroku dashboard, click the “Get Add-ons” link. Add the Heroku Scheduler add-on to your app, it’s free.

Go back to managing your app’s resources on the Heroku dashboard, then click “Heroku Scheduler Standard” to manage the Heroku Scheduler for your app. Add a new job, and set the frequency to Every 10 minutes. For your task, enter curl -I http://your-app-name.herokuapp.com. This will fetch HTTP response headers from your app, using Curl, every 10 minutes.

It should be noted that method 2 could potentially cause you to have a balance to pay at Heroku. That’s because Heroku Scheduler has Dyno Hour Usage.

So, there’s two options that everyone can use to keep your Heroku apps from sleeping, no matter what language your app is written in.


HTML5Press 2.5.3

If you’re new around here, you might think I release a new version of HTML5Press every day. I don’t. It hasn’t seen this much development since it’s initial release over 2 years ago.

2.5.3 is another small update that removes the “custom logo url” field from the HTML5Press theme options page. It also adds support for built-in WordPress header functionality. So, if you go to Appearance in your Dashboard, then to Header, you can set a custom header image.

Now, HTML5Press wasn’t designed with a header image in mind. Because of that, I decided to stick with the default image size specified in this article on ThemeShaper. The custom-header.php file in the root html5press directory is basically an exact copy of the custom-header.php that you’ll find in the ThemeShaper article.

I updated the theme submission ticket and attached a copy of HTML5Press 2.5.3. I also asked the reviewers to please not waste their time with reviewing 2.5.1 or 2.5.2, it’s exactly that, a waste of time. Fairly certain I won’t have to change many more things around before HTML5Press is finally accepted into the WordPress Theme Directory. But, who knows.

As usual, new versions of HTML5Press, including 2.5.3, can be downloaded from the HTML5Press page.


HTML5Press 2.5.2

I released HTML5Press 2.5, 2.5.1, and 2.5.2 early, early this morning. Why so many versions? Well, I’ve decided I need to get HTML5Press into the WordPress Theme Directory. Version 2.5.2 is all that you should care about though, unless you used the Twitter widget that was included with HTML5Press, in which case you might be upset with me (but it’s not all bad, keep reading).

I’ve had to remove the Twitter widget from HTML5Press as it had some simple caching functionality that required writing to and retrieving data from the filesystem. This isn’t appropriate behavior for WordPress themes, so I had to remove at least the caching piece before I could even submit HTML5Press for inclusion. Instead of chopping up the widget, I decided to entirely remove it. The Twitter widget that was included with HTML5Press can be downloaded as a standalone WordPress plugin, released by Matthias Siegel.

Also, WordPress won’t let you submit a theme for inclusion if it’s got any weird characters in the version, like a dash, which I use when building new versions of HTMl5Press (2.4-rc1, etc). So, I first had to bump up the version number to attempt uploading to the Theme Directory. Another version bump to fix an issue I found, and another version bump to remove the Twitter widget.

I haven’t updated the notification system that notifies you about new versions of HTML5Press. It still thinks the latest version is 2.5, which I’ll probably leave as-is until I get this theme accepted into the Theme Directory. Once it’s in the Theme Directory I’ll probably drop the custom update notification stuff all together.

I’m betting on it getting rejected this time around. Will probably need to implement the WordPress recommended way of uploading a custom logo, and remove the existing setup I’ve got to handle that.

HTML5Press will stick at the 2.5.x version for a while. I’m gonna keep using the 2.5.x versions to release new updates for re-submission to the Theme Directory. So, additional 2.5.x releases probably won’t include much in the way of new features. After it’s been accepted, I’ll start implementing new features again and will bump the version up to 2.6.


How-To: Monitor VPS Status From Heroku

I built and released this tool to monitor the status of your SolusVM client API-enabled VPS. It’s really easy to host it on Heroku, which is great since we don’t want to host the monitoring site on the VPS we want to monitor. You’ll need a Heroku account if you don’t already have one, the free account will do just fine.

Before we begin, you should probably install the Heroku Toolbelt. You’d also benefit from reading through some of the Heroku Dev Center articles. This one about deploying to Heroku with git is probably the most relevant for what we’re doing here.

You’ll need a terminal/command line for deploying to Heroku with git. A really great resource for new git users is Git Immersion, just click the green “Start Git Immersion” arrow to get started with git. Anyway, the 5 steps that follow assume you’ve created a Heroku account and have git installed and working.

  1. Fork tlongren/vps-status on GitHub and make a local clone.
  2. Install the Heroku Toolbelt and login to Heroku with the command “heroku login“. Enter you username and password to login with the Heroku Toolbelt.
  3. Create a new app on Heroku either through the web interface, or with the command “heroku create“. If you do it with the command line the app name will be shown to you, see here.
  4. Open a terminal and go into the folder that you cloned your fork into and run the command “heroku git:remote -a heroku-app-name“. That will add a remote named “heroku” to your local clone.
  5. Now, while still in your local clone folder, run “git push heroku master” to push your app to Heroku. If your app is named “heroku-app-name”, you can access your app at http://heroku-app-name.herokuapp.com.

That’s all there is to it. It might not seem simple at first glance, but it really is. To make changes, just edit the files in your local clone and commit those changes with git. Then run “git push heroku master” again to push the new code to Heroku.

Make sure you don’t send your changes back to GitHub, unless you’ve got private repositories. If you do a push to GitHub, your API key and hash will be accessible by the public, which isn’t something you want. Instead, you could either make a private repository at BitBucket or create a private repo using Dropbox like I do. The DropBox option is only reliable if you’re the only one editing the code, and if you’re only making changes from one machine at a time.

Let me know if you have any issues or think I’ve missed something.


Improved Permalink Redirection

After a hard evenings work, I have a much better redirection method to replace the one I described in this post. Previously, I was simply guessing which post a searcher was looking for and displayed a link to that post.

That was all fine and dandy, but I have pretty good search ranking for various keywords. I’d like to keep it that way. After digging around a bit I came across the best method to keep my search rankings in place and manage to redirect the searcher to the desired post. Enter the 301 Permanent Redirect.

I found a nice simple PHP function to do redirection on any number of levels. This function has the ability to send specific HTTP/1.1 status codes based on the type of redirection desired. Since my old permalinks will never be valid again, I chose the 301 Permanent Redirect. A note, the function listed at the URL linked above doesn’t work as-is, you need to modify it. The modified function is below, plus some extra code. All of that code is in my themes header.php file.
Continue reading “Improved Permalink Redirection”