4 ms·

There is no magic in Rails, it's just Ruby code. There will always be APIs that shouldn't be given untrusted data. When this happens anyway, calling it an "an

There is no magic in Rails, it's just Ruby code. There will always be APIs that shouldn't be given untrusted data. When this happens anyway, calling it an "anti-pattern" does not mean you have perceived some kind of systemic fundamental flaw in the framework. That's just a transparently self-serving way for you to feel superior because after all you're a "serious developer".

metaphorm 14y ago
magic is just a shorthand for "code executed automatically, behind the scenes, based on some reasonable assumptions". Rails does a whole lot of this type of magic, as does basically every framework.
- bithive123 14y ago
  Then it's a meaningless term. The fact that iTunes doesn't need to ship with drivers for my sound card is the same kind of "magic".
  - adamors 14y ago
    It is meaningless and I have a growing suspicion that it was coined by people who came from writing (PHP) websites from scratch. I remember being pleasantly surprised when I wrote my first website with a framework after a couple of years building sites from practically nothing. Compared to frameworkless PHP, Rails is magic but then so is Django or ASP.NET MVC.
  - metaphorm 14y ago
    this isn't a good analogy. Rails is a software development framework whose users are programmers. iTunes is a media player whose users are non-technical. in other words Rails is a tool while iTunes is a finished product. you wouldn't compare a hammer with a cabinet, would you? if zero-framework development is a hammer, then development with a framework is a power-tool combination drill/hammer/driver. the power-tool does so much more then the basic tool that it feels "magical". its not a meaningless term then. its a description of the power of the tool.
- batiste 14y ago
  I thought the magic term had something to do with explicit vs implicit. Some framework just don't call that much code behind your back without explicitly calling stuff. Rails is more oriented in a "convention over configuration" mindset, in this sense it might be more "magic" than others.
- deleted 14y ago
  [deleted]
- hackinthebochs 14y ago
  "Magic" code is code that gives little or no indication that it's being executed in the contexts that are affected. Think of this as the "locality" of code. Do the names and operations being referenced in the current context completely describe the functionality that is being executed? Then the code has high locality. Magic code is code with low locality.
- hackinthebochs 14y ago
  "Magic" code is code that gives little or no indication that it's being executed in the contexts that are affected. Think of this as the "locality" of code. Do the names and operations being referenced in the current context completely describe the functionality that is being executed? Then the code has high locality. Magic code is code with low locality.
papsosouid 14y ago
>There is no magic in Rails, it's just Ruby code In the context of dynamic languages, "magic" does not mean someone casting spells. Of course it is just ruby code. It is magic ruby code. Code which is executing a whole bunch of stuff behind the scenes without the user of that code (the web developer) being aware. Pointing out that doing really bad things like this is bad is no more transparently self-serving that you claiming "oh rails is totally fine and doing stupid shit is cool because its not really magic". Yes, it is a systemic fundamental flaw in the framework. The entire framework is built from the ground up on the idea that doing this kind of nonsense is good.
- adamors 14y ago
  > Code which is executing a whole bunch of stuff behind the scenes without the user of that code (the web developer) being aware But isn't this the whole point of a framework? That stuff gets done for you so you don't have to write everything from the ground up? Plus if you want to know exactly how everything is done, you can see it for yourself. As we all know Rails is open source and the code is perfectly readable for anyone that knows Ruby.
  - tedunangst 14y ago
    I want my framework to do the boring stuff I don't want to do myself. That doesn't imply I want it running off and doing other things I don't even know about.
  - papsosouid 14y ago
    No, that is not the point of a framework at all. I am absolutely shocked that you would present it as though the options are "blindly do stuff automagically" vs "write everything from scratch". A framework is more useful if I control it, not less useful. If you want to give me the ability to parse yaml from GET params, then give me a parse_yaml_from_get_params_with_a_really_long_rails_function_name() function to do it with. Don't just do it all the time in case I might want it. You don't need to automatically run a feature in order for the feature to exist, be used, and be useful.
  - 14y ago
sanderjd 14y ago
I agree with you about the grating self-satisfaction of a certain vocal set of commenters, and have argued in the past myself that there is no "magic" in Rails, but I think what people really mean when they say "magic" as related to a chunk of software, is that it has so many layers of abstraction that its function is obscured. All software deals in layers of abstraction, which makes it easier to reason about general function, but obscures specific function. All users of all software must make a constant trade-off between assuming abstractions are functioning properly and personally verifying their function, and all software must decide where the line between too little abstraction and too much obscurity should be drawn. When people talk about the "magic" in Rails, they mean that Rails has drawn that line quite far toward the abstraction side, which is true. There are some abstractions that are a net positive for security, and some that hinder it. While I don't agree with the condescending attitude of your parent and the many similar commenters, who seem to think no software they've ever written or integrated with has ever had a security issue, I think it is fair at this point to say that the level of abstraction in Rails' handling of user data has been a hindrance to its security. I think that is probably also a fair thing to say about most pieces of software that have ever handled potentially-malicious user data.
- bithive123 14y ago
  I would tend to agree, except that Rails can't be all things to all people. Experienced developers don't find it nearly as magical as most of the people being told to "just learn Rails" when they get interested in web development. I totally get that abstractions can obscure security issues, but some of the reactions I've been seeing to Rails having security issues are akin to a parent giving a child a dangerous toy without reading the instructions and then getting mad at the toy company when the child hurts itself.
  - sanderjd 14y ago
    I think we agree on all points. People with less experience with Rails see "magic" where people with more experience see abstractions with all the trade-offs implied, and importantly, know how to dig into those abstractions to understand what is really going on. But that digging in process tends to be spurred by surprising behavior, rather than security consciousness. I like your analogy to toys and children, except that the danger of these toys is not immediately apparent to adults either. But the toy company has been very prompt and transparent in finding ways for people to avoid the danger once it becomes apparent.

metaphorm 14y ago

magic is just a shorthand for "code executed automatically, behind the scenes, based on some reasonable assumptions". Rails does a whole lot of this type of magic, as does basically every framework.

bithive123 14y ago
Then it's a meaningless term. The fact that iTunes doesn't need to ship with drivers for my sound card is the same kind of "magic".
- adamors 14y ago
  It is meaningless and I have a growing suspicion that it was coined by people who came from writing (PHP) websites from scratch. I remember being pleasantly surprised when I wrote my first website with a framework after a couple of years building sites from practically nothing. Compared to frameworkless PHP, Rails is magic but then so is Django or ASP.NET MVC.
- metaphorm 14y ago
  this isn't a good analogy. Rails is a software development framework whose users are programmers. iTunes is a media player whose users are non-technical. in other words Rails is a tool while iTunes is a finished product. you wouldn't compare a hammer with a cabinet, would you? if zero-framework development is a hammer, then development with a framework is a power-tool combination drill/hammer/driver. the power-tool does so much more then the basic tool that it feels "magical". its not a meaningless term then. its a description of the power of the tool.
batiste 14y ago
I thought the magic term had something to do with explicit vs implicit. Some framework just don't call that much code behind your back without explicitly calling stuff. Rails is more oriented in a "convention over configuration" mindset, in this sense it might be more "magic" than others.
deleted 14y ago
[deleted]
hackinthebochs 14y ago
"Magic" code is code that gives little or no indication that it's being executed in the contexts that are affected. Think of this as the "locality" of code. Do the names and operations being referenced in the current context completely describe the functionality that is being executed? Then the code has high locality. Magic code is code with low locality.
hackinthebochs 14y ago
"Magic" code is code that gives little or no indication that it's being executed in the contexts that are affected. Think of this as the "locality" of code. Do the names and operations being referenced in the current context completely describe the functionality that is being executed? Then the code has high locality. Magic code is code with low locality.

papsosouid 14y ago

>There is no magic in Rails, it's just Ruby code In the context of dynamic languages, "magic" does not mean someone casting spells. Of course it is just ruby code. It is magic ruby code. Code which is executing a whole bunch of stuff behind the scenes without the user of that code (the web developer) being aware. Pointing out that doing really bad things like this is bad is no more transparently self-serving that you claiming "oh rails is totally fine and doing stupid shit is cool because its not really magic". Yes, it is a systemic fundamental flaw in the framework. The entire framework is built from the ground up on the idea that doing this kind of nonsense is good.

adamors 14y ago
> Code which is executing a whole bunch of stuff behind the scenes without the user of that code (the web developer) being aware But isn't this the whole point of a framework? That stuff gets done for you so you don't have to write everything from the ground up? Plus if you want to know exactly how everything is done, you can see it for yourself. As we all know Rails is open source and the code is perfectly readable for anyone that knows Ruby.
- tedunangst 14y ago
  I want my framework to do the boring stuff I don't want to do myself. That doesn't imply I want it running off and doing other things I don't even know about.
- papsosouid 14y ago
  No, that is not the point of a framework at all. I am absolutely shocked that you would present it as though the options are "blindly do stuff automagically" vs "write everything from scratch". A framework is more useful if I control it, not less useful. If you want to give me the ability to parse yaml from GET params, then give me a parse_yaml_from_get_params_with_a_really_long_rails_function_name() function to do it with. Don't just do it all the time in case I might want it. You don't need to automatically run a feature in order for the feature to exist, be used, and be useful.
- 14y ago

sanderjd 14y ago

I agree with you about the grating self-satisfaction of a certain vocal set of commenters, and have argued in the past myself that there is no "magic" in Rails, but I think what people really mean when they say "magic" as related to a chunk of software, is that it has so many layers of abstraction that its function is obscured. All software deals in layers of abstraction, which makes it easier to reason about general function, but obscures specific function. All users of all software must make a constant trade-off between assuming abstractions are functioning properly and personally verifying their function, and all software must decide where the line between too little abstraction and too much obscurity should be drawn. When people talk about the "magic" in Rails, they mean that Rails has drawn that line quite far toward the abstraction side, which is true. There are some abstractions that are a net positive for security, and some that hinder it. While I don't agree with the condescending attitude of your parent and the many similar commenters, who seem to think no software they've ever written or integrated with has ever had a security issue, I think it is fair at this point to say that the level of abstraction in Rails' handling of user data has been a hindrance to its security. I think that is probably also a fair thing to say about most pieces of software that have ever handled potentially-malicious user data.

bithive123 14y ago
I would tend to agree, except that Rails can't be all things to all people. Experienced developers don't find it nearly as magical as most of the people being told to "just learn Rails" when they get interested in web development. I totally get that abstractions can obscure security issues, but some of the reactions I've been seeing to Rails having security issues are akin to a parent giving a child a dangerous toy without reading the instructions and then getting mad at the toy company when the child hurts itself.
- sanderjd 14y ago
  I think we agree on all points. People with less experience with Rails see "magic" where people with more experience see abstractions with all the trade-offs implied, and importantly, know how to dig into those abstractions to understand what is really going on. But that digging in process tends to be spurred by surprising behavior, rather than security consciousness. I like your analogy to toys and children, except that the danger of these toys is not immediately apparent to adults either. But the toy company has been very prompt and transparent in finding ways for people to avoid the danger once it becomes apparent.