Active Resource was announced at RailsConf and the first tiny pieces of code has already been checked in, but what is it exactly? Ryan’s Scraps tries to answer that with a summary of the stuff that’s already working and the ideas for how to implement the rest of the interface.
The security fix from Rails 1.1.3 might have closed the hole, but it also caused breakage for people with controllers in modules. We’ve fixed that now, so Rails 1.1.4 should work for any application that also ran under 1.1.2. We apologize for the problem with 1.1.3 and encourage everyone running 1.1.x to upgrade as soon as possible to this release.
Note: Edge Rails was never affected by this security issue as it includes a rewritten routes module. So if you’re running on the latest edge, you don’t need to worry about upgrading.
Talk proposals are now being accepted for the European Rails
Conference, to be held September 14-15 in London. Accepted speakers
will get free admission to the conference. Join a line up that already includes the creator of Rails, David Heinemeier Hansson, Pragmatic Programmer Dave Thomas, best-selling author and passion maven Kathy Sierra, Rails core developers Jamis Buck, Marcel Molina, Jr., and Thomas Fuchs, Rails authors and trainers David Alan Black, and Chad Fowler, and Rake author Jim Weirich.
Proposal suggestions span a variety of Rails topics, including:
- case-studies in interesting Rails applications
- Rails add-ons and adapations (including experimental ones)
- analyses and critiques of specific aspects of the framework
- the use of Ruby in/for/with Rails development
- comparative analysis of Rails and other frameworks
- testing, coding, deployment, and all the rest!
The deadline for proposals is July 21. You are asked to submit a title, a short abstract, and a slightly longer
description (400 words or so). You don’t have to have the whole talk
written, just a reasonably detailed overview.
You can write to David A. Black (dblack at wobblini.net) if you have questions about the proposal
Keep an eye on the conference website feed for updates.
We’ve found and fixed a security issue with routing that could cause excess CPU usage in Rails processes when triggered by certain URLs. We strongly encourage anyone running 1.1.x to upgrade to the latest version. It’s fully backwards compatible and should serve as a small drop-in fix.
If you’re running the latest Edge Rails, though, there’s no need to update. We’ve rewritten the routes functionality on edge and the new version doesn’t have this problem.
To upgrade, you as always can just do:
gem install rails --include-dependencies
Note: This release doesn’t include any of the new CRUD/resource-based features. All of the new features we’ve been working on over the last couple of months will become available in 1.2.0, which is scheduled for “soonish”. This 1.1.3 release is purely to address the security issue and another few minor fixes that were available on the STABLE branch as well.
Paul Graham delivered one of the keynotes to an audience of about 550 people this weekend at RailsConf. The text of his talk, The Power of the Marginal, is now online. Hold tight for full video of almost all the keynotes in weeks to come. They will be made available for free to download.
You may have seen MOG mentioned on BoingBoing or elsewhere earlier this week. It’s the new social networking site that lets music lovers connect based on what they’re into, keep a blog about their musical discoveries, and find new things to appreciate based on their friends’ recommendations. It even has this MOG-O-MATIC plugin for iTunes so that it can figure out what you listen to without you having to tell it. Even if you don’t have your music tagged.
That’s all pretty cool, but for the readers of this blog, the really cool part is that MOG is written entirely in Ruby on Rails. The MOG software is the creation of Lucas Carlson, Dave Fayram, and Joshua Sierles. It’s a nice piece of work, serving up 1.5M requests per day using Pound, Mongrel and memcached, and they are still tuning it for performance. The app also includes an XML-RPC interface used by the plugin (though Dave says now he thinks REST might have been a better way to go).
So tune your internet dial to mog.com and take a listen…
RailsDay 2006 is in progress! Teams around the world will be working furiously all day to produce the best application possible in 24 hours.
Rails performance specialist Stefan Kaes, who writes extensively about optimizing Rails over at Rails Express has a lengthy article at the new InfoQ site called A Look at Common Performance Problems in Rails.
Kaes identifies various development practices that will slow down your Rails applications, such as repeating computations that only need to be run once and then cached. If you’ve located some slowness in your application, Kaes may have already identified some of the likely culprits.
In 1988, Ward Cunningham (yes, that Ward Cunningham) came up with an idea to use index cards as a tool for object-oriented design. I was working for Kent Beck at Apple at the time, so I got to hear Ward describe his idea over speakerphone in Kent’s office. Ward and Kent presented a paper on CRC cards at the OOPSLA conference the next year, and suddenly they were all the rage. Some companies even printed up branded CRC cards, which still makes me laugh.
Take an index card. (3x5 or 4x6 are good sizes, but any larger than that and they become too unwieldy to move around.) Write the name of a class across the top. Draw a vertical line separating the rest of the card into uneven halves - the left half should take up about 2/3 of the width. On the left side write the responsibilities of the class. On the right side write the objects or classes of objects that objects of this class collaborate with. That’s the basics right there. Once you have cards representing several classes, you can arrange the cards to explore object interactions and discover new responsibilities and collaborations.
While CRC cards can be used solo, where they really shine are during collaborative design. It’s easy for one person to move a card around to show others what they mean. Since cards move independently, two people can be writing on different cards at the same time. It makes for a lightweight yet effective group design process. It’s also a decent way to describe a design.
CRC cards also play well with the Rails mindset where constraints are empowering. Cards are small, so you can’t write so much on them that they become too complex to understand. Limited space keeps you focused on the important stuff. And since cards are easy to make, they are also easy to throw away - no investment equals no pain. Don’t like what’s on a card? Just tear it up and start over.
A good way to start with CRC cards is to use them to document an existing design. That way you don’t have to deal with creating a design while learning a new tool at the same time. Then you might use them to modify or expand the design for existing software. Once you are warmed up with them you can take them for a spin on a brand new design.