Disqus - Latest Comments for sfamiliar

Re: Ruby on Rails Code Quality Checklist - Matthew Paul Moore

B.Vandgrift — Mon, 12 Oct 2009 12:47:09 -0000

that's a solid example. not sure what you're meaning by 'domain'. care to elaborate?

Re: Ruby on Rails Code Quality Checklist - Matthew Paul Moore

B.Vandgrift — Wed, 07 Oct 2009 13:50:09 -0000

i know all the cool kids hate STI. i don't. i've used it many times successfully, and avoided it many times successfully. this hate-train for STI, which i maintain comes from (as the image next to the rule accurately depicts) a prejudice kept from another language or project, and it's blind spot that most developers would do well to get over. there are good uses for it, and by avoiding it unreasonably, your code isn't as clean and dry as it could be.

the real problem with STI in AR is that most people use it poorly: i.e., they take two models which have no relationship and have them share a table. we've all seen enough of that to know it's bad, however when you have a series of models that inherit the same data but require different rendering, processing, or validation, STI is the way to go.

the classic blog example? posts come from the blog, tweets come from your twitter feed, links come from delicious, images come from flickr, and they're all pulled and displayed on your blog (and stored in your db). four models, right? four db tables? each one has .. let's see .. an id, a date, a description, an author, maybe a source. so let's build four tables that do exactly the same thing? no -- use STI. in this use case, STI enables you to write different display partials for each type, accurately separating the data storage from the logic from the display. the data isn't likely to change. the views are likely to be fluid. you can write an abstract controller which each type controller inherits from as necessary, saving yourself a ton of time and making your views/ directory pristine and intuitive. the only reason to avoid this is because some big name in the rails community who used STI wrong that one time told you not to.

pull the blinders off, and jump off the bandwagon.

Re: It’s neither the chicken, nor the egg – Thoughts on disrupting online dating business models

B.Vandgrift — Wed, 10 Jun 2009 16:14:27 -0000

no need to steal the idea, we're already running that app. flowmingle.com integrated facebook connect several months ago, for a lot of these reasons. there are other big problems with online dating. the toothbrush dilemma, the lack of any kind of introduction process, sites overrun with bots, and a general failure to provide a method to get to know another person. we think we've largely solved these problems.

the reason we went with a cocktail-party like process is that small groups foster conversation, especially when the topics are guided. introduce 20 people. throw out a few topics for conversation, and let people express their opinions, ideas, dreams, etc. let them interact in an environment that's easy and fun to use, and where they don't have to worry about the traditional dating pitfalls, or barriers to communication. we WANT you to exchange email addresses, phone numbers, and IM information, for instance.

i invite you to take a look and see what our potential is for disrupting the modern online dating market. i think it's solid.

Re: SASS: The Better, More Powerful CSS - Intridea Company Blog

B.Vandgrift — Thu, 05 Feb 2009 11:07:04 -0000

Thanks for posting this. I've been vaguely aware of SASS for a bit, but never found a compelling reason to look deeper into it, partly because of bad experiences early on with haml, but mostly because I hadn't seen a good 'executive summary' type of article that was fast and easily digestible.

Call that problem solved.