Posted by Chuck Vose
Fri, 30 Oct 2009 20:22:00 GMT
Cross-posted at metaltoad.com: The Power of Yes
Of all the powerful words in any language assertion is in my opinion the absolute most powerful. With affermative language we are able to create trust, enact people’s will, and begin processes. Silly of course, to take one word to mean so much but I believe everyone can agree that when a client asks for something ‘yes’ should be the thing that jumps to your lips immediately, hopefully without qualification but at times you have to add on things like ‘and it will cost x’ or ’, now lets look at the plan and see how we can make this a reality’.
But this post isn’t about clients, it’s about our language and framework choices.
When I was new to programming I said no a lot. This was in part an aspect of my first language PHP, which was perhaps as immature as I was at the time. ‘No’ was probably my biggest buzzword, maybe followed by ‘can’t’ which I justified by saying that PHP couldn’t do it. Turns out I was wrong, PHP really can do almost anything, but at the time I couldn’t. But ‘No’ was certainly an artifact of the culture. The things I do in PHP are often much harder than they need to be, at least they feel unnecessarily difficult to me now, and in this environment it is easy to say that it’s to hard. I’ve noticed since starting to use PHP again I’ve noticed ‘can’t’ creeping into my language more and more.
Ruby was the first language that was strongly oriented towards ‘yes’ both in the language and the culture. It could have been that I learned later in life or in a place that had a very strong Ruby culture (Seattle), but I suspect that the language had more to do with it than anything else. Ruby positively wants to make things faster for you so that the time between your thought and your expression of said thought grows shorter and shorter as you learn more Ruby. As such, when your language is saying ‘yes’ so often you naturally begin to start thinking this way yourself.
Drupal was a bit of a revelation to me in this regard. Drupal, as everyone knows, is a PHP app, yet despite the underlying language constructs the ui says ‘yes’ even more often than Ruby does. As my coworker pointed out, the amount of a website that gets finished before you hit the code is absolutely staggering. Maybe 90% of any given Drupal website could be accomplished by Drupal using only CCK/Views (et al) with the rest of the customizations being fairly quick using the copious APIs available to us. This is assuming that you find the correct project, in all things of course selecting the best tool for the job yields the best results.
So what are your languages saying to you every day? As products of our surroundings it is absolutely critical that we evaluate what our languages and tools say to us no just what they say about us. PHP may have a stigma, and Drupal through association, but I believe that the way it works with us is a much stronger reason to invest in exploring Drupal.
Posted in Ruby, Programming | Tags can, client, drupal, languages, Ruby, t, yes | no comments
Posted by Chuck Vose
Fri, 02 Oct 2009 16:57:00 GMT
Cross-posted at company blog: http://metaltoad.com/blog/multiple-dynamic-tabs-brightcove-3
This week I had the wonderful opportunity to work on an interesting problem that as far as I can tell hasn’t been documented. The call came out that we needed to generate a couple dynamic tabs on the top of our player for smart playlists. Now, we already have one dynamic playlist so I thought it was going to be a fairly simple logical step up to three but I was really, really wrong.
If you read issue 3 of the pragprog magazine you’re probably thinking a lot about parallel and asynchronous processing. So it was extremely exciting to have come to a parallelization problem in my day to day activities. I’ll explain the problem:
In order to load a playlist into a brightcove player with the Player API you have to have already fetched the videos from the server using getMediaCollectionAsynch, getMediaInGroupAsynch, or getMediaAsynch. With one dynamic tab it’s pretty easy to use getMediaInGroupAsynch because you can assume that the only time the MEDIA_COLLECTION_LOAD event is going to fire is when your call has returned. But when you’re loading up two or more media items asynchronously you can no longer make that assumption.
If you’re just pulling down pre-defined playlists it’s super easy to drop something like the following in your onMediaCollectionLoad listener:
function onMediaCollectionLoad (e) {
if (e.mediaCollection === null) {}
else {
tabBar.insertTabAt(e.mediaCollection, 0);
}
}
However if you’re using getMediaInGroupAsynch or getMediaAsynch it can be difficult to figure out why the listener is getting called. For us we had three playlists of dynamic data but outside of comparing the resulting array to the original array (inefficient and error-prone) there is no way of knowing which asynch call asked for these videos.
But maybe we don’t care. All we care about is that the videos are loaded completely when we insert the tabs into the player right? So we stop relying on order and just make sure that all the videos are loaded into the player before adding some tabs. To do this I maintained a request counter (which could be called a counting semaphone were you so inclined. Before each request I increment the counter and when the request is filled I decrement the counter. When the counter hits 0 I know that all requests have been filled and I can safely add all the tabs at once.
Your code could probably look something like this:
var tab_count = 0;
var popular_tab;
function onTemplateReady (e) {
tabBar = exp.getElementById("playlistTabs");
if (popular.length > 0) {
tab_count = tab_count + 1;
popular_tab = true;
content.getMediaInGroupAsynch(popular);
}
}
function onMediaCollectionLoad (e) {
if (e.mediaCollection === null) {
// Do nothing
}
else {
// Make sure that these playlists coming back are coming from
// getMediaInGroupAsynch. Otherwise their id would be positive.
if (e.mediaCollection.id < 0) {
// Add all media to the player's memory.
var mediaDTOs = new Array();
jQuery.each(e.mediaCollection.mediaIds, function(i, val) {
mediaDTOs.push(content.getMedia(val));
});
// Decrement the counter. When this hits zero we'll have filled all reqs.
tab_count = tab_count - 1;
if (tab_count == 0) {
// Make sure this is one of the playlists we were going to add.
if (popular_tab) {
popular_playlist = {
displayName: "Most Viewed Videos",
mediaIds: popular
};
tabBar.insertTabAt(content.createRuntimeMediaCollection(popular_playlist, 'playlist'), 0);
}
}
}
}
}
Here’s hoping this helps you out in your quest for multi-tabbed players and managing asynchronous loading.
Posted in Brightcove, Programming | Tags asynchronous, brightcove, dynamic, jquery, parallel, processing, requests, tabs | no comments
