Slashdot Log In
Ruby on Rails 1.0 Released
Posted by
ScuttleMonkey
on Tue Dec 13, 2005 10:16 PM
from the web-deployment-made-easy dept.
from the web-deployment-made-easy dept.
Simon (S2) writes "Ruby on Rails 1.0 has been released. From the announcement: 'Rails 1.0 is mostly about making all the work we've been doing solid. So it's not packed with new features over 0.14.x, but has spit, polish, and long nights applied to iron out kinks and ensure that it
works mostly right, most of the time, for most of the people.' " The Ruby on Rails website has also been given a new look.
Related Stories
[+]
Apple Publishes Ruby On Rails Tutorial 228 comments
bonch writes "Apple has noticed the high amount of Mac usage in the Ruby on Rails community and has posted an illustrated Ruby on Rails tutorial. The document goes into more concise detail in getting new users up to speed, from database schema to moving beyond scaffolding, all done with the favored Rails editor, Textmate."
[+]
Exploring Active Record 266 comments
An anonymous reader writes "Everyone knows that no programming language is a perfect fit for every job. This article launches a 'new series by Bruce Tate that looks at ways other languages solve major problems and what those solutions mean to Java developers. He first explores Active Record, the persistence engine behind Ruby on Rails.'"
[+]
Technology: Ruby On Rails Goes 1.1 255 comments
MrByte420 writes "The Ruby On Rails team today released version 1.1 of the web framework. From the announcement: 'Rails 1.1 boasts more than 500 fixes, tweaks, and features from more than 100 contributors. Most of the updates just make everyday life a little smoother, a little rounder, and a little more joyful.' New features were examined back in February at Scottraymond.net and include Javascript/AJAX integration, enhancements to active record, and enhanced testing suites. Not to mention upgrading this time promises to be a piece of cake."
This discussion has been archived.
No new comments can be posted.
The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
Commercial equivalent is...? (Score:4, Interesting)
Re:Commercial equivalent is...? (Score:5, Informative)
Parent
Re:Mod_python has easier syntax (Score:5, Informative)
Where did you get this impression? Maybe because you saw some regular expressions in Ruby? Ruby syntax is much, much clearer than Perl.
Take a look here [rubyist.net]
Parent
It just works... mostly (Score:5, Interesting)
Er (Score:5, Interesting)
Re:Er (Score:5, Informative)
Parent
Watch this video (Score:5, Informative)
Parent
That is one sexy video. (Score:5, Informative)
About 5 years ago, if you wanted to make a blog, you'd sit down and design a database schema. You'd design a controller that would have certain actions. You'd write a bunch of templates that would have variable locations. You'd extend the controller to use these templates from the db to make views. You'd write pages which allowed editing of these values. You'd write code for sanity checking. You'd write unit tests. You'd do everything over again that you'd done before.
Slashcode, Scoop, you name it -- they were all written through the same ideas.
Ruby on Rails makes all the redundant parts go away. In the video (which I just watched, and finally gives me a compelling reason to learn and use Ruby), the person sits down and generates a basic controller for their blog. They then show that the basic templates generated will show text. It takes another 5 minutes to define a db called posts and generate a default action for it. The code is smart enough to just directly make the things like title and body editable widgets on the page. 5 minutes to have posted blogs!
Then the video takes 5 minutes to extend this by writing about 15 lines of code. This has a big effect: the listing of posts is abstracted out into a block that can be included in any page. The ordering is reversed. The title attribute is made a required field.
But what good is a blog without comments? In the final 5 minutes, the author quickly adds a comment table, generates a comment controller, says that posts own comments, sticks in 3 lines of code in the post view segment which do a foreach associated comment, display, and then adds a page to edit comments. They also (at the same time) show us the basics of the unit-testing framework you get "for free" (the basic test is return true, but he changed it to test if the comment post code worked with another 4 lines of code).
The entire thing took 15 minutes to write and had 58 lines of code. When the db schema changed, the code adapted -- the programmer did not have to rewrite the code. When the programmer wanted to change anything, the code would quickly bend itself to the task.
I dare say it's the sexiest thing I've seen yet. If they ever release a version 2 that allows for simple Javascript on the client for AJAX interfaces, there will be only 1 game in town for web development!
I'm not inexperienced in web design. I have written my own stuff to test ideas out, as well as participated in Scoop's development to a degree. Recently I've been playing with Drupal because all the basics are setup with it, and you can just extend it with modules. I can honestly say that while it took me an hour to setup Drupal (and another hour to get it completely to how I liked it) it a test config, I could probably replicate the base distribution plus the modules I use in Ruby on Rails within a day -- maybe 2, if I'm slow. It's that effective!
Parent
convention over configuration (Score:5, Interesting)
The MVC triad in Rails uses the ActiveRecord class for the model part. ActiveRecord is an ORM (Object Relational Mapping) class that follows a few clever rules about doing the mapping, so most of the time you don't have to repeat your mapping multiple times. If you have a "User" class, it knows to look for a table in the db called "users", and assumes the primary key is an integer named "id". A foreign key to an account record is assumed to be called "account_id". The creation time of a record is assumed to be a datetime named "created_at". All common elements have reasonable defaults, so when you are working on your app, you don't need to spend a lot of time mucking about with config files to specify stuff that is just so fracking obvious that it is a waste of your time to type it.
Rails is not all things to all programmers, but it has certainly hit the sweet spot for a huge class of web applications - database backed interactive sites. The Rails design is good for probably 90% of the sites that I use most.
As for coder jollies, well, it's been a while since I enjoyed programming. With Rails I've regained my enjoyment for programming enough that I'm considering doing that for the main part of my work again.
Parent
compatibility (Score:4, Interesting)
Commercial/Enterprise use? (Score:4, Interesting)
I have yet to personally see RoR in either situation and I don't know anyone who has - I'm not knocking RoR, just curious how it's actually being used.
Re:Commercial/Enterprise use? (Score:5, Informative)
http://www.rubyonrails.org/applications [rubyonrails.org]
Parent
New Look? (Score:5, Funny)
Would that be the "Service Unable: Damn You Slashdot" look?
Perl people, check out Catalyst (Score:5, Informative)
http://catalyst.perl.org/ [perl.org]
It's very nice so far, especially the controller portion. There's lots of addons and plugins for it, all of which are entirely optional. It's actually very open-ended and easy to extend.
I use the controller classes extensively, but write my own model, view, and support classes. Catalyst culture seems to encourage Class::DBI parentage as a base model class, but it's simple to roll your own (I hate CDBI, so I based mine on Ima::DBI instead). Your classes can work independently of Catalyst... it imposes no restrictions or inheritance constraints on you. Worth checking out.
Give ruby a quick try first (Score:5, Informative)
Also a great example of Ajaxy goodness, not to buzzword it too much. It's written by the affluent and creative why. Check out his neat-o blog too: http://redhanded.hobix.com/ [hobix.com]
-mix
Why rails annoys me... (Score:5, Interesting)
I freakin' can't stand using Rails. I remember getting very excited about it when I first discovered it. Watching apps being developed in 15 minutes. I read all the tutorials. I even bought the book from pragmatic programmer. I studied and wrote programs for 3 weeks. And I just could never get into it. On so many occasions I just felt cheated. It was all valid ruby code, but it just didn't seem in the spirit of ruby. My namespace was cluttered with a million methods. The names of which didn't seem logical and_reminded_me_of_php_function_names_rather_than
The biggest annoyance was automated code generation. It was almost pointless for me. If I made changes to the database, I either had to a) wipe the directory and start over reimplementing my changes. Or b) go through all the MVC code and find the references to the database. Well, this is what I have to do in most other web languages anyway! So what's the advantage? Scaffolding was great at this because it did everything dynamically. However, you can't reasonably keep the scaffolding because it's not meant to be your program. It's meant to be support around your program.
The experience seemed more like programming in php with a twist of mod_perl. All the reasons I wanted to get away from perl and php for web programming were back when I tried to write a large application. Rails just doesn't seem in the spirit of Ruby. It's not bad. Don't get me wrong. But it's not this revolutionary framework so many people would have you believe. Sure, it's great to show the 15 minute video. But I'd like to see the video of someone doing a large project in rails.
Re:Why rails annoys me... (Score:5, Interesting)
Parent
Web 2.0, Baby! (Score:5, Funny)
I'm guessing more pastels. And rounded corners.
Re:"mostly right"??? (Score:5, Insightful)
Parent
Re:"mostly right"??? (Score:5, Insightful)
Yeah, it's not great, but at least it's honest. Go on any developer site - MSDN, java.sun.com, whatever, and you'll see a nice long list of submitted bugs. Fact is, no software is perfect, so don't go crazy when they admit there might be uncaught bugs.
Parent
Re:"mostly right"??? (Score:4, Informative)
Parent
Re:"mostly right"??? (Score:4, Insightful)
Remember, Ruby is at the forefront of the agile development community. Many developments in unit testing, for instance, directly involve Ruby. Ruby developers are often the most experienced at effectively employing such development techniques.
And you know what? It shows. Ruby software is often of extremely high quality. It's not perfect, but there is much effort taken to ensure correctly-functioning code.
Parent
Jebus, has the poster or mod ever used rails?????? (Score:4, Insightful)
Parent
You speak of momentum. (Score:5, Insightful)
I've been around it for decades. I remember when Honeywell and Data General had "momentum". I'd be surprised if you've ever even seen a picture of their hardware.
A bit later there was CP/M. And Apple. Apple had much "momentum" in the 1980s, only to almost hit rock bottom. At least they've been able to pick themselves up again.
There was even talk this morning about Java losing its "momentum".
Ruby on Rails could very well overtake PHP quite quickly.
While some onus does rest on developers to develop quality code, that does not mean that the language and any implementations should not take steps to limit the ability of the programmer to write faulty code.
That holds especially true for languages that are used in hostile environments, such as the WWW. Considering that Web development is touted as PHP's strong point, one would think it would have excellent security. Of course, we know from experience that that is not the case.
Ruby won't necessarily make your code perfect. But Ruby, along with sound development techniques (unit testing, for example), will result in very secure applications. The use of PHP, on the other hand, is basically an invitation for security issues. It is not a well designed language, and it is not well implemented.
Parent
One word (Score:5, Insightful)
Next time there is a project to X, do a prototype of some of the functions in RoR, ostensibly so you can get it done in a couple of days and you can use it to figure out requirements. After playing with a couple of days, sit back and watch as the app dev group spends a month laying the keel for their "enterprise" class implementation. Continue to use your prototype to demonstrate new requirements (they always come up). If, after three or four months, the app dev group doesn't appear close to being able to deliever any business value, then one question that management should raise is what, exactly, is the property of "enterprise" that justifies the difference in effort between rails and whatever they're using. Then determine if it could indeed be put in the RoR prototype. If so, you're in. If not, you've contributed to requirements understanding and live to fight another day.
Parent