This is a static site, meaning it’s pretty much just an informational set of pages.  Previously, I’d been using Radiant CMS for such things, and MediaWiki before that.  But both of those solutions (along with WordPress, Drupal, and other CMS-like things) mean having to deploy a whole web application, complete with a database onto your server.  That takes manpower, RAM, and is a pain whenever you migrate to a different server.

You never really need the complexity of a CMS except when the content changes.  So instead of a CMS, how about software that just regenerates all of your HTML files whenever you change something on the site?

Turns out there’s a really good piece of software called nanoc that does just that.  Using nanoc, I was able to build the web site I wanted without a hassle, and compile it to static HTML files in under a second.  (There are already pretty good tutorials, including one on nanoc’s web site, for using it.)  I do recommend using nanoc version 3.1 or greater, since it has some very major usability improvements.  3.1 is in beta right now, but should be released really soon.

But what about when you want to deploy the site to your web server?  Well, you could just copy the entire contents of the output folder over there.  That would work, but:

• It gets to be a pain when you do updates (copy it again!  now copy it again!).
• It can be hard to back out a change (oops, I accidentally deleted a page).

Well, in the Rails world, there are a couple of good tools to do this kind of thing: the venerable Capistrano and the young, awesomely-named Vlad the Deployer.  There are some big differences between these two tools, but essentially, what they both do is:

• Build a set of folders on your web server called releases and shared.
• Check out the latest version of your site from your version control repository, under a new timestamped folder in releases.
• Copy or link any server-specific stuff you’ve put in shared into the new copy of your site.
• Run some tests to make sure the new copy is good.
• Create a symlink (or change the existing one) called current, pointing to the new copy of the site.

So with this setup, all you need to do is point your web server’s root for this site at the current location, and your deployment tool will set up new versions of it with no downtime.  Plus, it’s easy to roll back to an older version if you need to – just change the symlink back to the older copy.

I chose Vlad the Deployer for this site, partly because I like the name, and partly because it’s smaller and less Rails-specific.

Here’s how I did it:

Step 1: Install Vlad

If you’ve already got nanoc installed, you’ve already got Ruby and RubyGems.  So installing vlad is easy:

sudo gem install vlad

If you’re not using Subversion as your version control system (I’m using git), then you’ll also need to do one of the following:

sudo gem install vlad-git
sudo gem install vlad-perforce
sudo gem install vlad-hg

Step 2: Edit your Rakefile to enable Vlad

nanoc already put a Rakefile at the top of your project folder.  To enable Vlad deployment, just add the following lines to the bottom of that file:

require 'hoe'

begin
  require "vlad"
  Vlad.load :scm => "git"
rescue LoadError
  # do nothing
end

(If you’re not using git, change “git” to the name of the version control system you’re using.  Vlad supports “subversion”, “hg”, and “perforce” as well.)

Step 3: Write a config/deploy.rb file

Create a folder called config in your project folder.  In there, you’ll need a file called “deploy.rb”.  A basic Vlad deployment script is as simple as this:

set :application, "my_web_site"
set :domain, "root@my-web-server.com"
set :deploy_to, "/srv/my_web_site"
set :repository, "git://my-git-server.com/myproject"

(If you want to run the deployment as a different user besides root, just change that on the “domain” line.)

In our case, we need to do a little bit extra.  First of all, we need to override Vlad’s default “update_symlinks” task so that it doesn’t try to link in some Rails-specific folders from shared.  We can do that like this:

namespace :vlad do
  # clear out everything currently in update_symlinks
  Rake.clear_tasks('vlad:update_symlinks')

  task :update_symlinks do
    # nothing
  end
end

The Rake.clear_tasks line deletes the “vlad:update_symlinks” task.  We then redefine it (so that other tasks that try to run it won’t fail), but our new version does nothing.

Finally, we need to do an extra step: once our site is checked out onto the server, we need to use nanoc to compile it.  To do that, add this inside the “namespace :vlad” block:

task :update do
  run "cd #{release_path} && mkdir -p output && nanoc3 compile"
end

This will add an extra step to the “vlad:update” task.  It goes into our timestamped folder under releases, makes an “output” folder, and runs “nanoc3 compile” (which will compile our nanoc site into the “output” folder).

OK!  The final version of the deploy.rb file looks like this:

set :application, "my_web_site"
set :domain, "root@example.com"
set :deploy_to, "/srv/my_web_site"
set :repository, "git://my-git-server.com/myproject"</pre>
<pre>namespace :vlad do
  # clear out everything currently in update_symlinks
  Rake.clear_tasks('vlad:update_symlinks')

  task :update do
    run "cd #{release_path} && mkdir -p output && nanoc3 compile"
  end

  task :update_symlinks do
    # nothing
  end
end

Step 4: Run Vlad!

OK, we’re all set to run.  In your project folder, run:

rake vlad:setup

Vlad will SSH into your web server and create all its folders in the location you told it to.  (It will probably ask you for your server password, possibly multiple times.  If you want to avoid this, you can set up SSH public key authentication.)

Now we’re ready to deploy the site:

rake vlad:update

If you go check in the web server, you’ll see that your site has been deployed to the folder you chose, under “current/output”.

Step 5: Set up your web server

You need to tell your web server where to find the files for your new site.  I’m using nginx as my web server, so here is the configuration for that:

server {
    server_name my-new-site.com www.my-new-site.com;
    listen 80;

    location / {
       root /srv/my_web_site/current/output;
    }
}

Or for Apache, do something like:

<VirtualHost *:80>
      ServerName my-new-site.com
      ServerAlias www.my-new-site.com
      DocumentRoot /srv/my_web_site/current/output
</VirtualHost>

Restart your server, and boom, you’re done.

Afterwards

Now to update your site, you just check your changes into version control, and run:

rake vlad:update

Vlad will automatically update your server and change over the symlink.  If you want to roll back to the previous version:

rake vlad:rollback

(Click for full size.)

Introducing Journey – online surveys the way they should be. With Journey, creating a survey is simple, flexible, and hassle-free.

After seven weeks of private beta testing, Journey is open for business. I’m proud to be offering straightforward online survey creation for marketers, researchers, and anyone else who just wants answers.

Journey’s launch also marks the start of a new business venture: Sugar Pond. Sugar Pond is a software company dedicated to communication, user empowerment, and community. You can read more about what Sugar Pond stands for in our manifesto.

I really want to thank everyone who’s provided feedback, encouragement, and sage advice these past few months. I’m truly proud to know all of you, and grateful that you’ve helped me get this little project to this point.

Now, I have one more favor to ask of you all: please let people know. The best way to get the word out is to link people to this posting, or to the Journey home page, on your blog, Twitter, Facebook, Livejournal, or whatever else you use. If you believe Journey can be a success, please help me out by spreading the word about it.

And if you believe Journey could be a success if only I changed that one little thing, I want your honest feedback. Please, always feel free to email me at nat@sugarpond.net with your ideas, suggestions, and complaints. I want to hear from you.

Sierra On-Line was certainly the biggest single reason I got into computers and technology.  They pioneered the graphic adventure game genre and published a long string of amazing games throughout the 80′s and 90′s.  Notably, Sierra had a very good (for the computer games industry) gender balance among their high-profile game designers.

This is probably due in no small part to Roberta Williams, who co-founded the company with her husband Ken.  Although Ken ran the business end of the company largely behind the scenes, Roberta was the public face of Sierra and the creative force behind its most successful games, including Mystery House, the King’s Quest series, Phantasmagoria, and the Laura Bow Mysteries.  Without Roberta Williams’ creative vision, the modern graphical adventure game probably would never have existed.

Another of Sierra’s designers was Christy Marx, who wrote the “Conquests” series: Conquests of Camelot, a game about King Arthur, and Conquests of the Longbow, about Robin Hood.  While Marx certainly wasn’t as prolific as a game designer as Williams, her takes on these often-told tales are extremely unique and creative.  The Marx versions don’t shy away from portraying the characters as human beings, and highlight the religious undertones and the historical context of these stories.  The games can be downloaded from her web site. In addition to her work for Sierra, Christy Marx also has designed computer and video games for a variety of other companies.

Lori Ann Cole and her husband Corey created the Quest for Glory series.  These games were unique in their combination of RPG and adventure game elements; while most games attempting to combine these two genres end up resembling an RPG with some puzzles and dialogue trees, QfG plays like an adventure game with stats and combat.  Another innovation in this series is the ability to bring a character from one game to the next, keeping their stats, items and abilities.  The Quest for Glory games combine just the right levels of humor and seriousness, and manage to be challenging without ever becoming tedious.

But probably my favorite game designer of all time is Jane Jensen, creator of the Gabriel Knight mysteries.  Jensen brought a new level of maturity in writing to the computer games field, and tackled difficult, human stories that dealt with themes of the occult and disturbing.  But don’t let that description scare you off: Jensen’s games are universally fast-moving, gripping, and fun.  The Gabriel Knight series, more than perhaps any other out there, makes the case for computer games as literature.  And, I can’t wait to see her upcoming game.

Without the games of Sierra On-Line, I might not be in the technology field today.  Although I didn’t end up working on games for a living, the works of these designers started me down my eventual career path.  Similarly, a lot of my work on LARP has been influenced by these games.  It’s fair to say that they are my technology heroines.

Who are your technology heroines?

IMO, the requirements for redesigning the registration numbers display on the schedule page of ProCon are:

• Compactness: the display needs to be readable on the existing schedule items, which are typically at least 120 pixels wide and 100 pixels tall.  Other information on the schedule item leaves about 50 pixels of vertical space for this display to use.
• Information at a glance: People need to be able to use these displays to make quick decisions during the registration rush.  Can users glance quickly at this display and see:
  • Which games still have room to register, and
  • Of those, which games are running out of room quickly, and
  • Of the full games, which ones have short waiting lists?
• Learnability: Oftentimes, people don’t have a lot of time to learn how to use these things.  It should be intuitively obvious, or as close to it as possible, what the display means.

But, of course, there’s plenty of room to debate these requirements.  So, people who have commented on the last few posts (and anyone else, of course): do these seem like reasonable requirements?  Is there anything you’d add?  Is there anything here you don’t think is necessary?

Thanks to everyone for the continued feedback, it’s been very helpful.

Changes this time around:

• Because Laurion couldn’t tell what the velvet rope was, I’ve altered its appearance – hopefully it’s a bit more realistic now, and there’s a hint of forced perspective in it so that you can tell that the people are waiting behind it.  It could probably still use some improvement, though, and I’m more than happy to hear suggestions on it.
• Because Matthew and Josh both commented that they like the numbers better, I’ve added the maximums back.  I’m hoping the combination of this info and the progress bars will give the whole picture.  Hopefully the new wording is clear enough, but if people have better ideas for how to phrase it, please let me know.
• I added little “sparks” to the progress bars to indicate where the game’s stated preferred numbers are, but I’m not real thrilled about how they made it look, and I’m thinking of removing those.  What do you guys think?

(Plaese pardon my poor cut-and-paste job on the room numbers…)

UPDATE: And, based on my coworker Keith’s suggestions, another one:

However, it’s hard to tell at a glance which games have openings, and how many.  I’d like to make this easier to use, as well as easier on the eyes.  I’ve come up with a mockup:

(Note: the numbers in the mockup are basically the same as the numbers in the above image.  Just to show how neutral slots would look, I added 9 neutral slots to “Only Mighty Guests” for the mockup, 2 of which are taken.)

I can’t help but feel like this is still lacking something visually, but I’m not sure how to improve it.  If anyone has a suggestion, I’d love to hear it.

I, for one, welcome our New Facebook overlords.

Seriously, what’s wrong with the new layout?  It cleans up a lot of the cruft that used to be in the sidebars, adds a lot of new options right up front, and makes the pages easier to read in general.  OK, so I’m not sure I agree with the clearly-Windows-inspired “taskbar” on the bottom, but on the whole, this seems like a very nice design refresh to me.

Could someone please explain to me what this hate is all about?

As much as I love my usual LARP-publishing tool, LarpML, it’s not so great for producing highly-stylized materials with heavy graphic design elements.  However, I hit almost by accident on what I think is a pretty elegant solution.

I’ve been using Inkscape, a free vector-drawing tool, to design the printable materials for the game.  I chose Inkscape because it’s cross-platform and I’m cheap – let’s be honest here.   But one nice bonus is that its native file format is SVG, an up-and-coming standard from the W3 Consortium for storing vector-based illustrations.  SVG is based on XML, which means it’s easily readable by computer software, even software that doesn’t know about SVG.

Well, hmm, that gives me an idea.

I wrote a small Python script that takes a configuration file like this:

[template]
filename: horde-character-template.svg

[values]
acceptedTrigger: 102
rejectedTrigger: 350
name: Testy McTesterpants
affiliation: The Testing Organization
gender: hermaphrodite
citizenId: 123456789-01
destination: August 8, 2008
statedGoal: Stop Nat Budin from making yet another uninteresting blog post about LARP technology.
notes: You actually want to stab Nat Budin in the heart and take his stuff.  Muahahahahahahahaha!

(Note: The “acceptedTrigger” and “rejectedTrigger” fields are for GM use. They’re game mechanics. Don’t worry about it.)

And produces output that looks like this:

What this is actually doing is simply reading in the file specified under [template], and then going through each item in [values] and substituting into the SVG file based on the XML node ID, which Inkscape lets you set.

I’m pretty happy with this.  Producing the template file itself is no harder than just making a drawing in Inkscape, and the configuration file syntax is dead simple.  Obviously it won’t work for longer character sheets that need multiple pages, but this is a horde game – if we need multiple pages, we’re doing something wrong.

Once we’ve released Time Travel Review Board, I’m planning to also release the source code of my script, but it’s really, really simple – any Python programmer could easily produce it themselves.