the bonnet is up and we're on bricks. Fix it.

[mankyKitty]

This is a fixathon, hacking is for the students. :smiley:

• Update the nix-shell environment to more up to date definition, and include sqlite as it wasn't there before.
• Replace the use of aeson with waargonaut. This is up for discussion as waargonaut is a new QFPL library and aeson is far more prevalent in the wild.
• Improve the comments and explanations for various functions throughout the course as student feedback indicated that it was not always clear as to what was intended. In those situations where the types did not provide much guidance.
• Add another exercise involving generalising their existing AppM to allow for changing the error type. This allows for a more interesting challenge in the prepareAppReqs function initially. As well as allowing for an introduction to using the ExceptT transformer as a localised substitute when it is no longer possible to use AppM.
• Delete the application from Level03 and replace it with a more involved testing exercises where the students are actually testing their own code.
• Delete all duplicated testing. All testing will take place in the one module and students are expected to update this with their latest Application to check their work. As the initialisation of the Application becomes more involved in the latter stages, this will provide additional challenges.

TODO

• [x] Add documentation around using the :memory: file path when testing using the database.
• [x] Add initial Level08 document.

[gwils]

I like the change to waargonaut. It will certainly help to get more eyes on it. It will also be the library we're best able to help with after students finish the applied course when they start their own projects.

My only concern is that it's still new, but we're happily using it in other qfpl projects, so it's proven itself.

[mankyKitty]

Part of the concern that was raised about using waargonaut over aeson is that the moment you leave the course, you're going to encounter an ecosystem of packages that (almost) all use aeson.

It's a question of how well this choice aligns with the purpose of the course. Does it benefit the students or are we just using the course to push our own libraries. That's an extreme wording, but it gets the point across.

Ideally, the students will gain sufficiently general Haskell skills that they can establish how things work and use the tools they want. So our choice of aeson/waargonaut shouldn't be an issue.

My anec-data thus far is that the students enjoy these sorts of discussions and discussing pros and cons of approaches is something they want to get out of the course. So I plan to keep waargonaut in there for now, but explicitly raise it with the next class to get their opinion.

[gwils]

When I try to build this, I get errors about Level03/Core and Level03/Types listed in the exposed-modules section of the cabal file.

[mankyKitty]

Hrmm, that should be fixed already.

[gwils]

Ah yes, the trick is to git pull.

[gwils]

My anec-data thus far is that the students enjoy these sorts of discussions and discussing pros and cons of approaches is something they want to get out of the course. So I plan to keep waargonaut in there for now, but explicitly raise it with the next class to get their opinion.

As you say, feedback from students would be a good way to decide this.