Practice Badges#

Note

these are listed by the date they were posted

Practice badges are a chance to first review the basics and then try new dimensions of the concepts that we cover in class. After each class, you will need to review the day’s material. This includes reviewing prismia chat to see any questions you got wrong and reading the notes. The practice badge will also ask you to apply the day’s material in a similar, but distinct way. They represent the minimum bar for B-level understanding.

2024-09-05#

related notes

Activities:

  1. accept this assignment and join the existing team to get access to more features in our course organization.

  2. Post an introduction to your classmates on our discussion forum (include link to your comment in PR comment, must accept above to see)

  3. Read the notes from today’s class carefully

  4. Create a profile readme and include a screenshot of your profile

  5. Fill in the first two columns of your KWL chart (content of the PR; named to match the badge name)

2024-09-12#

related notes

Activities:

Any steps in a badge marked lab are steps that we are going to focus in on during lab time. Remember the goal of lab is to help you complete the work, not add additional work. The lab checkout will include some other tasks and then we will encourage you to work on this badge while we are there to help. Lab checkouts are checked only for completion though, not correctness, so steps of activities that we want you to really think about and revise if incorrect will be in a practice or review badge.

  1. Read the notes. If you have any questions, post an issue on the course website repo.

  2. Using your terminal, download your KWL repo. Include the command used in your badge PR comment.

  3. Try using setting up git using your favorite IDE or GitHub Desktop. Make a file gitoffline.md and include some notes of how it went. Was it hard? easy? what did you figure out or get stuck on? Is the terminology consistent or does it use different terms?

  4. lab Explore the difference between git add and git commit: try committing and pushing without adding, then add and push without committing. Describe what happens in each case in a file called gitcommit_tips.md. Compare what happens based on what you can see on GitHub and what you can see with git status. Write a scenario with examples of how a person might make mistakes with git add and commit and what to look for to get unstuck.

2024-09-12#

related notes

Activities:

Any steps in a badge marked lab are steps that we are going to focus in on during lab time. Remember the goal of lab is to help you complete the work, not add additional work. The lab checkout will include some other tasks and then we will encourage you to work on this badge while we are there to help. Lab checkouts are checked only for completion though, not correctness, so steps of activities that we want you to really think about and revise if incorrect will be in a practice or review badge.

  1. Read the notes. If you have any questions, post an issue on the course website repo.

  2. Using your terminal, download your KWL repo. Include the command used in your badge PR comment.

  3. Try using setting up git using your favorite IDE or GitHub Desktop. Make a file gitoffline.md and include some notes of how it went. Was it hard? easy? what did you figure out or get stuck on? Is the terminology consistent or does it use different terms?

  4. lab Explore the difference between git add and git commit: try committing and pushing without adding, then add and push without committing. Describe what happens in each case in a file called gitcommit_tips.md. Compare what happens based on what you can see on GitHub and what you can see with git status. Write a scenario with examples of how a person might make mistakes with git add and commit and what to look for to get unstuck.

2024-09-17#

related notes

Activities:

  1. Create a merge conflict in your KWL repo on the branch for this issue and resolve it using your favorite IDE, then create one and resolve it on GitHub in browser (this requires the merge conflict to occur on a PR). Describe how you created it, show the files, and describe how your IDE helps or does not help in merge_conflict_comparison.md. Give advice for when you think someone should resolve a merge conflict in GitHub vs using an IDE. (if you do not regulary use an, IDE, try VSCode) You can put content in the file for this step for the purpose of making the merge conflicts for this exercise.

  2. Learn about GitHub forks and more about git branches(you can also use other resources)

  3. In branches-forks.md in your KWL repo, compare and contrast branches and forks; be specific about their relationship. You may use mermaid diagrams if that helps you think through or communicate the ideas. If you use other resources, include them in your file as markdown links.

2024-09-19#

related notes

Activities:

  1. Update your KWL chart with any learned items.

  2. Get set up so that you can contribute to the course website repo from your local system. Note: you can pull from the compsys-progtools/fall2024 repo, but you do not not have push permission, so there is more to do than clone. Append the commands used and the contents of your fll2024/.git/configto a git-remote-practice.md. Then, using a text editor (or IDE), wrap each log with three backticks to make them fenced code blocks and add headings to the sections.

  3. learn about options for how git can display commit history. Try out a few different options. Choose two, write them both to a file (from the command line, not copy&paste), gitlog-compare.md. Then, using a text editor (or IDE), wrap each log with three backticks to make them fenced code blocks and then add text to the file describing a use case where that format in particular would be helpful.

Hint for working offline

Read about forks and working with remotes.

2024-09-24#

related notes

Activities:

badge steps marked lab are steps that you will be encouraged to use lab time to work on. For this one in particular, I am going to give you the messy repo in lab.

  1. lab Organize the provided messy folder (details will be provided in lab time). Commit and push the changes. Clone that repo locally.

  2. Organize a folder on your computer ( good candidate may be desktop or downloads folder), using only a terminal to make new directories, move files, check what’s inside them, etc. Answer reflection questions in a new file, terminal_organization_adv.md in your kwl repo. Tip: Start with a file explorer open, but then try to close it, and use only command line tools to explore and make your choices. If you get stuck, look up additional commands to do acomplish your goals.

# Terminal File moving reflection
1. How was this activity overall?
1. Did this get easier toward the end?
2. How was it different working on your own computer compared to the Codespace form? 
3. Did you have to look up how to do anything we had not done in class?
4. When do you think that using the terminal will be better than using your GUI file explorer?
5. What questions/challenges/ reflections do you have after this?
6. Append all of the commands you used in lab below. (not from your local computer's history, from the codespace history)

2024-09-26#

related notes

Activities:

  1. Read today’s notes when they are posted. There are imporant tips and explanation to be sure you did and ideas for explore/build badges.

  2. Most real projects partly adhere and at least partly deviate from any major design philosophy or paradigm. Add a ## Unix Philosophy section to your software.md about how that project adheres to and deviates from the unix philosophy. Be specific, using links to specific lines of code or specific sections in the documentation that support your claims. Provide at least one example of both adhering and deviating from the philosophy and three total examples (that is 2 examples for one side and one for the other). You can see what badge software.md was previously assigned in and the original instructions on the KWL file list.

2024-10-01#

related notes

Activities:

  1. Explore the tools for conventional commits and then pick one to try out. Work on the branch for this badge and use one of the tools that helps making conventional commits (eg in VSCode or a CLI for it)for a series of commits adding “features” and “bug fixes” telling the story of a code project in a file called commit-story.md. For each edit, add short phrases like ‘new feature 1’, or ‘next bug fix’ to the single file each time, but use conventional commits for each commit. In total make at least 5 different types of changes (types per conventional commits standard) including 2 breaking changes and at least 10 total commits to the file.

  2. learn about options for how git can display commit history. Try out a few different options. Choose two, write them both to a file, gitlog-compare.md. Using a text editor, wrap each log with three backticks to make them “code blocks” and then add text to the file describing a use case where that format in particular would be helpful. do this after the above so that your git log examples include your conventional commits

2024-10-01#

related notes

Activities:

  1. Explore the tools for conventional commits and then pick one to try out. Work on the branch for this badge and use one of the tools that helps making conventional commits (eg in VSCode or a CLI for it)for a series of commits adding “features” and “bug fixes” telling the story of a code project in a file called commit-story.md. For each edit, add short phrases like ‘new feature 1’, or ‘next bug fix’ to the single file each time, but use conventional commits for each commit. In total make at least 5 different types of changes (types per conventional commits standard) including 2 breaking changes and at least 10 total commits to the file.

  2. learn about options for how git can display commit history. Try out a few different options. Choose two, write them both to a file, gitlog-compare.md. Using a text editor, wrap each log with three backticks to make them “code blocks” and then add text to the file describing a use case where that format in particular would be helpful. do this after the above so that your git log examples include your conventional commits

2024-10-03#

related notes

Activities:

  1. Review the notes, jupyterbook docs, and experiment with the jupyter-book CLI to determine what files are required to make jupyter-book build run. Make your kwl repo into a jupyter book. Set it so that the _build directory is not under version control.

  2. Learn about the documentation ecosystem in another language that you know using at least one official source and additional sources as you find helpful. In docs-practice.md include a summary of your findings and compare and contrast it to jupyter book/sphinx. Include a bibtex based bibliography of the sources you used. You can use this generator for informal sources and google scholar for formal sources (or a reference manager).

2024-10-08#

related notes

Activities:

  1. Read about different workflows in git and add responses to the below in a workflows.md in your kwl repo. Two good places to read from are Git Book and the atlassian Docs

  2. Update your kwl chart with what you have learned or new questions in the want to know column

  3. Add the hash of the content of your completed workflows.md file and put that in the comment of your badge PR for this badge. Try to do this from your local CLI, but full credit even if you use the website interface

## Workflow Reflection

1. Why is it important that git can be used with different workflows?
1. Which workflow do you think you would like to work with best and why?
1. Describe a scenario that might make it better for the whole team to use a workflow other than the one you prefer.  

2024-10-10#

related notes

Activities:

  1. Analyze the xor hashing algorithm in the notes to determine which properties of a cryptographic hash are/not met. Include your analysis in xorhash.md

  2. find 2 more real world examples of using other number systems (either different bases or different symbols and bases) not mentioned in class that are currently used. Describe the number system and its usage in numbers.md. Include links to your sources and be sure that the sources are trustworthy.

  3. Calculate the maximum number of git objects that a repo can have without requiring you to use more than the minimum number of characters to refer to any object and include that number in gitcounts_scenarios.md with a title # Git counts. Describe 3 scenarios that would get you to that number of objects in terms of what types of objects would exist. For example, what is the maximum number of commits you could have without exceeding that number? How could you get to that number of objects in the fewest number of commits? What might be a typical way to get there? Assume normal git use with porcelain commands, not atypical cases with plubming commands. If you get stuck, outline what you know and then request a review.

  4. Read about the Learn more about the SHA-1 collision attach

  5. Learn more about how git is working on changing from SHA-1 to SHA-256 and answer the transition questions below gittransition.md

gittransition#

# transition questions

1. Why make the switch? (in detail, not just *an attack*)
2. What impact will the switch have on how git works?
3. Which developers will have the most work to do because of the switch?

2024-10-17#

related notes

Activities:

  1. Read more details about git internals to review what we did in class in greater detail. Make a file gitplumbingdetail.md and create a a table or mermaid diagram that shows the relationship between at least three porcelain commands and their corresponding plumbing commands (generally more than one each).

  2. Create gitislike.md and explain main git operations we have seen (add, commit, push) in your own words in a way that will either help you remember or how you would explain it to someone else at a high level. This might be analogies or explanations using other programming concepts or concepts from a hobby.

2024-10-22#

related notes

Activities:

  1. Update your KWL Chart learned column with what you’ve learned

  2. prevent badges.json and badges.yml from being tracked by git in your fall24 repo

  3. write a bash script that prevents jupyter-book from giving warnings about files not having a heading by using the file name as a temporary title. (see the badge from 10/3 where you should have converted your repo, or do that one first, this counts as an extension on that if you have not done it)

Hint: Use sed’s insert option and head as needed.

Explore idea#

modify your script to use a small llm from ollama to automatically insert a sensible title by summarizing the file. using a commercial chat interface does not qualify, but using an llm locally does

2024-10-24#

related notes

Activities:

  1. Answer the following in hpc.md of your KWL repo: (to think about how the design of the system we used in class impacts programming and connect it to other ideas taught in CS)

    1. What kinds of things would your code need to do if you were going to run it on an HPC system? 
    2. What sbatch options seem the most helpful?
    3. How might you go about setting the time limits for a script? How could you estimate how long a script will take?
    

2024-10-29#

related notes

Activities:

  1. On Seawulf, modfiy main.c from class to accept the integer as a command line argument instead of via input while running the program. See this tutorial for an example.

  2. Write a bash script demo_test.sh that runs your compiled program for each integer from 10 to 30 (syntax for a range is {start..end} so this would be {10..30})

  3. Write an sbatch script, batchrun.sh to run your script on a compute node and save the output to a file. The sbatch script should compile and link the program and then call the script. see the options

  4. use scp to download your modified main, script files, and output to your local computer and include them in your kwl repo.

2024-10-31#

related notes

Activities:

The first two tasks are the practice task, the thirds is a pre-approved explore badge. Hover it on your issue to create an independent issue to track it. Title the new issue Explore: IDE. On the explore badge, when it is ready for submission, request a review from Dr. Brown.

  1. In bestide.md, compare two IDEs using your group’s table from class, to evaluate each of them. Your review should have an introduction that justifies the ranking and defines the criteria, a section describing each IDE with respect to all of the criteria and your overall experience with that IDE, and a conclusion that explains which of the 3 is the best based on your evaluation.

  2. Configure your VS Code preferences to your github account. add settingssync.md with a description of what settings you customized and synced and reflect on why this is an important feature and what prerequisites to it might be.

  3. (explore badge opportunity) Create a small repo owned by compsys named ide-USERNAME where USERNAME is your gh username with some example code, a vscode/codespace devcontainer file that installs CodeTour and your favorite extension(s). Write a CodeTour that walks someone through using your favorite extension to do something with the code. The example code can be any language, can be very simple, can even have a bug in it if that helps your example. You can use an-IDE integrated LLM (eg GitHub Co-pilot, not the chat version) to generate some code for this purpose if you do not have some available to you already, but you cannot share solutions to a course assignment without that instructor’s permission.