Regardless of who you think is wrong or right in this particular display of greed and self-importance, I hope you can agree with me that this is a business deal between two corporate entities that should be solved (or not) between themselves.  Unfortunately, for a while now, the FCC has been involved, and apparently, the FCC wants no part of the NFL-Comcast mess.  I can’t blame them - these rich crybabies need to sort out this problem on their own.  Real Americans have real needs from their government in these difficult times, and they don’t involve watching football on Thursday nights.

Thing is, as this fight drags on and the economy continues to sink, both sides are going to lose out.  We pay a hefty bill to Comcast each month for Internet and TV service, and I’m starting to take a long look at the nickel-and-dime charges they tack on for every cable box, and HD service on each additional TV.  These prices were bumped up earlier this year, and our bill just continues to inflate.  I’m about to scale back on the cable boxes and sign up for a Netflix subscription.  For $8.99/month, you can have unlimited streaming movies to your XBOX 360, with many in HD.  That beats the pants off any Comcast premium channel price.

As for the NFL, they need to quickly get their head out of the clouds and realize that they’re lucky to be in a dominant position in the world of sports.  They need to negotiate resonably with Comcast and the other cable operators to get more of their games on TV.  They also need to start listening to their fans about on- and off-field issues like end zone celebrations (we like them) and continued reinstatement of thugs and hooligans like Adam Jones (we don’t like them).  Sports will be an important escape for Americans as we navigate through the new depression, and there needs to be a focus on making the games fun and competitive, instead of merely lining the NFL’s already deep pockets.

This is one of the first equations programmers learn. Very few programmers I have ever known stay away from “the juice” completely. Our daily work requires focus, concentration, and a high level of mental energy. I am convinced that there is a linear relationship between the amount of caffeine consumed and the amount of code written in a single day. When I don’t have coffee, I tend to stare at my code with little understanding of what to do next.

One of our programmers at InsureMe has a shrine to Rockstar energy drink on his desk. My personal addiction is a Starbucks cappuccino, every morning, if I can afford it. The office coffee isn’t bad either - it’s at least a step or two above your average grocery store brand. Some are into soda - I’ve seen structures made out of Coke or Mountain Dew cans that approach the Eiffel Tower in both size and complexity. Yes, we coders love our caffeine. There is a programming language named Java. Do you think that’s a mistake?

Think caffeine is bad for you? Probably not. I shall quote:

“However, caffeine’s popularity in the computer industry may also be due to the special mental boost caffeine confers, which helps improve accuracy and speed in completing certain tasks, including writing computer programs and operating computer systems.”

I promised a while back to write about the test tool I chose for the automated testing project I’m working on at InsureMe. At this point I have basically completed phase I of my project. I have been using, and am fairly happy with, an open-source tool called Selenium Remote Control (hereafter, SRC). So I guess a product review is in order …

To quote SRC’s website:

Selenium Remote Control is a test tool that allows you to write automated web application UI tests in any programming language against any HTTP website using any mainstream JavaScript-enabled browser.

And to quote Pulp Fiction:

That’s a bold statement.

Unlike most marketing statements, this one doesn’t stretch the truth to the far ends of the earth. Any programming language capable of sending an HTTP request can use SRC, and the team provides wrapper functions in Java, .Net, Perl, Python, Ruby, and Selenium’s own Selenese to make things even easier, if you use one of those languages.ÂÂ That should cover just about any web developer out there today, but those of you writing your web code in Cobol, feel free to complain.ÂÂ I am personally using the .Net library, which allows me to create a Windows app with C# and automate my testing via SRC.

The part about any JavaScript-enabled browser is also true. There are several pre-defined browser profiles (IE, Firefox, Opera) and you can use the custom profile to launch any browser you want. Your broswer needs to be JavaScript-enabled because that’s how SRC works - it pipes the HTTP requests through a proxy, and injects JavaScript code to click buttons, enter text, and select options on your web page. I don’t pretend to have a deep understanding of this process, but you can see more details at SRC’s website.

The Selenium suite of tools is actually made up of several components - Selenium Core and Selenium Server, which are the heart of the automation engine; Selenium IDE, which is a Firefox add-on for record-and-playback of tests; SRC; and the Selenese language, which is tailored to sending specific commands to Selenium Server. Without using the tools, it can be difficult to see how this all fits together - again, I would direct you to SRC’s website.

SRC’s advantages are many - the ability to work with so many different programming languages and browsers is one that even most expensive enterprise-level tools don’t have. SRC is open-source and free of charge, so you can try it on your own schedule without spending a penny. The documentation is good, for an open-source project. You can work through the quick tutorial in about 30 minutes and have all the knowledge you need to get started on a real project. The documentation and examples all revolve around unit testing frameworks (XUnit) but it’s not a requirement to use SRC. Any program that uses one of the supported languages can hook in the SRC library and go.

SRC’s disadvantages are few. Support is all forum-based, and to the Selenium team’s credit, they do a very good job of keeping up with the forums and responding to user issues. Still, many people are uncomfortable with this type of support, and for the most part, those people shouldn’t be considering open-source apps anyway. The only other disadvantage I’ve found is that communication between my program and the Selenium Server seems to lock up pretty quickly, if I switch to a different application on my desktop. Theoretically, this shouldn’t happen - Selenium Server is listening for HTTP requests on a specific port, and my program should be able to continue communicating with the server at a later time, regardless of what happens on the desktop. But it does lock up, every time. And it makes debugging and driving tests via a separate Windows app tough at times. It’s not a deal breaker, but definitely an issue that I will continue to investigate.

The bottom line is, SRC fits my needs for a web automation tool very nicely, and it gives me total control in code to create any kind of test tool that I can dream up. I’ll go into more detail about my project in another post, but suffice to say that Selenium and SRC get my thumbs up. Selenium should definitely be on your short list if you are evaluating any kind of web testing automation.