Archive for the ‘I Remember’ Category

The Green Room

Friday, November 6th, 2009

TechStars in Seattle

I just got back last night from a TechStars event in Seattle. The event was an opportunity for TechStars teams from all locations and years to get together and share the challenges they’re facing in every aspect of their businesses. Beyond that it was a great opportunity to meet some of the people from the Seattle entrepreneurial community and some of the fantastic mentors out there.

Listening to the other teams speak, the thing that really struck me was the different stages the companies were at based on the year they “graduated” from TechStars. Teams from the first year ranged from completely disbanded to successful exits (some of whom are onto their next big ideas). Teams from year two fascinated me most of all, as they represented the place where Vanilla can be a year from now. Some were struggling, others were seeing great success through bootstrapping alone, and others were considering new rounds of financing. Finally, the teams from this year (my “class”) were all in roughly the same boat – at or near closing their first round of financing, starting to hire staff, and really cranking hard at improving their products and services.

What struck me about the spectrum were the levels of what I’m calling “green”. I believe that we’re never going to know everything, and everyone is always in an intense state of learning – especially in start-ups, where there is always more to do than you had anticipated. I found that the knowledge I gained from interacting with the teams from the first two years was just as valuable – if not more valuable in some cases – as the knowledge I gained from interacting with mentors at the event. I left the event extremely excited about all of the things (yet unknown) that will happen to Vanilla in the next 12 months.

I spoke about these levels of green to some of the other teams from 2009 TechStars, and we all brought up one of our favourite sessions from our time at TechStars – the “Previous Founders Day”. On “Previous Founders Day”, David Cohen invited all of the companies that had previously gone through TechStars to come back to Boulder, sit in a big group across from the new class of founders, and field their questions until they ran out of them. To me, this past summer, those companies seemed so much further along than me, and I felt that we – sitting across from them – were clueless. What I didn’t know at the time was that they were sitting at various shades of green as well.

I, personally, can’t wait for that day to come in 2010. I’ve already started to compile a list of things that those founders should know about the program going in. For example: what it actually means to take on an investment and what the expectations of the investors are. In 2009 when I was going through the program, I was unaware that we’d be placed in front of investors so early in the summer, and I’m sure that to many of them I came across as a complete fool. Another example: how to make the most of your time. I thought I knew what “busy” was when I first entered the program, and by the last month of the program I ached for the heady, lazy days of month 1. Another example: how to approach mentors. In the beginning I was nervous about approaching mentors. I was afraid of saying something stupid and scaring them away. I didn’t realize that they expected me to say stupid things and have silly misconceptions. They wanted to help me work through the things I didn’t know.

Prepare yourselves, future TechStars, for the green room. I can’t wait to see what you’ve been working on, and share my “advanced” shade of green with you.

Garden Preview Part VI: Models & Forms

Tuesday, December 16th, 2008

Garden Preview Part I: Overview
Garden Preview Part II: Filesystem
Garden Preview Part III: Anatomy of a Request
Garden Preview Part IV: Views
Garden Preview Part V: Data
Garden Preview Part VI: Models & Forms
Garden Preview Part VII: Ajax
Garden Preview Part VIII: Plugins
Garden Preview Part IX: Roles & Permissions
Garden Preview Part X: User Registration
Garden Preview Part XI: Structure


The theory of a Model in MVC is that it is an object representation of the data being manipulated. As you’ve seen in the last Garden preview, however, the actual object representation of the data comes from the DataSet class in the form of a php stdObject. So, as you may have guessed already, in Garden the model isn’t a representation of the data.

In Garden, a model relates directly to a table, and (with the help of the database object) allows you to retrieve information from the table, enforce the schema of that table on data being manipulated, and put data into the table. The real power of the Model class in Garden comes from it’s ability to examine the table from which it was created, and understand the data types and requirements for putting data into that table. When combined with Garden’s Validation and Form classes, this makes for a very powerful set of tools.

The Model class itself is quite simple, and can be used on any table in the database. Let’s take a look at a very basic example of how a model could be used to get some data from a database, validate data, and update data.

// Create a validation object to handle 
// validation issues that the model will 
// encounter:
$Validation = new Validation();

// Create a new model based on a table 
// in the database called "Blog":
$BlogModel = new Model('Blog', $Validation);

// Retrieve a DataSet from the Blog table:
$BlogData = $BlogModel->GetWhere(array('BlogID' => '12'));

// Grab the first row of the dataset as an 
// associative array:
$Blog = $BlogData->FirstRow('', DATASET_TYPE_ARRAY);

// $Blog now contains every column of the 
// "Blog" table where BlogID == 12. Let's 
// change something:
$Blog['Title'] = 'Some blog title';

// And save it:
$BlogModel->Save($Blog); // Validates

// And let's try to insert something that 
// we know shouldn't go into the database:
$Blog['BlogID'] = 'Not an Integer!';

// And save it:
$BlogModel->Save($Blog); // Doesn't validate

When the model’s “GetWhere” method is called, it does a very simple “select * from Blog where BlogID = 12″ query that returns all of the columns from that table into a dataset. At this point, the model still doesn’t know anything about the structure of the table.

When the model’s “Save” method is called, the first thing it does is uses the Database object to get information about the table so that it can define the table’s schema. It looks at each column’s data types, isnullable, default values, keys, etc. Then it uses the validation object to build up a set of rules for each column. Finally, it examines the $Blog that was passed as it’s first argument, matching up associative array keys with column names, and then checks each field against the rules automatically defined for that table. As it encounters problems, it builds up a set of validation results that can then be used however you wish (typically they are consumed by Garden’s form object and displayed on the screen).

So, with just a few lines of code, I’ve grabbed data from the database, altered it, and saved it – making sure that no invalid data is inserted into the database, all exceptions are caught, and results can be delivered to the user:

// Prints:
Array (
    [BlogID] => Array (
            [0] => ValidateInteger

This means that the “BlogID” field has encountered a problem when attempting to validate that the BlogID value was an integer. If there had been other errors for that column, they would have also appeared, for example:

// Empty value is also incorrect
$Blog['BlogID'] = ''; 

// Prints:
Array (
    [BlogID] => Array (
            [0] => ValidateRequired,
            [1] => ValidateInteger

The validation object will always collect as much information about what is wrong with the data as possible. It is then up to the developer what to do with that information. Luckily, 99% of the time the developer will just let the Form handle the validation results.


In order for the database, models, validation, & datasets to shine, we need to get the information out and editable by the users. This is where the Form class comes into play.

Let’s take a look at an actual example of how the controller, model, validator, and form work together. Let’s say we get the following request:


Which is the same as calling the following controller in an imaginary “bloggingtool” application:


My “New” method on the post controller would contain:

public function New() {
   $Validation = new Validation();
   $BlogModel = new Model('Blog', $Validation);

   // Set the BlogModel on the form.

   // If the form has already been posted back...
   if ($this->Form->AuthenticatedPostBack()) {
      // Attempt to save the form values
      $BlogID = $this->Form->Save();

      // If it saved, redirect to the new entry:
      if ($BlogID !== FALSE)

   // Render the form

The form’s Save() method calls the model’s Save() and then takes any validation results that came out of it. If the save was successful, the model would have returned the id of the record inserted (or updated). If not, it could take all of the validation results and write them to the screen for the user to see.

That’s really all there is to saving a bunch of data to the database. You might be wondering: What fields were actually saved? That all depends on what you put on the form.

The Form class is a “user interface” class, which means that a large number of it’s methods actually return xhtml. As you can imagine, methods on the form object would include things like:

// This code would likely appear in a view 
// that gets rendered when $this->Render() 
// is called in the example above.
echo $this->Form->Open($FormOptionsArray);
echo $this->Form->Errors();
echo $this->Form->TextInput('Title');
echo $this->Form->TextBox('Body');
echo $this->Form->Close('Save');

In this example, you can see I’ve referenced two fields on the Model that is being manipulated: Title and Body. When the form’s “Save” method is called above (and the Model’s “Save” method is called therein), the model validates and attempts to save the data. If one of these two fields were required, it would return a validation result that would then be written to the screen by $this->Form->Errors(). Furthermore, if there were a field on the “Blog” table that were required and not present on this form, it would have a validation result for that as well.

What if we were editing a blog post instead of creating a new one?

public function Edit($BlogID = '') {
   $Validation = new Validation();
   $BlogModel = new Model('Blog', $Validation);
   // Load the blog being edited
   $Blog = $BlogModel
      ->GetWhere(array('BlogID' => $BlogID))
   // Set the BlogModel on the form.
   // Make sure the form knows which item we are editing.
   $this->Form->AddHidden('BlogID', $BlogID);

   // If the form has NOT been posted back...
   if ($this->Form->AuthenticatedPostBack() === FALSE) {
      // Set the blog on the form
   } else {
      // Attempt to save the form values
      $BlogID = $this->Form->Save();

      // If it saved, redirect to the new entry:
      if ($BlogID !== FALSE)

   // Render the form

I load the blog and set it’s data onto the form using $this->Form->SetData(). At that point the form takes over and knows to either (a) render the existing data if the form has not been posted back, or (b) render the postback data otherwise. And since I added the BlogID to the form’s hidden field collection, the model will know that it should update a blog row instead of insert a new one.


That’s a lot to swallow in one big gulp. For that reason, I’ve really only shown you the most basic of examples. Of course there are times when a new Model(‘TableName’) isn’t going to handle everything you need. In those cases you can create your own custom model class that extends the base Model class and delivers all of your custom methods and functionality. Furthermore, you don’t have to be tied to the form object so closely if you don’t want to. You can always pull back and handle all of your validations directly with the model. You can also create new custom validation rules that the validation object can apply to fields for more non-generic data validation.


At this point I’ve covered a lot of the core functionality. If you have any requests for things you’d like me to elaborate on, or other parts of the framework you are interested in hearing about, please let me know. Otherwise, I’ll move on to ajax next.

Office Fun

Saturday, March 15th, 2008

I remember what it was like to work in an office with other humans. Kind of. It’s been a long time. I do remember having a lot of fun in-between accomplishing daunting tasks. Anyway, I was using my new favourite website the other day (vimeo: seriously, it is a pleasure to use; designed beautifully; awesome community; great forum!) and I stumbled across a bunch of videos by Jake and Amir. These are two guys that work at and make funny videos.

Chips from Amir on Vimeo.

I Remember…

Thursday, December 6th, 2007

When I was very young I used to compete in singing competitions. The kind of thing where parents gather together in a gymnasium and watch their children embarrass themselves singing along with an old woman playing piano because … well, it’s cute.

I used to win these competitions quite often (a fine little eunuch, I was), but the number of parents gathering to watch made me very nervous. I was a tiny little kid standing in front of a silent audience of one hundred adults waiting to hear how badly I’m going to mess up. My mother told me that I should just look above the heads of the audience so it appears as though I’m looking at them, but I’m actually looking at their hair – this way it wouldn’t feel like they’re all staring back at me. Instead, when it came time to perform, I remember looking directly up at the rafters of the gymnasium. Everyone started laughing at me, and I thought they were just really enjoying it. I got so comfortable that I was rocking side to side getting right into the song – probably something like “I’m a bear called Jeremy”.

I won first place again that time, but I remember my mom skitting with laughter as she tried to explain to me that I was looking up too high.