9. Unix Philosophy#

Today we will continue organizing the github inclass repo as our working example.

Navigate to your inclass repo

Now we will add some text to the readme file

 echo "|file | contents |
> | --| -- |
> | abstract_base_class.py | core abstract classes for the project |
> | helper_functions.py | utitly funtions that are called by many classes |
> | important_classes.py | classes that inherit from the abc |
> | alternative_classes.py | classes that inherit from the abc |
> | LICENSE.md | the info on how the code can be reused|
> | CONTRIBUTING.md | instructions for how people can contribute to the project|
> | setup.py | file with function with instructions for pip |
> | test_abc.py | tests for constructors and methods in abstract_base_class.py|
> | tests_helpers.py | tests for constructors and methods in helper_functions.py|
> | tests_imp.py | tests for constructors and methods in important_classes.py|
> | tests_alt.py | tests for constructors and methods in alternative_classes.py|
> | API.md | jupyterbook file to generate api documentation |
> | _config.yml | jupyterbook config for documentation |
> | _toc.yml | jupyter book toc file for documentation |
> | philosophy.md | overview of how the code is organized for docs |
> | example.md | myst notebook example of using the code |
> | scratch.ipynb | jupyter notebook from dev |" >> README.md

9.1. What happens if we copy to a folder that has a file of the same name?#

cat docs/overview.md

# Practice

My name is Ayman
age = 27
touch overview.md
echo "Hello hello... " > overview.md
cat overview.md

+++{"lesson_part": "main"}

Hello hello…


ls
API.md                  helper_functions.py
CONTRIBUTING.md         important_classes.py
LICENSE.md              my_secrets/
README.md               overview.md
about.md                philosophy.md
abstract_base_class.py  scratch.ipynb
alternative_classes.py  setup.py
docs/                   tests/
cat docs/overview.md
# Practice

My name is Ayman
age = 27
cp overview.md docs/overview.md
cat docs/overview.md
Hello hello...

Note

Terminal is not going to tell you “There’s already a file with the same name pick the one you want to keep or keep both etc…” Terminal expects you to be aware and responsible of your actions.

Let’s fix it with the new content we just added to readme

cat README.md
# Practice

My name is Ayman
age = 27
|file | contents |

> | --| -- |

> | abstract_base_class.py | core abstract classes for the project |

> | helper_functions.py | utitly funtions that are called by many classes |

> | important_classes.py | classes that inherit from the abc |

> | alternative_classes.py | classes that inherit from the abc |

> | LICENSE.md | the info on how the code can be reused|

> | CONTRIBUTING.md | instructions for how people can contribute to the project|

> | setup.py | file with function with instructions for pip |

> | test_abc.py | tests for constructors and methods in abstract_base_class.py|

> | tests_helpers.py | tests for constructors and methods in helper_functions.py|

> | tests_imp.py | tests for constructors and methods in important_classes.py|

> | tests_alt.py | tests for constructors and methods in alternative_classes.py|

> | API.md | jupyterbook file to generate api documentation |

> | _config.yml | jupyterbook config for documentation |

> | _toc.yml | jupyter book toc file for documentation |

> | philosophy.md | overview of how the code is organized for docs |

> | example.md | myst notebook example of using the code |

> | scratch.ipynb | jupyter notebook from dev |
cp README.md docs/overview.md
cat docs/overview.md
# Practice

My name is Ayman
age = 27
|file | contents |

> | --| -- |

> | abstract_base_class.py | core abstract classes for the project |

> | helper_functions.py | utitly funtions that are called by many classes |

> | important_classes.py | classes that inherit from the abc |

> | alternative_classes.py | classes that inherit from the abc |

> | LICENSE.md | the info on how the code can be reused|

> | CONTRIBUTING.md | instructions for how people can contribute to the project|

> | setup.py | file with function with instructions for pip |

> | test_abc.py | tests for constructors and methods in abstract_base_class.py|

> | tests_helpers.py | tests for constructors and methods in helper_functions.py|

> | tests_imp.py | tests for constructors and methods in important_classes.py|

> | tests_alt.py | tests for constructors and methods in alternative_classes.py|

> | API.md | jupyterbook file to generate api documentation |

> | _config.yml | jupyterbook config for documentation |

> | _toc.yml | jupyter book toc file for documentation |

> | philosophy.md | overview of how the code is organized for docs |

> | example.md | myst notebook example of using the code |

> | scratch.ipynb | jupyter notebook from dev |

Attention

Not only did we copy the content of the README file to a new location. We gave the new file a different name at the same time. If using File Explorer you’d have to Ctrl + C from one place , Ctrl + V into the new place, then rename the file from README.md to overview.md. We did all of that in one command!!

git status
On branch organization
Changes not staged for commit:
  (use "git add/rm <file>..." to update what will be committed)
  (use "git restore <file>..." to discard changes in working directory)
        modified:   README.md
        deleted:    _config.yml
        deleted:    _toc.yml
        deleted:    example.md
        deleted:    tests_alt.py
        deleted:    tests_helpers.py
        deleted:    tests_imp.py
        deleted:    tsets_abc.py

Untracked files:
  (use "git add <file>..." to include in what will be committed)
        .gitignore
        docs/
        overview.md
        tests/

no changes added to commit (use "git add" and/or "git commit -a")

If I edited multiple files in a repo, how can I stage all of them?

  • [ ] git add f1, f2, f3

  • [x] git add .

  • [ ] git add -a

  • [ ] git add

git add . is the common way to add everything. Why?

Because the . is a special to the current directory, so everything that has been changed inside this directory gets staged with this command.

What about the command git add f1, f2, f3?

Well, the only thing wrong about this command is something we’ve talked about before. Lists in bash are separated by a space not a comma ,

So if we did git add f1 f2 f3 that would’ve worked. The only thing that’s annoying about this method is the waste of time when writing the name of every single file that I want to add when I can simply “select all” with the special character ..

But if we were staging more than one file all at once but NOT all the file then this is a perfect way to do so.

And finally, what about git add -a?

Well, let’s check is there such an option -a?

git add -h
usage: git add [<options>] [--] <pathspec>...

    -n, --[no-]dry-run    dry run
    -v, --[no-]verbose    be verbose

    -i, --[no-]interactive
                          interactive picking
    -p, --[no-]patch      select hunks interactively
    -e, --[no-]edit       edit current diff and apply
    -f, --[no-]force      allow adding otherwise ignored files
    -u, --[no-]update     update tracked files
    --[no-]renormalize    renormalize EOL of tracked files (implies -u)
    -N, --[no-]intent-to-add
                          record only the fact that the path will be added later
    -A, --[no-]all        add changes from all tracked and untracked files
    --[no-]ignore-removal ignore paths removed in the working tree (same as --no-all)
    --[no-]refresh        don't add, only refresh the index
    --[no-]ignore-errors  just skip files which cannot be added because of errors
    --[no-]ignore-missing check if - even missing - files are ignored in dry run
    --[no-]sparse         allow updating entries outside of the sparse-checkout cone
    --[no-]chmod (+|-)x   override the executable bit of the listed files
    --[no-]pathspec-from-file <file>
                          read pathspec from file
    --[no-]pathspec-file-nul
                          with --pathspec-from-file, pathspec elements are separated with NUL character

There isn’t such an option as -a, BUT, there is an option -A or --all that add changes from all tracked and untracked files

Now we know 😁

Let’s remove the new file we created for the experiment

rm overview.md

If I edited multiple files in a repo, why would I want NOT to stage all of them at once?

We might not want to add everything all at once because we think specific changes ought to have their own commit

git add README.md
git status
On branch organization
Changes to be committed:
  (use "git restore --staged <file>..." to unstage)
        modified:   README.md

Changes not staged for commit:
  (use "git add/rm <file>..." to update what will be committed)
  (use "git restore <file>..." to discard changes in working directory)
        deleted:    _config.yml
        deleted:    _toc.yml
        deleted:    example.md
        deleted:    tests_alt.py
        deleted:    tests_helpers.py
        deleted:    tests_imp.py
        deleted:    tsets_abc.py

Untracked files:
  (use "git add <file>..." to include in what will be committed)
        .gitignore
        docs/
        tests/
git commit -m "Added overview of files in readme.md"
[organization 93d4ae3] Added overview of files in readme.md
 1 file changed, 37 insertions(+)
git status
On branch organization
Changes not staged for commit:
  (use "git add/rm <file>..." to update what will be committed)
  (use "git restore <file>..." to discard changes in working directory)
        deleted:    _config.yml
        deleted:    _toc.yml
        deleted:    example.md
        deleted:    tests_alt.py
        deleted:    tests_helpers.py
        deleted:    tests_imp.py
        deleted:    tsets_abc.py

Untracked files:
  (use "git add <file>..." to include in what will be committed)
        .gitignore
        docs/
        tests/

no changes added to commit (use "git add" and/or "git commit -a")

Notice that the other files remain unchanged.

Let’s keep staging the changes that we made in steps that make sense.

ls docs/
_config.yml  _toc.yml  example.md  overview.md

We moved a bunch of files related to documentation to the docs/ folder. Let’s stage and commit these changes separate than other changes

What is a quick way for me to add all yml files?

git add *.yml
git status
On branch organization
Changes to be committed:
  (use "git restore --staged <file>..." to unstage)
        renamed:    _config.yml -> docs/_config.yml
        renamed:    _toc.yml -> docs/_toc.yml

Changes not staged for commit:
  (use "git add/rm <file>..." to update what will be committed)
  (use "git restore <file>..." to discard changes in working directory)
        deleted:    example.md
        deleted:    tests_alt.py
        deleted:    tests_helpers.py
        deleted:    tests_imp.py
        deleted:    tsets_abc.py

Untracked files:
  (use "git add <file>..." to include in what will be committed)
        .gitignore
        docs/example.md
        docs/overview.md
        tests/

Notice how when we added all yml files. git added the new ones and the deleted ones (staged the deletion of the ones that were moved) It then recognized the moving of the files into the docs folder as “renaming” with two different paths being the old and new names.

Notice also how now it specifies that there are two more files that are new to the docs/ directory and aren’t staged. One of which was moved from the main directory (example.md)

We also notice that two new files start with docs/ Is there a quick way to add all of them?

git add docs/*
git status
On branch organization
Changes to be committed:
  (use "git restore --staged <file>..." to unstage)
        renamed:    _config.yml -> docs/_config.yml
        renamed:    _toc.yml -> docs/_toc.yml
        new file:   docs/example.md
        new file:   docs/overview.md

Changes not staged for commit:
  (use "git add/rm <file>..." to update what will be committed)
  (use "git restore <file>..." to discard changes in working directory)
        deleted:    example.md
        deleted:    tests_alt.py
        deleted:    tests_helpers.py
        deleted:    tests_imp.py
        deleted:    tsets_abc.py

Untracked files:
  (use "git add <file>..." to include in what will be committed)
        .gitignore
        tests/
git add example.md
git status
On branch organization
Changes to be committed:
  (use "git restore --staged <file>..." to unstage)
        renamed:    _config.yml -> docs/_config.yml
        renamed:    _toc.yml -> docs/_toc.yml
        renamed:    example.md -> docs/example.md
        new file:   docs/overview.md

Changes not staged for commit:
  (use "git add/rm <file>..." to update what will be committed)
  (use "git restore <file>..." to discard changes in working directory)
        deleted:    tests_alt.py
        deleted:    tests_helpers.py
        deleted:    tests_imp.py
        deleted:    tsets_abc.py

Untracked files:
  (use "git add <file>..." to include in what will be committed)
        .gitignore
        tests/
git commit -m "Organized all documentation files."
[organization 99c73d4] Organized all documentation files.
 4 files changed, 41 insertions(+)
 rename _config.yml => docs/_config.yml (100%)
 rename _toc.yml => docs/_toc.yml (100%)
 rename example.md => docs/example.md (100%)
 create mode 100644 docs/overview.md
git status
On branch organization
Changes not staged for commit:
  (use "git add/rm <file>..." to update what will be committed)
  (use "git restore <file>..." to discard changes in working directory)
        deleted:    tests_alt.py
        deleted:    tests_helpers.py
        deleted:    tests_imp.py
        deleted:    tsets_abc.py

Untracked files:
  (use "git add <file>..." to include in what will be committed)
        .gitignore
        tests/

        no changes added to commit (use "git add" and/or "git commit -a")
git log
commit 99c73d4f2c0c87c3aef7a61366e56e3894a040a5 (HEAD -> organization)
Author: AymanBx <ayman_sandouk@uri.edu>
Date:   Tue Feb 25 13:02:20 2025 -0500

    Organized all documentation files.

commit 93d4ae322683efa703dedbb9acb8431807a38afd
Author: AymanBx <ayman_sandouk@uri.edu>
Date:   Tue Feb 25 12:53:36 2025 -0500

    Added overview of files in readme.md

commit 4ccfb5fe36073d15eaa4271d5f1355c0d9e1635b
Author: AymanBx <ayman_sandouk@uri.edu>
Date:   Thu Feb 20 13:13:59 2025 -0500

    added age to readme

commit 581ac5ef92ba5b4a647f30fc91a9d405e6900007 (origin/main, origin/HEAD, main)
Merge: 162a47b 7b56104
Author: Ayman Sandouk <111829133+AymanBx@users.noreply.github.com>
Date:   Thu Feb 20 11:19:10 2025 -0500

    Merge pull request #3 from compsys-progtools/organizing_ac

9.2. Discussion#

At your tables:

  • share your responses to the work in the prep work for today’s topic

  • discuss any similiarities or differences

  • if any, send back questions you have

  • if any, send points you want to share to the whole class

How did the processes, decisions, and practices that people at your table brought up compare to what you thought of?

9.3. Design#

In CS we tend to be more implicit about design, but that makes it hard to learn and keep track of.

Today’s goal is to be more explicit, disucssing some principles and seeing how you have already interacted wit them.

Today we’re going to do a bit more practical stuff, but we are also going to start to get into the philosophy of how things are organized.

Understanding the context and principles will help you:

  • remember how to do things

  • form reliable hypotheses about how to fix problems you have not seen before

  • help you understand when you should do things as they have always been done and when you should challenge and change things.

9.3.1. Why should we study design?#

  • it is easy to get distracted by implementation, syntax, algorithms

  • but the core principles of design organize ideas into simpler rules

9.3.2. Why are we studying developer tools?#

The best way to learn design is to study examples [Schon1984, Petre2016], and some of the best examples of software design come from the tools programmers use in their own work.

Software design by example

note

  • we will talk about some history in this course

This is because:

  • I think that history is important context for making decisions

  • when people are deeply influential, ignoring their role in history is not effective, we cannot undo what they did

  • we do not have to admire them or even say their names to acknowledge the work

  • computing technology has been used in Very Bad ways and in Definitely Good ways

9.4. Unix Philosophy#

sources:

The tenets:

  1. Make it easy to write, test, and run programs.

  2. Interactive use instead of batch processing.

  3. Economy and elegance of design due to size constraints (“salvation through suffering”).

  4. Self-supporting system: all Unix software is maintained under Unix.

For better or worse unix philosophy is dominant, so understanding it is valuable.

This critique is written that unix is not a good system for “normal folks” not in its effectiveness as a context for developers which is where *nix (unix, linux) systems remain popular.

context:
“normal folks” is the author’s term; my guess is that it is attempting to describe a typical, nondeveloper computer user terminology to refer to people has changed a lot over time; when we study concepts from primary sources, we have to interpret the document through the lens of what was normal at the time the document was written, not to excuse bad behavior but to not be distracted and see what is there

9.5. Philosophy in practice, using pipes#

Today we will work in your main repo

cd spring2025-kwl-AymanBx/

To check if your gh CLI is working:

gh
  Work seamlessly with GitHub from the command line.

USAGE
  gh <command> <subcommand> [flags]

CORE COMMANDS
  auth:        Authenticate gh and git with GitHub
  browse:      Open the repository in the browser
  codespace:   Connect to and manage codespaces
  gist:        Manage gists
  issue:       Manage issues
  org:         Manage organizations
  pr:          Manage pull requests
  project:     Work with GitHub Projects.
  release:     Manage releases
  repo:        Manage repositories

GITHUB ACTIONS COMMANDS
  cache:       Manage GitHub Actions caches
  run:         View details about workflow runs
  workflow:    View details about GitHub Actions workflows

EXTENSION COMMANDS
  classroom:   Extension classroom

ALIAS COMMANDS
  co:          Alias for "pr checkout"

ADDITIONAL COMMANDS
  alias:       Create command shortcuts
  api:         Make an authenticated GitHub API request
  attestation: Work with artifact attestations
  completion:  Generate shell completion scripts
  config:      Manage configuration for gh
  extension:   Manage gh extensions
  gpg-key:     Manage GPG keys
  label:       Manage labels
  ruleset:     View info about repo rulesets
  search:      Search for repositories, issues, and pull requests
  secret:      Manage GitHub secrets
  ssh-key:     Manage SSH keys
  status:      Print information about relevant issues, pull requests, and notifications across repositories
  variable:    Manage GitHub Actions variables

HELP TOPICS
  actions:     Learn about working with GitHub Actions
  environment: Environment variables that can be used with gh
  exit-codes:  Exit codes used by gh
  formatting:  Formatting options for JSON data exported from gh
  mintty:      Information about using gh with MinTTY
  reference:   A comprehensive reference of all gh commands

FLAGS
  --help      Show help for command
  --version   Show gh version

EXAMPLES
  gh issue create
  gh repo clone cli/cli
  gh pr checkout 321

LEARN MORE
  Use `gh <command> <subcommand> --help` for more information about a command.
  Read the manual at https://cli.github.com/manual
  Learn about exit codes using `gh help exit-codes`
  

When we use it without a subcommand, it gives us help output a list of all the commeands that we can use. If it is not working, you would get a command not found error.

Let’s also pull up the repo on the browser

gh repo view --web
Opening github.com/compsys-progtools/spring25-kwl-AymanBx in your browser.

Let’s inpsect the action file that creates the issues for your badges.

Note

We can also inspect the file on the terminal

cat .github/workflows/getassignment.yml 
name: Create badge issues (Do not run manually)
on:
  workflow_dispatch

jobs:
  check-contents:
    runs-on: ubuntu-latest
    steps:
    - uses: actions/checkout@v4
    
    # Install dependencies
    - name: Set up Python 
      uses: actions/setup-python@v5
      with:
        python-version: 3.12
    
    - name: Install Utils
      run: |
        pip install git+https://github.com/compsys-progtools/courseutils@main
    - name: Get badge requirements
      run: |
        # prepare badge lines
        pretitle="prepare-"$(cspt getbadgedate --prepare)
        cspt getassignment --type prepare | gh issue create --title $pretitle --label prepare --body-file -
        # review badge lines
        rtitle="review-"$(cspt getbadgedate --review)
        cspt getassignment --type review | gh issue create --title $rtitle --label review --body-file -
        # practice badge lines
        pratitle="practice-"$(cspt getbadgedate --practice)
        cspt getassignment --type practice | gh issue create --title $pratitle --label practice --body-file -
      env:
        GH_TOKEN: ${{ secrets.GITHUB_TOKEN }}
#  edit the run step above for the level(s) you want. 
#  You should keep the prepare, because they are required for experience badges 
#     You may choose to get only the review or only the practice (and change this any time) 
# added comment to fix

A lot of this is familiar, but we are focused today on the three highlighed lines

Here we see a few key things:

  • on the last line it uses a pipe | to connect a command sysgetassignment to the gh issue create command.

  • the gh issue create command uses the --body-file option with a value -; this uses std in, but since this is to the right of the pipe, it puts the output of the first command into this option

  • the 2nd to last line creates a variable (we will learn this more later) and the last line uses that variable

  • the Install Utils step, installs the tool that we’ve talked about before called courseutils…

We know that this action is what is used to create badge issues, so this custom code must be what gets information from the course website to get the assignments and prepare them for your badge issues.

TO confirm it worked, we use its base command

cspt 
Usage: cspt [OPTIONS] COMMAND [ARGS]...

Options:
  --help  Show this message and exit.

Commands:
  badgecounts     check if early bonus is met from output of `gh pr list...
  combinecounts   combine two yaml files by adding values
  createtoyfiles  from a yaml source file create a set of toy files with...
  earlybonus      check if early bonus is met from output of `gh pr list...
  exportac        export ac files for site from lesson
  exporthandout   export prismia version of the content
  exportprismia   export prismia version of the content
  getassignment   get the assignment text formatted
  getbadgedate    cli for calculate badge date
  grade           calculate a grade from yaml that had keys of...
  issuestat
  issuestatus     generate script to appy course issue statuse updates
  kwlcsv          generate the activity file csv file for the site...
  mkchecklist     transform input file to a gh markdown checklist, if the...
  parsedate       process select non dates
  prfixlist       check json output for titles that will not be counted...
  processexport   transform output from mac terminal export to myst...
  progressreport  list PR titles from json or - to use std in that have...
  titlecheck      check a single title

Let’s try the one we saw in the action

cspt getassignment --type prepare
404: Not Found

With default settings, it says 404.

We know that it goes online. So, for example, if you turn your wifi off and then try it again, you will get a different error.

To learn more about this, lets use the --help option.
A lot of CLI tools have this option. In this program, that I made, the Python library click that I used to make this, provides the help option automatically to show the documentation or lets me as the developer add help text to options.

cspt getassignment --help
Usage: cspt getassignment [OPTIONS]

  get the assignment text formatted

Options:
  --type TEXT  type can be {prepare, review, or practice}; default prepare
  --date TEXT  date should be YYYY-MM-DD of the tasks you want; default most
               recently posted
  --help       Show this message and exit.

Now we can see that it can take some options.

If we do not provide a date, I can tell you (and I should add to the documentation), it uses today’s date. Since we ran this on a day with class, before the badges were posted, the file it looked for did not exist, so we got 404.

We can use the options to get the last posted prepare work

cspt getassignment --type prepare --date 2024-09-26
- [ ] Think through and make some notes about what you have learned about design so far. Try to answer the questions below in `design_before.md`.  If you do not now know how to answer any of the questions, write in what questions you have. 

``` 
- What past experiences with making decisions about design of software do you have?
- what experiences studying design do you have? 
- What processes, decisions, and practices come to mind when you think about designing software?
- From your experiences as a user, how you would describe the design of command line tools vs other GUI based tools?
```
gh issue create --help
Create an issue on GitHub.

Adding an issue to projects requires authorization with the `project` scope.
To authorize, run `gh auth refresh -s project`.


USAGE
  gh issue create [flags]

ALIASES
  gh issue new

FLAGS
  -a, --assignee login   Assign people by their login. Use "@me" to self-assign.
  -b, --body string      Supply a body. Will prompt for one otherwise.
  -F, --body-file file   Read body text from file (use "-" to read from standard input)
  -e, --editor           Skip prompts and open the text editor to write the title and body in. The first line is the title and the remaining text is the body.
  -l, --label name       Add labels by name
  -m, --milestone name   Add the issue to a milestone by name
  -p, --project title    Add the issue to projects by title
      --recover string   Recover input from a failed run of create
  -T, --template file    Template file to use as starting body text
  -t, --title string     Supply a title. Will prompt for one otherwise.
  -w, --web              Open the browser to create an issue

INHERITED FLAGS
      --help                     Show help for command
  -R, --repo [HOST/]OWNER/REPO   Select another repository using the [HOST/]OWNER/REPO format

EXAMPLES
  $ gh issue create --title "I found a bug" --body "Nothing works"
  $ gh issue create --label "bug,help wanted"
  $ gh issue create --label bug --label "help wanted"
  $ gh issue create --assignee monalisa,hubot

  $ gh issue create --project "Roadmap"
  $ gh issue create --template "bug_report.md"

LEARN MORE
  Use `gh <command> <subcommand> --help` for more information about a command.
  Read the manual at https://cli.github.com/manual
  Learn about exit codes using `gh help exit-codes`

9.5.1. Interactive Design#

gh issue create
Creating issue in compsys-progtools/compsys-progtools--spring2025-kwl-kwl-template

? Title tst
? Body <Received>
? What's next? Submit
https://github.com/compsys-progtools/compsys-progtools--spring2025-kwl-kwl-template/issues/43
gh issue list
Showing 1 of 1 open issue in compsys-progtools/compsys-progtools--spring2025-kwl-kwl-template

ID   TITLE  LABELS  UPDATED               
#43  tst            less than a minute ago
gh issue view 43
tst compsys-progtools/compsys-progtools--spring2025-kwl-kwl-template#43
Open • AymanBx opened about 1 minute ago • 0 comments


  No description provided


View this issue on GitHub: https://github.com/compsys-progtools/compsys-progtools--spring2025-kwl-kwl-template/issues/43

COmment also allows us to work interactively.

gh issue comment 43

It uses nano which we have already been using, so you are well prepared for this!

- Press Enter to draft your comment in nano... 
? Submit? Yes
https://github.com/compsys-progtools/compsys-progtools--spring2025-kwl-kwl-template/issues/43#issuecomment-2377554046

We can look again

gh issue view 43
tst compsys-progtools/compsys-progtools--spring2025-kwl-kwl-template#43
Open • AymanBx opened about 2 minutes ago • 1 comment


  No description provided


AymanBx • 0m • Newest comment

  lksjflakjfladksjlf;kwhf;kwh                                                 


View this issue on GitHub: https://github.com/compsys-progtools/compsys-progtools--spring2025-kwl-kwl-template/issues/43

We can also close issues

gh issue close 43
✓ Closed issue compsys-progtools/compsys-progtools--spring2025-kwl-kwl-template#43 (tst)

9.6. Prepare for Next Class#

Read the README.md file in courseutils. in a file courseutils write a summary of your findings.

# Course Utils

## Short description
<!-- Short description of what you think this tool is for -->


## Use cases 
<!-- These are bullet points. Add as many as you need -->
* 
* 

## Summary
<!-- Any thoughts about the tool -->

9.7. Badges#

  1. Read today’s notes when they are posted. There are imporant tips and explanation to be sure you did.

  2. Most real projects partly adhere and at least partly deviate from any major design philosophy or paradigm. Review the open source project you looked at for the software.md file from before and decide if it primarily adheres to or deviates from the unix philosophy. Add a ## Unix Philosophy <Adherance/Deviation> section to your software.md, setting the title to indicate your decision and explain your decision in that section (pick one). Provide at least two specific examples supporting your choice, using links to specific lines of code or specific sections in the documentation that support your claims.

  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.

9.8. Experience Report Evidence#

9.9. Questions After Today’s Class#

9.9.1. why would we not stage all files in a repo all at once#

In case you wanted to separate the work you’ve made into different commits (checkpoints) to possibly deploy each one separately and make sure your main doesn’t break. And if main does break, you can tell which commit caused it to fail to run or deploy because you don’t have too many changes all in one commit.