Slide

For about as long as my development team has been a number larger than one, I've been on a relatively steady "unit test" kick. With the product I've worked on for over a year gaining more than one cook in the kitchen, it became time to start both writing tests to prevent basic regressions (and save our QA team tedious hours of blackbox testing), but also to automate those tests in order to quickly spot issues.

While I've been on this pretty steadily lately, I'm proud to say that automated testing was one of my first pet projects at Slide. If you ever crack into the Slide corporate network you can find my workstation under the name "ccnet" which is short for Cruise Control.NET, my first failed attempt at getting automated testing going on our now defunct Windows desktop client. As our development focus shifted away from desktop applications to social applications the ability to reliably test those systems plummeted; accordingly our test suite for these applications became paltry at best. As the organization started to scale, this simply could not stand much longer else we might not be able to efficiently push stable releases on a near-nightly schedule. As we've started to back-fill tests (test-after development?) the need to automate these tests has arisen to which I started digging aronud for something less painful to deal with than Cruise Control, enter Hudson.

For the past two months I've been experimenting with varying levels of success with Git inside of Slide, Inc.. Currently Slide makes use of Subversion and relies heavily on branches in Subversion for everything from project specific branches to release branches (branches that can live anywhere from under 12 hours to three weeks). There are plenty of other blog posts about the pitfalls of branching in Subversion that I won't go into here, suffice to say, it is...sub-par. Below is a rough diagram of our general current workflow with Subversion (I've had some other developers ask me "why don't you just work in trunk?" to which I usually wax poetic about the chaos of trunk when any project gets over 5 active developers (Slide engineering is somewhere between 30-50 engineers)).

• There's always a catch
• Subversion at Slide
• Toying with Git
• Git at Slide

A while ago I jotted down about seven or so ideas of stuff that I thought would make good blog posts, somehow "markup parsers in Python" is next on the list, so I might as well spill the beans on how incredibly easy it is to process (X)HTML with Python and a little built in class called HTMLParser.

There have been a few occasions when I needed a quick (and dirty) way to perform transforms on some chunk of HTML or merely "search and replace" parts of it. While it might be cleaner to do something with XSLT or the likes, using them doesn't even begin to match the speed of development of an HTMLParser-based class in Python.

Getting Started
One major thing to keep in mind when working with HTMLParser, especially if you're newer to Python, is that it is what's referred to as an "old styled" object, meaning subclassing it is a bit different than "new styled" classes. Since HTMLParser is an old-styled object, any time you'd want to call a super-class defined method you would need to perform HTMLParser.superMethod(arg) instead of super(SubHTMLParser, self).superMethod(arg)


Creating the HTML parser
For the purposes of this example, I want something simple, so we're just going to take a block of markup and "tweak" all the <a> tags within it to be "sad" (whereas "sad" means they'll be bold, blue, and blinkey). The actual code to do so is only 50 lines long and is as follows:

import HTMLParser
 
class SadHTML(HTMLParser.HTMLParser):
    '''A simple HTML transform-class based upon HTMLParser.  All links shall be bold, blue and blinky :('''
 
    def __init__(self, *args, **kwargs):
        HTMLParser.HTMLParser.__init__(self)
        self.stack = []

It's so easy to get caught up in the flurry of things going on here in Silicon Valley (not to mention just at Slide), but I figured that Hi5 deserved being mentioned. I'd like to congratulate Lou, Anil, Paul, Zack and the rest of the Hi5 Platform team on being (from what I can tell) the first social network to turn their OpenSocial-based platform on 100% to users. As of last friday they finally ramped up to 100%, meaning every user on Hi5 can add OpenSocial applications that have been approved and added to the Hi5 applications gallery.

The past couple weeks I've been lurking on the #Hi5dev channel on Freenode, where most of the Hi5 team has been as well, dutifully answering questions and getting general developer feedback. I highly recommend following their developer blog where Lou (pictured here) has been posting regular updates and all the important things that you need to do in order to get your application viral, approved and reaching Hi5's users.

Some of the applications we've launched include: Top Friends, Slide TV and SuperPoke. Of course, if all you want to do on Hi5 is be friends with me, you can find me here :).

Overall the OpenSocial/Hi5 platform has been an interesting experience, moving more of the application into the realm of JavaScript as opposed to what I've become used to on the Facebook platform has made me think harder about the separation of front-end code from back-end code and where you actually draw the line when both are written in the same language. One down, only two to go!

Since I've come from the land of desktop application development, there are a few concepts that I don't think quite "made the voyage" from desktop/thick-client development to web/thin-client development. The concept of "data binding" is completely lost in my opinion in the land of Javascript and HTML (not to mention the concept of "controls" to begin with).A few weeks ago while exploring a couple other concepts for how to improve our overall frontend development at Slide I prototyped a means of "databinding" controls, or at the very least DOM elements to data-providing Javascript functions.

I've posted an example here of some of the data binding code I've written for experimentation purposes. In the example page linked, there is a <ul> tag that is "bound" to a Javascript function, the Javascript function creates an array of associative arrays inline (it could very well be powered by some AJAX-oriented Javascript with minor adjustments). Using the results of the "databind" function specified on the bindable element, it creates a set of child nodes to attach to the parent list. In effect, the following code:

<script type="text/javascript">
    var bindSimpleList = function() {
        var simple_list = new Array();
        simple_list.push({'contents' : 'List Item #1 OMG', 'onclick' : function() { alert("You clicked the first list item! lulz"); }});
        simple_list.push({'contents' : 'List Item #2', 'style' : 'border-bottom: 1px dashed red; width: 100px;'});
        simple_list.push({'contents' : '<strong>List Item #3</strong>'});
        return simple_list;
    }
</script>
<ul class="bindable" databind="bindSimpleList" databindto="li"</ul>
</ul>

<ul class="bindable" databind="bindSimpleList" databindto="li">
    <li onclick="alert('You clicked the first list item! lulz');">List Item #1 OMG</li>
    <li style="border-bottom: 1px dashed red; width: 100px;">List Item #2</li>
    <li><strong>List Item #3</strong></li>
</ul>

Since the code is relatively simple (in my opinion) I figured I would throw it out there in all it's minimalistic glory and get some general feedback on the concept before I go "all out" and create a full-on jQuery extension based off of the linked prototype above. I'm trying to think of ways to make it more powerful as well, built-in support for binding to the results of an asynchrounous call to a URL that returns JSON that would then create the elements is at the top of my TODO list at this point. Feedback, flames and actual useful critiques are all welcome; I'll be sure to post again once I have the time to create the jQuery extension for binding, this however is more experimental quality (i.e. don't use it, i'm not).

What do you think?

I've been doing work with OpenSocial recently and have used the opportunity to bring my tolerance talent in Javascript up a notch or two. In doing so, I've been slowly but surely running into a myriad of browser-specific quirks along with a few cross-browser gems that have left me thinking about putting some browser developers on my "To Anonymously Beat Up In Alleyway" list (so far, James Gosling, and this man top the list).

After working on a few "classes" tonight (the notion that Javascript is object-oriented still makes me chuckle) I ran into an interesting problem with some of my global-level "constants" defined in the same file that I was working in, that my "class" just so happened to make use of. As I tend to do when I fall into situations like this to where I can't tell if I'm hallucinating or if something with Javascript has gone awry, I called over Sergio (in-house CSS master and Javascript Lvl. 60 Mage).

Some background to how Javascript works
Javascript engines essentially have two "modes" that it runs over your code that you can spot errors in. The first mode, "parsing", is where you'll find syntax errors spewing into the Javascript console. If you've used any interpreted language before (Python, Java, C#, Ruby), this is really just "compilation". Using Python as an example, when you import a module (i.e. import some_module) the Python interpreter actually compiles your code into Python byte-code to be executed at a later date. The second mode, "execution", is where you'll run into your run-time errors, using an accessing an undefined object property, overrunning an array index, etc. In Python/Java terms, this is where your compiled byte-code is actually being run in the Python/Java virtual machine.

The gripe
The crux of the problem comes down to two different ways to declare an associative array in Javascript, the following two notations are both correct and both "work":
Notation #1

var mapped_values = {};
mapped_values['key'] = 'value';

var mapped_values = {'key' : 'value'};

It's been almost a whole entire week since I left Austin, but it certainly seems better late than never.

So far this month I've been fortunate enough to have been invited to speak at a few events, and one or two I just happened to wedge myself into anyways.

I spoke at Graphing Social Patterns West in San Diego the first week in March on a concept I feel I didn't have the time to really explain sufficiently, "Social Portability" (pdf). Unfortunately most of the audience weren't developers, so I adjusted the presentation to shoot a bit higher level than usual.

Following GSP I spoke at BarCamp Austin 3 on building ASP.NET sites on top of the Mono stack (pdf). The session was relatively small, so it broke down into much more of a round table discussion (we were sitting at a literal round table) about some of our experiences with ASP.NET on Mono through Apache2/mod_mono and Lighttpd/Mono-FastCGI, etc.

Also while at SXSW I spoke at the Facebook Developer Garage Austin on the same concept as before, Social Portability, except this time the audience was far more developer oriented so I could dive into some nitty gritty bits of FBML/FBJS caveats, etc ((pdf). The Developer Garage was especially fun because the Zuckerborg was in attendance, and I met more than my fair share of interesting developer-types that were either Texans themselves, or in Texas for the event.

March is barely half over and I'm already exhausted.

Presentation Files
Social Portability.pdf (GSP)
Social Portability (Developer Garage).pdf
ASP.NET on Mono.pdf (BarCamp)

I'm not yet certain what kind of audience is going to be attending Graphing Social Patterns West, so I'm hoping I can help tip the scales in favor of developers because, to be frank, business people scare me.

I was told about AppNite and it seems like a good excuse to try to get more developers to make the trek down to San Diego to keep me company in a sea of marketers and business folk. Better yet, developers who enter the AppNite contests get 50% off the admission to the conference (enter here). Unfortunately I'm not going to enter my apps in the contest, but I do know a friend of mine Jason Rubenstein, of Just Three Words fame, has entered his app, to give you an idea of the stiff competition you'll be up against.

If that doesn't seal the deal for you, Virgin America flies to San Diego now, and round-trip flights from San Francisco to San Diego are only ~$85. Which means if you're a Silicon Valley Facebook/Bebo/OpenSocial developer you can come hang out at the conference for cheap, and if your application is good enough, get some killer exposure to potential investors, business contacts, and other developers (like me!).

Zach Allia (of Free Gifts fame), Jason Rubenstein (Just Three Words), Ryan Romanchuk (Dipity) as well as the developers on the speakers list will all be there, so it should be a fun meeting of the minds (for developers at least).

See you there!

For the past couple weeks I've been living dangerously, as some people know I live in the Tenderloin District, but that's not what I mean when I say "living dangerously." In my constant quest to squeeze as much performance out of Top Friends as possible, I've been evaluating the latest and greatest stuff that Facebook has to offer developers. In addition to the usual adding of features, tuning virality, and general application upkeep, I've been exploring mixes of FBML, FBJS, Mock AJAX, preload FQL, and batched queries all as a means to improve how fast Top Friends is for our users. I've been saying for months that it's exceptionally important to keep up with all of Facebook's changes, for better or for worse, and sometimes they throw out gems like preload FQL that will help shape new and interesting ways you can utilize Facebook's data inside your application.

The Feature
The first obvious thing that I wanted to apply preload FQL to, was a new feature we've pushed out called "Top Friends News" which aggregates "what's going on" with your Top Friends.

Coming up in the first week of March you'll be able to find me doing one of my three favorite things (right behind, writing code and sleeping), I'll be talking, in front of people, about Facebook, Bebo and "social applications." If you are one of the four people that have gone on record has having actually subscribed to my RSS feed, you might know that I spoke at something called "Graphing Social" in the past, but this time I'm speaking at "Graphing Social Patterns West" which will be occurring in parallel to O'Reilly's "ETech (Emerging Technology) Conference)" in San Diego March 3rd and 4th.

I'll be talking briefly, in front of people, on tuesday March 4th about during a joint session on "Social App Development 101: Elements of Style," where I'll be discussing some of keystone pieces of building an application that "pops" on Facebook and Bebo, and designing for portability, etc. My session is going to be brief, so I will most likely be employing my crouching-ninja-presentation technique, where the slides rotate every quarter-second at such a fast pace that the content becomes melded into my audiences' subconscious. It's been rumored to cause brain hemorrhaging, but that's nothing but an urban legend, I promise.

In general the entire event should be lots of fun; I'm looking forward to schmoozing with the speakers lined up for the event, as well the time-honored tradition at O'Reilly conferences, playing a good old game of "Find Tim and tickle him until he pees himself."

Overall the combination of GSP West and ETech looks like it's going to make for an interesting couple of days in San Diego, go ahead and register now to make sure you can get in.

I am starting to see more and more novice developers on the Facebook forums as well as the IRC channel asking fewer and fewer "development" questions and more and more "product" questions. I find this incredibly interesting because it means one of two things: either everybody has figured out how to use the Facebook platform or an increasing number of people are putting the proverbial cart before the horse when it comes to developing Facebook applications.

Call me cynical about the first option, but I find it highly unlikely that everybody figured out how to use the Facebook Platform; despite its low entry barrier many people are over-thinking it or simply trying to develop a Facebook application before they figure out how to build a web application in general.

The second option is far more likely, Facebook applications have reached such a level of ubiquity that "everybody and their mother" wants to write a Facebook application these days. Right now at a small consulting firm in Omaha, Nebraska some middle manager is asking his lead developer if the firm can reinvigorate their collaborative synergies and utilize the social graph to further meet their clients needs.

Facebook is the new Windows, and the Facebook Platform is the new Visual Basic and I feel as if there is a burden on "us" (the existing "top developers" on the platform) to start to cultivate a community that will encourage stylish, functional and ultimately useful applications on the Facebook platform, to ensure that there will never be a "Facebook 98" or a "Facebook ME".

Here's a couple of the best tips I can offer, and maybe Zach (developer of Free Gifts) can help expand.

We've been working pretty hard for the past month (well, for the past 8 months too) but I'm particularly proud of the work that my co-conspirator and I have been putting in on Top Friends (we're that green line that creeps up from behind on FunWall and Super Wall).

One of the most helpful "tools" that's been available to me has been Slide's competitive spirit. In addition to the 2,000+ developers on the Facebook platform we have some pretty healthy competition going on inside Slide as well. Between Top Friends, SuperPoke and FunWall there is plenty of trash-talking and "friendly competition" (read: if it weren't an HR violation, I'd of already resolved to dirty tactics). In doing so we've cultivated an environment where some of the most often heard phrases are: "Is Facebook down again?!" and "OH SCHNAP!"

It was recently announced that Slide (this little start-up that I work for) raised some more money. Neato.


Since Max isn't the aeron chair kind of CEO, it looks like we're going to spend that money on things like "engineers, hardware, etc." Bummer, I've always wondered how an $800 chair can exist that doesn't rub your feet and write your code for you.

Regardless, should be a fun year.

(p.s. we need more engineers)

I spoke with Tammy (our PR mastermind) about whether or not Slide was going to let me out of my cage to go to South by Southwest Interactive this coming March and it seems like they might actually let me! (I'm just as surprised as you are)

Unfortunately things with Facebook were at such a ridiculous pace when SXSWi was accepting panel submissions, that I never got a chance to submit my panel idea: "Slide is awesome, now let's talk about how great Slide is." This leaves me in a slightly awkward position, I cannot remember the last conference or event that I went to where I wasn't speaking or talking or dancing with a baboon in front of a live studio audience. Even at the last SXSWi I was there for about 36 hours and most of that time was spent setting up and then helping run BarCamp Austin². Ideally I'd like to get on stage with some of the guys from Twitter, Facebook, Bebo, Google and maybe even Myspace to discuss the more open social web that we seem to be moving towards and a bit about how awesome Slide is. It's probably nothing more than a pipe-dream however, since the panels seem to be quite locked down at the moment.

Of course, if nobody will have me, then I might be relegated to slumming up and down 6th street in Austin hanging out with the usual drunkards that I know in Austin (you know who you are) and getting into trouble. Mmm, trouble.

Regardless, if you're going to be in Austin for SXSWi let me know, I've got a stack of swanky new business cards I want to get rid of :)

Sergio, one of our talented web monkeys, sent an email out today that started with "OMFGBBQ!"

As it turns out, Sergio is a much more religious reader of Penny Arcade than the rest of us (a public shaming and revocation of some geek cards is in order) since he was the first to notice this:

Click to view the image fullsize