Ruby On Rails Goes 1.1

MrByte420 writes "The Ruby On Rails team today released version 1.1 of the web framework. From the announcement: 'Rails 1.1 boasts more than 500 fixes, tweaks, and features from more than 100 contributors. Most of the updates just make everyday life a little smoother, a little rounder, and a little more joyful.' New features were examined back in February at Scottraymond.net and include Javascript/AJAX integration, enhancements to active record, and enhanced testing suites. Not to mention upgrading this time promises to be a piece of cake."

Comments

Let me...

[irimi_00]

Let me be the first (or not) to say congrats to the dev team. I am sure this will make it easier to connect people, make money, and functionality online.

Ruby Tutorials

[emo boy]

http://www.digitalmediaminute.com/article/1816/top -ruby-on-rails-tutorials

Re:Ruby Tutorials

[Radres]

So if you're currently a Java rich client programmer, with no J2EE experience, how can you get a job as a Ruby coder (other than inventing a site to implement for yourself)?

Re:Ruby Tutorials

[BoRictor]

You write a book about it and speak at conferences extolling the benefits of moving from Java to RoR.

Re:Getting started

[Noer]

First, despite what some people say, I think you really have to learn the Ruby language first. Yes, you can get by coding 'by rote' but a deep understanding of this really elegant language will help a lot. Second, there are some great tutorials at the Ruby on Rails site but I think the best is the Agile Web Development with Rails book, though it hasn't yet been updated with the new Rails 1.1 features.

Ajax a welcome addition

[FecesFlingingRhesus]

It is nice to see them add the AJAX / JavaScript integration. I would like to see more frameworks include a mature AJAX framework to facilitate more dynamic interaction. To date the best I have seen so far is Echo2 which incorporate an event driven architecture that allows for seamless integration of client side events transmitted to the server side architecture. In all good show, I hope more frameworks will follow suit.

Re:Ajax a welcome addition

[FecesFlingingRhesus]

No I design web-based enterprise systems, I make it my job to evaluate all possible framework options.

Re:Getting started

[Anonymous Coward]

Programming Ruby - a free ruby eBook - http://www.rubycentral.com/book

Re:Getting started

[BioCS.Nerd]

This is a good place to start: http://poignantguide.net/ruby/ and then perhaps this: http://www.pragmaticprogrammer.com/titles/ruby/ (Either one is good -- I used the latter)

Or, if you're on the lazy side of things, you can try it right within your browser here: http://tryruby.hobix.com/

I hope this helps.

Re:Getting started

[moochfish]

Not trying to insult or anything, but did you RTA? I believe the TFA points to the ruby on rails website which has plenty of resources. One of the links across the top labeled "screencasts" even has videos you can watch.

Re:Getting started

[gavri]

The book is Programming Ruby. That's the second edition.

The first edition is available online. You don't need to buy the second edition unless you are really serious about learning Ruby. The first will do for evaluating the language and playing around with Rails. And if you really want to learn Rails (after going through the tutorials), Agile Web Development with Rails is the book I recommend.

Re:I haven't heard much

[davecrusoe]

To me, an intermediate PHP coder, it seems like a great way to move forward with developing new apps. Lots of redundancy in my PHP, and so I'm seeking a simpler, more elegant solution. Of course, that's partly due to my non-expert programming skills, but I'm switching over nonetheless. So, I guess you could say that it's gaining a following. The question is, as you point out rightly, how many sites have used it in their framework?

Perhaps there's no good answer, as commercial hosts are only now finally intergrating the Ruby code into their servers. But that they've elected (for example, Site5, my own host) to include the Rails in their hosting options seems to indicate that it's growing...

Re:I haven't heard much

[tcopeland]

We're using it for indi with a PostgreSQL back end. It's working pretty well so far, even with a Jabber server hitting the same database.

Re:Getting started

[SmallOak]

the Ruby doc site http://www.ruby-doc.org/

and yes go for the chunky bacon http://poignantguide.net/ruby/

Javascript is insecure - AJAX is security hole

[billstewart]

Sigh. Rails is joining the list of things that encourage people to use Javascript applications, just as all the AJAX stuff does. So anybody who's using those applications has to toast their security.

The problem isn't that you can't write secure Javascript code - you can. The problem is that if anybody wants to *use* your nice secure AJAX/RAILS/etc. application, they need to turn Javascript ON in their browser, which means they're vulnerable to maliciously-written Javascript on any other web pages they visit.

There's no easy way around the problem if you want to run the new cool AJAX applications, and there's a lot you can do with a programming model that makes it easy to distribute functions between the client and the server. For Mozilla users, it's probably possible for somebody to implement per-site permissions for Javascript the way they do for cookies, images, etc. For IE, though, you're just toast.

Re:Javascript is insecure - AJAX is security hole

[gregarican]

Ever heard of using the Trusted Sites list in Internet Explorer? seems to work for me for per-site permissions.

Re:Javascript is insecure - AJAX is security hole

[Dan Ost]

If you're already running Firefox, the NoScript extension is a simple way to protect yourself from what you just described. I would also expect other browsers allow you to white-list specific sites (though maybe not as easily as NoScript).

Re:Javascript is insecure - AJAX is security hole

[TrancePhreak]

For Mozilla users, it's probably possible for somebody to implement per-site permissions for Javascript the way they do for cookies, images, etc. For IE, though, you're just toast.

IE already impliments settings that allow you to whitelist sites for scripting. So by your meaning, Mozilla is toast.

Re:Javascript is insecure - AJAX is security hole

[ceejayoz]

And images expose you to things like the WMF exploit, so let's just go back to the 1980s of web design.

Re:Javascript is insecure - AJAX is security hole

[syphax]

Mod parent up; for a small inconvenience (you have to add each site to your whitelist with 2 clicks), NoScript provides a lot of protection. It also shows you how much fricking code is pulled from other domains- scary. The page on which I type this pulls code from:

slashdot.org
google-analytics.com
2mdn.net
questionmarket.com
falkag.net
and good ol' doubleclick.net

NoScript lets you select which code to run, and which to ignore. Inconvenient but awesome.

And somewhat on-topic, check out siteadvisor.com

Re:Javascript is insecure - AJAX is security hole

[Bogtha]

The problem is that if anybody wants to *use* your nice secure AJAX/RAILS/etc. application, they need to turn Javascript ON in their browser

If that's true, then the Ajax/JavaScript support in Rails is severely broken. Properly written JavaScript degrades gracefully, so that the people who have JavaScript enabled get the benefits of it, but the people who have JavaScript disabled can still use the application.

Can anybody who's used this new part of Rails comment on this? Does it really generate JavaScript that doesn't degrade gracefully? If it's true, then my opinion of Rails just plummetted.

Re:Javascript is insecure - AJAX is security hole

[Krimszon]

The problem is that if anybody wants to *use* your nice secure AJAX/RAILS/etc. application, they need to turn Javascript ON in their browser How many people have turned js off?

Re:Javascript is insecure - AJAX is security hole

[gregarican]

We're not talking about you (i.e. the context of a web applications developer). We are talking about the general public using a website containing AJAX-delivered applications. And, hate it as you might, the majority of website visitors are still using Internet Explorer. And proposing a patch for the Javascript hole in IE is the point of my post...

Re:Javascript is insecure - AJAX is security hole

[zardo]

Do you wear a football helmet when you drive? Just curious.

Re:Javascript is insecure - AJAX is security hole

[metamatic]

The easy way around the problem is per-site JavaScript permissions. Internet Explorer has allowed you to set up your browser like that for ages, I'm surprised Firefox isn't the same way.

Still, there's a plugin for it...

Re:Javascript is insecure - AJAX is security hole

[Tyrant Bob]

This is the fear based thinking that has lead to lack of development/appreciation of javascript over the years. Any useful technology has security issues, but you have to weigh them against the benefits. Javascripts holes are so minuscules that they do not even merit mentioning. Turning javascript on is more secure than surfing with Internet Explorer, so stop complaining about a non-problem.

Re:Javascript is insecure - AJAX is security hole

[nuzak]

Out of the box, rails doesn't add any javascript at all. The fact that when you do use the javascript generation, the fact that it's so closely tied to prototype .js is my main problem. Got a method or attribute called "extend"? Too bad, prototype owns it. Nice use of namespaces, fellas.

Re:Javascript is insecure - AJAX is security hole

[TodLiebeck]

First let me say that I'm the lead developer of Echo2, which absolutely requires JavaScript in order to function, so please take that into account as a bias if you desire.

I disagree with the statement "JavaScript is insecure". Implementations may be insecure, but the specification itself has no such problem. There have certainly been security holes discovered in JavaScript implementations. There have been equally dangerous security holes discovered in other aspects of the browser.

My other question to the "disable JavaScript" camp is, "what do you propose as an alternative?" Flash, client-side Java or any similar technology has the same security concerns as client-side JavaScript. The answer of "just use plain HTML" is not a solution. JavaScript and this "AJAX" stuff is not just about adding bling to applications--it's about eroding the barrier between remote and desktop applications.

Re:Javascript is insecure - AJAX is security hole

[21chrisp]

Ajax components don't degrade quite as gracefully as standard JS does. There just isn't any getting around this for Ajax apps. Rails does include degrade functionality for Ajax though. The difference is that the developer must add checks for this functionality. You will also need to add Ajax and non-ajax versions of pages for this to work. An Ajax page will only contain the html of the element that gets updated. A non-ajax page will contain all of the html for that page (at least that which is not in the layout.. but that's digressing..)

This can add a lot of extra development time though, so you really need to consider that before going down the Ajax route. All-in-all.. Rails makes ajax much easier than other frameworks (IMO), but you still need to cover the extra bases.

In practice, I shoot for 90% functionality for non-ajax mode Meaning that the user will be able to use a majority of the site w/o JS, but the experience will be a little more limiting. It's rarely noticable to user. This is similar to the Gmail aproach.

Re:Javascript is insecure - AJAX is security hole

[Bogtha]

Ajax components don't degrade quite as gracefully as standard JS does. There just isn't any getting around this for Ajax apps.

No, you're mistaking common practice for inherent flaw. There's nothing general to Ajax that precludes graceful degradation; Ajax is standard JavaScript, and the techniques used for graceful degradation are just the same for Ajax as they are for any other JavaScript.

Rails does include degrade functionality for Ajax though. The difference is that the developer must add checks for this functionality. You will also need to add Ajax and non-ajax versions of pages for this to work.

That doesn't sound like graceful degradation to me, that sounds like mid-90s browser detection and branching. Is there an example available? I find it hard to believe it's this awful after hearing so many good things about Rails.

Re:Javascript is insecure - AJAX is security hole

[Overly Critical Guy]

That depends on the developer. Rails is just a framework of APIs. Using respond_to, you can give a response based on what's enabled in the browser.

Re:Javascript is insecure - AJAX is security hole

[Overly Critical Guy]

Or, use respond_to and deliver content through AJAX or non-AJAX through the same action.

Despite that, I think it's time to get over it--scripting is a part of the World Wide Web. The whining about JavaScript reminds me of the whining about PDFs that always occurred on Slashdot a few years ago, which thankfully has mostly disappeared. Everyone stupidly assumed because Acrobat was slow, PDF was slow. Nope, Acrobat was slow because it loaded all its plugins on every startup, which Adobe stopped doing in the latest version.

Re:Javascript is insecure - AJAX is security hole

[Glog]

Bill, don't forget eating cookies causes browser cavities as well!!

Re:Javascript is insecure - AJAX is security hole

[pstreck]

while javascript can be potentially dangerous, a properly secured system will prevent most malicious javascript from doing any serious harm. of course, there are always new flaws that may allow access to admin level items, this is no different from any other network service running on a computer though.

Re:Javascript is insecure - AJAX is security hole

[billstewart]

> Do you wear a football helmet when I drive?

No, though I do sometimes wear a baseball hat. But I *do* close the car doors, hood, and trunk lid when I drive, with occasional rare exceptions when I'm hauling bulky objects, and occasionally a door doesn't get latched successfully and comes open by itself. .

Re:Javascript is insecure - AJAX is security hole

[billstewart]

Safe versions of scripting would be just fine. Java's generally fine, but all the JavaScriptKiddies go whining about how overweight and clunky it is :-) Gosling et al. went to a lot of work making sure it had a security model that would make it safe to use, even if that sacrificed a bit of functionality in the process. Would it have been powerful enough to do the same things AJAX does?

And no, I don't whine about PDFs, I bitch about them, like I do about people using Flash for navigation when hyperlinks or imagemaps would work just as well. Acrobat does seem to work better these days, at least when I'm running it on a 2 GHz PC with adequate amounts of memory, and has some basic cut&paste features for text, and the annoying limitations of deploying text as PDF-flavored Postscript are deliberate choices by the people who use them, so it's malice, not incompetence...

Re:Javascript is insecure - AJAX is security hole

[billstewart]

First of all I agree with you that client-side scripting can give you a huge amount of flexibility and improve application performance by letting you choose appropriate divisions of labor between the client and server sides of your network. I was working with people on problems like that in the early 80s back when graphics workstations were complex purpose-built boxes, Sun's NeWS did some really amazing things in the mid-late 80s (and because it was based on Postscript, it gave you really good control over what you drew on the screen, and what you saw really was what you got and what you wanted, and it was occasionally blazingly insecure and unstable as well), and Gosling used a lot of the lessons he learned from NeWS to develop Java.

And while 95% of the Javascript out there really is bling, the new AJAX stuff has let people build some really cool stuff.

But I disagree that Javascript has the same security models as Java - Java was built from the ground up with a security model that was critical to its deployability, while Javascript started out lightweight and had lots and lots of bandaids added to a fundamentally unsafe platform. Java has had the occasional implementation bug, which gets fixed, but the security model has been solid and secure - at the cost of being heavier-weight and sometimes slow. Javascript may be friendlier, and the bandaids do help a lot, but it's still simply Not Safe.

Re:Javascript is insecure - AJAX is security hole

[tacocat]

To put it simply, that's there problem.

It might be argued that one of the main contributions to Microsoft Windows success in the 1990's is their execute of ease of use and simplified interface for the users to experience. This has been continued despite an indefensible failure to take security seriously. And yet they continue to grow.

Given Microsoft as a success story, if you have a well written and therefore secure javascript application/website then you have the advantage of ease of use and simplifed interface for the clients and have actually surpassed Microsofts history of security.

I would say you are well ahead of the game.

Anyone who is serious enough to turn of javascript on their shiny new IE has probably already realized that they would be better off to just run with one of the alternatives. Anyone who doesn't know better still has javascript enabled on their MSIE browser.

So don't worry about it, it's not your problem.

Re:Javascript is insecure - AJAX is security hole

[lonecrow]

Sounds like a call for someone to write a FireFox extension that allows you to specify domains for which you will allow Javascript. Just like exceptions for cookies. If I had the time...well hell maybe I'll give it a go.

Re:Javascript is insecure - AJAX is security hole

[zardo]

occasionally a door doesn't get latched successfully and comes open by itself

You're going to get yourself killed!

What you should do is weld the doors shut so that nobody can get in OR out. Two birds with one stone, you see.

Re:Javascript is insecure - AJAX is security hole

[soulhuntre]

IE already impliments settings that allow you to whitelist sites for scripting.

You're bringing facts into this discussion. Clearly no one here wants that.

Re:Javascript is insecure - AJAX is security hole

[rnd()]

dude, what are you smoking?

Ajax sites dont have to be the least bit insecure... unless you code them that way. Rails makes it VERY EASY to code a secure Ajax app... RTFM

You are obviously just in a crabby mood and trying to start a flame war.

--
You can't teach an old dog new tricks, but you can let him out when he starts complaining about Rails.

Re:Javascript is insecure - AJAX is security hole

[baadger]

If you're paranoid about using Javascript, and want to use it selectively, more power to you. As others have already pointed out there is an extension for Firefox and IE natively has the Trusted Zone...but hey i'll cover the last base on Windows...Opera.

The 9.0 beta Opera builds available at the Opera desktop team blog all have per site preferences for everthing from cookies, referer logging, javascript, java and other settings.

Re:Javascript is insecure - AJAX is security hole

[sporkmonger]

Ever hear of degradable javascript? It's not built into Rails by default, but it's a popular technique among the Rails people nonetheless. Basically it means that the site works even if your visitor is irrationally paranoid or happens to use a crappy browser. It just doesn't have all the whiz-bang stuff and falls back on normal html form and anchor tags instead. I use the technique in all of my Rails sites and it works like a charm. (Also, whoever wrote the Firefox web developer extension that lets me switch javascript on and off so easily, thank you! It's a godsend!)

Re:Getting started

[gavri]

I'm not sure what you mean by a website that can show off what the language can do. Ruby, the language is independent of the Ruby on Rails framework.

But if you do mean that you want to see Ruby executed, an online interpreter is available.

If you're asking for examples of what Rails can do, it can do only what you can do using any other language on the server-side, only much faster and with cleaner code.

Rails is Great

[nashjobs]

It allowed me to develop this job website in 2 1/2 months spare time with 400 unit/functional tests. I was a Java programmer, and now there's no going back ;-)

Any other former Java programmers relate?

Re:Rails is Great

[Anonymous Coward]

I am still a java developer until someone starts to pay me to do rails fulltime. But, yes, I am doing rails in all my consulting and side work now...as well as all my personal apps. So, java still pays the bills but ruby/rails is the way of the future for me.

I equate it to the java transition that happened some years back....i have to still do java until the industry starts to realize the power of rails, just as I had to do C until they started to use Java.

Re:Rails is Great

[StarvingSE]

I see your site says beta, are you a former google employee?? ;)

Re:Rails is Great

[destiney]

You might add an entry to routes.rb and get rid of those fugly category URLs.

Just a thought..

Re:Rails is Great

[catch23]

One thing I like about Rails (or Ruby in general) is that you can have a relatively short turn-around time since Ruby is interpreted. In the old Java & Hibernate world, I'd have to run xdoclet for every new field in the database, re-compile with javac every time I added more functional code (either in the model or controller), or reload tomcat every now and then.

However with Ruby + Rails + Ruby & Rails Eclipse plugins, I almost never need to sit around for more than 2 seconds to see my generated output. I can quickly make a quick modification in model code and immediately see the effect by pressing the reload button on the web browser. I'll also say, the default debugging output of Rails is a lot easier to read than the default debugging output generated by Tomcat & faulty jsps.

After working with Hibernate for a good 3 years, I can say that it is sometimes nice to develop your database schema first rather than develop object mappings that will generate the schema. The whole "automated naming convention" also removes the possibility of a neophyte programmer to come along and create some ugly get/set methods with side effects.

Re:Rails is Great

[Philodoxx]

I'd argue that designing schemas, and designig object mappings are the exact same thing. Whatever you make your schema is is still defining the relationships that make a database work.

Re:Rails is Great

[Dukhat]

One thing I have noticed during the refactoring of php apps or python apps with more than 50,000 lines of code is that it is very hard to find all the places a function or variable is referenced in a scripting language. Even if you have unit tests for every function in your code, your tests probably don't cover every branch of every unit test. Using grep works fine if the function or variable has a unique name, but if I am looking for a contact's role, I may be looking for contact.role or c.role or cont.role. Bleh!

In a compiled language, I find out every place that is affected by the change in my objects' interfaces. Of course, strict type checking doesn't protect me from breaking things do to logic changes, but it does make refactoring large projects much less unwieldy. I definitely am more productive creating new code in a scripting language, but I think scripting language developers should be aware of difficulties that they will face once it is too late to switch to a different language.

I really wish that scripting languages had some sort of interface checking. Instead of checking the type and requiring you to extend the right combination of classes and interfaces, it would be nice if the scripting language warned you up front that a function is going access the "first_name" attribute of an object, so passing in an integer is not going to work.

Re:Rails is Great

[catch23]

Unfortunately, when you get deep into hibernate development (and have around 100 persistable object types) doing the database design in xdoclet mappings just doesn't cut it. You have an urge to just go to the database and do it yourself. Hibernate tries to (rightfully) hide a ton of behind-the-scene legwork which only contributes to productivity on large object models.

Re:Rails is Great

[catch23]

Just because Ruby is a dynamically typed language, it does not make the language a "scripting language". Look at the Smalltalk/Squeak system. The Squeak system has probably near 1-2 million lines of code. I would not call the Squeak system a "scripting language". Just because historically statically typed languages have been all compile-time languages, that does not mean in the future that there may be dynamically typed compile-time languages.

Re:Rails is Great

[scragz]

And add the required title tag to your pages. I'm not asking for full standards zealot level compliance, just a title tag; it's important.

Looking to get started in Rails?

[RunFatBoy.net]

Along with the API documentation, I found the book "Agile Web Development with Rails" highly beneficial. For a while there, it was the only definitive, concise source of Rails examples.

Even if you're skeptical of the Rails hype, I encourage any developer worth their salt to sit down with it for a weekend. The whole concept of convention over configuration can be a bit mind bending, especially if you're use to Java's XML hell. It's always beneficial to force your brain to adapt to new languages; it encourage contrarian thinking when considering new solutions.

Jim http://www.runfatboy.net/ -- Exercise for Web 2.0.

Re:Looking to get started in Rails?

[bahwi]

Agreed, no online tutorial did it for me, just made me look away. Then I read "Getting Real" from 37signals (look it up, a pdf book, cheap and worth it but I'm not their advertising co and it's easy enough to look up). That made me get Agile Dev w/ Rails after 3 bookstores to find it(It's not catalogued with Ruby books since it doesn't say Ruby in the title, so be careful!) and sat down and went through the first bunch of chapters pretty quick.

The thing I like especially is the unit testing, still getting my brain around it though.

Re:Looking to get started in Rails?

[catch23]

Ruby is a pretty nice tool, I do think it has far too much hype however. The hype is almost as bad as AJAX.

Re:Looking to get started in Rails?

[catch23]

One of the things I really liked about Ruby was the RubyGems project. It's sorta similar to Maven in the Java world in that it will go out and fetch additional package dependencies for software. I think Java really needs some kind of semi-centralized repository of open source packages so that one does not have to go through the trouble of reconfiguring packages all the time. My current project at work uses over 30 lgpl licensed projects and it's one big pain in the butt to upgrade these packages all the time. We software people need apt-get!

Re:Looking to get started in Rails?

[rho]

I've seen a thousand links telling me "here's a great place to learn about Ruby-on-Rails". I haven't seen one link that tells me why there's a compelling reason to drop everything I'm doing and refactor all my work into this fledgeling framework.

On a bang-for-buck analysis, it's better to lace together OSCommerce, phpBB2, and one of the random CMSes in order to produce an actual workable Web site that, you know, does something.

Everything that is "typical" has already been done, and debugged, by other projects. Things that are not typical usually require a lot of thinking, testing, and multiple trips back to the well to get things right. This is not where a framework shines, because it's unlikely the framework has anticipated your need exactly, and you're just as likely to be forced to work around the templates assumptions and quirks.

Put another way, RoR seems to do things that are simple very simply, and it seems to do things that have already been done quite simply. But for new, radically different applications, you're still back to straight programming and hand-writing SQL.

Re:Looking to get started in Rails?

[Eneff]

Ummmm....

You mean, like ibiblio?

You know, what maven hosts?

Re:Looking to get started in Rails?

[JerkBoB]

On a bang-for-buck analysis, it's better to lace together OSCommerce, phpBB2, and one of the random CMSes in order to produce an actual workable Web site that, you know, does something.

That must be some good crack you've got there. Have you ever heard of a little company called 37 Signals? No? Go check them out and tell me that their applications aren't useful. Ever heard of a site called Penny Arcade? No? Well, then I guess you're from another planet then, or something. Those are just some quick examples from memory of sites done in Ruby/Rails.

You stick to your *snicker* PHP... I'll be having more fun and getting more done with less code.

Put another way, RoR seems to do things that are simple very simply, and it seems to do things that have already been done quite simply. But for new, radically different applications, you're still back to straight programming and hand-writing SQL.

Opinions are like assholes... Everyone's got one, and often they stink. It's always amusing to watch people (here and elsewhere) spout off about something without even having learned about it.

If you had said "I've tried Rails, and here are xyz reasons why I don't feel compelled to move to it", I might be more interested in what you have to say. As it is, your post is about as useful as tits on a bull. :P

Re:Looking to get started in Rails?

[catch23]

Yes. However, RubyGems is much more "integrated" into the operating system than the Java equivalents. Plus, Ruby developers seem to be more likely to create a gem for their project than java developers creating an equivalent package type.

Re:Looking to get started in Rails?

[rho]

I'm sorry--didn't Penny Arcade farm out their store to ThinkGeek? So your example of RoR's superiority depends on a site that associates a comic with a blog post?

Well, there is 37signals, who made a nice guestbook. That's certainly new.

Just for your edification, I'm not particularly biased towards PHP. It's just that OSCommerce and phpBB2 are widely used and well-supported. My vast indifference to which programming language to use is only exceeded by my impatience with people who demonstrate irrational prejudice towards programming languages. Then I noticed your username, and promptly got over it.

Re:Looking to get started in Rails?

[JerkBoB]

I wasn't pointing out the store... Their site was recently redone using RoR. And I wasn't pointing at PA as an example of a particularly complex site, although I'm sure it gets quite a bit of traffic.

The main thrust of my post wasn't to be a RoR fanboy, although I can see why it would come across that way. That will teach me to post pre-caffeine. The reason I bothered to post was because of my annoyance with people like you who pontificate about why they won't bother to "believe the hype" without having done anything to learn about why the hype exists.

Sure, be skeptical. But until you've actually tried Ruby/Rails (notice that I am distinguishing between the language and the platform - I use Ruby outside of Rails), your dismissal of it just sounds like cranky curmudgeonly sour grapes.

Take a look at Ruby someday, you may be pleasantly surprised. I have nearly a decade (as both a sysadmin and webapp programmer) invested in Perl/Python, but I love Ruby and use it whenever I can now. Languages are tools, true, but some tools are better than others.

/me shrugs

Re:Looking to get started in Rails?

[Forbman]

OSCommerce has been on version 2.2 for...oh, at least 5 years now. Well supported? OK...Yeah.

Re:Looking to get started in Rails?

[rho]

I'm sorry--you're not interested in a stable ecommerce package? You'd prefer a new point-release every 6 months or so? I take it you don't sell much of anything. You likely don't see the value of an enterprise distro such as RHEL or CentOS either.

Re:Upgrading

[gregarican]

For now Windows-based implementations are a "piece of cake." But in time Mac OS X will be as well. This RoR project is still relatively young so I think the hype is moving forward faster than the underlying technology. Nevertheless a good thing to investigate...

Web an API junkyard

[amightywind]

This posting only serves to remind me what an API junkyard web programming has become. Let's see, we need server side Ruby to transmit and execute Javascript that manipulates a DOM to emit HTMP, gracefully degrading features for anachronistic browers. Zowie!

Re:Web an API junkyard

[killjoe]

I couldn't agree more. You know what the saddest part is? The applet could have saved us years ago. Only if Sun wasn't so incompetent and MS wans't full of such evil bastards.

Re:Web an API junkyard

[amightywind]

I agree. I am a little surprised the applet hasn't come back into style. It certainly provides a rich interface and is nowhere near as contorted as some of these 'frameworks'. It would have been nice if several languages could have supported Java bytecode output. Kawa scheme does. I don't know of any others. Another thing I have been puzzled about is why Sun never freed the Hotjava browser. In the old days, I used to like it. It certainly ran applets cleanly.

Re:Web an API junkyard

[pooh666]

I have to add in my agreement to this as well. It is sad what I could do with a Java applet years ago, and now people using flash act like it is a big deal. It is this lack of memory that allows this constant reinvention.

Re:Web an API junkyard

[Overly Critical Guy]

Aaaaaand how is that different from desktop development? Actually, how is that different from any other development?

Yeah, shocker, APIs call other APIs to call other APIs. That's how software works.

All you did was describe the basic model of server code delivering client code. Which is the future.

Re:Getting started

[binner1]

I recently finished the Pick Axe book 2nd ed and would highly recommend it. Like one of the other replies notes, it's a Ruby book, not a Rails book, but I agree you should learn Ruby first. The first edition of this book is available for free on the web at various locations (eg: http://www.rubycentral.com/book/). I started using this several years ago but got sidetracked. The recent Rails fuss has grabbed my attention again, so I finally sat down and dug in. It's now my language of choice for most programming tasks (quickly replacing Perl altogether for my needs). I've yet to do any Rails work, but have a few personal projects in mind that might be good testing for it. Ruby definitely stands on it's own as a language, Rails is just a beautiful use of a beautiful language.

Cheers.
-Ben

Re:I haven't heard much

[MadMirko]

Penny Arcade is using it since a few weeks. I don't know if the glitches with the site lately have anything to do with that, but Tycho sometimes mentioned them himself. So, a new release should be welcome to them.

Re:Congratulations Ruby on Rails

[Anonymous Coward]

Remember when folks ridiculed Java for being a silly, slow, toy that would never be ready for prime-time with no ide's and useless(cr)applets?

It seems like only yesterday, wait, it was.

Re:Upgrading

[metamatic]

The OS X problem is that Apple shipped an old and somewhat broken version of Ruby. I'm sure that now that Rails is getting more attention, that will be fixed in the next release of OS X... Ocelot or Liger or whatever it is.

http://developer.apple.com/tools/rubyonrails.html

Kudos to RoR...

[helix_r]

... May this be yet another nail in the coffin of the life-sucking tedium that is J2EE.

Re:Kudos to RoR...

[what about]

Since you mention J2EE and by consequence Java, I suggest you have a look at this comparison chart

You draw your conclusions

Re:Kudos to RoR...

[helix_r]

My conclusion is that the compute-intensive performance of java versus ruby does not really make much difference for the vast majority web apps.

It is not about performance. It is about developer productivity.

Re:Kudos to RoR...

[ievans]

If you're using J2EE/Java EE for simple data-driven web sites a la RoR, then you're probably not the target developer for the Java EE platform. I have nothing against these web frameworks and the people who love them, I should add. It's just that the average /.er doesn't see the need for the features that are at the core of enterprise Java, and therefore they dismiss the platform as being too heavyweight. Sure, for small-scale development. The same mentality pops up in discussions on whether, e.g. MySQL needs transactions. It's kind of like hearing somebody who once built a dog house talk about the design requirements of a skyscraper.

With that being said, Java EE 5 will make enterprise Java developer's lives much easier. EJBs, everyone's favorite whipping boy, are a lot easier to code now.

Re:Kudos to RoR...

[CastrTroy]

Exactly. Most web applications aren't really that computationally expensive. Most of the slowdowns are from database access, and network speed/content-size. Once those issues are fixed, then we can worry about languages that are faster than others.

Re:Kudos to RoR...

[molarmass192]

I was just going to suggest that the parent has deved a website used by more than 2 people. You've put it much more eliquently, I especially like the build a dog house vs. build a skyscraper comparison. I'd add, that Java is far more widely known. I can walk away from my code and KNOW somebody will be able to pick up where I left off, customers tend to like that kind of thing.

Re:Kudos to RoR...

[digidave]

Java is faster, but Ruby is easier on system resources. Ruby on Rails scales far easier than Java and saves mountains of developer time both while initially programming the app and maintaining it later.

My conclusion is that Rails apps are easier to program, easier to scale to multiple servers, easier to deploy, and they run slower than Java apps in some circumstances.

Re:Kudos to RoR...

[helix_r]

The fact of the matter is that the vast majority of web-apps are actually in-house apps that have a fairly small number of concurrent users.

Sadly, thousands of dev groups all over the world are slaving away very hard at j2ee simply because, well, its a good thing to have on one's resume or because consultants can bill mega-hours by building a "scalable enterprise application".

If people were honest about their motivations and real scalability requirements, it would be clear that j2ee fits a niche market and that more rapid, easier-to-use dev frameworks like RoR fill mainstream needs.

Re:Kudos to RoR...

[ievans]

No offense, but the oft-repeated anecdote about hundreds of poor schlups being forced to code horrendously overweight J2EE-apps while consultants wheel-away wheelbarrows full of cash doesn't ring true to me. What organization has this kind of money and time, especially since the downturn and what with offshoring development and all? Where are these companies?

I also question your use of the term "mainstream." One person's niche technology is the next person's mainstream one. There are different market segments for development frameworks and technologies. Ones that require the sort of transaction, security, and connectivity capabilities that exist in Java EE would find RoR severely lacking. As you found out, stand-alone web apps with low numbers of concurrent users don't need the security, transaction, and connectivity support in Java EE, so those developers don't use it.

Re:Kudos to RoR...

[larry bagina]

Java kills RoR in speed, ram, and scalability. RoR might be faster/easier with development and maintenance, but that's an advantage of Rails, not Ruby. There are Java, PHP, Perl, etc. Rails-like frameworks available.

Re:Kudos to RoR...

[CyberGarp]

With that being said, Java EE 5 will make enterprise Java developer's lives much easier. EJBs, everyone's favorite whipping boy, are a lot easier to code now.

Bwuaah hah aha hahahaha. Let's see, we go from EJB's are evil to a lot easier to code now. Sure, after getting burned and poked in the fires of hell by Sun's concept of a business layer, just getting slow roasted on a spit is prefered.

Re:Kudos to RoR...

[killjoe]

"Java kills RoR in speed, ram, and scalability. "

Really. According to these articles ROR was able to scale to more then a million hits per day spread out over 14 hours or so. That's around 20 dynamic pages per second and 85 gig of data PER DAY.

That's a real world application running today on ruby on rails, linux, mysql and fascgi.

How much of a developer productivity hit are you willing to take on the off chance that you will hit a limitation of Ruby or ROR?

The "java scales but fill-in-the-blank doesn't" crowd doesn't know jack about risk managment. They are willing to take all kinds of hits on developer productivity, deployment headaches, maintenance nightmares on the off chance that their web application will need to be the size of amazon.com or ebay. Silly don't you think?

Re:Kudos to RoR...

[21chrisp]

Just because companies shouldn't be wasting money doesn't mean they don't do it.

Java is ubiquitous in the corporate market. It is the Jack-of-All-Trades. It's what CTOs look for on a resume because they think Mr. Java can do ANYTHING, and Mr. Ruby might be able to learn Java after a year or so, but would be limited in what he could do until then.

I still can't fathom why people think Ruby lacks transaction, security, and connectivity. My experience with it is that it's highly reliable and connects to almost anything. I've never had security problems w/ it.. but it is still a bit obscure. I have ruby apps on a site drawing 30 million hits a month with no problems. I have it connecting Solaris, Linux, OSX, and Windows. If I want to add full transaction support I could connect it to Postgress, ORACLE, DB2 etc etc. Is that good enough? Where is the feature set not working? It seems to me like you haven't spent much time with Ruby.

Re:Kudos to RoR...

[BuildGate]

If people were honest about their motivations and real scalability requirements, it would be clear that j2ee fits a niche market and that more rapid, easier-to-use dev frameworks like RoR fill mainstream needs.

I always think for simple web development, JSP/Servlet should be good/simple enough. For large-scale stuff, of course I will use some framework (Struts/JSF/etc).

Can't see how RoR fit into the picture.

Re:Kudos to RoR...

[dubl-u]

If you're using J2EE/Java EE for simple data-driven web sites a la RoR, then you're probably not the target developer for the Java EE platform.

What the yutzes at Sun missed is that almost every large app starts life as a small app, and the way you learn to code well is by starting small and work up. This has led to a few obvious problems with the J2EE world:

• Because the J2EE stuff is a bitch to get started with, fewer people use it than should.
  
• If you start with the heavyweight J2EE stuff because you hope for high volume but don't get it, you end up paying a lot of money that you never needed to spend.
• Competitors who start with something like ROR are more likely to beat you to market, meaning that choosing J2EE makes it less likely you will need J2EE's expandability.
• People who start life coding on J2EE can't code worth a damn; they get so used to everything being difficult, slow, and mysterious that they never notice that their own code is difficult, slow, and mysterious.

And that's leaving aside that the most enterprise-ish portion of J2EE, EJB, has never come close to living up to its promise. Sun finally admitted that with EJB3, where they basically replaced it with an open-source package.

There's no reason that Java couldn't have birthed Rails, other than that Sun cares very little about enabling day-to-day development. Want to write a quick command-line Java app? Too bad, because Java takes 100 times as long to do "Hello World" as Ruby or Perl. Want to do multiple inheritance or mix-ins? Sorry, Sun thinks you're not smart enough. You find Java awkward for writing certain kinds of code? Tough. Better use some super-complicated framework with a zillion XML files. Need a quick scripting language or to evaluate a bit of code? Sorry, Charlie.

Java 1.5 was basically C# forcing Sun to briefly pay attention to developers. Perhaps the RoR movement will get Sun to pull their head out of the collective ass of the Fortune 500 and make Java 1.7 another release that tries to catch up with the competition's superior ease of development.

Re:Kudos to RoR...

[ievans]

"I still can't fathom why people think Ruby lacks transaction, security, and connectivity."

With Java EE, I can define business methods which automatically gain transaction attributes. I don't have to explicitly define transaction attributes, and ensure that any calls to a particular method happen within a transaction context. The transaction context is implicit, and goes beyond just database calls.

I've never tried to connect to connect a RoR app into a legacy datasource that uses CORBA, but I can imagine it would be a nightmare. Is there even a Ruby ORB? I doubt it. Granted, CORBA isn't used all that much, but if you need it you need it. With J2EE Connectors it's treated as just another datasource. That's what I mean by "connectivity."

Security contexts are defined on the app server level, and can be configured at deploy time and altered at run time rather than coded into the app. Do you want to make a component only accessible to a particular role? How about a particular method? Or an entire app? All of this can be configured pretty easily. If you need to integrate your app with an outside authorization mechanism, it's just a matter of configuring a particular realm in the app server.

The point is, these features are practically useless to developers working on a solitary web app (even one that gets a lot of hits). RoR or one of the other quick development frameworks really shine in these cases. But Java EE exists for a reason. A pickup truck can haul a lot of things, and is a really useful thing to have around. If you have to move a family of 5 to another city, the limitations are overwhelming.

Re:Kudos to RoR...

[NutscrapeSucks]

If I want to add full transaction support I could connect it to Postgress, ORACLE, DB2 etc etc. Is that good enough?

J2EE and Microsoft have transactional distributed middleware included.

Sometimes relying only on database transactions is not good enough (eg, in the classic "enterprise" application that has more than one backend system behind it).

Re:Kudos to RoR...

[MemoryDragon]

I have encountered only one project with hundreds of devs, in fact most j2ee apps I have seen were coded by a handful of people. It is not as hard as people always says. Rails biggest benefit is that it has a good set of tools on top of the framework (mainly scaffolding and codegens)) in the j2ee world there are similar tools, you just do not get it in j2ee. I once generated 40% of an app via xdoclet.

Re:I haven't heard much

[tyler.willard]

Ruby started to gain popularity about 5 years ago when the following article was published:

Programming in Ruby

Dr. Dobb's Journal January 2001
A freely available pure object-oriented language
By Dave Thomas and Andy Hunt

(you can't read the whole thing without an account so no link)

Granted, it's been around for over a decade, but it took a while before it got attention outside Japan.

Re:I haven't heard much

[Anonymous Coward]

Nobody. They're all to busy hyping it and posting on slashdot about how great it is. Meanwhile all us PHP/JSP/ASP/whatever programmers are off actually making web applications.

Re:Upgrading

[ceejayoz]

OSX already has Locomotive for that.

Re:Getting started

[mslinux]

I would suggest 'Programming Ruby'. The first edition can be read online here: http://www.rubycentral.com/book/

Ruby is a wonderful language that is very flexible. I came to it from Python. I enjoy using both languages, but Ruby has replaced Python as my 'home' language. I don't do web devel.... there's much more to Ruby than Rails :) Ruby is an excellent Windows or Unix sys admin language or a great general purpose programming language or a scientfic/computational language as well. Rails simply demonstrates Ruby's power and flexibility.
 
Ruby will be around for a long time.

This seems good for layman understanding

[AgNO3]

http://developer.apple.com/tools/rubyonrails.html Found that link on the ruby on rails site and it was the best description for a non techie like me that I could find in fast.

Re:This seems good for layman understanding

[ytsejam-ppc]

The best part about this article is that it was written by Mike Clark from the Pragmatic Studio. I took their class when it rolled through Denver, and I couldn't recommend it higher. Mike and Dave Thomas put on a great class.

Re:I haven't heard much

[hackstraw]

I haven't heard much about Ruby since the (geek) media blitz of over a year ago. How many people actually use Ruby on Rails? I see the same thing happening with AJAX.

Its the way geeks do things.

It reminds me back in the late 90s when everything was Java!!!

It reminds me of even further back in high school.

Back then, everybody was interested in sex, talked about sex, wanted sex, but nobody was doing sex.

Same thing with Java in the late 90s and Ruby today, and AJAX tomorrow.

Re:Upgrading

[masklinn]

If you want Ruby on Rails 1.1:

1. Check that you have the latest Ruby version (1.8.4) by running "ruby -v". If you do, go to step 2, if you don't upgrade your Ruby.
2. Check that you do have the Ruby Gems software. Just type "gem -v" in the CLI. If you don't have RubyGems then go get it
3. Once Gem is installed, just type "gem install rails --include-dependencies", this will install the latest version of Ruby on Rails and every package that's required by Rails (Rake, ActiveSupport, ActiveRecord, ActionPack, ActionMailer and ActionWebService). If you've ever used a Debian, think of "gem" as a Ruby-oriented version of apt-get.
4. You're done, start Railing away.

No problem / Noscript

[fforw]

The noscript firefox extension lets you forbid execution of javascript/java/flash by default and only enable it again for some sites (whitelist). Internet Explorer has "Trusted Sites" or something.. So all in all that is not that much of a problem..

Re:No problem / Noscript

[billstewart]

That sounds like precisely what I want - I'll have to try it. Thanks!

Ruby Apps

[Rac3r5]

I'm not a Ruby developer, the most I've done is just skimmed over some Ruby tutorials. I like the ease and simplicity of the Ruby syntax.

Is it possible to make stand-alone, executable apps in Ruby? What about GUI?

Re:Ruby Apps

[mslinux]

Yeah, for sure... this was written in Ruby. It's a stand-alone win32 executable for hashing files, strings, etc...

Re:Ruby Apps

[gregarican]

There are tools for making Ruby into self-extracting executables --> http://www.erikveen.dds.nl/rubyscript2exe/index.ht ml. But for a true compiled solution that will likely be bundled with Ruby 2.0. It should include a VM --> http://www.atdot.net/yarv/. As for GUI apps there are extension libraries for Tk, Qt, Fox, WxWindows, GTK, etc.

Re:Ruby Apps

[kbob88]

Sort of... not totally stand-alone in the traditional binary executable sense. You still need the Ruby interpreter.

But several tools (Ruby2EXE, ExeRb) allow you to bundle your program, libraries, and the Ruby interpreter into an executable that you can then distribute. I've used them in the past and they work well -- never had any users tell me they couldn't install the program.

There are various options available for a GUI. I've used wxRuby a lot. It's an interface to the WxWindows/WxWidgets toolkit. I think it works very well, and I really like it's auto-layout features using sizers, although the API is very C++-like.

Another toolkit that people use a bunch is fxruby, which interfaces with the Fox toolkit.

There are lots more GUIs. Take a look at the Ruby App Archive or lurk on the mailing lists to see what toolkits people are using (or just ask them).

Re:Ruby Apps

[killjoe]

Is there a way to write an activeX control or a DLL in ruby? That's what I need to replace some VB activex controls.

Re:Ruby Apps

[gregarican]

I personally haven't run into anything in Ruby that would pull this off, although I think that Python offers such things. The languages aren't that far removed from one another. If you are into dabbling I would check out Python too...

Re:Ruby Apps

[killjoe]

I know python can do it. For some reason nobody has written something like for ruby.

Re:Ruby Apps

[gregarican]

I think the reason behind this is Python seems geared toward Win32 implementations. Installing extension libraries and interfacing with the Win32 API is built into the Python environment. But Ruby seems to still be heavily rooted in Linux/GCC. There are many Ruby extension libraries that won't install on Win32/MSVC and not many people in the community complain. Perhaps it's because there is some unsaid beliefs that Windows isn't an ideal target amongst the core development team? Not sure, perhaps it is my own paranoia and frustration. Since I prefer Ruby over other languages but fitting everything into my Win32 requirements isn't the smoothest proposition...

Re:I haven't heard much

[digidave]

I'm coding a large-scale site in RoR right now. It'll be deployed across three Lighttpd servers with two MySQL servers. I'm about three weeks into the site and I've probably saved a month of work already over how long it'd take me to do the same work in Java or PHP.

Rails' efficiency won't continue to be that high as I get more into the business logic and smaller details, but for the data layers that I'm doing now Rails blows away anything else. I'll still be at least 50% ahead of where I'd be using Java and PHP when it's finished. The code will be way cleaner because Ruby is a better designed language than either Java or PHP. It'll be a snap to add features later, which is the problem we're currently having with our site and its 20,000+ lines of PHP code.

I've coded and managed Java and PHP sites. PHP is easier to work with than Java for most small to medium sites and Java can be easier on large sites. Neither of them are better than Rails for any size site.

I predict that Ruby on Rails will become the big third competitor in the market for building web apps. Java will still be bigger on the very high end because of EJBs and the need to interface with legacy systems and PHP will still be bigger on the low end because it's easier to learn since you don't need to know OOP to get started. Ruby on Rails will be the language/framework that finally fits into that middle market where most medium to large businesses are. PHP's code is too messy to work there without a lot of coder discipline and either a custom or well-done Open Source framework and Java is just too complicated.

Re:I haven't heard much

[finnif]

You need to work on some performance enhancements. That front page of indi loads unbelievably slow. Rails is really easy. I'm worried about the first time my sites get /.ed though. Ruby needs that JIT interpreter bad.

Re:Getting started

[XaXXon]

Everyone raves about the poignant guide, but I found that after reading it for 20 minutes, I hadn't done much except read stories and comic strips. I really didn't have much of an appreciation for the language.

There's something to be said for making a potentially dry subject interesting, but it seems to go too far with it and actually spread the actual information too thin.

Just my opinion, of course.

Lets use Google as an example ....

[Shohat]

As I see it , even if GoogleOS will not become the desktop standart , Google is heading in the direction of enabling many of the functions currently availble only as installed applications , through a web browser . Writely and Gmail are both AJAX based , and these are a word processor and a IM/Email application , both clearly target desktop-application dominated markets. To understand it better , you might want to use Gmail through a simple Javascript disabled interface (it is also supported, through basic HTML view) and see how it behaves . I believe that everything that is not content, will be delivered using an AJAX based interface in the near future .

Re:Lets use Google as an example ....

[Senzei]

I believe that everything that is not content, will be delivered using an AJAX based interface in the near future .

Dear god I hope not. AJAX is awesome when the application logic is relatively minor and the feature requirements are low. Gmail is great except that it does not support a lot of the collaboration features that make outlook/groupwise essential for office environments. Writely may work well for high school homework papers but try using it for a college thesis, much less putting together business documentation.

Ajax will probably take over some of the home versions of productivity tools. It does not have the power to handle the feature requirements of anything bigger than that.

Re:Lets use Google as an example ....

[aCapitalist]

AJAX (or rather DHTML) has some serious limitations that cannot be overcome without significant changes that would take years and years for all the browsers to implement. Just as Microsoft gave us XMLHttpRequest, I have a feeling WPF/E that will be a small plugin for at least Firefox and IE on windows and mac will bring the web to the next level. Flash is in the same category, but (to me) has a disadvantage of sending bytecode to the browser and not markup. XAML is just markup that can be scripted with standard Javascript or a subset of C# and VB.

AJAX is definitely cool for small app-like functionality on the web. It's raised the bar for sure. Thank God for pop-up blocking or you'd probably have most people turning off Javascript :)

Re:I haven't heard much

[BigZaphod]

Interesting comment. I'm curious about how Rails manages to save so much time as compared to PHP and the like. I don't have Rails experience and I've only just messed with Ruby enough to do a few Hello, World type things. What is it about the Rails approach that saves all the time and effort? I frequently see those claims, but it's a little harder to get solid, real-world examples.

Re:Getting started

[BioCS.Nerd]

I tend to agree with you. I found some of it interesting, but in the end I keep going back to my copy of the "pick axe" book. As one of my friends put it, the poignant guide tends to be a little *too* poignant.

Re:I haven't heard much

[tcopeland]

> That front page of indi loads unbelievably slow.

Yup, that's just a function of the Rails 1.1 effect - getindi.com is currently sharing a DSL line with rubyforge.org, which is serving the RubyGem index that lets people install Rails with gem install rails. Yikes!

Re:Getting started

[Dasch]

There has already been several replies pointing to very good resources, so I won't repeat those here. I myself came to Ruby from PHP - I had never used anything else (unless JavaScript counts), and I immediately fell in love. I've never gone back, and I don't think you will, either.

The main difference is that Ruby is a real *language*, not just a collection of Perl scripts (though PHP is maturing now; don't want to start a flame war.) You can alter it in almost any way you like, that's what so great about dynamic languages.

There are things you'll probably find confusing at first (I presume you know basic Object Oriented Programming from PHP 5,) particularly metaprogramming. Once you understand that, you'll be able to do things extremely simple and elegant.

Karma Whore Tutorials

[Anonymous Coward]

http://it.slashdot.org/comments.pl?sid=181523&cid= 15012418

Re:I haven't heard much

[yerfatma]

As someone who works in C#, PHP and ASP at work and has barely played with Rails, it's the strict enforcement of MVC that is such a time saver. It's not enforcement like "You have to do things our way" to slow you down, but "We're going to make it easy to do things right so you don't cheat as often". It pays off in things like consistency and ease of refactoring.

He said, without having built anything of note in the Ruby or Rails.

Re:I haven't heard much

[pixr99]

You owe it to yourself to go check out some of the screencasts. The two features that have saved me the most time (so far) are:

1. There's just about no configuration to do if you follow some simple and logical naming conventions.
2. Once you've created your database table, a simple "ruby scripts/generate scaffold Model Controller" (substituting your actual model and controller) writes enough code so that you can do inserts, updates and deletes on the table.

From there, you start customizing.

Weaknesses of "prototype.js"

[SimHacker]

As someone who's evaluated various JavaScript frameworks, what do you think of "prototype.js", the AJAX library that Ruby uses?

Does the new version of Ruby continue to use "prototype.js" or has it switched to a better designed and documented JavaScript framework?

How is the documentation of "prototype.js"? Does it have a rigorous test suite? How does "prototype.js"'s documentation and test suite compare with, say, MochiKit?

Does "prototype.js" continue to define additional methods on Object.prototype? How does it deal with the issue that defining extra methods on Object.prototype causes "for (key in obj)" to return those method names for every object, totally breaking a fundamental JavaScript language construct, and making it extremely difficult to integrate other JavaScript libraries and code modules without suffering mysterious bugs and crashes?

A JavaScript framework should NEVER define methods on Object.prototype or Array.prototype, because doing that breaks all JavaScript code that iterates over the keys of objecs or arrays, which is certainly not very friendly nor modular. Why did Ruby choose to use an AJAX framework that makes such a huge mistake? Have the maintainers of "prototype.js" gotten around to cleaning up that mess, and why did they make such a horrible mistake in the first place? Weren't they aware of this horrible JavaScript quirk, and why didn't they work around it in the first place? Isn't that supposed to be why we use JavaScript frameworks: to avoid such problems?

-Don

Re:Weaknesses of "prototype.js"

[FecesFlingingRhesus]

As someone who's evaluated various JavaScript frameworks

I do not evaluate JavaScript frameworks as JavaScript is only one portion of a mutli-teir application. I focus my efforts on comprehensive frameworks (such as RoR, Echo2, ASP.NET, JSF, etc.) that incorporate front to back solutions in an effort to reduce the overall development lifecycle of which AJAX is but one small facet (if existent, which was the point of my original post). Having to wire up the back end for AJAX communication does not serve this end that is why pure JavaScript frameworks such as MochiKit or SAJAX are a partial solution and not the solution as a whole, which as an architect is what I have to concern myself with the most. Linux would draw a similar parallel, though the kernel is an important piece of the OS pie, it is in the end, a partial solution you need user land tools, as well as drivers and applications in order to have a complete and useful system. If RoR implemented their AJAX architecture incorrectly (or did not use a proven JavaScript kit) then that is a problem that you must sort with them and not me, as I am neither the designer nor an authority of RoR. As I said in my original post I welcome the incorporation of an AJAX layer into any of the prospective frameworks that I may have to use at some point and as I said from my evaluation the most intuitive and well designed framework that I have used to date is Echo2 as a developer need not concern themselves with any layer of the client communication. Ajax and HTTP communication are seamlessly integrated into the event model. As well HTML is encapsulated in their component model. Therefore a developer only need concern themselves with one language and one technology. Narrowing technological focus directly translates into increased productivity. I let the framework developers concern themselves with their implementation specifics. If it is broken take it up with them as that is exactly what I would do or I would find a new framework.

Re:Weaknesses of "prototype.js"

[SimHacker]

I'm not asking you to fix the problem, I'm just pointing out that you should be aware of it, so you're not surprized when things start breaking for no obvious reason, when you try to do anything less than trivial with AJAX.

As the person evaluating frameworks, you should be aware of the limitations that the frameworks have. If you're using a framework that depends on "prototype.js", it should certainly concern you, because that means you're going to have trouble integrating other JavaScript code with it. Unless what you're doing is trivially simple and you're absolutely sure it will never grow in complexity, then you should keep the limitations of "prototype.js" in mind when you're evaluating Ruby on Rails, unless it provides an alternative.

-Don

Re:Weaknesses of "prototype.js"

[rossifer]

as I said from my evaluation the most intuitive and well designed framework that I have used to date is Echo2 as a developer need not concern themselves with any layer of the client communication.

I've had to use Echo and evaluated Echo2, and unless you agree with their framing of web applications (as desktop applications that happen to be accessed through a web browser), you'll get yourself in serious trouble. Their attitude is best summed up in their own response to a question about bookmarkable URL's: "Can you get a link to a certain window in a desktop application? Ajax is for web applications, not for hyperlinked documents."

<clue-bat>
Web applications are not desktop applications that happen to be used through a web browser.
</clue-bat>

Using the web as an application interface provides a number of new abilities (creating and passing around stateful references for one) that are simply not possible for a desktop application. And it's not like users don't know about these abilities or somehow don't expect them. The Nextapp devs and marketers say you shouldn't need to tell someone a URL that takes them directly to a particular piece of information (probably after an authentication step), but our users say that's a valuable/critical feature. Who should we listen to?

I'll use Echo again after the Nextapp guys learn some basics about the web. For the moment, they're clinging to outdated notions of information access and application context and that makes their frameworks a hinderance when trying to build an effective web application.

Regards,
Ross

Re:Weaknesses of "prototype.js"

[FecesFlingingRhesus]

Don,

I thank you for the heads up on the possibility of problems with the Ajax components of RoR as of now I am not currently evaluating RoR for any projects so my knowledge of the framework is limited to small test applications to gain personal knowledge of the framework as a whole. I concur with many conclusions that both you and the author of the article you cited draw. Breaking core functionality of a language is neither a good practice nor is it advisable. If I have the chance to evaluate RoR for a project I will keep your notes in mind and test my proof of concepts to test the fabric of the framework to ensure that they will not hinder my design.

Re:Weaknesses of "prototype.js"

[TerrapinOrange]

Why should a a JavaScript framework NEVER define methods on Object.prototype or Array.prototype? Code that requires a static definition of Array is clearly making incorrect assumptions about how the language is used, so I'd place the blame there, not with prototype.js.

Most people treat JavaScript like its C's retarded little brother, but that's just one of many programming styles that it adapts to. Methods like Array.each and Array.grep allow JavaScript to be used in a very Ruby-like fashion, which, in addition to making the language more comfortable for its target audience, usually results in tighter, more readable code. Extending Array and Object might lead to some exciting bugs in code that doesn't expect it, but I don't see how this makes the practice wholesale wrong. Ruby on Rails does stuff like this all over the place. Being able to say 3.months.ago or some_random_object.to_json is part of what makes Rails such a pleasure to work with, and I don't see why its JavaScript library shouldn't be extended the same freedoms.

To quickly address your other two issues, I got all the documentation I ever needed from this site, and, while unit tests are definitely nice, prototype's proven track record is enough for me. I haven't had the slightest bit of trouble with prototype -- it's done nothing but save me time thus far.

Re:Weaknesses of "prototype.js"

[FecesFlingingRhesus]

Web applications are not desktop applications that happen to be used through a web
browser.


Ross,
I do not totally agree with your conclusion, different application requires different architectures. This is the very reason that there is a plethora of different frameworks some solve different problems while some tackle the same tasks ad nasium.

Echo2, is aimed at tackling the problem of a thin rich clients over the internet. It is not designed to supplant you standard page based web applications where bookmaking content is necessitated. For a portal type application it is not the right tool for the job. Where it is the right tool for the job is in building a dynamic application that is distributable and maintainable in a single instance. It is very good for enterprise system development of say and accounting system or a admin system in which the user is accomplishing a business process. I am not talking about end user content based sites but applications that have traditionally been the domain of the desktop. The savings on administration alone are astronomical. As I have said it is not the right tool for ever job but to discount it out of hand is to not give it due diligence. In my realm of work Echo2 has liberated me for have to make the choice of either giving up the simplistic distribution of the web or the dynamic nature of the desktop.

The Nextapp devs and marketers say you shouldn't need to tell someone a URL that takes them directly to a particular piece of information

Again, an application designed to input information to store in a DB or to transact a process is where such frameworks shine not in content rich applications such as a shopping site or a documentation project. It depends on the nature of the application. If you are just creating a word document and saving it on a server then there is no need to bookmark said information. A completely different architecture exists for retrieving information in this design, such as opening the saved document from the web application.

Re:Weaknesses of "prototype.js"

[Senzei]

Why should a C++ program NEVER overload the plus and minus signs? Code taht requires a static definition of addition is clearly making incorrect assumptions about how the language is used, so I'd place the blame there.

The point is that there is very little reason WHY this change would be necessary instead of making a function that accepts these objects as arguments. What is really so different between push(item, array) and array.push(item)? What possible use could it have that is worth breaking looping over items in an associative array? The problem that prototype has is it is trading a useful language feature for dubious benefits.

The ability to extend basic primatives is awesome, but I want to control when that happens.

Re:Weaknesses of "prototype.js"

[ubernostrum]

Why should a a JavaScript framework NEVER define methods on Object.prototype or Array.prototype? Code that requires a static definition of Array is clearly making incorrect assumptions about how the language is used, so I'd place the blame there, not with prototype.js.

I place the blame squarely on Prototype. Application developers should never have to worry that someone else has snuck in and modified the core language's behavior without their knowledge, because down that path lie nightmares of coupling and maintainability which are best avoided.

Re:Weaknesses of "prototype.js"

[ubernostrum]

Echo2, is aimed at tackling the problem of a thin rich clients over the internet. It is not designed to supplant you standard page based web applications where bookmaking content is necessitated. For a portal type application it is not the right tool for the job. Where it is the right tool for the job is in building a dynamic application that is distributable and maintainable in a single instance.

Then why not take advantage of features of the Internet? If you're using HTTP, then every one of your content objects can be a resource accessible via HTTP GET at a unique URL, but too many "web application developers" fail to recognize that this gives them transparent, universally-usable storage and retrieval, programmatically accessible from pretty much every language on Earth, essentially for free. When you move into a new operating environment, you should adapt to that environment instead of trying to shoehorn another environment's worldview into it.

Re:Weaknesses of "prototype.js"

[rossifer]

different application requires different architectures.

No doubt. But we're not even to the architecture step, and I already disagree with how Nextapp wants to describe web applications. They're presuming that enterprise data and process repositories don't benefit from externalizable (or bookmarkable) URL's because desktop applications achieving similar goals got along without them.

Wow.

That's very short-sighted and seems to be a deliberate mis-framing of what the web and URL's mean to users, especially users with outside applications that would benefit greatly if there was a way to "point" into an application from other applications (like email, calendars, wiki's, issue trackers, etc.). URL's are an excellent means to that goal. But Nextapp rules them out as an artifact of "documents".

It is very good for enterprise system development of say and accounting system or a admin system in which the user is accomplishing a business process.

Actually, it's in exactly these meta-domains that I'm building web applications, and the ability to email a URL for a search or a specific content item (the details of a financial commitment, for instance) has been invaluable. More precisely, the inability to do so hurt us badly. When we were using Echo as the front end, we simply had to say "too difficult" for those use cases, and that ended up hurting us in the sales process.

So, in my experience, Echo was (and is) a poor choice for almost any kind of enterprise system development. Because the mistakes are not just bugs, they're baked in to your front-end architecture if you use Echo.

Again, an application designed to input information to store in a DB or to transact a process is where such frameworks shine not in content rich applications such as a shopping site or a documentation project.

Again, I'm referring to exactly the kind of enterprise information management applications that you're saying don't need emailable URL's (store info in a DB/transact a process). And I'm not saying that every view within an application UI needs to representable as a URL. Views that represent intermediate steps in user interactions (step 2 of 4 in the xyz wizard) aren't appropriate, but being able to send a URL that the recipient can use to see the status of a particular business process? Without needing to do their own search? Without needing to navigate from the splash page of the app? You're simply not valuing the time/frustration/perspective of your customers.

URL's aren't just for documents any more. Most web developers were saying this in 1996, but it's a decade later, and Nextapp still disagrees, thus the final remark of my previous message.

You seem to agree with the assumption made by the Nextapp developers: that anything more complex than hyperlinked documents doesn't really need URL's and web features. If that works for your customers so far, then IMHO you've been lucky. That didn't work for our customers, and I think is an unwise framing of what a "web application" actually should be.

Regards,
Ross

Re:Weaknesses of "prototype.js"

[FecesFlingingRhesus]

I did not move into another environment. I started out building web apps back in the CGI / Perl days when their was no framework and I know all to well the time frame it takes to develop a web app from the ground up when you have to slog through 12 different document, markup, script, and programming languages to get it out the door. I do not differ with the conclusion that sometimes resources need to be immediately accessible via a URL but some times they just don't. Most of the applications I build have a user authentication system in the first place. You can't just access the system without first logging in so this is the first line in deflecting the user from immediately landing on said page. I am not trying to shoehorn an archaic model onto a web model I am trying to develop new models which enable my developers to develop web applications quickly. It may not work for all but it has worked successfully for me. Where it has failed I have opted for other frameworks.

Re:Weaknesses of "prototype.js"

[FecesFlingingRhesus]

There is a common design pattern that developers using Echo2 use to bookmark internal elements of within the application. It is via a URL string as many other web apps use. One only need grab the string from the servlet context and parse it to return the application to a specific state, say maybe a string added on to the URL such as &invoice_id=7 parsing out this value will allow the developer to retrieve and display the invoice. You can even do this after a log in screen. Currently you have to build your own parser and command interpreter but given the other benefits of Echo2 this is a small piece of software to write and if built correctly fairly reusable among applications.

Where Echo2 fails in my opinion is in inter-application communication you cannot have an application that passes it context to another application. The developers are currently proposing solutions for this problem but in reality it is a small problem as it is rare that a developer needs full context passed between applications. Few frameworks offer this feature but it allows for more robust applications and allows for greater reuse.

Re:Weaknesses of "prototype.js"

[ubernostrum]

I do not differ with the conclusion that sometimes resources need to be immediately accessible via a URL but some times they just don't.

If you're developing an application which transacts its business over HTTP, and you're not using URLs as the basic representations of your application's resources, you need to just stop now. You're hurting your clients, you're hurting the Internet, and you're hurting me.

Most of the applications I build have a user authentication system in the first place. You can't just access the system without first logging in so this is the first line in deflecting the user from immediately landing on said page.

Hi, I'd like you to meet my friends: HTTP 401 Authorization Required and HTTP 403 Forbidden. They're bult in to the protocol your app is using, so the libraries you're developing with had better support them, and they're extensible to use pretty much any authentication scheme you want to use. And then once somebody's authenticated into your system, you can -- gasp! -- let them fetch things using standard HTTP methods like GET!

I am not trying to shoehorn an archaic model onto a web model I am trying to develop new models which enable my developers to develop web applications quickly.

Actually, I think you're working with people who've never developed web applications before, and rather than have them learn the new platform they'll be developing on you want to make it behave just like what they're used to. Fair warning: it won't be long before doing business that way will put you out of business.

Imagine if I decided to move from web development into desktop apps, and the first thing I did was write a local HTTP server that my app talked to for all its storage and retrieval instead of using native filesystem functions. I'd look pretty damn silly, wouldn't I? Well, just imagine how damn silly you must look...

Re:Weaknesses of "prototype.js"

[FecesFlingingRhesus]

Well, just imagine how damn silly you must look

Indignation and personal attacks are indicative of a diminished capacity to reson. Lets leave them out of the conversation or it is over. If you have a beef with my information then attach my information as attacking me will show its hollow end.

As for the HTTP Authentication comment you are talking about HTTP authentication vs "role your own" in which I will defer you to this discussion as the problems with HTTP Authentication are so numbered that it would be redundant to spew them all out here

http://ask.metafilter.com/mefi/21446
http://www.imc.org/atom-protocol/mail-archive/msg0 4511.html

No one in the field actually uses Http Authentication. I mean who EBay? Amazon? E-Trade? Yahoo? Microsoft? So I don't see your point. They all roll their own many of them use built in system accounts (which is a whole other argument) and put a front end on it. I mean really no one has used HTTP Authentication in years.

Re:Weaknesses of "prototype.js"

[rossifer]

Thanks for the info that it is possible to add your own externalizable URL generator/parser. This bit of information would probably do a lot for Echo2's acceptance if they were to publicize it more, but that would probably mean that they would have to repudiate lots of previous statements about it being unnecessary.

On that project where we used Echo, I ceded responsibility of the UI frameworks to someone else and trusted the answers I received back. When my own 1-hour research confirmed that the Echo team dismissed the need for externalizable URL's and I didn't see any information that it was possible, I gave up on those features while we were using Echo.

Where Echo2 fails in my opinion is in inter-application communication you cannot have an application that passes it context to another application. The developers are currently proposing solutions for this problem but in reality it is a small problem as it is rare that a developer needs full context passed between applications. Few frameworks offer this feature but it allows for more robust applications and allows for greater reuse.

These types of integration may seem rare to the Nextapp team, but they are the lifeblood of the data/workflow repositories that I've worked on. Enterprise applications rarely exist that don't have to talk to accounts payable/receivable and other components of CMP and ERP systems. In the contract management repository that I've been referring to, we built JMS/XML interfaces for service integration and tried to sell around UI integration (because Echo didn't support it). Now, with Struts/Tiles/JSF, the UI integration is practical and our users cite it as their most important feature.

But now that I know that Echo2 may support it (perhaps with a lot of work-around code), it may be worthwhile to re-evaluate Echo2. I certainly liked the look of our Echo application.

Regards,
Ross

Re:Weaknesses of "prototype.js"

[FecesFlingingRhesus]

This bit of information would probably do a lot for Echo2's acceptance

I agree but I think the problem is that as many of us use Echo2, we find less and less reasons to use book-marking capabilities. I have used it from time to time to show invoices and records but for the most part my developers have moved away from book-marking to other representation of data such as an icon on a user's workspace when they log in and our users love the simplicity of such a model. Anyway, I am rambling the point is your are correct the developers at Nextapp should tout this ability more as for some applications, not being able to bookmark is a show stopper.

Here is more info on the Bookmark pattern.
http://forum.nextapp.com/forum/index.php?showtopic =136&st=0&p=425&#entry425

As well here is some info on the inter application communication. I am a little vague on Echo2's implementation of this as I have not had to cross this bridge with any of my applications, but these problems are being evaluated and addressed to my understanding.

http://forum.nextapp.com/forum/index.php?showtopic =152&st=0&p=477&#entry477
http://forum.nextapp.com/forum/index.php?showtopic =300&st=0&p=1031&#entry1031

Re:Weaknesses of "prototype.js"

[ubernostrum]

Wow, you almost had a point there. Nobody uses HTTP auth because it's so flawed and, regardless of the type of auth, uses a single token that, if it got out, could be used by attackers to gain access regardless of whether it's actually the password or not. I see that.

And then you cite a list of five different companies whose authentication schemes consist of... sending a password over the wire. Consider two situations, then:

1. I send my password to eBay's non-HTTP-auth login system, and use an encrypted connection to do so (thanks HTTPS!).
2. I send my password to an HTTP-auth login system at some other site, and use an encrypted connection to do so (thanks HTTPS!).

Do you really think that situation 1 is any more secure than situation 2?

And yes, no-one's used HTTP Authentication in years, which is why you linked to an atom-pub post where they're talking about how they're currently using HTTP Authentication.

Re:Weaknesses of "prototype.js"

[rossifer]

I'll try to provide a slightly different response from the other poster (who seems to be letting his frustration with Echo/Nextapp get the better of him).

Most of the applications I build have a user authentication system in the first place. You can't just access the system without first logging in so this is the first line in deflecting the user from immediately landing on said page

Handling this scenario is a straightforward part of our authentication subsystem which aims to minimize user astonishment. Users don't get to see anything in the app if they're not authenticated, but just because you're not authenticated doesn't mean we can't be smart about what you're trying to accomplish.

If you browse to a page and don't have an identity yet, we set aside the URL you were going to, and send you to the authentication page with that URL as the "destinationURL" session attribute. After authentication, if there is a "destinationURL" value, we try to send you back there. "We try to send you" is pretty important, as you may not be able to see what you were trying to get to if you aren't authorized to see it. In that case, we present you with an "authorization failed" message and then send you back to the front page. If they've saved their login in their browser, all they do is click on the URL, hit [Enter] or click the [Login] button and, almost all of the time, the user is looking at what they wanted to see.

This also makes users much, much, MUCH happier about authentication timeouts. They go to lunch, come back, click on a button or start navigating again. The app gives them another login, and most of the time, takes them right back where they intended to go. They don't have to re-navigate from the front page to continue where they left off. Cleanly restarting from a timeout can fail for a few reasons, as sometimes what they were doing relied on session state (step 2 of 4 in the xyz wizard), so after the timeout, we sometimes have to fall back to the nearest sane page (the start of the wizard, perhaps). Other times, it makes more sense to provide a message about why they couldn't return to the page they were on and send them back to the front page, but most of the time, there's a decent non-astonishing alternative semantically "nearby" to where they were.

The lack of this feature in Echo drove me to distraction. You spent too much time talking over that last feature with the other developer:

[Please Wait]

AAuugghh!

Regards,
Ross

Re:Weaknesses of "prototype.js"

[FecesFlingingRhesus]

Security is an ancillary note to this argument, not that it is not important but the fact of the matter is any way you slice it you are going to have to send credentials over the wire I take no issue with that point, The problem is in the design restriction HTTP Authentication presents on a web application. It is fine for restricting access to a single document or set of documents but what happens when you need code level access. What happens when you need to masquerade permissions for the execution of a certain code block. The problem is that HTTP Authentication is not exposing this functionality to the application. In some cases there are libraries but in many cases there are not or they may not exist for your languade of choice. Not to mention restrictions with distribution and scalability. What if you system is compromised with a contained solution there are no worries about a breach of the web-servers permissions system as they are not authenticated on it, or worse the OS's permissions system. An abstracted model allows for this buffer. As well, there is the issue of managing the authentication. With HTTP Authentication the server assumes that a user is authenticated until the browser is closed while this may not be a problem for some application it can present a major problem for say a banking application that may want to terminate specific permissions as soon as a transaction is completed. Security systems such as BOA's site key are virtually impossible to duplicate using a HTTP Authentication model.

The links I provided where merely to highlight the problems that developers are encountering with trying to retrofit a HTTP Authentication model. Nothing more can be inferred from them.

Re:Weaknesses of "prototype.js"

[FecesFlingingRhesus]

The landing after login can be accomplished in either a HTTP Authentication or a "roll your own model" and I agree that it is the best design. My point with the authentication page was not that it did not matter that a user need land on the page but to highlight that in certain systems there is more involved in the process then just bookmaking a page for return. After reading my post it may seem that I was drawing the conclusion that it did not matter because the user must log in anyways.

The session expiration is a problem and I don't believe that it is the end all of a role your own system. This is where Ajax and a keep alive are now starting to help in fixing this model as you can issue keep alives without user interaction. By no means is the session based roll your own model the end all be all but it offers far more flexibility than HTTP Authentication.

Re:Weaknesses of "prototype.js"

[rossifer]

I agree but I think the problem is that as many of us use Echo2, we find less and less reasons to use book-marking capabilities.

This sounds like an inversion of the "Golden Hammer" antipattern. Maybe call it the "Missing Screwdriver" antipattern. "If you can't find your screwdriver, you tend to stop using screws, even when they're the most appropriate faster." Not incredibly catchy, but who knows?

Thanks for the good discussion, in any case. I always enjoy learning something new.

Regards,
Ross

Re:Weaknesses of "prototype.js"

[rossifer]

faster => fastener

*sigh* Darn you too-quick preview!!!

Regards,
Ross

Re:Weaknesses of "prototype.js"

[FecesFlingingRhesus]

Don't worry about it; I have severe dyslexia as you may have gathered from my spelling mistakes. So compared to me you look pretty good. I thank you for the discussion as well.

Re:Weaknesses of "prototype.js"

[FecesFlingingRhesus]

Yeah, I know it sounds wacky but I guess you would just have to see the application in action to understand the mitigation to bookmarks it does. My team is pretty well verses in a variety of frameworks. With a lot of experience in ASP / ASP.NET and JSP / Servlets so my guys do have a lot of experience with the options available and the design philosophies, but with the dynamic nature of Ajax it has been extremely easy for out users to implement document retrieval solutions that are more robust than just book-marking. Case in point I had one developer that built an XML file format that could save any applications state and be emailed, IM'ed or stored and then that application and session could be recreated via that document to the T. The user could pick up at any time (a year later) exactly where they left off. We are currently cleaning up the code and are going to submit it as an open library. It's like book-marking on steroids.

Re:I haven't heard much

[Gentlewhisper]

>Nobody. They're all to busy hyping it and posting on slashdot about how great it is. Meanwhile all us PHP/JSP/ASP/whatever
>programmers are off actually making web applications.

They can afford to do so, afterall writing a web app with those dinosaur languages take 5-10X as long when compared to Rails...

Zope - What RoR wants to be when it grows up.

[Qbertino]

You know a thing is superhyped when v1.1 is mentioned on slashdot.
Mind you RoR is cool compared to j2EE. Then again, it's allmost as if C is cool when compared to J2EE. J2EE sucks big time for server side web - even the Java Gurus agree on that. End of discussion, no news here.
But RoR isn't the end all of ssi frameworks. Django is at least as good (I'd say better and cleaner than RoR) and Zope has been around since the ninties and still is years ahead of the rest. People with an overview over the technologies generally agree on that. I had a story submission (rejected) on that the other week. Check out the linked webcast, it's a very interessting analysis of a set of technologies and solutions:

|||||
Nasa/JPL Web Framework Shootout

In an educative and entertaining webcast, Sean Kelly, a Nasa/JPL software engineer, goes into the details of a project based comparsion between a set of web application frameworks and servers. Including the much hyped Ruby on Rails and Django. Various Java technologies, Ruby on Rails, Django, TurboGears and Zope are covered. Details and traits of each are mentioned. For people involved with web developement there are not to many suprises though, yet the presentation and Kellys commenting are fun to watch.
In a nutshell: EJB, Hibernate and various other Java flavours fail spectacularly, Zope scores a clear victory with Django, RoR and TurboGears relatively close behind. Development speed, error-gotchas, the need for hand-tweaking and the requirement of handwritten SQL and available documentation go into the measuring. As does an overall tongue-in-check "fun-factor". The details are interessting though. TurboGears 'error-driven' developement gets a positive review, RoRs automated controller generation aswell and Zope gets a complete rundown on it's astounding set of features. In the end long-time Java developer Kelly convinces us that - no matter what we do - we really, positively, don't want to use EJB or Hibernate for this kind of stuff. Very entertaining and informative indeed.
|||||

Re:Zope - What RoR wants to be when it grows up.

[MemoryDragon]

Depends on which part of J2EE, Servlets are fine, JSPs are fine, EJB2 sucks big time, no discussion about that. While JSF and EJB3 is very good.

Re:Zope - What RoR wants to be when it grows up.

[Senzei]

Zope is awesome for the things that zope already does. Extending it involves crawling pretty far into the zope system though.

Re:Zope - What RoR wants to be when it grows up.

[ubernostrum]

In an educative and entertaining webcast, Sean Kelly, a Nasa/JPL software engineer, goes into the details of a project based comparsion between a set of web application frameworks and servers. Including the much hyped Ruby on Rails and Django. Various Java technologies, Ruby on Rails, Django, TurboGears and Zope are covered.

Except he got more than a few things wrong. To pick one example, he seems to be under the impression that Django doesn't support i18n/l10n when, in fact, we ship all the core Django applications with support for twenty-odd languages, and Django uses an extensible gettext-based system to make it easy to translate third-party apps and add new languages. We even include an i18n JavaScript library to make translation strings available to JS code. Our admin app even has a setting that chooses which language to render a page with based on the incoming Accept-Language header.

Moral of the story: nice video, but the guy hasn't necessarily done his homework.

Re:Zope - What RoR wants to be when it grows up.

[reginaldangermouse]

Isn't Zope a lot more restrictive than Ruby On Rails? It was when I last looked!

Re:I haven't heard much

[digidave]

I wouldn't say the Rails MVC model speeds things up that drastically, but it sure does make sure your app will be maintainable. That's what MVC is all about anyway.

Re:I haven't heard much

[Sokie]

I think an important thing to note here is that Rails is an web application framework for the Ruby programming language whereas PHP is just a programming language (with a few framework-ish features like session management).

You could see similar productivity benefits by using a good PHP framework. The difference is that Rails is a fantasic framework and most of PHP's frameworks are mediocre. Part of this has to do with some of the language features that Ruby offers enabling Rails to be simpler to use and yet more powerful at the same time.

Personally, I love Rails and I really hope that one of the recent PHP5 frameworks gets up to the point where it is comparable. If it doesn't though, I won't feel too bad leaving PHP (mostly) behind me.

Re:I haven't heard much

[digidave]

First, scaffolding helps getting started because the programmer can work on code rather than building forms that connect to the database. The trick there is to use the 'generate' script to create the scaffolding in real code rather than use the run-time scaffolding. The generated code is pretty clean and does the bare minimum required, which is a great platform for building on.

Second, with ActiveRecord the code feels very close to the data. When working within Rails' naming conventions it's very simple to do stuff like track back and forth in a data record and figure out what belongs to it (foreign keys referring to your data) and what it belongs to (foreign keys in your data referring to other data). Honestly, it seems heavy, but it works so well you forget about that. There have been a few times where I needed some data and found it already in my model object because the database relationship was there. This stuff has been made even better in Rails 1.1 because it stretches the relationship even more (relationships through other tables).

Everything also gets done with a lot less code both because Rails makes things easy and because Ruby is designed really well.

Re:Getting started

[CptPicard]

Hear hear, this is so true. Although I have been writing small Ruby scripts for a few years now, when I first took a look at RoR, I often had to pause to understand what exactly was happening in those very terse lines of code. You really need to understand Ruby's syntax and a lot of the philosophy quite deeply before you can grasp what is going on in RoR code. Without that understanding, you will never advance further in RoR than copying the tutorials.

This is an example of a more general syntax-vs-semantics tradeoff in programming languages. Sure it's impressive how little code you have to write, but the other side of this is that the required understanding per line of code density is higher.

Ruby on Rails?

[grimsweep]

I'm still waiting for C# on Cinderblocks.

Re:Ruby on Rails?

[fbg111]

You'll find it beneath a pier in Atlantic City, NJ, where Tony Soprano threw it into the water with cinderblocks chained to it, after he got fed up and switched to Ruby.

Re:Ruby on Rails?

[Game_Ender]

That would be Monorail: http://www.castleproject.org/index.php/MonoRail.

Upgrading IS painful

[Anonymous Coward]

Both Typo and the popular Globalize plug-in break down when run on Rails 1.1. So far for seamless backwards compatibility unfortunately.

Re:I haven't heard much

[larry bagina]

If you're doing strightforward CRUD database stuff, RoR automagically sets up everything for you. If that's good enough, then you've saved some time. Even if you need to tinker with it, it's often less work than other languages.

Re:Upgrading

[Seanasy]

You can also use Darwinports to install ruby and ruby-gems and whatever DB you want. Caveats: you have to install swig if you're using sqlite, you have to change a shebang or two to avoid conflicts with the installation of ruby that ships with OS X.

Re:I haven't heard much

[MemoryDragon]

Depends on where you live, I have yet to see a .Net deployment while I came across 10 java projects and several rails projects the last year. PHP on the other hand is slowly dying over here, only one PHP installation or so.

Oracle support

[dpletche]

We're dying to use Ruby on Rails. Developers in my group talk about it almost daily. Unfortunately the lack of solid Oracle database support is a showstopper. I'm inquiring about whether we might allocate funding to sponsor development of a stable, complete Oracle driver; my employer has a history of funding open source projects.

Re:Oracle support

[matchboy]

You might consider migrating away from Oracle to PostgreSQL. ;-) ...or give us a call and see if we can assist your Oracle driver development.

Re:Oracle support

[Forbman]

What do you need/want the Oracle driver to be able to do?

Still missing: many to many support

[jopet]

What I missed in rails most is proper support -- and that includes decent scaffold generation support -- for what is the most frequent case in nearly every non-trivial database application: many-to-many relationships. Thsi means showing an antry from tableA and in the same screen a scrollable/pageable list of entries from tableB which are connected through a join table with options for inserting or deleting tableB entries from/into the join table (and tableB, if necessary). From the release notes it seems that nothing has been done to make rails support this better. So, essentially, you have to do everything yourself again and you probably have to work around the problems regarding the id column in the join table.

Re:Still missing: many to many support

[ubernostrum]

What I missed in rails most is proper support -- and that includes decent scaffold generation support -- for what is the most frequent case in nearly every non-trivial database application: many-to-many relationships.

Many-to-many relationships? Rails may or may not have them (been a while since I last played with it), but Django most certainly does. We don't have "scaffolding" (though somebody's submitted a patch to do something similar), but we do give you a ready-to-go administrative interface built from introspecting your models, and it's got some nice tricks for displaying many-to-many relations. We also give you a lot of other useful stuff like generic views pre-written to handle most common tasks (CRUD, date-based object listing and navigation, etc.) so you just need to write templates and hook up to them; Django was extracted from the codebase of several large content-oriented sites, so it's really good at that sort of thing.

Disclaimer: I work for the company which originally developed Django. Though I didn't work there at the time; I applied because I liked Django and wanted more opportunities to work with it.

Re:Still missing: many to many support

[RegularFry]

We don't have "scaffolding" (though somebody's submitted a patch to do something similar), but we do give you a ready-to-go administrative interface built from introspecting your models, and it's got some nice tricks for displaying many-to-many relations. We also give you a lot of other useful stuff like generic views pre-written to handle most common tasks (CRUD, date-based object listing and navigation, etc.)

Sure sounds like scaffolding to me :-)

Re:Still missing: many to many support

[ubernostrum]

Sure sounds like scaffolding to me :-)

Not really. The idea behind Rails' scaffolding is to give you basic, unstyled example CRUD views that you're expected to throw away once you've built customized ones; they're a starting point. Django's admin application, on the other hand, is a production-ready, fully-styled application with manipulation of related objects, fancy JavaScript widgets (e.g., date and time selection, automatic population of URL "slugs", etc.), an auth system and full logging of user actions. And when I say "production-ready" I mean "production-ready": many Django applications in the wild find the stock admin application more than sufficient for their needs.

And the generic views really aren't scaffolding, either, because they're not meant to be thrown away and replaced with something you develop yourself, the idea being that some tasks (CRUD, lists of objects, detail of a particular object, date-based navigation, etc.) are so common you shouldn't have to write views to do them. So Django has a full set of generic views for these tasks, and all you have to do is route URLs to them for input and hook them up to page templates for output. I think the apparent similarity here comes from the nature of Rails' templates -- in Rails, the "view" and the "template" aren't separate, and you just have a "view" that's a mixture of HTML markup and embedded Ruby code. Django separates application logic from the templates, so a view in Django is pure Python, and returns a dictionary of variables and values to be used inside a template with deliberately simple syntax.

Re:Still missing: many to many support

[Forbman]

has_and_belongs_to_many... It just works.

Re:I haven't heard much

[PHPfanboy]

Interesting. Naturally we have no idea who you are, but from what I've seen (admittedly I've only spoken with hundreds of web development and systems teams over the past few years), the insurance industry is a Microsoft shop. That's about it. Most large companies (at least in Europe) are using Java as legacy and many are starting to drop PHP apps on top of them as Java re-usability is proving not to be as easy as it sounds and it takes a long time to get new Java projects out the door.

In addition, contrary to your claim, Open Source is indeed everywhere and mainly on the back of Linux which is replacing proprietary Unix which as you know is present in almost all large companies but also for the largest web clusters around (large web cluster != large company)

For some reason you've neglected to tell us all that in fact most large companies have a selection of technologies for a variety of historical and strategic reasons. I have rarely heard of a company using just one technology, though plenty claim to have only J2EE. What this says to me is that they are still 18 months from weighing alternatives as Java is overkill for many web projects (not my opinion, I'm not an application architect, just saying what I hear from others).

Incidentally, I have rarely seen MS SQL being used for web projects, MySQL is all over the place and serious players use Oracle (for the clustering). DB2 users suffer in general, though from what I've heard, they have bigger installed base than Oracle (just not for web projects).

In short, I have no idea which companies you're working with or where, but my experience is the complete opposite to yours.

I did hear of one Ruby project and that was a porn site in the Czech Republic, but I'm guessing I'm not speaking with the right people. I never heard of whole sites being migrated to Ruby, but I guess from the amount of buzz that some fun new stuff is being done with it.

All in all I'd say that despite techies pet hate for "marketing", Ruby is indeed being marketed loudly and enthusiastically by its community (I wonder why...) which goes to show that developers are no more immune to peer pressure and smart marketing than anyone else, they just think they are because they don't understand marketing.

Re:I haven't heard much

[pinkstuff]

"The code will be way cleaner because Ruby is a better designed language than either Java or PHP"

Okay, I admit that I don't know Ruby from a bar of soap - but I find it extremely hard to believe that it is a better designed language than Java.

If you mean that Java is hard to write web applications in, then yes, I admit there is a steep learning curve, but as a J2EE developer I can tell you that the last site I setup it took me more time to sort out the layout with style sheets than writing all of the ORM's in Hibernate! :). Admitidly it was a small website with only a handful of tables, but that just goes to show that it can be quick using Java tecnologies for any size site.

I would really like to know what in particular makes Ruby a better designed language, honest question, not flamebait! I am always open to new technologies, but what in particular would make me want to try RoR over other new 'web languages'? No one seems to say why it is so great other than 'it's faster to develop in' or 'it just is' :), but why? excluding the j2ee learning curve of course.

Re:I haven't heard much

[MemoryDragon]

Actually lets sum the situation up: I have done one insurance project, one project for an international corporation, I have been involved in one project for a poltical party and currently working on another big project for a public institution. I have yet to encounter a .net project there.

Most banks over here and insurances use Java due to the connectivity into their RS6000 and AS4000 environments.

Also banks usually are very IBM centric and most people working in banks I have met in the last year were very java centric. What I could gather in the last year however, was a certain shift away from J2EE EJBs towards Spring and servlet runner only installations.

Re:I haven't heard much

[Senzei]

I would say that most of the really big number time comparisons are to java, specifically to J2EE. Compared to PHP, especially PHP under a decent web framework, it does not have the same kind of productivity gains. That said ruby on rails is probably a better environment simply due to the quality of the languages involved.

Re:I haven't heard much

[MPHellwig]

Every language is elegant if you know enough about it to do your job and ,despite that knowledge, don't have the motivation to learn something else. Me, I started coding in python a year ago, being my first 'real' language, I've come to a point where I'm even productive, so for me python is elegant. But I don't rule out the possibility that other languages are more elegant. Perhaps the best way to find out is to (re)do a project or 2 in another language. But I will continue python for a while, I still find it fun to do work with it and I still have to learn tons about the language and programming in general.

I'm having fun with this

[osgeek]

I've been dabbling with Rails and Ruby for a couple of months now, and I don't want to get into a big debate on whether it's more efficient, more popular, or whatever semi-quantifiable metric you want to apply to it...

The bottom line for me right now is that I'm having fun with it. I've been really looking forward to the little extra time I've put aside each day to work with Rails; although I think that a lot of the fun I'm having is just pleasure at using Ruby.

Re:I haven't heard much

[fbg111]

I would really like to know what in particular makes Ruby a better designed language, honest question, not flamebait!

For starters, here's Steve Yegge of Amazon.com on languages, including Ruby.

Stevey Tours (and bashes) C, C++, Lisp, Perl, Ruby, Python.
Stevey on Languages: A Quick Tour of Ruby

And some more non-Ruby-specific, but interesting articles there, like this one.

It may be a little basic...

[Run4yourlives]

but here's something you might be interested in:

http://jrhicks.net/Projects/rails/has_many_and_bel ongs_to_many.pdf

Re:It may be a little basic...

[jopet]

Thank you for the link -- I knew this before and it kind of proves my point: it shows how lacking Rails is with regard to many-to-many relationshipt support (the has_and_belongs_to_many declaration is not really do anything useful). No reasonable scaffolding is done and what you need to do you have to implement yourself.

If you compare this with what e.g. MSAccess (and to a certain extend even OpenOffice) can do out of the box with a few keystrokes, the support for this in Rails can easily be called non-existent.

Re:It may be a little basic...

[Anonymous Coward]

HABTM is exactly what you're looking for.

class Color < AR::Base; has_and_belongs_to_many :people; end
class Person < AR::Base; has_and_belongs_to_many :colors; end

from there your model is wired up (using the table 'colors_people' for joins) to support things like:

jimmy = Person.create('name' => 'jimmy')
susan = Person.create('name' => 'susan')

red = Color.create('hex' => 'FF0000')
blue = Color.create('hex' => '0000FF')

jimmy.colors << red
jimmy.colors << blue
susan.colors << red

Want to get that data out?

Person.find_by_name('jimmy').colors.length ----> 2
Person.find_by_name('susan').colors.first.hex ----> 'FF0000'
Color.find_by_hex('FF0000).people.each { |person| puts person.name } ----> "jimmy\nsusan"

The relationships work both ways, and all over the ActiveRecord stuff is in there so it's fairly trivial to build a controller to manage the relationships - you can then bind that to some standard HTML forms, a web service, or some sort of Ajax monster. If that counts as nothing then I'm not really sure what needs to be done to make you happy.

Scaffold :foo is not inteded to produce anything but the most basic scaffolding for starting development. It doesn't do anything with joins because it's not supposed to. It doesn't build pretty forms with valid markup because it's not supposed to. It doesn't build ajax fancyness because it's not supposed to. It doesn't add confirmations to the destroy methods because it's not supposed to. Rails makes it easy to solve problems yourself, it doesn't solve them for you.

Re:It may be a little basic...

[James Kilton]

I still don't know why you think many to many is non-existant. ActiveRecord handles many-to-many relationships just fine. Take this example: table classes table students table classes_students The corresponding Rails code is: class Class From what your saying it sounds like you're not following Rails convention and as a result are required to manually specify the join tables and join columns (though those in themselves are also insanely simple). And since you've mentioned scaffolding, if the schema is following the convention, the scaffold created will have all the mappings done for you. Sorry, but this support is NOT non-existant.

Re:I haven't heard much

[pinkstuff]

I agree with you, only it's not that straight forward unfortunately. People are to quick to shoot down Java j2ee before they have actually learnt how to use it succesfully - they make a hash of their first website and move on without giving it a proper chance.

The problem is that most people don't have time to learn it succesfully AND also learn more than a couple of other languages succesfully, and in depth, so that they can make their own judgement. You have to really rely on what others experiences have been, or just choose a techonology you like the sound of and learn it inside out :).

So,

[Run4yourlives]

What's more expensive, developer man-hours or an extra server?

You draw your own conclusions.

Re:I haven't heard much

[ubernostrum]

I haven't heard much about Ruby since the (geek) media blitz of over a year ago. How many people actually use Ruby on Rails? I see the same thing happening with AJAX.

It's bad for publicity, but a lot of development with the new generation of web frameworks is taking place behind corporate firewalls and under NDAs. Some frameworks do advertise lists of public websites which use them, though. :)

Hello world

[amightywind]

Aaaaaand how is that different from desktop development? Actually, how is that different from any other development?

Maybe it is the switch between 3 languages to run 'Hello World'. Seems a tad overwrought. But I am wasting my time. Get back to your Visual Basic.

Re:Hello world

[Overly Critical Guy]

Maybe it is the switch between 3 languages to run 'Hello World'. Seems a tad overwrought. But I am wasting my time.

Running "Hello world" on the console calls several different APIs, some in different languages based on the platform you're using. Displaying a "Hello world" dialog in Windows will go through several layers. Displaying "Hello, world" on a cross-platform framework for client browsers will also go through several initial application layers. These are just things you need to accept as a newbie programmer (which you clearly are).

Get back to your Visual Basic.

Clearly, you have absolutely no counterargument, and I acknowledge that.

Next.

See it & Try it & You're a Star?

[JoeRails]

Who's using Rails? Check out the Rails wiki site for hundreds of example sites

And if you want a free cPanel/SSH account to download the new Rails version in to see what the craziness is all about - check out www.HostingRails.com

I think its safe to say that Ruby on Rails is the fastest growing Web 2.0-friendly framework - and for good reason. I mean c'mon - the average developer can pick up a few Rails tutorials and have a working demo app (w/ CRUD scaffold action and such) on their local box in a few minutes. Throw in some easily-incorporated Prototype and Scriptaculous effects, and this developer is the new cool kid on the block.

Crazy

~JoeRails

Re:I haven't heard much

[Homestar Breadmaker]

Poorly. Catalyst is far more flexible, and doesn't force less than ideal choices onto you like rails does.

Gems vs. traditional install?

[fossa]

I've used gems; it's very convenient from a single user who is writing ruby scripts and needs extension X. But say I want to distribute an application written in Ruby. In my Ruby code, I'll have "require 'some_ext' ", which won't work for those who have 'some_ext' installed via gems. Alternatively I could have "require 'rubygems'; require_gem 'some_ext'" which would work for the Gem users but not traditionaly installed extensions. Is there or will there be a solution to this, and what is it?

It seems the major hurdle in making code that uses either the Gem version or, if not there, the traditional version is the fact that Gems allow versioned includes, e.g. "include_gem 'some_ext >= 0.3' I've heard some complain about this and others state that this is a very useful feature.

One possible (but somewhat annoying) solution is to distribute a version with traditional includes and distribute a Gem using version via gems. Can Gems distribute apps (i.e. stuff that would go into /usr/bin) ? And even this would not solve the problem as I imagine much of the standard library would be installed traditionally even for users of gems, so the application would still not know how to require an extension.

The big question is...

[Homestar Breadmaker]

Since rails people always trot out this "scaffolding isn't supposed to do X" answer no matter what X is, the question remains: WTF is it supposed to do? Why is scaffolding even in rails, and why is it such a prominent and hyped "feature" when it is totally useless?

Re:The big question is...

[I Like Pudding]

It is neither prominent nor hyped. There was one example video that I can think of in which scaffolding was prominently featured, and now it seems to be the most mentioned topic by everyone who aren't familiar with the framework. All scaffolding does is create dead simple create/read/update functionality in a controller for a model. This is moderately useful at the beginning of a project where it saves you time writing bootstrap code, and not at all useful towards the middle/end when everything is already written. HENCE THE NAME, PEOPLE.

Re:The big question is...

[Homestar Breadmaker]

"It is neither prominent nor hyped."

It is both. Go watch the videos.

"All scaffolding does is create dead simple create/read/update functionality in a controller for a model."

Yes I know. That's why I asked why its even in rails at all, much less featured in videos.

"This is moderately useful at the beginning of a project where it saves you time writing bootstrap code"

No, its not. I can already add/update/delete/view things in the database, how do you think I created the database to begin with? This is what I mean. The only thing you can use scaffolding for is to be like a really crappy database admin tool. But you already need a database admin tool anyways, so what's the point of scaffolding?

Re:The big question is...

[I Like Pudding]

"All scaffolding does is create dead simple create/read/update functionality in a controller for a model."

Yes I know. That's why I asked why its even in rails at all, much less featured in videos.

No, according to your post, you didn't. You said "WTF is it supposed to do?", which I then answered. Were you dropped on your head as a child? Repeatedly?

"This is moderately useful at the beginning of a project where it saves you time writing bootstrap code"

No, its not. I can already add/update/delete/view things in the database, how do you think I created the database to begin with? This is what I mean. The only thing you can use scaffolding for is to be like a really crappy database admin tool. But you already need a database admin tool anyways, so what's the point of scaffolding?

I just told you what it is and why its there, and you ask me a second time. What is wrong with you? How can I force this knowledge into the dense region of space that is your head when you cannot even make sense of the written word? Wait, I know!

Second attempt, fortissimo: A WEB FORM IS FASTER. IT ALSO VALIDATES. MANUALLY INSERTING, VIEWING, AND EDITING COMPLEX DATA VIA SQL IS IRRITATING FOR MOST.

Re:The big question is...

[Homestar Breadmaker]

No, a web form is not faster. And your database is supposed to validate data unless you are retarded. You don't need to manually insert, view or edit complex data via SQL, there's plenty of graphical database admin tools out there. If you can create the tables to begin with, then you can obviously put data in the tables too. Hence scaffolding serves no purpose besides tricking people into thinking rails makes things faster than it really does.

Re:What a crock

[handslikesnakes]

XML + HTTP != SOAP

How about Catalyst?

[pasti]

I did a database-oriented web app last year. I found Catalyst http://catalyst.perl.org/ really really useful. The MVC pattern it imposes on you really helped. Ditto for the web framework, plugins, DB access and scaffolding.

From what I can tell, RoR is conceptually pretty close to Catalyst, but me being a perl-head, I chose Catalyst. Anyone tried them both? Any comments?

Re:How about Catalyst?

[it0]

I'm a c/perl guy and don't know catalyst but wrote some sites in perl using html::template and I just read http://www.perl.com/pub/a/2005/06/02/catalyst.html ?page=2 for a short tutorial.
I also just made my first rails website in 10 days, this includes a cms and also an elobarate scheduling app as well as some other stuff like user manager etc. This also includes the time to learn the language and get my head around concepts. The major problem with rails is documentation, there is just to much of it scattered around and should be organised more. But with the rails api website, the ruby docs and some tutorials you will get there.

The last 2 days was just finetuning what the customer wanted. From the tutorial I would say rails is easier to read. I think perl has more power over ruby, just as C has more power over Perl as you can go more low level with it. But ruby/rails is much easier to read and even less to type.
I will still remain to use C and Perl for a lot of stuff. But when it comes to websites / web applications I will stick with rails. I can't see myself turning back. Maintaining and extending code is dead easy also the ajax integration is great.

Re:I haven't heard much

[Anonymous Coward]

PHP is an ugly abomination of a language, while Ruby is simple, elegant and fully oo. The reason I've switched to RoR is Ruby, not Rails.

Re:But still doesn't scale

[ObsessiveMathsFreak]

Or maybe we could all get a link to the actual article itself, rather than someones blog linking to the article.

Re:I haven't heard much

[PHPfanboy]

Ah yes, I forgot pharmaceutical companies are big Microsoft shops. The types of companies you're dealing with make a lot of sense. TV stations are taking loads of Microsoft stuff as they're pushing IPTV big time. Lets assume the account managers are shoe-horning as much extra as they can into "IPTV" deals.

Petrol company. Interesting. Normally I'm seeing Java there (or outsourced and don't care).

Large retailers is interesting, I normally see Java there too as the projects are done by large System Integrators and let's face it, if you sell services by the day Java is such an obvious choice. Guess it just depends who wins the project.

Longer term I reckon Rails will take from some Java growth, from Python and maybe top end PHP stuff, but despite the buzz, I can't see its sweet spot yet.

Re:I haven't heard much

[gnufied]

http://it.slashdot.org/article.pl?sid=06/03/28/163 4201 perl rulez...

Great news!

[matchboy]

My Rails development firm has been working with Rails for over a year now and as of early last summer... we're exclusively Rails-focused. We've been working with features in 1.1 for several months now and are glad to see that these features are now part of the 1.1 release.

Ruby on Rails on PostgreSQL = Enterprise Rails! :-)

Re:Getting started

[Inkieminstrel]

It should be noted that the book you linked is available for free online at http://www.rubycentral.com/book/ It's very good for learning the language.

Re:I haven't heard much

[lucaslucaslucas]

Yes, cause new versions of a language fix programming errors ;-)

By the way, are you the same Mirko from the bsd-cert list?

API confusion

[amightywind]

Running "Hello world" on the console calls several different APIs, some in different languages based on the platform you're using.

What a silly fellow! Hello world in C to stdout (you mistakenly refer to it as a "console") is pretty butt simple in C. Even you should be able to understand it. The call graph is:

main()
>puts()
>>putc()

Nope, no "layers" here, one API. Ding!

Displaying "Hello, world" on a cross-platform framework for client browsers will also go through several initial application layers. These are just things you need to accept as a newbie programmer (which you clearly are).

And what would those be? Be careful, you won't find it in your "Java for Dummies" book. (Ouch, that must have hurt!)