Listen here (we're mentioned at 01:10)
Day to Day, July 8, 2008 · Outsource your daily tasks, stop making to-do lists in favor of to-don't lists. Timothy Ferriss, author of The 4-Hour Workweek: Escape 9-5, Live Anywhere, and Join the New Rich, offers guidelines for a plusher life, without a Blackberry. Hard-working Madeleine Brand considers how she could adapt them to her life.
| leave a comment |
Article: Creators of E-Mail Monster Now Try to Tame It
This will supposedly be on the front page of tomorrow's print edition.
| leave a comment |
This article interviewing Tim Ferriss, productivity guru and author of The 4-Hour Work Week, is on the front page of U.S. News and World Report's website today.
This is my favorite part:
That leads me to the importance of becoming aware of how you are spending or misspending time while you're on a computer. Do a time audit. Rescuetime.com will tell you how much time you spent on different websites and pages. It creates graphs and charts and tells you how you're wasting your time.
| leave a comment |
Here's a snippet from our google analytics for the web traffic of rescuetime.com.
The spike in the beginning is TechCrunch/LifeHacker coverage. The rest is word of mouth.
Our user signup graph is starting to look exponential.
Awesome.
| leave a comment |
We're going through the guts of RescueTime this week doing our monthly optimization of the database and all of the queries we use to generate and visualize our time management data.
One of the things we turned up that happens whenever a user client pushes data to our api servers is that this is the first thing that happens:
User Load (0.044165) SELECT * FROM users WHERE (email = 'blah@blah.com') LIMIT 1
User Columns (0.023302) SHOW FIELDS FROM users
User Load (0.612006) SELECT * FROM users WHERE (LOWER(users.email) = 'blah@blah.com' AND users.id <> 323224212) LIMIT 1
Notice the 0.6 second select call. That happens when we update the last_data_sent field on the user object and save it using ActiveRecord's save! method. The reason is because it's validating uniqueness of the user's email address (in case it happened to have been changed) - even though it clearly hasn't changed. Why isn't there a dirty flag there? Anyway, that's beside the point. This is going to continue to get worse for us as we grow our user table size.
The solution is to do this:
User.update_all(["last_data_sent = ?", Time.now], ["id = ?", 323224212])
which doesn't perform any validations (which we don't need here) and is appropriately fast. This is an example of how Rails is super great for getting things up and running quickly, but forgetting to go back and optimize can really hurt you. In our case we're shaving off more than 1/2 a second from every api call.
We've also already made changes to our database which have cut it in size from 20GB to 2GB... but I won't go into those here.
| leave a comment |
