Sequel: The Database Toolkit for Ruby by Jeremy Evans

He's not the original implementer of the Sequel module. He's improved it quite a bit. He added Jruby and Ruby 1.9 support, among other things.

Sequel is a domian-spefic-language (DSL) for Ruby for dealing with databases. It's not designed with web apps in mind, although it does work with them.

He spoke very quickly, as he was constrained for time. Sounded interesting, but was a bit hard to follow due to the speed.

sequel_model - an ORM build on Sequel

He uses it successfully with the adaptors for Oracle, MySQL and PostgreSQL adaptors. Has a thread safe connection pool. Insures db connections aren't leaked.

Sequel::Dataset sets it apart from other Ruby db libraries.

You can write complex SQL data queries without writing SQL, although you can if you want.

• Dataset Graphing
• Pagination Support
• Create table, Schema modification, etc.
• Master/Slave databases -- requires no modifications to your code.
• Sharding/Partitioning - simple to support with Sequel module
• Bound variables /might/ be faster, but don't depend on it.
• Prepared statements are similar to bound variables, but potentially faster. Only use after profiling/benchmarking.

Has a command line client called 'sequel'. The -E option causes all SQL to be echoed to standard output.

The future: Sequel 3.0. Many features will be moving to plugins, and the majority of the work is already complete. It's going to be easier to use, and require less memory.

Q: Does it support sharded database migrations?

A: No, not at this time. You can submit a patch.

Rails and Merb Merge by Yehuda Katz or The Future of Rails 3.0

Engine Yard has a new offering called Solo

ActionORM is a way of specifying an abstraction around an object. It makes any ORM look like ActiveRecord. He mentioned Rack integration.

Merb provides some middleware. Rails added various middleware. It's easy to use different kinds of middleware stack pieces.

Orchestra - an idea to build a module that is a common instrumenting framework for SQL and web frameworks.

Speed of languages: Ruby 1.9 and JRuby are very close to Perl in speed. He showed Python 2 as faster than Ruby 1.9 and Perl. Ruby 1.8.6 is the slowest of the comparisons he had posted. I just hope we all remember that speed benchmarks aren't worth much.

He spoke quite a bit about community agreement and standards. Perhaps that's a sign of the growing maturity of Ruby.

Rack Middleware by Jon Crosby, an employee of Engine Yard

He started by showing an example of monolithic Perl CGI, and moved quicky to Rails. Then he moved to talking about authentication and Rack. I was a bit lost as to what Rack does, or why I would care -- probably because I'm not a middleware developer.

Authentication: OpenID + Oauth Rack is the Web. The Web is Rack Rack is based on WSGI. It's a webserver interface. http://rack.rubyforge.org/ "Rack provides an minimal interface between webservers supporting Ruby and Ruby frameworks."

He showed some examples of rack.

• Rack::Pool:Session
• Rack::Profiler
• Rack::MailExceptions
• Rack:CSSHTTPRequest
• Rack::Cache - highly recommended

Cooperative Middleware Take a look at URI spaces CloudKit - and Open Web JSON client http://getcloudkit.com/ - expose :notes, :todos Has an OAuth plugin "filter"

"Via" HTTP headers. Used by Rack middleware

env['cloudkit.auth'] = 1
env['cloudkit.via'] << 'cloudkit.filter...'

Alternative stacks

• Rack::Map could let you create two apps for your same blog - a public and a private one.
• Rack::Map + Sinatra 0.9.1

Question: How do you detect colissions in the URI namespace?

Answer: There's no facility in Rack to do that. It's a good time to work on it before Rack hits version 1.0.

I'm attending the third annual Mountain West Ruby Conference in Salt Lake City. Since my notes may not represent the speakers accurately, it may be wise to read the summaries of the presentations over at the over at the web site. I'm taking notes for each of the speakers, and I'll prefix the title of each blog post with "mwrc".

Code Reading by James Edward Gray II

Little Big Planet: A cool PS3 game that people have created levels for. It's interesting to see the code that shows how people create levels.

Why is code reading important?

• Shows common idioms
• Get better at working on other's code
• Understand how something works
  • Understand limitations
• Seeing bad code helps you write better code
• Always need more ideas

rest_client: Networking code done right You can tell from the structure that it's clean code. He showed us the ugliest parts of the code, and it looked clean.

Restful-shell: IOD shell If you create a log file, it's executable code that you can then edit and enhance.

He created the Towers of Hanoi for LittleBigPlanet. He had to redesign the playing interface serveral times to get it to fit into the game correctly.

FasterCSV

Sometimes users want to work using indexes of columns. Other times, they want to work with column names. Sometimes, column names repeat. This library was one of the first users of the new Ruby m17n libraries, and he found a lot of bugs at that time.

BJ, Slave, Terminator: Ruby libraries to build multiprocessing UNIX software. Built to be very robust.

• Terminator is better than Ruby's timeout handlers. "plottokill pid"
• BJ - robust background priority queue for Rails. Notices changes from outside world via signals.
• Slave - multiprocessing with built in IPC. Heartbeat.

The Art of Code Reading

• Take a deep breath and relax
• Not all code sucks
• Don't start with Rails. There's a ton of great stuff in there, but it's really complex and hard to follow.
• Have a goal. "How does it do that?"
  • gem unpack
• Start with the tests
• Check for "examples"
• Try irb: irb -r