RedBeanPHP an amazing ORM

I want to share a little bit about my experience with a library called RedBeanPHP, since it's been a completely transformational tool for me in the prototyping process (and in fact, was a big contributor to the app that my teammate and I built at AngelHack NY, which we ended up winning).

So, here's the general idea.  In the prototyping process, no matter how much you plan ahead, it's fairly likely that you will want to add a DB column or change the values you were planning on storing.  This generally means having to do a few things:

• Add a script to alter the existing schema
• Make changes to a central script that builds your DB from scratch (in case you need to recreate it on a new DB instance).
• Deal with backwards compatibility/consistency issues

When you're prototyping, this is incredibly distracting and annoying (especially if you are like me and you just want to push a version out to start measuring usage).  Enter RedBean.  Redbean is an ORM just like any other with a little trick up its sleeve- it alters the schema to accommodate whatever values you want to assign to a given object type on the fly.  So let's take the following examples:

• Let's say I set foo.name = 1.
• Redbean might set the schema for column 'name' to be a TINYINT
• Let's say I then set foo.name = 1234
• Redbean might set the schema for 'name' to be an INT
• Let's say I then set foo.name = 'abcdefg'.
• Redbean might set the schema for 'name' to be VARCHAR(250).

It gets better though.  While it builds your schema, you're free to mess with your DB as much as you want behind the scenes (change schema, add indexes, etc) and redbean will still cooperate.  And once you're happy with the DB, you push to production and you want to make sure RedBean doesn't alter your schema, you add one line of code to the top of your PHP script to ensure that doesn't happen ('R::freeze()').  After that, if the DB is unhappy with what you're sending it, Redbean will just work as an ORM solution and pass back the error if the DB is unhappy with a given query.

Beyond that, check out the site.  The syntax is beautifully simple to understand and it's my ORM of choice at this point.

Jquery Mobile

Jquery Mobile is simply amazing.  If you haven't used it before, check out the demos/docs here.  Here's why you want to use it:

• It's HTML5.  This means that it will not only work as a mobile application site but it is directly portable to native apps on iphone, android, blackberry, etc through the PhoneGap framework (I'll write more on that at a later time).
• It comes with all of the basic widgets that you would expect any mobile app to have.  Pretty much nothing required from you except to embed the html5 tags.
• It is easier to build than a normal website.  This is because the structure of the framework is that you create every view of the application on a single html document.  This means that you have one document as the source of truth for pretty much everything, and if you get lazy (as I do, to my disappointment) and put all of your code in that document, there are no dependencies to worry about later.

Here are the key things to pay attention to, that took me a little while to get a hang of:

• Since you have multiple views (each treated as it's own 'site'), using $.(document).ready doesn't work the same.  The code loaded in that view gets loaded as soon as the entire html document is loaded to the page- NOT WHEN ANY SINGLE VIEW IS LOADED.  To have some JS executed when a view loads, you bind to the following events:
• $(document).delegate("#my_patients_view", "pageinit", function(){ //Your code here});
• This will execute your JS code when the view is initialized for the first time (ie: first time the homepage view is shown
• $(document).delegate("#my_patients_view", "pageshow", function(){ //Your code here});
• This will execute every single time the view is shown
• This is an important distinction because if you do event binding in this block of code, you will attach bind multiple event handlers to an item, which can give you trouble down the line
• Ex: You bind a click event to a button in a given view.  If the view is loaded twice, the second time you click the button it will issue 2 separate ajax call instead of one.

Seriously though, this is amazing.  Love everything about it.  Please use it.

Installing Localtunnel on Mac OSX

Localtunnel is a nifty little application that allows you to share your local webserver with the outside world.  The flow is pretty simple:

• Run your local webserver
• Localtunnel spits out a URL for you (ie: 'http://localtunnel.com/abcdefg')
• Share the localtunnel URL with anyone and they should be able to access your 'localhost' remotely over the web, as long as localtunnel continues to run in the background.

This is ideal for sharing quick demos/prototypes.  It is not a good temporary hosting solution because localtunnel shuts you out after ~20 mins if the service is not actively used.  

Installing this *should* be pretty easy but about a million posts online show that there is a little hidden step that makes this 10 minute process take 2 hours to figure out:

• You need ruby to install localtunnel according to their documentation:
• Download XCode through the app store
• Open XCode:
• Navigate to XCode ->Preferences->Downloads
• Install 'Command Line Tools'
• Open up terminal and run 'sudo gem install localtunnel'
• run 'localtunnel 80'.  You should get a message saying 'Failed to authenticate.'  To get around this, you need to upload a public key.
• Make sure you have a public key
• Run 'cd ~/.ssh'
• If the directory doesn't exist, created it by running 'mkdir ~/.ssh' and navigate into it by running 'cd ~/.ssh'
• If you do not have a private/public key pair (ie: id_rsa), create one by running 'ssh-keygen -t rsa -b 4096'
• Run 'localtunnel -k ~/.ssh/id_rsa.pub 80' and enter your passphrase.
• The service should now be running.  Take the url displayed and type it in your browser; you should be taken directly to your localhost index page.

Installing MySQL on OSX Lion

Setting up your dev environment can be a b*itch-and-a-half.  There are dozens of StackExchange articles about installing each tool/framework, but people change their setup so frequently that it's hard to tell which dependencies they have that you don't.  For my own benefit, I've decided to document how I set up my own system after a clean install of Mac OSX Lion, so all dependencies are accurately captured.  Hope this is of use to someone else as well.

Quick tips to set up MySQL on your intel Mac OSX Lion machine

• Download the MySQL .dmg file here
• Within the .dmg file:
• Run the large MySQL .pkg file
• Run the MySQLStartupItem.pkg file
• Run MySQL.pref_Pane
• Active MySQL server
• If you don't want to deal with this again, select the option to automatically start MySQL when your computer boots

Now, run the following commands in terminal

• Add mysql to your PATH
• Run 'sudo nano -S /etc/profile'
• Add the line 'export PATH=$PATH:/usr/local/mysql/bin' and save changes
• Open a new Terminal window for changes to take effect
• Enable a root password for your DB
• Run 'mysqladmin -u root password', where 'password' is your secure DB password.
• Run 'mysql -u root -p'.  You should now have command-line access to your local MySQL DB.

A Company's (First) Tipping Point

I like to think of the first sale as being the first major tipping point for a startup. It is the hardest sale to make, since little is known about the product's efficacy or the company's stability in the marketplace. This is a classic lemon problem, where information asymmetry between the seller and the market result in a breakdown of trust and propensity to buy at fair price. Overcoming this inertia is extremely difficult but there are very clever ways to overcome this by creating strong positive signals in the marketplace. The following (true) story, shared by Dr. Macmillan at Wharton, is a great example of this:

A salesman came to pitch an industrial plant manager on an innovative new water filter. The filter was twice as expensive as the next best alternative but lasted 5 times longer with the same efficacy. The investment would have justified itself but he did not make the purchase, because he had to somehow justify why his expenses had risen in the quarter to the company before any ROI from the purchase was evident. Having gotten this response, the salesman went to one of Proctor and Gamble's factories and gave the filter away for free. In doing so, he created an invoice and had it signed on delivery by the company. He then went back to the manager and showed a signed delivery slip (not showing that it was actually given for free). The fact that a major multinational had implemented the technology was all the manager needed to justify the expense to his bosses so he purchased the new filter product.

This is just one great example of how one can leverage the trusted/positive image of a client and create a strong signal in the marketplace that inspires confidence in the company and product. The key here was that the manager thought that P&G had puts its trust in the product by purchasing it, signaling to him that it was indeed a good investment (whether this is withholding or clever positioning may be debatable, but the signaling effect is clear). Over the years, I have seen both good and bad signaling strategies.

Good ways to signal the market:

• Get a customer with a strong reputation in the marketplace. If you work with a company that is known to have very high standards in their business relationships, you will benefit from this. This could also be the case with an adviser or investor who has a strong reputation.
  
• Set up free trial periods. This will signal your confidence in your product by shifting the risk to you, while still not making the client's purchase totally 'free'.
• Make use of great PR. There seems to be a positive signaling effect in peoples' minds from reading about a product in a reputable source (ie: "as seen in the NY Times").
• Collect data. Lots and lots of data. Try to get the study conducted/verified by an independent source. Show where the product works best and where it is least effective (this will show you are transparent and not only showing the positive data).
  

Bad ways to signal the market:

• Sign up early customers for free. While this can be great for collecting data, it does not say much about whether the counter party actually sees the value of your business. Anybody will try something if it's free. When you pitch the next company, it really does not send any valuable signal.
  
• Working to get 'the wrong' early customers who do not help you 'signal' your product's value to your target customer base. For example, if your target is a Tier 1 company do not waste too much time going after Tier 3 companies. This may in fact create a negative signal (ie: Tier 3 companies use this product).
  

These are just a few examples that come to mind from my last startup. Obviously there are cases where these rules will not apply but in general I think this is a decent framework.

Under the Googview Hood

I recently made an update to Googview, my first web project. The new functionality automatically updates the Googview background to current Bing search backgrounds from around the globe. This exposed me to a few new web technologies that I thought I would share here.

Search Functionality:

• Made using Google Custom Search Engine. This tools has a wizard that makes it very simple to create custom Google search tools.

Bing Images:

• Images are taken from Bing's global sites and put into an RSS feed by Long Zheng at istartedsomething.com
• This feed goes into Yahoo Pipes and is modified to make the media asset URL the 'title' of each item.
• A simple PHP script on the Googview page runs on load, takes in the Yahoo Pipes feed using MagpieRSS, parses the media asset url and writes it down to the page as HTML.
  

The Power of Instant Gratification

Today I was thinking about what it was in the fundamental design of web apps like Twitter, Facebook and Zynga that made them so successful in acquiring and keeping users (causing enormous changes in online behavior).

I was reminded of an analysis that I did for a large social gaming company as part of their recruiting process. They asked me to play one of their Maffia games and determine what features were driving 'virality'. At first, I had absolutely no idea how the game had become so popular. The GUI was limited to having a user click a handful of buttons that would instantly give them points and 'virtual goods'. There was no story-line, no mental challenge, no advanced visualization; just an instant reward for performing a simple action (for example, to rob a store, one would just click 'Commit Robery', and instantly see an increase in wealth points without any chance of failure). It was the equivalent of flipping a series of light switches on and off and getting some psychological reward for it. "Strange" I thought...

After playing for an hour however, I was rather surprised. I had progressed quite far in the game and started to enjoy it. I'd built a mini 'empire' and had no idea how I'd gotten there. Each click had given me some slight enjoyment and they had magically added up to an hour of gameplay. Furthermore the game kept kicking me off every time I made progress so I never got to the point where I was bored of it.

Instant Gratification (aka the Bon Bon Theory)
My theory on what has made web apps is that they deliver instant gratification in limited doses. In the game described above, I felt instant utility through building my collection of virtual goods. The game design allowed me to instantly enjoy small doses of pleasure, while forcing me to come back later for more. In the case of twitter and Facebook, we are gratified by the emotional value of seeing a constant stream of information from those we value most. Once again, this utility is enjoyed over time as updates/tweets trickle in small doses throughout the day.

I call this the Bon Bon Theory because it reminds me of how quickly one goes through little wrapped sweets when they are lying around the house. They are just the right size to give you instant satisfaction but never sizable enough to satisfy a craving (and the solution is always simple-- you just go back).

This is an extremely powerful concept and should be considered key when looking at future web services as we become more and more connected (since being 'always on' makes it easier to administer each 'dose' of utility).