This one will be more geeky: code contained herein.
The silver bullet of making applications is motivation. It’s the key to productivity. We should promote motivation. Motivation comes from happiness. Optimize for happiness. But how?
David didn’t used to be a happy programmer. He liked the end result, but not the process. The key factor to happiness is beautiful code.
Your application is not a beautiful snowflake. You are not special. Most of the work you do revolves around the same mundane details as everyone else.
Convention over configuration: because 80% of what you need to do is the same as everyone else. The 20% lets you be a beautiful snowflake for a brief moment.
Beautiful code is succinct and doesn’t repeat itself. In Ruby, configuration is very, very succinct because classes map to database tables. It’s a pattern that’s been abstracted, saving explicit configuration. The same goes for the primary key: it’s the same name, “id”, for each table so there’s another convention right there. There’s another pattern for foreign keys so that’s abstracted too.
But it’s convention over configuration: not never configure. If you need to do something outside the convention, that’s fine too. The assumptions come from conventions, but the exceptions are handled by configurations.
Another convention: matching names from the server to names on the client. The first part of a URL maps to a class; that assumption derives from a convention.
Flexibility is over-rated. You’re trading flexibility for productivity. Stop chasing it so religiously. Correspondingly, constraints are liberating. It encourages consistency. You don’t have to worry about naming things and mapping classes.
Do the right thing. Developers have a little angel over one shoulder and a little devil on the other. The environment determines the size of the devil or angel. The devil tempts you, telling you to leave stuff ‘till later. The angel is telling you to test. The angel wants you to follow best practices. PHP is the devil: constantly tempting you to the quick, ugly hacks. Ruby on Rails is the angel. The angel is embedded in RoR.
In Rails, you have to go out of your way to do something ugly. Test files are automatically created. Invitations to do better are embedded. You are constantly reminded of what you should be doing.
You are also given opportunities. You are encouraged to see the correct relationships between classes/tables: those relationships are exposed.
Expectations are also embedded. You are expected to use best practice. The community questions the way things are coded: is this the best way?
Sometimes the beautiful thing is to get out of the way.
When should you use Ruby on Rails? When you feel the hurt. If you’re not annoyed by the devil whispering in your ear, you’re probably not ready yet. But you will feel the hurt. Then you’ll be ready.
Are you overburdened by complexity? Do you appreciate agility? Do you appreciate testing? Rails is for you.
Q. Does it scale? A. Yes.