Deploy Strategies
If you look at the network graphs of heroku_san on github, you'll see a number of branches where the only change is the deletion of the following line from the deploy task:
- stage.migrate
If more than a few people are willing to take the effort to fork a gem just so they can delete 1 line, something smells. The reason is that these forkers were using something other than Rails+ActiveRecord+SQL in their project. Some were using Sinatra, others were using Rails, but with CouchDB.
The raison d'être for the heroku_san gem is to make Heroku deploys dirt simple. So, if people are making whole forks to customize the deploy task, we should make it less painful.
Quiz time!
- How many times (each day) have you typed this at your console?
git push heroku masterand then forgotten to runheroku run rake db:migrate --app yellow-snow-3141orheroku ps:restart - Does your script support a multi-stage environments?
- Do you remember how to get to the application's console process?
- Is your application's configuration consistent across all stages?
- Are you deploy scripts tested?
Help
"What's the best admin gem out there?"
- I've used typus and it's great, https://github.com/fesplugas/typus
- I know Erik Michaels-Ober has a good admin gem, https://github.com/sferik/rails_admin
- Active scaffold isn't admin specific but that could work
Interesting
"Amazon Web Services is down"
This is one of the longest outages we've seen of Amazon and thus Heroku. So many Ruby applications rely on Heroku that the community is certainly affected. Updates on the damage are on Heroku and Amazon. You can see how far reaching problems on EC2 are on ec2disabled.com
"Obama is in town!"
There have been rumors he is visiting a few notable software companies in the area, hopefully he'll stop by. Watch out for blocked streets for the motorcade.
Help
Some pivots are having trouble with a flash embed tag's scale attribute. The desired behavior is that the movie scale to fit the size of the element. According to documentation, this should just work. The flash content will not scale, instead the content is getting cropped.
Anyone have experience using Amazon RDS with Heroku?
Several projects at Pivotal have used this combination with great success.
Interesting
- A project had some intermittently slow queries. The problem was traced back to some large strings in one of the columns. The team solved this problem by overriding the default scope, and only selecting the expensive column when needed.
Helps
- Bundler + Heroku gotcha: Deploys to Heroku can break if you are using Bundler v1.0.6 in your local development environment (as of this writing, Heroku is using v1.0.3). Apparently the
--deploymentswitch is being stripped off andGemfile.lockis rebuilt. If the file differs from what's in the git repository, the deploy will fail with a somewhat mysterious error message. Work-around: Specify the bundler gem version to v1.0.3 (perhaps even up to v1.0.5) in yourGemfile.
Interesting:
bundle install --without testexcludes the test group in your Gemfile from the install. It works well for reducing the size of your Heroku slug. However, there's a glitch with this option on Heroku -- when you specify it, Heroku reinstalls every included gem every time you deploy. It does respect your Gemfile.lock, so you're trading a smaller slug for a longer deploy.Pivotal's open source CIMonitor project now supports OpenID! Thanks Tyler and Josh.
Arel has a bug that makes it difficult to use in
rails console. Every time you add a predicate, the number of internal objects in the Arel result increases exponentially. So, by the time you have 5 or 6 predicates, the console finishes generating the expression more or less instantly, and then spends 15+ minutes callingto_son the resulting Arel object in order to display it to you. tl;dr: when you're playing with Arel in rails console, end every line with; nilto avoid having it print out the result. The exponential object explosion will be fixed in Rails 3.1.
I've been wanting to use Pivotal Tracker on my iPhone, so I wrote a little proof of concept using the Tracker API. I thought that a native application would be much more difficult than a skinned web application using ActiveResource.
I tried out Dashcode, Apple's recommended iPhone-compatible front-end web development tool, but was disappointed. I basically found myself developing the entire application in javascript, actually using XMLHttpRequest to talk directly to the API. This would have been pretty neat if I could have pulled it off, but I'd rather develop a data-heavy application in rails than javascript.
I ended up using simple CSS to skin the application called UiUI. It's the best looking iphone UI I've seen, with tons of elements to choose from. It's missing effects, of course, being only CSS. I also used Heroku, a free and scalable rails deployment environment to host my application. With it, I was up and running with a functional tracker application in under 3 hours. Since then, I've added the ability to create and update stories.
Check it out, let me know what you think: http://itracker.heroku.com
If you're not on an iPhone, be sure to use Safari. It doesn't look great in Firefox or IE.