Posted by Chuck Vose
Fri, 30 Oct 2009 21: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, 25 Sep 2009 21: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
Tags contractors, drupal, git | no comments
Posted by Chuck Vose
Mon, 21 Sep 2009 22: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 Programming | Tags drupal, drush, Ruby, stakeout | no comments
Posted by Chuck Vose
Fri, 18 Sep 2009 23: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 Programming | Tags brightcove, drupal, javascript, php | no comments
