Yup Dot Com

The New Ruby-Lang.org

Posted by Daniel Butler Wed, 30 Aug 2006 22:00:00 GMT

A new design for ruby-lang.org is coming, and it's very Web 2.0. Sweet.

Ruby Lang Logo

Posted in Ruby on Rails, Web Design | no comments

Rails No-Nos Now

Posted by Daniel Butler Wed, 30 Aug 2006 21:45:00 GMT

Kevin Clark of San Diego has posted an article describing several deprecated features of Rails--thing you should fix now or they'll break later. Quickly, they are:

Accessing Instance Variables You Didn’t Create
Stop using find_all and find_first
Don't write the AJAX-enabled feature before you write the simple fallback feature.
Stop asking for things not directly related to your problem.
Don't use scaffolding.
Don't use components.
Don't use engines unless you're going to do it right.
Use layouts more
Don't use Rails Paginator class
Don't put controllers into namespaces.

I don't completely agree with all of Kevin's findings, but you should at least view the article to be aware of some of the problems that you might encounter using these less than best practices features.

Things You Shouldn't Be Doing in Rails

Posted in Ruby on Rails | no comments

Beware of "Assumed Logged In" Attacks

Posted by Daniel Butler Wed, 30 Aug 2006 11:01:00 GMT

Brian Ellin of Portland, Oregon, warns us of "assumed logged in" attacks, which are cross-site attacks in which another site carefully crafts a URL that opens in a hidden frame which performs a destructive action on a different site that you are assumed to have been logged in to. His solution: the secure-action-plugin. He describes the problem and the solution:

In an assumed logged in attack, a malicious site assumes the visitor is logged into your site. The malicious site manually crafts a URL to a destructive action on your site (change email, delete account, etc.) and opens the URL to that action in a hidden iframe. The browser then sends the user’s cookies and actions may be performed on your user’s behalf without them ever knowing. This technique may be used to steal accounts, inject or delete account data, or perform other malicious actions.

The plugin works by overriding ActionController.url_for and adding a signature of the user’s session_id and some salt to URL query strings. By adding a sig that includes the user’s session_id, it makes it impossible to for malicious sites to create URLs that will work on your site for anyone but themselves. The signature is verified before a secure action is executed.

Until now, I had not conceived of this type of attack. Thanks, Brian.

Secure Action on the Rails Wiki Page
Plugin Home Page
Ruby Plugins Directory Entry

Posted in Ruby on Rails | no comments

Modal Information Boxes: RedBoxPlugin for Ruby on Rails

Posted by Daniel Butler Tue, 29 Aug 2006 14:22:00 GMT

Craig Ambrose, an Aussie from Melbourne, has announced the RedBox Plugin for Ruby on Rails. He writes,

I've written a little plugin to use for displaying a block of html over a page while fading out the background. This is like the lightbox.js library, and all it's related offshoots (thickbox, greybox, etc.). My plugin, Redbox, is not really any better than these others (in fact, it's less mature, and less tested), but it builds on prototype and scriptaculous, is available as a rails plugin, provides easy to use helpers, and unlike the other libraries, works very well with rails' ajax functionality.

Looks nice, and it's easy to use. Thanks, Craigh.

Craig's Blog Entry
Demo Page
Ruby Plugins Directory Entry

Posted in Ruby on Rails | 1 comment

Ruby on Rails Forums in about 500 LOC: Beast

Posted by Daniel Butler Thu, 17 Aug 2006 17:58:00 GMT

Josh Goebel and Rick Olsen are working on Beast, a "small, light-weight forum in Rails with a scary name and a goal of around 500 lines of code when we're done." Beast is not mature yet, but forums is one application domain that is sorely lacking in the RoR world, and it's good to see people working on innovative applications. phpBB is difficult to maintain, modify, and full of security holes, and I've been searching for a better alternative, perhaps even going so far as to start writing my own forum system.

So far, RForum (stuck at version 0.2 since December 2005) looks like the most mature forum application available for Rails, and it comes complete with email gateway functionality, but hopefully other forum applications will start populating the thriving ecosystem.

Beast Demo Site
Beast Subversion Repository

Posted in Ruby on Rails | no comments

Bruce Tate on Rails Migrations

Posted by Daniel Butler Thu, 17 Aug 2006 14:41:00 GMT

Bruce Tate, a Java book author and Ruby on Rails advocate, discusses the advantages of Ruby on Rails database migration strategy, and concludes:

The migrations story in Java programming is not nearly as robust. Some products have spot solutions for some of the schema migrations problems, but without a systemic process for coordinating schema changes -- both up and down -- dealing with changes in the data and object model can be a difficult task. The Rails solution has some core advantages:

Rails migrations are DRY (don't repeat yourself). With Rails, you specify each column definition exactly once: in the migration. Some other mappers force you to specify a column six times: in the schema, the getter, the setter, the model's instance variable, the "from" mapping, and the "to" mapping.

Rails migrations allow data migration as well as schema migration.

Rails migrations let you use model logic with your data migration where SQL scripts don't.

Rails migrations are database independent, but SQL scripts aren't.

Rails migrations allow direct SQL for unsupported extensions (such as stored procedures or constraints), while some ORM mappers don't.

With all of the benefits of migrations, you'd expect a complex piece of code, but they are incredibly simple. Migrations have meaningful names and version numbers. Each migration, has an up and down method. Finally, a rake task coordinates running them in the correct order. This simple strategy is also revolutionary. The idea of expressing each schema change not in the model but as a distinct migration is both elegant and effective. Coordinating both data and schema changes is another paradigm shift, and an effective one. Best of all, these ideas are completely language agnostic. If you're building a new Java wrapping framework, you'd do well to consider migrations.

I personally take full advantage of migrations during development and maintenance of Ruby on Rails, and they have forever solved the chicken-and-egg data, code, and schema synchronization problem which made moving from development to production a unweildy and error-prone process in the past. It's also important to have a histor of the schema changes over time so that if a problem arises, you can track back to the exact change and schema migration which caused it.

Crossing Borders: Rails Migrations Article
Understanding Migrations @ Rails Wiki

Posted in Ruby on Rails | no comments