5 ms·

First he submitted a bug, and they closed it. Then, he reopened the bug to prove it was a bug, and they closed it again. Then, he submitted a new bug, 1001 ye

First he submitted a bug, and they closed it. Then, he reopened the bug to prove it was a bug, and they closed it again. Then, he submitted a new bug, 1001 years in the future, and they closed it, saying "Good one ;)" Then, he committed a text document to master, and they got all upset about it and got Github staff involved. How about this Ruby devs: actually consider what you're saying. Isn't the point of Ruby to make things simple? Yet, somehow, making rational default choices only applies to everything but this. I know that you love to feel better than everyone else (see: http://37signals.com/svn/posts/3124-give-it-five-minutes http://37signals.com/svn/posts/3124-give-it-five-minutes), but seriously, you shouldn't get all upset about it later when it turns out you're wrong. This is why I refuse to learn Ruby. I don't want to be associated with that community. "Learn Ruby if you want to be associated with a bunch of people who call themselves Rockstar Programmers."

angersock 15y ago
whoa whoa whoa Ruby is a really cool language with some fascinating features--don't limit yourself by assuming that you also have to learn the Rails stuff. Seriously, give it a shot in one of its more palatable forms.
- masklinn 15y ago
  > with some fascinating features If you come from PHP or Java anyway.
  - angersock 15y ago
    yes yes yes no new genuinely new programming ideas have happened since the 70s and 80s. Don't be obtuse.
    - masklinn 15y ago
      There's nothing obtuse about it, new programming ideas have happened since the 70s and 80s but as far as I know none of them is in Ruby, and you're basically assuming tylermenezes does not know about any of the (much older) features which did get into Ruby.
    - lclarkmichalek 15y ago
      Tell that to STM. Sure most new programming languages are amalgamations of existing concepts, but new stuff does turn up from time to time.
      - Robin_Message 15y ago
        But STM is from the 80s -- 1986 to be precise.
subdigital 15y ago
I think you're confusing Ruby with Rails. Flat out refusing to learn a wonderful programming language because you don't agree with it's dominant web framework is silly.
nwmcsween 15y ago
"This is why I refuse to learn Ruby. I don't want to be associated with that community. "Learn Ruby if you want to be associated with a bunch of people who call themselves Rockstar Programmers."" You refuse to learn a language due to how a project acts? Have you ever read the {open,free,net}BSD or Linux mailing lists? You're not going to make it far in software development with an attitude like that.
- Joeboy 15y ago
  I'm not intimate with the Ruby community, but the quality / quantity / culture of the community surrounding a programming language seems like a reasonable consideration to me.
- pp19dd 15y ago
  It's a fairly rational argument to have a preference/affinity for programming languages based on communities surrounding them. He stated his preferences, and that's perfectly fine. You might have been too quick in passing that judgement. Unless a quantum computing breakthrough alters the way we control computers, there will never be a one-language to rule them all. We'll continue having a wide diaspora and will take evolutionary steps to bind ideas together. Preemptive and comprehensive security model might be just one of those ideas.
  - nwmcsween 15y ago
    No it's not rational to assume a language isn't worth learning due to how some people act in fact it's ignorant. You use a tool due to it's merit not due to presumption of how everyone acts.
krobertson 15y ago
The "they" in this case being the Rails team and not Github? A common thread here seems to be grouping Github and Rails. Its interesting how bring up their Terms Of Service gets discounted and the holy war just takes over. No where did I mention Rails, Ruby, community, or anything else. Me: He broke the rules. Retort: I like plant. Disclaimer: The actions of individuals are representative of individuals. Drawing dramatic generalizations accomplishes nothing. Yes, there are more vocal asses in every community. For every asshat there is likely 100 quiet people. Right now, I'm being an asshat. Gee, homakov is Russian. All Russians must want to hack your site. Really? No, its a dumb generalization.
deleted 15y ago
[deleted]
chrisumbel 15y ago
Indeed, github, Ruby and Rails are all different things. I do recommend approaching language/platform/tool choices form an engineering rather than a social point of view. Don't get me wrong, though. I can see being turned off by rockstars, but you've found a language unencumbered by them?
wycats 15y ago
Not all security vulnerabilities can be protected automatically by a web framework. In many cases, frameworks provide features that developers can use themselves to secure their applications. Example: XSS is a common web security problem. In short, it means that putting user-originated data back on the page unescaped is unacceptable. Before Rails 3.0, the Rails approach to this problem was to provide a helper (h), which you could use to escape content that you knew to be vulnerable. Unfortunately, many Rails users did not use this feature in all places they should have used it. As a result, many applications (Twitter included) suffered from whack-a-mole XSS vulnerabilities. We were unable to solve this problem in the 2.x branch, because automatically escaping all text being put onto the page would be a massive breaking change and would break every app in existence. Further, simply escaping all text would not really solve the problem. For example, the "<form>" tag generated by Rails itself should not be escaped, while any of its contents or attributes provided by the application should. Asking the user to take on the responsibility to mark Rails-generated content as not needing escaping would reintroduce the same problem we had before: people would "unescape" things too eagerly, and apps would tend to have vulnerabilities. The solution was to release a plugin for Rails 2.3 users (rails_xss) and change the default in Rails 3. It isn't perfect: there are still cases where applications have to mark strings as "safe", and applications that have to do so often might have the same problem, but I think we did a good job, all things considered. This case is quite similar. Rails provides all the tools necessary to have a secure application (attr_accessible is the equivalent of h), but many apps don't use it correctly (or at all). In short, a Rails security default seems to be wrong, insofar as "wrong" means that many people fail to use the security feature, causing their applications to be vulnerable. As with the XSS feature, fixing this problem requires some thought. Simply changing the default would break a lot of applications in the wild. Like XSS, it's probably correct to do so anyway here. However, like XSS, we should make sure that we have done everything we possibly can to mitigate the additional cost associated with complying with the new default. If it's too painful, many people will overeagerly bypass the feature, reintroducing the very issue we were trying to protect them from. In this case, I have proposed a solution that I think will mitigate a lot of the problem (https://gist.github.com/1974187 https://gist.github.com/1974187), and we will likely ship it as a Rails 3.2 plugin. This will allow us to gather feedback about unexpected consequences and ensure that when we change the default for Rails 4 (which has not even shipped a prerelease yet), it actually mitigates the security problem in the vast majority of Rails applications.
drogus 15y ago
tylermenezes: the first "closed/open" thing was done by accident, @homakove didn't reopen it. I closed the second bug as this was just kind of trolling to get attention, there was no point on keeping it open.
collypops 15y ago
"Go looking for serious security holes in Rails? Change defaults so Rails users don't unsuspectingly open themselves up to attack? Fuck that! Let's add CoffeeScript instead. That's how I roll" - DHH* * Not actually DHH.

angersock 15y ago

whoa whoa whoa Ruby is a really cool language with some fascinating features--don't limit yourself by assuming that you also have to learn the Rails stuff. Seriously, give it a shot in one of its more palatable forms.

masklinn 15y ago
> with some fascinating features If you come from PHP or Java anyway.
- angersock 15y ago
  yes yes yes no new genuinely new programming ideas have happened since the 70s and 80s. Don't be obtuse.
  - masklinn 15y ago
    There's nothing obtuse about it, new programming ideas have happened since the 70s and 80s but as far as I know none of them is in Ruby, and you're basically assuming tylermenezes does not know about any of the (much older) features which did get into Ruby.
  - lclarkmichalek 15y ago
    Tell that to STM. Sure most new programming languages are amalgamations of existing concepts, but new stuff does turn up from time to time.
    - Robin_Message 15y ago
      But STM is from the 80s -- 1986 to be precise.

subdigital 15y ago

I think you're confusing Ruby with Rails. Flat out refusing to learn a wonderful programming language because you don't agree with it's dominant web framework is silly.

nwmcsween 15y ago

"This is why I refuse to learn Ruby. I don't want to be associated with that community. "Learn Ruby if you want to be associated with a bunch of people who call themselves Rockstar Programmers."" You refuse to learn a language due to how a project acts? Have you ever read the {open,free,net}BSD or Linux mailing lists? You're not going to make it far in software development with an attitude like that.

Joeboy 15y ago
I'm not intimate with the Ruby community, but the quality / quantity / culture of the community surrounding a programming language seems like a reasonable consideration to me.
pp19dd 15y ago
It's a fairly rational argument to have a preference/affinity for programming languages based on communities surrounding them. He stated his preferences, and that's perfectly fine. You might have been too quick in passing that judgement. Unless a quantum computing breakthrough alters the way we control computers, there will never be a one-language to rule them all. We'll continue having a wide diaspora and will take evolutionary steps to bind ideas together. Preemptive and comprehensive security model might be just one of those ideas.
- nwmcsween 15y ago
  No it's not rational to assume a language isn't worth learning due to how some people act in fact it's ignorant. You use a tool due to it's merit not due to presumption of how everyone acts.

krobertson 15y ago

The "they" in this case being the Rails team and not Github? A common thread here seems to be grouping Github and Rails. Its interesting how bring up their Terms Of Service gets discounted and the holy war just takes over. No where did I mention Rails, Ruby, community, or anything else. Me: He broke the rules. Retort: I like plant. Disclaimer: The actions of individuals are representative of individuals. Drawing dramatic generalizations accomplishes nothing. Yes, there are more vocal asses in every community. For every asshat there is likely 100 quiet people. Right now, I'm being an asshat. Gee, homakov is Russian. All Russians must want to hack your site. Really? No, its a dumb generalization.

deleted 15y ago

[deleted]

chrisumbel 15y ago

Indeed, github, Ruby and Rails are all different things. I do recommend approaching language/platform/tool choices form an engineering rather than a social point of view. Don't get me wrong, though. I can see being turned off by rockstars, but you've found a language unencumbered by them?

wycats 15y ago

Not all security vulnerabilities can be protected automatically by a web framework. In many cases, frameworks provide features that developers can use themselves to secure their applications. Example: XSS is a common web security problem. In short, it means that putting user-originated data back on the page unescaped is unacceptable. Before Rails 3.0, the Rails approach to this problem was to provide a helper (h), which you could use to escape content that you knew to be vulnerable. Unfortunately, many Rails users did not use this feature in all places they should have used it. As a result, many applications (Twitter included) suffered from whack-a-mole XSS vulnerabilities. We were unable to solve this problem in the 2.x branch, because automatically escaping all text being put onto the page would be a massive breaking change and would break every app in existence. Further, simply escaping all text would not really solve the problem. For example, the "<form>" tag generated by Rails itself should not be escaped, while any of its contents or attributes provided by the application should. Asking the user to take on the responsibility to mark Rails-generated content as not needing escaping would reintroduce the same problem we had before: people would "unescape" things too eagerly, and apps would tend to have vulnerabilities. The solution was to release a plugin for Rails 2.3 users (rails_xss) and change the default in Rails 3. It isn't perfect: there are still cases where applications have to mark strings as "safe", and applications that have to do so often might have the same problem, but I think we did a good job, all things considered. This case is quite similar. Rails provides all the tools necessary to have a secure application (attr_accessible is the equivalent of h), but many apps don't use it correctly (or at all). In short, a Rails security default seems to be wrong, insofar as "wrong" means that many people fail to use the security feature, causing their applications to be vulnerable. As with the XSS feature, fixing this problem requires some thought. Simply changing the default would break a lot of applications in the wild. Like XSS, it's probably correct to do so anyway here. However, like XSS, we should make sure that we have done everything we possibly can to mitigate the additional cost associated with complying with the new default. If it's too painful, many people will overeagerly bypass the feature, reintroducing the very issue we were trying to protect them from. In this case, I have proposed a solution that I think will mitigate a lot of the problem (https://gist.github.com/1974187 https://gist.github.com/1974187), and we will likely ship it as a Rails 3.2 plugin. This will allow us to gather feedback about unexpected consequences and ensure that when we change the default for Rails 4 (which has not even shipped a prerelease yet), it actually mitigates the security problem in the vast majority of Rails applications.

drogus 15y ago

tylermenezes: the first "closed/open" thing was done by accident, @homakove didn't reopen it. I closed the second bug as this was just kind of trolling to get attention, there was no point on keeping it open.

collypops 15y ago

"Go looking for serious security holes in Rails? Change defaults so Rails users don't unsuspectingly open themselves up to attack? Fuck that! Let's add CoffeeScript instead. That's how I roll" - DHH* * Not actually DHH.