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.
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.
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.
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.
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.
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!
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
In the world of computers, canonical always means real, and virtual always means fake.
For instance, a canonical host name is the real name. A virtual host name is a fake name.
So if somethings runs on virtually any web server, that means canonically it does not run on every web server.
http://www.slash7.com/flashback/2005/01/oreilly_o
"What the hell is an aluminum falcon?"
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
http://www.bellybutton.de/
While I'm not one to cast doubt needlessly on new, different ideas, I must admit that while the Ruby on Rails tutorial was spectacularly simple and fast, the fact is that when I decided to move from toy to trying to implement it, I encountered a number of problems.
First, the database that I hooked this framework to was not empty originally. After hooking the framework to that db, the data disappeared...I should repeat that, my data disappeared without my explicit instruction to destroy the data!.
Second, getting this running on linux was problematic because the tutorial was strictly for Windows and thus missed a few bits about linux (not really the author's fault since he admitted that linux takes more work).
I should be honest and say that after I discovered that RoR was truncating my database every time I tried to use it (without notifying me of that fact), I ran away in horror. I now use Zope and won't go back to RoR.
This line from the tutorial says it all
"Hmmm. Now that's different. The MyTest part of the URL maps to the newly created controller. Now it seems that Rails tried to find an action named index in this controller but couldn't."
I've tried using it and it's rubbish.
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!)
Ruby on Rails Screencast
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
Yes. Considering they're exactly the same language, with just one of them being more popular. Oh wait. They're not. Troll.
There is Catalyst
If you want to do any testing, rails expects you to have the ability to drop and create databases. And all the development is mysql based, so if you actually try to do anything non-trivial using another database, you end up with it spewing errors instead of working.
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.
The point is ruby is just perl with a less logical, but easier to read syntax. There's nothing you can do in one that you can't do in the other.
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
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.
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!
And there were two main problems:
1. It didn't install without a lot of effort (it took me 3 weeks on and off to get it working)
2. After all that, It deleted all my data without telling me.
This may sound funny at frist, but I accidently set it up on a production system, so it turned out not to be so funny.
As a result I've gone back to the technologies used in the advertisment embedded in this story (Microsoft Visual studio.net) . Like the ad says: "Create high performance web applications, and watch your throughput go through the roof". Never a truer word spoken. And I doubt it'll wipe my production system clean of all it's data any time soon.
The irony.
Um...yeah
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.
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.
l s.html
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-rai
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.
Table-ized A.I.
You could make the same comparision between perl and assembler if you wanted to.
Point being your point is not very strong.
Your web server can run Rails if it does the following:
- Can invoke CGI somehow (duh)
- 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.
Slashdot. It's Not For Common Sense
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.
Lack of eloquence does not denote lack of intelligence, though they often coincide.
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.
Slashdot. It's Not For Common Sense
The Perl version is called Catalyst.
They have a very nice Introduction too.
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!
Blow it out your ass, Java wanker. Sun blew it.
And how about a good tutorial on Ruby itself? Most of us have no idea what this language is about.
RoR stuff I've seen is CRUD straight out of the tables. I generally use stored procedures...does RoR still buy you a lot if you work that way? (eg., suppose I wanted to re-implement Slashdot...the CRUD paradigm probably ain't sufficient)
Clearly some people like ruby and rails, and that's super for them. But to act as though it is universally the greatest thing ever is naive. I have tried rails. I was very excited about it. I was even willing to suffer with the hideous syntax of ruby because rails seemed so good.
Then I tried to do actual work in it. And I realized it seems great when you play around, but when it really comes down to it, its not very helpful. I was more productive in java than I am in rails, and rails wasn't even able to work with oracle properly. Add the wrong column type to a table, rails blows up and spews errors. Report the bug, and get ignored because nobody cares about oracle, this is mysql-land.
Although I hate java, I am still stuck using it because rails is simply broken, and nobody cares enough to fix it. The devlopers attitudes towards security ("its not our problem" and "we're not going to inconvenience people just for security") is even more reason to avoid rails. And of course, ruby is slow as hell, has issues with its fake threading implimentation blocking the entire process and requiring a restart of the app, and for those of us who like the clean, logical syntax of C style languages, its a horror to read.
Its about taking a nice language like smalltalk, and then ruining it with hidious perlisms so nobody in their right mind would want to use it. Apparently its also about using pretend threads instead of OS threads, so you can trade the performace, stability and scalability of OS threading, for the ability to run your pseudo threads on DOS. No, I am not making that up, I wish I was.
I am going to guess not, and you might want to see someone about your condition. I don't know why so many rails advocates think that hatred of java, without even understanding it, will somehow help rails. It won't, you can stop.
If you take the time to read again, you will notice I didn't say anything about java, I did mention that perl is nicer than ruby though. I didn't mention java because I don't use it. I did mention perl because I do use it. Odd isn't it?
And yes, Sun did blow it. Java is completely useless to me, so it doesn't even get to rate against other languages, it simply doesn't exist. Unless I can easily use a language on whatever platform I want, without EULAs and patching and several hours of bullshit, then I am not using it. Its especially stupid since java never had any reason to be so closed and platform dependant.
Perl and assembler are not similar in any substantial way. Perl and ruby are very similar, if you know one you can easily pick up the other. Perl and assembler have very little in common, and knowing one will do very little to help you use the other.
My point is just fine, however you are mildly retarded.
OK, I built a new ruby on rails app againt an existing MySql database and didn't see any truncation. *shrug*
Ruby on Rails - is this somehow related to The Little Engine That Could?
-- Ed Avis ed@membled.com
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