Programming LOGO MINDSTORMS with Ruby (Shashank Date)

Having seen a LEGO Mindstorm robot at our CLUG meetings, I was very interested in seeing how Ruby works with the robots. The guts of the robot is the RCX brick that has inputs and outputs connected to the "nubs" on the top of the brick. Sensors and motors connect to the brick by snapping a sensor or motor block onto the nubs of the RCX brick.

The RCX brick sports 16 KB of ROM for BIOS-like functions and 32 KB of RAM containing a byte code interpreter. There is about 6 KB available for byte-coded user programs.

Shashank’s eleven year old son, Rutvik, demostrated the graphical "non-programming" environment by writing a simple program that moved the robot back and forth, switching directions on inputs from the light sensors and touch sensors.

Rutvik’s school has four dedicated PCs for programming the LEGO robots. To work with a particular robot, you must be sitting at the dedicated PC for that robot. Shashank’s goal is to use DRb to allow any PC in the lab to download programsm to any of the robots.

Using a second machine, Shashank ran a Ruby version of the program Rutvik used. The Ruby program on the client (rather than the RCX brick) and sent commands via DRb to the server machine, which in turn sent the command to the RCX robot via the IR tower.

…aside (David Black)

"Every conference needs a low point, and I’m always a team player". David confesses that he is standing in for a speaker who had to pull out of the conference. So David presented a program called aside that allows students to provide anonymous feedback to professors, and to allow professors to interact with anonymous students.

The purpose of David’s talk was not to present the program, but to open a discussion of applications vs frameworks and how to get some "half-baked" ruby programs out in the public eye. We discussed the role of RubyGarden and other web sites (e.g. CodedBliss) in the community. We had to cut the conversation short, but I’m sure the lunch time conversion

Building Environments for MUES (Michael Granger)

MUES stands for Multi-User Environment Server. MUES is the server for the FairyMUD project since 2000. It is an event based dispatcher for creating multi-user games. I’m really not up to speed on MUDs and such, but Michael’s design looked very clean and deep.

A Clueless Ruby Hacker Explores Security (Nathaniel Talbott)

Nathaniel talked about some basic issues around securing a DRb server using OpenSSL and other techniques. He stresses that security must be considered at a system level, not merely at a product level.

Teaching Ruby to Testers (Bret Pettichord)

Bret teaches a Scripting for Testers course with Brian Marick. They believe that some programming is required for automated testing, but that the programming should be easy. That’s why they use Ruby!

They take folk who have some programming experience, but that experience is stale. They might be familiar with procedural programming, but not with some of the newer paradigms. Bret and Brian use an Internet Explorer controller to programmatically control IE to interact with a web application. Bret demonstrated the code interactively.

Introducing Ruby to the Corporate World (Jim Freeze)

Jim’s perfect job involves getting paid to develope in Ruby (and not having to program in <fill in the blank>). Seriously, Jim shared some ideas for promoting Ruby in the workplace, something that most of us have dealt with in some for or another. Jim stresses the need to be honest about Ruby and its capabilities.

Jim has put together a course on Ruby for his company and is teaching it at several locations across the country.

Jim’s company also provides awards for "Productivity Wins", suggestions that save the company money. It was interesting to note that Ruby was involved in two of the first four wins in this contest and a third win copyied the architecture of a prior Ruby win.

Visions of the Future - Keynote Address (Yukihiro Matsumoto)

Finally, the moment we’ve all been waiting for, to hear news about Rite and Ruby 2. After an (short) introduction by David Black, Matz begins by saying that Ruby is "Good Enough" and that’s why we are here. So the real topic is "How Ruby Sucks", and what we will be doing about it.

First of all, Matz drew the distinction between what is Ruby 2 and what is Rite. Ruby 2 is the next version of the Ruby language. Matz plans to take advantage of the major version upgrade and introduce some things to clean up the language that are not necessarily backwards compatible. Rite refers specifically to the VM for Ruby 2.

So, with that in mind, here are some things that may by in Ruby 2.

Note:

The following is a paraphrase of the information Matz provided. The talk generally moved too fast for me to capture all the details, but I tried to capture the overall gist of the topic. If there are any inaccuracies, it is entirely my fault.

Note 2:

I discovered later that Chad Fowler had logged onto IRC during the keynote talk, and was streaming this same information into the IRC channel. Someone not at the conference was then taking the IRC information and updating the Ruby wiki pages in real time. That’s pretty cool.

• Local Variable scope. Block parameters will be block local, hiding any existing variables. Also, local variables created by "eval" will
• Instance Variables. @_foo will be truely private (not protected). Or maybe @foo will be private and @_foo protected. Matz hasn’t decided yet.
• Constant Lookup. New rule will check enclosing class, then all superclasses, then one level of nesting classes. This simplifies the rules for constant lookup.
• Class Variables. Now class variables will will be local to the class or module. Use accessors if you wish to access class variables from a larger scope.

  Question:

  How will class variables be different from class instance variables?

  Answer:

  Class instance variables are normal instance variables of the class object. Class variables will be more like static variables that are scoped by the class.

• Statements and Expressions. No implicit string concatenation (use "+"). Parenthesis will cause line continuations. Statement grouping by parenthesis will be disallowed, use begin/end instead.
• Multiple Values. Multiple value assignment is confusing. We can either separate arrays and multiple values strictly by syntax. Or we could use a subclass Array::Values < Array to return values. Matz hasn’t decided which solution he will go with. (There was a lot of questions and comments on this item).
• Method Visibilities. Private may be in a separate namespace from public/protected.
• Range in Condition. This is confusing. No one remembers the exact semantics (even Matz)
• Keyword Arguments. Finally! Here’s the scoop:

    def foo(a, b: 42, **keys)
      p [a,b,keys]
    end
    foo(1)               => [1,42,{}]
    foo(2, b: 5)         => [2,5,{}]
    foo(3, b: 4, c: 6)   => [3,4,{:c=>6}]
  

  Some Smalltalkers wanted an optional colon after foo. Matz said no.

• New Hash Literal. A new form of Hash literal will be available.

    { a: 1, b: 2, c: 3 }  == { :a => 1, :b => 2, :c => 3 }
  

• Method Combination. Pre, Post and Wrap method combinations will be available. These methods are modelled after the CLOS before/after/around modifiers.

   class Foo
     def foo:pre();  p "pre"; end
     def foo:post(); p "post"; end
     def foo:wrap(); p "wrap pre";   super;   p "wrap post"; end
     def foo();      p ;foo"; end
   end
  

  prints …

   wrap pre
   pre
   foo
   post
   wrap post
  

• Selector Namespace. It will be possible to modify the behaviors of selections within statically scoped namespace. Details are subject to change.
• Optional Type. Current strong typing experiments are class/module based. Matz is exploring options, but wants any solution to be signature based and efficient.

Matz is interested hearing about ideas, so he is encouraging RCRs (Ruby Change Requests) for a limited time (say March 2004). He wants more than mere "could we change it this way" type of requests, but RCRs should contain an abstract, motivation, proposal and rationale. Mats demonstrates an "proper" RCR#1 with the proposal to remove "proc" from the language.

After talking about Ruby 2, the language; Matz moved on to talk a bit about Rite, the VM for Ruby 2. Ruby 1.9 will be a testing ground for some items targeted for Rite. It sounds like the big push will be for dealing with M17N. The new RegEx engine (handling M17N) will be in 1.9.

You can find the slides at: www.rubyist.net/~matz/slides/rc2003/

Post Conference Activities

It was back to Club Max for another night of hacking on RubyGems. The group continued to work on it throughout the day during lunch and breaks. This evening David Black joined us.

Friday night we worked without a net … well, network. But tonight someone had enough presence of mind to snag Shashank’s network hub. Imagine this, four networked laptops in the corner of the bar with cables strung across several tables. The local club hoppers took it all in stride.

Tonight was an integration night. David supplied a version comparison module that he had worked on during the day. Rich integrated it with the code base on his laptop. I setup a CVS server on my laptop made it available to everyone. We did eventually check into that CVS system, but because of the small number of files, it was difficult to split up work in a meaningful way. Rich went ahead with the the software to create and extract gem files. Chad concentrated on the remote download and install portion. He even got a simple WebBrick server set up to serve out gem files loaded on a system.

What did I do? Well, my presentation was first thing in the morning, so I took the opportunity to finish that before doing anything else. I was able to integrate the Gem creation software into my general package task library in rake. I even slipped in a last minute slide into the Rake presentation showing how to generate gems.

It is really interesting to see how other developers go about writing software. I had paired with Rich earlier that day and the man is a code generating machine. Rich didn’t to TDD (at least not while I was pairing with him), but every step he takes is incremental and well tested by hand. He really knows how to break up a programming session into small tasks and tackle them one at a time and then put together the pieces into the final whole.

The night broke up a bit earlier than the night before. By the time we broke up, we had the beginnings of an actual working system. It was pretty exciting.

Next: the final day of the conference.