2024 02 20 - TheEvergreenStateCollege/upper-division-cs-23-24 GitHub Wiki

Week 07 - Tuesday

20 Feb 2024

Web Front-End - Morning Session

Catch-up Day from Snow Day. If you are caught up, please keep working on homework.

A Classification of Learning

Bloom's Taxonomy is a categorization of educational goals, arranged from simple to complex. It has been updated in 2001 since its invention in 1956, still containing six categories.

image

In the context of programming and computer engineering, we will consider the idea that Bloom's Taxonomy corresponds to abstractness of ideas, and also how long such knowledge will remain useful before it's replaced or obsolete.

Most of the technology that you will use and engineer for the rest of your life, hasn't even been invented yet. With that in mind, how will you decide what to keep in your mind, take notes on, or devote time to understanding?

The below examples are merely suggestions. With a pair programming partner, critique them, decide if the examples make sense to you, or come up with another one that fits better. Submit your suggestions on Canvas.

  • Remembering - Recognizing, Recalling.

    • Example: npm install used to install a dependency, but required the --save flag to save it to package.json. Now it saves all packages automatically.
    • Half-life - possibly 1 to 2 years. npm install may have different flags as part of its normal release cycle, or new subcommands in addition to install.

  • Understanding - Interpreting, Exemplifying, Classifying, Summarizing, Inferring, Comparing, Explaining

    • Example: npm is a package manager that downloads and installs third-party libraries for the NodeJS ecosystem. pip, cargo, maven are other examples of package managers for other programming languages. "Package managers" are a "kind of thing", or an entity that many programmers rely on in 2024.
    • Half-life - possibly 2 to 4 years. npm may be superseded by another tool, nodejs may fall out of popular usage, and therefore programmers will not need to be immediately familiar with its command-line flags. Around the time npm became popular, NodeJS programmers used build tools like grunt, gulp, yeoman, and these are less frequent now. Likewise, before pip became popular, python used to use a system called easy_install that was a convention that allowed anyone's python library to be installed from source, after it was downloaded. These days, there are other python package managers such as conda.

  • Apply - Executing, Implementing

    • Example: You decide to learn a new programming language called zig. As part of your first project, you want to use a library to read and write PNG image files and you find such a library online (let's call it zigpng). You may choose to search for the question "what is the package manager for Zig called?" If you don't find one, you may choose to automate the downloading and extracting of zigpng into your build scripts, so that other Zig programmers can build your program without having to find all its dependencies for themselves. You have applied your understanding of "package manager" to a new situation.
    • Half-life - possibly 4 to 16 years. The Node Package Manager was just coming into use in the 2010s, but most of the package managers that we use today did not exist at all in the 2000s. package managers were not widespread in the 2000s, most people manually downloaded and installed zip files and other archives to install dependencies. They arose to solve the problem of mismatching dependency versions, sometimes multiple versions of the same package, where a new installation may prevent existing software from working ("DLL hell", for dynamically-linked libraries on Windows). Package managers themselves have shortcomings, it's possible that software engineering will evolve past them to something better.

  • Analyze - Differentiating, Organizing, Attributing

    • Example: After using package managers like npm and building your own for zig for awhile, you notice that when you download and try someone else's code, you still spend a lot of time trying to get the same package versions as the author. Some days, you spend 70% of your time or more on install problems. It's a very frustrating experience. A single new package version in a project that requires thousands of them could stop everything from working, or a new programming language version will no longer support an old keyword that you need for backward compatibility. You search for ways to package software so that the dependencies are mostly immutable and locked to a version, and discover a few options to "virtualize" environments: docker, devcontainer, microcontainers, VirtualBox, nix, hypervisor VMs like qemu, and more.
    • Half-life - possibly 8 to 24 years. The idea of virtual machines in the form of "jailed" processes with limited resources on a native operating system, or software-emulated hardware, is useful now, but it is not so far-fetched to imagine that the same virtualization could happen with FPGAs (field-programmable gate arrays, or hardware circuit simulators) in the near future.

  • Evaluate - Checking, Critiquing

    • Example: You package and deploy your npm projects as docker images or snapshot them in VirtualBox, but you find that one of your clients, or your next boss, finds docker images too complicated to use. They require a separate image registry, which you have to host yourself if you don't want to publish it to DockerHub, and you have to learn a whole new suite of commands like docker inspect, docker exec. You have one week left on an important deadline and decide to just depend on package-lock.json files and specifying version numbers exactly in package.json like some-package==0.3.0, rather than a range like some-package^0.3.0 which means "any version equal to 0.3.0 or later".
    • Half-life - 16 or more years. A way to gracefully degrade from a purely virtualized, ideal, elegant solution to one that meets your deadlines or the preferences of your teammates is something that is hard to define, but will rarely go out of style.

  • Create - Generating, Planning, Producing

    • Example: After configuring a website for a final project in this Web Engineering class, you begin to think that there must be a much simpler way to automate the many different steps, now that you understand the purpose of the different parts and have experienced some of the things that can go wrong. You create a code generator, a set of scripts, or an AI-effectuated system that can produce the final website with a short compact description. (You also create another Perfect Markup Language consisting entirely of emoji's to represent it).
    • Half-life - 24 or more years. The ability to simplify is in many ways much harder than the ability to do complex things, and projecting forward, most possible futures will reward someone who can identify needs, adapt, and create new solutions, and make it easier for their community to get things done. On the opposite end of the spectrum, a more complex future may involve online applications that incorporate AI agents traveling between servers, decentralized peer networks, mesh routing on short-lived drones or robots, and more. A single package.json and npm project now seem woefully inadequate to describe and coordinate such a system. But learning how to use abstraction, modularity, testing, and program design will still be useful. (See Software Construction and AI Self-Hosting, next quarter).

GitGraph Practice

In your assignments and frontend directory, create a new subdirectory called week7 and add a README.md file similar to this one

https://github.com/TheEvergreenStateCollege/upper-division-cs/blob/main/web-24wi/assignments/ppham/week7/README.md

We will practice adding GitGraph mermaid diagrams to visualize our git branch workflow, as well as common mistakes that can happen.

https://mermaid.js.org/syntax/gitgraph.html