Recent posts

Sampler API, a metrics framework for Drupal

March 22, 2012

About a year ago, I wrote a Drupal module called Sampler API, which is a framework for data collection and storage with built-in Views integration (credit to mikey_p for the Views code).

From the project page: “The Sampler API allows modules to easily collect and store calculated pieces of data. It’s designed primarily to assist in collection, storage, and display of metrics.”

The module hasn’t seemed to get much attention, and I’m guessing at least part of the reason was that it never has had an official release. Well today that changes. ;)

A 6.x-1.0 release is now available, and the 7.x development release is also working pretty well – an official release for that branch should follow soon.

Environment management script for FreeSWITCH

March 18, 2012

As a FreeSWITCH consultant, one of the things I do regularly is set up new environments for working with clients. Yesterday I decided it would be nice to automate the process of basic management for these installations, and the freeswitch-env script was born.

Here’s the basics:

Usage: freeswitch-env <install|uninstall|list> <env-name>
  env-name: The name of the envelope to create. Will be appended to
  'freeswitch-' to create the final envelope name

Install goes through the standard configure/make/install steps, plus handles installing the default sounds, music on hold, and config files. If configured, it will also set up an init script for starting/stopping the install (I’ve only tested this on Redhat, but others would probably work with minor tweaking).

The script is fairly configurable, allowing you to specify a custom source code location, base install path for environments, user to run FreeSWITCH as, etc.

It’s released as part of my new freeswitch-utils package, where I’ll be adding other handy scripts, etc. that I find useful when working with FreeSWITCH.

Updates/improvements to db-query-assistant

March 16, 2012

I woke up this morning with a desire to better abstract the driver code for db-query-assistant mentioned in this post, and after a few hours of tinkering, profit!

So today is the release of version 0.2.0 of this helper library. All database driver code is now pluggable, and I’ve started with drivers for db-mysql and db-drizzle of the nodejsdb project.

Other node-based database connection modules would probably be pretty easy to provide drivers for, so feel free to submit pull requests to add new ones!

Helper library for node database drivers Connection pooling, multi/series querying

March 14, 2012

Summary

Update

I’ve renamed the respository for this software package, it’s now available here. Links in this post have been updated accordingly.

Today I’m releasing a nifty helper library I wrote to ease the pain of aync database queries in node.js. It provides the following features on top of node-db drivers:

Configurable connection pooling.
Issue multiple simultaneous queries, and get all results back in a callback when the last query completes.
Issue queries in series, getting the results for each previous query back before executing the next one.

At this point it only supports the db-mysql driver, as I haven’t abstracted the code to make the other drivers pluggable. Would be a simple thing to do though, feel free to submit a pull request!

It’s also possible that this could be abstracted further to provide functionality across different node-based database drivers.

This library was pretty easy to code up thanks to the awesome async and generic-pool modules.

Installation

Code

Available on github. No npm package yet, when the API is fully hardened it will be packaged.

Dependencies

Usage

See the README.

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.

#!/bin/sh ## ## Redhat / Linux / LSB ## # chkconfig: 345 85 15 # description: Startup script for Express / Node.js application with the \ ## forever module. ## ## A modification of https://gist.github.com/1339289 ## ## This is free software; you may redistribute it and/or modify ## it under the terms of the GNU General Public License as ## published by the Free Software Foundation; either version 2, ## or (at your option) any later version. ## ## This is distributed in the hope that it will be useful, but ## WITHOUT ANY WARRANTY; without even the implied warranty of ## MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the ## GNU General Public License for more details. ## # Source function library. . /etc/init.d/functions ################################################################################ ################################################################################ ## ## # APPLICATION section # ## Edit the variables below for your installation ## ################################################################################ ################################################################################ DESC="admin" NAME="app.js" DIR="/var/www" APP=${DIR}/${DESC}/${NAME} LOCKFILE=`basename $0 .sh` export NODE_ENV=${NODE_ENV:="production"} ################################################################################ ################################################################################ ## ## # PATHs section # ## ## ################################################################################ ################################################################################ export PATH=$HOME/local/bin:${PATH:=} export MANPATH=$HOME/local/man:${MANPATH:=} export LD_LIBRARY_PATH=$HOME/local/lib:${LD_LIBRARY_PATH:=} ################################################################################ ################################################################################ ## ## # FOREVER section # ## ## ################################################################################ ################################################################################ running() { forever list 2>/dev/null | grep ${APP} 2>&1 >/dev/null return $? } start_server() { forever start ${APP} 2>&1 >/dev/null return $? } stop_server() { forever stop ${APP} 2>&1 >/dev/null return $? } ################################################################################ ################################################################################ ## ## # GENERIC section # ## ## ################################################################################ ################################################################################ DIETIME=10 # Time to wait for the server to die, in seconds # If this value is set too low you might not # let some servers to die gracefully and # 'restart' will not work STARTTIME=2 # Time to wait for the server to start, in seconds # If this value is set each time the server is # started (on start or restart) the script will # stall to try to determine if it is running # If it is not set and the server takes time # to setup a pid file the log message might # be a false positive (says it did not start # when it actually did) # Console logging. log() { local STRING mode STRING=$1 arg2=$2 mode="${arg2:=success}" echo -n "$STRING " if [ "${RHGB_STARTED:-}" != "" -a -w /etc/rhgb/temp/rhgb-console ]; then echo -n "$STRING " > /etc/rhgb/temp/rhgb-console fi if [ "$mode" = "success" ]; then success $"$STRING" else failure $"$STRING" fi echo if [ "${RHGB_STARTED:-}" != "" -a -w /etc/rhgb/temp/rhgb-console ]; then if [ "$mode" = "success" ]; then echo_success > /etc/rhgb/temp/rhgb-console else echo_failure > /etc/rhgb/temp/rhgb-console [ -x /usr/bin/rhgb-client ] && /usr/bin/rhgb-client --details=yes fi echo > /etc/rhgb/temp/rhgb-console fi } # Starts the server. do_start() { # Check if it's running first if running ; then log "$DESC $NAME already running" exit 0 fi action "Starting $DESC $NAME" start_server RETVAL=$? if [ $RETVAL -eq 0 ]; then # NOTE: Some servers might die some time after they start, # this code will detect this issue if STARTTIME is set # to a reasonable value [ -n "$STARTTIME" ] && sleep $STARTTIME # Wait some time if running ; then # It's ok, the server started and is running log "$DESC $NAME started" touch /var/lock/subsys/$LOCKFILE RETVAL=0 else # It is not running after we did start log "$DESC $NAME died on startup" "failure" RETVAL=1 fi fi return $RETVAL } # Stops the server. do_stop() { if running ; then # Only stop the server if we see it running action "Stopping $DESC $NAME" stop_server RETVAL=$? [ $RETVAL -eq 0 ] && rm -f /var/lock/subsys/$LOCKFILE else # If it's not running don't do anything log "$DESC $NAME not running" RETVAL=0 fi return $RETVAL } case "$1" in start) do_start RETVAL=$? ;; stop) do_stop RETVAL=$? ;; restart) do_stop RETVAL=$? if [ $RETVAL -eq 0 ]; then # Wait some sensible amount, some server need this [ -n "$DIETIME" ] && sleep $DIETIME do_start RETVAL=$? fi ;; status) if running ; then log "$DESC $NAME running" else log "$DESC $NAME not running" fi RETVAL=0 ;; *) echo "Usage: ${0} {start|stop|status|restart}" RETVAL=1 ;; esac exit $RETVAL

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. :)

#!/bin/bash # # Utility script which can be used to trigger rebuild of a jekyll site that is # managed via a git repository. Most often, you would call this script in the # post-receive hook of a full (non-bare) git repository, such that the rebuild # happens after a push. # # Run with no arguments for usage. # # CAVEATS: # # 1. The git, jekyll, and pygmentize executables must be in the PATH. # 2. receive.denycurrentbranch should be set to 'warn' or 'ignore' in the # target repository. From within the target repository: # git config receive.denycurrentbranch warn # 3. If you're foolish enough leave uncommitted changes lying around in the # target repository, this script will wipe them out! # # Source the .bashrc file if present, this allows for a non-standard location # of executables, such as via RVM/pyenv. if [ -f ~/.bashrc ]; then . ~/.bashrc fi GIT=`which git` JEKYLL=`which jekyll` TIMESTAMP=`date` REPO_DIR=$1 LOG_FILE=$2 function usage() { echo " Usage: jekyll-git-push.sh <repo_dir> [log_file] repo_dir: Full path to the working tree of the jekyll site repository. log_file: Optional file to log results to. Ex. jekyll-git-push.sh /home/me/repo /tmp/jekyll.log " } function log() { message=$1 log_message="$TIMESTAMP - $REPO_DIR - $message" echo "$log_message" if [ "$LOG_FILE" != "" ]; then echo "$log_message" >> $LOG_FILE fi } if [ "$REPO_DIR" = "" ]; then log "ERROR: no repository configured" usage exit 1 fi $GIT --work-tree=${REPO_DIR} --git-dir=${REPO_DIR}/.git reset --hard if [ $? = 0 ]; then $JEKYLL build -s $REPO_DIR -d ${REPO_DIR}/_site if [ $? = 0 ]; then log "site rebuild successful" exit 0 else log "ERROR: could not rebuild site" usage fi else log "ERROR: could not reset the git working tree" usage fi exit 1

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. ;)