• 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 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 Institute. It will be your company after the Founder 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 many 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 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.

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.

Translation: Can you pretend to understand the unknowable well enough to pull a random but superficially believable number out of your ass which I will crucify you with later on if it turns out that whatever I did to prepare was insufficient and/or people generally believe that the failure was my fault.

# Stop Image and Document Hijacking
# Also have to handle these file types for piwik before they get processed by PHP below
location ~* (\.jpg|\.png|\.css|\.gif|\.jpeg|\.js|\.swf)$ {

   if ($http_referer ~* ^(http://my.domain.com) ) {
      expires max;
      break;
   }

   return 444;

}

location / {

   root   /home/public_html/my.domain.com/public/;
   index  index.php index.html;

   # this serves static files that exist without running other rewrite tests
   if (-f $request_filename) {
      expires max;
      break;
   }

   fastcgi_pass 127.0.0.1:9000;
   fastcgi_index index.php;
   include /usr/local/nginx/conf/fastcgi_params;
   fastcgi_param SCRIPT_FILENAME /home/public_html/my.domain.com/public/$fastcgi_script_name;
   include fastcgi_params;
}

Everything got better after that. Not sure who I thought I was fooling with my first solution, but it didn’t even work on myself.

I decided to give Piwik a try as my web analytics tool. I’ve used Mint in the past and am mostly happy with it, but I sometimes feel Shaun Inman has no sense of urgency to make improvements to catch up to the big guys. I also considered Google Analytics and GetClicky but can’t get over the idea of someone else owning my analytics data. Sure, that’s fine for my blog or other smaller sites, but for something “important”, I’d rather hold onto it myself.

Piwik installation was pretty straightforward, typical fare these days. First thing I noticed was that the site was completely broken in FireFox, but seemed to work fine in IE. Firing up Charles I saw 2 things that smelled wrong:

1. Requests for JavaScript and CSS files had a cache-busting query parameters stuck on the end of it, e.g. /piwik/themes/default/common.css?piwik=0.4.2. The idea here is that they can set a far-futures expires header on that file and let the browser cache it forever. When they release a new version of the site, they increment the version number on the request parameter and the browser goes and fetches the new styles or scripts. I thought this was an interesting technique, but possibly confusing nginx because….
2. The “Content-Type” header was coming back as “text/html” for both JavaScript and CSS files.

IE doesn’t seem to mind that the content type was set incorrectly but Firefox refused to apply the styles because of it. So I started tinkering to see what I could do. Worst case scenario I would just have to use piwik only in IE, but that seemed kind of defeatist. Strangely, no one else on the interwebs seemed to be having the same issue, which lead me to think it was something specific to my environment.

The first thing I tried was to remove the cache busting request parameter by commenting out this line of code in the piwik source code:

I found that line in the file core/View.php on line 54 in version 0.4.2. That got rid of the cache busting query parameter, but didn’t fix the content type issue, so I ended up putting that line back in. I tried dropping one of the CSS files I was testing on another server and requesting that to see the headers. They turned out to be fine, at which point I decided it had to be an nginx issue. A couple of hacky attempts later I came up with the idea of just adding another header to JavaScript or CSS files as such:

   if ( $request_filename ~* (\.css) ){
      add_header Content-Type "text/css; charset=UTF-8";
      break;
   }

   if ( $request_filename ~* (\.js) ){
      add_header Content-Type "application/x-javascript; charset=UTF-8";
      break;
   }

That seems to work. Not entirely thrilled about it since I still don’t fully understand why it’s happening. Two Content-Type headers are getting set, but Firefox is ok with that for now. Oh well.

Note this Update: read update

What I decided to do was to export the mapping to a config file. See an example config file here. This file goes into the application/config directory. You probably also want to update application/config/autoload.php to autoload that config file:

It is assumed that all JavaScript files are in the same location on disk and all CSS files are all in the same location on disk. It also assumes that all JavaScript files end with js and all CSS files end with css. The rest (mostly paths) can all be configured. I don’t show it but I have the absolute paths to the JavaScript/CSS files in the standard CodeIgniter config file.

The minify_config.php config file sets up a hash where the key is the controller name and the value is an array of JavaScript or CSS filenames. For simplicity’s sake the file name array is only one-dimensional, so you’ll notice the use of array_merge in some spots.

The MY_Includes class itself is greatly simplified now, but at its core performs the same task as the previous version, building a list of files to be included and passing them off to Minify for processing. The includetag.php controller is unchanged.

So the new and improved steps for integration are:

1. Download MY_Includes.php (here) and put it in your /system/applications/libraries directory
2. Download minify_config.php (here) and put it in your application/config directory
3. Edit the init method inside of MY_Includes.php to include the correct path to your Minify installation
4. (Optional) Edit the compileTags method inside of MY_Includes.php to include any special rules. Out of the box it will include a config item named global on every request, then check to see if there are any controller-specific files to include.
5. Download includetag.php (here) and put it in the /system/applications/controllers directory
6. Add the two code fragments commented with the text “for globally included header file” below to the appropriate file in your application
7. Fire it up

Feel free to post a comment if you have troubles and I’ll walk you through it or edit the post to fix any errors as needed.

Here’s the setup. My application is on 2 256 slices, 1 running nginx and PHP through fast cgi. The other is running MySQL. Outside of things like monit and munin, there is nothing else running on these slices. Perfect time to do some stress testing. The application is fairly database heavy, so I long ago decided to integrate memcache with an eye towards boosting peformance. Or so I thought (notice ominous foreshadowing).

My strategery with memcache is to never assume that it is either running, working, or contains the data I need. So my app will use it if it’s there but will carry on unaffected if it’s not. I left hooks in the app to be able to shut off memcache through config changes for cases where I’m testing via XAMPP and don’t have memcache running locally. This turned out to be very useful.

I have a third slice (which runs this blog and a couple of other smaller sites) that I installed http_load on. I used this box to drive the load tests.

One thing about http_load is that it doesn’t understand cookies. You provide it a URL or list of URLs and it just whacks on them until the server breaks. That poses a problem for apps like mine where being logged in is essential to the experience. So I had to make a few changes to the application to support a load testing mode. Once I change to this mode it will take the session identifier out of my config file instead of the cookie. No muss, no fuss, no meaningful change to the app’s behavior while in test mode, which is essential to ensure I’m comparing apples to apples.

OK, enough setup. Here’s one of my test scripts:

So, run 5 threads for 30 seconds. While that’s going on I’m checking top on my nginx and MySQL slices. First thing I notice – MySQL is pretty much sleeping through the test. Good news. Load on that slice barely breaks above .2. But the fast-cgi processes on the nginx box launch to the top and hog up CPU and memory at an alarming rate. Before the 30 seconds is over load on the nginx box is over 3. Not good. End result was about 27 requests per second. Not horrible, but there’s no way the box could maintain that kind of load long term. I ran this test:

Which simulates 20 requests a second. So what I’m trying to do there is find a reasonable amount of traffic that will stress the server but not kill it. That seemed to be about the breaking point. The server handled 20 requests a second with some negative effects but it seemed it could be stable at that level.

So, had to do some thinking. In an effort to cheer myself up, I figured I’d disable memcache and see how bad it would be without its help. If I got between 20 and 30 with memcache surely I’d only get between 15 and 20 without it.

Well, guess what, nerd. Not so much. To my amazement, the result came in around 36 requests per second without memcache. Not only that, CPU consumption by the fast-cgi threads was reduced and their memory consumption was totally normal. Beyond that, load on the database server didn’t budge.

It’s almost like memcache is penalizing me. Things got a little weirder when I commented out the code to pull some objects out of memcache but left others in. The results got down to 10 per second, which is nearly unbearable. I wish I had a conclusive summary to give but right now my thinking is that the overhead of connecting to memcache and hydrating objects is slower than just getting the data from the database. Or maybe I’m just overusing memcache – storing and retrieving too many small objects for example.

So for the meantime I’m running without memcache, despite the hours and hours of work I put in to integrate it, and all the hopes and dreams of the children.

Also, it might be a good idea to have some understanding of what the term “unit testing” means.

I had run xdebug to collect stats on my app’s landing page, the page where all users will be redirected after login. I’d naturally expect this to be one of the most heavily visited pages, therefore has to be as optimized as possible. After running the results of xdebug’s profiler (“xdebug.profiler_enable=On” in php.ini) through WinCacheGrind I found something like 300+ calls being made to the method CodeIgniter uses to load a library file/class. I had long suspected that liberal use of $CI->load->library(‘MY_Blah’) wasn’t necessarily good practice, but I didn’t suspect it could have been that bad.

So I decided to put my most-frequently loaded libraries into the autoload.php and remove any calls to load them in my libraries, controller, and views. The difference was noticeable, and a second pass through xdebug and WinCacheGrind proved the improvement was real. I tried not to go overboard by loading too many classes, and it seems like I was able to strike the right balance by autoloading less than ten of my dozens of classes.

Another interesting result was integrating memcache to save some of the objects that are frequently loaded on the landing page. These objects are for the most part shared across all users on the site. For some reason after I integrated memcache the memory usage for the controller (according to CodeIgniter) went up to around 8MB from 2MB. Very weird results that I’m going to have to think about. Database load on the page is near nothing, which is good news. I’m assuming the problem is in copying the objects out of memcache and creating PHP objects out of them.

Guess I’ll be doing some more profiling.

I was following these instructions – installed via PECL, added the line to php.ini, restarted the web server, etc. Nothing. Wasn’t showing up in either “php -m” or the output of phpinfo().

So then I decided to compile from source, using instructions on the same page. Now it actually got worse. I was getting a 502 error and this in the logs:

2009/06/04 16:50:46 [error] 4461#0: *1 recv() failed (104: Connection reset by peer) while reading response header from upstream, client: XXX.XXX.XXX, server: myserver.com, request: “GET /index.php HTTP/1.1″, upstream: “fastcgi://127.0.0.1:9000″, host: “myserver.com”

Begin freakout.

Nothing was working. Bounce web server. Nothing. Bounce slice. Nothing.

Continue freakout.

Don’t totally know why I decided to restart fastcgi, but sweet mother that worked. And not only that, xdebug was loading as expected.

sudo /etc/init.d/php-fastcgi restart

End freakout.

(To be more precise, I restarted nginx first and then restarted fastcgi.) Hope that helps someone out there. Certainly scared the tuna salad out of me for a good half hour. Oh the joys of system administration for developers.