10 ms·

What is this post responding to? And who is the target audience? Reading this feels exactly like reading the passive aggressive facebook posts of someone curr

by cbs 14y ago

What is this post responding to? And who is the target audience? Reading this feels exactly like reading the passive aggressive facebook posts of someone currently in a fight with their boy/girlfriend. We get it, Rails is "opinionated", sorry I guess we're saying "omakase" these days. Who really gives a fuck? The reason DHH is getting loud complaints is because people feel that they carry a legitimate grievance but also feel no way to voice that opinion (or are trolls). Douchetastic talking down to them like exemplified in this post won't help (and will encourage trolls). People with limited knowledge and understanding of something and/or restricted mobility in tech aren't in a place to see things the way you see them. Help them get to that place, instead of just telling them how to see things with metaphors that only work once you're at that place. Or just don't engage them at all. Edit: Huh. This DHH blog post doesn't really feel on par as a response to the conversation in that github issue. But if it is, know that my post was written assuming the criticism was of the type he describes, not the type that transpired.

sync 14y ago
https://github.com/rails/rails/commit/61b91c4c55bcbd5a2ec85d6e1c67755150653dff https://github.com/rails/rails/commit/61b91c4c55bcbd5a2ec85d...
- bguthrie 14y ago
  I read that entire comment thread, and maybe my perspective is skewed, but I saw none of the behavior that DHH described there. The discussion was generally polite, the participants were mostly experienced Ruby developers with open-source and community track records, and their objections were well-supported. I have less sympathy now for the original post than I did.
  - malandrew 14y ago
    Exactly my thoughts. For example, I know for certain that José Valim is (or at least was last time I checked) a core ruby dev and he's against this change for example. DHH wants to sound like he's talking to trolls and the casual Rails user, but it's clear from the github thread that he's responding to seasoned members of the community as well, which quite frankly is a pretty shitty way to treat people who are known contributors. It's not a community, it's whoever screams loudest. To me that thread and this posts shows that DHH is willingly wearing horse blinders instead of keeping his opinions being open to being amended through thoughtful discussion with others as talented as he is. The biggest problem with this "omakase" attitude is that it's causing Rails developers to miss the boat on many new developments in the state of the art in web app development because legacy is now baked in via opinion. 37Signals hasn't been the forefront of web-app design for a few years now. There are plenty of single page web apps out there that are far more responsible and present a better user experience than tools from 37Signals. Don't get me wrong, they are still decent, but they aren't demonstrative of what is achievable insofar as excellent user experiences are concerned. Maybe this has changed, but I spent a year working on a single page webapp built on Rails and the asset pipeline was excruciatingly painful to debug to get your javascript and other assets handled properly.
    - rrouse 14y ago
      Rails Core. I don't think he actually has Ruby core access like Aaron Patterson (Tenderlove) Actually, I think he's sort of on vacation from Rails for the most part. He's got Elixir to work on. As for the matter at hand, Bundler author Yehuda Katz said that checking in binstubs is actually not a good idea and is not recommended. DHH is going against the grain here.
      - steveklabnik 14y ago
        Aaron and Yehuda are the only two people on both teams, Jose is on Rails Core only. He is also a maintainer of Bundler, as is Terence, who is also on the thread.
    - hosh 14y ago
      "37Signals hasn't been the forefront of web-app design for a few years now." Exactly. This shift isn't just "single page web apps" either. It is a generational shift. When people say "apps" now, it isn't a "web app". For all the thousands of hours of experience DHH says he has, it is stuck in a very narrow view while the rest of the world has moved on. That's ok though. The neat thing about open source is that developers and users do not have to suffer dinosaurs for long. It does mean that I can no longer depend on my Rails skill to put food on the table. Recruiters, desperate for Rails developers, will no longer be knocking on my door. It's a good thing I've been laying in the groundwork for the inevitable irrelevancy of Rails.
      - dasil003 14y ago
        "The rest of the world has moved on"? Good lord man, there's more than one way to skin a cat, and the web is not simply "apps". If you think Rails is irrelevant today than you are practicing fad-driven-development moreso than developing any real insight about the lay of the software land.
        hosh 14y ago
        Yes. The rest of the world has moved on. If you've characterized what I am saying here as "web is simply apps", then you do not understand what I am saying. I've written this in one other comment, I suppose I will repeat myself: (1) There are more mobile units being sold than personal computers. (2) More importantly, there are 2 year olds whose first experience with a personal computing device will be a smartphone or a tablet. When the start going to school, they will be forced to use a keyboard and will resent it. They will see this as a problem to be solved, and will solve it. This is a generation gap, something between 10 - 18 years from now. (3) Our generation tend to think of the "web" as experienced primarily through a desktop or a laptop. We also like to think that we are at the cutting edge. We are not: these two year olds are. (4) Rails is designed and used by people who experience the "web" through a desktop, and refuses to see where the world will be heading in the following years. There are a lot more. So yes. The direction Rails is going will lead it to its irrelevance.
  - cbs 14y ago
    I agree, this is a good example of why I think the complaints about criticism in the open source space need to be put back in check. Some are deserved, but these guys aren't trolls or well-intentioned idiots they're all trying to build the best rails they can. I've been in and witnessed plenty of disagreements in closed source development, they always get much much more heated than this before someone pulled rank.
  - KVFinn 14y ago
    >I read that entire comment thread, and maybe my perspective is skewed, but I saw none of the behavior that DHH described there. The discussion was generally polite, the participants were mostly experienced Ruby developers with open-source and community track records, and their objections were well-supported. I have less sympathy now for the original post than I did. My thoughts exactly. I read the DHH post first and thought, "I totally agree. That's why I like rails." But the thread was perfectly civil and the people in it were experienced and well known in the Ruby world.
remi 14y ago
What is this post responding to? This: https://github.com/rails/rails/commit/61b91c4c55bcbd5a2ec85d6e1c67755150653dff https://github.com/rails/rails/commit/61b91c4c55bcbd5a2ec85d...
- javajosh 14y ago
  Thanks. I'm not really a rails person, so forgive me if I have some questions. Am I correct in interpreting that thread as DHH not wanting to support multiple ruby package managers in the rails codebase? In particular, DHH has 'blessed' rbenv and that commit wants to support rvm? If this is the case, then I have to wonder: why is there any dependency on a package manager at all in the rails codebase? This just seems odd to me, and perhaps is the source of the conflict. E.g. people are fine with 'omakase' frameworks, but these menus typically don't include toolchain dishes. It would be like going into a restaurant and being told that you must use chopsticks, no forks allowed.
  - steveklabnik 14y ago
    > In particular, DHH has 'blessed' rbenv and that commit wants to support rvm? No. Two things are going on: 1. 'binstubs' will now be checked into source control. If I use MRI and you use JRuby, they'll start with different things, and therefore, cause conflict. 2. Many of the Ruby version switchers work with '#!/usr/bin/env ruby', but rbenv won't in certain circumstances, so an optimization for it has been built into the framework now. David maintains that if I use MRI and you use JRuby, or if I use rvm and you use rbenv, this is an 'organizational failure.'
    - phene 14y ago
      Because no one ever wants to test their app against multiple versions of Ruby...
    - sstephenson 14y ago
      "Many of the Ruby version switchers work with '#!/usr/bin/env ruby', but rbenv won't in certain circumstances, so an optimization for it has been built into the framework now." Incorrect. It is support for an enhancement that rbenv provides. You often want to invoke an application binstub from another program such as cron, and you want to use the per-project Ruby version specified in the application's root directory. Other version managers require you to spawn a subshell and load the version manager into the shell or otherwise set up the per-project Ruby version environment, then `cd` into the application directory, and finally run the binstub. rbenv requires an environment set-up step too—set `RBENV_DIR` to the application root—but provides a wrapper that eliminates the need for such gymnastics. When you change a binstub's shebang to `#!/usr/bin/env ruby-local-exec` rbenv automatically searches up the binstub's directory tree to find the right Ruby version.
wyuenho 14y ago
I think the analogy broke down somewhere in the upscale restaurant analogy, but let's continue with food joints. In a town where you have only 1 big cafeteria (Rails), a pizza joint (Sinatra) and a few tiny snack stands, if you have friends, you'd probably have to get with the gang and head to the cafeteria for lunch. Now when the head cook decides to not offer disposable utensils anymore because of environmental concerns, but then the large Jewish community complaints about the bowls aren't kosher, then the head cook comes out and post a notice on the entrance that says, "If you can't eat out of the bowls I cleaned, get out of my cafeteria." Ok never mind, analogies can only work up to a point, it's almost 2013 and the world didn't end, chill out Rubyists...
monsterix 14y ago
If you follow the mass of Rails community, you'll get it. Mostly. And perhaps this piece also explains how painful and yet very commonly faced situation (being trolled with expertise) this if for most open source creators/leaders in their line of work. A sort of professional hazard. Sooner or later, this has to get better I am sure.
pretoriusB 14y ago
>What is this post responding to? And who is the target audience? People making comments like yours? E.g >Reading this feels exactly like reading the passive aggressive facebook posts of someone currently in a fight with their boy/girlfriend. We get it, Rails is "opinionated", sorry I guess we're saying "omakase" these days. Who really gives a fuck? Well, a lot of people don't give a fuck, and that's the problem the post addresses. They want Rails to not be opinionated, or to cater to _their_ opinion. >The reason DHH is getting loud complaints is because people feel that they carry a legitimate grievance but also feel no way to voice that opinion (or are trolls). Douchetastic talking down to them like exemplified in this post won't help (and will encourage trolls). I don't see anything bad (sorry, I guess we're saying "douchetastic" these days) about the post. Sounds like a legitimate complain from the creator of a popular framework. I also fail to see how people feel they "carry a legitimate grievance" but at the same time "feel no way to voice that opinion". If they don't participate in the Rails project, then, no, they don't have a "legitimate grievance". They just have a personal grievance. If, on the other hand they do participate, then they have lots of ways to voice their opinions.
- cbs 14y ago
  I also fail to see how people feel they [...] This is the kind of thinking I was referencing. You don't see it because you're not in their shoes, that doesn't mean it doesn't exist. It's fine and all that people do disagree, that's just the context for my post. If you want someone to see things your way, build a bridge over the gap in their misunderstanding. DHH's blog post its just preaching to the converted. That's why I asked the context and audience. Saying "Rails is omakase" is a lot like saying "git stores a directed acyclic graph of revisions" or "A monad is just a monoid in the category of endofunctors". Almost nobody gets it unless they already get it, and the behavior he seemed to be complaining about was critcism from the unwashed masses. It just doesn't fit. I asked who gives a fuck because what small sliver of his audience is going to both understand what he is trying to express AND take anything new away from the post? My initial read was wrong, because (to stretch his abused metaphor) he is actually talking about the fact his chefs and regular customers really seem to think 2 tsp of spice in the soup would be better than the 1 tsp he is insistent on using. Which makes his post make even less sense. He could have have ditched the flowery prose, meandering critcisms of criticism and just said "This is important to me, I'm pulling rank."
hosh 14y ago
I'm not knee-deep in this specific issue with the binstubs, but I generally agree about the legitimate grievances. The Merb effort and the Rails 3.0 refactor resulted from people unable to voice what they need. We seem to keep repeating history. Asset Pipeline is also the wrong area of innovation to focus on. Rails should be baking in support for creating API only apps, make it easy to shed template-driven code and write UX-agnostic backends. Mobile is driving a need for creating API-only apps, and something like Asset Pipeline is an evolutionary dead-end. There are more smartphone-like devices in the world than personal computers; there are kids growing up with a smartphone as their first computing device; people of our generation have a bias towards thinking of UX and web-apps as desktop-first; when the tooling around API-only Rails apps mature, then template-driven apps will start dying into irrelevance. But, I'm done with it. I'm looking at the next wave of leading edge of innovations for the masses, and it won't be in apps.
- technoweenie 14y ago
  > Rails should be baking in support for creating API only apps, make it easy to shed template-driven code and write UX-agnostic backends. Mobile is driving a need for creating API-only apps, and something like Asset Pipeline is an evolutionary dead-end. This has never been Rails' focus. Let Rails keep doing what it kicks ass at. Sinatra works great for API endpoints. There's probably an opportunity for an API-focused extension to Sinatra. Of course, Grape works too (https://github.com/intridea/grape https://github.com/intridea/grape). The nice thing is that all of these are built on Rack now. GitHub.com runs as a Unicorn rack app that mounts over 30 Sinatra apps and a massive Rails app together. I'm not saying this is an optimal solution, it's just where the app is at in its current evolution. But it is very possible :)
  - VeejayRampay 14y ago
    For things like APIs, Rails has https://github.com/rails-api/rails-api https://github.com/rails-api/rails-api, an excellent project.
    - hosh 14y ago

by cbs 14y ago

sync 14y ago

https://github.com/rails/rails/commit/61b91c4c55bcbd5a2ec85d6e1c67755150653dff https://github.com/rails/rails/commit/61b91c4c55bcbd5a2ec85d...

bguthrie 14y ago
I read that entire comment thread, and maybe my perspective is skewed, but I saw none of the behavior that DHH described there. The discussion was generally polite, the participants were mostly experienced Ruby developers with open-source and community track records, and their objections were well-supported. I have less sympathy now for the original post than I did.
- malandrew 14y ago
  Exactly my thoughts. For example, I know for certain that José Valim is (or at least was last time I checked) a core ruby dev and he's against this change for example. DHH wants to sound like he's talking to trolls and the casual Rails user, but it's clear from the github thread that he's responding to seasoned members of the community as well, which quite frankly is a pretty shitty way to treat people who are known contributors. It's not a community, it's whoever screams loudest. To me that thread and this posts shows that DHH is willingly wearing horse blinders instead of keeping his opinions being open to being amended through thoughtful discussion with others as talented as he is. The biggest problem with this "omakase" attitude is that it's causing Rails developers to miss the boat on many new developments in the state of the art in web app development because legacy is now baked in via opinion. 37Signals hasn't been the forefront of web-app design for a few years now. There are plenty of single page web apps out there that are far more responsible and present a better user experience than tools from 37Signals. Don't get me wrong, they are still decent, but they aren't demonstrative of what is achievable insofar as excellent user experiences are concerned. Maybe this has changed, but I spent a year working on a single page webapp built on Rails and the asset pipeline was excruciatingly painful to debug to get your javascript and other assets handled properly.
  - rrouse 14y ago
    Rails Core. I don't think he actually has Ruby core access like Aaron Patterson (Tenderlove) Actually, I think he's sort of on vacation from Rails for the most part. He's got Elixir to work on. As for the matter at hand, Bundler author Yehuda Katz said that checking in binstubs is actually not a good idea and is not recommended. DHH is going against the grain here.
    - steveklabnik 14y ago
      Aaron and Yehuda are the only two people on both teams, Jose is on Rails Core only. He is also a maintainer of Bundler, as is Terence, who is also on the thread.
  - hosh 14y ago
    "37Signals hasn't been the forefront of web-app design for a few years now." Exactly. This shift isn't just "single page web apps" either. It is a generational shift. When people say "apps" now, it isn't a "web app". For all the thousands of hours of experience DHH says he has, it is stuck in a very narrow view while the rest of the world has moved on. That's ok though. The neat thing about open source is that developers and users do not have to suffer dinosaurs for long. It does mean that I can no longer depend on my Rails skill to put food on the table. Recruiters, desperate for Rails developers, will no longer be knocking on my door. It's a good thing I've been laying in the groundwork for the inevitable irrelevancy of Rails.
    - dasil003 14y ago
      "The rest of the world has moved on"? Good lord man, there's more than one way to skin a cat, and the web is not simply "apps". If you think Rails is irrelevant today than you are practicing fad-driven-development moreso than developing any real insight about the lay of the software land.
      - hosh 14y ago
        Yes. The rest of the world has moved on. If you've characterized what I am saying here as "web is simply apps", then you do not understand what I am saying. I've written this in one other comment, I suppose I will repeat myself: (1) There are more mobile units being sold than personal computers. (2) More importantly, there are 2 year olds whose first experience with a personal computing device will be a smartphone or a tablet. When the start going to school, they will be forced to use a keyboard and will resent it. They will see this as a problem to be solved, and will solve it. This is a generation gap, something between 10 - 18 years from now. (3) Our generation tend to think of the "web" as experienced primarily through a desktop or a laptop. We also like to think that we are at the cutting edge. We are not: these two year olds are. (4) Rails is designed and used by people who experience the "web" through a desktop, and refuses to see where the world will be heading in the following years. There are a lot more. So yes. The direction Rails is going will lead it to its irrelevance.
- cbs 14y ago
  I agree, this is a good example of why I think the complaints about criticism in the open source space need to be put back in check. Some are deserved, but these guys aren't trolls or well-intentioned idiots they're all trying to build the best rails they can. I've been in and witnessed plenty of disagreements in closed source development, they always get much much more heated than this before someone pulled rank.
- KVFinn 14y ago
  >I read that entire comment thread, and maybe my perspective is skewed, but I saw none of the behavior that DHH described there. The discussion was generally polite, the participants were mostly experienced Ruby developers with open-source and community track records, and their objections were well-supported. I have less sympathy now for the original post than I did. My thoughts exactly. I read the DHH post first and thought, "I totally agree. That's why I like rails." But the thread was perfectly civil and the people in it were experienced and well known in the Ruby world.

remi 14y ago

What is this post responding to? This: https://github.com/rails/rails/commit/61b91c4c55bcbd5a2ec85d6e1c67755150653dff https://github.com/rails/rails/commit/61b91c4c55bcbd5a2ec85d...

javajosh 14y ago
Thanks. I'm not really a rails person, so forgive me if I have some questions. Am I correct in interpreting that thread as DHH not wanting to support multiple ruby package managers in the rails codebase? In particular, DHH has 'blessed' rbenv and that commit wants to support rvm? If this is the case, then I have to wonder: why is there any dependency on a package manager at all in the rails codebase? This just seems odd to me, and perhaps is the source of the conflict. E.g. people are fine with 'omakase' frameworks, but these menus typically don't include toolchain dishes. It would be like going into a restaurant and being told that you must use chopsticks, no forks allowed.
- steveklabnik 14y ago
  > In particular, DHH has 'blessed' rbenv and that commit wants to support rvm? No. Two things are going on: 1. 'binstubs' will now be checked into source control. If I use MRI and you use JRuby, they'll start with different things, and therefore, cause conflict. 2. Many of the Ruby version switchers work with '#!/usr/bin/env ruby', but rbenv won't in certain circumstances, so an optimization for it has been built into the framework now. David maintains that if I use MRI and you use JRuby, or if I use rvm and you use rbenv, this is an 'organizational failure.'
  - phene 14y ago
    Because no one ever wants to test their app against multiple versions of Ruby...
  - sstephenson 14y ago
    "Many of the Ruby version switchers work with '#!/usr/bin/env ruby', but rbenv won't in certain circumstances, so an optimization for it has been built into the framework now." Incorrect. It is support for an enhancement that rbenv provides. You often want to invoke an application binstub from another program such as cron, and you want to use the per-project Ruby version specified in the application's root directory. Other version managers require you to spawn a subshell and load the version manager into the shell or otherwise set up the per-project Ruby version environment, then `cd` into the application directory, and finally run the binstub. rbenv requires an environment set-up step too—set `RBENV_DIR` to the application root—but provides a wrapper that eliminates the need for such gymnastics. When you change a binstub's shebang to `#!/usr/bin/env ruby-local-exec` rbenv automatically searches up the binstub's directory tree to find the right Ruby version.

wyuenho 14y ago

I think the analogy broke down somewhere in the upscale restaurant analogy, but let's continue with food joints. In a town where you have only 1 big cafeteria (Rails), a pizza joint (Sinatra) and a few tiny snack stands, if you have friends, you'd probably have to get with the gang and head to the cafeteria for lunch. Now when the head cook decides to not offer disposable utensils anymore because of environmental concerns, but then the large Jewish community complaints about the bowls aren't kosher, then the head cook comes out and post a notice on the entrance that says, "If you can't eat out of the bowls I cleaned, get out of my cafeteria." Ok never mind, analogies can only work up to a point, it's almost 2013 and the world didn't end, chill out Rubyists...

monsterix 14y ago

If you follow the mass of Rails community, you'll get it. Mostly. And perhaps this piece also explains how painful and yet very commonly faced situation (being trolled with expertise) this if for most open source creators/leaders in their line of work. A sort of professional hazard. Sooner or later, this has to get better I am sure.

pretoriusB 14y ago

>What is this post responding to? And who is the target audience? People making comments like yours? E.g >Reading this feels exactly like reading the passive aggressive facebook posts of someone currently in a fight with their boy/girlfriend. We get it, Rails is "opinionated", sorry I guess we're saying "omakase" these days. Who really gives a fuck? Well, a lot of people don't give a fuck, and that's the problem the post addresses. They want Rails to not be opinionated, or to cater to _their_ opinion. >The reason DHH is getting loud complaints is because people feel that they carry a legitimate grievance but also feel no way to voice that opinion (or are trolls). Douchetastic talking down to them like exemplified in this post won't help (and will encourage trolls). I don't see anything bad (sorry, I guess we're saying "douchetastic" these days) about the post. Sounds like a legitimate complain from the creator of a popular framework. I also fail to see how people feel they "carry a legitimate grievance" but at the same time "feel no way to voice that opinion". If they don't participate in the Rails project, then, no, they don't have a "legitimate grievance". They just have a personal grievance. If, on the other hand they do participate, then they have lots of ways to voice their opinions.

cbs 14y ago
I also fail to see how people feel they [...] This is the kind of thinking I was referencing. You don't see it because you're not in their shoes, that doesn't mean it doesn't exist. It's fine and all that people do disagree, that's just the context for my post. If you want someone to see things your way, build a bridge over the gap in their misunderstanding. DHH's blog post its just preaching to the converted. That's why I asked the context and audience. Saying "Rails is omakase" is a lot like saying "git stores a directed acyclic graph of revisions" or "A monad is just a monoid in the category of endofunctors". Almost nobody gets it unless they already get it, and the behavior he seemed to be complaining about was critcism from the unwashed masses. It just doesn't fit. I asked who gives a fuck because what small sliver of his audience is going to both understand what he is trying to express AND take anything new away from the post? My initial read was wrong, because (to stretch his abused metaphor) he is actually talking about the fact his chefs and regular customers really seem to think 2 tsp of spice in the soup would be better than the 1 tsp he is insistent on using. Which makes his post make even less sense. He could have have ditched the flowery prose, meandering critcisms of criticism and just said "This is important to me, I'm pulling rank."

hosh 14y ago

I'm not knee-deep in this specific issue with the binstubs, but I generally agree about the legitimate grievances. The Merb effort and the Rails 3.0 refactor resulted from people unable to voice what they need. We seem to keep repeating history. Asset Pipeline is also the wrong area of innovation to focus on. Rails should be baking in support for creating API only apps, make it easy to shed template-driven code and write UX-agnostic backends. Mobile is driving a need for creating API-only apps, and something like Asset Pipeline is an evolutionary dead-end. There are more smartphone-like devices in the world than personal computers; there are kids growing up with a smartphone as their first computing device; people of our generation have a bias towards thinking of UX and web-apps as desktop-first; when the tooling around API-only Rails apps mature, then template-driven apps will start dying into irrelevance. But, I'm done with it. I'm looking at the next wave of leading edge of innovations for the masses, and it won't be in apps.

technoweenie 14y ago
> Rails should be baking in support for creating API only apps, make it easy to shed template-driven code and write UX-agnostic backends. Mobile is driving a need for creating API-only apps, and something like Asset Pipeline is an evolutionary dead-end. This has never been Rails' focus. Let Rails keep doing what it kicks ass at. Sinatra works great for API endpoints. There's probably an opportunity for an API-focused extension to Sinatra. Of course, Grape works too (https://github.com/intridea/grape https://github.com/intridea/grape). The nice thing is that all of these are built on Rack now. GitHub.com runs as a Unicorn rack app that mounts over 30 Sinatra apps and a massive Rails app together. I'm not saying this is an optimal solution, it's just where the app is at in its current evolution. But it is very possible :)
- VeejayRampay 14y ago
  For things like APIs, Rails has https://github.com/rails-api/rails-api https://github.com/rails-api/rails-api, an excellent project.
  - hosh 14y ago