Posted by Chuck Vose
Fri, 25 Sep 2009 20:49:00 GMT
Cross-posted from the Company Blog
In my experiences in the past working with external contractors is often a pain, especially the final merge where you try to incorporate all their code. I’ve always been a huge proponent of Subversion for SCM but today I saw an example where Git knocked the socks off of Subversion.
Time came and code needed to be merged into trunk. While discussing our options someone noticed that there was a .git file in the project directory and put the pieces together. While Subversion relies on a central repo Git has no such requirement and the contractor had included his git repo with the file which meant that we had his complete revision history available to us as well as an extremely easy method of applying diffs.
Normally merging was a pain but today we issued these commands, watched the output, then shared high-fives and a beer.
cd imported_files
git log
*write down the first couple chars of the SHA1 of the first commit
git diff --no-prefix {sha of first commit}..HEAD > patchfile
cd trunk
patch -p0 < ../imported_files/patchfile
Who knew it was going to be so easy!?
So the moral of the story: If you’re working with people that may not be in your office or you expect to get a tarball/zip of their work you could do no better than Git for version control. You get to see their complete history and work with it.
I’ll bet that someone out there smarter than myself actually knows how to replay the git commits so you can keep the revision history as well. Git is cool!
Note: Patch instructions based on these directions
Posted in Git, Programming | Tags contractors, git | no comments
Posted by Chuck Vose
Mon, 21 Sep 2009 21:55:00 GMT
Cross-posted to the company blog at: Fun with stakeout.rb
Having only left Rubyville a couple weeks ago there are still a lot of Ruby-based utilities that I still find incredibly handy. One such utility that I’ve recently fallen hopelessly in love with is stakeout.rb from: http://pragmaticautomation.com/cgi-bin/pragauto.cgi/Monitor/StakingOutFi…
Stakeout monitors your filestructure waiting for changes to happen and when they do it runs some command in the shell. Think about all the things you would like to happen when you change a file. Clear your cache? Refresh your browser via AppleScript? Run your PHPUnit tests? Program your Roomba vacuum to spin in a circle and sing for you? YES!
Take the code from the above webpage and drop it in a file called stakeout.rb. If you’re running Linux or OS X you probably already have Ruby. If you’re running windows I doubt the Ruby code would even work but do let me know if you do get it running and create a script for it.
After that simply run something like: ruby stakeout.rb ‘php drush.php clear cache’ sites/all/modules//
Now try editing and saving one of your module files. Success?
Rejoice!
Posted in Ruby, Drupal, Programming | Tags drupal, drush, Ruby, stakeout | 1 comment
Posted by Chuck Vose
Fri, 18 Sep 2009 22:19:00 GMT
Cross-posted to: Company blog version
Over the last two weeks I’ve been working on a project to convert one of our client’s websites to Brightcove 3 players. As I am quite new to drupal but not to PHP you can imagine that many of the problems I had were unrelated to brightcove itself but there were a few aspects that I thought were worth documenting for those who are in the (surprisingly) enviable position of doing this migration.
First off I want to mention how huge of an upgrade it was going between 2 and 3. It may not look like it from the player aspect, many of the players look largely the same, but the backend work was tremendous. In addition to creating a spectacular new studio for uploading media and creating playlists they redesigned the players to allow greater customization without having to build your own swf player. What’s best about the backend changes is that if you really want you can actually keep your v2 players and still use the updated studio to manage your media as well as using the updated Media API to directly query their database for content to display.
But what’s been crucial for us is the new Player API which allows us to use javascript to customize the actions of the player, load videos manually, and generally cause incredible ruckus without having to recompile the player itself.
To the point though, there is one mammoth gotcha in the upgrade between v2 and v3: if you’re specifying videos via the params (ie: almost every one of us) videos, the playlists they’re in, and the player both are in, must be from the same account. Additionally, videos must belong to the playlist that’s currently loaded as well or it just will ignore your selection.
Before I believe it was a little loosey goosey about where things came from but now there is this hard restriction. A little arbitrary feeling but there are ways of working around it. Here’s how we ended up working around the problem of having videos that didn’t have a playlist or that we just wanted to load in a different order:
In order to get a list of videos into javascript quickly and easily I used drupal_to_js and let it sort out the details. This was in my module file.
<script language="JavaScript" type="text/javascript">
videos = '. drupal_to_js($videos) .';
</script>
In our js file we create the variables we need, (remember to put var in the front or ie will flip out) and add listeners. TEMPLATE_READY will be called when the template is fully loaded and MEDIA_COLLECTION_LOAD will be called anytime there’s a switch between playlists or if we use the getMediaInGroupAsynch() function.
var player;
var video, exp, social, content;
var tabBar, videoList;
function onTemplateLoaded(pPlayer) {
player = bcPlayer.getPlayer(pPlayer);
video = player.getModule(APIModules.VIDEO_PLAYER);
exp = player.getModule(APIModules.EXPERIENCE);
content = player.getModule(APIModules.CONTENT);
exp.addEventListener(BCExperienceEvent.TEMPLATE_READY, onTemplateReady);
if (videos != null){
content.addEventListener(BCContentEvent.MEDIA_COLLECTION_LOAD, onMediaCollectionLoad);
}
}
When the player is loaded we want to load in a new set of videos. We don’t need to do anything with the return value because it will be caught by the listener we defined earlier in the js file.
function onTemplateReady(e) {
tabBar = exp.getElementByID("playlistTabs");
videoList = exp.getElementByID("videoList");
if (videos != null) {
content.getMediaInGroupAsynch(videos);
}
}
Finally we get to actually use the videos returned to the player. It’s worth noting that the videos var here is exactly the same as above, a comma delimited list of video_ids. getMediaInGroupAsynch() doesn’t actually do anything with the videos it loads, it just loads them in the player so that we can use them later.
function onMediaCollectionLoad(e) {
if (e.mediaCollection == null) {
// Do nothing because no results came back. Must have been all disabled videos.
}
else {
//once the ids have been fetched from the service, create the runtime lineup.
var playlist = {
displayName: "Selected Videos",
mediaIds: videos
};
var runtimeLineup = content.createRuntimeMediaCollection(playlist,"playlist");
tabBar.insertTabAt(runtimeLineup, 0);
// Select the new tab we created.
tabBar.setSelectedIndex(0);
// Select the correct video and play it.
videoList.setSelectedIndex(0);
video.loadVideo(list.getSelectedData());
}
}
Now you may be saying to yourself, why can’t I just specify a list of videos in the @videoList param? To which I have to say that I have no idea. The documentation even suggests that this is perfectly possible but in fact it isn’t. In the meantime we’re just going to have to learn how to use the Player API, it’s probably good for us anyways. It certainly was good for me and highly entertaining!
Posted in Drupal, Brightcove, Programming | Tags brightcove, drupal, javascript, php | no comments
