Blog

Archive for June, 2009

What is RubySpec?

By | June 11th, 2009 at 8:06AM

You might think that What is the meaning of life? is a tough question. But here’s one that will give it a run for its money: What is Ruby?

Ok sure, that comparison is hyperbole, but bear with me. Try this out in your irb session:

>> Float("0.5") == "0.5".to_f
=> true

That’s reasonable enough. Imagine if it weren’t true! But did you know that the Float() method converted the "0.5" text string to a Float object without calling the string’s to_f() method?

What is the definition of Ruby in this situation? Is it that Float() returns a Float object for a validly formatted text string or that Float() does so without calling the string’s to_f() method? Let’s investigate the situation a bit more.

In Ruby, if you define an arbitrary object that you want to behave like a Float object, you define a to_f() method for your object. Then Float() will call that method on your object:

>> s = "0.5"
=> "0.5"
>> def s.to_f() 42 end
=> nil
>> floaty = Object.new
=> #<Object:0x5eb190>
>> def floaty.to_f() 0.5 end
=> nil
>> Float(floaty) == Float(s)
=> true

Now that is surprising. A lot of the elegance of Ruby comes from generally everything being an object. In some sense, floaty and "0.5" are just objects, so why does the Float() method treat them differently?

More importantly, should you rely on Float() not calling your string’s to_f() method, or is that merely an implementation detail of MRI (Matz’s Ruby Implementation)? This is the dilemma faced repeatedly by every alternative Ruby implementation.

Fortunately, we have a powerful tool to assist us.

The RubySpec project is writing an executable definition of the Ruby programming language using RSpec-style specs. The tremendous utility of the specs is that alternate Ruby implementations can run them to determine if they are building a compatible Ruby engine.

Presently, the specs contain over 33,000 precisely defined facets of Ruby behavior. The specs cover Ruby behavior across different platforms, operating systems, and versions of the Ruby language. The goal is to ensure that Ruby applications written to use the core Ruby features covered by the specs will run the same on any Ruby implementation.

RubySpec has been well-known in the community of Ruby implementers for almost two years. Every major Ruby implementation is using it. However, many Ruby programmers are just learning about it. RubySpec has a lot to contribute to the larger Ruby community. Recently, I explain some ideas about this in an interview with Gregory Brown. Greg is starting a project, called Unity, to make the information contained in the RubySpecs more accessible to everyone.

Contributing to RubySpec is a great way to learn more about the Ruby programming language. At the same time, your contribution helps the alternate Ruby implementations and the Ruby ecosystem. In the past couple of weeks, contributors have added tons of fixes to the specs for Ruby 1.8.7 and 1.9. Check out their excellent work at the RubySpec Github repository.

I’ll be speaking about RubySpec at the upcoming Open Source Bridge conference June 17-19. If you have questions about RubySpec that you’d like me to address, please leave a comment.

Popularity: 1% |

BigDecimal Vulnerability in Ruby 1.8.6 and 1.8.7

By | June 10th, 2009 at 9:06AM

Yesterday, the first security vulnerability since Engine Yard took over maintenance of Ruby 1.8.6 was reported. It is a Denial of Service vulnerability in BigDecimal, by which an attacker can cause a segmentation fault by providing a very large number as input. ActiveRecord relies on BigDecimal, but this is not Rails specific.

Today, as part of our maintainer role for 1.8.6, we published a fix as part of Ruby 1.8.6 patch-level 369 and as a part of Ruby 1.8.7 patch-level 173.

The issue was initially discovered and fixed in the Ruby 1.9.1 trunk. We backported the fix to 1.8.6 by writing a test, watching it fail, then making it pass (the same way we always do). As part of our test-driven approach, Kirk Haines then added a test in RubySpec to test for the condition. We ran the test suite on OSX, RedHat Enterprise 3, CentOS 4, 32 and 64 bit Engine Yard Solo instances, and an Engine Yard Slice to verify the fix.

Engine Yard customers have been notified about the vulnerability via email with instructions on how to upgrade. Engine Yard Solo customers can get the new, patched version of Ruby 1.8.6 simply by redeploying their environments. In the future, new Engine Yard deployments will automatically get the new version.

Popularity: 1% |

New Solo Release—Server Monitoring, Self-Managed vhost Templates

By | June 8th, 2009 at 2:06PM

Today we’ve shipped a new release of Engine Yard Solo. This release includes a ton of bug fixes, but also contains a killer new feature.

We’ve enabled server monitoring for all customers!

Once you enable this new feature by hitting ‘Deploy’ in your dashboard to sync our recipes, you will have full server monitoring enabled for a number of important stats:

  • Load Average
  • Free Memory
  • IO-Wait
  • Swap Used
  • Free Disk Space for EBS volumes

Engine Yard Solo server alerts report

We will start collecting server alerts for you and displaying them in your dashboard. This is a great feature to give you much more insight into what your slices are doing and how healthy they are. The alerts screen gives you an at-a-glance place to see the health of your deployments — if the top of each section is green you know you are in good shape. If the top of each alert section is yellow or red — you know there may be some issues to look into and what the issues are!

We’ve also released a way for you to tell our automation system that you have local edits to certain config files that you do not want us to stomp on or touch. This is especially important for some apache or nginx vhost files. Before this change there was no way for your local edits to survive a ‘Deploy’ of our recipes. Now if you want to keep a config file with your own edits you just have to rename it with ‘keep.’ prepended to the name.

For example, say you want to edit the nginx vhost for your application that lives at /data/nginx/servers/myapp.conf. If you make changes to this file, all you need to do is rename it to /data/nginx/servers/keep.myapp.conf, and we will never touch that file again until you rename it back or remove it. This gives you the power to make customizations to your vhost configs without us stepping on them later. And since your vhosts are stored on your /data partition, which is an EBS device, your changes will even persist across terminate/create events as long as you mount the same volumes when you boot your environment back up.

I think these features make the platform much more useful and I hope you enjoy using them.

Popularity: 1% |

Http Digest Auth: Vulnerability in Rails 2.3.1/2

By | June 4th, 2009 at 5:06PM

If you are using Ruby on Rails 2.3.1 or 2.3.2,  using http *digest* authentication and setting the username / password via hash, then you will be affected by this vulnerability. This vulnerability allows users to bypass http authentication without a valid password.

Please read the full posting on the Rails Security Group for more details and the appropriate workaround to implement in your code, until the official fix is available in the 2.3.3 release.

(Engine Yard customers have already been contacted via email about this vulnerability).

Popularity: 1% |

Engine Yard Adds JRuby Support

By | June 1st, 2009 at 6:06AM

Today at JavaOne, Engine Yard is announcing support for JRuby. This means that people will soon be able to select JRuby as a runtime option for Engine Yard Cloud, and subsequently on the Engine Yard private cloud for cluster and slice customers. We’re excited to partner with Charlie Nutter and Tom Enebo and the broader JRuby team to make this happen. JRuby support will be in beta for Engine Yard Cloud in early July.

Since we’re announcing this at JavaOne, it might be good to reiterate the main reasons why Java developers have migrated and are continuing to migrate to Ruby and Rails:

  1. Rails: easier to learn, and faster to code than Java frameworks, and with Rails 3 coming—even simpler to extend.
  2. Ruby: easier to write with lots of means of abstraction (blocks, modules and metaprogramming.)
  3. Ruby: faster for iterative and agile methods with dynamic typing and no compile cycles
  4. An active community with excellent tools, training and lots of innovation: Agile Development With Rails, TextMate, Peepcode, RubyForge, RSpec, DataMapper, Rack etc.

Not to mention excellent REST support, a very fast regex engine, great collections handling, and all the other hundred reasons why people simply ENJOY developing in Ruby.

Very practically, we’re also adding JRuby support in response to demand from both companies and from professional web developers, who want to use Ruby and Rails, but have existing libraries written in Java.  For various reasons, they sometimes prefer Java native integration over the more ideal method of exposing old code via web-services. These folks like JRuby because it gives them an easy way to transition from Java to Ruby without having to re-write all their existing libraries on day one with Ruby (or completely swap out their platform and tools). In our mind, when you’re getting people to adopt a language and framework like Ruby and Rails—the more you can do to keep backward compatibility with existing stuff (code, tools, platforms) the better.

With JRuby support, our ongoing maintenance of the 1.8.6 branch of MRI and our continued sponsorship of Rubinius, we hope that Engine Yard is continuing to help Ruby and Rails be the first choices of web developers everywhere.

Popularity: 1% |