Wednesday, November 21, 2012

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.


Monday, November 19, 2012

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.