Installing Ruby + Watir on Windows 7: Quick Start

I recently had the experience of installing Ruby and Watir on a Windows 7 machine and found it a bit, um, less than straightforward. Here’s a recap of the steps such that in the future I can figure out how to do it again.

First: Ruby and DevKit Installers

  1. Let’s get Ruby. The best way to do this on Windows is to use the aptly-named RubyInstaller. Go to the RubyInstaller download page and grab the latest version of Ruby from the RubyInstallers section. Be sure to grab the x64 version if you’re running on a 64 bit system.
  2. Run the installer, which is pretty straightforward and will want to install Ruby to the root of your C: drive, in my case C:\Ruby200-x64
  3. In addition to Ruby, we’re going to need a set of development tools called the DevKit. You can install this from the RubyInstaller download page – it’s in the Development Kit section. Be sure to grab the appropriate version for your version of Ruby and platform. I can neither confirm nor deny that I initially installed the wrong version and burned several hours before I realized the underlying root cause (PEBKAC[1]).
  4. The DevKit installer is a bit less refined than most. You’ll want to save it to the folder where you want the tools installed, which is usually C:\DevKit. Run the installer which really just expands everything into the current folder.

Next: DevKit Configuration

  1. Drop to a command prompt, change to your DevKit directory, and run:

    C:\DevKit>ruby dk.rb init
    [INFO] found RubyInstaller v2.0.0 at C:/Ruby200-x64

    Initialization complete! Please review and modify the auto-generated ‘config.yml’ file to ensure it contains the root directories to all of the installed Rubies you want enhanced by the DevKit

  2. Finish the DevKit setup:

    C:\DevKit>ruby dk.rb install
    [INFO] Installing C:/Ruby200/lib/ruby/site_ruby/2.0.0/rubygems/defaults/operating_system.rb
    [INFO] Installing C:/Ruby200/lib/ruby/site_ruby/devkit.rb

And Then Watir

There’s some lightweight Watir documentation available, and substantial Watir documentation is, for better or worse, in a PDF ebook which can be downloaded here. It’s offered on a “pay what you want” basis, with $0.00 being a valid option.

The basic Watir install is pretty simple:

  1. Drop to your command prompt and run:

    C:\DevKit>gem install watir

  2. There is no Step 2

You should now have a Ruby/Watir setup on Windows 7.

  1. Problem exists between keyboard and chair  ↩

Have the Data: Log Your Work

Sometimes I have fantasies about working in an environment where I’m testing a single product and can really go heads-down into something, uninterrupted, for hours or days on end.

But that’s just my fantasy world and doesn’t reflect anywhere I’ve worked. A couple months ago I realized that I had a gut feeling about two things:

  • I was working on a lot of projects / tasks
  • Task-switching was killing my productivity

Being of the mindset that it’s wise to make decisions and changes based on data rather than gut feelings, I started logging my work.

Format Doesn’t Matter: Just Do It

Don’t get hung up about the “right” way to keep a log of your work. Pick something that’s going to work for you. Maybe that’s a notepad where you jot down your tasks/projects as the day progresses. Maybe it’s a text file in your favorite text editor. In my case, I setup a quick WordPress.com blog using the P2 theme which is pretty minimal and allows me to enter one-liners with each task that I’m working on. Those notes are timestamped and I can easily add tags for later sorting.

The Data is Fascinating

Turns out the problem wasn’t all in my head. On one particularly egregious Tuesday, I was interrupted and asked to task-switch to a different project 6 times before 9:15am.

Update: a couple hours after I published this, Crowd Favorite released Capsule which is worth a look.

The Most Important Software Development Skill

My employer has a couple developer positions open and we’ve been chatting around the office a bit about the traits and skills we’d like to see in candidates and new team members. While some of the chatter has been about technology exposure, or past projects, or mindset about collaboration and development methods, I’m convinced that the most important skill has nothing (and yet everything) to do with software development:

The Most Important Skill for a Software Developer is the Ability to Communicate

Museum of CommunicationsYes, we want someone who can write solid code. Our ideal candidate has an agile mindset. A new team member with experience working in the same line of business would be great. But those qualities can’t be realized if that person is not an effective communicator.

Off the top of my head, communication comes into play:

  • As a developer understands the requirements or stories
  • When the developer participates in the daily standup
  • As multiple developers collaborate to share code or experiences
  • For organizational communication purposes
  • In reading and resolving defects from our tracking system
  • While working with end users or analysts to ensure user acceptance

The inability to communicate effectively will slow down the team’s work and impair the effectiveness. In addition to back-and-forth for clarifications, poor communication can lead to the wrong code being written.

We Can’t Solve Business Problems if We Can’t Understand Them

And we can’t understand them without communication.

I suspect it’s far easier to teach a developer how to use jQuery than it is to teach an ineffective communicator how to clearly communicate their thoughts.

Photo by Flickr user Cargo Cult; used under Creative Commons license.

Agile Consistency Without Reams of Specs

My first actual article on this site was explaining my take on three tiers of consistency within software and assuring that a software program provides an experience where a user can expect things to be consistently intuitive and behave based on the user’s expectations.

Consistency in the Waterfall

Putting on the old man costume, one might muse a bit about the good old days of waterfall software development when everything worked out perfectly because we had reams of specifications for each project. The specifications must be right because they had sign-off by someone important and we had a big stack of change control paperwork for each modification!

Stepping off the sarcastic soapbox for a moment, I will note that implementing consistent behavior wasn’t likely easier in the waterfall days, but it was probably less ambiguous. One could always look up requirement 11.4.5.8 where it specified how something should work and compare the software to the letter of the requirement.

The Agile Consistency Dilemma

When we transition to a more agile way of building software, where we value

Working software over comprehensive documentation

how do we ensure consistency in the absence of pile of specifications?

Consistency by Communication and Familiarization

Looking at the three aspects of consistency I wrote about previously, we have:

  • Consistency within a given application
  • Consistency across applications within the line of business
  • Consistency with industry norms and trends

Within an application or across a line of business, we can help facilitate consistency by enabling and facilitating communication within the development team. Developers that chat and communicate about how they’re solving problems are likely to solve those problems in similar fashion.

Familiarization with products can help prevent reinvention of the wheel. If your company has six products, a developer ought to have end-user knowledge of all six such that when implementing a new feature they would know how that feature, interface, or workflow might already be in place in a different program. This seems like it would be obvious, but I can recall several cases where I’ve raised an issue of inconsistency across products (by the same organization) and the developer indicated that he or she had never seen that other product.

Consistency failures are often failures of innocent ignorance… the developers aren’t being inconsistent with intent. They’re being inconsistent because they aren’t aware. Increasing awareness increases the consistency.

Take that day or two that you might have spent reviewing specifications and go work with the software.

As an added bonus, that time spent communicating about consistency? Your developers will also communicate about other things and build a more cohesive team.

Ingredients of a Helpful Error Message

As they say, shit happens.

Even in software.

And when things go haywire, we want to communicate with the users in a helpful manner. Ideally, an error message:

  • Informs the user a bit about what went wrong (if known)
  • Instructs the user how he might fix the problem on his own (if possible)
  • Suggests what the user should do if further assistance is required

Thoughts?

Words That Have Meaning: All, Never, Every, Any

Nothing gets my QA ears perked up quite like user stories with the words all, never, every, or any. Because we thrive on exceptions.

I recall a scenario from a few years ago while meeting with some customers about a new “quick and dirty” (another red flag) project. We heard lots of chatter about adding records, updating records, but nothing about deletions. I posed the question:

Me: Would you ever need to delete records from the system?
Customer: No… never… that would be really rare.

If you don’t see the problem, go back and re-read that quote.

Every time a customer, developer, or analyst says “all”, “never”, “every”, “any” or another catch-all definitive statement, start asking questions about if they really mean it.