The truth is in the code...
The MsDO course is more oriented towards engineering than towards theory, which is reflected in the exam formats of the first two courses: They are centered upon solving exercises on the mandatory SkyCave project.
It is therefore essential that each of you setup a strong development environment.
The required toolstack includes:
You will also need a hosting provider for your Git repository. I advice BitBucket as the lessons on continuous delivery is based upon bitbucket pipelines. However, if you are used to GitHub or another CI/CD pipeline, it is fine with me.
I recommend that you use the course VM, M101, for your development. M101 comes with all recommended tools and the SkyCave code base (See update below) installed, so no trouble there. It is Linux which is a major player in the MsDO arena. By using it, you will keep your own machine clean of all the MsDO tools. And VMs are of course also an essential learning topic on its own right. So - lots of reason to use it.
To execute, you need VMWare WorkStation Player (Windows/Linux, free of charge for personal use), or VMWare Fusion (Mac, Tryware). However, instead of downloading these, you can as AU students get a 1 year license for the full VMWare WorkStation Pro/Fusion. To do that, use Software on the Hub, follow the link a bit down on the page, requires that you log in as AU student.
You will find M101 in the zip file: m101-msdo.zip (Zip / 4.4GB). Unzips to a folder with a VMWare version 15 virtual machine. It is a 64-bit Lubuntu 18.04 LTS Desktop machine with Java 11, Gradle 6.8, Git, Docker, and IntelliJ. User: csdev; pwd: csau. The SkyCave code is located in ~/proj/cave.
M101 is configured with 4GB RAM and 2 processors, but if you have more juice in your machine, you may wish to provide more CPU and RAM.
Why 'M101'? It is the old Messier catalogue number for the Pinwheel galaxy, which is the background picture (By ESA/Hubble, CC BY 4.0, Link) of the VM. I have a degree in astronomy way back...
If you prefer, you are of course also welcome to install the toolstack on you local machine, avoiding the M101.
You will then have to get the SkyCave Release 2107 (Zip) source code and install that manually. (See update below)
Liden tue kan vælte stort læs...
16th Aug: Unfortunately, an almost invisible
defect in 'PlayerServant's getQuote() method in the
2107 release of SkyCave will cause you trouble down the line, if
not fixed.
In the getQuote() method of class PlayerServant,
you will find the hardcoded string for quote 13:
if (quoteIndex == 13)
return "Education is what remains after one has forgotten what one has learned in school - Albert Einstein";
Comparing to the other two quotes, you will probably not notice that there is a dot missing, after the quote and before the dash. However, down the line, Crunch will notice and reject your code base.
So - introduce that 'end-of-quote-dot' in the source code,
... in school. - Albert ..., and update the test case that
fails due to matching on the old string.
Sorry for the trouble. There are a lot of moving parts in this course...
One central mandatory exercise is to make your own SkyCave system run in the cloud, so you need a cloud provider.
You can choose any you like, of course. Many of the suppliers have introduction offers that allows running for free for some limited time. Head over to the forum to get some ideas from your fellow students.
Personally, I have two suggestions. 'cloud.dk' is a Danish supplier with hosting here in DK, so if you want to support Danish jobs, that may be a good choice. The also support the 'flat rate' that I prefer to a more complex accounting system like for instance Amazon EC2. My favorite supplier is however 'DigitalOcean.com' that provides a pane called 'Markedplace' on which you can create a VM with Docker preinstalled. They also run a flat rate policy.
In the course, some exercises are marked by automated evaluation and feedback to exercises using "Crunch" which is a project that I developed in 2016, and resurrected for the F2020 course with success. So it will do another round of 'crunching your exercises.' Credits to Daniel Damgaard for pioneering quite a few of the tricks employed in his Master Thesis Summer 2016.
Automated assessment of distributed systems with feasible student feedback is frontier research and difficult, so please, keep an eye open for problems; and report to me, if you encounter any...
I made a paper on the topic Crunch: Automated Assessment of Microservice Architecture Assignments with Formative Feedback, if you are interested is some of the 'behind the scenes' stuff...
Once your group has solved an exercise marked by the [A]
notation for "Automated Evaluation" you submit it to Crunch
using a special web page, not by BrightSpace. You will need your
group's token (the groupToken field in the returned
authentication record from the SubscriptionService), as our
submission page is secured by obfuscation, and not by standard
security protocols, sorry. Do not share your group token,
this would allow others to submit exercises on your behalf!
You open the url
https://crunch.cs.au.dk/overview/(groupToken),
similar to the example below, showing a group with groupToken =
Hafnium738_Botswana880
This page both serves to show your progress as well as submitting more exercises for automated evaluation. Just enter the name of an exercise and hit the 'Submit' button. In the page above, four exercises have been evaluated but 'quote-service' did not pass Crunch's test suite.
Crunch is a batch program which runs every hour during the day. Thus submitting an exercise just enters it into your group's queue of exercises to be evaluated. All exercises are evaluated every time (in a previous course, I experienced groups that solved a new exercise but broke their solution to an earlier one. That is not doing DevOps!) Crunch stops testing as soon as the first test case fails - and always evaluates them in the sequence they appear on the mandatory exercise pages.
If a test fails, hit the 'Link to detailed result' that is a web page generated by Crunch providing as much information as possible in order to allow you to diagnose the failure: What it did, what it expected, 'docker logs' from the cmd and daemon, etc.. Please, report if you find this information confusing or important aspects are missing, so I can improve the output!
Note: Image from the 2016 version of Crunch, the output format has changed a bit...