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.

In general, I’ve found more success using the simple_form library for generating form processing. I’m a huge fan of JQuery itself and use it a lot, but I find JQuery UI to be less valuable. It seems over-engineered for what people use it for.

What I’ve found with JQuery UI sometimes is that people use it because it promises a lot of capability with not very much coding effort. But the challenge comes when there is debugging to do or when you want functionality that is not ‘out of the box’.

I had a customer very recently that brought me in to address some issues getting a complicated form to work on a project that used a lot of JQuery UI components. They had used these components and then tried to extend them because the functionality they wanted wasn’t exactly ‘out of the box’. It ended up being very complicated to debug and it took me close to a day to trace one of the defects back into the JQuery UI component itself — it was placing random extra elements in the DOM on the browser and causing some things to not work.

Debugging complicated JavaScript issues in the browser is more complicated than tracing rails exceptions on the server side.

simple_form, on the other hand, is a much simpler framework to use. Basically the views are very simple and styling and layout is determined through css. If you need any dynamic features on the form you can implement them using straight JQuery — which gives you a wealth of capability. Trying to add JQuery functions on top of JQuery UI components is much more complicated to debug.

Here’s a railscast on ‘simple_form’ – that’s a good place to start. It’s getting to become the most widely accepted way to do form processing for rails.

All this being said, using JQuery UI for to implement components of a view that aren’t related to forms processing may be the best way to go.

I figured I’d share them here since there may be other people around asking the same questions.

These links are references to the ‘guides’ that were developed as documentation by the Rails community. They’re ‘reference guides’, so they’re deeper in places than you’ll need. But I think they’re useful and I refer to them often.

1. Getting Started. To get started, the first thing is to just build a simple app and get it running. This, if nothing else, verifies that you have everything installed correctly and introduces you to the basics of building a rails application.

link: Getting Started with Ruby on Rails.

2. ActiveRecord. The first thing you need to understand with Ruby and Rails is how ActiveRecord works. It’s more than just the interface layer to the database, it’s the foundation of all your ‘Model’ code including data validation and relationships between objects.

Link: Active Record Query Interface

3. Rails routing. Understanding the routing in Rails is something that a lot of beginners miss — and it makes their first applications sub-optimal. Also, understanding the routing rules makes things so much easier. And it’s core to understanding the ‘restful’ concepts behind rails.

Link: Rails: Routing from the outside in.

4. Rendering views. A lot of the magic in rails happens in how easy and flexible it is to build, change and rearrange the actual pages you’re building — the ‘view’ part of the Mode-View-Controller model that Rails is based on. This guide gives you an introduction to how all that works and what the options are. Notice also how it builds on what you learned in ‘Rails Routing’.

Link: Rails Views: Layouts and Rendering.

Don’t get discouraged and don’t underestimate — this is a bit of work. But the value is great.

These guides are build to some extent as ‘reference guides’, so don’t worry about understanding every line. But scan and read some portions deeply — and you’ll come away with a great foundation in what Ruby on Rails is and how it works its magic.

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.

From the site:

“BarCamp Boston is Boston’s geek unconference, organized on the fly by attendees, for attendees. Visit the website and wiki at BarCampBoston.org. There is no registration fee, and all attendees are equal… but you don’t just attend a BarCamp — you can participate in discussions, host a session of your own, or join in another cooperative event (startup founder match, programming contest, design competition, and more…).”

Link:  BarCamp Boston 6 at 1 Memorial Drive, Cambridge, MA – Conferences,seminars on Plancast.

This first file should be put in /lib/app_config.rb.

# This singleton class stores configuration options.
# It makes use of Ruby's method_missing method
# Any option added to the application's config file
# is automatically available as a method of the same name.
#
class AppConfig
  include Singleton

  def method_missing(methId)
    instance_sym = ("@" + methId.id2name).to_sym
    instance_variable_set(instance_sym, @parser.send(methId)) unless     instance_variable_get(instance_sym)
    instance_variable_get(instance_sym)
  end
end


The above code uses method_missing to create methods on the fly that correspond to different configuration variables. Add the config variable, and it automatically becomes available as a method on the AppConfig singleton class.

You need this class to load and parse the yaml file that the data is stored in. It should be in /lib/yaml_app_config_parser.rb.


# This class parses /config/application.yml
# It supports both default and environment options.
# Environment options override the default options.
class YamlAppConfigParser

  def method_missing(methId)
    if @yaml[RAILS_ENV] && @yaml[RAILS_ENV][methId.id2name]
      @yaml[RAILS_ENV][methId.id2name]
    else
      @yaml['default'][methId.id2name]
    end
  end
end


The above 2 files you just put in your project and forget about. Then, you just add config values to the /config/application.yml file, and they become available config variables that vary by environment.

Here’s what a basic/config/application.yml might look like.


default:
  facebook_app_id: adsf78yadfkjasdf807y
  facebook_secret: adsf78yadfkjasdf807y
  path_to_file_foo: /mnt/files/foo.bar

production:
  facebook_app_id: my_prod_fb_app_id
  facebook_secret: my_prod_secret


Notice that the production environment has its own facebook_app_id and facebook_secret values, while the development environment just uses the default values. That’s how this approach works – you override only what you need.

Now to access these values from your code is simple, you just call:

  @facebook_app_id = AppConfig.instance.facebook_app_id
  @facebook_secret = AppConfig.instance.facebook_secret
  @path_to_file_foo = AppConfig.instance.path_to_file_foo

Then the variables you’ve set as above contain the configuration values specific to their environment.

But then, inevitably, once we’ve collected e-mails from all our customers and we go to use them – we get bounces. Which leaves us to clean up the mess – and there usually is a mess to clean up if we can’t tell the customer their order is ready or that we need information from them. Worse yet, we might just assume the information got through correctly and go on our merry way – leaving our customer dangling.

And while we’re quietly cursing our chubby-fingered (yet all important) customers, we wonder (or scream!) to ourselves why we don’t just write some code to validate the e-mail addresses when they’re entered?

But anyone who’s really looked into doing this will tell you that it gets deep quickly. What seems like it should be straightforward ends up arcane and impossible.

To begin with, e-mail address formats are covered by RFC 822 – which is filled with impenetrable discussions on “sequences of lexical symbols” such as “atoms”, “special characters”, “domain-literals” and “comments”.

“comments”? Yes, e-mail addresses can contain comments. I tested them too – and they work. A comment is (to the best of my knowledge) any text placed in parentheses anywhere in the email address. For example, my e-mail can be:


* kevin@kbedell.com, or
* kev(you da man!)in@kbedell.com, or
* kevin@k(evin)bedell.com


All these work – I tried them. Try validating that. I dare you.

Another bit of a twist is that you can also specify an IP address instead of a domain name. For example, I’m not only “kevin@kbedell.com”, I’m also kevin@216.80.243.82.

To make matters worse – as it should be expected to get – many mail servers won’t accept emails even if they are valid. For example, my mail server won’t accept kevin@216.80.243.82 – the anti-spam controls bounce it.

Imagine – all that work to validate it, and it still won’t work. Makes you want to spend your days surfing these pages…

I even ran across one brave soul that came up with a regular expression that he was sure could validate an e-mail address. Here it is:


function isValidEmail(emailAddress) {
var re =
/^(([^<>()[\]\\.,;:\s@\”]+(\.[^<>()[\]\\.,;:\s@\”]+)*)|(\”.+\”))@((\[[0-9]{1,3}\.[0-9]{1,3}\.[0-9]{1,3}\.[0-9]{1,3}\])|(([a-zA-Z\-0-9]+\.)+[a-zA-Z]{2,}))$/
return re.test(emailAddress);
}


Wow. That’s a mouthful. Of course, I’m so jaded by now that I’m sure he must’ve missed something. Or that the emails will just get bounced anyway.

So is validating an email address impossible? Here’s the answer: It’s easy!

You don’t have to be a genius to validate email addresses. All you have to do is send a test e-mail to the customer! Really – this is the only way. If it gets through, the address is valid. If it bounces, then it’s not.

Now let’s just hope no one ever changes their email address once we validate it…

Are my points “valid”?

[Note: This is a repost of a post I originally wrote for The O'Reilly Network in December of 2002]

Data loading is done for 2 purposes: First, to load data that will seed the system for ongoing use and that will live in the production environment, and second, to use for system testing. These two types of data are stored in two different ways.

Loading ‘seed’ data that will be required in production.

This data should be defined in /db/seeds.rb and loaded using the rake db:seed command. It should be loaded one time after initial database creation. If changes to the seeds.rb file are made, the database should be rebuilt and reloaded from scratch.

Loading test data.

This is data that is required for testing the application. Specifically, it is data that should not appear in the production application.

This data should be loaded through model classes (or using factory_girl or similar) in a ‘rake’ file, for example /lib/tasks/test_data.rake and then load it using the rake task rake app:load_demo_data. Similar to loading seeds.rb, if the test data changes then the database should be reloaded from scratch.

(Note that here the rake file is named /lib/tasks/test_data.rake and the rake task to load the data is rake app:load_demo_data. This would vary based on what you felt was an appropriate name for your project.)

Overall database loading/unloading

The correct way to load data into the database is to use the following rake commands:

rake db:drop db:create db:migrate db:seed app:load_demo_data

As you see, multiple rake commands can be run one after another sequenced on the same line.

This should be able to be done at any time by any person in development. If you make a change to any data, please assume that the above sequence of rake commands could be run at any time and all data could be replaced.

Note also that the above command will load data into the ‘development’ instance of your database. If you need to load (or reload) the production or test environments, then precede this command with the appropriate RAILS_ENV like so:

RAILS_ENV=test rake db:drop db:create db:migrate db:seed app:load_demo_data

Here’s an example of what the rake file /lib/tasks/test_data.rake might look like:


namespace :app do
  desc <<-DESC
    Load testing data.
    Run using the command 'rake app:load_demo_data'
  DESC
  task :load_demo_data => [:environment] do

  end
end


Why’s (Poignant) Guide to Ruby

Why’s (Poignant) Guide to Ruby is a classic. It’s done in an the format of a graphic novel and contains a lot of fun and interesting material. It was done by Why the Lucky Stiff, a cult figure in the ruby community that you should know about.

Rails for Zombies by EnvyLabs

A fun and entertaining guide to ruby on rails. Be careful, you may find yourself craving brains and entrails for lunch if you finish this one — though your rails skills will be better off for the effort.

Try Ruby!

An easy to use place to begin learning about Ruby (Not so much about rails, tho). It’s a great place to start if you are literally starting from scratch.

Ruby on Rails Tutorial

This is a non-free resource, but is well done and may be worth investing in if you are serious about learning the material. Highly recommended.

Ruby Koans

Ruby Koans is an interesting and insightful set of lessons on Ruby (not rails) that focuses on teaching through a set of unit tests. One of it’s strengths is that it introduces you immediately to the value and practice of unit testing — a critical skill and a core value of the ruby community.

The Rails API Docs

If you’re going to be a rails programmer, you need to have this url handy. Have a question on the :belongs_to statement? Want to understand the call-back lifecycle for active record model classes? It’s all here. Not for beginners, but definitely required before you’re ready to call yourself a master.

Railscasts

On of the best and one of my favorite resources on rails. Railscasts are an important resource for the entire rails community. They are a series of free — and very useful — videos on various topics in rails development, complete with source code. Want to know about Ajax calls? Want to understand the latest in authentication libraries? It’s all here.

RailsBridge

RailsBridge is an effort to build community around helping people learn rails. It’s people helping people. You can find a mentor there, get involved with something in your community, learn by volunteering time to a non-profit. It’s a valuable resource.

RubyLearning

Ruby Learning is a site put together by Satish Talim, a senior software consultant based in Pune, India. He’s done a thorough job of providing lessons on many aspects of the ruby language. The site is a bit over-done with adsense and other advertising, but there’s a lot of meat there too.

Peepcode Screencasts

Peepcode Screencasts are another well-known resource in the rails community. Similar to Railscasts, they publish a regular series of videos on different aspects of rails development. The screencasts aren’t free, but considering the time they could save you they could be a great investment in terms of getting you up to speed fast. They’re widely known and recommended.

To begin with, I’m not sure I agree with the premise of the question, in general.

If you want good solid work and it’s early, then pay people or make them cofounders.

Offering them a revenue share later (assuming revenue shows up) is problematic for just the reason you’re asking — what do you do if the revenue doesn’t show up?

Trying to find programmers willing to work for a promise of a share of potential revenue is likely to attract only programmers who can’t get a better deal. In other words, if they were really good they’d either be co-founding something or getting paid well for their skills.

Bottom line — either make them ‘co-founders’ or pay them. If not, you’ll increase your potential to attract people with nothing better to work on.