BillionaireClubCollc
  • News
  • Notifications
  • Shop
  • Cart
  • Media
  • Advertise with Us
  • Profile
  • Groups
  • Games
  • My Story
  • Chat
  • Contact Us
home shop notifications more
Signin
  •  Profile
  •  Sign Out
Skip to content

Billionaire Club Co LLC

Believe It and You Will Achieve It

Primary Menu
  • Home
  • Politics
  • TSR
  • Anime
  • Michael Jordan vs.Lebron James
  • Crypto
  • Soccer
  • Dating
  • Airplanes
  • Forex
  • Tax
  • New Movies Coming Soon
  • Games
  • CRYPTO INSURANCE
  • Sport
  • MEMES
  • K-POP
  • AI
  • The Bahamas
  • Digital NoMad
  • Joke of the Day
  • RapVerse
  • Stocks
  • SPORTS BETTING
  • Glamour
  • Beauty
  • Travel
  • Celebrity Net Worth
  • TMZ
  • Lotto
  • COVD-19
  • Fitness
  • The Bible is REAL
  • OutDoor Activity
  • Lifestyle
  • Culture
  • Boxing
  • Food
  • LGBTQ
  • Poetry
  • Music
  • Misc
  • Open Source
  • NASA
  • Science
  • Natural & Holstict Med
  • Gardening
  • DYI
  • History
  • Art
  • Education
  • Pets
  • Aliens
  • Astrology
  • Farming and LiveStock
  • LAW
  • Fast & Furious
  • Fishing & Hunting
  • Health
  • Credit Repair
  • Grants
  • All things legal
  • Reality TV
  • Africa Today
  • China Today
  • "DUMB SHIT.."
  • CRYPTO INSURANCE

Teaching High School Students Software Engineering: Prerequisites

:::info
Authors:
(1) Joseph Latessa, Department of Computer Science Wayne State University, Detroit MI USA ([email protected]);
(2) Aadi Huria, Senior, Salem High School Canton, MI USA ([email protected]);
(3) Deepak Raju, Senior, Salem High School, Canton MI USA ([email protected]).
:::
Table of Links
Abstract and Introduction
Related Work
Project Prerequisites
Project Implementation
Insight and Reflections
Conclusions, Acknowledgement and References
3 PROJECT PREREQUISITES
We will now take a closer look at each part of the project’s development. Throughout the summer, our meetings took place using Zoom at intervals of one or two meetings per week and each session lasted between one and two hours.
3.1 Tools and Installation
After introductions, a discussion about scheduling, and a discussion about what we planned to accomplish over the summer, we decided upon and installed our development tools to ensure a consistent development environment. This involved stepping through the WSL installation process and setting up Ubuntu user accounts. We then installed Windows Terminal as our command line application and Visual Studio Code as our preferred text editor. We then visited github.com to explore GitHub’s features and establish user accounts.
3.2 Linux Shell Familiarization
At our next meeting, we explored Windows Terminal and entered basic commands to navigate the directory structure. Basic commands such as ls, pwd, cd, mkdir, touch, mv, cp, and clear were discussed and demonstrated. We practiced creating directories, creating files, moving files, and displaying a directory’s contents. In addition to navigating the command line on one’s local machine, automation with GitHub Actions requires command line navigation on GitHub’s runners. A familiarity with the command line will therefore be needed later in the project.
3.3 Introducing Version Control
For the next few meetings, we focused on learning version control. To assist with this learning and because the students had previous experience writing Python, we implemented a simple calculator application in Python. The main function provided a menu for users to choose arithmetic operations and to input operands. Each operation such as addition, subtraction, and raising a number to a power was a separate function that received the requisite operands as parameters and returned the result. A skeleton of the Python code was provided, with unimplemented function stubs that all returned zero.
\
The students learned to create a new repository on GitHub and clone the new repository to a directory on their local machine. Git was introduced using terminal commands rather than through a GUI to provide further command line practice, which will be useful when executing commands on GitHub’s runners. Upon cloning the remote repository, we discussed the concepts of distributed versus centralized version control and discussed the pros and cons of each system. The students added the new calculator skeleton to the repository and pushed it to the remote. The Git commands clone, pull, status, log, add, commit, and push were introduced and applied.
\
Since two students were working on the project, one student implemented the addition function, and the other implemented the subtraction function. Each committed their local changes and pushed those changes to the remote. Each screen-shared while implementing the changes, and we noted how the second person to push needed to pull the changes already made to the remote before pushing one’s own. It was also noted that having made changes to different functions, the differences could be reconciled automatically without giving rise to a merge conflict.
\
We next discussed the concept of branching and the benefits of developing features on specific feature branches. We created separate branches for the implementation of the multiplication and power functions. One student implemented multiplication and the other implemented power. Continuing to practice staging and committing files, we committed our local feature branches and learned to establish remote tracking for new branches. git diff was also introduced to compare un-staged changes with the most recent local commit and to compare other commits using the relevant commit hash. We then applied git merge to locally merge our feature back into our local main branch. Since each student had changed different parts of the code, it was again noted that the merge was automatic and gave rise to no merge conflict.
\
Next, we specifically edited the code to create and demonstrate a merge conflict. Having both edited the same section of the code, the students learned to manually resolve merge conflicts.
\

\
We concluded our introduction to version control with a look at pull requests and forks. In addition to merging branches locally, we discussed a typical workflow in which a developer without push access to the main branch would propose changes by submitting a pull request. We also looked at creating repository forks and saw how pull requests could be submitted across forks. The final calculator function, a square root function, was merged into the main branch through the submission and approval of a pull request.
\
To prepare for the next phase of our project, the students created their own forks of the JETSCAPE [1] and GOMC [2] application repositories as well as the JETSCAPE and GOMC website repositories. Most of the time spent writing these tests would pertain to the website repositories.
3.4 Introducing Continuous Integration
To introduce the concept of continuous integration, we created a simple Python script that uses the requests.get method to query a website and return a status code. The script can be run manually at the command line and accepts a URL as a command line argument. If the status code returned is 200, a success message is printed, and the program exits normally. If another code is returned or if there is no response from the server, the program terminates having raised an exception. We tested the program manually on popular websites like google.com and on URLs we knew to be invalid.
\
We then discussed the usefulness of having a test run automatically either on a set schedule or whenever there are changes to a specified branch. Since there are two students and two websites (JETSCAPE [1] and GOMC [2]), each student focused on a specific website and worked on their locally cloned fork. We committed the Python script that checks for reachability and discussed the YAML file steps required to generate the automation. We decided that the test should run on push operations and pull requests to the main branch and run once per day at a specific time. We discussed the job steps including running on ubuntu-latest, checking out the current repository using GitHub’s checkout action, and executing terminal commands on GitHub’s runners to install the requests library using pip. We discussed that this step would be performed every time the workflow executes because each job runs on a new instance of ubuntu-latest. We then added the job steps to navigate to the tests/ folder on the runner and to execute the python3 command calling the URL reachability script. The students committed, pushed to the remote forks, and checked the Actions tabs on GitHub to review the running tests and their respective logs.
\
Equipped with prior knowledge of the Python language and having now gained a familiarity with the command line, version control, and automating workflows with GitHub Actions, the students were ready to start researching and experimenting with writing and deploying the automated tests.
\
:::info
This paper is available on arxiv under CC BY-NC-ND 4.0 DEED license.
:::
\

Welcome to Billionaire Club Co LLC, your gateway to a brand-new social media experience! Sign up today and dive into over 10,000 fresh daily articles and videos curated just for your enjoyment. Enjoy the ad free experience, unlimited content interactions, and get that coveted blue check verification—all for just $1 a month!

Source link

Share
What's your thought on the article, write a comment
0 Comments
×

Sign In to perform this Activity

Sign in
×

Account Frozen

Your account is frozen. You can still view content but cannot interact with it.

Please go to your settings to update your account status.

Open Profile Settings

Ads

  • Original Billionaire128 iPhone Case

    $ 15.50
  • Billionaire128 Liquid Gold Drawstring bag

    $ 22.50
  • Original Billionaire128 Old School Bucket Hat

    $ 28.50
  • News Social

    • Facebook
    • Twitter
    • Facebook
    • Twitter
    Copyright © 2024 Billionaire Club Co LLC. All rights reserved