MountainWest RubyConf 2008 Videos
Evan Phoenix is the creator of the Rubinius project, a virtual machine implementation for Ruby. This isn't really a technical talk about Rubinius, but more an update on the current state of the project (it already runs irb and RubyGems (09:12)) and an illustration of its extremely open development process. Evan says that one of the biggest outcomes of the project so far is its giant Spec suite (7:08). He then presents nine points that are vital to the success of the Rubinius community and can also be used as guidelines for other open projects:
- No task is too small (17:55)
- Every contributor has worth (20:05)
- Every contribution has worth (21:22)
- Asking for forgiveness is better than asking for permission (21:44)
- Debate is healthy (22:26)
- You are not your project (24:31)
- The "Keys to the Castle" is a myth (29:47)
- Foster experimentation (33:38)
- Excitement is contagious (Lead by example) (38:00)
Ezra starts with an introduction to the web framework merb, explaining the fundamental principles and key design considerations, like the merb motto "No code is faster than no code". He not only talks about merb, but also gives an introduction to Rack and GitHub.
- Why he started merb and why Rails isn't always the best solution (07:00).
- What's new in merb (10:43).
- Quick introduction to Rack (12:43).
- Merb::Router (21:16)
- The components from merb-more (30:46).
- A few words about merb-plugins (34:48).
- What's cool about GitHub (36:22).
- How merb's parameter passing for actions works (46:45).
Giles starts with the Greek letters pi, lambda and the word meta to lead over to metaprogramming (5:25). He argues that we usually don't really do meta programming but meta-OO. The first live demo is about Ruby2Ruby (6:28) and turns a Rails model class back into ruby code to see the magic Rails worked.
Giles is a very entertaining speaker, and I recommend watching the whole talk. Here are some entry points:
- Why monkeypatching isn't always appropriate (12:15).
- How he monkey-patches monkey-patching itself (meta-monkey-patching) to generate a script that visualizes an objectgraph (14:33).
- Code Generation in Action, a book every programmer should read (26:14).
- He takes a look at Lisp (29:12) and why he thinks that nobody uses it.
- Ruby, compared to Lisp and Perl, has a good balance of simplicity and magic (38:20).
In conclusion, his main point is that everyone should read Code Generation in Action!
Jeremy believes that most programmers don't use Ruby's objects right, so his talk sheds some light onto advanced topics like singleton classes and the
- What are objects? Definition and comparison to other languages (04:19).
- Behavior: Ways to change an object's functionality (8:19).
- Dynamism: The family of
- Advice: Prefer
- Practicalities: DRY'ing up your code and best practices (16:09).
The talk lasts about 20 minutes, the rest of the time is spent on questions.
Life cycle and maintenance accounts for 85% of software costs (11:55), so software needs to be readable. This can be achieved with DSLs. Joe starts with the classical example of the Starbucks DSL (13:41) and explains why Ruby is so well suited to write DSLs and where its ingredients came from (24:10).
The second half of the presentation is about a tale of 3 DSLs (31:31):
- Act 1: "oops I created a DSL", about tasks in rake and how Jim Weirich accidentally created rake.
- Act 2: Consistency, an example of custom asserts in rails models (37:19)
- Act 3: Business Language, on how to use a DSL to make specifications readable and verifyable for the client (42:53)
Jim's real keynote is titled "Anything I Want to Talk About", and starts with a very nice (and 5 slides long) quote from Fredrick Brooks' "The Mythical Man Month" about the nature of programming. He continues with the story on how he became a programmer (5:40) and the very first Lisp code he saw (6:56). The next 10 minutes are an introduction to Lisp, explaining the basics of Lisp and why it is so powerful (21:24).
He continues with his first software project, implementing fancy graphics stuff for some generals, using spare hardware nobody else wanted to use. They had to work with two extremely different architectures and assembler languages (26:10). To work in this hostile environment, they ported Forth to both systems, which was relatively easy because only a very small core of Forth is machine specific (34:53).
On a later job, Jim needed to work with a multithreaded system, which brought him to the conclusion that threaded programs are hard (46:39), and so he continues his presentation with a language that excels in this discipline: Erlang (47:25). What follows is a ten minutes introduction to Erlang.
The end of the presentation consists of a few remarks about why we are always tempted to create overly complex software (01:00:20) and a quote from Tony Hoare (01:05:32) about the two ways of constructing a software design. Fortunately for us, there are some promising trends (01:08:05).
Note: InfoQ just published a video interview with Jim Weirich, talking about rake and DSLs.