2. How does this course work?#

Today we will:

  • continue getting familiar with the structure of GitHub

  • clarify more how the course will flow

  • practice with new vocabulary

Tuesday was a lot of new information, today we will reinforce that mostly, and add only a little

2.1. Warm up#

  1. Navigate to your KWL repo

  2. Find the issues tab

  3. Open the prepare-2024-01-25 issue and follow those instructions

*hint: my KWL repo URL is: https://github.com/compsys-progtools/kwl-sp24-brownsarahm

2.2. What is it like to know things really well?#

When you know something well:

  • it becomes automatic, you can do it without thinking about the details

  • you are able to anticipate things

  • you use specialized vocabulary with ease

Important

The goal is to get you to that point with alal of the developer tools we will learn about.

If the tools become automatic in this class, you an use them with ease in other classes to your advantage.

Note

We did some prismia questions on GitHub things to reinforce that material we had already seen. When we do this, I’ll typically skip that section in the posted notes, but you can always view on prismia including getting a transcript from prisma:

  1. In the top left corner there is a > icon which opens a sidebar popup.

  2. In the top left opens a menu

  3. “Get transcript from class”

2.3. Pull Requests and Commits#

The unit of changes in a histoy is a commit. Each commmit is said to be “on” a branch.

We examined the PRs for your first experience badge.

a screenshot of an experience badge PR in Dr. Brown's kwl repo, it has 2 commits, which is denoted with a 2 next to commits on the tabs below the PR title above the first comment. The conversation tab is highlighted, below the first comment is shows the list of 2 separate commits. There are 0 checks, and 1 files changed as indicated by the tab titles.

Fig. 2.1 A PR that has two commits on it with one file changed. This PR compares the experience-$date branch to the main branch.#

From this page we can learn an important implication of the fact that a pull request is a comparison between two branches. Since the relationship is between the branches, it is not related directly to commits. We can add more commits to the branch after we make a PR, and they show up on the PR page.

At the bottom of this screenshot which is right above the checks for the PR is a reminder from GitHub:

Add more commits by pushing to the experience-$date branch on compsys-progtools/kwl-sp24-brownsarahm.

Note

here we are learning by example and then synthesizing that into concrete facts.

This course will proceed like this a lot; we do things to let you experience the important to know things in context first, then discuss and label and examine.

Hint

If we ever do something and you are not sure why, please ask!!

2.4. Why learn by example?#

just play with it

  • common attitude in CS

  • not optimal for learning

It’s not optimal for learning because it can leave you unguided and not knwo where to start, but it is the common culture in developer environments.

My goal is to teach you to thrive within that culture, because you are likely to encounter it at work.

My goal, however, is not to just drop you in with no preparation. If it feels that way, please ask questions.

We’ll practice what it looks like to learn by tinkering and then examining.

To do this:

  • set up opportunities for you to do the things that give you the opportunity

  • highlight important facts about what just happened

  • ask you questions to examine what just happened

This is why attendance/participation is a big part of your grade.

Experience badges are evidence of having learned, you get credit for engaging in the process of learning.

2.5. Admin#

  1. Go to you PR tab

  2. Find the PR titled “Template updates” that I created

  3. Merge and confirm the PR

2.6. Commit history & PRs#

When we merge a PR into main all of the commits on the PR compare branch are added to main + an additional commit for the merge itself.

For easy merges, that commit does not add more changes to any files, but if the merge is not automatic, it can.

2.7. This course will be different#

  • no Brightspace

  • 300 level = more independence

  • I will give advice, but only hold you accountable to a minimal set

  • High expectations, with a lot of flexibility

2.7.1. I do not judge your reasons for missing class.#

  • No need to tell me in advance

  • For 1 class, no need to tell me why at all

  • For 1 class, make it up and keep moving

  • For long absences, I will help you plan how to get caught up, must meet university criteria for excused absence

If you do email me about missing a single clss, I will likely not reply. Not because I do not care about your long term success; I do! I get too many emails. I try to prioritize time on things that has the biggest impact; confirming I saw an email that does not change any other policies is lower impact than, for example giving feedback on student work.

2.7.2. My focus is for you to learn#

  • that means, practice, feedback, and reflection

  • you should know that you have learned

  • you should be able to apply this material in other courses

Important

You will be asked to revise things at some point, for 2 reasons:

  • since I allow revisions, I enforce really high standards on the quality of your work so that you do not hold onto misconceptions

  • the process of using GitHub to make revisions is something to get familiar with.

2.7.3. Learning comes in many forms#

  • different types of material are best remembered in different ways

  • some things are hard to explain, but watching it is very concrete

2.8. Learning is the goal#

  • producing outputs as fast as possible is not learning

  • in a job, you may get paid to do things fast

  • your work also needs to be correct, without someone telling you it is

  • in a job you are trusted to know your work is correct, your boss does not check your work or grade you

  • to get a job, you have to interview, which means explaining, in words, to another person how to do something

2.9. What about AI?#

Large Language Models will change what programming looks like, but understanding is always going to be more effective than asking an AI. Large language models actually do not know anything, they just know what languages loook like and generate text.

if you cannot tell it when it’s wrong, you do not add value for a company, so why would they pay you?

2.10. This is a college course#

  • more than getting you one job, a bootcamp gets you one job

  • build a long (or maybe short, but fruitful) career

  • build critical thinking skill that makes you adaptable

  • have options

2.11. “I never use what I learned in college”#

  • very common saying

  • it’s actually a sign of deep learning

  • when we have expertise, we do not even notice when we apply it

  • college is not (just) about the facts, but the processes

2.12. How does this work?#

2.12.1. In class:#

  1. Memory/ understanding checks

  2. Review/ clarification as needed

  3. New topic demo with follow along, tiny practice

  4. Review, submit questions

2.12.2. Outside of class:#

  1. Read notes to refresh the material, check your understanding, and find more details

  2. Practice material that has been taught

  3. Activate your memory of related things to what we will cover to prepare

  4. Read articles/ watch videos to either fill in gaps or learn more details

  5. Bring questions to class

2.13. How to be successful#

Important

There are links on the side to advice from previous semesters, details in the grading have changed, but the core is still the same.

I give a time breakdown in the syllabus.

Take a minute to think about how you use your time and what that breakdown means for how you will plan.

This time breakdown is planned based on if the time-blocking strategy is helpful to you, but the most important thing is for you to make a plan that will work for you. I want this to be flexible enough that you can adapt it to your liking, but that mean you have to make choices.

2.14. What is this course about?#

In your KWL chart, there are a lot of different topics that are not obviously related, so what is this course really about?

We will:

  • practical exposure to important tools

  • design features of those tool categories

  • basic knowledge of many parts of the CS core

  • focus on the connections

We will use learning the tools to understand how computer scientists think and work.

Then we will use the tools to examine the field of Computer Science top to bottom (possibly out of order).

2.14.1. How it fits into your CS degree#

knowing where you’ve been and where we’re going will help you understand and remember

In CSC110, you learn to program in python and see algorithms from a variety of domain areas where computer science is applied.

(for BS) in CSC 340 and 440 you study the algorithms more mathematically, their complexity, etc.

In CSC211, 212, you learn the foundations of computer science: general programming and data structures.

Then in 301, 305, 411, 412 you study different aspects of software design and how computers work.

In this class, we’re going to connect different ideas. We are going to learn the tools used by computer scientists, deeply. You will understand why the tools are the way they are and how to use them even when things go wrong.

2.14.2. Programming is Collaborative#

There are two very common types of collaboration

  • code review (working independently and then reviewing)

  • pair programming (sitting together and discussing while writing)

We are going to build your skill in the code review model, especially.

You can do build badges collaboratively, for a closer collaboration, but those are your choice.

2.15. GitHub Actions Tab Review#

GitHub allows us to run scripts within our repos, the feature is called GitHub Actions and the individual items are called workflows.

../_images/actionpage.png

Fig. 2.2 Screen shot of the actions tab of my repo showing 4 total runs in the center panel. Three of the runs succeeded and have a green check mark. One failed and has a red x. On the left hand side there is a list of 5 possible actions to run. Notice the list of workflows on the left each has a unique name (because we generally choose to name things so that names can be used as identifies) the list of workflow runs includes the same name multiple times because we can run each workflow multiple times.#

this should be different from yours, because I tested things in mine before making your PRs

2.15.1. Get Credit for Today’s class#

**Run your Experience Reflection (inclass) action on your kwl repo **

talk with peers to make sure you remember what the right way to click on it is

2.16. Reminder about class structure#

flowchart TD exp[Experience badges] dated[Dated Badges] rev[Review badges] pra[Practice badge] inclass[Class Session <br> 26 total] exp --> | tracks participation for each| inclass rev --> |is one type of| dated pra --> |is one type of| dated breadth[Breadth bonus] breadth --> |awarded for 18 total | dated participation[Participation bonus] participation --> |awarded for 22 total| exp dated --> |posted for each| inclass

This is called a concept map, you would read it along the arrows, so this corresponds to the following bullets:

  • review badges are one type of dated badge

  • practice badges

  • dated badges are posted for each class session

  • experience badges track participation for each class session

Hint

Remember, this website is generated from a GitHub repo, you can find it from the course organization page on GitHub. The organization is named compsys-progtools so the org page is at https://github.com/compsys-progtools and it is the owner of your KWL repo so there is a link to it in the top left corner.

2.17. Prepare for lab#

this is really a tip/hint about what we will do in the next lab

Next lab we will give you help with sorting out the procedures of PRs and issues and submitting work.

If you work on the badges, but you are not sure about things, log your work as comments on the issue or even in a separate file somewhere, and we will help you get it submitted in lab.

You can also bring questions about anything in the syllabus to get help (or post them for written answers).

2.18. Prepare for next class#

  1. Find the glossary page for the course website, link it below. Review the terms for the next class: shell, terminal, bash, git, zsh, powershell, GitHub. Make a diagram using mermaid to highlight how these terms relate to one another

  2. Check your kwl repo before class and see if you have recieved feedback, reply or merge accordingly.

Example “venn diagram “ with mermaid subgraphs

flowchart subgraph Browsers subgraph Safari end subgraph Chromium based gg[Google Chrome] me[Microsoft Edge] end end

2.19. Badges#

  1. review notes after they are posted, both rendered and the raw markdown include links to each in your badge PR

  2. map out your computing knowledge or what you know about git/GitHub so far and add it to your kwl chart repo in a file called prior-knowledge-map.md. Use mermaid

the text in () below is why each step is assigned

  1. review today’s notes after they are posted, both rendered and the raw markdown versions. Include links to both views in your badge PR comment. (to review + there are hints for some of the following there)

  2. read Chapter 1, “Decoding your confusion while coding” in The Programmer’s Brain add a file called brain.md to your kwl repo that summarizes your thoughts on the chapter. Do you think this information will help you approach learning more effectively? why or why not? How, if at all, does it changes how you think about debugging and learning to program? Give examples of how you have encountered the different types of confusion in your prior programming experiences. (to help you get good strategies and prime for things we will see in the next few weeks)

  3. Make a concept map of your current understanding of git and github git-basics-map.md. Use mermaid syntax, to draw your map. GitHub can render it for you including while you work using the preview button. (review what we have learned so far; think about connections + learn a new tool)

  4. Read more about version control in general and add a “version control” row to your KWL chart with all 3 columns filled in. (git is version control, but not the only one)

2.20. Questions After Class#

2.20.1. In experience badge, after I commit, do I do anything after?#

Yes, request a review from @instructors

2.20.2. Are we adding a reviewer to our experience badge?#

Yes

2.20.3. do we check off the things in the experience badge checklist or does a TA do that?#

In the future, you will, but we’ll work through what that looks like in more detail next week.

2.20.4. do we do both the review and prepare?#

Only one per date. If you look, they’re very similar. For the first class, they’re just about the same. As we go on for the first few weeks the difference between them will increase (which is mostly complexity or depth of understanding that I am looking to check)

2.20.5. How do I submit work?#

Create a PR and request a review.

Two things to note:

  • in the penalty free zone, there is no penalty for doing it wrong

  • checking this is the main topic of the next lab, so we will one on one check in with each of you that you know how to do this

2.20.6. If we wanted to ping an instructor/the instructor that got assigned to us, would we @ them in a comment?#

Yes! you can @ mention any of us or the team whenever you need help.

2.21. A final note#

Tip

Reading to the end is always valued, you can claim a community badge for finding this by linking to the heading above and requesting a review from @brownsarahm, title your PR community-reading-notes.

Extra bonus, there are tips like this throughout the website that let you get community badges for setting things up, or reading carefully.