Redhat init script for managing a NodeJS app via forever

March 13, 2012

I run CentOS for my production servers, and generally like to manage my services via proper init scripts. Over the years I’ve run into situations where I couldn’t locate a decent init script for a service I want to deploy, and end up rolling my own. I’m no shell scripting wizard, but they work well for me; it seems like something worth sharing so others don’t have to reinvent the wheel.

Today, I went hunting for an init script that I could use to manage a NodeJS application, and while I found a Debian-based one, no Redhat-style one was forthcoming. I tweaked the Debian one I found to work on a Redhat-style system. The script below should work fine for any Redhat/Redhat clone server. You’ll need to take care of a few things after you get the script:

  • Install the forever package so it’s in your PATH, which is easily accomplished via npm install -g forever if you have NPM installed.
  • Edit the variables in the APPLICATION section to suit your needs.
  • Put the script into /etc/init.d and name it something meaningful, I go with node-[appname].
  • Make sure the it’s executable.
  • If you want to have it automagically start/stop on startup/shutdown, activate it with chkconfig, like chkconfig --add [scriptname].
  • Manage it manually via the service app, eg. service [scriptname] start.

This script should be reusable to run more than one node app, provided that:

  • There’s one uniquely named script per node app.
  • The node apps are started on different ports.

Overriding jQuery UI autocomplete methods Specifically select() and focus()

March 8, 2012

The jQuery UI documentation for autocomplete doesn’t do the greatest job of clarifying how to override the select() and focus() methods. There is mention of ‘Cancelling this event’, but they only snuck in how to do the cancelling in the search() method. This led to considerable confusion on my part, where code like this:

    $(document).ready(function() {  
      $('#foo').autocomplete({ 
        source: '/bar',
        select: function(event, ui) {   
          $('#selector').val(ui.item.label);    
          $('#target').val(ui.item.value);
        },
      });
    });
    

Would lead to the maddening result of those changes being applied, then overwritten by the default behavior of the method.

The simple solution is to add a return false; to the end of your custom implementation:

    $(document).ready(function() {  
      $('#foo').autocomplete({ 
        source: '/bar',
        select: function(event, ui) {   
          $('#selector').val(ui.item.label);    
          $('#target').val(ui.item.value);
          return false;
        },
      });
    });
    

This prevents the default code for the method from running.

Rebuilding a Jekyll site via git

March 3, 2012

Update 2015-01-19: I’ve updated this post to reflect the current version of Jekyll.

This site is built using Jekyll with Jekyll Bootstrap as a starting point. One of the nice things about hosting this kind of site on GitHub is that when you push updates, they trigger a rebuild of the Jekyll site, making for super easy deployment. For various reasons I decided that I didn’t want to host my site on Github, so I needed a way to have the same convenience on my own server.

The Jekyll Wiki and some other folks offer an approach that makes a copy of the checkout on the target server, then uses that for the rebuild, all triggered via the git post-receive hook. I like the basic idea, but it seemed cleaner and faster to me to just have a non-bare repository on the server and trigger the rebuild in place, which the script below accomplishes. I also like that I can rebuild the site very easily on the server if need be, by simply running jekyll build from the root of the working tree.

There are a couple of gotchas to this strategy, check out the CAVEATS comments in the script itself for details. And now, I’m going to make use of this sucker by pushing my post. :)

Kickoff party Interwebs style

March 2, 2012

Welcome to the online blog for Chad Phillips (aka hunmonk). The inspiration for this blog came from a community hangout session and a spare Scrabble dictionary. Paging through, picking out random interesting words, the term xylil leapt right off the page, and I knew that some day (domain name gods willing), I’d have a blog site with this name. :)

I doubt I’ll be a frequent blogger; I’ll mostly aim for getting stuff up relating to technical work I’m doing that might not be easy to find elsewhere. I’m one of those people who seems to run into edge cases and exceptions, which result in headbanging, which will hopefully ultimately result in a post that means you won’t have to suffer as I did. ;)

Older posts