4 ms·

You're building CRUD apps. The conventions work and are extensible for teams of 1, 10, 100 and 1000s. You are not special and neither is your product. Companies

You're building CRUD apps. The conventions work and are extensible for teams of 1, 10, 100 and 1000s. You are not special and neither is your product. Companies making millions or billions of dollars have used this framework successfully. This level of bike-shedding is what makes conventions necessary especially when dealing with the typical hyper-pedantic software developer. Just the thought of having to debate where to put every file in a project or having to invent a new folder structure for every app we build fills me with a bizarre mixture of boredom and rage. As with everything in life the people that whine about the medicine the most are the ones that make it necessary.

berkes 3y ago
> You're building CRUD apps. No. "we" are not.
- parthdesai 3y ago
  > Domain. Team. Project Planning. Combine any of them and the projects demand different things, but with Rails you are out of luck hmm, sounds like this rails app that one might have not heard bout. You should check it out. Think it's called Basecamp
  - emmet 3y ago
    help I’ve just witnessed a murder
    - PH95VuimJjqBqy 3y ago
      on the off chance someone doesn't understand the subtext here. BaseCamp is DHH's company's product. DHH is the creator of Ruby on Rails. He literally create RoR to build BaseCamp, which is exactly the type of software the other poster is claiming is problematic for RoR. DHH is on record as having said RoR was evolved organically from the early code of BaseCamp.
      - berkes 3y ago
        > which is exactly the type of software the other poster is claiming is problematic for RoR. I wasn't. I specifically did not mention any concrete examples. I presume parent misread it as "for project management rails is unsuited" which, indeed it's not: specifically because PM is very much CRUD and has relatively little and/or relatively simple business logic (It's not for nothing that the hello-world of nearly all frameworks around CRUD are "TODO lists", the simplest form of PM). What I tried to say, is that your domain, your team, your timing, your specific planning and your kind of project and any combination thereof has different needs. A setup, architecture, framework, fits one or a few of these perfect. But never all of the combinations of them. Nor over time (today you are a one-man-shop, tomorrow a team of 6. Today you build a full-stack web, tomorrow you need APIs for integration. Today you build a CRUD app for some medication journal, tomorrow it pivots into a complex tool for medical research.)
        PH95VuimJjqBqy 3y ago
        then you worded it badly. > Domain. Team. Project Planning. Combine any of them and the projects demand different things, but with Rails you are out of luck There's no reasonable interpretation of that in which BaseCamp doesn't fall into the list of things that you feel RoR is poor at.
jupp0r 3y ago
Your model of companies using Rails with 1000s of engineers is almost comically naive. Look at what Shopify and Github have to do to make Rails work for them. Also look at the non Ruby code engineers there are writing and ask yourself why they might be doing it. Rails is not a religion. It can be good at what it does without having to go on a crusade when people point out its substantial limitations.
- mosselman 3y ago
  If your reverse your comment you could say “only when your reach 100s of developers will you need to start changing things a bit.” Sounds good to me. Most companies never reach that scale and if they do, I think investing into some extras will be well worth it. Tobi looks pretty chill about it in the documentary.
  - jupp0r 3y ago
    Totally, Rails is a great tool. So is my gunsmith hammer. I can like it for what it does without arguing it's the best thing in the world for cutting wood or joining two pieces of metal together.
- gv83 3y ago
  you're seriously convinced they would have had no problems if they chose something else? every codebase that lasts that long and is used that much is going to face very hard challenges as it scales and meets new landmarks. the maintainable codebase from day 1 to day 5000 is (mostly) a myth. yeah maybe some other stack could have faced different tradeoffs. I'm also curious about YOUR choice of stack at this point.
  - jupp0r 3y ago
    I never said that some other stack wouldn't have problems. My point was that Rails is great at some problems and awful at others. No idea how this can be controversial at all. My impression seems to be that there is a group of fanboys that are not able to have any intelligent conversation on what their favorite tool is good for and what it's not good for. In my day job I use mostly Rails. My team is starting to rewrite some of the services we own in Golang because Rails is no longer a good fit for the problems and scale we use it for. Rails was great to get started fast. Nothing wrong with using a press instead of a hammer at some point, they are just tools.
breakfastduck 3y ago
This is part of the problem with your claim - many of us are not building CRUD apps, we are building complex enterprise software and there are unique challenges to solve.
- ativzzz 3y ago
  At the end of the day, all programming is CRUD at various levels of abstraction. You read some data, and then create/update/delete various forms of related data in various locations, like your DBMS or maybe a file or your GPU's VRAM Rails provides a way to approach CRUD via MVC. Controllers are your API. Models are the connection to the Database. Views are what the controllers render. If your app doesn't do these 3 things - API, Database, and representation of your API - you don't need rails (I bet you do those three things). Other than that, you're free to layer on whatever architecture via ruby that you want on top of these basic rails constructs. If you don't like it, again don't use rails. It's opinionated for a reason
- butlike 3y ago
  Then I think the focus should be on the API. At enterprise level, the API becomes the language, and the frameworks (and even departments to an extent) become the functions/methods. Business = program Company = class (business can be a conglomerate) Department = method frameworks = implementation details
butlike 3y ago
I don't think it's necessarily bike shedding, and actually a lot of the sentiments resonated with me. Rails is a tool that does a tool's job. It's nice to know a hammer does hammer things when you're expecting it. If you need a level, maybe use a different tool. I think the main issue is everyone expecting it to be "one-size fits all." It was never meant to be that, really

berkes 3y ago

> You're building CRUD apps. No. "we" are not.

parthdesai 3y ago
> Domain. Team. Project Planning. Combine any of them and the projects demand different things, but with Rails you are out of luck hmm, sounds like this rails app that one might have not heard bout. You should check it out. Think it's called Basecamp
- emmet 3y ago
  help I’ve just witnessed a murder
  - PH95VuimJjqBqy 3y ago
    on the off chance someone doesn't understand the subtext here. BaseCamp is DHH's company's product. DHH is the creator of Ruby on Rails. He literally create RoR to build BaseCamp, which is exactly the type of software the other poster is claiming is problematic for RoR. DHH is on record as having said RoR was evolved organically from the early code of BaseCamp.
    - berkes 3y ago
      > which is exactly the type of software the other poster is claiming is problematic for RoR. I wasn't. I specifically did not mention any concrete examples. I presume parent misread it as "for project management rails is unsuited" which, indeed it's not: specifically because PM is very much CRUD and has relatively little and/or relatively simple business logic (It's not for nothing that the hello-world of nearly all frameworks around CRUD are "TODO lists", the simplest form of PM). What I tried to say, is that your domain, your team, your timing, your specific planning and your kind of project and any combination thereof has different needs. A setup, architecture, framework, fits one or a few of these perfect. But never all of the combinations of them. Nor over time (today you are a one-man-shop, tomorrow a team of 6. Today you build a full-stack web, tomorrow you need APIs for integration. Today you build a CRUD app for some medication journal, tomorrow it pivots into a complex tool for medical research.)
      - PH95VuimJjqBqy 3y ago
        then you worded it badly. > Domain. Team. Project Planning. Combine any of them and the projects demand different things, but with Rails you are out of luck There's no reasonable interpretation of that in which BaseCamp doesn't fall into the list of things that you feel RoR is poor at.

jupp0r 3y ago

Your model of companies using Rails with 1000s of engineers is almost comically naive. Look at what Shopify and Github have to do to make Rails work for them. Also look at the non Ruby code engineers there are writing and ask yourself why they might be doing it. Rails is not a religion. It can be good at what it does without having to go on a crusade when people point out its substantial limitations.

mosselman 3y ago
If your reverse your comment you could say “only when your reach 100s of developers will you need to start changing things a bit.” Sounds good to me. Most companies never reach that scale and if they do, I think investing into some extras will be well worth it. Tobi looks pretty chill about it in the documentary.
- jupp0r 3y ago
  Totally, Rails is a great tool. So is my gunsmith hammer. I can like it for what it does without arguing it's the best thing in the world for cutting wood or joining two pieces of metal together.
gv83 3y ago
you're seriously convinced they would have had no problems if they chose something else? every codebase that lasts that long and is used that much is going to face very hard challenges as it scales and meets new landmarks. the maintainable codebase from day 1 to day 5000 is (mostly) a myth. yeah maybe some other stack could have faced different tradeoffs. I'm also curious about YOUR choice of stack at this point.
- jupp0r 3y ago
  I never said that some other stack wouldn't have problems. My point was that Rails is great at some problems and awful at others. No idea how this can be controversial at all. My impression seems to be that there is a group of fanboys that are not able to have any intelligent conversation on what their favorite tool is good for and what it's not good for. In my day job I use mostly Rails. My team is starting to rewrite some of the services we own in Golang because Rails is no longer a good fit for the problems and scale we use it for. Rails was great to get started fast. Nothing wrong with using a press instead of a hammer at some point, they are just tools.

breakfastduck 3y ago

This is part of the problem with your claim - many of us are not building CRUD apps, we are building complex enterprise software and there are unique challenges to solve.

ativzzz 3y ago
At the end of the day, all programming is CRUD at various levels of abstraction. You read some data, and then create/update/delete various forms of related data in various locations, like your DBMS or maybe a file or your GPU's VRAM Rails provides a way to approach CRUD via MVC. Controllers are your API. Models are the connection to the Database. Views are what the controllers render. If your app doesn't do these 3 things - API, Database, and representation of your API - you don't need rails (I bet you do those three things). Other than that, you're free to layer on whatever architecture via ruby that you want on top of these basic rails constructs. If you don't like it, again don't use rails. It's opinionated for a reason
butlike 3y ago
Then I think the focus should be on the API. At enterprise level, the API becomes the language, and the frameworks (and even departments to an extent) become the functions/methods. Business = program Company = class (business can be a conglomerate) Department = method frameworks = implementation details

butlike 3y ago

I don't think it's necessarily bike shedding, and actually a lot of the sentiments resonated with me. Rails is a tool that does a tool's job. It's nice to know a hammer does hammer things when you're expecting it. If you need a level, maybe use a different tool. I think the main issue is everyone expecting it to be "one-size fits all." It was never meant to be that, really