Twitter's Bootstrap is a pretty awesome toolkit to kickstart your next web app. But it uses Less. And that's unfortunate for the Rails community as Sass (SCSS) is pretty much defacto now.
So what should we do if we want to use Bootstrap in a Rails 3.1 project, and make it co-exist with Sass?
Here's how I do it.
1) Add Less to your Gemfile.
2) Submodule Bootstrap into your assets/stylesheets folder.
3) Create a bootstrap.less in assets/stylesheets to import the Bootstrap stylesheets you need.
4) Add that bootstrap.less to your application.css.
As for Sass files, I keep my main SCSS file (where I do all my @imports) in sass_main.scss, and add it to my application.css as well.
You are always up to date. Boostrap is under constant improvement and there are frequent pushes. Using Bootstrap as a submodule pointing to the main repo lets you pull in the latest changes anytime, without waiting on forks to port them over.
Sass and Sprockets still work as intended.
Extend Bootstrap as necessary, through cascading/adding Less files.
Update (Jan 22 2012): Bootstrap is consistently changing, so I've genericized the steps to illustrate the concept. Should you require the full Bootstrap suite beyond the stylesheets, you could still maintain the repo as a submodule, and use symlinks to point to the relavant folders within Bootstrap.
When performance wasn't a consideration from day one, inefficiency becomes endemic, corrupting every square mibbibyte of the project. Why not iterate a giant array instead of using hashes? Why not use LINQ everywhere, repeatedly and inefficiently filtering a massively excessive superset of the needed data?
Firstly, I feel that the array vs hash and LINQ examples are fairly contrived. In reality, a good engineer shouldn't even consider those approaches in the first place. There's rarely a compelling reason to do so.
A decent solution of either example would take marginally more time and produce way better code. And that's a trade-off a good engineer makes in a heartbeat from experience.
Engineering is about making business goals/optimization trade-off decisions. Constantly. One of the many traits of good engineers is how quickly and accurately (on hindsight) we can make such decisions. Unless the business goal is optimization.
I find that these debates often come down to an either-or proposition: “put off optimization indefinitely” or “optimize to the max the whole way through.” But it should never be so black and white. From a business view, both approaches are wrong, as they tend to entail unnecessary costs.
After much programming experience, including trying both extremes, I've learned that a middle road is the most cost-effective.
Those stats on your Google Analytics dashboard may not be real.
I developed an analytics system for a project I worked on a while back. We always compared our numbers to Google Analytics as one of our benchmarks. But our system kept reporting lower numbers, consistently.
So after diving into the deep end, here's what I discovered:
Your Google Analytics numbers for the past month are an approximation. Especially if you have high traffic.
Google revises your numbers towards the real ones gradually.
You'll only see your real numbers only about a month later.
And unfortunately, all this was confirmed by AWS' big spring crash of 2011.
For all the great features that Google Analytics provides us, I can see why they approximate the way they do.
Practical analytics systems are a game of pick two out of the three:
1) Generic collection
2) Multi-dimensional slicing
3) Real time reporting
Do all three and you'll have to hire yourself a team.
This is a series featuring ideas I came up with during my spare time over the years. These weren't as compelling as the side projects I worked on, so I didn't get a chance to develop them further. But hey, ideas are cheap.
I had a chat with a friend yesterday. We started throwing startups into “business model buckets”. And eventually, there were three.
1. Brains.
Aka returning users meaningfully contributing to your site and your treasure trove of data. These are behavioral change/shoot for the moon/change the world kind of ideas.
Monetization: Not immediately. Get the brains, hit critical mass, then your monetization strategy kicks in.
Hiccups: Hard to get right. Need funding, unless you have enough to bootstrap the runway.
2. Sales.
There's a demand for your product, and most likely from the long tail. You have to reach out to them and make sales. Your initial revenue is directly proportionate to your sales effort.
Monetization: Built right in. Most likely a tiered or freemium offering.
Monetization: Taking a cut of the transaction; built in from the start.
Fundraising: Would be nice.
Hiccups: Similar to 'Sales', possibly exaggerated due to the chicken and egg problem. Your length of boostrapped runway matters too.
Of course, after increased cash flow and users, the buckets start combining. That said, the type of idea you plays a part in what you initially decide to focus on. Don't have a long enough bootstrapped runway? Devoting yourself to a 'Brains' idea may not be practical.
I'm sure these buckets are obvious to many of us. But it's always good to revisit them as we think of our next big thing.