We had an excellent tech talk on Vertebra from Ezra Zygmuntowicz and the folks at EngineYard. If you’ve ever been a sysadmin responsible for many boxes, you’ll appreciate the awesome potential of Vertebra…
NetBeans and symlinks: a team was having problems with symlinks in SVN disappearing after a client edited the project in NetBeans. No, he was not using Windows…
Here are some tips for working with acts_as_paranoid (We have helpers for some of these in our common libraries):
Add :scope for validates_uniqueness_of
validates_uniqueness_of :user_id, :scope => :deleted_at
Add :conditions for named_scope with :joins
:select => "users.*",
:joins => :paranoid_relation,
:conditions => 'paranoid_relations.deleted_at IS NULL',
Ask for Help
This question came up at standup. I’ve put some thought into it, so I thought I’d throw it out for discussion and see what other people think.
At Pivotal, we use svn:externals and the Third-Party Branch Pattern (from the SCM Patterns Book) to manage easy, reliable cross-project updates of common plugins which live elsewhere (rubyforge, etc), without having to manually update in every project or be at the mercy of the RubyForge svn repo going down or being slow. When everything was on SVN, this worked well; we had some rake tasks which made it easy to update the branch from the latest trunk version in the external vendor repository. However, with more stuff like Desert is moving to GitHub.
One option is to just check the entire Git repo into subversion. This is labor-intensive, though. It also loses some of the benefits of the Third-Party branch pattern, such being able to easily preserve local patches while still pulling in changes from a new vendor version. We could probably update our Rake tasks to handle Git as well as SVN.
Another option is to switch all our projects to Git, but we aren’t quite ready for that across the board.
Plus, this is a problem even if you move your parent project to Git. For example, there is no easy Git equivalent to having a svn:external which automatically updates to the latest version of an external repository, which is a useful approach for Continuous Integration or automatically pulling the latest Edge Rails into your project on every update.
Here’s some links from people working on related issues, but please comment if you have any ideas or something that works well for you:
Ask for Help
We upgraded to rails 2.1 and polonium and our rspecs
are not running on CI, but run fine if you simply use rake on the
Check to see if you are using the rake extensions in pivotal core bundle.
Using setTimeout() to wait for DOM to update in JsUnit does not work.
Using setTimeout in tests is not going to do what you want, unless you mock setTimeout. Basically, setTimeout kicks off another thread which is not likely to effect the current test.
- There was an edge version of Rails (this project has a frozen Rails at some point in the past) that had a bug where a namespaced route would send a POST that should go to
MyController#create was instead going to a POST to
MyController#index. The fix is to freeze to current Edge, or use
Ask for Help
“Any way to turn off a validation in a re-opened class?”
No way to do this. Best to refactor by pulling the validation out of the class and then mixing it in, or not, at a different level.
- Y!Slow + Firebug + submit a form will cause the result to be pulled from cache instead of hitting your server. The workaround is to disable Y!Slow.
- Some of our customers are requesting targeting Firefox 3, which has some rendering differences from FF2. So we’re adding FF3 to the system image with a new icon and the correct trick to let it run side-by-side with FF2.
- On a related note, rumor is that Facebook is dropping support for IE6. So is 37Signals.
- Interesting issues with the Globalize plugin & Rails 2.1:
- The currency formatting code does not work at all anymore – it always uses a ‘$’
- Their work for localizing templates, which involves injecting a fully-qualified path, breaks
#assert_template. The workaround is to comment out the path injection code, but this only works if you don’t have localized templates.
- EngineYard’s eycap gem version 0.3.6 now has better support for deploying from SVN tags
- Deploying from tag, since the URL was different used to do a
rm -rf, which takes a long time on EY’s GFS disks for large file sizes. This was causing a customer’s deploy taking ~20 minutes
- The fix was to change eycap to use svn switch; the deploy now takes ~1 minute
Ask for Help
“Anyone seen/solved an issue with random font size increase using Firebug 1.1 or later?”
The issue is that at some point a page will render with much larger fonts and the CSS exploration won’t tell you why. The work around is to launch a browser with Firebug disabled and run it side by side with the same page in a window with Firebug enabled (restarting the 2nd window whenever the problem occurs.)
Seeing this with Firefox 2 and 3 and any Firebug later than 1.05 (which doesn’t run on FF3). This might be an issue with IFRAMEs, but we’re not sure. No data found on this via Google searches or the Firebug group. We will post there.
Model#update_all is your friend if you’re not yet on Rails 2.1
Model#update_attribute for each attribute,
#update_all will save direct to the database, bypassing validation, updating only the columns you specify. In Rails 2.1, with partial model updates, you may not need this. But if you’ve not yet upgraded your application, then give
#update_all a try.
Update: fixed per comment.
Model#update_attribute does not validate. Thanks for the catch!
Watch out for Firebug 1.1.0b12 for Firefox 2! It is The Evil. Several hours have been wasted as teams try to figure out what they are doing wrong (“Why are all of the fonts twice as big?!?!”) only to find out that this version of Firebug was the culprit.
- Uninstall Firebug from the Tools – Add-ons menu
- Restart Firefox. Do not skip this step!
- Install Firebug 1.0.5
- If using Desert and Rails 2.1, if the first view loaded is from a plugin things blow up.
Ask for Help
“How can I make follow_redirect go to a URL?”
When using a follow_redirect to a URL instead of a hash, the test fails with a string conversion exception. No solutions were forthcoming.