This is the first part of two blog posts about Euruko 2006, the European Ruby Conference that took place on November 4th and 5th 2006 in Munich.
Arriving in Munich late Friday afternoon, we soon headed to the pre-conference dinner at “Augustiner am Dom”, together with some dozen other Rubyists that were attending (and organizing) the conference, too. After the dinner, various discussion started, and I learned lots about making Apple pies in a Sandwich maker, having sex in zero gravity with help of a rubber-band and about “Creating Passionate Boozers”. It really was a nice dinner, but we had reserved far too much space for the people that actually came.
On Saturday morning, we went to Hotel Europe, our conference place. For the first time this year, we had “theater seating”, so you had no table to place your notebook, which, I think, would have encouraged more people to hack together in the presentation-free time. As usual, power sockets were a rare resource, and the WLAN there was so freaking expensive (4.50€ for 30 minutes!) that no one I know of bought it. It provided a nice atmosphere for the speakers, and had a big enough screen for the projector, too, so giving a talk there still was pretty nice, and probably better than it used to be in previous years.
The first “presentation” was a skype’d video message of Matz’ Keynote,
which started with “Hello Ruby!”, that we were going to hear a lot of times
due to technical problems. He essentially summarized his RubyConf
2006 talk recognizing Ruby has gained popularity and everyone is
excited about Ruby on Rails. Ruby’s goal is “happy programming”. He
went on with the return of the bike-shed, and explained he was going to
skip the “boring things from the last keynote” :-) According to him,
Ruby has good things (e.g. being a sweet language, having Rails, and
of course the community, said to be “one of the nicest”), but also
ugly (eval.c and parse.y) and bad things (mainly, Ruby 2 being
vaporware for a long time now). After listing a few bike-shed arguments
(inheriting Symbol from String or not, String#lines, removing
private and public or even adding static typing), he explained
Ruby 1.8 is “Good Enough”, so we don’t need to hurry. Still, he wants
to accelerate these bike-shed arguments, he calls it “Extreme
Arguing”. That created quite a few laughs. Before introducing the
future design process, he admitted RCRs didn’t work out. What’s sure
is that Ruby will stay Ruby and Matz will keep being the benevolent
dictator. All new RCRs should contain compatibility analysis and must
not contain vague ideas. PEPs for example seem to work out well.
Also, he wants to move all discussion on mailing lists, which seem
more appropriate than web-based things. Last, he explained why he
wants to have a (more) public design process: he wants to share the
fun of language design, is tired of the slow evolution of Ruby and
that we currently are using a three year old technology. Furthermore,
he fears that other languages will catch up. He also wants to educate
developers in the community. As a side-mark, he noted that if he dies,
we should keep 1.8 untouched forever, but he doesn’t care what we do
with 1.9. At the end of his presentation, he stated that Ruby 1.9.1 will
be out Christmas 2007.
The next talk was about Win32::AutoGui by Kingsley Hendrickse, who has/had a job as a tester, where he mainly tested GUIs and Windows applications. Win32::AutoGui is a pure Ruby rewrite of Win32::TestGui, and according to him, “a library, a tool, it helps automate things”. A big part of his presentation was done by rewriting the texts of comic strips (mainly Garfield), which was pretty amusing and lightened up the talk. He also exclaimed that the interface is more important than the code, so we shouldn’t look at the code yet. ;-) After a quick demonstration, he showed a few examples of how to automate Notepad (by doing key presses and navigating menus), how he likes to organize his test scripts (a big collection of small methods, which allows reuse), how to automate the Windows Calculator, this time using Test::Unit and using button clicks. There he also managed to make his Ruby core-dump, probably due to the presentation effect. ;-) He went on with an overview of available methods and future features he already has planned. The project will be soon on RubyForge, he stated.
After this, we had a talk about Ruby For Enterprising Testers by Mike Lee which actually was split into two parts, the second one described below. Mike has been using Ruby for one year now, but he doesn’t use Ruby for the beauty of it, but because it works for him. “It makes idiots like him capable”, he said. Mike works as a tester for an enterprise, and explained that effective (or lazy!) testers should automate their tests. After a quick overview of the testing process, he concluded that reporting really matters for enterprise usage, and it’s important to automate the testing incrementally so it will never break for a longer period of time. To the enterprise, Ruby is dark and dangerous witchcraft, so one needs to be careful on how to sell Ruby. He said it was easier not to ask for permission, but come up with ready-made solutions, which luckily are easy and quick to do in Ruby. Minimizing disruption also is very important for real life usage. Last but not the least, he said that if they want documents, write them; it means they like what you are doing.
The second part of the presentation (they work together) was titled “What I’ve learned since Euruko 2005” by Stefan Kaemper. He said he learnt “so much”, and not only about testing, but also about approaching learning languages. According to him, there are two approaches towards learning languages: Either “start original, get good”, which gets you going fast, or “start “good”, get original”, which in the end results in more maintainable code. However, it also needs more time: being fast and maintainable isn’t easily achieved, especially since “Software Industry” isn’t really an industry, but more like good craftsmanship. He went on with their obstacles in writing a testing framework: they had to learn about the business, architecture and design the framework, then implement it, deliver executed test cases, and all that in less than three months and without budget, or written requirements. He concluded his presentation with an rough overview of the framework and the API they use.
The next talk was Ruby on Rails for Java Developers by Mariano Kamp, which actually was done really good, but somehow we were not really the right audience. It started by dabbling into very basic Ruby and later gave an again pretty skin-deep introduction to Rails, always comparing it to Java. So, it was a really good talk for some Java audience, but somehow at the wrong place for Euruko. That’s my impression, at least.
After this, we had a talk on Specter, an ‘expect’ for Ruby by Hal Fulton,
who was probably the most prominent Rubyist in the audience this year.
(He came with help of a grant by Ruby Central, thank you guys!)
He started by explaining what expect is: a TCL-based tool for
manipulating text/console-based programs. He wrote a pure Ruby
implementation dubbed Specter, which works with any IO-like object.
Also, it understands regexps almost everywhere and uses blocks in a
Rubyish fashion. Of course, it’s also highly configurable.
Apparently, it has been around since 2004, but I have to admit I
hadn’t heard of it before.
Then, he went on with an explanation of the API used: #send sends
strings, there are various ways of delay and timeouts, #wait,
#wait_any, and #wait_do (that takes a hash to Procs) expect
strings. He showed a demonstration of it scripting colossal cave, an
old text adventure, and also showed how to connect two instances of
GNU chess so they’d play against each other. Since Specter is useful
for testing, too, he took some time and showed how to use it together
with Test::Unit as well. Although there still are a few bugs and TODO
items (mainly making it faster and having more examples), it has been
used by a friend of him to connect and script real mainframes.
The next talk, and probably the best one that day was Ten Things I Hate About Rails by Paul Battley, whose title slide already rocked: He reused the style of the movie “Ten Things I Hate About You”, which he of course adapted appropriately. The purpose of his talk was to take “an opinionated look at some opinionated software”, and though he doesn’t deny that Rails is great (It made Ruby popular, has a focused community and people now get paid coding Ruby), there are quite some parts he considers bad stuff (the high S/N ratio around Rails, some design decisions), so all in all, Rails could be better!—Not at least because of the way people write code for rails reflects on Ruby.
His points were:
HashWithIndifferentAccess, where he actually quoted me saying I consider it a design smell, because using a lot of Symbols troubles the memory and it’s really confusing sometimes, too.That Symbol fetish, he wondered if it’s due to the color of them in TextMate? He also complained about deprecation of
find_firstwhich got replaced byfind(:first), which really doesn’t make it faster or serves any purpose.Metaprogramming, which makes a lot of Rails code confusing. Repetition can be helpful at times, especially if you are not saving a lot with metaprogramming.
Routing, since the routing code is just ugly (it seems to be JIT-compiling Ruby!) and actually contains quite some duplication.
The Tests, since although it has a lot of tests they often are not clear (
test_destroy_just_kidding??) or not complete.Fixtures, which make tests brittle, and keeping them coherent is difficult.
Scaffolding, which seems to be “more useful for selling it on screencasts than for programming”…
ActiveRecord, because it makes it easy to write unscalable code.
That security incident, having the fix for a fix?
JavaScript helpers, since they are very obtrusive.
(it goes to eleven!),
acts_as_*, which are really poorly named (Example:acts_as_ferret).
The last talk on Saturday was about
Generative Rule-based systems using an interactive Ruby DSL by Mark Rudolph,
who worked at SGI, but now works on image evaluation for the ISS.
He enjoys doing 3D-graphics, but doesn’t like to model, so he uses
rule-based systems, which consist of facts, rules and an inference
engine to apply these rules on facts. He is encoding style into a set
of rules, which then acts as a collective swarm. This way, one can
create complex behavior out of simple rules (kind of chaos effect).
The whole thing works as a generative process: start with an axiom,
apply rules to facts (or facts to rules), then the working memory
accumulates a growing structure of facts, and the rules act as a
collective swarm. He also added semantics to the rule engine, so he
can have fact inter-relations, ‘tags’ on facts, a means for
‘accumulation’ and ‘reinforcement’, for example to allow creating a
given shape and even dynamically alter the character of facts.
The talk ended with an detailed explanation of how it works internally
(He is using method_missing to create seeds, using the rules as
visitors over an object graph and finally flushing (or serializing)
the graph tree as VRML.) It was too bad the system is not yet ready
to actually serialize the objects, so he couldn’t show examples of
what his systems produced.
After this, we went to Kilian’s Irish Pub and I had some very nice
discussions after dinner, mostly with the members of #ruby-de, where
we started with some easy physical questions, moved on to math, group
theory, then category theory, later computability and got quite
philosophical in the end. It was a big fun.
That’s how day one of Euruko ended, move on to day two.
NP: Dire Straits—On Every Street