www.flickr.com
|
Tuesday, August 02, 2005
Ruby on rails nearly derailed on OSX
With all of the fanfare around this super duper ruby on rails framework I've been reading so much about I thought it would be cool to learn something completely out of the realm of the java world. Most time I have little patience for new software packages. If the software can't install and be configured fairly easily out of the box then I know that invariably there's going to be problems while using the software in the long run so I usually dump it and am not much for giving things a second chance. Ruby on rails nearly caused me to give up because of some issues surrounding OSX 10.4 but after early struggles, putting it aside for a week, installing a new version, things worked great.
I went to http://download.rubyonrails.com/ where I followed the instructions:
Here’s how you install Rails using Ruby Gems:
Get hold of RubyGems 0.8.10 (or higher)
gem install rails --include-dependencies
rails /complete/path/to/new/railsapp
I didn't actually perform that last step after installing. I waited until I read the tutorial over at
oreilly.
There he tells you how to get things installed, rails, mysql.
Now that everything's installed I'm ready to create my first application. To do that you invoke a script to generate an application template. I move to my home directory and invoke:
"rails cookbook".
This provides you with a directory containing your skeleton app including a script you can use to start a mini webserver.
Setting my current dir to where my "cookbook" app was generated I start the mini webserver like so:
"ruby script\server"
Then I hit the local URL/port that the server is running on: http://127.0.0.1:3000/
success! I've just done the same thing I've done a million times with apache :-)
So when I created my cookbook/app dir an entire sub directory hierarchy was created. Some of
the more important ones are:
So now that I've got the lay of the land I'm ready to make some magic happen. The next step in the tutorial is to create a controller. I do that with the command:
"ruby script\generate controller MyTest"
That yields me the file my_test_controller.rb in the cookbook/app/controllers dir. I modify the contents to do something interesting, well kinda.
So now if I hit http://127.0.0.1:3000/MyTest I get a page that says "Hello, World". The MyTest URL pattern maps to the controller class and by default calls the "index" method in my controller class.
If I hit http://127.0.0.1:3000/MyTest/foo I get a page that says "Take it!"
This seems quite productive. Within 5 minutes of install I have a webapp that I'm adding custom code to and iterating really quickly. Granted it's not doing much but hey how long does "Hello, World" take in other examples?
Next step: Creating a database for the cookbook app.
I fired up my evaluation version of navicat for managing MySQL instances and proceeded to create a cookbook database and recipes table. Adding a title, description, date, and instructions column to the table.
After defining my table I'm ready to make this table available to my cookbook application. I generate a model class to represent the recipes table as follows:
"ruby script\generate model Recipe"
That produces:
Not much to that huh? Turns out the O/R mapping framework in rails called ActiveRecord will dynamically populate your class with properties based on the database table implicitly associated with the class by name, Recipe->recipes.
Next I need to generate the controller for accessing the recipe object instances as follows:
"ruby script\generate controller Recipe"
That produces an empty class but then I add a bit of scaffolding code that results in the following:
This scaffold code is what provides the default CRUD operations for database tables. This is another area where rails does the heavy lifting for you to get something going.
Now that I'm done creating my model and controller I test my code by trying to create a new recipe with:
http://127.0.0.1:3000/recipe/new
There you see HTML widgets for each of the columns in the database table, rendered appropriately for the data type of each column.
This is very powerful and yet as some of the folks in J2EE land have pointed out, very dangerous or fragile.
There's more to go in my exploration of ruby on rails but this is just a quick rundown of my experiences with it right out of the box. One thing that I didn't like is the lack of a tag library mechanism. It seems that the ruby on rails folks encourage the use of scriplet code embedded in HTML pages, yuck. There's a java.net project underway to borrow/steal from ruby on rails call Trails. I haven't had a chance to look yet but plan on seeing what's offered there. I've read some positive comments around the javaworld about the project so I'm anticipating good things. I have to admit I'm a bit dubious about how large Ruby can become simply because of the amount of investment that needs to occur into things like VM performance, language enhancements, frameworks for various application types, and platforms. Looking at how far Java has come in 10 years you'd better have a pretty compelling reason to re-create alot of the same solutions around an entirely new language.
I went to http://download.rubyonrails.com/ where I followed the instructions:
Here’s how you install Rails using Ruby Gems:
Get hold of RubyGems 0.8.10 (or higher)
gem install rails --include-dependencies
rails /complete/path/to/new/railsapp
I didn't actually perform that last step after installing. I waited until I read the tutorial over at
oreilly.
There he tells you how to get things installed, rails, mysql.
Now that everything's installed I'm ready to create my first application. To do that you invoke a script to generate an application template. I move to my home directory and invoke:
"rails cookbook".
This provides you with a directory containing your skeleton app including a script you can use to start a mini webserver.
Setting my current dir to where my "cookbook" app was generated I start the mini webserver like so:
"ruby script\server"
Then I hit the local URL/port that the server is running on: http://127.0.0.1:3000/
success! I've just done the same thing I've done a million times with apache :-)
So when I created my cookbook/app dir an entire sub directory hierarchy was created. Some of
the more important ones are:
So now that I've got the lay of the land I'm ready to make some magic happen. The next step in the tutorial is to create a controller. I do that with the command:
"ruby script\generate controller MyTest"
That yields me the file my_test_controller.rb in the cookbook/app/controllers dir. I modify the contents to do something interesting, well kinda.
class MyTestController < ApplicationController
def index
render_text "Hello, World"
end
def foo
render_text "Take it!"
end
end
So now if I hit http://127.0.0.1:3000/MyTest I get a page that says "Hello, World". The MyTest URL pattern maps to the controller class and by default calls the "index" method in my controller class.
If I hit http://127.0.0.1:3000/MyTest/foo I get a page that says "Take it!"
This seems quite productive. Within 5 minutes of install I have a webapp that I'm adding custom code to and iterating really quickly. Granted it's not doing much but hey how long does "Hello, World" take in other examples?
Next step: Creating a database for the cookbook app.
I fired up my evaluation version of navicat for managing MySQL instances and proceeded to create a cookbook database and recipes table. Adding a title, description, date, and instructions column to the table.
After defining my table I'm ready to make this table available to my cookbook application. I generate a model class to represent the recipes table as follows:
"ruby script\generate model Recipe"
That produces:
class Recipe < ActiveRecord::Base
end
Not much to that huh? Turns out the O/R mapping framework in rails called ActiveRecord will dynamically populate your class with properties based on the database table implicitly associated with the class by name, Recipe->recipes.
Next I need to generate the controller for accessing the recipe object instances as follows:
"ruby script\generate controller Recipe"
That produces an empty class but then I add a bit of scaffolding code that results in the following:
class RecipeController < ApplicationController
scaffold :recipe
end
This scaffold code is what provides the default CRUD operations for database tables. This is another area where rails does the heavy lifting for you to get something going.
Now that I'm done creating my model and controller I test my code by trying to create a new recipe with:
http://127.0.0.1:3000/recipe/new
There you see HTML widgets for each of the columns in the database table, rendered appropriately for the data type of each column.
This is very powerful and yet as some of the folks in J2EE land have pointed out, very dangerous or fragile.
There's more to go in my exploration of ruby on rails but this is just a quick rundown of my experiences with it right out of the box. One thing that I didn't like is the lack of a tag library mechanism. It seems that the ruby on rails folks encourage the use of scriplet code embedded in HTML pages, yuck. There's a java.net project underway to borrow/steal from ruby on rails call Trails. I haven't had a chance to look yet but plan on seeing what's offered there. I've read some positive comments around the javaworld about the project so I'm anticipating good things. I have to admit I'm a bit dubious about how large Ruby can become simply because of the amount of investment that needs to occur into things like VM performance, language enhancements, frameworks for various application types, and platforms. Looking at how far Java has come in 10 years you'd better have a pretty compelling reason to re-create alot of the same solutions around an entirely new language.
Comments:
<< Home
This is very powerful and yet as some of the folks in J2EE land have pointed out, very dangerous or fragile.
Can you provide some examples?
Can you provide some examples?
Well your schema completely shapes your application pages. So any changes in the schema will automatically change the pages that you see because they're all dynamically generated based on the schema information.
That seems both powerful and fragile at the same time because it may not be desirable to have a column exposed in your app.
Like I said there's still more exploring that I need to do so there might be some ways to change this behavior.
That seems both powerful and fragile at the same time because it may not be desirable to have a column exposed in your app.
Like I said there's still more exploring that I need to do so there might be some ways to change this behavior.
Don't focus too much on scaffolding, it's just a tool to get you started quickly. In a real world application, most (if not all) of it would be replaced by handcrafted code. So your final user interface is in no way bound to your schema...
RoR is definitely more than a CRUD framework, skimming though the API will give you a much better overview of all the neat stuff already available!
Cheers!
RoR is definitely more than a CRUD framework, skimming though the API will give you a much better overview of all the neat stuff already available!
Cheers!
<< Home
Post a Comment