Rails is omakase
david.heinemeierhansson.com
david.heinemeierhansson.com
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.
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.
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.
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.
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.
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.
At any rate, I don't see mobile-first making Rails irrelevant. Rails has never been cutting edge on front-end development except at the very very beginning when they bundled the brand-new Prototype library. But by the time they hit 1.0, seven years ago or whatever it was, they were already going down dead-end alleys like RJS in an attempt to avoid javascript. Since then Rails hasn't done anything amazing with front-end development, but they've stayed relevant in their own way with the asset pipeline, coffeescript, and generally staying out of your way to implement whatever front-end strategy you like.
Server-side development isn't going anywhere, so I don't see how the shift to mobile makes Rails irrelevant.
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.
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.
This: https://github.com/rails/rails/commit/61b91c4c55bcbd5a2ec85d...
ROFL, DHH has cajones.
@sbartholomew: @dhh the the Rails community has it relatively easy: http://article.gmane.org/gmane.linux.kernel/1414106 … :-)
When you create a new app you'll need to remove a line from the autogenerated .gitignore in order to work the way you expect.
No?
So Linus must be doing something right.
Linus was right, though.
And DHH was wrong.
Not a fan of the way Linus handled that, though he sure did set the tone and expectations for everyone else!
i'm betting he made that mail public very deliberately, as a way of telling the world at large that as kernel dictator he would not tolerate his "staff" treating users like that.
I think a big reason it's on the public list is because it should be. Linux is Linus' baby, he has every right to yell at someone for doing pretty much anything. And in this case, it was deserved. If you're going to break the first commandment of Linux development (don't break userspace), and blame the userspace for breaking, you should be reprimanded.
But that would be way overkilled, here, because we just speak of adding a line to the .gitignore file.
If you don't know git, .gitignore is a file you're expected to edit, you put there anything you don't want to commit in the repository.
So, once again, all the trolling is about changing a default option. Which can be changed back with one line of four characters ("/bin"), in a configuration file. Change to be made only once in the whole life of your application.
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.
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.'
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.
A sort of professional hazard.
Sooner or later, this has to get better I am sure.
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...
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.
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."
Why don't non-contributing users of a software project have a 'legitimate' opinion?
I wonder if this attitude in the late 90s / early 2000s accounts for Linux's level of success as a desktop OS.
Because their opinion gets any legitimacy only by what you paid for it, either by money or work.
Some core developers of OSS are accommodating enough to listen to the opinions of random users, but this only happens if said developers are either:
1) really nice guys than enjoy the interaction and/or pushovers.
2) getting something back from it (i.e they play nice because they also sell support or extra stuff and don't want to alienate potential customers)
Other than those 2 cases, non-contributing users can have whatever "grievances" they want, but it means nothing at all.
And it's also why lots of OSS developers could not give a flying duck is Linux took over the desktop or not. They do it for their own fun and benefit, not for some entity called Linux to gain market share.
I think this confuses validity of opinion with obligation. Certainly nobody from Rails has any obligation to a stranger. But it's another thing to tell Rails users their opinions are invalid.
For the record, I run a reasonably sized OSS project and constant get bombarded for feature requests and free assistance. I'm not a pushover, I don't sell support (although I've been asked to) but I am polite to people and I do believe user's opinion carries some weight, because I want my app to be successful.
I know very little about Rails. It's just that 'Rails is Omakase' reminds me of 'Debian is By Developers for Developers', which didn't work out well for the folks that wanted Debian to take over the world.
This is one of the fundamental problems around many (most?) OSS projects. The elitism that comes with believing you are somehow better than everyone else because you contributed, or started an OSS project.
This attitude also stumps your growth - many people who probably would contribute often end up staying in the shadows, not wanting to look stupid, or offend the sensibilities of the OSS team.
Perhaps a more welcoming attitude might not only make people more supporting of OSS, but might find you some more willing contributors as well?
What are you building open source software for, if not to be used by consumers? If you're building it for some sense of self-aggrandisement, why make it open source in the first place? Just keep it nicely closed, so that only the elite chosen few ever get access to it, and keep out those who's opinions apparently don't matter.
Open source (for many) is a way to pay it forward, and give back. Kinda strange that the very people you're supposedly helping by providing free software don't matter.
What is there NOT to understand?
You release it, because (not all at the same time):
1) You want and value the CONTRIBUTING users (that's your actual software's community).
2) You want it to be used by people but as it bloody is.
3) You want to make money off of it, and think the open source + support/extra services model works.
What I really don't understand are the complaints. Isn't one of the core benefits of open source that you can _change_ the source? If you don't like what DHH is doing, fork rails to your liking. But no, they want it there way AND in the upstream repository.
I'm sorry, but that is just fallacious. There are plenty of people who aren't involved in any given project, but would still be qualified to give decent advice.
Developers should consider random opinions, just not if they conflict with the direction of the software. If a number of users have similar grievances, that is an indicator that something needs to be fixed, or maybe the direction of the software should be changed slightly.
That's if the developer intends the software to be widely-used, of course
It's not about qualifications. It's about the willingness to hear them. I'd rather write my OWN project, MY way, that a better project in some other's terms. That's why people start their own projects after all.
So, the might be qualified, but the open source project creator could not care less about their advice, valid or not.
He might have his own opinions and long term ideas about the project. He didn't start to write software to be a slave to other people's ideas.
If he _wants_ other people's opinions, he'll ask for them.
And if he, like DHH, even posts a lengthy blog post telling them to shove them, then it's clear that he doesn't want them in this particular case.
>That's if the developer intends the software to be widely-used, of course
Developers can also intend for their software to be "widely-used" but only if it's _in their own terms_.
E.g RoR is widely used just fine, for example, despite being "opinionated".
So, "wanting your software to be widely used" does not necessarily imply that you "should consider random opinions".
Obviously you aren't obligated to accomodate anyone when you are doing your own project, even if you are doing your own project and then making it available publicly. But acting like a tiny dictator on a power trip is not the correct behavior if your purpose is to make a tool for public consumption.
If you want to "write your OWN project, YOUR way" you are not making a public tool, you are making a private tool that is available publicly.
Who said you expect or want "a large number of people" in the first place?
You might put your project out there just for the potential valuable contributors to help with the code, not for the end users.
And one can imagine someone creating something unique with no regard for what people are saying, and still expecting them to embrace it. Because he thinks his vision is perfect or better than what exists. Kind of like Ford's quote "If I had asked people what they wanted, I would have given them faster horses".
But the problem with all the above is the absolutism. You don't have to "_never_ listen" as you imply. A project leader might listen to user opinions sometimes, and don't care at all about their opinions on other aspects of his program that he feels adamant about.
E.g it's not like DHH _never_ listens and does whatever he likes "regardless of anyone else's opinions". He only does that for FEW aspects of the project.
>If you want to "write your OWN project, YOUR way" you are not making a public tool, you are making a private tool that is available publicly.
Yes. A lot of projects are like that and people should understand that and respect your decision, instead of bitching about it.
I don't see anything bad (sorry, I guess we're saying "douchetastic" these days) about the post.
"My pet theory is that it feels like meaningful activism in the moment. They haven't really paid much attention to how things are run on a day-to-day basis, but here's an opportunity to paint some signs and get on the barricades. Yeah, I've done my part! I've taken a stand! Down with.. uhm.. Turbolinks? Or was it CoffeeScript we're protesting this week? Or Bundler? Oh fuck it, down with SOMETHING! YEAH!!!"
I mean, you really don't see this as douchey or talking down? How? To me it actually seems impossible to read that and say "Sounds like a legitimate complaint from the creator of a popular framework" unless you already had your mind made up DHH was right no matter what.
This summed it up best in my eyes:
"Reading this feels exactly like reading the passive aggressive facebook posts of someone currently in a fight with their boy/girlfriend. "
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.
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).
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 :)
There are some people trying to revive Rails-API. I have already sent them an email begging them to steal ideas from Intermodal. https://groups.google.com/forum/#!topic/rails-api-core/LoJap...
Maybe they will, maybe they won't. I got a polite brush-off so I doubt they really looked at it, but since I am exiting, whatever.
In writing Intermodal, I've had to muck around with some of the guts of Rails. I've found that Rails 3.0 very much follows the principle of Russian Doll Pattern, but Rails 3.1 onwards started moving away from it. There are baked-in assumptions in the code for a template-driven app. This is where the Rails leadership is focused on.
The Rails 3 architecture is very modular. It was designed as framework to write frameworks, of which a template-driven app is one such framework. I have written a different framework specifically for just an app focused on SASS that has an abundance of CRUD operations.
However, when Rails 3.1 started transitioning into Rails 3.2, the assumption that Rails is specific for a template-driven app started being baked deeper into it. It was moving away from the "Russian Doll Pattern" that was so useful for me.
I've never built a SOAP API in Ruby, so maybe Rails wouldn't work with that very well. XML-RPC might also be a little tough, but I honestly can't think of any significant difference between a "traditional web app" and a RESTful API. They're a perfect example of code reuse in MVC (or Model2 if you want to be pedantic).
And more particularly since you seem to know about this, what other option would you favor?
It means he's a node troll. They take a shot at the dominant frameworks any chance they can get. Node trolls have reached the level of obnoxious arrogance that early Rails developers were once mocked for. Don't feed the trolls.
Sure, Sinatra doesn't come with ActiveRecord like Rails does, but you can use ActiveRecord on its own with Sinatra -- or use Sequel or DataMapper or whatever other ORM [or non-ORM persistence solution] you prefer -- with Sinatra, you don't have to code your own by hand. Similarly with other components.
Right now, I can create a rails app that doesn't use templates at all. I can start with a basic rails 4 install and quickly prototype an API that communicates through JSON or any other format I can think of. I can leverage handlebars and ember.js if I want to go that route, or I can stick with dumb old 'templates' to display my data. When you start coding ruby on rails you quickly realize that 'template' is just a word and that you are free to do literally anything you can think of, easily.
>> people of our generation have a bias towards thinking of UX and web-apps as desktop-first
Let us assume this is absolutely true. Why does rails keep you from writing code that honors this bias? Rails gives you abstractions you can use to decouple. If I want local data persistence perhaps I'll need support from other libraries--but only if I'm too shy to take a shot at writing a tool myself. I think you're on to something with the 'desktop-first' remark. We do need to be able to store data browser-side. We do need to address performance issues--especially as it relates to decoupling server-side data logic and application data logic. Rails is a very good tool for supporting solutions to these types of problems and packaging them in easy to implement applications.
>> But, I'm done with it. I'm looking at the next wave of leading edge of innovations for the masses..........
Obviously rails is useless if you don't want to make applications, but otherwise you can really do anything and it's not actually hard to configure rails.
I used to think that david hh and many other experts in the community were mean. Then I realized they have to deal with people all the time; not the 'grievances', but the attitudes. There are many trolls and one cannot be too careful.
This change 'breaks every single new Rails app on Heroku that uses rbenv', in the words of Heroku's Ruby platform lead. It is not a trivial change. This is David going against the wishes of every other maintainer of every other piece of software Rails works with, as well as other Rails maintainers, and then painting their comments as 'nerd rage' and 'organizational failures.'
Ugh.
After lots of discussions in Campfire, we're working through all these conceptual issues as a team, and steps are being taken so that EVERYONE is happy with what happens with regards to this feature.
Every time DHH goes off on one of his little rants and angers a lot of people in the process it's not just those people that get affected, and not just emotionally either. These Ruby [on Rails] dramas have a real-world impact on the rest of us, the hundreds of thousands of us that use Rails every day to make a living. It affects us in that it makes us all look like unprofessional schoolground children. Rails already has a stigma of "hipster" developers that tend to be up their own asses, and episodes like this really don't help our image. Especially not when the global developer community is not as massive as you'd like to believe, especially when people talk - to other developers, to potential and existing clients that then get per-conceptions of unprofessionalism, and to newbie developers that shy away and look into alternative languages and frameworks because they don't want to be associated with this wankery.
DHH's post, particularly the second paragraph, seriously comes across as if the core "team of chefs" is doing us all a massive favour and if we want to keep benefiting from the really beautiful thing that Rails is then we should shut the fuck up and take what we're given. Well this isn't Pyongyang (if we're going to play with metaphors) and DHH is not our dear leader. Yes of course I, and all the other Rails developers and immensely grateful for the framework's existence, but it's OSS now. There are thousands of contributors and so many more times commits than that to the projects since it did become OSS.
The community either needs a revolution or a fork because this downward spiral of foul air is just going to continue spreading and affecting us all. I'm sure if a couple of well respected individuals decided to take that route, a whole lot of people would back them up - I know I sure as hell would.
Pawel - a Rails developer.
I'd like people adding those kinds of claims to also give an estimate of how much they have contributed to the project.
I.e.
John S., Linux Kernel developer, contributed maybe 10 lines of code, or 0.0001% of the kernel source
or:
L. Torvalds, Linux Kernel developer, wrote the kernel code from scratch, that's my name on the project, biatches
Else, this "a Rails developers" signature tells us we should give extra credit to your opinion, but we don't know how much compared to DHH.
I don't mean it about you, Pawel, or your comment (I don't follow Rails that much anyway the last 2-3 years), I mean it in general.
Either way, you're looking at a brag-fest as people try to one-up each other. That can't be productive. I don't think any good would come of this.
Technical: DHH is wrong, plain and simple. No amount of defending the decision makes it right.
Community Management: DHH, while not as abrasive as Linus (another thread here linked to a kernel thread), IMO, DHH is (much) worse than Linus. Linus is abrasive and swears and yells. DHH is dismissive and condescending. DHH thinks he has better opinions, more depth of experience, smarter, more insight and generally "gets it" more than everyone around him, including the other maintainers.
For instance, the GNOME3 guys and the design direction they are taking. No matter what, they can't be "wrong" (whatever that means in this case) in that opinion?
I get that objective right/wrong can get complex and murky rather rapidly, though I feel with experience people can actually make judgement calls on these. And in this case, checking in binary assets is wrong, from experience. It causes many more problems that it solves. So, DHH is "wrong" in this instance even if he himself feels that it is the way to go.
[1] - "wrong" might have been an improper word to use, though for the sake of consistency, I'm going to continue ;)
I find this a bit disappointing because in any other situation, feedback and constructive criticism is welcome and typically acted on, even if you weren't involved in the production process. You might not be listened to, but you won't be silenced by your peers.
To use the silly analogy in the OP: you don't need to be a chef to say the food tastes like shit.
Well, he does. He's been doing Rails for literally 10 years now, so, strictly speaking, he is the most qualified opinion on the world in the topic of "Rails the application framework".
I agree that he sound condescending, but I understand his viewpoint. He's pushed a lot of changes through rails that at the time felt a lot like this one - a very vocal subset of the community got up and screamed bloody murder, and nowadays everyone realized it was the right idea.
Anyway, "DHH is wrong, no possible way he's right" isn't really a productive attitude to take in this discussion. He's been doing this for 10 years. Maybe you don't agree entirely, but DHH always has very good reasons for his opinions.
In my personal experience, oftentimes the people who have been around the longest are somewhat incapable of completely understanding an outside or new perspective. The fact that they often dismiss it because "I've been doing this for 10 years, I'm the most qualified" is a large part of that reason.
Also, I don’t understand why the article was written, every software developer makes their own decisions that not everyone will like — isn’t that obvious?
Same problem here. So much for the master chef with a decade of experience...
Have you seen the design for YCombinator.com? 1998 called and it wants its Arial font, <table> and <center> tags back. By your logic, YCombinator is worthless for helping Web startups launch.
Also, YC's crappy HTML doesn't make the site less useful for visitors. This blog's poor unicode support does.
He's just trying to explain it to the masses. Maybe he's hoping that a few borderline whiners will catch a clue and decide to put up or shut up... maybe he's just venting.
Regardless, I sympathize with him. I love rails. I love where his leadership has taken the framework steadily over the years.
They never shut up. :)
Given the size and pop culture around Rails I think he gets to deal with more stuff than the usual maintainer. I mean, there are people who actively celebrate when there is a security issue in Rails. When github was hacked due to a foolish mistake people where celebrating! This is the sort of thing that keeps me from joining any Framework community. Fanboyism.
Just so you know, those 'borderline whiners' are mostly other members of the core team.
In general, this is aligned with the author way of thinking and it also applies to stuff like languages (think C vs. Java) or even window/desktop environments (Fluxbox vs. Gnome).
[1]: https://github.com/rspec/rspec-rails [2]: https://github.com/cucumber/cucumber-rails [3]: https://github.com/thoughtbot/shoulda [4]: https://github.com/thoughtbot/factory_girl [5]: https://github.com/nulldb/nulldb [6]: https://github.com/notahat/machinist [7]: https://github.com/haml/haml [8]: https://github.com/josh/mustache-rails [9]: https://github.com/stonean/slim [10]: https://github.com/brasten/sequel-rails [11]: https://github.com/datamapper/dm-rails [12]: http://mongomapper.com/documentation/getting-started/rails.h...
[1] - https://github.com/RailsApps/rails-composer/#your-options
You can tell Padrino what you want during the creation of a new project.
You can tell Rails what you want immediately after the creation of a new project. Rails simply saves you time by having sane defaults. Convention over configuration at its best.
It's imo an anti-pattern to have developers working on the same app use different
tool chains like that. If your organization can't decide on rvm vs rbenv, then
you have deeper problems than what binstubs are checked in to your repository.
Second, if you are unable to use the same Ruby manager in production and development,
I feel bad for you. We rely on .rbenv-version to ensure that the same Ruby point
release is used in both places.
These aren't the cut-and-dry truths that DHH is presenting, although I can see the logic in them, and I think this problem has only happened because of binstubs, which are a really bad idea.
Not aimed at anyone in particular.
Thats why Im always wary of programmers who join into a framework too quickly.
I use Rails, and its a nice framework. But I'm not a fanboy. Its just another tool for the job. Just like Django, Symfony, Flask, Sinatra, Laravel, Slim, etc.
Now, I'm not getting into a pissing match with you. We are arguiing the same point, just from two different perspectives. I do agree that Rails 4 is mature enough. But the culture is not. And that's what keeps Rails from replacing shitty Enterprise frameworks. A shame because Ruby is fun to write and very powerful.
"Rails is not that. Rails is omakase. A team of chefs picked out the ingredients, designed the APIs, and arranged the order of consumption on your behalf according to their idea of what would make for a tasty full-stack framework. The menu can be both personal and quirky. It isn't designed to appeal to the taste of everyone, everywhere."
The folks who like omakase are of course free to enjoy Rails. More power to them. I personally learn more, and enjoy more, when I get to assemble a different menu for each project -- a menu suited to the project.
If anything, Rails poisons things in the Ruby community because the monolithic approach of the biggest framework in the community simply works against small libraries with small interfaces that are very compatible and remixable.
In fact, one of the best developments in the Ruby community lately has been the increase of other frameworks like grape, padrino, rack, sinatra, etc. I know some of these have been around for a long time, but it wasn't until Rails started getting long in the tooth that they started getting more and more attention.
What part of Rails is… monolithic? I don't understand this complaint. Rails 3 these days is pretty modular.
For the same reason I can't stand Sinatra et al; two-to-four hours into most projects I find myself saying "Oh yeah, I could really use an ORM, and some route helpers, and a view layer would be nice and how do I get this testing framework to play nice?" and before you know it you've wasted more time trying to cobble something together.
Another big difference to me is coupling: In theory Rails might be modular, but because of what Rails is, while you may be free to tear out ActiveRecord for example, it takes very little before you're knee deep in dealing with shit from 3rd party code that assumes the default stack. If you can't rely on all the Rails plugins and extensions, and you want to replace a major component of Rails, then there's suddenly a lot less reason to use it at all.
ORM? Hibernate or JPA2 can be run anywhere: inside or outside container (i.e.: desktop app, web-app, or simply daemon/service)
DI? Spring or CDI
Unit-test? JUnit or TestNG or others
Mocking? EasyMock, Mockito
Message Queue? Pick one out there
Templating? JSP, JSF(ish), Velocity, FreeMarker.
RESTful? Restlet, Jersey
Everybody plays well with one and the other.
Even the cutting edge of Ruby is now on the JVM, as Rubyists see a need for threads and find jRuby the most convenient way to move forward: http://tonyarcieri.com/2012-the-year-rubyists-learned-to-sto...
Rails took off in 2004 as a rebellion against the overly-heavy Java frameworks like Struts. But now what good ideas Rails offered have been incorporated into languages that run on the JVM, and a lot of innovation, in particular with concurrency, is happening on the JVM, and some of those things are areas where Ruby (other than JRuby) is weak.
Trend #1: modular components
Trend #2: platform (performance optimization as well)
What you described falls into #2 while what I refer to falls into #1.
If you are starting your own startup then clearly you want to pick the individual libraries that best suit your problem. You have to deal with them for a long time and the payoff from a small improvement gets large. You write a little glue code and you are good to go.
If you are working on a large number of CRUD sites all the time then you want a stable set of libraries that cover most of the problems you will encounter and having scaffolding and other glue code replacing mechanisms is preferrable, even if they aren't as flexible or efficient or elegant as could have been done manually. When you write the same glue code over and over again you end up automating it, and generalizations have tradeoffs.
There is really no comparison between the framework needs of single site developers and developers working for a web agency or who are working on many sites or spinning up a few new sites a month.
The conventions being enforced result in existing Rails code being easier to penetrate for new team members and more maintainable over time than was the case pre-Rails for web apps.
Rails is stronger for it.
The reason the analogy is off: when was the last time you went into a restaurant and said, "i'm going to base my work/livelihood on this menu"? Never. Sometimes when I go for a meal I know what I want and I order that. Often I'm looking for an experience and I'll ask, "If the chef were going to die tomorrow what would they eat tonight?". Omakase is a formalized way to see what the chef recommends at that moment in time.
Rails is not the same as me going into a restaurant looking for a great experience at that moment. I might have a mind-blowing meal but I'm not going to base my livelihood on it.
I'm not saying that DHH or Rails are flaky. I am saying that comparing a serious tool for serious work to omakase/the whims of the chef does Rails a disservice.
Even if you've staked your career on Rails, it's important to realize it's your choice, but his framework.
<meta charset="utf-8" />
In this case, this drama was triggered by... a one-line change to the default gitignore file.
I switched for a little while and ran into all sorts of path issues. As I was working through my issues, I noticed there seemed to be a lot of attitude around it and what I thought was unwarranted criticism of rvm. Soured me, and I haven't bothered with it since.
I'm sure it works great for some people though.
In the case of my example you could swap out the /delivery/web/app.rb or delivery/api/app.rb out for rails no problem. You wouldn't need to change any of the code in /app or /external to do so whatsoever.
Just because DHH thinks you should write your code one way and you don't agree doesn't mean you have to throw rails away entirely to have a different or better structure. Rails might be opinionated, but that's just like their opinion man.
People are way too into Rails...
We had this problem at work: a Sinatra app that had pieces and pieces of ActiveSupport bolted on, and it got to the stage where we needed a beefier database than Redis before the CTO eventually generated a new rails app and transplanted the Sinatra app on top of it.
It's all well and good saying "use Sinatra", but when you get to the stage where you're adding ActiveRecord because it's the most mature ORM out there, it's usually late enough in the game that you're actually writing a poor excuse for a Rails application.
[1]: http://www.asquera.de/opensource/2012/10/22/the-rails-monoth...
My point is - some of us are trying to build websites and get work done and were attracted to a full-stack framework so we didn't have to keep reinventing the wheel and so we can benefit from an ecosystem.
It's quite liberating to have things have a default naming convention and location. I can imagine it makes working on teams exceedingly easier other alternatives.
But an empty MVC4 application makes no assumptions about frameworks (JS, CSS, ORM, Tests, View engine, etc.), and yet it generates criticism that there isn't enough dependencies built-in. It seems MS can't find the middle ground.
I agree that it fragments open source projects (you won't find any two MVC4 apps that follow the same methodology), but I find the flexibility for an internal team to be more desirable than Rails.
Also, the analogy does not hold well because at a sushi bar, the one who orders is the end consumer. Rails is a tool for developers so a more accurate metaphor would be I am the chef, my customer orders omakase and Rails supplies all my tools and ingredients. If those tools and ingredients are what I need to make my customer happy, then great. If not, then I'd prefer to throw them away and do it right instead of dogmatically defending my framework like it's a religion.
That does not mean that many (mostly due to Dunning-Kruger) will claim to be masters and that even more will rush to the charlatans hoping for a magic spell that makes complex, new and continuously emerging technology easy without the need to learn or practice.
That's the one reason I wouldn't recommend each dev using a different package manager.
However, if we follow that logic, only experienced devs will venture to choose a different package manager. Which implies that he/she would be knowledgeable enough to edit his own .gitignore and whatnot.
Furthermore, ActiveRecord is much less tied into Rails core than the Django ORM is to Django.[1]
[1] - Yes, you technically can not use the ORM, but then you don't get the Django Admin, which, frankly, is the only thing Django has over many other Python web frameworks.
Rails doens't have "plug-in apps" in the same way as Django, because Rails doesn't have "apps" at all, apps are what you build with Rails, not part of Rails.
(And Rails does sort of support plug-in apps in the form of 'engine gems' -- but there are no conventions for how different engines interact with each other, because Rails doesn't establish conventions for end-user UI, it consistently does not go to as high a level of abstraction as Django. This has plusses and minuses of course).
I can remember the Rails HTML helpers with Javascript mixed in and the framework relying upon Prototype.
On the other hand I can't find any example of Django forcing UI stuff onto the developer other than maybe the widget/forms rendering methods.
Really, like what? I don't consider the admin to be end-user and even if it is, its highly customizable.
Django is really more modular and customizable than people give it credit for. Perhaps, because it works one way "out of the box" and you have to look deeper and learn it to have it work some other way.
what?
Contrary to Rails, Django never forced front-end solutions upon the user, and every suggestion on the dev list to do so is dismissed, which I'm in particular very happy with. The exception is admin, being a full-featured out of the box solution, but even there are some occasional talks about decoupling the orm/forms/admin and provide generic APIs.
What makes me personally prefer Django is the approach the developers take, which when compared to Rails is more conservative. If something is to change in Django, the old way generally gets marked as deprecated a few version prior, and changes are introduced to have limited impact. I mean, even when Django changed the base directory structure of a new project they made sure that old code with the old directory structure would still work in most cases.
For the new url template syntax in 1.5 (they changed it to fix an inconsistency with other tags, as well as to support a new use case to allow variables as an argument), a from-future fix was introduced early on (in 1.3 even!) so that people with slow moving projects could safely ignore the problem until they could get around to fixing it, while people with fast moving projects can adopt the new "correct" behavior early.
Not to say incremental upgrades are always painless, but the pain is limited and well documented. Things that can be introduced on the users schedule (like the new url template syntax), are.
In some ways, that could end up being a disservice. Django can't move as fast or change as much as Rails can. But really, that's what you signed up for. If you bought into Rails and now you're mad that the floor is moving, you really should've considered that in the first place. Likewise, if you bought into Django and you wonder why it doesn't have ZOMG coffeescript (or whatever) as a default, then you probably should have considered that. Personally, I'm okay with Django core moving slowly, because I can augment it with reusable apps that are able to move a lot more quickly.
You also don't see douchey posts from the Django developers. They generally show respect for competing frameworks, and aren't afraid to be critical of their own. There's a lot to like here.
DHH is right, there is no reason to complain.
I think it sums up some kind of state of mind on the internet today. it's not just about software or programming.