David Heinemeier Hansson has announced the release of Rails 2.1.1. You can get up and running with:

gem install rails --version 2.1.1 — remember to prefix with sudo, if appropriate!

Rails 2.1.1 is just a maintenance release of Rails 2.1 but, significantly, patches the REXML vulnerability - so if you haven't done that patch yet (naughty, naughty!) then just upgrade to 2.1.1 and you'll be good to go.

David also points out that a beta release of Rails 2.2 is "quite close" now.

The developer of NeverBlock, Muhammad Ali of eSpace, has written a compelling blog post called Building the Never Blocking Rails, Making Rails 12X Faster where he outlines a number of improvements and changes that can made to Rails to send its performance through the glass ceiling. It's worth noting, however, that the performance increases revolve around removing blocking operations (e.g. database queries that lock up a single Rails process for long periods of time) rather than truly increasing the "performance" of Rails at the base level.

eSpace say there's a lot more where this is coming from and they're due to release some very interesting projects in the near future around this theme. Keep an eye out - we'll be posting about it here on Rails Inside.

This post is sponsored by AlphaSights Ltd - AlphaSights are recruiting. If you're looking for a Ruby on Rails opportunity, can work in Cambridge, UK and enjoy the buzz of a brand new well-funded startup then look no further. AlphaSights are recruiting from entry level to senior positions and offer very competitive salaries and a great working environment.

Although Radiant may not be as well known among many Rails developers when compared to other Rails based CMS solutions such as Typo or Mephisto. Radiant is a powerful solution that has been steadily growing in popularity over time. Recently there have even been a number of Radiant specific openings posted around the Ruby and Rails job sites as more enterprises and agencies have begun adopting Radiant as their preferred solution for CMS capabilities.

Current lead developer Sean Cribbs recently posted about an upcoming Radiant Sprint Weekend designed to bring together a group of coders, designers and writers to Carrboro, NC with a focus on creating copious amounts code, design, and documentation for the upcoming 0.7 release of Radiant CMS. So I caught up with Sean to ask some questions about Radiant and his upcoming Sprint Weekend.

What is Radiant?

Radiant is a content management system that strips away all of the unnecessary junk that you get with most CMS software. It distills the essence of building a mostly-static site down to the essentials - pages, the actual content of the site, organized hierarchically in a tree; snippets, reusable pieces of content; and layouts, the wireframes or 'design' of the site. It ties these three pieces together with an elegant tag-based template language called Radius that gives the designer complete control over the output while making many common needs — generating navigation or showing the five latest articles, for example — very simple to perform. All of this is accessible from a simple and straightforward administration user-interface. Radiant also includes an automatic 5-minute page cache that speeds up response times while keeping the content reasonably fresh.

Why would a developer want to use Radiant?

Radiant isn't just for publishing static sites. We realized about two years ago that the most common use-case for a CMS is where someone has a site with a lot of static content, but some customized non-content-oriented functionality is needed too. Luckily, Radiant is built on Rails, so it has a lot of the tools that developers need baked-in.

However, it was hard to keep concerns separated and support all the needs that developers had with only the Rails plugin architecture. So in an effort to support those needs, the dev team built a mega-plugin system that we call "extensions". The beauty of extensions is that they work like plugins, adding their functionality after the rest of the framework is loaded, but they look like miniature Rails applications. An extension can have an app/ directory with all the typical Rails stuff, database migrations, public assets, plugins, routes, and a Test::Unit or RSpec suite. Extensions can modify the core of Radiant functionality through metaprogramming and even define their own page-types and Radius tags. Furthermore, there have been recent efforts to make sure most elements of Radiant's user-interface are customizable on the fly, allowing you to inject your own view code into any part of the interface.

It was funny — at the core team panel at RailsConf 2008, someone asked if Rails plugins would ever fully support routes and migrations. The consensus from the core team was a tentative "no". I wanted to jump up and down and yell, "Hey! Radiant does that!" Its extension system has been borrowed for use in the awesome e-commerce software Spree, and inspired a recent plugin architecture enhancement called "Desert" from PivotalLabs' Brian Takita.

Radiant also has a commitment to code quality. We're always trying to make our test-suite better, and we value clear code over clever or compact code. Sometimes this means our development cycle moves slower, but it's more important to get it right, in my opinion. The biggest blunders I've made over the past year with Radiant were in haste, which, to me, further drives home this principle. The extension system also helps us keep the core of Radiant tight and free of fluff.

What distinguishes Radiant from Other Rails CMS's (i.e .Typo, Mephisto, etc)?

Unlike Typo, Mephisto, El Dorado, and others, Radiant is a general-purpose CMS. Radiant doesn't aim to be portal software, nor a wiki, nor the best blogging software. You can create a blog with Radiant — and many of our users do, myself included — but you can also make a slick brochure website, or an art portfolio. Because there's few limitations on the ways to structure and manipulate content, you can make practically anything you want.

On the other hand, Radiant lacks a lot of the features that other CMS software provides; however, we tend to see this as a strength rather than a weakness. "Simplicity" is a core feature. If you need some feature Radiant doesn't have, we encourage you to build an extension to do it, or to seek out software that does it better.

What is the history of Radiant?

John Long, the original author, could answer this better, but I'll give it a shot. Radiant began in late 2005 as part of the redesign effort for the Ruby language homepage. After the identity team had designed the look and feel of the new site, they needed an elegant CMS upon which to build the site. Obviously, they preferred it be written with Ruby, and Rails was the new hotness at the time. Thus, Radiant was born. Ruby-Lang.org stands to this day as the longest running site on Radiant. It even survived the Slashdot effect following the release of The Ruby Way, 2nd edition.

The first public release of Radiant, version 0.5, was released in the spring of 2006. By September of 2006, 0.5.2 had been released and work began on the extension system, which debuted in version 0.6, about a month before RailsConf 2007. Since 0.6, we've been working on perfecting the extension system, upgraded the included version of Rails several times, and moved our test-suite over to RSpec. I expect we'll have the 0.7 release later this year, which will include a RESTful controller structure, a bunch of extensions to support blogging better, and a shiny new user-interface.

Can you give some examples of who is using Radiant?

There's a great page on the Radiant wiki that shows off sites created with Radiant.

Most notable lately has been its adoption by big companies and web development firms. For example, Digital Pulp and Saturn Flyer do most of their new site development with Radiant. Last year, I worked with Digital Pulp to launch their first Radiant sites, Redken.com and Redkensalon.com. This was a major accomplishment for them and for the Radiant software, liberating them from the dungeons of ezPublish, Drupal and Plone. Since releasing Redken, they have launched a number of others, including the Jack Kent Cooke Foundation and have several others in the works. I'm currently on contract to help relaunch Con-way's corporate website with Radiant. Things are going well and we've been able to contribute back to the community many of the features we're building.

How did you get involved with it?

In June of 2006, I grew tired of my Blogger service. Specifically, I was fed up with how slow it was (even on Google's cloud!), how inflexible the design was, and how opaque the template language was. I had started developing applications with Rails in February 2006 and wanted something for my blog that was on Rails. I didn't have time to develop something myself and I had seen buzz about Radiant earlier in the spring, so I tried it out. Once I grokked the content model, I really liked its flexibility so I gave it a shot and relaunched my blog on SeanCribbs.com. Since launch it has gone through at least two design changes that were fairly painless, thanks to Radiant's transparent content model. In one case, it was as easy as changing the layout of the root page.

Over the summer of 2006, I got more and more familiar with Radiant as I was solving my own problems and learning tips and tricks from the mailing-list. I started answering questions on the list so often that John Long asked me to start blogging "How-To" posts on radiantcms.org. That fall, the team I worked with in my day job decided to use Radiant for a major site redesign, so I got started developing extensions (which were very nascent at the time) for that project. In the process, I submitted a few good patches and John asked me to join the core team in January of 2007. Because my involvement has remained high and John wanted to focus on aspects of the visual design, he gave me the role of Lead Developer at the beginning of this year. Now I'm responsible for the direction of the core code of Radiant and managing the release cycle.

What initially drew you to Radiant?

I think what most drew me most to Radiant was its flexibility. I could make a blog, but I could also make some static pages, and even create my CSS stylesheets or generate an RSS feed with the same tools. It really gets out of your way when you want to publish some textual content, while providing just enough tools to fight off tedium.

What's in the current roadmap for Radiant?

Radiant 0.7, which we're planning to release before 2009, is what we're calling the "blogging release". This will include extensions that support comments on every page, Web 2.0-like "tag" classifications, blogging APIs, and tools to import from other blogging software. Along with that release will be a fully RESTful internal controller architecture and a brand-spanking-new interface. Following the 0.7 series, we plan to support internationalization, assets/binary files, content versioning, and some drag-and-drop features, among others.

The interesting thing about the current release cycle and the roadmap is that many community members are already building these planned features because they need them. Part of the reason we're currently on 0.6.9 and not 0.7 yet is that the extension system has allowed developers in the community to build the things they need and not affect the core Radiant code. In some areas, the community is moving faster than the core.

How can other people get involved with the development of Radiant?

The first step is to get on the mailing lists, which can be found from the Radiant website. Ask questions, answer questions, get your name into the community.

Second, build some sites with Radiant. Share your tips, tricks, tweaks, and code with the community.

Third, follow and contribute to the project. Since late spring 2008, main development has been done with git on GitHub. In June, the project moved completely over to GitHub in its own account — http://github.com/radiant. The account includes the core 'radiant', a number of sub-projects like the UI prototype and mockups, and a bevy of extensions that were authored originally by members of the dev team.
While I act as gatekeeper for the core, we're very open to adding other developers to help maintain the extensions — the "one patch gives commit bits" applies there. We only ask that your patches and pull-requests be clean, unobtrusive, and well-tested (with RSpec). Since moving to GitHub, we've nearly abandoned our existing Trac installation because most changes come to me through pull-requests. If you're not yet on GitHub, *you should be*.

Can you tell us more about the sprint weekend that you're planning?

In the recent past, I've noticed big-name projects in the Ruby community take on "sprint" weekends to hack out a lot of code (Rubinius, for example). Since we have some significant ground to cover before 0.7, I thought a hack-a-thon like that would be beneficial. Over the past few weeks, I ran online survey to collect a bunch of responses from community members who want to participate. While the details haven't been solidified yet, it will probably be in the Raleigh-Durham area (North Carolina, USA) in late October.

There are also a bunch of people who have been bugging me about holding a Radiant-focused conference, so there's another survey up to get information about that. You can find the survey linked from the Radiant blog, and the survey is open until mid-September. If we hold a Radiant conference, it will most likely happen in 2009, given how little of 2008 is left.

Post supported by thoughtbot — thoughtbot is a five year old web development consultancy, specializing exclusively in Ruby since Rails 1.0. We now provide an Advanced Rails training class, sharing our lessons from the trenches and interactively taking participants through the source and development process of a real-world app, Umbrella Today.

EnvyCasts is the latest venture by the presenters of the popular Rails Envy podcast - Jason Seifer and Gregg Pollack. Like PeepCode, EnvyCasts follows a model of offering an instructional video and supporting materials on a single topic for $9 in a variety of formats (QuickTime, Ogg Theora, and iPhone/iPod).

The first release is Advanced ActiveRecord - an entertaining walkthrough of several ActiveRecord-related situations such as loading large data sets (their solution yielding a significant speed boost over the standard technique), counter caching, polymorphic associations, and single table inheritance. A video preview is available at the site.

If the first screencast is indicative of EnvyCasts' ongoing style, you can expect an irreverent and non standard but highly memorable form of tuition. Unlike with other Rails screencasts I've seen, Gregg and Jason actually appear within the frame all the time, and a lot of light-hearted banter goes on between the two. Interludes also occur where Gregg Pollack walks you through miscellaneous information about the human brain. Separate to these parlor games, however, the topic-based knowledge is relayed in a very easy to learn, memorable style. If things like cheat sheets, drawings, mnemonics and other such tools help you to learn things, Jason and Gregg's style could be just what you need in order to learn some pretty deep Rails knowledge.

As an aside, the EnvyCasts site appears to be powered by Spree, an open source e-commerce platform for Rails. I hadn't heard of Spree before, so it might get some extra attention here on Rails Inside soon.

The official Ruby blog announces that REXML, an XML library that comes with Ruby and is heavily used by many Ruby apps (including RAils), is vulnerable to a specific type of attack that could result in a denial of service. Core Rails developer, Michael "Koz" Koziarski has posted instructions on how to work around it.

If you're running Rails 2.1.0 or later, it's very simple. Just run:

gem install rexml-expansion-fix

And then add this to your app's environment.rb file:

require 'rexml-expansion-fix'

For users of lower versions of Rails, refer to Koz's post for further information. Bear in mind that even if you don't use Rails' XML processing features, they will most likely be automatically employed by your app when it receives XML data, so get on top of this right away.

Exceptional is a new "exception tracking" and exception management application for Rails developers and their apps. It's currently in beta, but if you follow this special link, I'm told that Rails Inside readers will be prioritized in the signup process. It's developed by a group of guys working for a Web app development firm in Ireland called Contrast. Exceptional comes along at an interesting time, as US development team Thoughtbot has released something similar called Hoptoad. There are some differences, however - Contrast is planning to run Exceptional as a commercial Web service, whereas Hoptoad is going to be free for the foreseeable future.

Tools like Exceptional and Hoptoad replace old methods of tracking exceptions, such as the "exception_notifier" plugin that e-mails you whenever an exception is raised on your app. Having a Web app manage the exceptions is useful because everything is centralized and multiple developers can keep an eye on exceptions. Multiple exceptions of the same type can also be bundled together and mark as solved over time.

I caught up with one of Exception's lead developers, Eoghan McCabe (pronounced "Owen" - although I'll take corrections!), to ask some questions about the app.

What's your motivation for developing Exceptional?

Like most Rails developers, we take our craft pretty seriously. When we build apps for clients we obsessively monitor things like performance, traffic and exceptions. We had been using Exception Notifier and Logged_Exceptions and these were very, very helpful. But we wanted to take it one step further. We believe that teams work best on software they personally need, and on interesting technical challenges. Exceptional was both something we needed and a very fun app to code.

Tell us about how you developed Exceptional. Which tools, technologies and libraries were used?

On the front end, we're huge fans of the Blueprint CSS framework, which helps us translate our paper wireframes to screen with remarkable ease and speed. We've been using Prototype and Scriptaculous for javascript right now, but we're seriously considering moving to jQuery soon for its lightweight footprint and powerful selectors. This is really on the cards now that we can use Dan Webb's excellent lowpro framework with jQuery for unobtrusive loveliness.

On the server side we're using some of our favourite rails plugins:

• UltraSphinx – for it's awesomely reliable search indexing
• WillPaginate – every Rails project needs this plugin
• hubahuba – tasty set of extensions for basic classes
• RSpec – it's like marmite, but we love it

In our work flow:

• NewRelic RPM - we've managed to spot a lot of potential problems way in advance with New Relic and I really don't know how I developed without it. Now I save httperf for rainy days.
• Lighthouse – powerful but straight forward; we love passing tickets back to each other and use it to manage the features and changes for each milestone.
• GitHub – makes managing git repositories too easy; GitHub is a no-brainier as far as we're concerned.

All these tools, plugins and libraries make developing Exceptional an absolute pleasure.

What's your deployment setup like?

We're currently deploying to a small Slicehost cluster with the magic that is Capistrano. With plans to scale out to N boxes, we're still doing all of the server admin in-house but have been seriously considering taking a closer look at Engine Yard when the time is right.

Where do you see Exceptional heading in the future?

We hope Exceptional will become a must-have tool for Rails developers. That's why we're working closely with our beta testers and listening intently; we're focussed on the now. We don't have a feature chart or product roadmap. We improve Exceptional based on feedback from our (amazing) beta testers. This is our fourth iteration and we're ready to invite everyone on our signup list. We'll be inviting blocks of 50 each day starting today.

This post supported by Notifixious - Notifixious - a new notification service startup based in San
Francisco - needs a Rails expert to become its CTO! Knowledge of messaging technologies (XMPP) and REST API development is a must. You can learn more here.

David Heinemeier Hansson has announced that thanks to some solid work by Josh Peek over the summer, Rails 2.2 will be "thread safe." This will remove one of the common complaints against Rails from Merb fans and enable Rails to be extremely more efficient. While the most popular deployment of Ruby itself (MRI 1.8) doesn't support system threads yet, thread safety is a huge deal because it removes a lot of concurrency issues even with the existing Ruby interpreters.

South by Southwest (SXSW) is a set of festivals that take place each year in Austin, TX. Over the past few years, many Rubyists have made it to the event (Twitter's initially popularity storm was brewing at SXSW 2007!) and Ruby / Rails related events have been popular. SXSW have unveiled an "Interactive Panel Picker" for next year's festival and there are 15 Rails related proposals ready to vote for.

Panels include:

And, well, ten others. Check them out and get voting.