I don’t really care for the suggested approach in the Heroku docs for setting configuration variables locally. I have an open-source project that I’m working to get onto Heroku, so I decided to do a little work to come up with a solution that I prefer. I think this would work well for open source projects, as well as projects with multiple developers.
Here’s the basic idea:
You have a config file that contains all of your local configuration variables. It looks a lot like database.yml.
# config/config.yml
development:
session_key: example_development
session_secret: ESl6X3oKM1i1RRrD2QLwUUzz9jr1zxNO
domain: http://example.com
test:
session_key: example_test
session_secret: vrwPpJTvwnMVLP1wTSgqigSl7PMI7QcE
domain: http://example.com
production:
session_key: # any string identifying your app
session_secret: # a random, secret string at least 32 characters long
domain: # http://example.com
mailer: # noreply@example.com
You perform a little trickery in environment.rb to prefer the Heroku ENV storage of config vars (in the production environment), but you fall back to your config.yml if the config vars aren’t found in ENV (in the development and test environments).
# config/environment.rb
Rails::Initializer.run do |config|
require 'yaml'
# support yaml and heroku config vars, preferring ENV for heroku
CONFIG = (YAML.load_file('config/config.yml')[RAILS_ENV] rescue {}).merge(ENV)
config.action_controller.session = {
:key => CONFIG['session_key'],
:secret => CONFIG['session_secret']
}
end
Then, you create a rake task (rake heroku:config) that can be used to send all of the config vars for your production environment up to Heroku. This task can be invoked once to set things up, but can also be run again if you need to make any additions or changes.
# lib/tasks/heroku.rake
namespace :heroku do
task :config do
puts "Reading config/config.yml and sending config vars to Heroku..."
CONFIG = YAML.load_file('config/config.yml')['production'] rescue {}
command = "heroku config:add"
CONFIG.each {|key, val| command << " #{key}=#{val} " if val }
system command
end
end
This way, you've got all of your config vars stored with the project (.gitignored, of course)...
# .gitignore
/tmp/**/*
/log/*
*.log
/tmp/restart.txt
/config/config.yml
/config/database.yml
/db/*.sqlite3
...and you can easily set what you need on Heroku, like so:
$ rake heroku:config
Reading config/config.yml and sending config vars to Heroku...
Adding config vars:
session_key => example_production
session_secret => 1WlkMkYYi5611vtF...0ZMS2G3Xl67s4lEIK4sj65
domain => http://example.com
mailer => noreply@example.com
Restarting app...done.
The result is a pretty nice, I think.
You can see the installation and deployment instructions for my open source project El Dorado if you're curious about the overall flow.
I'd love to get some feedback on this approach, but I really like it so far :)
How to speed up gem installs 10x
Answer: Turn off ri and rdoc installation.
Perch
Perch is a really little content management system for when you (or your clients) need to edit content without the hassle of setting up a big CMS.
Installing Ruby on Rails and PostgreSQL on OS X, Third Edition
Over the past few years, I’ve helped you walk through the process of getting Ruby on Rails up and running on Mac OS X. The last version has been getting a lot of comments related to issues with the new Apple Leopard, so I’m going this post will expand on previous installation guides with what’s working for me as of January 2008.
Thoughts on Opera Unite
Opera’s CEO Jon von Tetzchner claims that “Opera Unite now decentralizes and democratizes the cloud.” I call bullshit. Opera Unite does indeed rely on a P2P-like network to function, but the big problem is that you must push all your traffic through Opera’s proxy service.
LESS – Leaner CSS
Less is Leaner css. Less extends css by adding: variables, mixins, operations and nested rules. Less uses existing css syntax. This means you can migrate your current .css files to .less in seconds and there is virtually no learning curve.
YC Company Hosting Stats
[Interesting stats and discussion on hosting.]
Rip: a RubyGems Replacement?
This makes package management as simple as passing files between friends. Email me your latest library, and I can run rip install path/to/lib. That’s it — you don’t need spec files, and you don’t need to build anything before your send me your code.
BigTable
BigTable is a fast and extremely large-scale DBMS. However, it departs from the typical convention of a fixed number of columns, instead described by the authors as “a sparse, distributed multi-dimensional sorted map”, sharing characteristics of both row-oriented and column-oriented databases. BigTable is designed to scale into the petabyte range across “hundreds or thousands of machines, and to make it easy to add more machines [to] the system and automatically start taking advantage of those resources without any reconfiguration”.
Opera Unite reinvents the Web: a Web server on the Web browser
[Very interesting possibilities here. Making it easier for people to serve content on the web can only lead to good things.]
tenderlove’s markup_validity
Test for valid markup with test/unit or rspec
Hemlock
Hemlock is an open-source framework that combines the richness of Flash with the scalability of XMPP, facilitating a new class of web applications where multiple users can interact in real time. Games, workspace collaboration, educational tools… The only limit is your imagination.
Rip: A New Package Management System for Ruby
But why a completely new package manager? What’s wrong with RubyGems? We asked one of Rip’s developers, Chris Wanstrath…
Ruby at ThoughtWorks
ThoughtWorks started using Ruby for production projects in 2006, from then till the end of 2008 we had done 41 ruby projects. In preparation for a talk at QCon I surveyed these projects to examine what lessons we can draw from the experience. I describe our thoughts so far on common questions about Ruby’s productivity, speed and maintainability.
[git pull] drm-next
See? All the rules really are pretty simple. There’s that somewhat subtle
interaction between “keep your own history clean” and “never try to clean
up _other_ proples histories”, but if you follow the rules for pulling,
you’ll never have that problem.
Inspired by this post, I thought I’d share a tip that helps me get the most out of GitHub.
Don’t just follow the projects that you’re interested in — follow other users. Here’s a list of people that I’m following. They’re constantly turning me on to new and interesting projects, because I get to see everything they’re working on, and everything they’re following.
Dig around the users that I follow, check out what they’re been up to, and try it out. If you find that your feed becomes a bit much to manage, try subscribing to your personal RSS feed. There’s a link on the home page when you’re logged in.
Thanks, GitHub. You’re the best.
I’m trying to save hard drive space, since I’ve got this super small (and fast?) SSD hard drive on the way. I noticed that I was using a TON of space to store totally worthless logs for my Rails apps. Now, I know I could set up proper log rotation, but I don’t feel like going through the trouble for my local machine.
Here’s a quick tip I picked up here that will set your logs to automatically rotate in the test and development environments. Just add the following line to these files:
- config/development.rb
- config/test.rb
config.logger = Logger.new(config.log_path, 2, 20.megabytes)
Make sure you’ve got these in your .gitignore file as well:
/log/*
*.log
That will keep your log files under control, but with plenty of room for digging in if need be.
