My last few issues have been about software patterns, which got me thinking about Ruby’s relationship with the programming resources from the broader object-oriented community.
While everyone’s experience in learning Rails will be different, you’ll usually start by learning things like Rails’s MVC architecture, how the names of views and controllers/actions are inferred, the routing DSL, the ActiveRecord API, and how to test Rails applications. That list is totally arbitrary and incomplete, but you’ll certainly learn things like those things.
In learning Ruby, you’ll pick up very different knowledge. You’ll learn things that are very distinct from Rails like what “everything is an object” means, how inheritance works, the various control flow mechanisms, how to define classes and modules, and how to use the standard library.
Learning Ruby and learning Rails complement each other. You can do a lot with Rails with only a shallow understanding of Ruby. You can learn Ruby without ever learning Rails. If you develop a well-rounded understanding of both, you should have the technical skills you need to get fairly far as a Rails developer.
Whether you’re learning Ruby or Rails, there are plenty of great resources. The community has created various books, videos, tutorials, and other resources, like the Ruby Koans.
Unless you’re already an experienced object-oriented programmer, once you’re comfortable with both Ruby and Rails and started building more complex applications you’ll want to learn more about application design and how you can structure your code to make it more maintainable, performant, and understandable.
This is where I see a gap in the resources out there. There’s not enough material out there* that seeks to teach someone who are comfortable with Ruby and Rails how to take those skills and use them to build meaningfully complex systems.
Books like Eric Evans Domain-Driven Design, Growing Object-Oriented Software, Guided by Tests by Freeman and Pryce, and Michael Feathers’ Working Effectively with Legacy Code are all great reads for an intermediate Ruby programmer, but all require some translation to understand how the concepts apply to dynamic languages like Ruby.
For example, Ruby doesn’t have a static type system, so no concept of interfaces beyond duck types. This makes advice like “mock interface, not classes” very difficult to follow. There are various techniques for following the spirit of this in Ruby, but you’d be hard pressed to find content explaining those techniques.
That’s just an example of the gap in content that translates the wisdom of decades of object-oriented programming for use in Ruby and Rails. Our tools and frameworks are sufficiently different that they warrant this kind of translation and distillation.
Ruby is a very mature ecosystem, no longer the hot new framework on the scene. We’ve built fantastic resources to get people to the intermediate level. When Rubyists want to build on that foundation, they’re faced with navigating all the OOP resources with minimal guidance, trying to adapt what they learn to one of the most dynamic languages in use today. Experience goes a long way, but we can do better.
Rails showed us that there’s tons of value in creating a software conventions in order to avoid having to reinvent the wheel at every turn. When it comes to software design, the Ruby community is nowhere near aligned on patterns and proposed solutions (like the dry-rb tooling) aren’t palatable to enough developers to take hold. I wish we had more resources to help the community develop more software design conventions so we can see the same benefits for application design.