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."

Comments

nice

[jlebrech]

seems like a nice tutorial, even for non-os x users. I'll have to bookmark it on my site.

Re:nice

[Anonymous Coward]

Don't bother. It would be a waste of your time because your site is ugly and completely useless.

Re:nice

[Anonymous Coward]

i thought that was a little harsh until I clicked the link

Re:nice

[a name no one though]

Agreed I'de pay at least $5,000 for that domain. Actually, I wouldn't.

Re:Figures

[sxtxixtxcxh]

seven minutes between the article posting and the first anti-mac sentiment? slashdot, you feeling okay?

So..

[PeterSomnium]

Now I'm finally able to get the Ruby Apple in Lufia on the SNES?

Re:So..

[PeterSomnium]

Lufia 1 & 2 were, in my opinion, after the Zelda series, the best RPG ever.. but anyway, on-topic.. I don't think they mean the Ruby Apple here :-(

Re:So..

[PeterSomnium]

I know, but I still think Lufia is great :P. Dekar is tha man!

anagram

[Anonymous Coward]

yu suk nob is an anagram of ruby on rails. Try it yourself!

Re:anagram

[Jerom]

no it is not.

Ruby Is Groovy

[ObsessiveMathsFreak]

Jobs: Ruby is groovy man. It's got like, vibe. We had to get in on that.

Gates: C# with .NET offers more flexibility with less development worries and higher performance...

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. .NET can accomplish all the same....

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! .NET does all this! Why won't anyone listen? You believe me right?

Torvalds: Look man. I really just don't give a shit.

Re:Ruby Is Groovy

[Anonymous Coward]

.NET's ORM system is nowhere near as complete or useful as the one in Rails... You're kidding yourself if you think otherwise (and yes, I have tried development in both systems and Rails beats .NET hands down)

Re:Ruby Is Groovy

[Anonymous Coward]

I actually would go with the "Gates" personality in your little chamber play. It IS just another hyped up silver bullet, and the current infatuation with it wont last.

Look out for the rabid fanboys here on Slashdot though, the Jerks on rails. Fastest prototyping and biggest mouths in town, with an ego that makes a Lisp programmer look humble.

Re:Ruby Is Groovy

[jlebrech]

Something like ruby is what apple needs to compete with .net.

It's another subset of ADA but the language is ment to be more readable and is more human the C#

Re:Ruby Is Groovy

[k2r]

> Ruby is a free spirit. It grows in like, the sunshine. It doesn't obey your rules!

It's more like "Ruby doesn't get in your way!" as Rails dosn't do (most of the time) and OSX avoids to do quite successfully , too.

Chunky. Bacon.
k2r

Re:Ruby Is Groovy

[LarsWestergren]

Something like ruby is what apple needs to compete with .net.

It is not like there is only room for a single programming language on a platform...

Besides, Apple already uses Java, for instance it built the highly successful WebObjects around it. If, against all odds, .Net would completely wipe out Java there is always Mono.

Re:Ruby Is Groovy

[guet]

WebObjects wasn't built around Java, or even on top of it. It was ported to Java after being written in Objective C.

However your point still stands, there are many frameworks to choose from on both platforms, there doesn't have to be One True Way, in fact, it's harmful to think that way.

Re:Ruby Is Groovy

[saboola]

Ballmer: (Throws a chair)

Re:Ruby Is Groovy

[jbolden]

Ruby -- A pretty cool scripting language.
Ruby on Rails -- A pretty cool web applications framework using Ruby .NET - A complex framework unifying a virtual machine written in a functional programming language (CLI) with the interpretive frameworks that most programmers are familiar with (language specific compilers). Ships with a complete IDE, hundreds of low level OS functions, implementations for some of the popular programming languages, a full set of widgets covering graphics, database access, networking....

_____

Your statement is like saying: Something like the whopper is what McDonald's needs to compete with Boeing's new engine.

Re:Ruby Is Groovy

[LarsWestergren]

Something like ruby is what apple needs to compete with .net.

Sorry, I was a bit quick to answer in my previous post, I completely missed you point. Here comes second try:

People who like Apple are hardly going to be swayed to PCs by .Net of all things. There are plenty of programming environments both for desktop apps and enterprise things, such as Objective C, Java and others.

Neither are .Net developers likely to swarm to Macs because of Ruby.

So while Ruby for Mac is a nice thing by all means for Mac developers, this does nothing for overall marketshare, which will depend on completely different things.

Re:Ruby Is Groovy

[Anonymous Coward]

Very true. I do think this just shows that MacOSX is an excellent development platform.

Re:Ruby Is Groovy

[Pollardito]

.NET's ORM system is nowhere near as complete or useful as the one in Rails... You're kidding yourself if you think otherwise (and yes, I have tried development in both systems and Rails beats .NET hands down)

dude, read closer, it's Bill Gates that's kidding himself

Re:Ruby Is Groovy

[Anonymous Coward]

Wow. Sarcasm is completely lost on you, isn't it?

Re:Ruby Is Groovy

[Eric_Cartman_South_P]

But have you ever seen Ruby on Rails... on weeeeeeed?

Re:Ruby Is Groovy

[Jearil]

That's interesting. First you attempt to attack a platform (the one under topic naturally), and then immediately attack the users of that platform before they can place any defense as, you know, a second opinion on why they may disagree with you. You even attack the fact that they might disagree with you in a way that makes any sort of defense appear as though they are just spouting out fanboi flames.

Instant defense without even an attack, such as what you have shown here, really makes one wonder if their arguments can stand on their own merits. I for one believe they cannot.

Re:Ruby Is Groovy

[hcdejong]

Yeah, I have. I went like "bleep, bleep, bleep", and then, like, half my paper was gone.

Re:Ruby Is Groovy

[Eivind Eklund]

Here we go again :)

Isn't the present split between programmers about 50-50 with Windows experience and without? I know I don't run into Windows programming that often, and I tend to run into more Unix than Windows programmers, even outside Unix circles...

Part of that is probably that I tend to like the "deep knowledge crowd" everywhere, and Windows is hard to have deep knowledge of, but I thought I'd seen statistics indicating about 50-50?

Eivind, questioning...

Re:Ruby Is Groovy

[mosch]

I disagree with that statement thoroughly.

Ruby is fantastic. Rails will probably be fantastic in about two years. Right now it's an immature product that gets in your way constantly, if you do anything seriously involved in it. Rails error messages range from "moderately unhelpful" to "holy shit obscure".

It seems that premature rails hype is leading to coders looking at it, and deciding that ruby is a shitty, inflexible, immature language, when they're blaming the wrong thing.

Re:Ruby Is Groovy

[jbolden]

You're right here we go again, I don't have a clue what you are responding to in my post. Let me rephrase just to make sure you are clear:
creating Ruby on Rails = X amount of man months (alternately degree of complexity_
creating .Net = Y amount of man months (degree of complexity)

Y is much much bigger than X.

Re:Ruby Is Groovy

[I Like Pudding]

Yes. All the variable names were pulled directly off the Taco Bell menu.

def nachos
  @nachos = @params[:nachos]
  render
end

Damn pot heads with their XSS-exploit-ridden pot code.

Re:Ruby Is Groovy

[Eivind Eklund]

What I wondered about was the idea that most programmers knew .NET from before (or maybe I misread)?

And yeah, .NET is definately much more complex than RoR - not sure if you're trying to say that's an advantage or disadvantage or just a fact?

Eivind.

Re:Ruby Is Groovy

[shutdown -p now]

.NET has a built-in ORM system?

Re:Ruby Is Groovy

[IAmTheDave]

People who like Apple are hardly going to be swayed to PCs by .Net of all things. There are plenty of programming environments both for desktop apps and enterprise things, such as Objective C, Java and others. Neither are .Net developers likely to swarm to Macs because of Ruby.

Exactly. And people like me, who switched to Mac at home but still write .NET will not be swayed.

Look, I love looking in to new languages, learning new things - it's why I got into programming to begin with. But unless you start your own business or are the director of IT at your company, you probably program what you do because you're paid to do it. Further to that, the more time you spend in a language, the better you become in that language and the more l33t you are on that platform, in that language, in that OS.

Yeah, I know PHP. I used to know PERL. I know a little Ruby. But I've been writing C# since .NET 1.0 was in beta, and I know it like the back of my hand. I love the language and the framework, and I'm an expert in it. So will something sway me to Ruby? Certainly not at my job, which has millions of lines of code in C#. Maybe at home, but why tax myself when I know C# so well?

So ROR is cool, but I guarentee you that even after a month with ROR, I can still do something cleaner, faster in C# and .NET, just because I know it so intimately.

Re:Ruby Is Groovy

[Anonymous Coward]

Doing .NET during the day, to pay the bills for now, and RoR at night to pay some smaller bills and have fun. I have to completely disagree. RoR is more functional, faster and easier to use. Annectodal evidence, but these are not fields that are easily quantified anyway.

I resisted Ruby and Rails for several years while I did python and cheetah. I then gave it a shot and have never looked back. Most of the problems I have run into with Rails is that I was trying to do something the hard way instead of the Rails way.

Give it a _fair_ shot and you most likely will never look back.

Re:Ruby Is Groovy

[jbolden]

More of a "just a fact". Mainly the point was that RoR and .Net weren't really comparable; the same way a an airplane and a hamburger.

As for knowing .NET from before unifying a virtual machine written in a functional programming language (CLI) with the interpretive frameworks that most programmers are familiar with (language specific compilers).

What I was saying was that .NET makes available to programmers many of the advantages of a functional programming language while using syntaxes of interpretive languages that are already familiar with. Lets take C# as an example of this. C# uses a syntax which your typical C/C++ or Java programmer would have no trouble adjusting to. The built in classes end up doing some late binding and lazy evaluation. However, because of the implementation in F# (the functional language), you don't take the performance hit you normally would for complex class constructions. KDE/QT would be an example of a C++ where you get the complex constructions late binding and lazy evaluation along with substantial performance hits. Win32 would be a good example of a framework where you get pretty good performance but very inflexible classes.

OK now we know what we are discussing, shoot. :)

Re:Ruby Is Groovy

[jbolden]

Oh I have no doubt RoR is more fun. Its a scripting language not a compiled language so more productive is almost a given.

OTOH reread the post. .NET is trying to accomplish a much more serious and difficult goal then a web application framework.

Re:Ruby Is Groovy

[Eivind Eklund]

Ah, then I missed the point. That's an interesting aspect of .NET, one that I've not thought about. I mostly stay away from MS technology for "ideological" reasons (put my money where my mouth is).

That said, I think the tech around C# seems very, very nice.

Eivind.

Re:Ruby Is Groovy

[finnif]

.NET's ORM system

Do you mean ADO.NET, which is not ORM? Or do you mean ObjectSpaces, which is not yet released?

If you're serious about ORM in .NET, check out Wilson's ORM, or check out NHibernate.

Re:Ruby Is Groovy

[Anonymous Coward]

Gates: But it's all just flash and hype. Nothing really new is going on! .NET does all this! Why won't anyone listen? You believe me right?

.NET is all flash and hype too. In fact, it's a very slow, bloated framework that tries to recreate Java but tie you to the Windows platform. .NET also isn't available for OS X anyway.

Re:Ruby Is Groovy

[Geckoman]

.NET - A complex framework unifying a virtual machine written in a functional programming language...Ships with a complete IDE, hundreds of low level OS functions... a full set of widgets covering graphics, database access, networking....

So...it's basically like Smalltalk? ;-)

Re:Ruby Is Groovy

[bheer]

> Win32 would be a good example of a framework where you get pretty good performance but very inflexible classes.

Nitpick: Win32 has classes?

Re:Ruby Is Groovy

[jbolden]

yep

Re:Ruby Is Groovy

[killjoe]

Webobjects kicks ass. Except for one thing. The learning curve is insanely steep.

If they made the rule system more useful everything else would pale in comparison.

If Apple know what to do with webobjects rails (or even zope) would have never been invented.

Re:Ruby Is Groovy

[bheer]

You linked to the WMI Classes. WMI classes are used to instantiate 'manageable' objects in a Windows system to make system administration and automation easy. When people say 'Win32' in a development context without qualification, they usually mean the Platform SDK, which is (last I checked) definitely _not_ OO.

Bringing WMI into a discussion of Qt vs RoR vs .NET makes very little sense.

Win32's successor (WinFX) has large parts of managed code, though and hence is partly OO.

Re:Ruby Is Groovy

[hcdejong]

Jobs: (Notices nothing as chair bounces off off RDF)

Re:Ruby Is Groovy

[rgraham]

> Chunky. Bacon.

I don't know if anyone else got this but I certainly did.

Re:Ruby Is Groovy

[jbolden]

You didn't look carefully. wind 32 classes. I think you are confusing two things:

1) Whether the functions themselves are organized in an OO way
2) Whether the languages required you to be OO in your thinking

Win16 was OO it was written in organized C++. OTOH VB 3 or whatever was not OO by any stretch. Do you see the difference? This actually pretty SOP for Microsoft they tend not to push people towards better ways of working but rather build products which fit people's percieved desires.

Re:Ruby Is Groovy

[Paradise Pete]

That was really good. Almost too good for a quick comment, especially from an obsessive maths freak. Did you just write that?

(and I'm old enough to remember when (some) people really talked like that)

Re:Ruby Is Groovy

[jma05]

It does now (of sorts, in some ways better). It's called Dlinq. Not completly out.

Re:Ruby Is Groovy

[shutdown -p now]

Isn't it scheduled to be released together with C# 3.0 somewhere in 2007? In which case, what do you mean by "not completely out" - is there a preview release?

Re:Ruby Is Groovy

[k2r]

> Rails will probably be fantastic in about two years. Right now it's an immature
> product that gets in your way constantly,

I have used RoR for some projects within the last 6 months and though it's far from being fantastic I don't feel as if it got in my way often. I really enjoy using Rails.
Of course Rails is waaaaaay more inflexible than the fact that it's a framework for Ruby promises and it was a moving taget within the last months. And it's a distributed documentation project.
In fact, some of the real beauty of Ruby is absolutely invisible and inaccessible using Rails.

It's based on some pragmatic decisions you have to comply - yes, the Rails metaphor fit's it quite well.
Rails is on it's tracks. If these tracks are "Your Way" - as it is with most of my projects - it's already a really fast _and_ scenic route to take.

I agree on the esotheric error-messages. You get used to them if you start understanding how rails works. But they suck badly and eat up time.

Well, not in the Worst Way. I once used an IDE at university which error-message read "something's wrong" :-)

k2r

(The system had a "No Help" Menu, too. It was for SML or Scheme, if I recall correctly.)

Re:Ruby Is Groovy

[ObsessiveMathsFreak]

I can safely say; it wrote itself.

Re:Ruby Is Groovy

[jma05]

Yup! You got it right. It will not be officially distributed till C# 3.0 comes out but it integrates fine with Visual Studio already.

Re:Ruby Is Groovy

[Frumious Wombat]

If it were only that elegant and well-implemented.

Somewhere, there's a rational parallel universe where almost everything is done in SmallTalk. Very little actually gets done, but it looks beautiful.

Mac and Ruby history

[Anonymous Coward]

Not that surprising as both Mac and Ruby were very popular in Japan already and Mac OS 10.2 also had Ruby installed by default. Using Ruby therefor seems like an easy step up from Applescript.

And now with Ruby-On-Rails being a killerapp for forward looking web designers seeing crosslinks between Mac users and Ruby users reaffirms the designer's idea that developing in Ruby is a reachable goal, as many others Mac users seem to have taken a similar path and already master Ruby.

Re:Mac and Ruby history

[Decaff]

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.

Re:Mac and Ruby history

[finnif]

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?

Re:Mac and Ruby history

[Overly Critical Guy]

I'm overwhelmed by your citation of sources and real-world examples proving your claim of Ruby's slowness!

Re:Mac and Ruby history

[Decaff]

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.

Re:Mac and Ruby history

[jkauzlar]

Complain, complain..

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!

Re:Mac and Ruby history

[finnif]

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

Re:Mac and Ruby history

[Decaff]

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?).

Re:Mac and Ruby history

[TerrapinOrange]

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?

Re:Mac and Ruby history

[TerrapinOrange]

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.

Re:Mac and Ruby history

[Decaff]

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?

Re:Mac and Ruby history

[Decaff]

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.

Re:Mac and Ruby history

[parking_lot]

If I read another Ruby article I think I'm gonna puke.

Re:Mac and Ruby history

[TerrapinOrange]

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?

Re:Mac and Ruby history

[Decaff]

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.

Re:Mac and Ruby history

[TerrapinOrange]

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.

Re:Mac and Ruby history

[finnif]

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.

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 /.ed?

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.

Re:Mac and Ruby history

[Decaff]

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.

Re:Mac and Ruby history

[gigahawk]

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.

Re:Mac and Ruby history

[gigahawk]

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.

Re:Mac and Ruby history

[Decaff]

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.

Re:Mac and Ruby history

[gigahawk]

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!

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.

Why?

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.

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.

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.

Re:Mac and Ruby history

[Decaff]

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).

Re:Mac and Ruby history

[gigahawk]

you aren't the only only user of the database, and such relationships have to be put and kept in the database.

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..:)

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.

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.

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.

Most quality Java ORMs have features to generate object models from databases.

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.

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.

Re:Mac and Ruby history

[Decaff]

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.

Re:Mac and Ruby history

[gigahawk]

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.

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.

such as the inability to test parts of the code away from the database.

We use functional, unit, and integration tests with fixtures.

Re:Mac and Ruby history

[Decaff]

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.

Re:Mac and Ruby history

[gigahawk]

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.

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.

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.

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.

they don't hide the fact that your data model simply doesn't exist away from the database

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.

Re:Mac and Ruby history

[Decaff]

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.

Re:Mac and Ruby history

[draven]

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.

Re:Mac and Ruby history

[Decaff]

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.

Now is the time...

[bogaboga]

...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.

Re:Now is the time...

[dtsazza]

I was kind of tired of trying other tutorials (mainly from the internet) as I fouind them incomplete and sincerely wanting.

Did you see Programming Ruby: The Pragmatic Programmer's Guide, by Ruby's creator Yukihiro Matsumoto? It's a freely-available transcript of a paper book, and I'm halfway through and finding it good going.

Now I'm only playing with Ruby at the moment, so I couldn't say how the examples and sections stand up to heavy industrial use, but if seems an excellent introduction and the tone and flow are both good!

Re:Now is the time...

[evolve75]

Actually it is the 1st edition of THE Ruby book (similar to the Camel book for Perl). This edition is somewhat outdated, but still a very good introduction and easy reference to the class libraries. BTW, the book has an introduction by Matsumoto, but has been written by Dave Thomas and Andy Hunt - not Matz.

Re:Now is the time...

[moongha]

You're correct that Programming Ruby (The pickaxe book) is an excellent introduction to Ruby.

But it wasn't written by Matz.

About The Authors

Dave Thomas is a cornerstone of the Ruby community, and is personally responsible for many of its innovative directions and initiatives. He and original co-author Andy Hunt are founders of the Pragmatic Programmers and the Pragmatic Bookshelf. Chad Fowler is co-director of Ruby Central, Inc., and remains an active, driving force in the Ruby community.

O'Reilly to the rescue

[CRCulver]

It's nice to have a free tutorial, but Amazon reports that O'Reilly is releasing something called Ruby on Rails: Up and Running in May. This will be good for those among us who have become addicted to O'Reilly's efficient guides.

Re:O'Reilly to the rescue

[Anonymous Coward]

How nice of you to spam Slashdot with your Amazon referrer ID. Feel like linking to another thousand or so books we're all too dumb to find?

Re:O'Reilly to the rescue

[flipper65]

Actually, you can order the 'rough cuts' version of the book now and download additional content as the author writes it.

Re:O'Reilly to the rescue

[Anonymous Coward]

It's nice to have a free tutorial, but Amazon reports that O'Reilly is releasing something called Ruby on Rails: Up and Running in May. This will be good for those among us who have become addicted to O'Reilly's efficient guides.

I have the Rough Cuts of this; skip it. Compared to other titles I've seen in Rough Cuts, this one is poorly written and lacks depth.

Re:Figures

[Anonymous Coward]

From TFA " And all members of the Rails core development team work with Macs "

And then FFP " seven minutes between the article posting and the first anti-mac sentiment? "

Hah!! I wont anti-Mac but could this be another bad technology like Macromedia Flash, very annoying to users yet the darling of developers?

Baskin Robins

[Mr. Underbridge]

Hey, I hear Baskin Robins is coming out with a new ice cream this month, "Ruby."

This month only though, flavor of the month. Next month they're doing AJAX.

Re:Baskin Robins

[Rosyna]

I had assumed they'd just release a Bubble Gum-like flavor called Web 2.0.

Perhaps we should ask The Question?

Re:Baskin Robins

[Anonymous Coward]

This is the worst joke I've ever heard.

Re:Baskin Robins

[mjpaci]

Mmmmm...AJAX ice cream. The real question is: with or without bleach?

Here is a review of AJAX:http://www.epinions.com/Ajax_Cleanser_with_Bl each_Easy_Rinse_Formula

Re:Baskin Robins

[Pollardito]

i can't understand the attraction to AJAX, it tasted pretty gritty the last time i tried it

Re:Baskin Robins

[Snap E Tom]

About four years ago, they had Python as the FoM. Anyone try it? I bet it tasted like chicken. I'm a vegetarian, so I didn't try it.

Re:Baskin Robins

[Dukael_Mikakis]

Probably meant it as a joke/troll, but it's a pretty empty comment, Ruby and AJAX are completely different things, one's a language the other's not. I understand the "flavor of the month" thing, but you're talking apples and oranges.

Comment removed

[account_deleted]

Comment removed based on user account deletion

Re:Figures

[Decaff]

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.

OS X Ruby doesn't work with Rails?

[Larthallor]

According to Apple's article:

The version of Ruby that ships on Mac OS X Tiger is 1.8.2, but it doesn't work well with Rails. So you'll need to upgrade your Ruby installation as well as install a newer version of Rails (as of this writing, use version 1.8.4).

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?

Re:OS X Ruby doesn't work with Rails?

[Anonymous Coward]

If you bother to KEEP READING, they mention that their chosen install system installs a SECOND copy of ruby so that anything relying on the default one in OSX isn't hosed. Simp.

Re:OS X Ruby doesn't work with Rails?

[skribble]

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?

Because it's probably not fully tested to work with Tiger. The only system updates you get with Software Update and bug fixes and security fixes. Occasionally you'll get something else which works behind the scenes with an updated iApp as well (there have been minor CoreImage and other framework pieces updated this way).

This is just good sense, it's stability vs. cutting edge. Also it can be a very bad thing to update the system incrementally (Ask Microsoft who have been bitten by this many times... often updating one thing can have unexpected results on others.

Also, for a developers interested in using Rails, updating Ruby is fairly trivial. I would also add that often even if Apple includes the latest version of something you may want to compile it yourself anyway (Apache, PHP. MySQL are good examples of things that people will often *upgrade* right out of the box).

Re:OS X Ruby doesn't work with Rails?

[newdamage]

Here's a tutorial for getting a completely self contained Rails dev environment ready to go on OS X, without having to worry about the default OS X Ruby install not supporting Readline and such.

Ruby on Rails, Lighttpd, MySQL on OS X Tiger

It's also a good tutorial for learning in general how to get the development tools you need and compiling them from source into /usr/local/

Re:OS X Ruby doesn't work with Rails?

[Mark Hood]

Because later in that same paragraph:

It starts by installing Ruby 1.8.4 without overwriting the system-installed Ruby (it puts the new version in /usr/local). That way, the default system works as expected for other users or programs already coded for the system-installed ruby.

Now if you'd asked why 1.8.4 might break things expecting 1.8.2, that's another question :)

Mark

Re:OS X Ruby doesn't work with Rails?

[squiggleslash]

There's something wrong, somehow, about the notion that a "mature" framework requires the absolute bleeding edge version, such that 1.8.4 works and 1.8.2 doesn't.

Mind you, it could just mean there's a bug in 1.8.2/.3 that happened to break RoR, so I'll reserve judgement.

Is Ruby "stable"? That is, is it still under intensive development or are we looking at minor upgrades to fix bugs and such in the implementation?

Re:OS X Ruby doesn't work with Rails?

[Peter Cooper]

No, it's that Apple's version of Ruby is screwed up. I still run most of my Rails apps on 1.8.2 (25th December 2004 build).

Re:OS X Ruby doesn't work with Rails?

[prockcore]

Because it's probably not fully tested to work with Tiger. The only system updates you get with Software Update and bug fixes and security fixes.

Well, actually, Apple has miscompiled Ruby since 2003. The pack/unpack functions don't work correctly. You can recompile 1.8.2 yourself and make it work just fine with Rails.

The problem is that Apple cross compiled Ruby screwy, so it thinks it's on a little endian machine when it's really on a PPC.

Converting stuff to Network Byte Order will actually give you the opposite using Apple's Ruby.

Apple should release a bug fix, but they have neglected to do so.

Re:OS X Ruby doesn't work with Rails?

[John Whitley]

[...] for a developers interested in using Rails, updating Ruby is fairly trivial.

Another point is that many people use a custom install of Ruby to ensure that they're using the same version as their webhosting service. There's no reason to run a newer version when that just introduces an unecessary difference between your development and production environments.

Re:OS X Ruby doesn't work with Rails?

[Fweeky]

"There's something wrong, somehow, about the notion that a "mature" framework requires the absolute bleeding edge version, such that 1.8.4 works and 1.8.2 doesn't."

Rails only hit 1.0 a few months ago, makes sense that they'll want people to run it with a Ruby release at least as recent, if only so people don't get bitten by security issues or bugs Rails exposes in earlier versions. FWIW I run Rails fine on an oldish Ruby 1.8.2 out of FreeBSD ports; I dare say Apple don't maintain their Ruby release as well.

"Is Ruby "stable"? That is, is it still under intensive development or are we looking at minor upgrades to fix bugs and such in the implementation?"

Both. 1.8 has been around for a few years and is still only on it's 4th major release. 1.9/2.0 are in heavy development and come with significant internal changes. You can be sure that by release Rails will be well tested with them :)

Re:OS X Ruby doesn't work with Rails?

[killjoe]

I have been going to WWDC for three years now. Every year during the feedback sessions people always ask the same things.

1) How come you hate webobjects developers so much.
2) When are you going to get a decent package management tool or formally adopt darwinports.

Every year the answers are the same.

1) We don't really hate you guys, we really love you, we neglect webobjects on purpose.
2) We are apple, neither darwinports nor pkgsrc, nor fink is good enough for us. One day we will write a really cool one just watch.

It would be funny if it wasn't so sad.

Re:OS X Ruby doesn't work with Rails?

[Enahs]

LOL.

Wouldn't know about the first part, but the second part...no surprise. What they'll do eventually is come up with something that replicates 95% of the functionality of Fink, pkgsrc, and DarwinPorts while being not only incompatible, but will actually break all three.

That's my prediction, at least...

Re:OS X Ruby doesn't work with Rails?

[ak3ldama]

word. someone understands this stuff!

Re:Figures

[Anonymous Coward]

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,

I think

[Anonymous Coward]

You all just like saying "Ruby on Rails."

Looks interesting

[ROOK*CA]

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?

Re:Looks interesting

[lennart78]

I've been spending quite some time working on it on an OS from Redmont. I'd reckon the experience can be compared to that on any *NIX/BSD you prefer.

The main things I have to say about tools is: I haven't found the right tool. Yet.

The scintilla-based editor that comes with rails is ok, but no more than that. I'd prefer an IDE, with some project management and such. It seems like there are some possibilities with eclipse. http://www.napcs.com/howto/railsonwindows.html#_To c111133460

But I still have to check that one out...

Re:Looks interesting

[ROOK*CA]

Cool thanks for the reply & the link, definitely a plus if the Eclipse plug in works well with this framework (Eclipse is a great IDE IMHO).

Re:Looks interesting

[Anonymous Coward]

How does it stack up against Java for ease of development and/or performance/flexibility?

My opinion;

Smaller projects - strengths of Ruby is greater.

Bigger projects - strengths of Java is greater.

At my job we are currently using Ruby for prototyping and small projects, if the project grows we move it to Java.

Re:Looks interesting

[ROOK*CA]

At my job we are currently using Ruby for prototyping and small projects, if the project grows we move it to Java.

What tools are you using (for Ruby and Java) and how would you rate their effectiveness/quality? do you find it easier to port your smaller ruby projects over to java when it's needed?

Thanks in advance :)

Re:Looks interesting

[Anonymous Coward]

I've been using RoR for a couple of projects (small) the last few months. I've found it capable of running on OSX and M$ well enough. My research has shown the main difficulty for most is in deploying a production install cleanly. However, these problems are likely addressed (search on RoR production deploy for more info) in common deployment scenarios.

As for IDE's.... The "Ruby Development Tool" (RDT) for Eclipse has nice potential! It's home page is: http://rubyeclipse.sourceforge.net/. Naturally, it requires Eclipse.

HTH

Re:Looks interesting

[bloobloo]

I used that tutorial at the weekend - you'll obviously have to setup MySQL yourself but it's a great guide. Use a Subversion repository, and I'm sure Switchtower could be integrated to allow easy deployment too.

Re:Looks interesting

[Anonymous Coward]

Sure it's easy, but the framework itself is a mess. The authors are "extreme programming" types who do whatever they feel like that day; test till it sort of works, and don't document.

Then they tell you to "just read the code, man", which is nearly impossible, since they make extensive use of Ruiby's ability to re-open classes and add/override functionality. At run time. How the hell is anyone ever supposed to figure out what is going on when you write self modifying code?

Re:Looks interesting

[kbob88]

I use it extensively (every day) to develop large, internally-focused applications. Our production environment is Linux Debian, while our development environment is (ugh) Windows.

We use Eclipse with the RDT plug-in for Ruby. It's quite nice. Not as great an IDE as IntelliJ IDEA, but pretty good. There's not much Ruby-specific functionality in Eclipse yet that I can see, but it's certainly better than a basic Windows editor.

We also use PostgreSQL, which has been very nice, stable, and fast. We've never had any problems with it and ROR. We use phpPgAdmin to administer it on production and pgAdmin III to administer it on development, both of which are fairly good database browser/query tools.

So far the experience has been great. More worrying than the tools is ActiveRecord, which has a lot of nice features, but a few really glaring holes.

Re:Looks interesting

[killjoe]

Rad Rails is what you are looking for. Very nice.

Re:Looks interesting

[Anonymous Coward]

Radrails is OK (at least on windows). I thought It would be great but, and I know this is nitpicking, the syntax hightlighting drives me nuts. It's better than it was but I still find it spotty. Sometimes it's a little random and you seem to have to have spaces for the parser to pick things up. Quite fankly, if scite (which I really like) or gedit would come out w/ a built in directory/file browser (ala textmate) I'd be all over it - syntax highlighting there in both is really good.

On linux I like .rb in scite and .rhtml in bluefish. Seems to break up the number of files I have open at any one time into two neat camps.

Another great tutorial, but....

[MrByte420]

The authors of rails books need to stop writing tutorials and write some comprehensive documentation. Even the page is quite lacking.

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', :discard_year => true)

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 :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)

Re:Another great tutorial, but....

[Eil]

The authors of rails books need to stop writing tutorials and write some comprehensive documentation.

This is what pushed me away from Rails not long after I started looking into it. Aside from API guides and the like, all real documentation on Rails and Ruby is outdated or sparse. Sure, there are lots of Rails tutorials out now, plus there's Why's Poignant Guide, but these alone are not nearly enough. The RoR community's answer is, of course, to simply buy the Programming Ruby and Agile Web Development with Rails books.

Right, spend over $50 on books just to see what RoR is all about? No thanks. The authors must be making a killing right now since there really is no other up-to-date documentation for these technologies out right now.

Re:Another great tutorial, but....

[Anonymous Coward]

It's not a manual, but the API docs are very conclusive. In addition to explaining what each component does and giving examples, it answers almost any question, including yours.

"Hmm... a time selector. That's probably related to date_select. Oh, look at that! ActionView::Helpers::DateHelper has a datetime_select function!"

And, if you're wondering why it doesn't have a time_select function, that's because your database doesn't have a time data type either. If you really, really want one anyway, you can use datetime_select, it just takes a little more work.

Re:Another great tutorial, but....

[MrByte420]

Don't get me wrong, the pragmatic progarmmer's book is pretty good, but its sparse in many parts.

Re:Another great tutorial, but....

[MrByte420]

MySQL has a time type. Besides, why does this have to be so difficult. I spent an half an hour on this little conquest for something that I should find an answer for in the index. I was writing a script tracking portal, I really didnt' want datetime, I just wanted time. And I certainly didn't want datetime in my input...

Re:Another great tutorial, but....

[Infernal Device]

The first time I visited the site, there was some sort of video tutorial about assembling a RoR site - which is absolutely useless if you're trying to find real information. That turned me off of Ruby almost instantly. There is a time and a place for video, but when you're trying to understand information and would prefer to go at your own pace, that is not it. I've never looked back - I have little reason to suspect that they've gotten any better.

Re:Another great tutorial, but....

[StandardDeviant]

(Aside: You can get the pickaxe and awdw/ror books for a little under fifty on bookpool.com, fwiw. (I just ordered them yesterday.))

Yeah, it is kind of a bummer to need to shell out some cash up front for texts, but on the other hand:
a) I remember when that was pretty much the case for Perl (Camel Book), and at least I've gotten a lot of mileage out of that investment.
b) to most anyone in IT, $50 is not that much money
c) assume the best case, where RoR really is good for you and your needs, what's the ROI of $50 worth of books vs. spending however much on another platform (esp. something proprietary)? Assume the worst case, and you hate Ruby and RoR. You're not out that much money in the large scheme of things.

The one thing I've found even mildly irritating about Ruby and RoR thus far is that everyone has been using Textmate in their screencasts, which is an editor that I've found ... underwhelming at best. I've seen obvious gui glitches in the thing during my trial period (e.g. turn on the 80 column screen guide, then move the window size around; it leaves a trail of faulty redraw garbage on the screen), the author states he's moving onto the next development tree, and the current version is 39 euro with no mention of the possibility to freely upgrade to 2.0 whenever that comes out (if the upgrade would even fix the bugs!). Bah. vim kicks textmate's ass nine ways to sunday and is free (s/vim/xemacs/ if you happen to swing that way, I'm sure you'd get more mileage out of even that lispy armaggedon than you would out of textmate). This isn't a ruby problem at all, just guilt by association with a crapoid editor. ;)

Re:Another great tutorial, but....

[asdfghjklqwertyuiop]

And, if you're wondering why it doesn't have a time_select function, that's because your database doesn't have a time data type either.

postgres and mysql both have time types...

Re:Another great tutorial, but....

[Fahrenheit 450]

the author states he's moving onto the next development tree, and the current version is 39 euro with no mention of the possibility to freely upgrade to 2.0 whenever that comes out (if the upgrade would even fix the bugs!).

Don't be so lazy next time, and try actually reading the blog entry where the new branch was mentioned...

You may wonder if this will be the 2.0 release, and likely it will. But it will be a free upgrade for all registered users. Though please do not buy TextMate today for what you think may come in 2.0. I make absolutely no promises about what future versions will contain, and I reserve the right to completely change my mind on what it should contain!

Re:Another great tutorial, but....

[Forbman]

At least if you buy the PDF's, Pragmatic Programmers iteratively "develops" the PDFs, so you can d/l a new version at a later date.

Again, how many Java books did you buy, that you rebought after each major Java upgrade, etc.?

Re:Another great tutorial, but....

[Watts Martin]

As a long-time text editor junkie, I actually like TextMate in a lot of ways despite its occasional warts. I've been a Vim user since the late '90s, it's pretty powerful, and you certainly can't beat its price, but the only editor I've seen that really beats TextMate's extensibility through its "bundle" system is XEmacs. (Or GNU Emacs, of course -- I just find XEmacs a bit friendlier.) And TM is considerably easier to extend than Emacsen.

If you like Vim for everything, more power to you; I'm still likely to use it for quick edits, because it's so nice to have a full-featured editor in the terminal window. But for heavy lifting, I like GUI editors, and TM is becoming one of the best ones I've seen. (Lest anyone pipe up with "the keyboard is better than the mouse" arguments, learn to use them in harmony, son. It's not like offering mouse-based selection and commands renders an editor incapable of full keyboard control.)

Re:Another great tutorial, but....

[killjoe]

WTF. Why object to paying 50 bucks for a book? You get a free language, free framework, free IDE, free operating system. Just pay 50 bucks for a book and be happy.

Re:Another great tutorial, but....

[Eil]

Okay, this is the 4th comment that I've received along these lines, telling me to just buy the darn books. Maybe I didn't explain myself well enough when I said that I didn't want to buy the books. I need more than just a few tutorials and API reference in order to decide whether or not RoR is right for me. I'm not in a financial position to throw $50+ down the tube in case it isn't.

From time to time, I'll probably glance at new tutorials, maybe ask some questions in the Ruby community, and prod my employer to splurge on the books.

I understand that Ruby is new (in terms of popularity, not age, of course) and that Rails is still practically in its infancy and that I can't expect there to be tons of free documentation floating about the interweb. But that assurance doesn't help my position any.

Re:Another great tutorial, but....

[StandardDeviant]

Yeah, because blogs are a perfect, intuitive source of product information and nothing ever said in a blog will later change. :)

Re:Another great tutorial, but....

[StandardDeviant]

You seem to be confused, the last paragraph is about Textmate, not about ruby itself or the books about it. (It only came to mind because it seems everyone and their dog making ruby / RoR screencasts is using tm.) (And yeah, the PDF approach by the pragmatic programmers is nice. That the pragmatic programmer guys are endorsing Ruby goes a long, long way with me. I probably wouldn't bother with yet another scripting language were it not for their endorsement.)

Re:Another great tutorial, but....

[StandardDeviant]

Agreed. Probably 70% of my programming time is spent with languages that are succinct enough in form (and well-enough known to me that I don't have to consult any docs when writing them) that a plain, quick editor like vim is fine... It's the Java/XML and XSLT/omgwtflol projects on my plate that make me wish I had something that handled things like easy code completion, tag or syntax auto-complete/balance, intelligent folding, etc. I know that vim can do those things, but they're just irritating enough to set up that I haven't bothered to date. (vim's syntax highlighter for jsp is also real bad last I checked, fwiw.) So right now I'm in vim most of the time, occasionally dropping over to stuff like netbeans.

Re:Another great tutorial, but....

[killjoe]

I don't know what to tell you. I guess ROR isn't for you. Maybe try PHP, there is a lot of documentation there. I was going to say try zope but it's even harder and the documentation is even more outdated.

I guess there is always java. Lost of documentation there if you want to spend all your time typing everything three times.... Customer myCustomer = new CustomerFactory.createCustomer("joe").asCustomer()

Whatever you do stay away from perl though, that way lies madness.

Re:Another great tutorial, but....

[iamdrscience]

The authors of rails books need to stop writing tutorials and write some comprehensive documentation

This is exactly right. Yeah maybe $50 isn't so much for a couple of books, but it's just one more impediment to people learning Ruby/RoR. One of the reasons PHP has gotten so big is because it's got good, comprehensive documentation both for the language and most of it's add-ons (PEAR, PECL, Smarty).

Re:Another great tutorial, but....

[Geoffreyerffoeg]

If religous zealots don't believe in Evolution, then why are they so worried about bird flu?

Because it's the first strain of flu that infects straw men.

Re:Another great tutorial, but....

[bar-agent]

Okay, this is the 4th comment that I've received along these lines, telling me to just buy the darn books.

This reminds me of Invader Zim.

"I want my slaw!"

"You have your slaw, sir!"

"I want my slaw!"

"You have your slaw, sir!"

"I want my slaw!"

"You have your slaw, sir!"

It's good day

[pepicek]

I, for one, welcome our new overlords on Ruby on Rails on Mac OS X (roromoxes?).

Especialy when I hope to be one of them :D.

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.

Usual omission...

[Anonymous Coward]

"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...

Re:Usual omission...

[I Like Pudding]

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.

No, you don't, and no, you won't. There is this thing called "iterative development" and this other thing called "refactoring". Do you write your apps on a stone tablet? This is even more stupid considering that you're lobbing this complaint at a FUCKING TUTORIAL. I know! Let's throw the full complexity of the framework at people who have never used Ruby before! That won't turn people away!

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.

...what? So, in order to be a real framework, I've got to whitelist opcodes and rows in my DB before I actually get anything done? Again, what? This is even more stupid when you consider that Rails has like 10 different third party auth plugins. ModelSecurity would probably tickle your prostate.

Yes you can add-on security to RoR, but it'll always be an add-on...

Bullshit. Access control is trival to add with "before-filter". Even if it wasn't, your statement would still be a lie.

Re:Usual omission...

[JulesLt]

From my understanding of Ruby, the ability to inject security, or logging, into existing classes via meta-programming, rather than refactoring or complex frameworks like Spring, is one of the things people get excited by.

Be interesting to see if this is what Part 2 will demonstrate.

Re:Usual omission...

[An Onerous Coward]

I'm in the middle of writing a fairly substantial website in Rails. The first iteration of the site, everyone could do everything to every bit of data. The second version? I added one line of code to the parent of my controllers:

before_filter :authorized? :except => ['show', 'list', 'index']

The authorized? function redirects users to the login page if they're not already logged in. So the result is, it's trivial to add validation code before every single action that makes changes to the database. If I want to add a function that validates that the person making changes is the person who owns the object being changed, that's one more function and one more line of code. I haven't done it, because it's supposed to be a collaboration tool where people are encouraged to edit each others' work.

You can do similar things to the models, defining actions and checks that have to happen before a database entry can be changed.

I'm really not seeing the point of your rant. If you want security on Rails, it's easy to go from zero security to total lockdown, then back off until the app is functional.

Re:Usual omission...

[Anonymous Coward]

In non-Rails frameworks, does an 'add-on' provide features in a way that makes them cumbersome or distinguishable from built-in features? If so, developers must really hate using add-ons.

Fortunately, the story is different with rails.

Here's an example of a security 'add-on' for Rails written by Bruce Perens (yes, that 'famous' Debian guy):

http://perens.com/FreeSoftware/ModelSecurity/Tutor ial.html

By providing security features in a base class used by controllers, ModelSecurity works in a manner that works seamlessly--as if it was part of Rails.

By the way, add-ons for rails can be via plugins, generators, or engines.

Re:Usual omission...

[Anonymous Coward]

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

This doesn't even make sense...

To simplify:

If your ... framework lets you write something ... without ... explicitly telling the code its okay...

I thought the point of writing code was that it's okay.

Anyway, you are obviously clueless when it comes to Rails. The security model is decent. Maybe not the best, but the framework (and ruby itself) make it easy to create good security. If you build a framework that has awesome security all the time then it will suck to work with, and no one will get anything done. The job of the framework is to meet the programmer half way, which RoR does admirably.

Re:Usual omission...

[Anonymous Coward]

I think you need your diaper changed.

Apple did'nt write this tutorial

[concept10]

from the Rails weblog

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.

Re:Apple did'nt write this tutorial

[Rosyna]

There is attributed on these. They're usually the links in the "See also" at the bottom of the ADC articles when they're not written by an apple person.

Re:Apple did'nt write this tutorial

[Anonymous Coward]

Royna, you might consider actually looking at the page in question before interjecting. There's no attribution...

Re:Apple did'nt write this tutorial

[Rosyna]

Sure there is. The very last link in the content:

Pragmatic Studio offers a three-day, interactive Ruby on Rails workshop.

That's how they are attributed.

For example, Technote 2078 was written by Laurence Harris. His name is in this reference section.

Sadly, technote 2078 is now woefully out of date. The statement Don't pass FSRefs in AppleEvents. Because FSRefs are not guaranteed to be valid across processes in Mac OS X you shouldn't send them in AppleEvents is not true as of 10.4. FSRefs now work across processes (but still not across reboots). FSSpecs are also safe to pass between processes as of 10.4. Both gained this new ability (that Mac OS 9 had) since volume reference numbers are no longer per process.

Not exactly provided by Apple...

[newdamage]

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.

Concise, interesting

[ursabear]

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.

Re:Concise, interesting

[ursabear]

Previous: link to TextMate got munged by post comment tool. Should be: http://macromates.com/ not something from ./ ...

But where would you use it?

[ch424]

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

Re:But where would you use it?

[concept10]

There are many hosts for Ruby on Rails, all you need to do is some clickety, clickety on the wiki: Asia

• FreeOnRails Offers free RubyOnRails hosting with FastCGI support using cPanel/Fantastico - 100 MB space/1 GB Bandwidth. (By India based developer)

• Hardfocus Media Full-service hosting in Japan. cPanel, Ruby on Rails, FastCGI, PHP, MySQL, etc. (Support in English)

• RailsHost.cn We support Ruby on Rails, FastCGI, PHP, MySQL, SSH-access and so on. (Chinese speaking)

Australia

• Hostcentral Australian based hosting provider with full Ruby-on-Rails support. MySQL, PostgreSQL, PHP, Python and Perl support also provided. Melbourne based servers with 99.5% SLA.

• SegPub Segment Publishing is a Sydney, Australia-based company who specialise in standards-compliant web development and FreeBSD-powered web hosting. Supports PHP, Perl, Python, Ruby on Rails (via Lighttpd), Subversion and more.

• WebSpace.net.au Australian web hosting company providing ruby on rails support, as well as support for all the other well known web-development languages (PHP, Perl, Python, .NET). All of our staff are technically minded (either systems administrators or programers), and are committed to bringing you the best support and web-hosting experience possible, bar none!

Europe

• Blackcurrant Hosting Blackcurrant Hosting offers Free Ruby on Rails hosting (FastCGI) with Unlimited MySQL databases. PHP4 & PHP5 also provided, as well as SSH access. cPanel-based hosting. Free--£0/year! We also offer paid plans from £25/Year.

• GsFactory.Net Ofertamos RoR con todos nuestros planes Linux, desde 3.5$/Mes. Ademas de PostgreSQL y JSP/Servlets con Tomcat. Now we offer RoR with our Linux Packages. Starting from 3.5$/Month.

• gradwell dot com Gradwell dot com Ltd (www.gradwell.com) offers ruby on rails hosting, with mysql, ssh access and others like php, mysql etc. Hosted on our own big unix server cluster in London. Customer support provided by a small team of 10 in Bath, South West UK.

• ProInet.se Now offering Ruby On Rails with our standard packages, we are one of the first Swedish hosting companies so offering this. Starting from 10:-SEK/Month for the cheapest package.

• nobudget hoster Now offering Free Typo Hosting! Cheap Plans with full suport. We install evrything you need to runn your Application! We currently provide Ruby on Rails, Symfony and Django, a lot more coming soon!

• Bytemark Hosting provide Linux Virtual Machines from ?15p.m. (this package has 80MB RAM, 4GB disc space and 25GB transfer). This is plenty for supporting a Rails application, MySQL database and lighttpd, and we're happy to use and support Rails ourselves. Plus you get root access; no sharing necessary.

• Happy Gecko - English speaking ISP in Spain 500mb web space, 150 euros per year including PHP, ASP, Ruby on Rails and MySQL support. SSH access also included.

• Hospes.pl : hosting Probably first in Poland hosting service based mainly on PostgreSQL. Offers both fundamental and advanced services for corporate and regular customers. Supports Ruby on Rails, PHP, Perl, CGI, Python

Re:But where would you use it?

[soundofthemoon]

While lots of hosts offer RoR hosting now (Dreamhost, TextDrive, PlanetArgon, etc.), this article is about developing using RoR, not deploying. Many RoR developers use Macs for their development work, and many of them have converted from using Windows because they've seen how much better the development tools are on the Mac. This article does a great job at showing how to get started doing that development.

Re:But where would you use it?

[adamUndefined]

My current hosting company doesn't want to run RoR. Apparently it doesn't play nicely with vhosts. I still plan on playing around with RoR on my own time now. I'm sure if it gets enough momentum behind it then it will become more popular for production use.

Re:But where would you use it?

[kbob88]

Develop on OSX (or anything else...), run production on Linux. That seems to be the standard modus operandi.

We use a Xen virtual private server (VPS) RimuHosting for production. The guys there seem very knowledgeable about running Rails (at least for a web host). They set up everything for us. Plus, it's nice having total control over everything on your server; even root access.

We tried a host that offered just a shared environment (A2), but Rails would hog the CPU and memory like crazy. And they wouldn't let us run FCGI in a shared environment b/c they said it didn't play nice with others. So we had to run SCGI which wasn't stable. It was a major pain, and I wouldn't recommend a shared environment for any production Rails app that gets even modest usage.

Because nobody wants to be a LAMR

[balls199]

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

Re:Because nobody wants to be a LAMR

[Anonymous Coward]

Am I misunderstanding you, or are you really saying that you chose (and will stick with) OS X for doing Ruby on Rails specifically to avoid the LAMR acronym?

Wow. That's lame.

Re:Because nobody wants to be a LAMR

[balls199]

Actually, (for those who couldn't tell) it is just a joke. I'm sticking with OS X because I currently have a nice development environment for RoR set up on it, and, more importantly, it's what I have.

Besides, isn't OSXAMRoR a much nicer acronym?

Re:Because nobody wants to be a LAMR

[Psycosys]

Hmmm, what about Linux-Apache-Ruby-Postgres. Ahh, but then I guess you'd be a LARPer.

what's so special about RoR?

[Anonymous Coward]

I'm not trying to flame or Troll here but I would like to know what the big deal about RoR is? What can it do that PHP or Perl/Mason can't? Is it just super easy web/db development? The reason I ask is I'm looking for a new language to learn this year and I'm torn between Python and RoR. I'm already fairly adept at interfacing both php and perl with mysql, what advantages are there at choosing RoR? (I'm not looking for because it's cool... I want to know if it's just hype or if RoR is useful enough to ditch PHP)

Re:what's so special about RoR?

[oni]

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!!

Rails users, evangelize

[suzerain]

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?

Re:Rails users, evangelize

[trosenbl]

I am not an expert.

Rails is a framework on top of ruby that handles things for you in a default fashion ("convention over configuration" they say). But, because of the way it and Ruby are designed, you can override the default behavior. The thing is, when 9 out of 10 projects can use the default behavior, there's much less effort required, so you'll have time to do more complicated things.

However, once you've gotten your, say, form input, you can use Ruby (a fully object-oriented and Turing complete language) to modify it just the same way as you would in any other language (although I would argue that Ruby makes even this part easier too).

Look at it this way, Rails is a bit of a toolbox. Can you tackle any woodworking project with your toolbox? No. But, 90% of the time, your construction projects can be done with the basic hammer, drill, router, etc.

Re:Rails users, evangelize

[digidave]

Give it a try and you'll find it can meet just about any needs. The HTML templates are something like JSP where you drop your data into an HTML page, so there is no limit on RoR site designs.

You'll find that most of the time Rails' data handling makes your life much easier than other frameworks. When Rails doesn't quite make the right decisions about your data you can always override the default functionality with the same or less work than would be required using other frameworks.

In my opinion, Rails is a no lose situation. Actually for me coming from a PHP and Java background it's an always win situation. I get Ruby, which is a better language than PHP or Java, plus I get Rails, which is the best web app framework I've ever worked with.

Re:Rails users, evangelize

[Peter Cooper]

I'm a bit too busy to go into any depth, but Ruby can be a very 'meta' language (much like LISP or Smalltalk) and it's easy to override almost anything, so dealing with special cases is pretty easy.

I've developed some pretty large scale things with RoR that required a lot beyond what the framework offered, and it's been fine.. although in hindsight I can see how I should have done things a bit different. That's mainly due to a lack of knowledge of Ruby rather than Rails though. Ruby is a lot more powerful than the quick demos show, even if Rails is not.

Re:Rails users, evangelize

[finnif]

Hey Ruby/Rails users...giving you a chance to evangelize

Don't worry, they've taken that chance for about a year now... trolling on every Java board and blog around.

Re:Rails users, evangelize

[Anonymous Coward]

you could go to http://rubyonrails.com/ and scroll down a little bit to see fancy looking sites that use rails.

Rails is OK, but exposes too much SQL

[YetAnotherName]

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!

Re:Rails is OK, but exposes too much SQL

[dana_virtual]

Warmly thanking you for the moov URL reference. It's certainly one of the best dynamic bake-offs I have yet seen. Although primarily a Python programmer, I came away with a reasoned and (I believe) impartial assessment from someone with no axe to grind. I certainly agree with the overall assessment that Java does not provide a decent basis for web enabling the user experience.

It certainly proivided a full course meal and very little evangelising. Thanks again for pointing this one out

The right tool?

[ErikZ]

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?

Re:The right tool?

[digidave]

"I just want to use CSS, and plug the whole thing into a database."

I'm confused. CSS works with HTML to do page layout. Ruby on Rails uses template which are written in HTML and CSS just like any other web page.

As far as just plugging it into the database, I suppose Rails is as close as you're going to get unless you just want to use a Content Management System (try joomla if you want a CMS). With Rails you build your database backend, then create a few lines of code to have Rails pull out the data and put it into the template. You can use the scaffolding feature to quickly create input forms, which might work fine as-is if you just want a quick way to drop text onto the site.

Re:The right tool?

[stridebird]

Yeah, well, when you have finished comparing the comparative merits of RoR against the other options and find yourself carried along with the fresh-faced apple-shaped enthousiasm that it's riding on, go check up on your hosting. RoR is so ready for the maintime that it runs on, ooh, er, well your Mac basically.

Unless you have good control over the hosting environment, you can't deploy it.

Where is the apache dynamic module for this? And don't say it's FastCGI. It has to become as readily available as PHP in the hosting environment before it moves into the main stream.

I could be wrong. Just seems to be something they gloss over when they are talking it up.

Re:The right tool?

[An Onerous Coward]

There are quite a few (relatively cheap) places that will host Rails apps, and if you're doing something substantial enough that you can justify renting out your own box at an ISP, then it's not a problem either.

The tricky middle ground is the one where someone is happy with their current ISP setup, but would like to add a Rails app. Then you have to decide whether the language is promising enough to justify a change. Usually, it doesn't, so people go back to what they were doing before.

Me, I've got my own little box and a very understanding ISP. I'm happy.

Comment removed

[account_deleted]

Comment removed based on user account deletion

I'm trying to learn RoR, but I have some issues

[jocknerd]

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).

Re:I'm trying to learn RoR, but I have some issues

[concept10]

You would want to use migrations for a variety of reasons:

* Get away from the verbosity of SQL - define your schema in Ruby

* Migrations are "database agnostic"

* Version control of your schemas

I didn't understand the benefits at first, but after I started using them, I can't go back to SQL.

It also makes your application easy to deploy, for example: You have a make a open source app, you want configuration and deployment to be as easy as possible. You define your schemas using migrations and the users basically create the databases, configure the /rails_app/config/database.yml and run 'rake db_schema_import' and they are set!

Re:I'm trying to learn RoR, but I have some issues

[mini me]

Why use the migration?

Because migrations...

• are database independent
• handle schema versions automatically
• are written in Ruby

The real question is, why not use migrations?

Re:I'm trying to learn RoR, but I have some issues

[soundofthemoon]

The AWDR book from Pragmatic includes material on creating an admin interface to the Depot application. I've found that to be a useful starting point for my own efforts. Chad Fowler's upcoming Rails Recipes book also has information on authentication. There are also a good number of auth plugins to be found on the wiki (wiki.rubyonrails.org), though I've found that it's simple enough to roll your own.

Once you've worked out your authentication, it's pretty easy to use scaffolding to create the basics of your admin interface. I will create scaffolds for all my tables in an admin/ module, and include authorization for all access to those scaffold controlers. That's about as much as I want from a standard admin interface - anything more than that will be constraining my app by the assumptions it makes about how it runs.

If you are looking for automation to help control your app in production, check out Switchtower. It is an excellent tool for remotely managing your app's deployment and operation in production.

Re:I'm trying to learn RoR, but I have some issues

[killjoe]

During the snakes and rubies talk david was asked about admin interfaces. He said something like "ROR doesn't really need one because there is a shell and you can work directly with activerecord objects from the shell, this is better then an admin screen".

His take is that you can work right inside the framework using nothing but ruby to manipulate your activerecord objects. This should be better then directly manipulating your tables because theoretically your activerecord objects keep your relations, validations etc so your data doesn't go wonky because you are directly editing records. I think there is something to that although I think it would be nice to be able to do that through the web too.

Re:I'm trying to learn RoR, but I have some issues

[killjoe]

"* Migrations are "database agnostic""

As long as your database is mysql. If it's anything else you have to take your chances. Postgres is supported pertty well, everybody else can go fuck themselves because it won't work at all.

Re:I'm trying to learn RoR, but I have some issues

[telbij]

lease somebody point me to a comprehensive step by step tutorial that details the creation of an administrative side of a web application.

The book's tutorial was pretty comprehensive wasn't it? I got about one third of the way through before I just flipped to the back and read the meaty sections. After that the API docs were mostly good enough. If you're new to web development then it may help to spend a few years writing web applications in PHP or Perl without a framework to understand why things go where they do in Rails. You'll also do well not to shortchange Ruby itself, but learn the language in depth so you understand where Rails is coming from and how stuff really works.

Why use the migration? I prefer to create my tables with good ol' SQL saved to a text file.

So that you can automatically update your application without overwriting your data or some brittle dump/reimport script. Also gives you the ability to rollback changes automatically with switchtower in case something breaks on your production server.

Right now they are a little weak with non-MySQL dbs, and you have to learn a little syntax, but if you want to be able to do things like release a new version of your web app every week then migrations are invaluable.

Compared with Django, RoR doesn't cut it.

[Qbertino]

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.

Re:Compared with Django, RoR doesn't cut it.

[usidoesit]

yeah! went to the page, checked it out. BTW, lot's of existing net infrastructure is written in Python, like mailman etc. So you can get paid to do it, and there's stuff you can use. Nothing is written in Ruby.

Because...

[Hamhock]

... 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.

Too much SQL?

[archeopterix]

Can you expand your point about exposing too much SQL? My worst experience with a framework was with J2EE entity beans (EJB ver. 2.0.) - the persistence layer that tried to hide the SQL only to reimplement it totally half-assedly. The EQL sucked a big time:

- 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?

Re:Too much SQL?

[CountBrass]

Uhm, what would be the point of re-implementing SQL? Both Hibernate (for Java) and RoR allow you to make SQL queries for none-OO type functions, eg mass updates/deletes, aggregations etc.

I thought it sounded familiar

[el_womble]

I hope they've told this guy about this new article.

screencast???

[Anonymous Coward]

Why the fuck do we need a new fucking name for a movie. Jesus Christ it's just a fucking .mov file!

Re:screencast???

[Anonymous Coward]

mod parent insightful

Re:screencast???

[Geoffreyerffoeg]

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".

Wish they'd spend this time patching bugs

[GekkePrutser]

Great!

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 :) And yes, I am a programmer myself. But if I wanted to program in Ruby I'd probably have found a tutorial somewhere already.

P.S.: This is not intended as a flame, just as a question where Apple's priorities lie.

Re:Wish they'd spend this time patching bugs

[bloodmusic]

Now that he's through with the tutorial, I'm sure he'll get back to the security problem. Then it's on to the next version of OS X, keeping the company's books, and emptying the trash cans. He's really quite busy.

Re:Wish they'd spend this time patching bugs

[99BottlesOfBeerInMyF]

Umm, the guys who write Web development tutorials for Apple are probably not the same guys that code the OS and applications. This tutorial wasn't actually written by Apple, they are just distributing it. You know the guys in finance are still working on accounts and haven't stopped to try to fix bugs in code either. I've been annoyed by Apple's weird handling of metadata versus extensions since they announced it but you are way off base in complaining about this as if it had some relation to security issues.

I'm Shocked !

[Anonymous Coward]

This is all about Ruby, which is a programming language! Everyone knows you aren't programming a Mac unless you're slogging along with XCode.

So, is this Rails things really official? I wouldn't want to get in trouble.

J2EE

[hotsauce]

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.

Re:Figures

[Decaff]

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.

no Locomotive love?

[cygnus]

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.

Python?

[Anonymous Coward]

But google uses python. Whats wrong? Python is dying because of its boring board of directors? Missed the train?

Ruby vs. ?

[ratboy666]

So, please elucidate.

What makes Ruby "lightweight" as compared to Smalltalk and ObjC?

I would argue that Smalltalk is "lighter" than Ruby.

Ratboy.

mod parent up

[adpowers]

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

WebObjects

[macserv]

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.

Re:WebObjects

[ltmon]

I guess because Rails simply provides another option. In this case one of the differentiating factors is mentioned in the parent post. The rails crowd are very anti-tools... anything that needs a big IDE and not just a text editor is too complex by half. Both points of view are valid, but choice is good isn't it? L.

Re:WebObjects

[Anonymous Coward]

Maybe it's because it's only free to develop with. It costs big money to deploy.

Re:WebObjects

[simoncoles]

I tried to like WebObjects, I really did. But it never seemed to work properly on my machine, always some bug or another. I bought the books, wrote a few small apps - and never seemed to be getting anywhere. That, combined with the fact that it clearly isn't getting any investment from Apple and the community is small (compared to other app servers & frameworks), made me very reluctant to invest more of my time. Ruby On Rails however "just works" (thanks, Locomotive!, clearly has a future and vibrant community, and does exactly what I need (rapid development of in-house web apps). Yes, WebObjects is nice - in theory - but in practice unless Apple's prepared to invest in it's future, I wouldn't start any new projects in it.

Re:Figures

[An Onerous Coward]

I bow before your masterful buzzword-fu. You must have great hair. Will you teach me to leverage my competitive synergies?

Hey, What about Catalyst

[holy zarquon's singi]

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.

Re:Figures

[unDees]

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).

mysql wide open?

[J. Random Luser]

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...

Which J2EE?

[MacDork]

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?

Re:Figures

[gigahawk]

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.

Re:Figures

[Decaff]

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.