BohConf 2010

After an exhilarating week of hosting the Rails community in Baltimore for RailsConf, I thought it’d be helpful to share the lessons that we learned organizing BohConf.

Community Code Drives Rock!

We had a strong showing of open source authors including Wayne Seguin, Gregory Brown, Aslak Hellesøy, Chris Eppstein, Nick Gauthier and various members of Thoughtbot crew. Wayne (rvm) and Greg (prawn) in particular raved about the contributions they were able to make to their projects. Hey, I even got a new release of Timecop out thanks to a patch from Larry Marburger. Other well known OSS authors that dropped by included Rick Olson, Patrick Peak, and Josh Nichols. If you were there and we missed you, please drop us a line in the comments!

Employ Signage Everywhere

The Vim session at Monday's BarCamp (photo courtesy of Nick Gauthier)

One problem that we had was that people entering BohConf did not have a sense of what was actually taking place. Despite having a schedule posted online, it was often not clear what was underway. During the community code drives, we should have had signs next to each table pointing out which OSS authors were there to work on which projects. During the BarCamps, we could have similarly posted signs that indicated which discussions were happening at which tables.

Publish Live Updates to the Website

The thing about being internet (nerd) famous is that that doesn’t necessarily mean that anyone knows what you look like. It would have been cool to post photos on the website of the OSS authors who were currently working the Community Code Drive. Similarly we could have posted the current BarCamp sessions on the website. A countdown to the start and end of the programming contest would have been cool too.

Programming Contests Rock!

Give a bunch of nerds a dataset, a deadline, and no rules, and you get some pretty awesome efforts. Our client SpotCrime made available a dataset of crimes in Maryland in the past couple of months. Tim Johnson submitted a processing.rb time lapse visualization, Aaron Scruggs submitted a super cool and clever gource visualization, and Greg Brown and several members of his crew (Jia, Jordan and Chenoa) showed a lot of creativity with their submission of Spot the Baddy, a simple but fun interactive game where you can catch the bad guy!

Advertise the Programming Contest Better

While we were very happy with the submissions that we received for the programming contest, we felt that not nearly enough people were aware that it was taking place. Which also means that nobody knew we were giving out a $100 visa card to the best submission.

A Schedule is Important

When running an unconf for three days, you cannot simply throw out all semblance of organization and expect a success. With various people responsible for different aspects of BohConf, it was very helpful to be able to refer to the schedule when explaining what was happening at BohConf. Furthermore, it allowed us to communicate specifics well ahead of time via Twitter to those who wished to participate.

Code Retreats Rock!

Matt Scilipoti running the Code Retreat (photo courtesy of James Duncan Davidson)

…but perhaps it wasn’t the best choice to displace another BarCamp session. After a wildly successful BarCamp Monday afternoon, many folks returned Tuesday looking for another. Though the code retreat was clearly appreciated by the dozen or so folks that participated, there seemed to be a lot more interest in the BarCamp.

Momentum Slowed

Considering that Monday was tutorial day, it was unrealistic to expect us to maintain the same level of participation Tuesday and Wednesday. Not only was there a big dropoff from Monday to Tuesday, but there was another one from Tuesday to Wednesday. BarCamp Wednesday afternoon was less successful than Monday’s, the discussion groups dissipated before we even got to the last session. It’s also worth noting that those of us running BohConf were running on fumes by that point which likely contributed to the loss of momentum.

We Didn’t Market SmartLogic Well Enough

While SmartLogic is instrumental to the B’more on Rails community (as a sponsor and organizer), BohConf was actually undertaken entirely by our team at SmartLogic. We felt that we missed a big opportunity to establish our company and individuals as more visible members of the Rails community. Our team members should have all had shirts, and we should have given away stickers and buttons to all attending BohConf.

Encourage Conversation

A group discussion at BohConf (photo courtesy of Nick Gauthier)

A large format session at an event like RailsConf scales pretty well. As far as you can project a speakers image (in time and space), that’s how many people you can reach. Open space events like BohConf scale less well because the effects are personal. The benefit of attending this kind of event is a lot more subjective, because each person’s experience is different. This means it’s vital that you give plenty of opportunities for people to start conversations. The BarCamp format isn’t about presentation topics as ending points, they’re conversation starters. The folks who got the most out of the event seemed to be the ones most open to meeting new people and sharing their story.

A fantastic way to get people involved is to simply encourage them to ask, “What are you working on?” Follow up with, “tell me about that” and most geeks, passionate about their craft and otherwise quiet, will talk for an hour.

Don’t Be Shy about Asking for Help Promoting

Though we had about 100 followers prior to the start of BohConf, we failed to reach a large segment of the RailsConf attendees before the conference started. Attendee after attendee that I spoke to were hearing about BohConf for the very first time. We should have reached out to Chad, DHH and others to talk about BohConf in the weeks leading up to it. Even a few tweets would’ve given the event a nice bump.

Get a Bigger Room Next Time

Despite the waning momentum as the days went on, we were still overpacked in the conference room that we had available. Luckily on Monday we were able to hijack the adjacent media room for our use. Otherwise we would have had to turn away to half of the 80+ folks hanging out during the peak.

Finally

We had an absolute blast organizing BohConf for the community. Practically all feedback we received was overwhelmingly positive. And there are rumors that we’ll be asked to put it on again next year. Whether or not we’re the ones to undertake it, we hope that these notes will aid those embarking on similar endeavors.

An extra special thanks to Adam Bachman, Nick Gauthier, Ryan DeStefano and Matt Scilipoti for their efforts in helping to run BohConf.

If you have any comments or critiques of BohConf, please leave a comment below. Thanks to all those who attended!


$> ls -l ~/projects/timecop/lib
drwxr-xr-x 5 john staff 170 Jan 14 20:31 timecop
-rw-r--r-- 1 john staff 82 Jan 14 20:31 timecop.rb


The reason for this is related to how RubyGems hijacks Ruby’s require method. When a gem is activated its lib/ folder is added to the load path. This means that anything inside that directory is now accessible via the require method. In order to avoid file naming collisions across gems, you must name these exactly the same as your gem. (see slides for I Don’t Trust Your Code for a more complete discussions of this)

However, this is slightly different with rack gems. The convention for naming rack middleware is by using a dash, e.g. rack-rewrite. The convention for requiring rack middleware though is to replace that dash with a slash, e.g. require 'rack/rewrite'.

The convention I’ve adopted for structuring rack middleware within a gem is to include a file by the same name as the gem and a rack directory in lib/, and then to include the second part of the middleware name as a subdirectory under that.


~/projects/rack-rewrite (master) $> ls -l lib/
total 8
drwxr-xr-x 4 john staff 136 Apr 17 18:02 rack
-rw-r--r--@ 1 john staff 22 Apr 17 18:02 rack-rewrite.rb

~/projects/rack-rewrite (master) $> ls -l lib/rack
total 8
drwxr-xr-x 3 john staff 102 May 13 11:09 rewrite
-rw-r--r--@ 1 john staff 827 Apr 17 18:02 rewrite.rb


This allows my users to use either require 'rack-rewrite' or require 'rack/rewrite'.

Rack::Rewrite is a web-server agnostic rack middleware for defining and applying rewrite rules. In many cases you can get away with Rack::Rewrite instead of writing Apache mod_rewrite rules.

Documentation is hosted at RubyForge. The source code is hosted at GitHub.

Updates include:

API

• Fix rack 1.1.0 / rails3 compatibility by eliminating reliance on REQUEST_URI env param. Paths are now constructed with PATH_INFO and QUERY_STRING
• Follow rack directory/require convention: require ‘rack/rewrite’ instead of ‘rack-rewrite’
• Include an HTML anchor tag linked to where the URL being redirected to in the body of 301′s and 302′s

Rack::Rewrite is a web-server agnostic rack middleware for defining and applying rewrite rules. In many cases you can get away with Rack::Rewrite instead of writing Apache mod_rewrite rules.

Documentation is hosted at RubyForge. The source code is hosted at GitHub.

Updates include:

API

• Implement $& substitution pattern (thanks to Ben Brinckerhoff)

Maintenance

• Ignore empty captures instead of failing during subsitution (thanks to Ben Brinckerhoff)
• Play nice with Rack::Test requests which only set PATH_INFO and not REQUEST_URI (thanks to @docunext)
• Use QUERY_STRING instead of QUERYSTRING as per Rack spec. Closes Issue #1.

Maryland Tech Crawl

Why create another technology event?

It’s a good question– I think a lot of folks feel like there’s been a deluge of events in the past year — Innovate, Ignite, Refresh, TEDx, TechNite, Tech Cocktail, BootstrapMD, Outlet, Barcamp, not to mention the myriad of local user groups — so why create the Tech Crawl?

While I love all of these events, I feel that none of them provide a venue for our entrepreneurs to actually showcase their technologies. The Tech Crawl is primarily a “show and tell” event. It’s an opportunity for our community to get acquainted with the superb work that our technology entrepreneurs are pouring their blood and sweat into.

Why did SmartLogic want to get involved?

As an active member in both the business and technology communities in the mid-Atlantic region, I felt that I was still in the dark about the work a lot of companies were doing. I’ve noticed that the most interesting innovations are achieved by folks who are not out actively networking. Just consider the nature of a technology startup– you’re either building or selling, but not necessarily marketing or showcasing on a large scale. I thought there was room for an event that brought the community to the entrepreneurs.

Who am I excited to see?

• Juxtopia: these guys are doing some really cool stuff in the realm of wearable tech. I can’t wait to see the actual equipment!
• Direct Dimensions: they do some impressive work in 3D scanning and modeling. They were recently recognized in the BBJ for work they’re doing digitizing museum collections.
• Videntity: this team has been developing identity verification software that allows doctors to more easily exchange sensitive information securely.

Obviously I’m also excited to see the media (BBJ, Sun, BmoreMedia, and Mario Armstrong, tech contributor for NPR, CNN, and Sirius XM Radio) all come out to cover the Tech Crawl.

If you haven’t already signed up to attend, please register online. If you’d like to present your product please send an email to fgursel@etcbaltimore.com.

Timecop is a RubyGem providing “time travel” and “time freezing” capabilities, making it dead simple to test time-dependent code. It provides a unified method to mock Time.now, Date.today, and DateTime.now in a single call.

Documentation is hosted at RubyForge. The source code is hosted at GitHub.

Updates include:

Maintenance

• Fix various timezone-related issues. Notably, when traveling to a DateTime
  instance specified in a non-local timezone, convert provided DateTime
  instance to a local instance and return that from DateTime.now.
  Code contributed by Michaël Witrant [piglop]
• Fix bug that would not allow Timecop to be used when Ruby’s ‘date’
  library had not been previously loaded.
  Code contributed by Tuomas Kareinen [tuomas]
• Fix bug when traveling to a DateTime across a DST boundary that
  resulted in DateTime’s being off by an hour.
• Migrate argument parsing into Timecop::TimeStackItem to reduce the
  responsibility of the Timecop class.

Google Analytics Navigation

Enter Rack::Rewrite. Rack::Rewrite is a Rack middleware for defining and applying rewrite rules. Though it’s not a full replacement for Apache’s mod_rewrite, a great deal of rules I’ve previously written in Apache config files can be replaced by Rack::Rewrite. Run gem install rack-rewrite to install the gem.

In order to determine which URL’s were most important to issue 301′s for, we turned to Google Analytics. By reviewing the most popular landing pages of the past two months from our site, we were able to methodically write our redirect rules.

Google Analytics | Top Landing Pages

Here is a subset of the associated Rack::Rewrite rules.

  config.middleware.insert_before(Rack::Lock, Rack::Rewrite) do        
    # original wiki smartlogicsolutions.com website
    r301 '/wiki/Main_Page', '/'
    r301 '/wiki/John_Trupiano', '/john'
    r301 %r{^/wiki/(Charity|Charities|Local_Connection)$}, '/gratis-work-and-charities'
    r301 '/wiki/Category:Portfolio', '/portfolio'
    r301 '/wiki/ExxonMobil_-_Brand_Asset_Center', '/portfolio/exxonmobil-brand-asset-center'
    r301 '/wiki/In_the_News', '/in-the-news'
    r301 '/wiki/Getting_to_our_Office', '/driving-directions'
    r301 '/wiki/Category:Employees', '/our-team'
    r301 '/wiki/SimNet_for_Office_2007', '/portfolio/simnet-for-office-2007-and-vista'
    r301 '/wiki/VNC_Collaboration_Application', '/portfolio/shared-desktop'
    r301 '/wiki/Contact_Information', '/contact-us'
  end

This scheme is great for landing pages, but what if we had querystring information that we wanted to keep around? This is common for tracking codes — many marketing platforms generate URL’s that embed data in the querystring for recording and tracking purposes. We can leverage the following trick to maintain the querystring across a rewrite.

  r301 %r{^/wiki/Main_Page(\?.*)?$}, '/$1'

Note the following:

• We are conditionally matching a querystring so that the rule continues to match in the absence of a querystring.
• We are leveraging substitution patterns to reconstitute the querystring in the rewritten URL.

Many more great use cases for Rack::Rewrite are covered in the project’s README.

I typically leverage rewrite rules to take my sites offline for maintenance. Most capistrano users will be familiar with the following Apache rewrite ruleset.

  RewriteCond %{REQUEST_URI} !\.(css|jpg|png)$
  RewriteCond %{DOCUMENT_ROOT}/system/maintenance.html -f
  RewriteCond %{SCRIPT_FILENAME} !maintenance.html
  RewriteRule ^.*$ /system/maintenance.html [L]

This ruleset matches requests for non-asset URL’s and renders a maintenance page if it exists on the filesystem. When capistrano users run cap deploy:web:disable REASON="site upgrade" UNTIL="2PM" a maintenance page is placed in public/system and this ruleset begins to kick in. Running cap deploy:web:enable will remove this page and the ruleset ceases to match.

We can replace this ruleset with the following Rack::Rewrite rule:

  # Ruby 1.8.x
  maintenance_file = File.join(RAILS_ROOT, 'public', 'system', 'maintenance.html')
  send_file /.*/, maintenance_file, :if => Proc.new { |rack_env|
    File.exists?(maintenance_file) && rack_env['REQUEST_URI'] !~ /\.(css|jpg|png)/
  }

This rewrite rule uses the send_file method to return the maintenance page, uses a rule guard (the :if proc) to check for the existence of the file, and accesses the rack environment directly (rack_env arg to the Proc) to check the request URI. Due to the shortcomings of the Ruby 1.8′s regular expression library (no negative lookahead), we have to leverage the rule guard to allow assets to continue to be served (css, jpg, png).

Using Ruby 1.9, this rule is simpler.

  # Ruby 1.9.x
  maintenance_file = File.join(RAILS_ROOT, 'public', 'system', 'maintenance.html')
  send_file /(.*)$(?<!css|png|jpg)/, maintenance_file, :if => Proc.new { |rack_env|
    File.exists?(maintenance_file)
  }

Users of 1.8.x can leverage Oniguruma to keep the rule simpler.

  # Ruby 1.8.x + Oniguruma
  maintenance_file = File.join(RAILS_ROOT, 'public', 'system', 'maintenance.html')
  send_file Oniguruma::ORegexp.new("(.*)$(?<!css|png|jpg)"), maintenance_file, :if => Proc.new { |rack_env|
    File.exists?(maintenance_file)
  }

Timecop is a RubyGem providing “time travel” and “time freezing” capabilities, making it dead simple to test time-dependent code. It provides a unified method to mock Time.now, Date.today, and DateTime.now in a single call.

Documentation is on RubyForge. The source code is hosted at GitHub.

Updates include:

API

• Completely remove Timecop#unset_all (deprecated by Timecop#return in 0.2.0)
• Return Time.now from #freeze, #travel and #return — code contributed by Keith Bennett (keithrbennett)

Maintenance

• Fix bug that left Time#mock_time set in some instances
• Upped build dependency to jeweler ~> 1.2.1
• Don’t pollute top-level namespace with classes/constants

Documentation

• Clearer examples in the README, better description in the gemspec
• Improve RDoc

• Replacing your current ruby installation with a patched version
• Installing a gem to patch the code and then updating your application to load the patch.

The latter approach only postpones the inevitable, so I opted for the former. If you’re using the debian packages, it’s a simple call to aptitude update. However, if you’ve installed from source, this presents a few challenges.

The upgrade is actually quite straightforward. According to the REE Documentation, you simply need to run the new installer over top of your previous installation. This includes specifying the exact same directory name that you used to install the previous version.

As you may know, REE installs by default into /opt/ruby-enterprise-1.8.6-<year_month_day_release>. However, after completing this, you’re left with a directory name that doesn’t reflect what’s actually installed in there. If you’ve a little neurotic like I am, you’re going to want to rename that directory. However, be careful. Your Passenger configuration is likely pointing to the directory that you want to rename, so you’ll have to remember to update your apache/nginx configuration to reflect this.

When we install REE we create a symlink at /opt/ruby which points to the version of ruby that we want passenger to run. This allows us to quickly swap in/out different versions of ruby for testing/upgrading/etc.

Considering we have dozens of client applications running on distinct servers each with their own versions of REE installed, I decided to write a script to minimize the manual effort required to upgrade several production servers.

#!/bin/sh
# Author: John Trupiano
# Script to upgrade an REE installation on a hot server and maintain sane directory names
 
if [ "$(whoami)" != "root" ]; then
  echo "You need to be root to run this!"
  exit 2
fi
 
RF_RELEASE=58677
REE_VERSION=20090610
REE=ruby-enterprise-1.8.6-$REE_VERSION
URL=http://rubyforge.org/frs/download.php/$RF_RELEASE/$REE.tar.gz
 
# Determine what the most recent version of REE is that is installed
MOST_RECENT_REE_VERSION=`ls /opt | awk -F"-" '$4 > max && $2 == "enterprise" { max=$4; maxline=$0 }; END { print max }'`
MOST_RECENT_REE=ruby-enterprise-1.8.6-$MOST_RECENT_REE_VERSION
 
WORKING_DIR=/root/src
 
echo "Going to update $MOST_RECENT_REE to $REE"
 
echo "Back up previous release"
cp -R /opt/$MOST_RECENT_REE /opt/$MOST_RECENT_REE.bak
 
echo "Download new release"
mkdir -p $WORKING_DIR
cd $WORKING_DIR && wget $URL
 
echo "Untar and install over the previous release for 'upgrade' according to REE manual"
tar xzf $REE.tar.gz
./$REE/installer --auto /opt/$MOST_RECENT_REE
 
echo "Shuffle folder names to remain sane"
mv /opt/$MOST_RECENT_REE /opt/$REE && mv /opt/$MOST_RECENT_REE.bak /opt/$MOST_RECENT_REE
 
echo "Actually symlink in the new version of REE"
rm /opt/ruby && ln -s /opt/$REE /opt/ruby
 
echo "Clean up after ourselves"
rm -f $WORKING_DIR/$REE

Simply upload this script to your server, su – up to root and run it. Then restart apache/nginx so that passenger will pick up the new version of ruby. All of your gems will be maintained, and your most recent version of REE will remain in tact at /opt/ruby-enterprise-1.8.6-<old_version> in case you need it again.

View the script on github