Monthly Archive for November, 2007

Is this dog 200 feet tall?

Ettore the Maremma Sheepdog

200 foot tall dog

200 foot tall dog

Building Ruby with OpenSSL on Debian

If you are building Ruby by hand on Debian and you need OpenSSL support, make sure to install the libssl-dev package (sudo aptitude install libssl-dev). The tricky part is that even if you don’t install it, configuring the Ruby build with OpenSSL (./configure --with-openssl ...) will not complain that the necessary libraries are missing. Why? Here is someone’s guess in the ruby IRC room (I can’t remember if I was in ruby or ruby-lang):

peshalto: I remember long ago when encryption libraries were always supplied as stubs to
deal with export restrictions. not sure if that’s still done today. with a fake library
stub in place, a compile would go along happily and you’d never know that the encryption
was disabled.
peshalto: could that still be the case today? i wonder if it’s picking up a stub from
somewhere and not finding the real library you installed.

Offering defaults when prompting for user input in Capistrano

I use Capistrano to deploy my Rails projects. I often deploy the same project in several environments-- in addition to the production server, we always have a staging server, and sometimes a "data" server where data can be entered before launch. What this means is that I need to modify the server and username variables in deploy.rb whenever I am deploying to a different server, which is a hassle because it brings it out of sync with the version in my Subversion repository. So if I need to commit changes to deploy.rb, I have to do the partial-manual-revert dance: change the variables back to their defaults, commit my other changes, and change the variables back to my custom values. Ugh.

What I would really like is for Capistrano to prompt me for these variables, and also offer defaults with the most common case. Here is my solution:

RUBY:
  1. def prompt_with_default(var, default)
  2.   set(var) do
  3.     Capistrano::CLI.ui.ask "#{var} [#{default}] : "
  4.   end
  5.   set var, default if eval("#{var.to_s}.empty?")
  6. end
  7.  
  8. prompt_with_default(:domain, "example.com")
  9. prompt_with_default(:user, ENV['USER'])

Now the user will be prompted for input for each variable. If the user hits enter without entering any text, the default presented in square brackets will be used.

CODE:
  1. cap deploy:check
  2. domain [example.com] :
  3. user [john] :
  4. * executing `deploy:check'
  5. ..........

Spamgourmet: handy disposable email address service

I'd like to point out a fantastic project that an old buddy of mine from my artmovement.com [site offline for 7 years] days has been running for 7 years: spamgourmet. Spamgourmet provides you with unlimited "disposable email addresses", for when you are forced to use an email address on the web when registering or signing up for something, and you are worried that it might get put onto a spam list or put to some other undesirable use.

It's an ingenius system. Here's how it works. My username is "john". Let's say I need to register with a newspaper in order to gain access to its content, and I don't trust the newspaper with my email address. I'll use an address like this:

nytimes.10.john@spamgourmet.com

This means that up to 10 emails (from anywhere on the internet, actually), can be sent to me through this email address. After it has been used 10 times, ALL email to that address will be discarded.

Neat, huh?

Dissent

I've been working on a film about dissenters at the 2004 Republican National Convention. It's been delayed and backburned for a few years but I'm finally able to get back to it. I just put up version 1 and made a new website for the project, http://dissent.cc.

Head over and check it out, I'd love to know what you think.




Close
Powered by ShareThis