When we launched Fan Profile just over a week ago, we knew there would be bugs, refactoring and tuning.

There always is.

Minus the bugs, I love this phase. The pressure to launch is gone, and my attention turns to making the product perfect. I mean, who doesn't like perfection?

This time, my pursuit took me and the entire team into huge pile of CRUD.

I had just finished reading the "Gospel of the Seven Actions" (new, show, index, edit, update, create, destroy), and just that easily, I became a born again CRUDian.

My plan was to go through all our controllers and simultaneously tune queries, move code to models and "CRUDify" manufactured actions such as "search, about, mail, send_group_invite" and more.

I figured I could do it incrementally and quickly, so there was no need for a branch -- I'd be done in a day, day and a half.

Whoooopsss.

Yeah, I'll branch in the future because this was no easy task.

Some actions just don't fit nicely into one of the seven. For example, what about an action that takes a comma separated list of positions and rearranges a user's favorite teams based on those parameters?

Well, I had called it "reorder," but delving into the Gospel, I found out that what I am in fact doing is updating an existing order, so we get:

 
map.resources :users as 'fans' do |users|
  users.resource :team_orders, :controller => :user_team_orders
end
 

Notice it is resource not resources. This means that a team can have ONE order, so you can specify the update action without specifying an id, which is good because there is no "order" model anywhere that maps to a table.

In the case of groups, we actually split one controller into eight, but the task is winding down.

I'm fixing the tests and caching and then I'll QA, hopefully in time for a release Monday. Then Fan Profiles will be one giant piece of CRUD where all exposed actions will be "one of the seven" (cue the choir).

If I didn't have a financial accounting mid term on Sunday, I'd celebrate our walk into the CRUDdy light.

The 2008 Web 2.0 Conference (and Expo) got off to a raucous start today. This morning I participated in a workshop (emphasis on the "shop") covering Facebook and opensocial application development. While extremely disappointing in its basicity (a word which I am coining to mean "When a group of people watch some girl click around her MySpace profile to show where you can put really neat widgets"), the latter half of the workshop did semi-touch on important concepts concerning how one should develop in this rapidly changing social network application development environment. I wish the entire 3 hours had been spent developing a working application from scratch, though, even if it had just been a dumb "Hello World" app that says "Hello World" to your friends. Then they could've discussed specific issues encountered with working with Facebook and OpenSocial. How you deal with the differing implementations in the OpenSocial containers. The best way to update and maintain your code to work on the various sites. That's stuff I would've liked to learn about. But if anything it provided a few scraps for thought about OpenSocial coding.

In the afternoon I sat in on a pretty interesting talk about "Innovating on Time" (which may or may not be the official title, but close enough). This topic is something I'd like to go more in depth with at a later point when I've had the opportunity to read a little more and collect my thoughts, but the premise that someone or some group should allot time in their schedules for the simple act of idea creation - or "ideating" - is pretty interesting to me. And while this was the primary focus of the first half of the workshop (there was a 15 minute break for snacks which were nowhere to be found...sob), the second half of the workshop focused on the issue of how you act on these ideas in a timely manner. The presenter, Scott Berkun, brought up several key issues and roadblocks we all face when trying to complete a project - be it innovative or not. At one point he started presenting a series of charts and was throwing around "quantities of work-time" and calculus-based derivative explanations of how projects finish in a hyperbolic fashion. It got a little goofy. But the last 10 minutes of wrap-up definitely left some good messages in terms of how one (or, again, one group) should focus on developing innovative products in an efficient and timely manner.

Early-to-late evening after the conference is mostly a vague wash of various scary homeless people harassing me.

In conclusion,

Web 2.0 FTW

Scrum is the glue that holds our agile iterative development process together. You can get a more official and in-depth definition on the Scrum process from wikipedia or any number of places around the web.

We've found it to be one of the most helpful processes that helps keep our small group working together on a large project on task through improved communication and high transparency.

Here is how we run our daily scrum:

Since we our team is made up of people from different locations, we all call into a conference number at the same time every morning. Once we get everyone on we do a quick round table which involves each participant giving their status update.

Each team member answers three questions:

1) What did you do yesterday?

2) What are you planning to work on today?

3) Do you have any road blocks (any issues that are impeding your progress)?

And that's pretty much it!

A Scrum with 4-6 people participating shouldn't take much longer than 10-15 minutes. Sometimes it can go a bit longer or shorter depending on if any road blocks are brought up, and if there are larger issues that come up that warrant more discussion, we table them and schedule a separate meeting to discuss in depth.

So, keep a set time, round table the three questions, and get back to writing code!

I was really excited when I saw O'Reilly was publishing a Javascript book by Douglas Crockford.

Crockford is one of the leading minds in Javascript, and I was fortunate enough to find his insights early in my Javascript learning days.

I read his take and implementation of Classical inheritance with Javascript a while back and remember thinking how nifty Javascript really could be.

I had the same reaction after reading Javascript: The Good Parts.

While most I already was familiar with most of the items covered in the book (closures), I still learned a great deal (always declare variables at the top) and was reminded of a bit more and encouraged to try some things I never have before (JSLint).

Knowledge of closures and how they work in Javascript separates mediocre Javascript development from solid to good Javascript development.

I nearly always have a test question about closures for interviewees.

Crockford does a better than adequate job explaining them, including a very common gotcha:

 
// BAD EXAMPLE
 
// Make a function that assigns event handler functions to an array
 of nodes the wrong way.
// When you click on a node, an alert box is supposed to display the ordinal
of the node.
// But it always displays the number of nodes instead.
 
var add_the_handlers = function (nodes) {
    var i;
    for (i = 0; i < nodes.length; i += 1) {
        nodes[i].onclick = function (e) {
            alert(i);
        }
    }
};
 
// END BAD EXAMPLE
 
// BETTER EXAMPLE
 
// Make a function that assigns event handler functions to an array of nodes
 the right way.
// When you click on a node, an alert box will display the ordinal of the node.
 
var add_the_handlers = function (nodes) {
    var i;
    for (i = 0; i < nodes.length; i += 1) {
        nodes[i].onclick = function (i) {
            return function (e) {
                alert(i);
            };
        }(i);
    }
};
 

Harnessing the power of closures is the coolest thing about Javascript and really shows off what the language is good at.

Additionally, Crockford reminded me of hasOwnProperty. hasOwnProperty is a life saver when built in objects begin to get extended.

 
o = new Object();
o.prop = 'exists';
o.hasOwnProperty('prop');             // returns true
o.hasOwnProperty('toString');         // returns false
o.hasOwnProperty('hasOwnProperty');   // returns false
 

There are a couple things I don't feel as strongly about.

Crockford rails on global variables, as most Javascript developers do. I used to be of this ilk but have backed of the vitriol lately.

Teams need to set down a convention for global variables. We use "g_". This avoids 99% of name collisions. We usually saw those when we'd create a global variable "var sport = 'nfl'" and then analytics script or ad script would set a variable "var sport = 'National Football League'".

Yes, these bugs are extremely difficult to track down sometimes, but I don't think namespacing everything is required as Crockford suggests.

I also don't understand why Crockford places unary operators (especially -- and ++) in the "Bad Parts" section.

He explains that it creates harder code to maintain. I don't necessarily agree with that assessment and I've always thought there was a significant performance benefit to "++".

I'm not generally a guy who does this, but the script below should show there is a benefit, but it's not significant for my purposes.

 
var date1 = new Date();
var milliseconds1 = date1.getTime();
var j=0;
for (i=0; i < 1000000; i++)
{
    j++;
}
var date2 = new Date();
var milliseconds2 = date2.getTime();
 
var difference = milliseconds2 - milliseconds1;
alert(difference); 
 
var date1 = new Date();
var milliseconds1 = date1.getTime();
var j=0;
for (i=0; i < 1000000; i++)
{
    j = j + 1;
}
var date2 = new Date();
var milliseconds2 = date2.getTime();
 
var difference = milliseconds2 - milliseconds1;
alert(difference);
 

So, I guess "++ vs i = i +1" is a preference things. I'll stick with "++".

However, I totally agree with Crockford's assessment of placing variables.

In most languages, it is generally best to declare variables at the site of first use. That turns out to be a bad practice in JavaScript because it does not have block scope. It is better to declare all variables at the top of each function.

That means removing "var i = 0" from the loop declaration.

At times, Crockford comes off as a bit preachy as he can at times, but I get the impression that's because he truly is passionate about this stuff.

Finally, the appendix includes a great section on using JSLint, which I have played with but never used in production setting. I think I'll try that now.

Overall, this book is great for a beginner. In fact if all Javascript newbies would read this, the Javascript realm would be a happier, smarter one. For the good to great, it's a fun one-to-two-hour read that can be illuminating and a good review.

Of all languages, I have the most experience with Javascript, and that knowledge really helped me with learning Ruby. There are a lot of the same principles.

Interestingly though, Rails has moved me from a Fat Client (where as much code and functionality as possible is written in Javascript) Javascript developer to a Thin Client guy.

This mostly is due to RJS, which pretty much necessitates two Ajax/Javascript patterns: On-Demand Javascript and HTML Message.

Oh, one last thing in the book that I flat out did not know. parseInt can take a radix parameter, so that parseInt("08", 10) produces 8. Amazing! That caused me a lot of headaches!

If not for the televisions at the gym, I would have totally forgot today was the NFL Drafts, one of the biggest traffic drivers for ESPN.com.

In my former Bristol, CT life, I worked as a Web developer for the sports data group. 

This group oversees virtually all applications that rely on automated data and are Fantasy-related. Think scoreboards, box scores, live game pages, standings, statistics, etc. But more importantly for the current discussion, we built and powered the Draft applications.

If you haven't seen this, just check out the Front Page today. It's actually a lot better than it was any year that I was in the group, so congrats to those guys.

Part of overseeing this application meant we would send two people to the Draft in NYC to input the picks as they were made. Don't ask me why this couldn't be automated and or synced with television because I asked that same question and don't think it was ever answered.

Anyway, this never went smoothly. Our connectivity would get dropped or four trades would be announced. It was always something that had us scrambling at spurts.

Despite that, our product never suffered. If we had to, we'd get on cell phones and call in picks and trades to a stand-by engineer in Bristol waiting to run stored procs if necessary.

Overall, I really enjoy the NFL Draft. I always watched it growing up, covered it a few times when I was a reporter eons ago and then made the trip three times for ESPN.

The first 10 picks or so are really exciting. Most of the players getting drafted are there, and it's like watching the next NFL superstars start their careers.

The later rounds, especially the second day, can be pure torture. My first year with ESPN at the Draft, I started off the day with a migraine, which lasted the complete nine-mind numbing hours as guys I had never heard went to teams that would end up cutting them the first day of camp. Not only did I have to stay on top of these picks, but I had to handle situations where the 287th pick was traded for a sixth ad seventh round pick in next years Draft. Ugh.

Overall, though, it's a good time and has really become a big event. The NFL and ESPN do a great job putting it on and covering it. 

Just skip the second day and catch up with it the following day when it's all over.

Fight For The Top Ain't Yet Another Facecebook Application Where You Pick Winners.

It's so much better than that. And we launched it yesterday. For more information, check out Dary's post about it.

One of the completely new bits of functionality on the new and improved Fan Profiles app is the addition of Groups. Like minded fans of whatever can now join forces under the same group and discuss whatever it is that they fancy.

Whether you're a fan of the Raiders Nation, Cowboys Nation, the Red Sox or Yankees, or you love fantasy games, poker, or bass fishing, there is a place for you in Fan Profile Groups. And the beauty of it is, if there isn't then you can go ahead and create your own.

I'm a huge Dodger fan so I had to be the first to create that group. If you bleed blue too then you should check it out and join up.

Here are some of the ins and outs of groups...

Currently, there are two types of groups:

1) Public - anyone can join

2) Private - you must request and invite or receive an invite from the group admin.

All groups are viewable by anyone but you must be a member in order to contribute to a group.

The functionality included with a group from the regular member's point of view is:

1) the ability to post a photo

2) tag a photo that you uploaded

3) comment on the Comment Wall

4) comment on any photo in the group

There will be additional fun things added to groups but that's pretty much it as a member at the moment. If you are the admin of a group, meaning you are the person that started the group, then you can do quite a bit more.

Being an admin is pretty fun actually. You get to do a number of things that distinguishes if from other groups. As a group admin, you can:

1) upload a group logo

2) set the theme for the group

3) tag the group with meaningful words which in turn makes it easier for other fans to find your group

4) you get to moderate all the content that is contributed by all the members. For example, if a member of the group posts something that just doesn't belong then you can delete it. In my Dodgers group a Giants fan thought he was all sneaky and joined up and posted some nonsense about the Giants. I deleted the comment because this just wasn't the place for a Giants troll to make his statement. As the admin I am also able to invite others to join (via their Fan Profile user name or personal email address)

5) Admins can message all the members of the group.

6) Blocking. Oh yeah, that Giants fan is now blocked from my Dodger group. Since the group is open for anyone to join, I have a little control over keeping people out that are just out to ruin it.

Give it a try! Look for a group that suits you or, even better, start your own! And if you have any feedback or thoughts on what you'd like to see added to the groups functionality, then post a comment and let us know.

I recently sat in on part of ABC's two-day Digital Media Developer Summit.

Lex Sisney, CEO of ELC, which we teamed up with with for development and training, spoke about Agile and Iterative development, open source and how they could fit into ABC's developer stack.

Lex touched on three trends:

1) Success of agile/iterative project management
2) Emergence of developer friendly programming languages (specifically Ruby)
3) Commoditization of hosting (Amazon Web Services)

I spoke about how the ESPN Community Group utilizes these three trends for our development process. Oh, ESPN and ABC are part of Disney, which is why I got the invite in the first place.

We got a great reception from the various developers and managers there, which was great. These folks use the same proprietary technology and project management methods we used to use and I got the impression there is a lot of excitement for trying new technologies, methods and hosting solutions.

One of the best questions was what are the fringe benefits we've enjoyed from using all open source methods and technologies. As a manager and developer, I have noticed several:

1) Greater number of applicants for positions
2) Developers acquire skills more quickly
3) Developers acquire a much broader range of skills
4) Developers are more eager to improve their knowledge and skills (because they are acquiring marketable assets)
5) We have become part of a much larger community. Both in terms of taking and giving, we are active in the community through code sharing, Google Groups and much more.

Another great question regarded the combination of Test Driven Development, Agile Development and Ruby on Rails and if they can be separated.

I think Lex answered this best by saying TDD and Agile are methods and RoR is a great tool to use with these methods.

But it is interesting because Agile and TDD almost go hand-in-hand with Rails because the stack is so conducive to those methods that developers would almost have to fight against the methods NOT to use them with Rails.

Any language or stack (especially MVC stacks) can utilize TDD and Agile as processes, but both were baked in with Rails.

I can't think of any reason why that's bad, but I'd be interested to hear arguments on negatives to that.

The last big theme that I tried to stress is that we are not forcing or trying to force any one to adopt our methods or technologies, but merely present that, even in a large company with established methods and technologies, change still can happen, and languages, methods and hosting can be chosen to fit a particular application or product.

For example, I said that moving from Java to Ruby to do the heavy SAX-based parsing of statistical data feeds probably wouldn't be the best idea, but Ruby may be a much better solution for building a new social network.

So I am very glad Lex and got to share knowledge with developers from another part of the community. I hope the company as a whole embraces different solutions, so we can move beyond boundaries created by a particular technology and join a very smart and open community.

I'm going to keep this short and sweet since it's 3 something in the morning PT time but we just re-launched Fan Profiles! We've been working on it for the past few months and this is just the beginning but it feels great to finally have it out there.

Check it out and sign up for your own account here: http://sportsnation.espn.go.com

A more in-depth look at what this launch entailed is coming soon.

Today marks the completion of our most recent, month-long Facebook project "Fight for the Top". The game itself is quite ingenious. While the notion of a pick 'em style game isn't new, the notion of a punishing pick 'em style game is (to me at least). The basic premise of the game is "Don't guess wrong", because if you do your entire streak is reset. Imagine if this game had been out for the past couple years. You'd built a streak of say 423 games right in-a-row by picking only majorly major favorites. You look at the matchups for opening weekend College Football last September. "Michigan at home vs App St.? Please. No brainer." And on Sunday you're on par with Gene Parmesan who just signed up 15 minutes ago. That's the beauty of the game. It is ruthless. So pick all the 1s vs 16s in the first round of next year's March Madness. I dare you. One year that pick is gonna break your heart.

And speaking of streaks, after watching video of the 03/04 Arsenal squad, "The Invincibles", who went undefeated in 49 straight games, I wish I'd gotten into soccer earlier. I've played my entire life, but it was never on TV save for the World Cup and (ahem) the MLS. But watching highlights of that squad - the artistry of Henry, the brilliance of Pires, the wall-like nature of Lehmann - it was like nothing I've ever seen. They were just so FAST! And wildly inventive. Try and track down a highlight from the first game of that 03/04 season against Southampton and watch Pires' 3rd goal of that match. About 5 yards outside the box a deflection is coming to him. He sneaks a peek at the keeper and sees he's maybe 6 or 7 yards off the line. So of course he one-times a 20-yard chip over the keeper's outstretched arms into the back of the net. Such a ridiculous goal. Pires in his prime was one of the all-time greats.

Keep an eye out for Fight for the Top early next week!

In conclusion,

FIGHT FOR THE TOP!

FIGHT!