Version 3.1.1 has been released. There a few cool improvements such as auto-reloading when .autotest is updated and git support, as well as a whole mess of stuff that I have to assume are improvements. Full text of the update here:

http://blog.zenspider.com/2008/10/zentest-version-3110-has-been.html

Rails has come a long way quickly, but one of the biggest problems with our favorite MVC framework is support for multiple databases.

Sure you can use self.table_name and/or establish_connection to force a model to point to a table in a different db, but try running a freaking test with fixtures for the offshoot models, and you'll see what I'm talking about.

Even more depressing is SQLite3's lack of cross-database query join support, making this statement impossible:

has_and_belongs_to_many :blocked_users,
:class_name => 'User', :join_table => :blocked_users,
:foreign_key => "user_id", :association_foreign_key => "blocked_user_id"

Here's the kicker: All of our apps are multi-database apps, so that means no more SQLite allowed for us, and I really loved it until now.

If I'm wrong, let me know. I'd love to go back to using SQLite for local development. Same for an easy way to load fixtures.

Opened up irb and had a little fun this morning:

%w(good morning dary).each {|w| system("say -v Victoria #{w}")}

Awww. Good morning to you too Victoria

RubyGems 1.2 is available now. Everyone should update. In addition to a few bug fixes, it also removes the need to bulk update (which I think is pretty sweet).

RubyForge page

Like many web developers I am largely self taught. The web is full of endless resources and anyone with an internet connection and Google can more or less figure anything out.

Having said that, it often times does help to have a course provide structure as a guideline to your learning. I found a course that is online and free to anyone that wants to learn the basics of Ruby.

You can find it here: http://www.rubylearning.org/class/

You can also check out the notes here: http://rubylearning.com/satishtalim/tutorial.html

I haven't taken a computer science course in over a decade so this course helped get me back to the fundamentals of programming and specifically how they relate to the world of Ruby.

The individual that puts the course together has an active twitter account and is easily accessible on the course message boards and via email.

I've been going through the many resources I've used over the past several months to get up to speed on RoR and will start posting more of them here on this blog going forward.

I tried to use Ruby's built-in Active Record fixtures module to import an Excel-exported CSV file. No dice. Kept getting cryptic errors about improper formatting. Whoops. So then I installed this wicked cool gem named FasterCSV and piggy-backed off of this migration import script and everything went great. So for all those people with ancient (and kinda useless) Excel data files, now there's a relatively quick and painless way to import them into SQL dbs. Here are the steps I went through:

Install the gem:
sudo gem install fastercsv

Now I have several tables in my College Football spreadsheet and for this example I'll use the one with ratings data for College Football games. Each entry has a game_id, region_id (for the various regions where ratings data comes from, e.g., Atlanta and Austin), a rating, and a duration in quarter hours (since some games are only cut-ins, e.g., Georgia Tech-Georgia ends early and the Atlanta region picks up the last half hour of the Texas-Oklahoma game). So here's the script that imports my gross Excel spreadsheet into a useable SQL table - db-agnostic by the way (How do I love thee Rails? Let me count the ways.)

require 'fastercsv'

def self.down
end
end
And it's just that easy. Another cool thing, that I haven't done yet, is that you could take that one bulky Excel sheet that has way too much information in it, break it into useful models, and form actual relationships between the data. What a novel idea!

In Conclusion,

This rules!

I wrote a script tonight to curl several URLs, but sleep for 2 minutes in between each request. I piggybacked on a little script written by programmer John McCann from NYC. Here's what the code looks like:

#!/usr/bin/env ruby
RAILS_ROOT = File.expand_path(File.dirname(__FILE__) + '/..')

require File.join(RAILS_ROOT, "config/environment")

puts "writing curl script..."

t1 = Time.now

foos = Foo.find_by_sql("select distinct bar from foos;")

curls = foos.map! {|foo| "curl 'https://some.api.com?data=%7Bfoobar%3A#{foo.bar}%7D&key=12345'\n"}

curl_script = curls.join("sleep 120\n")

File.open("curl.sh", "w") {|f| f <<>

t2 = Time.now

puts "curl script written in " + (t2 - t1).to_s + " seconds"

What's fun about this script is that it was a new challenge for me on a couple fronts. I learned about encoding curl requests (%7Bfoobar%3A#{foo.bar}%7D produces {foobar:[value_of_foo.bar]}). After clumsily grabbing all objects and filtering after the query, I refactored the SQL to just grab distinct values from the db. I learned that the "w" attribute of the File.open class method either creates a file or sets its byte count to 0 if it already exists. And finally I learned about the "sleep" function which takes an integer parameter representing the number of seconds to wait until the next line is executed - this was especially helpful in not hammering the service I was accessing.

So not a major script, but pretty fun and interesting nonetheless.

In Conclusion,

I heart curl.

View Here

Behavior-driven development (BDD) is a programming paradigm that emphasizes defining behavioral characteristics of your code before actually writing any code. An example is if I'm defining a calculator controller my calculator should return 2 when given the equation 1 + 1, should return an error when trying to do division by 0, etc. By clearly defining what your code should do before writing it, it makes it much easier to write solid, test-covered code upfront and makes it a cinch to debug as you go along because you're immediately alerted whenever new functionality accidentally breaks legacy portions of your codebase.

I've found BDD much more intuitive than TDD (test-driven development). The above video by Dave Astels, one of the original developers of rSpec, gives a nice overview of BDD vs. TDD and the pros of the former. Also touches on the benefits of using a dynamic language like Ruby.

In Conclusion,

Pretty neat...

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've set up countless WordPress blogs in my time.

The entire process took me about 30 minutes when I set up my first one a couple years back. And each time, through experience and code improvements, it was easier.

Until this time.

The difference was that this is an actual ESPN blog, created and maintained by actual ESPN employees.

The difference between a company blog and a personal blog is huge, especially, considering ESPN has never had a public-facing blog run by employees.

So, what will we write about here? I don't know. Pretty much anything related to sports, the Internet or working for ESPN.

A better question is what we won't write about here.

We won't cover any secrets. Sure, we'll talk about products we're working and are getting ready to launch, but we're not going to give away competitive advantages.

We'll also steer clear of any legal issues that have to do with ESPN that could potentially affect the company.

We won't flatly criticize ESPN. Think about it. When we criticize the company, we are criticizing SOMEONE or multiple someones we work with. It's just not cool to criticize a coworker in a public forum. If we want to talk about work done outside of this group, we'll try to interview the person or people responsible for the work and present their insight here.

We are developers and Internet fanatics who want to share our experiences and thoughts with The Community.

More specifically, we're Rails developers and Web 2.0 junkies. Oh, we're huge sports fans, too. So mostly, we'll be sticking to talking about our dealings with each and try to give you a feel for what it's like to work for ESPN.