Slashdot Mirror
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."
http://subway.python-hosting.com
It's rough, but it's coming along.
Has anyone actually done some interesting stuff that now works in a productive environment?
"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.
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.
DO NOT DISTURB THE SE
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
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.
Your pizza just the way you ought to have it.
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.
GCHQ Quantum Insert installed. If only our tongues were made of glass, how much more careful we would be when we speak
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!
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.
Lack of eloquence does not denote lack of intelligence, though they often coincide.
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.
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.
Lack of eloquence does not denote lack of intelligence, though they often coincide.
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.
Democrats or Republicans. They are both taking us to the same place and they are not afraid of us anymore.