User:DSkrien
From Foss2Serve
(Difference between revisions)
(→Possible Course Activities using OpenMRS) |
m |
||
| (2 intermediate revisions by one user not shown) | |||
| Line 16: | Line 16: | ||
'''Issues for the instructor''': | '''Issues for the instructor''': | ||
| − | + | * How do I find specific sections of such a large code base that are appropriate for my students? | |
| − | + | * I want a sequence of tasks for the students that gradually get them deeper into the FOSS code base. | |
| − | + | * I want to have students work in groups of 4 consisting of 2 teams of 2 (I have a class size around 24). This way they get experience working in pairs, as in pair programming, and having to coordinate between two teams. Over the semester, should I change the groups/teams? Should I let the students change groups/teams? To handle grades, I would give each group a common grade and then adjust the member's grades based on feedback from their group members (every student grades their coworkers) | |
| − | + | * I need to spend some time getting them set up to install and run the software and download the code base. | |
| − | + | * I need to spend some time teaching them to use GitHub, which is non-trivial. I would like to set up a GitHub account for each team of two and each group of four. Each group would fork the FOSS code base and each team would create a branch. The two branches would need to be merged before a pull request is issued to the FOSS project. | |
| − | + | ||
| − | + | * At every step, I want to have the students update a blog post (one per group) with what they did and problems they encountered when trying to do it. I need to show them how to set up the blogs and learn to use them. | |
| − | + | '''Possible Specific Tasks for Students''': | |
| − | + | * Have the students start by doing load testing and usability testing of the whole package to get a feeling for what the whole package is for and how to use it. | |
| − | + | * Work on the documentation, e.g., examples of how to use a feature, to clarify any confusing sections the students encountered when first using the software. | |
| − | + | * Take one package from the FOSS source code and present an overview of its design. | |
| − | + | * Write and run unit tests for files in the package to get a feeling for unit testing and regression testing. | |
| − | + | * Have students review code and present to the class the _worst_ example of elegant code they found in their package and explain how they would fix it. | |
| − | - Have the students find and fix bugs and submit their code. | + | * Have students actually refactor and submit a more elegant version of the code they found to be inelegant. Note that they are not yet fixing bugs--they are just cleaning up existing code. |
| + | |||
| + | * Have the students find and fix bugs and submit their code. | ||
| + | |||
| + | |||
| + | [[Category:POSSE 2016-06]] | ||
Latest revision as of 01:36, 7 February 2017
Dale Skrien
Dale Skrien is a Professor in the Department of Computer Science at Colby College. Colby College is a liberal arts college in Waterville, ME, with approximately 1800 students.
Dr. Skrien has been teaching computer science at Colby for approximately 30 years. His research interests have included algorithmic graph theory, computer music, and computer science educational software. He has authored or co-authored three computer science or mathematics textbooks.
Dr. Skrien enjoys snowshoeing in the Maine woods in the winter and relaxing on the lakeshore in the summer.
First Ideas for Possible Course Activities using FOSS
My son, when he was a summer intern during his college years, was initially given a job as tester. It seemed like a very appropriate way to productively find out what the software does. I think it might be a good way for my students to begin working on FOSS. Maybe load testing and usability testing could be the first steps, followed by unit testing. At this point, the students will be more familiar with the whole project from a user's perspective as well as a developer's perspective and so can begin looking at small sections of code to fix bugs, refactor it to clean up working code, or to look at a larger section to understand the design of it.
More details for Possible Course Activities
Issues for the instructor:
- How do I find specific sections of such a large code base that are appropriate for my students?
- I want a sequence of tasks for the students that gradually get them deeper into the FOSS code base.
- I want to have students work in groups of 4 consisting of 2 teams of 2 (I have a class size around 24). This way they get experience working in pairs, as in pair programming, and having to coordinate between two teams. Over the semester, should I change the groups/teams? Should I let the students change groups/teams? To handle grades, I would give each group a common grade and then adjust the member's grades based on feedback from their group members (every student grades their coworkers)
- I need to spend some time getting them set up to install and run the software and download the code base.
- I need to spend some time teaching them to use GitHub, which is non-trivial. I would like to set up a GitHub account for each team of two and each group of four. Each group would fork the FOSS code base and each team would create a branch. The two branches would need to be merged before a pull request is issued to the FOSS project.
- At every step, I want to have the students update a blog post (one per group) with what they did and problems they encountered when trying to do it. I need to show them how to set up the blogs and learn to use them.
Possible Specific Tasks for Students:
- Have the students start by doing load testing and usability testing of the whole package to get a feeling for what the whole package is for and how to use it.
- Work on the documentation, e.g., examples of how to use a feature, to clarify any confusing sections the students encountered when first using the software.
- Take one package from the FOSS source code and present an overview of its design.
- Write and run unit tests for files in the package to get a feeling for unit testing and regression testing.
- Have students review code and present to the class the _worst_ example of elegant code they found in their package and explain how they would fix it.
- Have students actually refactor and submit a more elegant version of the code they found to be inelegant. Note that they are not yet fixing bugs--they are just cleaning up existing code.
- Have the students find and fix bugs and submit their code.
