Regardless of the reason, I learned a lot from the experience of finally getting a lot of attention focused on something I had worked on.  Here’s the good and the bad of how I handled it, and also some financial results:

Results

• Upgrade of server to bigger plan on Linode: -$16
• Money from affiliate links on SFF: $0 (Really!  Experimenting to see if affiliate links would be a better way to make money was actually the original purpose of the site.)
• New customers for Bespoke Row: 5 (which was actually more orders, because some of them ordered a second time after getting their shirts)

Good

• Quickly responded to comments online – e.g. on Reddit where people thought I should make the connection to Bespoke Row more clear, so I changed the site in a few hours.
• Created a new channel to my main business – The visitors to Bespoke Row who came from SFF generally converted at a better rate than other visitors, which I think is because SF basically acts as a demonstration of why they need a custom shirt before they come over.  There are also now a lot more links to SFF than to Bespoke Row on the web, too, so I hope it will continue to work this way for a long time.
• Learned that affiliate links are also a hard way to make a living – The fact that I had thousands of people on my site and not a single affiliate sale pretty much answered my question about how many visitors would be needed to make money from affiliate links to clothing sites.

Bad

• No Analytics – I built the site so quickly that I didn’t even add in any analytics packages.  This is so easy to do, and I missed it.  Now I don’t even know how much traffic I actually got.
• No way for people to sign up for future news and updates – I have a feeling I lost a lot of potential sales here.  A lot of people visited the site, but I have no way to identify them or to follow up because I didn’t have a newsletter signup or a link to a Twitter account that people could follow, etc.  Even though part of the appeal of SFF was that you don’t need to sign up, you can just use it, some percentage of people would probably have wanted to leave feedback or hear about changes.  I will definitely remember this for any future projects.  I added a Twitter account pretty quickly, but all it could do was message people who had shared SFF or the LifeHacker link.  That’s a bit different than having a group of followers that would see any future tweets.
• No way for people to share – Traffic died off pretty quickly after about a week.  It was old news on LifeHacker, and people didn’t think to come back.  In combination with not having any way to remind them (see above), I also didn’t have any way for the current traffic to lead to more traffic.  In retrospect, SFF results would be great to share with family or friends right before people go shopping for Christmas gifts.  Even beyond that, just giving people the opportunity to tell their friends on Twitter and Facebook might have led to traffic that built over time instead of falling off.
• No way to grow the database – There are a lot of ways to get no results on Shirt Fit Finder – for example, if you’re taller than the tallest shirt we knew about, we don’t have anything to show you.  This happened to many people.  There were also a lot of people who didn’t own any of the shirts listed, so they couldn’t even search for something better.  A week later, I added a way for people to search with their own shirts and add different brands to the database, but it was a little too late.
• No way to know about the site going down during the day – I didn’t leave any way for people to wake me up during the night, and the notices from my host were all sent to my personal email so my partner in Boston didn’t even realize what was happening.  I fixed this by changing my linode account to be associated with a shared Bespoke Row email address instead.

Overall, though, Shirt Fit Finder was a huge success.  I will definitely be doing more side projects in the future to see what other ideas can gain traction.  They may or may not be related to Bespoke Row, but because I’m thinking quite a lot about the problems of choice and knowledge when making fashion decisions these days, they probably will be.

With those two requirements, I built ShirtFitFinder.com, which lets you search for brand name dress shirts that will fit you well based on what you don’t like about shirts that you already own.  We’ll see if people use it, and if so, I’ll give it some more attention.  At the very least, it was great practice for iWeekend this month.

For now, though, I’m done with the project; I only had a week, so now I’m back to my regularly scheduled Bespoke Row stuff – we’re launching custom pants soon!

For a while, I became fairly depressed, but eventually I realized that I was going to have to get over these feelings and go find some friends of my own or else I was going to go crazy.  I knew there must be a way, because every day I could see how easily my girlfriend was able to make new friends and very quickly start a meaningful relationship with them.

One of the big skills my girlfriend has that I lack is that she always knows who to call on any given day.  She instinctively knows how long to wait between contacts for friends vs. business contacts, and she can remember for whom it’s been too long.  I don’t know if my brain is just different from hers, but I find that requires a lot of effort.  If I haven’t seen someone for a long time, I’m probably less likely to think of hanging out with them, not more likely…

Luckily, I’m an analytical programmer, so I can use a computer to do this thinking for me.  I made myself a spreadsheet that keeps track of my contacts and calculates when the next that I should reach out to each of them is.  Every person can have their own period of time that I should wait, so if someone’s a good friend, I can remember them every three weeks, but if someone just needs an update every once in a while, I can send them an email every three months and be ok.  I now check this every week to see who I should get in touch with.  For example, this week, I need to email my friend Jason and see how he’s doing in Boston.

After using this for a while, I feel much more confident about getting more people in my network and not worrying that I’ll lose track of them.  I can safely say that I’ve made more new friends in the last month than in the first five months I was in Beijing.

I actually think this would be a fun web app to build.  Would anyone else be interested in getting an email every Monday that reminds you who you should be in touch with this week?  If there’s a positive response, I’ll take a few days and build an MVP for this and send everyone an invite.

1. Part of being programmer is constantly learning, and I wanted to evaluate python and the Google App Engine as a possible replacement for the PHP work I had already done.
2. I wanted to make my test app something real, though, so I needed a simple idea.
3. Beijing is a much dustier place than anywhere in the US – it can even be hazardous to breathe the air sometimes, and I was a bit worried about it when I first moved.
4. There was already a service on Twitter (@BeijingAir) that updates every hour with particulate matter and ozone statistics.
5. However, Twitter is blocked in China, so I can’t check it on my iPhone, plus Twitter is text-only, so there are no graphs.

By having Google’s servers request and cache the pollution data for me in the US, I figured I could create a database of historical pollution data, visualize it how I wanted, and access it on my iPhone because the data would now be served by a non-Twitter server.

So, I downloaded the Google development server, read up on Python, read about the Twitter API and put this together in a day or two.  Google’s toolchain made it quite easy to deploy the application.

It’s really pretty simple – in App Engine apps, you can create a process that will execute every X number of minutes/hours/days.  That meant I needed two pages for my app.  The first one would be a page that kicks off a process to access the latest updates from @BeijingAir, parse them, and store the data in Google’s DB.  The second is the home page, which accesses the data for the last 24 hours and displays it in a table, which then gets turned into a graph via javascript.  Every half hour, my script gets the latest twitter updates (throwing them away if they’re already in the DB) and that’s it.

If I ever get time to play around with it again, I’d like to make some cosmetic changes.  One would be to move the ‘About this page’ into the same fixed-width div as the pollution graphs.  That way, when I open it on my iPhone, the screen would automatically resize to fit the graphs perfectly.  Currently, I have to double click on them to get that behavior.

Secondly, I’d improve the graph display.  We really only need one graph, since the concentration and AQI for each pollutant are directly related.  Also, to make it more clear what range the graph is in, we should change its color (and the color of the description text) to match the colors defined on www.airnow.gov.  That would make it clear when one graph is going down and the other is going up that the one going down can still be a lot worse because it’s been bad for the entire day.

If you want, you can look at the code on github.com.  Feel free to send me any questions or code patches if you want to change anything.

It turns out that big part of my answer involves automating everything.  Part of my reasoning is that our team is very small now, so the more we automate, the more we can concentrate on just development.  Another part of my reasoning is that I’ve read a lot about continuous deployment lately and many of the principles like decreasing the time between developing a hypothesis and learning your answer make sense and can only be achieved through extensive automation.

To that end, I’ve decided that all the developers should have some common git hooks in their repositories that will do things like run tests, etc.  Moreover, since we’ll be spending a lot of time developing these hook scripts, I’d like them to be backed up and versioned as well – i.e. also in the repository.

Therefore, my first step was to create a folder in the repository called /git_hooks/ and symlink /.git/hooks -> /git_hooks/.  This way, any changes we make to the hooks will be automatically applied across all the developers’ machines.

However, this has a downside in that everyone’s hooks become the same and they are unable to add their own (I, for example, might like to add a spell checker to my commit comments, but that would be annoying if someone didn’t like it).  To solve that problem, I created a /git_hooks/personal/ directory which behaves just like the normal /.git/hooks/ directory, and any hooks a developer adds in there get executed as part of the common hook.  Here’s the code I used as the base of all of our common hooks to make it work:

#!/bin/sh

# Check if the individual developer has his own hook
CMD_NAME=`basename $0`
if [ -f $GIT_DIR/hooks/personal/$CMD_NAME ]
then
  # If so, run it. $@ passes all the command line arguments passed to this function
  # If the personal hook fails, fail this one as well
  if ! $GIT_DIR/hooks/personal/$CMD_NAME $@
  then
    echo "User hook '$CMD_NAME' failed"
    exit 1
  fi
fi

exit 0

Finally, if any developer does decide to add their own hooks in /git_hooks/personal/, they should be sure to add a line containing “/git_hooks/personal/*[^.sample]” to the end of their /.git/info/exclude file so that git will ignore their customizations.

You can download this at http://gist.github.com/357538.

I started out trying interface builder and got a basic interface to show up pretty quickly, but it was rather confusing and I didn’t really know what was going on.  Next, I thought I should probably just go through the tutorials in my book (iPhone SDK Application Development by O’Reilly) so that I could get an overview of what’s actually possible with the iPhone.  That way, when I restart building my own apps it will be much faster because I’ll know what I’m doing.

However, I’ve now been trying to get the TextView example in Chapter 3 (Hello World) to work for almost a week!  I typed in all the code correctly (twice, into two separate projects), and it compiles fine, but all I get on the iPhone simulator is a black screen!  After a while, I found the debugger console button in XCode and realized I was getting the following errors:

warning: Unable to read symbols for “/System/Library/Frameworks/UIKit.framework/UIKit” (file not found).
warning: Unable to read symbols from “UIKit” (not yet mapped into memory).
warning: Unable to read symbols for “/System/Library/Frameworks/CoreGraphics.framework/CoreGraphics” (file not found).
warning: Unable to read symbols from “CoreGraphics” (not yet mapped into memory).

These frameworks are quite obviously linked in XCode (because the code completion works and the project compiles fine), but for some reason they don’t show up in the simulator.  After searching online, I’ve gotten to the point where I think it has to do with the way they’re referenced in XCode and that when running on the simulator, the application doesn’t actually compile all the references together; it just starts running without them, so you have to run it from within XCode.   Some people have also said that it had to do with breakpoints in code.  However, I’m running from within XCode and I don’t have any breakpoints, so I think it must be a file location configuration issue.  Now, I’ve had no luck finding any solutions online or by experimenting…

I’ll let you know how it works out; I’m not going to give up on this.

—- Update – March 1, 2009 —-

Well, the Hello World example started working… First thing to note is that the “file not found” type warnings I noted above don’t actually seem to be related to the problem; now that it works, they still show up.

I fixed the blank black screen by cleaning all targets (in the Build menu), then rewriting Hello World to directly use a TextView instead of manually subclassing UIView myself. Also, I didn’t allocate a window object; I just started using it and let the synthesize keyword work for me (before, I was trying to remove Interface Builder from the project, like it recommended in the book. Here’s the code that first worked (I called the project “Arg” because I was so frustrated):

ArgAppDelegate.h:

#import

@end


ArgAppDelegate.m:

#import
#import
#import
#import "ArgAppDelegate.h"

- (void)dealloc {
[window release];
[super dealloc];
}
@end


This compiled fine and the text view showed up correctly, etc. Next, I slowly changed the code one line at a time back to the original code, compiling at each step, to see if I could find the line that was causing the problem. Unfortunately, I eventually came back to the original code and it worked…

ArgAppDelegate.h:

#import

@end


ArgAppDelegate.m:


#import
#import
#import
#import "ArgAppDelegate.h"

- (void)dealloc {
[myMainView release];
[window release];
[super dealloc];
}


main.m:


#import

NSAutoreleasePool * pool = [[NSAutoreleasePool alloc] init];
int retVal = UIApplicationMain(argc, argv, nil, @"ArgAppDelegate");
[pool release];
return retVal;
}


I hope this helps somewhat to anyone having the same problem. I found this incredibly frustrating and am not entirely happy about my solution here. I still don’t really know why it happened in the first place, so I’m worried it will come up again in the future. Let’s hope not!

As I thought about the problem, I realized that salsa dancing (and most partner dances) is really a finite-state machine. We have X number of states (the positions that you end up in on beat 1), and transitions between the states (twirls, etc.). Naturally, I thought of creating a diagram with states and transitions and tracing paths through the diagram to come up with new sequences. This way, if I could memorize a few positions and all the different transitions between them, I could come up with lots of sequences on my own without ever having to memorize a two-minute series of steps. Each set of steps would be at most 8 or 16 beats long.

Still, I didn’t know exactly what to call each state, what precisely is considered a transition, or most importantly, how to present this information in a usable manner. Last week, I was again thinking about this and realized that since a finite-state diagram is also a directed graph, and the web is a directed graph, a webpage made perfect sense for a presentation mechanism. Moreover, if I used a wiki, I could start adding pieces very easily, even if I don’t know the best terminology or have the perfect definition of each state. Plus, other people can add their own moves to the wiki and eventually, we can all learn from each other.

Thus, yesterday morning, I started a new website: salsa.wikidot.com. So far it’s not much; I have a few positions and moves described, and I plan to add more. I feel a little bit like I shouldn’t actually be the one adding content, since I’m so new at dancing and don’t really know how to describe everything. However, I also think that a lot of times we just need to start doing something even if we don’t know how, so there it is. I have it set up so that it will be easy to add photos and videos of the steps if I ever get that far. Should be fun. Hopefully this helps someone someday.

My project ended up being some work in story-analysis using common sense (provided by ConceptNet, another Media Lab project) as well as trying a new approach to anaphora resolution (basically determining antecedents for pronouns), which didn’t rely so much on common sense.

If you’re really interested, you can download the paper I wrote. I also am planning on releasing the source code to my project by the end of the month, though I want to get through my linear-algebra final first before I clean it up and put it on a webpage somewhere.