The Sci-GaIA Winter School
This post describes the thoughts and experiences in the runup to and development of the Sci-GaIA Winter School 2016. The winter school was originally designed as part of the project proposal, as part of a series of technical development meetings which included both this winter school and a later summer school. Since it was developed in the context of the Sci-GaIA project, there was a particular focus on the development of science gateways, and relevant applications which could be included in them. There was a signficant amount of effort spent to identify capable teams which were interested in participating to this school, and there were several criteria in identifying them. Most of the applicants came from institutes participating in or closely associated with the project, however the call for participation was entirely open. Eventually, 11 applications from as many teams were accepted.
Open and Reproducible Learning
This event was is as much a learning process for those preparing and hosting the course as it is for those taking it, and there were several goals associated with the course aside from the central goal of extending the repertoire of applications in the Africa Grid Science Gateway. Great emphasis has been placed by the Sci-GaIA project on the practice of Openness, in particular, the practice and philosophy of Open Science. The project has indeed gone so far as to make a public declaration of the position of the consortium members on this point, which culminated in the Dakar Declaration on Open Science1. Putting the philosophy of Open Science into practice implies developing courseware which itself is Open2, however due to the nature of the course and the curriculum, merely having the lesson plan and learning content available is not enough. Since much of the course revolves around developing software, we need a means to check and validate this software - preferably in an automated way. Furthermore, we teach the design and implementation of this software with a particular environment in mind, that if a federated distributed computing platform. Without access to an environment simulating this, for testing and integration purposes, the school would have little sense if it were re-run elsewhere. Therefore, the school resources which needed to be “opened” were not only the content (slides, video lectures, assignments etc), but also the functional environment in which the school’s participants would be working. In order to make this reproducible, a fair amount of automation and code3 for the orchestration of support services was desired.
The first online school
Whilst this was not the first time that a short intensive course on science gateway development was being conducted by the members of the consortium, it did however represent the first time that this would be done entirely online. There was to be no face-to-face participation or interaction between the students and lecturers, and this represented particular challenges both to the lecturers and to the students. For one thing, a choice of courseware delivery had to be made at the start of the project. The choice was not a trivial one - the online learning space is perhaps not crowded, but is at least well-populated with very capable and mature platforms. We discuss the choice of OpenEdX below.
Although this school was not to be a MOOC4, it had a few of the aspects of one.
a course of study made available over the Internet without charge to a very large number of people."anyone who decides to take a MOOC simply logs on to the website and signs up"
Whereas a MOOC is, according to the definition, open to all who sign up, our course had a far more limited scope since there was some review involved in the acceptance of the applicats. It is however offered for free, and a certificate of attendance will be offered to those who complete the course assignments and follow the lectures. This was thus the first time that we had to consider the implications of verifying a student’s knowledge and progress without being able to physically sit next to them and see for ourselves. This distance had implications for the evaluation of student learning and progress monitoring, especially considering the curriculum.
A new course had to be developed, since there is to our knowledge no existing curriculum which covers the aspects which are needed for the science gateway development course. However, aspects of the curriculum were supported by content generated and maintained by others5
The high-level overview of the course curriculum is as follows :
- Development Environment
- Portlet Development
- Liferay User Interface
- Liferay portlet preferences
- Catania Science Gateways Framework
- Job submission portlet development
- Application development
In the first and second sections, there is a lot of time dedicated to instilling relevant concepts, workflows and tools for developing software in (distributed) teams. Much inspiration was taken from the Software Carpentry lessons6. Indeed, to save time and promote the re-use of material, students were told to follow the bash and git lessons. Although these were not excplicit prerequisites of the course7 in terms of developing science gateway portlets, it was essential for the students to have a good working knowledge of the shell and change control, in order to effectively collaborate with each other and the course staff.
In this section, we describe the services tools necessary to actually run the course, and provide some discussion to support our choices in certain cases. In the effort to ensure that the course was reproducible, as mentioned above, it was necessary to provide not only the content, but also the necessary environment to execute the course. We refer to this as tooling, and there are several components:
- Courseware platform
- Development Environment
- Discussion Forum
- Code Review Service
- Continuous Integration and testing Service
The most obvious component necessary for an online course is the courseware platform. This is required in order to serve content, as well as define assignments and track the proress of students.
Continuous Integration and testing
References and Footnotes
This declaration was made in Dakar during the Sci-GaIA Open Science workshop, co-hosted with the WACREN annual meeting in 2016. The declaration itself and all supporting material are in a Github repository ↩
Open Educational Resources have several definitions and aspects. The aspect which we found most important were the re-usability (including availability and licensing issues) and open-source nature of the resources. ↩
We refer here to the Ansible playbooks which were developed for the orchestration of the services described in “Tooling”, which were essential to the school. These were delivered for the express purpose of the school, and could in principle be re-deployed by others on their own infrastructure, in a different context, making the school not only replicable, but also reproducible. ↩
We used software carpentry, docker docs, githubg docs, liferay docs ↩