This will be a bit controversial, but I doubt you'll find a lot of usage for data structures and algorithms, outside working with hashes and arrays (creating, merging, traversing, mapping and so on). I've been a programmer for almost two decades and the only time I've needed to know anything about the big O notation was during interviews and only in the first part of my career. As it was already explained on this thread, writing software is not an exercise in computer science, but in software engineering.
If you're planning to expand your knowledge so you can build high quality Ruby on Rails application, I'd suggest the following resources after you've learned the basics of Rails:
Ruby & Rails
There are a couple of books that tackle in more detail some topics regarding Ruby and Rails. Unfortunately they are tied to older versions of Ruby and Rails, but they are still excellent books:
​
SQL
Using a framework which contains an ORM does not mean you don't need to understand how relational databases work. You won't be writing queries by hand, but you still need to know how to query the data and how the relations between tables work. These two books are a gentle introduction and go into a lot of detail:
If you want to go deeper, I also recommend Effective SQL, SQL Cookbook, and SQL Antipatterns (there's a new edition coming out soon), but these are recipe books.
​
Object-Oriented Programming
The biggest issue with programming nowadays is managing complexity and change. Since you've picked Ruby and Ruby on Rails, the simplest way to do that is via object-oriented programming. However, it's extremely easy to make a mess out of OOP because you need to use the proper abstractions and metaphors and you need to understand when you should favor cohesion over flexibility. There are a couple of classics (some were already mentioned here) that should help you write better object-oriented code:
​
Domain-Driven Design
Now that you know your way around a Rails codebase and you have the technical skills to add write code, the biggest problem is understanding the business domain. There are a number of ways to do this, but probably the best methodology right now is Domain-Driven Design. However, following DDD too rigidly might be at odds with the typical Rails Way of doing things (like adding a layer of abstraction between the controllers and models), so use this as a guidance.
​
There is also plenty of information on YouTube. For example, DHH posted 7 videos a couple of years ago about different Rails concepts. There are some excellent presentations from various Ruby and Rails conferences and, if I were to pick three, it would be these three talks by Sandi Metz ("Nothing is something" is definitely my favorite, but all three are great).
Obviously, don't buy everything at once. Some things might be more important or more relevant to you than others. Take the time to practice the concepts you read so you fully understand when to use them, what are the advantages, and what are the downsides. Don't be afraid to test new things and see if those mental models work for you.
Best of luck!
Go ahead man, Ruby it's still a great language. Probably you will end up learning RoR as well; a solid framework, it uses convention over configuration (you can still avoid these conventions but that would add extra work). There are a lot of great ruby books.
For Ruby
Fo RoR