May 08

Surprisingly basic Rails performance tips – and the people that don’t love them

Antonio Cangiano offers up 10 Ruby on Rails Performance tips, some of which are really just good practice in any web application and aren’t specific to Rails. This includes gems like:

don’t be afraid of using the cool features provided by your database, even if they are not directly supported by Rails and doing so means bypassing ActiveRecord. For example define stored procedures and functions, knowing that you can use them by communicating directly with the database through driver calls, rather than ActiveRecord high level method.


Retrieve only the information that you need. A lot of execution time can be wasted by running selects for data that is not really needed.

Shocking stuff!

What amazes me is the level of irritation evident in the comments from people decrying this as “premature optimization”. I agree that you shouldn’t completely reorganize your code to achieve some speculative performance increase before you really know what parts of your app are going to have issues. However, some things are just common sense. If I can pull back data from the database without doing O(n) queries in a loop, I should do that. If I need to run a report with lots of aggregated data, I should probably consider computing that in the DB via a function or stored procedure. Bottom line, there are things that are guaranteed to cause you problems. Sitting around and smugly saying, “I don’t want to optimize prematurely here” is no excuse for writing dumb code.

(Link to the performance tips via the FiveRuns Blog)

May 08

Towards the Web OS

Cesar Torres analyzed the new Facebook profile design yesterday as did TechCrunch. Both come to the same conclusion: Facebook is trying to become a web operating system. Both cite the use of a Mac OSX-style menu design (a weak indicator of an “OS” in my opinion) but Cesar goes farther to mention Facebook’s application platform, chat client and data portability developments. So, does an app platform plus a menu bar plus chat an OS make? Even a nascent OS? My answer to that is that Facebook, while acting more and more like a web-based OS is just a part of the Web OS.

What is an OS?

The whole concept of what makes an OS is a bit hard to pin down. At this point, I’d love to offer up the definition of an OS from my undergrad operating systems book but it appears to be missing chapter one. Suffice it to say it would have said something about CPU management, process management and probably something about batch jobs (it was really old when I got to it in 2000). Instead I’ll quote Wikipedia’s article on the topic:

An operating system is the software component of a computer system that is responsible for the management and coordination of activities and the sharing of the resources of the computer. The operating system (OS) acts as a host for application programs that are run on the machine. As a host, one of the purposes of an operating system is to handle the details of the operation of the hardware. This relieves application programs from having to manage these details and makes it easier to write applications.

If you’re a programmer and you see something that promises to relieve you from the details of something, you know you’re seeing an abstraction. Programmers love abstractions. In the name of simplification, we layer abstraction after abstraction on top of each other until we feel like we’ve got something easy enough to be productive. (And then we write something on top of that.) We write an OS to hide the hardware, we write programming languages that hide the details of the OS, we write APIs to make tasks easier in the programming languages and on and on and on. Fundamentally, an OS is just an abstraction over the bare metal.

This definition of the OS as an abstraction layer for application development is, of course, pretty technical. I would say that most people consider an OS (if they were to consider it) as the thing that lets them run their email app, their word processor or their web browser. In general, it should fade into the background and let people get on with what they want to get done using their actual apps. If it does bring itself into the foreground it should be by providing shiny eye candy and not with shiny blue screens.

Here’s the kicker though… Beyond just running our apps, we also expect our OS to allow them to share data. As OSes have evolved, we’ve come to think of them less as a resource management tool and more of a collection of useful apps that can all work reasonably well together when facilitated by the OS environment. This goes back at least to the Unix concept of small programs that take an input, perform a useful function and provide an output. This allows for all sorts of nifty command line piping and chaining of outputs to inputs; all facilitated by the operating system. I believe you could say this pattern is the precedent for today’s mashups.

So here’s a working definition. An OS is the thing that manages the hard low-level stuff so people can write apps so we can get things done by using and combining those apps. So does a web OS do this but just on the web?

Are we there yet?

I think we do have a nascent Web OS but it’s not one that’s provided by a single entity. It’s not Facebook or Google. It goes across the web as a whole. Each of these services provides a component of the overall experience much in the same way that Unix utilities do. Though Facebook search reminds us of OSX Spotlight; search on the web OS is located at google.com (for now).

Of course, the Web OS is being built beyond just our user experience interacting with web sites through our browser. The data sharing of the Web OS is being enabled by a host of technologies available to application developers. At the lowest level, we have the fundamental architecture of the web itself, HTTP, which allows for any kind of resource to be located and accessed. We can use HTTP to access any sort of data, but the critical types of data to the web OS are the meta ones that we can use to actually describe data: XML, JSON and even HTML. These form the basis for all the APIs we’ve come to know and love from all the web applications out there that have our data. Over the past few years we’ve begun to scratch the surface of what we can do when we can pipe information from one app to another via the environment provided us by this Web OS. From Google Maps mashups to the nearly infinite number of Twitter apps, we’re beginning to leverage these services in all kinds of ways. Once application developers can begin to rely on these services to abstract away the complexity of performing certain tasks whether that’s raw data storage, identity, search, messaging or the social graph then we’ll have a true Web OS.

Right now, there are still too many barriers. Many (maybe most) apps don’t allow data to move from place to place or put up walled gardens around what APIs and platforms they do offer. With data portability, we’re moving in the right direction (primarily with social data at least), but we’re not there yet. And, of course, there are still tons of applications that don’t (and may never) live in the cloud and so can’t participate fully in the emerging OS.

If we’re not there yet, where are we going?

We’ve still got a long way to go yet with the Web OS, but the pieces are emerging. Applications are moving into the cloud and we’re in the early days of programmatic communication between our various web utilities. We’re progressively abstracting away the hard parts of building really complex and powerful systems. That’s why programmers obsess about abstractions; they make hard things simple. And when hard things become simple, you’ve just taken a step to making even harder things possible. Ultimately the Web OS goes way beyond the placement of menus in Facebook, it will provide us the platform to make the previously impossible possible.

May 08

Serving the social graph and keeping the lights on: What Facebook and MySpace have in common with the power company

Mashable has a post today discussing Facebook’s 10% traffic decline from March to April as well as their year-on-year slowdown from 98% growth to 56% growth. This just adds to the recent meme of “Facebook kind of sucks” that has been going around for a while. For example RWW wants to make Facebook useful again and Scoble tweets about his version of the malaise.

The first issue seem to be with Facebook apps. They’re too spammy, too messy on the profile page and too pointless. I have to agree with this point. I just don’t know that there was so much missing from my poke experience that I need to be super-poked (or banana kicked or abducted by aliens or really receive a picture of a freaking cookie – but hey, I don’t have a $500 million company so what do I know?). Facebook is working to solve this problem by tweaking privacy settings, application notification rates, etc. Their long-awaited profile redesign should help as well.

The larger issue in my mind is that once you get on Facebook and get over the initial high of finding people you’ve not talked to in 7 years and exchanging a few wall posts, there’s really not that much to do. It’s great to connect with these people and get periodic updates on what they’re doing via the News Feed but it just doesn’t create a terribly sticky experience. There are some aspects of Facebook with real utility such as groups and events but they are really just small features that really aren’t much better than the alternatives.

I think the reason for both the issues above is that Facebook and MySpace are each aiming to be the utility company for social networks; ubiquitous and underlying everything else. Facebook even (in a phrase I have to feel like comes straight from Zuckerberg) calls itself a “social utility”. The problem with this approach is that utilities are not where the action is. Very few of us think about how awesome our power company is for powering our TVs; we just expect to pay a reasonable price and for the electricity to never go out. Utilities are what have to exist so we can get to the good stuff.

With the advent of the triple data portability initiatives from Facebook, MySpace and Google over the past couple weeks they’re taking even more steps towards becoming these utilities by providing their social graph data to others. In my opinion, it will be “the others” (and possibly Google) that benefit most from these developments. Sites targeting highly motivated niche communities will be able to spring up and use social graph data without having to force users into yet another “find and friend” cycle. Unique user experiences can be created that exploit the webs of links between people in the same way links between pages have been exploited on the web. Ultimately, these sites and applications will be the destinations for users looking to get value from social networking. We’ll go there, do the fun stuff (and maybe even spend the money). We’ll just expect Facebook and MySpace to fade into the background and keep the lights on.

May 08

Looking back on what I’ve learned as I start something new

Today is my last day at Kadro Solutions, my employer for the last 4 years. Over the next few days, I’m going to take a brief foray into the wilderness with some friends to clear my head. After that, I’m embarking on starting my second company, Appozite. I’m excited (and a little nervous) about this new step but I want to take a moment to talk about my experience at Kadro.

My time with Kadro really started back in 2000 when I was a co-op at iXL in the waning days of the .com bubble. I worked there in Raleigh, NC with most of the guys that would eventually form Kadro. Fast forward 3 years later: they call me up out of the blue, tell me about their new company and ask if I might be interested in helping them out. I really appreciated that they had remembered the skinny sophomore from back in the day enough to search me out and get in touch. It really could not have come at a more opportune time for me. It was during a difficult period for Liquid (the company I started in college) right after I had graduated and gotten married. By 2004, I was working at Kadro full time.

It was a tough choice to spend less time on Liquid and start working at Kadro. In retrospect, I believe it was the right one. Everyone who has the entrepreneurial gene like me struggles sometimes working as “just an employee” even at a company as small, flexible and supportive of individual initiative as Kadro. However, I soon came to realize that working with this smart group of veterans meant I would learn an incredible amount.

I learned how to really sacrifice and really take risks to get a business off the ground by watching the Kadro owners go without pay when necessary and work incredible hours when things were tough in the earlier days. I don’t think I had learned this lesson well enough at Liquid. There are just times when you have to double down.

I learned what it means to deliver for a customer and be committed to their success even if that means you sometimes have to put your own short-term gain on hold. You ask questions. You learn the customer’s business: what makes them money, what costs them money, what they want to achieve. Often this means you stray far beyond just the technology that you’re responsible for. This means you become a trusted advisor, a friend, a long-term partner. A business that just throws things over a wall to the customer, collects an invoice and moves on is not a sustainable business. I’ve watched Kadro grow and become very successful this way. It’s the right way.

I learned what it means to fall short despite heroic efforts. If you work at Kadro, you know what project I mean. Ultimately, it succeeded but it certainly was rough at the time. Until this project, I had always delivered and delivered well whether it was an application or a school project. This one though, didn’t quite work out that way. It tested my team and me to our breaking point (and probably beyond). I learned that you have to pull yourself up and do whatever you can to make it right. These things happen but you can do better next time; you can plan better, you can manage expectations better and you can ask for help when you need it.

I learned what it means to trust and be trusted by a group of business partners. Sometimes you have to take a risk and extend trust to someone before they’ve truly earned it. Kadro did this with me time and again. Whether it was letting me contribute directly to our core code framework from very early days to entrusting me as account manager of one of our biggest customers, Kadro chose to give me the responsibility and the freedom to take on important tasks. I hope that I ultimately earned what they gave.

I learned what it means to build friendships that start within a team of colleagues but that grow well beyond that. We worked together but there was a lot more to it than that. We played ping-pong, we went to lunch, we argued, we came up with ideas, we developed 1000 inside jokes. We even had the occasional KHappyHour (thanks John). I watched Malcolm and Scott add to their families, commiserated with Rick as he’s taken care of his and kept Andy and Elizabeth in my thoughts as they struggled to start theirs even though I couldn’t help much from all the way out here in Austin.

Finally, I learned that you should never, ever let Scott pick a name for your company, or work for your company, or get near anything of value.

Thank you to everyone at Kadro. The experience has been invaluable and I hope the friendships last well beyond this transition.

May 08

Concept Dropping

concept dropping (v) – the act of incoherently stringing together concepts for the sole purpose of using said concepts to impress an uninformed audience. (see also: transparent meme-whoring)

Steve Gillmore provides what should now be seen as the canonical concept-dropping example on TechCruch:

Simply put, you have to have the ability to broadcast an acuity for successful guesses. We’re at the doorway of gesture farming, where individual gesturers go beyond implicit behavior harvesting and aggregation and overtly share not just what they like but what they ignore. We’re seeing this in the political realm, where people are tuning out repetitive and shrill networks built on track spamming (Reverend Wright, Day One, electability) and tuning in to credible authentic sources regardless of media affiliation. They’re going direct via TinyUrl and their social graph (follow/track/filter) ontology


May 08

Adventures in Macro Blogging

I’ve been using Twitter seriously for several months now and I really enjoy the rapid information exchange of the micro blogging platform. I’ve never been able to sustain a “real” blog for very long but I’ve stuck with Twitter. That 140 character limit is a far lower barrier to entry than the blank HTML text area of WordPress admin which seems to call for so much tedious “organization” and “coherence”. All that said, I’m going to give macro blogging another try as I do occasionally wish to express myself in more than the length of a text message. Here’s hoping for relatively frequent, somewhat coherent posts longer than 140 characters.