The QuarkRuby blog has created a great Ruby on Rails Security Guide that gives you a wealth of links to articles and plugins dealing with security in Rails applications. Everything fromn XSS to CSRF stuff is covered.
There’s a lot of action going on in the Rails IDE space these days. Besides Aptana RadRails, which has been around for a long time, Sun’s got impressive Rails support in the new NetBeans, and just this week CodeGear launched their 3rdRail IDE, which also looks like a great setup.
I’m personally not quite ready to leave TextMate behind, but it’s encouraging to see all these options for dedicated Rails IDEs. It’s not going to be long before they’ll be giving regular text editors a serious run for their money.
The party in Berlin came to an end all too soon. I had a blast there and so did everyone else it seemed. Such a fantastic atmosphere and group of people. If you weren’t able to make it, you can peruse the presentation slides or the pictures. Thanks to everyone who made it possible and to all who was able to come.
For a while, the patch queue was getting badly out of hand. The flood of new entries was simply too great to be reasonably managed by a small group of people. Too much got stuff got stale and their creators got disillusioned, understandably so. But for a while now, we’ve been running with a new policy on patches, which seems to be working a lot better for those who’ve been following it.
But I’m sensing that a fair number of people are not aware of those changes in policy, so I thought best to bring them up again here.
Step 1: Raise the barriers of quality
Part of the reason that the original patch queue got out of hand was due to the large number of patches coming in that lacked essential qualities of a good patch. They were either missing a good rationale (why am I doing this? what’s the benefits?), good test cases, or didn’t update the relevant documentation. To apply such a patch meant that this work had to be shouldered by someone else, usually the guy who wanted to apply the patch.
Now the barriers of quality are more apparent. Your patch will simply not be considered for inclusion before it has all those elements. It’ll live with the “unverified” keyword until you or someone else that cares especially deeply about the patch (like someone else having the same problem) gets the quality up to par. Then the patch moves on to step 2.
Step 2: Get the community engaged to review your patch
The last step before your patch is ready to be put in the queue for inclusion is to get community support round up. We now require that three different people must review your patch, apply it, run the tests, read your documentation, and like what it does and how it’s implemented. When they do, they’ll make a comment on the ticket with a “+1”.
Get three such +1s and you can tag your patch with the “verified” keyword. That’ll make the patch appear in Report #12: Verified Patches, which is a bell telling the core team that you patch is baked and ready to be included (barring a final review).
The core team is trying to keep report #12 empty at all times. There shouldn’t be a big lag time between getting to “verified” and getting a final review of your patch, which will either send it back to unverified (because the implementation is deemed in need of work or because there’s some fundemental disagreement over whether or how this patch goes about its business) or it’ll be applied and available in edge.
So if you have a patch that you still care about sitting in the queue, dust it off, and put it through these two simple steps and you’ll be back on the road to glory. There are still no guarantees that your patch will receive immediate attention, but so far we’ve managed to keep report #12 moving very nicely. It’s all empty as of today!
The front page of http://dev.rubyonrails.org has been updated to reflect this policy.
After a short period of downtime following a massive spam attack, the Rails wiki is now back in business.
RailsConf Europe is coming up fast and we’re happy to report that all the seats are now gone. We’ll have one packed show to put on. I can’t wait to hook up with everyone again. Go Berlin!
The fantastic team at Rails Envy is back with their Apple-style commercials comparing Ruby on Rails to a variety of competing environments. This time they have a one-two punch first striking .NET and then doing PHP/CakePHP. As always, it’s funny stuff and really nicely done. Keep it up, boys!
Looking for a good way to browse the Rails API documentation? Alex Gorbatchev has recently created Noobkit, a documentation browser for Rails, Ruby core, and over 20 other useful libraries. It also supports searching, comments (with your OpenID), and bookmarks.
The first release candidate for Prototype 1.6.0 is now [available for download](http://prototypejs.org/2007/8/15/prototype-1-6-0-release-candidate). This version features a rewrite of the event system, including support for DOM-based custom events and the DOMContentLoaded event, true class inheritance and superclass method references, and improvements to the DOM, Ajax, and function APIs. Please give it a spin in your apps and [let us know](http://dev.rubyonrails.org/) if you run into trouble.
It’s that time of the year again: time for another Rails coding competition. In the spirit of the previous Rails Day contests, Rails Rumble challenges teams of up to four to create the best application possible in just 48 hours. This year’s competition is a little bit differently this time around, so checkout the rules. Judging is now performed by the community, allowing anyone to signup and choose their favorites. Also, your app will be provided a VPS to host the application through the end of October. How cool is that?
If you want to compete, you need to organize quickly, the contest runs on September 8th and 9th.