TR 3:15 - 4:45 pm Arts & Sciences (CAS) 134
Week 3 Class 6 Thu Sep 10 Posted: Sep 10
Announcements:
Similar Action Words
Many action words are similar in meaning, but can vary in specificity or in details that they imply.
| Word 1 | Word 2 | Explanation |
|---|---|---|
| Delete | Remove | "Delete" often implies a permanent action, while "Remove" can be less final or reversible |
| Approve | Accept | "Approve" sounds authoritative, while "Accept" is more general |
| Invite | Connect | "Invite" is very specific, suggesting a request for participation, whereas "Connect" is broader |
| Create | Add | "Create" is making something new, whereas "Add" can mean including something that already exists |
| Subscribe | Register | "Subscribe" is ongoing engagement, while "Register" is often a one-time action |
| Approve | Validate | "Approve" is a decision or permission, while "Validate" suggests checking or confirming correctness |
| Merge | Link | "Merge" is combining into one, whereas "Link" connects them without combining |
| Submit | Send | "Submit" is submission to a process, while "Send" is transferring information |
| Stop | Pause | "Stop" is final, while "Pause" is temporary |
| Cancel | Stop | "Cancel" is preventing something from starting or finishing, whereas "Stop" is halting an ongoing action |
Note that the customer may not realize the difference between these terms, and say one when they mean the other.
Exercise 11: GitHub Username GitHub Classroom is no more. Instead, we are using Classroom 50. The process for allowing you to create a repository has changed and is as follows: 1) Add you to the UACPSC GitHub Organization, and 2) Add you to the roster for the course. To do so, I need your GitHub Username. If you don't provide it, you won't be able to do the projects and some exercises.
The title of this exercise is a link to the form where you can enter your GitHub Username.
Once I add you to the roster, you will receive an invitation to join the UACPSC GitHub Organization. You will need to join in order to create repositories. Note that this differs from the GitHub Classroom process of the past.
Due Friday, Sep 11 by 9 am.
Class
Unless stated otherwise, all exercises are due by 4 pm on Fri Sep 11
Project 1 is due Monday, September 21 at 11:59:59 pm, in the file Requirements.md in a GitHub Organization UACPSC repository. You will need a GitHub account, give me your GitHub Username, and accept the invitation to join the GitHub organization UACPSC. Once you are all setup, an invitation link to create the repository is in Brightspace.
At your place of work, you need to submit a formal report describing the project's current state. Write a report of your individual and team activities, including these primary sections:
1. User Stories
User Stories with title, description, estimate, and space for priority
This will be shown to the customer. This section should not contain any information that a customer should not see.
2. General Process
Details of the overall process and procedure that created the Estimates
This will be shown to the customer, so only data on the User Story cards from section 1 should be shown.
3. Background Data
Details on spread, assumptions, issues, etc.
How did the team interaction work, and what did and did not work well
This will not be shown to the customer. It is for your supervisor.
In other words, the report describes all the work and processes followed while creating the user stories and their estimates. The details of the general process and the general observations in Section 3 are in the form of a narrative, i.e., describe what you did, how you did it, and the result, ordered by time. The report's tone is professional, with a clear, consistent presentation.
The team created the User Stories and Estimates, but this report is an individual project. In your account, make changes to User Stories if they do not follow the guidelines given in the book. These changes are especially crucial for the Title and the Description. Split User Stories if the Estimate is too large. Explain any changes in your report.
The report uses plain-text formatting syntax Markdown. Markdown is an almost universal format for text formatting in software development. Due to its direct conversion to HTML, Markdown has replaced HTML and other plain-text formatting languages in SE. It has become so popular that it is a new document type in OneDrive.
You will use git to work on your report. Assuming a username of jdoe@uakron.edu, the steps are as follows:
jdoe@uakron.edu
Note: All commits must have non-blank commit messages. Any non-blank commit messages will not be accepted, leading to a 0 on the entire project.
A GitHub Codespace is available for this project. See the guide GitHub Codespaces.
After you have committed your final change to the project, you must run your report through a report check to see if it follows many of the Markdown requirements of the project. To do so, create a GitHub Codespace for the project. When in there, enter the command:
You should see a clean report. If it finds anything, fix it and rerun the checkmd command.
The checkmd is a custom command created for this project to verify specific Markdown requirements. A clean run does not mean you have nothing wrong with your project.
Upload an terminal session of your report successfully passing the checkmd program.
To demonstrate this, you will record a terminal session using asciinema. It records the commands you enter and the output the command produces. asciinema is already installed in the GitHub Codespaces image. You can also install asciinema on Linux/WSL/macOS.
asciinema is relatively straightforward to use.
You can play, pause, skip, etc. You can also copy the commands as text. Note that the replay even includes your pauses and any delay as the command is run.
At the end of the terminal session, asciinema will show a URL. Anybody can use this URL to view the session. This is what you will submit for the exercise to the link in the exercise title. The URL should not contain "connect" or be a local file. Test your URL in a browser; an incorrect URL will receive a 0.
Submit the URL via this form: Project 1
The report content, format, and involvement in team activities are all considered for your score.
Think carefully about how you present the report, including using Markdown. Remember, the User Stories form an unordered set, not an ordered list.
Start by reviewing your user stories, particularly the titles. Titles that do not have an action term, or have a poor action term, will be counted off on your score for this exercise.
As a team, create estimates for the user stories by using the planning poker procedure described on pages 48-49 of the book.
When the team reaches a consensus for the estimate, place the estimate at the bottom left of the User Story as indicated by the example, e.g., "Estimate: 1 day" or "Estimate: 3 days".
Individually, each team member will turn in to Brightspace individual notes that include for each round of planning poker:
If the team is not able to come to a consensus, table that User Story and go on to another one.
The notes are due by the end of class. They can be in the form of a PDF (print to file from a computing device), or a JPG (picture taken via your phone).
The more you work with the user stories, the more you will find improvements to them. Be sure to make those improvements. Also, you may think of additional user stories. Be sure to add them.
TA: Mr. Hayden Cowan hc138@uakron.edu