3 ms·

It's definitely nice to get a resource like this, but anyone who spends a reasonable amount of time writing applications for Rails should pick up all this. Ther

by kondro 16y ago

It's definitely nice to get a resource like this, but anyone who spends a reasonable amount of time writing applications for Rails should pick up all this. There really isn't that much Magic, it's convention. Think of it like Struts, Spring or the Zend framework with all the configuration done for you with excellent documentation.

elmomalmo 16y ago
Agreed, any reasonable developer looks past the magic myth. Like the article says, you read the source code and gain an understanding. However, I'd dispute the assertion that Rails has excellent docs, it certainly hasn't always been the case. When I started with Rails, in 2006, the docs where woefully out of date. All the latest information that was available was in a variety of disparate blog posts, written by Rails enthusiasts. That was a significant barrier to learning at the time.
bad_user 16y ago
I think both the author and you are missing the point. Ignoring the people that just reiterate poorly formulated ideas heard somewhere else, the complaints about magic were quite valid: originally the Rails source-code was too hard to read and comprehend. When I used Django, I read most of the source-code from django.core and even stuff from django.contrib. Django also has its quirks. I could understand pretty easily how a ForeignKey works (I don't know, it just clicked), but understanding how a FileField works was hard because the object I was receiving was just a proxy that forwarded all messages to an object that I couldn't figure out how it got instantiated (or the logic behind the decision). And when I did figure out how the thing worked, I puked a little and came up with an inelegant hack for what I was trying to do. Figuring out how stuff works is really useful when you want to extend the provided functionality or work around a bug that has to be fixed RIGHT NOW or break free of those conventions that sometimes are just too limiting. Not to mention incomplete documentation which many times is seriously lacking. Django's source code (when compared to Rails), while also full of conventions, has this neat property that I like: you can read and understand 70% of its source-code (going line-by-line with a debugger) without fully understanding Python's meta-programming capabilities, which makes it really friendly to beginners. I mean, the convention for "has_many :tags" is really neat, but such conventions have to have complementaries in the Rails source-code ... i.e. clear conventions for how to find and read the source-code of this mechanism. Fortunately Rails 3 got a major refactoring effort, that I could read portions of it. It's more modular and reader-friendly now: and this is partly because people complained about magic. With a couple of additions here and there, it can be the web framework I've been waiting my whole web-dev carrier :-)
- josevalim 16y ago
  I agree with you. I had the post a bit longer but I cut it down a bit before publishing and it discussed some points you mentioned. People had reasons to call Rails as something "magic" some time ago. But "magic" at that time really translated to poor design and lack of documentation. Most of Rails has changed since then. Rails has good documentation for already some time, the internals are cleaner than ever before and should continue improving (for example, check Aaron Patterson's work on Active Record for Rails 3.1). But people still call it magic, because it became an habit. Even simpler and smaller things in Rails, like the "find_by_email" method in Active Record that relies on Ruby's method_missing, were for a long time called as "magic finders". Another proof of that habit was my take on Inherited Resources. The code is clean, modular, well-tested since day one, but I still stamped "magic" on the README when I first released it because it sounded cool. This is the mistake I want to prevent people from doing it all over again. Maybe a better moto would be: "There is not such thing as magic, only bad and poorly-documented code."

by kondro 16y ago

elmomalmo 16y ago

Agreed, any reasonable developer looks past the magic myth. Like the article says, you read the source code and gain an understanding. However, I'd dispute the assertion that Rails has excellent docs, it certainly hasn't always been the case. When I started with Rails, in 2006, the docs where woefully out of date. All the latest information that was available was in a variety of disparate blog posts, written by Rails enthusiasts. That was a significant barrier to learning at the time.

bad_user 16y ago

I think both the author and you are missing the point. Ignoring the people that just reiterate poorly formulated ideas heard somewhere else, the complaints about magic were quite valid: originally the Rails source-code was too hard to read and comprehend. When I used Django, I read most of the source-code from django.core and even stuff from django.contrib. Django also has its quirks. I could understand pretty easily how a ForeignKey works (I don't know, it just clicked), but understanding how a FileField works was hard because the object I was receiving was just a proxy that forwarded all messages to an object that I couldn't figure out how it got instantiated (or the logic behind the decision). And when I did figure out how the thing worked, I puked a little and came up with an inelegant hack for what I was trying to do. Figuring out how stuff works is really useful when you want to extend the provided functionality or work around a bug that has to be fixed RIGHT NOW or break free of those conventions that sometimes are just too limiting. Not to mention incomplete documentation which many times is seriously lacking. Django's source code (when compared to Rails), while also full of conventions, has this neat property that I like: you can read and understand 70% of its source-code (going line-by-line with a debugger) without fully understanding Python's meta-programming capabilities, which makes it really friendly to beginners. I mean, the convention for "has_many :tags" is really neat, but such conventions have to have complementaries in the Rails source-code ... i.e. clear conventions for how to find and read the source-code of this mechanism. Fortunately Rails 3 got a major refactoring effort, that I could read portions of it. It's more modular and reader-friendly now: and this is partly because people complained about magic. With a couple of additions here and there, it can be the web framework I've been waiting my whole web-dev carrier :-)

josevalim 16y ago
I agree with you. I had the post a bit longer but I cut it down a bit before publishing and it discussed some points you mentioned. People had reasons to call Rails as something "magic" some time ago. But "magic" at that time really translated to poor design and lack of documentation. Most of Rails has changed since then. Rails has good documentation for already some time, the internals are cleaner than ever before and should continue improving (for example, check Aaron Patterson's work on Active Record for Rails 3.1). But people still call it magic, because it became an habit. Even simpler and smaller things in Rails, like the "find_by_email" method in Active Record that relies on Ruby's method_missing, were for a long time called as "magic finders". Another proof of that habit was my take on Inherited Resources. The code is clean, modular, well-tested since day one, but I still stamped "magic" on the README when I first released it because it sounded cool. This is the mistake I want to prevent people from doing it all over again. Maybe a better moto would be: "There is not such thing as magic, only bad and poorly-documented code."