Classpath struggle, even the Jedi

{

Larry O'Brien, well known Jedi Master of many things development posts:

"I have to wire up a ColdFusion to an Axis Web Service. I've spent the past 3
hours trying to figure out freaking classpath issues: something about a
ClassCastException from a org.apache.commons.logging.LogFactory. I'm giving up
for the day. Stupid freaking classpaths."

I can remember sitting in my one room apartment above a garage in Whittier fighting with classpaths, trying to wrangle them into my understanding of Java. It is not schadenfreude that makes me post this, it's more the comfort of knowing that I'm not the only one to have struggled with them.

}

Friction

{

Reading Joel Spolsky and others on the hring process is always interesting. One aspect of their writing that has always intrigued me has been the "quiz questions" used to get a feel for the interviewee's level of intelligence.

Lately I've been interviewing people regularly and am slowly coming up with a format that gets me closest to a person's technical level as it pertains to our company. I usually ask a person to rate themselves on a scale of one to ten in three areas:
1. Web Application Development (HTML / CSS / Javascript / ASP.NET (or any other web app framework or perl/scripting env)
2. "Fat" clients (Windows Forms .NET / COM )
3. Database programming and administration (SQL / Database Design)

I then follow up their ratings of themselves with some general questions in each area. For example, most people consider themselves knowledgable with web development because they know some basic html. Questions I like to pose here may be along the lines of asking what the difference is between DIV and SPAN elements, or what their understanding of why XHTML (versus HTML 4.0) came into existence, or whether they think designing with tables is a bad idea. On the programming side I like to ask a person about the postback cycle in ASP.NET, or if they come from a non-.NET environment, about something like state management (querystring, session, etc...) in web applications. Another favorite area of mine is javascript since many people think they know it but can't provide answers for even a simple question like how to register an event for an html element. When I ask questions the point is definitely not about trivia but more to gauge whether the candidate is about aptitude or whether they'd be capable of jumping right in the fray and making a contribution.

But beyond the technical questions, beyond the idea of "Smart, Gets Stuff Done" as goals in the ideal candidate, probably the most important thing about working the environments I've been exposed to is learning how they deal with "Friction." I was watching a panel show once on CSPAN where a wizened old military man said: "The difference between war plans and war is friction." As I understand it, friction has to do with all those little things (and big things) that go wrong. In our case, friction is almost always involved in trying to hit release dates. Friction is also a big player when it comes to team dynamics and how people treat each other.

For all the talk online about people who are exceptionally smart and productive, I'm surprised that the question of friction isn't more important when choosing programmers since friction is always a part of software development. Everyone's got a story about this, but here's mine: I worked with a guy who was exceptionally sharp, anal-retentive, and detail oriented. He'd forgotten more within his discipline than I probably will know. I would ask him from time to time for help on the little problems I was dealing with and his answers were always prompt and accurate. We worked together as peers and that's what made me capable of liking him however, for many people, he was nearly impossible to deal with because any change that required flexibility on his part was out of the question. If I'd been a team lead on a project, he'd be a difficult decision because of this attitude, and what would push me from the "maybe" into the "no" decision would not be my own ability to work with him, it would be his affect on the team as a whole and how he affected the team's group culture.

One thing to bear in mind is that I'm a consultant who writes business-ware which may mean that friction comes up for me a lot more than someone working at a shrinkwrap company, or a behemoth powerhouse with zillions of great hackers. But as my experience accumulates, I begin to see that a person who has the ability to calm a client down while being able to refocus and get a project out the door is more valuable than a person who is a brilliant programmer but unable to deal with the type of rapid change and improvisation necessary for our work.

}

Commands and Abstractions

{

I clash with people occasionally over my approach to SQL Server. My approach to SQL Server is quite simple: Transact SQL. Never one for layers of abstraction and always seduced by speed, I prefer to keep my management activity in Query Analyzer. SQL Management Studio seems a bit slower than its older cousin, so quite often I prefer Query Analyzer even with the brand new SQL Server 2005.

Often times for me preferences like this develop after bad experiences but today was a reminder of what kinds of things a layer of abstraction is capable of doing behind your back if you don't monitor it. We have a table with 82 columns and something like 50,000 rows. One of these columns needed to be extended from VARCHAR(10) to VARCHAR(50). I was walking through the steps as they may occur in Enterprise Manager so I opened the product (wait a few seconds), selected my database (wait a few seconds), opened the tables node (wait a few seconds), and then right clicked on my table to examine and manipulate the column (another few seconds, plus scrolling up and down to locate the column I wanted). I made my change and then proceeded to make a "change script" which, to my horror, creates a temp table, copies data and affects other tables referenced by the table whose column I was changing.

My usual approach to something like this is the following: Start->Run (Instantaneous). "isqlw" and hit enter (Instantaneous). In the query window I type the following:

1 USE MyTestDatabase

2 GO

3

4 ALTER TABLE Foo

5 ALTER COLUMN Bar VARCHAR(50)

6 GO

This is a simple example, titled away from the GUI but there's more to this. Because the GUI represents an abstraction, there are limitations a person who is there encounters and begins to operate with. A simple example is the following: assume a table has 3 stored procedures (select, insert, update) and you've added a few columns that you'd like to include as parameters in each of the procs. In Enterprise Manager, or SQL Management Studio, a person is inclined to think in terms of a single procedure at once and likely to visit each procedure to make this change. A wise Unix gray beard or someone else who's comfortable with a text editor will dump all the procedures they need to modify into a single file, do some search/replace operations as a single step, and do the update.

The point for me really veers from SQL Server at this point and gets into the question of the abstractions which I myself rely on unnecessarily - which prevent my thinking to get past a certain point. Although I have come to rely on the command line more and more over time, there are still things I learn: DOS things! that have really changed how I think about certain types of problems. A simple example of this is from a few months ago when I learned of the existence of pushd and popd, commands for storing and retrieving working directories on a stack. These relatively trivial techniques make it easy to do things that never really occured to me before. Like the fact that I could just use fc to check for differences in files. Or piping a request for help to a file so I could have documentation for a command. Here is an example that might be interesting: wsdl.exe /? >wsdlParameters.txt

One last point of clarification: I am not against abstractions. In many instances they work quite well. A while back I wrote a web based tool for viewing objects in SQL Server databases - basically outputting queries to the Information Schema views. Everything that tool does can be duplicated in query analyzer or in SQL Management Studio. But in terms of raw speed, flipping back and forth on table definitions in the web based tool beats clicking around in the GUI or retyping the same select statement with a different table name in the where clause. What I believe is that abstractions are used best when what they are hiding is understood fully. This is counter intuitive; most people think the abstractions - an easy GUI, a simple command, and so on - are there to make things simpler for people who want to keep details hidden. That is always dangerous, even when it's effective. I'd prefer to struggle with what's underneath and then live blissfully choosing the abstractions I find useful.

}

Serious Reading

{

Chris Sells answers a few questions in public but one comment got my attention:

How are you able to keep up with the changes? What books do you read?

[csells] I keep up with changes by a) a broad familiarity with as much technology as possible and then b) committing to using it because it feels like it’ll be the right thing and c) using fear to motivate me (recognize a pattern? : ). I read books on demand given the topic I’m into, and then it’s 3-5 books in a week for immersion. Frankly, after writing a few books, I’m a bit of a snob, so I don’t read a lot of technical books for fun the way I used to.

Wow: three to five books in a week for "immersion." It's a stark reminder on a personal level of how much more aggressive I need to get with my own reading list (which, incidentally, includes Sells's Windows Forms Programming) but in a general sense it shows a hallmark of what the information age does to programmers - it might not be intelligence that separates us (though I think Sells is remarkably intelligent), it's the ability to absorb information quickly.

I don't read very quickly so it's a matter of discipline and will to work on absorbing what's relevant for the job and the future. But in a word where guys like Sells chew up and spit out technologies before most people are seriously working with them, a person needs a good reminder of staying focused.

It reminds me of the brief exchange I had with Hanselman. I'd ask a question, he'd casually suggest a book. It says, to me, that there's a bit of mysticism to how smart people like that stay on top of things but really that the information is out there and ready to be consumed if only one is disciplined enough to pursue it.

}

Windows Forms for Visual Basic 6 users

{

My current project at work is a Windows Forms application. Even though I've been programming .NET almost daily since it's introduction, just about all of what I've done is web based programming using ASP.NET. The non-web code I've written has been for the most part libraries (DLLs) to use in web apps.

Most of what I know about thick clients comes from doing work in Visual Basic 6 so while I usually know where I'd like to go with something, I find myself hitting a wall with how to do it in VS 2005.

An example of this would be this morning, trying to figure out whether the Locked property for controls is ported to .NET Windows Forms. Unfortunately it's not - the Locked property you find has to do with resizing and moving, not making controls editable.

Fortunately MSDN has a great resource here for people making the transition that lets you see Visual Basic 6.0 and Windows Forms compared directly.

}

Rhino Book

{

I got David Flanagan's new Javascript Reference earlier this week. My fourth edition is nice and worn, but it will be nice to have the updated perspective since so much has happened in internet time since the fourth edition was published. It's the third edition of the book that I've owned and while buying the same book more than once has a big psychological drawback, I'm especially looking forward to reading the sections on the XmlHttp (AJAX) side of javascript.

}

Firefox Hiding Namespaces! ARG.

{

For a while I've had people ask me how I did my photoblog and because I wrote it from scratch it's not really useful (and it's definitely "Me-ware": unusable to just about anyone but me). I always direct people towards Flickr but it doesn't have the photoblog experience quite like mine and other photoblogs.

This weekend I've been writing a tool called Flickr-Fu that grabs the RSS feed from Flickr and attempts to simulate the photoblog experience allowing a user to navigate forward and backward one photograph at a time. The RSS xml structure is extended by Yahoo with it's own namespace: http://search.yahoo.com/mrss - all such tags are given a "media" prefix to distinguish them from the structure of RSS 2.0. Using XPaths with .NET is pretty straight forward until you run into the namespace issue, at which point there is a class XmlNamespaceManager that you will need to tame in order to get the job done.

But before this point I was hitting my head against a wall: I could see the media:content tag that I needed to get the image URL but I could see no namespace associated with it! It doesn't follow as well-formed XML to have namespaces without some namespace URI but sure enough, Firefox was hiding the namespace URI. I pasted to IE and was able to get a proper reference to use with the XmlNamespaceManager. What a strange thing to display XML in a stylesheet but leave off the namespace references in the root element! Just to prove I'm not hallucinating, here's a screen cap:

Once the namespace issue was cleared up for me, the code was quite simple:

21 XmlNamespaceManager spaceManager = new XmlNamespaceManager(doc.NameTable);

22 spaceManager.AddNamespace("media", "http://search.yahoo.com/mrss");

23 linkToBig = xnItem.SelectSingleNode("media:content/@url", spaceManager).InnerText;

Flickr-Fu is a work in progress but you can have a look here.

}

Raganwald Responds

{

I had posted about Yegge's Agile/agile essay, trying to follow some of the interesting comments that ensued on the web. I made the following comment about Raganwald's response:

"Raganwald has the most interesting response
I've seen so far: that it all comes down to people over process and a good team
will succeed despite methodological strategy. "

He has since posted an elaboration in response on his blog - I was a little off in my reading:

"No. I'm saying that a "good" methodology cannot save a bad team. That does not
mean that a good team can survive a bad methodology. There are four
critical parts of a successful software project, and in my experience you
cannot succeed if any of them are missing. People are the first of those,
management the last. Methodology is a part of management in my view. In some
situations, strong management can impose an informal rather than a formal
methodology. But it would be stretching a point to claim that such situations
lacked process or had a bad process."

}

NULLs in subqueries

{

Here was an interesting issue we ran into this week. I haven't run into this before and thought I should share - a friend was using a subquery to filter and because of NULL results in the field his result was an empty set.

My approach to things like this is usually to use a join rather than a subquery and ultimately that's how we saw how Microsoft SQL Server was processing things. But this behavior is quite subtle so I'm posting since a person running into the same issue may Google there way to this entry:

1 CREATE TABLE #TRAN(

2 TRANID INT,

3 TRANNAME VARCHAR(50)

4 )

5 GO

6

7 CREATE TABLE #ACH(

8 ACHID INT IDENTITY(1,1),

9 ACHNAME VARCHAR(50),

10 TRANID INT NULL

11 )

12 GO

13

14 INSERT INTO #TRAN VALUES(1,'TRANSACTION A')

15 INSERT INTO #TRAN VALUES(2,'TRANSACTION B')

16 INSERT INTO #TRAN VALUES(3,'TRANSACTION C')

17 INSERT INTO #TRAN VALUES(4,'TRANSACTION D')

18 INSERT INTO #TRAN VALUES(5,'TRANSACTION E')

19

20

21 INSERT INTO #ACH VALUES('ACH 1A', 1)

22 INSERT INTO #ACH VALUES('ACH 2A', 2)

23 INSERT INTO #ACH VALUES('ACH 3A', 3)

24 INSERT INTO #ACH VALUES('ACH 1B', 1)

25 INSERT INTO #ACH VALUES('ACH 1C', 1)

26 INSERT INTO #ACH VALUES('ACH 3B', 3)

27 INSERT INTO #ACH VALUES('TEST',NULL)

28

29 -- RETURNS NOTHING

30 SELECT * FROM #TRAN

31 WHERE

32 TRANID NOT IN

33 (SELECT TRANID FROM #ACH)

34

35 -- RETURNS TRANID 4,5

36 SELECT * FROM #TRAN

37 WHERE

38 TRANID NOT IN

39 (SELECT TRANID FROM #ACH WHERE TRANID IS NOT NULL)

}

People, Process

{

Steve Yegge has a post about the agile software development process. Gifted in wit and sarcasm, Yegge doesn't spare many punches in basically saying that "Agile" as is known as a process is basically about marketing and making money for consultants. He contrasts this with a lower cased "agile" which is what he believes Google (his employer) practices and others should.

A lot of comments seem to be coming back - resistance to Yegge's comments over at The Mindset because (and I agree with this) some of the things that are true for Google (working without deadlines) just can't be true for the rest of us. The Mindset also doesn't believe that the glossy, non-substantive Agile flies with most businesses. I'm not as optimistic as The Mindset since I have seen many an organization fleeced, but I do agree that most people aren't fools. Especially developers, the majority of which I've worked with are big skeptics.

Raganwald has the most interesting response I've seen so far: that it all comes down to people over process and a good team will succeed despite methodological strategy. Interesting because especially when it comes to Google, it seems like they take the cream of the crop so it would follow that they can be so lax with all the rock stars they have working there. Raganwald seems to fit into Spolsky's camp (maybe it was Raganwald's camp to begin with) where the equation is: Good programmers + working conditions == Great Software

Dare Obasanjo is pretty straight forward with how he sees Google:
"'smart people dicking around' type projects" versus "shipping code."
It doesn't get more plain than that now, does it?

Quite interesting especially since it wasn't long ago that I listened to Jutta Eckstein talking about Agility on Software Engineering Radio. The first thing out of her mouth was:
"People over process."

I think there's a lot of frustration in the marketing and money making of Agile but the finer details seem to have a lot of things that are great tactics in software development. "People over process" is a great way for the Agile methodology to begin itself since it allows for the Raganwald/Spolsky perspective but many of the communication things are good as well. What Yegge points out as "agile" in the sense of big rewards and incentives seem to have to do with compensation, not necessarily development methodology. Pair programming, as far as I know isn't a part of Agile but this is something I've never really seen as a full time approach. One thing I've been struggling with in my current project is the weight given to doing frequent releases in Agile. Because we started from scratch it doesn't make much sense and in this case we are departing from conventional Agile. However as the framework for the software begins to take form I'll push the team for more frequent builds that the client can look at. For now, scaffolding and putting things together for others takes far too much time and all the client would see is unfinished stuff that we are well aware is unfinished. Doing "SCRUM" meetings is another departure for us - we meet when necessary but there's enough on various plates to make meeting and percentages too much overhead.

In the end I find myself seeing truth in each person's perspective: Yegge is right about some of the dogma (whether it was intended or not is another question) some apply to Agile programming. The Mindset is right that those of us who don't work at Google don't have the luxury of working without a deadline. Raganwald is absolutely right on the importance of hiring. I did two interviews this week and that was... interesting. People, especially the caliber of whom work at Google, just aren't a reality for where I work. I include myself in that category since I'm not certain I'd fare too well in their hiring process.

}

Do you test your work?

{

Most places I've been people would nod and look at you with disdain. But I can't think of a person I've met that is as rigorous as this. (Courtesy of CodingHorror)

Testing seems to have less to do with technical proficiency (what gets you the initial result) and more to do with tenacity. I'm hoping it's like a muscle too - the more it is exercised, the more anal retentive I'll become about the lengths I go to check my work.

}

Eric Sink: Code Cover, Unit Tests

{

A good essay I finally got to last weekend is Eric Sink advocating code coverage. Code coverage is simply understanding how much of your code is executed within your application. For people like me who start off by sketching, revising, and honing their work, I'm sure an analysis of parts of dead code would be quite revealing.

But there were two other peripheral things about this essay that were very interesting to me. The first was a side comment Eric makes about how many lines of code he's written in the project:

"This library consists of 12,341 lines of algorithms, plus 5,819 lines of unit tests."

What's interesting about this to me is that Eric, who is a developer I completely respect, is writing about a line of code in unit tests for every couple of lines he is writing as actual project. Ever since I became the resident nag of unit tests, trying to lead by example, I have come to realize just how much discipline it takes to have serious test coverage. As time has passed I've been happy with our choice since it's been helping us release much steadier versions of our software. I've also learned a lot about how to test our code, which I'll hopefully find time to share on this blog later.

The second thing that is interesting to me is that Eric always seems to have a side project of some kind. As a CEO of what seems to be a successful ISV this is impressive since many people I know in positions like that tend to lose their technical skills as they accumulate the managerial/strategic ones.

}

Visual Studio Environment Settings

{

First it was Scott talking about his Visual Studio environment and then it was Jeff posting some of his own settings and a website to download customized VS.NET Environment settings.

I'm usually a bit boring when it comes to things like this - I used to like the courier font at 10 or 8pt since I'm used to laptops with next to nothing in coding real estate. Otherwise everything was default.

But I've taken to Jeff's ZenBurn settings quite a bit.

I hope the IDE Hot or Not site takes off; it would be interesting to see what some other people's settings look like. Who knew Visual Studio could have a Toyota Scion style effect and bring out a person's personality?

}

Unit Testing

{

I've worked on lots of projects but never been in a position to push everyone to have a unit test for all the important pieces of the application.

Pushing for unit tests makes me feel like the resident nag, especially when it goes beyond making the proclaimation that we'll approach the project in this way and leads into my sitting down with people pointing out code that seems to work but isn't covered by any unit tests. I'd be inclined to follow up everyone's code with unit tests they could have written myself, but it's too much work for a single person.

Another difficulty is that while I get the concepts behind unit testing, writing a good unit test is proving more thought provoking and difficult than just the idea of having a test that covers a method call. Most of the articles about unit testing talk about it in terms of methods that don't seem to have as much complexity or methods that don't leverage external resources. It's easy, with articles like that to have an example of a method that adds two numbers and then has a test that asserts that two values added have a correct result.

In our case, we've got a somewhat large database that we are utilizing in most methods making how/what we test for much more tricky. For example, if we have a method:

public LoanApplication GetApplicationById(int appId){ ... }

What's the best way to test it? Thus far we've got the following things:
1. Make sure the result is not null.
2. Compare properties against database query (with a tested database library).

Our test for that method may look like the following:

[TestMethod]
public void TestGetApplicationById(){
AppService appService = new AppService();
Assert.IsNotNull(appService.GetApplicationById(1));
LoanApplication testLoanApp = appService.GetApplicationById(1);
DataTable testTable = db.GetDataTable("select * from App where AppId=1");
Assert.AreEqual(testTable.Rows[0]["AppId"], testLoanApp.AppId);
// other fields test
}

How does one get tests like this right?

}

Testing Frameworks: NUnit up one

{

After spending a long time without having the ability to impose "testing" in the projects I was working on, I'm now in the position as lead developer to make testing a part of our development process.

Last week I went back and forth with either using NUnit, which I'd be more inclined to do on my own versus Visual Studio Team's built in testing capability. I chose Visual Studio just because it would be easier for team members to get to; I can't look over everyone's shoulder and force them to write tests but I can make it as easy as possible to encourage the behavior.

Before doing so I did a search to try to see if there were major differences between NUnit and Visual Studio's testing - I don't remember anything notable but today, just my luck since we've gone full force in the Visual Studio direction, I find a post complaining of lack of functionality in Visual Studio's test framework vs NUnit.

}

Jobs

{

Joel Spolsky has a new job board.

}

REST for the wife

{

When I was teaching I'd love to ask a person to give me an explanation of a technical concept as though I was a 13 year old. It's easy to memorize the acronyms but it's much harder to unpack them, especially with enough understanding to simplify them for people that have no assumptions with respect to the concept.

Ryan Tomayko, in this case, has done an amazing thing: read along as he explains REST to his wife (who we may assume as an intelligent but non-technical person).

}

Rumble in the Jungle

{

There is a saying among Africans: "When two elephants fight, it's the grass the suffers most."

But fortunately this doesn't apply to the web; when two giants go at it, we get to tune in and watch the blow for blow, entertained.

On Friday Joel Spolsky published The Language Wars, in which he discussed an approach to picking a language/platform for application development. I believe his point had more to do with picking a well trodden path for a development project, as well as having an architect with lots of experience with your chosen platform/language. Along the way, however, he said:

... and a handful of platforms where The Jury Is Not In, So Why Take The Risk When Your Job Is On The Line? (Ruby on Rails). Before you flame me, Ruby is a beautiful language and I'm sure you can have a lot of fun developing apps it in, and in fact if you want to do something non-mission-critical, I'm sure you'll have a lot of fun, but for Serious Business Stuff you really must recognize...

The rest you can read in the post but these comments sparked a fire from Ruby on Rail's inventor, David Heinemeier Hansson who retorted quickly on his blog that Joel was full of FUD. It's an interesting exchange but Hansson points out that Joel's final thrust is about a language called Wasabi that is used at Fogbugz and completely outside the "well trodden path" or "proven platform" category he seems to espouse at the outset of the article.

Soon after the rebuttle was posted there seemed to be a lot of people who thought Wasabi was a joke that Joel was using to wink at his like-minded classicists with while stoking the fire of the Ruby hipsters - so much so that many posted that they "got the joke" maybe in part to feel like they were the clever Ivy League programmers they assumed Joel left the easter egg for.

But they were wrong, and Joel followed up with a post in which he confirmed the existence of Wasabi, while backing away a bit from controversy by not rebutting the rebuttle.

All in all, it was an interesting friday evening following this story around. I never assumed Wasabi was an inside joke; Joel's mentioned many times that Fog Creek had a compiler they used to generate Fogbugz code in PHP and VBScript amongst other languages. I didn't understand the big fuss on the part of Heinemeier Hansson either and others - the concept of a domain specific language written in something doesn't pull away its platform underpinnings. If anything the platform is a safety net of sorts. But beyond this, the most important piece of the puzzle is Joel's second point: an architect is absolutely necessary for big, enterprise software (in order to do a good job).

On the other hand I find Joel's skepticism toward Ruby on Rails as premature as the blind enthusiasm of many. There is a lot of room between "Serious Business Applications" and college projects. Many business applications are not mission critical banking - I just participated in a rewrite of a sales project management platform that could have been Ruby on Rails fodder. If anything there's going to be better, smarter business development tools as a result of the good ideas that Rails has fostered.

Time to stay tuned to the aftermath in the blog/web world.

}

David doesn't get it

{

David Pogue, tech writer for the New York Times claims (follow up here) that perhaps the reason that there are so many Wintel vs Mac computers in corporate America are because IT folks just want to keep their jobs and the viruses, spyware, and a defective Microsoft operating system help them. A corporate environment with Macs and fewer issues would, according to his logic, result in less work, a smaller budget, and a smaller IT staff.

But Pogue is missing a big aspect of the corporate world: what Visual Basic was historically, and what the .NET Framework is today. Corporate environments are filled with throwaway programs that are very specialized towards people's business needs. Without an environment like that (with serious investment) on Macs, that sort of shift is not possible. It harks back to Balmer's "Developers, Developers, Developers!"

Web applications are removing this disparity between operating systems, but I wonder if Apple sees developers as tightly bound in their corporate strategy as Microsoft does. Because they don't, and don't understand corporate software, it lends itself to the chasm between Apple computer and the business user.

ps. I'm aware of Filemaker and Xcode, I just don't think they are as good. As a thought experiment, compare how much Apple bets on these with how much Microsoft bets on Visual Studio and .NET.

}

Ruby $LOAD_PATH Watir

{

On and off I've been messing around trying to get Watir to work on my machine. The gem installed properly based on the instructions given to simple go to the command line and use the following:

gem install watir

But when I tried to execute a simple test I got the following:

uninitialized constant Watir
./watir.rb:6
c:/ruby/lib/ruby/site_ruby/1.8/rubygems/custom_require.rb:21:in `require'
C:/CODE06/RubyStart/WatirTest.rb:7
./watir.rb:6: uninitialized constant Watir (NameError)
from c:/ruby/lib/ruby/site_ruby/1.8/rubygems/custom_require.rb:21:in `require'
from C:/CODE06/RubyStart/WatirTest.rb:7

It seemed like an environment variable was not properly referencing the library but when I hunted for it I saw no environment variables. I ran the unit tests for Watir and it seemed to have installed correctly but I noticed the following at the beginning of each:

$LOAD_PATH.unshift File.join(File.dirname(__FILE__), '..') if $0 == __FILE__

Smells like a path the the library so I investigated with:

puts $LOAD_PATH

which shows me the following:

c:/ruby/lib/ruby/site_ruby/1.8
c:/ruby/lib/ruby/site_ruby/1.8/i386-msvcrt
c:/ruby/lib/ruby/site_ruby
c:/ruby/lib/ruby/1.8
c:/ruby/lib/ruby/1.8/i386-mswin32

In order to get the script working I just hacked the $LOAD_PATH to include a hardcoded reference to my Watir libraries:

$LOAD_PATH.unshift 'c:/ruby/lib/ruby/gems/1.8/gems/watir-1.4.1'

From there I was set with the following simple script:

require 'watir'

include Watir

ie = Watir::IE.new
ie.goto("http://www.t3rse.com")

I'll dig into this - I haven't had the patience to sit down with a Ruby book just yet (anyone have ideas?) but if anyone has a similar problem running Watir, here is a hack to get you started if this is a hit on your Google search.

}