mirror of
https://github.com/qfpl/applied-fp-course.git
synced 2024-11-23 03:44:45 +03:00
Documentation updates.
Readme install and setup instructions improved. Added note about course being designed for use in a guided environment. Made the FUTURE_PLANS a little less self-interested.
This commit is contained in:
Sean Chalmers
parent
d913dfc49a
commit
91d9dd90b3
@ -1,27 +1,10 @@
|
||||
Use of lenses and classy `mtl` will be left to supplemental material. I would
|
||||
like to be able to use it lenses more but the additional explanation required
|
||||
Use of lenses and classy `mtl` will be left to supplemental material. It would
|
||||
be nice to be able to use it lenses more but the additional explanation required
|
||||
might be a bit much and not very predictable ?
|
||||
|
||||
Ultimate Goal
|
||||
===============
|
||||
### Further lessons
|
||||
|
||||
This course aims to teach some of the techniques for building a larger
|
||||
application with FP, using Haskell. By the end of this course you should be
|
||||
comfortable tackling more advanced projects, and expanding on the concepts and
|
||||
choices presented here in your own future efforts.
|
||||
|
||||
We will build an ultra basic web application and build upon it.
|
||||
|
||||
Subgoals (?)
|
||||
========
|
||||
- ghcid
|
||||
- hedgehog
|
||||
- cabal files
|
||||
|
||||
Goals
|
||||
======
|
||||
|
||||
1 - Death to Strings
|
||||
N - Death to Strings
|
||||
---
|
||||
Start up and Servant introduction.
|
||||
|
||||
@ -29,7 +12,7 @@ Start up and Servant introduction.
|
||||
* Explain that we're using strings for routes and this is bad(TM).
|
||||
* Move to Servant, explain why, show type driven dev to explain routes->function relationship.
|
||||
|
||||
2 - Faking Global Vars with Science
|
||||
N - Faking Global Vars with Science
|
||||
---
|
||||
Show that nothing can be changed in the current app without recompliation.
|
||||
Rework the application so we can change the port values and have general app
|
||||
@ -40,7 +23,7 @@ config.
|
||||
* Add `mtl` dependency.
|
||||
* Natural Transformation required from our new `ReaderT` to Servant (too much?).
|
||||
|
||||
3 - Would you like to play a game?
|
||||
N - Would you like to play a game?
|
||||
---
|
||||
Introduce handling input/output also preempt the inclusion of persistent storage.
|
||||
|
||||
@ -50,7 +33,7 @@ Introduce handling input/output also preempt the inclusion of persistent storage
|
||||
* Add the required instances.
|
||||
* Change the function up so that it randomly selects a move, evaluates victory/defeat.
|
||||
|
||||
4 - Type safe tantrums
|
||||
N - Type safe tantrums
|
||||
---
|
||||
Introduce error handling by breaking REST rules by having our application throw
|
||||
an error when it loses at Rock-Paper-Scissors.
|
||||
@ -61,7 +44,7 @@ an error when it loses at Rock-Paper-Scissors.
|
||||
* More discussion to be had here regarding the ordering of transformer stacks.
|
||||
* Discuss the errors that appear. Work through fixing these with type-holes in the Natural Transform.
|
||||
|
||||
5 - Elephants
|
||||
N - Elephants
|
||||
---
|
||||
We'd like to be able to store a history of RPS games.
|
||||
|
||||
@ -77,7 +60,7 @@ We'd like to be able to store a history of RPS games.
|
||||
|
||||
** Prompt discussion about what lurks beneath the surface of the `IO a` query functionality.
|
||||
|
||||
6 - Except when exceptionally excepted
|
||||
N - Except when exceptionally excepted
|
||||
---
|
||||
Handling, catching, and rethrowing exceptions. Motivate errors as values over exceptions.
|
||||
|
||||
@ -92,7 +75,7 @@ Handling, catching, and rethrowing exceptions. Motivate errors as values over ex
|
||||
|
||||
* Discuss how you might implement logging ? Leave as exercise.
|
||||
|
||||
7 - BOSS FIGHT - A
|
||||
N - BOSS FIGHT - A
|
||||
---
|
||||
Replace the stringly DB layer with something better:
|
||||
- [Selda](https://selda.link/)
|
||||
@ -111,7 +94,7 @@ time, to varying degrees:
|
||||
All packages use generics of some description, not sure how much air time they
|
||||
need? Passing mention and throw some links around, move on.
|
||||
|
||||
8 - BOSS FIGHT - B
|
||||
N - BOSS FIGHT - B
|
||||
---
|
||||
Integration of 'classy mtl' style application design.
|
||||
|
||||
|
||||
57
README.md
57
README.md
@ -1,4 +1,6 @@
|
||||
## Advanced FP Course
|
||||
# Advanced Functional Programming Course
|
||||
|
||||
|
||||
|
||||
### You:
|
||||
|
||||
@ -22,16 +24,52 @@
|
||||
* Will utilise both type & test driven development techniques
|
||||
* Will explain architectural and design trade-offs when appropriate
|
||||
|
||||
|
||||
### Course Sequence:
|
||||
|
||||
You're welcome to setup your own project with ``$ cabal init`` and follow along
|
||||
with the general flow of the course, or work through the exercises in the
|
||||
projects provided.
|
||||
|
||||
#### Subsequent lessons may have spoilers, don't cheat yourself out of experience!
|
||||
Each level is a self-contained Haskell application, containing incomplete or as
|
||||
yet undefined, data types and functions. There is a cabal file and Nix
|
||||
configuration files for each level, so you can use either cabal sandboxes or a
|
||||
``nix-shell``, depending on your preference.
|
||||
|
||||
NB : No doctests yet :(
|
||||
To use a sandbox:
|
||||
```bash
|
||||
$ cd <levelN>
|
||||
$ cabal sandbox init
|
||||
$ cabal configure
|
||||
$ cabal install --only-dependencies
|
||||
```
|
||||
The normal cabal build commands should then work as expected. We do recommend
|
||||
using cabal sandboxes as they provide a contained Haskell environment for a
|
||||
given project. Easy to clean up and package versions won't clash with any other
|
||||
sandboxed project you may be working on. Hence their name.
|
||||
|
||||
To use the Nix Shell:
|
||||
```bash
|
||||
$ cd <levelN>
|
||||
$ nix-shell
|
||||
```
|
||||
Once that completes you will be in a ``nix-shell`` environment with all the
|
||||
tools required to make build the application for that level. Note that the
|
||||
levels build on each other, so you can go to the highest level and enter a
|
||||
nix-shell there, you will then have all the required tools for every level.
|
||||
|
||||
The ``shell.nix`` is provided separate from the ``default.nix`` so if you have a
|
||||
different workflow you can still utilise the derivation.
|
||||
|
||||
##### Please note...
|
||||
|
||||
These lessons are designed to be completed with an instructor as part of the
|
||||
Data61 Advanced Functional Programming Course. You are of course welcome to
|
||||
clone the repository and give it a try, but you may find the tasks more
|
||||
difficult. If you have any questions we can be contacted in
|
||||
the [#fp-course IRC channel](https://freenode.net). You can use the
|
||||
free [WebChat client](https://webchat.freenode.net).
|
||||
|
||||
#### Subsequent lessons may contain spoilers, don't cheat yourself out of the experience!
|
||||
|
||||
* Level 01 : Simple Hello World web app.
|
||||
* Level 02 : Define our application spec with types!
|
||||
@ -44,11 +82,8 @@ NB : No doctests yet :(
|
||||
-- Coming Soon...
|
||||
* Level 08 : (Bonus Round) Lenses & Refactoring
|
||||
|
||||
-- Unsure...
|
||||
* Level 09 : Add session controls (login, logout), so I can have some semblance
|
||||
of application state so I can add some property based tests for the
|
||||
login/logout/access restricted area state machine
|
||||
|
||||
TODO:
|
||||
* Teacher notes/guide
|
||||
-- Maybe...
|
||||
* Level 09 : Add session controls (login, logout) and a protected route. So we
|
||||
can have something that resembles application state. For the purposes of
|
||||
modelling the state machine and implementing some property based tests.
|
||||
|
||||
|
||||
Loading…
Reference in New Issue
Block a user