New from O'Reilly: RJS Templates for Rails

Cody Fauser has just announced the release of his PDF-only book RJS Templates for Rails.

From almost the day we checked rjs into the repository, Cody was quickly singling himself out as an expert. When he found out they weren’t going to make the 1.0 release, he made an rjs plugin available for those staying back at 1.0. Before we had extensive documentation, he was doing the dirty work, putting together various tutorials and explanations. Many of you likely learned about rjs from Cody. And now, many more of you likely will too.

Jaded Pixel wisely brought him onto their team. He’s applied his rjs skills to great effect on Shopify.

As a reviewer of RJS Templates for Rails, I can attest to it being comprehensive and up to date. The book provides a tutorial style guide to using rjs then at the end there is a full reference. Most impressively, Cody is a solid technical writer. I’m quite sure this is his first book yet it reads like it was written by someone who’s been doing this for years. I hope it’s not his last.

You can get a copy for 9 bucks.

Rails System Back on Track

Hopefully you didn’t notice, but I’ve been very busy this weekend. I finally took the plunge and got all the Rails applications that run on this machine up to snuff. All applications hosted here are now deployed with Capistrano, run under Mongrel (using the mongrel_cluster plugin) with requests being handled by Apache 2.2 and proxied to Mongrel by the mod_proxy_balancer module. So far it seems to be working great. You’ll notice that the Wiki, the Manuals and the weblog are all much zippier. The machine seems to be much happier as well.

And, to cap off all this fun, the weblog has been migrated from Typo to Mephisto, the blog/CMS engine from Rails Core member Rick Olson. The feed has also been moved to FeedBurner and redirects have been put in place so your reader should make the change automatically. If not, just subscribe here.

Thanks to everyone who helped me check and test things! Trac improvements are next on my list. Stay tuned!

Patience, Grasshopper

We all know that for some time this blog has needed some love. Well at last it can be told: There’s been a super-secret project underway for a while to upgrade the blog and get it running the way it should. We didn’t want to make a huge deal of it, but it seems that a few overly enthusiastic readers really enjoy posting bug reports as comments. So just chill out – the upgrade is coming soon. Posting thousands of comments isn’t going to make it happen any faster.

Browse your Subversion Repositories

Bounty Source provides the Open Source community with free hosting and tools including a task manager, a CMS, and a Subversion Code Repository. They’ve been gracious enough to release the Subversion Browser as a Rails plugin.

I’ve posted a technique on Rails Weenie on using your application’s authentication scheme on the plugin, so that your secret sauce is not available to the whole world.

Shopify is open for business

We’re lagging the official announcement by a fair margin, but that won’t hold back our official word of congratulations for Jaded Pixel as they’ve launched Shopify. It’s instant-on stores that don’t smell like a candy bar left in your pocket in the mid-90’ies. Complete with its own templating engine, Shopify makes it silly easy to create great looking stores that doesn’t just follow a cookie-cutter format.

In Rails circles, Jaded Pixel is mostly known as the company starring Rails Core developer Tobias Lütke. The team has already been sharing a great many extractions from the work of Shopify. So if you’ve played with the template engine Liquid or installed the forum-system Opinion, you’ve been touched by Shopify (now isn’t that heart warming!).

Once again, major props to Tobi and crew for finally delivering on this massive undertaking.

Collaborative Rails API Documentation

With Rails in a constant state of evolution, it’s important for its users to help each other stay in step with what’s current. To that end, Conor Hunt has created Rannotate, a system for collaboratively annotating RDoc-generated documentation.

He’s gone a step further and posted Rannotate instances for both Rails and Ruby.

Read, post, learn, and teach. At critical mass, Conor’s service could provide a huge benefit to the community. Coupled with Kevin Clark’s Rails documentation crusade, things are looking better and better on the documentation front.

These guys deserve our appreciation and our support. Now go post some annotations!

New Rails App: RightCart.com

Back in January I took the Pragmatic Rails Studio along with some guys named Dylan Stamat and Jonathan Siegel. Earlier this week they announced a brand new internet application: RightCart.com. By the way, the two of them wrote it in Ruby on Rails in just six weeks!

RightCart logo

RightCart is “Shopping 2.0”. It lets you embed a shopping cart on any web page with just three lines of HTML and JavaScript. The RightCart service manages your customer’s shopping cart contents for you, so integrating shopping capabilities into your website is trivial. They take care of everything from your catalog to payment processing. You can sell your own stuff and pay them a small percentage. You can also sell stuff from a shared catalog (with over a million items already) and get a 1% commission on the sale.

And like all good Web 2.0 companies, RightCart has a blog (State of the Cart) to share news about their business and services.

Congratulations to Dylan and Jonathan on their product launch!

All about Rails Trac keywords

Keywords in the Rails Trac get used in two ways. The first is a standard tagging system, where users tag tickets with whatever keywords they think describe the topic of the ticket. To give you an idea of what people use this type of tag for, here are the 25 most commonly used ones:

postgresql, performance, ajax, test, routes, sqlserver, activerecord, mysql, rake, documentation, form, prototype, generator, fixtures, error, helper, migration, patch, scaffold, webrick, oracle, adapter, session, has_many, tested, inflector, date.

Using keywords as tags is fine, but by no means required. It may make it easier for someone to find your ticket if they encounter a similar issue, but it’s not a big deal if you don’t use any tags at all.

The second way keywords are used is to help manage how tickets are processed. As of this writing there are 20 standard reports in the Rails Trac, and nine of them filter tickets based on specific keywords. A couple of the reports are only used during a push towards a release. One is being used for managing documentation updates. And six are about the life-cycle and categorization of patches. Those six are the ones that are interesting to us here.

A patch is just a ticket that has .diff file attached that contains a bug-fix or enhancement of some sort. The summary line for patch tickets should always start with the text [PATCH]. You don’t need to use a patch keyword - it’s redundant and no one pays attention to it. There are just five keywords that are used to manage patches during regular (non-push) development:

verified, unverified, needy, risky, tiny

Here’s how to use these keywords on your patch: Don’t. You should not use any of these keywords when creating a patch ticket. They are used by the core team to indicate the processing state of a patch, and if you add the keywords yourself it can confuse matters and might make it harder for someone to sort out what to do with the patch.

As I’m sure you’re curious (or you wouldn’t be reading this article), here’s a summary of what the keywords are used for. Verified and unverified indicate whether someone from the core team (or designated helper) has checked out the patch to see if it operates as claimed, tests pass, etc. Needy, risky, and tiny indicate the patch’s potential impact to stability and if extra work might be involved in getting it working. Full explanations can be found on the report pages in Trac. Look at reports 3, 4, 11, 12, 16 and 17, if you really want to know.

There isn’t a rigid process the core team uses to process patch submissions. The patch life-cycle reports get used sometimes, and other times people just watch the Trac RSS feed for new patches. Marcel Molina Jr says, “I use the reports but not religiously. I use them once-in-a-whilely. On the occasion when I do, though, it is appreciated and allows me to quickly process a lot of tickets.” So if you want your patch to be processed quickly, it’s probably best to leave off the five patch-state keywords and let the core team use them without confusion.