I completely understand the issues behind the story and I agree — it’s much easier to create a new instance on AWS than it is to understand how secure it is. A lot of people have the skills to create instances; fewer have the skills to ensure they’re secure.

This, by the way, is one of the reasons I really like deploying Rails applications on Engine Yard.

When you create an instance on Engine Yard, here are some of the security features you get:

• It’s impossible to ‘ssh’ directly into a system with a username/password. ‘ssh keys’ are required.
• You can only connect to the machines as the ‘deploy’ user — not as root or any other user.
• Once you login, you have sudo access and can swith user to root, but only after you’re on the machine already.
• To enable ‘ssh’ connection for a particular user, you have to log into the Engine Yard admin panel and upload the user’s public key then specifically authorize them on a particular instance.
• The apps in the stack (passenger, rails, mysql, postgresql, etc) are run under accounts with restricted access.
• The database passwords only exist on the instance and are generated random strings.

This isn’t to say that they’re perfect, but I think it does say that a good deal of care has been taken to make sure the instances are secure. Most of the examples in the article were from users who were inexperienced or lacked the knowledge to secure their instances.

I once worked with another customer who deployed their applications using a different (yet commonly used) deployment tool. It created their instances using one of the popular Ubuntu-based AMI’s.

There were a number of security issues with the implementation — primary access to the instances was done using ‘ssh’ with ‘root’ as the login, the database accounts were setup with no passwords, etc. Not that the tool they used didn’t allow these things, but they took extra time to implement and the person who’d set it up hadn’t done so.

Kevin: For our readers who are unfamiliar with Ruby and Rails, can you give us a short description of what they are and what makes them different from other development environments?

DHH: Ruby is a dynamic and object-oriented programming language created in 1995 by Yukihiro Matsumoto. It has been described as a cross between Smalltalk and Perl, but I don’t think that juxtaposition does it justice. Ruby is, more than anything else, a language for writing beautiful code that makes programmers happy.

Rails, then, is an attempt to mold the beauty and productiveness of Ruby into a solution for Web applications. We’ve sought to adhere to the same core principle that guided the development of Ruby: make the programmer happy!

This might all sound mighty fluffy, but only until you recognize that the single-most important factor in programmer productivity is motivation. And, happy programmers are certainly motivated programmers. Thus, if you optimize for happiness, you’re optimizing for motivation, which ultimately leads to an optimization for productivity.

Kevin: What is Rails? Why was it developed?

DHH: Rails is an extraction from a solution to a real problem. It’s not a science project. It’s not something clever men sat down and designed in the highest of ivory towers. It’s simply the generic pieces that were left after I tried to use Ruby to create Basecamp—the Web-based project management system from 37signals.

That means it’s a very pragmatic, very targeted framework with a strong sense of direction. You might not share its vision, but it undeniably has one. I like to call that opinionated software. And Rails sure has a lot of opinions.

From one point of view, it could be said to be the collection of opinions I have about how Web applications should be constructed. Surely you can use Ruby on Rails without sharing all my opinions on how to create Web applications, but the more opinions you share, the less work is put upon you.

And, these opinions are surprisingly simple. They aim to give most people most of what they want, most of the time. It’s a strong disagreement with the conventional wisdom that everything should be configurable, that the framework should be impartial and objective. In my mind, that’s the same as saying that everything should be equally hard.

Kevin: I’ve been reading about Active Record and the ORM (Object-Relational Mapping) capabilitites (or how the application interfaces with databases) that are available using Ruby on Rails. Can you comment on this?

DHH: Active Record has, by many, been called the crown of Rails. Its core mission is to make relational data mesh seamlessly with an object-oriented domain model. And to do so with a minimum of explicit configuration.

So, you’ll have a Person class that’s automatically mapped to a people table (notice the cases and pluralization that Rails automatically figures out). This Person class will then have a first_name method if the people table has a first_name column. So, we’re using reflection and conventions to escape the XML situps that plague frameworks of the old world.

Although the lack of explicit configuration scores high points with the Enterprise crowd used to Hibernate, EJBs and other Java frameworks, it’s the mere notion of ORM that wins big with the PHP/.NET crowd. Active Record relieves you from the vast majority of all SQL writing. It’s automatically constructed on the fly. No more three-line INSERTs, no more repetitive, tedious UPDATEs. The only SQL left is the bottleneck-clearing work where actual brainpower is involved on how to make this query go really fast.

Kevin: For many of our readers to adopt Ruby and Rails (or convince their management to let them), they need real success stories. Where has Ruby and Rails been used to build scalable, production applications?

DHH: Ruby on Rails has been a huge hit inside a lot of organizations. We have some 400 people signed up as working either partially or completely in a Rails-related job. So, like an iceberg, the bulk of the action happens below the surface.

But, we do have a good number of public success stories too. My own company, 37signals, has four widely popular applications used by hundreds of thousands to manage their projects (Basecamp), their personal life (Backpack), their to-do lists (Ta-Da List) and their collaborative writing (Writeboard). That suite has been the number-one poster child for Ruby on Rails and has helped win over a lot of doubters.

But 37signals is by no means the only small team doing big things with Ruby on Rails. The Robot Co-op has a suite of social networks that includes 43things, 43places and 43people. Together, these networks push more than two and a half million dynamic page views a day across their three-machine setup.

Odeo is running Ruby on Rails to power its podcasting portal in front of thousands of subscribers. Evan Williams created Blogger and knows a thing or two about running a huge, public site. He’s at the wheel at Odeo.

Strongspace is just one of several Rails applications in the making from TextDrive. They provide gigabytes of secure hosting in the sky. It’s a really cool and smooth site by the same guys that carry the title of being the official Rails hosting firm.

And, that’s just a small taste. We have major applications in everything from e-commerce to productivity to content—you name it. There are very few kinds of Web applications left that Rails hasn’t been used to create.

Kevin: By the way, I’ve been a Backpack user for a while and I love it. Was it completely developed using Rails?

DHH: Backpack is indeed 100% Ruby on Rails. When it launched, it was a mere 2,000 lines of code.

Kevin: Java had been around for a while before it really penetrated the enterprise. It took the development of J2EE for it to establish itself as a true “enterprise development platform”. The addition of transactional management, flexible deployment strategies and so on seemed required for it to mature into that role. Could you see Ruby and Rails eventually following a similar path, or do you think its role will be something different?

DHH: We have a wide enterprise audience that uses Rails simply because it gets the job done, faster. I think we’ve seen the peak of Java in the enterprise. I’m sensing an understanding that while Java and the J2EE gang certainly has its uses in legacy integration, huge distributed setups that require two-phase commits and so on, it’s way overkill for the majority of applications created in the enterprise.

Dave Thomas from the Pragmatic Programmers recently expressed this as “cracking nuts with a sledgehammer”. Yes, a few special jobs do need sledgehammers. But you don’t need to use it [a sledgehammer] for all the other jobs that need to get done.

That’s why having a company standard on something like Java and J2EE seems so nonsensical. Why would you use the heaviest and slowest machinery to solve the 80% of the business that would rather have its valuable software two, three, five or ten times faster? Or, whatever the multiplier is in your environment. So, keep the big guns in store for that last 20% that actually requires it.

Kevin: Is there anything else you think is important to tell our readers about Ruby and Rails?

DHH: Give it a try! We’ve fought hard to make Ruby on Rails the easiest Web-application framework to try out. Get Ruby, get RubyGems (the apt-get of Ruby libraries), gem install rails, rails my_application, and you have your application skeleton running and ready to produce.

It’s hard to relay in words just how fast and easy it is to get started. So, I would invite your readers to check out the 15-minute video on the Rails Web site where we build a complete, if simple, blogging engine.

You have an attribute that can be a set of specific values, like the status of a transaction that can be ‘processing’, ‘succeeded’ or ‘failed’.  You now want to make it easy to check these values on your model object and you think you might want to create a named scope for one of more of them.

Here’s a simple ‘design pattern’ that makes this easy and fast.

First, define a Module within your Class and use it to define constants for the allowed values, then put those values in an Array. This tightens up the code by encouraging developers to only set that attribute to one of the ‘predefined’ values. For example:

class Transaction < ActiveRecord::Base

  # Allowed values for attribute 'status'
  module Status
    PROCESSING = 'processing'
    SUCCEEDED   = 'succeeded'
    FAILED     = 'failed'
  end
  STATUSES = [Status::PROCESSING, Status::SUCCEEDED, Status::FAILED]

end

This is a simple ‘design pattern’ that encourages the use of good practices in development.

Now that we’ve got this in place, let’s spin up some ruby magic to automate the creation of status methods and named scopes for each of the different values. We’ll do so with this bit of code:

STATUSES.each do |status|
   # Define a 'setter' method for each status value
   define_method "#{status}!".to_sym do
     self.status = status
   end
   # Define an 'interrogator' method for each status value
   define_method "#{status}?".to_sym do
     self.status == status
   end
  # Define a named scope for each status value
   self.named_scope status.to_sym, :conditions => { :status => status }
 end

It’s part of the magic of Ruby that classes can so easily extend themselves by adding new methods.

And if you change the allowed values for the ‘status’ field, simply modify the Module definition and add the new value to the array — creation of named scopes and the other methods will be taken care of automatically.

Sometimes when using Active Record you may want to create a database connection to a database other than the default database specified in your database.yml file.

When this happens, the easiest way to do it is to use the Class-level convenience method on ActiveRecord::Base. Like this:

Imagine your database.yml entry looks like this:

development_foo:
  adapter: mysql
  encoding: utf8
  database: foo
  pool: 5
  username: my_user
  password: my_pass
  socket: /tmp/mysql.sock

Now you want to create active record models that use that database connection. Here’s how:

# 'Bar' model points to the table 'bars' in the database 'foo'

class Bar < ActiveRecord::Base

  # specify the database.yml entry
  $db_config = 'development_foo'

  # Fetch the database.yml configuration
  $config = ActiveRecord::Base.configurations[$db_config]

 # Now we can establish a connection to that database and
 # this ActiveRecord model class will point to that database.
  establish_connection $config

end

It’s simple!

Copyright Kevin Bedell, 2009
All this code can be freely used under the terms of the MIT License.