In article <5.1.0.14.0.20011107155748.05d21e30 / mail48727.popserver.pop.net>,
Brian Marick  <marick / testing.com> wrote:
>At the Ruby Conference, Andy Hunt kicked off with a talk about Ruby 
>evangelism. Afterward, I mentioned a common theory about technology 
>adoption. It's from Geoffrey Moore's _Crossing the Chasm_, which I reviewed 
>here:
><http://www.testing.com/writings/reviews/moore-chasm.html>
>
>Briefly, his book is about the difficulties a technology has making it from 
>acceptance by technology enthusiasts and visionaries to acceptance by the 
>mainstream. His solution is to concentrate on a niche market. Become the 
>obvious mainstream solution in that market, then spread to the larger world.
>
>I observe that the "markets" for CGI scripts and sysadmin scripts already 
>have entrenched obvious solutions.

Not necessarily, it seems to me a lot of sysadmins still use csh or bash 
scripts.  Some are beginning to use Perl, but I think Ruby has viability 
in this domain.  But you're right, testing is probably a very good niche 
'market' for Ruby.

>
>However, the world of testing scripts is not so settled. Those testers who 
>script probably use Perl, but there are not so many of them, and I think 
>they're not as set in their ways. It would be relatively easy to present 
>Ruby as the obvious choice for testing scripting if we (1) had scripts/apps 
>for people to use and customize and (2) had a hard core of notice-able 
>testers using Ruby.
>
>I've started (2) going. The January/February issue of STQE magazine
><http://www.stqemagazine.com> will have an article by our very own Phil 
>Tomson about using Ruby for a testing problem. The following issue will 
>have an article about how useful it is for testers to know a scripting 
>language. That article uses Perl and bash, but it will get people thinking 
>in the right general direction.
>
>Going forward: There's a web site done by the company that does the magazine
><http://www.stickyminds.com/>. I bet I could persuade them to give me a 
>"Ruby Gems" column, in which I monthly or so talked about using Ruby to 
>solve a testing problem. I have a stagnant website <www.testingcraft.com> 
>that could be pressed into service as the place to go to look for Ruby 
>testing solutions. (That's not impossibly far from the website's ostensible 
>purpose.) I'm fairly well known in the testing world, and I know key 
>players well; we could perhaps leverage that. For example, I'd like to 
>persuade Florida Institute of Technology (one of the few universities that 
>actually teaches testing) to somehow fold Ruby into its curriculum. Lisa 
>Crispin and I have started a mailing list on "agile testing"
><http://groups.yahoo.com/group/agile-testing>. People reading that list are 
>probably predisposed to innovate and join movements.
>
>All that is well and good, but as or more important is (1) - scripts and apps.
>
>So, questions:
>1) Who's got code?

I've got what I call dTest (OK, maybe it needs a better name ;-)
It's a distributed test system that uses dRuby to distribute testcases to
machines on a network and then gets results back from them.  It needs a 
lot of work to make it more general-purpose (it was originally made for a 
specific testing purpose in a specific environment - my goal is to 
'generalize' the code and make it easier to configure).  I wrote it for a 
testing application where we had thousands of testcases for testing 
language compliance and they needed to run overnight so we needed to have 
several machines running testcases.

I've also just released the Ruby Template System - This is one of the 
things I needed as a building block for dTest.  Since I was testing a 
compiler for language compliance(actually, I was also testing a 
programmable logic architecture in conjunction with the compiler) I needed 
to generate a lot of different testcase designs to run through the 
compiler/synthesizer.  In many cases, the best solution was to create 
template design files for the target language (VHDL) with embedded Perl 
(now Ruby) code.  VHDL programs were then generated from these templates.

I'm also working on a Win32 module hierarchy.  Right now I've got the 
equivilent of Perl's Win32::Process finished (for controlling processes 
under Win32 - this is also something that dTest uses).  My plan is to 
implement Perl's Win32::TestGui next - it allows you to send events (mouse 
clicks, key clicks) to windows which have a specific title (or to the 
active window).

This stuff is on my home page, currently: http://www.aracnet.com/~ptkwt
(well, dTest isn't there yet, I'll work on getting something up there 
for people to look at in the next couple of weeks)

>2) Who's willing to write code?

I'm gonna be doing that.

>3) Who's got success stories to share?

Well, I'd have to say that it isn't entirely a success yet - but I'm 
working on it.

>4) Who's got ideas about spreading the word to testers?
>5) What are those ideas?
>
>
I think, as you mentioned, reviving your www.testing.com or 
www.testingcraft.com site with Ruby information would be a good step in 
the right direction.

Phil
-- 
rm -rf /bin/laden