Ilya Grigorik has posted a very nice introduction to bloom filters in Ruby:
Instead of storing the key-value pairs, as a regular hash table would, a Bloom filter will give you only one piece of information: true or false based on the presence of a key in the hash table (equivalent to Enumerable's include?() function in Ruby). This relaxation allows the filter to be represented with a much smaller piece of memory: instead of storing each value, a bloom filter is simply an array of bits indicating the presence of that key in the filter.
(Not to be confused with the pretty kind of bloom filters)
Starting with Merb: a collection of links
Merb homepage.
Ruby Enterprise Edition. Apparently Ruby plus tcmalloc. All the cool kids are using it.
Phusion Passenger. The Apache module formerly known as mod_rails. Version 2.0 has support for Rack. Rack is a good idea:
Rack provides a minimal interface between webservers supporting Ruby and Ruby frameworks.
The Merb docs on deploying with Passenger.
Merb is ORM agnostic so grab DataMapper too. Or maybe Sequel.
Merb focusing on controler logic rather than shoving down developers throat a particular, bloated ORM engine is a very refreshing change from current trends in web frameworks. And it continues with its choice of a view rendering policy. There is none.
Merb is not yet 1.0 and still very much on active development. Grab it from from git.
If you choose DataMapper you may want to live on the edge.
Or just follow and easy, short tutorial to get started faster.
Haml is interesting too.
One of the main attractions (a least for me) of dynamic languages are their functional capabilities. Python has crippled lambdas but makes it up with very powerful stateful generators and generator expressions, even if its scoping rules are a bit fishy.
In comparison Ruby goes in the opposite direction. Being relatively poor on comprehension syntax it makes it up by offering 7 different ways to define a block of code and pass it around, with varying degrees of scoping. Unfortunately most of them appear to be nearly identical and are being kept around just to not break old code. Investigating this matter I found this enlightening sample script from Paul Cantrell:
This is quite a dizzing array of syntactic options, with subtle semantics differences that are not at all obvious, and riddled with minor special cases. It's like a big bear trap from programmers who expect the language to just work.
Paul explains how most of this mess grew out of lacking a formal specification for Ruby as a language, and how most of the ways to define a code block are equivalent and different at the same time. The final conclusion would be to use lambda if you want a true, lexically scoped first order function, and code blocks for everything else. The script finishes with a very cool lazy evaluation example and a pointer to the Lazy gem.