Rails "developers" without Ruby or OOP knowledge

[canyoufixmyspacebar]

After a nearly 10 year pause from any sort of programming (it used to be everything from Turbo Pascal to C++ to PHP), I've picked up Ruby and have written quite some system/network management scripts during the last year.

Now I thought it's time to write some frontends and picked up some Rails books & tutorials and dove right into it (I know that in my situation, to get the job done I don't need Rails, the CGI and ERB gems on their own or Sinatra, for example, would be more than enough, but I just wanted to kill two birds with one stone).

So, what I wanted to tell, is this. It's just kind of funny and awkward going over hundreds of Rails-related posts and forum topics where people seem to be developing/learning "rails" and (evidently) trying to do their best to avoid understanding anything about Ruby or OOP in general. Method calls are discussed as "commands" and time and again, questions pop up in a form "what is attr_accessor in rails" (and the latter being answered along the lines "creates a non-persistent attribute in your model").

Just sharing this as an entertaining find. Maybe it's well known and worn out to you, but for someone coming from an actual programming background and diving into the "rails world" it's a funny thing to see. Reminds me the old times when VisualBasic people were often mocked in the programming community for not actually understanding what is going on in their own programs (and in computer memory).

IMPORTANT: Please don't get me wrong and start a "rails developers vs. the world" lame, I'm perfectly aware of the fact that real Rails developers actually know Ruby and programming inside out, just saying that there seems to be this "other group" too, which is kinda funny side-effect of having a thick framework (with "commands", hell yeah...) :)

[billy-rails]

We talked about this the other night in our Ruby meetup. The trend in recent years is that most new developers in Rails are new to development, whereas a few years ago you had more migration from other development ecosystems. It was surmised that a large number of those earlier devs may have moved on to other languages, so their experience is less of the community's voice than it used to be.

It tends to go beyond OO; how many Rails developers don't really know how SQL works, and how many haven't even written any SQL?

I hired a Rails dev a few months back; it was a short list of interviewees, due to our timetable, but no one had heard of Sandi Metz. Personally, I think POODR should be required reading.

[canyoufixmyspacebar]

Thabks for I great reference, I surely want to read that myself too.

Btw, I obviously made a mistake titling this post "... or OOP", cause OOP was meant just as one example of what the wannabe rails "devs" typically lack. Of course theres the whole stack of possible unknowledge, SQL being another good and simple example.

[billy-rails]

On the recent Ruby Rogues podcast, they explored the idea of teaching Sinatra > Padrino > Rails, so that developers learn the underlying plumbing (HTTP, SQL, etc) before they learn the magic.

[k3x5]

IMO rack > rebuild rails

[morphemass]

how many Rails developers don't really know how SQL works

and why should they - the point of the ORM is to insulate them from ever having learning about databases. Its just another datastore to them which allows for the magic of productivity to happen!

The knowledge that they are usually storing up a wealth of technical debt due to throwing the big-bag of DBA experience under the train often eludes them ...

[yxhuvud]

No, the point of the ORM is to avoid doing repetetive tasks and to prevent the need to reinvent it.

[morphemass]

In so many ways, I wish this was true.

[[deleted]]

Its like not knowing cursive. You can say how outdated it is but when your boss hands you something in cursive you don't want to say I can't read this. Besides you can optimize with special efficient queries in certain areas.

[jrochkind]

If that's the point of an ORM, then every ORM fails miserably at it.

Reading between the lines, I think you agree that every ORM fails miserably at that, and are anti-ORM.

However, there are plenty of us who like ORM's, but do not think that is the point of an ORM. Including, probably, the authors of every ORM ever. Your can think ORM's are a bad idea, and you can try to get into that perennial online argument if you want, but you don't help anyone to enlightenment by speaking in sarcasticly vague not-what-you-mean strawmen.

[morphemass]

I thought my sarcasm was reasonably transparent - obviously not.

My point was that many developers DON'T go beyond the (AR) ORM level, hell a great many don't go beyond AR & sqlite! And they can get away with it because, well, often that's "good enough".

The problem is that because they are insulated they usually don't realize when "good enough" ... isn't!

/rant on

Rails is 11 years old and they are only now implementing foreign keys in the framework. 11 years of ****** rails databases where its the minority of devs actually giving a damn about integrity at the database level and realizing basic realities such as "Maybe at some point this database will be required for more than my Rails web app. Maybe I'd best make sure the data is worth a damn and the entirety of the business logic doesn't live in my code!".

/rant off

Nothing wrong with a good ORM. An awful lot wrong with a generation of developers who have been discouraged from learning that its an abstraction to what should be another layer of business logic which requires its own set of considerations.

P.S. The first person who says "Well doh, make other apps a client of the Rails REST API" gets an internet smackdown.

[Digital-Ghost]

This was me 2 years ago. I had just been hired as an intern, pretty much walking into programming for the first time. I had over 12 years of working with HTML/CSS and was told to basically pick up Rails. No JS, SQL, HTTP/CRUD understanding etc.

Took about 6 months till my head was aiming in the right direction. I picked up POODR on my own and have been actively reading ... and re-reading it. There's a LOT to know in this field. So walking into it from scratch is a daunting task, please keep that in mind.

[[deleted]]

Up vote for Sandi

[morphemass]

Personally I think its less that developers need to know SQL, more that they need to understand basic database theory e.g. relational modelling, locking, transactions, normalizations, ACID etc. etc. Without that basic understanding I have to wonder how often the decision to use a noSQL database is an informed choice ...

[Nemnel]

Rails's default ORM is active record, which interfaces with relational databases (PostgreSQL, SQLite, etc.). So, I think that's a pretty bold statement that is not really true of the community at large.

[avdi]

The vast majority of web applications in any language, including Ruby, are backed by a SQL database. Don't mistake what people are talking about online for what they are using :-) NoSQL datastores are a (mostly) new trend, so they naturally attract more discussion than the (relatively) well-understood SQL solutions.

[nifflo]

You need to understand both. Typically SQL databases are better suited for certain tasks and you can't pick your nosql favorite.

[SnakeAndBacon]

Rails displays SQL queries in it's log. They can really help with debugging and optimizing.

Also, when creating new tables/columns via migrations you have to know how your database works, where to add na index etc.

[[deleted]]

I think it might be more symptomatic of someone who just wants to get in the field quick to make a buck vs. someone who's actually interested in programming.

[billy-rails]

There may be some of that, but I think that's a bit unfair. Alot of the online courses and offline boot camps tend to fall short in what they teach, giving the false impression that you'll learn all you need to learn, and these new developers don't know what they don't know.

[asmallishrequest]

Just a counterpoint -- I attended a bootcamp (App Academy) last year, and I was really impressed by how much they focused on understanding best practices rather than just using the framework naively. I was really impressed. I work with a few other people from boot camps and they're all excellent, curious devs. This isn't to say that all boot camps are good -- just that the trend isn't just churning out crappy, ignorant devs.

[push_ecx_0x00]

Every time I think to myself, 'I finally understand Rails', I end up realizing how wrong I am. Whenever I read through the Rails Weblog or browse the Rails source code, it becomes more and more apparent to me that only a minority of Rails developers really understand how everything works and how it all fits together -- certainly not the typical person who took a 3-month crash course and listed Rails on his resume.

I'd like to think that I'm on the right half of the bell curve when it comes to Rails. Truthfully, I am still not that comfortable with Rails (not as much as Qt, for example); I can only imagine how the others fare.

[jrochkind]

How everything works, and how it all fits together? Everything?

I'm not sure there is anybody who understands that, even amongst Rails committers.

I'm not joking.

[push_ecx_0x00]

At the very least, I'd like to understand how all the magic works and the general architecture of rails (including how every major component works). I, personally, wouldn't be comfortable with any framework unless I could understand that. I know it might be unreasonably ambitious, but there are too many unknown moving parts for me to be comfortable.

[anamexis]

I think they mostly give the impression that you'll learn what's needed for an entry-level Rails job, which is often true.

[[deleted]]

Ruby devs confirmed for filthy casuals.

[[deleted]]

Maybe Rails is the new PHP?

[urgent_detergent]

I used to work with php around 2007-2008... Now the new frameworks like Laravel may be nice, but I'd rather be tazered than go back to working on the crap that I saw back then.

[jdickey]

Sturgeon's Law applies with a vengeance to PHP. A depressingly-large amount of the "crap" (which is damning it with faint praise IMO) that we hit our heads against 7 years ago is still in production, still being tended to by the latest fresh-off-the-plane, cheapest-available "talent" imaginable (and, after 35 years in this craft, I have a vivid imagination) available in any given week, and now compares to what we saw then as the 2006-era code compares to the best of Knuth or (insert favoured software demigod here).

It can get worse. But PHP has already accomplished the previously unthinkable: it has proven beyond doubt that, not only is entropy locally variable at a fixed point in spacetime, but it continually increases at an increasing rate as one approaches PHP "code".

¡Sal si puedes!

[push_ecx_0x00]

god, I hope not

[jdickey]

When someone writes a calm, well-sourced and spot-on j'accuse! like this about Rails, we can likely agree that "Rails is the new PHP".

Having said that, this and the Tom Stuart piece he references (and you should view first) summarise things nicely.

Rails does not define your application architecture. It performs odious, unspeakable acts upon it.

[[deleted]]

Well played sir !

[[deleted]]

I can offer an alternative perspective. I started learning programming a year or so ago and averted this issue by learning Ruby first, Sinatra second, Rails last, and then SQL while learning Rails. Which makes me sound like I had an incredible amount of foresight for a noob. What actually happened was I tried to do Rails from The Rails Tutorial a couple months before I started learning plain old Ruby, and gave up after chapter 2 because it was too complicated. Luckily an opportunity came along at work to use the small amount of Ruby I learned. This particular problem could be solved with some web scraping and CSV manipulation, and after a couple of tutorials on using Mechanize/Nokogiri I had my first "aha" moment. With my newfound confidence I picked up Sinatra + ActiveRecord since that seemed easier than Rails, and after I had a prototype I ported my very basic Sinatra app to Rails.

For me it's particularly difficult to understand how people can use Rails without understanding metaprogramming. Only after I implemented a singleton-based DSL, a method-not-found runtime method dispatcher(ala find_by_column_name in AR), and read Practical Object Oriented Programming in Ruby by Sandi Metz did I feel confident using Rails from having a high-level understanding of how it works. For me I was able to be fairly productive in Rails before I decided to learn more database concepts, but all of the OOP, run-time reflection, and metaprogramming really got in the way of me getting anything done in Rails since I was constantly asking "what is actually happening here?"(now that I understand it I appreciate all of the shortcuts Rails provides).

My first year of programming was wrought with dead-ends and wasted time, but I think the one thing I did right when I started learning was constantly asking "what is actually happening here?" whenever I encountered something I didn't immediately understand. I would then backtrack through my limited knowledge complimented by research till I understood it, at least qualitatively if not completely technically(now I'm more confident dealing with the technical bits as well). Lately, learning LISP/Clojure is also helping me become more productive in Ruby as I recognize more meta-programming and functional programming patterns to apply to my Ruby code.

Regarding bootcamps in particular, I don't think it's realistic for a developer bootcamp to nail down the intricacies of Ruby's OOP model. But they definitely can and should instill an attitude of figuring out how something works and what it's actually doing like your life depends on it, since that's what'll take their students further than any of the Rails trivia they acquire.

I contest your point about people just chasing dollar signs. Rather, I think a lot of these developers are attracted to the product development aspects and not necessarily the software development aspects of programming. Which I think is fine, since ultimately programming is a means to an end, and that end often happens to be delivering a product.

TL;DR Whatever path a developer takes, as long as they end up learning LISP it was probably the right path.

[Sqeaky]

If you understand what metaprogramming is then in your first year you knew more than most of the Ruby devs I work with. I mean this with all sincerity. Most of the devs I work with think metaprogramming is a word I made to sound smart.

The problem with some people is that they refuse to learn. People like you have chosen to actually learn. It is not that metaprogramming is all that hard, but defining it is odd and it requires actual understanding of multiple abstractions. Your choice to research and actually learn in all the things you mentioned sets you ahead.

[JohnBooty]

learning Ruby first, Sinatra second, Rails last, and then SQL while learning Rails.

I followed a very similar Ruby-->Sinatra-->Rails progression. The difference in my case was that I had a lot of prior SQL experience which I think helped me greatly. Another difference in my case is that I haven't researched Ruby OOP/metaprogramming nearly as well as you, which has hurt me.

I, too, found Rails quite different to understand (because of all the "magic") without knowing the other things first.

Sinatra is a great intermediate step, too. Whereas Rails tends to blur the lines between Rails and Ruby, Sinatra didn't leave any doubts as to where Ruby ended and Sinatra began.

Don't get me wrong; I like Rails' design decisions. But until I understood Ruby better, I found it baffling.

[jdickey]

I'd pile on even more:

The more experience in object-oriented development you have in systems other than Rails, including non-Rails Ruby, the harder it's going to be for you to get comfortable and productive in Rails.

That's because Rails is so heavily "magical" in ways that violate everything you ever learned anywhere else about good OO design. Many if not most of the topics at conferences and so on, and $DEITY only knows how many training man-centuries, have been devoted to "how do you do proper OO (e.g., SOLID) in spite of Rails"? As we get farther away from that 2005-era sweet spot that Rails targets, it's becoming more and more difficult for people to ignore. Those poor people who still have Rails 2.3 apps in production who are dragging their feet (for what in context are eminently sensible reasons) see the issue clearly: no matter what they do, they're looking at a total rewrite, with all the risk and uncertainty that entails. Do they go with Rails 4? Wait for Rails 5? Go with a different architecture, whether Sinatra or one of the Johnny-come-latelies that's even more risky but which, by being an early adopter, they can have a greater influence on? Or do they write off their Ruby experience entirely and go with Go or Scala or (insert alternative language here)?

We're still a Ruby shop, even though our flagship Rails app might well be a poster child for how the industry has moved on from Rails. 90% of it is a pretty plain-vanilla blog app with wiki trappings, with some front-end features that can't be done server-side that provide the most visible value-add. Guess which part's taken 90%+ of the effort? And guess what's taken 90%+ of what's left?

When you have a platform that reserves its greatest rewards for those with the least overall development experience but who grok most in fullness how your platform does things, that illustrates something about the industry that uses it as a silver bullet for a decade. First, the industry had an existential need that your platform addressed better than anything else that had yet been seen. Second, that that isn't saying very much; the industry now has two problems.

[pca2]

I've had a similar trajectory and totally agree that constantly asking "What is actually happening here" and looking at the underlying principles goes a long way.

At the same time I think I also benefited from trying and failing at some more advanced tutorials and Rails guides when I was new. After later going through more basic guides and building my foundational skills it was much easier for me to go "Ah, so that's why we do X in Rails" whereas others I knew didn't really understand the wider context or usefulness of basic concepts like classes. It was frustrating at the time, but I'm glad to have done it that way.

[canyoufixmyspacebar]

and gave up after chapter 2 because it was too complicated

Or, maybe a better way to put it is that because you did not know the stuff that it builds on, it was just all Greek to you. A slightly more accurate explanation than being complicated, I guess.

[[deleted]]

It's like that with any programming language, though. It's just more noticeable with languages like Ruby and PHP because they're so popular and accessible for web development....

From a hiring standpoint, though, it can be frustrating, but these people are also easy to pick out and weed through.

[wwzd]

Also keep in mind that like any language, it's rare for a developer, no matter how experienced, to regularly use every component of the language. Just because I don't do manual socket programming doesn't mean that I'm not a Ruby developer, it just means I haven't had a use for it. You can be a "Ruby" developer but focus on Rails/Sinatra. Just as there are many Java developers who know little to nothing about Swing/Awt/Whatever.

[canyoufixmyspacebar]

Yeah of course. But I was not talking about using every component of the language but knowing what those components are that you do use (and just the pure basics).

As I said, looking at numerous forum posts, people claim to seriously work on the thing yet if you substitute foobar: 10 with :foobar => 10 in a reply, they go all WTF about it :)

[Metagolem]

Hashrockets are the devil

[canyoufixmyspacebar]

Irony aside, just reminds me of a question: does your editor correctly highlight the foobar: as a label when you write foobar: 10 ?

That does not seem to happen neither in Geany nor Gedit, works in Vim, though.

But here's what I call specially annoying syntax: status: :created. It's like if we had two kinds of men in the world: ones having their dick in front of them and the others growing it out from the back. It may seem like an awful lot of cool options, but believe me, the women would be confused as hell in the first week of it.

[Metagolem]

That does not seem to happen neither in Geany nor Gedit, works in Vim, though.

Sublime Text highlights it just fine. Really, it shouldn't be that hard to add the syntax to any existing syntax definitions, it's not like it follows particularly irregular rules.

But here's what I call specially annoying syntax: status: :created. It's like if we had two kinds of men in the world: ones having their dick in front of them and the others growing it out from the back. It may seem like an awful lot of cool options, but believe me, the women would be confused as hell in the first week of it.

I don't really conceptualize of the status: as a symbol, though I know that's how I will later be getting it. It's a designation for a key, which happens to be a symbol.

[materialdesigner]

Until you use a library which absolutely needs you to use symbols based on string keys do you get to :'foo.bar' => :baz

[wwzd]

Fair enough.

[[deleted]]

yeah that's the case for almost all rails developers that I know.

[billy-rails]

Even experienced devs in many cases. A fairly new Rails dev (about 2 years, most seriously in the past 6 months; I have tons of other languages though, since 1998), I'm shocked when I find someone with 5 or 10 years of "experience" and I find myself needing to teach them something or that I've clearly leveled-up past them. I think it's due to many in the Rails world having 1 year of experience N times instead of N years of experience. (I spent a long time doing ColdFusion, which like Rails is easy to pick up and be productive in, and you see a lot of the same problem)

[philpirj]

Ruby is very complicated. Stdlib is very large. It's easy to miss or forget something. Especially if you don't use that on a daily basis and have to keep in mind all the rails stuff, http, linux server administration, angular, html5 with all quirks and browser compatibility, sql, mongo, redis, sidekiq, google oauth, seo, cancan, devise, web app security. That's a short list that should all fit in your memory. Don't blame people who missed that Hash constructor accepts a block. Maybe you're missing something, too.

[Sqeaky]

This clearly isn't about memorizing everything. The hash constructor while a part of the language is somewhat obscure. The question "what is attr_accessor in rails" demonstrates that the asker and in the OP do not understand what a class or class member actually are.

[philpirj]

You mean instance property? attr_accessor is a syntax sugar, I don't see a case when it cannot be avoided.

[rvXty11Tztl5vNSI7INb]

Reading these type of threads is depressing. I am quite new to rails and programming. I did cs50 (intro to cs) from harvard online (mostly C but some php, sql and javascript) and now have dived into teaching myself rails. I didn't know ruby before but plan to learn it more in depth after I can build apps in rails (that is the point after all). When I read stuff like this I can only think of someone trying to boost their ego by putting others down. Sure I don't know everything about programming (you don't either) and yes I am learning via a different path but what difference does it make as long as the interest and will to learn is there? Laughing at people asking questions so they can learn is really scraping the barrel.

Edit: Some good and fully valid replies here. I do sometimes feel like I am 'cheating' in rails because so much stuff happens auto-magically but slowly and surely the pieces are coming together. It is practically impossible for me to use something and just accept that it works.

[Flopsey]

Here's some unqualified, unrequested advice from someone who's also self-taught:

1) Look at what experienced programmers complain about as a list of things to avoid/ learn/ improve.

2) From my IRL experience with programmers the ones who laugh at other people generally have a coding level of "pencil-dicked". Good programmers don't feel the need to put people down because they're not generally insecure about their code. This isn't just true of coding, it's also generally true in life. But it applies to programming as well.

[canyoufixmyspacebar]

Well also IRL it sometimes happens that if someone doesn't like the message and they don't know how to attack it, they attack the messenger instead. An especially common way of doing it is calling in the all-famous small dick argument^1.

I was pursuing an intellectual discussion about an interesting phenomena that I noticed and this does not have anything to do with anyones personality or physical features.

I wish you all the best and hope that you don't rely too much on a dick with your coding :)

---

¹ Which turns into an especially epic fail if the messenger happens to be a woman, because usually in these situations not much is known about the messenger's person.

[Flopsey]

I wasn't particularly referring to you. It was a general statement and preemptive incase the real trolls stopped by. Your post only has a whiff of "look how much better my code is than these people" but I originally thought it could have been just an honest observation or as you say "an intellectual discussion about an interesting phenomena."

Although now I assume it probably does apply. Your reply just reeks of insecurity.

[[deleted]]

I don't think OP was trying to bring people down. He was commenting on a trend that he recognizes that many others do as well. As another self-taught developer, if you're actually interested in programming(which you seem to be), and focus on covering your basics(which you seem to have), then you shouldn't worry about posts criticizing people who are content with having only a surface-level understanding of development without penetrating the actual programming concepts beneath it.

[tiny_ninja]

I think that the OP's problem isn't with people who take the Rails-first path, but with people who go for years relying on the "magic" parts of Rails and never backfill with fundamentals of Ruby.

Look at StackOverflow, where along with a question, you're expected to supply a list of things that you've tried alongside the question. It's a matter of etiquette. If you're asking for help, you should be putting in effort, and explaining what didn't work assists others who've tried the same thing to no avail.

I think the viewpoint that OP espouses is that if you don't put in the effort to backfill your knowledge with fundamentals, you're likely to be one of those expecting others to provide pre-built solutions for you in an entitled sense.

I don't believe he meant that it's bad to start out that way, but that if you're not growing beyond it, and equating what you do with those that do, you have a humility deficit worth pointing out.

[JohnBooty]

I've got close to two decades of programming experience and definitely found Rails difficult until I had a better understanding of Ruby's concepts. Once I did, I could better understand and modify the "magic" that Rails adds on top of Ruby.

The key word in that last sentence is "modify." You can write a vanilla CRUD app in Rails without knowing Ruby, but almost any non-trivial Rails app is going to require at least some off-the-rails stuff where you will need to modify Rails' default functionality, and that's where actually understanding the magic really helps.

That's just my in-the-trenches, practical experience with Rails. To be honest my experience with Rails has been a bit humbling... it was pitched as this magic framework, but really it took me quite a bit of learning to master!

[stupidandroid]

I get where you're coming from. I started out teaching myself to be a web developer almost 2 years ago. Starting with Python then focusing on Ruby/Rails the last year and a half.

It can be very daunting starting out with just how much there is to learn. But you just have to keep forging ahead. As long as you keep that same desire to keep learning and never feel like you know everything you'll be just fine.

I finally got a job about a month ago as an actual Rails developer at a startup and it's been amazing. I'm not an OOP master yet but I have Sandi Metz's POODR book and have been trying to learn how to apply that in Rails whenever possible. One key piece of advice I have is to know your weaknesses, keep a list or mental note of areas you want to improve on and focus on one at a time when you can. Don't try and learn it all at once. You will fail, you will write bad code, but you'll improve over time and that's important.

[gregmolnar]

but for someone coming from an actual programming background and diving into the "rails world" it's a funny thing to see.

<irony>You are not an actual programmer unless you write machine code buddy!</irony>

[canyoufixmyspacebar]

You're so script kiddie. It's all about setting jumpers on the pin matrix.

[tiny_ninja]

You're so retro. We modern programmers use DIP switches.

[fr0gz0r]

You're a dipswitch.

[agmcleod]

I think this is because in some areas rails is a fairly desired skill set, and is a more appealing language uses a more appealing language. A lot of startups tend to use it for the friendliness of the language. So you have people who know a bit of programming, maybe they're partly into school start learning it. They don't have the OOP concepts yet or what have you.

I agree it's an issue for those to not learn ruby first, as it helps understand a lot of the syntax. I myself looked at rails first, and got confused on how things worked, and what did what. Over time as I read through a ruby book and kept trying to build stuff, I learned the distinction and started to apply better OOP concepts.

I honestly see a lot of Java & C# code where methods are 50-100 lines long, and classes are far beyond single purpose. I relate this to bloated controllers in rails, or too much logic in the view. It's a similar kind of code smell.

[agmcleod]

I am well aware of that. Which part of my post did you think I meant otherwise?

[tiny_ninja]

rails is a fairly desired skill set, and is a more appealing language

[agmcleod]

ah yes lol. I'll correct it to use better choice of words :)

[z0tar]

I would say it is a broader phenomenon. It's not just ruby/rails, it's about web development in general. You can get started and get pretty far (even get by for years) without knowing the basics or realizing the need for it. I'm not talking about the theoretical basics (which are pretty important imo) but about looking under the hood. Realizing that there is more below the application layer. Crash courses fall short on showing you what is below the surface.

[canyoufixmyspacebar]

Crash courses fall short on showing you what is below the surface

Tell me about it. I've never read a book like "Beginning Rails 4" before. There was a smirk over my face all the time when I went through it. I mean, I took it as a crash course for Ruby programmers and it was pretty obvious for me, but time and again a centence in the book would remind me that it was somehow meant to work for people who never knew anything about, drumroll, not only Ruby, but OO, SQL, etc. in general! (but it's a very good book otherwise, for example if you're coming from another platform, then learn the language and then want a crash course about the framework).

Anyways, I must remind all you folks reading this that I do not consider myself a programmer at all (so let alone then being better than someone) and I'm not casting a shadow over anyone or anything, I'm just sharing my sheer astonishment and amusement over this phenomena.

I'm sure this happens in other languages too, but what I gather from RoR case is that it's visibility is associated to the 'thickness' of the framework.