Naturally, there's some selection bias there (most people who give up are unlikely to write), but that doesn't change the joy for the people who did have a great and easy time.
I've been using RailsTutorial, and while it's packed with info, I feel like I would benefit from a more solid understanding of many of the basics.
I've found this to be an AWESOME resource:
http://openclassroom.stanford.edu/MainFolder/CoursePage.php?...
It's a full Stanford class of lecture videos. It really solidified my understanding of the concepts I learned from Hartl's tutorial.
Sinatra is actually a great foundation for big things, although it doesn't give you the whole stack, but only the way how to build your stack.
I've been developing on Padrino (which builds on Sinatra) for 2 years now and I am still surprised by how easy adding features/plugins to Sinatra (and by that, Padrino) is, especially as the most useful Rails plugins now also come with a "pure rack" variant.
On the other side, I often ran into problems with the huge stack that Rails has, so that I had to tackle issues far before I actually needed a feature.
We should strive to make the learning curve more enjoyable rather than making it beginner friendly, The only way i know of doing that is to show evolution of technologies, there merits and de-merits and why or how we have reached where we have reached and why we took the technological decisions that we took. How we reached to rails from PHP or cgi. How treacherous the journey was.
Rails just has too much magic and higher level of abstraction built in that it easier for beginners, But when you want to do something really great you need to look under the hood. That is RUBY, Rack and HTTP.
Because sooner or later you will realize that a web app is nothing more than HTML/CSS/Javascript so you know the nuts and bolts of the underlying infrastructure the better.
I think learning something as basic as sinatra is much better than learning rails , so that you have some idea of the underlying stuff and then when you move to rails you can learn more of rails by just looking at its code.
Personally i learnt a great deal from looking at rails source than looking at a tutorial. But surely it would be a daunting task for a noob. Also learning Rack comes naturally with sinatra. and as you look at Rack, sooner or later you would figure out how to write a cgi adapter for your rack app.
Then Comes rails which saves you from all the mundane task you were doing developing in sinatra and much more.
This way you would have a better understanding and appreciation for rails and all the stuff that you don't have to do or write in rails.
At the same time you will have a better understanding of how a particular feature is working in rails. This improves your debugging skills because you know where to look for when something goes wrong.
Finally Ruby is the elephant in the room so you need to be better at ruby to become excellent at rails, Which often is shadowed by the magic that rails provides, so learning RUBY first is more important than rails, sinatra or anything.
You can't really call a framework a language.
For example, in cakephp we have this cook book http://book.cakephp.org which the quality of the content surpasses every cakephp book on amazon.
So, like apps "simple & feature rich" can get along together like "learnability & usability" can get along too. It just needs more work.
That's why many people have started to use CoffeeScript and/or Backbone.js to write more maintainable JavaScript. But the CoffeeScript/Backbone.js route is harder for beginners but in the long run it's a much better choice.
> But the CoffeeScript/Backbone.js route is harder for
> beginners but in the long run it's a much better choice.
This is how I see it:
Pure JavaScript + JQuery = Very easy to get started but very hard to maintain when the code base grows if you don't know JavaScript very well.
CoffeeScript + JQuery + Backbone.js = Harder to get started but the code becomes easier to maintain when the codebase is big.
I know that JQuery is not about organizing code.
That was a decision I regretted many times. The hoops I had to jump through to deal with complex database queries were ridiculous. The difference in quality and robustness between ActiveRecord and cakePHP's ORM (at that time, anyway) were pronounced, with AR coming out way, way ahead.
There's no doubt, in my mind, that if you are going to take on a large, ambitious web application project, you'll be better served by Rails.
You'll also have to note that both frameworks have progressed significantly in the last few years - CakePHP actually just released a new major version, as did Rails a few months ago - so your experience a few years ago - was this in the 1.1 era - would just be indicative of the framework's beginnings, not where it currently is.
Feel free to message me with your thoughts if they still conflict; I'd love to hear the other side of the story since improving CakePHP as a framework helps not just my ego, but other developers who are using CakePHP to make a living :)
- In my very humble opinion, only one - English! I can't comment on the international community - book has been any good (That by Mariano Iglesias) and they all tend to either have outdated information or just bad code samples. So no, they do not surpass the quality of the framework. - Hard stuff is always hard, regardless of the framework. At a certain point, you start butting heads with limitations in the language, at which point no framework will help. I've also found "hard stuff" to be fairly easy in CakePHP due to the large plugin base I can reach into - only Django and Ruby Gems really solve this sort of problem - so no, the hard stuff doesn't get harder.
Regardless, I'd be more than happy to get your feedback on this though. Send me a message :)
>There are plenty of cases where learnability and usability are in conflict
>That's where learnability and usability are again in conflict
But it is hard to work on both so you may need to work on usabilitiy first then work twice as hard for learnability.
A MD is not for beginners either. Policing is not for beginners either. Even cooking is not for beginners.
I had my first son 9 month ago before I learned how to change a diaper. Being a Dad is definitely not for beginners.
Life is not easy, nothing is for beginners.
People just learn along the way if they think this is the skill they need to learn and they have a strong will.
The most important thing is to BEGIN.
If you on the other hand optimize for usability, for making things simple and easy to use for someone who understands the basics, you'll often end up with something that has great learnability as well. Maybe not as much as could be achieved as if that was your only goal, but plenty still.
The other aspect is whether you as a framework designer are designing something for yourself and your peers or if you're trying to dumb things down on behalf of beginners. In other words, designing for what you think beginners might find easy in their learning phase. That's really hard to do. Most technology I've seen designed in such a master/apprentice fashion sucks.
Finally, when you're comparing complexity, it's generally more helpful to look at the complexity involved with completing an entire task. Comparing complexity of "hello world" tells you little about what the complexity is going to be like developing a complete, modern web application from database migrations to XSS/CRSF protection.
That's where learnability and usability are again in conflict. Yes, it's harder to learn a framework that has answers for things like "how do I migrate a database once I have data I care about", or whatever feature you want to focus on, but once you hit that problem, you'll be glad that it's there and find the solution less complex than stringing something together from tons of separate parts yourself.
All that being said, I think Sinatra is wonderful. So what if it's not a fit for building a whole Basecamp or Github? It's great for teaching someone the basics of how HTTP works and it's great for smaller surface apps or for smaller, isolated parts of bigger apps.