GithubHelp home page GithubHelp logo

braughtg / dickinsonhfoss-comp190 Goto Github PK

View Code? Open in Web Editor NEW
0.0 2.0 0.0 45.76 MB

Description, materials and preliminary assessment of the course "Tools and Techniques for Software Development (COMP 190)" prepared with partial support from foss2serve through the Software Freedom Conservancy.

dickinsonhfoss-comp190's Introduction

Dickinson H/FOSS - Tools and Techniques for Software Development (COMP 190)

Introduction:

Beginning in Fall 2016 Dickinson College began offering a year-long senior capstone course in which students engage with Free and Open Source Software (FOSS) projects and often those with humanitarian objectives (i.e. HFOSS projects). A full report on this capstone and its materials is also available. Based on our experiences with this senior capstone we significantly redesigned our curriculum beginning fall 2019 so that the knowledge, experiences and technical skill development necessary for H/FOSS participation occurs earlier and is distributed across a sequence of courses.

The first course in that sequence is COMP 190 - Tools and Techniques for Software Development,:

An introduction to the Unix command line environment, shell scripting, system administration, debugging tools and version control. Skills developed will be applied in the context of a Humanitarian Free and Open Source Software (HFOSS) project. Case studies of social, legal and ethical issues raised by computing and computing for the greater good will complement the technical skill development.

The stated learning objectives for the course are:

Students will:

  • gain proficiency with command line interaction with a Unix operating system including installation and configuration of software, shell scripting and basic system administration tasks.
  • gain proficiency with modern software development tools and their common uses including a debugger and a version control system.
  • deepen their understanding of social and ethical issues in computing and their appreciation of computing for the greater good.
  • [Writing in the Discipline (WiD) goal] develop their ability to produce clear, concise, technical writing for developers.

Our website contains the full details of the Dickinson computer science curriculum and highlights the H/FOSS course sequence (190/290/390/491/492) in the Tools & Practices area.

This repository will be a static snapshot and review of the materials for the COMP 190 course following its first offering in fall 2020. Please feel free to reach out if you are interested in most recent revisions of the materials.

Course Context:

COMP 190 - Tools and Techniques for Software Development has been designed to be taken in the first semester of a student's second year. It is a required course for both computer science majors and minors, but is open to students from any major. Prior to taking COMP 190, students will have completed two introductory computer science courses, typically with one being procedural (Python) and one being object oriented (Java). However, these prerequisites primarily serve to ensure maturity in the discipline rather than the specifics of any particular programming language or paradigm.

Dickinson counts courses rather than credit hours and COMP 190 counts as 1/2 course (equivalent to 2 credit hours). As such, the course would, under non-Pandemic conditions, meet for 75 minutes once per week for 14 weeks plus a three-hour final exam period each semester. To reach 1/2 course credit, there is also a nominal expectation of 3 to 4 hours of work outside of class each week.

The semester in which this course was developed and first offered (fall 2020) was taught remotely due to the COVID-19 pandemic. This presented numerous challenges. The result was that there were 11 instead of 14 meetings, meetings were shortened to 10-20 minutes to adapt to asynchronous video delivery, and hands-on activities were designed as workshop style guided explorations to be completed with asynchronous support.

While produced for use during a semester of remote instruction, the presentation slides and activities should be readily and effectively adaptable to in-person instruction. The same introductory presentation could be used, with the expanded 75-minute meeting times providing additional time for discussion, question and answer, opportunities to review past activities, exploration of enrichment topics and/or for students to begin work on the activities. Development of materials for additional meetings, bringing the total to 14, will enable the course to more fully meet the stated learning objectives. The course is set to be offered again, in-person, in fall 2021. Materials will be revised and expanded at that time. Some detail on the revisions and expansions are included in the Reflections & Improvements section below.

Course Materials & Outline:

A Syllabus used in the course in fall 2020 is available. Logically the course is divided into three topics, each with individual course meetings and activities as outlined below. A brief description of each topic and the titles of each of its class meetings are provided. For each class meeting the Power Point slide deck for the introduction and the activities assigned are linked below. Alternatively, all of the material can also be downloaded as a single zip file.

For each meeting the introductory lecture is intended to be a near minimal introduction to the content necessary to begin the activities. They try to provide context, convey the big ideas, essential vocabulary, and to clarify particularly troublesome details. The activities then both both review the key points of the lectures and guide students through good practices for independent learning of new material. The activities ask a variety of questions ranging from very direct facts that focus in on essential terms and ideas, to reporting results that confirm and reinforce hands-on steps, to more open questions that ask them to apply or reflect on the content of the activity.

A. Unix Introduction

Students use a virtual machine environment (VirtualBox) to install a Linux operating system (LinuxLite). They then use this environment to develop facility with the command line interface, common gnu/linux tools and filters, simple shell scripting for task automation and performing basic system administration tasks such as installing software and managing users, groups and permissions.

  1. Operating Systems & Virtual Machines: Slide Deck | Activity Sheet
  2. Shell Commands: Slide Deck | Activity Sheet
  3. Command Line Tools and Filters: Slide Deck | Activity Sheet
  4. Shell Scripting: Slide Deck | Activity Sheet
  5. Basic System Administration: Slide Deck | Activity Sheet

B. Free and Open Source Software

Students begin to explore FOSS ideas and techniques. They look at the range of intellectual property rights (copyrights, trademarks, design rights, patents) and learn about Open Source licenses. They gain experience with the use of version control via git and GitHub (easily adapted to GitLab) and issue trackers in the context of FOSS projects. The traditional automake tools are used to build a FOSS project and provide practice resolving dependency issues. Finally, Docker is introduced as a mechanism for simplifying the setup of FOSS development environments.

  1. Intellectual Property, Sofware Licencing and FOSS: Slide Deck | Activity Sheet
  2. Version Control & a Branching Workflow: Slide Deck | Activity Sheet
  3. Version Control & Merge Conflicts: Slide Deck | Activity Sheet
  4. Building a FOSS Project: The gnu Autotools & Dependencies: Slide Deck | Activity Sheet
  5. Docker for FOSS Development: Slide Deck | Activity Sheet

C. Humanitarian Free and Open Source Software Participation

Students explore the structure, licensing and documentation of a number of mature HFOSS projects. This provides a basis for assessing and suggesting improvements to our own FarmData2 project project. Students install FarmData2 and ultimately have several opportunities to contribute to FarmData2 through the confirmation/refinement/clarification of issues and by making pull requests that improve documentation. It is worth note that activities in this section would be relatively easy to adapt to other H/FOSS projects of interest at a particular institution.

  1. H/FOSS Communities and FarmData2: Slide Deck | Activity Sheet
    • These activities are based in part on the state of the FarmData2 project at the time of writing. Thus, as FarmData2 continues to evolve some parts of this activity will become out of date (e.g. the installation process has been greatly simplified already). Those parts will need to be updated and adapted as the FarmData2 project progresses.

Student Surveys & Analysis

Students were asked to complete a Likert-scale pre/post course survey to assess their attitudes towards H/FOSS and their perceptions of what they learned in the course. The questions asked in the survey were identical for the pre/post surveys. The questions on the survey and the breakdown of student agreement with each statement before and after the course are shown in Figure 1. The full survey is also available as a pdf.

Survey Results

Figure 1: Pre/post course survey question and results. Each bar represents 100% of student responses with the size of each color representing the fraction of students that expressed the indicated level of agreement. The pre-survey was completed by n=20 students and the post-survey was completed by n=14 students. Click the image for the full size version.

Overall this group of students moved strongly toward increasing agreement on every question, suggesting that student perceive that they are achieving the learning goals set for the course. There were only two statements with which a few students disagreed on the post-course survey. On the first, several students strongly disagreed that they had contributed to a FOSS project in the past. All students in the course made contributions to the FarmData2 project by commenting on issues and making a pull request for a documentation improvement. It is possible that students did not consider these to be actual contributions, did not consider FarmData2 to be a real FOSS project, or they may have interpreted this question as asking about prior to this course. In all cases, more clear messaging about what constitutes a contribution should address this. In the second, students as a whole agreed less strongly (as compared to other questions) that they knew how to write a good bug report. Students worked with issue trackers, read bug reports and had the opportunity to comment on them. However, instruction on this topic was implicit rather than explicit. Thus, this result is consistent with the course materials used in this offering. More explicit instruction and practice with writing issue tracker ticket is planned for the next revision of the course.

Reflections & Content Improvements

The materials in this repository reflect the first offering of this course. As with any course, not to mention one created in such unusual circumstances, there is room for revision and improvement in future offerings. Some overall reflections on the course and materials to be addressed as well as some more specific content areas to be improved are outlined below.

Reflections

  • Students engaged with the materials and in individual discussions reported learning a lot. Of particular note, this was true both of students who had limited exposure to Linux and the command line, as well as those who were more experienced. One student in particular, who had "taught himself Linux," and setup his own web server, frequently mentioned how he was still learning new things. Thus, the course seems pitched at a good level both for those without prior Linux and command line experience and those that have built up some experience on their own.

  • Overall the activity sheets would benefit from a more intentional structure and progression of questions. The concepts of directed, convergent and divergent questions from the POGIL methodology may provide a useful framework for this revision. Some more specific thoughts on this include:

    • Many of the activities guide students through a series of steps that model typical scenarios, usage patterns or workflows. These activities give each student a concrete experience with the related skill or concept. The questions associated with these activities are often of the form "what command did you use?" or "what output was generated?" While providing these answers ensures that each student has had the desired concrete experience, they may feel didactic. However, having such experiences are an essential first step for most students in internalizing and generalizing the skills and concepts and being able to verify that they have had them is an important part of the course assessment. One way to address this may be by making the intention of these directed and convergent questions explicit to students. They could be clearly distinguished in some way from divergent questions that require more thought, reflection and understanding (more below).
    • The activities do contain reflective and divergent questions that require the generalization or synthesis of the skills and concepts. However, they should be more frequent and applied more systematically. The approach in the prior point of clearly distinguishing different types of questions will be useful in being more intentional about including questions of all three types.
    • The activities have a mix of narrative, steps to be taken and questions to be answered. Some steps require answers, others do not. This mixture resulted in some students occasionally missing places where questions required an answer. Adding answer boxes to the activity sheets is a simple way that this can be addressed in the future. This will have the added benefit of simplifying grading by clearly delineating the student responses from the narrative of the activity sheets. Related to the prior two points, the styling of the answer boxes could be the mechanism used to indicate the type of each question. This could have the added benefit of reinforcing in the students' minds the role the importance of each type of question for independent learning processes.
  • The FarmData2 project and HFOSS did not play as central a role in the course as was originally hoped. This was in part due to constraints on course development time and in part due to the relative immature state of FarmData2 when the course began. Over future iterations of the course both HFOSS and the FarmData2 project will become a more fully integrated part of the course from the start. For example, if the installation of FarmData2 becomes simple enough, it could be done early on in the course and then activities such as the command line tools, shell scripting and version control could be applied, if not introduced, in the context of FarmData2.

Content Improvement

  • The introduction of regular expressions in Activity 03 seemed insufficient and should be reconsidered. The idea of regular expressions, at least simple matching patterns, are an important topic. Focusing on a few key usage patterns (e.g. wildcards, start or end of line matching, etc), rather than more broadly, should help reduce the scope and improve student facility with the essentials.

  • The coverage of intellectual property in Activity 06 was adequate but could be improved. There was no single resource found that covered the key IP areas (patents, copyright, trademark, design rights) at an appropriate depth that was consistent across areas. Ideally an introduction to all of these areas that clearly delineates their purpose, requirements and limits can be found or pieced together. If not, one could be produced. This would then, as it is now, be the stepping off point for covering FOSS licensing and its relationship to copyright in greater depth.

  • Options for adapting Activities 07 and 08 (on version control, the branching workflow and merge conflicts) to use a frozen/resettable version of a real project should be explored. It will be essential to keep the cognitive load of the code changes to a minimum to allow the focus to be on learning version control. Perhaps small changes to wording or interface colors or fonts might be a good target. Additionally, approaches for automating the merging of pull requests and the introduction of merge conflicts should be explored. The use of something like GitHub Actions should provide all of the necessary capabilities.

  • A mature HFOSS project should be identified for use in Activities 09 and 10 on build tools and Docker. These activities currently use the FreeCiv project. This was a choice of efficiency as prior activities had already been developed for this project based on its use in the book Practical Open Source Software Exploration. Projects in the GNOME GitLab seem like good targets for this move as many of them use the traditional build tools and require dependencies to be installed. Admittedly, as projects move to container based distributions and development environments exposure to the traditional build tools will become less and less of a concern.

  • It is an open question for consideration whether the creation of container images (e.g. writing Docker files) should be included in the course. From the perspective of joining a FOSS project this is unlikely to be necessary. But from the perspective of creating a FOSS project it is increasingly essential. I would expect that a new activity following Activity 10 could cover elementary examples of Docker and docker-compose files sufficient to provide an understanding of the fundamental concepts involved. Alternatively, Activity 10 and this new one could be restructured if it yields a more effective presentation. For example, it may make sense to introduce writing docker-compose files to combine existing images into an application first, with Docker files being introduced second as a way to customize existing images.

  • Due to time constraints an activity focusing on debugger use was not developed in the first offering. Ideally, this would come after Activities 09 and 10 and make use of the same HFOSS project. This will be greatly simplified by including a browser based IDE and debugging solution in the containerized development environment used in the prior activities, possibly even having had the students produce the environment using a container for something like Eclipse Theia.

  • Activity 11 should be expanded into two activities and an open-ended finals-week assignment. The first activity would, as it begins now, focus on understanding mature HFOSS communities and an introduction to the FarmData2 community. This would include conducting critical reviews of essential documentation, doing an installation, and making contributions to documentation. The second activity, would focus on working within the issue tracker, verifying and clarifying issues and would include explicit instruction on writing for issues (to satisfy the WiD goal as mentioned earlier). A finals-week project would then provide opportunities for self-selected contributions to the project based on a curated issue list addressing documentation, issue refinement and small bug fixes or relevant new feature development (e.g. scrips, Docker files, etc).


Acknowledgements:

Partial support for the development of these materials has been provided by:

I want to thank the following individuals for their unique contributions to this project:

  • Tim Wahls, good friend and computer science faculty at Dickinson, who led the development of the original FarmData and AnimalData projects. We miss you Tim!
  • Matt Steiman, farmer at the Dickinson College Farm, it is his collaboration with Tim that made the original FarmData/AnimalData possible. It is his patience and generosity with his time that are now making FarmData2 possible.
  • Mike Stenta and the team at FarmOS, on which FarmData2 runs, for their awesome platform and the open, helpful and welcoming community that they have built around it.
  • Allen Tucker at The Non-Profit FOSS Institute for his early work porting FarmData/AnimalData to FarmOS and his continuing contributions to both FarmData2 and to HFOSS in education more broadly.
  • Michael Skalak, computer science faculty at Dickinson, who's work in understanding the FarmOS system and who's continuous work on FarmData2 is essential to its success.
  • Stony Jackson & Heidi Ellis at Western New England College and Karl Wurst at Worcester State University for their insights and advice in getting the FarmData2 project off the ground as a new HFOSS project targeted at student participation.
  • All of the students that took COMP 190 at Dickinson College with me in fall 2020. Their thoughtful feedback on the course activities and their contributions to FarmData2 will make both better!

Finally, I want to mention some of the outstanding resources that either directly or indirectly informed the activities and materials created for this course:


Licensing:

Creative Commons Attribution-NonCommercial-ShareAlike 4.0 International License

All textual materials provided in this repository are licensed under a Creative Commons Attribution-NonCommercial-ShareAlike 4.0 International License

dickinsonhfoss-comp190's People

Contributors

braughtg avatar braughtstu avatar

Watchers

 avatar  avatar

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    ๐Ÿ–– Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. ๐Ÿ“Š๐Ÿ“ˆ๐ŸŽ‰

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google โค๏ธ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.