This article is heavily styled and is best viewed at PeepCode!

This article is heavily styled and is best viewed at PeepCode!

Files should be navigable by file, class, or method name and show metadata useful for distinguishing between similar files (mockup).

TextMate

Keyboard

Fuzzy

Beautiful

Command-T with fuzzy search was revolutionary and was one of the main reasons I bought a copy of TextMate. But it breaks down for projects with many files of the same name (such as Ruby on Rails).

Theres no way to filter by directory.

Tabs are even worse. I frequently open more tabs than can fit on my screen, which means that both usability and the extra tabs get thrown out the window. The tab menu can only be accessed with the mouse and becomes a human-powered binary search of an unsorted list.²

Xcode

Keyboard

Beautiful

Xcodes Open Quickly command (Command-Shift-D) only works with the exact file name starting with the first letter.

Xcodes Open Quickly dialog

Many Cocoa developers store all their code files in the root directory of the project and rely on Xcodes virtual directories for organization, which is the only reason its even barely usable.

Emacs

Keyboard

Fuzzy

Path

Emacs is the closest to satisfying my requirements.

The ido-menu provides fuzzy search, including pathnames. Chris Wanstraths textmate.el plugin³ wraps it in even more useful functionality, such as autodiscovery of a project root based on the existence of a .git directory.

Open buffers (similar to tabs) can be searched for by name (C-x b) or in a list (C-x C-b).

But the inline menu is an ugly paragraph.

A powerful search hidden behind a mess of text.

The initial prototype performs a fuzzy search on paths and lists file modification dates.

There is a vulnerability in Ruby on Rails which could allow an attacker to circumvent the CSRF protection provided. This vulnerability has been assigned the CVE Identifier CVE-2011-0447.

• Versions Affected: 2.1.0 and above
• Not affected: Applications which dont use the built in CSRF protection.
• Fixed Versions: 3.0.4, 2.3.11

Impact

Certain combinations of browser plugins and HTTP redirects can be used to trick the users browser into making cross-domain requests which include arbitrary HTTP headers specified by the attacker. An attacker can utilise this to spoof ajax and API requests and bypass the built in CSRF protection and successfully attack an application. All users running an affected release should upgrade or apply the patches immediately.

Releases

The 3.0.4 and 2.3.11 releases are available at the normal locations.

Upgrade Process

There are two major changes in this fix, the behaviour when CSRF protection fails has changed and the token will now be required for all non-GET requests.

After applying this patch failed CSRF requests will no longer generate HTTP 500 errors, instead the session will be reset. Users can override this behaviour by overriding handle_unverified_request in their own controllers.

Users must still take care that users cannot be auto logged in via non-session data. For example, an application using filters to implement remember me functionality must either remove those cookies in their handle_unverified_request handlers or ensure that the remember me code is only executed on GET requests. A custom handler which removes the remember_me cookie would look like:

def handle_unverified_request   super # call the default behaviour which resets the session   cookies.delete(:remember_me) # remove the auto login cookie so the fraudulent request is rejected.end

There are two steps to ensuring that your application sends the CSRF Token with every ajax request. Providing the token in a meta tag, then ensuring your javascript reads those values and provides them with each request. The first step involves you including the csrf_meta_tag helper somewhere in your applications layout. Rails 3 applications likely already include this helper, however it has now been backported to the 2.3.x series. An example of its use would be something like this in application.html.erb:

<%= javascript_include_tag :defaults %><%= csrf_meta_tag %>

In addition to altering the templates, an applications javascript must be changed to send the token with Ajax requests. Rails 3 applications can just update their rails.js file using rake rails:update, 2.x applications which dont use the built-in ajax view helpers will need to add a framework-specific snippet to their application.js. Examples of those snippets are available:

• prototype-snippet.js Prototype script which includes the csrf token in every Ajax request
• jquery-snippet.js JQuery script which includes the csrf token in every Ajax request.

Workarounds

There are no feasible workarounds for this vulnerability.

Patches

To aid users who arent able to upgrade immediately we have provided patches for the two supported release series. They are in git-am format, 3-0-csrf.patch includes two changesets, the others consist of a single changeset.

• 2-3-csrf.patch Patch for 2.3 series
• 3-0-csrf.patch Patch for 3.0 series

Given the severity of the problem we are also providing backported fixes to the 2.2 and 2.1 series. There will be no gem releases for these versions but the stable branches in git will be updated.

• 2-2-csrf.patch Patch for 2.2 series
• 2-1-csrf.patch Patch for 2.1 series

Please note that only the 2.3.x and 3.0.x series are supported at present. Users of earlier unsupported releases are advised to upgrade as soon as possible as we cannot guarantee continued security fixes indefinitely.

Credits

Thanks to Felix Grbert of the Google Security Team for reporting the vulnerability to us and working with us to ensure that the fix didnt introduce any new issues. Thanks also to the Shopify development team for their assistance in verifying the fix and the upgrade process. The original vulnerability has been reported to vendors by kuza55

Two new versions of Ruby On Rails have been released today. As well as including a number of bugfixes they contain fixes for some security issues. The full details of each of the vulnerabilities are available on the rubyonrails-security mailing list. We strongly urge you to update production Rails applications as soon as possible. Rather than post the advisories individually to this blog, Ill just link to the google talk archives.

Install the latest version using gem install rails. Or if youre using bundler, edit your gemfile and run bundle update rails.

Summaries

Affecting 2.x.x and 3.0.x

• XSS Risk in mail_to :encode=>:javascript CVE-2011-0446
• CSRF Bypass Risk CVE-2011-0447

Affecting 3.0.x only

• Filter Problems on Case Insensitive Filesystems CVE-2011-0449
• Potential SQL Injection with limit() CVE-2011-0448

Eloquent Ruby (Amazon.com - print & Kindle) by Russ Olsen is the first Ruby book I've read in its entirety within 24 hours; it's that good. That may be all you need to know before you buy a copy at Amazon.com, Amazon.co.uk or read it on Safari (if you have an account). If you want to learn more though, keep reading.

What Is "Eloquent Ruby"?

Eloquent Ruby is a book published by Addison Wesley and written by Russ Olsen (who also wrote Design Patterns in Ruby a few years ago). It clocks in at around 400 pages and has 31 chapters clocking in at around a punchy 10 pages each. Each chapter is titled as a guideline you should follow to write "eloquent" Ruby - things like Create Classes That Understand Equality and Write Code That Looks Like Ruby - and typically the claim is explained, some code examples shown and discussed, some real world examples pointed to, and that's it.

As with Design Patterns in Ruby, Russ adopts a chatty, familiar tone. Reading this book is like reading a book specifically written for you by a friend. He doesn't shoot off on many unnecessary tangents and he keeps the stories short and sweet but this book certainly couldn't be called dry.

The book is also notably short of egregious errors or omissions. Even when I don't read something with a fine-toothed comb on standby, I can usually pick out a laundry list of factual and grammatical errors or omissions (as both Obie Fernandez and my wife will attest) but Eloquent Ruby gave me little to chew on. I can only bring to mind a few spacing and formatting issues and only one true "error": a > instead of a < in a class definition on a single example.

Russ tries to remain neutral with his choice of Ruby implementations but the book seems to focus primarily on Ruby 1.9 (Ruby 1.9.1 specifically but that's just due to when he wrote it) while providing useful footnotes in the cases where there are differences to Ruby 1.8. No matter what Ruby implementation you're using, there's little to confuse you as most of it is very non-implementation and non-version specific.

I wholeheartedly recommend this book to anyone except those who, well, could have written a similar book themselves. The short punchy chapters make it a delight to read and gives the option of reading it merely 10 minutes at a time before bed or similar. The short chapters also make it useful as a reference if you forget how to do a certain thing like, say, use method_missing, even though it's not put together as a reference book at all. Lastly, this book is a must read if you're not confident with Ruby idioms and the best way to structure and lay out your code - Russ's approaches reinforce the current "standard" way to write Ruby and this alone is worth the price of admission.

Who Should Buy It?

• Any Ruby developer who doesn't yet feel like they're at guru level (that's most of us!)
• Anyone who wants to get a feel for the typically undocumented style, syntax, and structural standards of top Ruby developers.

Who Shouldn't Buy It?

• Anyone without a sense of humor or who doesn't like a chatty, familiar type of writing.
• Matz, Dave Thomas, Chad Fowler, Russ Olsen himself, and a few others.
• Anyone who's resistant to change and wants to keep coding Ruby "their way."

The Chapters

The chapter titles in Eloquent Ruby are useful enough to give you an indication of the level(s) it aims at and whether it would be interesting to you, so here goes:

1. Write Code That Looks Like Ruby
2. Choose The Right Control Structure
3. Take Advantage Of Ruby's Smart Collections
4. Take Advantage Of Ruby's Smart Strings
5. Find The Right String With Regular Expressions
6. Use Symbols To Stand For Something
7. Treat Everything Like An Object - Because It Is
8. Embrace Dynamic Typing
9. Write Specs!
10. Construct Your Classes From Short, Focused Methods
11. Define Operators Respectfully
12. Create Classes That Understand Equality
13. Get The Behavior You Need With Singleton And Class Methods
14. Use Class Instance Variables
15. Use Modules As Name spaces
16. Use Modules As Mixins
17. Use Blocks To Iterate
18. Execute Around With A Block
19. Save Blocks To Execute Later
20. Use Hooks To Keep Your Program Informed
21. Use method_missing For Flexible Error Handling
22. Use method_missing For Delegation
23. Use method_missing To Build Flexible APIs
24. Update Existing Classes With Monkey Patching
25. Create Self Modifying Classes
26. Create Classes That Modify Their Subclasses
27. Invent Internal DSLs
28. Build External DSLs For Flexible Syntax
29. Package Your Programs As Gems
30. Know Your Ruby Implementation
31. Keep An Open Mind To Go With Those Open Classes

There's something for everyone and it gets progressively more advanced.

How to Get Eloquent Ruby

If you want a print or Kindle copy, head to Amazon.com, Amazon.co.uk, or your other favorite book retailer. If a PDF or EPUB file is more to your taste, InformIT has those for sale (currently for $28.79).

Kindle Preview

Rails 3 is great. RSpec 2 is great. And Ruby 1.9.2 is really great. Getting them all running together and quickly, however, isn't entirely straightforward. In this post I demonstrate how to get everything ticking over along with automatically running, super-snappy test runs.

The ultimate outcome is using Ruby 1.9.2 (though much of this is relevant to 1.8 still) to create a Rails 3 app, hook up RSpec 2, and be able to run specs quickly. The first two parts are easy(ish) but the "quickly" part requires some tinkering. Grab a coffee and carry on..

Create a new Rails 3 app

Got Rails 3 installed? If not, gem install rails will see you good. Then head on down to your favorite project folder with your shell and create a new Rails 3 app like so:

rails new myapp --skip-test-unit

You can retroactively bring RSpec 2 into an existing Rails 3 project, of course, but it's easier for this walkthrough to start afresh in case of application-specific issues.

Hooking up RSpec 2 with RSpec-Rails

Edit the Gemfile file in your new Rails project (myapp/Gemfile in this example) and add the following block to the bottom:

group :development, :test do  gem 'rspec-rails'end

This tells Bundler (a gem management and dependency tool Rails 3 likes to lean on) we want to use the rspec-rails gem which will get RSpec running with Rails 3.0 for us. Next, we get Bundler to do its thing:

bundle

This will install all of the gems referenced in Gemfile, including rspec-rails. (You can use bundle install instead, if you prefer, but bundle on its own works too.)

Last but not least, we need to run RSpec's 'generator' that rspec-rails has put in place for us:

rails generate rspec:install

The generator creates a few files. Namely:

• .rspec - a config file where we can store extra command line options for the rspec command line tool. By default it contains --colour which turns on colored output from RSpec.
• spec - a directory that will store all of the various model, controller, view, acceptance and other specs for your app
• spec/spec_helper.rb - a file that's loaded by every spec (not in any automatic way but most have require 'spec_helper' at the top). It sets the test environment, contains app level RSpec configuration items, loads support files, and more.

We still can't run rake and see anything interesting yet because we don't have a database or any models initialized.

Creating a model to test

Let's take the easy way out and use the scaffold generator to flesh out something for us to test (as well as to see what spec files can be generated automatically):

rails generate scaffold Person name:string age:integer zipcode:string

It's worth noting that when you generate the scaffold numerous spec files are also created (thanks to rspec-rails):

spec/models/person_spec.rbspec/controllers/people_controller_spec.rbspec/views/people/edit.html.erb_spec.rbspec/views/people/index.html.erb_spec.rbspec/views/people/new.html.erb_spec.rbspec/views/people/show.html.erb_spec.rbspec/helpers/people_helper_spec.rbspec/routing/people_routing_spec.rbspec/requests/people_spec.rb

Now bring the database up to speed with the migration for the new model:

rake db:migrate

Now let's run rake - finally! The result:

...............**............Pending:  PeopleHelper add some examples to (or delete) /Users/peter/dev/rails/myapp/spec/helpers/people_helper_spec.rb    # Not Yet Implemented    # ./spec/helpers/people_helper_spec.rb:14  Person add some examples to (or delete) /Users/peter/dev/rails/myapp/spec/models/person_spec.rb    # Not Yet Implemented    # ./spec/models/person_spec.rb:4Finished in 0.31043 seconds29 examples, 0 failures, 2 pending

Rock and roll. We're up and running. Sort of. Let's put in some "real" specs to be sure things are working nicely.

Change spec/models/person_spec.rb to the following rather contrived pair of specs:

require 'spec_helper'describe Person do  it "can be instantiated" do    Person.new.should be_an_instance_of(Person)  end  it "can be saved successfully" do    Person.create.should be_persisted  endend

Not the most useful things to spec out, admittedly, but you get a little database action and get rid of a pending spec we had cluttering things up. We haven't got anything else we can seriously test yet anyway.

Now let's run rake spec:models to focus our efforts on what we've just done:

..Finished in 0.09378 seconds2 examples, 0 failures

How to have specs run automatically with Watchr

Let's assume we've progressed with developing our app and we're working on models and controllers, testing along the way. Rather than running rake or bundle exec rspec all of the time, wouldn't it be great to have the relevant spec run automatically when we either edit the spec or a model/controller that has a spec? Well, with watchr, we can. (Note: Some people prefer autotest. I find watchr more flexible and useful for other things beyond just running specs.)

But if you really want to use autotest, Mike Bethany explains how to set it up in a similar scenario in a post of his own, along with autotest-growl for OS X notifications.

Add watchr to your Gemfile's testing and production gem section:

group :development, :test do  gem 'rspec-rails'  gem 'watchr'end

Then run bundle to install it.

Next, create a file called .watchr in your app's root folder and populate it with this code:

def run_spec(file)  unless File.exist?(file)    puts "#{file} does not exist"    return  end  puts "Running #{file}"  system "bundle exec rspec #{file}"  putsendwatch("spec/.*/*_spec\.rb") do |match|  run_spec match[0]endwatch("app/(.*/.*)\.rb") do |match|  run_spec %{spec/#{match[1]}_spec.rb}end

This 'watchr script' directs a running watchr process to do a few things:

• If any file ending in _spec.rb under the spec/ directory changes, run the run_spec method with its filename.
• If any .rb file under the app/ directory changes, call the run_spec method with an equivalently named _spec.rb file under spec.
• run_file accepts a filename for a spec file, checks it exists, and tells the system to run it (using system)

If you now run watchr .watchr to use the .watchr script, not much will happen. But if you make any change (or even just re-save) to, say, spec/models/person_spec.rb, that spec will run automatically. Make a change to app/models/person.rb and it's the same deal. To stop watchr, CTRL+C saves the day.

Watchr can be used for a lot more than this but this is just for starters ;-)

Optionally, you might also like to create lib/tasks/watchr.rake and include the following code so you can just remember to run rake watchr instead (it's nice to have anything you run within a project contained in one place):

desc "Run watchr"task :watchr do  sh %{bundle exec watchr .watchr}end

How to get faster spec runs with Spork

We've got Rails 3 running with RSpec 2 and watchr's giving us some automatically-running-spec love. But do you notice how slow it is? Specs run quickly once they're loaded but there are several seconds of waiting beforehand.

If you run time rake spec:models with Ruby 1.9.2, you'll probably see a wallclock time of over 5 seconds (5.204s on my machine and I'm SSDed up) - holy splingledoops! If not, you're lucky, but it's a commonly reported problem with some improvements expected in Ruby 1.9.3. We can't wait that long though..

Enter Spork. Spork is a tool that loads the Rails environment and then forks each time you want to run some specs (or tests, it can be set up to run with Test::Unit too). In this way, the whole Rails initialization process is skipped, shaving valuable seconds off of your spec runs.

Edit your Gemfile again and include Spork:

gem 'spork', '~> 0.9.0.rc'

Run bundle to install Spork.

Next, Spork needs to make some changes to your spec/spec_helper.rb file. Because it only initializes the Rails environment once and then forks it, you might have initialization features that you need to run on each test run. Spork will let you do this but it needs to make those changes first. Run:

spork --bootstrap

The result:

Using RSpecBootstrapping /Users/peter/dev/rails/myapp/spec/spec_helper.rb.Done. Edit /Users/peter/dev/rails/myapp/spec/spec_helper.rb now with your favorite text editor and follow the instructions.

Bring up spec/spec_helper.rb. All spork --bootstrap has done is add some extra code to the top of the file. Read the comments there to get a better feel for what to do and what Spork requires and keep them in mind as we progress (in case you want to do something differently).

Get rid of require 'rubygems' from the first line - we're using Bundler so it's not necessary.

Next, cut and paste all of the 'old' contents of spec_helper.rb into the Spork.prefork block. Since we're running an empty(ish) project, there's nothing special we've added that we need to run on each run using the Spork.each_run block. We can leave that empty.

You'll end up with a spec_helper.rb file that looks like this:

require 'spork'Spork.prefork do  # Loading more in this block will cause your tests to run faster. However,   # if you change any configuration or code from libraries loaded here, you'll  # need to restart spork for it take effect.  # This file is copied to spec/ when you run 'rails generate rspec:install'  ENV["RAILS_ENV"] ||= 'test'  require File.expand_path("../../config/environment", __FILE__)  require 'rspec/rails'  # Requires supporting ruby files with custom matchers and macros, etc,  # in spec/support/ and its subdirectories.  Dir[Rails.root.join("spec/support/**/*.rb")].each {|f| require f}  RSpec.configure do |config|    # == Mock Framework    #    # If you prefer to use mocha, flexmock or RR, uncomment the appropriate line:    #    # config.mock_with :mocha    # config.mock_with :flexmock    # config.mock_with :rr    config.mock_with :rspec    # Remove this line if you're not using ActiveRecord or ActiveRecord fixtures    config.fixture_path = "#{::Rails.root}/spec/fixtures"    # If you're not using ActiveRecord, or you'd prefer not to run each of your    # examples within a transaction, remove the following line or assign false    # instead of true.    config.use_transactional_fixtures = true  endendSpork.each_run do  # This code will be run each time you run your specs.end

Head back to your shell and the root of your project and run spork:

Using RSpecLoading Spork.prefork block...Spork is ready and listening on 8989!

Now we're cooking with gas. Open another shell, head to the root of your project, and run watchr .watchr too. Then head to spec/models/person_spec.rb in your text editor and re-save it (or even make a change if you want). Your specs run but.. they're no faster! What's wrong?

It turns out we need to make another change so that RSpec knows we're running Spork. Edit the .rspec file (mentioned earlier) and add --drb to the line (so it probably reads --colour --drb). Now, edit the spec again, save, and.. fast!

You should note that if you use rake at this point to run your entire suite, it'll still not be particularly fast because rake itself is initializing Rails in order to do its job. But if you want to run your entire suite quickly, just run:

rspec spec

With our dummy app and on my machine, this runs in a wallclock time of 0.759s - a serious improvement over 5.2 seconds.

We have Rails 3, RSpec 2, watchr, spork, and SUPER-DUPER FAST SPECS all running on Ruby 1.9.2. Score!

A minor snafu will remain, though. If you update app/models/person.rb, the change won't take effect in your tests since Spork has the old Person still in memory. One way around this is to edit config/environments/test.rb and change:

config.cache_classes = true

To:

config.cache_classes = false

Now your app's classes are reloaded when necessary.

Level: Intermediate

For many years, serious database aficionados have preferred the Postgres database system. Its industrial strength many installations store terabytes of data. Its fully open source (not controlled by a predatory corporation). Its fast and easy to use. Full text search is built-in. Its the default database for all applications deployed to Heroku.

In 65 minutes, respected database expert (and world-traveling teacher of The Database is Your Friend workshops) Xavier Shay teaches the most useful and powerful features of Postgres. Youll learn to use the built-in full-text search and optimize it. Youll work with triggers and indexes. Youll save yourself hours of frustration with tips for using Postgres smoothly with Rails 3.

If youre familiar with databases but want to add Postgres to your toolbox, this is the video for you!

Youll learn to:

• Setup full text search
• Optimize search with triggers and indexes
• Use Postgres with Ruby on Rails 3
• Optimize indexes by including only the rows that you need
• Use database standards for more reliable queries
• Write powerful reports in only a few lines of code
• Convert an existing MySQL application to use Postgres

Postgres works well as an auxiliary reporting database or as the main database for your application. Get started today!

Subscribe for your business, as an individual, or buy this screencast for only $12!

Includes a typed transcript.

Level: Intermediate

You may not know it, but youve probably used software written by John Barnette. Hes a committer to RubyGems. His initial attempt at fixing the test fixture problem shipped with Rails 2 over three years ago.

Whenever I code with John, I always walk away with something practical that I can use in my web applications.

This screencast is part of a new series at PeepCode where we sit down with expert programmers and watch them work. The point isnt to create a deployable product, but rather to discover workflow tips and development hacks that usually require years of experience to figure out.

In this hour and fifty minute screencast, John tries to build a simple group chat application. And amazingly, he actually completes a prototype and deploys it! If youre like us, youll learn something useful whether or not you use any or all of:

• Ruby
• Sinatra
• Git
• Emacs
• The terminal
• RubyGems
• Test driven development with minitest and rack/test
• Heroku deployment
• Pusher real-time push web service
• Isolate, Johns 500 line sandboxing and bundling library

Unlike most other PeepCode Screencasts, we move through this project with only minimal hand-holding. In fact, John even runs into a few problems and has to figure out the solution on his own.

Subscribe for your business, as an individual, or buy this screencast for only $12!

I caught up with this thread on Joel’s discussion board today. We software developers will take any opportunity to rant about the bass-ackwards code we have to deal with on a regular basis. For passionate developers, it’s understandable that most code wouldn’t live up to our standardsonly a select few projects have the amount of resources necessary to truly pursue perfection. Over time the exposure to imperfect code can condition us with unfair knee-jerk reaction to new code.

How bad is the code really?

The world is full of terrible code. Usually that becomes painfully obvious at maintenance time. When an existing project is opened up for the first time by a new team member, I think the instinct is to see the flaws before the brilliance. What kinds of things make code stinky? Well it depends who you ask, but some possible reasons are:

• Unnecessary duplication of code (under-abstracted)
• Overly complicated code (over-abstracted or unnecessarily clever)
• Too many files/classes
• Giant monolithic classes
• Wrong design patterns applied
• Stupid algorithms
• Failure to use appropriate libraries or framework features (reinventing the wheel)
• Inconsistency (lack of conventions)
• Numerous obvious comments
• No documentation

Anyone whose done their share of code maintenance has probably been annoyed by most of the things on this list one time or another. “If only they had done it this way.” It’s easy to just assume the code sucks based on a first impression. Once you jump to that conclusion, every minor flaw affirms your prejudice.

Pet peeves

Let’s step back a minute and give ourselves an ego check. To an experienced developer there are hundreds of nuances that will stick out like a sore thumb, but they are likely to annoy you far more than they actually impact your productivity were you to consider them objectively.

If you’re not careful, your concern for the code boils over into judgement of the previous programmers. Maybe the last guy wasn’t up to snuff in this language, maybe his pet peeves were different, maybe he was just a blathering idiot. Whatever the case, why dwell on it?

I’ve managed to make it through a lot of bad code without slowing down much. Every once and a while a refactoring or straight-up delete and rewrite was necessary, but most of the time I was able to grit my teeth and get some changes done relatively quickly.

Real reasons code “sucks”

The problem facing you is likely to be different from what the last programmer faced. It would be foolish to assume that the software was designed with the same requirements that you have in front of you today. Who’s to say the business goals haven’t changed drastically since then?

You and the last developer have different information. Even after you’ve spent a lot of time on the code and understand all the intricacies and business goals, you still may not know the history of the project. Maybe the code has grown and shrunk and morphed into something completely different from when it started. If it’s time to refactor, maybe that’s your job.

It’s also quite possible that refactoring is not worth it. Good developers innately want maintainable and aesthetically pleasing code, but there is a cost. We can’t write perfect software before we understand it, and we can’t refactor without spending time. The developer is usually in a better position than the manager to assess the long-term cost of not refactoring, but he also has a vested interested in exaggerating that cost. To make a fair assessment, the developer must have a direct business interest. Even then there’s a great deal of uncertainty. It’s always a gamble.

Cognitive dissonance

Developers are conditioned to be right. Our job requires a fiercely logical thought process and the ability to make absolute assertions. Being wrong means things are broken, sometimes spectacularly so. And because we think so hard about things in this way, our conclusions are usually well-reasoned. But we are still human, and we still have the same defense mechanisms around our belief systems as everybody else. The insidious thing is that our reasoning blinds us to our own subjectivity. Our open-mindedness is a badge of pride, but also a set of subconscious blinders.

The only really objective thing about software is its output.

Software engineering is about making choices. Some choices are pragmatic (C++ for performance), some are philosophical (Ruby vs Python), but most are an intangible mixture of past experience and future expectations. When you see some code for the first time, the chances that it will mesh with your experience and philosophy are pretty slim. Eventually you may come to appreciate it for what it is, but in the meantime every tradeoff that didn’t follow your current line of thought will irk you.

Software is messy

None of this is to say that there aren’t real quality problems in the software industryof course there are. But I think it’s worth carefully considering our own motivations and biases before judging how bad the problem really is.

We may not like dealing with inadequately-funded balls of mud, but that’s probably where most of the paying work is. Even in relatively clean code bases, reasonable people can disagree on style or architecture points. Regardless of initial code quality, there will always be difficult and inelegant maintenance that needs to be done. My goal is to keep emotion out of it, and just fix problems. Refactoring is great if a business case can be made, otherwise just slog through as fast as possible without complaining.

Easier said than done, I know.

Detailed description

In Ruby's $SAFE semantics, safe level of 4 is used to run a untrusted code (such as plugin). So in upper safe levels, some sort of operations are prohibited to prevent untrusted codes from attacking outer (trusted) data.

Exception#to_s was found to be problematic around it. The method can trick safe level mechanism and destructively modifies an untaitned string to be tainted. With this an attacker can modify arbitrary untainted strings like this:

$secret_path = "foo"proc do    $SAFE = 4    Exception.new($secret_path).to_s    $secret_path.replace "/etc/passwd"end.callopen($secret_path) do  ...end

Affected versions

Luckily this attack is ineffective for 1.9.x series of ruby. Affected versions are restricted to:

• Ruby 1.8.6 patchlevel 420 and all prior versions
• Ruby 1.8.7 patchlevel 330 and all prior versions
• Development versions of Ruby 1.8 (1.8.8dev)

Solutions

Please upgrade to a newer version.

Updates

• 1.8.7-334 was released to fix this issue. 1.8.7 users are encouraged to upgrade.
  • ftp://ftp.ruby-lang.org/pub/ruby/1.8/ruby-1.8.7-p334.tar.gz
  • ftp://ftp.ruby-lang.org/pub/ruby/1.8/ruby-1.8.7-p334.tar.bz2
  • ftp://ftp.ruby-lang.org/pub/ruby/1.8/ruby-1.8.7-p334.zip

This is the second release of Ruby 1.9.2. It fixes many bugs found in 1.9.2-p0. See ChangeLog for more detail.

Download

• <URL:http://ftp.ruby-lang.org/pub/ruby/1.9/ruby-1.9.2-p136.tar.bz2><dl>
  SIZE:
  <!-- RDLabel: "SIZE:" -->
  8819324 bytes
  MD5:
  <!-- RDLabel: "MD5:" -->
  52958d35d1b437f5d9d225690de94c13
  SHA256:
  <!-- RDLabel: "SHA256:" -->
  33092509aad118f07f0483a3db1d4c5adaccf4bb0324cd43f44e3bd3dd1858cb
  </dl>
• <URL:http://ftp.ruby-lang.org/pub/ruby/1.9/ruby-1.9.2-p136.tar.gz><dl>
  SIZE:
  <!-- RDLabel: "SIZE:" -->
  11155066 bytes
  MD5:
  <!-- RDLabel: "MD5:" -->
  6e17b200b907244478582b7d06cd512e
  SHA256:
  <!-- RDLabel: "SHA256:" -->
  c4314df44f3ab81230685fb51c296ce21034f4c719e2fcc0baba221d19f28746
  </dl>
• <URL:http://ftp.ruby-lang.org/pub/ruby/1.9/ruby-1.9.2-p136.zip><dl>
  SIZE:
  <!-- RDLabel: "SIZE:" -->
  12566581 bytes
  MD5:
  <!-- RDLabel: "MD5:" -->
  f400021058e886786ded510a9f45b2c6
  SHA256:
  <!-- RDLabel: "SHA256:" -->
  84ffc047b29032ba848dbbf50d3302de7ac732db1448e57303c27ad4b47c2c5b
  </dl>