Slashdot Mirror
Apple Publishes Ruby On Rails Tutorial
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."
seems like a nice tutorial, even for non-os x users. I'll have to bookmark it on my site.
Jobs: Ruby is groovy man. It's got like, vibe. We had to get in on that.
.NET offers more flexibility with less development worries and higher performance...
.NET can accomplish all the same....
.NET does all this! Why won't anyone listen? You believe me right?
Gates: C# with
Jobs: Man! Talk about Squaresville! Ruby is hip man! It's a love machine. A child of the earth.
Torvalds: Ruby is based on perl, which is in turn based on bash scripting, which I like.
Jobs: You see man! Ruby is a free spirit. It grows in like, the sunshine. It doesn't obey your rules!
Gates: But it's just another paradigm.
Jobs: On Rails man! Rails!!! It's like hyperspeed into the cosmos. And that's why its fit for Apple's attention. Now if you'll excuse me, I have to go get some podcasts over rss, browse some blogs, do some yoga. You dig?
***Jobs walk's away clicking fingers rhythmicly***
Gates: But it's all just flash and hype. Nothing really new is going on!
Torvalds: Look man. I really just don't give a shit.
May the Maths Be with you!
...to delve into Ruby. I was kind of tired of trying other tutorials (mainly from the internet) as I fouind them incomplete and sincerely wanting. Thanks to slashdot for the link.
This month only though, flavor of the month. Next month they're doing AJAX.
Comment removed based on user account deletion
very annoying to users yet the darling of developers?
Only those developers who can't see that a tight coupling between your code and your database is not a good idea.
So my question is: if Apple thinks Ruby on Rails is such hot shit, why doesn't they just upgrade their version to 1.8.4 via Software Update?
Haven't really had an opportunity to look much at either Ruby or RoR, this tutorial looks interesting, anyone out that works with RoR got any opinions on the availability/quality of tools and how it lives on other OS platforms...say Linux or FreeBSD?
How does it stack up against Java for ease of development and/or performance/flexibility?
Actually, you can order the 'rough cuts' version of the book now and download additional content as the author writes it.
The authors of rails books need to stop writing tutorials and write some comprehensive documentation. Even the page is quite lacking.
:discard_year => true)
:discard_year so the whole exercise is quite fustrating when you do find the docs, but i can live with bugs that will be fixed)
For example, suppose you have a time field, not a date field, no year, just time. And you want to create that element in your webform.
If it were date, you'd use date_select, pass it the name of the object and the name of the field, and your done, you get a nice input box. Suppose you want the same thing for time, its still date select with a series of discard attributes, e.g.
date_select('meeting','starttime',
However, you as the person looking for the documentation for this are led on somewhat of a goose chase becuase your time input box information is not even close to what you'd expect (time_select perhaps?) and you should be looking under "date" for "time".
(Incidentally, Rails 1.0 has a bug where it seems to ignore
If religous zealots don't believe in Evolution, then why are they so worried about bird flu?
I, for one, welcome our new overlords on Ruby on Rails on Mac OS X (roromoxes?).
:D.
Especialy when I hope to be one of them
In what (will be) new in rails 1.1, you will find more interesting stuff about that beautiful framework and its future. Worth reading if you are flirting with RoR.
"In version 2 of my generic Ruby On Rails tutorial, I'll show you how to add some security to your site, so that not everyone can delete your todos/add expenses/edit your photos".
Nooo! You've got to get security right from the start! Start with minimal privilege and add only that that is required. Otherwise you'll end up with an unholy holey mess.
If your web-based framework lets you write something that lets you modify anything on the server without either logging in or explicitly telling the code its okay, then choose another framework ASAP.
Yes you can add-on security to RoR, but it'll always be an add-on...
The Apple Developer Connection doesn't supply any attribution for their articles, but this one was written by none other than Mike Clark, who along with Dave Thomas runs the always-sold-out Pragmatic Studio series of Ruby on Rails and Ajax training.
As noted on the Ruby on Rails weblog, the author is Mike Clark, who is fairly involved in the Rails community. He's not an Apple employee though. The ADC article just doesn't have his name on it, so it mistakenly seems like this tutorial came from within Apple.
ce n'est pas un Sig.
The tutorial is concise and clean - a must for folks like me that don't have tons of time... I appreciate the post to ./ about this... my son has been asking about Ruby, and neither he nor I have had time to do anything with it at this point.
I agree that the article should be attributed. It's important to give credit where credit is due. It's also interesting that the article mentions http://macromates.com/">TextMate. TextMate is a nice concept.
Simple tutorials like this are critical to the adoption of many technologies - but it would be nice to see better documentation about the everyday use of Ruby and ROR {nudge, nudge}.
To pre-empt nuclear (or as the prez sez: new-queue-lurr) return strikes, let me say this: Tools like Ruby can be a real treat. I love the use of many languages (Java, Smalltalk, ObjC, etc.), but other, more lightweight tools make things come together in a big way for lots of jobs - use the tool and/or environment that works best, and do your best to work your craft the best way you can. It isn't about platforms or languages - its about design, solving problems for the users, and maybe getting to make a living along the way.
A Passionate Independent Musician
How many web hosts offer Ruby? In fact, how many web hosts run OSX? I can see this working on your own computer, for things like their example in the tutorial, and maybe for an app within a corporation but on the web there doesn't seem to be a feasible application for it. There's more truth than you think in ObsessiveMathsFreak's funny post. ch424
I've recently started playing with RoR, and though my first choice platform for any programming project is usually Linux, I went with OS X instead.
Unlike Linux-Apache-Mysql-Php/Perl/Python which has the nice acronym LAMP. Linux-Apache-Mysql-Ruby has the rather unfortunate acronym LAMR (pronouced lamer).
I'll stick with developing RoR on OS X.
If you're interested in my lates RoR project, check out: OSWiki
Hey Ruby/Rails users...giving you a chance to evangelize. I've never used it, but to me, it almost seems like a framework designed to make quick demos, but every demo I have seen is completely lacking in any design or uniqueness.
So, my question is this: how easy is it if you want to have a more complex visual layout? What If I want a form to submit to an encrypted text file? What if I need to work this system into a very intricate design?
What I'm trying to get at is: does its simplicity w/r/t getting something quick and dirty together mean it's a pain in the ass when you want to do something very special with it? Or is it equally easy to completely customize and change?
gameDB
See also this screencast for a comparison of Ruby on Rails, Zope (Plone), TurboGears, and Django. Oh, and J2EE which fares ... rather poorly in my opinion.
Warning: the screencast is 36 minutes long!
This may be a dumb question but...
Everything I'm seeing about Ruby on Rails says it's great for making "Web Applications". I'm going to start designing a new dynamic website soon, and I was wondering about building it using RoR.
I just want to use CSS, and plug the whole thing into a database.
So are they just buzzwording me, or is RoR the wrong tool to use for something like this?
Democrats or Republicans. They are both taking us to the same place and they are not afraid of us anymore.
Comment removed based on user account deletion
I'm going gung ho into RoR. I've bought the book from the Pragmatic Studio. I've bought TextMate. But I continue to hit a dead end. And its not getting away from scaffolding. No it comes down to an admin interface. RoR needs one desperately. And now. Django has one built in. Every tutorial on Rails is basically a one table tutorial with an occasional lookup table thrown in. Please somebody point me to a comprehensive step by step tutorial that details the creation of an administrative side of a web application.
And I'm not impressed with Apple's tutorial. Why use the migration? I prefer to create my tables with good ol' SQL saved to a text file. Store it in the db subdirectory of your Rails app. Then import it into your favorite database (plug for PostgreSQL).
Hey, Guys! Get with the programm. Ruby on Rails is so last-season.
Django is where the musics at. And for good reasons too. It's more mature, easyer to use, faster in developement, less performance hungry, has a documentation that's up to date and has a grown up backend kit. It's only that they GPLd it last summer, that's why it hasn't gotten all the press yet.
And this is not to start a flamewar. Compare them both and you'll see what I mean.
The RoR and Django guys are good friends btw.
We suffer more in our imagination than in reality. - Seneca
no it is not.
... the majority of Apple users don't care about Ruby or Ruby on Rails, so there really isn't a reason for a Software Update upgrade that only .5 % (maybe less?) of their users want. For those that do care (such as myself) it's a relatively painless upgrade doing it yourself.
Two Minus Three Equals Negative Fun -Troy McClure
- no mass updates/deletes.
- no aggregation (count,max,min,sum)
- no dynamic queries
- restricted joins
I've heard they fixed it to some degree in EJB ver. 3.0, getting it close to the actual SQL expression power.
Do you know a persistence framework that doesn't expose SQL and yet gives you the power that SQL does?
I hope they've told this guy about this new article.
Scared of flying, pointy things snce 1979!
Great!
:) And yes, I am a programmer myself. But if I wanted to program in Ruby I'd probably have found a tutorial somewhere already.
However, I wish they'd spend some more time fixing important security holes in their OS rather than writing articles. We still don't have a patch for this Extremely Critical vulnerability http://secunia.com/advisories/18963. And it's been a week now.
I'd rather have a secure OS running on my powerbook than a tutorial on some programming language I've never heard of before
P.S.: This is not intended as a flame, just as a question where Apple's priorities lie.
It's not as if J2EE is the only way to do web application development with Java. Some times a Mack truck is needed, most of the time a pickup will do.
Lies about crimes
What can it do that PHP or Perl/Mason can't?
Well for one thing, they are designing it from the ground up to be safer than PHP. I actually do like PHP but damn, it's so easy to shoot yourself in the foot! I think I'm a good programmer. I constantly think about things like SQL injection. I read all the PHP documentation about the mail() function, but sure enough, I opened myself up to being a spam relay. I don't know if I was hit, but I had code out there that was vulnerable.
But I followed the docs!!
And now with Ruby-On-Rails being a killerapp for forward looking web designers
No - it is a killer app for getting mentions on Slashdot.
Having a development system with the relative lack of performance of Ruby, and the very close tie-in to the database and schema of Rails is more of a website killer than an killer app, I am afraid to report.
So, you think reinventing the wheel when it comes to GUI is a great idea? One database, one platform independent GUI - sounds perfect to me,
How does reinventing the GUI wheel come into it? If anything is providing yet another re-invented GUI it is Rails. And, having platform independent GUI but producing code that can be very fragile if you attempt to migrate between different database products (or even if someone else radically changes your schema) sounds plain nuts to me.
i'm kind of bummed that they didn't mention Locomotive, which really makes getting started with Rails very very easy. it seems like every Rails tutorial starts with "OK compile Ruby, install Gems, install Rails, install and configure MySQL, and 10 hours later, you can use this really simple framework!" when with Locomotive and SQLite3, you can basically just download one app, click two buttons, and start typing.
Just raise the taxes on crack.
No - it is a killer app for getting mentions on Slashdot. Having a development system with the relative lack of performance of Ruby, and the very close tie-in to the database and schema of Rails is more of a website killer than an killer app, I am afraid to report.
I'm with Decaff on this one. I drank the RoR kool-aid after one of the earlier posts to slashdot. The first few weeks was awesome. Then essentially what happened was I ended up trying to rip out every aspect of RoR until I was just left with Ruby... which had terrible performance.
If you're going to go with RoR, make sure you take the long view. While everyone says "it scales, because it has FastCGI", I'd really like to hear more about extreme high volume sites that are using it. How's it going for them?
I'm overwhelmed by your citation of sources and real-world examples proving your claim of Ruby's slowness!
"Sufferin' succotash."
But google uses python. Whats wrong? Python is dying because of its boring board of directors? Missed the train?
So, please elucidate.
What makes Ruby "lightweight" as compared to Smalltalk and ObjC?
I would argue that Smalltalk is "lighter" than Ruby.
Ratboy.
Just another "Cubible(sic) Joe" 2 17 3061
I used Locomotive when I was playing with RoR a few months back and it is amazingly simple. Locomotive is easy to install, run, and even easy to get rid of if necessary (just drag it to the trash like everything else).
Andrew
I'm overwhelmed by your citation of sources and real-world examples proving your claim of Ruby's slowness!
It is an interpreted language without even a native code translator (at least not one that is out of early beta).
If you would like to explain how that is supposed to be fast , I would be very interested..... Unless, of course, compiler writers have been wasting their time for the past 50 years.
Variety is the spice of life. We don't want to do everything in PHP or whatever 'framework' you propose to be the great end-all. We'd be bored.
Besides, Rails is not only very young, but it works fine, performance-wise, for 75% of the business sites that need database support. You wouldn't use it for Amazon.com, but it might work fine for Gary's Auto Repair's business site, which is the sort of thing most free-lance developers are doing in their spare time.
Oh, and don't be "afraid to report" your perfectly unsubstantiated opinions! It's a free internet-- just come out and say it!
I'm overwhelmed by your citation of sources and real-world examples proving your claim of Ruby's slowness!
Rails, not counting rendering or database query, takes anywhere from a few to several millseconds to respond to any web query on a modern Xeon processor.
I'm not sure I understand the argument of "real world examples" when it comes to performance. Either someone cares about performance or they don't. Over the span of the entire life of Rails, the argument has been "the database is the bottleneck anyway" and "well, it's not slow enough for my blog app!" Ok, so when is it slow enough? We live in a world where people still have to bust out ASM to get desired performance for some applications. For web applications, is performance so unimportant compared to development time that we're willing to make any sacrifice necessary? I don't agree with that sentiment, and neither does the developer of Ruby, who's working on a new, performance-oriented interpreter http://www.rubygarden.org/ruby?Rite
Besides, Rails is not only very young, but it works fine, performance-wise, for 75% of the business sites that need database support. You wouldn't use it for Amazon.com, but it might work fine for Gary's Auto Repair's business site, which is the sort of thing most free-lance developers are doing in their spare time.
I have heard this sort of false statement so often!
Sorry, but this kind of thing does not work fine for these sites. They may work find for these sort of sites most of the time, but what generally happens is that sooner or later the site will have a burst of high demand, or some additional functionality will be added which requires extra processing (transferring masses of updates to the site by a SOAP service, for example), and the either site collapses, or loses you friends when your site takes up all the CPU on a multi-site machine! Then what happens is the site is re-written and re-hosted in a faster, more established technology, and the expensed saved by using the cool new technology is lost.
I have seen this happen far too often, (but as I am paid to clean up the results, why should I complain?).
I don't understand why someone would want to use Ruby on Rails on Mac OS X, when WebObjects comes with the developer tools, is an enterprise-class Java app server, and is way faster in both development and deployment (on Mac, Windows, Unix, or Linux) than anything else I've seen.
It really is the best kept secret in the web app world. If you've not tried it, you might want to give it a shot.
I bow before your masterful buzzword-fu. You must have great hair. Will you teach me to leverage my competitive synergies?
You want the truthiness? You can't handle the truthiness!
I've seen you bring this up before, but I still don't really follow. Rail can infer model details if you don't provide them yourself because, most of the time, it's the reasonable thing to do. Why should I have to tell it that the PRODUCTS table backs the Product model, or that a VARCHAR field holds data from a String property? The relationship is obvious, and Rails saves me the hassle of mapping it myself. These are simply default values however, and there's absolutely nothing preventing me from overriding them. If you choose to map everything (using something called a migration), Rails can even generate the schema for you against a variety of different types of databases.
There are ORM layers that go further with their abstractions than Rails, but I think Rails goes far enough. Sure, you can't just pull out your database and replace it with LDAP with a simple configuration change but, in my experience at least, these sorts of requirements just don't come up very often, and the products that do support such things tend do so at the expense of something more important. All that abstraction doesn't count for much if I'm left high and dry when I have to do bulk update or sum(), or if I'm going to have to spend the rest of my life setting the thing up. And, partly because rails really tries to enforce proper MVC design, and partly because Ruby is just such a damn productive language, making major changes to the way models work wouldn't be very difficult in most cases anyway.
However, as much as I'd like to believe otherwise, I don't, in fact, know everything, and I'd be interested in hearing about your experiences. Have you had problems with Rails in this area? What was the situation?
Most of yahoo is written in PHP. Microsoft.com was, last I checked, uncomplied, pre .NET ASP. Google uses Python for most of it's applications. Slashdot uses Perl. Penny Arcade, A List Apart, 43Things, and all the 37 Signals sites use Ruby.
All of these sites receive 1000x more traffic than Gary's Auto Repair ever will, and yet they're holding up just fine, despite being written in relatively poorly performing languages. Language performance simply isn't much of a factor for the vast majority of web apps, where the bottleneck is almost always in the database.
Catalyst is the hot new Perl based Model-View-Controller framework. It's been out for about a year, it's production ready easy for any competent programmer to work with, and backed by massive collection of libraries on CPAN. It has a large friendly and active user community, which you can find via the website.
Me, I'm using it for lots of things - my project of the moment is gluing in some of the tasty AI modules on CPAN into it for automatic classification.
"...we should just trust our president in every decision that he makes and we should just support that." B.Spears 2003
Most of yahoo is written in PHP. Microsoft.com was, last I checked, uncomplied, pre .NET ASP. Google uses Python for most of it's applications. Slashdot uses Perl. Penny Arcade, A List Apart, 43Things, and all the 37 Signals sites use Ruby.
No, you are wrong. Most of Yahoo is not written in PHP, and Google does not use Python for most of its applications. They use these languages for some aspects of their sites, but increasingly pass of 'heavy lifting' to higher performance systems based on J2EE and C/C++.
Using a language does not mean that that a site only or primarily uses the language for everything. Major sites may have the time and resources to manage complex mixed-language development. Small developers don't.
All of these sites receive 1000x more traffic than Gary's Auto Repair ever will, and yet they're holding up just fine, despite being written in relatively poorly performing languages.
Factually incorrect. They use higher performance languages where necessary, and they have the money and resources to scale parts of the site by simply throwing more hardware at things. If you suggest to a small-scale customer that they can deal with occasional high demand by stringing together machines you will be shown the door pretty quickly - saying that a you are dealing with a 'cool new development system' is no excuse for inefficiency.
Language performance simply isn't much of a factor for the vast majority of web apps, where the bottleneck is almost always in the database.
Why not respond to the point made in a post? Have you actually tried handling a significant volume of XML in Ruby or Perl (and I mean in the language, not passing stuff off to a C library)? Have you tried doing something like image management (often a requirement of content managemenent sites) purely in these languages?
Sure, you can't just pull out your database and replace it with LDAP with a simple configuration change but, in my experience at least, these sorts of requirements just don't come up very often,
You would be surprised! Of course, the issue is that when they do come up, you are really at a loss with Rails. I consider portability a very valuable form of insurance.
Trying to track all uses of a table or column in a large project written in a dynamic language isn't always easy (I have never found it so).
and the products that do support such things tend do so at the expense of something more important. All that abstraction doesn't count for much if I'm left high and dry when I have to do bulk update or sum(), or if I'm going to have to spend the rest of my life setting the thing up.
I think you should take a look at some products like Kodo. They simply don't give you portability at the expense of anything else. With APIs like JDO 2.0 and EJB 3.0 I can do operations like sum() with a single line of portable query language just like with SQL. With a good product like Kodo I can easily do bulk updates with very high performance using ORM, with almost no additional work needed for tuning. It is very easy.
There is this common belief that you need to be close to the database for efficiency - efficiency is counter to portability. This is just not true anymore. My app handles millions of records and I can switch my it between PostgreSQL, Oracle or MySQL in seconds.
However, as much as I'd like to believe otherwise, I don't, in fact, know everything, and I'd be interested in hearing about your experiences. Have you had problems with Rails in this area? What was the situation?
Not specifically with Rails, but with similar approaches, over many years (since the 80s!). One of the most recent examples was a website that I was supporting that was developed years ago in an interpreted language - Cold Fusion. Not only was this website slow, but it included code that was highly specific to the underlying Microsoft database that was providing information for the site. Of course, eventually, under the load of increasing complexity and demand the site collapsed. It was then my task to re-code the entire thing for higher performance. At the time, I used JSPs as I could quickly port Cold Fusion pages to JSP. JSP gets translated to Java code, then compiled on demand so could provide much higher performance. The problem was made a lot worse because of the closeness of the code to the underlying database. We did not have a Microsoft host for the site, so it had to be ported to a non-MS datastore. I resolved never to tie a website to a specific database again, and I fixed this issue by using a Java standard ORM system - JDO. This meant I could deploy with trivial changes to PostgreSQL, MySQL even Oracle or a dozen others. The site has been up since and has dealt with hugely greater loads and demands (such as high-volume transactions to update the information).
Another recent example was when a colleague, against my advice, decided to use highly vendor-specific SQL to implement a website instead of a portable system - JDO or Hibernate. It turned out that all his development for a modern version of PostgreSQL under Windows was wasted because the hosting system was a rather older version of RedHat, and we did not have the option of installing newer versions of the database. The only practical database for use on that host was a somwehat out-of-date version of MySQL. Now, if he had used a portable ORM, this would have been a trivial matter. Instead it took weeks of work.
So, my experience that that portability can be a real problem, and even worse - you can't predict when it will be an issue!
Now I develop using a high-performance Java ORM - Kodo. This works fine both for simple tasks and very large batch operations. Even better, there is the option for automated clustering and cacheing as my website grows. There are nice open-source ORMs like JPOX and Hibernate that offer the same capabilities, if not quite the same performance.
If I read another Ruby article I think I'm gonna puke.
Of course the heavy lifting is done in a compiled language. In fact, that was pretty much my point. It's all about using the right tools for the job. If I was writing a database, I'd probably use C, but to use it for a standard web app would be the very definition of premature optimization in my eyes. Java fairs better than C here, but why hobble the productivity of my entire project by using static language for everything when only 1% of it is performance critical code?
Along similar lines, I have not tried complicated image or XML processing using pure Ruby, nor can I understand why anyone would want to. Ruby ships with a fast, native XML processor, and typing "gem install rmagick" is all it takes to get nice Ruby API for ImageMagick. The fact that these are native libraries is completely shielded from the developer, leaving the best of both worlds: Native performance, with Ruby productivity.
Most of these performance bottlenecks became solved problems a long time ago. When I interact with a Ruby On Rails application, I'm dealing with a native web server, a native database, native database drivers, native image processing code, probably a native XML parser, as well as the Ruby standard libraries, many of which are also written in C. At their core, most web apps do little more than move around data. Why not use a language that's well suited to this sort of task?
I've run the same non-trivial Rails app on three different database products (MySQL on the old Web host, PostgresQL on the new host, and SQLite locally) with minimal headaches -- just migrate the data, tweak a config-file setting, and It Just Works (tm).
"I call a baby goat a 'goatse.'" -- my non-Internet-savvy 6-year-old stepdaughter
Java fairs better than C here, but why hobble the productivity of my entire project by using static language for everything when only 1% of it is performance critical code?
Because it is a myth that it hobbles productivity, or at least a strongly debated point. The productivity issue of static vs dynamic languages has been a matter of strong debate for decades, with no side winning! This is an extremely complex matter.
At their core, most web apps do little more than move around data. Why not use a language that's well suited to this sort of task?
Because Ruby isn't suited to this for some types of data. And then you have to either rely on someone else's beta-level library for your commercial site or drop down to Java or C yourself. Then you have lost the supposed productivity benefits of using a simple language.
My first glance thru the tutorial saw mysql being run with the default root acct, no password :-( And last time I looked it was necessary to start mysql with a directive to listen localhost only, otherwise port 3306 is open to the world. Apple's (in)famous secure systems again...
Well, perhaps this is a case where it's best to agree to disagree. Your comments are all valid and well presented, but my experiences have pointed me in a different direction.
Moving between databases hasn't been a big problem for me. Somewhat ironically, the only major issue of this type that I've had to deal with recently involved going from MySQL to Oracle in a Hibernate project, but this was more Oracle's fault than Hibernate's. We did have to resort to a few native queries to work around it however.
That issue aside though, I've found that changing business requirements and aggressive project schedules are a far bigger problem for me than database interoperability. For me, the best insurance is an agile language that lets me quickly respond to change, and that lets me get to the heart of a problem without having to pile up gobs of scaffolding and configuration code. I have years more experience with Java than I do with Ruby, but I'm still 2 - 4x more productive using Rails than I am using Tapestry + Hibernate, and easily 10 - 20x more productive than I am when I'm forced to work on a Struts + JSP + JDBC project.
Part of this may be personal preference however. I enjoy programming in Ruby more, for reasons beyond productivity, and therefor am able to stay focused longer. Ruby just jives with me I suppose. I like the way it works -- it's very intuitive to me.
For some developers, I can see how Java could be the best choice. Rails has definitely won me over though.
I'd probably use C, but to use it for a standard web app would be the very definition of premature optimization in my eyes.
/.ed?
At what point is it not premature to optimize a website? Should we start optimizing when the hockey stick takes over, and our site goes down? Or when it gets
Just like any other programmer, web programmers need to design to performance requirements and optimize along the way. If the required performance requires using C, do that from the start. If you plan to deploy to a million people, why would you start by writing a website that only deploys to 500, then spend the next two years trying to dig yourself out of that hole? I'm sure the Orkut and Friendster developers have thoughts on how that's gone for them, or several thousand other web designers whose websites have died under load in the name of easier programming.
I'm not saying it's impossible meet high performance requirements with Ruby or Python. I'm just saying that it's insane not to design to some level of performance in a market where your server can get crushed overnight.
We did have to resort to a few native queries to work around it however.
The thing is, I have dealt with small projects that soon grew to substantial ones, with hundreds of thousands of lines, and hundreds of native queries!
For me, the best insurance is an agile language that lets me quickly respond to change, and that lets me get to the heart of a problem without having to pile up gobs of scaffolding and configuration code.
This is an area where Java is changing fast. The era of huge amounts of scaffolding and configuration is going.
To give an example - I don't use configuration at all: All the information about my schema is in my Java classes, with a few Annotations. I can generate my schema from the se classes with the click of a mouse, or via a single Ant task.
There are great new systems for Java like Seam, that allows both the web presentation and the schema to all be generated and controlled from just a few annotated classes!
The idea (often promoted by Rails supporters) that Java has to be swamped by configuration is way out of date.
Part of this may be personal preference however. I enjoy programming in Ruby more, for reasons beyond productivity, and therefor am able to stay focused longer. Ruby just jives with me I suppose. I like the way it works -- it's very intuitive to me.
I hope you continue to enjoy it!
However, I still think there are huge benefits to the type-safe approach. Given a 100,000-line project, how long would it take you to find all usages of a particular column name from a table? With my approach, I can find this out in seconds. Because (unlike with Rails) I have a mapping structure (via the Annotations in my data model classes), my code is isolated from many changes in the schema.
We use "screencast" instead of "movie" for the same reason we use "screenshot" instead of "picture". They both describe that we're capturing from a program.
And in a more philosophical sense, it's the same reason we use "sound" instead of "noise".
Which J2EE development environment are they comparing to? Personally, I like WebObjects. As far as I can tell... Apple was and still is doing everything RoR is doing. Apple (NeXT) just started doing it about a decade earlier. Would anyone care to point out something I'm missing in WO that RoR offers? Well... other than hype?
Actually all of these database problems are solved by Migration in ruby on rails. Not only do they allow you a database agnostic representation of your database schema defined purely in ruby (for sql server, mysql, sqlite, db2, oracle, postgres). They also give you schema versioning capabilities that tie into your deployment tasks if you're using switchtower.
I also find the idea of having to write my queries in a specialized 'portable' query language pretty annoying. If you use standard SQL it is portable anyhow and adding one more level of indirection so I can do the same thing is, not too bright. But with migrations you don't have to worry about any of that anyway.
This is also pretty informative about web applications and frameworks
http://oodt.jpl.nasa.gov/better-web-app.mov
Ruby, by design, takes less lines to do the same thing than most statically typed languages mainly because of its heavy usage of lexical closures. Closures are implemented as what people see as 'blocks' in ruby, which allows code to be more meaningful and terse.
What is this talk about tight coupling and databases? The ORM in rails is not database vendor specific. I don't know a single framework that enforces a database vendor. I'm really confused about what you're talking about. In order to change database vendors in rails you change the database type in one config file and the database adapter automatically changes. The SQL generated by ActiveRecord is standard and the messaging and protocols to the database are specific to the adapters included in rails.
If your schema changes you just change your models if that is even necessary since you don't have to define any of the field names in your models by default so it is highly likely they will just work. If that fails you can always use database migrations which allow you to not only represent your schema in ruby but also to version your database. This works very well with a version control system.
No one should be making drastic changes to some centralized production schema that isn't somehow recorded in a version control patch that can be checked out and run to update your local development/testing database schema. Then you can test your web application code against the new database schema before submitting changes to the repository.
Basecamp uses Ruby on Rails. They serve over 1.8 million hits a month. They use caching and lighttpd with fastcgi. But you can do the same with apache/fastcgi or whatever webserver you want with fastcgi or SCGI. If you don't design your database schema and web application code with scalability and performance in mind then it will be difficult to scale up to a large number of users.
Things to consider include:
Web server
Use of a web server like lighttpd, zeus, or litespeed which use non-blocking select-based connection handling instead of a pre-forking method like apache can handle several times more traffic on the same machine and with less memory and processor usage. This means more performance for your applications.
Usage of on disk sessions
Database storage for session data is much faster and allows for easy http load balancing when the application grows large enough to warrant it.
Number of database queries
Designing the database so that the number of required queries is small. This might require the use of 'eager loading' which performs table joins to form larger result sets with more data. This leads to fewer queries that are larger in size.
Size of each result set
Queries that return a large number of fields or rows can cause a problem because the ORM has to map the result set to objects which means a lot of allocations and assignments by the interpreter. Many times you can solve this by providing paging for large datasets, and additionaly by using the 'lazy loading' behavior of most ORMs so that data is loaded only at the time it is needed. This leads to more queries that are smaller in size.
Database indexing
A lot of the bottlenecks of busy web applications are caused by the database. An intelligent use of indexing can cause select statements to run a orders of magnitude faster than they would otherwise. However, each time you insert a new row or update an indexed field in a table the index has to be recreated for that portion so you have to index appropriately. This is one of the most important things you can do improve the performance of your web applications.
Disk Caching
Cache controllers, actions, models, or blocks of code that render/fetch data so that it can be pulled straight from disk. This can speed up applications by immense factors. For instance in a blog the pages don't need to change unless someone adds a new comment or a post. Caching all of the blog pages until someone adds a comment or a post speeds up the application by a large amount since most of the requests are read-only.
Memory Caching
Add-ons like memcache allow your cache to be stored directly into memory, making it even faster.
That being said, all of these things are supported in rails. If you want to make web applications with ruby on rails or any other framework fly, these are the things to consider. If you do these things your rails application will perform as well as almost any other framework around, even at high load times.
Actually all of these database problems are solved by Migration in ruby on rails. Not only do they allow you a database agnostic representation of your database schema defined purely in ruby (for sql server, mysql, sqlite, db2, oracle, postgres). They also give you schema versioning capabilities that tie into your deployment tasks if you're using switchtower.
No, these problem aren't solved. Look at the schema migration documentation. There are significant things that aren't migrated - 'minor' things like foreign keys!
Why should I put up with a half-working Rails version when my Java ORM allows me to port things in seconds? In fact the more interesting question is - why to Ruby on Rails users put up with such poor quality products?
I also find the idea of having to write my queries in a specialized 'portable' query language pretty annoying.
Why?
If you use standard SQL it is portable anyhow and adding one more level of indirection so I can do the same thing is, not too bright. But with migrations you don't have to worry about any of that anyway.
This is false in almost every respect. Standard SQL is not and has never been portable - migrations between, say SQL Server and DB2 are a nightmare in terms of SQL. Some small subset may be roughly portable, but if you use this subset, you aren't using the full power of the databse.
Secondly, the migrations don't port the SQL you are using, do you do have to worry about this.
I've run the same non-trivial Rails app on three different database products (MySQL on the old Web host, PostgresQL on the new host, and SQLite locally) with minimal headaches -- just migrate the data, tweak a config-file setting, and It Just Works (tm).
Right. Add a foreign key constraint to the PostgreSQL version. Show me an automatic migration of that to the others. Add a couple of 'text' columns to the PostgreSQL version. Show me an automatic migration to Oracle.
Sorry, but Rails is primitive.
I'll admit you can't define foriegn keys natively in your migrations. There are design decisions for this, mainly due the syntax differences and support for foriegn keys amongst databases vendors. They might add them later they might not. Rails prefers to keep this information at the ruby level right now using the has_many, belongs_to, etc. modifiers in the models.
I have SQL, I don't need EQL or any other specialized language. I work with my objects natively in ruby and don't even worry about SQL since ActiveRecord takes care of writing it for me. Don't you? All I have to do to change which database I'm using is change the database user/pass/name in a config file and rerun my migrations on the new database to generate the new schema. I still don't get foreign keys generated in the new databases which is GREAT if I'm using sqlite2 since it doesn't support foreigns keys. What does java do? Probably just ignores that sqlite2 even exists.
SQL-99 has been supported by all database vendors for years. If you are using the 'full power' features that are available in one database that aren't available in another no amount of magic database tools are going to make the features available. Not to mention even some features like 'views' or 'triggers' that several vendors support will have different implementations and different sql syntax. So the question is where do you draw the line with the features you expect to be portable amongst all of your database implementations and where should your database tools draw the line? For rails the line is drawn at sqlite which has a very small feature set compared to other databases. Does java even write things like views for you? This would seem a bit over the top and unecessary.
Also we're talkign about two different pieces here, Migrations and the ORM. The only thing that is not included in the ORM is automatically forming object relations from foriegn keys without having to explicity tell the model about it. But you can't do that in java either, you have to tell the models about their foriegn key relationships even when they are specified in the database already. Other than that the ORM (ActiveRecord) writes the same standard SQL-99 for select, update, delete, insert, count, etc. as any ORM would write from its models in java or otherwise; nothing special is required at this layer. Migrations are relatively new so the ability to store views, triggers, etc. in the ruby schema file is not included and even if it was, should it be? I don't particularly think it should, since this would ruin the database agnosticity of migrations. For instance you couldn't migrate views or triggers to sqlite no matter how sophisticated your database tools were.
Rails prefers to keep this information at the ruby level right now using the has_many, belongs_to, etc. modifiers in the models.
Yes, because that is easy to support. However for a significant number of situations, you aren't the only only user of the database, and such relationships have to be put and kept in the database. More mature ORMs than Rails handle this.
SQL-99 has been supported by all database vendors for years.
No, it hasn't. Neither Oracle, Microsoft or IBM fully support SQL 99. They support different parts of the core standard.
If you are using the 'full power' features that are available in one database that aren't available in another no amount of magic database tools are going to make the features available.
Sorry, you are flat wrong about this. Quality Java ORM systems will automatically make use of the full features of specific databases in order to provide optimum efficiency in querying - as a developer you don't have to put work in to get this. If you have a complex object query, vendor-specific features will be used to make that query work fast. However, if you port exactly the same object query code to another database, it will use different vendor features automatically.
Can you now see why I think Rails is primitive?
The only thing that is not included in the ORM is automatically forming object relations from foriegn keys without having to explicity tell the model about it. But you can't do that in java either, you have to tell the models about their foriegn key relationships even when they are specified in the database already.
No, you don't. Most quality Java ORMs have features to generate object models from databases.
But you are missing the point. The way I work is to develop my object model in one place only - Java classes. The ORM will automatically generate foreign keys in whatever database I choose when it generates the schema to represent my classes. If I pick another vendor's database and switch to that, it does this for me again. It is the DRY principle that Rails is supposed to represent! I specify (and change) things in one place - my object model.
ther than that the ORM (ActiveRecord) writes the same standard SQL-99 for select, update, delete, insert, count, etc. as any ORM would write from its models in java or otherwise; nothing special is required at this layer.
As indicated above, you are wrong. There are ORMs that are far more mature and capable than Rails, and that will automatically go beyond SQL-99 and use powerful features of specific databases to get performance.
My view is that trying to use some sort of common portable subset of SQL-99 is a cop-out, which would be considered a very poor solution in any other situation. I would imagine a database manager who had purchased Oracle or DB2 would be somewhat disappointed if you weren't using the latest features of that database in order to get performance. Sure, you can do that with Rails, but at the cost of losing portability. With a good Java ORM you can do that automatically, and you don't lose portability.
So the question is where do you draw the line with the features you expect to be portable amongst all of your database implementations and where should your database tools draw the line? For rails the line is drawn at sqlite which has a very small feature set compared to other databases.
Indeed, and this seems very poor to me. Sorry, but this seems typical of the Rails approach - implement only a little, then claim that is this 'all you need'.
Does java even write things like views for you? This would seem a bit over the top and unecessary.
No - the idea of Java ORMs is to write things that relate to the object model, and are required to keep that object model valid and consistent (constrains, foreign keys etc.). If there are view and triggers etc, those are the result of some other use of the same data store, and are not relevant to the Java code (although Java ORMs can easily make use of views and stored procedures).
Why does you not being the only user of the database mean that foreign key constraints have to be kept in the database? Foreign keys don't somehow make your colleagues better developers..:)
What are these vendor specific features that you're referring to that speed up the queries an ORM is doing? I'd like to hear about at least one or two.
So which is it? Are we generating models from databases or databases from models?
In the case that we're generating databases from the object model, as you prefer, you still have to list out everything explicitly in your models to generate your databases in which case rails does not do this as it is designed to have the database be created first. Once again the java ORM can't generate foriegn keys in sqlite or other databases that don't support them. This has the possibility of leaving your database schema inconsistent between database vendors and if you were relying on foriegn keys for any type of data validation then your entire application is going to be inconsistent. The solution is simple, don't rely on foreign keys. Relying on foreign keys actually places you closer to your database implementation and not further away from it, which you argued earlier is what you don't want. Also use of foreign keys doesn't allow for rich features like polymorphic associations.
The same argument can be made for all features that are not standard across database vendors. If database portability is a major concern for the application then you have to pick the set of features for some set of databases that you want your application to be portable across and only use features from those databases. Like I said, java has made this tradeoff, but it has only worried about db2, sql server, and oracle. The intersection of the features of these database vendors is where most java ORMs choose to set their feature base lower limit. If you added some other databases and versions in there you'd lose foriegn keys and several other features. Rails adds in MySql, postgres and sqlite which makes the intersection of features smaller. Is this the right place to place the level of support in the framework or the wrong place? I don't know.
In the case where you make your database first and then generate your object models, well then rails is much better at this than any java ORM mainly because of the strong run-time reflection that ruby allows.
Why does you not being the only user of the database mean that foreign key constraints have to be kept in the database? Foreign keys don't somehow make your colleagues better developers..:)
No, but it makes sure they can't screw up your data.
So which is it? Are we generating models from databases or databases from models?
Both. Depends on the circumstances. Which is why most Java ORMs have 'meet in the middle' schema handling where your requirements can match the constraints of existing schema information.
Once again the java ORM can't generate foriegn keys in sqlite or other databases that don't support them. This has the possibility of leaving your database schema inconsistent between database vendors and if you were relying on foriegn keys for any type of data validation then your entire application is going to be inconsistent. The solution is simple, don't rely on foreign keys. Relying on foreign keys actually places you closer to your database implementation and not further away from it, which you argued earlier is what you don't want. Also use of foreign keys doesn't allow for rich features like polymorphic associations.
Of course your application need not be inconsistent.
Having this flexiblity in Java ORMs allows you to develop and run test cases on lighter databases - perhaps without foreign keys, and then deply on more robust databases in a multi-user, multi-application environment with foreign keys. It is a powerful and simple facility that gives your code flexibility and robustness.
If database portability is a major concern for the application then you have to pick the set of features for some set of databases that you want your application to be portable across and only use features from those databases. Like I said, java has made this tradeoff, but it has only worried about db2, sql server, and oracle.
No, you are wrong. You don't have to pick a set of features with a Java ORM - you get the full set of features for the database you deploy on automatically. There is no tradeoff, and to say there is is to misunderstand how well Java systems work.
In the case where you make your database first and then generate your object models, well then rails is much better at this than any java ORM mainly because of the strong run-time reflection that ruby allows.
No. The issue of using run-time reflection is irrelevant to where you define your model. Java can easily work with definitions in the database as the place where the model is defined. But anyway, run-time reflection seems cool but has major disadvantages, such as the inability to test parts of the code away from the database. It also makes your code potentially highly fragile - your code is succeptible to run-time changes in the schema by other code or other users.
If you define in your model that you have foreign keys but you deploy to sqlite, you don't have foreign keys. That is a trade off for any application in any framework. Therefore if sqlite is your deployment database your application has to decide that you can't rely on features not implemented in sqlite. This is what I meant. These are decisions made when the application is planned.
If you're saying that you will just define the maximum set of features and then the database tool will skip the ones that aren't available in one database when deploying to it, and will use them on deployment to another database, then fine. But that is simply a waste of your time.
The only way you could ever have an application that relies on sophisticated database features in a deployment environment is to also have those features available for you in your testing and development environment. In any event during development if you're developing on a database with lesser features than your deployment environment, you can't test those features in your application. If you're developing on the database with more features than your deployment environment you can't implement the features in your application since you don't have the database to support them in your development setup.
Also, what features are we even talking about? The only possible feature I could think of is foriegn keys and user defined data types since that is something that can be represented in a model. Everything else an ORM does is select, update, insert, and delete in very standard ways. All of these other 'features' like views, triggers, stored procedures, indices, caching etc. are indepedent of the queries or frameworks that you use and are carried out by the database and not implemented in any model objects. I know for a fact ORMs like Hibernate simply write normal SQL queries even if they have to translate them from special query languages like HQL. All of the special options that you put in hibernate models merely tell it how to form the SQL and which other models to join or save when performing different operations.
We use functional, unit, and integration tests with fixtures.
If you define in your model that you have foreign keys but you deploy to sqlite, you don't have foreign keys. That is a trade off for any application in any framework. Therefore if sqlite is your deployment database your application has to decide that you can't rely on features not implemented in sqlite. This is what I meant. These are decisions made when the application is planned.
You are missing the point. You don't need to make these decisions, or if you do make them, you don't need to make them once and for all for all deployments.
For example, you may have test datasets that don't need constraints as you are the only one using them. But, for the real deployment (which may be a multi-user and multi-app environment) you get the constraints for free that protect your data.
If you're saying that you will just define the maximum set of features and then the database tool will skip the ones that aren't available in one database when deploying to it, and will use them on deployment to another database, then fine. But that is simply a waste of your time.
I didn't say that, as this is not how things work. Imagine that the ORM is like an optimising compiler that analyses the database and produces the best SQL given the particular database. Sort of like compiling automatically with 64-bit instructions on a 64-bit processor if you are running on one.
The only way you could ever have an application that relies on sophisticated database features in a deployment environment is to also have those features available for you in your testing and development environment.
No, not true. There may be (and are) particular functions or ways of doing joins etc. that are available on one database but not on another. You don't need these around at testing - the ORM will automatically use them if you select that database. No testing or use in development environment required.
Also, what features are we even talking about? The only possible feature I could think of is foriegn keys and user defined data types since that is something that can be represented in a model. Everything else an ORM does is select, update, insert, and delete in very standard ways.
No, it doesn't. It can use highly specific optimisations (types of joins, specific functions available in specific database products etc.) to produce very highly tuned queries. And it can do this automatically.
All of these other 'features' like views, triggers, stored procedures, indices, caching etc. are indepedent of the queries or frameworks that you use and are carried out by the database and not implemented in any model objects.
No, you are wrong again. Views and triggers are database-specific, but indices and cacheing can be very finely controlled by the ORM automatically based on analysis of your object model. They can, in some systems, even be implemented directly in model objects via annotations.
I know for a fact ORMs like Hibernate simply write normal SQL queries even if they have to translate them from special query languages like HQL.
No, you are wrong again. They can produce not only very vendor-specific SQL (not 'normal' queries), but systems like JDO don't even need to use SQL - they can use a very wide range of persistence mechanisms - object database, SOAP, XML, CSV, file systems, LDAP.
All of the special options that you put in hibernate models merely tell it how to form the SQL and which other models to join or save when performing different operations.
That is Hibernate. Java ORMs consist of far more than Hiberbate - there are many systems that are far more efficient and far more powerful.
We use functional, unit, and integration tests with fixtures.
You can use as much of these as you like, but they don't hide the fact that your data model simply doesn't exist away from the database, and even worse, if you (or someone else) changes the database, your data classes change. Testing is simply papering over this design flaw of Rails.
So what you're saying is that the ORM layer groks the foreign keys from the object models and places the constraints on the database when it is available as a feature. This is not bad, but once again, you can't rely on those keys for data validation in your application unless you know that all of your development/deployment systems have this ability.
We must be living in very different worlds.. Go read your logs show me this magic SQL and the joins you're talking about and the functions as well.. I'll believe that they exist when I see them.. I've been developing web applications for a long time; I must have missed out on all this special tech.
You're right, the domain model resides inside the database. That is its purpose and the reason it is relational. Maybe this is a difference of philosophy.
So what you're saying is that the ORM layer groks the foreign keys from the object models and places the constraints on the database when it is available as a feature.
Exactly.
Go read your logs show me this magic SQL and the joins you're talking about and the functions as well.. I'll believe that they exist when I see them.. I've been developing web applications for a long time; I must have missed out on all this special tech.
OK. However, this is not 'magic SQL' or 'special tech' - this are features that should be well-known to experienced database developers. Things like using sub-queries in some databases where they are allowed (Oracle), using vendor-specific sql functions (e.g. 'decode' in Oracle) and coding specific join types that are optimised for specific databases.
Let me emphasise - with a good Java ORM, you don't have to be a database expert to get these optimisations - you get them automatically because the ORM developer knows when they can be used and produces optimised SQL from your portable query. You can get this in Java because there are standards for ORMs, and database vendors can compete to provide optimal implementations (like Oracle and TopLink). You aren't forced to resort to some sub-standard subset of SQL as with Rails.
This is not bad, but once again, you can't rely on those keys for data validation in your application unless you know that all of your development/deployment systems have this ability.
You aren't requiring this for validation in your application - it is adding safety (and efficiency) in certain deployment situations. You aren't relying on them in, say, an embedded test database as you don't need them there. You can rely on them in situations where they are appropriate - multi-user databases where other applications may share the data store.
And, again, you don't need to specify these manually in your database. The ORM can generate them for you.
You're right, the domain model resides inside the database. That is its purpose and the reason it is relational. Maybe this is a difference of philosophy.
It is, and it is an old-fashioned and very restrictive philosophy. I assumed that most development had moved to OOP and flexibility, from the relational model that was commonplace in the 80s. It seems Rails wants to step back decades! With my JDO java ORM I can persist the same truly object-oriented model to high-performance relational stores, hierarchical XML or even CSV. Even better, I can allow the user of my application to choose. I can say 'here is my application - you pick the database'. And I get the full features of a portable query language no matter what store - I can run complex queries on CSV files! It may not be efficient, but I can do it - and for small volumes of data that is incredibly powerful.
Any less flexibility seems primitive to me; because it is primitive.
I honestly believe that a lot of Rails supporters really haven't investigated what modern Java ORMs can do. If they did, they would demand far more of Rails. I really don't understand why they put up with so little.
But what's your point? When using native bindings to C libraries, they act just like other perl modules. It's the same reason we don't use native perl database drivers as well. I don't see how using C bindings in modules is an argument against using the language. Perl was written in C as well, after all.
-- Marcus Ramberg
But what's your point? When using native bindings to C libraries, they act just like other perl modules. It's the same reason we don't use native perl database drivers as well. I don't see how using C bindings in modules is an argument against using the language. Perl was written in C as well, after all.
Because it is a mess when you have to do it yourself. You are having to support two languages in your project - two sets of compilers, two types of debugger, and you are having to package additional libraries with your code. All this is uncessary if you find a fast enough language.