Enroll through edx.org (It's free)

You already have The prerrequisites From What You are saying.

If You are in University, listen to Leslie Lamport: University is a time to edúcate youtself, You learn The job on The job.

Taking a single user application to multiple users does have some extra work. Just going to ask some thought starter questions:

- Do you have an integration with the school's SIS (student info system) or are you web scraping their site?

- How would you keep your system updated for things like classes filling up, times changing, etc.

- How would users login to this application to pull up their schedule & classes?

- How are you updating the school's system, if at all, with schedule changes?

- Does your application consider major or graduating requirements in how to choose what classes? Some schools system provide this.

> Its object oriented, like Java, it has ActiveRecord which is an Object Relational Model, it has an opinionated file structure strongly aimed towards MVC (model, view, controller)

Sorry if this sounds ignorant (it is, because I never had a formal CS education), but why are these things important? When I first started learning programming, OOP was all the rage, as was MVC, but it seems like in the last few years, the web dev world has largely moved towards React's "function soup inside HTML templates" model.

I was about to start learning Ruby and Rails for a job, but your post has me curious and also a little worried. "Batteries included" is nice, but does Ruby force you into a particular coding style/paradigm, and is that going to cause any readability/maintainability issues, especially when paired with a JSX frontend?

Regarding "function soup inside HTML templates" I think you should strongly consider Rails Hotwire [0] (in Rails 7+, add-on for 6.1) and having the server, well, serve the HTML. Rails is a full stack framework and Turbo/Hotwire can do a lot of the heavy lifting for dynamic applications.

[0] https://hotwired.dev/

On top of that it has a decent and friendly to beginners community promoting good code style and practices.

RoR is just a superior choice on many levels.

Doesn’t mean that it is perfect all weather tool (far from it) but its a solid beginners choice to avoid any regrets looking back.

In Ruby however each object kind of gets its own set of three things, three files - Views, Models, Controllers - which means if you have a lot of things that do very little each, you end up with lots of files and switching tabs.

For how my mind works, I dislike this, as every simple Controller kind of looks like every other. It gets predictable, but grating. I personally struggle to read/maintain large MVC codebases because of this - having 3 controller tabs, 1 view tabs, 3 model tabs open to understand something that might be 3 files in Next.js is pretty difficult for me. But the predictability to know that it will be that way does give certainty and save some time when I am new to the code and somebody else has written it.

I'd take Ruby or a similar framework approach (e.g. OG Angular, Laravel, Java EE) if you have 8+ people working on the project. But for projects smaller than that, the beauty of having things in one place is very useful, and pleasant to the extent that most components look quite different and you can remember them that way. You can search for HTML from inspect element and probably find the state logic/processing from the API/backend causing a bug immediately. More recent frameworks and next.js (e.g. fire-svelte and server actions) allow backend code to more readily - yet securely - be placed near client side code, in a way, like PHP.

Also another big part of the background is that views were kind of like a sane version of the JS hell. Javascript until ES6 had many flaws; Ruby views kind of offered a sane alternative; your variables and logic were local, you could work on the visuals in isolation, you could compose them within each other dynamically and without issues where say, some code assumed there was only one of a certain element. But React components offer all that too, but in JS, the natural language of the frontend, necessary for things like click/hover/API calls/media rendering/media recording/permissions/storing data easily.

OOP and MVC are dropping out of fashion in Colleges as Java loses dominance to Python/Javascript there. Ruby is less strict and more terse than Java - you can just procedurally run it to process files for example, in Java you'd need the whole public static void main thing going on - but most people use Python for that these days.

in early JS versions, you had to rely on this pattern called "callbacks" for many actions. Callbacks were hard to read and infamously hard to debug with strange variable scope issues (resulting in a workaround ".bind()" with its own flaws), variables were often global or accidentally changed, rarely immutable with unfortunate side effects, and types and type comparison is strange (and remains so today). Worse, the general pattern was to include scripts and create snippets/elements with IDs or classes that would be "activated" by the javascript. This was good but could go terribly wrong. If two scripts happened to re-use the same code or class ID in global scope, or you yourself accidentally did, you could get all sorts of bugs, even some caused just by the ordering of the imports. React put it's foot down on this and closed off the scope using props, while allowing you to manage state, use HTML, and include CSS. I will admit I am ignorant about Ruby in 2024; but, to my mind, ES6 rising phased out Ruby.

For styling take Bulma or Bootstap (or any of “most popular css frameworks” except Tailwind), they work right out of box and require little knowledge.