What alternative do you suggest for using models in migrations? I was in several situations where I had to not only change the underlying db structure but change the contained data, too.

Data changes, especially moving data around, are almost always rake task-worthy in my experience.

The other side of that, populating large amounts of seed data into new databases, is a difficult task no matter the method; seed_fu attempted to deal with it, but it’s not an optimal solution and pretty old. I’m not even sure if it works anymore. It’s worse if you need the seed data to be from a legacy database in tests (e.g. a nutritional database). Reloading lots of data each time a clone_structure_to_test is done makes your tests very slow.

I break down migrations into three kinds; structural (tables, columns, indices, etc.), data (pre-populating tables, etc.) and procedural (moving data around, recalculating counts, etc.). The first is what I strive to limit migrations to. I feel like there should be a good answer for the second and Rails 3.0 has a ‘Simplest Thing That Can Work’ feature in Rails commit #4932f7b. The third, I try to relegate to rake tasks that are usually run once, on deployment of the branch.

The procedural tasks don’t need to be run when building a fresh database, because there isn’t legacy data to correct. That’s why you can usually define the model in the migration to force it to work even if the real model is gone or renamed; there’s no data, so the operations often don’t matter. If they don’t NEED to be run when building a fresh database, I try not to put them in the migrations.

It’s not ‘hard and fast’, because I usually work in startups to small companies, where dogma doesn’t work so well. Imagine, though, a large and thin piece of foam. It’s flexible, and you can make it into all sorts of shapes, and yet it’s simple. Each time you add code that makes reasonable changes in the future painful, it’s like putting a thin glass rod into the foam. It’s still flexible, but there’s some bends you can’t do without breaking. Add too many and you’ve got an inflexible and brittle object, no matter how dynamic the base material is.

The fear of breaking things by changing the code is deeply demotivating for everyone.

I know I waterboarded that analogy, but hopefully it makes sense…

— Morgan Schweers, CyberFOX!

Just noting that I closed my ‘gmail’ window, and my Firefox process went from 883M to 585M.
I guarantee that 300M weren’t being used by the gmail page as it stood. Perhaps Google’s Javascript foo is not as powerful as they’d like, and it’s holding onto old AJAX results?

I can guess a few other things about what might be going wrong (caching AJAX requests in the browser, for instance), but one way or another, if you have memory problems with Firefox 2 and you keep a gmail tab open, try closing your gmail tab now and then.

I have to wonder if it’s a general AJAXy problem with Firefox, or specific to gmail…

One way to test (which I’m going to try soon) is to try a ‘reload page’ instead of a ‘close tab’, to see if it’s the browser/page-renderer/caching keeping the memory occupied, or the JavaScript on the page that is abusing memory.

There are limits to how much CPU we allow any given page of JavaScript to have; I’m surprised there aren’t any limits to how much memory it can have.

– Morgan Schweers, CyberFOX!

I used to do this with ‘new windows’ in Netscape 4.x, and I got into a long discussion with a Netscape engineer about my usage patterns (having 40+ Netscape windows open tended to crash it badly eventually), and they acknowledged that the program was unstable under that kind of usage. Worse, was that the email reader ran in the same process as the browser, so crashing the browser crashed my mail. Tabs (and Firefox, as a lighter browser) saved my sanity.

I try to never close my browser, and I reboot my computer only every couple of weeks (and that’s only if it’s my Windows box). Happily with Session Saver, I never had to worry about shutting down my browser, as it preserves my tabs and windows. (I miss Session Saver in Safari…)

If you find that Firefox 1.5 is unstable under too many tabs (it worked pretty well for me), get a session saver. It’s a life-saver when your browser crashes and you would otherwise lose 100+ tabs that you clicked to look at later, so you don’t know what the URLs were…

Firefox 2 ships with (x) on each tab. Bleh. Fix it by browsing to:
about:config
Filter for:
browser.tabs.closeButtons
double-click it, and set the value to:
3
You can create it if it doesn’t already exist.)
I recommend the FF2 extension ‘Restarter’, until they add the Restart option into the menu standard, in order to deal better with adding extensions. For the IE7-ish ‘preview’ mode, I’d suggest the extension Showcase, or Reveal if they update that plugin to 2.0.

I’d also suggest turning on session saving for all sessions, by adding configs:
browser.startup.page=3
browser.sessionstore.resume_session=true
Now if only I could revert to the old ’shrinking tab’ behavior, at least down to a certain width.

Update: You can set this by changing your config options as follows:

browser.tabs.tabClipWidth=35
browser.tabs.tabMinWidth=25
This will set your tab width to 25 pixels minimum, which will let you see a LOT more tabs than the old setting of 100. I chose 35 for the clip width, based on having divided the minWidth by 4, I divided the clipWidth (default of 140) by 4 as well. However, my tab usage often means that I need nothing more than the favicon in the tab to know where I’m going, or I never random-access the tabs, closing one to continue reading at another page.

Anyhow, these have been some power user tips from a dedicated Firefox user.

– Morgan Schweers, CyberFOX!