GithubHelp home page GithubHelp logo

top-meta's Introduction

The Odin Project

The Odin Project (TOP) is an open-source curriculum for learning full-stack web development. Our mission is to provide a comprehensive curriculum to learn web development for free. We help users learn the skills and build the impressive portfolio of projects they need to get hired as a web developer.

Some of the topics we cover include:

  • Ruby
  • Ruby on Rails
  • SQL
  • HTML and CSS
  • Javascript
  • Node
  • React
  • How to go about getting a job in the industry

This repo contains the TOP app which pulls in lesson content as well as front-end and back-end code. To see the actual lesson content that gets pulled in, please go to the TOP curriculum repo.

Our community can be found on the TOP Discord server.

Contributing

Build Status

The Odin Project depends on open-source contributions to improve, grow, and thrive. We welcome contributors of all experience levels and backgrounds to help maintain this awesome curriculum and community. If you would like to contribute to our curriculum, be sure to thoroughly read our contributing guide.

Feel free to also watch this scrimba walkthrough of The Odin Project web app repo, which will give you an introduction to this repository. Note that since this scrimba was recorded, the content and/or structure may have changed in this repo. The focus of this scrimba is less on the actual content, but more of a high level overview.

top-meta's People

Contributors

01zulfi avatar asartea avatar chargrilledchook avatar codyloyd avatar couchoftomato avatar dm-murphy avatar fortypercenttitanium avatar i3uckwheat avatar joshdevhub avatar kashura avatar kevinmulhern avatar leosoaivan avatar linkonsat avatar manonlef avatar maoshizhong avatar marvingay avatar mgrigoriev8109 avatar rlmoser99 avatar robocopyzer0 avatar scheals avatar thatblindgeye avatar twalton83 avatar wise-king-sullyman avatar xandora avatar zachmmeyer avatar

Stargazers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

Watchers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

top-meta's Issues

Lesson: HTML/CSS - Custom Properties

Lesson Overview

A short lesson about the magic that is custom properties. This is a very important concept.. but it's also fairly simple so it doesn't need to be long.

Lesson Outline

The order of this outline doesn't need to be followed 100%, but the items listed here do need to show up in the lesson somewhere. If you feel like there has been an omission ask in Discord before expanding the scope of this lesson.

  • custom properties (variables)
    • make sure to cover things besides just colors.
    • theming/dark mode (prefers-color-scheme)

Acceptance Criteria

This is the definition of success. If the requirements here are not met, the work effort is not complete.

  • All items from the outline above are present in the lesson.
  • Lesson follows proper format
    • Section headings are ###
    • Code blocks use ~~~ and include a language name.
    • Lists are numbered.
  • Lesson has the following sections:
    • 'Learning Outcomes' at the beginning, optionally after a short introduction paragraph (relatively brief, give students an overview of what they're about to learn, with few specific details)
    • Assignment(optional) a list of resources to consume.
    • Practice(optional)
    • 'Additional Resources' (should exist even if it's blank)
    • 'Knowledge Check' (specific questions to test knowledge. Has details. Doesn't just parrot the Learning Outcomes. More of a spot-check, doesn't need to be exhaustive)
  • Lesson has been run through a spell-checker

Ruby Testing Lessons

Title Author Date
Ruby Testing Lessons Kevin 29/07/2021

Ruby Testing Lessons

Summary

A new section of testing lessons that would come just after the OOP section in the Ruby course.

Motivation

The testing section in the Ruby course was improved greatly last year with the addition of Rachels Testing Playground. However the testing lesson content is a bit lacking which is causing a disconnect between the lessons and the exercises.

The main goal of this project will be to improve the testing section with more broken down and comprehensive lessons where we will be able to introduce students to all the important concepts and have them do exercises along the way instead of all the exercises at the end.

A secondary goal will be to introduce students to testing earlier in the course by moving the testing section between the OOP and Files sections. This will allow students to utilize testing in the intermediary sections of the course and properly aligns the most important things we need to teach students in the Ruby course.
1: Fundamentals > 2: OOP > 3: Testing

Suggested implementation

1: Introduction Lesson
This lesson will explain the reasoning behind automated testing.

2: RSpec Part 1: Basics Lesson
This lesson will introduce students to basic RSpec syntax.

3: RSpec Part 2: Code Sharing Lesson
This lesson will introduce students to various code sharing techniques in RSpec.

4: Unit Testing Part 1: Basics:
This lesson will introduce a partially completed project that we will use in the examples.

5: Unit Testing Part 2: Mocks and Stubs
This lesson will build off the lesson before it by using the same example.

6: End-to-end Testing
This lesson will once again build off the unit testing lessons by getting the student to write a couple of end-to-end tests for it using aruba.

7: TDD Lesson
This final lesson will introduce the TDD workflow.

Drawbacks

The OOP section of the Ruby course that will come before this new section also needs a refresh. Good OOP knowledge helps tremendously with learning testing in Ruby. These new lessons may need to cover some minor OOP related things they otherwise wouldn't until the OOP section refresh can be done to compensate.

Git course (Sully / Cat )

Git Course

Summary

Revise the Git / GitHub related content to increase competency with these tools and equalize the understanding of them between the JS and Ruby tracks.

Motivation

A lack of Git / GitHub understanding by those on the JS track exemplified the discrepancy between the JS and Ruby tracks. Additionally, students have shown a lack of understanding of the importance of good commit messages, and a lack of knowledge when using Git in a team environment.

Suggested Implementation

1: Git Commits
This lesson will explain the importance of commit messages, the best practices for commit messages, when to commit, and how to set VSCode as the default Git commit editor. We are currently planning to put this lesson between the dev tools 1 and Google homepage lessons in Foundations. Once the HTML/CSS rewrite is done it should be easy to port this lesson to before the first project.

2: Basics of Git Branching
This will likely not be substantial enough to be its own lesson, but just a small addition at the top of the RPS project with instructions on how to branch, replacing what was done in this PR which links to this resource and explains things that are not important to students at the RPS level.

3: PR Procedure & Working with Open Source Projects
This lesson will be largely (if not 100%) based on the Using Git in the Real World lesson, but placed somewhere around the Weather App in the JS course and Custom Enumerable in the Ruby course rather than having it in the existing Git section.

4: Advanced Git Topics
This lesson will be largely (if not 100%) based on the A Deeper Look at Git lesson, but placed somewhere around Battleship in the JS course and Connect Four in the Ruby course rather than having it in the existing Git section.

Drawbacks

Adding length to the courses (especially foundations) is always something that should be weighed against the utility added. (Note: If expanding foundations for this content is deemed not worthwhile, we believe that a lesson focused on commit messages is still needed and suggest this lesson be after the first projects of the JS and Ruby courses.)

Lesson: HTML/CSS - Project for after morehtml and morecss

Lesson Overview

Point of this project is to give learners a chance to flex all the new properties they've learned in the 'more html' and 'more css' lessons

Lesson Outline

Provide a design that uses:

  • forms
  • tables (good luck figuring out a good way to shoehorn in a form AND a table lol)
  • background image/background position
  • border/border-radius
  • box-shadow
  • overflow (nice to have: maybe scrolling on the form or something?.. idk this sounds like a bad idea. )
  • opacity
  • custom font
  • font-style
  • line-height
  • text shadow/letter-spacing (maybe for a site-logo?)

Acceptance Criteria

This is the definition of success. If the requirements here are not met, the work effort is not complete.

  • All items from the outline above are present in the lesson.
  • Lesson follows proper format
    • Section headings are ###
    • Code blocks use ~~~ and include a language name.
    • Lists are numbered.
  • Lesson has the following sections:
    • 'Learning Outcomes' at the beginning, optionally after a short introduction paragraph (relatively brief, give students an overview of what they're about to learn, with few specific details)
    • Assignment(optional) a list of resources to consume.
    • Practice(optional)
    • 'Additional Resources' (should exist even if it's blank)
    • 'Knowledge Check' (specific questions to test knowledge. Has details. Doesn't just parrot the Learning Outcomes. More of a spot-check, doesn't need to be exhaustive)
  • Lesson has been run through a spell-checker

Lesson: Foundations - CSS Foundations

Lesson Overview

Much like the HTML foundations section, this lesson is not intended to be all-inclusive or to replace the breadth of our current lesson (FreeCodeCamp). We just want to get students up and running with CSS.

Lesson Outline

The order of this outline doesn't need to be followed 100%, but the items listed here do need to show up in the lesson somewhere. If you feel like there has been an omission ask in Discord before expanding the scope of this lesson.

  • Basic Syntax
  • Selectors
    • Element Selectors
    • Classes and class selectors (teach adding classes to HTML here.. that wasn't covered previously)
    • ids and id selectors (teach adding IDs to HTML here.. that wasn't covered previously)
    • basic combinations of selectors
      • selector, selector vs selector selector vs selector.selector
      • don't cover siblings or direct ancestors ( selector > selector ) yet.
  • The Cascade, Specificity, Inheritance
  • Some Basic, Crucial CSS properties:
    • Make a note here that this is definitely not a complete list, we're just scratching the surface to get things started.
    • color, background-color, (briefly cover css colors like hex values, rgb, hsl etc)
    • typography basics (font-size, font-family, font-weight)
    • text-align
    • height/width (for images specifically... we'll cover the box-model next)

Acceptance Criteria

This is the definition of success. If the requirements here are not met, the work effort is not complete.

  • All items from the outline above are present in the lesson.
  • Lesson follows proper format
    • Section headings are ###
    • Code blocks use ~~~ and include a language name.
    • Lists are numbered.
  • Lesson has the following sections:
    • 'Learning Outcomes' at the beginning, optionally after a short introduction paragraph (relatively brief, give students an overview of what they're about to learn, with few specific details)
    • Assignment(optional) a list of resources to consume.
    • Practice(optional)
    • 'Additional Resources' (should exist even if it's blank)
    • 'Knowledge Check' (specific questions to test knowledge. Has details. Doesn't just parrot the Learning Outcomes. More of a spot-check, doesn't need to be exhaustive)
  • Lesson has been run through a spell-checker

Lesson: HTML/CSS - Project: Admin Dashboard

Lesson Overview

students create an 'admin dashboard' style page from a mockup

Lesson Outline

The order of this outline doesn't need to be followed 100%, but the items listed here do need to show up in the lesson somewhere. If you feel like there has been an omission ask in Discord before expanding the scope of this lesson.

... should use everything we learned above. create a mockup, let students do it 🤷🏽

Acceptance Criteria

This is the definition of success. If the requirements here are not met, the work effort is not complete.

  • All items from the outline above are present in the lesson.
  • Lesson follows proper format
    • Section headings are ###
    • Code blocks use ~~~ and include a language name.
    • Lists are numbered.
  • Lesson has the following sections:
    • 'Learning Outcomes' at the beginning, optionally after a short introduction paragraph (relatively brief, give students an overview of what they're about to learn, with few specific details)
    • Assignment(optional) a list of resources to consume.
    • Practice(optional)
    • 'Additional Resources' (should exist even if it's blank)
    • 'Knowledge Check' (specific questions to test knowledge. Has details. Doesn't just parrot the Learning Outcomes. More of a spot-check, doesn't need to be exhaustive)
  • Lesson has been run through a spell-checker

Lesson: HTML/CSS - Positioning

Lesson Overview

it's crazy that we're saving this until this late until the curriculum. Rationale: When it's taught early, students waaaay over-rely on it when the actual use case for fixed/absolute positioning is pretty slim these days.

you should see how many google-homepages we get where everything is absolutely positioned on the screen lol.

Lesson Outline

The order of this outline doesn't need to be followed 100%, but the items listed here do need to show up in the lesson somewhere. If you feel like there has been an omission ask in Discord before expanding the scope of this lesson.

  • absolute positiong
  • fixed positioning
  • sticky positioning
  • make sure to cover how/when this stuff is actually used in the wild. consider practical applications.

Acceptance Criteria

This is the definition of success. If the requirements here are not met, the work effort is not complete.

  • All items from the outline above are present in the lesson.
  • Lesson follows proper format
    • Section headings are ###
    • Code blocks use ~~~ and include a language name.
    • Lists are numbered.
  • Lesson has the following sections:
    • 'Learning Outcomes' at the beginning, optionally after a short introduction paragraph (relatively brief, give students an overview of what they're about to learn, with few specific details)
    • Assignment(optional) a list of resources to consume.
    • Practice(optional)
    • 'Additional Resources' (should exist even if it's blank)
    • 'Knowledge Check' (specific questions to test knowledge. Has details. Doesn't just parrot the Learning Outcomes. More of a spot-check, doesn't need to be exhaustive)
  • Lesson has been run through a spell-checker

Lesson: Foundations - Flexbox

Lesson Overview

Potentially controversial to get to flex so early. I want to get students to grab onto this concept now before flooding their minds with box-shadows and border-radiuses and line-height etc.

Lesson Outline

The order of this outline doesn't need to be followed 100%, but the items listed here do need to show up in the lesson somewhere. If you feel like there has been an omission ask in Discord before expanding the scope of this lesson.

  • Flex containers
    • alignment/justification
      • flex-end/flex-start
      • centering
      • space-between, space-around
    • gap
    • direction
  • flex-children
    • flex-grow
    • flex-shrink
    • flex-basis
    • flex shorthand
  • PRACTICE: recreate some small 'components' using flex
    • common header layouts
    • a 'card' with header/footer/content
    • that 'icons with text under them' thing (screenshot at end of issue)

Acceptance Criteria

This is the definition of success. If the requirements here are not met, the work effort is not complete.

  • All items from the outline above are present in the lesson.
  • Lesson follows proper format
    • Section headings are ###
    • Code blocks use ~~~ and include a language name.
    • Lists are numbered.
  • Lesson has the following sections:
    • 'Learning Outcomes' at the beginning, optionally after a short introduction paragraph (relatively brief, give students an overview of what they're about to learn, with few specific details)
    • Assignment(optional) a list of resources to consume.
    • Practice(optional)
    • 'Additional Resources' (should exist even if it's blank)
    • 'Knowledge Check' (specific questions to test knowledge. Has details. Doesn't just parrot the Learning Outcomes. More of a spot-check, doesn't need to be exhaustive)
  • Lesson has been run through a spell-checker

icons with text lol
CleanShot 2021-08-11 at 14 03 56@2x

holy grail layout:
CleanShot 2021-08-11 at 14 05 12@2x

Lesson: Foundations - Positioning and Layout Introduction

Lesson Overview

Introduction to 'positioning and layout' and the box-model

Lesson Outline

The order of this outline doesn't need to be followed 100%, but the items listed here do need to show up in the lesson somewhere. If you feel like there has been an omission ask in Discord before expanding the scope of this lesson.

  • Introduction to Positioning
  • The Box Model
    • Everything is a rectangle, and all layout and positioning can be conceptualized by arranging and nesting these rectangles. The box model is the most important foundational concept here... it's pretty simple really, but we need to make sure students GET IT.
    • height/width
    • border/padding/margin
    • box-sizing
  • Normal document flow
  • block vs inline vs inline block

Acceptance Criteria

This is the definition of success. If the requirements here are not met, the work effort is not complete.

  • All items from the outline above are present in the lesson.
  • Lesson follows proper format
    • Section headings are ###
    • Code blocks use ~~~ and include a language name.
    • Lists are numbered.
  • Lesson has the following sections:
    • 'Learning Outcomes' at the beginning, optionally after a short introduction paragraph (relatively brief, give students an overview of what they're about to learn, with few specific details)
    • Assignment(optional) a list of resources to consume.
    • Practice(optional)
    • 'Additional Resources' (should exist even if it's blank)
    • 'Knowledge Check' (specific questions to test knowledge. Has details. Doesn't just parrot the Learning Outcomes. More of a spot-check, doesn't need to be exhaustive)
  • Lesson has been run through a spell-checker

Lesson: Foundations - Inspecting HTML and CSS

Lesson Overview

This doesn't have to go too far in depth, but knowing how to use the inspector is going to be crucial for the positioning lessons that come up next.

Lesson Outline

The order of this outline doesn't need to be followed 100%, but the items listed here do need to show up in the lesson somewhere. If you feel like there has been an omission ask in Discord before expanding the scope of this lesson.

  • How to access the inspector
  • Select and inspect specific elements
  • try out styles in the browser
  • tips/tricks

Acceptance Criteria

This is the definition of success. If the requirements here are not met, the work effort is not complete.

  • All items from the outline above are present in the lesson.
  • Lesson follows proper format
    • Section headings are ###
    • Code blocks use ~~~ and include a language name.
    • Lists are numbered.
  • Lesson has the following sections:
    • 'Learning Outcomes' at the beginning, optionally after a short introduction paragraph (relatively brief, give students an overview of what they're about to learn, with few specific details)
    • Assignment(optional) a list of resources to consume.
    • Practice(optional)
    • 'Additional Resources' (should exist even if it's blank)
    • 'Knowledge Check' (specific questions to test knowledge. Has details. Doesn't just parrot the Learning Outcomes. More of a spot-check, doesn't need to be exhaustive)
  • Lesson has been run through a spell-checker

Lesson: Foundations - HTML Foundations

Lesson Overview

This lesson is not intended to be all inclusive.. just get students up and running with HTML (no css) We'll go into detail about all the other important tags, attributes, accessibility concerns etc. in a later lesson.

Lesson Outline

The order of this outline doesn't need to be followed 100%, but the items listed here do need to show up in the lesson somewhere. If you feel like there has been an omission ask in Discord before expanding the scope of this lesson.

  • Basic Syntax, tags and elements
  • Basic Boilerplate
  • Most common tags
    • div
    • p, em, strong
    • section headings (h1, h2, etc)
    • lists (ul, li, ol)
    • img
    • anchors, buttons
      • mention that buttons are of limited use until you learn JS.
  • Other tags: we are specifically not teaching other common tags here (they'll come later) but we should at least link to a resource that lists them all so students are aware of them.
  • Practice: Recipe
    • use as many of the above tags as possible to make a basic recipe page.
    • should have an image, section headings, descriptive text, lists (ingredients, steps) and links.
    • consider mocking one up and providing a screenshot for students to emulate.

Acceptance Criteria

This is the definition of success. If the requirements here are not met, the work effort is not complete.

  • All items from the outline above are present in the lesson.
  • Lesson follows proper format
    • Section headings are ###
    • Code blocks use ~~~ and include a language name.
    • Lists are numbered.
  • Lesson has the following sections:
    • 'Learning Outcomes' at the beginning, optionally after a short introduction paragraph (relatively brief, give students an overview of what they're about to learn, with few specific details)
    • Assignment(optional) a list of resources to consume.
    • Practice(optional)
    • 'Additional Resources' (should exist even if it's blank)
    • 'Knowledge Check' (specific questions to test knowledge. Has details. Doesn't just parrot the Learning Outcomes. More of a spot-check, doesn't need to be exhaustive)
  • Lesson has been run through a spell-checker

Unit Testing Part 1: Basics

Summary

We need a lesson to introduce students to what unit testing is and how to unit test simple query methods.

Acceptance Criteria

Lesson content should cover:

  • What are unit tests?
  • Testing Query methods.
  • Testing Different Paths through methods with context.
  • Don't test private methods.
  • Exercise: Finish unit testing more of the example project methods.
  • Exercise: Unit test a few ready made value object classes.

Lesson: HTML/CSS - Animation

Lesson Overview

ANimation!

Lesson Outline

The order of this outline doesn't need to be followed 100%, but the items listed here do need to show up in the lesson somewhere. If you feel like there has been an omission ask in Discord before expanding the scope of this lesson.

  • transitions
    • include warning about 'repaints' and animating transforms/opacity
  • keyframe animations
  • Practice: button-hover, dropdown, pop-up modal

Acceptance Criteria

This is the definition of success. If the requirements here are not met, the work effort is not complete.

  • All items from the outline above are present in the lesson.
  • Lesson follows proper format
    • Section headings are ###
    • Code blocks use ~~~ and include a language name.
    • Lists are numbered.
  • Lesson has the following sections:
    • 'Learning Outcomes' at the beginning, optionally after a short introduction paragraph (relatively brief, give students an overview of what they're about to learn, with few specific details)
    • Assignment(optional) a list of resources to consume.
    • Practice(optional)
    • 'Additional Resources' (should exist even if it's blank)
    • 'Knowledge Check' (specific questions to test knowledge. Has details. Doesn't just parrot the Learning Outcomes. More of a spot-check, doesn't need to be exhaustive)
  • Lesson has been run through a spell-checker

Lesson: HTML/CSS - Floats

Lesson Overview

Floats are a little bit old-fashioned.. but they have their place and deserve a mention. This lesson can be pretty short.

Lesson Outline

The order of this outline doesn't need to be followed 100%, but the items listed here do need to show up in the lesson somewhere. If you feel like there has been an omission ask in Discord before expanding the scope of this lesson.

  • feel free to discuss the fact that floats were used for layout back in the day... but stray FAR away from actually recommending them for anything besides sticking inline elements inside a paragraph.
  • floats remove content from the normal document flow!
  • cover shapes with shape-outside, and the chrome shape-editor. Pretty niche behavior.. but it's neat and worth mentioning.

Acceptance Criteria

This is the definition of success. If the requirements here are not met, the work effort is not complete.

  • All items from the outline above are present in the lesson.
  • Lesson follows proper format
    • Section headings are ###
    • Code blocks use ~~~ and include a language name.
    • Lists are numbered.
  • Lesson has the following sections:
    • 'Learning Outcomes' at the beginning, optionally after a short introduction paragraph (relatively brief, give students an overview of what they're about to learn, with few specific details)
    • Assignment(optional) a list of resources to consume.
    • Practice(optional)
    • 'Additional Resources' (should exist even if it's blank)
    • 'Knowledge Check' (specific questions to test knowledge. Has details. Doesn't just parrot the Learning Outcomes. More of a spot-check, doesn't need to be exhaustive)
  • Lesson has been run through a spell-checker

Lesson: Html/css - SVG

Lesson Overview

We need a lesson that covers svg!

Lesson Outline

The order of this outline doesn't need to be followed 100%, but the items listed here do need to show up in the lesson somewhere. If you feel like there has been an omission ask in Discord before expanding the scope of this lesson.

  • Benefits of SVG over other graphics formats.
  • basic format/syntax
    • be sure to note that nobody actually codes these by hand. Not uncommon for people to edit the code as needed, but nobody is drawing complex shapes by writing svg code.
  • basic usage (inline/imported)
  • sources for svg icons/images

Acceptance Criteria

This is the definition of success. If the requirements here are not met, the work effort is not complete.

  • All items from the outline above are present in the lesson.
  • Lesson follows proper format
    • Section headings are ###
    • Code blocks use ~~~ and include a language name.
    • Lists are numbered.
  • Lesson has the following sections:
    • 'Learning Outcomes' at the beginning, optionally after a short introduction paragraph (relatively brief, give students an overview of what they're about to learn, with few specific details)
    • Assignment(optional) a list of resources to consume.
    • Practice(optional)
    • 'Additional Resources' (should exist even if it's blank)
    • 'Knowledge Check' (specific questions to test knowledge. Has details. Doesn't just parrot the Learning Outcomes. More of a spot-check, doesn't need to be exhaustive)
  • Lesson has been run through a spell-checker

Lesson: HTML/CSS - More CSS

Lesson Overview

Here's where we cover all the decorative css properties that we didn't cover in foundations. This is mostly decorative stuff.. don't worry about grid or positioning here.

Lesson Outline

The order of this outline doesn't need to be followed 100%, but the items listed here do need to show up in the lesson somewhere. If you feel like there has been an omission ask in Discord before expanding the scope of this lesson.

For this lesson, find a reference that covers everything and link to that, and then specifically call out the most common/important ones.
this document is awesome.. but maybe not the most friendly. feel free to find another one.

add a note that these things are best googled instead of remembered. Once you know a thing is possible with CSS, searching "how to add shadow css" is easier than trying to memorize everything lol.

  • default styles (browsers all inject styles into the various base tags)
    • css resets
  • css units (px, %, em, rem, vh,vw
  • important ones:
    • background (and all the related properties like, bg-size, bg-repeat
    • borders (and related properties, border-radius)
    • box-shadow
    • min/max-height and width
    • overflow
    • opacity
    • list-style-type
  • practice: some basic component styles
    • style some buttons!
    • a couple cards/modals etc.
    • ?

Acceptance Criteria

This is the definition of success. If the requirements here are not met, the work effort is not complete.

  • All items from the outline above are present in the lesson.
  • Lesson follows proper format
    • Section headings are ###
    • Code blocks use ~~~ and include a language name.
    • Lists are numbered.
  • Lesson has the following sections:
    • 'Learning Outcomes' at the beginning, optionally after a short introduction paragraph (relatively brief, give students an overview of what they're about to learn, with few specific details)
    • Assignment(optional) a list of resources to consume.
    • Practice(optional)
    • 'Additional Resources' (should exist even if it's blank)
    • 'Knowledge Check' (specific questions to test knowledge. Has details. Doesn't just parrot the Learning Outcomes. More of a spot-check, doesn't need to be exhaustive)
  • Lesson has been run through a spell-checker

Feature: Team Page

Title Author Date
Team Page Kevin 27/07/2021

Team Page

Summary

A page on the site that will provide details about the team behind TOP.

Motivation

  • It will help give credibility to the platform by being transparent about the team behind the project.
  • It will help give credibility to the curriculum as it will show the project is being run by a team with industry experience.
  • It will provide a place where we can be transparent about the process of becoming a maintainer so anyone interesting in joining the team can find out what they need to do.
  • It could potentially be used to highlight the roles and skill gaps we need filled within the team.
  • Replaces the out of date hall of fame section on the contributing page to give deserved recognition to the volunteers behind TOP.

Suggested implementation

A standard team page like the templates here would do.

Each team member would have an avatar, a brief description and possible social links. We could include how long they've been working in the industry and/or TOP and what they've mostly worked on with TOP.

Splitting the page into two sections for the current team and past team members would be good for giving recognition to past team members who have helped make TOP what is is and fulfil the same purpose as the current HOF section does.

Drawbacks

  • Potential for doxing team members who would rather remain private. We shouldn't have any requirements for anyone listed on the team page to use a real avatar of themselves or to provide personal details about where they work or social links if they'd rather not include any of those.

Alternatives

We could update the HOF on the contributing page instead.

Additional

Most team members have naturally fallen into different roles. But we haven't formally discussed it. It may be a good idea to formally agree on roles if we are want to include that information about each team member.

Examples
Ruby on Rails team page
I like how they list the country of each maintainer and how long they've been part of the team. It shows they are from a wide range of cultures and the project has stability with longer serving members while also growing with members joining more recently.
Screenshot 2022-10-30 at 12 41 10

Crystal Lang Team
I like the alumni section and the part about all the other contributors not part of the team - giving recognition to everyone past and present.
Screenshot 2022-10-30 at 12 43 02

.NET Path

Title Author Date
.NET Path/Course Zachary Baird 07/27/2021

A new C#/.NET path for The Odin Project

Summary

This is an idea/proposition to start writing a .NET path for The Odin Project. .NET development can be written in a couple languages, but this course will focus on using C#.

Motivation

This new path would increase the amount of content on the site and appeal to students who may want to learn C#/.NET. There are a large number of .NET positions available in the industry across the world, and providing a curriculum for self-learners to dive into the .NET ecosystem would be - I think - a great edition to The Odin Project.

With .NET 5 being cross-platform and as performant as ever, learning C# on a *nix system should now mesh well with The Odin Project's broader scope.

Suggested implementation

This course will be written by primarily myself and outside contributors who wish to help me. I've got some buddies I know who are enthusiastic about helping contribute to Odin and helping students find jobs who have volunteered their time to help me write and review this course.

Drawbacks

There are some drawbacks to this path I think we may run into I want to discuss:

  • We may get an influx of students who insist that The Odin Project should support Windows. The intention of this course is not to open up this can of worms, but to provide a way for self-learners to experience C# and .NET development. That being said, I can see the team being burnt out with this question very quickly.
  • As far as I'm aware, not much of the team is very experienced with C#, although some have exposure to it. As a result, supporting the course may be challenging in the context of maintainer resources. However, I do believe this problem will solve itself via A) maintainers learning C# as byproduct of reviewing the lesson content as it's written & B) exceptional students and community members who've followed the C# course elevating to maintainer status or contributing to Odin in their free time.
  • C#/.NET development is not traditionally done on a Linux system. While .NET is commonly performed on Mac machines with Visual Studio, we will need to be cognizant that the normative .NET development experience in the industry is on Windows 10. I think we can account for this by - at the conclusion of the .NET course where they build Facebook - mentioning that Windows development is usually performed on Windows via the Visual Studio IDE (ie. not VSCode). After learning C# without Visual Studio holding their hands, students should be able to set up a Windows dev environment no problem.

Additional

This is something I've started taking the baby steps for already. A lesson outline is being drafted that will heavily mirror the Ruby on Rails path. I suspect my acquaintances, colleagues and myself will be the primary contributors on this idea. As a result, I do not foresee any strain being laid on the Odin team unless maintainers want to try their hand at helping write lesson content. The bulk of the work I predict maintainers helping with most is review, proofreading, and test-driving the course.

Lesson: HTML/CSS - HTML Forms

Lesson Overview

This lesson will explain the importance of commit messages, the best practices for commit messages, when to commit, and how to set VSCode as the default Git commit editor. We are currently planning to put this lesson between the dev tools 1 and Google homepage lessons in Foundations.

Lesson Outline

The order of this outline doesn't need to be followed 100%, but the items listed here do need to show up in the lesson somewhere. If you feel like there has been an omission ask in Discord before expanding the scope of this lesson.

  • more HTML tags
  • semantic HTML (this is covered in more depth during the a11y lessons... but we should at least mention that it's not ideal to just use divs for everything lol)
  • forms

Acceptance Criteria

This is the definition of success. If the requirements here are not met, the work effort is not complete.

  • All items from the outline above are present in the lesson.
  • Lesson follows proper format
    • Section headings are ###
    • Code blocks use ~~~ and include a language name.
    • Lists are numbered.
  • Lesson has the following sections:
    • 'Learning Outcomes' at the beginning, optionally after a short introduction paragraph (relatively brief, give students an overview of what they're about to learn, with few specific details)
    • Assignment(optional) a list of resources to consume.
    • Practice(optional)
    • 'Additional Resources' (should exist even if it's blank)
    • 'Knowledge Check' (specific questions to test knowledge. Has details. Doesn't just parrot the Learning Outcomes. More of a spot-check, doesn't need to be exhaustive)
  • Lesson has been run through a spell-checker

[TEMPLATE] - Idea Format Sample

Title Author Date
Idea title Your name today

IDEA NAME

Summary

Brief explanation of the idea. Feel free to keep the other parts of the template blank until you're ready to have it discussed. But if you want core/maintainers to discuss the idea, please make sure to provide supporting materials.

Motivation

Explain the motivation behind this proposal. What is the purpose of this change or implementation? What does it solve? What is the expected outcome of this proposal?

Make sure to express the motivation of this proposal in the best way you can so that if the change or implementation that is suggested here is not accepted, this motivation can be used to come up with an alternative solution.

Suggested implementation

Suggested implementation for the proposal, how will this be implemented? if you like, include examples or diagrams that can help explain. If it is a change in flow or management, specify what it should be changed to and how will that look. This doesnt have to be detailed implementation although it is encouraged but at the very least you as the author of the proposal should have an implementation idea in mind.

Drawbacks

Are there any drawbacks to this proposal? consider the following:

  • Complexities or time consuming.
  • Amount of people needed to develop or availability of your own time.
  • Impact of the current state.
  • Will users need to change their flow? in what way?

Alternatives

Are there any alternative implementations to this? What else can be done?

Additional

This can be any unanswered questions, things that still need to considered or solved about the implementation, any reference links to the initial ideation such as a Discourse Forum, discussions or anything else.

Odin Test Bot

Title Author Date
Odin Test Bot Kevin 02/08/2021

Odin Test Bot

Summary

Create a test instance of Odin bot so maintainers and outside contributors can easily test new changes.

Motivation

  • Currently maintainers need to spin up instances of Odin bot locally and use personal servers to test changes. This is painful and time consuming.

  • Outside contributors are unable to test anything related to the points api as they do not have the api key.

Suggested implementation

  • Create a test version of Odin Bot on Heroku.
  • Hook it up to the points api on the staging server which will provide an inconsequential endpoint outside contributors can use.

Additional

Lesson: HTML/CSS - Responsive CSS

Lesson Overview

Responsive css... making sure your stuff works well on all devices

Lesson Outline

The order of this outline doesn't need to be followed 100%, but the items listed here do need to show up in the lesson somewhere. If you feel like there has been an omission ask in Discord before expanding the scope of this lesson.

  • viewport meta tag
  • natural responsivity (i.e. flexing, grid, min/max-width)
  • responsive images
  • media queries
  • project (provide mockup/design)

Acceptance Criteria

This is the definition of success. If the requirements here are not met, the work effort is not complete.

  • All items from the outline above are present in the lesson.
  • Lesson follows proper format
    • Section headings are ###
    • Code blocks use ~~~ and include a language name.
    • Lists are numbered.
  • Lesson has the following sections:
    • 'Learning Outcomes' at the beginning, optionally after a short introduction paragraph (relatively brief, give students an overview of what they're about to learn, with few specific details)
    • Assignment(optional) a list of resources to consume.
    • Practice(optional)
    • 'Additional Resources' (should exist even if it's blank)
    • 'Knowledge Check' (specific questions to test knowledge. Has details. Doesn't just parrot the Learning Outcomes. More of a spot-check, doesn't need to be exhaustive)
  • Lesson has been run through a spell-checker

[TEMPLATE] - User story / work item

The purpose of using this template is to break down large initiatives into smaller, independent pieces. The idea is that as we break down the big initiatives, people are able to contribute efficiently to meet acceptance criteria set in the ticket.

The work item should utilize these suggested components, but use your best judgement:

Summary

What is the purpose of this deliverable? How will it bring us closer to finishing the initiative?

Example: We need to create a logo for the TOP styled leggings. We can use the proceeds to raise the funds for hosting costs.

Acceptance Criteria

This is the definition of success. If the requirements here are not met, the work effort is not complete.
Example:

  • The design should be on both legs.
  • The design should be above knee, but below the hip.
  • The colors should include the most annoying shades of green and orange.

Exercises for RSpec Basics

Summary

We need exercises to reinforce RSpec Matchers.

Acceptance Criteria

Lesson content should cover:

  • Exercises for matchers covered in the lessons.
  • Exercises for a few more matchers students may find useful.

Official TOP Blog

It has been requested that we consider adding an official Odin blog where core/maintainers can write about non curriculum content.

Lesson: HTML/CSS - CSS Functions (calc, min, max etc.)

Lesson Overview

A fairly Short lesson about css functions.

Lesson Outline

The order of this outline doesn't need to be followed 100%, but the items listed here do need to show up in the lesson somewhere. If you feel like there has been an omission ask in Discord before expanding the scope of this lesson.

  • calc
  • max
  • min
  • clamp
  • suggested usages for the above.

Acceptance Criteria

This is the definition of success. If the requirements here are not met, the work effort is not complete.

  • All items from the outline above are present in the lesson.
  • Lesson follows proper format
    • Section headings are ###
    • Code blocks use ~~~ and include a language name.
    • Lists are numbered.
  • Lesson has the following sections:
    • 'Learning Outcomes' at the beginning, optionally after a short introduction paragraph (relatively brief, give students an overview of what they're about to learn, with few specific details)
    • Assignment(optional) a list of resources to consume.
    • Practice(optional)
    • 'Additional Resources' (should exist even if it's blank)
    • 'Knowledge Check' (specific questions to test knowledge. Has details. Doesn't just parrot the Learning Outcomes. More of a spot-check, doesn't need to be exhaustive)
  • Lesson has been run through a spell-checker

Organizing JS Update

Title Author Date
Update Organizing JS Cody Loyd 17 Sep 2021

Update Organizing JS

Summary

Our 'organizing JS' section could use a little bit of....... organization.

Essentially we need to clarify what we actually recommend learners use for their projects moving forward.

Motivation

We've noticed some confusion in the chat about which patterns should be used. The 'Organizing JS' section presents several ways of creating and manipulating objects/modules/classes etc. and some learners are having a hard time reconciling all of these options once they've gotten to the end.

Suggested implementation

Need to do a little more brainstorming on actual solutions here... but we should rewrite or reorganize those lessons to more clearly communicate what we're doing.

What we're doing

In a nutshell, those lessons present several building blocks and methods of organizing JS (i.e. doing object-oriented programming) before presenting our recommended modern method, ES Modules (import, export) and classes.

We present these methods for multiple reasons including improving general language skills (learning how to do factory functions really solidifies some fundamental JS knowledge), learning how classes/modules work behind the scenes (i.e. classes are just some sugar over normal constructors/prototypes), and exposing learners to patterns they are likely to encounter in the wild (the IIFE module pattern, object constructors and even factories are pretty common in the real world).

Suggestions:

Because of the aforementioned reasons, I think that information should stay... but:

  • We should go over the whole thing in an attempt to more clearly communicate WHY each pattern is taught and to keep the goal in mind.
  • We should also make it more clear that the recommended solution IS the recommended solution when we get to it.
  • We should add a little more detail regarding 'design patterns' before the TODO list project so that it's clear how that project should be designed and organized before they start.

Drawbacks

Are there any drawbacks to this proposal? consider the following:

  • The concrete solution is unclear at this point, needs more reflection.
  • Someone's gotta write it.

Alternatives

We could rip out the confusing stuff and just teach the recommended solution. Not a fan of this idea.. but it would be more clear.

Lesson: HTML/CSS - Browser Compatibility

Lesson Overview

A quick lesson that covers browser compatibility, a little bit of history and a link to caniuse

Lesson Outline

The order of this outline doesn't need to be followed 100%, but the items listed here do need to show up in the lesson somewhere. If you feel like there has been an omission ask in Discord before expanding the scope of this lesson.

  • Browser compatibility in general
    • How browser releases work
    • how new CSS features find their way into browsers
  • When is it safe to use new features
    • checking compatibility (caniuse)
    • when compatibility matters.
  • Mobile browsers
    • anything on ios is technically safari
    • the device emulator in chrome or firefox doesn't emulate anything besides screen size

Acceptance Criteria

This is the definition of success. If the requirements here are not met, the work effort is not complete.

  • All items from the outline above are present in the lesson.
  • Lesson follows proper format
    • Section headings are ###
    • Code blocks use ~~~ and include a language name.
    • Lists are numbered.
  • Lesson has the following sections:
    • 'Learning Outcomes' at the beginning, optionally after a short introduction paragraph (relatively brief, give students an overview of what they're about to learn, with few specific details)
    • Assignment(optional) a list of resources to consume.
    • Practice(optional)
    • 'Additional Resources' (should exist even if it's blank)
    • 'Knowledge Check' (specific questions to test knowledge. Has details. Doesn't just parrot the Learning Outcomes. More of a spot-check, doesn't need to be exhaustive)
  • Lesson has been run through a spell-checker

Lesson: HTML/CSS - Final Project (not ready for work yet)

Lesson Overview

need to pick a project for this.

Lesson Outline

The order of this outline doesn't need to be followed 100%, but the items listed here do need to show up in the lesson somewhere. If you feel like there has been an omission ask in Discord before expanding the scope of this lesson.

....

Acceptance Criteria

This is the definition of success. If the requirements here are not met, the work effort is not complete.

  • All items from the outline above are present in the lesson.
  • Lesson follows proper format
    • Section headings are ###
    • Code blocks use ~~~ and include a language name.
    • Lists are numbered.
  • Lesson has the following sections:
    • 'Learning Outcomes' at the beginning, optionally after a short introduction paragraph (relatively brief, give students an overview of what they're about to learn, with few specific details)
    • Assignment(optional) a list of resources to consume.
    • Practice(optional)
    • 'Additional Resources' (should exist even if it's blank)
    • 'Knowledge Check' (specific questions to test knowledge. Has details. Doesn't just parrot the Learning Outcomes. More of a spot-check, doesn't need to be exhaustive)
  • Lesson has been run through a spell-checker

Lesson: HTML/CSS - Responsive CSS

Lesson Overview

bigger lesson covering everythign responsive

Lesson Outline

The order of this outline doesn't need to be followed 100%, but the items listed here do need to show up in the lesson somewhere. If you feel like there has been an omission ask in Discord before expanding the scope of this lesson.

  • WHAT IS RESPONSIVE (and what isn't responsive)
  • relative units
  • using grid/flex to make naturally responsive material
  • responsive images
  • media-queries

Acceptance Criteria

This is the definition of success. If the requirements here are not met, the work effort is not complete.

  • All items from the outline above are present in the lesson.
  • Lesson follows proper format
    • Section headings are ###
    • Code blocks use ~~~ and include a language name.
    • Lists are numbered.
  • Lesson has the following sections:
    • 'Learning Outcomes' at the beginning, optionally after a short introduction paragraph (relatively brief, give students an overview of what they're about to learn, with few specific details)
    • Assignment(optional) a list of resources to consume.
    • Practice(optional)
    • 'Additional Resources' (should exist even if it's blank)
    • 'Knowledge Check' (specific questions to test knowledge. Has details. Doesn't just parrot the Learning Outcomes. More of a spot-check, doesn't need to be exhaustive)
  • Lesson has been run through a spell-checker

Lesson: HTML/CSS - Transforms

Lesson Overview

it's in the title <3

Lesson Outline

The order of this outline doesn't need to be followed 100%, but the items listed here do need to show up in the lesson somewhere. If you feel like there has been an omission ask in Discord before expanding the scope of this lesson.

  • Transforms
    • note that these are useful for animations, which will be taught in the next lesson
    • translate
    • scale
    • rotate
    • find a reference with the rest of them.

Acceptance Criteria

This is the definition of success. If the requirements here are not met, the work effort is not complete.

  • All items from the outline above are present in the lesson.
  • Lesson follows proper format
    • Section headings are ###
    • Code blocks use ~~~ and include a language name.
    • Lists are numbered.
  • Lesson has the following sections:
    • 'Learning Outcomes' at the beginning, optionally after a short introduction paragraph (relatively brief, give students an overview of what they're about to learn, with few specific details)
    • Assignment(optional) a list of resources to consume.
    • Practice(optional)
    • 'Additional Resources' (should exist even if it's blank)
    • 'Knowledge Check' (specific questions to test knowledge. Has details. Doesn't just parrot the Learning Outcomes. More of a spot-check, doesn't need to be exhaustive)
  • Lesson has been run through a spell-checker

HTML / CSS Course Update

Title Author Date
Team Page Cody 06/08/2021

HTML/CSS rewrite

Summary

It's time to rework our HTML/CSS material from the ground up.

Motivation

  • Our current materials have become stale and out-of-date. They do not reflect best practices and modern CSS.
  • We over-rely on FreeCodeCamp, with which many students express frustration.
  • A very common complaint is that students are not good at, or not prepared to use CSS properly when it comes time to do projects.
  • Offloading the entire learning experience to a single resource (FCC) is not very odin-like
  • Overall, we can do better!

Suggested implementation

TLDR: outline a course flow, create issues for each lesson. write lessons.

Currently we have a pretty good idea of what all needs to go in this course. This document is currently the best and most complete effort https://docs.google.com/document/d/1XZXFAoADMTCF-nzvSPrbP5HwjM-pMfJ4nZVe7vpTCpk/edit#heading=h.rtv866lwog4w

  • We need to go through it once again, iron out any wrinkles and finalize it as an outline of everything that needs to be written. It's in pretty good shape at the moment so this shouldn't be a huge effort.
  • We need to come to a consensus on what our MVP is. Personally I'll suggest we go ahead and plan for the entire project, but then prioritize and complete and deploy the MVP items as a first milestone.
  • Individual sections should be broken into issues with clear objectives such that anyone can research and write......
  • ....at which point we can begin writing lessons.

Drawbacks

Writing lessons is time consuming. Maybe our efforts could be spent on something else?

Alternatives

We could just massage what we have instead of starting from the ground up. the FCC lessons could be broken up, with added context and some interstitial projects.

Additional

EDIT: see this issue-comment for a more detailed and accurate proposal for placement of this material inside the curriculum #15 (comment)

ORIGINAL TEXT:
We need to decide where this material is going to fit in the curriculum. Currently we have our stuff split with some of the very basics mentioned in the foundations course, and a full HTML/CSS course at the very end. I'm not convinced this is our best way forward, but I also do not have much clarity on what the best way forward actually should be.

If we keep our current arrangement we will at least need to decide which items belong in the 'foundations' course, and which can go in the full course. We'll also need to decide (and write/outline) what needs to be reviewed in the full course. I am of the opinion that at least half of this content (up until 'positioning') is 'foundational'... which doesn't really leave much content for the full course.

Another option is to front-load the HTML and CSS course in our tracks instead of saving it till the end. I'm not sure I'm a fan of this either, however. The rationale for saving it till the end has been to get students to writing actual code ASAP.... and I think that's still valid. I do not know how it would change our drop-off rate if we had an extended HTML/CSS course up front.

A third option is to keep the 'foundations' css course very basic... like maybe just the HTML content and CSS basics (linking styles, selectors and basic rules like font styles and colors) and then pepper in a few smaller modules between the larger courses.

EDIT: (this example has been dismissed, it won't work well)

Consider this example:

  • Foundations (contains HTML BASICS and CSS BASICS)
  • CSS Module 1 (contains more advanced HTML, and CSS Layout/Positioning)
  • Javascript (contains no additional css material)
  • CSS Module 2 (contains forms, responsive CSS and 'advanced' CSS)
  • NODEJS

The actual breakdown and placement are somewhat arbitrary here, so don't get all up-in-arms about the order just yet.

Personally, I think this might be our best plan. It offers the most flexibility with pacing by letting our students get past the basics of HTML and into JS quickly during foundations.. but also allows for flexibility with the placement of other useful foundational content. We'll need to hash out the details and decide what belongs in each module, but I do not think that it represents an increase in the amount of work.

Additionally breaking it up like this may help us line out an MVP for milestone 1. For instance (again, this is only an example.. dont' get hung up on the specifics), we could keep (but reduce!) FCC for the 'foundations' lessons, and keep the current HTML/CSS course (perhaps edited/reduced) for module 2, and focus mainly on writing Module 1 for our first milestone... then after that is deployed, focus on reworking foundations, and then module 2.

Add MongoDB University Intro Course to Node Path

Title Author Date
Add MongoDB University Course to Node Tatiana 9.20.21

Add MongoDB University Intro Course to Node Path

Summary

The Node course should have a standalone MongoDB section, leveraging the official MongoDB Mongo University course. The course uses a real MongoDB Atlas instance, and uses sandboxes to make queries. These sandboxes are assignments which are checked for accuracy.

Motivation

We get a significant amount of learners who believe that the Node course lacks a database because it is not broken out into its own section. Additionally, the existing material leverages an ORM, and students "know" MongoDB due to that ORM, but this abstracts away a lot of the underlying DB concepts. Additionally, this brings some parity with the Ruby course which has a section focused solely on learning SQL standalone.

Suggested implementation

A new section titled "MongoDB" will be added between the introductory section and the "Express and MongoDB" section. The existing "Express and MongoDB" section will be retitled with possibly "Express and Mongoose".

The "MongoDB" section will include one lesson titled "MongoDB Basics"

Drawbacks

  • Complexities or time consuming: It shouldn't be time consuming, it is one lesson with an introductory description of MongoDB and the course assignment, and renaming the following section.
  • Amount of people needed to develop or availability of your own time: 1 person, should be < 8 hours total.
  • Impact of the current state: It may confuse those in the middle of the course similarly to those who were mid-Foundations with the HTML/CSS rollout.
  • Will users need to change their flow? in what way?: See above. We should use the same guidance we used for HTML/CSS (go back and do this).

Alternatives

Are there any alternative implementations to this? What else can be done?
At this time, the other alternative is writing the content from scratch.

Additional

Discussion: https://discord.com/channels/505093832157691914/753463351568498729/889517929631207435

End-to-end Testing

Summary

We need a lesson to introduce students to end-to-end testing and what to test with it.

Acceptance Criteria

Lesson content should cover:

  • What are end-to-end tests?
  • What to test - test the happy path and don't try to cover all edge cases.
  • The testing pyramid.
  • Exercise: write some more end-to-end tests for the example project.

Git Commits Lesson

Lesson Overview

This lesson will explain the importance of commit messages, the best practices for commit messages, when to commit, and how to set VSCode as the default Git commit editor. We are currently planning to put this lesson between the dev tools 1 and Google homepage lessons in Foundations.

Lesson Outline

  • Explain the importance of commit messages
  • Best practices for commit messages
  • when to commit
  • How to set VSCode as the default Git commit editor

Acceptance Criteria

This is the definition of success. If the requirements here are not met, the work effort is not complete.

  • Explain the importance of commit messages
    • Why it is important to have good commit messages
    • How it can help you stand apart when you are applying for jobs down the line
    • How it is useful to yourself and other devs you are working with for your commit messages to be good
  • When to commit
    • Article/explanation on when it is good to commit
  • Best practices for commit messages
    • Write out the best practices and include the link to an article
  • How to set VSCode as the default Git commit editor -Zach added this to Git Basics
    • Benefits of this (can use VSCode Spell check, easier to edit, character length)
    • Directions from COC that Briggs linked us -Zach added this to Git Basics
  • Clean up current Git lesson in Foundations to remove any duplicate information in that lesson that is covered here
  • Link to this lesson in all projects in Foundations as a reminder/refresher

Git Branching Basics Lesson

Overview

We need a lesson (or addition to an existing lesson) that explains the basics of branching to students. It should undo some of what was done in this PR and equip learners with the skills needed to use branching on the UI building portion of RPS. This lesson should be located immediately before (or as part of) the revisiting RPS project in foundations.

Acceptance Criteria

  • The fork and branch resource added in this PR is removed and all links pointing back to it in future lessons are also removed/updated to coincide with the new content
  • Content informs students on (the basics of) what branches are (i.e. they aren't folders)
  • Content explains basic commands/workflow to branch (i.e. how to make a branch, switch branches, merge)
    - [ ] Content explains what a merge conflict is, and how to resolve a basic merge conflict

Misc/braindump (things that would be good additions but need a home)

the difference between cloning and adding a remote, and when you should do each - YES put in git basics

the difference between cloning and forking, and when you should do each - YES put in PR and open source workflow lesson

explanations of the more complicated error messages, and maybe some stuff about the hints it gives that scare people - YES put in commit lesson

deleting the .git directory - NO

Experience making PRs and experience reviewing/approving/merging PRs. - Rachel - PROBABLY but no idea how to implement. Revist in the future.

I propose Zach proposes that the Git Basic lesson (https://www.theodinproject.com/paths/foundations/courses/foundations/lessons/git-basics) be partially redone to include having a README generated when the repo is created on GitHub. This would avoid them creating an empty GH repo and misunderstanding the instructions on the site (initializing git in their root directory) by not having any instructions on the site at all at this point. They'd hopefully go back to the curriculum and move on to step 5. - YES

I Zach also proposes for creation of a repos folder [in the Git Basics lesson], once again to avoid initializing git accidentally in the root folder. At least if it's initialized in repos there is a much smaller risk of important file loss. - YES - in Git Basics, mention to use in recipe project

Don't put multiple projects in one repo/have nested repos - YES put in git basics and mention in recipe project

Lesson: HTML/CSS - Frameworks and Preprocessors

Lesson Overview

Just an overview of frameworks and preprocessors.

Lesson Outline

The order of this outline doesn't need to be followed 100%, but the items listed here do need to show up in the lesson somewhere. If you feel like there has been an omission ask in Discord before expanding the scope of this lesson.

  • Definition of frameworks
  • pro/con of using them, when you might want to use them
  • overview of popular frameworks
  • definition of preprocessor
  • pros/cons
  • features you might want to take advantage of

Acceptance Criteria

This is the definition of success. If the requirements here are not met, the work effort is not complete.

  • All items from the outline above are present in the lesson.
  • Lesson follows proper format
    • Section headings are ###
    • Code blocks use ~~~ and include a language name.
    • Lists are numbered.
  • Lesson has the following sections:
    • 'Learning Outcomes' at the beginning, optionally after a short introduction paragraph (relatively brief, give students an overview of what they're about to learn, with few specific details)
    • Assignment(optional) a list of resources to consume.
    • Practice(optional)
    • 'Additional Resources' (should exist even if it's blank)
    • 'Knowledge Check' (specific questions to test knowledge. Has details. Doesn't just parrot the Learning Outcomes. More of a spot-check, doesn't need to be exhaustive)
  • Lesson has been run through a spell-checker

RSpec Part 1: Basics

Summary

We need a lesson to introduce students to the basic RSpec syntax.

Acceptance Criteria

Lesson content should cover:

  • Installing RSpec.
  • Structuring test files with describes and it blocks.
  • Expectations
  • Matchers
  • Anatomy of a test.

TheOdinProject/curriculum#22519

Lesson: Foundations - Final Project

Lesson Overview

This is going to replace the classic 'google homepage' assignment. RIP good buddy.

Haven't yet decided how we're going to present projects like this.... will update issue once that's decided.,

Lesson Outline

The order of this outline doesn't need to be followed 100%, but the items listed here do need to show up in the lesson somewhere. If you feel like there has been an omission ask in Discord before expanding the scope of this lesson.

  • Project: recreate a basic page with dummy content.
  • pick something basic in the vein of these templates https://startbootstrap.com/templates
  • create mockup for students to use during dev.

Acceptance Criteria

This is the definition of success. If the requirements here are not met, the work effort is not complete.

  • All items from the outline above are present in the lesson.
  • Lesson follows proper format
    • Section headings are ###
    • Code blocks use ~~~ and include a language name.
    • Lists are numbered.
  • Lesson has the following sections:
    • 'Learning Outcomes' at the beginning, optionally after a short introduction paragraph (relatively brief, give students an overview of what they're about to learn, with few specific details)
    • Assignment(optional) a list of resources to consume.
    • Practice(optional)
    • 'Additional Resources' (should exist even if it's blank)
    • 'Knowledge Check' (specific questions to test knowledge. Has details. Doesn't just parrot the Learning Outcomes. More of a spot-check, doesn't need to be exhaustive)
  • Lesson has been run through a spell-checker

Lesson: HTML/CSS - Grid

Lesson Overview

Covers grid lol.

Lesson Outline

The order of this outline doesn't need to be followed 100%, but the items listed here do need to show up in the lesson somewhere. If you feel like there has been an omission ask in Discord before expanding the scope of this lesson.

  • Grid containers:
    • Grid-template-columns / grid-template-rows
    • Grid-template-areas
    • Shorthand (grid-template)
    • Gap (row-gap, column-gap)
  • Grid children
    • Column-start, column-end, row-start, row-end.
      • Also shorthand
    • Grid-area
  • Special units and functions
    • Fr
    • Repeat
    • Auto-fill
    • auto-fit
    • Min, max, minmax
  • Practice.. Similar to ‘flex’ section. Do some components and page layout.

Acceptance Criteria

This is the definition of success. If the requirements here are not met, the work effort is not complete.

  • All items from the outline above are present in the lesson.
  • Lesson follows proper format
    • Section headings are ###
    • Code blocks use ~~~ and include a language name.
    • Lists are numbered.
  • Lesson has the following sections:
    • 'Learning Outcomes' at the beginning, optionally after a short introduction paragraph (relatively brief, give students an overview of what they're about to learn, with few specific details)
    • Assignment(optional) a list of resources to consume.
    • Practice(optional)
    • 'Additional Resources' (should exist even if it's blank)
    • 'Knowledge Check' (specific questions to test knowledge. Has details. Doesn't just parrot the Learning Outcomes. More of a spot-check, doesn't need to be exhaustive)
  • Lesson has been run through a spell-checker

HTML/CSS Course chore: update image links to use statically CDN

Summary

It's annoying to use these CDN links for writing lessons, but we need them before we go live. For the moment, we're writing new lessons just using relative links:
CleanShot 2021-08-13 at 14 59 42@2x

after everything is merged, and before we update the seeds to go live we need to change the links.

Acceptance Criteria

This is the definition of success. If the requirements here are not met, the work effort is not complete.

  • all new lessons have CDN links instead of relative links

TDD Lesson

Summary

We need a lesson to introduce students to the TDD workflow and why it's useful.

Acceptance Criteria

Lesson content should cover:

  • What is TDD and its benefits.
  • Explain the red green refactor cycle.
  • Walk the student through TDD'ing a couple of methods of a small class.
  • Exercise: Finishing TDD'ing a few more methods in the example class used in the content.
  • Exercise: TDD a value object.
  • Exercise: TDD a class that has a collaborator which doesn't exist yet using mocks.

Unit Testing Part 2: Mocks and Stubs

Summary

We need a lesson to introduce students to mocks and stubs and their uses in unit tests.

Acceptance Criteria

Lesson content should cover:

  • What are mocks.
  • What are command methods?
  • What are stubs?
  • How to use them.
  • Disadvantages.
  • Exercise: Finish mocking more of the example projects crud actions to its database.
  • Exercises: Mock a weather service response in a test to make it predicable.
  • Exercises: Mock a quote of the day service response in a test to make it predicable.
  • Exercises: Mock a database service response that takes a while in a test to make the test fast.

Lesson: Foundations - Introduction to HTML and CSS

Lesson Overview

This is a basic intro to HTML and CSS, don't worry about syntax details, just cover what they are and what they're used for

Lesson Outline

The order of this outline doesn't need to be followed 100%, but the items listed here do need to show up in the lesson somewhere. If you feel like there has been an omission ask in Discord before expanding the scope of this lesson.

  • what are HTML and CSS
    • what are they used for and how do they relate to one another?
  • Rationale for this course/section (HTML/CSS Foundations)
    • i.e. why are we learning this, and why are we learning it now.

Acceptance Criteria

This is the definition of success. If the requirements here are not met, the work effort is not complete.

  • All items from the outline above are present in the lesson.
  • Lesson follows proper format
    • Section headings are ###
    • Code blocks use ~~~ and include a language name.
    • Lists are numbered.
  • Lesson has the following sections:
    • 'Learning Outcomes' at the beginning, optionally after a short introduction paragraph (relatively brief, give students an overview of what they're about to learn, with few specific details)
    • Assignment(optional) a list of resources to consume.
    • Practice(optional)
    • 'Additional Resources' (should exist even if it's blank)
    • 'Knowledge Check' (specific questions to test knowledge. Has details. Doesn't just parrot the Learning Outcomes. More of a spot-check, doesn't need to be exhaustive)
  • Lesson has been run through a spell-checker

Lesson: HTML/CSS - Advanced Selectors

Lesson Overview

covers all the fancy selectors that we didn't get to in foundations

Lesson Outline

The order of this outline doesn't need to be followed 100%, but the items listed here do need to show up in the lesson somewhere. If you feel like there has been an omission ask in Discord before expanding the scope of this lesson.

this document has a good list on page 20 and 23

feel free to find an external resource to cover them.

  • parent/sibling
  • Attribute
  • Pseudo-selectors
    • Hover, focus, before/after, first/last-child etc.

Acceptance Criteria

This is the definition of success. If the requirements here are not met, the work effort is not complete.

  • All items from the outline above are present in the lesson.
  • Lesson follows proper format
    • Section headings are ###
    • Code blocks use ~~~ and include a language name.
    • Lists are numbered.
  • Lesson has the following sections:
    • 'Learning Outcomes' at the beginning, optionally after a short introduction paragraph (relatively brief, give students an overview of what they're about to learn, with few specific details)
    • Assignment(optional) a list of resources to consume.
    • Practice(optional)
    • 'Additional Resources' (should exist even if it's blank)
    • 'Knowledge Check' (specific questions to test knowledge. Has details. Doesn't just parrot the Learning Outcomes. More of a spot-check, doesn't need to be exhaustive)
  • Lesson has been run through a spell-checker

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. 📊📈🎉

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google ❤️ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.