A year ago I started to implement a GUI app that I could use to track the 250-300+ student projects of my Data structures and algorithms course. The motivation for the tool was to answer the question:
How can you manage four courses with nearly 1000 students when you only have two full time teachers and two part-time supportive teachers to manage all teaching, evaluating and supporting the students in their learning in all of these courses?
Me
The plan was, that using this tool, I could more easily be aware of the statuses of the many student projects in this one course. And then when necessary, do something about possible issues.
Like, knowing that a student is left behind (no commits to the project in the last week or two), gives me a possibility to ask if there is anything I as a teacher could do to help the student to proceed in the course.
And if one or several of the unit tests of the various course programming tasks fail, especially if the task was supposed to be finished already, I could go and check the reason(s). Either by asking the student or taking a look at the git repository of the student myself.
The version last year required me to run shell scripts that would automatically retrieve the up to date code of the student from their remote repository using git pull. Output was directed to a log file the app then parsed to view the content. Similarly, tests were executed in batch from shell scripts with Maven (mvn test), result written to another log file. Again, the app would parse that log file to show in a graph how the tests succeeded or failed.
A while ago I decided that I would like to integrate all the functionality within the GUI app and ditch the separate shell scripts. Also, I decided that the information about the commits and test results would be saved into a database. This way, when app launch is now much faster since it does not need to parse the various log files to show content every time the app is launched.
Instead, when launched, the app reads the repository information, git log data and the test results from a database file. App launches much faster with immediately visible data. When I want to update the commit data for all student repositories, I just press the refresh button in the app toolbar and the app starts to pull data for each repository from the remote repository URLs.
When I want to update the test data, pressing another button (the hammer button in the toolbar) starts to execute tests that are due, saving the test results in the app database. I can also refresh an individual repo from remote or execute tests for a single project to get a quick update on the status of the student’s project.
Until now I’ve focused on getting the tabular data visible. Yesterday, I implemented a similar commit grid view you can see in a person’s GitHub profile. This color grid shows the commits visualised for all student repositories:
In this grid, time proceeds vertically from up towards bottom of the grid view. Each repository is one thin column on the grid. The timeline starts from the date the course started, proceeding down.
The grid ends at the current date in the bottom of the grid. So when the course proceeds the grid gets taller. Since this course displayed here started on September, the grid here is 42 days “tall”. This will give me a very high level visual awareness of level of activity among all the students in the course.
Obviously the usefulness of the tool depends on the fact (?) that students push their commits to the remote repository often, preferably daily or at least weekly. If they do not, we teachers cannot see them and this tool does not show them. As you can see, some of the repositories are in red, meaning there has not been a commit for over 14 days. Orange repositories indicate the most recent commit being over a week old.
Red and orange colors may mean that the student has decided to do most of the course progrmming just before the deadline. A common though not the best choice. So seeing lots of red at this point does not necessarily mean big issues with passing the course. We’ll see…
I’ve been constantly trying to motivate the students to do commits and pushing often. It is beneficial for them too – you get a backup of your work in the remote, and when you need teachers’ assistance, teachers have immediate access to the code from the remote.
Since the first real deadline of the course will be after two weeks, it is time for me to start using the information from the tool:
- I can easily send email to the student not having recent commits, by clicking on the (redacted) blue text where student name is displayed – that will initiate an email I will send to the student.
- Clicking on the repository URL (also redacted) will open the browser and take me to the remote repository web page of that student.
- Another (redacted) blue line will open the local folder in Finder for me to start looking at the student project directory on my machine.
Those repositories in blue are all OK, and (probably) I do not need to be concerned with those. Especially if the scheduled tests also pass. The purpose of the tool is to let me focus on those students that probably need attention to be able to pass the course in time.
Some implementation details:
- Implemented on macOS using Xcode, Swift and SwiftUI.
- Uses Core Data as the app database, with five database tables and ten relationships between the tables.
- Executes
gitandmvn testcommands in child processes usingProcessclass. - SwiftUI
Tableused for tabular content. - Commit grid is draw in a SwiftUI view using
CanvasandGraphicsContext. - Uses the SwiftUI
redacted(reason:)function to hide student information for demonstration purposes. - Student and repository data is imported from a tab separated text file exported from Moodle. There, student enter their information and the remote repository URL in a questionnaire form. The form data is then exported as a
tsvfile, which is imported to the app and all student data is written to the database. No need to enter the student data manually.