Warren Ellis writes:

So, are people rolling their own private microblogging networks yet? And knocking together mobile pages and writing/hacking desktop apps to work with their private microblogging networks yet? It would seem to me to be the obvious outgrowth of the Twitter phenomenon: ambient communication for secret societies.

(Which you can take to mean “gated communities,” “dev teams” “people who like their privacy” or “bomb-throwing anarchists.”) …

I’d happily run two microblogging desktop apps: one for Twitter, and one for My Spooky Friends Net. And, after a while, I’d probably stop using the Twitter app, I’d imagine.

I’d be willing to work on My Spooky Friends Net.

Update: There are a ton of apps that work with Laconica / identi.ca already!

I need an HTCPCP daemon.

Or an intern.

There is coffee all over the world. Increasingly, in a world in which computing is ubiquitous, the computists want to make coffee. Coffee brewing is an art, but the distributed intelligence of the web-connected world transcends art…

I’m gonna go make some coffee. Blog post on really simple ruby daemonizing coming soon. Stay tuned.

There seems to be a bit of interest in the Ruby community lately in putting together handy libraries for creating Ruby daemons, so I thought I’d throw our own particular solution into the mix. Our solution intentionally avoids a lot of the common daemonizing tasks (like detaching from the terminal) so it might not be quite appropriate to call it daemonizing, but it fills our requirements nicely. (As an aside, check out Kenneth Kalmer’s new library daemon-kit for a nice actual-daemon implementation in Ruby.)

We originally tried coding things by hand using Daemons, and then modularizing our oft-repeated code to stay DRY, but we kept running into stability issues. Also, when you fork a Ruby daemon, particularly one that’s loaded up a large stack in memory, you end up at least briefly using twice as much memory. So, memory hogging and crashing needed to be avoided.

None of our daemons required advanced process handling, either. They were simple, single instance workers that had very particular tasks (like schedulers and message handlers for PingMe). We found ourselves asking, “do we really need to be forking child processes for this?”

The answer is no. Instead we are using a module we just pushed to Github that we call Looper. It allows us to take any bit of code or a class and run it as a kind of daemon. Or, more specifically, the class uses Looper to take advantage of its simple signal trapping, loop handling (including sleeping), and the class can rely on Looper to catch any unhandled exception, report it, and keep on keepin’ on.

The loopme method takes a block that it runs for you, handles sleeping between runs, and will catch any unhandled exceptions that bubble up. Thus, if you want to exit on a particular exception, you’ve got to rescue it in your code and set @run to false. It also sets up signal trapping so that signals TERM, INT and HUP will all cause the loop to end (I’d be open to changing this behavior or adding additional signal responses if anybody has an interest).

Here’s an example “daemon” that uses looper to kick it:

require 'looper'
require 'twitter'

class DoSomething
  include Looper

  def initialize(config)
    @run = true
    # do config stuff, etc...
    @sleep = config[:sleep].nil? ? 60 : config[:sleep]
  end # initialize

  def run
    loopme(@sleep) do
      begin
        # this is where the meat of your code goes...
        messages = twitter.direct_messages({:since => Time.now.strftime("%a, %d %b %Y %H:%M:%S %Z")})
      rescue Twitter::EpicFailure => e
        puts "bailing out, dude!" 
        # set run to false to put the kabosh on the next run
        @run = false
      end
    end
  end
end

# and here's how we kick it off:
DoSomething.new( { :sleep => 10 } ).run

Pretty simple, right? No coding up the signals, the sleeping, the global exception handler, etc. You can take a look at looper.rb to see exactly what it does for you. From here, starting and stopping our script is really easy, and can be re-used for each of our daemons. It boils down to starting it up with nohup (and script/runner because we like having our rails stack), and then killing it later with the PID:

$ nohup script/runner -e RAILS_ENV /path/to/DoSomething.rb

There’s no need to use Rails’ script/runner, you could just call ruby itself and save yourself a lot of memory ;-)

The following is an init script that we use to start and stop any of our Looper daemons:

#!/bin/bash
#
# chkconfig: 345 70 30 
# description: control script for daemons 
#

usage(){
  echo $"Usage: $0 {start|stop|restart} {daemon1|godzilla|voltron}"
}

# daemon name is required as second param
if [ "$2" = "" ]
  then 
    usage
    exit 5
fi

# RAILS_ENV?
if [ "$RAILS_ENV" = "" ]; then
  RAILS_ENV='development'
fi

# RAILS_DIR?
if [ "$RAILS_ENV" = "production" ]; then
  RAILS_DIR='/www/app/current'
else # assume development
  RAILS_DIR='/www/dev.app/current'
fi

PROGRAM="${RAILS_DIR}/daemons/${2}/looper.rb"
RUNNER="${RAILS_DIR}/script/runner"

LOG="/var/log/app/daemon_${RAILS_ENV}.log"

# if the daemon is missing, well, the daemon is missing!
test -f $PROGRAM || exit 5

# See how we were called
case "$1" in
  start)
  nohup $RUNNER -e $RAILS_ENV $PROGRAM >> $LOG 2>&1 &
    ;;
  stop)
    PID=`ps auxw | grep ${PROGRAM} | grep -v grep | awk '{ print $2 }'`
    echo "Stopping PID: ${PID}"
    kill $PID
    sleep 2
    ;;
  restart)
    $0 stop
    $0 start
    ;;
  *)
    usage
    exit 1
  ;;
esac

exit 0

Today’s dose of win:

“Alright!! It’s working against the production servers – monitoring 6 web apps across three servers. My boss is very happy. That means I am even happier. I have been working with Nagios now for roughly 4 months. The user login test was the final piece of this project. Thanks again for the help.”

How cool is that? We have a plugin for Nagios called ckFormLogin that monitors login processes for popular asset management systems (Oracle CoreID Access Manager, CA eTrust Siteminder, Sun Access Manager, &c.), and when people have a little trouble with it, we’re pretty happy to help them out. But rarely do you get cool feedback like that.

Nagios itself is a really useful and highly configurable piece of monitoring software. The interface is a bit Soviet, sure, but it works great, and it’s open source. So is the ckFormLogin plugin.

This post is probably not what you’d expect. But our time-tracker service Tempo has some great charting capabilities. Behold, the effects of a recent virus (of which I will spare you the horrific details) on my productivity:

Above is the Heads-Up-Display, at the top of the main screen. It reads pretty easily – my productivity was sent to bed!

Check out the utilization chart, which is a bit more instructive as to what happened, and when. That’s accessible by clicking the productivity percentage number box in the HUD, or just pulling it up from the Charts tab:

Brutal.

Utilization is a measurement concept in Tempo that is supposed to give you a ballpark idea how much of your time is accounted for, compared to how much time is generally available in a work-day. So, for every day in a report, the par for the day is considered to be 7 to 9 hours (which is a pretty common length for a workday), and that’s the horizontal, light-blue bar going across the graph between 7 and 9 on the Y-axis. The bars then show us a visual comparison of our utilization for the time periods. If I were to expand the date range enough, these would be grouped by week, then by month. Here’s what my utilization looks like since Nov 1st, 2008, until now:

So 2008 was a pretty productive year for us here at Zetetic. I can’t really go through it all right here and right now, but we’re quite excited about the new year, improvements we’ll be making to our existing products, and the new products and services we’re currently building.

And with that I’m going back to bed. Offers to send me comfort whisky, cheese burgers and nurses will not be turned away outright.