TR 3:15 - 4:45 pm Arts & Sciences (CAS) 134
Week 4 Class 7 Tue Sep 15 Posted: Sep 15
Announcements:
Exercise 11: GitHub Username
There are three steps to allow you to create repositories for the projects and some of the exercises:
For 3, I indicated in your feedback for Exercise 11 if this was not accepted yet, then you need to accept the invitation
Invitations are email to the email account for your GitHub Username. I assume in most cases this is your UA email.
You can also view these on your GitHub Organization Page
If you accept the invitation, I will give you full credit for this exercise.
Windows File Explorer & WSL
To open the Windows File Explorer on the current directory in WSL:
The . means the current directory in WSL. You can also open a file explorer.exe Requirements.md. If you open a path it has to be in Linux format, e.g., C:\Users\JohnDoe\Documents would be /mnt/c/Users/JohnDoe/Documents.
Assumptions
I noticed that many of the assumptions mentioned are about the difficulty of implementation. This is not what the book discusses. Instead, they are assumptions about what the user story means. The only person who can answer those assumptions is the customer.
From now on, label assumptions about the user story as assumptions and assumptions about implementation as implementation.
Dependencies
I see a lot of user story estimates where the assumptions include the completion of a previous user story. This is a dependency. Avoid dependencies at all costs. For example, Add … does not have to be completed before Delete …. Obviously there will be some dependencies, but they are to be at the user-story level, not the implementation level.
Class
Exercise 13: Commit to Project 1 Repository
Following the procedure given in the assignment and demonstrated in class, contribute at least one commit to the Project 1 repository. This must be a valid and useful commit.
git CLI to make the commit. You can do this wherever you have the repository cloned. You can even do this in a GitHub Codespacegit commits:
You can see your commit messages with the git log command.
Unless stated otherwise, all exercises are due by 4 pm on Wed Sep 16
Your management is concerned that your team does not have a complete set of user stories. The first problem is low recall, i.e., the team is not capturing all the user stories the customer needs. The second problem is that without not enough work, the organization will have to let some of the team members go cut everybody's pay.
The customer met with their team and returned with a list of potential user-story titles. These possible new user stories fall into one of the following categories:
Each team member will fill out the form for your team. The form will not be available until your team meeting time.
Create a new user story, or multiple user stories, for each of these valid potential user stories. This includes fixing any title issues and adding a description. Also, take this time to fix any existing user stories.
If you have any additional time, then create more estimates. As you did before, keep track of details for the next team meeting when you will submit any estimate details.
There is nothing to upload for this exercise. Complete the provided form during class time.
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.
TA: Mr. Hayden Cowan hc138@uakron.edu