CI285 introduction to functional programming
School of Computing, Engineering and Mathematics
General description of the coursework: There are three parts to this task:
- design of an appropriate RESTful API,
- implementation of your API, and
- a short reflective report.
The RESTful API should be an appropriate mechanism for calculating the addition of integers. That is to say, your API should support the basic operations of a calculator. And an advanced design will support both unauthenticated and authenticated requests. Authenticated users should be offered their calculation history as an additional feature. This should be accounted in the RESTful API.
You may implement your RESTful API using any Haskell based technology that you choose. We will be covering the implementation of REST APIs using Yesod in lectures. Furthermore, you should include some unit tests for your API implementation.
Finally, a short reflective report is required. The purpose of this reflective report is for you to explain how your design maps onto implementation. We are looking for your report to show insight into your design and implementation. A more straightforward howto is not considered to show insight. It is considered a good example of best practice for your report to link to changes documented in your git commit log. These links can be to public URLs on a service such as GitLab or GitHub.
A short note on achieving an ‘A’ grade: To achieve an ‘A’ grade, you should extend your RESTful API to allow users calculate the nth digit of π. The implementation of this calculation must then parallelize the computation of the nth digit. You should be aware that we are unlikely to cover use of the par monad or other parallelization technique in class. As such, this is certainly an ‘A’ grade direction.
Module outcomes assessed by this piece of work: Learning outcomes 2, 3 and 4.
Indicative marking criteria:
Percent of total criteria
25% Calculator API design.
25% Calculator implementation.
25% Persistent data storage and querying.
25% π calculation task.
Note that the above criteria are indicative. This means that if you do something interesting, then I can give you marks for that.
Submission procedure:
Your code should be in a public git repository that I can pull from. A plaintext document called README.md (i.e. markdown formatted) should be in the root of your archive and detail exactly how to build your code. If you have used any 3rd party code, you should document this in the README file and ensure that you’re using the code under a licence that allows it. An astute student may automate the build using stack/cabal. If your documentation for building your code is not correct and concise, then it will be harder for me to build your product. If I can’t build your product, it’s even harder for me to award marks.
To submit your project you should do two things:
- Ensure the latest version of your source code has been pushed to some repository that I can pull from, and
submit the repository URL and reflective report as a PDF (I only accept PDF for technical reasons) on StudentCentral.
- A copy of your coursework submission may be made as part of the University of Brighton and School of Computing, Mathematical and Information Sciences procedures which aim to monitor and improve quality of teaching. If a copy is made, it will be kept only for this purpose and will be destroyed once this purpose has been fulfilled. You should refer to your student handbook for details.
- All work submitted must be your own (or your teams for an assignment which has been specified as a group submission) and all sources which do not fall into that category must be correctly attributed. The markers may submit the whole set of submissions to the JISC Plagiarism Detection Service.
