One of the first examples of using IronRuby on the web, possibly the first since it was the announcement of the project, was Scott Guthrie announcing the project and using WPF way back in 2007.

We’ve come a long way since then. But that’s all been internal to IronRuby. In addition, I’ve not seen the community truly embrace IronRuby as it has had some growing pains. I don’t mean to dis those working on the project, just look at my non-existent commit log to see how much of a leg I have to stand on if I where to dis them. I mean to say that I’ve not seen many people talking about using it in production. And until we see production IronRuby, we won’t be able to tell the wider .NET world how awesome working in ruby really is.

Confession, this is the album where I stopped listening to REM. Dunno why, because Monster was one of the best albums I never bought.

Let us review our strategy, especially referencing our usage of White. I find it interesting that Test Complete makes it so hard to “do the right thing” as propounded by both Scripting GUI Tests in Ruby and by White. And just what is that?

The responsibility of the test script is to

• perform a series of actions and verifications.
• allow someone to read the script and understand what the hell is going on.

I’ve been continuing my exploration of IronRuby and White for gui testing. I expected to deal with Automation IDs first, but I’ll get back to that. For now I’m tying IronRuby to White, and handling generics.

My install of white is not in the GAC, so I’ll be requireing DLLs from a directory. DLLs are looked for in ruby’s $LOAD_PATH, just like ruby libraries. It’s an array. You’ll notice that White suggests also including an NUnit dll, but I’ve not needed that with RSpec. And, I want to shorten the namespace stuff. So let’s start with white.rb and we’ll add to it later.

white_loc = "C:\\Projects\\Libs\\White_Bin_0.18"
$LOAD_PATH.push(white_loc)
require "White.Core.dll"
Application = Core::Application

I’m currently involved with a WPF project as a tester.  My charge is to automate the System-Level testing of this project for my client.  Our belife is that automated testing allows us to find “popup bugs” before they become a problem.  This has worked well, in combination with the team doing a degree of dog-fooding.  They catch the esoteric things, I find the simple things no one looks for.  Also, I’m currently working with a lot of them as we build manual test scripts for our verification phase.  This is a lot more focused act that, once automated as we move forward with version two, will allow us to have a better understanding of the “shipability” of our software.  We’re regulated and we want to automate most of the acceptance testing, at least in theory.

When I started my DSL talk for los officiea, I was looking around for neat DSL things to add when I found Irony.  I found it at a Lang.NET talk.  Then I wrote a small DSL to define some geometric circles.  So, here’s a quick rundown of how I made it happen.

Irony is used to define a parser.  Inside the parser’s constructor, we build the BNF tree that describes the grammar.  When that’s done, Irony will spit out an Abstract Syntax Tree (AST) that we can use for “real work”.  Let’s take a look at some of the grammar, before we see the Parser code.

program <- shape +

shape <- circle | polygon | rectangle

circle <- circle point radius number

point <- [ number , number ]

What this looks like is the program ‘circle [100, 150] radius 35’.  It gives me circle with a center and a radius.  What’s that look like in C#?  Or at least the circle bit?

I just started a talk about DSLs.  I’m posting the slides for consumption.

Slides

Slides w/ Notes

I’ve been working on a presentation and some other stuff all month, but I had to work on a T-Shirt idea for IndyALT.NET.  It’s been nagging at me for a while.  And it was fun!  It has been far too long since I pushed pixels!

Last week, IndyAlt.NET had a series of lightning talks that was a lot of fun. We where covering tools we’ve used. It was kind of a show and tell night.

Turns out that giving lightning talks are a specialized skill. I learned some things and I want to share.

There are two types of things you can talk about, small things and large things. This seems obvious, but you need to know which one you’re covering.

Small things: You may run under. This is okay. State the thesis quickly and up front. “Why do I care”. It can be cool, address a problem, or just be “pink”[0]. You can cover some neat use cases in that time.

Large things: It’s fine to not hit detail. Think of this as an overview of your thing. Give me a hook so I want to look into it more. I want to see why I want to look into this tool. Think of this as a 5 minute infomercial for the “Rolly”, not a lifestyle comercial for a cadillac. If it’s open source, I should want to commit to it. If it’s a product, I want to use it. If its a cool technique, I want to do it.

[0] My wife eleveates “Being Pink” to core functionality. When she got her pink Razor, that was its defining and most important feature. She was shocked to find out she likes her iPhone more, but she had to get a pink case for it. It was a moral imparative.

There is an erlang syntax that is beloved by OO converts to the language,  the parametrized module.  Here is why.

> Obj = param_example:new("Tony").
> Obj:name().
"Tony"

This Syntax makes an OO guy feel cozy.  And taking a look at the implementation of our module, we see the the implied variable is defined on the module definition.

-module(param_example, [Name]).
-export([get_name/0, set_name/1]).

get_name() -> Name.

There is a caveat.  If a module is parametrized, all functions are parametrized.  You cannot use non-parametrized functions to wrap your parametrized function, like this.

> Obj = param_example:new("Tony").
> ListOfNames = param_example:new_from_list(["Tom", "Dick", "Harry"]).

In fact, there’s some magic, functions actually have an arity of one more than you think. Actually, an extra parameter for each module parameter. In addition, these are constant, like all erlang variables. Since you don’t have access to a recursive call stack, you can’t change them.

However you can use a separate module to front- end the parametrized calls. And “mutating” calls can return new instances with new parameters.

So when Is it a good thing and when do you not want to use it?  I like the idea of using parametrized devices to wrap a bunch of data I’m going to be passing around but still has some functionality that needs to be called.

The scenario I didn’t find it useful for is having several processes that I can call without having a reference.  More concretely, I need to have rooms addressable via names of some other soft reference.  And their variables need to be modifiable. I abused named gen_server services for this.

-module(named_example).
-behaviour(gen_server).
-export([start_link/2, get_description/1, handle_call/3,init/1]).
-record(room, {name, description}).

server_name(Name) -> list_to_atom( lists:concat([ ?MODULE, "_", Name])).

start_link(Name, Description) ->
  gen_server:start_link({local, server_name(Name)}, ?MODULE, #room{name=Name, description=Description}, []).

get_description(Name) ->
  get_description:call(server_name(Name), description.

handle_call(description, _From, State) ->
  {reply, State#room.description, State}.

So, there are two ways of dealing with a collection of processes that are cleaner (don’t use the raw message send) than just passing around a Pid.  They do different things, but might could be used in combination.  I’m just not sure how, yet.

Oh, hey. If you have a better solution, please post a comment.

I kind of mentioned this project at the tail end of the big py country post. I’ve been spending some time writing a rudimentary MUD in Erlang. Why? MUDs are fun. I want to know if Erlang is a fit for any future SEP projects. And I’m interested in what it would take to do the same thing on the .NET platform.

So, what do I mean by ‘rudimentary’ MUD? I want to connect via telnet. I want to issue commands. I want to move from room to room. I want to create rooms. I want to create items. I want to meet others waking around the mud. I want to run my mud across a cluster of servers. But, at this point scripting and combat aren’t in scope.

While I’ve made progress, Holidays happen and it will probably take a few weeks longer than the one week I was originally planning. I’ve got my telnet and command parser. I’m logging in and storing my users in the world. And that’s where I am right now.  It’s not just to holidays, it’s also learning a new language and it’s libraries.  I’ve had to fight with the dictionary for a while, then there’s some missing commas that keep cropping up.

I’m still trying to figure out the finer points of OTP, which may cause a rewrite of my telnet service.

Once I’m done, I’ll be putting together a more complete post on the project and start using this as a referance for a .NET implementation. Now, the .NET implementation may only be a roadmap and a short talk comparing the two platforms. Either way, this should be fun.