New Rails App:

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: 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.

Rails Views

Bruce Williams has started a new article series he calls Rails Views. Bruce is a long-time Rubyist and Rails early adopter and is the UI lead on development of a very large and complex Rails system. If it’s Rails and UI-related, Bruce is the man.

Now he’s chosen to share some of his Rails UI wisdom with the rest of us. If you’re doing complex user interface work in Rails, check it out.

Associations guru Josh Susser available for hire

Josh Susser has just announced that he is available for hire. Though relatively new on the Rails scene, Josh has proved a fast learner and has made his mark with several valuable contributions to the community. Just the other day we added him as an author to this very blog. Take a look at his posts over on his personal blog and if he looks like a good fit get in touch with him: josh at hasmanythrough com.

Testing RJS with ARTS

An Achilles’ heal of Rails is no good way to test your RJS. As the presentation behavior gets more and more sophisticated, the inability to test it becomes a real problem. Not anymore.

Kevin Clark has released ARTS, a mechanism to test RJS. His API is simple yet flexible. A single point of entry let’s you test a considerable amount of the RJS you can generate. Here’s an idea of what you can do:

  assert_rjs :alert, 'Hi!'                                                     
  assert_rjs :assign, 'a', '2'                                                 
  assert_rjs :call, 'foo', 'bar', 'baz'                                        
  assert_rjs :draggable, 'draggable_item'                                      
  assert_rjs :drop_receiving, 'receiving_item'                                 
  assert_rjs :hide, "post_1", "post_2", "post_3"                               
  assert_rjs :insert_html, :bottom, 'posts'                                    
  assert_rjs :redirect_to, :action => 'list'                                   
  assert_rjs :remove, "post_1", "post_2", "post_3"                             
  assert_rjs :replace, 'completely_replaced_div', '<p>This replaced the        
  assert_rjs :replace_html, 'replaceable_div', "This goes inside the           
  assert_rjs :show, "post_1", "post_2", "post_3"                               
  assert_rjs :sortable, 'sortable_item'                                        
  assert_rjs :toggle, "post_1", "post_2", "post_3"                             
  assert_rjs :visual_effect, :highlight, "posts", :duration => '1.0'           

He’s written up an extensive tutorial to get you up and running.

The Railways at Reboot 8

Finnish superstar Jarkko Laine, who’s been in the Rails community since day one, is going to be hosting a discussion this Thursday around 9PM at Reboot 8 in Copenhagen called The Railways.

The idea of
the discussion is to bring together people who have already dipped
their toes in the Rails koolaid with those who have contemplated doing so but have not yet made the jump. The conversation will be around
topics like:

  • What in the Rails way has struck people as most important?
    What has made the most difference?
  • Real-world war stories. How has Rails made something possible/
    easier/more productive?
  • Whatever people feel is important to tell Rails newbies.

All Rails people attending Reboot are kindly asked to participate in
the discussion and think beforehand of a few good stories they can
tell to spread the love.

Rails Helps People Find and Share Wine

Dan Benjamin, the man who brought A List Apart to Rails, has teamed up with web-standards guru Dan Cederholm and launched Cork’d, a free service for wine fans.

Built with Rails, Cork’d lets you rate, review, and catalog the wines you’ve tried. You can also keep track of wines you’d like to try and buy easily. Best of all, the site has a nice social network aspect to it, where members are encouraged to share and subscribe to each others’ reviews and recommendations.

Guide: Environments in Rails 1.1

As mentioned last week, Kevin Clark is taking your suggestions and developing weekly guides that cover the ins and outs of Rails.

He’s delivered on his first guide: Environments in Rails 1.1. The accompaying Cheat Sheet is particularly noteworthy. It lists all the various configuration options available to you, with a brief description of the purpose they serve.

To have your say on what Kevin covers next, send him your suggestion at kevin dot clark at gmail dot com with [idea] in the subject.