Rails isn't for beginners(rakeroutes.com)
rakeroutes.com
Rails isn't for beginners
http://rakeroutes.com/blog/rails-is-not-for-beginners/
10 comments
You're right, this applies just as much to Django. I should really have said, "Frameworks aren't for beginners". A framework allows an expert to get going without dealing with the trivial details; but to the beginner there are no trivial details.
I think it depends on the framework.
A full-stack framework such as Rails or Django isn't going to help with learning because it 'magics' too much of the underlying structure of building a web app away. You end up using so many proprietary pieces, all of which "just work" (and don't worry how, just know that it does) together.
Conversely, micro-frameworks such as Sinatra and web.py (the structure of which inspired App Engine's webapp, and Friendfeed's Tornado) get rid of just enough of the underlying complexity of getting Ruby/Python to talk to a browser to, as is often said, let you feel as if you are writing a Python (or Ruby) web app, rather than a Django (or Rails) web app.
Perhaps the middle ground for your students is frameworks such as Flask and Pyramid, which start as a micro framework, but which offer the full-stack batteries included features as and when you need them.
A full-stack framework such as Rails or Django isn't going to help with learning because it 'magics' too much of the underlying structure of building a web app away. You end up using so many proprietary pieces, all of which "just work" (and don't worry how, just know that it does) together.
Conversely, micro-frameworks such as Sinatra and web.py (the structure of which inspired App Engine's webapp, and Friendfeed's Tornado) get rid of just enough of the underlying complexity of getting Ruby/Python to talk to a browser to, as is often said, let you feel as if you are writing a Python (or Ruby) web app, rather than a Django (or Rails) web app.
Perhaps the middle ground for your students is frameworks such as Flask and Pyramid, which start as a micro framework, but which offer the full-stack batteries included features as and when you need them.
I dunno if the magic is the real problem. I think the real problem with full-stack frameworks is that they require you to drink their entire pitcher of Kool-Aid in order to get up and running. There's no easy "Hello World" to give new users confidence.
Take Django for instance (because I have more experience with it than I have with Rails). Just to get through the introductory tutorial (https://docs.djangoproject.com/en/dev/intro/tutorial01/) you have to wrap your brain around projects, apps, views, models, and Django's command-line tools. Contrast that to getting started in PHP without a framework; you can introduce someone who only knows HTML to PHP extremely gently, by taking an existing HTML document (which they understand) and sprinkling in some PHP to do simple stuff. They won't be a programming god with that knowledge, of course, but that's not important; what's important is that they took the first step and succeeded, which gives them the confidence to take the second. With a full-stack framework, getting that first step right involves a lot of mental work, which increases the chances that people will screw it up or abandon it in frustration.
Frameworks frequently compound this problem by inventing their own terminology for features, or taking words people already use and redefining them, so you can't easily map things you already know from other systems to things inside the framework. Just in the Django intro, for instance, we have to learn the difference between projects and apps, both of which are commonly used terms that Django has overloaded with Django-specific meanings.
All of this means that taking the first step in going from "has never used Django" to "Django newbie" involves a lot of learning, and that guarantees that some people are going to just walk away and others are going to try to follow along but get lost in the complexity.
Take Django for instance (because I have more experience with it than I have with Rails). Just to get through the introductory tutorial (https://docs.djangoproject.com/en/dev/intro/tutorial01/) you have to wrap your brain around projects, apps, views, models, and Django's command-line tools. Contrast that to getting started in PHP without a framework; you can introduce someone who only knows HTML to PHP extremely gently, by taking an existing HTML document (which they understand) and sprinkling in some PHP to do simple stuff. They won't be a programming god with that knowledge, of course, but that's not important; what's important is that they took the first step and succeeded, which gives them the confidence to take the second. With a full-stack framework, getting that first step right involves a lot of mental work, which increases the chances that people will screw it up or abandon it in frustration.
Frameworks frequently compound this problem by inventing their own terminology for features, or taking words people already use and redefining them, so you can't easily map things you already know from other systems to things inside the framework. Just in the Django intro, for instance, we have to learn the difference between projects and apps, both of which are commonly used terms that Django has overloaded with Django-specific meanings.
All of this means that taking the first step in going from "has never used Django" to "Django newbie" involves a lot of learning, and that guarantees that some people are going to just walk away and others are going to try to follow along but get lost in the complexity.
Thank you, this is really helpful feedback. I can learn any technology I want to, but since programming is not part of my daily professional work I often have a hard time knowing what pieces are worth my time to learn. I've been thinking about Flask and Pyramid for a while, so I will check them out with an eye towards sharing them with students.
I wish I had you as my teacher...my teacher photocopied teach your self SAM series.
I agree completely.
A couple of months ago my sister approached my and asked "How do I learn how to make websites?" She has no programming experience, so I thought for a while on where to start. I figured if I showed her what I was working on in Python/Django, she would be completely overwhelmed. So I started with just HTML. As she worked through that, she started asking questions like, how to change layout and fonts, so we started working with CSS. She's not at the point yet, but I think PHP is going to blow her mind, as I've seen her copy/pasting stuff from file to file.
I think its important to start at the beginning and learn some of the pain points that these frameworks solve before jumping in. Otherwise you just get frustrated wondering why things are set up a certain way.
A couple of months ago my sister approached my and asked "How do I learn how to make websites?" She has no programming experience, so I thought for a while on where to start. I figured if I showed her what I was working on in Python/Django, she would be completely overwhelmed. So I started with just HTML. As she worked through that, she started asking questions like, how to change layout and fonts, so we started working with CSS. She's not at the point yet, but I think PHP is going to blow her mind, as I've seen her copy/pasting stuff from file to file.
I think its important to start at the beginning and learn some of the pain points that these frameworks solve before jumping in. Otherwise you just get frustrated wondering why things are set up a certain way.
That's the nail on the head right there. Without any context even the conventions of Rails seem like arbitrary decisions just to make things complicated. Once you understand the problem you can appreciate the solution.
I'm not sure. I remember learning HTML and CSS through WYSIWYG editors such as Dreamweaver (essentially abstractions, no?), and then getting frustrated by how much excess code it was adding. That then gave me the impetus to delve into the code and then begin learning the HTML, CSS, principles informing the design. Had I started back then trying to tackle HTML head on, I might have been overwhelmed.
Similarly, I'm trying to learn building web apps at the moment. I'd rather have some decisions taken for me by Rails (in the knowledge that they've been based on some kind of best practice / consensus) and try and build backwards from there. It's probably not the purists way of learning, but then I don't have the level of expertise a purist probably does.
Similarly, I'm trying to learn building web apps at the moment. I'd rather have some decisions taken for me by Rails (in the knowledge that they've been based on some kind of best practice / consensus) and try and build backwards from there. It's probably not the purists way of learning, but then I don't have the level of expertise a purist probably does.
Coming to Rails frustrated with the slog that you have to deal with otherwise is exactly the path that Rails was designed to accomodate. You know and appreciate the fact that Rails is making decisions for you to help you get going while a beginner would probably be overwhelmed by all the complexity.
Absolutely - and in fact, one of the virtues of the better Rails tutorials is that they do expose you to some of the complexity.
You learn to understand that things are passing between the model and controller, and the rough sequence of things. I've come to appreciate the basics of a RESTful approach, and why things are as they are. I'll of course need to take away the abstraction over time, but without having the abstraction in the first place, I probably wouldnt have started.
That said, I second the point about getting it installed. I shouldn't have to be on StackOverflow for that.
You learn to understand that things are passing between the model and controller, and the rough sequence of things. I've come to appreciate the basics of a RESTful approach, and why things are as they are. I'll of course need to take away the abstraction over time, but without having the abstraction in the first place, I probably wouldnt have started.
That said, I second the point about getting it installed. I shouldn't have to be on StackOverflow for that.
I think it would be helpful to explain a bit about the language of HTTP between the browser and server.
Perhaps that can help a lot to understand what the client is doing and what the server is doing. And it's pretty simple and straight forward.
Perhaps that can help a lot to understand what the client is doing and what the server is doing. And it's pretty simple and straight forward.
Learning to program is all about learning mental abstractions. A beginner will have no conceptualization of what a web application can or should do. Where an experienced web programmer from any language will hear requirements and immediately (and almost unconsciously) start building up a mental model of the problem domain, the beginner will still be struggling with how the system itself works. That will be true in any web development framework, because there’s simply no way for any framework to think through the problem for you.
This.
This.
This will probably get downvoted into oblivion (fair enough since it's a thoroughly unconstructive comment) but I'm really developing a pet peeve against comments that basically consist just of the word "This." or start with "This." and follow it with some tame form of agreement.
I find it about 2.44 times as annoying as someone commenting "upvoted". I now reflexively downvote any comment starting with "This.". I know I have no power to alter such a strong internet meme, but I thought I'd mention it to get it off my chest. Sorry for wasting your time with this post.
I find it about 2.44 times as annoying as someone commenting "upvoted". I now reflexively downvote any comment starting with "This.". I know I have no power to alter such a strong internet meme, but I thought I'd mention it to get it off my chest. Sorry for wasting your time with this post.
Funny. "This will probably get downvoted into oblivion" is my pet peeve. There's just something that irks me about a person who is putting up their opinion voluntarily seemingly knowing that it will not be reciprocated by others but provide a pretext hoping to fish guilt from others who may disagree. If you have an opinion stand behind it; take whatever berating you're about to receive in full confidence because what really matters if the community as a whole doesn't share the same outlook?
I don't think "This will probably get downvoted" is necessarily a fish for guilt.
To me, what it signals is that the commenter is aware of the unpopularity of the idea. They've given it a second consideration and still believe in it. By saying so, they're asking the reader to also give it a second consideration.
It's saying "this is more than a kneejerk reaction for me, please respond with more than a kneejerk reaction".
To me, what it signals is that the commenter is aware of the unpopularity of the idea. They've given it a second consideration and still believe in it. By saying so, they're asking the reader to also give it a second consideration.
It's saying "this is more than a kneejerk reaction for me, please respond with more than a kneejerk reaction".
[deleted]
Whenever I see "This", I picture a caveman pointing and barking.
[deleted]
There seems to be a fundamental misunderstanding about what "beginner" means for Rails.
I've been a .NET developer for over 10 years. I'm a Rails "beginner". I'd say I'm comfortable with web technology, and yet Rails was an absolute nightmare for me to get started with.
If the Rails community wants people like me to stop doing what they were doing and use Rails instead, it MUST be easier to get started with.
I've been a .NET developer for over 10 years. I'm a Rails "beginner". I'd say I'm comfortable with web technology, and yet Rails was an absolute nightmare for me to get started with.
If the Rails community wants people like me to stop doing what they were doing and use Rails instead, it MUST be easier to get started with.
I just got hired for a gig as a rails developer, and I feel your pain. I got hired because I primarily work with python, and have good experience with Django, flask and the like, but I had never really touched rails. From the various comments I'd heard, I figured it would be a simple transition, but man has it been annoying. Just setting up their dev environment took almost an entire 8-hour day, and I was one of the 'faster ones'.
Not to mention that having to deal with rails legacy code, you quickly realize that despite the original developer's best efforts, the whole magical+'convention over configuration' aspect of rails just totally goes against the concept of 'self-documenting code'. Compound that with the fragile version requirements of both Ruby and Rails, and you have a recipe for frustration. Out of any given search I perform, about a third of the 'relevant' results are for incompatible versions of rails, making it hard to find anything reliable outside the official docs (which leave a bit to be desired).
I may just be spoiled by the relatively conservative + documentation-heavy nature of most of the python frameworks I've worked with, but considering the popularity of rails (even amongst non-developers), I guess I just expected the barrier to entry to be a bit lower...
Not to mention that having to deal with rails legacy code, you quickly realize that despite the original developer's best efforts, the whole magical+'convention over configuration' aspect of rails just totally goes against the concept of 'self-documenting code'. Compound that with the fragile version requirements of both Ruby and Rails, and you have a recipe for frustration. Out of any given search I perform, about a third of the 'relevant' results are for incompatible versions of rails, making it hard to find anything reliable outside the official docs (which leave a bit to be desired).
I may just be spoiled by the relatively conservative + documentation-heavy nature of most of the python frameworks I've worked with, but considering the popularity of rails (even amongst non-developers), I guess I just expected the barrier to entry to be a bit lower...
Can you give more details? Bundler gives very strong versioning of dependancies, I find railstutorial.org, railsguides, and the api docs to be pretty complete, and "convention over configuration" means things like your models are singular names of your tables, and if you do something like "belongs_to :other_model" it expects an "other_model_id" field by default, and will link to to a class called OtherModel. It is the sort of thing that can be a pain if you don't know it, but can be learned quite easily, especially if you have more experienced folks your working with.
I learned rails and django at about the same time, and I never understood the praise of the django docs. Both projects have above average documentation for open source projects, but if anything I find the rails docs are far more consistently up to date compared to django. Both have helpful and active communities though (which is far more important imo), and I never really had that hard of a time figuring something out.
I think rails has a "For Noobs" reputation with people who have never used it, but as someone who didn't really have any preconceptions going in, I find this "rails 3 is hard" thing really hard to understand.
I learned rails and django at about the same time, and I never understood the praise of the django docs. Both projects have above average documentation for open source projects, but if anything I find the rails docs are far more consistently up to date compared to django. Both have helpful and active communities though (which is far more important imo), and I never really had that hard of a time figuring something out.
I think rails has a "For Noobs" reputation with people who have never used it, but as someone who didn't really have any preconceptions going in, I find this "rails 3 is hard" thing really hard to understand.
> It is the sort of thing that can be a pain if you don't know it, but can be learned quite easily
I agree, it's not terribly hard to pick up the basic idea, but it still doesn't lend itself to the idea of being 'self-documenting', which has always been a helpful fallback when dealing with python stuff that I encounter problems with. I guess it kinda just feels like it encourages too shallow of an understanding of what's going on, especially if for some reason I might want to tweak/customize certain things later on; it feels more geared towards giving you a fish, as opposed to teaching you how to fish (which is highlighted by the 'standard' encouragement to use lots of code generation). Even after going through the docs, it took me way too long to get even a vague idea of how to properly set up a custom model/migration without the rails generator tool. But I'll admit, that's all a lot more in the realm of personal preference.
Bundler is cool, but even with strict versioning, setting things up for the first time is no walk in the park. I won't blame rails for that though, that's clearly more of an ecosystem problem. A bigger problem than versioning though (in my eyes anyway), is when plugins follow this 'rails-way' of doing things magically, and leave no clear way to troubleshoot problems when they arise (devise, I'm looking at you).
I too find the rails guides and rails tutorial to be immensely helpful, but it's more because I would literally be completely lost without referring to them every 5mins, than because I find them terribly insightful. I know the django docs aren't really that much better, but since I can usually work my way around a django project without referring them as frequently, I guess my standards for them is lower? Same could be said for a lot of their plugins, because again, at least there I have been able to fall back on 'self-documenting code' most of the time.
I do think rails is pretty cool, and I could see why it got the praise it did, but I would probably only use it on small projects that involved only a handful of people from the get-go, because I would feel bad dropping a newbie onto a mountain of legacy rails code.
I agree, it's not terribly hard to pick up the basic idea, but it still doesn't lend itself to the idea of being 'self-documenting', which has always been a helpful fallback when dealing with python stuff that I encounter problems with. I guess it kinda just feels like it encourages too shallow of an understanding of what's going on, especially if for some reason I might want to tweak/customize certain things later on; it feels more geared towards giving you a fish, as opposed to teaching you how to fish (which is highlighted by the 'standard' encouragement to use lots of code generation). Even after going through the docs, it took me way too long to get even a vague idea of how to properly set up a custom model/migration without the rails generator tool. But I'll admit, that's all a lot more in the realm of personal preference.
Bundler is cool, but even with strict versioning, setting things up for the first time is no walk in the park. I won't blame rails for that though, that's clearly more of an ecosystem problem. A bigger problem than versioning though (in my eyes anyway), is when plugins follow this 'rails-way' of doing things magically, and leave no clear way to troubleshoot problems when they arise (devise, I'm looking at you).
I too find the rails guides and rails tutorial to be immensely helpful, but it's more because I would literally be completely lost without referring to them every 5mins, than because I find them terribly insightful. I know the django docs aren't really that much better, but since I can usually work my way around a django project without referring them as frequently, I guess my standards for them is lower? Same could be said for a lot of their plugins, because again, at least there I have been able to fall back on 'self-documenting code' most of the time.
I do think rails is pretty cool, and I could see why it got the praise it did, but I would probably only use it on small projects that involved only a handful of people from the get-go, because I would feel bad dropping a newbie onto a mountain of legacy rails code.
>>I agree, it's not terribly hard to pick up the basic idea, but it still doesn't lend itself to the idea of being 'self-documenting', which has always been a helpful fallback when dealing with python stuff that I encounter problems with. I guess it kinda just feels like it encourages too shallow of an understanding of what's going on, especially if for some reason I might want to tweak/customize certain things later on; it feels more geared towards giving you a fish, as opposed to teaching you how to fish (which is highlighted by the 'standard' encouragement to use lots of code generation).
I have been doing rails every day for about two years now, working on a moderately large (200k loc) app, and we very rarely go against the "rails way" of doing things wrt to naming. Like if you have a model called Post and a model called Comment with a line that says "has_many :comments" in the post, there is a lot going on. The name of the accessor will be called "comments", it will lookup data in the "comments" table that have an fk of "post_id" and materialize a collection of Comment objects.
I find those are good conventions, they are readable, and more importantly, they are consistant across all the rails apps I will ever see. So when I write new code, or am reading code I am not familiar with, there is this whole class of things I don't need to make decisions about, since there is already this implied group understanding of the way things should be.
Now, in the time I have been doing this, there have been probably around 3-4 times when I _have_ wanted to customize those things, but it is really so incredibly rare that I would go so far as to say you wont hit a point where going against the convention is a good idea until you do this professionally, at which point hitting up apidock and finding out about the :class_name and :foreign_key options.
The places where I tend to branch out is things like custom validators, or putting a bit more architecture in then jamming everything into fat models, but fighting rails conventions really isn't something you ever want to do no matter how experienced you are with them
>> Even after going through the docs, it took me way too long to get even a vague idea of how to properly set up a custom model/migration without the rails generator tool. But I'll admit, that's all a lot more in the realm of personal preference.
I think this is where the disconnect is for me about accusations of magic. A model is a ruby class that extends ActiveRecord::Base, is named as the singular version of the table, and is put into the app/models directory. I don't find any of those things particularly magical or mysterious, but if you only use the generators then you are never forced to think about the implications of the code that is being used, so that process of learning gets pushed out until way later.
The other thing is I see it recommended quite often to skip learning ruby by itself, and just pick it up as you go with rails. I think that is terrible advice, rails uses many features in the ruby language that aren't common in other similar languages. So when you run across an api like the create_table which uses a builder pattern with blocks, it seems like a lot more magical then it actually is.
Personally, I only use generators to create migration classes, and that is just so it puts the timestamp in for me. They are really there to help beginners get going (and potentially write some boilerplate code for you, although I usually would rather only write the bits I need rather then delete all the stuff I don't need). Maybe they do more harm then good though, and people should start recommending that beginners learning the framework create files manually until they gain a certain baseline of understanding.
I have been doing rails every day for about two years now, working on a moderately large (200k loc) app, and we very rarely go against the "rails way" of doing things wrt to naming. Like if you have a model called Post and a model called Comment with a line that says "has_many :comments" in the post, there is a lot going on. The name of the accessor will be called "comments", it will lookup data in the "comments" table that have an fk of "post_id" and materialize a collection of Comment objects.
I find those are good conventions, they are readable, and more importantly, they are consistant across all the rails apps I will ever see. So when I write new code, or am reading code I am not familiar with, there is this whole class of things I don't need to make decisions about, since there is already this implied group understanding of the way things should be.
Now, in the time I have been doing this, there have been probably around 3-4 times when I _have_ wanted to customize those things, but it is really so incredibly rare that I would go so far as to say you wont hit a point where going against the convention is a good idea until you do this professionally, at which point hitting up apidock and finding out about the :class_name and :foreign_key options.
The places where I tend to branch out is things like custom validators, or putting a bit more architecture in then jamming everything into fat models, but fighting rails conventions really isn't something you ever want to do no matter how experienced you are with them
>> Even after going through the docs, it took me way too long to get even a vague idea of how to properly set up a custom model/migration without the rails generator tool. But I'll admit, that's all a lot more in the realm of personal preference.
I think this is where the disconnect is for me about accusations of magic. A model is a ruby class that extends ActiveRecord::Base, is named as the singular version of the table, and is put into the app/models directory. I don't find any of those things particularly magical or mysterious, but if you only use the generators then you are never forced to think about the implications of the code that is being used, so that process of learning gets pushed out until way later.
The other thing is I see it recommended quite often to skip learning ruby by itself, and just pick it up as you go with rails. I think that is terrible advice, rails uses many features in the ruby language that aren't common in other similar languages. So when you run across an api like the create_table which uses a builder pattern with blocks, it seems like a lot more magical then it actually is.
Personally, I only use generators to create migration classes, and that is just so it puts the timestamp in for me. They are really there to help beginners get going (and potentially write some boilerplate code for you, although I usually would rather only write the bits I need rather then delete all the stuff I don't need). Maybe they do more harm then good though, and people should start recommending that beginners learning the framework create files manually until they gain a certain baseline of understanding.
I'm a Python/Django developer and I built a simple web app that helps me track my time with Rails 3 (with Ajax forms and all that shit), from scratch, without knowing anything about it, in 3 days.
I don't know what you mean about versioning, but IMHO, the versioning story is more solid in the Ruby world. I like virtualenv and pip, but I like RVM, gems and bundler more and had fewer problems while using them. Like, try to specify Maxwind's Geo-IP library as a dependency in a pip requirements.txt and you'll know what I mean.
It really depends on your learning style. Myself I like to read the API docs, or look at the source-code. The Rails Guides are pretty good too, without being boring.
Also, make no mistake about it, Django and Rails are different in mentality. When starting with Rails, don't bring along your preconceptions about how the framework should work.
I don't know what you mean about versioning, but IMHO, the versioning story is more solid in the Ruby world. I like virtualenv and pip, but I like RVM, gems and bundler more and had fewer problems while using them. Like, try to specify Maxwind's Geo-IP library as a dependency in a pip requirements.txt and you'll know what I mean.
It really depends on your learning style. Myself I like to read the API docs, or look at the source-code. The Rails Guides are pretty good too, without being boring.
Also, make no mistake about it, Django and Rails are different in mentality. When starting with Rails, don't bring along your preconceptions about how the framework should work.
I've observed that veterans in tool A frequently have huge problems when they try to get around the very different tool B. This, and not Rails, could be the cause of the problems you are experiencing. Every time I have to maintain a Java web app, for instance, I suffer.
My experience with Django and Plone, more often than not, makes everything much more painful than it would be were I more comfortable with, say, ASP.NET.
My experience with Django and Plone, more often than not, makes everything much more painful than it would be were I more comfortable with, say, ASP.NET.
I think the biggest thing is if that learning a complex framework is hard enough, but people often just assume that their expertise in a c-like static language is immediately transferable to anything else. If you have no experience in a dynamic or functional language and want to pick something up in that area, the first thing you have to learn is how people approach problems in that different paradigm, followed by gaining a level of competence with the syntax/libraries before they can even start learning the framework.
I think it's actually worse than that - there's a lot to unlearn in order to be effective with tools like Rails. It's like approaching Smalltalk and asking where's the source code.
> I've been a .NET developer for over 10 years.
Me too, and I just started using Rails in the last few weeks and am finding it a joy to work with. Way better than .Net. How exactly is it a nightmare?
Me too, and I just started using Rails in the last few weeks and am finding it a joy to work with. Way better than .Net. How exactly is it a nightmare?
USING Rails is a breeze. Getting it INSTALLED is the nightmare.
One expects a learning curve starting any new language, but I prefer that to start AFTER I've got it installed.
One expects a learning curve starting any new language, but I prefer that to start AFTER I've got it installed.
http://railsinstaller.org/ ?
in general, windows support in the ruby world is sort of a third class citizen, but I had thought rails installation was a solved problem
in general, windows support in the ruby world is sort of a third class citizen, but I had thought rails installation was a solved problem
When i ditched .NET I went OSX :)
I'm a Python/Django and Ruby/Rails developer and getting started with ASP.NET MVC was difficult ... I won't say nightmare, simply because I reserve that word for real nightmares and learning a new framework is not one.
So if the .NET community wants people like me to stop doing what they are doing and use ASP.NET instead, it MUST be easier to get started with.
And no, I don't want to develop on top of Windows or Visual Studio. Start from there.
So if the .NET community wants people like me to stop doing what they are doing and use ASP.NET instead, it MUST be easier to get started with.
And no, I don't want to develop on top of Windows or Visual Studio. Start from there.
I, for one, am glad that you appreciated and highlighted one of the key portions of my post. I spent a lot of time on it (relative to the rest of the post) to try and convey the point concisely.
I'd always remembered word-of-mouth from Rails enthusiasts touting how easy Rails was (talking 2006-2007). A Rails guru last summer told me that 'Rails was never promoted as being easy'. Was my memory faulty? Has the PR around Rails changed over the years?
If you're a beginner, as in, never made a web app in your life, Rails is going to be hard because it expects you to know so much.
But if you're a seasoned web developer who knows JS, HTML, CSS, and SQL, and has a grasp on OO programming, Rails is easy. To be honest, the CS students that intern for me are working on the production apps within a couple of weeks.
But if you're a seasoned web developer who knows JS, HTML, CSS, and SQL, and has a grasp on OO programming, Rails is easy. To be honest, the CS students that intern for me are working on the production apps within a couple of weeks.
I couldn't say, I'm not familiar with the PR around Rails. But I will point out that Rails being easy is different than Rails being for beginners.
Rails is easy in that it solves a lot of pain points that exist around web development. If you are an absolute beginner then you won't yet have any conceptualization of the pain points and Rails will just seem needlessly complex.
Rails is easy in that it solves a lot of pain points that exist around web development. If you are an absolute beginner then you won't yet have any conceptualization of the pain points and Rails will just seem needlessly complex.
Every time I use something that isn't rails, I am reminded by how easy it makes things. You get
- validations - basic architecture - emails - dependancy management - asset packaging and management - concept of "dev" vs "production" mode - data access - logging - test framework - easy way to provide an api - access to loads of other things (like authentication/ auto CRUD / client side testing / etc)
and all of that usually is just a line or two of code to activate, and will get wired up with everything else. On top of that it is actually done well, and if you dont like any of those bits, they are easy to swap out (for example, I don't use the built in test framework, templating, or data access framework pretty much every, but it is STILL easy to get going quickly).
I understand that was a bit fanboi-ish, but if I were going to rave about rails, that is what I would say :)
- validations - basic architecture - emails - dependancy management - asset packaging and management - concept of "dev" vs "production" mode - data access - logging - test framework - easy way to provide an api - access to loads of other things (like authentication/ auto CRUD / client side testing / etc)
and all of that usually is just a line or two of code to activate, and will get wired up with everything else. On top of that it is actually done well, and if you dont like any of those bits, they are easy to swap out (for example, I don't use the built in test framework, templating, or data access framework pretty much every, but it is STILL easy to get going quickly).
I understand that was a bit fanboi-ish, but if I were going to rave about rails, that is what I would say :)
Rails was promoted as being productive, i.e., able to produce amazing results fast. To my recollection, it was never promoted as being easy to learn.
It was promoted as being easy for people who already knew how to program. Which it was. The 5-minute blog video wouldn't help a total newb at all, but to an experienced developer it's clear how powerful it was.
I can attest to this. I was a total noob when I saw that video and didn't get it.
Spent several years in the murky php waters because I could just drop that code in the html I did know and go.
Now that I have more experience its more more clear the benefits of rails/django
Spent several years in the murky php waters because I could just drop that code in the html I did know and go.
Now that I have more experience its more more clear the benefits of rails/django
I am a beginner and you are 100% right. I am working my way through learning some Python and when I started to find stuff referring to Django and web frameworks, they all seem to be touted as 'easy'. So, I thought, 'what the hell, let's build a web app'. After installing Django I was totally lost. Sure, I could install the framework and work through the tutorials but I am still miles away from actually building something on my own, because, while I know how to write some lines of code and create some basic tools I still don't know how to BUILD anything.
Yeah, I'm realizing that there isn't a great starting point for someone to get into web development from scratch. I don't think Django or Rails should even factor into it.
I've liked what I've seen of Code Academy, that might be something to look into if you haven't already: http://www.codecademy.com
I've liked what I've seen of Code Academy, that might be something to look into if you haven't already: http://www.codecademy.com
Thanks, I went through the Code Academy courses and they were fun and helpful, but the biggest strides I've had in programming have been thinking of an idea and then trying to build it from what I know. This way, I am applying what I already know, further cementing it and it forces me to run into problems that I cannot yet solve. I spend up to a week trying to figure out a solution to that problem on my own. If I can't, I'll head to Stackoverflow and ask there. That's been the best way for me so far.
Absolutely. Thinking of an idea and then coding to its realization is a classic method of learning to program. It sounds like you have a great system for learning. I'd only caution that even if you come up with a solution to a problem on your own: do the search engine/stack overflow research anyway to see alternative methods. If you don't find any: blog about it.
Interesting that right at the top of rubyonrails.com is this quote:
“Ruby on Rails is a breakthrough in lowering the barriers of entry to programming. Powerful web applications that formerly might have taken weeks or months to develop can be produced in a matter of days.” -Tim O'Reilly, Founder of O'Reilly Media
“Ruby on Rails is a breakthrough in lowering the barriers of entry to programming. Powerful web applications that formerly might have taken weeks or months to develop can be produced in a matter of days.” -Tim O'Reilly, Founder of O'Reilly Media
"Powerful web applications that formerly might have taken weeks or months to develop can be produced in a matter of days."
This is true if you are already an experienced web developer. You already know the problem space well and have an intuition about good solutions and approaches. Someone handing you Rails as a tool can certainly speed up the development time.
This is also only true if the application is trivial; you can only create a simple "first cut" of a product in a matter of days.
"Ruby on Rails is a breakthrough in lowering the barriers of entry to programming."
I think Ruby is a great first programming language; it has a cleaner, more consistent syntax than some other languages with fewer gotchas and edge cases (I'm looking at you, JavaScript!).
Rails, on the other hand, has a lot of magic, so that if it is your first programming experience, you will probably approach programming more in terms of memorizing and repeating the magical incantations instead of having an understanding of how the system works and practice in designing and crafting good systems of your own. So in that sense, Rails (and the state of web programming in general) may make it harder for people to get really good at programming.
This is true if you are already an experienced web developer. You already know the problem space well and have an intuition about good solutions and approaches. Someone handing you Rails as a tool can certainly speed up the development time.
This is also only true if the application is trivial; you can only create a simple "first cut" of a product in a matter of days.
"Ruby on Rails is a breakthrough in lowering the barriers of entry to programming."
I think Ruby is a great first programming language; it has a cleaner, more consistent syntax than some other languages with fewer gotchas and edge cases (I'm looking at you, JavaScript!).
Rails, on the other hand, has a lot of magic, so that if it is your first programming experience, you will probably approach programming more in terms of memorizing and repeating the magical incantations instead of having an understanding of how the system works and practice in designing and crafting good systems of your own. So in that sense, Rails (and the state of web programming in general) may make it harder for people to get really good at programming.
Yes, the barrier to entry to writing web applications is significantly lowered by Rails; but it's not meant to be a replacement for experience. Rails is supremely helpful, but not explicitly designed for beginners.
I got pretty far along with Rails Tutorial, and came to love Ruby after just a short time. Its so nice and such a refreshing change from PHP.
BUT! What I hadn't anticipated was really not knowing anything about how to make a web app. I knew nothing about REST, nothing about get/put, nothing about forms, etc.
I thought Ruby and Rails were the answer to the problem I'd been having for years. I thought that I was just in need of the right programming language to help take my skills to the next level. I realize now however, after some cool Ruby bits and some Rails basics, that you're only going to get the best results out of language and framework when you know the basics.
And there's a lot of basics: rest, basic http methods, forms, sql, routes, etc etc etc.
BUT! What I hadn't anticipated was really not knowing anything about how to make a web app. I knew nothing about REST, nothing about get/put, nothing about forms, etc.
I thought Ruby and Rails were the answer to the problem I'd been having for years. I thought that I was just in need of the right programming language to help take my skills to the next level. I realize now however, after some cool Ruby bits and some Rails basics, that you're only going to get the best results out of language and framework when you know the basics.
And there's a lot of basics: rest, basic http methods, forms, sql, routes, etc etc etc.
I am a huge advocate for the Django web framework, yet I always tell people that web frameworks (Django|Rails|etc) are not for beginners. Like many have mentioned, it's easy for experienced web programmers that have been mucking around things done "the old fashioned way" and without any true MVC structure.
I assume it would be difficult for novice programmers to really understand what the advantages and best practices of MVC web frameworks are for, when they have little experience of having worked in anything else.
I would argue that the lack of a simple installation process to get Rails running makes it inaccessible for a lot of beginners (myself included). Without stackoverflow, I wouldn't have known where to start - or what commands I'd have to enter into the terminal. As far as I know, there is no script that automates this process.
Compare this to PHP, where most of today's shared hosts support it right out of the box.
It has gotten better.
Install - http://railsinstaller.org/ Learn - http://ruby.railstutorial.org
Install - http://railsinstaller.org/ Learn - http://ruby.railstutorial.org
I'm pretty interested in that project. We had a dev on Lion try to get a Ruby 1.9.3 + Rails 3.2 environment up who ran into all kinds of issues: a far cry from the days of locomotive indeed.
for future reference, step 1 - gcc toolchain (https://github.com/kennethreitz/osx-gcc-installer or xcode), step 2 - rvm (http://beginrescueend.com/), step 3 - "rvm install 1.9.3 && rvm 1.9.3 --default && gem install rails" (homebrew will also probably be necessary for any dev work on osx, but not really needed to get rails going)
I've found that rvm makes everything easier. And through OS X development I've also learned that I should avoid port at all costs.
RVM is superb. And, yes, I think a major issue was that he was trying to use macports for installation of things instead of homebrew.
I have complained in the thread about that kickstarter project already and I'll repeat myself from a slightly different angle here. I say: Installation is not the problem. It's just a pre-taste of what you're getting into and if the standard procedure is so broken that it needs artificial padding then we have a much bigger problem here.
That bigger and real problem with Rails is wrong abstractions and too much magic, the stuff that you hit right after installation. In terms of discoverability Rails is the poorest of all popular web-frameworks.
I'll say Rails has many things right, but just as many deeply wrong. Which is an amplified problem for absolute beginners - for them it's double hard to unlearn bad patterns after struggling to grasp them in first place.
To name just a few:
It is not right that the default modus-operandi for pretty much everything (e.g. devise) is to inject a bunch of invisible, undiscoverable magic at installation time and leave the user at best with a few hardly discoverable hints about how it actually works (and where to look when it doesn't).
It is not right that rails still makes heavy use of code-generators (related to the previous bullet).
It is not right to still have no automation for schema migration. I do in fact claim the ActiveRecord pattern has proven a poor choice for the Rails use-case.
etc.
For teaching I would claim Rails is about the worst possible choice. It's an opaque blob of magic that provides good leverage when massaged in just the right way. But that "right" way is in large parts so undiscoverable and detached from reality that you end up with juniors who may be able to churn out simple rails views - yet are immediately lost when anything diverts from their learned script.
So, back on topic. In my experience teaching web-stuff works best bottom up. Start with HTML/CSS, then give them something like sinatra so they get a grasp on what a request is. Even PHP is a valid choice here.
Rails is for much later, for when they at least have a remote clue what they're doing.
That bigger and real problem with Rails is wrong abstractions and too much magic, the stuff that you hit right after installation. In terms of discoverability Rails is the poorest of all popular web-frameworks.
I'll say Rails has many things right, but just as many deeply wrong. Which is an amplified problem for absolute beginners - for them it's double hard to unlearn bad patterns after struggling to grasp them in first place.
To name just a few:
It is not right that the default modus-operandi for pretty much everything (e.g. devise) is to inject a bunch of invisible, undiscoverable magic at installation time and leave the user at best with a few hardly discoverable hints about how it actually works (and where to look when it doesn't).
It is not right that rails still makes heavy use of code-generators (related to the previous bullet).
It is not right to still have no automation for schema migration. I do in fact claim the ActiveRecord pattern has proven a poor choice for the Rails use-case.
etc.
For teaching I would claim Rails is about the worst possible choice. It's an opaque blob of magic that provides good leverage when massaged in just the right way. But that "right" way is in large parts so undiscoverable and detached from reality that you end up with juniors who may be able to churn out simple rails views - yet are immediately lost when anything diverts from their learned script.
So, back on topic. In my experience teaching web-stuff works best bottom up. Start with HTML/CSS, then give them something like sinatra so they get a grasp on what a request is. Even PHP is a valid choice here.
Rails is for much later, for when they at least have a remote clue what they're doing.
If you get a shared host with Rails support, it's installed there to. Getting PHP configured with Apache on localhost is... easy for some people, but not for others.
Exactly. I do love Rails and it's great for what it does, but it isn't (and never was) designed to help beginners write web applications.
To me, it's more about "holy shit, several level of abstraction" that I have to learn by heart in order to use rails, rather than learning the commands that does a rails application.
It's a lot easier, in my opinion, to start from nothing but a few libraries and then write a toy web application. However, you're left to write everything yourself.
It's a lot easier, in my opinion, to start from nothing but a few libraries and then write a toy web application. However, you're left to write everything yourself.
>implying PHP is easy/simple to install on a local dev machine
Rails' local dev install process is only just as complex as Django/PHP, and for everything else, there's Heroku.
Rails' local dev install process is only just as complex as Django/PHP, and for everything else, there's Heroku.
What platform are you developing on?
For me, Django installation on any recent Debian-based distro is as easy as either "sudo apt-get install Django" or, if I want to do things the right way "sudo apt-get install python-virtualenv; virtualenv --no-site-packages project; source project/bin/activate; pip install django;"
In all fairness, as I type that last part out, I suppose it's not all that straightforward, but on a fast internet connection, it's something I can do in under a minute.
For me, Django installation on any recent Debian-based distro is as easy as either "sudo apt-get install Django" or, if I want to do things the right way "sudo apt-get install python-virtualenv; virtualenv --no-site-packages project; source project/bin/activate; pip install django;"
In all fairness, as I type that last part out, I suppose it's not all that straightforward, but on a fast internet connection, it's something I can do in under a minute.
So as someone who has programmed before in C# and Python, and has a knowledge of OOP, what would you suggest to start in Web Development (Apart from HTML, CSS and JS) ?
I tried PHP, but I found the syntax extremely awfull and verbose, any alternatives ?
If you want to stick with a language you know, ASP.net MVC and Django are both great full stack frameworks for getting complex stuff done quickly and well.
If you want to go a bit more of a futureproof route, focus on learning something like backbone or ember, and treat your server as an api. In that case, what framework you choose doesn't matter so much, as long as it provides good json serialization and easy data access.
If you want to go a bit more of a futureproof route, focus on learning something like backbone or ember, and treat your server as an api. In that case, what framework you choose doesn't matter so much, as long as it provides good json serialization and easy data access.
I'm not up on current Django tutorials (which may be more your style since you're already familiar with Python) but you are a great candidate for Michael Hartl's fantastic Rails tutorial: http://ruby.railstutorial.org/
You can buy the books and screencasts or read the whole thing online for free.
You can buy the books and screencasts or read the whole thing online for free.
I know C# is a great C styled language but calling PHP too verbose is a little... strange imo.
When you say you "tried PHP" I'm assuming you didn't start with a framework of some sort? Writing straight PHP scripts will probably rot your brain.
http://fuelphp.com/ or http://laravel.com/
Would be my two cents from the PHP crowd.
When you say you "tried PHP" I'm assuming you didn't start with a framework of some sort? Writing straight PHP scripts will probably rot your brain.
http://fuelphp.com/ or http://laravel.com/
Would be my two cents from the PHP crowd.
This has led me to consider whether I could teach them to build web apps using django, or rails, or any other framework. It quickly becomes a daunting proposition for anything nontrivial.
You can follow tutorials, books, and videos all you want. But when it comes down to it, every good web app is developed over time through iteration and troubleshooting. Those are two areas where you simply have to understand what is going on under the hood to be successful. It's nice to work with data through an abstraction layer, but when you do something that doesn't work well with the abstraction layer you need to be able to do some manual twiddling with your actual database.
Frameworks make it easier for experienced developers to build meaningful projects quickly, which they are then able to maintain based on their deeper technical understanding. Frameworks may help inexperienced people play with a simple web app. But frameworks don't let the average person build and maintain complex web apps.