The SitePoint Forums have moved.

You can now find them here.
This forum is now closed to new posts, but you can browse existing content.
You can find out more information about the move and how to open a new account (if necessary) here.
If you get stuck you can get support by emailing forums@sitepoint.com

If this is your first visit, be sure to
check out the FAQ by clicking the
link above. You may have to register
before you can post: click the register link above to proceed. To start viewing messages,
select the forum that you want to visit from the selection below.

Rails for educational use

Hey Ruby people,

Firstly I must say that I am extremely impressed with both Ruby and the Rails framework. I started a thread on why I thought ASP.NET was a bad place to start teaching web programming and building web applications, and the more I think about it, teaching Rails would be a much better alternative than PHP or ASP.NET - after students have a solid understanding of server-side proccessing and HTML/CSS and Javascript.

I haven't done much Rails development at all, but the mentality of a framework like Rails seems to sit so much more nicely to me. While still being able to leverage the code-generating scripts available in Rails nothing is ever hidden from view. Rails seems to encourage you to customise the output of things like the Scaffolding tool. Where-as ASP.NET seems to just use the pre-packaged solution and plug it in.

I also think the MVC model is an excellent one to teach as best practice. Keeping a clean separation of these areas will inevitably encourage well structured applications.

While there isn't a huge amount of work available for Rails developers in industry at the moment, the skills gained by learning Rails at uni would make the students better developers in general. And more able to pick up another technology.

I agree. I am pretty new to Ruby and Rails, but I have learned far more from it in the past month or so than all my years in school. I learned very little about best practices in school honestly. Even if you never plan on using it for production applications, I think it is a great educational tool for improving programming skills in general.

I also think the MVC model is an excellent one to teach as best practice. Keeping a clean separation of these areas will inevitably encourage well structured applications.

ASP.NET is going to support the MVC model so soon, actually you can use it even now by writting your own framework or using some 3-rd parties, anyway I mean that that ASP.NET MFC Framework is written by Microsoft.

ASP.NET is going to support the MVC model so soon, actually you can use it even now by writting your own framework or using some 3-rd parties, anyway I mean that that ASP.NET MFC Framework is written by Microsoft.

Actually, if you hate magic abstractions and frameworks, you are going to hate rails. Funnily enough, I am not a huge fan because of the nasty amount of abstraction and magic naming that makes it go. But that is probably just the uber l337 DBA in me.

Funnily enough, I am not a huge fan because of the nasty amount of abstraction and magic naming that makes it go. But that is probably just the uber l337 DBA in me.

I'll agree with this, it's a difference of approach. Database-centric people tend to hate Rails because 1. magic naming, 2. the activerecord gem which does a lot of behind-the-scenes work that lots of people don't see (not to mention that some people hate the activerecord design pattern), and 3. DHH's "I just use databases as big hashes" quote.

Rails is good for education because it gets fast results, which is encouraging for anybody trying to learn the language. It's also why people recommend stuff like Python and Logo as first programming languages. The language/framework might not teach you everything you need to know about programming/web development, but it will teach you enough high-level concepts and give you near-immediate results to help you decide whether or not you want to keep learning.

MS is considering complementing the ASP.NET model with a "web MVC" library (like Rails it is not the Smalltalk-80 MVC). So far it seems to sacrifice (part of) the composability of ASP.NET for a model which seems inferior to Rails, especially when it comes to the communication between controller and view. For that price they hope to make the controller more testable and thus better support a TDD/agile development. It is not a replacement of web forms, which will continue to be advanced.

Note, the template/codebehind/business object used by many in ASP.NET already constitutes a MVC pattern which on a number of key characteristics is more in line with the original smalltalk-80 pattern (notably composability/recursivity, view persistence, view/model communication, controller role) then the "web MVC".

MS is also introducing "dynamic data controls" which is like scaffolding but will melt away more gradually when you customize/override them.

Having said that, Ruby is a beautiful language. It has a clear vision and a terse and intuitive syntax. It is a wonderful language for education as it stresses to-the-point code, abstractions, reusability.

Without getting into the nitty-gritty details of Ruby compared to other languages, I think it's roughly a Good Thing to teach first. With a few caveats, though.

On the good side of things- MVC, Testing, separation of code, a beautiful base language, some best practices are stressed (once you're in Rails it's easy to go with the flow and start using Subversion, testing, and so on). In many respects it's a good way to orient people in the right direction for these aspects. I've seen some of my fellow students here at school take a PHP class a few years ago and the nonstandard way of using PHP with a half-baked framework built by the professor had more people confused about MVC than you'd imagine. That's really just an argument for frameworks in general, though, as it helps people orient their thoughts in that regard.

But I digress. I think there are two negatives in regard to Rails in the classroom: the "magic" as was mentioned earlier, and environment setup. The "magic" of Rails can either be good or bad- if you're teaching a bunch of business majors who don't *really* need to know the nitty gritty details, that's good, but if you're trying to ground some CS majors with some web specifics, well, that might not be as appropriate (though it could be argued that this would give them a foundation to investigate the magic further once they're ready to move on).

Secondly, deployment and development environment for Rails still remains a bit tricky, in my opinion. Even with things like Locomotive or InstantRails there can still be some tricky stumbling blocks right out of the gate for someone new to the language or the environment. I feel like this will be greatly improved in the next 1-2 years of Rails maturity, but right now it's just not as painless as some other languages, unfortunately.

Actually, if you hate magic abstractions and frameworks, you are going to hate rails. Funnily enough, I am not a huge fan because of the nasty amount of abstraction and magic naming that makes it go. But that is probably just the uber l337 DBA in me.

My experience with Rails is limited so I can only talk of the first impressions, but all the code and HTML in the view is available for you to modify - This isn't abstracted at all. So using the scaffold command for example creates a bunch of pages in the view that you can then modify. The database model is largely abstracted though. So as I understand it - the front-end isn't abstacted to the same level as .NET.

.., but all the code and HTML in the view is available for you to modify - This isn't abstracted at all.

Oh yes it is. link_to, link_to_remote, button_to, text_area, text_field, radio_button and many more are all html emitting helper functions; the widgets of Rails, if you like. They take parameters which let you control their behavior, but it is not transparent what the actual html will be. The helpers make sure that e.g. routes are respected, that field ID are consistent with the validation (so that Rails can automagically highlight the errorneous fields) etc.

flash is an abstraction of error summary, sometimes carried over from page view to page view.

Most of Rails AJAX is implemented using abstractions. Indeed, the RJS views encourage you to write JavaScript in a Ruby abstracted form.

All of these abstractions work remarkably well, but they will not teach you the basic HTML stuff. They allow you to program forms and navigation on a higher level.

My experience with Rails is limited so I can only talk of the first impressions, but all the code and HTML in the view is available for you to modify - This isn't abstracted at all. So using the scaffold command for example creates a bunch of pages in the view that you can then modify. The database model is largely abstracted though. So as I understand it - the front-end isn't abstacted to the same level as .NET.

See what Honeymonster said about ruby's html layer abstractions. At the same time, it also abstracts/autogenerates the important bits of the application based on alot of magic naming schemes.

If you want to feel what the web was like before all these abstractions, write an ISAPI DLL that handles raw HTTP request-response at a binary level. Ah for the old days where men were men and web applications were web applications.

These helpers are quite differen't to the controls built in .NET
Have a look at the one line of code each of those examples generates - These helpers, in fact only save you from typing the single HTML element in it's full form.

The back-end is heavilly abstracted though and maybe this would make it an unsuitable first language, Though I definitely think Rails and Ruby has a lot of educational value so should be offered as an elective.

These helpers, in fact only save you from typing the single HTML element in it's full form.

That is incorrect. Many of the helpers are essential in building the site navigation by generating the correct urls. Some of them will inject JavaScript if you define :confirm in the options hash. And when you code rJS views you use all kinds of functions which will emit javascript to replace, insert or delete elements in the client DOM.

The most notable difference to ASP.NET tags is that ASP.NET tags are object oriented where Rails' helper methods are just that, methods.

I don't feel that abstractions are bad for learning. As another poster asked, if yoy want to learn HTML+CSS, why would you use Rails (or ASP.NET) for that? Now, if you want to see an example of a consistent, well designed programming language, Ruby is a very good example. If you want to try working with a framework with strong architectural (and philosophical) guidance, Rails is a very good subject.

I don't feel that abstractions are bad for learning. As another poster asked, if yoy want to learn HTML+CSS, why would you use Rails (or ASP.NET) for that? Now, if you want to see an example of a consistent, well designed programming language, Ruby is a very good example. If you want to try working with a framework with strong architectural (and philosophical) guidance, Rails is a very good subject.