This is the third article in a series to try to convince more developers to learn Ruby on Rails, even if they are not involved in web programming. See also part II.
As developers we have come to expect a great deal of pain in our lives. It stated when we deciphered cryptic error messages from our first C compiler, continued through poorly documented tools, and then extended into just using our operating system. Later, developing for APIs like Win32 quickly turn into trial and error sessions. Long periods without progress.
Things just don't have to be this way. Rails taught me this. While installing Rails was less than trivial for cygwin, it certainly keeps things moving.
When you create a new rails program, using the rails command, it is ready to run. Immediately. Run script/server and it is a go. It doesn't do anything, but it is configured for me. I'm ready to develop it, Rails does not get in the way.
Immediately I know the installation worked. I see this immediate feedback everywhere I look
- Scaffolds - ready to run out of the box
- Generated tests - ready included by the included Rakefile
- Database migrations - forward and backward, generated for me ready for rake db:migrate<
- Models - immediately accessible from the console (post migration). Test data generated too.
- Controller actions usable via a standard URL.
- Views, properly named already routed by the controller's default action
And of course, code changes immediately reparsed in the development environment. But there is more. Gems and plugins, with a single command they are ready to use. No restarting Windows.
This instant feedback loop is simply addictive. Productive too - keeps my attention span locked in to the development of the project. I want my customers to get this instant feedback as well, so they are addicted to my product, find it so easy to use. No waiting. No trial and error.
Install and have the reference demo running in 20 seconds. That's where Rails has put the bar.
No comments:
Post a Comment