astral projections

This blog is dead, long live this blog.

Tue, 16 Jun 2009 17:42:49 GMT

Actually, long live the idea of this blog broken up into many tiny pieces. This has always been a way for me to post my random thoughts about things but lately I've been able to find other outlets for them - Twitter and Facebook. If you'd like to have a more scattered, but at least semi interactive view into my world, you can friend me on Facebook (if I've met you in person) and/or follow me on Twitter.

And with that I likely conclude my broadcast here (at least, in public).

Edit: Ok, Maybe I won't conclude, but I had to put something up since I haven't posted in FOREVER. :P

Productivity Porn

Thu, 22 Jan 2009 03:09:25 GMT

Random:

Here's a look at my top 5 applications from 2008 and how much time I spent in them by week.
(from an alpha version of an upcoming version of RescueTime)

TextMate is the app I use to do all my coding. It was a rough summer for writing code, it seems...

This is just ..... so cool

Fri, 07 Nov 2008 05:29:42 GMT

Check this out.

Our next president has a blog.

The entire website makes me giddy. If this is what we can expect from our new administration when it comes to information access and interaction, I'm going to feel so at home.

From the page source:


    document.write(unescape("%3Cscript src='" + gaJsHost + "google-analytics.com/ga.js'

They use google analytics.

This is a really interesting page. I love that they essentially have a feedback/submit ideas form.

Based on this and the barackobama.com site (on which I made a profile in Feb 2007, btw ha), you can tell the people in charge are on top of the latest in internet application development best practices. Their entire site is pretty state of the art. I can't wait to see where they're going to take this.

Government 2.0 is coming.

Edit: I forgot he also twitters: http://twitter.com/barackobama

Fix for psyco in Django 1.0 query module

Thu, 23 Oct 2008 22:59:40 GMT

Today I enabled threaded (mpm worker) mod_python to try to boost performance of the RescueTime back end and started noticing the following error showing up in the logs:


File "/opt/lib/python2.5/site-packages/django/db/models/query.py", line 497, in _filter_or_exclude
    clone = self._clone()
File "/opt/lib/python2.5/site-packages/django/db/models/query.py", line 595, in _clone
    query = self.query.clone()
File "/opt/lib/python2.5/site-packages/django/db/models/sql/query.py", line 195, in clone
    obj.__dict__.update(kwargs)
TypeError: descriptor '__dict__' for 'Empty' objects doesn't apply to 'Query' object'

The problem appears to be due to the magic that function does of
changing the runtime class of an object (which is explicitly listed as a known bug with using psyco on their site).

To fix it, I figured I'd just prevent that particular method from getting optimized by psyco, so I added this to the top of my models.py file:


from django.db import models
import psyco
psyco.cannotcompile(models.sql.query.Query.clone)

So far so good...

RescueTime Raises Funding

Tue, 23 Sep 2008 02:13:08 GMT

RescueTime Proving Useful For The Enterprise, Raises $900k

Y Combinator startup RescueTime lets users monitor which applications and websites they use/visit the most, and then lets them use that information to try to cut down on inefficient uses of time. It’s useful on an individual basis, and it helps businesses (who pay $4-$8/user/month) monitor what applications are being used, and where time is being wasted.

Not even a year old, our work is just getting started - but we have a lot more time and resources to help us now.

Tony on FastCompany.tv

Sat, 19 Jul 2008 02:23:58 GMT

Tony talks to Scoble about RescueTime, and uses my computer to show it off. Oh he mentions my work habits too (ha!). It was filmed at the old Jobster offices in Pioneer Square.

http://www.fastcompany.tv/video/see-how-much-tme-you-are-wasting-with-rescuetime

This one is cool - RescueTime on NPR

Tue, 08 Jul 2008 23:08:16 GMT

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.

Obligatory NY Times Braggery

Sat, 14 Jun 2008 02:49:55 GMT

Article: Creators of E-Mail Monster Now Try to Tame It

This will supposedly be on the front page of tomorrow's print edition.

This little robot box has stolen my heart

Thu, 24 Apr 2008 17:51:26 GMT

RescueTime in U.S. News and World Report

Thu, 27 Mar 2008 17:05:59 GMT

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.

- Tim Ferriss

Thanks, Tim! That's a great plug!

I love this trend

Mon, 10 Mar 2008 06:24:26 GMT

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.

Rails Wisdom of the Day

Wed, 13 Feb 2008 17:28:39 GMT

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.

Well gee...

Fri, 01 Feb 2008 21:58:09 GMT

I'm an optimist, which sometimes makes me give people too much of the benefit of the doubt. Case in point: I'm an Obama supporter (I've been for a long while, back before it was cool) but lately I'd been thinking that if one of the worst case scenarios happens in the next election, namely McCain being elected, that it wouldn't be all that terrible.

This makes me wanna kinda change my mind. Can we please not elect any of these crazy Republican guys? Please? I'm tired of watching my homeland turn into a crazy-town.

I guess my computer says something about me

Thu, 31 Jan 2008 22:58:46 GMT

I don't have much time to blog these days, but I just had to post this:

Those who claimed a Mac as their primary computer were found to be "more liberal, less modest, and more assured of their superiority than the population at large."

from here

7 Tips for Managing Your Releases Without a QA Department

Mon, 21 Jan 2008 19:40:53 GMT

I've gone back and forth through my career from jobs where I was writing code behind the safety net of a QA department to jobs where I was the only gateway between my code and the wild world of users. At the end of last year I quit my job and started working on RescueTime full-time, once again switching from the world of QA-ed code to what amounts to the seat of my pants. While the details of this jump are fresh in my head, I figured I'd share some of the things that I've learned that should help when you are the only one you're relying on to protect your users from bugs, crashes, and downtime.

When you think you're ready to release a significant batch of new features, wait a couple of days before you deploy to production. The temptation for me is always to release immediately (OMG our users are going to love this! They need it now!), but I've found that by waiting a day or two I always come up with some scenarios, use cases, boundary cases, and bugs that I hadn't thought of. It isn't until you start to get bored with the new features you've written that you really understand what their limits are. It doesn't cost much to take the extra time to let the dust settle in your mind before pushing something out that's not quite ready. Your users who will almost always immediately find what's wrong.

Deploy to a staging environment first. This seems obvious but when it's just you, it's very tempting to feel like your code is golden and just push it right from your laptop to production. Make sure your staging environment runs on its own database (preferably a reasonably recent copy of production) and test out any database migrations on the staging database. A lot of times I make last minute changes to my code on my machine and think they look good enough to not have to test them again. Staging is your sanity check. Use it to your advantage, because nothing drives you more insane than struggling to fix a botched deploy on the live site.

Write tests. It's difficult to justify a huge number of tests in the early phases of a new project (are people even going to use this?) but for features that have been especially tricky to nail down or that just are essential to your product working correctly, it really helps to have tests that you can use as a baseline when you need to refactor. RescueTime just went through a significant architecture change and I could've used a few more tests around to make sure we covered our bases.

Have someone else verify that everything works. Get your other co-founders to use it for a day or, if you have to, contact one of your power users and invite them to use the staging server. You need to have someone use it other than you before launching. There will inevitably be something that breaks caused by doing something you just hadn't thought of doing.

Branch, tag, then deploy. Don't deploy from trunk. Srsly. You're going to have issues if you do. Take this scenario: You spend a week coding up features for a new release. The day before the deploy there's a bug in the existing code that needs to be fixed immediately. In a rush, you submit a fix to a source file from your trunk enlistment on your machine and deploy it to production. Whoops! Now you have added code from features that haven't been released yet. Not only that, but you've only been using trunk, so you have to go back and back-merge all of your changes. I branch every release that will be deployed to production, and only deploy tags from that release. This makes it easy to roll back, and forces you to have separate code enlistments for each release of the code you're working on. It also forces you to be disciplined with your checkins since each production deploy requires a new tag. Here's a link to a discussion on how to add this functionality to your capistrano deploy configuration.

Don't push new bits at peak usage. Find a time, usually late at night (7-9PM PST is usually a good bet) when there aren't a huge number of users on your site. That way, if you need an outage (or worse - you have a big problem), it won't affect too many users.

If you do have a problem - don't panic! Users are grinding away on a gnarly bug on your production server? Oh well, you tried as hard as you could (presuming you followed the previous advice) to release smoothly. Your code is still "beta" after all. Put up an outage page and calmly debug and fix the problem. If you can't in a reasonable amount of time, roll back and fix it tomorrow. The worst thing to do is to panic and turn a small issue into a larger one (like accidentally dropping your DB for example).

That's all the advice I have for now. This week we'll be launching a new release of RescueTime with some nifty (and complex) new features. I'll let you know how it goes, and will amend this list accordingly. :)

End of Year Post

Wed, 26 Dec 2007 19:46:36 GMT

It's not quite the end of the year, but there's not much more I'll be doing before it arrives, so I might as well post now.

I usually dislike odd numbered years, but this was a good one! I've had a string of them lately, so it seems like maybe that's a silly perception that I have.

Here's what I did in 2007:

Got re-admitted to college, completed 3 courses to finish my degree, graduated with a BS in CS
Lost ~40 lbs and generally got back into good aerobic shape (resting heart rate < 60 bpm)
Advanced my career, worked under several great mentors, gained enormous amounts of experience in areas that had been lacking
Began, took a break from, and resumed work on fledgling startup company
Helped pitch and raise Y Combinator funding for said fledgling startup
Saved enough money to be able to self-fund myself while working on the new company next year
Re-injured my knee, had ACL surgery, rehabilitated it
Somehow managed to visit family and keep my wonderful wife reasonably happy through all the above

I still feel like I'm missing some things. This has been one of the busiest years I've ever had. I can't wait to see the payoff in 2008.

Yes

Tue, 25 Dec 2007 09:21:42 GMT

Is it Christmas?

Transistions! (Oh teh profundity)

Wed, 19 Dec 2007 19:23:44 GMT

On Saturday I finally accomplished the goal I set out to complete in October of 1996. In reality, it was a goal I set for myself when I was somewhere around 7 years old. I completed my BS in Computer Science. I'm glad I attended the commencement ceremony, it really put a period at the end of the 11 year trail I took to get here. I was even a minor celebrity at the event. So now I'm officially a scientist! I even get to include it on my corporate profile. Not having my degree was never something that got in my way, since I had taken almost all of my courses before I left school the first time. It really does feel like my career is more grounded now, though. It's somewhat hard to describe.

At the end of the year I'll be leaving my favorite company to work for (up until this point) - Jobster. I'll be cutting the strings to go full time and full speed ahead on RescueTime. I feel like I've learned so much in the last <2 years - enough that I'm ready to go at it for real this time. With Jobby, I was in a little over my head. Now, I'm extremely confident that I can help to start and run a company at this point in my career. RescueTime is already building up a lot of good traction and interest without any real market prodding. It speaks to the fact that people really seem to have the problems we're trying to help solve, and are very much in need of a good product to help them.

So, next year should be exciting! I'll be focused on only one thing (effort-wise) for the first time in years. While the road ahead will be very energy-consuming, I'll actually be less burdened than I have in a while, and it should go quite smoothly. 2007 was a year of learning, branching out, refactoring, and accomplishment. 2008 will hopefully be the beginning of a whole new phase in my life and career. Wow, does that sound sappy.

Final Math Grade

Sun, 02 Dec 2007 01:03:22 GMT

Midterm Exam: 100/100
Final Exam: 282/300
Midterm Average: (97.0)
Final Average: (94.20)
Course grade: A

So I guess I'm done with school.

Wed, 28 Nov 2007 06:24:52 GMT

Just finished my final exam in discrete math.

Earlier this week I finished my work for algorithms.

That's it, I guess. What a weird feeling.

Graduation is Dec 15th.

How busy is too busy?

Fri, 14 Sep 2007 17:19:19 GMT

I'm so busy that when you see me not doing work, I'm actually putting something else I should be doing off until later. I imagine I'll have a day where everything is due at once and I'll explode.

This is only until December, though. I can take it.

Started my first class this week

Wed, 22 Aug 2007 05:32:08 GMT

I just finished a bank of discrete math homework.

I actually am enjoying this! I certainly didn't enjoy it the last time around. I used to really really fear math - not so much the difficulty, just the complexity. There's something nice about this math, though, it's very much like solving puzzles, so far. Oh, and it's also like analyzing and arguing. I'm good at that. I suppose I'll get better after this course. :)

I also used to hate doing homework. I guess I'm not as sick of it anymore as I was when I started out in college 11 years ago. There's one thing that I learned quickly in college (and it's probably the most important thing for my brother who just entered college to remember - write this down, Aaron!). I'll even make use of what I just learned and put it in the form of a proposition:

Let p be the statement "You do your homework."
Let q be the statement "You do well in your courses."

p -> q

Which reads: "If you do your homework then you do well in your courses."

The truth value of this statement can be analyzed using the following 4 cases:
1) You do your homework and you do well in your courses. - This is true
2) You do your homework and you do not do well in your courses. This is false, This means that if you can provide an example of someone doing their homework and not doing well in their courses, chances are either p does not imply q (in which case I'm wrong), or you're just at a sucky school.
3) You do not do your homework and you do well in your courses. This is true, because p can still imply q, it's just that in this case you happened to get lucky, or already knew much of the material and didn't need to do your homework. I wouldn't rely on this, though. Case 1 is still your best bet, especially if it turns out that p <-> q.
4) You do not do your homework and do not do well in your courses. This is true. See, you should've done your homework.

I suppose I don't have as many distractions from homework this time around. I'm less inclined to watch a lot of TV or play a lot of video games these days. It probably just happens when you get older. I've also been listening to a lot of lecture podcasts lately, so maybe I'm just craving the experience of learning new things again. Either way, it's great. I'm much less stressed about the prospect of taking these last two classes now.

But make no mistake, I'll also be incredibly relieved when it's all over.

Nevermind: Facebook isn't evil

Wed, 15 Aug 2007 22:46:49 GMT

... at least in the way I previously described.

They just created a feature today where you can specify the owner of Facebook application API keys.

So much for my theory. :)

Facebook's (Evil?) Application Strategy

Wed, 08 Aug 2007 16:06:25 GMT

As many of the people who read this journal already know, I'm pretty active in several areas of Facebook application development - with a project I'm doing at my job (the Jobster app) and some projects I'm doing on my own for fun (Favorite Games and some others I haven't launched yet). During the time I've spent working in and around Facebook, both as a developer and as an observer of a full-fledged business partnership, I feel like I've gained quite a bit of insight into their operating practices and strategies. The jury is out about whether or not Facebook itself will break out of it's current classification as probably-just-another-social-network and launch into something entirely new (my gut says it will), but I feel like making a prediction about a new business model that the folks there will likely soon introduce. This article is mostly meant to be a brain dump for me more than anything else. I'm not a practiced market analyst or web prognosticator, I'm just exploring some ideas that have recently struck me as interesting.

Let me start off by saying that the Facebook application platform is quite slick. Whether or not you agree with the way it opens up the Facebook user base to a never ending stream of product shills and bandwagons and fads, you have to admit that it provides a very robust way to tap into an existing social network and build a user-powered product. The FBML and FQL APIs are nicely feature complete, decently documented (although the API tends to change often, with little warning), and have become reasonably stable and fast. Using 3rd party libraries, a developer can go from zero to fledgling Facebook application in just a few hours, and work toward building a feature set that could reach millions of users.

That last part is the interesting thing. Depending on who you ask, Facebook applications can be valued by the number of users who have them installed, up to $.30 per user for large applications, and maybe even lots more for particularly interesting ones who may have a smaller but growing audience. Over the past few weeks I've seen numerous posts on the Facebook Developer's message board offering applications for sale, and offers to buy. There have been an emergence of speculator companies like Slide who are buying up the biggest and most popular applications, and there are even individual entrepreneurs who are hiring developers and buying up batches of promising applications. I've even heard rumblings of VC firms and angel investors seeding bits of money into the space. It's pretty obvious that there is an emerging marketplace for Facebook users and applications that reach them.

There's a problem with all of this buying activity, though. One feature that is blatantly missing from the Facebook developer platform is the ability to transfer API keys for applications. Let me explain. An API key is given to a Facebook user when they first submit an application on Facebook. This key is then used throughout the application, tying Facebook users to the application when they choose to install it. Users of an application are bound to the API key they agree to accept when they install it, and API keys are bound to the developers who provision them. Therefore, if a Facebook application developer decides to sell his application, there's no way to transfer the API key to the purchaser of the app without losing all of the application's users.

To put it simply, API keys, and with them the users of the application, are non-transferrable. Since the value of the application is in its users, what must usually happen is the API key remains with the person who created it, and a contractual obligation is included in the sale that gives the purchaser access to the key through the originator's account. This is risky, though, because if that user deletes the API key (by accident or on purpose) all of the users of the application are lost, with no recourse by the company who buys the application. In essence, there's no good way to transfer the control of a Facebook app without losing its value.

Facebook's official stance on this seems to be that if a user sells an application, the purchaser should create a new API key and transfer the code, database, and user information collected into a new application of the same name. The problem with this is there's no guarantee that you will be able to regain all of your user base, since there's no way (other than them returning to your application's specific URL) to reach them to let them know that they need to accept a new API key and re-install it to continue to use the app (and thus get counted in the application's numbers). I can be said that they have a reasonable argument against this kind of thing predicated on the idea of protecting the privacy and user experience of their members; but that's a weak argument at best, especially in the case when a larger group can take over the application and provide more useful features. When you consider that along side of the fact that Facebook actively deletes accounts that are clearly not actual people, and explicitly does not allow companies to make corporate accounts, it really seems likely that they're planning on taking a piece of the action of the marketplace of applications they're creating.

I don't believe that the complexity of the process of transferring an API key is a preventative factor, either. There doesn't seem to be any serious security or architectural reasons I can think of that would make an API key transfer feature difficult. Facebook isn't a small organization engineering-wise. When I visited them early in the year I believe they had over 50 software developers - more than enough to undergo some pretty daunting architectural gymnastics.

What seems to make the most sense is that Facebook is probably working on creating a way to sell applications which requires a fee payout to Facebook (for an amount which would most likely be tied to the number of active users). This idea doesn't seem too big of a stretch when you consider the steps they've been taking to move toward a "web operating system," or a "google of people," as well as their own internal promotions encouraging developers to replace popular features of Facebook with their own applications. If successful, the value in having this kind of a marketplace would be quite significant, especially as the larger companies begin to dip their toes in the Facebook application space.

It'll be interesting to see how this plays out. You can find plenty of horror stories of developer accounts getting disabled for "misuse," completely orphaning the applications they've created, as well as their users. There's a specific way Facebook wants you to develop applications on their platform and they are unforgiving about it, to the point of account termination for non-compliance. It's worth the while of everyone who's interested in entering this space to read the terms of service and understand them fully. Facebook sometimes seems merciless about enforcing their policies. It's easy for them to hide behind their "just protecting our users" stance.

One thing's for sure, the folks at Facebook hold all the keys to this emerging marketplace. You can bet that they're going to find a way to monetize it, and keep it under their tight control. I just hope that they're not evil about it.

Exciting work update!

Wed, 08 Aug 2007 03:09:26 GMT

Here's the latest article about the new Jobster Facebook app I worked on.

There've been several articles lately, all of them with great things to say.

The application has over 42,000 users now. I'm getting to work on a new feature that will launch soon that brings back some of the spirit of Jobby, which should only increase our adoption numbers.

Here's hoping this Facebook thing takes off. ;) I should say, though, that I'm currently working on an article about some Facebook application fishiness I've been uncovering. I think it's interesting how they're positioning their application ownership. I don't think people quite understand the leverage Facebook has in this space. More on that soon.

EDIT: Here's the article I was talking about.