<!--   Study materials and lab tasks will be posted here.   -->

The only due item this week is your Peer Assessment 4 feedback on the design documents you have received, due on Wednesday, April 7.

You should of course be working towards completing your project so you can present all its features at the last progress report meeting that will take place this week.

There is no lab task, but the TAs will be available for any make up lab tasks necessary.

Our topic this week is refactoring. As everybody is certainly busy, it is an optional topic.

If you do not know how to rename variables in Eclipse using the refactoring facilities, I highly recommend watching the first part of this short video.

For more on refactoring, you can watch this instructor video on it. Feel free to do this after the term is finished.

There is no lab task, but the TAs will be available for any make up lab tasks necessary.

1. Learn about refactoring
2. Provide feedback on the design documents you received before the deadline
3. Prepare for the last progress report meeting with the customer
4. All requirements must be implemented and tested
5. Documents are being finalized

There are two things due this week:

1. Peer Assessment 4 will be posted on Thursday (Mar 25). You will be submitting your design document on Wednesday, March 31 to receive feedback. As usual, you will be graded for the feedback you will provide.
2. For the lab task, you will demonstrate how you debugged one of the bugs you team received last week.

Our topic this week is debugging. Start by watching these two videos on debugging in Eclipse: 1. Breakpoints 2. Debugging

When using Gradle, the process is a bit more involved, so next watch this instructor video on how to set up Gradle for debugging. The code in the video is in the JavaFXSample project in this github repository.

Your team should divide the bug reports you received last week among the team members. You should respond to all the bug reports assigned to you on github.

Choose one of the bug reports assigned to you. Use the debugging facilities of Eclipse (set breakpoints, step through etc) to trace the source of the bug and fix it. Demonstrate the above process to the TA (revert to a commit that still has the bug to demonstrate if necessary).

1. Learn about debugging
2. Produce a complete draft of your design document and submit it by the deadline
3. Ensure other documents are also being worked on
4. All requirements must be implemented and ready for testing/debugging

There are two things due this week that are both related to bug reporting:

1. For Peer assessment 3, you are required to submit 3 bug reports for each of the two projects you are evaluating. See the PeerScholar link for more details.
2. For the lab task, you will choose one of these bug reports and demonstrate the bug to the TA.

Our topic this week is bug reporting. Start by watching Section 4 (Bug Reporting) of this online course.

For the bug reports that you will create this week, use the list of sections in this video. You should also add the input you tested with as an attachment, and list which MusicXML viewer(s) you tested with.

If you'd like to learn more about bug reports, this is a great but longer online course. If you have time for only one video from it, watch this one.

Choose one of the bug reports you created this week, demonstrate to the TA the incorrect behaviour, and present the bug report.

1. Learn about bug reporting
2. Produce constructive bug reports for peer systems
3. Implementation on all new requirements must be underway
4. Your system must be able to handle simple tabs for all three instruments by now

There are two things due this week:

1. The lab task as described below.
2. The current version of your system. See the PeerScholar submission link for more details.

This week we take a look at testing again. These slides discuss the two topics we will focus on:

1. Test coverage. Start by watching this instructor video on the topic. The code in the video is in the TestCoverage project in this github repository. Next, update your system to use JaCoCo and create test coverage reports. Work on improving the coverage of your test code.
2. GUI testing. Start by watching this instructor video on the topic. The code in the video is in the JavaFXSample project in this github repository. Next, check out the TestFX github page for more information. Add appropriate GUI test cases to your system.

Demonstrate to the TA the code coverage for the part of the code that you are responsible. Briefly discuss how you plan to improve the coverage of your tests.

1. Learn about code coverage
2. Learn about GUI testing
3. Repeated from last week: Study the additional requirements posted about the project and start implementing them
4. Produce a version of the system that implements as many requirements as possible for submission on Wednesday, Mar 17.

The only thing due this week is the lab task below.

Optional but recommended: For Peer Assessment 2, rate the feedback you received (as a team), and/or rate your group members on their contributions until the midterm submission.

The final submission will be similar to the midterm submission, except it will also contain a Design Document (worth 20% of the final submission). Our target this week is to start working on this document by creating diagrams describing the system you are developing.

Start by watching this online course on UML and its diagrams. Focus on the following types of diagrams: activity, class, sequence, and object. Study other types of diagrams for your own interest.

Select a tool that you will use for such kind of diagrams (as a software engineer you'll have to do these quite often). You can use any number of tools (see complete list below) including dedicated UML tools, such as PlantUML, or drawing tools with UML support such as diagrams.net.

These slides present the purpose of the design document and emphasize some of the points made in the course as well.

You may also find useful these tutorials on different kinds of UML diagrams, as well as this list of UML tools.

Each student must draw two diagrams describing an aspect of the system.

The two diagrams cannot be of the same type. Choose two of the following types of diagrams: activity, class, sequence, and object.

Groupmates can choose the same type of diagram but they must describe a different part of the system, e.g. one prepares a sequence diagram related to input parsing, another prepares a sequence diagram related to MusicXML creation.

Describe both diagrams to the TA in the lab session.

1. Learn about design documentation and the corresponding UML diagrams
2. Create the first draft of the design document including the diagrams prepared for the lab task
3. Study the additional requirements posted about the project and start implementing them

The only due item this week is the midterm project submission for the project, which is due on Sunday, February 28 at 11:59pm. Submission instructions can be found in these slides.

There is no study material or lab task due this week. Any student that has missed a lab task will have a chance to re-take it during the Wednesday meeting (first come - first serve).

The progress report meetings for this week will be your chance to present your midterm submission to your instructor and, perhaps more importantly, to the TA that will mark it. It is recommended that you practice your presentation before the meeting so you can highlight all the cool features of your app, while showing all important use cases.

No lab task this week. The TAs will be available at the usual time for any make-up lab tasks required.

1. Study the peer feedback you will receive for your app
2. Finalize the code of your midterm submission as in the above instructions
3. Finalize all three documents
4. Submit midterm submission by Sun Feb 28
5. Prepare a nice demo/presentation for your app for the next progress meeting

This week lasts for two weeks due to Reading Week. There is a lab task due on the Wednesday after Reading Week as usual. The second peer assessment will take place over the space of these two weeks:

By Wednesday, February 17, submit a prototype + User Manual of your system as a team. Make sure that your instructions are clear so that your peers can run your prototype successfully. Note that you are not being graded on the quality of your prototype at this point. This is for you to receive feedback on what you have done so far.

By Wednesday, February 24, each student has to submit feedback on the prototypes and User Manuals that are assigned to them in PeerScholar. A rubric for how your feedback will be graded has been added to the Assess Phase description.

Our target this week is to start using Gradle to build our system, run our tests, and manage any library dependencies.

Start by watching this instructor video, on how to set up your Gradle build script in Eclipse. This should be all you need in order to use Gradle in your system so that your peers can run your system without worrying about library dependencies. The build script developed in the video is here. Replace the one in your system with it, and customize the main class name.

These slides present the main points about Gradle made in the video as well.

For more information on Gradle, this online course on Gradle basics, and this course on Gradle and Java will help you understand how to write Gradle build scripts, and what is happening behind the scenes. These courses do not use Eclipse, so focus on concepts rather than syntax.

For this week's lab task, you must complete the transition to using Gradle for your system. Demonstrate building and running your system using Gradle under Eclipse to the TA.

1. Learn about Gradle
2. Use Gradle in order to build and run your application and test code
3. Submit the prototype and user manual of your system by Wed Feb 17
4. Provide feedback on the prototypes and user manuals you will be assigned
5. Continue developing your application and test code and the documentation (Requirements, Testing, User Manual) of your system.

Apart from the usual lab task due during Wednesday's meeting, this week each student has to submit feedback on the Requirements Documents that are assigned to them in PeerScholar. A rubric for how your feedback will be graded has been added to the Assess Phase description.

Our target this week is to start on our system's testing. The system you are developing in this course must be fully tested. We will use the JUnit framework to do this.

Start by going through this online course. Focus on these videos: 1-5, 7-12, 14-17. You can ignore videos 6 and 13 on Maven. We will discuss Gradle and JUnit next week. Maven and Gradle projects have the same folder structure, so the rest of the course applies to our course. Videos 18 and after are more advanced features of JUnit that are good to know but not necessary for this course.

These slides present the main points about JUnit as well. To get the Counter example, check out the EECS 2311 project from https://github.com/biltzerpos/TeachingCode

You can find detailed information about JUnit 5 in its official documentation (use only as reference).

For this week's lab task, write 3 separate JUnit test cases for some of the code you have developed so far for the project. Describe them to the TA and demonstrate running them.

If your code is not easy to test (e.g. you have been working on the GUI), you can develop test cases for a part of the system written by one of your teammates.

1. Understand JUnit
2. Start writing test code for all the application code in your project
3. Start documenting the tests you are creating in a Testing Document (it will be part of the midterm and final submission)
4. Provide feedback on the Requirements Documents you will be assigned
5. Have a prototype of your system that runs end-to-end to demonstrate to your customer at the end of the week

Apart from the usual lab task due during Wednesday's meeting, this week your team has to submit a first draft of the Requirements Document. See the Peer Assessment link in eClass for more details.

Our target this week is to finish the material on git by learning about git workflows, as well as to learn what goes in a requirements document, including use cases and user stories.

First off, for those of you still unsure about merges, when do they fail, what is a fast-forward merge etc, you might find this explanation helpful.

Next, we will learn about a method to organize the branches in our repository called Gitflow. Read the original description, as well as this explanation.

These slides present the main points from the above links, and describe how branches must be organized in EECS 2311.

Next, complete Sections 2 and 3 of this course (login with Passport York credentials). It is a very nice introduction to requirements and use cases. I particularly like the fact that clarity is emphasized over formality. For your Requirements document, also focus on a clear set of requirements and use cases without worrying about including all possible sections or following a particular format.

Prior to the lab task demonstration, your team must organize the branches in your repository as outlined in the slides above.

For the lab task, demonstrate committing to your personal branch, then merging the changes to the develop branch, and finally pushing both the develop branch and your personal branch to github. To avoid conflicts, remember to pull the develop branch just before starting your demonstration.

1. Understand gitflow
2. Organize your team repository according to gitflow
3. Learn about requirements, use cases and user stories
4. Finalize and submit the first draft of the system's Requirements document
5. Your master branch now has the latest stable version of your system. You can always switch to it and demo to your customer.

Only the lab task is due at the end of the week. The week after you will be submitting a first draft of the Requirements Document for the system, so you get started on it.

Our target this week is to learn how to work with branches in git, including resolving conflicts when they arise.

Start by completing this course (login with Passport York credentials). It is a very nice, detailed introduction to local and remote branches, including resolving conflicts. Even though this course is using git in the command-line fashion, it is important to understand it thoroughly. A lot of the command-line terminology shows up in Eclipse. If you are pressed for time, you can skip Section 5 on stashing changes, although it is a powerful tool you should learn how to use at some point.

Once you have completed the course above, watch this instructor video on how to do some of the command-line operations in Eclipse, using Egit. You can find the Egit documentation through Eclipse (Help → Help Contents). This tutorial is also quite helpful (you might want to become familiar with the way Egit decorates icons - scroll towards the end of the tutorial).

Finally, this is not required studying, but this is a handy page that lists everything you might need to remember about command-line git. It includes instructions on how to make your README file on github look nice.

For this lab task, you will join the TA in groups of 2 or 3. Demonstrate creating a conflict by editing the same file at the same time. After one student pushes the update to the team repository, another must pull and resolve the conflict in any way they see fit. Each student must demonstrate the process of resolving the conflict.

1. Understand local and remote branches
2. Learn what causes conflicts and how to resolve them
3. Create a first runnable version of your system to demo during your progress report
4. Continue with your draft of the system's requirements (what does the system do for the user)

Only the lab task is due at the end of the week.

Our target this week is to learn the basics of git and github.

Start by making sure that all team members have completed the setup demonstrated in lecture. These slides list all the steps for that setup. A video of the instructor going through these steps can be found here. Added January 19: A short video on resolving .classpath conflicts.

Next, read the first three chapters of the Pro Git Book. Focus on the concepts of version control, not the command-line syntax, as we will use git through Eclipse. This set of slides describes the important concepts from these chapters as well.

For those of you that prefer videos to reading, this course is a great introduction to git (login with Passport York credentials). It also focuses on the command-line syntax of git which will not be a focus in this course, so focus more on the version control concepts.

Prior to meeting the TA, ensure that your group repository contains a change to one of the files that does not exist on your machine (ask a teammate to push a change).

Demonstrate pulling the change, making a new change, and pushing it to the online repository.

1. Understand the basics of git
2. Set up group repository, all members are able to push/pull
3. Start coding
4. Start on a draft of the system's requirements (what does the system do for the user)
5. Prepare for the first meeting with your customer

Topic: Course Introduction

Slides: Module 0 - Course Introduction

<!--   ===== Week 1 =====   Topic: Introduction to the project   {{:module01-projectintroduction.pdf|Module 1 - Project Introduction}}   [[http://www.paulowe.com/venn_diagram_061119/activity.html|Example Venn diagram tool]]     ===== Week 2 =====   Topic: Version Control   Slides: {{:module02-git.pdf|Module 2 - Version Control}}   Useful links:   [[https://book.git-scm.com/book/en/v2|Pro Git ebook]]   [[http://www.vogella.com/tutorials/EclipseGit/article.html|EGit tutorial]]     ===== Week 3 =====   Topics: Gitflow   Slides: {{:module03-gitflow.pdf|PDF}}   Useful links:   [[https://www.campingcoder.com/2018/03/git-merges-demystified/|Git Merges Demystified]]   [[https://nvie.com/posts/a-successful-git-branching-model/|Original Gitflow description]]   [[https://www.campingcoder.com/2018/04/how-to-use-git-flow/|Another Gitflow description]]   ===== Week 4 =====   Topics: Test-Driven Development, JUnit   Slides: {{:module04-junit.pdf|PDF}}   Code: Check out the EECS 2311 project from [[https://github.com/biltzerpos/TeachingCode|https://github.com/biltzerpos/TeachingCode]]   Useful links:   [[https://junit.org/junit5/docs/current/user-guide/| JUnit 5 documentation]]           ===== Week 5 =====   Topics: Test code coverage, GUI Testing   Slides: {{:module05-testcodecoverage.pdf|PDF}}   GUI Testing example in the [[https://github.com/biltzerpos/TeachingCode|EECS 2311 github repository]]       ===== Week 6 =====   Topics: Midterm Submission   Slides: {{:module06-midtermsubmission.pdf|PDF}}   ===== Week 7 =====   Topics: New project requirements, Continuous Deployment   Slides: {{:module07-continuousdeployment.pdf|PDF}}   [[https://github.com/biltzerpos/counterci|Github repo with continuous deployment]]   ===== Week 8 =====   Topics: Design Documentation   Slides: {{:module08-designdocumentation.pdf|PDF}}   [[http://www.tracemodeler.com/articles/a_quick_introduction_to_uml_sequence_diagrams/|Sequence diagram tutorial 1]]   [[https://online.visual-paradigm.com/tutorials/sequence-diagram-tutorial/|Sequence diagram tutorial 2]]   [[http://en.wikipedia.org/wiki/List_of_Unified_Modeling_Language_tools|List of UML tools]]       ===== Week 9 =====   Topics: Issue tracking   Slides: {{:module09-issuetracking.pdf|PDF}}   [[https://developer.mozilla.org/en-US/docs/Screening_duplicate_bugs | How to find reported bugs]]   [[https://bugs.eclipse.org/bugs/query.cgi|Search for Eclipse bugs]]         ===== Week 10 =====   Topics: Debugging   Slides: {{:module10-debugging.pdf|PDF}}           ===== Week 11 =====   Topics: Refactoring   Slides: {{:module11-refactoring.pdf|PDF}}         ===== Week 12 =====   Final Submission   Slides: {{:module12-finalsubmission.pdf|PDF}}   -->