Deploying a Video Sitemap

If you've ever considered implementing a video sitemap, you''ve probably gone throught the same thought process we did. First, "what's a video sitemap?" then "should we have one?" followed by "how come these docs don't make much sense, and why does there seem to be no good information in a Google search?" We spent a while at Mahalo researching to try go figure out if this made sense to build or not. At some point in this process I came across a video which clinched the decision for me. It features Matt Cutts recommending, in no uncertain terms, that all video publisher build video sitemaps.

As a sidenote: If you're considering a video sitemap yourself, I would recommend devoting some time to watching this video from ReelSEO: http://www.reelseo.com/video-xml-sitemaps-video/. It answers a lot of questions that aren't in the documentation or any blog posts I found.

After some looking around, one question still in our minds was: "does all of this still make sense if our videos are hosted on YouTube?" Clearly Google has some sense that our videos exist, as the YouTube version shows up in searches. Yet Google may not be aware of it on the Mahalo.com page we've built for it. In a lot of cases, we believe that the Mahalo.com page is a more valuable experience for a user than simply viewing the video on YouTube, as we are able to provide some additional context to the video within Mahalo.com.

Here's a good example:

Searching for "how to play the chromatic scale on guitar" in google's search returns 3 video links at the top of the search. Two of them are Mahalo's videos on YouTube.

Watching these videos will get the user what they were searching for, but what would be awesome would be for that video link to point to this video on a Mahalo.com course page here: http://www.mahalo.com/learn-to-play-guitar-beginner-course/how-to-play-the-chromatic-scale-on-guitar/. It's good for the user and it's good for Mahalo.

So we built a video sitemap to see if we could start ranking for our videos on our site.

We launched last Thursday, and according to Google Webmaster Tools, the video section of our sitemap has been indexed. We seem to have no errors, and of the 1200 videos listed per page in the sitemap, somewhere between 600 and 1000 are supposedly in the index. I can't seem to find any in Google's video search though, so I'm not sure what's up. I know we do have a few videos which are missing some fields, but that wouldn't explain why none of our videos are showing up in Google's video search.

Hopefully this will resolve itself in the next week or so, but if anyone out there has any suggestions, I'd be happy to hear them. Please email me at jeff@mahalo.com.

Jacob Kaplan-Moss at Mahalo

This post is really late in coming. In trying to get Mahalo 4 launched on time, a few things got pushed off, so here I am trying to catch up.

Way back in November (I think), Jacob Kaplan-Moss visited the Django LA meetup at Mahalo and enlightened us regarding tools and practices for automating sysops.

Sorry for the dark videos, we tried to make the slides readable (with questionable success). The talk is still super interesting.

Part 1:

Part 2:

Part 3:

Part 4:

Part 5:

Part 6:

Tips.js - Lesson 1: For-in Caveats

JS has several different looping statements, many of which we know and love: for, while, and do-while. Now I know what you all are thinking: "But, Rich, JS is clearly sub-par to all of our more modern languages because it doesn't have a for-each statment". You are (in)correct. JS has a sort of for-each statement, which we like to call the for-in statement. Our friend for-in has the structure of for (var <key> in <object>). Recall that all objects in JS are basically key/value stores, so what this loop does is iterate through all of the runtime keys (properties that are bound to the object by your code) on the given object, so if you were to have an Object obj and you added the properties x, y, and z, the for-in loop would iterate through those keys x, y, and z.

Sounds good, but there's a problem. Recall that JS is a prototype-based object oriented language, meaning all objects have a prototype property which references another object from which it will inherit properties from, and that object will have a prototype to another object, etc. The problem with for-in statements is that they do not discriminate between properties of the object and properties of the object's prototype chain. Well, okay, it's not actually a problem as this is the ECMAScript standard behavior of the for-in statement. The problem is that few people are actually aware of this behavior.

If you crack open a firebug/chrome console, and try it out, you'll see that if you have an object foo whose prototype object is another object bar where foo has a property fizz and bar has a property buzz, then the following will happen:

var foo = { fizz: 'asdf' };
var bar = { buzz: 'qwerty' };

foo.__proto__ = bar;

for (var x in foo) {
    console.log(x); //prints "fizz" and "buzz"
}

[Disclaimer: It's considered bad form to directly modify the __proto__ attribute of an object. This is just for demonstration purposes] You'll also notice that if you look at bar's prototype, you'll see the native/host JS Object, which has a bunch of properties that the for-in statement seems to ignore. For-in only cares about properties that are assigned at runtime, meaning any property we assign in our scripts, for example Array.prototype.someFunction = function() {};. There are several high-profile JS libraries that do things like this for a living (ever wonder why the Prototype JS library is called "Prototype"?). Now consider if you try using a for-in loop with an array. Arrays in JS are just objects. Do a console.dir on an Array object and you'll see that it is simply and object with keys that map to the index of the array data (the object's property of "0" is simply a reference to the zeroth index of the array, and this is why using array accessors [] work when you access object keys; there is really no difference in accessing an array index and accessing an object property). Because of this, doing a for-in statement on an array will iterate through all of the elements in your array as you would expect, but if you ever modify the Array object's prototype, that modification is considered a runtime modification and will be iterated in the for-in loop.

Bottom line is, if you never actually do any native/host object prototype modifications, you don't have to worry about this issue. I should also mention that several browsers support an ECMAScript 5 standard Object function called keys, which when called returns an array of all keys on the given object that completely disregards the prototype chain. This is basically a native way to do the following:

for (var x in foo) {
    if (foo.hasOwnProperty(x)) {
        console.log(x);
    }
}

I'm not a big fan of using the above method outside of native code, as the loop will still execute through all of the properties of the prototype chain with an added conditional execution to determine if the property belongs to foo, and if you don't really know how many runtime properties were added up the prototype chain, this has potential to be inefficient (but if you do actually know that you're not doing any native/host object prototype modifications, you can feel free to use for-in at your leisure. Just understand that it can come back and bite you later on down the line if you're not careful)

memcache-top patch to see curr_items

I stumbled upon memcache-top in the Homebrew Formula repository. It's a neat little Perl application that aggregate stats from a memcached cluster and displays it in a nice little table.

I like to use: memcache-top --servers='server1,server2,server3' --commands --sleep=1

My only qualm is it doesn't display the curr_items stat. So I wrote a little patch for v0.6 that will add an ITEMS column to the table.

Get the patch from the issue I filed.

MySQL 5.5 Homebrew Formula

I recently switched to a 27" iMac workstation running Snow Leopard from Ubuntu 10.10 (Maverick Meerkat). The resident Mac fanbois suggested Homebrew over Fink and MacPorts. At first I didn't heed their warnings and went with MacPorts (I do love the FreeBSD ports system of which MacPorts is based on). However, when it decided to start setting up its own environment I understood the warnings. So I scrapped that and went with Homebrew.

Small issue with Homebrew is it seems to want to stick to 'Stable' releases. I really didn't want to use MySQL 5.1 since it's a snail compared to MySQL 5.5. Not having an ultra-fast storage array in my iMac this would become an issue with all the work I have to do. So I set out into Ruby land and banged out my first Homebrew formula.

Read More...