Monthly Archives: March 2008

The closing Jimnote at MountainWest RubyConf

Many of us call the opening keynote of WWDC by Steve Jobs the Stevenote. Well I’m dubbing the closing keynote of MountainWest RubyConf the Jimnote in honor of Jim Weirich. But… maybe I’m too late. It was sort of like watching a Mike Tyson fight (back when he was his prime and KOing people in 90 seconds.)

Jim gets up, tells us that this is the most important thing that programmers should know and brings up three slides:

K.I.S.S.

do it

end

and sits down.

OK – here he comes and more fired up than ever.

A brief tutorial on LISP.

syntax: s-expressions (s-exps), atoms, lists

nil is the same as empty list

functions: car == head, cdr == tail (trivia: car is address register, cdr is decrement register), cons, eq, atom

special forms: cond, lambda

LISP is turing complete with just this small set of rules.

Now we go into a discussion of how Jim solved the problem of showing the same graphics between an 8-bit memory-mapped 8080-based computer and a 16-bit vector-based PDP11. The answer: FORTH.

FORTH “words” (like Ruby methods) were very short and FORTH itself used reverse polish notation (RPN.) Jim learned about factoring properly this way. To port FORTH all Jim needed to do was write some primitive words (aka graphics drivers.) Note that Jim says that Nintendo console games were written in FORTH.

UDFs – now we’re looking at unducted fans engines which has spinning blades which would pull in air into the engine but did not succeed.

But… designing these engines was an interesting gig. It did involved multiple threads that access shared data. Which is a huge headache. Perhaps a way to help with this would be to avoid system locks but this worked out to one chance in a million of failure. Which seems like good chances, but it failed roughly once a day (since it executed roughly 1.5 million times a day). The point is that writing threaded applications is hard especially when accessing shared modifiable data.

Which brings us to Erlang…

There’s four types: Atoms, Variables, Tuples, and Lists. Hmm I think I see how this starts to form a Moebius strip.

You can’t change a variable once its assigned, which is actually pattern matching. I would call this immutable data. I use immutable data when passing objects between threads in my Cocoa apps.

Then we go into a client/server example in Erlang and it starts to remind me of Cocoa’s Distributed Objects.

In Ruby you send messages to objects and in Erlang you send messages to processes.

We’ve come up with really complicated systems. Jim shows a code example with 6 different languages/frameworks in one html snippet that shows HTML, CSS, Java, JSP, taglib, and JavaScript.

Erlang in comparison is simple, powerful and spawns processes quickly. Ockham might have approved.

“There are two ways of constructing a software design: One way is to make it so simple that there are obviously no deficiencies, and the other way is to make it so complicated that there are no obvious deficiencies. The first method is far more difficult.” – Tony Hoare

We live in a (programming/business/consumer?) society that values complexity. In the Ruby world, we’ve come up with Camping, Merb, and Rubinius.

So in summary: Simplify.

  1. Small core.
  2. Simple rules.
  3. Powerful abstractions.

Follow-up question: Where do you draw the line between simplicity and metaprogramming? Answer: If it solves a problem you’re having, go ahead and metaprogram – as long as its a significant amount (more than one line or so.)

MountainWest RubyConf Day 1

Well we’re 3/4ths of the way through MountainWest RubyConf. It has been a pretty interesting conference so far. Yesterday was jam-packed from 9AM-9PM (with breaks for lunch and dinner – we are human after all.) Today we are doing the same and the afternoon sessions are about to start. I was pretty lax about blogging about RubyConf which was a mistake:

I learn more when I write about what I’ve learned.

Its sort of the same process where you learn more when you teach something to someone else. Except you’re not teaching directly to someone and that someone may be your future self. It may be insane to talk to yourself but googling and then finding a past post that is relevant makes you glad you wrote that down.

Here’s what’s happened on Day 1 of MountainWest RubyConf:

Evan Phoenix gave a talk mostly on how to properly manage an open source project with Rubinius as the example. The key here is encouraging community involvement. Rubinius for the uninitiated is a Ruby VM in the style of the original Smalltalk VM that will prune to the absolute minimum the amount of code that is NOT Ruby. In comparison, MRI which is the default Ruby implementation has a lot of C in the “kernel” portion of the VM.

Watch the video of Evan’s talk.

Ezra gave a good talk about Merb. It seems to me that Merb is emerging as an important counterpart to Rails. In addition, there are other application servers that are also coming up to complement Mongrel, like Evented Mongrel and Tiny. The basic justification to use something like Evented Mongrel + Merb is when you have consistent, short-lived (1-2 seconds) requests like for a webservice. I think that Merb is also still popularly used to handle file uploads in Rails applications.

Two funny yet valid quotes from Ezra I think also illustrates the need for Merb (vs just building out everything in Rails): “Throwing more servers at the problem only goes so far…” and “Premature Optimization is the root of all hosting bills.”

Watch the video of Ezra’s talk.

One interesting note is that EngineYard who is a sponsor of MountainWest RubyConf employs both Evan and Ezra and helps to fund their projects.

Ok… afternoon talks starting – more later.

Update: I added links so you can watch both of these talks in streaming video courtesy of Confreaks.

What to do before you do Ruby on Rails development on Mac OS X Leopard

Apple has a new series about Ruby on Rails development on Mac OS X Leopard. Its a nice article to help get you going. One thing I’d like to reiterate is that it is good to lock down your RubyGems paths. This way you will always that your RubyGems go in the right directories that Apple has set up.

So before you follow the steps in the initial Developing Rails Applications on Mac OS X Leopard article, you should take the following steps:

  1. Open up ~/.bash_profile in your favorite editor (create it if its not already there)
  2. Type in
    export GEM_HOME=/Library/Ruby/Gems/1.8
  3. Type in
    export GEM_PATH=/System/Library/Frameworks/Ruby.framework/Versions/1.8/usr/lib/ruby/gems/1.8
  4. Save ~/.bash_profile
  5. Execute
    source ~/.bash_profile

This makes it so that no matter what version of rubygems you have, you have access to the Apple-provided gems in $GEM_PATH and you’re able to install/update new gems in $GEM_HOME.