Maggie Nelson

Finally found some footage of the Inner Join / Outer Join database song Craig Campbell and I created for the Schematic Tech Summit in September 2008! (The contribution was: lyrics about 50/50 and 100% of music is original and written by Craig.)

Link to the footage: Inner Join / Outer Join

And the lyrics:

Craig: “Hey Maggie, I think this song’s going to be in A major…”
Maggie “Major?! but I just met’er!”

inner join outer join
do you really know the difference?
inner join outer join
a null could ruin your existence

it doesn’t matter which you choose
whichever database you use
oracle, mysql [and postgres!]
i’ve got a story i should tell
about inner and outer joins

CHORUS

do those phrases sound like gibberish
like bubbles from a talking fish?
or german or italian
or japanese or french or dutch
or maybe klingon?

CHORUS

focus on integrity
and your database will feel pretty
do you want an epic fail
or do you want your app to scale
and reach to Jupiter

where aliens can run queries
to make sure you have your foreign keys
have your ON DELETE CASCADE
relations come to aid!
your world is normalized

CHORUS x 2

Schematic gave me some props for speaking at the NYSE panel I mentioned earlier:

Thanks for the reference!

CouchDB has infected me and I’ve been reading a lot about alternative ways to store data AND organize it. In the midst of options for alternatives to relational databases, these two stand out:

Cassandra – “Cassandra is a highly scalable, eventually consistent, distributed, structured key-value store. Cassandra brings together the distributed systems technologies from Dynamo and the data model from Google’s BigTable. Like Dynamo, Cassandra is eventually consistent. Like BigTable, Cassandra provides a ColumnFamily-based data model richer than typical key/value systems.”

The huge appeal of Cassandra seems to be the approach to make it highly fault-tolerant. Writes never fail. Data is always available. No single point of failure. If you’re making a Twitter-like app, you should consider it.

Tokyo Cabinet – “Tokyo Cabinet uses hash algorithm to retrieve records. If a bucket array has sufficient number of elements, the time complexity of retrieval is “O(1)”. That is, time required for retrieving a record is constant, regardless of the scale of a database. It is also the same about storing and deleting. Collision of hash values is managed by separate chaining. Data structure of the chains is binary search tree. Even if a bucket array has unusually scarce elements, the time complexity of retrieval is “O(log n)”.”

Tokyo Cabinet is slightly newer and is apparently stupidly fast, faster than any other storage solutions out there (at least for now). It’s written in C and provided as API of C, Perl, Ruby, Java, and Lua.

Do you know anyone who has used these two already? Care to share your experiences?

As you may remember from my excited Twitter posts, I spoke on a panel organized by Rackspace at the New York Stock Exchange on June 17th. The audience of the panel was mostly composed of representatives from various NYC agencies that, basically, build cool websites for clients (Yours Truly’s employer included).

The panel topic was loosely defined and the conversation tended gravitate toward Twitter and Twitter-like applications. Why Twitter? It gained huge popularity, resulting in performance problems, often leading to the surfacing of the beloved Fail Whale. It also attracts some of the biggest buzzwords of Web 2.0: social networks, information architecture, folksonomy (hash tag anyone?). In the end, Twitter has piles and piles of data – a lot of it is noise, but there is a method to the madness. The panel talked about the possibilities other applications like it mean to the Internet and to future people-oriented business.

Among others, I shared the panel with Jonathan Bryce, the co-founder of Mosso.com, now rebranded to The Rackspace Cloud and Robert Scoble, a Twitterer and FriendFeeder Extraordinaire!

The Rackspace team took a video of the panel, so check it out! (Warning: pretty big .mov file.) I already <3'ed Rackspace, as many of you know, but just in case, big props to Adrianna Bustamante and her team for the efficient nerd-wrangling! (Although I still got to mention robot overlords in the panel!)

Oh, and as for the question: “How do we make money from Twitter?” The answer is “Nobody knows, and even if they did, they sure aren’t going to tell you for free!”

Yesterday I gave a talk at the php|tek 2009 Conference about the ORM in the PHP World. In the first part of the presentation, I’m focusing on what an ORM is, what would make a great ORM, design patters for ORM and tying ORM systems to the PHP world in terms of philosophy, uses and approaches. The second part of the presentation talks about a list of ORMs that I have seen and their pros and cons.

The ORMs I mention:

• Propel
• Doctrine
• dOrm
• Zend Framework – specifically the proposed Zend_Db_Mapper
• Xyster Framework
• CodeIgniter
• ez components’s Persistent Object and Persistent Mapping
• symfony
• PHPLinq
• Solar’s Solar_Sql_Model
• Outlet PHP ORM
• CoughPHP
• ORMer

I plan on talking about each of these ORMs in detail in separate blog posts, so stay tuned!