Rails isn't for beginners
rakeroutes.com
rakeroutes.com
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.
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.
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.
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.
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.
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.
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.
This.
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.
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".
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.
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.
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?
One expects a learning curve starting any new language, but I prefer that to start AFTER I've got it installed.
I installed it that way, wasn't difficult at all.
As for Ubuntu, it's a sad state. Installing ruby-rvm and/or rubygems from the the repositories can break your whole system.
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
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...
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 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 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 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.
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.
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.
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.
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
- 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 :)
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
“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
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.
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.
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.
Rails' local dev install process is only just as complex as Django/PHP, and for everything else, there's Heroku.
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.
Install - http://railsinstaller.org/ Learn - http://ruby.railstutorial.org
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.
You can buy the books and screencasts or read the whole thing online for free.
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.
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.