Just came across this awesome post that describes how to fix an annoying bug with autotest that causes it not to show up like half the time. I hated having to go back to the terminal whenever growl didn't popup; every time it was another half second of my life wasted. I must've wasted upwards of 3 minutes because of this bug. I could've killed like 3 level 11 Goretusks in that time (just started playing WoW - level 15 Human Lock, username merckens, keep an eye out for me - I'll be the guy dominating everyone). If you've noticed this problem with your autotest-growl interaction, read the post. Worked for me.

Rails has come a long way quickly, but one of the biggest problems with our favorite MVC framework is support for multiple databases.

Sure you can use self.table_name and/or establish_connection to force a model to point to a table in a different db, but try running a freaking test with fixtures for the offshoot models, and you'll see what I'm talking about.

Even more depressing is SQLite3's lack of cross-database query join support, making this statement impossible:

has_and_belongs_to_many :blocked_users,
:class_name => 'User', :join_table => :blocked_users,
:foreign_key => "user_id", :association_foreign_key => "blocked_user_id"

Here's the kicker: All of our apps are multi-database apps, so that means no more SQLite allowed for us, and I really loved it until now.

If I'm wrong, let me know. I'd love to go back to using SQLite for local development. Same for an easy way to load fixtures.

We launched Fight For The Top about two and a half months ago (one third of the time, I've been on top), and it's turned into a fun little Facebook Application. Like all our products thus far, it grew to where it is organically. No ads, marketing or publicity.

Today that changes. We asked ESPN's ad group to create a banner ad for it, and the ad went into rotation today on ESPN.com.

Let's hope it brings in some new challengers.

I love this: Reddit, Stumbleupon, Del.icio.us and Hacker News Algorithms Exposed!

Reddit's algorithm is probably my favorite, using logarithms to weight earlier votes more heavily. Although I do enjoy the StumbleUpon "safety variable" (which keeps it from being totally gamed). And the del.icio.us algorithm is kind of remarkable in its simplicity. As Danny says though, the "10,000 Pound Gorilla in the Room" is of course Digg's algorithm, which is stored in a single machine buried 5 miles below the surface of the Earth.

Opened up irb and had a little fun this morning:

%w(good morning dary).each {|w| system("say -v Victoria #{w}")}

Awww. Good morning to you too Victoria

MySpace will launch its Data Availability later today (see here and here), beating Google and Facebook to the punch.

Unfortunately all three will be pretty much useless to us.

First, there are legal issues with sharing data, which I wrote about previously.

But that's not the biggest problem. None of these services will allow you to store anything beyond simple ids (no social graph, photos, etc). In MySpace's case, a developer can't even cache this data.

So every time we render a page, we'd be calling out to MySpace. The performance implications of doing this would relegate potential asewome data to a buried link, like "See my MySpace data". Vomit.

Let me know when we can sync. That's what data portability really is. I want to be able to upload a photo, add a friend, remove a friend, write a comment or change my first name, and have it appeaer across all my social networks. I want to see relationships. What team is most popular among MySpace users? Between MySpace and Facebook users, who is more accurate at picking scores and winners?

Sure, this may be a boon for sites that don't have any compelling user data of there own and get virtually no traffic, but those sites aren't relevant anyway.

Until we can sync data across social networks, all this "Data Portability" is just PR.

Steven Hodson wrote a nice post about the absurdity of a newspaper deathwatch.

Sometimes, people in our industry never cease to amaze me with how myopic they are. Couple quick points. When we say newspapers are dying, are we talking about the physical paper we hold in are hands or are we talking about the industry itself? Both are fairly ridiculous, but I would be willing to  entertain the notion that the physical paper may be on its way out with this green movement and technology shift. But to assume that, say, the nytimes.com will be replace by a network of blogs is patently absurd.

Sure, blogs like techcrunch, mashable and the usual suspects often scoop traditional media, but technology is one of hundreds of topics newspapers cover.

When blogs start covering local townhall meetings and writing features and ride-alongs, then we can talk.

Just checked out this video (links directly to m4v file) that someone forwarded to me earlier today.

Basically when trying to scale a rails app (or really any web based app) there are three core rules to live by.

1) Spindles = Bad. Talking to databases and/or file systems are slow.

2) Dynamic to static. Dynamic content is your enemy.

3) Push to the edge. Push everything as close to the client as you can.

"Rails scales exactly like any other web application... You need to take into account all the components, from the moment the request is received into the load balancer, all the way down, and all the way back again."

We're constantly working on improving performance on Fan Profiles as it continues to grow and have learned that these core rules are indeed the way to live by when working on scaling issues. Our work is far from done and likely will never be, but it's cool to see another sucessful rails team discuss these issues and how they tackled them.

Sunday provided a wonderful conclusion to RailsConf 2008. Here are some brief notes for the sessions I attended to whet your appetite with links to their RailsConf pages (where you can grab slides).

Waxing Ballroom Floors on the Titanic (and Other Less Seaworthy Vessels) - Rick Bradley, Yossef Mendelssohn, Kevin Barnes (OG Consulting) (RailsConf page)
Plugins:
object_daddy
timely
shmemeter
autochronic
freshtrack
nihilist_bot
flame

Genomes on Rails - Matt Wood (Wellcome Trust Sanger Institute) (RailsConf page)
Frequently and rapidly changing data

• Don’t have fields – store data as Descriptor/DescriptorValue objects (key/value pairs)
• With careful indexing it’s not that slow
• If one field is consistent across versions, that can be added to the db
• Can map Descriptors between different versions

They specify task the same way and allow users to create pipelines for various projects
Throughput: Data → 320tb/450 cpu cluster → Archive (2 Petabytes of data)

• Multiple instances of multiple applications (loosely coupled)
• Deployment is difficult because you need to push to all your instances
• reverse proxying with fairnginx in front of mongrels, deploying with cap

The Profitable Programmer: Creating Successful Side Projects - Geoffrey Grosenbach (Topfunky Corporation), Tom Preston-Werner (Powerset, Inc.), Chris Wanstrath (Err Free), PJ Hyett (Err Free), Ben Curtis (Catch the Best) (RailsConf page)
Project Ideas:

• Build something simple
• Build something you want to use
• Take something that’s already popular in one area and move it to one where it doesn’t exist

Implementation:

• Build it yourself
• Sub-contract

Promotion:

• Allow free accounts with limited, but useful functionality
• Piggyback on already established people and sites
• Form symbiotic relationships with existing sites
• Drive traffic to their sites
• Promote their product through yours

Success:

• Don’t listen to critics as you go through issues while expanding
• Try to build apps that are a source of constant income and require little effort to maintain
• Avoid VC → basically just getting a boss

Notes:

• Donationware? Ads?
• Ads are tricky because you have to become a marketer
• Market Research
• Track how people interact with the app and not how they say they interact or are going to interact with it
• Try to do something where its easy to get to people you want to sell to
• Think about how often people will use it (including you)
• Keep in mind who’s actually going to be paying for it

That's it. What an amazing conference. Can't wait until next year!

RubyGems 1.2 is available now. Everyone should update. In addition to a few bug fixes, it also removes the need to bulk update (which I think is pretty sweet).

RubyForge page