Introducing BreakStreak

I’d like to introduce my newest project: BreakStreak.  BreakStreak helps you get into a routine.  It does this in a few key ways:

  1. You sign up to perform a routine, say cooking or working out, along with a specified number per week.  Every time you accomplish your goal, progress gets added to your “streak.”  Eventually your streak will get so long that you won’t ever want to break it and start over.
  2. You can create incentives for keeping your streak — although incentives are optional.  For example, if you break your streak, you can have a SMS and/or email be sent to friends.  You won’t break the streak if you know your friends will find out.  You can also donate $1 to charity for each activity you don’t perform for a given routine.  30% of that $1 is kept by BreakStreak to help operate the website.  Again, these incentives are optional.

I built BreakStreak because there are so many things I wish I spent more time doing, in particular cooking and meditating.  And many of my friends have the same problem, too.  BreakStreak is designed to help us set a goal and stick to it.  My hope is that BreakStreak can be a common and useful tool for helping each of us hack our lives better, with the sole goal of making us happier and more proud of our accomplishments.  A friend of mine, Brian, has helped me with much of the brainstorming and product ideas.

Give it a try at breakstreak.com!  And let me know if you have any thoughts or feedback.

Introducing CriticallyIn

I’ve begun building a bunch of prototypes for ideas I have had over the last few years, each an experiment to see if my ideas have legs.  My goal is to turn one of these ideas into a business as soon as one is validated.  I’d like to tell you about the first of these experiments, CriticallyIn.

CriticallyIn let’s you create an event that requires a minimum RSVP in order for the event to take place.  There is a certain class of event that needs to hit critical mass in order for the experience to be enjoyable (think flash mobs, silent dance parties, protests, etc).  CriticallyIn was built to help plan and organize those such events.

I’m using CriticallyIn to plan my Bay to Breakers MC Hammer theme, along with gauge interest for a faux cycling celebration flash mob idea I have.

I’m not going to promote CriticallyIn that heavily, because at this point I’m solely interested in running an experiment and learning from the early users of the product.  If you plan an event or attend one, please let me know if you have any feedback or thoughts.  And while I’m here, feel free to fill out a survey for me here :).  Enjoy!

Map Your Facebook Friends

I created a little site that maps Facebook friends.  It’s called Shibby (shibby.us), and it uses the Facebook Python SDK, a Python geocoding library, the Google Maps API, and Django.  Take a look at my graph:

I have a few ideas to make this thing more engaging and more interesting, but for now I plan to leave Shibby as is.  Let me know if you’d like to see other visualizations/features.  Otherwise, enjoy :).

My Google, Shanghai: Explained

I’ve talked a little about being in China, but I haven’t said much about why. Up until only recently my duties at Google were unclear, but now I understand my purpose: Christophe dragged me over here to contribute to Hadoop, an open-source MapReduce implementation.

Hadoop is essentially a tool used by software engineers to write programs that use large amounts of computers to process vast amounts of data. Cloud computing is the new buzz word, but Google revolutionized large-scale computing, or distributed-computing, many years ago. Historically, lots of data (like that of the internet) was analyzed by large, expensive computers. In fact, historically, lots of data just flat out wasn’t analyzed. Now, in the wake of MapReduce, Hadoop puts hundreds or even thousands of commodity computers to work to analyze data. Cloud computing is one of the reasons why Google is the best search engine, and industries all over are benefiting from the cloud. Cancer researchers are able to more efficiently understand their data. Astronomers can crunch their images much faster. Hadoop allows any company to effectively understand large amounts of data.

It’s not yet clear exactly how I’ll be contributing to Hadoop; those details should surface soon. I admit that Hadoop is my first open-source project, and I’m very, very excited to be contributing to a field that is growing so rapidly. More updates to come!

Bonus story: after slaving away for four days, I finally have Hadoop’s trunk build running on a multi-node cluster. Boom shakalaka!

A Second Look at Software Engineering a Startup

I wrote a post a while back about software engineering a startup, and Clint‘s comment made me realize that my post was poorly thought out and just plain bad.  I argued that the quality of code you write should be related to the type of financial situation you’re in.  For example, if you’re a funded startup, then you should be writing good, maintainable code.  However, if you’re not funded or if you’re doing a personal project, then you should code quickly to get features out the door.  I want to revise my argument.

I’ve now worked on two pretty large personal projects: Cellarspot and Best Seattle Bars.  Cellarspot was developed in JSP, and the code we wrote was totally maintainable and robust.  On the other hand, Best Seattle Bars was developed in PHP, and the code I wrote was all inline.  The following analysis may be obvious, but I’ll make it anyway:

Robust, Maintainable Code
Advantages: Maintainable, easily refactorable, and expandable
Disadvantages: Generally requires more work, thought, and usually a more advanced development environment

Inline Code
Advantages: Requires less work, less thought, and a much less sophisticated development enrivonment
Disadvantages: Not maintainable, not easily refactorable, and not expandable

So when should you write fast, inline code, and when should you write good, robust code?  Inline code is great when you want to prototype something.  It allows you to quickly launch a set of features so you can evaluate your idea.  Robust, maintainable code is basically great for all other cases.  Now let’s examine three cases:

You write inline code and your idea blows up
Your idea takes flight and before you know it you have tons of users, tons of peers programming with you, and your users want more features and better reliability.  Chances are good that you’ll have to recode your entire web app, and that’s going to be a HUGE upfront cost that perhaps is more costly than writing good code to begin with.

You write good, maintainable, robust code, and your idea flops
First, let me just say that I feel your pain. One might think that this case is a total waste of time, but I’ll argue the contrary. I learned an insane amount by going through the process of writing good code, and it would be a good practice for me to do it again. The value one gains by going through this process is huge – it can help you get jobs (it did for me at least), and it keeps you sharp.

You use Ruby on Rails or some similar framework
Frameworks such as Ruby on Rails and Django let you write good, maintainable code very, very quickly.  They let you avoid the above two cases completely, because you won’t waste your time on a flopped idea and you won’t find yourself scrambling for dear life if your idea blows up.

My conslusion is the following: write good, maintainable code, and choose a framework that makes it easy for you to do so.  You’ll avoid the upfront costs of writing good code, and you’ll avoid the posiblity of large refactoring down the road.

Google’s Earth Day

It appears as though Google has beaten me to the punch again.  A few months back I wanted to create a user-driven, Q&A-style search engine.  Two days after I got my idea and started coding I learned that Google had done this in Google Labs and that Mahalo was already doing this.  Dang.

Another recent idea I had was to create an index of non-profit organizations in hopes of allowing people to become more aware of the organizations that are out there.  Google just announced that as well.  I suppose it’s better Google than me – they have huge traffic and will most likely generate a lot of donations.  If my non-profit index would follow suit with all of my other websites such as Helpd, which has somewhat of a similar goal, then the non-profits would get little to no donations.  Go take a look at what Google is doing, and donate if you want.  It’ll probably help out :).  I donated to Acterra.

More Best Seattle Bars Improvements

In my quest to learn more about JavaScript, I launched another iteration of Best Seattle Bars that includes:

  • Searching (searches the name, the description, and all reviews)
  • Adding of new bars by the user
  • More user profile fields (name, email, phone)
  • Framework for SMS and email announcements
  • Promotion integration (BSB is participating in the Fremont Troll Stroll to benefit Cystic Fibrosis)

Next up is probably photo adding and possibly a few others.  Any suggestions?  Hope you enjoy!

Best Seattle Bars Improvements

Best Seattle Bars is so far the most successful website that I’ve ever launched. The guy with the idea, Kyle Trew, loves to hit the bars, and he promotes the site almost every chance he gets. Almost half of our traffic is direct traffic, which implies that his promotions are definitely working. Anyway, I launched a new version of the site just a few minutes ago. I’ve been working on this new version for about two weeks, and it’s worlds better than the previous version. Here’s a feature list:

  • Improved map user experience
  • User registration
  • 5-star ratings
  • Improved bar landing pages
  • Driving directions

I’ve already started working on the next version, which should again be a huge improvement.

Go take a look and let me know if you have any suggestions. Enjoy!

Networks Project: Radical

My friend, Robert, and I finished our big networks project about 2 weeks ago, and I just wanted to share the project. We were given Nokia N800s and told to write a P2P file sharing application in C. Awesome.

Phase 1: The Basics
We follow the specified protocol and write a program that lets N800s request lists of files and also request files from their neighbors. Neighbors are discovered by UDP broadcast packets that are sent every few seconds. All other communication – file list and file requests – are done over TCP. I’m leaving a lot of detail out such as port selection and protocol details, but the project was relatively simple and fun – lots of buffer/network code.

Phase 2: Routing
We build off of phase 1 and implement a link state routing mechanism. We also use Dijkstra’s algorithm to compute the shortest path between all nodes. We build a ping and ping reply feature to test our routing. Link state packets and ping packets are sent via UDP. This part of the project was long, hard, and awesome – tons of fun data structure/algorithm code.

Phase 3: Enhancements to Phase 1
We build a file search and request mechanism so N800s can ask their neighbors for a particular file instead of first viewing a list and then downloading. Neighbors queue requests that they can’t fulfill and send these queued requests to their neighbors. Files are downloaded automatically when a request is fulfilled. I can’t remember what network transport layer is used, but I’m pretty sure file requests and downloads were both sent over TCP. Again, a really fun phase.

Conclusions
This project was awesome. Robert and I probably spent at least 100 hours each in the labs, and we enjoyed most of it. The biggest pains were cross-compiling and running on the N800s and odd GCC behavior. If you’re a UW CSE student and plan to take networks (CSE 461), then try and take it with Arvind Krishnamurthy. Robert and I both have a few complaints about the class, but the project was tons of fun. We ended up writing around 4,000 lines of C code from scratch, including a generic hash map, list, set, and many-to-many table. Great project. I wanted to post the source code, but then I realized that I probably shouldn’t ;).

Looking for a Content Management System?

I just made a post on the Redfin Developers’ Blog talking about my 6-month-long effort to choose and implement Bricolage, an open-source content management system (CMS).  This is post one of two; the second post, written by Jason, discusses implementation specifics and will be published shortly.  Take a look at my post here if you’re interested.