Rails course update

[CouchofTomato]

Rails Course Overview

This details how the course should flow. What do we want to cover and when.

Contents

1. Introduction
2. Rails Basics
3. ActiveRecord Basics
4. Forms and Authentication
5. Advanced Forms and ActiveRecord
6. Apis
7. Mailers and Advanced Topics

Introduction

1. How this course will work
2. Preparing for deployment
3. Installing Rails (project)

Rails Basics

1. A railsy web refresher
2. Routing
3. Controllers
4. Views
5. The Asset Pipeline
6. Webpacker
7. Deployment
8. Blog app (project)

ActiveRecord Basics

1. ActiveRecord basics
2. Micro-reddit (project)

Forms and Authentication

1. Form Basics
2. Forms (project)
3. Sessions, Cookies and Authentication
4. Members only (project)

Advanced Forms and ActiveRecord

1. ActiveRecord queries
2. ActiveRecord Associations
3. Private Events (project)
4. ActiveRecord callbacks
5. Advanced forms
6. Flight Booker (project)

APIs

1. APIs and building your own
2. Working with external APIs
3. Kittens API
4. Flickr API

Mailers and Advanced Topics

1. Mailers
2. Sending confirmation emails (project)
3. Advanced Topics
4. Websockets and ActionCable
5. Finals Rails Project (project)
6. Conclusion

[MchaseCov]

There's been some discussions on Discord between the Ruby & Contributions channels, but those tuning into this discussion may have missed those. I wanted to start by recapping some of the discussion points that I have been a part of myself so that it can be easily referenced and discussed by others. This comment is going to stand on its own as the recap points and I will begin my actual discussion in a separate reply

---

Established Rails 7 Updates (Based on currently existing issue postings)

• update Installation of Rails from 6 to 7
• new Lesson(s) on Hotwire Turbo (Drive, Frames, Streams. Turbo Native is outside of the scope of TOP as it is mobile app related.)
• new Lesson(s) on Hotwire Stimulus
• Lessons on new "Javascript inclusion" options
  • new Importmaps (Rails 7 default)
  • new JS bundling (Bundler option for Rails 7)
  • update Webpacker is not recommended for Rails 7 going forward, but still maintained in existing projects

Curriculum structure ideas (Discussed but not actually established anywhere)

• The Rails Basics section is already long and adding new lessons about the Javascript assets would make it even longer.
  • The asset pipeline lessons could be moved until after this section.
  • Webpacker itself could be moved to the end-of-course advanced section, as it would be supplementary information and not actually used during a Rails 7 TOP curriculum.
  • The Rails Basics section could be reworked to be more simple and focus on the very basics of MVC. Afterwards, more detailed information on MVC, routes, ActiveRecord, etc.
• The new Turbo lesson could be split into two lessons. Turbo Streams have broadcast functionality, but Websockets are not currently taught until the end of TOP. This "Advanced Turbo Stream" portion could be moved into that lesson or be a small lesson in the advanced section
  • The idea of a "basic" and "advanced" version of topics has been brought up as a general possibility for course structure

[MchaseCov]

To start with an actual discussion point:

I do agree that the basics section is a bit long and brought up that the asset pipeline content doesn't really fit in to the main MVC idea and the blog app project's focus.

Thinking on it some more, I wonder if the Blog App could be used as more of a learning tool than it currently is? Right now the course is structured in a way that gives you a lot of information and then you follow the getting started with Rails guide. This guide is great and personally I used it very often when progressing forward and needing to remember how to do the syntax of something like permitted params or if I should use delete vs destroy, etc.

I was thinking it may be beneficial to teach alongside the blog app, rather than before it. I recall that I learned a lot more by doing this project than the reading before it. Even though I thought I understood MVC as a concept and all of the reading, I was a bit overwhelmed when it came to the actual practice of it and putting it into place. I knew on paper that the controller connects to the model and view, but I didn't really know what it looked like to go through and build them. I almost had to "learn twice" because the first time around was giving me so much information that it was hard to know which topic I was applying.

For instance, the Rails Basics section may have short and simple lessons on MVC/routing/whatever else is deemed to be included still. Then during the blog app project, have students do a chunk at a time and discuss what they have been doing to solidify their knowledge. Right now, the lesson page essentially just tells you "do until 8.2, skip 8.3 if you have issues, and then you can optionally do 9 and 10."

I think it may be helpful to break it down more and move the learning from the lessons to the project. An example of what the structure could be is:

• Now, complete section 4.0 of the blog app tutorial. This section will help you get started with your first piece of your application, the controller and it's routing. Remember, the routing is the part of our application that knows where to send the requests that users send in.
  • In section 4.2, we set get "/articles", to: "articles#index" in our route file. This means that anybody who goes to the url http://localhost:3000/articles will be making a GET request that is sent to our index action of our articles controller.
  • We also ran the command to generate a controller. Rails offers generators for you to quickly get the pieces of your app created without having to manually create and set up each file from scratch. You can see that we generated the index action by typing it as an argument in our command
  • In 4.3 we went back to our route file again. This is because we had to set our "root" route. You can think of this as the default route. When somebody goes to your website without any subdirectory, this is the route that they will be requesting.

(Obviously I oversimplified some topics here, take this as a rough example of structure and not an actual publish-ready recap)

---

That is a bit of a long-winded example and may be overboard, considering the blog app does include some of this in the tutorial itself. You could have overall section recaps instead of individual "X.1 X.2 X.3" pointers. My overall point is that I think it may help to teach these topics in a way that allows the learners to be able to apply their knowledge at the same time.

My proposal here isn't to turn it into a tutorial but rather a recap of what the students have already done and saying, "you did this, with these pieces of MVC, and this is why you did it".

[CouchofTomato]

Thanks @MchaseCov

Some great points.

I've been doing some thinking on the structure as over time it has become a bit disjointed so I'm just going to throw out all my random thoughts and then we can start to pick through and find some actionable points.

Having a project to follow along to rather than at the end of the rails basics section is a great idea. The blog app is good because it will likely stay updated with each new rails version so I agree it's not a bad project to stick with. It's a bit awkward though that it covers models which aren't covered in the basics section. So I agree with you that we should consider to change the basics section to cover the MVC parts of rails in a basic way alongside the blog app relevant sections.

I propose we consider moving the railsy web refresher to the end of the introduction section. That way we can start rails basics with routing, controllers, views and then models and active record . The final project could be micro reddit for the basics section.

Not sure where deployment would sit in with that but I'm sure a natural home for it will become clear when everything else is ironed out.

The asset pipeline could probably be it's own section where we cover assets which will include both css-bundling and js-bundling now and images etc

The forms section is ok I think except for any small updates. Advanced Forms and Active Record makes sense to go together because the advanced forms cover associations through forms so that is probably also ok.

The other sections likewise don't look too bad on content.

For the new content, especially the turbo and stimulus lessons they are advanced concepts so it would make sense to push them further back in the course. They aren't rails basics at all so maybe before or after the api lessons would work?

The advanced topics lesson feels a bit awkward as a mish-mash of things. I wonder if some of these could be extracted out

I think webpacker can probably just become a section within a lesson on the js-bundling gem rather than a standalone lesson. Students won't need to know a lot of the details. Just knowledge that it exists, what its purpose was and a little bit on how it worked in case they come across it in the wild.

Happy to hear from Kevin shortly too, but although I've just splurged all my thoughts above I think if we focus on the basics section initially to iron out the details there we can then move onto the other sections so any feedback on my proposals for the basics section in appreciated.

[MchaseCov]

Oh I really like your ideas here!! Ill give some thoughts I had as I read them. Nothing really dissenting, just a bit of input to share that I generally agree and some thoughts.

It's a bit awkward though that it covers models which aren't covered in the basics section.

Oh interesting, I never noticed that. I guess its technically covered in the "general MVC" sense that is included, but I guess that also contributes to my feeling of "learning in the blog app" because it also covers content that was actually new.

I propose we consider moving the railsy web refresher to the end of the introduction section. That way we can start rails basics with routing, controllers, views and then models and active record . The final project could be micro reddit for the basics section.

I think this sounds great. Would barely be a change as far as "learning order' goes, and just makes organization nicer. It covers a lot of loose topics but as just general reminders. I think this does work better in a "general intro" sort of sense rather than in the basics. It covers a lot of terms in a loose way and would help the rails basics be cut down and focused more.

Not sure where deployment would sit in with that but I'm sure a natural home for it will become clear when everything else is ironed out.

Its hard to say specifics at the moment, but I think it fits somewhere towards the end of the blog app tutorial. Most of the deployment page is just teaching things like a 'dyno' and not highly involved so its not actually a large overwhelming chunk IMO. (I think the hardest part of it is that you have to change your database to PostgreSQL and that has some bumps to set up and isn't really explained anywhere besides a bonus resource). SSH key is already set up during the intro section though. I think that if the blog is being made as a work-along, whether the work along is across multiple lessons as example or just a narrated project on one page, a natural follow-up would be saying how to deploy it to the web and still having that taught before micro-reddit.

The asset pipeline could probably be it's own section

Already in agreement there and suggested this myself before I knew it was being looked at.

The forms section is ok

Random note: Devise forms should be wrapped in turbo-disable containers (so error messages are shown) and the controller#create actions's render :new needs to include status: :unprocessable_entity just for overall compatibility and smooth sailing. This isn't really in response to you or on topic, just a thing that comes to mind when you say small updates. I think the forms section itself is pretty good for the content, simple to do, and would just need minor tweaks to make sure nothing is dated or awkward.

The other sections likewise don't look too bad on content.

Agreed. Although I was wondering if the Active Record section could have a lesson that essentially says "reminder that you know Rspec and/or Minitest, you have these really cool fixture files being made for you and these really cool test files to use them in. Heres how to write basic tests for associations or validations, good luuuuck" (Or maybe Rspec from Ruby already teaches you everything you need to know and its fine, I genuinely do not remember)

(Turbo & Stimulus) aren't rails basics at all so maybe before or after the api lessons would work?

I think Turbo goes great right after APIs because you can teach turbo stream formats as "hey this is just like you learned with format for JSON, except its format for Turbo Stream." where you make a .turbo_stream.erb and have it in your controller and its a special kind of response. It mirrors the syntax and is a good follow up to APIs. It doesn't really "build on top" of any other topic besides the fact that format is taught in APIs so it seems about as good of a place as any without it being too early as well. Stimulus doesn't really flow anywhere specifically that I can think of, but it should probably just be right after the Turbo lesson no matter what just because its made to be a Turbo website helper.

The advanced topics lesson feels a bit awkward as a mish-mash of things

I dont have any great ideas on this yet. I do the Advanced section could be divided into smaller lessons like "Advanced Routing, Advanced Controllers(?), Advanced Layouts, Advanced Turbo Streams". I think this gives the advanced section a more clear identity as well as a place for future "advanced things" to have a home. Doesn't mean you have to fill much more content, rather that the content is more divided and focused so keep it from becoming a 'misc things we left out' graveyard lesson page.

This does make it a bit awkward to fit in "mailers'. Its not really an advanced level of something already learned, but I dont think it hurts to leave it in advanced? Or it could just be its own tiny lesson section like Active Record Basics is now.

While looking at this section, I do want to bring up Websocket/Action Cable. At the moment, it seems like the one topic that has its own dedicated lesson plan that isnt actually used in a project (not counting the follow-along assignment). With the introduction of Turbo Stream being relatively simple, should there be an extra credit for some kind of turbo stream in the Facebook project? Or maybe just a mini work-along project that uses Turbo Streaming? Otherwise, there could be a use for a "bonus materials" section. Move the conclusion 'lesson' into it, alongside anything that isn't actually used in the curriculum but still is a good resource for those going forward to know about and be able to refer back to. Websockets and Webpacker gem are the only two I can think of that would fit in there now, and you mentioned that Webpacker could just be a subheader now (which I also agree with) so this isn't something I say with a huge necessity. Just a random idea to throw out.

---

Obviously I am not a Maintainer myself nor do I have the full grasp of what direction and lesson-plan design that TOP uses. I dont intend to say anything here with authority or even experience really, just sharing some thoughts in response to your post of how I think some more specifics could be done or things to look out for or possibly throwing new ideas out that could be expanded upon.

[CouchofTomato]

Hey @MchaseCov

Super valuable feedback.

Firstly don't worry that you aren't a maintainer. We all got there by doing exactly what you're doing now. Getting involved and helping shape TOP for the future.

I can't say I disagree with anything you've said and everything sounds sensible.

The plan is that we get TOP rails 7 ready ASAP with the minimal amount of work needed. Then we continue with the slightly bigger project of improving the course and we'd love for you to help in any way you feel comfortable. Tomorrow I'll draw up a proposed course template for getting us rails 7 ready and if we all agree we can work on those and get the course out there.

[CouchofTomato]

@MchaseCov @KevinMulhern - would appreciate some feedback to make sure we're on the same page.

The section with the blog app is still a bit of a pain really so I'm still pondering this. Worst case scenario we tackle it after we get on rails 7. This is the minimum path needed to get updated.

We also need to decide on Chase's note

Random note: Devise forms should be wrapped in turbo-disable containers (so error messages are shown) and the controller#create actions's render :new needs to include status: :unprocessable_entity just for overall compatibility and smooth sailing. This isn't really in response to you or on topic, just a thing that comes to mind when you say small updates. I think the forms section itself is pretty good for the content, simple to do, and would just need minor tweaks to make sure nothing is dated or awkward.

Rails Course Overview - Proposed initial Rails 7 structure

This can be the working structure that we can agree on and then action and get our course rails 7 ready.

Introduction

1. How this course will work
2. Preparing for deployment
3. Installing Rails (project)
4. A railsy web refresher

Rails Basics

1. Routing
2. Controllers
3. Views
4. Deployment
5. Blog app (project)

ActiveRecord Basics

1. ActiveRecord basics
2. Micro-reddit (project)

The Asset Pipeline

1. The Asset Pipeline
2. Importmaps

Forms and Authentication

1. Form Basics
2. Forms (project)
3. Sessions, Cookies and Authentication
4. Members only (project)

Advanced Forms and ActiveRecord

1. ActiveRecord queries
2. ActiveRecord Associations
3. Private Events (project)
4. ActiveRecord callbacks
5. Advanced forms
6. Flight Booker (project)

APIs

1. APIs and building your own
2. Working with external APIs
3. Kittens API
4. Flickr API

Rails Sprinkles

1. CSS-Bundling
2. JS-Bundling (including a section on webpacker)
3. Turbo
4. Stimulus
5. (should we have a project here to cover these technologies?)

Mailers and Advanced Topics

1. Mailers
2. Sending confirmation emails (project)
3. Advanced Topics
4. Websockets and ActionCable
5. Finals Rails Project (project)
6. Conclusion

[MchaseCov]

In my opinion this is a good start to move forward with. I don't see anything out of place and I think it's a good update for Rails 7, and then the extra reworking ideas could be done afterwards.

The section with the blog app is still a bit of a pain really so I'm still pondering this.

I think its fine if the written content of the Rails Basics lessons stay the same, besides being rearranged. In my opinion, it would be okay to minimally update those lessons for now and then approach the space for a more streamlined Basics section in another course update. Nothing in the section is missing or incorrect (besides random things that would need a 6.1 > 7 update). I suggested the rework of the section because I think it could be improved but I don't think that its a critical issue; It could take the back seat for the Rails 7 update to focus on Rails 7 alone.

In the ActiveRecord section, are you using "JS-Bundling" as an umbella term or as reference to specifically the js bundling gem for Rails 7? If you mean the gem, then importmaps do also need to be included somewhere. I assume it's just an umbella term for all 3 of the methods though. I only point this out since the working name of the section and the name of the gem overlap and I want to be on the same page.

I don't think a Turbo/Stimulus project would be unreasonable, considering how it can be very simple to set up. Without broadcasting, it's really just wrapping things inside of HTML helper tags and adding a new format to your controller.

(For something basic, you only need about 3 1-line turbo_stream view format files, the controller format do to handle it, a basic Stimulus controller, and then a few turbo_frame_tags in the standard views for fun. )

Stimulus is the only 'hard' part I forsee; I imagine most people on the Ruby>Rails path are not thinking about Javascript at this point in the path, but since we do have a Stimulus lesson I don't think it would be unreasonable to ask for a basic controller. I think if there is a project, it could be like the Micro Reddit or the first Forms project. To me, those two projects feel like they're a hybrid of project and interactive lesson. It's not about building something large and impressive, but rather just using the tools hands-on to be familiar with them and how they work and the errors you may face when using them.

And then I wanted to say a bit more in regards to my note if it's also being discussed:

The Getting Started With Rails blog app project on the Rails Guides website itself does use render :new, status: :unprocessable_entity in the example project as well as data-turbo-delete & data-turbo-confirm for when you want a pop-up to confirm on click (which is a replacement for the previous UJS approach of data-delete/confirm). TOP already links to the most recent version of this project so even now, this is how people are being taught to do this. I'm sure the course has other places that need to be updated, but for the record it does seem like that's just the new way to do things and it's already updated on their end.

The Devise/Hotwire compatibility, on the other hand, I do need to test and research more. Initially, you had to essentially paste a bunch of settings and even a controller override inside of the Devise config. I don't know if any of that matters anymore in any situations, nor do I know for sure if there's a better way to handle Devise error messages than disabling Turbo's caching. Wrapping the form in a Turbo Disable is a solution that works, but may not be the most correct solution to teach. Completely unsure. I'm starting to receive job interviews so I haven't had the chance to study the interactions between the gems just yet.

[CouchofTomato]

Thanks @MchaseCov

I told Kevin just this morning that I forgot to add importmaps. I think our original plan was to go with a lesson on importmaps and then we could kick the bundling gems a little further down the list as they aren't a rails fundamental which went over my head so I'll get the outline updated now.

Someone did ask this in the chatrooms and they're going to submit a PR to link to the rails 6.1 version of the rails blog app just to give us some breathing room to get this fixed, otherwise it's going to be confusing for learners. I am hoping we're only like 2 or 3 weeks from being ready to launch rails 7 anyway.

We can then deal with any small issues as they crop up

[CouchofTomato]

@MchaseCov @KevinMulhern See updated course outline #81 (comment)

[MchaseCov]

Updated outline looks really good to me! I actually like the split of jsbundling & webpacker down to the bottom. Never occurred to me to split the new methods up, but it makes sense and im sure won't be as overwhelming as back-to-back lessons right in the middle of AR and forms!

Is there any particular direction or topics that I could help on? If nothing in particular, I have some ideas of where I could be able to contribute more.

I can make some time this week to check out the remaining Rails 7 lesson issues that nobody has responded to and see if theres one that I think I could write a good lesson on. Otherwise, I can take a few looks through the course to note any minor things that I think need to be updated that could get slipped over just in case. I don't expect there to be much, other than a "turbolinks" or "rails 6" here and there. For the sake of not spamming notifications with 10-character changes, I could do that as one combined "terminology update" PR with all the changes as individual commits in the single branch.

This also helps with the Turbo lesson I already wrote. Knowing it's towards the end and that it's after key sections like APIs will help with editing it down and making it flow better.

[CouchofTomato]

Hey @MchaseCov

Thanks. Normally I'd say do them separately because htey are easier to review but in this case we can't merge these changes until we're ready to go so if you want to do the minor changes then it's probably better to do just one PR that we can merge when the course is ready to go.

I would say though normally we get the course ready and then do any small changes, especially as we get feedback from those taking the course who find these small issues.

[linkonsat]

-MMIncorporated. Something I would love to see and an example given of what was needed to improve the Rails course was testing. After looking at the example of tests on the Rails guide for different things to test i wanted to share my thoughts. I believe depending on how testing is incorporated it may change how some things are structured overall or the flow of the rails lessons. There are a few ways that come to mind for structuring a testing section for the rails section.

1. Having one major testing section that would go over major areas of testing and go over a TDD approach when creating a rails application. As well as lessons on testing more minor aspects.
   1a. In the current iteration of the lesson framework mailers and action cable comes right before the final project. This does present an issue when incorporating testing. In that, the current setup has mailers and action cable both come right before the final project in the advanced topics when both can be tested. Testing for mailers and action cable would end up being before it's mentioned as a lesson. This could make it seem disjointed not mentioning mailers and action pack within the testing section when they can be tested.

1b. A few solutions come to mind for this. One way is to introduce minor lessons for mailers and action pack going over testing both of them while having the testing section go over the rest of the testing concepts. There is another option to just ignore mailers and action pack testing, however, since it is mentioned in the rails guides I think it should at least be mentioned. Another Is to have the rails course be similar to the ruby course where there is the testing section then the final project section afterward. With the lessons going over all aspects of testing then finishing off with a TDD project. Personally, while this progression makes more sense to me, a concern is if we ask the learner to do a project right before the final project using what they learned from the lessons previously there is a chance they end up creating the equivalent of the final project. in which case I am not entirely sure it makes sense to have them end up building two large projects immediately after each other. Which for that reason I am skeptical of this choice but, it could still work albeit it would be harder to avoid having the learner build the equivalent of the final project twice or a project simply isn't included in this section which I don't favor at all.

2. Have the testing section go over the major components of testing and have minor testing lessons on for example controllers immediately after the lesson they are introduced in. A pro of this is that it would make logical sense to introduce testing a certain aspect of rails after it is introduced rather than later. This would not require moving any of the particular lessons and would simply be adding a testing section and adding lessons or brief mentions of smaller component testing such as controllers when the lesson is reached. It would also allow a section on major testing concepts while sprinkling testing certain aspects such as controllers as they come up in other lessons. I am leaning toward this mainly because it would not require building a major project with all the features and would mean the final project could make sense just staying with the advanced topics. As well as just introducing testing mailers and action cable as they appear rather than it occurring later. I personally favor this mainly due to the fact that it doesn't require lessons to be rearranged and a section for testing could be introduced wherever is deemed the best rather than it being forced to come later making it easier to introduce a moderate TDD rails project.
   2a. An issue I see here is that it would require sprinkling lessons or adding content to other lessons outside of the testing section. Which could affect the flow of the rails section. It could also be argued that if these testing lessons are not in the testing section it may seem odd when referring back to them for those testing lessons to not be in the section. However, the flexibility of being able to place a testing section wherever a reasonably sized rails TDD project would fit seems beneficial. There would also not be a need to move the final project out of the advanced section while introducing how to test things such as controllers in the lesson after they are introduced seems like a positive and may encourage an individual learner to incorporate tests for those aspects earlier and thus get them familiar with setting up tests by the time they reach the testing section where a TDD project could be introduced.

[CouchofTomato]

Thanks for the feedback @linkonsat

I think it's totally reasonable to have a testing section that covers the main areas of concern for a Rails app and then cover separatately any other areas as they arise. Not all apps will need a mailer or actioncable to we can cover those after they come up in the course and I don't see that being an issue.

@KevinMulhern had an idea, similar to the Ruby course, where we can have some Rails repos set up for students to clone with tests already written and students will need to write the code to make them pass, this could be creating the correct model for example. This way we could also show some well written tests that students can learn from. This will be discussed further once the course is Rails 7 ready.

[linkonsat]

I think it's totally reasonable to have a testing section that covers the main areas of concern for a Rails app and then cover separately any other areas as they arise. Not all apps will need a mailer or actioncable to we can cover those after they come up in the course and I don't see that being an issue.

@CouchofTomato Sweet! I was thinking about this today a bit. Given that that the rails course doesn't have testing within it already. I am assuming most learners within the rails section are already used to thinking about rails without testing. Given this, my assumption is that testing would be included after the rails course is updated to 7.

Going over what testing smaller areas could be. A lesson on testing a concept would be introduced after the lesson that concept is introduced in. This lesson would go over how to set up the test, what kind of test it is, what we would test for that concept and perhaps a error message example and how to resolve it. I think having this information in a lesson after the concept is introduced versus having the information in a test repo would be beneficial. An issue with non-exercise information in a repo is learners may focus on just passing the tests and not be taking the time to go over the commented out section in a repo. Whereas if the information is in it's own separate lesson the intention should be clear to focus on reading the content and understanding it versus just passing the test.

This is also beneficial as the testing lessons could be created without relying on the existence of a testing repo. As the lesson itself would go over what creating the test would look like. Making it a handy reference for when a project lesson is reached with or without the testing repo. Just want to state as well that when testing is worked on after the rails course is updated to 7. I would love to help on that if the opportunity is made available to non maintainers. On second thought i could just raise the individual issues in the proper discord channel and make the PR's but, seeing as it would be part of larger addition I'm not sure it's effective to do it in that way since it would be odd to have testing lessons pop in rails randomly. Still i would love to help!

KevinMulhern had an idea, similar to the Ruby course, where we can have some Rails repos set up for students to clone with tests already written and students will need to write the code to make them pass, this could be creating the correct model for example. This way we could also show some well written tests that students can learn from. This will be discussed further once the course is Rails 7 ready.

Just want to say I really like this idea. Particularly as it could utilized with the testing lessons and the main testing section as exercises to do. If a learner is inquisitive as well it could give them ideas on what to test.

[KevinMulhern]

I've had my head in the testing stuff for a while now 😅 If we wanted to do something quick as an mvp we could get away with creating just two testing lessons:

• A Model testing lesson in the Active Record section which would include something about fixtures/factorybot
• An End-to-end testing lesson that teaches Capybara in the Advanced Forms and Active Record

Those two lessons combined with the testing lessons in the Ruby course will cover a vast majority of what students will need to test in Rails.

Anything else like mailer testing and request specs for the API section would be great to have as well of course. But if we want to prioritise, those are the two that will have the biggest impact.

[ChargrilledChook]

Regarding a turbo / stimulus project, these technologies could be a good candidate to go back and extend or refactor an earlier project with these tools, similar to how people add a mailer to Flight Booker.

For instance, adding to blog project or micro reddit posts and comments. This also has the advantage of being very easy to implement (compared to concepting a brand new project). If it's decided that's worth doing anyway, would still be a good warm up.

[CouchofTomato]

Yeah I like this idea.

[linkonsat]

Looking through the debugging page on the rails guide. I was thinking it might be useful to provide a lesson just going over the new tools. Especially given that rails 7 uses different debugging gems than introduced in the Ruby Section as well as the log file. I think a brief lesson as part of the Rails basics going over ways to use the new debugging tools could be useful. Mainly to introduce to learners on how to use these tools before going deeper into the rails course.

[KevinMulhern]

Doing this is such a great idea @CouchofTomato 💪 If we can come up with the ideal or as close to an ideal lesson plan as we can, we’ll have a solid roadmap to work off for a good while instead of the ad-hoc approach of adding lessons here and there we usually take.

Just some of the things I’ve been thinking about with the Rails course. Sorry, I know a few of these have already been mentioned. But I think it's worth reiterating them:

• Make the basics section “basic” by focusing on teaching MVC
• Deep dives into each area (routes, controllers, views) later.
• Smaller, shorter lessons. For example instead of one lesson covering migrations, validations and associations. We would have a lesson for each.
• Lots of exercises in the form of repos where students need to write code to get tests passing. Especially in the Active Record lessons.
• Testing lessons spread throughout.

I mentioned to @CouchofTomato, it may be worth doing a “completive analysis”. This is basically looking at other Rails curriculums, courses, books etc to see if there are any prevalent patterns in how they all introduce and place things, assessing what they do good/bad and what we could do better.

We’ve done this in the past for a few things and it's always generated a lot of really good insights that can kick start making our own lesson plan.

[linkonsat]

@KevinMulhern that format sounds really great. Going through the rails course some of rails guide are a bit lengthy. It would definitely be worth breaking it up for a better learner experience. As well as making the process of releasing updates through chunks less disruptive. Only thing that comes off the top of my head at the moment is perhaps a debugger lesson in the basics section and whatever ideas can be gained through a competitive analysis as you suggested to @CouchofTomato .

[mgrigoriev8109]

So I looked through this conversation, and having just made my way through the beginning of rails up until Micro-Reddit I had a thought / some feedback.

While going through the MVC lessons I attempted to follow along the Blog App and do a bit of it with every lesson I learned. So as I learned about Routers, I did the small part of the Blog App which included Routers, then with the Controllers lesson I did the same, and then Views (similarly to what @MchaseCov was discussing). I did find that this was very difficult to do, as the Blog App tends to bounce around a lot between those three concepts a lot. I had a much easier time with the Blog App after I stopped trying to bounce around, and more thoroughly read through all of the content one time through- since I was able to create a more cohesive structure in m head of what MVC looks like and how everything interacts.

I started thinking about the Blog App again once I began working on Micro-Reddit. The Micro-Reddit project is amazing, and I feel like as a learner I got so much more out of it than the Blog App, because the in-house instructions were more vague, which challenged me to use the documentation to find out how to solve the various instructions given (while still providing hints, references to material, and lines of code at just the right moments).

So the suggestion I had to updating the Rails Course, and I would love to help create this, would be to create an In-house Blog App project with instructions which are slightly more vague than the explicit ones provided by https://guides.rubyonrails.org/v6.1/getting_started.html

As mentioned in this conversation Models aren't covered until later lessons, so those parts of the project (I believe sections 5.0-5.3) can remain predominantly copy/pasting code with explanations of what's happening.

The upsides of this change would be that learners would get significantly more practice with Routes, Views, Controllers, and doing their own research of Rails documentation to create all three.

The potential downsides of this change would be that more broad instructions would result in learners possibly running into more issues, and this would create the need for more help in the #rails-help channel. This additional bandwidth required by the community could possibly be offset by still including the Getting Started link as something to reference when learners are unsure of what to do.

Let me know if I'm out of line in suggesting this, or any thoughts on why this is possibly a bad idea / any ways in which I can help :)

[CouchofTomato]

@mgrigoriev8109

You'd never be out of line in making a suggestion. We welcome the thoughts of anyone which is why I specifically set up this discussion.

I'm not sure this is the correct approach. I think having them follow along to instructions has some benefit to just getting them familiar with what they should expect to see from running some commands. The overhead of trying to build a project when you don't even really understand what models, views or controllers are might not be that helpful.

Kevin's idea of re-intorducing an earlier section about building a web app without using rails, so either using sinatra or some other tool would be more beneficial in introducing them to concepts without the mental overhead of trying to understand all the Rails conventions.

[ChargrilledChook]

On the topic of building a web app without rails, I found this article recently:
https://shopify.engineering/building-web-app-ruby-rails

It begins by building a web app in plain Ruby then slowly adding on more libraries and abstractions - from using rack, to adding SQLite, and then adding core Rails libraries (like active record) without using Rails itself.

Using this as an assignment (or adapting it) could be a great crash course intro for the Rails section

[mgrigoriev8109]

Makes a lot of sense, I appreciate your feedback and thoughts, thank you for responding!

Let me know if there's any assistance needed in the Rails section. I enjoy teaching, writing, and rewriting lessons - and would love to give back by helping in any way I can.