Sounds like from the comments that Rails is gaining a little bit more popularity again instead of being known as the boring robust framework
Ruby on Rails: The Documentary [video]
21–30 of 248 posts
Re: Ruby on Rails: The Documentary [video]
#22Really amazing documentary! Been using Rails for the last couple of years and it’s just so productive for a small team to build product and follow well established patterns in building business logic.
I’d recommend to those interested in seeing how a real Rails app is structured to look at the Jumpstart codebase as it’s a great resource on how to structure things
As an alternative Bullet Train is pretty good, even though it adds a lot of bespoke libraries that aren’t the “Rails way”
Re: Ruby on Rails: The Documentary [video]
#23Two figures that inspired me were missing, why the lucky stiff and Ryan Bates from railcasts fame. Otherwise great docu with DHH "f*uk you" slide which does give an insight into successful open source projects.
I agree with that, I would also have liked to have seen Tenderlove in it.
Re: Ruby on Rails: The Documentary [video]
#24I saw it and I don't think it make it any justice, Ruby on Rails changed the paradigm of creating web applications with routes instead of files (like PHP, JSP and Webforms did) with the MVC pattern that now is present in every respectable web framework and the documentary doesn't tell that. It was enjoyable though.
Re: Ruby on Rails: The Documentary [video]
#25> if you open up any Rails application, it looks basically the same in structure whether it is the biggest Rails app there is or a new one. I used to love this, untill I started to hate it. I am convinced this is a major contributor to why so many Rails apps turn into an unmaintainable mess over years. Who measures onboarding in hours? It's fine if it takes a day or two to understand the domain. And the framework. An…
You're bike shedding [0].
Rails/DHH took already established design patterns and made strong opinions into a convention on the folder hierarchy of where you store your code. You can change that hierarchy, its not set in stone. It will require a lot of change. I've been on teams and it isn't just on-boarding time, its countless hours trying to find code written by someone no longer there that had their own layout of where files should go. Without conventions, people will run amok with a file structure. Multiply that by the number of developers on the team with attrition and different view points on organizing files and it can be a giant mess after a number of years. Its all a waste of time and has nothing to do with the quality of the code, what domain the application is in or anything really.
If you love Ruby there are other libraries out there like Sinatra [1] that don't have the conventions of Rails.
Re: Ruby on Rails: The Documentary [video]
#26I had a lot of fun watching this documentary. The one person framework really comes out in the personal story of Toby from Shopify. "From Hello World to IPO". What I also loved is that he mentioned that if you open up any Rails application, it looks basically the same in structure whether it is the biggest Rails app there is or a new one. Sure that can be true for many apps, but in a world of, for example, APIs and f…
What's funny to me is I have been doing Rails for 15 years, even wrote books on it, and I just thought Tobi was a guy who made a lot of popular Rails stuff. Didn't realize he was the founder and worth 5.5 billion dollars lol
Re: Ruby on Rails: The Documentary [video]
#27I had a lot of fun watching this documentary. The one person framework really comes out in the personal story of Toby from Shopify. "From Hello World to IPO". What I also loved is that he mentioned that if you open up any Rails application, it looks basically the same in structure whether it is the biggest Rails app there is or a new one. Sure that can be true for many apps, but in a world of, for example, APIs and f…
[dead]
Re: Ruby on Rails: The Documentary [video]
#28> if you open up any Rails application, it looks basically the same in structure whether it is the biggest Rails app there is or a new one. I used to love this, untill I started to hate it. I am convinced this is a major contributor to why so many Rails apps turn into an unmaintainable mess over years. Who measures onboarding in hours? It's fine if it takes a day or two to understand the domain. And the framework. An…
i’m preparing a talk for either railsconf or railsworld that puts this question/concern to the community. two times i have deviated from the standard apps/{models,controllers,views} layout and i have profited massively, especially in terms of conceptual integrity and abstraction. all my code lives in app/lib under domain-specific directories. this includes the models. the only part worth separating is the web router and controllers. i have achieved separation between my app and the web parts that aren’t offered by default by rails. i’m hoping to share my experience, for the community’s consideration.
Re: Ruby on Rails: The Documentary [video]
#29One of my biggest mistakes as a dev was not really learning Rails until 2015. I just didn’t know how much faster building web apps could be.
Yeah me too. I am still sad thinking about the number of hours I spend messing with python environments and versions because I was told it was the “quick and easy” option for solving this or that small problem.* Also worth mentioning Michael Hart’s intro course, which is a really shockingly well done way to ramp up from absolute zero, even for someone with very little code experience. * Which, in fairness, it mostly…
Were you using Django?
Re: Ruby on Rails: The Documentary [video]
#30> if you open up any Rails application, it looks basically the same in structure whether it is the biggest Rails app there is or a new one. I used to love this, untill I started to hate it. I am convinced this is a major contributor to why so many Rails apps turn into an unmaintainable mess over years. Who measures onboarding in hours? It's fine if it takes a day or two to understand the domain. And the framework. An…
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.