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.
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.
Registration for Rails Day 2006 is now open.
Head on over and signup your team.
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.
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!
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!
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!
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.
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.
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.
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 div</p>' assert_rjs :replace_html, 'replaceable_div', "This goes inside the div" 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 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
- 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/
- 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.