1–8 of 8 posts
What kind of work is done to diffrentiate from that? I'm curious what the more advanced workflows/projects look like. What work is airbnb or github doing?
it seems like a logarithm where you get a lot of results quickly and the rest is incremental improvements to get slightly better, or is it another pattern?
Indeed Rails is extremely good for prototyping, but building an actual MVP (let alone a product) takes a lot more than that + there are more stages that have been ommited for very good reasons from that video-tutorial.
As you grow, you do less of "belongs_to" and "has_many" and you do way more Ruby and way more Glue code that will work with all the models in the system and generate something for the user.
Scaling is a big issue, you constantly work around "best practices" that don't scale. (active-model-serialization for example) in favor of more fine-grained control over your models and data flow.
These days, the work is about 45-45-10, 45% you do APIs, 45% you do JS/React/etc... and 10% you do "Rails" (likely even less).
When the project grows, the monolithic nature of it starts to be a very big pain in the ass. We are moving more and more into services that do one thing well and not automatically include everything into the project.
Hope this answers your question
Tips: Forget Rails, Learn Ruby, HTTP, how things flow from the request to the response. Adopt universal best practices.
https://www.trip.com is 90% Rails I'd say. Everything you see on the surface is Rails. As you grow, you do less of "belongs_to" and "has_many" and you do way more Ruby and way more Glue code that will work with all the models in the system and generate something for the user. Scaling is a big issue, you constantly work around "best practices" that don't scale. (active-model-serialization for example) in favor of more…
https://www.trip.com is 90% Rails I'd say. Everything you see on the surface is Rails. As you grow, you do less of "belongs_to" and "has_many" and you do way more Ruby and way more Glue code that will work with all the models in the system and generate something for the user. Scaling is a big issue, you constantly work around "best practices" that don't scale. (active-model-serialization for example) in favor of more…
"Forget Rails, Learn Ruby" I disagree, Ruby is mostly nothing without Rails. It's a great language, but otherwise has little usage when it comes down to getting a job.
Rails is a framework. You are not a Rails engineer, you are a Ruby engineer.
I see this a lot with people that started with Rails, they don't understand the basics of Ruby and it's capabilities, they look for "Array comparison Rails" etc...
https://www.trip.com is 90% Rails I'd say. Everything you see on the surface is Rails. As you grow, you do less of "belongs_to" and "has_many" and you do way more Ruby and way more Glue code that will work with all the models in the system and generate something for the user. Scaling is a big issue, you constantly work around "best practices" that don't scale. (active-model-serialization for example) in favor of more…
This has inspired me to take my learning and future work far more seriously (along with reading war of art last night)
from now on my goal is to be an engineer and a businesswoman first and foremost, with the goal of being able to engineer quality products and systems for myself and freelance clients
from here im going to go through the odin project and focus on being well grounded in the fundamental principles and techs - no longer just a hobby and now i know to be at the top i will need a lot of grueling work
good thing i like react and js!
thx again :)
i think rails to start followed by some other stacks to see what best universal practices are
https://www.trip.com is 90% Rails I'd say. Everything you see on the surface is Rails. As you grow, you do less of "belongs_to" and "has_many" and you do way more Ruby and way more Glue code that will work with all the models in the system and generate something for the user. Scaling is a big issue, you constantly work around "best practices" that don't scale. (active-model-serialization for example) in favor of more…