No, We Really Mean “Vendor It”

Posted by s.f. on June 13, 2011

(Originally posted on tumblr)

Now that we have both RVM and Bundler, you’re following the advice in this article and keeping all your gems in source control, right?

No? Why not? “I have a custom fork that I don’t want to put on a public server”? Pfshaw!

1. Put a ‘:git’ option in your Gemfile pointing to your local repo:

gem ‘my_custom_gem’, ’1.0.0′, :git=>’file://path/to/your/repo’

2. Follow the steps in the article:

bundle install –path vendor’

bundler package

Make sure the gem file for your custom gem is in vendor/cache.

3. Remove the :git flag in your Gemfile

gem ‘my_custom_gem’, ’1.0.0′

4. Run

bundle install –path vendor

again to remove the git references from Gemfile.lock.

5. Check in vendor/cache/*, Gemfile, Gemfile.lock, and .bundle/config to source control.

There now, that wasn’t so hard. And now you don’t have to worry about losing the original git repo, or reinstalling the custom gem on every deploy.

God, sphinx, and you

Posted by s.f. on April 15, 2008

god is my newest favorite tool for server and Rails monitoring, not to mention the entertaining conversations it can produce(“God was spanking the mongrels repeatedly, without letting them fully start”, “god spammed my mailbox with over 700 emails this weekend”, “I’m killing god right now, it should be back in a minute”). One of the last pieces I forgot to include in this setup was Sphinx and, in an apt demonstration of Murphy’s law, it decided to silently die this weekend while I was out of town. So the first thing I did today was to let god manage it as well.

One hurdle people might run into is whether to let god auto-daemonize the process(a useful feature indeed), but our hand is forced by Sphinx already daemonizing itself along with its own PID file(trying to let both god and a process daemonize itself is pretty much crossing the streams). Fortunately, sphinx provides its own “stop” command so we don’t have to go crazy trying to lookup a PID in our god config:

w.start = "searchd -c #{RAILS_ROOT}/config/#{RAILS_ENV}.sphinx.conf"
w.stop = "searchd -c #{RAILS_ROOT}/config/#{RAILS_ENV}.sphinx.conf --stop"
w.pid_file = File.join(RAILS_ROOT, "log/searchd.#{RAILS_ENV}.pid")

Easy peasy. I absolutely adore god’s ability to plug into the event system on OSX, so between god and launchd, I’ve almost got a bulletproof config[1].

[1] “bulletproof” for the value of “resists .22 rounds hand-thrown at it by a grade-schooler”, mind you.

sittin’ calm after pres butan 2

Posted by s.f. on March 11, 2008

Last Monday, the Rails pseudo-content-management-system that I’ve been working on for the past nine months went live at the Yakima, replacing a 4-year old system that ezmobius designed as his first Rails project.

This one’s brand-spankin’ new: Rails 2.0 from the get-go, fairly proper REST(where possible), using a dedicated SQL database, adherence to clean design(again, where possible), and copious use of plugins.
(current favorites: has_finder, thinking_sphinx, acts_as_state_machine, will_paginate, and acl_system2).

Granted, there’s still holes, and I’m already working to fix some poor architectural assumptions I made four months ago, but the newsroom is breathing relief at not having to jump through server hoops anymore(which weren’t ezmobius’ fault so much as limitations of tech and budget at the time).

Now eagerly waiting to see if I merit one of the expected Internet replies:

  • “Newspapers are no different than blogs! You’ve wasted your time reimplementing Mephisto! You’re dragging the rest of us Ruby folk down by not implementing something new that nobody’s ever seen yet!”
  • “Man, Rails isn’t really cut out for building a CMS. Why didn’t you use Drupal or Django? Fail, dude, fail.”
  • “Obviously your paper has money to throw away if they let you sit around for nine months instead of buying Ellington!
  • “you use rails haha i could hav don it in a month with PHP u suk”

My human brain needs beer now.

Shells at 30,000 Feet

Posted by s.f. on November 28, 2007

One of the things I’ve noticed is that most OSX hints for setting up anything in *nix-land tell you to add path statements just to ~/.bash_profile, usually assuming that you’re working on your own machine. But if you’re ssh’ing to another OSX(or -nix based) and set up the path in the same way, this will probably cause vlad(and capistrano, I guess) to fail with “command not found”, since they use a non-interactive shell to run commands. There are simple fixes: enable PermitUserEnvironment in your /etc/sshd_conf file. Which works, but 1: it’s a potential security hole(paranoia, a game we all can play!), and 2: it’s overkill, because having your path in ~/.bashrc is the proper way to do it, as pointed out here.