As I mentioned previously I’ve been involved in the Winter 2009 semester of the Founder’s Institute in NYC. I thought I’d write a little bit about what I’ve learned to help others get the most out of the experience. Some of these are practical, some of these are just things to keep in mind as you progress through the semester. In no particular order….

• You’ll get the most out of it if you have an idea of what you want to do before you start. To its credit, the Institute will accept you if you don’t have an idea, but to some degree I think this is giving people just enough rope to hang themselves given the aggressive nature of the curriculum. The fact of the matter is that those of us who got the most out of the Founder’s Institute came in already pretty much knowing what we wanted to do and spent a lot of time tuning and focusing it. Yes, the first couple of sessions will be about how to develop an idea, how to research the opportunity, etc. I found the information to be very useful, but more in a “good to know for next time” way. It’s really hard to keep up with the later sessions if you spend the first 3 or 4 weeks vetting 5 different ideas.
• Therefore, getting in is about you as a founder, not your idea. But staying in is about how well you execute on your idea. Don’t forget that you are expected to have an incorporated company with a real business model and a real plan for success at the end of this. It’s not as easy as it looks.
• Actively seek out those who will challenge your assumptions sooner rather than later. It took me a while to realize that those who didn’t want to talk about their idea (including myself) were doing so because they didn’t want to hear the hard truth about what someone else thought. I know it’s not easy to hear. We’ve all convinced ourselves that whatever we’re thinking of doing can’t possibly fail and that anyone who doesn’t see it that way is wasting our time. That’s expected. But keeping it to yourself doesn’t prove anything. You join this program because you want your idea to succeed.
• Sign up for office hours. It’s free advice from people who have done this before and want to help you succeed. If you’re serious about building a business there’s no excuse for passing that opportunity up.
• Keep an open mind at all times. That pain you feel when someone criticizes your idea – that’s called growth. No one’s going to plunk down a bag of cash for a clever idea. At times someone “just won’t get it”. When that happens you can either find a way to convince them or become defiant and disengage. You can probably guess which one will work in your favor long term. Take the feedback (good and bad) and get better.
• That being said, know when to take advice and when to leave it. It’s your company. Don’t ever forget that. It was your company before the Founder’s Institute. It will be your company after the Founder’s Institute. If something really matters to you, stand your ground. Realize that you may still be wrong, but at least you learned something valuable.
• Volunteer to be president of your working group. People act like being the president of the group is like getting the plague or something. It’s not that bad. For the most part you’re just organizing meetings and taking notes. Yes, there are some founders who can’t keep up and you have to find a way to motivate them. It can be time consuming in a lot of ways, but it’s good practice and there are a number of upsides that come with the role. I was president for the 2nd and 3rd groups and found it to be valuable.
• Time is short, be ready to work. Kinda goes without saying. There’s not a lot of time in the program and a lot to do. If you’re going to do this right it’ll need to be a priority in your life for 3 or 4 months. Make sure your spouse or significant other understands this as well.
• Network, network, network. Get to know the other founders. Go out for drinks after each session. Find out about their business. Tell them about yours. Organize on LinkedIn. Connect with mentors where appropriate. These people have a stake in making sure you’re successful and you have a stake in making sure they’re successful. A little extra effort will pay off for everyone.
• The working groups can make or break your experience. A good working group can help you in more ways than you expect. A bad working group can really tax your energy. If things aren’t going well in your group, talk to your president. If he or she doesn’t listen talk to your local facilitator. Don’t let it slide. It’s up to you to get as much value as you can out of the experience, and every week counts.
• The mentors are great but aren’t everything. I came in expecting a one-on-one mentorship. It was a bit naive. The mentors are both successful and busy. They are all nice, and all helpful, but don’t expect too much. Honestly I don’t think I connected on a personal level with any of them. Part of it is that none of them really know my space very well, and I can’t really blame them that for that. It might speak more about my company than I want to think about.

Feel free to ask questions in the comments. If appropriate I will contact you directly via the email address you supply. As I’m still participating in the Founder’s Institute I’ve tried to avoid any conclusive statements. There’s still a lot of time left in this semester and a lot has changed even since my last post.

We recently bought my mother a digital photo frame for her birthday. The product itself was really nice – connect via USB, WiFi, flash cards, etc. Shows pictures, plays movies, plays music. Perfect gift for a tech-savvy mom who has a growing family.

But the real star of the show was actually Picasa. If you don’t know, recent versions of Picasa will actually scan faces in your photos and present them to you so you can provide names. It does the hard work, and you can coach it along by accepting its suggestions or providing a correction. It then indexes your images so that you can find all images with Aunt Sally, or all images with your brother *and* Aunt Sally.

With this it became trivial to preload my mom’s digital photo frame with family photos. Go through the index for reach family member and copy over some memorable shots. Easy and amazing.

I know it’s not new, and I know Google didn’t do it alone, but this seems to me to be a major milestone for the digital era. Wheels were important, and a lot of things can be done with a wheel, but history truly took a turn when someone strapped a motor to 4 of them and made a car. I feel the same way about digital cameras now. Important, but the dawn of facial recognition on the desktop makes this something else. I can only imagine what comes next. I’m sure someone out there has been spending a lot of time on exactly that. I can’t wait to see it.

For the past month I’ve been involved in the Founder’s Institute NYC Winter 2009 program. The program’s aim is to train founders in the art of building a business so they can avoid common missteps and give them a better shot at being successful. There are about 40 founders in the NY session, representing a good cross section of industries and skill sets.

I haven’t written much about it yet because I wasn’t sure what to say. The process of applying and getting accepted was incredibly condensed and emotional (read: delusions of grandeur). As those hopes and dreams slowly adjust back to reality I’m seeing both the good and the bad. It’s mostly good, but not entirely. One thing I struggled with going in was what I expected to get out of it. I spoke to other founders informally about that question and the answers varied widely. My initial impression was that no one really new what to expect. That can be both a challenge and and opportunity.

I’m reserving final word for later – there’s a long time to go and many things could change – but so far I think the experience has been helpful in a number of ways, both intended and unintended. One of the first things Adeo Ressi said was that Founder’s Institute is not going to make or break my business. It will give me some tools that will help, but it’s still up to me. I think that’s very valuable advice and something I have to keep in mind as I go through process.

I’d been using Google Apps for receiving emails sent to my domain up until an hour ago. As I’ve mentioned before, I’m running my app on Slicehost, and as usual they had some great instructions for using Google Apps for your email needs.

That was working kinda ok but there were a couple of things that annoy me about that solution. First is that I just don’t want Google involved in every single thing I do online. I generally trust them, but there are some things I don’t want to use them for, namely anything to do with my business (I don’t use Google Analytics either). The second is that I think it’s highway robbery to pay $50 per user per year for the premier account. I only need 2 right now, but down the line I might need more. I didn’t relish the thought of giving them $300 or $400 a year to provide a beefed up version of their free tools.

So today I discovered that Rackspace has an email hosting solution as well. And if you’re a Slicehost customer and need 3 or fewer inboxes (that me!) it’s only $3/month. The normal starter package’s price is $10/month for up to 10 inboxes, which is still totally reasonable. So in less than an hour I converted from Google Apps to Rackspace Email Hosting. And of course they have the usual helpful configuration instructions to get you started.

I have a couple of concerns that I’ll follow up on in future posts. The first is that according to the representative I chatted with there’s a limit of about 200 outgoing emails per hour. I think that’s going to be ok for my app, but I guess I’ll see. The other is that I’m pretty useless with mail configuration things and I’m a little nervous about how much effort will be involved in connecting my local postfix to their smtp server for outgoing email. I’m sure I’ll figure that out eventually though.

In any case, for $3/month, moving back to Google won’t be a huge issue if it should come to that. Hopefully it won’t. I’ve already gotten a few small tastes of the fanatical support from Rackspace and I have to say it’s pretty nice so far.

A lot of developer cycles are spent discussing the benefits of YAGNI and KISS. On the surface it would seem that there is an army of righteous developers fighting against the demons of over-engineering and maximum complexity. And despite our valiant battles, despite all the books and blog posts and rallying calls from respected technology professionals, the demons are still churning out bloated, impossible to maintain code.

I’ll let you in on a little secret. We are the enemy. Not just the guy who sits next to you, or the guy that churned out mess of code and then left the company. You are the problem. I am the problem. The enemy is us.

Yes, we can all agree in principle that complexity is bad and simplicity is good. The problem is that complexity is completely subjective. Maybe you misjudge or were misinformed about how likely it is that a certain feature will be needed. Maybe you thought of some brilliant solution and you want to leave it as a placeholder in case you need to come back to it later (or so others can see how clever you are). Maybe you don’t want to do it the cheap way because you’re afraid others will snicker at your solution. Maybe you’re afraid a simple solution will lead to longer development times later on. Maybe your definition of simplicity is skewed. Whatever the case, no one sets out to over-complicate a piece of code. And yet it happens time and time again.

There are rules of thumb that can be followed. But what it boils down to is always discipline. It’s not easy to simplify. It sometimes feels wrong. But I’ve never looked at working code and cursed because it was too simple. I’m not even sure it’s possible for working code to be too simple. But it sure as hell easy for it to be too complex.

So why is over-engineering is like snoring? Because no one thinks they do it. And yet somehow there is a market for snoring relief aides.

In my first post about SSL integration on my site, I discussed how I came to a decision about a certificate issuer. I chose DigiCert, and have been very happy with them. One great bonus was their extensive list of instructions for setting up the certs on almost any web server known to man. So even though Part II of this series was intended to be about installation, I think DigiCert has that covered. Their instructions for nginx were spot on, so I wouldn’t be able to add anything meaningful to them anyway.

But buying and installing the certificate is a little different than using it. This post will focus on how I integrated the certificate into the site and what additional nginx configuration I had to make to support that strategy.

After kicking it around for a while I realized I really have 2 options. I can either convert the entire site to use https or convert as few pages as possible (e.g. just the login and register pages). The argument for a limited use of https is that all else being equal, the web server will require a little more CPU to encrypt/decrypt the https traffic. This is apparently an issue particularly with nginx as even the creator has said it can drag down performance for high-traffic sites. Since I’m not expecting Amazon-level traffic, this wasn’t as big a deal to me.

Another argument for limiting the use of https is that some low-cost CDNs, such as Amazon CouldFront, don’t support https traffic. This was a concern for me. I will eventually want to move my images, screencasts, stylesheets, and JS files to a CDN, so the fewer https pages I have the less of an issue this would be.

Related to this, some posts I read claimed that browsers will refuse to cache images, CSS, and scripts if they came across https. In my testing with Charles in Firefox and IE on Windows I did not experience that. In other words, any files that could be cached by the brower were cached. Yes, it was a limited test, but it covers a lot of the target base of my app. I believe either this used to be the case and no longer is or it’s one of those old wive’s tales that people just assume is the case but have never really taken the time to test.

I saw a couple of benefits for using https for the whole site. The first was that it simplified my application architecture. For instance, say you have a login page that’s intended to be served over https but it includes a common header image that’s present on all pages. That image has to also be served over https on the login page or the user will get a popup warning message that the page contains both secure and insecure content. That message is at least annoying if not scary to some users, so it’s best to avoid it by ensuring that the image is served up via https. But that means you may have a situation where you have 2 copies of that image so that it can be served up by both https and http. Or your configuration might become more complex in order to support 2 virtual servers pointing at the same image file on disk. Either way it’s a complicating factor that I wasn’t thrilled about wasting time on. If the entire site is served over https this issue goes away.

Secondly, it would be easier to configure than having only some pages be served via https. For instance, let’s say the login page is https. If someone asks for that page via http, the server should be nice and redirect them to https. But for almost all other pages it should allow regular http requests to process normally. These exceptions are easy to handle for one or two pages, but for more than a couple that quickly becomes difficult to manage effectively.

Lastly, my application is targeted at kids in the 10 to 15 years old range. For me, the more security the better. As with any site that relies on cookies to identify logged in users, it’s theoretically possible to hijack someone’s session via the cookie value, and if that were to happen it would lead to some seriously bad press for me. Again, if the entire site is accessed over https this issue goes away.

So as you can probably guess, I decided to serve the entire site over https. The big question I haven’t answered here is what effects this had on performance. I’ll discuss that the final installment in this series. But for those also using nginx, below is an excerpt of the config changes I made to support this. It should be self-explanatory, but leave me a comment if you need any help through it.

# non-secure site - send all requests to https
server {

        server_name www.mysite.com mysite.com;
        listen 80;

        location / {
           rewrite ^/(.*)$ https://www.mysite.com/$1 permanent;
        }
}

# secure site
server {

        server_name www.mysite.com mysite.com;

        listen 443;
        ssl on;
        ssl_certificate /path/to/pem/file;
        ssl_certificate_key /path/to/key/file;
        .....
}

One of the things I love about being a software developer is the fractal nature of our work. When we design a system we are almost always taking some piece of the universe and attempting to deconstruct it and model it so that it can run inside a computer. Examples of good (or bad) design are all around us, and our work demands that we draw on these examples to create a working piece of software. And software itself is nothing more than a bunch of bits and registers and some electricity that’s pretending to be more than the sum of its parts.

So I found myself reading Coders at Work on the 8:06 train the other day. I don’t usually catch the 8:06. The 8:06 is a double-decker train. And watching the conductor come through to collect our tickets I realized he represented a real-world example of a mutex.

This day there was only 1 conductor for both levels of the double-decker. It dawned on me that it would be very easy for someone to avoid having to pay by hanging out in the upper level and waiting for the conductor to collect the tickets from the lower level, then sneaking down to the lower level while the conductor moves to the upper level.

The lone conductor represented a flawed algorithm. There was no lock on the resource (exit door = I/O stream?). Adding another conductor could solve the leakage problem and lock the resource. But that would limit (or serialize) the free flow of passengers to and from the car.

I could probably go on exaggerating this example for while but I think you probably get the point.

Anyone have the first clue as to why Facebook’s developer documentation sucks so hard?

I was developing a simple Facebook application for one of my company’s clients that required me to update a user’s status via a scheduled background process. The developer documentation lead me down all kinds of paths by referencing infinite session keys and the “keep me logged in” check box. So I scoured the internets for some examples, only to find that there aren’t many. All these claims that bajillions of people are creating Facebook apps and not a single one of them that are updating a user’s status offline can document it? ARRRGGG!

So, here is what I hope will save someone else a ton of time – a real life, working code sample for updating a user’s Facebook status offline. Careful – make no sudden moves or you might scare this rare beast back into hiding.

Our app is requesting two extended permissions – “offline_access” and “status_update”. This is also using Elliot Haughin’s Facebook plugin for CodeIgniter. Elliot’s package includes an older version of the Facebook PHP Library, so I had to grab the latest version from Facebook and drop it in place. Other than that it was easy to integrate this into my app.

//http://wiki.developers.facebook.com/index.php/Users.hasAppPermission
//must be one of:
//   email, read_stream, publish_stream, offline_access, status_update, photo_upload,
//   create_event, rsvp_event, sms, video_upload, create_note, share_item
if( $this->facebook_connect->client->users_hasAppPermission("offline_access", $fbUID) &&
    $this->facebook_connect->client->users_hasAppPermission("status_update", $fbUID) ){
    $this->facebook_connect->client->users_setStatus("some status message", $fbUID);
}

Seriously, that’s it! All those posts, all that searching – for 3 lines of code! The key point that was conveniently left out of other articles is that there is no “session key” required now. Facebook is smart enough to know that the user granted the app permission for offline_access and status_update, so you only need to send the user’s Facebook ID. Moley.

Another annoyance. They make a big deal out of the fact that they provide a REST-ful interface, but none of the examples in their documentation show the format of the REST request (although they do at least provide the REST server URL and a handy hint to include the “Content-Type: application/x-www-form-urlencoded” header). Yes, I get it, you want me to use the PHP Library, which is nicely designed. But for quick and dirty testing I like to whip up some curl commands. If I don’t know how to format the XML I can’t easily do that. Bah!

I’m amazed at the amount of code that I see that contains uninitialized variables. I can’t think of a bigger bang-for-the-buck habit you can fall into than taking an extra 2 seconds to properly initialize whatever variable you’ve created. Look, I know a lot of ORM layers use NULL variables as a flag to insert/select/update null values. I get it. I don’t love it, but I get it. Other than that, I can’t think of a single reason to not initialize your variables. Unless you love NullPointerExceptions, or security exploits, or constantly having to check for null before you call a method on an object you just got back, or who know whatever else people have done to themselves because they were to lazy to add ” = 0;” after their variable declarations. Coding is hard enough as it is. This just makes it harder.

In an earlier post I referred to the tendency of a site’s home page to speak volumes about the character and and principles. I call this Psychotic Home Pager Design Syndrome. There are a couple of great examples of this, but the ones that stand out best to me are sites like GoDaddy.com, ESPN.com, and MLB.com. Imagine you are someone coming to the home page of one of those sites looking for a very specific product. Imagine trying to find that product in the mess of boxes and links and images and ads. It’s impossible.

One might argue that these companies have tons of products, and the home page reflects the need to have their most successful products featured and touted. Exactly. Having worked at MLB.com, I can tell you exactly how this happens. You have 2 distinct business units with shiny products that represent some business interest. You have 2 product managers who equate sales of their product with the size of their year end bonus. You have endless campaigning to have your product featured on the home page, where it will get the most traffic. You have exactly 1 CEO who doesn’t really want to have the product managers draw short straws because, afterall, it’s just pixels on a page. So the end result is a mish-mash of products and services that speaks more to the internal structure of the company than to usability.

Contrast this to a company that gets a lot of fanboys/good press – 37Signals. I won’t go into details here about my thoughts on the 37Signals hype (that should tell you enough), but for a company with a good smattering of products their home page is simple and usable. In the context of what we know of the internals of their company, this makes a ton of sense.