Part 2 of Ruby on Rails Tutorial Online

An anonymous reader writes "Curt Hibbs has released Part 2 of his tutorial Rolling with Ruby on Rails to the O'Reilly ONLamp site. The first part was published in January. Topics covered are database transactions, callbacks, unit testing and caching." From the article: "In Rolling with Ruby on Rails, I barely scratched the surface of what you can do with Ruby on Rails. I didn't talk about data validation or database transactions, and I did not mention callbacks, unit testing, or caching. There was hardly a mention of the many helpers that Rails includes to make your life easier. I can't really do justice to all of these topics in the space of this article, but I will go into details on some of them and present a brief overview of the rest, with links to more detailed information."

Comments

Python Version of RoR

[grayrest]

http://subway.python-hosting.com

It's rough, but it's coming along.

Re:Python Version of RoR

[jellomizer]

It is always good to have two closly competing languages. Ruby and Python are so close in design it helps keep both on their toes. Some people consider Python and Perl to be competive but the language syntax is much more different, and often lead to more of a holy war debate on what is better. While I don't find this type of argument for Python vs. Ruby But I could just be looking in the wrong spots.

Re:Python Version of RoR

[m50d]

Cobol fingers? If you've ever coded in a team you will be indenting anyway, python just means you can type most of the language using the normal keys, rather than twisting your fingers round to reach the edge of the keyboard at every turn. (Seriously, how do you type all that punctuation? I suppose the extreme conciseness of perl means there's less typing overall which maybe makes up for it, but still....)

Re:Python Version of RoR

[Colonel Panic]

Wouldn't that be PoR?

Seriously, though, I really think that Ruby the language is part of what makes RoR so great. I'm not sure you can do a lot of the same stuff in Python as you can with Ruby. Being able to define natural looking domain-specific languages using Ruby's code blocks seems like something that would be very difficult in Python. But as they say, imiation is the sincerest form of flattery...

Re:Python Version of RoR

[Colonel Panic]

Sorry...
That should be 'immolation is the sincerest form of flattery'.

Re:Python Version of RoR

[Simon]

Being able to define natural looking domain-specific languages using Ruby's code blocks seems like something that would be very difficult in Python.

Do you any examples of this in action? I mean a non-trivial example showing a Ruby block based solution for a problem that is clearly better than the more tradional (messy?) solution.

Impress me. :-)

--
Simon

Re:Python Version of RoR

[Anonymous Coward]

Being able to define natural looking domain-specific languages using Ruby's code blocks seems like something that would be very difficult in Python. But as they say, imiation is the sincerest form of flattery...

Yes, the guys who invented Smalltalk must be really proud that Ruby has finally managed to produce a popular version of all their innovations.

Re:Python Version of RoR

[Tyler Eaves]

Haven't done any ruby in a while, so I don't have any code handy, but blocks are great for things like GUI callbacks. You can put the code right where it would logically fit, and you don't end up with a 1001 quitButtonOnClick() type functions cluttering your namespace.

Re:Python Version of RoR

[BridgeBum]

Similar ideas worth taking a look at for python:

http://www.cherrypy.org/

BSD Licence, also based on MVC style design.

Re:Python Version of RoR

[smittyoneeach]

Hopefully not a Java-esque Megalithic Vacuous Classterfsck (MVC).

Re:Python Version of RoR

[Anonymous Coward]

[3, 4, 2, 6, 7, 8, 1, 12, 5].sort { |x, y|
if x >= 5 and y >= 5
y x
else
x y
end
}

This sorts the array in the ascending order up to 5, and in the descending order after that, which gives [1, 2, 3, 4, 12, 8, 7, 6, 5]. This is a very simple example, but it would be less nice without blocs. Then you have more interesting cases, like:

[1, 3, 7].collect { |x| x+1 }

Which gives [2, 4, 8]. The result array is built by taking every element of the first array and applying the bloc to it. Not convinced ?

[3, 4, 12, 76, 2].find { |x| x > 4 and x.modulo(2) == 0 }

Gives 12, of course. But by using the same bloc with find_all instead of find, you get [12, 76].

Of course, it's nothing new. You could get an equally nice syntax by using a functional language. But to my mind, ruby brings you the best from OOP and the best front functional programming. I just wish it was faster.

Re:Python Version of RoR

[congaflum]

The ActiveRecord classes in Rails make use of these sorts of things quite a lot. For example:

class Firm < ActiveRecord::Base
has_many :clients
has_one :account
belongs_to :conglomorate

before_destroy { |record| Client.destroy_all "client_of = #{record.id}" }
end

The before_destroy is a callback used to implement triggers in the code, similar to how they'd work in the DB. Shown here using a block but you can also just have regular method calls.

Although it doesn't use blocks, I think the very declarative-looking use of has_many etc is quite nice too.

Re:Python Version of RoR

[Paradox]

I can't impress you, sorry. But I can say that Ruby blocks are a powerful tool that are very flexible and useful. Ruby iterators are the showcase of this tool, and they're something you use every day in ruby. For example:

ary = [1,2,3,4,5] # Example Array
ary.each do |val| # Begin a block
puts val.to_s + " was here!"
end

Blocks can be used inline as above, or turned into true closure-bearing functors like so:

my_block = lambda { |x| puts x.to_s was here }
my_block.call "Kilroy"
ary = [1,2,3,4,5]
ary.each &my_block

You can write higher order functions that accept lexical blocks trivially. For example:

def my_hof( &block )
yield # Calls the associated block within scope
block.call #Calls the associated block as a function
end

Also, ruby's blocks are used to do neat things like ensure things happen at the end of an operation. File I/O is the classic example. Check out how Ruby's library ensures your file closes:

File.open( "somefile.txt", "w" ) do |handle|
handle.puts "This is text in the file."
end # File is ensured to be closed now

This is just a small sample of what Ruby's standard lib does with blocks. They're really quite useful. They're like Lisp's lambdas but with a cleaner syntax when used inline.

Re:Python Version of RoR

[Paradox]

It isn't just Ruby's blocks that make Rails so great. It's the fact that it's possible for Ruby Classes to reopen themselves and dynamically define, alias, and remove methods from themselves.

When you see a block of code like this in Rails:

class Person < ActiveRecord::Base
has_many :addresses
has_and_belongs_to_many :friends, :class_name => "Person"
end

What it does is take the schema for the People table, parse it, and actually re-open the Person class at runtime and adds the methods to support the schema fields and relations.

Open classes are something many languages frown upon, which is why it's so darn hard to make an ActiveRecord class or an ActionView class like Rails' in another language besdies Ruby.

Re:Python Version of RoR

[thraxil]

list comprehensions are fun.

off the top of my head,

[1,3,7].collect { |x| x + 1}

would be written in python as:

[x + 1 for x in [1,3,7]]

(which i personally find much more readable) and

[3,4,12,76,2].find { |x| x > 4 and x.modulo(2) == 0 }

would be written in python as:

[x for x in [3,4,12,76,2] if x > 4 and (x % 2) == 0][0]

and the find_all version just wouldn't have '[0]' at the end.

and the weird sort would be something like:

[3,4,2,6,7,8,1,12,5].sort(lambda x,y: ((x >= 5 and y >= 5) and cmp(y,x)) or (cmp(x,y)))

except that python's sort is in-place, so you'd really want to have that list in a variable if you intended to do anything with the results:

l = [3,4,...]
l.sort(lambda:...)

most python programmers would shun that use of lambda though and do things in a slightly longer but more obvious fashion.

Re:Python Version of RoR

[arkanes]

On the other hand, I actually prefer explicitly creating functions for everything rather than using lamdas or anonymous blocks all over the place. It makes refactoring easier, and the explicitness aids my comprehension of the code. Different strokes for different folks, I suppose.

Re:Python Version of RoR

[namekuseijin]

So, as we all can see:

Python programmers like procedures and procedure declarations;
Ruby programmers like functions and anonymous function calls;

and both languages and styles have their pros and cons and are Turing-equivalent.

boy, that was boring...

Re:Python Version of RoR

[swimmar132]

You don't have to use anonymous blocks.

What is this?

[Lovesquid]

Hmmm... nowhere in the summary does it tell what "Ruby on Rails" is, or why I should care about it, and with the server getting hammered, I can't RTFA to find out. How about including a 1-sentence summary of what the topic of any story IS before posting it, for those of us who don't already know everything there is to know about everything.

Re:What is this?

[Otter]

I must have gotten in just ahead of the mob...to quote from Part I:

Ruby on Rails, the super productive new way to develop web applications

OK, that's helpful. Continuing...

Ruby is a pure object-oriented programming language with a super clean syntax that makes programming elegant and fun...

Rails is a open source Ruby framework for developing database-backed web applications. What's special about that? There are dozens of frameworks out there and most of them have been around much longer than Rails. Why should you care about yet another framework?

What would you think if I told you that you could develop a web application at least ten times faster with Rails than you could with a typical Java framework? You can--without making any sacrifices in the quality of your application! How is this possible?

Part of the answer is in the Ruby programming language. Many things that are very simple to do in Ruby are not even possible in most other languages. Rails takes full advantage of this. The rest of the answer is in two of Rail's guiding principles: less software and convention over configuration.

Less software means you write fewer lines of code to implement your application. Keeping your code small means faster development and fewer bugs, which makes your code easier to understand, maintain, and enhance. Very shortly, you will see how Rails cuts your code burden.

Convention over configuration means an end to verbose XML configuration files--there aren't any in Rails! Instead of configuration files, a Rails application uses a few simple programming conventions that allow it to figure out everything through reflection and discovery. Your application code and your running database already contain everything that Rails needs to know!

Re:What is this?

[Metteyya]

You can always use Google. Ever heard of that tool? If not, check out Ruby on Rails Site.

Re:What is this?

[Cyberax]

It's a collection of Java Best Practices rewritten in a 'cool' geeky language. Nothing new....

Re:What is this?

[davestar]

Well, don't feel too bad. Even if you'd already read the previous article, you still wouldn't have a clue what this is:

"In Rolling with Ruby on Rails, I barely scratched the surface of what you can do with Ruby on Rails"

Re:What is this?

[iwan-nl]

I've never used Ruby myself, but judging from the text you quoted, RoR people seem to have a weak spot for superlatives and exclamation marks... Let's just hope their coding is more "super" than their writing.

Re:What is this?

[JamesOfTheDesert]

It's a collection of Java Best Practices rewritten in a 'cool' geeky language. Nothing new....

Quite true. For example, Java Best Practice #1 is to avoid using long, detailed XML files for configuration, and instead use the programming languge itself, which is dynamically loaded and interpreted when needed.

Another Java Best Practice is to let the framework write the tedious boilerplate code for you. For example, in Struts, you just run

% struts myAppName

and you're halfway done writing your Web application.

Here's one more Java Best Practice: Avoid expensive , complex application server software, and do rapid development using the Web server that is built into the standard library. Then deploy to the Web server of choice with no code changes or quirky vendor-specific API hacks.

Re:What is this?

[Saeed al-Sahaf]

Normally, "editors" would do something like this. Does Slashdot have "editors"?

Re:What is this?

[bobbinFrapples]

harsh

Re:What is this?

[Cyberax]

I advise you to read "Better, Faster, Lighter Java" by Bruce Tate for a list of current best practices.

Re:What is this?

[coldtone]

Halfway done?! You must be kidding!

Being a java web developer, and using struts to build 3 different applications I have to say that enough is enough.

Struts is a very simple web framework, which will do several things for you.
Dramatically increase the size of your app.
Limit the functionality of your app.
Makes the code hard to read and follow. Just about everything runs though the struts config file.

The only benefit I see with struts is that is provides some clean definitions for code. (A place for display, a place for validation, a place for the work to be done) And gives you some tags to help with internationalization. (Just help mind you, if you need to have a totally different layout for a different language then, well you're screwed.)

I would only use struts again if I was writing an application that was to be localized and translated, and was working on a large team. Otherwise a well written set of JSP's will get the job done faster and will be easier to read.

Re:What is this?

[tigeba]

Please correct me if this is a mis-characterization, but RoR replaces maintaining long detailed XML configuration files with maintaing long, detailed database specific sql files.

Using RoR, you create a table and let Ruby dynamically determine a bunch of information about relationships and data types and then you access various properties of this data. You are also forced to use RoR's Object model (You have to extend ActiveRecord, correct?)

Using something like Hibernate, you write an object, then do something do describe it (Java Annotations, XDoclet markup, tedious XML configuration file) and It can create the DDL/alter tables on the fly for you, and you are not forced to extend any object.

To me each approach seems to have merit, as well as inherent drawbacks.

Re:What is this?

[swimmar132]

RoR replaces maintaining long detailed XML configuration files with maintaing long, detailed database specific sql files.

No, RoR's models don't come from maintained SQL files. I believe it uses reflection to dynamically build the models.

Using RoR, you create a table and let Ruby dynamically determine a bunch of information about relationships and data types and then you access various properties of this data.

Yes.

You are also forced to use RoR's Object model (You have to extend ActiveRecord, correct?)

No. You can use the other components of Rails (ActionPack and the Web Service portion) without using ActiveRecord.

Using something like Hibernate, you write an object, then do something do describe it (Java Annotations, XDoclet markup, tedious XML configuration file) and It can create the DDL/alter tables on the fly for you, and you are not forced to extend any object.

That's probably true, I haven't worked with Hibernate. But with Rails, you make a change to the DB table, and the model instantly reflects that change.

Re:What is this?

[tigeba]

"No, RoR's models don't come from maintained SQL files. I believe it uses reflection to dynamically build the models."

I understand that RoR is not literally reading some sql file containing DDL. My point is merely that the database schema does not magically appear from nowhere. You as the developer have to create and maintain this DDL somehow. Most developers would probably maintain this as one or many sql files that they would blow into the database as needed.

No. You can use the other components of Rails (ActionPack and the Web Service portion) without using ActiveRecord."

Developing a database web application using RoR would be a bit pointless without the ActiveRecord portion now wouldnt it? I think I was fairly clear ly discussing the persistence portion of RoR.

Re:What is this?

[Enahs]

Wow! You don't have time to read the article, but you have time to post a bitchy whiny comment.

Amazing!

Re:What is this?

[arkanes]

My point is merely that the database schema does not magically appear from nowhere.

It is magically pulled from the database. Lots of existing OR mapping tools can do this, including Java ones, but lacking Ruby's dynamic nature it's done as an extra pre-compilation step. Rails can do it at runtime.

Re:What is this?

[tigeba]

Yes, but what magically puts it in the database? Nothing, the developer has to do this. Again the whole point is that this is not a zero configuration system, you are just offloading the configuration somewhere else.

Re:What is this?

[JamesOfTheDesert]

Yes, but what magically puts it in the database? Nothing, the developer has to do this. Again the whole point is that this is not a zero configuration system, you are just offloading the configuration somewhere else.

Yes, of course, and any claims that Rails eliminates config files are, um, over-statements.

But: Given that *no* tool magically pulls the database schema by psychic forces straight from one's brain, the next best thing is to use a library that at least encourages you to use the best tool for the job. I would prefer to define my database using either a nice admin tool, or SQL. Or code in Ruby and have the database layer created for me (as Og/Nitro does).

The goal in these kinds of tools is to decrease or eliminate the need for intermdiary formats. I'd rather define my database layer using either Ruby or SQL. Tools that require the use of some additional "binding" language introduce yet another layer of abstraction with little gain for the trouble (and yes, the current version of Rails still requires one to use YAML as a database config language).

If Struts or whatver comes after it let the user define system details using Java or Groovy it would be a big improvement.

Re:What is this?

[arkanes]

I may be overstating what Rails does, as I am not an expert in this, but i have worked with frameworks (and written a little half-assed one of my own) which pulls the *schema* information directly from the database, parses it, and uses that to create the mappings. The "configuration" is your database schema. The developer does nothing, unless they want to override the way the tool does the default OR mappings.

Re:What is this?

[cygnus]

actually, some Java OR frameworks *do* do stuff at runtime... it's called "bytecode enhancement." Hibernate uses this to allow for lazy loading, for example.

i guess the question is, does it make sense for your application to be continually figuring out what it's database schema is at runtime, when it usually changes so little once the app is developed. i can imagine for smaller projects with light loads and in RAD situations, this makes a lot of sense, because you're exchanging a little processing overhead for a lot of flexibility during development. but for large databases with lots of simultaneous users, where the database is never changed, or even was set in stone long before the app ever came along, using tools like Middlegen or XDoclet to do things like this at compile time makes a hell of a lot of sense.

Re:What is this?

[legirons]

"Hmmm... nowhere in the summary does it tell what "Ruby on Rails" is"

We already know. Sorry. We watched the first video, and have been using it ever since. Seriously, it's fairly well-known among developers.

"or why I should care about it"
You don't have to care about it. And Slashdot summaries probably won't help. The video however, probably will, so it's good that they linked to that.

Just my luck that at the moment I wanted to get RoR anyway for a project, I look on slashdot and see they've posted a story about it, with link to MPEG.

"How about including a 1-sentence summary of what the topic of any story IS"

Highlight any words you don't understand, right-click, and select "web search for selected text".

As with many other technology definitions, you could just type the phrase literally into wikipedia and expect a reasonably good answer.

Ruby is great

[boeserjavamann]

too bad there isn't the big fellowship right now (besides japan, where it is bigger than python, whatever that means ;) i think its the most clean and powerful oo-scriptings language available.

Any interesting projects?

[elh_inny]

Has anyone actually done some interesting stuff that now works in a productive environment?

Re:Any interesting projects?

[Nik13]

Last time when Pt1 of the the article came out, in the discussions on /. some sites were pointed out (seemed like decent sites too).

I've been meaning to get around to add RoR to my apache (XAMPP) setup to try it out. Most of what I do at work is ASP/ASP.Net and I've been looking for something else (not to fully replace them, but perhaps as a complement). I'm not big on php, but it has it's uses and followers (I use it on some small websities with cheap hosting). J2EE isn't my definition of fun (although it's robust and all).

From what I had seen, RoR seemed pretty promising (and it keeps getting better they say), but I'll have to dig deeper to see it's full power. The only problem I can see now is finding some decent hosting for that, preferably cheap (RoR *with postgresql* to make things worse).

Re:Any interesting projects?

[elmartinos]

Shure! Even though Ruby on Rails is really very young, there are a few commercial sites that use it already. Here are a few links:

• http://www.43things.com/ Nice amazon-like community thingy
• http://www.basecamphq.com/ Online project management sofware
• http://www.tadalist.com/ Todo-lists
• http://www.snowdevil.ca/ Snowboard stuff

Although, the first 3 links are somewhat related.

Re:Any interesting projects?

[mrmargolis]

Basecamp(http://www.basecamphq.com/): tens of thousands of users, designed by the creator of RoR 43Things(http://www.43things.com/): thousands of users, now working with Amazon.com TadaList(http://tadalist.com/): an online todo list app with thousands of users Snowdevil(http://www.snowdevil.ca/): an online store that is powered by rails. It was deployed very rapidly using rails. If you can get through to the onlamp article there is a more complete listing of real world RoR applications at the end.

Re:Any interesting projects?

[orion024]

From what I had seen, RoR seemed pretty promising (and it keeps getting better they say), but I'll have to dig deeper to see it's full power. The only problem I can see now is finding some decent hosting for that, preferably cheap (RoR *with postgresql* to make things worse).

Check out http://www.textdrive.com/

Sounds exciting...

[szlevente]

"A Rails web application can run under virtually any web server"
Now that really made me curious. Is that really true, tried, and tested? If so, we need another bunch of tutorials about how to use Rails under Tomcat, Apache, etc. There is no way this framework will replace existing Java frameworks, but using it for prototyping is promising.

Re:Sounds exciting...

[zimba-tm]

Some answers for those who are lazy

== ROR runs and was tested under :
Apache + CGI
Apache + FCGI
Apache + mod_ruby
Lighttpd + FCGI
WebRick (ruby server)

OS : Linux / Window / OSX / *BSD

== Real-life examples :
www.basecamphq.com
www.tadalist.com
www.43thi ngs.com
www.snowdevil.ca
www.bellybutton.de

Re:Sounds exciting...

[Nik13]

In this case, I guess "virtually any webserver" means either apache, lighttpd or WebRick. I couldn't find anything IIS related (not that I spent hours looking either).

DB wise, it supports MySQL, PostgreSQL, SQLite, MS SQL Server, IBM DB2 and Oracle.

Re:Sounds exciting...

[rubycodez]

No way this framework will replace existing java frameworks

There is actually a chance it may become a mainstream way of building an enterprise framework. There is a very cool new bytecode Ruby virtual machine and just-in-time compiler (YARV), and the next generation of Ruby, Ruby 2, will support native OS threading. Unlike Java, the source for Ruby is and will be completely open & transparent. Ruby can run on platforms where java can't, like BeOS and MS-DOS.

Re:Sounds exciting...

[geniusj]

Well.. BeOS and MS-DOS. That just seals Java's fate ;). Seriously though, I love Ruby.. The consistency it shows throughout the language is very refreshing. I can usually guess at syntax or method names if I don't already know them. We're on the same wavelength ;)

Re:Sounds exciting...

[drew]

yeah, 'cause BeOS and MS-DOS are crucial platforms to support when you're developing an enterprise framework.

Re:Sounds exciting...

[rubycodez]

it means in the past 7 years I've had to use java technology (from BEA, from Sun, from IBM, etc.) professionally for which the source wasn't available, and it's caused me headaches.

Rails and other Rails tutorials

[teidou]

To explain Ruby on Rails, I could say it is a highly integrated model-view-controller type web application framework. That would be like saying a Ferrari is a 4 wheeled internal combustion vehicle: true, but misses the point.

For more info, see RubyOnRails.com. An good alternative tutorial is at http://rails.homelinux.org/.

There are even better introductory materials coming. Dave Thomas (of Pragmatic Programmers) is working on a Rails book, chapters are being reviewed presently.

Rails is powerful an flexible. More importnatly, it's a lot of fun. If you are a programmer who want to enjoy web-based application development, please do take a look at Rails.

Re:Rails and other Rails tutorials

[pamri]

Another great resource is the Ruby on rails weblog which has links to more tutorials, job postings about rails, updates, etc., There's also an updated video tutorial on building a weblog.

Re:Rails and other Rails tutorials

[snorklewacker]

> To explain Ruby on Rails, I could say it is a highly integrated model-view-controller type web application framework.

Rails is not really MVC -- The Controller part at any rate, the bane of every struts programmer, is entirely invisible in Rails. I suppose not having to deal with it yourself doesn't make it go away ... but really, nearly ANY application can be broken down into MVC parts or otherwise viewed through some MVC lens. The term was never all that meaningful (it only made sense when the controller was implementing low-level stuff like device drivers in smalltalk), but it's almost wholly meaningless for modern web apps.

At any rate, you tend to define look and behavior in the same file in Rails, which makes it rather not MVC. It's there to make programmers productive, not create divisions between coders and web monkey designers. You could template if you wanted to, you just generally don't. It's rather a breath of fresh air, actually.

One thing has changed...

[WWWWolf]

When the part one was published, I had severe problems getting Rails to work in Debian. There was a lot of really odd tools that needed to be installed and all that. Rails web page had tons of Ruby packages that I was pretty sure I didn't need...

But one thing has changed since then: Rails is now in Debian unstable!

Re:One thing has changed...

[pamri]

Actually, rails/any ruby library/app/whatever is quite easy to install if it is available on ruby gems and you have installed ruby gems. ruby gems is sort of like apt for ruby. Once you install gems, to install rails, all you have to do is, gem install rails and gem uninstall rails to uninstall rails. Although you are unlikely to need it. :-D

Re:One thing has changed...

[Tobias Luetke]

Please don't make this sound like an rails or ruby issue. Debian really blew it on packaging ruby. Most of the system related problems which come up in #rubyonrails are related to debian linux installations.

How did they come up with the brilliant idea to split the standard library into 34 different packages? I just can't see how something moronic like this can even get started considering that a standard library is all about raising the status quo of the language by providing some shoulders to stand on so people can reach for higher goals.

Keep in mind that ruby has no dependencies at all. All dependencies are optional and the libraries using them (tk,x11, readline) fail gracefully with exceptions when the parts are not installed. Not so if the entire library is missing, this will cause a runtime exception with cryptic error message which rails will never be able to handle. Also ruby is tiny the entire package is 3mb!

I heard they are talking about improving the situation by adding a "virtual package" for ruby which contains all 34 seperate packages

Future in Debian terminology is traditionally not soon and thats a fix feeble fix considering all they need to do is to put all 3mb of ruby in one package

Anyways the point is fairly moot now since debian doesn't have ruby 1.8.2 anyways which is required for the latest rails

Luckily its easy to install ruby by hand. And I heard gentoo and freebsd install pretty easily too...

Re:One thing has changed...

[cortana]

$ cat /var/lib/apt/lists/ftp.uk.debian.org_debian_dists_ sarge_main_binary-i386_Packages | grep-dctrl -n --field=Package ruby --show=Size

Summing the output, yeilds 31806976 bytes or 30 MB.

$ aptitude show rails
Package: rails ...
Depends: ruby (> 1.8), ruby ( 0.10.7),
libyaml-ruby (> 1.8.2), rdoc (> 1.8.2), libtest-unit-ruby (> 1.8.2),
libdrb-ruby1.8, libsoap-ruby1.8, libxmlrpc-ruby (> 1.8)
Recommends: libwebrick-ruby1.8, irb (> 1.8)
Suggests: libapache-mod-ruby
Description: MVC ruby based framework geared for web application development ...

If you see a dependancy missing from that list, please file a bug.

Re:One thing has changed...

[agrippa_cash]

http://www.2sheds.ru/blog/2005/02/installing-ruby- on-rails-on-debian.php has a good tutorial which shows an alternate server for a acouple debs and from which you can just copy and paste the horrensously long atp-get command. Sadly, I get a 'permission denied' error chenever I try to run 'rails foo'. So maybe the tutorial wasn't that great after all.

Re:One thing has changed...

[TheMysteriousFuture]

Well how about, uhm, I dunno, fixing your permissions? either just sudo rails foo && chown -R me:me foo, or ensure you have permission to create a directory in the current directory.

Re:One thing has changed...

[agrippa_cash]

It sounds just crazy enough to work. (Actually the permission denied error was the first of many showstoppers for me.)

Re:One thing has changed...

[TheMysteriousFuture]

What are or were the others?

ROR rocks!

[Pfhreakaz0id]

As a guy who has written db-driven web apps in ASP, asp.net ( alittle), perl CGI, plain JSP/Servlet and j2ee app server with EJB's (both with and without a persistence framerwork/Object-relational bridge), I can tell you ROR is my favorite. I've only been using it for two weeks on a part-time project. It's ... beautiful. I can't think of any way to describe it. It. Just. Works.

And ruby is a really nice scripting language. You should check it out.

Re:ROR rocks!

[pepicek]

The best way to describe ruby and rails for me it's that you are writting programs for you to understand them, not for computer. It's really changing the way you think when you are programing. You have time to focus on bussiness problem rather than computer's. Even if you have Mac OSX and really love it :-).

Re:ROR rocks!

[Anonymous Coward]

Hi, I'd like to learn some new stuff. I've decided that Ruby is my new project. I'm coming from the point-of-view that I haven't really programmed at all in a long time (not since I took some classes in school, other than programming some excel macros in vba). Any suggestions where I should start with Ruby. Initially I've been taking the random approach; I've got Ruby (and Tcl) installed, and I'm just looking at tutorials and adding text boxes, and stuff like that. Any suggested easy first projects that really help someone learn Ruby? I want to find a project that will be (a) easy at start, but can grow more challenging, and (b) that I will find useful (I figure that'll keep me focused)... Any suggestions?

Thanks,
-dan

Re:ROR rocks!

[Pfhreakaz0id]

Dan: hmmm, I'd find an itch to scratch. You can start by install rails and go thru the "todo list" tutorial web site. That's what I did. Maybe that will fire some ideas. Want to write a blog? write your own little blog site. It would be pretty trivial to do in rails.... I dunno.

Agile Web Development With Rails

[Ridgelift]

Dave Thomas' new book "Agile Web Development With Rails" is due out in July. It's really, really good so far (I'm one of the lucky ones who is helping review it). My perspective is a person who knows very little about databases, web application development and no previous knowledge of Ruby, the language that Rails is built on.

One of the big problems with Ruby on Rails is that it is well documented, but a lot of it is API's and reference documentation. Dave's new book has an excellent tutorial which is the best thing I've seen written so far about RoR for newbies, and promises to go into the depth and detail similar to his Pickaxe book.

If you've previously looked at RoR and were disillusioned because you just weren't "getting it " or didn't want to slug through the technical documentation, I encourage you to keep an open mind and wait until Dave's book is released. I'm finally getting over the hump with RoR and I now see what all the fervour is about.

(Oh, don't ask me to post or send copies of his drafts, 'cause I ain't gonna!)

Re:Agile Web Development With Rails

[__Maad__]

One concern that I have about this is: How long has this book been in the works? Rails has gone through leaps and bounds and fairly huge changes( sometimes on a week-to-week basis) even in the few months I've been working with it. Will the book be up-to-date when it comes out?

Re:Agile Web Development With Rails

[Ridgelift]

One concern that I have about this is: How long has this book been in the works? Rails has gone through leaps and bounds and fairly huge changes( sometimes on a week-to-week basis) even in the few months I've been working with it. Will the book be up-to-date when it comes out?

It's current up to 0.10, the latest version. David Heinemeier Hansson, the author of Rails, is also on the review team and seems to be good friends with Dave Thomas. So I think it's fair to say the book will be faily up to date, but like all technical books on new products it will date quickly.

Re:Agile Web Development With Rails

[Ridgelift]

Am I the only one concerned that the reviewer for a book on web development using ruby admits he knows next to nothing about web development, databases, or ruby?
I'm one reviewer amongst 22. I would say all the rest of the reviewers are much further along than I am, including DHH who wrote Rails.

Dave Thomas is looking to write a book that will help people learn Rails. My big contribution other than grammatical and spelling errors is "Hey Dave, I don't understand this section you say is easy".

To me, it's smart to let the uninitiated in so he can see if he's reaching part of his target audience: the ignorant :-)

Re:Agile Web Development With Rails

[E_elven]

Yeah, gee, wonder why a tutorial would need to be read by an uninitiated person to ensure it actually teaches something. What a sham.

Re:Agile Web Development With Rails

[JamesOfTheDesert]

If you've previously looked at RoR and were disillusioned because you just weren't "getting it " or didn't want to slug through the technical documentation, I encourage you to keep an open mind and wait until Dave's book is released.

Ah; sounds like this is getting closer to Struts land: Great tool, but to really understand it you need to buy a book.

Or no?

Comparing RoR with Java solutions

[MarkWatson]

I have worked through the RoR tutorial and re-implemented a simple admin web app that I originally wrote for a customer using JSPs and Tomcat. I must say that what took me 4 hours to write using JSPs and JDBC took about 30 minutes using RoR.

A big advantage that Ruby and Python have over Java is that they are dynamic languages that makes it not too difficult to write a database wrapper class that dynamically looks at database/tables meta data and generates access methods on the fly. Java Tails (using XDoclet market tags) can't really compete.

I really love the full J2EE stack for developing large scalable web applications but I am now looking at alternatives for creating smaller systems much more quickly.

BTW, I really like RoR's templating scheme: much like JSPs in syntax (JSP non-XML syntax, that is) but do to Ruby's much terser notation for enumerating collections, the the templates tend to look a little cleaner.

For Python, I really like the light weight CherryPy web application framework. I plan on checking out Python Subway also when I have some time.

-Mark

Re:Comparing RoR with Java solutions

[dDrum]

There is a version of rails in java.
It's called Trails and it uses spring, hibernate and tapestry.

Site - http://trails.dev.java.net
Tutorial - https://trails.dev.java.net/tutorial/"
Trails in action - https://trails.dev.java.net/media/trails_withnarra tion.mov

It's still beta but you can try it.

Re:Comparing RoR with Java solutions

[jimm]

When you watch the "Trails in action" movie be aware that each time he does a redeploy, the ant task takes about 37 seconds. With Rails, it's about one second.

Re:Comparing RoR with Java solutions

[Paradox]

Compare the Trails video with any of the Rails videos. It's kind of sad really. The trails video does less than what the Rails video does, and it takes much longer, is more complex, and relies on an IDE. Bummer for Java.

I'm not sure that Java can be used to replicate Rails. It might be possible, but it would probably mean abandoning a lot of existing infrastructure. Ruby does a lot of very clever/strange things, like dynamically adding methods to classes based off database schemas. The best we've seen Java do thus far is do this kind of thing statically via code generation and hints garnered from the source file comments.

Trails is a neat idea and it does bring some great things to the table when it comes to Rapid Web Application Development, but it isn't fair (for Trails) to compare it to Rails... at least as of yet, anyways.

Re:Comparing RoR with Java solutions

[Tobias Luetke]

Please note that the movie pauses for the recompilation which happens after every change to the views and lasts 47seconds.
They also try to replace Rail's ActiveRecord with hibernate which actually generates the OR code before compiling and not during run time meaning recompilation for every database change.

Just to put trails into perspective.

Rails picks up all changes to files immediately as long as you are in the development environment.

Trails is just flattering itself with comparing itself to rails.

Or for Perl...

[stu42j]

There is Catalyst

Rails got me curious about Ruby

[MSBob]

The Rails is such a great showcase of Ruby it really got me interested in the langauge itself. In particular looking at their Object Relational mapping tool it's very impressive how easy it is express your mappings with very little effort. Have a look at this example and compare it to a typical set of java classes with Hibernate tags. Then in case of Hibernate you have the extra build steps with Ant to generate the hbm files and so on. Don't get me wrong I like Hibernate and use it every day but Hibernate must operate within Java's syntactic limitations. With Ruby there is so much more flexibility that helps Rails achieve much more simplicity and expresiveness.

Re:Rails got me curious about Ruby

[MSBob]

And that's still much too much legwork for most developers' tastes. I have worked with Hibernate for the past two years and know the library and the supporting tools inside out... and I still cringe every time I have to create this complicated setup just to have my OR working.

34 different packages

[metamatic]

Debian does the same thing to Perl, except there are substantially more than 34 packages. I'm not sure what the point is, as Perl has its own package management via the CPAN module. I wish Debian would let Perl do its own package management, like Gentoo does.

The entire Ruby system isn't 3MB, either, if you're calling those 34 packages the system. The log4r package alone is 1.1MB, libqt-ruby is another 1.3MB, and libxmlparser-ruby is 0.8MB.

And Debian does have Ruby 1.8.2, I run Debian unstable and I've been using 1.8.2 for a while now.

Re:34 different packages

[cpeterso]

And Debian does have Ruby 1.8.2, I run Debian unstable and I've been using 1.8.2 for a while now.

Try telling that to my web host. They (sanely) use Debian Stable on their servers. Debian Stable only includes Ruby 1.6.7. Why should they use Debian Unstable on production servers?

Re:34 different packages

[metamatic]

So that they can offer a more competitive selection of web applications, and attract more customers. Duh.

Of course, they may not realize that. Similarly, it seems to be tough to find a web host that offers ordinary people J2EE...

Re:34 different packages

[MostlyHarmless]

With Perl, at least, there's a good reason: Perl is required by the base system, and it is important to keep the base small. IIRC, the way they do it with Perl now is the way the parent was saying would happen soon (erm, eventually :-p) with Ruby: there is a minimal package for the base system, but if you install the package called "perl", it will install much more.

Personal Testimonial

[orion024]

A few years back I created a dynamic MySQL backed website in PHP. When I first started learning Ruby, I converted this site to Ruby (ala eRuby and mod_ruby). I easily cut my code in half, *plus* it became a whole lot easier to read (and I was a ruby-newbie!). I am now migrating the site to use Rails, which, from what I can tell so far, is cutting that code down in half *again*.

If Rails had been around when I first started the site, I would have saved hours upon hours of development time. Rails is an amazing framework. It's cut down my development time, and my code is easy to read. It's made web-development *fun* again.

Their most recent release (0.10) provided support for writing (and using!) web services. I've already written one and put it into production with a VisualStudio C# app. Great stuff.

This is an amazing technology

[badboy_tw2002]

I don't normally write cheerleading testimonials, but its also rare I find something this cool that I want to gush about it.

The first tutorial (I saw it right here on Slashdot!) got me curious about RoR. I went home and installed it that night. A couple weeks later (total of maybe 10 hours invested) I had completely converted my community website over to rails (from a servlets site), and am launching it fairly soon. The funny thing is, the actual code to drive this thing is really small. No boring, repetative database code, automatic validation, lots of helpful classes (authentication is downloading a new package and running a make script). Things in the tutorial make it look like you're limited to standard naming conventions, but I assure you that you can override everything if you've got an existing database that doesn't match the RoR naming scheme.

I've found the community very helpful. Hosting is a bit limited now, but I'm getting a textdrive.com account soon to get my new site up and running.

This is definately worth an install and the 20 minutes it takes to do the tutorial, check it out!

Re:This is an amazing technology

[ErikZ]

I've been curious about Ruby, and I'm probably going to try using RoR to fix up my PHP/MySQL site. So I've got a quick question:

How much did you know about OO before you started? I've never had to touch it before.

Mod Parent +1 Sarcastic

[MAdMaxOr]

Um...yeah

Ruby?

[mikehunt]

Anyone who wants to post reasons for why I need to learn yet another language?

Like why I need to learn another set of editor commands...?

Mike.

Re:Ruby?

[Paradox]

Because if you don't learn Ruby, you can't use Rails. Rails is so compelling, you'll learn Ruby just to use it. Then you'll realize how incredibly cool Ruby is as a language, and how incredibly productive it is at the same time. And in the long run, you'll be better off for it.

Yes, Ruby is that good. Rails is a very nice framework, and it does things that you couldn't do easily in other languages (and that includes Python).

As for editor commands, didn't you know only Emacs users get into heaven? ;)

Re:Ruby?

[mikehunt]

Oh shit...I'm I vi user. On all platforms. Like I say, life is much too short for yet another editor!

Ruby seems interesting, maybe once I've swallowed VB and Java, I'll get around to it.

Mike.

Re:Ruby?

[Paradox]

Ruby seems interesting, maybe once I've swallowed VB and Java, I'll get around to it.

It might be best not to learn Ruby first. If you were to learn it first, learning Java afterwords would be incredibly painful. Nothing makes you realize how bad Java is like learning Ruby.

VB isn't so bad, I guess, but I'd rather use Ruby and the FX toolkit for those kinds of simple script apps. But Ruby does have an amazign set of winapi bindings as part of the standard library. You might want to elevate it above VB.

Re:Ruby?

[mikehunt]

Hmm. I've done DOS and much earlier operating systems. Quit the PC world once Windows came along. Got into big UNIX systems.

It's interesting to watch how languages progress. I cut my teeth on BASIC at 13, progressed to assembler and ended up doing that for a job. I've programmed many different architectures over the years, including some that most people do not see. My only conclusion from my assembler days is that there are lots of different achitectures and instruction sets. Most processors are equally easy to program.

There again, I've also written huge transaction processing systems in C. Loads of crap in shell script. Now I can think C in my head.

Nobody has managed to convince me about 'object oriented' vs 'functional' programming. I've seen just as much shit code in every language.

Languages, methodologies, 'extreme programming'.

Just get the job done!

Mike.

Re:Ruby?

[Paradox]

Nobody has managed to convince me about 'object oriented' vs 'functional' programming. I've seen just as much shit code in every language.

One thing about Ruby, is that it is very pragmatic concering its feature set. It has very functional features but is still very OO.

Just get the job done!

Seriously man, you'd love Ruby. It's probably one of the most pragmatic languages I've ever used, and I've used most of them.

Re:Ruby?

[mikehunt]

Well, like I say, I'm more a functional fan. There again, I'm off on a 4 day Java course next week, so maybe it will spark my interest for OO languages.

Java's basic design is great, I've looked through it many times. What I have not seen is really cool stuff in Java that did not need a long, intimate association with the language.

But if Java fires me up, Ruby here I come!

Mike.

Re:Ruby?

[arkanes]

If you love functional programming, you will hate Java and love Ruby. On the other hand, if you love functional programming but have been doing it in C, you may already be beyond help ;).

Easy to install on a host that doesn't have it

[inventric]

My webhost (http://www.inventric.com/nicewebhost) didn't have it out of the box either. And many people think if their webhost doesn't have it they are out of luck.

I wrote a tutorial on getting Rails installed without having root access. The tutorial has some specific stuff for my webhost, but it might give you some ideas on getting it installed for yourself.

The tutorial is at: http://www.inventric.com/blog/2005/01/ruby-on-rail s.html

Frameworks closely tied to languages, WHY

[Tablizer]

Anyone who wants to post reasons for why I need to learn yet another language?

Indeed. Why can't somebody make a fairly language-neutral framework? Why are all the UI frameworks so tightly bound to specific languages and why do people accept that?

Things like data/field dictionaries, screen descriptions, UI widget attributes, and event handling frameworks don't need to be closely tied to specific languages because they are mostly declarative in nature, so why are they in practice?

It just does not seem very efficient to reinvent the wheel for each and every language. There about 100 languages in popular use. If we reinvent a web/ui/gui framework for each and every one, then we have spent 100 times the effort than need be. (Well, adaptors and sharing for similar langs may make it more like 50.) It would seem wiser to make one standard and do that one really well instead of do it 50 times poorly for each lang. We managed to divorce database usage from being language-specific. Time for UI also.

Re:Frameworks closely tied to languages, WHY

[mikehunt]

I'd rather like to reverse your analogy:

It is not a good idea to reinvent a language for each new wheel.

I guess it's only old farts like me that remember when the functionality was the issue instead of the language that you should implement the functionality with.

Mike.

Re:Frameworks closely tied to languages, WHY

[swimmar132]

There are certain features in Ruby that make it exceptionally easy to implement something like Rails. Reflection, blocks, etc.

Re:Frameworks closely tied to languages, WHY

[Tablizer]

There are certain features in Ruby that make it exceptionally easy to implement something like Rails. Reflection, blocks, etc.

It appears to me that they often just don't like SQL, reinventing joins etc., not necessarily that it is objectively better than direct SQL. (I think SQL has flaws too, but still not worth reinventing collection-oriented idioms to escape them.)

If have had long debates with FP proponents who suggest that closures and HOF greatly simplify code, but have yet to see direct evidence in my domain other than some who don't know how to use non-FP tools well.

How about we not get into another language war today.

Re:Frameworks closely tied to languages, WHY

[matvei]

We managed to divorce database usage from being language-specific. Time for UI also.

That should be "Time for web application development also". You can write GUI apps with almost any popular language (c++, python, perl, ruby) using any of the popular widget sets (wxwidgets, gtk+, qt). For example, take a look at the impressive list of GTK+'s language bindings.

Sure you can't mix and match bits and pieces written in different languages very easily, but it's possible. And it most certainly is not like you need to reinvent the GUI library for every language.

I too wish we could say the same about developing web applications.. Just thinking about coding anything more complex than an online recipe database in PHP makes me shudder :-P

Re:Frameworks closely tied to languages, WHY

[Tablizer]

I agree. The pre-web client/server tools made UI's a lot easier and flexible than HTML+JS+DOM. It is as if we took a step backward. I have been kicking around HTTP-friendly GUI approaches, and the hard part is defining what the server and what the client takes care of.

Re:Frameworks closely tied to languages, WHY

[arkanes]

Hi top!

In brief order: All widely used UI frameworks with the exception of the Windows API support declarative mechanisms, Windows to do so in the still-vaporware longhorn, all of them including Windows have bindings in enormous varieties of languages.

We never divorced database usage from being language-specific - it's done exactly the same way GUI is, with language-specific wrappers, often over other generic wrappers. There's a common query language which is sadly not all that common after all.

The "best" way to write web applications is still up in the air and being explored, Rails is one of those explorations.

well..

[Run4yourlives]

You could make the same comparision between perl and assembler if you wanted to.

Point being your point is not very strong.

Caveat

[Paradox]

Yeah, it does run under most basic webservers. Not too long ago, Rails needed apache's mod_rewrite to get the pretty URLs. But the addition of Rails Routes fixed that mostly.

Your web server can run Rails if it does the following:

1. Can invoke CGI somehow (duh)
2. Can forward URLs like http://somesite/somename/blah/blah/blah to http://somesite/somename/dispatch.cgi?/blah/blah/b lah

This is an awful lot of them, and Ruby runs on just about every platform used for web serving, so yeah. Rails could work most anywhere.

If you can't do the URL forwarding, Rails still works. The URLS are just ugly as sin and you lose some nice URL autogeneration features in the API.

Shortcomings of Rails

[sean23007]

I considered using Ruby on Rails for a large project I was doing, and found that though it was extremely easy to get started and do simple applications, it fails on more complicated databases. It does everything for you automatically, and you can easily write functions in Ruby that do the work of the database, but this is best only when the database isn't doing a whole lot itself except for holding data.

My database is in PostgreSQL, and uses a lot of dynamically named tables and schemas, as well as many trigger functions written in pl/pgsql. In order to get RoR to work, I found that I was going to have to edit the framework itself extensively, and would still be hampered by the slowness of Rails, which I found to be unforgivable.

I ended up having to design my own framework in Python, which can handle the most complicated databases without any more trouble than the simplest. The construction of the pages now takes a little more time than it did in Rails, but pages that used to take over a second to load are now instantaneous.

That said, I translated a small web app from Rails to my own framework, and the translation took less time than it did to write it in Rails in the first place and ran a lot faster, but that's because the design was done in Rails. I'd say that Rails is really good for prototyping small applications and getting them working really quickly, and then translating them to another framework for production becomes quite simple.

For non-trivial web applications, Rails has the problem of being optimized for ease of use, not for complete control. Note that I'm not trolling, or saying Rails has no use. Just that I found that it wasn't sufficiently capable for what I was trying to do with it.

Re:Shortcomings of Rails

[swimmar132]

The part of Rails that deals with the database and does the ORM is called ActiveRecord. You don't have to use AR with the other components of Rails.

Also, AR has gone through some extensive changes in the last release, it may better suit your purposes now.

Keep in mind that it's still a fairly new framework. It will only get better!

Re:Shortcomings of Rails

[sean23007]

I don't mean to say that Rails has no uses. It definitely seemed to be wonderful for a certain subset of applications. However, the amount of work it would have taken to rewrite ActiveRecord such that it would be compatible with my database was roughly equivalent to the amount of work it would take to completely implement my own solution. I simply decided to do the latter. Perhaps I should have written an AR replacement that would have been enough for my database, because that certainly would have advanced Rails greatly. If someone else does that, my biggest complaint about Rails simply disappears.

Bear in mind, however, that it feels really good to implement an entire framework yourself. While developing my application, I feel like DHH must have while he was writing Basecamp. It's a great feeling.

Re:Shortcomings of Rails

[bunco]

May I ask what packages you used for your python framework? I've been toying w/ CherryPy for awhile now. Me likes.

Re:Shortcomings of Rails

[sean23007]

I haven't looked at CherryPy at all, really, and the only packages I'm using but didn't write are cgi (comes with Python) and psycopg (for interaction with PGSQL). I wrote my own db class which creates objects that map to a table, with a dict variable where the keys are field names in the table and the values are the values of the corresponding field. I've written classes for each high level type of data, and am in the process of finalizing my sessions class. I doubt I'll be able to open the code, for business reasons, which is unfortunate. I'll be selling the entire codebase to a company which will in turn sell services based on the accompanying application (which the framework is designed from the ground up to serve perfectly).

Re:Shortcomings of Rails

[pico303]

"dynamically named tables and schemas!?!"

You have got to be kidding me...you're naming database tables and schemas on the fly, from your application?

My DBA just threw up.

Re:Shortcomings of Rails

[sean23007]

Yes, most of the data in the database is held in tables that are dynamically created based on the data entered into the database. This kind of architecture was basically required for the size and speed requirements we were under during the design phase. And before you demonstrate your lack of knowledge on the subject, not only is the database design rated Type 3 Normal, it's been lauded by many people responsible for the design and implementation of the largest databases used in hospitals and other mission-critical fields across the country.

Your DBA just realized he should read the Postgres manual a few more times.

Re:Shortcomings of Rails

[arkanes]

I'm going to sound like someone I know and really dislike here, but...

If you're regularly dynamically creating and nameing tables, that sounds like you're abusing SQL to create trees and other arbitrarily nested hierarchies. Assuming Oracle and it's tree extensions isn't an option, maybe you should reconsider using an RDBMS for a tree-based back end? Or maybe you're doing something totally different, in which case just ignore me.

Re:Shortcomings of Rails

[sean23007]

Basically Oracle isn't an option because we're trying to maximize cost-effectiveness, and thus are sticking with free, open source solutions. We chose Postgresql as the backend, and in a production setting it is competitive with Oracle, in features, stability, and speed. We used pl/pgsql to create the functions and triggers which create the tables. pl/pgsql is a clone of an Oracle language, and can basically be used in Oracle databases to achieve the same functionality.

The design of the database drew high praise from the inhabitants of the Postgres listhost, and it was their advice that led me to the decision to write my own framework to handle it. The information we got from them says that only the most advanced databases out there are using these techniques this extensively (yet), and most frontends that they've heard of can't handle it.

Performance-wise, the thing absolutely flies.

Re:Shortcomings of Rails

[pico303]

I've read the PostgreSQL manual, and I don't remember them every encouraging me to create tables in the manner in which you suggest.

I'm no DBA, so I've never heard of a "Type 3 Normal" design. Neither has Google, so if you could point me at a reference online, I'd be interested in checking it out. Granted, I have no details on what your project goals are, or who your target customer is. Most importantly, I have no idea what the size of your database is or the user load on the application.

That said, given that your choices were between Ruby and Python, I can't imagine that it's a massively scaled application, with database replication, server session replication, graceful failover, etc., etc. If you're willing to put your money where your mouth is, maybe you'll let us all know (a) your application, and (b) what person or persons "responsible for the design and implementation of the largest databases used in hospitals and other mission-critical fields across the country" like this design? I'd ask them if they'd ever take their huge Oracle databases and perform dynamic table or schema generation on the fly.

Whenever anyone has come to me wanting to dynamically generate tables and schema, it's typically either been bad design, or trying to apply non-relational data storage requirements to a relational database. Everybody knows you're supposed to save all your data in a relational database, right? Doesn't matter what the format... I fight this battle with management all the time. Everybody and their brother has heard of Oracle, but sometimes just a plain text file does the job nicely.

As an aside, I'm curious how you would generate reporting against your database? I'm guessing you just do a general search against user-supplied fields or something. How ever would you optimize those queries against indexes? Either they are very small tables, or your code must be doing most of the work a standard RDBMS would be doing, calculating possible SELECTs and generating indexes on the fly by interpolating user intent. Again, not knowing the details of your application, this is just a guess. Would definitely pose an interesting problem.

Now, having said all this, if you're just generating tables based on a well-defined set of configuration information entered by the user at installation time, well, that's a different story. I could see how that would be a problem for Rails without being bad database design.

My DBA is an Oracle DBA. Unless you've managed to cluster several hundred PostgreSQL servers, I'd say my DBA can beat up your DBA.

Re:Shortcomings of Rails

[ErikZ]

Considering how many eyebrows you're raising, maybe it would be a good idea to write up an article on it?

Unless you enjoy having to explain yourself over and over. :)

Re:Shortcomings of Rails

[TheMysteriousFuture]

As the sibling post mentioned, I'd love to see an article on what you've done. Maybe you could even get O'Reilly's onlamp site to publish it. Or just throw it up somewhere :).

Re:Shortcomings of Rails

[mabinogi]

try looking for "Third Normal Form" or database normalisation instead, though that in itself has little to do with the dynamic table creation situation.

There are some types of applications in which you cannot know at the time of writing the application what data is needed to be stored beyond a few common fields - say you're creating an inventory system and you need to be able to have it expand to contain information about new products and can't know in advance what special information you might need beyound the common stuff for those products.

In that case you've got three options -
1. create a table with the common fields and a fixed number of extra fields - extrainfo1, extrainfo2, extrainfo3...extrainfon
2. use a generic database format where you create one table with the common fields and another that effective contains name value pairs and a foreign key reference back to the main table
3. Create a separate table for each product type on the fly when the product is initialiy defined in your system, and use a product type to table name / definition mapping to locate which table to use.

Each of those approaches is perfectly valid for certain jobs and each has its own set of advantages and disadvantages.

1 allows you to avoid dynamic SQL and the complexity of extra joins but is the most limited in flexibility - you're stuck with the data definition you used at the time of writing and if a product type has more extra information than you allowed for or information of differing types or lengths then you're out of luck.

2 is more flexible as it allows any number of extra fields for a product but it adds complexity to your queries (although that can be aleviated with a view - but if you know enough about your data to create a view then you know enough not to require this approach in the first place) it is also harder to enforce data integrity and still suffers from the problem of differing data types and lengths. There are also potential performance problems due to causing the creation of a table with a potentially huge number of records (number of products * average number of extra information records) However, I'm not sure how much of a difference that makes in practice. Effective indexing is also more troublesome, as you either have to index everything or nothing.

3 is more complicated than 1 but simpler to write queries against than 2. It requires dynamic SQL but allows the enforcement of data integrity constraints, it allows you to use the appropriate data type for each field rather than storing everything as a varchar and lets you choose the right lengths and precisions for text and numeric fields. You also have the flexibility to choose how you index the table on a per field basis - exactly as if you'd hard coded the definition in advance.

Of the three of them I think that 2 would be the most likely to make a DBA throw up.

Re:Shortcomings of Rails

[sean23007]

A simple question! Pressed for time at the moment, I'll answer this one. I wrote my framework in Python because I'm much more fluent in Python than in Ruby. If I were as good with Ruby as I am with Python, I might have updated ActiveRecord to work with my database, or considered some other Ruby-based solution. As it is, Python is my language of choice.

Rails has a very clear MVC separation.

[Paradox]

At any rate, you tend to define look and behavior in the same file in Rails,

Excuse me? Uhh, the look is defined by the templates, and the controllers just do the setup and actions. Rails has a very clear separation of view and controller.

You define look in the templates and behavior in the controller. Sometimes, the behavior is just loading a group of database items into a class variable for display. Sometimes, it's more complex, involving things like redirection and database manipulation.

But you'd be hard pressed to say the separation isn't there at all.

MOD PARENT UP!

[badboy_tw2002]

Wow, really cool stuff! I think I'm going to try that tonight, I might not have to switch web hosts after all! MOD PARENT UP!

What I really want...

[fm6]

... is a version of the tutorial that's not on PDF. Since the tutorial was authored on OpenOffice, it would have been just as easy to provide a web version.

And how about a good tutorial on Ruby itself? Most of us have no idea what this language is about.

'Rails'?

[Ed Avis]

Ruby on Rails - is this somehow related to The Little Engine That Could?

Re:No, you can't make that comparison at all.

[Run4yourlives]

Before you want to call me retarded, have the guts to put your name behind your words, otherwise shut-up.

Perl and ruby are very similar, if you know one you can easily pick up the other.

No, they're actually not similar at all, and if you were familiar with ruby you would have a bit of a clue regarding this. It's closer to smalltalk than Perl, really.

Re:Stored procedures?

[Pfhreakaz0id]

stored procedures... um, I know you can implement custom "sql finders" for a class. I don't see why that couldn't work, but you'd lose a lot of the great stuff that way.

Rails outside of Ruby? How about Aesthetics...

[DoctoRoR]

The way you answer reflects a rigid top-down mindset. After reading some of Paul Graham's essays, I began to question that way of thinking and asked myself if Rails could be built easily outside of Ruby, or alternatively, whether the types of problems that Rails addresses are more efficiently handled by your top-down list of components. Rails is more than a UI framework; it's being grown from the language up towards web app solutions. If you read some of Graham's essays in the light of Ruby on Rails, you might reconsider.

Graham suggests new languages may be trending towards LISP, perhaps because LISP was initially a theoretical exercise by McCarthy, a gedankenexperiment not really designed to be shoehorned into 1958 computational constraints, but rather discovered "when you try to axiomatize computation." (See Graham's full postscript paper The Roots of Lisp .) FORTRAN and C, on the other hand, took a lot of cues from the hardware; they had to be fast. Over time, the lower-level languages have been relegated to handle algorithmically-simple, computationally-needy problems, while the scripting languages - PERL, PHP, Python, Ruby - have been getting fast and moving from simple glue to more complex processing tasks.

Two decades have passed since I looked at LISP code, and I'm wondering if I like Ruby because it's as powerful as that language in my distant memory, yet more aesthetically pleasing syntax-wise since I'd been coding in C, C++, and PHP. It's refreshing to be using a true object-oriented (message-based) language that has strong (as in "walks like a duck") typing, closures, and seemingly dynamic everything (types, open classes). Although I'm relatively new to Ruby and Rails, I can see this is a language I'm going to enjoy using and figuring out.

Graham talks about bottom-up design , changing the language to suit the problem. It suggests one reason why Rails looks so good compared to other web frameworks: Rails looks like souped-up Ruby and not just a bunch of classes, procedure calls, and bolted-on code.

"In Lisp, you don't just write your program down toward the language, you also build the language up toward your program," Graham wrote. "Language and program evolve together... In the end your program will look as if the language had been designed for it. And when language and program fit one another well, you end up with code which is clear, small, and efficient." That's a pretty good description from 1993 on Rails development and points to a not-so-subtle difference between the web frameworks.

Just as standard Ruby lets you use "attr_writer :some_attribute", Rails provides a formalism for defining data relationships like "has_many :data_thing". The Ruby Way seems to run deep. It'll be interesting to see if Rails manages to adhere to that philosophy as it expands.

When answering the question "Could Rails be built without Ruby?", I think you have to address not only the functionality but the aesthetics as well. It's more than the simple lines-of-code metric. It's whether you've built a language up towards a Rails language that solves problems common in web development. As Graham points out, you could build Rails out of any language that's Turing-equivalent; the real question is in your quest to duplicate the aesthetics, whether you'd wind up doing a back-door implementation of a Ruby interpreter in the process. For Python users, the port might not be incredibly difficult. For C users, it might be easier to build a Ruby interpreter.

One of the knocks against Zope 2, a leading Python app and backend server framework, was how un-Pythonic the framework appeared to some developers