At RubyConf 2008, other than giving his own Scaling Ruby talk, Gregg Pollack of EnvyCasts was hard at work getting summaries of all of the presentations from the speakers. In RubyConf 2008 in 90 Seconds you get a fast-fire summary of the summaries. In RubyConf in 31 Minutes you get a more complete record - good viewing for anyone who didn't attend the conference as it gives you a good idea of what's on the Ruby community's mind.
If you've ever investigated how to build your own compiler, you might be familiar with LLVM (Low Level Virtual Machine), a "compiler infrastructure" that makes it easy(ish) to create virtual machines, code generators, and optimizers of your own. It also has its own intermediate representation language that's architecture independent and the instruction sets and typing system available are similarly language independent. In theory, if you want to build your own programming language and a compiler for it, LLVM will get you most of the way.
Ruby's most popular Web application framework, Ruby on Rails, takes another giant step today with the release of Rails 2.2! It follows on just five months after Rails 2.1, but offers even more significant improvements, particularly in the areas of compatibility, internationalization, and documentation. Read David Heinemeier Hansson's release post for a quick overview.
HappyMapper is John Nunemaker's attempt at "making XML fun again" for Rubyists by providing an object to XML mapping library with a succinct syntax. Essentially, you can use HappyMapper to rapidly turn XML into Ruby objects - even nesting them inside and referring to each other. This is powerful stuff. To install, just gem install happymapper
Testing is a firmly ingrained part of the Ruby culture: you probably ran across Test::Unit not long after you first started writing Ruby code (though it wouldn't be surprising if you ignored it for a while). But it hasn't been a static part of Ruby - we've seen the simple availability of tests evolve into test-driven development (TDD) that in turn gave rise to behavior-driven development (BDD). Along the way, Ruby has spawned a variety of testing tools and frameworks. The latest, Aslak Hellesoy'sCucumber, is the latest addition to the RSpec family of tools.
Earlier this month, Rails Envy's Gregg Pollack gave a talk at RubyConf08 called Scaling Ruby (without the Rails). He answered questions like "How do existing Ruby applications use Threads/Processes to scale?", "How do we implement an Event Driven application using Ruby EventMachine?", "What are the current bottlenecks with speeding up Ruby and how can they be fixed?", and "What does Ruby 1.9 bring to the table to speed things up?" From what I hear, it was a very well received and informative session.
Back in March, Ruby developer Gregory Brown raised the idea of receiving donations so he could work on open source Ruby projects full-time. It went well, and out of this project came Prawn, a pure Ruby PDF generation library. Not one to rest on his laurels, Gregory's now working on a book for O'Reilly called Ruby Best Practices, billed as "for programmers who want to use Ruby the way Rubyists do." The book will cover how to design "beautiful" APIs and DSLs, along with lots of other general topics that will make your code more expressive and make you a better Ruby developer into the bargain.
When you want your objects to refer to / have associations with other objects, it can quickly become a complex procedure. Ryan Daigle to the rescue! Ryan has built Roxy, a "Ruby Proxy-Object Library." He's also put together an awesome blog post with the motivation for developing Roxy and some code examples showing how it works. Roxy gives you the ability to add some rather ActiveRecord-esque functionality to your classes and their instances.
Anyone building up a project with many dependencies - and in the Ruby community, with so much functionality wrapped up in gems and plugins, it's hard to imagine not having external dependencies! - must face the issue of managing the situation in source code control. How do you maintain everything you need in your own repository, while still being able to update your dependencies from their own repository? How do you set things up so you can even contribute to the projects you depend on?
Merb - a much heralded, highly flexible Ruby-based Web application framework - has reached version 1.0 after two years of development. Congratulations to Merb's creator, Ezra Zygmuntowicz, and to the large group of associated developers (such as Yehuda Katz and Matt Aimonetti) who've kept adding features and pushed Merb forward to be a significant alternative to Rails.
We've all heard the admonitions: "Don't Repeat Yourself!" But how do you avoid this if you're working on a Ruby codebase that stretches to thousands of lines, maintained by multiple developers? One answer is to run a tool that looks for duplicate code. This is an area where good tools are tantalizingly close - there are at least three out there that are worth checking out: