While sitting at the bar one of my sisters’ friends drew a lot of attention from the gentlemen of Rutherford County. We’ll call her Liz (gah, when does 30Rock start up again??). Some would come up and chat, others ask for a dance. The most peculiar case of them all was one who had been ordering drinks from across the bar and finally got up the courage to come over and, without a word, slip Liz a piece of paper with his phone number on it before disappearing into the night.

Yes, this post is about programming, bear with me.

Let’s give this guy, say Dennis, the benefit of the doubt and assume that these tactics have worked before with success. On this particular night with a gorgeous girl from out of town: no dice. Dennis wouldn’t get the callback.

Let’s pseudo-code this scenario:

$liz = new AttractiveOutOfTownGirl();
$dennis = new SmallTownFriendlyYoungMan();
$liz->setDrink($dennis->buyDrink('Vodka Redbull'));
$liz->setDrink($dennis->buyDrink('Sex on the Beach'));
$liz->receiveNumber($dennis->getPagerNumber());
$dennis->disappearIntoTheNight();

Spot any patterns? Thrice Dennis has taken an action that results in some value: he’s bought 2 drinks and retrieved his pager number. All of his methods have resulted in some value that is handed to Liz and he’s getting no acknowledgement back. He interacted with muted methods. Dennis’ shot at success depended on Liz having some internal, finite state machine that transitioned from “stranger” to  “stranger willing to call a stranger” with every additional drink. How could this have gone better for Dennis?

Before we get there let’s talk about muted methods. Procedures. Voids. Black holes in programs where input results in no output. Scary stuff! But why, what’s so bad about muted functions? Let’s nitpick our example. It is so  choppy. Do you feel the choppiness?

Noun verb.
Noun verb.
Noun verb.
Liz set drink.
Liz set drink.
Liz give number.

When your verb is muted, there’s nothing more to be said. End of story. Next line. You’ve got nothing to play off of, no chance to converse. When you’re working with muted functions you have no segue. You’re giving without receiving.

If muted functions are the problem, how could this scene look a little less ugly? Perhaps Dennis could have conversed with Liz. Interacted with her. Made use of a more fluent interface…

$dennis->saysTo($liz, "Hey girl, from out of town?") // returns $liz
       ->saysTo($dennis, "Yes, how'd you know?") // returns $dennis
       ->saysTo($liz, "Never did seen you before!") // returns $liz
       ->isStillSmiling()
       ? // If she's smiling
   $liz->setDrink($dennis->buyDrink('Vodka Redbull')) // returns $liz
       ->saysTo($dennis, "Thanks, you're kind of cute.")
       ->saysTo($liz, "That's how we're grown here. Can I call you?")
       ->saysTo($dennis, "Sure, my name is Liz and the number is...")
       ->punchesInNumber("919-928-9090") // returns $dennis
       ->says("Great, call you tomorrow!") // returns $dennis
       ->disappearIntoTheNight()
       : // If she's frowning
$dennis->movesAlong();

When you’re not dealing with muted methods you give your code the chance to come to life in a more fluid, fluent way. There’s only sentences here, it’s just longer, richer, and more involved. There’s magical, programmatic banter happening here!

This style of object-oriented interface, where method chaining and thoughtful return values enable a pseudo-domain specific language written entirely in a general purpose language, has been called a “Fluent Interface” by Martin Fowler and Eric Evans. It’s an inspiring departure from the days of the void, black hole methods like setters.

So, next time you’re writing an interface for some new class, or sitting at a bar wondering how best to approach that attractive member of the opposite sex, avoid muted methods at all costs. They’re black holes. They’re just awkward, feedbackless, and overall uncomfortable for everyone involved.

When your functions or methods don’t return ask yourself “if I were to return something here what would be useful?” Most often, it’s a reference to the object itself. Or an immutable clone.

“Oh, god no, not an immutable clone! I thought this article was about bar game?” Hmm… you’re right. I’ll save the immutable clone wars for another post. You should subscribe to this RSS feed if immutable clones pique your interest. Or nerdy bar game.

• Using virtual machines and shell scripts to achieve the Ultimate Small Team Software Engineering Environment ™
• Real Software Engineering in PHP
• Trees, Recursion, Permissions, and Architecture of my company’s next Content Management System
• How to simplify internals and increase functionality of the Recess Framework by leveraging PHP 5.3’s new features like anonymous functions and namespaces
• A big client integration project that deals with scary acronyms like HIPAA

This space should be more lively than the ghosttown that it has become over the last 8 months. More off the cuff writing on the topic of the hour than the more structured pieces I’ve been writing for New Media’s Web Development Blog or the Recess PHP Blog.

To kick that off the off the cuff writing, a few words on _why. I don’t know _why, I haven’t read the poignant guide to Ruby (although I’ve come across it a number of occasions and been intrigued), nor have I used much of his huge body of open source work. None the less his recent disappearance has been sitting really funny on my stomach. Really funny. This guy is prolithic, talented, and obsessed with teaching the art and joy of programming. I didn’t fully appreciate _why until watching his recent talk at Carnegie Melon [embedded below]. His excitement and creative knack for opening programming up to a younger audience is energizing. Here’s to hoping an even brighter chapter to that story is about to unfold…

Without further adieu… Routing in Recess!

Recess! PHP Framework

Tip #1: Using PUT and DELETE methods

In PHP you can determine which HTTP method was used with: $_SERVER['REQUEST_METHOD']; From web browsers this will be either GET or POST. For RESTful clients applications need to support PUT and DELETE (and ideally OPTIONS, etc.) as well. Unfortunately PHP doesn’t have $_PUT and $_DELETE variables like it does $_POST and $_GET. Here’s how to access the content of a PUT request in PHP:

$_PUT  = array();
if($_SERVER['REQUEST_METHOD'] == 'PUT') {
    $putdata = file_get_contents('php://input');
    $exploded = explode('&', $putdata); 

    foreach($exploded as $pair) {
        $item = explode('=', $pair);
        if(count($item) == 2) {
            $_PUT[urldecode($item[0])] = urldecode($item[1]);
        }
    }
}

Tip #2: Send Custom HTTP/1.1 Headers

PHP’s header function allows custom HTTP headers to be sent to the client. The HTTP/1.x header contains the response code from the server. PHP will, by default, send back a 200 OK status code which suggests that the request has succeeded even if it has die()’ed or a new resource has been created. There are two ways to change the status code of your response:

header('HTTP/1.1 404 Not Found');
/* OR */
header('Location: http://www.foo.com/bar', true, 201); // 201 CREATED

The first line is a generic way of setting the response status code. If your response requires another header, like the Location header to the resource of a ‘201 Created’ or ‘301 Moved Permanently’, placing the integer status code in the third parameter of header is a shortcut. It is the logical equivalent of the following example, which is easier to read at the cost of being an extra line of code.

header('HTTP/1.1 201 Created');
header('Location: http://www.foo.com/bar');

Tip #3: Send Meaningful HTTP Headers

Policy for deciding when it is appropriate to send each HTTP status code is a full post on its own and the HTTP spec leaves room for ambiguity. There are many other resources on the net which provide insights so I’ll just touch on a few.

201 Created is used when a new resource has been created. It should include a Location header which specifies the URL for the resource (i.e. books/1). The inclusion of a location header does not automatically forward the client to the resource, rather, 201 Created responses should include an entity (message body) which lists the location of the resource.

202 Accepted allows the server to tell the client “yeah, we heard your order, we’ll get to it soon.” Think the Twitter API on a busy day. Where 201 Created implies the resource has been created before a response returns, 202 Accepted implies the request is ok and in a queue somewhere.

304 Not Modified in conjunction with caching and conditional GET requests (requests with If-Modified-Since / If-None-Match headers) allows web applications to say “the content hasn’t changed, continue using the cached version” without having to re-render and send the cached content down the pipe.

401 Unauthorized should be used when attempting to access a resource which requires authentication credentials the request does not carry. This is used in conjunction with www-authentication.

500 Internal Server Error is better than OK when your PHP script dies or reaches an exception.

In the Recess! Framework I use this StatusCodes class to provide named constants for all HTTP/1.1 status codes. Example usage:

header(StatusCodes::httpHeaderFor(StatusCodes::HTTP_NOT_FOUND));

Tip #4: Don’t Use $_SESSION

A truly RESTful PHP application should be entirely stateless- all requests should contain enough information to be handled without additional server side state. In practice this means storing authentication information in a cookie with a timestamp and a checksum. Additional data can also be stored in a cookie. In the event you need more than a cookie’s worth of data fall back to storing it in a central database with the authentication still in the cookie. This is how Flickr approaches statelessness.

Tip #5: Test with cURL or rest-client

cURL makes it easy to execute any HTTP METHOD on a resource URL. You can pass request parameters and headers as well as inspect response headers and data. The command line tool ‘curl’ is standard on many *nix distros. Windows users should check out MinGW/MSYS which supports cURL. Even PHP has cURL functions which are enabled on most hosts (php/curl install page).

cURL Example Usage & Common Parameters:

# curl -X PUT http://www.foo.com/bar/1 -d "some=var" -d "other=var2" -H "Accept: text/json" -I

-X [METHOD] Specify the HTTP method.
-d “name=value” Set a POST/PUT field name and value.
-H [HEADER] Set a header.
-I Only display response’s headers.

Alternatively, a free GUI to test REST interfaces is Java/Swing based rest-client. rest-client is scriptable and has support for JSON/XML.

Tip #6 – Use a RESTful PHP Framework

Frankly, developers shouldn’t have to worry about many of these low-level details of REST when writing PHP apps. REST is based on conventions and conventions, by nature, involve a lot of boilerplate. This is right up a framework’s alley (as Rails has shown). What options exist for PHP? CodeIgniter’s routing completely ignores the HTTP METHOD so there is serious hacking that needs to be done. Cake has REST support but wasn’t designed to make specifying useful response status codes a part of the framework. Konstruct appears to have a very well thought out architecture for a controllers framework built around HTTP and REST. Unfortunately it is not easily approached and lacking (intentionally) many components, like an ORM layer, developers have come to expect in a modern web framework.

(Disclaimer: Shameless Plug!) The lack of a solid, RESTful PHP framework was one of my primary motivations for creating the Recess! Framework. Recess is a full-stack, open source (MIT), RESTful PHP framework. If you’re interested in writing RESTful PHP applications check it out and sign-up to be notified of its upcoming release.

Re: Oversight #1 – No Data Access Layer

Quality software design and engineering is all about abstracting away details and finding the proper layers of functionality. As Justin points out, if there is no layer of abstraction which wraps data access code then low-level data access code will appear everywhere. PHP projects which interleave data connections and queries throughout their code are difficult to maintain.

The database stack in Recess! has four major components: 1) SQL statement builder, 2) Data Sources, 3) Data Sets, 4) Object-Relational Mapped Models. The notion of a ‘data access layer’ is taken care of by Data Sources. Data sources wrap properly around PDO and introduce new methods beyond PDO’s, for example: getTables and getColumns($table). The implementation of these methods is specific to the RDBMS so Recess! also has the notion of a vendor specific driver called a DataSourceProvider. Currently Sqlite and MySql are supported.

Re: Oversight #2 – Design for Only One Database Connection

Small, greenfield projects often start out with a single database. This leads to naive data access layers which only support connections to a single database. Recess! supports multiple, named Data Sources. Instead of using a singleton pattern it uses a registry to store the Data Sources by name.

Having named Data Sources in an application gets really powerful at higher layers of abstraction, such as at the ORM layer, where we can mark-up a model with a single annotation to define which Data Source the model is persisted in.

Re: Oversight #3 – No Developer Logging

This isn’t as fully fleshed out yet as I’d like but the plans and hooks are in place to be able to log queries, their stack traces, as well as their EXPLAIN’ed strategies for execution in the RDBMS. In Recess! there is a distinct difference between Development mode and Production mode. Sql logging will be a toggle option on by default in development and off by default in production.

Re: Oversight #4 – Queries Written in Procedural Processes

My dislike of queries being written in procedural code may run even deeper than Justin’s! Recess! abdicates SQL string manipulation to a low-level SqlBuilder class. An instance of SqlBuilder allows SQL query strings to be built incrementally using chained method calls. Let’s take a look at some examples:

$sqlBuilder = new SqlBuilder();
$sql = $sqlBuilder
            ->from('people')
            ->like('name','Kris')
            ->orderBy('age')
            ->toSql();
// $sql is now:
// 'SELECT people.*
//    WHERE people.name = :people_name
//    ORDER BY people.age
$args = $sqlBuilder->getPdoArguments();
// $args is now array( 'people_name' => 'Kris' );

// Let's add another criterion
$sql = $sqlBuilder->equal('home_city', 'Charlotte')->toSql();
// $sql is now:
//  SELECT people.*
//      WHERE people.name LIKE :people_name
//      AND people.home_city = :people_home_city
//      ORDER BY people.age

$args = $sqlBuilder->getPdoArguments();
// $args is now array(
//                   'people_name' => 'Kris',
//                   'people_home_city' => 'Charlotte' );

SqlBuilder can do more complex things like joins, as well as inserts, updates, and deletes. Recess! users, though, will likely never use SqlBuilder because it’s still too low level of an abstraction. Internally, however, having the ability to incrementally construct query strings has made the framework code quite pretty.

Here’s code at the level of abstraction Recess! developers can expect to write:

class Person extends Model { }
$person = new Person();
$person->name = 'Kris';
$person->homeCity = 'Charlotte';
$people = $person->find()->orderBy('name');
foreach($people as $person) {
   echo $person->name, ' ', $person->age, '<br />';
}

This example just scrapes the surface of Recess! object-relational mapping. Relationships, CRUDS, cascading deletes, etc. are all handled as well. In a future post I’ll step through the data access stack’s capabilities in more detail. Needless to say, in Recess! queries won’t be mixed with procedural code!

Re: Oversight #5 – No Separation of Reads and Writes

Once projects outgrow a single server RDBMS the next step is often to do a Master/Slave setup in MySQL. In a Master/Slave setup expensive and less frequent writes are channeled to the Master server while reads are channeled to the Slave server.

In Recess!, by using named data sources as described in #2, we can handle Data Sources on a per model basis. A natural extension of this is handling reads and writes independently on a per model basis. The pseudo-code below shows how this may look on a model:

/**
 * !Source master, For: Writes
 * !Source (slave1, slave2, slave3), For: Reads
 * !HasMany books
 */
class Person extends Model {}

/**
 * !Source master
 * !BelongsTo person
 */
class Books extends Model {}

In a future post I’ll describe the Recess! annotations system which will explain the constructs you’re seeing in the DocComments. Recess! annotations give us a way of providing static metadata about a class and are built-in to the framework’s core. Recess! annotations should be familiar to Java and .Net programmers who have used annotations.

Conclusion

So that’s a quick look at how Recess! handles Justin Carmony’s commonly made MySQL/PHP mistakes. These issues are abstracted away in the internals of Recess. If you’re a PHP developer check out RecessFramework.com and sign-up to be notified when it is publicly released “very soon now”.

Simple, Built-in Dynamic Properties

Check out the following code listing:

class DynamicProperties { }
$object = new DynamicProperties;

print isset($object->foo) ? 't' : 'f'; // f

// Set Dynamic Properties foo and fooz
$object->foo = 'bar';
$object->fooz = 'baz';

// Isset and Unset work
isset($object->foo); // true
unset($object->foo); 

// Iterate through Properties and Values
foreach($object as $property => $value)  {
     print($property . ' = ' . $value . '<br />');
}
// Prints:
//   fooz = baz

Using the built-in dynamic instance properties is an order of magnitude faster (30x, by my profiling) than using magic __get and __set methods. Built in dynamic property accesses happen without invoking a method call back to PHP script.

So when does it make sense to use __get and __set? If you need more complex behavior, like calculated properties, you must use __get and __set. Also, as an astute comment points out, if you would prefer not to have dynamic properties on a class you can throw errors from __get and __set.

StdClass: Anonymous Objects

Sometimes all that is necessary is a property bag to throw key value pairs into. One way is to use array, but this requires quoting all keys. Another way is to use dynamic properties on an instance of StdClass. StdClass is a sparsely documented class in PHP which has no predefined members.

$object = new StdClass;
$object->foo = 'bar';
json_encode($object);

Next I’ll touch on the SPL’s Countable and ArrayAccess as a means of being able to accomplish the following in PHP:

class MyClass implements Countable, ArrayAccess { ... }

$myObject = new MyClass();
// Using array access notation
$myObject[0] = 'hello';
$myObject[1] = 'world';
$myObject['foo'] = 'bar';

Thanks to the folks pointing out that you don’t need to extend from StdClass in order to have dynamic properties!

VoteTheSite.com - Vote on Political Websites

After the elections have taken place the votes on websites will be tallied up and compared to election results. Should be really interesting to see what the outcome is and how strong website quality correlates with campaign success.

Within the first 24 hours over 5,000 votes have been cast. Congrats to the New Media team for getting this out the door so quickly (with a little help from the Mechanical Turk)! Go vote on the websites in your state…

VoteTheSite.com was written (in under 2 days!) on an early version of the PHP Framework, the Recess! Framework, I’ve had my head down plugging away on the past couple of weeks. Expect blog activity to pick up as the Recess! Framework moves closer to a public release. Sign up to be notified of the release at RecessFramework.com.

Energized by what I saw at the Web 2.0 Expo in NY I’m back at it again. My three big goals with this take:

1) Get it in the wild: Open source with an MIT license. This is going to happen before the New Year. Hopefully sooner. We intended to do this with V2. It actually was publicly available in 2006 for a brief period of time but without any real plan for evangelism. I’ve been using open source software for a long time and its high time to give back.

2) Play nice in the new RESTful world. If I had to bet on a paradigm for interacting with web APIs I would bet the farm on REST. It is perfectly aligned with the grain of the web. Most existing frameworks written without an emphasis on REST have made awkward face lifts to adapt. When revisiting our own framework and considering how to make it properly RESTful this would have held true if not for…

3) Signficantly Improving the Architecture. Revisiting old code is a joy. It’s easy to forget how clever you were and how much work you did. Yet it’s very disturbing to realize how hacked some of the fundamental design was. As mentioned, the current version was influenced significantly by what Rails plumbing looked like circa-2006. Since then two really important things have changed: 1) the emphasis on tying closer to HTTP protocol, and 2) two additional years of experience with systems design under the belt.

So, here’s to take 3! Bits available for download in upcoming months. E-mail me at krisjordan/gmail if interested in being copied on barely functional, pre-release bits in the mean time. Otherwise, stay tuned.

Innovating with Sticky Notes (Excerpt)

A technique that caught my eye was “Innovating with Sticky Notes” (p28). The premise is to use a sharpie and generate ideas on sticky notes. One idea per sticky note (the bonus of using a sharpie is that is about all you can fit). Just unleash as many ideas as possible and get them up on the wall. Structure and flow can then be orchestrated by rearranging the notes.

Idea Notes for Chord Talk

I decided to give the sticky note method a shot with a talk I’m giving on the Chord Protocol in a graduate class I’m auditing at UNC. I must admit I really liked the technique after trying it out. It’s quick and dirty and prevented me from getting lost in details and aesthetics. My focus remained on the big ideas and overall message I wanted to ‘teach’. I would even go so far as to say that it’s fun. Once I’m done with the talk I’ll narrate a slideshow and throw it up on here so you can see the end result.

This sharpie + sticky notes method is only a detail in the grand thesis of Nancy Duarte’s slide:ology. Spend some quality time with this book before you prepare your next presentation, you won’t regret it.

Aside: if you’re going to use this technique on a wall at a coffee shop be prepared for inquisitive looks!

10. Your Web App: Give it a REST

David Heinemier Hansson’s session about making Ruby on Rails RESTful cast this battle as an epic one between the REST Rebels and the Imperial WS-* Death Star. It’s going to be a tough fight but you know who’s gonna win.

REST (Representational State Transfer) is the elegant architecture and set of conventions first presented in Roy Fielding’s PhD dissertation “Architectural Styles and the Design of Network-based Software Architectures“. It is well aligned with the HTTP protocol and much simpler to implement and use than SOAP, XMLRPC, etc.

Implementing RESTful APIs in web applications is getting really easy with leading frameworks like Rails and Cake supporting REST as a first-class citizen. The Atom format is leading the charge as a RESTful format supported by the big players: Google, Microsoft, Yahoo, Twitter, etc.

9. “It’s Not Information Overload, It’s Filter Failure”

Clay Shirky’s talk states that since the invention of the printing press humans have always faced information overload. We have been surrounded by more information than we can consume in an entire lifetime for centuries. The problem is not information over load, it’s filter failure. We need better filters.

Jay Adelson of Digg believes building better filters is exactly the mission Digg and other players in the collaborative filter space are addressing.

8. Sensor Driven Data: The Web is Getting Orwellian

With Apple putting GPS in iPhones, Google putting GPS in Android, Nikon putting GPS in the Coolpix P6000, and … you get the point. GPS, motion sensors, video recorders, microphones, and other sensors are increasingly distributed and surrounding us.

Tim O’Reilly believes a BIG revolution is happening Here. Tim is really bullish on sensor driven data. Where 2.0 has its own O’Reilly Conference. This space is heating up fast.

7. Javascript is Bringing Sexy Back to the Browser

John Resig gave a session on processing.js, his visualization engine running atop the HTML5 Canvas. The canvas has really low level functionality, a la OpenGL for 2-D surfaces, but with the right libraries in place it can lead to some truly impressive results. Flickr’s Paul Hammond gave perhaps the most compelling story of the use of Javascript and Canvas. After building Flickr Stats, using Canvas for graph visualizations, a team member loaded a page on an iPhone. It just flat out worked.

Unfortunately my friends over at Microsoft are slowing down the progress here with no planned support for the HTML5 Canvas in IE8. Google’s excanvas gets around this for IE users by mapping to VML. Unfortunately excanvas currently only works in quirks mode in IE8. Damnit Microsoft, you’ve brought IE8 a long ways towards being a modern, friendly player on the web, why not support Canvas? Come on Oz, come on.

6. The Open Web is Nearing the Tipping Point

DataPortability co-founders Chris Saad and Daniela Barbosa gave a great session on the basic motivations behind the movement. The future the DataPortability group is trying to create, one which allows us to owning our data, our contacts, our relationships, etc. and be able to move them freely and easily between the on-line systems we use sounds truly empowering. The big players are joining the party: Microsoft, Google, Facebook, Six Apart, Linked In, Yahoo, Digg, Plaxo, MySpace. But Chris says “Who cares about them? This is a grassroots effort!”

Joseph Smarr, Chief Architect of Plaxo, gave another interesting session on the major components of the open web and how they fit together. OAuth, OpenID, Open Social, and others were covered. The feeling I walked away with is that we’re a lot closer than I thought.

5. Web Scalability thanks to Async & Danga

“You can’t drop something in 40,000 buckets, synchronously, at once”, said Digg’s Lead Architect, Joe Stump in his session “Scaling Digg and Other Web Applications“. He was referencing what happens when Kevin Rose posts a message on Twitter. (Rose actually has nearly 65,000 followers on Twitter) Asynchronous task queuing is how the folks at Digg, Twitter, and Flickr deal with problems that are really hard to do in real time in any scalable fashion.

Just about all of Brad Fitzpatrick’s (of LiveJournal and OpenID fame) lightweight systems software, freely available at Danga.com, seems to be used by the biggest Web 2.0 players to achieve scale. That memcached, gearman, perlbal, djabberd, and mogilefs, all came out of Fitzpatrick and Danga is just incredible. No wonder Google gobbled him up from Six Apart.

4. Web 2.0 Traffic: It’s Out-of-Band

The knowledge tidbit that stuck out more in my mind than any other was that Twitter gets 10 times the amount of traffic from its API than it does through its website. It makes sense, I’d just never acknowledged it explicitly. Dion Hinchcliffe’s workshop painted a similar story for many other Web 2.0 successes. The canonical example is YouTube with the embedded video. The decision to put html snippets plainly visible, right beside of the video, was perhaps their most genius move. Modern web applications and services are making themselves relevant by opening as many channels of distribution possible through feeds, widgets, badges, and programmable APIs.

3. Cal Henderson’s PHP Tent Revival

If not for Cal Henderson I may have never have touched PHP again. I’m probably going to come back to this topic in more depth in a future post but Cal’s workshop “Scalable Web Architectures: Common Patterns and Approaches” renewed my interest in, relationship with, and respect for PHP. The funny thing is that wasn’t even the point of the talk. Cal and Joe Stump of Digg’s succinct point that Langauges Don’t Scale is right on. Sure PHP isn’t as beautiful, trendy, or well designed as Python or Ruby are. However, some of the design decisions made by PHP’s Rasmus, specifically the ’shared nothing’ness, make it a great technology for web applications. There’s a reason why Facebook, Digg, Flickr, and co. are still on it.

After Cal’s workshop I asked him: if you could do it all over again with Flickr would you choose to go with Python or Ruby? Cal’s answer: Nope, I’d do it in PHP.

2. Set Your Baby Free

By grooming and nurturing a web app internally for an extended period of time is you lose a lot of value. Jason Fried’s notion of “half a product is better than a half-assed product” is so fitting here. Sandy Jen of Meebo echoes similar notions in her talk: Start out with something simple, see if it works, evolve. Bring your customers into the feedback loop as quickly as possible. Joshua Schachter, founder of delicious, spoke of the exact same sentiments in his talk on “Scaling and Building Social Systems“.

1. Want to Set the World on Fire? YOU Better Bring the Fire.

If you are not bringing the heat, get out of the kitchen. Passion was the common thread amongst the most inspiring talks I saw at the conference. Between Gary Vaynerchuk, Jason Fried, and Arianna Huffington the message was  consistent: be passionate. I’m going to let Gary roll this one out with his amazingly energetic keynote on building personal brand…