The latest episode of the Ruby Rogues Podcast on Technical Debt was a great conversation about how we purposely or inadvertently accrue Technical Debt. One example in my personal process, is embedded CSS and/or Javascript (I know). In the interest of time, I will slop some styles or even Javascript on the bottom of the page to get a feature working, and move on the the next item on my list. Here is the debt incurred: At some point before launch I will have to refractor the Javascripts and organize my CSS into and external sheet, but until I do that I have a debt to be paid in development time. This is a trivial example, and not the best habit to have, but it helps me get to a working prototype more quickly, and compared to other technical debts, it's more like borrowing five bucks from a co-worker for lunch.
A larger technical debt that the panelists on the podcast touched on was gem dependencies in Ruby and especially Rails applications. The debt metaphor, in my opinion, slightly missed the mark. I've worked on applications as an agency developer, and as a freelancer which had a very profound dependence on third party gems and plugins. During development this is a great resource. Instead of laboriously writing mundane code to help you fulfill one business rule or another, you simply add a line to your environment.rb file.
Initially, the debt incurred is small, and the return is high. But there comes a point when the "environment" changes. In the financial world, this was in 2008. In the Rails world this was the Summer of 2010. The release of Rails 3 was rushed in with the new emphasis on Ruby 1.9 (And please, don't get me wrong, this is a fantastic step forward in the Ruby on Rails ecosystem). Upgrading your app to Rails 3 and especially Ruby 1.9 would require all of your dependencies to do the same, and immediately not everyone was on board. If you were depending on a gem that had stopped being maintained, then BAM! The interest rate on your debt just went from a comfortable 2.25% to 18%. A Technical ARM.
So when your app, is in the double-digits of gem dependencies, or is heavily relying on gems that have not made it out of 0.X release, you're playing with fire. Consider writing the code yourself instead of adding yet another dependency.
This is a logo I designed for a new company that you'll hopefully being hearing about in 2011. The folks behind it hope to change the way you contract home-improvment projects by adding a level of transparency never seen before in the industry.
Blogs—as I've come to find out—become quite a nuisance while you're busy with other items in life, especially work. June 3 through today have been exactly that for me. I thought I'd take a moment to fill this blog with all of the great things I've been working on that have forced me to neglect it.
NFL 32 Teams in 32 Days & Fan Rankings
With NFL.com, I released a power-ranking app, which ran immediately following the 2010 NFL Draft. Fan's rankings were tallied and revealed during NFL Network's flagship daily news show, Total Access. The site was successful enough to earn a promotion to be NFL.com's primary week-to-week power rankings app for the run of the 2010 regular season.
On Friday, Sept. 3, NFL Network debuted a new 10-episode series produced by NFL Films entitled, The Top 100: NFL’s Greatest Players. Leading up to the series launch, NFL.com polled their fans for who they thought the Top 100 players off all-time were. Building the web ballot fell to me, and I was tasked with taking a similar approach to the NFL Drat MVPs voting. Users are given two random players from which to choose the superior player. The Fans submitted an astounding 12 million votes!
NFLRUSH Fantasy Football is a great game for young fans who want to play fantasy football and follow their favorite players. The goal is to pick the players you think will do the best each week of the season. It can be best described as Fantasy Football Light for kids. The prize, however, is anything but. NFL Rush is giving away a $10,000 scholarship to the winner!
Home Team Challenge is a regular season clone of last year's NFL Playoff Challenge. The caveat being that users compete against other fans of their favorite NFL franchise. Players are chosen weekly to earn fantasy points. All 32 team are represented and you can find each team's game following the URL scheme: teamname.challengegames.nfl.com/hometeamchallenge/ (see below).
I teamed up with NFLatino.com and Univision.com to build the NFL's first fantasy football game entirely in Spanish for the 2010 regular season. The game is Weekly Player Pick'em with groupings for US and International users.
For the second year, I teamed with Versus.com to build their NCAA Football pick'em game. This is in the style of the classic office pool format, where participants simply pick winners. Your picks are measured against other group members, a resident expert, and the community of users at large.
Was he out? Yeah, he was out. But instituting replay in Major League Baseball is a knee-jerk, over-reaction to the blown call last night in the Tigers-Indians game. The goal of instant replay as I understand it, is to get a potentially outcome-altering play correct. Let's be honest with each other for a moment: This play—safe or out—had no impact on the outcome of the game. It only obscured what is merely a statistical anomaly in MLB. Furthermore, for this one instance where replay could have been used to overturn an obviously incorrect call, I will have to be subjected to dozens of safe/out, catch/no-catch, fair/foul, balk/no-balk, etc. replays on utterly inconsequential plays in the game.
I have a half-baked theory on this. If you're paying attention to the mainstream media these days, it is obvious to you that modern journalism is nothing but sensational voyeurism or agenda driving. Usually both. Reporters and their media outlets insist on being the story, rather than reporting on it. (This is mostly off-the-cuff, so I'm not going to get into specific examples. Grant me the leeway you would an editorial cartoon).
Sports media are no different. Game officials make calls in a split second. Sometimes incorrectly. You make a lot of bad decisions too, so he who is without sin... The talking heads on radio and television enjoy and take advantage of the ability to watch a play, frame-by-frame and insist that they, not the official standing 3 feet away from the play, can make the proper judgement. The media wants to control the game from their comfortable ivory tower, with infinite hind-sight and total lack of consequence for their judgements. They want to be the story, not report on it. That crooked umpire with the untrustworthy sneer and handlebar mustache stole the perfect game from that poor player. Why, if we could have just used our television cameras we could have prevented this travesty!
Replay makes sports feel like a high-stakes civil litigation trial, and Tim McCarver is the prosecuting attorney. But I think the most compelling argument against replay is that, if the NFL is any example, the officials still get the call wrong!
Even though this was a made-for-TV event, I still think the NFL did a hell of a job for the fans at Radio City. I also think that the fans do a hell of a job for the NFL making this event what it is. When I told people that I was going to the draft, I got a lot of, "Really? Sounds boring." But let me tell you, there was not a dull moment. The passion that the fan-base has for the NFL is unmatched in American sports. Every team was represented by a group of their supporters, which I thought was remarkable. People cross the country for this event! But none were more noticeably (and audibly) represented then the Jets contingency. They owned the building last night, so hats off to them.
My latest game on NFL.com allows you to create your own first-round mock NFL draft. Correct points earn points toward the grand prize: A 4-day, 3-night trip to Hawai'i to take in the 2011 Pro Bowl Game. Predict the Pick on NFL.com!
Facebook Connect is an easy, yet powerful way to drive members of your Facebook network to your site or application, and vice versa. Facebook Connect pairs a registered Facebook Application with a website's URL. This poses a problem for engineers who develop in one environment, test in another, perhaps QA in a third, and deploy to a production server each available at a different URL.
The logical approach to using Facebook Connect would be to pair it with the production environment, and this is not wrong, necessarily. The issue is that the way you register applications with Facebook is to pair them with one specific URL, while your website has several. Let's suppose your application lives in the following environments:
Dev
http://localhost:3000
Test
http://test.myapp.mycompany.com
QA
http://qa.myapp.mycompany.com
Production
http://example.com
It's plain to see that the same code base is available at four different URLs. What we obviously don't want is 4 versions of the code base. So, what I've done here, is propose a simple way for the Facebook Connect functionality of your site to be aware of what environment it is running in.
Step 1: Create a new Facebook Application for each environment
This is probably the most tedious part. Head on over to http://www.facebook.com/developers and click on Set Up New Application. Give your application a name, and be sure to include the name of the environment in the name for each except production. This will make it easier to organize as you'll see later. You'll need to do this once for each URL (environment) your website is accessible from.
Step 2: Set the Connect Callback URL
Now that you app is created you'll need to tell Facebook how (or rather, where) to connect to it. Click the "Connect" option on the left-side of the screen and then provide the root level URL for this particular environment. It must be exact (including the port number for localhost).
If, in development, you use any port besides 3000 be sure to note it appropriately here. If for any reason your server is running on another port other than the one you've specified, FB Connect will fail.
Step 3: Instantiate Constants in environment.rb files
So, up until now, we've been telling Facebook how to connect to our site. We also need to make our Rails app aware of Facebook. Assuming each of the environments that our Rails app is running in has a unique, corresponding environment.rb file, we can use these file to set some reqired information about connecting to Facebook. Using the same example from above, let's say your config/environments/ directory contains something like this:
$ ls config/environments/
development.rb test.rb qa.rb production.rb
Open up each of the files in you favorite text editor and at the bottom add this line:
Be sure to fill in the correct App ID, API key, and Secret for the environment you're setting up. This is why I told you that including the environment name in the App's title was a good idea! These values are always available on your personal Facebook Applications page.
Step 4: Make your pages aware of FB.Connect and FBML
You'll need to add an attribute to the <html> element and a few lines of Javascript to every page that will be using FB Connect. Fortunately, this is very straight forward in Rails. This code belongs in each layout file that will be using FB Connect. In most applications, this is simply the application layout. So open that file for editing.
To make your pages aware of FBML,
add the following attribute to the <html> element:
xmlns:fb="http://www.facebook.com/2008/fbml"
To make your pages aware of the FB.Connect JS Object, add the following lines to the bottom of your layout:
Part of this step is optional and part of it is required. I'll begin with the required part. You'll need to make a control file available to Facebook Connect. You may have already been asked to do this and verify it. If not, place the xd_receiver.htm file that Facebook provided (you can also find it at the end of this post) in your application's public/ directory. Once you have done this your application is fully capable of using Facebook Connect correctly in each environment it happens to be running in.
The optional portion of this step involves creating an xd_receiver.htm file for each of your application's environments. I recommend doing this in case you need to make domain specific changes to the xd_receiver.htm file. If you only have one, making a change for one environment may break the file for the other environments.
Begin by creating a new directory in your Rails app under public/ called fb_connect. In this directory create a new directory for each environment your application runs in. In each of the environment directories, place a copy of the xd_receiver.htm file. This is where you will make any environment (domain) specific changes if you need to down the road.
Facebook Connect assumes that it will be able to find xd_receiver.htm immediately under your application's connect URL that you specified in Step 2. We'll need to tell Facebook explicitly where to find the correct xd_receiver.htm file. To do this, open up each environment.rb file and add a new value to our constant:
There you have it. No more telling your PM that "It'll work when it gets to production, I promise." You can now test Facebook Connect functionality in each environment your application lives in.
XD Reciever file: Download If you're using this approach or need a hand setting it up feel free to contact me.
NFL Weekly Countdown is a game that I built for NFL.com with Sports Technologies, and today I found out that it has earned a nomination for a Sports Emmy Award. You can read the press release on NFL.com. The category it was nominated in is Outstanding new approaches sports programming.
NFL Weekly Countdown combines a Web-based voting system (that I was responsible for), with a TV show airing on NFL Network. Each week, the results of the fans' vote on weeklycountdown.nfl.com determined the order that the videos appeared on the TV Show. This is not a new approach to sports programming, but it certainly is outstanding. Everyone working on this project really knocked it out of the park.
Was he out? Yeah, he was out. But instituting replay in Major League Baseball is a knee-jerk, over-reaction to the blown call last night in the Tigers-Indians game. The goal of instant replay as I understand it, is to get a potentially outcome-altering play correct. Let's be honest with each other for a moment: This play—safe or out—had no impact on the outcome of the game. It only obscured what is merely a statistical anomaly in MLB. Furthermore, for this one instance where replay could have been used to overturn an obviously incorrect call, I will have to be subjected to dozens of safe/out, catch/no-catch, fair/foul, balk/no-balk, etc. replays on utterly inconsequential plays in the game.
